All of lore.kernel.org
 help / color / mirror / Atom feed
From: "H. Nikolaus Schaller" <hns@goldelico.com>
To: Sylwester Nawrocki <snawrocki@kernel.org>
Cc: Hugues FRUCHET <hugues.fruchet@st.com>,
	Guennadi Liakhovetski <g.liakhovetski@gmx.de>,
	Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Maxime Coquelin <mcoquelin.stm32@gmail.com>,
	Alexandre TORGUE <alexandre.torgue@st.com>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Hans Verkuil <hverkuil@xs4all.nl>,
	devicetree <devicetree@vger.kernel.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	LKML <linux-kernel@vger.kernel.org>,
	"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
	Benjamin Gaignard <benjamin.gaignard@linaro.org>,
	Yannick FERTRE <yannick.fertre@st.com>,
	Discussions about the Letux Kernel 
	<letux-kernel@openphoenux.org>
Subject: Re: [PATCH v1 1/6] DT bindings: add bindings for ov965x camera module
Date: Wed, 28 Jun 2017 11:12:38 +0200	[thread overview]
Message-ID: <6F68CD33-70E6-47C1-9E89-5E2AA776879F@goldelico.com> (raw)
In-Reply-To: <e2a9df8b-00f8-ae36-f4f3-63dcc98dea50@kernel.org>


> Am 28.06.2017 um 00:57 schrieb Sylwester Nawrocki <snawrocki@kernel.org>:
> 
> On 06/27/2017 07:48 AM, H. Nikolaus Schaller wrote:
>>> Am 26.06.2017 um 22:04 schrieb Sylwester Nawrocki <snawrocki@kernel.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.

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

WARNING: multiple messages have this Message-ID (diff)
From: "H. Nikolaus Schaller" <hns@goldelico.com>
To: Sylwester Nawrocki <snawrocki@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
	devicetree <devicetree@vger.kernel.org>,
	Benjamin Gaignard <benjamin.gaignard@linaro.org>,
	Discussions about the Letux Kernel <letux-kernel@openphoenux.org>,
	Alexandre TORGUE <alexandre.torgue@st.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Hans Verkuil <hverkuil@xs4all.nl>,
	Yannick FERTRE <yannick.fertre@st.com>,
	Rob Herring <robh+dt@kernel.org>,
	Maxime Coquelin <mcoquelin.stm32@gmail.com>,
	Hugues FRUCHET <hugues.fruchet@st.com>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Guennadi Liakhovetski <g.liakhovetski@gmx.de>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>
Subject: Re: [PATCH v1 1/6] DT bindings: add bindings for ov965x camera module
Date: Wed, 28 Jun 2017 11:12:38 +0200	[thread overview]
Message-ID: <6F68CD33-70E6-47C1-9E89-5E2AA776879F@goldelico.com> (raw)
In-Reply-To: <e2a9df8b-00f8-ae36-f4f3-63dcc98dea50@kernel.org>


> Am 28.06.2017 um 00:57 schrieb Sylwester Nawrocki <snawrocki@kernel.org>:
> 
> On 06/27/2017 07:48 AM, H. Nikolaus Schaller wrote:
>>> Am 26.06.2017 um 22:04 schrieb Sylwester Nawrocki <snawrocki@kernel.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.

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

WARNING: multiple messages have this Message-ID (diff)
From: hns@goldelico.com (H. Nikolaus Schaller)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v1 1/6] DT bindings: add bindings for ov965x camera module
Date: Wed, 28 Jun 2017 11:12:38 +0200	[thread overview]
Message-ID: <6F68CD33-70E6-47C1-9E89-5E2AA776879F@goldelico.com> (raw)
In-Reply-To: <e2a9df8b-00f8-ae36-f4f3-63dcc98dea50@kernel.org>


> Am 28.06.2017 um 00:57 schrieb Sylwester Nawrocki <snawrocki@kernel.org>:
> 
> On 06/27/2017 07:48 AM, H. Nikolaus Schaller wrote:
>>> Am 26.06.2017 um 22:04 schrieb Sylwester Nawrocki <snawrocki@kernel.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.

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

  reply	other threads:[~2017-06-28  9:13 UTC|newest]

