On Tue, Jul 25, 2017 at 10:38 AM, Sebastian Reichel <sebastian.reichel@xxxxxxxxxxxxxxx> wrote: > [Adding Rob & Mark, since this affects DT binding] We discussed and I thought agreed on this already a while back... > Hi, > > On Tue, Jul 25, 2017 at 08:03:41AM -0700, Tony Lindgren wrote: >> * Dave Gerlach <d-gerlach@xxxxxx> [170725 07:18]: >> > >> > This patch will introduce all sorts of chaos with PM low power modes in addition >> > to leaving many IPs in undefined power states. What happens on a system when RTC >> > is present and powered but is marked disabled in the DT? Nothing, which means it >> > is just left powered for no reason at all. >> >> What status = "disabled" means is that Linux does not know about the >> device at all. We are not following the standard right now, and that's why I >> introduced status = "incomplete" which means the device driver can probe and >> bail out after idling the device. > > Yes, but other platforms usually expect, that the hardware is off > or in low power mode when not being touched at all. I've seen > different platforms, that disable available IP cores in the SoC > using status = "disabled" and enable the ones being used in the > board file. As far as I understood it suspend/resume is still > supposed to work on those devices. The equivalent on OMAP would > be to power-down the module. If a platform wants to go find all or some of the disabled devices, and do something about them, that is fine. But from a core/common standpoint "disabled" should be treated the same as if the node was not there. > > So there are arguments for both variants: > > a) add status = "ignore" and read status = "disabled" as > "do not use device, but power down" No, too late. "disabled" already has a defined meaning. > b) add status = "powerdown" and read status = "disabled" as > "completly ignore this device" > > It is obvious, that we need an extra state. Or something with platform specific knowledge can do something. But my understanding was device specific knowledge was needed (i.e. a driver needs to handle the device). >> > With this patch in place the only way to ensure suspend will work is to have >> > every single device marked "okay" regardless of whether or not it's in use or >> > present on the system. The original intent of having omap_hwmod touch hwmods >> > regardless of their dt state is to put the system into a defined state at boot >> > time for PM. HWMODs do not have a fixed default state, every hwmod has a default >> > state which can be on or off at boot depending on the platform, and without this >> > in place, some modules can easily be left on by accident which will entirely >> > prevent suspend on platforms like am335x or am437x if the IP sits in the >> > peripheral power domain. >> >> Default is status = "okay" and there really should be no reason to mark SoC >> devices as "disabled" unless they really are not accessible as on HS devices. >> We do have PM working for many omap3 devices without having to use status = >> "disabled" at all except for some HS devices. Of course this needs to be >> verified though :) >> >> But really, "disabled" is not the problem for PM, the limitations we have >> for PM issues are missing runtime PM implementations in device drivers, >> such as for OHCI/EHCI. > > -- Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
