> 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. 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? BR and thanks, Nikolaus -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
