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
