* [PATCH v7 00/12] mux controller abstraction and iio/i2c muxes
From: Peter Rosin @ 2017-01-04 12:16 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Peter Rosin, Wolfram Sang, Rob Herring, Mark Rutland,
Jonathan Cameron, Hartmut Knaack, Lars-Peter Clausen,
Peter Meerwald-Stadler, Jonathan Corbet, Arnd Bergmann,
Greg Kroah-Hartman, linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA
Hi!
v6 -> v7 changes
- move from drivers/misc/mux-* to drivers/mux/
[I will remove Cc:s to Arnd and Greg for v8, when/if that happens]
- add managed versions of mux_chip_alloc and mux_chip_register
- use the above in mux-gpio.c and mux-adg792a.c
- also use them to support a simplified binding of a gpio mux for the common
case where there is a single consumer (and no specific idle requirements)
- new binding for describing idle behaviour of mux-adg792a
- add bindings for the gpo-pins on the mux-adg792g
- use device_property_read_u32 instead of of_property_read_u32 in mux-gpio.c
- rename iio mux compatible to io-channel-mux (was iio-mux)
- remove linuxism in the bindings (it was mentioning a function name)
- add missing quote in the example in the io-channel-mux binding
- factor out preparatory cleanup of devres docs to its own patch
- add blank line in mux_chip_free
- use SIMPLE_{PARENT,MUX}_LOCKED instead of magic numbers {0,1} in
i2c-mux-simple.c
- add some acks and a reviewed-by from Jonathan
v5 -> v6 changes
- fix stupidity in mux_chip_priv, mux_gpio_remove and adg792a_remove.
- change the devicetree bindings for the iio-mux to use a list of strings
(channels property) instead of a list children.
v4 -> v5 changes
- remove support for fancier dt layouts and go back to the phandle
approach from v2 and before, killing the horrible non-working
refcounting crap from v4 and avoiding a bunch of life-time issues
in v3.
- introduce the concept of a mux-chip, that can hold one or more
mux-controllers (inspired by the pwm subsystem).
- add dt #mux-control-cells property needed to get to the desired
mux controller if a mux chip provides more than one.
- take away the option to build the mux-core as a module.
- if the mux controller has an idle state, make sure the mux controller
is set up in the idle state initially (when it should be idle).
- do not use a variable length array on the stack in mux_gpio_set to
temporarily store the gpio state, preallocate space instead.
- fix resource leak on one failure path in mux_gpio_probe.
- driver for Analog Devices ADG792A/G, literally the first mux chip
I found on the Internet with an i2c interface (that was not a
dedicated i2c multiplexer like PCA9547) which I used to verify
that the abstractions in the mux core are up to the task. Untested,
just proof of concept that at least looks pretty and compiles...
- various touch-ups.
v3 -> v4 changes
- rebased onto next-20161122 (depends on recent _available iio changes).
- added support for having the mux-controller in a child node of a
mux-consumer if it is a sole consumer, to hopefully even further satisfy
the complaint from Rob (and later Lars-Peter) about dt complexity.
- the above came at the cost of some rather horrible refcounting code,
please review and suggest how it should be done...
- changed to register a device class instead of a bus.
- pass in the parent device into mux_control_alloc and require less
work from mux-control drivers.
- changed device names from mux:control%d to mux%d
- move kernel-doc from mux-core.c to mux.h (and add some bits).
- give the gpio driver a chance to update all mux pins at once.
- factor out iio ext_info lookup into new helper function. /Lars-Peter
- use an unsigned type for the iio ext_info count. /Lars-Peter
- unified "brag strings" in the file headers.
v2 -> v3 changes
- have the mux-controller in the parent node of any mux-controller consumer,
to hopefully satisfy complaint from Rob about dt complexity.
- improve commit message of the mux subsystem commit, making it more
general, as requested by Jonathan.
- remove priv member from struct mux_control and calculate it on the
fly. /Jonathan
- make the function comments in mux-core.c kernel doc. /Jonathan
- add devm_mux_control_* to Documentation/driver.model/devres.txt. /Jonathan
- add common dt bindings for mux-controllers, refer to them from the
mux-gpio bindings. /Rob
- clarify how the gpio pins map to the mux state. /Rob
- separate CONFIG_ variables for the mux core and the mux gpio driver.
- improve Kconfig help texts.
- make CONFIG_MUX_GPIO depend on CONFIG_GPIOLIB.
- keep track of the number of mux states in the mux core.
- since the iio channel number is used as mux state, it was possible
to drop the state member from the mux_child struct.
- cleanup dt bindings for i2c-mux-simple, it had some of copy-paste
problems from ots origin (i2c-mux-gpio).
- select the mux control subsystem in config for the i2c-mux-simple driver.
- add entries to MAINTAINERS and my sign-off, I'm now satisfied and know
nothing in this to be ashamed of.
v1 -> v2 changes
- fixup export of mux_control_put reported by kbuild
- drop devicetree iio-ext-info property as noted by Lars-Peter,
and replace the functionality by exposing all ext_info
attributes of the parent channel for each of the muxed
channels. A cache on top of that and each muxed channel
gets its own view of the ext_info of the parent channel.
- implement idle-state for muxes
- clear out the cache on failure in order to force a mux
update on the following use
- cleanup the probe of i2c-mux-simple driver
- fix a bug in the i2c-mux-simple driver, where failure in
the selection of the mux caused a deadlock when the mux
was later unconditionally deselected.
I have a piece of hardware that is using the same 3 GPIO pins
to control four 8-way muxes. Three of them control ADC lines
to an ADS1015 chip with an iio driver, and the last one
controls the SDA line of an i2c bus. We have some deployed
code to handle this, but you do not want to see it or ever
hear about it. I'm not sure why I even mention it. Anyway,
the situation has nagged me to no end for quite some time.
So, after first getting more intimate with the i2c muxing code
and later discovering the drivers/iio/inkern.c file and
writing a couple of drivers making use of it, I came up with
what I think is an acceptable solution; add a generic mux
controller driver (and subsystem) that is shared between all
instances, and combine that with an iio mux driver and a new
generic i2c mux driver. The new i2c mux I called "simple"
since it is only hooking the i2c muxing and the new mux
controller (much like the alsa simple card driver does for ASoC).
One thing that I would like to do, but don't see a solution
for, is to move the mux control code that is present in
various drivers in drivers/i2c/muxes to this new minimalistic
muxing subsystem, thus converting all present i2c muxes (but
perhaps not gates and arbitrators) to be i2c-mux-simple muxes.
I'm using an rwsem to lock a mux, but that isn't really a
perfect fit. Is there a better locking primitive that I don't
know about that fits better? I had a mutex at one point, but
that didn't allow any concurrent accesses at all. At least
the rwsem allows concurrent access as long as all users
agree on the mux state, but I suspect that the rwsem will
degrade to the mutex situation pretty quickly if there is
any contention.
Also, the "mux" name feels a bit ambitious, there are many muxes
in the world, and this tiny bit of code is probably not good
enough to be a nice fit for all...
Cheers,
peda
Peter Rosin (12):
devres: trivial whitespace fix
dt-bindings: document devicetree bindings for mux-controllers and
mux-gpio
mux: minimal mux subsystem and gpio-based mux controller
dt-bindings: simplified bindings for single-user gpio mux
mux: support simplified bindings for single-user gpio mux
iio: inkern: api for manipulating ext_info of iio channels
dt-bindings: iio: iio-mux: document iio-mux bindings
iio: multiplexer: new iio category and iio-mux driver
dt-bindings: i2c: i2c-mux-simple: document i2c-mux-simple bindings
i2c: i2c-mux-simple: new driver
dt-bindings: mux-adg792a: document devicetree bindings for ADG792A/G
mux
mux: adg792a: add mux controller driver for ADG792A/G
.../devicetree/bindings/i2c/i2c-mux-simple.txt | 81 ++++
.../bindings/iio/multiplexer/io-channel-mux.txt | 39 ++
.../devicetree/bindings/mux/mux-adg792a.txt | 79 ++++
.../devicetree/bindings/mux/mux-controller.txt | 153 +++++++
Documentation/devicetree/bindings/mux/mux-gpio.txt | 68 +++
Documentation/driver-model/devres.txt | 10 +-
MAINTAINERS | 14 +
drivers/Kconfig | 2 +
drivers/Makefile | 1 +
drivers/i2c/muxes/Kconfig | 13 +
drivers/i2c/muxes/Makefile | 1 +
drivers/i2c/muxes/i2c-mux-simple.c | 182 ++++++++
drivers/iio/Kconfig | 1 +
drivers/iio/Makefile | 1 +
drivers/iio/inkern.c | 60 +++
drivers/iio/multiplexer/Kconfig | 18 +
drivers/iio/multiplexer/Makefile | 6 +
drivers/iio/multiplexer/iio-mux.c | 456 ++++++++++++++++++++
drivers/mux/Kconfig | 45 ++
drivers/mux/Makefile | 7 +
drivers/mux/mux-adg792a.c | 169 ++++++++
drivers/mux/mux-core.c | 475 +++++++++++++++++++++
drivers/mux/mux-gpio.c | 70 +++
include/linux/iio/consumer.h | 37 ++
include/linux/mux.h | 251 +++++++++++
25 files changed, 2238 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-mux-simple.txt
create mode 100644 Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.txt
create mode 100644 Documentation/devicetree/bindings/mux/mux-adg792a.txt
create mode 100644 Documentation/devicetree/bindings/mux/mux-controller.txt
create mode 100644 Documentation/devicetree/bindings/mux/mux-gpio.txt
create mode 100644 drivers/i2c/muxes/i2c-mux-simple.c
create mode 100644 drivers/iio/multiplexer/Kconfig
create mode 100644 drivers/iio/multiplexer/Makefile
create mode 100644 drivers/iio/multiplexer/iio-mux.c
create mode 100644 drivers/mux/Kconfig
create mode 100644 drivers/mux/Makefile
create mode 100644 drivers/mux/mux-adg792a.c
create mode 100644 drivers/mux/mux-core.c
create mode 100644 drivers/mux/mux-gpio.c
create mode 100644 include/linux/mux.h
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH V5 4/8] mfd: da9061: MFD core support
From: Steve Twiss @ 2017-01-04 12:07 UTC (permalink / raw)
To: Lee Jones
Cc: LINUX-KERNEL, DEVICETREE, Dmitry Torokhov, Eduardo Valentin,
Guenter Roeck, LINUX-INPUT, LINUX-PM, LINUX-WATCHDOG,
Liam Girdwood, Mark Brown, Mark Rutland, Rob Herring,
Support Opensource, Wim Van Sebroeck, Zhang Rui
In-Reply-To: <20170104101221.GT27589@dell>
Hi Lee,
On 04 January 2017 10:12, Lee Jones wrote:
> Subject: Re: [PATCH V5 4/8] mfd: da9061: MFD core support
> On Thu, 15 Dec 2016, Steve Twiss wrote:
> > From: Steve Twiss <stwiss.opensource@diasemi.com>
[...]
> > +static const struct of_device_id da9062_dt_ids[] = {
> > + { .compatible = "dlg,da9061", .data = (void *)COMPAT_TYPE_DA9061,
> },
> > + { .compatible = "dlg,da9062", .data = (void *)COMPAT_TYPE_DA9062,
> },
>
> It looks like this device can dynamically obtain this information from
> the device. Please use that method instead.
As I mentioned in an earlier post,
https://lkml.org/lkml/2016/11/7/418
The 61/62 device type has been defined by the device tree in this case, and
that definition is used to set the register map. With the regmap defined,
access to the registers is then possible.
It is not possible to detect the device type automatically in this case because
it suggests a predefined regmap.
This is the reason I define the chip type (DA9061 or DA9062) in the device
tree and then assign the correct regmap first before accessing any registers.
[...]
> > + if (i2c->dev.of_node) {
> > + match = of_match_node(da9062_dt_ids, i2c->dev.of_node);
> > + if (!match)
> > + return -EINVAL;
> > +
> > + chip->chip_type = (int)match->data;
> > + } else
> > + chip->chip_type = id->driver_data;
>
> Please obtain this information from DA9062AA_VARIANT_ID.
The variant ID does contain the information about whether it is a 61 or 62, but
in order to read the register the regmap definition needs to be defined
first.
[...]
> > static const struct i2c_device_id da9062_i2c_id[] = {
> > - { "da9062", 0 },
> > + { "da9061", COMPAT_TYPE_DA9061 },
> > + { "da9062", COMPAT_TYPE_DA9062 },
>
> This too.
Regards,
Steve
^ permalink raw reply
* [PATCH] mailbox: sti: Fix mbox-names copy and paste error
From: Lee Jones @ 2017-01-04 12:05 UTC (permalink / raw)
To: patrice.chotard, jassisinghbrar
Cc: linux-arm-kernel, linux-kernel, kernel, devicetree, Lee Jones
Due to an over-sight, mbox-names has become mbox-name in some instances.
Let's put it right.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
Documentation/devicetree/bindings/mailbox/sti-mailbox.txt | 4 ++--
arch/arm/boot/dts/stih407-family.dtsi | 8 ++++----
drivers/mailbox/mailbox-sti.c | 2 +-
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/mailbox/sti-mailbox.txt b/Documentation/devicetree/bindings/mailbox/sti-mailbox.txt
index 351f612..648d176 100644
--- a/Documentation/devicetree/bindings/mailbox/sti-mailbox.txt
+++ b/Documentation/devicetree/bindings/mailbox/sti-mailbox.txt
@@ -9,7 +9,7 @@ Controller
Required properties:
- compatible : Should be "st,stih407-mailbox"
- reg : Offset and length of the device's register set
-- mbox-name : Name of the mailbox
+- mbox-names : Name of the mailbox
- #mbox-cells: : Must be 2
<&phandle instance channel direction>
phandle : Label name of controller
@@ -26,7 +26,7 @@ mailbox0: mailbox@0 {
reg = <0x08f00000 0x1000>;
interrupts = <GIC_SPI 1 IRQ_TYPE_NONE>;
#mbox-cells = <2>;
- mbox-name = "a9";
+ mbox-names = "a9";
};
Client
diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
index c8b2944..00c67d4 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -787,7 +787,7 @@
reg = <0x8f00000 0x1000>;
interrupts = <GIC_SPI 1 IRQ_TYPE_NONE>;
#mbox-cells = <2>;
- mbox-name = "a9";
+ mbox-names = "a9";
status = "okay";
};
@@ -795,7 +795,7 @@
compatible = "st,stih407-mailbox";
reg = <0x8f01000 0x1000>;
#mbox-cells = <2>;
- mbox-name = "st231_gp_1";
+ mbox-names = "st231_gp_1";
status = "okay";
};
@@ -803,7 +803,7 @@
compatible = "st,stih407-mailbox";
reg = <0x8f02000 0x1000>;
#mbox-cells = <2>;
- mbox-name = "st231_gp_0";
+ mbox-names = "st231_gp_0";
status = "okay";
};
@@ -811,7 +811,7 @@
compatible = "st,stih407-mailbox";
reg = <0x8f03000 0x1000>;
#mbox-cells = <2>;
- mbox-name = "st231_audio_video";
+ mbox-names = "st231_audio_video";
status = "okay";
};
diff --git a/drivers/mailbox/mailbox-sti.c b/drivers/mailbox/mailbox-sti.c
index 41bcd33..e532a98 100644
--- a/drivers/mailbox/mailbox-sti.c
+++ b/drivers/mailbox/mailbox-sti.c
@@ -434,7 +434,7 @@ static int sti_mbox_probe(struct platform_device *pdev)
if (IS_ERR(mdev->base))
return PTR_ERR(mdev->base);
- ret = of_property_read_string(np, "mbox-name", &mdev->name);
+ ret = of_property_read_string(np, "mbox-names", &mdev->name);
if (ret)
mdev->name = np->full_name;
--
2.10.2
^ permalink raw reply related
* Re: [PATCH 18/22] mfd: axp20x: add MFD cells for AXP20X and AXP22X battery driver
From: Lee Jones @ 2017-01-04 11:57 UTC (permalink / raw)
To: Quentin Schulz
Cc: jic23-DgEjT+Ai2ygdnm+yROfE0A, knaack.h-Mmb7MZpHnFY,
lars-Qo5EllUWu/uELgA04lAiVw, pmeerw-jW+XmwGofnusTnJN9+BGXg,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
wens-jdAy2FN1RRM, sre-DgEjT+Ai2ygdnm+yROfE0A,
linux-I+IVW8TIWO2tmTQ+vhA3Yw,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
icenowy-ymACFijhrKM, bonbons-ud5FBsm0p/xEiooADzr8i9i2O/JbrIOy
In-Reply-To: <20170102163723.7939-19-quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On Mon, 02 Jan 2017, Quentin Schulz wrote:
> The X-Powers AXP20X and AXP22X PMICs can have a battery as power supply.
>
> This patch adds the AXP20X/AXP22X battery driver to the MFD cells of the
> AXP209, AXP221 and AXP223 MFD.
>
> Signed-off-by: Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> ---
> drivers/mfd/axp20x.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
For my own reference:
Acked-for-MFD-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> index 7f0f05f..8730fc2 100644
> --- a/drivers/mfd/axp20x.c
> +++ b/drivers/mfd/axp20x.c
> @@ -587,6 +587,9 @@ static struct mfd_cell axp20x_cells[] = {
> .name = "axp20x-adc",
> .of_compatible = "x-powers,axp209-adc",
> }, {
> + .name = "axp20x-battery-power-supply",
> + .of_compatible = "x-powers,axp209-battery-power-supply",
> + }, {
> .name = "axp20x-ac-power-supply",
> .of_compatible = "x-powers,axp202-ac-power-supply",
> .num_resources = ARRAY_SIZE(axp20x_ac_power_supply_resources),
> @@ -615,6 +618,9 @@ static struct mfd_cell axp221_cells[] = {
> .num_resources = ARRAY_SIZE(axp20x_ac_power_supply_resources),
> .resources = axp20x_ac_power_supply_resources,
> }, {
> + .name = "axp20x-battery-power-supply",
> + .of_compatible = "x-powers,axp221-battery-power-supply",
> + }, {
> .name = "axp20x-usb-power-supply",
> .of_compatible = "x-powers,axp221-usb-power-supply",
> .num_resources = ARRAY_SIZE(axp22x_usb_power_supply_resources),
> @@ -631,6 +637,9 @@ static struct mfd_cell axp223_cells[] = {
> .name = "axp20x-adc",
> .of_compatible = "x-powers,axp221-adc"
> }, {
> + .name = "axp20x-battery-power-supply",
> + .of_compatible = "x-powers,axp221-battery-power-supply",
> + }, {
> .name = "axp20x-regulator",
> }, {
> .name = "axp20x-ac-power-supply",
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH 16/22] mfd: axp20x: add V_OFF to writeable regs for AXP20X and AXP22X
From: Lee Jones @ 2017-01-04 11:57 UTC (permalink / raw)
To: Quentin Schulz
Cc: jic23, knaack.h, lars, pmeerw, robh+dt, mark.rutland, wens, sre,
linux, maxime.ripard, linux-iio, devicetree, linux-kernel,
linux-pm, linux-arm-kernel, thomas.petazzoni, icenowy, bonbons
In-Reply-To: <20170102163723.7939-17-quentin.schulz@free-electrons.com>
On Mon, 02 Jan 2017, Quentin Schulz wrote:
> The V_OFF register has its first 3 read-write bits for the minimal
> voltage (Voff) of the battery before the system is automatically shut
> down due to the power being too low.
>
> This adds V_OFF register to the writeable registers of AXP20X and AXP22X
> PMICs.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
> ---
> drivers/mfd/axp20x.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
For my own reference:
Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> index 19bdba3..7f0f05f 100644
> --- a/drivers/mfd/axp20x.c
> +++ b/drivers/mfd/axp20x.c
> @@ -65,7 +65,7 @@ static const struct regmap_access_table axp152_volatile_table = {
>
> static const struct regmap_range axp20x_writeable_ranges[] = {
> regmap_reg_range(AXP20X_DATACACHE(0), AXP20X_IRQ5_STATE),
> - regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_VBUS_IPSOUT_MGMT),
> + regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_V_OFF),
> regmap_reg_range(AXP20X_CHRG_CTRL1, AXP20X_CHRG_CTRL1),
> regmap_reg_range(AXP20X_DCDC_MODE, AXP20X_FG_RES),
> regmap_reg_range(AXP20X_RDC_H, AXP20X_OCV(AXP20X_OCV_MAX)),
> @@ -94,7 +94,7 @@ static const struct regmap_access_table axp20x_volatile_table = {
> /* AXP22x ranges are shared with the AXP809, as they cover the same range */
> static const struct regmap_range axp22x_writeable_ranges[] = {
> regmap_reg_range(AXP20X_DATACACHE(0), AXP20X_IRQ5_STATE),
> - regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_VBUS_IPSOUT_MGMT),
> + regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_V_OFF),
> regmap_reg_range(AXP20X_CHRG_CTRL1, AXP20X_CHRG_CTRL1),
> regmap_reg_range(AXP20X_DCDC_MODE, AXP22X_BATLOW_THRES1),
> };
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH 15/22] mfd: axp20x: add CHRG_CTRL1 to writeable regs for AXP20X/AXP22X
From: Lee Jones @ 2017-01-04 11:57 UTC (permalink / raw)
To: Quentin Schulz
Cc: jic23, knaack.h, lars, pmeerw, robh+dt, mark.rutland, wens, sre,
linux, maxime.ripard, linux-iio, devicetree, linux-kernel,
linux-pm, linux-arm-kernel, thomas.petazzoni, icenowy, bonbons
In-Reply-To: <20170102163723.7939-16-quentin.schulz@free-electrons.com>
On Mon, 02 Jan 2017, Quentin Schulz wrote:
> The CHR_CTRL1 register is made of 7 read-write bits with one being used
> to set the target voltage for battery charging.
>
> This adds the CHRG_CTRL1 register to the list of writeable registers for
> AXP20X and AXP22X PMICs.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
> ---
> drivers/mfd/axp20x.c | 2 ++
> 1 file changed, 2 insertions(+)
For my own reference:
Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> index 65c57d0..19bdba3 100644
> --- a/drivers/mfd/axp20x.c
> +++ b/drivers/mfd/axp20x.c
> @@ -66,6 +66,7 @@ static const struct regmap_access_table axp152_volatile_table = {
> static const struct regmap_range axp20x_writeable_ranges[] = {
> regmap_reg_range(AXP20X_DATACACHE(0), AXP20X_IRQ5_STATE),
> regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_VBUS_IPSOUT_MGMT),
> + regmap_reg_range(AXP20X_CHRG_CTRL1, AXP20X_CHRG_CTRL1),
> regmap_reg_range(AXP20X_DCDC_MODE, AXP20X_FG_RES),
> regmap_reg_range(AXP20X_RDC_H, AXP20X_OCV(AXP20X_OCV_MAX)),
> };
> @@ -94,6 +95,7 @@ static const struct regmap_access_table axp20x_volatile_table = {
> static const struct regmap_range axp22x_writeable_ranges[] = {
> regmap_reg_range(AXP20X_DATACACHE(0), AXP20X_IRQ5_STATE),
> regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_VBUS_IPSOUT_MGMT),
> + regmap_reg_range(AXP20X_CHRG_CTRL1, AXP20X_CHRG_CTRL1),
> regmap_reg_range(AXP20X_DCDC_MODE, AXP22X_BATLOW_THRES1),
> };
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH 09/22] mfd: axp20x: add AC power supply cells for AXP22X PMICs
From: Lee Jones @ 2017-01-04 11:57 UTC (permalink / raw)
To: Quentin Schulz
Cc: jic23, knaack.h, lars, pmeerw, robh+dt, mark.rutland, wens, sre,
linux, maxime.ripard, linux-iio, devicetree, linux-kernel,
linux-pm, linux-arm-kernel, thomas.petazzoni, icenowy, bonbons
In-Reply-To: <20170102163723.7939-10-quentin.schulz@free-electrons.com>
On Mon, 02 Jan 2017, Quentin Schulz wrote:
> The X-Powers AXP20X and AXP22X PMICs expose the status of AC power
> supply.
>
> This adds the AC power supply driver to the MFD cells of the AXP22X
> PMICs.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
> ---
> drivers/mfd/axp20x.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
For my own reference:
Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> index 31a84d81..65c57d0 100644
> --- a/drivers/mfd/axp20x.c
> +++ b/drivers/mfd/axp20x.c
> @@ -608,6 +608,11 @@ static struct mfd_cell axp221_cells[] = {
> .name = "axp20x-adc",
> .of_compatible = "x-powers,axp221-adc"
> }, {
> + .name = "axp20x-ac-power-supply",
> + .of_compatible = "x-powers,axp221-ac-power-supply",
> + .num_resources = ARRAY_SIZE(axp20x_ac_power_supply_resources),
> + .resources = axp20x_ac_power_supply_resources,
> + }, {
> .name = "axp20x-usb-power-supply",
> .of_compatible = "x-powers,axp221-usb-power-supply",
> .num_resources = ARRAY_SIZE(axp22x_usb_power_supply_resources),
> @@ -626,6 +631,11 @@ static struct mfd_cell axp223_cells[] = {
> }, {
> .name = "axp20x-regulator",
> }, {
> + .name = "axp20x-ac-power-supply",
> + .of_compatible = "x-powers,axp221-ac-power-supply",
> + .num_resources = ARRAY_SIZE(axp20x_ac_power_supply_resources),
> + .resources = axp20x_ac_power_supply_resources,
> + }, {
> .name = "axp20x-usb-power-supply",
> .of_compatible = "x-powers,axp223-usb-power-supply",
> .num_resources = ARRAY_SIZE(axp22x_usb_power_supply_resources),
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH 04/22] mfd: axp20x: add ADC cells for AXP20X and AXP22X PMICs
From: Lee Jones @ 2017-01-04 11:56 UTC (permalink / raw)
To: Quentin Schulz
Cc: jic23-DgEjT+Ai2ygdnm+yROfE0A, knaack.h-Mmb7MZpHnFY,
lars-Qo5EllUWu/uELgA04lAiVw, pmeerw-jW+XmwGofnusTnJN9+BGXg,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
wens-jdAy2FN1RRM, sre-DgEjT+Ai2ygdnm+yROfE0A,
linux-I+IVW8TIWO2tmTQ+vhA3Yw,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
icenowy-ymACFijhrKM, bonbons-ud5FBsm0p/xEiooADzr8i9i2O/JbrIOy
In-Reply-To: <20170104115602.GB24058@dell>
On Wed, 04 Jan 2017, Lee Jones wrote:
> On Mon, 02 Jan 2017, Quentin Schulz wrote:
>
> > This adds the AXP20X/AXP22x ADCs driver to the mfd cells of the AXP209,
> > AXP221 and AXP223 MFD.
> >
> > Signed-off-by: Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> > ---
> > drivers/mfd/axp20x.c | 9 +++++++++
> > 1 file changed, 9 insertions(+)
>
> Applied, thanks.
Whoops, wrong key combo! Should have been:
For my own reference:
Acked-for-MFD-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> > diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> > index a33db5e..31a84d81 100644
> > --- a/drivers/mfd/axp20x.c
> > +++ b/drivers/mfd/axp20x.c
> > @@ -582,6 +582,9 @@ static struct mfd_cell axp20x_cells[] = {
> > }, {
> > .name = "axp20x-regulator",
> > }, {
> > + .name = "axp20x-adc",
> > + .of_compatible = "x-powers,axp209-adc",
> > + }, {
> > .name = "axp20x-ac-power-supply",
> > .of_compatible = "x-powers,axp202-ac-power-supply",
> > .num_resources = ARRAY_SIZE(axp20x_ac_power_supply_resources),
> > @@ -602,6 +605,9 @@ static struct mfd_cell axp221_cells[] = {
> > }, {
> > .name = "axp20x-regulator",
> > }, {
> > + .name = "axp20x-adc",
> > + .of_compatible = "x-powers,axp221-adc"
> > + }, {
> > .name = "axp20x-usb-power-supply",
> > .of_compatible = "x-powers,axp221-usb-power-supply",
> > .num_resources = ARRAY_SIZE(axp22x_usb_power_supply_resources),
> > @@ -615,6 +621,9 @@ static struct mfd_cell axp223_cells[] = {
> > .num_resources = ARRAY_SIZE(axp22x_pek_resources),
> > .resources = axp22x_pek_resources,
> > }, {
> > + .name = "axp20x-adc",
> > + .of_compatible = "x-powers,axp221-adc"
> > + }, {
> > .name = "axp20x-regulator",
> > }, {
> > .name = "axp20x-usb-power-supply",
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH 04/22] mfd: axp20x: add ADC cells for AXP20X and AXP22X PMICs
From: Lee Jones @ 2017-01-04 11:56 UTC (permalink / raw)
To: Quentin Schulz
Cc: jic23, knaack.h, lars, pmeerw, robh+dt, mark.rutland, wens, sre,
linux, maxime.ripard, linux-iio, devicetree, linux-kernel,
linux-pm, linux-arm-kernel, thomas.petazzoni, icenowy, bonbons
In-Reply-To: <20170102163723.7939-5-quentin.schulz@free-electrons.com>
On Mon, 02 Jan 2017, Quentin Schulz wrote:
> This adds the AXP20X/AXP22x ADCs driver to the mfd cells of the AXP209,
> AXP221 and AXP223 MFD.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
> ---
> drivers/mfd/axp20x.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
Applied, thanks.
> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> index a33db5e..31a84d81 100644
> --- a/drivers/mfd/axp20x.c
> +++ b/drivers/mfd/axp20x.c
> @@ -582,6 +582,9 @@ static struct mfd_cell axp20x_cells[] = {
> }, {
> .name = "axp20x-regulator",
> }, {
> + .name = "axp20x-adc",
> + .of_compatible = "x-powers,axp209-adc",
> + }, {
> .name = "axp20x-ac-power-supply",
> .of_compatible = "x-powers,axp202-ac-power-supply",
> .num_resources = ARRAY_SIZE(axp20x_ac_power_supply_resources),
> @@ -602,6 +605,9 @@ static struct mfd_cell axp221_cells[] = {
> }, {
> .name = "axp20x-regulator",
> }, {
> + .name = "axp20x-adc",
> + .of_compatible = "x-powers,axp221-adc"
> + }, {
> .name = "axp20x-usb-power-supply",
> .of_compatible = "x-powers,axp221-usb-power-supply",
> .num_resources = ARRAY_SIZE(axp22x_usb_power_supply_resources),
> @@ -615,6 +621,9 @@ static struct mfd_cell axp223_cells[] = {
> .num_resources = ARRAY_SIZE(axp22x_pek_resources),
> .resources = axp22x_pek_resources,
> }, {
> + .name = "axp20x-adc",
> + .of_compatible = "x-powers,axp221-adc"
> + }, {
> .name = "axp20x-regulator",
> }, {
> .name = "axp20x-usb-power-supply",
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH 02/22] mfd: axp20x: add ADC data regs to volatile regs for AXP22X
From: Lee Jones @ 2017-01-04 11:55 UTC (permalink / raw)
To: Quentin Schulz
Cc: jic23-DgEjT+Ai2ygdnm+yROfE0A, knaack.h-Mmb7MZpHnFY,
lars-Qo5EllUWu/uELgA04lAiVw, pmeerw-jW+XmwGofnusTnJN9+BGXg,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
wens-jdAy2FN1RRM, sre-DgEjT+Ai2ygdnm+yROfE0A,
linux-I+IVW8TIWO2tmTQ+vhA3Yw,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
icenowy-ymACFijhrKM, bonbons-ud5FBsm0p/xEiooADzr8i9i2O/JbrIOy
In-Reply-To: <20170102163723.7939-3-quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On Mon, 02 Jan 2017, Quentin Schulz wrote:
> The AXP22X PMICs have multiple ADCs, each one exposing data from the
> different power supplies connected to the PMIC.
>
> This adds the different ADC data registers to the volatile registers of
> the AXP22X PMIC.
>
> Signed-off-by: Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
For my own reference:
Acked-for-MFD-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> drivers/mfd/axp20x.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> index 619a83e..a33db5e 100644
> --- a/drivers/mfd/axp20x.c
> +++ b/drivers/mfd/axp20x.c
> @@ -100,6 +100,7 @@ static const struct regmap_range axp22x_writeable_ranges[] = {
> static const struct regmap_range axp22x_volatile_ranges[] = {
> regmap_reg_range(AXP20X_PWR_INPUT_STATUS, AXP20X_PWR_OP_MODE),
> regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_VBUS_IPSOUT_MGMT),
> + regmap_reg_range(AXP22X_TEMP_ADC_H, AXP20X_BATT_DISCHRG_I_L),
> regmap_reg_range(AXP20X_IRQ1_EN, AXP20X_IRQ5_STATE),
> regmap_reg_range(AXP22X_GPIO_STATE, AXP22X_GPIO_STATE),
> regmap_reg_range(AXP22X_PMIC_ADC_H, AXP20X_IPSOUT_V_HIGH_L),
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH v4 1/5] devicetree: mfd: Add binding for the TI LM3533
From: Lee Jones @ 2017-01-04 11:54 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Rob Herring, Mark Rutland, Jonathan Cameron, Hartmut Knaack,
Lars-Peter Clausen, Peter Meerwald-Stadler, Richard Purdie,
Jacek Anaszewski, Pavel Machek, Jingoo Han, devicetree,
linux-kernel, linux-iio, linux-leds, Bjorn Andersson
In-Reply-To: <20161226181153.11271-1-bjorn.andersson@linaro.org>
On Mon, 26 Dec 2016, Bjorn Andersson wrote:
> From: Bjorn Andersson <bjorn.andersson@sonymobile.com>
>
> Add the binding for the Texas Instruments LM3533 lighting power
> solution.
>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
For my own reference:
Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> ---
>
> I had Acks from Jonathan and Rob on v3, but dropped these due to the added
> compatible properties.
>
> Changes since v3:
> - Added compatible to sub-nodes, per Lee's requested to treat them as separate
> pieces.
>
> Documentation/devicetree/bindings/mfd/lm3533.txt | 205 +++++++++++++++++++++++
> 1 file changed, 205 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/lm3533.txt
>
> diff --git a/Documentation/devicetree/bindings/mfd/lm3533.txt b/Documentation/devicetree/bindings/mfd/lm3533.txt
> new file mode 100644
> index 000000000000..909281096ba2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/lm3533.txt
> @@ -0,0 +1,205 @@
> +Texas Instruments LM3533 binding
> +
> +This binding describes the Texas Instruments LM3533, a lighting power solution
> +for smartphone handsets. The common properties are described directly in the
> +node, while each individual component are described in an optional subnode.
> +
> +- compatible:
> + Usage: required
> + Value type: <stringlist>
> + Definition: must be:
> + "ti,lm3533"
> +
> +- reg:
> + Usage: required
> + Value type: <u32>
> + Definition: i2c address of the LM3533 chip
> +
> +- als-supply:
> + Usage: optional
> + Value type: <prop-encoded-array>
> + Definition: reference to regulator powering the V_als input; as
> + specified in "../regulator/regulator.txt"
> +
> +- hwen-gpios:
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: reference to gpio pin connected to the HWEN input; as
> + specified in "../gpio/gpio.txt"
> +
> +- ti,boost-freq-hz:
> + Usage: required
> + Value type: <u32>
> + Definition: switch-frequency of the boost converter, must be either:
> + 500000 or 1000000
> +
> +- ti,boost-ovp-mv:
> + Usage: required
> + Value type: <u32>
> + Definition: over-voltage protection limit, in mV. Must be one of:
> + 16000, 24000, 32000 or 40000
> +
> +- #address-cells:
> + Usage: required
> + Value type: <u32>
> + Definition: must be 1
> +
> +- #size-cells:
> + Usage: required
> + Value type: <u32>
> + Definition: must be 0
> +
> += ALS SUBNODE
> +The ambient light sensor subnode carrying the light sensor related properties.
> +
> +- compatible:
> + Usage: required
> + Value type: <stringlist>
> + Definition: must be:
> + "ti,lm3533-als"
> +
> +- ti,als-resistance-ohm:
> + Usage: required (unless ti,pwm-mode is specified)
> + Value type: <u32>
> + Definition: specifies the resistor value (R_als), in Ohm. Valid values
> + ranges from 200000 to 1574 Ohm.
> +
> +- ti,pwm-mode:
> + Usage: optional
> + Value type: <empty>
> + Definition: specifies, if present, that the als should operate in PWM
> + mode - rather than analog mode
> +
> += BACKLIGHT NODES
> +Backlight subnodes carrying the backlight related properties.
> +
> +- compatible:
> + Usage: required
> + Value type: <stringlist>
> + Definition: must be:
> + "ti,lm3533-backlight"
> +
> +- reg:
> + Usage: required
> + Value type: <u32>
> + Definition: specifies which of the two backlights this node corresponds
> + to
> +
> +- default-brightness:
> + Usage: optional
> + Value type: <32>
> + Definition: specifies the default brightness for the backlight, in
> + units of brightness [0-255]
> +
> +- label:
> + Usage: required
> + Value type: <string>
> + Definition: specifies a name of this backlight
> +
> +- led-max-microamp:
> + Usage: required
> + Value type: <u32>
> + Definition: specifies the max current for this backlight, in uA, as
> + described in "../leds/common.txt"
> +
> +- ti,pwm-zones:
> + Usage: optional
> + Value type: <u32 list>
> + Definition: lists the ALS zones to be PWM controlled for this backlight,
> + the values in the list are in the range [0 - 4]
> +
> += LED NODES
> +LED subnodes carrying the LED related properties.
> +
> +- compatible:
> + Usage: required
> + Value type: <stringlist>
> + Definition: must be:
> + "ti,lm3533-led"
> +
> +- reg:
> + Usage: required
> + Value type: <u32>
> + Definition: specifies which of the four LEDs this node corresponds to
> +
> +- linux,default-trigger:
> + Usage: optional
> + Value type: <string>
> + Definition: specifies the default trigger for the LED, as described in
> + "../leds/common.txt"
> +
> +- label:
> + Usage: required
> + Value type: <string>
> + Definition: specifies a name of this LED, as described in
> + "../leds/common.txt"
> +
> +- led-max-microamp:
> + Usage: required
> + Value type: <u32>
> + Definition: specifies the max current for this LED, in uA, as described
> + in "../leds/common.txt"
> +
> +- ti,pwm-zones:
> + Usage: optional
> + Value type: <u32 list>
> + Definition: lists the ALS zones to be PWM controlled for this LED, the
> + values in the list are in the range [0 - 4]
> +
> += EXAMPLE
> +
> +i2c@12460000 {
> + compatible = "qcom,i2c-qup-v1.1.1";
> + ...
> +
> + lm3533@36 {
> + compatible = "ti,lm3533";
> + reg = <0x36>;
> +
> + als-supply = <&pm8921_l11>;
> + hwen-gpios = <&pm8921_gpio 26 GPIO_ACTIVE_HIGH>;
> +
> + ti,boost-freq-hz = <500000>;
> + ti,boost-ovp-mv = <24000>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + als {
> + compatible = "ti,lm3533-als";
> + ti,als-resistance-ohm = <200000>;
> + };
> +
> + backlight@0 {
> + compatible = "ti,lm3533-backlight";
> + reg = <0>;
> + label = "backlight";
> +
> + led-max-microamp = <20200>;
> + };
> +
> + led@0 {
> + compatible = "ti,lm3533-led";
> + reg = <0>;
> + label = "red";
> +
> + led-max-microamp = <5000>;
> + };
> +
> + led@1 {
> + compatible = "ti,lm3533-led";
> + reg = <1>;
> + label = "green";
> +
> + led-max-microamp = <5000>;
> + };
> +
> + led@2 {
> + compatible = "ti,lm3533-led";
> + reg = <2>;
> + label = "blue";
> +
> + led-max-microamp = <5000>;
> + };
> + };
> +
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH v4 2/5] mfd: lm3533: Support initialization from Device Tree
From: Lee Jones @ 2017-01-04 11:54 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Rob Herring, Mark Rutland, Jonathan Cameron, Hartmut Knaack,
Lars-Peter Clausen, Peter Meerwald-Stadler, Richard Purdie,
Jacek Anaszewski, Pavel Machek, Jingoo Han,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-leds-u79uwXL29TY76Z2rM5mHXA, Bjorn Andersson
In-Reply-To: <20161226181153.11271-2-bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Mon, 26 Dec 2016, Bjorn Andersson wrote:
> From: Bjorn Andersson <bjorn.andersson-/MT0OVThwyLZJqsBc5GL+g@public.gmane.org>
>
> Implement support for initialization of the lm3533 driver core and
> probing child devices from Device Tree.
>
> Signed-off-by: Bjorn Andersson <bjorn.andersson-/MT0OVThwyLZJqsBc5GL+g@public.gmane.org>
> Signed-off-by: Bjorn Andersson <bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
>
> Changes since v3:
> - Moved parsing of child of nodes into each child driver
> - Use of_platform_populate() to instanciate child devices
>
> drivers/mfd/lm3533-core.c | 76 +++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 76 insertions(+)
>
> diff --git a/drivers/mfd/lm3533-core.c b/drivers/mfd/lm3533-core.c
> index 5abcbb2e8849..f147677f05ff 100644
> --- a/drivers/mfd/lm3533-core.c
> +++ b/drivers/mfd/lm3533-core.c
> @@ -18,6 +18,8 @@
> #include <linux/gpio.h>
> #include <linux/i2c.h>
> #include <linux/mfd/core.h>
> +#include <linux/of_gpio.h>
> +#include <linux/of_platform.h>
> #include <linux/regmap.h>
> #include <linux/seq_file.h>
> #include <linux/slab.h>
> @@ -512,6 +514,11 @@ static int lm3533_device_init(struct lm3533 *lm3533)
> lm3533_device_bl_init(lm3533);
> lm3533_device_led_init(lm3533);
>
> + if (lm3533->dev->of_node) {
> + of_platform_populate(lm3533->dev->of_node, NULL, NULL,
> + lm3533->dev);
> + }
I think it's save to call of_platform_populate(), even if !of_node.
It will just fail and return an error code, which you are ignoring
anyway.
> ret = sysfs_create_group(&lm3533->dev->kobj, &lm3533_attribute_group);
> if (ret < 0) {
> dev_err(lm3533->dev, "failed to create sysfs attributes\n");
> @@ -588,10 +595,73 @@ static const struct regmap_config regmap_config = {
> .precious_reg = lm3533_precious_register,
> };
>
> +static int lm3533_of_parse_enum(struct device *dev, const char *propname,
> + const unsigned int *match, size_t num_matches)
> +{
> + size_t i;
> + int ret;
> + u32 val;
> +
> + ret = of_property_read_u32(dev->of_node, propname, &val);
> + if (ret < 0) {
> + dev_err(dev, "failed to parse %s\n", propname);
> + return ret;
> + }
> +
> + for (i = 0; i < num_matches; i++) {
> + if (val == match[i])
> + return i;
> + }
> +
> + dev_err(dev, "unsupported value of %s\n", propname);
> + return -EINVAL;
> +}
> +
> +static int lm3533_pdata_from_of_node(struct device *dev)
> +{
> + struct lm3533_platform_data *pdata;
> + int ret;
> + const unsigned int freqs[] = {
> + [LM3533_BOOST_FREQ_500KHZ] = 500000,
> + [LM3533_BOOST_FREQ_1000KHZ] = 1000000,
> + };
> + const unsigned int ovps[] = {
> + [LM3533_BOOST_OVP_16V] = 16000,
> + [LM3533_BOOST_OVP_24V] = 24000,
> + [LM3533_BOOST_OVP_32V] = 32000,
> + [LM3533_BOOST_OVP_40V] = 40000,
> + };
> +
> + pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
> + if (!pdata)
> + return -ENOMEM;
> +
> + pdata->gpio_hwen = of_get_named_gpio(dev->of_node, "hwen-gpios", 0);
> + if (pdata->gpio_hwen < 0)
> + return pdata->gpio_hwen;
> +
> + ret = lm3533_of_parse_enum(dev, "ti,boost-freq-hz",
> + freqs, ARRAY_SIZE(freqs));
> + if (ret < 0)
> + return ret;
> + pdata->boost_freq = ret;
> +
> + ret = lm3533_of_parse_enum(dev, "ti,boost-ovp-mv",
> + ovps, ARRAY_SIZE(ovps));
> + if (ret < 0)
> + return ret;
> + pdata->boost_ovp = ret;
> +
> + dev->platform_data = pdata;
> +
> + return 0;
> +}
> +
> static int lm3533_i2c_probe(struct i2c_client *i2c,
> const struct i2c_device_id *id)
> {
> struct lm3533 *lm3533;
> + int ret;
>
> dev_dbg(&i2c->dev, "%s\n", __func__);
>
> @@ -608,6 +678,12 @@ static int lm3533_i2c_probe(struct i2c_client *i2c,
> lm3533->dev = &i2c->dev;
> lm3533->irq = i2c->irq;
>
> + if (i2c->dev.of_node) {
I'd prefer this check to be placed in lm3533_pdata_from_of_node().
Just return silently if !dev->of_node.
> + ret = lm3533_pdata_from_of_node(lm3533->dev);
> + if (ret < 0)
> + return ret;
> + }
> +
> return lm3533_device_init(lm3533);
> }
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v5 3/5] backlight: lm3533: Support initialization from Device Tree
From: Bjorn Andersson @ 2017-01-04 11:50 UTC (permalink / raw)
To: Lee Jones, Jingoo Han
Cc: Rob Herring, Mark Rutland, Jonathan Cameron, Hartmut Knaack,
Lars-Peter Clausen, Peter Meerwald-Stadler, Richard Purdie,
Pavel Machek, devicetree, linux-kernel, linux-iio, linux-leds
In-Reply-To: <20170104115050.24770-1-bjorn.andersson@linaro.org>
From: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Implement support for initialization of the lm3533 backlight from Device
Tree.
Acked-by: Jingoo Han <jingoohan1@gmail.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
Note that this patch can be merged independently of the other patches in the
series, pending approval of the DT binding.
Changes since v4:
- Acks from Pavel and Jingoo
Changes since v3:
- Moved backlight DT parsing from mfd driver
- Gave driver its own compatible
drivers/video/backlight/lm3533_bl.c | 98 +++++++++++++++++++++++++++++++++++--
1 file changed, 95 insertions(+), 3 deletions(-)
diff --git a/drivers/video/backlight/lm3533_bl.c b/drivers/video/backlight/lm3533_bl.c
index 0e2337f367b6..2f132199e604 100644
--- a/drivers/video/backlight/lm3533_bl.c
+++ b/drivers/video/backlight/lm3533_bl.c
@@ -22,6 +22,7 @@
#define LM3533_HVCTRLBANK_COUNT 2
+#define LM3533_BL_DEFAULT_BRIGHTNESS 200
#define LM3533_BL_MAX_BRIGHTNESS 255
#define LM3533_REG_CTRLBANK_AB_BCONF 0x1a
@@ -269,6 +270,86 @@ static int lm3533_bl_setup(struct lm3533_bl *bl,
return lm3533_ctrlbank_set_pwm(&bl->cb, pdata->pwm);
}
+static int lm3533_of_parse_pwm_zones(struct device_node *node)
+{
+ const char *propname = "ti,pwm-zones";
+ u32 zones[5];
+ int count;
+ int ret;
+ int i;
+
+ count = of_property_count_u32_elems(node, propname);
+ if (count == -EINVAL)
+ return 0;
+ if (count <= 0)
+ return count;
+ if (count >= ARRAY_SIZE(zones))
+ return -EINVAL;
+
+ ret = of_property_read_u32_array(node, propname, zones, count);
+ if (ret < 0)
+ return ret;
+
+ /* Enable pwm input, and enable the selected zones */
+ ret = BIT(0);
+ for (i = 0; i < count; i++)
+ ret |= BIT(zones[i] + 1);
+
+ return ret;
+}
+
+static struct lm3533_bl_platform_data *lm3533_bl_of_parse(struct device *dev,
+ int *id)
+{
+ struct lm3533_bl_platform_data *bl_pdata;
+ struct device_node *node = dev->of_node;
+ int ret;
+ u32 reg;
+ u32 val;
+
+ bl_pdata = devm_kzalloc(dev, sizeof(*bl_pdata), GFP_KERNEL);
+ if (!bl_pdata)
+ return NULL;
+
+ ret = of_property_read_u32(node, "reg", ®);
+ if (ret < 0) {
+ dev_err(dev, "invalid reg property\n");
+ return NULL;
+ }
+ *id = reg;
+
+ ret = of_property_read_string(node, "label",
+ (const char **)&bl_pdata->name);
+ if (ret < 0) {
+ dev_err(dev, "unable to parse label\n");
+ return NULL;
+ }
+
+ ret = of_property_read_u32(node, "led-max-microamp", &val);
+ if (ret < 0) {
+ dev_err(dev, "unable to parse led-max-microamp\n");
+ return NULL;
+ }
+ bl_pdata->max_current = val;
+
+ val = LM3533_BL_DEFAULT_BRIGHTNESS;
+ ret = of_property_read_u32(node, "default-brightness", &val);
+ if (ret < 0 && ret != -EINVAL) {
+ dev_err(dev, "unable to parse default-brightness\n");
+ return NULL;
+ }
+ bl_pdata->default_brightness = val;
+
+ ret = lm3533_of_parse_pwm_zones(node);
+ if (ret < 0) {
+ dev_err(dev, "failed to parse ti,pwm-zones\n");
+ return NULL;
+ }
+ bl_pdata->pwm = ret;
+
+ return bl_pdata;
+}
+
static int lm3533_bl_probe(struct platform_device *pdev)
{
struct lm3533 *lm3533;
@@ -277,6 +358,7 @@ static int lm3533_bl_probe(struct platform_device *pdev)
struct backlight_device *bd;
struct backlight_properties props;
int ret;
+ int id;
dev_dbg(&pdev->dev, "%s\n", __func__);
@@ -284,14 +366,17 @@ static int lm3533_bl_probe(struct platform_device *pdev)
if (!lm3533)
return -EINVAL;
+ id = pdev->id;
pdata = dev_get_platdata(&pdev->dev);
+ if (!pdata)
+ pdata = lm3533_bl_of_parse(&pdev->dev, &id);
if (!pdata) {
dev_err(&pdev->dev, "no platform data\n");
return -EINVAL;
}
- if (pdev->id < 0 || pdev->id >= LM3533_HVCTRLBANK_COUNT) {
- dev_err(&pdev->dev, "illegal backlight id %d\n", pdev->id);
+ if (id < 0 || id >= LM3533_HVCTRLBANK_COUNT) {
+ dev_err(&pdev->dev, "illegal backlight id %d\n", id);
return -EINVAL;
}
@@ -300,7 +385,7 @@ static int lm3533_bl_probe(struct platform_device *pdev)
return -ENOMEM;
bl->lm3533 = lm3533;
- bl->id = pdev->id;
+ bl->id = id;
bl->cb.lm3533 = lm3533;
bl->cb.id = lm3533_bl_get_ctrlbank_id(bl);
@@ -394,10 +479,17 @@ static void lm3533_bl_shutdown(struct platform_device *pdev)
lm3533_ctrlbank_disable(&bl->cb);
}
+static const struct of_device_id lm3533_bl_of_match[] = {
+ { .compatible = "ti,lm3533-backlight", },
+ { },
+};
+MODULE_DEVICE_TABLE(of, lm3533_bl_of_match);
+
static struct platform_driver lm3533_bl_driver = {
.driver = {
.name = "lm3533-backlight",
.pm = &lm3533_bl_pm_ops,
+ .of_match_table = lm3533_bl_of_match,
},
.probe = lm3533_bl_probe,
.remove = lm3533_bl_remove,
--
2.11.0
^ permalink raw reply related
* [PATCH v5 2/5] mfd: lm3533: Support initialization from Device Tree
From: Bjorn Andersson @ 2017-01-04 11:50 UTC (permalink / raw)
To: Lee Jones
Cc: Rob Herring, Mark Rutland, Jonathan Cameron, Hartmut Knaack,
Lars-Peter Clausen, Peter Meerwald-Stadler, Richard Purdie,
Pavel Machek, Jingoo Han, devicetree, linux-kernel, linux-iio,
linux-leds
In-Reply-To: <20170104115050.24770-1-bjorn.andersson@linaro.org>
From: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Implement support for initialization of the lm3533 driver core and
probing child devices from Device Tree.
Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
Note that this patch can be merged independently of the other patches in the
series, pending approval of the DT binding.
Changes since v4:
- Moved of_node check into lm3533_pdata_from_of_node()
Changes since v3:
- Moved parsing of child of nodes into each child driver
- Use of_platform_populate() to instanciate child devices
drivers/mfd/lm3533-core.c | 77 +++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 77 insertions(+)
diff --git a/drivers/mfd/lm3533-core.c b/drivers/mfd/lm3533-core.c
index 5abcbb2e8849..37bcd5a0b99f 100644
--- a/drivers/mfd/lm3533-core.c
+++ b/drivers/mfd/lm3533-core.c
@@ -18,6 +18,8 @@
#include <linux/gpio.h>
#include <linux/i2c.h>
#include <linux/mfd/core.h>
+#include <linux/of_gpio.h>
+#include <linux/of_platform.h>
#include <linux/regmap.h>
#include <linux/seq_file.h>
#include <linux/slab.h>
@@ -512,6 +514,11 @@ static int lm3533_device_init(struct lm3533 *lm3533)
lm3533_device_bl_init(lm3533);
lm3533_device_led_init(lm3533);
+ if (lm3533->dev->of_node) {
+ of_platform_populate(lm3533->dev->of_node, NULL, NULL,
+ lm3533->dev);
+ }
+
ret = sysfs_create_group(&lm3533->dev->kobj, &lm3533_attribute_group);
if (ret < 0) {
dev_err(lm3533->dev, "failed to create sysfs attributes\n");
@@ -588,10 +595,76 @@ static const struct regmap_config regmap_config = {
.precious_reg = lm3533_precious_register,
};
+static int lm3533_of_parse_enum(struct device *dev, const char *propname,
+ const unsigned int *match, size_t num_matches)
+{
+ size_t i;
+ int ret;
+ u32 val;
+
+ ret = of_property_read_u32(dev->of_node, propname, &val);
+ if (ret < 0) {
+ dev_err(dev, "failed to parse %s\n", propname);
+ return ret;
+ }
+
+ for (i = 0; i < num_matches; i++) {
+ if (val == match[i])
+ return i;
+ }
+
+ dev_err(dev, "unsupported value of %s\n", propname);
+ return -EINVAL;
+}
+
+static int lm3533_pdata_from_of_node(struct device *dev)
+{
+ struct lm3533_platform_data *pdata;
+ int ret;
+ const unsigned int freqs[] = {
+ [LM3533_BOOST_FREQ_500KHZ] = 500000,
+ [LM3533_BOOST_FREQ_1000KHZ] = 1000000,
+ };
+ const unsigned int ovps[] = {
+ [LM3533_BOOST_OVP_16V] = 16000,
+ [LM3533_BOOST_OVP_24V] = 24000,
+ [LM3533_BOOST_OVP_32V] = 32000,
+ [LM3533_BOOST_OVP_40V] = 40000,
+ };
+
+ if (!dev->of_node)
+ return 0;
+
+ pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
+
+ pdata->gpio_hwen = of_get_named_gpio(dev->of_node, "hwen-gpios", 0);
+ if (pdata->gpio_hwen < 0)
+ return pdata->gpio_hwen;
+
+ ret = lm3533_of_parse_enum(dev, "ti,boost-freq-hz",
+ freqs, ARRAY_SIZE(freqs));
+ if (ret < 0)
+ return ret;
+ pdata->boost_freq = ret;
+
+ ret = lm3533_of_parse_enum(dev, "ti,boost-ovp-mv",
+ ovps, ARRAY_SIZE(ovps));
+ if (ret < 0)
+ return ret;
+ pdata->boost_ovp = ret;
+
+ dev->platform_data = pdata;
+
+ return 0;
+}
+
static int lm3533_i2c_probe(struct i2c_client *i2c,
const struct i2c_device_id *id)
{
struct lm3533 *lm3533;
+ int ret;
dev_dbg(&i2c->dev, "%s\n", __func__);
@@ -608,6 +681,10 @@ static int lm3533_i2c_probe(struct i2c_client *i2c,
lm3533->dev = &i2c->dev;
lm3533->irq = i2c->irq;
+ ret = lm3533_pdata_from_of_node(lm3533->dev);
+ if (ret < 0)
+ return ret;
+
return lm3533_device_init(lm3533);
}
--
2.11.0
^ permalink raw reply related
* [PATCH v5 1/5] devicetree: mfd: Add binding for the TI LM3533
From: Bjorn Andersson @ 2017-01-04 11:50 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Jonathan Cameron
Cc: Lee Jones, Hartmut Knaack, Lars-Peter Clausen,
Peter Meerwald-Stadler, Richard Purdie, Pavel Machek, Jingoo Han,
devicetree, linux-kernel, linux-iio, linux-leds
From: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Add the binding for the Texas Instruments LM3533 lighting power
solution.
Acked-by: Jonathan Cameron <jic23@kernel.org>
Acked-by: Rob Herring <robh@kernel.org>
Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
Changes since v4:
- Acks from Jonathan, Lee and Rob
Changes since v3:
- Added compatible to sub-nodes, per Lee's requested to treat them as separate
pieces.
Documentation/devicetree/bindings/mfd/lm3533.txt | 205 +++++++++++++++++++++++
1 file changed, 205 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/lm3533.txt
diff --git a/Documentation/devicetree/bindings/mfd/lm3533.txt b/Documentation/devicetree/bindings/mfd/lm3533.txt
new file mode 100644
index 000000000000..909281096ba2
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/lm3533.txt
@@ -0,0 +1,205 @@
+Texas Instruments LM3533 binding
+
+This binding describes the Texas Instruments LM3533, a lighting power solution
+for smartphone handsets. The common properties are described directly in the
+node, while each individual component are described in an optional subnode.
+
+- compatible:
+ Usage: required
+ Value type: <stringlist>
+ Definition: must be:
+ "ti,lm3533"
+
+- reg:
+ Usage: required
+ Value type: <u32>
+ Definition: i2c address of the LM3533 chip
+
+- als-supply:
+ Usage: optional
+ Value type: <prop-encoded-array>
+ Definition: reference to regulator powering the V_als input; as
+ specified in "../regulator/regulator.txt"
+
+- hwen-gpios:
+ Usage: required
+ Value type: <prop-encoded-array>
+ Definition: reference to gpio pin connected to the HWEN input; as
+ specified in "../gpio/gpio.txt"
+
+- ti,boost-freq-hz:
+ Usage: required
+ Value type: <u32>
+ Definition: switch-frequency of the boost converter, must be either:
+ 500000 or 1000000
+
+- ti,boost-ovp-mv:
+ Usage: required
+ Value type: <u32>
+ Definition: over-voltage protection limit, in mV. Must be one of:
+ 16000, 24000, 32000 or 40000
+
+- #address-cells:
+ Usage: required
+ Value type: <u32>
+ Definition: must be 1
+
+- #size-cells:
+ Usage: required
+ Value type: <u32>
+ Definition: must be 0
+
+= ALS SUBNODE
+The ambient light sensor subnode carrying the light sensor related properties.
+
+- compatible:
+ Usage: required
+ Value type: <stringlist>
+ Definition: must be:
+ "ti,lm3533-als"
+
+- ti,als-resistance-ohm:
+ Usage: required (unless ti,pwm-mode is specified)
+ Value type: <u32>
+ Definition: specifies the resistor value (R_als), in Ohm. Valid values
+ ranges from 200000 to 1574 Ohm.
+
+- ti,pwm-mode:
+ Usage: optional
+ Value type: <empty>
+ Definition: specifies, if present, that the als should operate in PWM
+ mode - rather than analog mode
+
+= BACKLIGHT NODES
+Backlight subnodes carrying the backlight related properties.
+
+- compatible:
+ Usage: required
+ Value type: <stringlist>
+ Definition: must be:
+ "ti,lm3533-backlight"
+
+- reg:
+ Usage: required
+ Value type: <u32>
+ Definition: specifies which of the two backlights this node corresponds
+ to
+
+- default-brightness:
+ Usage: optional
+ Value type: <32>
+ Definition: specifies the default brightness for the backlight, in
+ units of brightness [0-255]
+
+- label:
+ Usage: required
+ Value type: <string>
+ Definition: specifies a name of this backlight
+
+- led-max-microamp:
+ Usage: required
+ Value type: <u32>
+ Definition: specifies the max current for this backlight, in uA, as
+ described in "../leds/common.txt"
+
+- ti,pwm-zones:
+ Usage: optional
+ Value type: <u32 list>
+ Definition: lists the ALS zones to be PWM controlled for this backlight,
+ the values in the list are in the range [0 - 4]
+
+= LED NODES
+LED subnodes carrying the LED related properties.
+
+- compatible:
+ Usage: required
+ Value type: <stringlist>
+ Definition: must be:
+ "ti,lm3533-led"
+
+- reg:
+ Usage: required
+ Value type: <u32>
+ Definition: specifies which of the four LEDs this node corresponds to
+
+- linux,default-trigger:
+ Usage: optional
+ Value type: <string>
+ Definition: specifies the default trigger for the LED, as described in
+ "../leds/common.txt"
+
+- label:
+ Usage: required
+ Value type: <string>
+ Definition: specifies a name of this LED, as described in
+ "../leds/common.txt"
+
+- led-max-microamp:
+ Usage: required
+ Value type: <u32>
+ Definition: specifies the max current for this LED, in uA, as described
+ in "../leds/common.txt"
+
+- ti,pwm-zones:
+ Usage: optional
+ Value type: <u32 list>
+ Definition: lists the ALS zones to be PWM controlled for this LED, the
+ values in the list are in the range [0 - 4]
+
+= EXAMPLE
+
+i2c@12460000 {
+ compatible = "qcom,i2c-qup-v1.1.1";
+ ...
+
+ lm3533@36 {
+ compatible = "ti,lm3533";
+ reg = <0x36>;
+
+ als-supply = <&pm8921_l11>;
+ hwen-gpios = <&pm8921_gpio 26 GPIO_ACTIVE_HIGH>;
+
+ ti,boost-freq-hz = <500000>;
+ ti,boost-ovp-mv = <24000>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ als {
+ compatible = "ti,lm3533-als";
+ ti,als-resistance-ohm = <200000>;
+ };
+
+ backlight@0 {
+ compatible = "ti,lm3533-backlight";
+ reg = <0>;
+ label = "backlight";
+
+ led-max-microamp = <20200>;
+ };
+
+ led@0 {
+ compatible = "ti,lm3533-led";
+ reg = <0>;
+ label = "red";
+
+ led-max-microamp = <5000>;
+ };
+
+ led@1 {
+ compatible = "ti,lm3533-led";
+ reg = <1>;
+ label = "green";
+
+ led-max-microamp = <5000>;
+ };
+
+ led@2 {
+ compatible = "ti,lm3533-led";
+ reg = <2>;
+ label = "blue";
+
+ led-max-microamp = <5000>;
+ };
+ };
+
--
2.11.0
^ permalink raw reply related
* [PATCH v6 5/5] soc: zte: pm_domains: Add support for zx296718
From: Baoyou Xie @ 2017-01-04 11:48 UTC (permalink / raw)
To: jun.nie-QSEj5FYQhm4dnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, krzk-DgEjT+Ai2ygdnm+yROfE0A,
arnd-r2nGTMty4D4, ulf.hansson-QSEj5FYQhm4dnm+yROfE0A,
amitdanielk-Re5JQEeQqe8AvxtiuMwx3w, claudiu.manoil-3arQi8VN3Tc,
yangbo.lu-3arQi8VN3Tc, pankaj.dubey-Sze3O3UU22JBDgjK7y7TUQ,
geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ,
laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
shawnguo-DgEjT+Ai2ygdnm+yROfE0A,
baoyou.xie-QSEj5FYQhm4dnm+yROfE0A,
xie.baoyou-Th6q7B73Y6EnDS1+zs4M5A,
chen.chaokai-Th6q7B73Y6EnDS1+zs4M5A,
wang.qiang01-Th6q7B73Y6EnDS1+zs4M5A
In-Reply-To: <1483530494-14177-1-git-send-email-baoyou.xie-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
This patch introduces the power domain driver of zx296718
which belongs to zte's zx2967 family.
Signed-off-by: Baoyou Xie <baoyou.xie-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Reviewed-by: Jun Nie <jun.nie-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
drivers/soc/zte/Makefile | 1 +
drivers/soc/zte/zx296718_pm_domains.c | 181 ++++++++++++++++++++++++++++++++++
2 files changed, 182 insertions(+)
create mode 100644 drivers/soc/zte/zx296718_pm_domains.c
diff --git a/drivers/soc/zte/Makefile b/drivers/soc/zte/Makefile
index 8a37f2f..96b7cd4 100644
--- a/drivers/soc/zte/Makefile
+++ b/drivers/soc/zte/Makefile
@@ -2,3 +2,4 @@
# ZTE SOC drivers
#
obj-$(CONFIG_ZX2967_PM_DOMAINS) += zx2967_pm_domains.o
+obj-$(CONFIG_ZX2967_PM_DOMAINS) += zx296718_pm_domains.o
diff --git a/drivers/soc/zte/zx296718_pm_domains.c b/drivers/soc/zte/zx296718_pm_domains.c
new file mode 100644
index 0000000..52003ee
--- /dev/null
+++ b/drivers/soc/zte/zx296718_pm_domains.c
@@ -0,0 +1,181 @@
+/*
+ * Copyright (C) 2017 ZTE Ltd.
+ *
+ * Author: Baoyou Xie <baoyou.xie-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
+ * License terms: GNU General Public License (GPL) version 2
+ */
+#include <dt-bindings/soc/zte,pm_domains.h>
+#include "zx2967_pm_domains.h"
+
+static u16 zx296718_offsets[REG_ARRAY_SIZE] = {
+ [REG_CLKEN] = 0x18,
+ [REG_ISOEN] = 0x1c,
+ [REG_RSTEN] = 0x20,
+ [REG_PWREN] = 0x24,
+ [REG_ACK_SYNC] = 0x28,
+};
+
+enum {
+ PCU_DM_VOU = 0,
+ PCU_DM_SAPPU,
+ PCU_DM_VDE,
+ PCU_DM_VCE,
+ PCU_DM_HDE,
+ PCU_DM_VIU,
+ PCU_DM_USB20,
+ PCU_DM_USB21,
+ PCU_DM_USB30,
+ PCU_DM_HSIC,
+ PCU_DM_GMAC,
+ PCU_DM_TS,
+};
+
+static struct zx2967_pm_domain vou_domain = {
+ .dm = {
+ .name = "vou_domain",
+ },
+ .bit = PCU_DM_VOU,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct zx2967_pm_domain sappu_domain = {
+ .dm = {
+ .name = "sappu_domain",
+ },
+ .bit = PCU_DM_SAPPU,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct zx2967_pm_domain vde_domain = {
+ .dm = {
+ .name = "vde_domain",
+ },
+ .bit = PCU_DM_VDE,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct zx2967_pm_domain vce_domain = {
+ .dm = {
+ .name = "vce_domain",
+ },
+ .bit = PCU_DM_VCE,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct zx2967_pm_domain hde_domain = {
+ .dm = {
+ .name = "hde_domain",
+ },
+ .bit = PCU_DM_HDE,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct zx2967_pm_domain viu_domain = {
+ .dm = {
+ .name = "viu_domain",
+ },
+ .bit = PCU_DM_VIU,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct zx2967_pm_domain usb20_domain = {
+ .dm = {
+ .name = "usb20_domain",
+ },
+ .bit = PCU_DM_USB20,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct zx2967_pm_domain usb21_domain = {
+ .dm = {
+ .name = "usb21_domain",
+ },
+ .bit = PCU_DM_USB21,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct zx2967_pm_domain usb30_domain = {
+ .dm = {
+ .name = "usb30_domain",
+ },
+ .bit = PCU_DM_USB30,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct zx2967_pm_domain hsic_domain = {
+ .dm = {
+ .name = "hsic_domain",
+ },
+ .bit = PCU_DM_HSIC,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct zx2967_pm_domain gmac_domain = {
+ .dm = {
+ .name = "gmac_domain",
+ },
+ .bit = PCU_DM_GMAC,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct zx2967_pm_domain ts_domain = {
+ .dm = {
+ .name = "ts_domain",
+ },
+ .bit = PCU_DM_TS,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct generic_pm_domain *zx296718_pm_domains[] = {
+ [DM_ZX296718_SAPPU] = &sappu_domain.dm,
+ [DM_ZX296718_VDE] = &vde_domain.dm,
+ [DM_ZX296718_VCE] = &vce_domain.dm,
+ [DM_ZX296718_HDE] = &hde_domain.dm,
+ [DM_ZX296718_VIU] = &viu_domain.dm,
+ [DM_ZX296718_USB20] = &usb20_domain.dm,
+ [DM_ZX296718_USB21] = &usb21_domain.dm,
+ [DM_ZX296718_USB30] = &usb30_domain.dm,
+ [DM_ZX296718_HSIC] = &hsic_domain.dm,
+ [DM_ZX296718_GMAC] = &gmac_domain.dm,
+ [DM_ZX296718_TS] = &ts_domain.dm,
+ [DM_ZX296718_VOU] = &vou_domain.dm,
+};
+
+static int zx296718_pd_probe(struct platform_device *pdev)
+{
+ return zx2967_pd_probe(pdev,
+ zx296718_pm_domains,
+ ARRAY_SIZE(zx296718_pm_domains));
+}
+
+static const struct of_device_id zx296718_pm_domain_matches[] = {
+ { .compatible = "zte,zx296718-pcu", },
+ { },
+};
+
+static struct platform_driver zx296718_pd_driver = {
+ .driver = {
+ .name = "zx-powerdomain",
+ .owner = THIS_MODULE,
+ .of_match_table = zx296718_pm_domain_matches,
+ },
+ .probe = zx296718_pd_probe,
+};
+
+static int __init zx296718_pd_init(void)
+{
+ return platform_driver_register(&zx296718_pd_driver);
+}
+subsys_initcall(zx296718_pd_init);
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v6 4/5] soc: zte: pm_domains: Prepare for supporting ARMv8 zx2967 family
From: Baoyou Xie @ 2017-01-04 11:48 UTC (permalink / raw)
To: jun.nie, robh+dt, mark.rutland, krzk, arnd, ulf.hansson,
amitdanielk, claudiu.manoil, yangbo.lu, pankaj.dubey,
geert+renesas, laurent.pinchart
Cc: linux-arm-kernel, devicetree, linux-kernel, shawnguo, baoyou.xie,
xie.baoyou, chen.chaokai, wang.qiang01
In-Reply-To: <1483530494-14177-1-git-send-email-baoyou.xie@linaro.org>
The ARMv8 zx2967 family (296718, 296716 etc) uses different value
for controlling the power domain on/off registers, Choose the
value depending on the compatible.
Multiple domains are prepared for the family, this patch prepares
the common functions.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
drivers/soc/Kconfig | 1 +
drivers/soc/Makefile | 1 +
drivers/soc/zte/Kconfig | 13 ++++
drivers/soc/zte/Makefile | 4 +
drivers/soc/zte/zx2967_pm_domains.c | 142 ++++++++++++++++++++++++++++++++++++
drivers/soc/zte/zx2967_pm_domains.h | 44 +++++++++++
6 files changed, 205 insertions(+)
create mode 100644 drivers/soc/zte/Kconfig
create mode 100644 drivers/soc/zte/Makefile
create mode 100644 drivers/soc/zte/zx2967_pm_domains.c
create mode 100644 drivers/soc/zte/zx2967_pm_domains.h
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index f31bceb..f09023f 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -11,5 +11,6 @@ source "drivers/soc/tegra/Kconfig"
source "drivers/soc/ti/Kconfig"
source "drivers/soc/ux500/Kconfig"
source "drivers/soc/versatile/Kconfig"
+source "drivers/soc/zte/Kconfig"
endmenu
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index 50c23d0..05eae52 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -16,3 +16,4 @@ obj-$(CONFIG_ARCH_TEGRA) += tegra/
obj-$(CONFIG_SOC_TI) += ti/
obj-$(CONFIG_ARCH_U8500) += ux500/
obj-$(CONFIG_PLAT_VERSATILE) += versatile/
+obj-$(CONFIG_ARCH_ZX) += zte/
diff --git a/drivers/soc/zte/Kconfig b/drivers/soc/zte/Kconfig
new file mode 100644
index 0000000..20bde38
--- /dev/null
+++ b/drivers/soc/zte/Kconfig
@@ -0,0 +1,13 @@
+#
+# ZTE SoC drivers
+#
+menuconfig SOC_ZTE
+ bool "ZTE SoC driver support"
+
+if SOC_ZTE
+
+config ZX2967_PM_DOMAINS
+ bool "ZX2967 PM domains"
+ depends on PM_GENERIC_DOMAINS
+
+endif
diff --git a/drivers/soc/zte/Makefile b/drivers/soc/zte/Makefile
new file mode 100644
index 0000000..8a37f2f
--- /dev/null
+++ b/drivers/soc/zte/Makefile
@@ -0,0 +1,4 @@
+#
+# ZTE SOC drivers
+#
+obj-$(CONFIG_ZX2967_PM_DOMAINS) += zx2967_pm_domains.o
diff --git a/drivers/soc/zte/zx2967_pm_domains.c b/drivers/soc/zte/zx2967_pm_domains.c
new file mode 100644
index 0000000..f190a62
--- /dev/null
+++ b/drivers/soc/zte/zx2967_pm_domains.c
@@ -0,0 +1,142 @@
+/*
+ * Copyright (C) 2017 ZTE Ltd.
+ *
+ * Author: Baoyou Xie <baoyou.xie@linaro.org>
+ * License terms: GNU General Public License (GPL) version 2
+ */
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/of.h>
+
+#include "zx2967_pm_domains.h"
+
+#define PCU_DM_CLKEN(zpd) ((zpd)->reg_offset[REG_CLKEN])
+#define PCU_DM_ISOEN(zpd) ((zpd)->reg_offset[REG_ISOEN])
+#define PCU_DM_RSTEN(zpd) ((zpd)->reg_offset[REG_RSTEN])
+#define PCU_DM_PWREN(zpd) ((zpd)->reg_offset[REG_PWREN])
+#define PCU_DM_ACK_SYNC(zpd) ((zpd)->reg_offset[REG_ACK_SYNC])
+
+static void __iomem *pcubase;
+
+int zx2967_power_on(struct generic_pm_domain *domain)
+{
+ struct zx2967_pm_domain *zpd = (struct zx2967_pm_domain *)domain;
+ unsigned long loop = 1000;
+ u32 val;
+
+ val = readl_relaxed(pcubase + PCU_DM_PWREN(zpd));
+ if (zpd->polarity == PWREN)
+ val |= BIT(zpd->bit);
+ else
+ val &= ~BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_PWREN(zpd));
+
+ do {
+ udelay(1);
+ val = readl_relaxed(pcubase + PCU_DM_ACK_SYNC(zpd))
+ & BIT(zpd->bit);
+ } while (--loop && !val);
+
+ if (!loop) {
+ pr_err("Error: %s %s fail\n", __func__, domain->name);
+ return -EIO;
+ }
+
+ val = readl_relaxed(pcubase + PCU_DM_RSTEN(zpd));
+ val |= BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_RSTEN(zpd));
+ udelay(5);
+
+ val = readl_relaxed(pcubase + PCU_DM_ISOEN(zpd));
+ val &= ~BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_ISOEN(zpd));
+ udelay(5);
+
+ val = readl_relaxed(pcubase + PCU_DM_CLKEN(zpd));
+ val |= BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_CLKEN(zpd));
+ udelay(5);
+
+ pr_debug("poweron %s\n", domain->name);
+
+ return 0;
+}
+
+int zx2967_power_off(struct generic_pm_domain *domain)
+{
+ struct zx2967_pm_domain *zpd = (struct zx2967_pm_domain *)domain;
+ unsigned long loop = 1000;
+ u32 val;
+
+ val = readl_relaxed(pcubase + PCU_DM_CLKEN(zpd));
+ val &= ~BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_CLKEN(zpd));
+ udelay(5);
+
+ val = readl_relaxed(pcubase + PCU_DM_ISOEN(zpd));
+ val |= BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_ISOEN(zpd));
+ udelay(5);
+
+ val = readl_relaxed(pcubase + PCU_DM_RSTEN(zpd));
+ val &= ~BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_RSTEN(zpd));
+ udelay(5);
+
+ val = readl_relaxed(pcubase + PCU_DM_PWREN(zpd));
+ if (zpd->polarity == PWREN)
+ val &= ~BIT(zpd->bit);
+ else
+ val |= BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_PWREN(zpd));
+
+ do {
+ udelay(1);
+ val = readl_relaxed(pcubase + PCU_DM_ACK_SYNC(zpd))
+ & BIT(zpd->bit);
+ } while (--loop && val);
+
+ if (!loop) {
+ pr_err("Error: %s %s fail\n", __func__, domain->name);
+ return -EIO;
+ }
+
+ pr_debug("poweroff %s\n", domain->name);
+
+ return 0;
+}
+
+int zx2967_pd_probe(struct platform_device *pdev,
+ struct generic_pm_domain **zx_pm_domains,
+ int domain_num)
+{
+ struct genpd_onecell_data *genpd_data;
+ struct resource *res;
+ int i;
+
+ genpd_data = devm_kzalloc(&pdev->dev, sizeof(*genpd_data), GFP_KERNEL);
+ if (!genpd_data)
+ return -ENOMEM;
+
+ genpd_data->domains = zx_pm_domains;
+ genpd_data->num_domains = domain_num;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ pcubase = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(pcubase)) {
+ dev_err(&pdev->dev, "ioremap fail.\n");
+ return PTR_ERR(pcubase);
+ }
+
+ for (i = 0; i < domain_num; ++i) {
+ zx_pm_domains[i]->power_on = zx2967_power_on;
+ zx_pm_domains[i]->power_off = zx2967_power_off;
+
+ pm_genpd_init(zx_pm_domains[i], NULL, false);
+ }
+
+ of_genpd_add_provider_onecell(pdev->dev.of_node, genpd_data);
+ dev_info(&pdev->dev, "powerdomain init ok\n");
+ return 0;
+}
diff --git a/drivers/soc/zte/zx2967_pm_domains.h b/drivers/soc/zte/zx2967_pm_domains.h
new file mode 100644
index 0000000..cb46595
--- /dev/null
+++ b/drivers/soc/zte/zx2967_pm_domains.h
@@ -0,0 +1,44 @@
+/*
+ * Header for ZTE's Power Domain Driver support
+ *
+ * Copyright (C) 2017 ZTE Ltd.
+ *
+ * Author: Baoyou Xie <baoyou.xie@linaro.org>
+ * License terms: GNU General Public License (GPL) version 2
+ */
+
+#ifndef __ZTE_ZX2967_PM_DOMAIN_H
+#define __ZTE_ZX2967_PM_DOMAIN_H
+
+#include <linux/platform_device.h>
+#include <linux/pm_domain.h>
+
+enum {
+ REG_CLKEN,
+ REG_ISOEN,
+ REG_RSTEN,
+ REG_PWREN,
+ REG_PWRDN,
+ REG_ACK_SYNC,
+
+ /* The size of the array - must be last */
+ REG_ARRAY_SIZE,
+};
+
+enum zx2967_power_polarity {
+ PWREN,
+ PWRDN,
+};
+
+struct zx2967_pm_domain {
+ struct generic_pm_domain dm;
+ const u16 bit;
+ const enum zx2967_power_polarity polarity;
+ const u16 *reg_offset;
+};
+
+int zx2967_pd_probe(struct platform_device *pdev,
+ struct generic_pm_domain **zx_pm_domains,
+ int domain_num);
+
+#endif /* __ZTE_ZX2967_PM_DOMAIN_H */
--
2.7.4
^ permalink raw reply related
* [PATCH v6 3/5] soc: zte: Add header for PM domains specifiers
From: Baoyou Xie @ 2017-01-04 11:48 UTC (permalink / raw)
To: jun.nie-QSEj5FYQhm4dnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, krzk-DgEjT+Ai2ygdnm+yROfE0A,
arnd-r2nGTMty4D4, ulf.hansson-QSEj5FYQhm4dnm+yROfE0A,
amitdanielk-Re5JQEeQqe8AvxtiuMwx3w, claudiu.manoil-3arQi8VN3Tc,
yangbo.lu-3arQi8VN3Tc, pankaj.dubey-Sze3O3UU22JBDgjK7y7TUQ,
geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ,
laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
shawnguo-DgEjT+Ai2ygdnm+yROfE0A,
baoyou.xie-QSEj5FYQhm4dnm+yROfE0A,
xie.baoyou-Th6q7B73Y6EnDS1+zs4M5A,
chen.chaokai-Th6q7B73Y6EnDS1+zs4M5A,
wang.qiang01-Th6q7B73Y6EnDS1+zs4M5A
In-Reply-To: <1483530494-14177-1-git-send-email-baoyou.xie-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
This patch adds header with values used for ZTE 2967
SoC's power domain driver.
Signed-off-by: Baoyou Xie <baoyou.xie-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
include/dt-bindings/soc/zte,pm_domains.h | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
create mode 100644 include/dt-bindings/soc/zte,pm_domains.h
diff --git a/include/dt-bindings/soc/zte,pm_domains.h b/include/dt-bindings/soc/zte,pm_domains.h
new file mode 100644
index 0000000..01e9abc
--- /dev/null
+++ b/include/dt-bindings/soc/zte,pm_domains.h
@@ -0,0 +1,23 @@
+/*
+ * Copyright (C) 2017 Linaro Ltd.
+ *
+ * Author: Baoyou Xie <baoyou.xie-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
+ * License terms: GNU General Public License (GPL) version 2
+ */
+#ifndef _DT_BINDINGS_SOC_ZTE_PM_DOMAINS_H
+#define _DT_BINDINGS_SOC_ZTE_PM_DOMAINS_H
+
+#define DM_ZX296718_SAPPU 0
+#define DM_ZX296718_VDE 1 /* g1v6 */
+#define DM_ZX296718_VCE 2 /* h1v6 */
+#define DM_ZX296718_HDE 3 /* g2v2 */
+#define DM_ZX296718_VIU 4
+#define DM_ZX296718_USB20 5
+#define DM_ZX296718_USB21 6
+#define DM_ZX296718_USB30 7
+#define DM_ZX296718_HSIC 8
+#define DM_ZX296718_GMAC 9
+#define DM_ZX296718_TS 10
+#define DM_ZX296718_VOU 11
+
+#endif /* _DT_BINDINGS_SOC_ZTE_PM_DOMAINS_H */
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v6 2/5] MAINTAINERS: add zx2967 SoC drivers to ARM ZTE architecture
From: Baoyou Xie @ 2017-01-04 11:48 UTC (permalink / raw)
To: jun.nie-QSEj5FYQhm4dnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, krzk-DgEjT+Ai2ygdnm+yROfE0A,
arnd-r2nGTMty4D4, ulf.hansson-QSEj5FYQhm4dnm+yROfE0A,
amitdanielk-Re5JQEeQqe8AvxtiuMwx3w, claudiu.manoil-3arQi8VN3Tc,
yangbo.lu-3arQi8VN3Tc, pankaj.dubey-Sze3O3UU22JBDgjK7y7TUQ,
geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ,
laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
shawnguo-DgEjT+Ai2ygdnm+yROfE0A,
baoyou.xie-QSEj5FYQhm4dnm+yROfE0A,
xie.baoyou-Th6q7B73Y6EnDS1+zs4M5A,
chen.chaokai-Th6q7B73Y6EnDS1+zs4M5A,
wang.qiang01-Th6q7B73Y6EnDS1+zs4M5A
In-Reply-To: <1483530494-14177-1-git-send-email-baoyou.xie-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Add the ZTE SoC drivers as maintained by ARM ZTE
architecture maintainers, as they're parts of the core IP.
By the way, this patch adds the maintainer for ARM
ZTE architecture to Baoyou Xie.
Signed-off-by: Baoyou Xie <baoyou.xie-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
MAINTAINERS | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index ad199da..2593296 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1975,12 +1975,17 @@ F: arch/arm/mach-pxa/include/mach/z2.h
ARM/ZTE ARCHITECTURE
M: Jun Nie <jun.nie-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
+M: Baoyou Xie <baoyou.xie-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
L: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org (moderated for non-subscribers)
S: Maintained
F: arch/arm/mach-zx/
F: drivers/clk/zte/
+F: drivers/soc/zte/
+F: drivers/thermal/zx*
F: Documentation/devicetree/bindings/arm/zte.txt
F: Documentation/devicetree/bindings/clock/zx296702-clk.txt
+F: Documentation/devicetree/bindings/soc/zte/
+F: include/dt-bindings/soc/zx*.h
ARM/ZYNQ ARCHITECTURE
M: Michal Simek <michal.simek-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v6 1/5] dt-bindings: zte: documents zx2967 power domain driver bindings
From: Baoyou Xie @ 2017-01-04 11:48 UTC (permalink / raw)
To: jun.nie, robh+dt, mark.rutland, krzk, arnd, ulf.hansson,
amitdanielk, claudiu.manoil, yangbo.lu, pankaj.dubey,
geert+renesas, laurent.pinchart
Cc: linux-arm-kernel, devicetree, linux-kernel, shawnguo, baoyou.xie,
xie.baoyou, chen.chaokai, wang.qiang01
This patch documents devicetree tree bindings for the ZTE zx2967
power domain driver.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
Documentation/devicetree/bindings/soc/zte/pd-2967xx.txt | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/zte/pd-2967xx.txt
diff --git a/Documentation/devicetree/bindings/soc/zte/pd-2967xx.txt b/Documentation/devicetree/bindings/soc/zte/pd-2967xx.txt
new file mode 100644
index 0000000..1476318
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/zte/pd-2967xx.txt
@@ -0,0 +1,17 @@
+* ZTE 2967 SoC Power Domains
+
+2967 processors include support for multiple power domains which are used
+to gate power to one or more peripherals on the processor.
+
+Required Properties:
+- compatible: should be one of the following.
+ * zte,zx296718-pcu - for zx296718 board's power domain.
+- reg: physical base address of the controller and length of memory mapped
+ region.
+
+Example:
+
+ pcu_domain: pcu@0x00117000 {
+ compatible = "zte,zx296718-pcu";
+ reg = <0x00117000 0x1000>;
+ };
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v4 5/5] mfd: dt: Add bindings for the Aspeed SoC Display Controller (GFX)
From: Lee Jones @ 2017-01-04 11:36 UTC (permalink / raw)
To: Andrew Jeffery
Cc: Rob Herring, Mark Rutland, Linus Walleij, Corey Minyard,
Cédric Le Goater, Joel Stanley, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <20161220071535.27542-6-andrew@aj.id.au>
On Tue, 20 Dec 2016, Andrew Jeffery wrote:
> The Aspeed SoC Display Controller is presented as a syscon device to
> arbitrate access by display and pinmux drivers. Video pinmux
> configuration on fifth generation SoCs depends on bits in both the
> System Control Unit and the Display Controller.
>
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
> Documentation/devicetree/bindings/mfd/aspeed-gfx.txt | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/aspeed-gfx.txt
Applied, thanks.
> diff --git a/Documentation/devicetree/bindings/mfd/aspeed-gfx.txt b/Documentation/devicetree/bindings/mfd/aspeed-gfx.txt
> new file mode 100644
> index 000000000000..aea5370efd97
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/aspeed-gfx.txt
> @@ -0,0 +1,17 @@
> +* Device tree bindings for Aspeed SoC Display Controller (GFX)
> +
> +The Aspeed SoC Display Controller primarily does as its name suggests, but also
> +participates in pinmux requests on the g5 SoCs. It is therefore considered a
> +syscon device.
> +
> +Required properties:
> +- compatible: "aspeed,ast2500-gfx", "syscon"
> +- reg: contains offset/length value of the GFX memory
> + region.
> +
> +Example:
> +
> +gfx: display@1e6e6000 {
> + compatible = "aspeed,ast2500-gfx", "syscon";
> + reg = <0x1e6e6000 0x1000>;
> +};
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH v4 4/5] mfd: dt: Add bindings for the Aspeed LPC Host Controller (LHC)
From: Lee Jones @ 2017-01-04 11:36 UTC (permalink / raw)
To: Andrew Jeffery
Cc: Rob Herring, Mark Rutland, Linus Walleij, Corey Minyard,
Cédric Le Goater, Joel Stanley,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161220071535.27542-5-andrew-zrmu5oMJ5Fs@public.gmane.org>
On Tue, 20 Dec 2016, Andrew Jeffery wrote:
> The LPC bus pinmux configuration on fifth generation Aspeed SoCs depends
> on bits in both the System Control Unit and the LPC Host Controller.
>
> The Aspeed LPC Host Controller is described as a child node of the
> LPC host-range syscon device for arbitration of access by the host
> controller and pinmux drivers.
>
> Signed-off-by: Andrew Jeffery <andrew-zrmu5oMJ5Fs@public.gmane.org>
> Reviewed-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
>
> Linus: I've retained your r-b tag I don't think the addition of the ast2400
> compatible string will fuss you. Please let me know if you feel this is
> inappropriate.
>
> .../devicetree/bindings/mfd/aspeed-lpc.txt | 26 ++++++++++++++++++++++
> 1 file changed, 26 insertions(+)
Applied, thanks.
> diff --git a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
> index a97131aba446..514d82ced95b 100644
> --- a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
> +++ b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
> @@ -109,3 +109,29 @@ lpc: lpc@1e789000 {
> };
> };
>
> +Host Node Children
> +==================
> +
> +LPC Host Controller
> +-------------------
> +
> +The Aspeed LPC Host Controller configures the Low Pin Count (LPC) bus behaviour
> +between the host and the baseboard management controller. The registers exist
> +in the "host" portion of the Aspeed LPC controller, which must be the parent of
> +the LPC host controller node.
> +
> +Required properties:
> +
> +- compatible: One of:
> + "aspeed,ast2400-lhc";
> + "aspeed,ast2500-lhc";
> +
> +- reg: contains offset/length values of the LHC memory regions. In the
> + AST2400 and AST2500 there are two regions.
> +
> +Example:
> +
> +lhc: lhc@20 {
> + compatible = "aspeed,ast2500-lhc";
> + reg = <0x20 0x24 0x48 0x8>;
> +};
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 3/5] mfd: dt: Add Aspeed Low Pin Count Controller bindings
From: Lee Jones @ 2017-01-04 11:36 UTC (permalink / raw)
To: Andrew Jeffery
Cc: Rob Herring, Mark Rutland, Linus Walleij, Corey Minyard,
Cédric Le Goater, Joel Stanley,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161220071535.27542-4-andrew-zrmu5oMJ5Fs@public.gmane.org>
On Tue, 20 Dec 2016, Andrew Jeffery wrote:
> Signed-off-by: Andrew Jeffery <andrew-zrmu5oMJ5Fs@public.gmane.org>
> Reviewed-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Reviewed-by: Joel Stanley <joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> ---
> .../devicetree/bindings/mfd/aspeed-lpc.txt | 111 +++++++++++++++++++++
> 1 file changed, 111 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
Applied, thanks.
> diff --git a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
> new file mode 100644
> index 000000000000..a97131aba446
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
> @@ -0,0 +1,111 @@
> +======================================================================
> +Device tree bindings for the Aspeed Low Pin Count (LPC) Bus Controller
> +======================================================================
> +
> +The LPC bus is a means to bridge a host CPU to a number of low-bandwidth
> +peripheral devices, replacing the use of the ISA bus in the age of PCI[0]. The
> +primary use case of the Aspeed LPC controller is as a slave on the bus
> +(typically in a Baseboard Management Controller SoC), but under certain
> +conditions it can also take the role of bus master.
> +
> +The LPC controller is represented as a multi-function device to account for the
> +mix of functionality it provides. The principle split is between the register
> +layout at the start of the I/O space which is, to quote the Aspeed datasheet,
> +"basically compatible with the [LPC registers from the] popular BMC controller
> +H8S/2168[1]", and everything else, where everything else is an eclectic
> +collection of functions with a esoteric register layout. "Everything else",
> +here labeled the "host" portion of the controller, includes, but is not limited
> +to:
> +
> +* An IPMI Block Transfer[2] Controller
> +
> +* An LPC Host Controller: Manages LPC functions such as host vs slave mode, the
> + physical properties of some LPC pins, configuration of serial IRQs, and
> + APB-to-LPC bridging amonst other functions.
> +
> +* An LPC Host Interface Controller: Manages functions exposed to the host such
> + as LPC firmware hub cycles, configuration of the LPC-to-AHB mapping, UART
> + management and bus snoop configuration.
> +
> +* A set of SuperIO[3] scratch registers: Enables implementation of e.g. custom
> + hardware management protocols for handover between the host and baseboard
> + management controller.
> +
> +Additionally the state of the LPC controller influences the pinmux
> +configuration, therefore the host portion of the controller is exposed as a
> +syscon as a means to arbitrate access.
> +
> +[0] http://www.intel.com/design/chipsets/industry/25128901.pdf
> +[1] https://www.renesas.com/en-sg/doc/products/mpumcu/001/rej09b0078_h8s2168.pdf?key=7c88837454702128622bee53acbda8f4
> +[2] http://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/ipmi-second-gen-interface-spec-v2-rev1-1.pdf
> +[3] https://en.wikipedia.org/wiki/Super_I/O
> +
> +Required properties
> +===================
> +
> +- compatible: One of:
> + "aspeed,ast2400-lpc", "simple-mfd"
> + "aspeed,ast2500-lpc", "simple-mfd"
> +
> +- reg: contains the physical address and length values of the Aspeed
> + LPC memory region.
> +
> +- #address-cells: <1>
> +- #size-cells: <1>
> +- ranges: Maps 0 to the physical address and length of the LPC memory
> + region
> +
> +Required LPC Child nodes
> +========================
> +
> +BMC Node
> +--------
> +
> +- compatible: One of:
> + "aspeed,ast2400-lpc-bmc"
> + "aspeed,ast2500-lpc-bmc"
> +
> +- reg: contains the physical address and length values of the
> + H8S/2168-compatible LPC controller memory region
> +
> +Host Node
> +---------
> +
> +- compatible: One of:
> + "aspeed,ast2400-lpc-host", "simple-mfd", "syscon"
> + "aspeed,ast2500-lpc-host", "simple-mfd", "syscon"
> +
> +- reg: contains the address and length values of the host-related
> + register space for the Aspeed LPC controller
> +
> +- #address-cells: <1>
> +- #size-cells: <1>
> +- ranges: Maps 0 to the address and length of the host-related LPC memory
> + region
> +
> +Example:
> +
> +lpc: lpc@1e789000 {
> + compatible = "aspeed,ast2500-lpc", "simple-mfd";
> + reg = <0x1e789000 0x1000>;
> +
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x0 0x1e789000 0x1000>;
> +
> + lpc_bmc: lpc-bmc@0 {
> + compatible = "aspeed,ast2500-lpc-bmc";
> + reg = <0x0 0x80>;
> + };
> +
> + lpc_host: lpc-host@80 {
> + compatible = "aspeed,ast2500-lpc-host", "simple-mfd", "syscon";
> + reg = <0x80 0x1e0>;
> + reg-io-width = <4>;
> +
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x0 0x80 0x1e0>;
> + };
> +};
> +
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 2/5] mfd: dt: ranges, #address-cells and #size-cells as optional properties
From: Lee Jones @ 2017-01-04 11:36 UTC (permalink / raw)
To: Andrew Jeffery
Cc: Rob Herring, Mark Rutland, Linus Walleij, Corey Minyard,
Cédric Le Goater, Joel Stanley,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161220071535.27542-3-andrew-zrmu5oMJ5Fs@public.gmane.org>
On Tue, 20 Dec 2016, Andrew Jeffery wrote:
> Whilst describing a device and not a bus, simple-mfd is modelled on
> simple-bus where child nodes are iterated and registered as platform
> devices. Some complex devices, e.g. the Aspeed LPC controller, can
> benefit from address space mapping such that child nodes can use the
> regs property to describe their resource offsets within the
> multi-function device.
>
> Signed-off-by: Andrew Jeffery <andrew-zrmu5oMJ5Fs@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> ---
> Documentation/devicetree/bindings/mfd/mfd.txt | 10 ++++++++++
> 1 file changed, 10 insertions(+)
Applied, thanks.
> diff --git a/Documentation/devicetree/bindings/mfd/mfd.txt b/Documentation/devicetree/bindings/mfd/mfd.txt
> index f1fceeda12f1..bcb6abb9d413 100644
> --- a/Documentation/devicetree/bindings/mfd/mfd.txt
> +++ b/Documentation/devicetree/bindings/mfd/mfd.txt
> @@ -25,6 +25,16 @@ Optional properties:
> be used. In the latter case the child devices will be determined by the
> operating system.
>
> +- ranges: Describes the address mapping relationship to the parent. Should set
> + the child's base address to 0, the physical address within parent's address
> + space, and the length of the address map.
> +
> +- #address-cells: Specifies the number of cells used to represent physical base
> + addresses. Must be present if ranges is used.
> +
> +- #size-cells: Specifies the number of cells used to represent the size of an
> + address. Must be present if ranges is used.
> +
> Example:
>
> foo@1000 {
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 1/5] mfd: dt: Fix "indicates" typo in mfd bindings document
From: Lee Jones @ 2017-01-04 11:23 UTC (permalink / raw)
To: Andrew Jeffery
Cc: Rob Herring, Mark Rutland, Linus Walleij, Corey Minyard,
Cédric Le Goater, Joel Stanley,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161220071535.27542-2-andrew-zrmu5oMJ5Fs@public.gmane.org>
On Tue, 20 Dec 2016, Andrew Jeffery wrote:
> Signed-off-by: Andrew Jeffery <andrew-zrmu5oMJ5Fs@public.gmane.org>
> Acked-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> ---
> Documentation/devicetree/bindings/mfd/mfd.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied, thanks.
> diff --git a/Documentation/devicetree/bindings/mfd/mfd.txt b/Documentation/devicetree/bindings/mfd/mfd.txt
> index af9d6931a1a2..f1fceeda12f1 100644
> --- a/Documentation/devicetree/bindings/mfd/mfd.txt
> +++ b/Documentation/devicetree/bindings/mfd/mfd.txt
> @@ -19,7 +19,7 @@ Optional properties:
>
> - compatible : "simple-mfd" - this signifies that the operating system should
> consider all subnodes of the MFD device as separate devices akin to how
> - "simple-bus" inidicates when to see subnodes as children for a simple
> + "simple-bus" indicates when to see subnodes as children for a simple
> memory-mapped bus. For more complex devices, when the nexus driver has to
> probe registers to figure out what child devices exist etc, this should not
> be used. In the latter case the child devices will be determined by the
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox