[PATCH v3 2/2] arm64: dts: imx: Add i.mx8mm Gateworks gw7901 dts support

[Tim Harvey]

The Gateworks GW7901 is an ARM based single board computer (SBC)
featuring:
 - i.MX8M Mini SoC
 - LPDDR4 DRAM
 - eMMC FLASH
 - SPI FRAM
 - Gateworks System Controller (GSC)
 - Atmel ATECC Crypto Authentication
 - USB 2.0
 - Microchip GbE Switch
 - Multiple multi-protocol RS232/RS485/RS422 Serial ports
 - onboard 802.11ac WiFi / BT
 - microSD socket
 - miniPCIe socket with PCIe, USB 2.0 and dual SIM sockets
 - Wide range DC power input
 - 802.3at PoE

Signed-off-by: Tim Harvey 
Reviewed-by: Fabio Estevam 
---
v3:
- remove always-on from regulators that don't have on/off control
- place 'enable-active-high' righ tafter gpio prop in regulators
- remove unnecessary newline
- add newlines between properties and child node
- add newlines between child nodes
- remove unnecessary newline between properties
- add reviewed-by

v2:
 - add missing GSC #address-cells and #size-cells
 - use common node name for SPI FLASH and drop mb85rs4mt compatible
 - add missing pinctrl-names to PMIC
 - add rohm,reset-snvs-powered to PMIC
 - add 32.768 kHz clock to PMIC
---
 arch/arm64/boot/dts/freescale/Makefile|1 +
 .../dts/freescale/imx8mm-venice-gw7901.dts| 1019 +
 2 files changed, 1020 insertions(+)
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-venice-gw7901.dts

diff --git a/arch/arm64/boot/dts/freescale/Makefile 
b/arch/arm64/boot/dts/freescale/Makefile
index 6438db3822f8..2a93323a7d3e 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -39,6 +39,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mm-var-som-symphony.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mm-venice-gw71xx-0x.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mm-venice-gw72xx-0x.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mm-venice-gw73xx-0x.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mm-venice-gw7901.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mn-beacon-kit.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mn-evk.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mn-ddr4-evk.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw7901.dts 
b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw7901.dts
new file mode 100644
index ..5a1e9df39bec
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw7901.dts
@@ -0,0 +1,1019 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2020 Gateworks Corporation
+ */
+
+/dts-v1/;
+
+#include 
+#include 
+#include 
+
+#include "imx8mm.dtsi"
+
+/ {
+   model = "Gateworks Venice GW7901 i.MX8MM board";
+   compatible = "gw,imx8mm-gw7901", "fsl,imx8mm";
+
+   aliases {
+   ethernet0 = 
+   ethernet1 = 
+   ethernet2 = 
+   ethernet3 = 
+   ethernet4 = 
+   usb0 = 
+   usb1 = 
+   };
+
+   chosen {
+   stdout-path = 
+   };
+
+   memory@4000 {
+   device_type = "memory";
+   reg = <0x0 0x4000 0 0x8000>;
+   };
+
+   gpio-keys {
+   compatible = "gpio-keys";
+
+   user-pb {
+   label = "user_pb";
+   gpios = < 2 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   };
+
+   user-pb1x {
+   label = "user_pb1x";
+   linux,code = ;
+   interrupt-parent = <>;
+   interrupts = <0>;
+   };
+
+   key-erased {
+   label = "key_erased";
+   linux,code = ;
+   interrupt-parent = <>;
+   interrupts = <1>;
+   };
+
+   eeprom-wp {
+   label = "eeprom_wp";
+   linux,code = ;
+   interrupt-parent = <>;
+   interrupts = <2>;
+   };
+
+   tamper {
+   label = "tamper";
+   linux,code = ;
+   interrupt-parent = <>;
+   interrupts = <5>;
+   };
+
+   switch-hold {
+   label = "switch_hold";
+   linux,code = ;
+   interrupt-parent = <>;
+   interrupts = <7>;
+   };
+   };
+
+   led-controller {
+   compatible = "gpio-leds";
+
+   led-0 {
+   function = LED_FUNCTION_STATUS;
+   color = ;
+   label = "led01_red";
+   gpios = <_gpio 0 GPIO_ACTIVE_HIGH>;
+   default-state = "off";
+   };
+
+   led-1 {
+   function = LED_FUNCTION_STATUS;

[PATCH v3 1/2] dt-bindings: arm: imx: add imx8mm gw7901 support

[Tim Harvey]

The Gateworks GW7901 is an ARM based single board computer (SBC)
featuring:
 - i.MX8M Mini SoC
 - LPDDR4 DRAM
 - eMMC FLASH
 - SPI FRAM
 - Gateworks System Controller (GSC)
 - Atmel ATECC Crypto Authentication
 - USB 2.0
 - Microchip GbE Switch
 - Multiple multi-protocol RS232/RS485/RS422 Serial ports
 - onboard 802.11ac WiFi / BT
 - microSD socket
 - miniPCIe socket with PCIe, USB 2.0 and dual SIM sockets
 - Wide range DC power input
 - 802.3at PoE

Acked-by: Rob Herring 
Signed-off-by: Tim Harvey 
Reviewed-by: Fabio Estevam 
---
v3:
 - add reviewed-by

v2:
 - add Rob's Acked-by
---
 Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml 
b/Documentation/devicetree/bindings/arm/fsl.yaml
index 297c87f45db8..9af86ce3142d 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -684,6 +684,7 @@ properties:
   - gw,imx8mm-gw71xx-0x   # i.MX8MM Gateworks Development Kit
   - gw,imx8mm-gw72xx-0x   # i.MX8MM Gateworks Development Kit
   - gw,imx8mm-gw73xx-0x   # i.MX8MM Gateworks Development Kit
+  - gw,imx8mm-gw7901  # i.MX8MM Gateworks Board
   - kontron,imx8mm-n801x-som  # i.MX8MM Kontron SL (N801X) SOM
   - variscite,var-som-mx8mm   # i.MX8MM Variscite VAR-SOM-MX8MM 
module
   - const: fsl,imx8mm
-- 
2.17.1

[PATCH v2 1/2] dt-bindings: arm: imx: add imx8mm gw7901 support

[Tim Harvey]

The Gateworks GW7901 is an ARM based single board computer (SBC)
featuring:
 - i.MX8M Mini SoC
 - LPDDR4 DRAM
 - eMMC FLASH
 - SPI FRAM
 - Gateworks System Controller (GSC)
 - Atmel ATECC Crypto Authentication
 - USB 2.0
 - Microchip GbE Switch
 - Multiple multi-protocol RS232/RS485/RS422 Serial ports
 - onboard 802.11ac WiFi / BT
 - microSD socket
 - miniPCIe socket with PCIe, USB 2.0 and dual SIM sockets
 - Wide range DC power input
 - 802.3at PoE

Acked-by: Rob Herring 
Signed-off-by: Tim Harvey 
---
v2:
 - add Rob's Acked-by
---
 Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml 
b/Documentation/devicetree/bindings/arm/fsl.yaml
index 297c87f45db8..9af86ce3142d 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -684,6 +684,7 @@ properties:
   - gw,imx8mm-gw71xx-0x   # i.MX8MM Gateworks Development Kit
   - gw,imx8mm-gw72xx-0x   # i.MX8MM Gateworks Development Kit
   - gw,imx8mm-gw73xx-0x   # i.MX8MM Gateworks Development Kit
+  - gw,imx8mm-gw7901  # i.MX8MM Gateworks Board
   - kontron,imx8mm-n801x-som  # i.MX8MM Kontron SL (N801X) SOM
   - variscite,var-som-mx8mm   # i.MX8MM Variscite VAR-SOM-MX8MM 
module
   - const: fsl,imx8mm
-- 
2.17.1

[PATCH v2 2/2] arm64: dts: imx: Add i.mx8mm Gateworks gw7901 dts support

[Tim Harvey]

The Gateworks GW7901 is an ARM based single board computer (SBC)
featuring:
 - i.MX8M Mini SoC
 - LPDDR4 DRAM
 - eMMC FLASH
 - SPI FRAM
 - Gateworks System Controller (GSC)
 - Atmel ATECC Crypto Authentication
 - USB 2.0
 - Microchip GbE Switch
 - Multiple multi-protocol RS232/RS485/RS422 Serial ports
 - onboard 802.11ac WiFi / BT
 - microSD socket
 - miniPCIe socket with PCIe, USB 2.0 and dual SIM sockets
 - Wide range DC power input
 - 802.3at PoE

Signed-off-by: Tim Harvey 
---
v2:
 - fixed issues reported by check_dtbs:
   - add missing GSC #address-cells and #size-cells
 - use common node name for SPI FLASH and drop mb85rs4mt compatible
 - add missing pinctrl-names to PMIC
 - add rohm,reset-snvs-powered to PMIC
 - add 32.768 kHz clock to PMIC

Signed-off-by: Tim Harvey 
---
 arch/arm64/boot/dts/freescale/Makefile|1 +
 .../dts/freescale/imx8mm-venice-gw7901.dts| 1016 +
 2 files changed, 1017 insertions(+)
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-venice-gw7901.dts

diff --git a/arch/arm64/boot/dts/freescale/Makefile 
b/arch/arm64/boot/dts/freescale/Makefile
index 6438db3822f8..2a93323a7d3e 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -39,6 +39,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mm-var-som-symphony.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mm-venice-gw71xx-0x.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mm-venice-gw72xx-0x.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mm-venice-gw73xx-0x.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mm-venice-gw7901.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mn-beacon-kit.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mn-evk.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mn-ddr4-evk.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw7901.dts 
b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw7901.dts
new file mode 100644
index ..d6431b01babc
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw7901.dts
@@ -0,0 +1,1016 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2020 Gateworks Corporation
+ */
+
+/dts-v1/;
+
+#include 
+#include 
+#include 
+
+#include "imx8mm.dtsi"
+
+/ {
+   model = "Gateworks Venice GW7901 i.MX8MM board";
+   compatible = "gw,imx8mm-gw7901", "fsl,imx8mm";
+
+   aliases {
+   ethernet0 = 
+   ethernet1 = 
+   ethernet2 = 
+   ethernet3 = 
+   ethernet4 = 
+   usb0 = 
+   usb1 = 
+   };
+
+   chosen {
+   stdout-path = 
+   };
+
+   memory@4000 {
+   device_type = "memory";
+   reg = <0x0 0x4000 0 0x8000>;
+   };
+
+   gpio-keys {
+   compatible = "gpio-keys";
+
+   user-pb {
+   label = "user_pb";
+   gpios = < 2 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   };
+
+   user-pb1x {
+   label = "user_pb1x";
+   linux,code = ;
+   interrupt-parent = <>;
+   interrupts = <0>;
+   };
+
+   key-erased {
+   label = "key_erased";
+   linux,code = ;
+   interrupt-parent = <>;
+   interrupts = <1>;
+   };
+
+   eeprom-wp {
+   label = "eeprom_wp";
+   linux,code = ;
+   interrupt-parent = <>;
+   interrupts = <2>;
+   };
+
+   tamper {
+   label = "tamper";
+   linux,code = ;
+   interrupt-parent = <>;
+   interrupts = <5>;
+   };
+
+   switch-hold {
+   label = "switch_hold";
+   linux,code = ;
+   interrupt-parent = <>;
+   interrupts = <7>;
+   };
+   };
+
+   led-controller {
+   compatible = "gpio-leds";
+
+   led-0 {
+   function = LED_FUNCTION_STATUS;
+   color = ;
+   label = "led01_red";
+   gpios = <_gpio 0 GPIO_ACTIVE_HIGH>;
+   default-state = "off";
+   };
+
+   led-1 {
+   function = LED_FUNCTION_STATUS;
+   color = ;
+   label = "led01_grn";
+   gpios = <_gpio 1 GPIO_ACTIVE_HIGH>;
+   default-state = "off";
+   };
+
+   led-2 {
+   functi

Re: [PATCH v5 10/14] clk: imx: Add generic blk-ctl driver

[Tim Harvey]

On Thu, Feb 25, 2021 at 12:28 AM Jacky Bai  wrote:
>
>
>
> > -Original Message-
> > From: Frieder Schrempf [mailto:frieder.schre...@kontron.de]
> > Sent: Thursday, February 25, 2021 4:23 PM
> > To: Abel Vesa ; Dong Aisheng 
> > Cc: Aisheng Dong ; Rob Herring ;
> > Peng Fan ; Jacky Bai ; Anson Huang
> > ; devicetree ;
> > Stephen Boyd ; Shawn Guo ;
> > Mike Turquette ; Linux Kernel Mailing List
> > ; Marek Vasut ;
> > dl-linux-imx ; Sascha Hauer ;
> > Fabio Estevam ; Philipp Zabel
> > ; Adam Ford ; linux-clk
> > ; moderated list:ARM/FREESCALE IMX / MXC
> > ARM ARCHITECTURE ; Lucas Stach
> > 
> > Subject: Re: [PATCH v5 10/14] clk: imx: Add generic blk-ctl driver
> >
> > Hi Abel,
> >
> > On 17.11.20 15:48, Abel Vesa wrote:
> > > On 20-11-11 17:13:25, Dong Aisheng wrote:
> > >> On Tue, Nov 3, 2020 at 7:22 PM Abel Vesa  wrote:
> > >> ...
> > >>> +static int imx_blk_ctl_reset_set(struct reset_controller_dev *rcdev,
> > >>> + unsigned long id, bool assert) {
> > >>> +   struct imx_blk_ctl_drvdata *drvdata = container_of(rcdev,
> > >>> +   struct imx_blk_ctl_drvdata, rcdev);
> > >>> +   unsigned int offset = drvdata->rst_hws[id].offset;
> > >>> +   unsigned int shift = drvdata->rst_hws[id].shift;
> > >>> +   unsigned int mask = drvdata->rst_hws[id].mask;
> > >>> +   void __iomem *reg_addr = drvdata->base + offset;
> > >>> +   unsigned long flags;
> > >>> +   u32 reg;
> > >>> +
> > >>> +   if (!assert && !test_bit(1, >rst_hws[id].asserted))
> > >>> +   return -ENODEV;
> > >>
> > >> What if consumers call deassert first in probe which seems common in
> > kernel?
> > >> It seems will fail.
> > >> e.g.
> > >> probe() {
> > >>  reset_control_get()
> > >>  reset_control_deassert()
> > >> }
> > >>
> > >> Regards
> > >> Aisheng
> > >>
> > >
> > > OK, I'm trying to explain here how I know the resets are supposed to
> > > be working and how the BLK_CTL IP is working.
> > >
> > >
> > > First of, the BLK_CTL bits (resets and clocks) all have the HW init
> > > (default) values as 0. Basically, after the blk_ctl PD is powered on,
> > > the resets are deasserted and clocks are gated by default. Since the
> > > blk_ctl is not the parent of any of the consumers in devicetree (the
> > > reg maps are entirely different anyway), there is no way of ordering
> > > the runtime callbacks between the consumer and the blk_ctl. So we
> > > might end up having the runtime resume callback after the one from
> > > EARC (consumer), for example, which will basically overwrite the value
> > written by EARC driver with whatever was saved on suspend.
> > >
> > > Now, about the usage of the reset bits. AFAICT, it would make more
> > > sense to assert the reset, then enable the clock, then deassert. This
> > > way, you're keeping the EARC (consumer) in reset (with the clocks on)
> > > until you eventually release it out of reset by deasserting. This is
> > > how the runtime resume should deal with the reset and the clock. As
> > > for the runtime suspend, the reset can be entirely ignored as long as 
> > > you're
> > disabling the clock.
> > >
> > > This last part will allow the blk_ctl to make the following assumption:
> > > if all the clocks are disabled and none of the reset bits are asserted, I 
> > > can
> > power off.
> > >
> > > Now, I know there are drivers outthere that do assert on suspend, but
> > > as long as the clocks are disabled, the assert will have no impact.
> > > But maybe in their case the reset controller cannot power down itself.
> > >
> > > As for the safekeeping of the register, I'll just drop it due to the 
> > > following
> > arguments:
> > > 1. all the clocks are gated by default 2. all resets are deasserted by
> > > default 3. when blk_ctl goes down, all the consumers go down. (all
> > > have the same PD)
> > >
> > >  From 1 and 2 results the IP will not be running and from 3 results
> > > the HW state of every IP becomes HW init state.
> >
> > Are there any plans to continue this work? As BLK-CTL it is not only 
> > relevant
> > for the i.MX8MP, but also for i.MX8MM and i.MX8MN, it would be nice to get
> > this ready in order to prepare for proper graphics/display support.
> >
>
> Before continuing this work, we need to find out a way to resolve the cycling 
> dependency issue between power domain and blk-ctrl.
> it is indeed introduced some troubles in NXP latest internal release when the 
> blk-ctrl driver is added.
>

Jacky,

Any update on this? This is still blocking several drivers and major
functionality of the i.MX8 SoC's in mainline and I would hope this
would be a top priority for NXP.

Best regards,

Tim

Re: [PATCH 1/4] dt-bindings: at25: add Fujitsu MB85RS4MT

[Tim Harvey]

'On Tue, Mar 9, 2021 at 9:34 PM  wrote:
>
> On 3/10/21 12:59 AM, Michael Walle wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
> > content is safe
> >
> > Hi Tim,
> >
> > Am 2021-03-09 23:00, schrieb Tim Harvey:
> >> Document the compatible value for the Fujitsu MB85RS4MT SPI
> >> FRAM EEPROM device so that it can be used in DTS files.
> >>
> >> This is a 512KiB FRAM EEPROM.
> >>
> >> Signed-off-by: Tim Harvey 
> >> ---
> >>  Documentation/devicetree/bindings/eeprom/at25.yaml | 1 +
> >>  1 file changed, 1 insertion(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/eeprom/at25.yaml
> >> b/Documentation/devicetree/bindings/eeprom/at25.yaml
> >> index 6a2dc8b3ed14..f594db72b711 100644
> >> --- a/Documentation/devicetree/bindings/eeprom/at25.yaml
> >> +++ b/Documentation/devicetree/bindings/eeprom/at25.yaml
> >> @@ -26,6 +26,7 @@ properties:
> >>- anvo,anv32e61w
> >>- atmel,at25256B
> >>- fujitsu,mb85rs1mt
> >> +  - fujitsu,mb85rs4mt
> >>- fujitsu,mb85rs64
> >>- microchip,at25160bn
> >>- microchip,25lc040
> >
> > Hm, the driver is spi-nor but this is for the at25 driver. Is
> > this correct? Doesn't it work if you just add the ID to
> > spi-nor/fujitsu.c and use 'compatible = "jedec,spi-nor' ?
> >
>
> Tim,
>
> Can you try and see if you can work with this flash by setting "atmel,at25"
> compatible?

It does not work with 'atmel,at25'. I was fooled into adding it to
at25.yaml because that is where the mb85rs1mt compatible was. I
suppose at some time the drivers were split as mb85rs1mt is clearly in
the spi-nor driver now.

I will drop the patch to at25.yaml and now that I realize all I need
is 'jedec,spi-nor' I won't need any bindings patch.

>
> There are some SPI NOR-like flashes MRAMs, FRAMs, even EEPROMs, that share
> a part of opcodes of SPI NORs, but have slightly different characteristics
> (ex. no erase, no wait times for writes on FRAMs).
> See the patch series submitted by Richard, that I have stalled:
> https://patchwork.ozlabs.org/project/linux-mtd/list/?series=208584=*
>

This series makes sense to me. I tested it and indeed it provides a
vast performance improvement. Richards patch would collide with my
patch that adds the mb85rs4mt detection. Let me know what you're going
to do there and if you need me to rebase 'mtd: spi-nor: fujitsu: add
support for MB85RS4MT' on top of it.

Best regards,

Tim

Re: [PATCH 1/4] dt-bindings: at25: add Fujitsu MB85RS4MT

[Tim Harvey]

On Tue, Mar 9, 2021 at 2:59 PM Michael Walle  wrote:
>
> Hi Tim,
>
> Am 2021-03-09 23:00, schrieb Tim Harvey:
> > Document the compatible value for the Fujitsu MB85RS4MT SPI
> > FRAM EEPROM device so that it can be used in DTS files.
> >
> > This is a 512KiB FRAM EEPROM.
> >
> > Signed-off-by: Tim Harvey 
> > ---
> >  Documentation/devicetree/bindings/eeprom/at25.yaml | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/Documentation/devicetree/bindings/eeprom/at25.yaml
> > b/Documentation/devicetree/bindings/eeprom/at25.yaml
> > index 6a2dc8b3ed14..f594db72b711 100644
> > --- a/Documentation/devicetree/bindings/eeprom/at25.yaml
> > +++ b/Documentation/devicetree/bindings/eeprom/at25.yaml
> > @@ -26,6 +26,7 @@ properties:
> >- anvo,anv32e61w
> >- atmel,at25256B
> >- fujitsu,mb85rs1mt
> > +  - fujitsu,mb85rs4mt
> >- fujitsu,mb85rs64
> >- microchip,at25160bn
> >- microchip,25lc040
>
> Hm, the driver is spi-nor but this is for the at25 driver. Is
> this correct? Doesn't it work if you just add the ID to
> spi-nor/fujitsu.c and use 'compatible = "jedec,spi-nor' ?
>

Michael,

Yes it works just fine as 'compatible = "jedec,spi-nor"' and that
makes sense. I'll drop this patch and update my device-tree
accordingly.

Thanks,

Tim

[PATCH 4/4] arm64: dts: imx: Add i.mx8mm Gateworks gw7901 dts support

[Tim Harvey]

The Gateworks GW7901 is an ARM based single board computer (SBC)
featuring:
 - i.MX8M Mini SoC
 - LPDDR4 DRAM
 - eMMC FLASH
 - SPI FRAM
 - Gateworks System Controller (GSC)
 - Atmel ATECC Crypto Authentication
 - USB 2.0
 - Microchip GbE Switch
 - Multiple multi-protocol RS232/RS485/RS422 Serial ports
 - onboard 802.11ac WiFi / BT
 - microSD socket
 - miniPCIe socket with PCIe, USB 2.0 and dual SIM sockets
 - Wide range DC power input
 - 802.3at PoE

Signed-off-by: Tim Harvey 
---
 arch/arm64/boot/dts/freescale/Makefile|1 +
 .../dts/freescale/imx8mm-venice-gw7901.dts| 1008 +
 2 files changed, 1009 insertions(+)
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-venice-gw7901.dts

diff --git a/arch/arm64/boot/dts/freescale/Makefile 
b/arch/arm64/boot/dts/freescale/Makefile
index 6438db3822f8..2a93323a7d3e 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -39,6 +39,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mm-var-som-symphony.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mm-venice-gw71xx-0x.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mm-venice-gw72xx-0x.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mm-venice-gw73xx-0x.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mm-venice-gw7901.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mn-beacon-kit.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mn-evk.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mn-ddr4-evk.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw7901.dts 
b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw7901.dts
new file mode 100644
index ..718b4b7d555b
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw7901.dts
@@ -0,0 +1,1008 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2020 Gateworks Corporation
+ */
+
+/dts-v1/;
+
+#include 
+#include 
+#include 
+
+#include "imx8mm.dtsi"
+
+/ {
+   model = "Gateworks Venice GW7901 i.MX8MM board";
+   compatible = "gw,imx8mm-gw7901", "fsl,imx8mm";
+
+   aliases {
+   ethernet0 = 
+   ethernet1 = 
+   ethernet2 = 
+   ethernet3 = 
+   ethernet4 = 
+   usb0 = 
+   usb1 = 
+   };
+
+   chosen {
+   stdout-path = 
+   };
+
+   memory@4000 {
+   device_type = "memory";
+   reg = <0x0 0x4000 0 0x8000>;
+   };
+
+   gpio-keys {
+   compatible = "gpio-keys";
+
+   user-pb {
+   label = "user_pb";
+   gpios = < 2 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   };
+
+   user-pb1x {
+   label = "user_pb1x";
+   linux,code = ;
+   interrupt-parent = <>;
+   interrupts = <0>;
+   };
+
+   key-erased {
+   label = "key_erased";
+   linux,code = ;
+   interrupt-parent = <>;
+   interrupts = <1>;
+   };
+
+   eeprom-wp {
+   label = "eeprom_wp";
+   linux,code = ;
+   interrupt-parent = <>;
+   interrupts = <2>;
+   };
+
+   tamper {
+   label = "tamper";
+   linux,code = ;
+   interrupt-parent = <>;
+   interrupts = <5>;
+   };
+
+   switch-hold {
+   label = "switch_hold";
+   linux,code = ;
+   interrupt-parent = <>;
+   interrupts = <7>;
+   };
+   };
+
+   led-controller {
+   compatible = "gpio-leds";
+
+   led-0 {
+   function = LED_FUNCTION_STATUS;
+   color = ;
+   label = "led01_red";
+   gpios = <_gpio 0 GPIO_ACTIVE_HIGH>;
+   default-state = "off";
+   };
+
+   led-1 {
+   function = LED_FUNCTION_STATUS;
+   color = ;
+   label = "led01_grn";
+   gpios = <_gpio 1 GPIO_ACTIVE_HIGH>;
+   default-state = "off";
+   };
+
+   led-2 {
+   function = LED_FUNCTION_STATUS;
+   color = ;
+   label = "led02_red";
+   gpios = <_gpio 2 GPIO_ACTIVE_HIGH>;
+   default-state = "off";
+   };
+
+   led-3 {
+   

[PATCH 2/4] mtd: spi-nor: fujitsu: add support for MB85RS4MT

[Tim Harvey]

Add support for the Fujitsu MB85RS4MT SPI FRAM EEPROM device.

This is a 512KiB FRAM EEPROM.

Signed-off-by: Tim Harvey 
---
 drivers/mtd/spi-nor/fujitsu.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mtd/spi-nor/fujitsu.c b/drivers/mtd/spi-nor/fujitsu.c
index e385d93e756c..9df5d0576cea 100644
--- a/drivers/mtd/spi-nor/fujitsu.c
+++ b/drivers/mtd/spi-nor/fujitsu.c
@@ -11,6 +11,7 @@
 static const struct flash_info fujitsu_parts[] = {
/* Fujitsu */
{ "mb85rs1mt", INFO(0x047f27, 0, 128 * 1024, 1, SPI_NOR_NO_ERASE) },
+   { "mb85rs4mt", INFO(0x047f49, 0, 512 * 1024, 1, SPI_NOR_NO_ERASE) },
 };
 
 const struct spi_nor_manufacturer spi_nor_fujitsu = {
-- 
2.17.1

[PATCH 1/4] dt-bindings: at25: add Fujitsu MB85RS4MT

[Tim Harvey]

Document the compatible value for the Fujitsu MB85RS4MT SPI
FRAM EEPROM device so that it can be used in DTS files.

This is a 512KiB FRAM EEPROM.

Signed-off-by: Tim Harvey 
---
 Documentation/devicetree/bindings/eeprom/at25.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/eeprom/at25.yaml 
b/Documentation/devicetree/bindings/eeprom/at25.yaml
index 6a2dc8b3ed14..f594db72b711 100644
--- a/Documentation/devicetree/bindings/eeprom/at25.yaml
+++ b/Documentation/devicetree/bindings/eeprom/at25.yaml
@@ -26,6 +26,7 @@ properties:
   - anvo,anv32e61w
   - atmel,at25256B
   - fujitsu,mb85rs1mt
+  - fujitsu,mb85rs4mt
   - fujitsu,mb85rs64
   - microchip,at25160bn
   - microchip,25lc040
-- 
2.17.1

[PATCH 3/4] dt-bindings: arm: imx: add imx8mm gw7901 support

[Tim Harvey]

The Gateworks GW7901 is an ARM based single board computer (SBC)
featuring:
 - i.MX8M Mini SoC
 - LPDDR4 DRAM
 - eMMC FLASH
 - SPI FRAM
 - Gateworks System Controller (GSC)
 - Atmel ATECC Crypto Authentication
 - USB 2.0
 - Microchip GbE Switch
 - Multiple multi-protocol RS232/RS485/RS422 Serial ports
 - onboard 802.11ac WiFi / BT
 - microSD socket
 - miniPCIe socket with PCIe, USB 2.0 and dual SIM sockets
 - Wide range DC power input
 - 802.3at PoE

Signed-off-by: Tim Harvey 
---
 Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml 
b/Documentation/devicetree/bindings/arm/fsl.yaml
index 297c87f45db8..9af86ce3142d 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -684,6 +684,7 @@ properties:
   - gw,imx8mm-gw71xx-0x   # i.MX8MM Gateworks Development Kit
   - gw,imx8mm-gw72xx-0x   # i.MX8MM Gateworks Development Kit
   - gw,imx8mm-gw73xx-0x   # i.MX8MM Gateworks Development Kit
+  - gw,imx8mm-gw7901  # i.MX8MM Gateworks Board
   - kontron,imx8mm-n801x-som  # i.MX8MM Kontron SL (N801X) SOM
   - variscite,var-som-mx8mm   # i.MX8MM Variscite VAR-SOM-MX8MM 
module
   - const: fsl,imx8mm
-- 
2.17.1

[PATCH v5 1/2] dt-bindings: arm: fsl: Add binding for Gateworks boards with IMX8MM

[Tim Harvey]

Add bindings for the Gateworks Venice Development kit boards with
IMX8MM System on Module.

Signed-off-by: Tim Harvey 
---
v5: no changes
v4: no changes
v3: no changes
v2: no changes
---
 Documentation/devicetree/bindings/arm/fsl.yaml | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml 
b/Documentation/devicetree/bindings/arm/fsl.yaml
index 1ca9dfa..705c6e8 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -405,6 +405,9 @@ properties:
   - beacon,imx8mm-beacon-kit  # i.MX8MM Beacon Development Kit
   - fsl,imx8mm-ddr4-evk   # i.MX8MM DDR4 EVK Board
   - fsl,imx8mm-evk# i.MX8MM EVK Board
+  - gw,imx8mm-gw71xx-0x   # i.MX8MM Gateworks Development Kit
+  - gw,imx8mm-gw72xx-0x   # i.MX8MM Gateworks Development Kit
+  - gw,imx8mm-gw73xx-0x   # i.MX8MM Gateworks Development Kit
   - variscite,var-som-mx8mm   # i.MX8MM Variscite VAR-SOM-MX8MM 
module
   - const: fsl,imx8mm
 
-- 
2.7.4

[PATCH v5 2/2] arm64: dts: imx8mm: Add Gateworks i.MX 8M Mini Development Kits

[Tim Harvey]

The Gateworks Venice GW71xx-0x/GW72xx-0x/GW73xx-0x are development
kits consisting of a GW700x SoM and a Baseboard. Future SoM's such
as the GW701x will create additional combinations.

The GW700x SoM contains:
 - i.MX 8M Mini SoC
 - LPDDR4 DRAM
 - eMMC FLASH
 - Gateworks System Controller (eeprom/pushbutton/reset/voltage-monitor)
 - GbE PHY connected to the i.MX 8M Mini FEC
 - Power Management IC

The GW71xx Baseboard contains:
 - 1x MiniPCIe Socket with USB2.0, PCIe, and SIM
 - 1x RJ45 GbE (i.MX 8M Mini FEC)
 - I/O connector with 1x-SPI/1x-I2C/1x-UART/4x-GPIO signals
 - PCIe Clock generator
 - GPS and accelerometer
 - 1x USB 2.0 Front Panel connector
 - wide range power supply

The GW72xx Baseboard contains:
 - 2x MiniPCIe Socket with USB2.0, PCIe, and SIM
 - 2x RJ45 GbE (i.MX 8M Mini FEC and LAN743x)
 - 1x MicroSD connector
 - 1x USB 2.0 Front Panel connector
 - 1x SPI connector
 - 1x Serial connector supporting 2x-UART or 1x-UART configured as 1 of:
   RS232 w/ flow-control, RS485, RS422
 - PCIe Clock generator
 - GPS and accelerometer
 - Media Expansion connector (MIPI-CSI/MIPI-DSI/GPIO/I2S)
 - I/O connector with 2x-ADC,2x-GPIO,1x-UART,1x-I2C
 - wide range power supply

The GW73xx Baseboard contains:
 - 3x MiniPCIe Socket with USB2.0, PCIe, and SIM
 - 2x RJ45 GbE (i.MX 8M Mini FEC and LAN743x)
 - 1x MicroSD connector
 - 1x USB 2.0 Front Panel connector
 - 1x SPI connector
 - 1x Serial connector supporting 2x-UART or 1x-UART configured as 1 of:
   RS232 w/ flow-control, RS485, RS422
 - WiFi/BT
 - PCIe Clock generator
 - GPS and accelerometer
 - Media Expansion connector (MIPI-CSI/MIPI-DSI/GPIO/I2S)
 - I/O connector with 2x-ADC,2x-GPIO,1x-UART,1x-I2C
 - wide range power supply

Signed-off-by: Tim Harvey 
---
v5:
 - fixed typo/grammar in commit log (s/controll/control s/comprised/consisting/)
 - removed underscore from remaining node names
 - removed blank line in hoggrp
 - removed unused assigned-clocks and assigned-clock-rates node from usdhc nodes

v4:
 - replace underscore with hyphen for gpio-keys node
 - add 'off-board header' comments to i2c/spi/uart nodes that go off-board
 - move node comments to own line above node
 - add spaces after comma
 - move uart2_gpio rs485 config pinmux to hoggroup as they don't necessarily
   relate to uart2
 - fix fifo-depth dt property for phy

v3:
 - fix gpio controller node name
 - add rtc node to SoM
 - add pmic pinctrl to SoM
 - fixed compatible string for SoM eeprom's

v2:
 - fix i.MX 8M Mini name in commit log
 - consistent use of underscore vs hyphen in labels
 - fix gsc interrupt type
 - fix iomux group node names
 - fix led-controller bindings:
   (use correct node names, color, function and remove label)
 - use accelerometer node name vs accel
 - remove sai3 from gw71xx baseboard
 - added serial connector description to commit message
 - added I/O connector description to commit message
 - removed unnecessary #address-cells/#size-cells from gpio-keys node
---
 arch/arm64/boot/dts/freescale/Makefile |   3 +
 .../boot/dts/freescale/imx8mm-venice-gw700x.dtsi   | 495 +
 .../boot/dts/freescale/imx8mm-venice-gw71xx-0x.dts |  19 +
 .../boot/dts/freescale/imx8mm-venice-gw71xx.dtsi   | 186 
 .../boot/dts/freescale/imx8mm-venice-gw72xx-0x.dts |  20 +
 .../boot/dts/freescale/imx8mm-venice-gw72xx.dtsi   | 311 +
 .../boot/dts/freescale/imx8mm-venice-gw73xx-0x.dts |  19 +
 .../boot/dts/freescale/imx8mm-venice-gw73xx.dtsi   | 362 +++
 8 files changed, 1415 insertions(+)
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-venice-gw71xx-0x.dts
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-venice-gw71xx.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-venice-gw72xx-0x.dts
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-venice-gw72xx.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-venice-gw73xx-0x.dts
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-venice-gw73xx.dtsi

diff --git a/arch/arm64/boot/dts/freescale/Makefile 
b/arch/arm64/boot/dts/freescale/Makefile
index f8d5943..ecdd233 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -32,6 +32,9 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mm-beacon-kit.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mm-evk.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mm-ddr4-evk.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mm-var-som-symphony.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mm-venice-gw71xx-0x.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mm-venice-gw72xx-0x.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mm-venice-gw73xx-0x.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mn-evk.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mn-ddr4-evk.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mn-var-som-symphony.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi 
b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi
new file mode 100644
index ..c769fad
--- /dev/null
+++ b

Re: [PATCH v4 2/2] arm64: dts: imx8mm: Add Gateworks i.MX 8M Mini Development Kits

[Tim Harvey]

On Mon, Jan 4, 2021 at 4:36 AM Krzysztof Kozlowski  wrote:
>
> On Wed, Dec 30, 2020 at 09:58:43AM -0800, Tim Harvey wrote:
> > The Gateworks Venice GW71xx-0x/GW72xx-0x/GW73xx-0x are development
> > kits comprised of a GW700x SoM and a Baseboard. Future SoM's such
> > as the GW701x will create additional combinations.
> >
> > The GW700x SoM contains:
> >  - i.MX 8M Mini SoC
> >  - LPDDR4 DRAM
> >  - eMMC FLASH
> >  - Gateworks System Controller (eeprom/pushbutton/reset/voltage-monitor)
> >  - GbE PHY connected to the i.MX 8M Mini FEC
> >  - Power Management IC
> >
> > The GW71xx Baseboard contains:
> >  - 1x MiniPCIe Socket with USB2.0, PCIe, and SIM
> >  - 1x RJ45 GbE (i.MX 8M Mini FEC)
> >  - I/O connector with 1x-SPI/1x-I2C/1x-UART/4x-GPIO signals
> >  - PCIe Clock generator
> >  - GPS and accelerometer
> >  - 1x USB 2.0 Front Panel connector
> >  - wide range power supply
> >
> > The GW72xx Baseboard contains:
> >  - 2x MiniPCIe Socket with USB2.0, PCIe, and SIM
> >  - 2x RJ45 GbE (i.MX 8M Mini FEC and LAN743x)
> >  - 1x MicroSD connector
> >  - 1x USB 2.0 Front Panel connector
> >  - 1x SPI connector
> >  - 1x Serial connector supporting 2x-UART or 1x-UART configured as 1 of:
> >RS232 w/ flow-controll, RS485, RS422
> >  - PCIe Clock generator
> >  - GPS and accelerometer
> >  - Media Expansion connector (MIPI-CSI/MIPI-DSI/GPIO/I2S)
> >  - I/O connector with 2x-ADC,2x-GPIO,1x-UART,1x-I2C
> >  - wide range power supply
> >
> > The GW73xx Baseboard contains:
> >  - 3x MiniPCIe Socket with USB2.0, PCIe, and SIM
> >  - 2x RJ45 GbE (i.MX 8M Mini FEC and LAN743x)
> >  - 1x MicroSD connector
> >  - 1x USB 2.0 Front Panel connector
> >  - 1x SPI connector
> >  - 1x Serial connector supporting 2x-UART or 1x-UART configured as 1 of:
> >RS232 w/ flow-controll, RS485, RS422
> >  - WiFi/BT
> >  - PCIe Clock generator
> >  - GPS and accelerometer
> >  - Media Expansion connector (MIPI-CSI/MIPI-DSI/GPIO/I2S)
> >  - I/O connector with 2x-ADC,2x-GPIO,1x-UART,1x-I2C
> >  - wide range power supply
> >
> > Signed-off-by: Tim Harvey 
> > ---
> > v4:
> >  - replace underscore with hyphen for gpio-keys node
> >  - add 'off-board header' comments to i2c/spi/uart nodes that go off-board
> >  - move node comments to own line above node
> >  - add spaces after comma
> >  - move uart2_gpio rs485 config pinmux to hoggroup as they don't necessarily
> >relate to uart2
> >  - fix fifo-depth dt property for phy
> >
> > v3:
> >  - fix gpio controller node name
> >  - add rtc node to SoM
> >  - add pmic pinctrl to SoM
> >  - fixed compatible string for SoM eeprom's
> >
> > v2:
> >  - fix i.MX 8M Mini name in commit log
> >  - consistent use of underscore vs hyphen in labels
> >  - fix gsc interrupt type
> >  - fix iomux group node names
> >  - fix led-controller bindings:
> >(use correct node names, color, function and remove label)
> >  - use accelerometer node name vs accel
> >  - remove sai3 from gw71xx baseboard
> >  - added serial connector description to commit message
> >  - added I/O connector description to commit message
> >  - removed unnecessary #address-cells/#size-cells from gpio-keys node
> >
> > Signed-off-by: Tim Harvey 
> > ---
> >  arch/arm64/boot/dts/freescale/Makefile |   3 +
> >  .../boot/dts/freescale/imx8mm-venice-gw700x.dtsi   | 497 
> > +
> >  .../boot/dts/freescale/imx8mm-venice-gw71xx-0x.dts |  19 +
> >  .../boot/dts/freescale/imx8mm-venice-gw71xx.dtsi   | 186 
> >  .../boot/dts/freescale/imx8mm-venice-gw72xx-0x.dts |  20 +
> >  .../boot/dts/freescale/imx8mm-venice-gw72xx.dtsi   | 314 +
> >  .../boot/dts/freescale/imx8mm-venice-gw73xx-0x.dts |  19 +
> >  .../boot/dts/freescale/imx8mm-venice-gw73xx.dtsi   | 366 +++
> >  8 files changed, 1424 insertions(+)
> >  create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi
> >  create mode 100644 
> > arch/arm64/boot/dts/freescale/imx8mm-venice-gw71xx-0x.dts
> >  create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-venice-gw71xx.dtsi
> >  create mode 100644 
> > arch/arm64/boot/dts/freescale/imx8mm-venice-gw72xx-0x.dts
> >  create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-venice-gw72xx.dtsi
> >  create mode 100644 
> > arch/arm64/boot/dts/freescale/imx8mm-venice-gw73xx-0x.dts
> >  create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-venice-gw

[PATCH v4 2/2] arm64: dts: imx8mm: Add Gateworks i.MX 8M Mini Development Kits

[Tim Harvey]

The Gateworks Venice GW71xx-0x/GW72xx-0x/GW73xx-0x are development
kits comprised of a GW700x SoM and a Baseboard. Future SoM's such
as the GW701x will create additional combinations.

The GW700x SoM contains:
 - i.MX 8M Mini SoC
 - LPDDR4 DRAM
 - eMMC FLASH
 - Gateworks System Controller (eeprom/pushbutton/reset/voltage-monitor)
 - GbE PHY connected to the i.MX 8M Mini FEC
 - Power Management IC

The GW71xx Baseboard contains:
 - 1x MiniPCIe Socket with USB2.0, PCIe, and SIM
 - 1x RJ45 GbE (i.MX 8M Mini FEC)
 - I/O connector with 1x-SPI/1x-I2C/1x-UART/4x-GPIO signals
 - PCIe Clock generator
 - GPS and accelerometer
 - 1x USB 2.0 Front Panel connector
 - wide range power supply

The GW72xx Baseboard contains:
 - 2x MiniPCIe Socket with USB2.0, PCIe, and SIM
 - 2x RJ45 GbE (i.MX 8M Mini FEC and LAN743x)
 - 1x MicroSD connector
 - 1x USB 2.0 Front Panel connector
 - 1x SPI connector
 - 1x Serial connector supporting 2x-UART or 1x-UART configured as 1 of:
   RS232 w/ flow-controll, RS485, RS422
 - PCIe Clock generator
 - GPS and accelerometer
 - Media Expansion connector (MIPI-CSI/MIPI-DSI/GPIO/I2S)
 - I/O connector with 2x-ADC,2x-GPIO,1x-UART,1x-I2C
 - wide range power supply

The GW73xx Baseboard contains:
 - 3x MiniPCIe Socket with USB2.0, PCIe, and SIM
 - 2x RJ45 GbE (i.MX 8M Mini FEC and LAN743x)
 - 1x MicroSD connector
 - 1x USB 2.0 Front Panel connector
 - 1x SPI connector
 - 1x Serial connector supporting 2x-UART or 1x-UART configured as 1 of:
   RS232 w/ flow-controll, RS485, RS422
 - WiFi/BT
 - PCIe Clock generator
 - GPS and accelerometer
 - Media Expansion connector (MIPI-CSI/MIPI-DSI/GPIO/I2S)
 - I/O connector with 2x-ADC,2x-GPIO,1x-UART,1x-I2C
 - wide range power supply

Signed-off-by: Tim Harvey 
---
v4:
 - replace underscore with hyphen for gpio-keys node
 - add 'off-board header' comments to i2c/spi/uart nodes that go off-board
 - move node comments to own line above node
 - add spaces after comma
 - move uart2_gpio rs485 config pinmux to hoggroup as they don't necessarily
   relate to uart2
 - fix fifo-depth dt property for phy

v3:
 - fix gpio controller node name
 - add rtc node to SoM
 - add pmic pinctrl to SoM
 - fixed compatible string for SoM eeprom's

v2:
 - fix i.MX 8M Mini name in commit log
 - consistent use of underscore vs hyphen in labels
 - fix gsc interrupt type
 - fix iomux group node names
 - fix led-controller bindings:
   (use correct node names, color, function and remove label)
 - use accelerometer node name vs accel
 - remove sai3 from gw71xx baseboard
 - added serial connector description to commit message
 - added I/O connector description to commit message
 - removed unnecessary #address-cells/#size-cells from gpio-keys node

Signed-off-by: Tim Harvey 
---
 arch/arm64/boot/dts/freescale/Makefile |   3 +
 .../boot/dts/freescale/imx8mm-venice-gw700x.dtsi   | 497 +
 .../boot/dts/freescale/imx8mm-venice-gw71xx-0x.dts |  19 +
 .../boot/dts/freescale/imx8mm-venice-gw71xx.dtsi   | 186 
 .../boot/dts/freescale/imx8mm-venice-gw72xx-0x.dts |  20 +
 .../boot/dts/freescale/imx8mm-venice-gw72xx.dtsi   | 314 +
 .../boot/dts/freescale/imx8mm-venice-gw73xx-0x.dts |  19 +
 .../boot/dts/freescale/imx8mm-venice-gw73xx.dtsi   | 366 +++
 8 files changed, 1424 insertions(+)
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-venice-gw71xx-0x.dts
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-venice-gw71xx.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-venice-gw72xx-0x.dts
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-venice-gw72xx.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-venice-gw73xx-0x.dts
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-venice-gw73xx.dtsi

diff --git a/arch/arm64/boot/dts/freescale/Makefile 
b/arch/arm64/boot/dts/freescale/Makefile
index f8d5943..ecdd233 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -32,6 +32,9 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mm-beacon-kit.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mm-evk.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mm-ddr4-evk.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mm-var-som-symphony.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mm-venice-gw71xx-0x.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mm-venice-gw72xx-0x.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mm-venice-gw73xx-0x.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mn-evk.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mn-ddr4-evk.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mn-var-som-symphony.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi 
b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi
new file mode 100644
index ..5985a39
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi
@@ -0,0 +1,497 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2020 Gateworks Corporation
+ */
+
+#include 
+#include 
+#include

[PATCH v4 1/2] dt-bindings: arm: fsl: Add binding for Gateworks boards with IMX8MM

[Tim Harvey]

Add bindings for the Gateworks Venice Development kit boards with
IMX8MM System on Module.

Signed-off-by: Tim Harvey 
---
v4: no changes
v3: no changes
v2: no changes
---
 Documentation/devicetree/bindings/arm/fsl.yaml | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml 
b/Documentation/devicetree/bindings/arm/fsl.yaml
index 1ca9dfa..705c6e8 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -405,6 +405,9 @@ properties:
   - beacon,imx8mm-beacon-kit  # i.MX8MM Beacon Development Kit
   - fsl,imx8mm-ddr4-evk   # i.MX8MM DDR4 EVK Board
   - fsl,imx8mm-evk# i.MX8MM EVK Board
+  - gw,imx8mm-gw71xx-0x   # i.MX8MM Gateworks Development Kit
+  - gw,imx8mm-gw72xx-0x   # i.MX8MM Gateworks Development Kit
+  - gw,imx8mm-gw73xx-0x   # i.MX8MM Gateworks Development Kit
   - variscite,var-som-mx8mm   # i.MX8MM Variscite VAR-SOM-MX8MM 
module
   - const: fsl,imx8mm
 
-- 
2.7.4

Re: [PATCH] regmap: irq: do not allow setting irq bits during ack

[Tim Harvey]

On Wed, Dec 30, 2020 at 5:14 AM Mark Brown  wrote:
>
> On Tue, Dec 29, 2020 at 08:23:00AM -0800, Tim Harvey wrote:
> > On Tue, Dec 29, 2020 at 5:06 AM Mark Brown  wrote:
>
> > > I can't understand what this commit message is trying to say, sorry.
> > > Which bits are you talking about when you say "if bits are set"?  Isn't
> > > acknowleding the interrupt clearing the bits asserting the interrupt?  I
> > > can't tell what the problem you're trying to fix is.
>
> > If for example status=0x01 the current code for ack_invert will write
> > a 0xfe to clear that bit which ends up setting all other interrupt
> > bits keeping the interrupt from ever being de-asserted. With the patch
> > applied a status=0x01 will result in a 0x00 written to clear that bit
> > and keep other's from being set.
>
> But that's not an inverted ack as far as I can see?  That's writing back
> the bit you're trying to clear which is the default ack.  Why do you
> believe this is an inverted ack?  In any case the changelog for the
> patch needs to be clear.

Mark,

It 'is' inverted ack because the device I have requires a '0' to be
written to clear the interrupt instead of a '1'.

The chip I'm using has a status register where bit values of 1
indicate an interrupt assertion and to clear it you write a 0 (where
as the typical non-ack-invert case you write a 1 to clear). The chip
I'm using also allows you to 'set' (by writing a 1) to bits that were
not already set which would keep it from de-asserting it's interrupt.

Honestly I thought the commit message was very clear. What exactly is
your suggestion? It is of course confusing when talking about code
that handles both ack invert and the normal case (let alone the new
case of 'clear_ack').

Best regards,

Tim

Re: [PATCH] regmap: irq: do not allow setting irq bits during ack

[Tim Harvey]

On Tue, Dec 29, 2020 at 5:06 AM Mark Brown  wrote:
>
> On Mon, Dec 28, 2020 at 01:45:51PM -0800, Tim Harvey wrote:
>
> > Some interrupt controllers may not de-assert their interrupt if
> > bits are set when acknowledging the bits that caused the interrupt.
>
> > Take care to not apply the mask to the status until we are done
> > acknowledging the interrupt and take care to mask the bits according
> > for the ack_invert state.
>
> I can't understand what this commit message is trying to say, sorry.
> Which bits are you talking about when you say "if bits are set"?  Isn't
> acknowleding the interrupt clearing the bits asserting the interrupt?  I
> can't tell what the problem you're trying to fix is.

Mark,

If for example status=0x01 the current code for ack_invert will write
a 0xfe to clear that bit which ends up setting all other interrupt
bits keeping the interrupt from ever being de-asserted. With the patch
applied a status=0x01 will result in a 0x00 written to clear that bit
and keep other's from being set.

Tim

[PATCH v3 2/2] arm64: dts: imx8mm: Add Gateworks i.MX 8M Mini Development Kits

[Tim Harvey]

The Gateworks Venice GW71xx-0x/GW72xx-0x/GW73xx-0x are development
kits comprised of a GW700x SoM and a Baseboard. Future SoM's such
as the GW701x will create additional combinations.

The GW700x SoM contains:
 - i.MX 8M Mini SoC
 - LPDDR4 DRAM
 - eMMC FLASH
 - Gateworks System Controller (eeprom/pushbutton/reset/voltage-monitor)
 - GbE PHY connected to the i.MX 8M Mini FEC
 - Power Management IC

The GW71xx Baseboard contains:
 - 1x MiniPCIe Socket with USB2.0, PCIe, and SIM
 - 1x RJ45 GbE (i.MX 8M Mini FEC)
 - I/O connector with 1x-SPI/1x-I2C/1x-UART/4x-GPIO signals
 - PCIe Clock generator
 - GPS and accelerometer
 - 1x USB 2.0 Front Panel connector
 - wide range power supply

The GW72xx Baseboard contains:
 - 2x MiniPCIe Socket with USB2.0, PCIe, and SIM
 - 2x RJ45 GbE (i.MX 8M Mini FEC and LAN743x)
 - 1x MicroSD connector
 - 1x USB 2.0 Front Panel connector
 - 1x SPI connector
 - 1x Serial connector supporting 2x-UART or 1x-UART configured as 1 of:
   RS232 w/ flow-controll, RS485, RS422
 - PCIe Clock generator
 - GPS and accelerometer
 - Media Expansion connector (MIPI-CSI/MIPI-DSI/GPIO/I2S)
 - I/O connector with 2x-ADC,2x-GPIO,1x-UART,1x-I2C
 - wide range power supply

The GW73xx Baseboard contains:
 - 3x MiniPCIe Socket with USB2.0, PCIe, and SIM
 - 2x RJ45 GbE (i.MX 8M Mini FEC and LAN743x)
 - 1x MicroSD connector
 - 1x USB 2.0 Front Panel connector
 - 1x SPI connector
 - 1x Serial connector supporting 2x-UART or 1x-UART configured as 1 of:
   RS232 w/ flow-controll, RS485, RS422
 - WiFi/BT
 - PCIe Clock generator
 - GPS and accelerometer
 - Media Expansion connector (MIPI-CSI/MIPI-DSI/GPIO/I2S)
 - I/O connector with 2x-ADC,2x-GPIO,1x-UART,1x-I2C
 - wide range power supply

Signed-off-by: Tim Harvey 
---
v3:
 - fix gpio controller node name
 - add rtc node to SoM
 - add pmic pinctrl to SoM
 - fixed compatible string for SoM eeprom's

v2:
 - fix i.MX 8M Mini name in commit log
 - consistent use of underscore vs hyphen in labels
 - fix gsc interrupt type
 - fix iomux group node names
 - fix led-controller bindings:
   (use correct node names, color, function and remove label)
 - use accelerometer node name vs accel
 - remove sai3 from gw71xx baseboard
 - added serial connector description to commit message
 - added I/O connector description to commit message
 - removed unnecessary #address-cells/#size-cells from gpio-keys node
---
 arch/arm64/boot/dts/freescale/Makefile |   3 +
 .../boot/dts/freescale/imx8mm-venice-gw700x.dtsi   | 495 +
 .../boot/dts/freescale/imx8mm-venice-gw71xx-0x.dts |  19 +
 .../boot/dts/freescale/imx8mm-venice-gw71xx.dtsi   | 182 
 .../boot/dts/freescale/imx8mm-venice-gw72xx-0x.dts |  20 +
 .../boot/dts/freescale/imx8mm-venice-gw72xx.dtsi   | 316 +
 .../boot/dts/freescale/imx8mm-venice-gw73xx-0x.dts |  19 +
 .../boot/dts/freescale/imx8mm-venice-gw73xx.dtsi   | 368 +++
 8 files changed, 1422 insertions(+)
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-venice-gw71xx-0x.dts
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-venice-gw71xx.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-venice-gw72xx-0x.dts
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-venice-gw72xx.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-venice-gw73xx-0x.dts
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-venice-gw73xx.dtsi

diff --git a/arch/arm64/boot/dts/freescale/Makefile 
b/arch/arm64/boot/dts/freescale/Makefile
index f8d5943..ecdd233 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -32,6 +32,9 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mm-beacon-kit.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mm-evk.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mm-ddr4-evk.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mm-var-som-symphony.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mm-venice-gw71xx-0x.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mm-venice-gw72xx-0x.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mm-venice-gw73xx-0x.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mn-evk.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mn-ddr4-evk.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mn-var-som-symphony.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi 
b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi
new file mode 100644
index ..bc63525
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi
@@ -0,0 +1,495 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2020 Gateworks Corporation
+ */
+
+#include 
+#include 
+#include 
+
+/ {
+   memory@4000 {
+   device_type = "memory";
+   reg = <0x0 0x4000 0 0x8000>;
+   };
+
+   gpio_keys {
+   compatible = "gpio-keys";
+
+   user_pb {
+   label = "user_pb";
+   gpios = < 2 GPIO_ACTIVE_L

[PATCH v3 1/2] dt-bindings: arm: fsl: Add binding for Gateworks boards with IMX8MM

[Tim Harvey]

Add bindings for the Gateworks Venice Development kit boards with
IMX8MM System on Module.

Signed-off-by: Tim Harvey 
---
v3: no changes
v2: no changes
---
 Documentation/devicetree/bindings/arm/fsl.yaml | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml 
b/Documentation/devicetree/bindings/arm/fsl.yaml
index 1ca9dfa..705c6e8 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -405,6 +405,9 @@ properties:
   - beacon,imx8mm-beacon-kit  # i.MX8MM Beacon Development Kit
   - fsl,imx8mm-ddr4-evk   # i.MX8MM DDR4 EVK Board
   - fsl,imx8mm-evk# i.MX8MM EVK Board
+  - gw,imx8mm-gw71xx-0x   # i.MX8MM Gateworks Development Kit
+  - gw,imx8mm-gw72xx-0x   # i.MX8MM Gateworks Development Kit
+  - gw,imx8mm-gw73xx-0x   # i.MX8MM Gateworks Development Kit
   - variscite,var-som-mx8mm   # i.MX8MM Variscite VAR-SOM-MX8MM 
module
   - const: fsl,imx8mm
 
-- 
2.7.4

[PATCH v2 1/2] dt-bindings: arm: fsl: Add binding for Gateworks boards with IMX8MM

[Tim Harvey]

Add bindings for the Gateworks Venice Development kit boards with
IMX8MM System on Module.

Signed-off-by: Tim Harvey 
---
v2: no changes

---
 Documentation/devicetree/bindings/arm/fsl.yaml | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml 
b/Documentation/devicetree/bindings/arm/fsl.yaml
index 1ca9dfa..705c6e8 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -405,6 +405,9 @@ properties:
   - beacon,imx8mm-beacon-kit  # i.MX8MM Beacon Development Kit
   - fsl,imx8mm-ddr4-evk   # i.MX8MM DDR4 EVK Board
   - fsl,imx8mm-evk# i.MX8MM EVK Board
+  - gw,imx8mm-gw71xx-0x   # i.MX8MM Gateworks Development Kit
+  - gw,imx8mm-gw72xx-0x   # i.MX8MM Gateworks Development Kit
+  - gw,imx8mm-gw73xx-0x   # i.MX8MM Gateworks Development Kit
   - variscite,var-som-mx8mm   # i.MX8MM Variscite VAR-SOM-MX8MM 
module
   - const: fsl,imx8mm
 
-- 
2.7.4

[PATCH v2 2/2] arm64: dts: imx8mm: Add Gateworks i.MX 8M Mini Development Kits

[Tim Harvey]

The Gateworks Venice GW71xx-0x/GW72xx-0x/GW73xx-0x are development
kits comprised of a GW700x SoM and a Baseboard. Future SoM's such
as the GW701x will create additional combinations.

The GW700x SoM contains:
 - i.MX 8M Mini SoC
 - LPDDR4 DRAM
 - eMMC FLASH
 - Gateworks System Controller (eeprom/pushbutton/reset/voltage-monitor)
 - GbE PHY connected to the i.MX 8M Mini FEC
 - Power Management IC

The GW71xx Baseboard contains:
 - 1x MiniPCIe Socket with USB2.0, PCIe, and SIM
 - 1x RJ45 GbE (i.MX 8M Mini FEC)
 - I/O connector with 1x-SPI/1x-I2C/1x-UART/4x-GPIO signals
 - PCIe Clock generator
 - GPS and accelerometer
 - 1x USB 2.0 Front Panel connector
 - wide range power supply

The GW72xx Baseboard contains:
 - 2x MiniPCIe Socket with USB2.0, PCIe, and SIM
 - 2x RJ45 GbE (i.MX 8M Mini FEC and LAN743x)
 - 1x MicroSD connector
 - 1x USB 2.0 Front Panel connector
 - 1x SPI connector
 - 1x Serial connector supporting 2x-UART or 1x-UART configured as 1 of:
   RS232 w/ flow-controll, RS485, RS422
 - PCIe Clock generator
 - GPS and accelerometer
 - Media Expansion connector (MIPI-CSI/MIPI-DSI/GPIO/I2S)
 - I/O connector with 2x-ADC,2x-GPIO,1x-UART,1x-I2C
 - wide range power supply

The GW73xx Baseboard contains:
 - 3x MiniPCIe Socket with USB2.0, PCIe, and SIM
 - 2x RJ45 GbE (i.MX 8M Mini FEC and LAN743x)
 - 1x MicroSD connector
 - 1x USB 2.0 Front Panel connector
 - 1x SPI connector
 - 1x Serial connector supporting 2x-UART or 1x-UART configured as 1 of:
   RS232 w/ flow-controll, RS485, RS422
 - WiFi/BT
 - PCIe Clock generator
 - GPS and accelerometer
 - Media Expansion connector (MIPI-CSI/MIPI-DSI/GPIO/I2S)
 - I/O connector with 2x-ADC,2x-GPIO,1x-UART,1x-I2C
 - wide range power supply

Signed-off-by: Tim Harvey 
---
v2:
 - fix i.MX 8M Mini name in commit log
 - consistent use of underscore vs hyphen in labels
 - fix gsc interrupt type
 - fix iomux group node names
 - fix led-controller bindings:
   (use correct node names, color, function and remove label)
 - use accelerometer node name vs accel
 - remove sai3 from gw71xx baseboard
 - added serial connector description to commit message
 - added I/O connector description to commit message
 - removed unnecessary #address-cells/#size-cells from gpio-keys node
---
 arch/arm64/boot/dts/freescale/Makefile |   3 +
 .../boot/dts/freescale/imx8mm-venice-gw700x.dtsi   | 480 +
 .../boot/dts/freescale/imx8mm-venice-gw71xx-0x.dts |  19 +
 .../boot/dts/freescale/imx8mm-venice-gw71xx.dtsi   | 182 
 .../boot/dts/freescale/imx8mm-venice-gw72xx-0x.dts |  20 +
 .../boot/dts/freescale/imx8mm-venice-gw72xx.dtsi   | 316 ++
 .../boot/dts/freescale/imx8mm-venice-gw73xx-0x.dts |  19 +
 .../boot/dts/freescale/imx8mm-venice-gw73xx.dtsi   | 368 
 8 files changed, 1407 insertions(+)
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-venice-gw71xx-0x.dts
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-venice-gw71xx.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-venice-gw72xx-0x.dts
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-venice-gw72xx.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-venice-gw73xx-0x.dts
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-venice-gw73xx.dtsi

diff --git a/arch/arm64/boot/dts/freescale/Makefile 
b/arch/arm64/boot/dts/freescale/Makefile
index f8d5943..ecdd233 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -32,6 +32,9 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mm-beacon-kit.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mm-evk.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mm-ddr4-evk.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mm-var-som-symphony.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mm-venice-gw71xx-0x.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mm-venice-gw72xx-0x.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mm-venice-gw73xx-0x.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mn-evk.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mn-ddr4-evk.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mn-var-som-symphony.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi 
b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi
new file mode 100644
index ..e039ba1
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi
@@ -0,0 +1,480 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2020 Gateworks Corporation
+ */
+
+#include 
+#include 
+#include 
+
+/ {
+   memory@4000 {
+   device_type = "memory";
+   reg = <0x0 0x4000 0 0x8000>;
+   };
+
+   gpio_keys {
+   compatible = "gpio-keys";
+
+   user_pb {
+   label = "user_pb";
+   gpios = < 2 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   };
+
+   user_pb1x {
+   label = "

[PATCH] regmap: irq: do not allow setting irq bits during ack

[Tim Harvey]

Some interrupt controllers may not de-assert their interrupt if
bits are set when acknowledging the bits that caused the interrupt.

Take care to not apply the mask to the status until we are done
acknowledging the interrupt and take care to mask the bits according
for the ack_invert state.

This is needed to avoid a stuck interrupt case for the Gateworks
System Controller which uses ack_invert. If the status has the mask
applied before clearing the bits it will end up setting bits that
are enabled but were not the cause the interrupt which will keep
the GSC from ever de-asserting its interrupt.

Cc: Tony Lindgren 
Cc: Laxminath Kasam 
Cc: Robert Jones 
Signed-off-by: Tim Harvey 
---
 drivers/base/regmap/regmap-irq.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/base/regmap/regmap-irq.c b/drivers/base/regmap/regmap-irq.c
index ad5c2de..560c641 100644
--- a/drivers/base/regmap/regmap-irq.c
+++ b/drivers/base/regmap/regmap-irq.c
@@ -496,29 +496,29 @@ static irqreturn_t regmap_irq_thread(int irq, void *d)
 * doing a write per register.
 */
for (i = 0; i < data->chip->num_regs; i++) {
-   data->status_buf[i] &= ~data->mask_buf[i];
-
-   if (data->status_buf[i] && (chip->ack_base || chip->use_ack)) {
+   if ((data->status_buf[i] && ~data->mask_buf[i]) &&
+   (chip->ack_base || chip->use_ack)) {
reg = chip->ack_base +
(i * map->reg_stride * data->irq_reg_stride);
if (chip->ack_invert)
ret = regmap_write(map, reg,
-   ~data->status_buf[i]);
+   ~data->status_buf[i] & 
data->mask_buf[i]);
else
ret = regmap_write(map, reg,
-   data->status_buf[i]);
+   data->status_buf[i] & 
~data->mask_buf[i]);
if (chip->clear_ack) {
if (chip->ack_invert && !ret)
ret = regmap_write(map, reg,
-   data->status_buf[i]);
+   data->status_buf[i] & 
~data->mask_buf[i]);
else if (!ret)
ret = regmap_write(map, reg,
-   ~data->status_buf[i]);
+   ~data->status_buf[i] & 
data->mask_buf[i]);
}
if (ret != 0)
dev_err(map->dev, "Failed to ack 0x%x: %d\n",
reg, ret);
}
+   data->status_buf[i] &= ~data->mask_buf[i];
}
 
for (i = 0; i < chip->num_irqs; i++) {
-- 
2.7.4

[PATCH] mfd: gateworks-gsc: fix interrupt type

[Tim Harvey]

The Gateworks System Controller has an active-low interrupt.
Fix the interrupt request type.

Fixes: d85234994b2f ("mfd: Add Gateworks System Controller core driver")

Cc: 
Signed-off-by: Tim Harvey 
---
 drivers/mfd/gateworks-gsc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mfd/gateworks-gsc.c b/drivers/mfd/gateworks-gsc.c
index 576da62..d878767 100644
--- a/drivers/mfd/gateworks-gsc.c
+++ b/drivers/mfd/gateworks-gsc.c
@@ -234,7 +234,7 @@ static int gsc_probe(struct i2c_client *client)
 
ret = devm_regmap_add_irq_chip(dev, gsc->regmap, client->irq,
   IRQF_ONESHOT | IRQF_SHARED |
-  IRQF_TRIGGER_FALLING, 0,
+  IRQF_TRIGGER_LOW, 0,
   _irq_chip, _data);
if (ret)
return ret;
-- 
2.7.4

[PATCH] dt-bindings: mfd: gateworks-gsc: Add fan-tach mode

[Tim Harvey]

In 7497d4a66c59 ("hwmon: (gsc-hwmon) add fan sensor") a mode
was added to report RPM's from a fan tach input.

Add this mode to the dt-bindings for the Gateworks System Controller.

Signed-off-by: Tim Harvey 
---
 Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml 
b/Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml
index d08e8fe..5a1e8d2 100644
--- a/Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml
+++ b/Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml
@@ -83,8 +83,9 @@ properties:
 2 - scaled voltage based on an optional resistor divider
 and optional offset
 3 - pre-scaled 16-bit voltage value
+4 - fan tach input to report RPM's
 $ref: /schemas/types.yaml#/definitions/uint32
-enum: [0, 1, 2, 3]
+enum: [0, 1, 2, 3, 4]
 
   gw,voltage-divider-ohms:
 description: Values of resistors for divider on raw ADC input
-- 
2.7.4

Re: [PATCH 2/2] arm64: dts: imx8mm: Add Gateworks IMX8MM Development Kits

[Tim Harvey]

On Thu, Dec 24, 2020 at 3:37 AM Krzysztof Kozlowski  wrote:
>

Thanks for the review!

> On Wed, Dec 23, 2020 at 02:23:16PM -0800, Tim Harvey wrote:
> > The Gateworks Venice GW71xx-0x/GW72xx-0x/GW73xx-0x are development
> > kits comprised of a GW700x SoM and a Baseboard.
> >
> > The GW700x SoM contains:
> >  - IMX8MM SoC
>
> It's i.MX 8M Mini.
> https://www.nxp.com/products/processors-and-microcontrollers/arm-processors/i-mx-applications-processors/i-mx-8-processors/i-mx-8m-mini-arm-cortex-a53-cortex-m4-audio-voice-video:i.MX8MMINI
>

ok

> >  - LPDDR4 DRAM
> >  - eMMC FLASH
> >  - Gateworks System Controller (eeprom/pushbutton/reset/voltage-monitor)
> >  - GbE PHY connected to the IMX8MM FEC
> >  - Power Management IC
> >
> > The GW71xx Baseboard contains:
> >  - 1x MiniPCIe Socket with USB2.0, PCIe, and SIM
> >  - 1x RJ45 GbE (IMX8MM FEC)
> >  - PCIe Clock generator
> >  - GPS and accelerometer
> >  - 1x USB 2.0 Front Panel connector
> >  - wide range power supply
> >
> > The GW72xx Baseboard contains:
> >  - 2x MiniPCIe Socket with USB2.0, PCIe, and SIM
> >  - 2x RJ45 GbE (IMX8MM FEC and LAN743x)
> >  - 1x MicroSD connector
> >  - 1x USB 2.0 Front Panel connector
> >  - 1x SPI connector
> >  - PCIe Clock generator
> >  - GPS and accelerometer
> >  - Media Expansion connector (MIPI-CSI/MIPI-DSI/GPIO/I2S)
> >  - wide range power supply
> >
> > The GW73xx Baseboard contains:
> >  - 3x MiniPCIe Socket with USB2.0, PCIe, and SIM
> >  - 2x RJ45 GbE (IMX8MM FEC and LAN743x)
> >  - 1x MicroSD connector
> >  - 1x USB 2.0 Front Panel connector
> >  - 1x SPI connector
> >  - WiFi/BT
> >  - PCIe Clock generator
> >  - GPS and accelerometer
> >  - Media Expansion connector (MIPI-CSI/MIPI-DSI/GPIO/I2S)
> >  - wide range power supply
> >
> > Signed-off-by: Tim Harvey 
> > ---

> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi
> > @@ -0,0 +1,482 @@
> > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > +/*
> > + * Copyright 2020 Gateworks Corporation
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +
> > +/ {
> > + memory@4000 {
> > + device_type = "memory";
> > + reg = <0x0 0x4000 0 0x8000>;
> > + };
> > +
> > + gpio_keys {
> > + compatible = "gpio-keys";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + user_pb {
> > + label = "user_pb";
> > + gpios = <_gpio 2 GPIO_ACTIVE_LOW>;
> > + linux,code = ;
> > + };
> > +
> > + user_pb1x {
> > + label = "user_pb1x";
> > + linux,code = ;
> > + interrupt-parent = <>;
> > + interrupts = <0>;
> > + };
> > +
> > + key_erased {
> > + label = "key-erased";
>
> Above you use underscore, here hyphen. Make it consistent.

ok

>
> > + linux,code = ;
> > + interrupt-parent = <>;
> > + interrupts = <1>;
> > + };
> > +
> > + eeprom_wp {
> > + label = "eeprom_wp";
> > + linux,code = ;
> > + interrupt-parent = <>;
> > + interrupts = <2>;
> > + };
> > +
> > + tamper {
> > + label = "tamper";
> > + linux,code = ;
> > + interrupt-parent = <>;
> > + interrupts = <5>;
> > + };
> > +
> > + switch_hold {
> > + label = "switch_hold";
> > + linux,code = ;
> > + interrupt-parent = <>;
> > + interrupts = <7>;
> > + };
> > + };
> > +};
> > +

> > +
> > + {
> > + clock-frequency = <10>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <_i2c1>;
> > + status = "okay";
> > +
> > + gsc: gsc@20 {
>
> Node name should descr

Re: [PATCH 2/2] arm64: dts: imx8mm: Add Gateworks IMX8MM Development Kits

[Tim Harvey]

On Thu, Dec 24, 2020 at 7:34 AM Sven Van Asbroeck  wrote:
>
> Tim, Anders,
>
> On Wed, Dec 23, 2020 at 5:45 PM Tim Harvey  wrote:
> >
> >  - 2x RJ45 GbE (IMX8MM FEC and LAN743x)
>
> I noticed that you are users of the LAN743x PCIe ethernet chip.
>
> On non-cache snooping architectures such as ARM, the receive performance of
> this chip's driver is about 1/3 of what it should be. I am currently 
> preparing a
> patch set which boosts performance x3, but it's not trivial, so I am looking 
> for
> LAN743X users who could help test the patch set - especially on arm64 or x86,
> architectures I have no access to.
>

Sven,

I'm happy to test your patches for lan743x.

Best regards,

Tim

Re: [PATCH 1/2] dt-bindings: arm: fsl: Add binding for Gateworks boards with IMX8MM

[Tim Harvey]

On Thu, Dec 24, 2020 at 3:23 AM Krzysztof Kozlowski  wrote:
>
> On Wed, Dec 23, 2020 at 02:23:15PM -0800, Tim Harvey wrote:
> > Add bindings for the Gateworks Venice Development kit boards with
> > IMX8MM System on Module.
> >
> > Signed-off-by: Tim Harvey 
> > ---
> >  Documentation/devicetree/bindings/arm/fsl.yaml | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml 
> > b/Documentation/devicetree/bindings/arm/fsl.yaml
> > index 1ca9dfa..705c6e8 100644
> > --- a/Documentation/devicetree/bindings/arm/fsl.yaml
> > +++ b/Documentation/devicetree/bindings/arm/fsl.yaml
> > @@ -405,6 +405,9 @@ properties:
> >- beacon,imx8mm-beacon-kit  # i.MX8MM Beacon Development Kit
> >- fsl,imx8mm-ddr4-evk   # i.MX8MM DDR4 EVK Board
> >- fsl,imx8mm-evk# i.MX8MM EVK Board
> > +  - gw,imx8mm-gw71xx-0x   # i.MX8MM Gateworks Development 
> > Kit
> > +  - gw,imx8mm-gw72xx-0x   # i.MX8MM Gateworks Development 
> > Kit
> > +  - gw,imx8mm-gw73xx-0x   # i.MX8MM Gateworks Development 
> > Kit
>
> I think you should skip the wildcards in compatible and choose one
> specific compatible. What if at some point you would like to add 
> gw,imx8mm-gw7113-0x?
>

Krzysztof,

Thanks for the review. I do want the wildcards as above because they
represent model variations that do not affect device-tree such as
component subloads.

Thanks,

Tim

[PATCH 1/2] dt-bindings: arm: fsl: Add binding for Gateworks boards with IMX8MM

[Tim Harvey]

Add bindings for the Gateworks Venice Development kit boards with
IMX8MM System on Module.

Signed-off-by: Tim Harvey 
---
 Documentation/devicetree/bindings/arm/fsl.yaml | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml 
b/Documentation/devicetree/bindings/arm/fsl.yaml
index 1ca9dfa..705c6e8 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -405,6 +405,9 @@ properties:
   - beacon,imx8mm-beacon-kit  # i.MX8MM Beacon Development Kit
   - fsl,imx8mm-ddr4-evk   # i.MX8MM DDR4 EVK Board
   - fsl,imx8mm-evk# i.MX8MM EVK Board
+  - gw,imx8mm-gw71xx-0x   # i.MX8MM Gateworks Development Kit
+  - gw,imx8mm-gw72xx-0x   # i.MX8MM Gateworks Development Kit
+  - gw,imx8mm-gw73xx-0x   # i.MX8MM Gateworks Development Kit
   - variscite,var-som-mx8mm   # i.MX8MM Variscite VAR-SOM-MX8MM 
module
   - const: fsl,imx8mm
 
-- 
2.7.4

[PATCH 2/2] arm64: dts: imx8mm: Add Gateworks IMX8MM Development Kits

[Tim Harvey]

The Gateworks Venice GW71xx-0x/GW72xx-0x/GW73xx-0x are development
kits comprised of a GW700x SoM and a Baseboard.

The GW700x SoM contains:
 - IMX8MM SoC
 - LPDDR4 DRAM
 - eMMC FLASH
 - Gateworks System Controller (eeprom/pushbutton/reset/voltage-monitor)
 - GbE PHY connected to the IMX8MM FEC
 - Power Management IC

The GW71xx Baseboard contains:
 - 1x MiniPCIe Socket with USB2.0, PCIe, and SIM
 - 1x RJ45 GbE (IMX8MM FEC)
 - PCIe Clock generator
 - GPS and accelerometer
 - 1x USB 2.0 Front Panel connector
 - wide range power supply

The GW72xx Baseboard contains:
 - 2x MiniPCIe Socket with USB2.0, PCIe, and SIM
 - 2x RJ45 GbE (IMX8MM FEC and LAN743x)
 - 1x MicroSD connector
 - 1x USB 2.0 Front Panel connector
 - 1x SPI connector
 - PCIe Clock generator
 - GPS and accelerometer
 - Media Expansion connector (MIPI-CSI/MIPI-DSI/GPIO/I2S)
 - wide range power supply

The GW73xx Baseboard contains:
 - 3x MiniPCIe Socket with USB2.0, PCIe, and SIM
 - 2x RJ45 GbE (IMX8MM FEC and LAN743x)
 - 1x MicroSD connector
 - 1x USB 2.0 Front Panel connector
 - 1x SPI connector
 - WiFi/BT
 - PCIe Clock generator
 - GPS and accelerometer
 - Media Expansion connector (MIPI-CSI/MIPI-DSI/GPIO/I2S)
 - wide range power supply

Signed-off-by: Tim Harvey 
---
 arch/arm64/boot/dts/freescale/Makefile |   3 +
 .../boot/dts/freescale/imx8mm-venice-gw700x.dtsi   | 482 +
 .../boot/dts/freescale/imx8mm-venice-gw71xx-0x.dts |  19 +
 .../boot/dts/freescale/imx8mm-venice-gw71xx.dtsi   | 186 
 .../boot/dts/freescale/imx8mm-venice-gw72xx-0x.dts |  20 +
 .../boot/dts/freescale/imx8mm-venice-gw72xx.dtsi   | 311 +
 .../boot/dts/freescale/imx8mm-venice-gw73xx-0x.dts |  19 +
 .../boot/dts/freescale/imx8mm-venice-gw73xx.dtsi   | 363 
 8 files changed, 1403 insertions(+)
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-venice-gw71xx-0x.dts
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-venice-gw71xx.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-venice-gw72xx-0x.dts
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-venice-gw72xx.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-venice-gw73xx-0x.dts
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-venice-gw73xx.dtsi

diff --git a/arch/arm64/boot/dts/freescale/Makefile 
b/arch/arm64/boot/dts/freescale/Makefile
index f8d5943..ecdd233 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -32,6 +32,9 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mm-beacon-kit.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mm-evk.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mm-ddr4-evk.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mm-var-som-symphony.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mm-venice-gw71xx-0x.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mm-venice-gw72xx-0x.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mm-venice-gw73xx-0x.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mn-evk.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mn-ddr4-evk.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mn-var-som-symphony.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi 
b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi
new file mode 100644
index ..7e1b96b
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi
@@ -0,0 +1,482 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2020 Gateworks Corporation
+ */
+
+#include 
+#include 
+#include 
+
+/ {
+   memory@4000 {
+   device_type = "memory";
+   reg = <0x0 0x4000 0 0x8000>;
+   };
+
+   gpio_keys {
+   compatible = "gpio-keys";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   user_pb {
+   label = "user_pb";
+   gpios = <_gpio 2 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   };
+
+   user_pb1x {
+   label = "user_pb1x";
+   linux,code = ;
+   interrupt-parent = <>;
+   interrupts = <0>;
+   };
+
+   key_erased {
+   label = "key-erased";
+   linux,code = ;
+   interrupt-parent = <>;
+   interrupts = <1>;
+   };
+
+   eeprom_wp {
+   label = "eeprom_wp";
+   linux,code = ;
+   interrupt-parent = <>;
+   interrupts = <2>;
+   };
+
+   tamper {
+   label = "tamper";
+   linux,code = ;
+   interrupt-parent = <>;
+   interrupts = <5>;
+   };
+
+  

Re: [PATCH] mfd: cpcap: Fix interrupt regression with regmap clear_ack

[Tim Harvey]

On Sun, Nov 15, 2020 at 12:43 AM Tony Lindgren  wrote:
>
> * Tim Harvey  [201113 22:07]:
> > 3a6f0fb7b8eb ("regmap: irq: Add support to clear ack registers")
> > appears to not only add the new clear_ack case it also attempts to
> > resolve the long standing ack_invert issue with this change:
> >
> > - ret = regmap_write(map, reg, data->status_buf[i]);
> > + if (chip->ack_invert)
> > +  ret = regmap_write(map, reg,
> > +  ~data->status_buf[i]);
> > + else
> > + ret = regmap_write(map, reg,
> > + data->status_buf[i]);
>
> Yes that's what I noticed too. And that's why cpcap was working for
> me with ack_invert and without it earlier.
>
> > However, this still doesn't resolve the issue I have with my
> > device/driver because it ends up writing 1's to all the other bits in
> > the ack register which keeps my device's interrupt from de-asserting.
> > Perhaps that's a strange behavior of my device that it allows you to
> > 'set' interrupt source bits which causes the interrupt to stay
> > asserted? I'm also wondering if my issue is that I currently have the
> > interrupt registered as such:
> >
> > ret = devm_regmap_add_irq_chip(dev, gsc->regmap, client->irq,
> > IRQF_ONESHOT | IRQF_SHARED | IRQF_TRIGGER_FALLING, 0, _irq_chip,
> > _data);
> >
> > Perhaps this should be IRQF_TRIGGER_LOW as the device will not
> > de-assert its IRQ# until all source bits are cleared.
>
> Yes could be. For cpcap, we have IRQ_TYPE_LEVEL_HIGH configured in the
> motorola-cpcap-mapphone.dtsi file.
>
> > Tony, I thought that your pcap issue was that it truly did not have an
> > inverted ack and the fact that ack_invert did not work was why you
> > never noticed any issue. If this is true I would think you would want
> > to disable ack_invert but not necessarily enable clear_ack. Did your
> > testing show it needed to toggle the ack to clear it?
>
> Well I looked at the v3.0.8 Motorola Linux Android kernel, it actually
> does clear_ack. So I'd rather keep the same logic as we have no proper
> documentation for cpcap. I also confirmed still works without ack_invert
> too while ack_invert now is broken. But using clear_ack now that we
> have it working seems safer.
>
> Regards,
>
> Tony

Tony,

Ok - sounds like the right thing for your device.

Reviewed-By: Tim Harvey 

Tim

Re: [PATCH] mfd: cpcap: Fix interrupt regression with regmap clear_ack

[Tim Harvey]

On Mon, Nov 16, 2020 at 10:59 AM Mark Brown  wrote:
>
> On Fri, Nov 13, 2020 at 02:06:29PM -0800, Tim Harvey wrote:
>
> > asserted? I'm also wondering if my issue is that I currently have the
> > interrupt registered as such:
>
> > ret = devm_regmap_add_irq_chip(dev, gsc->regmap, client->irq,
> > IRQF_ONESHOT | IRQF_SHARED | IRQF_TRIGGER_FALLING, 0, _irq_chip,
> > _data);
>
> > Perhaps this should be IRQF_TRIGGER_LOW as the device will not
> > de-assert its IRQ# until all source bits are cleared.
>
> That's clearly an active low interrupt, it will break things if it's
> registered as edge triggered.

Mark,

Agreed - I will post a fix for my driver that changes it to IRQF_TRIGGER_LOW

What are your thoughts regarding the issue of  regmap_irq_sync_unlock
ack_invert ack'ing by writing ~d->mask_buf[i] which ends up setting
all the other bits not trying to be awk'd? I would say that the device
allowing an interrupt status to be 'set' and keeping it from releasing
its IRQ is strange/broken for sure, but I'll need to work around it
somehow.

Best Regards,

Tim

Re: [PATCH] mfd: cpcap: Fix interrupt regression with regmap clear_ack

[Tim Harvey]

On Fri, Nov 13, 2020 at 2:21 AM Lee Jones  wrote:
>
> On Wed, 11 Nov 2020, Tony Lindgren wrote:
>
> > With commit 3a6f0fb7b8eb ("regmap: irq: Add support to clear ack
> > registers"), the cpcap interrupts are no longer getting acked properly
> > leading to a very unresponsive device with CPUs fully loaded spinning
> > in the threaded IRQ handlers.
> >
> > To me it looks like the clear_ack commit above actually fixed a long
> > standing bug in regmap_irq_thread() where we unconditionally acked the
> > interrupts earlier without considering ack_invert. And the issue with
> > cpcap started happening as we now also consider ack_invert.
> >
> > Tim Harvey  tried to fix this issue earlier with
> > "[PATCH v2] regmap: irq: fix ack-invert", but the reading of the ack
> > register was considered unnecessary for just ack_invert, and we did not
> > have clear_ack available yet. As the cpcap irqs worked both with and
> > without ack_invert earlier because of the unconditional ack, the
> > problem remained hidden until now.
> >
> > Also, looks like the earlier v3.0.8 based Motorola Android Linux kernel
> > does clear_ack style read-clear-write with "ireg_val & ~mreg_val" instead
> > of just ack_invert style write. So let's switch cpcap to use clear_ack
> > to fix the issue.
> >
> > Fixes: 3a6f0fb7b8eb ("regmap: irq: Add support to clear ack registers")
> > Cc: Carl Philipp Klemm 
> > Cc: Laxminath Kasam 
> > Cc: Merlijn Wajer 
> > Cc: Mark Brown 
> > Cc: Pavel Machek 
> > Cc: Sebastian Reichel 
> > Cc: Tim Harvey 
>
> It would be nice to have you review this Tim.
>

Tony / Lee,

Thanks for keeping me in the loop on this. I still haven't properly
resolved the issue with my device/driver interrupts
(drivers/mfd/gateworks_gsc.c) which requires ack_invert (writing 0 to
clearing interrupt bits).

3a6f0fb7b8eb ("regmap: irq: Add support to clear ack registers")
appears to not only add the new clear_ack case it also attempts to
resolve the long standing ack_invert issue with this change:

- ret = regmap_write(map, reg, data->status_buf[i]);
+ if (chip->ack_invert)
+  ret = regmap_write(map, reg,
+  ~data->status_buf[i]);
+ else
+ ret = regmap_write(map, reg,
+ data->status_buf[i]);

However, this still doesn't resolve the issue I have with my
device/driver because it ends up writing 1's to all the other bits in
the ack register which keeps my device's interrupt from de-asserting.
Perhaps that's a strange behavior of my device that it allows you to
'set' interrupt source bits which causes the interrupt to stay
asserted? I'm also wondering if my issue is that I currently have the
interrupt registered as such:

ret = devm_regmap_add_irq_chip(dev, gsc->regmap, client->irq,
IRQF_ONESHOT | IRQF_SHARED | IRQF_TRIGGER_FALLING, 0, _irq_chip,
_data);

Perhaps this should be IRQF_TRIGGER_LOW as the device will not
de-assert its IRQ# until all source bits are cleared.

Tony, I thought that your pcap issue was that it truly did not have an
inverted ack and the fact that ack_invert did not work was why you
never noticed any issue. If this is true I would think you would want
to disable ack_invert but not necessarily enable clear_ack. Did your
testing show it needed to toggle the ack to clear it?

Best Regards,

Tim

Re: [PATCH v2 1/4] ARM: dts: imx6qdl-gw5xxx: correct interrupt flags

[Tim Harvey]

>  #include 
>  #include 
> +#include 
>
>  / {
> /* these are used by bootloader for disabling nodes */
> @@ -154,7 +155,7 @@
> compatible = "gw,gsc";
> reg = <0x20>;
> interrupt-parent = <>;
> -   interrupts = <4 GPIO_ACTIVE_LOW>;
> +   interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
> interrupt-controller;
> #interrupt-cells = <1>;
> #size-cells = <0>;
> diff --git a/arch/arm/boot/dts/imx6qdl-gw5910.dtsi 
> b/arch/arm/boot/dts/imx6qdl-gw5910.dtsi
> index 6c943a517ad7..ed4e22259959 100644
> --- a/arch/arm/boot/dts/imx6qdl-gw5910.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-gw5910.dtsi
> @@ -5,6 +5,7 @@
>
>  #include 
>  #include 
> +#include 
>
>  / {
> /* these are used by bootloader for disabling nodes */
> @@ -163,7 +164,7 @@
> compatible = "gw,gsc";
> reg = <0x20>;
> interrupt-parent = <>;
> -   interrupts = <4 GPIO_ACTIVE_LOW>;
> +   interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
> interrupt-controller;
> #interrupt-cells = <1>;
> #size-cells = <0>;
> diff --git a/arch/arm/boot/dts/imx6qdl-gw5912.dtsi 
> b/arch/arm/boot/dts/imx6qdl-gw5912.dtsi
> index 441d8ce97aa4..797f160249f7 100644
> --- a/arch/arm/boot/dts/imx6qdl-gw5912.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-gw5912.dtsi
> @@ -5,6 +5,7 @@
>
>  #include 
>  #include 
> +#include 
>
>  / {
> /* these are used by bootloader for disabling nodes */
> @@ -158,7 +159,7 @@
> compatible = "gw,gsc";
> reg = <0x20>;
> interrupt-parent = <>;
> -   interrupts = <4 GPIO_ACTIVE_LOW>;
> +   interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
> interrupt-controller;
> #interrupt-cells = <1>;
> #address-cells = <1>;
> diff --git a/arch/arm/boot/dts/imx6qdl-gw5913.dtsi 
> b/arch/arm/boot/dts/imx6qdl-gw5913.dtsi
> index d62a8da49367..4cd7d290f5b2 100644
> --- a/arch/arm/boot/dts/imx6qdl-gw5913.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-gw5913.dtsi
> @@ -5,6 +5,7 @@
>
>  #include 
>  #include 
> +#include 
>
>  / {
> /* these are used by bootloader for disabling nodes */
> @@ -139,7 +140,7 @@
> compatible = "gw,gsc";
> reg = <0x20>;
> interrupt-parent = <>;
> -   interrupts = <4 GPIO_ACTIVE_LOW>;
> +   interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
> interrupt-controller;
> #interrupt-cells = <1>;
> #size-cells = <0>;
> --
> 2.17.1
>

for series:
Acked-By: Tim Harvey 

Thanks Krzysztof

Tim


Tim

Re: [PATCH] dt-bindings: mfd: Correct interrupt flags in examples

[Tim Harvey]

On Tue, Sep 8, 2020 at 7:59 AM Krzysztof Kozlowski  wrote:
>
> GPIO_ACTIVE_x flags are not correct in the context of interrupt flags.
> These are simple defines so they could be used in DTS but they will not
> have the same meaning:
> 1. GPIO_ACTIVE_HIGH = 0 = IRQ_TYPE_NONE
> 2. GPIO_ACTIVE_LOW  = 1 = IRQ_TYPE_EDGE_RISING
>
> Correct the interrupt flags, assuming the author of the code wanted some
> logical behavior behind the name "ACTIVE_xxx", this is:
>   ACTIVE_LOW => IRQ_TYPE_LEVEL_LOW
>
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  Documentation/devicetree/bindings/mfd/act8945a.txt  | 2 +-
>  Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml| 3 ++-
>  Documentation/devicetree/bindings/mfd/rohm,bd70528-pmic.txt | 2 +-
>  3 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/mfd/act8945a.txt 
> b/Documentation/devicetree/bindings/mfd/act8945a.txt
> index e6f168db6c72..5ca75d888b4a 100644
> --- a/Documentation/devicetree/bindings/mfd/act8945a.txt
> +++ b/Documentation/devicetree/bindings/mfd/act8945a.txt
> @@ -71,7 +71,7 @@ Example:
> pinctrl-names = "default";
> pinctrl-0 = <_charger_chglev 
> _charger_lbo _charger_irq>;
> interrupt-parent = <>;
> -   interrupts = <45 GPIO_ACTIVE_LOW>;
> +   interrupts = <45 IRQ_TYPE_LEVEL_LOW>;
>
> active-semi,chglev-gpios = < 12 
> GPIO_ACTIVE_HIGH>;
> active-semi,lbo-gpios = < 72 GPIO_ACTIVE_LOW>;
> diff --git a/Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml 
> b/Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml
> index 9b6eb50606e8..e541eb0d02ed 100644
> --- a/Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml
> +++ b/Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml
> @@ -147,6 +147,7 @@ required:
>  examples:
>- |
>  #include 
> +#include 
>  i2c {
>  #address-cells = <1>;
>  #size-cells = <0>;
> @@ -155,7 +156,7 @@ examples:
>  compatible = "gw,gsc";
>  reg = <0x20>;
>  interrupt-parent = <>;
> -    interrupts = <4 GPIO_ACTIVE_LOW>;
> +interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
>  interrupt-controller;
>  #interrupt-cells = <1>;
>  #address-cells = <1>;

For gateworks-gsc.yaml:
Acked-By: Tim Harvey 

Thanks for finding this!

Tim

[PATCH v2] hwmon: gsc-hwmon: add fan sensor

[Tim Harvey]

Add a fan sensor to report RPM's from a fan tach input.

Signed-off-by: Tim Harvey 
--
v2:
 - avoid unnecessary line split and fix opening brace location
---
 drivers/hwmon/gsc-hwmon.c   | 32 +---
 include/linux/platform_data/gsc_hwmon.h |  1 +
 2 files changed, 30 insertions(+), 3 deletions(-)

diff --git a/drivers/hwmon/gsc-hwmon.c b/drivers/hwmon/gsc-hwmon.c
index c6d4567..1fe3741 100644
--- a/drivers/hwmon/gsc-hwmon.c
+++ b/drivers/hwmon/gsc-hwmon.c
@@ -17,6 +17,7 @@
 
 #define GSC_HWMON_MAX_TEMP_CH  16
 #define GSC_HWMON_MAX_IN_CH16
+#define GSC_HWMON_MAX_FAN_CH   16
 
 #define GSC_HWMON_RESOLUTION   12
 #define GSC_HWMON_VREF 2500
@@ -27,11 +28,14 @@ struct gsc_hwmon_data {
struct regmap *regmap;
const struct gsc_hwmon_channel *temp_ch[GSC_HWMON_MAX_TEMP_CH];
const struct gsc_hwmon_channel *in_ch[GSC_HWMON_MAX_IN_CH];
+   const struct gsc_hwmon_channel *fan_ch[GSC_HWMON_MAX_FAN_CH];
u32 temp_config[GSC_HWMON_MAX_TEMP_CH + 1];
u32 in_config[GSC_HWMON_MAX_IN_CH + 1];
+   u32 fan_config[GSC_HWMON_MAX_FAN_CH + 1];
struct hwmon_channel_info temp_info;
struct hwmon_channel_info in_info;
-   const struct hwmon_channel_info *info[3];
+   struct hwmon_channel_info fan_info;
+   const struct hwmon_channel_info *info[4];
struct hwmon_chip_info chip;
 };
 
@@ -155,6 +159,9 @@ gsc_hwmon_read(struct device *dev, enum hwmon_sensor_types 
type, u32 attr,
case hwmon_temp:
ch = hwmon->temp_ch[channel];
break;
+   case hwmon_fan:
+   ch = hwmon->fan_ch[channel];
+   break;
default:
return -EOPNOTSUPP;
}
@@ -187,6 +194,9 @@ gsc_hwmon_read(struct device *dev, enum hwmon_sensor_types 
type, u32 attr,
/* adjust by uV offset */
tmp += ch->mvoffset;
break;
+   case mode_fan:
+   tmp *= 30; /* convert to revolutions per minute */
+   break;
case mode_voltage_24bit:
case mode_voltage_16bit:
/* no adjustment needed */
@@ -211,6 +221,9 @@ gsc_hwmon_read_string(struct device *dev, enum 
hwmon_sensor_types type,
case hwmon_temp:
*buf = hwmon->temp_ch[channel]->name;
break;
+   case hwmon_fan:
+   *buf = hwmon->fan_ch[channel]->name;
+   break;
default:
return -ENOTSUPP;
}
@@ -304,7 +317,7 @@ static int gsc_hwmon_probe(struct platform_device *pdev)
struct gsc_hwmon_platform_data *pdata = dev_get_platdata(dev);
struct gsc_hwmon_data *hwmon;
const struct attribute_group **groups;
-   int i, i_in, i_temp;
+   int i, i_in, i_temp, i_fan;
 
if (!pdata) {
pdata = gsc_hwmon_get_devtree_pdata(dev);
@@ -324,7 +337,7 @@ static int gsc_hwmon_probe(struct platform_device *pdev)
if (IS_ERR(hwmon->regmap))
return PTR_ERR(hwmon->regmap);
 
-   for (i = 0, i_in = 0, i_temp = 0; i < hwmon->pdata->nchannels; i++) {
+   for (i = 0, i_in = 0, i_temp = 0, i_fan = 0; i < 
hwmon->pdata->nchannels; i++) {
const struct gsc_hwmon_channel *ch = >channels[i];
 
switch (ch->mode) {
@@ -338,6 +351,16 @@ static int gsc_hwmon_probe(struct platform_device *pdev)
 HWMON_T_LABEL;
i_temp++;
break;
+   case mode_fan:
+   if (i_fan == GSC_HWMON_MAX_FAN_CH) {
+   dev_err(gsc->dev, "too many fan channels\n");
+   return -EINVAL;
+   }
+   hwmon->fan_ch[i_fan] = ch;
+   hwmon->fan_config[i_fan] = HWMON_F_INPUT |
+  HWMON_F_LABEL;
+   i_fan++;
+   break;
case mode_voltage_24bit:
case mode_voltage_16bit:
case mode_voltage_raw:
@@ -361,10 +384,13 @@ static int gsc_hwmon_probe(struct platform_device *pdev)
hwmon->chip.info = hwmon->info;
hwmon->info[0] = >temp_info;
hwmon->info[1] = >in_info;
+   hwmon->info[2] = >fan_info;
hwmon->temp_info.type = hwmon_temp;
hwmon->temp_info.config = hwmon->temp_config;
hwmon->in_info.type = hwmon_in;
hwmon->in_info.config = hwmon->in_config;
+   hwmon->fan_info.type = hwmon_fan;
+   hwmon->fan_info.config = hwmon->fan_config;
 
groups = pdata->fan_base ? gsc_hwmon_groups : NULL;
hwmon_dev = devm_hwmon_device_register_with_info(dev,
diff --git a/include/linux/platform_data/gsc_hwmon.h 
b/include/linux

[PATCH] hwmon: gsc-hwmon: add fan sensor

[Tim Harvey]

Add a fan sensor to report RPM's from a fan tach input.

Signed-off-by: Tim Harvey 
---
 drivers/hwmon/gsc-hwmon.c   | 34 ++---
 include/linux/platform_data/gsc_hwmon.h |  1 +
 2 files changed, 32 insertions(+), 3 deletions(-)

diff --git a/drivers/hwmon/gsc-hwmon.c b/drivers/hwmon/gsc-hwmon.c
index c6d4567..a86a0e5 100644
--- a/drivers/hwmon/gsc-hwmon.c
+++ b/drivers/hwmon/gsc-hwmon.c
@@ -17,6 +17,7 @@
 
 #define GSC_HWMON_MAX_TEMP_CH  16
 #define GSC_HWMON_MAX_IN_CH16
+#define GSC_HWMON_MAX_FAN_CH   16
 
 #define GSC_HWMON_RESOLUTION   12
 #define GSC_HWMON_VREF 2500
@@ -27,11 +28,14 @@ struct gsc_hwmon_data {
struct regmap *regmap;
const struct gsc_hwmon_channel *temp_ch[GSC_HWMON_MAX_TEMP_CH];
const struct gsc_hwmon_channel *in_ch[GSC_HWMON_MAX_IN_CH];
+   const struct gsc_hwmon_channel *fan_ch[GSC_HWMON_MAX_FAN_CH];
u32 temp_config[GSC_HWMON_MAX_TEMP_CH + 1];
u32 in_config[GSC_HWMON_MAX_IN_CH + 1];
+   u32 fan_config[GSC_HWMON_MAX_FAN_CH + 1];
struct hwmon_channel_info temp_info;
struct hwmon_channel_info in_info;
-   const struct hwmon_channel_info *info[3];
+   struct hwmon_channel_info fan_info;
+   const struct hwmon_channel_info *info[4];
struct hwmon_chip_info chip;
 };
 
@@ -155,6 +159,9 @@ gsc_hwmon_read(struct device *dev, enum hwmon_sensor_types 
type, u32 attr,
case hwmon_temp:
ch = hwmon->temp_ch[channel];
break;
+   case hwmon_fan:
+   ch = hwmon->fan_ch[channel];
+   break;
default:
return -EOPNOTSUPP;
}
@@ -187,6 +194,9 @@ gsc_hwmon_read(struct device *dev, enum hwmon_sensor_types 
type, u32 attr,
/* adjust by uV offset */
tmp += ch->mvoffset;
break;
+   case mode_fan:
+   tmp *= 30; /* convert to revolutions per minute */
+   break;
case mode_voltage_24bit:
case mode_voltage_16bit:
/* no adjustment needed */
@@ -211,6 +221,9 @@ gsc_hwmon_read_string(struct device *dev, enum 
hwmon_sensor_types type,
case hwmon_temp:
*buf = hwmon->temp_ch[channel]->name;
break;
+   case hwmon_fan:
+   *buf = hwmon->fan_ch[channel]->name;
+   break;
default:
return -ENOTSUPP;
}
@@ -304,7 +317,7 @@ static int gsc_hwmon_probe(struct platform_device *pdev)
struct gsc_hwmon_platform_data *pdata = dev_get_platdata(dev);
struct gsc_hwmon_data *hwmon;
const struct attribute_group **groups;
-   int i, i_in, i_temp;
+   int i, i_in, i_temp, i_fan;
 
if (!pdata) {
pdata = gsc_hwmon_get_devtree_pdata(dev);
@@ -324,7 +337,9 @@ static int gsc_hwmon_probe(struct platform_device *pdev)
if (IS_ERR(hwmon->regmap))
return PTR_ERR(hwmon->regmap);
 
-   for (i = 0, i_in = 0, i_temp = 0; i < hwmon->pdata->nchannels; i++) {
+   for (i = 0, i_in = 0, i_temp = 0, i_fan = 0;
+i < hwmon->pdata->nchannels; i++)
+   {
const struct gsc_hwmon_channel *ch = >channels[i];
 
switch (ch->mode) {
@@ -338,6 +353,16 @@ static int gsc_hwmon_probe(struct platform_device *pdev)
 HWMON_T_LABEL;
i_temp++;
break;
+   case mode_fan:
+   if (i_fan == GSC_HWMON_MAX_FAN_CH) {
+   dev_err(gsc->dev, "too many fan channels\n");
+   return -EINVAL;
+   }
+   hwmon->fan_ch[i_fan] = ch;
+   hwmon->fan_config[i_fan] = HWMON_F_INPUT |
+  HWMON_F_LABEL;
+   i_fan++;
+   break;
case mode_voltage_24bit:
case mode_voltage_16bit:
case mode_voltage_raw:
@@ -361,10 +386,13 @@ static int gsc_hwmon_probe(struct platform_device *pdev)
hwmon->chip.info = hwmon->info;
hwmon->info[0] = >temp_info;
hwmon->info[1] = >in_info;
+   hwmon->info[2] = >fan_info;
hwmon->temp_info.type = hwmon_temp;
hwmon->temp_info.config = hwmon->temp_config;
hwmon->in_info.type = hwmon_in;
hwmon->in_info.config = hwmon->in_config;
+   hwmon->fan_info.type = hwmon_fan;
+   hwmon->fan_info.config = hwmon->fan_config;
 
groups = pdata->fan_base ? gsc_hwmon_groups : NULL;
hwmon_dev = devm_hwmon_device_register_with_info(dev,
diff --git a/include/linux/platform_data/gsc_hwmon.h 
b/include/linux/platform_data/gsc_hwmon.h
index 37a8f554d..281

[PATCH] hwmon: gsc-hwmon: scale temperature to millidegrees

[Tim Harvey]

The GSC registers report temperature in decidegrees celcius so we
need to scale it to represent the hwmon sysfs API of millidegrees.

Cc: sta...@vger.kernel.org
Signed-off-by: Tim Harvey 
---
 drivers/hwmon/gsc-hwmon.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/hwmon/gsc-hwmon.c b/drivers/hwmon/gsc-hwmon.c
index 3dfe2ca..c6d4567 100644
--- a/drivers/hwmon/gsc-hwmon.c
+++ b/drivers/hwmon/gsc-hwmon.c
@@ -172,6 +172,7 @@ gsc_hwmon_read(struct device *dev, enum hwmon_sensor_types 
type, u32 attr,
case mode_temperature:
if (tmp > 0x8000)
tmp -= 0x;
+   tmp *= 100; /* convert to millidegrees celsius */
break;
case mode_voltage_raw:
tmp = clamp_val(tmp, 0, BIT(GSC_HWMON_RESOLUTION));
-- 
2.7.4

[RESEND PATCH] can: mcp251x: add support for half duplex controllers

[Tim Harvey]

Some SPI host controllers do not support full-duplex SPI and are
marked as such via the SPI_CONTROLLER_HALF_DUPLEX controller flag.

For such controllers use half duplex transactions but retain full
duplex transactions for the controllers that can handle those.

Signed-off-by: Tim Harvey 
---
 drivers/net/can/spi/mcp251x.c | 34 +++---
 1 file changed, 27 insertions(+), 7 deletions(-)

diff --git a/drivers/net/can/spi/mcp251x.c b/drivers/net/can/spi/mcp251x.c
index 5009ff2..203ef20 100644
--- a/drivers/net/can/spi/mcp251x.c
+++ b/drivers/net/can/spi/mcp251x.c
@@ -290,8 +290,12 @@ static u8 mcp251x_read_reg(struct spi_device *spi, u8 reg)
priv->spi_tx_buf[0] = INSTRUCTION_READ;
priv->spi_tx_buf[1] = reg;
 
-   mcp251x_spi_trans(spi, 3);
-   val = priv->spi_rx_buf[2];
+   if (spi->controller->flags & SPI_CONTROLLER_HALF_DUPLEX) {
+   spi_write_then_read(spi, priv->spi_tx_buf, 2, , 1);
+   } else {
+   mcp251x_spi_trans(spi, 3);
+   val = priv->spi_rx_buf[2];
+   }
 
return val;
 }
@@ -303,10 +307,18 @@ static void mcp251x_read_2regs(struct spi_device *spi, u8 
reg, u8 *v1, u8 *v2)
priv->spi_tx_buf[0] = INSTRUCTION_READ;
priv->spi_tx_buf[1] = reg;
 
-   mcp251x_spi_trans(spi, 4);
+   if (spi->controller->flags & SPI_CONTROLLER_HALF_DUPLEX) {
+   u8 val[2] = { 0 };
 
-   *v1 = priv->spi_rx_buf[2];
-   *v2 = priv->spi_rx_buf[3];
+   spi_write_then_read(spi, priv->spi_tx_buf, 2, val, 2);
+   *v1 = val[0];
+   *v2 = val[1];
+   } else {
+   mcp251x_spi_trans(spi, 4);
+
+   *v1 = priv->spi_rx_buf[2];
+   *v2 = priv->spi_rx_buf[3];
+   }
 }
 
 static void mcp251x_write_reg(struct spi_device *spi, u8 reg, u8 val)
@@ -409,8 +421,16 @@ static void mcp251x_hw_rx_frame(struct spi_device *spi, u8 
*buf,
buf[i] = mcp251x_read_reg(spi, RXBCTRL(buf_idx) + i);
} else {
priv->spi_tx_buf[RXBCTRL_OFF] = INSTRUCTION_READ_RXB(buf_idx);
-   mcp251x_spi_trans(spi, SPI_TRANSFER_BUF_LEN);
-   memcpy(buf, priv->spi_rx_buf, SPI_TRANSFER_BUF_LEN);
+   if (spi->controller->flags & SPI_CONTROLLER_HALF_DUPLEX) {
+   spi_write_then_read(spi, priv->spi_tx_buf, 1,
+   priv->spi_rx_buf,
+   SPI_TRANSFER_BUF_LEN);
+   memcpy(buf + 1, priv->spi_rx_buf,
+  SPI_TRANSFER_BUF_LEN - 1);
+   } else {
+   mcp251x_spi_trans(spi, SPI_TRANSFER_BUF_LEN);
+   memcpy(buf, priv->spi_rx_buf, SPI_TRANSFER_BUF_LEN);
+   }
}
 }
 
-- 
2.7.4

[PATCH v4] ARM: dts: imx6qdl-gw: add Gateworks System Controller support

[Tim Harvey]

Add Gateworks System Controller support to Gateworks Ventana boards:
- add dt bindings for GSC mfd driver and hwmon driver for ADC's and
  fan controllers.
- add dt bindings for gpio-keys driver for push-button and interrupt events

Signed-off-by: Tim Harvey 
---
v4:
 - add missing #address-cells to gw5912 gsc node to address dtc warning

v3:
 - change underscore to hyphen in node names
 - use generic node name for gsc_gpio nodes

v2:
 - use keycode bindings from linux-event-codes.h
 - fix gw5910 vdd_bat adc mode
 - fix gw5913 vdd_bat adc mode
---
 arch/arm/boot/dts/imx6qdl-gw51xx.dtsi | 153 +--
 arch/arm/boot/dts/imx6qdl-gw52xx.dtsi | 159 ++--
 arch/arm/boot/dts/imx6qdl-gw53xx.dtsi | 165 +++--
 arch/arm/boot/dts/imx6qdl-gw54xx.dtsi | 167 --
 arch/arm/boot/dts/imx6qdl-gw551x.dtsi | 147 --
 arch/arm/boot/dts/imx6qdl-gw552x.dtsi | 153 +--
 arch/arm/boot/dts/imx6qdl-gw553x.dtsi | 141 +++-
 arch/arm/boot/dts/imx6qdl-gw560x.dtsi | 164 +++--
 arch/arm/boot/dts/imx6qdl-gw5903.dtsi | 140 +++-
 arch/arm/boot/dts/imx6qdl-gw5904.dtsi | 141 +++-
 arch/arm/boot/dts/imx6qdl-gw5907.dtsi | 142 -
 arch/arm/boot/dts/imx6qdl-gw5910.dtsi | 160 +++-
 arch/arm/boot/dts/imx6qdl-gw5912.dtsi | 148 +-
 arch/arm/boot/dts/imx6qdl-gw5913.dtsi | 153 ++-
 14 files changed, 2076 insertions(+), 57 deletions(-)

diff --git a/arch/arm/boot/dts/imx6qdl-gw51xx.dtsi 
b/arch/arm/boot/dts/imx6qdl-gw51xx.dtsi
index 419a7cd..7705285 100644
--- a/arch/arm/boot/dts/imx6qdl-gw51xx.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw51xx.dtsi
@@ -4,6 +4,7 @@
  */
 
 #include 
+#include 
 
 / {
/* these are used by bootloader for disabling nodes */
@@ -19,6 +20,53 @@
bootargs = "console=ttymxc1,115200";
};
 
+   gpio-keys {
+   compatible = "gpio-keys";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   user-pb {
+   label = "user_pb";
+   gpios = <_gpio 0 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   };
+
+   user-pb1x {
+   label = "user_pb1x";
+   linux,code = ;
+   interrupt-parent = <>;
+   interrupts = <0>;
+   };
+
+   key-erased {
+   label = "key-erased";
+   linux,code = ;
+   interrupt-parent = <>;
+   interrupts = <1>;
+   };
+
+   eeprom-wp {
+   label = "eeprom_wp";
+   linux,code = ;
+   interrupt-parent = <>;
+   interrupts = <2>;
+   };
+
+   tamper {
+   label = "tamper";
+   linux,code = ;
+   interrupt-parent = <>;
+   interrupts = <5>;
+   };
+
+   switch-hold {
+   label = "switch_hold";
+   linux,code = ;
+   interrupt-parent = <>;
+   interrupts = <7>;
+   };
+   };
+
leds {
compatible = "gpio-leds";
pinctrl-names = "default";
@@ -102,6 +150,103 @@
pinctrl-0 = <_i2c1>;
status = "okay";
 
+   gsc: gsc@20 {
+   compatible = "gw,gsc";
+   reg = <0x20>;
+   interrupt-parent = <>;
+   interrupts = <4 GPIO_ACTIVE_LOW>;
+   interrupt-controller;
+   #interrupt-cells = <1>;
+   #size-cells = <0>;
+
+   adc {
+   compatible = "gw,gsc-adc";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   channel@0 {
+   gw,mode = <0>;
+   reg = <0x00>;
+   label = "temp";
+   };
+
+   channel@2 {
+   gw,mode = <1>;
+   reg = <0x02>;
+   label = "vdd_vin";
+   };
+
+   channel@5 {
+   gw,mode = <1>

Re: [PATCH] can: mcp251x: add support for half duplex controllers

[Tim Harvey]

On Thu, May 28, 2020 at 8:28 AM Tim Harvey  wrote:
>
> Some SPI host controllers do not support full-duplex SPI and are
> marked as such via the SPI_CONTROLLER_HALF_DUPLEX controller flag.
>
> For such controllers use half duplex transactions but retain full
> duplex transactions for the controllers that can handle those.
>
> Signed-off-by: Tim Harvey 
> ---
>  drivers/net/can/spi/mcp251x.c | 34 +++---
>  1 file changed, 27 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/can/spi/mcp251x.c b/drivers/net/can/spi/mcp251x.c
> index 5009ff2..203ef20 100644
> --- a/drivers/net/can/spi/mcp251x.c
> +++ b/drivers/net/can/spi/mcp251x.c
> @@ -290,8 +290,12 @@ static u8 mcp251x_read_reg(struct spi_device *spi, u8 
> reg)
> priv->spi_tx_buf[0] = INSTRUCTION_READ;
> priv->spi_tx_buf[1] = reg;
>
> -   mcp251x_spi_trans(spi, 3);
> -   val = priv->spi_rx_buf[2];
> +   if (spi->controller->flags & SPI_CONTROLLER_HALF_DUPLEX) {
> +   spi_write_then_read(spi, priv->spi_tx_buf, 2, , 1);
> +   } else {
> +   mcp251x_spi_trans(spi, 3);
> +   val = priv->spi_rx_buf[2];
> +   }
>
> return val;
>  }
> @@ -303,10 +307,18 @@ static void mcp251x_read_2regs(struct spi_device *spi, 
> u8 reg, u8 *v1, u8 *v2)
> priv->spi_tx_buf[0] = INSTRUCTION_READ;
> priv->spi_tx_buf[1] = reg;
>
> -   mcp251x_spi_trans(spi, 4);
> +   if (spi->controller->flags & SPI_CONTROLLER_HALF_DUPLEX) {
> +   u8 val[2] = { 0 };
>
> -   *v1 = priv->spi_rx_buf[2];
> -   *v2 = priv->spi_rx_buf[3];
> +   spi_write_then_read(spi, priv->spi_tx_buf, 2, val, 2);
> +   *v1 = val[0];
> +   *v2 = val[1];
> +   } else {
> +   mcp251x_spi_trans(spi, 4);
> +
> +   *v1 = priv->spi_rx_buf[2];
> +   *v2 = priv->spi_rx_buf[3];
> +   }
>  }
>
>  static void mcp251x_write_reg(struct spi_device *spi, u8 reg, u8 val)
> @@ -409,8 +421,16 @@ static void mcp251x_hw_rx_frame(struct spi_device *spi, 
> u8 *buf,
> buf[i] = mcp251x_read_reg(spi, RXBCTRL(buf_idx) + i);
> } else {
> priv->spi_tx_buf[RXBCTRL_OFF] = INSTRUCTION_READ_RXB(buf_idx);
> -   mcp251x_spi_trans(spi, SPI_TRANSFER_BUF_LEN);
> -   memcpy(buf, priv->spi_rx_buf, SPI_TRANSFER_BUF_LEN);
> +   if (spi->controller->flags & SPI_CONTROLLER_HALF_DUPLEX) {
> +   spi_write_then_read(spi, priv->spi_tx_buf, 1,
> +   priv->spi_rx_buf,
> +   SPI_TRANSFER_BUF_LEN);
> +   memcpy(buf + 1, priv->spi_rx_buf,
> +  SPI_TRANSFER_BUF_LEN - 1);
> +   } else {
> +   mcp251x_spi_trans(spi, SPI_TRANSFER_BUF_LEN);
> +   memcpy(buf, priv->spi_rx_buf, SPI_TRANSFER_BUF_LEN);
> +   }
> }
>  }
>
> --
> 2.7.4
>

Marc / Wolfgang,

Any feedback on this?

Best Regards,

Tim

Re: linux-next: build warnings after merge of the imx-mxs tree

[Tim Harvey]

On Tue, Jun 23, 2020 at 4:50 PM Stephen Rothwell  wrote:
>
> Hi all,
>
> After merging the imx-mxs tree, today's linux-next build (arm
> multi_v7_defconfig) produced these warnings:
>
> arch/arm/boot/dts/imx6qdl-gw53xx.dtsi:350.4-27: Warning (reg_format): 
> /soc/pcie@1ffc000/pcie@0,0,0/pcie@1,0,0:reg: property has invalid length (20 
> bytes) (#address-cells == 2, #size-cells == 1)
> arch/arm/boot/dts/imx6qdl-gw53xx.dtsi:353.5-28: Warning (reg_format): 
> /soc/pcie@1ffc000/pcie@0,0,0/pcie@1,0,0/pcie@2,4,0:reg: property has invalid 
> length (20 bytes) (#address-cells == 2, #size-cells == 1)
> arch/arm/boot/dts/imx6qdl-gw53xx.dtsi:356.6-29: Warning (reg_format): 
> /soc/pcie@1ffc000/pcie@0,0,0/pcie@1,0,0/pcie@2,4,0/pcie@4,0,0:reg: property 
> has invalid length (20 bytes) (#address-cells == 2, #size-cells == 1)
> arch/arm/boot/dts/imx6dl-gw53xx.dtb: Warning (pci_device_bus_num): Failed 
> prerequisite 'reg_format'
> arch/arm/boot/dts/imx6dl-gw53xx.dtb: Warning (i2c_bus_reg): Failed 
> prerequisite 'reg_format'
> arch/arm/boot/dts/imx6dl-gw53xx.dtb: Warning (spi_bus_reg): Failed 
> prerequisite 'reg_format'
> arch/arm/boot/dts/imx6qdl-gw53xx.dtsi:349.14-360.5: Warning 
> (avoid_default_addr_size): /soc/pcie@1ffc000/pcie@0,0,0/pcie@1,0,0: Relying 
> on default #address-cells value
> arch/arm/boot/dts/imx6qdl-gw53xx.dtsi:349.14-360.5: Warning 
> (avoid_default_addr_size): /soc/pcie@1ffc000/pcie@0,0,0/pcie@1,0,0: Relying 
> on default #size-cells value
> arch/arm/boot/dts/imx6qdl-gw53xx.dtsi:352.15-359.6: Warning 
> (avoid_default_addr_size): 
> /soc/pcie@1ffc000/pcie@0,0,0/pcie@1,0,0/pcie@2,4,0: Relying on default 
> #address-cells value
> arch/arm/boot/dts/imx6qdl-gw53xx.dtsi:352.15-359.6: Warning 
> (avoid_default_addr_size): 
> /soc/pcie@1ffc000/pcie@0,0,0/pcie@1,0,0/pcie@2,4,0: Relying on default 
> #size-cells value
> arch/arm/boot/dts/imx6qdl-gw53xx.dtsi:355.22-358.7: Warning 
> (avoid_default_addr_size): 
> /soc/pcie@1ffc000/pcie@0,0,0/pcie@1,0,0/pcie@2,4,0/pcie@4,0,0: Relying on 
> default #address-cells value
> arch/arm/boot/dts/imx6qdl-gw53xx.dtsi:355.22-358.7: Warning 
> (avoid_default_addr_size): 
> /soc/pcie@1ffc000/pcie@0,0,0/pcie@1,0,0/pcie@2,4,0/pcie@4,0,0: Relying on 
> default #size-cells value
> arch/arm/boot/dts/imx6qdl-gw54xx.dtsi:407.4-27: Warning (reg_format): 
> /soc/pcie@1ffc000/pcie@0,0,0/pcie@1,0,0:reg: property has invalid length (20 
> bytes) (#address-cells == 2, #size-cells == 1)
> arch/arm/boot/dts/imx6qdl-gw54xx.dtsi:410.5-28: Warning (reg_format): 
> /soc/pcie@1ffc000/pcie@0,0,0/pcie@1,0,0/pcie@2,8,0:reg: property has invalid 
> length (20 bytes) (#address-cells == 2, #size-cells == 1)
> arch/arm/boot/dts/imx6qdl-gw54xx.dtsi:413.6-29: Warning (reg_format): 
> /soc/pcie@1ffc000/pcie@0,0,0/pcie@1,0,0/pcie@2,8,0/pcie@8,0,0:reg: property 
> has invalid length (20 bytes) (#address-cells == 2, #size-cells == 1)
> arch/arm/boot/dts/imx6dl-gw54xx.dtb: Warning (pci_device_bus_num): Failed 
> prerequisite 'reg_format'
> arch/arm/boot/dts/imx6dl-gw54xx.dtb: Warning (i2c_bus_reg): Failed 
> prerequisite 'reg_format'
> arch/arm/boot/dts/imx6dl-gw54xx.dtb: Warning (spi_bus_reg): Failed 
> prerequisite 'reg_format'
> arch/arm/boot/dts/imx6qdl-gw54xx.dtsi:406.14-417.5: Warning 
> (avoid_default_addr_size): /soc/pcie@1ffc000/pcie@0,0,0/pcie@1,0,0: Relying 
> on default #address-cells value
> arch/arm/boot/dts/imx6qdl-gw54xx.dtsi:406.14-417.5: Warning 
> (avoid_default_addr_size): /soc/pcie@1ffc000/pcie@0,0,0/pcie@1,0,0: Relying 
> on default #size-cells value
> arch/arm/boot/dts/imx6qdl-gw54xx.dtsi:409.15-416.6: Warning 
> (avoid_default_addr_size): 
> /soc/pcie@1ffc000/pcie@0,0,0/pcie@1,0,0/pcie@2,8,0: Relying on default 
> #address-cells value
> arch/arm/boot/dts/imx6qdl-gw54xx.dtsi:409.15-416.6: Warning 
> (avoid_default_addr_size): 
> /soc/pcie@1ffc000/pcie@0,0,0/pcie@1,0,0/pcie@2,8,0: Relying on default 
> #size-cells value
> arch/arm/boot/dts/imx6qdl-gw54xx.dtsi:412.22-415.7: Warning 
> (avoid_default_addr_size): 
> /soc/pcie@1ffc000/pcie@0,0,0/pcie@1,0,0/pcie@2,8,0/pcie@8,0,0: Relying on 
> default #address-cells value
> arch/arm/boot/dts/imx6qdl-gw54xx.dtsi:412.22-415.7: Warning 
> (avoid_default_addr_size): 
> /soc/pcie@1ffc000/pcie@0,0,0/pcie@1,0,0/pcie@2,8,0/pcie@8,0,0: Relying on 
> default #size-cells value
> arch/arm/boot/dts/imx6qdl-gw53xx.dtsi:350.4-27: Warning (reg_format): 
> /soc/pcie@1ffc000/pcie@0,0,0/pcie@1,0,0:reg: property has invalid length (20 
> bytes) (#address-cells == 2, #size-cells == 1)
> arch/arm/boot/dts/imx6qdl-gw53xx.dtsi:353.5-28: Warning (reg_format): 
> /soc/pcie@1ffc000/pcie@0,0,0/pcie@1,0,0/pcie@2,4,0:reg: property has invalid 
> length (20 bytes) (#address-cells == 2, #size-cells == 1)
> arch/arm/boot/dts/imx6qdl-gw53xx.dtsi:356.6-29: Warning (reg_format): 
> /soc/pcie@1ffc000/pcie@0,0,0/pcie@1,0,0/pcie@2,4,0/pcie@4,0,0:reg: property 
> has invalid length (20 bytes) (#address-cells == 2, #size-cells == 1)
> arch/arm/boot/dts/imx6q-gw53xx.dtb: Warning 

[PATCH v3] ARM: dts: imx6qdl-gw551x: fix audio SSI

[Tim Harvey]

The audio codec on the GW551x routes to ssi1

Cc: sta...@vger.kernel.org
Fixes: 3117e851cef1 ("ARM: dts: imx: Add TDA19971 HDMI Receiver to GW551x")
Signed-off-by: Tim Harvey 
---
v3: add fixes tag
v2: fix typo in commit short desc
---
 arch/arm/boot/dts/imx6qdl-gw551x.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/imx6qdl-gw551x.dtsi 
b/arch/arm/boot/dts/imx6qdl-gw551x.dtsi
index c38e86e..8c33510 100644
--- a/arch/arm/boot/dts/imx6qdl-gw551x.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw551x.dtsi
@@ -110,7 +110,7 @@
simple-audio-card,frame-master = <_codec>;
 
sound_cpu: simple-audio-card,cpu {
-   sound-dai = <>;
+   sound-dai = <>;
};
 
sound_codec: simple-audio-card,codec {
-- 
2.7.4

Re: [RESEND PATCH v2] ARM: dts: imx6qdl-gw551x: fix audio SSI

[Tim Harvey]

On Tue, Jun 23, 2020 at 11:41 AM Fabio Estevam  wrote:
>
> Hi Tim,
>
> On Tue, Jun 23, 2020 at 3:31 PM Tim Harvey  wrote:
> >
> > The audio codec on the GW551x routes to ssi1
> >
> > Signed-off-by: Tim Harvey 
>
> Shouldn't this have a Fixes tag, so that it could be backported to
> older stable kernels?

Fabio,

Yes, it likely should as it fixes audio capture from 3117e851cef1b4e1.
I didn't think it would apply cleanly to stable but it looks like it
does.

I cc'd sta...@vger.kernel.org. Should I submit a new revision with the
following?

Cc: sta...@vger.kernel.org
Fixes: 3117e851cef1b4e1 ("ARM: dts: imx: Add TDA19971 HDMI Receiver to GW551x")

Thanks,

Tim

[PATCH v3] ARM: dts: imx6qdl-gw: add Gateworks System Controller support

[Tim Harvey]

Add Gateworks System Controller support to Gateworks Ventana boards:
- add dt bindings for GSC mfd driver and hwmon driver for ADC's and
  fan controllers.
- add dt bindings for gpio-keys driver for push-button and interrupt events

Signed-off-by: Tim Harvey 
---
v3:
 - change underscore to hyphen in node names
 - use generic node name for gsc_gpio nodes

v2:
 - use keycode bindings from linux-event-codes.h
 - fix gw5910 vdd_bat adc mode
 - fix gw5913 vdd_bat adc mode
---
 arch/arm/boot/dts/imx6qdl-gw51xx.dtsi | 153 +--
 arch/arm/boot/dts/imx6qdl-gw52xx.dtsi | 159 ++--
 arch/arm/boot/dts/imx6qdl-gw53xx.dtsi | 165 +++--
 arch/arm/boot/dts/imx6qdl-gw54xx.dtsi | 167 --
 arch/arm/boot/dts/imx6qdl-gw551x.dtsi | 147 --
 arch/arm/boot/dts/imx6qdl-gw552x.dtsi | 153 +--
 arch/arm/boot/dts/imx6qdl-gw553x.dtsi | 141 +++-
 arch/arm/boot/dts/imx6qdl-gw560x.dtsi | 164 +++--
 arch/arm/boot/dts/imx6qdl-gw5903.dtsi | 140 +++-
 arch/arm/boot/dts/imx6qdl-gw5904.dtsi | 141 +++-
 arch/arm/boot/dts/imx6qdl-gw5907.dtsi | 142 -
 arch/arm/boot/dts/imx6qdl-gw5910.dtsi | 160 +++-
 arch/arm/boot/dts/imx6qdl-gw5912.dtsi | 147 +-
 arch/arm/boot/dts/imx6qdl-gw5913.dtsi | 153 ++-
 14 files changed, 2075 insertions(+), 57 deletions(-)

diff --git a/arch/arm/boot/dts/imx6qdl-gw51xx.dtsi 
b/arch/arm/boot/dts/imx6qdl-gw51xx.dtsi
index 419a7cd..7705285 100644
--- a/arch/arm/boot/dts/imx6qdl-gw51xx.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw51xx.dtsi
@@ -4,6 +4,7 @@
  */
 
 #include 
+#include 
 
 / {
/* these are used by bootloader for disabling nodes */
@@ -19,6 +20,53 @@
bootargs = "console=ttymxc1,115200";
};
 
+   gpio-keys {
+   compatible = "gpio-keys";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   user-pb {
+   label = "user_pb";
+   gpios = <_gpio 0 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   };
+
+   user-pb1x {
+   label = "user_pb1x";
+   linux,code = ;
+   interrupt-parent = <>;
+   interrupts = <0>;
+   };
+
+   key-erased {
+   label = "key-erased";
+   linux,code = ;
+   interrupt-parent = <>;
+   interrupts = <1>;
+   };
+
+   eeprom-wp {
+   label = "eeprom_wp";
+   linux,code = ;
+   interrupt-parent = <>;
+   interrupts = <2>;
+   };
+
+   tamper {
+   label = "tamper";
+   linux,code = ;
+   interrupt-parent = <>;
+   interrupts = <5>;
+   };
+
+   switch-hold {
+   label = "switch_hold";
+   linux,code = ;
+   interrupt-parent = <>;
+   interrupts = <7>;
+   };
+   };
+
leds {
compatible = "gpio-leds";
pinctrl-names = "default";
@@ -102,6 +150,103 @@
pinctrl-0 = <_i2c1>;
status = "okay";
 
+   gsc: gsc@20 {
+   compatible = "gw,gsc";
+   reg = <0x20>;
+   interrupt-parent = <>;
+   interrupts = <4 GPIO_ACTIVE_LOW>;
+   interrupt-controller;
+   #interrupt-cells = <1>;
+   #size-cells = <0>;
+
+   adc {
+   compatible = "gw,gsc-adc";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   channel@0 {
+   gw,mode = <0>;
+   reg = <0x00>;
+   label = "temp";
+   };
+
+   channel@2 {
+   gw,mode = <1>;
+   reg = <0x02>;
+   label = "vdd_vin";
+   };
+
+   channel@5 {
+   gw,mode = <1>;
+   reg = <0x05>;
+ 

[RESEND PATCH v2] ARM: dts: imx6qdl-gw551x: fix audio SSI

[Tim Harvey]

The audio codec on the GW551x routes to ssi1

Signed-off-by: Tim Harvey 
---
v2: fix typo in commit short desc
---
 arch/arm/boot/dts/imx6qdl-gw551x.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/imx6qdl-gw551x.dtsi 
b/arch/arm/boot/dts/imx6qdl-gw551x.dtsi
index c38e86e..8c33510 100644
--- a/arch/arm/boot/dts/imx6qdl-gw551x.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw551x.dtsi
@@ -110,7 +110,7 @@
simple-audio-card,frame-master = <_codec>;
 
sound_cpu: simple-audio-card,cpu {
-   sound-dai = <>;
+   sound-dai = <>;
};
 
sound_codec: simple-audio-card,codec {
-- 
2.7.4

[PATCH v2] ARM: dts: imx6qdl-gw: add Gateworks System Controller support

[Tim Harvey]

Add Gateworks System Controller support to Gateworks Ventana boards:
- add dt bindings for GSC mfd driver and hwmon driver for ADC's and
  fan controllers.
- add dt bindings for gpio-keys driver for push-button and interrupt events

Signed-off-by: Tim Harvey 
---
v2:
 - use keycode bindings from linux-event-codes.h
 - fix gw5910/gw5913 vdd_bat ADC mode (these boards use 16bit pre-scaled ADC)

---
 arch/arm/boot/dts/imx6qdl-gw51xx.dtsi | 153 +--
 arch/arm/boot/dts/imx6qdl-gw52xx.dtsi | 159 ++--
 arch/arm/boot/dts/imx6qdl-gw53xx.dtsi | 165 +++--
 arch/arm/boot/dts/imx6qdl-gw54xx.dtsi | 167 --
 arch/arm/boot/dts/imx6qdl-gw551x.dtsi | 147 --
 arch/arm/boot/dts/imx6qdl-gw552x.dtsi | 153 +--
 arch/arm/boot/dts/imx6qdl-gw553x.dtsi | 141 +++-
 arch/arm/boot/dts/imx6qdl-gw560x.dtsi | 164 +++--
 arch/arm/boot/dts/imx6qdl-gw5903.dtsi | 140 +++-
 arch/arm/boot/dts/imx6qdl-gw5904.dtsi | 141 +++-
 arch/arm/boot/dts/imx6qdl-gw5907.dtsi | 142 -
 arch/arm/boot/dts/imx6qdl-gw5910.dtsi | 160 +++-
 arch/arm/boot/dts/imx6qdl-gw5912.dtsi | 147 +-
 arch/arm/boot/dts/imx6qdl-gw5913.dtsi | 153 ++-
 14 files changed, 2075 insertions(+), 57 deletions(-)

diff --git a/arch/arm/boot/dts/imx6qdl-gw51xx.dtsi 
b/arch/arm/boot/dts/imx6qdl-gw51xx.dtsi
index 419a7cd..712458d 100644
--- a/arch/arm/boot/dts/imx6qdl-gw51xx.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw51xx.dtsi
@@ -4,6 +4,7 @@
  */
 
 #include 
+#include 
 
 / {
/* these are used by bootloader for disabling nodes */
@@ -19,6 +20,53 @@
bootargs = "console=ttymxc1,115200";
};
 
+   gpio_keys {
+   compatible = "gpio-keys";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   user_pb {
+   label = "user_pb";
+   gpios = <_gpio 0 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   };
+
+   user_pb1x {
+   label = "user_pb1x";
+   linux,code = ;
+   interrupt-parent = <>;
+   interrupts = <0>;
+   };
+
+   key_erased {
+   label = "key-erased";
+   linux,code = ;
+   interrupt-parent = <>;
+   interrupts = <1>;
+   };
+
+   eeprom_wp {
+   label = "eeprom_wp";
+   linux,code = ;
+   interrupt-parent = <>;
+   interrupts = <2>;
+   };
+
+   tamper {
+   label = "tamper";
+   linux,code = ;
+   interrupt-parent = <>;
+   interrupts = <5>;
+   };
+
+   switch_hold {
+   label = "switch_hold";
+   linux,code = ;
+   interrupt-parent = <>;
+   interrupts = <7>;
+   };
+   };
+
leds {
compatible = "gpio-leds";
pinctrl-names = "default";
@@ -102,6 +150,103 @@
pinctrl-0 = <_i2c1>;
status = "okay";
 
+   gsc: gsc@20 {
+   compatible = "gw,gsc";
+   reg = <0x20>;
+   interrupt-parent = <>;
+   interrupts = <4 GPIO_ACTIVE_LOW>;
+   interrupt-controller;
+   #interrupt-cells = <1>;
+   #size-cells = <0>;
+
+   adc {
+   compatible = "gw,gsc-adc";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   channel@0 {
+   gw,mode = <0>;
+   reg = <0x00>;
+   label = "temp";
+   };
+
+   channel@2 {
+   gw,mode = <1>;
+   reg = <0x02>;
+   label = "vdd_vin";
+   };
+
+   channel@5 {
+   gw,mode = <1>;
+   reg = <0x05>;
+   label = "vdd_3p3";
+   };
+
+

[PATCH] lan743x: allow mac address to come from dt

[Tim Harvey]

If a valid mac address is present in dt, use that before using
CSR's or a random mac address.

Signed-off-by: Tim Harvey 
---
 drivers/net/ethernet/microchip/lan743x_main.c | 41 ---
 1 file changed, 25 insertions(+), 16 deletions(-)

diff --git a/drivers/net/ethernet/microchip/lan743x_main.c 
b/drivers/net/ethernet/microchip/lan743x_main.c
index 7ef22bf..50ad56b 100644
--- a/drivers/net/ethernet/microchip/lan743x_main.c
+++ b/drivers/net/ethernet/microchip/lan743x_main.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "lan743x_main.h"
 #include "lan743x_ethtool.h"
 
@@ -804,26 +805,29 @@ static int lan743x_mac_init(struct lan743x_adapter 
*adapter)
data |= MAC_CR_CNTR_RST_;
lan743x_csr_write(adapter, MAC_CR, data);
 
-   mac_addr_hi = lan743x_csr_read(adapter, MAC_RX_ADDRH);
-   mac_addr_lo = lan743x_csr_read(adapter, MAC_RX_ADDRL);
-   adapter->mac_address[0] = mac_addr_lo & 0xFF;
-   adapter->mac_address[1] = (mac_addr_lo >> 8) & 0xFF;
-   adapter->mac_address[2] = (mac_addr_lo >> 16) & 0xFF;
-   adapter->mac_address[3] = (mac_addr_lo >> 24) & 0xFF;
-   adapter->mac_address[4] = mac_addr_hi & 0xFF;
-   adapter->mac_address[5] = (mac_addr_hi >> 8) & 0xFF;
+   if (!is_valid_ether_addr(adapter->mac_address)) {
+   mac_addr_hi = lan743x_csr_read(adapter, MAC_RX_ADDRH);
+   mac_addr_lo = lan743x_csr_read(adapter, MAC_RX_ADDRL);
+   adapter->mac_address[0] = mac_addr_lo & 0xFF;
+   adapter->mac_address[1] = (mac_addr_lo >> 8) & 0xFF;
+   adapter->mac_address[2] = (mac_addr_lo >> 16) & 0xFF;
+   adapter->mac_address[3] = (mac_addr_lo >> 24) & 0xFF;
+   adapter->mac_address[4] = mac_addr_hi & 0xFF;
+   adapter->mac_address[5] = (mac_addr_hi >> 8) & 0xFF;
+
+   if (((mac_addr_hi & 0x) == 0x) &&
+   mac_addr_lo == 0x) {
+   mac_address_valid = false;
+   } else if (!is_valid_ether_addr(adapter->mac_address)) {
+   mac_address_valid = false;
+   }
 
-   if (((mac_addr_hi & 0x) == 0x) &&
-   mac_addr_lo == 0x) {
-   mac_address_valid = false;
-   } else if (!is_valid_ether_addr(adapter->mac_address)) {
-   mac_address_valid = false;
+   if (!mac_address_valid)
+   eth_random_addr(adapter->mac_address);
}
-
-   if (!mac_address_valid)
-   eth_random_addr(adapter->mac_address);
lan743x_mac_set_address(adapter, adapter->mac_address);
ether_addr_copy(netdev->dev_addr, adapter->mac_address);
+
return 0;
 }
 
@@ -2756,6 +2760,7 @@ static int lan743x_pcidev_probe(struct pci_dev *pdev,
 {
struct lan743x_adapter *adapter = NULL;
struct net_device *netdev = NULL;
+   const void *mac_addr;
int ret = -ENODEV;
 
netdev = devm_alloc_etherdev(>dev,
@@ -2772,6 +2777,10 @@ static int lan743x_pcidev_probe(struct pci_dev *pdev,
  NETIF_MSG_IFDOWN | NETIF_MSG_TX_QUEUED;
netdev->max_mtu = LAN743X_MAX_FRAME_SIZE;
 
+   mac_addr = of_get_mac_address(pdev->dev.of_node);
+   if (!IS_ERR(mac_addr))
+   ether_addr_copy(adapter->mac_address, mac_addr);
+
ret = lan743x_pci_init(adapter, pdev);
if (ret)
goto return_error;
-- 
2.7.4

[PATCH] lan743x: add MODULE_DEVICE_TABLE for module loading alias

[Tim Harvey]

Without a MODULE_DEVICE_TABLE the attributes are missing that create
an alias for auto-loading the module in userspace via hotplug.

Signed-off-by: Tim Harvey 
---
 drivers/net/ethernet/microchip/lan743x_main.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/ethernet/microchip/lan743x_main.c 
b/drivers/net/ethernet/microchip/lan743x_main.c
index c5c5c68..f1711ac 100644
--- a/drivers/net/ethernet/microchip/lan743x_main.c
+++ b/drivers/net/ethernet/microchip/lan743x_main.c
@@ -3091,6 +3091,8 @@ static const struct pci_device_id lan743x_pcidev_tbl[] = {
{ 0, }
 };
 
+MODULE_DEVICE_TABLE(pci, lan743x_pcidev_tbl);
+
 static struct pci_driver lan743x_pcidev_driver = {
.name = DRIVER_NAME,
.id_table = lan743x_pcidev_tbl,
-- 
2.7.4

[PATCH 2/2] hwmon: (gsc): add 16bit pre-scaled voltage mode

[Tim Harvey]

add a 16-bit pre-scaled voltage mode to adc and clarify that existing
pre-scaled mode is 24bit.

Signed-off-by: Tim Harvey 
---
 drivers/hwmon/gsc-hwmon.c   | 8 +---
 include/linux/platform_data/gsc_hwmon.h | 3 ++-
 2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/hwmon/gsc-hwmon.c b/drivers/hwmon/gsc-hwmon.c
index 2137bc6..3dfe2ca 100644
--- a/drivers/hwmon/gsc-hwmon.c
+++ b/drivers/hwmon/gsc-hwmon.c
@@ -159,7 +159,7 @@ gsc_hwmon_read(struct device *dev, enum hwmon_sensor_types 
type, u32 attr,
return -EOPNOTSUPP;
}
 
-   sz = (ch->mode == mode_voltage) ? 3 : 2;
+   sz = (ch->mode == mode_voltage_24bit) ? 3 : 2;
ret = regmap_bulk_read(hwmon->regmap, ch->reg, buf, sz);
if (ret)
return ret;
@@ -186,7 +186,8 @@ gsc_hwmon_read(struct device *dev, enum hwmon_sensor_types 
type, u32 attr,
/* adjust by uV offset */
tmp += ch->mvoffset;
break;
-   case mode_voltage:
+   case mode_voltage_24bit:
+   case mode_voltage_16bit:
/* no adjustment needed */
break;
}
@@ -336,7 +337,8 @@ static int gsc_hwmon_probe(struct platform_device *pdev)
 HWMON_T_LABEL;
i_temp++;
break;
-   case mode_voltage:
+   case mode_voltage_24bit:
+   case mode_voltage_16bit:
case mode_voltage_raw:
if (i_in == GSC_HWMON_MAX_IN_CH) {
dev_err(gsc->dev, "too many input channels\n");
diff --git a/include/linux/platform_data/gsc_hwmon.h 
b/include/linux/platform_data/gsc_hwmon.h
index ec1611a..37a8f554d 100644
--- a/include/linux/platform_data/gsc_hwmon.h
+++ b/include/linux/platform_data/gsc_hwmon.h
@@ -4,8 +4,9 @@
 
 enum gsc_hwmon_mode {
mode_temperature,
-   mode_voltage,
+   mode_voltage_24bit,
mode_voltage_raw,
+   mode_voltage_16bit,
mode_max,
 };
 
-- 
2.7.4

[PATCH 1/2] dt-bindings: mfd: gateworks-gsc: add 16bit pre-scaled voltage mode

[Tim Harvey]

add a 16-bit pre-scaled voltage mode to adc and clarify that existing
pre-scaled mode is 24bit.

Signed-off-by: Tim Harvey 
---
 Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml 
b/Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml
index 487a844..ceec33f 100644
--- a/Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml
+++ b/Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml
@@ -79,11 +79,12 @@ properties:
 description: |
   conversion mode:
 0 - temperature, in C*10
-1 - pre-scaled voltage value
+1 - pre-scaled 24-bit voltage value
 2 - scaled voltage based on an optional resistor divider
 and optional offset
+3 - pre-scaled 16-bit voltage value
 $ref: /schemas/types.yaml#/definitions/uint32
-enum: [0, 1, 2]
+enum: [0, 1, 2, 3]
 
   gw,voltage-divider-ohms:
 description: Values of resistors for divider on raw ADC input
-- 
2.7.4

[PATCH 0/2] add 16bit pre-scaled adc mode to Gateworks GSC hwmon

[Tim Harvey]

The Gateworks GSC hwmon driver supports multiple modes of ADC's. Add a
mode for 16-bit pre-scaled values and clarify that the existing pre-scale
mode is 24-bit.

Tim Harvey (2):
  dt-bindings: mfd: gateworks-gsc: add 16bit pre-scaled voltage mode
  hwmon: (gsc): add 16bit pre-scaled voltage mode

 Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml | 5 +++--
 drivers/hwmon/gsc-hwmon.c| 8 +---
 include/linux/platform_data/gsc_hwmon.h  | 3 ++-
 3 files changed, 10 insertions(+), 6 deletions(-)

-- 
2.7.4

[PATCH] ARM: dts: imx6qdl-gw54xx: allow boot firmware to set eth1 MAC

[Tim Harvey]

The GW54xx has a PCIe based GbE as the 2nd ethernet device. The
boot firmware will populate the local-mac-address field of the
device aliased to ethernet1 thus adding the PCIe device to
dt allows boot firmware to set its MAC address.

Signed-off-by: Tim Harvey 
---
 arch/arm/boot/dts/imx6qdl-gw54xx.dtsi | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi 
b/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
index c40583d..5527f95 100644
--- a/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
@@ -9,6 +9,7 @@
 / {
/* these are used by bootloader for disabling nodes */
aliases {
+   ethernet1 = 
led0 = 
led1 = 
led2 = 
@@ -398,6 +399,23 @@
pinctrl-0 = <_pcie>;
reset-gpio = < 29 GPIO_ACTIVE_LOW>;
status = "okay";
+
+   pcie@0,0,0 {
+   reg = <0x 0 0 0 0>;
+
+   pcie@1,0,0 {
+   reg = <0x 0 0 0 0>;
+
+   pcie@2,8,0 {
+   reg = <0x4000 0 0 0 0>;
+
+   eth1: pcie@8,0,0 {
+   reg = <0x 0 0 0 0>;
+   local-mac-address = [00 00 00 00 00 00];
+   };
+   };
+   };
+   };
 };
 
  {
-- 
2.7.4

[PATCH] ARM: dts: imx6qdl-gw53xx: allow boot firmware to set eth1 MAC

[Tim Harvey]

The GW53xx has a PCIe based GbE as the 2nd ethernet device. The
boot firmware will populate the local-mac-address field of the
device aliased to ethernet1 thus adding the PCIe device to
dt allows boot firmware to set its MAC address.

Signed-off-by: Tim Harvey 
---
 arch/arm/boot/dts/imx6qdl-gw53xx.dtsi | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi 
b/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
index 8942bec..6601d07 100644
--- a/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
@@ -8,6 +8,7 @@
 / {
/* these are used by bootloader for disabling nodes */
aliases {
+   ethernet1 = 
led0 = 
led1 = 
led2 = 
@@ -341,6 +342,23 @@
pinctrl-0 = <_pcie>;
reset-gpio = < 29 GPIO_ACTIVE_LOW>;
status = "okay";
+
+   pcie@0,0,0 {
+   reg = <0x 0 0 0 0>;
+
+   pcie@1,0,0 {
+   reg = <0x 0 0 0 0>;
+
+   pcie@2,4,0 {
+   reg = <0x2000 0 0 0 0>;
+
+   eth1: pcie@4,0,0 {
+   reg = <0x 0 0 0 0>;
+   local-mac-address = [00 00 00 00 00 00];
+   };
+   };
+   };
+   };
 };
 
  {
-- 
2.7.4

[RFC PATCH] spi: spi-cavium-thunderx: flag controller as half duplex

[Tim Harvey]

The OcteonTX (TX1/ThunderX) SPI controller does not support full
duplex transactions. Set the appropriate flag such that the spi
core will return -EINVAL on such transactions requested by chip
drivers.

This is an RFC as I need someone from Marvell/Cavium to confirm
if this driver is used for other silicon that does support
full duplex transfers (in which case we will need to identify
that we are running on the ThunderX arch before setting the flag).

Cc: Robert Richter 
Signed-off-by: Tim Harvey 
---
 drivers/spi/spi-cavium-thunderx.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/spi/spi-cavium-thunderx.c 
b/drivers/spi/spi-cavium-thunderx.c
index fd6b9ca..60c0d69 100644
--- a/drivers/spi/spi-cavium-thunderx.c
+++ b/drivers/spi/spi-cavium-thunderx.c
@@ -64,6 +64,7 @@ static int thunderx_spi_probe(struct pci_dev *pdev,
p->sys_freq = SYS_FREQ_DEFAULT;
dev_info(dev, "Set system clock to %u\n", p->sys_freq);
 
+   master->flags = SPI_MASTER_HALF_DUPLEX;
master->num_chipselect = 4;
master->mode_bits = SPI_CPHA | SPI_CPOL | SPI_CS_HIGH |
SPI_LSB_FIRST | SPI_3WIRE;
-- 
2.7.4

[PATCH] can: mcp251x: add support for half duplex controllers

[Tim Harvey]

Some SPI host controllers do not support full-duplex SPI and are
marked as such via the SPI_CONTROLLER_HALF_DUPLEX controller flag.

For such controllers use half duplex transactions but retain full
duplex transactions for the controllers that can handle those.

Signed-off-by: Tim Harvey 
---
 drivers/net/can/spi/mcp251x.c | 34 +++---
 1 file changed, 27 insertions(+), 7 deletions(-)

diff --git a/drivers/net/can/spi/mcp251x.c b/drivers/net/can/spi/mcp251x.c
index 5009ff2..203ef20 100644
--- a/drivers/net/can/spi/mcp251x.c
+++ b/drivers/net/can/spi/mcp251x.c
@@ -290,8 +290,12 @@ static u8 mcp251x_read_reg(struct spi_device *spi, u8 reg)
priv->spi_tx_buf[0] = INSTRUCTION_READ;
priv->spi_tx_buf[1] = reg;
 
-   mcp251x_spi_trans(spi, 3);
-   val = priv->spi_rx_buf[2];
+   if (spi->controller->flags & SPI_CONTROLLER_HALF_DUPLEX) {
+   spi_write_then_read(spi, priv->spi_tx_buf, 2, , 1);
+   } else {
+   mcp251x_spi_trans(spi, 3);
+   val = priv->spi_rx_buf[2];
+   }
 
return val;
 }
@@ -303,10 +307,18 @@ static void mcp251x_read_2regs(struct spi_device *spi, u8 
reg, u8 *v1, u8 *v2)
priv->spi_tx_buf[0] = INSTRUCTION_READ;
priv->spi_tx_buf[1] = reg;
 
-   mcp251x_spi_trans(spi, 4);
+   if (spi->controller->flags & SPI_CONTROLLER_HALF_DUPLEX) {
+   u8 val[2] = { 0 };
 
-   *v1 = priv->spi_rx_buf[2];
-   *v2 = priv->spi_rx_buf[3];
+   spi_write_then_read(spi, priv->spi_tx_buf, 2, val, 2);
+   *v1 = val[0];
+   *v2 = val[1];
+   } else {
+   mcp251x_spi_trans(spi, 4);
+
+   *v1 = priv->spi_rx_buf[2];
+   *v2 = priv->spi_rx_buf[3];
+   }
 }
 
 static void mcp251x_write_reg(struct spi_device *spi, u8 reg, u8 val)
@@ -409,8 +421,16 @@ static void mcp251x_hw_rx_frame(struct spi_device *spi, u8 
*buf,
buf[i] = mcp251x_read_reg(spi, RXBCTRL(buf_idx) + i);
} else {
priv->spi_tx_buf[RXBCTRL_OFF] = INSTRUCTION_READ_RXB(buf_idx);
-   mcp251x_spi_trans(spi, SPI_TRANSFER_BUF_LEN);
-   memcpy(buf, priv->spi_rx_buf, SPI_TRANSFER_BUF_LEN);
+   if (spi->controller->flags & SPI_CONTROLLER_HALF_DUPLEX) {
+   spi_write_then_read(spi, priv->spi_tx_buf, 1,
+   priv->spi_rx_buf,
+   SPI_TRANSFER_BUF_LEN);
+   memcpy(buf + 1, priv->spi_rx_buf,
+  SPI_TRANSFER_BUF_LEN - 1);
+   } else {
+   mcp251x_spi_trans(spi, SPI_TRANSFER_BUF_LEN);
+   memcpy(buf, priv->spi_rx_buf, SPI_TRANSFER_BUF_LEN);
+   }
}
 }
 
-- 
2.7.4

Re: [PATCH] can: mcp251x: convert to half-duplex SPI

[Tim Harvey]

On Wed, Feb 26, 2020 at 2:19 AM Marc Kleine-Budde  wrote:
>
> On 2/26/20 8:37 AM, Marc Kleine-Budde wrote:
> >> Your right... there is the mcp251x_hw_rx_frame() call that also uses
> >> spi_rx_buf after a synchronous transfer (I didn't see any others).
> >> I'll look at this again.
> >
> > Have you hardware to test your changes? I think the SPI framework would
> > return an -EINVAL in that casethough the return value is sometimes
> > not checked by the driver :/
>
> See https://elixir.bootlin.com/linux/v5.5.6/source/drivers/spi/spi.c#L3413
>
> If you have really have HW with SPI_CONTROLLER_HALF_DUPLEX (a.k.a
> SPI_MASTER_HALF_DUPLEX) restrictions, you need to convert _every_
> mcp251x_spi_trans() call in the driver, as _always_ both rx_buf _and_
> tx_buf are used.
>

Marc,

Sorry for the long delay... I'm finally getting back to this issue.

I'm told by Marvell/Cavium that the OcteonTX SPI hardware does not
support full duplex although I don't see this in any of their errata
or reference manuals. Perhaps someone familiar with the CN81xx/CN80xx
OcteonTX hardware from Marvell/Cavium can weigh in here as I'm not
clear if this limitation is in all hardware that uses the
spi-cavium-thunderx.c driver (I've added Jan to the list who authored
the driver)

As you point out setting SPI_CONTROLLER_HALF_DUPLEX will cause
spi_{sync,async,async_locked} calls to fail with -EINVAL if they have
both a tx and rx buf, so this should be done to help catch these
issues:
diff --git a/drivers/spi/spi-cavium-thunderx.c
b/drivers/spi/spi-cavium-thunderx.c
index fd6b9ca..76fdb94 100644
--- a/drivers/spi/spi-cavium-thunderx.c
+++ b/drivers/spi/spi-cavium-thunderx.c
@@ -64,6 +65,7 @@ static int thunderx_spi_probe(struct pci_dev *pdev,
p->sys_freq = SYS_FREQ_DEFAULT;
dev_info(dev, "Set system clock to %u\n", p->sys_freq);

+   master->flags = SPI_MASTER_HALF_DUPLEX;
master->num_chipselect = 4;
master->mode_bits = SPI_CPHA | SPI_CPOL | SPI_CS_HIGH |
SPI_LSB_FIRST | SPI_3WIRE;

Now, with regards to the mcp251x.c driver you were correct that I was
missing dealing with the full-duplex call from mcp251x_hw_rx_frame()
which indeed was causing data corruption on recieve.

So the following patch to mcp251x.c properly converts mcp251x to half-duplex:

diff --git a/drivers/net/can/spi/mcp251x.c b/drivers/net/can/spi/mcp251x.c
index 5009ff2..016c1e5 100644
--- a/drivers/net/can/spi/mcp251x.c
+++ b/drivers/net/can/spi/mcp251x.c
@@ -290,23 +290,23 @@ static u8 mcp251x_read_reg(struct spi_device *spi, u8 reg)
priv->spi_tx_buf[0] = INSTRUCTION_READ;
priv->spi_tx_buf[1] = reg;

-   mcp251x_spi_trans(spi, 3);
-   val = priv->spi_rx_buf[2];
+   spi_write_then_read(spi, priv->spi_tx_buf, 2, , 1);

return val;
 }

 static void mcp251x_read_2regs(struct spi_device *spi, u8 reg, u8 *v1, u8 *v2)
 {
+   u8 val[2] = {0};
struct mcp251x_priv *priv = spi_get_drvdata(spi);

priv->spi_tx_buf[0] = INSTRUCTION_READ;
priv->spi_tx_buf[1] = reg;

-   mcp251x_spi_trans(spi, 4);
+   spi_write_then_read(spi, priv->spi_tx_buf, 2, val, 2);

-   *v1 = priv->spi_rx_buf[2];
-   *v2 = priv->spi_rx_buf[3];
+   *v1 = val[0];
+   *v2 = val[1];
 }

 static void mcp251x_write_reg(struct spi_device *spi, u8 reg, u8 val)
@@ -409,8 +409,9 @@ static void mcp251x_hw_rx_frame(struct spi_device
*spi, u8 *buf,
buf[i] = mcp251x_read_reg(spi, RXBCTRL(buf_idx) + i);
} else {
priv->spi_tx_buf[RXBCTRL_OFF] = INSTRUCTION_READ_RXB(buf_idx);
-   mcp251x_spi_trans(spi, SPI_TRANSFER_BUF_LEN);
-   memcpy(buf, priv->spi_rx_buf, SPI_TRANSFER_BUF_LEN);
+   spi_write_then_read(spi, priv->spi_tx_buf, 1, priv->spi_rx_buf,
+   SPI_TRANSFER_BUF_LEN);
+   memcpy(buf + 1, priv->spi_rx_buf, SPI_TRANSFER_BUF_LEN - 1);
}
 }

I do have hardware to test with and without this patch my CN80xx board
with an MCP25625 fails device probing (mcp251x spi0.1: MCP251x didn't
enter in conf mode after reset) because read values are corrupt. With
this patch my the MCP25625 works fine on the CN80xx detecting,
sending, and receiving frames.

Should I be submitting this patch with logic that only does
half-duplex if the spi controller doesn't support it (if
(spi->controller->flags & SPI_CONTROLLER_HALF_DUPLEX)) or is it
acceptable to simply make the driver half-duplex like this for all
cases?

Best Regards,

Tim

Re: [PATCH] soc: imx: Add power domain driver support for i.mx8m family

[Tim Harvey]

On Mon, May 4, 2020 at 2:19 AM Lucas Stach  wrote:
>
> Am Montag, den 27.04.2020, 15:37 + schrieb Jacky Bai:
> > > -Original Message-
> > > From: Lucas Stach 
> > > Sent: Monday, April 27, 2020 11:11 PM
> > > To: Abel Vesa ; Jacky Bai ; Shawn
> > > Guo ; Sascha Hauer ; Liam
> > > Girdwood ; Mark Brown 
> > > Cc: Aisheng Dong ; dl-linux-imx
> > > ; linux-arm-ker...@lists.infradead.org; Linux Kernel
> > > Mailing List 
> > > Subject: Re: [PATCH] soc: imx: Add power domain driver support for i.mx8m
> > > family
> > >
> > > Am Montag, den 27.04.2020, 17:58 +0300 schrieb Abel Vesa:
> > > > From: Jacky Bai 
> > > >
> > > > The i.MX8M family is a set of NXP product focus on delivering the
> > > > latest and greatest video and audio experience combining
> > > > state-of-the-art media-specific features with high-performance
> > > > processing while optimized for lowest power consumption.
> > > >
> > > > i.MX8MQ, i.MX8MM, i.MX8MN, even the furture i.MX8MP are all belong to
> > > > this family. A GPC module is used to manage all the PU power domain
> > > > on/off. But the situation is that the number of power domains & the
> > > > power up sequence has significate difference on those SoCs. Even on
> > > > the same SoC. The power up sequence still has big difference. It makes
> > > > us hard to reuse the GPCv2 driver to cover the whole i.MX8M family.
> > > > Each time a new SoC is supported in the mainline kernel, we need to
> > > > modify the GPCv2 driver to support it. We need to add or modify
> > > > hundred lines of code in worst case.
> > > > It is a bad practice for the driver maintainability.
> > > >
> > > > This driver add a more generic power domain driver that the actual
> > > > power on/off is done by TF-A code. the abstraction give us the
> > > > possibility that using one driver to cover the whole i.MX8M family in
> > > > kernel side.
> > > >
> > >
> > > Again: what does this driver bring to the table, other than moving a 
> > > fraction of
> > > the power domain functionality into the firmware?
> > >
> > > The discussions on the last submissions of this driver already 
> > > established that
> > > we can't move all functionality for the power domains into the firmware, 
> > > as
> > > controlling regulators is probably not easy to do from this context. Also 
> > > the
> > > TF-A side implementation of this driver is "interesting" IMHO, it does 
> > > stuff like
> > > accessing the clock controller registers without any locking or other 
> > > means of
> > > mutual exclusion with the Linux kernel clock controller driver.
> > >
> >
> > The clock handling is in kernel side through CCF, not in ATF. See the patch 
> > below.
> >
> > > Why can't we just extend the existing GPCv2 driver with support for the 
> > > other
> > > i.MX8M family members?
> > >
> >
> > The reason that why I don’t like to extend the GPCv2 is that when doing 
> > domain on/off,
> > We need to access some special control register in each domain & do some 
> > special flow,
> > These control register(mediamix block control, vpumix block control) is not 
> > in GPC
> > module's address range. No benefit to reuse the GPCv2. Only bring 
> > complexity to the
> > GPCv2 driver each time a new SoC is added.
> >
> > Yes, the i.MX8M power domain support has been pending for a while. ARM guys 
> > rejected this patchset
> > because they suggest us to use SCMI rather than SiP. But SCMI is only 
> > partial suitable for our
> > case.
>
> Can you please point me to the most resent version of the TF-A side
> implementation of this? The i.MX8MM implementation in the
> imx_5.4.3_2.0.0 branch in the codeaurora imx-atf repo still contains
> writes to the clock controller register range.
>
> Also I would love to learn why the GPC needs to access Mediamix and
> VPUmix domain registers. If you are talking about the NOC configuration
> I would strongly suggest that those should be handled by a Linux side
> interconnect driver, this has nothing to do with the power domain
> sequencing, it just happens to lose state over the power down and needs
> to be reprogrammed after power on. The NOC configuration though is use-
> case dependent, so this should be properly handled in a rich OS driver.
>
> Sure we needs to extend the Linux side GPC driver for each new SoC
> generation, but that's no different from any other hardware driver in
> Linux. Drivers are the abstraction around the hardware, there is no
> need to invent another one if there are no clear benefits.
>

Jacky / Abel,

Any movement on this? As I see it the lack of imx8mm power-domain
support in the kernel is holding up USB, PCIe, VPU, and perhaps
GPU/CSI as well. I would tend to agree that hiding this functionality
in the TF-A is probably not the best approach especially as that
requires a NXP version of the TF-A. I really don't see the issue with
the gpc driver getting a little more complicated if it needs to. There
is bound to be some complication as there is such a large variation of

[PATCH] ARM: dts: imx: imx6qdl-gw: add Gateworks System Controller

[Tim Harvey]

Add Gateworks System Controller support to Gateworks Ventana boards:
- add dt bindings for GSC mfd driver and hwmon driver for ADC's and
  fan controllers.
- add dt bindings for gpio-keys driver for push-button and interrupt events
  from the GSC.

Signed-off-by: Tim Harvey 
---
 arch/arm/boot/dts/imx6qdl-gw51xx.dtsi | 152 +--
 arch/arm/boot/dts/imx6qdl-gw52xx.dtsi | 158 ++--
 arch/arm/boot/dts/imx6qdl-gw53xx.dtsi | 164 +++--
 arch/arm/boot/dts/imx6qdl-gw54xx.dtsi | 166 --
 arch/arm/boot/dts/imx6qdl-gw551x.dtsi | 146 --
 arch/arm/boot/dts/imx6qdl-gw552x.dtsi | 152 +--
 arch/arm/boot/dts/imx6qdl-gw553x.dtsi | 140 +++-
 arch/arm/boot/dts/imx6qdl-gw560x.dtsi | 164 +++--
 arch/arm/boot/dts/imx6qdl-gw5903.dtsi | 139 +++-
 arch/arm/boot/dts/imx6qdl-gw5904.dtsi | 140 +++-
 arch/arm/boot/dts/imx6qdl-gw5907.dtsi | 141 -
 arch/arm/boot/dts/imx6qdl-gw5910.dtsi | 159 +++-
 arch/arm/boot/dts/imx6qdl-gw5912.dtsi | 146 +-
 arch/arm/boot/dts/imx6qdl-gw5913.dtsi | 152 ++-
 14 files changed, 2062 insertions(+), 57 deletions(-)

diff --git a/arch/arm/boot/dts/imx6qdl-gw51xx.dtsi 
b/arch/arm/boot/dts/imx6qdl-gw51xx.dtsi
index 419a7cd..5fbf7d1 100644
--- a/arch/arm/boot/dts/imx6qdl-gw51xx.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw51xx.dtsi
@@ -19,6 +19,53 @@
bootargs = "console=ttymxc1,115200";
};
 
+   gpio_keys {
+   compatible = "gpio-keys";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   user_pb {
+   label = "user_pb";
+   gpios = <_gpio 0 GPIO_ACTIVE_LOW>;
+   linux,code = <256>; /* BTN_0 */
+   };
+
+   user_pb1x {
+   label = "user_pb1x";
+   linux,code = <257>; /* BTN_1 */
+   interrupt-parent = <>;
+   interrupts = <0>;
+   };
+
+   key_erased {
+   label = "key-erased";
+   linux,code = <258>; /* BTN_2 */
+   interrupt-parent = <>;
+   interrupts = <1>;
+   };
+
+   eeprom_wp {
+   label = "eeprom_wp";
+   linux,code = <259>; /* BTN_3 */
+   interrupt-parent = <>;
+   interrupts = <2>;
+   };
+
+   tamper {
+   label = "tamper";
+   linux,code = <260>; /* BTN_4 */
+   interrupt-parent = <>;
+   interrupts = <5>;
+   };
+
+   switch_hold {
+   label = "switch_hold";
+   linux,code = <261>; /* BTN_5 */
+   interrupt-parent = <>;
+   interrupts = <7>;
+   };
+   };
+
leds {
compatible = "gpio-leds";
pinctrl-names = "default";
@@ -102,6 +149,103 @@
pinctrl-0 = <_i2c1>;
status = "okay";
 
+   gsc: gsc@20 {
+   compatible = "gw,gsc";
+   reg = <0x20>;
+   interrupt-parent = <>;
+   interrupts = <4 GPIO_ACTIVE_LOW>;
+   interrupt-controller;
+   #interrupt-cells = <1>;
+   #size-cells = <0>;
+
+   adc {
+   compatible = "gw,gsc-adc";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   channel@0 {
+   gw,mode = <0>;
+   reg = <0x00>;
+   label = "temp";
+   };
+
+   channel@2 {
+   gw,mode = <1>;
+   reg = <0x02>;
+   label = "vdd_vin";
+   };
+
+   channel@5 {
+   gw,mode = <1>;
+   reg = <0x05>;
+   label = "vdd_3p3";
+   };
+
+   channel@8 {
+   gw,mode = <1>;
+   

Re: [PATCH] ARM64: dts: imx8mm-evk: Assigned clocks for audio plls

[Tim Harvey]

On Wed, Oct 16, 2019 at 3:36 AM S.j. Wang  wrote:
>
> Assign clocks and clock-rates for audio plls, that audio
> drivers can utilize them.
>
> Add dai-tdm-slot-num and dai-tdm-slot-width for sound-wm8524,
> that sai driver can generate correct bit clock.
>
> Fixes: 13f3b9fdef6c ("arm64: dts: imx8mm-evk: Enable audio codec wm8524")
> Signed-off-by: Shengjiu Wang 
> ---
>  arch/arm64/boot/dts/freescale/imx8mm-evk.dts | 2 ++
>  arch/arm64/boot/dts/freescale/imx8mm.dtsi| 8 ++--
>  2 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dts 
> b/arch/arm64/boot/dts/freescale/imx8mm-evk.dts
> index f7a15f3904c2..13137451b438 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dts
> +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dts
> @@ -62,6 +62,8 @@
>
> cpudai: simple-audio-card,cpu {
> sound-dai = <>;
> +   dai-tdm-slot-num = <2>;
> +   dai-tdm-slot-width = <32>;
> };
>

Shengjiu,

Can you explain the why dai-tdm-slot-width here is 32? I noticed when
I assigned that for an imx8mm board I'm working on (that uses a
tlv320aic3x codec) I ended up with the clock being off by a factor of
2 (audio playback was 2x too slow).

Best Regards,

Tim

[PATCH 3/3] hwmon: add Gateworks System Controller support

[Tim Harvey]

The Gateworks System Controller has a hwmon sub-component that exposes
up to 16 ADC's, some of which are temperature sensors, others which are
voltage inputs. The ADC configuration (register mapping and name) is
configured via device-tree and varies board to board.

Signed-off-by: Tim Harvey 
Reviewed-by: Guenter Roeck 
---
v11:
- no change

v10:
- no change

v9:
- use exported gsc_{read,write}
- added Reviewed-by: Guenter Roeck 

v8:
- move regmap init to hwmon

v7:
- fix whitespace in Kconfig
- remove unnecessary device pointer in private data
- change divider from mili-ohms to ohms
- move fan base property to reg

v6:
- fix size of info field
- improve pwm output control documentation
- include unit suffix in divider and offset
- change subnode name to gsc-adc
- change to fan subnode
- fix voltage offset

v5:
- fix various checkpatch issues
- correct gsc-hwmon.rst in MAINTAINERS
- encorporate Gunter's feedback:
 - switch to SENSOR_DEVICE_ATTR_{RW,RO}
 - use tmp value to avoid excessive pointer deference
 - simplify shift operation
 - scale voffset once
 - simplify is_visible function
 - remove empty line at end of file

v4:
- adjust for uV offset from device-tree
- remove unnecessary optional write function
- remove register range check
- change dev_err prints to use gsc dev
- hard-code resolution/scaling for raw adcs
- describe units of ADC resolution
- move to using pwm_auto_point_{pwm,temp} for FAN PWM
- ensure space before/after operators
- remove unnecessary parens
- remove more debugging
- add default case and comment for type_voltage
- remove unnecessary index bounds checks for channel
- remove unnecessary clearing of struct fields
- added Documentation/hwmon/gsc-hwmon.rst

v3:
- add voltage_raw input type and supporting fields
- add channel validation to is_visible function
- remove unnecessary channel validation from read/write functions

v2:
- change license comment style
- remove DEBUG
- simplify regmap_bulk_read err check
- remove break after returns in switch statement
- fix fan setpoint buffer address
- remove unnecessary parens
- consistently use struct device *dev pointer
- change license/comment block
- add validation for hwmon child node props
- move parsing of of to own function
- use strlcpy to ensure null termination
- fix static array sizes and removed unnecessary initializers
- dynamically allocate channels
- fix fan input label
- support platform data
- fixed whitespace issues
---
 Documentation/hwmon/gsc-hwmon.rst   |  53 +
 Documentation/hwmon/index.rst   |   1 +
 MAINTAINERS |   3 +
 drivers/hwmon/Kconfig   |   9 +
 drivers/hwmon/Makefile  |   1 +
 drivers/hwmon/gsc-hwmon.c   | 390 
 include/linux/platform_data/gsc_hwmon.h |  44 
 7 files changed, 501 insertions(+)
 create mode 100644 Documentation/hwmon/gsc-hwmon.rst
 create mode 100644 drivers/hwmon/gsc-hwmon.c
 create mode 100644 include/linux/platform_data/gsc_hwmon.h

diff --git a/Documentation/hwmon/gsc-hwmon.rst 
b/Documentation/hwmon/gsc-hwmon.rst
new file mode 100644
index ..ffac392
--- /dev/null
+++ b/Documentation/hwmon/gsc-hwmon.rst
@@ -0,0 +1,53 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Kernel driver gsc-hwmon
+===
+
+Supported chips: Gateworks GSC
+Datasheet: http://trac.gateworks.com/wiki/gsc
+Author: Tim Harvey 
+
+Description:
+
+
+This driver supports hardware monitoring for the temperature sensor,
+various ADC's connected to the GSC, and optional FAN controller available
+on some boards.
+
+
+Voltage Monitoring
+--
+
+The voltage inputs are scaled either internally or by the driver depending
+on the GSC version and firmware. The values returned by the driver do not need
+further scaling. The voltage input labels provide the voltage rail name:
+
+inX_input  Measured voltage (mV).
+inX_label  Name of voltage rail.
+
+
+Temperature Monitoring
+--
+
+Temperatures are measured with 12-bit or 10-bit resolution and are scaled
+either internally or by the driver depending on the GSC version and firmware.
+The values returned by the driver reflect millidegree Celcius:
+
+tempX_inputMeasured temperature.
+tempX_labelName of temperature input.
+
+
+PWM Output Control
+--
+
+The GSC features 1 PWM output that operates in automatic mode where the
+PWM value will be scalled depending on 6 temperature boundaries.
+The tempeature boundaries are read-write and in millidegree Celcius and the
+read-only PWM values range from 0 (off) to 255 (full speed).
+Fan speed will be set to minimum (off) when the temperature sensor reads
+less than pwm1_auto_point1_temp and maximum when the temperature sensor
+equals or exceeds pwm1_auto_point6_temp.
+
+pwm1_auto_point[1-6]_pwm   PWM value.
+pwm1_auto_point[1-6]_temp  Temperature boundary.
+
diff --git

[PATCH v11 2/3] mfd: add Gateworks System Controller core driver

[Tim Harvey]

The Gateworks System Controller (GSC) is an I2C slave controller
implemented with an MSP430 micro-controller whose firmware embeds the
following features:
 - I/O expander (16 GPIO's) using PCA955x protocol
 - Real Time Clock using DS1672 protocol
 - User EEPROM using AT24 protocol
 - HWMON using custom protocol
 - Interrupt controller with tamper detect, user pushbotton
 - Watchdog controller capable of full board power-cycle
 - Power Control capable of full board power-cycle

see http://trac.gateworks.com/wiki/gsc for more details

Signed-off-by: Tim Harvey 
Acked-for-MFD-by: Lee Jones 
---
v11:
- fix compile error

v10:
- fix typo and gramatical errors in Kconfig and comment block
- drop unused i2c device-id table
- added Lee's ack in s-o-b

v9:
- rebase against 5.7-rc2
- cleanup gsc_powerdown() by using BIT(), put_unaligned_le32(), and avoid
  unnecessary assignments
- rename GSC_CTRL_1 SLEEP related defines to simplify
- add better description and sub-module info to driver description
- whitespace changes per review
- remove unused irq_data pointer in ddata
- remove unnecesary i2c_set_clientdata
- use devm_i2c_new_dummy_device to avoid need of free's
- change regsiter definitions to enum
- export gsc_{read,write} instead of sharing them via ddata

v8:
- whitespace fixes
- describe sub-devices in Kconfig
- add error print for invalid command
- update copyright
- use devm_of_platform_populate
- use probe_new
- move hwmon's regmap init to hwmon

v7:
- remove irq from private data struct

v6:
- remove duplicate signature and fix commit log

v5:
- simplify powerdown function

v4:
- remove hwmon max reg check/define
- fix powerdown function

v3:
- rename gsc->gateworks-gsc
- remove uncecessary include for linux/mfd/core.h
- upercase I2C in comments
- remove i2c debug
- remove uncecessary comments
- don't use KBUILD_MODNAME for name
- remove unnecessary v1/v2/v3 tracking
- unregister hwmon i2c adapter on remove

v2:
- change license comment block style
- remove COMPILE_TEST (Randy)
- fixed whitespace issues
- replaced a printk with dev_err
---
 MAINTAINERS |   8 ++
 drivers/mfd/Kconfig |  15 +++
 drivers/mfd/Makefile|   1 +
 drivers/mfd/gateworks-gsc.c | 277 
 include/linux/mfd/gsc.h |  76 
 5 files changed, 377 insertions(+)
 create mode 100644 drivers/mfd/gateworks-gsc.c
 create mode 100644 include/linux/mfd/gsc.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 091ec22..c78a014 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7028,6 +7028,14 @@ F:   kernel/futex.c
 F: tools/perf/bench/futex*
 F: tools/testing/selftests/futex/
 
+GATEWORKS SYSTEM CONTROLLER (GSC) DRIVER
+M:     Tim Harvey 
+M: Robert Jones 
+S: Maintained
+F: Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml
+F: drivers/mfd/gateworks-gsc.c
+F: include/linux/mfd/gsc.h
+
 GASKET DRIVER FRAMEWORK
 M: Rob Springer 
 M: Todd Poynor 
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 0a59249..05448e7 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -407,6 +407,21 @@ config MFD_EXYNOS_LPASS
  Select this option to enable support for Samsung Exynos Low Power
  Audio Subsystem.
 
+config MFD_GATEWORKS_GSC
+   tristate "Gateworks System Controller"
+   depends on (I2C && OF)
+   select MFD_CORE
+   select REGMAP_I2C
+   select REGMAP_IRQ
+   help
+ Enable support for the Gateworks System Controller (GSC) found
+ on Gateworks Single Board Computers supporting system functions
+ such as push-button monitor, multiple ADC's for voltage and
+ temperature monitoring, fan controller and watchdog monitor.
+ This driver provides common support for accessing the device.
+ Additional drivers must be enabled in order to use the
+ functionality of the device.
+
 config MFD_MC13XXX
tristate
depends on (SPI_MASTER || I2C)
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index f935d10..ed433ae 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_MFD_BCM590XX)+= bcm590xx.o
 obj-$(CONFIG_MFD_BD9571MWV)+= bd9571mwv.o
 obj-$(CONFIG_MFD_CROS_EC_DEV)  += cros_ec_dev.o
 obj-$(CONFIG_MFD_EXYNOS_LPASS) += exynos-lpass.o
+obj-$(CONFIG_MFD_GATEWORKS_GSC)+= gateworks-gsc.o
 
 obj-$(CONFIG_HTC_PASIC3)   += htc-pasic3.o
 obj-$(CONFIG_HTC_I2CPLD)   += htc-i2cpld.o
diff --git a/drivers/mfd/gateworks-gsc.c b/drivers/mfd/gateworks-gsc.c
new file mode 100644
index ..576da62
--- /dev/null
+++ b/drivers/mfd/gateworks-gsc.c
@@ -0,0 +1,277 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * The Gateworks System Controller (GSC) is a multi-function
+ * device designed for use in Gateworks Single Board Computers.
+ * The control interface is I2C, with an interrupt. The device supports
+ * system functions such as push-button monit

[PATCH v11 0/3] Add support for the Gateworks System Controller

[Tim Harvey]

This series adds support for the Gateworks System Controller used on Gateworks
Laguna, Ventana, and Newport product families.

The GSC is an MSP430 I2C slave controller whose firmware embeds the following
features:
 - I/O expander (16 GPIO's emulating a PCA955x)
 - EEPROM (enumating AT24)
 - RTC (enumating DS1672)
 - HWMON
 - Interrupt controller with tamper detect, user pushbotton
 - Watchdog controller capable of full board power-cycle
 - Power Control capable of full board power-cycle

see http://trac.gateworks.com/wiki/gsc for more details

v11:
 - mfd: fix compile error

v10:
 - mfd: fix typo and gramatical errors in Kconfig and comment block
 - mfd: drop unused i2c device-id table
 - mfd: added Lee's ack in s-o-b

v9:
 - rebase against 5.7-rc2
 - dt-binding: remove allOf: see https://lkml.org/lkml/2020/4/15/1930
 - dt-binding: encorporate Lee's review comments for item descriptions
 - dt-binding: added Reviewed-by: Rob Herring 
 - mfd: cleanup gsc_powerdown() by using BIT(), put_unaligned_le32(), and
   avoid unnecessary assignments
 - mfd: rename GSC_CTRL_1 SLEEP related defines to simplify
 - mfd: add better description and sub-module info to driver description
 - mfd: whitespace changes per review
 - mfd: remove unused irq_data pointer in ddata
 - mfd: remove unnecesary i2c_set_clientdata
 - mfd: use devm_i2c_new_dummy_device to avoid need of free's
 - mfd: change regsiter definitions to enum
 - mfd: export gsc_{read,write} instead of sharing them via ddata
 - hwmon: use exported gsc_{read,write}
 - hwmon: added Reviewed-by: Guenter Roeck 

v8:
 - mfd: whitespace fixes
 - mfd: describe sub-devices in Kconfig
 - mfd: add error print for invalid command
 - mfd: update copyright
 - mfd: use devm_of_platform_populate
 - mfd: use probe_new
 - mfd: move hwmon's regmap init to hwmon
 - hwmon: move hwmon's regmap init to hwmon
 - dt-bindings: add register to fan-controller node name

v7:
 - dt-bindings: change divider from mili-ohms to ohms
 - dt-bindings: add constraints for voltage divider and offset
 - dt-bindings: remove unnecessary ref for offset
 - dt-bindings: renamed fan to fan-controller and changed base prop to reg
 - mfd:  remove irq from private data struct
 - hwmon: fix whitespace in Kconfig
 - hwmon: remove unnecessary device pointer in private data
 - hwmon: change divider from mili-ohms to ohms
 - hwmon: move fan base property to reg

v6:
 - hwmon: fix size of info field
 - hwmon: improve pwm output control documentation
 - hwmon: include unit suffix in divider and offset
 - hwmon: change subnode name to gsc-adc
 - hwmon: change to fan subnode
 - hwmon: fix voltage offset
 - dt-bindings: fix commit message typo
 - dt-bindings: drop invalid description from #interrupt-cells property
 - dt-bindings: fix adc pattern property
 - dt-bindings: add unit suffix
 - dt-bindings: replace hwmon/adc with adc/channel
 - dt-bindings: changed adc type to gw,mode
 - dt-bindings: add unit suffix and drop ref for voltage-divider
 - dt-bindings: add unit suffix for voltage-offset
 - dt-bindings: moved fan to its own subnode with base register

v5:
 - fix checkpatch issues
 - fix dt_binding_check issues
 - address feedback from v4

v4:
 - hwmon: move to using pwm_auto_point_{pwm,temp} for FAN PWM
 - hwmon: remove unncessary resolution/scaling properties for ADCs
 - bindings: update to yaml Documentation
 - removed watchdog driver

v3:
 - removed unnecessary input driver
 - added wdt driver
 - bindings: encorporated feedback from mailng list
 - hwmon:
 - encoroprated feedback from mailng list
 - added support for raw ADC voltage input used in newer GSC firmware

v2:
 - change license comment block style
 - remove COMPILE_TEST
 - fixed whitespace issues
 - replaced a printk with dev_err
 - remove DEBUG
 - simplify regmap_bulk_read err check
 - remove break after returns in switch statement
 - fix fan setpoint buffer address
 - remove unnecessary parens
 - consistently use struct device *dev pointer
 - add validation for hwmon child node props
 - move parsing of of to own function
 - use strlcpy to ensure null termination
 - fix static array sizes and removed unnecessary initializers
 - dynamically allocate channels
 - fix fan input label
 - support platform data

Tim Harvey (3):
  dt-bindings: mfd: Add Gateworks System Controller bindings
  mfd: add Gateworks System Controller core driver
  hwmon: add Gateworks System Controller support

 .../devicetree/bindings/mfd/gateworks-gsc.yaml | 196 +++
 Documentation/hwmon/gsc-hwmon.rst  |  53 +++
 Documentation/hwmon/index.rst  |   1 +
 MAINTAINERS|  11 +
 drivers/hwmon/Kconfig  |   9 +
 drivers/hwmon/Makefile |   1 +
 drivers/hwmon/gsc-hwmon.c  | 390 +
 drivers/mfd/Kconfig|  15 +
 drivers/mfd/Makefile   |   1 +
 drivers/mfd

[PATCH v11 1/3] dt-bindings: mfd: Add Gateworks System Controller bindings

[Tim Harvey]

This patch adds documentation of device-tree bindings for the
Gateworks System Controller (GSC).

Signed-off-by: Tim Harvey 
Reviewed-by: Rob Herring 
---
v11:
 - no change

v10:
 - no change

v9:
 - added Reviewed-by: Rob Herring 
 - remove allOf: see https://lkml.org/lkml/2020/4/15/1930
 - encorporate Lee's review comments for item descriptions

v8:
 - add register to fan-controller node name

v7:
 - change divider from mili-ohms to ohms
 - add constraints for voltage divider and offset
 - remove unnecessary ref for offset
 - renamed fan to fan-controller and changed base prop to reg

v6:
 - fix typo
 - drop invalid description from #interrupt-cells property
 - fix adc pattern property
 - add unit suffix
 - replace hwmon/adc with adc/channel
 - changed adc type to mode and enum int
 - add unit suffix and drop ref for voltage-divider
 - moved fan to its own subnode with base register

v5:
 - resolve dt_binding_check issues

v4:
 - move to using pwm_auto_point_{pwm,temp} for FAN PWM
 - remove unncessary resolution/scaling properties for ADCs
 - update to yaml
 - remove watchdog

v3:
 - replaced _ with -
 - remove input bindings
 - added full description of hwmon
 - fix unit address of hwmon child nodes
---
 .../devicetree/bindings/mfd/gateworks-gsc.yaml | 196 +
 1 file changed, 196 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml

diff --git a/Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml 
b/Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml
new file mode 100644
index ..487a844
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml
@@ -0,0 +1,196 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/gateworks-gsc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Gateworks System Controller
+
+description: |
+  The Gateworks System Controller (GSC) is a device present across various
+  Gateworks product families that provides a set of system related features
+  such as the following (refer to the board hardware user manuals to see what
+  features are present)
+   - Watchdog Timer
+   - GPIO
+   - Pushbutton controller
+   - Hardware monitor with ADC's for temperature and voltage rails and
+ fan controller
+
+maintainers:
+  - Tim Harvey 
+  - Robert Jones 
+
+properties:
+  $nodename:
+pattern: "gsc@[0-9a-f]{1,2}"
+  compatible:
+const: gw,gsc
+
+  reg:
+description: I2C device address
+maxItems: 1
+
+  interrupts:
+maxItems: 1
+
+  interrupt-controller: true
+
+  "#interrupt-cells":
+const: 1
+
+  "#address-cells":
+const: 1
+
+  "#size-cells":
+const: 0
+
+  adc:
+type: object
+description: Optional hardware monitoring module
+
+properties:
+  compatible:
+const: gw,gsc-adc
+
+  "#address-cells":
+const: 1
+
+  "#size-cells":
+const: 0
+
+patternProperties:
+  "^channel@[0-9]+$":
+type: object
+description: |
+  Properties for a single ADC which can report cooked values
+  (i.e. temperature sensor based on thermister), raw values
+  (i.e. voltage rail with a pre-scaling resistor divider).
+
+properties:
+  reg:
+description: Register of the ADC
+maxItems: 1
+
+  label:
+description: Name of the ADC input
+
+  gw,mode:
+description: |
+  conversion mode:
+0 - temperature, in C*10
+1 - pre-scaled voltage value
+2 - scaled voltage based on an optional resistor divider
+and optional offset
+$ref: /schemas/types.yaml#/definitions/uint32
+enum: [0, 1, 2]
+
+  gw,voltage-divider-ohms:
+description: Values of resistors for divider on raw ADC input
+maxItems: 2
+items:
+ minimum: 1000
+ maximum: 100
+
+  gw,voltage-offset-microvolt:
+description: |
+  A positive voltage offset to apply to a raw ADC
+  (i.e. to compensate for a diode drop).
+minimum: 0
+maximum: 100
+
+required:
+  - gw,mode
+  - reg
+  - label
+
+required:
+  - compatible
+  - "#address-cells"
+  - "#size-cells"
+
+patternProperties:
+  "^fan-controller@[0-9a-f]+$":
+type: object
+description: Optional fan controller
+
+properties:
+  compatible:
+const: gw,gsc-fan
+
+  "#address-cells":
+const: 1
+
+  "#size-cells":
+const: 0
+
+  reg:
+description: The fan controller base address
+maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - "#address-c

[PATCH v10 2/3] mfd: add Gateworks System Controller core driver

[Tim Harvey]

The Gateworks System Controller (GSC) is an I2C slave controller
implemented with an MSP430 micro-controller whose firmware embeds the
following features:
 - I/O expander (16 GPIO's) using PCA955x protocol
 - Real Time Clock using DS1672 protocol
 - User EEPROM using AT24 protocol
 - HWMON using custom protocol
 - Interrupt controller with tamper detect, user pushbotton
 - Watchdog controller capable of full board power-cycle
 - Power Control capable of full board power-cycle

see http://trac.gateworks.com/wiki/gsc for more details

Signed-off-by: Tim Harvey 
Acked-for-MFD-by: Lee Jones 
---
v10:
- fix typo and gramatical errors in Kconfig and comment block
- drop unused i2c device-id table
- added Lee's ack in s-o-b

v9:
- rebase against 5.7-rc2
- cleanup gsc_powerdown() by using BIT(), put_unaligned_le32(), and avoid
  unnecessary assignments
- rename GSC_CTRL_1 SLEEP related defines to simplify
- add better description and sub-module info to driver description
- whitespace changes per review
- remove unused irq_data pointer in ddata
- remove unnecesary i2c_set_clientdata
- use devm_i2c_new_dummy_device to avoid need of free's
- change regsiter definitions to enum
- export gsc_{read,write} instead of sharing them via ddata

v8:
- whitespace fixes
- describe sub-devices in Kconfig
- add error print for invalid command
- update copyright
- use devm_of_platform_populate
- use probe_new
- move hwmon's regmap init to hwmon

v7:
- remove irq from private data struct

v6:
- remove duplicate signature and fix commit log

v5:
- simplify powerdown function

v4:
- remove hwmon max reg check/define
- fix powerdown function

v3:
- rename gsc->gateworks-gsc
- remove uncecessary include for linux/mfd/core.h
- upercase I2C in comments
- remove i2c debug
- remove uncecessary comments
- don't use KBUILD_MODNAME for name
- remove unnecessary v1/v2/v3 tracking
- unregister hwmon i2c adapter on remove

v2:
- change license comment block style
- remove COMPILE_TEST (Randy)
- fixed whitespace issues
- replaced a printk with dev_err
---
 MAINTAINERS |   8 ++
 drivers/mfd/Kconfig |  15 +++
 drivers/mfd/Makefile|   1 +
 drivers/mfd/gateworks-gsc.c | 278 
 include/linux/mfd/gsc.h |  76 
 5 files changed, 378 insertions(+)
 create mode 100644 drivers/mfd/gateworks-gsc.c
 create mode 100644 include/linux/mfd/gsc.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 091ec22..c78a014 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7028,6 +7028,14 @@ F:   kernel/futex.c
 F: tools/perf/bench/futex*
 F: tools/testing/selftests/futex/
 
+GATEWORKS SYSTEM CONTROLLER (GSC) DRIVER
+M:     Tim Harvey 
+M: Robert Jones 
+S: Maintained
+F: Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml
+F: drivers/mfd/gateworks-gsc.c
+F: include/linux/mfd/gsc.h
+
 GASKET DRIVER FRAMEWORK
 M: Rob Springer 
 M: Todd Poynor 
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 0a59249..05448e7 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -407,6 +407,21 @@ config MFD_EXYNOS_LPASS
  Select this option to enable support for Samsung Exynos Low Power
  Audio Subsystem.
 
+config MFD_GATEWORKS_GSC
+   tristate "Gateworks System Controller"
+   depends on (I2C && OF)
+   select MFD_CORE
+   select REGMAP_I2C
+   select REGMAP_IRQ
+   help
+ Enable support for the Gateworks System Controller (GSC) found
+ on Gateworks Single Board Computers supporting system functions
+ such as push-button monitor, multiple ADC's for voltage and
+ temperature monitoring, fan controller and watchdog monitor.
+ This driver provides common support for accessing the device.
+ Additional drivers must be enabled in order to use the
+ functionality of the device.
+
 config MFD_MC13XXX
tristate
depends on (SPI_MASTER || I2C)
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index f935d10..ed433ae 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_MFD_BCM590XX)+= bcm590xx.o
 obj-$(CONFIG_MFD_BD9571MWV)+= bd9571mwv.o
 obj-$(CONFIG_MFD_CROS_EC_DEV)  += cros_ec_dev.o
 obj-$(CONFIG_MFD_EXYNOS_LPASS) += exynos-lpass.o
+obj-$(CONFIG_MFD_GATEWORKS_GSC)+= gateworks-gsc.o
 
 obj-$(CONFIG_HTC_PASIC3)   += htc-pasic3.o
 obj-$(CONFIG_HTC_I2CPLD)   += htc-i2cpld.o
diff --git a/drivers/mfd/gateworks-gsc.c b/drivers/mfd/gateworks-gsc.c
new file mode 100644
index ..d43a4dd
--- /dev/null
+++ b/drivers/mfd/gateworks-gsc.c
@@ -0,0 +1,278 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * The Gateworks System Controller (GSC) is a multi-function
+ * device designed for use in Gateworks Single Board Computers.
+ * The control interface is I2C, with an interrupt. The device supports
+ * system functions such as push-button monitoring, multiple 

[PATCH v10 0/3] Add support for the Gateworks System Controller

[Tim Harvey]

This series adds support for the Gateworks System Controller used on Gateworks
Laguna, Ventana, and Newport product families.

The GSC is an MSP430 I2C slave controller whose firmware embeds the following
features:
 - I/O expander (16 GPIO's emulating a PCA955x)
 - EEPROM (enumating AT24)
 - RTC (enumating DS1672)
 - HWMON
 - Interrupt controller with tamper detect, user pushbotton
 - Watchdog controller capable of full board power-cycle
 - Power Control capable of full board power-cycle

see http://trac.gateworks.com/wiki/gsc for more details

v10:
 - mfd: fix typo and gramatical errors in Kconfig and comment block
 - mfd: drop unused i2c device-id table
 - mfd: added Lee's ack in s-o-b

v9:
 - rebase against 5.7-rc2
 - dt-binding: remove allOf: see https://lkml.org/lkml/2020/4/15/1930
 - dt-binding: encorporate Lee's review comments for item descriptions
 - dt-binding: added Reviewed-by: Rob Herring 
 - mfd: cleanup gsc_powerdown() by using BIT(), put_unaligned_le32(), and
   avoid unnecessary assignments
 - mfd: rename GSC_CTRL_1 SLEEP related defines to simplify
 - mfd: add better description and sub-module info to driver description
 - mfd: whitespace changes per review
 - mfd: remove unused irq_data pointer in ddata
 - mfd: remove unnecesary i2c_set_clientdata
 - mfd: use devm_i2c_new_dummy_device to avoid need of free's
 - mfd: change regsiter definitions to enum
 - mfd: export gsc_{read,write} instead of sharing them via ddata
 - hwmon: use exported gsc_{read,write}
 - hwmon: added Reviewed-by: Guenter Roeck 


v8:
 - mfd: whitespace fixes
 - mfd: describe sub-devices in Kconfig
 - mfd: add error print for invalid command
 - mfd: update copyright
 - mfd: use devm_of_platform_populate
 - mfd: use probe_new
 - mfd: move hwmon's regmap init to hwmon
 - hwmon: move hwmon's regmap init to hwmon
 - dt-bindings: add register to fan-controller node name

v7:
 - dt-bindings: change divider from mili-ohms to ohms
 - dt-bindings: add constraints for voltage divider and offset
 - dt-bindings: remove unnecessary ref for offset
 - dt-bindings: renamed fan to fan-controller and changed base prop to reg
 - mfd:  remove irq from private data struct
 - hwmon: fix whitespace in Kconfig
 - hwmon: remove unnecessary device pointer in private data
 - hwmon: change divider from mili-ohms to ohms
 - hwmon: move fan base property to reg

v6:
 - hwmon: fix size of info field
 - hwmon: improve pwm output control documentation
 - hwmon: include unit suffix in divider and offset
 - hwmon: change subnode name to gsc-adc
 - hwmon: change to fan subnode
 - hwmon: fix voltage offset
 - dt-bindings: fix commit message typo
 - dt-bindings: drop invalid description from #interrupt-cells property
 - dt-bindings: fix adc pattern property
 - dt-bindings: add unit suffix
 - dt-bindings: replace hwmon/adc with adc/channel
 - dt-bindings: changed adc type to gw,mode
 - dt-bindings: add unit suffix and drop ref for voltage-divider
 - dt-bindings: add unit suffix for voltage-offset
 - dt-bindings: moved fan to its own subnode with base register

v5:
 - fix checkpatch issues
 - fix dt_binding_check issues
 - address feedback from v4

v4:
 - hwmon: move to using pwm_auto_point_{pwm,temp} for FAN PWM
 - hwmon: remove unncessary resolution/scaling properties for ADCs
 - bindings: update to yaml Documentation
 - removed watchdog driver

v3:
 - removed unnecessary input driver
 - added wdt driver
 - bindings: encorporated feedback from mailng list
 - hwmon:
 - encoroprated feedback from mailng list
 - added support for raw ADC voltage input used in newer GSC firmware

v2:
 - change license comment block style
 - remove COMPILE_TEST
 - fixed whitespace issues
 - replaced a printk with dev_err
 - remove DEBUG
 - simplify regmap_bulk_read err check
 - remove break after returns in switch statement
 - fix fan setpoint buffer address
 - remove unnecessary parens
 - consistently use struct device *dev pointer
 - add validation for hwmon child node props
 - move parsing of of to own function
 - use strlcpy to ensure null termination
 - fix static array sizes and removed unnecessary initializers
 - dynamically allocate channels
 - fix fan input label
 - support platform data

Tim Harvey (3):
  dt-bindings: mfd: Add Gateworks System Controller bindings
  mfd: add Gateworks System Controller core driver
  hwmon: add Gateworks System Controller support

 .../devicetree/bindings/mfd/gateworks-gsc.yaml | 196 +++
 Documentation/hwmon/gsc-hwmon.rst  |  53 +++
 Documentation/hwmon/index.rst  |   1 +
 MAINTAINERS|  11 +
 drivers/hwmon/Kconfig  |   9 +
 drivers/hwmon/Makefile |   1 +
 drivers/hwmon/gsc-hwmon.c  | 390 +
 drivers/mfd/Kconfig|  15 +
 drivers/mfd/Makefile   |   1 +
 drivers/mfd/gateworks-gsc.c

[PATCH v10 1/3] dt-bindings: mfd: Add Gateworks System Controller bindings

[Tim Harvey]

This patch adds documentation of device-tree bindings for the
Gateworks System Controller (GSC).

Signed-off-by: Tim Harvey 
Reviewed-by: Rob Herring 
---
v10:
 - no changes

v9:
 - added Reviewed-by: Rob Herring 
 - remove allOf: see https://lkml.org/lkml/2020/4/15/1930
 - encorporate Lee's review comments for item descriptions

v8:
 - add register to fan-controller node name

v7:
 - change divider from mili-ohms to ohms
 - add constraints for voltage divider and offset
 - remove unnecessary ref for offset
 - renamed fan to fan-controller and changed base prop to reg

v6:
 - fix typo
 - drop invalid description from #interrupt-cells property
 - fix adc pattern property
 - add unit suffix
 - replace hwmon/adc with adc/channel
 - changed adc type to mode and enum int
 - add unit suffix and drop ref for voltage-divider
 - moved fan to its own subnode with base register

v5:
 - resolve dt_binding_check issues

v4:
 - move to using pwm_auto_point_{pwm,temp} for FAN PWM
 - remove unncessary resolution/scaling properties for ADCs
 - update to yaml
 - remove watchdog

v3:
 - replaced _ with -
 - remove input bindings
 - added full description of hwmon
 - fix unit address of hwmon child nodes
---
 .../devicetree/bindings/mfd/gateworks-gsc.yaml | 196 +
 1 file changed, 196 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml

diff --git a/Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml 
b/Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml
new file mode 100644
index ..487a844
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml
@@ -0,0 +1,196 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/gateworks-gsc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Gateworks System Controller
+
+description: |
+  The Gateworks System Controller (GSC) is a device present across various
+  Gateworks product families that provides a set of system related features
+  such as the following (refer to the board hardware user manuals to see what
+  features are present)
+   - Watchdog Timer
+   - GPIO
+   - Pushbutton controller
+   - Hardware monitor with ADC's for temperature and voltage rails and
+ fan controller
+
+maintainers:
+  - Tim Harvey 
+  - Robert Jones 
+
+properties:
+  $nodename:
+pattern: "gsc@[0-9a-f]{1,2}"
+  compatible:
+const: gw,gsc
+
+  reg:
+description: I2C device address
+maxItems: 1
+
+  interrupts:
+maxItems: 1
+
+  interrupt-controller: true
+
+  "#interrupt-cells":
+const: 1
+
+  "#address-cells":
+const: 1
+
+  "#size-cells":
+const: 0
+
+  adc:
+type: object
+description: Optional hardware monitoring module
+
+properties:
+  compatible:
+const: gw,gsc-adc
+
+  "#address-cells":
+const: 1
+
+  "#size-cells":
+const: 0
+
+patternProperties:
+  "^channel@[0-9]+$":
+type: object
+description: |
+  Properties for a single ADC which can report cooked values
+  (i.e. temperature sensor based on thermister), raw values
+  (i.e. voltage rail with a pre-scaling resistor divider).
+
+properties:
+  reg:
+description: Register of the ADC
+maxItems: 1
+
+  label:
+description: Name of the ADC input
+
+  gw,mode:
+description: |
+  conversion mode:
+0 - temperature, in C*10
+1 - pre-scaled voltage value
+2 - scaled voltage based on an optional resistor divider
+and optional offset
+$ref: /schemas/types.yaml#/definitions/uint32
+enum: [0, 1, 2]
+
+  gw,voltage-divider-ohms:
+description: Values of resistors for divider on raw ADC input
+maxItems: 2
+items:
+ minimum: 1000
+ maximum: 100
+
+  gw,voltage-offset-microvolt:
+description: |
+  A positive voltage offset to apply to a raw ADC
+  (i.e. to compensate for a diode drop).
+minimum: 0
+maximum: 100
+
+required:
+  - gw,mode
+  - reg
+  - label
+
+required:
+  - compatible
+  - "#address-cells"
+  - "#size-cells"
+
+patternProperties:
+  "^fan-controller@[0-9a-f]+$":
+type: object
+description: Optional fan controller
+
+properties:
+  compatible:
+const: gw,gsc-fan
+
+  "#address-cells":
+const: 1
+
+  "#size-cells":
+const: 0
+
+  reg:
+description: The fan controller base address
+maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - "#address-cells&q

[PATCH v10 3/3] hwmon: add Gateworks System Controller support

[Tim Harvey]

The Gateworks System Controller has a hwmon sub-component that exposes
up to 16 ADC's, some of which are temperature sensors, others which are
voltage inputs. The ADC configuration (register mapping and name) is
configured via device-tree and varies board to board.

Signed-off-by: Tim Harvey 
Reviewed-by: Guenter Roeck 
---
v10:
- no changes

v9:
- use exported gsc_{read,write}
- added Reviewed-by: Guenter Roeck 

v8:
- move regmap init to hwmon

v7:
- fix whitespace in Kconfig
- remove unnecessary device pointer in private data
- change divider from mili-ohms to ohms
- move fan base property to reg

v6:
- fix size of info field
- improve pwm output control documentation
- include unit suffix in divider and offset
- change subnode name to gsc-adc
- change to fan subnode
- fix voltage offset

v5:
- fix various checkpatch issues
- correct gsc-hwmon.rst in MAINTAINERS
- encorporate Gunter's feedback:
 - switch to SENSOR_DEVICE_ATTR_{RW,RO}
 - use tmp value to avoid excessive pointer deference
 - simplify shift operation
 - scale voffset once
 - simplify is_visible function
 - remove empty line at end of file

v4:
- adjust for uV offset from device-tree
- remove unnecessary optional write function
- remove register range check
- change dev_err prints to use gsc dev
- hard-code resolution/scaling for raw adcs
- describe units of ADC resolution
- move to using pwm_auto_point_{pwm,temp} for FAN PWM
- ensure space before/after operators
- remove unnecessary parens
- remove more debugging
- add default case and comment for type_voltage
- remove unnecessary index bounds checks for channel
- remove unnecessary clearing of struct fields
- added Documentation/hwmon/gsc-hwmon.rst

v3:
- add voltage_raw input type and supporting fields
- add channel validation to is_visible function
- remove unnecessary channel validation from read/write functions

v2:
- change license comment style
- remove DEBUG
- simplify regmap_bulk_read err check
- remove break after returns in switch statement
- fix fan setpoint buffer address
- remove unnecessary parens
- consistently use struct device *dev pointer
- change license/comment block
- add validation for hwmon child node props
- move parsing of of to own function
- use strlcpy to ensure null termination
- fix static array sizes and removed unnecessary initializers
- dynamically allocate channels
- fix fan input label
- support platform data
- fixed whitespace issues
---
 Documentation/hwmon/gsc-hwmon.rst   |  53 +
 Documentation/hwmon/index.rst   |   1 +
 MAINTAINERS |   3 +
 drivers/hwmon/Kconfig   |   9 +
 drivers/hwmon/Makefile  |   1 +
 drivers/hwmon/gsc-hwmon.c   | 390 
 include/linux/platform_data/gsc_hwmon.h |  44 
 7 files changed, 501 insertions(+)
 create mode 100644 Documentation/hwmon/gsc-hwmon.rst
 create mode 100644 drivers/hwmon/gsc-hwmon.c
 create mode 100644 include/linux/platform_data/gsc_hwmon.h

diff --git a/Documentation/hwmon/gsc-hwmon.rst 
b/Documentation/hwmon/gsc-hwmon.rst
new file mode 100644
index ..ffac392
--- /dev/null
+++ b/Documentation/hwmon/gsc-hwmon.rst
@@ -0,0 +1,53 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Kernel driver gsc-hwmon
+===
+
+Supported chips: Gateworks GSC
+Datasheet: http://trac.gateworks.com/wiki/gsc
+Author: Tim Harvey 
+
+Description:
+
+
+This driver supports hardware monitoring for the temperature sensor,
+various ADC's connected to the GSC, and optional FAN controller available
+on some boards.
+
+
+Voltage Monitoring
+--
+
+The voltage inputs are scaled either internally or by the driver depending
+on the GSC version and firmware. The values returned by the driver do not need
+further scaling. The voltage input labels provide the voltage rail name:
+
+inX_input  Measured voltage (mV).
+inX_label  Name of voltage rail.
+
+
+Temperature Monitoring
+--
+
+Temperatures are measured with 12-bit or 10-bit resolution and are scaled
+either internally or by the driver depending on the GSC version and firmware.
+The values returned by the driver reflect millidegree Celcius:
+
+tempX_inputMeasured temperature.
+tempX_labelName of temperature input.
+
+
+PWM Output Control
+--
+
+The GSC features 1 PWM output that operates in automatic mode where the
+PWM value will be scalled depending on 6 temperature boundaries.
+The tempeature boundaries are read-write and in millidegree Celcius and the
+read-only PWM values range from 0 (off) to 255 (full speed).
+Fan speed will be set to minimum (off) when the temperature sensor reads
+less than pwm1_auto_point1_temp and maximum when the temperature sensor
+equals or exceeds pwm1_auto_point6_temp.
+
+pwm1_auto_point[1-6]_pwm   PWM value.
+pwm1_auto_point[1-6]_temp  Temperature boundary.
+
diff --git a/Documentation

[PATCH] ARM: dts: imx6qdl-gw5910: fix wlan regulator

[Tim Harvey]

Connect the wl_reg regulator to usdhc2 such that it can be enabled
and disabled as needed. There is no need for this to be always-on.

Signed-off-by: Tim Harvey 
---
 arch/arm/boot/dts/imx6qdl-gw5910.dtsi | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/imx6qdl-gw5910.dtsi 
b/arch/arm/boot/dts/imx6qdl-gw5910.dtsi
index b850f8f..0857de5 100644
--- a/arch/arm/boot/dts/imx6qdl-gw5910.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw5910.dtsi
@@ -81,7 +81,6 @@
enable-active-high;
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
-   regulator-always-on;
};
 };
 
@@ -251,7 +250,7 @@
  {
pinctrl-names = "default";
pinctrl-0 = <_usdhc2>;
-   vmmc-supply = <_3p3v>;
+   vmmc-supply = <_wl>;
non-removable;
bus-width = <4>;
status = "okay";
-- 
2.7.4

[PATCH] ARM: dts: imx6qdl-gw5910: add support for bcm4330-bt

[Tim Harvey]

The Sterling-LWB has a BCM4330 which has a UART based bluetooth
HCI. Add support for binding to the bcm_hci driver to take care
of handling the shutdown gpio and loading firmware.

Because the shutdown gpio is more of an enable than a regulator
go ahead and replace the regulator with a shutdown-gpio.

Signed-off-by: Tim Harvey 
---
 arch/arm/boot/dts/imx6qdl-gw5910.dtsi | 32 
 1 file changed, 12 insertions(+), 20 deletions(-)

diff --git a/arch/arm/boot/dts/imx6qdl-gw5910.dtsi 
b/arch/arm/boot/dts/imx6qdl-gw5910.dtsi
index 30fe47f..b850f8f 100644
--- a/arch/arm/boot/dts/imx6qdl-gw5910.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw5910.dtsi
@@ -83,19 +83,6 @@
regulator-max-microvolt = <330>;
regulator-always-on;
};
-
-   reg_bt: regulator-bt {
-   pinctrl-names = "default";
-   pinctrl-0 = <_reg_bt>;
-   compatible = "regulator-fixed";
-   regulator-name = "bt";
-   gpio = < 2 GPIO_ACTIVE_HIGH>;
-   startup-delay-us = <100>;
-   enable-active-high;
-   regulator-min-microvolt = <330>;
-   regulator-max-microvolt = <330>;
-   regulator-always-on;
-   };
 };
 
 
@@ -231,9 +218,14 @@
 /* Sterling-LWB Bluetooth */
  {
pinctrl-names = "default";
-   pinctrl-0 = <_uart4>;
+   pinctrl-0 = <_uart4>,<_bten>;
uart-has-rtscts;
status = "okay";
+
+   bluetooth {
+   compatible = "brcm,bcm4330-bt";
+   shutdown-gpios = < 2 GPIO_ACTIVE_HIGH>;
+   };
 };
 
 /* GPS */
@@ -288,6 +280,12 @@
>;
};
 
+   pinctrl_bten: btengrp {
+   fsl,pins = <
+   MX6QDL_PAD_GPIO_2__GPIO1_IO02   0x1b0b1
+   >;
+   };
+
pinctrl_ecspi3: escpi3grp {
fsl,pins = <
MX6QDL_PAD_DISP0_DAT0__ECSPI3_SCLK  0x100b1
@@ -393,12 +391,6 @@
>;
};
 
-   pinctrl_reg_bt: regbtgrp {
-   fsl,pins = <
-   MX6QDL_PAD_GPIO_2__GPIO1_IO02   0x1b0b1
-   >;
-   };
-
pinctrl_reg_wl: regwlgrp {
fsl,pins = <
MX6QDL_PAD_GPIO_5__GPIO1_IO05   0x1b0b1
-- 
2.7.4

[PATCH] ARM: dts: imx6qdl-gw5904: add lsm9ds1 iio imu/magn support

[Tim Harvey]

Add one node for the accel/gyro i2c device and another for the separate
magnetometer device in the lsm9ds1.

Signed-off-by: Tim Harvey 
---
 arch/arm/boot/dts/imx6qdl-gw5904.dtsi | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl-gw5904.dtsi 
b/arch/arm/boot/dts/imx6qdl-gw5904.dtsi
index 6d21cc6..76d6cf5 100644
--- a/arch/arm/boot/dts/imx6qdl-gw5904.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw5904.dtsi
@@ -248,6 +248,15 @@
pinctrl-0 = <_i2c2>;
status = "okay";
 
+   magn@1c {
+   compatible = "st,lsm9ds1-magn";
+   reg = <0x1c>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_mag>;
+   interrupt-parent = <>;
+   interrupts = <17 IRQ_TYPE_EDGE_RISING>;
+   };
+
ltc3676: pmic@3c {
compatible = "lltc,ltc3676";
reg = <0x3c>;
@@ -320,6 +329,16 @@
};
};
};
+
+   imu@6a {
+   compatible = "st,lsm9ds1-imu";
+   reg = <0x6a>;
+   st,drdy-int-pin = <1>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_imu>;
+   interrupt-parent = <>;
+   interrupts = <18 IRQ_TYPE_LEVEL_HIGH>;
+   };
 };
 
  {
@@ -501,6 +520,18 @@
>;
};
 
+   pinctrl_imu: imugrp {
+   fsl,pins = <
+   MX6QDL_PAD_DI0_PIN2__GPIO4_IO18 0x1b0b0
+   >;
+   };
+
+   pinctrl_mag: maggrp {
+   fsl,pins = <
+   MX6QDL_PAD_DISP0_DAT23__GPIO5_IO17  0x1b0b0
+   >;
+   };
+
pinctrl_pcie: pciegrp {
fsl,pins = <
MX6QDL_PAD_GPIO_0__GPIO1_IO00   0x1b0b0 /* PCIE RST */
-- 
2.7.4

[PATCH] ARM: dts: imx6qdl-gw560x: add lsm9ds1 iio imu/magn support

[Tim Harvey]

Add one node for the accel/gyro i2c device and another for the separate
magnetometer device in the lsm9ds1.

Signed-off-by: Tim Harvey 
---
 arch/arm/boot/dts/imx6qdl-gw560x.dtsi | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl-gw560x.dtsi 
b/arch/arm/boot/dts/imx6qdl-gw560x.dtsi
index e8e36df..69ca70d 100644
--- a/arch/arm/boot/dts/imx6qdl-gw560x.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw560x.dtsi
@@ -295,6 +295,15 @@
VDDIO-supply = <_3p3v>;
};
 
+   magn@1c {
+   compatible = "st,lsm9ds1-magn";
+   reg = <0x1c>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_mag>;
+   interrupt-parent = <>;
+   interrupts = <9 IRQ_TYPE_EDGE_RISING>;
+   };
+
tca8418: keypad@34 {
compatible = "ti,tca8418";
pinctrl-names = "default";
@@ -389,6 +398,16 @@
};
};
};
+
+   imu@6a {
+   compatible = "st,lsm9ds1-imu";
+   reg = <0x6a>;
+   st,drdy-int-pin = <1>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_imu>;
+   interrupt-parent = <>;
+   interrupts = <6 IRQ_TYPE_LEVEL_HIGH>;
+   };
 };
 
  {
@@ -609,6 +628,12 @@
>;
};
 
+   pinctrl_imu: imugrp {
+   fsl,pins = <
+   MX6QDL_PAD_DISP0_DAT12__GPIO5_IO06  0x1b0b0
+   >;
+   };
+
pinctrl_keypad: keypadgrp {
fsl,pins = <
MX6QDL_PAD_DISP0_DAT17__GPIO5_IO11  0x0001b0b0 /* 
KEYPAD_IRQ# */
@@ -616,6 +641,12 @@
>;
};
 
+   pinctrl_mag: maggrp {
+   fsl,pins = <
+   MX6QDL_PAD_DISP0_DAT15__GPIO5_IO09  0x1b0b0
+   >;
+   };
+
pinctrl_pcie: pciegrp {
fsl,pins = <
MX6QDL_PAD_DISP0_DAT10__GPIO4_IO31  0x1b0b0/* 
PCI_RST# */
-- 
2.7.4

[PATCH v9 2/3] mfd: add Gateworks System Controller core driver

[Tim Harvey]

The Gateworks System Controller (GSC) is an I2C slave controller
implemented with an MSP430 micro-controller whose firmware embeds the
following features:
 - I/O expander (16 GPIO's) using PCA955x protocol
 - Real Time Clock using DS1672 protocol
 - User EEPROM using AT24 protocol
 - HWMON using custom protocol
 - Interrupt controller with tamper detect, user pushbotton
 - Watchdog controller capable of full board power-cycle
 - Power Control capable of full board power-cycle

see http://trac.gateworks.com/wiki/gsc for more details

Signed-off-by: Tim Harvey 
---
v9:
- rebase against 5.7-rc2
- cleanup gsc_powerdown() by using BIT(), put_unaligned_le32(), and avoid
  unnecessary assignments
- rename GSC_CTRL_1 SLEEP related defines to simplify
- add better description and sub-module info to driver description
- whitespace changes per review
- remove unused irq_data pointer in ddata
- remove unnecesary i2c_set_clientdata
- use devm_i2c_new_dummy_device to avoid need of free's
- change regsiter definitions to enum
- export gsc_{read,write} instead of sharing them via ddata

v8:
- whitespace fixes
- describe sub-devices in Kconfig
- add error print for invalid command
- update copyright
- use devm_of_platform_populate
- use probe_new
- move hwmon's regmap init to hwmon

v7:
- remove irq from private data struct

v6:
- remove duplicate signature and fix commit log

v5:
- simplify powerdown function

v4:
- remove hwmon max reg check/define
- fix powerdown function

v3:
- rename gsc->gateworks-gsc
- remove uncecessary include for linux/mfd/core.h
- upercase I2C in comments
- remove i2c debug
- remove uncecessary comments
- don't use KBUILD_MODNAME for name
- remove unnecessary v1/v2/v3 tracking
- unregister hwmon i2c adapter on remove

v2:
- change license comment block style
- remove COMPILE_TEST (Randy)
- fixed whitespace issues
- replaced a printk with dev_err
---
 MAINTAINERS |   8 ++
 drivers/mfd/Kconfig |  16 +++
 drivers/mfd/Makefile|   1 +
 drivers/mfd/gateworks-gsc.c | 284 
 include/linux/mfd/gsc.h |  76 
 5 files changed, 385 insertions(+)
 create mode 100644 drivers/mfd/gateworks-gsc.c
 create mode 100644 include/linux/mfd/gsc.h

diff --git a/MAINTAINERS b/MAINTAINERS
index b816a45..035dfb9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7032,6 +7032,14 @@ F:   kernel/futex.c
 F: tools/perf/bench/futex*
 F: tools/testing/selftests/futex/
 
+GATEWORKS SYSTEM CONTROLLER (GSC) DRIVER
+M:     Tim Harvey 
+M: Robert Jones 
+S: Maintained
+F: Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml
+F: drivers/mfd/gateworks-gsc.c
+F: include/linux/mfd/gsc.h
+
 GASKET DRIVER FRAMEWORK
 M: Rob Springer 
 M: Todd Poynor 
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 0a59249..d7546cd 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -407,6 +407,22 @@ config MFD_EXYNOS_LPASS
  Select this option to enable support for Samsung Exynos Low Power
  Audio Subsystem.
 
+config MFD_GATEWORKS_GSC
+   tristate "Gateworks System Controller"
+   depends on (I2C && OF)
+   select MFD_CORE
+   select REGMAP_I2C
+   select REGMAP_IRQ
+   help
+ Enable support for the Gateworks System Controller (GSC) found
+ on Gateworks Single Board Computers supporting system system
+ functions such as pushbutton monitor, multiple ADC's for voltage
+ and temperature, fan controller, and watchdog monitor. This
+ driver provides common support for accessing the device and
+ additional drivers must be enabled in order to use the
+ functionality of the device:
+   gsc-hwmon for ADC readings and fan controller support
+
 config MFD_MC13XXX
tristate
depends on (SPI_MASTER || I2C)
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index f935d10..ed433ae 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_MFD_BCM590XX)+= bcm590xx.o
 obj-$(CONFIG_MFD_BD9571MWV)+= bd9571mwv.o
 obj-$(CONFIG_MFD_CROS_EC_DEV)  += cros_ec_dev.o
 obj-$(CONFIG_MFD_EXYNOS_LPASS) += exynos-lpass.o
+obj-$(CONFIG_MFD_GATEWORKS_GSC)+= gateworks-gsc.o
 
 obj-$(CONFIG_HTC_PASIC3)   += htc-pasic3.o
 obj-$(CONFIG_HTC_I2CPLD)   += htc-i2cpld.o
diff --git a/drivers/mfd/gateworks-gsc.c b/drivers/mfd/gateworks-gsc.c
new file mode 100644
index ..796effb
--- /dev/null
+++ b/drivers/mfd/gateworks-gsc.c
@@ -0,0 +1,284 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * The Gateworks System Controller (GSC) is a multi-function
+ * device designed for use in Gateworks Single Board Computers.
+ * The control interface is I2C, with an interrupt. The device supports
+ * system functions such as pushbutton monitoring, multiple ADC's for
+ * voltage and temperature, fan controller, and watchdog monitor.
+ *
+ * Copyrig

[PATCH v9 1/3] dt-bindings: mfd: Add Gateworks System Controller bindings

[Tim Harvey]

This patch adds documentation of device-tree bindings for the
Gateworks System Controller (GSC).

Signed-off-by: Tim Harvey 
Reviewed-by: Rob Herring 
---
v9:
 - added Reviewed-by: Rob Herring 
 - remove allOf: see https://lkml.org/lkml/2020/4/15/1930
 - encorporate Lee's review comments for item descriptions

v8:
 - add register to fan-controller node name

v7:
 - change divider from mili-ohms to ohms
 - add constraints for voltage divider and offset
 - remove unnecessary ref for offset
 - renamed fan to fan-controller and changed base prop to reg

v6:
 - fix typo
 - drop invalid description from #interrupt-cells property
 - fix adc pattern property
 - add unit suffix
 - replace hwmon/adc with adc/channel
 - changed adc type to mode and enum int
 - add unit suffix and drop ref for voltage-divider
 - moved fan to its own subnode with base register

v5:
 - resolve dt_binding_check issues

v4:
 - move to using pwm_auto_point_{pwm,temp} for FAN PWM
 - remove unncessary resolution/scaling properties for ADCs
 - update to yaml
 - remove watchdog

v3:
 - replaced _ with -
 - remove input bindings
 - added full description of hwmon
 - fix unit address of hwmon child nodes
---
 .../devicetree/bindings/mfd/gateworks-gsc.yaml | 196 +
 1 file changed, 196 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml

diff --git a/Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml 
b/Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml
new file mode 100644
index ..487a844
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml
@@ -0,0 +1,196 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/gateworks-gsc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Gateworks System Controller
+
+description: |
+  The Gateworks System Controller (GSC) is a device present across various
+  Gateworks product families that provides a set of system related features
+  such as the following (refer to the board hardware user manuals to see what
+  features are present)
+   - Watchdog Timer
+   - GPIO
+   - Pushbutton controller
+   - Hardware monitor with ADC's for temperature and voltage rails and
+ fan controller
+
+maintainers:
+  - Tim Harvey 
+  - Robert Jones 
+
+properties:
+  $nodename:
+pattern: "gsc@[0-9a-f]{1,2}"
+  compatible:
+const: gw,gsc
+
+  reg:
+description: I2C device address
+maxItems: 1
+
+  interrupts:
+maxItems: 1
+
+  interrupt-controller: true
+
+  "#interrupt-cells":
+const: 1
+
+  "#address-cells":
+const: 1
+
+  "#size-cells":
+const: 0
+
+  adc:
+type: object
+description: Optional hardware monitoring module
+
+properties:
+  compatible:
+const: gw,gsc-adc
+
+  "#address-cells":
+const: 1
+
+  "#size-cells":
+const: 0
+
+patternProperties:
+  "^channel@[0-9]+$":
+type: object
+description: |
+  Properties for a single ADC which can report cooked values
+  (i.e. temperature sensor based on thermister), raw values
+  (i.e. voltage rail with a pre-scaling resistor divider).
+
+properties:
+  reg:
+description: Register of the ADC
+maxItems: 1
+
+  label:
+description: Name of the ADC input
+
+  gw,mode:
+description: |
+  conversion mode:
+0 - temperature, in C*10
+1 - pre-scaled voltage value
+2 - scaled voltage based on an optional resistor divider
+and optional offset
+$ref: /schemas/types.yaml#/definitions/uint32
+enum: [0, 1, 2]
+
+  gw,voltage-divider-ohms:
+description: Values of resistors for divider on raw ADC input
+maxItems: 2
+items:
+ minimum: 1000
+ maximum: 100
+
+  gw,voltage-offset-microvolt:
+description: |
+  A positive voltage offset to apply to a raw ADC
+  (i.e. to compensate for a diode drop).
+minimum: 0
+maximum: 100
+
+required:
+  - gw,mode
+  - reg
+  - label
+
+required:
+  - compatible
+  - "#address-cells"
+  - "#size-cells"
+
+patternProperties:
+  "^fan-controller@[0-9a-f]+$":
+type: object
+description: Optional fan controller
+
+properties:
+  compatible:
+const: gw,gsc-fan
+
+  "#address-cells":
+const: 1
+
+  "#size-cells":
+const: 0
+
+  reg:
+description: The fan controller base address
+maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - "#address-cells"
+  - "#s

[PATCH v9 0/3] Add support for the Gateworks System Controller

[Tim Harvey]

This series adds support for the Gateworks System Controller used on Gateworks
Laguna, Ventana, and Newport product families.

The GSC is an MSP430 I2C slave controller whose firmware embeds the following
features:
 - I/O expander (16 GPIO's emulating a PCA955x)
 - EEPROM (enumating AT24)
 - RTC (enumating DS1672)
 - HWMON
 - Interrupt controller with tamper detect, user pushbotton
 - Watchdog controller capable of full board power-cycle
 - Power Control capable of full board power-cycle

see http://trac.gateworks.com/wiki/gsc for more details
---
v9:
 - rebase against 5.7-rc2
 - dt-binding: remove allOf: see https://lkml.org/lkml/2020/4/15/1930
 - dt-binding: encorporate Lee's review comments for item descriptions
 - dt-binding: added Reviewed-by: Rob Herring 
 - mfd: cleanup gsc_powerdown() by using BIT(), put_unaligned_le32(), and
   avoid unnecessary assignments
 - mfd: rename GSC_CTRL_1 SLEEP related defines to simplify
 - mfd: add better description and sub-module info to driver description
 - mfd: whitespace changes per review
 - mfd: remove unused irq_data pointer in ddata
 - mfd: remove unnecesary i2c_set_clientdata
 - mfd: use devm_i2c_new_dummy_device to avoid need of free's
 - mfd: change regsiter definitions to enum
 - mfd: export gsc_{read,write} instead of sharing them via ddata
 - hwmon: use exported gsc_{read,write}
 - hwmon: added Reviewed-by: Guenter Roeck 

 
v8:
 - mfd: whitespace fixes
 - mfd: describe sub-devices in Kconfig
 - mfd: add error print for invalid command
 - mfd: update copyright
 - mfd: use devm_of_platform_populate
 - mfd: use probe_new
 - mfd: move hwmon's regmap init to hwmon
 - hwmon: move hwmon's regmap init to hwmon
 - dt-bindings: add register to fan-controller node name

v7:
 - dt-bindings: change divider from mili-ohms to ohms
 - dt-bindings: add constraints for voltage divider and offset
 - dt-bindings: remove unnecessary ref for offset
 - dt-bindings: renamed fan to fan-controller and changed base prop to reg
 - mfd:  remove irq from private data struct
 - hwmon: fix whitespace in Kconfig
 - hwmon: remove unnecessary device pointer in private data
 - hwmon: change divider from mili-ohms to ohms
 - hwmon: move fan base property to reg

v6:
 - hwmon: fix size of info field
 - hwmon: improve pwm output control documentation
 - hwmon: include unit suffix in divider and offset
 - hwmon: change subnode name to gsc-adc
 - hwmon: change to fan subnode
 - hwmon: fix voltage offset
 - dt-bindings: fix commit message typo
 - dt-bindings: drop invalid description from #interrupt-cells property
 - dt-bindings: fix adc pattern property
 - dt-bindings: add unit suffix
 - dt-bindings: replace hwmon/adc with adc/channel
 - dt-bindings: changed adc type to gw,mode
 - dt-bindings: add unit suffix and drop ref for voltage-divider
 - dt-bindings: add unit suffix for voltage-offset
 - dt-bindings: moved fan to its own subnode with base register

v5:
 - fix checkpatch issues
 - fix dt_binding_check issues
 - address feedback from v4

v4:
 - hwmon: move to using pwm_auto_point_{pwm,temp} for FAN PWM
 - hwmon: remove unncessary resolution/scaling properties for ADCs
 - bindings: update to yaml Documentation
 - removed watchdog driver

v3:
 - removed unnecessary input driver
 - added wdt driver
 - bindings: encorporated feedback from mailng list
 - hwmon:
 - encoroprated feedback from mailng list
 - added support for raw ADC voltage input used in newer GSC firmware

v2:
 - change license comment block style
 - remove COMPILE_TEST
 - fixed whitespace issues
 - replaced a printk with dev_err
 - remove DEBUG
 - simplify regmap_bulk_read err check
 - remove break after returns in switch statement
 - fix fan setpoint buffer address
 - remove unnecessary parens
 - consistently use struct device *dev pointer
 - add validation for hwmon child node props
 - move parsing of of to own function
 - use strlcpy to ensure null termination
 - fix static array sizes and removed unnecessary initializers
 - dynamically allocate channels
 - fix fan input label
 - support platform data

Tim Harvey (3):
  dt-bindings: mfd: Add Gateworks System Controller bindings
  mfd: add Gateworks System Controller core driver
  hwmon: add Gateworks System Controller support

 .../devicetree/bindings/mfd/gateworks-gsc.yaml | 196 +++
 Documentation/hwmon/gsc-hwmon.rst  |  53 +++
 Documentation/hwmon/index.rst  |   1 +
 MAINTAINERS|  11 +
 drivers/hwmon/Kconfig  |   9 +
 drivers/hwmon/Makefile |   1 +
 drivers/hwmon/gsc-hwmon.c  | 390 +
 drivers/mfd/Kconfig|  16 +
 drivers/mfd/Makefile   |   1 +
 drivers/mfd/gateworks-gsc.c| 284 +++
 include/linux/mfd/gsc.h|  76 
 include/linux/platform_data/gsc_hwmon.h

[PATCH v9 3/3] hwmon: add Gateworks System Controller support

[Tim Harvey]

The Gateworks System Controller has a hwmon sub-component that exposes
up to 16 ADC's, some of which are temperature sensors, others which are
voltage inputs. The ADC configuration (register mapping and name) is
configured via device-tree and varies board to board.

Signed-off-by: Tim Harvey 
Reviewed-by: Guenter Roeck 
---
v9:
- use exported gsc_{read,write}
- added Reviewed-by: Guenter Roeck 

v8:
- move regmap init to hwmon

v7:
- fix whitespace in Kconfig
- remove unnecessary device pointer in private data
- change divider from mili-ohms to ohms
- move fan base property to reg

v6:
- fix size of info field
- improve pwm output control documentation
- include unit suffix in divider and offset
- change subnode name to gsc-adc
- change to fan subnode
- fix voltage offset

v5:
- fix various checkpatch issues
- correct gsc-hwmon.rst in MAINTAINERS
- encorporate Gunter's feedback:
 - switch to SENSOR_DEVICE_ATTR_{RW,RO}
 - use tmp value to avoid excessive pointer deference
 - simplify shift operation
 - scale voffset once
 - simplify is_visible function
 - remove empty line at end of file

v4:
- adjust for uV offset from device-tree
- remove unnecessary optional write function
- remove register range check
- change dev_err prints to use gsc dev
- hard-code resolution/scaling for raw adcs
- describe units of ADC resolution
- move to using pwm_auto_point_{pwm,temp} for FAN PWM
- ensure space before/after operators
- remove unnecessary parens
- remove more debugging
- add default case and comment for type_voltage
- remove unnecessary index bounds checks for channel
- remove unnecessary clearing of struct fields
- added Documentation/hwmon/gsc-hwmon.rst

v3:
- add voltage_raw input type and supporting fields
- add channel validation to is_visible function
- remove unnecessary channel validation from read/write functions

v2:
- change license comment style
- remove DEBUG
- simplify regmap_bulk_read err check
- remove break after returns in switch statement
- fix fan setpoint buffer address
- remove unnecessary parens
- consistently use struct device *dev pointer
- change license/comment block
- add validation for hwmon child node props
- move parsing of of to own function
- use strlcpy to ensure null termination
- fix static array sizes and removed unnecessary initializers
- dynamically allocate channels
- fix fan input label
- support platform data
- fixed whitespace issues
---
 Documentation/hwmon/gsc-hwmon.rst   |  53 +
 Documentation/hwmon/index.rst   |   1 +
 MAINTAINERS |   3 +
 drivers/hwmon/Kconfig   |   9 +
 drivers/hwmon/Makefile  |   1 +
 drivers/hwmon/gsc-hwmon.c   | 390 
 include/linux/platform_data/gsc_hwmon.h |  44 
 7 files changed, 501 insertions(+)
 create mode 100644 Documentation/hwmon/gsc-hwmon.rst
 create mode 100644 drivers/hwmon/gsc-hwmon.c
 create mode 100644 include/linux/platform_data/gsc_hwmon.h

diff --git a/Documentation/hwmon/gsc-hwmon.rst 
b/Documentation/hwmon/gsc-hwmon.rst
new file mode 100644
index ..ffac392
--- /dev/null
+++ b/Documentation/hwmon/gsc-hwmon.rst
@@ -0,0 +1,53 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Kernel driver gsc-hwmon
+===
+
+Supported chips: Gateworks GSC
+Datasheet: http://trac.gateworks.com/wiki/gsc
+Author: Tim Harvey 
+
+Description:
+
+
+This driver supports hardware monitoring for the temperature sensor,
+various ADC's connected to the GSC, and optional FAN controller available
+on some boards.
+
+
+Voltage Monitoring
+--
+
+The voltage inputs are scaled either internally or by the driver depending
+on the GSC version and firmware. The values returned by the driver do not need
+further scaling. The voltage input labels provide the voltage rail name:
+
+inX_input  Measured voltage (mV).
+inX_label  Name of voltage rail.
+
+
+Temperature Monitoring
+--
+
+Temperatures are measured with 12-bit or 10-bit resolution and are scaled
+either internally or by the driver depending on the GSC version and firmware.
+The values returned by the driver reflect millidegree Celcius:
+
+tempX_inputMeasured temperature.
+tempX_labelName of temperature input.
+
+
+PWM Output Control
+--
+
+The GSC features 1 PWM output that operates in automatic mode where the
+PWM value will be scalled depending on 6 temperature boundaries.
+The tempeature boundaries are read-write and in millidegree Celcius and the
+read-only PWM values range from 0 (off) to 255 (full speed).
+Fan speed will be set to minimum (off) when the temperature sensor reads
+less than pwm1_auto_point1_temp and maximum when the temperature sensor
+equals or exceeds pwm1_auto_point6_temp.
+
+pwm1_auto_point[1-6]_pwm   PWM value.
+pwm1_auto_point[1-6]_temp  Temperature boundary.
+
diff --git a/Documentation/hwmon/index.rst b

[PATCH v2] ARM: dts: gw552x: add USB OTG support

[Tim Harvey]

The GW552x-B board revision adds USB OTG support.

Enable the device-tree node and configure the OTG_ID pin.

Signed-off-by: Tim Harvey 
---
 arch/arm/boot/dts/imx6qdl-gw552x.dtsi | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl-gw552x.dtsi 
b/arch/arm/boot/dts/imx6qdl-gw552x.dtsi
index dc646b7..bb35971 100644
--- a/arch/arm/boot/dts/imx6qdl-gw552x.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw552x.dtsi
@@ -258,6 +258,14 @@
status = "okay";
 };
 
+ {
+   vbus-supply = <_5p0v>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_usbotg>;
+   disable-over-current;
+   status = "okay";
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_wdog>;
@@ -359,6 +367,12 @@
>;
};
 
+   pinctrl_usbotg: usbotggrp {
+   fsl,pins = <
+   MX6QDL_PAD_ENET_RX_ER__USB_OTG_ID   0x13059
+   >;
+   };
+
pinctrl_wdog: wdoggrp {
fsl,pins = <
MX6QDL_PAD_DISP0_DAT8__WDOG1_B  0x1b0b0
-- 
2.7.4

Re: [PATCH] ARM: dts: gw552x: add USB OTG support

[Tim Harvey]

On Tue, Apr 28, 2020 at 8:37 PM Shawn Guo  wrote:
>
> On Fri, Apr 24, 2020 at 10:10:15AM -0700, Tim Harvey wrote:
> > The GW552x-B board revision adds USB OTG support.
> >
> > Enable the device-tree node and configure the OTG_ID pin.
> >
> > Signed-off-by: Tim Harvey 
> > ---
> >  arch/arm/boot/dts/imx6qdl-gw552x.dtsi | 16 ++--
> >  1 file changed, 14 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/imx6qdl-gw552x.dtsi 
> > b/arch/arm/boot/dts/imx6qdl-gw552x.dtsi
> > index dc646b7..133a1e3 100644
> > --- a/arch/arm/boot/dts/imx6qdl-gw552x.dtsi
> > +++ b/arch/arm/boot/dts/imx6qdl-gw552x.dtsi
> > @@ -12,8 +12,6 @@
> >   led1 = 
> >   led2 = 
> >   nand = 
> > - usb0 = 
> > - usb1 = 
>
> Have some comments about this change in the commit log?
>

Shawn,

I shouldn't have removed those... will submit a v2. Thank you for catching this!

Tim

Re: [PATCH v8 2/3] mfd: add Gateworks System Controller core driver

[Tim Harvey]

On Tue, Apr 28, 2020 at 11:33 PM Lee Jones  wrote:
>
> On Tue, 28 Apr 2020, Tim Harvey wrote:
>
> > On Tue, Apr 28, 2020 at 2:44 AM Lee Jones  wrote:
> > >
> > 
> > > > +
> > > > +static int gsc_probe(struct i2c_client *client)
> > > > +{
> > > > + struct device *dev = >dev;
> > > > + struct gsc_dev *gsc;
> > > > + int ret;
> > > > + unsigned int reg;
> > > > +
> > > > + gsc = devm_kzalloc(dev, sizeof(*gsc), GFP_KERNEL);
> > > > + if (!gsc)
> > > > + return -ENOMEM;
> > > > +
> > > > + gsc->dev = >dev;
> > > > + gsc->i2c = client;
> > > > + i2c_set_clientdata(client, gsc);
> > > > +
> > > > + gsc->bus.reg_write = gsc_regmap_regwrite;
> > > > + gsc->bus.reg_read = gsc_regmap_regread;
> > >
> > > Why do you need to store these in ddata?
> >
> > Lee,
> >
> > Thanks for the review!
> >
> > I need the remap_bus* for devm_regmap_init() in the hwmon sub-module driver:
> >
> > hwmon->regmap = devm_regmap_init(dev, >bus, gsc->i2c_hwmon,
> > _hwmon_regmap_config);
> >
> > Is there something easier I'm missing?
>
> This is an odd setup.  I haven't seen one driver registering another
> driver's Regmap call-backs before, related or otherwise.  Normally the
> Regmap is setup (initialised) in the parent driver and child drivers
> just make use of it.  Here it looks like you are registering 2
> separate Regmaps, but using the same call-backs for both, which seems
> wrong to me.
>

Lee,

It is perhaps an odd setup. The hwmon sub-device is at a different i2c
slave address than the other sub-devices. The same callbacks are used
for reg read/write to take advantage of the retries due to the errata
resulting in occasional NAK'd register reads.

Tim

Re: [PATCH v8 2/3] mfd: add Gateworks System Controller core driver

[Tim Harvey]

On Tue, Apr 28, 2020 at 2:44 AM Lee Jones  wrote:
>

> > +
> > +static int gsc_probe(struct i2c_client *client)
> > +{
> > + struct device *dev = >dev;
> > + struct gsc_dev *gsc;
> > + int ret;
> > + unsigned int reg;
> > +
> > + gsc = devm_kzalloc(dev, sizeof(*gsc), GFP_KERNEL);
> > + if (!gsc)
> > + return -ENOMEM;
> > +
> > + gsc->dev = >dev;
> > + gsc->i2c = client;
> > + i2c_set_clientdata(client, gsc);
> > +
> > + gsc->bus.reg_write = gsc_regmap_regwrite;
> > + gsc->bus.reg_read = gsc_regmap_regread;
>
> Why do you need to store these in ddata?

Lee,

Thanks for the review!

I need the remap_bus* for devm_regmap_init() in the hwmon sub-module driver:

hwmon->regmap = devm_regmap_init(dev, >bus, gsc->i2c_hwmon,
_hwmon_regmap_config);

Is there something easier I'm missing?

Thanks,

Tim

Re: [PATCH] media: i2c: adv7180: fix adv7280 BT.656-4 compatibility

[Tim Harvey]

On Fri, Sep 27, 2019 at 1:43 PM Niklas Söderlund
 wrote:
>
> Hi Tim,
>
> On 2019-09-27 12:26:40 -0700, Tim Harvey wrote:
> > On Fri, Sep 27, 2019 at 12:04 PM Niklas Söderlund
> >  wrote:
> > >
> > > Hi Tim,
> > >
> > > Sorry for taking to so long to look at this.
> > >
> > > On 2019-09-23 15:04:47 -0700, Tim Harvey wrote:
> > > > On Thu, Aug 29, 2019 at 7:29 AM Niklas Söderlund
> > > >  wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > On 2019-08-29 13:43:49 +0200, Hans Verkuil wrote:
> > > > > > Adding Niklas.
> > > > > >
> > > > > > Niklas, can you take a look at this?
> > > > >
> > > > > I'm happy to have a look at this. I'm currently moving so all my 
> > > > > boards
> > > > > are in a box somewhere. I hope to have my lab up and running next 
> > > > > week,
> > > > > so if this is not urgent I will look at it then.
> > > > >
> > > >
> > > > Niklas,
> > > >
> > > > Have you looked at this yet? Without this patch the ADV7280A does not
> > > > output proper BT.656. We tested this on a Gateworks Ventana GW5404-G
> > > > which uses the ADV7280A connected to the IMX6 CSI parallel bus. I'm
> > > > hoping to see this get merged and perhaps backported to older kernels.
> > >
> > > I only have access to an adv7180 so I was unable to test this patch.
> > > After reviewing the documentation I think the patch is OK if what you
> > > want is to unconditionally switch the driver from outputting BT.656-3 to
> > > outputting BT.656-4.
> > >
> > > As this change would effect a large number of compat strings (adv7280,
> > > adv7280-m, adv7281, adv7281-m, adv7281-ma, adv7282, adv7282-m) and the
> > > goal is to back port it I'm a bit reluctant to adding my tag to this
> > > patch as I'm not sure if this will break other setups.
> > >
> > > From the documentation about the BT.656-4 register (address 0x04 bit 7):
> > >
> > > Between Revision 3 and Revision 4 of the ITU-R BT.656 standards,
> > > the ITU has changed the toggling position for the V bit within
> > > the SAV EAV codes for NTSC. The ITU-R BT.656-4 standard
> > > bit allows the user to select an output mode that is compliant
> > > with either the previous or new standard. For further information,
> > > visit the International Telecommunication Union website.
> > >
> > > Note that the standard change only affects NTSC and has no
> > > bearing on PAL.
> > >
> > > When ITU-R BT.656-4 is 0 (default), the ITU-R BT.656-3
> > > specification is used. The V bit goes low at EAV of Line 10
> > > and Line 273.
> > >
> > > When ITU-R BT.656-4 is 1, the ITU-R BT.656-4 specification is
> > > used. The V bit goes low at EAV of Line 20 and Line 283.
> > >
> > > Do you know what effects such a change would bring? Looking at the
> > > driver BT.656-4 seems to be set unconditionally for some adv7180 chips.
> > >
> >
> > Niklas,
> >
> > Quite simply, we have a board that has an ADV7180 attached to the
> > parallel CSI of an IMX6 that worked fine with mainline drivers then
> > when we revised this board to attach an ADV7280A in the same way
> > capture failed to sync. Investigation showed that the NEWAVMODE
> > differed between the two.
>
> I understand your problem, the driver configures adv7180 and adv7280
> differently.
>
> >
> > So if the point of the driver is to configure the variants in the same
> > way, this patch needs to be applied.
>
> I'm not sure that is the point of the driver. As the driver today
> configures different compatible strings differently. Some as ITU-R
> BT.656-3 and some as ITU-R BT.656-4, I can only assume there is a reason
> for that.
>
> >
> > I would maintain that the adv7180 comes up with NEWAVMODE enabled and
> > in order to be compatible we must configure the adv7282 the same.
> >
> > The same argument can be made for setting the V bit end position in
> > NTSC mode - its done for the adv7180 so for compatible output it
> > should be done for the adv7282.
>
> I understand that this is needed to make it a drop-in replacement for
> the adv7180 in your use-case. But I'm not sure it is a good idea for
> other users of the driver. What if someone is already us

Re: [PATCH] media: i2c: adv7180: fix adv7280 BT.656-4 compatibility

[Tim Harvey]

On Fri, Sep 27, 2019 at 12:04 PM Niklas Söderlund
 wrote:
>
> Hi Tim,
>
> Sorry for taking to so long to look at this.
>
> On 2019-09-23 15:04:47 -0700, Tim Harvey wrote:
> > On Thu, Aug 29, 2019 at 7:29 AM Niklas Söderlund
> >  wrote:
> > >
> > > Hi,
> > >
> > > On 2019-08-29 13:43:49 +0200, Hans Verkuil wrote:
> > > > Adding Niklas.
> > > >
> > > > Niklas, can you take a look at this?
> > >
> > > I'm happy to have a look at this. I'm currently moving so all my boards
> > > are in a box somewhere. I hope to have my lab up and running next week,
> > > so if this is not urgent I will look at it then.
> > >
> >
> > Niklas,
> >
> > Have you looked at this yet? Without this patch the ADV7280A does not
> > output proper BT.656. We tested this on a Gateworks Ventana GW5404-G
> > which uses the ADV7280A connected to the IMX6 CSI parallel bus. I'm
> > hoping to see this get merged and perhaps backported to older kernels.
>
> I only have access to an adv7180 so I was unable to test this patch.
> After reviewing the documentation I think the patch is OK if what you
> want is to unconditionally switch the driver from outputting BT.656-3 to
> outputting BT.656-4.
>
> As this change would effect a large number of compat strings (adv7280,
> adv7280-m, adv7281, adv7281-m, adv7281-ma, adv7282, adv7282-m) and the
> goal is to back port it I'm a bit reluctant to adding my tag to this
> patch as I'm not sure if this will break other setups.
>
> From the documentation about the BT.656-4 register (address 0x04 bit 7):
>
> Between Revision 3 and Revision 4 of the ITU-R BT.656 standards,
> the ITU has changed the toggling position for the V bit within
> the SAV EAV codes for NTSC. The ITU-R BT.656-4 standard
> bit allows the user to select an output mode that is compliant
> with either the previous or new standard. For further information,
> visit the International Telecommunication Union website.
>
> Note that the standard change only affects NTSC and has no
> bearing on PAL.
>
> When ITU-R BT.656-4 is 0 (default), the ITU-R BT.656-3
> specification is used. The V bit goes low at EAV of Line 10
> and Line 273.
>
> When ITU-R BT.656-4 is 1, the ITU-R BT.656-4 specification is
> used. The V bit goes low at EAV of Line 20 and Line 283.
>
> Do you know what effects such a change would bring? Looking at the
> driver BT.656-4 seems to be set unconditionally for some adv7180 chips.
>

Niklas,

Quite simply, we have a board that has an ADV7180 attached to the
parallel CSI of an IMX6 that worked fine with mainline drivers then
when we revised this board to attach an ADV7280A in the same way
capture failed to sync. Investigation showed that the NEWAVMODE
differed between the two.

So if the point of the driver is to configure the variants in the same
way, this patch needs to be applied.

I would maintain that the adv7180 comes up with NEWAVMODE enabled and
in order to be compatible we must configure the adv7282 the same.

The same argument can be made for setting the V bit end position in
NTSC mode - its done for the adv7180 so for compatible output it
should be done for the adv7282.

> >
> > Regards,
> >
> > Tim
> >
> > > >
> > > > Regards,
> > > >
> > > >   Hans
> > > >
> > > > On 8/27/19 11:55 PM, Matthew Michilot wrote:
> > > > > From: Matthew Michilot 
> > > > >
> > > > > Captured video would be out of sync when using the adv7280 with
> > > > > the BT.656-4 protocol. Certain registers (0x04, 0x31, 0xE6) had to
> > > > > be configured properly to ensure BT.656-4 compatibility.
> > > > >
> > > > > An error in the adv7280 reference manual suggested that EAV/SAV mode
> > > > > was enabled by default, however upon inspecting register 0x31, it was
> > > > > determined to be disabled by default.
>
> The manual I have [1] states that NEWAVMODE is switched off by default.
> I'm only asking as I would like to know if there is an error in that
> datasheet or not.
>
> 1. 
> https://www.analog.com/media/en/technical-documentation/user-guides/ADV7280_7281_7282_7283_UG-637.pdf
>

Table 99 in that document shows NEVAVMODE disabled on power-up
(0x31=0x02) yet Page 77 shows it enabled at power-up. Looking at an
actual device we find it is indeed disabled on powerup (0x31=0x02) so
Table 99 is correct, and Page 77 is not.

If you look at the ADV7180 datasheet
(https://www.analog.com/media/en/technical-documentation/data-sheets/ADV7180.pdf)
Table 105 sh

Re: [PATCH] media: i2c: adv7180: fix adv7280 BT.656-4 compatibility

[Tim Harvey]

On Thu, Aug 29, 2019 at 7:29 AM Niklas Söderlund
 wrote:
>
> Hi,
>
> On 2019-08-29 13:43:49 +0200, Hans Verkuil wrote:
> > Adding Niklas.
> >
> > Niklas, can you take a look at this?
>
> I'm happy to have a look at this. I'm currently moving so all my boards
> are in a box somewhere. I hope to have my lab up and running next week,
> so if this is not urgent I will look at it then.
>

Niklas,

Have you looked at this yet? Without this patch the ADV7280A does not
output proper BT.656. We tested this on a Gateworks Ventana GW5404-G
which uses the ADV7280A connected to the IMX6 CSI parallel bus. I'm
hoping to see this get merged and perhaps backported to older kernels.

Regards,

Tim

> >
> > Regards,
> >
> >   Hans
> >
> > On 8/27/19 11:55 PM, Matthew Michilot wrote:
> > > From: Matthew Michilot 
> > >
> > > Captured video would be out of sync when using the adv7280 with
> > > the BT.656-4 protocol. Certain registers (0x04, 0x31, 0xE6) had to
> > > be configured properly to ensure BT.656-4 compatibility.
> > >
> > > An error in the adv7280 reference manual suggested that EAV/SAV mode
> > > was enabled by default, however upon inspecting register 0x31, it was
> > > determined to be disabled by default.
> > >
> > > Signed-off-by: Matthew Michilot 
> > > Reviewed-by: Tim Harvey 
> > > ---
> > >  drivers/media/i2c/adv7180.c | 15 +--
> > >  1 file changed, 13 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c
> > > index 99697baad2ea..27da424dce76 100644
> > > --- a/drivers/media/i2c/adv7180.c
> > > +++ b/drivers/media/i2c/adv7180.c
> > > @@ -94,6 +94,7 @@
> > >  #define ADV7180_REG_SHAP_FILTER_CTL_1  0x0017
> > >  #define ADV7180_REG_CTRL_2 0x001d
> > >  #define ADV7180_REG_VSYNC_FIELD_CTL_1  0x0031
> > > +#define ADV7180_VSYNC_FIELD_CTL_1_NEWAV 0x12
> > >  #define ADV7180_REG_MANUAL_WIN_CTL_1   0x003d
> > >  #define ADV7180_REG_MANUAL_WIN_CTL_2   0x003e
> > >  #define ADV7180_REG_MANUAL_WIN_CTL_3   0x003f
> > > @@ -935,10 +936,20 @@ static int adv7182_init(struct adv7180_state *state)
> > > adv7180_write(state, ADV7180_REG_EXTENDED_OUTPUT_CONTROL, 
> > > 0x57);
> > > adv7180_write(state, ADV7180_REG_CTRL_2, 0xc0);
> > > } else {
> > > -   if (state->chip_info->flags & ADV7180_FLAG_V2)
> > > +   if (state->chip_info->flags & ADV7180_FLAG_V2) {
> > > +   /* ITU-R BT.656-4 compatible */
> > > adv7180_write(state,
> > >   ADV7180_REG_EXTENDED_OUTPUT_CONTROL,
> > > - 0x17);
> > > + 
> > > ADV7180_EXTENDED_OUTPUT_CONTROL_NTSCDIS);
> > > +   /* Manually set NEWAVMODE */
> > > +   adv7180_write(state,
> > > + ADV7180_REG_VSYNC_FIELD_CTL_1,
> > > + ADV7180_VSYNC_FIELD_CTL_1_NEWAV);
> > > +   /* Manually set V bit end position in NTSC mode */
> > > +   adv7180_write(state,
> > > + ADV7180_REG_NTSC_V_BIT_END,
> > > + ADV7180_NTSC_V_BIT_END_MANUAL_NVEND);
> > > +   }
> > > else
> > > adv7180_write(state,
> > >   ADV7180_REG_EXTENDED_OUTPUT_CONTROL,
> > >
> >
>
> --
> Regards,
> Niklas Söderlund

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

[Tim Harvey]

On Sun, Mar 17, 2019 at 10:00 AM Russell King - ARM Linux admin
 wrote:
>
> On Sun, Mar 17, 2019 at 04:48:24PM +, Måns Rullgård wrote:
> > Stefan Agner  writes:
> >
> > > On 16.03.2019 16:39, Russell King - ARM Linux admin wrote:
> > >> On Sat, Mar 16, 2019 at 01:33:58PM +0100, Marek Vasut wrote:
> > >>> If you have a FS or partition table there, it does.
> > >>> If you don't, I agree ... that's a problem.
> > >>
> > >> eMMC boot partitions are called mmcblkXbootY, and unless you have more
> > >> than one eMMC device on the system, they can be found either by looking
> > >> for /dev/mmcblk*boot* or by querying udev.  The advantage of using udev
> > >> is you can discover the physical device behind it by looking at DEVPATH,
> > >> ID_PATH, etc, but you may not have that installed on an embedded device.
> > >>
> > >> However, as I say, just looking for /dev/mmcblk*boot* is sufficient to
> > >> find the eMMC boot partitions where there is just one eMMC device
> > >> present (which seems to be the standard setup.)
> > >>
> > >>> > I don't care the slightest what the numbering is, as long as it is
> > >>> > stable.  On some hardware, with an unpatched kernel, the mmc device
> > >>> > numbering changes depending on whether or not an SD card is inserted 
> > >>> > on
> > >>> > boot.  Getting rid of that behaviour is really all I want.
> > >>>
> > >>> Agreed, that would be an improvement.
> > >>
> > >> The mmc device numbering was tied to the mmc host numbering a while back
> > >> and the order that the hosts are probed should be completely independent
> > >> of whether a card is inserted or not:
> > >>
> > >> snprintf(md->disk->disk_name, sizeof(md->disk->disk_name),
> > >>  "mmcblk%u%s", card->host->index, subname ? subname : 
> > >> "");
> > >>
> > >> snprintf(rpmb_name, sizeof(rpmb_name),
> > >>  "mmcblk%u%s", card->host->index, subname ? subname : 
> > >> "");
> > >>
> > >> I suspect that Mans is quoting something from the dim and distant past
> > >> to confuse the issue - as shown above, it is now dependent on the host
> > >> numbering order not the order in which cards are inserted.
> > >
> > > Commit 9aaf3437aa72 ("mmc: block: Use the mmc host device index as the
> > > mmcblk device index") which came in with v4.6 enables constant mmc block
> > > device numbering. I can confirm that it works nicely, and it improved
> > > the situation a lot.
> >
> > That's the answer I was looking for.  I guess we can drop these patches
> > from our kernels then.
> >
> > > That being said, we still use a patch downstream which allows
> > > renumbering using an alias. We deal with a bunch of different boards
> > > with different SoC's. I have a couple of SD cards with various rootfs
> > > and use internal eMMC boot quite often as well. Remembering which board
> > > uses which numbering is a pain. Maintaining a patch is just easier...
> > > Furthermore, U-Boot allows reordering and all boards I deal with use mmc
> > > 0 for the internal eMMC. The aliases allow consistency.
> >
> > Since pretty much every other device type supports renumbering with DT
> > aliases, it would make sense to do this for mmc as well.
>
> SATA does not.  SCSI devices, whether they are disks, cdroms, tape
> drives or whatever have always been allocated dynamically in the
> order that they are discovered.
>
> Ethernet also does not, and davem remains opposed the idea of fixed
> allocation in the kernel.
>
> It's only a minority that demand fixed enumeration of devices.
>

Russell,

How does this case differ form defining a 'stdout-path' in the chosen
node of the device-tree [1] purposed to provide a path to the boot
console device among multiple UART's a board may have.

Again, I'm merely trying to overcome the fact that on one of my IMX6
boards usdhc2 registers as 'mmcblk0' and is an SDIO radio while usdhc3
registers as 'mmcblk1' and is the only 'bootable' device. I'm not all
that familiar with SDIO drivers... perhaps its completely wrong that
the IMX6 MMC driver is registering usdhc2 as a 'block device'?

Tim
[1] https://www.kernel.org/doc/Documentation/devicetree/bindings/chosen.txt

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

[Tim Harvey]

Tim Harvey - Principal Software EngineerGateworks Corporation -
http://www.gateworks.com/3026 S. Higuera St. San Luis Obispo CA
93401805-781-2000
On Fri, Mar 15, 2019 at 4:00 PM Marek Vasut  wrote:
>
> On 3/15/19 10:52 PM, Tim Harvey wrote:
> > Tim Harvey - Principal Software EngineerGateworks Corporation -
> > http://www.gateworks.com/3026 S. Higuera St. San Luis Obispo CA
> > 93401805-781-2000
> > On Tue, Mar 5, 2019 at 4:39 AM Måns Rullgård  wrote:
> >>
> >> Douglas Anderson  writes:
> >>
> >>> This series picks patches from various different places to produce what
> >>> I consider the best solution to getting consistent mmc and mmcblk
> >>> ordering.
> >>>
> >>> Why consistent ordering and why not just use UUIDs?  IMHO consistent
> >>> ordering solves a few different problems:
> >>>
> >>> 1. For poor, feeble-minded humans like me, have sane numbering for
> >>>devices helps a lot.  When grepping through dmesg it's terribly handy
> >>>if a given SDMMC device has a consistent number.  I know that I can
> >>>do "dmesg | grep mmc0" or "dmesg | grep mmcblk0" to find info about
> >>>the eMMC.  I know that I can do "dmesg | grep mmc1" to find info
> >>>about the SD card slot.  I don't want it to matter which one probed
> >>>first, I don't want it to matter if I'm working on a variant of the
> >>>hardware that has the SD card slot disabled, and I don't want to care
> >>>what my boot device was.  Worrying about what device number I got
> >>>increases my cognitive load.
> >>>
> >>> 2. There are cases where it's not trivially easy during development to
> >>>use the UUID.  Specifically I work a lot with coreboot / depthcharge
> >>>as a BIOS.  When configured properly, that BIOS has a nice feature to
> >>>allow you to fetch the kernel and kernel command line from TFTP by
> >>>pressing Ctrl-N.  In this particular case the BIOS doesn't actually
> >>>know which disk I'd like for my root filesystem, so it's not so easy
> >>>for it to put the right UUID into the command line.  For this
> >>>purpose, knowing that "mmcblk0" will always refer to eMMC is handy.
> >>>
> >>> Changes in v2:
> >>> - Rebased atop mmc-next
> >>> - Stat dynamic allocation after fixed allocation; thanks Wolfram!
> >>> - rk3288 patch new for v2
> >>>
> >>> Douglas Anderson (1):
> >>>   ARM: dts: rockchip: Add mmc aliases for rk3288 platform
> >>>
> >>> Jaehoon Chung (1):
> >>>   Documentation: mmc: Document mmc aliases
> >>>
> >>> Stefan Agner (2):
> >>>   mmc: read mmc alias from device tree
> >>>   mmc: use SD/MMC host ID for block device name ID
> >>>
> >>>  Documentation/devicetree/bindings/mmc/mmc.txt | 11 +++
> >>>  arch/arm/boot/dts/rk3288.dtsi |  4 
> >>>  drivers/mmc/card/block.c  |  2 +-
> >>>  drivers/mmc/core/host.c   | 17 -
> >>>  4 files changed, 32 insertions(+), 2 deletions(-)
> >>
> >> Did anyone ever come up with an acceptable solution for this?  After
> >> three years, I'm getting tired of rebasing these patches onto every new
> >> kernel.
> >>
> >> UUIDs or similar are NOT an option for multiple reasons:
> >>
> >> - We have two rootfs partitions for ping-pong updates, so simply
> >>   referring to "the thing with ID foo" doesn't work.
> >>
> >> - Installing said updates needs direct access the device/partition,
> >>   which may not even have a filesystem.
> >>
> >> - The u-boot environment is stored in an eMMC "boot" partition, and
> >>   userspace needs to know where to find it.
> >>
> >> I'm sure I'm not the only one in a similar situation.
> >>
> >> Russel, feel free to shout abuse at me.  I don't care, but it makes you
> >> look stupid.
> >>
> >
> > Completely agree here - we need a dt solution that allows us to
> > specify ordering.
>
> Nope, ordering would be a policy and does not describe hardware, thus it
> shouldn't be in the DT. Use UUID or PARTUUID, they apply both to raw FS
> (fsuuid) and to partitions (part uuid). Linux kernel can mount FS using
> PARTUUID, to support UUID you need initramfs.

Marek,

Sure... a 'policy' decision would be which bootable device to boot
from but the issue I see that needs solving is for the vendor to be
able to describe via dt what devices are bootable for MMC (an SDIO
wifi device is not bootable yet a eMMC/microSD is).

Isn't this exactly the same issue as what the stdout-path specifies in
the chosen node? Modern SoC's have multiple UART's yet boot firmware
needs to know which one is the serial console just like boot firmware
should be able to figure out what device or devices are bootable.

Perhaps we can add a 'bootdev-path' in the chosen node?

Regards,

Tim

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

[Tim Harvey]

Tim Harvey - Principal Software EngineerGateworks Corporation -
http://www.gateworks.com/3026 S. Higuera St. San Luis Obispo CA
93401805-781-2000
On Tue, Mar 5, 2019 at 4:39 AM Måns Rullgård  wrote:
>
> Douglas Anderson  writes:
>
> > This series picks patches from various different places to produce what
> > I consider the best solution to getting consistent mmc and mmcblk
> > ordering.
> >
> > Why consistent ordering and why not just use UUIDs?  IMHO consistent
> > ordering solves a few different problems:
> >
> > 1. For poor, feeble-minded humans like me, have sane numbering for
> >devices helps a lot.  When grepping through dmesg it's terribly handy
> >if a given SDMMC device has a consistent number.  I know that I can
> >do "dmesg | grep mmc0" or "dmesg | grep mmcblk0" to find info about
> >the eMMC.  I know that I can do "dmesg | grep mmc1" to find info
> >about the SD card slot.  I don't want it to matter which one probed
> >first, I don't want it to matter if I'm working on a variant of the
> >hardware that has the SD card slot disabled, and I don't want to care
> >what my boot device was.  Worrying about what device number I got
> >increases my cognitive load.
> >
> > 2. There are cases where it's not trivially easy during development to
> >use the UUID.  Specifically I work a lot with coreboot / depthcharge
> >as a BIOS.  When configured properly, that BIOS has a nice feature to
> >allow you to fetch the kernel and kernel command line from TFTP by
> >pressing Ctrl-N.  In this particular case the BIOS doesn't actually
> >know which disk I'd like for my root filesystem, so it's not so easy
> >for it to put the right UUID into the command line.  For this
> >purpose, knowing that "mmcblk0" will always refer to eMMC is handy.
> >
> > Changes in v2:
> > - Rebased atop mmc-next
> > - Stat dynamic allocation after fixed allocation; thanks Wolfram!
> > - rk3288 patch new for v2
> >
> > Douglas Anderson (1):
> >   ARM: dts: rockchip: Add mmc aliases for rk3288 platform
> >
> > Jaehoon Chung (1):
> >   Documentation: mmc: Document mmc aliases
> >
> > Stefan Agner (2):
> >   mmc: read mmc alias from device tree
> >   mmc: use SD/MMC host ID for block device name ID
> >
> >  Documentation/devicetree/bindings/mmc/mmc.txt | 11 +++
> >  arch/arm/boot/dts/rk3288.dtsi |  4 
> >  drivers/mmc/card/block.c  |  2 +-
> >  drivers/mmc/core/host.c   | 17 -
> >  4 files changed, 32 insertions(+), 2 deletions(-)
>
> Did anyone ever come up with an acceptable solution for this?  After
> three years, I'm getting tired of rebasing these patches onto every new
> kernel.
>
> UUIDs or similar are NOT an option for multiple reasons:
>
> - We have two rootfs partitions for ping-pong updates, so simply
>   referring to "the thing with ID foo" doesn't work.
>
> - Installing said updates needs direct access the device/partition,
>   which may not even have a filesystem.
>
> - The u-boot environment is stored in an eMMC "boot" partition, and
>   userspace needs to know where to find it.
>
> I'm sure I'm not the only one in a similar situation.
>
> Russel, feel free to shout abuse at me.  I don't care, but it makes you
> look stupid.
>

Completely agree here - we need a dt solution that allows us to
specify ordering.

I support a variety of IMX6 boards where for PCB routing reasons the
bootable MMC device is not always the first sdhc (sometimes the first
one is an SDIO radio for example). It seems ridiculous that I can't
handle this with:

aliases {
mmc0 =  /* MMC boot device */
mmc1 =  /* SDIO radio */
};

I see the imx6q-dhcom-som added in
52c7a088badd665a09ca9307ffa91e88d5686a7d re-defines the default
imx6qdl.dtsi mmc0-mmc3 aiases but I don't see any handling of this in
code anywhere - am I missing something?

Marek, why did you change the alias ordering for imx6q-dhcom-som.dtsi?
(maybe your carrying around a patch to make this useful?)

+   aliases {
+   mmc0 = 
+   mmc1 = 
+   mmc2 = 
+   mmc3 = 
+   };

Regards,

Tim

Re: [PATCH 1/2] regulator: ltc3676: Simplify .readable_reg and .writable_reg callbacks

[Tim Harvey]

On Fri, Feb 15, 2019 at 3:54 AM Axel Lin  wrote:
>
> Use case range for continuous range to make the code shorter.
> The .readable_reg and .writable_reg implementation are exactly the same,
> so use a common ltc3676_readable_writeable_reg function instead.
>
> Signed-off-by: Axel Lin 
> ---
>  drivers/regulator/ltc3676.c | 63 +++--
>  1 file changed, 5 insertions(+), 58 deletions(-)
>
> diff --git a/drivers/regulator/ltc3676.c b/drivers/regulator/ltc3676.c
> index 71fd0f2a4b76..549a1a243870 100644
> --- a/drivers/regulator/ltc3676.c
> +++ b/drivers/regulator/ltc3676.c
> @@ -241,61 +241,10 @@ static struct regulator_desc 
> ltc3676_regulators[LTC3676_NUM_REGULATORS] = {
> LTC3676_FIXED_REG(LDO4, ldo4, LDOB, 2),
>  };
>
> -static bool ltc3676_writeable_reg(struct device *dev, unsigned int reg)
> +static bool ltc3676_readable_writeable_reg(struct device *dev, unsigned int 
> reg)
>  {
> switch (reg) {
> -   case LTC3676_IRQSTAT:
> -   case LTC3676_BUCK1:
> -   case LTC3676_BUCK2:
> -   case LTC3676_BUCK3:
> -   case LTC3676_BUCK4:
> -   case LTC3676_LDOA:
> -   case LTC3676_LDOB:
> -   case LTC3676_SQD1:
> -   case LTC3676_SQD2:
> -   case LTC3676_CNTRL:
> -   case LTC3676_DVB1A:
> -   case LTC3676_DVB1B:
> -   case LTC3676_DVB2A:
> -   case LTC3676_DVB2B:
> -   case LTC3676_DVB3A:
> -   case LTC3676_DVB3B:
> -   case LTC3676_DVB4A:
> -   case LTC3676_DVB4B:
> -   case LTC3676_MSKIRQ:
> -   case LTC3676_MSKPG:
> -   case LTC3676_USER:
> -   case LTC3676_HRST:
> -   case LTC3676_CLIRQ:
> -   return true;
> -   }
> -   return false;
> -}
> -
> -static bool ltc3676_readable_reg(struct device *dev, unsigned int reg)
> -{
> -   switch (reg) {
> -   case LTC3676_IRQSTAT:
> -   case LTC3676_BUCK1:
> -   case LTC3676_BUCK2:
> -   case LTC3676_BUCK3:
> -   case LTC3676_BUCK4:
> -   case LTC3676_LDOA:
> -   case LTC3676_LDOB:
> -   case LTC3676_SQD1:
> -   case LTC3676_SQD2:
> -   case LTC3676_CNTRL:
> -   case LTC3676_DVB1A:
> -   case LTC3676_DVB1B:
> -   case LTC3676_DVB2A:
> -   case LTC3676_DVB2B:
> -   case LTC3676_DVB3A:
> -   case LTC3676_DVB3B:
> -   case LTC3676_DVB4A:
> -   case LTC3676_DVB4B:
> -   case LTC3676_MSKIRQ:
> -   case LTC3676_MSKPG:
> -   case LTC3676_USER:
> +   case LTC3676_BUCK1 ... LTC3676_IRQSTAT:
> case LTC3676_HRST:
> case LTC3676_CLIRQ:
> return true;
> @@ -306,9 +255,7 @@ static bool ltc3676_readable_reg(struct device *dev, 
> unsigned int reg)
>  static bool ltc3676_volatile_reg(struct device *dev, unsigned int reg)
>  {
> switch (reg) {
> -   case LTC3676_IRQSTAT:
> -   case LTC3676_PGSTATL:
> -   case LTC3676_PGSTATRT:
> +   case LTC3676_IRQSTAT ... LTC3676_PGSTATRT:
> return true;
> }
> return false;
> @@ -317,8 +264,8 @@ static bool ltc3676_volatile_reg(struct device *dev, 
> unsigned int reg)
>  static const struct regmap_config ltc3676_regmap_config = {
> .reg_bits = 8,
> .val_bits = 8,
> -   .writeable_reg = ltc3676_writeable_reg,
> -   .readable_reg = ltc3676_readable_reg,
> +   .writeable_reg = ltc3676_readable_writeable_reg,
> +   .readable_reg = ltc3676_readable_writeable_reg,
> .volatile_reg = ltc3676_volatile_reg,
> .max_register = LTC3676_CLIRQ,
> .use_single_read = true,
> --
> 2.17.1
>

Acked-by: Tim Harvey 

Tim

Re: [PATCH 2/2] regulator: ltc3676: Fix module description

[Tim Harvey]

On Fri, Feb 15, 2019 at 3:54 AM Axel Lin  wrote:
>
> This driver is for LTC3676 rather than LTC1376.
>
> Signed-off-by: Axel Lin 
> ---
>  drivers/regulator/ltc3676.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/regulator/ltc3676.c b/drivers/regulator/ltc3676.c
> index 549a1a243870..e6d66e492b85 100644
> --- a/drivers/regulator/ltc3676.c
> +++ b/drivers/regulator/ltc3676.c
> @@ -389,5 +389,5 @@ static struct i2c_driver ltc3676_driver = {
>  module_i2c_driver(ltc3676_driver);
>
>  MODULE_AUTHOR("Tim Harvey ");
> -MODULE_DESCRIPTION("Regulator driver for Linear Technology LTC1376");
> +MODULE_DESCRIPTION("Regulator driver for Linear Technology LTC3676");
>  MODULE_LICENSE("GPL v2");
> --

Acked-by: Tim Harvey 

Tim

Re: [PATCH v3 3/4] gpu: ipu-v3: ipu-ic: Add support for BT.709 encoding

[Tim Harvey]

On Fri, Feb 8, 2019 at 11:28 AM Steve Longerbeam  wrote:
>
> Pass v4l2 encoding enum to the ipu_ic task init functions, and add
> support for the BT.709 encoding and inverse encoding matrices.
>
> Reported-by: Tim Harvey 
> Signed-off-by: Steve Longerbeam 
> ---
> Changes in v2:
> - only return "Unsupported YCbCr encoding" error if inf != outf,
>   since if inf == outf, the identity matrix can be used. Reported
>   by Tim Harvey.
> ---
>  drivers/gpu/ipu-v3/ipu-ic.c | 71 +++--
>  drivers/gpu/ipu-v3/ipu-image-convert.c  |  1 +
>  drivers/staging/media/imx/imx-ic-prpencvf.c |  4 +-
>  include/video/imx-ipu-v3.h  |  5 +-
>  4 files changed, 71 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/ipu-v3/ipu-ic.c b/drivers/gpu/ipu-v3/ipu-ic.c
> index e459615a49a1..0d57ca7ba18e 100644
> --- a/drivers/gpu/ipu-v3/ipu-ic.c
> +++ b/drivers/gpu/ipu-v3/ipu-ic.c
> @@ -212,6 +212,23 @@ static const struct ic_csc_params ic_csc_identity = {
> .scale = 2,
>  };
>
> +/*
> + * BT.709 encoding from RGB full range to YUV limited range:
> + *
> + * Y = R *  .2126 + G *  .7152 + B *  .0722;
> + * U = R * -.1146 + G * -.3854 + B *  .5000 + 128.;
> + * V = R *  .5000 + G * -.4542 + B * -.0458 + 128.;
> + */
> +static const struct ic_csc_params ic_csc_rgb2ycbcr_bt709 = {
> +   .coeff = {
> +   { 54, 183, 18 },
> +   { 483, 413, 128 },
> +   { 128, 396, 500 },
> +   },
> +   .offset = { 0, 512, 512 },
> +   .scale = 1,
> +};
> +
>  /*
>   * Inverse BT.601 encoding from YUV limited range to RGB full range:
>   *
> @@ -229,12 +246,31 @@ static const struct ic_csc_params 
> ic_csc_ycbcr2rgb_bt601 = {
> .scale = 2,
>  };
>
> +/*
> + * Inverse BT.709 encoding from YUV limited range to RGB full range:
> + *
> + * R = (1. * (Y - 16)) + (1.5748 * (Cr - 128));
> + * G = (1. * (Y - 16)) - (0.1873 * (Cb - 128)) - (0.4681 * (Cr - 128));
> + * B = (1. * (Y - 16)) + (1.8556 * (Cb - 128);
> + */
> +static const struct ic_csc_params ic_csc_ycbcr2rgb_bt709 = {
> +   .coeff = {
> +   { 128, 0, 202 },
> +   { 128, 488, 452 },
> +   { 128, 238, 0 },
> +   },
> +   .offset = { -435, 136, -507 },
> +   .scale = 2,
> +};
> +
>  static int init_csc(struct ipu_ic *ic,
> enum ipu_color_space inf,
> enum ipu_color_space outf,
> +   enum v4l2_ycbcr_encoding encoding,
> int csc_index)
>  {
> struct ipu_ic_priv *priv = ic->priv;
> +   const struct ic_csc_params *params_rgb2yuv, *params_yuv2rgb;
> const struct ic_csc_params *params;
> u32 __iomem *base;
> const u16 (*c)[3];
> @@ -244,12 +280,30 @@ static int init_csc(struct ipu_ic *ic,
> base = (u32 __iomem *)
> (priv->tpmem_base + ic->reg->tpmem_csc[csc_index]);
>
> +   switch (encoding) {
> +   case V4L2_YCBCR_ENC_601:
> +   params_rgb2yuv =  _csc_rgb2ycbcr_bt601;
> +   params_yuv2rgb = _csc_ycbcr2rgb_bt601;
> +   break;
> +   case V4L2_YCBCR_ENC_709:
> +   params_rgb2yuv =  _csc_rgb2ycbcr_bt709;
> +   params_yuv2rgb = _csc_ycbcr2rgb_bt709;
> +   break;
> +   default:
> +   if (inf != outf) {
> +   dev_err(priv->ipu->dev,
> +   "Unsupported YCbCr encoding\n");
> +   return -EINVAL;
> +   }
> +   break;
> +   }
> +
> if (inf == outf)
> params = _csc_identity;
> else if (inf == IPUV3_COLORSPACE_YUV)
> -   params = _csc_ycbcr2rgb_bt601;
> +   params = _csc_ycbcr2rgb;


Steve,

compile issue...

params = params_yuv2rgb;

> else
> -   params = _csc_rgb2ycbcr_bt601;
> +   params = _csc_rgb2ycbcr;

params = params_rgb2yuv;

But, I'm still failing when using the mem2mem element (gst-launch-1.0
v4l2src device=/dev/video4 ! v4l2video8convert
output-io-mode=dmabuf-import ! fbdevsink) with 'Unsupported YCbCr
encoding' because of inf=IPU_COLORSPACE_YCBCR outf=IPU_COLORSPACE_RGB
and a seemingly unset encoding being passed in.

It looks like maybe something in the mem2mem driver isn't defaulting
encoding. The call path is (v4l2_m2m_streamon -> device_run ->
ipu_image_convert_queue -> convert_start -> ipu_ic_task_init_rsc ->
init_csc).

Tim

Re: [PATCH 2/3] gpu: ipu-v3: ipu-ic: Add support for BT.709 encoding

[Tim Harvey]

On Sun, Feb 3, 2019 at 11:48 AM Steve Longerbeam  wrote:
>
> Pass v4l2 encoding enum to the ipu_ic task init functions, and add
> support for the BT.709 encoding and inverse encoding matrices.
>
> Reported-by: Tim Harvey 
> Signed-off-by: Steve Longerbeam 
> ---
>  drivers/gpu/ipu-v3/ipu-ic.c | 67 ++---
>  drivers/gpu/ipu-v3/ipu-image-convert.c  |  1 +
>  drivers/staging/media/imx/imx-ic-prpencvf.c |  4 +-
>  include/video/imx-ipu-v3.h  |  5 +-
>  4 files changed, 67 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/ipu-v3/ipu-ic.c b/drivers/gpu/ipu-v3/ipu-ic.c
> index 35ae86ff0585..63362b4fff81 100644
> --- a/drivers/gpu/ipu-v3/ipu-ic.c
> +++ b/drivers/gpu/ipu-v3/ipu-ic.c
> @@ -199,6 +199,23 @@ static const struct ic_csc_params ic_csc_rgb2ycbcr_bt601 
> = {
> .scale = 1,
>  };
>
> +/*
> + * BT.709 encoding from RGB full range to YUV limited range:
> + *
> + * Y = R *  .2126 + G *  .7152 + B *  .0722;
> + * U = R * -.1146 + G * -.3854 + B *  .5000 + 128.;
> + * V = R *  .5000 + G * -.4542 + B * -.0458 + 128.;
> + */
> +static const struct ic_csc_params ic_csc_rgb2ycbcr_bt709 = {
> +   .coeff = {
> +   { 54, 183, 18 },
> +   { 483, 413, 128 },
> +   { 128, 396, 500 },
> +   },
> +   .offset = { 0, 512, 512 },
> +   .scale = 1,
> +};
> +
>  /* transparent RGB->RGB matrix for graphics combining */
>  static const struct ic_csc_params ic_csc_rgb2rgb = {
> .coeff = {
> @@ -226,12 +243,31 @@ static const struct ic_csc_params 
> ic_csc_ycbcr2rgb_bt601 = {
> .scale = 2,
>  };
>
> +/*
> + * Inverse BT.709 encoding from YUV limited range to RGB full range:
> + *
> + * R = (1. * (Y - 16)) + (1.5748 * (Cr - 128));
> + * G = (1. * (Y - 16)) - (0.1873 * (Cb - 128)) - (0.4681 * (Cr - 128));
> + * B = (1. * (Y - 16)) + (1.8556 * (Cb - 128);
> + */
> +static const struct ic_csc_params ic_csc_ycbcr2rgb_bt709 = {
> +   .coeff = {
> +   { 128, 0, 202 },
> +   { 128, 488, 452 },
> +   { 128, 238, 0 },
> +   },
> +   .offset = { -435, 136, -507 },
> +   .scale = 2,
> +};
> +
>  static int init_csc(struct ipu_ic *ic,
> enum ipu_color_space inf,
> enum ipu_color_space outf,
> +   enum v4l2_ycbcr_encoding encoding,
> int csc_index)
>  {
> struct ipu_ic_priv *priv = ic->priv;
> +   const struct ic_csc_params *params_rgb2yuv, *params_yuv2rgb;
> const struct ic_csc_params *params;
> u32 __iomem *base;
> const u16 (*c)[3];
> @@ -241,10 +277,24 @@ static int init_csc(struct ipu_ic *ic,
> base = (u32 __iomem *)
> (priv->tpmem_base + ic->reg->tpmem_csc[csc_index]);
>
> +   switch (encoding) {
> +   case V4L2_YCBCR_ENC_601:
> +   params_rgb2yuv =  _csc_rgb2ycbcr_bt601;
> +   params_yuv2rgb = _csc_ycbcr2rgb_bt601;
> +   break;
> +   case V4L2_YCBCR_ENC_709:
> +   params_rgb2yuv =  _csc_rgb2ycbcr_bt709;
> +   params_yuv2rgb = _csc_ycbcr2rgb_bt709;
> +   break;
> +   default:
> +   dev_err(priv->ipu->dev, "Unsupported YCbCr encoding\n");
> +   return -EINVAL;
> +   }
> +

Steve,

This will fail for RGB to RGB with 'Unsupported YCbCr encoding. We
need to account for the RGB->RGB case.

How about something like:

 static int init_csc(struct ipu_ic *ic,
enum ipu_color_space inf,
enum ipu_color_space outf,
+   enum v4l2_ycbcr_encoding encoding,
int csc_index)
 {
struct ipu_ic_priv *priv = ic->priv;
-   const struct ic_csc_params *params;
+   const struct ic_csc_params *params = NULL;
u32 __iomem *base;
const u16 (*c)[3];
const u16 *a;
@@ -241,13 +276,18 @@ static int init_csc(struct ipu_ic *ic,
base = (u32 __iomem *)
(priv->tpmem_base + ic->reg->tpmem_csc[csc_index]);

-   if (inf == IPUV3_COLORSPACE_YUV && outf == IPUV3_COLORSPACE_RGB)
-   params = _csc_ycbcr2rgb_bt601;
-   else if (inf == IPUV3_COLORSPACE_RGB && outf == IPUV3_COLORSPACE_YUV)
-   params = _csc_rgb2ycbcr_bt601;
+   if (inf == IPUV3_COLORSPACE_YUV && outf == IPUV3_COLORSPACE_RGB) {
+   params = (encoding == V4L2_YCBCR_ENC_601) ?
+   _csc_ycbcr2rgb_bt601 : _csc_ycbcr2rgb_bt709;
+   }
+   else if (inf == IPUV3_COLORSPACE_RGB && outf == IPUV3_COLORSPACE_YUV) {
+   

Re: [PATCH v8 11/11] media: imx.rst: Update doc to reflect fixes to interlaced capture

[Tim Harvey]

On Tue, Jan 22, 2019 at 4:10 PM Steve Longerbeam  wrote:
>
>
>
> On 1/21/19 12:24 PM, Tim Harvey wrote:
> > On Tue, Jan 15, 2019 at 3:54 PM Steve Longerbeam  
> > wrote:
> >> Hi Tim,
> >>
> >> On 1/15/19 1:58 PM, Tim Harvey wrote:
> >>> On Wed, Jan 9, 2019 at 10:30 AM Steve Longerbeam  
> >>> wrote:
> >>>> Also add an example pipeline for unconverted capture with interweave
> >>>> on SabreAuto.
> >>>>
> >>>> Cleanup some language in various places in the process.
> >>>>
> >>>> Signed-off-by: Steve Longerbeam 
> >>>> Reviewed-by: Philipp Zabel 
> >>>> ---
> >>>> Changes since v4:
> >>>> - Make clear that it is IDMAC channel that does pixel reordering and
> >>>> interweave, not the CSI. Caught by Philipp Zabel.
> >>>> Changes since v3:
> >>>> - none.
> >>>> Changes since v2:
> >>>> - expand on idmac interweave behavior in CSI subdev.
> >>>> - switch second SabreAuto pipeline example to PAL to give
> >>>> both NTSC and PAL examples.
> >>>> - Cleanup some language in various places.
> >>>> ---
> >>>>Documentation/media/v4l-drivers/imx.rst | 103 +++-
> >>>>1 file changed, 66 insertions(+), 37 deletions(-)
> >>>>
> >>> 
> >>>>Capture Pipelines
> >>>>-
> >>>> @@ -516,10 +522,33 @@ On the SabreAuto, an on-board ADV7180 SD decoder 
> >>>> is connected to the
> >>>>parallel bus input on the internal video mux to IPU1 CSI0.
> >>>>
> >>>>The following example configures a pipeline to capture from the 
> >>>> ADV7180
> >>>> -video decoder, assuming NTSC 720x480 input signals, with Motion
> >>>> -Compensated de-interlacing. Pad field types assume the adv7180 outputs
> >>>> -"interlaced". $outputfmt can be any format supported by the 
> >>>> ipu1_ic_prpvf
> >>>> -entity at its output pad:
> >>>> +video decoder, assuming NTSC 720x480 input signals, using simple
> >>>> +interweave (unconverted and without motion compensation). The adv7180
> >>>> +must output sequential or alternating fields (field type 'seq-bt' for
> >>>> +NTSC, or 'alternate'):
> >>>> +
> >>>> +.. code-block:: none
> >>>> +
> >>>> +   # Setup links
> >>>> +   media-ctl -l "'adv7180 3-0021':0 -> 'ipu1_csi0_mux':1[1]"
> >>>> +   media-ctl -l "'ipu1_csi0_mux':2 -> 'ipu1_csi0':0[1]"
> >>>> +   media-ctl -l "'ipu1_csi0':2 -> 'ipu1_csi0 capture':0[1]"
> >>>> +   # Configure pads
> >>>> +   media-ctl -V "'adv7180 3-0021':0 [fmt:UYVY2X8/720x480 field:seq-bt]"
> >>>> +   media-ctl -V "'ipu1_csi0_mux':2 [fmt:UYVY2X8/720x480]"
> >>>> +   media-ctl -V "'ipu1_csi0':2 [fmt:AYUV32/720x480]"
> >>>> +   # Configure "ipu1_csi0 capture" interface (assumed at /dev/video4)
> >>>> +   v4l2-ctl -d4 --set-fmt-video=field=interlaced_bt
> >>>> +
> >>>> +Streaming can then begin on /dev/video4. The v4l2-ctl tool can also be
> >>>> +used to select any supported YUV pixelformat on /dev/video4.
> >>>> +
> >>> Hi Steve,
> >>>
> >>> I'm testing 4.20 with this patchset on top.
> >>>
> >>> I'm on a GW5104 which has an IMX6Q with the adv7180 on ipu1_csi0 like
> >>> the SabeAuto example above I can't get the simple interveave example
> >>> to work:
> >>>
> >>> media-ctl -r # reset all links
> >>> # Setup links (ADV7180 IPU1_CSI0)
> >>> media-ctl -l '"adv7180 2-0020":0 -> "ipu1_csi0_mux":1[1]'
> >>> media-ctl -l '"ipu1_csi0_mux":2 -> "ipu1_csi0":0[1]'
> >>> media-ctl -l '"ipu1_csi0":2 -> "ipu1_csi0 capture":0[1]' # /dev/video4
> >>> # Configure pads
> >>> media-ctl -V "'adv7180 2-0020':0 [fmt:UYVY2X8/720x480 field:seq-bt]"
> >>> media-ctl -V "'ipu1_csi0_mux':2 [fmt:UYVY2X8/720x480]"
> >>> media-ctl -V "'ipu1_csi0':0 [fmt:AYUV32/720x480]"
> >> This is the reason. The adv7180 is only allowing to configure alterna

Re: [PATCH v8 11/11] media: imx.rst: Update doc to reflect fixes to interlaced capture

[Tim Harvey]

On Mon, Jan 21, 2019 at 12:24 PM Tim Harvey  wrote:
>
> On Tue, Jan 15, 2019 at 3:54 PM Steve Longerbeam  
> wrote:
> >
> > Hi Tim,
> >
> > On 1/15/19 1:58 PM, Tim Harvey wrote:
> > > On Wed, Jan 9, 2019 at 10:30 AM Steve Longerbeam  
> > > wrote:
> > >> Also add an example pipeline for unconverted capture with interweave
> > >> on SabreAuto.
> > >>
> > >> Cleanup some language in various places in the process.
> > >>
> > >> Signed-off-by: Steve Longerbeam 
> > >> Reviewed-by: Philipp Zabel 
> > >> ---
> > >> Changes since v4:
> > >> - Make clear that it is IDMAC channel that does pixel reordering and
> > >>interweave, not the CSI. Caught by Philipp Zabel.
> > >> Changes since v3:
> > >> - none.
> > >> Changes since v2:
> > >> - expand on idmac interweave behavior in CSI subdev.
> > >> - switch second SabreAuto pipeline example to PAL to give
> > >>both NTSC and PAL examples.
> > >> - Cleanup some language in various places.
> > >> ---
> > >>   Documentation/media/v4l-drivers/imx.rst | 103 +++-
> > >>   1 file changed, 66 insertions(+), 37 deletions(-)
> > >>
> > > 
> > >>   Capture Pipelines
> > >>   -
> > >> @@ -516,10 +522,33 @@ On the SabreAuto, an on-board ADV7180 SD decoder 
> > >> is connected to the
> > >>   parallel bus input on the internal video mux to IPU1 CSI0.
> > >>
> > >>   The following example configures a pipeline to capture from the ADV7180
> > >> -video decoder, assuming NTSC 720x480 input signals, with Motion
> > >> -Compensated de-interlacing. Pad field types assume the adv7180 outputs
> > >> -"interlaced". $outputfmt can be any format supported by the 
> > >> ipu1_ic_prpvf
> > >> -entity at its output pad:
> > >> +video decoder, assuming NTSC 720x480 input signals, using simple
> > >> +interweave (unconverted and without motion compensation). The adv7180
> > >> +must output sequential or alternating fields (field type 'seq-bt' for
> > >> +NTSC, or 'alternate'):
> > >> +
> > >> +.. code-block:: none
> > >> +
> > >> +   # Setup links
> > >> +   media-ctl -l "'adv7180 3-0021':0 -> 'ipu1_csi0_mux':1[1]"
> > >> +   media-ctl -l "'ipu1_csi0_mux':2 -> 'ipu1_csi0':0[1]"
> > >> +   media-ctl -l "'ipu1_csi0':2 -> 'ipu1_csi0 capture':0[1]"
> > >> +   # Configure pads
> > >> +   media-ctl -V "'adv7180 3-0021':0 [fmt:UYVY2X8/720x480 field:seq-bt]"
> > >> +   media-ctl -V "'ipu1_csi0_mux':2 [fmt:UYVY2X8/720x480]"
> > >> +   media-ctl -V "'ipu1_csi0':2 [fmt:AYUV32/720x480]"
> > >> +   # Configure "ipu1_csi0 capture" interface (assumed at /dev/video4)
> > >> +   v4l2-ctl -d4 --set-fmt-video=field=interlaced_bt
> > >> +
> > >> +Streaming can then begin on /dev/video4. The v4l2-ctl tool can also be
> > >> +used to select any supported YUV pixelformat on /dev/video4.
> > >> +
> > > Hi Steve,
> > >
> > > I'm testing 4.20 with this patchset on top.
> > >
> > > I'm on a GW5104 which has an IMX6Q with the adv7180 on ipu1_csi0 like
> > > the SabeAuto example above I can't get the simple interveave example
> > > to work:
> > >
> > > media-ctl -r # reset all links
> > > # Setup links (ADV7180 IPU1_CSI0)
> > > media-ctl -l '"adv7180 2-0020":0 -> "ipu1_csi0_mux":1[1]'
> > > media-ctl -l '"ipu1_csi0_mux":2 -> "ipu1_csi0":0[1]'
> > > media-ctl -l '"ipu1_csi0":2 -> "ipu1_csi0 capture":0[1]' # /dev/video4
> > > # Configure pads
> > > media-ctl -V "'adv7180 2-0020':0 [fmt:UYVY2X8/720x480 field:seq-bt]"
> > > media-ctl -V "'ipu1_csi0_mux':2 [fmt:UYVY2X8/720x480]"
> > > media-ctl -V "'ipu1_csi0':0 [fmt:AYUV32/720x480]"
> >
> > This is the reason. The adv7180 is only allowing to configure alternate
> > field mode, and thus it reports the field height on the mbus, not the
> > full frame height. Imx deals with alternate field mode by capturing a
> > full frame, so the CSI entity sets the output pad height to double the
> > height.
> >
> > So the CSI input pad needs to be config

Re: [PATCH v8 11/11] media: imx.rst: Update doc to reflect fixes to interlaced capture

[Tim Harvey]

On Tue, Jan 15, 2019 at 3:54 PM Steve Longerbeam  wrote:
>
> Hi Tim,
>
> On 1/15/19 1:58 PM, Tim Harvey wrote:
> > On Wed, Jan 9, 2019 at 10:30 AM Steve Longerbeam  
> > wrote:
> >> Also add an example pipeline for unconverted capture with interweave
> >> on SabreAuto.
> >>
> >> Cleanup some language in various places in the process.
> >>
> >> Signed-off-by: Steve Longerbeam 
> >> Reviewed-by: Philipp Zabel 
> >> ---
> >> Changes since v4:
> >> - Make clear that it is IDMAC channel that does pixel reordering and
> >>interweave, not the CSI. Caught by Philipp Zabel.
> >> Changes since v3:
> >> - none.
> >> Changes since v2:
> >> - expand on idmac interweave behavior in CSI subdev.
> >> - switch second SabreAuto pipeline example to PAL to give
> >>both NTSC and PAL examples.
> >> - Cleanup some language in various places.
> >> ---
> >>   Documentation/media/v4l-drivers/imx.rst | 103 +++-
> >>   1 file changed, 66 insertions(+), 37 deletions(-)
> >>
> > 
> >>   Capture Pipelines
> >>   -
> >> @@ -516,10 +522,33 @@ On the SabreAuto, an on-board ADV7180 SD decoder is 
> >> connected to the
> >>   parallel bus input on the internal video mux to IPU1 CSI0.
> >>
> >>   The following example configures a pipeline to capture from the ADV7180
> >> -video decoder, assuming NTSC 720x480 input signals, with Motion
> >> -Compensated de-interlacing. Pad field types assume the adv7180 outputs
> >> -"interlaced". $outputfmt can be any format supported by the ipu1_ic_prpvf
> >> -entity at its output pad:
> >> +video decoder, assuming NTSC 720x480 input signals, using simple
> >> +interweave (unconverted and without motion compensation). The adv7180
> >> +must output sequential or alternating fields (field type 'seq-bt' for
> >> +NTSC, or 'alternate'):
> >> +
> >> +.. code-block:: none
> >> +
> >> +   # Setup links
> >> +   media-ctl -l "'adv7180 3-0021':0 -> 'ipu1_csi0_mux':1[1]"
> >> +   media-ctl -l "'ipu1_csi0_mux':2 -> 'ipu1_csi0':0[1]"
> >> +   media-ctl -l "'ipu1_csi0':2 -> 'ipu1_csi0 capture':0[1]"
> >> +   # Configure pads
> >> +   media-ctl -V "'adv7180 3-0021':0 [fmt:UYVY2X8/720x480 field:seq-bt]"
> >> +   media-ctl -V "'ipu1_csi0_mux':2 [fmt:UYVY2X8/720x480]"
> >> +   media-ctl -V "'ipu1_csi0':2 [fmt:AYUV32/720x480]"
> >> +   # Configure "ipu1_csi0 capture" interface (assumed at /dev/video4)
> >> +   v4l2-ctl -d4 --set-fmt-video=field=interlaced_bt
> >> +
> >> +Streaming can then begin on /dev/video4. The v4l2-ctl tool can also be
> >> +used to select any supported YUV pixelformat on /dev/video4.
> >> +
> > Hi Steve,
> >
> > I'm testing 4.20 with this patchset on top.
> >
> > I'm on a GW5104 which has an IMX6Q with the adv7180 on ipu1_csi0 like
> > the SabeAuto example above I can't get the simple interveave example
> > to work:
> >
> > media-ctl -r # reset all links
> > # Setup links (ADV7180 IPU1_CSI0)
> > media-ctl -l '"adv7180 2-0020":0 -> "ipu1_csi0_mux":1[1]'
> > media-ctl -l '"ipu1_csi0_mux":2 -> "ipu1_csi0":0[1]'
> > media-ctl -l '"ipu1_csi0":2 -> "ipu1_csi0 capture":0[1]' # /dev/video4
> > # Configure pads
> > media-ctl -V "'adv7180 2-0020':0 [fmt:UYVY2X8/720x480 field:seq-bt]"
> > media-ctl -V "'ipu1_csi0_mux':2 [fmt:UYVY2X8/720x480]"
> > media-ctl -V "'ipu1_csi0':0 [fmt:AYUV32/720x480]"
>
> This is the reason. The adv7180 is only allowing to configure alternate
> field mode, and thus it reports the field height on the mbus, not the
> full frame height. Imx deals with alternate field mode by capturing a
> full frame, so the CSI entity sets the output pad height to double the
> height.
>
> So the CSI input pad needs to be configured with the field height:
>
> media-ctl -V "'ipu1_csi0':0 [fmt:AYUV32/720x240]"
>
> It should work for you after doing that. And better yet, don't bother
> configuring the input pad, because media-ctl will propagate formats from
> source to sink pads for you, so it's better to rely on the propagation,
> and set the CSI output pad format instead (full frame height at output pad):
>
> media-ctl -V "'ipu1_csi0':2 [fmt:AYUV32/720x480]"
>

Steve,

Thanks - that makes sense.

Re: [PATCH v8 11/11] media: imx.rst: Update doc to reflect fixes to interlaced capture

[Tim Harvey]

On Wed, Jan 9, 2019 at 10:30 AM Steve Longerbeam  wrote:
>
> Also add an example pipeline for unconverted capture with interweave
> on SabreAuto.
>
> Cleanup some language in various places in the process.
>
> Signed-off-by: Steve Longerbeam 
> Reviewed-by: Philipp Zabel 
> ---
> Changes since v4:
> - Make clear that it is IDMAC channel that does pixel reordering and
>   interweave, not the CSI. Caught by Philipp Zabel.
> Changes since v3:
> - none.
> Changes since v2:
> - expand on idmac interweave behavior in CSI subdev.
> - switch second SabreAuto pipeline example to PAL to give
>   both NTSC and PAL examples.
> - Cleanup some language in various places.
> ---
>  Documentation/media/v4l-drivers/imx.rst | 103 +++-
>  1 file changed, 66 insertions(+), 37 deletions(-)
>

>  Capture Pipelines
>  -
> @@ -516,10 +522,33 @@ On the SabreAuto, an on-board ADV7180 SD decoder is 
> connected to the
>  parallel bus input on the internal video mux to IPU1 CSI0.
>
>  The following example configures a pipeline to capture from the ADV7180
> -video decoder, assuming NTSC 720x480 input signals, with Motion
> -Compensated de-interlacing. Pad field types assume the adv7180 outputs
> -"interlaced". $outputfmt can be any format supported by the ipu1_ic_prpvf
> -entity at its output pad:
> +video decoder, assuming NTSC 720x480 input signals, using simple
> +interweave (unconverted and without motion compensation). The adv7180
> +must output sequential or alternating fields (field type 'seq-bt' for
> +NTSC, or 'alternate'):
> +
> +.. code-block:: none
> +
> +   # Setup links
> +   media-ctl -l "'adv7180 3-0021':0 -> 'ipu1_csi0_mux':1[1]"
> +   media-ctl -l "'ipu1_csi0_mux':2 -> 'ipu1_csi0':0[1]"
> +   media-ctl -l "'ipu1_csi0':2 -> 'ipu1_csi0 capture':0[1]"
> +   # Configure pads
> +   media-ctl -V "'adv7180 3-0021':0 [fmt:UYVY2X8/720x480 field:seq-bt]"
> +   media-ctl -V "'ipu1_csi0_mux':2 [fmt:UYVY2X8/720x480]"
> +   media-ctl -V "'ipu1_csi0':2 [fmt:AYUV32/720x480]"
> +   # Configure "ipu1_csi0 capture" interface (assumed at /dev/video4)
> +   v4l2-ctl -d4 --set-fmt-video=field=interlaced_bt
> +
> +Streaming can then begin on /dev/video4. The v4l2-ctl tool can also be
> +used to select any supported YUV pixelformat on /dev/video4.
> +

Hi Steve,

I'm testing 4.20 with this patchset on top.

I'm on a GW5104 which has an IMX6Q with the adv7180 on ipu1_csi0 like
the SabeAuto example above I can't get the simple interveave example
to work:

media-ctl -r # reset all links
# Setup links (ADV7180 IPU1_CSI0)
media-ctl -l '"adv7180 2-0020":0 -> "ipu1_csi0_mux":1[1]'
media-ctl -l '"ipu1_csi0_mux":2 -> "ipu1_csi0":0[1]'
media-ctl -l '"ipu1_csi0":2 -> "ipu1_csi0 capture":0[1]' # /dev/video4
# Configure pads
media-ctl -V "'adv7180 2-0020':0 [fmt:UYVY2X8/720x480 field:seq-bt]"
media-ctl -V "'ipu1_csi0_mux':2 [fmt:UYVY2X8/720x480]"
media-ctl -V "'ipu1_csi0':0 [fmt:AYUV32/720x480]"
# Configure 'ipu1_csi0 capture' interface (/dev/video4)
v4l2-ctl -d4 --set-fmt-video=field=interlaced_bt
# streaming can now begin on the raw capture device node at /dev/video4
v4l2-ctl -d4 --stream-mmap --stream-to=/x.raw --stream-count=1 # capture 1 frame
[ 5547.354460] ipu1_csi0: pipeline start failed with -32
VIDIOC_STREAMON: failed: Broken pipe

Any ideas what is causing this pipeline failure.

> +This example configures a pipeline to capture from the ADV7180
> +video decoder, assuming PAL 720x576 input signals, with Motion
> +Compensated de-interlacing. The adv7180 must output sequential or
> +alternating fields (field type 'seq-tb' for PAL, or 'alternate').
> +$outputfmt can be any format supported by the ipu1_ic_prpvf entity
> +at its output pad:
>
>  .. code-block:: none
>
> @@ -531,11 +560,11 @@ entity at its output pad:
> media-ctl -l "'ipu1_ic_prp':2 -> 'ipu1_ic_prpvf':0[1]"
> media-ctl -l "'ipu1_ic_prpvf':1 -> 'ipu1_ic_prpvf capture':0[1]"
> # Configure pads
> -   media-ctl -V "'adv7180 3-0021':0 [fmt:UYVY2X8/720x480]"
> -   media-ctl -V "'ipu1_csi0_mux':2 [fmt:UYVY2X8/720x480 field:interlaced]"
> -   media-ctl -V "'ipu1_csi0':1 [fmt:AYUV32/720x480 field:interlaced]"
> -   media-ctl -V "'ipu1_vdic':2 [fmt:AYUV32/720x480 field:none]"
> -   media-ctl -V "'ipu1_ic_prp':2 [fmt:AYUV32/720x480 field:none]"
> +   media-ctl -V "'adv7180 3-0021':0 [fmt:UYVY2X8/720x576 field:seq-tb]"
> +   media-ctl -V "'ipu1_csi0_mux':2 [fmt:UYVY2X8/720x576]"
> +   media-ctl -V "'ipu1_csi0':1 [fmt:AYUV32/720x576]"
> +   media-ctl -V "'ipu1_vdic':2 [fmt:AYUV32/720x576 field:none]"
> +   media-ctl -V "'ipu1_ic_prp':2 [fmt:AYUV32/720x576 field:none]"
> media-ctl -V "'ipu1_ic_prpvf':1 [fmt:$outputfmt field:none]"
>
>  Streaming can then begin on the capture device node at

The above motion-compensation example pipeline does now work with this
patch series - thanks for addressing this!

Regards,

Tim

Re: [PATCH] media: imx-csi: Input connections to CSI should be optional

[Tim Harvey]

On Wed, Jan 9, 2019 at 10:34 AM Steve Longerbeam  wrote:
>
> Some imx platforms do not have fwnode connections to all CSI input
> ports, and should not be treated as an error. This includes the
> imx6q SabreAuto, which has no connections to ipu1_csi1 and ipu2_csi0.
> Return -ENOTCONN in imx_csi_parse_endpoint() so that v4l2-fwnode
> endpoint parsing will not treat an unconnected CSI input port as
> an error.
>
> Fixes: c893500a16baf ("media: imx: csi: Register a subdev notifier")
>
> Signed-off-by: Steve Longerbeam 
> ---
>  drivers/staging/media/imx/imx-media-csi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/media/imx/imx-media-csi.c 
> b/drivers/staging/media/imx/imx-media-csi.c
> index 4223f8d418ae..30b1717982ae 100644
> --- a/drivers/staging/media/imx/imx-media-csi.c
> +++ b/drivers/staging/media/imx/imx-media-csi.c
> @@ -1787,7 +1787,7 @@ static int imx_csi_parse_endpoint(struct device *dev,
>   struct v4l2_fwnode_endpoint *vep,
>   struct v4l2_async_subdev *asd)
>  {
> -   return fwnode_device_is_available(asd->match.fwnode) ? 0 : -EINVAL;
> +   return fwnode_device_is_available(asd->match.fwnode) ? 0 : -ENOTCONN;
>  }
>
>  static int imx_csi_async_register(struct csi_priv *priv)
> --
> 2.17.1
>

Steve,

Thanks, this fixes adv7180 the capture regression on the Gateworks
Ventana boards as well. This should go to stable to fix 4.20 so please
add a 'Cc: sta...@vger.kernel.org' if you re-submit (else we can send
it to sta...@vger.kernel.org later).

Acked-by: Tim Harvey 

Tim

Re: [PATCH v3][RESEND] media: i2c: tda1997: replace codec to component

[Tim Harvey]

On Mon, Apr 23, 2018 at 9:52 AM, Mark Brown <broo...@kernel.org> wrote:
> On Mon, Apr 23, 2018 at 09:44:17AM -0700, Tim Harvey wrote:
>
>> Could you add some detail to the commit explaining why we need to
>> replace codec to component? I don't really know what that means.
>> Please refer to a commit if the ASoC API is changing in some way we
>> need to catch up with.
>
> This is a big transition in the ASoC API which is nearing completion -
> this driver is one of the last users of the CODEC struct, we've (well,
> mainly Morimoto-san) been migrating things away from it to the more
> general purpose component.  There's no one commit to point at really as
> the two have coexisted for a while and we won't be able to finally
> remove the CODEC struct until all the drivers have transitioned away.

Mark,

Ok - thanks for the explanation!

Kuninori,

Sorry this took so long to get to. Tested on a GW5404

Tested-by: Tim Harvey <thar...@gateworks.com>
Acked-by: Tim Harvey <thar...@gateworks.com>

Regards,

Tim

Re: [PATCH v3][RESEND] media: i2c: tda1997: replace codec to component

[Tim Harvey]

On Mon, Apr 23, 2018 at 9:52 AM, Mark Brown  wrote:
> On Mon, Apr 23, 2018 at 09:44:17AM -0700, Tim Harvey wrote:
>
>> Could you add some detail to the commit explaining why we need to
>> replace codec to component? I don't really know what that means.
>> Please refer to a commit if the ASoC API is changing in some way we
>> need to catch up with.
>
> This is a big transition in the ASoC API which is nearing completion -
> this driver is one of the last users of the CODEC struct, we've (well,
> mainly Morimoto-san) been migrating things away from it to the more
> general purpose component.  There's no one commit to point at really as
> the two have coexisted for a while and we won't be able to finally
> remove the CODEC struct until all the drivers have transitioned away.

Mark,

Ok - thanks for the explanation!

Kuninori,

Sorry this took so long to get to. Tested on a GW5404

Tested-by: Tim Harvey 
Acked-by: Tim Harvey 

Regards,

Tim

Re: [PATCH v3][RESEND] media: i2c: tda1997: replace codec to component

[Tim Harvey]

On Sun, Apr 22, 2018 at 7:10 PM, Kuninori Morimoto
 wrote:
>
> From: Kuninori Morimoto 
>
> Now we can replace Codec to Component. Let's do it.
>
> Note:
> xxx_codec_xxx() ->  xxx_component_xxx()
> .idle_bias_off = 0  ->  .idle_bias_on = 1
> .ignore_pmdown_time = 0 ->  .use_pmdown_time = 1
> -   ->  .endianness = 1
> -   ->  .non_legacy_dai_naming = 1
>
> Signed-off-by: Kuninori Morimoto 
> ---
> Tim, Mauro
>
> 2 weeks passed. I re-send.
> This replace patch is needed for ALSA SoC, otherwise it can't probe anymore.
>
> v2 -> v3
>
>  - fixup driver name (= tda1997)
>

Kuninori,

Could you add some detail to the commit explaining why we need to
replace codec to component? I don't really know what that means.
Please refer to a commit if the ASoC API is changing in some way we
need to catch up with.

Regards,

Tim

Re: [PATCH v3][RESEND] media: i2c: tda1997: replace codec to component

[Tim Harvey]

On Sun, Apr 22, 2018 at 7:10 PM, Kuninori Morimoto
 wrote:
>
> From: Kuninori Morimoto 
>
> Now we can replace Codec to Component. Let's do it.
>
> Note:
> xxx_codec_xxx() ->  xxx_component_xxx()
> .idle_bias_off = 0  ->  .idle_bias_on = 1
> .ignore_pmdown_time = 0 ->  .use_pmdown_time = 1
> -   ->  .endianness = 1
> -   ->  .non_legacy_dai_naming = 1
>
> Signed-off-by: Kuninori Morimoto 
> ---
> Tim, Mauro
>
> 2 weeks passed. I re-send.
> This replace patch is needed for ALSA SoC, otherwise it can't probe anymore.
>
> v2 -> v3
>
>  - fixup driver name (= tda1997)
>

Kuninori,

Could you add some detail to the commit explaining why we need to
replace codec to component? I don't really know what that means.
Please refer to a commit if the ASoC API is changing in some way we
need to catch up with.

Regards,

Tim

Re: [v3,4/4] watchdog: add Gateworks System Controller support

[Tim Harvey]

On Mon, Apr 2, 2018 at 9:32 AM, Andrew Lunn  wrote:
>> The 'use case' we have been using this in for a couple years is that
>> users who want to use this watchdog will enable it externally (we have
>> a command in the bootloader) and if enabled the kernel driver (that
>> I'm proposing here which we've been using out-of-tree) will register
>> the watchdog device and the userspace watchdog process can open the
>> device and start tickling it. If the watchdog is never enabled (or
>> disabled via the bootloader command) the kernel driver fails to probe
>> and the SoC's watchdog can be used.
>
> Hi Tim
>
> Is there any reason not to give the user the choice to use both
> watchdogs? Normally you write drivers to expose the hardware, and then
> let the users choice if they want to use it.
>

Andrew,

I don't know what value the SoC watchdog has if you have the GSC
watchdog available that can power cycle the board but I would agree
normally you would expose all of them. I suppose this may be a
different case because I'm expecting the user to go and manually
enable the watchdog instead of using the kernel to do it which means
if its not enabled its not really available to be used.

Tim