[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID:
<3e88618470fa4f2ca15ba868dcecb1d3OSQPR06MB7252F20C7715CD90F0DE282F8B8DA@OSQPR06MB7252.apcprd06.prod.outlook.com>
Date: Mon, 19 Jan 2026 02:39:51 +0000
From: Billy Tsai <billy_tsai@...eedtech.com>
To: Andrew Jeffery <andrew@...econstruct.com.au>, Tony Lindgren
<tony@...mide.com>, Haojian Zhuang <haojian.zhuang@...aro.org>, Linus Walleij
<linusw@...nel.org>
CC: "linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>, "linux-omap@...r.kernel.org"
<linux-omap@...r.kernel.org>, "linux-gpio@...r.kernel.org"
<linux-gpio@...r.kernel.org>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>, BMC-SW <BMC-SW@...eedtech.com>
Subject: Re: [PATCH 0/3] pinctrl: single: bit-per-mux DT flexibility, probe
robustness, and consistent pinconf offsets
> > This series updates pinctrl-single to behave more predictably on
> > bit-per-mux platforms by making its DT interface more flexible, its probe
> > path more tolerant of pre-reserved resources, and its pin configuration
> > register addressing consistent with pinmux.
> Can you provide some more context here? For instance, this is motivated
> by the AST2700 - can you talk a bit more about why its design needs
> these changes?
> > It extends the driver to accept a per-pin <pin_index func_sel> style
> > description for bit-per-mux users while keeping the existing
> > pinctrl-single,bits binding as the preferred input when available. It also
> > relaxes probe failure when the I/O memory region cannot be reserved
> > exclusively, allowing initialization to proceed with a warning on systems
> > where that region is already reserved.
> >
> Can you unpack what's going on here in the context of the target soc?
Hi Andrew,
This series is mainly extending pinctrl-single to match how AST2700 uses the
pinmux and pinconf registers. There are three parts:
1. Per-pin DT binding for bit-per-mux
In the current driver, bit-per-mux users can only describe pinmux via
pinctrl-single,bits (<offset, value, mask>). On AST2700 the pinmux register
layout is contiguous per pin:
pin 0 maps to 0x400[3:0], pin 1 maps to 0x400[7:4], pin 2 maps to 0x400[11:8], and so on.
For that layout, describing each pin by <pin_index func_sel> is more direct and readable
than crafting offset/mask/value tuples.
Example:
pinctrl-single,pins = <
0 2 // pin 0 to function 2
1 3 // pin 1 to function 3
2 0 // pin 2 to function 0
>;
This change lets the driver accept that per-pin encoding while still
preferring the existing pinctrl-single,bits binding for compatibility.
2. Unify pinconf offset mapping with pinmux
Today pinconf offset calculation assumes a linear per-register width even if
bit-per-mux/function-mask is in use. On AST2700, pinconf follows the same
bit-per-pin layout as pinmux. For example,
drive strength: pin 0 at 0x4c0[1:0], pin 1 at 0x4c0[3:2], etc.
Pulldown: pin 0 at 0x480[0], pin 1 at 0x480[1], etc.
Unifying pinconf offset mapping with the pinmux logic makes the behavior correct
and easier to understand.
3. Probe with busy memory region
On AST2700 boards the SCU/pinctrl registers are often reserved in the DT by
a top-level “syscon” node or by firmware. devm_request_mem_region() returns
-EBUSY even though the region is valid and should be shared. Without this
change, pinctrl-single fails to probe and all pinmux setup is lost. The patch
just downgrades that case to a warning and continues.
Thanks
Best regards,
Billy Tsai
Powered by blists - more mailing lists