public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: viresh.kumar@linaro.org (Viresh Kumar)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC 0/5] drivers: Add boot constraints core
Date: Thu, 29 Jun 2017 20:17:11 +0530	[thread overview]
Message-ID: <20170629144711.GO29665@vireshk-i7> (raw)
In-Reply-To: <beab4875-8dd7-43d7-9ad2-6e38963d7d4c@gr13.net>

On 29-06-17, 12:40, Enrico Weigelt, metux IT consult wrote:
> Just curious: aren't the devices (at least w/ DT) only initialized after
> dependencies (eg. regulators) are already up ?

No. Drivers are registered to the kernel (randomly, though we can know
their order) and devices are registered separately (platform/amba
devices get registered automatically with DT, hint:
drivers/of/platform.c). The device core checks while registering
devices/drivers if their drivers/devices are available or not. If
yes, then the devices are probed using the drivers. Now the drivers
must make sure all the dependencies are met at this point, else they
can return -EPROBE_DEFER and the kernel will try probing them again.

> Let's imagine a LCD panel driven by a regulator behind SPI. The panel
> driver would ask the regulator framework to switch on, which would
> call the regulator driver. This one now would talk to SPI framework,
> which finally calls the SPI driver. If SPI isn't up yet, it would all
> be deferred, leaving the panel driver uninitialized (tried again later).

This should happen in probe, otherwise we are screwed.

> If the bootloader already switched on the panel (therefore already
> enabled SPI), why does it matter that the panel driver isn't up yet ?

But the kernel doesn't know how it is configured, there can be so many
configurable parameters. The kernel needs to do it again by itself.

> Is there anything that accidentially switches it off again (eg. by
> resetting the regulator) ?

It is not just about switching it off, but the configuration here.

Let me try with an example. A regulator is shared between LCD and DMA
controller.

Operable ranges of the regulator: 1.8 - 3.0 V
Range required by LCD: 2.0 - 3.0 V
Range required by DMA: 1.8 - 2.5 V

Of course the right range for both of them to work here is 2.0 - 2.5
V.

Now the LCD is already enabled by the bootloader and kernel doesn't
know the ranges. DMA requests for the regulator and we set its voltage
to 1.8 V. LCD is screwed while we are still booting.

This will go worse if we add more devices to this example that share
the same regulator.

-- 
viresh

  reply	other threads:[~2017-06-29 14:47 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-28 10:26 [RFC 0/5] drivers: Add boot constraints core Viresh Kumar
2017-06-28 10:26 ` [RFC 1/5] " Viresh Kumar
2017-06-28 15:55   ` Randy Dunlap
2017-06-29  3:51     ` Viresh Kumar
2017-06-29 12:50       ` Russell King - ARM Linux
2017-06-29 14:49         ` Viresh Kumar
2017-06-28 10:26 ` [RFC 2/5] drivers: boot_constraint: Add support for supply constraints Viresh Kumar
2017-06-28 10:26 ` [RFC 3/5] drivers: boot_constraint: Add boot_constraints_disable kernel parameter Viresh Kumar
2017-06-28 15:51   ` Randy Dunlap
2017-06-28 10:26 ` [RFC 4/5] drivers: boot_constraint: Add debugfs support Viresh Kumar
2017-06-28 15:46   ` Randy Dunlap
2017-06-29  4:11     ` Viresh Kumar
2017-06-28 10:26 ` [RFC 5/5] drivers: Code to test boot constraints Viresh Kumar
2017-06-29 12:40 ` [RFC 0/5] drivers: Add boot constraints core Enrico Weigelt, metux IT consult
2017-06-29 14:47   ` Viresh Kumar [this message]
2017-06-29 15:06     ` Enrico Weigelt, metux IT consult
2017-06-30  3:16       ` Viresh Kumar
2017-06-30  3:33         ` Chen-Yu Tsai
2017-06-30  3:55           ` Viresh Kumar
2017-06-30  4:05             ` Chen-Yu Tsai
2017-06-30  4:12               ` Viresh Kumar
2017-06-30  4:22                 ` Chen-Yu Tsai
2017-06-30  5:12                   ` Viresh Kumar
2017-06-30  6:36                     ` Chen-Yu Tsai
2017-06-30  8:43                       ` Viresh Kumar
2017-06-30 12:10                         ` Mark Brown
2017-07-03  6:15                           ` Viresh Kumar
2017-07-03 15:07                             ` Mark Brown
2017-07-04  6:45                               ` Viresh Kumar
2017-06-30 12:12                   ` Mark Brown
2017-06-29 12:49 ` Russell King - ARM Linux
2017-06-29 13:05   ` Enrico Weigelt, metux IT consult
2017-06-29 14:58   ` Viresh Kumar
2017-06-29 15:43     ` Russell King - ARM Linux
2017-06-29 21:00       ` Stephen Boyd
2017-07-05 22:07         ` Rob Clark
2017-07-07 22:39           ` Stephen Boyd

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170629144711.GO29665@vireshk-i7 \
    --to=viresh.kumar@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox