mbox series

[0/2] soc: imx: gpc: Power off PU domain in suspend/resume on 6qp

Message ID cover.1530530881.git.leonard.crestez@nxp.com
Headers show
Series soc: imx: gpc: Power off PU domain in suspend/resume on 6qp | expand

Message

Leonard Crestez July 2, 2018, 11:52 a.m. UTC 
Tested by doing `rtcwake -s 5 -m mem` while running glxgears on etnaviv.

The first patch is required because otherwise it is not easy to reach pgc
domains from the gpc itself when using new-style bindings. It's also
easier to understand.

The use of dynamic allocation in this driver is strange. Since there is
only one GPC physically present in each soc my impulse would be to make
most things global and delete imx_gpc_driver.remove entirely.

With current code (even without my patches) attempting to dynamically
remove/probe the GPC fils since since the per-pgc platform_device
instances are not removed. I'm trying something like this:

echo 130000.gpu > /sys/bus/platform/drivers/etnaviv-gpu/unbind
echo 134000.gpu > /sys/bus/platform/drivers/etnaviv-gpu/unbind
echo 20dc000.gpc  > /sys/bus/platform/drivers/imx-gpc/unbind
echo 20dc000.gpc  > /sys/bus/platform/drivers/imx-gpc/bind

But is there any usecase for dynamically removing the GPC? Instead of
trying to fix it I'd rather delete imx_gpc_driver.remove, just like
for gpcv2. Would anyone object to a patch doing this?

This series is not very pretty, constructive suggestions is welcome.
NXP internal tree has quite a lot of changes in gpc code and this causes
a lot of trouble when doing upgrades so I am trying to push some of the
internal features upstream.

Maybe instead of direct calls from mach-imx the gpc could implement
SLEEP_PM_OPS instead? It would still need a way to access the pgc
devices directly.

Leonard Crestez (2):
  soc: imx: gpc: Use static platform_device instances
  soc: imx: gpc: Power off PU domain in suspend/resume on 6qp

 arch/arm/mach-imx/gpc.c | 10 +++++
 drivers/soc/imx/gpc.c   | 93 ++++++++++++++++++++++++++---------------
 2 files changed, 70 insertions(+), 33 deletions(-)

Comments

Lucas Stach July 2, 2018, 12:15 p.m. UTC | #1 
Am Montag, den 02.07.2018, 14:52 +0300 schrieb Leonard Crestez:
> Tested by doing `rtcwake -s 5 -m mem` while running glxgears on
> etnaviv.
> 
> The first patch is required because otherwise it is not easy to reach
> pgc
> domains from the gpc itself when using new-style bindings. It's also
> easier to understand.
> 
> The use of dynamic allocation in this driver is strange. Since there
> is
> only one GPC physically present in each soc my impulse would be to
> make
> most things global and delete imx_gpc_driver.remove entirely.
> 
> With current code (even without my patches) attempting to dynamically
> remove/probe the GPC fils since since the per-pgc platform_device
> instances are not removed. I'm trying something like this:
> 
> echo 130000.gpu > /sys/bus/platform/drivers/etnaviv-gpu/unbind
> echo 134000.gpu > /sys/bus/platform/drivers/etnaviv-gpu/unbind
> echo 20dc000.gpc  > /sys/bus/platform/drivers/imx-gpc/unbind
> echo 20dc000.gpc  > /sys/bus/platform/drivers/imx-gpc/bind
> 
> But is there any usecase for dynamically removing the GPC? Instead of
> trying to fix it I'd rather delete imx_gpc_driver.remove, just like
> for gpcv2. Would anyone object to a patch doing this?

Yes, as this is taking things in wrong direction. With device-links we
are able to unbind consumer devices when a provider is removed. As the
GPC is a consumer of a regulator, not having the ability to unbind it
would break that use case.

We might still have bugs in some of those functions, but then those
should really be fixed instead of removed.

Regards,
Lucas
Leonard Crestez July 2, 2018, 1:49 p.m. UTC | #2 
On Mon, 2018-07-02 at 14:15 +0200, Lucas Stach wrote:
> Am Montag, den 02.07.2018, 14:52 +0300 schrieb Leonard Crestez:

> > With current code (even without my patches) attempting to dynamically
> > remove/probe the GPC fils since since the per-pgc platform_device
> > instances are not removed. I'm trying something like this:
> > 
> > echo 130000.gpu > /sys/bus/platform/drivers/etnaviv-gpu/unbind
> > echo 134000.gpu > /sys/bus/platform/drivers/etnaviv-gpu/unbind
> > echo 20dc000.gpc  > /sys/bus/platform/drivers/imx-gpc/unbind
> > echo 20dc000.gpc  > /sys/bus/platform/drivers/imx-gpc/bind
> > 
> > But is there any usecase for dynamically removing the GPC? Instead of
> > trying to fix it I'd rather delete imx_gpc_driver.remove, just like
> > for gpcv2. Would anyone object to a patch doing this?
> 
> Yes, as this is taking things in wrong direction. With device-links we
> are able to unbind consumer devices when a provider is removed. As the
> GPC is a consumer of a regulator, not having the ability to unbind it
> would break that use case.

The GPC is a "consumer" of the LDO regulators which are built into the
SOC. Why would you want to unbind any of this stuff?

I don't understand the usecase, maybe you can elaborate?
Lucas Stach July 2, 2018, 1:58 p.m. UTC | #3 
Am Montag, den 02.07.2018, 13:49 +0000 schrieb Leonard Crestez:
> On Mon, 2018-07-02 at 14:15 +0200, Lucas Stach wrote:
> > Am Montag, den 02.07.2018, 14:52 +0300 schrieb Leonard Crestez:
> > > With current code (even without my patches) attempting to dynamically
> > > remove/probe the GPC fils since since the per-pgc platform_device
> > > instances are not removed. I'm trying something like this:
> > > 
> > > echo 130000.gpu > /sys/bus/platform/drivers/etnaviv-gpu/unbind
> > > echo 134000.gpu > /sys/bus/platform/drivers/etnaviv-gpu/unbind
> > > echo 20dc000.gpc  > /sys/bus/platform/drivers/imx-gpc/unbind
> > > echo 20dc000.gpc  > /sys/bus/platform/drivers/imx-gpc/bind
> > > 
> > > But is there any usecase for dynamically removing the GPC? Instead of
> > > trying to fix it I'd rather delete imx_gpc_driver.remove, just like
> > > for gpcv2. Would anyone object to a patch doing this?
> > 
> > Yes, as this is taking things in wrong direction. With device-links we
> > are able to unbind consumer devices when a provider is removed. As the
> > GPC is a consumer of a regulator, not having the ability to unbind it
> > would break that use case.
> 
> The GPC is a "consumer" of the LDO regulators which are built into the
> SOC. Why would you want to unbind any of this stuff?

Which in turn might be consumers of external regulators, which may have
a module driver that can be reloaded by the user at will.

> I don't understand the usecase, maybe you can elaborate?

You could make that argument for almost every device on a SoC, yet the
explicit default in Linux is for device drivers to be hot-pluggable.

Anything that changes the system layout at Linux runtime, like
devicetree overlays or dynamic system partition solutions like
Jailhouse depend on driver/device hotplug to work. I know that there
are quite a few bugs in this area, because it's less tested than other
code paths, but I'm unwilling to accept that we are actively going in
the direction of breaking this stuff.

Regards,
Lucas