[RFC PATCH 0/6] arm64: Initial support Texas Instrument's AM654 Platform

[RFC PATCH 0/6] arm64: Initial support Texas Instrument's AM654 Platform

[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

[RFC PATCH 1/6] Documentation: arm: ti: Add bindings for AM654 SoC

[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

[RFC PATCH 2/6] arm64: Add support for TI's K3 Multicore SoC architecture

[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

[RFC PATCH 3/6] serial: 8250_omap: Add support for AM654 UART controller

[Nishanth Menon]

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

[RFC PATCH 4/6] serial: 8250_omap: Make 8250_omap driver driver depend on ARCH_K3

[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

Re: [RFC PATCH 1/6] Documentation: arm: ti: Add bindings for AM654 SoC

[Rob Herring]

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
> 

Re: [RFC PATCH 3/6] serial: 8250_omap: Add support for AM654 UART controller

[Rob Herring]

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
> 

Re: [RFC PATCH 1/6] Documentation: arm: ti: Add bindings for AM654 SoC

[Nishanth Menon]

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

Re: [RFC PATCH 3/6] serial: 8250_omap: Add support for AM654 UART controller

[Nishanth Menon]

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

Re: [RFC PATCH 3/6] serial: 8250_omap: Add support for AM654 UART controller

[Sekhar Nori]

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

Re: [RFC PATCH 3/6] serial: 8250_omap: Add support for AM654 UART controller

[Rob Herring]

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