From: Sylwester Nawrocki <s.nawrocki@samsung.com>
To: "H. Nikolaus Schaller" <hns@goldelico.com>
Cc: Hugues FRUCHET <hugues.fruchet@st.com>,
Guennadi Liakhovetski <g.liakhovetski@gmx.de>,
Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Maxime Coquelin <mcoquelin.stm32@gmail.com>,
Alexandre TORGUE <alexandre.torgue@st.com>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Hans Verkuil <hverkuil@xs4all.nl>,
devicetree <devicetree@vger.kernel.org>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
LKML <linux-kernel@vger.kernel.org>,
"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
Benjamin Gaignard <benjamin.gaignard@linaro.org>,
Yannick FERTRE <yannick.fertre@st.com>,
Discussions about the Letux Kernel
<letux-kernel@openphoenux.org>
Subject: Re: [PATCH v1 1/6] DT bindings: add bindings for ov965x camera module
Date: Wed, 28 Jun 2017 12:50:39 +0200 [thread overview]
Message-ID: <5bcc7ec0-4ae5-3703-3cee-ed644eef710a@samsung.com> (raw)
In-Reply-To: <6F68CD33-70E6-47C1-9E89-5E2AA776879F@goldelico.com>
On 06/28/2017 11:12 AM, H. Nikolaus Schaller wrote:
>> Am 28.06.2017 um 00:57 schrieb Sylwester Nawrocki <snawrocki@kernel.org>:
>> On 06/27/2017 07:48 AM, H. Nikolaus Schaller wrote:
>>>> Am 26.06.2017 um 22:04 schrieb Sylwester Nawrocki <snawrocki@kernel.org>:
>>>> On 06/26/2017 12:35 PM, Hugues FRUCHET wrote:
>>>>>> What I am missing to support the GTA04 camera is the control of the optional "vana-supply".
>>>>>> So the driver does not power up the camera module when needed and therefore probing fails.
>>>>>>
>>>>>> - vana-supply: a regulator to power up the camera module.
>>>>>>
>>>>>> Driver code is not complex to add:
>>>>
>>>>> Yes, I saw it in your code, but as I don't have any programmable power
>>>>> supply on my setup, I have not pushed this commit.
>>>>
>>>> Since you are about to add voltage supplies to the DT binding I'd suggest
>>>> to include all three voltage supplies of the sensor chip. Looking at the OV9650
>>>> and the OV9655 datasheet there are following names used for the voltage supply
>>>> pins:
>>>>
>>>> AVDD - Analog power supply,
>>>> DVDD - Power supply for digital core logic,
>>>> DOVDD - Digital power supply for I/O.
>>>
>>> The latter two are usually not independently switchable from the SoC power
>>> the module is connected to.
>>>
>>> And sometimes DVDD and DOVDD are connected together.
>>>
>>> So the driver can't make much use of knowing or requesting them because the
>>> 1.8V supply is always active, even during suspend.
>>>
>>>>
>>>> I doubt the sensor can work without any of these voltage supplies, thus
>>>> regulator_get_optional() should not be used. I would just use the regulator
>>>> bulk API to handle all three power supplies.
>>>
>>> The digital part works with AVDD turned off. So the LDO supplying AVDD should
>>> be switchable to save power (&vaux3 on the GTA04 device).>
>>> But not all designs can switch it off. Hence the idea to define it as an
>>> /optional/ regulator. If it is not defined by DT, the driver simply assumes
>>> it is always powered on.
>>
>> I didn't say we can't define regulator supply properties as optional in the DT
>> binding. If we define them as such and any of these *-supply properties is
>> missing in DT with regulator_get() the regulator core will use dummy regulator
>> for that particular voltage supply. While with regulator_get_optional()
>> -ENODEV is returned when the regulator cannot be found.
>
> Ah, ok. I see.
>
> I had thought that it is the right thing to do like devm_gpiod_get_optional().
>
> That one it is described as:
>
> "* This is equivalent to gpiod_get(), except that when no GPIO was assigned to
> * the requested function it will return NULL. This is convenient for drivers
> * that need to handle optional GPIOs."
>
> Seems to be inconsistent definition of what "optional" means.
Indeed, this commit explains it further:
commit de1dd9fd2156874b45803299b3b27e65d5defdd9
regulator: core: Provide hints to the core about optional supplies
> So we indeed should use devm_regulator_get() in this case. Thanks for > pointing out!
>>> So in summary we only need AVDD switched for the GTA04 - but it does not
>>> matter if the others are optional properties. We would not use them.
>>>
>>> It does matter if they are mandatory because it adds DT complexity (size
>>> and processing) without added function.
>>
>> We should not be defining DT binding only with selected use cases/board
>> designs in mind. IMO all three voltage supplies should be listed in the
>> binding, presumably all can be made optional, with an assumption that when
>> the property is missing selected pin is hooked up to a fixed regulator.
>
> Ok, then it should just be defined in the bindings but not used by
> the driver?
Yes, I think so. So we have a possibly complete binding right from the
beginning. I someone needs handling other supplies than AVDD they could
update the driver in future.
Regards,
Sylwester
next prev parent reply other threads:[~2017-06-28 10:50 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-22 15:05 [PATCH v1 0/6] Add support of OV9655 camera Hugues Fruchet
2017-06-22 15:05 ` [PATCH v1 1/6] DT bindings: add bindings for ov965x camera module Hugues Fruchet
2017-06-23 10:25 ` H. Nikolaus Schaller
2017-06-23 10:46 ` Andreas Färber
2017-06-23 10:59 ` H. Nikolaus Schaller
2017-06-23 11:58 ` Laurent Pinchart
2017-06-23 14:53 ` H. Nikolaus Schaller
2017-06-23 14:57 ` Andreas Färber
2017-06-23 15:22 ` H. Nikolaus Schaller
2017-06-23 18:05 ` Suman Anna
2017-06-23 18:59 ` H. Nikolaus Schaller
2017-06-23 22:24 ` Suman Anna
2017-06-26 6:00 ` H. Nikolaus Schaller
2017-06-26 10:35 ` Hugues FRUCHET
2017-06-26 20:04 ` Sylwester Nawrocki
2017-06-27 5:48 ` H. Nikolaus Schaller
2017-06-27 22:57 ` Sylwester Nawrocki
2017-06-28 9:12 ` H. Nikolaus Schaller
2017-06-28 10:50 ` Sylwester Nawrocki [this message]
2017-06-28 11:24 ` H. Nikolaus Schaller
2017-06-28 12:28 ` Hugues FRUCHET
2017-06-26 18:56 ` Rob Herring
2017-06-26 18:54 ` Rob Herring
2017-06-22 15:05 ` [PATCH v1 2/6] [media] ov9650: add device tree support Hugues Fruchet
2017-06-26 16:31 ` Sakari Ailus
2017-06-26 17:46 ` H. Nikolaus Schaller
2017-06-27 5:36 ` Sakari Ailus
2017-06-27 10:14 ` Hugues FRUCHET
2017-06-22 15:05 ` [PATCH v1 3/6] [media] ov9650: select the nearest higher resolution Hugues Fruchet
2017-06-22 15:05 ` [PATCH v1 4/6] [media] ov9650: use write_array() for resolution sequences Hugues Fruchet
2017-06-26 16:33 ` Sakari Ailus
2017-06-29 13:59 ` Hugues FRUCHET
2017-06-22 15:05 ` [PATCH v1 5/6] [media] ov9650: add multiple variant support Hugues Fruchet
2017-06-25 12:36 ` kbuild test robot
2017-06-22 15:05 ` [PATCH v1 6/6] [media] ov9650: add support of OV9655 variant Hugues Fruchet
2017-06-25 16:07 ` kbuild test robot
2017-06-25 16:07 ` [PATCH] ov9650: fix semicolon.cocci warnings kbuild test robot
2017-06-26 6:03 ` [PATCH v1 6/6] [media] ov9650: add support of OV9655 variant H. Nikolaus Schaller
2017-06-26 11:49 ` Hugues FRUCHET
2017-06-22 15:41 ` [PATCH v1 0/6] Add support of OV9655 camera H. Nikolaus Schaller
2017-06-23 10:25 ` H. Nikolaus Schaller
2017-06-25 9:18 ` omap3isp camera was " Pavel Machek
2017-06-26 6:05 ` H. Nikolaus Schaller
2017-06-26 8:39 ` Pavel Machek
2017-06-26 9:53 ` H. Nikolaus Schaller
2017-06-26 11:16 ` Pavel Machek
2017-06-27 5:49 ` H. Nikolaus Schaller
2017-06-26 13:19 ` Hugues FRUCHET
[not found] ` <E4E1E683-9CD0-4F23-AB03-080C52D0D73B@goldelico.com>
2017-06-27 7:57 ` Hugues FRUCHET
[not found] ` <95B10899-9966-4844-9667-D2434968A492@goldelico.com>
[not found] ` <85e62c47-e319-c801-376c-95f4d9cbf75a@st.com>
[not found] ` <E183E921-B8F4-4F8A-A302-58297A874990@goldelico.com>
[not found] ` <77bd3b8fe52643d68ecc821ec22bc0e6@SFHDAG5NODE1.st.com>
2017-07-01 21:00 ` H. Nikolaus Schaller
2017-07-03 8:16 ` Hugues FRUCHET
2017-07-03 9:14 ` H. Nikolaus Schaller
2017-07-03 12:03 ` Hugues FRUCHET
2017-07-03 12:23 ` H. Nikolaus Schaller
2017-07-05 14:02 ` H. Nikolaus Schaller
2017-07-08 20:55 ` Sakari Ailus
2017-06-26 6:02 ` H. Nikolaus Schaller
2017-06-26 10:05 ` Hugues FRUCHET
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=5bcc7ec0-4ae5-3703-3cee-ed644eef710a@samsung.com \
--to=s.nawrocki@samsung.com \
--cc=alexandre.torgue@st.com \
--cc=benjamin.gaignard@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=g.liakhovetski@gmx.de \
--cc=hns@goldelico.com \
--cc=hugues.fruchet@st.com \
--cc=hverkuil@xs4all.nl \
--cc=letux-kernel@openphoenux.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mchehab@kernel.org \
--cc=mcoquelin.stm32@gmail.com \
--cc=robh+dt@kernel.org \
--cc=yannick.fertre@st.com \
/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
all inboxes | Powered by JetHome®