From: Stefan Agner <stefan@agner.ch>
To: Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Cc: plagnioj-sclMFOaUSTBWk0Htik3J/w@public.gmane.org,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Subject: Re: [PATCH] video: mxsfb: get supply regulator optionally
Date: Tue, 06 Sep 2016 18:23:31 +0000 [thread overview]
Message-ID: <4b3a7bda2202a536efaf4a693234c273@agner.ch> (raw)
In-Reply-To: <f8368040-bb5a-91e0-7511-df462719b949-l0cyMroinI0@public.gmane.org>
On 2016-09-06 01:21, Tomi Valkeinen wrote:
> Hi,
>
> On 04/09/16 07:26, Stefan Agner wrote:
>> The lcd-supply is meant to be optional, there are several device-
>> trees not specifying it and the code handles error values silently.
>> Therefor, avoid creating a dummy regulator (and the associated
>> warning) by using devm_regulator_get_optional.
>>
>> While at it, document that fact also in the device-tree bindings.
>
> The binding change looks correct, but using
> devm_regulator_get_optional() does not sound correct.
>
> devm_regulator_get_optional() is to be used when the device in question
> truly can function without the power supply. But if the supply is there,
> it's just not controlled by the SW, devm_regulator_get() is to be used.
The framebuffer device can even function without a display, no problem
there.. Probably not really useful...
devm_regulator_get creates a dummy regulator and a warning. Afaik, the
dummy regulator was meant to be as an aid during development, but not as
a permanent solution. This is what the initial commit of the dummy
regulator says:
> In order to ease transitions with drivers are boards start using regulators
> provide an option to cause all regulator_get() calls to succeed, with a
> dummy always on regulator being supplied where one has not been configured.
> A warning is printed whenever the dummy regulator is used to aid system
> development.
I think we should either make the property mandatory and fix the device
trees or we should fix the driver to support an optional regulator. The
code already supports the reg_lcd being NULL, which is probably mostly
pointless right now as devm_regulator_get always returns a dummy
regulator.
--
Stefan
WARNING: multiple messages have this Message-ID (diff)
From: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org>
To: Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Cc: plagnioj-sclMFOaUSTBWk0Htik3J/w@public.gmane.org,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Subject: Re: [PATCH] video: mxsfb: get supply regulator optionally
Date: Tue, 06 Sep 2016 11:23:31 -0700 [thread overview]
Message-ID: <4b3a7bda2202a536efaf4a693234c273@agner.ch> (raw)
In-Reply-To: <f8368040-bb5a-91e0-7511-df462719b949-l0cyMroinI0@public.gmane.org>
On 2016-09-06 01:21, Tomi Valkeinen wrote:
> Hi,
>
> On 04/09/16 07:26, Stefan Agner wrote:
>> The lcd-supply is meant to be optional, there are several device-
>> trees not specifying it and the code handles error values silently.
>> Therefor, avoid creating a dummy regulator (and the associated
>> warning) by using devm_regulator_get_optional.
>>
>> While at it, document that fact also in the device-tree bindings.
>
> The binding change looks correct, but using
> devm_regulator_get_optional() does not sound correct.
>
> devm_regulator_get_optional() is to be used when the device in question
> truly can function without the power supply. But if the supply is there,
> it's just not controlled by the SW, devm_regulator_get() is to be used.
The framebuffer device can even function without a display, no problem
there.. Probably not really useful...
devm_regulator_get creates a dummy regulator and a warning. Afaik, the
dummy regulator was meant to be as an aid during development, but not as
a permanent solution. This is what the initial commit of the dummy
regulator says:
> In order to ease transitions with drivers are boards start using regulators
> provide an option to cause all regulator_get() calls to succeed, with a
> dummy always on regulator being supplied where one has not been configured.
> A warning is printed whenever the dummy regulator is used to aid system
> development.
I think we should either make the property mandatory and fix the device
trees or we should fix the driver to support an optional regulator. The
code already supports the reg_lcd being NULL, which is probably mostly
pointless right now as devm_regulator_get always returns a dummy
regulator.
--
Stefan
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Stefan Agner <stefan@agner.ch>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: plagnioj@jcrosoft.com, robh+dt@kernel.org, mark.rutland@arm.com,
devicetree@vger.kernel.org, linux-fbdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Mark Brown <broonie@kernel.org>
Subject: Re: [PATCH] video: mxsfb: get supply regulator optionally
Date: Tue, 06 Sep 2016 11:23:31 -0700 [thread overview]
Message-ID: <4b3a7bda2202a536efaf4a693234c273@agner.ch> (raw)
In-Reply-To: <f8368040-bb5a-91e0-7511-df462719b949@ti.com>
On 2016-09-06 01:21, Tomi Valkeinen wrote:
> Hi,
>
> On 04/09/16 07:26, Stefan Agner wrote:
>> The lcd-supply is meant to be optional, there are several device-
>> trees not specifying it and the code handles error values silently.
>> Therefor, avoid creating a dummy regulator (and the associated
>> warning) by using devm_regulator_get_optional.
>>
>> While at it, document that fact also in the device-tree bindings.
>
> The binding change looks correct, but using
> devm_regulator_get_optional() does not sound correct.
>
> devm_regulator_get_optional() is to be used when the device in question
> truly can function without the power supply. But if the supply is there,
> it's just not controlled by the SW, devm_regulator_get() is to be used.
The framebuffer device can even function without a display, no problem
there.. Probably not really useful...
devm_regulator_get creates a dummy regulator and a warning. Afaik, the
dummy regulator was meant to be as an aid during development, but not as
a permanent solution. This is what the initial commit of the dummy
regulator says:
> In order to ease transitions with drivers are boards start using regulators
> provide an option to cause all regulator_get() calls to succeed, with a
> dummy always on regulator being supplied where one has not been configured.
> A warning is printed whenever the dummy regulator is used to aid system
> development.
I think we should either make the property mandatory and fix the device
trees or we should fix the driver to support an optional regulator. The
code already supports the reg_lcd being NULL, which is probably mostly
pointless right now as devm_regulator_get always returns a dummy
regulator.
--
Stefan
next prev parent reply other threads:[~2016-09-06 18:23 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-04 4:26 [PATCH] video: mxsfb: get supply regulator optionally Stefan Agner
2016-09-04 4:26 ` Stefan Agner
2016-09-04 4:26 ` Stefan Agner
2016-09-06 8:21 ` Tomi Valkeinen
2016-09-06 8:21 ` Tomi Valkeinen
2016-09-06 8:21 ` Tomi Valkeinen
[not found] ` <f8368040-bb5a-91e0-7511-df462719b949-l0cyMroinI0@public.gmane.org>
2016-09-06 18:23 ` Stefan Agner [this message]
2016-09-06 18:23 ` Stefan Agner
2016-09-06 18:23 ` Stefan Agner
2016-09-06 22:22 ` Mark Brown
2016-09-06 22:22 ` Mark Brown
[not found] ` <4b3a7bda2202a536efaf4a693234c273-XLVq0VzYD2Y@public.gmane.org>
2016-09-07 7:20 ` Tomi Valkeinen
2016-09-07 7:20 ` Tomi Valkeinen
2016-09-07 7:20 ` Tomi Valkeinen
[not found] ` <1812b2bf-bd66-3553-4c2d-3d2b08603ca0-l0cyMroinI0@public.gmane.org>
2016-09-12 23:47 ` Mark Brown
2016-09-12 23:47 ` Mark Brown
2016-09-12 23:47 ` Mark Brown
2016-11-09 0:16 ` Stefan Agner
2016-11-09 0:16 ` Stefan Agner
2016-11-09 0:16 ` Stefan Agner
[not found] ` <20160904042627.30182-1-stefan-XLVq0VzYD2Y@public.gmane.org>
2016-09-12 15:47 ` Rob Herring
2016-09-12 15:47 ` Rob Herring
2016-09-12 15:47 ` Rob Herring
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=4b3a7bda2202a536efaf4a693234c273@agner.ch \
--to=stefan@agner.ch \
--cc=broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \
--cc=plagnioj-sclMFOaUSTBWk0Htik3J/w@public.gmane.org \
--cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=tomi.valkeinen-l0cyMroinI0@public.gmane.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.