On 11:25-20210121, Suman Anna wrote: > On 1/20/21 2:25 PM, Dave Gerlach wrote: > > 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 <faiz_abbas@xxxxxx> > > Signed-off-by: Aswath Govindraju <a-govindraju@xxxxxx> > > Hmm, there are a few pieces contributed by me, so please do add > > Signed-off-by: Suman Anna <s-anna@xxxxxx> Sure, thanks.. [...] > > + > > + 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
