diff mbox

[RESEND,1/2] devicetree: mxsfb: add reset-active property

Message ID 1452594141-26073-1-git-send-email-mans@mansr.com (mailing list archive)
State New, archived
Headers show

Commit Message

Måns Rullgård Jan. 12, 2016, 10:22 a.m. UTC
Some boards connect the LCD_RESET pin to a reset input on the
display panel.  On these boards, this pin must be set to the
proper level for the display to function.

This adds an optional "reset-active" property to the "display"
subnode such that devicetrees can specify the desired polarity
of the LCD_RESET pin.

Signed-off-by: Mans Rullgard <mans@mansr.com>
---
 Documentation/devicetree/bindings/display/mxsfb.txt | 5 +++++
 1 file changed, 5 insertions(+)

Comments

Tomi Valkeinen Jan. 12, 2016, 12:44 p.m. UTC | #1
On 12/01/16 12:22, Mans Rullgard wrote:
> Some boards connect the LCD_RESET pin to a reset input on the
> display panel.  On these boards, this pin must be set to the
> proper level for the display to function.
> 
> This adds an optional "reset-active" property to the "display"
> subnode such that devicetrees can specify the desired polarity
> of the LCD_RESET pin.
> 
> Signed-off-by: Mans Rullgard <mans@mansr.com>
> ---
>  Documentation/devicetree/bindings/display/mxsfb.txt | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/display/mxsfb.txt b/Documentation/devicetree/bindings/display/mxsfb.txt
> index 96ec5179c8a0..cb7212a6bdf2 100644
> --- a/Documentation/devicetree/bindings/display/mxsfb.txt
> +++ b/Documentation/devicetree/bindings/display/mxsfb.txt
> @@ -13,6 +13,11 @@ Required properties:
>  - bits-per-pixel : <16> for RGB565, <32> for RGB888/666.
>  - bus-width : number of data lines.  Could be <8>, <16>, <18> or <24>.
>  
> +Optional properties:
> +- reset-active : <0>: reset pin is active low
> +                 <1>: reset pin is active high
> +                 omitted: reset pin not used
> +
>  Required sub-node:
>  - display-timings : Refer to binding doc display-timing.txt for details.

So maybe this is fine for the mxsfb if it doesn't support any kind of
panel drivers, and there's no plan to extend it. Otherwise the LCD_RESET
pin could perhaps be exposed as a GPIO for the panel drivers.

But even so, I think the definition of "reset" is a bit vague.

I know panels for which "reset" is a pulse, you assert it for a short
period. Other panels take reset more like a on/off switch. If I'm not
mistaken, this one is the latter kind.

I don't see any sleeps related to reset in the code. If reset is
asserted when the display is blanked, is it guaranteed that the reset
stays asserted long enough until the display is enabled again?

 Tomi
Måns Rullgård Jan. 12, 2016, 1:10 p.m. UTC | #2
Tomi Valkeinen <tomi.valkeinen@ti.com> writes:

> On 12/01/16 12:22, Mans Rullgard wrote:
>> Some boards connect the LCD_RESET pin to a reset input on the
>> display panel.  On these boards, this pin must be set to the
>> proper level for the display to function.
>> 
>> This adds an optional "reset-active" property to the "display"
>> subnode such that devicetrees can specify the desired polarity
>> of the LCD_RESET pin.
>> 
>> Signed-off-by: Mans Rullgard <mans@mansr.com>
>> ---
>>  Documentation/devicetree/bindings/display/mxsfb.txt | 5 +++++
>>  1 file changed, 5 insertions(+)
>> 
>> diff --git a/Documentation/devicetree/bindings/display/mxsfb.txt b/Documentation/devicetree/bindings/display/mxsfb.txt
>> index 96ec5179c8a0..cb7212a6bdf2 100644
>> --- a/Documentation/devicetree/bindings/display/mxsfb.txt
>> +++ b/Documentation/devicetree/bindings/display/mxsfb.txt
>> @@ -13,6 +13,11 @@ Required properties:
>>  - bits-per-pixel : <16> for RGB565, <32> for RGB888/666.
>>  - bus-width : number of data lines.  Could be <8>, <16>, <18> or <24>.
>>  
>> +Optional properties:
>> +- reset-active : <0>: reset pin is active low
>> +                 <1>: reset pin is active high
>> +                 omitted: reset pin not used
>> +
>>  Required sub-node:
>>  - display-timings : Refer to binding doc display-timing.txt for details.
>
> So maybe this is fine for the mxsfb if it doesn't support any kind of
> panel drivers, and there's no plan to extend it. Otherwise the LCD_RESET
> pin could perhaps be exposed as a GPIO for the panel drivers.
>
> But even so, I think the definition of "reset" is a bit vague.
>
> I know panels for which "reset" is a pulse, you assert it for a short
> period. Other panels take reset more like a on/off switch. If I'm not
> mistaken, this one is the latter kind.
>
> I don't see any sleeps related to reset in the code. If reset is
> asserted when the display is blanked, is it guaranteed that the reset
> stays asserted long enough until the display is enabled again?

In the datasheet for the panel I'm dealing with, there's some vague
mention of 10 us (I missed it last time I looked), and my patch indeed
fails to ensure this is met.  Other panels will obviously have different
requirements.  To handle all cases properly, I suppose a configurable
delay after changing the reset pin should be added.

I could also take the lazy way out, pinmux this signal high and leave it
at that.
Tomi Valkeinen Jan. 12, 2016, 1:39 p.m. UTC | #3
On 12/01/16 15:10, Måns Rullgård wrote:

>> I don't see any sleeps related to reset in the code. If reset is
>> asserted when the display is blanked, is it guaranteed that the reset
>> stays asserted long enough until the display is enabled again?
> 
> In the datasheet for the panel I'm dealing with, there's some vague
> mention of 10 us (I missed it last time I looked), and my patch indeed
> fails to ensure this is met.  Other panels will obviously have different
> requirements.  To handle all cases properly, I suppose a configurable
> delay after changing the reset pin should be added.

Right. And then you need to ensure the powers are enabled in the right
order, the pixel clock is started at the right time (some need pix clock
before reset), and so on and so on =).

> I could also take the lazy way out, pinmux this signal high and leave it
> at that.

I've seen panels that require a reset after powers have been off, or
similar, but I hope those are minority.

So yes, probably just making sure the reset is not asserted is the most
generic and easy way forward.

 Tomi
diff mbox

Patch

diff --git a/Documentation/devicetree/bindings/display/mxsfb.txt b/Documentation/devicetree/bindings/display/mxsfb.txt
index 96ec5179c8a0..cb7212a6bdf2 100644
--- a/Documentation/devicetree/bindings/display/mxsfb.txt
+++ b/Documentation/devicetree/bindings/display/mxsfb.txt
@@ -13,6 +13,11 @@  Required properties:
 - bits-per-pixel : <16> for RGB565, <32> for RGB888/666.
 - bus-width : number of data lines.  Could be <8>, <16>, <18> or <24>.
 
+Optional properties:
+- reset-active : <0>: reset pin is active low
+                 <1>: reset pin is active high
+                 omitted: reset pin not used
+
 Required sub-node:
 - display-timings : Refer to binding doc display-timing.txt for details.