linux-kernel - Re: [PATCH v1 1/6] DT bindings: add bindings for ov965x camera module

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] [thread-next>] [day] [month] [year] [list]
Message-Id: <9D51AC4C-6CB7-46A5-B363-2AD6DA6C497F@goldelico.com>
Date:   Wed, 28 Jun 2017 13:24:57 +0200
From:   "H. Nikolaus Schaller" <hns@...delico.com>
To:     Sylwester Nawrocki <s.nawrocki@...sung.com>
Cc:     Hugues FRUCHET <hugues.fruchet@...com>,
        Guennadi Liakhovetski <g.liakhovetski@....de>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Maxime Coquelin <mcoquelin.stm32@...il.com>,
        Alexandre TORGUE <alexandre.torgue@...com>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Hans Verkuil <hverkuil@...all.nl>,
        devicetree <devicetree@...r.kernel.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        LKML <linux-kernel@...r.kernel.org>,
        "linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
        Benjamin Gaignard <benjamin.gaignard@...aro.org>,
        Yannick FERTRE <yannick.fertre@...com>,
        Discussions about the Letux Kernel 
        <letux-kernel@...nphoenux.org>
Subject: Re: [PATCH v1 1/6] DT bindings: add bindings for ov965x camera module


> Am 28.06.2017 um 12:50 schrieb Sylwester Nawrocki <s.nawrocki@...sung.com>:
> 
> On 06/28/2017 11:12 AM, H. Nikolaus Schaller wrote:
>>> Am 28.06.2017 um 00:57 schrieb Sylwester Nawrocki <snawrocki@...nel.org>:
>>> On 06/27/2017 07:48 AM, H. Nikolaus Schaller wrote:
>>>>> Am 26.06.2017 um 22:04 schrieb Sylwester Nawrocki <snawrocki@...nel.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.

Fine! I have sent some patches to Hughues so that he can integrate it in
his next version of the patch series.

BR and thanks,
Nikolaus