From: Dominik Kierner <dkierner@dh-electronics.com>
To: Javier Martinez Canillas <javierm@redhat.com>
Cc: "airlied@linux.ie" <airlied@linux.ie>,
"andriy.shevchenko@linux.intel.com"
<andriy.shevchenko@linux.intel.com>,
"daniel.vetter@ffwll.ch" <daniel.vetter@ffwll.ch>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"geert@linux-m68k.org" <geert@linux-m68k.org>,
"lee.jones@linaro.org" <lee.jones@linaro.org>,
"linux-fbdev@vger.kernel.org" <linux-fbdev@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-pwm@vger.kernel.org" <linux-pwm@vger.kernel.org>,
"maxime@cerno.tech" <maxime@cerno.tech>,
"noralf@tronnes.org" <noralf@tronnes.org>,
"sam@ravnborg.org" <sam@ravnborg.org>,
"thierry.reding@gmail.com" <thierry.reding@gmail.com>,
"tzimmermann@suse.de" <tzimmermann@suse.de>,
"u.kleine-koenig@pengutronix.de" <u.kleine-koenig@pengutronix.de>
Subject: Re: [PATCH v6 3/6] drm: Add driver for Solomon SSD130x OLED displays
Date: Tue, 14 Jun 2022 14:05:36 +0000 [thread overview]
Message-ID: <4dfc32123d1d4e38ae1afdd3f33109a9@dh-electronics.com> (raw)
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
next reply other threads:[~2022-06-14 14:16 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-14 14:05 Dominik Kierner [this message]
-- strict thread matches above, loose matches on Subject: below --
2022-06-13 11:39 [PATCH v6 3/6] drm: Add driver for Solomon SSD130x OLED displays Dominik Kierner
2022-06-13 15:35 ` andriy.shevchenko
2022-06-13 17:41 ` Javier Martinez Canillas
2022-06-13 18:17 ` Javier Martinez Canillas
2022-03-10 13:11 Dominik Kierner
2022-05-25 19:46 ` Javier Martinez Canillas
2022-06-01 16:58 ` andriy.shevchenko
2022-02-14 13:37 [PATCH v6 0/6] " Javier Martinez Canillas
2022-02-14 13:37 ` [PATCH v6 3/6] " Javier Martinez Canillas
2022-02-16 9:16 ` Maxime Ripard
2022-03-08 16:30 ` Geert Uytterhoeven
2022-03-09 12:14 ` Javier Martinez Canillas
2022-03-09 12:56 ` Geert Uytterhoeven
2022-03-09 13:43 ` Javier Martinez Canillas
2022-03-09 20:04 ` Geert Uytterhoeven
2022-03-09 20:13 ` Javier Martinez Canillas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4dfc32123d1d4e38ae1afdd3f33109a9@dh-electronics.com \
--to=dkierner@dh-electronics.com \
--cc=airlied@linux.ie \
--cc=andriy.shevchenko@linux.intel.com \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=geert@linux-m68k.org \
--cc=javierm@redhat.com \
--cc=lee.jones@linaro.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pwm@vger.kernel.org \
--cc=maxime@cerno.tech \
--cc=noralf@tronnes.org \
--cc=sam@ravnborg.org \
--cc=thierry.reding@gmail.com \
--cc=tzimmermann@suse.de \
--cc=u.kleine-koenig@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).