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>] [day] [month] [year] [list]

Message-ID: <4dfc32123d1d4e38ae1afdd3f33109a9@dh-electronics.com>
Date:   Tue, 14 Jun 2022 14:05:36 +0000
From:   Dominik Kierner <dkierner@...electronics.com>
To:     Javier Martinez Canillas <javierm@...hat.com>
CC:     "airlied@...ux.ie" <airlied@...ux.ie>,
        "andriy.shevchenko@...ux.intel.com" 
        <andriy.shevchenko@...ux.intel.com>,
        "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

Hello Javier

On 6/14/22 13:39, Javier Martinez Canillas wrote:

> > I always understood regulator_get_optional() as a way of not having to rely on a dummy,
> > when a regulator is not present, but please correct me, if I am wrong on this.
> > The dummies would only be necessary for the mandatory supplies VCC and VDD.
> >
> 
> Yes, that's what I tried to say. That's regulator_get() and not _optional()
> the function that will provide a dummy regulator if isn't physically present:
> 
> https://elixir.bootlin.com/linux/latest/source/drivers/regulator/core.c#L2067
> 
> > You mean this part of the documentation of regulator_get_optional(), correct?:
> >
> >> * This is intended for use by consumers for devices which can have
> >> * some supplies unconnected in normal use, such as some MMC devices.
> >> * It can allow the regulator core to provide stub supplies for other
> >> * supplies requested using normal regulator_get() calls without
> >> * disrupting the operation of drivers that can handle absent
> >> * supplies.
> >
> >
> So for example when you just use a voltage rail in let's say a board pin header
> then you will need to define supply nodes with compatible = "regulator-
> fixed" ?

Exactly.

> That is indeed more accurate from a hardware description point of view but I'm
> not convinced that this is something worth to break DT backward compatibility.

> You also mentioned (IIUC) that the regulators could be made optional and their
> presence be used as an indication that an atomic charge pump configuration can
> be made instead of using the current ssd130x->display_settings.use_charge_pump.
> 
> I think that would prefer that the latter option, but will let others to chime
> in since maybe I'm not correct on the preferred approach.

Yes, here the reference for the former approach:
Chapter 2 "Charge Pump Regulator" on Page 62 of the SSD1306 datasheet:
https://cdn-shop.adafruit.com/datasheets/SSD1306.pdf

Just a TL;DR of the former approach for easier discussion:
The logic supply VDD would always be mandatory.
The low voltage supply VBAT would be optional and probed first.
If found, it would supersede the "high" voltage driving supply VCC and
the charge pump would be enabled. If VBAT is not found, then VCC is
mandatory and the charge pump will not be enabled.


--
Best regards

Dominik Kierner
Research & Development
DH electronics