Hi Daniel Am 11.08.22 um 19:23 schrieb Daniel Vetter: > On Wed, 27 Jul 2022 at 09:53, Thomas Zimmermann 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 wrote: >>>>> Compute the framebuffer's scanline stride length if not given by >>>>> the simplefb data. >>>>> >>>>> Signed-off-by: Thomas Zimmermann >>>> >>>> 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. 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 >>> >> >> -- >> 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