[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20180411043947.GK7671@vireshk-i7>
Date: Wed, 11 Apr 2018 10:09:47 +0530
From: Viresh Kumar <viresh.kumar@...aro.org>
To: Lucas Stach <l.stach@...gutronix.de>
Cc: Georgi Djakov <georgi.djakov@...aro.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Vincent Guittot <vincent.guittot@...aro.org>,
Stephen Boyd <sboyd@...nel.org>,
Rajendra Nayak <rnayak@...eaurora.org>,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
robdclark@...il.com, s.hauer@...gutronix.de, shawnguo@...nel.org,
fabio.estevam@....com, nm@...com, xuwei5@...ilicon.com,
robh+dt@...nel.org, olof@...om.net
Subject: Re: [PATCH V7 00/13] drivers: Boot Constraint core
On 10-04-18, 15:40, Lucas Stach wrote:
> Can you please describe how this bootconstraints core integration is
> simpler than a "run things at max performance until late kernel init",
> which could be triggered by a simple initcall similar to what is done
> for clocks and regulators?
>
> To me the bootcontraints stuff looks like a fairly complex solution and
> your use-case doesn't even sound like you strictly want to keep a
> bootloader configuration, but rather run things at max performance
> until you are reasonably sure that you got all the necessary bandwidth
> requests.
What about this case where drivers of some of the devices used during
boot are built as modules, like display, HDMI, etc., and would be
available only after userspace is up. We need to take care of their
bandwidth requirements as well, until the time their driver comes up.
--
viresh
Powered by blists - more mailing lists