Re: [PATCH v15 3/4] dts: zynqmp: add properties for TCM in remoteproc
On 4/12/24 20:37, Tanmay Shah wrote:
Add properties as per new bindings in zynqmp remoteproc node
to represent TCM address and size.
This patch also adds alternative remoteproc node to represent
remoteproc cluster in split mode. By default lockstep mode is
enabled and users should disable it before using split mode
dts. Both device-tree nodes can't be used simultaneously one
of them must be disabled. For zcu102-1.0 and zcu102-1.1 board
remoteproc split mode dts node is enabled and lockstep mode
dts is disabled.
Signed-off-by: Tanmay Shah
---
.../boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts | 8 +++
arch/arm64/boot/dts/xilinx/zynqmp.dtsi| 67 +--
2 files changed, 70 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts
b/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts
index c8f71a1aec89..495ca94b45db 100644
--- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts
+++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts
@@ -14,6 +14,14 @@ / {
compatible = "xlnx,zynqmp-zcu102-rev1.0", "xlnx,zynqmp-zcu102",
"xlnx,zynqmp";
};
+_split {
+ status = "okay";
+};
+
+_lockstep {
+ status = "disabled";
+};
+
{
#address-cells = <1>;
#size-cells = <1>;
diff --git a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
index 25d20d803230..ef31b0fc73d1 100644
--- a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
+++ b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
@@ -260,19 +260,76 @@ fpga_full: fpga-full {
ranges;
};
- remoteproc {
+ rproc_lockstep: remoteproc@ffe0 {
compatible = "xlnx,zynqmp-r5fss";
xlnx,cluster-mode = <1>;
+ xlnx,tcm-mode = <1>;
- r5f-0 {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ ranges = <0x0 0x0 0x0 0xffe0 0x0 0x1>,
+<0x0 0x2 0x0 0xffe2 0x0 0x1>,
+<0x0 0x1 0x0 0xffe1 0x0 0x1>,
+<0x0 0x3 0x0 0xffe3 0x0 0x1>;
+
+ r5f@0 {
+ compatible = "xlnx,zynqmp-r5f";
+ reg = <0x0 0x0 0x0 0x1>,
+ <0x0 0x2 0x0 0x1>,
+ <0x0 0x1 0x0 0x1>,
+ <0x0 0x3 0x0 0x1>;
+ reg-names = "atcm0", "btcm0", "atcm1", "btcm1";
+ power-domains = <_firmware PD_RPU_0>,
+ <_firmware PD_R5_0_ATCM>,
+ <_firmware PD_R5_0_BTCM>,
+ <_firmware PD_R5_1_ATCM>,
+ <_firmware PD_R5_1_BTCM>;
+ memory-region = <_0_fw_image>;
+ };
+
+ r5f@1 {
+ compatible = "xlnx,zynqmp-r5f";
+ reg = <0x1 0x0 0x0 0x1>, <0x1 0x2 0x0 0x1>;
+ reg-names = "atcm0", "btcm0";
+ power-domains = <_firmware PD_RPU_1>,
+ <_firmware PD_R5_1_ATCM>,
+ <_firmware PD_R5_1_BTCM>;
+ memory-region = <_1_fw_image>;
+ };
+ };
+
+ rproc_split: remoteproc-split@ffe0 {
+ status = "disabled";
+ compatible = "xlnx,zynqmp-r5fss";
+ xlnx,cluster-mode = <0>;
+ xlnx,tcm-mode = <0>;
+
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ ranges = <0x0 0x0 0x0 0xffe0 0x0 0x1>,
+<0x0 0x2 0x0 0xffe2 0x0 0x1>,
+<0x1 0x0 0x0 0xffe9 0x0 0x1>,
+<0x1 0x2 0x0 0xffeb 0x0 0x1>;
+
+ r5f@0 {
compatible = "xlnx,zynqmp-r5f";
- power-domains = <_firmware PD_RPU_0>;
+ reg = <0x0 0x0 0x0 0x1>, <0x0 0x2 0x0 0x1>;
+ reg-names = "atcm0", "btcm0";
+ power-domains = <_firmware PD_RPU_0>,
+ <_firmware PD_R5_0_ATCM>,
+ <_firmware PD_R5_0_BTCM>;
memory-region = <_0_fw_image>;
};
- r5f-1 {
+ r5f@1 {
compatible = "xlnx,zynqmp-r5f";
- power-domains = <_firmware PD_RPU_1>;
+ reg = <0x1 0x0 0x0 0x1>, <0x1 0x2 0x0 0x1>;
+ reg-names = "atcm0", "btcm0";
+ power-domains = <_firmware PD_RPU_1>,
+ <_firmware PD_R5_1_ATCM>,
+ <_firmware PD_R5_1_BTCM>;
Re: [PATCH v9 2/3] dts: zynqmp: add properties for TCM in remoteproc
On 1/10/24 22:35, Tanmay Shah wrote:
Add properties as per new bindings in zynqmp remoteproc node
to represent TCM address and size.
This patch also adds alternative remoteproc node to represent
remoteproc cluster in split mode. By default lockstep mode is
enabled and users should disable it before using split mode
dts. Both device-tree nodes can't be used simultaneously one
of them must be disabled. For zcu102-1.0 and zcu102-1.1 board
remoteproc split mode dts node is enabled and lockstep mode
dts is disabled.
Signed-off-by: Tanmay Shah
---
Changes in v9:
- fix rproc lockstep dts
.../boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts | 8 +++
arch/arm64/boot/dts/xilinx/zynqmp.dtsi| 58 +--
2 files changed, 61 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts
b/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts
index c8f71a1aec89..495ca94b45db 100644
--- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts
+++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts
@@ -14,6 +14,14 @@ / {
compatible = "xlnx,zynqmp-zcu102-rev1.0", "xlnx,zynqmp-zcu102",
"xlnx,zynqmp";
};
+_split {
+ status = "okay";
+};
+
+_lockstep {
+ status = "disabled";
+};
+
{
#address-cells = <1>;
#size-cells = <1>;
diff --git a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
index b61fc99cd911..cfdd1f68501f 100644
--- a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
+++ b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
@@ -247,19 +247,67 @@ fpga_full: fpga-full {
ranges;
};
- remoteproc {
+ rproc_lockstep: remoteproc@ffe0 {
compatible = "xlnx,zynqmp-r5fss";
xlnx,cluster-mode = <1>;
- r5f-0 {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ ranges = <0x0 0x0 0x0 0xffe0 0x0 0x2>,
+<0x0 0x2 0x0 0xffe2 0x0 0x2>;
+
+ r5f@0 {
+ compatible = "xlnx,zynqmp-r5f";
+ reg = <0x0 0x0 0x0 0x2>, <0x0 0x2 0x0 0x2>;
+ reg-names = "atcm", "btcm";
+ power-domains = <_firmware PD_RPU_0>,
+ <_firmware PD_R5_0_ATCM>,
+ <_firmware PD_R5_0_BTCM>;
+ memory-region = <_0_fw_image>;
+ };
+
+ r5f@1 {
+ compatible = "xlnx,zynqmp-r5f";
+ reg = <0x1 0x0 0x0 0x1>, <0x1 0x2 0x0 0x1>;
+ reg-names = "atcm", "btcm";
+ power-domains = <_firmware PD_RPU_1>,
+ <_firmware PD_R5_1_ATCM>,
+ <_firmware PD_R5_1_BTCM>;
+ memory-region = <_1_fw_image>;
+ };
+ };
+
+ rproc_split: remoteproc-split@ffe0 {
+ status = "disabled";
+ compatible = "xlnx,zynqmp-r5fss";
+ xlnx,cluster-mode = <0>;
+
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ ranges = <0x0 0x0 0x0 0xffe0 0x0 0x1>,
+<0x0 0x2 0x0 0xffe2 0x0 0x1>,
+<0x1 0x0 0x0 0xffe9 0x0 0x1>,
+<0x1 0x2 0x0 0xffeb 0x0 0x1>;
+
+ r5f@0 {
compatible = "xlnx,zynqmp-r5f";
- power-domains = <_firmware PD_RPU_0>;
+ reg = <0x0 0x0 0x0 0x1>, <0x0 0x2 0x0 0x1>;
+ reg-names = "atcm", "btcm";
+ power-domains = <_firmware PD_RPU_0>,
+ <_firmware PD_R5_0_ATCM>,
+ <_firmware PD_R5_0_BTCM>;
memory-region = <_0_fw_image>;
};
- r5f-1 {
+ r5f@1 {
compatible = "xlnx,zynqmp-r5f";
- power-domains = <_firmware PD_RPU_1>;
+ reg = <0x1 0x0 0x0 0x10000>, <0x1 0x2 0x0 0x1>;
+ reg-names = "atcm", "btcm";
+ power-domains = <_firmware PD_RPU_1>,
+ <_firmware PD_R5_1_ATCM>,
+ <_firmware PD_R5_1_BTCM>;
memory-region = <_1_fw_image>;
};
};
Acked-by: Michal Simek
Thanks,
Michal
Re: [PATCH v8 2/3] dts: zynqmp: add properties for TCM in remoteproc
On 12/16/23 00:57, Tanmay Shah wrote:
Add properties as per new bindings in zynqmp remoteproc node
to represent TCM address and size.
This patch also adds alternative remoteproc node to represent
remoteproc cluster in split mode. By default lockstep mode is
enabled and users should disable it before using split mode
dts. Both device-tree nodes can't be used simultaneously one
of them must be disabled. For zcu102-1.0 and zcu102-1.1 board
remoteproc split mode dts node is enabled and lockstep mode
dts is disabled.
Signed-off-by: Tanmay Shah
---
.../boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts | 8 +++
arch/arm64/boot/dts/xilinx/zynqmp.dtsi| 60 +--
2 files changed, 63 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts
b/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts
index c8f71a1aec89..495ca94b45db 100644
--- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts
+++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts
@@ -14,6 +14,14 @@ / {
compatible = "xlnx,zynqmp-zcu102-rev1.0", "xlnx,zynqmp-zcu102",
"xlnx,zynqmp";
};
+_split {
+ status = "okay";
+};
+
+_lockstep {
+ status = "disabled";
+};
+
{
#address-cells = <1>;
#size-cells = <1>;
diff --git a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
index b61fc99cd911..602e6aba7ac5 100644
--- a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
+++ b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
@@ -247,19 +247,69 @@ fpga_full: fpga-full {
ranges;
};
- remoteproc {
+ rproc_lockstep: remoteproc@ffe0 {
compatible = "xlnx,zynqmp-r5fss";
xlnx,cluster-mode = <1>;
- r5f-0 {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ ranges = <0x0 0x0 0x0 0xffe0 0x0 0x2>,
+<0x0 0x2 0x0 0xffe2 0x0 0x2>,
+<0x1 0x0 0x0 0xffe9 0x0 0x1>,
+<0x1 0x2 0x0 0xffeb 0x0 0x1>;
+
+ r5f@0 {
+ compatible = "xlnx,zynqmp-r5f";
+ reg = <0x0 0x0 0x0 0x2>, <0x0 0x2 0x0 0x2>;
+ reg-names = "atcm", "btcm";
+ power-domains = <_firmware PD_RPU_0>,
+ <_firmware PD_R5_0_ATCM>,
+ <_firmware PD_R5_0_BTCM>;
+ memory-region = <_0_fw_image>;
+ };
+
+ r5f@1 {
+ compatible = "xlnx,zynqmp-r5f";
+ reg = <0x1 0x0 0x0 0x1>, <0x1 0x2 0x0 0x1>;
+ reg-names = "atcm", "btcm";
+ power-domains = <_firmware PD_RPU_1>,
+ <_firmware PD_R5_1_ATCM>,
+ <_firmware PD_R5_1_BTCM>;
+ memory-region = <_1_fw_image>;
+ };
+ };
+
+ rproc_split: remoteproc-split@ffe0 {
+ status = "disabled";
+ compatible = "xlnx,zynqmp-r5fss";
+ xlnx,cluster-mode = <0>;
+
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ ranges = <0x0 0x0 0x0 0xffe0 0x0 0x1>,
+<0x0 0x2 0x0 0xffe2 0x0 0x1>,
+<0x1 0x0 0x0 0xffe9 0x0 0x1>,
+<0x1 0x2 0x0 0xffeb 0x0 0x1>;
+
+ r5f@0 {
compatible = "xlnx,zynqmp-r5f";
- power-domains = <_firmware PD_RPU_0>;
+ reg = <0x0 0x0 0x0 0x1>, <0x0 0x2 0x0 0x1>;
+ reg-names = "atcm", "btcm";
+ power-domains = <_firmware PD_RPU_0>,
+ <_firmware PD_R5_0_ATCM>,
+ <_firmware PD_R5_0_BTCM>;
memory-region = <_0_fw_image>;
};
- r5f-1 {
+ r5f@1 {
compatible = "xlnx,zynqmp-r5f";
- power-domains = <_firmware PD_RPU_1>;
+ reg = <0x1 0x0 0x0 0x1>, <0x1 0x2 0x0 0x1>;
+ reg-names = "atcm", "btcm";
+ power-domains = <_firmware PD_RPU_1>,
+ <_firmware PD_R5_1_ATCM>,
+ <_firmware PD_R5_1_BTCM>;
memory-region = <_1_fw_image>;
};
};
Acked-by: Michal Simek
Let me know if you want me to take this via my tree.
Thanks,
Michal
Re: [PATCH v2] irqchip/xilinx: Expose Kconfig option for Zynq/ZynqMP
On 4/19/21 9:42 PM, Robert Hancock wrote: > Previously the XILINX_INTC config option was hidden and only > auto-selected on the MicroBlaze platform. However, this IP can also be > used on the Zynq and ZynqMP platforms as a secondary cascaded > controller. Allow this option to be user-enabled on those platforms. > > Signed-off-by: Robert Hancock > --- > drivers/irqchip/Kconfig | 7 ++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig > index 15536e321df5..1020cc5a7800 100644 > --- a/drivers/irqchip/Kconfig > +++ b/drivers/irqchip/Kconfig > @@ -279,8 +279,13 @@ config XTENSA_MX > select GENERIC_IRQ_EFFECTIVE_AFF_MASK > > config XILINX_INTC > - bool > + bool "Xilinx Interrupt Controller IP" > + depends on MICROBLAZE || ARCH_ZYNQ || ARCH_ZYNQMP || COMPILE_TEST > select IRQ_DOMAIN > + help > + Support for the Xilinx Interrupt Controller IP core. > + This is used as a primary controller with MicroBlaze and can also > + be used as a secondary chained controller on other platforms. > > config IRQ_CROSSBAR > bool > Acked-by: Michal Simek Thanks, Michal
Re: [PATCH 1/3] arm64: dts: xilinx: Add the clock nodes for zynqmp
On 4/19/21 1:48 PM, Jan Kiszka wrote:
> On 19.04.21 12:52, Michal Simek wrote:
>> Hi Jan,
>>
>> On 4/18/21 2:12 PM, Jan Kiszka wrote:
>>> On 01.04.21 16:52, Jan Kiszka wrote:
>>>> On 01.04.21 13:42, Michal Simek wrote:
>>>>> Hi Jan,
>>>>>
>>>>> On 3/27/21 8:55 PM, Jan Kiszka wrote:
>>>>>> On 07.11.19 10:44, Rajan Vaja wrote:
>>>>>>> Add clock nodes for zynqmp based on CCF.
>>>>>>>
>>>>>>> Signed-off-by: Rajan Vaja
>>>>>>> ---
>>>>>>> arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi | 222
>>>>>>> +
>>>>>>> arch/arm64/boot/dts/xilinx/zynqmp-zc1232-revA.dts | 4 +-
>>>>>>> arch/arm64/boot/dts/xilinx/zynqmp-zc1254-revA.dts | 4 +-
>>>>>>> arch/arm64/boot/dts/xilinx/zynqmp-zc1275-revA.dts | 2 +-
>>>>>>> .../boot/dts/xilinx/zynqmp-zc1751-xm015-dc1.dts| 4 +-
>>>>>>> .../boot/dts/xilinx/zynqmp-zc1751-xm016-dc2.dts| 4 +-
>>>>>>> .../boot/dts/xilinx/zynqmp-zc1751-xm017-dc3.dts| 4 +-
>>>>>>> .../boot/dts/xilinx/zynqmp-zc1751-xm018-dc4.dts| 4 +-
>>>>>>> .../boot/dts/xilinx/zynqmp-zc1751-xm019-dc5.dts| 4 +-
>>>>>>> arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts | 4 +-
>>>>>>> arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts | 4 +-
>>>>>>> arch/arm64/boot/dts/xilinx/zynqmp-zcu104-revA.dts | 4 +-
>>>>>>> arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts | 4 +-
>>>>>>> arch/arm64/boot/dts/xilinx/zynqmp-zcu111-revA.dts | 4 +-
>>>>>>> arch/arm64/boot/dts/xilinx/zynqmp.dtsi | 24 ++-
>>>>>>> 15 files changed, 270 insertions(+), 26 deletions(-)
>>>>>>> create mode 100644 arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
>>>>>>>
>>>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
>>>>>>> b/arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
>>>>>>> new file mode 100644
>>>>>>> index 000..9868ca1
>>>>>>> --- /dev/null
>>>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
>>>>>>> @@ -0,0 +1,222 @@
>>>>>>> +// SPDX-License-Identifier: GPL-2.0+
>>>>>>> +/*
>>>>>>> + * Clock specification for Xilinx ZynqMP
>>>>>>> + *
>>>>>>> + * (C) Copyright 2017 - 2019, Xilinx, Inc.
>>>>>>> + *
>>>>>>> + * Michal Simek
>>>>>>> + */
>>>>>>> +
>>>>>>> +#include
>>>>>>> +/ {
>>>>>>> + pss_ref_clk: pss_ref_clk {
>>>>>>> + u-boot,dm-pre-reloc;
>>>>>>> + compatible = "fixed-clock";
>>>>>>> + #clock-cells = <0>;
>>>>>>> + clock-frequency = <>;
>>>>>>> + };
>>>>>>> +
>>>>>>> + video_clk: video_clk {
>>>>>>> + u-boot,dm-pre-reloc;
>>>>>>> + compatible = "fixed-clock";
>>>>>>> + #clock-cells = <0>;
>>>>>>> + clock-frequency = <2700>;
>>>>>>> + };
>>>>>>> +
>>>>>>> + pss_alt_ref_clk: pss_alt_ref_clk {
>>>>>>> + u-boot,dm-pre-reloc;
>>>>>>> + compatible = "fixed-clock";
>>>>>>> + #clock-cells = <0>;
>>>>>>> + clock-frequency = <0>;
>>>>>>> + };
>>>>>>> +
>>>>>>> + gt_crx_ref_clk: gt_crx_ref_clk {
>>>>>>> + u-boot,dm-pre-reloc;
>>>>>>> + compatible = "fixed-clock";
>>>>>>> + #clock-cells = <0>;
>>>>>>> + clock-frequency = <10800>;
>>>>>>> + };
>>>>>>> +
>>>>>>> + aux_ref_clk: aux_ref_cl
Re: [PATCH] irqchip/xilinx: Expose Kconfig option
Hi Marc and Robert, +Anirudha On 4/16/21 8:14 PM, Robert Hancock wrote: > On Fri, 2021-04-16 at 18:53 +0100, Marc Zyngier wrote: >> On Fri, 16 Apr 2021 17:05:49 +0100, >> Robert Hancock wrote: >>> On Fri, 2021-04-16 at 14:41 +0100, Marc Zyngier wrote: On Fri, 16 Apr 2021 00:32:50 +0100, Robert Hancock wrote: > Previously the XILINX_INTC config option was hidden and only > auto-selected on the MicroBlaze platform. However, this IP can also be > used on other platforms. Allow this option to be user-enabled. > > Signed-off-by: Robert Hancock I don't think this is a good idea. In general, people have no idea which interrupt controller they need to select. So you either end-up with a missing interrupt controller, or a bunch you really don't need. This is essentially a platform constraint, and this should directly be selected by the platform if you have this IP in your system. Thanks, M. >>> >>> The problem is essentially that at the platform level, we don't know, other >>> than in the MicroBlaze case where we know it will be used as the platform's >>> primary interrupt controller. In our case, we are using this IP core on the >>> ZynqMP platform as a secondary cascaded interrupt controller in the FPGA >>> portion of the device. >>> But many ZynqMP configurations wouldn't have this device present, it >>> depends on what the user instantiates in the programmable logic. >>> Also, this core could just as easily be instantiated in standalone >>> Xilinx FPGAs which could be connected to many different platforms >>> over a PCIe, AXI, etc. bus. >> >> Not compiling it for some users is great if you happen to *know* what >> you have to select, which is probably a single digit percentage of the >> people that build their own kernel. At least having it to depend on >> ZYNQMP (or some other FPGA platform) would narrow it down. >> >> And if you have some other HW in your FPGA, you can make the config >> fragment for this HW select the right interrupt controller. But I'm >> definitely not keen on making this a universally user-selectable >> driver. > > In general there is no specific or unique config option for what is > instantiated in an FPGA, it is completely up to the whims of whoever set it > up. > You can instantiate whatever logic cores you want and there is no guarantee > whether they will or won't end up using this interrupt controller in the path > somewhere, so having a dependency there doesn't make much sense. For FPGA > logic > it's ultimately up to the user to ensure the kernel config they are using has > the right drivers enabled for the cores they are using. Kconfig doesn't and > can't really help in this regard. > > There's some precedent on this issue with drivers for various other FPGA-based > IP cores for SPI, I2C, Ethernet etc. Often they started out with an > architecture constraint which limited them to the platform they were > originally > developed with, but which was later removed because the ability to use them in > standalone FPGAs means that the platforms they could potentially be used with > are basically unconstrained. > >> >>> So I don't think having this as a platform constraint makes sense. >> >> I don't think imposing this on *everyone*, across all supported >> architectures and platforms makes any sense. Surely, people who build >> their own HW (because that's what we are talking about here) can be >> bothered to add the small Kconfig fragment that is required to their >> kernel build. > The same interrupt controller was used by ppc405 and ppc440 xilinx platform in past. Unfortunately it was separate copy of this microblaze one and ppc copy should be already removed by removing support for these platforms. The first(default) configuration which was mentioned above is primary interrupt controller for Microblaze. That being said this controller can be used and actually is used by Xilinx Zynq(arm32) ZynqMP(arm64) and Versal(arm64) SOCs as a cascate intc controller. I have also seen couple of different cpus in PL which can use (and actually use it) this soft IP. But limiting it for Zynq/ZynqMP should be fine. Recently my colleague (Anirudha) did some experiments with binding and unbinding this driver for cases where you are using it as cascade interrupt controller in a programmable logic(PL) (primary controller is GIC) and then you want to exchange the whole PL by different configuration that you need to have option to remove this chip. Thanks, Michal
Re: [PATCH 1/3] arm64: dts: xilinx: Add the clock nodes for zynqmp
Hi Jan,
On 4/18/21 2:12 PM, Jan Kiszka wrote:
> On 01.04.21 16:52, Jan Kiszka wrote:
>> On 01.04.21 13:42, Michal Simek wrote:
>>> Hi Jan,
>>>
>>> On 3/27/21 8:55 PM, Jan Kiszka wrote:
>>>> On 07.11.19 10:44, Rajan Vaja wrote:
>>>>> Add clock nodes for zynqmp based on CCF.
>>>>>
>>>>> Signed-off-by: Rajan Vaja
>>>>> ---
>>>>> arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi | 222
>>>>> +
>>>>> arch/arm64/boot/dts/xilinx/zynqmp-zc1232-revA.dts | 4 +-
>>>>> arch/arm64/boot/dts/xilinx/zynqmp-zc1254-revA.dts | 4 +-
>>>>> arch/arm64/boot/dts/xilinx/zynqmp-zc1275-revA.dts | 2 +-
>>>>> .../boot/dts/xilinx/zynqmp-zc1751-xm015-dc1.dts| 4 +-
>>>>> .../boot/dts/xilinx/zynqmp-zc1751-xm016-dc2.dts| 4 +-
>>>>> .../boot/dts/xilinx/zynqmp-zc1751-xm017-dc3.dts| 4 +-
>>>>> .../boot/dts/xilinx/zynqmp-zc1751-xm018-dc4.dts| 4 +-
>>>>> .../boot/dts/xilinx/zynqmp-zc1751-xm019-dc5.dts| 4 +-
>>>>> arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts | 4 +-
>>>>> arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts | 4 +-
>>>>> arch/arm64/boot/dts/xilinx/zynqmp-zcu104-revA.dts | 4 +-
>>>>> arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts | 4 +-
>>>>> arch/arm64/boot/dts/xilinx/zynqmp-zcu111-revA.dts | 4 +-
>>>>> arch/arm64/boot/dts/xilinx/zynqmp.dtsi | 24 ++-
>>>>> 15 files changed, 270 insertions(+), 26 deletions(-)
>>>>> create mode 100644 arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
>>>>>
>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
>>>>> b/arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
>>>>> new file mode 100644
>>>>> index 000..9868ca1
>>>>> --- /dev/null
>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
>>>>> @@ -0,0 +1,222 @@
>>>>> +// SPDX-License-Identifier: GPL-2.0+
>>>>> +/*
>>>>> + * Clock specification for Xilinx ZynqMP
>>>>> + *
>>>>> + * (C) Copyright 2017 - 2019, Xilinx, Inc.
>>>>> + *
>>>>> + * Michal Simek
>>>>> + */
>>>>> +
>>>>> +#include
>>>>> +/ {
>>>>> + pss_ref_clk: pss_ref_clk {
>>>>> + u-boot,dm-pre-reloc;
>>>>> + compatible = "fixed-clock";
>>>>> + #clock-cells = <0>;
>>>>> + clock-frequency = <>;
>>>>> + };
>>>>> +
>>>>> + video_clk: video_clk {
>>>>> + u-boot,dm-pre-reloc;
>>>>> + compatible = "fixed-clock";
>>>>> + #clock-cells = <0>;
>>>>> + clock-frequency = <2700>;
>>>>> + };
>>>>> +
>>>>> + pss_alt_ref_clk: pss_alt_ref_clk {
>>>>> + u-boot,dm-pre-reloc;
>>>>> + compatible = "fixed-clock";
>>>>> + #clock-cells = <0>;
>>>>> + clock-frequency = <0>;
>>>>> + };
>>>>> +
>>>>> + gt_crx_ref_clk: gt_crx_ref_clk {
>>>>> + u-boot,dm-pre-reloc;
>>>>> + compatible = "fixed-clock";
>>>>> + #clock-cells = <0>;
>>>>> + clock-frequency = <10800>;
>>>>> + };
>>>>> +
>>>>> + aux_ref_clk: aux_ref_clk {
>>>>> + u-boot,dm-pre-reloc;
>>>>> + compatible = "fixed-clock";
>>>>> + #clock-cells = <0>;
>>>>> + clock-frequency = <2700>;
>>>>> + };
>>>>> +};
>>>>> +
>>>>> + {
>>>>> + clocks = <_clk CAN0_REF>, <_clk LPD_LSBUS>;
>>>>> +};
>>>>> +
>>>>> + {
>>>>> + clocks = <_clk CAN1_REF>, <_clk LPD_LSBUS>;
>>>>> +};
>>>>> +
>>>>> + {
>>>>> + clocks = <_clk ACPU>;
>>>>> +};
>>>>> +
>>>>> +_dma_chan1 {
>>>>> + clocks = <_clk GDMA_REF>, <_clk LPD_LSBUS>;
>>>&
Re: [PATCH v4 2/2] usb: dwc3: Add driver for Xilinx platforms
Hi Guenter, On 4/11/21 4:02 PM, Guenter Roeck wrote: > Michal, > > On 4/7/21 11:08 PM, Michal Simek wrote: > ... >> It looks like that you directly created the patch. Isn't it better to >> send it yourself? Or do you want Manish to create it based on guidance >> above? >> > -next is substantially broken all over the place. I already spend way too much > time bisecting and analyzing the failures, and making sure that the problems > are not caused by qemu (which is why I tracked down this problem in such > detail). > I don't really have time to write patches and guide them through the process, > sorry. I definitely appreciate your help on this. Manish has sent a patch for it already. http://lore.kernel.org/r/1617904448-74611-3-git-send-email-manish.nar...@xilinx.com Not sure why he hasn't added you to CC but at least Reported-by: tag with your name should be added. Thanks, Michal
Re: [PATCH v1 2/5] gpio: xilinx: Correct kernel doc for xgpio_probe()
On 4/8/21 4:55 PM, Andy Shevchenko wrote:
> Kernel doc validator complains:
>
> .../gpio-xilinx.c:556: warning: expecting prototype for xgpio_of_probe().
> Prototype was for xgpio_probe() instead
>
> Correct as suggested by changing the name of the function in the doc..
>
> Fixes: 749564ffd52d ("gpio/xilinx: Convert the driver to platform device
> interface")
> Signed-off-by: Andy Shevchenko
> ---
> drivers/gpio/gpio-xilinx.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpio/gpio-xilinx.c b/drivers/gpio/gpio-xilinx.c
> index b411d3156e0b..136557e7dd3c 100644
> --- a/drivers/gpio/gpio-xilinx.c
> +++ b/drivers/gpio/gpio-xilinx.c
> @@ -542,7 +542,7 @@ static void xgpio_irqhandler(struct irq_desc *desc)
> }
>
> /**
> - * xgpio_of_probe - Probe method for the GPIO device.
> + * xgpio_probe - Probe method for the GPIO device.
> * @pdev: pointer to the platform device
> *
> * Return:
>
Reviewed-by: Michal Simek
Thanks,
Michal
Re: [PATCH -next] i2c: cadence: Fix PM reference leak in cdns_i2c_master_xfer()
On 4/8/21 1:23 PM, Pu Lehui wrote: > pm_runtime_get_sync() will increment pm usage counter even it failed. > Forgetting to putting operation will result in reference leak here. > Fix it by replacing it with pm_runtime_resume_and_get() to keep usage > counter balanced. > > Signed-off-by: Pu Lehui > --- > drivers/i2c/busses/i2c-cadence.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/i2c/busses/i2c-cadence.c > b/drivers/i2c/busses/i2c-cadence.c > index e4b7f2a951ad..e8eae8725900 100644 > --- a/drivers/i2c/busses/i2c-cadence.c > +++ b/drivers/i2c/busses/i2c-cadence.c > @@ -789,7 +789,7 @@ static int cdns_i2c_master_xfer(struct i2c_adapter *adap, > struct i2c_msg *msgs, > bool change_role = false; > #endif > > - ret = pm_runtime_get_sync(id->dev); > + ret = pm_runtime_resume_and_get(id->dev); > if (ret < 0) > return ret; > > @@ -911,7 +911,7 @@ static int cdns_reg_slave(struct i2c_client *slave) > if (slave->flags & I2C_CLIENT_TEN) > return -EAFNOSUPPORT; > > - ret = pm_runtime_get_sync(id->dev); > + ret = pm_runtime_resume_and_get(id->dev); > if (ret < 0) > return ret; > > Ravi/Shubhrajyoti: Please take a look at this. Thanks, Michal
Re: [PATCH] spi: spi-zynqmp-gqspi: Fix runtime PM imbalance in zynqmp_qspi_probe
++ On 4/8/21 11:25 AM, Dinghao Liu wrote: > When platform_get_irq() fails, a pairing PM usage counter > increment is needed to keep the counter balanced. It's the > same for the following error paths. > > Signed-off-by: Dinghao Liu > --- > drivers/spi/spi-zynqmp-gqspi.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/spi/spi-zynqmp-gqspi.c b/drivers/spi/spi-zynqmp-gqspi.c > index c8fa6ee18ae7..95963a2de64a 100644 > --- a/drivers/spi/spi-zynqmp-gqspi.c > +++ b/drivers/spi/spi-zynqmp-gqspi.c > @@ -1197,6 +1197,7 @@ static int zynqmp_qspi_probe(struct platform_device > *pdev) > return 0; > > clk_dis_all: > + pm_runtime_get_noresume(>dev); > pm_runtime_set_suspended(>dev); > pm_runtime_disable(>dev); > clk_disable_unprepare(xqspi->refclk); >
Re: [PATCH v4 2/2] usb: dwc3: Add driver for Xilinx platforms
Hi Guenter,
On 4/7/21 11:48 PM, Guenter Roeck wrote:
> On Wed, Mar 17, 2021 at 12:22:29PM +0530, Manish Narani wrote:
>> Add a new driver for supporting Xilinx platforms. This driver is used
>> for some sequence of operations required for Xilinx USB controllers.
>> This driver is also used to choose between PIPE clock coming from SerDes
>> and the Suspend Clock. Before the controller is out of reset, the clock
>> selection should be changed to PIPE clock in order to make the USB
>> controller work. There is a register added in Xilinx USB controller
>> register space for the same.
>>
>> Signed-off-by: Manish Narani
>
> Trying this driver with qemu (v6.0.0-rc2) results in:
>
> [ 15.184242] dwc3-xilinx ff9d.usb: error -ENODEV: failed to assert Reset
> [ 15.185754] Unable to handle kernel paging request at virtual address
> 006b6b6b6b6b6b9b
> [ 15.185994] Mem abort info:
> [ 15.186065] ESR = 0x9604
> [ 15.186317] EC = 0x25: DABT (current EL), IL = 32 bits
> [ 15.186414] SET = 0, FnV = 0
> [ 15.186498] EA = 0, S1PTW = 0
> [ 15.186579] Data abort info:
> [ 15.18] ISV = 0, ISS = 0x0004
> [ 15.186756] CM = 0, WnR = 0
> [ 15.186887] [006b6b6b6b6b6b9b] address between user and kernel address
> ranges
> [ 15.187436] Internal error: Oops: 9604 [#1] PREEMPT SMP
> [ 15.18] Modules linked in:
> [ 15.188060] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
> 5.12.0-rc6-next-20210406-6-g05407f068fc9-dirty #1
> [ 15.188265] Hardware name: Xilinx Versal Virtual development board (DT)
> [ 15.188495] pstate: 8005 (Nzcv daif -PAN -UAO -TCO BTYPE=--)
> [ 15.188614] pc : __clk_put+0x24/0x138
> [ 15.188716] lr : __clk_put+0x24/0x138
> [ 15.188791] sp : 80001326bac0
> [ 15.188853] x29: 80001326bac0 x28: 0644ed00
> [ 15.188982] x27: 0421ecd0 x26: 0421e810
> [ 15.189076] x25: 0644f100 x24:
> [ 15.189170] x23: 8000126a2570 x22: 0005
> [ 15.189271] x21: 0644ed00 x20: 06449970
> [ 15.189367] x19: 6b6b6b6b6b6b6b6b x18: 0010
> [ 15.189456] x17: 0001 x16:
> [ 15.189546] x15: 03af0490 x14: 01b7
> [ 15.189642] x13: 03af0490 x12: ffea
> [ 15.189729] x11: 8000123b6460 x10: 0080
> [ 15.189815] x9 : 676993c6 x8 : 676993c6
> [ 15.189941] x7 : 7d152ab3 x6 : 800012768480
> [ 15.190047] x5 : x4 : 7f97631e
> [ 15.190139] x3 : d5bdf2c2 x2 : 000b
> [ 15.190233] x1 : 03af0040 x0 : 0001
> [ 15.190432] Call trace:
> [ 15.190506] __clk_put+0x24/0x138
> [ 15.190588] clk_put+0x10/0x20
> [ 15.190653] clk_bulk_put+0x3c/0x60
> [ 15.190724] devm_clk_bulk_release+0x1c/0x28
> [ 15.190806] release_nodes+0x1c0/0x2b0
> [ 15.190887] devres_release_all+0x38/0x60
> [ 15.190963] really_probe+0x1e4/0x3a8
> [ 15.191042] driver_probe_device+0x64/0xc8
> ...
>
> because of ...
>
>> +
>> +ret = devm_clk_bulk_get_all(priv_data->dev, _data->clks);
>> +if (ret < 0)
>> +return ret;
>> +
> ...
>> +
>> +err_clk_put:
>> +clk_bulk_disable_unprepare(priv_data->num_clocks, priv_data->clks);
>> +clk_bulk_put_all(priv_data->num_clocks, priv_data->clks);
>
> clk_bulk_put_all() is not necessary because of devm_clk_bulk_get_all(),
> and results in a double free.
>
>> +static int dwc3_xlnx_remove(struct platform_device *pdev)
>> +{
>> +struct dwc3_xlnx*priv_data = platform_get_drvdata(pdev);
>> +struct device *dev = >dev;
>> +
>> +of_platform_depopulate(dev);
>> +
>> +clk_bulk_disable_unprepare(priv_data->num_clocks, priv_data->clks);
>> +clk_bulk_put_all(priv_data->num_clocks, priv_data->clks);
>
> Same here. This will likely crash the driver on unload.
It looks like that you directly created the patch. Isn't it better to
send it yourself? Or do you want Manish to create it based on guidance
above?
Manish: Can you please take a look at this?
Thanks,
Michal
Re: [PATCH V2] ata: ahci: ceva: Updated code by using dev_err_probe()
Hi Jens,
On 3/5/21 10:10 AM, Piyush Mehta wrote:
> Updated code with already prepared dev_err_probe(). It reduces code size
> and simplifies EPROBE_DEFER handling.
>
> Also, unify message format for similar error cases.
>
> Signed-off-by: Piyush Mehta
> Acked-by: Michal Simek
> ---
> This patch is based on ahci-ceva patches:
> https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git/commit/?h=for-next=5542fabd9e07d6c49c07862e73070c325f93d390
>
> Tree:
> https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git/tree/?h=for-next
>
> Changes for V2:
> - Address review comment- remove curly brackets {}.
> ---
> drivers/ata/ahci_ceva.c | 8 +++-
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/ata/ahci_ceva.c b/drivers/ata/ahci_ceva.c
> index b980218..50b56cd 100644
> --- a/drivers/ata/ahci_ceva.c
> +++ b/drivers/ata/ahci_ceva.c
> @@ -206,11 +206,9 @@ static int ceva_ahci_probe(struct platform_device *pdev)
>
> cevapriv->rst = devm_reset_control_get_optional_exclusive(>dev,
> NULL);
> - if (IS_ERR(cevapriv->rst)) {
> - if (PTR_ERR(cevapriv->rst) != -EPROBE_DEFER)
> - dev_err(>dev, "failed to get reset: %ld\n",
> - PTR_ERR(cevapriv->rst));
> - }
> + if (IS_ERR(cevapriv->rst))
> + dev_err_probe(>dev, PTR_ERR(cevapriv->rst),
> + "failed to get reset\n");
>
> hpriv = ahci_platform_get_resources(pdev, 0);
> if (IS_ERR(hpriv))
>
Can you please apply this to your tree?
Thanks,
Michal
Re: [PATCH 1/3] arm64: dts: xilinx: Add the clock nodes for zynqmp
Hi Jan,
On 3/27/21 8:55 PM, Jan Kiszka wrote:
> On 07.11.19 10:44, Rajan Vaja wrote:
>> Add clock nodes for zynqmp based on CCF.
>>
>> Signed-off-by: Rajan Vaja
>> ---
>> arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi | 222
>> +
>> arch/arm64/boot/dts/xilinx/zynqmp-zc1232-revA.dts | 4 +-
>> arch/arm64/boot/dts/xilinx/zynqmp-zc1254-revA.dts | 4 +-
>> arch/arm64/boot/dts/xilinx/zynqmp-zc1275-revA.dts | 2 +-
>> .../boot/dts/xilinx/zynqmp-zc1751-xm015-dc1.dts| 4 +-
>> .../boot/dts/xilinx/zynqmp-zc1751-xm016-dc2.dts| 4 +-
>> .../boot/dts/xilinx/zynqmp-zc1751-xm017-dc3.dts| 4 +-
>> .../boot/dts/xilinx/zynqmp-zc1751-xm018-dc4.dts| 4 +-
>> .../boot/dts/xilinx/zynqmp-zc1751-xm019-dc5.dts| 4 +-
>> arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts | 4 +-
>> arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts | 4 +-
>> arch/arm64/boot/dts/xilinx/zynqmp-zcu104-revA.dts | 4 +-
>> arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts | 4 +-
>> arch/arm64/boot/dts/xilinx/zynqmp-zcu111-revA.dts | 4 +-
>> arch/arm64/boot/dts/xilinx/zynqmp.dtsi | 24 ++-
>> 15 files changed, 270 insertions(+), 26 deletions(-)
>> create mode 100644 arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
>>
>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
>> b/arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
>> new file mode 100644
>> index 000..9868ca1
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
>> @@ -0,0 +1,222 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +/*
>> + * Clock specification for Xilinx ZynqMP
>> + *
>> + * (C) Copyright 2017 - 2019, Xilinx, Inc.
>> + *
>> + * Michal Simek
>> + */
>> +
>> +#include
>> +/ {
>> +pss_ref_clk: pss_ref_clk {
>> +u-boot,dm-pre-reloc;
>> +compatible = "fixed-clock";
>> +#clock-cells = <0>;
>> +clock-frequency = <>;
>> +};
>> +
>> +video_clk: video_clk {
>> +u-boot,dm-pre-reloc;
>> +compatible = "fixed-clock";
>> +#clock-cells = <0>;
>> +clock-frequency = <2700>;
>> +};
>> +
>> +pss_alt_ref_clk: pss_alt_ref_clk {
>> +u-boot,dm-pre-reloc;
>> +compatible = "fixed-clock";
>> +#clock-cells = <0>;
>> +clock-frequency = <0>;
>> +};
>> +
>> +gt_crx_ref_clk: gt_crx_ref_clk {
>> +u-boot,dm-pre-reloc;
>> +compatible = "fixed-clock";
>> +#clock-cells = <0>;
>> +clock-frequency = <10800>;
>> +};
>> +
>> +aux_ref_clk: aux_ref_clk {
>> +u-boot,dm-pre-reloc;
>> +compatible = "fixed-clock";
>> +#clock-cells = <0>;
>> +clock-frequency = <2700>;
>> +};
>> +};
>> +
>> + {
>> +clocks = <_clk CAN0_REF>, <_clk LPD_LSBUS>;
>> +};
>> +
>> + {
>> +clocks = <_clk CAN1_REF>, <_clk LPD_LSBUS>;
>> +};
>> +
>> + {
>> +clocks = <_clk ACPU>;
>> +};
>> +
>> +_dma_chan1 {
>> +clocks = <_clk GDMA_REF>, <_clk LPD_LSBUS>;
>> +};
>> +
>> +_dma_chan2 {
>> +clocks = <_clk GDMA_REF>, <_clk LPD_LSBUS>;
>> +};
>> +
>> +_dma_chan3 {
>> +clocks = <_clk GDMA_REF>, <_clk LPD_LSBUS>;
>> +};
>> +
>> +_dma_chan4 {
>> +clocks = <_clk GDMA_REF>, <_clk LPD_LSBUS>;
>> +};
>> +
>> +_dma_chan5 {
>> +clocks = <_clk GDMA_REF>, <_clk LPD_LSBUS>;
>> +};
>> +
>> +_dma_chan6 {
>> +clocks = <_clk GDMA_REF>, <_clk LPD_LSBUS>;
>> +};
>> +
>> +_dma_chan7 {
>> +clocks = <_clk GDMA_REF>, <_clk LPD_LSBUS>;
>> +};
>> +
>> +_dma_chan8 {
>> +clocks = <_clk GDMA_REF>, <_clk LPD_LSBUS>;
>> +};
>> +
>> +_dma_chan1 {
>> +clocks = <_clk ADMA_REF>, <_clk LPD_LSBUS>;
>> +};
>> +
>> +_dma_chan2 {
>> +clocks = <_clk ADMA_REF>, <_clk LPD_LSBUS>;
>> +};
>> +
>> +_dma_chan3 {
>> +clocks = <_clk ADMA_REF>, <_clk LPD_LSBUS>;
>>
Re: [PATCH net-next v2] net: axienet: Remove redundant dev_err call in axienet_probe()
On 3/29/21 3:45 AM, Huang Guobin wrote:
> From: Guobin Huang
>
> There is a error message within devm_ioremap_resource
> already, so remove the dev_err call to avoid redundant
> error message.
>
> Reported-by: Hulk Robot
> Signed-off-by: Guobin Huang
> ---
> drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> index 5d677db0aee5..f77a794540fc 100644
> --- a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> +++ b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> @@ -1878,7 +1878,6 @@ static int axienet_probe(struct platform_device *pdev)
> ethres = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> lp->regs = devm_ioremap_resource(>dev, ethres);
> if (IS_ERR(lp->regs)) {
> - dev_err(>dev, "could not map Axi Ethernet regs.\n");
> ret = PTR_ERR(lp->regs);
> goto cleanup_clk;
> }
>
I have already reviewed v1 and I can't see any v2 description what has
changed. Why am I getting this v2? Where is my tag?
Thanks,
Michal
Re: [PATCH v4] phy: zynqmp: Handle the clock enable/disable properly
;
> + goto err_clk_put;
> }
> }
>
> return 0;
> +
> +err_clk_put:
> + while (refclk--)
> + clk_disable_unprepare(gtr_dev->clk[refclk]);
> +
> + return ret;
> }
>
> static int xpsgtr_probe(struct platform_device *pdev)
> @@ -912,6 +947,7 @@ static int xpsgtr_probe(struct platform_device *pdev)
> struct xpsgtr_dev *gtr_dev;
> struct phy_provider *provider;
> unsigned int port;
> + unsigned int i;
> int ret;
>
> gtr_dev = devm_kzalloc(>dev, sizeof(*gtr_dev), GFP_KERNEL);
> @@ -951,7 +987,8 @@ static int xpsgtr_probe(struct platform_device *pdev)
> phy = devm_phy_create(>dev, np, _phyops);
> if (IS_ERR(phy)) {
> dev_err(>dev, "failed to create PHY\n");
> - return PTR_ERR(phy);
> + ret = PTR_ERR(phy);
> + goto err_clk_put;
> }
>
> gtr_phy->phy = phy;
> @@ -962,9 +999,16 @@ static int xpsgtr_probe(struct platform_device *pdev)
> provider = devm_of_phy_provider_register(>dev, xpsgtr_xlate);
> if (IS_ERR(provider)) {
> dev_err(>dev, "registering provider failed\n");
> - return PTR_ERR(provider);
> + ret = PTR_ERR(provider);
> + goto err_clk_put;
> }
> return 0;
> +
> +err_clk_put:
> + for (i = 0; i < ARRAY_SIZE(gtr_dev->clk); i++)
> + clk_disable_unprepare(gtr_dev->clk[i]);
> +
> + return ret;
> }
>
> static const struct of_device_id xpsgtr_of_match[] = {
>
Acked-by: Michal Simek
Thanks,
Michal
Re: [PATCH v4 3/3] pinctrl: Add Xilinx ZynqMP pinctrl driver support
On 3/24/21 10:13 AM, Greg Kroah-Hartman wrote: > On Wed, Mar 24, 2021 at 10:02:53AM +0100, Michal Simek wrote: >> >> >> On 3/24/21 9:49 AM, Greg Kroah-Hartman wrote: >>> On Wed, Mar 24, 2021 at 09:29:12AM +0100, Michal Simek wrote: >>>> On 3/23/21 2:42 PM, Greg Kroah-Hartman wrote: >>>>> On Wed, Mar 17, 2021 at 01:55:16PM +0530, Sai Krishna Potthuri wrote: >>>>>> Adding pinctrl driver for Xilinx ZynqMP platform. >>>>>> This driver queries pin information from firmware and registers >>>>>> pin control accordingly. >>>>>> >>>>>> Signed-off-by: Sai Krishna Potthuri >>>>>> >>>>>> --- >>>>>> drivers/pinctrl/Kconfig | 13 + >>>>>> drivers/pinctrl/Makefile |1 + >>>>>> drivers/pinctrl/pinctrl-zynqmp.c | 1030 ++ >>>>>> 3 files changed, 1044 insertions(+) >>>>>> create mode 100644 drivers/pinctrl/pinctrl-zynqmp.c >>>>>> >>>>>> diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig >>>>>> index 815095326e2d..25d3c7208975 100644 >>>>>> --- a/drivers/pinctrl/Kconfig >>>>>> +++ b/drivers/pinctrl/Kconfig >>>>>> @@ -341,6 +341,19 @@ config PINCTRL_ZYNQ >>>>>> help >>>>>>This selects the pinctrl driver for Xilinx Zynq. >>>>>> >>>>>> +config PINCTRL_ZYNQMP >>>>>> +bool "Pinctrl driver for Xilinx ZynqMP" >>>>> >>>>> Please make this work as a module. >>>> >>>> The most of pinctrl drivers are builtin modules now which is not excuse >>>> it is just fact. >>>> $ git grep module_pla drivers/pinctrl/ | wc -l >>>> 40 >>>> $ git grep builtin_pla drivers/pinctrl/ | wc -l >>>> 64 >>> >>> For new ones, we can do better, don't make us have to go back and fix >>> this up later. >> >> As I said not a big deal. If this is the way to go then I these rules >> should be followed which is not what it is happening based on 3 latest >> pinctrl drivers below. > > I do not disagree, but I point out issues when I see them, you got > unlucky :) I feel we were lucky that our driver got your attention and we do it properly from the beginning. :-) Thanks, Michal
Re: [PATCH v4 3/3] pinctrl: Add Xilinx ZynqMP pinctrl driver support
On 3/24/21 9:49 AM, Greg Kroah-Hartman wrote:
> On Wed, Mar 24, 2021 at 09:29:12AM +0100, Michal Simek wrote:
>> On 3/23/21 2:42 PM, Greg Kroah-Hartman wrote:
>>> On Wed, Mar 17, 2021 at 01:55:16PM +0530, Sai Krishna Potthuri wrote:
>>>> Adding pinctrl driver for Xilinx ZynqMP platform.
>>>> This driver queries pin information from firmware and registers
>>>> pin control accordingly.
>>>>
>>>> Signed-off-by: Sai Krishna Potthuri
>>>>
>>>> ---
>>>> drivers/pinctrl/Kconfig | 13 +
>>>> drivers/pinctrl/Makefile |1 +
>>>> drivers/pinctrl/pinctrl-zynqmp.c | 1030 ++
>>>> 3 files changed, 1044 insertions(+)
>>>> create mode 100644 drivers/pinctrl/pinctrl-zynqmp.c
>>>>
>>>> diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
>>>> index 815095326e2d..25d3c7208975 100644
>>>> --- a/drivers/pinctrl/Kconfig
>>>> +++ b/drivers/pinctrl/Kconfig
>>>> @@ -341,6 +341,19 @@ config PINCTRL_ZYNQ
>>>>help
>>>> This selects the pinctrl driver for Xilinx Zynq.
>>>>
>>>> +config PINCTRL_ZYNQMP
>>>> + bool "Pinctrl driver for Xilinx ZynqMP"
>>>
>>> Please make this work as a module.
>>
>> The most of pinctrl drivers are builtin modules now which is not excuse
>> it is just fact.
>> $ git grep module_pla drivers/pinctrl/ | wc -l
>> 40
>> $ git grep builtin_pla drivers/pinctrl/ | wc -l
>> 64
>
> For new ones, we can do better, don't make us have to go back and fix
> this up later.
As I said not a big deal. If this is the way to go then I these rules
should be followed which is not what it is happening based on 3 latest
pinctrl drivers below.
>
>> Also at least last 3 pinctrl drivers which have been merged are not modules.
>> d4c34d09ab03 ("pinctrl: Add RISC-V Canaan Kendryte K210 FPIOA driver")
>> 7e5ea974e61c ("pinctrl: pinctrl-microchip-sgpio: Add pinctrl driver for
>> Microsemi Serial GPIO")
>> a68a7844264e ("pinctrl: visconti: Add Toshiba Visconti SoCs pinctrl
>> support")
>>
>> None is saying that it can't be done but that cases where you use
>> pinctrl as module are really very limited. When you start to use pinctrl
>> and its functionality you need to have it as the part of the kernel to
>> be to get console, mmc, ethernet, usb, etc.
>>
>> That's why I would like to know what functionality and use case you have
>> in mind that this driver should be made module.
>
> The "functionality" of building a kernel image that works on all
> hardware types. Just like x86-64 has been for a very long time :)
ok.
Thanks,
Michal
Re: [PATCH v4 3/3] pinctrl: Add Xilinx ZynqMP pinctrl driver support
On 3/23/21 2:42 PM, Greg Kroah-Hartman wrote:
> On Wed, Mar 17, 2021 at 01:55:16PM +0530, Sai Krishna Potthuri wrote:
>> Adding pinctrl driver for Xilinx ZynqMP platform.
>> This driver queries pin information from firmware and registers
>> pin control accordingly.
>>
>> Signed-off-by: Sai Krishna Potthuri
>> ---
>> drivers/pinctrl/Kconfig | 13 +
>> drivers/pinctrl/Makefile |1 +
>> drivers/pinctrl/pinctrl-zynqmp.c | 1030 ++
>> 3 files changed, 1044 insertions(+)
>> create mode 100644 drivers/pinctrl/pinctrl-zynqmp.c
>>
>> diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
>> index 815095326e2d..25d3c7208975 100644
>> --- a/drivers/pinctrl/Kconfig
>> +++ b/drivers/pinctrl/Kconfig
>> @@ -341,6 +341,19 @@ config PINCTRL_ZYNQ
>> help
>>This selects the pinctrl driver for Xilinx Zynq.
>>
>> +config PINCTRL_ZYNQMP
>> +bool "Pinctrl driver for Xilinx ZynqMP"
>
> Please make this work as a module.
The most of pinctrl drivers are builtin modules now which is not excuse
it is just fact.
$ git grep module_pla drivers/pinctrl/ | wc -l
40
$ git grep builtin_pla drivers/pinctrl/ | wc -l
64
Also at least last 3 pinctrl drivers which have been merged are not modules.
d4c34d09ab03 ("pinctrl: Add RISC-V Canaan Kendryte K210 FPIOA driver")
7e5ea974e61c ("pinctrl: pinctrl-microchip-sgpio: Add pinctrl driver for
Microsemi Serial GPIO")
a68a7844264e ("pinctrl: visconti: Add Toshiba Visconti SoCs pinctrl
support")
None is saying that it can't be done but that cases where you use
pinctrl as module are really very limited. When you start to use pinctrl
and its functionality you need to have it as the part of the kernel to
be to get console, mmc, ethernet, usb, etc.
That's why I would like to know what functionality and use case you have
in mind that this driver should be made module.
Thanks,
Michal
Re: [PATCH v3] phy: zynqmp: Handle the clock enable/disable properly
On 3/23/21 3:19 PM, Manish Narani wrote:
> The current driver is not handling the clock enable/disable operations
> properly. The clocks need to be handled correctly by enabling or
> disabling at appropriate places. This patch adds code to handle the
> same.
>
> Signed-off-by: Manish Narani
> ---
> drivers/phy/xilinx/phy-zynqmp.c | 57
> -
> 1 file changed, 50 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/phy/xilinx/phy-zynqmp.c b/drivers/phy/xilinx/phy-zynqmp.c
> index 2b65f84..69492a5 100644
> --- a/drivers/phy/xilinx/phy-zynqmp.c
> +++ b/drivers/phy/xilinx/phy-zynqmp.c
> @@ -219,6 +219,7 @@ struct xpsgtr_dev {
> struct mutex gtr_mutex; /* mutex for locking */
> struct xpsgtr_phy phys[NUM_LANES];
> const struct xpsgtr_ssc *refclk_sscs[NUM_LANES];
> + struct clk *clk[NUM_LANES];
Please also document this property.
./scripts/kernel-doc -man -v drivers/phy/xilinx/phy-zynqmp.c >/dev/null
drivers/phy/xilinx/phy-zynqmp.c:170: info: Scanning doc for struct
xpsgtr_ssc
drivers/phy/xilinx/phy-zynqmp.c:184: info: Scanning doc for struct
xpsgtr_phy
drivers/phy/xilinx/phy-zynqmp.c:204: info: Scanning doc for struct
xpsgtr_dev
drivers/phy/xilinx/phy-zynqmp.c:226: warning: Function parameter or
member 'clk' not described in 'xpsgtr_dev'
1 warnings
Thanks,
Michal
Re: [PATCH] xsysace: Remove SYSACE driver
On 3/23/21 5:28 PM, Jens Axboe wrote: > On 3/23/21 10:25 AM, Michal Simek wrote: >> >> >> On 3/23/21 5:23 PM, Jens Axboe wrote: >>> On 3/22/21 6:04 PM, Davidlohr Bueso wrote: >>>> Hi, >>>> >>>> On Mon, 09 Nov 2020, Michal Simek wrote: >>>> >>>>> Sysace IP is no longer used on Xilinx PowerPC 405/440 and Microblaze >>>>> systems. The driver is not regularly tested and very likely not working >>>>> for >>>>> quite a long time that's why remove it. >>>> >>>> Is there a reason this patch was never merged? can the driver be >>>> removed? I ran into this as a potential tasklet user that can be >>>> replaced/removed. >>> >>> I'd be happy to merge it for 5.13. >>> >> >> Can you just take this version? Or do you want me to send it again? > > Minor edits needed for fuzz, but I've applied this version. Thanks, Michal
Re: [PATCH] xsysace: Remove SYSACE driver
On 3/23/21 5:23 PM, Jens Axboe wrote: > On 3/22/21 6:04 PM, Davidlohr Bueso wrote: >> Hi, >> >> On Mon, 09 Nov 2020, Michal Simek wrote: >> >>> Sysace IP is no longer used on Xilinx PowerPC 405/440 and Microblaze >>> systems. The driver is not regularly tested and very likely not working for >>> quite a long time that's why remove it. >> >> Is there a reason this patch was never merged? can the driver be >> removed? I ran into this as a potential tasklet user that can be >> replaced/removed. > > I'd be happy to merge it for 5.13. > Can you just take this version? Or do you want me to send it again? Thanks, Michal
Re: [PATCH 03/13] PCI: xilinx: Convert to MSI domains
On 3/22/21 1:23 PM, Lorenzo Pieralisi wrote: > On Thu, Feb 25, 2021 at 03:10:13PM +, Marc Zyngier wrote: >> In anticipation of the removal of the msi_controller structure, convert >> the ancient xilinx host controller driver to MSI domains. >> >> We end-up with the usual two domain structure, the top one being a >> generic PCI/MSI domain, the bottom one being xilinx-specific and handling >> the actual HW interrupt allocation. >> >> This allows us to fix some of the most appaling MSI programming, where >> the message programmed in the device is the virtual IRQ number instead >> of the allocated vector number. The allocator is also made safe with >> a mutex. This should allow support for MultiMSI, but I decided not to >> even try, since I cannot test it. >> >> Also take the opportunity to get rid of the cargo-culted memory allocation >> for the MSI capture address. *ANY* sufficiently aligned address should >> be good enough, so use the physical address of the xilinx_pcie_host >> structure instead. > > I'd agree with Bjorn that the MSI doorbell change is better split into > a separate patch, I can do it myself at merge if you agree. Thank you for doing it. Thanks, Michal
Re: [PATCH 03/13] PCI: xilinx: Convert to MSI domains
Hi, On 3/22/21 1:21 PM, Lorenzo Pieralisi wrote: > On Thu, Feb 25, 2021 at 03:10:13PM +, Marc Zyngier wrote: >> In anticipation of the removal of the msi_controller structure, convert >> the ancient xilinx host controller driver to MSI domains. >> >> We end-up with the usual two domain structure, the top one being a >> generic PCI/MSI domain, the bottom one being xilinx-specific and handling >> the actual HW interrupt allocation. >> >> This allows us to fix some of the most appaling MSI programming, where >> the message programmed in the device is the virtual IRQ number instead >> of the allocated vector number. The allocator is also made safe with >> a mutex. This should allow support for MultiMSI, but I decided not to >> even try, since I cannot test it. >> >> Also take the opportunity to get rid of the cargo-culted memory allocation >> for the MSI capture address. *ANY* sufficiently aligned address should >> be good enough, so use the physical address of the xilinx_pcie_host >> structure instead. >> >> Signed-off-by: Marc Zyngier >> --- >> drivers/pci/controller/Kconfig | 2 +- >> drivers/pci/controller/pcie-xilinx.c | 238 +++ >> 2 files changed, 96 insertions(+), 144 deletions(-) > > Michal, > > can you please test these changes or make sure someone does and report > back on the mailing list please ? > > I would like to merge this series for v5.13. I got just private response (not sure why) from Bharat March 5 that changes are fine. It means go ahead with it. Thanks, Michal
Re: [PATCH] microblaze: Fix a typo
On 3/19/21 5:53 AM, Bhaskar Chowdhury wrote: > > s/storign/storing/ > > Signed-off-by: Bhaskar Chowdhury > --- > arch/microblaze/lib/uaccess_old.S | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/microblaze/lib/uaccess_old.S > b/arch/microblaze/lib/uaccess_old.S > index 0e8cc2710c27..eca290090038 100644 > --- a/arch/microblaze/lib/uaccess_old.S > +++ b/arch/microblaze/lib/uaccess_old.S > @@ -188,7 +188,7 @@ w2: sw r4, r5, r3 > .text > > .align 4 /* Alignment is important to keep icache happy */ > -page:/* Create room on stack and save registers for storign values */ > +page:/* Create room on stack and save registers for storing values */ > addik r1, r1, -40 > swi r5, r1, 0 > swi r6, r1, 4 > -- > 2.26.2 > Applied. M -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
[PATCH] pinctrl: core: Set ret to 0 when group is skipped
Static analyzer tool found that the ret variable is not initialized but
code expects ret value >=0 when pinconf is skipped in the first pinmux
loop. The same expectation is for pinmux in a pinconf loop.
That's why initialize ret to 0 to avoid uninitialized ret value in first
loop or reusing ret value from first loop in second.
Addresses-Coverity: ("Uninitialized variables")
Signed-off-by: Michal Simek
CC: Colin Ian King
CC: Dan Carpenter
---
drivers/pinctrl/core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index f5c32d2a3c91..136c323d855e 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -1266,6 +1266,7 @@ static int pinctrl_commit_state(struct pinctrl *p, struct
pinctrl_state *state)
break;
case PIN_MAP_TYPE_CONFIGS_PIN:
case PIN_MAP_TYPE_CONFIGS_GROUP:
+ ret = 0;
break;
default:
ret = -EINVAL;
@@ -1284,6 +1285,7 @@ static int pinctrl_commit_state(struct pinctrl *p, struct
pinctrl_state *state)
list_for_each_entry(setting, >settings, node) {
switch (setting->type) {
case PIN_MAP_TYPE_MUX_GROUP:
+ ret = 0;
break;
case PIN_MAP_TYPE_CONFIGS_PIN:
case PIN_MAP_TYPE_CONFIGS_GROUP:
--
2.30.1
Re: pinctrl: core: Handling pinmux and pinconf separately
On 3/11/21 12:24 PM, Colin Ian King wrote:
> On 11/03/2021 11:16, Michal Simek wrote:
>>
>>
>> On 3/11/21 11:57 AM, Colin Ian King wrote:
>>> Hi,
>>>
>>> Static analysis on linux-next with Coverity has found a potential issue
>>> in drivers/pinctrl/core.c with the following commit:
>>>
>>> commit 0952b7ec1614abf232e921aac0cc2bca8e60e162
>>> Author: Michal Simek
>>> Date: Wed Mar 10 09:16:54 2021 +0100
>>>
>>> pinctrl: core: Handling pinmux and pinconf separately
>>>
>>> The analysis is as follows:
>>>
>>> 1234 /**
>>> 1235 * pinctrl_commit_state() - select/activate/program a pinctrl state
>>> to HW
>>> 1236 * @p: the pinctrl handle for the device that requests configuration
>>> 1237 * @state: the state handle to select/activate/program
>>> 1238 */
>>> 1239 static int pinctrl_commit_state(struct pinctrl *p, struct
>>> pinctrl_state *state)
>>> 1240 {
>>> 1241struct pinctrl_setting *setting, *setting2;
>>> 1242struct pinctrl_state *old_state = p->state;
>>>
>>> 1. var_decl: Declaring variable ret without initializer.
>>>
>>> 1243int ret;
>>> 1244
>>>
>>> 2. Condition p->state, taking true branch.
>>>
>>> 1245if (p->state) {
>>> 1246/*
>>> 1247 * For each pinmux setting in the old state, forget
>>> SW's record
>>> 1248 * of mux owner for that pingroup. Any pingroups
>>> which are
>>> 1249 * still owned by the new state will be re-acquired
>>> by the call
>>> 1250 * to pinmux_enable_setting() in the loop below.
>>> 1251 */
>>>
>>> 3. Condition 0 /* !!(!__builtin_types_compatible_p() &&
>>> !__builtin_types_compatible_p()) */, taking false branch.
>>> 4. Condition !(>node == >state->settings), taking true
>>> branch.
>>> 7. Condition 0 /* !!(!__builtin_types_compatible_p() &&
>>> !__builtin_types_compatible_p()) */, taking false branch.
>>> 8. Condition !(>node == >state->settings), taking true
>>> branch.
>>> 11. Condition 0 /* !!(!__builtin_types_compatible_p() &&
>>> !__builtin_types_compatible_p()) */, taking false branch.
>>> 12. Condition !(>node == >state->settings), taking false
>>> branch.
>>>
>>> 1252list_for_each_entry(setting, >state->settings,
>>> node) {
>>>
>>> 5. Condition setting->type != PIN_MAP_TYPE_MUX_GROUP, taking true
>>> branch.
>>> 9. Condition setting->type != PIN_MAP_TYPE_MUX_GROUP, taking true
>>> branch.
>>> 1253if (setting->type != PIN_MAP_TYPE_MUX_GROUP)
>>> 6. Continuing loop.
>>> 10. Continuing loop.
>>>
>>> 1254continue;
>>> 1255pinmux_disable_setting(setting);
>>> 1256}
>>> 1257}
>>> 1258
>>> 1259p->state = NULL;
>>> 1260
>>> 1261/* Apply all the settings for the new state - pinmux first */
>>>
>>> 13. Condition 0 /* !!(!__builtin_types_compatible_p() &&
>>> !__builtin_types_compatible_p()) */, taking false branch.
>>> 14. Condition !(>node == >settings), taking true branch.
>>> 1262list_for_each_entry(setting, >settings, node) {
>>> 15. Switch case value PIN_MAP_TYPE_CONFIGS_PIN.
>>>
>>> 1263switch (setting->type) {
>>> 1264case PIN_MAP_TYPE_MUX_GROUP:
>>> 1265ret = pinmux_enable_setting(setting);
>>> 1266break;
>>> 1267case PIN_MAP_TYPE_CONFIGS_PIN:
>>> 1268case PIN_MAP_TYPE_CONFIGS_GROUP:
>>>
>>> 16. Breaking from switch.
>>>
>>> 1269break;
>>> 1270default:
>>> 1271ret = -EINVAL;
>>> 1272break;
>>> 1273}
>>> 1274
>>>
>>> Uninitialized scalar variable (UNINIT)
>>> 17. uninit_use: Using uninitialized value ret.
>>>
>>> 1275if (ret < 0)
>>> 1276goto unapply_new_state;
>>>
>>> For the PIN_MAP_TYPE_CONFIGS_PIN and PIN_MAP_TYPE_CONFIGS_GROUP
>>> setting->type cases the loop can break out with ret not being set. Since
>>> ret has not been initialized it the ret < 0 check is checking against an
>>> uninitialized value.
>>>
>>> I was not sure if the PIN_MAP_TYPE_CONFIGS_PIN and
>>> PIN_MAP_TYPE_CONFIGS_GROUP cases should be setting ret and if so, what
>>> the value of ret should be set to (is it an error condition or not?). Or
>>> should ret be initialized to 0 or a default error value at the start of
>>> the function.
>>>
>>> Hence I'm reporting this issue.
>>
>> What about this? Is this passing static analysis?
>
> It will take me 2 hours to re-run the analysis, but from eyeballing the
> code I think the assignments will fix this.
would be good if you can rerun it and get back to us on this.
I will wait if something else will pop up and then will send v2 with
this that Linus can apply this one instead.
Thanks,
Michal
Re: pinctrl: core: Handling pinmux and pinconf separately
On 3/11/21 11:57 AM, Colin Ian King wrote:
> Hi,
>
> Static analysis on linux-next with Coverity has found a potential issue
> in drivers/pinctrl/core.c with the following commit:
>
> commit 0952b7ec1614abf232e921aac0cc2bca8e60e162
> Author: Michal Simek
> Date: Wed Mar 10 09:16:54 2021 +0100
>
> pinctrl: core: Handling pinmux and pinconf separately
>
> The analysis is as follows:
>
> 1234 /**
> 1235 * pinctrl_commit_state() - select/activate/program a pinctrl state
> to HW
> 1236 * @p: the pinctrl handle for the device that requests configuration
> 1237 * @state: the state handle to select/activate/program
> 1238 */
> 1239 static int pinctrl_commit_state(struct pinctrl *p, struct
> pinctrl_state *state)
> 1240 {
> 1241struct pinctrl_setting *setting, *setting2;
> 1242struct pinctrl_state *old_state = p->state;
>
> 1. var_decl: Declaring variable ret without initializer.
>
> 1243int ret;
> 1244
>
> 2. Condition p->state, taking true branch.
>
> 1245if (p->state) {
> 1246/*
> 1247 * For each pinmux setting in the old state, forget
> SW's record
> 1248 * of mux owner for that pingroup. Any pingroups
> which are
> 1249 * still owned by the new state will be re-acquired
> by the call
> 1250 * to pinmux_enable_setting() in the loop below.
> 1251 */
>
> 3. Condition 0 /* !!(!__builtin_types_compatible_p() &&
> !__builtin_types_compatible_p()) */, taking false branch.
> 4. Condition !(>node == >state->settings), taking true
> branch.
> 7. Condition 0 /* !!(!__builtin_types_compatible_p() &&
> !__builtin_types_compatible_p()) */, taking false branch.
> 8. Condition !(>node == >state->settings), taking true
> branch.
> 11. Condition 0 /* !!(!__builtin_types_compatible_p() &&
> !__builtin_types_compatible_p()) */, taking false branch.
> 12. Condition !(>node == >state->settings), taking false
> branch.
>
> 1252list_for_each_entry(setting, >state->settings,
> node) {
>
> 5. Condition setting->type != PIN_MAP_TYPE_MUX_GROUP, taking true
> branch.
> 9. Condition setting->type != PIN_MAP_TYPE_MUX_GROUP, taking true
> branch.
> 1253if (setting->type != PIN_MAP_TYPE_MUX_GROUP)
> 6. Continuing loop.
> 10. Continuing loop.
>
> 1254continue;
> 1255pinmux_disable_setting(setting);
> 1256}
> 1257}
> 1258
> 1259p->state = NULL;
> 1260
> 1261/* Apply all the settings for the new state - pinmux first */
>
> 13. Condition 0 /* !!(!__builtin_types_compatible_p() &&
> !__builtin_types_compatible_p()) */, taking false branch.
> 14. Condition !(>node == >settings), taking true branch.
> 1262list_for_each_entry(setting, >settings, node) {
> 15. Switch case value PIN_MAP_TYPE_CONFIGS_PIN.
>
> 1263switch (setting->type) {
> 1264case PIN_MAP_TYPE_MUX_GROUP:
> 1265ret = pinmux_enable_setting(setting);
> 1266break;
> 1267case PIN_MAP_TYPE_CONFIGS_PIN:
> 1268case PIN_MAP_TYPE_CONFIGS_GROUP:
>
> 16. Breaking from switch.
>
> 1269break;
> 1270default:
> 1271ret = -EINVAL;
> 1272break;
> 1273}
> 1274
>
> Uninitialized scalar variable (UNINIT)
> 17. uninit_use: Using uninitialized value ret.
>
> 1275if (ret < 0)
> 1276goto unapply_new_state;
>
> For the PIN_MAP_TYPE_CONFIGS_PIN and PIN_MAP_TYPE_CONFIGS_GROUP
> setting->type cases the loop can break out with ret not being set. Since
> ret has not been initialized it the ret < 0 check is checking against an
> uninitialized value.
>
> I was not sure if the PIN_MAP_TYPE_CONFIGS_PIN and
> PIN_MAP_TYPE_CONFIGS_GROUP cases should be setting ret and if so, what
> the value of ret should be set to (is it an error condition or not?). Or
> should ret be initialized to 0 or a default error value at the start of
> the function.
>
> Hence I'm reporting this issue.
What about this? Is this passing static analysis?
diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index f5c32d2a3c91..136c323d855e 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -1266,6 +1266,7 @@ static int pinctrl_commit_state(st
Re: [PATCH] microblaze: remove unneeded variable 'err'
On 3/10/21 9:50 AM, Yang Li wrote:
> Fix the following coccicheck warning:
> ./arch/microblaze/kernel/signal.c:60:14-17: Unneeded variable: "err".
> Return "0" on line 78
>
> Reported-by: Abaci Robot
> Signed-off-by: Yang Li
> ---
> arch/microblaze/kernel/signal.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/arch/microblaze/kernel/signal.c b/arch/microblaze/kernel/signal.c
> index fc61eb0..c4b7b30 100644
> --- a/arch/microblaze/kernel/signal.c
> +++ b/arch/microblaze/kernel/signal.c
> @@ -57,8 +57,6 @@ struct rt_sigframe {
> static int restore_sigcontext(struct pt_regs *regs,
> struct sigcontext __user *sc, int *rval_p)
> {
> - unsigned int err = 0;
> -
> #define COPY(x) {err |= __get_user(regs->x, >regs.x); }
This is wrong because as you use err is used here.
Thanks,
Michal
> COPY(r0);
> COPY(r1);
> @@ -75,7 +73,7 @@ static int restore_sigcontext(struct pt_regs *regs,
>
> *rval_p = regs->r3;
>
> - return err;
> + return 0;
> }
>
> asmlinkage long sys_rt_sigreturn(struct pt_regs *regs)
>
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
[PATCH] pinctrl: core: Handling pinmux and pinconf separately
Right now the handling order depends on how entries are coming which is
corresponding with order in DT. We have reached the case with DT overlays
where conf and mux descriptions are exchanged which ends up in sequence
that firmware has been asked to perform configuration before requesting the
pin.
The patch is enforcing the order that pin is requested all the time first
followed by pin configuration. This change will ensure that firmware gets
requests in the right order.
Signed-off-by: Michal Simek
---
drivers/pinctrl/core.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index 7d3370289938..f5c32d2a3c91 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -1258,13 +1258,34 @@ static int pinctrl_commit_state(struct pinctrl *p,
struct pinctrl_state *state)
p->state = NULL;
- /* Apply all the settings for the new state */
+ /* Apply all the settings for the new state - pinmux first */
list_for_each_entry(setting, >settings, node) {
switch (setting->type) {
case PIN_MAP_TYPE_MUX_GROUP:
ret = pinmux_enable_setting(setting);
break;
case PIN_MAP_TYPE_CONFIGS_PIN:
+ case PIN_MAP_TYPE_CONFIGS_GROUP:
+ break;
+ default:
+ ret = -EINVAL;
+ break;
+ }
+
+ if (ret < 0)
+ goto unapply_new_state;
+
+ /* Do not link hogs (circular dependency) */
+ if (p != setting->pctldev->p)
+ pinctrl_link_add(setting->pctldev, p->dev);
+ }
+
+ /* Apply all the settings for the new state - pinconf after */
+ list_for_each_entry(setting, >settings, node) {
+ switch (setting->type) {
+ case PIN_MAP_TYPE_MUX_GROUP:
+ break;
+ case PIN_MAP_TYPE_CONFIGS_PIN:
case PIN_MAP_TYPE_CONFIGS_GROUP:
ret = pinconf_apply_setting(setting);
break;
--
2.30.1
Re: [PATCH] arm64: dts: zynqmp: Remove si5328 device nodes
On 3/8/21 12:54 PM, quanyang.w...@windriver.com wrote:
> From: Quanyang Wang
>
> The function of_i2c_get_board_info will call of_modalias_node to check
> if a device_node contains "compatible" string. But for the device si5328
> at zcu102/zcu106 boards, there is no proper DT bindings for them. So remove
> si5328 device nodes from dts files to eliminate the error info in the boot
> message:
>
> i2c i2c-10: of_i2c: modalias failure on
> /axi/i2c@ff03/i2c-mux@74/i2c@4/clock-generator@69
> i2c i2c-10: Failed to create I2C device for
> /axi/i2c@ff03/i2c-mux@74/i2c@4/clock-generator@69
>
> Signed-off-by: Quanyang Wang
> ---
> .../boot/dts/xilinx/zynqmp-zcu102-revA.dts| 20 +--
> .../boot/dts/xilinx/zynqmp-zcu106-revA.dts| 20 +--
> 2 files changed, 2 insertions(+), 38 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts
> b/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts
> index 12e8bd48dc8c..eca6c2de84a7 100644
> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts
> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts
> @@ -580,25 +580,7 @@ i2c@4 {
> #address-cells = <1>;
> #size-cells = <0>;
> reg = <4>;
> - si5328: clock-generator@69 {/* SI5328 - u20 */
> - reg = <0x69>;
> - /*
> - * Chip has interrupt present connected to PL
> - * interrupt-parent = <&>;
> - * interrupts = <>;
> - */
> - #address-cells = <1>;
> - #size-cells = <0>;
> - #clock-cells = <1>;
> - clocks = <>;
> - clock-names = "xtal";
> - clock-output-names = "si5328";
> -
> - si5328_clk: clk0@0 {
> - reg = <0>;
> - clock-frequency = <2700>;
> - };
> - };
> + /* SI5328 - u20 */
> };
> /* 5 - 7 unconnected */
> };
> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts
> b/arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts
> index 18771e868399..eff7c6447087 100644
> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts
> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts
> @@ -581,25 +581,7 @@ i2c@4 {
> #address-cells = <1>;
> #size-cells = <0>;
> reg = <4>;
> - si5328: clock-generator@69 {/* SI5328 - u20 */
> - reg = <0x69>;
> - /*
> - * Chip has interrupt present connected to PL
> - * interrupt-parent = <&>;
> - * interrupts = <>;
> - */
> - #address-cells = <1>;
> - #size-cells = <0>;
> - #clock-cells = <1>;
> - clocks = <>;
> - clock-names = "xtal";
> - clock-output-names = "si5328";
> -
> - si5328_clk: clk0@0 {
> - reg = <0>;
> - clock-frequency = <2700>;
> - };
> - };
> + /* SI5328 - u20 */
> };
> i2c@5 {
> #address-cells = <1>;
>
Applied.
M
Re: [PATCH] arm64: dts: zynqmp: Add compatible strings for si5328
Hi, On 3/8/21 9:35 AM, Laurent Pinchart wrote: > Hi Quanyang, > > Thank you for the patch. > > On Mon, Mar 08, 2021 at 03:08:43PM +0800, quanyang.w...@windriver.com wrote: >> From: Quanyang Wang >> >> The function of_i2c_get_board_info will call of_modalias_node to check >> if a device_node contains "compatible" string. So let's assign the >> proper string "silabs,si5328" to clock-generator@69's compatible >> property to eliminate the error info as below: > > As far as I can tell, "silabs,si5328" isn't documented in > Documentation/devicetree/bindings/. We need DT bindings before making > use of the compatible string. > the second option is to remove/comment this node. Thanks, Michal
Re: [PATCH v3 3/3] gpio: xilinx: Utilize generic bitmap_get_value and _set_value
On 3/6/21 3:06 PM, Syed Nayyar Waris wrote:
> This patch reimplements the xgpio_set_multiple() function in
> drivers/gpio/gpio-xilinx.c to use the new generic functions:
> bitmap_get_value() and bitmap_set_value(). The code is now simpler
> to read and understand. Moreover, instead of looping for each bit
> in xgpio_set_multiple() function, now we can check each channel at
> a time and save cycles.
>
> Cc: Bartosz Golaszewski
> Cc: Michal Simek
> Signed-off-by: Syed Nayyar Waris
> Acked-by: William Breathitt Gray
> ---
> drivers/gpio/gpio-xilinx.c | 63 +++---
> 1 file changed, 32 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpio/gpio-xilinx.c b/drivers/gpio/gpio-xilinx.c
> index be539381fd82..8445e69cf37b 100644
> --- a/drivers/gpio/gpio-xilinx.c
> +++ b/drivers/gpio/gpio-xilinx.c
> @@ -15,6 +15,7 @@
> #include
> #include
> #include
> +#include "gpiolib.h"
>
> /* Register Offset Definitions */
> #define XGPIO_DATA_OFFSET (0x0)/* Data register */
> @@ -141,37 +142,37 @@ static void xgpio_set_multiple(struct gpio_chip *gc,
> unsigned long *mask,
> {
> unsigned long flags;
> struct xgpio_instance *chip = gpiochip_get_data(gc);
> - int index = xgpio_index(chip, 0);
> - int offset, i;
> -
> - spin_lock_irqsave(>gpio_lock[index], flags);
> -
> - /* Write to GPIO signals */
> - for (i = 0; i < gc->ngpio; i++) {
> - if (*mask == 0)
> - break;
> - /* Once finished with an index write it out to the register */
> - if (index != xgpio_index(chip, i)) {
> - xgpio_writereg(chip->regs + XGPIO_DATA_OFFSET +
> -index * XGPIO_CHANNEL_OFFSET,
> -chip->gpio_state[index]);
> - spin_unlock_irqrestore(>gpio_lock[index], flags);
> - index = xgpio_index(chip, i);
> - spin_lock_irqsave(>gpio_lock[index], flags);
> - }
> - if (__test_and_clear_bit(i, mask)) {
> - offset = xgpio_offset(chip, i);
> - if (test_bit(i, bits))
> - chip->gpio_state[index] |= BIT(offset);
> - else
> - chip->gpio_state[index] &= ~BIT(offset);
> - }
> - }
> -
> - xgpio_writereg(chip->regs + XGPIO_DATA_OFFSET +
> -index * XGPIO_CHANNEL_OFFSET, chip->gpio_state[index]);
> -
> - spin_unlock_irqrestore(>gpio_lock[index], flags);
> + u32 *const state = chip->gpio_state;
> + unsigned int *const width = chip->gpio_width;
> +
> + DECLARE_BITMAP(old, 64);
> + DECLARE_BITMAP(new, 64);
> + DECLARE_BITMAP(changed, 64);
> +
> + spin_lock_irqsave(>gpio_lock[0], flags);
> + spin_lock(>gpio_lock[1]);
> +
> + bitmap_set_value(old, 64, state[0], width[0], 0);
> + bitmap_set_value(old, 64, state[1], width[1], width[0]);
> + bitmap_replace(new, old, bits, mask, gc->ngpio);
> +
> + bitmap_set_value(old, 64, state[0], 32, 0);
> + bitmap_set_value(old, 64, state[1], 32, 32);
> + state[0] = bitmap_get_value(new, 0, width[0]);
> + state[1] = bitmap_get_value(new, width[0], width[1]);
> + bitmap_set_value(new, 64, state[0], 32, 0);
> + bitmap_set_value(new, 64, state[1], 32, 32);
> + bitmap_xor(changed, old, new, 64);
> +
> + if (((u32 *)changed)[0])
> + xgpio_writereg(chip->regs + XGPIO_DATA_OFFSET,
> + state[0]);
> + if (((u32 *)changed)[1])
> + xgpio_writereg(chip->regs + XGPIO_DATA_OFFSET +
> + XGPIO_CHANNEL_OFFSET, state[1]);
> +
> + spin_unlock(>gpio_lock[1]);
> + spin_unlock_irqrestore(>gpio_lock[0], flags);
> }
>
> /**
>
Srinivas N: Can you please test this code?
Thanks,
Michal
Re: [PATCH] media: platform: xilinx: fix error return code of xvip_graph_init()
On 3/5/21 10:48 AM, Jia-Ju Bai wrote:
> When the list of xdev->notifier.asd_list is empty, no error return code
> of xvip_graph_init() is assigned.
> To fix this bug, ret is assigned with -ENOENT as error return code.
>
> Reported-by: TOTE Robot
> Signed-off-by: Jia-Ju Bai
> ---
> drivers/media/platform/xilinx/xilinx-vipp.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/media/platform/xilinx/xilinx-vipp.c
> b/drivers/media/platform/xilinx/xilinx-vipp.c
> index bf4015d852e3..2ce31d7ce1a6 100644
> --- a/drivers/media/platform/xilinx/xilinx-vipp.c
> +++ b/drivers/media/platform/xilinx/xilinx-vipp.c
> @@ -525,6 +525,7 @@ static int xvip_graph_init(struct xvip_composite_device
> *xdev)
>
> if (list_empty(>notifier.asd_list)) {
> dev_err(xdev->dev, "no subdev found in graph\n");
> + ret = -ENOENT;
> goto done;
> }
>
>
Reviewed-by: Michal Simek
Thanks,
Michal
Re: [PATCH] ata: ahci: ceva: Updated code by using dev_err_probe()
On 3/4/21 4:53 PM, Piyush Mehta wrote:
> Updated code with already prepared dev_err_probe(). It reduces code size
> and simplifies EPROBE_DEFER handling.
>
> Also, unify message format for similar error cases.
>
> Signed-off-by: Piyush Mehta
> ---
> This patch is based on ahci-ceva patches:
> https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git/commit/?h=for-next=5542fabd9e07d6c49c07862e73070c325f93d390
>
> Tree:
> https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git/tree/?h=for-next
> ---
> drivers/ata/ahci_ceva.c |5 ++---
> 1 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/ata/ahci_ceva.c b/drivers/ata/ahci_ceva.c
> index b980218..a935209 100644
> --- a/drivers/ata/ahci_ceva.c
> +++ b/drivers/ata/ahci_ceva.c
> @@ -207,9 +207,8 @@ static int ceva_ahci_probe(struct platform_device *pdev)
> cevapriv->rst = devm_reset_control_get_optional_exclusive(>dev,
> NULL);
> if (IS_ERR(cevapriv->rst)) {
> - if (PTR_ERR(cevapriv->rst) != -EPROBE_DEFER)
> - dev_err(>dev, "failed to get reset: %ld\n",
> - PTR_ERR(cevapriv->rst));
> + dev_err_probe(>dev, PTR_ERR(cevapriv->rst),
> + "failed to get reset\n");
> }
I got it twice not sure why.
nit: Sorry I didn't spot it in the first internal review.
But you can also remove that {} around.
With that fixed please add my
Acked-by: Michal Simek
Thanks,
Michal
Re: [PATCH] reset: zynqmp: replace spaces with tabs
On 3/4/21 5:00 PM, Philipp Zabel wrote:
> Fixes checkpatch issues:
>
> ERROR: code indent should use tabs where possible
> #86: FILE: drivers/reset/reset-zynqmp.c:86:
> +.reset_id = 0,$
>
> WARNING: please, no spaces at the start of a line
> #86: FILE: drivers/reset/reset-zynqmp.c:86:
> +.reset_id = 0,$
>
> ERROR: code indent should use tabs where possible
> #87: FILE: drivers/reset/reset-zynqmp.c:87:
> +.num_resets = VERSAL_NR_RESETS,$
>
> WARNING: please, no spaces at the start of a line
> #87: FILE: drivers/reset/reset-zynqmp.c:87:
> +.num_resets = VERSAL_NR_RESETS,$
>
> Signed-off-by: Philipp Zabel
> ---
> drivers/reset/reset-zynqmp.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/reset/reset-zynqmp.c b/drivers/reset/reset-zynqmp.c
> index ebd433fa09dd..daa425e74c96 100644
> --- a/drivers/reset/reset-zynqmp.c
> +++ b/drivers/reset/reset-zynqmp.c
> @@ -83,8 +83,8 @@ static const struct zynqmp_reset_soc_data zynqmp_reset_data
> = {
> };
>
> static const struct zynqmp_reset_soc_data versal_reset_data = {
> -.reset_id = 0,
> -.num_resets = VERSAL_NR_RESETS,
> + .reset_id = 0,
> + .num_resets = VERSAL_NR_RESETS,
> };
>
> static const struct reset_control_ops zynqmp_reset_ops = {
>
Reviewed-by: Michal Simek
Thanks,
Michal
Re: [PATCH V3 2/2] ata: ahci: ceva: Update the driver to support xilinx GT phy
On 2/8/21 7:03 PM, Piyush Mehta wrote:
> SATA controller used in Xilinx ZynqMP platform uses xilinx GT phy
> which has 4 GT lanes and can be used by 4 peripherals at a time.
> SATA controller uses 1 GT phy lane among the 4 GT lanes. To configure
> the GT lane for the SATA controller, the below sequence is expected.
>
> 1. Assert the SATA controller reset.
> 2. Configure the xilinx GT phy lane for SATA controller (phy_init).
> 3. De-assert the SATA controller reset.
> 4. Wait for PLL of the GT lane used by SATA to be locked (phy_power_on).
>
> The ahci_platform_enable_resources() by default does the phy_init()
> and phy_power_on() but the default sequence doesn't work with Xilinx
> platforms. Because of this reason, updated the driver to support the
> new sequence.
>
> Added cevapriv->rst check, for backward compatibility with the older
> sequence. If the reset controller is not available, then the SATA
> controller will configure with the older sequences.
>
> Signed-off-by: Piyush Mehta
> ---
> drivers/ata/ahci_ceva.c | 43 ---
> 1 file changed, 40 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/ata/ahci_ceva.c b/drivers/ata/ahci_ceva.c
> index b10fd4c..b980218 100644
> --- a/drivers/ata/ahci_ceva.c
> +++ b/drivers/ata/ahci_ceva.c
> @@ -12,6 +12,7 @@
> #include
> #include
> #include
> +#include
> #include "ahci.h"
>
> /* Vendor Specific Register Offsets */
> @@ -87,6 +88,7 @@ struct ceva_ahci_priv {
> u32 axicc;
> bool is_cci_enabled;
> int flags;
> + struct reset_control *rst;
> };
>
> static unsigned int ceva_ahci_read_id(struct ata_device *dev,
> @@ -202,13 +204,48 @@ static int ceva_ahci_probe(struct platform_device *pdev)
>
> cevapriv->ahci_pdev = pdev;
>
> + cevapriv->rst = devm_reset_control_get_optional_exclusive(>dev,
> + NULL);
> + if (IS_ERR(cevapriv->rst)) {
> + if (PTR_ERR(cevapriv->rst) != -EPROBE_DEFER)
> + dev_err(>dev, "failed to get reset: %ld\n",
> + PTR_ERR(cevapriv->rst));
> + }
nit: This can be handled via dev_err_probe() to simplify this logic here.
It was added by a787e5400a1c ("driver core: add device probe log
helper") but up to Jens if he wants this to be fixed.
> +
> hpriv = ahci_platform_get_resources(pdev, 0);
> if (IS_ERR(hpriv))
> return PTR_ERR(hpriv);
>
> - rc = ahci_platform_enable_resources(hpriv);
> - if (rc)
> - return rc;
> + if (!cevapriv->rst) {
> + rc = ahci_platform_enable_resources(hpriv);
> + if (rc)
> + return rc;
> + } else {
> + int i;
> +
> + rc = ahci_platform_enable_clks(hpriv);
> + if (rc)
> + return rc;
> + /* Assert the controller reset */
> + reset_control_assert(cevapriv->rst);
> +
> + for (i = 0; i < hpriv->nports; i++) {
> + rc = phy_init(hpriv->phys[i]);
> + if (rc)
> + return rc;
> + }
> +
> + /* De-assert the controller reset */
> + reset_control_deassert(cevapriv->rst);
> +
> + for (i = 0; i < hpriv->nports; i++) {
> + rc = phy_power_on(hpriv->phys[i]);
> + if (rc) {
> + phy_exit(hpriv->phys[i]);
> + return rc;
> + }
> + }
> + }
>
> if (of_property_read_bool(np, "ceva,broken-gen2"))
> cevapriv->flags = CEVA_FLAG_BROKEN_GEN2;
>
Acked-by: Michal Simek
Jens: Can you please take a look at this patch if you see any other issue?
Thanks,
Michal
Re: [PATCH v1] microblaze: tag highmem_setup() with __meminit
On 3/2/21 10:04 AM, David Hildenbrand wrote:
> On 01.03.21 23:18, Oscar Salvador wrote:
>> On Mon, Mar 01, 2021 at 12:47:49PM +0100, David Hildenbrand wrote:
>>> With commit a0cd7a7c4bc0 ("mm: simplify free_highmem_page() and
>>> free_reserved_page()") the kernel test robot complains about a warning:
>>>
>>> WARNING: modpost: vmlinux.o(.text.unlikely+0x23ac): Section mismatch in
>>> Â Â reference from the function highmem_setup() to the function
>>> Â Â .meminit.text:memblock_is_reserved()
>>>
>>> This has been broken ever since microblaze added highmem support,
>>> because memblock_is_reserved() was already tagged with "__init" back
>>> then -
>>> most probably the function always got inlined, so we never stumbled over
>>> it.
>>
>> It might be good to point out that we need __meminit instead of __init
>> because microblaze platform does not define CONFIG_ARCH_KEEP_MEMBLOCK,
>> and __init_memblock fallsback to that.
>>
>> (I had to go and look as I was puzzled :-) )
>>
>> Reviewed-by: Oscar Salvador
>
> Thanks!
>
> Whoever feels like picking this up (@Andrew?) can you add
>
> "We need __meminit because __init_memblock defaults to that without
> CONFIG_ARCH_KEEP_MEMBLOCK" and __init_memblock is not used outside
> memblock code.
>
Applied with this line added.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
Re: [PATCH 1/2] microblaze: syscalls: switch to generic syscalltbl.sh
On 3/1/21 3:23 PM, Masahiro Yamada wrote:
> Many architectures duplicate similar shell scripts.
>
> This commit converts microblaze to use scripts/syscalltbl.sh.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> arch/microblaze/kernel/syscall_table.S| 3 +-
> arch/microblaze/kernel/syscalls/Makefile | 7 ++--
> arch/microblaze/kernel/syscalls/syscalltbl.sh | 32 ---
> 3 files changed, 3 insertions(+), 39 deletions(-)
> delete mode 100644 arch/microblaze/kernel/syscalls/syscalltbl.sh
>
> diff --git a/arch/microblaze/kernel/syscall_table.S
> b/arch/microblaze/kernel/syscall_table.S
> index ce006646f741..3bc60a2b159e 100644
> --- a/arch/microblaze/kernel/syscall_table.S
> +++ b/arch/microblaze/kernel/syscall_table.S
> @@ -1,6 +1,5 @@
> /* SPDX-License-Identifier: GPL-2.0 */
>
> -#define __SYSCALL(nr, entry, nargs) .long entry
> +#define __SYSCALL(nr, entry) .long entry
> ENTRY(sys_call_table)
> #include
> -#undef __SYSCALL
> diff --git a/arch/microblaze/kernel/syscalls/Makefile
> b/arch/microblaze/kernel/syscalls/Makefile
> index 285aaba832d9..ad2492cb5568 100644
> --- a/arch/microblaze/kernel/syscalls/Makefile
> +++ b/arch/microblaze/kernel/syscalls/Makefile
> @@ -7,7 +7,7 @@ _dummy := $(shell [ -d '$(uapi)' ] || mkdir -p '$(uapi)')
> \
>
> syscall := $(src)/syscall.tbl
> syshdr := $(srctree)/$(src)/syscallhdr.sh
> -systbl := $(srctree)/$(src)/syscalltbl.sh
> +systbl := $(srctree)/scripts/syscalltbl.sh
>
> quiet_cmd_syshdr = SYSHDR $@
>cmd_syshdr = $(CONFIG_SHELL) '$(syshdr)' '$<' '$@' \
> @@ -16,10 +16,7 @@ quiet_cmd_syshdr = SYSHDR $@
> '$(syshdr_offset_$(basetarget))'
>
> quiet_cmd_systbl = SYSTBL $@
> - cmd_systbl = $(CONFIG_SHELL) '$(systbl)' '$<' '$@' \
> -'$(systbl_abis_$(basetarget))' \
> -'$(systbl_abi_$(basetarget))'\
> -'$(systbl_offset_$(basetarget))'
> + cmd_systbl = $(CONFIG_SHELL) $(systbl) $< $@
>
> $(uapi)/unistd_32.h: $(syscall) $(syshdr) FORCE
> $(call if_changed,syshdr)
> diff --git a/arch/microblaze/kernel/syscalls/syscalltbl.sh
> b/arch/microblaze/kernel/syscalls/syscalltbl.sh
> deleted file mode 100644
> index 85d78d9309ad..
> --- a/arch/microblaze/kernel/syscalls/syscalltbl.sh
> +++ /dev/null
> @@ -1,32 +0,0 @@
> -#!/bin/sh
> -# SPDX-License-Identifier: GPL-2.0
> -
> -in="$1"
> -out="$2"
> -my_abis=`echo "($3)" | tr ',' '|'`
> -my_abi="$4"
> -offset="$5"
> -
> -emit() {
> - t_nxt="$1"
> - t_nr="$2"
> - t_entry="$3"
> -
> - while [ $t_nxt -lt $t_nr ]; do
> - printf "__SYSCALL(%s, sys_ni_syscall, )\n" "${t_nxt}"
> - t_nxt=$((t_nxt+1))
> - done
> - printf "__SYSCALL(%s, %s, )\n" "${t_nxt}" "${t_entry}"
> -}
> -
> -grep -E "^[0-9A-Fa-fXx]+[[:space:]]+${my_abis}" "$in" | sort -n | (
> - nxt=0
> - if [ -z "$offset" ]; then
> - offset=0
> - fi
> -
> - while read nr abi name entry ; do
> - emit $((nxt+offset)) $((nr+offset)) $entry
> - nxt=$((nr+1))
> - done
> -) > "$out"
>
Applied both.
M
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
Re: DT overlay applied via pinctrl description
On 3/1/21 3:13 PM, Linus Walleij wrote: > On Mon, Mar 1, 2021 at 10:31 AM Michal Simek wrote: >> On 3/1/21 10:19 AM, Linus Walleij wrote: > >> Does this mean that you prefer to fix how dt overlay applying instead of >> fixing code to apply mux configs first before conf one? >> >> Something like this? (just c patch below) > > I think your patch looks correct! Can you make a proper patch, > make sure it solves your problem and submit to the mailing > list for review? I will check it on our platform and will send proper patch for it. Thanks, Michal
Re: DT overlay applied via pinctrl description
Hi Linus,
On 3/1/21 10:19 AM, Linus Walleij wrote:
> On Tue, Feb 16, 2021 at 4:35 PM Michal Simek wrote:
>
>> I have a question about expectations when pinctrl setting is applied. In
>> DTS all nodes are described in the order available in DT.
>>
>> uart-default {
>> mux {
>> ...
>> };
>>
>> conf {
>> ...
>> };
>> };
>>
>> I don't know if this standard description or not. I definitely see other
>> pinctrl drivers which are using different structure.
>>
>> Anyway when overlay is applied the order has changed to
>> uart-default {
>> conf {
>> ...
>> };
>>
>> mux {
>> ...
>> };
>> };
>>
>> which is causing issue because pin is configured first via conf node
>> before it is requested via mux. This is something what firmware is
>> checking and error out.
>
> As Frank says the DT ordering has no semantic meaning, it is essentially
> a functional language, describes object relations not sequences.
>
> The Linux kernel applies the mux and conf in that order because of how
> the code is implemented (this order also makes a lot of sense for the
> hardware). I would recommend to trace the execution of an overlay
> being applied and try to find the reason conf goes before mux and fix
> the bug there. I think it is a bug in how pinctrl handles DT overlays.
Does this mean that you prefer to fix how dt overlay applying instead of
fixing code to apply mux configs first before conf one?
Something like this? (just c patch below)
Thanks,
Michal
diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index 7d3370289938..cf56ee5d7e02 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -1258,13 +1258,35 @@ static int pinctrl_commit_state(struct pinctrl
*p, struct pinctrl_state *state)
p->state = NULL;
- /* Apply all the settings for the new state */
+ /* Apply all the settings for the new state - pinmux first */
list_for_each_entry(setting, >settings, node) {
switch (setting->type) {
case PIN_MAP_TYPE_MUX_GROUP:
ret = pinmux_enable_setting(setting);
break;
case PIN_MAP_TYPE_CONFIGS_PIN:
+ case PIN_MAP_TYPE_CONFIGS_GROUP:
+ break;
+ default:
+ ret = -EINVAL;
+ break;
+ }
+
+ if (ret < 0) {
+ goto unapply_new_state;
+ }
+
+ /* Do not link hogs (circular dependency) */
+ if (p != setting->pctldev->p)
+ pinctrl_link_add(setting->pctldev, p->dev);
+ }
+
+ /* Apply all the settings for the new state - pinconf after */
+ list_for_each_entry(setting, >settings, node) {
+ switch (setting->type) {
+ case PIN_MAP_TYPE_MUX_GROUP:
+ break;
+ case PIN_MAP_TYPE_CONFIGS_PIN:
case PIN_MAP_TYPE_CONFIGS_GROUP:
ret = pinconf_apply_setting(setting);
break;
Re: [PATCH v3 1/3] firmware: xilinx: Add pinctrl support
Hi Noburiho,
On 2/28/21 1:17 AM, Nobuhiro Iwamatsu wrote:
> Hi,
>
> 2021年2月12日(金) 21:10 Sai Krishna Potthuri
> :
>>
>> Adding pinctrl support to query platform specific information (pins)
>> from firmware.
>>
>> Signed-off-by: Sai Krishna Potthuri
>> Acked-by: Michal Simek
>> ---
>> drivers/firmware/xilinx/zynqmp.c | 114 +++
>> include/linux/firmware/xlnx-zynqmp.h | 90 +
>> 2 files changed, 204 insertions(+)
>>
>> diff --git a/drivers/firmware/xilinx/zynqmp.c
>> b/drivers/firmware/xilinx/zynqmp.c
>> index efb8a66efc68..299c3d5a9ebd 100644
>> --- a/drivers/firmware/xilinx/zynqmp.c
>> +++ b/drivers/firmware/xilinx/zynqmp.c
>> @@ -784,6 +784,120 @@ int zynqmp_pm_fpga_get_status(u32 *value)
>> }
>> EXPORT_SYMBOL_GPL(zynqmp_pm_fpga_get_status);
>>
>
>
>
>> @@ -125,6 +131,12 @@ enum pm_query_id {
>> PM_QID_CLOCK_GET_FIXEDFACTOR_PARAMS,
>> PM_QID_CLOCK_GET_PARENTS,
>> PM_QID_CLOCK_GET_ATTRIBUTES,
>> + PM_QID_PINCTRL_GET_NUM_PINS = 6,
>> + PM_QID_PINCTRL_GET_NUM_FUNCTIONS = 7,
>> + PM_QID_PINCTRL_GET_NUM_FUNCTION_GROUPS = 8,
>> + PM_QID_PINCTRL_GET_FUNCTION_NAME = 9,
>> + PM_QID_PINCTRL_GET_FUNCTION_GROUPS = 10,
>> + PM_QID_PINCTRL_GET_PIN_GROUPS = 11,
>
> These do not have to have values, Because PM_QID_INVALID is 0.
>
>> PM_QID_CLOCK_GET_NUM_CLOCKS = 12,
>
> And you can drop value from this.
Please take a look at
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/include/linux/firmware/xlnx-zynqmp.h?h=v5.12-rc1=1077d4367ab3b97f6db2f66c87289af863652215
We are using explicit values as was recommended by Greg.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
Re: [PATCH v2 1/2] dt-bindings: usb: misc: Add binding for Microchip usb5744 hub
Hi Rob, On 2/11/21 3:42 PM, Rob Herring wrote: > On Thu, Feb 11, 2021 at 3:35 AM Michal Simek wrote: >> >> Hi Rob, >> >> On 2/10/21 11:22 PM, Rob Herring wrote: >>> On Tue, Feb 09, 2021 at 11:48:09AM +0100, Michal Simek wrote: >>>> From: Piyush Mehta >>>> >>>> Added dt binding for usb5744 driver. >>>> >>>> Signed-off-by: Piyush Mehta >>>> Signed-off-by: Michal Simek >>>> --- >>>> >>>> Changes in v2: None >>>> >>>> .../bindings/usb/microchip,usb5744.yaml | 56 +++ >>>> MAINTAINERS | 1 + >>>> 2 files changed, 57 insertions(+) >>>> create mode 100644 >>>> Documentation/devicetree/bindings/usb/microchip,usb5744.yaml >>>> >>>> diff --git a/Documentation/devicetree/bindings/usb/microchip,usb5744.yaml >>>> b/Documentation/devicetree/bindings/usb/microchip,usb5744.yaml >>>> new file mode 100644 >>>> index ..fe222f6db81d >>>> --- /dev/null >>>> +++ b/Documentation/devicetree/bindings/usb/microchip,usb5744.yaml >>>> @@ -0,0 +1,56 @@ >>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >>>> +%YAML 1.2 >>>> +--- >>>> +$id: "http://devicetree.org/schemas/usb/microchip,usb5744.yaml#; >>>> +$schema: "http://devicetree.org/meta-schemas/core.yaml#; >>>> + >>>> +title: Bindings for the Microchip USB5744 4-port Hub Controller >>>> + >>>> +description: >>>> + Microchip’s USB5744 SmartHub™ IC is a 4 port, SuperSpeed (SS)/Hi-Speed >>>> (HS), >>>> + low power, low pin count configurable and fully compliant with the USB >>>> 3.1 >>>> + Gen 1 specification. The USB5744 also supports Full Speed (FS) and Low >>>> Speed >>>> + (LS) USB signaling, offering complete coverage of all defined USB >>>> operating >>>> + speeds. The new SuperSpeed hubs operate in parallel with the USB 2.0 >>>> + controller, so 5 Gbps SuperSpeed data transfers are not affected by >>>> slower >>>> + USB 2.0 traffic. >>>> + >>>> +maintainers: >>>> + - Piyush Mehta >>>> + - Michal Simek >>>> + >>>> +properties: >>>> + compatible: >>>> +const: microchip,usb5744 >>>> + >>>> + reg: >>>> +maxItems: 1 >>>> +description: | >>>> + Specifies the i2c slave address, it is required and should be 0x2d >>>> + if I2C is used. >>> >>> If I2C is not used, then this should be underneath the USB host as a USB >>> device. That also implies a different compatible string. I'd suggest you >>> just say I2C is required if that's your use. >> >> We can't say that i2c is required because we have both cases. One is >> really usb hub connected over i2c which at least requires to send one >> smbus command to start operate. But it can be extended to add more >> features - limit speeds, disable ports, etc. >> >> And the second is really the same usb hub without i2c connected which >> runs in default mode. But reset is required to ensure proper reset >> sequence. >> Hub also have external clock chip which is not handled now because it is >> just crystal on the board but if you want I can also model it via fixed >> clock and call clock enable for it. >> >> It is the same use case as is with >> Documentation/devicetree/bindings/usb/usb3503.txt > > Yes, there are examples of how we don't want to do it. ok. > >> Can you please elaborate why different compatible string should be used? >> It is still the same device and not quite sure why different compatible >> string should be used. >> >> Do you also want to example where this node is the part of usb node? > > See usb/usb-device.txt. And there is this[1] under review. > > For these cases with I2C, I'd really rather see the hub always under > the USB bus with a link to the I2C bus when connected. I read that thread and also looked at his device and it is very similar to this one. Binding should also have information about i2c or spi. It is the same case here that you can use this hub without any bus connected which works in default mode. Or when i2c/smbus is connected and the hub is waiting for initialization sequence. And I expect spi behaves very similarly but don't have this setup here. Do we have any binding doc which is using suggested bus link? Thanks, Michal
Re: [PATCH v5 0/4] USB: misc: Add onboard_usb_hub driver
Hi Matthias, On 2/10/21 6:10 PM, Matthias Kaehlcke wrote: > This series adds the onboard_usb_hub_driver, the corresponding > device tree bindings and creation of onboard_usb_hub platform in > the xhci-plat driver during probe(). > > The main issue the driver addresses is that a USB hub needs to be > powered before it can be discovered. For discrete onboard hubs (an > example for such a hub is the Realtek RTS5411) this is often solved > by supplying the hub with an 'always-on' regulator, which is kind > of a hack. Some onboard hubs may require further initialization > steps, like changing the state of a GPIO or enabling a clock, which > requires even more hacks. This driver creates a platform device > representing the hub which performs the necessary initialization. > Currently it only supports switching on a single regulator, support > for multiple regulators or other actions can be added as needed. > Different initialization sequences can be supported based on the > compatible string. > > Besides performing the initialization the driver can be configured > to power the hub off during system suspend. This can help to extend > battery life on battery powered devices which have no requirements > to keep the hub powered during suspend. The driver can also be > configured to leave the hub powered when a wakeup capable USB device > is connected when suspending, and power it off otherwise. > Rob pointed me here at your series. http://lore.kernel.org/r/cal_jsqjedhx6typpukbnzv7clk6uzvjq3cyg9iy_j5dlpqv...@mail.gmail.com And I have looked at RTS5411 datasheet and it looks very similar to Microchip usb5744 chip we use. Both have i2c/smbus and spi interfaces and also input clock. usb5744 has also external gpio reset. There are also usb3503 and others which should fit to this generic DT binding. Thanks, Michal That's why please keep me in the loop on v6 because I think
[GIT PULL] arch/microblaze patches for 5.12-rc1
Hi Linus, please pull these 3 patches to your tree. Thanks, Michal The following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e: Linux 5.11-rc1 (2020-12-27 15:30:22 -0800) are available in the Git repository at: git://git.monstr.eu/linux-2.6-microblaze.git tags/microblaze-v5.12 for you to fetch changes up to 48783be427c70a377c83a17d045eee98c90220da: microblaze: Fix built-in DTB alignment to be 8-byte aligned (2021-02-16 07:43:36 +0100) Microblaze patches for 5.12-rc1 - Fix DTB alignment - Remove < GCC 4 support - Remove TRACING_SUPPORT selection Geert Uytterhoeven (1): microblaze: Remove support for gcc < 4 Masahiro Yamada (1): microblaze: do not select TRACING_SUPPORT directly Rob Herring (1): microblaze: Fix built-in DTB alignment to be 8-byte aligned arch/microblaze/Kconfig | 1 - arch/microblaze/kernel/module.c | 26 -- arch/microblaze/kernel/vmlinux.lds.S | 2 +- 3 files changed, 1 insertion(+), 28 deletions(-) -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
DT overlay applied via pinctrl description
Hi,
I have a question about expectations when pinctrl setting is applied. In
DTS all nodes are described in the order available in DT.
uart-default {
mux {
...
};
conf {
...
};
};
I don't know if this standard description or not. I definitely see other
pinctrl drivers which are using different structure.
Anyway when overlay is applied the order has changed to
uart-default {
conf {
...
};
mux {
...
};
};
which is causing issue because pin is configured first via conf node
before it is requested via mux. This is something what firmware is
checking and error out.
That's why I want to check with you if this is issue with DT binding
description we use in zynqmp pinctrl driver posted here
https://lore.kernel.org/linux-arm-kernel/1613131643-60062-1-git-send-email-lakshmi.sai.krishna.potth...@xilinx.com/
I have also tried to use init and default configuration where init is
called just with mux setting and then default is called just with config
but the issue is there as well because in pinctrl_commit_state()
previous state is checked and for MUXes pinmux_disable_setting() is
called which release a pin. And then configuration in default is called
but without requesting pin which fails for the same reason as above.
That's why my questions are:
Are we using incorrect DT description?
And is there a need sort subnodes in a way that mux should be called
first by core before configuration?
Or is there any different way how to do it?
Thanks,
Michal
Re: [PATCH v3] firmware: xilinx: Remove zynqmp_pm_get_eemi_ops() in IS_REACHABLE(CONFIG_ZYNQMP_FIRMWARE)
On 2/15/21 4:58 PM, Nobuhiro Iwamatsu wrote:
> zynqmp_pm_get_eemi_ops() was removed in commit 4db8180ffe7c: "Firmware:
> xilinx:
> Remove eemi ops for fpga related APIs", but not in
> IS_REACHABLE(CONFIG_ZYNQMP_FIRMWARE).
> Any driver who want to communicate with PMC using EEMI APIs use the functions
> provided
> for each function
> This removed zynqmp_pm_get_eemi_ops() in
> IS_REACHABLE(CONFIG_ZYNQMP_FIRMWARE), and also
> modify the documentation for this driver.
>
> Fixes: 4db8180ffe7c ("firmware: xilinx: Remove eemi ops for fpga related
> APIs")
> Signed-off-by: Nobuhiro Iwamatsu
> ---
> v3: Update eemi.rst.
> v2: Added the comment pointed out by Michal.
>
> Documentation/driver-api/xilinx/eemi.rst | 31 ++--
> include/linux/firmware/xlnx-zynqmp.h | 5
> 2 files changed, 2 insertions(+), 34 deletions(-)
>
> diff --git a/Documentation/driver-api/xilinx/eemi.rst
> b/Documentation/driver-api/xilinx/eemi.rst
> index 9dcbc6f18d75df..579cf9a407ac2f 100644
> --- a/Documentation/driver-api/xilinx/eemi.rst
> +++ b/Documentation/driver-api/xilinx/eemi.rst
> @@ -16,35 +16,8 @@ components running across different processing clusters on
> a chip or
> device to communicate with a power management controller (PMC) on a
> device to issue or respond to power management requests.
>
> -EEMI ops is a structure containing all eemi APIs supported by Zynq MPSoC.
> -The zynqmp-firmware driver maintain all EEMI APIs in zynqmp_eemi_ops
> -structure. Any driver who want to communicate with PMC using EEMI APIs
> -can call zynqmp_pm_get_eemi_ops().
> -
> -Example of EEMI ops::
> -
> - /* zynqmp-firmware driver maintain all EEMI APIs */
> - struct zynqmp_eemi_ops {
> - int (*get_api_version)(u32 *version);
> - int (*query_data)(struct zynqmp_pm_query_data qdata, u32 *out);
> - };
> -
> - static const struct zynqmp_eemi_ops eemi_ops = {
> - .get_api_version = zynqmp_pm_get_api_version,
> - .query_data = zynqmp_pm_query_data,
> - };
> -
> -Example of EEMI ops usage::
> -
> - static const struct zynqmp_eemi_ops *eemi_ops;
> - u32 ret_payload[PAYLOAD_ARG_CNT];
> - int ret;
> -
> - eemi_ops = zynqmp_pm_get_eemi_ops();
> - if (IS_ERR(eemi_ops))
> - return PTR_ERR(eemi_ops);
> -
> - ret = eemi_ops->query_data(qdata, ret_payload);
> +Any driver who want to communicate with PMC using EEMI APIs use the
wants
> +functions provided for each function.
>
> IOCTL
> --
> diff --git a/include/linux/firmware/xlnx-zynqmp.h
> b/include/linux/firmware/xlnx-zynqmp.h
> index c8a18da6906e78..70e19ab34ff1ca 100644
> --- a/include/linux/firmware/xlnx-zynqmp.h
> +++ b/include/linux/firmware/xlnx-zynqmp.h
> @@ -416,11 +416,6 @@ int zynqmp_pm_read_pggs(u32 index, u32 *value);
> int zynqmp_pm_system_shutdown(const u32 type, const u32 subtype);
> int zynqmp_pm_set_boot_health_status(u32 value);
> #else
> -static inline struct zynqmp_eemi_ops *zynqmp_pm_get_eemi_ops(void)
> -{
> - return ERR_PTR(-ENODEV);
> -}
> -
> static inline int zynqmp_pm_get_api_version(u32 *version)
> {
> return -ENODEV;
>
Queue for 5.13 with corrected sentence above.
Thanks,
Michal
Re: [PATCH] microblaze: Fix built-in DTB alignment to be 8-byte aligned
so 13. 2. 2021 v 2:16 odesÃlatel Rob Herring napsal:
>
> Commit 79edff12060f ("scripts/dtc: Update to upstream version
> v1.6.0-51-g183df9e9c2b9") broke booting on Microblaze systems depending on
> the build. The problem is libfdt gained an 8-byte starting alignment check,
> but the Microblaze built-in DTB area is only 4-byte aligned. This affected
> not just built-in DTBs as bootloader passed DTBs are copied into the
> built-in DTB region.
>
> Other arches using built-in DTBs use a common linker macro which has
> sufficient alignment.
>
> Fixes: 79edff12060f ("scripts/dtc: Update to upstream version
> v1.6.0-51-g183df9e9c2b9")
> Reported-by: Guenter Roeck
> Tested-by: Guenter Roeck
> Cc: Michal Simek
> Signed-off-by: Rob Herring
> ---
> As the commit is in my tree, I'll take this via the DT tree.
>
> arch/microblaze/kernel/vmlinux.lds.S | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/microblaze/kernel/vmlinux.lds.S
> b/arch/microblaze/kernel/vmlinux.lds.S
> index df07b3d06cd6..fb31747ec092 100644
> --- a/arch/microblaze/kernel/vmlinux.lds.S
> +++ b/arch/microblaze/kernel/vmlinux.lds.S
> @@ -45,7 +45,7 @@ SECTIONS {
> _etext = . ;
> }
>
> - . = ALIGN (4) ;
> + . = ALIGN (8) ;
> __fdt_blob : AT(ADDR(__fdt_blob) - LOAD_OFFSET) {
> _fdt_start = . ;/* place for fdt blob */
> *(__fdt_blob) ; /* Any link-placed DTB */
> --
> 2.27.0
>
Applied.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
Re: [PATCH] scripts/dtc: Update to upstream version v1.6.0-51-g183df9e9c2b9
Hi, On 2/12/21 11:50 PM, Guenter Roeck wrote: > On Fri, Feb 12, 2021 at 04:34:04PM -0600, Rob Herring wrote: >> On Fri, Feb 12, 2021 at 3:01 PM Rob Herring wrote: >>> >>> On Fri, Feb 12, 2021 at 9:17 AM Guenter Roeck wrote: On Fri, Feb 12, 2021 at 08:16:04AM -0600, Rob Herring wrote: > On Thu, Feb 11, 2021 at 9:31 PM Guenter Roeck wrote: >> >> Hi Rob, >> >> On Wed, Feb 03, 2021 at 03:26:03PM -0600, Rob Herring wrote: >>> This adds the following commits from upstream: >>> >>> 183df9e9c2b9 gitignore: Ignore the swp files >>> 0db6d09584e1 gitignore: Add cscope files >>> 307afa1a7be8 Update Jon Loeliger's email >>> ca16a723fa9d fdtdump: Fix gcc11 warning >>> 64990a272e8f srcpos: increase MAX_SRCFILE_DEPTH >>> 163f0469bf2e dtc: Allow overlays to have .dtbo extension >>> 3b01518e688d Set last_comp_version correctly in new dtb and fix >>> potential version issues in fdt_open_into >>> f7e5737f26aa tests: Fix overlay_overlay_nosugar test case >>> 7cd5d5fe43d5 libfdt: Tweak description of assume-aligned load helpers >>> a7c404099349 libfdt: Internally perform potentially unaligned loads >>> bab85e48a6f4 meson: increase default timeout for tests >>> f8b46098824d meson: do not assume python is installed, skip tests >>> 30a56bce4f0b meson: fix -Wall warning >>> 5e735860c478 libfdt: Check for 8-byte address alignment in >>> fdt_ro_probe_() >>> 67849a327927 build-sys: add meson build >>> 05874d08212d pylibfdt: allow build out of tree >>> 3bc3a6b9fe0c dtc: Fix signedness comparisons warnings: Wrap (-1) >>> e1147b159e92 dtc: Fix signedness comparisons warnings: change types >>> 04cf1fdc0fcf convert-dtsv0: Fix signedness comparisons warning >>> b30013edb878 libfdt: Fix kernel-doc comments >>> >>> Signed-off-by: Rob Herring >> >> This patch causes my little-endian microblaze qemu emulations to fail >> silently (no console output) in next-20210211. Reverting this patch >> together with "scripts: dtc: Build fdtoverlay tool" fixes the problem. > > My guess would be something in libfdt. Maybe 7cd5d5fe43d5 or > a7c404099349, though that should return to historical behavior. > > Can you give me the qemu command line and kernel cfg? > I copied everything you should need to build a kernel (including toolchain) to http://server.roeck-us.net/qemu/microblazeel/ [ wow, I really need to update that compiler ] >>> >>> I can't seem to get BE/LE nor reverted or not working. It's always >>> dying in microblaze_cache_init() based on the last print. It's your >>> config, but gcc 10.1.0 off of kernel.org. >> >> It seems gcc 10.1 does not work. Seems to die before here: >> >> pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 >> >>> There is at least one possible problem here that the FDT may only be 4 >>> byte aligned. The assumption is 8 bytes to not have misaligned >>> accesses (and only for 64-bit accesses if 4 byte aligned). That's an >>> issue with the qemu image loading depending on the sizes and >>> combination of images loaded. That doesn't explain your failure >>> though. As the initrd is a multiple of 8 bytes, you should be fine. >> >> It's the built-in dtb alignment that is the problem. I had noticed >> this earlier, then discovered I had no built-in DTB and QEMU provides >> a default. And changing didn't help because on broken gcc-10 it was 8 >> byte aligned. None of that should matter because we're not using the >> built-in either, right? Wrong! The assembly entry code copies the >> bootloader dtb into the built-in dtb space. I remember this now from >> the last time I cleaned up the early DT code. I suppose the reason is >> the bootloader dtb is not or may not be at an address mapped early. > I have tried 9.3 and 10.0 from https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/ but none of them did boot on real HW. Xilinx stayed on 9.2 and I have asked team to generate gcc 10/10.1 for me to be able to try it myself. > I think the problem is here: > > /* initialize device tree for usage in early_printk */ > early_init_devtree(_fdt_start); > > That probably also explains why enabling earlycon doesn't help. Can you please elaborate more on it? I see earlycon to be enabled quite early. [0.00] Ramdisk addr 0x, [0.00] Compiled-in FDT at (ptrval) [0.00] earlycon: ns16550a0 at MMIO 0x44a01000 (options '115200n8') [0.00] printk: bootconsole [ns16550a0] enabled [0.00] cma: Reserved 16 MiB at 0xaec0 > >> I'd really like to get rid of that copy. Anyway, the oneliner below >> fixes it. We need it either way, but I'd like some comments on the >> copy. >> > > I can not comment on the copy, but the change below does indeed fix > the problem. Feel free to add > > Tested-by: Guenter Roeck > > to the patch if you send it out. Please send the patch. Would be the best
Re: [PATCH] drivers: firmware: xilinx: Fix dereferencing freed memory
On 2/8/21 7:31 AM, Rajan Vaja wrote:
> From: Tejas Patel
>
> Fix smatch warning:
> drivers/firmware/xilinx/zynqmp.c:1288 zynqmp_firmware_remove()
> error: dereferencing freed memory 'feature_data'
>
> Use hash_for_each_safe for safe removal of hash entry.
>
> Fixes: acfdd18591ea ("firmware: xilinx: Use hash-table for api feature check")
> Reported-by: kernel test robot
> Reported-by: Dan Carpenter
> Signed-off-by: Tejas Patel
> Signed-off-by: Rajan Vaja
> ---
> drivers/firmware/xilinx/zynqmp.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/firmware/xilinx/zynqmp.c
> b/drivers/firmware/xilinx/zynqmp.c
> index 7eb9958..83082e2 100644
> --- a/drivers/firmware/xilinx/zynqmp.c
> +++ b/drivers/firmware/xilinx/zynqmp.c
> @@ -2,7 +2,7 @@
> /*
> * Xilinx Zynq MPSoC Firmware layer
> *
> - * Copyright (C) 2014-2020 Xilinx, Inc.
> + * Copyright (C) 2014-2021 Xilinx, Inc.
> *
> * Michal Simek
> * Davorin Mista
> @@ -1280,12 +1280,13 @@ static int zynqmp_firmware_probe(struct
> platform_device *pdev)
> static int zynqmp_firmware_remove(struct platform_device *pdev)
> {
> struct pm_api_feature_data *feature_data;
> + struct hlist_node *tmp;
> int i;
>
> mfd_remove_devices(>dev);
> zynqmp_pm_api_debugfs_exit();
>
> - hash_for_each(pm_api_features_map, i, feature_data, hentry) {
> + hash_for_each_safe(pm_api_features_map, i, tmp, feature_data, hentry) {
> hash_del(_data->hentry);
> kfree(feature_data);
> }
>
Applied.
Thanks,
Michal
Re: [PATCH v2] firmware: xilinx: Remove zynqmp_pm_get_eemi_ops() in IS_REACHABLE(CONFIG_ZYNQMP_FIRMWARE)
On 2/12/21 12:23 AM, Nobuhiro Iwamatsu wrote:
> zynqmp_pm_get_eemi_ops() was removed in commit 4db8180ffe7c: "Firmware:
> xilinx:
> Remove eemi ops for fpga related APIs", but not in
> IS_REACHABLE(CONFIG_ZYNQMP_FIRMWARE).
> Any driver who want to communicate with PMC using EEMI APIs use the functions
> provided
> for each function.
> This removed zynqmp_pm_get_eemi_ops() in
> IS_REACHABLE(CONFIG_ZYNQMP_FIRMWARE), and also
> modify the documentation for this driver.
>
> Fixes: 4db8180ffe7c ("firmware: xilinx: Remove eemi ops for fpga related
> APIs")
> Signed-off-by: Nobuhiro Iwamatsu
> ---
> v2: Added the comment pointed out by Michal.
>
> Documentation/driver-api/xilinx/eemi.rst | 27 +---
> include/linux/firmware/xlnx-zynqmp.h | 5 -
> 2 files changed, 1 insertion(+), 31 deletions(-)
>
> diff --git a/Documentation/driver-api/xilinx/eemi.rst
> b/Documentation/driver-api/xilinx/eemi.rst
> index 9dcbc6f18d75df..53416d25d309a8 100644
> --- a/Documentation/driver-api/xilinx/eemi.rst
> +++ b/Documentation/driver-api/xilinx/eemi.rst
> @@ -19,32 +19,7 @@ device to issue or respond to power management requests.
> EEMI ops is a structure containing all eemi APIs supported by Zynq MPSoC.
> The zynqmp-firmware driver maintain all EEMI APIs in zynqmp_eemi_ops
> structure. Any driver who want to communicate with PMC using EEMI APIs
> -can call zynqmp_pm_get_eemi_ops().
> -
> -Example of EEMI ops::
> -
> - /* zynqmp-firmware driver maintain all EEMI APIs */
> - struct zynqmp_eemi_ops {
> - int (*get_api_version)(u32 *version);
> - int (*query_data)(struct zynqmp_pm_query_data qdata, u32 *out);
> - };
> -
> - static const struct zynqmp_eemi_ops eemi_ops = {
> - .get_api_version = zynqmp_pm_get_api_version,
> - .query_data = zynqmp_pm_query_data,
> - };
> -
> -Example of EEMI ops usage::
> -
> - static const struct zynqmp_eemi_ops *eemi_ops;
> - u32 ret_payload[PAYLOAD_ARG_CNT];
> - int ret;
> -
> - eemi_ops = zynqmp_pm_get_eemi_ops();
> - if (IS_ERR(eemi_ops))
> - return PTR_ERR(eemi_ops);
> -
> - ret = eemi_ops->query_data(qdata, ret_payload);
> +use the functions provided for each function.
>
> IOCTL
> --
> diff --git a/include/linux/firmware/xlnx-zynqmp.h
> b/include/linux/firmware/xlnx-zynqmp.h
> index 2a0da841c942f6..4ef77deaf7918c 100644
> --- a/include/linux/firmware/xlnx-zynqmp.h
> +++ b/include/linux/firmware/xlnx-zynqmp.h
> @@ -355,11 +355,6 @@ int zynqmp_pm_read_pggs(u32 index, u32 *value);
> int zynqmp_pm_system_shutdown(const u32 type, const u32 subtype);
> int zynqmp_pm_set_boot_health_status(u32 value);
> #else
> -static inline struct zynqmp_eemi_ops *zynqmp_pm_get_eemi_ops(void)
> -{
> - return ERR_PTR(-ENODEV);
> -}
> -
> static inline int zynqmp_pm_get_api_version(u32 *version)
> {
> return -ENODEV;
>
I can't see any difference compare to v1. Don't you forget to commit
your changes?
Thanks,
Michal
Re: [PATCH 4/4] microblaze: Remove support for gcc < 4
On 2/10/21 3:11 PM, Geert Uytterhoeven wrote:
> Since commit cafa0010cd51fb71 ("Raise the minimum required gcc version
> to 4.6") , the kernel can no longer be compiled using gcc-3.
> Hence drop support code for gcc-3.
>
> Signed-off-by: Geert Uytterhoeven
> ---
> arch/microblaze/kernel/module.c | 26 --
> 1 file changed, 26 deletions(-)
>
> diff --git a/arch/microblaze/kernel/module.c b/arch/microblaze/kernel/module.c
> index 9f12e3c2bb42a319..e5db3a57b9e30d9e 100644
> --- a/arch/microblaze/kernel/module.c
> +++ b/arch/microblaze/kernel/module.c
> @@ -24,9 +24,6 @@ int apply_relocate_add(Elf32_Shdr *sechdrs, const char
> *strtab,
> Elf32_Sym *sym;
> unsigned long int *location;
> unsigned long int value;
> -#if __GNUC__ < 4
> - unsigned long int old_value;
> -#endif
>
> pr_debug("Applying add relocation section %u to %u\n",
> relsec, sechdrs[relsec].sh_info);
> @@ -49,40 +46,17 @@ int apply_relocate_add(Elf32_Shdr *sechdrs, const char
> *strtab,
>*/
>
> case R_MICROBLAZE_32:
> -#if __GNUC__ < 4
> - old_value = *location;
> - *location = value + old_value;
> -
> - pr_debug("R_MICROBLAZE_32 (%08lx->%08lx)\n",
> - old_value, value);
> -#else
> *location = value;
> -#endif
> break;
>
> case R_MICROBLAZE_64:
> -#if __GNUC__ < 4
> - /* Split relocs only required/used pre gcc4.1.1 */
> - old_value = ((location[0] & 0x) << 16) |
> - (location[1] & 0x);
> - value += old_value;
> -#endif
> location[0] = (location[0] & 0x) |
> (value >> 16);
> location[1] = (location[1] & 0x) |
> (value & 0x);
> -#if __GNUC__ < 4
> - pr_debug("R_MICROBLAZE_64 (%08lx->%08lx)\n",
> - old_value, value);
> -#endif
> break;
>
> case R_MICROBLAZE_64_PCREL:
> -#if __GNUC__ < 4
> - old_value = (location[0] & 0x) << 16 |
> - (location[1] & 0xFFFF);
> - value -= old_value;
> -#endif
> value -= (unsigned long int)(location) + 4;
> location[0] = (location[0] & 0x) |
> (value >> 16);
>
Applied.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
Re: [PATCH v2] dt-bindings: spi: zynq: Convert Zynq QSPI binding to yaml
On 2/11/21 1:39 PM, Mark Brown wrote: > On Thu, Feb 11, 2021 at 10:37:30AM +0100, Michal Simek wrote: >> st 10. 2. 2021 v 11:10 odesÃlatel Michal Simek >> napsal: > >>> +description: >>> + The Xilinx Zynq QSPI controller is used to access multi-bit serial flash >>> + memory devices. > >> Applied. > > Doesn't really matter here but I would really expect subsystem binding > documents to go through the subsystem tree. Sorry about it. I will keep that in my mind for future. Thanks, Michal
Re: [PATCH] ARM: zynq: Update Copyright date in DTS
On 2/11/21 12:27 PM, Arnd Bergmann wrote: > On Mon, Feb 1, 2021 at 3:28 PM Michal Simek wrote: >> >> Update years in header to be up2date. >> >> Signed-off-by: Michal Simek > > I saw this in your pull request, and I did not think this was how > copyrights work. > > From what I can tell, most of the files have not been touched in > years, so it's surprising that the copyright would include every > year up to 2021. > > Would you mind respinning the pull request either without this > patch, or with a clarified patch description that explains > what you do and a Signed-off-by from one of your company's > lawyers if they asked you for it? Ok. I will drop it for now. I will be touching this files with adding qspi description based on yaml binding. Thanks, Michal
Re: [PATCH] ARM: zynq: Update Copyright date in DTS
po 1. 2. 2021 v 15:28 odesÃlatel Michal Simek napsal:
>
> Update years in header to be up2date.
>
> Signed-off-by: Michal Simek
> ---
>
> arch/arm/boot/dts/zynq-7000.dtsi | 2 +-
> arch/arm/boot/dts/zynq-cc108.dts | 2 +-
> arch/arm/boot/dts/zynq-zc702.dts | 2 +-
> arch/arm/boot/dts/zynq-zc706.dts | 2 +-
> arch/arm/boot/dts/zynq-zc770-xm010.dts | 2 +-
> arch/arm/boot/dts/zynq-zc770-xm011.dts | 2 +-
> arch/arm/boot/dts/zynq-zc770-xm012.dts | 2 +-
> arch/arm/boot/dts/zynq-zc770-xm013.dts | 2 +-
> arch/arm/boot/dts/zynq-zed.dts | 2 +-
> arch/arm/boot/dts/zynq-zybo.dts| 2 +-
> 10 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm/boot/dts/zynq-7000.dtsi
> b/arch/arm/boot/dts/zynq-7000.dtsi
> index c4810d58540b..d46c1e2652e7 100644
> --- a/arch/arm/boot/dts/zynq-7000.dtsi
> +++ b/arch/arm/boot/dts/zynq-7000.dtsi
> @@ -1,6 +1,6 @@
> // SPDX-License-Identifier: GPL-2.0
> /*
> - * Copyright (C) 2011 - 2014 Xilinx
> + * Copyright (C) 2011 - 2021 Xilinx
> */
>
> / {
> diff --git a/arch/arm/boot/dts/zynq-cc108.dts
> b/arch/arm/boot/dts/zynq-cc108.dts
> index 8b9ab9bba23b..33546e13bb46 100644
> --- a/arch/arm/boot/dts/zynq-cc108.dts
> +++ b/arch/arm/boot/dts/zynq-cc108.dts
> @@ -2,7 +2,7 @@
> /*
> * Xilinx CC108 board DTS
> *
> - * (C) Copyright 2007-2018 Xilinx, Inc.
> + * (C) Copyright 2007-2021 Xilinx, Inc.
> * (C) Copyright 2007-2013 Michal Simek
> * (C) Copyright 2007-2012 PetaLogix Qld Pty Ltd
> *
> diff --git a/arch/arm/boot/dts/zynq-zc702.dts
> b/arch/arm/boot/dts/zynq-zc702.dts
> index cf70aff26c66..a226498364af 100644
> --- a/arch/arm/boot/dts/zynq-zc702.dts
> +++ b/arch/arm/boot/dts/zynq-zc702.dts
> @@ -1,6 +1,6 @@
> // SPDX-License-Identifier: GPL-2.0
> /*
> - * Copyright (C) 2011 - 2014 Xilinx
> + * Copyright (C) 2011 - 2021 Xilinx
> * Copyright (C) 2012 National Instruments Corp.
> */
> /dts-v1/;
> diff --git a/arch/arm/boot/dts/zynq-zc706.dts
> b/arch/arm/boot/dts/zynq-zc706.dts
> index 77943c16d33f..73d8b7a78415 100644
> --- a/arch/arm/boot/dts/zynq-zc706.dts
> +++ b/arch/arm/boot/dts/zynq-zc706.dts
> @@ -1,6 +1,6 @@
> // SPDX-License-Identifier: GPL-2.0
> /*
> - * Copyright (C) 2011 - 2014 Xilinx
> + * Copyright (C) 2011 - 2021 Xilinx
> * Copyright (C) 2012 National Instruments Corp.
> */
> /dts-v1/;
> diff --git a/arch/arm/boot/dts/zynq-zc770-xm010.dts
> b/arch/arm/boot/dts/zynq-zc770-xm010.dts
> index 0dd352289a45..e54a229b1f78 100644
> --- a/arch/arm/boot/dts/zynq-zc770-xm010.dts
> +++ b/arch/arm/boot/dts/zynq-zc770-xm010.dts
> @@ -2,7 +2,7 @@
> /*
> * Xilinx ZC770 XM010 board DTS
> *
> - * Copyright (C) 2013-2018 Xilinx, Inc.
> + * Copyright (C) 2013-2021 Xilinx, Inc.
> */
> /dts-v1/;
> #include "zynq-7000.dtsi"
> diff --git a/arch/arm/boot/dts/zynq-zc770-xm011.dts
> b/arch/arm/boot/dts/zynq-zc770-xm011.dts
> index 56732e8f6ca1..a4ce58e1e648 100644
> --- a/arch/arm/boot/dts/zynq-zc770-xm011.dts
> +++ b/arch/arm/boot/dts/zynq-zc770-xm011.dts
> @@ -2,7 +2,7 @@
> /*
> * Xilinx ZC770 XM011 board DTS
> *
> - * Copyright (C) 2013-2018 Xilinx, Inc.
> + * Copyright (C) 2013-2021 Xilinx, Inc.
> */
> /dts-v1/;
> #include "zynq-7000.dtsi"
> diff --git a/arch/arm/boot/dts/zynq-zc770-xm012.dts
> b/arch/arm/boot/dts/zynq-zc770-xm012.dts
> index d2359b789eb8..f842e7ad4f9d 100644
> --- a/arch/arm/boot/dts/zynq-zc770-xm012.dts
> +++ b/arch/arm/boot/dts/zynq-zc770-xm012.dts
> @@ -2,7 +2,7 @@
> /*
> * Xilinx ZC770 XM012 board DTS
> *
> - * Copyright (C) 2013-2018 Xilinx, Inc.
> + * Copyright (C) 2013-2021 Xilinx, Inc.
> */
> /dts-v1/;
> #include "zynq-7000.dtsi"
> diff --git a/arch/arm/boot/dts/zynq-zc770-xm013.dts
> b/arch/arm/boot/dts/zynq-zc770-xm013.dts
> index 38d96adc870c..fe4cd75bc9db 100644
> --- a/arch/arm/boot/dts/zynq-zc770-xm013.dts
> +++ b/arch/arm/boot/dts/zynq-zc770-xm013.dts
> @@ -2,7 +2,7 @@
> /*
> * Xilinx ZC770 XM013 board DTS
> *
> - * Copyright (C) 2013 Xilinx, Inc.
> + * Copyright (C) 2013-2021 Xilinx, Inc.
> */
> /dts-v1/;
> #include "zynq-7000.dtsi"
> diff --git a/arch/arm/boot/dts/zynq-zed.dts b/arch/arm/boot/dts/zynq-zed.dts
> index 6a5a93aa6552..fd2b562d374d 100644
> --- a/arch/arm/boot/dts/zynq-zed.dts
> +++ b/arch/arm/boot/dts/zynq-zed.dts
> @@ -1,6 +1,6 @@
> // SPDX-License-Identifier: GPL-2.0
> /*
> - * Copyright (C) 2011 - 2014 Xilinx
> + * Copyright (C) 2011 - 2021 Xilinx
> * Copyright (C) 2012 National Instruments Corp.
> */
> /dts-v1/;
> diff --git a/arch/arm/boot
Re: [PATCH v2 1/2] dt-bindings: usb: misc: Add binding for Microchip usb5744 hub
Hi Rob, On 2/10/21 11:22 PM, Rob Herring wrote: > On Tue, Feb 09, 2021 at 11:48:09AM +0100, Michal Simek wrote: >> From: Piyush Mehta >> >> Added dt binding for usb5744 driver. >> >> Signed-off-by: Piyush Mehta >> Signed-off-by: Michal Simek >> --- >> >> Changes in v2: None >> >> .../bindings/usb/microchip,usb5744.yaml | 56 +++ >> MAINTAINERS | 1 + >> 2 files changed, 57 insertions(+) >> create mode 100644 >> Documentation/devicetree/bindings/usb/microchip,usb5744.yaml >> >> diff --git a/Documentation/devicetree/bindings/usb/microchip,usb5744.yaml >> b/Documentation/devicetree/bindings/usb/microchip,usb5744.yaml >> new file mode 100644 >> index ..fe222f6db81d >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/usb/microchip,usb5744.yaml >> @@ -0,0 +1,56 @@ >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >> +%YAML 1.2 >> +--- >> +$id: "http://devicetree.org/schemas/usb/microchip,usb5744.yaml#; >> +$schema: "http://devicetree.org/meta-schemas/core.yaml#; >> + >> +title: Bindings for the Microchip USB5744 4-port Hub Controller >> + >> +description: >> + Microchip’s USB5744 SmartHub™ IC is a 4 port, SuperSpeed (SS)/Hi-Speed >> (HS), >> + low power, low pin count configurable and fully compliant with the USB 3.1 >> + Gen 1 specification. The USB5744 also supports Full Speed (FS) and Low >> Speed >> + (LS) USB signaling, offering complete coverage of all defined USB >> operating >> + speeds. The new SuperSpeed hubs operate in parallel with the USB 2.0 >> + controller, so 5 Gbps SuperSpeed data transfers are not affected by slower >> + USB 2.0 traffic. >> + >> +maintainers: >> + - Piyush Mehta >> + - Michal Simek >> + >> +properties: >> + compatible: >> +const: microchip,usb5744 >> + >> + reg: >> +maxItems: 1 >> +description: | >> + Specifies the i2c slave address, it is required and should be 0x2d >> + if I2C is used. > > If I2C is not used, then this should be underneath the USB host as a USB > device. That also implies a different compatible string. I'd suggest you > just say I2C is required if that's your use. We can't say that i2c is required because we have both cases. One is really usb hub connected over i2c which at least requires to send one smbus command to start operate. But it can be extended to add more features - limit speeds, disable ports, etc. And the second is really the same usb hub without i2c connected which runs in default mode. But reset is required to ensure proper reset sequence. Hub also have external clock chip which is not handled now because it is just crystal on the board but if you want I can also model it via fixed clock and call clock enable for it. It is the same use case as is with Documentation/devicetree/bindings/usb/usb3503.txt Can you please elaborate why different compatible string should be used? It is still the same device and not quite sure why different compatible string should be used. Do you also want to example where this node is the part of usb node? > > 'const: 0x2d' instead of maxItems is the schema to express the address > if fixed. Will fix. Thanks, Michal
Re: [PATCH v2] dt-bindings: spi: zynq: Convert Zynq QSPI binding to yaml
st 10. 2. 2021 v 11:10 odesÃlatel Michal Simek napsal:
>
> Convert spi-zynq-qspi.txt to yaml.
>
> Signed-off-by: Michal Simek
> ---
>
> Changes in v2:
> - s/additionalProperties: true/unevaluatedProperties: false/
>
> .../devicetree/bindings/spi/spi-zynq-qspi.txt | 25
> .../bindings/spi/xlnx,zynq-qspi.yaml | 59 +++
> MAINTAINERS | 1 +
> 3 files changed, 60 insertions(+), 25 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/spi/spi-zynq-qspi.txt
> create mode 100644 Documentation/devicetree/bindings/spi/xlnx,zynq-qspi.yaml
>
> diff --git a/Documentation/devicetree/bindings/spi/spi-zynq-qspi.txt
> b/Documentation/devicetree/bindings/spi/spi-zynq-qspi.txt
> deleted file mode 100644
> index 16b734ad3102..
> --- a/Documentation/devicetree/bindings/spi/spi-zynq-qspi.txt
> +++ /dev/null
> @@ -1,25 +0,0 @@
> -Xilinx Zynq QSPI controller Device Tree Bindings
>
> -
> -Required properties:
> -- compatible : Should be "xlnx,zynq-qspi-1.0".
> -- reg : Physical base address and size of QSPI registers
> map.
> -- interrupts : Property with a value describing the interrupt
> - number.
> -- clock-names : List of input clock names - "ref_clk", "pclk"
> - (See clock bindings for details).
> -- clocks : Clock phandles (see clock bindings for details).
> -
> -Optional properties:
> -- num-cs : Number of chip selects used.
> -
> -Example:
> - qspi: spi@e000d000 {
> - compatible = "xlnx,zynq-qspi-1.0";
> - reg = <0xe000d000 0x1000>;
> - interrupt-parent = <>;
> - interrupts = <0 19 4>;
> - clock-names = "ref_clk", "pclk";
> - clocks = < 10>, < 43>;
> - num-cs = <1>;
> - };
> diff --git a/Documentation/devicetree/bindings/spi/xlnx,zynq-qspi.yaml
> b/Documentation/devicetree/bindings/spi/xlnx,zynq-qspi.yaml
> new file mode 100644
> index ..1f1c40a9f320
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/spi/xlnx,zynq-qspi.yaml
> @@ -0,0 +1,59 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/spi/xlnx,zynq-qspi.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Xilinx Zynq QSPI controller
> +
> +description:
> + The Xilinx Zynq QSPI controller is used to access multi-bit serial flash
> + memory devices.
> +
> +allOf:
> + - $ref: "spi-controller.yaml#"
> +
> +maintainers:
> + - Michal Simek
> +
> +# Everything else is described in the common file
> +properties:
> + compatible:
> +const: xlnx,zynq-qspi-1.0
> +
> + reg:
> +maxItems: 1
> +
> + interrupts:
> +maxItems: 1
> +
> + clocks:
> +items:
> + - description: reference clock
> + - description: peripheral clock
> +
> + clock-names:
> +items:
> + - const: ref_clk
> + - const: pclk
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - clocks
> + - clock-names
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> +spi@e000d000 {
> +compatible = "xlnx,zynq-qspi-1.0";
> +reg = <0xe000d000 0x1000>;
> +interrupt-parent = <>;
> +interrupts = <0 19 4>;
> +clock-names = "ref_clk", "pclk";
> +clocks = < 10>, < 43>;
> +num-cs = <1>;
> +};
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 546aa66428c9..e494b061dcd1 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2766,6 +2766,7 @@ W:http://wiki.xilinx.com
> T: git https://github.com/Xilinx/linux-xlnx.git
> F: Documentation/devicetree/bindings/i2c/cdns,i2c-r1p10.yaml
> F: Documentation/devicetree/bindings/i2c/xlnx,xps-iic-2.00.a.yaml
> +F: Documentation/devicetree/bindings/spi/xlnx,zynq-qspi.yaml
> F: arch/arm/mach-zynq/
> F: drivers/block/xsysace.c
> F: drivers/clocksource/timer-cadence-ttc.c
> --
> 2.30.0
>
Applied.
M
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
Re: [PATCH 2/2] usb: misc: usb5744: Add support for USB hub controller
Hi Andrew,
On 2/10/21 3:52 AM, Andrew Lunn wrote:
> On Tue, Feb 09, 2021 at 10:53:20AM +0100, Michal Simek wrote:
>> +static int usb5744_i2c_probe(struct i2c_client *client,
>> + const struct i2c_device_id *id)
>> +{
>> +struct device *dev = >dev;
>> +int ret;
>> +
>> +/* Trigger gpio reset to the hub. */
>> +ret = usb5744_init_hw(dev);
>> +if (ret)
>> +return ret;
>> +
>> +/* Send SMBus command to boot hub. */
>> +ret = i2c_smbus_write_word_data(client, 0xAA, swab16(0x5600));
>
> Hi Michal
>
> This is not my area of the kernel. But that swab16() stood out, and
> made me wonder about endianness. Will this work correctly on big and
> little endian hosts?
thanks for bringing this up. I didn't test it on BE system.
I have grepped the kernel
[linux](xnext/usb5744)$ git grep i2c_smbus_write_word_data | grep swab
drivers/media/i2c/uda1342.c:17: i2c_smbus_write_word_data(client, reg,
swab16(value));
drivers/media/i2c/vpx3220.c:97: if (i2c_smbus_write_word_data(client,
0x27, swab16(fpaddr)) == -1) {
drivers/media/i2c/vpx3220.c:106:if (i2c_smbus_write_word_data(client,
0x28, swab16(data)) == -1) {
drivers/media/i2c/vpx3220.c:120:if (i2c_smbus_write_word_data(client,
0x26, swab16(fpaddr)) == -1) {
drivers/usb/misc/usb5744.c:50: ret = i2c_smbus_write_word_data(client,
0xAA, swab16(0x5600));
include/linux/i2c.h:168:return i2c_smbus_write_word_data(client,
command, swab16(value));
And last one is interesting
164 static inline s32
165 i2c_smbus_write_word_swapped(const struct i2c_client *client,
166 u8 command, u16 value)
167 {
168 return i2c_smbus_write_word_data(client, command,
swab16(value));
169 }
And this function is also used
[linux](xnext/usb5744)$ git grep i2c_smbus_write_word_swapped | wc -l
76
I think it would be the best to test it and see if this code works on BE
but I need to prepare it first.
And current code is aligned with others but it doesn't mean that it is
correct.
Thanks,
Michal
[PATCH v2] dt-bindings: spi: zynq: Convert Zynq QSPI binding to yaml
Convert spi-zynq-qspi.txt to yaml.
Signed-off-by: Michal Simek
---
Changes in v2:
- s/additionalProperties: true/unevaluatedProperties: false/
.../devicetree/bindings/spi/spi-zynq-qspi.txt | 25
.../bindings/spi/xlnx,zynq-qspi.yaml | 59 +++
MAINTAINERS | 1 +
3 files changed, 60 insertions(+), 25 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/spi/spi-zynq-qspi.txt
create mode 100644 Documentation/devicetree/bindings/spi/xlnx,zynq-qspi.yaml
diff --git a/Documentation/devicetree/bindings/spi/spi-zynq-qspi.txt
b/Documentation/devicetree/bindings/spi/spi-zynq-qspi.txt
deleted file mode 100644
index 16b734ad3102..
--- a/Documentation/devicetree/bindings/spi/spi-zynq-qspi.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-Xilinx Zynq QSPI controller Device Tree Bindings
-
-Required properties:
-- compatible : Should be "xlnx,zynq-qspi-1.0".
-- reg : Physical base address and size of QSPI registers map.
-- interrupts : Property with a value describing the interrupt
- number.
-- clock-names : List of input clock names - "ref_clk", "pclk"
- (See clock bindings for details).
-- clocks : Clock phandles (see clock bindings for details).
-
-Optional properties:
-- num-cs : Number of chip selects used.
-
-Example:
- qspi: spi@e000d000 {
- compatible = "xlnx,zynq-qspi-1.0";
- reg = <0xe000d000 0x1000>;
- interrupt-parent = <>;
- interrupts = <0 19 4>;
- clock-names = "ref_clk", "pclk";
- clocks = < 10>, < 43>;
- num-cs = <1>;
- };
diff --git a/Documentation/devicetree/bindings/spi/xlnx,zynq-qspi.yaml
b/Documentation/devicetree/bindings/spi/xlnx,zynq-qspi.yaml
new file mode 100644
index ..1f1c40a9f320
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/xlnx,zynq-qspi.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/xlnx,zynq-qspi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xilinx Zynq QSPI controller
+
+description:
+ The Xilinx Zynq QSPI controller is used to access multi-bit serial flash
+ memory devices.
+
+allOf:
+ - $ref: "spi-controller.yaml#"
+
+maintainers:
+ - Michal Simek
+
+# Everything else is described in the common file
+properties:
+ compatible:
+const: xlnx,zynq-qspi-1.0
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ clocks:
+items:
+ - description: reference clock
+ - description: peripheral clock
+
+ clock-names:
+items:
+ - const: ref_clk
+ - const: pclk
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+spi@e000d000 {
+compatible = "xlnx,zynq-qspi-1.0";
+reg = <0xe000d000 0x1000>;
+interrupt-parent = <>;
+interrupts = <0 19 4>;
+clock-names = "ref_clk", "pclk";
+clocks = < 10>, < 43>;
+num-cs = <1>;
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index 546aa66428c9..e494b061dcd1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2766,6 +2766,7 @@ W:http://wiki.xilinx.com
T: git https://github.com/Xilinx/linux-xlnx.git
F: Documentation/devicetree/bindings/i2c/cdns,i2c-r1p10.yaml
F: Documentation/devicetree/bindings/i2c/xlnx,xps-iic-2.00.a.yaml
+F: Documentation/devicetree/bindings/spi/xlnx,zynq-qspi.yaml
F: arch/arm/mach-zynq/
F: drivers/block/xsysace.c
F: drivers/clocksource/timer-cadence-ttc.c
--
2.30.0
Re: [PATCH] dt-bindings: arm: xilinx: Add missing Zturn boards
po 1. 2. 2021 v 14:16 odesÃlatel Michal Simek napsal: > > Add missing DT compatible strings for Zturn boards. > > Signed-off-by: Michal Simek > --- > > Patches are based on > https://lore.kernel.org/linux-arm-kernel/20210120194033.26970-3-mich...@walle.cc/ > --- > Documentation/devicetree/bindings/arm/xilinx.yaml | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Documentation/devicetree/bindings/arm/xilinx.yaml > b/Documentation/devicetree/bindings/arm/xilinx.yaml > index aaca69d0199f..05217537fb0c 100644 > --- a/Documentation/devicetree/bindings/arm/xilinx.yaml > +++ b/Documentation/devicetree/bindings/arm/xilinx.yaml > @@ -23,6 +23,8 @@ properties: >- digilent,zynq-zybo >- digilent,zynq-zybo-z7 >- ebang,ebaz4205 > + - myir,zynq-zturn-v5 > + - myir,zynq-zturn >- xlnx,zynq-cc108 >- xlnx,zynq-zc702 > - xlnx,zynq-zc706 > -- > 2.30.0 > Applied. M -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
[PATCH v2] usb: misc: usb3503: Fix logic in usb3503_init()
Based on
https://lore.kernel.org/linux-arm-kernel/ycjv59g3tq2ha...@kroah.com/
initialization should fail if any registration fails.
Signed-off-by: Michal Simek
---
Changes in v2:
- Also remove i2c driver when platform driver registration failed.
drivers/usb/misc/usb3503.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/misc/usb3503.c b/drivers/usb/misc/usb3503.c
index 48099c6bf04c..330f494cd158 100644
--- a/drivers/usb/misc/usb3503.c
+++ b/drivers/usb/misc/usb3503.c
@@ -409,13 +409,18 @@ static int __init usb3503_init(void)
int err;
err = i2c_add_driver(_i2c_driver);
- if (err != 0)
+ if (err) {
pr_err("usb3503: Failed to register I2C driver: %d\n", err);
+ return err;
+ }
err = platform_driver_register(_platform_driver);
- if (err != 0)
+ if (err) {
pr_err("usb3503: Failed to register platform driver: %d\n",
err);
+ i2c_del_driver(_i2c_driver);
+ return err;
+ }
return 0;
}
--
2.30.0
[PATCH] usb: misc: usb3503: Fix logic in usb3503_init()
Based on
https://lore.kernel.org/linux-arm-kernel/ycjv59g3tq2ha...@kroah.com/
initialization should fail if any registration fails.
Signed-off-by: Michal Simek
---
drivers/usb/misc/usb3503.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/misc/usb3503.c b/drivers/usb/misc/usb3503.c
index 48099c6bf04c..3aae83fbebae 100644
--- a/drivers/usb/misc/usb3503.c
+++ b/drivers/usb/misc/usb3503.c
@@ -409,13 +409,17 @@ static int __init usb3503_init(void)
int err;
err = i2c_add_driver(_i2c_driver);
- if (err != 0)
+ if (err) {
pr_err("usb3503: Failed to register I2C driver: %d\n", err);
+ return err;
+ }
err = platform_driver_register(_platform_driver);
- if (err != 0)
+ if (err) {
pr_err("usb3503: Failed to register platform driver: %d\n",
err);
+ return err;
+ }
return 0;
}
--
2.30.0
[PATCH v2 2/2] usb: misc: usb5744: Add support for USB hub controller
From: Piyush Mehta
This patch adds a USB GPIO based hub reset for USB5744 hub. This usb5744
driver trigger hub reset signal after soft reset or core Reset. The HUB
needs to be resetted after completion of phy initialization. After the
toggling of gpio, hub configure using i2c usb attached command.
USB5744 hub can be used without any I2C connection, is handled by a
simple platform device driver.
As part of the reset, sets the direction of the pin to output before
toggling the pin. Delay of millisecond is added in between low and
high to meet the setup and hold time requirement of the reset.
Signed-off-by: Piyush Mehta
Signed-off-by: Michal Simek
---
Changes in v2:
- s/USB_USB5744/USB_HUB_USB5744/g
- Fix order in Makefile and Kconfig
MAINTAINERS| 1 +
drivers/usb/misc/Kconfig | 9 +++
drivers/usb/misc/Makefile | 1 +
drivers/usb/misc/usb5744.c | 115 +
4 files changed, 126 insertions(+)
create mode 100644 drivers/usb/misc/usb5744.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 7439471b5d37..56d1fcdd24f6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2706,6 +2706,7 @@ F:drivers/edac/synopsys_edac.c
F: drivers/i2c/busses/i2c-cadence.c
F: drivers/i2c/busses/i2c-xiic.c
F: drivers/mmc/host/sdhci-of-arasan.c
+F: drivers/usb/misc/usb5744.c
N: zynq
N: xilinx
diff --git a/drivers/usb/misc/Kconfig b/drivers/usb/misc/Kconfig
index 8f1144359012..9995a5701fd9 100644
--- a/drivers/usb/misc/Kconfig
+++ b/drivers/usb/misc/Kconfig
@@ -255,6 +255,15 @@ config USB_HSIC_USB4604
help
This option enables support for SMSC USB4604 HSIC to USB 2.0 Driver.
+config USB_HUB_USB5744
+ tristate "Microchip USB5744 Hub driver"
+ depends on I2C
+ depends on GPIOLIB
+ help
+ This option enables support for Microchip USB5744 Hub. This driver
+ optionally reset the hub using gpio pin and configure hub via i2c if
+ connected.
+
config USB_LINK_LAYER_TEST
tristate "USB Link Layer Test driver"
help
diff --git a/drivers/usb/misc/Makefile b/drivers/usb/misc/Makefile
index 5f4e598573ab..fbb9adf08f8c 100644
--- a/drivers/usb/misc/Makefile
+++ b/drivers/usb/misc/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_USB_YUREX) += yurex.o
obj-$(CONFIG_USB_HUB_USB251XB) += usb251xb.o
obj-$(CONFIG_USB_HSIC_USB3503) += usb3503.o
obj-$(CONFIG_USB_HSIC_USB4604) += usb4604.o
+obj-$(CONFIG_USB_HUB_USB5744) += usb5744.o
obj-$(CONFIG_USB_CHAOSKEY) += chaoskey.o
obj-$(CONFIG_USB_SISUSBVGA)+= sisusbvga/
diff --git a/drivers/usb/misc/usb5744.c b/drivers/usb/misc/usb5744.c
new file mode 100644
index ..729b76345c69
--- /dev/null
+++ b/drivers/usb/misc/usb5744.c
@@ -0,0 +1,115 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Driver for the Microchip USB5744 4-port hub.
+ *
+ * Copyright (c) 2021 Xilinx, Inc.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static int usb5744_init_hw(struct device *dev)
+{
+ struct gpio_desc *reset_gpio;
+
+ reset_gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
+ if (IS_ERR(reset_gpio)) {
+ dev_err(dev, "Failed to bind reset gpio");
+ return -ENODEV;
+ }
+
+ if (reset_gpio) {
+ /* Toggle RESET_N to reset the hub. */
+ gpiod_set_value(reset_gpio, 0);
+ usleep_range(5, 20); /* trstia */
+ gpiod_set_value(reset_gpio, 1);
+ usleep_range(5000, 1); /* tcsh */
+ }
+
+ return 0;
+}
+
+static int usb5744_i2c_probe(struct i2c_client *client,
+const struct i2c_device_id *id)
+{
+ struct device *dev = >dev;
+ int ret;
+
+ /* Trigger gpio reset to the hub. */
+ ret = usb5744_init_hw(dev);
+ if (ret)
+ return ret;
+
+ /* Send SMBus command to boot hub. */
+ ret = i2c_smbus_write_word_data(client, 0xAA, swab16(0x5600));
+ if (ret < 0)
+ dev_err(dev, "Sending boot command failed");
+
+ return ret;
+}
+
+static int usb5744_platform_probe(struct platform_device *pdev)
+{
+ /* Trigger gpio reset to the hub. */
+ return usb5744_init_hw(>dev);
+}
+
+static const struct i2c_device_id usb5744_id[] = {
+ { "usb5744", 0 },
+ {}
+};
+MODULE_DEVICE_TABLE(i2c, usb5744_id);
+
+static struct i2c_driver usb5744_i2c_driver = {
+ .driver = {
+ .name = "usb5744",
+ },
+ .probe = usb5744_i2c_probe,
+ .id_table = usb5744_id,
+};
+
+static const struct of_device_id usb5744_platform_id[] = {
+ { .compatible = "microchip,usb5744", },
+ { }
+};
+
+static struct platform_driver usb5744_platform_driver = {
+ .driver = {
+
[PATCH v2 1/2] dt-bindings: usb: misc: Add binding for Microchip usb5744 hub
From: Piyush Mehta
Added dt binding for usb5744 driver.
Signed-off-by: Piyush Mehta
Signed-off-by: Michal Simek
---
Changes in v2: None
.../bindings/usb/microchip,usb5744.yaml | 56 +++
MAINTAINERS | 1 +
2 files changed, 57 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/microchip,usb5744.yaml
diff --git a/Documentation/devicetree/bindings/usb/microchip,usb5744.yaml
b/Documentation/devicetree/bindings/usb/microchip,usb5744.yaml
new file mode 100644
index ..fe222f6db81d
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/microchip,usb5744.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/usb/microchip,usb5744.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Bindings for the Microchip USB5744 4-port Hub Controller
+
+description:
+ Microchip’s USB5744 SmartHub™ IC is a 4 port, SuperSpeed (SS)/Hi-Speed (HS),
+ low power, low pin count configurable and fully compliant with the USB 3.1
+ Gen 1 specification. The USB5744 also supports Full Speed (FS) and Low Speed
+ (LS) USB signaling, offering complete coverage of all defined USB operating
+ speeds. The new SuperSpeed hubs operate in parallel with the USB 2.0
+ controller, so 5 Gbps SuperSpeed data transfers are not affected by slower
+ USB 2.0 traffic.
+
+maintainers:
+ - Piyush Mehta
+ - Michal Simek
+
+properties:
+ compatible:
+const: microchip,usb5744
+
+ reg:
+maxItems: 1
+description: |
+ Specifies the i2c slave address, it is required and should be 0x2d
+ if I2C is used.
+
+ reset-gpios:
+maxItems: 1
+description:
+ The phandle and specifier for the GPIO that controls the RESET line of
+ USB hub.
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+usb5744@2d {
+compatible = "microchip,usb5744";
+reg = <0x2d>;
+reset-gpios = < 44 GPIO_ACTIVE_HIGH>;
+};
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index 41e8d3d7faec..7439471b5d37 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2697,6 +2697,7 @@ W:http://wiki.xilinx.com
T: git https://github.com/Xilinx/linux-xlnx.git
F: Documentation/devicetree/bindings/i2c/cdns,i2c-r1p10.yaml
F: Documentation/devicetree/bindings/i2c/xlnx,xps-iic-2.00.a.yaml
+F: Documentation/devicetree/bindings/usb/microchip,usb5744.yaml
F: arch/arm/mach-zynq/
F: drivers/block/xsysace.c
F: drivers/clocksource/timer-cadence-ttc.c
--
2.30.0
[PATCH v2 0/2] usb: misc: Add support for Microchip USB5744
Hi, the series is adding basic support for this USB hub. The key part is running reset over GPIO line and when i2c is connected it is necessary to send command to boot the hub. This chip is available on Xilinx zcu100/Ultra96 v1 board. Thanks, Michal Changes in v2: - s/USB_USB5744/USB_HUB_USB5744/g - Fix order in Makefile and Kconfig Piyush Mehta (2): dt-bindings: usb: misc: Add binding for Microchip usb5744 hub usb: misc: usb5744: Add support for USB hub controller .../bindings/usb/microchip,usb5744.yaml | 56 + MAINTAINERS | 2 + drivers/usb/misc/Kconfig | 9 ++ drivers/usb/misc/Makefile | 1 + drivers/usb/misc/usb5744.c| 115 ++ 5 files changed, 183 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/microchip,usb5744.yaml create mode 100644 drivers/usb/misc/usb5744.c -- 2.30.0
Re: [PATCH 2/2] usb: misc: usb5744: Add support for USB hub controller
On 2/9/21 11:03 AM, Greg Kroah-Hartman wrote: > On Tue, Feb 09, 2021 at 10:53:20AM +0100, Michal Simek wrote: >> From: Piyush Mehta >> >> This patch adds a USB GPIO based hub reset for USB5744 hub. This usb5744 >> driver trigger hub reset signal after soft reset or core Reset. The HUB >> needs to be resetted after completion of phy initialization. After the >> toggling of gpio, hub configure using i2c usb attached command. >> >> USB5744 hub can be used without any I2C connection, is handled by a >> simple platform device driver. >> >> As part of the reset, sets the direction of the pin to output before >> toggling the pin. Delay of millisecond is added in between low and >> high to meet the setup and hold time requirement of the reset. >> >> Signed-off-by: Piyush Mehta >> Signed-off-by: Michal Simek >> --- >> >> MAINTAINERS| 1 + >> drivers/usb/misc/Kconfig | 9 +++ >> drivers/usb/misc/Makefile | 1 + >> drivers/usb/misc/usb5744.c | 115 + >> 4 files changed, 126 insertions(+) >> create mode 100644 drivers/usb/misc/usb5744.c >> >> diff --git a/MAINTAINERS b/MAINTAINERS >> index 7439471b5d37..56d1fcdd24f6 100644 >> --- a/MAINTAINERS >> +++ b/MAINTAINERS >> @@ -2706,6 +2706,7 @@ F: drivers/edac/synopsys_edac.c >> F: drivers/i2c/busses/i2c-cadence.c >> F: drivers/i2c/busses/i2c-xiic.c >> F: drivers/mmc/host/sdhci-of-arasan.c >> +F: drivers/usb/misc/usb5744.c >> N: zynq >> N: xilinx >> >> diff --git a/drivers/usb/misc/Kconfig b/drivers/usb/misc/Kconfig >> index 8f1144359012..30335b5c4f88 100644 >> --- a/drivers/usb/misc/Kconfig >> +++ b/drivers/usb/misc/Kconfig >> @@ -242,6 +242,15 @@ config USB_HUB_USB251XB >>parameters may be set in devicetree or platform data. >>Say Y or M here if you need to configure such a device via SMBus. >> >> +config USB_USB5744 >> +tristate "Microchip USB5744 Hub driver" >> +depends on I2C >> +depends on GPIOLIB >> +help >> + This option enables support for Microchip USB5744 Hub. This driver >> + optionally reset the hub using gpio pin and configure hub via i2c if >> + connected. >> + >> config USB_HSIC_USB3503 >> tristate "USB3503 HSIC to USB20 Driver" >> depends on I2C >> diff --git a/drivers/usb/misc/Makefile b/drivers/usb/misc/Makefile >> index 5f4e598573ab..5920146a506a 100644 >> --- a/drivers/usb/misc/Makefile >> +++ b/drivers/usb/misc/Makefile >> @@ -25,6 +25,7 @@ obj-$(CONFIG_USB_USS720) += uss720.o >> obj-$(CONFIG_USB_SEVSEG)+= usbsevseg.o >> obj-$(CONFIG_USB_YUREX) += yurex.o >> obj-$(CONFIG_USB_HUB_USB251XB) += usb251xb.o >> +obj-$(CONFIG_USB_USB5744) += usb5744.o > > Can you follow the convention of the config options we have already, and > make this USB_HUB_USB5744 please? Sure. > >> obj-$(CONFIG_USB_HSIC_USB3503) += usb3503.o >> obj-$(CONFIG_USB_HSIC_USB4604) += usb4604.o > > And then put it in sorted order :) Do you want me to sort the whole Makefile and Kconfig as separate patch? It is pretty much unsorted now. And any other problem with the driver itself? Thanks, Michal
[PATCH 2/2] usb: misc: usb5744: Add support for USB hub controller
From: Piyush Mehta
This patch adds a USB GPIO based hub reset for USB5744 hub. This usb5744
driver trigger hub reset signal after soft reset or core Reset. The HUB
needs to be resetted after completion of phy initialization. After the
toggling of gpio, hub configure using i2c usb attached command.
USB5744 hub can be used without any I2C connection, is handled by a
simple platform device driver.
As part of the reset, sets the direction of the pin to output before
toggling the pin. Delay of millisecond is added in between low and
high to meet the setup and hold time requirement of the reset.
Signed-off-by: Piyush Mehta
Signed-off-by: Michal Simek
---
MAINTAINERS| 1 +
drivers/usb/misc/Kconfig | 9 +++
drivers/usb/misc/Makefile | 1 +
drivers/usb/misc/usb5744.c | 115 +
4 files changed, 126 insertions(+)
create mode 100644 drivers/usb/misc/usb5744.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 7439471b5d37..56d1fcdd24f6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2706,6 +2706,7 @@ F:drivers/edac/synopsys_edac.c
F: drivers/i2c/busses/i2c-cadence.c
F: drivers/i2c/busses/i2c-xiic.c
F: drivers/mmc/host/sdhci-of-arasan.c
+F: drivers/usb/misc/usb5744.c
N: zynq
N: xilinx
diff --git a/drivers/usb/misc/Kconfig b/drivers/usb/misc/Kconfig
index 8f1144359012..30335b5c4f88 100644
--- a/drivers/usb/misc/Kconfig
+++ b/drivers/usb/misc/Kconfig
@@ -242,6 +242,15 @@ config USB_HUB_USB251XB
parameters may be set in devicetree or platform data.
Say Y or M here if you need to configure such a device via SMBus.
+config USB_USB5744
+ tristate "Microchip USB5744 Hub driver"
+ depends on I2C
+ depends on GPIOLIB
+ help
+ This option enables support for Microchip USB5744 Hub. This driver
+ optionally reset the hub using gpio pin and configure hub via i2c if
+ connected.
+
config USB_HSIC_USB3503
tristate "USB3503 HSIC to USB20 Driver"
depends on I2C
diff --git a/drivers/usb/misc/Makefile b/drivers/usb/misc/Makefile
index 5f4e598573ab..5920146a506a 100644
--- a/drivers/usb/misc/Makefile
+++ b/drivers/usb/misc/Makefile
@@ -25,6 +25,7 @@ obj-$(CONFIG_USB_USS720) += uss720.o
obj-$(CONFIG_USB_SEVSEG) += usbsevseg.o
obj-$(CONFIG_USB_YUREX)+= yurex.o
obj-$(CONFIG_USB_HUB_USB251XB) += usb251xb.o
+obj-$(CONFIG_USB_USB5744) += usb5744.o
obj-$(CONFIG_USB_HSIC_USB3503) += usb3503.o
obj-$(CONFIG_USB_HSIC_USB4604) += usb4604.o
obj-$(CONFIG_USB_CHAOSKEY) += chaoskey.o
diff --git a/drivers/usb/misc/usb5744.c b/drivers/usb/misc/usb5744.c
new file mode 100644
index ..729b76345c69
--- /dev/null
+++ b/drivers/usb/misc/usb5744.c
@@ -0,0 +1,115 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Driver for the Microchip USB5744 4-port hub.
+ *
+ * Copyright (c) 2021 Xilinx, Inc.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static int usb5744_init_hw(struct device *dev)
+{
+ struct gpio_desc *reset_gpio;
+
+ reset_gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
+ if (IS_ERR(reset_gpio)) {
+ dev_err(dev, "Failed to bind reset gpio");
+ return -ENODEV;
+ }
+
+ if (reset_gpio) {
+ /* Toggle RESET_N to reset the hub. */
+ gpiod_set_value(reset_gpio, 0);
+ usleep_range(5, 20); /* trstia */
+ gpiod_set_value(reset_gpio, 1);
+ usleep_range(5000, 1); /* tcsh */
+ }
+
+ return 0;
+}
+
+static int usb5744_i2c_probe(struct i2c_client *client,
+const struct i2c_device_id *id)
+{
+ struct device *dev = >dev;
+ int ret;
+
+ /* Trigger gpio reset to the hub. */
+ ret = usb5744_init_hw(dev);
+ if (ret)
+ return ret;
+
+ /* Send SMBus command to boot hub. */
+ ret = i2c_smbus_write_word_data(client, 0xAA, swab16(0x5600));
+ if (ret < 0)
+ dev_err(dev, "Sending boot command failed");
+
+ return ret;
+}
+
+static int usb5744_platform_probe(struct platform_device *pdev)
+{
+ /* Trigger gpio reset to the hub. */
+ return usb5744_init_hw(>dev);
+}
+
+static const struct i2c_device_id usb5744_id[] = {
+ { "usb5744", 0 },
+ {}
+};
+MODULE_DEVICE_TABLE(i2c, usb5744_id);
+
+static struct i2c_driver usb5744_i2c_driver = {
+ .driver = {
+ .name = "usb5744",
+ },
+ .probe = usb5744_i2c_probe,
+ .id_table = usb5744_id,
+};
+
+static const struct of_device_id usb5744_platform_id[] = {
+ { .compatible = "microchip,usb5744", },
+ { }
+};
+
+static struct platform_driver usb5744_platform_driver = {
+
[PATCH 1/2] dt-bindings: usb: misc: Add binding for Microchip usb5744 hub
From: Piyush Mehta
Added dt binding for usb5744 driver.
Signed-off-by: Piyush Mehta
Signed-off-by: Michal Simek
---
.../bindings/usb/microchip,usb5744.yaml | 56 +++
MAINTAINERS | 1 +
2 files changed, 57 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/microchip,usb5744.yaml
diff --git a/Documentation/devicetree/bindings/usb/microchip,usb5744.yaml
b/Documentation/devicetree/bindings/usb/microchip,usb5744.yaml
new file mode 100644
index ..fe222f6db81d
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/microchip,usb5744.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/usb/microchip,usb5744.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Bindings for the Microchip USB5744 4-port Hub Controller
+
+description:
+ Microchip’s USB5744 SmartHub™ IC is a 4 port, SuperSpeed (SS)/Hi-Speed (HS),
+ low power, low pin count configurable and fully compliant with the USB 3.1
+ Gen 1 specification. The USB5744 also supports Full Speed (FS) and Low Speed
+ (LS) USB signaling, offering complete coverage of all defined USB operating
+ speeds. The new SuperSpeed hubs operate in parallel with the USB 2.0
+ controller, so 5 Gbps SuperSpeed data transfers are not affected by slower
+ USB 2.0 traffic.
+
+maintainers:
+ - Piyush Mehta
+ - Michal Simek
+
+properties:
+ compatible:
+const: microchip,usb5744
+
+ reg:
+maxItems: 1
+description: |
+ Specifies the i2c slave address, it is required and should be 0x2d
+ if I2C is used.
+
+ reset-gpios:
+maxItems: 1
+description:
+ The phandle and specifier for the GPIO that controls the RESET line of
+ USB hub.
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+usb5744@2d {
+compatible = "microchip,usb5744";
+reg = <0x2d>;
+reset-gpios = < 44 GPIO_ACTIVE_HIGH>;
+};
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index 41e8d3d7faec..7439471b5d37 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2697,6 +2697,7 @@ W:http://wiki.xilinx.com
T: git https://github.com/Xilinx/linux-xlnx.git
F: Documentation/devicetree/bindings/i2c/cdns,i2c-r1p10.yaml
F: Documentation/devicetree/bindings/i2c/xlnx,xps-iic-2.00.a.yaml
+F: Documentation/devicetree/bindings/usb/microchip,usb5744.yaml
F: arch/arm/mach-zynq/
F: drivers/block/xsysace.c
F: drivers/clocksource/timer-cadence-ttc.c
--
2.30.0
[PATCH 0/2] usb: misc: Add support for Microchip USB5744
Hi, the series is adding basic support for this USB hub. The key part is running reset over GPIO line and when i2c is connected it is necessary to send command to boot the hub. This chip is available on Xilinx zcu100/Ultra96 v1 board. Thanks, Michal Piyush Mehta (2): dt-bindings: usb: misc: Add binding for Microchip usb5744 hub usb: misc: usb5744: Add support for USB hub controller .../bindings/usb/microchip,usb5744.yaml | 56 + MAINTAINERS | 2 + drivers/usb/misc/Kconfig | 9 ++ drivers/usb/misc/Makefile | 1 + drivers/usb/misc/usb5744.c| 115 ++ 5 files changed, 183 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/microchip,usb5744.yaml create mode 100644 drivers/usb/misc/usb5744.c -- 2.30.0
[PATCH] fpga: xilinx-pr-decoupler: Simplify code by using dev_err_probe()
Use already prepared dev_err_probe() introduced by commit a787e5400a1c
("driver core: add device probe log helper").
It simplifies EPROBE_DEFER handling.
Signed-off-by: Michal Simek
---
drivers/fpga/xilinx-pr-decoupler.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/fpga/xilinx-pr-decoupler.c
b/drivers/fpga/xilinx-pr-decoupler.c
index 7d69af230567..b0eaf26af6e7 100644
--- a/drivers/fpga/xilinx-pr-decoupler.c
+++ b/drivers/fpga/xilinx-pr-decoupler.c
@@ -100,11 +100,9 @@ static int xlnx_pr_decoupler_probe(struct platform_device
*pdev)
return PTR_ERR(priv->io_base);
priv->clk = devm_clk_get(>dev, "aclk");
- if (IS_ERR(priv->clk)) {
- if (PTR_ERR(priv->clk) != -EPROBE_DEFER)
- dev_err(>dev, "input clock not found\n");
- return PTR_ERR(priv->clk);
- }
+ if (IS_ERR(priv->clk))
+ return dev_err_probe(>dev, PTR_ERR(priv->clk),
+"input clock not found\n");
err = clk_prepare_enable(priv->clk);
if (err) {
--
2.30.0
[PATCH] phy: zynqmp: Simplify code by using dev_err_probe()
Use already prepared dev_err_probe() introduced by commit a787e5400a1c
("driver core: add device probe log helper").
It simplifies EPROBE_DEFER handling.
Signed-off-by: Michal Simek
---
drivers/phy/xilinx/phy-zynqmp.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/phy/xilinx/phy-zynqmp.c b/drivers/phy/xilinx/phy-zynqmp.c
index 2b0f921b6ee3..2b65f84a5f89 100644
--- a/drivers/phy/xilinx/phy-zynqmp.c
+++ b/drivers/phy/xilinx/phy-zynqmp.c
@@ -874,13 +874,10 @@ static int xpsgtr_get_ref_clocks(struct xpsgtr_dev
*gtr_dev)
snprintf(name, sizeof(name), "ref%u", refclk);
clk = devm_clk_get_optional(gtr_dev->dev, name);
- if (IS_ERR(clk)) {
- if (PTR_ERR(clk) != -EPROBE_DEFER)
- dev_err(gtr_dev->dev,
- "Failed to get reference clock %u:
%ld\n",
- refclk, PTR_ERR(clk));
- return PTR_ERR(clk);
- }
+ if (IS_ERR(clk))
+ return dev_err_probe(gtr_dev->dev, PTR_ERR(clk),
+"Failed to get reference clock
%u\n",
+refclk);
if (!clk)
continue;
--
2.30.0
Re: [PATCH] fpga: fpga-mgr: xilinx-spi: fix error messages on -EPROBE_DEFER
Hi,
On 2/4/21 1:13 PM, Luca Ceresoli wrote:
> The current code produces an error message on devm_gpiod_get() errors even
> when the error is -EPROBE_DEFER, which should be silent.
>
> This has been observed producing a significant amount of messages like:
>
> xlnx-slave-spi spi1.1: Failed to get PROGRAM_B gpio: -517
>
> Fix and simplify code by using the dev_err_probe() helper function.
>
> Signed-off-by: Luca Ceresoli
> Fixes: dd2784c01d93 ("fpga manager: xilinx-spi: check INIT_B pin during
> write_init")
> Fixes: 061c97d13f1a ("fpga manager: Add Xilinx slave serial SPI driver")
> ---
> drivers/fpga/xilinx-spi.c | 24 +---
> 1 file changed, 9 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/fpga/xilinx-spi.c b/drivers/fpga/xilinx-spi.c
> index 27defa98092d..fee4d0abf6bf 100644
> --- a/drivers/fpga/xilinx-spi.c
> +++ b/drivers/fpga/xilinx-spi.c
> @@ -233,25 +233,19 @@ static int xilinx_spi_probe(struct spi_device *spi)
>
> /* PROGRAM_B is active low */
> conf->prog_b = devm_gpiod_get(>dev, "prog_b", GPIOD_OUT_LOW);
> - if (IS_ERR(conf->prog_b)) {
> - dev_err(>dev, "Failed to get PROGRAM_B gpio: %ld\n",
> - PTR_ERR(conf->prog_b));
> - return PTR_ERR(conf->prog_b);
> - }
> + if (IS_ERR(conf->prog_b))
> + return dev_err_probe(>dev, PTR_ERR(conf->prog_b),
> + "Failed to get PROGRAM_B gpio\n");
>
> conf->init_b = devm_gpiod_get_optional(>dev, "init-b", GPIOD_IN);
> - if (IS_ERR(conf->init_b)) {
> - dev_err(>dev, "Failed to get INIT_B gpio: %ld\n",
> - PTR_ERR(conf->init_b));
> - return PTR_ERR(conf->init_b);
> - }
> + if (IS_ERR(conf->init_b))
> + return dev_err_probe(>dev, PTR_ERR(conf->init_b),
> + "Failed to get INIT_B gpio\n");
>
> conf->done = devm_gpiod_get(>dev, "done", GPIOD_IN);
> - if (IS_ERR(conf->done)) {
> - dev_err(>dev, "Failed to get DONE gpio: %ld\n",
> - PTR_ERR(conf->done));
> - return PTR_ERR(conf->done);
> - }
> + if (IS_ERR(conf->done))
> + return dev_err_probe(>dev, PTR_ERR(conf->done),
> + "Failed to get DONE gpio\n");
>
> mgr = devm_fpga_mgr_create(>dev,
> "Xilinx Slave Serial FPGA Manager",
>
Acked-by: Michal Simek
Thanks,
Michal
[PATCH] can: xilinx_can: Simplify code by using dev_err_probe()
Use already prepared dev_err_probe() introduced by commit a787e5400a1c
("driver core: add device probe log helper").
It simplifies EPROBE_DEFER handling.
Also unify message format for similar error cases.
Signed-off-by: Michal Simek
---
drivers/net/can/xilinx_can.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/net/can/xilinx_can.c b/drivers/net/can/xilinx_can.c
index 37fa19c62d73..3b883e607d8b 100644
--- a/drivers/net/can/xilinx_can.c
+++ b/drivers/net/can/xilinx_can.c
@@ -1772,17 +1772,15 @@ static int xcan_probe(struct platform_device *pdev)
/* Getting the CAN can_clk info */
priv->can_clk = devm_clk_get(>dev, "can_clk");
if (IS_ERR(priv->can_clk)) {
- if (PTR_ERR(priv->can_clk) != -EPROBE_DEFER)
- dev_err(>dev, "Device clock not found.\n");
- ret = PTR_ERR(priv->can_clk);
+ ret = dev_err_probe(>dev, PTR_ERR(priv->can_clk),
+ "device clock not found\n");
goto err_free;
}
priv->bus_clk = devm_clk_get(>dev, devtype->bus_clk_name);
if (IS_ERR(priv->bus_clk)) {
- if (PTR_ERR(priv->bus_clk) != -EPROBE_DEFER)
- dev_err(>dev, "bus clock not found\n");
- ret = PTR_ERR(priv->bus_clk);
+ ret = dev_err_probe(>dev, PTR_ERR(priv->bus_clk),
+ "bus clock not found\n");
goto err_free;
}
--
2.30.0
Re: [PATCH] ARM: dts: zynq: Add address-cells property to interrupt controllers
On 2/3/21 3:12 PM, Rob Herring wrote:
> On Wed, Feb 3, 2021 at 1:01 AM Michal Simek wrote:
>>
>>
>>
>> On 2/1/21 6:41 PM, Rob Herring wrote:
>>> On Mon, Feb 1, 2021 at 8:27 AM Michal Simek wrote:
>>>>
>>>> The commit 3eb619b2f7d8 ("scripts/dtc: Update to upstream version
>>>> v1.6.0-11-g9d7888cbf19c") updated dtc version which also contained DTC
>>>> commit
>>>> "81e0919a3e21 checks: Add interrupt provider test"
>>>> where reasons for this checking are mentioned as
>>>> "A missing #address-cells property is less critical, but creates
>>>> ambiguities when used in interrupt-map properties, so warn about this as
>>>> well now."
>>>>
>>>> Add address-cells property to gic and gpio nodes to get rid of this
>>>> warning.
>>>> The similar change has been done for ZynqMP too.
>>>
>>> FYI, we're going to make this check dependent on having an
>>> interrupt-map property. So adding these isn't necessary.
>>
>> Good to know. Is there going to be report if interrupt-map doesn't
>> exist? Which can end up with reverting these changes?
>
> You mean a warning if '#address-cells' is present and interrupt-map is
> not? No, that would cause lots of warnings.
yep. What's the timeline for this? I mean I want to get to state that
all current warnings are gone that it will be much easier to add stuff
which we have in soc tree.
Thanks,
Michal
[PATCH] firmware: xilinx: Use explicit values for all enum values
Based on discussion at
https://lore.kernel.org/r/20200318125003.ga2727...@kroah.com we got
recommendation to use explicit values for all enum values.
The patch is following this recommendation.
Signed-off-by: Michal Simek
---
Based on
https://lore.kernel.org/r/86e94593a29a1b5b1958c539a1bfabdd08c0948e.1610959734.git.michal.si...@xilinx.com
which is already merged to char-misc-next
---
include/linux/firmware/xlnx-zynqmp.h | 338 +--
1 file changed, 169 insertions(+), 169 deletions(-)
diff --git a/include/linux/firmware/xlnx-zynqmp.h
b/include/linux/firmware/xlnx-zynqmp.h
index 0a483249ff30..71177b17eee5 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -64,25 +64,25 @@ enum pm_api_id {
PM_GET_API_VERSION = 1,
PM_SYSTEM_SHUTDOWN = 12,
PM_REQUEST_NODE = 13,
- PM_RELEASE_NODE,
- PM_SET_REQUIREMENT,
+ PM_RELEASE_NODE = 14,
+ PM_SET_REQUIREMENT = 15,
PM_RESET_ASSERT = 17,
- PM_RESET_GET_STATUS,
+ PM_RESET_GET_STATUS = 18,
PM_PM_INIT_FINALIZE = 21,
- PM_FPGA_LOAD,
- PM_FPGA_GET_STATUS,
+ PM_FPGA_LOAD = 22,
+ PM_FPGA_GET_STATUS = 23,
PM_GET_CHIPID = 24,
PM_IOCTL = 34,
- PM_QUERY_DATA,
- PM_CLOCK_ENABLE,
- PM_CLOCK_DISABLE,
- PM_CLOCK_GETSTATE,
- PM_CLOCK_SETDIVIDER,
- PM_CLOCK_GETDIVIDER,
- PM_CLOCK_SETRATE,
- PM_CLOCK_GETRATE,
- PM_CLOCK_SETPARENT,
- PM_CLOCK_GETPARENT,
+ PM_QUERY_DATA = 35,
+ PM_CLOCK_ENABLE = 36,
+ PM_CLOCK_DISABLE = 37,
+ PM_CLOCK_GETSTATE = 38,
+ PM_CLOCK_SETDIVIDER = 39,
+ PM_CLOCK_GETDIVIDER = 40,
+ PM_CLOCK_SETRATE = 41,
+ PM_CLOCK_GETRATE = 42,
+ PM_CLOCK_SETPARENT = 43,
+ PM_CLOCK_GETPARENT = 44,
PM_SECURE_AES = 47,
PM_FEATURE_CHECK = 63,
};
@@ -92,21 +92,21 @@ enum pm_ret_status {
XST_PM_SUCCESS = 0,
XST_PM_NO_FEATURE = 19,
XST_PM_INTERNAL = 2000,
- XST_PM_CONFLICT,
- XST_PM_NO_ACCESS,
- XST_PM_INVALID_NODE,
- XST_PM_DOUBLE_REQ,
- XST_PM_ABORT_SUSPEND,
+ XST_PM_CONFLICT = 2001,
+ XST_PM_NO_ACCESS = 2002,
+ XST_PM_INVALID_NODE = 2003,
+ XST_PM_DOUBLE_REQ = 2004,
+ XST_PM_ABORT_SUSPEND = 2005,
XST_PM_MULT_USER = 2008,
};
enum pm_ioctl_id {
IOCTL_SD_DLL_RESET = 6,
- IOCTL_SET_SD_TAPDELAY,
- IOCTL_SET_PLL_FRAC_MODE,
- IOCTL_GET_PLL_FRAC_MODE,
- IOCTL_SET_PLL_FRAC_DATA,
- IOCTL_GET_PLL_FRAC_DATA,
+ IOCTL_SET_SD_TAPDELAY = 7,
+ IOCTL_SET_PLL_FRAC_MODE = 8,
+ IOCTL_GET_PLL_FRAC_MODE = 9,
+ IOCTL_SET_PLL_FRAC_DATA = 10,
+ IOCTL_GET_PLL_FRAC_DATA = 11,
IOCTL_WRITE_GGS = 12,
IOCTL_READ_GGS = 13,
IOCTL_WRITE_PGGS = 14,
@@ -116,185 +116,185 @@ enum pm_ioctl_id {
};
enum pm_query_id {
- PM_QID_INVALID,
- PM_QID_CLOCK_GET_NAME,
- PM_QID_CLOCK_GET_TOPOLOGY,
- PM_QID_CLOCK_GET_FIXEDFACTOR_PARAMS,
- PM_QID_CLOCK_GET_PARENTS,
- PM_QID_CLOCK_GET_ATTRIBUTES,
+ PM_QID_INVALID = 0,
+ PM_QID_CLOCK_GET_NAME = 1,
+ PM_QID_CLOCK_GET_TOPOLOGY = 2,
+ PM_QID_CLOCK_GET_FIXEDFACTOR_PARAMS = 3,
+ PM_QID_CLOCK_GET_PARENTS = 4,
+ PM_QID_CLOCK_GET_ATTRIBUTES = 5,
PM_QID_CLOCK_GET_NUM_CLOCKS = 12,
- PM_QID_CLOCK_GET_MAX_DIVISOR,
+ PM_QID_CLOCK_GET_MAX_DIVISOR = 13,
};
enum zynqmp_pm_reset_action {
- PM_RESET_ACTION_RELEASE,
- PM_RESET_ACTION_ASSERT,
- PM_RESET_ACTION_PULSE,
+ PM_RESET_ACTION_RELEASE = 0,
+ PM_RESET_ACTION_ASSERT = 1,
+ PM_RESET_ACTION_PULSE = 2,
};
enum zynqmp_pm_reset {
ZYNQMP_PM_RESET_START = 1000,
ZYNQMP_PM_RESET_PCIE_CFG = ZYNQMP_PM_RESET_START,
- ZYNQMP_PM_RESET_PCIE_BRIDGE,
- ZYNQMP_PM_RESET_PCIE_CTRL,
- ZYNQMP_PM_RESET_DP,
- ZYNQMP_PM_RESET_SWDT_CRF,
- ZYNQMP_PM_RESET_AFI_FM5,
- ZYNQMP_PM_RESET_AFI_FM4,
- ZYNQMP_PM_RESET_AFI_FM3,
- ZYNQMP_PM_RESET_AFI_FM2,
- ZYNQMP_PM_RESET_AFI_FM1,
- ZYNQMP_PM_RESET_AFI_FM0,
- ZYNQMP_PM_RESET_GDMA,
- ZYNQMP_PM_RESET_GPU_PP1,
- ZYNQMP_PM_RESET_GPU_PP0,
- ZYNQMP_PM_RESET_GPU,
- ZYNQMP_PM_RESET_GT,
- ZYNQMP_PM_RESET_SATA,
- ZYNQMP_PM_RESET_ACPU3_PWRON,
- ZYNQMP_PM_RESET_ACPU2_PWRON,
- ZYNQMP_PM_RESET_ACPU1_PWRON,
- ZYNQMP_PM_RESET_ACPU0_PWRON,
- ZYNQMP_PM_RESET_APU_L2,
- ZYNQMP_PM_RESET_ACPU3,
- ZYNQMP_PM_RESET_ACPU2,
- ZYNQMP_PM_RESET_ACPU1,
- ZYNQMP_PM_RESET_ACPU0,
- ZYNQMP_PM_RESET_DDR,
- ZYNQMP_PM_RESET_APM_FPD,
- ZYNQMP_PM_RESET_SOFT,
- ZYNQMP_PM_RESET_GEM0,
- ZYNQMP_PM_RESET_GEM1,
- ZYNQMP_PM_RESET_GEM2,
- ZYNQMP_PM_RESET_GEM3,
- ZYNQMP_PM_RESET_QSPI,
- ZYNQMP_PM_RESET_UART0
[PATCH] dt-bindings: spi: zynq: Convert Zynq QSPI binding to yaml
Convert spi-zynq-qspi.txt to yaml.
Signed-off-by: Michal Simek
---
.../devicetree/bindings/spi/spi-zynq-qspi.txt | 25
.../bindings/spi/xlnx,zynq-qspi.yaml | 59 +++
MAINTAINERS | 1 +
3 files changed, 60 insertions(+), 25 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/spi/spi-zynq-qspi.txt
create mode 100644 Documentation/devicetree/bindings/spi/xlnx,zynq-qspi.yaml
diff --git a/Documentation/devicetree/bindings/spi/spi-zynq-qspi.txt
b/Documentation/devicetree/bindings/spi/spi-zynq-qspi.txt
deleted file mode 100644
index 16b734ad3102..
--- a/Documentation/devicetree/bindings/spi/spi-zynq-qspi.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-Xilinx Zynq QSPI controller Device Tree Bindings
-
-Required properties:
-- compatible : Should be "xlnx,zynq-qspi-1.0".
-- reg : Physical base address and size of QSPI registers map.
-- interrupts : Property with a value describing the interrupt
- number.
-- clock-names : List of input clock names - "ref_clk", "pclk"
- (See clock bindings for details).
-- clocks : Clock phandles (see clock bindings for details).
-
-Optional properties:
-- num-cs : Number of chip selects used.
-
-Example:
- qspi: spi@e000d000 {
- compatible = "xlnx,zynq-qspi-1.0";
- reg = <0xe000d000 0x1000>;
- interrupt-parent = <>;
- interrupts = <0 19 4>;
- clock-names = "ref_clk", "pclk";
- clocks = < 10>, < 43>;
- num-cs = <1>;
- };
diff --git a/Documentation/devicetree/bindings/spi/xlnx,zynq-qspi.yaml
b/Documentation/devicetree/bindings/spi/xlnx,zynq-qspi.yaml
new file mode 100644
index ..03269a7433b3
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/xlnx,zynq-qspi.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/xlnx,zynq-qspi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xilinx Zynq QSPI controller
+
+description:
+ The Xilinx Zynq QSPI controller is used to access multi-bit serial flash
+ memory devices.
+
+allOf:
+ - $ref: "spi-controller.yaml#"
+
+maintainers:
+ - Michal Simek
+
+# Everything else is described in the common file
+properties:
+ compatible:
+const: xlnx,zynq-qspi-1.0
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ clocks:
+items:
+ - description: reference clock
+ - description: peripheral clock
+
+ clock-names:
+items:
+ - const: ref_clk
+ - const: pclk
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+additionalProperties: true
+
+examples:
+ - |
+spi@e000d000 {
+compatible = "xlnx,zynq-qspi-1.0";
+reg = <0xe000d000 0x1000>;
+interrupt-parent = <>;
+interrupts = <0 19 4>;
+clock-names = "ref_clk", "pclk";
+clocks = < 10>, < 43>;
+num-cs = <1>;
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index 546aa66428c9..e494b061dcd1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2766,6 +2766,7 @@ W:http://wiki.xilinx.com
T: git https://github.com/Xilinx/linux-xlnx.git
F: Documentation/devicetree/bindings/i2c/cdns,i2c-r1p10.yaml
F: Documentation/devicetree/bindings/i2c/xlnx,xps-iic-2.00.a.yaml
+F: Documentation/devicetree/bindings/spi/xlnx,zynq-qspi.yaml
F: arch/arm/mach-zynq/
F: drivers/block/xsysace.c
F: drivers/clocksource/timer-cadence-ttc.c
--
2.30.0
Re: [PATCH] ARM: dts: ebaz4205: add pinctrl entries for switches
On 2/1/21 2:30 PM, Michael Walle wrote:
> Add the pinctrl entries for the GPIOs which are connected to the
> push buttons on this board.
>
> Signed-off-by: Michael Walle
> ---
> arch/arm/boot/dts/zynq-ebaz4205.dts | 23 +++
> 1 file changed, 23 insertions(+)
>
> diff --git a/arch/arm/boot/dts/zynq-ebaz4205.dts
> b/arch/arm/boot/dts/zynq-ebaz4205.dts
> index e802d4ae8804..b0b836aedd76 100644
> --- a/arch/arm/boot/dts/zynq-ebaz4205.dts
> +++ b/arch/arm/boot/dts/zynq-ebaz4205.dts
> @@ -43,7 +43,30 @@
> };
> };
>
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_gpio0_default>;
> +};
> +
> {
> + pinctrl_gpio0_default: gpio0-default {
> + mux {
> + groups = "gpio0_20_grp", "gpio0_32_grp";
> + function = "gpio0";
> + };
> +
> + conf {
> + groups = "gpio0_20_grp", "gpio0_32_grp";
> + io-standard = <3>;
> + slew-rate = <0>;
> + };
> +
> + conf-pull-up {
> + pins = "MIO20", "MIO32";
> + bias-disable;
> + };
> + };
> +
> pinctrl_sdhci0_default: sdhci0-default {
> mux {
> groups = "sdio0_2_grp";
>
Applied.
M
Re: [PATCH] ARM: dts: zynq: Add address-cells property to interrupt controllers
On 2/1/21 6:41 PM, Rob Herring wrote:
> On Mon, Feb 1, 2021 at 8:27 AM Michal Simek wrote:
>>
>> The commit 3eb619b2f7d8 ("scripts/dtc: Update to upstream version
>> v1.6.0-11-g9d7888cbf19c") updated dtc version which also contained DTC
>> commit
>> "81e0919a3e21 checks: Add interrupt provider test"
>> where reasons for this checking are mentioned as
>> "A missing #address-cells property is less critical, but creates
>> ambiguities when used in interrupt-map properties, so warn about this as
>> well now."
>>
>> Add address-cells property to gic and gpio nodes to get rid of this warning.
>> The similar change has been done for ZynqMP too.
>
> FYI, we're going to make this check dependent on having an
> interrupt-map property. So adding these isn't necessary.
Good to know. Is there going to be report if interrupt-map doesn't
exist? Which can end up with reverting these changes?
Thanks,
Michal
Re: [PATCH v3 1/4] clk: axi-clkgen: replace ARCH dependencies with driver deps
On 2/1/21 4:12 PM, Alexandru Ardelean wrote: > The intent is to be able to run this driver to access the IP core in setups > where FPGA board is also connected via a PCIe bus. In such cases the number > of combinations explodes, where the host system can be an x86 with Xilinx > Zynq/ZynqMP/Microblaze board connected via PCIe. > Or even a ZynqMP board with a ZynqMP/Zynq/Microblaze connected via PCIe. > > To accommodate for these cases, this change removes the limitation for this > driver to be compilable only on Zynq/Microblaze architectures. > And adds dependencies on the mechanisms required by the driver to work (OF > and HAS_IOMEM). > > Signed-off-by: Dragos Bogdan > Signed-off-by: Alexandru Ardelean > --- > drivers/clk/Kconfig | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig > index 85856cff506c..cee1d4e657bc 100644 > --- a/drivers/clk/Kconfig > +++ b/drivers/clk/Kconfig > @@ -247,7 +247,8 @@ config CLK_TWL6040 > > config COMMON_CLK_AXI_CLKGEN > tristate "AXI clkgen driver" > - depends on ARCH_ZYNQ || MICROBLAZE || COMPILE_TEST > + depends on HAS_IOMEM || COMPILE_TEST > + depends on OF > help > Support for the Analog Devices axi-clkgen pcore clock generator for > Xilinx > FPGAs. It is commonly used in Analog Devices' reference designs. > Make sense. Acked-by: Michal Simek Thanks, Michal
[PATCH] ARM: zynq: Update Copyright date in DTS
Update years in header to be up2date.
Signed-off-by: Michal Simek
---
arch/arm/boot/dts/zynq-7000.dtsi | 2 +-
arch/arm/boot/dts/zynq-cc108.dts | 2 +-
arch/arm/boot/dts/zynq-zc702.dts | 2 +-
arch/arm/boot/dts/zynq-zc706.dts | 2 +-
arch/arm/boot/dts/zynq-zc770-xm010.dts | 2 +-
arch/arm/boot/dts/zynq-zc770-xm011.dts | 2 +-
arch/arm/boot/dts/zynq-zc770-xm012.dts | 2 +-
arch/arm/boot/dts/zynq-zc770-xm013.dts | 2 +-
arch/arm/boot/dts/zynq-zed.dts | 2 +-
arch/arm/boot/dts/zynq-zybo.dts| 2 +-
10 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/arm/boot/dts/zynq-7000.dtsi b/arch/arm/boot/dts/zynq-7000.dtsi
index c4810d58540b..d46c1e2652e7 100644
--- a/arch/arm/boot/dts/zynq-7000.dtsi
+++ b/arch/arm/boot/dts/zynq-7000.dtsi
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0
/*
- * Copyright (C) 2011 - 2014 Xilinx
+ * Copyright (C) 2011 - 2021 Xilinx
*/
/ {
diff --git a/arch/arm/boot/dts/zynq-cc108.dts b/arch/arm/boot/dts/zynq-cc108.dts
index 8b9ab9bba23b..33546e13bb46 100644
--- a/arch/arm/boot/dts/zynq-cc108.dts
+++ b/arch/arm/boot/dts/zynq-cc108.dts
@@ -2,7 +2,7 @@
/*
* Xilinx CC108 board DTS
*
- * (C) Copyright 2007-2018 Xilinx, Inc.
+ * (C) Copyright 2007-2021 Xilinx, Inc.
* (C) Copyright 2007-2013 Michal Simek
* (C) Copyright 2007-2012 PetaLogix Qld Pty Ltd
*
diff --git a/arch/arm/boot/dts/zynq-zc702.dts b/arch/arm/boot/dts/zynq-zc702.dts
index cf70aff26c66..a226498364af 100644
--- a/arch/arm/boot/dts/zynq-zc702.dts
+++ b/arch/arm/boot/dts/zynq-zc702.dts
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0
/*
- * Copyright (C) 2011 - 2014 Xilinx
+ * Copyright (C) 2011 - 2021 Xilinx
* Copyright (C) 2012 National Instruments Corp.
*/
/dts-v1/;
diff --git a/arch/arm/boot/dts/zynq-zc706.dts b/arch/arm/boot/dts/zynq-zc706.dts
index 77943c16d33f..73d8b7a78415 100644
--- a/arch/arm/boot/dts/zynq-zc706.dts
+++ b/arch/arm/boot/dts/zynq-zc706.dts
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0
/*
- * Copyright (C) 2011 - 2014 Xilinx
+ * Copyright (C) 2011 - 2021 Xilinx
* Copyright (C) 2012 National Instruments Corp.
*/
/dts-v1/;
diff --git a/arch/arm/boot/dts/zynq-zc770-xm010.dts
b/arch/arm/boot/dts/zynq-zc770-xm010.dts
index 0dd352289a45..e54a229b1f78 100644
--- a/arch/arm/boot/dts/zynq-zc770-xm010.dts
+++ b/arch/arm/boot/dts/zynq-zc770-xm010.dts
@@ -2,7 +2,7 @@
/*
* Xilinx ZC770 XM010 board DTS
*
- * Copyright (C) 2013-2018 Xilinx, Inc.
+ * Copyright (C) 2013-2021 Xilinx, Inc.
*/
/dts-v1/;
#include "zynq-7000.dtsi"
diff --git a/arch/arm/boot/dts/zynq-zc770-xm011.dts
b/arch/arm/boot/dts/zynq-zc770-xm011.dts
index 56732e8f6ca1..a4ce58e1e648 100644
--- a/arch/arm/boot/dts/zynq-zc770-xm011.dts
+++ b/arch/arm/boot/dts/zynq-zc770-xm011.dts
@@ -2,7 +2,7 @@
/*
* Xilinx ZC770 XM011 board DTS
*
- * Copyright (C) 2013-2018 Xilinx, Inc.
+ * Copyright (C) 2013-2021 Xilinx, Inc.
*/
/dts-v1/;
#include "zynq-7000.dtsi"
diff --git a/arch/arm/boot/dts/zynq-zc770-xm012.dts
b/arch/arm/boot/dts/zynq-zc770-xm012.dts
index d2359b789eb8..f842e7ad4f9d 100644
--- a/arch/arm/boot/dts/zynq-zc770-xm012.dts
+++ b/arch/arm/boot/dts/zynq-zc770-xm012.dts
@@ -2,7 +2,7 @@
/*
* Xilinx ZC770 XM012 board DTS
*
- * Copyright (C) 2013-2018 Xilinx, Inc.
+ * Copyright (C) 2013-2021 Xilinx, Inc.
*/
/dts-v1/;
#include "zynq-7000.dtsi"
diff --git a/arch/arm/boot/dts/zynq-zc770-xm013.dts
b/arch/arm/boot/dts/zynq-zc770-xm013.dts
index 38d96adc870c..fe4cd75bc9db 100644
--- a/arch/arm/boot/dts/zynq-zc770-xm013.dts
+++ b/arch/arm/boot/dts/zynq-zc770-xm013.dts
@@ -2,7 +2,7 @@
/*
* Xilinx ZC770 XM013 board DTS
*
- * Copyright (C) 2013 Xilinx, Inc.
+ * Copyright (C) 2013-2021 Xilinx, Inc.
*/
/dts-v1/;
#include "zynq-7000.dtsi"
diff --git a/arch/arm/boot/dts/zynq-zed.dts b/arch/arm/boot/dts/zynq-zed.dts
index 6a5a93aa6552..fd2b562d374d 100644
--- a/arch/arm/boot/dts/zynq-zed.dts
+++ b/arch/arm/boot/dts/zynq-zed.dts
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0
/*
- * Copyright (C) 2011 - 2014 Xilinx
+ * Copyright (C) 2011 - 2021 Xilinx
* Copyright (C) 2012 National Instruments Corp.
*/
/dts-v1/;
diff --git a/arch/arm/boot/dts/zynq-zybo.dts b/arch/arm/boot/dts/zynq-zybo.dts
index 755f6f109d5a..f163f9d69f80 100644
--- a/arch/arm/boot/dts/zynq-zybo.dts
+++ b/arch/arm/boot/dts/zynq-zybo.dts
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0
/*
- * Copyright (C) 2011 - 2014 Xilinx
+ * Copyright (C) 2011 - 2021 Xilinx
* Copyright (C) 2012 National Instruments Corp.
*/
/dts-v1/;
--
2.30.0
[PATCH] ARM: dts: zynq: Add address-cells property to interrupt controllers
The commit 3eb619b2f7d8 ("scripts/dtc: Update to upstream version
v1.6.0-11-g9d7888cbf19c") updated dtc version which also contained DTC
commit
"81e0919a3e21 checks: Add interrupt provider test"
where reasons for this checking are mentioned as
"A missing #address-cells property is less critical, but creates
ambiguities when used in interrupt-map properties, so warn about this as
well now."
Add address-cells property to gic and gpio nodes to get rid of this warning.
The similar change has been done for ZynqMP too.
CC: Andre Przywara
Signed-off-by: Michal Simek
---
arch/arm/boot/dts/zynq-7000.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/zynq-7000.dtsi b/arch/arm/boot/dts/zynq-7000.dtsi
index df9ad831cf05..c4810d58540b 100644
--- a/arch/arm/boot/dts/zynq-7000.dtsi
+++ b/arch/arm/boot/dts/zynq-7000.dtsi
@@ -133,6 +133,7 @@ can1: can@e0009000 {
gpio0: gpio@e000a000 {
compatible = "xlnx,zynq-gpio-1.0";
+ #address-cells = <0>;
#gpio-cells = <2>;
clocks = < 42>;
gpio-controller;
@@ -168,6 +169,7 @@ i2c1: i2c@e0005000 {
intc: interrupt-controller@f8f01000 {
compatible = "arm,cortex-a9-gic";
#interrupt-cells = <3>;
+ #address-cells = <0>;
interrupt-controller;
reg = <0xF8F01000 0x1000>,
<0xF8F00100 0x100>;
--
2.30.0
[PATCH] dt-bindings: arm: xilinx: Add missing Zturn boards
Add missing DT compatible strings for Zturn boards. Signed-off-by: Michal Simek --- Patches are based on https://lore.kernel.org/linux-arm-kernel/20210120194033.26970-3-mich...@walle.cc/ --- Documentation/devicetree/bindings/arm/xilinx.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/xilinx.yaml b/Documentation/devicetree/bindings/arm/xilinx.yaml index aaca69d0199f..05217537fb0c 100644 --- a/Documentation/devicetree/bindings/arm/xilinx.yaml +++ b/Documentation/devicetree/bindings/arm/xilinx.yaml @@ -23,6 +23,8 @@ properties: - digilent,zynq-zybo - digilent,zynq-zybo-z7 - ebang,ebaz4205 + - myir,zynq-zturn-v5 + - myir,zynq-zturn - xlnx,zynq-cc108 - xlnx,zynq-zc702 - xlnx,zynq-zc706 -- 2.30.0
Re: [PATCH] firmware: xilinx: Remove zynqmp_pm_get_eemi_ops() in IS_REACHABLE(CONFIG_ZYNQMP_FIRMWARE)
Hi,
On 1/31/21 3:30 PM, Nobuhiro Iwamatsu wrote:
> zynqmp_pm_get_eemi_ops() was removed in commit 4db8180ffe7c: "Firmware:
> xilinx:
> Remove eemi ops for fpga related APIs", but not in
> IS_REACHABLE(CONFIG_ZYNQMP_FIRMWARE).
> This removed zynqmp_pm_get_eemi_ops() in
> IS_REACHABLE(CONFIG_ZYNQMP_FIRMWARE), and also
> modify the documentation for this driver.
>
> Fixes: 4db8180ffe7c ("firmware: xilinx: Remove eemi ops for fpga related
> APIs")
> Signed-off-by: Nobuhiro Iwamatsu
> ---
> Documentation/driver-api/xilinx/eemi.rst | 27 +---
> include/linux/firmware/xlnx-zynqmp.h | 5 -
> 2 files changed, 1 insertion(+), 31 deletions(-)
>
> diff --git a/Documentation/driver-api/xilinx/eemi.rst
> b/Documentation/driver-api/xilinx/eemi.rst
> index 9dcbc6f18d75df..53416d25d309a8 100644
> --- a/Documentation/driver-api/xilinx/eemi.rst
> +++ b/Documentation/driver-api/xilinx/eemi.rst
> @@ -19,32 +19,7 @@ device to issue or respond to power management requests.
> EEMI ops is a structure containing all eemi APIs supported by Zynq MPSoC.
> The zynqmp-firmware driver maintain all EEMI APIs in zynqmp_eemi_ops
> structure. Any driver who want to communicate with PMC using EEMI APIs
The whole paragraph should be tuned. I would leave here just
"Any driver who want to communicate with PMC using EEMI APIs
use the functions provided for each function."
Because there is no reference to any eemi ops structure.
The rest looks good to me.
Thanks,
Michal
Re: [PATCH 0/3] arm64: dts: zynqmp: Enable and Wire DP
Hi, On 1/21/21 1:36 PM, Michal Simek wrote: > Hi, > > I am updating DT patches which were there part of DP v11 series sent by > Laurent in past [1]. Patches have been removed in v12 [2]. > The series is rebased on the top of [3] which wired si5341 clock chip. > > [1] > http://lore.kernel.org/r/20200318153728.25843-1-laurent.pinch...@ideasonboard.com > [2] > http://lore.kernel.org/r/20200718001347.25451-1-laurent.pinch...@ideasonboard.com > [3] http://lore.kernel.org/r/cover.1611224800.git.michal.si...@xilinx.com > > Thanks, > Michal > > > Laurent Pinchart (2): > arm64: dts: zynqmp: Add DPDMA node > arm64: dts: zynqmp: Wire up the DisplayPort subsystem > > Michal Simek (1): > arm64: dts: zynqmp: Add DisplayPort subsystem > > .../arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi | 10 ++ > .../boot/dts/xilinx/zynqmp-zcu100-revC.dts| 31 ++ > .../boot/dts/xilinx/zynqmp-zcu102-revA.dts| 10 ++ > .../boot/dts/xilinx/zynqmp-zcu104-revA.dts| 11 +++ > .../boot/dts/xilinx/zynqmp-zcu104-revC.dts| 11 +++ > .../boot/dts/xilinx/zynqmp-zcu106-revA.dts| 11 +++ > .../boot/dts/xilinx/zynqmp-zcu111-revA.dts| 11 +++ > arch/arm64/boot/dts/xilinx/zynqmp.dtsi| 32 +++++++ > 8 files changed, 127 insertions(+) > Applied all. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
Re: [PATCH] dt-bindings: arm: Fix typo in zcu111 board
On 1/21/21 11:56 AM, Michal Simek wrote: > Trivial fix. > > Signed-off-by: Michal Simek > --- > > Documentation/devicetree/bindings/arm/xilinx.yaml | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/arm/xilinx.yaml > b/Documentation/devicetree/bindings/arm/xilinx.yaml > index ae0ef1bf7965..97e77b4e077c 100644 > --- a/Documentation/devicetree/bindings/arm/xilinx.yaml > +++ b/Documentation/devicetree/bindings/arm/xilinx.yaml > @@ -108,7 +108,7 @@ properties: > items: >- enum: >- xlnx,zynqmp-zcu111-revA > - - xlnx,zynqmp-zcu11-rev1.0 > + - xlnx,zynqmp-zcu111-rev1.0 >- const: xlnx,zynqmp-zcu111 > - const: xlnx,zynqmp > > Applied. M -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
Re: [PATCH v2 12/12] arm64: dts: zynqmp: Add description for zcu104 revC
On 1/21/21 11:27 AM, Michal Simek wrote:
> Xilinx ZynqMP zcu104 revC and newer board revisions have different i2c
> structure compare to revA. The rest of the board is the same from software
> perspective.
> Also enable DMAs and QSPI.
>
> Signed-off-by: Michal Simek
> ---
>
> Changes in v2: None
>
> arch/arm64/boot/dts/xilinx/Makefile | 1 +
> .../boot/dts/xilinx/zynqmp-zcu104-revC.dts| 282 ++
> 2 files changed, 283 insertions(+)
> create mode 100644 arch/arm64/boot/dts/xilinx/zynqmp-zcu104-revC.dts
>
> diff --git a/arch/arm64/boot/dts/xilinx/Makefile
> b/arch/arm64/boot/dts/xilinx/Makefile
> index 60f5443f3ef4..11fb4fd3ebd4 100644
> --- a/arch/arm64/boot/dts/xilinx/Makefile
> +++ b/arch/arm64/boot/dts/xilinx/Makefile
> @@ -13,5 +13,6 @@ dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu102-revA.dtb
> dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu102-revB.dtb
> dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu102-rev1.0.dtb
> dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu104-revA.dtb
> +dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu104-revC.dtb
> dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu106-revA.dtb
> dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu111-revA.dtb
> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu104-revC.dts
> b/arch/arm64/boot/dts/xilinx/zynqmp-zcu104-revC.dts
> new file mode 100644
> index ..414f98f1831e
> --- /dev/null
> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu104-revC.dts
> @@ -0,0 +1,282 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * dts file for Xilinx ZynqMP ZCU104
> + *
> + * (C) Copyright 2017 - 2020, Xilinx, Inc.
> + *
> + * Michal Simek
> + */
> +
> +/dts-v1/;
> +
> +#include "zynqmp.dtsi"
> +#include "zynqmp-clk-ccf.dtsi"
> +#include
> +#include
> +
> +/ {
> + model = "ZynqMP ZCU104 RevC";
> + compatible = "xlnx,zynqmp-zcu104-revC", "xlnx,zynqmp-zcu104",
> "xlnx,zynqmp";
> +
> + aliases {
> + ethernet0 =
> + i2c0 =
> + mmc0 =
> + rtc0 =
> + serial0 =
> + serial1 =
> + serial2 =
> + };
> +
> + chosen {
> + bootargs = "earlycon";
> + stdout-path = "serial0:115200n8";
> + };
> +
> + memory@0 {
> + device_type = "memory";
> + reg = <0x0 0x0 0x0 0x8000>;
> + };
> +
> + ina226 {
> + compatible = "iio-hwmon";
> + io-channels = < 0>, < 1>, < 2>, < 3>;
> + };
> +
> + clock_8t49n287_5: clk125 {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <12500>;
> + };
> +
> + clock_8t49n287_2: clk26 {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <2600>;
> + };
> +
> + clock_8t49n287_3: clk27 {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <2700>;
> + };
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> +_dma_chan1 {
> + status = "okay";
> +};
> +
> +_dma_chan2 {
> + status = "okay";
> +};
> +
> +_dma_chan3 {
> + status = "okay";
> +};
> +
> +_dma_chan4 {
> + status = "okay";
> +};
> +
> +_dma_chan5 {
> + status = "okay";
> +};
> +
> +_dma_chan6 {
> + status = "okay";
> +};
> +
> +_dma_chan7 {
> + status = "okay";
> +};
> +
> +_dma_chan8 {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> + phy-handle = <>;
> + phy-mode = "rgmii-id";
> + phy0: ethernet-phy@c {
> + reg = <0xc>;
> + ti,rx-internal-delay = <0x8>;
> + ti,tx-internal-delay = <0xa>;
> + ti,fifo-depth = <0x1>;
> + ti,dp83867-rxctrl-strap-quirk;
> + };
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> + clock-frequency = <40>;
> +
> + tca6416_u97: gpio@20 {
> + compatible = "ti,tca6416";
> + reg = <0x20>;
> + gpio-controller;
Re: [PATCH v2 00/12] arm64: dts: zynqmp: DT updates to match latest drivers
On 1/21/21 11:26 AM, Michal Simek wrote: > Hi, > > I am sending this series to reflect the latest drivers which have been > merged to mainline kernel. I have boot it on zcu102-rev1.0 and also > zcu104-rev1.0. That's why I have also added DT for this newer revision. > > The series is based on https://github.com/Xilinx/linux-xlnx/tree/zynqmp/dt. > And mio-bank patch requires update in dt-binding which has been posted here > https://lore.kernel.org/r/5fa17dfe4b42abefd84b4cbb7b8bcd4d31398f40.1606914986.git.michal.si...@xilinx.com > > Thanks, > Michal > > Changes in v2: > - Remove reset description for IPs from this patch. IPs will be enabled > separately with DT binding update. > - Change patch subject > > Michal Simek (12): > arm64: dts: zynqmp: Fix u48 si5382 chip on zcu111 > arm64: dts: zynqmp: Add DT description for si5328 for zcu102/zcu106 > arm64: dts: zynqmp: Enable si5341 driver for zcu102/106/111 > arm64: dts: zynqmp: Enable reset controller driver > arm64: dts: zynqmp: Enable phy driver for Sata on zcu102/zcu104/zcu106 > arm64: dts: zynqmp: Add label for zynqmp_ipi > arm64: dts: zynqmp: Add missing mio-bank properties to sdhcis > arm64: dts: zynqmp: Wire arasan nand controller > arm64: dts: zynqmp: Wire zynqmp qspi controller > arm64: dts: zynqmp: Add missing lpd watchdog node > arm64: dts: zynqmp: Add missing iommu IDs > arm64: dts: zynqmp: Add description for zcu104 revC > > arch/arm64/boot/dts/xilinx/Makefile | 1 + > .../arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi | 12 + > .../boot/dts/xilinx/zynqmp-zcu100-revC.dts| 2 + > .../boot/dts/xilinx/zynqmp-zcu102-revA.dts| 84 +- > .../boot/dts/xilinx/zynqmp-zcu104-revA.dts| 29 ++ > .../boot/dts/xilinx/zynqmp-zcu104-revC.dts| 282 ++ > .../boot/dts/xilinx/zynqmp-zcu106-revA.dts| 78 + > .../boot/dts/xilinx/zynqmp-zcu111-revA.dts| 59 +++- > arch/arm64/boot/dts/xilinx/zynqmp.dtsi| 94 +- > 9 files changed, 637 insertions(+), 4 deletions(-) > create mode 100644 arch/arm64/boot/dts/xilinx/zynqmp-zcu104-revC.dts > Applied all. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
Re: [PATCH 1/1] MAINTAINERS: remove myself from the list
On 1/27/21 2:13 AM, Hyun Kwon wrote: > The email will become invalid soon. > > Signed-off-by: Hyun Kwon > Cc: Laurent Pinchart > Cc: Michal Simek > --- > MAINTAINERS | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 992fe3b0900a..4fc00c2da56d 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -6048,7 +6048,6 @@ F: Documentation/gpu/xen-front.rst > F: drivers/gpu/drm/xen/ > > DRM DRIVERS FOR XILINX > -M: Hyun Kwon > M: Laurent Pinchart > L: dri-de...@lists.freedesktop.org > S: Maintained > @@ -19577,7 +19576,6 @@ S:Maintained > F: drivers/tty/serial/uartlite.c > > XILINX VIDEO IP CORES > -M: Hyun Kwon > M: Laurent Pinchart > L: linux-me...@vger.kernel.org > S: Supported > @@ -19587,7 +19585,6 @@ F:drivers/media/platform/xilinx/ > F: include/uapi/linux/xilinx-v4l2-controls.h > > XILINX ZYNQMP DPDMA DRIVER > -M: Hyun Kwon > M: Laurent Pinchart > L: dmaeng...@vger.kernel.org > S: Supported > Acked-by: Michal Simek Laurent: Can you ask media maintainer to pick it up? Thanks, Michal
Re: [PATCH 3/3] fpga: versal-fpga: Add versal fpga manager driver
Hi On 1/27/21 9:57 AM, Nava kishore Manne wrote: > Hi Moritz, > > Please find my response inline. > >> -Original Message- >> From: Moritz Fischer >> Sent: Sunday, January 24, 2021 5:04 AM >> To: Nava kishore Manne >> Cc: Moritz Fischer ; t...@redhat.com; >> robh...@kernel.org; Michal Simek ; linux- >> f...@vger.kernel.org; devicet...@vger.kernel.org; linux-arm- >> ker...@lists.infradead.org; linux-kernel@vger.kernel.org; git >> ; chinnikishore...@gmail.com; Appana Durga Kedareswara >> Rao >> Subject: Re: [PATCH 3/3] fpga: versal-fpga: Add versal fpga manager driver >> >> Hi Nava, >> >> On Fri, Jan 22, 2021 at 10:34:15AM +, Nava kishore Manne wrote: >>> Hi Moritz, >>> >>> Thanks for the review. >>> Please find my response inline. >>> >>>> -Original Message- >>>> From: Moritz Fischer >>>> Sent: Tuesday, January 19, 2021 6:03 AM >>>> To: Nava kishore Manne >>>> Cc: m...@kernel.org; t...@redhat.com; robh...@kernel.org; Michal >>>> Simek ; linux-f...@vger.kernel.org; >>>> devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; >>>> linux- ker...@vger.kernel.org; git ; >>>> chinnikishore...@gmail.com; Appana Durga Kedareswara Rao >>>> >>>> Subject: Re: [PATCH 3/3] fpga: versal-fpga: Add versal fpga manager >>>> driver >>>> >>>> Hi Nava, >>>> >>>> On Mon, Jan 18, 2021 at 08:13:18AM +0530, Nava kishore Manne wrote: >>>>> This patch adds driver for versal fpga manager. >>>> Nit: Add support for Xilinx Versal FPGA manager >>> >>> Will fix in v2. >>> >>>>> >>>>> PDI source type can be DDR, OCM, QSPI flash etc.. >>>> No idea what PDI is :) >>> >>> Programmable device image (PDI). >>> This file is generated by Xilinx Vivado tool and it contains configuration >>> data >> objects. >>> >>>>> But driver allocates memory always from DDR, Since driver supports >>>>> only DDR source type. >>>>> >>>>> Signed-off-by: Appana Durga Kedareswara rao >>>>> >>>>> Signed-off-by: Nava kishore Manne >>>>> --- >>>>> drivers/fpga/Kconfig | 8 ++ >>>>> drivers/fpga/Makefile | 1 + >>>>> drivers/fpga/versal-fpga.c | 149 >>>>> + >>>>> 3 files changed, 158 insertions(+) create mode 100644 >>>>> drivers/fpga/versal-fpga.c >>>>> >>>>> diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig index >>>>> 5645226ca3ce..9f779c3a6739 100644 >>>>> --- a/drivers/fpga/Kconfig >>>>> +++ b/drivers/fpga/Kconfig >>>>> @@ -216,4 +216,12 @@ config FPGA_MGR_ZYNQMP_FPGA >>>>> to configure the programmable logic(PL) through PS >>>>> on ZynqMP SoC. >>>>> >>>>> +config FPGA_MGR_VERSAL_FPGA >>>>> +tristate "Xilinx Versal FPGA" >>>>> +depends on ARCH_ZYNQMP || COMPILE_TEST >>>>> +help >>>>> + Select this option to enable FPGA manager driver support for >>>>> + Xilinx Versal SOC. This driver uses the versal soc firmware >>>>> + interface to load programmable logic(PL) images >>>>> + on versal soc. >>>>> endif # FPGA >>>>> diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile index >>>>> d8e21dfc6778..40c9adb6a644 100644 >>>>> --- a/drivers/fpga/Makefile >>>>> +++ b/drivers/fpga/Makefile >>>>> @@ -18,6 +18,7 @@ obj-$(CONFIG_FPGA_MGR_TS73XX) += >>>> ts73xx-fpga.o >>>>> obj-$(CONFIG_FPGA_MGR_XILINX_SPI)+= xilinx-spi.o >>>>> obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA) += zynq-fpga.o >>>>> obj-$(CONFIG_FPGA_MGR_ZYNQMP_FPGA) += zynqmp-fpga.o >>>>> +obj-$(CONFIG_FPGA_MGR_VERSAL_FPGA) += versal-fpga.o >>>>> obj-$(CONFIG_ALTERA_PR_IP_CORE) += altera-pr-ip-core.o >>>>> obj-$(CONFIG_ALTERA_PR_IP_CORE_PLAT)+= altera-pr-ip-core-plat.o >>>>> >>>>> diff --git a/drivers/fpga/versal-fpga.c >>>>> b/drivers/fpga/versal-fpga.c new file mode 100644 index >>>>> ..2a42aa78b182 >>&g
Re: [PATCH 1/1] MAINTAINERS: remove myself from the list
Hi, On 1/27/21 3:18 AM, Hyun Kwon wrote: > Hi Laurent, > > On Tue, Jan 26, 2021 at 05:37:02PM -0800, Laurent Pinchart wrote: >> Hi Hyun, >> >> Thank you for the patch. >> >> On Tue, Jan 26, 2021 at 05:13:12PM -0800, Hyun Kwon wrote: >>> The email will become invalid soon. >> >> Is there, by any chance, anyone at Xilinx would could help maintaining >> these drivers ? >> > > Yes, there will be. I gave my recommendations, but it's still under > discussion. > I'll ensure it's decided sooner than later. I am still around and I will make sure that someone will take a look at it. Just let me know that you are expecting any input from Xilinx till we have someone. Thanks, Michal
Re: [PATCH 0/3] add Ebang EBAZ4205 support
On 1/20/21 8:40 PM, Michael Walle wrote: > Add support for the Ebang EBAZ4205 board. This board was once used as a > control board for a bitcoin mining device. Nowawdays it is sold as a cheap > Zynq-7000 eval board. > > Michael Walle (3): > dt-bindings: add ebang vendor prefix > dt-bindings: arm: add Ebang EBAZ4205 board > ARM: dts: add Ebang EBAZ4205 device tree > > .../devicetree/bindings/arm/xilinx.yaml | 1 + > .../devicetree/bindings/vendor-prefixes.yaml | 2 + > arch/arm/boot/dts/Makefile| 1 + > arch/arm/boot/dts/zynq-ebaz4205.dts | 109 ++ > 4 files changed, 113 insertions(+) > create mode 100644 arch/arm/boot/dts/zynq-ebaz4205.dts > Applied all. Thanks, Michal
Re: [PATCH 01/21] clk: zynq: pll: Fix kernel-doc formatting in 'clk_register_zynq_pll's header
On 1/26/21 1:45 PM, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> drivers/clk/zynq/pll.c:187: warning: Function parameter or member 'name' not
> described in 'clk_register_zynq_pll'
> drivers/clk/zynq/pll.c:187: warning: Function parameter or member 'parent'
> not described in 'clk_register_zynq_pll'
> drivers/clk/zynq/pll.c:187: warning: Function parameter or member 'pll_ctrl'
> not described in 'clk_register_zynq_pll'
> drivers/clk/zynq/pll.c:187: warning: Function parameter or member
> 'pll_status' not described in 'clk_register_zynq_pll'
> drivers/clk/zynq/pll.c:187: warning: Function parameter or member
> 'lock_index' not described in 'clk_register_zynq_pll'
> drivers/clk/zynq/pll.c:187: warning: Function parameter or member 'lock' not
> described in 'clk_register_zynq_pll'
>
> Cc: Michael Turquette
> Cc: Stephen Boyd
> Cc: Michal Simek
> Cc: "Sören Brinkmann"
> Cc: linux-...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Signed-off-by: Lee Jones
> ---
> drivers/clk/zynq/pll.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/clk/zynq/pll.c b/drivers/clk/zynq/pll.c
> index dcb2037a95964..54f4184de89af 100644
> --- a/drivers/clk/zynq/pll.c
> +++ b/drivers/clk/zynq/pll.c
> @@ -173,12 +173,12 @@ static const struct clk_ops zynq_pll_ops = {
>
> /**
> * clk_register_zynq_pll() - Register PLL with the clock framework
> - * @name PLL name
> - * @parent Parent clock name
> - * @pll_ctrl Pointer to PLL control register
> - * @pll_status Pointer to PLL status register
> - * @lock_index Bit index to this PLL's lock status bit in @pll_status
> - * @lock Register lock
> + * @name:PLL name
> + * @parent: Parent clock name
> + * @pll_ctrl:Pointer to PLL control register
> + * @pll_status: Pointer to PLL status register
> + * @lock_index: Bit index to this PLL's lock status bit in @pll_status
> + * @lock:Register lock
> * Returns handle to the registered clock.
> */
> struct clk *clk_register_zynq_pll(const char *name, const char *parent,
>
When you are on this we should also fix that Returns which are also
reported by kernel-doc
When your patch is applied:
[linux](master)$ ./scripts/kernel-doc -v -man drivers/clk/zynq/pll.c >
/dev/null
drivers/clk/zynq/pll.c:15: warning: missing initial short description on
line:
* struct zynq_pll
drivers/clk/zynq/pll.c:15: info: Scanning doc for struct
drivers/clk/zynq/pll.c:45: info: Scanning doc for zynq_pll_round_rate
drivers/clk/zynq/pll.c:53: warning: No description found for return
value of 'zynq_pll_round_rate'
drivers/clk/zynq/pll.c:66: info: Scanning doc for zynq_pll_recalc_rate
drivers/clk/zynq/pll.c:73: warning: No description found for return
value of 'zynq_pll_recalc_rate'
drivers/clk/zynq/pll.c:88: info: Scanning doc for zynq_pll_is_enabled
drivers/clk/zynq/pll.c:96: warning: No description found for return
value of 'zynq_pll_is_enabled'
drivers/clk/zynq/pll.c:111: info: Scanning doc for zynq_pll_enable
drivers/clk/zynq/pll.c:116: warning: No description found for return
value of 'zynq_pll_enable'
drivers/clk/zynq/pll.c:141: info: Scanning doc for zynq_pll_disable
drivers/clk/zynq/pll.c:175: info: Scanning doc for clk_register_zynq_pll
drivers/clk/zynq/pll.c:187: warning: No description found for return
value of 'clk_register_zynq_pll'
6 warnings
Can you please also fix it? It can be done in separate patch if this is
not reported by W=1.
Acked-by: Michal Simek
Thanks,
Michal
Re: [PATCH 21/21] clk: zynqmp: divider: Add missing description for 'max_div'
On 1/26/21 1:45 PM, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> drivers/clk/zynqmp/divider.c:46: warning: Function parameter or member
> 'max_div' not described in 'zynqmp_clk_divider'
>
> Cc: Michael Turquette
> Cc: Stephen Boyd
> Cc: Michal Simek
> Cc: Rajan Vaja
> Cc: linux-...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Signed-off-by: Lee Jones
> ---
> drivers/clk/zynqmp/divider.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/clk/zynqmp/divider.c b/drivers/clk/zynqmp/divider.c
> index 66da02b83d393..e9bf7958b8218 100644
> --- a/drivers/clk/zynqmp/divider.c
> +++ b/drivers/clk/zynqmp/divider.c
> @@ -35,6 +35,7 @@
> * @is_frac: The divider is a fractional divider
> * @clk_id: Id of clock
> * @div_type:divisor type (TYPE_DIV1 or TYPE_DIV2)
> + * @max_div: maximum supported divisor (fetched from firmware)
> */
> struct zynqmp_clk_divider {
> struct clk_hw hw;
>
In our soc tree we have
* @max_div:Maximum divisor value allowed
But your description should be also fine. Rajan please reply if I am
wrong. Otherwise:
Acked-by: Michal Simek
Thanks,
Michal
Re: [PATCH 1/2] arm64: boot: dts: add new dts for hellcat & petra
On 1/25/21 10:04 PM, Daniel Walker (danielwa) wrote: > On Mon, Jan 25, 2021 at 08:52:01AM +0100, Michal Simek wrote: >>> >>>> >>>> Long time ago we said that we are not going to push any PL related >>>> configurations. It means all below can't be merged. >>>> And there are also coding style issues. >>> >>> You'll need to explain this more. It's likely this was added at the >>> suggestion of >>> Xilinx. If it can't be upstreamed what should we replace it with ? >> >> No idea who gave you this suggestion from Xilinx. > > Just an FYI , I didn't write this dts or work on it's original development so > I > can't name names. ok. > >> I had similar thread with Michael Walle about supporting Ebang board. >> PL depends on your custom design and can change quite quickly that's >> there is no good/bad configuration. That's why all of them can be valid >> and kernel is not the right location to store thousands of >> configurations (likely in overlay form). That's why only fixed >> configurations for PS are added to kernel. >> And I prefer if there is any good reason behind why these platforms >> should be added. > > I'm not sure what your talking about above .. Are you suggesting the changes > in > my DTS will change quickly ? They have been the same for years , we don't plan > to change them. This DTS is not a prototype it's a released Cisco product. I am saying that I will NACK all DT changes which target PL. No matter that you didn't change hw design for years. You can add PL to DT overlay and apply it in Linux or do it via bootloader. > If I did delete this "PL configuration" where would you expect it to > re-appear ? > Typically things which aren't upstreamable are transformed into something > else, > it's rare that something is just removed and has no transformation. dt overlay in your distribution, rootfs as separate file and base DT in mainline. Thanks, Michal
Re: [PATCH 1/2] arm64: boot: dts: add new dts for hellcat & petra
Hi Daniel, On 1/22/21 9:32 PM, Daniel Walker (danielwa) wrote: > On Fri, Jan 22, 2021 at 09:48:53AM +0100, Michal Simek wrote: >> Hi Daniel, >> >> On 1/22/21 12:12 AM, Daniel Walker wrote: >>> Add Petra and Hellcat dts file. These platforms are based on >>> the Xilinx Zynqmp platform. >>> >>> Signed-off-by: Daniel Walker >>> Cc: xe-linux-exter...@cisco.com >>> --- >>> arch/arm64/boot/dts/xilinx/Makefile | 2 + >>> .../boot/dts/xilinx/zynqmp-petra-hellcat.dts | 856 ++ >>> arch/arm64/boot/dts/xilinx/zynqmp-petra.dts | 847 + >>> 3 files changed, 1705 insertions(+) >>> create mode 100644 arch/arm64/boot/dts/xilinx/zynqmp-petra-hellcat.dts >>> create mode 100644 arch/arm64/boot/dts/xilinx/zynqmp-petra.dts >> >> First of all I can't see 2/2. > > It wasn't being submitted to you. But here it is if you care to look at it. > > https://lkml.org/lkml/2021/1/21/1468 I think spi-dev should enable the same approach as is used by uio driver. Take a look at 05c3e0bb5629b897b0459e4bfb1b93d729033b99 But it is up to Mark it this could be reasonable solution for this driver. > >> >> Long time ago we said that we are not going to push any PL related >> configurations. It means all below can't be merged. >> And there are also coding style issues. > > You'll need to explain this more. It's likely this was added at the > suggestion of > Xilinx. If it can't be upstreamed what should we replace it with ? No idea who gave you this suggestion from Xilinx. I had similar thread with Michael Walle about supporting Ebang board. PL depends on your custom design and can change quite quickly that's there is no good/bad configuration. That's why all of them can be valid and kernel is not the right location to store thousands of configurations (likely in overlay form). That's why only fixed configurations for PS are added to kernel. And I prefer if there is any good reason behind why these platforms should be added. > I will review your other comments and re-submit. Happy to take a look at it again but completely remove PL description. Thanks, Michal
Re: [PATCH v2 1/3] firmware: xilinx: Added pinctrl support
Hi, On 1/22/21 1:50 PM, Linus Walleij wrote: > On Tue, Jan 19, 2021 at 6:28 AM Sai Krishna Potthuri > wrote: > >> Add pinctrl support to query platform specific information (pins) >> from firmware. >> >> Signed-off-by: Sai Krishna Potthuri > > I need an ACK from the maintainer of this file to merge it with the rest to > the pinctrl tree. I suppose Michal? here it is. Acked-by: Michal Simek Thanks, Michal
Re: [PATCH 06/12] arm64: dts: zynqmp: Add label for zynqmp_ipi
Hi, On 1/21/21 11:29 PM, Laurent Pinchart wrote: > Hi Michal, > > I've just realized I forgot to reply to this e-mail, sorry. > > On Tue, Dec 08, 2020 at 08:26:41AM +0100, Michal Simek wrote: >> On 07. 12. 20 23:16, Laurent Pinchart wrote: >>> On Mon, Dec 07, 2020 at 10:39:25AM +0100, Michal Simek wrote: >>>> On 06. 12. 20 23:46, Laurent Pinchart wrote: >>>>> On Wed, Dec 02, 2020 at 03:06:05PM +0100, Michal Simek wrote: >>>>>> Add label which is used by bootloader for adding bootloader specific >>>>>> flag. >>>>>> >>>>>> Signed-off-by: Michal Simek >>>>>> --- >>>>>> >>>>>> U-Boot needs to add u-boot,dm-pre-reloc; property >>>>> >>>>> I'm not entirely sure what best practice rules are in this area, but >>>>> shouldn't U-Boot locate the node by name instead of label ? >>>> >>>> Labels are not listed in dt binding and there are two approaches how to >>>> reference nodes. Via full path with node name or via labels. >>>> I do normally use labels which are much simple. >>> >>> Note that labels require the DTB to be compiled with the -@ option, >>> otherwise they're not present in the binary. >> >> U-Boot is using different concept. You can see that there are a lot of >> -u-boot.dtsi files in dts folders. These are automatically included to >> DTS before DTC is called. It means you don't need to build overlay to >> get merged. >> >>>> And also if you take a look how dtb looks like (convert back to dts) you >>>> can see that for example aliases are using full path (just ) but >>>> clocks/gic which is the part of <> is handled via phandles as numbers. >>>> >>>> And labels names can vary and shouldn't be the part of binding doc as >>>> far as I know. But I can be wrong of course. >>> >>> The DT bindings should document the interface with the operating system, >>> and if applicable, the boot loader. If the boot loader requires a >>> particular label, then it becomes part of the ABI, and I think it should >>> be documented in the bindings. >> >> We have been discussing with Rob some month ago but didn't have a time >> to do step further. Just keep it short Rob was ok to keep bootloader >> binding inside Linux repo. > > I think that makes sense, DT bindings are meant to be OS-agnostic, so > boot loader requirements should be documented there. > >> There is no hardcoding for a particular name. There is just a need to >> have any label. U-Boot needs to have one property(e.g. >> u-boot,dm-pre-reloc;) just to do early allocation. >> The name is just reference and none is really looking for it. It is just >> a way how to include it in much easier way. > > Just to make sure I understand this issue correctly, does this mean that > you need to reference the node in a *-u-boot.dtsi file, and want a label > to do so ? The label name needs to be the same in the base file (taken > from the Linux source tree) and the *-u-boot.dtsi file (in the U-Boot > source tree) in that case. Isn't it the role of DT bindings to document > such requirements ? I prefer to have all nodes with labels just in case you need to reference it. Simply based on experience it happens time to time that something needs to be aligned, new property added and sometimes we touch dt overlays. It means I prefer to have labels for all nodes. In connection to u-boot. U-Boot introduced *-u-boot.dtsi files for bootloader specific configurations. I think that's sort of bad design and it should be done differently by simply document/align this binding with the kernel. And in this u-boot,dm-pre-reloc case it should be handle differently and any transition is required. Normally *-u-boot.dtsi should just reference node in "root" dts via labels. And u-boot is trying to align dts with the kernel. And last part on this if make sense to also document labels as requirement. I don't think it is good idea. You can have in general multiple instances of the same IP which you need to add some properties to. You would have to defined all of them for all existing SOCs which will be very painful. It also takes so much time to upstream it that's why checking one more thing there is IMHO just additional step. I think that everybody should be trying to align all things together across all projects. That's for example what I want to do in this gtr/dp between Linux/U-Boot. Thanks, Michal
Re: Fail to boot qemu xlnx-zcu102 due to lot of drivers not probing
Hi, On 1/22/21 10:24 AM, Corentin Labbe wrote: > Hello > > With at least qemu 5.1.0 (and later), the xlnx-zcu102 machine boot lead to a > panic due to missing console. > qemu-system-aarch64 -kernel Image -nographic -machine xlnx-zcu102 -device > ide-hd,drive=lavatest -serial mon:stdio -serial null -append > 'earlycon=cdns,mmio,0xFF00,115200n8 console=ttyPS0 root=/dev/ram0 > ip=dhcp' -dtb zynqmp-zcu102-rev1.0.dtb -m 2048 -nic > user,model=cadence_gem,mac=52:54:00:12:34:58 -drive > format=qcow2,file=disk.img,if=none,id=lavatest -initrd rootfs.cpio.gz > [0.00] Booting Linux on physical CPU 0x00 [0x410fd034] > [0.00] Linux version 5.5.0-rc1-4-g9c8a47b484ed (clabbe@arnold) > (gcc version 7.5.0 (Linaro GCC 7.5-2019.12)) #17 SMP PREEMPT Fri Jan 22 > 09:19:31 UTC 2021 > [0.00] Machine model: ZynqMP ZCU102 Rev1.0 > [0.00] earlycon: cdns0 at MMIO 0xff00 (options '115200n8') > [0.00] printk: bootconsole [cdns0] enabled > [0.00] efi: Getting EFI parameters from FDT: > [0.00] efi: UEFI not found. > [0.00] cma: Reserved 32 MiB at 0x7e00 > [0.00] NUMA: No NUMA configuration found > [0.00] NUMA: Faking a node at [mem > 0x-0x7fff] > [0.00] NUMA: NODE_DATA [mem 0x7dbe0100-0x7dbe1fff] > [0.00] Zone ranges: > [0.00] DMA [mem 0x-0x3fff] > [0.00] DMA32[mem 0x4000-0x7fff] > [0.00] Normal empty > [0.00] Movable zone start for each node > [0.00] Early memory node ranges > [0.00] node 0: [mem 0x-0x7fff] > [0.00] Initmem setup node 0 [mem > 0x-0x7fff] > [0.00] psci: probing for conduit method from DT. > [0.00] psci: PSCIv0.2 detected in firmware. > [0.00] psci: Using standard PSCI v0.2 function IDs > [0.00] psci: Trusted OS migration not required > [0.00] percpu: Embedded 22 pages/cpu s53016 r8192 d28904 u90112 > [0.00] Detected VIPT I-cache on CPU0 > [0.00] CPU features: detected: ARM erratum 845719 > [0.00] CPU features: detected: ARM erratum 843419 > [0.00] Built 1 zonelists, mobility grouping on. Total pages: 516096 > [0.00] Policy zone: DMA32 > [0.00] Kernel command line: earlycon=cdns,mmio,0xFF00,115200n8 > console=ttyPS0 root=/dev/ram0 ip=dhcp > [0.00] Dentry cache hash table entries: 262144 (order: 9, 2097152 > bytes, linear) > [0.00] Inode-cache hash table entries: 131072 (order: 8, 1048576 > bytes, linear) > [0.00] mem auto-init: stack:off, heap alloc:off, heap free:off > [0.00] software IO TLB: mapped [mem 0x3bfff000-0x3000] (64MB) > [0.00] Memory: 1907172K/2097152K available (12092K kernel code, 1896K > rwdata, 6640K rodata, 5120K init, 456K bss, 157212K reserved, 32768K > cma-reserved) > [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 > [0.00] rcu: Preemptible hierarchical RCU implementation. > [0.00] rcu: RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=4. > [0.00]Tasks RCU enabled. > [0.00] rcu: RCU calculated value of scheduler-enlistment delay is 25 > jiffies. > [0.00] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4 > [0.00] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0 > [0.00] random: get_random_bytes called from start_kernel+0x2b8/0x454 > with crng_init=0 > [0.00] arch_timer: cp15 timer(s) running at 62.50MHz (virt). > [0.00] clocksource: arch_sys_counter: mask: 0xff > max_cycles: 0x1cd42e208c, max_idle_ns: 881590405314 ns > [0.000118] sched_clock: 56 bits at 62MHz, resolution 16ns, wraps every > 4398046511096ns > [0.006458] Console: colour dummy device 80x25 > [0.008026] Calibrating delay loop (skipped), value calculated using timer > frequency.. 125.00 BogoMIPS (lpj=25) > [0.008182] pid_max: default: 32768 minimum: 301 > [0.009157] LSM: Security Framework initializing > [0.010014] Mount-cache hash table entries: 4096 (order: 3, 32768 bytes, > linear) > [0.010106] Mountpoint-cache hash table entries: 4096 (order: 3, 32768 > bytes, linear) > [0.060263] ASID allocator initialised with 32768 entries > [0.067849] rcu: Hierarchical SRCU implementation. > [0.079370] EFI services will not be available. > [0.088702] smp: Bringing up secondary CPUs ... > [0.118904] Detected VIPT I-cache on CPU1 > [0.119921] CPU1: Booted secondary processor 0x01 [0x410fd034] > [0.156284] Detected VIPT I-cache on CPU2 > [0.156514] CPU2: Booted secondary processor 0x02 [0x410fd034] > [0.189310] Detected VIPT I-cache on CPU3 > [0.189472] CPU3: Booted secondary processor 0x03 [0x410fd034] > [0.189921] smp:
Re: [PATCH 1/2] arm64: boot: dts: add new dts for hellcat & petra
Hi Daniel,
On 1/22/21 12:12 AM, Daniel Walker wrote:
> Add Petra and Hellcat dts file. These platforms are based on
> the Xilinx Zynqmp platform.
>
> Signed-off-by: Daniel Walker
> Cc: xe-linux-exter...@cisco.com
> ---
> arch/arm64/boot/dts/xilinx/Makefile | 2 +
> .../boot/dts/xilinx/zynqmp-petra-hellcat.dts | 856 ++
> arch/arm64/boot/dts/xilinx/zynqmp-petra.dts | 847 +
> 3 files changed, 1705 insertions(+)
> create mode 100644 arch/arm64/boot/dts/xilinx/zynqmp-petra-hellcat.dts
> create mode 100644 arch/arm64/boot/dts/xilinx/zynqmp-petra.dts
First of all I can't see 2/2.
>
> diff --git a/arch/arm64/boot/dts/xilinx/Makefile
> b/arch/arm64/boot/dts/xilinx/Makefile
> index 60f5443f3ef4..d9eacb3c60e5 100644
> --- a/arch/arm64/boot/dts/xilinx/Makefile
> +++ b/arch/arm64/boot/dts/xilinx/Makefile
> @@ -15,3 +15,5 @@ dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu102-rev1.0.dtb
> dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu104-revA.dtb
> dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu106-revA.dtb
> dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu111-revA.dtb
> +dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-petra.dts
> +dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-petra-hellcat.dts
> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-petra-hellcat.dts
> b/arch/arm64/boot/dts/xilinx/zynqmp-petra-hellcat.dts
> new file mode 100644
> index ..87e23c1cac65
> --- /dev/null
> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-petra-hellcat.dts
> @@ -0,0 +1,856 @@
> +/*
> + * dts file for Cisco Petra-Hellcat Switching IOT platform
> + *
> + * (C) Copyright 2016-2018, Cisco Systems, Inc.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
This should be SPDX header.
> + */
> +
> +/dts-v1/;
> +
> +#include "zynqmp.dtsi"
> +#include "zynqmp-clk-ccf.dtsi"
> +
> +/*
> + * PL *
> + */
useless
> +
> +/ {
> +reserved-memory {
> +#address-cells = <0x2>;
just 2
> +#size-cells = <0x2>;
just 2
> +ranges;
> +
> +rproc@3ed0 {
> +no-map;
> +reg = <0x0 0x3ed0 0x0 0x100>;
> +};
> +zynqmp_sha_reserved: buffer@0 {
> +compatible = "shared-dma-pool";
> +no-map;
> +reg = <0x0 0x7800 0x0 0x0002>;
> +};
> +};
> +
> +sha384 {
> +compatible = "xlnx,zynqmp-keccak-384";
> +memory-region = <_sha_reserved>;
> +};
> +
> + amba_pl: amba_pl@0 {
Long time ago we said that we are not going to push any PL related
configurations. It means all below can't be merged.
And there are also coding style issues.
> + #address-cells = <2>;
> + #size-cells = <2>;
> + compatible = "simple-bus";
> + ranges ;
> + design_1_i_axi_iic_BP: i2c@80104000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +clocks = <0x3 0x47>;
> + compatible = "xlnx,xps-iic-2.00.a";
> + interrupt-parent = <>;
> + interrupts = <0 93 4>;
> + reg = <0x0 0x80104000 0x0 0x1000>;
> + };
> + design_1_i_axi_iic_KM_PLT: i2c@80106000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +clocks = <0x3 0x47>;
> + compatible = "xlnx,xps-iic-2.00.a";
> + interrupt-parent = <>;
> + interrupts = <0 107 4>;
> + reg = <0x0 0x80106000 0x0 0x1000>;
> + };
> + design_1_i_axi_iic_LC1: i2c@8010 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +clocks = <0x3 0x47>;
> + compatible = "xlnx,xps-iic-2.00.a";
> + interrupt-parent = <>;
> + interrupts = <0 89 4>;
> + reg = <0x0 0x8010 0x0 0x1000>;
> + };
> + design_1_i_axi_iic_LC2: i2c@80101000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +clocks = <0x3 0x47>;
> + compatible = "xlnx,xps-iic-2.00.a";
> + interrupt-parent = <>;
> + interrupts = <0 90 4>;
> + reg = <0x0 0x80101000 0x0 0x1000>;
> + };
> + design_1_i_axi_iic_LC3: i2c@80102000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +clocks = <0x3 0x47>;
> + compatible = "xlnx,xps-iic-2.00.a";
> + interrupt-parent = <>;
> + interrupts = <0 91 4>;
> +
Re: [PATCH 3/3] arm64: dts: zynqmp: Wire up the DisplayPort subsystem
Hi Laurent,
On 1/22/21 8:46 AM, Laurent Pinchart wrote:
> Hi Michal,
>
> On Fri, Jan 22, 2021 at 08:19:15AM +0100, Michal Simek wrote:
>> On 1/21/21 11:37 PM, Laurent Pinchart wrote:
>>> On Thu, Jan 21, 2021 at 01:36:07PM +0100, Michal Simek wrote:
>>>> From: Laurent Pinchart
>>>>
>>>> Enable the dpsub device and wire it up to the PS-GTR PHY lanes routed to
>>>> the DisplayPort connector.
>>>>
>>>> Signed-off-by: Laurent Pinchart
>>>> Signed-off-by: Michal Simek
>>>> ---
>>>>
>>>> Wire all the boards
>>>>
>>>> ---
>>>> .../boot/dts/xilinx/zynqmp-zcu100-revC.dts| 31 +++
>>>> .../boot/dts/xilinx/zynqmp-zcu102-revA.dts| 10 ++
>>>> .../boot/dts/xilinx/zynqmp-zcu104-revA.dts| 11 +++
>>>> .../boot/dts/xilinx/zynqmp-zcu104-revC.dts| 11 +++
>>>> .../boot/dts/xilinx/zynqmp-zcu106-revA.dts| 11 +++
>>>> .../boot/dts/xilinx/zynqmp-zcu111-revA.dts| 11 +++
>>>> 6 files changed, 85 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts
>>>> b/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts
>>>> index 71ebcaadb7c8..a53598c3624b 100644
>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts
>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts
>>>> @@ -15,6 +15,7 @@
>>>> #include
>>>> #include
>>>> #include
>>>> +#include
>>>>
>>>> / {
>>>>model = "ZynqMP ZCU100 RevC";
>>>> @@ -108,6 +109,18 @@ ina226 {
>>>>compatible = "iio-hwmon";
>>>>io-channels = < 0>, < 1>, < 2>, < 3>;
>>>>};
>>>> +
>>>> + si5335a_0: clk26 {
>>>> + compatible = "fixed-clock";
>>>> + #clock-cells = <0>;
>>>> + clock-frequency = <2600>;
>>>> + };
>>>> +
>>>> + si5335a_1: clk27 {
>>>> + compatible = "fixed-clock";
>>>> + #clock-cells = <0>;
>>>> + clock-frequency = <2700>;
>>>> + };
>>>
>>> This is fine as a workaround for now, but I'm still wondering how we'll
>>> solve this properly. We can declare the SI5335A in DT without wiring the
>>> output that provides the clock to the PS, otherwise it will be disabled
>>> as part of the boot process.
>>
>> All these clock chips are preprogrammed to certain rate and enabled by
>> default. It means there doesn't need to be any SW handling to enable it.
>> When driver for these clock chips comes we can change this that's why I
>> used labels which are saying which output it is.
>
> Unless I'm mistaken, on the ZCU106 board, the chip is an SI5341B, which
> has a driver already. I tried to declare it in DT, but the PS_REF_CLK
> then got disabled at the end of boot, and the system wasn't happy about
> it :-)
In series before si5341 chips are enabled as the part of sata
enablement. Maybe you missed always-on parameter.
si5341_9: out@9 {
/* refclk9 used for PS_REF_CLK 33.3 MHz */
reg = <9>;
always-on;
};
I just retest it and I can't see any issue. Sata
I see DP driver probed but I can't see anything on 4k monitor but maybe
there should be something to setup (I use fs from 2015).
thanks,
Michal