Thread overview: 190+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-22 15:05 [PATCH v1 0/6] Add support of OV9655 camera Hugues Fruchet
2017-06-22 15:05 ` Hugues Fruchet
2017-06-22 15:05 ` Hugues Fruchet
2017-06-22 15:05 ` [PATCH v1 1/6] DT bindings: add bindings for ov965x camera module Hugues Fruchet
2017-06-22 15:05   ` Hugues Fruchet
2017-06-22 15:05   ` Hugues Fruchet
2017-06-23 10:25   ` H. Nikolaus Schaller
2017-06-23 10:25     ` H. Nikolaus Schaller
2017-06-23 10:25     ` H. Nikolaus Schaller
2017-06-23 10:25     ` H. Nikolaus Schaller
2017-06-23 10:46     ` Andreas Färber
2017-06-23 10:46       ` Andreas Färber
2017-06-23 10:46       ` Andreas Färber
2017-06-23 10:46       ` Andreas Färber
2017-06-23 10:59       ` H. Nikolaus Schaller
2017-06-23 10:59         ` H. Nikolaus Schaller
2017-06-23 10:59         ` H. Nikolaus Schaller
2017-06-23 10:59         ` H. Nikolaus Schaller
2017-06-23 11:58         ` Laurent Pinchart
2017-06-23 11:58           ` Laurent Pinchart
2017-06-23 11:58           ` Laurent Pinchart
2017-06-23 14:53           ` H. Nikolaus Schaller
2017-06-23 14:53             ` H. Nikolaus Schaller
2017-06-23 14:53             ` H. Nikolaus Schaller
2017-06-23 14:53             ` H. Nikolaus Schaller
2017-06-23 14:57             ` Andreas Färber
2017-06-23 14:57               ` Andreas Färber
2017-06-23 14:57               ` Andreas Färber
2017-06-23 14:57               ` Andreas Färber
2017-06-23 15:22               ` H. Nikolaus Schaller
2017-06-23 15:22                 ` H. Nikolaus Schaller
2017-06-23 15:22                 ` H. Nikolaus Schaller
2017-06-23 15:22                 ` H. Nikolaus Schaller
2017-06-23 18:05                 ` Suman Anna
2017-06-23 18:05                   ` Suman Anna
2017-06-23 18:05                   ` Suman Anna
2017-06-23 18:05                   ` Suman Anna
2017-06-23 18:59                   ` H. Nikolaus Schaller
2017-06-23 18:59                     ` H. Nikolaus Schaller
2017-06-23 18:59                     ` H. Nikolaus Schaller
2017-06-23 18:59                     ` H. Nikolaus Schaller
2017-06-23 22:24                     ` Suman Anna
2017-06-23 22:24                       ` Suman Anna
2017-06-23 22:24                       ` Suman Anna
2017-06-23 22:24                       ` Suman Anna
2017-06-26  6:00                       ` H. Nikolaus Schaller
2017-06-26  6:00                         ` H. Nikolaus Schaller
2017-06-26  6:00                         ` H. Nikolaus Schaller
2017-06-26  6:00                         ` H. Nikolaus Schaller
2017-06-26 10:35     ` Hugues FRUCHET
2017-06-26 10:35       ` Hugues FRUCHET
2017-06-26 10:35       ` Hugues FRUCHET
2017-06-26 10:35       ` Hugues FRUCHET
2017-06-26 20:04       ` Sylwester Nawrocki
2017-06-26 20:04         ` Sylwester Nawrocki
2017-06-26 20:04         ` Sylwester Nawrocki
2017-06-26 20:04         ` Sylwester Nawrocki
2017-06-27  5:48         ` H. Nikolaus Schaller
2017-06-27  5:48           ` H. Nikolaus Schaller
2017-06-27  5:48           ` H. Nikolaus Schaller
2017-06-27 22:57           ` Sylwester Nawrocki
2017-06-27 22:57             ` Sylwester Nawrocki
2017-06-27 22:57             ` Sylwester Nawrocki
2017-06-27 22:57             ` Sylwester Nawrocki
2017-06-28  9:12             ` H. Nikolaus Schaller [this message]
2017-06-28  9:12               ` H. Nikolaus Schaller
2017-06-28  9:12               ` H. Nikolaus Schaller
2017-06-28  9:12               ` H. Nikolaus Schaller
2017-06-28 10:50               ` Sylwester Nawrocki
2017-06-28 10:50                 ` Sylwester Nawrocki
2017-06-28 10:50                 ` Sylwester Nawrocki
2017-06-28 10:50                 ` Sylwester Nawrocki
2017-06-28 11:24                 ` H. Nikolaus Schaller
2017-06-28 11:24                   ` H. Nikolaus Schaller
2017-06-28 11:24                   ` H. Nikolaus Schaller
2017-06-28 11:24                   ` H. Nikolaus Schaller
2017-06-28 12:28                   ` Hugues FRUCHET
2017-06-28 12:28                     ` Hugues FRUCHET
2017-06-28 12:28                     ` Hugues FRUCHET
2017-06-26 18:56     ` Rob Herring
2017-06-26 18:56       ` Rob Herring
2017-06-26 18:56       ` Rob Herring
2017-06-26 18:56       ` Rob Herring
2017-06-26 18:54   ` Rob Herring
2017-06-26 18:54     ` Rob Herring
2017-06-26 18:54     ` Rob Herring
2017-06-22 15:05 ` [PATCH v1 2/6] [media] ov9650: add device tree support Hugues Fruchet
2017-06-22 15:05   ` Hugues Fruchet
2017-06-22 15:05   ` Hugues Fruchet
2017-06-26 16:31   ` Sakari Ailus
2017-06-26 16:31     ` Sakari Ailus
2017-06-26 17:46     ` H. Nikolaus Schaller
2017-06-26 17:46       ` H. Nikolaus Schaller
2017-06-26 17:46       ` H. Nikolaus Schaller
2017-06-27  5:36       ` Sakari Ailus
2017-06-27  5:36         ` Sakari Ailus
2017-06-27  5:36         ` Sakari Ailus
2017-06-27 10:14         ` Hugues FRUCHET
2017-06-27 10:14           ` Hugues FRUCHET
2017-06-27 10:14           ` Hugues FRUCHET
2017-06-22 15:05 ` [PATCH v1 3/6] [media] ov9650: select the nearest higher resolution Hugues Fruchet
2017-06-22 15:05   ` Hugues Fruchet
2017-06-22 15:05   ` Hugues Fruchet
2017-06-22 15:05 ` [PATCH v1 4/6] [media] ov9650: use write_array() for resolution sequences Hugues Fruchet
2017-06-22 15:05   ` Hugues Fruchet
2017-06-22 15:05   ` Hugues Fruchet
2017-06-26 16:33   ` Sakari Ailus
2017-06-26 16:33     ` Sakari Ailus
2017-06-26 16:33     ` Sakari Ailus
2017-06-29 13:59     ` Hugues FRUCHET
2017-06-29 13:59       ` Hugues FRUCHET
2017-06-29 13:59       ` Hugues FRUCHET
2017-06-29 13:59       ` Hugues FRUCHET
2017-06-22 15:05 ` [PATCH v1 5/6] [media] ov9650: add multiple variant support Hugues Fruchet
2017-06-22 15:05   ` Hugues Fruchet
2017-06-22 15:05   ` Hugues Fruchet
2017-06-25 12:36   ` kbuild test robot
2017-06-25 12:36     ` kbuild test robot
2017-06-25 12:36     ` kbuild test robot
2017-06-22 15:05 ` [PATCH v1 6/6] [media] ov9650: add support of OV9655 variant Hugues Fruchet
2017-06-22 15:05   ` Hugues Fruchet
2017-06-22 15:05   ` Hugues Fruchet
2017-06-25 16:07   ` [PATCH] ov9650: fix semicolon.cocci warnings kbuild test robot
2017-06-25 16:07     ` kbuild test robot
2017-06-25 16:07     ` kbuild test robot
2017-06-25 16:07   ` [PATCH v1 6/6] [media] ov9650: add support of OV9655 variant kbuild test robot
2017-06-25 16:07     ` kbuild test robot
2017-06-25 16:07     ` kbuild test robot
2017-06-26  6:03   ` H. Nikolaus Schaller
2017-06-26  6:03     ` H. Nikolaus Schaller
2017-06-26  6:03     ` H. Nikolaus Schaller
2017-06-26 11:49     ` Hugues FRUCHET
2017-06-26 11:49       ` Hugues FRUCHET
2017-06-26 11:49       ` Hugues FRUCHET
2017-06-26 11:49       ` Hugues FRUCHET
2017-06-22 15:41 ` [PATCH v1 0/6] Add support of OV9655 camera H. Nikolaus Schaller
2017-06-22 15:41   ` H. Nikolaus Schaller
2017-06-22 15:41   ` H. Nikolaus Schaller
2017-06-22 15:41   ` H. Nikolaus Schaller
2017-06-23 10:25   ` H. Nikolaus Schaller
2017-06-23 10:25     ` H. Nikolaus Schaller
2017-06-23 10:25     ` H. Nikolaus Schaller
2017-06-23 10:25     ` H. Nikolaus Schaller
2017-06-25  9:18     ` omap3isp camera was " Pavel Machek
2017-06-25  9:18       ` Pavel Machek
2017-06-25  9:18       ` Pavel Machek
2017-06-26  6:05       ` H. Nikolaus Schaller
2017-06-26  6:05         ` H. Nikolaus Schaller
2017-06-26  6:05         ` H. Nikolaus Schaller
2017-06-26  6:05         ` H. Nikolaus Schaller
2017-06-26  8:39         ` Pavel Machek
2017-06-26  8:39           ` Pavel Machek
2017-06-26  8:39           ` Pavel Machek
2017-06-26  8:39           ` Pavel Machek
2017-06-26  9:53           ` H. Nikolaus Schaller
2017-06-26  9:53             ` H. Nikolaus Schaller
2017-06-26  9:53             ` H. Nikolaus Schaller
2017-06-26  9:53             ` H. Nikolaus Schaller
2017-06-26 11:16             ` Pavel Machek
2017-06-26 11:16               ` Pavel Machek
2017-06-26 11:16               ` Pavel Machek
2017-06-26 11:16               ` Pavel Machek
2017-06-27  5:49               ` H. Nikolaus Schaller
2017-06-27  5:49                 ` H. Nikolaus Schaller
2017-06-27  5:49                 ` H. Nikolaus Schaller
2017-06-27  5:49                 ` H. Nikolaus Schaller
2017-06-26 13:19           ` Hugues FRUCHET
2017-06-26 13:19             ` Hugues FRUCHET
2017-06-26 13:19             ` Hugues FRUCHET
2017-06-26 16:28             ` H. Nikolaus Schaller
2017-06-26 16:28               ` H. Nikolaus Schaller
2017-06-27  7:57               ` Hugues FRUCHET
2017-06-27  7:57                 ` Hugues FRUCHET
2017-06-27  7:57                 ` Hugues FRUCHET
2017-06-27  7:57                 ` Hugues FRUCHET
     [not found]                 ` <95B10899-9966-4844-9667-D2434968A492@goldelico.com>
     [not found]                   ` <85e62c47-e319-c801-376c-95f4d9cbf75a@st.com>
     [not found]                     ` <E183E921-B8F4-4F8A-A302-58297A874990@goldelico.com>
     [not found]                       ` <77bd3b8fe52643d68ecc821ec22bc0e6@SFHDAG5NODE1.st.com>
