On 07/25/2017 10:03 AM, 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. I don't disagree that we are not following standard, but this is the way it's been done and it's what makes things work. > >> 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. What about when no driver is present and runtime PM does not apply at all? hwmod handles that case and shuts the IP off at boot regardless of what state it's in. Example I can see already, on am335x, uart5 is left active after u-boot runs. We don't use uart5 by default in the kernel on am335x-evm so it's marked disabled in the DT, with this patch applied suspends fails with "PM: Could not transition all powerdomains to target state" message because uart5 (and other IPs for that matter) block transition of the PER domain and you don't enter suspend. How would we handle this and other IPs with similar issues? Again, I'm not saying we are doing things right by touching nodes with disabled set, but that's how it works today, and taking this patch alone will break a lot of things, there's a lot of other things that will need to be addressed first. Regards, Dave > > Regards, > > Tony > > >> [1] https://www.spinics.net/lists/linux-omap/msg116382.html -- 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
