diff mbox

drm: Set depth and bpp for XRGB4444 family formats

Message ID 1470820916-20607-1-git-send-email-fabien.dessenne@st.com (mailing list archive)
State New, archived
Headers show

Commit Message

Fabien DESSENNE Aug. 10, 2016, 9:21 a.m. UTC
These pixel formats are supported by format_check() from drm_crtc.c, so
provide there depth and bpp.

Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com>
---
 drivers/gpu/drm/drm_fourcc.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

Comments

Daniel Vetter Aug. 10, 2016, 10:35 a.m. UTC | #1
On Wed, Aug 10, 2016 at 11:21:56AM +0200, Fabien Dessenne wrote:
> These pixel formats are supported by format_check() from drm_crtc.c, so
> provide there depth and bpp.
> 
> Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com>

Why? Who's going to use this?
-Daniel

> ---
>  drivers/gpu/drm/drm_fourcc.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index 0645c85..aa8c909 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -80,6 +80,17 @@ void drm_fb_get_bpp_depth(uint32_t format, unsigned int *depth,
>  		*depth = 8;
>  		*bpp = 8;
>  		break;
> +	case DRM_FORMAT_XRGB4444:
> +	case DRM_FORMAT_XBGR4444:
> +	case DRM_FORMAT_RGBX4444:
> +	case DRM_FORMAT_BGRX4444:
> +	case DRM_FORMAT_ARGB4444:
> +	case DRM_FORMAT_ABGR4444:
> +	case DRM_FORMAT_RGBA4444:
> +	case DRM_FORMAT_BGRA4444:
> +		*depth = 12;
> +		*bpp = 16;
> +		break;
>  	case DRM_FORMAT_XRGB1555:
>  	case DRM_FORMAT_XBGR1555:
>  	case DRM_FORMAT_RGBX5551:
> -- 
> 1.9.1
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
Fabien DESSENNE Aug. 10, 2016, 11:04 a.m. UTC | #2
On 08/10/2016 12:35 PM, Daniel Vetter wrote:
> On Wed, Aug 10, 2016 at 11:21:56AM +0200, Fabien Dessenne wrote:
>> These pixel formats are supported by format_check() from drm_crtc.c, so
>> provide there depth and bpp.
>>
>> Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com>
> Why?
At least for consistency between format_check() and drm_fb_get_bpp_depth().

> Who's going to use this?
For the time being, I can see 9 drivers that make more or less use of 
this format (amd, atmel-hlcdc, exynos, fsl-dcu, imx, omapdrm, radeon, 
rcar-du, sti).
In top of that I am working on a new driver that actually needs this 
format, and that does not work without this patch.
> -Daniel
>
>> ---
>>   drivers/gpu/drm/drm_fourcc.c | 11 +++++++++++
>>   1 file changed, 11 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
>> index 0645c85..aa8c909 100644
>> --- a/drivers/gpu/drm/drm_fourcc.c
>> +++ b/drivers/gpu/drm/drm_fourcc.c
>> @@ -80,6 +80,17 @@ void drm_fb_get_bpp_depth(uint32_t format, unsigned int *depth,
>>   		*depth = 8;
>>   		*bpp = 8;
>>   		break;
>> +	case DRM_FORMAT_XRGB4444:
>> +	case DRM_FORMAT_XBGR4444:
>> +	case DRM_FORMAT_RGBX4444:
>> +	case DRM_FORMAT_BGRX4444:
>> +	case DRM_FORMAT_ARGB4444:
>> +	case DRM_FORMAT_ABGR4444:
>> +	case DRM_FORMAT_RGBA4444:
>> +	case DRM_FORMAT_BGRA4444:
>> +		*depth = 12;
>> +		*bpp = 16;
>> +		break;
>>   	case DRM_FORMAT_XRGB1555:
>>   	case DRM_FORMAT_XBGR1555:
>>   	case DRM_FORMAT_RGBX5551:
>> -- 
>> 1.9.1
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
Daniel Vetter Aug. 10, 2016, 2:12 p.m. UTC | #3
On Wed, Aug 10, 2016 at 01:04:54PM +0200, Fabien DESSENNE wrote:
> 
> On 08/10/2016 12:35 PM, Daniel Vetter wrote:
> > On Wed, Aug 10, 2016 at 11:21:56AM +0200, Fabien Dessenne wrote:
> >> These pixel formats are supported by format_check() from drm_crtc.c, so
> >> provide there depth and bpp.
> >>
> >> Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com>
> > Why?
> At least for consistency between format_check() and drm_fb_get_bpp_depth().

fb_get_bpp_depth is kinda legacy, the recommended way is to have a switch
statement in your driver that directly decodes DRM_FORMAT_* into driver
register values. The inconsistency is intentional since just looking at
bpp and depth removes a lot of information.

Probably a better patch would be to update the kerneldoc for these
functions. Also Laurent is working on a complete reorg of all this.
-Daniel

> > Who's going to use this?
> For the time being, I can see 9 drivers that make more or less use of 
> this format (amd, atmel-hlcdc, exynos, fsl-dcu, imx, omapdrm, radeon, 
> rcar-du, sti).
> In top of that I am working on a new driver that actually needs this 
> format, and that does not work without this patch.
> > -Daniel
> >
> >> ---
> >>   drivers/gpu/drm/drm_fourcc.c | 11 +++++++++++
> >>   1 file changed, 11 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> >> index 0645c85..aa8c909 100644
> >> --- a/drivers/gpu/drm/drm_fourcc.c
> >> +++ b/drivers/gpu/drm/drm_fourcc.c
> >> @@ -80,6 +80,17 @@ void drm_fb_get_bpp_depth(uint32_t format, unsigned int *depth,
> >>   		*depth = 8;
> >>   		*bpp = 8;
> >>   		break;
> >> +	case DRM_FORMAT_XRGB4444:
> >> +	case DRM_FORMAT_XBGR4444:
> >> +	case DRM_FORMAT_RGBX4444:
> >> +	case DRM_FORMAT_BGRX4444:
> >> +	case DRM_FORMAT_ARGB4444:
> >> +	case DRM_FORMAT_ABGR4444:
> >> +	case DRM_FORMAT_RGBA4444:
> >> +	case DRM_FORMAT_BGRA4444:
> >> +		*depth = 12;
> >> +		*bpp = 16;
> >> +		break;
> >>   	case DRM_FORMAT_XRGB1555:
> >>   	case DRM_FORMAT_XBGR1555:
> >>   	case DRM_FORMAT_RGBX5551:
> >> -- 
> >> 1.9.1
> >>
> >> _______________________________________________
> >> dri-devel mailing list
> >> dri-devel@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
Fabien DESSENNE Aug. 10, 2016, 3:26 p.m. UTC | #4
On 08/10/2016 04:12 PM, Daniel Vetter wrote:
> On Wed, Aug 10, 2016 at 01:04:54PM +0200, Fabien DESSENNE wrote:
>> On 08/10/2016 12:35 PM, Daniel Vetter wrote:
>>> On Wed, Aug 10, 2016 at 11:21:56AM +0200, Fabien Dessenne wrote:
>>>> These pixel formats are supported by format_check() from drm_crtc.c, so
>>>> provide there depth and bpp.
>>>>
>>>> Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com>
>>> Why?
>> At least for consistency between format_check() and drm_fb_get_bpp_depth().
> fb_get_bpp_depth is kinda legacy, the recommended way is to have a switch
> statement in your driver that directly decodes DRM_FORMAT_* into driver
> register values. The inconsistency is intentional since just looking at
> bpp and depth removes a lot of information.
I can understand  that fb_get_bpp_depth() shall not be called by (new) 
drivers.
But it is also called by the core part through drm_format_plane_cpp() 
which is not a legacy interface and is used across many drivers (I think 
that this is a recent change initiated by Ville).
> Probably a better patch would be to update the kerneldoc for these
> functions.

For the time being we have an issue with the current drivers that use 
the 4444 DRM formats and updating kerneldoc won't fix them
>   Also Laurent is working on a complete reorg of all this.

Looping Laurent who may have a different opinion, or plan to consider 
the 4444 DRM formats in its rework.

Fabien
> -Daniel
>
>>> Who's going to use this?
>> For the time being, I can see 9 drivers that make more or less use of
>> this format (amd, atmel-hlcdc, exynos, fsl-dcu, imx, omapdrm, radeon,
>> rcar-du, sti).
>> In top of that I am working on a new driver that actually needs this
>> format, and that does not work without this patch.
>>> -Daniel
>>>
>>>> ---
>>>>    drivers/gpu/drm/drm_fourcc.c | 11 +++++++++++
>>>>    1 file changed, 11 insertions(+)
>>>>
>>>> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
>>>> index 0645c85..aa8c909 100644
>>>> --- a/drivers/gpu/drm/drm_fourcc.c
>>>> +++ b/drivers/gpu/drm/drm_fourcc.c
>>>> @@ -80,6 +80,17 @@ void drm_fb_get_bpp_depth(uint32_t format, unsigned int *depth,
>>>>    		*depth = 8;
>>>>    		*bpp = 8;
>>>>    		break;
>>>> +	case DRM_FORMAT_XRGB4444:
>>>> +	case DRM_FORMAT_XBGR4444:
>>>> +	case DRM_FORMAT_RGBX4444:
>>>> +	case DRM_FORMAT_BGRX4444:
>>>> +	case DRM_FORMAT_ARGB4444:
>>>> +	case DRM_FORMAT_ABGR4444:
>>>> +	case DRM_FORMAT_RGBA4444:
>>>> +	case DRM_FORMAT_BGRA4444:
>>>> +		*depth = 12;
>>>> +		*bpp = 16;
>>>> +		break;
>>>>    	case DRM_FORMAT_XRGB1555:
>>>>    	case DRM_FORMAT_XBGR1555:
>>>>    	case DRM_FORMAT_RGBX5551:
>>>> -- 
>>>> 1.9.1
>>>>
>>>> _______________________________________________
>>>> dri-devel mailing list
>>>> dri-devel@lists.freedesktop.org
>>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
Daniel Vetter Aug. 10, 2016, 4:57 p.m. UTC | #5
On Wed, Aug 10, 2016 at 5:26 PM, Fabien DESSENNE <fabien.dessenne@st.com> wrote:
> On 08/10/2016 04:12 PM, Daniel Vetter wrote:
>> On Wed, Aug 10, 2016 at 01:04:54PM +0200, Fabien DESSENNE wrote:
>>> On 08/10/2016 12:35 PM, Daniel Vetter wrote:
>>>> On Wed, Aug 10, 2016 at 11:21:56AM +0200, Fabien Dessenne wrote:
>>>>> These pixel formats are supported by format_check() from drm_crtc.c, so
>>>>> provide there depth and bpp.
>>>>>
>>>>> Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com>
>>>> Why?
>>> At least for consistency between format_check() and drm_fb_get_bpp_depth().
>> fb_get_bpp_depth is kinda legacy, the recommended way is to have a switch
>> statement in your driver that directly decodes DRM_FORMAT_* into driver
>> register values. The inconsistency is intentional since just looking at
>> bpp and depth removes a lot of information.
> I can understand  that fb_get_bpp_depth() shall not be called by (new)
> drivers.
> But it is also called by the core part through drm_format_plane_cpp()
> which is not a legacy interface and is used across many drivers (I think
> that this is a recent change initiated by Ville).

I've dug around and the only places I've found changes is from 2012. I
think rgb444 formats just plain never worked. But in case I've missed
something and this is a regression then indeed we need to fix it. For
the real solution it's better to sync up with Laurent and his plans to
rework the fourcc handling we have in drm.
-Daniel
Ville Syrjälä Aug. 10, 2016, 5:11 p.m. UTC | #6
On Wed, Aug 10, 2016 at 06:57:02PM +0200, Daniel Vetter wrote:
> On Wed, Aug 10, 2016 at 5:26 PM, Fabien DESSENNE <fabien.dessenne@st.com> wrote:
> > On 08/10/2016 04:12 PM, Daniel Vetter wrote:
> >> On Wed, Aug 10, 2016 at 01:04:54PM +0200, Fabien DESSENNE wrote:
> >>> On 08/10/2016 12:35 PM, Daniel Vetter wrote:
> >>>> On Wed, Aug 10, 2016 at 11:21:56AM +0200, Fabien Dessenne wrote:
> >>>>> These pixel formats are supported by format_check() from drm_crtc.c, so
> >>>>> provide there depth and bpp.
> >>>>>
> >>>>> Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com>
> >>>> Why?
> >>> At least for consistency between format_check() and drm_fb_get_bpp_depth().
> >> fb_get_bpp_depth is kinda legacy, the recommended way is to have a switch
> >> statement in your driver that directly decodes DRM_FORMAT_* into driver
> >> register values. The inconsistency is intentional since just looking at
> >> bpp and depth removes a lot of information.
> > I can understand  that fb_get_bpp_depth() shall not be called by (new)
> > drivers.
> > But it is also called by the core part through drm_format_plane_cpp()
> > which is not a legacy interface and is used across many drivers (I think
> > that this is a recent change initiated by Ville).
> 
> I've dug around and the only places I've found changes is from 2012. I
> think rgb444 formats just plain never worked. But in case I've missed
> something and this is a regression then indeed we need to fix it.

Looks like I just plain forgot about these formats when I added
drm_format_plane_cpp().

> For
> the real solution it's better to sync up with Laurent and his plans to
> rework the fourcc handling we have in drm.
> -Daniel
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
Fabien DESSENNE Aug. 19, 2016, 9:01 a.m. UTC | #7
Hi Laurent,

Daniel talked about a planned reorg from you around DRM formats (or 
something like this) and I have proposed to fix some missing parts with 
the XRGB444 formats.

Can you let us know if you can consider this fix as part of your reorg?

If you can't what would be the best option to get this fixed?

Fabien


On 08/10/2016 05:26 PM, Fabien DESSENNE wrote:
>
> On 08/10/2016 04:12 PM, Daniel Vetter wrote:
>> On Wed, Aug 10, 2016 at 01:04:54PM +0200, Fabien DESSENNE wrote:
>>> On 08/10/2016 12:35 PM, Daniel Vetter wrote:
>>>> On Wed, Aug 10, 2016 at 11:21:56AM +0200, Fabien Dessenne wrote:
>>>>> These pixel formats are supported by format_check() from 
>>>>> drm_crtc.c, so
>>>>> provide there depth and bpp.
>>>>>
>>>>> Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com>
>>>> Why?
>>> At least for consistency between format_check() and 
>>> drm_fb_get_bpp_depth().
>> fb_get_bpp_depth is kinda legacy, the recommended way is to have a 
>> switch
>> statement in your driver that directly decodes DRM_FORMAT_* into driver
>> register values. The inconsistency is intentional since just looking at
>> bpp and depth removes a lot of information.
> I can understand  that fb_get_bpp_depth() shall not be called by (new) 
> drivers.
> But it is also called by the core part through drm_format_plane_cpp() 
> which is not a legacy interface and is used across many drivers (I 
> think that this is a recent change initiated by Ville).
>> Probably a better patch would be to update the kerneldoc for these
>> functions.
>
> For the time being we have an issue with the current drivers that use 
> the 4444 DRM formats and updating kerneldoc won't fix them
>>   Also Laurent is working on a complete reorg of all this.
>
> Looping Laurent who may have a different opinion, or plan to consider 
> the 4444 DRM formats in its rework.
>
> Fabien
>> -Daniel
>>
>>>> Who's going to use this?
>>> For the time being, I can see 9 drivers that make more or less use of
>>> this format (amd, atmel-hlcdc, exynos, fsl-dcu, imx, omapdrm, radeon,
>>> rcar-du, sti).
>>> In top of that I am working on a new driver that actually needs this
>>> format, and that does not work without this patch.
>>>> -Daniel
>>>>
>>>>> ---
>>>>>    drivers/gpu/drm/drm_fourcc.c | 11 +++++++++++
>>>>>    1 file changed, 11 insertions(+)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/drm_fourcc.c 
>>>>> b/drivers/gpu/drm/drm_fourcc.c
>>>>> index 0645c85..aa8c909 100644
>>>>> --- a/drivers/gpu/drm/drm_fourcc.c
>>>>> +++ b/drivers/gpu/drm/drm_fourcc.c
>>>>> @@ -80,6 +80,17 @@ void drm_fb_get_bpp_depth(uint32_t format, 
>>>>> unsigned int *depth,
>>>>>            *depth = 8;
>>>>>            *bpp = 8;
>>>>>            break;
>>>>> +    case DRM_FORMAT_XRGB4444:
>>>>> +    case DRM_FORMAT_XBGR4444:
>>>>> +    case DRM_FORMAT_RGBX4444:
>>>>> +    case DRM_FORMAT_BGRX4444:
>>>>> +    case DRM_FORMAT_ARGB4444:
>>>>> +    case DRM_FORMAT_ABGR4444:
>>>>> +    case DRM_FORMAT_RGBA4444:
>>>>> +    case DRM_FORMAT_BGRA4444:
>>>>> +        *depth = 12;
>>>>> +        *bpp = 16;
>>>>> +        break;
>>>>>        case DRM_FORMAT_XRGB1555:
>>>>>        case DRM_FORMAT_XBGR1555:
>>>>>        case DRM_FORMAT_RGBX5551:
>>>>> -- 
>>>>> 1.9.1
>>>>>
>>>>> _______________________________________________
>>>>> dri-devel mailing list
>>>>> dri-devel@lists.freedesktop.org
>>>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
Laurent Pinchart Sept. 9, 2016, 9:09 a.m. UTC | #8
Hi Fabien,

On Friday 19 Aug 2016 11:01:37 Fabien DESSENNE wrote:
> Hi Laurent,
> 
> Daniel talked about a planned reorg from you around DRM formats (or
> something like this) and I have proposed to fix some missing parts with
> the XRGB444 formats.
> 
> Can you let us know if you can consider this fix as part of your reorg?

I don't, because it's already there :-) See "[PATCH v4 00/14] Centralize 
format information" posted to this mailing list.

The series removes the drm_fb_get_bpp_depth() function. You have several 
options:

- Use drm_format_info() to retrieve format information that include the depth 
and the number of bytes per pixel per plane.

- Use drm_format_plane_cpp() if you only need the number of bytes per pixel 
per plane.

- Check the formats directly in your driver instead of basing decisions on the 
number of bytes per pixel, as Daniel mentioned.

> If you can't what would be the best option to get this fixed?
diff mbox

Patch

diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 0645c85..aa8c909 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -80,6 +80,17 @@  void drm_fb_get_bpp_depth(uint32_t format, unsigned int *depth,
 		*depth = 8;
 		*bpp = 8;
 		break;
+	case DRM_FORMAT_XRGB4444:
+	case DRM_FORMAT_XBGR4444:
+	case DRM_FORMAT_RGBX4444:
+	case DRM_FORMAT_BGRX4444:
+	case DRM_FORMAT_ARGB4444:
+	case DRM_FORMAT_ABGR4444:
+	case DRM_FORMAT_RGBA4444:
+	case DRM_FORMAT_BGRA4444:
+		*depth = 12;
+		*bpp = 16;
+		break;
 	case DRM_FORMAT_XRGB1555:
 	case DRM_FORMAT_XBGR1555:
 	case DRM_FORMAT_RGBX5551: