linux-kernel - Re: [PATCH v6 3/6] drm: Add driver for Solomon SSD130x OLED displays

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 1 Jun 2022 19:58:18 +0300
From:   "andriy.shevchenko@...ux.intel.com" 
        <andriy.shevchenko@...ux.intel.com>
To:     Javier Martinez Canillas <javierm@...hat.com>
Cc:     Dominik Kierner <dkierner@...electronics.com>,
        "airlied@...ux.ie" <airlied@...ux.ie>,
        "daniel.vetter@...ll.ch" <daniel.vetter@...ll.ch>,
        "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
        "geert@...ux-m68k.org" <geert@...ux-m68k.org>,
        "lee.jones@...aro.org" <lee.jones@...aro.org>,
        "linux-fbdev@...r.kernel.org" <linux-fbdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-pwm@...r.kernel.org" <linux-pwm@...r.kernel.org>,
        "maxime@...no.tech" <maxime@...no.tech>,
        "noralf@...nnes.org" <noralf@...nnes.org>,
        "sam@...nborg.org" <sam@...nborg.org>,
        "thierry.reding@...il.com" <thierry.reding@...il.com>,
        "tzimmermann@...e.de" <tzimmermann@...e.de>,
        "u.kleine-koenig@...gutronix.de" <u.kleine-koenig@...gutronix.de>
Subject: Re: [PATCH v6 3/6] drm: Add driver for Solomon SSD130x OLED displays

On Wed, May 25, 2022 at 09:46:24PM +0200, Javier Martinez Canillas wrote:
> On 3/10/22 14:11, Dominik Kierner wrote:

...

> > # DRM Mode Configuration via Device Tree
> > 
> > In the old fbdev driver, the display modes are hard-coded, which means
> > for every new display configuration, a new patch needs to be mainlined,
> > which slows down official Kernel support and
> > puts burden on the maintainers.
> > Additionally, with the DRM-subsystem supporting height and length
> > information, for scaling, this opens up a lot of new combinations.
> > The SSD1306 for example, is available in multiple resolutions like
> > 128x64 and 96x16 and comes in different sizes per resolution as well.
> > Just to name a few:
> > * 128x64 0.96" (22x11mm)
> > * 128x64 1.3" (30x15mm)
> > * 96x16 0.69" (18x3mm)
> >> Instead of hard-coding, I would suggest something along the lines of
> > of_get_drm_display_mode().
> > The displays won't need to support multiple modes at the same time,
> > let alone support for switching between them,
> > so the one-time invocation of this expensive function might be worth it. 
> > maybe a new and simpler function that could be named:
> > of_get_drm_display_mode_simple()
> 
> This makes sense to me as well.

What about non-OF platforms? Please, do not spread OF-only interfaces,
and use fwnode instead.

> > Providing a mode could later prove useful for a conversion to
> > drm_panel, if that is feasible.
> > 
> > But for a function like this, I have to chicken out.

-- 
With Best Regards,
Andy Shevchenko