lkml.org 
[lkml]   [2018]   [Jul]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH 0/2] soc: imx: gpc: Power off PU domain in suspend/resume on 6qp
Date
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?
\
 
 \ /
  Last update: 2018-07-02 15:50    [W:0.083 / U:0.176 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site