linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sander Vanheule <sander@svanheule.net>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Andrew Lunn <andrew@lunn.ch>, Pavel Machek <pavel@ucw.cz>,
	Rob Herring <robh+dt@kernel.org>,
	Lee Jones <lee.jones@linaro.org>, Mark Brown <broonie@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Rafael J . Wysocki" <rafael@kernel.org>,
	Michael Walle <michael@walle.cc>,
	Linus Walleij <linus.walleij@linaro.org>,
	Bartosz Golaszewski <bgolaszewski@baylibre.com>,
	Linux LED Subsystem <linux-leds@vger.kernel.org>,
	devicetree <devicetree@vger.kernel.org>,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 0/6] RTL8231 GPIO expander support
Date: Wed, 26 May 2021 23:02:40 +0200	[thread overview]
Message-ID: <cbfba24a6206ec73ccc844da5d1331959e3f3520.camel@svanheule.net> (raw)
In-Reply-To: <CAHp75VfCBtcQX4rvmQnRMquM0k7ZBqOgZN15Z7TFNSO60SB9TA@mail.gmail.com>

On Tue, 2021-05-25 at 20:11 +0300, Andy Shevchenko wrote:
> On Mon, May 24, 2021 at 7:30 PM Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
> > On Mon, May 24, 2021 at 6:03 PM Sander Vanheule <sander@svanheule.net>
> > wrote:
> > > On Mon, 2021-05-24 at 15:54 +0300, Andy Shevchenko wrote:
> 
> ...
> 
> > > Sadly, I don't. Most of the info we have comes from code archives of
> > > switch
> > > vendors (Zyxel, Cisco etc). Boards need to be reverse engineered, and the
> > > few
> > > leaked datasheets that can be found on the internet aren't exactly thick
> > > in
> > > information.
> > > 
> > > The RTL8231 datasheet is actually quite useful, but makes no mention of
> > > the
> > > output value isse. Since this isn't an official resource, I don't think it
> > > would
> > > be appropriate to link it via a Datasheet: tag.
> > > https://github.com/libc0607/Realtek_switch_hacking/blob/files/RTL8231_Datasheet_
> > > 1.2.pdf
> > > 
> > > Looking at the datasheet again, I came up with a... terrible hack to work
> > > around
> > > the output value issue.
> > > 
> > > The chip also has GPIO_INVERT registers that I hadn't used until now,
> > > because
> > > the logical inversion is handled in the kernel. However, these inversion
> > > registers only apply to the output values. So, I could implement glitch-
> > > free
> > > output behaviour in the following way:
> > >  * After chip reset, and before enabling the output driver (MFD
> > > initialisation):
> > >     - Mux all pins as GPIO
> > >     - Change all pins to outputs,
> > 
> > No. no, no. This is much worse than the glitches. You never know what
> > the hardware is connected there and it's potential breakage (on hw
> > level) possible.
> > 
> > >  so the data registers (0x1c-0x1e) become writable
> > >     - Write value 0 to all pins
> > >     - Change all pins to GPI to change them into high-Z
> > >  * In the pinctrl/gpio driver:
> > >     - Use data registers as input-only
> > >     - Use inversion register to determine output value (can be written any
> > > time)
> > > 
> > > The above gives glitch-free outputs, but the values that are read back
> > > (when
> > > configured as output), come from the data registers. They should now be
> > > coming
> > > from the inversion (reg_set_base) registers, but the code prefers to use
> > > the
> > > data registers (reg_dat_base).
> > 
> > Lemme read the datasheet and see if I find any clue for the hw behaviour.
> 
> Thank you for your patience!
> 
> Have you explored the possibility of using En_Sync_GPIO?

Got around to testing things.

If En_Sync_GPIO is enabled, it's still possible to change the pin direction
without also writing the Sync_GPIO bit. So even with the latching, glitches are
still produced.

As long as Sync_GPIO is not set to latch the new values, it also appears that
reads of the data registers result in the current output value, not the new one.

As a different test, I've added a pull-down, to make the input level low. Now I
see the opposite behaviour as before (with set-value-before-direction):
 * OUT-HIGH > IN (low) > OUT-LOW: results in a high level (i.e. old value)
 * OUT-HIGH > IN (low) > OUT-HIGH: results in a high level (new/old value)
 * OUT-LOW > IN (low) > OUT-HIGH: results in a high level (new value, or toggled
   old value?)
 * OUT-LOW > IN (low) > OUT-LOW: results in a low level (new/old value)

For reference, with a pull-up:
 * OUT-HIGH > IN (high) > OUT-HIGH: high result
 * OUT-HIGH > IN (high) > OUT-LOW: low result
 * OUT-LOW > IN (high) > OUT-HIGH: low result
 * OUT-LOW > IN (high) > OUT-LOW: low result

