* Re: [PATCH 3/4] dt-bindings: iio: adc: Migrate AD7606 documentation to yaml
From: Rob Herring @ 2019-08-02 13:41 UTC (permalink / raw)
To: Beniamin Bia
Cc: Jonathan Cameron, Lars-Peter Clausen, Michael Hennerich,
Hartmut Knaack, Peter Meerwald, Greg Kroah-Hartman,
open list:IIO SUBSYSTEM AND DRIVERS, devel,
linux-kernel@vger.kernel.org, Mark Rutland, devicetree,
Paul E. McKenney, Mauro Carvalho Chehab, Linus Walleij,
Nicolas Ferre, biabeniamin
In-Reply-To: <20190802100304.15899-3-beniamin.bia@analog.com>
On Fri, Aug 2, 2019 at 4:03 AM Beniamin Bia <beniamin.bia@analog.com> wrote:
>
> The documentation for ad7606 was migrated to yaml, the new Linux Kernel
> standard.
Did you forget to delete the old file?
It's a DT, not kernel standard really.
>
> Signed-off-by: Beniamin Bia <beniamin.bia@analog.com>
> ---
> .../bindings/iio/adc/adi,ad7606.yaml | 134 ++++++++++++++++++
> MAINTAINERS | 2 +-
> 2 files changed, 135 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml
> new file mode 100644
> index 000000000000..509dbe9c84d2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml
> @@ -0,0 +1,134 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iio/adc/adi,ad7606.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Analog Devices AD7606 Simultaneous Sampling ADC
> +
> +maintainers:
> + - Beniamin Bia <beniamin.bia@analog.com>
> + - Stefan Popa <stefan.popa@analog.com>
> +
> +description: |
> + Analog Devices AD7606 Simultaneous Sampling ADC
> + https://www.analog.com/media/en/technical-documentation/data-sheets/ad7606_7606-6_7606-4.pdf
> + https://www.analog.com/media/en/technical-documentation/data-sheets/AD7616.pdf
> +
> +properties:
> + compatible:
> + enum:
> + - adi,ad7605-4
> + - adi,ad7606-8
> + - adi,ad7606-6
> + - adi,ad7606-4
> + - adi,ad7616
> +
> + reg:
> + maxItems: 1
> +
> + spi-cpha: true
> +
> + avcc-supply:
> + description:
> + Phandle to the Avcc power supply
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + adi,conversion-start-gpios:
> + description:
> + Must be the device tree identifier of the CONVST pin.
> + This logic input is used to initiate conversions on the analog
> + input channels. As the line is active high, it should be marked
> + GPIO_ACTIVE_HIGH.
> + maxItems: 1
> +
> + reset-gpios:
> + description:
> + Must be the device tree identifier of the RESET pin. If specified,
> + it will be asserted during driver probe. As the line is active high,
> + it should be marked GPIO_ACTIVE_HIGH.
> + maxItems: 1
> +
> + standby-gpios:
> + description:
> + Must be the device tree identifier of the STBY pin. This pin is used
> + to place the AD7606 into one of two power-down modes, Standby mode or
> + Shutdown mode. As the line is active low, it should be marked
> + GPIO_ACTIVE_LOW.
> + maxItems: 1
> +
> + adi,first-data-gpios:
> + description:
> + Must be the device tree identifier of the FRSTDATA pin.
> + The FRSTDATA output indicates when the first channel, V1, is
> + being read back on either the parallel, byte or serial interface.
> + As the line is active high, it should be marked GPIO_ACTIVE_HIGH.
> + maxItems: 1
> +
> + adi,range-gpios:
> + description:
> + Must be the device tree identifier of the RANGE pin. The polarity on
> + this pin determines the input range of the analog input channels. If
> + this pin is tied to a logic high, the analog input range is ±10V for
> + all channels. If this pin is tied to a logic low, the analog input range
> + is ±5V for all channels. As the line is active high, it should be marked
> + GPIO_ACTIVE_HIGH.
> + maxItems: 1
> +
> + adi,oversampling-ratio-gpios:
> + description:
> + Must be the device tree identifier of the over-sampling
> + mode pins. As the line is active high, it should be marked
> + GPIO_ACTIVE_HIGH.
> + maxItems: 1
> +
> + adi,sw-mode:
> + description:
> + Software mode of operation, so far available only for ad7616.
> + It is enabled when all three oversampling mode pins are connected to
> + high level. The device is configured by the corresponding registers. If the
> + adi,oversampling-ratio-gpios property is defined, then the driver will set the
> + oversampling gpios to high. Otherwise, it is assumed that the pins are hardwired
> + to VDD.
> + maxItems: 1
> + type: boolean
> +
> +required:
> + - compatible
> + - reg
> + - spi-cpha
> + - avcc-supply
> + - interrupts
> + - adi,conversion-start-gpios
> +
> +examples:
> + - |
> + spi0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + adc@0 {
> + compatible = "adi,ad7606-8";
> + reg = <0>;
> + spi-max-frequency = <1000000>;
> + spi-cpol;
> +
> + avcc-supply = <&adc_vref>;
> +
> + interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
> + interrupt-parent = <&gpio>;
> +
> + adi,conversion-start-gpios = <&gpio 17 GPIO_ACTIVE_HIGH>;
> + reset-gpios = <&gpio 27 GPIO_ACTIVE_HIGH>;
> + adi,first-data-gpios = <&gpio 22 GPIO_ACTIVE_HIGH>;
> + adi,oversampling-ratio-gpios = <&gpio 18 GPIO_ACTIVE_HIGH
> + &gpio 23 GPIO_ACTIVE_HIGH
> + &gpio 26 GPIO_ACTIVE_HIGH>;
> + standby-gpios = <&gpio 24 GPIO_ACTIVE_LOW>;
> + adi,sw-mode;
> + };
> + };
> +...
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 052d7a8591fb..d2e465772071 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -900,7 +900,7 @@ L: linux-iio@vger.kernel.org
> W: http://ez.analog.com/community/linux-device-drivers
> S: Supported
> F: drivers/iio/adc/ad7606.c
> -F: Documentation/devicetree/bindings/iio/adc/adi,ad7606.txt
> +F: Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml
>
> ANALOG DEVICES INC AD7768-1 DRIVER
> M: Stefan Popa <stefan.popa@analog.com>
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH 2/4] dt-bindings: i2c: rcar: Rename bindings documentation file
From: Wolfram Sang @ 2019-08-02 13:36 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Simon Horman, Wolfram Sang, Chris Brandt, Rob Herring,
Mark Rutland, Magnus Damm, Linux I2C,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux-Renesas
In-Reply-To: <CAMuHMdUYTo1_zz4sCv5=PRL90EyFSU_b5WgUJoc4Oii08F_tww@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 555 bytes --]
Hi Geert,
> With the above fixed:
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Now I understand why I applied this patch despite your request for a
change. Patchwork picked up the tag, and so I it looked to me in the
patchwork summary that this patch series was completely reviewed.
Would it be OK for you to not give the formal tag in advance but rather
describe it like "you may add my rev-by tag like in patch 1"? Or just
wait for v2 and tag?
Workflows aside, thanks for your continued reviews of patches!
Best regards,
Wolfram
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: counter: new bindings for TI eQEP
From: Rob Herring @ 2019-08-02 13:34 UTC (permalink / raw)
To: William Breathitt Gray
Cc: David Lechner, open list:IIO SUBSYSTEM AND DRIVERS, linux-omap,
devicetree, Mark Rutland, Jonathan Cameron, Benoît Cousson,
Tony Lindgren, Thierry Reding, linux-kernel@vger.kernel.org,
Linux PWM List
In-Reply-To: <20190802072513.GA30522@icarus>
On Fri, Aug 2, 2019 at 1:25 AM William Breathitt Gray
<vilhelm.gray@gmail.com> wrote:
>
> On Sat, Jul 27, 2019 at 08:48:36PM +0100, Jonathan Cameron wrote:
> > On Mon, 22 Jul 2019 10:45:35 -0500
> > David Lechner <david@lechnology.com> wrote:
> >
> > > This documents device tree binding for the Texas Instruments Enhanced
> > > Quadrature Encoder Pulse (eQEP) Module found in various TI SoCs.
> > >
> > > Signed-off-by: David Lechner <david@lechnology.com>
> >
> > Up to William given it is a counter binding, (unless Rob overrules)
> > but new bindings are generally preferred as yaml.
> >
> > Content looks fine to me.
> >
> > Thanks,
> >
> > Jonathan
>
> Rob,
>
> Would you prefer these bindings as yaml, or shall I accept them as they
> are now?
Still up to you at this point, but I certainly prefer them to be DT schema.
Rob
^ permalink raw reply
* Re: [PATCH v3 04/10] dt-bindings: mfd: Add compatible for the MediaTek MT6358 PMIC
From: Hsin-hsiung Wang @ 2019-08-02 13:28 UTC (permalink / raw)
To: Nicolas Boichat
Cc: Lee Jones, Rob Herring, Mark Brown, Matthias Brugger,
Mark Rutland, Alessandro Zummo, Alexandre Belloni, srv_heupstream,
devicetree, Sean Wang, Liam Girdwood, lkml,
moderated list:ARM/Mediatek SoC support, linux-arm Mailing List,
Eddie Huang, linux-rtc
In-Reply-To: <CANMq1KCiK69kXkpagccqd1=pKOs7qOOVuJUaCe5JfoGVmPt7mg@mail.gmail.com>
Hi Nicolas,
On Tue, 2019-05-07 at 14:24 +0900, Nicolas Boichat wrote:
> On Fri, May 3, 2019 at 6:34 PM Hsin-Hsiung Wang
> <hsin-hsiung.wang@mediatek.com> wrote:
> >
...
> > This adds compatible for the MediaTek MT6358 PMIC.
> >
> > Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> > Signed-off-by: Hsin-Hsiung Wang <hsin-hsiung.wang@mediatek.com>
> > ---
> > Documentation/devicetree/bindings/mfd/mt6397.txt | 11 ++++++++---
> > 1 file changed, 8 insertions(+), 3 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/mfd/mt6397.txt b/Documentation/devicetree/bindings/mfd/mt6397.txt
> > index 0ebd08af777d..62f1c17c7738 100644
> > --- a/Documentation/devicetree/bindings/mfd/mt6397.txt
> > +++ b/Documentation/devicetree/bindings/mfd/mt6397.txt
> > @@ -17,22 +17,27 @@ Documentation/devicetree/bindings/soc/mediatek/pwrap.txt
> > This document describes the binding for MFD device and its sub module.
> >
> > Required properties:
> > -compatible: "mediatek,mt6397" or "mediatek,mt6323"
> > +compatible:
> > + "mediatek,mt6323" for PMIC MT6323
> > + "mediatek,mt6358" for PMIC MT6358
> > + "mediatek,mt6397" for PMIC MT6397
> >
> > Optional subnodes:
> >
> > - rtc
> > Required properties:
> > - - compatible: "mediatek,mt6397-rtc"
> > + - compatible: "mediatek,mt6397-rtc" or "mediatek,mt6358-rtc"
> > - regulators
> > Required properties:
> > - compatible: "mediatek,mt6397-regulator"
> > see Documentation/devicetree/bindings/regulator/mt6397-regulator.txt
> > + - compatible: "mediatek,mt6358-regulator"
> > + see Documentation/devicetree/bindings/regulator/mt6358-regulator.txt
> > - compatible: "mediatek,mt6323-regulator"
> > see Documentation/devicetree/bindings/regulator/mt6323-regulator.txt
> > - codec
> > Required properties:
> > - - compatible: "mediatek,mt6397-codec"
> > + - compatible: "mediatek,mt6397-codec" or "mediatek,mt6358-sound"
>
> Sean had a question about this
> (https://patchwork.kernel.org/patch/10846669/#22524299):
> "why didn't we use a more consistent naming as mt6358-codec?"
>
The compatible name, "mediatek,mt6358-sound", is already in mt6358 audio
driver which is already in the upstream codebase.
After discussing with audio owner, we will submit another patch to fix
it.
Thanks.
> > - clk
> > Required properties:
> > - compatible: "mediatek,mt6397-clk"
> > --
> > 2.18.0
> >
> >
> > _______________________________________________
> > Linux-mediatek mailing list
> > Linux-mediatek@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply
* [PATCH AUTOSEL 4.19 33/42] ARM: dts: bcm: bcm47094: add missing #cells for mdio-bus-mux
From: Sasha Levin @ 2019-08-02 13:22 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Olof Johansson, Sasha Levin, linux-arm-kernel, Arnd Bergmann,
devicetree
In-Reply-To: <20190802132302.13537-1-sashal@kernel.org>
From: Arnd Bergmann <arnd@arndb.de>
[ Upstream commit 3a9d2569e45cb02769cda26fee4a02126867c934 ]
The mdio-bus-mux has no #address-cells/#size-cells property,
which causes a few dtc warnings:
arch/arm/boot/dts/bcm47094-linksys-panamera.dts:129.4-18: Warning (reg_format): /mdio-bus-mux/mdio@200:reg: property has invalid length (4 bytes) (#address-cells == 2, #size-cells == 1)
arch/arm/boot/dts/bcm47094-linksys-panamera.dtb: Warning (pci_device_bus_num): Failed prerequisite 'reg_format'
arch/arm/boot/dts/bcm47094-linksys-panamera.dtb: Warning (i2c_bus_reg): Failed prerequisite 'reg_format'
arch/arm/boot/dts/bcm47094-linksys-panamera.dtb: Warning (spi_bus_reg): Failed prerequisite 'reg_format'
arch/arm/boot/dts/bcm47094-linksys-panamera.dts:128.22-132.5: Warning (avoid_default_addr_size): /mdio-bus-mux/mdio@200: Relying on default #address-cells value
arch/arm/boot/dts/bcm47094-linksys-panamera.dts:128.22-132.5: Warning (avoid_default_addr_size): /mdio-bus-mux/mdio@200: Relying on default #size-cells value
Add the normal cell numbers.
Link: https://lore.kernel.org/r/20190722145618.1155492-1-arnd@arndb.de
Fixes: 2bebdfcdcd0f ("ARM: dts: BCM5301X: Add support for Linksys EA9500")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm/boot/dts/bcm47094-linksys-panamera.dts | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/boot/dts/bcm47094-linksys-panamera.dts b/arch/arm/boot/dts/bcm47094-linksys-panamera.dts
index 36efe410dcd71..9e33c41f54112 100644
--- a/arch/arm/boot/dts/bcm47094-linksys-panamera.dts
+++ b/arch/arm/boot/dts/bcm47094-linksys-panamera.dts
@@ -125,6 +125,9 @@
};
mdio-bus-mux {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
/* BIT(9) = 1 => external mdio */
mdio_ext: mdio@200 {
reg = <0x200>;
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 63/76] ARM: dts: bcm: bcm47094: add missing #cells for mdio-bus-mux
From: Sasha Levin @ 2019-08-02 13:19 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Olof Johansson, Sasha Levin, linux-arm-kernel, Arnd Bergmann,
devicetree
In-Reply-To: <20190802131951.11600-1-sashal@kernel.org>
From: Arnd Bergmann <arnd@arndb.de>
[ Upstream commit 3a9d2569e45cb02769cda26fee4a02126867c934 ]
The mdio-bus-mux has no #address-cells/#size-cells property,
which causes a few dtc warnings:
arch/arm/boot/dts/bcm47094-linksys-panamera.dts:129.4-18: Warning (reg_format): /mdio-bus-mux/mdio@200:reg: property has invalid length (4 bytes) (#address-cells == 2, #size-cells == 1)
arch/arm/boot/dts/bcm47094-linksys-panamera.dtb: Warning (pci_device_bus_num): Failed prerequisite 'reg_format'
arch/arm/boot/dts/bcm47094-linksys-panamera.dtb: Warning (i2c_bus_reg): Failed prerequisite 'reg_format'
arch/arm/boot/dts/bcm47094-linksys-panamera.dtb: Warning (spi_bus_reg): Failed prerequisite 'reg_format'
arch/arm/boot/dts/bcm47094-linksys-panamera.dts:128.22-132.5: Warning (avoid_default_addr_size): /mdio-bus-mux/mdio@200: Relying on default #address-cells value
arch/arm/boot/dts/bcm47094-linksys-panamera.dts:128.22-132.5: Warning (avoid_default_addr_size): /mdio-bus-mux/mdio@200: Relying on default #size-cells value
Add the normal cell numbers.
Link: https://lore.kernel.org/r/20190722145618.1155492-1-arnd@arndb.de
Fixes: 2bebdfcdcd0f ("ARM: dts: BCM5301X: Add support for Linksys EA9500")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm/boot/dts/bcm47094-linksys-panamera.dts | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/boot/dts/bcm47094-linksys-panamera.dts b/arch/arm/boot/dts/bcm47094-linksys-panamera.dts
index 5fd47eec4407e..1679959a3654d 100644
--- a/arch/arm/boot/dts/bcm47094-linksys-panamera.dts
+++ b/arch/arm/boot/dts/bcm47094-linksys-panamera.dts
@@ -126,6 +126,9 @@
};
mdio-bus-mux {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
/* BIT(9) = 1 => external mdio */
mdio_ext: mdio@200 {
reg = <0x200>;
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 45/76] arm64: dts: imx8mq: fix SAI compatible
From: Sasha Levin @ 2019-08-02 13:19 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Lucas Stach, Daniel Baluta, Shawn Guo, Sasha Levin, devicetree
In-Reply-To: <20190802131951.11600-1-sashal@kernel.org>
From: Lucas Stach <l.stach@pengutronix.de>
[ Upstream commit 8d0148473dece51675d11dd59b8db5fe4b5d2e7e ]
The i.MX8M SAI block is not compatible with the i.MX6SX one, as the
register layout has changed due to two version registers being added
at the beginning of the address map. Remove the bogus compatible.
Fixes: 8c61538dc945 ("arm64: dts: imx8mq: Add SAI2 node")
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm64/boot/dts/freescale/imx8mq.dtsi | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
index 6d635ba0904c5..6632cbd88bed3 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
@@ -675,8 +675,7 @@
sai2: sai@308b0000 {
#sound-dai-cells = <0>;
- compatible = "fsl,imx8mq-sai",
- "fsl,imx6sx-sai";
+ compatible = "fsl,imx8mq-sai";
reg = <0x308b0000 0x10000>;
interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clk IMX8MQ_CLK_SAI2_IPG>,
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 44/76] arm64: dts: imx8mm: Correct SAI3 RXC/TXFS pin's mux option #1
From: Sasha Levin @ 2019-08-02 13:19 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Anson Huang, Shawn Guo, Sasha Levin, devicetree
In-Reply-To: <20190802131951.11600-1-sashal@kernel.org>
From: Anson Huang <Anson.Huang@nxp.com>
[ Upstream commit 52d09014bb104a9157c0f5530700291052d2955c ]
According to i.MX8MM reference manual Rev.1, 03/2019:
SAI3_RXC pin's mux option #1 should be GPT1_CLK, NOT GPT1_CAPTURE2;
SAI3_TXFS pin's mux option #1 should be GPT1_CAPTURE2, NOT GPT1_CLK.
Fixes: c1c9d41319c3 ("dt-bindings: imx: Add pinctrl binding doc for imx8mm")
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm64/boot/dts/freescale/imx8mm-pinfunc.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-pinfunc.h b/arch/arm64/boot/dts/freescale/imx8mm-pinfunc.h
index e25f7fcd79975..cffa8991880d1 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-pinfunc.h
+++ b/arch/arm64/boot/dts/freescale/imx8mm-pinfunc.h
@@ -462,7 +462,7 @@
#define MX8MM_IOMUXC_SAI3_RXFS_GPIO4_IO28 0x1CC 0x434 0x000 0x5 0x0
#define MX8MM_IOMUXC_SAI3_RXFS_TPSMP_HTRANS0 0x1CC 0x434 0x000 0x7 0x0
#define MX8MM_IOMUXC_SAI3_RXC_SAI3_RX_BCLK 0x1D0 0x438 0x000 0x0 0x0
-#define MX8MM_IOMUXC_SAI3_RXC_GPT1_CAPTURE2 0x1D0 0x438 0x000 0x1 0x0
+#define MX8MM_IOMUXC_SAI3_RXC_GPT1_CLK 0x1D0 0x438 0x000 0x1 0x0
#define MX8MM_IOMUXC_SAI3_RXC_SAI5_RX_BCLK 0x1D0 0x438 0x4D0 0x2 0x2
#define MX8MM_IOMUXC_SAI3_RXC_GPIO4_IO29 0x1D0 0x438 0x000 0x5 0x0
#define MX8MM_IOMUXC_SAI3_RXC_TPSMP_HTRANS1 0x1D0 0x438 0x000 0x7 0x0
@@ -472,7 +472,7 @@
#define MX8MM_IOMUXC_SAI3_RXD_GPIO4_IO30 0x1D4 0x43C 0x000 0x5 0x0
#define MX8MM_IOMUXC_SAI3_RXD_TPSMP_HDATA0 0x1D4 0x43C 0x000 0x7 0x0
#define MX8MM_IOMUXC_SAI3_TXFS_SAI3_TX_SYNC 0x1D8 0x440 0x000 0x0 0x0
-#define MX8MM_IOMUXC_SAI3_TXFS_GPT1_CLK 0x1D8 0x440 0x000 0x1 0x0
+#define MX8MM_IOMUXC_SAI3_TXFS_GPT1_CAPTURE2 0x1D8 0x440 0x000 0x1 0x0
#define MX8MM_IOMUXC_SAI3_TXFS_SAI5_RX_DATA1 0x1D8 0x440 0x4D8 0x2 0x2
#define MX8MM_IOMUXC_SAI3_TXFS_GPIO4_IO31 0x1D8 0x440 0x000 0x5 0x0
#define MX8MM_IOMUXC_SAI3_TXFS_TPSMP_HDATA1 0x1D8 0x440 0x000 0x7 0x0
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 33/76] ARM: dts: imx6ul: fix clock frequency property name of I2C buses
From: Sasha Levin @ 2019-08-02 13:19 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sébastien Szymanski, Fabio Estevam, Shawn Guo, Sasha Levin,
devicetree
In-Reply-To: <20190802131951.11600-1-sashal@kernel.org>
From: Sébastien Szymanski <sebastien.szymanski@armadeus.com>
[ Upstream commit 2ca99396333999b9b5c5b91b36cbccacfe571aaf ]
A few boards set clock frequency of their I2C buses with
"clock_frequency" property. The right property is "clock-frequency".
Signed-off-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm/boot/dts/imx6ul-14x14-evk.dtsi | 2 +-
arch/arm/boot/dts/imx6ul-geam.dts | 2 +-
arch/arm/boot/dts/imx6ul-isiot.dtsi | 2 +-
arch/arm/boot/dts/imx6ul-pico-hobbit.dts | 2 +-
arch/arm/boot/dts/imx6ul-pico-pi.dts | 4 ++--
5 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/imx6ul-14x14-evk.dtsi b/arch/arm/boot/dts/imx6ul-14x14-evk.dtsi
index 9207d5d071f11..d556f7c541ce6 100644
--- a/arch/arm/boot/dts/imx6ul-14x14-evk.dtsi
+++ b/arch/arm/boot/dts/imx6ul-14x14-evk.dtsi
@@ -112,7 +112,7 @@
};
&i2c2 {
- clock_frequency = <100000>;
+ clock-frequency = <100000>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_i2c2>;
status = "okay";
diff --git a/arch/arm/boot/dts/imx6ul-geam.dts b/arch/arm/boot/dts/imx6ul-geam.dts
index bc77f26a2f1de..6157a058feec9 100644
--- a/arch/arm/boot/dts/imx6ul-geam.dts
+++ b/arch/arm/boot/dts/imx6ul-geam.dts
@@ -156,7 +156,7 @@
};
&i2c2 {
- clock_frequency = <100000>;
+ clock-frequency = <100000>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_i2c2>;
status = "okay";
diff --git a/arch/arm/boot/dts/imx6ul-isiot.dtsi b/arch/arm/boot/dts/imx6ul-isiot.dtsi
index 213e802bf35c5..23e6e2e7ace9d 100644
--- a/arch/arm/boot/dts/imx6ul-isiot.dtsi
+++ b/arch/arm/boot/dts/imx6ul-isiot.dtsi
@@ -148,7 +148,7 @@
};
&i2c2 {
- clock_frequency = <100000>;
+ clock-frequency = <100000>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_i2c2>;
status = "okay";
diff --git a/arch/arm/boot/dts/imx6ul-pico-hobbit.dts b/arch/arm/boot/dts/imx6ul-pico-hobbit.dts
index 39eeeddac39e3..09f7ffa9ad8c4 100644
--- a/arch/arm/boot/dts/imx6ul-pico-hobbit.dts
+++ b/arch/arm/boot/dts/imx6ul-pico-hobbit.dts
@@ -43,7 +43,7 @@
};
&i2c2 {
- clock_frequency = <100000>;
+ clock-frequency = <100000>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_i2c2>;
status = "okay";
diff --git a/arch/arm/boot/dts/imx6ul-pico-pi.dts b/arch/arm/boot/dts/imx6ul-pico-pi.dts
index de07357b27fc2..6cd7d5877d20c 100644
--- a/arch/arm/boot/dts/imx6ul-pico-pi.dts
+++ b/arch/arm/boot/dts/imx6ul-pico-pi.dts
@@ -43,7 +43,7 @@
};
&i2c2 {
- clock_frequency = <100000>;
+ clock-frequency = <100000>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_i2c2>;
status = "okay";
@@ -58,7 +58,7 @@
};
&i2c3 {
- clock_frequency = <100000>;
+ clock-frequency = <100000>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_i2c3>;
status = "okay";
--
2.20.1
^ permalink raw reply related
* Re: [PATCH V6 01/21] irqchip: tegra: Do not disable COP IRQ during suspend
From: Peter De Schrijver @ 2019-08-02 13:05 UTC (permalink / raw)
To: Dmitry Osipenko
Cc: Sowjanya Komatineni, thierry.reding, jonathanh, tglx, jason,
marc.zyngier, linus.walleij, stefan, mark.rutland, pgaikwad,
sboyd, linux-clk, linux-gpio, jckuo, josephl, talho, linux-tegra,
linux-kernel, mperttunen, spatra, robh+dt, devicetree
In-Reply-To: <de1723df-8580-32fb-eb9d-e4c02f2b4306@gmail.com>
On Thu, Jul 25, 2019 at 01:59:09PM +0300, Dmitry Osipenko wrote:
> 25.07.2019 13:38, Peter De Schrijver пишет:
> > On Thu, Jul 25, 2019 at 01:33:48PM +0300, Peter De Schrijver wrote:
> >> On Thu, Jul 25, 2019 at 01:05:13PM +0300, Dmitry Osipenko wrote:
> >>> 25.07.2019 12:55, Peter De Schrijver пишет:
> >>>> On Mon, Jul 22, 2019 at 12:54:51PM +0300, Dmitry Osipenko wrote:
> >>>>>
> >>>>> All Tegra SoCs support SC7, hence the 'supports_sc7' and the comment
> >>>>> doesn't sound correct to me. Something like 'firmware_sc7' should suit
> >>>>> better here.
> >>>>>
> >>>>>> + writel_relaxed(~0ul, ictlr + ICTLR_COP_IER_CLR);
> >>>>>
> >>>>> Secondly, I'm also not sure why COP interrupts need to be disabled for
> >>>>> pre-T210 at all, since COP is unused. This looks to me like it was
> >>>>> cut-n-pasted from downstream kernel without a good reason and could be
> >>>>> simply removed.
> >>>>
> >>>> I don't think we can rely on the fact that COP is unused. People can
> >>>> write their own code to run on COP.
> >>>
> >>> 1. Not upstream - doesn't matter.
> >>>
> >>
> >> The code is not part of the kernel, so obviously it's not upstream?
> >>
> >>> 2. That's not very good if something unknown is running on COP and then
> >>> kernel suddenly intervenes, don't you think so?
> >>
> >> Unless the code was written with this in mind.
> >>
>
> In that case, please see 1. ;)
>
In general the kernel should not touch the COP interrupts I think.
> >
> > Looking at this again, I don't think we need to enable the IRQ at all.
>
> Could you please clarify? The code only saves/restores COP's interrupts
> context across suspend-resume.
The sc7 entry firmware doesn't use interrupts.
Peter.
^ permalink raw reply
* Re: [RFC PATCH v2 0/4] Input: mpr121-polled: Add polled driver for MPR121
From: Michal Vokáč @ 2019-08-02 12:45 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Rob Herring, Mark Rutland, Shawn Guo, Sascha Hauer, Fabio Estevam,
linux-input, devicetree, linux-kernel, Pengutronix Kernel Team
In-Reply-To: <20190801234954.GA178933@dtor-ws>
On 02. 08. 19 1:49, Dmitry Torokhov wrote:
> On Tue, Jul 30, 2019 at 11:25:49AM +0200, Michal Vokáč wrote:
>> On 27. 07. 19 9:31, Dmitry Torokhov wrote:
>>> On Fri, Jul 26, 2019 at 01:31:31PM +0200, Michal Vokáč wrote:
>>>> On 25. 07. 19 16:40, Dmitry Torokhov wrote:
>>>>> On Thu, Jul 25, 2019 at 02:58:02PM +0200, Michal Vokáč wrote:
>>>>>> On 25. 07. 19 10:57, Dmitry Torokhov wrote:
>>>>>>> Hi Michal,
>>>>>>>
>>>>>>> On Tue, May 21, 2019 at 08:51:17AM +0200, Michal Vokáč wrote:
>>>>>>>> On 21. 05. 19 7:37, Dmitry Torokhov wrote:
>>>>>>>>> Hi Michal,
>>>>>>>>>
>>>>>>>>> On Fri, May 17, 2019 at 03:12:49PM +0200, Michal Vokáč wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I have to deal with a situation where we have a custom i.MX6 based
>>>>>>>>>> platform in production that uses the MPR121 touchkey controller.
>>>>>>>>>> Unfortunately the chip is connected using only the I2C interface.
>>>>>>>>>> The interrupt line is not used. Back in 2015 (Linux v3.14), my
>>>>>>>>>> colleague modded the existing mpr121_touchkey.c driver to use polling
>>>>>>>>>> instead of interrupt.
>>>>>>>>>>
>>>>>>>>>> For quite some time yet I am in a process of updating the product from
>>>>>>>>>> the ancient Freescale v3.14 kernel to the latest mainline and pushing
>>>>>>>>>> any needed changes upstream. The DT files for our imx6dl-yapp4 platform
>>>>>>>>>> already made it into v5.1-rc.
>>>>>>>>>>
>>>>>>>>>> I rebased and updated our mpr121 patch to the latest mainline.
>>>>>>>>>> It is created as a separate driver, similarly to gpio_keys_polled.
>>>>>>>>>>
>>>>>>>>>> The I2C device is quite susceptible to ESD. An ESD test quite often
>>>>>>>>>> causes reset of the chip or some register randomly changes its value.
>>>>>>>>>> The [PATCH 3/4] adds a write-through register cache. With the cache
>>>>>>>>>> this state can be detected and the device can be re-initialied.
>>>>>>>>>>
>>>>>>>>>> The main question is: Is there any chance that such a polled driver
>>>>>>>>>> could be accepted? Is it correct to implement it as a separate driver
>>>>>>>>>> or should it be done as an option in the existing driver? I can not
>>>>>>>>>> really imagine how I would do that though..
>>>>>>>>>>
>>>>>>>>>> There are also certain worries that the MPR121 chip may no longer be
>>>>>>>>>> available in nonspecifically distant future. In case of EOL I will need
>>>>>>>>>> to add a polled driver for an other touchkey chip. May it be already
>>>>>>>>>> in mainline or a completely new one.
>>>>>>>>>
>>>>>>>>> I think that my addition of input_polled_dev was ultimately a wrong
>>>>>>>>> thing to do. I am looking into enabling polling mode for regular input
>>>>>>>>> devices as we then can enable polling mode in existing drivers.
>>>>>>>>
>>>>>>>> OK, that sounds good. Especially when one needs to switch from one chip
>>>>>>>> to another that is already in tree, the need for a whole new polling
>>>>>>>> driver is eliminated.
>>>>>>>
>>>>>>> Could you please try the patch below and see if it works for your use
>>>>>>> case? Note that I have not tried running it, but it compiles so it must
>>>>>>> be good ;)
>>>>>>
>>>>>> Hi Dmitry,
>>>>>> Thank you very much for the patch!
>>>>>> I gave it a shot and it seems you forgot to add the input-poller.h file
>>>>>> to the patch.. it does not compile on my side :(
>>>>>
>>>>> Oops ;) Please see the updated patch below.
>>>>
>>>> Thank you, now it is (almost) good as you said :D
>>>>
>>>>>>
>>>>>>> Input: add support for polling to input devices
>>>>>>>
>>>>>>> From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>>>>>>>
>>>>>>> Separating "normal" and "polled" input devices was a mistake, as often we want
>>>>>>> to allow the very same device work on both interrupt-driven and polled mode,
>>>>>>> depending on the board on which the device is used.
>>>>>>>
>>>>>>> This introduces new APIs:
>>>>>>>
>>>>>>> - input_setup_polling
>>>>>>> - input_set_poll_interval
>>>>>>> - input_set_min_poll_interval
>>>>>>> - input_set_max_poll_interval
>>>>>>>
>>>>>>> These new APIs allow switching an input device into polled mode with sysfs
>>>>>>> attributes matching drivers using input_polled_dev APIs that will be eventually
>>>>>>> removed.
>>>>>>
>>>>>> After reading this I am not really sure what else needs to be done
>>>>>> to test/use the poller. I suspect I need to modify the input device
>>>>>> driver (mpr121_touchkey.c in my case) like this:
>>>>>>
>>>>>> If the interrupt gpio is not provided in DT, the device driver probe
>>>>>> function should:
>>>>>> - not request the threaded interrupt
>>>>>> - call input_setup_polling and provide it with poll_fn
>>>>>> Can the mpr_touchkey_interrupt function be used as is for this
>>>>>> purpose? The only problem I see is it returns IRQ_HANDLED.
>>>>>
>>>>> I'd factor out code suitable for polling from mpr_touchkey_interrupt()
>>>>> and then do
>>>>>
>>>>> static irqreturn_t mpr_touchkey_interrupt(...)
>>>>> {
>>>>> mpr_touchkey_report(...);
>>>>> return IRQ_HANDLED;
>>>>> }
>>>>>
>>>>
>>>> Probably a trivial problem for experienced kernel hacker but I can not
>>>> wrap my head around this - the interrupt handler takes the mpr121
>>>> device id as an argument while the poller poll_fn takes struct input_dev.
>>>>
>>>> I fail to figure out how to get the device id from the input device.
>>>>
>> Thanks for the hints Dmitry. I am trying my best but still have some
>> issues with the input_set/get_drvdata.
>>
>> The kernel Oopses on NULL pointer dereference in mpr_touchkey_report.
>> Here is the backtrace:
>>
>> [ 2.916960] 8<--- cut here ---
>> [ 2.920022] Unable to handle kernel NULL pointer dereference at virtual address 000001d0
>> [ 2.928138] pgd = (ptrval)
>
> Ah, that's my fault I believe. Can you please try sticking
>
> poller->input = dev;
>
> into input_setup_polling()?
>
Nice, that solved the problem and I confirm the poller mechanism works
as expected. The sysfs poll/min/max interface also works just fine.
Please Cc me when you submit your patch. I think you can already add
my "Tested-by: Michal Vokáč <michal.vokac@ysoft.com>".
I will send mine series when the poller is in your tree. I will include
the proposed DT binding change, adding the "linux,poll-interrupt"
property, though Rob did not respond to this yet.
What about the min/max poll interval limits? Was your idea those should
also be configurable from DT? Currently I defined some limits that are
reasonable for our use case but may not be suitable for someone else.
In the meantime I also need to improve reliability of the reading.
Sometimes the keys get stuck or an electrostatic discharge causes
reset of the chip. I will extract changes that deal with these problems
from the RFC series and from some downstream patches and submit those
later.
Thank you!
Michal
^ permalink raw reply
* Re: [PATCH v7 07/20] clk: tegra: clk-periph: Add save and restore support
From: Dmitry Osipenko @ 2019-08-02 12:38 UTC (permalink / raw)
To: Sowjanya Komatineni, thierry.reding, jonathanh, tglx, jason,
marc.zyngier, linus.walleij, stefan, mark.rutland
Cc: pdeschrijver, pgaikwad, sboyd, linux-clk, linux-gpio, jckuo,
josephl, talho, linux-tegra, linux-kernel, mperttunen, spatra,
robh+dt, devicetree
In-Reply-To: <9f6fc791-5c76-76d5-98fb-fd8facfd75d7@nvidia.com>
02.08.2019 2:49, Sowjanya Komatineni пишет:
>
> On 8/1/19 4:19 PM, Sowjanya Komatineni wrote:
>>
>> On 8/1/19 2:30 PM, Sowjanya Komatineni wrote:
>>>
>>> On 8/1/19 1:54 PM, Dmitry Osipenko wrote:
>>>> 01.08.2019 23:31, Sowjanya Komatineni пишет:
>>>>> On 8/1/19 1:17 PM, Dmitry Osipenko wrote:
>>>>>> 01.08.2019 22:42, Sowjanya Komatineni пишет:
>>>>>>> On 8/1/19 12:00 PM, Dmitry Osipenko wrote:
>>>>>>>> 01.08.2019 20:58, Sowjanya Komatineni пишет:
>>>>>>>>> On 7/31/19 4:09 PM, Sowjanya Komatineni wrote:
>>>>>>>>>> On 7/31/19 3:44 AM, Dmitry Osipenko wrote:
>>>>>>>>>>> 31.07.2019 12:50, Dmitry Osipenko пишет:
>>>>>>>>>>>> 31.07.2019 3:20, Sowjanya Komatineni пишет:
>>>>>>>>>>>>> This patch implements save and restore context for peripheral
>>>>>>>>>>>>> fixed
>>>>>>>>>>>>> clock ops, peripheral gate clock ops, sdmmc mux clock ops, and
>>>>>>>>>>>>> peripheral clock ops.
>>>>>>>>>>>>>
>>>>>>>>>>>>> During system suspend, core power goes off and looses the
>>>>>>>>>>>>> settings
>>>>>>>>>>>>> of the Tegra CAR controller registers.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So during suspend entry clock and reset state of
>>>>>>>>>>>>> peripherals is
>>>>>>>>>>>>> saved
>>>>>>>>>>>>> and on resume they are restored to have clocks back to same
>>>>>>>>>>>>> rate and
>>>>>>>>>>>>> state as before suspend.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Acked-by: Thierry Reding <treding@nvidia.com>
>>>>>>>>>>>>> Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com>
>>>>>>>>>>>>> ---
>>>>>>>>>>>>> drivers/clk/tegra/clk-periph-fixed.c | 33
>>>>>>>>>>>>> ++++++++++++++++++++++++++++++++
>>>>>>>>>>>>> drivers/clk/tegra/clk-periph-gate.c | 34
>>>>>>>>>>>>> +++++++++++++++++++++++++++++++++
>>>>>>>>>>>>> drivers/clk/tegra/clk-periph.c | 37
>>>>>>>>>>>>> ++++++++++++++++++++++++++++++++++++
>>>>>>>>>>>>> drivers/clk/tegra/clk-sdmmc-mux.c | 28
>>>>>>>>>>>>> +++++++++++++++++++++++++++
>>>>>>>>>>>>> drivers/clk/tegra/clk.h | 6 ++++++
>>>>>>>>>>>>> 5 files changed, 138 insertions(+)
>>>>>>>>>>>>>
>>>>>>>>>>>>> diff --git a/drivers/clk/tegra/clk-periph-fixed.c
>>>>>>>>>>>>> b/drivers/clk/tegra/clk-periph-fixed.c
>>>>>>>>>>>>> index c088e7a280df..21b24530fa00 100644
>>>>>>>>>>>>> --- a/drivers/clk/tegra/clk-periph-fixed.c
>>>>>>>>>>>>> +++ b/drivers/clk/tegra/clk-periph-fixed.c
>>>>>>>>>>>>> @@ -60,11 +60,44 @@ tegra_clk_periph_fixed_recalc_rate(struct
>>>>>>>>>>>>> clk_hw *hw,
>>>>>>>>>>>>> return (unsigned long)rate;
>>>>>>>>>>>>> }
>>>>>>>>>>>>> +static int tegra_clk_periph_fixed_save_context(struct
>>>>>>>>>>>>> clk_hw
>>>>>>>>>>>>> *hw)
>>>>>>>>>>>>> +{
>>>>>>>>>>>>> + struct tegra_clk_periph_fixed *fixed =
>>>>>>>>>>>>> to_tegra_clk_periph_fixed(hw);
>>>>>>>>>>>>> + u32 mask = 1 << (fixed->num % 32);
>>>>>>>>>>>>> +
>>>>>>>>>>>>> + fixed->enb_ctx = readl_relaxed(fixed->base +
>>>>>>>>>>>>> fixed->regs->enb_reg) &
>>>>>>>>>>>>> + mask;
>>>>>>>>>>>>> + fixed->rst_ctx = readl_relaxed(fixed->base +
>>>>>>>>>>>>> fixed->regs->rst_reg) &
>>>>>>>>>>>>> + mask;
>>>>>>>>>>>>> +
>>>>>>>>>>>>> + return 0;
>>>>>>>>>>>>> +}
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +static void tegra_clk_periph_fixed_restore_context(struct
>>>>>>>>>>>>> clk_hw
>>>>>>>>>>>>> *hw)
>>>>>>>>>>>>> +{
>>>>>>>>>>>>> + struct tegra_clk_periph_fixed *fixed =
>>>>>>>>>>>>> to_tegra_clk_periph_fixed(hw);
>>>>>>>>>>>>> + u32 mask = 1 << (fixed->num % 32);
>>>>>>>>>>>>> +
>>>>>>>>>>>>> + if (fixed->enb_ctx)
>>>>>>>>>>>>> + writel_relaxed(mask, fixed->base +
>>>>>>>>>>>>> fixed->regs->enb_set_reg);
>>>>>>>>>>>>> + else
>>>>>>>>>>>>> + writel_relaxed(mask, fixed->base +
>>>>>>>>>>>>> fixed->regs->enb_clr_reg);
>>>>>>>>>>>>> +
>>>>>>>>>>>>> + udelay(2);
>>>>>>>>>>>>> +
>>>>>>>>>>>>> + if (!fixed->rst_ctx) {
>>>>>>>>>>>>> + udelay(5); /* reset propogation delay */
>>>>>>>>>>>>> + writel_relaxed(mask, fixed->base +
>>>>>>>>>>>>> fixed->regs->rst_reg);
>>>>>>>>>>>>> + }
>>>>>>>>>>>>> +}
>>>>>>>>>>>>> +
>>>>>>>>>>>>> static const struct clk_ops tegra_clk_periph_fixed_ops
>>>>>>>>>>>>> = {
>>>>>>>>>>>>> .is_enabled = tegra_clk_periph_fixed_is_enabled,
>>>>>>>>>>>>> .enable = tegra_clk_periph_fixed_enable,
>>>>>>>>>>>>> .disable = tegra_clk_periph_fixed_disable,
>>>>>>>>>>>>> .recalc_rate = tegra_clk_periph_fixed_recalc_rate,
>>>>>>>>>>>>> + .save_context = tegra_clk_periph_fixed_save_context,
>>>>>>>>>>>>> + .restore_context =
>>>>>>>>>>>>> tegra_clk_periph_fixed_restore_context,
>>>>>>>>>>>>> };
>>>>>>>>>>>>> struct clk *tegra_clk_register_periph_fixed(const char
>>>>>>>>>>>>> *name,
>>>>>>>>>>>>> diff --git a/drivers/clk/tegra/clk-periph-gate.c
>>>>>>>>>>>>> b/drivers/clk/tegra/clk-periph-gate.c
>>>>>>>>>>>>> index 4b31beefc9fc..6ba5b08e0787 100644
>>>>>>>>>>>>> --- a/drivers/clk/tegra/clk-periph-gate.c
>>>>>>>>>>>>> +++ b/drivers/clk/tegra/clk-periph-gate.c
>>>>>>>>>>>>> @@ -25,6 +25,8 @@ static DEFINE_SPINLOCK(periph_ref_lock);
>>>>>>>>>>>>> #define read_rst(gate) \
>>>>>>>>>>>>> readl_relaxed(gate->clk_base + (gate->regs->rst_reg))
>>>>>>>>>>>>> +#define write_rst_set(val, gate) \
>>>>>>>>>>>>> + writel_relaxed(val, gate->clk_base +
>>>>>>>>>>>>> (gate->regs->rst_set_reg))
>>>>>>>>>>>>> #define write_rst_clr(val, gate) \
>>>>>>>>>>>>> writel_relaxed(val, gate->clk_base +
>>>>>>>>>>>>> (gate->regs->rst_clr_reg))
>>>>>>>>>>>>> @@ -110,10 +112,42 @@ static void
>>>>>>>>>>>>> clk_periph_disable(struct
>>>>>>>>>>>>> clk_hw *hw)
>>>>>>>>>>>>> spin_unlock_irqrestore(&periph_ref_lock, flags);
>>>>>>>>>>>>> }
>>>>>>>>>>>>> +static int clk_periph_gate_save_context(struct clk_hw
>>>>>>>>>>>>> *hw)
>>>>>>>>>>>>> +{
>>>>>>>>>>>>> + struct tegra_clk_periph_gate *gate =
>>>>>>>>>>>>> to_clk_periph_gate(hw);
>>>>>>>>>>>>> +
>>>>>>>>>>>>> + gate->clk_state_ctx = read_enb(gate) &
>>>>>>>>>>>>> periph_clk_to_bit(gate);
>>>>>>>>>>>>> + gate->rst_state_ctx = read_rst(gate) &
>>>>>>>>>>>>> periph_clk_to_bit(gate);
>>>>>>>>>>>>> +
>>>>>>>>>>>>> + return 0;
>>>>>>>>>>>>> +}
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +static void clk_periph_gate_restore_context(struct clk_hw
>>>>>>>>>>>>> *hw)
>>>>>>>>>>>>> +{
>>>>>>>>>>>>> + struct tegra_clk_periph_gate *gate =
>>>>>>>>>>>>> to_clk_periph_gate(hw);
>>>>>>>>>>>>> +
>>>>>>>>>>>>> + if (gate->clk_state_ctx)
>>>>>>>>>>>>> + write_enb_set(periph_clk_to_bit(gate), gate);
>>>>>>>>>>>>> + else
>>>>>>>>>>>>> + write_enb_clr(periph_clk_to_bit(gate), gate);
>>>>>>>>>>>>> +
>>>>>>>>>>>>> + udelay(5);
>>>>>>>>>>>>> +
>>>>>>>>>>>>> + if (!(gate->flags & TEGRA_PERIPH_NO_RESET) &&
>>>>>>>>>>>>> + !(gate->flags & TEGRA_PERIPH_MANUAL_RESET)) {
>>>>>>>>>>>>> + if (gate->rst_state_ctx)
>>>>>>>>>>>>> + write_rst_set(periph_clk_to_bit(gate), gate);
>>>>>>>>>>>>> + else
>>>>>>>>>>>>> + write_rst_clr(periph_clk_to_bit(gate), gate);
>>>>>>>>>>>>> + }
>>>>>>>>>>>>> +}
>>>>>>>>>>>>> +
>>>>>>>>>>>>> const struct clk_ops tegra_clk_periph_gate_ops = {
>>>>>>>>>>>>> .is_enabled = clk_periph_is_enabled,
>>>>>>>>>>>>> .enable = clk_periph_enable,
>>>>>>>>>>>>> .disable = clk_periph_disable,
>>>>>>>>>>>>> + .save_context = clk_periph_gate_save_context,
>>>>>>>>>>>>> + .restore_context = clk_periph_gate_restore_context,
>>>>>>>>>>>>> };
>>>>>>>>>>>>> struct clk *tegra_clk_register_periph_gate(const
>>>>>>>>>>>>> char *name,
>>>>>>>>>>>>> diff --git a/drivers/clk/tegra/clk-periph.c
>>>>>>>>>>>>> b/drivers/clk/tegra/clk-periph.c
>>>>>>>>>>>>> index 58437da25156..06fb62955768 100644
>>>>>>>>>>>>> --- a/drivers/clk/tegra/clk-periph.c
>>>>>>>>>>>>> +++ b/drivers/clk/tegra/clk-periph.c
>>>>>>>>>>>>> @@ -99,6 +99,37 @@ static void clk_periph_disable(struct
>>>>>>>>>>>>> clk_hw
>>>>>>>>>>>>> *hw)
>>>>>>>>>>>>> gate_ops->disable(gate_hw);
>>>>>>>>>>>>> }
>>>>>>>>>>>>> +static int clk_periph_save_context(struct clk_hw *hw)
>>>>>>>>>>>>> +{
>>>>>>>>>>>>> + struct tegra_clk_periph *periph = to_clk_periph(hw);
>>>>>>>>>>>>> + const struct clk_ops *gate_ops = periph->gate_ops;
>>>>>>>>>>>>> + struct clk_hw *gate_hw = &periph->gate.hw;
>>>>>>>>>>>>> +
>>>>>>>>>>>>> + if (!(periph->gate.flags & TEGRA_PERIPH_NO_GATE))
>>>>>>>>>>>>> + gate_ops->save_context(gate_hw);
>>>>>>>>>>>>> +
>>>>>>>>>>>>> + periph->parent_ctx = clk_periph_get_parent(hw);
>>>>>>>>>>>>> +
>>>>>>>>>>>>> + return 0;
>>>>>>>>>>>>> +}
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +static void clk_periph_restore_context(struct clk_hw *hw)
>>>>>>>>>>>>> +{
>>>>>>>>>>>>> + struct tegra_clk_periph *periph = to_clk_periph(hw);
>>>>>>>>>>>>> + const struct clk_ops *gate_ops = periph->gate_ops;
>>>>>>>>>>>>> + struct clk_hw *gate_hw = &periph->gate.hw;
>>>>>>>>>>>>> + const struct clk_ops *div_ops = periph->div_ops;
>>>>>>>>>>>>> + struct clk_hw *div_hw = &periph->divider.hw;
>>>>>>>>>>>>> +
>>>>>>>>>>>>> + clk_periph_set_parent(hw, periph->parent_ctx);
>>>>>>>>>>>>> +
>>>>>>>>>>>>> + if (!(periph->gate.flags & TEGRA_PERIPH_NO_DIV))
>>>>>>>>>>>>> + div_ops->restore_context(div_hw);
>>>>>>>>>>>> Could you please point to where the divider's save_context()
>>>>>>>>>>>> happens?
>>>>>>>>>>>> Because I can't see it.
>>>>>>>>>>> Ah, I now see that there is no need to save the dividers context
>>>>>>>>>>> because
>>>>>>>>>>> clk itself has enough info that is needed for the context's
>>>>>>>>>>> restoring
>>>>>>>>>>> (like I pointed in the review to v6).
>>>>>>>>>>>
>>>>>>>>>>> Looks like you could also implement a new
>>>>>>>>>>> clk_hw_get_parent_index()
>>>>>>>>>>> generic helper to get the index instead of storing it manually.
>>>>>>>>>> clk_periph_get_parent basically invokes existing clk_mux_ops
>>>>>>>>>> get_parent() which is then saved in tegra_clk_periph.
>>>>>>>>>>
>>>>>>>>>> All existing drivers are using directly get_parent() from clk_mux
>>>>>>>>>> which actually gets index from the register read.
>>>>>>>>>>
>>>>>>>>>> To have this more generic w.r.t save/restore context point of
>>>>>>>>>> view,
>>>>>>>>>> probably instead of implementing new get_parent_index helper,
>>>>>>>>>> I think
>>>>>>>>>> its better to implement save_context and restore_context to
>>>>>>>>>> clk_mux_ops along with creating parent_index field into
>>>>>>>>>> clk_mux to
>>>>>>>>>> cache index during set_parent.
>>>>>>>>>>
>>>>>>>>>> So we just need to invoke mux_ops save_context and
>>>>>>>>>> restore_context.
>>>>>>>>>>
>>>>>>>>> I hope its ok to add save/restore context to clk_mux_ops to be
>>>>>>>>> more
>>>>>>>>> generic w.r.t save/restore context rather than get_parent_index
>>>>>>>>> API.
>>>>>>>>> Please confirm if you agree.
>>>>>>>> Sounds like a good idea. I see that there is a 'restoring'
>>>>>>>> helper for
>>>>>>>> the generic clk_gate, seems something similar could be done for the
>>>>>>>> clk_mux. And looks like anyway you'll need to associate the parent
>>>>>>>> clock
>>>>>>>> with the hw index in order to restore the muxing.
>>>>>>> by 'restoring' helper for generic clk_gate, are you referring to
>>>>>>> clk_gate_restore_context API?
>>>>>> Yes.
>>>>>>
>>>>>>> clk_gate_restore_context is API that's any clk drivers can use for
>>>>>>> clk_gate operation restore for custom gate clk_ops.
>>>>>>>
>>>>>>> But clk-periph is directly using generic clk_mux ops from clk_mux
>>>>>>> so I
>>>>>>> think we should add .restore_context to clk_mux_ops and then during
>>>>>>> clk-periph restore need to invoke mux_ops->restore_context.
>>>>>> I'm not sure whether it will be good for every driver that uses
>>>>>> generic
>>>>>> clk_mux ops. Should be more flexible to have a generic helper
>>>>>> function
>>>>>> that any driver could use in order to restore the clock's parent.
>>>>>>
>>>>>> The clk-periph restoring also includes case of combining divider and
>>>>>> parent restoring, so generic helper could be useful in that case
>>>>>> as well.
>>>>>>
>>>>>> It also looks like you could actually use the
>>>>>> clk_gate_restore_context()
>>>>>> instead of manually saving the clock's enable-state, couldn't you?
>>>>> ok for clk_mux, can add generic clk_mux_restore_context API rather
>>>>> than
>>>>> using restore_context in clk_ops and will invoke that during
>>>>> clk_periph
>>>>> restore.
>>>>>
> digging thru looks like for clk_periph source restore instead of
> clk_mux_restore_context, i can directly do clk_hw_get_parent and
> clk_set_parent with mux_hw as they invoke mux_ops get/set parent anyway.
> Will do this for periph clk mux
>>>>>
>>>>> Reg clk_gate, looks like we cant use generic clk_gate_restore_context
>>>>> for clk-periph as it calls enable/disable callbacks and
>>>>> clk_periph_enable/disable in clk-periph-gate also updated refcnt and
>>>>> depending on that actual enable/disable is set.
>>>>>
>>>>> During suspend, peripherals that are already enabled have their
>>>>> refcnt >
>>>>> 1, so they dont go thru enable/disable on restore if we use same
>>>>> enable/disable callback.
>>>> Looks like you could just decrement the gate's enable_refcnt on
>>>> save_context, wouldn't that work?
>>>>
>> gate->enable_refcnt is within clk-periph-gate which gets updated when
>> enable/disable callbacks get execute thru clk_core_enable/disable.
>> But actual enable_count used in clk_gate_restore_context is the one
>> which gets updated with in the clk core enable/disable functions which
>> invokes these callbacks. Depending on this enable_count in clk core it
>> invokes enable/disable.
>>
>> So, this will cause mismatch if we handle refcnt during save/restore
>> of tegra_clk_periph_gate_ops and also enable/disable thru this
>> clk_gate_restore_context is based on enable_count from clk core.
>>
>>>>> Also to align exact reset state along with CLK (like for case where
>>>>> CLK
>>>>> is enabled but peripheral might be in reset state), implemented
>>>>> save/restore in tegra specific tegra_clk_periph_gate_ops
>>>> I'm wondering whether instead of saving/restoring reset-state of every
>>>> clock, you could simply save/restore the whole RST_DEV_x_SET register.
>>>> Couldn't you?
>>> Thats what I was doing in first version of patch. But later as we
>>> moved to use clk_save_context and clk_restore_context, peripheral
>>> clk_hw RST & CLK enables happen thru its corresponding save/restore
>>> after source restore
>>
>>
>> Also, to align both CLK & RST to the exact state of register, doing
>> save/restore in tegra_clk_periph_gate_ops and invoking this after
>> source restore for peripheral clock, seems cleaner to avoid any
>> misconfiguration b/w rst & clk settings.
>>
It looks to me that it is very wasteful to store/restore each individual
gate and reset state, also given that some of them are shared. I think
that the gates and resets should be restored separately for the
peripherals by a custom tegra_clk_save/restore_periph_gates/resets().
^ permalink raw reply
* Re: [PATCH v7 07/20] clk: tegra: clk-periph: Add save and restore support
From: Dmitry Osipenko @ 2019-08-02 12:32 UTC (permalink / raw)
To: Sowjanya Komatineni, thierry.reding, jonathanh, tglx, jason,
marc.zyngier, linus.walleij, stefan, mark.rutland
Cc: pdeschrijver, pgaikwad, sboyd, linux-clk, linux-gpio, jckuo,
josephl, talho, linux-tegra, linux-kernel, mperttunen, spatra,
robh+dt, devicetree
In-Reply-To: <1564532424-10449-8-git-send-email-skomatineni@nvidia.com>
31.07.2019 3:20, Sowjanya Komatineni пишет:
> This patch implements save and restore context for peripheral fixed
> clock ops, peripheral gate clock ops, sdmmc mux clock ops, and
> peripheral clock ops.
>
> During system suspend, core power goes off and looses the settings
> of the Tegra CAR controller registers.
>
> So during suspend entry clock and reset state of peripherals is saved
> and on resume they are restored to have clocks back to same rate and
> state as before suspend.
>
> Acked-by: Thierry Reding <treding@nvidia.com>
> Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com>
> ---
> drivers/clk/tegra/clk-periph-fixed.c | 33 ++++++++++++++++++++++++++++++++
> drivers/clk/tegra/clk-periph-gate.c | 34 +++++++++++++++++++++++++++++++++
> drivers/clk/tegra/clk-periph.c | 37 ++++++++++++++++++++++++++++++++++++
> drivers/clk/tegra/clk-sdmmc-mux.c | 28 +++++++++++++++++++++++++++
> drivers/clk/tegra/clk.h | 6 ++++++
> 5 files changed, 138 insertions(+)
>
> diff --git a/drivers/clk/tegra/clk-periph-fixed.c b/drivers/clk/tegra/clk-periph-fixed.c
> index c088e7a280df..21b24530fa00 100644
> --- a/drivers/clk/tegra/clk-periph-fixed.c
> +++ b/drivers/clk/tegra/clk-periph-fixed.c
> @@ -60,11 +60,44 @@ tegra_clk_periph_fixed_recalc_rate(struct clk_hw *hw,
> return (unsigned long)rate;
> }
>
> +static int tegra_clk_periph_fixed_save_context(struct clk_hw *hw)
> +{
> + struct tegra_clk_periph_fixed *fixed = to_tegra_clk_periph_fixed(hw);
> + u32 mask = 1 << (fixed->num % 32);
This could be BIT(fixed->num % 32).
> + fixed->enb_ctx = readl_relaxed(fixed->base + fixed->regs->enb_reg) &
> + mask;
> + fixed->rst_ctx = readl_relaxed(fixed->base + fixed->regs->rst_reg) &
> + mask;
The enb_ctx/rst_ctx are booleans, while you assigning an integer value
here. You're getting away here because bool is an 32bit unsigned int,
but you shouldn't rely on it and always explicitly convert to a bool.
> + return 0;
> +}
> +
> +static void tegra_clk_periph_fixed_restore_context(struct clk_hw *hw)
> +{
> + struct tegra_clk_periph_fixed *fixed = to_tegra_clk_periph_fixed(hw);
> + u32 mask = 1 << (fixed->num % 32);
> +
> + if (fixed->enb_ctx)
> + writel_relaxed(mask, fixed->base + fixed->regs->enb_set_reg);
> + else
> + writel_relaxed(mask, fixed->base + fixed->regs->enb_clr_reg);
> +
> + udelay(2);
Will be better to read out and compare the hardware's state with the
restored one, then bail out if the state is unchanged.
Shouldn't it be fence_udelay()?
> + if (!fixed->rst_ctx) {
> + udelay(5); /* reset propogation delay */
Why delaying is done before the writing to the reset register?
> + writel_relaxed(mask, fixed->base + fixed->regs->rst_reg);
I'm not quite sure what's going on here, this looks wrong.
1. rst_reg points to RST_DEVICES_x
2. Each bit of RST_DEVICES_x represents the reset-assertion state of
each individual device
3. By writing to rst_reg, all (!) devices are deasserted, except the one
device which corresponds to the mask
4. The reset is asserted for a single device, while !fixed->rst_ctx
means that it actually should be deasserted (?)
Apparently you should use rst_set_reg / rst_clr_reg.
> + }
What about the case where rst_ctx=true?
> +}
> @@ -517,6 +517,8 @@ struct tegra_clk_periph_gate {
> int clk_num;
> int *enable_refcnt;
> const struct tegra_clk_periph_regs *regs;
> + bool clk_state_ctx;
> + bool rst_state_ctx;
> };
>
> #define to_clk_periph_gate(_hw) \
> @@ -543,6 +545,8 @@ struct tegra_clk_periph_fixed {
> unsigned int mul;
> unsigned int div;
> unsigned int num;
> + bool enb_ctx;
> + bool rst_ctx;
> };
I'd expect these to be bool:1.
^ permalink raw reply
* Re: [PATCH V13 12/12] PCI: tegra: Add Tegra194 PCIe support
From: Vidya Sagar @ 2019-08-02 12:06 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: bhelgaas, robh+dt, mark.rutland, thierry.reding, jonathanh,
kishon, catalin.marinas, will.deacon, jingoohan1,
gustavo.pimentel, digetx, mperttunen, linux-pci, devicetree,
linux-tegra, linux-kernel, linux-arm-kernel, kthota, mmaddireddy,
sagar.tv
In-Reply-To: <20190730154939.GA367@e121166-lin.cambridge.arm.com>
On 7/30/2019 9:19 PM, Lorenzo Pieralisi wrote:
> On Tue, Jul 23, 2019 at 08:14:08PM +0530, Vidya Sagar wrote:
>> On 7/16/2019 4:52 PM, Lorenzo Pieralisi wrote:
>>> On Sat, Jul 13, 2019 at 12:34:34PM +0530, Vidya Sagar wrote:
>>>
>>> [...]
>>>
>>>>>>>> +static int tegra_pcie_bpmp_set_ctrl_state(struct tegra_pcie_dw *pcie,
>>>>>>>> + bool enable)
>>>>>>>> +{
>>>>>>>> + struct mrq_uphy_response resp;
>>>>>>>> + struct tegra_bpmp_message msg;
>>>>>>>> + struct mrq_uphy_request req;
>>>>>>>> + int err;
>>>>>>>> +
>>>>>>>> + if (pcie->cid == 5)
>>>>>>>> + return 0;
>>>>>>>
>>>>>>> What's wrong with cid == 5 ? Explain please.
>>>>>> Controller with ID=5 doesn't need any programming to enable it which is
>>>>>> done here through calling firmware API.
>>>>>>
>>>>>>>
>>>>>>>> + memset(&req, 0, sizeof(req));
>>>>>>>> + memset(&resp, 0, sizeof(resp));
>>>>>>>> +
>>>>>>>> + req.cmd = CMD_UPHY_PCIE_CONTROLLER_STATE;
>>>>>>>> + req.controller_state.pcie_controller = pcie->cid;
>>>>>>>> + req.controller_state.enable = enable;
>>>>>>>> +
>>>>>>>> + memset(&msg, 0, sizeof(msg));
>>>>>>>> + msg.mrq = MRQ_UPHY;
>>>>>>>> + msg.tx.data = &req;
>>>>>>>> + msg.tx.size = sizeof(req);
>>>>>>>> + msg.rx.data = &resp;
>>>>>>>> + msg.rx.size = sizeof(resp);
>>>>>>>> +
>>>>>>>> + if (irqs_disabled())
>>>>>>>
>>>>>>> Can you explain to me what this check is meant to achieve please ?
>>>>>> Firmware interface provides different APIs to be called when there are
>>>>>> no interrupts enabled in the system (noirq context) and otherwise
>>>>>> hence checking that situation here and calling appropriate API.
>>>>>
>>>>> That's what I am questioning. Being called from {suspend/resume}_noirq()
>>>>> callbacks (if that's the code path this check caters for) does not mean
>>>>> irqs_disabled() == true.
>>>> Agree.
>>>> Actually, I got a hint of having this check from the following.
>>>> Both tegra_bpmp_transfer_atomic() and tegra_bpmp_transfer() are indirectly
>>>> called by APIs registered with .master_xfer() and .master_xfer_atomic() hooks of
>>>> struct i2c_algorithm and the decision to call which one of these is made using the
>>>> following check in i2c-core.h file.
>>>> static inline bool i2c_in_atomic_xfer_mode(void)
>>>> {
>>>> return system_state > SYSTEM_RUNNING && irqs_disabled();
>>>> }
>>>> I think I should use this condition as is IIUC.
>>>> Please let me know if there are any concerns with this.
>>>
>>> It is not a concern, it is just that I don't understand how this code
>>> can be called with IRQs disabled, if you can give me an execution path I
>>> am happy to leave the check there. On top of that, when called from
>>> suspend NOIRQ context, it is likely to use the blocking API (because
>>> IRQs aren't disabled at CPU level) behind which there is most certainly
>>> an IRQ required to wake the thread up and if the IRQ in question was
>>> disabled in the suspend NOIRQ phase this code is likely to deadlock.
>>>
>>> I want to make sure we can justify adding this check, I do not
>>> want to add it because we think it can be needed when it may not
>>> be needed at all (and it gets copy and pasted over and over again
>>> in other drivers).
>> I had a discussion internally about this and the prescribed usage of these APIs
>> seem to be that
>> use tegra_bpmp_transfer() in .probe() and other paths where interrupts are
>> enabled as this API needs interrupts to be enabled for its working.
>> Use tegra_bpmp_transfer_atomic() surrounded by local_irq_save()/local_irq_restore()
>> in other paths where interrupt servicing is disabled.
>
> Why tegra_bpmp_transfer_atomic() needs IRQs to be disabled ? And why
> is it needed in this piece of code where IRQs are _never_ disabled
> at CPU level ?
>
> IRQs are enabled when you call a suspend_noirq() callback, so the
> blocking API can be used as long as the IRQ descriptor backing
> the IRQ that will wake-up the blocked call is marked as
> IRQF_NO_SUSPEND.
>
> The problem is not IRQs enabled/disabled at CPU level, the problem is
> the IRQ descriptor of the IRQ required to handle the blocking BPMP call,
> mark it as IRQF_NO_SUSPEND and remove the tegra_bpmp_transfer_atomic()
> call from this code (or please give me a concrete example pinpointing
> why it is needed).
Ideally, using tegra_bpmp_transfer() alone in all paths (.probe() as well as .resume_noirq())
should have worked as the corresponding IRQ is already flagged as IRQF_NO_SUSPEND, but,
because of the way BPMP-FW driver in kernel making its interface available through .resume_early(),
tegra_bpmp_transfer() wasn't working as expected and I pushed a patch (CC'ing you) at
http://patchwork.ozlabs.org/patch/1140973/ to make it .resume_noirq() from .resume_early().
With that in place, we can just use tegra_bpmp_trasnfer().
I'll push a new patch with this change once my BPMP-FW driver patch is approved.
Thanks,
Vidya Sagar
>
> Thanks,
> Lorenzo
>
>> I'll go ahead and make next patch series with this if this looks fine to you.
>>
>>>
>>>>> Actually, if tegra_bpmp_transfer() requires IRQs to be enabled you may
>>>>> even end up in a situation where that blocking call does not wake up
>>>>> because the IRQ in question was disabled in the NOIRQ suspend/resume
>>>>> phase.
>>>>>
>>>>> [...]
>>>>>
>>>>>>>> +static int tegra_pcie_dw_probe(struct platform_device *pdev)
>>>>>>>> +{
>>>>>>>> + const struct tegra_pcie_soc *data;
>>>>>>>> + struct device *dev = &pdev->dev;
>>>>>>>> + struct resource *atu_dma_res;
>>>>>>>> + struct tegra_pcie_dw *pcie;
>>>>>>>> + struct resource *dbi_res;
>>>>>>>> + struct pcie_port *pp;
>>>>>>>> + struct dw_pcie *pci;
>>>>>>>> + struct phy **phys;
>>>>>>>> + char *name;
>>>>>>>> + int ret;
>>>>>>>> + u32 i;
>>>>>>>> +
>>>>>>>> + pcie = devm_kzalloc(dev, sizeof(*pcie), GFP_KERNEL);
>>>>>>>> + if (!pcie)
>>>>>>>> + return -ENOMEM;
>>>>>>>> +
>>>>>>>> + pci = &pcie->pci;
>>>>>>>> + pci->dev = &pdev->dev;
>>>>>>>> + pci->ops = &tegra_dw_pcie_ops;
>>>>>>>> + pp = &pci->pp;
>>>>>>>> + pcie->dev = &pdev->dev;
>>>>>>>> +
>>>>>>>> + data = (struct tegra_pcie_soc *)of_device_get_match_data(dev);
>>>>>>>> + if (!data)
>>>>>>>> + return -EINVAL;
>>>>>>>> + pcie->mode = (enum dw_pcie_device_mode)data->mode;
>>>>>>>> +
>>>>>>>> + ret = tegra_pcie_dw_parse_dt(pcie);
>>>>>>>> + if (ret < 0) {
>>>>>>>> + dev_err(dev, "Failed to parse device tree: %d\n", ret);
>>>>>>>> + return ret;
>>>>>>>> + }
>>>>>>>> +
>>>>>>>> + pcie->pex_ctl_supply = devm_regulator_get(dev, "vddio-pex-ctl");
>>>>>>>> + if (IS_ERR(pcie->pex_ctl_supply)) {
>>>>>>>> + dev_err(dev, "Failed to get regulator: %ld\n",
>>>>>>>> + PTR_ERR(pcie->pex_ctl_supply));
>>>>>>>> + return PTR_ERR(pcie->pex_ctl_supply);
>>>>>>>> + }
>>>>>>>> +
>>>>>>>> + pcie->core_clk = devm_clk_get(dev, "core");
>>>>>>>> + if (IS_ERR(pcie->core_clk)) {
>>>>>>>> + dev_err(dev, "Failed to get core clock: %ld\n",
>>>>>>>> + PTR_ERR(pcie->core_clk));
>>>>>>>> + return PTR_ERR(pcie->core_clk);
>>>>>>>> + }
>>>>>>>> +
>>>>>>>> + pcie->appl_res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
>>>>>>>> + "appl");
>>>>>>>> + if (!pcie->appl_res) {
>>>>>>>> + dev_err(dev, "Failed to find \"appl\" region\n");
>>>>>>>> + return PTR_ERR(pcie->appl_res);
>>>>>>>> + }
>>>>>>>> + pcie->appl_base = devm_ioremap_resource(dev, pcie->appl_res);
>>>>>>>> + if (IS_ERR(pcie->appl_base))
>>>>>>>> + return PTR_ERR(pcie->appl_base);
>>>>>>>> +
>>>>>>>> + pcie->core_apb_rst = devm_reset_control_get(dev, "apb");
>>>>>>>> + if (IS_ERR(pcie->core_apb_rst)) {
>>>>>>>> + dev_err(dev, "Failed to get APB reset: %ld\n",
>>>>>>>> + PTR_ERR(pcie->core_apb_rst));
>>>>>>>> + return PTR_ERR(pcie->core_apb_rst);
>>>>>>>> + }
>>>>>>>> +
>>>>>>>> + phys = devm_kcalloc(dev, pcie->phy_count, sizeof(*phys), GFP_KERNEL);
>>>>>>>> + if (!phys)
>>>>>>>> + return PTR_ERR(phys);
>>>>>>>> +
>>>>>>>> + for (i = 0; i < pcie->phy_count; i++) {
>>>>>>>> + name = kasprintf(GFP_KERNEL, "p2u-%u", i);
>>>>>>>> + if (!name) {
>>>>>>>> + dev_err(dev, "Failed to create P2U string\n");
>>>>>>>> + return -ENOMEM;
>>>>>>>> + }
>>>>>>>> + phys[i] = devm_phy_get(dev, name);
>>>>>>>> + kfree(name);
>>>>>>>> + if (IS_ERR(phys[i])) {
>>>>>>>> + ret = PTR_ERR(phys[i]);
>>>>>>>> + dev_err(dev, "Failed to get PHY: %d\n", ret);
>>>>>>>> + return ret;
>>>>>>>> + }
>>>>>>>> + }
>>>>>>>> +
>>>>>>>> + pcie->phys = phys;
>>>>>>>> +
>>>>>>>> + dbi_res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "dbi");
>>>>>>>> + if (!dbi_res) {
>>>>>>>> + dev_err(dev, "Failed to find \"dbi\" region\n");
>>>>>>>> + return PTR_ERR(dbi_res);
>>>>>>>> + }
>>>>>>>> + pcie->dbi_res = dbi_res;
>>>>>>>> +
>>>>>>>> + pci->dbi_base = devm_ioremap_resource(dev, dbi_res);
>>>>>>>> + if (IS_ERR(pci->dbi_base))
>>>>>>>> + return PTR_ERR(pci->dbi_base);
>>>>>>>> +
>>>>>>>> + /* Tegra HW locates DBI2 at a fixed offset from DBI */
>>>>>>>> + pci->dbi_base2 = pci->dbi_base + 0x1000;
>>>>>>>> +
>>>>>>>> + atu_dma_res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
>>>>>>>> + "atu_dma");
>>>>>>>> + if (!atu_dma_res) {
>>>>>>>> + dev_err(dev, "Failed to find \"atu_dma\" region\n");
>>>>>>>> + return PTR_ERR(atu_dma_res);
>>>>>>>> + }
>>>>>>>> + pcie->atu_dma_res = atu_dma_res;
>>>>>>>> + pci->atu_base = devm_ioremap_resource(dev, atu_dma_res);
>>>>>>>> + if (IS_ERR(pci->atu_base))
>>>>>>>> + return PTR_ERR(pci->atu_base);
>>>>>>>> +
>>>>>>>> + pcie->core_rst = devm_reset_control_get(dev, "core");
>>>>>>>> + if (IS_ERR(pcie->core_rst)) {
>>>>>>>> + dev_err(dev, "Failed to get core reset: %ld\n",
>>>>>>>> + PTR_ERR(pcie->core_rst));
>>>>>>>> + return PTR_ERR(pcie->core_rst);
>>>>>>>> + }
>>>>>>>> +
>>>>>>>> + pp->irq = platform_get_irq_byname(pdev, "intr");
>>>>>>>> + if (!pp->irq) {
>>>>>>>> + dev_err(dev, "Failed to get \"intr\" interrupt\n");
>>>>>>>> + return -ENODEV;
>>>>>>>> + }
>>>>>>>> +
>>>>>>>> + ret = devm_request_irq(dev, pp->irq, tegra_pcie_irq_handler,
>>>>>>>> + IRQF_SHARED, "tegra-pcie-intr", pcie);
>>>>>>>> + if (ret) {
>>>>>>>> + dev_err(dev, "Failed to request IRQ %d: %d\n", pp->irq, ret);
>>>>>>>> + return ret;
>>>>>>>> + }
>>>>>>>> +
>>>>>>>> + pcie->bpmp = tegra_bpmp_get(dev);
>>>>>>>> + if (IS_ERR(pcie->bpmp))
>>>>>>>> + return PTR_ERR(pcie->bpmp);
>>>>>>>> +
>>>>>>>> + platform_set_drvdata(pdev, pcie);
>>>>>>>> +
>>>>>>>> + if (pcie->mode == DW_PCIE_RC_TYPE) {
>>>>>>>> + ret = tegra_pcie_config_rp(pcie);
>>>>>>>> + if (ret && ret != -ENOMEDIUM)
>>>>>>>> + goto fail;
>>>>>>>> + else
>>>>>>>> + return 0;
>>>>>>>
>>>>>>> So if the link is not up we still go ahead and make probe
>>>>>>> succeed. What for ?
>>>>>> We may need root port to be available to support hot-plugging of
>>>>>> endpoint devices, so, we don't fail the probe.
>>>>>
>>>>> We need it or we don't. If you do support hotplugging of endpoint
>>>>> devices point me at the code, otherwise link up failure means
>>>>> failure to probe.
>>>> Currently hotplugging of endpoint is not supported, but it is one of
>>>> the use cases that we may add support for in future.
>>>
>>> You should elaborate on this, I do not understand what you mean,
>>> either the root port(s) supports hotplug or it does not.
>>>
>>>> But, why should we fail probe if link up doesn't happen? As such,
>>>> nothing went wrong in terms of root port initialization right? I
>>>> checked other DWC based implementations and following are not failing
>>>> the probe pci-dra7xx.c, pcie-armada8k.c, pcie-artpec6.c, pcie-histb.c,
>>>> pcie-kirin.c, pcie-spear13xx.c, pci-exynos.c, pci-imx6.c,
>>>> pci-keystone.c, pci-layerscape.c
>>>>
>>>> Although following do fail the probe if link is not up. pcie-qcom.c,
>>>> pcie-uniphier.c, pci-meson.c
>>>>
>>>> So, to me, it looks more like a choice we can make whether to fail the
>>>> probe or not and in this case we are choosing not to fail.
>>>
>>> I disagree. I had an offline chat with Bjorn and whether link-up should
>>> fail the probe or not depends on whether the root port(s) is hotplug
>>> capable or not and this in turn relies on the root port "Slot
>>> implemented" bit in the PCI Express capabilities register.
>>>
>>> It is a choice but it should be based on evidence.
>>>
>>> Lorenzo
>> With Bjorn's latest comment on top of this, I think we are good not to fail
>> the probe here.
>>
>> - Vidya Sagar
>>>
>>
^ permalink raw reply
* [PATCH v4 2/2] iio: light: noa1305: Add support for NOA1305
From: Martyn Welch @ 2019-08-02 11:42 UTC (permalink / raw)
To: Mark Rutland, Jonathan Cameron
Cc: Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler,
linux-iio, linux-kernel, kernel, devicetree, Martyn Welch,
Sergei M
In-Reply-To: <20190802114228.1278-1-martyn.welch@collabora.com>
This driver adds the initial support for the ON Semiconductor
NOA1305 Ambient Light Sensor.
Originally written by Sergei Miroshnichenko. Found here:
https://github.com/EmcraftSystems/linux-upstream/commit/196d6cf897e632d2cb82d45484bd7a1bfdd5b6d9
Signed-off-by: Sergei M <fizik1@yandex.com>
Signed-off-by: Martyn Welch <martyn.welch@collabora.com>
---
Changes:
v2:
- Correcting authorship and SOB.
v3:
- Improve register define naming.
- Follow IIO convention of interleaving register bit definitions with
register defintions.
- Use proper endian swapping.
- Process raw sensor count into Lux.
- Avoid setting variables to zero when not needed.
- Check return value of i2c writes.
- Implement disabling of regulator as a devm action.
- Remove excessive white spacing.
v4:
- Clean up returns
- Remove redundant noa1305_remove()
- Remove redundant interrupt configuration/disabling
- Return raw value and scaling
Note: Scaling added for all possible interation times to ensure the
mechanism utilised would allow this, though chip currently
statically configured to 800mS.
drivers/iio/light/Kconfig | 10 ++
drivers/iio/light/Makefile | 1 +
drivers/iio/light/noa1305.c | 312 ++++++++++++++++++++++++++++++++++++
3 files changed, 323 insertions(+)
create mode 100644 drivers/iio/light/noa1305.c
diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig
index 954c958cfc43..d1db0ec0d0f5 100644
--- a/drivers/iio/light/Kconfig
+++ b/drivers/iio/light/Kconfig
@@ -309,6 +309,16 @@ config MAX44009
To compile this driver as a module, choose M here:
the module will be called max44009.
+config NOA1305
+ tristate "ON Semiconductor NOA1305 ambient light sensor"
+ depends on I2C
+ help
+ Say Y here if you want to build support for the ON Semiconductor
+ NOA1305 ambient light sensor.
+
+ To compile this driver as a module, choose M here:
+ The module will be called noa1305.
+
config OPT3001
tristate "Texas Instruments OPT3001 Light Sensor"
depends on I2C
diff --git a/drivers/iio/light/Makefile b/drivers/iio/light/Makefile
index e40794fbb435..00d1f9b98f39 100644
--- a/drivers/iio/light/Makefile
+++ b/drivers/iio/light/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_LTR501) += ltr501.o
obj-$(CONFIG_LV0104CS) += lv0104cs.o
obj-$(CONFIG_MAX44000) += max44000.o
obj-$(CONFIG_MAX44009) += max44009.o
+obj-$(CONFIG_NOA1305) += noa1305.o
obj-$(CONFIG_OPT3001) += opt3001.o
obj-$(CONFIG_PA12203001) += pa12203001.o
obj-$(CONFIG_RPR0521) += rpr0521.o
diff --git a/drivers/iio/light/noa1305.c b/drivers/iio/light/noa1305.c
new file mode 100644
index 000000000000..b8758aa7b32a
--- /dev/null
+++ b/drivers/iio/light/noa1305.c
@@ -0,0 +1,312 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Support for ON Semiconductor NOA1305 ambient light sensor
+ *
+ * Copyright (C) 2016 Emcraft Systems
+ * Copyright (C) 2019 Collabora Ltd.
+ */
+
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/i2c.h>
+#include <linux/iio/iio.h>
+#include <linux/iio/sysfs.h>
+#include <linux/module.h>
+#include <linux/regmap.h>
+#include <linux/regulator/consumer.h>
+
+#define NOA1305_REG_POWER_CONTROL 0x0
+#define NOA1305_POWER_CONTROL_DOWN 0x00
+#define NOA1305_POWER_CONTROL_ON 0x08
+#define NOA1305_REG_RESET 0x1
+#define NOA1305_RESET_RESET 0x10
+#define NOA1305_REG_INTEGRATION_TIME 0x2
+#define NOA1305_INTEGR_TIME_800MS 0x00
+#define NOA1305_INTEGR_TIME_400MS 0x01
+#define NOA1305_INTEGR_TIME_200MS 0x02
+#define NOA1305_INTEGR_TIME_100MS 0x03
+#define NOA1305_INTEGR_TIME_50MS 0x04
+#define NOA1305_INTEGR_TIME_25MS 0x05
+#define NOA1305_INTEGR_TIME_12_5MS 0x06
+#define NOA1305_INTEGR_TIME_6_25MS 0x07
+#define NOA1305_REG_INT_SELECT 0x3
+#define NOA1305_INT_SEL_ACTIVE_HIGH 0x01
+#define NOA1305_INT_SEL_ACTIVE_LOW 0x02
+#define NOA1305_INT_SEL_INACTIVE 0x03
+#define NOA1305_REG_INT_THRESH_LSB 0x4
+#define NOA1305_REG_INT_THRESH_MSB 0x5
+#define NOA1305_REG_ALS_DATA_LSB 0x6
+#define NOA1305_REG_ALS_DATA_MSB 0x7
+#define NOA1305_REG_DEVICE_ID_LSB 0x8
+#define NOA1305_REG_DEVICE_ID_MSB 0x9
+
+#define NOA1305_DEVICE_ID 0x0519
+#define NOA1305_DRIVER_NAME "noa1305"
+
+struct noa1305_priv {
+ struct i2c_client *client;
+ struct regmap *regmap;
+ struct regulator *vin_reg;
+};
+
+static int noa1305_measure(struct noa1305_priv *priv)
+{
+ __le16 data;
+ int ret;
+
+ ret = regmap_bulk_read(priv->regmap, NOA1305_REG_ALS_DATA_LSB, &data,
+ 2);
+ if (ret < 0)
+ return ret;
+
+ return le16_to_cpu(data);
+}
+
+static int noa1305_scale(struct noa1305_priv *priv, int *val, int *val2)
+{
+ int data;
+ int ret;
+
+ ret = regmap_read(priv->regmap, NOA1305_REG_INTEGRATION_TIME, &data);
+ if (ret < 0)
+ return ret;
+
+ /*
+ * Lux = count / (<Integration Constant> * <Integration Time>)
+ *
+ * Integration Constant = 7.7
+ * Integration Time in Seconds
+ */
+ switch (data) {
+ case NOA1305_INTEGR_TIME_800MS:
+ *val = 100;
+ *val2 = 77 * 8;
+ break;
+ case NOA1305_INTEGR_TIME_400MS:
+ *val = 100;
+ *val2 = 77 * 4;
+ case NOA1305_INTEGR_TIME_200MS:
+ *val = 100;
+ *val2 = 77 * 2;
+ break;
+ case NOA1305_INTEGR_TIME_100MS:
+ *val = 100;
+ *val2 = 77;
+ break;
+ case NOA1305_INTEGR_TIME_50MS:
+ *val = 1000;
+ *val2 = 77 * 5;
+ break;
+ case NOA1305_INTEGR_TIME_25MS:
+ *val = 10000;
+ *val2 = 77 * 25;
+ break;
+ case NOA1305_INTEGR_TIME_12_5MS:
+ *val = 100000;
+ *val2 = 77 * 125;
+ break;
+ case NOA1305_INTEGR_TIME_6_25MS:
+ *val = 1000000;
+ *val2 = 77 * 625;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return IIO_VAL_FRACTIONAL;
+}
+
+static const struct iio_chan_spec noa1305_channels[] = {
+ {
+ .type = IIO_LIGHT,
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
+ .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE),
+ }
+};
+
+static int noa1305_read_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ int *val, int *val2, long mask)
+{
+ int ret = -EINVAL;
+ struct noa1305_priv *priv = iio_priv(indio_dev);
+
+ switch (mask) {
+ case IIO_CHAN_INFO_RAW:
+ switch (chan->type) {
+ case IIO_LIGHT:
+ ret = noa1305_measure(priv);
+ if (ret < 0)
+ return ret;
+ *val = ret;
+ return IIO_VAL_INT;
+ default:
+ break;
+ }
+ break;
+ case IIO_CHAN_INFO_SCALE:
+ switch (chan->type) {
+ case IIO_LIGHT:
+ return noa1305_scale(priv, val, val2);
+ default:
+ break;
+ }
+ break;
+ default:
+ break;
+ }
+
+ return ret;
+}
+
+static const struct iio_info noa1305_info = {
+ .read_raw = noa1305_read_raw,
+};
+
+static bool noa1305_writable_reg(struct device *dev, unsigned int reg)
+{
+ switch (reg) {
+ case NOA1305_REG_POWER_CONTROL:
+ case NOA1305_REG_RESET:
+ case NOA1305_REG_INTEGRATION_TIME:
+ case NOA1305_REG_INT_SELECT:
+ case NOA1305_REG_INT_THRESH_LSB:
+ case NOA1305_REG_INT_THRESH_MSB:
+ return true;
+ default:
+ return false;
+ }
+}
+
+static const struct regmap_config noa1305_regmap_config = {
+ .name = NOA1305_DRIVER_NAME,
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = NOA1305_REG_DEVICE_ID_MSB,
+ .writeable_reg = noa1305_writable_reg,
+};
+
+static void noa1305_reg_remove(void *data)
+{
+ struct noa1305_priv *priv = data;
+
+ regulator_disable(priv->vin_reg);
+}
+
+static int noa1305_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ struct noa1305_priv *priv;
+ struct iio_dev *indio_dev;
+ struct regmap *regmap;
+ __le16 data;
+ unsigned int dev_id;
+ int ret;
+
+ indio_dev = devm_iio_device_alloc(&client->dev, sizeof(*priv));
+ if (!indio_dev)
+ return -ENOMEM;
+
+ regmap = devm_regmap_init_i2c(client, &noa1305_regmap_config);
+ if (IS_ERR(regmap)) {
+ dev_err(&client->dev, "Regmap initialization failed.\n");
+ return PTR_ERR(regmap);
+ }
+
+ priv = iio_priv(indio_dev);
+
+ priv->vin_reg = devm_regulator_get(&client->dev, "vin");
+ if (IS_ERR(priv->vin_reg)) {
+ dev_err(&client->dev, "get regulator vin failed\n");
+ return PTR_ERR(priv->vin_reg);
+ }
+
+ ret = regulator_enable(priv->vin_reg);
+ if (ret) {
+ dev_err(&client->dev, "enable regulator vin failed\n");
+ return ret;
+ }
+
+ ret = devm_add_action_or_reset(&client->dev, noa1305_reg_remove, priv);
+ if (ret) {
+ dev_err(&client->dev, "addition of devm action failed\n");
+ return ret;
+ }
+
+ i2c_set_clientdata(client, indio_dev);
+ priv->client = client;
+ priv->regmap = regmap;
+
+ ret = regmap_bulk_read(regmap, NOA1305_REG_DEVICE_ID_LSB, &data, 2);
+ if (ret < 0) {
+ dev_err(&client->dev, "ID reading failed: %d\n", ret);
+ return ret;
+ }
+
+ dev_id = le16_to_cpu(data);
+ if (dev_id != NOA1305_DEVICE_ID) {
+ dev_err(&client->dev, "Unknown device ID: 0x%x\n", dev_id);
+ return -ENODEV;
+ }
+
+ ret = regmap_write(regmap, NOA1305_REG_POWER_CONTROL,
+ NOA1305_POWER_CONTROL_ON);
+ if (ret < 0) {
+ dev_err(&client->dev, "Enabling power control failed\n");
+ return ret;
+ }
+
+ ret = regmap_write(regmap, NOA1305_REG_RESET, NOA1305_RESET_RESET);
+ if (ret < 0) {
+ dev_err(&client->dev, "Device reset failed\n");
+ return ret;
+ }
+
+ ret = regmap_write(regmap, NOA1305_REG_INTEGRATION_TIME,
+ NOA1305_INTEGR_TIME_800MS);
+ if (ret < 0) {
+ dev_err(&client->dev, "Setting integration time failed\n");
+ return ret;
+ }
+
+ indio_dev->dev.parent = &client->dev;
+ indio_dev->info = &noa1305_info;
+ indio_dev->channels = noa1305_channels;
+ indio_dev->num_channels = ARRAY_SIZE(noa1305_channels);
+ indio_dev->name = NOA1305_DRIVER_NAME;
+ indio_dev->modes = INDIO_DIRECT_MODE;
+
+ ret = devm_iio_device_register(&client->dev, indio_dev);
+ if (ret)
+ dev_err(&client->dev, "registering device failed\n");
+
+ return ret;
+}
+
+static const struct of_device_id noa1305_of_match[] = {
+ { .compatible = "onnn,noa1305" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, noa1305_of_match);
+
+static const struct i2c_device_id noa1305_ids[] = {
+ { "noa1305", 0 },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, noa1305_id);
+
+static struct i2c_driver noa1305_driver = {
+ .driver = {
+ .name = NOA1305_DRIVER_NAME,
+ .of_match_table = noa1305_of_match,
+ },
+ .probe = noa1305_probe,
+ .id_table = noa1305_ids,
+};
+
+module_i2c_driver(noa1305_driver);
+
+MODULE_AUTHOR("Sergei Miroshnichenko <sergeimir@emcraft.com>");
+MODULE_AUTHOR("Martyn Welch <martyn.welch@collabora.com");
+MODULE_DESCRIPTION("ON Semiconductor NOA1305 ambient light sensor");
+MODULE_LICENSE("GPL");
--
2.20.1
^ permalink raw reply related
* [PATCH v4 1/2] dt-bindings: Add binding document for NOA1305
From: Martyn Welch @ 2019-08-02 11:42 UTC (permalink / raw)
To: Mark Rutland, Jonathan Cameron
Cc: Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler,
linux-iio, linux-kernel, kernel, devicetree, Martyn Welch,
Rob Herring
Document the ON Semiconductor NOA1305 ambient light sensor devicetree
bindings.
Signed-off-by: Martyn Welch <martyn.welch@collabora.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Changes:
v2: Same as v1.
v3: Same as v2.
v4: Same as v3.
.../bindings/iio/light/noa1305.yaml | 44 +++++++++++++++++++
1 file changed, 44 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/light/noa1305.yaml
diff --git a/Documentation/devicetree/bindings/iio/light/noa1305.yaml b/Documentation/devicetree/bindings/iio/light/noa1305.yaml
new file mode 100644
index 000000000000..17e7f140b69b
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/light/noa1305.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/light/noa1305.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ON Semiconductor NOA1305 Ambient Light Sensor
+
+maintainers:
+ - Martyn Welch <martyn.welch@collabora.com>
+
+description: |
+ Ambient sensing with an i2c interface.
+
+ https://www.onsemi.com/pub/Collateral/NOA1305-D.PDF
+
+properties:
+ compatible:
+ enum:
+ - onnn,noa1305
+
+ reg:
+ maxItems: 1
+
+ vin-supply:
+ description: Regulator that provides power to the sensor
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ i2c {
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ light@39 {
+ compatible = "onnn,noa1305";
+ reg = <0x39>;
+ };
+ };
+...
--
2.20.1
^ permalink raw reply related
* Re: [alsa-devel] [PATCH v2 3/3] ASoC: TDA7802: Add turn-on diagnostic routine
From: Mark Brown @ 2019-08-02 11:10 UTC (permalink / raw)
To: Thomas Preston
Cc: Mark Rutland, devicetree, alsa-devel, Charles Keepax,
Kuninori Morimoto, Kirill Marinushkin, Liam Girdwood,
Marco Felsch, Annaliese McDermond, Takashi Iwai, Paul Cercueil,
Vinod Koul, Rob Herring, Srinivas Kandagatla, Jerome Brunet,
linux-kernel, Cheng-Yi Chiang
In-Reply-To: <472cc4ee-2e80-8b08-d842-79c65df572f3@codethink.co.uk>
[-- Attachment #1: Type: text/plain, Size: 959 bytes --]
On Fri, Aug 02, 2019 at 09:32:17AM +0100, Thomas Preston wrote:
> On 02/08/2019 00:42, Mark Brown wrote:
> > Yes, that's definitely doable - we've got some other drivers with
> > similar things like calibration triggers exposed that way.
> One problem with using a kcontrol as a trigger for the turn-on diagnostic
> is that the diagnostic routine has a "return value".
You can use a read only control for the readback, or just have it be
triggered by overwriting the readback value. You can cache the result.
> Hm, maybe a better idea is to have the turn on diagnostic only run on
> device probe (as its name suggests!), and print something to dmesg:
> modprobe tda7802 turn_on_diagnostic=1
> tda7802-codec i2c-TDA7802:00: Turn on diagnostic 04 04 04 04
> Kirill Marinushkin mentioned this in the first review [0], it just didn't
> really sink in until now!
You could do that too, yeah. Depends on what this is diagnosing and if
that'd be useful.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 1/4] mailbox: arm_mhuv2: add device tree binding documentation
From: Sudeep Holla @ 2019-08-02 10:59 UTC (permalink / raw)
To: Jassi Brar
Cc: Tushar Khandelwal, Linux Kernel Mailing List, tushar.2nov,
morten_bp, nd, Morten Borup Petersen, Rob Herring, Mark Rutland,
Devicetree List, Sudeep Holla
In-Reply-To: <CABb+yY04vW-i35N6P57KSKgmMAYkrA2CDyUvA-bLCZMxiZaocw@mail.gmail.com>
On Sun, Jul 21, 2019 at 04:58:04PM -0500, Jassi Brar wrote:
> On Wed, Jul 17, 2019 at 2:26 PM Tushar Khandelwal
> <tushar.khandelwal@arm.com> wrote:
>
> > diff --git a/Documentation/devicetree/bindings/mailbox/arm,mhuv2.txt b/Documentation/devicetree/bindings/mailbox/arm,mhuv2.txt
> > new file mode 100644
> > index 000000000000..3a05593414bc
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mailbox/arm,mhuv2.txt
> > @@ -0,0 +1,108 @@
> > +Arm MHUv2 Mailbox Driver
> > +========================
> > +
> > +The Arm Message-Handling-Unit (MHU) Version 2 is a mailbox controller that has
> > +between 1 and 124 channel windows to provide unidirectional communication with
> > +remote processor(s).
> > +
> > +Given the unidirectional nature of the device, an MHUv2 mailbox may only be
> > +written to or read from. If a pair of MHU devices is implemented between two
> > +processing elements to provide bidirectional communication, these must be
> > +specified as two separate mailboxes.
> > +
> > +A device tree node for an Arm MHUv2 device must specify either a receiver frame
> > +or a sender frame, indicating which end of the unidirectional MHU device which
> > +the device node entry describes.
> > +
> > +An MHU device must be specified with a transport protocol. The transport
> > +protocol of an MHU device determines the method of data transmission as well as
> > +the number of provided mailboxes.
> > +Following are the possible transport protocol types:
> > +- Single-word: An MHU device implements as many mailboxes as it
> > + provides channel windows. Data is transmitted through
> > + the MHU registers.
> > +- Multi-word: An MHU device implements a single mailbox. All channel windows
> > + will be used during transmission. Data is transmitted through
> > + the MHU registers.
> > +- Doorbell: An MHU device implements as many mailboxes as there are flag
> > + bits available in its channel windows. Optionally, data may
> > + be transmitted through a shared memory region, wherein the MHU
> > + is used strictly as an interrupt generation mechanism.
> > +
> > +Mailbox Device Node:
> > +====================
> > +
> > +Required properties:
> > +--------------------
> > +- compatible: Shall be "arm,mhuv2" & "arm,primecell"
> > +- reg: Contains the mailbox register address range (base
> > + address and length)
> > +- #mbox-cells Shall be 1 - the index of the channel needed.
> > +- mhu-frame Frame type of the device.
> > + Shall be either "sender" or "receiver"
> > +- mhu-protocol Transport protocol of the device. Shall be one of the
> > + following: "single-word", "multi-word", "doorbell"
> > +
> > +Required properties (receiver frame):
> > +-------------------------------------
> > +- interrupts: Contains the interrupt information corresponding to the
> > + combined interrupt of the receiver frame
> > +
> > +Example:
> > +--------
> > +
> > + mbox_mw_tx: mhu@10000000 {
> > + compatible = "arm,mhuv2","arm,primecell";
> > + reg = <0x10000000 0x1000>;
> > + clocks = <&refclk100mhz>;
> > + clock-names = "apb_pclk";
> > + #mbox-cells = <1>;
> > + mhu-protocol = "multi-word";
> > + mhu-frame = "sender";
> > + };
> > +
> > + mbox_sw_tx: mhu@10000000 {
> > + compatible = "arm,mhuv2","arm,primecell";
> > + reg = <0x11000000 0x1000>;
> > + clocks = <&refclk100mhz>;
> > + clock-names = "apb_pclk";
> > + #mbox-cells = <1>;
> > + mhu-protocol = "single-word";
> > + mhu-frame = "sender";
> > + };
> > +
> > + mbox_db_rx: mhu@10000000 {
> > + compatible = "arm,mhuv2","arm,primecell";
> > + reg = <0x12000000 0x1000>;
> > + clocks = <&refclk100mhz>;
> > + clock-names = "apb_pclk";
> > + #mbox-cells = <1>;
> > + interrupts = <0 45 4>;
> > + interrupt-names = "mhu_rx";
> > + mhu-protocol = "doorbell";
> > + mhu-frame = "receiver";
> > + };
> > +
> > + mhu_client: scb@2e000000 {
> > + compatible = "fujitsu,mb86s70-scb-1.0";
> > + reg = <0 0x2e000000 0x4000>;
> > + mboxes =
> > + // For multi-word frames, client may only instantiate a single
> > + // mailbox for a mailbox controller
> > + <&mbox_mw_tx 0>,
> > +
> > + // For single-word frames, client may instantiate as many
> > + // mailboxes as there are channel windows in the MHU
> > + <&mbox_sw_tx 0>,
> > + <&mbox_sw_tx 1>,
> > + <&mbox_sw_tx 2>,
> > + <&mbox_sw_tx 3>,
> > +
> > + // For doorbell frames, client may instantiate as many mailboxes
> > + // as there are bits available in the combined number of channel
> > + // windows ((channel windows * 32) mailboxes)
> > + <mbox_db_rx 0>,
> > + <mbox_db_rx 1>,
> > + ...
> > + <mbox_db_rx 17>;
> > + };
>
> If the mhuv2 instance implements, say, 3 channel windows between
> sender (linux) and receiver (firmware), and Linux runs two protocols
> each requiring 1 and 2-word sized messages respectively. The hardware
> supports that by assigning windows [0] and [1,2] to each protocol.
> However, I don't think the driver can support that. Or does it?
>
FWIW, the IP is designed to cover wide range of usecase from IoT to servers
with variable window length. I don't see the need to complicate the driver
supporting mix-n-match at the cost of latency. Each platform choose one
transport protocol for all it's use.
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH 1/4] mailbox: arm_mhuv2: add device tree binding documentation
From: Sudeep Holla @ 2019-08-02 10:53 UTC (permalink / raw)
To: Jassi Brar
Cc: Tushar Khandelwal, Linux Kernel Mailing List, tushar.2nov,
morten_bp, nd, Morten Borup Petersen, Rob Herring, Mark Rutland,
Devicetree List, Sudeep Holla
In-Reply-To: <CABb+yY1SeHTgZQNAHJW+dZG=khah5c5igtKy+MrjADnZF29Aow@mail.gmail.com>
On Thu, Jul 25, 2019 at 12:49:58AM -0500, Jassi Brar wrote:
> On Sun, Jul 21, 2019 at 4:58 PM Jassi Brar <jassisinghbrar@gmail.com> wrote:
> >
[...]
> > If the mhuv2 instance implements, say, 3 channel windows between
> > sender (linux) and receiver (firmware), and Linux runs two protocols
> > each requiring 1 and 2-word sized messages respectively. The hardware
> > supports that by assigning windows [0] and [1,2] to each protocol.
> > However, I don't think the driver can support that. Or does it?
> >
> Thinking about it, IMO, the mbox-cell should carry a 128 (4x32) bit
> mask specifying the set of windows (corresponding to the bits set in
> the mask) associated with the channel.
> And the controller driver should see any channel as associated with
> variable number of windows 'N', where N is [0,124]
>
> mhu_client1: proto1@2e000000 {
> .....
> mboxes = <&mbox 0x0 0x0 0x0 0x1>
> }
>
> mhu_client2: proto2@2f000000 {
> .....
> mboxes = <&mbox 0x0 0x0 0x0 0x6>
> }
>
This still doesn't address the overhead I mentioned in my arm_mhu_v1
series.
As per you suggestion, we will have one channel with all possible
bit mask value to specify the window. Let's imagine that 2 protocols
share the same channel, then the requests are serialised.
E.g. if bits 0 and 1 are allocated for say protocol#1 and bits 2 and 3
for protocol#2.
Further protocol#1 has higher latency requirements like sched-governor
DVFS and there are 3-4 pending requests on protocol#2, then the incoming
requests for protocol#1 is blocked.
This is definitely overhead and I have seen lots of issue around this
and hence I was requesting that we need to create individual channels
for each of these. Having abstraction on top to multiplex or arbitrate
won't help.
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH 1/4] mailbox: arm_mhuv2: add device tree binding documentation
From: Morten Borup Petersen @ 2019-08-02 10:41 UTC (permalink / raw)
To: Jassi Brar
Cc: Tushar Khandelwal, Linux Kernel Mailing List,
tushar.2nov@gmail.com, nd@arm.com, Morten Borup Petersen,
Rob Herring, Mark Rutland, Devicetree List
In-Reply-To: <CABb+yY3yMWbUiQnJgfQhwnW1OM3aoFL3ZFc018E-fxGichi-4Q@mail.gmail.com>
On 7/31/19 9:31 AM, Jassi Brar wrote:
> On Sun, Jul 28, 2019 at 4:28 PM Morten Borup Petersen <morten_bp@live.dk> wrote:
>>
>>
>>
>> On 7/25/19 7:49 AM, Jassi Brar wrote:
>>> On Sun, Jul 21, 2019 at 4:58 PM Jassi Brar <jassisinghbrar@gmail.com> wrote:
>>>>
>>>> On Wed, Jul 17, 2019 at 2:26 PM Tushar Khandelwal
>>>> <tushar.khandelwal@arm.com> wrote:
>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/mailbox/arm,mhuv2.txt b/Documentation/devicetree/bindings/mailbox/arm,mhuv2.txt
>>>>> new file mode 100644
>>>>> index 000000000000..3a05593414bc
>>>>> --- /dev/null
>>>>> +++ b/Documentation/devicetree/bindings/mailbox/arm,mhuv2.txt
>>>>> @@ -0,0 +1,108 @@
>>>>> +Arm MHUv2 Mailbox Driver
>>>>> +========================
>>>>> +
>>>>> +The Arm Message-Handling-Unit (MHU) Version 2 is a mailbox controller that has
>>>>> +between 1 and 124 channel windows to provide unidirectional communication with
>>>>> +remote processor(s).
>>>>> +
>>>>> +Given the unidirectional nature of the device, an MHUv2 mailbox may only be
>>>>> +written to or read from. If a pair of MHU devices is implemented between two
>>>>> +processing elements to provide bidirectional communication, these must be
>>>>> +specified as two separate mailboxes.
>>>>> +
>>>>> +A device tree node for an Arm MHUv2 device must specify either a receiver frame
>>>>> +or a sender frame, indicating which end of the unidirectional MHU device which
>>>>> +the device node entry describes.
>>>>> +
>>>>> +An MHU device must be specified with a transport protocol. The transport
>>>>> +protocol of an MHU device determines the method of data transmission as well as
>>>>> +the number of provided mailboxes.
>>>>> +Following are the possible transport protocol types:
>>>>> +- Single-word: An MHU device implements as many mailboxes as it
>>>>> + provides channel windows. Data is transmitted through
>>>>> + the MHU registers.
>>>>> +- Multi-word: An MHU device implements a single mailbox. All channel windows
>>>>> + will be used during transmission. Data is transmitted through
>>>>> + the MHU registers.
>>>>> +- Doorbell: An MHU device implements as many mailboxes as there are flag
>>>>> + bits available in its channel windows. Optionally, data may
>>>>> + be transmitted through a shared memory region, wherein the MHU
>>>>> + is used strictly as an interrupt generation mechanism.
>>>>> +
>>>>> +Mailbox Device Node:
>>>>> +====================
>>>>> +
>>>>> +Required properties:
>>>>> +--------------------
>>>>> +- compatible: Shall be "arm,mhuv2" & "arm,primecell"
>>>>> +- reg: Contains the mailbox register address range (base
>>>>> + address and length)
>>>>> +- #mbox-cells Shall be 1 - the index of the channel needed.
>>>>> +- mhu-frame Frame type of the device.
>>>>> + Shall be either "sender" or "receiver"
>>>>> +- mhu-protocol Transport protocol of the device. Shall be one of the
>>>>> + following: "single-word", "multi-word", "doorbell"
>>>>> +
>>>>> +Required properties (receiver frame):
>>>>> +-------------------------------------
>>>>> +- interrupts: Contains the interrupt information corresponding to the
>>>>> + combined interrupt of the receiver frame
>>>>> +
>>>>> +Example:
>>>>> +--------
>>>>> +
>>>>> + mbox_mw_tx: mhu@10000000 {
>>>>> + compatible = "arm,mhuv2","arm,primecell";
>>>>> + reg = <0x10000000 0x1000>;
>>>>> + clocks = <&refclk100mhz>;
>>>>> + clock-names = "apb_pclk";
>>>>> + #mbox-cells = <1>;
>>>>> + mhu-protocol = "multi-word";
>>>>> + mhu-frame = "sender";
>>>>> + };
>>>>> +
>>>>> + mbox_sw_tx: mhu@10000000 {
>>>>> + compatible = "arm,mhuv2","arm,primecell";
>>>>> + reg = <0x11000000 0x1000>;
>>>>> + clocks = <&refclk100mhz>;
>>>>> + clock-names = "apb_pclk";
>>>>> + #mbox-cells = <1>;
>>>>> + mhu-protocol = "single-word";
>>>>> + mhu-frame = "sender";
>>>>> + };
>>>>> +
>>>>> + mbox_db_rx: mhu@10000000 {
>>>>> + compatible = "arm,mhuv2","arm,primecell";
>>>>> + reg = <0x12000000 0x1000>;
>>>>> + clocks = <&refclk100mhz>;
>>>>> + clock-names = "apb_pclk";
>>>>> + #mbox-cells = <1>;
>>>>> + interrupts = <0 45 4>;
>>>>> + interrupt-names = "mhu_rx";
>>>>> + mhu-protocol = "doorbell";
>>>>> + mhu-frame = "receiver";
>>>>> + };
>>>>> +
>>>>> + mhu_client: scb@2e000000 {
>>>>> + compatible = "fujitsu,mb86s70-scb-1.0";
>>>>> + reg = <0 0x2e000000 0x4000>;
>>>>> + mboxes =
>>>>> + // For multi-word frames, client may only instantiate a single
>>>>> + // mailbox for a mailbox controller
>>>>> + <&mbox_mw_tx 0>,
>>>>> +
>>>>> + // For single-word frames, client may instantiate as many
>>>>> + // mailboxes as there are channel windows in the MHU
>>>>> + <&mbox_sw_tx 0>,
>>>>> + <&mbox_sw_tx 1>,
>>>>> + <&mbox_sw_tx 2>,
>>>>> + <&mbox_sw_tx 3>,
>>>>> +
>>>>> + // For doorbell frames, client may instantiate as many mailboxes
>>>>> + // as there are bits available in the combined number of channel
>>>>> + // windows ((channel windows * 32) mailboxes)
>>>>> + <mbox_db_rx 0>,
>>>>> + <mbox_db_rx 1>,
>>>>> + ...
>>>>> + <mbox_db_rx 17>;
>>>>> + };
>>>>
>>>> If the mhuv2 instance implements, say, 3 channel windows between
>>>> sender (linux) and receiver (firmware), and Linux runs two protocols
>>>> each requiring 1 and 2-word sized messages respectively. The hardware
>>>> supports that by assigning windows [0] and [1,2] to each protocol.
>>>> However, I don't think the driver can support that. Or does it?
>>>>
>>> Thinking about it, IMO, the mbox-cell should carry a 128 (4x32) bit
>>> mask specifying the set of windows (corresponding to the bits set in
>>> the mask) associated with the channel.
>>> And the controller driver should see any channel as associated with
>>> variable number of windows 'N', where N is [0,124]
>>>
>>> mhu_client1: proto1@2e000000 {
>>> .....
>>> mboxes = <&mbox 0x0 0x0 0x0 0x1>
>>> }
>>>
>>> mhu_client2: proto2@2f000000 {
>>> .....
>>> mboxes = <&mbox 0x0 0x0 0x0 0x6>
>>> }
>>>
>>> Cheers!
>>>
>>
>> As mentioned in the response to your initial comment, the driver does
>> not currently support mixing protocols.
>>
> Thanks for acknowledging that limitation. But lets also address it.
>
We are hesitant to dedicate time to developing mixing protocols given
that we don't have any current usecase nor any current platform which
would support this.
>> If mixing protocols is to be supported in the future, then this seems
>> like a suitable way of specifying which channels are associated with
>> which mailboxes (especially for mixing single- and multi-word modes).
>>
> We can not change DT bindings again when we feel like updating the driver.
> The bindings should precisely and completely define the h/w, not what
> mode we currently implement.
> It is not for pure idealism, it actually makes the code simpler and futureproof.
>
>> However, there still is an issue in that both single-word and doorbell
>> requires only 1 channel window - and as such, the transport protocol
>> cannot be deduced from merely the number of masked channel windows.
>>
> I don't see why the driver should worry -- the channel carries 32-bit
> message or some random value just to trigger an interrupt is purely
> upto the client driver.
>
With the current design, it is not up to the client driver to
distinguish which bit was set within a channel window when an interrupt
was raised in doorbell mode. Currently, in doorbell mode, each bit
within a channel isspecified to be a distinct mailbox. Having this,
different mailbox clients may register mailboxes for different bits
within a single MHU device.
with the current design, when an interrupt is raised and an MHU is in
doorbell mode, the MHU driver will be responsible for deducing which
flag bit was set and from this set bit decide which mailbox to trigger a
callback on.
This is why we need to be able to specify the bit number when in
doorbell mode, in the device tree.
>> Furthermore, for doorbell, a mbox may be registered for _each_ available
>> bit within a channel window (further complicating things if we were to
>> include mixing protocols in this initial driver version), making
>> assigning channel windows to mailboxes semantically different from when
>> assigning to single- or multi-word.
>>
> Not sure about that, that would be implementing virtual channels. Each
> window carries one signal, and that is the minimum bandwidth assigned
> to a channel.
>
> Thanks
>
If implementing transport protocol mixing would be a requirement for the
acceptance of the driver, then we agree on that the format which you've
suggested would be a clean solution. However, given that we would like
to keep the ability to specify doorbell mailboxes in the device tree, we
suggest a format such as the following:
mhu_client1: proto2@2f000000 {
.....
/* Requesting to use channel window 0 of &mbox, registering
a mailbox in singe-word mode. */
mboxes = <&mbox 0x0 0x0 0x0 0x1>
}
mhu_client2: proto1@2e000000 {
.....
/* Requesting to use channel window 1 of &mbox, registering
mailboxes in doorbell mode, using bits 3 and 5. The MHU
driver is able to discern between putting channel window 1
into doorbell mode over single word mode, given the
presence of the extra argument. */
mboxes = <&mbox 0x0 0x0 0x0 0x2 3>,
<&mbox 0x0 0x0 0x0 0x2 5>
}
This would remove the ambiguity around deducing a mailbox to be in
single-word or doorbell mode.
Deciding to put channel window(s) into multi-word mode would be, as you
proposed, to mask more than one channel for a mailbox, ie:
mhu_client3: proto2@2f000000 {
.....
/* Requesting to use channel window 2-3 of &mbox, registering
a mailbox in multi-word mode. */
mboxes = <&mbox 0x0 0x0 0x0 0xC>
}
Thanks,
Morten
^ permalink raw reply
* [PATCH v2 6/6] ARM: dts: mmp2: add OLPC XO 1.75 machine
From: Lubomir Rintel @ 2019-08-02 10:33 UTC (permalink / raw)
To: Olof Johansson
Cc: Rob Herring, Mark Rutland, linux-arm-kernel, devicetree,
linux-kernel, Pavel Machek, Lubomir Rintel
In-Reply-To: <20190802103326.531250-1-lkundrak@v3.sk>
This is a fairly complete description of an OLPC XO 1.75 laptop.
What's missing for now is the GPU, LCD controller, DCON, the panel and
audio.
The machine is booted with OpenFirmware and thus has a devicetree.
However, older versions are unable to create a valid FDT and don't
follow the Linux bindings. Having an device tree in the kernel tree
makes it easier to use mainline kernels on such machines, test changes
with CONFIG_ARM_APPENDED_DTB and give a good reference on what bindings
are used on the machine without an access to one.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
---
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/mmp2-olpc-xo-1-75.dts | 244 ++++++++++++++++++++++++
2 files changed, 246 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/mmp2-olpc-xo-1-75.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 9159fa2cea90c..65213b5265187 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -336,7 +336,8 @@ dtb-$(CONFIG_MACH_MESON8) += \
dtb-$(CONFIG_ARCH_MMP) += \
pxa168-aspenite.dtb \
pxa910-dkb.dtb \
- mmp2-brownstone.dtb
+ mmp2-brownstone.dtb \
+ mmp2-olpc-xo-1-75.dtb
dtb-$(CONFIG_ARCH_MPS2) += \
mps2-an385.dtb \
mps2-an399.dtb
diff --git a/arch/arm/boot/dts/mmp2-olpc-xo-1-75.dts b/arch/arm/boot/dts/mmp2-olpc-xo-1-75.dts
new file mode 100644
index 0000000000000..6cfa0d4a18845
--- /dev/null
+++ b/arch/arm/boot/dts/mmp2-olpc-xo-1-75.dts
@@ -0,0 +1,244 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * OLPC XO 1.75 Laptop.
+ *
+ * Copyright (C) 2018,2019 Lubomir Rintel <lkundrak@v3.sk>
+ */
+
+/dts-v1/;
+#include "mmp2.dtsi"
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/linux-event-codes.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+
+/ {
+ model = "OLPC XO-1.75";
+ compatible = "olpc,xo-1.75", "mrvl,mmp2";
+
+ chosen {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ framebuffer@1fc00000 {
+ compatible = "simple-framebuffer";
+ reg = <0x1fc00000 (1200 * 900 * 2)>;
+ width = <1200>;
+ height = <900>;
+ stride = <(1200 * 2)>;
+ format = "r5g6b5";
+ clocks = <&soc_clocks MMP2_CLK_DISP0_LCDC>,
+ <&soc_clocks MMP2_CLK_DISP0>;
+ };
+ };
+
+ memory {
+ linux,usable-memory = <0x0 0x1f800000>;
+ available = <0xcf000 0x1ef31000 0x1000 0xbf000>;
+ reg = <0x0 0x20000000>;
+ device_type = "memory";
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ lid {
+ label = "Lid";
+ gpios = <&gpio 129 GPIO_ACTIVE_LOW>;
+ linux,input-type = <EV_SW>;
+ linux,code = <SW_LID>;
+ wakeup-source;
+ };
+
+ tablet_mode {
+ label = "E-Book Mode";
+ gpios = <&gpio 128 GPIO_ACTIVE_LOW>;
+ linux,input-type = <EV_SW>;
+ linux,code = <SW_TABLET_MODE>;
+ wakeup-source;
+ };
+
+ microphone_insert {
+ label = "Microphone Plug";
+ gpios = <&gpio 96 GPIO_ACTIVE_HIGH>;
+ linux,input-type = <EV_SW>;
+ linux,code = <SW_MICROPHONE_INSERT>;
+ debounce-interval = <100>;
+ wakeup-source;
+ };
+
+ headphone_insert {
+ label = "Headphone Plug";
+ gpios = <&gpio 97 GPIO_ACTIVE_HIGH>;
+ linux,input-type = <EV_SW>;
+ linux,code = <SW_HEADPHONE_INSERT>;
+ debounce-interval = <100>;
+ wakeup-source;
+ };
+ };
+
+ camera_i2c {
+ compatible = "i2c-gpio";
+ gpios = <&gpio 109 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>,
+ <&gpio 108 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ i2c-gpio,timeout-ms = <1000>;
+ status = "okay";
+
+ camera@21 {
+ compatible = "ovti,ov7670";
+ reg = <0x21>;
+ reset-gpios = <&gpio 102 GPIO_ACTIVE_LOW>;
+ powerdown-gpios = <&gpio 150 GPIO_ACTIVE_LOW>;
+ clocks = <&camera0>;
+ clock-names = "xclk";
+
+ port {
+ ov7670_0: endpoint {
+ hsync-active = <1>;
+ vsync-active = <1>;
+ remote-endpoint = <&camera0_0>;
+ };
+ };
+ };
+ };
+
+ battery {
+ compatible = "olpc,xo1.5-battery", "olpc,xo1-battery";
+ };
+
+ wlan_reg: fixedregulator0 {
+ compatible = "regulator-fixed";
+ regulator-name = "wlan";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ gpio = <&gpio 34 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ wlan_pwrseq: pwrseq0 {
+ compatible = "mmc-pwrseq-sd8787";
+ powerdown-gpios = <&gpio 57 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&gpio 58 GPIO_ACTIVE_HIGH>;
+ };
+
+ soc {
+ axi@d4200000 {
+ ap-sp@d4290000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "olpc,ap-sp";
+ interrupts = <40>;
+ reg = <0xd4290000 0x1000>;
+ data-gpios = <&gpio 72 GPIO_ACTIVE_HIGH>;
+ clk-gpios = <&gpio 71 GPIO_ACTIVE_HIGH>;
+ status = "okay";
+ };
+ };
+ };
+};
+
+&uart3 {
+ status = "okay";
+};
+
+&uart4 {
+ status = "okay";
+};
+
+&rtc {
+ status = "okay";
+};
+
+&usb_phy0 {
+ status = "okay";
+};
+
+&usb_otg0 {
+ status = "okay";
+};
+
+&mmc1 {
+ clock-frequency = <50000000>;
+ no-1-8-v;
+ mrvl,clk-delay-cycles = <31>;
+ broken-cd;
+ status = "okay";
+};
+
+&mmc2 {
+ clock-frequency = <50000000>;
+ no-1-8-v;
+ bus-width = <4>;
+ non-removable;
+ broken-cd;
+ wakeup-source;
+ keep-power-in-suspend;
+ mmc-pwrseq = <&wlan_pwrseq>;
+ vmmc-supply = <&wlan_reg>;
+ status = "okay";
+};
+
+&mmc3 {
+ clock-frequency = <50000000>;
+ no-1-8-v;
+ bus-width = <8>;
+ non-removable;
+ broken-cd;
+ mrvl,clk-delay-cycles = <31>;
+ status = "okay";
+};
+
+&twsi1 {
+ status = "okay";
+
+ audio-codec@1a {
+ compatible = "realtek,alc5631";
+ reg = <0x1a>;
+ status = "okay";
+ };
+};
+
+&twsi2 {
+ status = "okay";
+
+ rtc@68 {
+ compatible = "dallas,ds1338";
+ reg = <0x68>;
+ status = "okay";
+ };
+};
+
+&twsi6 {
+ status = "okay";
+
+ accelerometer@1d {
+ compatible = "st,lis331dlh", "st,lis3lv02d";
+ reg = <0x1d>;
+ status = "okay";
+ };
+};
+
+&ssp3 {
+ #address-cells = <0>;
+ spi-slave;
+ status = "okay";
+ ready-gpio = <&gpio 125 GPIO_ACTIVE_HIGH>;
+
+ slave {
+ compatible = "olpc,xo1.75-ec";
+ spi-cpha;
+ cmd-gpio = <&gpio 155 GPIO_ACTIVE_HIGH>;
+ };
+};
+
+&camera0 {
+ status = "okay";
+
+ port {
+ camera0_0: endpoint {
+ remote-endpoint = <&ov7670_0>;
+ };
+ };
+};
--
2.21.0
^ permalink raw reply related
* [PATCH v2 5/6] ARM: dts: mmp2: specify reg-shift for the UARTs
From: Lubomir Rintel @ 2019-08-02 10:33 UTC (permalink / raw)
To: Olof Johansson
Cc: Rob Herring, Mark Rutland, linux-arm-kernel, devicetree,
linux-kernel, Pavel Machek, Lubomir Rintel
In-Reply-To: <20190802103326.531250-1-lkundrak@v3.sk>
This makes the 8250_of driver happy. There are two more drivers in the
tree that bind to mrvl,mmp-uart compatibles: pxa and 8250_pxa and
neither of them requires the reg-shift property, assuming it's always 2.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
---
Changes since v1:
- Updated the subject to fit the style of the DTS updates
---
arch/arm/boot/dts/mmp2.dtsi | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/mmp2.dtsi b/arch/arm/boot/dts/mmp2.dtsi
index 68b5470773232..6a2f072c1d0a8 100644
--- a/arch/arm/boot/dts/mmp2.dtsi
+++ b/arch/arm/boot/dts/mmp2.dtsi
@@ -214,6 +214,7 @@
interrupts = <27>;
clocks = <&soc_clocks MMP2_CLK_UART0>;
resets = <&soc_clocks MMP2_CLK_UART0>;
+ reg-shift = <2>;
status = "disabled";
};
@@ -223,6 +224,7 @@
interrupts = <28>;
clocks = <&soc_clocks MMP2_CLK_UART1>;
resets = <&soc_clocks MMP2_CLK_UART1>;
+ reg-shift = <2>;
status = "disabled";
};
@@ -232,6 +234,7 @@
interrupts = <24>;
clocks = <&soc_clocks MMP2_CLK_UART2>;
resets = <&soc_clocks MMP2_CLK_UART2>;
+ reg-shift = <2>;
status = "disabled";
};
@@ -241,6 +244,7 @@
interrupts = <46>;
clocks = <&soc_clocks MMP2_CLK_UART3>;
resets = <&soc_clocks MMP2_CLK_UART3>;
+ reg-shift = <2>;
status = "disabled";
};
--
2.21.0
^ permalink raw reply related
* [PATCH v2 4/6] ARM: dts: mmp2: add camera interfaces
From: Lubomir Rintel @ 2019-08-02 10:33 UTC (permalink / raw)
To: Olof Johansson
Cc: Rob Herring, Mark Rutland, linux-arm-kernel, devicetree,
linux-kernel, Pavel Machek, Lubomir Rintel
In-Reply-To: <20190802103326.531250-1-lkundrak@v3.sk>
Supported by the mmp-camera driver.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
---
arch/arm/boot/dts/mmp2.dtsi | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/mmp2.dtsi b/arch/arm/boot/dts/mmp2.dtsi
index 21432cb9143f7..68b5470773232 100644
--- a/arch/arm/boot/dts/mmp2.dtsi
+++ b/arch/arm/boot/dts/mmp2.dtsi
@@ -170,6 +170,28 @@
interrupts = <54>;
status = "disabled";
};
+
+ camera0: camera@d420a000 {
+ compatible = "marvell,mmp2-ccic";
+ reg = <0xd420a000 0x800>;
+ interrupts = <42>;
+ clocks = <&soc_clocks MMP2_CLK_CCIC0>;
+ clock-names = "axi";
+ #clock-cells = <0>;
+ clock-output-names = "mclk";
+ status = "disabled";
+ };
+
+ camera1: camera@d420a800 {
+ compatible = "marvell,mmp2-ccic";
+ reg = <0xd420a800 0x800>;
+ interrupts = <30>;
+ clocks = <&soc_clocks MMP2_CLK_CCIC1>;
+ clock-names = "axi";
+ #clock-cells = <0>;
+ clock-output-names = "mclk";
+ status = "disabled";
+ };
};
apb@d4000000 { /* APB */
--
2.21.0
^ permalink raw reply related
* [PATCH v2 3/6] ARM: dts: mmp2: rename the USB PHY node
From: Lubomir Rintel @ 2019-08-02 10:33 UTC (permalink / raw)
To: Olof Johansson
Cc: Mark Rutland, devicetree, linux-kernel, Lubomir Rintel,
Rob Herring, Pavel Machek, linux-arm-kernel
In-Reply-To: <20190802103326.531250-1-lkundrak@v3.sk>
This device is not an OTG phy, it's a regular USB HS phy. Follow the
generic node name recommendation, and rename it to "usb-phy".
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
---
arch/arm/boot/dts/mmp2.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/mmp2.dtsi b/arch/arm/boot/dts/mmp2.dtsi
index e64639ce57a91..21432cb9143f7 100644
--- a/arch/arm/boot/dts/mmp2.dtsi
+++ b/arch/arm/boot/dts/mmp2.dtsi
@@ -117,7 +117,7 @@
mrvl,intc-nr-irqs = <2>;
};
- usb_otg_phy0: usb-otg-phy@d4207000 {
+ usb_phy0: usb-phy@d4207000 {
compatible = "marvell,mmp2-usb-phy";
reg = <0xd4207000 0x40>;
#phy-cells = <0>;
@@ -130,7 +130,7 @@
interrupts = <44>;
clocks = <&soc_clocks MMP2_CLK_USB>;
clock-names = "USBCLK";
- phys = <&usb_otg_phy0>;
+ phys = <&usb_phy0>;
phy-names = "usb";
status = "disabled";
};
--
2.21.0
^ permalink raw reply related
* [PATCH v2 2/6] ARM: dts: mmp2: fix the SPI nodes
From: Lubomir Rintel @ 2019-08-02 10:33 UTC (permalink / raw)
To: Olof Johansson
Cc: Rob Herring, Mark Rutland, linux-arm-kernel, devicetree,
linux-kernel, Pavel Machek, Lubomir Rintel
In-Reply-To: <20190802103326.531250-1-lkundrak@v3.sk>
The SPI bus has a single address cell and not size cells.
Also, dtc thinks the SPI nodes are preferrably called "spi" and it is
right to think so.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
---
arch/arm/boot/dts/mmp2.dtsi | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/mmp2.dtsi b/arch/arm/boot/dts/mmp2.dtsi
index 50b6c38b39cc3..e64639ce57a91 100644
--- a/arch/arm/boot/dts/mmp2.dtsi
+++ b/arch/arm/boot/dts/mmp2.dtsi
@@ -346,35 +346,43 @@
status = "disabled";
};
- ssp1: ssp@d4035000 {
+ ssp1: spi@d4035000 {
compatible = "marvell,mmp2-ssp";
reg = <0xd4035000 0x1000>;
clocks = <&soc_clocks MMP2_CLK_SSP0>;
interrupts = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
status = "disabled";
};
- ssp2: ssp@d4036000 {
+ ssp2: spi@d4036000 {
compatible = "marvell,mmp2-ssp";
reg = <0xd4036000 0x1000>;
clocks = <&soc_clocks MMP2_CLK_SSP1>;
interrupts = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
status = "disabled";
};
- ssp3: ssp@d4037000 {
+ ssp3: spi@d4037000 {
compatible = "marvell,mmp2-ssp";
reg = <0xd4037000 0x1000>;
clocks = <&soc_clocks MMP2_CLK_SSP2>;
interrupts = <20>;
+ #address-cells = <1>;
+ #size-cells = <0>;
status = "disabled";
};
- ssp4: ssp@d4039000 {
+ ssp4: spi@d4039000 {
compatible = "marvell,mmp2-ssp";
reg = <0xd4039000 0x1000>;
clocks = <&soc_clocks MMP2_CLK_SSP3>;
interrupts = <21>;
+ #address-cells = <1>;
+ #size-cells = <0>;
status = "disabled";
};
};
--
2.21.0
^ 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