All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andy.shevchenko@gmail.com>
To: Sander Vanheule <sander@svanheule.net>
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: Mon, 22 Mar 2021 15:16:38 +0200	[thread overview]
Message-ID: <CAHp75VdPro54q9_hhdi8m+GkwYDqyvsUthBGjksk2LTkHeYJgA@mail.gmail.com> (raw)
In-Reply-To: <e89125c1ffb56f64c7c2037192e490d56ab12492.camel@svanheule.net>

On Fri, Mar 19, 2021 at 11:48 PM Sander Vanheule <sander@svanheule.net> wrote:
> 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:

...

> > > 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.

You mean that they are following the same rules as DIR/DATA/ISR. right?

> A-B-C-D means:  (A << 24) | (B << 16) | (C << 8) | D
> A-A-B-B means:  (A << 16) | B

If the above is true for unused registers, it's clearly hardware endianness.

You need special treatment for IMR, but in general it follows the
logic behind the others.

So, you need some kind of I/O accessors like
 read_u8_reg()
 write_u8_reg()
 read_u16_reg()
 write_u16_reg()

And depending on endianess of hardware to call proper set of them.

-- 
With Best Regards,
Andy Shevchenko

  reply	other threads:[~2021-03-22 13:18 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
2021-03-22 13:16                 ` Andy Shevchenko [this message]
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=CAHp75VdPro54q9_hhdi8m+GkwYDqyvsUthBGjksk2LTkHeYJgA@mail.gmail.com \
    --to=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=sander@svanheule.net \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.