diff mbox

[RFC,1/2] dt-bindings: simplefb: Support a list of regulator supply properties

Message ID 1444669458-5588-2-git-send-email-wens@csie.org
State Superseded, archived
Headers show

Commit Message

Chen-Yu Tsai Oct. 12, 2015, 5:04 p.m. UTC
The physical display tied to the framebuffer may have regulators
providing power to it, such as power for LCDs or interface conversion
chips.

The number of regulators in use may vary, but the regulator supply
binding can not be a list. Work around this by adding a "num-supplies"
property to communicate the number of supplies, and a list of 0 ~ N
"vinN-supply" properties for the actual regulator supply.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 .../devicetree/bindings/video/simple-framebuffer.txt       | 14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

Comments

Mark Rutland Oct. 12, 2015, 5:10 p.m. UTC | #1
On Tue, Oct 13, 2015 at 01:04:17AM +0800, Chen-Yu Tsai wrote:
> The physical display tied to the framebuffer may have regulators
> providing power to it, such as power for LCDs or interface conversion
> chips.
> 
> The number of regulators in use may vary, but the regulator supply
> binding can not be a list. Work around this by adding a "num-supplies"
> property to communicate the number of supplies, and a list of 0 ~ N
> "vinN-supply" properties for the actual regulator supply.

This is getting more complicated by the minute...

> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> ---
>  .../devicetree/bindings/video/simple-framebuffer.txt       | 14 ++++++++++----
>  1 file changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer.txt b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
> index 4474ef6e0b95..0cc43e1be8b5 100644
> --- a/Documentation/devicetree/bindings/video/simple-framebuffer.txt
> +++ b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
> @@ -47,10 +47,14 @@ Required properties:
>    - a8b8g8r8 (32-bit pixels, d[31:24]=a, d[23:16]=b, d[15:8]=g, d[7:0]=r).
>  
>  Optional properties:
> -- clocks : List of clocks used by the framebuffer. Clocks listed here
> -           are expected to already be configured correctly. The OS must
> -           ensure these clocks are not modified or disabled while the
> -           simple framebuffer remains active.
> +- clocks : List of clocks used by the framebuffer.
> +- num-supplies : The number of regulators used by the framebuffer.
> +- vinN-supply : The N-th (from 0) regulator used by the framebuffer.

I don't see why you need num-supplies. Why not just try probing
vin${N}-supply until such a property isn't present in the DT?

Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Chen-Yu Tsai Oct. 13, 2015, 2:22 a.m. UTC | #2
On Tue, Oct 13, 2015 at 1:10 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> On Tue, Oct 13, 2015 at 01:04:17AM +0800, Chen-Yu Tsai wrote:
>> The physical display tied to the framebuffer may have regulators
>> providing power to it, such as power for LCDs or interface conversion
>> chips.
>>
>> The number of regulators in use may vary, but the regulator supply
>> binding can not be a list. Work around this by adding a "num-supplies"
>> property to communicate the number of supplies, and a list of 0 ~ N
>> "vinN-supply" properties for the actual regulator supply.
>
> This is getting more complicated by the minute...

Yeah...

I considered "backlight" and "panel" properties, but that seems to need
more effort to parse. Regulators seemed easier.

>
>> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
>> ---
>>  .../devicetree/bindings/video/simple-framebuffer.txt       | 14 ++++++++++----
>>  1 file changed, 10 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer.txt b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
>> index 4474ef6e0b95..0cc43e1be8b5 100644
>> --- a/Documentation/devicetree/bindings/video/simple-framebuffer.txt
>> +++ b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
>> @@ -47,10 +47,14 @@ Required properties:
>>    - a8b8g8r8 (32-bit pixels, d[31:24]=a, d[23:16]=b, d[15:8]=g, d[7:0]=r).
>>
>>  Optional properties:
>> -- clocks : List of clocks used by the framebuffer. Clocks listed here
>> -           are expected to already be configured correctly. The OS must
>> -           ensure these clocks are not modified or disabled while the
>> -           simple framebuffer remains active.
>> +- clocks : List of clocks used by the framebuffer.
>> +- num-supplies : The number of regulators used by the framebuffer.
>> +- vinN-supply : The N-th (from 0) regulator used by the framebuffer.
>
> I don't see why you need num-supplies. Why not just try probing
> vin${N}-supply until such a property isn't present in the DT?

That's doable. Though I'd add a hard limit on it. Does 16 seem reasonable?

Thanks
ChenYu
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Hans de Goede Oct. 13, 2015, 7:08 a.m. UTC | #3
Hi,

