Message-Id: <20210708224226.457224-1-djrscally@gmail.com>
Date:   Thu,  8 Jul 2021 23:42:24 +0100
From:   Daniel Scally <djrscally@...il.com>
To:     linux-kernel@...r.kernel.org, platform-driver-x86@...r.kernel.org
Cc:     hdegoede@...hat.com, mgross@...ux.intel.com,
        luzmaximilian@...il.com, lgirdwood@...il.com, broonie@...nel.org,
        andy.shevchenko@...il.com, laurent.pinchart@...asonboard.com,
        kieran.bingham@...asonboard.com
Subject: [RFC PATCH 0/2] Add software node support to regulator framework

Hello all

See previous series for some background context [1]

Some x86 laptops with ACPI tables designed for Windows have a TPS68470
PMIC providing regulators and clocks to camera modules. The DSDT tables for
those cameras lack any power control methods, declaring only a
dependency on the ACPI device representing the TPS68470. This leaves the
regulator framework with no means of determining appropriate voltages for the
regulators provided by the PMIC, or of determining which regulators relate to
which of the sensor's requested supplies. 

This series is a prototype of an emulation of the device tree regulator
initialisation and lookup functions, using software nodes. Software nodes
relating to each regulator are registered as children of the TPS68470's ACPI
firmware node. Those regulators have properties describing their constraints
(for example "regulator-min-microvolt"). Similarly, software nodes are
registered and assigned as secondary to the Camera's firmware node - these
software nodes have reference properties named after the supply in the same
way as device tree's phandles, for example "avdd-supply", and linking to the
software node assigned to the appropriate regulator. We can then use those
constraints to specify the appropriate voltages and the references to allow the
camera drivers to look up the correct regulator device. 

Although not included in this series, I would plan to use a similar method for
linking the clocks provided by the TPS68470 to the sensor so that it can be
discovered too.

I'm posting this to see if people agree it's a good approach for tackling the 
problem; I may be overthinking this and there's a much easier way that I should
be looking at instead. It will have knock-ons in the cio2-bridge code [2], as
that is adding software nodes to the same sensors to connect them to the media
graph. Similarly, is the board file an acceptable solution, or should we just
define the configuration for these devices (there's three orf our laptop models
in scope) in int3472-tps68470 instead?

Thanks
Dan

[1] https://lore.kernel.org/lkml/20210603224007.120560-1-djrscally@gmail.com/
[2] https://elixir.bootlin.com/linux/latest/source/drivers/media/pci/intel/ipu3/cio2-bridge.c#L166


Daniel Scally (2):
  regulator: Add support for software node connections
  platform/surface: Add Surface Go 2 board file

 MAINTAINERS                                |   6 +
 drivers/platform/surface/Kconfig           |  10 ++
 drivers/platform/surface/Makefile          |   1 +
 drivers/platform/surface/surface_go_2.c    | 135 +++++++++++++++++++++
 drivers/regulator/Kconfig                  |   6 +
 drivers/regulator/Makefile                 |   1 +
 drivers/regulator/core.c                   |  23 ++++
 drivers/regulator/swnode_regulator.c       | 111 +++++++++++++++++
 include/linux/regulator/swnode_regulator.h |  33 +++++
 9 files changed, 326 insertions(+)
 create mode 100644 drivers/platform/surface/surface_go_2.c
 create mode 100644 drivers/regulator/swnode_regulator.c
 create mode 100644 include/linux/regulator/swnode_regulator.h

-- 
2.25.1

Powered by blists - more mailing lists