mbox series

[V6,Resend,00/13] drivers: Boot Constraint core

Message ID cover.1515554879.git.viresh.kumar@linaro.org
Headers show
Series drivers: Boot Constraint core | expand

Message

Viresh Kumar Jan. 10, 2018, 3:47 a.m. UTC
Hi Greg,

I am re-sending V6 as you suggested. There is no change from the patches
sent on 14/15th of December, apart from rebasing on driver-core-next.

I have tested the Hisilicon patches (again) on hikey 9660 board, IMX
stuff was earlier tested by Sascha (Pengutronix) on i.MX6 and Qualcomm
stuff was earlier tested by Rajendra (Qualcomm) on Dragonboard 410C
(This required some more patches related to display driver which
Rajendra should be sending separately later on).


Problem statement:

Some devices are powered ON by the bootloader before the bootloader
handovers control to Linux. It maybe important for those devices to keep
working until the time a Linux device driver probes the device and
reconfigure its resources.

A typical example of that can be the LCD controller, which is used by
the bootloaders to show image(s) while the platform is booting into
Linux.  The LCD controller can be using some resources, like clk,
regulators, etc, that are shared between several devices. These shared
resources should be configured to satisfy need of all the users.  If
another device's (X) driver gets probed before the LCD controller driver
in this case, then it may end up disabling or reconfiguring these
resources to ranges satisfying the current users (only device X) and
that can make the LCD screen unstable.

Another case can be a debug serial port enabled from the bootloader.

Of course we can have more complex cases where the same resource is
getting used by two devices while the kernel boots and the order in
which devices get probed wouldn't matter as the other device will surely
break then.

There are also cases where the resources may not be shared, but the
kernel will disable them forcefully as no users may have appeared until
a certain point in kernel boot. This makes sure that the resources stay
enabled. A wide variety of constraints can be satisfied using the new
framework.

Proposed solution:

This series introduces the concept of "boot-constraint", which are set
by platform specific drivers (for now at least) at early init (like
subsys_initcall) and the kernel will keep satisfying them until the time
driver for such a device is probed (successfully or unsuccessfully).
Once the driver is probed, the driver core removes the constraints set
for the device. This series implements clk, regulator and PM domain
constraints currently.

Pushed here:
git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/linux.git boot-constraints

V5->V6:
- Fix a build error reported by build bot for !CONFIG_OF_ADDRESS. This
  was already sent on 15th December.
- Rebased over latest driver-core-next.

V4->V5:
- SPDX Licence format used.
- arm,primecell stuff removed from boot constraint core and added a
  helper in OF core (which already handles amba and platform devices).
- Removed a bunch of BUG_ON(), pr_fmt(), comments.
- Changed directory and other names from
  boot_constraints/boot_constraint.
- Removed serial.o file and moved the code to hikey and imx files.
- Don't return error from dummy helper.
- Added documentation and corresponding kernel doc comments in the code.
- Updated MAINTAINERS.

V3->V4:
- Added support for imx, hikey and Qcom usecases.
- Enhanced boot constraints core to make drivers code easy and handle
  complex cases.
- Two new patches for OF included to provide APIs to boot constraint
  core.
- Removed the kernel parameter patch for now.
- Don't check return values of debugfs routines.
- Moved the boot constraints core from drivers/base/ to drivers/.

V2->V3:
- Removed DT support as we aren't sure about how to define the bindings
  yet.
- Added CLK and PM domain constraint types.
- A new directory is added for boot constraints, which will also contain
  platform specific drivers in future.
- Deferred devices are still supported, just that it wouldn't be called
  from generic code anymore but platform specific code.
- Tested on Qcom 410c dragonboard with display flash screen (Rajendra).
- Usual renaming/commit-log-updates/etc changes done.

V1->V2:
- Add support for setting constraints for devices created from DT.
- Allow handling deferred devices earlier then late_init.
- Remove 'default y' line from kconfig.
- Drop '=" after boot_constraints_disable kernel param.
- Dropped the dummy testing patch now.

--
viresh

Rajendra Nayak (1):
  boot_constraint: Add Qualcomm display controller constraints

Viresh Kumar (12):
  of: platform: Add of_find_any_device_by_node()
  of: platform: Make of_platform_bus_create() global
  drivers: Add boot constraints core
  boot_constraint: Add support for supply constraints
  boot_constraint: Add support for clk constraints
  boot_constraint: Add support for PM constraints
  boot_constraint: Add debugfs support
  boot_constraint: Manage deferrable constraints
  boot_constraint: Add support for Hisilicon platforms
  boot_constraint: Add support for IMX platform
  boot_constraint: Update MAINTAINERS
  boot_constraint: Add documentation

 .../driver-api/boot-constraint/constraints.rst     |  98 +++++++
 Documentation/driver-api/boot-constraint/index.rst |   4 +
 Documentation/driver-api/index.rst                 |   1 +
 MAINTAINERS                                        |   9 +
 arch/arm/mach-imx/Kconfig                          |   1 +
 arch/arm64/Kconfig.platforms                       |   2 +
 drivers/Kconfig                                    |   2 +
 drivers/Makefile                                   |   1 +
 drivers/base/dd.c                                  |  32 ++-
 drivers/boot_constraint/Kconfig                    |   9 +
 drivers/boot_constraint/Makefile                   |   7 +
 drivers/boot_constraint/clk.c                      |  70 +++++
 drivers/boot_constraint/core.c                     | 290 +++++++++++++++++++++
 drivers/boot_constraint/core.h                     |  47 ++++
 drivers/boot_constraint/deferrable_dev.c           | 241 +++++++++++++++++
 drivers/boot_constraint/hikey.c                    | 158 +++++++++++
 drivers/boot_constraint/imx.c                      | 126 +++++++++
 drivers/boot_constraint/pm.c                       |  28 ++
 drivers/boot_constraint/qcom.c                     | 122 +++++++++
 drivers/boot_constraint/supply.c                   | 104 ++++++++
 drivers/clk/imx/clk-imx25.c                        |  12 -
 drivers/clk/imx/clk-imx27.c                        |  13 -
 drivers/clk/imx/clk-imx31.c                        |  12 -
 drivers/clk/imx/clk-imx35.c                        |  10 -
 drivers/clk/imx/clk-imx51-imx53.c                  |  16 --
 drivers/clk/imx/clk-imx6q.c                        |   8 -
 drivers/clk/imx/clk-imx6sl.c                       |   8 -
 drivers/clk/imx/clk-imx6sx.c                       |   8 -
 drivers/clk/imx/clk-imx7d.c                        |  14 -
 drivers/clk/imx/clk.c                              |  38 ---
 drivers/clk/imx/clk.h                              |   1 -
 drivers/of/platform.c                              |  63 ++++-
 include/linux/boot_constraint.h                    | 121 +++++++++
 include/linux/of_platform.h                        |  16 ++
 34 files changed, 1541 insertions(+), 151 deletions(-)
 create mode 100644 Documentation/driver-api/boot-constraint/constraints.rst
 create mode 100644 Documentation/driver-api/boot-constraint/index.rst
 create mode 100644 drivers/boot_constraint/Kconfig
 create mode 100644 drivers/boot_constraint/Makefile
 create mode 100644 drivers/boot_constraint/clk.c
 create mode 100644 drivers/boot_constraint/core.c
 create mode 100644 drivers/boot_constraint/core.h
 create mode 100644 drivers/boot_constraint/deferrable_dev.c
 create mode 100644 drivers/boot_constraint/hikey.c
 create mode 100644 drivers/boot_constraint/imx.c
 create mode 100644 drivers/boot_constraint/pm.c
 create mode 100644 drivers/boot_constraint/qcom.c
 create mode 100644 drivers/boot_constraint/supply.c
 create mode 100644 include/linux/boot_constraint.h

-- 
2.15.0.194.g9af6a3dea062

Comments

Rob Herring Jan. 10, 2018, 11:13 p.m. UTC | #1
On Tue, Jan 9, 2018 at 9:47 PM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> Hi Greg,

>

> I am re-sending V6 as you suggested. There is no change from the patches

> sent on 14/15th of December, apart from rebasing on driver-core-next.

>

> I have tested the Hisilicon patches (again) on hikey 9660 board, IMX

> stuff was earlier tested by Sascha (Pengutronix) on i.MX6 and Qualcomm

> stuff was earlier tested by Rajendra (Qualcomm) on Dragonboard 410C

> (This required some more patches related to display driver which

> Rajendra should be sending separately later on).

>

>

> Problem statement:

>

> Some devices are powered ON by the bootloader before the bootloader

> handovers control to Linux. It maybe important for those devices to keep

> working until the time a Linux device driver probes the device and

> reconfigure its resources.


Some devices are powered on by a bootloader, but only a small few have
to be maintained thru booting. Most you can just re-initialized.

> A typical example of that can be the LCD controller, which is used by

> the bootloaders to show image(s) while the platform is booting into

> Linux.  The LCD controller can be using some resources, like clk,

> regulators, etc, that are shared between several devices. These shared

> resources should be configured to satisfy need of all the users.  If

> another device's (X) driver gets probed before the LCD controller driver

> in this case, then it may end up disabling or reconfiguring these

> resources to ranges satisfying the current users (only device X) and

> that can make the LCD screen unstable.


