| Message ID | 20231201171544.1901-1-francesco@dolcini.it (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v2] arm64: defconfig: increase SERIAL_8250_NR_UARTS | expand |
On 18:15-20231201, Francesco Dolcini wrote: > Increase CONFIG_SERIAL_8250_NR_UARTS from 4 to 8, the current legacy value > is not adequate for embedded systems that use SoCs where it's common to > have a large number of serial ports. > > No need to change CONFIG_SERIAL_8250_RUNTIME_UARTS, see commit 9d86719f8769 > ("serial: 8250: Allow using ports higher than SERIAL_8250_RUNTIME_UARTS"). > > The need to increase this value was noticed while working with Toradex > Verdin AM62, this board has 4 serial UART instances available to the user > plus an internal one that is connected to a Bluetooth module. Without this > change the fifth UART connected to the BT module is not instantiated and BT > is not working. > > Instead of increasing the number to the bare minimum (5) that would be > required to solve this specific issue, we increase this to 8 which seems a > more reasonable number to have in the defconfig and should cover more valid > use cases. To address Arnd's concern on size increase, it will be good to add: --- With this change kernel image increases by ~3.2k. bloat-o-meter summary: add/remove: 1/1 grow/shrink: 7/0 up/down: 3220/-8 (3212) --- Full bloat-o-meter report: aarch64-none-linux-gnu-gcc (11.3.1 20220712) $ ./scripts/bloat-o-meter ./vmlinux.old vmlinux add/remove: 1/1 grow/shrink: 7/0 up/down: 3220/-8 (3212) Function old new delta serial8250_ports 3136 6272 +3136 serial8250_register_8250_port 1176 1208 +32 serial8250_remove 120 136 +16 serial8250_unregister_port 288 296 +8 serial8250_suspend 120 128 +8 serial8250_setup_port 212 220 +8 e843419@0d28_000102dd_3a64 - 8 +8 serial8250_init 468 472 +4 e843419@0c0a_0000eb9e_8cc 8 - -8 Total: Before=28756614, After=28759826, chg +0.01% > > Cc: Tony Lindgren <tony@atomide.com> > Reviewed-by: Tony Lindgren <tony@atomide.com> > Signed-off-by: Francesco Dolcini <francesco@dolcini.it> > --- > arch/arm64/configs/defconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig > index b60aa1f89343..ecd365cd1d87 100644 > --- a/arch/arm64/configs/defconfig > +++ b/arch/arm64/configs/defconfig > @@ -448,6 +448,7 @@ CONFIG_SERIO_AMBAKMI=y > CONFIG_LEGACY_PTY_COUNT=16 > CONFIG_SERIAL_8250=y > CONFIG_SERIAL_8250_CONSOLE=y > +CONFIG_SERIAL_8250_NR_UARTS=8 > CONFIG_SERIAL_8250_EXTENDED=y > CONFIG_SERIAL_8250_SHARE_IRQ=y > CONFIG_SERIAL_8250_BCM2835AUX=y > -- > 2.39.2 >
On Fri, Dec 01, 2023 at 01:19:58PM -0600, Nishanth Menon wrote: > On 18:15-20231201, Francesco Dolcini wrote: > > Increase CONFIG_SERIAL_8250_NR_UARTS from 4 to 8, the current legacy value > > is not adequate for embedded systems that use SoCs where it's common to > > have a large number of serial ports. > > > > No need to change CONFIG_SERIAL_8250_RUNTIME_UARTS, see commit 9d86719f8769 > > ("serial: 8250: Allow using ports higher than SERIAL_8250_RUNTIME_UARTS"). > > > > The need to increase this value was noticed while working with Toradex > > Verdin AM62, this board has 4 serial UART instances available to the user > > plus an internal one that is connected to a Bluetooth module. Without this > > change the fifth UART connected to the BT module is not instantiated and BT > > is not working. > > > > Instead of increasing the number to the bare minimum (5) that would be > > required to solve this specific issue, we increase this to 8 which seems a > > more reasonable number to have in the defconfig and should cover more valid > > use cases. > > To address Arnd's concern on size increase, it will be good to add: I can and I will add it in a v3 - it takes less time to do it than reply to this email and thanks for taking the time to provide the actual data. With that said my understanding is that the goal of the arm64 defconfig is to enable the supported arm64 hardware and the related kernel development. It's not supposed to be a minimal config in size nor an optimal configuration from the performance point of view. It's a single configuration that includes support for each and every platform [1] supported by Linux arm64 ... To me Arnd was just stating a fact, not raising a concern that was supposed to be addressed (just correct me if I'm wrong, of course). [1] well, apart AMD Pensando and Bitmain, at the moment, but you get the point, I'm sure ;-). > --- > With this change kernel image increases by ~3.2k. bloat-o-meter summary: > add/remove: 1/1 grow/shrink: 7/0 up/down: 3220/-8 (3212) > --- Francesco
On 20:52-20231201, Francesco Dolcini wrote: > On Fri, Dec 01, 2023 at 01:19:58PM -0600, Nishanth Menon wrote: > > On 18:15-20231201, Francesco Dolcini wrote: > > > Increase CONFIG_SERIAL_8250_NR_UARTS from 4 to 8, the current legacy value > > > is not adequate for embedded systems that use SoCs where it's common to > > > have a large number of serial ports. > > > > > > No need to change CONFIG_SERIAL_8250_RUNTIME_UARTS, see commit 9d86719f8769 > > > ("serial: 8250: Allow using ports higher than SERIAL_8250_RUNTIME_UARTS"). > > > > > > The need to increase this value was noticed while working with Toradex > > > Verdin AM62, this board has 4 serial UART instances available to the user > > > plus an internal one that is connected to a Bluetooth module. Without this > > > change the fifth UART connected to the BT module is not instantiated and BT > > > is not working. > > > > > > Instead of increasing the number to the bare minimum (5) that would be > > > required to solve this specific issue, we increase this to 8 which seems a > > > more reasonable number to have in the defconfig and should cover more valid > > > use cases. > > > > To address Arnd's concern on size increase, it will be good to add: > > I can and I will add it in a v3 - it takes less time to do it than reply to > this email and thanks for taking the time to provide the actual data. > > With that said my understanding is that the goal of the arm64 defconfig is > to enable the supported arm64 hardware and the related kernel development. > It's not supposed to be a minimal config in size nor an optimal > configuration from the performance point of view. It's a single > configuration that includes support for each and every platform [1] > supported by Linux arm64 ... > > To me Arnd was just stating a fact, not raising a concern that was supposed > to be addressed (just correct me if I'm wrong, of course). > > [1] well, apart AMD Pensando and Bitmain, at the moment, but you get the > point, I'm sure ;-). > Hehe, thanks Francesco. Arnd, my memory was a bit right on the topic though.. .. I think we had gone down a similar road before in trying to increase the number of 8250 UARTs [1] but without this strong a reason.. Been a while, I think our v3 is much stronger case now. [1] https://lore.kernel.org/all/CAK8P3a2VSBvOn1o+q1PYZaQ6LS9U4cz+DZGuDbisHkwNs2dAAw@mail.gmail.com/#t
On Sat, Dec 2, 2023, at 00:26, Nishanth Menon wrote: > On 20:52-20231201, Francesco Dolcini wrote: >> On Fri, Dec 01, 2023 at 01:19:58PM -0600, Nishanth Menon wrote: >> > On 18:15-20231201, Francesco Dolcini wrote: >> To me Arnd was just stating a fact, not raising a concern that was supposed >> to be addressed (just correct me if I'm wrong, of course). >> >> [1] well, apart AMD Pensando and Bitmain, at the moment, but you get the >> point, I'm sure ;-). >> > > Hehe, thanks Francesco. > > Arnd, my memory was a bit right on the topic though.. .. I think we > had gone down a similar road before in trying to increase the number > of 8250 UARTs [1] but without this strong a reason.. Been a while, I > think our v3 is much stronger case now. > > [1] > https://lore.kernel.org/all/CAK8P3a2VSBvOn1o+q1PYZaQ6LS9U4cz+DZGuDbisHkwNs2dAAw@mail.gmail.com/#t I think in that case the problem was that the aliases were done in the .dtsi file but enabled in the board specific .dts, which would be pointless and confusing. If we have a board that actually wires up more uarts to connectors or devices, can clearly raise the compile time limit to whatever that needs. Arnd
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index b60aa1f89343..ecd365cd1d87 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -448,6 +448,7 @@ CONFIG_SERIO_AMBAKMI=y CONFIG_LEGACY_PTY_COUNT=16 CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y +CONFIG_SERIAL_8250_NR_UARTS=8 CONFIG_SERIAL_8250_EXTENDED=y CONFIG_SERIAL_8250_SHARE_IRQ=y CONFIG_SERIAL_8250_BCM2835AUX=y
Increase CONFIG_SERIAL_8250_NR_UARTS from 4 to 8, the current legacy value is not adequate for embedded systems that use SoCs where it's common to have a large number of serial ports. No need to change CONFIG_SERIAL_8250_RUNTIME_UARTS, see commit 9d86719f8769 ("serial: 8250: Allow using ports higher than SERIAL_8250_RUNTIME_UARTS"). The need to increase this value was noticed while working with Toradex Verdin AM62, this board has 4 serial UART instances available to the user plus an internal one that is connected to a Bluetooth module. Without this change the fifth UART connected to the BT module is not instantiated and BT is not working. Instead of increasing the number to the bare minimum (5) that would be required to solve this specific issue, we increase this to 8 which seems a more reasonable number to have in the defconfig and should cover more valid use cases. Cc: Tony Lindgren <tony@atomide.com> Reviewed-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Francesco Dolcini <francesco@dolcini.it> --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+)