On Tue, 22 Nov 2022 17:22:45 +0100
Quentin Schulz [off-list ref] wrote:

Hi Robin,

On 11/22/22 13:46, Robin Murphy wrote:

quoted

On 2022-11-22 09:58, Quentin Schulz wrote:  

quoted

Hi David,

Thanks Fabio for the Cc.

On 11/22/22 08:18, David Jander wrote:  

quoted

On Mon, 21 Nov 2022 15:18:32 -0300
Fabio Estevam [off-list ref] wrote:
 

quoted

[Adding Angus and David]  

Thanks. This was apparently necessary ;-)
 

quoted

On Mon, Nov 21, 2022 at 3:12 PM Quentin Schulz 
[off-list ref] wrote:  

quoted

From: Quentin Schulz <redacted>

The reset line is active low for the Goodix touchscreen controller so
let's fix the polarity in the Device Tree node.

Signed-off-by: Quentin Schulz <redacted>
---
  arch/arm64/boot/dts/freescale/imx8mm-prt8mm.dts         | 2 +-
  arch/arm64/boot/dts/freescale/imx8mq-librem5-devkit.dts | 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8mm-prt8mm.dts 

b/arch/arm64/boot/dts/freescale/imx8mm-prt8mm.dts
index 9fbbbb556c0b3..df7e5ae9698e1 100644

--- a/arch/arm64/boot/dts/freescale/imx8mm-prt8mm.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mm-prt8mm.dts

@@ -107,7 +107,7 @@ touchscreeen@5d {

                 interrupt-parent = <&gpio1>;
                 interrupts = <8 IRQ_TYPE_NONE>;
                 irq-gpios = <&gpio1 8 GPIO_ACTIVE_HIGH>;
-               reset-gpios = <&gpio1 9 GPIO_ACTIVE_HIGH>;
+               reset-gpios = <&gpio1 9 GPIO_ACTIVE_LOW>;  

NACK!

The PRT8MM has an inverter in the reset line. The reason for that is 
that the
reset line needs to be inactive when the driving side is unpowered.
The DT was correct, this change will break it.
 

The DT was correct. The implementation in the driver is changed (the 
polarity is swapped) in this patch series, therefore the DT isn't 
correct anymore, hence this patch.  

I'm not sure it's quite that simple... FWIW I'm using an add-on LCD 
module with a GT9271[1] (and I won't be the only one - Raspberry Pi and 
other SBC users using DT overlays or custom-built DTBs are a whole other 
can of worms here), where GPIO_ACTIVE_LOW is correctly specified per the 
schematics, thus "wrong" for the current driver behaviour, yet it *is* 
working OK as-is. I guess that's because /RSTB ends up driven low for 
long enough between the current "deassertion" by 
gpiod_direction_output(1) and gpiod_direction_input() allowing the 
external pull-up to take it high again.
  

Correct, that seems like it is the case for "current-wrong" GPIO level, 
provided you have a pull-up on the RESET line (as recommended in the 
datasheet).

c.f. 
https://github.com/hadess/gt9xx/blob/master/specifications/GT9271%20Datasheet.pdf

with the current driver, what I assume we should get is:
             ___________________
INT _______|                   |___________

     ____________           __________________
RST             |_________|

    ^
    L__ pull-up on RST so high by default
         ^
         L___ gpiod_direction_output(0) (deassert GPIO active-low, so high)
            ^
            L____ goodix_irq_direction_output
                 ^
                 L___ gpiod_direction_output(1) (assert GPIO active-low, 
so low)
                           ^
                           L____ gpiod_direction_input() (floating, 
pull-up on RST so high)

This works because of the pull-up on RST and that what matters is that 
the INT lane is configured 100µs before a rising edge on RST line (for 
at least 5ms). However, the init sequence is not properly followed and 
might get broken in the future since it is not something that we 
explicitly support.

With the proposed patch:
             ___________________
INT _______|                   |___________

     ____         __________________
RST     |_______|

    ^
    L__ pull-up on RST so high by default
         ^
         L___ gpiod_direction_output(1) (assert GPIO active-low, so low)
            ^
            L____ goodix_irq_direction_output
                 ^
                 L___ gpiod_direction_output(1) (deassert GPIO 
active-low, so high)
                           ^
                           L____ gpiod_direction_input() (floating, 
pull-up on RST so high)

This should work too and does not rely on some side effects/timings and 
should be future-proof.

As for OOT DTB/DTBO, nothing I can do unfortunately, that is correct.

The fact that we have both "interpretations" of the RESET GPIO level in 
Linux is worrying, albeit with OOT DTBs. A driver or subsystem rework 
might break boards in which case people should update their DTB as 
suggested here or we'll decide to support both interpretations, which 
ain't great either.

Thanks for the detailed drawings. Yes, it seems this is an unfortunate case of
both polarities kind of working.

Our DT was correct, but the driver was wrong, even if it seemed to work
correctly, so this NACK still stands.

Our board has this GPIO pin wired to the gate of a MOSFET which acts as an
inverter and also isolates the signal from the GPIO port power rail. So from
the GPIO point of view, the signal is ACTIVE_HIGH. Please leave the DT like
this.

Thanks for fixing the driver.

Best regards,

-- 
David Jander
Protonic Holland.


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel