Re: [PATCH v2 2/2] serial: sc16is7xx: hard reset the chip if reset-gpios is defined in dt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 5 Jun 2024 20:55:21 +0800
Hui Wang <hui.wang@xxxxxxxxxxxxx> wrote:

> 
> On 6/5/24 19:19, Andy Shevchenko wrote:
> > On Wed, Jun 5, 2024 at 1:55 PM Hui Wang<hui.wang@xxxxxxxxxxxxx>  wrote:
> >> On 6/5/24 18:30, Maarten Brock wrote:
> >>>> From: Hugo Villeneuve<hugo@xxxxxxxxxxx>
> >>>> Sent: Tuesday, 4 June 2024 16:23
> > <...>
> >
> >>>> Add function description from original comment "Reset device,
> >>>> purging any pending irq / data", since the comment applies to both
> >>>> hardware and software reset,
> >>> No it does not (at this moment). See below.
> > ...
> >
> >>> The problem here is that this only deasserts the reset if it were asserted before.
> >>> Nothing happens if it already was deasserted. This makes the delay also pretty
> >>> useless.
> >>>
> >>> To make this a proper reset pulse for the device you must first assert the reset,
> >>> then wait >3us, and finally deassert the reset.
> >> My understanding is when calling devm_gpiod_get_optional(dev, "reset",
> >> GPIOD_OUT_LOW) and returning a valid (gpio_desc *), the flag
> >> GPIOD_OUT_LOW guarantees the GPIO is set to output and low (assert the
> >> reset pin).
> > No, this is logical, not physical state. Maarten is correct. How did
> > you test this?
> 
> Yes, Maarten, Krzysztof and you are correct. Thanks for pointing out 
> this error.
> 
> If I call "reset_gpio = devm_gpiod_get_optional(dev, "reset", 
> GPIOD_OUT_HIGH);" I will get the result as below:
> 
> # cat /sys/kernel/debug/gpio
> 
> gpiochip4: GPIOs 128-159, parent: platform/30240000.gpio, 30240000.gpio: 
> gpio-141 ( |reset ) out lo ACTIVE LOW
> 
> If I call "reset_gpio = devm_gpiod_get_optional(dev, "reset", 
> GPIOD_OUT_LOW);" I will get the result as below:
> 
> # cat /sys/kernel/debug/gpio
> 
> gpiochip4: GPIOs 128-159, parent: platform/30240000.gpio, 30240000.gpio: 
> gpio-141 ( |reset ) out hi ACTIVE LOW
> 
> I tested the reset pin by dumping chip registers, if the reset pin is 
> asserted (out lo), I will get the result like this:
> 
> # cat /sys/kernel/debug/regmap/spi0.0-port0/registers 1: 10 2: ff 3: 00 
> 4: ec 5: ff 6: ff 7: ff 8: ff 9: ff a: ff b: ff c: ff d: ff e: ff f: 06

Hi Hui,
the best way to test a reset pin is with a voltmeter, if you can. It is
way too easy to get confused with reset pins values/polarities, etc.

By the way, if the reset pin is asserted, you cannot communicate with
the device, therefore dumping registers cannot work for debug purpose.

Hugo.


> 
> If the reset pin is deasserted (out hi), I will get:
> 
> # cat /sys/kernel/debug/regmap/spi0.0-port0/registers 1: 10 2: 01 3: 00 
> 4: 00 5: 60 6: 00 7: 2e 8: 40 9: 00 a: 00 b: ff c: 00 d: 00 e: 00 f: 06
> 
> My original code set the reset GPIO to high (the reset pin is 
> deasserted) continuously, so I didn't notice this hidden error.
> 
> Thanks,
> 
> Hui.
> 
> >


-- 
Hugo Villeneuve




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux