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

[Zev Weiss]

On Mon, Dec 13, 2021 at 07:29:48PM PST, Ryan Chen wrote:
>Hello,
>> -----Original Message-----
>> From: Zev Weiss <zev at bewilderbeest.net>
>> Sent: Tuesday, December 14, 2021 11:21 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:39:17PM PST, Ryan Chen wrote:
>> >Hello,
>> >
>> >> -----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...
>>
>> https://github.com/openbmc/u-boot/blob/a570745a1a836e351bd4b1131f23a4
>> fa5013d6dd/arch/arm/dts/ast2400.dtsi#L1130-L1133
>>
>> and
>>
>> https://github.com/openbmc/u-boot/blob/a570745a1a836e351bd4b1131f23a4
>> fa5013d6dd/arch/arm/dts/ast2400.dtsi#L1375-L1378
>>
>The following is my point.
>https://github.com/openbmc/u-boot/blob/a570745a1a836e351bd4b1131f23a4fa5013d6dd/arch/arm/dts/ast2400.dtsi#L3
>

I'm afraid I don't follow...how does it being copied from the Linux 
kernel device tree affect whether or not we should group these two or 
keep them separate?


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