mbox series

[V5,00/13] drivers: Boot Constraint core

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

Message

Viresh Kumar Dec. 14, 2017, 3:33 p.m. UTC
Hi Greg,

Here is V5 of the boot constraints core based on your feedback from V4.
Hope this looks better now :)

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.

Targeted for: v4.16

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

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

Greg Kroah-Hartman Jan. 9, 2018, 6:47 p.m. UTC | #1
On Thu, Dec 14, 2017 at 09:03:07PM +0530, Viresh Kumar wrote:
> Hi Greg,

> 

> Here is V5 of the boot constraints core based on your feedback from V4.

> Hope this looks better now :)

> 

> 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).


Can you resend this?  As you can tell, I've been a bit busy for the past
month or so :(

And you had a few different versions of at least one of these patches,
which is messy.  Also, why is there no signed-off-by on the OF core
patches?

thanks,

greg k-h
Viresh Kumar Jan. 10, 2018, 3:44 a.m. UTC | #2
On 09-01-18, 19:47, Greg Kroah-Hartman wrote:
> Can you resend this?  As you can tell, I've been a bit busy for the past

> month or so :(


Sure.

> Also, why is there no signed-off-by on the OF core patches?


A bit confused, sorry. Are you looking for my signed-off ? They are already
there.

Or are you looking for Rob's (OF maintainer) signed-off ?

-- 
viresh
Greg Kroah-Hartman Jan. 10, 2018, 8:08 a.m. UTC | #3
On Wed, Jan 10, 2018 at 09:14:40AM +0530, Viresh Kumar wrote:
> On 09-01-18, 19:47, Greg Kroah-Hartman wrote:

> > Can you resend this?  As you can tell, I've been a bit busy for the past

> > month or so :(

> 

> Sure.

> 

> > Also, why is there no signed-off-by on the OF core patches?

> 

> A bit confused, sorry. Are you looking for my signed-off ? They are already

> there.

> 

> Or are you looking for Rob's (OF maintainer) signed-off ?


Looking for Rob's, why hasn't he reviewed this yet?

thanks,

greg k-h
Viresh Kumar Jan. 10, 2018, 8:42 a.m. UTC | #4
On 10-01-18, 09:08, Greg Kroah-Hartman wrote:
> On Wed, Jan 10, 2018 at 09:14:40AM +0530, Viresh Kumar wrote:

> > On 09-01-18, 19:47, Greg Kroah-Hartman wrote:

> > > Can you resend this?  As you can tell, I've been a bit busy for the past

> > > month or so :(

> > 

> > Sure.

> > 

> > > Also, why is there no signed-off-by on the OF core patches?

> > 

> > A bit confused, sorry. Are you looking for my signed-off ? They are already

> > there.

> > 

> > Or are you looking for Rob's (OF maintainer) signed-off ?

> 

> Looking for Rob's, why hasn't he reviewed this yet?


He went through them for sure but never gave his Ack. I have asked him to
provide Acks for the first 2 patches this morning, if they look fine to him.

-- 
viresh
Rob Herring Jan. 10, 2018, 6:19 p.m. UTC | #5
On Wed, Jan 10, 2018 at 2:42 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 10-01-18, 09:08, Greg Kroah-Hartman wrote:

>> On Wed, Jan 10, 2018 at 09:14:40AM +0530, Viresh Kumar wrote:

>> > On 09-01-18, 19:47, Greg Kroah-Hartman wrote:

>> > > Can you resend this?  As you can tell, I've been a bit busy for the past

>> > > month or so :(

>> >

>> > Sure.

>> >

>> > > Also, why is there no signed-off-by on the OF core patches?

>> >

>> > A bit confused, sorry. Are you looking for my signed-off ? They are already

>> > there.

>> >

>> > Or are you looking for Rob's (OF maintainer) signed-off ?

>>

>> Looking for Rob's, why hasn't he reviewed this yet?


I did review the whole series on version v4... The whole thing seems
pretty hacky to me. OTOH, I don't know if there's an elegant solution
to this problem. This also tries to be a general solution for what's
largely an earlycon (which is, news flash, a debug tool) and displays
for which we already address at least some of this with simplefb (not
that it is a great solution either). I've yet to hear of any other
concrete uses for this.

> He went through them for sure but never gave his Ack. I have asked him to

> provide Acks for the first 2 patches this morning, if they look fine to him.


The drivers/of/ changes on their own are innocent enough if there's a
reason (We generally want users using of_platform_populate rather than
of_platform_bus_create, so that's why it's not exported now.). It's
really all the rest that concerns me.

Rob
Olof Johansson Jan. 10, 2018, 6:54 p.m. UTC | #6
Hi,

On Thu, Dec 14, 2017 at 7:33 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> Hi Greg,

>

> Here is V5 of the boot constraints core based on your feedback from V4.

> Hope this looks better now :)

>

> 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.

>

> Targeted for: v4.16

>

> Pushed here:

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

>

> 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 ++++++++


The SoC-specific pieces should preferrably go under drivers/soc
instead, to reduce cross-tree dependencies when introducing new SoC
variants.

They're more related to the SoC than to the boot_constraint framework anyway.

Bikeshed: We've traditionally had really terse and precise names under
drivers/. This is the first verbose one with a _ in it. Maybe find a
shorter name or just concatenate to 'bootconstraints'? We didn't call
it remote_proc or rapid_io, etc, either. :)

-Olof
Viresh Kumar Jan. 11, 2018, 9:51 a.m. UTC | #7
On 10-01-18, 10:54, Olof Johansson wrote:
> The SoC-specific pieces should preferrably go under drivers/soc

> instead, to reduce cross-tree dependencies when introducing new SoC

> variants.

> 

> They're more related to the SoC than to the boot_constraint framework anyway.


Hmm, okay.

> Bikeshed: We've traditionally had really terse and precise names under

> drivers/. This is the first verbose one with a _ in it. Maybe find a

> shorter name or just concatenate to 'bootconstraints'? We didn't call

> it remote_proc or rapid_io, etc, either. :)


Sure.

-- 
viresh