* Re: [PATCH RFC 1/7] pinctrl: sh-pfc: add new flags into struct sh_pfc_pin_config
From: Geert Uytterhoeven @ 2019-08-06 8:46 UTC (permalink / raw)
To: Yoshihiro Shimoda
Cc: Linus Walleij, Geert Uytterhoeven, Thierry Reding, Rob Herring,
Mark Rutland, open list:GPIO SUBSYSTEM, Linux PWM List,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux-Renesas
In-Reply-To: <1562576868-8124-2-git-send-email-yoshihiro.shimoda.uh@renesas.com>
On Mon, Jul 8, 2019 at 11:08 AM Yoshihiro Shimoda
<yoshihiro.shimoda.uh@renesas.com> wrote:
> To clean/modify the code up later, this patch just adds new flags
> "mux_set" and "gpio_enabled" into the struct sh_pfc_pin_config.
>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH 4/4] arm64: dts: lx2160a: Fix incorrect I2C clock divider
From: Chuanhua Han @ 2019-08-06 8:42 UTC (permalink / raw)
To: shawnguo, leoyang.li, robh+dt, mark.rutland
Cc: linux-arm-kernel, devicetree, linux-kernel, Chuanhua Han
In-Reply-To: <20190806084223.23543-1-chuanhua.han@nxp.com>
Lx2160a platform, the i2c input clock is actually platform pll CLK / 16
(this is the hardware connection), other clock divider can not get the
correct i2c clock, resulting in the output of SCL pin clock is not
accurate.
Signed-off-by: Chuanhua Han <chuanhua.han@nxp.com>
---
arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
index 4720a8e..408e0ec 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
@@ -485,7 +485,7 @@
reg = <0x0 0x2000000 0x0 0x10000>;
interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
clock-names = "i2c";
- clocks = <&clockgen 4 7>;
+ clocks = <&clockgen 4 15>;
scl-gpio = <&gpio2 15 GPIO_ACTIVE_HIGH>;
status = "disabled";
};
@@ -497,7 +497,7 @@
reg = <0x0 0x2010000 0x0 0x10000>;
interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
clock-names = "i2c";
- clocks = <&clockgen 4 7>;
+ clocks = <&clockgen 4 15>;
status = "disabled";
};
@@ -508,7 +508,7 @@
reg = <0x0 0x2020000 0x0 0x10000>;
interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>;
clock-names = "i2c";
- clocks = <&clockgen 4 7>;
+ clocks = <&clockgen 4 15>;
status = "disabled";
};
@@ -519,7 +519,7 @@
reg = <0x0 0x2030000 0x0 0x10000>;
interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>;
clock-names = "i2c";
- clocks = <&clockgen 4 7>;
+ clocks = <&clockgen 4 15>;
status = "disabled";
};
@@ -530,7 +530,7 @@
reg = <0x0 0x2040000 0x0 0x10000>;
interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
clock-names = "i2c";
- clocks = <&clockgen 4 7>;
+ clocks = <&clockgen 4 15>;
scl-gpio = <&gpio2 16 GPIO_ACTIVE_HIGH>;
status = "disabled";
};
@@ -542,7 +542,7 @@
reg = <0x0 0x2050000 0x0 0x10000>;
interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
clock-names = "i2c";
- clocks = <&clockgen 4 7>;
+ clocks = <&clockgen 4 15>;
status = "disabled";
};
@@ -553,7 +553,7 @@
reg = <0x0 0x2060000 0x0 0x10000>;
interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
clock-names = "i2c";
- clocks = <&clockgen 4 7>;
+ clocks = <&clockgen 4 15>;
status = "disabled";
};
@@ -564,7 +564,7 @@
reg = <0x0 0x2070000 0x0 0x10000>;
interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
clock-names = "i2c";
- clocks = <&clockgen 4 7>;
+ clocks = <&clockgen 4 15>;
status = "disabled";
};
--
2.9.5
^ permalink raw reply related
* [PATCH 3/4] arm64: dts: ls1028a: Fix incorrect I2C clock divider
From: Chuanhua Han @ 2019-08-06 8:42 UTC (permalink / raw)
To: shawnguo, leoyang.li, robh+dt, mark.rutland
Cc: linux-arm-kernel, devicetree, linux-kernel, Chuanhua Han
In-Reply-To: <20190806084223.23543-1-chuanhua.han@nxp.com>
Ls1028a platform, the i2c input clock is actually platform pll CLK / 4
(this is the hardware connection), other clock divider can not get the
correct i2c clock, resulting in the output of SCL pin clock is not
accurate.
Signed-off-by: Chuanhua Han <chuanhua.han@nxp.com>
---
arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
index aef5b06..cca7bfdb 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
@@ -171,7 +171,7 @@
#size-cells = <0>;
reg = <0x0 0x2000000 0x0 0x10000>;
interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clockgen 4 1>;
+ clocks = <&clockgen 4 3>;
status = "disabled";
};
@@ -181,7 +181,7 @@
#size-cells = <0>;
reg = <0x0 0x2010000 0x0 0x10000>;
interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clockgen 4 1>;
+ clocks = <&clockgen 4 3>;
status = "disabled";
};
@@ -191,7 +191,7 @@
#size-cells = <0>;
reg = <0x0 0x2020000 0x0 0x10000>;
interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clockgen 4 1>;
+ clocks = <&clockgen 4 3>;
status = "disabled";
};
@@ -201,7 +201,7 @@
#size-cells = <0>;
reg = <0x0 0x2030000 0x0 0x10000>;
interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clockgen 4 1>;
+ clocks = <&clockgen 4 3>;
status = "disabled";
};
@@ -211,7 +211,7 @@
#size-cells = <0>;
reg = <0x0 0x2040000 0x0 0x10000>;
interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clockgen 4 1>;
+ clocks = <&clockgen 4 3>;
status = "disabled";
};
@@ -221,7 +221,7 @@
#size-cells = <0>;
reg = <0x0 0x2050000 0x0 0x10000>;
interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clockgen 4 1>;
+ clocks = <&clockgen 4 3>;
status = "disabled";
};
@@ -231,7 +231,7 @@
#size-cells = <0>;
reg = <0x0 0x2060000 0x0 0x10000>;
interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clockgen 4 1>;
+ clocks = <&clockgen 4 3>;
status = "disabled";
};
@@ -241,7 +241,7 @@
#size-cells = <0>;
reg = <0x0 0x2070000 0x0 0x10000>;
interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clockgen 4 1>;
+ clocks = <&clockgen 4 3>;
status = "disabled";
};
--
2.9.5
^ permalink raw reply related
* [PATCH 2/4] arm64: dts: ls1012a: Fix incorrect I2C clock divider
From: Chuanhua Han @ 2019-08-06 8:42 UTC (permalink / raw)
To: shawnguo, leoyang.li, robh+dt, mark.rutland
Cc: linux-arm-kernel, devicetree, linux-kernel, Chuanhua Han
In-Reply-To: <20190806084223.23543-1-chuanhua.han@nxp.com>
Ls1012a platform, the i2c input clock is actually platform pll CLK / 4
(this is the hardware connection), other clock divider can not get the
correct i2c clock, resulting in the output of SCL pin clock is not
accurate.
Signed-off-by: Chuanhua Han <chuanhua.han@nxp.com>
---
arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
index ec6257a..124a7e2 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
@@ -323,7 +323,7 @@
#size-cells = <0>;
reg = <0x0 0x2180000 0x0 0x10000>;
interrupts = <0 56 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clockgen 4 0>;
+ clocks = <&clockgen 4 3>;
status = "disabled";
};
@@ -333,7 +333,7 @@
#size-cells = <0>;
reg = <0x0 0x2190000 0x0 0x10000>;
interrupts = <0 57 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clockgen 4 0>;
+ clocks = <&clockgen 4 3>;
status = "disabled";
};
--
2.9.5
^ permalink raw reply related
* [PATCH 1/4] arm64: dts: ls1088a: Fix incorrect I2C clock divider
From: Chuanhua Han @ 2019-08-06 8:42 UTC (permalink / raw)
To: shawnguo, leoyang.li, robh+dt, mark.rutland
Cc: linux-arm-kernel, devicetree, linux-kernel, Chuanhua Han
Ls1088a platform, the i2c input clock is actually platform pll CLK / 8
(this is the hardware connection), other clock divider can not get the
correct i2c clock, resulting in the output of SCL pin clock is not
accurate.
Signed-off-by: Chuanhua Han <chuanhua.han@nxp.com>
---
arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
index 20f5ebd..30b760e 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
@@ -324,7 +324,7 @@
#size-cells = <0>;
reg = <0x0 0x2000000 0x0 0x10000>;
interrupts = <0 34 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clockgen 4 3>;
+ clocks = <&clockgen 4 7>;
status = "disabled";
};
@@ -334,7 +334,7 @@
#size-cells = <0>;
reg = <0x0 0x2010000 0x0 0x10000>;
interrupts = <0 34 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clockgen 4 3>;
+ clocks = <&clockgen 4 7>;
status = "disabled";
};
@@ -344,7 +344,7 @@
#size-cells = <0>;
reg = <0x0 0x2020000 0x0 0x10000>;
interrupts = <0 35 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clockgen 4 3>;
+ clocks = <&clockgen 4 7>;
status = "disabled";
};
@@ -354,7 +354,7 @@
#size-cells = <0>;
reg = <0x0 0x2030000 0x0 0x10000>;
interrupts = <0 35 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clockgen 4 3>;
+ clocks = <&clockgen 4 7>;
status = "disabled";
};
--
2.9.5
^ permalink raw reply related
* Re: [PATCH v2 3/4] arm64: dts: meson: Link nvmem and secure-monitor nodes
From: Jerome Brunet @ 2019-08-06 8:26 UTC (permalink / raw)
To: srinivas.kandagatla, khilman, narmstrong, robh+dt, tglx,
linux-arm-kernel, linux-amlogic, devicetree
Cc: Carlo Caione
In-Reply-To: <20190731082339.20163-4-ccaione@baylibre.com>
On Wed 31 Jul 2019 at 09:23, Carlo Caione <ccaione@baylibre.com> wrote:
> The former is going to use the latter to retrieve the efuses data.
>
Reviewed-by: Jerome Brunet <jbrunet@baylibre.com>
> Signed-off-by: Carlo Caione <ccaione@baylibre.com>
^ permalink raw reply
* Re: [PATCH v2 2/4] nvmem: meson-efuse: bindings: Add secure-monitor phandle
From: Jerome Brunet @ 2019-08-06 8:25 UTC (permalink / raw)
To: srinivas.kandagatla, khilman, narmstrong, robh+dt, tglx,
linux-arm-kernel, linux-amlogic, devicetree
Cc: Carlo Caione
In-Reply-To: <20190731082339.20163-3-ccaione@baylibre.com>
On Wed 31 Jul 2019 at 09:23, Carlo Caione <ccaione@baylibre.com> wrote:
> Add a new property to link the nvmem driver to the secure-monitor. The
> nvmem driver needs to access the secure-monitor to be able to access the
> fuses.
>
Reviewed-by: Jerome Brunet <jbrunet@baylibre.com>
> Signed-off-by: Carlo Caione <ccaione@baylibre.com>
^ permalink raw reply
* Re: [PATCH v2 0/4] Rework secure-monitor driver
From: Srinivas Kandagatla @ 2019-08-06 8:25 UTC (permalink / raw)
To: Kevin Hilman, Carlo Caione
Cc: devicetree, narmstrong, robh+dt, linux-amlogic, tglx,
linux-arm-kernel, jbrunet
In-Reply-To: <7hftmfguug.fsf@baylibre.com>
Hi Kevin,
On 05/08/2019 22:34, Kevin Hilman wrote:
> Srinivas,
>
> Carlo Caione <ccaione@baylibre.com> writes:
>
>> The secure-monitor driver is currently in really bad shape, not my
>> proudest piece of code (thanks Jerome for pointing that out ;). I tried
>> to rework it a bit to make it a bit more tolerable.
>>
>> I needed to change a bit the APIs and consequently adapt the only user
>> we have, that is the nvmem/efuses driver. To not break bisectability I
>> added one single commit to change both the drivers.
>
> With your ack on the nvmem bindings and nvmem part of patch 4/4, I can
> take the series take the rest of this series through my tree for Amlogic
> SoCs.
Sounds good for me!
I have Acked the driver changes, bindings need ack from DT guys.
Thanks,
srini
>
> Kevin
>
^ permalink raw reply
* Re: [PATCH v2 4/4] firmware: meson_sm: Rework driver as a proper platform driver
From: Srinivas Kandagatla @ 2019-08-06 8:23 UTC (permalink / raw)
To: Carlo Caione, khilman, narmstrong, robh+dt, tglx, jbrunet,
linux-arm-kernel, linux-amlogic, devicetree
In-Reply-To: <20190731082339.20163-5-ccaione@baylibre.com>
On 31/07/2019 09:23, Carlo Caione wrote:
> The secure monitor driver is currently a frankenstein driver which is
> registered as a platform driver but its functionality goes through a
> global struct accessed by the consumer drivers using exported helper
> functions.
>
> Try to tidy up the driver moving the firmware struct into the driver
> data and make the consumer drivers referencing the secure-monitor using
> a new property in the DT.
>
> Currently only the nvmem driver is using this API so we can fix it in
> the same commit.
>
> Reviewed-by: Jerome Brunet <jbrunet@baylibre.com>
> Signed-off-by: Carlo Caione <ccaione@baylibre.com>
> ---
> drivers/firmware/meson/meson_sm.c | 94 +++++++++++++++++--------
> drivers/nvmem/meson-efuse.c | 24 ++++++-
Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
^ permalink raw reply
* Re: [PATCH 2/3] dt-bindings: display: amlogic,meson-vpu: convert to yaml
From: Neil Armstrong @ 2019-08-06 7:59 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, dri-devel, linux-amlogic,
linux-kernel@vger.kernel.org
In-Reply-To: <CAL_JsqLMS2y5ZR4SH6TVwnaTDhnGwk2_C_81DTz9J=ypDdBd4w@mail.gmail.com>
On 06/08/2019 00:19, Rob Herring wrote:
> On Mon, Aug 5, 2019 at 7:43 AM Neil Armstrong <narmstrong@baylibre.com> wrote:
>>
>> Now that we have the DT validation in place, let's convert the device tree
>> bindings for the Amlogic Display Controller over to YAML schemas.
>>
>> The original example has a leftover "dmc" memory cell, that has been
>> removed in the yaml rewrite.
>>
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>> ---
>> .../bindings/display/amlogic,meson-vpu.txt | 121 --------------
>> .../bindings/display/amlogic,meson-vpu.yaml | 153 ++++++++++++++++++
>> 2 files changed, 153 insertions(+), 121 deletions(-)
>> delete mode 100644 Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt
>> create mode 100644 Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml
>
>
>> diff --git a/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml b/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml
>> new file mode 100644
>> index 000000000000..9eba13031998
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml
>> @@ -0,0 +1,153 @@
>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>> +# Copyright 2019 BayLibre, SAS
>> +%YAML 1.2
>> +---
>> +$id: "http://devicetree.org/schemas/display/amlogic,meson-vpu.yaml#"
>> +$schema: "http://devicetree.org/meta-schemas/core.yaml#"
>> +
>> +title: Amlogic Meson Display Controller
>> +
>> +maintainers:
>> + - Neil Armstrong <narmstrong@baylibre.com>
>> +
>> +description: |
>> + The Amlogic Meson Display controller is composed of several components
>> + that are going to be documented below
>> +
>> + DMC|---------------VPU (Video Processing Unit)----------------|------HHI------|
>> + | vd1 _______ _____________ _________________ | |
>> + D |-------| |----| | | | | HDMI PLL |
>> + D | vd2 | VIU | | Video Post | | Video Encoders |<---|-----VCLK |
>> + R |-------| |----| Processing | | | | |
>> + | osd2 | | | |---| Enci ----------|----|-----VDAC------|
>> + R |-------| CSC |----| Scalers | | Encp ----------|----|----HDMI-TX----|
>> + A | osd1 | | | Blenders | | Encl ----------|----|---------------|
>> + M |-------|______|----|____________| |________________| | |
>> + ___|__________________________________________________________|_______________|
>> +
>> +
>> + VIU: Video Input Unit
>> + ---------------------
>> +
>> + The Video Input Unit is in charge of the pixel scanout from the DDR memory.
>> + It fetches the frames addresses, stride and parameters from the "Canvas" memory.
>> + This part is also in charge of the CSC (Colorspace Conversion).
>> + It can handle 2 OSD Planes and 2 Video Planes.
>> +
>> + VPP: Video Post Processing
>> + --------------------------
>> +
>> + The Video Post Processing is in charge of the scaling and blending of the
>> + various planes into a single pixel stream.
>> + There is a special "pre-blending" used by the video planes with a dedicated
>> + scaler and a "post-blending" to merge with the OSD Planes.
>> + The OSD planes also have a dedicated scaler for one of the OSD.
>> +
>> + VENC: Video Encoders
>> + --------------------
>> +
>> + The VENC is composed of the multiple pixel encoders
>> + - ENCI : Interlace Video encoder for CVBS and Interlace HDMI
>> + - ENCP : Progressive Video Encoder for HDMI
>> + - ENCL : LCD LVDS Encoder
>> + The VENC Unit gets a Pixel Clocks (VCLK) from a dedicated HDMI PLL and clock
>> + tree and provides the scanout clock to the VPP and VIU.
>> + The ENCI is connected to a single VDAC for Composite Output.
>> + The ENCI and ENCP are connected to an on-chip HDMI Transceiver.
>> +
>> + The following table lists for each supported model the port number
>> + corresponding to each VPU output.
>> +
>> + Port 0 Port 1
>> + -----------------------------------------
>> + S905 (GXBB) CVBS VDAC HDMI-TX
>> + S905X (GXL) CVBS VDAC HDMI-TX
>> + S905D (GXL) CVBS VDAC HDMI-TX
>> + S912 (GXM) CVBS VDAC HDMI-TX
>> + S905X2 (G12A) CVBS VDAC HDMI-TX
>> + S905Y2 (G12A) CVBS VDAC HDMI-TX
>> + S905D2 (G12A) CVBS VDAC HDMI-TX
>> +
>> +properties:
>> + compatible:
>> + oneOf:
>> + - items:
>> + - enum:
>> + - amlogic,meson-gxbb-vpu # GXBB (S905)
>> + - amlogic,meson-gxl-vpu # GXL (S905X, S905D)
>> + - amlogic,meson-gxm-vpu # GXM (S912)
>> + - const: amlogic,meson-gx-vpu
>> + - enum:
>> + - amlogic,meson-g12a-vpu # G12A (S905X2, S905Y2, S905D2)
>> +
>> + reg:
>> + maxItems: 2
>> +
>> + reg-names:
>> + items:
>> + - const: vpu
>> + - const: hhi
>> +
>> + interrupts:
>> + maxItems: 1
>> +
>> + power-domains:
>> + description: phandle to the associated power domain
>> + allOf:
>> + - $ref: /schemas/types.yaml#/definitions/phandle
>
> Common properties don't need a type definition. As this can be an
> array, you just need 'maxItems: 1'.
Ok
>
> Same comments on patch 1 apply here too.
OK
>
> Rob
>
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: display: amlogic,meson-dw-hdmi: convert to yaml
From: Neil Armstrong @ 2019-08-06 7:57 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, dri-devel, linux-amlogic,
linux-kernel@vger.kernel.org
In-Reply-To: <CAL_JsqJPFdR6bj_XuVuEDFYhCpmhQ4pZ66egCNJH_U26tTydmA@mail.gmail.com>
On 06/08/2019 00:15, Rob Herring wrote:
> On Mon, Aug 5, 2019 at 7:43 AM Neil Armstrong <narmstrong@baylibre.com> wrote:
>>
>> Now that we have the DT validation in place, let's convert the device tree
>> bindings for the Amlogic Synopsys DW-HDMI specifics over to YAML schemas.
>>
>> The original example and usage of clock-names uses a reversed "isfr"
>> and "iahb" clock-names, the rewritten YAML bindings uses the reversed
>> instead of fixing the device trees order.
>>
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>> ---
>> .../display/amlogic,meson-dw-hdmi.txt | 119 -------------
>> .../display/amlogic,meson-dw-hdmi.yaml | 160 ++++++++++++++++++
>> 2 files changed, 160 insertions(+), 119 deletions(-)
>> delete mode 100644 Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.txt
>> create mode 100644 Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml
>
>> diff --git a/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml b/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml
>> new file mode 100644
>> index 000000000000..1212aa7a624f
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml
>> @@ -0,0 +1,160 @@
>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>> +# Copyright 2019 BayLibre, SAS
>> +%YAML 1.2
>> +---
>> +$id: "http://devicetree.org/schemas/display/amlogic,meson-dw-hdmi.yaml#"
>> +$schema: "http://devicetree.org/meta-schemas/core.yaml#"
>> +
>> +title: Amlogic specific extensions to the Synopsys Designware HDMI Controller
>> +
>> +maintainers:
>> + - Neil Armstrong <narmstrong@baylibre.com>
>> +
>> +description: |
>> + The Amlogic Meson Synopsys Designware Integration is composed of
>> + - A Synopsys DesignWare HDMI Controller IP
>> + - A TOP control block controlling the Clocks and PHY
>> + - A custom HDMI PHY in order to convert video to TMDS signal
>> + ___________________________________
>> + | HDMI TOP |<= HPD
>> + |___________________________________|
>> + | | |
>> + | Synopsys HDMI | HDMI PHY |=> TMDS
>> + | Controller |________________|
>> + |___________________________________|<=> DDC
>> +
>> + The HDMI TOP block only supports HPD sensing.
>> + The Synopsys HDMI Controller interrupt is routed through the
>> + TOP Block interrupt.
>> + Communication to the TOP Block and the Synopsys HDMI Controller is done
>> + via a pair of dedicated addr+read/write registers.
>> + The HDMI PHY is configured by registers in the HHI register block.
>> +
>> + Pixel data arrives in "4:4:4" format from the VENC block and the VPU HDMI mux
>> + selects either the ENCI encoder for the 576i or 480i formats or the ENCP
>> + encoder for all the other formats including interlaced HD formats.
>> +
>> + The VENC uses a DVI encoder on top of the ENCI or ENCP encoders to generate
>> + DVI timings for the HDMI controller.
>> +
>> + Amlogic Meson GXBB, GXL and GXM SoCs families embeds the Synopsys DesignWare
>> + HDMI TX IP version 2.01a with HDCP and I2C & S/PDIF
>> + audio source interfaces.
>> +
>> + The following table lists for each supported model the port number
>> + corresponding to each HDMI output and input.
>> +
>> + Port 0 Port 1
>> + -----------------------------------------
>> + S905 (GXBB) VENC Input TMDS Output
>> + S905X (GXL) VENC Input TMDS Output
>> + S905D (GXL) VENC Input TMDS Output
>> + S912 (GXM) VENC Input TMDS Output
>> + S905X2 (G12A) VENC Input TMDS Output
>> + S905Y2 (G12A) VENC Input TMDS Output
>> + S905D2 (G12A) VENC Input TMDS Output
>
> Does this ever change?
Not for this one, I could remove the table and add the description
in port@0 and port@1.
>
>> +
>> +properties:
>> + compatible:
>> + oneOf:
>> + - items:
>> + - enum:
>> + - amlogic,meson-gxbb-dw-hdmi # GXBB (S905)
>> + - amlogic,meson-gxl-dw-hdmi # GXL (S905X, S905D)
>> + - amlogic,meson-gxm-dw-hdmi # GXM (S912)
>> + - const: amlogic,meson-gx-dw-hdmi
>> + - enum:
>> + - amlogic,meson-g12a-dw-hdmi # G12A (S905X2, S905Y2, S905D2)
>> +
>> + reg:
>> + maxItems: 1
>> +
>> + interrupts:
>> + maxItems: 1
>> +
>> + clocks:
>> + minItems: 3
>> +
>> + clock-names:
>> + items:
>> + - const: isfr
>> + - const: iahb
>> + - const: venci
>> +
>> + resets:
>> + minItems: 3
>> +
>> + reset-names:
>> + items:
>> + - const: hdmitx_apb
>> + - const: hdmitx
>> + - const: hdmitx_phy
>> +
>> + hdmi-supply:
>> + description: phandle to an external 5V regulator to power the HDMI logic
>> + allOf:
>> + - $ref: /schemas/types.yaml#/definitions/phandle
>> +
>> + port@0:
>> + type: object
>> + description:
>> + A port node modeled using the OF graph
>> + bindings specified in Documentation/devicetree/bindings/graph.txt.
>
> Would be better to say this is the VENC (or ...? input and drop the
> reference (as I expect graph.txt will be replaced with graph.yaml).
Yes
>
>> +
>> + port@1:
>> + type: object
>> + description:
>> + A port node modeled using the OF graph
>> + bindings specified in Documentation/devicetree/bindings/graph.txt.
>> +
>> + "#address-cells":
>> + const: 1
>> +
>> + "#size-cells":
>> + const: 0
>> +
>> +required:
>> + - compatible
>> + - reg
>> + - interrupts
>> + - clocks
>> + - clock-names
>> + - resets
>> + - reset-names
>> + - port@0
>> + - port@1
>> + - "#address-cells"
>> + - "#size-cells"
>
> Should be able to add an 'additionalProperties: false' here.
Ok
>
>> +
>> +examples:
>> + - |
>> + hdmi_tx: hdmi-tx@c883a000 {
>> + compatible = "amlogic,meson-gxbb-dw-hdmi", "amlogic,meson-gx-dw-hdmi";
>> + reg = <0xc883a000 0x1c>;
>> + interrupts = <57>;
>> + resets = <&reset_apb>, <&reset_hdmitx>, <&reset_hdmitx_phy>;
>> + reset-names = "hdmitx_apb", "hdmitx", "hdmitx_phy";
>> + clocks = <&clk_isfr>, <&clk_iahb>, <&clk_venci>;
>> + clock-names = "isfr", "iahb", "venci";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + /* VPU VENC Input */
>> + hdmi_tx_venc_port: port@0 {
>> + reg = <0>;
>> +
>> + hdmi_tx_in: endpoint {
>> + remote-endpoint = <&hdmi_tx_out>;
>> + };
>> + };
>> +
>> + /* TMDS Output */
>> + hdmi_tx_tmds_port: port@1 {
>> + reg = <1>;
>> +
>> + hdmi_tx_tmds_out: endpoint {
>> + remote-endpoint = <&hdmi_connector_in>;
>> + };
>> + };
>> + };
>> +
>> --
>> 2.22.0
>>
^ permalink raw reply
* [PATCH] dt-bindings: arm: amlogic: fix x96-max/sei510 section in amlogic.yaml
From: Neil Armstrong @ 2019-08-06 7:55 UTC (permalink / raw)
To: khilman
Cc: robh+dt, devicetree, linux-amlogic, linux-kernel,
Christian Hewitt, Neil Armstrong
From: Christian Hewitt <christianshewitt@gmail.com>
Move amediatech,x96-max and seirobotics,sei510 to the S905D2 section and
update the S905D2 description to S905D2/X2/Y2.
Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
Documentation/devicetree/bindings/arm/amlogic.yaml | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml
index 325c6fd3566d..4668064dd7e5 100644
--- a/Documentation/devicetree/bindings/arm/amlogic.yaml
+++ b/Documentation/devicetree/bindings/arm/amlogic.yaml
@@ -91,13 +91,11 @@ properties:
- description: Boards with the Amlogic Meson GXL S905X SoC
items:
- enum:
- - amediatech,x96-max
- amlogic,p212
- hwacom,amazetv
- khadas,vim
- libretech,cc
- nexbox,a95x
- - seirobotics,sei510
- const: amlogic,s905x
- const: amlogic,meson-gxl
@@ -129,10 +127,12 @@ properties:
- const: amlogic,a113d
- const: amlogic,meson-axg
- - description: Boards with the Amlogic Meson G12A S905D2 SoC
+ - description: Boards with the Amlogic Meson G12A S905D2/X2/Y2 SoC
items:
- enum:
+ - amediatech,x96-max
- amlogic,u200
+ - seirobotics,sei510
- const: amlogic,g12a
- description: Boards with the Amlogic Meson G12B S922X SoC
--
2.22.0
^ permalink raw reply related
* Re: [PATCH v8 00/11] add USB GPIO based connection detection driver
From: Chunfeng Yun @ 2019-08-06 7:48 UTC (permalink / raw)
To: Linus Walleij
Cc: Rob Herring, Greg Kroah-Hartman, Biju Das, Mark Rutland,
Matthias Brugger, Adam Thomson, Li Jun, Badhri Jagan Sridharan,
Heikki Krogerus, Hans de Goede, Andy Shevchenko, Min Guo,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-kernel@vger.kernel.org, linux-usb, Linux ARM, ARM/Mediate
In-Reply-To: <CACRpkdaBT24JPH_VsKtgp6fjWtVuqM50rXkDVYKmLHgR5hdJzA@mail.gmail.com>
On Mon, 2019-08-05 at 12:06 +0200, Linus Walleij wrote:
> On Wed, Jul 24, 2019 at 10:51 AM Chunfeng Yun <chunfeng.yun@mediatek.com> wrote:
>
> > Because the USB Connector is introduced and the requirement of
> > usb-connector.txt binding, the old way using extcon to support
> > USB Dual-Role switch is now deprecated, meanwhile there is no
> > available common driver when use Type-B connector, typically
> > using an input GPIO to detect USB ID pin.
>
> However while this was going on,
> drivers/extcon/extcon-fsa9480.c was merged and that detects
> not only GPIO on the USB port but multiplexed usecases such
> as UART over the USB micro PHY (and no that UART is not
> a USB UART, but an actual RX/TX over D-/D+).
>
> That driver also measure a whole slew of funny resistance
> values on the ID pin, that is how it does its job.
I look into the spec of fsa9480, it indeed detect many USB accessories.
But this driver is used for simplest cases that only uses micro
receptacle with id-pin/vbus-pin
>
> But for just "hey I'm plugged in" we can surely keep this
> ID on GPIO detection in the USB subsystem.
Sorry, you mean provide a common API? could you please describe more
clearer about your suggestion?
Introducing a single driver using usb_role_switch will help to keep
transparent for USB controller driver, no matter it uses type-c or micro
Thanks a lot
>
> I just get a bit insecure about how we should ideally
> handle these "funny-PHY's".
>
> Yours,
> Linus Walleij
^ permalink raw reply
* RE: [PATCH 0/6] hwspinlock: allow sharing of hwspinlocks
From: Fabien DESSENNE @ 2019-08-06 7:43 UTC (permalink / raw)
To: s-anna@ti.com
Cc: Ohad Ben-Cohen, Rob Herring, Mark Rutland, Maxime Coquelin,
Alexandre TORGUE, Jonathan Corbet,
linux-remoteproc@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org,
Benjamin GAIGNARD, Bjorn Andersson
In-Reply-To: <20190805174659.GA23928@tuxbook-pro>
Hi Suman,
Could you please let us know your thoughts or comments?
BR
Fabien
> -----Original Message-----
> From: Bjorn Andersson <bjorn.andersson@linaro.org>
> Sent: lundi 5 août 2019 19:47
> To: Fabien DESSENNE <fabien.dessenne@st.com>
> Cc: Ohad Ben-Cohen <ohad@wizery.com>; Rob Herring <robh+dt@kernel.org>;
> Mark Rutland <mark.rutland@arm.com>; Maxime Coquelin
> <mcoquelin.stm32@gmail.com>; Alexandre TORGUE
> <alexandre.torgue@st.com>; Jonathan Corbet <corbet@lwn.net>; linux-
> remoteproc@vger.kernel.org; devicetree@vger.kernel.org; linux-
> kernel@vger.kernel.org; linux-stm32@st-md-mailman.stormreply.com; linux-arm-
> kernel@lists.infradead.org; linux-doc@vger.kernel.org; Benjamin GAIGNARD
> <benjamin.gaignard@st.com>
> Subject: Re: [PATCH 0/6] hwspinlock: allow sharing of hwspinlocks
>
> On Mon 05 Aug 01:48 PDT 2019, Fabien DESSENNE wrote:
>
> >
> > On 01/08/2019 9:14 PM, Bjorn Andersson wrote:
> > > On Wed 13 Mar 08:50 PDT 2019, Fabien Dessenne wrote:
> > >
> > >> The current implementation does not allow two different devices to
> > >> use a common hwspinlock. This patch set proposes to have, as an
> > >> option, some hwspinlocks shared between several users.
> > >>
> > >> Below is an example that explain the need for this:
> > >> exti: interrupt-controller@5000d000 {
> > >> compatible = "st,stm32mp1-exti", "syscon";
> > >> interrupt-controller;
> > >> #interrupt-cells = <2>;
> > >> reg = <0x5000d000 0x400>;
> > >> hwlocks = <&hsem 1>;
> > >> };
> > >> The two drivers (stm32mp1-exti and syscon) refer to the same hwlock.
> > >> With the current hwspinlock implementation, only the first driver
> > >> succeeds in requesting (hwspin_lock_request_specific) the hwlock.
> > >> The second request fails.
> > >>
> > >>
> > >> The proposed approach does not modify the API, but extends the DT
> 'hwlocks'
> > >> property with a second optional parameter (the first one identifies
> > >> an
> > >> hwlock) that specifies whether an hwlock is requested for exclusive
> > >> usage (current behavior) or can be shared between several users.
> > >> Examples:
> > >> hwlocks = <&hsem 8>; Ref to hwlock #8 for exclusive usage
> > >> hwlocks = <&hsem 8 0>; Ref to hwlock #8 for exclusive (0) usage
> > >> hwlocks = <&hsem 8 1>; Ref to hwlock #8 for shared (1) usage
> > >>
> > >> As a constraint, the #hwlock-cells value must be 1 or 2.
> > >> In the current implementation, this can have theorically any value but:
> > >> - all of the exisiting drivers use the same value : 1.
> > >> - the framework supports only one value : 1 (see implementation of
> > >> of_hwspin_lock_simple_xlate())
> > >> Hence, it shall not be a problem to restrict this value to 1 or 2
> > >> since it won't break any driver.
> > >>
> > > Hi Fabien,
> > >
> > > Your series looks good, but it makes me wonder why the hardware
> > > locks should be an exclusive resource.
> > >
> > > How about just making all (specific) locks shared?
> >
> > Hi Bjorn,
> >
> > Making all locks shared is a possible implementation (my first
> > implementation was going this way) but there are some drawbacks we
> > must be aware of:
> >
> > A/ This theoretically break the legacy behavior (the legacy works with
> > exclusive (UNUSED radix tag) usage). As a consequence, an existing
> > driver that is currently failing to request a lock (already claimed by
> > another
> > user) would now work fine. Not sure that there are such drivers, so
> > this point is probably not a real issue.
> >
>
> Right, it's possible that a previously misconfigured system now successfully
> probes more than one device that uses a particular spinlock. But such system
> would be suffering from issues related to e.g.
> probe ordering.
>
> So I think we should ignore this issue.
>
> > B/ This would introduce some inconsistency between the two 'request'
> > API which are hwspin_lock_request() and hwspin_lock_request_specific().
> > hwspin_lock_request() looks for an unused lock, so requests for an
> > exclusive usage. On the other side, request_specific() would request shared
> locks.
> > Worst the following sequence can transform an exclusive usage into a
> > shared
> >
>
> There is already an inconsistency in between these; as with above any system
> that uses both request() and request_specific() will be suffering from intermittent
> failures due to probe ordering.
>
> > one:
> > -hwspin_lock_request() -> returns Id#0 (exclusive)
> > -hwspin_lock_request() -> returns Id#1 (exclusive)
> > -hwspin_lock_request_specific(0) -> returns Id#0 and makes Id#0
> > shared Honestly I am not sure that this is a real issue, but it's
> > better to have it in mind before we take ay decision
>
> The case where I can see a
> problem with this would be if the two clients somehow would nest their locking
> regions.
>
> But generally I think this could consider this an improvement, because the
> request_specific() would now be able to acquire its hwlock, with some additional
> contention due to the multiple use.
>
> > I could not find any driver using the hwspin_lock_request() API, we
> > may decide to remove (or to make deprecated) this API, having
> > everything 'shared without any conditions'.
> >
>
> It would be nice to have an upstream user of this API.
>
> >
> > I can see three options:
> > 1- Keep my initial proposition
> > 2- Have hwspin_lock_request_specific() using shared locks and
> > hwspin_lock_request() using unused (so 'initially' exclusive) locks.
> > 3- Have hwspin_lock_request_specific() using shared locks and
> > remove/make deprecated hwspin_lock_request().
> >
> > Just let me know what is your preference.
> >
>
> I think we should start with #2 and would like input from e.g. Suman regarding #3.
>
> Regards,
> Bjorn
>
> > BR
> >
> > Fabien
> >
> > >
> > > Regards,
> > > Bjorn
> > >
> > >> Fabien Dessenne (6):
> > >> dt-bindings: hwlock: add support of shared locks
> > >> hwspinlock: allow sharing of hwspinlocks
> > >> dt-bindings: hwlock: update STM32 #hwlock-cells value
> > >> ARM: dts: stm32: Add hwspinlock node for stm32mp157 SoC
> > >> ARM: dts: stm32: Add hwlock for irqchip on stm32mp157
> > >> ARM: dts: stm32: hwlocks for GPIO for stm32mp157
> > >>
> > >> .../devicetree/bindings/hwlock/hwlock.txt | 27 +++++--
> > >> .../bindings/hwlock/st,stm32-hwspinlock.txt | 6 +-
> > >> Documentation/hwspinlock.txt | 10 ++-
> > >> arch/arm/boot/dts/stm32mp157-pinctrl.dtsi | 2 +
> > >> arch/arm/boot/dts/stm32mp157c.dtsi | 10 +++
> > >> drivers/hwspinlock/hwspinlock_core.c | 82 +++++++++++++++++-
> ----
> > >> drivers/hwspinlock/hwspinlock_internal.h | 2 +
> > >> 7 files changed, 108 insertions(+), 31 deletions(-)
> > >>
> > >> --
> > >> 2.7.4
> > >>
^ permalink raw reply
* Re: [RFCv2 0/9] dt-bindings: first tentative of conversion to yaml format
From: Neil Armstrong @ 2019-08-06 7:42 UTC (permalink / raw)
To: Rob Herring
Cc: Philipp Zabel, devicetree, LINUX-WATCHDOG, Jassi Brar, linux-spi,
open list:HARDWARE RANDOM NUMBER GENERATOR CORE,
open list:SERIAL DRIVERS, linux-amlogic, Kishon Vijay Abraham I,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <CAL_JsqJzwtSXX0nrS7RBP8u-e=16SiWOBjLrvy8Amc08PfpXag@mail.gmail.com>
Hi Rob,
On 05/08/2019 23:51, Rob Herring wrote:
> On Mon, Aug 5, 2019 at 6:03 AM Neil Armstrong <narmstrong@baylibre.com> wrote:
>>
>> This is a first tentative to convert some of the simplest Amlogic
>> dt-bindings to the yaml format.
>>
>> All have been tested using :
>> $ make ARCH=arm64 dtbs_check
>>
>> Issues with the amlogic arm64 DTs has already been identified thanks
>> to the validation scripts. The DT fixes will be pushed once these yaml
>> bindings are acked.
>>
>> Changes since rfc v1:
>> - Fixed bindings according to Rob's comments
>> - Added commit log
>> - renamed yaml files using amlogic prefix
>>
>> Neil Armstrong (9):
>> dt-bindings: mailbox: meson-mhu: convert to yaml
>> dt-bindings: rng: amlogic,meson-rng: convert to yaml
>> dt-bindings: spi: meson: convert to yaml
>> dt-bindings: reset: amlogic,meson-reset: convert to yaml
>> dt-bindings: arm: amlogic: amlogic,meson-gx-ao-secure: convert to yaml
>> dt-bindings: phy: meson-g12a-usb2-phy: convert to yaml
>> dt-bindings: phy: meson-g12a-usb3-pcie-phy: convert to yaml
>> dt-bindings: serial: meson-uart: convert to yaml
>> dt-bindings: watchdog: meson-gxbb-wdt: convert to yaml
>
> For the series,
>
> Reviewed-by: Rob Herring <robh@kernel.org>
>
> What's your merge plan? Do you want me to take the whole series?
I planned to split them for each subsystem, but it may be much simpler
if you take the whole serie.
Neil
>
> Rob
>
^ permalink raw reply
* Re: [RFCv2 4/9] dt-bindings: reset: amlogic,meson-reset: convert to yaml
From: Philipp Zabel @ 2019-08-06 7:41 UTC (permalink / raw)
To: Neil Armstrong, robh+dt; +Cc: linux-amlogic, linux-arm-kernel, devicetree
In-Reply-To: <20190805120320.32282-5-narmstrong@baylibre.com>
On Mon, 2019-08-05 at 14:03 +0200, Neil Armstrong wrote:
> Now that we have the DT validation in place, let's convert the device tree
> bindings for the Amlogic Reset controller over to a YAML schemas.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Let me know if you want me to pick up this patch, otherwise
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
to merge with the rest of the series.
regards
Philipp
> ---
> .../bindings/reset/amlogic,meson-reset.txt | 19 ----------
> .../bindings/reset/amlogic,meson-reset.yaml | 37 +++++++++++++++++++
> 2 files changed, 37 insertions(+), 19 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/reset/amlogic,meson-reset.txt
> create mode 100644 Documentation/devicetree/bindings/reset/amlogic,meson-reset.yaml
>
> diff --git a/Documentation/devicetree/bindings/reset/amlogic,meson-reset.txt b/Documentation/devicetree/bindings/reset/amlogic,meson-reset.txt
> deleted file mode 100644
> index 28ef6c295c76..000000000000
> --- a/Documentation/devicetree/bindings/reset/amlogic,meson-reset.txt
> +++ /dev/null
> @@ -1,19 +0,0 @@
> -Amlogic Meson SoC Reset Controller
> -=======================================
> -
> -Please also refer to reset.txt in this directory for common reset
> -controller binding usage.
> -
> -Required properties:
> -- compatible: Should be "amlogic,meson8b-reset", "amlogic,meson-gxbb-reset" or
> - "amlogic,meson-axg-reset".
> -- reg: should contain the register address base
> -- #reset-cells: 1, see below
> -
> -example:
> -
> -reset: reset-controller {
> - compatible = "amlogic,meson-gxbb-reset";
> - reg = <0x0 0x04404 0x0 0x20>;
> - #reset-cells = <1>;
> -};
> diff --git a/Documentation/devicetree/bindings/reset/amlogic,meson-reset.yaml b/Documentation/devicetree/bindings/reset/amlogic,meson-reset.yaml
> new file mode 100644
> index 000000000000..00917d868d58
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/reset/amlogic,meson-reset.yaml
> @@ -0,0 +1,37 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +# Copyright 2019 BayLibre, SAS
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/reset/amlogic,meson-reset.yaml#"
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#"
> +
> +title: Amlogic Meson SoC Reset Controller
> +
> +maintainers:
> + - Neil Armstrong <narmstrong@baylibre.com>
> +
> +properties:
> + compatible:
> + enum:
> + - amlogic,meson8b-reset # Reset Controller on Meson8b and compatible SoCs
> + - amlogic,meson-gxbb-reset # Reset Controller on GXBB and compatible SoCs
> + - amlogic,meson-axg-reset # Reset Controller on AXG and compatible SoCs
> +
> + reg:
> + maxItems: 1
> +
> + "#reset-cells":
> + const: 1
> +
> +required:
> + - compatible
> + - reg
> + - "#reset-cells"
> +
> +examples:
> + - |
> + reset-controller@c884404 {
> + compatible = "amlogic,meson-gxbb-reset";
> + reg = <0xc884404 0x20>;
> + #reset-cells = <1>;
> + };
^ permalink raw reply
* Re: [PATCH v2 3/3] soc/tegra: regulators: Add regulators coupler for Tegra30
From: Peter De Schrijver @ 2019-08-06 7:30 UTC (permalink / raw)
To: Dmitry Osipenko
Cc: Rob Herring, Thierry Reding, Jonathan Hunter, Mark Brown,
devicetree, linux-tegra, linux-kernel
In-Reply-To: <1a9464b3-6e0e-00ff-64d8-b3abf7982dfb@gmail.com>
On Mon, Aug 05, 2019 at 02:03:29PM +0300, Dmitry Osipenko wrote:
> 05.08.2019 11:33, Peter De Schrijver пишет:
> > On Fri, Aug 02, 2019 at 05:39:23PM +0300, Dmitry Osipenko wrote:
> >> 02.08.2019 17:05, Peter De Schrijver пишет:
> >>> On Thu, Jul 25, 2019 at 06:18:32PM +0300, Dmitry Osipenko wrote:
> >>>> Add regulators coupler for Tegra30 SoCs that performs voltage balancing
> >>>> of a coupled regulators and thus provides voltage scaling functionality.
> >>>>
> >>>> There are 2 coupled regulators on all Tegra30 SoCs: CORE and CPU. The
> >>>> coupled regulator voltages shall be in a range of 300mV from each other
> >>>> and CORE voltage shall be higher than the CPU by N mV, where N depends
> >>>> on the CPU voltage.
> >>>>
> >>>> Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
> >>>> ---
> >>>> drivers/soc/tegra/Kconfig | 4 +
> >>>> drivers/soc/tegra/Makefile | 1 +
> >>>> drivers/soc/tegra/regulators-tegra30.c | 316 +++++++++++++++++++++++++
> >>>> 3 files changed, 321 insertions(+)
> >>>> create mode 100644 drivers/soc/tegra/regulators-tegra30.c
> >>>>
> >>> ...
> >>>
> >>>> +
> >>>> +static int tegra30_core_cpu_limit(int cpu_uV)
> >>>> +{
> >>>> + if (cpu_uV < 800000)
> >>>> + return 950000;
> >>>> +
> >>>> + if (cpu_uV < 900000)
> >>>> + return 1000000;
> >>>> +
> >>>> + if (cpu_uV < 1000000)
> >>>> + return 1100000;
> >>>> +
> >>>> + if (cpu_uV < 1100000)
> >>>> + return 1200000;
> >>>> +
> >>>> + if (cpu_uV < 1250000) {
> >>>> + switch (tegra_sku_info.cpu_speedo_id) {
> >>>> + case 0 ... 1:
> >>> Aren't we supposed to add /* fall through */ here now?
> >>
> >> There is no compiler warning if there is nothing in-between of the
> >> case-switches, so annotation isn't really necessary here. Of course it
> >> is possible to add an explicit annotation just to make clear the
> >> fall-through intention.
> >>
> >
> > Ah. Ok. Whatever you want then :)
>
> I'll add the comments if there will be a need to re-spin this series.
>
> >>>> + case 4:
> >>>> + case 7 ... 8:
> >>>> + return 1200000;
> >>>> +
> >>>> + default:
> >>>> + return 1300000;
> >>>> + }
> >>>> + }
> >>>> +
> >>>
> >>> Other than that, this looks ok to me.
> >>
> >> Awesome, thank you very much! Explicit ACK will be appreciated as well.
> >
> > Acked-By: Peter De Schrijver <pdeschrijver@nvidia.com>
All of them.
Peter.
^ permalink raw reply
* Re: [PATCH v4 07/10] regulator: mt6358: Add support for MT6358 regulator
From: Hsin-hsiung Wang @ 2019-08-06 7:28 UTC (permalink / raw)
To: Mark Brown
Cc: Mark Rutland, Alessandro Zummo, Alexandre Belloni, srv_heupstream,
devicetree, Sean Wang, Liam Girdwood, linux-kernel,
Richard Fontana, Rob Herring, linux-mediatek, Allison Randal,
linux-rtc, Matthias Brugger, Thomas Gleixner, Eddie Huang,
Lee Jones, Kate Stewart, linux-arm-kernel
In-Reply-To: <20190805131030.GE6432@sirena.org.uk>
Hi Mark,
On Mon, 2019-08-05 at 14:10 +0100, Mark Brown wrote:
> On Mon, Aug 05, 2019 at 01:21:55PM +0800, Hsin-Hsiung Wang wrote:
>
> > +static const u32 vmch_voltages[] = {
> > + 2900000, 3000000, 3300000,
> > +};
>
> > +static const u32 vemc_voltages[] = {
> > + 2900000, 3000000, 3300000,
> > +};
>
> Several of these tables appear to be identical.
>
I will use the same voltage table in the next patch.
> > +static inline unsigned int mt6358_map_mode(unsigned int mode)
> > +{
> > + return mode == MT6358_BUCK_MODE_AUTO ?
> > + REGULATOR_MODE_NORMAL : REGULATOR_MODE_FAST;
> > +}
>
> There is no need for this to be an inline and please write normal
> conditional statements to improve legibility. There's other examples in
> the driver.
>
will fix it in the next patch.
> > +static int mt6358_get_buck_voltage_sel(struct regulator_dev *rdev)
> > +{
> > + int ret, regval;
> > + struct mt6358_regulator_info *info = rdev_get_drvdata(rdev);
> > +
> > + ret = regmap_read(rdev->regmap, info->da_vsel_reg, ®val);
> > + if (ret != 0) {
> > + dev_info(&rdev->dev,
> > + "Failed to get mt6358 Buck %s vsel reg: %d\n",
> > + info->desc.name, ret);
>
> dev_err() for errors here and throughout the driver.
>
will fix it in the next patch.
> > + return ret;
> > + }
> > +
> > + ret = (regval >> info->da_vsel_shift) & info->da_vsel_mask;
> > +
> > + return ret;
> > +}
>
> This looks like a standard get_voltage_sel_regmap()?
>
MT6358 has buck voltage status registers to show the actual output
voltage and the registers are different from the voltage setting
registers.
We want to get the actual voltage output, so we use the da_vsel status
registers here.
> > +err_mode:
> > + if (ret != 0)
> > + return ret;
> > +
> > + return 0;
>
> Or just return ret unconditionally?
will modify it to return ret unconditionally in the next patch.
Thanks a lot.
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply
* Re: [PATCH 15/16] net: phy: adin: add ethtool get_stats support
From: Ardelean, Alexandru @ 2019-08-06 7:18 UTC (permalink / raw)
To: andrew@lunn.ch
Cc: davem@davemloft.net, hkallweit1@gmail.com,
devicetree@vger.kernel.org, mark.rutland@arm.com,
linux-kernel@vger.kernel.org, f.fainelli@gmail.com,
netdev@vger.kernel.org, robh+dt@kernel.org
In-Reply-To: <20190805153058.GU24275@lunn.ch>
On Mon, 2019-08-05 at 17:30 +0200, Andrew Lunn wrote:
> [External]
>
> On Mon, Aug 05, 2019 at 07:54:52PM +0300, Alexandru Ardelean wrote:
> > This change implements retrieving all the error counters from the PHY.
> > The PHY supports several error counters/stats. The `Mean Square Errors`
> > status values are only valie when a link is established, and shouldn't be
> > incremented. These values characterize the quality of a signal.
>
> I think you mean accumulated, not incremented?
accumulated sounds better;
> > The rest of the error counters are self-clearing on read.
> > Most of them are reports from the Frame Checker engine that the PHY has.
> >
> > Not retrieving the `LPI Wake Error Count Register` here, since that is used
> > by the PHY framework to check for any EEE errors. And that register is
> > self-clearing when read (as per IEEE spec).
> >
> > Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
> > ---
> > drivers/net/phy/adin.c | 108 +++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 108 insertions(+)
> >
> > diff --git a/drivers/net/phy/adin.c b/drivers/net/phy/adin.c
> > index a1f3456a8504..04896547dac8 100644
> > --- a/drivers/net/phy/adin.c
> > +++ b/drivers/net/phy/adin.c
> > @@ -103,6 +103,32 @@ static struct clause22_mmd_map clause22_mmd_map[] = {
> > { MDIO_MMD_PCS, MDIO_PCS_EEE_WK_ERR, ADIN1300_LPI_WAKE_ERR_CNT_REG },
> > };
> >
> > +struct adin_hw_stat {
> > + const char *string;
> > + u16 reg1;
> > + u16 reg2;
> > + bool do_not_inc;
>
> do_not_accumulate? or reverse its meaning, clear_on_read?
do_not_accumulate works;
there are only 4 regs that need this property set to true
>
> Andrew
^ permalink raw reply
* Re: [PATCH 15/16] net: phy: adin: add ethtool get_stats support
From: Ardelean, Alexandru @ 2019-08-06 7:11 UTC (permalink / raw)
To: andrew@lunn.ch
Cc: davem@davemloft.net, hkallweit1@gmail.com,
devicetree@vger.kernel.org, mark.rutland@arm.com,
linux-kernel@vger.kernel.org, f.fainelli@gmail.com,
netdev@vger.kernel.org, robh+dt@kernel.org
In-Reply-To: <20190805152832.GT24275@lunn.ch>
On Mon, 2019-08-05 at 17:28 +0200, Andrew Lunn wrote:
> [External]
>
> > +struct adin_hw_stat {
> > + const char *string;
> > +static void adin_get_strings(struct phy_device *phydev, u8 *data)
> > +{
> > + int i;
> > +
> > + for (i = 0; i < ARRAY_SIZE(adin_hw_stats); i++) {
> > + memcpy(data + i * ETH_GSTRING_LEN,
> > + adin_hw_stats[i].string, ETH_GSTRING_LEN);
>
> You define string as a char *. So it will be only as long as it should
> be. However memcpy always copies ETH_GSTRING_LEN bytes, doing off the
> end of the string and into whatever follows.
>
hmm, will use strlcpy()
i blindedly copied memcpy() from some other driver
>
> > + }
> > +}
> > +
> > +static int adin_read_mmd_stat_regs(struct phy_device *phydev,
> > + struct adin_hw_stat *stat,
> > + u32 *val)
> > +{
> > + int ret;
> > +
> > + ret = phy_read_mmd(phydev, MDIO_MMD_VEND1, stat->reg1);
> > + if (ret < 0)
> > + return ret;
> > +
> > + *val = (ret & 0xffff);
> > +
> > + if (stat->reg2 == 0)
> > + return 0;
> > +
> > + ret = phy_read_mmd(phydev, MDIO_MMD_VEND1, stat->reg2);
> > + if (ret < 0)
> > + return ret;
> > +
> > + *val <<= 16;
> > + *val |= (ret & 0xffff);
>
> Does the hardware have a snapshot feature? Is there a danger that
> between the two reads stat->reg1 rolls over and you end up with too
> big a value?
i'm afraid i don't understand about the snapshot feature you are mentioning;
i.e. i don't remember seeing it in other chips;
regarding the danger that stat->reg1 rolls over, i guess that is possible, but it's a bit hard to guard against;
i guess if it ends up in that scenario, [for many counters] things would be horribly bad, and the chip, or cabling would
be unusable;
not sure if this answer is sufficient/satisfactory;
thanks
>
> Andrew
^ permalink raw reply
* Re: [PATCH 16/16] dt-bindings: net: add bindings for ADIN PHY driver
From: Ardelean, Alexandru @ 2019-08-06 7:03 UTC (permalink / raw)
To: andrew@lunn.ch
Cc: davem@davemloft.net, hkallweit1@gmail.com,
devicetree@vger.kernel.org, mark.rutland@arm.com,
linux-kernel@vger.kernel.org, f.fainelli@gmail.com,
netdev@vger.kernel.org, robh+dt@kernel.org
In-Reply-To: <20190805141100.GG24275@lunn.ch>
On Mon, 2019-08-05 at 16:11 +0200, Andrew Lunn wrote:
> [External]
>
> > + adi,rx-internal-delay:
> > + $ref: /schemas/types.yaml#/definitions/uint32
> > + description: |
> > + RGMII RX Clock Delay used only when PHY operates in RGMII mode (phy-mode
> > + is "rgmii-id", "rgmii-rxid", "rgmii-txid") see `dt-bindings/net/adin.h`
> > + default value is 0 (which represents 2 ns)
> > + enum: [ 0, 1, 2, 6, 7 ]
>
> We want these numbers to be in ns. So the default value would actually
> be 2. The driver needs to convert the number in DT to a value to poke
> into a PHY register. Please rename the property adi,rx-internal-delay-ns.
ack;
also, good point about ns units and PHY driver to convert it to reg values;
>
> > +
> > + adi,tx-internal-delay:
> > + $ref: /schemas/types.yaml#/definitions/uint32
> > + description: |
> > + RGMII TX Clock Delay used only when PHY operates in RGMII mode (phy-mode
> > + is "rgmii-id", "rgmii-rxid", "rgmii-txid") see `dt-bindings/net/adin.h`
> > + default value is 0 (which represents 2 ns)
> > + enum: [ 0, 1, 2, 6, 7 ]
>
> Same here.
>
> > +
> > + adi,fifo-depth:
> > + $ref: /schemas/types.yaml#/definitions/uint32
> > + description: |
> > + When operating in RMII mode, this option configures the FIFO depth.
> > + See `dt-bindings/net/adin.h`.
> > + enum: [ 0, 1, 2, 3, 4, 5 ]
>
> Units? You should probably rename this adi,fifo-depth-bits and list
> the valid values in bits.
units are bits;
will adapt this
>
> > +
> > + adi,eee-enabled:
> > + description: |
> > + Advertise EEE capabilities on power-up/init (default disabled)
> > + type: boolean
>
> It is not the PHY which decides this. The MAC indicates if it is EEE
> capable to phylib. phylib looks into the PHY registers to determine if
> the PHY supports EEE. phylib will then enable EEE
> advertisement. Please remove this, and ensure EEE is disabled by
> default.
ack;
will remove
>
> Andrew
^ permalink raw reply
* Re: [PATCH 16/16] dt-bindings: net: add bindings for ADIN PHY driver
From: Ardelean, Alexandru @ 2019-08-06 6:57 UTC (permalink / raw)
To: andrew@lunn.ch
Cc: davem@davemloft.net, hkallweit1@gmail.com,
devicetree@vger.kernel.org, mark.rutland@arm.com,
linux-kernel@vger.kernel.org, f.fainelli@gmail.com,
netdev@vger.kernel.org, robh+dt@kernel.org
In-Reply-To: <20190805142754.GL24275@lunn.ch>
On Mon, 2019-08-05 at 16:27 +0200, Andrew Lunn wrote:
> [External]
>
> On Mon, Aug 05, 2019 at 07:54:53PM +0300, Alexandru Ardelean wrote:
> > This change adds bindings for the Analog Devices ADIN PHY driver, detailing
> > all the properties implemented by the driver.
> >
> > Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
> > ---
> > .../devicetree/bindings/net/adi,adin.yaml | 93 +++++++++++++++++++
> > MAINTAINERS | 2 +
> > include/dt-bindings/net/adin.h | 26 ++++++
> > 3 files changed, 121 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/net/adi,adin.yaml
> > create mode 100644 include/dt-bindings/net/adin.h
> >
> > diff --git a/Documentation/devicetree/bindings/net/adi,adin.yaml
> > b/Documentation/devicetree/bindings/net/adi,adin.yaml
> > new file mode 100644
> > index 000000000000..fcf884bb86f7
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/adi,adin.yaml
> > @@ -0,0 +1,93 @@
> > +# SPDX-License-Identifier: GPL-2.0+
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/net/adi,adin.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Analog Devices ADIN1200/ADIN1300 PHY
> > +
> > +maintainers:
> > + - Alexandru Ardelean <alexandru.ardelean@analog.com>
> > +
> > +description: |
> > + Bindings for Analog Devices Industrial Ethernet PHYsphy
> > +
> > +properties:
> > + compatible:
> > + description: |
> > + Compatible list, may contain "ethernet-phy-ieee802.3-c45" in which case
> > + Clause 45 will be used to access device management registers. If
> > + unspecified, Clause 22 will be used. Use this only when MDIO supports
> > + Clause 45 access, but there is no other way to determine this.
> > + enum:
> > + - ethernet-phy-ieee802.3-c45
>
> It is valid to list ethernet-phy-ieee802.3-c22, it is just not
> required. So maybe you should list it here to keep the DT validater happy?
ack
>
> Andrew
^ permalink raw reply
* Re: [PATCH 14/16] net: phy: adin: make sure down-speed auto-neg is enabled
From: Ardelean, Alexandru @ 2019-08-06 6:53 UTC (permalink / raw)
To: devicetree@vger.kernel.org, hkallweit1@gmail.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: f.fainelli@gmail.com, davem@davemloft.net, mark.rutland@arm.com,
robh+dt@kernel.org, andrew@lunn.ch
In-Reply-To: <baac3842-bd9c-75af-83e3-9e89def1c429@gmail.com>
On Tue, 2019-08-06 at 07:52 +0200, Heiner Kallweit wrote:
> [External]
>
> On 05.08.2019 18:54, Alexandru Ardelean wrote:
> > Down-speed auto-negotiation may not always be enabled, in which case the
> > PHY won't down-shift to 100 or 10 during auto-negotiation.
> >
> > Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
> > ---
> > drivers/net/phy/adin.c | 27 +++++++++++++++++++++++++++
> > 1 file changed, 27 insertions(+)
> >
> > diff --git a/drivers/net/phy/adin.c b/drivers/net/phy/adin.c
> > index 86848444bd98..a1f3456a8504 100644
> > --- a/drivers/net/phy/adin.c
> > +++ b/drivers/net/phy/adin.c
> > @@ -32,6 +32,13 @@
> > #define ADIN1300_NRG_PD_TX_EN BIT(2)
> > #define ADIN1300_NRG_PD_STATUS BIT(1)
> >
> > +#define ADIN1300_PHY_CTRL2 0x0016
> > +#define ADIN1300_DOWNSPEED_AN_100_EN BIT(11)
> > +#define ADIN1300_DOWNSPEED_AN_10_EN BIT(10)
> > +#define ADIN1300_GROUP_MDIO_EN BIT(6)
> > +#define ADIN1300_DOWNSPEEDS_EN \
> > + (ADIN1300_DOWNSPEED_AN_100_EN | ADIN1300_DOWNSPEED_AN_10_EN)
> > +
> > #define ADIN1300_INT_MASK_REG 0x0018
> > #define ADIN1300_INT_MDIO_SYNC_EN BIT(9)
> > #define ADIN1300_INT_ANEG_STAT_CHNG_EN BIT(8)
> > @@ -425,6 +432,22 @@ static int adin_config_mdix(struct phy_device *phydev)
> > return phy_write(phydev, ADIN1300_PHY_CTRL1, reg);
> > }
> >
> > +static int adin_config_downspeeds(struct phy_device *phydev)
> > +{
> > + int reg;
> > +
> > + reg = phy_read(phydev, ADIN1300_PHY_CTRL2);
> > + if (reg < 0)
> > + return reg;
> > +
> > + if ((reg & ADIN1300_DOWNSPEEDS_EN) == ADIN1300_DOWNSPEEDS_EN)
> > + return 0;
> > +
> > + reg |= ADIN1300_DOWNSPEEDS_EN;
> > +
> > + return phy_write(phydev, ADIN1300_PHY_CTRL2, reg);
>
> Using phy_set_bits() would be easier.
ack;
missed this;
thanks
>
> > +}
> > +
> > static int adin_config_aneg(struct phy_device *phydev)
> > {
> > int ret;
> > @@ -433,6 +456,10 @@ static int adin_config_aneg(struct phy_device *phydev)
> > if (ret)
> > return ret;
> >
> > + ret = adin_config_downspeeds(phydev);
> > + if (ret < 0)
> > + return ret;
> > +
> > return genphy_config_aneg(phydev);
> > }
> >
> >
^ permalink raw reply
* Re: [PATCH 14/16] net: phy: adin: make sure down-speed auto-neg is enabled
From: Ardelean, Alexandru @ 2019-08-06 6:53 UTC (permalink / raw)
To: andrew@lunn.ch
Cc: davem@davemloft.net, hkallweit1@gmail.com,
devicetree@vger.kernel.org, mark.rutland@arm.com,
linux-kernel@vger.kernel.org, f.fainelli@gmail.com,
netdev@vger.kernel.org, robh+dt@kernel.org
In-Reply-To: <20190805152214.GS24275@lunn.ch>
On Mon, 2019-08-05 at 17:22 +0200, Andrew Lunn wrote:
> [External]
>
> On Mon, Aug 05, 2019 at 07:54:51PM +0300, Alexandru Ardelean wrote:
> > Down-speed auto-negotiation may not always be enabled, in which case the
> > PHY won't down-shift to 100 or 10 during auto-negotiation.
>
> Please look at how the marvell driver enables and configures this
> feature. Ideally we want all PHY drivers to use the same configuration
> API for features like this.
ack
>
> Andrew
^ permalink raw reply
* Re: [PATCH 12/16] net: phy: adin: read EEE setting from device-tree
From: Ardelean, Alexandru @ 2019-08-06 6:52 UTC (permalink / raw)
To: andrew@lunn.ch
Cc: davem@davemloft.net, hkallweit1@gmail.com,
devicetree@vger.kernel.org, mark.rutland@arm.com,
linux-kernel@vger.kernel.org, f.fainelli@gmail.com,
netdev@vger.kernel.org, robh+dt@kernel.org
In-Reply-To: <20190805151909.GR24275@lunn.ch>
On Mon, 2019-08-05 at 17:19 +0200, Andrew Lunn wrote:
> [External]
>
> On Mon, Aug 05, 2019 at 07:54:49PM +0300, Alexandru Ardelean wrote:
> > By default, EEE is not advertised on system init. This change allows the
> > user to specify a device property to enable EEE advertisements when the PHY
> > initializes.
>
> This patch is not required. If EEE is not being advertised when it
> should, it means there is a MAC driver bug.
ack;
same thing about PHY specifics ignoring MAC specifics
thanks
>
> Andrew
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox