* Re: [PATCH v2 1/5] dt-bindings: gpu: add bindings for the ARM Mali Midgard GPU
From: Guillaume Tucker @ 2017-04-24 10:43 UTC (permalink / raw)
To: Rob Herring
Cc: Heiko Stuebner, Mark Rutland, Sjoerd Simons,
Enric Balletbo i Serra, John Reitan, Wookey,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <b8cf7acd-83e9-49fb-0800-19a76b8dcce5-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
On 18/04/17 10:15, Guillaume Tucker wrote:
> Hi Rob,
>
> On 04/04/17 03:00, Rob Herring wrote:
>> On Sun, Apr 02, 2017 at 08:59:44AM +0100, Guillaume Tucker wrote:
>>> +- operating-points : Refer to Documentation/devicetree/bindings/power/opp.txt
>>> + for details.
>>
>> Is this going to be sufficient vs. operating-points-v2? Or should it be
>> a power domain with OPPs?
>
> In principle, switching to operating-points-v2 should be very
> straightforward. I have smoke-tested the driver with an
> operating-points-v2 table and a phandle to it inside the gpu node
> in place of operating-points and it seems to be working fine. At
> least it parsed the OPPs and got initialised correctly.
>
> My understanding is that operating-points (v1) are not deprecated
> so we could keep the bindings as-is, but please let me know
> otherwise and I can try to address that in my next patch version.
> In the documentation, it should only be the case of replacing
> operating-points with operating-points-v2.
While the opp bindings documentation doesn't mention anything
about operating-points being deprecated, the code and comments in
of.c are pretty clear about this:
/*
* OPPs have two version of bindings now. The older one is deprecated,
* try for the new binding first.
*/
So I shall use operating-points-v2 in my patch v4.
Thanks,
Guillaume
--
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 V7 4/7] mfd: da9061: MFD core support
From: Steve Twiss @ 2017-04-24 10:37 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: <20170404083902.ywo3pdxptgfcqvga@dell>
On 04 April 2017 09:39, Lee Jones wrote:
> Subject: Re: [PATCH V7 4/7] mfd: da9061: MFD core support
>
> On Mon, 03 Apr 2017, Steve Twiss wrote:
> > From: Steve Twiss <stwiss.opensource@diasemi.com>
> > MFD support for DA9061 is provided as part of the DA9062 device driver.
> >
> > The registers header file adds two new chip variant IDs defined in DA9061
> > and DA9062 hardware. The core header file adds new software enumerations
> > for listing the valid DA9061 IRQs and a da9062_compatible_types enumeration
> > for distinguishing between DA9061/62 devices in software.
> >
> > The core source code adds a new .compatible of_device_id entry. This is
> > extended from DA9062 to support both "dlg,da9061" and "dlg,da9062". The
> > .data entry now holds a reference to the enumerated device type.
> >
> > A new regmap_irq_chip model is added for DA9061 and this supports the new
> > list of regmap_irq entries. A new mfd_cell da9061_devs[] array lists the
> > new sub system components for DA9061. Support is added for a new DA9061
> > regmap_config which lists the correct readable, writable and volatile
> > ranges for this chip.
> >
> > The probe function uses the device tree compatible string to switch on the
> > da9062_compatible_types and configure the correct mfd cells, irq chip and
> > regmap config.
> >
> > Kconfig is updated to reflect support for DA9061 and DA9062 PMICs.
> >
> > Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
>
> Ah, here it is.
>
> Applied, thanks.
Hi Lee,
I noticed the DA9061 core support has been added into linux-next, however
the commit message was changed from the original title:
"mfd: da9061: MFD core support"
to add the mistake:
"mfd: Add suppfor for DA9061"
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=d3fe0806025cacdab1462d5704e1c98ab9db4564
Can this be fixed please?
This patch has not been upstreamed into linux-mainline and is still in linux-next.
Regards,
Steve
^ permalink raw reply
* Re: Re: [PATCH v5 02/11] clk: sunxi-ng: add support for DE2 CCU
From: icenowy-h8G6r0blFSE @ 2017-04-24 10:26 UTC (permalink / raw)
To: maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8
Cc: Rob Herring, Chen-Yu Tsai, Jernej Skrabec,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170424085109.p44bmzbyjkuf7ckv@lukather>
在 2017-04-24 16:51，Maxime Ripard 写道：
> Hi,
>
> On Sun, Apr 23, 2017 at 06:37:45PM +0800, Icenowy Zheng wrote:
>> +static const struct of_device_id sunxi_de2_clk_ids[] = {
>> + {
>> + .compatible = "allwinner,sun8i-a83t-de2-clk",
>> + .data = &sun8i_a83t_de2_clk_desc,
>> + },
>> + {
>> + .compatible = "allwinner,sun50i-h5-de2-clk",
>> + .data = &sun50i_a64_de2_clk_desc,
>> + },
>> + /*
>> + * The Allwinner A64 SoC needs some bit to be poke in syscon to make
>> + * DE2 really working.
>> + * So there's currently no A64 compatible here.
>> + * H5 shares the same reset line with A64, so here H5 is using the
>> + * clock description of A64.
>> + */
>> + { }
>> +};
>
> So that A64 driver would require more than just what you defined in
> the binding in order to operate?
Yes. When trying to do A64 driver, I will send out first a patch to
add the needed binding bit.
>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: Re: [PATCH v3 02/12] arm64: allwinner: a64: add NMI controller on A64
From: icenowy-h8G6r0blFSE @ 2017-04-24 10:25 UTC (permalink / raw)
To: Maxime Ripard
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Mark Brown,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Liam Girdwood,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Chen-Yu Tsai, Rob Herring,
Lee Jones, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170424071746.u2lrk43kmvvd7m25@lukather>
在 2017-04-24 15:17，Maxime Ripard 写道：
> On Thu, Apr 20, 2017 at 03:03:38PM +0800, icenowy-h8G6r0blFSE@public.gmane.org wrote:
>> 在 2017-04-20 13:58，Maxime Ripard 写道：
>> > On Tue, Apr 18, 2017 at 06:56:43PM +0800, Icenowy Zheng wrote:
>> > >
>> > >
>> > > 于 2017年4月18日 GMT+08:00 下午3:00:16, Maxime Ripard
>> > > <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> 写到:
>> > > >On Mon, Apr 17, 2017 at 07:57:37PM +0800, Icenowy Zheng wrote:
>> > > >> Allwinner A64 SoC features a NMI controller, which is usually
>> > > >connected
>> > > >> to the AXP PMIC.
>> > > >>
>> > > >> Add support for it.
>> > > >>
>> > > >> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
>> > > >> Acked-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
>> > > >> ---
>> > > >> Changes in v2:
>> > > >> - Added Chen-Yu's ACK.
>> > > >>
>> > > >> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 8 ++++++++
>> > > >> 1 file changed, 8 insertions(+)
>> > > >>
>> > > >> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> > > >b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> > > >> index 05ec9fc5e81f..53c18ca372ea 100644
>> > > >> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> > > >> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> > > >> @@ -403,6 +403,14 @@
>> > > >> <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
>> > > >> };
>> > > >>
>> > > >> + nmi_intc: interrupt-controller@01f00c0c {
>> > > >> + compatible = "allwinner,sun6i-a31-sc-nmi";
>> > > >> + interrupt-controller;
>> > > >> + #interrupt-cells = <2>;
>> > > >> + reg = <0x01f00c0c 0x38>;
>> > > >
>> > > >The base address is not correct, and there's uncertainty on whether
>> > > >this is this particular controller or not. Did you even test this?
>> > >
>> > > Tested by axp20x-pek.
>> >
>> > Still, the base address is wrong, which is yet another hint that this
>> > is not the same interrupt controller, and just works by accident.
>>
>> No, it's the same as other post-sun6i device trees.
>> See other post-sun6i device trees: (or maybe they're all wrong, but
>> as we have no document for it, we should temporarily keep them)
>>
>> sun6i-a31.dtsi
>> ```
>> nmi_intc: interrupt-controller@01f00c0c {
>> compatible = "allwinner,sun6i-a31-sc-nmi";
>> interrupt-controller;
>> #interrupt-cells = <2>;
>> reg = <0x01f00c0c 0x38>;
>> interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
>> };
>> ```
>>
>> sun8i-a23-a33.dtsi
>> ```
>> nmi_intc: interrupt-controller@01f00c0c {
>> compatible = "allwinner,sun6i-a31-sc-nmi";
>> interrupt-controller;
>> #interrupt-cells = <2>;
>> reg = <0x01f00c0c 0x38>;
>> interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
>> };
>> ```
>>
>> But according to the BSP device tree, the base address should be
>> 0x01f00c00. Should I send some patch to fix all of them? (but it will
>> break device tree compatibility)
>
> I'm really not a big fan of "if we see something that is broken, just
> let it rot" to be honest.
>
> We have no idea how this controller works exactly, just like we have
> no idea if it is exactly the same controller or not.
>
> The only thing we have today is the memory map, and it tells us that
> it has more registers than what you express here.
>
> Because of the DT backward compatibility, you have to think of it the
> other way around: what will happen if it turns out we need to setup
> any register outside of that region you described in the DT, in
> something like a year or so?
>
> We can't, really. While if you have the full memory region from the
> beginning, then you just have to add a single writel in your driver.
So things are now already broken, and we may need to fix also A31 and
A23/33.
How should we do this?
>
> Maxime
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH 02/16] mfd: madera: Add common support for Cirrus Logic Madera codecs
From: Lee Jones @ 2017-04-24 10:03 UTC (permalink / raw)
To: Richard Fitzgerald
Cc: linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
gnurou-Re5JQEeQqe8AvxtiuMwx3w, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
tglx-hfZtesqFncYOwBW4kG4KsQ, jason-NLaQJdtUoK4Be96aLqz0jA,
broonie-DgEjT+Ai2ygdnm+yROfE0A, alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1492620124.4826.47.camel-WeElTRBN8n0bEPBeyYQi64iQ8/zYDDdY1BehtkLrGTY@public.gmane.org>
On Wed, 19 Apr 2017, Richard Fitzgerald wrote:
> On Wed, 2017-04-12 at 13:54 +0100, Lee Jones wrote:
> > On Wed, 05 Apr 2017, Richard Fitzgerald wrote:
> >
> > > This adds the generic core support for Cirrus Logic "Madera" class codecs.
> > > These are complex audio codec SoCs with a variety of digital and analogue
> > > I/O, onboard audio processing and DSPs, and other features.
> > >
> > > These codecs are all based off a common set of hardware IP so can be
> > > supported by a core of common code (with a few minor device-to-device
> > > variations).
> > >
> > > Signed-off-by: Charles Keepax <ckeepax-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
> > > Signed-off-by: Nikesh Oswal <Nikesh.Oswal-UVNVL95qEvAciDkP5Hr2oA@public.gmane.org>
> > > Signed-off-by: Richard Fitzgerald <rf-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
> > > ---
> > > Documentation/devicetree/bindings/mfd/madera.txt | 79 +++
> > > MAINTAINERS | 3 +
> > > drivers/mfd/Kconfig | 23 +
> > > drivers/mfd/Makefile | 4 +
> > > drivers/mfd/madera-core.c | 689 +++++++++++++++++++++++
> > > drivers/mfd/madera-i2c.c | 130 +++++
> > > drivers/mfd/madera-spi.c | 131 +++++
> > > drivers/mfd/madera.h | 52 ++
> > > include/linux/mfd/madera/core.h | 175 ++++++
> > > include/linux/mfd/madera/pdata.h | 88 +++
> > > 10 files changed, 1374 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/mfd/madera.txt
> > > create mode 100644 drivers/mfd/madera-core.c
> > > create mode 100644 drivers/mfd/madera-i2c.c
> > > create mode 100644 drivers/mfd/madera-spi.c
> > > create mode 100644 drivers/mfd/madera.h
> > > create mode 100644 include/linux/mfd/madera/core.h
> > > create mode 100644 include/linux/mfd/madera/pdata.h
> > >
> > > diff --git a/Documentation/devicetree/bindings/mfd/madera.txt b/Documentation/devicetree/bindings/mfd/madera.txt
> > > new file mode 100644
> > > index 0000000..a6c3260
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/mfd/madera.txt
> > > @@ -0,0 +1,79 @@
> > > +Cirrus Logic Madera class audio codecs multi-function device
> > > +
> > > +These devices are audio SoCs with extensive digital capabilities and a range
> > > +of analogue I/O.
> > > +
> > > +See also the child driver bindings in:
> > > +bindings/extcon/extcon-madera.txt
> > > +bindings/gpio/gpio-madera.txt
> > > +bindings/interrupt-controller/cirrus,madera.txt
> > > +bindings/pinctrl/cirrus,madera-pinctrl.txt
> > > +bindings/regulator/madera-ldo1.txt
> > > +bindings/regulator/madera-micsupp.txt
> > > +bindings/sound/madera.txt
> > > +
> > > +Required properties:
> > > +
> > > + - compatible : One of the following chip-specific strings:
> > > + "cirrus,cs47l35"
> > > + "cirrus,cs47l85"
> > > + "cirrus,cs47l90"
> > > + "cirrus,cs47l91"
> > > + "cirrus,wm1840"
> > > +
> > > + - reg : I2C slave address when connected using I2C, chip select number when
> > > + using SPI.
> > > +
> > > + - DCVDD-supply : Power supply for the device as defined in
> > > + bindings/regulator/regulator.txt
> > > + Mandatory on CS47L35, CS47L90, CS47L91
> > > + Optional on CS47L85, WM1840
> > > +
> > > + - AVDD-supply, DBVDD1-supply, DBVDD2-supply, CPVDD1-supply, CPVDD2-supply :
> > > + Power supplies for the device
> > > +
> > > + - DBVDD3-supply, DBVDD4-supply : Power supplies for the device
> > > + (CS47L85, CS47L90, CS47L91, WM1840)
> > > +
> > > + - SPKVDDL-supply, SPKVDDR-supply : Power supplies for the device
> > > + (CS47L85, WM1840)
> > > +
> > > + - SPKVDD-supply : Power supply for the device
> > > + (CS47L35)
> > > +
> > > +Optional properties:
> > > +
> > > + - MICVDD-supply : Power supply, only need to be specified if
> > > + powered externally
> > > +
> > > + - reset-gpios : One entry specifying the GPIO controlling /RESET.
> > > + As defined in bindings/gpio.txt.
> > > + Although optional, it is strongly recommended to use a hardware reset
> > > +
> > > + - MICBIASx : Initial data for the MICBIAS regulators, as covered in
> > > + Documentation/devicetree/bindings/regulator/regulator.txt.
> > > + One for each MICBIAS generator (MICBIAS1, MICBIAS2, ...)
> > > + (all codecs)
> > > +
> > > + One for each output pin (MICBIAS1A, MIBCIAS1B, MICBIAS2A, ...)
> > > + (all except CS47L85, WM1840)
> > > +
> > > + The following following additional property is supported for the generator
> > > + nodes:
> > > + - cirrus,ext-cap : Set to 1 if the MICBIAS has external decoupling
> > > + capacitors attached.
> > > +
> > > +Example:
> > > +
> > > +codec: cs47l85@0 {
> >
> > Node names should be generic.
> >
> > You can swap these round if you want, so:
> >
> > cs47l85: codec@0 {
> >
> > ... is valid.
> >
> > > + compatible = "cirrus,cs47l85";
> > > + reg = <0>;
> > > +
> > > + reset-gpios = <&gpio 0>;
> > > +
> > > + MICBIAS1 {
> > > + regulator-min-microvolt = <900000>;
> > > + regulator-max-microvolt = <3300000>;
> > > + cirrus,ext-cap = <1>;
> > > + };
> > > +};
> > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > index 02995c9..d28e53f 100644
> > > --- a/MAINTAINERS
> > > +++ b/MAINTAINERS
> > > @@ -3266,7 +3266,10 @@ L: patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org
> > > T: git https://github.com/CirrusLogic/linux-drivers.git
> > > W: https://github.com/CirrusLogic/linux-drivers/wiki
> > > S: Supported
> > > +F: Documentation/devicetree/bindings/mfd/madera.txt
> > > F: include/linux/mfd/madera/*
> > > +F: drivers/mfd/madera*
> > > +F: drivers/mfd/cs47l*
> > >
> > > CLEANCACHE API
> > > M: Konrad Rzeszutek Wilk <konrad.wilk-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
> > > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> > > index ce3a918..f0f9979 100644
> > > --- a/drivers/mfd/Kconfig
> > > +++ b/drivers/mfd/Kconfig
> > > @@ -203,6 +203,29 @@ config MFD_CROS_EC_SPI
> > > response time cannot be guaranteed, we support ignoring
> > > 'pre-amble' bytes before the response actually starts.
> > >
> > > +config MFD_MADERA
> > > + bool
> > > + select REGMAP
> > > + select MFD_CORE
> > > +
> > > +config MFD_MADERA_I2C
> > > + tristate "Cirrus Logic Madera codecs with I2C"
> > > + select MFD_MADERA
> > > + select REGMAP_I2C
> > > + depends on I2C
> > > + help
> > > + Support for the Cirrus Logic Madera platform audio SoC
> > > + core functionality controlled via I2C.
> > > +
> > > +config MFD_MADERA_SPI
> > > + tristate "Cirrus Logic Madera codecs with SPI"
> > > + select MFD_MADERA
> > > + select REGMAP_SPI
> > > + depends on SPI_MASTER
> > > + help
> > > + Support for the Cirrus Logic Madera platform audio SoC
> > > + core functionality controlled via SPI.
> > > +
> > > config MFD_ASIC3
> > > bool "Compaq ASIC3"
> > > depends on GPIOLIB && ARM
> > > diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> > > index fa86dbe..c41f6c9 100644
> > > --- a/drivers/mfd/Makefile
> > > +++ b/drivers/mfd/Makefile
> > > @@ -72,6 +72,10 @@ obj-$(CONFIG_MFD_WM8350_I2C) += wm8350-i2c.o
> > > wm8994-objs := wm8994-core.o wm8994-irq.o wm8994-regmap.o
> > > obj-$(CONFIG_MFD_WM8994) += wm8994.o
> > >
> > > +obj-$(CONFIG_MFD_MADERA) += madera-core.o
> > > +obj-$(CONFIG_MFD_MADERA_I2C) += madera-i2c.o
> > > +obj-$(CONFIG_MFD_MADERA_SPI) += madera-spi.o
> > > +
> > > obj-$(CONFIG_TPS6105X) += tps6105x.o
> > > obj-$(CONFIG_TPS65010) += tps65010.o
> > > obj-$(CONFIG_TPS6507X) += tps6507x.o
> > > diff --git a/drivers/mfd/madera-core.c b/drivers/mfd/madera-core.c
> > > new file mode 100644
> > > index 0000000..ab5fe9b
> > > --- /dev/null
> > > +++ b/drivers/mfd/madera-core.c
> > > @@ -0,0 +1,689 @@
> > > +/*
> > > + * Core MFD support for Cirrus Logic Madera codecs
> > > + *
> > > + * Copyright 2015-2017 Cirrus Logic
> > > + *
> > > + * This program is free software; you can redistribute it and/or modify
> > > + * it under the terms of the GNU General Public License version 2 as
> > > + * published by the Free Software Foundation.
> > > + */
> > > +
> > > +#include <linux/device.h>
> > > +#include <linux/delay.h>
> > > +#include <linux/err.h>
> > > +#include <linux/gpio.h>
> > > +#include <linux/mfd/core.h>
> > > +#include <linux/module.h>
> > > +#include <linux/notifier.h>
> > > +#include <linux/of.h>
> > > +#include <linux/of_device.h>
> > > +#include <linux/of_gpio.h>
> > > +#include <linux/platform_device.h>
> > > +#include <linux/pm_runtime.h>
> > > +#include <linux/regmap.h>
> > > +#include <linux/regulator/consumer.h>
> > > +#include <linux/regulator/machine.h>
> > > +#include <linux/regulator/of_regulator.h>
> > > +
> > > +#include <linux/mfd/madera/core.h>
> > > +#include <linux/mfd/madera/registers.h>
> > > +
> > > +#include "madera.h"
> > > +
> > > +#define CS47L35_SILICON_ID 0x6360
> > > +#define CS47L85_SILICON_ID 0x6338
> > > +#define CS47L90_SILICON_ID 0x6364
> > > +
> > > +#define MADERA_32KZ_MCLK2 1
> > > +
> > > +static const char * const madera_core_supplies[] = {
> > > + "AVDD",
> > > + "DBVDD1",
> > > +};
> > > +
> > > +static const struct mfd_cell madera_ldo1_devs[] = {
> > > + { .name = "madera-ldo1", .of_compatible = "cirrus,madera-ldo1" },
> > > +};
> > > +
> > > +static const struct mfd_cell cs47l35_devs[] = {
> > > + { .name = "madera-pinctrl", .of_compatible = "cirrus,madera-pinctrl" },
> > > + { .name = "madera-irq", },
> >
> > I believe this should be "interrupt-controller".
> >
>
> I don't think that's the case. I checked other irchip drivers and they
> have no particular standard naming. At least one is called
> "something-irq", none are called "something-interrupt-controller"
>
> > irq is ambiguous.
> >
>
> I can't really see what other driver this could be confused with,
> especially as it's specified as madera-* so the alternative drivers are
> limited. Given the limited set of drivers I think it's clear enough it's
> the driver for the IRQ and a longer name doesn't add information.
>
> > Same goes for the ones below.
> >
>
> Ditto. madera-micsupp will be replaced by the existing arizona-micsupp.
> Most gpio drivers are called "something-gpio". Extcon is the name of a
> driver subsystem so should be sufficiently clear. Likewise madera-codec.
I meant just the "-irq" entries.
... but I'm not 100% convinced that calling it "-irq" a terrible idea,
just that "irq-controller" or "interrupt-controller" would be better.
Either way, it's not a blocking point.
> > > + { .name = "madera-micsupp", .of_compatible = "cirrus,madera-micsupp" },
> > > + { .name = "madera-gpio", .of_compatible = "cirrus,madera-gpio" },
> > > + { .name = "madera-extcon", .of_compatible = "cirrus,madera-extcon" },
> > > + { .name = "cs47l35-codec", .of_compatible = "cirrus,cs47l35-codec" },
> > > + { .name = "madera-haptics", .of_compatible = "cirrus,madera-haptics" },
> > > +};
> > > +
> > > +static const struct mfd_cell cs47l85_devs[] = {
> > > + { .name = "madera-pinctrl", .of_compatible = "cirrus,madera-pinctrl" },
> > > + { .name = "madera-irq", },
> > > + { .name = "madera-micsupp", .of_compatible = "cirrus,madera-micsupp" },
> > > + { .name = "madera-gpio", .of_compatible = "cirrus,madera-gpio" },
> > > + { .name = "madera-extcon", .of_compatible = "cirrus,madera-extcon" },
> > > + { .name = "cs47l85-codec", .of_compatible = "cirrus,cs47l85-codec" },
> > > + { .name = "madera-haptics", .of_compatible = "cirrus,madera-haptics" },
> > > +};
> > > +
> > > +static const struct mfd_cell cs47l90_devs[] = {
> > > + { .name = "madera-pinctrl", .of_compatible = "cirrus,madera-pinctrl" },
> > > + { .name = "madera-irq", },
> > > + { .name = "madera-micsupp", .of_compatible = "cirrus,madera-micsupp" },
> > > + { .name = "madera-gpio", .of_compatible = "cirrus,madera-gpio" },
> > > + { .name = "madera-extcon", .of_compatible = "cirrus,madera-extcon" },
> > > + { .name = "cs47l90-codec", .of_compatible = "cirrus,cs47l90-codec" },
> > > + { .name = "madera-haptics", .of_compatible = "cirrus,madera-haptics" },
> > > +};
> > > +
> > > +const char *madera_name_from_type(enum madera_type type)
> > > +{
> > > + switch (type) {
> > > + case CS47L35:
> > > + return "CS47L35";
> > > + case CS47L85:
> > > + return "CS47L85";
> > > + case CS47L90:
> > > + return "CS47L90";
> > > + case CS47L91:
> > > + return "CS47L91";
> > > + case WM1840:
> > > + return "WM1840";
> > > + default:
> > > + return "Unknown";
> > > + }
> > > +}
> > > +EXPORT_SYMBOL_GPL(madera_name_from_type);
> > > +
> > > +#define MADERA_BOOT_POLL_MAX_INTERVAL_US 5000
> > > +#define MADERA_BOOT_POLL_TIMEOUT_US 25000
> > > +
> > > +static int madera_wait_for_boot(struct madera *madera)
> > > +{
> > > + unsigned int val;
> > > + int ret;
> > > +
> > > + /*
> > > + * We can't use an interrupt as we need to runtime resume to do so,
> > > + * so we poll the status bit. This won't race with the interrupt
> > > + * handler because it will be blocked on runtime resume.
> > > + */
> > > + ret = regmap_read_poll_timeout(madera->regmap,
> > > + MADERA_IRQ1_RAW_STATUS_1,
> > > + val,
> > > + (val & MADERA_BOOT_DONE_STS1),
> > > + MADERA_BOOT_POLL_MAX_INTERVAL_US,
> > > + MADERA_BOOT_POLL_TIMEOUT_US);
> > > + /*
> > > + * BOOT_DONE defaults to unmasked on boot so we must ack it.
> > > + * Do this unconditionally to avoid interrupt storms
> > > + */
> > > + regmap_write(madera->regmap, MADERA_IRQ1_STATUS_1,
> > > + MADERA_BOOT_DONE_EINT1);
> > > +
> > > + if (ret)
> > > + dev_err(madera->dev, "Polling BOOT_DONE_STS failed: %d\n", ret);
> >
> > Why isn't this under the call to regmap_read_poll_timeout()?
> >
>
> It was intended to make it clear that we must ack the BOOT_DONE now no
> matter what and to avoid the potential with them the other way around of
> someone adding more code in the if (or just a ret) and so accidentally
> failing to do the ack. I could swap them but I think I prefer keeping
> them this way and changing the comment to say this.
Okay.
I'm going to assume that we are in agreement for all points that you
did not answer (which is good). I look forward to the next version.
--
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: Applied "ASoC: Add Odroid sound DT bindings documentation" to the asoc tree
From: Mark Brown @ 2017-04-24 9:57 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Sylwester Nawrocki, linux-samsung-soc, linux-clk, dri-devel,
alsa-devel, devicetree, jy0922.shim, Javier Martinez Canillas,
Bartłomiej Żołnierkiewicz, Seung Woo Kim, Inki Dae,
Chanwoo Choi, robh+dt
In-Reply-To: <20170421180710.6gdaosnk2gn2leoo@kozik-lap>
[-- Attachment #1: Type: text/plain, Size: 368 bytes --]
On Fri, Apr 21, 2017 at 08:07:10PM +0200, Krzysztof Kozlowski wrote:
> Mutt is complaining that your key used to sign the mails has expired:
> gpg: Note: This key has expired!
> Primary key fingerprint: 3F25 68AA C269 98F9 E813 A1C5 C3F4 36CA 30F5 D8EB
> Subkey fingerprint: ADE6 68AA 6757 18B5 9FE2 9FEA 24D6 8B72 5D54 87D0
gpg --refresh-keys should fix that.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH V2] clk: hi6220: Add the hi655x's pmic clock
From: Daniel Lezcano @ 2017-04-24 9:43 UTC (permalink / raw)
To: Lee Jones
Cc: sboyd, mturquette, xuwei5, devicetree, linux-kernel,
linux-arm-kernel, linux-clk
In-Reply-To: <20170424093154.ffo7zsr66a2yjy74@dell>
On Mon, Apr 24, 2017 at 10:31:54AM +0100, Lee Jones wrote:
> On Sat, 08 Apr 2017, Daniel Lezcano wrote:
>
> > The hi655x multi function device is a PMIC providing regulators.
> >
> > The PMIC also provides a clock for the WiFi and the Bluetooth, let's implement
> > this clock in order to add it in the hi655x MFD and allow proper wireless
> > initialization.
> >
> > Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> > ---
> >
> > Changelog:
> >
> > V2:
> > - Added COMPILE_TEST option, compiled on x86
> > - Removed useless parenthesis
> > - Used of_clk_hw_simple_get() instead of deref dance
> > - Do bailout if the clock-names is not specified
> > - Rollback on error
> > - Folded mfd line change and binding
> > - Added #clock-cells binding documentation
> > - Added #clock-cells in the DT
> >
> > V1: initial post
> > ---
>
> ??
>
> > ---
>
> I'm unsure if this as been mentioned before, but bundling;
> driver & architecture changes and documentation into a single patch is
> very seldom a good idea. In this case, you should split this into at
> least 3, perhaps 4 patches.
>
> > .../devicetree/bindings/mfd/hisilicon,hi655x.txt | 6 +
>
> Patch 1
>
> > arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 1 +
>
> Patch 2
>
> > drivers/clk/Kconfig | 8 ++
> > drivers/clk/Makefile | 1 +
> > drivers/clk/clk-hi655x.c | 140 +++++++++++++++++++++
>
> Patch 3
>
> > drivers/mfd/hi655x-pmic.c | 3 +-
>
> Patch 4
>
> [...]
Yep. Will do that next time.
Thanks.
-- Daniel
^ permalink raw reply
* Re: [PATCH V2] clk: hi6220: Add the hi655x's pmic clock
From: Lee Jones @ 2017-04-24 9:31 UTC (permalink / raw)
To: Daniel Lezcano
Cc: sboyd, mturquette, xuwei5, devicetree, linux-kernel,
linux-arm-kernel, linux-clk
In-Reply-To: <1491683412-12237-1-git-send-email-daniel.lezcano@linaro.org>
On Sat, 08 Apr 2017, Daniel Lezcano wrote:
> The hi655x multi function device is a PMIC providing regulators.
>
> The PMIC also provides a clock for the WiFi and the Bluetooth, let's implement
> this clock in order to add it in the hi655x MFD and allow proper wireless
> initialization.
>
> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> ---
>
> Changelog:
>
> V2:
> - Added COMPILE_TEST option, compiled on x86
> - Removed useless parenthesis
> - Used of_clk_hw_simple_get() instead of deref dance
> - Do bailout if the clock-names is not specified
> - Rollback on error
> - Folded mfd line change and binding
> - Added #clock-cells binding documentation
> - Added #clock-cells in the DT
>
> V1: initial post
> ---
??
> ---
I'm unsure if this as been mentioned before, but bundling;
driver & architecture changes and documentation into a single patch is
very seldom a good idea. In this case, you should split this into at
least 3, perhaps 4 patches.
> .../devicetree/bindings/mfd/hisilicon,hi655x.txt | 6 +
Patch 1
> arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 1 +
Patch 2
> drivers/clk/Kconfig | 8 ++
> drivers/clk/Makefile | 1 +
> drivers/clk/clk-hi655x.c | 140 +++++++++++++++++++++
Patch 3
> drivers/mfd/hi655x-pmic.c | 3 +-
Patch 4
[...]
> 6 files changed, 158 insertions(+), 1 deletion(-)
> create mode 100644 drivers/clk/clk-hi655x.c
>
> diff --git a/Documentation/devicetree/bindings/mfd/hisilicon,hi655x.txt b/Documentation/devicetree/bindings/mfd/hisilicon,hi655x.txt
> index 0548569..194e2a9fd 100644
> --- a/Documentation/devicetree/bindings/mfd/hisilicon,hi655x.txt
> +++ b/Documentation/devicetree/bindings/mfd/hisilicon,hi655x.txt
> @@ -16,6 +16,11 @@ Required properties:
> - reg: Base address of PMIC on Hi6220 SoC.
> - interrupt-controller: Hi655x has internal IRQs (has own IRQ domain).
> - pmic-gpios: The GPIO used by PMIC IRQ.
> +- #clock-cells: From common clock binding; shall be set to 0
> +
> +Optional properties:
> +- clock-output-names: From common clock binding to override the
> + default output clock name
>
> Example:
> pmic: pmic@f8000000 {
> @@ -24,4 +29,5 @@ Example:
> interrupt-controller;
> #interrupt-cells = <2>;
> pmic-gpios = <&gpio1 2 GPIO_ACTIVE_HIGH>;
> + clock-cells = <0>;
> }
> diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
> index dba3c13..bb9afb1 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
> +++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
> @@ -328,6 +328,7 @@
> interrupt-controller;
> #interrupt-cells = <2>;
> pmic-gpios = <&gpio1 2 GPIO_ACTIVE_HIGH>;
> + #clock-cells = <0>;
>
> regulators {
> ldo2: LDO2 {
> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> index 9356ab4..36cfea3 100644
> --- a/drivers/clk/Kconfig
> +++ b/drivers/clk/Kconfig
> @@ -47,6 +47,14 @@ config COMMON_CLK_RK808
> clocked at 32KHz each. Clkout1 is always on, Clkout2 can off
> by control register.
>
> +config COMMON_CLK_HI655X
> + tristate "Clock driver for Hi655x"
> + depends on MFD_HI655X_PMIC || COMPILE_TEST
> + ---help---
> + This driver supports the hi655x PMIC clock. This
> + multi-function device has one fixed-rate oscillator, clocked
> + at 32KHz.
> +
> config COMMON_CLK_SCPI
> tristate "Clock driver controlled via SCPI interface"
> depends on ARM_SCPI_PROTOCOL || COMPILE_TEST
> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index 92c12b8..c19983a 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -36,6 +36,7 @@ obj-$(CONFIG_COMMON_CLK_PALMAS) += clk-palmas.o
> obj-$(CONFIG_COMMON_CLK_PWM) += clk-pwm.o
> obj-$(CONFIG_CLK_QORIQ) += clk-qoriq.o
> obj-$(CONFIG_COMMON_CLK_RK808) += clk-rk808.o
> +obj-$(CONFIG_COMMON_CLK_HI655X) += clk-hi655x.o
> obj-$(CONFIG_COMMON_CLK_S2MPS11) += clk-s2mps11.o
> obj-$(CONFIG_COMMON_CLK_SCPI) += clk-scpi.o
> obj-$(CONFIG_COMMON_CLK_SI5351) += clk-si5351.o
> diff --git a/drivers/clk/clk-hi655x.c b/drivers/clk/clk-hi655x.c
> new file mode 100644
> index 0000000..b2bea32
> --- /dev/null
> +++ b/drivers/clk/clk-hi655x.c
> @@ -0,0 +1,140 @@
> +/*
> + * Clock driver for Hi655x
> + *
> + * Copyright (c) 2016, Linaro Ltd.
> + *
> + * Author: Daniel Lezcano <daniel.lezcano@linaro.org>
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
> + * more details.
> + */
> +#include <linux/clk-provider.h>
> +#include <linux/clkdev.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +#include <linux/slab.h>
> +#include <linux/mfd/core.h>
> +#include <linux/mfd/hi655x-pmic.h>
> +
> +#define HI655X_CLK_BASE HI655X_BUS_ADDR(0x1c)
> +#define HI655X_CLK_SET BIT(6)
> +
> +struct hi655x_clk {
> + struct hi655x_pmic *hi655x;
> + struct clk_hw clk_hw;
> +};
> +
> +static unsigned long hi655x_clk_recalc_rate(struct clk_hw *hw,
> + unsigned long parent_rate)
> +{
> + return 32768;
> +}
> +
> +static int hi655x_clk_enable(struct clk_hw *hw, bool enable)
> +{
> + struct hi655x_clk *hi655x_clk =
> + container_of(hw, struct hi655x_clk, clk_hw);
> +
> + struct hi655x_pmic *hi655x = hi655x_clk->hi655x;
> +
> + return regmap_update_bits(hi655x->regmap, HI655X_CLK_BASE,
> + HI655X_CLK_SET, enable ? HI655X_CLK_SET : 0);
> +}
> +
> +static int hi655x_clk_prepare(struct clk_hw *hw)
> +{
> + return hi655x_clk_enable(hw, true);
> +}
> +
> +static void hi655x_clk_unprepare(struct clk_hw *hw)
> +{
> + hi655x_clk_enable(hw, false);
> +}
> +
> +static int hi655x_clk_is_prepared(struct clk_hw *hw)
> +{
> + struct hi655x_clk *hi655x_clk =
> + container_of(hw, struct hi655x_clk, clk_hw);
> + struct hi655x_pmic *hi655x = hi655x_clk->hi655x;
> + int ret;
> + uint32_t val;
> +
> + ret = regmap_read(hi655x->regmap, HI655X_CLK_BASE, &val);
> + if (ret < 0)
> + return ret;
> +
> + return val & HI655X_CLK_BASE;
> +}
> +
> +static const struct clk_ops hi655x_clk_ops = {
> + .prepare = hi655x_clk_prepare,
> + .unprepare = hi655x_clk_unprepare,
> + .is_prepared = hi655x_clk_is_prepared,
> + .recalc_rate = hi655x_clk_recalc_rate,
> +};
> +
> +static int hi655x_clk_probe(struct platform_device *pdev)
> +{
> + struct device *parent = pdev->dev.parent;
> + struct hi655x_pmic *hi655x = dev_get_drvdata(parent);
> + struct clk_init_data *hi655x_clk_init;
> + struct hi655x_clk *hi655x_clk;
> + const char *clk_name = "hi655x-clk";
> + int ret;
> +
> + hi655x_clk = devm_kzalloc(&pdev->dev, sizeof(*hi655x_clk), GFP_KERNEL);
> + if (!hi655x_clk)
> + return -ENOMEM;
> +
> + hi655x_clk_init = devm_kzalloc(&pdev->dev, sizeof(*hi655x_clk_init),
> + GFP_KERNEL);
> + if (!hi655x_clk_init)
> + return -ENOMEM;
> +
> + of_property_read_string_index(parent->of_node, "clock-output-names",
> + 0, &clk_name);
> +
> + hi655x_clk_init->name = clk_name;
> + hi655x_clk_init->ops = &hi655x_clk_ops;
> +
> + hi655x_clk->clk_hw.init = hi655x_clk_init;
> + hi655x_clk->hi655x = hi655x;
> +
> + platform_set_drvdata(pdev, hi655x_clk);
> +
> + ret = devm_clk_hw_register(&pdev->dev, &hi655x_clk->clk_hw);
> + if (ret)
> + return ret;
> +
> + ret = of_clk_add_hw_provider(parent->of_node, of_clk_hw_simple_get,
> + &hi655x_clk->clk_hw);
> + if (ret)
> + return ret;
> +
> + ret = clk_hw_register_clkdev(&hi655x_clk->clk_hw, clk_name, NULL);
> + if (ret)
> + of_clk_del_provider(parent->of_node);
> +
> + return ret;
> +}
> +
> +static struct platform_driver hi655x_clk_driver = {
> + .probe = hi655x_clk_probe,
> + .driver = {
> + .name = "hi655x-clk",
> + },
> +};
> +
> +module_platform_driver(hi655x_clk_driver);
> +
> +MODULE_DESCRIPTION("Clk driver for the hi655x series PMICs");
> +MODULE_AUTHOR("Daniel Lezcano <daniel.lezcano@linaro.org>");
> +MODULE_LICENSE("GPL");
> +MODULE_ALIAS("platform:hi655x-clk");
> diff --git a/drivers/mfd/hi655x-pmic.c b/drivers/mfd/hi655x-pmic.c
> index ba706ad..c37ccbf 100644
> --- a/drivers/mfd/hi655x-pmic.c
> +++ b/drivers/mfd/hi655x-pmic.c
> @@ -77,7 +77,8 @@
> .num_resources = ARRAY_SIZE(pwrkey_resources),
> .resources = &pwrkey_resources[0],
> },
> - { .name = "hi655x-regulator", },
> + { .name = "hi655x-regulator", },
> + { .name = "hi655x-clk", },
> };
>
> static void hi655x_local_irq_clear(struct regmap *map)
--
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/7] pinctrl: dt-bindings: Add documentation for Armada 37xx pin controllers
From: Linus Walleij @ 2017-04-24 9:29 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Jason Cooper,
Andrew Lunn, Sebastian Hesselbarth, Thomas Petazzoni,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Nadav Haklai, Victor Gu, Marcin Wojtas, Wilson Ding, Hua Jing,
Neta Zur Hershkovits
In-Reply-To: <941d03c9a3bdfd5e789aada29b35184ec9fed9fe.1491405475.git-series.gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On Wed, Apr 5, 2017 at 5:18 PM, Gregory CLEMENT
<gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> Document the device tree binding for the pin controllers found on the
> Armada 37xx SoCs.
>
> Update the binding documention of the xtal clk which is a subnode of this
> syscon node.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Patch applied, fixed up Rob's comment and added his ACK in the process.
Yours,
Linus Walleij
--
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 v6 4/4] ARM: dts: armada-xp: Use pwm-fan rather than gpio-fan
From: Linus Walleij @ 2017-04-24 9:20 UTC (permalink / raw)
To: Ralph Sennhauser
Cc: linux-gpio@vger.kernel.org, Andrew Lunn, Thierry Reding,
Alexandre Courbot, Rob Herring, Mark Rutland, Jason Cooper,
Gregory Clement, Sebastian Hesselbarth, Russell King,
linux-pwm@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20170414154056.32055-5-ralph.sennhauser@gmail.com>
On Fri, Apr 14, 2017 at 5:40 PM, Ralph Sennhauser
<ralph.sennhauser@gmail.com> wrote:
> From: Andrew Lunn <andrew@lunn.ch>
>
> The mvebu GPIO driver can also perform PWM on some pins. Use the pwm-fan
> driver to control the fan of the WRT1900AC, giving us finer grained control
> over its speed and hence noise.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> URL: https://patchwork.ozlabs.org/patch/427291/
> [Ralph Sennhauser: drop flags paramter from pwms, no longer used]
> Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
> Tested-by: Andrew Lunn <andrew@lunn.ch>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Please funnel this through ARM SoC.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v6 3/4] ARM: mvebu: Enable SENSORS_PWM_FAN in defconfig
From: Linus Walleij @ 2017-04-24 9:20 UTC (permalink / raw)
To: Ralph Sennhauser
Cc: linux-gpio@vger.kernel.org, Andrew Lunn, Thierry Reding,
Alexandre Courbot, Rob Herring, Mark Rutland, Jason Cooper,
Gregory Clement, Sebastian Hesselbarth, Russell King,
linux-pwm@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20170414154056.32055-4-ralph.sennhauser@gmail.com>
On Fri, Apr 14, 2017 at 5:40 PM, Ralph Sennhauser
<ralph.sennhauser@gmail.com> wrote:
> From: Andrew Lunn <andrew@lunn.ch>
>
> Now that the GPIO driver also supports PWM operation, enable the PWM
> framework and fan driver in mvebu_v7_defconfig.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> URL: https://patchwork.ozlabs.org/patch/427297/
> [Ralph Sennhauser: add fan driver to defconfig]
> Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
> Tested-by: Andrew Lunn <andrew@lunn.ch>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Please funnel this through ARM SoC.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v6 2/4] ARM: dts: mvebu: Add PWM properties to .dtsi files
From: Linus Walleij @ 2017-04-24 9:19 UTC (permalink / raw)
To: Ralph Sennhauser
Cc: linux-gpio@vger.kernel.org, Andrew Lunn, Thierry Reding,
Alexandre Courbot, Rob Herring, Mark Rutland, Jason Cooper,
Gregory Clement, Sebastian Hesselbarth, Russell King,
linux-pwm@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20170414154056.32055-3-ralph.sennhauser@gmail.com>
On Fri, Apr 14, 2017 at 5:40 PM, Ralph Sennhauser
<ralph.sennhauser@gmail.com> wrote:
> From: Andrew Lunn <andrew@lunn.ch>
>
> Add properties to the GPIO nodes to allow them to be also used as PWM
> lines.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> URL: https://patchwork.ozlabs.org/patch/427294/
> [Ralph Sennhauser: Add new compatible string marvell,armada-370-xp-gpio]
> Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
> Tested-by: Andrew Lunn <andrew@lunn.ch>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Please funnel this through ARM SoC.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v6 1/4] gpio: mvebu: Add limited PWM support
From: Linus Walleij @ 2017-04-24 9:18 UTC (permalink / raw)
To: Ralph Sennhauser
Cc: linux-gpio@vger.kernel.org, Andrew Lunn, Thierry Reding,
Alexandre Courbot, Rob Herring, Mark Rutland, Jason Cooper,
Gregory Clement, Sebastian Hesselbarth, Russell King,
linux-pwm@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20170414154056.32055-2-ralph.sennhauser@gmail.com>
On Fri, Apr 14, 2017 at 5:40 PM, Ralph Sennhauser
<ralph.sennhauser@gmail.com> wrote:
> From: Andrew Lunn <andrew@lunn.ch>
>
> Armada 370/XP devices can 'blink' GPIO lines with a configurable on
> and off period. This can be modelled as a PWM.
>
> However, there are only two sets of PWM configuration registers for
> all the GPIO lines. This driver simply allows a single GPIO line per
> GPIO chip of 32 lines to be used as a PWM. Attempts to use more return
> EBUSY.
>
> Due to the interleaving of registers it is not simple to separate the
> PWM driver from the GPIO driver. Thus the GPIO driver has been
> extended with a PWM driver.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> URL: https://patchwork.ozlabs.org/patch/427287/
> URL: https://patchwork.ozlabs.org/patch/427295/
> [Ralph Sennhauser:
> * Port forward
> * Merge PWM portion into gpio-mvebu.c
> * Switch to atomic PWM API
> * Add new compatible string marvell,armada-370-xp-gpio
> * Update and merge documentation patch
> * Update MAINTAINERS]
> Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
> Tested-by: Andrew Lunn <andrew@lunn.ch>
> Acked-by: Thierry Reding <thierry.reding@gmail.com>
> Acked-by: Rob Herring <robh@kernel.org>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH V3 2/2] ARM64: dts: hi6220-hikey: Add clock binding for the pmic mfd
From: Daniel Lezcano @ 2017-04-24 9:16 UTC (permalink / raw)
To: Lee Jones
Cc: Stephen Boyd, mturquette, xuwei5, linux-kernel, linux-clk,
devicetree, linux-arm-kernel
In-Reply-To: <20170424085944.aa5dsc4g6bwm5rgi@dell>
On Mon, Apr 24, 2017 at 09:59:44AM +0100, Lee Jones wrote:
> On Sat, 22 Apr 2017, Daniel Lezcano wrote:
>
> > On 22/04/2017 04:02, Stephen Boyd wrote:
> > > On 04/17, Daniel Lezcano wrote:
> > >> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> > >> ---
> > >> Documentation/devicetree/bindings/mfd/hisilicon,hi655x.txt | 6 ++++++
> > >> arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 1 +
> > >> 2 files changed, 7 insertions(+)
> > >>
> > >
> > > I take it this goes through arm-soc? Not sure why I'm on To:
> > > line.
> >
> > Probably it should go through Lee's tree.
>
> Unlikely.
>
> The document and the DTS change should really have gone separately,
> but to save you from having to mess around so close to the merge window:
>
> Acked-by: Lee Jones <lee.jones@linaro.org>
Thanks Lee.
Usually, I take the DT changes (including doc) with the timers changes with the
maintainer and Rob's blessing. So the DT and the driver changes are aligned in
my tree and make the submission changes easier.
I agree mixing the patches for different destinations into a single patchset is
fuzzy, I will take care next time to separate the patches.
-- Daniel
> --
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* Re: [PATCH v5 1/4] gpio: mvebu: Add limited PWM support
From: Linus Walleij @ 2017-04-24 9:15 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Andrew Lunn, Ralph Sennhauser, Thierry Reding, Mark Rutland,
Jason Cooper, Alexandre Courbot, Russell King,
linux-pwm@vger.kernel.org, linux-kernel@vger.kernel.org,
Gregory Clement, devicetree@vger.kernel.org, Rob Herring,
linux-gpio@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Sebastian Hesselbarth
In-Reply-To: <20170421111952.54978e80@free-electrons.com>
On Fri, Apr 21, 2017 at 11:19 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> I clearly don't want to block this, but I believe this is a very good
> illustration of why stable DT bindings simply don't work. We are
> realizing here that having each GPIO bank represented as a separate DT
> node doesn't work, because this blinking functionality is not per GPIO
> bank, but global to all GPIO banks.
>
> I am totally fine with compromise, and having things simple first, and
> extend them later if needed. But this stable DT binding rule makes this
> quite impossible: what is a compromise today might put you in big
> troubles tomorrow.
Really "stable bindings" I never believed in. It's just a pipe dream.
Well they might become stable when the system is "finished"
whenever that happens.
I think a better rationale is that of the IETF:
"rough consensus and running code", make deployed DTs work,
if they are not deployed, or only getting deployed together with the
kernel, changing the bindings are not a problem.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v5 09/11] ARM: dts: sun8i: add DE2 nodes for V3s SoC
From: Maxime Ripard @ 2017-04-24 9:06 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Rob Herring, Chen-Yu Tsai, Jernej Skrabec,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170423103754.50012-10-icenowy-h8G6r0blFSE@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 343 bytes --]
On Sun, Apr 23, 2017 at 06:37:52PM +0800, Icenowy Zheng wrote:
> + tcon0_out: port@1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <1>;
> + };
> + };
> + };
> +
> +
There's one too many newline here.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 2/3] iio: adc: at91-sama5d2_adc: add hw trigger and buffer support
From: Ludovic Desroches @ 2017-04-24 9:06 UTC (permalink / raw)
To: Eugen Hristev
Cc: nicolas.ferre-UWL1GkI3JZL3oGB3hsPCZA,
alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
linux-iio-u79uwXL29TY76Z2rM5mHXA, jic23-DgEjT+Ai2ygdnm+yROfE0A,
lars-Qo5EllUWu/uELgA04lAiVw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
ludovic.desroches-UWL1GkI3JZL3oGB3hsPCZA
In-Reply-To: <1492590045-17329-3-git-send-email-eugen.hristev-UWL1GkI3JZL3oGB3hsPCZA@public.gmane.org>
On Wed, Apr 19, 2017 at 11:20:44AM +0300, Eugen Hristev wrote:
> Added support for the external hardware trigger on pin ADTRG,
> integrated the three possible edge triggers into the subsystem
> and created buffer management for data retrieval
>
> Signed-off-by: Eugen Hristev <eugen.hristev-UWL1GkI3JZL3oGB3hsPCZA@public.gmane.org>
Acked-by: Ludovic Desroches <ludovic.desroches-UWL1GkI3JZL3oGB3hsPCZA@public.gmane.org>
> ---
> drivers/iio/adc/at91-sama5d2_adc.c | 207 ++++++++++++++++++++++++++++++++++++-
> 1 file changed, 204 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iio/adc/at91-sama5d2_adc.c b/drivers/iio/adc/at91-sama5d2_adc.c
> index e10dca3..09a8c3d 100644
> --- a/drivers/iio/adc/at91-sama5d2_adc.c
> +++ b/drivers/iio/adc/at91-sama5d2_adc.c
> @@ -23,8 +23,15 @@
> #include <linux/platform_device.h>
> #include <linux/sched.h>
> #include <linux/wait.h>
> +#include <linux/slab.h>
> +
> #include <linux/iio/iio.h>
> #include <linux/iio/sysfs.h>
> +#include <linux/iio/buffer.h>
> +#include <linux/iio/trigger.h>
> +#include <linux/iio/trigger_consumer.h>
> +#include <linux/iio/triggered_buffer.h>
> +
> #include <linux/regulator/consumer.h>
>
> /* Control Register */
> @@ -132,6 +139,17 @@
> #define AT91_SAMA5D2_PRESSR 0xbc
> /* Trigger Register */
> #define AT91_SAMA5D2_TRGR 0xc0
> +/* Mask for TRGMOD field of TRGR register */
> +#define AT91_SAMA5D2_TRGR_TRGMOD_MASK GENMASK(2, 0)
> +/* No trigger, only software trigger can start conversions */
> +#define AT91_SAMA5D2_TRGR_TRGMOD_NO_TRIGGER 0
> +/* Trigger Mode external trigger rising edge */
> +#define AT91_SAMA5D2_TRGR_TRGMOD_EXT_TRIG_RISE 1
> +/* Trigger Mode external trigger falling edge */
> +#define AT91_SAMA5D2_TRGR_TRGMOD_EXT_TRIG_FALL 2
> +/* Trigger Mode external trigger any edge */
> +#define AT91_SAMA5D2_TRGR_TRGMOD_EXT_TRIG_ANY 3
> +
> /* Correction Select Register */
> #define AT91_SAMA5D2_COSR 0xd0
> /* Correction Value Register */
> @@ -145,14 +163,20 @@
> /* Version Register */
> #define AT91_SAMA5D2_VERSION 0xfc
>
> +#define AT91_SAMA5D2_HW_TRIG_CNT 3
> +#define AT91_SAMA5D2_SINGLE_CHAN_CNT 12
> +#define AT91_SAMA5D2_DIFF_CHAN_CNT 6
> +
> #define AT91_SAMA5D2_CHAN_SINGLE(num, addr) \
> { \
> .type = IIO_VOLTAGE, \
> .channel = num, \
> .address = addr, \
> + .scan_index = num, \
> .scan_type = { \
> .sign = 'u', \
> .realbits = 12, \
> + .storagebits = 16, \
> }, \
> .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
> .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
> @@ -168,9 +192,11 @@
> .channel = num, \
> .channel2 = num2, \
> .address = addr, \
> + .scan_index = num + AT91_SAMA5D2_SINGLE_CHAN_CNT, \
> .scan_type = { \
> .sign = 's', \
> .realbits = 12, \
> + .storagebits = 16, \
> }, \
> .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
> .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
> @@ -188,18 +214,26 @@ struct at91_adc_soc_info {
> unsigned max_sample_rate;
> };
>
> +struct at91_adc_trigger {
> + char *name;
> + unsigned int trgmod_value;
> +};
> +
> struct at91_adc_state {
> void __iomem *base;
> int irq;
> struct clk *per_clk;
> struct regulator *reg;
> struct regulator *vref;
> + u16 *buffer;
> int vref_uv;
> const struct iio_chan_spec *chan;
> bool conversion_done;
> u32 conversion_value;
> struct at91_adc_soc_info soc_info;
> wait_queue_head_t wq_data_available;
> + struct iio_trigger **trig;
> + const struct at91_adc_trigger *trigger_list;
> /*
> * lock to prevent concurrent 'single conversion' requests through
> * sysfs.
> @@ -207,6 +241,21 @@ struct at91_adc_state {
> struct mutex lock;
> };
>
> +static const struct at91_adc_trigger at91_adc_trigger_list[] = {
> + {
> + .name = "external-rising",
> + .trgmod_value = AT91_SAMA5D2_TRGR_TRGMOD_EXT_TRIG_RISE,
> + },
> + {
> + .name = "external-falling",
> + .trgmod_value = AT91_SAMA5D2_TRGR_TRGMOD_EXT_TRIG_FALL,
> + },
> + {
> + .name = "external-any",
> + .trgmod_value = AT91_SAMA5D2_TRGR_TRGMOD_EXT_TRIG_ANY,
> + },
> +};
> +
> static const struct iio_chan_spec at91_adc_channels[] = {
> AT91_SAMA5D2_CHAN_SINGLE(0, 0x50),
> AT91_SAMA5D2_CHAN_SINGLE(1, 0x54),
> @@ -226,8 +275,141 @@ static const struct iio_chan_spec at91_adc_channels[] = {
> AT91_SAMA5D2_CHAN_DIFF(6, 7, 0x68),
> AT91_SAMA5D2_CHAN_DIFF(8, 9, 0x70),
> AT91_SAMA5D2_CHAN_DIFF(10, 11, 0x78),
> + IIO_CHAN_SOFT_TIMESTAMP(AT91_SAMA5D2_SINGLE_CHAN_CNT
> + + AT91_SAMA5D2_DIFF_CHAN_CNT + 1),
> };
>
> +static int at91_adc_configure_trigger(struct iio_trigger *trig, bool state)
> +{
> + struct iio_dev *indio = iio_trigger_get_drvdata(trig);
> + struct at91_adc_state *st = iio_priv(indio);
> + u32 status = at91_adc_readl(st, AT91_SAMA5D2_TRGR);
> + u8 bit;
> + int i;
> +
> + /* clear TRGMOD */
> + status &= ~AT91_SAMA5D2_TRGR_TRGMOD_MASK;
> +
> + /* if we are disabling the trigger, it's enough to clear TRGMOD */
> + if (!state) {
> + at91_adc_writel(st, AT91_SAMA5D2_TRGR, status);
> + kfree(st->buffer);
> + return 0;
> + }
> +
> + st->buffer = kmalloc(indio->scan_bytes, GFP_KERNEL);
> + if (!st->buffer)
> + return -ENOMEM;
> +
> + for (i = 0; i < AT91_SAMA5D2_HW_TRIG_CNT; i++) {
> + if (!strstr(trig->name, st->trigger_list[i].name)) {
> + status |= st->trigger_list[i].trgmod_value;
> + break;
> + }
> + }
> +
> + /* setup hw trigger */
> + at91_adc_writel(st, AT91_SAMA5D2_TRGR, status);
> +
> + for_each_set_bit(bit, indio->active_scan_mask, indio->num_channels) {
> + struct iio_chan_spec const *chan = indio->channels + bit;
> +
> + at91_adc_writel(st, AT91_SAMA5D2_CHER, BIT(chan->channel));
> + at91_adc_writel(st, AT91_SAMA5D2_IER, BIT(chan->channel));
> + }
> +
> + return 0;
> +}
> +
> +static const struct iio_trigger_ops at91_adc_trigger_ops = {
> + .owner = THIS_MODULE,
> + .set_trigger_state = &at91_adc_configure_trigger,
> +};
> +
> +static struct iio_trigger *at91_adc_allocate_trigger(struct iio_dev *indio,
> + char *trigger_name)
> +{
> + struct iio_trigger *trig;
> + int ret;
> +
> + trig = devm_iio_trigger_alloc(&indio->dev, "%s-dev%d-%s", indio->name,
> + indio->id, trigger_name);
> + if (!trig)
> + return NULL;
> +
> + trig->dev.parent = indio->dev.parent;
> + iio_trigger_set_drvdata(trig, indio);
> + trig->ops = &at91_adc_trigger_ops;
> +
> + ret = devm_iio_trigger_register(&indio->dev, trig);
> +
> + if (ret)
> + return NULL;
> +
> + return trig;
> +}
> +
> +static int at91_adc_trigger_init(struct iio_dev *indio)
> +{
> + struct at91_adc_state *st = iio_priv(indio);
> + int i;
> +
> + st->trig = devm_kzalloc(&indio->dev,
> + AT91_SAMA5D2_HW_TRIG_CNT * sizeof(*st->trig),
> + GFP_KERNEL);
> +
> + if (!st->trig) {
> + dev_err(&indio->dev, "could not allocate trig list memory\n");
> + return -ENOMEM;
> + }
> +
> + for (i = 0; i < AT91_SAMA5D2_HW_TRIG_CNT; i++) {
> + st->trig[i] = at91_adc_allocate_trigger(indio,
> + st->trigger_list[i].name);
> + if (!st->trig[i]) {
> + dev_err(&indio->dev,
> + "could not allocate trigger %d\n", i);
> + return -ENOMEM;
> + }
> + }
> +
> + return 0;
> +}
> +
> +static irqreturn_t at91_adc_trigger_handler(int irq, void *p)
> +{
> + struct iio_poll_func *pf = p;
> + struct iio_dev *indio = pf->indio_dev;
> + struct at91_adc_state *st = iio_priv(indio);
> + int i = 0;
> + u8 bit;
> +
> + for_each_set_bit(bit, indio->active_scan_mask, indio->num_channels) {
> + struct iio_chan_spec const *chan = indio->channels + bit;
> +
> + st->buffer[i] = at91_adc_readl(st, chan->address);
> + i++;
> + }
> +
> + iio_push_to_buffers_with_timestamp(indio, st->buffer, pf->timestamp);
> +
> + iio_trigger_notify_done(indio->trig);
> +
> + /* Needed to ACK the DRDY interruption */
> + at91_adc_readl(st, AT91_SAMA5D2_LCDR);
> +
> + enable_irq(st->irq);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static int at91_adc_buffer_init(struct iio_dev *indio)
> +{
> + return devm_iio_triggered_buffer_setup(&indio->dev, indio,
> + &iio_pollfunc_store_time,
> + &at91_adc_trigger_handler, NULL);
> +}
> +
> static unsigned at91_adc_startup_time(unsigned startup_time_min,
> unsigned adc_clk_khz)
> {
> @@ -293,14 +475,19 @@ static irqreturn_t at91_adc_interrupt(int irq, void *private)
> u32 status = at91_adc_readl(st, AT91_SAMA5D2_ISR);
> u32 imr = at91_adc_readl(st, AT91_SAMA5D2_IMR);
>
> - if (status & imr) {
> + if (!(status & imr))
> + return IRQ_NONE;
> +
> + if (iio_buffer_enabled(indio)) {
> + disable_irq_nosync(irq);
> + iio_trigger_poll(indio->trig);
> + } else {
> st->conversion_value = at91_adc_readl(st, st->chan->address);
> st->conversion_done = true;
> wake_up_interruptible(&st->wq_data_available);
> - return IRQ_HANDLED;
> }
>
> - return IRQ_NONE;
> + return IRQ_HANDLED;
> }
>
> static int at91_adc_read_raw(struct iio_dev *indio_dev,
> @@ -406,6 +593,8 @@ static int at91_adc_probe(struct platform_device *pdev)
>
> st = iio_priv(indio_dev);
>
> + st->trigger_list = at91_adc_trigger_list;
> +
> ret = of_property_read_u32(pdev->dev.of_node,
> "atmel,min-sample-rate-hz",
> &st->soc_info.min_sample_rate);
> @@ -499,6 +688,18 @@ static int at91_adc_probe(struct platform_device *pdev)
>
> platform_set_drvdata(pdev, indio_dev);
>
> + ret = at91_adc_buffer_init(indio_dev);
> + if (ret < 0) {
> + dev_err(&pdev->dev, "couldn't initialize the buffer.\n");
> + goto per_clk_disable_unprepare;
> + }
> +
> + ret = at91_adc_trigger_init(indio_dev);
> + if (ret < 0) {
> + dev_err(&pdev->dev, "couldn't setup the triggers.\n");
> + goto per_clk_disable_unprepare;
> + }
> +
> ret = iio_device_register(indio_dev);
> if (ret < 0)
> goto per_clk_disable_unprepare;
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH v5 05/11] drm/sun4i: abstract a engine type
From: Maxime Ripard @ 2017-04-24 9:05 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Rob Herring, Chen-Yu Tsai, Jernej Skrabec,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170423103754.50012-6-icenowy-h8G6r0blFSE@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1440 bytes --]
Hi,
Thanks a lot for that work.
On Sun, Apr 23, 2017 at 06:37:48PM +0800, Icenowy Zheng wrote:
> As we are going to add support for the Allwinner DE2 engine in sun4i-drm
> driver, we will finally have two types of display engines -- the DE1
> backend and the DE2 mixer. They both do some display blending and feed
> graphics data to TCON, so I choose to call them both "engine" here.
>
> Abstract the engine type to a new struct with an ops struct, which contains
> functions that should be called outside the engine-specified code (in
> TCON, CRTC or TV Encoder code).
>
> A dedicated Kconfig option is also added to control whether
> sun4i-backend-specified code (sun4i_backend.c and sun4i_layer.c) should
> be built. As we removed the codes in CRTC code that directly call the
> layer code, we can now extract the layer part and combine it with the
> backend part into a new module, sun4i-backend.ko.
While the code itself is good now, the patch mixes a few things that
would be better to be split in separate patches. I think it would be
better if you had patches organized like this:
- Abstract the engine type by create the sunxi_engine structure and
fixing all the callers.
- Move the layers and backend files in the same module, and remove
the now useless EXPORT_SYMBOLS.
- Create a Kconfig option.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 1/3] ARM: dts: at91: sama5d2_xplained: enable ADTRG pin
From: Ludovic Desroches @ 2017-04-24 9:04 UTC (permalink / raw)
To: Eugen Hristev
Cc: devicetree, lars, linux-iio, linux-kernel, ludovic.desroches,
alexandre.belloni, linux-arm-kernel, jic23
In-Reply-To: <1492590045-17329-2-git-send-email-eugen.hristev@microchip.com>
On Wed, Apr 19, 2017 at 11:20:43AM +0300, Eugen Hristev wrote:
> Enable pinctrl for ADTRG pin (PD31) for ADC hardware trigger support.
>
> Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
> ---
> arch/arm/boot/dts/at91-sama5d2_xplained.dts | 16 +++++++++++++++-
> 1 file changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/at91-sama5d2_xplained.dts b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
> index 0bef9e0..04754b1 100644
> --- a/arch/arm/boot/dts/at91-sama5d2_xplained.dts
> +++ b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
> @@ -303,7 +303,7 @@
> vddana-supply = <&vdd_3v3_lp_reg>;
> vref-supply = <&vdd_3v3_lp_reg>;
> pinctrl-names = "default";
> - pinctrl-0 = <&pinctrl_adc_default>;
> + pinctrl-0 = <&pinctrl_adc_default &pinctrl_adtrg_default>;
> status = "okay";
> };
>
> @@ -322,6 +322,20 @@
> bias-disable;
> };
>
> + /*
> + * The ADTRG pin can work on any edge type.
> + * In here it's being pulled up, so need to
> + * connect it to ground to get an edge e.g.
> + * Trigger can be configured on falling, rise
> + * or any edge, and the pull-up can be changed
> + * to pull-down or left floating according to
> + * needs.
> + */
> + pinctrl_adtrg_default: adtrg_default {
> + pinmux = <PIN_PD31__ADTRG>;
> + bias-pull-up;
> + };
> +
> pinctrl_charger_chglev: charger_chglev {
> pinmux = <PIN_PA12__GPIO>;
> bias-disable;
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH] arm64: dts: r8a7795: update PFC node name to pin-controller
From: Geert Uytterhoeven @ 2017-04-24 9:03 UTC (permalink / raw)
To: Simon Horman
Cc: Linux-Renesas, linux-arm-kernel@lists.infradead.org, Magnus Damm,
Sergei Shtylyov, Rob Herring, Mark Rutland,
devicetree@vger.kernel.org
In-Reply-To: <1493023915-21658-1-git-send-email-horms+renesas@verge.net.au>
On Mon, Apr 24, 2017 at 10:51 AM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> The device trees for Renesas SoCs use either pfc or pin-controller
> as the node name for the PFC device. This patch is intended to take a step
> towards unifying the node name used as pin-controller which appears to
> be more the more generic of the two and thus more in keeping with the DT
s/be more/be/
> specs.
>
> My analysis is that this is a user-visible change to the extent that kernel
> logs, and sysfs entries change from e6060000.pfc and pfc@e6060000 to
> e6060000.pin-controller and pin-controller@e6060000.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH V3 2/2] ARM64: dts: hi6220-hikey: Add clock binding for the pmic mfd
From: Lee Jones @ 2017-04-24 8:59 UTC (permalink / raw)
To: Daniel Lezcano
Cc: Stephen Boyd, mturquette, xuwei5, linux-kernel, linux-clk,
devicetree, linux-arm-kernel
In-Reply-To: <370c36f9-e6fc-416c-776b-edc1e42d7ddc@linaro.org>
On Sat, 22 Apr 2017, Daniel Lezcano wrote:
> On 22/04/2017 04:02, Stephen Boyd wrote:
> > On 04/17, Daniel Lezcano wrote:
> >> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> >> ---
> >> Documentation/devicetree/bindings/mfd/hisilicon,hi655x.txt | 6 ++++++
> >> arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 1 +
> >> 2 files changed, 7 insertions(+)
> >>
> >
> > I take it this goes through arm-soc? Not sure why I'm on To:
> > line.
>
> Probably it should go through Lee's tree.
Unlikely.
The document and the DTS change should really have gone separately,
but to save you from having to mess around so close to the merge window:
Acked-by: Lee Jones <lee.jones@linaro.org>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH] arm64: dts: r8a7795: update PFC node name to pin-controller
From: Simon Horman @ 2017-04-24 8:51 UTC (permalink / raw)
To: linux-renesas-soc
Cc: linux-arm-kernel, Magnus Damm, Sergei Shtylyov, Rob Herring,
Mark Rutland, devicetree, Simon Horman
The device trees for Renesas SoCs use either pfc or pin-controller
as the node name for the PFC device. This patch is intended to take a step
towards unifying the node name used as pin-controller which appears to
be more the more generic of the two and thus more in keeping with the DT
specs.
My analysis is that this is a user-visible change to the extent that kernel
logs, and sysfs entries change from e6060000.pfc and pfc@e6060000 to
e6060000.pin-controller and pin-controller@e6060000.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
Before:
/sys/kernel/debug/pinctrl/e6060000.pfc
/sys/devices/platform/soc/e6060000.pfc
/sys/firmware/devicetree/base/soc/pfc@e6060000
/sys/bus/platform/devices/e6060000.pfc
/sys/bus/platform/drivers/sh-pfc
/sys/bus/platform/drivers/sh-pfc/e6060000.pfc
After:
/sys/kernel/debug/pinctrl/e6060000.pin-controller
/sys/devices/platform/soc/e6060000.pin-controller
/sys/firmware/devicetree/base/soc/pin-controller@e6060000
/sys/bus/platform/devices/e6060000.pin-controller
/sys/bus/platform/drivers/sh-pfc
/sys/bus/platform/drivers/sh-pfc/e6060000.pin-controller
---
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index e99d6443b3e4..7d87dff70ac8 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -398,7 +398,7 @@
#power-domain-cells = <1>;
};
- pfc: pfc@e6060000 {
+ pfc: pin-controller@e6060000 {
compatible = "renesas,pfc-r8a7795";
reg = <0 0xe6060000 0 0x50c>;
};
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* Re: [PATCH v5 02/11] clk: sunxi-ng: add support for DE2 CCU
From: Maxime Ripard @ 2017-04-24 8:51 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Rob Herring, Chen-Yu Tsai, Jernej Skrabec,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170423103754.50012-3-icenowy-h8G6r0blFSE@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 858 bytes --]
Hi,
On Sun, Apr 23, 2017 at 06:37:45PM +0800, Icenowy Zheng wrote:
> +static const struct of_device_id sunxi_de2_clk_ids[] = {
> + {
> + .compatible = "allwinner,sun8i-a83t-de2-clk",
> + .data = &sun8i_a83t_de2_clk_desc,
> + },
> + {
> + .compatible = "allwinner,sun50i-h5-de2-clk",
> + .data = &sun50i_a64_de2_clk_desc,
> + },
> + /*
> + * The Allwinner A64 SoC needs some bit to be poke in syscon to make
> + * DE2 really working.
> + * So there's currently no A64 compatible here.
> + * H5 shares the same reset line with A64, so here H5 is using the
> + * clock description of A64.
> + */
> + { }
> +};
So that A64 driver would require more than just what you defined in
the binding in order to operate?
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [PATCH v14 11/11] mux: adg792a: add mux controller driver for ADG792A/G
From: Peter Rosin @ 2017-04-24 8:36 UTC (permalink / raw)
To: linux-kernel, Greg Kroah-Hartman
Cc: Peter Rosin, Wolfram Sang, Rob Herring, Mark Rutland,
Jonathan Cameron, Hartmut Knaack, Lars-Peter Clausen,
Peter Meerwald-Stadler, Jonathan Corbet, linux-i2c, devicetree,
linux-iio, linux-doc, Andrew Morton, Colin Ian King,
Paul Gortmaker, Philipp Zabel, kernel
In-Reply-To: <1493022995-16917-1-git-send-email-peda@axentia.se>
Analog Devices ADG792A/G is a triple 4:1 mux.
Reviewed-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Peter Rosin <peda@axentia.se>
---
drivers/mux/Kconfig | 12 ++++
drivers/mux/Makefile | 1 +
drivers/mux/mux-adg792a.c | 157 ++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 170 insertions(+)
create mode 100644 drivers/mux/mux-adg792a.c
diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
index e580c2d028d2..34b8284d6d29 100644
--- a/drivers/mux/Kconfig
+++ b/drivers/mux/Kconfig
@@ -17,6 +17,18 @@ menuconfig MULTIPLEXER
if MULTIPLEXER
+config MUX_ADG792A
+ tristate "Analog Devices ADG792A/ADG792G Multiplexers"
+ depends on I2C
+ help
+ ADG792A and ADG792G Wide Bandwidth Triple 4:1 Multiplexers
+
+ The driver supports both operating the three multiplexers in
+ parallel and operating them independently.
+
+ To compile the driver as a module, choose M here: the module will
+ be called mux-adg792a.
+
config MUX_GPIO
tristate "GPIO-controlled Multiplexer"
depends on GPIOLIB
diff --git a/drivers/mux/Makefile b/drivers/mux/Makefile
index bb16953f6290..b00a7d37d2fb 100644
--- a/drivers/mux/Makefile
+++ b/drivers/mux/Makefile
@@ -3,4 +3,5 @@
#
obj-$(CONFIG_MULTIPLEXER) += mux-core.o
+obj-$(CONFIG_MUX_ADG792A) += mux-adg792a.o
obj-$(CONFIG_MUX_GPIO) += mux-gpio.o
diff --git a/drivers/mux/mux-adg792a.c b/drivers/mux/mux-adg792a.c
new file mode 100644
index 000000000000..12aa221ab90d
--- /dev/null
+++ b/drivers/mux/mux-adg792a.c
@@ -0,0 +1,157 @@
+/*
+ * Multiplexer driver for Analog Devices ADG792A/G Triple 4:1 mux
+ *
+ * Copyright (C) 2017 Axentia Technologies AB
+ *
+ * Author: Peter Rosin <peda@axentia.se>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/err.h>
+#include <linux/i2c.h>
+#include <linux/module.h>
+#include <linux/mux/driver.h>
+#include <linux/property.h>
+
+#define ADG792A_LDSW BIT(0)
+#define ADG792A_RESETB BIT(1)
+#define ADG792A_DISABLE(mux) (0x50 | (mux))
+#define ADG792A_DISABLE_ALL (0x5f)
+#define ADG792A_MUX(mux, state) (0xc0 | (((mux) + 1) << 2) | (state))
+#define ADG792A_MUX_ALL(state) (0xc0 | (state))
+
+static int adg792a_write_cmd(struct i2c_client *i2c, u8 cmd, int reset)
+{
+ u8 data = ADG792A_RESETB | ADG792A_LDSW;
+
+ /* ADG792A_RESETB is active low, the chip resets when it is zero. */
+ if (reset)
+ data &= ~ADG792A_RESETB;
+
+ return i2c_smbus_write_byte_data(i2c, cmd, data);
+}
+
+static int adg792a_set(struct mux_control *mux, int state)
+{
+ struct i2c_client *i2c = to_i2c_client(mux->chip->dev.parent);
+ u8 cmd;
+
+ if (mux->chip->controllers == 1) {
+ /* parallel mux controller operation */
+ if (state == MUX_IDLE_DISCONNECT)
+ cmd = ADG792A_DISABLE_ALL;
+ else
+ cmd = ADG792A_MUX_ALL(state);
+ } else {
+ unsigned int controller = mux_control_get_index(mux);
+
+ if (state == MUX_IDLE_DISCONNECT)
+ cmd = ADG792A_DISABLE(controller);
+ else
+ cmd = ADG792A_MUX(controller, state);
+ }
+
+ return adg792a_write_cmd(i2c, cmd, 0);
+}
+
+static const struct mux_control_ops adg792a_ops = {
+ .set = adg792a_set,
+};
+
+static int adg792a_probe(struct i2c_client *i2c,
+ const struct i2c_device_id *id)
+{
+ struct device *dev = &i2c->dev;
+ struct mux_chip *mux_chip;
+ s32 idle_state[3];
+ u32 cells;
+ int ret;
+ int i;
+
+ if (!i2c_check_functionality(i2c->adapter, I2C_FUNC_SMBUS_BYTE_DATA))
+ return -ENODEV;
+
+ ret = device_property_read_u32(dev, "#mux-control-cells", &cells);
+ if (ret < 0)
+ return ret;
+ if (cells >= 2)
+ return -EINVAL;
+
+ mux_chip = devm_mux_chip_alloc(dev, cells ? 3 : 1, 0);
+ if (IS_ERR(mux_chip))
+ return PTR_ERR(mux_chip);
+
+ mux_chip->ops = &adg792a_ops;
+
+ ret = adg792a_write_cmd(i2c, ADG792A_DISABLE_ALL, 1);
+ if (ret < 0)
+ return ret;
+
+ ret = device_property_read_u32_array(dev, "idle-state",
+ (u32 *)idle_state,
+ mux_chip->controllers);
+ if (ret < 0) {
+ idle_state[0] = MUX_IDLE_AS_IS;
+ idle_state[1] = MUX_IDLE_AS_IS;
+ idle_state[2] = MUX_IDLE_AS_IS;
+ }
+
+ for (i = 0; i < mux_chip->controllers; ++i) {
+ struct mux_control *mux = &mux_chip->mux[i];
+
+ mux->states = 4;
+
+ switch (idle_state[i]) {
+ case MUX_IDLE_DISCONNECT:
+ case MUX_IDLE_AS_IS:
+ case 0 ... 4:
+ mux->idle_state = idle_state[i];
+ break;
+ default:
+ dev_err(dev, "invalid idle-state %d\n", idle_state[i]);
+ return -EINVAL;
+ }
+ }
+
+ ret = devm_mux_chip_register(dev, mux_chip);
+ if (ret < 0)
+ return ret;
+
+ if (cells)
+ dev_info(dev, "3x single pole quadruple throw muxes registered\n");
+ else
+ dev_info(dev, "triple pole quadruple throw mux registered\n");
+
+ return 0;
+}
+
+static const struct i2c_device_id adg792a_id[] = {
+ { .name = "adg792a", },
+ { .name = "adg792g", },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, adg792a_id);
+
+static const struct of_device_id adg792a_of_match[] = {
+ { .compatible = "adi,adg792a", },
+ { .compatible = "adi,adg792g", },
+ { }
+};
+MODULE_DEVICE_TABLE(of, adg792a_of_match);
+
+static struct i2c_driver adg792a_driver = {
+ .driver = {
+ .name = "adg792a",
+ .of_match_table = of_match_ptr(adg792a_of_match),
+ },
+ .probe = adg792a_probe,
+ .id_table = adg792a_id,
+};
+module_i2c_driver(adg792a_driver);
+
+MODULE_DESCRIPTION("Analog Devices ADG792A/G Triple 4:1 mux driver");
+MODULE_AUTHOR("Peter Rosin <peda@axentia.se>");
+MODULE_LICENSE("GPL v2");
--
2.1.4
^ permalink raw reply related
* [PATCH v14 10/11] dt-bindings: mux-adg792a: document devicetree bindings for ADG792A/G mux
From: Peter Rosin @ 2017-04-24 8:36 UTC (permalink / raw)
To: linux-kernel, Greg Kroah-Hartman
Cc: Peter Rosin, Wolfram Sang, Rob Herring, Mark Rutland,
Jonathan Cameron, Hartmut Knaack, Lars-Peter Clausen,
Peter Meerwald-Stadler, Jonathan Corbet, linux-i2c, devicetree,
linux-iio, linux-doc, Andrew Morton, Colin Ian King,
Paul Gortmaker, Philipp Zabel, kernel
In-Reply-To: <1493022995-16917-1-git-send-email-peda@axentia.se>
Analog Devices ADG792A/G is a triple 4:1 mux.
Acked-by: Jonathan Cameron <jic23@kernel.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Peter Rosin <peda@axentia.se>
---
.../devicetree/bindings/mux/adi,adg792a.txt | 75 ++++++++++++++++++++++
1 file changed, 75 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mux/adi,adg792a.txt
diff --git a/Documentation/devicetree/bindings/mux/adi,adg792a.txt b/Documentation/devicetree/bindings/mux/adi,adg792a.txt
new file mode 100644
index 000000000000..96b787a69f50
--- /dev/null
+++ b/Documentation/devicetree/bindings/mux/adi,adg792a.txt
@@ -0,0 +1,75 @@
+Bindings for Analog Devices ADG792A/G Triple 4:1 Multiplexers
+
+Required properties:
+- compatible : "adi,adg792a" or "adi,adg792g"
+- #mux-control-cells : <0> if parallel (the three muxes are bound together
+ with a single mux controller controlling all three muxes), or <1> if
+ not (one mux controller for each mux).
+* Standard mux-controller bindings as described in mux-controller.txt
+
+Optional properties for ADG792G:
+- gpio-controller : if present, #gpio-cells below is required.
+- #gpio-cells : should be <2>
+ - First cell is the GPO line number, i.e. 0 or 1
+ - Second cell is used to specify active high (0)
+ or active low (1)
+
+Optional properties:
+- idle-state : if present, array of states that the mux controllers will have
+ when idle. The special state MUX_IDLE_AS_IS is the default and
+ MUX_IDLE_DISCONNECT is also supported.
+
+States 0 through 3 correspond to signals A through D in the datasheet.
+
+Example:
+
+ /*
+ * Three independent mux controllers (of which one is used).
+ * Mux 0 is disconnected when idle, mux 1 idles in the previously
+ * selected state and mux 2 idles with signal B.
+ */
+ &i2c0 {
+ mux: mux-controller@50 {
+ compatible = "adi,adg792a";
+ reg = <0x50>;
+ #mux-control-cells = <1>;
+
+ idle-state = <MUX_IDLE_DISCONNECT MUX_IDLE_AS_IS 1>;
+ };
+ };
+
+ adc-mux {
+ compatible = "io-channel-mux";
+ io-channels = <&adc 0>;
+ io-channel-names = "parent";
+
+ mux-controls = <&mux 2>;
+
+ channels = "sync-1", "", "out";
+ };
+
+
+ /*
+ * Three parallel muxes with one mux controller, useful e.g. if
+ * the adc is differential, thus needing two signals to be muxed
+ * simultaneously for correct operation.
+ */
+ &i2c0 {
+ pmux: mux-controller@50 {
+ compatible = "adi,adg792a";
+ reg = <0x50>;
+ #mux-control-cells = <0>;
+
+ idle-state = <1>;
+ };
+ };
+
+ diff-adc-mux {
+ compatible = "io-channel-mux";
+ io-channels = <&adc 0>;
+ io-channel-names = "parent";
+
+ mux-controls = <&pmux>;
+
+ channels = "sync-1", "", "out";
+ };
--
2.1.4
^ permalink raw reply related
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