* RE: [EXT] Re: [PATCH net 3/4] ARM: dts: imx6: update fec gpr property to match new format
From: Andy Duan @ 2020-05-25 2:29 UTC (permalink / raw)
To: Fuzzey, Martin
Cc: Andrew Lunn, David S. Miller, netdev@vger.kernel.org,
robh+dt@kernel.org, shawnguo@kernel.org,
devicetree@vger.kernel.org
In-Reply-To: <CANh8QzwxfnQ1cACz=6dhYujEVtQoTCw8kTgkHi9BnxESptL=xQ@mail.gmail.com>
From: Fuzzey, Martin <martin.fuzzey@flowbird.group> Sent: Saturday, May 23, 2020 2:03 AM
> Hi Andy,
>
> On Fri, 22 May 2020, 03:01 Andy Duan, <fugang.duan@nxp.com> wrote:
> >
> > Andrew, many customers require the wol feature, NXP NPI release always
> > support the wol feature to match customers requirement.
> >
> > And some customers' board only design one ethernet instance based on
> > imx6sx/imx7d/
> > Imx8 serial, but which instance we never know, maybe enet1, maybe
> > enet2. So we should supply different values for gpr.
> >
> > So, it is very necessary to support wol feature for multiple instances.
> >
>
> Yes, I don't think anyone is saying otherwise.
>
> The problem is just that there are already .dtsi files for i.MX chips having
> multiple ethernet interfaces in the mainline kernel (at least imx6ui.dtsi,
> imx6sx.dts, imx7d.dtsi) but that this patch series does not modify those files
> to use the new DT format.
>
For imx6ul/imx6sx/imx7d/imx8mq/imx8mm/imx8mn chips to support wol,
I plan to submit another dts patch after the patch set is accepted.
If you think add the dts patch appending to the patch set, I will add it in v2.
> It currently only modifies the dts files that are already supported by
> hardcoded values in the driver.
>
> As to not knowing which instance it shouldn't matter.
> The base dtsi can declare both/all ethernet interfaces with the appropriate
> GPR bits.
> Both set to status = "disabled".
>
> Then the board specific dts file sets status="okay" and activates wol by adding
> "
> "fsl,magic-packet" if the hardaware supports it (because that depends on
> things beyond the SoC, like how the ethernet PHY is clocked and powered.)
>
> Martin
^ permalink raw reply
* Re: [PATCH v5 09/13] soc: mediatek: cmdq: add write_s value function
From: Dennis-YC Hsieh @ 2020-05-25 2:27 UTC (permalink / raw)
To: Matthias Brugger
Cc: Rob Herring, Mark Rutland, Jassi Brar, Philipp Zabel,
David Airlie, Daniel Vetter, linux-kernel, linux-mediatek,
devicetree, wsd_upstream, dri-devel, Bibby Hsieh, CK Hu,
Houlong Wei, linux-arm-kernel, HS Liao
In-Reply-To: <eb604637-28f0-fa8f-ce4b-3e87f6c944ad@gmail.com>
On Sun, 2020-05-24 at 20:13 +0200, Matthias Brugger wrote:
>
> On 24/05/2020 19:31, Dennis-YC Hsieh wrote:
> > Hi Matthias,
> >
> > Thanks for your comment.
> >
> > On Sat, 2020-05-16 at 20:20 +0200, Matthias Brugger wrote:
> >>
> >> On 08/03/2020 11:52, Dennis YC Hsieh wrote:
> >>> add write_s function in cmdq helper functions which
> >>> writes a constant value to address with large dma
> >>> access support.
> >>>
> >>> Signed-off-by: Dennis YC Hsieh <dennis-yc.hsieh@mediatek.com>
> >>> Reviewed-by: CK Hu <ck.hu@mediatek.com>
> >>> ---
> >>> drivers/soc/mediatek/mtk-cmdq-helper.c | 26 ++++++++++++++++++++++++++
> >>> include/linux/soc/mediatek/mtk-cmdq.h | 14 ++++++++++++++
> >>> 2 files changed, 40 insertions(+)
> >>>
> >>> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
> >>> index 03c129230cd7..a9ebbabb7439 100644
> >>> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> >>> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> >>> @@ -269,6 +269,32 @@ int cmdq_pkt_write_s(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
> >>> }
> >>> EXPORT_SYMBOL(cmdq_pkt_write_s);
> >>>
> >>> +int cmdq_pkt_write_s_value(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
> >>> + u16 addr_low, u32 value, u32 mask)
> >>> +{
> >>> + struct cmdq_instruction inst = { {0} };
> >>> + int err;
> >>> +
> >>> + if (mask != U32_MAX) {
> >>> + inst.op = CMDQ_CODE_MASK;
> >>> + inst.mask = ~mask;
> >>> + err = cmdq_pkt_append_command(pkt, inst);
> >>> + if (err < 0)
> >>> + return err;
> >>> +
> >>> + inst.op = CMDQ_CODE_WRITE_S_MASK;
> >>> + } else {
> >>> + inst.op = CMDQ_CODE_WRITE_S;
> >>> + }
> >>> +
> >>> + inst.sop = high_addr_reg_idx;
> >>
> >> Writing u16 value in a 5 bit wide variable?
> >
> > We need only 5 bits in this case. I'll change high_addr_reg_idx
> > parameter to u8.
> >
>
> Ok, please make sure to mask the value, so that it's explicit in the code that
> we only use the lowest 5 bits of high_addr_reg_idx.
Is it necessary to mask the value?
Since sop already defined as "u8 sop:5;", I thought it is explicit that
only use 5 bits and compiler should do the rest jobs.
Regards,
Dennis
>
> Regards,
> Matthias
>
> >>
> >>> + inst.offset = addr_low;
> >>> + inst.value = value;
> >>> +
> >>> + return cmdq_pkt_append_command(pkt, inst);
> >>> +}
> >>> +EXPORT_SYMBOL(cmdq_pkt_write_s_value);
> >>> +
> >>> int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
> >>> {
> >>> struct cmdq_instruction inst = { {0} };
> >>> diff --git a/include/linux/soc/mediatek/mtk-cmdq.h b/include/linux/soc/mediatek/mtk-cmdq.h
> >>> index 01b4184af310..fec292aac83c 100644
> >>> --- a/include/linux/soc/mediatek/mtk-cmdq.h
> >>> +++ b/include/linux/soc/mediatek/mtk-cmdq.h
> >>> @@ -135,6 +135,20 @@ int cmdq_pkt_read_s(struct cmdq_pkt *pkt, u16 high_addr_reg_idx, u16 addr_low,
> >>> int cmdq_pkt_write_s(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
> >>> u16 addr_low, u16 src_reg_idx, u32 mask);
> >>>
> >>> +/**
> >>> + * cmdq_pkt_write_s_value() - append write_s command with mask to the CMDQ
> >>> + * packet which write value to a physical address
> >>> + * @pkt: the CMDQ packet
> >>> + * @high_addr_reg_idx: internal regisger ID which contains high address of pa
> >>
> >> register
> >
> > will fix
> >
> >
> > Regards,
> > Dennis
> >
> >>
> >>> + * @addr_low: low address of pa
> >>> + * @value: the specified target value
> >>> + * @mask: the specified target mask
> >>> + *
> >>> + * Return: 0 for success; else the error code is returned
> >>> + */
> >>> +int cmdq_pkt_write_s_value(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
> >>> + u16 addr_low, u32 value, u32 mask);
> >>> +
> >>> /**
> >>> * cmdq_pkt_wfe() - append wait for event command to the CMDQ packet
> >>> * @pkt: the CMDQ packet
> >>>
> >
^ permalink raw reply
* [PATCH v5 3/3] ARM: dts: Add Caninos Loucos Labrador
From: Matheus Castello @ 2020-05-25 1:30 UTC (permalink / raw)
To: afaerber, manivannan.sadhasivam, mark.rutland, robh+dt
Cc: edgar.righi, igor.lima, linux-arm-kernel, devicetree,
linux-kernel, linux-actions, Matheus Castello
In-Reply-To: <20200525013008.108750-1-matheus@castello.eng.br>
Add Device Trees for Caninos Loucos Labrador CoM and base board.
Based on the work of Andreas Färber on Lemaker Guitar device tree.
Signed-off-by: Matheus Castello <matheus@castello.eng.br>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: Andreas Färber <afaerber@suse.de>
---
arch/arm/boot/dts/Makefile | 1 +
.../arm/boot/dts/owl-s500-labrador-base-m.dts | 34 +++++++++++++++++++
arch/arm/boot/dts/owl-s500-labrador-v2.dtsi | 22 ++++++++++++
3 files changed, 57 insertions(+)
create mode 100644 arch/arm/boot/dts/owl-s500-labrador-base-m.dts
create mode 100644 arch/arm/boot/dts/owl-s500-labrador-v2.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index e8dd99201397..0f8c1f255574 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -856,6 +856,7 @@ dtb-$(CONFIG_ARCH_ORION5X) += \
dtb-$(CONFIG_ARCH_ACTIONS) += \
owl-s500-cubieboard6.dtb \
owl-s500-guitar-bb-rev-b.dtb \
+ owl-s500-labrador-base-m.dtb \
owl-s500-sparky.dtb
dtb-$(CONFIG_ARCH_PRIMA2) += \
prima2-evb.dtb
diff --git a/arch/arm/boot/dts/owl-s500-labrador-base-m.dts b/arch/arm/boot/dts/owl-s500-labrador-base-m.dts
new file mode 100644
index 000000000000..044568fec25e
--- /dev/null
+++ b/arch/arm/boot/dts/owl-s500-labrador-base-m.dts
@@ -0,0 +1,34 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Caninos Labrador Base Board
+ *
+ * Copyright (c) 2019-2020 Matheus Castello
+ */
+
+/dts-v1/;
+
+#include "owl-s500-labrador-v2.dtsi"
+
+/ {
+ model = "Caninos Labrador Base-M v1.0a";
+ compatible = "caninos,labrador-base-m", "actions,s500";
+
+ aliases {
+ serial3 = &uart3;
+ };
+
+ chosen {
+ stdout-path = "serial3:115200n8";
+ };
+
+ uart3_clk: uart3-clk {
+ compatible = "fixed-clock";
+ clock-frequency = <921600>;
+ #clock-cells = <0>;
+ };
+};
+
+&uart3 {
+ status = "okay";
+ clocks = <&uart3_clk>;
+};
diff --git a/arch/arm/boot/dts/owl-s500-labrador-v2.dtsi b/arch/arm/boot/dts/owl-s500-labrador-v2.dtsi
new file mode 100644
index 000000000000..883ff2f9886d
--- /dev/null
+++ b/arch/arm/boot/dts/owl-s500-labrador-v2.dtsi
@@ -0,0 +1,22 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Caninos Labrador SoM V2
+ *
+ * Copyright (c) 2019-2020 Matheus Castello
+ */
+
+#include "owl-s500.dtsi"
+
+/ {
+ model = "Caninos Labrador Core V2.1";
+ compatible = "caninos,labrador-v2", "actions,s500";
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x0 0x80000000>;
+ };
+};
+
+&timer {
+ clocks = <&hosc>;
+};
--
2.26.2
^ permalink raw reply related
* [PATCH v5 1/3] dt-bindings: Add vendor prefix for Caninos Loucos
From: Matheus Castello @ 2020-05-25 1:30 UTC (permalink / raw)
To: afaerber, manivannan.sadhasivam, mark.rutland, robh+dt
Cc: edgar.righi, igor.lima, linux-arm-kernel, devicetree,
linux-kernel, linux-actions, Matheus Castello, Rob Herring
In-Reply-To: <20200525013008.108750-1-matheus@castello.eng.br>
The Caninos Loucos Program develops Single Board Computers with an open
structure. The Program wants to form a community of developers to use
IoT technologies and disseminate the learning of embedded systems in
Brazil.
It is an initiative of the Technological Integrated Systems Laboratory
(LSI-TEC) with the support of Polytechnic School of the University of
São Paulo (Poli-USP) and Jon "Maddog" Hall.
Signed-off-by: Matheus Castello <matheus@castello.eng.br>
Acked-by: Rob Herring <robh@kernel.org>
Reviewed-by: Andreas Färber <afaerber@suse.de>
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index d3891386d671..a20a05e3deaa 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -167,6 +167,8 @@ patternProperties:
description: CALAO Systems SAS
"^calxeda,.*":
description: Calxeda
+ "^caninos,.*":
+ description: Caninos Loucos Program
"^capella,.*":
description: Capella Microsystems, Inc
"^cascoda,.*":
--
2.26.2
^ permalink raw reply related
* [PATCH v5 2/3] dt-bindings: arm: actions: Document Caninos Loucos Labrador
From: Matheus Castello @ 2020-05-25 1:30 UTC (permalink / raw)
To: afaerber, manivannan.sadhasivam, mark.rutland, robh+dt
Cc: edgar.righi, igor.lima, linux-arm-kernel, devicetree,
linux-kernel, linux-actions, Matheus Castello, Rob Herring
In-Reply-To: <20200525013008.108750-1-matheus@castello.eng.br>
Update the documentation to add the Caninos Loucos Labrador. Labrador
project consists of a computer on module based on the Actions Semi S500
processor and the Labrador base board.
Signed-off-by: Matheus Castello <matheus@castello.eng.br>
Acked-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/arm/actions.yaml | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/actions.yaml b/Documentation/devicetree/bindings/arm/actions.yaml
index ace3fdaa8396..2187e1c5bc73 100644
--- a/Documentation/devicetree/bindings/arm/actions.yaml
+++ b/Documentation/devicetree/bindings/arm/actions.yaml
@@ -19,6 +19,11 @@ properties:
- allo,sparky # Allo.com Sparky
- cubietech,cubieboard6 # Cubietech CubieBoard6
- const: actions,s500
+ - items:
+ - enum:
+ - caninos,labrador-v2 # Labrador Core v2
+ - caninos,labrador-base-m # Labrador Base Board M v1
+ - const: actions,s500
- items:
- enum:
- lemaker,guitar-bb-rev-b # LeMaker Guitar Base Board rev. B
--
2.26.2
^ permalink raw reply related
* [PATCH v5 0/3] Add Caninos Loucos Labrador CoM and Base Board Device Tree
From: Matheus Castello @ 2020-05-25 1:30 UTC (permalink / raw)
To: afaerber, manivannan.sadhasivam, mark.rutland, robh+dt
Cc: edgar.righi, igor.lima, linux-arm-kernel, devicetree,
linux-kernel, linux-actions, Matheus Castello
Sorry for the delay.
Thanks Andreas, Mani and Rob for your time reviewing it.
Changes since v4:
(Suggested by Rob Herring)
- Fix issues with yaml indentation
Changes since v3:
(Suggested by Andreas Färber)
- Fix sort on actions.yaml
- Change the file owl-s500-labrador-bb.dts to owl-s500-labrador-base-m.dts
- Add description for both the SoM and Base Board
- Add Model description for both the SoM and Base Board
Matheus Castello (3):
dt-bindings: Add vendor prefix for Caninos Loucos
dt-bindings: arm: actions: Document Caninos Loucos Labrador
ARM: dts: Add Caninos Loucos Labrador
.../devicetree/bindings/arm/actions.yaml | 5 +++
.../devicetree/bindings/vendor-prefixes.yaml | 2 ++
arch/arm/boot/dts/Makefile | 1 +
.../arm/boot/dts/owl-s500-labrador-base-m.dts | 34 +++++++++++++++++++
arch/arm/boot/dts/owl-s500-labrador-v2.dtsi | 22 ++++++++++++
5 files changed, 64 insertions(+)
create mode 100644 arch/arm/boot/dts/owl-s500-labrador-base-m.dts
create mode 100644 arch/arm/boot/dts/owl-s500-labrador-v2.dtsi
--
2.26.2
^ permalink raw reply
* Re: [PATCH v5 10/13] soc: mediatek: cmdq: export finalize function
From: Chun-Kuang Hu @ 2020-05-25 0:23 UTC (permalink / raw)
To: Matthias Brugger
Cc: Dennis YC Hsieh, Rob Herring, Mark Rutland, Jassi Brar,
Philipp Zabel, David Airlie, Daniel Vetter, devicetree,
wsd_upstream, linux-kernel, DRI Development, HS Liao,
moderated list:ARM/Mediatek SoC support, Houlong Wei, Linux ARM
In-Reply-To: <5d6b61b2-23c9-647f-fa22-73e779010bd8@gmail.com>
Hi, Matthias:
Matthias Brugger <matthias.bgg@gmail.com> 於 2020年5月17日 週日 上午2:22寫道：
>
>
>
> On 08/03/2020 11:52, Dennis YC Hsieh wrote:
> > Export finalize function to client which helps append eoc and jump
> > command to pkt. Let client decide call finalize or not.
> >
> > Signed-off-by: Dennis YC Hsieh <dennis-yc.hsieh@mediatek.com>
> > Reviewed-by: CK Hu <ck.hu@mediatek.com>
> > ---
> > drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 1 +
> > drivers/soc/mediatek/mtk-cmdq-helper.c | 7 ++-----
> > include/linux/soc/mediatek/mtk-cmdq.h | 8 ++++++++
> > 3 files changed, 11 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > index 0dfcd1787e65..7daaabc26eb1 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > @@ -490,6 +490,7 @@ static void mtk_drm_crtc_hw_config(struct mtk_drm_crtc *mtk_crtc)
> > cmdq_pkt_clear_event(cmdq_handle, mtk_crtc->cmdq_event);
> > cmdq_pkt_wfe(cmdq_handle, mtk_crtc->cmdq_event);
> > mtk_crtc_ddp_config(crtc, cmdq_handle);
> > + cmdq_pkt_finalize(cmdq_handle);
> > cmdq_pkt_flush_async(cmdq_handle, ddp_cmdq_cb, cmdq_handle);
> > }
> > #endif
>
> This should be a independent patch.
> Other then that patch looks good.
Apply only drm part or only cmdq helpr part, it would be abnormal.
Shall we seperate this patch?
Or seperate it but make sure these two patches be in the same tree?
Regards,
Chun-Kuang.
>
> > diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
> > index a9ebbabb7439..59bc1164b411 100644
> > --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> > +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> > @@ -372,7 +372,7 @@ int cmdq_pkt_assign(struct cmdq_pkt *pkt, u16 reg_idx, u32 value)
> > }
> > EXPORT_SYMBOL(cmdq_pkt_assign);
> >
> > -static int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
> > +int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
> > {
> > struct cmdq_instruction inst = { {0} };
> > int err;
> > @@ -392,6 +392,7 @@ static int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
> >
> > return err;
> > }
> > +EXPORT_SYMBOL(cmdq_pkt_finalize);
> >
> > static void cmdq_pkt_flush_async_cb(struct cmdq_cb_data data)
> > {
> > @@ -426,10 +427,6 @@ int cmdq_pkt_flush_async(struct cmdq_pkt *pkt, cmdq_async_flush_cb cb,
> > unsigned long flags = 0;
> > struct cmdq_client *client = (struct cmdq_client *)pkt->cl;
> >
> > - err = cmdq_pkt_finalize(pkt);
> > - if (err < 0)
> > - return err;
> > -
> > pkt->cb.cb = cb;
> > pkt->cb.data = data;
> > pkt->async_cb.cb = cmdq_pkt_flush_async_cb;
> > diff --git a/include/linux/soc/mediatek/mtk-cmdq.h b/include/linux/soc/mediatek/mtk-cmdq.h
> > index fec292aac83c..99e77155f967 100644
> > --- a/include/linux/soc/mediatek/mtk-cmdq.h
> > +++ b/include/linux/soc/mediatek/mtk-cmdq.h
> > @@ -213,6 +213,14 @@ int cmdq_pkt_poll_mask(struct cmdq_pkt *pkt, u8 subsys,
> > */
> > int cmdq_pkt_assign(struct cmdq_pkt *pkt, u16 reg_idx, u32 value);
> >
> > +/**
> > + * cmdq_pkt_finalize() - Append EOC and jump command to pkt.
> > + * @pkt: the CMDQ packet
> > + *
> > + * Return: 0 for success; else the error code is returned
> > + */
> > +int cmdq_pkt_finalize(struct cmdq_pkt *pkt);
> > +
> > /**
> > * cmdq_pkt_flush_async() - trigger CMDQ to asynchronously execute the CMDQ
> > * packet and call back at the end of done packet
> >
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v3 1/8] dt-bindings: net: meson-dwmac: Add the amlogic,rx-delay-ns property
From: Florian Fainelli @ 2020-05-24 22:05 UTC (permalink / raw)
To: Pavel Machek, Martin Blumenstingl
Cc: robh+dt, andrew, linux-amlogic, devicetree, jianxin.pan, davem,
netdev, linux-kernel, linux-arm-kernel
In-Reply-To: <20200524212843.GF1192@bug>
On 5/24/2020 2:28 PM, Pavel Machek wrote:
> On Tue 2020-05-12 23:10:56, Martin Blumenstingl wrote:
>> The PRG_ETHERNET registers on Meson8b and newer SoCs can add an RX
>> delay. Add a property with the known supported values so it can be
>> configured according to the board layout.
>>
>> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
>> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
>> ---
>> .../bindings/net/amlogic,meson-dwmac.yaml | 13 +++++++++++++
>> 1 file changed, 13 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
>> index ae91aa9d8616..66074314e57a 100644
>> --- a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
>> +++ b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
>> @@ -67,6 +67,19 @@ allOf:
>> PHY and MAC are adding a delay).
>> Any configuration is ignored when the phy-mode is set to "rmii".
>>
>> + amlogic,rx-delay-ns:
>> + enum:
>
> Is it likely other MACs will need rx-delay property, too? Should we get rid of the amlogic,
> prefix?
Yes, there are several MAC bindings that already define a delay property:
Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml:
allwinner,rx-delay-ps:
Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml:
allwinner,rx-delay-ps:
Documentation/devicetree/bindings/net/apm-xgene-enet.txt:- rx-delay:
Delay value for RGMII bridge RX clock.
Documentation/devicetree/bindings/net/apm-xgene-enet.txt: rx-delay
= <2>;
Documentation/devicetree/bindings/net/cavium-pip.txt:- rx-delay: Delay
value for RGMII receive clock. Optional. Disabled if 0.
Documentation/devicetree/bindings/net/mediatek-dwmac.txt:-
mediatek,rx-delay-ps: RX clock delay macro value. Default is 0.
Documentation/devicetree/bindings/net/mediatek-dwmac.txt:
mediatek,rx-delay-ps = <1530>;
standardizing on rx-delay-ps and tx-delay-ps would make sense since that
is the lowest resolution and the property would be correctly named with
an unit in the name.
--
Florian
^ permalink raw reply
* [PATCH 5/8] dt-bindings: usb: usb-xhci: Document r8a7742 support
From: Lad Prabhakar @ 2020-05-24 21:37 UTC (permalink / raw)
To: Geert Uytterhoeven, Vinod Koul, Rob Herring, Bjorn Helgaas,
Kishon Vijay Abraham I, Greg Kroah-Hartman, Magnus Damm
Cc: dmaengine, linux-pci, linux-usb, linux-renesas-soc, devicetree,
linux-kernel, Prabhakar, Lad Prabhakar
In-Reply-To: <1590356277-19993-1-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
Document r8a7742 xhci support. The driver will use the fallback
compatible string "renesas,rcar-gen2-xhci", therefore no driver
change is needed.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
---
Documentation/devicetree/bindings/usb/usb-xhci.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt b/Documentation/devicetree/bindings/usb/usb-xhci.txt
index 3f37895..ce54791 100644
--- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
@@ -7,6 +7,7 @@ Required properties:
- "marvell,armada3700-xhci" for Armada 37xx SoCs
- "marvell,armada-375-xhci" for Armada 375 SoCs
- "marvell,armada-380-xhci" for Armada 38x SoCs
+ - "renesas,xhci-r8a7742" for r8a7742 SoC
- "renesas,xhci-r8a7743" for r8a7743 SoC
- "renesas,xhci-r8a7744" for r8a7744 SoC
- "renesas,xhci-r8a774a1" for r8a774a1 SoC
--
2.7.4
^ permalink raw reply related
* [PATCH 6/8] ARM: dts: r8a7742: Add USB 2.0 host support
From: Lad Prabhakar @ 2020-05-24 21:37 UTC (permalink / raw)
To: Geert Uytterhoeven, Vinod Koul, Rob Herring, Bjorn Helgaas,
Kishon Vijay Abraham I, Greg Kroah-Hartman, Magnus Damm
Cc: dmaengine, linux-pci, linux-usb, linux-renesas-soc, devicetree,
linux-kernel, Prabhakar, Lad Prabhakar
In-Reply-To: <1590356277-19993-1-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
Describe internal PCI bridge devices, USB phy device and
link PCI USB devices to USB phy.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
---
arch/arm/boot/dts/r8a7742.dtsi | 115 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 115 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7742.dtsi b/arch/arm/boot/dts/r8a7742.dtsi
index df914da..5be3da7 100644
--- a/arch/arm/boot/dts/r8a7742.dtsi
+++ b/arch/arm/boot/dts/r8a7742.dtsi
@@ -505,6 +505,28 @@
status = "disabled";
};
+ usbphy: usb-phy@e6590100 {
+ compatible = "renesas,usb-phy-r8a7742",
+ "renesas,rcar-gen2-usb-phy";
+ reg = <0 0xe6590100 0 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&cpg CPG_MOD 704>;
+ clock-names = "usbhs";
+ power-domains = <&sysc R8A7742_PD_ALWAYS_ON>;
+ resets = <&cpg 704>;
+ status = "disabled";
+
+ usb0: usb-channel@0 {
+ reg = <0>;
+ #phy-cells = <1>;
+ };
+ usb2: usb-channel@2 {
+ reg = <2>;
+ #phy-cells = <1>;
+ };
+ };
+
dmac0: dma-controller@e6700000 {
compatible = "renesas,dmac-r8a7742",
"renesas,rcar-dmac";
@@ -754,6 +776,99 @@
status = "disabled";
};
+ pci0: pci@ee090000 {
+ compatible = "renesas,pci-r8a7742",
+ "renesas,pci-rcar-gen2";
+ device_type = "pci";
+ reg = <0 0xee090000 0 0xc00>,
+ <0 0xee080000 0 0x1100>;
+ interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 703>;
+ power-domains = <&sysc R8A7742_PD_ALWAYS_ON>;
+ resets = <&cpg 703>;
+ status = "disabled";
+
+ bus-range = <0 0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ ranges = <0x02000000 0 0xee080000 0 0xee080000 0 0x00010000>;
+ interrupt-map-mask = <0xf800 0 0 0x7>;
+ interrupt-map = <0x0000 0 0 1 &gic GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>,
+ <0x0800 0 0 1 &gic GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>,
+ <0x1000 0 0 2 &gic GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
+
+ usb@1,0 {
+ reg = <0x800 0 0 0 0>;
+ phys = <&usb0 0>;
+ phy-names = "usb";
+ };
+
+ usb@2,0 {
+ reg = <0x1000 0 0 0 0>;
+ phys = <&usb0 0>;
+ phy-names = "usb";
+ };
+ };
+
+ pci1: pci@ee0b0000 {
+ compatible = "renesas,pci-r8a7742",
+ "renesas,pci-rcar-gen2";
+ device_type = "pci";
+ reg = <0 0xee0b0000 0 0xc00>,
+ <0 0xee0a0000 0 0x1100>;
+ interrupts = <GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 703>;
+ power-domains = <&sysc R8A7742_PD_ALWAYS_ON>;
+ resets = <&cpg 703>;
+ status = "disabled";
+
+ bus-range = <1 1>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ ranges = <0x02000000 0 0xee0a0000 0 0xee0a0000 0 0x00010000>;
+ interrupt-map-mask = <0xf800 0 0 0x7>;
+ interrupt-map = <0x0000 0 0 1 &gic GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>,
+ <0x0800 0 0 1 &gic GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>,
+ <0x1000 0 0 2 &gic GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ pci2: pci@ee0d0000 {
+ compatible = "renesas,pci-r8a7742",
+ "renesas,pci-rcar-gen2";
+ device_type = "pci";
+ clocks = <&cpg CPG_MOD 703>;
+ power-domains = <&sysc R8A7742_PD_ALWAYS_ON>;
+ resets = <&cpg 703>;
+ reg = <0 0xee0d0000 0 0xc00>,
+ <0 0xee0c0000 0 0x1100>;
+ interrupts = <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+
+ bus-range = <2 2>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ ranges = <0x02000000 0 0xee0c0000 0 0xee0c0000 0 0x00010000>;
+ interrupt-map-mask = <0xf800 0 0 0x7>;
+ interrupt-map = <0x0000 0 0 1 &gic GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>,
+ <0x0800 0 0 1 &gic GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>,
+ <0x1000 0 0 2 &gic GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>;
+
+ usb@1,0 {
+ reg = <0x20800 0 0 0 0>;
+ phys = <&usb2 0>;
+ phy-names = "usb";
+ };
+
+ usb@2,0 {
+ reg = <0x21000 0 0 0 0>;
+ phys = <&usb2 0>;
+ phy-names = "usb";
+ };
+ };
+
sdhi0: sd@ee100000 {
compatible = "renesas,sdhi-r8a7742",
"renesas,rcar-gen2-sdhi";
--
2.7.4
^ permalink raw reply related
* [PATCH 7/8] ARM: dts: r8a7742: Add USB-DMAC and HSUSB device nodes
From: Lad Prabhakar @ 2020-05-24 21:37 UTC (permalink / raw)
To: Geert Uytterhoeven, Vinod Koul, Rob Herring, Bjorn Helgaas,
Kishon Vijay Abraham I, Greg Kroah-Hartman, Magnus Damm
Cc: dmaengine, linux-pci, linux-usb, linux-renesas-soc, devicetree,
linux-kernel, Prabhakar, Lad Prabhakar
In-Reply-To: <1590356277-19993-1-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
Add usb dmac and hsusb device nodes on RZ/G1H SoC dtsi.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
---
arch/arm/boot/dts/r8a7742.dtsi | 45 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 45 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7742.dtsi b/arch/arm/boot/dts/r8a7742.dtsi
index 5be3da7..cbf3d85 100644
--- a/arch/arm/boot/dts/r8a7742.dtsi
+++ b/arch/arm/boot/dts/r8a7742.dtsi
@@ -505,6 +505,23 @@
status = "disabled";
};
+ hsusb: usb@e6590000 {
+ compatible = "renesas,usbhs-r8a7742",
+ "renesas,rcar-gen2-usbhs";
+ reg = <0 0xe6590000 0 0x100>;
+ interrupts = <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 704>;
+ dmas = <&usb_dmac0 0>, <&usb_dmac0 1>,
+ <&usb_dmac1 0>, <&usb_dmac1 1>;
+ dma-names = "ch0", "ch1", "ch2", "ch3";
+ power-domains = <&sysc R8A7742_PD_ALWAYS_ON>;
+ resets = <&cpg 704>;
+ renesas,buswait = <4>;
+ phys = <&usb0 1>;
+ phy-names = "usb";
+ status = "disabled";
+ };
+
usbphy: usb-phy@e6590100 {
compatible = "renesas,usb-phy-r8a7742",
"renesas,rcar-gen2-usb-phy";
@@ -527,6 +544,34 @@
};
};
+ usb_dmac0: dma-controller@e65a0000 {
+ compatible = "renesas,r8a7742-usb-dmac",
+ "renesas,usb-dmac";
+ reg = <0 0xe65a0000 0 0x100>;
+ interrupts = <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "ch0", "ch1";
+ clocks = <&cpg CPG_MOD 330>;
+ power-domains = <&sysc R8A7742_PD_ALWAYS_ON>;
+ resets = <&cpg 330>;
+ #dma-cells = <1>;
+ dma-channels = <2>;
+ };
+
+ usb_dmac1: dma-controller@e65b0000 {
+ compatible = "renesas,r8a7742-usb-dmac",
+ "renesas,usb-dmac";
+ reg = <0 0xe65b0000 0 0x100>;
+ interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "ch0", "ch1";
+ clocks = <&cpg CPG_MOD 331>;
+ power-domains = <&sysc R8A7742_PD_ALWAYS_ON>;
+ resets = <&cpg 331>;
+ #dma-cells = <1>;
+ dma-channels = <2>;
+ };
+
dmac0: dma-controller@e6700000 {
compatible = "renesas,dmac-r8a7742",
"renesas,rcar-dmac";
--
2.7.4
^ permalink raw reply related
* [PATCH 8/8] ARM: dts: r8a7742: Add xhci support
From: Lad Prabhakar @ 2020-05-24 21:37 UTC (permalink / raw)
To: Geert Uytterhoeven, Vinod Koul, Rob Herring, Bjorn Helgaas,
Kishon Vijay Abraham I, Greg Kroah-Hartman, Magnus Damm
Cc: dmaengine, linux-pci, linux-usb, linux-renesas-soc, devicetree,
linux-kernel, Prabhakar, Lad Prabhakar
In-Reply-To: <1590356277-19993-1-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
Add xhci support to R8A7742 SoC DT.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
---
arch/arm/boot/dts/r8a7742.dtsi | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7742.dtsi b/arch/arm/boot/dts/r8a7742.dtsi
index cbf3d85..3a9c67b 100644
--- a/arch/arm/boot/dts/r8a7742.dtsi
+++ b/arch/arm/boot/dts/r8a7742.dtsi
@@ -821,6 +821,19 @@
status = "disabled";
};
+ xhci: usb@ee000000 {
+ compatible = "renesas,xhci-r8a7742",
+ "renesas,rcar-gen2-xhci";
+ reg = <0 0xee000000 0 0xc00>;
+ interrupts = <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 328>;
+ power-domains = <&sysc R8A7742_PD_ALWAYS_ON>;
+ resets = <&cpg 328>;
+ phys = <&usb2 1>;
+ phy-names = "usb";
+ status = "disabled";
+ };
+
pci0: pci@ee090000 {
compatible = "renesas,pci-r8a7742",
"renesas,pci-rcar-gen2";
--
2.7.4
^ permalink raw reply related
* [PATCH 4/8] dt-bindings: dmaengine: renesas,usb-dmac: Add binding for r8a7742
From: Lad Prabhakar @ 2020-05-24 21:37 UTC (permalink / raw)
To: Geert Uytterhoeven, Vinod Koul, Rob Herring, Bjorn Helgaas,
Kishon Vijay Abraham I, Greg Kroah-Hartman, Magnus Damm
Cc: dmaengine, linux-pci, linux-usb, linux-renesas-soc, devicetree,
linux-kernel, Prabhakar, Lad Prabhakar
In-Reply-To: <1590356277-19993-1-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
Document RZ/G1H (R8A7742) SoC bindings.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
---
Documentation/devicetree/bindings/dma/renesas,usb-dmac.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/dma/renesas,usb-dmac.yaml b/Documentation/devicetree/bindings/dma/renesas,usb-dmac.yaml
index 9ca6d8d..03aea6a 100644
--- a/Documentation/devicetree/bindings/dma/renesas,usb-dmac.yaml
+++ b/Documentation/devicetree/bindings/dma/renesas,usb-dmac.yaml
@@ -16,6 +16,7 @@ properties:
compatible:
items:
- enum:
+ - renesas,r8a7742-usb-dmac # RZ/G1H
- renesas,r8a7743-usb-dmac # RZ/G1M
- renesas,r8a7744-usb-dmac # RZ/G1N
- renesas,r8a7745-usb-dmac # RZ/G1E
--
2.7.4
^ permalink raw reply related
* [PATCH 3/8] dt-bindings: usb: renesas,usbhs: Add support for r8a7742
From: Lad Prabhakar @ 2020-05-24 21:37 UTC (permalink / raw)
To: Geert Uytterhoeven, Vinod Koul, Rob Herring, Bjorn Helgaas,
Kishon Vijay Abraham I, Greg Kroah-Hartman, Magnus Damm
Cc: dmaengine, linux-pci, linux-usb, linux-renesas-soc, devicetree,
linux-kernel, Prabhakar, Lad Prabhakar
In-Reply-To: <1590356277-19993-1-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
Document support for RZ/G1H (R8A7742) SoC.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
---
Documentation/devicetree/bindings/usb/renesas,usbhs.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml b/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml
index 469affa..32ade41 100644
--- a/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml
+++ b/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml
@@ -22,6 +22,7 @@ properties:
- items:
- enum:
+ - renesas,usbhs-r8a7742 # RZ/G1H
- renesas,usbhs-r8a7743 # RZ/G1M
- renesas,usbhs-r8a7744 # RZ/G1N
- renesas,usbhs-r8a7745 # RZ/G1E
--
2.7.4
^ permalink raw reply related
* [PATCH 2/8] dt-bindings: PCI: pci-rcar-gen2: Add device tree support for r8a7742
From: Lad Prabhakar @ 2020-05-24 21:37 UTC (permalink / raw)
To: Geert Uytterhoeven, Vinod Koul, Rob Herring, Bjorn Helgaas,
Kishon Vijay Abraham I, Greg Kroah-Hartman, Magnus Damm
Cc: dmaengine, linux-pci, linux-usb, linux-renesas-soc, devicetree,
linux-kernel, Prabhakar, Lad Prabhakar
In-Reply-To: <1590356277-19993-1-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
Add internal PCI bridge support for r8a7742 SoC. The Renesas RZ/G1H
(R8A7742) internal PCI bridge is identical to the R-Car Gen2 family.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
---
Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
index b94078f..aeba38f 100644
--- a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
+++ b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
@@ -6,7 +6,8 @@ AHB. There is one bridge instance per USB port connected to the internal
OHCI and EHCI controllers.
Required properties:
-- compatible: "renesas,pci-r8a7743" for the R8A7743 SoC;
+- compatible: "renesas,pci-r8a7742" for the R8A7742 SoC;
+ "renesas,pci-r8a7743" for the R8A7743 SoC;
"renesas,pci-r8a7744" for the R8A7744 SoC;
"renesas,pci-r8a7745" for the R8A7745 SoC;
"renesas,pci-r8a7790" for the R8A7790 SoC;
--
2.7.4
^ permalink raw reply related
* [PATCH 1/8] dt-bindings: phy: rcar-gen2: Add r8a7742 support
From: Lad Prabhakar @ 2020-05-24 21:37 UTC (permalink / raw)
To: Geert Uytterhoeven, Vinod Koul, Rob Herring, Bjorn Helgaas,
Kishon Vijay Abraham I, Greg Kroah-Hartman, Magnus Damm
Cc: dmaengine, linux-pci, linux-usb, linux-renesas-soc, devicetree,
linux-kernel, Prabhakar, Lad Prabhakar
In-Reply-To: <1590356277-19993-1-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
Add USB PHY support for r8a7742 SoC. Renesas RZ/G1H (R8A7742)
USB PHY is identical to the R-Car Gen2 family.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
---
Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt b/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt
index ac96d64..a3bd1c4 100644
--- a/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt
+++ b/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt
@@ -4,7 +4,8 @@ This file provides information on what the device node for the R-Car generation
2 USB PHY contains.
Required properties:
-- compatible: "renesas,usb-phy-r8a7743" if the device is a part of R8A7743 SoC.
+- compatible: "renesas,usb-phy-r8a7742" if the device is a part of R8A7742 SoC.
+ "renesas,usb-phy-r8a7743" if the device is a part of R8A7743 SoC.
"renesas,usb-phy-r8a7744" if the device is a part of R8A7744 SoC.
"renesas,usb-phy-r8a7745" if the device is a part of R8A7745 SoC.
"renesas,usb-phy-r8a77470" if the device is a part of R8A77470 SoC.
--
2.7.4
^ permalink raw reply related
* [PATCH 0/8] R8A7742 add support for HSUSB and USB2.0/3.0
From: Lad Prabhakar @ 2020-05-24 21:37 UTC (permalink / raw)
To: Geert Uytterhoeven, Vinod Koul, Rob Herring, Bjorn Helgaas,
Kishon Vijay Abraham I, Greg Kroah-Hartman, Magnus Damm
Cc: dmaengine, linux-pci, linux-usb, linux-renesas-soc, devicetree,
linux-kernel, Prabhakar, Lad Prabhakar
Hi All,
This patch series adds support for HSUSB, USB2.0 and USB3.0 to
R8A7742 SoC DT.
This patch series applies on-top of [1].
[1] https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=288491
Cheers,
Prabhakar
Lad Prabhakar (8):
dt-bindings: phy: rcar-gen2: Add r8a7742 support
dt-bindings: PCI: pci-rcar-gen2: Add device tree support for r8a7742
dt-bindings: usb: renesas,usbhs: Add support for r8a7742
dt-bindings: dmaengine: renesas,usb-dmac: Add binding for r8a7742
dt-bindings: usb: usb-xhci: Document r8a7742 support
ARM: dts: r8a7742: Add USB 2.0 host support
ARM: dts: r8a7742: Add USB-DMAC and HSUSB device nodes
ARM: dts: r8a7742: Add xhci support
.../devicetree/bindings/dma/renesas,usb-dmac.yaml | 1 +
.../devicetree/bindings/pci/pci-rcar-gen2.txt | 3 +-
.../devicetree/bindings/phy/rcar-gen2-phy.txt | 3 +-
.../devicetree/bindings/usb/renesas,usbhs.yaml | 1 +
Documentation/devicetree/bindings/usb/usb-xhci.txt | 1 +
arch/arm/boot/dts/r8a7742.dtsi | 173 +++++++++++++++++++++
6 files changed, 180 insertions(+), 2 deletions(-)
--
2.7.4
^ permalink raw reply
* Re: [PATCH v3 1/8] dt-bindings: net: meson-dwmac: Add the amlogic,rx-delay-ns property
From: Pavel Machek @ 2020-05-24 21:28 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: robh+dt, andrew, f.fainelli, linux-amlogic, devicetree,
jianxin.pan, davem, netdev, linux-kernel, linux-arm-kernel
In-Reply-To: <20200512211103.530674-2-martin.blumenstingl@googlemail.com>
On Tue 2020-05-12 23:10:56, Martin Blumenstingl wrote:
> The PRG_ETHERNET registers on Meson8b and newer SoCs can add an RX
> delay. Add a property with the known supported values so it can be
> configured according to the board layout.
>
> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> ---
> .../bindings/net/amlogic,meson-dwmac.yaml | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
> index ae91aa9d8616..66074314e57a 100644
> --- a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
> +++ b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
> @@ -67,6 +67,19 @@ allOf:
> PHY and MAC are adding a delay).
> Any configuration is ignored when the phy-mode is set to "rmii".
>
> + amlogic,rx-delay-ns:
> + enum:
Is it likely other MACs will need rx-delay property, too? Should we get rid of the amlogic,
prefix?
Pavel
^ permalink raw reply
* [PATCH 00/10] Enable GPU for SM8150 and SM8250
From: Jonathan Marek @ 2020-05-24 21:06 UTC (permalink / raw)
To: linux-arm-msm
Cc: Andy Gross, Bjorn Andersson,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:COMMON CLK FRAMEWORK, open list, Michael Turquette,
Rob Herring, Stephen Boyd
This series adds the missing clock drivers and dts nodes to enable
the GPU on both SM8150 and SM8250.
Adreno 640/650 support was recently added to drm/msm [1], but an
extra patch [2] is still required for GPU to actually work on SM8250.
[1] https://patchwork.freedesktop.org/series/76198/
[2] https://gist.github.com/flto/784f1aca761ebf2fe6c105719a4a04ca
Jonathan Marek (10):
clk: qcom: clk-alpha-pll: remove unused/incorrect PLL_CAL_VAL
clk: qcom: clk-alpha-pll: same regs and ops for trion and lucid
clk: qcom: clk-alpha-pll: use the right PCAL_DONE value for lucid pll
clk: qcom: gcc: remove unnecessary vco_table from SM8150
dt-bindings: clock: Introduce SM8150 QCOM Graphics clock bindings
dt-bindings: clock: Introduce SM8250 QCOM Graphics clock bindings
clk: qcom: Add graphics clock controller driver for SM8150
clk: qcom: Add graphics clock controller driver for SM8250
arm64: dts: qcom: add sm8150 GPU nodes
arm64: dts: qcom: add sm8250 GPU nodes
arch/arm64/boot/dts/qcom/sm8150.dtsi | 132 +++++
arch/arm64/boot/dts/qcom/sm8250.dtsi | 139 ++++++
drivers/clk/qcom/Kconfig | 16 +
drivers/clk/qcom/Makefile | 2 +
drivers/clk/qcom/clk-alpha-pll.c | 70 ++-
drivers/clk/qcom/clk-alpha-pll.h | 15 +-
drivers/clk/qcom/gcc-sm8150.c | 18 +-
drivers/clk/qcom/gpucc-sm8150.c | 429 ++++++++++++++++
drivers/clk/qcom/gpucc-sm8250.c | 458 ++++++++++++++++++
include/dt-bindings/clock/qcom,gpucc-sm8150.h | 40 ++
include/dt-bindings/clock/qcom,gpucc-sm8250.h | 40 ++
11 files changed, 1304 insertions(+), 55 deletions(-)
create mode 100644 drivers/clk/qcom/gpucc-sm8150.c
create mode 100644 drivers/clk/qcom/gpucc-sm8250.c
create mode 100644 include/dt-bindings/clock/qcom,gpucc-sm8150.h
create mode 100644 include/dt-bindings/clock/qcom,gpucc-sm8250.h
--
2.26.1
^ permalink raw reply
* [PATCH 05/10] dt-bindings: clock: Introduce SM8150 QCOM Graphics clock bindings
From: Jonathan Marek @ 2020-05-24 21:06 UTC (permalink / raw)
To: linux-arm-msm
Cc: Andy Gross, Bjorn Andersson, Rob Herring, open list,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
In-Reply-To: <20200524210615.17035-1-jonathan@marek.ca>
Add device tree bindings for graphics clock controller for
Qualcomm Technology Inc's SM8150 SoCs.
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
---
include/dt-bindings/clock/qcom,gpucc-sm8150.h | 40 +++++++++++++++++++
1 file changed, 40 insertions(+)
create mode 100644 include/dt-bindings/clock/qcom,gpucc-sm8150.h
diff --git a/include/dt-bindings/clock/qcom,gpucc-sm8150.h b/include/dt-bindings/clock/qcom,gpucc-sm8150.h
new file mode 100644
index 000000000000..e7cac7fe9739
--- /dev/null
+++ b/include/dt-bindings/clock/qcom,gpucc-sm8150.h
@@ -0,0 +1,40 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2017-2020, The Linux Foundation. All rights reserved.
+ */
+
+#ifndef _DT_BINDINGS_CLK_QCOM_GPU_CC_SM8150_H
+#define _DT_BINDINGS_CLK_QCOM_GPU_CC_SM8150_H
+
+/* GPU_CC clock registers */
+#define GPU_CC_AHB_CLK 0
+#define GPU_CC_CRC_AHB_CLK 1
+#define GPU_CC_CX_APB_CLK 2
+#define GPU_CC_CX_GMU_CLK 3
+#define GPU_CC_CX_QDSS_AT_CLK 4
+#define GPU_CC_CX_QDSS_TRIG_CLK 5
+#define GPU_CC_CX_QDSS_TSCTR_CLK 6
+#define GPU_CC_CX_SNOC_DVM_CLK 7
+#define GPU_CC_CXO_AON_CLK 8
+#define GPU_CC_CXO_CLK 9
+#define GPU_CC_GMU_CLK_SRC 10
+#define GPU_CC_GX_GMU_CLK 11
+#define GPU_CC_GX_QDSS_TSCTR_CLK 12
+#define GPU_CC_GX_VSENSE_CLK 13
+#define GPU_CC_PLL1 14
+#define GPU_CC_PLL_TEST_CLK 15
+#define GPU_CC_SLEEP_CLK 16
+
+/* GPU_CC Resets */
+#define GPUCC_GPU_CC_CX_BCR 0
+#define GPUCC_GPU_CC_GFX3D_AON_BCR 1
+#define GPUCC_GPU_CC_GMU_BCR 2
+#define GPUCC_GPU_CC_GX_BCR 3
+#define GPUCC_GPU_CC_SPDM_BCR 4
+#define GPUCC_GPU_CC_XO_BCR 5
+
+/* GPU_CC GDSCRs */
+#define GPU_CX_GDSC 0
+#define GPU_GX_GDSC 1
+
+#endif
--
2.26.1
^ permalink raw reply related
* [PATCH 06/10] dt-bindings: clock: Introduce SM8250 QCOM Graphics clock bindings
From: Jonathan Marek @ 2020-05-24 21:06 UTC (permalink / raw)
To: linux-arm-msm
Cc: Andy Gross, Bjorn Andersson, Rob Herring, open list,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
In-Reply-To: <20200524210615.17035-1-jonathan@marek.ca>
Add device tree bindings for graphics clock controller for
Qualcomm Technology Inc's SM8250 SoCs.
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
---
include/dt-bindings/clock/qcom,gpucc-sm8250.h | 40 +++++++++++++++++++
1 file changed, 40 insertions(+)
create mode 100644 include/dt-bindings/clock/qcom,gpucc-sm8250.h
diff --git a/include/dt-bindings/clock/qcom,gpucc-sm8250.h b/include/dt-bindings/clock/qcom,gpucc-sm8250.h
new file mode 100644
index 000000000000..c8fe64e399fd
--- /dev/null
+++ b/include/dt-bindings/clock/qcom,gpucc-sm8250.h
@@ -0,0 +1,40 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2017-2020, The Linux Foundation. All rights reserved.
+ */
+
+#ifndef _DT_BINDINGS_CLK_QCOM_GPU_CC_SM8250_H
+#define _DT_BINDINGS_CLK_QCOM_GPU_CC_SM8250_H
+
+/* GPU_CC clock registers */
+#define GPU_CC_AHB_CLK 0
+#define GPU_CC_CRC_AHB_CLK 1
+#define GPU_CC_CX_APB_CLK 2
+#define GPU_CC_CX_GMU_CLK 3
+#define GPU_CC_CX_QDSS_AT_CLK 4
+#define GPU_CC_CX_QDSS_TRIG_CLK 5
+#define GPU_CC_CX_QDSS_TSCTR_CLK 6
+#define GPU_CC_CX_SNOC_DVM_CLK 7
+#define GPU_CC_CXO_AON_CLK 8
+#define GPU_CC_CXO_CLK 9
+#define GPU_CC_GMU_CLK_SRC 10
+#define GPU_CC_GX_GMU_CLK 11
+#define GPU_CC_GX_QDSS_TSCTR_CLK 12
+#define GPU_CC_GX_VSENSE_CLK 13
+#define GPU_CC_PLL1 14
+#define GPU_CC_SLEEP_CLK 15
+#define GPU_CC_HLOS1_VOTE_GPU_SMMU_CLK 16
+
+/* GPU_CC Resets */
+#define GPUCC_GPU_CC_ACD_BCR 0
+#define GPUCC_GPU_CC_CX_BCR 1
+#define GPUCC_GPU_CC_GFX3D_AON_BCR 2
+#define GPUCC_GPU_CC_GMU_BCR 3
+#define GPUCC_GPU_CC_GX_BCR 4
+#define GPUCC_GPU_CC_XO_BCR 5
+
+/* GPU_CC GDSCRs */
+#define GPU_CX_GDSC 0
+#define GPU_GX_GDSC 1
+
+#endif
--
2.26.1
^ permalink raw reply related
* [PATCH 09/10] arm64: dts: qcom: add sm8150 GPU nodes
From: Jonathan Marek @ 2020-05-24 21:06 UTC (permalink / raw)
To: linux-arm-msm
Cc: Andy Gross, Bjorn Andersson, Rob Herring,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
In-Reply-To: <20200524210615.17035-1-jonathan@marek.ca>
This brings up the GPU. Tested on HDK855 by running vulkan CTS.
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
---
arch/arm64/boot/dts/qcom/sm8150.dtsi | 132 +++++++++++++++++++++++++++
1 file changed, 132 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8150.dtsi b/arch/arm64/boot/dts/qcom/sm8150.dtsi
index 903514fc299f..1996e42ccb28 100644
--- a/arch/arm64/boot/dts/qcom/sm8150.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8150.dtsi
@@ -10,6 +10,7 @@
#include <dt-bindings/soc/qcom,rpmh-rsc.h>
#include <dt-bindings/clock/qcom,rpmh.h>
#include <dt-bindings/clock/qcom,gcc-sm8150.h>
+#include <dt-bindings/clock/qcom,gpucc-sm8150.h>
/ {
interrupt-parent = <&intc>;
@@ -540,6 +541,137 @@ glink-edge {
};
};
+ gpu: gpu@2c00000 {
+ /*
+ * note: the amd,imageon compatible makes it possible
+ * to use the drm/msm driver without the display node,
+ * make sure to remove it when display node is added
+ */
+ compatible = "qcom,adreno-640.1",
+ "qcom,adreno",
+ "amd,imageon";
+ #stream-id-cells = <16>;
+
+ reg = <0 0x2c00000 0 0x40000>;
+ reg-names = "kgsl_3d0_reg_memory";
+
+ interrupts = <GIC_SPI 300 IRQ_TYPE_LEVEL_HIGH>;
+
+ iommus = <&adreno_smmu 0 0x401>;
+
+ operating-points-v2 = <&gpu_opp_table>;
+
+ qcom,gmu = <&gmu>;
+
+ zap-shader {
+ memory-region = <&gpu_mem>;
+ };
+
+ /* note: downstream checks gpu binning for 675 Mhz */
+ gpu_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-675000000 {
+ opp-hz = /bits/ 64 <675000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_NOM_L1>;
+ };
+
+ opp-585000000 {
+ opp-hz = /bits/ 64 <585000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_NOM>;
+ };
+
+ opp-499200000 {
+ opp-hz = /bits/ 64 <499200000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_SVS_L2>;
+ };
+
+ opp-427000000 {
+ opp-hz = /bits/ 64 <427000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_SVS_L1>;
+ };
+
+ opp-345000000 {
+ opp-hz = /bits/ 64 <345000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_SVS>;
+ };
+
+ opp-257000000 {
+ opp-hz = /bits/ 64 <257000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS>;
+ };
+ };
+ };
+
+ gmu: gmu@2c6a000 {
+ compatible="qcom,adreno-gmu-640.1", "qcom,adreno-gmu";
+
+ reg = <0 0x2c6a000 0 0x30000>,
+ <0 0xb290000 0 0x10000>,
+ <0 0xb490000 0 0x10000>;
+ reg-names = "gmu", "gmu_pdc", "gmu_pdc_seq";
+
+ interrupts = <GIC_SPI 304 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 305 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "hfi", "gmu";
+
+ clocks = <&gpucc GPU_CC_AHB_CLK>,
+ <&gpucc GPU_CC_CX_GMU_CLK>,
+ <&gpucc GPU_CC_CXO_CLK>,
+ <&gcc GCC_DDRSS_GPU_AXI_CLK>,
+ <&gcc GCC_GPU_MEMNOC_GFX_CLK>;
+ clock-names = "ahb", "gmu", "cxo", "axi", "memnoc";
+
+ power-domains = <&gpucc GPU_CX_GDSC>,
+ <&gpucc GPU_GX_GDSC>;
+ power-domain-names = "cx", "gx";
+
+ iommus = <&adreno_smmu 5 0x400>;
+
+ operating-points-v2 = <&gmu_opp_table>;
+
+ gmu_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-200000000 {
+ opp-hz = /bits/ 64 <200000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_MIN_SVS>;
+ };
+ };
+ };
+
+ gpucc: clock-controller@2c90000 {
+ compatible = "qcom,sm8150-gpucc";
+ reg = <0 0x2c90000 0 0x9000>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ clocks = <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "xo";
+ };
+
+ adreno_smmu: iommu@2ca0000 {
+ compatible = "qcom,sdm845-smmu-500", "arm,mmu-500";
+ reg = <0 0x2ca0000 0 0x10000>;
+ #iommu-cells = <2>;
+ #global-interrupts = <1>;
+ interrupts = <GIC_SPI 674 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 681 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 682 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 683 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 684 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 685 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 686 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 687 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 688 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&gpucc GPU_CC_AHB_CLK>,
+ <&gcc GCC_GPU_MEMNOC_GFX_CLK>,
+ <&gcc GCC_GPU_SNOC_DVM_GFX_CLK>;
+ clock-names = "ahb", "bus", "iface";
+
+ power-domains = <&gpucc GPU_CX_GDSC>;
+ };
+
tlmm: pinctrl@3100000 {
compatible = "qcom,sm8150-pinctrl";
reg = <0x0 0x03100000 0x0 0x300000>,
--
2.26.1
^ permalink raw reply related
* [PATCH 10/10] arm64: dts: qcom: add sm8250 GPU nodes
From: Jonathan Marek @ 2020-05-24 21:06 UTC (permalink / raw)
To: linux-arm-msm
Cc: Andy Gross, Bjorn Andersson, Rob Herring,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
In-Reply-To: <20200524210615.17035-1-jonathan@marek.ca>
This brings up the GPU. Tested on HDK865 by running vulkan CTS.
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
---
arch/arm64/boot/dts/qcom/sm8250.dtsi | 139 +++++++++++++++++++++++++++
1 file changed, 139 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi b/arch/arm64/boot/dts/qcom/sm8250.dtsi
index 3bdce658c08a..a55d0e5d7425 100644
--- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
@@ -5,6 +5,7 @@
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/clock/qcom,gcc-sm8250.h>
+#include <dt-bindings/clock/qcom,gpucc-sm8250.h>
#include <dt-bindings/clock/qcom,rpmh.h>
#include <dt-bindings/power/qcom-rpmpd.h>
#include <dt-bindings/soc/qcom,rpmh-rsc.h>
@@ -387,6 +388,144 @@ tcsr_mutex: hwlock@1f40000 {
#hwlock-cells = <1>;
};
+ gpu: gpu@3d00000 {
+ /*
+ * note: the amd,imageon compatible makes it possible
+ * to use the drm/msm driver without the display node,
+ * make sure to remove it when display node is added
+ */
+ compatible = "qcom,adreno-650.2",
+ "qcom,adreno",
+ "amd,imageon";
+ #stream-id-cells = <16>;
+
+ reg = <0 0x3d00000 0 0x40000>;
+ reg-names = "kgsl_3d0_reg_memory";
+
+ interrupts = <GIC_SPI 300 IRQ_TYPE_LEVEL_HIGH>;
+
+ iommus = <&adreno_smmu 0 0x401>;
+
+ operating-points-v2 = <&gpu_opp_table>;
+
+ qcom,gmu = <&gmu>;
+
+ zap-shader {
+ memory-region = <&gpu_mem>;
+ };
+
+ /* note: downstream checks gpu binning for 670 Mhz */
+ gpu_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-670000000 {
+ opp-hz = /bits/ 64 <670000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_NOM_L1>;
+ };
+
+ opp-587000000 {
+ opp-hz = /bits/ 64 <587000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_NOM>;
+ };
+
+ opp-525000000 {
+ opp-hz = /bits/ 64 <525000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_SVS_L2>;
+ };
+
+ opp-490000000 {
+ opp-hz = /bits/ 64 <490000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_SVS_L1>;
+ };
+
+ /* opp-441600000 {
+ opp-hz = /bits/ 64 <441600000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_SVS_L0>;
+ }; */
+
+ opp-400000000 {
+ opp-hz = /bits/ 64 <400000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_SVS>;
+ };
+
+ opp-305000000 {
+ opp-hz = /bits/ 64 <305000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS>;
+ };
+ };
+ };
+
+ gmu: gmu@3d6a000 {
+ compatible="qcom,adreno-gmu-650.2", "qcom,adreno-gmu";
+
+ reg = <0 0x3d6a000 0 0x30000>,
+ <0 0x3de0000 0 0x10000>,
+ <0 0xb290000 0 0x10000>,
+ <0 0xb490000 0 0x10000>;
+ reg-names = "gmu", "rscc", "gmu_pdc", "gmu_pdc_seq";
+
+ interrupts = <GIC_SPI 304 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 305 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "hfi", "gmu";
+
+ clocks = <&gpucc GPU_CC_AHB_CLK>,
+ <&gpucc GPU_CC_CX_GMU_CLK>,
+ <&gpucc GPU_CC_CXO_CLK>,
+ <&gcc GCC_DDRSS_GPU_AXI_CLK>,
+ <&gcc GCC_GPU_MEMNOC_GFX_CLK>;
+ clock-names = "ahb", "gmu", "cxo", "axi", "memnoc";
+
+ power-domains = <&gpucc GPU_CX_GDSC>,
+ <&gpucc GPU_GX_GDSC>;
+ power-domain-names = "cx", "gx";
+
+ iommus = <&adreno_smmu 5 0x400>;
+
+ operating-points-v2 = <&gmu_opp_table>;
+
+ gmu_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-200000000 {
+ opp-hz = /bits/ 64 <200000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_MIN_SVS>;
+ };
+ };
+ };
+
+ gpucc: clock-controller@3d90000 {
+ compatible = "qcom,sm8250-gpucc";
+ reg = <0 0x3d90000 0 0x9000>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ clocks = <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "xo";
+ };
+
+ adreno_smmu: iommu@3da0000 {
+ compatible = "qcom,sdm845-smmu-500", "arm,mmu-500";
+ reg = <0 0x3da0000 0 0x10000>;
+ #iommu-cells = <2>;
+ #global-interrupts = <2>;
+ interrupts = <GIC_SPI 672 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 673 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 678 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 679 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 680 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 681 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 682 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 683 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 684 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 685 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&gpucc GPU_CC_AHB_CLK>,
+ <&gcc GCC_GPU_MEMNOC_GFX_CLK>,
+ <&gcc GCC_GPU_SNOC_DVM_GFX_CLK>;
+ clock-names = "ahb", "bus", "iface";
+
+ power-domains = <&gpucc GPU_CX_GDSC>;
+ };
+
usb_1_hsphy: phy@88e3000 {
compatible = "qcom,sm8250-usb-hs-phy",
"qcom,usb-snps-hs-7nm-phy";
--
2.26.1
^ permalink raw reply related
* Re: [V8, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
From: Sakari Ailus @ 2020-05-24 20:33 UTC (permalink / raw)
To: Tomasz Figa
Cc: Dongchun Zhu, Rob Herring, Linus Walleij, Bartosz Golaszewski,
Mauro Carvalho Chehab, Andy Shevchenko, Mark Rutland,
Nicolas Boichat, Matthias Brugger, Cao Bing Bu, srv_heupstream,
moderated list:ARM/Mediatek SoC support,
list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>, Joerg Roedel <joro@8bytes.org>,,
Sj Huang, Linux Media Mailing List, linux-devicetree, Louis Kuo,
Shengnan Wang (王圣男)
In-Reply-To: <CAAFQd5DgrDwPEpdN9ErJWsHbMDpo2s_u3pwsqtpNwVk4g3_CdQ@mail.gmail.com>
On Thu, May 21, 2020 at 08:59:56PM +0200, Tomasz Figa wrote:
> Hi Dongchun, Rob,
>
> On Tue, May 12, 2020 at 4:41 AM Dongchun Zhu <dongchun.zhu@mediatek.com> wrote:
> >
> > Hi Rob,
> >
> > Thanks for the review.
> >
> > On Mon, 2020-05-11 at 11:02 -0500, Rob Herring wrote:
> > > On Sat, May 09, 2020 at 04:06:26PM +0800, Dongchun Zhu wrote:
> [snip]
> > > > + port {
> > > > + wcam_out: endpoint {
> > > > + remote-endpoint = <&mipi_in_wcam>;
> > > > + data-lanes = <1>;
> > >
> > > This doesn't match the schema which says this should be 4 entries.
> > >
> >
> > Property "data-lanes" shows the number of lanes that sensor supports.
> > If this property is omitted, four-lane operation is assumed.
> > For OV02A10, it is one-lane operation, so the property is supposed to be
> > set to <1>.
> >
>
> To clarify on this, the ov02a10 sensor supports only 1 lane. It's not
> a driver limitation.
If there's nothing to configure there, then the property should be omitted.
I understood the sensor supported one to four lanes...
--
Sakari Ailus
^ permalink raw reply
* Re: [PATCH 2/3] sdhci: sparx5: Add Sparx5 SoC eMMC driver
From: Adrian Hunter @ 2020-05-24 19:26 UTC (permalink / raw)
To: Lars Povlsen
Cc: Ulf Hansson, SoC Team, Microchip Linux Driver Support, linux-mmc,
devicetree, linux-arm-kernel, linux-kernel, Alexandre Belloni
In-Reply-To: <87wo56q2o3.fsf@soft-dev15.microsemi.net>
On 20/05/20 2:14 pm, Lars Povlsen wrote:
>
> Lars Povlsen writes:
>
>> Adrian Hunter writes:
>>
>>> On 13/05/20 4:31 pm, Lars Povlsen wrote:
>>>> This adds the eMMC driver for the Sparx5 SoC. It is based upon the
>>>> designware IP, but requires some extra initialization and quirks.
>>>>
>>>> Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
>>>> Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
>>>> ---
> {Snip]
>>>> +};
>>>> +
>>>> +static const struct sdhci_pltfm_data sdhci_sparx5_pdata = {
>>>> + .quirks = 0,
>>>> + .quirks2 = SDHCI_QUIRK2_HOST_NO_CMD23 | /* Card quirk */
>>>
>>> If this is a card quirk then it should be in drivers/mmc/core/quirks.h not here.
>>
>
> Adrian, I had a go at changing the controller quirk to a card quirk.
>
> Unfortunately, SDHCI_QUIRK2_HOST_NO_CMD23 does not directly translate to
> MMC_QUIRK_BLK_NO_CMD23, as for 'do_rel_wr' in mmc_blk_rw_rq_prep(), it
> will *still* use MMC_SET_BLOCK_COUNT (cmd23), causing the issue.
>
> We are using a ISSI "IS004G" device, and so I have gone through the
> motions of adding it to quirks.h. The comment before the list of devices
> using MMC_QUIRK_BLK_NO_CMD23 suggest working around a performance issue,
> which is not exactly the issue I'm seeing. I'm seeing combinations of
> CMD_TOUT_ERR, DATA_CRC_ERR and DATA_END_BIT_ERR whenever a cmd23 is
> issued.
>
> I have not been able to test the controller with another eMMC device
> yet, but I expect its not the controller at fault.
>
> So, I'm a little bit in doubt of how to proceed - either keep the quirk
> as a controller quirk - or make a *new* card quirk (with
> SDHCI_QUIRK2_HOST_NO_CMD23 semantics)?
>
> Anybody else have had experience with ISSI eMMC devices?
>
> I have also tried to use DT sdhci-caps-mask, but MMC_CAP_CMD23 is not
> read from the controller just (unconditionally) set in sdhci.c - so that
> doesn't fly either.
>
> Any suggestions?
It is up to you. In the future, you may want to distinguish devices that
have this problem from ones that do not.
If you are not sure it is the ISSI eMMC, and maybe not the host controller,
then might it be the board? Perhaps make SDHCI_QUIRK2_HOST_NO_CMD23
conditional on the particular compatibility string?
At a minimum, change the "/* Card quirk */" comment to a fuller explanation.
>
>> Yes, its supposedly a card quirk. I'll see to use the card quirks
>> methods in place.
>>
>
^ 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