I've only tested this with the sysfs interface, so I don't know what the result
would be on multiple writes to the data register (during input, but probably not
very relevant). Nor have I tested direction changes if the input has changed
between two output values.

I may have some time tomorrow for more testing, but otherwise it'll have to wait
until the weekend. Any other ideas in the meantime?


Best,
Sander


  parent reply	other threads:[~2021-05-26 21:02 UTC|newest]

Thread overview: 114+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-11 12:25 [PATCH 0/5] RTL8231 GPIO expander support Sander Vanheule
2021-05-11 12:25 ` [PATCH 1/5] dt-bindings: leds: Binding for RTL8231 scan matrix Sander Vanheule
2021-05-17 22:31   ` Rob Herring
2021-05-19 16:39     ` Sander Vanheule
2021-05-11 12:25 ` [PATCH 2/5] dt-bindings: mfd: Binding for RTL8231 Sander Vanheule
2021-05-17 22:38   ` Rob Herring
2021-05-19 16:53     ` Sander Vanheule
2021-05-11 12:25 ` [PATCH 3/5] mfd: Add RTL8231 core device Sander Vanheule
2021-05-12 12:29   ` kernel test robot
2021-05-12 13:13   ` kernel test robot
2021-05-19 14:58     ` Lee Jones
2021-05-19 15:11       ` Sander Vanheule
2021-05-11 12:25 ` [PATCH 4/5] pinctrl: Add RTL8231 pin control and GPIO support Sander Vanheule
2021-05-11 12:25 ` [PATCH 5/5] leds: Add support for RTL8231 LED scan matrix Sander Vanheule
     [not found] ` <CAHp75VffoKyyPJbdtKMLx575c9LT0S8+EHOk7Mw36j=aTL6Q4Q@mail.gmail.com>
2021-05-16 21:40   ` [PATCH 0/5] RTL8231 GPIO expander support Sander Vanheule
2021-05-17  8:13     ` Andy Shevchenko
2021-05-17  8:50       ` Sander Vanheule
2021-05-17 19:32     ` Sander Vanheule
2021-05-17 19:28 ` [PATCH v2 0/7] " Sander Vanheule
2021-05-17 19:28   ` [PATCH v2 1/7] regmap: Add MDIO bus support Sander Vanheule
2021-05-19 16:12     ` Mark Brown
2021-05-17 19:28   ` [PATCH v2 2/7] gpio: regmap: Add configurable dir/value order Sander Vanheule
2021-05-17 21:06     ` Andy Shevchenko
2021-05-18  1:40     ` Andrew Lunn
2021-05-18 11:39       ` Sander Vanheule
2021-05-23 22:21       ` Sander Vanheule
2021-05-18  8:39     ` Michael Walle
2021-05-18 10:39       ` Andy Shevchenko
2021-05-23 21:19       ` Sander Vanheule
2021-05-17 19:28   ` [PATCH v2 3/7] dt-bindings: leds: Binding for RTL8231 scan matrix Sander Vanheule
2021-05-17 19:28   ` [PATCH v2 4/7] dt-bindings: mfd: Binding for RTL8231 Sander Vanheule
2021-05-18 22:02     ` Linus Walleij
2021-05-17 19:28   ` [PATCH v2 5/7] mfd: Add RTL8231 core device Sander Vanheule
2021-05-17 21:18     ` Andy Shevchenko
2021-05-23 21:28       ` Sander Vanheule
2021-05-24  7:49         ` Andy Shevchenko
2021-05-24  7:50       ` Sander Vanheule
2021-05-24  7:55         ` Andy Shevchenko
2021-05-24  8:04           ` Sander Vanheule
2021-05-17 19:28   ` [PATCH v2 6/7] pinctrl: Add RTL8231 pin control and GPIO support Sander Vanheule
2021-05-17 21:42     ` Andy Shevchenko
2021-05-17 21:46       ` Andy Shevchenko
2021-05-23 21:42       ` Sander Vanheule
2021-05-17 19:28   ` [PATCH v2 7/7] leds: Add support for RTL8231 LED scan matrix Sander Vanheule
2021-05-17 22:00     ` Andy Shevchenko
2021-05-23 21:53       ` Sander Vanheule
2021-05-19 16:10   ` (subset) [PATCH v2 0/7] RTL8231 GPIO expander support Mark Brown
2021-05-23 22:33 ` [PATCH v3 0/6] " Sander Vanheule
2021-05-23 22:33   ` [PATCH v3 1/6] gpio: regmap: Add quirk for output data register Sander Vanheule
2021-05-28  6:40     ` Michael Walle
2021-06-03 10:03       ` Sander Vanheule
2021-05-31  7:25     ` Bartosz Golaszewski
2021-05-23 22:34   ` [PATCH v3 2/6] dt-bindings: leds: Binding for RTL8231 scan matrix Sander Vanheule
2021-06-02 18:58     ` Rob Herring
2021-05-23 22:34   ` [PATCH v3 3/6] dt-bindings: mfd: Binding for RTL8231 Sander Vanheule
2021-05-27 23:31     ` Linus Walleij
2021-06-02 19:02     ` Rob Herring
2021-05-23 22:34   ` [PATCH v3 4/6] mfd: Add RTL8231 core device Sander Vanheule
2021-05-24  8:02     ` Andy Shevchenko
2021-05-24  8:23       ` Sander Vanheule
2021-05-24 10:18         ` Andy Shevchenko
2021-05-24 11:41           ` Sander Vanheule
2021-05-23 22:34   ` [PATCH v3 5/6] pinctrl: Add RTL8231 pin control and GPIO support Sander Vanheule
2021-05-28  6:29     ` Michael Walle
2021-05-28  6:42       ` Sander Vanheule
2021-05-28  6:43         ` Michael Walle
2021-05-23 22:34   ` [PATCH v3 6/6] leds: Add support for RTL8231 LED scan matrix Sander Vanheule
2021-05-24 10:24     ` Andy Shevchenko
2021-05-24 12:04       ` Sander Vanheule
2021-05-24 12:47         ` Andy Shevchenko
2021-05-24 15:30           ` Sander Vanheule
2021-05-24  1:10   ` [PATCH v3 0/6] RTL8231 GPIO expander support Andrew Lunn
2021-05-24  7:53     ` Andy Shevchenko
2021-05-24 11:41       ` Sander Vanheule
2021-05-24 12:54         ` Andy Shevchenko
2021-05-24 15:03           ` Sander Vanheule
2021-05-24 16:30             ` Andy Shevchenko
2021-05-25 17:11               ` Andy Shevchenko
2021-05-25 18:00                 ` Sander Vanheule
2021-05-26 21:02                 ` Sander Vanheule [this message]
2021-05-27 10:38                   ` Andy Shevchenko
2021-05-27 10:41                     ` Hans de Goede
2021-05-24 15:20           ` Sander Vanheule
2021-05-28  6:37         ` Michael Walle
2021-05-30 16:19           ` Sander Vanheule
2021-05-30 16:51             ` Hans de Goede
2021-05-30 18:16               ` Andy Shevchenko
2021-05-30 21:22                 ` Michael Walle
2021-05-31  8:36                   ` Sander Vanheule
2021-05-31 10:02                     ` Michael Walle
     [not found]                       ` <CAHp75VfOrUBRQH1vrXEwHN4ZPojQfQju-_wp_3djZeozEaatug@mail.gmail.com>
2021-05-31 15:33                         ` [PATCH 0/5] " Sander Vanheule
2021-05-31 15:48                           ` Andy Shevchenko
2021-06-01 11:49                             ` Michael Walle
2021-06-01 15:24                               ` Andy Shevchenko
2021-06-02 20:20                                 ` Sander Vanheule
2021-06-01  9:59                 ` [PATCH v3 0/6] " Linus Walleij
2021-06-01 10:18                   ` Michael Walle
2021-06-01 10:51                     ` Linus Walleij
2021-06-01 11:41                       ` Michael Walle
2021-06-01 11:48                         ` Linus Walleij
2021-06-03 10:00 ` [PATCH v4 0/5] " Sander Vanheule
2021-06-03 10:00   ` [PATCH v4 1/5] dt-bindings: leds: Binding for RTL8231 scan matrix Sander Vanheule
2021-06-03 10:00   ` [PATCH v4 2/5] dt-bindings: mfd: Binding for RTL8231 Sander Vanheule
2021-06-03 10:00   ` [PATCH v4 3/5] mfd: Add RTL8231 core device Sander Vanheule
2021-06-03 10:58     ` Andy Shevchenko
2021-06-03 11:28       ` Sander Vanheule
2021-06-03 14:03         ` Andrew Lunn
2021-06-03 15:20           ` Sander Vanheule
2021-06-05 11:07       ` Sander Vanheule
2021-06-03 10:00   ` [PATCH v4 4/5] pinctrl: Add RTL8231 pin control and GPIO support Sander Vanheule
2021-06-03 10:18     ` Andy Shevchenko
2021-06-04 22:10     ` Linus Walleij
2021-06-03 10:00   ` [PATCH v4 5/5] leds: Add support for RTL8231 LED scan matrix Sander Vanheule
2021-06-03 11:01     ` Andy Shevchenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cbfba24a6206ec73ccc844da5d1331959e3f3520.camel@svanheule.net \
    --to=sander@svanheule.net \
    --cc=andrew@lunn.ch \
    --cc=andy.shevchenko@gmail.com \
    --cc=bgolaszewski@baylibre.com \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=lee.jones@linaro.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=michael@walle.cc \
    --cc=pavel@ucw.cz \
    --cc=rafael@kernel.org \
    --cc=robh+dt@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).