We already have simple fb and a binding for it. It only handles clocks
I think, but could be extended to other things. I rather not extend
it, but it is there already and we don't need different solutions for
this.

> Another case can be a debug serial port enabled from the bootloader.


I looked at your case with HiKey some. As far as the PL011
driver/console is concerned, it should work as the clock is never
enabled/disabled and then probe deferred (IMO, doing any h/w init
before all resources are acquired is a driver error). The problem is
the AMBA bus enabling apb_pclk (which has a dedicated clk gate) and
then disabling it on deferred probe. The AMBA bus is fairly odd in
this regard. We could solve this just with an initcall to find
stdout-path node and enable all the clocks in the node and then a late
initcall to disable those clocks. Kind of hacky, but so is this
series.

Really, I think the clock framework is broken in that we leave clocks
in a mismatched state (reset state or whatever the bootloader decided)
until the end of booting. Then we are left with dealing with these
various platform specific issues. We should either not actually
disable clocks until the end of boot (just defer until we turn off all
unused clocks) or start requiring the clock drivers to turn off all
the clocks except the ones needed to continue booting (or otherwise
known to be constraints). The former should be easy to implement
because the code to turn off clocks is already there. We just need a
boot done flag and check that flag in disable function.

Rob
Chen-Yu Tsai Jan. 11, 2018, 2:07 a.m. UTC | #2
On Thu, Jan 11, 2018 at 7:13 AM, Rob Herring <robh+dt@kernel.org> wrote:
> On Tue, Jan 9, 2018 at 9:47 PM, Viresh Kumar <viresh.kumar@linaro.org> wrote:

>> Hi Greg,

>>

>> I am re-sending V6 as you suggested. There is no change from the patches

>> sent on 14/15th of December, apart from rebasing on driver-core-next.

>>

>> I have tested the Hisilicon patches (again) on hikey 9660 board, IMX

>> stuff was earlier tested by Sascha (Pengutronix) on i.MX6 and Qualcomm

>> stuff was earlier tested by Rajendra (Qualcomm) on Dragonboard 410C

>> (This required some more patches related to display driver which

>> Rajendra should be sending separately later on).

>>

>>

>> Problem statement:

>>

>> Some devices are powered ON by the bootloader before the bootloader

>> handovers control to Linux. It maybe important for those devices to keep

>> working until the time a Linux device driver probes the device and

>> reconfigure its resources.

>

> Some devices are powered on by a bootloader, but only a small few have

> to be maintained thru booting. Most you can just re-initialized.

>

>> A typical example of that can be the LCD controller, which is used by

>> the bootloaders to show image(s) while the platform is booting into

>> Linux.  The LCD controller can be using some resources, like clk,

>> regulators, etc, that are shared between several devices. These shared

>> resources should be configured to satisfy need of all the users.  If

>> another device's (X) driver gets probed before the LCD controller driver

>> in this case, then it may end up disabling or reconfiguring these

>> resources to ranges satisfying the current users (only device X) and

>> that can make the LCD screen unstable.

>

> We already have simple fb and a binding for it. It only handles clocks

> I think, but could be extended to other things. I rather not extend

> it, but it is there already and we don't need different solutions for

> this.


simplefb also handles regulators. This was added quite a while ago to
keep LCD displays powered on Allwinner tablets. However in general it
only grabs references to these resources and enables them so the kernel
frameworks don't think they are unused and turn them off. It doesn't
do clock rate or voltage constraints which Viresh wants. It should be
easy to do for regulators, and AFAIK there is a clock rate protection
mechanism for the clk framework in the works.

ChenYu

>> Another case can be a debug serial port enabled from the bootloader.

>

> I looked at your case with HiKey some. As far as the PL011

> driver/console is concerned, it should work as the clock is never

> enabled/disabled and then probe deferred (IMO, doing any h/w init

> before all resources are acquired is a driver error). The problem is

> the AMBA bus enabling apb_pclk (which has a dedicated clk gate) and

> then disabling it on deferred probe. The AMBA bus is fairly odd in

> this regard. We could solve this just with an initcall to find

> stdout-path node and enable all the clocks in the node and then a late

> initcall to disable those clocks. Kind of hacky, but so is this

> series.

>

> Really, I think the clock framework is broken in that we leave clocks

> in a mismatched state (reset state or whatever the bootloader decided)

> until the end of booting. Then we are left with dealing with these

> various platform specific issues. We should either not actually

> disable clocks until the end of boot (just defer until we turn off all

> unused clocks) or start requiring the clock drivers to turn off all

> the clocks except the ones needed to continue booting (or otherwise

> known to be constraints). The former should be easy to implement

> because the code to turn off clocks is already there. We just need a

