* RE: [PATCH v4 2/5] dt-bindings: serial: renesas,scif: Validate 'interrupts' and 'interrupt-names'
From: Biju Das @ 2024-03-25 16:21 UTC (permalink / raw)
To: Prabhakar, Geert Uytterhoeven, Greg Kroah-Hartman, Jiri Slaby,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Magnus Damm
Cc: linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-serial@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
Fabrizio Castro, Prabhakar Mahadev Lad
In-Reply-To: <20240322144355.878930-3-prabhakar.mahadev-lad.rj@bp.renesas.com>
Hi Prabhakar,
> -----Original Message-----
> From: Prabhakar <prabhakar.csengg@gmail.com>
> Sent: Friday, March 22, 2024 2:44 PM
> Subject: [PATCH v4 2/5] dt-bindings: serial: renesas,scif: Validate 'interrupts' and 'interrupt-
> names'
>
> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> This commit adds support to validate the 'interrupts' and 'interrupt-names'
> properties for every supported SoC. This ensures proper handling and configuration of interrupt-
> related properties across supported platforms.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> v3->v4
> - Reverted back to v2 version of the patch.
> - Used suggestion from Krzysztof for interrupts
> - Restored RB tag from Geert
>
> v2->v3
> - Listed interrupts and interrupt-names for every SoC in if check
> ---
> .../bindings/serial/renesas,scif.yaml | 73 ++++++++++++++-----
> 1 file changed, 55 insertions(+), 18 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/serial/renesas,scif.yaml
> b/Documentation/devicetree/bindings/serial/renesas,scif.yaml
> index af72c3420453..eb2aa5e75e02 100644
> --- a/Documentation/devicetree/bindings/serial/renesas,scif.yaml
> +++ b/Documentation/devicetree/bindings/serial/renesas,scif.yaml
> @@ -86,11 +86,6 @@ properties:
> oneOf:
> - items:
> - description: A combined interrupt
> - - items:
> - - description: Error interrupt
> - - description: Receive buffer full interrupt
> - - description: Transmit buffer empty interrupt
> - - description: Break interrupt
> - items:
> - description: Error interrupt
> - description: Receive buffer full interrupt @@ -98,21 +93,17 @@ properties:
> - description: Break interrupt
> - description: Data Ready interrupt
> - description: Transmit End interrupt
> + minItems: 4
I think here minItems is 1 as it is either 1 or 4 or 6
Cheers,
Biju
>
> interrupt-names:
> - oneOf:
> - - items:
> - - const: eri
> - - const: rxi
> - - const: txi
> - - const: bri
> - - items:
> - - const: eri
> - - const: rxi
> - - const: txi
> - - const: bri
> - - const: dri
> - - const: tei
> + minItems: 4
> + items:
> + - const: eri
> + - const: rxi
> + - const: txi
> + - const: bri
> + - const: dri
> + - const: tei
>
> clocks:
> minItems: 1
> @@ -173,6 +164,52 @@ allOf:
> required:
> - resets
>
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - renesas,rcar-gen1-scif
> + - renesas,rcar-gen2-scif
> + - renesas,rcar-gen3-scif
> + - renesas,rcar-gen4-scif
> + then:
> + properties:
> + interrupts:
> + maxItems: 1
> +
> + interrupt-names: false
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - renesas,scif-r7s72100
> + then:
> + properties:
> + interrupts:
> + minItems: 4
> + maxItems: 4
> +
> + interrupt-names:
> + maxItems: 4
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - renesas,scif-r7s9210
> + - renesas,scif-r9a07g044
> + then:
> + properties:
> + interrupts:
> + minItems: 6
> +
> + interrupt-names:
> + minItems: 6
> +
> unevaluatedProperties: false
>
> examples:
> --
> 2.34.1
>
^ permalink raw reply
* [PATCH] arm64: dts: rockchip: quartzpro64: Enable the GPU
From: Dragan Simic @ 2024-03-25 16:19 UTC (permalink / raw)
To: linux-rockchip
Cc: heiko, linux-arm-kernel, devicetree, robh+dt,
krzysztof.kozlowski+dt, conor+dt, boris.brezillon, linux-kernel,
kernel, sebastian.reichel
Following the approach used to enable the Mali GPU on the rk3588-evb1, [1]
do the same for the Pine64 QuartzPro64, which uses nearly identical hardware
design as the RK3588 EVB1.
The slight disadvantage is that the regulator coupling logic requires the
regulators to be always on, which is also noted in the comments. This is
obviously something to be improved at some point in the future, but should
be fine for now, especially because the QuartzPro64 isn't a battery-powered
board, so low power consumption isn't paramount.
[1] https://lore.kernel.org/linux-rockchip/20240325153850.189128-5-sebastian.reichel@collabora.com/
Signed-off-by: Dragan Simic <dsimic@manjaro.org>
---
.../arm64/boot/dts/rockchip/rk3588-quartzpro64.dts | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-quartzpro64.dts b/arch/arm64/boot/dts/rockchip/rk3588-quartzpro64.dts
index 67414d72e2b6..68d432c61ea5 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-quartzpro64.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588-quartzpro64.dts
@@ -285,6 +285,12 @@ &gmac0_rgmii_clk
status = "okay";
};
+&gpu {
+ mali-supply = <&vdd_gpu_s0>;
+ sram-supply = <&vdd_gpu_mem_s0>;
+ status = "okay";
+};
+
&i2c2 {
status = "okay";
@@ -491,11 +497,15 @@ rk806_dvs3_null: dvs3-null-pins {
regulators {
vdd_gpu_s0: dcdc-reg1 {
regulator-name = "vdd_gpu_s0";
+ /* regulator coupling requires always-on */
+ regulator-always-on;
regulator-boot-on;
regulator-enable-ramp-delay = <400>;
regulator-min-microvolt = <550000>;
regulator-max-microvolt = <950000>;
regulator-ramp-delay = <12500>;
+ regulator-coupled-with = <&vdd_gpu_mem_s0>;
+ regulator-coupled-max-spread = <10000>;
regulator-state-mem {
regulator-off-in-suspend;
@@ -545,11 +555,15 @@ regulator-state-mem {
vdd_gpu_mem_s0: dcdc-reg5 {
regulator-name = "vdd_gpu_mem_s0";
+ /* regulator coupling requires always-on */
+ regulator-always-on;
regulator-boot-on;
regulator-enable-ramp-delay = <400>;
regulator-min-microvolt = <675000>;
regulator-max-microvolt = <950000>;
regulator-ramp-delay = <12500>;
+ regulator-coupled-with = <&vdd_gpu_s0>;
+ regulator-coupled-max-spread = <10000>;
regulator-state-mem {
regulator-off-in-suspend;
^ permalink raw reply related
* Re: [PATCH] docs: dt-bindings: add missing address/size-cells to example
From: Rob Herring @ 2024-03-25 16:07 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-kernel, Krzysztof Kozlowski, Tudor Ambarus, Conor Dooley,
devicetree
In-Reply-To: <20240325091139.18602-1-krzysztof.kozlowski@linaro.org>
On Mon, 25 Mar 2024 10:11:39 +0100, Krzysztof Kozlowski wrote:
> Complete the example of recommended order of properties by adding
> missing address/size-cells. They are not necessary to illustrate the
> style, but lack of them us bit really correct DTS code which might
> confuse readers.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>
> ---
>
> Cc: Tudor Ambarus <tudor.ambarus@linaro.org>
> ---
> Documentation/devicetree/bindings/dts-coding-style.rst | 2 ++
> 1 file changed, 2 insertions(+)
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH v1 4/4] arm64: dts: rockchip: rk3588-evb1: Enable GPU
From: Sebastian Reichel @ 2024-03-25 16:06 UTC (permalink / raw)
To: Boris Brezillon
Cc: Heiko Stuebner, linux-rockchip, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, devicetree, linux-kernel, kernel
In-Reply-To: <20240325165308.483b01b3@collabora.com>
[-- Attachment #1: Type: text/plain, Size: 865 bytes --]
Hi,
On Mon, Mar 25, 2024 at 04:53:08PM +0100, Boris Brezillon wrote:
> [...]
> > @@ -484,12 +490,15 @@ rk806_dvs3_null: dvs3-null-pins {
> >
> > regulators {
> > vdd_gpu_s0: dcdc-reg1 {
> > + regulator-always-on;
>
> IIRC, this is only needed because of some bug in the power-domain
> driver (or elsewhere). Is there any other reason to flag those as
> always-on? I mean, it's working but probably not ideal from a PM
> standpoint, as that means the regulators will stay on even when the GPU
> is idle.
EVB1 needs it for the generic coupler infrastructure. The Linux
coupler code cannot handle non always-on regulators at the moment.
That's something, which could be improved, but I think for now we
can just make the regulator always-on for the EVB1. The EVB1 is not
running from a battery anyways.
Greetings
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: rtc: armada-380-rtc: convert to dtschema
From: Rob Herring @ 2024-03-25 16:02 UTC (permalink / raw)
To: Javier Carrasco
Cc: Alexandre Belloni, Krzysztof Kozlowski, Conor Dooley,
Baruch Siach, linux-rtc, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <6e68e0ca-2f3e-41a7-bb96-00fbdadc4436@gmail.com>
On Sun, Mar 24, 2024 at 01:02:31AM +0100, Javier Carrasco wrote:
> On 3/24/24 00:37, Alexandre Belloni wrote:
> > On 23/03/2024 23:46:13+0100, Javier Carrasco wrote:
> >> Convert existing binding to dtschema to support validation.
> >>
> >> +required:
> >> + - compatible
> >> + - reg
> >> + - reg-names
> >> + - interrupts
> >> +
> >> +additionalProperties: false
> >
> > This is not correct because at least start-year is supported. Please
> > check for all your other submissions too.
> >
>
> allOf:
> - $ref: rtc.yaml#
>
> is missing, and then
>
> unvealuatedProperties: false
>
> to account for that.
>
> "start-year" is read in the RTC base class, so I wonder why so many RTC
> bindings add a reference to rtc.yaml, but then use
>
> additionalProperties: false
They may have pre-dated support for 'unevaluatedProperties', or you can
list out which properties are used from a referenced schema which
disallows unlisted properties. There's no hard rule here. Either way is
fine.
Other than this and my 1 other comment, this series looks fine to me.
Rob
^ permalink raw reply
* Re: [PATCH 3/4] dt-bindings: rtc: digicolor-rtc: convert to dtschema
From: Rob Herring @ 2024-03-25 16:01 UTC (permalink / raw)
To: Javier Carrasco
Cc: Alexandre Belloni, Krzysztof Kozlowski, Conor Dooley,
Baruch Siach, linux-rtc, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <20240323-rtc-yaml-v1-3-0c5d12b1b89d@gmail.com>
On Sat, Mar 23, 2024 at 11:46:15PM +0100, Javier Carrasco wrote:
> Convert existing binding to dtschema to support validation.
>
> The binding has been renamed to match its compatible. Apart from that,
> it is a direct conversion with no additions.
>
> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
> ---
> .../devicetree/bindings/rtc/cnxt,cx92755-rtc.yaml | 37 ++++++++++++++++++++++
> .../devicetree/bindings/rtc/digicolor-rtc.txt | 17 ----------
> 2 files changed, 37 insertions(+), 17 deletions(-)
This could probably just go into trivial-rtc.yaml.
Rob
^ permalink raw reply
* Re: [PATCH v1 3/4] arm64: dts: rockchip: rk3588-rock5b: Enable GPU
From: Sebastian Reichel @ 2024-03-25 15:58 UTC (permalink / raw)
To: Boris Brezillon
Cc: Heiko Stuebner, linux-rockchip, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, devicetree, linux-kernel, kernel
In-Reply-To: <20240325164441.1dab4018@collabora.com>
[-- Attachment #1: Type: text/plain, Size: 1748 bytes --]
Hi,
On Mon, Mar 25, 2024 at 04:44:41PM +0100, Boris Brezillon wrote:
> On Mon, 25 Mar 2024 16:37:20 +0100
> Sebastian Reichel <sebastian.reichel@collabora.com> wrote:
>
> > From: Boris Brezillon <boris.brezillon@collabora.com>
> >
> > Enable the Mali GPU in the Rock 5B.
> >
> > Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
>
> I don't remember writing this patch ;-), maybe I screwed authorship at
> some point, dunno.
mh, I cherry-picked the DT patches from your branch before
cleaning them up.
> > Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
> > ---
> > arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts
> > index 1fe8b2a0ed75..096ee7a98b89 100644
> > --- a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts
> > +++ b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts
> > @@ -180,6 +180,11 @@ &cpu_l3 {
> > cpu-supply = <&vdd_cpu_lit_s0>;
> > };
> >
> > +&gpu {
> > + mali-supply = <&vdd_gpu_s0>;
> > + status = "okay";
> > +};
> > +
> > &i2c0 {
> > pinctrl-names = "default";
> > pinctrl-0 = <&i2c0m2_xfer>;
> > @@ -470,6 +475,7 @@ rk806_dvs3_null: dvs3-null-pins {
> >
> > regulators {
> > vdd_gpu_s0: vdd_gpu_mem_s0: dcdc-reg1 {
> > + regulator-always-on;
>
> Hm, should we mention why the regulator is always on here?
In case of the EVB1 it's needed because the generic coupler driver
cannot handle regulators that are not always on. I'm not sure why
it was added for the Rock 5B. I will check if it works without that
flag.
Greetings,
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v3 4/5] dt-bindings: dma: fsl-edma: add fsl,imx8ulp-edma compatible string
From: Rob Herring @ 2024-03-25 15:55 UTC (permalink / raw)
To: Frank Li
Cc: Vinod Koul, linux-kernel, Conor Dooley, devicetree, imx,
dmaengine, Joy Zou, Peng Fan, Krzysztof Kozlowski
In-Reply-To: <20240323-8ulp_edma-v3-4-c0e981027c05@nxp.com>
On Sat, 23 Mar 2024 11:34:53 -0400, Frank Li wrote:
> From: Joy Zou <joy.zou@nxp.com>
>
> Introduce the compatible string 'fsl,imx8ulp-edma' to enable support for
> the i.MX8ULP's eDMA, alongside adjusting the clock numbering. The i.MX8ULP
> eDMA architecture features one clock for each DMA channel and an additional
> clock for the core controller. Given a maximum of 32 DMA channels, the
> maximum clock number consequently increases to 33.
>
> Signed-off-by: Joy Zou <joy.zou@nxp.com>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
> ---
>
> Notes:
> Changes in v3:
> - Change clock name form CHXX-CLK to chxx
> - Fix typeo 'clock'
> - Add dma-cell description
> - About clock-names:
> items:
> oneOf:
> - const: dma
> - pattern: ...
>
> Which already detect naming wrong, for example:
>
> clock-names = "dma", "ch00", "ch01", "ch02", "ch03",
> ....
> "ch28", "ch29", "ch30", "abcc";
>
> arch/arm64/boot/dts/freescale/imx8ulp-evk.dtb: dma-controller@29010000: clock-names:32: 'oneOf' conditional failed, one must be fixed:
> 'dma' was expected
> 'abcc' does not match '^ch(0[0-9]|[1-2][0-9]|3[01])$'
>
> Only lose order check, such as ch00, dma, ch03, ch02, can pass check.
> I think it is good enough.
>
> I tried rob's suggestion, but met some technology issue. Detail see
>
> https://lore.kernel.org/imx/20240229-8ulp_edma-v2-0-9d12f883c8f7@nxp.com/T/#mc5767dd505d4b7cfc66586a0631684a57e735476
>
> .../devicetree/bindings/dma/fsl,edma.yaml | 40 ++++++++++++++++++++--
> 1 file changed, 38 insertions(+), 2 deletions(-)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v1 4/4] arm64: dts: rockchip: rk3588-evb1: Enable GPU
From: Boris Brezillon @ 2024-03-25 15:53 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Heiko Stuebner, linux-rockchip, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, devicetree, linux-kernel, kernel
In-Reply-To: <20240325153850.189128-5-sebastian.reichel@collabora.com>
On Mon, 25 Mar 2024 16:37:21 +0100
Sebastian Reichel <sebastian.reichel@collabora.com> wrote:
> From: Boris Brezillon <boris.brezillon@collabora.com>
>
> Enable the Mali GPU in the RK3588 EVB1.
>
> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
> ---
> arch/arm64/boot/dts/rockchip/rk3588-evb1-v10.dts | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3588-evb1-v10.dts b/arch/arm64/boot/dts/rockchip/rk3588-evb1-v10.dts
> index de30c2632b8e..b51a17b404f3 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3588-evb1-v10.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3588-evb1-v10.dts
> @@ -281,6 +281,12 @@ &gmac0_rgmii_clk
> status = "okay";
> };
>
> +&gpu {
> + mali-supply = <&vdd_gpu_s0>;
> + sram-supply = <&vdd_gpu_mem_s0>;
> + status = "okay";
> +};
> +
> &i2c2 {
> status = "okay";
>
> @@ -484,12 +490,15 @@ rk806_dvs3_null: dvs3-null-pins {
>
> regulators {
> vdd_gpu_s0: dcdc-reg1 {
> + regulator-always-on;
IIRC, this is only needed because of some bug in the power-domain
driver (or elsewhere). Is there any other reason to flag those as
always-on? I mean, it's working but probably not ideal from a PM
standpoint, as that means the regulators will stay on even when the GPU
is idle.
> regulator-boot-on;
> regulator-min-microvolt = <550000>;
> regulator-max-microvolt = <950000>;
> regulator-ramp-delay = <12500>;
> regulator-name = "vdd_gpu_s0";
> regulator-enable-ramp-delay = <400>;
> + regulator-coupled-with = <&vdd_gpu_mem_s0>;
> + regulator-coupled-max-spread = <10000>;
> regulator-state-mem {
> regulator-off-in-suspend;
> };
> @@ -534,12 +543,15 @@ regulator-state-mem {
> };
>
> vdd_gpu_mem_s0: dcdc-reg5 {
> + regulator-always-on;
> regulator-boot-on;
> regulator-min-microvolt = <675000>;
> regulator-max-microvolt = <950000>;
> regulator-ramp-delay = <12500>;
> regulator-enable-ramp-delay = <400>;
> regulator-name = "vdd_gpu_mem_s0";
> + regulator-coupled-with = <&vdd_gpu_s0>;
> + regulator-coupled-max-spread = <10000>;
> regulator-state-mem {
> regulator-off-in-suspend;
> };
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: imx8mp: Add DT nodes for the two ISPs
From: Alexander Stein @ 2024-03-25 15:52 UTC (permalink / raw)
To: imx, linux-arm-kernel, Laurent Pinchart
Cc: Paul Elder, Adam Ford, Conor Dooley, Fabio Estevam,
Krzysztof Kozlowski, Marek Vasut, Pengutronix Kernel Team,
Rob Herring, Sascha Hauer, Shawn Guo, devicetree, linux-media
In-Reply-To: <20240325151339.19041-1-laurent.pinchart@ideasonboard.com>
Hi Laurent,
Am Montag, 25. März 2024, 16:13:39 CET schrieb Laurent Pinchart:
> From: Paul Elder <paul.elder@ideasonboard.com>
>
> The ISP supports both CSI and parallel interfaces, where port 0
> corresponds to the former and port 1 corresponds to the latter. Since
> the i.MX8MP's ISPs are connected by the parallel interface to the CSI
> receiver, set them both to port 1.
>
> Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> Changes since v1:
>
> - Fix clock ordering
> - Add #address-cells and #size-cells to ports nodes
> ---
> arch/arm64/boot/dts/freescale/imx8mp.dtsi | 50 +++++++++++++++++++++++
> 1 file changed, 50 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> index bfc5c81a5bd4..1d2670b91b53 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> @@ -1616,6 +1616,56 @@ isi_in_1: endpoint {
> };
> };
>
> + isp_0: isp@32e10000 {
> + compatible = "fsl,imx8mp-isp";
> + reg = <0x32e10000 0x10000>;
> + interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clk IMX8MP_CLK_MEDIA_ISP_ROOT>,
> + <&clk IMX8MP_CLK_MEDIA_AXI_ROOT>,
> + <&clk IMX8MP_CLK_MEDIA_APB_ROOT>;
> + clock-names = "isp", "aclk", "hclk";
> + assigned-clocks = <&clk IMX8MP_CLK_MEDIA_ISP>;
> + assigned-clock-parents = <&clk IMX8MP_SYS_PLL2_500M>;
> + assigned-clock-rates = <500000000>;
> + power-domains = <&media_blk_ctrl IMX8MP_MEDIABLK_PD_ISP>;
> + fsl,blk-ctrl = <&media_blk_ctrl 0>;
> + status = "disabled";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@1 {
> + reg = <1>;
> + };
> + };
> + };
> +
> + isp_1: isp@32e20000 {
> + compatible = "fsl,imx8mp-isp";
> + reg = <0x32e20000 0x10000>;
> + interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clk IMX8MP_CLK_MEDIA_ISP_ROOT>,
> + <&clk IMX8MP_CLK_MEDIA_AXI_ROOT>,
> + <&clk IMX8MP_CLK_MEDIA_APB_ROOT>;
> + clock-names = "isp", "aclk", "hclk";
> + assigned-clocks = <&clk IMX8MP_CLK_MEDIA_ISP>;
> + assigned-clock-parents = <&clk IMX8MP_SYS_PLL2_500M>;
> + assigned-clock-rates = <500000000>;
> + power-domains = <&media_blk_ctrl IMX8MP_MEDIABLK_PD_ISP>;
> + fsl,blk-ctrl = <&media_blk_ctrl 1>;
> + status = "disabled";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@1 {
> + reg = <1>;
> + };
> + };
> + };
> +
The patch itself is okay. But you might not be able to
configure the parent of IMX8MP_CLK_MEDIA_ISP if dewarp is enabled before.
This is due to IMX8MP_CLK_MEDIA_ISP_ROOT being enabled in 'pgc_ispdwp'
power domain. Reparenting is not possible anymore in this case.
Something like
---8<---
--- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
@@ -1837,11 +1837,13 @@ media_blk_ctrl: blk-ctrl@32ec0000 {
<&clk IMX8MP_CLK_MEDIA_APB>,
<&clk IMX8MP_CLK_MEDIA_DISP1_PIX>,
<&clk IMX8MP_CLK_MEDIA_DISP2_PIX>,
+ <&clk IMX8MP_CLK_MEDIA_ISP>,
<&clk IMX8MP_VIDEO_PLL1>;
assigned-clock-parents = <&clk IMX8MP_SYS_PLL2_1000M>,
<&clk IMX8MP_SYS_PLL1_800M>,
<&clk IMX8MP_VIDEO_PLL1_OUT>,
- <&clk IMX8MP_VIDEO_PLL1_OUT>;
+ <&clk IMX8MP_VIDEO_PLL1_OUT>,
+ <&clk IMX8MP_SYS_PLL2_500M>;
assigned-clock-rates = <500000000>, <200000000>,
<0>, <0>, <1039500000>;
#power-domain-cells = <1>;
---8<---
is needed.
Best regards,
Alexander
> dewarp: dwe@32e30000 {
> compatible = "nxp,imx8mp-dw100";
> reg = <0x32e30000 0x10000>;
>
> base-commit: 4cece764965020c22cff7665b18a012006359095
>
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/
^ permalink raw reply
* Re: [PATCH v2 1/1] ASoC: dt-bindings: fsl-esai: Convert fsl,esai.txt to yaml
From: Rob Herring @ 2024-03-25 15:52 UTC (permalink / raw)
To: Frank Li
Cc: linux-kernel, Mark Brown, linux-sound, Krzysztof Kozlowski,
Shengjiu Wang, devicetree, Liam Girdwood, imx, Conor Dooley
In-Reply-To: <20240322145406.2613256-1-Frank.Li@nxp.com>
On Fri, 22 Mar 2024 10:54:05 -0400, Frank Li wrote:
> Convert fsl,esai.txt to yaml. So DTB_CHECK tools can verify dts file about
> esai part.
>
> clock-names 'spba' is optional according to description. So minItems of
> clocks and clock-names is 3.
>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
> ---
>
> Notes:
> Change from v1 to v2
> - alphabetical order compatible string according to rob's suggestion
> - clock description move under 'clock' according to kryszof's suggestion
> - fix descritpion indent according to rob's suggestion
>
> Pass dt_binding check
> make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j8 dt_binding_check DT_SCHEMA_FILES=fsl,esai.yaml
> DTEX Documentation/devicetree/bindings/sound/fsl,esai.example.dts
> LINT Documentation/devicetree/bindings
> CHKDT Documentation/devicetree/bindings/processed-schema.json
> SCHEMA Documentation/devicetree/bindings/processed-schema.json
> DTC_CHK Documentation/devicetree/bindings/sound/fsl,esai.example.dtb
>
> .../devicetree/bindings/sound/fsl,esai.txt | 68 ----------
> .../devicetree/bindings/sound/fsl,esai.yaml | 116 ++++++++++++++++++
> 2 files changed, 116 insertions(+), 68 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/sound/fsl,esai.txt
> create mode 100644 Documentation/devicetree/bindings/sound/fsl,esai.yaml
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v2 3/3] cpufreq: qcom-nvmem: add support for IPQ5321
From: Kathiravan Thirumoorthy @ 2024-03-25 15:49 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Ilia Lin, Rafael J. Wysocki, Viresh Kumar
Cc: linux-arm-msm, devicetree, linux-kernel, linux-pm,
Kathiravan Thirumoorthy, Mukesh Ojha
In-Reply-To: <20240325-ipq5321-sku-support-v2-0-f30ce244732f@quicinc.com>
Like all other SoCs in IPQ5332 family, cpufreq for IPQ5321 is also
determined by the eFuse, with the maximum limit of 1.1GHz. Add support
for the same.
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Mukesh Ojha <quic_mojha@quicinc.com>
Signed-off-by: Kathiravan Thirumoorthy <quic_kathirav@quicinc.com>
---
drivers/cpufreq/qcom-cpufreq-nvmem.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/cpufreq/qcom-cpufreq-nvmem.c b/drivers/cpufreq/qcom-cpufreq-nvmem.c
index ea05d9d67490..0a46b5d49d32 100644
--- a/drivers/cpufreq/qcom-cpufreq-nvmem.c
+++ b/drivers/cpufreq/qcom-cpufreq-nvmem.c
@@ -191,6 +191,7 @@ static int qcom_cpufreq_kryo_name_version(struct device *cpu_dev,
case QCOM_ID_IPQ5312:
case QCOM_ID_IPQ5302:
case QCOM_ID_IPQ5300:
+ case QCOM_ID_IPQ5321:
case QCOM_ID_IPQ9514:
case QCOM_ID_IPQ9550:
case QCOM_ID_IPQ9554:
--
2.34.1
^ permalink raw reply related
* [PATCH v2 2/3] soc: qcom: socinfo: Add SoC ID for IPQ5321
From: Kathiravan Thirumoorthy @ 2024-03-25 15:49 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Ilia Lin, Rafael J. Wysocki, Viresh Kumar
Cc: linux-arm-msm, devicetree, linux-kernel, linux-pm,
Kathiravan Thirumoorthy, Krzysztof Kozlowski, Mukesh Ojha
In-Reply-To: <20240325-ipq5321-sku-support-v2-0-f30ce244732f@quicinc.com>
Add the SoC ID for IPQ5321, which belong to the family of IPQ5332 SoC.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Mukesh Ojha <quic_mojha@quicinc.com>
Signed-off-by: Kathiravan Thirumoorthy <quic_kathirav@quicinc.com>
---
drivers/soc/qcom/socinfo.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/soc/qcom/socinfo.c b/drivers/soc/qcom/socinfo.c
index 277c07a6603d..287139f0cb1c 100644
--- a/drivers/soc/qcom/socinfo.c
+++ b/drivers/soc/qcom/socinfo.c
@@ -445,6 +445,7 @@ static const struct soc_id soc_id[] = {
{ qcom_board_id(QCS8550) },
{ qcom_board_id(QCM8550) },
{ qcom_board_id(IPQ5300) },
+ { qcom_board_id(IPQ5321) },
};
static const char *socinfo_machine(struct device *dev, unsigned int id)
--
2.34.1
^ permalink raw reply related
* [PATCH v2 1/3] dt-bindings: arm: qcom,ids: Add SoC ID for IPQ5321
From: Kathiravan Thirumoorthy @ 2024-03-25 15:49 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Ilia Lin, Rafael J. Wysocki, Viresh Kumar
Cc: linux-arm-msm, devicetree, linux-kernel, linux-pm,
Kathiravan Thirumoorthy, Krzysztof Kozlowski, Mukesh Ojha
In-Reply-To: <20240325-ipq5321-sku-support-v2-0-f30ce244732f@quicinc.com>
Add the ID for the Qualcomm IPQ5321 SoC.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Mukesh Ojha <quic_mojha@quicinc.com>
Signed-off-by: Kathiravan Thirumoorthy <quic_kathirav@quicinc.com>
---
include/dt-bindings/arm/qcom,ids.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/dt-bindings/arm/qcom,ids.h b/include/dt-bindings/arm/qcom,ids.h
index d040033dc8ee..a2958952a9ec 100644
--- a/include/dt-bindings/arm/qcom,ids.h
+++ b/include/dt-bindings/arm/qcom,ids.h
@@ -272,6 +272,7 @@
#define QCOM_ID_QCS8550 603
#define QCOM_ID_QCM8550 604
#define QCOM_ID_IPQ5300 624
+#define QCOM_ID_IPQ5321 650
/*
* The board type and revision information, used by Qualcomm bootloaders and
--
2.34.1
^ permalink raw reply related
* [PATCH v2 0/3] Add support for the IPQ5321 SoC
From: Kathiravan Thirumoorthy @ 2024-03-25 15:49 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Ilia Lin, Rafael J. Wysocki, Viresh Kumar
Cc: linux-arm-msm, devicetree, linux-kernel, linux-pm,
Kathiravan Thirumoorthy, Krzysztof Kozlowski, Mukesh Ojha
IPQ5321 SoC belong to IPQ5332 family. Add the SoC ID and the cpufreq
support. Maximum cpufreq for IPQ5321 is 1.1GHZ, which is determined
based on the eFuse.
Viresh is okay to merge the cpufreq change via qcom tree[1] and provided
his Ack.
[1]
https://lore.kernel.org/linux-arm-msm/20240306053200.6iwrviltwt3pnfnt@vireshk-i7/
Signed-off-by: Kathiravan Thirumoorthy <quic_kathirav@quicinc.com>
---
Changes in v2:
- rebase on next-20240325
- pick up the tags
- Link to v1:
https://lore.kernel.org/linux-arm-msm/20240228-ipq5321-sku-support-v1-0-14e4d4715f4b@quicinc.com/
---
Kathiravan Thirumoorthy (3):
dt-bindings: arm: qcom,ids: Add SoC ID for IPQ5321
soc: qcom: socinfo: Add SoC ID for IPQ5321
cpufreq: qcom-nvmem: add support for IPQ5321
drivers/cpufreq/qcom-cpufreq-nvmem.c | 1 +
drivers/soc/qcom/socinfo.c | 1 +
include/dt-bindings/arm/qcom,ids.h | 1 +
3 files changed, 3 insertions(+)
---
base-commit: 1fdad13606e104ff103ca19d2d660830cb36d43e
change-id: 20240228-ipq5321-sku-support-bd07056d5e01
Best regards,
--
Kathiravan Thirumoorthy <quic_kathirav@quicinc.com>
^ permalink raw reply
* Re: [PATCH 0/8] block: implement NVMEM provider
From: Daniel Golle @ 2024-03-25 15:46 UTC (permalink / raw)
To: Rob Herring
Cc: Krzysztof Kozlowski, Conor Dooley, Ulf Hansson, Jens Axboe,
Dave Chinner, Jan Kara, Thomas Weißschuh, Damien Le Moal,
Li Lingfeng, Christian Brauner, Christian Heusel, Min Li,
Adrian Hunter, Avri Altman, Hannes Reinecke, Christian Loehle,
Bean Huo, Yeqi Fu, Victor Shih, Christophe JAILLET,
Dominique Martinet, Ricardo B. Marliere, devicetree, linux-kernel,
linux-mmc, linux-block
In-Reply-To: <20240325151259.GB3591150-robh@kernel.org>
On Mon, Mar 25, 2024 at 10:12:59AM -0500, Rob Herring wrote:
> On Thu, Mar 21, 2024 at 07:31:48PM +0000, Daniel Golle wrote:
> > On embedded devices using an eMMC it is common that one or more (hw/sw)
> > partitions on the eMMC are used to store MAC addresses and Wi-Fi
> > calibration EEPROM data.
> >
> > Implement an NVMEM provider backed by a block device as typically the
> > NVMEM framework is used to have kernel drivers read and use binary data
> > from EEPROMs, efuses, flash memory (MTD), ...
> >
> > In order to be able to reference hardware partitions on an eMMC, add code
> > to bind each hardware partition to a specific firmware subnode.
> >
> > Overall, this enables uniform handling across practially all flash
> > storage types used for this purpose (MTD, UBI, and now also MMC).
> >
> > As part of this series it was necessary to define a device tree schema
> > for block devices and partitions on them, which (similar to how it now
> > works also for UBI volumes) can be matched by one or more properties.
> >
> > ---
> > This series has previously been submitted as RFC on July 19th 2023[1]
> > and most of the basic idea did not change since. Another round of RFC
> > was submitted on March 5th 2024[2] which has received overall positive
> > feedback and only minor corrections have been done since (see
> > changelog below).
>
> Also, please version your patches. 'RFC' is a tag, not a version. v1 was
> July. v2 was March 5th. This is v3.
According to "Submitting patches: the essential guide to getting your
code into the kernel" [1] a version is also a tag.
Quote:
Common tags might include a version descriptor if the [sic] multiple
versions of the patch have been sent out in response to comments
(i.e., “v1, v2, v3”), or “RFC” to indicate a request for comments.
Maybe this should be clarified, exclusive or inclusive "or" is up to
the reader to interpret at this point, and I've often seen RFC, RFCv2,
v1, v2, ... as a sequence of tags applied for the same series, which
is why I followed what I used to believe was the most common
interpretation of the guidelines.
In any way, thank you for pointing it out, I assume the next iteration
should then be v4.
[1]: https://docs.kernel.org/process/submitting-patches.html
^ permalink raw reply
* Re: [PATCH v1 3/4] arm64: dts: rockchip: rk3588-rock5b: Enable GPU
From: Boris Brezillon @ 2024-03-25 15:44 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Heiko Stuebner, linux-rockchip, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, devicetree, linux-kernel, kernel
In-Reply-To: <20240325153850.189128-4-sebastian.reichel@collabora.com>
On Mon, 25 Mar 2024 16:37:20 +0100
Sebastian Reichel <sebastian.reichel@collabora.com> wrote:
> From: Boris Brezillon <boris.brezillon@collabora.com>
>
> Enable the Mali GPU in the Rock 5B.
>
> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
I don't remember writing this patch ;-), maybe I screwed authorship at
some point, dunno.
> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
> ---
> arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts
> index 1fe8b2a0ed75..096ee7a98b89 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts
> @@ -180,6 +180,11 @@ &cpu_l3 {
> cpu-supply = <&vdd_cpu_lit_s0>;
> };
>
> +&gpu {
> + mali-supply = <&vdd_gpu_s0>;
> + status = "okay";
> +};
> +
> &i2c0 {
> pinctrl-names = "default";
> pinctrl-0 = <&i2c0m2_xfer>;
> @@ -470,6 +475,7 @@ rk806_dvs3_null: dvs3-null-pins {
>
> regulators {
> vdd_gpu_s0: vdd_gpu_mem_s0: dcdc-reg1 {
> + regulator-always-on;
Hm, should we mention why the regulator is always on here?
> regulator-boot-on;
> regulator-min-microvolt = <550000>;
> regulator-max-microvolt = <950000>;
^ permalink raw reply
* Re: [PATCH 3/4] arm64: dts: rockchip: Correct RGxx3 SDMMC ordering
From: Heiko Stübner @ 2024-03-25 15:39 UTC (permalink / raw)
To: linux-rockchip, Chris Morgan
Cc: devicetree, conor+dt, krzysztof.kozlowski+dt, robh, Chris Morgan
In-Reply-To: <20240325143729.83852-4-macroalpha82@gmail.com>
Hmm,
Am Montag, 25. März 2024, 15:37:28 CET schrieb Chris Morgan:
> From: Chris Morgan <macromorgan@hotmail.com>
>
> Make the order of SDMMC predictable across the entire device lineup.
> This allows userspace to always know that sdmmc0 is the eMMC (when
> present), sdmmc1 is always the first sd card slot, sdmmc2 is always
> the 2nd sd card slot (when present), and sdmmc3 is always the wifi
> (when present).
>
> Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
this is really really difficult.
For example, you added the rg353p, rk503 nad rg353vs and their aliases
two years ago for 6.1 , the rg353ps for 6.5. So someone might actually
rely on those already in their userspace setup.
So reorganizing the aliases to point to different devices might actually
break userspace, which as you might know, is sort of a big deal ;-) .
Userspace programs can determine the mmc mapping via the board-compatible
though.
Heiko
> ---
> arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg-arc-d.dts | 7 -------
> arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg-arc-s.dts | 6 ------
> arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg353p.dts | 7 -------
> arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg353ps.dts | 6 ------
> arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg353v.dts | 7 -------
> arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg353vs.dts | 6 ------
> arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg503.dts | 6 ------
> arch/arm64/boot/dts/rockchip/rk3566-anbernic-rgxx3.dtsi | 7 +++++++
> 8 files changed, 7 insertions(+), 45 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg-arc-d.dts b/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg-arc-d.dts
> index ab83e8a61615..d239a8452957 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg-arc-d.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg-arc-d.dts
> @@ -10,13 +10,6 @@
> / {
> model = "Anbernic RG ARC-D";
> compatible = "anbernic,rg-arc-d", "rockchip,rk3566";
> -
> - aliases {
> - mmc0 = &sdhci;
> - mmc1 = &sdmmc0;
> - mmc2 = &sdmmc1;
> - mmc3 = &sdmmc2;
> - };
> };
>
> &i2c2 {
> diff --git a/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg-arc-s.dts b/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg-arc-s.dts
> index 6264a8c78d0b..4bb13d94a759 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg-arc-s.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg-arc-s.dts
> @@ -10,10 +10,4 @@
> / {
> model = "Anbernic RG ARC-S";
> compatible = "anbernic,rg-arc-s", "rockchip,rk3566";
> -
> - aliases {
> - mmc1 = &sdmmc0;
> - mmc2 = &sdmmc1;
> - mmc3 = &sdmmc2;
> - };
> };
> diff --git a/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg353p.dts b/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg353p.dts
> index 8aa93c646bec..94c678c44d3a 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg353p.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg353p.dts
> @@ -11,13 +11,6 @@ / {
> model = "RG353P";
> compatible = "anbernic,rg353p", "rockchip,rk3566";
>
> - aliases {
> - mmc0 = &sdhci;
> - mmc1 = &sdmmc0;
> - mmc2 = &sdmmc1;
> - mmc3 = &sdmmc2;
> - };
> -
> battery: battery {
> compatible = "simple-battery";
> charge-full-design-microamp-hours = <3472000>;
> diff --git a/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg353ps.dts b/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg353ps.dts
> index b211973e36c2..25edd81ce26b 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg353ps.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg353ps.dts
> @@ -11,12 +11,6 @@ / {
> model = "RG353PS";
> compatible = "anbernic,rg353ps", "rockchip,rk3566";
>
> - aliases {
> - mmc0 = &sdmmc0;
> - mmc1 = &sdmmc1;
> - mmc2 = &sdmmc2;
> - };
> -
> battery: battery {
> compatible = "simple-battery";
> charge-full-design-microamp-hours = <3472000>;
> diff --git a/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg353v.dts b/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg353v.dts
> index f49ce29ba597..5354c5958df2 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg353v.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg353v.dts
> @@ -11,13 +11,6 @@ / {
> model = "RG353V";
> compatible = "anbernic,rg353v", "rockchip,rk3566";
>
> - aliases {
> - mmc0 = &sdhci;
> - mmc1 = &sdmmc0;
> - mmc2 = &sdmmc1;
> - mmc3 = &sdmmc2;
> - };
> -
> battery: battery {
> compatible = "simple-battery";
> charge-full-design-microamp-hours = <3151000>;
> diff --git a/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg353vs.dts b/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg353vs.dts
> index a7dc462fe21f..02653b59f6c2 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg353vs.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg353vs.dts
> @@ -11,12 +11,6 @@ / {
> model = "RG353VS";
> compatible = "anbernic,rg353vs", "rockchip,rk3566";
>
> - aliases {
> - mmc0 = &sdmmc0;
> - mmc1 = &sdmmc1;
> - mmc2 = &sdmmc2;
> - };
> -
> battery: battery {
> compatible = "simple-battery";
> charge-full-design-microamp-hours = <3151000>;
> diff --git a/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg503.dts b/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg503.dts
> index 94e6dd61a2db..e7161a86a9f1 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg503.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg503.dts
> @@ -11,12 +11,6 @@ / {
> model = "RG503";
> compatible = "anbernic,rg503", "rockchip,rk3566";
>
> - aliases {
> - mmc0 = &sdmmc0;
> - mmc1 = &sdmmc1;
> - mmc2 = &sdmmc2;
> - };
> -
> adc-joystick {
> compatible = "adc-joystick";
> io-channels = <&adc_mux 0>,
> diff --git a/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rgxx3.dtsi b/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rgxx3.dtsi
> index 233eade30f21..47c8fdc7c843 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rgxx3.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rgxx3.dtsi
> @@ -12,6 +12,13 @@
> / {
> chassis-type = "handset";
>
> + aliases {
> + mmc0 = &sdhci;
> + mmc1 = &sdmmc0;
> + mmc2 = &sdmmc1;
> + mmc3 = &sdmmc2;
> + };
> +
> chosen: chosen {
> stdout-path = "serial2:1500000n8";
> };
>
^ permalink raw reply
* Re: [PATCH 0/8] block: implement NVMEM provider
From: Daniel Golle @ 2024-03-25 15:38 UTC (permalink / raw)
To: Rob Herring
Cc: Krzysztof Kozlowski, Conor Dooley, Ulf Hansson, Jens Axboe,
Dave Chinner, Jan Kara, Thomas Weißschuh, Damien Le Moal,
Li Lingfeng, Christian Brauner, Christian Heusel, Min Li,
Adrian Hunter, Avri Altman, Hannes Reinecke, Christian Loehle,
Bean Huo, Yeqi Fu, Victor Shih, Christophe JAILLET,
Dominique Martinet, Ricardo B. Marliere, devicetree, linux-kernel,
linux-mmc, linux-block
In-Reply-To: <20240325151046.GA3591150-robh@kernel.org>
On Mon, Mar 25, 2024 at 10:10:46AM -0500, Rob Herring wrote:
> On Thu, Mar 21, 2024 at 07:31:48PM +0000, Daniel Golle wrote:
> > On embedded devices using an eMMC it is common that one or more (hw/sw)
> > partitions on the eMMC are used to store MAC addresses and Wi-Fi
> > calibration EEPROM data.
> >
> > Implement an NVMEM provider backed by a block device as typically the
> > NVMEM framework is used to have kernel drivers read and use binary data
> > from EEPROMs, efuses, flash memory (MTD), ...
> >
> > In order to be able to reference hardware partitions on an eMMC, add code
> > to bind each hardware partition to a specific firmware subnode.
> >
> > Overall, this enables uniform handling across practially all flash
> > storage types used for this purpose (MTD, UBI, and now also MMC).
> >
> > As part of this series it was necessary to define a device tree schema
> > for block devices and partitions on them, which (similar to how it now
> > works also for UBI volumes) can be matched by one or more properties.
> >
> > ---
> > This series has previously been submitted as RFC on July 19th 2023[1]
> > and most of the basic idea did not change since. Another round of RFC
> > was submitted on March 5th 2024[2] which has received overall positive
> > feedback and only minor corrections have been done since (see
> > changelog below).
>
> I don't recall giving positive feedback.
>
> I still think this should use offsets rather than partition specific
> information. Not wanting to have to update the offsets if they change is
> not reason enough to not use them.
Using raw offsets on the block device (rather than the partition)
won't work for most existing devices and boot firmware out there. They
always reference the partition, usually by the name of a GPT
partition (but sometimes also PARTUUID or even PARTNO) which is then
used in the exact same way as an MTD partition or UBI volume would be
on devices with NOR or NAND flash. Just on eMMC we usually use a GPT
or MBR partition table rather than defining partitions in DT or cmdline,
which is rather rare (for historic reasons, I suppose, but it is what it
is now).
Depending on the eMMC chip used, that partition may not even be at the
same offset for different batches of the same device and hence I'd
like to just do it in the same way vendor firmware does it as well.
Chad of Adtran has previously confirmed that [1], which was the
positive feedback I was refering to. Other vendors like GL-iNet or
Netgear are doing the exact same thing.
As of now, we support this in OpenWrt by adding a lot of
board-specific knowledge to userland, which is ugly and also prevents
using things like PXE-initiated nfsroot on those devices.
The purpose of this series is to be able to properly support such devices
(ie. practially all consumer-grade routers out there using an eMMC for
storing firmware).
Also, those devices have enough resources to run a general purpose
distribution like Debian instead of OpenWrt, and all the userland
hacks to set MAC addresses and extract WiFi-EEPROM-data in a
board-specific ways will most certainly never find their way into
Debian. It's just not how embedded Linux works, unless you are looking
only at the RaspberryPi which got that data stored in a textfile
which is shipped by the distribution -- something very weird and very
different from literally all of-the-shelf routers, access-points or
switches I have ever seen (and I've seen many). Maybe Felix who has
seen even more of them can tell us more about that.
[1]: https://patchwork.kernel.org/project/linux-block/patch/f70bb480aef6f55228a25ce20ff0e88e670e1b70.1709667858.git.daniel@makrotopia.org/#25756072
^ permalink raw reply
* [PATCH v1 2/4] arm64: dts: rockchip: rk3588: Add GPU nodes
From: Sebastian Reichel @ 2024-03-25 15:37 UTC (permalink / raw)
To: Heiko Stuebner, linux-rockchip
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Boris Brezillon,
devicetree, linux-kernel, kernel, Sebastian Reichel
In-Reply-To: <20240325153850.189128-1-sebastian.reichel@collabora.com>
From: Boris Brezillon <boris.brezillon@collabora.com>
Add Mali GPU Node to the RK3588 SoC DT including GPU clock
operating points
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
arch/arm64/boot/dts/rockchip/rk3588s.dtsi | 56 +++++++++++++++++++++++
1 file changed, 56 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
index 87b83c87bd55..89d40cff635f 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
@@ -501,6 +501,62 @@ usb_host2_xhci: usb@fcd00000 {
status = "disabled";
};
+ gpu: gpu@fb000000 {
+ compatible = "rockchip,rk3588-mali", "arm,mali-valhall-csf";
+ reg = <0x0 0xfb000000 0x0 0x200000>;
+ #cooling-cells = <2>;
+ assigned-clocks = <&scmi_clk SCMI_CLK_GPU>;
+ assigned-clock-rates = <200000000>;
+ clocks = <&cru CLK_GPU>, <&cru CLK_GPU_COREGROUP>,
+ <&cru CLK_GPU_STACKS>;
+ clock-names = "core", "coregroup", "stacks";
+ dynamic-power-coefficient = <2982>;
+ interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH 0>;
+ interrupt-names = "job", "mmu", "gpu";
+ operating-points-v2 = <&gpu_opp_table>;
+ power-domains = <&power RK3588_PD_GPU>;
+ status = "disabled";
+
+ gpu_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-300000000 {
+ opp-hz = /bits/ 64 <300000000>;
+ opp-microvolt = <675000 675000 850000>;
+ };
+ opp-400000000 {
+ opp-hz = /bits/ 64 <400000000>;
+ opp-microvolt = <675000 675000 850000>;
+ };
+ opp-500000000 {
+ opp-hz = /bits/ 64 <500000000>;
+ opp-microvolt = <675000 675000 850000>;
+ };
+ opp-600000000 {
+ opp-hz = /bits/ 64 <600000000>;
+ opp-microvolt = <675000 675000 850000>;
+ };
+ opp-700000000 {
+ opp-hz = /bits/ 64 <700000000>;
+ opp-microvolt = <700000 700000 850000>;
+ };
+ opp-800000000 {
+ opp-hz = /bits/ 64 <800000000>;
+ opp-microvolt = <750000 750000 850000>;
+ };
+ opp-900000000 {
+ opp-hz = /bits/ 64 <900000000>;
+ opp-microvolt = <800000 800000 850000>;
+ };
+ opp-1000000000 {
+ opp-hz = /bits/ 64 <1000000000>;
+ opp-microvolt = <850000 850000 850000>;
+ };
+ };
+ };
+
pmu1grf: syscon@fd58a000 {
compatible = "rockchip,rk3588-pmugrf", "syscon", "simple-mfd";
reg = <0x0 0xfd58a000 0x0 0x10000>;
--
2.43.0
^ permalink raw reply related
* [PATCH v1 1/4] arm64: defconfig: support Mali CSF-based GPUs
From: Sebastian Reichel @ 2024-03-25 15:37 UTC (permalink / raw)
To: Heiko Stuebner, linux-rockchip
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Boris Brezillon,
devicetree, linux-kernel, Sebastian Reichel, kernel
In-Reply-To: <20240325153850.189128-1-sebastian.reichel@collabora.com>
Enable support for Mali CSF-based GPUs, which is found on recent
ARM SoCs, such as Rockchip or Mediatek.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 2c30d617e180..65e33174f813 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -907,6 +907,7 @@ CONFIG_DRM_MESON=m
CONFIG_DRM_PL111=m
CONFIG_DRM_LIMA=m
CONFIG_DRM_PANFROST=m
+CONFIG_DRM_PANTHOR=m
CONFIG_DRM_TIDSS=m
CONFIG_DRM_POWERVR=m
CONFIG_FB=y
--
2.43.0
^ permalink raw reply related
* [PATCH v1 4/4] arm64: dts: rockchip: rk3588-evb1: Enable GPU
From: Sebastian Reichel @ 2024-03-25 15:37 UTC (permalink / raw)
To: Heiko Stuebner, linux-rockchip
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Boris Brezillon,
devicetree, linux-kernel, kernel, Sebastian Reichel
In-Reply-To: <20240325153850.189128-1-sebastian.reichel@collabora.com>
From: Boris Brezillon <boris.brezillon@collabora.com>
Enable the Mali GPU in the RK3588 EVB1.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
arch/arm64/boot/dts/rockchip/rk3588-evb1-v10.dts | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-evb1-v10.dts b/arch/arm64/boot/dts/rockchip/rk3588-evb1-v10.dts
index de30c2632b8e..b51a17b404f3 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-evb1-v10.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588-evb1-v10.dts
@@ -281,6 +281,12 @@ &gmac0_rgmii_clk
status = "okay";
};
+&gpu {
+ mali-supply = <&vdd_gpu_s0>;
+ sram-supply = <&vdd_gpu_mem_s0>;
+ status = "okay";
+};
+
&i2c2 {
status = "okay";
@@ -484,12 +490,15 @@ rk806_dvs3_null: dvs3-null-pins {
regulators {
vdd_gpu_s0: dcdc-reg1 {
+ regulator-always-on;
regulator-boot-on;
regulator-min-microvolt = <550000>;
regulator-max-microvolt = <950000>;
regulator-ramp-delay = <12500>;
regulator-name = "vdd_gpu_s0";
regulator-enable-ramp-delay = <400>;
+ regulator-coupled-with = <&vdd_gpu_mem_s0>;
+ regulator-coupled-max-spread = <10000>;
regulator-state-mem {
regulator-off-in-suspend;
};
@@ -534,12 +543,15 @@ regulator-state-mem {
};
vdd_gpu_mem_s0: dcdc-reg5 {
+ regulator-always-on;
regulator-boot-on;
regulator-min-microvolt = <675000>;
regulator-max-microvolt = <950000>;
regulator-ramp-delay = <12500>;
regulator-enable-ramp-delay = <400>;
regulator-name = "vdd_gpu_mem_s0";
+ regulator-coupled-with = <&vdd_gpu_s0>;
+ regulator-coupled-max-spread = <10000>;
regulator-state-mem {
regulator-off-in-suspend;
};
--
2.43.0
^ permalink raw reply related
* [PATCH v1 3/4] arm64: dts: rockchip: rk3588-rock5b: Enable GPU
From: Sebastian Reichel @ 2024-03-25 15:37 UTC (permalink / raw)
To: Heiko Stuebner, linux-rockchip
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Boris Brezillon,
devicetree, linux-kernel, kernel, Sebastian Reichel
In-Reply-To: <20240325153850.189128-1-sebastian.reichel@collabora.com>
From: Boris Brezillon <boris.brezillon@collabora.com>
Enable the Mali GPU in the Rock 5B.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts
index 1fe8b2a0ed75..096ee7a98b89 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts
@@ -180,6 +180,11 @@ &cpu_l3 {
cpu-supply = <&vdd_cpu_lit_s0>;
};
+&gpu {
+ mali-supply = <&vdd_gpu_s0>;
+ status = "okay";
+};
+
&i2c0 {
pinctrl-names = "default";
pinctrl-0 = <&i2c0m2_xfer>;
@@ -470,6 +475,7 @@ rk806_dvs3_null: dvs3-null-pins {
regulators {
vdd_gpu_s0: vdd_gpu_mem_s0: dcdc-reg1 {
+ regulator-always-on;
regulator-boot-on;
regulator-min-microvolt = <550000>;
regulator-max-microvolt = <950000>;
--
2.43.0
^ permalink raw reply related
* [PATCH v1 0/4] RK3588 GPU support
From: Sebastian Reichel @ 2024-03-25 15:37 UTC (permalink / raw)
To: Heiko Stuebner, linux-rockchip
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Boris Brezillon,
devicetree, linux-kernel, Sebastian Reichel, kernel
Hi,
Panthor has landed in drm-misc-next including the DT bindings, so
let's add the necessary DT changes to support the GPU on RK3588.
This adds support at SoC level and support for the EVB1 as well as
the Rock 5B, which covers both variants found in RK3588 boards:
1. Having dedicated regulators for GPU core and GPU memory. This is
handled by coupling both regulators.
2. Having a shared regulator for GPU core and GPU memory.
I prepared a branch with just the GPU DT changes (and the panthor driver
changes) based on Heiko's for-next branch:
https://gitlab.collabora.com/hardware-enablement/rockchip-3588/linux/-/commits/rk3588-gpu
Greetings,
-- Sebastian
Boris Brezillon (3):
arm64: dts: rockchip: rk3588: Add GPU nodes
arm64: dts: rockchip: rk3588-rock5b: Enable GPU
arm64: dts: rockchip: rk3588-evb1: Enable GPU
Sebastian Reichel (1):
arm64: defconfig: support Mali CSF-based GPUs
.../boot/dts/rockchip/rk3588-evb1-v10.dts | 12 ++++
.../boot/dts/rockchip/rk3588-rock-5b.dts | 6 ++
arch/arm64/boot/dts/rockchip/rk3588s.dtsi | 56 +++++++++++++++++++
arch/arm64/configs/defconfig | 1 +
4 files changed, 75 insertions(+)
--
2.43.0
^ permalink raw reply
* [net-next,v4 2/2] ravb: Add support for an optional MDIO mode
From: Niklas Söderlund @ 2024-03-25 15:34 UTC (permalink / raw)
To: Sergey Shtylyov, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Claudiu Beznea, Yoshihiro Shimoda, Biju Das,
netdev, devicetree
Cc: linux-renesas-soc, Niklas Söderlund, Andrew Lunn
In-Reply-To: <20240325153451.2366083-1-niklas.soderlund+renesas@ragnatech.se>
The driver used the DT node of the device itself when registering the
MDIO bus. While this works, it creates a problem: it forces any MDIO bus
properties to also be set on the devices DT node. This mixes the
properties of two distinctly different things and is confusing.
This change adds support for an optional mdio node to be defined as a
child to the device DT node. The child node can then be used to describe
MDIO bus properties that the MDIO core can act on when registering the
bus.
If no mdio child node is found the driver fallback to the old behavior
and register the MDIO bus using the device DT node. This change is
backward compatible with old bindings in use.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Sergey Shtylyov <s.shtylyov@omp.ru>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
---
* Changes since v3
- None
* Changes since v2
- Use DT node instead of OF ode in commit message.
- Update punctuation in commit message.
- Simplify the node selection in the driver.
---
drivers/net/ethernet/renesas/ravb_main.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c
index d1be030c8848..9a397f9b4c0c 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -2564,6 +2564,7 @@ static int ravb_mdio_init(struct ravb_private *priv)
{
struct platform_device *pdev = priv->pdev;
struct device *dev = &pdev->dev;
+ struct device_node *mdio_node;
struct phy_device *phydev;
struct device_node *pn;
int error;
@@ -2583,7 +2584,13 @@ static int ravb_mdio_init(struct ravb_private *priv)
pdev->name, pdev->id);
/* Register MDIO bus */
- error = of_mdiobus_register(priv->mii_bus, dev->of_node);
+ mdio_node = of_get_child_by_name(dev->of_node, "mdio");
+ if (!mdio_node) {
+ /* backwards compatibility for DT lacking mdio subnode */
+ mdio_node = of_node_get(dev->of_node);
+ }
+ error = of_mdiobus_register(priv->mii_bus, mdio_node);
+ of_node_put(mdio_node);
if (error)
goto out_free_bus;
--
2.44.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox