From: Sander Vanheule <sander@svanheule.net>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: "open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
devicetree <devicetree@vger.kernel.org>,
Linus Walleij <linus.walleij@linaro.org>,
Bartosz Golaszewski <bgolaszewski@baylibre.com>,
Rob Herring <robh+dt@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Marc Zyngier <maz@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Bert Vermeulen <bert@biot.com>
Subject: Re: [PATCH v2 2/2] gpio: Add Realtek Otto GPIO support
Date: Fri, 19 Mar 2021 22:48:00 +0100 [thread overview]
Message-ID: <e89125c1ffb56f64c7c2037192e490d56ab12492.camel@svanheule.net> (raw)
In-Reply-To: <CAHp75Vf=-WdJ3U6o1G-Xi4W7tkCzyij0FD3MNY1q0x6bkimxow@mail.gmail.com>
On Fri, 2021-03-19 at 23:24 +0200, Andy Shevchenko wrote:
> On Fri, Mar 19, 2021 at 11:20 PM Sander Vanheule <
> sander@svanheule.net> wrote:
> > On Fri, 2021-03-19 at 19:57 +0200, Andy Shevchenko wrote:
> > > On Fri, Mar 19, 2021 at 5:51 PM Sander Vanheule
> > > <sander@svanheule.net> wrote:
> > > > On Wed, 2021-03-17 at 15:08 +0200, Andy Shevchenko wrote:
> > > > > On Mon, Mar 15, 2021 at 11:11 PM Sander Vanheule <
> > > > > sander@svanheule.net> wrote:
>
> ...
>
> > > > > > + return swab32(readl(ctrl->base +
> > > > > > REALTEK_GPIO_REG_ISR));
> > > > >
> > > > > Why swab?! How is this supposed to work on BE CPUs?
> > > > > Ditto for all swabXX() usage.
> > > >
> > > > My use of swab32/swahw32 has little to do with the CPU being BE
> > > > or
> > > > LE,
> > > > but more with the register packing in the GPIO peripheral.
> > > >
> > > > The supported SoCs have port layout A-B-C-D in the registers,
> > > > where
> > > > firmware built with Realtek's SDK always denotes A0 as the first
> > > > GPIO
> > > > line. So bit 24 in a register has the value for A0 (with the
> > > > exception
> > > > of the IMR register).
> > > >
> > > > I wrote these wrapper functions to be able to use the BIT() macro
> > > > with
> > > > the GPIO line number, similar to how gpio-mmio uses ioread32be()
> > > > when
> > > > the BGPIOF_BIG_ENDIAN_BYTE_ORDER flag is used.
> > > >
> > > > For the IMR register, port A again comes first, but is now 16
> > > > bits
> > > > wide
> > > > instead of 8, with A0 at bits 16:17. That's why swahw32 is used
> > > > for
> > > > this register.
> > > >
> > > > On the currently unsupported RTL9300-series, the port layout is
> > > > reversed: D-C-B-A. GPIO line A0 is then at bit 0, so the swapping
> > > > functions won't be required. When support for this alternate port
> > > > layout is added, some code will need to be added to differentiate
> > > > between the two cases.
> > >
> > > Yes, you have different endianess on the hardware level, why not to
> > > use the proper accessors (with or without utilization of the above
> > > mentioned BGPIOF_BIG_ENDIAN_BYTE_ORDER)?
> >
> > The point I was trying to make, is that it isn't an endianess issue.
> > I
> > shouldn't have used a register with single byte values to try to
> > illustrate that.
> >
> > Consider instead the interrupt masking registers. To write the IMR
> > bits
> > for port A (GPIO 0-7), a 16-bit value must be written. This value
> > (e.g.
> > u16 port_a_imr) is always BE, independent of the packing order of the
> > ports in the registers:
> >
> > // On RTL8380: port A is in the upper word
> > writew(port_a_imr, base + OFFSET_IMR_AB);
> >
> > // On RTL9300: port A is in the lower word
> > writew(port_a_imr, base + OFFSET_IMR_AB + 2);
> >
> > I want the low GPIO lines to be in the lower half-word, so I can
> > manipulate GPIO lines 0-15 with simple mask and shift operations.
> >
> > It just so happens, that all registers needed by bgpio_init contain
> > single-byte values. With BGPIO_BIG_ENDIAN_BYTE_ORDER the port order
> > is
> > reversed as required, but it's a bit of a misnomer here.
>
> How many registers (per GPIO / port) do you have?
> Can you list them and show endianess of the data for each of them and
> for old and new hardware (something like a 3 column table)?
Each GPIO bank, with 32 GPIO lines, consists of four 8-line ports.
There are seven registers per port, but only five are used:
| | Data | RTL8380 | RTL9300
Reg | Offset | type | byte order | byte order
-------+--------+---------+------------+-----------
DIR | 0x08 | 4 * u8 | A-B-C-D | D-C-B-A
DATA | 0x0C | 4 * u8 | A-B-C-D | D-C-B-A
ISR | 0x10 | 4 * u8 | A-B-C-D | D-C-B-A
IMR_AB | 0x14 | 2 * u16 | A-A-B-B | B-B-A-A
IMR_CD | 0x18 | 2 * u16 | C-C-D-D | D-D-C-C
The unused other registers are all 4*u8.
A-B-C-D means: (A << 24) | (B << 16) | (C << 8) | D
A-A-B-B means: (A << 16) | B
--
Best,
Sander
next prev parent reply other threads:[~2021-03-19 21:48 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-15 8:23 [PATCH 0/2] Add Realtek Otto GPIO support Sander Vanheule
2021-03-15 8:23 ` [PATCH 1/2] dt-bindings: gpio: Binding for Realtek Otto GPIO Sander Vanheule
2021-03-15 15:01 ` Linus Walleij
2021-03-15 8:23 ` [PATCH 2/2] gpio: Add Realtek Otto GPIO support Sander Vanheule
2021-03-15 15:10 ` Linus Walleij
2021-03-15 19:09 ` Sander Vanheule
2021-03-15 19:08 ` [PATCH v2 0/2] " Sander Vanheule
2021-03-15 19:08 ` [PATCH v2 1/2] dt-bindings: gpio: Binding for Realtek Otto GPIO Sander Vanheule
2021-03-24 18:29 ` Rob Herring
2021-03-15 19:08 ` [PATCH v2 2/2] gpio: Add Realtek Otto GPIO support Sander Vanheule
2021-03-17 13:08 ` Andy Shevchenko
2021-03-19 15:51 ` Sander Vanheule
2021-03-19 17:57 ` Andy Shevchenko
2021-03-19 21:20 ` Sander Vanheule
2021-03-19 21:24 ` Andy Shevchenko
2021-03-19 21:48 ` Sander Vanheule [this message]
2021-03-22 13:16 ` Andy Shevchenko
2021-03-24 21:22 ` [PATCH v3 0/2] " Sander Vanheule
2021-03-24 21:22 ` [PATCH v3 1/2] dt-bindings: gpio: Binding for Realtek Otto GPIO Sander Vanheule
2021-03-24 21:22 ` [PATCH v3 2/2] gpio: Add Realtek Otto GPIO support Sander Vanheule
2021-03-24 21:29 ` Sander Vanheule
2021-03-26 12:03 ` [PATCH v4 0/2] " Sander Vanheule
2021-03-26 12:03 ` [PATCH v4 1/2] dt-bindings: gpio: Binding for Realtek Otto GPIO Sander Vanheule
2021-03-27 18:16 ` Rob Herring
2021-03-26 12:03 ` [PATCH v4 2/2] gpio: Add Realtek Otto GPIO support Sander Vanheule
2021-03-26 18:19 ` Andy Shevchenko
2021-03-26 21:11 ` Sander Vanheule
2021-03-29 10:26 ` Andy Shevchenko
2021-03-29 17:28 ` Sander Vanheule
2021-03-30 10:14 ` Andy Shevchenko
2021-03-30 15:26 ` [PATCH v5 0/2] " Sander Vanheule
2021-03-30 15:26 ` [PATCH v5 1/2] dt-bindings: gpio: Binding for Realtek Otto GPIO Sander Vanheule
2021-03-30 15:26 ` [PATCH v5 2/2] gpio: Add Realtek Otto GPIO support Sander Vanheule
2021-03-30 16:43 ` Andy Shevchenko
2021-03-30 17:48 ` [PATCH v6 0/2] " Sander Vanheule
2021-03-30 17:48 ` [PATCH v6 1/2] dt-bindings: gpio: Binding for Realtek Otto GPIO Sander Vanheule
2021-03-30 17:48 ` [PATCH v6 2/2] gpio: Add Realtek Otto GPIO support Sander Vanheule
2021-03-31 7:49 ` [PATCH v6 0/2] " Bartosz Golaszewski
2021-03-31 8:11 ` Sander Vanheule
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=e89125c1ffb56f64c7c2037192e490d56ab12492.camel@svanheule.net \
--to=sander@svanheule.net \
--cc=andy.shevchenko@gmail.com \
--cc=bert@biot.com \
--cc=bgolaszewski@baylibre.com \
--cc=devicetree@vger.kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@kernel.org \
--cc=robh+dt@kernel.org \
--cc=tglx@linutronix.de \
/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).