Re: [PATCH v2 0/4] Add overlays to disable optional hardware in k3-am6xx-phycore-som boards

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 6/12/24 3:19 AM, Vignesh Raghavendra wrote:

On 05/06/24 04:45, Nathan Morrisson wrote:
Hi Vignesh,

On 6/3/24 10:41 AM, Vignesh Raghavendra wrote:
Hi Nathan,

On 29/05/24 04:21, Nathan Morrisson wrote:
Add three overlays to disable the eth phy, rtc, and spi nor. These
overlays will be used to disable device tree nodes for components
that are optionally not populated.

v2:
    - Add build time tests in makefile

Nathan Morrisson (4):
    arm64: dts: ti: k3-am64-phycore-som: Add serial_flash label
    arm64: dts: ti: k3-am6xx-phycore-som: Add overlay to disable eth phy
    arm64: dts: ti: k3-am6xx-phycore-som: Add overlay to disable rtc
    arm64: dts: ti: k3-am6xx-phycore-som: Add overlay to disabl spi nor

   arch/arm64/boot/dts/ti/Makefile               | 17 +++++++++++++++++
   .../boot/dts/ti/k3-am64-phycore-som.dtsi      |  2 +-
   .../ti/k3-am6xx-phycore-disable-eth-phy.dtso  | 19 +++++++++++++++++++
   .../dts/ti/k3-am6xx-phycore-disable-rtc.dtso  | 15 +++++++++++++++
   .../ti/k3-am6xx-phycore-disable-spi-nor.dtso  | 15 +++++++++++++++
   5 files changed, 67 insertions(+), 1 deletion(-)
   create mode 100644
arch/arm64/boot/dts/ti/k3-am6xx-phycore-disable-eth-phy.dtso
   create mode 100644
arch/arm64/boot/dts/ti/k3-am6xx-phycore-disable-rtc.dtso
   create mode 100644
arch/arm64/boot/dts/ti/k3-am6xx-phycore-disable-spi-nor.dtso

I am not sure if this a common practice to have overlays to disable
missing components (at least I dont see such dtso in kernel). I would
like to see an what DT maintainers feel as such dtsos can explode in
numbers.

Is this something that U-Boot can detect and fix up for the Linux DT?
We have an EEPROM on our board with information on what is populated on
that particular board. We will apply these overlays based on that EEPROM
data.
Typical usage of overlay is to keep the minimum in baseboard and enable
optional components in the overlay. But it would also depend on whats
information is present in the EEPROM.

Could you provide bit more color on whats in EEPROM and how each overlay
would be applied? Please add the same to commit message and respin.

The EEPROM contains information about the configuration of the board. The standard configuration has an ethernet phy, rtc, and spi nor. These components can be left out to save cost, and that configuration information is what is stored in the EEPROM. If these components are not used, then we would use these overlays to change the device tree appropriately.

I will send a new version with this in the commit, and there is also a more detailed explanation at [1].

[1] https://lore.kernel.org/lkml/4e7dd467-20be-43ce-936d-200ede6d511b@xxxxxxxxx/

Regards,

Nathan


Unpopulated SPI flash and RTC should ideally not be an issue as drivers
would gracefully fail albeit with some sort of error msg.
Not so sure about Eth PHYs though.

Also, Are these dtso's mutually exclusive? ie can SoM have SPI flash but
not RTC, have RTC and SPI Flash but no ETH PHY?
They are not mutually exclusive, you could have any combination of
overlays applied.


Regards,

Nathan





[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux