drivers/tty/serial/Kconfig | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
This driver runs also on SoCs without a Tegra20 APB DMA controller (e.g.
Tegra234).
Remove the Kconfig dependency on TEGRA20_APB_DMA, and remove reference to
the APB DMA controller from the Kconfig help text.
Fixes: 60d2016a5161 ("arm64: tegra: Add Tegra234 GPCDMA device tree node")
Signed-off-by: Francesco Lavra <flavra@baylibre.com>
---
drivers/tty/serial/Kconfig | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 44427415a80d..6212a814fdb7 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -255,14 +255,13 @@ config SERIAL_SAMSUNG_CONSOLE
config SERIAL_TEGRA
tristate "NVIDIA Tegra20/30 SoC serial controller"
- depends on (ARCH_TEGRA && TEGRA20_APB_DMA) || COMPILE_TEST
+ depends on ARCH_TEGRA || COMPILE_TEST
select SERIAL_CORE
help
Support for the on-chip UARTs on the NVIDIA Tegra series SOCs
providing /dev/ttyTHS0, 1, 2, 3 and 4 (note, some machines may not
provide all of these ports, depending on how the serial port
- are enabled). This driver uses the APB DMA to achieve higher baudrate
- and better performance.
+ are enabled).
config SERIAL_TEGRA_TCU
tristate "NVIDIA Tegra Combined UART"
--
2.39.5
On Wed, Nov 26, 2025 at 10:07:59AM +0100, Francesco Lavra wrote: > This driver runs also on SoCs without a Tegra20 APB DMA controller (e.g. > Tegra234). > Remove the Kconfig dependency on TEGRA20_APB_DMA, and remove reference to > the APB DMA controller from the Kconfig help text. ... > help > Support for the on-chip UARTs on the NVIDIA Tegra series SOCs > providing /dev/ttyTHS0, 1, 2, 3 and 4 (note, some machines may not > provide all of these ports, depending on how the serial port > - are enabled). This driver uses the APB DMA to achieve higher baudrate > - and better performance. > + are enabled). I think this removes a good piece of information. Perhaps rephrase? This driver may use the APB DMA when available to achieve higher baudrate and better performance. -- With Best Regards, Andy Shevchenko
On Wed, 2025-11-26 at 13:20 +0200, Andy Shevchenko wrote: > On Wed, Nov 26, 2025 at 10:07:59AM +0100, Francesco Lavra wrote: > > This driver runs also on SoCs without a Tegra20 APB DMA controller > > (e.g. > > Tegra234). > > Remove the Kconfig dependency on TEGRA20_APB_DMA, and remove reference > > to > > the APB DMA controller from the Kconfig help text. > > ... > > > help > > Support for the on-chip UARTs on the NVIDIA Tegra series SOCs > > providing /dev/ttyTHS0, 1, 2, 3 and 4 (note, some machines > > may not > > provide all of these ports, depending on how the serial port > > - are enabled). This driver uses the APB DMA to achieve higher > > baudrate > > - and better performance. > > + are enabled). > > I think this removes a good piece of information. Perhaps rephrase? > > This driver may use the APB DMA when available to achieve > higher baudrate and better performance. I think this sentence would make it sound like the driver performs better if the APB DMA controller is available, but in reality the driver just uses the generic DMA API like most serial drivers, and there is nothing APB- specific in it. If another DMA controller (e.g. GPC on Tegra234) is available instead of the APB one, the serial peripheral will be just as fast.
On Wed, Nov 26, 2025 at 01:08:23PM +0100, Francesco Lavra wrote: > On Wed, 2025-11-26 at 13:20 +0200, Andy Shevchenko wrote: > > On Wed, Nov 26, 2025 at 10:07:59AM +0100, Francesco Lavra wrote: ... > > > help > > > Support for the on-chip UARTs on the NVIDIA Tegra series SOCs > > > providing /dev/ttyTHS0, 1, 2, 3 and 4 (note, some machines > > > may not > > > provide all of these ports, depending on how the serial port > > > - are enabled). This driver uses the APB DMA to achieve higher > > > baudrate > > > - and better performance. > > > + are enabled). > > > > I think this removes a good piece of information. Perhaps rephrase? > > > > This driver may use the APB DMA when available to achieve > > higher baudrate and better performance. > > I think this sentence would make it sound like the driver performs better > if the APB DMA controller is available, but in reality the driver just uses > the generic DMA API like most serial drivers, and there is nothing APB- > specific in it. If another DMA controller (e.g. GPC on Tegra234) is > available instead of the APB one, the serial peripheral will be just as > fast. OK. But this is not the case for Tegra234? Or is it and it uses DMA for UART? -- With Best Regards, Andy Shevchenko
On Wed, 2025-11-26 at 18:25 +0200, Andy Shevchenko wrote: > On Wed, Nov 26, 2025 at 01:08:23PM +0100, Francesco Lavra wrote: > > On Wed, 2025-11-26 at 13:20 +0200, Andy Shevchenko wrote: > > > On Wed, Nov 26, 2025 at 10:07:59AM +0100, Francesco Lavra wrote: > > ... > > > > > help > > > > Support for the on-chip UARTs on the NVIDIA Tegra series > > > > SOCs > > > > providing /dev/ttyTHS0, 1, 2, 3 and 4 (note, some > > > > machines > > > > may not > > > > provide all of these ports, depending on how the serial > > > > port > > > > - are enabled). This driver uses the APB DMA to achieve > > > > higher > > > > baudrate > > > > - and better performance. > > > > + are enabled). > > > > > > I think this removes a good piece of information. Perhaps rephrase? > > > > > > This driver may use the APB DMA when available to achieve > > > higher baudrate and better performance. > > > > I think this sentence would make it sound like the driver performs > > better > > if the APB DMA controller is available, but in reality the driver just > > uses > > the generic DMA API like most serial drivers, and there is nothing APB- > > specific in it. If another DMA controller (e.g. GPC on Tegra234) is > > available instead of the APB one, the serial peripheral will be just as > > fast. > > OK. But this is not the case for Tegra234? Or is it and it uses DMA for > UART? Yes, that is the case, Tegra234 has just a different DMA controller (TEGRA186_GPC_DMA), which is used by the UART driver as long as the relevant device tree node properties are in place.
On Wed, Nov 26, 2025 at 05:45:25PM +0100, Francesco Lavra wrote: > On Wed, 2025-11-26 at 18:25 +0200, Andy Shevchenko wrote: > > On Wed, Nov 26, 2025 at 01:08:23PM +0100, Francesco Lavra wrote: > > > On Wed, 2025-11-26 at 13:20 +0200, Andy Shevchenko wrote: > > > > On Wed, Nov 26, 2025 at 10:07:59AM +0100, Francesco Lavra wrote: ... > > > > > help > > > > > Support for the on-chip UARTs on the NVIDIA Tegra series > > > > > SOCs > > > > > providing /dev/ttyTHS0, 1, 2, 3 and 4 (note, some > > > > > machines > > > > > may not > > > > > provide all of these ports, depending on how the serial > > > > > port > > > > > - are enabled). This driver uses the APB DMA to achieve > > > > > higher > > > > > baudrate > > > > > - and better performance. > > > > > + are enabled). > > > > > > > > I think this removes a good piece of information. Perhaps rephrase? > > > > > > > > This driver may use the APB DMA when available to achieve > > > > higher baudrate and better performance. > > > > > > I think this sentence would make it sound like the driver performs > > > better > > > if the APB DMA controller is available, but in reality the driver just > > > uses > > > the generic DMA API like most serial drivers, and there is nothing APB- > > > specific in it. If another DMA controller (e.g. GPC on Tegra234) is > > > available instead of the APB one, the serial peripheral will be just as > > > fast. > > > > OK. But this is not the case for Tegra234? Or is it and it uses DMA for > > UART? > > Yes, that is the case, Tegra234 has just a different DMA controller > (TEGRA186_GPC_DMA), which is used by the UART driver as long as the > relevant device tree node properties are in place. Okay, with this it means that some generic statement like This driver may use the DMA when available to achieve higher baudrate and better performance. is too generic to be added. That said, I agree that you dropped the original one completely. FWIW, Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> -- With Best Regards, Andy Shevchenko
© 2016 - 2025 Red Hat, Inc.