On 11:25-20210121, Suman Anna wrote:

On 1/20/21 2:25 PM, Dave Gerlach wrote:

quoted

The AM642 SoC belongs to the K3 Multicore SoC architecture platform,
providing advanced system integration to enable applications such as
Motor Drives, PLC, Remote IO and IoT Gateways.

Some highlights of this SoC are:
* Dual Cortex-A53s in a single cluster, two clusters of dual Cortex-R5F
  MCUs, and a single Cortex-M4F.
* Two Gigabit Industrial Communication Subsystems (ICSSG).
* Integrated Ethernet switch supporting up to a total of two external
  ports.
* PCIe-GEN2x1L, USB3/USB2, 2xCAN-FD, eMMC and SD, UFS, OSPI memory
  controller, QSPI, I2C, eCAP/eQEP, ePWM, ADC, among other
  peripherals.
* Centralized System Controller for Security, Power, and Resource
  Management (DMSC).

See AM64X Technical Reference Manual (SPRUIM2, Nov 2020)
for further details: https://www.ti.com/lit/pdf/spruim2

Introduce basic support for the AM642 SoC to enable ramdisk or MMC
boot. Introduce the sdhci, i2c, spi, and uart MAIN domain periperhals
under cbass_main and the i2c, spi, and uart MCU domain periperhals
under cbass_mcu.

Signed-off-by: Faiz Abbas <redacted>
Signed-off-by: Aswath Govindraju <redacted>

Hmm, there are a few pieces contributed by me, so please do add

Signed-off-by: Suman Anna <redacted>

Sure, thanks..

[...]

quoted

+
+	sdhci0: mmc@fa10000 {
+		compatible = "ti,am64-sdhci-8bit";

Hmm, I tried booting this series on top of 5.11-rc1 + Nishanth's current
ti-k3-dts-next. So, boot of these patches using this baseline fails when using
MMC rootfs, but is ok when using initramfs. This particular compatible and the
corresponding driver change are only in linux-next coming through couple of
patches from the MMC subsystem.

I am not sure why we would be including stuff that's dependent on some other
patches being merged from a different sub-system? Strangely, this ought to be
caught by dtbs_check, but it is not throwing any errors.

IMHO, these should only be added if you have no other external dependencies
especially when you are applying on a 5.11-rc baseline. The MMC pull-requests
would not go through arm-soc either.

Yes, I am aware of this - this is no different from integration we have
done in the past as well.. intent is to get bindings in via subsystem
trees and dts changes via arm-soc. I always insist that basic ramdisk
boot always in the basic introduction tree. mmc, nfs are add-ons that
get added via subsystem tree and I host the dts changes - in this case
every dts node binding is fine with subsystems already queued in
linux-next. And this is no different from what I have noticed on other
ARM SoC maintainer trees as well.

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D