[PATCH u-boot v2019.04-aspeed-openbmc] pinctrl: ast2400: add support for TXD3/RXD3 pins

Zev Weiss zev at bewilderbeest.net
Tue Dec 14 14:20:32 AEDT 2021

On Mon, Dec 13, 2021 at 05:39:17PM PST, Ryan Chen wrote:
>> -----Original Message-----
>> From: Zev Weiss <zev at bewilderbeest.net>
>> Sent: Tuesday, December 14, 2021 9:33 AM
>> To: Ryan Chen <ryan_chen at aspeedtech.com>
>> Cc: openbmc at lists.ozlabs.org; Joel Stanley <joel at jms.id.au>; ChiaWei Wang
>> <chiawei_wang at aspeedtech.com>
>> Subject: Re: [PATCH u-boot v2019.04-aspeed-openbmc] pinctrl: ast2400: add
>> support for TXD3/RXD3 pins
>> On Mon, Dec 13, 2021 at 05:22:52PM PST, Ryan Chen wrote:
>> >Hello,
>> >	You may need claim for function group for link, not for pin link.
>> >	Ex.
>> >	static struct aspeed_sig_desc uart3_link[] = {
>> >		{ 0x80, BIT(22), 0},
>> >		{ 0x80, BIT(23), 0},
>> >	}
>> >
>> >	ast2400_groups[] = {
>> >	{ "UART3", 2, uart3_link },
>> >Ryan
>> Hi Ryan,
>> That possibility occurred to me, but the existing function/group names in
>> arch/arm/dts/ast2400.dtsi (lines 1130-1133 and 1375-1378) made me think
>> they should be separate.
>This device tree is copied from Linux kernel.
>> I'm certainly not an expert on pinctrl stuff
>> though...is there some other existing logic or mechanism to link a "UART3" to
>> the separate "TXD3" and "RXD3" in the device tree?
>There is no separate in u-boot device tree.

Perhaps we're misunderstanding each other...




look fairly separate to me?

>May I know why you need separate?

In my particular case I don't need these two to be separate, but it 
seems conceivable that there might be other cases that would require a 
different set of signals to be enabled for a generic "UART3" group -- 
possibly more (sideband signals like CTS and such), or perhaps even 
fewer (e.g. if you had an output-only UART3 just for logging or 
something, and only needed TXD3 for that, but still wanted to use pin 
B14 as GPIOE7 instead of RXD3).  Keeping them separate seems like it 
leaves things as flexible as possible, avoiding imposing any artificial 


More information about the openbmc mailing list