2017-07-01 21:00                         ` H. Nikolaus Schaller
2017-07-03  8:16                           ` Hugues FRUCHET
2017-07-03  9:14                             ` H. Nikolaus Schaller
2017-07-03 12:03                               ` Hugues FRUCHET
2017-07-03 12:23                                 ` H. Nikolaus Schaller
2017-07-05 14:02                                   ` H. Nikolaus Schaller
2017-07-08 20:55                                     ` Sakari Ailus
2017-06-26  6:02     ` H. Nikolaus Schaller
2017-06-26  6:02       ` H. Nikolaus Schaller
2017-06-26  6:02       ` H. Nikolaus Schaller
2017-06-26  6:02       ` H. Nikolaus Schaller
2017-06-26 10:05   ` Hugues FRUCHET
2017-06-26 10:05     ` Hugues FRUCHET
2017-06-26 10:05     ` Hugues FRUCHET
2017-06-26 10:05     ` Hugues FRUCHET

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6F68CD33-70E6-47C1-9E89-5E2AA776879F@goldelico.com \
    --to=hns@goldelico.com \
    --cc=alexandre.torgue@st.com \
    --cc=benjamin.gaignard@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=g.liakhovetski@gmx.de \
    --cc=hugues.fruchet@st.com \
    --cc=hverkuil@xs4all.nl \
    --cc=letux-kernel@openphoenux.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mchehab@kernel.org \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=robh+dt@kernel.org \
    --cc=snawrocki@kernel.org \
    --cc=yannick.fertre@st.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.