On 13-10-15 04:22, Chen-Yu Tsai wrote:
> On Tue, Oct 13, 2015 at 1:10 AM, Mark Rutland <mark.rutland@arm.com> wrote:
>> On Tue, Oct 13, 2015 at 01:04:17AM +0800, Chen-Yu Tsai wrote:
>>> The physical display tied to the framebuffer may have regulators
>>> providing power to it, such as power for LCDs or interface conversion
>>> chips.
>>>
>>> The number of regulators in use may vary, but the regulator supply
>>> binding can not be a list. Work around this by adding a "num-supplies"
>>> property to communicate the number of supplies, and a list of 0 ~ N
>>> "vinN-supply" properties for the actual regulator supply.
>>
>> This is getting more complicated by the minute...
>
> Yeah...
>
> I considered "backlight" and "panel" properties, but that seems to need
> more effort to parse. Regulators seemed easier.
>
>>
>>> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
>>> ---
>>>   .../devicetree/bindings/video/simple-framebuffer.txt       | 14 ++++++++++----
>>>   1 file changed, 10 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer.txt b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
>>> index 4474ef6e0b95..0cc43e1be8b5 100644
>>> --- a/Documentation/devicetree/bindings/video/simple-framebuffer.txt
>>> +++ b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
>>> @@ -47,10 +47,14 @@ Required properties:
>>>     - a8b8g8r8 (32-bit pixels, d[31:24]=a, d[23:16]=b, d[15:8]=g, d[7:0]=r).
>>>
>>>   Optional properties:
>>> -- clocks : List of clocks used by the framebuffer. Clocks listed here
>>> -           are expected to already be configured correctly. The OS must
>>> -           ensure these clocks are not modified or disabled while the
>>> -           simple framebuffer remains active.
>>> +- clocks : List of clocks used by the framebuffer.
>>> +- num-supplies : The number of regulators used by the framebuffer.
>>> +- vinN-supply : The N-th (from 0) regulator used by the framebuffer.
>>
>> I don't see why you need num-supplies. Why not just try probing
>> vin${N}-supply until such a property isn't present in the DT?

+1 for this.

> That's doable. Though I'd add a hard limit on it. Does 16 seem reasonable?

I would not add a hard limit to the binding, you can use a fixed array in
the code to make the code simpler. I would say 8 should be sufficient, since
the limit will only be in the code we can always bump it when we need to.

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Mark Brown Oct. 14, 2015, 10:36 a.m. UTC | #4
On Tue, Oct 13, 2015 at 09:08:46AM +0200, Hans de Goede wrote:
> On 13-10-15 04:22, Chen-Yu Tsai wrote:
> >On Tue, Oct 13, 2015 at 1:10 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> >>On Tue, Oct 13, 2015 at 01:04:17AM +0800, Chen-Yu Tsai wrote:

> >>>+- num-supplies : The number of regulators used by the framebuffer.
> >>>+- vinN-supply : The N-th (from 0) regulator used by the framebuffer.

> >>I don't see why you need num-supplies. Why not just try probing
> >>vin${N}-supply until such a property isn't present in the DT?

> +1 for this.

Even better would be to just enumerate all the properties on the node
and request anything with a FOO-supply name.  That way we can keep
using standard regulator bindings that name the supplies after their
actual names on the device.

> > That's doable. Though I'd add a hard limit on it. Does 16 seem
> > reasonable?

> I would not add a hard limit to the binding, you can use a fixed array in
> the code to make the code simpler. I would say 8 should be sufficient, since
> the limit will only be in the code we can always bump it when we need
> to.

Or just dynamically allocate the array and resize as needed if it starts
to get to be a problem.
diff mbox

Patch

diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer.txt b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
index 4474ef6e0b95..0cc43e1be8b5 100644
--- a/Documentation/devicetree/bindings/video/simple-framebuffer.txt
+++ b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
@@ -47,10 +47,14 @@  Required properties:
   - a8b8g8r8 (32-bit pixels, d[31:24]=a, d[23:16]=b, d[15:8]=g, d[7:0]=r).
 
 Optional properties:
-- clocks : List of clocks used by the framebuffer. Clocks listed here
-           are expected to already be configured correctly. The OS must
-           ensure these clocks are not modified or disabled while the
-           simple framebuffer remains active.
+- clocks : List of clocks used by the framebuffer.
+- num-supplies : The number of regulators used by the framebuffer.
+- vinN-supply : The N-th (from 0) regulator used by the framebuffer.
+
+  The above resources are expected to already be configured correctly.
+  The OS must ensure they are not modified or disabled while the simple
+  framebuffer remains active.
+
 - display : phandle pointing to the primary display hardware node
 
 Example:
@@ -68,6 +72,8 @@  chosen {
 		stride = <(1600 * 2)>;
 		format = "r5g6b5";
 		clocks = <&ahb_gates 36>, <&ahb_gates 43>, <&ahb_gates 44>;
+		num-supplies = <1>;
+		vin0-supply = <&reg_dc1sw>;
 		display = <&lcdc0>;
 	};
 	stdout-path = "display0";