From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751554AbdF1LZn (ORCPT ); Wed, 28 Jun 2017 07:25:43 -0400 Received: from mo4-p00-ob.smtp.rzone.de ([81.169.146.163]:36258 "EHLO mo4-p00-ob.smtp.rzone.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751469AbdF1LZg (ORCPT ); Wed, 28 Jun 2017 07:25:36 -0400 X-RZG-AUTH: :JGIXVUS7cutRB/49FwqZ7WcecEarQROEYabkiUo6mSAGQ+qKID8zPH8HfA== X-RZG-CLASS-ID: mo00 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: [PATCH v1 1/6] DT bindings: add bindings for ov965x camera module From: "H. Nikolaus Schaller" In-Reply-To: <5bcc7ec0-4ae5-3703-3cee-ed644eef710a@samsung.com> Date: Wed, 28 Jun 2017 13:24:57 +0200 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 Message-Id: <9D51AC4C-6CB7-46A5-B363-2AD6DA6C497F@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> <5bcc7ec0-4ae5-3703-3cee-ed644eef710a@samsung.com> To: Sylwester Nawrocki X-Mailer: Apple Mail (2.3124) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id v5SBPpVj031471 > Am 28.06.2017 um 12:50 schrieb Sylwester Nawrocki : > > 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. 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: "H. Nikolaus Schaller" Subject: Re: [PATCH v1 1/6] DT bindings: add bindings for ov965x camera module Date: Wed, 28 Jun 2017 13:24:57 +0200 Message-ID: <9D51AC4C-6CB7-46A5-B363-2AD6DA6C497F@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> <5bcc7ec0-4ae5-3703-3cee-ed644eef710a@samsung.com> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <5bcc7ec0-4ae5-3703-3cee-ed644eef710a-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Sylwester Nawrocki 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 > Am 28.06.2017 um 12:50 schrieb Sylwester Nawrocki = : >=20 > 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. >>>>>>>=20 >>>>>>> - vana-supply: a regulator to power up the camera module. >>>>>>>=20 >>>>>>> Driver code is not complex to add: >>>>>=20 >>>>>> 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. >>>>>=20 >>>>> 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: >>>>>=20 >>>>> AVDD - Analog power supply, >>>>> DVDD - Power supply for digital core logic, >>>>> DOVDD - Digital power supply for I/O. >>>>=20 >>>> The latter two are usually not independently switchable from the = SoC power >>>> the module is connected to. >>>>=20 >>>> And sometimes DVDD and DOVDD are connected together. >>>>=20 >>>> So the driver can't make much use of knowing or requesting them = because the >>>> 1.8V supply is always active, even during suspend. >>>>=20 >>>>>=20 >>>>> 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. >>>>=20 >>>> 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. >>>=20 >>> 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. >>=20 >> Ah, ok. I see. >>=20 >> I had thought that it is the right thing to do like = devm_gpiod_get_optional(). >>=20 >> That one it is described as: >>=20 >> "* 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." >>=20 >> Seems to be inconsistent definition of what "optional" means. >=20 > Indeed, this commit explains it further: >=20 > commit de1dd9fd2156874b45803299b3b27e65d5defdd9 > regulator: core: Provide hints to the core about optional supplies >=20 >> So we indeed should use devm_regulator_get() in this case. Thanks for = > pointing out! >=20 >>>> 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. >>>>=20 >>>> It does matter if they are mandatory because it adds DT complexity = (size >>>> and processing) without added function. >>>=20 >>> 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. >>=20 >> Ok, then it should just be defined in the bindings but not used by=20 >> the driver? >=20 > Yes, I think so. So we have a possibly complete binding right from the=20= > 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 -- 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 mo4-p00-ob.smtp.rzone.de ([81.169.146.163]:36258 "EHLO mo4-p00-ob.smtp.rzone.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751469AbdF1LZg (ORCPT ); Wed, 28 Jun 2017 07:25:36 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: [PATCH v1 1/6] DT bindings: add bindings for ov965x camera module From: "H. Nikolaus Schaller" In-Reply-To: <5bcc7ec0-4ae5-3703-3cee-ed644eef710a@samsung.com> Date: Wed, 28 Jun 2017 13:24:57 +0200 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 Content-Transfer-Encoding: quoted-printable Message-Id: <9D51AC4C-6CB7-46A5-B363-2AD6DA6C497F@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> <5bcc7ec0-4ae5-3703-3cee-ed644eef710a@samsung.com> To: Sylwester Nawrocki Sender: linux-media-owner@vger.kernel.org List-ID: > Am 28.06.2017 um 12:50 schrieb Sylwester Nawrocki = : >=20 > 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. >>>>>>>=20 >>>>>>> - vana-supply: a regulator to power up the camera module. >>>>>>>=20 >>>>>>> Driver code is not complex to add: >>>>>=20 >>>>>> 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. >>>>>=20 >>>>> 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: >>>>>=20 >>>>> AVDD - Analog power supply, >>>>> DVDD - Power supply for digital core logic, >>>>> DOVDD - Digital power supply for I/O. >>>>=20 >>>> The latter two are usually not independently switchable from the = SoC power >>>> the module is connected to. >>>>=20 >>>> And sometimes DVDD and DOVDD are connected together. >>>>=20 >>>> So the driver can't make much use of knowing or requesting them = because the >>>> 1.8V supply is always active, even during suspend. >>>>=20 >>>>>=20 >>>>> 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. >>>>=20 >>>> 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. >>>=20 >>> 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. >>=20 >> Ah, ok. I see. >>=20 >> I had thought that it is the right thing to do like = devm_gpiod_get_optional(). >>=20 >> That one it is described as: >>=20 >> "* 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." >>=20 >> Seems to be inconsistent definition of what "optional" means. >=20 > Indeed, this commit explains it further: >=20 > commit de1dd9fd2156874b45803299b3b27e65d5defdd9 > regulator: core: Provide hints to the core about optional supplies >=20 >> So we indeed should use devm_regulator_get() in this case. Thanks for = > pointing out! >=20 >>>> 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. >>>>=20 >>>> It does matter if they are mandatory because it adds DT complexity = (size >>>> and processing) without added function. >>>=20 >>> 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. >>=20 >> Ok, then it should just be defined in the bindings but not used by=20 >> the driver? >=20 > Yes, I think so. So we have a possibly complete binding right from the=20= > 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: hns@goldelico.com (H. Nikolaus Schaller) Date: Wed, 28 Jun 2017 13:24:57 +0200 Subject: [PATCH v1 1/6] DT bindings: add bindings for ov965x camera module In-Reply-To: <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> <5bcc7ec0-4ae5-3703-3cee-ed644eef710a@samsung.com> Message-ID: <9D51AC4C-6CB7-46A5-B363-2AD6DA6C497F@goldelico.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org > Am 28.06.2017 um 12:50 schrieb Sylwester Nawrocki : > > 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. 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