Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1637351

[RFC] regulator: Shared regulators (configured by bootloader)

Path csiph.com!goblin1!goblin.stu.neva.ru!news.mixmin.net!news.unit0.net!news.panservice.it!bofh.it!news.nic.it!robomod
From Viresh Kumar <viresh.kumar@linaro.org>
Newsgroups linux.kernel
Subject [RFC] regulator: Shared regulators (configured by bootloader)
Date Mon, 08 May 2017 12:30:02 +0200
Message-ID <tEO5s-2HR-3@gated-at.bofh.it> (permalink)
Dkim-Signature v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :user-agent; bh=qCWISoWXsbhsDzs0i7sMqaodTvyZwlOVR8aP86DGz6Y=; b=Ou3JJw9bEE/RW8EE9XeLJCxRXIg4GqIkD/gmGBxIFEIudSEmdbic/Yc9GI2Hc3izbQ 1C1muSbpPZ7bp0YqyLcBNqWjpC7w0paxTnCI2ujfAKIEWYWIJzbiaHtXp+BwDbcGTRAW ldsDNRGl3zsrRemJXFAOjkgqjQPcIQtICqbaQ=
X-Google-Dkim-Signature v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:user-agent; bh=qCWISoWXsbhsDzs0i7sMqaodTvyZwlOVR8aP86DGz6Y=; b=LnKZlgkozv4/Y52zfNmZ7Jigj3+0vpwnhfDzLUBhrCwForGAW3Hq+sQm8T2gCLkYYK 8FwZMn7vl4V/AHcpi6PRMyVNzsKuWzIxtvsyt6ICDW2kOt3wMvlNXDQxwmJmrEFk8slp D3xGIny660sdbE0aMNDDiJ+Rl7/Ucnnx6Ty1f7eO+TBqt9rPXdgJHL0ozWp5yIfMxgVn 1ReTPvcEN60pyr872yMXrZ/5ZEoaE1TC6sy+bnnmt1Xoo6oJmFAmDX80aO+XiJxIXXnk OyXIvGGwJgcWaUefwfzxD+CmWaunidNrBv/5lKYxUiEmOb41WbPjsBd4ABKq5ce9S21O Wgpg==
X-Gm-Message-State AN3rC/5pNl/nA+mPF6YS0TTj1BYR9RCd34A5x1scirh7zron6xLwV/PP QttgTw4QuBFJJUPa
X-Received by 10.84.179.99 with SMTP id a90mr82094444plc.26.1494238865343; Mon, 08 May 2017 03:21:05 -0700 (PDT)
MIME-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Disposition inline
User-Agent Mutt/1.5.24 (2015-08-30)
Sender robomod@news.nic.it
List-ID <linux-kernel.vger.kernel.org>
X-Mailing-List linux-kernel@vger.kernel.org
Approved robomod@news.nic.it
Lines 55
Organization linux.* mail to news gateway
X-Original-Cc Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, "Nayak, Rajendra" <rnayak@codeaurora.org>, Stephen Boyd <sboyd@codeaurora.org>, Vincent Guittot <vincent.guittot@linaro.org>, Serge Broslavsky <serge.broslavsky@linaro.org>
X-Original-Date Mon, 8 May 2017 15:51:02 +0530
X-Original-Message-ID <20170508102102.GI17010@vireshk-i7>
X-Original-Sender linux-kernel-owner@vger.kernel.org
Xref csiph.com linux.kernel:1637351

Show key headers only | View raw


Hi Mark/Liam,

I am looking to solve a problem faced by some of the Qualcomm
platforms and want your suggestions on how should we fix it. One of my
ex-colleague tried to solve [1] this problem but that thread never
concluded (and I don't really agree with the solution it offered).


Problem statement

A regulator is shared by multiple devices and their drivers can get
probed in any order. The regulator is configured (with constraints
suitable for one or more devices) by the bootloader (i.e. regulator
was ON at kernel boot). While the drivers get probed, they may choose
to disable or reconfigure the regulator. And that is of course the
right thing to do for those drivers. But this might not be ideal for
other devices which share the regulator and are currently using it
(but haven't been probed yet).

A typical use case in cell phones is to put up a simple splash screen
in the bootloader and replace that screen when userspace is running
(typically with the home screen). If a shared regulator is enabled in
the bootloader to power the screen and left on during kernel
initialization, it's possible that a non-screen driver may disable or
reconfigure the regulator from its probe() and that would generate a
glitch at the screen, which wouldn't be nice.


Solution(s)

There is no way for us to know when the kernel has done booting,
specially with the drivers compiled as modules, as they can be
inserted anytime. For example, if the LCD driver is never inserted to
the kernel, then we should never allow to regulator to get disabled
(Even if that results in loss of energy).

I was wondering if we should add some DT properties to consumer
devices to list down such constraints and create "proxy" regulators
for them as soon as possible during the kernel boot (maybe from
regulator_register()). Of course that would require us to traverse all
DT nodes containing such properties, as the device drivers shouldn't
be up by then.

And finally once the drivers are probed and try to get regulator for
the device, we remove these proxy regulators (only after creating the
real ones). If driver for some proxy regulator doesn't get probed,
then that regulator stays ON for ever.

Suggestions ? Take your time to reply, I know that the merge window
has just started.

-- 
viresh

[1] https://lkml.org/lkml/2016/5/9/64

Back to linux.kernel | Previous | Next | Find similar | Unroll thread


Thread

[RFC] regulator: Shared regulators (configured by bootloader) Viresh Kumar <viresh.kumar@linaro.org> - 2017-05-08 12:30 +0200

csiph-web