[PATCH v2 04/10] drm/simpledrm: Compute framebuffer stride if not set

Thomas Zimmermann tzimmermann at suse.de
Fri Aug 12 04:27:42 AEST 2022



Am 11.08.22 um 20:26 schrieb Thomas Zimmermann:
> Hi Daniel
> 
> Am 11.08.22 um 19:23 schrieb Daniel Vetter:
>> On Wed, 27 Jul 2022 at 09:53, Thomas Zimmermann <tzimmermann at suse.de> 
>> wrote:
>>>
>>> Hi
>>>
>>> Am 25.07.22 um 17:13 schrieb Javier Martinez Canillas:
>>>> Hello Geert,
>>>>
>>>> On 7/21/22 16:46, Geert Uytterhoeven wrote:
>>>>> Hi Thomas,
>>>>>
>>>>> On Wed, Jul 20, 2022 at 4:27 PM Thomas Zimmermann 
>>>>> <tzimmermann at suse.de> wrote:
>>>>>> Compute the framebuffer's scanline stride length if not given by
>>>>>> the simplefb data.
>>>>>>
>>>>>> Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de>
>>>>>
>>>>> Thanks for your patch!
>>>>>
>>>>>> --- a/drivers/gpu/drm/tiny/simpledrm.c
>>>>>> +++ b/drivers/gpu/drm/tiny/simpledrm.c
>>>>>> @@ -743,6 +743,9 @@ static struct simpledrm_device 
>>>>>> *simpledrm_device_create(struct drm_driver *drv,
>>>>>>                   drm_err(dev, "no simplefb configuration found\n");
>>>>>>                   return ERR_PTR(-ENODEV);
>>>>>>           }
>>>>>> +       if (!stride)
>>>>>> +               stride = format->cpp[0] * width;
>>>>>
>>>>> DIV_ROUND_UP(drm_format_info_bpp(format) * width, 8)
>>>>>
>>>>
>>>> I think you meant here:
>>>>
>>>> DIV_ROUND_UP(drm_format_info_bpp(format, 0) * width, 8) ?
>>>
>>> I guess, that's the right function. My original code is correct, but cpp
>>> is also deprecated.
>>
>> You all mean drm_format_info_min_pitch().
> 
> Thanks a lot. I wasn't even aware of this function, but I had almost 
> written my own implementation of it.  I'll update the patch accordingly.

Arghh, too late. I merged that patch already.

> 
> Best regards
> Thomas
> 
>>
>> I really don't want drivers to go grab any of the legacy format info
>> fields like bpp or depth. switch() statements on the fourcc code for
>> programming registers, or one of the real helper functions in
>> drm_fourcc.c (there might be some gaps), but not ever going through
>> legacy concepts. Anything else just leads to subtle bugs when new
>> formats get added and oops suddenly the assumptions don't hold.
>>
>> Those should be strictly limited to legacy (i.e. not drm_fourcc aware)
>> interfaces. Heck I think even fbdev emulation should completely switch
>> over to drm_fourcc/drm_format_info, but alas that's a pile of work and
>> not much payoff.
>>
>> I'm trying to volunteer Same to add a legacy_bpp tag to the above
>> helper and appropriately limit it, I think limiting to formats with
>> depth!=0 is probably the right thing. And then we should probably
>> remove a pile of the cargo-culted depth!=0 entries too.
>> -Daniel
>>
>>>
>>> Best regards
>>> Thomas
>>>
>>>>
>>>> With that change,
>>>>
>>>> Acked-by: Javier Martinez Canillas <javierm at redhat.com>
>>>>
>>>
>>> -- 
>>> Thomas Zimmermann
>>> Graphics Driver Developer
>>> SUSE Software Solutions Germany GmbH
>>> Maxfeldstr. 5, 90409 Nürnberg, Germany
>>> (HRB 36809, AG Nürnberg)
>>> Geschäftsführer: Ivo Totev
>>
>>
>>
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20220811/e29ff883/attachment-0001.sig>


More information about the Linuxppc-dev mailing list