> boot done flag and check that flag in disable function.
Rob Herring Jan. 11, 2018, 1:45 p.m. UTC | #3
On Wed, Jan 10, 2018 at 8:07 PM, Chen-Yu Tsai <wens@csie.org> wrote:
> On Thu, Jan 11, 2018 at 7:13 AM, Rob Herring <robh+dt@kernel.org> wrote:

>> On Tue, Jan 9, 2018 at 9:47 PM, Viresh Kumar <viresh.kumar@linaro.org> wrote:

>>> Hi Greg,

>>>

>>> I am re-sending V6 as you suggested. There is no change from the patches

>>> sent on 14/15th of December, apart from rebasing on driver-core-next.

>>>

>>> I have tested the Hisilicon patches (again) on hikey 9660 board, IMX

>>> stuff was earlier tested by Sascha (Pengutronix) on i.MX6 and Qualcomm

>>> stuff was earlier tested by Rajendra (Qualcomm) on Dragonboard 410C

>>> (This required some more patches related to display driver which

>>> Rajendra should be sending separately later on).

>>>

>>>

>>> Problem statement:

>>>

>>> Some devices are powered ON by the bootloader before the bootloader

>>> handovers control to Linux. It maybe important for those devices to keep

>>> working until the time a Linux device driver probes the device and

>>> reconfigure its resources.

>>

>> Some devices are powered on by a bootloader, but only a small few have

>> to be maintained thru booting. Most you can just re-initialized.

>>

>>> A typical example of that can be the LCD controller, which is used by

>>> the bootloaders to show image(s) while the platform is booting into

>>> Linux.  The LCD controller can be using some resources, like clk,

>>> regulators, etc, that are shared between several devices. These shared

>>> resources should be configured to satisfy need of all the users.  If

>>> another device's (X) driver gets probed before the LCD controller driver

>>> in this case, then it may end up disabling or reconfiguring these

>>> resources to ranges satisfying the current users (only device X) and

>>> that can make the LCD screen unstable.

>>

>> We already have simple fb and a binding for it. It only handles clocks

>> I think, but could be extended to other things. I rather not extend

>> it, but it is there already and we don't need different solutions for

>> this.

>

> simplefb also handles regulators. This was added quite a while ago to

> keep LCD displays powered on Allwinner tablets. However in general it

> only grabs references to these resources and enables them so the kernel

> frameworks don't think they are unused and turn them off. It doesn't

> do clock rate or voltage constraints which Viresh wants. It should be

> easy to do for regulators, and AFAIK there is a clock rate protection

> mechanism for the clk framework in the works.


Why do we need constraints beyond taking a reference? The constraint
is don't change things. If it is more complex than that, then you need
something to parse the "real" DT nodes for the h/w blocks.

Rob
Viresh Kumar Jan. 25, 2018, 11:01 a.m. UTC | #4
On 10-01-18, 17:13, Rob Herring wrote:
> On Tue, Jan 9, 2018 at 9:47 PM, Viresh Kumar <viresh.kumar@linaro.org> wrote:

> > A typical example of that can be the LCD controller, which is used by

> > the bootloaders to show image(s) while the platform is booting into

> > Linux.  The LCD controller can be using some resources, like clk,

> > regulators, etc, that are shared between several devices. These shared

> > resources should be configured to satisfy need of all the users.  If

> > another device's (X) driver gets probed before the LCD controller driver

> > in this case, then it may end up disabling or reconfiguring these

> > resources to ranges satisfying the current users (only device X) and

> > that can make the LCD screen unstable.

> 

> We already have simple fb and a binding for it. It only handles clocks

> I think, but could be extended to other things. I rather not extend

> it, but it is there already and we don't need different solutions for

> this.


Got a bit busy lately and wasn't able to look into the details of it.

So AFAICT the basic problem I was trying to solve still exists with simple-fb
as well. And the problem is that nothing prevents another driver to get probed
before the display driver (or simple-fb) and reconfigure the resources. Even if
we let simple-fb come up really early, the resources like clk/regulator may not
be available. And so the ordering thing is still unsolved for me.

-- 
viresh
Viresh Kumar Feb. 12, 2018, 7:10 a.m. UTC | #5
On 25-01-18, 16:31, Viresh Kumar wrote:
> So AFAICT the basic problem I was trying to solve still exists with simple-fb

> as well. And the problem is that nothing prevents another driver to get probed

> before the display driver (or simple-fb) and reconfigure the resources. Even if

> we let simple-fb come up really early, the resources like clk/regulator may not

> be available. And so the ordering thing is still unsolved for me.


Ping !!

I understand your concerns Rob, they are surely genuine and I can't
deny that. But I don't see a cleaner "way" (Or "Hack", if you want to
call it that way), to solve these ugly problems.

-- 
viresh