[Intel-gfx] [PATCH 04/23] drm: Add drm structures for palette color property

[Sharma, Shashank]

Regards
Shashank

On 9/21/2015 10:16 PM, Ville Syrjälä wrote:
> On Wed, Sep 16, 2015 at 11:07:01PM +0530, Shashank Sharma wrote:
>> From: Kausal Malladi <kausalmalladi at gmail.com>
>>
>> This patch adds new structures in DRM layer for Palette color
>> correction.These structures will be used by user space agents
>> to configure appropriate number of samples and Palette LUT for
>> a platform.
>>
>> Signed-off-by: Shashank Sharma <shashank.sharma at intel.com>
>> Signed-off-by: Kausal Malladi <kausalmalladi at gmail.com>
>> ---
>>   include/uapi/drm/drm.h | 27 +++++++++++++++++++++++++++
>>   1 file changed, 27 insertions(+)
>>
>> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
>> index e3c642f..f72b916 100644
>> --- a/include/uapi/drm/drm.h
>> +++ b/include/uapi/drm/drm.h
>> @@ -840,6 +840,33 @@ struct drm_palette_caps {
>>   	__u32 num_samples_after_ctm;
>>   };
>>
>> +struct drm_r32g32b32 {
>> +	/*
>> +	 * Data is in U8.24 fixed point format.
>> +	 * All platforms support values within [0, 1.0] range,
>> +	 * for Red, Green and Blue colors.
>> +	 */
>> +	__u32 r32;
>> +	__u32 g32;
>> +	__u32 b32;
>> +};
>> +
>> +struct drm_palette {
>> +	/* Structure version. Should be 1 currently */
>> +	__u32 version;
>
> I don't think we want to version the blobs. For one, we don't have a way
> for userspace to ask for a specific version, so the kernel wouldn't know
> which version it should return to each client.
>
> If we ever need to come up with new version of a specific blob, I think we
> just have to define another property for it. Either that or we'd some kind
> of client cap stuff to negotiate the used version between the kernel and
> a specific client.
>
> Well, I suppose we migth be able to borrow the "flags+extend at the end"
> trick we sometimes use for ioctl parameters to work for blobs too. But I
> have a feeling we don't want to go there.
>
> So yeah, I think we should go with the "blob layout is fixed for each
> property" approach. Versioning then happens by introducing new versions
> of the same property if needed.
>
Well, reason behind adding this version was, as this framework was a new 
development, we wanted to keep scope for further changes on request from 
other drivers/modules. But yes, I agree, its kind of overhead, so we can 
also remove it. Will do that in next patch set.
>> +	/*
>> +	 * This has to be a supported value during get call.
>> +	 * Feature will be disabled if this is 0 while set
>> +	 */
>> +	__u32 num_samples;
>> +	/*
>> +	 * Starting of palette LUT in R32G32B32 format.
>> +	 * Each of RGB value is in U8.24 fixed point format.
>> +	 * Actual number of samples will depend upon num_samples
>> +	 */
>> +	struct drm_r32g32b32 lut[0];
>> +};
>> +
>>   /* typedef area */
>>   #ifndef __KERNEL__
>>   typedef struct drm_clip_rect drm_clip_rect_t;
>> --
>> 1.9.1
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>