From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751536AbdF1Kuz (ORCPT ); Wed, 28 Jun 2017 06:50:55 -0400 Received: from mailout1.samsung.com ([203.254.224.24]:45492 "EHLO mailout1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751234AbdF1Kuu (ORCPT ); Wed, 28 Jun 2017 06:50:50 -0400 X-AuditID: b6c32a2c-f79e76d00000129c-c1-59538a07356f Subject: Re: [PATCH v1 1/6] DT bindings: add bindings for ov965x camera module To: "H. Nikolaus Schaller" Cc: Hugues FRUCHET , Guennadi Liakhovetski , Rob Herring , Mark Rutland , Maxime Coquelin , Alexandre TORGUE , Mauro Carvalho Chehab , Hans Verkuil , devicetree , linux-arm-kernel , LKML , "linux-media@vger.kernel.org" , Benjamin Gaignard , Yannick FERTRE , Discussions about the Letux Kernel From: Sylwester Nawrocki Message-id: <5bcc7ec0-4ae5-3703-3cee-ed644eef710a@samsung.com> Date: Wed, 28 Jun 2017 12:50:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-version: 1.0 In-reply-to: <6F68CD33-70E6-47C1-9E89-5E2AA776879F@goldelico.com> Content-type: text/plain; charset="utf-8" Content-language: en-GB Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA02SfUzMcRzHfe9+T8XZ15X6KMrOQ7RExvbdWLJZ+zWbtWUTf6Tf+DlNT+5X En/IQ05x5KytbuSmpG5ncik9CDtRu4S0niwlqsUQ8nBNobtftv57fd+f9+f7+b4/+3JK9Rjt xyUkp4m6ZCFRw3hS1Y9WBq1ic2N2rim/AOT2YAsiJ+wOhlxtfEaT0dtFCuKs/qEgpc7vNHFc GlaQqomXDLG966RJe91lhpyrqKLJ9a62KYttQkGKJm/SJLuhkSX6nGwmAvPWIivia02vWf7L 1zjeOupQ8jZLDsP3dt5j+MqSY/wpYx3LDzkblPyYLYB3/Bhjo2fv8ty4V0xMOCTqVofHe+4v uT9Cpz4IPDzQdJLJQuYFuciDA7wOLL+vMjL7wIu+W1PsyanxdQQ/TxtZV0GNxxDkFQT8b7jf XcrKppsIuttMSDb1I8gyBrrYC0fD+7vjbt0bh0LOrwnK1aDEDTQ8Hy5zFxgcBobH592swuHQ ZrTQuYjjKLwMKkeDXPJ8HAvXjBdZ2TIPnJf6KBd74M3waviNu1WJV8LIdyMlsy886e+Z1gOh 0vpJKT86n4PO2t2u6wEvAtvDaXkLvB0qQTJ7wYemO6zMfnD2jMmdEfAFBM3Wk0g+FCDo1ecp ZNcGeNTURsvD5oLh96BCHqCCM6fVsoWHxvefp7e7GT5/6ZjerpGCG/ZiNg8tNs3IZpqRxzQj j2lGHjOiLMhHTJWStKK0PjUsVBKSpPRkbeielCQbcn/F4JAa1GfeakeYQ5o5qjLvmJ1qWjgk ZSbZEXBKjbeqQj8lqfYKmUdEXcpuXXqiKNmRP0dpfFUryjtj1VgrpIkHRDFV1P2vKjgPvyw0 a7wrviwi3y8yxtBMbY/YdbQ2o6K1IzI6yFdruNK/RN9VG2c0B6yr6flbnrFh8F3dcr1uqX/v 8QUDT5c8+CBsM4zei0r4k38x6vLB1mKvycKRgaZ9m9C3h2uLW4SvhTuk7KrG9hDimN31EcIH 4tImA82h1+o2kYU5d5z1jnqLNkNDSfuFsGClThL+AWly72mGAwAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnleLIzCtJLcpLzFFi42I5/e+xoC57V3CkwaEuLouNT04zWjQdOsVm Mf/IOVaL9xvnMVn82PaVyWLZjy+sFqcmP2Oy2PrnEpvFpsfXWC0u75rDZtGzYSurxdLrF4FK Nv1hspj3dy2rReveI+wW7Z2tbA4CHmvmrWH02DnrLrvHh49xHmven2L22LSqk83jzrU9bB6b l9R7tEzaxe7x9MdeZo/Pm+Q8Tn39zB7AHeVmk5GamJJapJCal5yfkpmXbqsUGuKma6GkkJeY m2qrFKHrGxKkpFCWmFMK5BkZoAEH5wD3YCV9uwS3jCX7XrAW7JeveHi8ma2BcYFkFyMnh4SA icS+G8vYIWwxiQv31rN1MXJxCAmsZpS4tGErO4TzkFGiff8XVpAqYQE/iTmTDjGD2CICehKd 3/+wgBQxCxxklZg9eTojRMckFokvR/8yglSxCRhK9B7tA7N5BewkLk5aBTSJg4NFQFVi83t1 kLCoQITErusHWCFKBCV+TL7HAmJzCjhK3Hr2gBGknFlAXWLKlFyQMLOAuMSx+zcZIWx5ic1r 3jJPYBSchaR7FkLHLCQds5B0LGBkWcXIlVpQnJueW2xUYLSJEZgIth3WCtjB2HQu+hCjAAej Eg9vQWVwpBBrYllxZe4hRgkOZiUR3g3tQCHelMTKqtSi/Pii0pzU4kOMpkD/TGSWEk3OByap vJJ4QxNLIxMDMzNDIwNjMyVx3gmBXyKEBNITS1KzU1MLUotg+pg4OKUaGA1Wsl3fsORxAWOZ VvPPl5U8GQEl/Vud+DeeDTG0UKraeUTd4LbCpF8FvlPuNXk5PZ6+Z8lKH53mgh6l5Vc4vk4P NuA1/HPROfsa9xzv7y+d7jSrbz1V/WvtR5P3ixLs+dJ+LWj7enK946uDU/zDIpesPMOi4WLB 1yARYm6kcqtljfWjS/oWLkosxRmJhlrMRcWJABlqHjMaAwAA X-MTR: 20000000000000000@CPGS X-CMS-MailID: 20170628105047epcas5p4bcc2701d245816ff288f7a99a7d6f2bf X-Msg-Generator: CA X-Sender-IP: 182.195.42.80 X-Local-Sender: =?UTF-8?B?U3lsd2VzdGVyIE5hd3JvY2tpG1NSUE9MLUtlcm5lbCAoVFAp?= =?UTF-8?B?G+yCvOyEseyghOyekBtTZW5pb3IgU29mdHdhcmUgRW5naW5lZXI=?= X-Global-Sender: =?UTF-8?B?U3lsd2VzdGVyIE5hd3JvY2tpG1NSUE9MLUtlcm5lbCAoVFAp?= =?UTF-8?B?G1NhbXN1bmcgRWxlY3Ryb25pY3MbU2VuaW9yIFNvZnR3YXJlIEVuZ2luZWVy?= X-Sender-Code: =?UTF-8?B?QzEwG0VIURtDMTBDRDAyQ0QwMjczOTI=?= CMS-TYPE: 105P X-CMS-RootMailID: 20170628091334epcas5p2071ae52aa3f9312b1099e37ffac20eb1 X-RootMTR: 20170628091334epcas5p2071ae52aa3f9312b1099e37ffac20eb1 References: <1498143942-12682-1-git-send-email-hugues.fruchet@st.com> <1498143942-12682-2-git-send-email-hugues.fruchet@st.com> <64e3005d-31df-71f2-762b-2c1b1152fc2d@st.com> <5cd25a47-f3be-8c40-3940-29f26a245076@kernel.org> <39501C78-7B81-4803-94C1-25DFA06EA526@goldelico.com> <6F68CD33-70E6-47C1-9E89-5E2AA776879F@goldelico.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/28/2017 11:12 AM, H. Nikolaus Schaller wrote: >> Am 28.06.2017 um 00:57 schrieb Sylwester Nawrocki : >> On 06/27/2017 07:48 AM, H. Nikolaus Schaller wrote: >>>> Am 26.06.2017 um 22:04 schrieb Sylwester Nawrocki : >>>> 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sylwester Nawrocki Subject: Re: [PATCH v1 1/6] DT bindings: add bindings for ov965x camera module Date: Wed, 28 Jun 2017 12:50:39 +0200 Message-ID: <5bcc7ec0-4ae5-3703-3cee-ed644eef710a@samsung.com> References: <1498143942-12682-1-git-send-email-hugues.fruchet@st.com> <1498143942-12682-2-git-send-email-hugues.fruchet@st.com> <64e3005d-31df-71f2-762b-2c1b1152fc2d@st.com> <5cd25a47-f3be-8c40-3940-29f26a245076@kernel.org> <39501C78-7B81-4803-94C1-25DFA06EA526@goldelico.com> <6F68CD33-70E6-47C1-9E89-5E2AA776879F@goldelico.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Return-path: In-reply-to: <6F68CD33-70E6-47C1-9E89-5E2AA776879F-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org> Content-language: en-GB Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: "H. Nikolaus Schaller" Cc: Hugues FRUCHET , Guennadi Liakhovetski , Rob Herring , Mark Rutland , Maxime Coquelin , Alexandre TORGUE , Mauro Carvalho Chehab , Hans Verkuil , devicetree , linux-arm-kernel , LKML , "linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Benjamin Gaignard , Yannick FERTRE , Discussions about the Letux Kernel List-Id: devicetree@vger.kernel.org On 06/28/2017 11:12 AM, H. Nikolaus Schaller wrote: >> Am 28.06.2017 um 00:57 schrieb Sylwester Nawrocki : >> On 06/27/2017 07:48 AM, H. Nikolaus Schaller wrote: >>>> Am 26.06.2017 um 22:04 schrieb Sylwester Nawrocki : >>>> 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 -- 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mailout1.samsung.com ([203.254.224.24]:45492 "EHLO mailout1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751234AbdF1Kuu (ORCPT ); Wed, 28 Jun 2017 06:50:50 -0400 Subject: Re: [PATCH v1 1/6] DT bindings: add bindings for ov965x camera module To: "H. Nikolaus Schaller" Cc: Hugues FRUCHET , Guennadi Liakhovetski , Rob Herring , Mark Rutland , Maxime Coquelin , Alexandre TORGUE , Mauro Carvalho Chehab , Hans Verkuil , devicetree , linux-arm-kernel , LKML , "linux-media@vger.kernel.org" , Benjamin Gaignard , Yannick FERTRE , Discussions about the Letux Kernel From: Sylwester Nawrocki Message-id: <5bcc7ec0-4ae5-3703-3cee-ed644eef710a@samsung.com> Date: Wed, 28 Jun 2017 12:50:39 +0200 MIME-version: 1.0 In-reply-to: <6F68CD33-70E6-47C1-9E89-5E2AA776879F@goldelico.com> Content-type: text/plain; charset="utf-8" Content-language: en-GB Content-transfer-encoding: 7bit References: <1498143942-12682-1-git-send-email-hugues.fruchet@st.com> <1498143942-12682-2-git-send-email-hugues.fruchet@st.com> <64e3005d-31df-71f2-762b-2c1b1152fc2d@st.com> <5cd25a47-f3be-8c40-3940-29f26a245076@kernel.org> <39501C78-7B81-4803-94C1-25DFA06EA526@goldelico.com> <6F68CD33-70E6-47C1-9E89-5E2AA776879F@goldelico.com> Sender: linux-media-owner@vger.kernel.org List-ID: On 06/28/2017 11:12 AM, H. Nikolaus Schaller wrote: >> Am 28.06.2017 um 00:57 schrieb Sylwester Nawrocki : >> On 06/27/2017 07:48 AM, H. Nikolaus Schaller wrote: >>>> Am 26.06.2017 um 22:04 schrieb Sylwester Nawrocki : >>>> 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: s.nawrocki@samsung.com (Sylwester Nawrocki) Date: Wed, 28 Jun 2017 12:50:39 +0200 Subject: [PATCH v1 1/6] DT bindings: add bindings for ov965x camera module In-Reply-To: <6F68CD33-70E6-47C1-9E89-5E2AA776879F@goldelico.com> References: <1498143942-12682-1-git-send-email-hugues.fruchet@st.com> <1498143942-12682-2-git-send-email-hugues.fruchet@st.com> <64e3005d-31df-71f2-762b-2c1b1152fc2d@st.com> <5cd25a47-f3be-8c40-3940-29f26a245076@kernel.org> <39501C78-7B81-4803-94C1-25DFA06EA526@goldelico.com> <6F68CD33-70E6-47C1-9E89-5E2AA776879F@goldelico.com> Message-ID: <5bcc7ec0-4ae5-3703-3cee-ed644eef710a@samsung.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 06/28/2017 11:12 AM, H. Nikolaus Schaller wrote: >> Am 28.06.2017 um 00:57 schrieb Sylwester Nawrocki : >> On 06/27/2017 07:48 AM, H. Nikolaus Schaller wrote: >>>> Am 26.06.2017 um 22:04 schrieb Sylwester Nawrocki : >>>> 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