| Message ID | 20220203140240.973690-1-matthias.schiffer@ew.tq-group.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v2,1/2] arm64: dts: ti: k3-am65: disable optional peripherals by default | expand |
Rob, Tony, Arnd, SoC maintainers, On 15:02-20220203, Matthias Schiffer wrote: > All peripherals that require pinmuxing or other configuration to work > should be disabled by default. Dependent DTS are adjusted accordingly. https://lore.kernel.org/linux-arm-kernel/20201112183538.6805-1-nm@ti.com/ reversal all over again. Is there a specific pattern we are intending to use here? Because, if we are going down this path (which would be a major churn across multiple downstream trees as well) - I'd rather have this as a documented standard and not just a TI approach and will need to be done across all K3 devices. Are you aware of such a documented guideline, rather than "word of mouth"? Maybe I have'nt looked deep enough, but checking.. > > The following nodes are now "disabled" according to dtx_diff and were not > overridden to "okay", as they define no pinctrl: > k3-am654-base-board: > - mcu_i2c0 > - mcu_spi0..2 > - mcu_uart0 > - cal > - main_i2c3 > - ehrpwm0..5 > - main_uart1..2 > - main_spi1..4 > > k3-am65-iot2050*: > - mci_spi1..2 > - cal > - ehrpwm0..5 > - main_spi0..4 > > Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> > --- [...] > diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi > index ce8bb4a61011e..5aa425d1ba802 100644 > --- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi > +++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi > @@ -64,6 +64,7 @@ serdes0: serdes@900000 { > ti,serdes-clk = <&serdes0_clk>; [...] > @@ -1337,6 +1388,7 @@ icssg2_mdio: mdio@32400 { > #address-cells = <1>; > #size-cells = <0>; > bus_freq = <1000000>; > + status = "disabled"; > }; > }; > }; > diff --git a/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi b/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi > index 8d592bf41d6f1..57ac3a493adbe 100644 > --- a/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi > +++ b/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi > @@ -22,11 +22,12 @@ phy_gmii_sel: phy@4040 { > > mcu_uart0: serial@40a00000 { > compatible = "ti,am654-uart"; > - reg = <0x00 0x40a00000 0x00 0x100>; > - interrupts = <GIC_SPI 565 IRQ_TYPE_LEVEL_HIGH>; > - clock-frequency = <96000000>; > - current-speed = <115200>; > - power-domains = <&k3_pds 149 TI_SCI_PD_EXCLUSIVE>; > + reg = <0x00 0x40a00000 0x00 0x100>; > + interrupts = <GIC_SPI 565 IRQ_TYPE_LEVEL_HIGH>; > + clock-frequency = <96000000>; > + current-speed = <115200>; > + power-domains = <&k3_pds 149 TI_SCI_PD_EXCLUSIVE>; When doing these kind of changes, do not include ancillary tab cleanups. keep such cleanups separate patch. > + status = "disabled"; > }; > > mcu_ram: sram@41c00000 { > @@ -46,6 +47,7 @@ mcu_i2c0: i2c@40b00000 { > clock-names = "fck"; > clocks = <&k3_clks 114 1>; > power-domains = <&k3_pds 114 TI_SCI_PD_EXCLUSIVE>; > + status = "disabled"; > }; > > mcu_spi0: spi@40300000 { > @@ -56,6 +58,7 @@ mcu_spi0: spi@40300000 { > power-domains = <&k3_pds 142 TI_SCI_PD_EXCLUSIVE>; > #address-cells = <1>; > #size-cells = <0>; > + status = "disabled"; > }; >
Hi, * Nishanth Menon <nm@ti.com> [220204 14:30]: > Rob, Tony, Arnd, SoC maintainers, > > On 15:02-20220203, Matthias Schiffer wrote: > > All peripherals that require pinmuxing or other configuration to work > > should be disabled by default. Dependent DTS are adjusted accordingly. Disabling SoC internal devices by default is not a good policy. The devices are available even if not pinned out. Disabling device by default causes runtime PM to not work as the kernel will completely ignore the disabled devices. And this means you add a dependency to some certain version of a bootloader for PM to work. Additionally tagging devices as disabled by default (and then again re-enabling them in the board specific dts files) is just pointless churn and bloat. See for example commit 12afc0cf8121 ("ARM: dts: Drop pointless status changing for am3 musb") :) If you really want to disable some devices for memory usage or other reasons, do it in the board specific dts files. > https://lore.kernel.org/linux-arm-kernel/20201112183538.6805-1-nm@ti.com/ > reversal all over again. > > Is there a specific pattern we are intending to use here? Because, if we > are going down this path (which would be a major churn across multiple > downstream trees as well) - I'd rather have this as a documented > standard and not just a TI approach and will need to be done across all > K3 devices. > > Are you aware of such a documented guideline, rather than "word of > mouth"? Maybe I have'nt looked deep enough, but checking.. For SoCs that don't implement runtime PM the policy can be different without causing any harm. But for any SoCs implementing runtime PM, an unknown state from the bootloader is not going to work. Regards, Tony
On Mon, 2022-02-07 at 08:54 +0200, Tony Lindgren wrote: > Hi, > > * Nishanth Menon <nm@ti.com> [220204 14:30]: > > Rob, Tony, Arnd, SoC maintainers, > > > > On 15:02-20220203, Matthias Schiffer wrote: > > > All peripherals that require pinmuxing or other configuration to > > > work > > > should be disabled by default. Dependent DTS are adjusted > > > accordingly. > > Disabling SoC internal devices by default is not a good policy. The > devices are available even if not pinned out. Disabling device by > default > causes runtime PM to not work as the kernel will completely ignore > the > disabled devices. And this means you add a dependency to some certain > version of a bootloader for PM to work. > > Additionally tagging devices as disabled by default (and then again > re-enabling them in the board specific dts files) is just pointless > churn and bloat. See for example commit 12afc0cf8121 ("ARM: dts: Drop > pointless status changing for am3 musb") :) > > If you really want to disable some devices for memory usage or other > reasons, do it in the board specific dts files. Attempting to use unmuxed peripherals often leads to ugly errors - I2C without pullups appearing busy, UARTs in endless break condition, ... Such errors are often seen as defects in hardware or software by people who aren't familiar with the internals. I can see the issue with bootloaders leaving peripherals in an unknown state, but I'm not happy with keeping such devices enabled in the kernel either. Generally I think that it's a bootloader's responsiblity to disable unneeded devices - the kernel may not even have a driver for some peripherals, leading to the same behaviour as a "disabled" status. For this reason I believe that it should always be okay to set unneeded devices to "disabled", and it should be considered a safe default. I'm not sure what the consensus on these issues is. I'm more familiar with NXP's i.MX and Layerscape SoCs, where it's common to have all muxable peripherals set to "disabled" in the base DTSI, and a quick grep through a few dts directories gives me the impression that this is the case for most other vendors as well. Regards, Matthias > > > https://lore.kernel.org/linux-arm-kernel/20201112183538.6805-1-nm@ti.com/ > > reversal all over again. > > > > Is there a specific pattern we are intending to use here? Because, > > if we > > are going down this path (which would be a major churn across > > multiple > > downstream trees as well) - I'd rather have this as a documented > > standard and not just a TI approach and will need to be done across > > all > > K3 devices. > > > > Are you aware of such a documented guideline, rather than "word of > > mouth"? Maybe I have'nt looked deep enough, but checking.. > > For SoCs that don't implement runtime PM the policy can be different > without causing any harm. But for any SoCs implementing runtime PM, > an > unknown state from the bootloader is not going to work. > > Regards, > > Tony
* Matthias Schiffer <matthias.schiffer@ew.tq-group.com> [220207 08:45]: > Generally I think that it's a bootloader's responsiblity to disable > unneeded devices - the kernel may not even have a driver for some > peripherals, leading to the same behaviour as a "disabled" status. For > this reason I believe that it should always be okay to set unneeded > devices to "disabled", and it should be considered a safe default. Not possible, think kexec for example :) How would the previous kernel even know what to disable if Linux has no idea about the devices? If there are issues you're seeing, it's likely a bug in some of the device drivers for not checking for the necessary resources like pinctrl for i2c lines. > I'm not sure what the consensus on these issues is. I'm more familiar > with NXP's i.MX and Layerscape SoCs, where it's common to have all > muxable peripherals set to "disabled" in the base DTSI, and a quick > grep through a few dts directories gives me the impression that this is > the case for most other vendors as well. This approach only works for SoCs that don't need the kernel to idle devices for runtime PM. Regards, Tony
On Mon, 2022-02-07 at 13:25 +0200, Tony Lindgren wrote: > * Matthias Schiffer <matthias.schiffer@ew.tq-group.com> [220207 > 08:45]: > > Generally I think that it's a bootloader's responsiblity to disable > > unneeded devices - the kernel may not even have a driver for some > > peripherals, leading to the same behaviour as a "disabled" status. > > For > > this reason I believe that it should always be okay to set unneeded > > devices to "disabled", and it should be considered a safe default. > > Not possible, think kexec for example :) How would the previous > kernel > even know what to disable if Linux has no idea about the devices? Well, optimally, bootloader and all kernels would agree on the devices that are actually available, but I get your point. > > If there are issues you're seeing, it's likely a bug in some of the > device drivers for not checking for the necessary resources like > pinctrl for i2c lines. I don't think it's common for individual drivers to care about pinctrl unless switching between different pin settings is required at runtime. Many drivers can be used on different hardware, some of which may require pinmuxing, while others don't. Also, what is the expected behavior of a driver that is probed for an unusable device? Wouldn't this require some as-of-yet nonexisting status between "okay" and "disabled" that conveys something like "probe this device, initialize (and disable) PM, but don't register anything", so no unusable devices become visible to userspace (and possibly other kernel drivers)? > > > I'm not sure what the consensus on these issues is. I'm more > > familiar > > with NXP's i.MX and Layerscape SoCs, where it's common to have all > > muxable peripherals set to "disabled" in the base DTSI, and a quick > > grep through a few dts directories gives me the impression that > > this is > > the case for most other vendors as well. > > This approach only works for SoCs that don't need the kernel to idle > devices for runtime PM. I'm pretty sure that most modern SoCs I looked at have runtime PM, and it is simply expected that unusable devices are never enabled in the first place, so there is no need for the kernel to know about them. Regards, Matthias > Regards, > > Tony
* Matthias Schiffer <matthias.schiffer@ew.tq-group.com> [220208 10:53]: > On Mon, 2022-02-07 at 13:25 +0200, Tony Lindgren wrote: > > * Matthias Schiffer <matthias.schiffer@ew.tq-group.com> [220207 > > 08:45]: > > > Generally I think that it's a bootloader's responsiblity to disable > > > unneeded devices - the kernel may not even have a driver for some > > > peripherals, leading to the same behaviour as a "disabled" status. > > > For > > > this reason I believe that it should always be okay to set unneeded > > > devices to "disabled", and it should be considered a safe default. > > > > Not possible, think kexec for example :) How would the previous > > kernel > > even know what to disable if Linux has no idea about the devices? > > Well, optimally, bootloader and all kernels would agree on the devices > that are actually available, but I get your point. > > > > > If there are issues you're seeing, it's likely a bug in some of the > > device drivers for not checking for the necessary resources like > > pinctrl for i2c lines. > > I don't think it's common for individual drivers to care about pinctrl > unless switching between different pin settings is required at runtime. > Many drivers can be used on different hardware, some of which may > require pinmuxing, while others don't. Yeah that's true, some configurations only do pin muxing in the bootloader. So pins are not a good criteria for devicetree status enabled for when the device is operational. Probably a better criteria for devicetree "operational" status is the device can be clocked and configured or idled. Some devices like GPUs can render to memory with no external pin configuration for example. Following Linux running on a PC analogy.. If ACPI has some device that causes driver warnings on Linux boot, do we patch the ACPI table and pretend the device does not exist? Or do we patch the device driver to deal with the random buggy bootloader state for the device? :) > Also, what is the expected behavior of a driver that is probed for an > unusable device? Wouldn't this require some as-of-yet nonexisting > status between "okay" and "disabled" that conveys something like "probe > this device, initialize (and disable) PM, but don't register anything", > so no unusable devices become visible to userspace (and possibly other > kernel drivers)? I did some experimental patches several years ago to add devicetree status for incomplete, but eventually came to the conclusion that it was not really needed. Feel free to revisit that if you have the spare cycles :) Having the drivers check for the resources like clocks and then just idle the device after probe solved the issues I was seeing for warnings and kexec. In some cases the device may need to be reset or at least properly reconfigured in the probe as the state can be unknown from the bootloader. That's about all there is to it. Sure you could save some memory with less instances for some devices, so maybe the status = "incomplete" could be used to do the trick for that. > > > I'm not sure what the consensus on these issues is. I'm more > > > familiar > > > with NXP's i.MX and Layerscape SoCs, where it's common to have all > > > muxable peripherals set to "disabled" in the base DTSI, and a quick > > > grep through a few dts directories gives me the impression that > > > this is > > > the case for most other vendors as well. > > > > This approach only works for SoCs that don't need the kernel to idle > > devices for runtime PM. > > I'm pretty sure that most modern SoCs I looked at have runtime PM, and > it is simply expected that unusable devices are never enabled in the > first place, so there is no need for the kernel to know about them. Yeah well that assumption is the difference in getting runtime PM to work in a sane way across multiple SoCs and devices :) Devices tagged with status = "disabled" are completely ignored by the kernel. Interconnect and bus related code may not know the details on how to reset and idle the child devices. Relying on firmware to do the reset and idle of unused devices may be too generic, can be buggy, and probably depends on the firmware revision. Regards, Tony
Hi Matthias Schiffer, On Thu, 3 Feb 2022 15:02:39 +0100, Matthias Schiffer wrote: > All peripherals that require pinmuxing or other configuration to work > should be disabled by default. Dependent DTS are adjusted accordingly. > > The following nodes are now "disabled" according to dtx_diff and were not > overridden to "okay", as they define no pinctrl: > > k3-am654-base-board: > - mcu_i2c0 > - mcu_spi0..2 > - mcu_uart0 > - cal > - main_i2c3 > - ehrpwm0..5 > - main_uart1..2 > - main_spi1..4 > > [...] Patch 1 of the series, I have'nt pickedup given the argumentation we have had in the thread.. if we need a broader alignment, I am all for it, but lets start pushing from updating a process document as a discussion point.. I bet that should start triggering more debates. I have applied the following (patch #2) to branch ti-k3-dts-next on [1] with minor cosmetic (subject line capitalization, message format to 70 char) fixups.. Thank you! [2/2] arm64: dts: ti: k3-am65*: remove #address-cells/#size-cells from flash nodes commit: 292b0dd7cdc1b00a8acb199605ecf73bb253c5b5 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent up the chain during the next merge window (or sooner if it is a relevant bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. [1] git://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git
On Tue, 2022-02-08 at 13:52 +0200, Tony Lindgren wrote: > * Matthias Schiffer <matthias.schiffer@ew.tq-group.com> [220208 > 10:53]: > > On Mon, 2022-02-07 at 13:25 +0200, Tony Lindgren wrote: > > > * Matthias Schiffer <matthias.schiffer@ew.tq-group.com> [220207 > > > 08:45]: > > > > Generally I think that it's a bootloader's responsiblity to > > > > disable > > > > unneeded devices - the kernel may not even have a driver for > > > > some > > > > peripherals, leading to the same behaviour as a "disabled" > > > > status. > > > > For > > > > this reason I believe that it should always be okay to set > > > > unneeded > > > > devices to "disabled", and it should be considered a safe > > > > default. > > > > > > Not possible, think kexec for example :) How would the previous > > > kernel > > > even know what to disable if Linux has no idea about the devices? > > > > Well, optimally, bootloader and all kernels would agree on the > > devices > > that are actually available, but I get your point. > > > > > If there are issues you're seeing, it's likely a bug in some of > > > the > > > device drivers for not checking for the necessary resources like > > > pinctrl for i2c lines. > > > > I don't think it's common for individual drivers to care about > > pinctrl > > unless switching between different pin settings is required at > > runtime. > > Many drivers can be used on different hardware, some of which may > > require pinmuxing, while others don't. > > Yeah that's true, some configurations only do pin muxing in the > bootloader. So pins are not a good criteria for devicetree status > enabled > for when the device is operational. > > Probably a better criteria for devicetree "operational" status is the > device can be clocked and configured or idled. Some devices like GPUs > can render to memory with no external pin configuration for example. > I don't think any properties currently exist that could or should be used to decide whether a device is operational. Clocks etc. are usually internal to the SoC and thus already set in the SoC DTSI. Pins and power supplies may be specific to a mainboard, but can also be optional. Whether an I2C bus can be operational may solely depend on whether external pullups are connected to the pins or not. The idea of an "incomplete" status like you mention below sounds better to me. I also thought about adding something like a "probe_disabled()" that is called instead of probe() for "disabled" devices, but I assume that would cause a boot time penalty on systems that have many "disabled" devices and don't actually need this... > Following Linux running on a PC analogy.. If ACPI has some device > that > causes driver warnings on Linux boot, do we patch the ACPI table and > pretend the device does not exist? Or do we patch the device driver > to > deal with the random buggy bootloader state for the device? :) > > > Also, what is the expected behavior of a driver that is probed for > > an > > unusable device? Wouldn't this require some as-of-yet nonexisting > > status between "okay" and "disabled" that conveys something like > > "probe > > this device, initialize (and disable) PM, but don't register > > anything", > > so no unusable devices become visible to userspace (and possibly > > other > > kernel drivers)? > > I did some experimental patches several years ago to add devicetree > status for incomplete, but eventually came to the conclusion that it > was not really needed. Feel free to revisit that if you have the > spare cycles :) > > Having the drivers check for the resources like clocks and then just > idle the device after probe solved the issues I was seeing for > warnings > and kexec. In some cases the device may need to be reset or at least > properly reconfigured in the probe as the state can be unknown from > the > bootloader. That's about all there is to it. Sure you could save some > memory with less instances for some devices, so maybe the status = > "incomplete" could be used to do the trick for that. I don't really care about memory usage. What I do care about is that incorrect userspace usage doesn't cause ugly kernel warnings (for example timeouts for i2cdetect on unmuxed bus) when we can avoid it, because such issues always lead to support requests. Not being able to hide non-operational devices from userspace feels like a regression from older hardware. > > > > > I'm not sure what the consensus on these issues is. I'm more > > > > familiar > > > > with NXP's i.MX and Layerscape SoCs, where it's common to have > > > > all > > > > muxable peripherals set to "disabled" in the base DTSI, and a > > > > quick > > > > grep through a few dts directories gives me the impression that > > > > this is > > > > the case for most other vendors as well. > > > > > > This approach only works for SoCs that don't need the kernel to > > > idle > > > devices for runtime PM. > > > > I'm pretty sure that most modern SoCs I looked at have runtime PM, > > and > > it is simply expected that unusable devices are never enabled in > > the > > first place, so there is no need for the kernel to know about them. > > Yeah well that assumption is the difference in getting runtime PM to > work in a sane way across multiple SoCs and devices :) > > Devices tagged with status = "disabled" are completely ignored by the > kernel. Interconnect and bus related code may not know the details on > how to reset and idle the child devices. Relying on firmware to do > the > reset and idle of unused devices may be too generic, can be buggy, > and > probably depends on the firmware revision. Well, so far it seems like the `status = "disabled"` is just being pushed from the SoC DTSIs to the board DTSs on TI hardware. For the AM64 platform (which is fairly similar to the AM65), both mainboards that currently exist disable unused UARTs, I2C/SPI busses, PWMs, ... (Some of these might be disabled to make them usable from the R5/M4 cores, but I don't think that the case for all of them - "reserved" would be more appropriate than "disabled" in these cases anyways) AFAICT, disabling non-operatational devices in the board DTS instead of the SoC DTSI is worse than the alternatives in every way: - Verbose board DTS: You have to think about all the devices that exist in the SoC, not just the ones you want to use - Adding new nodes without `status = "disabled" to SoC DTSI can potentially cause issues on dependent boards - It doesn't solve the issues that not having `status = "disabled"` in the DTSI is supposed to solve Regards, Matthias > > Regards, > > Tony
Hi, * Matthias Schiffer <matthias.schiffer@ew.tq-group.com> [220228 10:29]: > AFAICT, disabling non-operatational devices in the board DTS instead of > the SoC DTSI is worse than the alternatives in every way: > > - Verbose board DTS: You have to think about all the devices that exist > in the SoC, not just the ones you want to use > - Adding new nodes without `status = "disabled" to SoC DTSI can > potentially cause issues on dependent boards > - It doesn't solve the issues that not having `status = "disabled"` in > the DTSI is supposed to solve My preference is the least amount of tinkering in the dts files naturally :) It really does not matter if the extra dts churn is to enable or disable devices, it should not be needed at all. To summarize, my main point really is the following: There should not be any need to tag the SoC internal devices with anything in the dts files. The device drivers should be able to just deal with the situation. IMO devices should be tagged with disabled or reserved when they are not accessible for example because of being used by secure mode for example. If the the status needs to be set to anything, it really is a symptom of incomplete handling somewhere. Regards, Tony
On Wed, 2022-03-09 at 11:11 +0200, Tony Lindgren wrote: > Hi, > > * Matthias Schiffer <matthias.schiffer@ew.tq-group.com> [220228 > 10:29]: > > AFAICT, disabling non-operatational devices in the board DTS > > instead of > > the SoC DTSI is worse than the alternatives in every way: > > > > - Verbose board DTS: You have to think about all the devices that > > exist > > in the SoC, not just the ones you want to use > > - Adding new nodes without `status = "disabled" to SoC DTSI can > > potentially cause issues on dependent boards > > - It doesn't solve the issues that not having `status = "disabled"` > > in > > the DTSI is supposed to solve > > My preference is the least amount of tinkering in the dts files > naturally :) It really does not matter if the extra dts churn is to > enable or disable devices, it should not be needed at all. > > To summarize, my main point really is the following: > > There should not be any need to tag the SoC internal devices with > anything > in the dts files. The device drivers should be able to just deal with > the > situation. IMO devices should be tagged with disabled or reserved > when > they are not accessible for example because of being used by secure > mode > for example. If the the status needs to be set to anything, it really > is > a symptom of incomplete handling somewhere. > > Regards, > > Tony Hi Tony, while I agree that it would be great if drivers could just detect when hardware is not available, this is simply not how most drivers work - when you instantiate the driver via a non-disabled(/reserved/...) DT node, the driver expects a usable device. Especially for busses like I2C, there is no way for a driver to reliably detect whether the bus is usable or not. (There are several states that can't really be distinguished: Is pinmuxing missing, or does the device not need any muxing? Is a line low because it is not actually connected to anything, or is there another master currently using the bus, or is the bus stuck due to a faulty device?) Which is why it is the convention for SoC DTSI files disable nodes for devices that may be unusable. Taking UARTs as an example, a quick grep for "serial@" nodes in arch/arm/boot/dts/*.dtsi and arch/arm64/boot/dts/*/*.dtsi shows that the vast majority of these nodes is disabled by default. Regards, Matthias
* Matthias Schiffer <matthias.schiffer@ew.tq-group.com> [220309 11:09]: > while I agree that it would be great if drivers could just detect when > hardware is not available, this is simply not how most drivers work - > when you instantiate the driver via a non-disabled(/reserved/...) DT > node, the driver expects a usable device. > > Especially for busses like I2C, there is no way for a driver to > reliably detect whether the bus is usable or not. (There are several > states that can't really be distinguished: Is pinmuxing missing, or > does the device not need any muxing? Is a line low because it is not > actually connected to anything, or is there another master currently > using the bus, or is the bus stuck due to a faulty device?) Well how about set only the problem devices with status = "disabled" with a proper comment in the SoC dtsi file? See for example what has been done in arch/arm64/boot/dts/apple that has been pretty widely reviewed and done with a good taste :) Not sure what can be done to idle the unused devices in the disabled case though, maybe some firmware call to disable all unclaimed devices could be done if it does not exist already. The firmware may not have the capability to idle devices that need firmware loaded to idle them for example though. Regards, Tony
diff --git a/arch/arm64/boot/dts/ti/k3-am65-iot2050-common-pg1.dtsi b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common-pg1.dtsi index 51f902fa35a73..746f0e89a305c 100644 --- a/arch/arm64/boot/dts/ti/k3-am65-iot2050-common-pg1.dtsi +++ b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common-pg1.dtsi @@ -13,10 +13,6 @@ &dss { assigned-clock-parents = <&k3_clks 67 5>; }; -&serdes0 { - status = "disabled"; -}; - &sdhci1 { no-1-8-v; }; diff --git a/arch/arm64/boot/dts/ti/k3-am65-iot2050-common-pg2.dtsi b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common-pg2.dtsi index e73458ca69007..b769fe6fc072f 100644 --- a/arch/arm64/boot/dts/ti/k3-am65-iot2050-common-pg2.dtsi +++ b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common-pg2.dtsi @@ -35,6 +35,7 @@ &dss { &serdes0 { assigned-clocks = <&k3_clks 153 4>, <&serdes0 AM654_SERDES_CMU_REFCLK>; assigned-clock-parents = <&k3_clks 153 7>, <&k3_clks 153 4>; + status = "okay"; }; &dwc3_0 { @@ -42,10 +43,16 @@ &dwc3_0 { <&k3_clks 151 8>; /* set PIPE3_TXB_CLK to WIZ8B2M4VSB */ phys = <&serdes0 PHY_TYPE_USB3 0>; phy-names = "usb3-phy"; + status = "okay"; }; &usb0 { maximum-speed = "super-speed"; snps,dis-u1-entry-quirk; snps,dis-u2-entry-quirk; + status = "okay"; +}; + +&usb0_phy { + status = "okay"; }; diff --git a/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi index 3079eaee01c06..873c123c611ed 100644 --- a/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi +++ b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi @@ -362,15 +362,13 @@ &wkup_uart0 { &main_uart1 { pinctrl-names = "default"; pinctrl-0 = <&main_uart1_pins_default>; -}; - -&main_uart2 { - status = "disabled"; + status = "okay"; }; &mcu_uart0 { pinctrl-names = "default"; pinctrl-0 = <&arduino_uart_pins_default>; + status = "okay"; }; &main_gpio0 { @@ -416,12 +414,14 @@ &wkup_i2c0 { pinctrl-names = "default"; pinctrl-0 = <&wkup_i2c0_pins_default>; clock-frequency = <400000>; + status = "okay"; }; &mcu_i2c0 { pinctrl-names = "default"; pinctrl-0 = <&mcu_i2c0_pins_default>; clock-frequency = <400000>; + status = "okay"; psu: regulator@60 { compatible = "ti,tps62363"; @@ -481,6 +481,7 @@ &main_i2c0 { pinctrl-names = "default"; pinctrl-0 = <&main_i2c0_pins_default>; clock-frequency = <400000>; + status = "okay"; rtc: rtc8564@51 { compatible = "nxp,pcf8563"; @@ -498,12 +499,14 @@ &main_i2c1 { pinctrl-names = "default"; pinctrl-0 = <&main_i2c1_pins_default>; clock-frequency = <400000>; + status = "okay"; }; &main_i2c2 { pinctrl-names = "default"; pinctrl-0 = <&main_i2c2_pins_default>; clock-frequency = <400000>; + status = "okay"; }; &main_i2c3 { @@ -514,6 +517,8 @@ &main_i2c3 { #address-cells = <1>; #size-cells = <0>; + status = "okay"; + edp-bridge@f { compatible = "toshiba,tc358767"; reg = <0x0f>; @@ -541,13 +546,10 @@ bridge_in: endpoint { }; }; -&mcu_cpsw { - status = "disabled"; -}; - &ecap0 { pinctrl-names = "default"; pinctrl-0 = <&ecap0_pins_default>; + status = "okay"; }; &sdhci1 { @@ -555,20 +557,38 @@ &sdhci1 { pinctrl-0 = <&main_mmc1_pins_default>; ti,driver-strength-ohm = <50>; disable-wp; + status = "okay"; +}; + +&dwc3_0 { + status = "okay"; }; + &usb0 { pinctrl-names = "default"; pinctrl-0 = <&usb0_pins_default>; dr_mode = "host"; }; +&usb0_phy { + status = "okay"; +}; + +&dwc3_1 { + status = "okay"; +}; + &usb1 { pinctrl-names = "default"; pinctrl-0 = <&usb1_pins_default>; dr_mode = "host"; }; +&usb1_phy { + status = "okay"; +}; + &mcu_spi0 { pinctrl-names = "default"; pinctrl-0 = <&mcu_spi0_pins_default>; @@ -576,13 +596,12 @@ &mcu_spi0 { #address-cells = <1>; #size-cells= <0>; ti,pindir-d0-out-d1-in; -}; - -&tscadc0 { - status = "disabled"; + status = "okay"; }; &tscadc1 { + status = "okay"; + adc { ti,adc-channels = <0 1 2 3 4 5>; }; @@ -591,6 +610,7 @@ adc { &ospi0 { pinctrl-names = "default"; pinctrl-0 = <&mcu_fss0_ospi0_pins_default>; + status = "okay"; flash@0 { compatible = "jedec,spi-nor"; @@ -611,6 +631,7 @@ flash@0 { &dss { pinctrl-names = "default"; pinctrl-0 = <&dss_vout1_pins_default>; + status = "okay"; assigned-clocks = <&k3_clks 67 2>; assigned-clock-parents = <&k3_clks 67 5>; @@ -628,17 +649,14 @@ dpi_out: endpoint { }; }; -&pcie0_rc { - status = "disabled"; -}; - -&pcie0_ep { - status = "disabled"; +&serdes1 { + status = "okay"; }; &pcie1_rc { pinctrl-names = "default"; pinctrl-0 = <&minipcie_pins_default>; + status = "okay"; num-lanes = <1>; phys = <&serdes1 PHY_TYPE_PCIE 0>; @@ -646,20 +664,9 @@ &pcie1_rc { reset-gpios = <&wkup_gpio0 27 GPIO_ACTIVE_HIGH>; }; -&m_can0 { - status = "disabled"; -}; - -&m_can1 { - status = "disabled"; -}; - -&pcie1_ep { - status = "disabled"; -}; - &mailbox0_cluster0 { interrupts = <436>; + status = "okay"; mbox_mcu_r5fss0_core0: mbox-mcu-r5fss0-core0 { ti,mbox-tx = <1 0 0>; @@ -669,6 +676,7 @@ mbox_mcu_r5fss0_core0: mbox-mcu-r5fss0-core0 { &mailbox0_cluster1 { interrupts = <432>; + status = "okay"; mbox_mcu_r5fss0_core1: mbox-mcu-r5fss0-core1 { ti,mbox-tx = <1 0 0>; @@ -676,46 +684,6 @@ mbox_mcu_r5fss0_core1: mbox-mcu-r5fss0-core1 { }; }; -&mailbox0_cluster2 { - status = "disabled"; -}; - -&mailbox0_cluster3 { - status = "disabled"; -}; - -&mailbox0_cluster4 { - status = "disabled"; -}; - -&mailbox0_cluster5 { - status = "disabled"; -}; - -&mailbox0_cluster6 { - status = "disabled"; -}; - -&mailbox0_cluster7 { - status = "disabled"; -}; - -&mailbox0_cluster8 { - status = "disabled"; -}; - -&mailbox0_cluster9 { - status = "disabled"; -}; - -&mailbox0_cluster10 { - status = "disabled"; -}; - -&mailbox0_cluster11 { - status = "disabled"; -}; - &mcu_r5fss0_core0 { memory-region = <&mcu_r5fss0_core0_dma_memory_region>, <&mcu_r5fss0_core0_memory_region>; @@ -727,27 +695,3 @@ &mcu_r5fss0_core1 { <&mcu_r5fss0_core1_memory_region>; mboxes = <&mailbox0_cluster1 &mbox_mcu_r5fss0_core1>; }; - -&icssg0_mdio { - status = "disabled"; -}; - -&icssg1_mdio { - status = "disabled"; -}; - -&icssg2_mdio { - status = "disabled"; -}; - -&mcasp0 { - status = "disabled"; -}; - -&mcasp1 { - status = "disabled"; -}; - -&mcasp2 { - status = "disabled"; -}; diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi index ce8bb4a61011e..5aa425d1ba802 100644 --- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi +++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi @@ -64,6 +64,7 @@ serdes0: serdes@900000 { ti,serdes-clk = <&serdes0_clk>; #clock-cells = <1>; mux-controls = <&serdes_mux 0>; + status = "disabled"; }; serdes1: serdes@910000 { @@ -79,6 +80,7 @@ serdes1: serdes@910000 { ti,serdes-clk = <&serdes1_clk>; #clock-cells = <1>; mux-controls = <&serdes_mux 1>; + status = "disabled"; }; main_uart0: serial@2800000 { @@ -88,6 +90,7 @@ main_uart0: serial@2800000 { clock-frequency = <48000000>; current-speed = <115200>; power-domains = <&k3_pds 146 TI_SCI_PD_EXCLUSIVE>; + status = "disabled"; }; main_uart1: serial@2810000 { @@ -96,6 +99,7 @@ main_uart1: serial@2810000 { interrupts = <GIC_SPI 193 IRQ_TYPE_LEVEL_HIGH>; clock-frequency = <48000000>; power-domains = <&k3_pds 147 TI_SCI_PD_EXCLUSIVE>; + status = "disabled"; }; main_uart2: serial@2820000 { @@ -104,6 +108,7 @@ main_uart2: serial@2820000 { interrupts = <GIC_SPI 194 IRQ_TYPE_LEVEL_HIGH>; clock-frequency = <48000000>; power-domains = <&k3_pds 148 TI_SCI_PD_EXCLUSIVE>; + status = "disabled"; }; crypto: crypto@4e00000 { @@ -152,6 +157,7 @@ main_i2c0: i2c@2000000 { clock-names = "fck"; clocks = <&k3_clks 110 1>; power-domains = <&k3_pds 110 TI_SCI_PD_EXCLUSIVE>; + status = "disabled"; }; main_i2c1: i2c@2010000 { @@ -163,6 +169,7 @@ main_i2c1: i2c@2010000 { clock-names = "fck"; clocks = <&k3_clks 111 1>; power-domains = <&k3_pds 111 TI_SCI_PD_EXCLUSIVE>; + status = "disabled"; }; main_i2c2: i2c@2020000 { @@ -174,6 +181,7 @@ main_i2c2: i2c@2020000 { clock-names = "fck"; clocks = <&k3_clks 112 1>; power-domains = <&k3_pds 112 TI_SCI_PD_EXCLUSIVE>; + status = "disabled"; }; main_i2c3: i2c@2030000 { @@ -185,6 +193,7 @@ main_i2c3: i2c@2030000 { clock-names = "fck"; clocks = <&k3_clks 113 1>; power-domains = <&k3_pds 113 TI_SCI_PD_EXCLUSIVE>; + status = "disabled"; }; ecap0: pwm@3100000 { @@ -194,6 +203,7 @@ ecap0: pwm@3100000 { power-domains = <&k3_pds 39 TI_SCI_PD_EXCLUSIVE>; clocks = <&k3_clks 39 0>; clock-names = "fck"; + status = "disabled"; }; main_spi0: spi@2100000 { @@ -206,6 +216,7 @@ main_spi0: spi@2100000 { #size-cells = <0>; dmas = <&main_udmap 0xc500>, <&main_udmap 0x4500>; dma-names = "tx0", "rx0"; + status = "disabled"; }; main_spi1: spi@2110000 { @@ -218,6 +229,7 @@ main_spi1: spi@2110000 { #size-cells = <0>; assigned-clocks = <&k3_clks 137 1>; assigned-clock-rates = <48000000>; + status = "disabled"; }; main_spi2: spi@2120000 { @@ -228,6 +240,7 @@ main_spi2: spi@2120000 { power-domains = <&k3_pds 139 TI_SCI_PD_EXCLUSIVE>; #address-cells = <1>; #size-cells = <0>; + status = "disabled"; }; main_spi3: spi@2130000 { @@ -238,6 +251,7 @@ main_spi3: spi@2130000 { power-domains = <&k3_pds 140 TI_SCI_PD_EXCLUSIVE>; #address-cells = <1>; #size-cells = <0>; + status = "disabled"; }; main_spi4: spi@2140000 { @@ -248,6 +262,7 @@ main_spi4: spi@2140000 { power-domains = <&k3_pds 141 TI_SCI_PD_EXCLUSIVE>; #address-cells = <1>; #size-cells = <0>; + status = "disabled"; }; sdhci0: mmc@4f80000 { @@ -272,6 +287,7 @@ sdhci0: mmc@4f80000 { ti,otap-del-sel-hs400 = <0x0>; ti,trm-icp = <0x8>; dma-coherent; + status = "disabled"; }; sdhci1: mmc@4fa0000 { @@ -295,6 +311,7 @@ sdhci1: mmc@4fa0000 { ti,otap-del-sel = <0x2>; ti,trm-icp = <0x8>; dma-coherent; + status = "disabled"; }; scm_conf: scm-conf@100000 { @@ -361,6 +378,7 @@ dwc3_0: dwc3@4000000 { assigned-clocks = <&k3_clks 151 2>, <&k3_clks 151 7>; assigned-clock-parents = <&k3_clks 151 4>, /* set REF_CLK to 20MHz i.e. PER0_PLL/48 */ <&k3_clks 151 9>; /* set PIPE3_TXB_CLK to CLK_12M_RC/256 (for HS only) */ + status = "disabled"; usb0: usb@10000 { compatible = "snps,dwc3"; @@ -386,6 +404,7 @@ usb0_phy: phy@4100000 { clocks = <&k3_clks 151 0>, <&k3_clks 151 1>; clock-names = "wkupclk", "refclk"; #phy-cells = <0>; + status = "disabled"; }; dwc3_1: dwc3@4020000 { @@ -400,6 +419,7 @@ dwc3_1: dwc3@4020000 { clocks = <&k3_clks 152 2>; assigned-clocks = <&k3_clks 152 2>; assigned-clock-parents = <&k3_clks 152 4>; /* set REF_CLK to 20MHz i.e. PER0_PLL/48 */ + status = "disabled"; usb1: usb@10000 { compatible = "snps,dwc3"; @@ -424,6 +444,7 @@ usb1_phy: phy@4110000 { clocks = <&k3_clks 152 0>, <&k3_clks 152 1>; clock-names = "wkupclk", "refclk"; #phy-cells = <0>; + status = "disabled"; }; intr_main_gpio: interrupt-controller@a00000 { @@ -497,6 +518,7 @@ mailbox0_cluster0: mailbox@31f80000 { ti,mbox-num-users = <4>; ti,mbox-num-fifos = <16>; interrupt-parent = <&intr_main_navss>; + status = "disabled"; }; mailbox0_cluster1: mailbox@31f81000 { @@ -506,6 +528,7 @@ mailbox0_cluster1: mailbox@31f81000 { ti,mbox-num-users = <4>; ti,mbox-num-fifos = <16>; interrupt-parent = <&intr_main_navss>; + status = "disabled"; }; mailbox0_cluster2: mailbox@31f82000 { @@ -515,6 +538,7 @@ mailbox0_cluster2: mailbox@31f82000 { ti,mbox-num-users = <4>; ti,mbox-num-fifos = <16>; interrupt-parent = <&intr_main_navss>; + status = "disabled"; }; mailbox0_cluster3: mailbox@31f83000 { @@ -524,6 +548,7 @@ mailbox0_cluster3: mailbox@31f83000 { ti,mbox-num-users = <4>; ti,mbox-num-fifos = <16>; interrupt-parent = <&intr_main_navss>; + status = "disabled"; }; mailbox0_cluster4: mailbox@31f84000 { @@ -533,6 +558,7 @@ mailbox0_cluster4: mailbox@31f84000 { ti,mbox-num-users = <4>; ti,mbox-num-fifos = <16>; interrupt-parent = <&intr_main_navss>; + status = "disabled"; }; mailbox0_cluster5: mailbox@31f85000 { @@ -542,6 +568,7 @@ mailbox0_cluster5: mailbox@31f85000 { ti,mbox-num-users = <4>; ti,mbox-num-fifos = <16>; interrupt-parent = <&intr_main_navss>; + status = "disabled"; }; mailbox0_cluster6: mailbox@31f86000 { @@ -551,6 +578,7 @@ mailbox0_cluster6: mailbox@31f86000 { ti,mbox-num-users = <4>; ti,mbox-num-fifos = <16>; interrupt-parent = <&intr_main_navss>; + status = "disabled"; }; mailbox0_cluster7: mailbox@31f87000 { @@ -560,6 +588,7 @@ mailbox0_cluster7: mailbox@31f87000 { ti,mbox-num-users = <4>; ti,mbox-num-fifos = <16>; interrupt-parent = <&intr_main_navss>; + status = "disabled"; }; mailbox0_cluster8: mailbox@31f88000 { @@ -569,6 +598,7 @@ mailbox0_cluster8: mailbox@31f88000 { ti,mbox-num-users = <4>; ti,mbox-num-fifos = <16>; interrupt-parent = <&intr_main_navss>; + status = "disabled"; }; mailbox0_cluster9: mailbox@31f89000 { @@ -578,6 +608,7 @@ mailbox0_cluster9: mailbox@31f89000 { ti,mbox-num-users = <4>; ti,mbox-num-fifos = <16>; interrupt-parent = <&intr_main_navss>; + status = "disabled"; }; mailbox0_cluster10: mailbox@31f8a000 { @@ -587,6 +618,7 @@ mailbox0_cluster10: mailbox@31f8a000 { ti,mbox-num-users = <4>; ti,mbox-num-fifos = <16>; interrupt-parent = <&intr_main_navss>; + status = "disabled"; }; mailbox0_cluster11: mailbox@31f8b000 { @@ -596,6 +628,7 @@ mailbox0_cluster11: mailbox@31f8b000 { ti,mbox-num-users = <4>; ti,mbox-num-fifos = <16>; interrupt-parent = <&intr_main_navss>; + status = "disabled"; }; ringacc: ringacc@3c000000 { @@ -703,6 +736,7 @@ pcie0_rc: pcie@5500000 { interrupts = <GIC_SPI 340 IRQ_TYPE_EDGE_RISING>; msi-map = <0x0 &gic_its 0x0 0x10000>; device_type = "pci"; + status = "disabled"; }; pcie0_ep: pcie-ep@5500000 { @@ -716,6 +750,7 @@ pcie0_ep: pcie-ep@5500000 { max-link-speed = <2>; dma-coherent; interrupts = <GIC_SPI 340 IRQ_TYPE_EDGE_RISING>; + status = "disabled"; }; pcie1_rc: pcie@5600000 { @@ -736,6 +771,7 @@ pcie1_rc: pcie@5600000 { interrupts = <GIC_SPI 355 IRQ_TYPE_EDGE_RISING>; msi-map = <0x0 &gic_its 0x10000 0x10000>; device_type = "pci"; + status = "disabled"; }; pcie1_ep: pcie-ep@5600000 { @@ -749,6 +785,7 @@ pcie1_ep: pcie-ep@5600000 { max-link-speed = <2>; dma-coherent; interrupts = <GIC_SPI 355 IRQ_TYPE_EDGE_RISING>; + status = "disabled"; }; mcasp0: mcasp@2b00000 { @@ -766,6 +803,7 @@ mcasp0: mcasp@2b00000 { clocks = <&k3_clks 104 0>; clock-names = "fck"; power-domains = <&k3_pds 104 TI_SCI_PD_EXCLUSIVE>; + status = "disabled"; }; mcasp1: mcasp@2b10000 { @@ -783,6 +821,7 @@ mcasp1: mcasp@2b10000 { clocks = <&k3_clks 105 0>; clock-names = "fck"; power-domains = <&k3_pds 105 TI_SCI_PD_EXCLUSIVE>; + status = "disabled"; }; mcasp2: mcasp@2b20000 { @@ -800,6 +839,7 @@ mcasp2: mcasp@2b20000 { clocks = <&k3_clks 106 0>; clock-names = "fck"; power-domains = <&k3_pds 106 TI_SCI_PD_EXCLUSIVE>; + status = "disabled"; }; cal: cal@6f03000 { @@ -813,6 +853,7 @@ cal: cal@6f03000 { clock-names = "fck"; clocks = <&k3_clks 2 0>; power-domains = <&k3_pds 2 TI_SCI_PD_EXCLUSIVE>; + status = "disabled"; ports { #address-cells = <1>; @@ -857,6 +898,8 @@ dss: dss@4a00000 { dma-coherent; + status = "disabled"; + dss_ports: ports { #address-cells = <1>; #size-cells = <0>; @@ -870,6 +913,7 @@ ehrpwm0: pwm@3000000 { power-domains = <&k3_pds 40 TI_SCI_PD_EXCLUSIVE>; clocks = <&ehrpwm_tbclk 0>, <&k3_clks 40 0>; clock-names = "tbclk", "fck"; + status = "disabled"; }; ehrpwm1: pwm@3010000 { @@ -879,6 +923,7 @@ ehrpwm1: pwm@3010000 { power-domains = <&k3_pds 41 TI_SCI_PD_EXCLUSIVE>; clocks = <&ehrpwm_tbclk 1>, <&k3_clks 41 0>; clock-names = "tbclk", "fck"; + status = "disabled"; }; ehrpwm2: pwm@3020000 { @@ -888,6 +933,7 @@ ehrpwm2: pwm@3020000 { power-domains = <&k3_pds 42 TI_SCI_PD_EXCLUSIVE>; clocks = <&ehrpwm_tbclk 2>, <&k3_clks 42 0>; clock-names = "tbclk", "fck"; + status = "disabled"; }; ehrpwm3: pwm@3030000 { @@ -897,6 +943,7 @@ ehrpwm3: pwm@3030000 { power-domains = <&k3_pds 43 TI_SCI_PD_EXCLUSIVE>; clocks = <&ehrpwm_tbclk 3>, <&k3_clks 43 0>; clock-names = "tbclk", "fck"; + status = "disabled"; }; ehrpwm4: pwm@3040000 { @@ -906,6 +953,7 @@ ehrpwm4: pwm@3040000 { power-domains = <&k3_pds 44 TI_SCI_PD_EXCLUSIVE>; clocks = <&ehrpwm_tbclk 4>, <&k3_clks 44 0>; clock-names = "tbclk", "fck"; + status = "disabled"; }; ehrpwm5: pwm@3050000 { @@ -915,6 +963,7 @@ ehrpwm5: pwm@3050000 { power-domains = <&k3_pds 45 TI_SCI_PD_EXCLUSIVE>; clocks = <&ehrpwm_tbclk 5>, <&k3_clks 45 0>; clock-names = "tbclk", "fck"; + status = "disabled"; }; icssg0: icssg@b000000 { @@ -1055,6 +1104,7 @@ icssg0_mdio: mdio@32400 { #address-cells = <1>; #size-cells = <0>; bus_freq = <1000000>; + status = "disabled"; }; }; @@ -1196,6 +1246,7 @@ icssg1_mdio: mdio@32400 { #address-cells = <1>; #size-cells = <0>; bus_freq = <1000000>; + status = "disabled"; }; }; @@ -1337,6 +1388,7 @@ icssg2_mdio: mdio@32400 { #address-cells = <1>; #size-cells = <0>; bus_freq = <1000000>; + status = "disabled"; }; }; }; diff --git a/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi b/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi index 8d592bf41d6f1..57ac3a493adbe 100644 --- a/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi +++ b/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi @@ -22,11 +22,12 @@ phy_gmii_sel: phy@4040 { mcu_uart0: serial@40a00000 { compatible = "ti,am654-uart"; - reg = <0x00 0x40a00000 0x00 0x100>; - interrupts = <GIC_SPI 565 IRQ_TYPE_LEVEL_HIGH>; - clock-frequency = <96000000>; - current-speed = <115200>; - power-domains = <&k3_pds 149 TI_SCI_PD_EXCLUSIVE>; + reg = <0x00 0x40a00000 0x00 0x100>; + interrupts = <GIC_SPI 565 IRQ_TYPE_LEVEL_HIGH>; + clock-frequency = <96000000>; + current-speed = <115200>; + power-domains = <&k3_pds 149 TI_SCI_PD_EXCLUSIVE>; + status = "disabled"; }; mcu_ram: sram@41c00000 { @@ -46,6 +47,7 @@ mcu_i2c0: i2c@40b00000 { clock-names = "fck"; clocks = <&k3_clks 114 1>; power-domains = <&k3_pds 114 TI_SCI_PD_EXCLUSIVE>; + status = "disabled"; }; mcu_spi0: spi@40300000 { @@ -56,6 +58,7 @@ mcu_spi0: spi@40300000 { power-domains = <&k3_pds 142 TI_SCI_PD_EXCLUSIVE>; #address-cells = <1>; #size-cells = <0>; + status = "disabled"; }; mcu_spi1: spi@40310000 { @@ -66,6 +69,7 @@ mcu_spi1: spi@40310000 { power-domains = <&k3_pds 143 TI_SCI_PD_EXCLUSIVE>; #address-cells = <1>; #size-cells = <0>; + status = "disabled"; }; mcu_spi2: spi@40320000 { @@ -76,6 +80,7 @@ mcu_spi2: spi@40320000 { power-domains = <&k3_pds 144 TI_SCI_PD_EXCLUSIVE>; #address-cells = <1>; #size-cells = <0>; + status = "disabled"; }; tscadc0: tscadc@40200000 { @@ -89,6 +94,7 @@ tscadc0: tscadc@40200000 { dmas = <&mcu_udmap 0x7100>, <&mcu_udmap 0x7101 >; dma-names = "fifo0", "fifo1"; + status = "disabled"; adc { #io-channel-cells = <1>; @@ -107,6 +113,7 @@ tscadc1: tscadc@40210000 { dmas = <&mcu_udmap 0x7102>, <&mcu_udmap 0x7103>; dma-names = "fifo0", "fifo1"; + status = "disabled"; adc { #io-channel-cells = <1>; @@ -172,6 +179,7 @@ m_can0: mcan@40528000 { <GIC_SPI 545 IRQ_TYPE_LEVEL_HIGH>; interrupt-names = "int0", "int1"; bosch,mram-cfg = <0x0 128 64 64 64 64 32 32>; + status = "disabled"; }; m_can1: mcan@40568000 { @@ -187,6 +195,7 @@ m_can1: mcan@40568000 { <GIC_SPI 548 IRQ_TYPE_LEVEL_HIGH>; interrupt-names = "int0", "int1"; bosch,mram-cfg = <0x0 128 64 64 64 64 32 32>; + status = "disabled"; }; fss: fss@47000000 { @@ -252,6 +261,8 @@ mcu_cpsw: ethernet@46000000 { "tx4", "tx5", "tx6", "tx7", "rx"; + status = "disabled"; + ethernet-ports { #address-cells = <1>; #size-cells = <0>; diff --git a/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi index 9c69d0917f69a..8f0c505a16edd 100644 --- a/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi +++ b/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi @@ -54,6 +54,7 @@ wkup_uart0: serial@42300000 { clock-frequency = <48000000>; current-speed = <115200>; power-domains = <&k3_pds 150 TI_SCI_PD_EXCLUSIVE>; + status = "disabled"; }; wkup_i2c0: i2c@42120000 { @@ -65,6 +66,7 @@ wkup_i2c0: i2c@42120000 { clock-names = "fck"; clocks = <&k3_clks 115 1>; power-domains = <&k3_pds 115 TI_SCI_PD_EXCLUSIVE>; + status = "disabled"; }; intr_wkup_gpio: interrupt-controller@42200000 { diff --git a/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic-common.dtsi b/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic-common.dtsi index 4a9bf7d7c07dc..29f539cc23921 100644 --- a/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic-common.dtsi +++ b/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic-common.dtsi @@ -29,11 +29,6 @@ cpu-map { /delete-node/ l2-cache1; }; -/* eMMC */ -&sdhci0 { - status = "disabled"; -}; - &main_pmx0 { main_uart0_pins_default: main-uart0-pins-default { pinctrl-single,pins = < @@ -52,6 +47,7 @@ AM65X_IOPAD(0x0194, PIN_INPUT, 1) /* (E24) UART0_RIN */ &main_uart0 { pinctrl-names = "default"; pinctrl-0 = <&main_uart0_pins_default>; + status = "okay"; }; &mcu_r5fss0 { diff --git a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts index 9043f91c9bec7..821ee7f2eff04 100644 --- a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts +++ b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts @@ -275,12 +275,14 @@ &main_uart0 { pinctrl-names = "default"; pinctrl-0 = <&main_uart0_pins_default>; power-domains = <&k3_pds 146 TI_SCI_PD_SHARED>; + status = "okay"; }; &wkup_i2c0 { pinctrl-names = "default"; pinctrl-0 = <&wkup_i2c0_pins_default>; clock-frequency = <400000>; + status = "okay"; pca9554: gpio@39 { compatible = "nxp,pca9554"; @@ -300,6 +302,7 @@ &main_i2c0 { pinctrl-names = "default"; pinctrl-0 = <&main_i2c0_pins_default>; clock-frequency = <400000>; + status = "okay"; pca9555: gpio@21 { compatible = "nxp,pca9555"; @@ -313,17 +316,20 @@ &main_i2c1 { pinctrl-names = "default"; pinctrl-0 = <&main_i2c1_pins_default>; clock-frequency = <400000>; + status = "okay"; }; &main_i2c2 { pinctrl-names = "default"; pinctrl-0 = <&main_i2c2_pins_default>; clock-frequency = <400000>; + status = "okay"; }; &ecap0 { pinctrl-names = "default"; pinctrl-0 = <&ecap0_pins_default>; + status = "okay"; }; &main_spi0 { @@ -332,6 +338,7 @@ &main_spi0 { #address-cells = <1>; #size-cells= <0>; ti,pindir-d0-out-d1-in; + status = "okay"; flash@0{ compatible = "jedec,spi-nor"; @@ -351,6 +358,7 @@ &sdhci0 { non-removable; ti,driver-strength-ohm = <50>; disable-wp; + status = "okay"; }; /* @@ -364,6 +372,11 @@ &sdhci1 { pinctrl-0 = <&main_mmc1_pins_default>; ti,driver-strength-ohm = <50>; disable-wp; + status = "okay"; +}; + +&dwc3_1 { + status = "okay"; }; &usb1 { @@ -372,60 +385,29 @@ &usb1 { dr_mode = "otg"; }; -&dwc3_0 { - status = "disabled"; -}; - -&usb0_phy { - status = "disabled"; +&usb1_phy { + status = "okay"; }; &tscadc0 { + status = "okay"; + adc { ti,adc-channels = <0 1 2 3 4 5 6 7>; }; }; &tscadc1 { + status = "okay"; + adc { ti,adc-channels = <0 1 2 3 4 5 6 7>; }; }; -&serdes0 { - status = "disabled"; -}; - -&serdes1 { - status = "disabled"; -}; - -&pcie0_rc { - status = "disabled"; -}; - -&pcie0_ep { - status = "disabled"; -}; - -&pcie1_rc { - status = "disabled"; -}; - -&pcie1_ep { - status = "disabled"; -}; - -&m_can0 { - status = "disabled"; -}; - -&m_can1 { - status = "disabled"; -}; - &mailbox0_cluster0 { interrupts = <436>; + status = "okay"; mbox_mcu_r5fss0_core0: mbox-mcu-r5fss0-core0 { ti,mbox-tx = <1 0 0>; @@ -435,6 +417,7 @@ mbox_mcu_r5fss0_core0: mbox-mcu-r5fss0-core0 { &mailbox0_cluster1 { interrupts = <432>; + status = "okay"; mbox_mcu_r5fss0_core1: mbox-mcu-r5fss0-core1 { ti,mbox-tx = <1 0 0>; @@ -442,46 +425,6 @@ mbox_mcu_r5fss0_core1: mbox-mcu-r5fss0-core1 { }; }; -&mailbox0_cluster2 { - status = "disabled"; -}; - -&mailbox0_cluster3 { - status = "disabled"; -}; - -&mailbox0_cluster4 { - status = "disabled"; -}; - -&mailbox0_cluster5 { - status = "disabled"; -}; - -&mailbox0_cluster6 { - status = "disabled"; -}; - -&mailbox0_cluster7 { - status = "disabled"; -}; - -&mailbox0_cluster8 { - status = "disabled"; -}; - -&mailbox0_cluster9 { - status = "disabled"; -}; - -&mailbox0_cluster10 { - status = "disabled"; -}; - -&mailbox0_cluster11 { - status = "disabled"; -}; - &mcu_r5fss0_core0 { memory-region = <&mcu_r5fss0_core0_dma_memory_region>, <&mcu_r5fss0_core0_memory_region>; @@ -497,6 +440,7 @@ &mcu_r5fss0_core1 { &ospi0 { pinctrl-names = "default"; pinctrl-0 = <&mcu_fss0_ospi0_pins_default>; + status = "okay"; flash@0{ compatible = "jedec,spi-nor"; @@ -517,6 +461,7 @@ flash@0{ &mcu_cpsw { pinctrl-names = "default"; pinctrl-0 = <&mcu_cpsw_pins_default &mcu_mdio_pins_default>; + status = "okay"; }; &davinci_mdio { @@ -531,31 +476,3 @@ &cpsw_port1 { phy-mode = "rgmii-rxid"; phy-handle = <&phy0>; }; - -&mcasp0 { - status = "disabled"; -}; - -&mcasp1 { - status = "disabled"; -}; - -&mcasp2 { - status = "disabled"; -}; - -&dss { - status = "disabled"; -}; - -&icssg0_mdio { - status = "disabled"; -}; - -&icssg1_mdio { - status = "disabled"; -}; - -&icssg2_mdio { - status = "disabled"; -}; diff --git a/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-common.dtsi b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-common.dtsi index d25e8b26187f9..731224ec5c366 100644 --- a/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-common.dtsi +++ b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-common.dtsi @@ -49,8 +49,5 @@ &sdhci0 { non-removable; ti,driver-strength-ohm = <50>; disable-wp; -}; - -&main_uart0 { - status = "disabled"; + status = "okay"; };
All peripherals that require pinmuxing or other configuration to work should be disabled by default. Dependent DTS are adjusted accordingly. The following nodes are now "disabled" according to dtx_diff and were not overridden to "okay", as they define no pinctrl: k3-am654-base-board: - mcu_i2c0 - mcu_spi0..2 - mcu_uart0 - cal - main_i2c3 - ehrpwm0..5 - main_uart1..2 - main_spi1..4 k3-am65-iot2050*: - mci_spi1..2 - cal - ehrpwm0..5 - main_spi0..4 Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> --- v2: disable mcu_uart0 by default .../dts/ti/k3-am65-iot2050-common-pg1.dtsi | 4 - .../dts/ti/k3-am65-iot2050-common-pg2.dtsi | 7 + .../boot/dts/ti/k3-am65-iot2050-common.dtsi | 132 +++++------------- arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 52 +++++++ arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi | 21 ++- arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi | 2 + .../ti/k3-am6528-iot2050-basic-common.dtsi | 6 +- .../arm64/boot/dts/ti/k3-am654-base-board.dts | 129 +++-------------- .../ti/k3-am6548-iot2050-advanced-common.dtsi | 5 +- 9 files changed, 140 insertions(+), 218 deletions(-)