* [RFC PATCH 0/6] arm64: Initial support Texas Instrument's AM654 Platform
@ 2018-06-05 6:01 ` Nishanth Menon
0 siblings, 0 replies; 31+ messages in thread
From: Nishanth Menon @ 2018-06-05 6:01 UTC (permalink / raw)
To: Santosh Shilimkar, Will Deacon, Catalin Marinas,
Greg Kroah-Hartman, Mark Rutland, Rob Herring
Cc: linux-serial, linux-kernel, devicetree, linux-arm-kernel,
Tony Lindgren, Vignesh R, Tero Kristo, Russell King,
Sudeep Holla, Nishanth Menon
Hi,
The following series enables support for newest addition in TI's SoC
portfolio - AM654 SoC.
The series is an RFC based off next-20180604 and will post formally once
v4.18-rc1 is available.
The series (part 1 of 4) is available here:
https://github.com/nmenon/linux-2.6-playground/commits/upstream/next-20180604/k3-1-am6-base
Full Boot log is available here: https://pastebin.ubuntu.com/p/vWCzMKtBCW/
The AM654 SoC is a lead device of the K3 Multicore SoC architecture
platform, targeted for broad market and industrial control with aim to
meet the complex processing needs of modern embedded products.
The Linux development follows closely the 66AK2G SoC model in aarch64.
See AM65x Technical Reference Manual (SPRUID7, April 2018)
for further details: http://www.ti.com/lit/pdf/spruid7
Lokesh Vutla (1):
serial: 8250_omap: Make 8250_omap driver driver depend on ARCH_K3
Nishanth Menon (5):
Documentation: arm: ti: Add bindings for AM654 SoC
arm64: Add support for TI's K3 Multicore SoC architecture
serial: 8250_omap: Add support for AM654 UART controller
arm64: dts: ti: Add Support for AM654 SoC
arm64: dts: ti: Add support for AM654 EVM base board
Documentation/devicetree/bindings/arm/ti/k3.txt | 33 +++++
.../devicetree/bindings/serial/omap_serial.txt | 1 +
MAINTAINERS | 9 ++
arch/arm64/Kconfig.platforms | 7 +
arch/arm64/boot/dts/Makefile | 1 +
arch/arm64/boot/dts/ti/Makefile | 9 ++
arch/arm64/boot/dts/ti/k3-am6.dtsi | 144 +++++++++++++++++++++
arch/arm64/boot/dts/ti/k3-am654-base-board.dts | 40 ++++++
arch/arm64/boot/dts/ti/k3-am654.dtsi | 117 +++++++++++++++++
drivers/soc/ti/Kconfig | 14 ++
drivers/tty/serial/8250/8250_omap.c | 1 +
drivers/tty/serial/8250/Kconfig | 2 +-
12 files changed, 377 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/arm/ti/k3.txt
create mode 100644 arch/arm64/boot/dts/ti/Makefile
create mode 100644 arch/arm64/boot/dts/ti/k3-am6.dtsi
create mode 100644 arch/arm64/boot/dts/ti/k3-am654-base-board.dts
create mode 100644 arch/arm64/boot/dts/ti/k3-am654.dtsi
--
2.15.1
^ permalink raw reply [flat|nested] 31+ messages in thread
* [RFC PATCH 0/6] arm64: Initial support Texas Instrument's AM654 Platform
@ 2018-06-05 6:01 ` Nishanth Menon
0 siblings, 0 replies; 31+ messages in thread
From: Nishanth Menon @ 2018-06-05 6:01 UTC (permalink / raw)
To: Santosh Shilimkar, Will Deacon, Catalin Marinas,
Greg Kroah-Hartman, Mark Rutland, Rob Herring
Cc: linux-serial, linux-kernel, devicetree, linux-arm-kernel,
Tony Lindgren, Vignesh R, Tero Kristo, Russell King,
Sudeep Holla, Nishanth Menon
Hi,
The following series enables support for newest addition in TI's SoC
portfolio - AM654 SoC.
The series is an RFC based off next-20180604 and will post formally once
v4.18-rc1 is available.
The series (part 1 of 4) is available here:
https://github.com/nmenon/linux-2.6-playground/commits/upstream/next-20180604/k3-1-am6-base
Full Boot log is available here: https://pastebin.ubuntu.com/p/vWCzMKtBCW/
The AM654 SoC is a lead device of the K3 Multicore SoC architecture
platform, targeted for broad market and industrial control with aim to
meet the complex processing needs of modern embedded products.
The Linux development follows closely the 66AK2G SoC model in aarch64.
See AM65x Technical Reference Manual (SPRUID7, April 2018)
for further details: http://www.ti.com/lit/pdf/spruid7
Lokesh Vutla (1):
serial: 8250_omap: Make 8250_omap driver driver depend on ARCH_K3
Nishanth Menon (5):
Documentation: arm: ti: Add bindings for AM654 SoC
arm64: Add support for TI's K3 Multicore SoC architecture
serial: 8250_omap: Add support for AM654 UART controller
arm64: dts: ti: Add Support for AM654 SoC
arm64: dts: ti: Add support for AM654 EVM base board
Documentation/devicetree/bindings/arm/ti/k3.txt | 33 +++++
.../devicetree/bindings/serial/omap_serial.txt | 1 +
MAINTAINERS | 9 ++
arch/arm64/Kconfig.platforms | 7 +
arch/arm64/boot/dts/Makefile | 1 +
arch/arm64/boot/dts/ti/Makefile | 9 ++
arch/arm64/boot/dts/ti/k3-am6.dtsi | 144 +++++++++++++++++++++
arch/arm64/boot/dts/ti/k3-am654-base-board.dts | 40 ++++++
arch/arm64/boot/dts/ti/k3-am654.dtsi | 117 +++++++++++++++++
drivers/soc/ti/Kconfig | 14 ++
drivers/tty/serial/8250/8250_omap.c | 1 +
drivers/tty/serial/8250/Kconfig | 2 +-
12 files changed, 377 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/arm/ti/k3.txt
create mode 100644 arch/arm64/boot/dts/ti/Makefile
create mode 100644 arch/arm64/boot/dts/ti/k3-am6.dtsi
create mode 100644 arch/arm64/boot/dts/ti/k3-am654-base-board.dts
create mode 100644 arch/arm64/boot/dts/ti/k3-am654.dtsi
--
2.15.1
^ permalink raw reply [flat|nested] 31+ messages in thread
* [RFC PATCH 0/6] arm64: Initial support Texas Instrument's AM654 Platform
@ 2018-06-05 6:01 ` Nishanth Menon
0 siblings, 0 replies; 31+ messages in thread
From: Nishanth Menon @ 2018-06-05 6:01 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
The following series enables support for newest addition in TI's SoC
portfolio - AM654 SoC.
The series is an RFC based off next-20180604 and will post formally once
v4.18-rc1 is available.
The series (part 1 of 4) is available here:
https://github.com/nmenon/linux-2.6-playground/commits/upstream/next-20180604/k3-1-am6-base
Full Boot log is available here: https://pastebin.ubuntu.com/p/vWCzMKtBCW/
The AM654 SoC is a lead device of the K3 Multicore SoC architecture
platform, targeted for broad market and industrial control with aim to
meet the complex processing needs of modern embedded products.
The Linux development follows closely the 66AK2G SoC model in aarch64.
See AM65x Technical Reference Manual (SPRUID7, April 2018)
for further details: http://www.ti.com/lit/pdf/spruid7
Lokesh Vutla (1):
serial: 8250_omap: Make 8250_omap driver driver depend on ARCH_K3
Nishanth Menon (5):
Documentation: arm: ti: Add bindings for AM654 SoC
arm64: Add support for TI's K3 Multicore SoC architecture
serial: 8250_omap: Add support for AM654 UART controller
arm64: dts: ti: Add Support for AM654 SoC
arm64: dts: ti: Add support for AM654 EVM base board
Documentation/devicetree/bindings/arm/ti/k3.txt | 33 +++++
.../devicetree/bindings/serial/omap_serial.txt | 1 +
MAINTAINERS | 9 ++
arch/arm64/Kconfig.platforms | 7 +
arch/arm64/boot/dts/Makefile | 1 +
arch/arm64/boot/dts/ti/Makefile | 9 ++
arch/arm64/boot/dts/ti/k3-am6.dtsi | 144 +++++++++++++++++++++
arch/arm64/boot/dts/ti/k3-am654-base-board.dts | 40 ++++++
arch/arm64/boot/dts/ti/k3-am654.dtsi | 117 +++++++++++++++++
drivers/soc/ti/Kconfig | 14 ++
drivers/tty/serial/8250/8250_omap.c | 1 +
drivers/tty/serial/8250/Kconfig | 2 +-
12 files changed, 377 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/arm/ti/k3.txt
create mode 100644 arch/arm64/boot/dts/ti/Makefile
create mode 100644 arch/arm64/boot/dts/ti/k3-am6.dtsi
create mode 100644 arch/arm64/boot/dts/ti/k3-am654-base-board.dts
create mode 100644 arch/arm64/boot/dts/ti/k3-am654.dtsi
--
2.15.1
^ permalink raw reply [flat|nested] 31+ messages in thread
* [RFC PATCH 1/6] Documentation: arm: ti: Add bindings for AM654 SoC
2018-06-05 6:01 ` Nishanth Menon
(?)
@ 2018-06-05 6:01 ` Nishanth Menon
-1 siblings, 0 replies; 31+ messages in thread
From: Nishanth Menon @ 2018-06-05 6:01 UTC (permalink / raw)
To: Santosh Shilimkar, Will Deacon, Catalin Marinas,
Greg Kroah-Hartman, Mark Rutland, Rob Herring
Cc: linux-serial, linux-kernel, devicetree, linux-arm-kernel,
Tony Lindgren, Vignesh R, Tero Kristo, Russell King,
Sudeep Holla, Nishanth Menon
The AM654 SoC is a lead device of the K3 Multicore SoC architecture
platform, targeted for broad market and industrial control with aim to
meet the complex processing needs of modern embedded products.
Some highlights of this SoC are:
* Quad ARMv8 A53 cores split over two clusters
* GICv3 compliant GIC500
* Configurable L3 Cache and IO-coherent architecture
* Dual lock-step capable R5F uC for safety-critical applications
* High data throughput capable distributed DMA architecture under NAVSS
* Three Gigabit Industrial Communication Subsystems (ICSSG), each with dual
PRUs and dual RTUs
* Hardware accelerator block containing AES/DES/SHA/MD5 called SA2UL
* Centralized System Controller for Security, Power, and Resource
management.
* Dual ADCSS, eQEP/eCAP, eHRPWM, dual CAN-FD
* Flash subystem with OSPI and Hyperbus interfaces
* Multimedia capability with CAL, DSS7-UL, SGX544, McASP
* Peripheral connectivity including USB3, PCIE, MMC/SD, GPMC, I2C, SPI,
GPIO
See AM65x Technical Reference Manual (SPRUID7, April 2018)
for further details: http://www.ti.com/lit/pdf/spruid7
Signed-off-by: Nishanth Menon <nm@ti.com>
---
Documentation/devicetree/bindings/arm/ti/k3.txt | 33 +++++++++++++++++++++++++
MAINTAINERS | 7 ++++++
2 files changed, 40 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/ti/k3.txt
diff --git a/Documentation/devicetree/bindings/arm/ti/k3.txt b/Documentation/devicetree/bindings/arm/ti/k3.txt
new file mode 100644
index 000000000000..cbabb1b89f6f
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/ti/k3.txt
@@ -0,0 +1,33 @@
+Texas Instruments K3 Multicore SoC architecture device tree bindings
+--------------------------------------------------------------------
+
+Boards based on K3 Multicore SoC architecture shall have the following property:
+- compatible: Every hardware block introduced in K3 Multicore SoC
+ architecture shall be of the form:
+ "ti,XXX-YYY", where:
+ 'XXX' represents the specific SoC part for which the support is added.
+ 'YYY' represents the corresponding peripheral in SoC being supported.
+
+ NOTE: Generic devices such as GIC or legacy devices shall use the specified
+ compatible for those devices.
+
+ Example:
+ compatible = "ti,am654-i2c";
+
+SoCs
+-------------------------------------------
+
+Each device tree root node must specify which exact SoC in K3 Multicore SoC
+architecture it uses, using one of the following compatible values:
+
+- AM654
+ compatible = "ti,am654";
+
+Boards
+-------------------------------------------
+
+In addition, each device tree root node must specify which one or more
+of the following board-specific compatible values:
+
+- AM654 EVM
+ compatible = "ti,am654-evm", "ti,am654";
diff --git a/MAINTAINERS b/MAINTAINERS
index f39a8de1bbd7..cfb35b252ac7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2086,6 +2086,13 @@ L: linux-kernel@vger.kernel.org
S: Maintained
F: drivers/memory/*emif*
+ARM/TEXAS INSTRUMENTS K3 ARCHITECTURE
+M: Tero Kristo <t-kristo@ti.com>
+M: Nishanth Menon <nm@ti.com>
+L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
+S: Supported
+F: Documentation/devicetree/bindings/arm/ti/k3.txt
+
ARM/TEXAS INSTRUMENT KEYSTONE ARCHITECTURE
M: Santosh Shilimkar <ssantosh@kernel.org>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
--
2.15.1
^ permalink raw reply related [flat|nested] 31+ messages in thread
* [RFC PATCH 1/6] Documentation: arm: ti: Add bindings for AM654 SoC
@ 2018-06-05 6:01 ` Nishanth Menon
0 siblings, 0 replies; 31+ messages in thread
From: Nishanth Menon @ 2018-06-05 6:01 UTC (permalink / raw)
To: Santosh Shilimkar, Will Deacon, Catalin Marinas,
Greg Kroah-Hartman, Mark Rutland, Rob Herring
Cc: linux-serial, linux-kernel, devicetree, linux-arm-kernel,
Tony Lindgren, Vignesh R, Tero Kristo, Russell King,
Sudeep Holla, Nishanth Menon
The AM654 SoC is a lead device of the K3 Multicore SoC architecture
platform, targeted for broad market and industrial control with aim to
meet the complex processing needs of modern embedded products.
Some highlights of this SoC are:
* Quad ARMv8 A53 cores split over two clusters
* GICv3 compliant GIC500
* Configurable L3 Cache and IO-coherent architecture
* Dual lock-step capable R5F uC for safety-critical applications
* High data throughput capable distributed DMA architecture under NAVSS
* Three Gigabit Industrial Communication Subsystems (ICSSG), each with dual
PRUs and dual RTUs
* Hardware accelerator block containing AES/DES/SHA/MD5 called SA2UL
* Centralized System Controller for Security, Power, and Resource
management.
* Dual ADCSS, eQEP/eCAP, eHRPWM, dual CAN-FD
* Flash subystem with OSPI and Hyperbus interfaces
* Multimedia capability with CAL, DSS7-UL, SGX544, McASP
* Peripheral connectivity including USB3, PCIE, MMC/SD, GPMC, I2C, SPI,
GPIO
See AM65x Technical Reference Manual (SPRUID7, April 2018)
for further details: http://www.ti.com/lit/pdf/spruid7
Signed-off-by: Nishanth Menon <nm@ti.com>
---
Documentation/devicetree/bindings/arm/ti/k3.txt | 33 +++++++++++++++++++++++++
MAINTAINERS | 7 ++++++
2 files changed, 40 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/ti/k3.txt
diff --git a/Documentation/devicetree/bindings/arm/ti/k3.txt b/Documentation/devicetree/bindings/arm/ti/k3.txt
new file mode 100644
index 000000000000..cbabb1b89f6f
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/ti/k3.txt
@@ -0,0 +1,33 @@
+Texas Instruments K3 Multicore SoC architecture device tree bindings
+--------------------------------------------------------------------
+
+Boards based on K3 Multicore SoC architecture shall have the following property:
+- compatible: Every hardware block introduced in K3 Multicore SoC
+ architecture shall be of the form:
+ "ti,XXX-YYY", where:
+ 'XXX' represents the specific SoC part for which the support is added.
+ 'YYY' represents the corresponding peripheral in SoC being supported.
+
+ NOTE: Generic devices such as GIC or legacy devices shall use the specified
+ compatible for those devices.
+
+ Example:
+ compatible = "ti,am654-i2c";
+
+SoCs
+-------------------------------------------
+
+Each device tree root node must specify which exact SoC in K3 Multicore SoC
+architecture it uses, using one of the following compatible values:
+
+- AM654
+ compatible = "ti,am654";
+
+Boards
+-------------------------------------------
+
+In addition, each device tree root node must specify which one or more
+of the following board-specific compatible values:
+
+- AM654 EVM
+ compatible = "ti,am654-evm", "ti,am654";
diff --git a/MAINTAINERS b/MAINTAINERS
index f39a8de1bbd7..cfb35b252ac7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2086,6 +2086,13 @@ L: linux-kernel@vger.kernel.org
S: Maintained
F: drivers/memory/*emif*
+ARM/TEXAS INSTRUMENTS K3 ARCHITECTURE
+M: Tero Kristo <t-kristo@ti.com>
+M: Nishanth Menon <nm@ti.com>
+L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
+S: Supported
+F: Documentation/devicetree/bindings/arm/ti/k3.txt
+
ARM/TEXAS INSTRUMENT KEYSTONE ARCHITECTURE
M: Santosh Shilimkar <ssantosh@kernel.org>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
--
2.15.1
^ permalink raw reply related [flat|nested] 31+ messages in thread
* [RFC PATCH 1/6] Documentation: arm: ti: Add bindings for AM654 SoC
@ 2018-06-05 6:01 ` Nishanth Menon
0 siblings, 0 replies; 31+ messages in thread
From: Nishanth Menon @ 2018-06-05 6:01 UTC (permalink / raw)
To: linux-arm-kernel
The AM654 SoC is a lead device of the K3 Multicore SoC architecture
platform, targeted for broad market and industrial control with aim to
meet the complex processing needs of modern embedded products.
Some highlights of this SoC are:
* Quad ARMv8 A53 cores split over two clusters
* GICv3 compliant GIC500
* Configurable L3 Cache and IO-coherent architecture
* Dual lock-step capable R5F uC for safety-critical applications
* High data throughput capable distributed DMA architecture under NAVSS
* Three Gigabit Industrial Communication Subsystems (ICSSG), each with dual
PRUs and dual RTUs
* Hardware accelerator block containing AES/DES/SHA/MD5 called SA2UL
* Centralized System Controller for Security, Power, and Resource
management.
* Dual ADCSS, eQEP/eCAP, eHRPWM, dual CAN-FD
* Flash subystem with OSPI and Hyperbus interfaces
* Multimedia capability with CAL, DSS7-UL, SGX544, McASP
* Peripheral connectivity including USB3, PCIE, MMC/SD, GPMC, I2C, SPI,
GPIO
See AM65x Technical Reference Manual (SPRUID7, April 2018)
for further details: http://www.ti.com/lit/pdf/spruid7
Signed-off-by: Nishanth Menon <nm@ti.com>
---
Documentation/devicetree/bindings/arm/ti/k3.txt | 33 +++++++++++++++++++++++++
MAINTAINERS | 7 ++++++
2 files changed, 40 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/ti/k3.txt
diff --git a/Documentation/devicetree/bindings/arm/ti/k3.txt b/Documentation/devicetree/bindings/arm/ti/k3.txt
new file mode 100644
index 000000000000..cbabb1b89f6f
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/ti/k3.txt
@@ -0,0 +1,33 @@
+Texas Instruments K3 Multicore SoC architecture device tree bindings
+--------------------------------------------------------------------
+
+Boards based on K3 Multicore SoC architecture shall have the following property:
+- compatible: Every hardware block introduced in K3 Multicore SoC
+ architecture shall be of the form:
+ "ti,XXX-YYY", where:
+ 'XXX' represents the specific SoC part for which the support is added.
+ 'YYY' represents the corresponding peripheral in SoC being supported.
+
+ NOTE: Generic devices such as GIC or legacy devices shall use the specified
+ compatible for those devices.
+
+ Example:
+ compatible = "ti,am654-i2c";
+
+SoCs
+-------------------------------------------
+
+Each device tree root node must specify which exact SoC in K3 Multicore SoC
+architecture it uses, using one of the following compatible values:
+
+- AM654
+ compatible = "ti,am654";
+
+Boards
+-------------------------------------------
+
+In addition, each device tree root node must specify which one or more
+of the following board-specific compatible values:
+
+- AM654 EVM
+ compatible = "ti,am654-evm", "ti,am654";
diff --git a/MAINTAINERS b/MAINTAINERS
index f39a8de1bbd7..cfb35b252ac7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2086,6 +2086,13 @@ L: linux-kernel at vger.kernel.org
S: Maintained
F: drivers/memory/*emif*
+ARM/TEXAS INSTRUMENTS K3 ARCHITECTURE
+M: Tero Kristo <t-kristo@ti.com>
+M: Nishanth Menon <nm@ti.com>
+L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
+S: Supported
+F: Documentation/devicetree/bindings/arm/ti/k3.txt
+
ARM/TEXAS INSTRUMENT KEYSTONE ARCHITECTURE
M: Santosh Shilimkar <ssantosh@kernel.org>
L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
--
2.15.1
^ permalink raw reply related [flat|nested] 31+ messages in thread
* [RFC PATCH 2/6] arm64: Add support for TI's K3 Multicore SoC architecture
2018-06-05 6:01 ` Nishanth Menon
(?)
@ 2018-06-05 6:01 ` Nishanth Menon
-1 siblings, 0 replies; 31+ messages in thread
From: Nishanth Menon @ 2018-06-05 6:01 UTC (permalink / raw)
To: Santosh Shilimkar, Will Deacon, Catalin Marinas,
Greg Kroah-Hartman, Mark Rutland, Rob Herring
Cc: linux-serial, linux-kernel, devicetree, linux-arm-kernel,
Tony Lindgren, Vignesh R, Tero Kristo, Russell King,
Sudeep Holla, Nishanth Menon
Add support for Texas Instrument's K3 Multicore SoC architecture
processors.
Signed-off-by: Nishanth Menon <nm@ti.com>
---
arch/arm64/Kconfig.platforms | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index d5aeac351fc3..52df25bf4f8c 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -71,6 +71,13 @@ config ARCH_EXYNOS
help
This enables support for ARMv8 based Samsung Exynos SoC family.
+config ARCH_K3
+ bool "Texas Instruments Inc. K3 multicore SoC architecture"
+ select PM_GENERIC_DOMAINS if PM
+ help
+ This enables support for Texas Instruments' K3 multicore SoC
+ architecture.
+
config ARCH_LAYERSCAPE
bool "ARMv8 based Freescale Layerscape SoC family"
select EDAC_SUPPORT
--
2.15.1
^ permalink raw reply related [flat|nested] 31+ messages in thread
* [RFC PATCH 2/6] arm64: Add support for TI's K3 Multicore SoC architecture
@ 2018-06-05 6:01 ` Nishanth Menon
0 siblings, 0 replies; 31+ messages in thread
From: Nishanth Menon @ 2018-06-05 6:01 UTC (permalink / raw)
To: Santosh Shilimkar, Will Deacon, Catalin Marinas,
Greg Kroah-Hartman, Mark Rutland, Rob Herring
Cc: linux-serial, linux-kernel, devicetree, linux-arm-kernel,
Tony Lindgren, Vignesh R, Tero Kristo, Russell King,
Sudeep Holla, Nishanth Menon
Add support for Texas Instrument's K3 Multicore SoC architecture
processors.
Signed-off-by: Nishanth Menon <nm@ti.com>
---
arch/arm64/Kconfig.platforms | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index d5aeac351fc3..52df25bf4f8c 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -71,6 +71,13 @@ config ARCH_EXYNOS
help
This enables support for ARMv8 based Samsung Exynos SoC family.
+config ARCH_K3
+ bool "Texas Instruments Inc. K3 multicore SoC architecture"
+ select PM_GENERIC_DOMAINS if PM
+ help
+ This enables support for Texas Instruments' K3 multicore SoC
+ architecture.
+
config ARCH_LAYERSCAPE
bool "ARMv8 based Freescale Layerscape SoC family"
select EDAC_SUPPORT
--
2.15.1
^ permalink raw reply related [flat|nested] 31+ messages in thread
* [RFC PATCH 2/6] arm64: Add support for TI's K3 Multicore SoC architecture
@ 2018-06-05 6:01 ` Nishanth Menon
0 siblings, 0 replies; 31+ messages in thread
From: Nishanth Menon @ 2018-06-05 6:01 UTC (permalink / raw)
To: linux-arm-kernel
Add support for Texas Instrument's K3 Multicore SoC architecture
processors.
Signed-off-by: Nishanth Menon <nm@ti.com>
---
arch/arm64/Kconfig.platforms | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index d5aeac351fc3..52df25bf4f8c 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -71,6 +71,13 @@ config ARCH_EXYNOS
help
This enables support for ARMv8 based Samsung Exynos SoC family.
+config ARCH_K3
+ bool "Texas Instruments Inc. K3 multicore SoC architecture"
+ select PM_GENERIC_DOMAINS if PM
+ help
+ This enables support for Texas Instruments' K3 multicore SoC
+ architecture.
+
config ARCH_LAYERSCAPE
bool "ARMv8 based Freescale Layerscape SoC family"
select EDAC_SUPPORT
--
2.15.1
^ permalink raw reply related [flat|nested] 31+ messages in thread
* [RFC PATCH 3/6] serial: 8250_omap: Add support for AM654 UART controller
2018-06-05 6:01 ` Nishanth Menon
(?)
@ 2018-06-05 6:01 ` Nishanth Menon
-1 siblings, 0 replies; 31+ messages in thread
From: Nishanth Menon @ 2018-06-05 6:01 UTC (permalink / raw)
To: Santosh Shilimkar, Will Deacon, Catalin Marinas,
Greg Kroah-Hartman, Mark Rutland, Rob Herring
Cc: linux-serial, linux-kernel, devicetree, linux-arm-kernel,
Tony Lindgren, Vignesh R, Tero Kristo, Russell King,
Sudeep Holla, Nishanth Menon, Sekhar Nori
AM654 uses a UART controller that is compatible (partially) with
existing 8250 UART, however, has a few differences with respect to DMA
support and control paths. Introduce a base definition that allows us
to build up the differences in follow on patches.
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Vignesh R <vigneshr@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
Documentation/devicetree/bindings/serial/omap_serial.txt | 1 +
drivers/tty/serial/8250/8250_omap.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt b/Documentation/devicetree/bindings/serial/omap_serial.txt
index 4b0f05adb228..c35d5ece1156 100644
--- a/Documentation/devicetree/bindings/serial/omap_serial.txt
+++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
@@ -1,6 +1,7 @@
OMAP UART controller
Required properties:
+- compatible : should be "ti,am654-uart" for AM654 controllers
- compatible : should be "ti,omap2-uart" for OMAP2 controllers
- compatible : should be "ti,omap3-uart" for OMAP3 controllers
- compatible : should be "ti,omap4-uart" for OMAP4 controllers
diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
index 1b337fee07ed..a019286f8bb6 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -1115,6 +1115,7 @@ static const u8 am3352_habit = OMAP_DMA_TX_KICK | UART_ERRATA_CLOCK_DISABLE;
static const u8 dra742_habit = UART_ERRATA_CLOCK_DISABLE;
static const struct of_device_id omap8250_dt_ids[] = {
+ { .compatible = "ti,am654-uart" },
{ .compatible = "ti,omap2-uart" },
{ .compatible = "ti,omap3-uart" },
{ .compatible = "ti,omap4-uart", .data = &omap4_habit, },
--
2.15.1
^ permalink raw reply related [flat|nested] 31+ messages in thread
* [RFC PATCH 3/6] serial: 8250_omap: Add support for AM654 UART controller
@ 2018-06-05 6:01 ` Nishanth Menon
0 siblings, 0 replies; 31+ messages in thread
From: Nishanth Menon @ 2018-06-05 6:01 UTC (permalink / raw)
To: Santosh Shilimkar, Will Deacon, Catalin Marinas,
Greg Kroah-Hartman, Mark Rutland, Rob Herring
Cc: linux-serial, linux-kernel, devicetree, linux-arm-kernel,
Tony Lindgren, Vignesh R, Tero Kristo, Russell King,
Sudeep Holla, Nishanth Menon, Sekhar Nori
AM654 uses a UART controller that is compatible (partially) with
existing 8250 UART, however, has a few differences with respect to DMA
support and control paths. Introduce a base definition that allows us
to build up the differences in follow on patches.
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Vignesh R <vigneshr@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
Documentation/devicetree/bindings/serial/omap_serial.txt | 1 +
drivers/tty/serial/8250/8250_omap.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt b/Documentation/devicetree/bindings/serial/omap_serial.txt
index 4b0f05adb228..c35d5ece1156 100644
--- a/Documentation/devicetree/bindings/serial/omap_serial.txt
+++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
@@ -1,6 +1,7 @@
OMAP UART controller
Required properties:
+- compatible : should be "ti,am654-uart" for AM654 controllers
- compatible : should be "ti,omap2-uart" for OMAP2 controllers
- compatible : should be "ti,omap3-uart" for OMAP3 controllers
- compatible : should be "ti,omap4-uart" for OMAP4 controllers
diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
index 1b337fee07ed..a019286f8bb6 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -1115,6 +1115,7 @@ static const u8 am3352_habit = OMAP_DMA_TX_KICK | UART_ERRATA_CLOCK_DISABLE;
static const u8 dra742_habit = UART_ERRATA_CLOCK_DISABLE;
static const struct of_device_id omap8250_dt_ids[] = {
+ { .compatible = "ti,am654-uart" },
{ .compatible = "ti,omap2-uart" },
{ .compatible = "ti,omap3-uart" },
{ .compatible = "ti,omap4-uart", .data = &omap4_habit, },
--
2.15.1
^ permalink raw reply related [flat|nested] 31+ messages in thread
* [RFC PATCH 3/6] serial: 8250_omap: Add support for AM654 UART controller
@ 2018-06-05 6:01 ` Nishanth Menon
0 siblings, 0 replies; 31+ messages in thread
From: Nishanth Menon @ 2018-06-05 6:01 UTC (permalink / raw)
To: linux-arm-kernel
AM654 uses a UART controller that is compatible (partially) with
existing 8250 UART, however, has a few differences with respect to DMA
support and control paths. Introduce a base definition that allows us
to build up the differences in follow on patches.
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Vignesh R <vigneshr@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
Documentation/devicetree/bindings/serial/omap_serial.txt | 1 +
drivers/tty/serial/8250/8250_omap.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt b/Documentation/devicetree/bindings/serial/omap_serial.txt
index 4b0f05adb228..c35d5ece1156 100644
--- a/Documentation/devicetree/bindings/serial/omap_serial.txt
+++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
@@ -1,6 +1,7 @@
OMAP UART controller
Required properties:
+- compatible : should be "ti,am654-uart" for AM654 controllers
- compatible : should be "ti,omap2-uart" for OMAP2 controllers
- compatible : should be "ti,omap3-uart" for OMAP3 controllers
- compatible : should be "ti,omap4-uart" for OMAP4 controllers
diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
index 1b337fee07ed..a019286f8bb6 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -1115,6 +1115,7 @@ static const u8 am3352_habit = OMAP_DMA_TX_KICK | UART_ERRATA_CLOCK_DISABLE;
static const u8 dra742_habit = UART_ERRATA_CLOCK_DISABLE;
static const struct of_device_id omap8250_dt_ids[] = {
+ { .compatible = "ti,am654-uart" },
{ .compatible = "ti,omap2-uart" },
{ .compatible = "ti,omap3-uart" },
{ .compatible = "ti,omap4-uart", .data = &omap4_habit, },
--
2.15.1
^ permalink raw reply related [flat|nested] 31+ messages in thread
* [RFC PATCH 4/6] serial: 8250_omap: Make 8250_omap driver driver depend on ARCH_K3
2018-06-05 6:01 ` Nishanth Menon
(?)
@ 2018-06-05 6:01 ` Nishanth Menon
-1 siblings, 0 replies; 31+ messages in thread
From: Nishanth Menon @ 2018-06-05 6:01 UTC (permalink / raw)
To: Santosh Shilimkar, Will Deacon, Catalin Marinas,
Greg Kroah-Hartman, Mark Rutland, Rob Herring
Cc: linux-serial, linux-kernel, devicetree, linux-arm-kernel,
Tony Lindgren, Vignesh R, Tero Kristo, Russell King,
Sudeep Holla, Lokesh Vutla, Nishanth Menon
From: Lokesh Vutla <lokeshvutla@ti.com>
Allow 8250 omap serial driver to be used for K3 platforms.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
drivers/tty/serial/8250/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/8250/Kconfig b/drivers/tty/serial/8250/Kconfig
index f005eaf8bc57..15c2c5463835 100644
--- a/drivers/tty/serial/8250/Kconfig
+++ b/drivers/tty/serial/8250/Kconfig
@@ -375,7 +375,7 @@ config SERIAL_8250_RT288X
config SERIAL_8250_OMAP
tristate "Support for OMAP internal UART (8250 based driver)"
- depends on SERIAL_8250 && ARCH_OMAP2PLUS
+ depends on SERIAL_8250 && (ARCH_OMAP2PLUS || ARCH_K3)
help
If you have a machine based on an Texas Instruments OMAP CPU you
can enable its onboard serial ports by enabling this option.
--
2.15.1
^ permalink raw reply related [flat|nested] 31+ messages in thread
* [RFC PATCH 4/6] serial: 8250_omap: Make 8250_omap driver driver depend on ARCH_K3
@ 2018-06-05 6:01 ` Nishanth Menon
0 siblings, 0 replies; 31+ messages in thread
From: Nishanth Menon @ 2018-06-05 6:01 UTC (permalink / raw)
To: Santosh Shilimkar, Will Deacon, Catalin Marinas,
Greg Kroah-Hartman, Mark Rutland, Rob Herring
Cc: Nishanth Menon, devicetree, Vignesh R, Tony Lindgren,
linux-kernel, Russell King, Tero Kristo, Lokesh Vutla,
linux-serial, Sudeep Holla, linux-arm-kernel
From: Lokesh Vutla <lokeshvutla@ti.com>
Allow 8250 omap serial driver to be used for K3 platforms.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
drivers/tty/serial/8250/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/8250/Kconfig b/drivers/tty/serial/8250/Kconfig
index f005eaf8bc57..15c2c5463835 100644
--- a/drivers/tty/serial/8250/Kconfig
+++ b/drivers/tty/serial/8250/Kconfig
@@ -375,7 +375,7 @@ config SERIAL_8250_RT288X
config SERIAL_8250_OMAP
tristate "Support for OMAP internal UART (8250 based driver)"
- depends on SERIAL_8250 && ARCH_OMAP2PLUS
+ depends on SERIAL_8250 && (ARCH_OMAP2PLUS || ARCH_K3)
help
If you have a machine based on an Texas Instruments OMAP CPU you
can enable its onboard serial ports by enabling this option.
--
2.15.1
^ permalink raw reply related [flat|nested] 31+ messages in thread
* [RFC PATCH 4/6] serial: 8250_omap: Make 8250_omap driver driver depend on ARCH_K3
@ 2018-06-05 6:01 ` Nishanth Menon
0 siblings, 0 replies; 31+ messages in thread
From: Nishanth Menon @ 2018-06-05 6:01 UTC (permalink / raw)
To: linux-arm-kernel
From: Lokesh Vutla <lokeshvutla@ti.com>
Allow 8250 omap serial driver to be used for K3 platforms.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
drivers/tty/serial/8250/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/8250/Kconfig b/drivers/tty/serial/8250/Kconfig
index f005eaf8bc57..15c2c5463835 100644
--- a/drivers/tty/serial/8250/Kconfig
+++ b/drivers/tty/serial/8250/Kconfig
@@ -375,7 +375,7 @@ config SERIAL_8250_RT288X
config SERIAL_8250_OMAP
tristate "Support for OMAP internal UART (8250 based driver)"
- depends on SERIAL_8250 && ARCH_OMAP2PLUS
+ depends on SERIAL_8250 && (ARCH_OMAP2PLUS || ARCH_K3)
help
If you have a machine based on an Texas Instruments OMAP CPU you
can enable its onboard serial ports by enabling this option.
--
2.15.1
^ permalink raw reply related [flat|nested] 31+ messages in thread
* Re: [RFC PATCH 1/6] Documentation: arm: ti: Add bindings for AM654 SoC
2018-06-05 6:01 ` Nishanth Menon
@ 2018-06-12 21:05 ` Rob Herring
-1 siblings, 0 replies; 31+ messages in thread
From: Rob Herring @ 2018-06-12 21:05 UTC (permalink / raw)
To: Nishanth Menon
Cc: Santosh Shilimkar, Will Deacon, Catalin Marinas,
Greg Kroah-Hartman, Mark Rutland, linux-serial, linux-kernel,
devicetree, linux-arm-kernel, Tony Lindgren, Vignesh R,
Tero Kristo, Russell King, Sudeep Holla
On Tue, Jun 05, 2018 at 01:01:20AM -0500, Nishanth Menon wrote:
> The AM654 SoC is a lead device of the K3 Multicore SoC architecture
> platform, targeted for broad market and industrial control with aim to
> meet the complex processing needs of modern embedded products.
>
> Some highlights of this SoC are:
> * Quad ARMv8 A53 cores split over two clusters
> * GICv3 compliant GIC500
> * Configurable L3 Cache and IO-coherent architecture
> * Dual lock-step capable R5F uC for safety-critical applications
> * High data throughput capable distributed DMA architecture under NAVSS
> * Three Gigabit Industrial Communication Subsystems (ICSSG), each with dual
> PRUs and dual RTUs
> * Hardware accelerator block containing AES/DES/SHA/MD5 called SA2UL
> * Centralized System Controller for Security, Power, and Resource
> management.
> * Dual ADCSS, eQEP/eCAP, eHRPWM, dual CAN-FD
> * Flash subystem with OSPI and Hyperbus interfaces
> * Multimedia capability with CAL, DSS7-UL, SGX544, McASP
> * Peripheral connectivity including USB3, PCIE, MMC/SD, GPMC, I2C, SPI,
> GPIO
>
> See AM65x Technical Reference Manual (SPRUID7, April 2018)
> for further details: http://www.ti.com/lit/pdf/spruid7
>
> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
> Documentation/devicetree/bindings/arm/ti/k3.txt | 33 +++++++++++++++++++++++++
> MAINTAINERS | 7 ++++++
> 2 files changed, 40 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/ti/k3.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/ti/k3.txt b/Documentation/devicetree/bindings/arm/ti/k3.txt
> new file mode 100644
> index 000000000000..cbabb1b89f6f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/ti/k3.txt
> @@ -0,0 +1,33 @@
> +Texas Instruments K3 Multicore SoC architecture device tree bindings
> +--------------------------------------------------------------------
> +
> +Boards based on K3 Multicore SoC architecture shall have the following property:
> +- compatible: Every hardware block introduced in K3 Multicore SoC
> + architecture shall be of the form:
> + "ti,XXX-YYY", where:
> + 'XXX' represents the specific SoC part for which the support is added.
> + 'YYY' represents the corresponding peripheral in SoC being supported.
No need to explain standard DT convention here. (But I don't think we
have this convention documented anywhere, so patches welcome. :))
> +
> + NOTE: Generic devices such as GIC or legacy devices shall use the specified
> + compatible for those devices.
> +
> + Example:
> + compatible = "ti,am654-i2c";
> +
> +SoCs
> +-------------------------------------------
> +
> +Each device tree root node must specify which exact SoC in K3 Multicore SoC
> +architecture it uses, using one of the following compatible values:
> +
> +- AM654
> + compatible = "ti,am654";
> +
> +Boards
> +-------------------------------------------
> +
> +In addition, each device tree root node must specify which one or more
> +of the following board-specific compatible values:
> +
> +- AM654 EVM
> + compatible = "ti,am654-evm", "ti,am654";
> diff --git a/MAINTAINERS b/MAINTAINERS
> index f39a8de1bbd7..cfb35b252ac7 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2086,6 +2086,13 @@ L: linux-kernel@vger.kernel.org
> S: Maintained
> F: drivers/memory/*emif*
>
> +ARM/TEXAS INSTRUMENTS K3 ARCHITECTURE
> +M: Tero Kristo <t-kristo@ti.com>
> +M: Nishanth Menon <nm@ti.com>
> +L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
> +S: Supported
> +F: Documentation/devicetree/bindings/arm/ti/k3.txt
> +
> ARM/TEXAS INSTRUMENT KEYSTONE ARCHITECTURE
> M: Santosh Shilimkar <ssantosh@kernel.org>
> L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
> --
> 2.15.1
>
^ permalink raw reply [flat|nested] 31+ messages in thread
* [RFC PATCH 1/6] Documentation: arm: ti: Add bindings for AM654 SoC
@ 2018-06-12 21:05 ` Rob Herring
0 siblings, 0 replies; 31+ messages in thread
From: Rob Herring @ 2018-06-12 21:05 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Jun 05, 2018 at 01:01:20AM -0500, Nishanth Menon wrote:
> The AM654 SoC is a lead device of the K3 Multicore SoC architecture
> platform, targeted for broad market and industrial control with aim to
> meet the complex processing needs of modern embedded products.
>
> Some highlights of this SoC are:
> * Quad ARMv8 A53 cores split over two clusters
> * GICv3 compliant GIC500
> * Configurable L3 Cache and IO-coherent architecture
> * Dual lock-step capable R5F uC for safety-critical applications
> * High data throughput capable distributed DMA architecture under NAVSS
> * Three Gigabit Industrial Communication Subsystems (ICSSG), each with dual
> PRUs and dual RTUs
> * Hardware accelerator block containing AES/DES/SHA/MD5 called SA2UL
> * Centralized System Controller for Security, Power, and Resource
> management.
> * Dual ADCSS, eQEP/eCAP, eHRPWM, dual CAN-FD
> * Flash subystem with OSPI and Hyperbus interfaces
> * Multimedia capability with CAL, DSS7-UL, SGX544, McASP
> * Peripheral connectivity including USB3, PCIE, MMC/SD, GPMC, I2C, SPI,
> GPIO
>
> See AM65x Technical Reference Manual (SPRUID7, April 2018)
> for further details: http://www.ti.com/lit/pdf/spruid7
>
> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
> Documentation/devicetree/bindings/arm/ti/k3.txt | 33 +++++++++++++++++++++++++
> MAINTAINERS | 7 ++++++
> 2 files changed, 40 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/ti/k3.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/ti/k3.txt b/Documentation/devicetree/bindings/arm/ti/k3.txt
> new file mode 100644
> index 000000000000..cbabb1b89f6f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/ti/k3.txt
> @@ -0,0 +1,33 @@
> +Texas Instruments K3 Multicore SoC architecture device tree bindings
> +--------------------------------------------------------------------
> +
> +Boards based on K3 Multicore SoC architecture shall have the following property:
> +- compatible: Every hardware block introduced in K3 Multicore SoC
> + architecture shall be of the form:
> + "ti,XXX-YYY", where:
> + 'XXX' represents the specific SoC part for which the support is added.
> + 'YYY' represents the corresponding peripheral in SoC being supported.
No need to explain standard DT convention here. (But I don't think we
have this convention documented anywhere, so patches welcome. :))
> +
> + NOTE: Generic devices such as GIC or legacy devices shall use the specified
> + compatible for those devices.
> +
> + Example:
> + compatible = "ti,am654-i2c";
> +
> +SoCs
> +-------------------------------------------
> +
> +Each device tree root node must specify which exact SoC in K3 Multicore SoC
> +architecture it uses, using one of the following compatible values:
> +
> +- AM654
> + compatible = "ti,am654";
> +
> +Boards
> +-------------------------------------------
> +
> +In addition, each device tree root node must specify which one or more
> +of the following board-specific compatible values:
> +
> +- AM654 EVM
> + compatible = "ti,am654-evm", "ti,am654";
> diff --git a/MAINTAINERS b/MAINTAINERS
> index f39a8de1bbd7..cfb35b252ac7 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2086,6 +2086,13 @@ L: linux-kernel at vger.kernel.org
> S: Maintained
> F: drivers/memory/*emif*
>
> +ARM/TEXAS INSTRUMENTS K3 ARCHITECTURE
> +M: Tero Kristo <t-kristo@ti.com>
> +M: Nishanth Menon <nm@ti.com>
> +L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
> +S: Supported
> +F: Documentation/devicetree/bindings/arm/ti/k3.txt
> +
> ARM/TEXAS INSTRUMENT KEYSTONE ARCHITECTURE
> M: Santosh Shilimkar <ssantosh@kernel.org>
> L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
> --
> 2.15.1
>
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC PATCH 3/6] serial: 8250_omap: Add support for AM654 UART controller
2018-06-05 6:01 ` Nishanth Menon
@ 2018-06-12 21:06 ` Rob Herring
-1 siblings, 0 replies; 31+ messages in thread
From: Rob Herring @ 2018-06-12 21:06 UTC (permalink / raw)
To: Nishanth Menon
Cc: Santosh Shilimkar, Will Deacon, Catalin Marinas,
Greg Kroah-Hartman, Mark Rutland, linux-serial, linux-kernel,
devicetree, linux-arm-kernel, Tony Lindgren, Vignesh R,
Tero Kristo, Russell King, Sudeep Holla, Sekhar Nori
On Tue, Jun 05, 2018 at 01:01:22AM -0500, Nishanth Menon wrote:
> AM654 uses a UART controller that is compatible (partially) with
> existing 8250 UART, however, has a few differences with respect to DMA
> support and control paths. Introduce a base definition that allows us
> to build up the differences in follow on patches.
>
> Cc: Sekhar Nori <nsekhar@ti.com>
> Cc: Vignesh R <vigneshr@ti.com>
> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
> Documentation/devicetree/bindings/serial/omap_serial.txt | 1 +
> drivers/tty/serial/8250/8250_omap.c | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt b/Documentation/devicetree/bindings/serial/omap_serial.txt
> index 4b0f05adb228..c35d5ece1156 100644
> --- a/Documentation/devicetree/bindings/serial/omap_serial.txt
> +++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
> @@ -1,6 +1,7 @@
> OMAP UART controller
>
> Required properties:
> +- compatible : should be "ti,am654-uart" for AM654 controllers
Not compatible with any existing TI 8250 UARTs?
> - compatible : should be "ti,omap2-uart" for OMAP2 controllers
> - compatible : should be "ti,omap3-uart" for OMAP3 controllers
> - compatible : should be "ti,omap4-uart" for OMAP4 controllers
> diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
> index 1b337fee07ed..a019286f8bb6 100644
> --- a/drivers/tty/serial/8250/8250_omap.c
> +++ b/drivers/tty/serial/8250/8250_omap.c
> @@ -1115,6 +1115,7 @@ static const u8 am3352_habit = OMAP_DMA_TX_KICK | UART_ERRATA_CLOCK_DISABLE;
> static const u8 dra742_habit = UART_ERRATA_CLOCK_DISABLE;
>
> static const struct of_device_id omap8250_dt_ids[] = {
> + { .compatible = "ti,am654-uart" },
> { .compatible = "ti,omap2-uart" },
> { .compatible = "ti,omap3-uart" },
> { .compatible = "ti,omap4-uart", .data = &omap4_habit, },
> --
> 2.15.1
>
^ permalink raw reply [flat|nested] 31+ messages in thread
* [RFC PATCH 3/6] serial: 8250_omap: Add support for AM654 UART controller
@ 2018-06-12 21:06 ` Rob Herring
0 siblings, 0 replies; 31+ messages in thread
From: Rob Herring @ 2018-06-12 21:06 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Jun 05, 2018 at 01:01:22AM -0500, Nishanth Menon wrote:
> AM654 uses a UART controller that is compatible (partially) with
> existing 8250 UART, however, has a few differences with respect to DMA
> support and control paths. Introduce a base definition that allows us
> to build up the differences in follow on patches.
>
> Cc: Sekhar Nori <nsekhar@ti.com>
> Cc: Vignesh R <vigneshr@ti.com>
> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
> Documentation/devicetree/bindings/serial/omap_serial.txt | 1 +
> drivers/tty/serial/8250/8250_omap.c | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt b/Documentation/devicetree/bindings/serial/omap_serial.txt
> index 4b0f05adb228..c35d5ece1156 100644
> --- a/Documentation/devicetree/bindings/serial/omap_serial.txt
> +++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
> @@ -1,6 +1,7 @@
> OMAP UART controller
>
> Required properties:
> +- compatible : should be "ti,am654-uart" for AM654 controllers
Not compatible with any existing TI 8250 UARTs?
> - compatible : should be "ti,omap2-uart" for OMAP2 controllers
> - compatible : should be "ti,omap3-uart" for OMAP3 controllers
> - compatible : should be "ti,omap4-uart" for OMAP4 controllers
> diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
> index 1b337fee07ed..a019286f8bb6 100644
> --- a/drivers/tty/serial/8250/8250_omap.c
> +++ b/drivers/tty/serial/8250/8250_omap.c
> @@ -1115,6 +1115,7 @@ static const u8 am3352_habit = OMAP_DMA_TX_KICK | UART_ERRATA_CLOCK_DISABLE;
> static const u8 dra742_habit = UART_ERRATA_CLOCK_DISABLE;
>
> static const struct of_device_id omap8250_dt_ids[] = {
> + { .compatible = "ti,am654-uart" },
> { .compatible = "ti,omap2-uart" },
> { .compatible = "ti,omap3-uart" },
> { .compatible = "ti,omap4-uart", .data = &omap4_habit, },
> --
> 2.15.1
>
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC PATCH 1/6] Documentation: arm: ti: Add bindings for AM654 SoC
2018-06-12 21:05 ` Rob Herring
(?)
@ 2018-06-12 22:01 ` Nishanth Menon
-1 siblings, 0 replies; 31+ messages in thread
From: Nishanth Menon @ 2018-06-12 22:01 UTC (permalink / raw)
To: Rob Herring
Cc: Santosh Shilimkar, Will Deacon, Catalin Marinas,
Greg Kroah-Hartman, Mark Rutland, linux-serial, linux-kernel,
devicetree, linux-arm-kernel, Tony Lindgren, Vignesh R,
Tero Kristo, Russell King, Sudeep Holla
On 21:05-20180612, Rob Herring wrote:
> On Tue, Jun 05, 2018 at 01:01:20AM -0500, Nishanth Menon wrote:
[...]
> > +Boards based on K3 Multicore SoC architecture shall have the following property:
> > +- compatible: Every hardware block introduced in K3 Multicore SoC
> > + architecture shall be of the form:
> > + "ti,XXX-YYY", where:
> > + 'XXX' represents the specific SoC part for which the support is added.
> > + 'YYY' represents the corresponding peripheral in SoC being supported.
>
> No need to explain standard DT convention here. (But I don't think we
> have this convention documented anywhere, so patches welcome. :))
>
Thanks. Will drop off from my series (will skip the generic dts
convention for now ;) ).
--
Regards,
Nishanth Menon
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC PATCH 1/6] Documentation: arm: ti: Add bindings for AM654 SoC
@ 2018-06-12 22:01 ` Nishanth Menon
0 siblings, 0 replies; 31+ messages in thread
From: Nishanth Menon @ 2018-06-12 22:01 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree, Sudeep Holla, Vignesh R, Tony Lindgren,
Catalin Marinas, Santosh Shilimkar, Will Deacon, linux-kernel,
Russell King, Tero Kristo, linux-serial, Greg Kroah-Hartman,
linux-arm-kernel
On 21:05-20180612, Rob Herring wrote:
> On Tue, Jun 05, 2018 at 01:01:20AM -0500, Nishanth Menon wrote:
[...]
> > +Boards based on K3 Multicore SoC architecture shall have the following property:
> > +- compatible: Every hardware block introduced in K3 Multicore SoC
> > + architecture shall be of the form:
> > + "ti,XXX-YYY", where:
> > + 'XXX' represents the specific SoC part for which the support is added.
> > + 'YYY' represents the corresponding peripheral in SoC being supported.
>
> No need to explain standard DT convention here. (But I don't think we
> have this convention documented anywhere, so patches welcome. :))
>
Thanks. Will drop off from my series (will skip the generic dts
convention for now ;) ).
--
Regards,
Nishanth Menon
^ permalink raw reply [flat|nested] 31+ messages in thread
* [RFC PATCH 1/6] Documentation: arm: ti: Add bindings for AM654 SoC
@ 2018-06-12 22:01 ` Nishanth Menon
0 siblings, 0 replies; 31+ messages in thread
From: Nishanth Menon @ 2018-06-12 22:01 UTC (permalink / raw)
To: linux-arm-kernel
On 21:05-20180612, Rob Herring wrote:
> On Tue, Jun 05, 2018 at 01:01:20AM -0500, Nishanth Menon wrote:
[...]
> > +Boards based on K3 Multicore SoC architecture shall have the following property:
> > +- compatible: Every hardware block introduced in K3 Multicore SoC
> > + architecture shall be of the form:
> > + "ti,XXX-YYY", where:
> > + 'XXX' represents the specific SoC part for which the support is added.
> > + 'YYY' represents the corresponding peripheral in SoC being supported.
>
> No need to explain standard DT convention here. (But I don't think we
> have this convention documented anywhere, so patches welcome. :))
>
Thanks. Will drop off from my series (will skip the generic dts
convention for now ;) ).
--
Regards,
Nishanth Menon
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC PATCH 3/6] serial: 8250_omap: Add support for AM654 UART controller
2018-06-12 21:06 ` Rob Herring
(?)
@ 2018-06-12 22:03 ` Nishanth Menon
-1 siblings, 0 replies; 31+ messages in thread
From: Nishanth Menon @ 2018-06-12 22:03 UTC (permalink / raw)
To: Rob Herring
Cc: Santosh Shilimkar, Will Deacon, Catalin Marinas,
Greg Kroah-Hartman, Mark Rutland, linux-serial, linux-kernel,
devicetree, linux-arm-kernel, Tony Lindgren, Vignesh R,
Tero Kristo, Russell King, Sudeep Holla, Sekhar Nori
On 21:06-20180612, Rob Herring wrote:
> > diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt b/Documentation/devicetree/bindings/serial/omap_serial.txt
> > index 4b0f05adb228..c35d5ece1156 100644
> > --- a/Documentation/devicetree/bindings/serial/omap_serial.txt
> > +++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
> > @@ -1,6 +1,7 @@
> > OMAP UART controller
> >
> > Required properties:
> > +- compatible : should be "ti,am654-uart" for AM654 controllers
>
> Not compatible with any existing TI 8250 UARTs?
Base is compatible, however there are differences in DMA operation and
few additional bits. omap4-uart is sufficient for a basic PIO mode of
operation given initialization a bootloader might do for base console.
I will split the bindings off into it's own patch to keep the confusion
to a minimum and allowing serial driver change to go in independently.
--
Regards,
Nishanth Menon
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC PATCH 3/6] serial: 8250_omap: Add support for AM654 UART controller
@ 2018-06-12 22:03 ` Nishanth Menon
0 siblings, 0 replies; 31+ messages in thread
From: Nishanth Menon @ 2018-06-12 22:03 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree, Sudeep Holla, Vignesh R, Tony Lindgren,
Catalin Marinas, Santosh Shilimkar, Will Deacon, linux-kernel,
Sekhar Nori, Russell King, Tero Kristo, linux-serial,
Greg Kroah-Hartman, linux-arm-kernel
On 21:06-20180612, Rob Herring wrote:
> > diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt b/Documentation/devicetree/bindings/serial/omap_serial.txt
> > index 4b0f05adb228..c35d5ece1156 100644
> > --- a/Documentation/devicetree/bindings/serial/omap_serial.txt
> > +++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
> > @@ -1,6 +1,7 @@
> > OMAP UART controller
> >
> > Required properties:
> > +- compatible : should be "ti,am654-uart" for AM654 controllers
>
> Not compatible with any existing TI 8250 UARTs?
Base is compatible, however there are differences in DMA operation and
few additional bits. omap4-uart is sufficient for a basic PIO mode of
operation given initialization a bootloader might do for base console.
I will split the bindings off into it's own patch to keep the confusion
to a minimum and allowing serial driver change to go in independently.
--
Regards,
Nishanth Menon
^ permalink raw reply [flat|nested] 31+ messages in thread
* [RFC PATCH 3/6] serial: 8250_omap: Add support for AM654 UART controller
@ 2018-06-12 22:03 ` Nishanth Menon
0 siblings, 0 replies; 31+ messages in thread
From: Nishanth Menon @ 2018-06-12 22:03 UTC (permalink / raw)
To: linux-arm-kernel
On 21:06-20180612, Rob Herring wrote:
> > diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt b/Documentation/devicetree/bindings/serial/omap_serial.txt
> > index 4b0f05adb228..c35d5ece1156 100644
> > --- a/Documentation/devicetree/bindings/serial/omap_serial.txt
> > +++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
> > @@ -1,6 +1,7 @@
> > OMAP UART controller
> >
> > Required properties:
> > +- compatible : should be "ti,am654-uart" for AM654 controllers
>
> Not compatible with any existing TI 8250 UARTs?
Base is compatible, however there are differences in DMA operation and
few additional bits. omap4-uart is sufficient for a basic PIO mode of
operation given initialization a bootloader might do for base console.
I will split the bindings off into it's own patch to keep the confusion
to a minimum and allowing serial driver change to go in independently.
--
Regards,
Nishanth Menon
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC PATCH 3/6] serial: 8250_omap: Add support for AM654 UART controller
2018-06-12 21:06 ` Rob Herring
(?)
@ 2018-06-15 17:17 ` Sekhar Nori
-1 siblings, 0 replies; 31+ messages in thread
From: Sekhar Nori @ 2018-06-15 17:17 UTC (permalink / raw)
To: Rob Herring, Nishanth Menon
Cc: Santosh Shilimkar, Will Deacon, Catalin Marinas,
Greg Kroah-Hartman, Mark Rutland, linux-serial, linux-kernel,
devicetree, linux-arm-kernel, Tony Lindgren, Vignesh R,
Tero Kristo, Russell King, Sudeep Holla
Hi Rob,
On Wednesday 13 June 2018 02:36 AM, Rob Herring wrote:
> On Tue, Jun 05, 2018 at 01:01:22AM -0500, Nishanth Menon wrote:
>> AM654 uses a UART controller that is compatible (partially) with
>> existing 8250 UART, however, has a few differences with respect to DMA
>> support and control paths. Introduce a base definition that allows us
>> to build up the differences in follow on patches.
>>
>> Cc: Sekhar Nori <nsekhar@ti.com>
>> Cc: Vignesh R <vigneshr@ti.com>
>> Signed-off-by: Nishanth Menon <nm@ti.com>
>> ---
>> Documentation/devicetree/bindings/serial/omap_serial.txt | 1 +
>> drivers/tty/serial/8250/8250_omap.c | 1 +
>> 2 files changed, 2 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt b/Documentation/devicetree/bindings/serial/omap_serial.txt
>> index 4b0f05adb228..c35d5ece1156 100644
>> --- a/Documentation/devicetree/bindings/serial/omap_serial.txt
>> +++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
>> @@ -1,6 +1,7 @@
>> OMAP UART controller
>>
>> Required properties:
>> +- compatible : should be "ti,am654-uart" for AM654 controllers
>
> Not compatible with any existing TI 8250 UARTs?
Curious on why you asked about this. Are you suggesting why not:
"ti,<new-soc>-uart", "ti,<old-soc>-uart"
or you are asking why introduce "ti,<new-soc>-uart" unless there is
clear demonstrable need for using it in driver code.
In general, I think "ti,<new-soc>-uart", "ti,<old-soc>-uart" in
device-tree (and by extension in binding document) is better even in
there are no _known_ incompatibilities at the time of initial driver
submission. The reason is silicon integration and process differences
many times spill over into driver.
Of course, the idea is not to go postal and create a new compatible for
every pin-compatible part number that gets created, but probably a new
compatible should be created for a new silicon die.
We have just started introducing support for this SoC, and since it
reuses many IPs, this question is likely to come up again.
In this particular case though, Nishanth is perfectly right in not saying
compatible : should be "ti,am654-uart", "ti,omap4-uart"
Because we *know* UART DMA integration is different and a match against
omap4 would result in non-working UART once DMA is enabled by default.
Thanks,
Sekhar
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC PATCH 3/6] serial: 8250_omap: Add support for AM654 UART controller
@ 2018-06-15 17:17 ` Sekhar Nori
0 siblings, 0 replies; 31+ messages in thread
From: Sekhar Nori @ 2018-06-15 17:17 UTC (permalink / raw)
To: Rob Herring, Nishanth Menon
Cc: Mark Rutland, devicetree, Sudeep Holla, Vignesh R, Tony Lindgren,
Catalin Marinas, Santosh Shilimkar, Will Deacon, linux-kernel,
Russell King, Tero Kristo, linux-serial, Greg Kroah-Hartman,
linux-arm-kernel
Hi Rob,
On Wednesday 13 June 2018 02:36 AM, Rob Herring wrote:
> On Tue, Jun 05, 2018 at 01:01:22AM -0500, Nishanth Menon wrote:
>> AM654 uses a UART controller that is compatible (partially) with
>> existing 8250 UART, however, has a few differences with respect to DMA
>> support and control paths. Introduce a base definition that allows us
>> to build up the differences in follow on patches.
>>
>> Cc: Sekhar Nori <nsekhar@ti.com>
>> Cc: Vignesh R <vigneshr@ti.com>
>> Signed-off-by: Nishanth Menon <nm@ti.com>
>> ---
>> Documentation/devicetree/bindings/serial/omap_serial.txt | 1 +
>> drivers/tty/serial/8250/8250_omap.c | 1 +
>> 2 files changed, 2 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt b/Documentation/devicetree/bindings/serial/omap_serial.txt
>> index 4b0f05adb228..c35d5ece1156 100644
>> --- a/Documentation/devicetree/bindings/serial/omap_serial.txt
>> +++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
>> @@ -1,6 +1,7 @@
>> OMAP UART controller
>>
>> Required properties:
>> +- compatible : should be "ti,am654-uart" for AM654 controllers
>
> Not compatible with any existing TI 8250 UARTs?
Curious on why you asked about this. Are you suggesting why not:
"ti,<new-soc>-uart", "ti,<old-soc>-uart"
or you are asking why introduce "ti,<new-soc>-uart" unless there is
clear demonstrable need for using it in driver code.
In general, I think "ti,<new-soc>-uart", "ti,<old-soc>-uart" in
device-tree (and by extension in binding document) is better even in
there are no _known_ incompatibilities at the time of initial driver
submission. The reason is silicon integration and process differences
many times spill over into driver.
Of course, the idea is not to go postal and create a new compatible for
every pin-compatible part number that gets created, but probably a new
compatible should be created for a new silicon die.
We have just started introducing support for this SoC, and since it
reuses many IPs, this question is likely to come up again.
In this particular case though, Nishanth is perfectly right in not saying
compatible : should be "ti,am654-uart", "ti,omap4-uart"
Because we *know* UART DMA integration is different and a match against
omap4 would result in non-working UART once DMA is enabled by default.
Thanks,
Sekhar
^ permalink raw reply [flat|nested] 31+ messages in thread
* [RFC PATCH 3/6] serial: 8250_omap: Add support for AM654 UART controller
@ 2018-06-15 17:17 ` Sekhar Nori
0 siblings, 0 replies; 31+ messages in thread
From: Sekhar Nori @ 2018-06-15 17:17 UTC (permalink / raw)
To: linux-arm-kernel
Hi Rob,
On Wednesday 13 June 2018 02:36 AM, Rob Herring wrote:
> On Tue, Jun 05, 2018 at 01:01:22AM -0500, Nishanth Menon wrote:
>> AM654 uses a UART controller that is compatible (partially) with
>> existing 8250 UART, however, has a few differences with respect to DMA
>> support and control paths. Introduce a base definition that allows us
>> to build up the differences in follow on patches.
>>
>> Cc: Sekhar Nori <nsekhar@ti.com>
>> Cc: Vignesh R <vigneshr@ti.com>
>> Signed-off-by: Nishanth Menon <nm@ti.com>
>> ---
>> Documentation/devicetree/bindings/serial/omap_serial.txt | 1 +
>> drivers/tty/serial/8250/8250_omap.c | 1 +
>> 2 files changed, 2 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt b/Documentation/devicetree/bindings/serial/omap_serial.txt
>> index 4b0f05adb228..c35d5ece1156 100644
>> --- a/Documentation/devicetree/bindings/serial/omap_serial.txt
>> +++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
>> @@ -1,6 +1,7 @@
>> OMAP UART controller
>>
>> Required properties:
>> +- compatible : should be "ti,am654-uart" for AM654 controllers
>
> Not compatible with any existing TI 8250 UARTs?
Curious on why you asked about this. Are you suggesting why not:
"ti,<new-soc>-uart", "ti,<old-soc>-uart"
or you are asking why introduce "ti,<new-soc>-uart" unless there is
clear demonstrable need for using it in driver code.
In general, I think "ti,<new-soc>-uart", "ti,<old-soc>-uart" in
device-tree (and by extension in binding document) is better even in
there are no _known_ incompatibilities at the time of initial driver
submission. The reason is silicon integration and process differences
many times spill over into driver.
Of course, the idea is not to go postal and create a new compatible for
every pin-compatible part number that gets created, but probably a new
compatible should be created for a new silicon die.
We have just started introducing support for this SoC, and since it
reuses many IPs, this question is likely to come up again.
In this particular case though, Nishanth is perfectly right in not saying
compatible : should be "ti,am654-uart", "ti,omap4-uart"
Because we *know* UART DMA integration is different and a match against
omap4 would result in non-working UART once DMA is enabled by default.
Thanks,
Sekhar
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC PATCH 3/6] serial: 8250_omap: Add support for AM654 UART controller
2018-06-15 17:17 ` Sekhar Nori
(?)
@ 2018-06-15 21:56 ` Rob Herring
-1 siblings, 0 replies; 31+ messages in thread
From: Rob Herring @ 2018-06-15 21:56 UTC (permalink / raw)
To: Sekhar Nori
Cc: Nishanth Menon, Santosh Shilimkar, Will Deacon, Catalin Marinas,
Greg Kroah-Hartman, Mark Rutland, open list:SERIAL DRIVERS,
linux-kernel, devicetree,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Tony Lindgren, Vignesh R, Tero Kristo, Russell King,
Sudeep Holla
On Fri, Jun 15, 2018 at 11:17 AM, Sekhar Nori <nsekhar@ti.com> wrote:
> Hi Rob,
>
> On Wednesday 13 June 2018 02:36 AM, Rob Herring wrote:
>> On Tue, Jun 05, 2018 at 01:01:22AM -0500, Nishanth Menon wrote:
>>> AM654 uses a UART controller that is compatible (partially) with
>>> existing 8250 UART, however, has a few differences with respect to DMA
>>> support and control paths. Introduce a base definition that allows us
>>> to build up the differences in follow on patches.
>>>
>>> Cc: Sekhar Nori <nsekhar@ti.com>
>>> Cc: Vignesh R <vigneshr@ti.com>
>>> Signed-off-by: Nishanth Menon <nm@ti.com>
>>> ---
>>> Documentation/devicetree/bindings/serial/omap_serial.txt | 1 +
>>> drivers/tty/serial/8250/8250_omap.c | 1 +
>>> 2 files changed, 2 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt b/Documentation/devicetree/bindings/serial/omap_serial.txt
>>> index 4b0f05adb228..c35d5ece1156 100644
>>> --- a/Documentation/devicetree/bindings/serial/omap_serial.txt
>>> +++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
>>> @@ -1,6 +1,7 @@
>>> OMAP UART controller
>>>
>>> Required properties:
>>> +- compatible : should be "ti,am654-uart" for AM654 controllers
>>
>> Not compatible with any existing TI 8250 UARTs?
>
> Curious on why you asked about this. Are you suggesting why not:
>
> "ti,<new-soc>-uart", "ti,<old-soc>-uart"
Correct.
> or you are asking why introduce "ti,<new-soc>-uart" unless there is
> clear demonstrable need for using it in driver code.
>
> In general, I think "ti,<new-soc>-uart", "ti,<old-soc>-uart" in
> device-tree (and by extension in binding document) is better even in
> there are no _known_ incompatibilities at the time of initial driver
> submission. The reason is silicon integration and process differences
> many times spill over into driver.
Yes, and chip designers can't be trusted. ;)
> Of course, the idea is not to go postal and create a new compatible for
> every pin-compatible part number that gets created, but probably a new
> compatible should be created for a new silicon die.
Yes, that's the criteria I would use too. That's sometimes hard if
it's not the chip vendor doing the DT bindings.
> We have just started introducing support for this SoC, and since it
> reuses many IPs, this question is likely to come up again.
>
> In this particular case though, Nishanth is perfectly right in not saying
>
> compatible : should be "ti,am654-uart", "ti,omap4-uart"
>
> Because we *know* UART DMA integration is different and a match against
> omap4 would result in non-working UART once DMA is enabled by default.
Okay, makes sense. I'd suggest rewording the commit message to include
this. The "compatible to 8250 except for DMA" part I would have
applied to all TI UARTs rather than DMA differences with other TI
UARTs.
Rob
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC PATCH 3/6] serial: 8250_omap: Add support for AM654 UART controller
@ 2018-06-15 21:56 ` Rob Herring
0 siblings, 0 replies; 31+ messages in thread
From: Rob Herring @ 2018-06-15 21:56 UTC (permalink / raw)
To: Sekhar Nori
Cc: Nishanth Menon, Santosh Shilimkar, Will Deacon, Catalin Marinas,
Greg Kroah-Hartman, Mark Rutland, open list:SERIAL DRIVERS,
linux-kernel, devicetree,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Tony Lindgren, Vignesh R, Tero Kristo, Russell King,
Sudeep Holla
On Fri, Jun 15, 2018 at 11:17 AM, Sekhar Nori <nsekhar@ti.com> wrote:
> Hi Rob,
>
> On Wednesday 13 June 2018 02:36 AM, Rob Herring wrote:
>> On Tue, Jun 05, 2018 at 01:01:22AM -0500, Nishanth Menon wrote:
>>> AM654 uses a UART controller that is compatible (partially) with
>>> existing 8250 UART, however, has a few differences with respect to DMA
>>> support and control paths. Introduce a base definition that allows us
>>> to build up the differences in follow on patches.
>>>
>>> Cc: Sekhar Nori <nsekhar@ti.com>
>>> Cc: Vignesh R <vigneshr@ti.com>
>>> Signed-off-by: Nishanth Menon <nm@ti.com>
>>> ---
>>> Documentation/devicetree/bindings/serial/omap_serial.txt | 1 +
>>> drivers/tty/serial/8250/8250_omap.c | 1 +
>>> 2 files changed, 2 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt b/Documentation/devicetree/bindings/serial/omap_serial.txt
>>> index 4b0f05adb228..c35d5ece1156 100644
>>> --- a/Documentation/devicetree/bindings/serial/omap_serial.txt
>>> +++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
>>> @@ -1,6 +1,7 @@
>>> OMAP UART controller
>>>
>>> Required properties:
>>> +- compatible : should be "ti,am654-uart" for AM654 controllers
>>
>> Not compatible with any existing TI 8250 UARTs?
>
> Curious on why you asked about this. Are you suggesting why not:
>
> "ti,<new-soc>-uart", "ti,<old-soc>-uart"
Correct.
> or you are asking why introduce "ti,<new-soc>-uart" unless there is
> clear demonstrable need for using it in driver code.
>
> In general, I think "ti,<new-soc>-uart", "ti,<old-soc>-uart" in
> device-tree (and by extension in binding document) is better even in
> there are no _known_ incompatibilities at the time of initial driver
> submission. The reason is silicon integration and process differences
> many times spill over into driver.
Yes, and chip designers can't be trusted. ;)
> Of course, the idea is not to go postal and create a new compatible for
> every pin-compatible part number that gets created, but probably a new
> compatible should be created for a new silicon die.
Yes, that's the criteria I would use too. That's sometimes hard if
it's not the chip vendor doing the DT bindings.
> We have just started introducing support for this SoC, and since it
> reuses many IPs, this question is likely to come up again.
>
> In this particular case though, Nishanth is perfectly right in not saying
>
> compatible : should be "ti,am654-uart", "ti,omap4-uart"
>
> Because we *know* UART DMA integration is different and a match against
> omap4 would result in non-working UART once DMA is enabled by default.
Okay, makes sense. I'd suggest rewording the commit message to include
this. The "compatible to 8250 except for DMA" part I would have
applied to all TI UARTs rather than DMA differences with other TI
UARTs.
Rob
^ permalink raw reply [flat|nested] 31+ messages in thread
* [RFC PATCH 3/6] serial: 8250_omap: Add support for AM654 UART controller
@ 2018-06-15 21:56 ` Rob Herring
0 siblings, 0 replies; 31+ messages in thread
From: Rob Herring @ 2018-06-15 21:56 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Jun 15, 2018 at 11:17 AM, Sekhar Nori <nsekhar@ti.com> wrote:
> Hi Rob,
>
> On Wednesday 13 June 2018 02:36 AM, Rob Herring wrote:
>> On Tue, Jun 05, 2018 at 01:01:22AM -0500, Nishanth Menon wrote:
>>> AM654 uses a UART controller that is compatible (partially) with
>>> existing 8250 UART, however, has a few differences with respect to DMA
>>> support and control paths. Introduce a base definition that allows us
>>> to build up the differences in follow on patches.
>>>
>>> Cc: Sekhar Nori <nsekhar@ti.com>
>>> Cc: Vignesh R <vigneshr@ti.com>
>>> Signed-off-by: Nishanth Menon <nm@ti.com>
>>> ---
>>> Documentation/devicetree/bindings/serial/omap_serial.txt | 1 +
>>> drivers/tty/serial/8250/8250_omap.c | 1 +
>>> 2 files changed, 2 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt b/Documentation/devicetree/bindings/serial/omap_serial.txt
>>> index 4b0f05adb228..c35d5ece1156 100644
>>> --- a/Documentation/devicetree/bindings/serial/omap_serial.txt
>>> +++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
>>> @@ -1,6 +1,7 @@
>>> OMAP UART controller
>>>
>>> Required properties:
>>> +- compatible : should be "ti,am654-uart" for AM654 controllers
>>
>> Not compatible with any existing TI 8250 UARTs?
>
> Curious on why you asked about this. Are you suggesting why not:
>
> "ti,<new-soc>-uart", "ti,<old-soc>-uart"
Correct.
> or you are asking why introduce "ti,<new-soc>-uart" unless there is
> clear demonstrable need for using it in driver code.
>
> In general, I think "ti,<new-soc>-uart", "ti,<old-soc>-uart" in
> device-tree (and by extension in binding document) is better even in
> there are no _known_ incompatibilities at the time of initial driver
> submission. The reason is silicon integration and process differences
> many times spill over into driver.
Yes, and chip designers can't be trusted. ;)
> Of course, the idea is not to go postal and create a new compatible for
> every pin-compatible part number that gets created, but probably a new
> compatible should be created for a new silicon die.
Yes, that's the criteria I would use too. That's sometimes hard if
it's not the chip vendor doing the DT bindings.
> We have just started introducing support for this SoC, and since it
> reuses many IPs, this question is likely to come up again.
>
> In this particular case though, Nishanth is perfectly right in not saying
>
> compatible : should be "ti,am654-uart", "ti,omap4-uart"
>
> Because we *know* UART DMA integration is different and a match against
> omap4 would result in non-working UART once DMA is enabled by default.
Okay, makes sense. I'd suggest rewording the commit message to include
this. The "compatible to 8250 except for DMA" part I would have
applied to all TI UARTs rather than DMA differences with other TI
UARTs.
Rob
^ permalink raw reply [flat|nested] 31+ messages in thread
end of thread, other threads:[~2018-06-15 21:56 UTC | newest]
Thread overview: 31+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-06-05 6:01 [RFC PATCH 0/6] arm64: Initial support Texas Instrument's AM654 Platform Nishanth Menon
2018-06-05 6:01 ` Nishanth Menon
2018-06-05 6:01 ` Nishanth Menon
2018-06-05 6:01 ` [RFC PATCH 1/6] Documentation: arm: ti: Add bindings for AM654 SoC Nishanth Menon
2018-06-05 6:01 ` Nishanth Menon
2018-06-05 6:01 ` Nishanth Menon
2018-06-12 21:05 ` Rob Herring
2018-06-12 21:05 ` Rob Herring
2018-06-12 22:01 ` Nishanth Menon
2018-06-12 22:01 ` Nishanth Menon
2018-06-12 22:01 ` Nishanth Menon
2018-06-05 6:01 ` [RFC PATCH 2/6] arm64: Add support for TI's K3 Multicore SoC architecture Nishanth Menon
2018-06-05 6:01 ` Nishanth Menon
2018-06-05 6:01 ` Nishanth Menon
2018-06-05 6:01 ` [RFC PATCH 3/6] serial: 8250_omap: Add support for AM654 UART controller Nishanth Menon
2018-06-05 6:01 ` Nishanth Menon
2018-06-05 6:01 ` Nishanth Menon
2018-06-12 21:06 ` Rob Herring
2018-06-12 21:06 ` Rob Herring
2018-06-12 22:03 ` Nishanth Menon
2018-06-12 22:03 ` Nishanth Menon
2018-06-12 22:03 ` Nishanth Menon
2018-06-15 17:17 ` Sekhar Nori
2018-06-15 17:17 ` Sekhar Nori
2018-06-15 17:17 ` Sekhar Nori
2018-06-15 21:56 ` Rob Herring
2018-06-15 21:56 ` Rob Herring
2018-06-15 21:56 ` Rob Herring
2018-06-05 6:01 ` [RFC PATCH 4/6] serial: 8250_omap: Make 8250_omap driver driver depend on ARCH_K3 Nishanth Menon
2018-06-05 6:01 ` Nishanth Menon
2018-06-05 6:01 ` Nishanth Menon
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.