[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJiQ=7CorBMaO80xcEx4ygYFDJxxav_yyPs2jegKo3vrX1REHA@mail.gmail.com>
Date: Wed, 16 Jul 2014 11:55:16 -0700
From: Kevin Cernekee <cernekee@...il.com>
To: Alan Stern <stern@...land.harvard.edu>
Cc: Dmitry Torokhov <dtor@...gle.com>,
Patrik Fimml <patrikf@...omium.org>, linux-pm@...r.kernel.org,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Benson Leung <bleung@...gle.com>,
"linux-input@...r.kernel.org" <linux-input@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Power-managing devices that are not of interest at some point in time
On Wed, Jul 16, 2014 at 11:08 AM, Alan Stern <stern@...land.harvard.edu> wrote:
>> I am not so much concerned about userspace, but about reusing of as
>> much of existing PM framework in the drivers. Right now it is very
>> hard to correctly track dependencies between general open/close,
>> system suspend/resume, and various runtime-PM transitions. Adding yet
>> another PM mechanism into the mix will just add more complexity.
>
> Would it make sense to unbind the drivers for these devices when the
> lid is closed? With the drivers gone, there would naturally be no I/O
> interactions with the hardware and the class devices would disappear.
FWIW, per your earlier recommendation[1], that is the approach that my
group has been using to disable various host controllers when Linux is
running (not suspended) but certain power-hungry peripherals are not
needed. It has mostly worked out OK; each driver typically implements
its own special PHY init/shutdown procedure, and calls into the common
clk_* functions to enable/disable the appropriate clocks.
Obviously the application needs to be able to cope with disappearing
devices, and you wouldn't want to have any filesystems mounted on top
of them when the unbind event happens.
Our devices are on an SoC's internal bus, not PCI.
[1] http://lists.linuxfoundation.org/pipermail/linux-pm/2012-April/033976.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists