On 06/28/2017 01:24 PM, H. Nikolaus Schaller wrote: > >> Am 28.06.2017 um 12:50 schrieb Sylwester Nawrocki <s.nawrocki@xxxxxxxxxxx>: >> >> On 06/28/2017 11:12 AM, H. Nikolaus Schaller wrote: >>>> Am 28.06.2017 um 00:57 schrieb Sylwester Nawrocki <snawrocki@xxxxxxxxxx>: >>>> On 06/27/2017 07:48 AM, H. Nikolaus Schaller wrote: >>>>>> Am 26.06.2017 um 22:04 schrieb Sylwester Nawrocki <snawrocki@xxxxxxxxxx>: >>>>>> 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 > OK got it, I'll push in v2.
