[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMuHMdXKavD1JLTMRhF6grRchd9pwDd3oupPPCRDw1Can3nb=w@mail.gmail.com>
Date: Mon, 10 Jul 2023 16:12:03 +0200
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Prabhakar <prabhakar.csengg@...il.com>
Cc: Magnus Damm <magnus.damm@...il.com>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Linus Walleij <linus.walleij@...aro.org>,
linux-renesas-soc@...r.kernel.org, devicetree@...r.kernel.org,
linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-gpio@...r.kernel.org, Biju Das <biju.das.jz@...renesas.com>,
Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
Subject: Re: [RFC PATCH 1/4] pinctrl: renesas: rzg2l: Include pinmap in
RZG2L_GPIO_PORT_PACK() macro
Hi Prabhakar,
On Fri, Jun 30, 2023 at 2:05 PM Prabhakar <prabhakar.csengg@...il.com> wrote:
> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
>
> Currently we assume all the port pins are sequential ie always PX_0 to
> PX_n (n=1..7) exist, but on RZ/Five SoC we have additional pins P19_1 to
> P28_5 which have holes in them, for example only one pin on port19 is
> available and that is P19_1 and not P19_0.
>
> So to handle such cases include pinmap for each port which would indicate
> the pin availability on each port. With this we also get additional pin
> validation, for example on the RZ/G2L SOC P0 has two pins P0_1 and P0_0
> but with DT/SYSFS could use the P0_2-P0_7.
>
> While at it, update rzg2l_validate_gpio_pin() to use the port pinmap to
> validate the gpio pin.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
> ---
> drivers/pinctrl/renesas/pinctrl-rzg2l.c | 167 ++++++++++++------------
> 1 file changed, 86 insertions(+), 81 deletions(-)
>
> diff --git a/drivers/pinctrl/renesas/pinctrl-rzg2l.c b/drivers/pinctrl/renesas/pinctrl-rzg2l.c
> index 9511d920565e..a0c2e585e765 100644
> --- a/drivers/pinctrl/renesas/pinctrl-rzg2l.c
> +++ b/drivers/pinctrl/renesas/pinctrl-rzg2l.c
> @@ -67,10 +67,12 @@
> PIN_CFG_FILCLKSEL)
>
> /*
> - * n indicates number of pins in the port, a is the register index
> - * and f is pin configuration capabilities supported.
> + * m indicates the bitmap of supported pins, n indicates number
> + * of pins in the port, a is the register index and f is pin
> + * configuration capabilities supported.
> */
> -#define RZG2L_GPIO_PORT_PACK(n, a, f) (((n) << 28) | ((a) << 20) | (f))
> +#define RZG2L_GPIO_PORT_PACK(m, n, a, f) ((UL(m) << 32) | (UL(n) << 28) | ((a) << 20) | (f))
Do we actually need 20 bits for the "f" field?
As Biju already commented, "n" can be derived from "m".
If "f" can be shrunk, we might fit everything in 32 bits.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Powered by blists - more mailing lists