Re: [RFC] ARM: OMAP2+: hwmod: don't touch hwmod if disabled

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

 



[Adding Rob & Mark, since this affects DT binding]

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.

So there are arguments for both variants:

 a) add status = "ignore" and read status = "disabled" as
    "do not use device, but power down"
 b) add status = "powerdown" and read status = "disabled" as
    "completly ignore this device"

It is obvious, that we need an extra state.

> > 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

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux