On 19/11/22 03:45, Nishanth Menon wrote:
On 15:08-20221118, Andrew Davis wrote:
On 11/18/22 1:27 PM, Nishanth Menon wrote:
On 12:15-20221118, Andrew Davis wrote:
I don't see either of those addressed in that thread, only that
the aliases should go in the .dts files and be trimmed, nothing
Key is trimmed to what the system and ecosystem needs.
stops us from:
chosen {
stdout-path = "serial10:115200n8";
};
aliases {
serial10 = &main_uart8;
};
Do we need 10 serial aliases? There are'nt 10 serial ports exposed in
j782s2. ok - lets say we do this, then: [1] is needed to boot? but why
do we need to do that for all armv8 platforms when aliases allows us
Why do we need SERIAL_8250_NR_UARTS at all, might be a better question.
These should be dynamically allocated if the number goes over the
default count imposed by the TTY framework. Maybe folks are still a
bit too afraid to touch the TTY subsystem core, I don't blame them..
to trim it to just the 3 or 4 serial ports the platform really needs
That + being able to use the convention that serial2 is always linux
console, is'nt that a good thing? Hence recommending to just expose the
serialports as aliases to exactly what we need while keeping serial2 as
the linux console (which in this case happens to be main_uart8 - example
as j721s2 does).
"serial2 as the linux console" is *not* a convention, we just don't want to
fix up our bootloader/userspace to actually reason about what serial ports to
put logins on. Why not make ttyS10 the default, or ttyS666, it doesn't solve
your multi-distro issue either way since they usually only start a login on
ttyS0, console=, and/or the first virtual tty. Never on ttyS2. So you are
hacking up DT for a solution that doesn't do what you want in the end.
ttyS2 is an accidental convention not a "by design" or definition
convention. I suspect we ended up here from old OMAP days - all
platforms in k3 ended up with ttyS2. In hindsight, if I had to do it
by design, I would probably have picked ttyS0, well, we did'nt.
$ git grep stdout-path arch/arm/boot/dts|grep serial|cut -d '=' -f 2|cut -d ':' -f1|grep -v '&'|sort|uniq -c
379 "serial0
21 "serial1
33 "serial2
13 "serial3
1 "/slaves@3e000000/serial@0
$ git grep stdout-path arch/arm64/boot/dts|grep serial|cut -d '=' -f 2|cut -d ':' -f1|grep -v '&'|sort|uniq -c
245 "serial0
17 "serial0";
7 "serial1
49 "serial2
3 "serial3
2 "serial4
2 "serial5
2 "serial6
$ git grep stdout-path arch/arm64/boot/dts/ti|grep serial|cut -d '=' -f 2|cut -d ':' -f1|grep -v '&'|sort|uniq -c
8 "serial2
1 "serial3
I don't buy the argument here for 1-1 mapping of aliased serial
instances to instances - why should main_uart8 be ttyS10, why not
ttyS8 (it is equally valid - why was it called uart8?).. That mapping
is just a convention we are choosing to create.
The iot2050 ecosystem picked ttyS3 as the linux console for reasons of
that ecosystem. K3 so far has selected ttyS2 as the convention for
console - no matter where the serial instances have been located.
I want to maintain consistency of existing TI platforms here without
needing to shove a dozen things on existing users (yes j78-evm is a new
board, but it is within the existing k3 s/w ecosystem and yes, getty,
systemd etc are smarter today than once upon a time)
So, given TI K3 history does'nt follow rest of the non-TI instances
unfortunately - and I am going to put my foot down here - serial8 or 10
is "fake" anyways - rationalization can be made in different ways. So
pushing for one over the other is not something I will entertain.
From usage model point of view - serial0 will be the best candidate as
console followed by serial2 (purely statistically speaking). In K3
context, it is just serial2 in TI board ecosystem.
That is a discussion for pros and cons - Open to hearing opinions.
Unless I hear 1000% strong reasons with _backing data_ - not an
subjective "it is correct thing to do" - why we'd want to move TI
board ecosystem (including all the pains of bootloader combinations
etc) switch over to ttyS0[1], having a mix and churn for the s/w
ecosystem of having to deal with ttyS0 and ttyS2 nodes in arm64/dts/ti
at least for the TI board ecosystem.. I cant see why i want to put the
ecosystem through another churn on consoles.. But, fine, i will keep
my ears open. If there are no strong arguments with _data_, then we
stick with serial2 and y'all can curse me for another decade+ for that
call :)
[1] I have'nt forgotten ttyO2 to ttyS2 transition of OMAP
https://duckduckgo.com/?q=ttyO2+to+ttyS2+omap
Hi all,
I agree that there could be different standpoints on the aliasing of serial,
and the current way might not be the right way, but we have been using that
a quite long without any issues. (All K3 platforms use the same serial2 for
console).
IMO, if needed, the right way to change to other serial would be to:
1. Change all the serial aliases across K3 platforms, along with other
serial dependencies in userspace.
2. And have that as a separate patch series, i.e. a series that changes
all the
incorrect aliases across K3 platforms. And this J784S4 patch series is
not that
one.
Coming to a consensus would take time, lets do that separately and no
point blocking
this series for it. All the previous platforms use the serial2 for
console uart
and I will post my next series with the same. If there is a need to
change the serial
aliasing, change it across all previous platforms in a separate patch
series.
--
Thanks and regards,
Apurva Nandan,
Texas Instruments India.
