Re: [PATCH 1/2] dt-bindings: soc: ti: ti,pruss: add ti,am1806-pruss
On 17/01/21 1:48 AM, David Lechner wrote: > On 1/15/21 10:45 AM, Suman Anna wrote: >> + Sekhar and Bartosz >> >> Hi David, >> >> On 1/4/21 12:30 PM, David Lechner wrote: >>> This adds a "ti,am1806-pruss" compatible type for the PRUSS found in >>> TI AM18xx/OMAP-L138 SoCs. >>> >>> Signed-off-by: David Lechner >>> --- >>> Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml | 2 ++ >>> 1 file changed, 2 insertions(+) >>> >>> diff --git a/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml >>> b/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml >>> index 037c51b2f972..a6ed23fdbc00 100644 >>> --- a/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml >>> +++ b/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml >>> @@ -61,6 +61,7 @@ properties: >>> compatible: >>> enum: >>> + - ti,am1806-pruss # for AM18xx/OMAP-L138 SoC family >> >> Almost all the drivers for these SoCs use the prefix "ti,da850-xxx" >> for the >> compatibles. Can we switch to using those instead of ti,am1806? > > I wasn't sure which chips exactly are "DA850". If someone can tell > me, I can look at the docs to see if they have a PRUSS. Hi David, you can treat DA850 is same as OMAP-L138 for all purposes in kernel. Thanks, Sekhar
Re: [RESEND PATCH] MAINTAINERS: Add myself as a reviewer for CADENCE USB3 DRD IP DRIVER
+ Peter, Pawel and Roger for their acks. On 08/12/20 10:38 AM, Aswath Govindraju wrote: > I would like to help in reviewing CADENCE USB3 DRD IP DRIVER patches > > Signed-off-by: Aswath Govindraju > --- > > Resending the patch to add more viewers. > > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 6aac0f845f34..ff9bd7d18d94 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -3861,6 +3861,7 @@ CADENCE USB3 DRD IP DRIVER > M: Peter Chen > M: Pawel Laszczak > M: Roger Quadros > +R: Aswath Govindraju > L: linux-...@vger.kernel.org > S: Maintained > T: git git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb.git > -- > 2.17.1 >
Re: [PATCH v3 00/10] Introduced new Cadence USBSSP DRD Driver.
On 24/11/20 3:22 PM, Pawel Laszczak wrote: > Sekhar, > >> >> >> On 24/11/20 2:51 PM, Pawel Laszczak wrote: >>> Peter, >>> On 20-11-19 15:12:57, Pawel Laszczak wrote: > This patch introduce new Cadence USBSS DRD driver to linux kernel. > > The Cadence USBSS DRD Controller is a highly configurable IP Core which > can be instantiated as Dual-Role Device (DRD), Peripheral Only and > Host Only (XHCI)configurations. > > The current driver has been validated with FPGA burned. We have support > for PCIe bus, which is used on FPGA prototyping. > > The host side of USBSS-DRD controller is compliance with XHCI > specification, so it works with standard XHCI Linux driver. > > The device side of USBSS DRD controller is compliant with XHCI. > The architecture for device side is almost the same as for host side, > and most of the XHCI specification can be used to understand how > this controller operates. > > This controller and driver support Full Speed, Hight Speed, Supper Speed > and Supper Speed Plus USB protocol. > > The prefix cdnsp used in driver has chosen by analogy to cdn3 driver. > The last letter of this acronym means PLUS. The formal name of controller > is USBSSP but it's to generic so I've decided to use CDNSP. > > The patch 1: adds support for DRD CDNSP. > The patch 2: separates common code that can be reusable by cdnsp driver. > The patch 3: moves reusable code to separate module. > The patch 4: changes prefixes in reusable code from cdns3 to common cdns. > The patch 5: adopts gadget_dev pointer in cdns structure to make possible > use it in both drivers. > The patches 6-8: add the main part of driver and has been intentionally > split into 3 part. In my opinion such division should not > affect understanding and reviewing the driver, and cause that > main patch (7/8) is little smaller. Patch 6 introduces main > header file for driver, 7 is the main part that implements > all > functionality of driver and 8 introduces tracepoints. > The patch 9: Adds cdns3 prefixes to files related with USBSS driver. > the patch 10: Adds USBSSP DRD IP driver entry to MAINTAINERS file. > > Changlog from v2: > - removed not used pdev parameter from cdnsp_read/wite_64 functions > - fixed incorrect value assigned to CDNSP_ENDPOINTS_NUM (32 -> 31) > - replaced some constant value with CDNSP_ENDPOINTS_NUM macro > - replaced 'true' with '1' in bits description in cdnsp-gadget.h file > - fixed some typos > - some other less important changes suggested by Peter Chen Hi Pawel, I have updated my -next tree as the latest usb-next tree which v5.10-rc4 is included, would you please rebase my tree and send again, I could apply your patches and test, if test could pass, I will apply it to my -next tree. You don't need to rebase again since it is a huge patch set, will take some efforts for rebase. >>> >>> I'll try to post it tomorrow. >> >> Pawel, have you tested TI J7 for regressions after this series? After >> your latest changes, can you post a tree which someone in TI can test? > > No I haven't test it on J7. For testing I'm using PCIe based platform for > both cnds3 and cdnsp driver. Do you have access to J7 EVM? Are you willing to test it there to make sure nothing broke? > > Why you can't use the latest kernel version and current series ? Sure. Let me try that. Looking at some other traffic on this thread, I was not sure where this applies. So, this applies to latest of Linus's tree? I re-read the cover letter but cannot find this information. Thanks, Sekhar
Re: [PATCH v3 00/10] Introduced new Cadence USBSSP DRD Driver.
On 24/11/20 2:51 PM, Pawel Laszczak wrote: > Peter, > >> On 20-11-19 15:12:57, Pawel Laszczak wrote: >>> This patch introduce new Cadence USBSS DRD driver to linux kernel. >>> >>> The Cadence USBSS DRD Controller is a highly configurable IP Core which >>> can be instantiated as Dual-Role Device (DRD), Peripheral Only and >>> Host Only (XHCI)configurations. >>> >>> The current driver has been validated with FPGA burned. We have support >>> for PCIe bus, which is used on FPGA prototyping. >>> >>> The host side of USBSS-DRD controller is compliance with XHCI >>> specification, so it works with standard XHCI Linux driver. >>> >>> The device side of USBSS DRD controller is compliant with XHCI. >>> The architecture for device side is almost the same as for host side, >>> and most of the XHCI specification can be used to understand how >>> this controller operates. >>> >>> This controller and driver support Full Speed, Hight Speed, Supper Speed >>> and Supper Speed Plus USB protocol. >>> >>> The prefix cdnsp used in driver has chosen by analogy to cdn3 driver. >>> The last letter of this acronym means PLUS. The formal name of controller >>> is USBSSP but it's to generic so I've decided to use CDNSP. >>> >>> The patch 1: adds support for DRD CDNSP. >>> The patch 2: separates common code that can be reusable by cdnsp driver. >>> The patch 3: moves reusable code to separate module. >>> The patch 4: changes prefixes in reusable code from cdns3 to common cdns. >>> The patch 5: adopts gadget_dev pointer in cdns structure to make possible >>> use it in both drivers. >>> The patches 6-8: add the main part of driver and has been intentionally >>> split into 3 part. In my opinion such division should not >>> affect understanding and reviewing the driver, and cause that >>> main patch (7/8) is little smaller. Patch 6 introduces main >>> header file for driver, 7 is the main part that implements all >>> functionality of driver and 8 introduces tracepoints. >>> The patch 9: Adds cdns3 prefixes to files related with USBSS driver. >>> the patch 10: Adds USBSSP DRD IP driver entry to MAINTAINERS file. >>> >>> Changlog from v2: >>> - removed not used pdev parameter from cdnsp_read/wite_64 functions >>> - fixed incorrect value assigned to CDNSP_ENDPOINTS_NUM (32 -> 31) >>> - replaced some constant value with CDNSP_ENDPOINTS_NUM macro >>> - replaced 'true' with '1' in bits description in cdnsp-gadget.h file >>> - fixed some typos >>> - some other less important changes suggested by Peter Chen >> >> Hi Pawel, >> >> I have updated my -next tree as the latest usb-next tree which v5.10-rc4 >> is included, would you please rebase my tree and send again, I could apply >> your >> patches and test, if test could pass, I will apply it to my -next tree. >> You don't need to rebase again since it is a huge patch set, will take some >> efforts for rebase. >> > > I'll try to post it tomorrow. Pawel, have you tested TI J7 for regressions after this series? After your latest changes, can you post a tree which someone in TI can test? Thanks, Sekhar
Re: [PATCH v2 2/4] arm64: dts: ti: k3: squelch warnings regarding no #address-cells for interrupt-controller
On 24/11/20 6:51 AM, Nishanth Menon wrote: > On 09:45-20201123, Sekhar Nori wrote: >>>> The main reason I commented - is hope to get some clarification from DT >>>> maintainers. >>>> 90% of interrupt-controller nodes do not have #address-cells and I never >>>> seen in in GPIO nodes >>>> (most often is present in PCI and GIC nodes). >>>> and nobody seems fixing it. So, if we are going to move this direction >>>> it's reasonable to get clarification to be sure. >>>> >>>> And there is no "never" here - #address-cells always can be added if >>>> really required. >>> >>> >>> OK - as a GPIO node, but as an interrupt-controller node, I was >>> looking at [1] and wondering if that was the precedence. >>> >>> Yes, will be good to get direction from the DT maintainers on this >>> topic. >> >> Shall I respin this series with 2/4 dropped while we wait for decision >> on this? >> >> #address-cells warnings on interrupt controller can perhaps be handled >> all at once (there are many of those in existing DT anyway). >> >> GPIO is basic support and holds up many other modules (like MMC/SD). > > > There are'nt too many new patches in my queue that depends on GPIO, I'd > rather not introduce new warnings unless we are completely at a > stalemate. I'd rather use this opportunity to understand where what we > need to be doing. GPIO was originally submitted as part of 8 patch series titled "[PATCH 0/8] Add support for UHS modes in TI's J721e and J7200 boards" Rest of those patches need to be resubmitted after GPIO is accepted. Can you apply patch 1/4 at least. Its fairly non-controversial. It will help reduce patch backlog and fix some warnings too. Thanks, Sekhar
Re: [PATCH v2 2/4] arm64: dts: ti: k3: squelch warnings regarding no #address-cells for interrupt-controller
On 19/11/20 6:58 PM, Nishanth Menon wrote: > Punting over to Rob and DT team's wisdom.. > > On 13:17-20201119, Grygorii Strashko wrote: >> >> >> On 18/11/2020 17:12, Nishanth Menon wrote: >>> On 13:38-20201118, Grygorii Strashko wrote: >>>> Hi Rob, >>>> >>>> On 17/11/2020 18:19, Sekhar Nori wrote: >>>>> With dtc 1.6.0, building TI device-tree files with W=2 results in warnings >>>>> like below for all interrupt controllers. >>>>> >>>>> /bus@10/bus@3000/interrupt-controller1: Missing #address-cells in >>>>> interrupt provider >>>>> >>>>> Fix these by adding #address-cells = <0>; for all interrupt controllers in >>>>> TI device-tree files. Any other #address-cells value is really only needed >>>>> if interrupt-map property is being used (which is not the case for >>>>> existing >>>>> TI device-tree files) >>>>> >>>>> Signed-off-by: Sekhar Nori >>>>> --- >>>>>arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 5 + >>>>>arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi| 2 ++ >>>>>arch/arm64/boot/dts/ti/k3-am654-base-board.dts| 1 + >>>>>arch/arm64/boot/dts/ti/k3-j7200-main.dtsi | 3 +++ >>>>>arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi | 1 + >>>>>arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts | 1 + >>>>>arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 11 +++ >>>>>arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi | 3 +++ >>>>>8 files changed, 27 insertions(+) >>>>> >>>>> diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi >>>>> b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi >>>>> index aa8725db0187..55aaa1404d7d 100644 >>>>> --- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi >>>>> +++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi >>>>> @@ -440,6 +440,7 @@ >>>>> interrupt-controller; >>>>> interrupt-parent = <>; >>>>> #interrupt-cells = <1>; >>>>> + #address-cells = <0>; >>>> Does it really required or mandatory to have #address-cells = <0>; defined >>>> for interrupt-controller DT nodes which >>>> do not have child nodes and no "interrupt-map"? >>> >>> Just to help clarify (I could be mistaken as well): is'nt the >>> interrupt map for user interrupt map nodes that refer to this >>> interrupt controller node to state they dont need a parent address >>> specifier - so are we claiming none of the users will have an >>> interrupt-map (now and never in the future as well) - we we might want >>> to explain why we think that is the case, and if we are expecting dtc >>> to deduce that (if so how?)? >>> >> >> The main reason I commented - is hope to get some clarification from DT >> maintainers. >> 90% of interrupt-controller nodes do not have #address-cells and I never >> seen in in GPIO nodes >> (most often is present in PCI and GIC nodes). >> and nobody seems fixing it. So, if we are going to move this direction it's >> reasonable to get clarification to be sure. >> >> And there is no "never" here - #address-cells always can be added if really >> required. > > > OK - as a GPIO node, but as an interrupt-controller node, I was > looking at [1] and wondering if that was the precedence. > > Yes, will be good to get direction from the DT maintainers on this > topic. Shall I respin this series with 2/4 dropped while we wait for decision on this? #address-cells warnings on interrupt controller can perhaps be handled all at once (there are many of those in existing DT anyway). GPIO is basic support and holds up many other modules (like MMC/SD). Thanks, Sekhar
[PATCH v2 1/4] arm64: dts: ti: k3: squelch warning about lack of #interrupt-cells
There are couple of places where INTA interrupt controller lacks #interrupt-cells property. This leads to warnings of the type: arch/arm64/boot/dts/ti/k3-j721e-main.dtsi:147.51-156.5: Warning (interrupt_provider): /bus@10/main-navss/interrupt-controller@33d0: Missing #interrupt-cells in interrupt provider When building TI device-tree files with W=2 warning level. Fix these. Signed-off-by: Sekhar Nori --- arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 1 + arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 1 + 2 files changed, 2 insertions(+) diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi index 3eeb6e9876db..aa8725db0187 100644 --- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi +++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi @@ -473,6 +473,7 @@ interrupt-controller; interrupt-parent = <_main_navss>; msi-controller; + #interrupt-cells = <0>; ti,sci = <>; ti,sci-dev-id = <179>; ti,interrupt-ranges = <0 0 256>; diff --git a/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi b/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi index e2a96b2c423c..ffedd9531362 100644 --- a/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi +++ b/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi @@ -148,6 +148,7 @@ interrupt-controller; interrupt-parent = <_navss_intr>; msi-controller; + #interrupt-cells = <0>; ti,sci = <>; ti,sci-dev-id = <209>; ti,interrupt-ranges = <0 0 256>; -- 2.17.1
[PATCH v2 2/4] arm64: dts: ti: k3: squelch warnings regarding no #address-cells for interrupt-controller
With dtc 1.6.0, building TI device-tree files with W=2 results in warnings like below for all interrupt controllers. /bus@10/bus@3000/interrupt-controller1: Missing #address-cells in interrupt provider Fix these by adding #address-cells = <0>; for all interrupt controllers in TI device-tree files. Any other #address-cells value is really only needed if interrupt-map property is being used (which is not the case for existing TI device-tree files) Signed-off-by: Sekhar Nori --- arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 5 + arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi| 2 ++ arch/arm64/boot/dts/ti/k3-am654-base-board.dts| 1 + arch/arm64/boot/dts/ti/k3-j7200-main.dtsi | 3 +++ arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi | 1 + arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts | 1 + arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 11 +++ arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi | 3 +++ 8 files changed, 27 insertions(+) diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi index aa8725db0187..55aaa1404d7d 100644 --- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi +++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi @@ -440,6 +440,7 @@ interrupt-controller; interrupt-parent = <>; #interrupt-cells = <1>; + #address-cells = <0>; ti,sci = <>; ti,sci-dev-id = <100>; ti,interrupt-ranges = <0 392 32>; @@ -461,6 +462,7 @@ interrupt-controller; interrupt-parent = <>; #interrupt-cells = <1>; + #address-cells = <0>; ti,sci = <>; ti,sci-dev-id = <182>; ti,interrupt-ranges = <0 64 64>, @@ -474,6 +476,7 @@ interrupt-parent = <_main_navss>; msi-controller; #interrupt-cells = <0>; + #address-cells = <0>; ti,sci = <>; ti,sci-dev-id = <179>; ti,interrupt-ranges = <0 0 256>; @@ -670,6 +673,7 @@ interrupts = <192>, <193>, <194>, <195>, <196>, <197>; interrupt-controller; #interrupt-cells = <2>; + #address-cells = <0>; ti,ngpio = <96>; ti,davinci-gpio-unbanked = <0>; clocks = <_clks 57 0>; @@ -685,6 +689,7 @@ interrupts = <200>, <201>, <202>, <203>, <204>, <205>; interrupt-controller; #interrupt-cells = <2>; + #address-cells = <0>; ti,ngpio = <90>; ti,davinci-gpio-unbanked = <0>; clocks = <_clks 58 0>; diff --git a/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi index ed42f13e7663..7fe5782a1f79 100644 --- a/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi +++ b/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi @@ -75,6 +75,7 @@ interrupt-controller; interrupt-parent = <>; #interrupt-cells = <1>; + #address-cells = <0>; ti,sci = <>; ti,sci-dev-id = <156>; ti,interrupt-ranges = <0 712 16>; @@ -89,6 +90,7 @@ interrupts = <60>, <61>, <62>, <63>; interrupt-controller; #interrupt-cells = <2>; + #address-cells = <0>; ti,ngpio = <56>; ti,davinci-gpio-unbanked = <0>; clocks = <_clks 59 0>; diff --git a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts index d12dd89f3405..376de272cb4e 100644 --- a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts +++ b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts @@ -236,6 +236,7 @@ interrupts = <25 IRQ_TYPE_EDGE_FALLING>; interrupt-controller; #interrupt-cells = <2>; + #address-cells = <0>; }; }; diff --git a/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi b/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi index 72d6496e88dd..d07081b20aee 100644 --- a/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi +++ b/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi @@ -67,6 +67,7 @@ interrupt-controller; interrupt-parent = <>; #interrupt-cells = <1>; + #address-
[PATCH v2 3/4] arm64: dts: ti: k3-j7200: Add gpio nodes
From: Faiz Abbas
There are 4 instances of gpio modules in main domain:
gpio0, gpio2, gpio4 and gpio6
Groups are created to provide protection between different processor
virtual worlds. Each of these modules I/O pins are muxed within the
group. Exactly one module can be selected to control the corresponding
pin by selecting it in the pad mux configuration registers.
This group pins out 69 lines (5 banks). Add DT modes for each module
instance in the main domain.
Similar to the gpio groups in main domain, there is one gpio group in
wakeup domain with 2 mdoules instances in it.
The gpio group pins out 73 pins (5 banks). Add DT nodes for each module
instance in the wakeup domain.
Signed-off-by: Faiz Abbas
Signed-off-by: Sekhar Nori
---
arch/arm64/boot/dts/ti/k3-j7200-main.dtsi | 72 +++
.../boot/dts/ti/k3-j7200-mcu-wakeup.dtsi | 34 +
2 files changed, 106 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
b/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
index d07081b20aee..b313b895fd31 100644
--- a/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
@@ -449,4 +449,76 @@
dr_mode = "otg";
};
};
+
+ main_gpio0: gpio@60 {
+ compatible = "ti,j721e-gpio", "ti,keystone-gpio";
+ reg = <0x00 0x0060 0x00 0x100>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <_gpio_intr>;
+ interrupts = <145>, <146>, <147>, <148>,
+<149>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ #address-cells = <0>;
+ ti,ngpio = <69>;
+ ti,davinci-gpio-unbanked = <0>;
+ power-domains = <_pds 105 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <_clks 105 0>;
+ clock-names = "gpio";
+ };
+
+ main_gpio2: gpio@61 {
+ compatible = "ti,j721e-gpio", "ti,keystone-gpio";
+ reg = <0x00 0x0061 0x00 0x100>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <_gpio_intr>;
+ interrupts = <154>, <155>, <156>, <157>,
+<158>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ #address-cells = <0>;
+ ti,ngpio = <69>;
+ ti,davinci-gpio-unbanked = <0>;
+ power-domains = <_pds 107 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <_clks 107 0>;
+ clock-names = "gpio";
+ };
+
+ main_gpio4: gpio@62 {
+ compatible = "ti,j721e-gpio", "ti,keystone-gpio";
+ reg = <0x00 0x0062 0x00 0x100>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <_gpio_intr>;
+ interrupts = <163>, <164>, <165>, <166>,
+<167>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ #address-cells = <0>;
+ ti,ngpio = <69>;
+ ti,davinci-gpio-unbanked = <0>;
+ power-domains = <_pds 109 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <_clks 109 0>;
+ clock-names = "gpio";
+ };
+
+ main_gpio6: gpio@63 {
+ compatible = "ti,j721e-gpio", "ti,keystone-gpio";
+ reg = <0x00 0x0063 0x00 0x100>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <_gpio_intr>;
+ interrupts = <172>, <173>, <174>, <175>,
+<176>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ #address-cells = <0>;
+ ti,ngpio = <69>;
+ ti,davinci-gpio-unbanked = <0>;
+ power-domains = <_pds 111 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <_clks 111 0>;
+ clock-names = "gpio";
+ };
};
diff --git a/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
b/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
index 4801876bd107..a09e2157d80f 100644
--- a/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
@@ -108,6 +108,40 @@
ti,interrupt-ranges = <16 960 16>;
};
+ wkup_gpio0: gpio@4211 {
+ compati
[PATCH v2 0/4] arm64: dts: ti: J7200 GPIO support and warning fixes
These patches add gpio support for TI's J7200 platform. The first two patches fix existing warnings in preparation for adding GPIO support. Changes in v2: - Add patches fixing existing warnings so GPIO support does not end up adding more warnings - Addressed Nishanth's comments on GPIO patches - merge patches adding main and wakeup domain GPIOs into single patch - fix commit description going over 75 chars - fix W=2 warnings about lack of #address-cells in GPIO nodes Faiz Abbas (2): arm64: dts: ti: k3-j7200: Add gpio nodes arm64: dts: ti: k3-j7200-common-proc-board: Disable unused gpio modules Sekhar Nori (2): arm64: dts: ti: k3: squelch warning about lack of #interrupt-cells arm64: dts: ti: k3: squelch warnings regarding no #address-cells for interrupt-controller arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 6 ++ arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi| 2 + .../arm64/boot/dts/ti/k3-am654-base-board.dts | 1 + .../dts/ti/k3-j7200-common-proc-board.dts | 16 arch/arm64/boot/dts/ti/k3-j7200-main.dtsi | 75 +++ .../boot/dts/ti/k3-j7200-mcu-wakeup.dtsi | 35 + .../dts/ti/k3-j721e-common-proc-board.dts | 1 + arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 12 +++ .../boot/dts/ti/k3-j721e-mcu-wakeup.dtsi | 3 + 9 files changed, 151 insertions(+) -- 2.17.1
[PATCH v2 4/4] arm64: dts: ti: k3-j7200-common-proc-board: Disable unused gpio modules
From: Faiz Abbas
There are 6 gpio instances inside SoC with 2 groups as show below:
Group one: wkup_gpio0, wkup_gpio1
Group two: main_gpio0, main_gpio2, main_gpio4, main_gpio6
Only one instance from each group can be used at a time. So use main_gpio0
and wkup_gpio0 in current linux context and disable the rest of the nodes.
Signed-off-by: Faiz Abbas
Signed-off-by: Sekhar Nori
---
.../boot/dts/ti/k3-j7200-common-proc-board.dts | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
b/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
index ef03e7636b66..0bc4170225d5 100644
--- a/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
+++ b/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
@@ -127,6 +127,22 @@
status = "disabled";
};
+_gpio2 {
+ status = "disabled";
+};
+
+_gpio4 {
+ status = "disabled";
+};
+
+_gpio6 {
+ status = "disabled";
+};
+
+_gpio1 {
+ status = "disabled";
+};
+
_cpsw {
pinctrl-names = "default";
pinctrl-0 = <_cpsw_pins_default _mdio_pins_default>;
--
2.17.1
Re: [PATCH 1/3] arm64: dts: ti: k3-j7200-main: Add gpio nodes in main domain
On 14/11/20 9:45 AM, Grygorii Strashko wrote:
> Hi
>
> On 13/11/2020 22:55, Nishanth Menon wrote:
>> On 00:39-20201114, Sekhar Nori wrote:
>>>
>>> I was using the latest schema from master. But I changed to 2020.08.1
>>> also, and still don't see the warning.
>>>
>>> $ dt-doc-validate --version
>>> 2020.12.dev1+gab5a73fcef26
>>>
>>> I dont have a system-wide dtc installed. One in kernel tree is updated.
>>>
>>> $ scripts/dtc/dtc --version
>>> Version: DTC 1.6.0-gcbca977e
>>>
>>> Looking at your logs, it looks like you have more patches than just this
>>> applied. I wonder if thats making a difference. Can you check with just
>>> these patches applied to linux-next or share your tree which includes
>>> other patches?
>>>
>>> In your logs, you have such error for other interrupt controller nodes
>>> as well. For example:
>>>
>>> arch/arm64/boot/dts/ti/k3-j7200-main.dtsi:
>>> /bus@10/bus@3000/interrupt-controller1: Missing #address-cells
>>> in interrupt provider
>>>
>>> Which I don't see in my logs. My guess is some other patch(es) in your
>>> patch stack either uncovers this warning or causes it.
>>
>> Oh boy! I sent you and myself on wild goose chase! Really sorry about
>> messing up in the report of bug.
>>
>> It is not dtbs_check, it is building dtbs with W=2 that generates this
>> warning. dtc 1.6.0 is sufficient to reproduce this behavior.
>>
>> Using v5.10-rc1 as baseline (happens the same with next-20201113 as
>> well.
>>
>> v5.10-rc1: https://pastebin.ubuntu.com/p/Pn9HDqRjQ4/ (recording:
>> https://asciinema.org/a/55YVpql9Bq8rh8fePTxI2xObO)
>>
>> v5.10-rc1 + 1st patch in the series(since we are testing):
>> https://pastebin.ubuntu.com/p/QWQRMSv565/ (recording:
>> https://asciinema.org/a/ZSKZkOY13l4lmZ2xWH34jMlM1)
>>
>> Diff: https://pastebin.ubuntu.com/p/239sYYT2QY/
>>
>
> This warning come from scripts/dtc/checks.c
> and was introduced by commit 3eb619b2f7d8 ("scripts/dtc: Update to
> upstream version v1.6.0-11-g9d7888cbf19c").
>
> In my opinion it's false warning as there is no requirement to have
> #address-cells in interrupt provider node.
> by the way, above commit description says: "The interrupt_provider check
> is noisy, so turn it off for now."
Adding Andre who adding this check in upstream dtc for guidance.
It looks like address-cells makes sense only if there is an
interrupt-map specified as well. Since we don't use it, I can add
#address-cells = <0>;
to silence the warning. Let me know if there is a better way to deal
with this.
Thanks,
Sekhar
Re: [PATCH 1/3] arm64: dts: ti: k3-j7200-main: Add gpio nodes in main domain
On 14/11/20 12:10 AM, Nishanth Menon wrote: > On 23:59-20201113, Sekhar Nori wrote: > [..] >>> dtbs_check: we added: >>> arch/arm64/boot/dts/ti/k3-j7200-main.dtsi: /bus@10/gpio@60: Missing >>> #address-cells in interrupt provider >>> arch/arm64/boot/dts/ti/k3-j7200-main.dtsi: /bus@10/gpio@61: Missing >>> #address-cells in interrupt provider >>> arch/arm64/boot/dts/ti/k3-j7200-main.dtsi: /bus@10/gpio@62: Missing >>> #address-cells in interrupt provider >>> arch/arm64/boot/dts/ti/k3-j7200-main.dtsi: /bus@10/gpio@63: Missing >>> #address-cells in interrupt provider >> >> Hmm, running dtbs_check, I did not really see this. These are all the >> warnings I see for TI platforms: https://pastebin.ubuntu.com/p/m2my62mjQq/ > > Here is the full list of checks I ran through with kernel_patch_verify > (docker) > https://pastebin.ubuntu.com/p/tcnWw89CMD/ > > See lines 128 onwards for this series. kernel_patch_verify does'nt > complain on existing warnings, but just prints when there are additional > ones added in. Also make sure we have the right dtc as well > dtc 1.6.0 and dt_schema 2020.8.1 was used. I was using the latest schema from master. But I changed to 2020.08.1 also, and still don't see the warning. $ dt-doc-validate --version 2020.12.dev1+gab5a73fcef26 I dont have a system-wide dtc installed. One in kernel tree is updated. $ scripts/dtc/dtc --version Version: DTC 1.6.0-gcbca977e Looking at your logs, it looks like you have more patches than just this applied. I wonder if thats making a difference. Can you check with just these patches applied to linux-next or share your tree which includes other patches? In your logs, you have such error for other interrupt controller nodes as well. For example: arch/arm64/boot/dts/ti/k3-j7200-main.dtsi: /bus@10/bus@3000/interrupt-controller1: Missing #address-cells in interrupt provider Which I don't see in my logs. My guess is some other patch(es) in your patch stack either uncovers this warning or causes it. > >> >> The tree I am testing is linux-next of 12th Nov + these three patches >> applied. >> >> Also, #address-cells for interrupt provider being compulsory does not >> make full sense to me. Nothing in >> Documentation/devicetree/bindings/interrupt-controller/interrupts.txt or >> Documentation/devicetree/bindings/gpio/gpio-davinci.txt suggests that as >> well. >> >> Existing GPIO nodes for AM654 or J721E does not have #address-cells as well. >> >> Adding Grygorii as well, in case he knows more about this. > > > Yes - we need to have this conversation in the community :) I had > tagged this internally already during the 5.10 merge cycle that we > need to clean up the #address-cells warning and in some cases, maybe > the bindings are probably not accurate to attempt an enforcement. > I'd really like a conclusion on the topic as I recollect Lokesh and > Grygorii had a debate internally, but reached no conclusion, lets get > the wisdom of the community to help us here. Adding Lokesh to cc as well. Thanks, Sekhar
Re: [PATCH 1/3] arm64: dts: ti: k3-j7200-main: Add gpio nodes in main domain
Hi Nishanth, On 12/11/20 10:09 PM, Nishanth Menon wrote: > On 00:41-20201103, Faiz Abbas wrote: >> There are 4 instances of gpio modules in main domain: >> gpio0, gpio2, gpio4 and gpio6 >> >> Groups are created to provide protection between different processor virtual >> worlds. Each of these modules I/O pins are muxed within the group. Exactly >> one module can be selected to control the corresponding pin by selecting it >> in the pad mux configuration registers. > Could you check with checkpatch --strict please? > > I see: > > WARNING: Possible unwrapped commit description (prefer a maximum 75 chars per > line) > >> >> This group pins out 69 lines (5 banks). >> >> Add DT modes for each module instance in the main domain. >> >> Signed-off-by: Faiz Abbas >> --- >> arch/arm64/boot/dts/ti/k3-j7200-main.dtsi | 68 +++ > > dtbs_check: we added: > arch/arm64/boot/dts/ti/k3-j7200-main.dtsi: /bus@10/gpio@60: Missing > #address-cells in interrupt provider > arch/arm64/boot/dts/ti/k3-j7200-main.dtsi: /bus@10/gpio@61: Missing > #address-cells in interrupt provider > arch/arm64/boot/dts/ti/k3-j7200-main.dtsi: /bus@10/gpio@62: Missing > #address-cells in interrupt provider > arch/arm64/boot/dts/ti/k3-j7200-main.dtsi: /bus@10/gpio@63: Missing > #address-cells in interrupt provider Hmm, running dtbs_check, I did not really see this. These are all the warnings I see for TI platforms: https://pastebin.ubuntu.com/p/m2my62mjQq/ The tree I am testing is linux-next of 12th Nov + these three patches applied. Also, #address-cells for interrupt provider being compulsory does not make full sense to me. Nothing in Documentation/devicetree/bindings/interrupt-controller/interrupts.txt or Documentation/devicetree/bindings/gpio/gpio-davinci.txt suggests that as well. Existing GPIO nodes for AM654 or J721E does not have #address-cells as well. Adding Grygorii as well, in case he knows more about this. Thanks, Sekhar
Re: [PATCH v3] arm64: defconfig: Enable GPIO and I2C configs for TI's J721e platform
On 13/11/20 10:34 PM, Nishanth Menon wrote: > On 21:19-20201113, Sekhar Nori wrote: >> From: Faiz Abbas >> >> Add configs to help enable regulators that supply power to the SD card >> on TI's J721e platform. These regulators are controlled by either >> SoC gpios or gpios over i2c expander. >> >> vmlinux size before and after patch follow: >> > Sekhar, > >> Before: >>text data bss dec hex filename >> 19755448 10376346 535572 306673661d3f266 vmlinux >> >> After: >>text data bss dec hex filename >> 19769232 10381390 536212 306868341d43e72 vmlinux >> >> difference is 19,468 (dec) >> >> Acked-by: Tero Kristo >> Signed-off-by: Faiz Abbas >> Signed-off-by: Sekhar Nori >> --- >> changes in v3: >> - add size delta as requested by Nishanth Menon > > https://git.kernel.org/pub/scm/linux/kernel/git/nmenon/linux.git/commit/?h=ti-k3-config-next=6b133f475a97a0839f02e3c0b937886b9adc2933 > > https://lore.kernel.org/linux-arm-kernel/20201103190821.30937-1-faiz_ab...@ti.com/ > > > Is this a duplicate patch? Looks like, please discard. For some reason, Faiz's v3 did not show-up in my inbox and v2 applied cleanly to linux-next/master. So I assume it was not refreshed. Thanks, Sekhar
[PATCH v3] arm64: defconfig: Enable GPIO and I2C configs for TI's J721e platform
From: Faiz Abbas Add configs to help enable regulators that supply power to the SD card on TI's J721e platform. These regulators are controlled by either SoC gpios or gpios over i2c expander. vmlinux size before and after patch follow: Before: textdata bss dec hex filename 1975544810376346 535572 306673661d3f266 vmlinux After: textdata bss dec hex filename 1976923210381390 536212 306868341d43e72 vmlinux difference is 19,468 (dec) Acked-by: Tero Kristo Signed-off-by: Faiz Abbas Signed-off-by: Sekhar Nori --- changes in v3: - add size delta as requested by Nishanth Menon arch/arm64/configs/defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index c5f404ce2eec..e44d3f438530 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -438,6 +438,7 @@ CONFIG_I2C_IMX=y CONFIG_I2C_IMX_LPI2C=y CONFIG_I2C_MESON=y CONFIG_I2C_MV64XXX=y +CONFIG_I2C_OMAP=y CONFIG_I2C_OWL=y CONFIG_I2C_PXA=y CONFIG_I2C_QCOM_CCI=m @@ -498,6 +499,7 @@ CONFIG_PINCTRL_SDM845=y CONFIG_PINCTRL_SM8150=y CONFIG_PINCTRL_SM8250=y CONFIG_GPIO_ALTERA=m +CONFIG_GPIO_DAVINCI=y CONFIG_GPIO_DWAPB=y CONFIG_GPIO_MB86S7X=y CONFIG_GPIO_MPC8XXX=y -- 2.17.1
Re: [RESEND PATCH] arm64: dts: ti: k3-j7200-mcu-wakeup: Enable ADC support
On 29/10/20 10:39 AM, Vignesh Raghavendra wrote: > J7200 has a single instance of 8 channel ADC in MCU domain. Add DT node > for the same. > > Signed-off-by: Vignesh Raghavendra Reviewed-by: Sekhar Nori Thanks, Sekhar
Re: [PATCH] ARM: davinci: fix kconfig dependency warning when !GPIOLIB
On 14/09/20 7:49 PM, Necip Fazil Yildiran wrote:
> When MACH_DAVINCI_DA830_EVM is enabled and GPIOLIB is disabled, it results
> in the following Kbuild warning:
>
> WARNING: unmet direct dependencies detected for GPIO_PCF857X
> Depends on [n]: GPIOLIB [=n] && I2C [=y]
> Selected by [y]:
> - MACH_DAVINCI_DA830_EVM [=y] && ARCH_DAVINCI [=y] && ARCH_DAVINCI_DA830
> [=y] && I2C [=y]
>
> The reason is that MACH_DAVINCI_DA830_EVM selects GPIO_PCF857X without
> depending on or selecting GPIOLIB while GPIO_PCF857X is subordinate to
> GPIOLIB.
>
> Honor the kconfig menu hierarchy to remove kconfig dependency warnings.
>
> Fixes: 77316f057526 ("davinci: DA830/OMAP-L137 EVM: use runtime detection for
> UI card")
> Signed-off-by: Necip Fazil Yildiran
Here too, I think changing to "imply GPIO_PCF857X if I2C" is better.
Thanks,
Sekhar
Re: [PATCH] ARM: davinci: fix kconfig dependency warning when !PINCTRL
Hi Necip,
On 14/09/20 6:08 PM, Necip Fazil Yildiran wrote:
> When ARCH_DAVINCI is enabled and PINCTRL is disabled, it results
> in the following Kbuild warning:
>
> WARNING: unmet direct dependencies detected for PINCTRL_SINGLE
> Depends on [n]: PINCTRL [=n] && OF [=y] && HAS_IOMEM [=y]
> Selected by [y]:
> - ARCH_DAVINCI [=y] && ARCH_MULTI_V5 [=y]
>
> The reason is that ARCH_DAVINCI selects PINCTRL_SINGLE without depending on
> or selecting PINCTRL while PINCTRL_SINGLE is subordinate to PINCTRL.
>
> Honor the kconfig menu hierarchy to remove kconfig dependency warnings.
>
> Fixes: f962396ce292 ("ARM: davinci: support multiplatform build for ARM v5")
> Signed-off-by: Necip Fazil Yildiran
I think its better to fix this by changing the "select PINCTRL_SINGLE"
to "imply PINCTRL_SINGLE". It should be valid to build a DaVinci kernel
without pinctrl support if bootloader is taking care of the pin muxing.
I would not recommend it, but its not illegal either.
While at it, I would drop the other "select PINCTRL" line under "config
MACH_DA8XX_DT". It should not be needed since ARCH_DAVINCI will imply
PINCTRL_SINGLE
Thanks,
Sekhar
Re: [PATCH v2 0/2] Add support for MMC/SD on j7200-evm
On 24/09/20 4:56 PM, Faiz Abbas wrote: > The following patches add dt support for MMC/SD on TI's j7200-evm. > > Currently, eMMC support upto HS200 speed and SD card supports upto high > speed speed mode. To be sure, the TRM calls for SD card speed up to DDR50. And I believe there is work going on to go higher too. That needs voltage switching though and can come in as follow-on patches. This is good first step. Reviewed-by: Sekhar Nori Thanks, Sekhar
Re: [PATCH v2 0/2] arm64: dts: ti: k3-j7200: Add HyperFlash related nodes
On 23/09/20 10:01 PM, Vignesh Raghavendra wrote: > This series adds HyperBus and HyperFlash nodes for TI's J7200 SoC Reviewed-by: Sekhar Nori
Re: [PATCH v2 0/2] J7200: Add I2C support
On 23/09/20 9:23 PM, Vignesh Raghavendra wrote: > Add I2C and I2C IO expanders nodes for J7200 > > v2: > Align reg address format with that of file's (s/0x0/0x00) Reviewed-by: Sekhar Nori
Re: [PATCH v6 0/2] PHY: Add new PHY attribute max_link_rate
On 16/09/20 6:13 PM, Vinod Koul wrote: > On 16-09-20, 15:18, Laurent Pinchart wrote: >> Hi Sekhar, >> >> On Wed, Sep 16, 2020 at 01:11:17PM +0530, Sekhar Nori wrote: >>> On 11/09/20 11:48 AM, Swapnil Jakhade wrote: >>>> This patch series adds a new PHY attribute max_link_rate. >>>> It also updates Cadence Torrent PHY driver to set attributes bus_width, >>>> max_link_rate and mode for DisplayPort. >>>> >>>> It includes following patches: >>>> >>>> 1. 0001-phy-Add-new-PHY-attribute-max_link_rate.patch >>>> This patch adds max_link_rate as a new PHY attribute. >>>> >>>> 2. 0002-phy-cadence-torrent-Set-Torrent-PHY-attributes.patch >>>> This patch sets PHY attributes in Cadence Torrent PHY driver. This will >>>> enable drivers using this PHY to read these properties. >>>> >>>> These attributes will be used in the Cadence MHDP DRM bridge driver [1] >>>> which is in the process of upstreaming. >>> >>> Can you please add these patches on an immutable branch/tag when you are >>> ready to apply them - will try to see if we can use it to get the >>> DisplayPort driver merged in v5.10 too. >>> >>> Hi Laurent, any other ideas on managing the dependency? >> >> I think that will work fine. > > Please pull tag phy-attrs-5.10 for phy tree Thanks Vinod! Swapnil, please be sure to let DRM maintainers know about the PHY tree and the tag they can use when the DP patches are ready for merge. Please keep Vinod in the loop too so he is aware of the tag being pulled. Thanks, Sekhar
Re: [PATCH v6 0/2] PHY: Add new PHY attribute max_link_rate
Hi Vinod, On 11/09/20 11:48 AM, Swapnil Jakhade wrote: > This patch series adds a new PHY attribute max_link_rate. > It also updates Cadence Torrent PHY driver to set attributes bus_width, > max_link_rate and mode for DisplayPort. > > It includes following patches: > > 1. 0001-phy-Add-new-PHY-attribute-max_link_rate.patch > This patch adds max_link_rate as a new PHY attribute. > > 2. 0002-phy-cadence-torrent-Set-Torrent-PHY-attributes.patch > This patch sets PHY attributes in Cadence Torrent PHY driver. This will > enable drivers using this PHY to read these properties. > > These attributes will be used in the Cadence MHDP DRM bridge driver [1] > which is in the process of upstreaming. Can you please add these patches on an immutable branch/tag when you are ready to apply them - will try to see if we can use it to get the DisplayPort driver merged in v5.10 too. Hi Laurent, any other ideas on managing the dependency? Thanks, Sekhar
Re: [PATCH v2] ARM: davinci: use simple i2c probe function
On 10/08/20 3:07 PM, Wolfram Sang wrote:
> On Sun, Aug 09, 2020 at 07:24:44PM +0200, Stephen Kitt wrote:
>> The i2c probe functions here don't use the id information provided in
>> their second argument, so the single-parameter i2c probe function
>> ("probe_new") can be used instead.
>>
>> This avoids scanning the identifier tables during probes.
>>
>> Signed-off-by: Stephen Kitt
>
> This is useful, helps deprecating the old probe method:
>
> Acked-by: Wolfram Sang
Queued for v5.10.
Thanks,
Sekhar
Re: [PATCH v5] phy: omap-usb2-phy: disable PHY charger detect
On 8/20/20 7:09 PM, Roger Quadros wrote: > AM654x PG1.0 has a silicon bug that D+ is pulled high after POR, which > could cause enumeration failure with some USB hubs. Disabling the > USB2_PHY Charger Detect function will put D+ into the normal state. > > This addresses Silicon Errata: > i2075 - "USB2PHY: USB2PHY Charger Detect is Enabled by Default Without VBUS > Presence" > > Signed-off-by: Roger Quadros + Vinod as well
Re: [PATCH v4 1/3] dt-binding: phy: convert ti,omap-usb2 to YAML
On 8/20/20 7:10 PM, Roger Quadros wrote: > Kishon, > > On 16/07/2020 11:22, Roger Quadros wrote: >> Move ti,omap-usb2 to its own YAML schema. >> >> Signed-off-by: Roger Quadros >> Reviewed-by: Rob Herring > > Can you please pick just this one patch from this series for -next? Thanks. + Vinod as well. Thanks, Sekhar
[PATCH v2 2/3] phy: ti: am654: simplify return handling
Checking return value after each regfield write becomes
hard to read quickly as number of writes increase.
Simplify by checking for error only once.
Signed-off-by: Sekhar Nori
---
drivers/phy/ti/phy-am654-serdes.c | 48 +--
1 file changed, 20 insertions(+), 28 deletions(-)
diff --git a/drivers/phy/ti/phy-am654-serdes.c
b/drivers/phy/ti/phy-am654-serdes.c
index 836193a71018..e73432a7bf0c 100644
--- a/drivers/phy/ti/phy-am654-serdes.c
+++ b/drivers/phy/ti/phy-am654-serdes.c
@@ -161,34 +161,32 @@ static void serdes_am654_disable_pll(struct serdes_am654
*phy)
static int serdes_am654_enable_txrx(struct serdes_am654 *phy)
{
- int ret;
+ int ret = 0;
/* Enable TX */
- ret = regmap_field_write(phy->fields[TX0_ENABLE], TX0_ENABLE_STATE);
- if (ret)
- return ret;
+ ret |= regmap_field_write(phy->fields[TX0_ENABLE], TX0_ENABLE_STATE);
/* Enable RX */
- ret = regmap_field_write(phy->fields[RX0_ENABLE], RX0_ENABLE_STATE);
+ ret |= regmap_field_write(phy->fields[RX0_ENABLE], RX0_ENABLE_STATE);
+
if (ret)
- return ret;
+ return -EIO;
return 0;
}
static int serdes_am654_disable_txrx(struct serdes_am654 *phy)
{
- int ret;
+ int ret = 0;
/* Disable TX */
- ret = regmap_field_write(phy->fields[TX0_ENABLE], TX0_DISABLE_STATE);
- if (ret)
- return ret;
+ ret |= regmap_field_write(phy->fields[TX0_ENABLE], TX0_DISABLE_STATE);
/* Disable RX */
- ret = regmap_field_write(phy->fields[RX0_ENABLE], RX0_DISABLE_STATE);
+ ret |= regmap_field_write(phy->fields[RX0_ENABLE], RX0_DISABLE_STATE);
+
if (ret)
- return ret;
+ return -EIO;
return 0;
}
@@ -311,19 +309,14 @@ static int serdes_am654_usb3_init(struct serdes_am654
*phy)
static int serdes_am654_pcie_init(struct serdes_am654 *phy)
{
- int ret;
+ int ret = 0;
- ret = regmap_field_write(phy->fields[CONFIG_VERSION], VERSION_VAL);
- if (ret)
- return ret;
+ ret |= regmap_field_write(phy->fields[CONFIG_VERSION], VERSION_VAL);
+ ret |= regmap_field_write(phy->fields[CMU_MASTER_CDN], 0x1);
+ ret |= regmap_field_write(phy->fields[L1_MASTER_CDN], 0x1);
- ret = regmap_field_write(phy->fields[CMU_MASTER_CDN], 0x1);
if (ret)
- return ret;
-
- ret = regmap_field_write(phy->fields[L1_MASTER_CDN], 0x1);
- if (ret)
- return ret;
+ return -EIO;
return 0;
}
@@ -345,20 +338,19 @@ static int serdes_am654_init(struct phy *x)
static int serdes_am654_reset(struct phy *x)
{
struct serdes_am654 *phy = phy_get_drvdata(x);
- int ret;
+ int ret = 0;
serdes_am654_disable_pll(phy);
serdes_am654_disable_txrx(phy);
- ret = regmap_field_write(phy->fields[POR_EN], 0x1);
- if (ret)
- return ret;
+ ret |= regmap_field_write(phy->fields[POR_EN], 0x1);
mdelay(1);
- ret = regmap_field_write(phy->fields[POR_EN], 0x0);
+ ret |= regmap_field_write(phy->fields[POR_EN], 0x0);
+
if (ret)
- return ret;
+ return -EIO;
return 0;
}
--
2.17.1
[PATCH v2 0/3] phy: ti: am654: improve PCIe enumeration performance
This patch series updates AM654x PCIe serdes settings to latest recommended by hardware. This fixes Gen2 enumeration issues seen previously. Series applies to v5.8-rc3 changes in v2: - Fix W=1 warning - Remove references to Gen3 issues because Gen3 is not supported due to errata on AM654x device. Sekhar Nori (3): phy: ti: am654: simplify regfield handling phy: ti: am654: simplify return handling phy: ti: am654: update PCIe serdes config drivers/phy/ti/phy-am654-serdes.c | 325 +++--- 1 file changed, 211 insertions(+), 114 deletions(-) -- 2.17.1
[PATCH v2 3/3] phy: ti: am654: update PCIe serdes config
Update PCIe serdes config to latest suggested for
hardware. This fixes cases of failure to enumerate
in Gen2 mode with some cards.
Signed-off-by: Sekhar Nori
---
drivers/phy/ti/phy-am654-serdes.c | 140 --
1 file changed, 135 insertions(+), 5 deletions(-)
diff --git a/drivers/phy/ti/phy-am654-serdes.c
b/drivers/phy/ti/phy-am654-serdes.c
index e73432a7bf0c..d249cc4dff4c 100644
--- a/drivers/phy/ti/phy-am654-serdes.c
+++ b/drivers/phy/ti/phy-am654-serdes.c
@@ -19,15 +19,38 @@
#include
#include
+#define CMU_R004 0x4
+#define CMU_R060 0x60
#define CMU_R07C 0x7c
-
+#define CMU_R088 0x88
+#define CMU_R0D0 0xd0
+#define CMU_R0E8 0xe8
+
+#define LANE_R048 0x248
+#define LANE_R058 0x258
+#define LANE_R06c 0x26c
+#define LANE_R070 0x270
+#define LANE_R070 0x270
+#define LANE_R19C 0x39c
+
+#define COMLANE_R004 0xa04
#define COMLANE_R138 0xb38
#define VERSION_VAL0x70
#define COMLANE_R190 0xb90
-
#define COMLANE_R194 0xb94
+#define COMRXEQ_R004 0x1404
+#define COMRXEQ_R008 0x1408
+#define COMRXEQ_R00C 0x140c
+#define COMRXEQ_R014 0x1414
+#define COMRXEQ_R018 0x1418
+#define COMRXEQ_R01C 0x141c
+#define COMRXEQ_R04C 0x144c
+#define COMRXEQ_R088 0x1488
+#define COMRXEQ_R094 0x1494
+#define COMRXEQ_R098 0x1498
+
#define SERDES_CTRL0x1fd0
#define WIZ_LANEXCTL_STS 0x1fe0
@@ -81,8 +104,33 @@ static struct regmap_config serdes_am654_regmap_config = {
};
enum serdes_am654_fields {
+ /* CMU PLL Control */
+ CMU_PLL_CTRL,
+
+ LANE_PLL_CTRL_RXEQ_RXIDLE,
+
+ /* CMU VCO bias current and VREG setting */
+ AHB_PMA_CM_VCO_VBIAS_VREG,
+ AHB_PMA_CM_VCO_BIAS_VREG,
+
+ AHB_PMA_CM_SR,
+ AHB_SSC_GEN_Z_O_20_13,
+
+ /* AHB PMA Lane Configuration */
+ AHB_PMA_LN_AGC_THSEL_VREGH,
+
+ /* AGC and Signal detect theshold for Gen3 */
+ AHB_PMA_LN_GEN3_AGC_SD_THSEL,
+
+ AHB_PMA_LN_RX_SELR_GEN3,
+ AHB_PMA_LN_TX_DRV,
+
/* CMU Master Reset */
CMU_MASTER_CDN,
+
+ /* P2S ring buffer initial startup pointer difference */
+ P2S_RBUF_PTR_DIFF,
+
CONFIG_VERSION,
/* Lane 1 Master Reset */
@@ -91,6 +139,42 @@ enum serdes_am654_fields {
/* CMU OK Status */
CMU_OK_I_0,
+ /* Mid-speed initial calibration control */
+ COMRXEQ_MS_INIT_CTRL_7_0,
+
+ /* High-speed initial calibration control */
+ COMRXEQ_HS_INIT_CAL_7_0,
+
+ /* Mid-speed recalibration control */
+ COMRXEQ_MS_RECAL_CTRL_7_0,
+
+ /* High-speed recalibration control */
+ COMRXEQ_HS_RECAL_CTRL_7_0,
+
+ /* ATT configuration */
+ COMRXEQ_CSR_ATT_CONFIG,
+
+ /* Edge based boost adaptation window length */
+ COMRXEQ_CSR_EBSTADAPT_WIN_LEN,
+
+ /* COMRXEQ control 3 & 4 */
+ COMRXEQ_CTRL_3_4,
+
+ /* COMRXEQ control 14, 15 and 16*/
+ COMRXEQ_CTRL_14_15_16,
+
+ /* Threshold for errors in pattern data */
+ COMRXEQ_CSR_DLEV_ERR_THRESH,
+
+ /* COMRXEQ control 25 */
+ COMRXEQ_CTRL_25,
+
+ /* Mid-speed rate change calibration control */
+ CSR_RXEQ_RATE_CHANGE_CAL_RUN_RATE2_O,
+
+ /* High-speed rate change calibration control */
+ COMRXEQ_HS_RCHANGE_CTRL_7_0,
+
/* Serdes reset */
POR_EN,
@@ -112,10 +196,33 @@ enum serdes_am654_fields {
};
static const struct reg_field serdes_am654_reg_fields[] = {
- [CMU_MASTER_CDN]= REG_FIELD(CMU_R07C, 24, 24),
+ [CMU_PLL_CTRL] = REG_FIELD(CMU_R004, 8, 15),
+ [AHB_PMA_CM_VCO_VBIAS_VREG] = REG_FIELD(CMU_R060, 8, 15),
+ [CMU_MASTER_CDN]= REG_FIELD(CMU_R07C, 24, 31),
+ [AHB_PMA_CM_VCO_BIAS_VREG] = REG_FIELD(CMU_R088, 24, 31),
+ [AHB_PMA_CM_SR] = REG_FIELD(CMU_R0D0, 24, 31),
+ [AHB_SSC_GEN_Z_O_20_13] = REG_FIELD(CMU_R0E8, 8, 15),
+ [LANE_PLL_CTRL_RXEQ_RXIDLE] = REG_FIELD(LANE_R048, 8, 15),
+ [AHB_PMA_LN_AGC_THSEL_VREGH]= REG_FIELD(LANE_R058, 16, 23),
+ [AHB_PMA_LN_GEN3_AGC_SD_THSEL] = REG_FIELD(LANE_R06c, 0, 7),
+ [AHB_PMA_LN_RX_SELR_GEN3] = REG_FIELD(LANE_R070, 16, 23),
+ [AHB_PMA_LN_TX_DRV] = REG_FIELD(LANE_R19C, 16, 23),
+ [P2S_RBUF_PTR_DIFF] = REG_FIELD(COMLANE_R004, 0, 7),
[CONFIG_VERSION]= REG_FIELD(COMLANE_R138, 16, 23),
- [L1_MASTER_CDN] = REG_FIELD(COMLANE_R190, 9, 9),
+ [L1_MASTER_CDN] = REG_FIELD(COMLANE_R190, 8, 15),
[CMU_OK_I_0]= REG_FIELD(COMLANE_R194, 19, 19),
+ [COMRXEQ_MS_INIT_CTRL
[PATCH v2 1/3] phy: ti: am654: simplify regfield handling
regfield handling in current driver code is made complicated
by having a separate regfield variable for each field which
is allocated individually.
This quickly gets unwieldy once number of regfields increase.
Instead, use an array of regfields which are allocated in a
loop.
Signed-off-by: Sekhar Nori
---
drivers/phy/ti/phy-am654-serdes.c | 161 +-
1 file changed, 68 insertions(+), 93 deletions(-)
diff --git a/drivers/phy/ti/phy-am654-serdes.c
b/drivers/phy/ti/phy-am654-serdes.c
index 0a166d5a6414..836193a71018 100644
--- a/drivers/phy/ti/phy-am654-serdes.c
+++ b/drivers/phy/ti/phy-am654-serdes.c
@@ -22,7 +22,7 @@
#define CMU_R07C 0x7c
#define COMLANE_R138 0xb38
-#define VERSION0x70
+#define VERSION_VAL0x70
#define COMLANE_R190 0xb90
@@ -80,27 +80,52 @@ static struct regmap_config serdes_am654_regmap_config = {
.max_register = 0x1ffc,
};
-static const struct reg_field cmu_master_cdn_o = REG_FIELD(CMU_R07C, 24, 24);
-static const struct reg_field config_version = REG_FIELD(COMLANE_R138, 16, 23);
-static const struct reg_field l1_master_cdn_o = REG_FIELD(COMLANE_R190, 9, 9);
-static const struct reg_field cmu_ok_i_0 = REG_FIELD(COMLANE_R194, 19, 19);
-static const struct reg_field por_en = REG_FIELD(SERDES_CTRL, 29, 29);
-static const struct reg_field tx0_enable = REG_FIELD(WIZ_LANEXCTL_STS, 29, 31);
-static const struct reg_field rx0_enable = REG_FIELD(WIZ_LANEXCTL_STS, 13, 15);
-static const struct reg_field pll_enable = REG_FIELD(WIZ_PLL_CTRL, 29, 31);
-static const struct reg_field pll_ok = REG_FIELD(WIZ_PLL_CTRL, 28, 28);
+enum serdes_am654_fields {
+ /* CMU Master Reset */
+ CMU_MASTER_CDN,
+ CONFIG_VERSION,
+
+ /* Lane 1 Master Reset */
+ L1_MASTER_CDN,
+
+ /* CMU OK Status */
+ CMU_OK_I_0,
+
+ /* Serdes reset */
+ POR_EN,
+
+ /* Tx Enable Value */
+ TX0_ENABLE,
+
+ /* Rx Enable Value */
+ RX0_ENABLE,
+
+ /* PLL Enable Value */
+ PLL_ENABLE,
+
+ /* PLL ready for use */
+ PLL_OK,
+
+ /* sentinel */
+ MAX_FIELDS
+
+};
+
+static const struct reg_field serdes_am654_reg_fields[] = {
+ [CMU_MASTER_CDN]= REG_FIELD(CMU_R07C, 24, 24),
+ [CONFIG_VERSION]= REG_FIELD(COMLANE_R138, 16, 23),
+ [L1_MASTER_CDN] = REG_FIELD(COMLANE_R190, 9, 9),
+ [CMU_OK_I_0]= REG_FIELD(COMLANE_R194, 19, 19),
+ [POR_EN]= REG_FIELD(SERDES_CTRL, 29, 29),
+ [TX0_ENABLE]= REG_FIELD(WIZ_LANEXCTL_STS, 29, 31),
+ [RX0_ENABLE]= REG_FIELD(WIZ_LANEXCTL_STS, 13, 15),
+ [PLL_ENABLE]= REG_FIELD(WIZ_PLL_CTRL, 29, 31),
+ [PLL_OK]= REG_FIELD(WIZ_PLL_CTRL, 28, 28),
+};
struct serdes_am654 {
struct regmap *regmap;
- struct regmap_field *cmu_master_cdn_o;
- struct regmap_field *config_version;
- struct regmap_field *l1_master_cdn_o;
- struct regmap_field *cmu_ok_i_0;
- struct regmap_field *por_en;
- struct regmap_field *tx0_enable;
- struct regmap_field *rx0_enable;
- struct regmap_field *pll_enable;
- struct regmap_field *pll_ok;
+ struct regmap_field *fields[MAX_FIELDS];
struct device *dev;
struct mux_control *control;
@@ -116,12 +141,12 @@ static int serdes_am654_enable_pll(struct serdes_am654
*phy)
int ret;
u32 val;
- ret = regmap_field_write(phy->pll_enable, PLL_ENABLE_STATE);
+ ret = regmap_field_write(phy->fields[PLL_ENABLE], PLL_ENABLE_STATE);
if (ret)
return ret;
- return regmap_field_read_poll_timeout(phy->pll_ok, val, val, 1000,
- PLL_LOCK_TIME);
+ return regmap_field_read_poll_timeout(phy->fields[PLL_OK], val, val,
+ 1000, PLL_LOCK_TIME);
}
static void serdes_am654_disable_pll(struct serdes_am654 *phy)
@@ -129,7 +154,7 @@ static void serdes_am654_disable_pll(struct serdes_am654
*phy)
struct device *dev = phy->dev;
int ret;
- ret = regmap_field_write(phy->pll_enable, PLL_DISABLE_STATE);
+ ret = regmap_field_write(phy->fields[PLL_ENABLE], PLL_DISABLE_STATE);
if (ret)
dev_err(dev, "Failed to disable PLL\n");
}
@@ -139,12 +164,12 @@ static int serdes_am654_enable_txrx(struct serdes_am654
*phy)
int ret;
/* Enable TX */
- ret = regmap_field_write(phy->tx0_enable, TX0_ENABLE_STATE);
+ ret = regmap_field_write(phy->fields[TX0_ENABLE], TX0_ENABLE_STATE);
if (ret)
return ret;
/* Enable RX */
- ret = regmap_field_wr
Re: [PATCH v4 0/2] Add new PHY APIs to framework to get/set PHY attributes
On 7/27/20 3:25 PM, Vinod Koul wrote: > Hi Sekhar, > > On 26-07-20, 01:24, Sekhar Nori wrote: >> Hi Vinod, >> >> On 7/17/20 12:20 PM, Swapnil Jakhade wrote: >>> This patch series adds a new pair of PHY APIs that can be used to get/set >>> all the PHY attributes. It also adds a new PHY attribute max_link_rate. >>> >>> It includes following patches: >>> >>> 1. v4-0001-phy-Add-new-PHY-attribute-max_link_rate-and-APIs-.patch >>> This patch adds max_link_rate as a new PHY attribute along with a pair of >>> APIs that allow using the generic PHY subsystem to get/set PHY attributes >>> supported by the PHY. >>> >>> 2. v4-0002-phy-cadence-torrent-Use-kernel-PHY-API-to-set-PHY.patch >>> This patch uses PHY API phy_set_attrs() to set corresponding PHY properties >>> in Cadence Torrent PHY driver. This will enable drivers using this PHY to >>> read these properties using PHY framework. >>> >>> The phy_get_attrs() API will be used in the DRM bridge driver [1] which is >>> in the process of upstreaming. >> >> Is it possible to queue these for v5.9 also? I did notice that phy >> updates for v5.9-rc1 are posted already. But these APIs are needed for >> the DisplayPort driver thats getting ready for merge too. Having these >> queued now will make managing dependencies much easier. > > I would prefer if we defer core change to post rc1. For your display, we > can provide a signed tag for you/drm folks to fetch. > > Would that be okay? Okay, that would work too. Thanks, Sekhar
Re: [PATCH v4 0/2] Add new PHY APIs to framework to get/set PHY attributes
Hi Vinod, On 7/17/20 12:20 PM, Swapnil Jakhade wrote: > This patch series adds a new pair of PHY APIs that can be used to get/set > all the PHY attributes. It also adds a new PHY attribute max_link_rate. > > It includes following patches: > > 1. v4-0001-phy-Add-new-PHY-attribute-max_link_rate-and-APIs-.patch > This patch adds max_link_rate as a new PHY attribute along with a pair of > APIs that allow using the generic PHY subsystem to get/set PHY attributes > supported by the PHY. > > 2. v4-0002-phy-cadence-torrent-Use-kernel-PHY-API-to-set-PHY.patch > This patch uses PHY API phy_set_attrs() to set corresponding PHY properties > in Cadence Torrent PHY driver. This will enable drivers using this PHY to > read these properties using PHY framework. > > The phy_get_attrs() API will be used in the DRM bridge driver [1] which is > in the process of upstreaming. Is it possible to queue these for v5.9 also? I did notice that phy updates for v5.9-rc1 are posted already. But these APIs are needed for the DisplayPort driver thats getting ready for merge too. Having these queued now will make managing dependencies much easier. Thanks, Sekhar
[PATCH 0/3] phy: ti: am654: improve PCIe enumeration performance
This patch series updates AM654x PCIe serdes settings to latest recommended by hardware. This fixes Gen2 enumeration issues and significantly improves Gen3 enumeration failures seen previously. Sekhar Nori (3): phy: ti: am654: simplify regfield handling phy: ti: am654: simplify return handling phy: ti: am654: update PCIe serdes config drivers/phy/ti/phy-am654-serdes.c | 325 +++--- 1 file changed, 212 insertions(+), 113 deletions(-) -- 2.17.1
[PATCH 1/3] phy: ti: am654: simplify regfield handling
regfield handling in current driver code is made complicated
by having a separate regfield variable for each field which
is allocated individually.
This quickly gets unwieldy once number of regfields increase.
Instead, use an array of regfields which are allocated in a
loop.
Signed-off-by: Sekhar Nori
---
drivers/phy/ti/phy-am654-serdes.c | 161 +-
1 file changed, 69 insertions(+), 92 deletions(-)
diff --git a/drivers/phy/ti/phy-am654-serdes.c
b/drivers/phy/ti/phy-am654-serdes.c
index 0a166d5a6414..ed7669c6a7a0 100644
--- a/drivers/phy/ti/phy-am654-serdes.c
+++ b/drivers/phy/ti/phy-am654-serdes.c
@@ -22,7 +22,7 @@
#define CMU_R07C 0x7c
#define COMLANE_R138 0xb38
-#define VERSION0x70
+#define VERSION_VAL0x70
#define COMLANE_R190 0xb90
@@ -80,27 +80,54 @@ static struct regmap_config serdes_am654_regmap_config = {
.max_register = 0x1ffc,
};
-static const struct reg_field cmu_master_cdn_o = REG_FIELD(CMU_R07C, 24, 24);
-static const struct reg_field config_version = REG_FIELD(COMLANE_R138, 16, 23);
-static const struct reg_field l1_master_cdn_o = REG_FIELD(COMLANE_R190, 9, 9);
-static const struct reg_field cmu_ok_i_0 = REG_FIELD(COMLANE_R194, 19, 19);
-static const struct reg_field por_en = REG_FIELD(SERDES_CTRL, 29, 29);
-static const struct reg_field tx0_enable = REG_FIELD(WIZ_LANEXCTL_STS, 29, 31);
-static const struct reg_field rx0_enable = REG_FIELD(WIZ_LANEXCTL_STS, 13, 15);
-static const struct reg_field pll_enable = REG_FIELD(WIZ_PLL_CTRL, 29, 31);
+enum serdes_am654_fields {
+ /* CMU Master Reset */
+ CMU_MASTER_CDN,
+ CONFIG_VERSION,
+
+ /* Lane 1 Master Reset */
+ L1_MASTER_CDN,
+
+ /* CMU OK Status */
+ CMU_OK_I_0,
+
+ /* Serdes reset */
+ POR_EN,
+
+ /* Tx Enable Value */
+ TX0_ENABLE,
+
+ /* Rx Enable Value */
+ RX0_ENABLE,
+
+ /* PLL Enable Value */
+ PLL_ENABLE,
+
+ /* PLL ready for use */
+ PLL_OK,
+
+ /* sentinel */
+ MAX_FIELDS
+
+};
+
+static const struct reg_field serdes_am654_reg_fields[] = {
+ [CMU_MASTER_CDN]= REG_FIELD(CMU_R07C, 24, 24),
+ [CONFIG_VERSION]= REG_FIELD(COMLANE_R138, 16, 23),
+ [L1_MASTER_CDN] = REG_FIELD(COMLANE_R190, 9, 9),
+ [CMU_OK_I_0]= REG_FIELD(COMLANE_R194, 19, 19),
+ [POR_EN]= REG_FIELD(SERDES_CTRL, 29, 29),
+ [TX0_ENABLE]= REG_FIELD(WIZ_LANEXCTL_STS, 29, 31),
+ [RX0_ENABLE]= REG_FIELD(WIZ_LANEXCTL_STS, 13, 15),
+ [PLL_ENABLE]= REG_FIELD(WIZ_PLL_CTRL, 29, 31),
+ [PLL_OK]= REG_FIELD(WIZ_PLL_CTRL, 28, 28),
+};
+
static const struct reg_field pll_ok = REG_FIELD(WIZ_PLL_CTRL, 28, 28);
struct serdes_am654 {
struct regmap *regmap;
- struct regmap_field *cmu_master_cdn_o;
- struct regmap_field *config_version;
- struct regmap_field *l1_master_cdn_o;
- struct regmap_field *cmu_ok_i_0;
- struct regmap_field *por_en;
- struct regmap_field *tx0_enable;
- struct regmap_field *rx0_enable;
- struct regmap_field *pll_enable;
- struct regmap_field *pll_ok;
+ struct regmap_field *fields[MAX_FIELDS];
struct device *dev;
struct mux_control *control;
@@ -116,12 +143,12 @@ static int serdes_am654_enable_pll(struct serdes_am654
*phy)
int ret;
u32 val;
- ret = regmap_field_write(phy->pll_enable, PLL_ENABLE_STATE);
+ ret = regmap_field_write(phy->fields[PLL_ENABLE], PLL_ENABLE_STATE);
if (ret)
return ret;
- return regmap_field_read_poll_timeout(phy->pll_ok, val, val, 1000,
- PLL_LOCK_TIME);
+ return regmap_field_read_poll_timeout(phy->fields[PLL_OK], val, val,
+ 1000, PLL_LOCK_TIME);
}
static void serdes_am654_disable_pll(struct serdes_am654 *phy)
@@ -129,7 +156,7 @@ static void serdes_am654_disable_pll(struct serdes_am654
*phy)
struct device *dev = phy->dev;
int ret;
- ret = regmap_field_write(phy->pll_enable, PLL_DISABLE_STATE);
+ ret = regmap_field_write(phy->fields[PLL_ENABLE], PLL_DISABLE_STATE);
if (ret)
dev_err(dev, "Failed to disable PLL\n");
}
@@ -139,12 +166,12 @@ static int serdes_am654_enable_txrx(struct serdes_am654
*phy)
int ret;
/* Enable TX */
- ret = regmap_field_write(phy->tx0_enable, TX0_ENABLE_STATE);
+ ret = regmap_field_write(phy->fields[TX0_ENABLE], TX0_ENABLE_STATE);
if (ret)
return ret;
/* Enable RX */
- ret = regmap_field_wr
[PATCH 2/3] phy: ti: am654: simplify return handling
Checking return value after each regfield write becomes
hard to read quickly as number of writes increase.
Simplify by checking for error only once.
Signed-off-by: Sekhar Nori
---
drivers/phy/ti/phy-am654-serdes.c | 48 +--
1 file changed, 20 insertions(+), 28 deletions(-)
diff --git a/drivers/phy/ti/phy-am654-serdes.c
b/drivers/phy/ti/phy-am654-serdes.c
index ed7669c6a7a0..f3d58853553d 100644
--- a/drivers/phy/ti/phy-am654-serdes.c
+++ b/drivers/phy/ti/phy-am654-serdes.c
@@ -163,34 +163,32 @@ static void serdes_am654_disable_pll(struct serdes_am654
*phy)
static int serdes_am654_enable_txrx(struct serdes_am654 *phy)
{
- int ret;
+ int ret = 0;
/* Enable TX */
- ret = regmap_field_write(phy->fields[TX0_ENABLE], TX0_ENABLE_STATE);
- if (ret)
- return ret;
+ ret |= regmap_field_write(phy->fields[TX0_ENABLE], TX0_ENABLE_STATE);
/* Enable RX */
- ret = regmap_field_write(phy->fields[RX0_ENABLE], RX0_ENABLE_STATE);
+ ret |= regmap_field_write(phy->fields[RX0_ENABLE], RX0_ENABLE_STATE);
+
if (ret)
- return ret;
+ return -EIO;
return 0;
}
static int serdes_am654_disable_txrx(struct serdes_am654 *phy)
{
- int ret;
+ int ret = 0;
/* Disable TX */
- ret = regmap_field_write(phy->fields[TX0_ENABLE], TX0_DISABLE_STATE);
- if (ret)
- return ret;
+ ret |= regmap_field_write(phy->fields[TX0_ENABLE], TX0_DISABLE_STATE);
/* Disable RX */
- ret = regmap_field_write(phy->fields[RX0_ENABLE], RX0_DISABLE_STATE);
+ ret |= regmap_field_write(phy->fields[RX0_ENABLE], RX0_DISABLE_STATE);
+
if (ret)
- return ret;
+ return -EIO;
return 0;
}
@@ -313,19 +311,14 @@ static int serdes_am654_usb3_init(struct serdes_am654
*phy)
static int serdes_am654_pcie_init(struct serdes_am654 *phy)
{
- int ret;
+ int ret = 0;
- ret = regmap_field_write(phy->fields[CONFIG_VERSION], VERSION_VAL);
- if (ret)
- return ret;
+ ret |= regmap_field_write(phy->fields[CONFIG_VERSION], VERSION_VAL);
+ ret |= regmap_field_write(phy->fields[CMU_MASTER_CDN], 0x1);
+ ret |= regmap_field_write(phy->fields[L1_MASTER_CDN], 0x1);
- ret = regmap_field_write(phy->fields[CMU_MASTER_CDN], 0x1);
if (ret)
- return ret;
-
- ret = regmap_field_write(phy->fields[L1_MASTER_CDN], 0x1);
- if (ret)
- return ret;
+ return -EIO;
return 0;
}
@@ -347,20 +340,19 @@ static int serdes_am654_init(struct phy *x)
static int serdes_am654_reset(struct phy *x)
{
struct serdes_am654 *phy = phy_get_drvdata(x);
- int ret;
+ int ret = 0;
serdes_am654_disable_pll(phy);
serdes_am654_disable_txrx(phy);
- ret = regmap_field_write(phy->fields[POR_EN], 0x1);
- if (ret)
- return ret;
+ ret |= regmap_field_write(phy->fields[POR_EN], 0x1);
mdelay(1);
- ret = regmap_field_write(phy->fields[POR_EN], 0x0);
+ ret |= regmap_field_write(phy->fields[POR_EN], 0x0);
+
if (ret)
- return ret;
+ return -EIO;
return 0;
}
--
2.17.1
[PATCH 3/3] phy: ti: am654: update PCIe serdes config
Update PCIe serdes config to latest suggested for
hardware. This fixes cases of failure to enumerate
in Gen2 mode with some cards. It also improves Gen3
enumeration, but occassional failures still exist.
Signed-off-by: Sekhar Nori
---
drivers/phy/ti/phy-am654-serdes.c | 140 --
1 file changed, 135 insertions(+), 5 deletions(-)
diff --git a/drivers/phy/ti/phy-am654-serdes.c
b/drivers/phy/ti/phy-am654-serdes.c
index f3d58853553d..980bf9187bd7 100644
--- a/drivers/phy/ti/phy-am654-serdes.c
+++ b/drivers/phy/ti/phy-am654-serdes.c
@@ -19,15 +19,38 @@
#include
#include
+#define CMU_R004 0x4
+#define CMU_R060 0x60
#define CMU_R07C 0x7c
-
+#define CMU_R088 0x88
+#define CMU_R0D0 0xd0
+#define CMU_R0E8 0xe8
+
+#define LANE_R048 0x248
+#define LANE_R058 0x258
+#define LANE_R06c 0x26c
+#define LANE_R070 0x270
+#define LANE_R070 0x270
+#define LANE_R19C 0x39c
+
+#define COMLANE_R004 0xa04
#define COMLANE_R138 0xb38
#define VERSION_VAL0x70
#define COMLANE_R190 0xb90
-
#define COMLANE_R194 0xb94
+#define COMRXEQ_R004 0x1404
+#define COMRXEQ_R008 0x1408
+#define COMRXEQ_R00C 0x140c
+#define COMRXEQ_R014 0x1414
+#define COMRXEQ_R018 0x1418
+#define COMRXEQ_R01C 0x141c
+#define COMRXEQ_R04C 0x144c
+#define COMRXEQ_R088 0x1488
+#define COMRXEQ_R094 0x1494
+#define COMRXEQ_R098 0x1498
+
#define SERDES_CTRL0x1fd0
#define WIZ_LANEXCTL_STS 0x1fe0
@@ -81,8 +104,33 @@ static struct regmap_config serdes_am654_regmap_config = {
};
enum serdes_am654_fields {
+ /* CMU PLL Control */
+ CMU_PLL_CTRL,
+
+ LANE_PLL_CTRL_RXEQ_RXIDLE,
+
+ /* CMU VCO bias current and VREG setting */
+ AHB_PMA_CM_VCO_VBIAS_VREG,
+ AHB_PMA_CM_VCO_BIAS_VREG,
+
+ AHB_PMA_CM_SR,
+ AHB_SSC_GEN_Z_O_20_13,
+
+ /* AHB PMA Lane Configuration */
+ AHB_PMA_LN_AGC_THSEL_VREGH,
+
+ /* AGC and Signal detect theshold for Gen3 */
+ AHB_PMA_LN_GEN3_AGC_SD_THSEL,
+
+ AHB_PMA_LN_RX_SELR_GEN3,
+ AHB_PMA_LN_TX_DRV,
+
/* CMU Master Reset */
CMU_MASTER_CDN,
+
+ /* P2S ring buffer initial startup pointer difference */
+ P2S_RBUF_PTR_DIFF,
+
CONFIG_VERSION,
/* Lane 1 Master Reset */
@@ -91,6 +139,42 @@ enum serdes_am654_fields {
/* CMU OK Status */
CMU_OK_I_0,
+ /* Mid-speed initial calibration control */
+ COMRXEQ_MS_INIT_CTRL_7_0,
+
+ /* High-speed initial calibration control */
+ COMRXEQ_HS_INIT_CAL_7_0,
+
+ /* Mid-speed recalibration control */
+ COMRXEQ_MS_RECAL_CTRL_7_0,
+
+ /* High-speed recalibration control */
+ COMRXEQ_HS_RECAL_CTRL_7_0,
+
+ /* ATT configuration */
+ COMRXEQ_CSR_ATT_CONFIG,
+
+ /* Edge based boost adaptation window length */
+ COMRXEQ_CSR_EBSTADAPT_WIN_LEN,
+
+ /* COMRXEQ control 3 & 4 */
+ COMRXEQ_CTRL_3_4,
+
+ /* COMRXEQ control 14, 15 and 16*/
+ COMRXEQ_CTRL_14_15_16,
+
+ /* Threshold for errors in pattern data */
+ COMRXEQ_CSR_DLEV_ERR_THRESH,
+
+ /* COMRXEQ control 25 */
+ COMRXEQ_CTRL_25,
+
+ /* Mid-speed rate change calibration control */
+ CSR_RXEQ_RATE_CHANGE_CAL_RUN_RATE2_O,
+
+ /* High-speed rate change calibration control */
+ COMRXEQ_HS_RCHANGE_CTRL_7_0,
+
/* Serdes reset */
POR_EN,
@@ -112,10 +196,33 @@ enum serdes_am654_fields {
};
static const struct reg_field serdes_am654_reg_fields[] = {
- [CMU_MASTER_CDN]= REG_FIELD(CMU_R07C, 24, 24),
+ [CMU_PLL_CTRL] = REG_FIELD(CMU_R004, 8, 15),
+ [AHB_PMA_CM_VCO_VBIAS_VREG] = REG_FIELD(CMU_R060, 8, 15),
+ [CMU_MASTER_CDN]= REG_FIELD(CMU_R07C, 24, 31),
+ [AHB_PMA_CM_VCO_BIAS_VREG] = REG_FIELD(CMU_R088, 24, 31),
+ [AHB_PMA_CM_SR] = REG_FIELD(CMU_R0D0, 24, 31),
+ [AHB_SSC_GEN_Z_O_20_13] = REG_FIELD(CMU_R0E8, 8, 15),
+ [LANE_PLL_CTRL_RXEQ_RXIDLE] = REG_FIELD(LANE_R048, 8, 15),
+ [AHB_PMA_LN_AGC_THSEL_VREGH]= REG_FIELD(LANE_R058, 16, 23),
+ [AHB_PMA_LN_GEN3_AGC_SD_THSEL] = REG_FIELD(LANE_R06c, 0, 7),
+ [AHB_PMA_LN_RX_SELR_GEN3] = REG_FIELD(LANE_R070, 16, 23),
+ [AHB_PMA_LN_TX_DRV] = REG_FIELD(LANE_R19C, 16, 23),
+ [P2S_RBUF_PTR_DIFF] = REG_FIELD(COMLANE_R004, 0, 7),
[CONFIG_VERSION]= REG_FIELD(COMLANE_R138, 16, 23),
- [L1_MASTER_CDN] = REG_FIELD(COMLANE_R190, 9, 9),
+ [L1_MASTER_CDN] = REG_FIELD(COMLANE_R190, 8, 15),
[CMU_OK
Re: [PATCH v2 1/8] arch: arm: mach-davinci: Fix trivial spelling
On 7/16/20 1:32 PM, Bartosz Golaszewski wrote:
> On Wed, Jul 15, 2020 at 2:48 PM Kieran Bingham
> wrote:
>>
>> The word 'descriptor' is misspelled throughout the tree.
>>
>> Fix it up accordingly:
>> decriptors -> descriptors
>>
>> Signed-off-by: Kieran Bingham
>> ---
>> arch/arm/mach-davinci/board-da830-evm.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/mach-davinci/board-da830-evm.c
>> b/arch/arm/mach-davinci/board-da830-evm.c
>> index a273ab25c668..1076886938b6 100644
>> --- a/arch/arm/mach-davinci/board-da830-evm.c
>> +++ b/arch/arm/mach-davinci/board-da830-evm.c
>> @@ -266,7 +266,7 @@ static struct mtd_partition da830_evm_nand_partitions[]
>> = {
>> }
>> };
>>
>> -/* flash bbt decriptors */
>> +/* flash bbt descriptors */
>> static uint8_t da830_evm_nand_bbt_pattern[] = { 'B', 'b', 't', '0' };
>> static uint8_t da830_evm_nand_mirror_pattern[] = { '1', 't', 'b', 'B' };
>>
>> --
>> 2.25.1
>>
>
> Reviewed-by: Bartosz Golaszewski
Fixed up subject prefix to "ARM: davinci: " for consistency, and applied.
Thanks,
Sekhar
Re: [PATCH for v5.9] ARM: mach-davinci: Replace HTTP links with HTTPS ones
On 7/19/20 3:50 PM, Alexander A. Klimov wrote: > Rationale: > Reduces attack surface on kernel devs opening the links for MITM > as HTTPS traffic is much harder to manipulate. > > Deterministic algorithm: > For each file: > If not .svg: > For each line: > If doesn't contain `\bxmlns\b`: > For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`: > If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`: > If both the HTTP and HTTPS versions > return 200 OK and serve the same content: > Replace HTTP with HTTPS. > > Signed-off-by: Alexander A. Klimov > diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts > index f2e7609e5346..87c517d65f62 100644 > --- a/arch/arm/boot/dts/da850-evm.dts > +++ b/arch/arm/boot/dts/da850-evm.dts > @@ -2,7 +2,7 @@ > /* > * Device Tree for DA850 EVM board > * > - * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/ > + * Copyright (C) 2012 Texas Instruments Incorporated - https://www.ti.com/ > */ > /dts-v1/; > #include "da850.dtsi" > diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig > index d028d38a44bf..5b0125f1265c 100644 > --- a/arch/arm/mach-davinci/Kconfig > +++ b/arch/arm/mach-davinci/Kconfig > @@ -201,7 +201,7 @@ config MACH_MITYOMAPL138 > help > Say Y here to select the Critical Link MityDSP-L138/MityARM-1808 > System on Module. Information on this SoM may be found at > - http://www.mitydsp.com > + https://www.mitydsp.com > > config MACH_OMAPL138_HAWKBOARD > bool "TI AM1808 / OMAPL-138 Hawkboard platform" > @@ -209,7 +209,7 @@ config MACH_OMAPL138_HAWKBOARD > help > Say Y here to select the TI AM1808 / OMAPL-138 Hawkboard platform . > Information of this board may be found at > - http://www.hawkboard.org/ > + https://www.hawkboard.org/ This now redirects to something irrelevant. So, dropped the URL altogether. Also, we use prefix "ARM: davinci: " in subject line. I made those changes locally and committed the patch. Will try to send for v5.9, but its getting quite late. Thanks, Sekhar
Re: [PATCH] clocksource/drivers/timer-ti-dm: Fix suspend and resume for am3 and am4
On 7/20/20 8:00 PM, Tony Lindgren wrote:
> * Carlos Hernandez [200717 21:35]:
>> On 7/17/20 6:29 AM, Daniel Lezcano wrote:
>>> On 13/07/2020 18:26, Tony Lindgren wrote:
Fixes: 52762fbd1c47 ("clocksource/drivers/timer-ti-dm: Add clockevent and
clocksource support")
Reported-by: Carlos Hernandez
Signed-off-by: Tony Lindgren
---
>>> Carlos, were you able to test this patch ?
>>
>> Tested the patch on top of 5.8-rc5.
>>
>> cbdb2617290d (HEAD) clocksource/drivers/timer-ti-dm: Fix suspend and resume
>> for am3 and am4
>> 11ba468877bb (tag: v5.8-rc5) Linux 5.8-rc5
>>
>> It works on am335x-evm but fails on am437x-evm
>
> Thanks for testing.
>
>> am4:
>>
>> ** 1196 printk messages dropped **
>
> The above does not look normal..
>
>> 4400.ocp:L3 Custom Error: MASTER DSS TARGET GPMC (Read)
>> ** 34 printk messages dropped **
>
> ..but the above points to the GPMC module failing to suspend.
> This seems to be some other GPMC specific issue not related
> to the system timers.
So, I guess this patch can still go into v5.8 while the AM437x GP EVM
failures are root caused.
Carlos, Daniel is looking for your tested by. Can you send it because it
fixes the original problem report with dmtimer?
Thanks,
Sekhar
Re: [PATCH] ARM: dts: keystone-k2g-evm: fix rgmii phy-mode for ksz9031 phy
Hi Santosh,
On 7/15/20 2:24 PM, Grygorii Strashko wrote:
> Since commit bcf3440c6dd7 ("net: phy: micrel: add phy-mode support for the
> KSZ9031 PHY") the networking is broken on keystone-k2g-evm board.
>
> The above board have phy-mode = "rgmii-id" and it is worked before because
> KSZ9031 PHY started with default RGMII internal delays configuration (TX
> off, RX on 1.2 ns) and MAC provided TX delay by default.
> After above commit, the KSZ9031 PHY starts handling phy mode properly and
> enables both RX and TX delays, as result networking is become broken.
>
> Fix it by switching to phy-mode = "rgmii-rxid" to reflect previous
> behavior.
>
> Cc: Oleksij Rempel
> Cc: Andrew Lunn
> Cc: Philippe Schenker
> Fixes: bcf3440c6dd7 ("net: phy: micrel: add phy-mode support for the KSZ9031
> PHY")
> Signed-off-by: Grygorii Strashko
> ---
> Fix for one more broken TI board with KSZ9031 PHY.
This is coming bit late, but its important to get into v5.8 since NFS
boot fails without this blocking all mainline testing for this platform.
Can we send this to ARM SoC for -rc7. If you are going to be busy this
week, I am happy to send a pull request on your behalf with your ack
included. Let me know.
Thanks,
Sekhar
Re: [PATCH 7/7] arm64: defconfig: Enable AM654x SDHCI controller
On 7/16/20 5:49 PM, Faiz Abbas wrote: > Hi, > > On 19/06/20 6:28 pm, Faiz Abbas wrote: >> Enable CONFIG_SDHCI_AM654 to Support AM65x sdhci controller. >> >> Signed-off-by: Faiz Abbas >> --- >> arch/arm64/configs/defconfig | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig >> index 883e8bace3ed..40dd13e0adc5 100644 >> --- a/arch/arm64/configs/defconfig >> +++ b/arch/arm64/configs/defconfig >> @@ -731,6 +731,7 @@ CONFIG_MMC_DW_ROCKCHIP=y >> CONFIG_MMC_SUNXI=y >> CONFIG_MMC_BCM2835=y >> CONFIG_MMC_SDHCI_XENON=y >> +CONFIG_MMC_SDHCI_AM654=y >> CONFIG_MMC_OWL=y >> CONFIG_NEW_LEDS=y >> CONFIG_LEDS_CLASS=y >> > > Gentle ping. Will, Catalin, can this patch be picked up? >From logs, Arnd has been picking up patches for this file. Looping in Arnd and ARM-SoC team. Thanks, Sekhar
Re: [PATCH] ARM: davinci: dm644x-evm: Add Fixed regulators needed for tlv320aic33
On 17/10/19 4:37 PM, Sekhar Nori wrote: > On 30/08/19 3:53 PM, Peter Ujfalusi wrote: >> The codec driver needs correct regulators in order to probe. >> Both VCC_3.3V and VCC_1.8V is always on fixed regulators on the board. >> >> Signed-off-by: Peter Ujfalusi > > Applied for v5.4 This too causes DM644x boot to break. I can enable DEBUG_LL and post logs, but I suspect they will look very similar to the DM365 case. Thanks, Sekhar
Re: [PATCH] ARM: davinci: dm365-evm: Add Fixed regulators needed for tlv320aic3101
On 17/10/19 4:39 PM, Sekhar Nori wrote: > On 30/08/19 3:52 PM, Peter Ujfalusi wrote: >> The codec driver needs correct regulators in order to probe. >> Both VCC_3V3 and VCC_1V8 is always on fixed regulators on the board. >> >> Signed-off-by: Peter Ujfalusi > > Applied for v5.4 This is breaking boot on DM365 EVM. Booting Linux on physical CPU 0x0 Linux version 5.4.0-rc1-1-g927d10a85791-dirty (a0875516@psplinux063) (gcc v9 CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=0005317f CPU: VIVT data cache, VIVT instruction cache Machine: DaVinci DM365 EVM Memory policy: Data cache writethrough cma: Reserved 16 MiB at 0x86c0 DaVinci dm365_rev1.1 variant 0x0 On node 0 totalpages: 32768 DMA zone: 256 pages used for memmap DMA zone: 0 pages reserved DMA zone: 32768 pages, LIFO batch:7 pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 pcpu-alloc: [0] 0 Built 1 zonelists, mobility grouping on. Total pages: 32512 Kernel command line: console=ttyS0,115200n8 root=/dev/nfs rw nfsroot=172.24.210p Dentry cache hash table entries: 16384 (order: 4, 65536 bytes, linear) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes, linear) mem auto-init: stack:off, heap alloc:off, heap free:off Memory: 106776K/131072K available (4760K kernel code, 253K rwdata, 1160K rodata) SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 rcu: Preemptible hierarchical RCU implementation. Tasks RCU enabled. rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies. NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16 random: get_random_bytes called from start_kernel+0x25c/0x440 with crng_init=0 clocksource: timer0_1: mask: 0x max_cycles: 0x, max_idle_ns: 79s sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 89478484971ns Console: colour dummy device 80x30 Calibrating delay loop... 146.84 BogoMIPS (lpj=734208) pid_max: default: 32768 minimum: 301 Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear) Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear) CPU: Testing write buffer coherency: ok Setting up static identity map for 0x80008400 - 0x80008458 rcu: Hierarchical SRCU implementation. devtmpfs: initialized clocksource: jiffies: mask: 0x max_cycles: 0x, max_idle_ns: 191s futex hash table entries: 256 (order: -1, 3072 bytes, linear) pinctrl core: initialized pinctrl subsystem NET: Registered protocol family 16 DMA: preallocated 256 KiB pool for atomic coherent allocations mux: initialized INT_EDMA_CC mux: Setting register INT_EDMA_CC mux:INTMUX (0x0018) = 0x -> 0x0004 cpuidle: using governor menu mux: initialized INT_EMAC_RXTHRESH mux: Setting register INT_EMAC_RXTHRESH mux:INTMUX (0x0018) = 0x0004 -> 0x4004 mux: initialized INT_EMAC_RXPULSE mux: Setting register INT_EMAC_RXPULSE mux:INTMUX (0x0018) = 0x4004 -> 0xc004 mux: initialized INT_EMAC_TXPULSE mux: Setting register INT_EMAC_TXPULSE mux:INTMUX (0x0018) = 0xc004 -> 0x0001c004 mux: initialized INT_EMAC_MISCPULSE mux: Setting register INT_EMAC_MISCPULSE mux:I
Re: [PATCH] ARM: davinci: dm365: Fix McBSP dma_slave_map entry
On 30/08/19 3:52 PM, Peter Ujfalusi wrote:
> dm365 have only single McBSP, so the device name is without .0
>
> Fixes: 0c750e1fe481d ("ARM: davinci: dm365: Add dma_slave_map to edma")
> Signed-off-by: Peter Ujfalusi
Applied for v5.4
Thanks,
Sekhar
Re: [PATCH] ARM: davinci: dm365-evm: Add Fixed regulators needed for tlv320aic3101
On 30/08/19 3:52 PM, Peter Ujfalusi wrote: > The codec driver needs correct regulators in order to probe. > Both VCC_3V3 and VCC_1V8 is always on fixed regulators on the board. > > Signed-off-by: Peter Ujfalusi Applied for v5.4 Thanks, Sekhar
Re: [PATCH] ARM: davinci: dm644x-evm: Add Fixed regulators needed for tlv320aic33
On 30/08/19 3:53 PM, Peter Ujfalusi wrote: > The codec driver needs correct regulators in order to probe. > Both VCC_3.3V and VCC_1.8V is always on fixed regulators on the board. > > Signed-off-by: Peter Ujfalusi Applied for v5.4 Thanks, Sekhar
Re: [PATCH v2 linux-next 2/4] arm: configs: davinci_all_defconfig: Change CONFIG_REMOTEPROC from m to y
On 20/09/19 1:29 PM, Keerthy wrote:
> Commit 6334150e9a36 ("remoteproc: don't allow modular build")
> changes CONFIG_REMOTEPROC to a boolean from a tristate config
> option which inhibits all defconfigs marking CONFIG_REMOTEPROC as
> a module in compiling the remoteproc and dependent config options.
>
> So fix the davinci_all_defconfig to have CONFIG_REMOTEPROC built in.
>
> Fixes: 6334150e9a36 ("remoteproc: don't allow modular build")
> Signed-off-by: Keerthy
> ---
> arch/arm/configs/davinci_all_defconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/configs/davinci_all_defconfig
> b/arch/arm/configs/davinci_all_defconfig
> index b34970ce6b31..01e3c0f4be92 100644
> --- a/arch/arm/configs/davinci_all_defconfig
> +++ b/arch/arm/configs/davinci_all_defconfig
> @@ -228,7 +228,7 @@ CONFIG_RTC_DRV_OMAP=m
> CONFIG_DMADEVICES=y
> CONFIG_TI_EDMA=y
> CONFIG_COMMON_CLK_PWM=m
> -CONFIG_REMOTEPROC=m
> +CONFIG_REMOTEPROC=y
Acked-by: Sekhar Nori
Thanks,
Sekhar
Re: [PATCH v2 0/5] ARM: make DaVinci part of the ARM v5 multiplatform build
On 08/09/19 7:01 PM, Bartosz Golaszewski wrote: > sob., 7 wrz 2019 o 10:21 Arnd Bergmann napisał(a): >> >> On Wed, Aug 28, 2019 at 9:55 AM Bartosz Golaszewski >> wrote: >>> śr., 28 sie 2019 o 09:44 Sekhar Nori napisał(a): >>> >>> Actually I tested this without the clocksource conversion and it works >>> - the previous driver still selects relevant config options. But I >>> think you're right - it's worth picking up all the bug fixes from this >>> series and then merging the rest once dm365 issue is fixed. >> >> I just had another look at the series and found that the driver fixes >> (patches 1 and 2) are queued in linux-next, and patch 3 was merged. >> >> If you like, I could put the remaining two patches into the arm/late branch >> and send that after the media and staging trees are merged into mainline. >> >> Arnd > > Sure! Makes sense. > > Sekhar: this series doesn't break current mainline (i.e. without the > clocksource series) so I think we're safe even for dm365. Yes, I boot/NFS tested the two patches applied on latest linux-next on on all 6 DaVinci SoCs. I have acked the patches in case Arnd will apply them directly to ARM-SoC. Thanks, Sekhar
Re: [PATCH v2 4/5] ARM: davinci: support multiplatform build for ARM v5
On 25/07/19 6:42 PM, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski > > Add modifications necessary to make davinci part of the ARM v5 > multiplatform build. > > Move the arch-specific configuration out of arch/arm/Kconfig and > into mach-davinci/Kconfig. Remove the sub-menu for DaVinci > implementations (they'll be visible directly under the system type. > Select all necessary options not already selected by ARCH_MULTI_V5. > Update davinci_all_defconfig. Explicitly include the mach-specific > headers in mach-davinci/Makefile. > > Signed-off-by: Bartosz Golaszewski Acked-by: Sekhar Nori Thanks, Sekhar
Re: [PATCH v2 5/5] ARM: multi_v5_defconfig: make DaVinci part of the ARM v5 multiplatform build
On 25/07/19 6:42 PM, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski > > Add all DaVinci boards to multi_v5_defconfig. > > Signed-off-by: Bartosz Golaszewski Acked-by: Sekhar Nori Thanks, Sekhar
Re: [PATCH v2 0/5] ARM: make DaVinci part of the ARM v5 multiplatform build
On 28/08/19 1:03 PM, Bartosz Golaszewski wrote: > pon., 5 sie 2019 o 10:31 Bartosz Golaszewski napisał(a): >> >> czw., 25 lip 2019 o 16:57 Arnd Bergmann napisał(a): >>> >>> On Thu, Jul 25, 2019 at 3:13 PM Bartosz Golaszewski wrote: From: Bartosz Golaszewski This series makes DaVinci part of the multiplatform build for ARM v5. First three patches fix build errors spotted and fixed by Arnd with v1. The fourth patch adds necessary bits and pieces for davinci to support multiplatform build and the last one actually adds all davinci boards to multi_v5_defconfig. Tested on da850-lcdk with both multi_v5 as well as davinci_all defconfigs. v1 -> v2: - added patches from Arnd that fix build errors spotted when building random configurations (much appreciated) - rebased on top of v5.3-rc1 >>> Arnd Bergmann (3): staging: media/davinci_vpfe: fix pinmux setup compilation media: davinci-vpbe: remove obsolete includes davinci: fix sleep.S build error on ARMv4 Bartosz Golaszewski (2): ARM: davinci: support multiplatform build for ARM v5 ARM: multi_v5_defconfig: make DaVinci part of the ARM v5 multiplatform build >>> >>> >>> Thanks a lot for reposting the series! >>> >>> I wonder how we shoud deal with the dependencies now that the two media >>> patches got merged in the linux-media tree. >>> >>> It would be tempting to just merge the arch/arm/ changes, but that creates >>> a bisection problem when the vpbe driver is enabled. I don't care >>> about the staging driver really as that one is broken anyway, but including >>> the "media: davinci-vpbe: remove obsolete includes" fix would be better >>> here. >>> >>> Mauro, any idea for how to handle that? Should we apply an identical >>> patch to the davinci tree, or maybe only have it the ARM tree and you >>> drop it from your tree (I don't know if you have a rule against rebasing). >>> Sorry for not coordinating with Bartosz before I sent the patch again >>> earlier this week. >>> >>> >>> Arnd >> >> Hi Arnd, >> >> is there any action required from me for this series? >> >> Bart > > Ping. I dont think the multi-platform parts can be merged in v5.4 since we dont have DM365 converted successfully to use clocksource driver yet. But other parts of the series can be merged and hopefully we resolve that pending issue for v5.5 Thanks, Sekhar
Re: [PATCH] ARM: davinci: dm646x: Fix a typo in the comment
On 23/07/19 3:06 AM, Christophe JAILLET wrote: > The driver is dedicated to DM646x. So update the description in the top > most comment accordingly. > > It must have been derived from dm644x.c, but looks DM646 speecific now. > > Signed-off-by: Christophe JAILLET Applied to my v5.4/soc branch. Thanks, Sekhar
Re: [PATCH] ARM: dts: da850-evm: Use generic jedec, spi-nor for flash
On 23/07/19 5:40 PM, Adam Ford wrote: > Logic PD re-spun the L138 and AM1808 SOM's with larger flash. > The m25p80 driver has a generic 'jedec,spi-nor' compatible option > which is requests to use whenever possible since it will read the > JEDEC READ ID opcode. > > Signed-off-by: Adam Ford Applied to v5.4/dt Thanks, Sekhar
Re: [RESEND PATCH 00/10] ARM: davinci: use the new clocksource driver
On 08/08/19 1:11 PM, Bartosz Golaszewski wrote: > śr., 7 sie 2019 o 21:28 Sekhar Nori napisał(a): >> >> On 05/08/19 1:59 PM, Bartosz Golaszewski wrote: >>> pon., 22 lip 2019 o 15:17 Bartosz Golaszewski napisał(a): >>>> >>>> From: Bartosz Golaszewski >>>> >>>> Sekhar, >>>> >>>> the following patches switch DaVinci to using the new clocksource driver >>>> which >>>> is now upstream. They are rebased on top of v5.3-rc1. Additionally the >>>> following two patches were reverted locally due to a regression in v5.3-rc1 >>>> about which the relevant maintainers have been already notified: >>>> >>>> 2eef1399a866 modules: fix BUG when load module with rodata=n >>>> 93651f80dcb6 modules: fix compile error if don't have strict module rwx >>>> >>>> Bartosz Golaszewski (10): >>>> ARM: davinci: enable the clocksource driver for DT mode >>>> ARM: davinci: WARN_ON() if clk_get() fails >>>> ARM: davinci: da850: switch to using the clocksource driver >>>> ARM: davinci: da830: switch to using the clocksource driver >>>> ARM: davinci: move timer definitions to davinci.h >>>> ARM: davinci: dm355: switch to using the clocksource driver >>>> ARM: davinci: dm365: switch to using the clocksource driver >>>> ARM: davinci: dm644x: switch to using the clocksource driver >>>> ARM: davinci: dm646x: switch to using the clocksource driver >>>> ARM: davinci: remove legacy timer support >>>> >>>> arch/arm/Kconfig| 1 + >>>> arch/arm/mach-davinci/Makefile | 3 +- >>>> arch/arm/mach-davinci/da830.c | 45 +-- >>>> arch/arm/mach-davinci/da850.c | 50 +-- >>>> arch/arm/mach-davinci/davinci.h | 3 + >>>> arch/arm/mach-davinci/devices-da8xx.c | 1 - >>>> arch/arm/mach-davinci/devices.c | 19 - >>>> arch/arm/mach-davinci/dm355.c | 28 +- >>>> arch/arm/mach-davinci/dm365.c | 26 +- >>>> arch/arm/mach-davinci/dm644x.c | 28 +- >>>> arch/arm/mach-davinci/dm646x.c | 28 +- >>>> arch/arm/mach-davinci/include/mach/common.h | 17 - >>>> arch/arm/mach-davinci/include/mach/time.h | 35 -- >>>> arch/arm/mach-davinci/time.c| 414 >>>> 14 files changed, 110 insertions(+), 588 deletions(-) >>>> delete mode 100644 arch/arm/mach-davinci/include/mach/time.h >>>> delete mode 100644 arch/arm/mach-davinci/time.c >>>> >>>> -- >>>> 2.21.0 >>>> >>> >>> Hi Sekhar, >>> >>> a gentle ping. Is this series good to go in for v5.4? >> >> Hi Bartosz, a quick test shows that DM365 fails to boot after this. Can >> you please see if there is anything obviously wrong for that SoC. Rest >> seems to be okay. >> >> Thanks, >> Sekhar > > Hi Sekhar, > > just verified on Kevin's dm365-evm rebased on top of v5.3-rc3 and it > boots fine. I know that davinci failed to boot at v5.3-rc1. > > Let me know if I can help with debugging. Added series except 7/10 and 10/10 to v5.4/soc. Debug of DM365 issue is still going on offline. DM365 migration is postponed pending conclusion of that debug. Thanks, Sekhar
Re: [PATCH v2 0/9] ARM: davinci: da850-evm: remove more legacy GPIO calls
On 05/08/19 2:00 PM, Bartosz Golaszewski wrote: > pon., 22 lip 2019 o 15:44 Bartosz Golaszewski napisał(a): >> >> From: Bartosz Golaszewski >> >> This is another small step on the path to liberating davinci from legacy >> GPIO API calls and shrinking the davinci GPIO driver by not having to >> support the base GPIO number anymore. >> >> This time we're removing the legacy calls used indirectly by the LCDC >> fbdev driver. >> >> First two patches enable the GPIO backlight driver in >> davinci_all_defconfig. >> >> Patch 3/12 models the backlight GPIO as an actual GPIO backlight device. >> >> Patches 4-6 extend the fbdev driver with regulator support and convert >> the da850-evm board file to using it. >> >> Last three patches are improvements to the da8xx fbdev driver since >> we're already touching it in this series. >> >> v1 -> v2: >> - dopped the gpio-backlight patches from this series as since v5.3-rc1 we >> can probe the module with neither the OF node nor platform data >> - collected review and ack tags >> - rebased on top of v5.3-rc1 >> >> Bartosz Golaszewski (9): >> ARM: davinci: refresh davinci_all_defconfig >> ARM: davinci_all_defconfig: enable GPIO backlight >> ARM: davinci: da850-evm: model the backlight GPIO as an actual device >> fbdev: da8xx: add support for a regulator >> ARM: davinci: da850-evm: switch to using a fixed regulator for lcdc >> fbdev: da8xx: remove panel_power_ctrl() callback from platform data >> fbdev: da8xx-fb: use devm_platform_ioremap_resource() >> fbdev: da8xx-fb: drop a redundant if >> fbdev: da8xx: use resource management for dma >> >> arch/arm/configs/davinci_all_defconfig | 27 ++ >> arch/arm/mach-davinci/board-da850-evm.c | 90 +- >> drivers/video/fbdev/da8xx-fb.c | 118 +--- >> include/video/da8xx-fb.h| 1 - >> 4 files changed, 141 insertions(+), 95 deletions(-) >> >> -- >> 2.21.0 >> > > Hi Sekhar, > > the fbdev patches have been acked by Bartlomiej. I think the entire > series can go through the ARM-SoC tree. Applied for v5.4. Will queue through ARM-SoC. Thanks, Sekhar
Re: [RESEND PATCH 00/10] ARM: davinci: use the new clocksource driver
On 05/08/19 1:59 PM, Bartosz Golaszewski wrote: > pon., 22 lip 2019 o 15:17 Bartosz Golaszewski napisał(a): >> >> From: Bartosz Golaszewski >> >> Sekhar, >> >> the following patches switch DaVinci to using the new clocksource driver >> which >> is now upstream. They are rebased on top of v5.3-rc1. Additionally the >> following two patches were reverted locally due to a regression in v5.3-rc1 >> about which the relevant maintainers have been already notified: >> >> 2eef1399a866 modules: fix BUG when load module with rodata=n >> 93651f80dcb6 modules: fix compile error if don't have strict module rwx >> >> Bartosz Golaszewski (10): >> ARM: davinci: enable the clocksource driver for DT mode >> ARM: davinci: WARN_ON() if clk_get() fails >> ARM: davinci: da850: switch to using the clocksource driver >> ARM: davinci: da830: switch to using the clocksource driver >> ARM: davinci: move timer definitions to davinci.h >> ARM: davinci: dm355: switch to using the clocksource driver >> ARM: davinci: dm365: switch to using the clocksource driver >> ARM: davinci: dm644x: switch to using the clocksource driver >> ARM: davinci: dm646x: switch to using the clocksource driver >> ARM: davinci: remove legacy timer support >> >> arch/arm/Kconfig| 1 + >> arch/arm/mach-davinci/Makefile | 3 +- >> arch/arm/mach-davinci/da830.c | 45 +-- >> arch/arm/mach-davinci/da850.c | 50 +-- >> arch/arm/mach-davinci/davinci.h | 3 + >> arch/arm/mach-davinci/devices-da8xx.c | 1 - >> arch/arm/mach-davinci/devices.c | 19 - >> arch/arm/mach-davinci/dm355.c | 28 +- >> arch/arm/mach-davinci/dm365.c | 26 +- >> arch/arm/mach-davinci/dm644x.c | 28 +- >> arch/arm/mach-davinci/dm646x.c | 28 +- >> arch/arm/mach-davinci/include/mach/common.h | 17 - >> arch/arm/mach-davinci/include/mach/time.h | 35 -- >> arch/arm/mach-davinci/time.c| 414 >> 14 files changed, 110 insertions(+), 588 deletions(-) >> delete mode 100644 arch/arm/mach-davinci/include/mach/time.h >> delete mode 100644 arch/arm/mach-davinci/time.c >> >> -- >> 2.21.0 >> > > Hi Sekhar, > > a gentle ping. Is this series good to go in for v5.4? Hi Bartosz, a quick test shows that DM365 fails to boot after this. Can you please see if there is anything obviously wrong for that SoC. Rest seems to be okay. Thanks, Sekhar
Re: [PATCH] media: staging: davinci: remove vpfe driver
On 23/07/19 4:14 PM, Arnd Bergmann wrote: > The davinci_vpfe driver was merged into staging back in 2012 by Manjunath > Hadli from TI, with a long TODO list. > > For all I can tell, since then it has only seen fixes for compile-time > issues and global cleanups, but nobody has actually worked on the items > on the TODO list. > > To make things worse, the driver in its current form is incompatible with > the platform code in arch/arm/mach-davinci, i.e. the driver expects to > get its platform_data passed to the device as a 'struct vpfe_config', > but uses a differnet definition for that structure compared to what the > platform uses. > > Finally, there is another driver for the same device in > drivers/media/platform/davinci/vpfe_capture.c. From all I can tell, the > staging version was originally a copy of a more featureful driver in TI's > downstream kernels. However, that kernel no longer supports dm365 after > linux-2.6.37, and the mainline version moved in a different direction. > > Signed-off-by: Arnd Bergmann Acked-by: Sekhar Nori Thanks, Sekhar
Re: [PATCH] staging: media/davinci_vpfe: fix pinmux setup compilation
Hi Arnd, On 22/07/19 1:42 PM, Arnd Bergmann wrote: > The dm365_isif staging driver uses an odd method for configuring its > pin muxing by calling directly into low-level davinci platform specific > code, even when being compile-tested for other platforms. > > As we want davinci to be part of a multi-platform kernel, this will > cause a build failure when those headers are no longer exported even > for davinci: > > drivers/staging/media/davinci_vpfe/dm365_isif.c: In function 'vpfe_isif_init': > drivers/staging/media/davinci_vpfe/dm365_isif.c:2031:2: error: implicit > declaration of function 'davinci_cfg_reg'; did you mean 'omap_cfg_reg'? > [-Werror=implicit-function-declaration] > davinci_cfg_reg(DM365_VIN_CAM_WEN); > ^~~ > omap_cfg_reg > drivers/staging/media/davinci_vpfe/dm365_isif.c:2031:18: error: > 'DM365_VIN_CAM_WEN' undeclared (first use in this function); did you mean > 'DM365_ISIF_MAX_CLDC'? > davinci_cfg_reg(DM365_VIN_CAM_WEN); > ^ > > Digging further, it seems that the platform data structures defined > in drivers/staging/media/davinci_vpfe/vpfe.h are an incompatible > version of the same structures in include/media/davinci/vpfe_capture.h, > which is the version that is used by the platform code, so the > combination that exists in the mainline kernel cannot be used. > > The platform code already has an abstraction for the pinmux, > in the form of the dm365_isif_setup_pinmux() helper. If we want > to ever get to use the staging driver again, this needs to be > read from the platform data passed to this driver, or rewritten > to use the pinmux framework. > > For the moment, pretend we pass the helper function in the > staging platform driver to get it to build cleanly. I could > not figure out how the staging driver relates to the code > in drivers/media/platform/davinci/, some clarification on that > would be helpful to decide what the long-term plan on this > should be to either remove the staging driver as obsolete or > integrate it with the rest in a way that actually works. > > Signed-off-by: Arnd Bergmann I looked at the history of updates on this driver over last 4 years. None of them are towards fixing some issue found with the driver during actual usage or for improving its design to move it out of staging. I think no one is really using it or working on moving it out of staging. Perhaps the right thing to do would be to delete it. Thanks, Sekhar
Re: linux-next: build failure after merge of the usb and usb-gadget trees
On 04/07/19 1:55 PM, Felipe Balbi wrote:
>
> Hi,
>
> Pawel Laszczak writes:
>
>>>
>>> Hi,
>>>
>>> On Thu, Jul 4, 2019 at 9:59 AM Greg KH wrote:
On Thu, Jul 04, 2019 at 04:34:58PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the usb tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> arm-linux-gnueabi-ld: drivers/usb/dwc3/trace.o: in function
> `trace_raw_output_dwc3_log_ctrl':
> trace.c:(.text+0x119c): undefined reference to `usb_decode_ctrl'
>
> Caused by commit
>
> 3db1b636c07e ("usb:gadget Separated decoding functions from dwc3
> driver.")
>
> I have used the usb tree from next-20190703 for today.
>
> This also occurs in the usb-gadget tree so I have used the version of
> that from next-20190703 as well.
Odd, I thought I pulled the usb-gadget tree into mine. Felipe, can you
take a look at this to see if I messed something up?
>>>
>>> This looks like it was caused by Pawel's patches.
>>>
>>> I'll try to reproduce here and see what's causing it.
>>
>> Problem is in my Patch. I reproduced it, but I don't understand why compiler
>> complains about usb_decode_ctrl. It's compiled into libcomposite.ko and
>> declaration is in drivers/usb/gadget.h.
>
> That's because in multi_v7_defconfig dwc3 is built-in while libcomposite
> is a module:
>
> CONFIG_USB_DWC3=y
> CONFIG_USB_LIBCOMPOSITE=m
>
>
> I remember that when you were doing this work, I asked you to move
> functions to usb/common. Why did you deviate from that suggestion? It's
> clear that decoding a ctrl request can be used by peripheral and host
> and we wouldn't have to deal with this problem if you had just followed
> the suggestion.
>
> Now we have to come up with a way to fix this that doesn't involve
> reverting my part2 tag in its entirety because there are other important
> things there.
>
> This is what I get for trusting people to do their part. I couldn't even
> compile test this since I don't have ARM compilers anymore (actually,
> just installed to test). Your customer, however, uses ARM cores so I
> would expect you to have at least compile tested this on ARM. How come
> this wasn't verified by anybody at TI?
>
> TI used to have automated testing for many of the important defconfigs,
> is that completely gone? Are you guys relying entirely on linux-next?
I just checked back to see what happened here. In our product kernel
(which does undergo build test with multiple defconfigs), we are using
v6 of these patches which did not have this issue.
I think 0-day kbuild tester could have caught the issue as well. Within
boundaries of existing infrastructure, that probably was the best bet
here. Not sure why that did not happen (probably just build scheduling).
Thanks,
Sekhar
Re: [PATCH 1/2] ARM: davinci: da830-evm: add missing regulator constraints for OHCI
On 25/06/19 10:19 PM, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> We need to enable status changes for the fixed power supply for the USB
> controller.
>
> Fixes: 274e4c336192 ("ARM: davinci: da830-evm: add a fixed regulator for
> ohci-da8xx")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Bartosz Golaszewski
For both these patches as well, the offending commit was introduced in
v5.2 so I dropped the stable tag while applying.
Will send pull request tomorrow after some build and boot testing.
Thanks,
Sekhar
Re: [PATCH] ARM: davinci: da830-evm: fix GPIO lookup for OHCI
On 25/06/19 8:46 PM, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> The fixed regulator driver doesn't specify any con_id for gpio lookup
> so it must be NULL in the table entry.
>
> Fixes: 274e4c336192 ("ARM: davinci: da830-evm: add a fixed regulator for
> ohci-da8xx")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Bartosz Golaszewski
The offending commit was introduced in v5.2 so I dropped the stable tag
while applying.
Will send pull request tomorrow after some build and testing.
Thanks,
Sekhar
Re: [PATCH] mfd: davinci_voicecodec: remove pointless #include
On 28/06/19 4:17 PM, Arnd Bergmann wrote: > [I missed the davinci maintainers on cc here, sorry] > > On Fri, Jun 28, 2019 at 12:41 PM Arnd Bergmann wrote: >> >> When building davinci as multiplatform, we get a build error >> in this file: >> >> drivers/mfd/davinci_voicecodec.c:22:10: fatal error: 'mach/hardware.h' file >> not found >> >> The header is only used to access the io_v2p() macro, but the >> result is already known because that comes from the resource >> a little bit earlier. >> >> Signed-off-by: Arnd Bergmann Acked-by: Sekhar Nori Thanks, Sekhar
Re: [PATCH] media: davinci-vpbe: remove obsolete includes
On 28/06/19 4:21 PM, Arnd Bergmann wrote: > The driver builds fine without these, and they cause build > problems once davinci multiplatform support is enabled. > > Signed-off-by: Arnd Bergmann Acked-by: Sekhar Nori Thanks, Sekhar
Re: [RFC v3 0/2] clocksource: davinci-timer: new driver
On 24/06/19 12:51 PM, Bartosz Golaszewski wrote: > pon., 24 cze 2019 o 07:40 Daniel Lezcano > napisał(a): >> >> >> Sekhar, Bartosz, >> >> if the sparse warning is not fixed, the driver won't hit this kernel >> version. Please fix it before the two next days otherwise it won't make >> it for v5.4. >> >> Thanks >> > > Hi Daniel, > > will do, I just came back to the office. > > Sekhar, how do we want to handle the rest of the platform code with > this driver? Do you think it can make it for the next release? It may have to wait till next release, I am afraid. Lets first try to get the driver in though. I can try a late pull request with no guarantees. Thanks, Sekhar
Re: [RESEND PATCH v5 0/5] ARM: da850: enable cpufreq in DT mode
On 27/05/19 1:52 PM, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski > > Note: resending rebased on top of v5.2-rc2 > > === > > This series adds cpufreq-dt operating points for da850 boards supported > with device tree (da850-lcdk, da850-lego-ev3, da850-evm). > > Last patch enables CPUFREQ_DT in davinci_all_defconfig. Series applied and pull request sent for v5.3 Thanks, Sekhar
Re: [PATCH] [RESEND] ARM: davinci: fix sleep.S build error on ARMv4
Hi Arnd, On 19/06/19 6:41 PM, Arnd Bergmann wrote: > When building a multiplatform kernel that includes armv4 support, > the default target CPU does not support the blx instruction, > which leads to a build failure: > > arch/arm/mach-davinci/sleep.S: Assembler messages: > arch/arm/mach-davinci/sleep.S:56: Error: selected processor does not support > `blx ip' in ARM mode > > Add a .arch statement in the sources to make this file build. > > Signed-off-by: Arnd Bergmann Tested on OMAP-L138 LCDK board with suspend-resume. Assuming you will pick this directly: Acked-by: Sekhar Nori Regards, Sekhar
Re: [RFC v3 0/2] clocksource: davinci-timer: new driver
On 18/06/19 11:33 PM, Daniel Lezcano wrote: > On 14/06/2019 16:25, Daniel Lezcano wrote: >> On 14/06/2019 12:39, Sekhar Nori wrote: >>> Hi Daniel, >>> >>> On 05/06/19 2:03 PM, Bartosz Golaszewski wrote: >>>> From: Bartosz Golaszewski >>>> >>>> This is another version of the new davinci clocksource driver. After much >>>> discussion this contains many changes to simplify and improve the driver. >>> >>> Does this look good to you now? If yes, can you please merge and provide >>> an immutable branch to me so I can merge dependent mach-davinci patches? >> >> Yes, I think it is fine. >> >> http://g...@git.linaro.org/people/daniel.lezcano/linux.git >> timers/drivers/davinci >> >> It is v5.2-rc4 + (2 x patches) >> >> It is merged in clockevents/next which is exported to linux-next and for >> kernel-ci. >> >> AFAIU, the patch was compiled and tested. If not, please let me know. >> >> Please, wait a couple of days I confirm the tests passed and you can >> consider the branch immutable. > > lkp complained, please do not use the branch. > > I'm waiting for Bartosz to fix the issue. Alright, noted. Thanks, Sekhar
Re: [PATCH] ARM: davinci: da8xx: specify dma_coherent_mask for lcdc
On 07/06/19 8:03 PM, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> The lcdc device is missing the dma_coherent_mask definition causing the
> following warning on da850-evm:
>
> da8xx_lcdc da8xx_lcdc.0: found Sharp_LK043T1DG01 panel
> [ cut here ]
> WARNING: CPU: 0 PID: 1 at kernel/dma/mapping.c:247 dma_alloc_attrs+0xc8/0x110
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper Not tainted 5.2.0-rc3-00077-g16d72dd4891f #18
> Hardware name: DaVinci DA850/OMAP-L138/AM18x EVM
> [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
> [] (show_stack) from [] (__warn+0xec/0x114)
> [] (__warn) from [] (warn_slowpath_null+0x3c/0x48)
> [] (warn_slowpath_null) from []
> (dma_alloc_attrs+0xc8/0x110)
> [] (dma_alloc_attrs) from [] (fb_probe+0x228/0x5a8)
> [] (fb_probe) from [] (platform_drv_probe+0x48/0x9c)
> [] (platform_drv_probe) from [] (really_probe+0x1d8/0x2d4)
> [] (really_probe) from [] (driver_probe_device+0x5c/0x168)
> [] (driver_probe_device) from []
> (device_driver_attach+0x58/0x60)
> [] (device_driver_attach) from []
> (__driver_attach+0x80/0xbc)
> [] (__driver_attach) from [] (bus_for_each_dev+0x64/0xb4)
> [] (bus_for_each_dev) from [] (bus_add_driver+0xe4/0x1d8)
> [] (bus_add_driver) from [] (driver_register+0x78/0x10c)
> [] (driver_register) from [] (do_one_initcall+0x48/0x1bc)
> [] (do_one_initcall) from []
> (kernel_init_freeable+0x10c/0x1d8)
> [] (kernel_init_freeable) from [] (kernel_init+0x8/0xf4)
> [] (kernel_init) from [] (ret_from_fork+0x14/0x34)
> Exception stack(0xc6837fb0 to 0xc6837ff8)
> 7fa0:
> 7fc0:
> 7fe0: 0013
> ---[ end trace 8a8073511be81dd2 ]---
>
> Add a 32-bit mask to the platform device's definition.
>
> Signed-off-by: Bartosz Golaszewski
> ---
> arch/arm/mach-davinci/devices-da8xx.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm/mach-davinci/devices-da8xx.c
> b/arch/arm/mach-davinci/devices-da8xx.c
> index 9ff02de448c6..767cc6f7834c 100644
> --- a/arch/arm/mach-davinci/devices-da8xx.c
> +++ b/arch/arm/mach-davinci/devices-da8xx.c
> @@ -683,6 +683,9 @@ static struct platform_device da8xx_lcdc_device = {
> .id = 0,
> .num_resources = ARRAY_SIZE(da8xx_lcdc_resources),
> .resource = da8xx_lcdc_resources,
> + .dev= {
> + .coherent_dma_mask = DMA_BIT_MASK(32)
Applied to fixes for v5.2 with a ',' added at the end so next
initialization can be added without changing this line.
Thanks,
Sekhar
Re: [PATCH] ARM: davinci: da850-evm: call regulator_has_full_constraints()
On 08/06/19 7:37 PM, Linus Walleij wrote: > On Fri, Jun 7, 2019 at 11:02 AM Bartosz Golaszewski wrote: > >> From: Bartosz Golaszewski >> >> The BB expander at 0x21 i2c bus 1 fails to probe on da850-evm because >> the board doesn't set has_full_constraints to true in the regulator >> API. >> >> Call regulator_has_full_constraints() at the end of board registration >> just like we do in da850-lcdk and da830-evm. >> >> Signed-off-by: Bartosz Golaszewski > > Reviewed-by: Linus Walleij > > I assume Sekhar will queue this and the LED patch? Yes, will do. Added this to fixes for v5.2 Thanks, Sekhar
Re: [RFC v3 0/2] clocksource: davinci-timer: new driver
Hi Daniel, On 05/06/19 2:03 PM, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski > > This is another version of the new davinci clocksource driver. After much > discussion this contains many changes to simplify and improve the driver. Does this look good to you now? If yes, can you please merge and provide an immutable branch to me so I can merge dependent mach-davinci patches? Thanks, Sekhar
Re: [PATCH 5.1 101/155] usb: ohci-da8xx: disable the regulator if the overcurrent irq fired
Hi,
On 13/06/19 2:03 PM, Greg Kroah-Hartman wrote:
> [ Upstream commit d327330185f192411be80563a3c8398f4538cdb2 ]
>
> Historically the power supply management in this driver has been handled
> in two separate places in parallel. Device-tree users simply defined an
> appropriate regulator, while two boards with no DT support (da830-evm and
> omapl138-hawk) passed functions defined in their respective board files
> over platform data. These functions simply used legacy GPIO calls to
> watch the oc GPIO for interrupts and disable the vbus GPIO when the irq
> fires.
>
> Commit d193abf1c913 ("usb: ohci-da8xx: add vbus and overcurrent gpios")
> updated these GPIO calls to the modern API and moved them inside the
> driver.
>
> This however is not the optimal solution for the vbus GPIO which should
> be modeled as a fixed regulator that can be controlled with a GPIO.
>
> In order to keep the overcurrent protection available once we move the
> board files to using fixed regulators we need to disable the enable_reg
> regulator when the overcurrent indicator interrupt fires. Since we
> cannot call regulator_disable() from interrupt context, we need to
> switch to using a oneshot threaded interrupt.
>
> Acked-by: Alan Stern
> Signed-off-by: Bartosz Golaszewski
> Signed-off-by: Sekhar Nori
> Signed-off-by: Sasha Levin
This is a preparatory patch for some clean-up. This should not be
backported to stable.
Thanks,
Sekhar
Re: [PATCH v6 5/6] usb:cdns3 Add Cadence USB3 DRD Driver
On 04/06/19 1:47 PM, Pawel Laszczak wrote:
>>
>> On 10/04/19 1:18 PM, Pawel Laszczak wrote:
>>> +static void cdns3_wa1_tray_restore_cycle_bit(struct cdns3_device *priv_dev,
>>> +struct cdns3_endpoint *priv_ep)
>>> +{
>>> + int dma_index;
>>> + u32 doorbell;
>>> +
>>> + doorbell = !!(readl(_dev->regs->ep_cmd) & EP_CMD_DRDY);
>>
>>> + dma_index = (readl(_dev->regs->ep_traddr) -
>>> + priv_ep->trb_pool_dma) / TRB_SIZE;
>>
>> This gets upgraded to 64-bit by 64-bit division whenever dma_addr_t is
>> 64-bit. That should be avoided. Following diff should fix it.
>> But please review the logic itself. You are subtracting a 64 bit entity
>>from a 32-bit entity. What is guaranteeing that priv_ep->trb_pool_dma is
>> 32-bit?
>>
>> There is one more instance of same issue in cdns3_request_handled().
>>
>> Thanks,
>> Sekhar
>>
>> [1]
>> diff --git a/drivers/usb/cdns3/gadget.c b/drivers/usb/cdns3/gadget.c
>> index bfd5dbf40c7e..e73b618501fb 100644
>> --- a/drivers/usb/cdns3/gadget.c
>> +++ b/drivers/usb/cdns3/gadget.c
>> @@ -749,8 +749,8 @@ static void cdns3_wa1_tray_restore_cycle_bit(struct
>> cdns3_device *priv_dev,
>> u32 doorbell;
>>
>> doorbell = !!(readl(_dev->regs->ep_cmd) & EP_CMD_DRDY);
>> -dma_index = (readl(_dev->regs->ep_traddr) -
>> -priv_ep->trb_pool_dma) / TRB_SIZE;
>> +dma_index = readl(_dev->regs->ep_traddr) - priv_ep->trb_pool_dma;
>> +dma_index /= TRB_SIZE;
>
> Hi Sekhar,
>
> In the next latest version I added setting dma and coherent mask to 32-bits
> as suggested by Roger.
> Controller can do only 32-bit access.
I think this should work for now except if in some future version of
controller the limitation of 32-bit access is fixed. I guess that might
mean different logic for DMA handling anyway.
> DMA address space should be allocated from first 32 bits of address space.
> Most significant 32-bit
> of priv_ep->trb_pool_dma should be zeroed, so I do not assume any issue in
> this place.
>
> Have you seen any issue with this on your platform ?
build fails with
ERROR: "__aeabi_uldivmod" [drivers/usb/cdns3/cdns3.ko] undefined!
on 32-bit platforms with ARM LPAE enabled. So please roll in the fix I
suggested.
Thanks,
Sekhar
Re: [PATCH v6 5/6] usb:cdns3 Add Cadence USB3 DRD Driver
On 10/04/19 1:18 PM, Pawel Laszczak wrote:
> +static void cdns3_wa1_tray_restore_cycle_bit(struct cdns3_device *priv_dev,
> + struct cdns3_endpoint *priv_ep)
> +{
> + int dma_index;
> + u32 doorbell;
> +
> + doorbell = !!(readl(_dev->regs->ep_cmd) & EP_CMD_DRDY);
> + dma_index = (readl(_dev->regs->ep_traddr) -
> + priv_ep->trb_pool_dma) / TRB_SIZE;
This gets upgraded to 64-bit by 64-bit division whenever dma_addr_t is
64-bit. That should be avoided. Following diff should fix it.
But please review the logic itself. You are subtracting a 64 bit entity
from a 32-bit entity. What is guaranteeing that priv_ep->trb_pool_dma is
32-bit?
There is one more instance of same issue in cdns3_request_handled().
Thanks,
Sekhar
[1]
diff --git a/drivers/usb/cdns3/gadget.c b/drivers/usb/cdns3/gadget.c
index bfd5dbf40c7e..e73b618501fb 100644
--- a/drivers/usb/cdns3/gadget.c
+++ b/drivers/usb/cdns3/gadget.c
@@ -749,8 +749,8 @@ static void cdns3_wa1_tray_restore_cycle_bit(struct
cdns3_device *priv_dev,
u32 doorbell;
doorbell = !!(readl(_dev->regs->ep_cmd) & EP_CMD_DRDY);
- dma_index = (readl(_dev->regs->ep_traddr) -
- priv_ep->trb_pool_dma) / TRB_SIZE;
+ dma_index = readl(_dev->regs->ep_traddr) - priv_ep->trb_pool_dma;
+ dma_index /= TRB_SIZE;
Re: [PATCH RFT] regulator: tps6507x: Fix boot regression due to testing wrong init_data pointer
On 16/05/19 6:18 PM, Axel Lin wrote:
> A NULL init_data once incremented will lead to oops, fix it.
>
> Fixes: f979c08f7624 ("regulator: tps6507x: Convert to regulator core's
> simplified DT parsing code")
> Reported-by: Sekhar Nori
> Signed-off-by: Axel Lin
> ---
> Hi Sekhar,
> Please check if this patch works, thanks.
> Axel
Boot is fine now and PMIC regulator rail microvolts readings from sysfs
are correct as well. I did not try to change the voltages though.
Tested-by: Sekhar Nori
Thanks,
Sekhar
boot regression on da850-evm with commit f979c08f7624
Hi Axel Lin,
Your commit f979c08f7624 ("regulator: tps6507x: Convert to regulator
core's simplified DT parsing code") causes a boot regression on da850-
evm.
The device-tree file is arch/arm/boot/dts/da850-evm.dts
Full logs below. tps_board in tps6507x_pmic_probe() is NULL. The check
for init_data introduced in the offending patch:
for (i = 0; i < TPS6507X_NUM_REGULATOR; i++, info++, init_data++) {
/* Register the regulators */
tps->info[i] = info;
- if (init_data->driver_data) {
+ if (init_data && init_data->driver_data) {
struct tps6507x_reg_platform_data *data =
init_data->driver_data;
- tps->info[i]->defdcdc_default = data->defdcdc_default;
works only for first iteration of the loop. A NULL init_data once
incremented will lead to oops.
Reverting the commit solves the issue, but I assume there is a better
solution. Please advise.
Thanks,
Sekhar
Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Linux version 5.1.0-11058-g83f3ef3de625 (a0875516@psplinux063) (gcc version
8.2.1 20180802 (GNU Toolchain for the A-profile Architecture 8.2-2018.11
(arm-rel-8.26))) #60 PREEMPT Thu May 16 17:00:16 IST 2019
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=0005317f
CPU: VIVT data cache, VIVT instruction cache
OF: fdt: Machine model: DA850/AM1808/OMAP-L138 EVM
Memory policy: Data cache writethrough
cma: Reserved 16 MiB at 0xc700
DaVinci da850/omap-l138 variant 0x0
Built 1 zonelists, mobility grouping on. Total pages: 32512
Kernel command line: console=ttyS2,115200n8 root=/dev/nfs rw
nfsroot=172.24.210.141:/datalocal/Sekhar/new/debian/armel ip=dhcp
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 106904K/131072K available (4624K kernel code, 248K rwdata, 1120K
rodata, 212K init, 137K bss, 7784K reserved, 16384K cma-reserved)
SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
rcu: Preemptible hierarchical RCU implementation.
Tasks RCU enabled.
rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies.
NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
random: get_random_bytes called from start_kernel+0x258/0x428 with crng_init=0
clocksource: timer0_1: mask: 0x max_cycles: 0x, max_idle_ns:
79635851949 ns
sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 89478484971ns
Console: colour dummy device 80x30
Calibrating delay loop... 148.88 BogoMIPS (lpj=78)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
*** VALIDATE proc ***
*** VALIDATE cgroup1 ***
*** VALIDATE cgroup2 ***
CPU: Testing write buffer coherency: ok
Setting up static identity map for 0xc0008400 - 0xc0008458
rcu: Hierarchical SRCU implementation.
devtmpfs: initialized
clocksource: jiffies: mask: 0x max_cycles: 0x, max_idle_ns:
1911260446275 ns
futex hash table entries: 256 (order: -1, 3072 bytes)
pinctrl core: initialized pinctrl subsystem
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
cpuidle: using governor menu
mux: initialized RTC_ALARM
mux: Setting register RTC_ALARM
mux:PINMUX0 (0x) = 0x4408 -> 0x2408
gpiochip_add_data_with_key: GPIOs 368..511 (1e26000.gpio) failed to register,
-517
edma 1e3.edma: memcpy is disabled
edma 1e3.edma: TI EDMA DMA engine driver
baseboard_3v3: supplied by vbat
baseboard_1v8: supplied by vbat
clocksource: Switched to clocksource timer0_1
NET: Registered protocol family 2
tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 4096 bytes)
TCP established hash table entries: 1024 (order: 0, 4096 bytes)
TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
TCP: Hash tables configured (established 1024 bind 1024)
UDP hash table entries: 256 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
workingset: timestamp_bits=30 max_order=15 bucket_order=0
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 251)
io scheduler mq-deadline registered
io scheduler kyber registered
pinctrl-single 1c14120.pinmux: 160 pins, size 80
Serial: 8250/16550 driver, 3 ports, IRQ sharing disabled
1d0c000.serial: ttyS1 at MMIO 0x1d0c000 (irq = 69, base_baud = 825) is a TI
DA8xx/66AK2x
1d0d000.serial: ttyS2 at MMIO 0x1d0d000 (irq = 77, base_baud = 825) is a TI
DA8xx/66AK2x
printk: console [ttyS2] enabled
brd: module loaded
libphy: Fixed MDIO Bus: probed
davinci_mdio 1e24000.mdio: davinci mdio revision 1.5, bus freq 220
Re: [PATCH] clk: Remove io.h from clk-provider.h
On 14/05/19 10:39 PM, Stephen Boyd wrote: > Now that we've gotten rid of clk_readl() we can remove io.h from the > clk-provider header and push out the io.h include to any code that isn't > already including the io.h header but using things like readl/writel, > etc. For mach-davinci and drivers/clk/davinci Acked-by: Sekhar Nori Thanks, Sekhar
Re: [PATCH v3 1/3] ARM: dts: da850: add cpu node and operating points to DT
On 16/04/19 2:07 PM, Bartosz Golaszewski wrote: > If we agree on the direction of these patches, then I can go with a > single enabled OPP for lcdk (456 MHz) and all OPPs up to 375 MHz > enabled for da850-evm. Sounds good to me. Thanks, Sekhar
Re: [PATCH v3 1/3] ARM: dts: da850: add cpu node and operating points to DT
On 16/04/19 5:18 PM, Adam Ford wrote: > On Tue, Apr 16, 2019 at 3:38 AM Bartosz Golaszewski wrote: >> >> pon., 15 kwi 2019 o 12:21 Sekhar Nori napisał(a): >>> >>> On 12/04/19 9:01 PM, Bartosz Golaszewski wrote: >>>> pt., 12 kwi 2019 o 15:53 Sekhar Nori napisał(a): >>>>> >>>>> On 12/04/19 5:41 PM, Bartosz Golaszewski wrote: >>>>>> pt., 12 kwi 2019 o 13:26 Sekhar Nori napisał(a): >>>>>>> >>>>>>> Hi Bartosz, >>>>>>> >>>>>>> On 08/04/19 1:29 PM, Bartosz Golaszewski wrote: >>>>>>>> From: David Lechner >>>>>>>> >>>>>>>> This adds a cpu node and operating points to the common da850.dtsi >>>>>>>> file. >>>>>>>> >>>>>>>> Additionally, a regulator is added to the LEGO EV3 board along with >>>>>>>> some board-specific CPU configuration. >>>>>>>> >>>>>>>> Regulators need to be hooked up on other boards to get them working. >>>>>>>> >>>>>>>> Signed-off-by: David Lechner >>>>>>>> Signed-off-by: Bartosz Golaszewski >>>>>>> >>>>>>> I remember you mentioning about some problems using OCHI and cpufreq >>>>>>> together. Are those resolved now? CPU PLL on DA850 can affect other >>>>>>> peripheral clock frequencies too. So enabling it should really be a >>>>>>> per-board decision. >>>>>>> >>>>>> >>>>>> The problems are still there. I've never been able to find the >>>>>> culprit, but it also occurs on TI BSP in the same way (a couple >>>>>> cpufreq transitions will make the controller unresponsive). >>>>> >>>>> Is that on LCDK as well? As I recall cpufreq was never enabled on LCDK >>>>> in TI BSP. >>>>> >>>> >>>> Yes, I just verified that the bug occurs on LCDK with patches from this >>>> series. >>>> >>>>> If the OHCI problem is present on LCDK, then there is a user visible >>>>> regression on mainline after this patch. Lets enable cpufreq in LCDK >>>>> only if all working peripherals keep working afterwards. >>>>> >>>> >>>> The OHCI driver doesn't register any cpufreq transition notifier >>>> callbacks. I can't really find anything in the datasheet, but I'm >>>> wondering if we shouldn't do something similar to what the driver for >>>> davinci i2c controller does. I'll try a couple things tomorrow. >>> >>> Even if OHCI issue is fixed, with a fixed regulator like on LCDK, I am >>> not sure the benefits of just frequency scaling will be justifiable enough. >>> >>> Fixing the OHCI issue may help in other boards like da850-evm use it >>> though. So that will be a good thing. >>> >> >> I've been trying different things, like suspending the device before >> the transition, resetting the controller or playing with the clock >> during transitions but it always results in the same kind of error: >> >> ohci-da8xx 1e25000.usb: frame counter not updating; disabled >> ohci-da8xx 1e25000.usb: HC died; cleaning up >> usb 1-1: USB disconnect, device number 2 >> >> If you have any idea - let me know, otherwise I'll give up. >> >> If we agree on the direction of these patches, then I can go with a >> single enabled OPP for lcdk (456 MHz) and all OPPs up to 375 MHz >> enabled for da850-evm. > > One last questions, and this probably directed at Sekhar, but what > happens if you modify the OPP for the boards with fixed regulators to > enable all the frequencies but with the only available voltage. Is > there harm is running the processor at a higher voltage than > necessary? I did some quick experiments on a different ARM board and > I saw some changes in power consumption. I would think some power > savings might be better than none, but I don't know if it causes> damage. The OMAP-L138 datasheet mentions two versions of devices in core voltage specification: Variable (1.2V-1.0V) for 375 MHz version Variable (1.3V-1.0V) for 456 MHz version If you have 375 MHz version of device, I do not think you should run at 1.3V. I don't know what "damage" it will cause or how long it takes for any of it to be visible. Keeping that aside, I doubt there will be a lot of power-saving benefit without voltage scaling. Even if you see a slightly lower power number when you reduce frequency, there is also work to be done for the scaling operation itself. Thanks, Sekhar
Re: [PATCH v3 1/3] ARM: dts: da850: add cpu node and operating points to DT
On 12/04/19 9:01 PM, Bartosz Golaszewski wrote: > pt., 12 kwi 2019 o 15:53 Sekhar Nori napisał(a): >> >> On 12/04/19 5:41 PM, Bartosz Golaszewski wrote: >>> pt., 12 kwi 2019 o 13:26 Sekhar Nori napisał(a): >>>> >>>> Hi Bartosz, >>>> >>>> On 08/04/19 1:29 PM, Bartosz Golaszewski wrote: >>>>> From: David Lechner >>>>> >>>>> This adds a cpu node and operating points to the common da850.dtsi file. >>>>> >>>>> Additionally, a regulator is added to the LEGO EV3 board along with >>>>> some board-specific CPU configuration. >>>>> >>>>> Regulators need to be hooked up on other boards to get them working. >>>>> >>>>> Signed-off-by: David Lechner >>>>> Signed-off-by: Bartosz Golaszewski >>>> >>>> I remember you mentioning about some problems using OCHI and cpufreq >>>> together. Are those resolved now? CPU PLL on DA850 can affect other >>>> peripheral clock frequencies too. So enabling it should really be a >>>> per-board decision. >>>> >>> >>> The problems are still there. I've never been able to find the >>> culprit, but it also occurs on TI BSP in the same way (a couple >>> cpufreq transitions will make the controller unresponsive). >> >> Is that on LCDK as well? As I recall cpufreq was never enabled on LCDK >> in TI BSP. >> > > Yes, I just verified that the bug occurs on LCDK with patches from this > series. > >> If the OHCI problem is present on LCDK, then there is a user visible >> regression on mainline after this patch. Lets enable cpufreq in LCDK >> only if all working peripherals keep working afterwards. >> > > The OHCI driver doesn't register any cpufreq transition notifier > callbacks. I can't really find anything in the datasheet, but I'm > wondering if we shouldn't do something similar to what the driver for > davinci i2c controller does. I'll try a couple things tomorrow. Even if OHCI issue is fixed, with a fixed regulator like on LCDK, I am not sure the benefits of just frequency scaling will be justifiable enough. Fixing the OHCI issue may help in other boards like da850-evm use it though. So that will be a good thing. How do you feel about keeping all OPPs disabled by default in da850.dtsi and enabling only the ones that make sense for a board in .dts? Empty OPP table is illegal, so this does mean that every board must enable at least one OPP. Thanks, Sekhar
Re: [PATCH v3 1/3] ARM: dts: da850: add cpu node and operating points to DT
On 12/04/19 5:41 PM, Bartosz Golaszewski wrote: > pt., 12 kwi 2019 o 13:26 Sekhar Nori napisał(a): >> >> Hi Bartosz, >> >> On 08/04/19 1:29 PM, Bartosz Golaszewski wrote: >>> From: David Lechner >>> >>> This adds a cpu node and operating points to the common da850.dtsi file. >>> >>> Additionally, a regulator is added to the LEGO EV3 board along with >>> some board-specific CPU configuration. >>> >>> Regulators need to be hooked up on other boards to get them working. >>> >>> Signed-off-by: David Lechner >>> Signed-off-by: Bartosz Golaszewski >> >> I remember you mentioning about some problems using OCHI and cpufreq >> together. Are those resolved now? CPU PLL on DA850 can affect other >> peripheral clock frequencies too. So enabling it should really be a >> per-board decision. >> > > The problems are still there. I've never been able to find the > culprit, but it also occurs on TI BSP in the same way (a couple > cpufreq transitions will make the controller unresponsive). Is that on LCDK as well? As I recall cpufreq was never enabled on LCDK in TI BSP. If the OHCI problem is present on LCDK, then there is a user visible regression on mainline after this patch. Lets enable cpufreq in LCDK only if all working peripherals keep working afterwards. Thanks, Sekhar
Re: [PATCH v3 2/3] ARM: dts: da850-evm: enable cpufreq
On 08/04/19 1:29 PM, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> Enable cpufreq-dt support for da850-evm. The cvdd is supplied by the
> tps6507 pmic with configurable output voltage, so all operating points
> can be enabled.
>
> Signed-off-by: Bartosz Golaszewski
Adam, can you please ack? Looks good to me.
Thanks,
Sekhar
> ---
> arch/arm/boot/dts/da850-evm.dts | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
> index f04bc3e15332..f94bb38fdad9 100644
> --- a/arch/arm/boot/dts/da850-evm.dts
> +++ b/arch/arm/boot/dts/da850-evm.dts
> @@ -191,6 +191,19 @@
> };
> };
>
> + {
> + cpu-supply = <_reg>;
> +};
> +
> +/*
> + * The standard da850-evm kits and SOM's are 375MHz so enable this operating
> + * point by default. Higher frequencies must be enabled for custom boards
> with
> + * other variants of the SoC.
> + */
> +_375 {
> + status = "okay";
> +};
> +
> {
> status = "okay";
> };
> --
> 2.21.0
>
Re: [PATCH v3 1/3] ARM: dts: da850: add cpu node and operating points to DT
Hi Bartosz,
On 08/04/19 1:29 PM, Bartosz Golaszewski wrote:
> From: David Lechner
>
> This adds a cpu node and operating points to the common da850.dtsi file.
>
> Additionally, a regulator is added to the LEGO EV3 board along with
> some board-specific CPU configuration.
>
> Regulators need to be hooked up on other boards to get them working.
>
> Signed-off-by: David Lechner
> Signed-off-by: Bartosz Golaszewski
I remember you mentioning about some problems using OCHI and cpufreq
together. Are those resolved now? CPU PLL on DA850 can affect other
peripheral clock frequencies too. So enabling it should really be a
per-board decision.
No problems with adding OPPs to da850.dtsi, but which of those are
enabled on any board should be after some thorough testing and analysis.
Because of that, I think its also better to split da850.dtsi from board
specific changes in this patch.
> + opp_table: opp-table {
> + compatible = "operating-points-v2";
> +
> + opp_100: opp100-1 {
> + opp-hz = /bits/ 64 <1>;
> + opp-microvolt = <100 95 105>;
> + };
> +
> + opp_200: opp110-2 {
> + opp-hz = /bits/ 64 <2>;
> + opp-microvolt = <110 105 116>;
> + };
> +
> + opp_300: opp120-3 {
> + opp-hz = /bits/ 64 <3>;
> + opp-microvolt = <120 114 132>;
> + };
> +
> + /*
> + * Original silicon was 300MHz max, so higher frequencies
> + * need to be enabled on a per-board basis if the chip is
> + * capable.
> + */
> +
> + opp_375: opp120-37500 {
> + status = "disabled";
> + opp-hz = /bits/ 64 <37500>;
> + opp-microvolt = <120 114 132>;
> + };
> +
> + opp_415: opp130-41500 {
> + status = "disabled";
> + opp-hz = /bits/ 64 <41500>;
> + opp-microvolt = <130 125 135>;
> + };
> +
> + opp_456: opp130-45600 {
> + status = "disabled";
> + opp-hz = /bits/ 64 <45600>;
> + opp-microvolt = <130 125 135>;
> + };
Here, lets stick to OPPs defined in OMAP-L138 data manual (irrespective
of what existing board code has). Page 93 of
http://www.ti.com/lit/ds/symlink/omap-l138.pdf
Thanks,
Sekhar
Re: [PATCH v4 3/6] usb: ohci-da8xx: disable the regulator if the overcurrent irq fired
Hi Bartosz,
On 11/04/19 3:00 PM, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> Historically the power supply management in this driver has been handled
> in two separate places in parallel. Device-tree users simply defined an
> appropriate regulator, while two boards with no DT support (da830-evm and
> omapl138-hawk) passed functions defined in their respective board files
> over platform data. These functions simply used legacy GPIO calls to
> watch the oc GPIO for interrupts and disable the vbus GPIO when the irq
> fires.
>
> Commit d193abf1c913 ("usb: ohci-da8xx: add vbus and overcurrent gpios")
> updated these GPIO calls to the modern API and moved them inside the
> driver.
>
> This however is not the optimal solution for the vbus GPIO which should
> be modeled as a fixed regulator that can be controlled with a GPIO.
>
> In order to keep the overcurrent protection available once we move the
> board files to using fixed regulators we need to disable the enable_reg
> regulator when the overcurrent indicator interrupt fires. Since we
> cannot call regulator_disable() from interrupt context, we need to
> switch to using a oneshot threaded interrupt.
>
> Signed-off-by: Bartosz Golaszewski
I thought a bit on whether it makes sense to merge this patch into 6/6
since that is modifying some code you introduce here. But I think its
probably better to keep it separate like you have it now.
6/6 is about dropping support for vbus gpio, where as here you are
letting regulator be used for handing overcurrent detected using oci gpio.
Having it separate makes it possible to revert dropping support for vbus
gpio while keeping this functionality ;)
> -static irqreturn_t ohci_da8xx_oc_handler(int irq, void *data)
> +static irqreturn_t ohci_da8xx_oc_thread(int irq, void *data)
> {
> struct da8xx_ohci_hcd *da8xx_ohci = data;
> + struct device *dev = da8xx_ohci->hcd->self.controller;
> + int ret;
>
> - if (gpiod_get_value(da8xx_ohci->oc_gpio))
> - gpiod_set_value(da8xx_ohci->vbus_gpio, 0);
> + if (gpiod_get_value_cansleep(da8xx_ohci->oc_gpio)) {
> + if (da8xx_ohci->vbus_gpio) {
> + gpiod_set_value_cansleep(da8xx_ohci->vbus_gpio, 0);
> + } else if (da8xx_ohci->vbus_reg) {
> + ret = regulator_disable(da8xx_ohci->vbus_reg);
> + if (ret)
> + dev_err(dev,
> + "Failed to disable regulator: %d\n",
> + ret);
> + }
> +
Unnecessary empty line here, that too one that introduces white space
error. Please drop.
Thanks,
Sekhar
Re: [PATCH v2 1/4] ARM: davinci: fix cpufreq registration on da850-evm
On 04/04/19 4:44 PM, Adam Ford wrote:
> On Thu, Apr 4, 2019 at 5:01 AM Bartosz Golaszewski wrote:
>>
>> śr., 3 kwi 2019 o 17:49 Adam Ford napisał(a):
>>>
>>> On Wed, Apr 3, 2019 at 7:50 AM Bartosz Golaszewski wrote:
>>>>
>>>> śr., 27 mar 2019 o 12:14 Sekhar Nori napisał(a):
>>>>>
>>>>> Hi Bart,
>>>>>
>>>>> On 26/03/19 11:21 PM, Bartosz Golaszewski wrote:
>>>>>> wt., 26 mar 2019 o 15:00 Adam Ford napisał(a):
>>>>>>>
>>>>>>> On Fri, Mar 22, 2019 at 8:31 AM Bartosz Golaszewski
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> From: Bartosz Golaszewski
>>>>>>>>
>>>>>>>> The system_rev variable is never set on davinci and is always 0, so
>>>>>>>> we're using the default max operating point of 300MHz. The cvdd supply
>>>>>>>> comes from the tps6507 pmic and the voltage can go all the way to 1.3V
>>>>>>>> so the maximum supported rate should be 456MHz.
>>>>>>>
>>>>>>> My understanding is that only certain revisions of the silicon can go
>>>>>>> to 456MHz. The L138's Datasheet lists both a 456 and 375 version. I
>>>>>>> cannot find a way to read a register to determine which version of the
>>>>>>> silicon is available. Maybe Sekhar can confirm.
>>>>>>>
>>>>>>
>>>>>> Commit 28bd2c341120 ("davinci: am18x/da850/omap-l138 evm: add support
>>>>>> for higher speed grades") mentions the following:
>>>>>>
>>>>>> ---
>>>>>> U-Boot on the EVM sets up ATAG_REVISION to inform the OS
>>>>>> regarding the speed grade supported by the silicon. We use
>>>>>> this information to pass on the speed grade information to
>>>>>> the SoC code.
>>>>>> ---
>>>>>>
>>>>>> Should the system_rev somehow reflect that revision? Any way I can check
>>>>>> it?
>>>>>
>>>>> Can you check if the procedure in doc/README.davinci in U-Boot sources
>>>>> still works?
>>>>>
>>>>> Environment Variables
>>>>> =
>>>>>
>>>>> The DA850 EVM allows the user to specify the maximum cpu clock allowed by
>>>>> the
>>>>> silicon, in Hz, via an environment variable "maxcpuclk".
>>>>>
>>>>> The maximum clock rate allowed depends on the silicon populated on the
>>>>> EVM.
>>>>> Please make sure you understand the restrictions placed on this clock in
>>>>> the
>>>>> device specific datasheet before setting up this variable. This
>>>>> information is
>>>>> passed to the Linux kernel using the ATAG_REVISION atag.
>>>>>
>>>>> If "maxcpuclk" is not defined, the configuration
>>>>> CONFIG_DA850_EVM_MAX_CPU_CLK
>>>>> is used to obtain this information.
>>>>>
>>>>> Thanks,
>>>>> Sekhar
>>>>
>>>> Hi Sekhar,
>>>>
>>>> I built the current upstream u-boot and the get_board_rev() function
>>>> for da850-evm doesn't seem to be called at all. For instance the
>>>> lego-ev3 platform does this:
>>>>
>>>> ./lego/ev3/legoev3.c:108: board_rev = get_board_rev();
>>>>
>>>> but in davinci this function seems to be unused and I don't see it
>>>> called from any other core u-boot component. I don't see any commit
>>>> that would mention this function but there are a lot of commits
>>>> removing get_board_rev() for other boards in git log. Is it possible
>>>> it stopped being used at some point?
>>>
>>> Look for setup_revision_tag in arch/arm/lib/bootm.c
>>>
>>> The function appears to be called from there.
>>>
>>> There is a __weak reference in the header file which I think allows
>>> people to remove them without breaking bootm.
>>>
>>> adam
>>>>
>>>> Bart
>>
>> Thanks, now verified that this still works in board file mode for
>> da850-evm. Now the questions is - what about DT mode? Should we only
>> enable the lowest possible mode (300MHz) and leave it to the user to
>> enable any higher frequencies?
>
> From everything that I can find in Logic PD's database, the standard
> da850-evm kits and SOM's are 375MHz, so I think it's safe to run up to
> that speed. I would disable the speed options for 408 and 456, but
> leave them shown for anyone who may have purchased a custom version
> with the 456MHz variant which I can also see there are some. At least
> for the L138 and AM1808 SOM's, those customers who who they are, so
> making it obvious how to enable it would be a good thing.
>
> Just my two cents.
Sounds good to me.
Thanks,
Sekhar
Re: [RESEND PATCH 1/2] ARM: davinci: support multiplatform build for ARM v5
On 25/03/19 6:38 PM, Arnd Bergmann wrote: > On Mon, Mar 18, 2019 at 1:29 PM Bartosz Golaszewski wrote: >> >> From: Bartosz Golaszewski >> >> Add modifications necessary to make davinci part of the ARM v5 >> multiplatform build. >> >> Move the arch-specific configuration out of arch/arm/Kconfig and >> into mach-davinci/Kconfig. Remove the sub-menu for DaVinci >> implementations (they'll be visible directly under the system type. >> Select all necessary options not already selected by ARCH_MULTI_V5. >> Update davinci_all_defconfig. Explicitly include the mach-specific >> headers in mach-davinci/Makefile. >> >> Signed-off-by: Bartosz Golaszewski > > I like this a lot, it gives me some hope that we can eventually > do the same for the remaining ARMv5 platforms that are > not multiplatform yet (s3c24xx, ks8695, w90x900, lpc32xx, > omap1, ep93xx, and maybe even the xscale based ones). > > I have done a lot of randconfig testing with this patch appled now > and not found any issues, great work! Thanks Arnd. Will take this as your Acked-by: The timer conversion patches are pending review/rework. Will queue once those are cleared. Regards, Sekhar
Re: [PATCH v4 00/11] ARM: davinci: modernize the timer support
Hi Daniel, Thomas, On 18/03/19 5:40 PM, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski > > This series removes the legacy timer code from mach-davinci in favor of > a new clocksource driver it introduces. > > Patch 1 adds a new clocksource driver for davinci. > > Patch 2 enables the new driver for device-tree based systems. > > Patch 3 adds a WARN_ON() to the machine code of all davinci boards > which is triggered if clk_get() for the timer clock fails. This is needed > as the new driver expects the clock to be functional and doesn't check it. > > Patches 4-5 and 7-10 switch the board files to using the new > clocksource driver while patch 6 moves some necessary defines to > a different place since we'll be removing the file that contains them. > > Patch 11 removes legacy timer code. The series looks good to me. With your ack on 1/11, I would like to merge the series through ARM SoC tree. Thanks, Sekhar
Re: [PATCH v2 1/4] ARM: davinci: fix cpufreq registration on da850-evm
Hi Bart,
On 26/03/19 11:21 PM, Bartosz Golaszewski wrote:
> wt., 26 mar 2019 o 15:00 Adam Ford napisał(a):
>>
>> On Fri, Mar 22, 2019 at 8:31 AM Bartosz Golaszewski wrote:
>>>
>>> From: Bartosz Golaszewski
>>>
>>> The system_rev variable is never set on davinci and is always 0, so
>>> we're using the default max operating point of 300MHz. The cvdd supply
>>> comes from the tps6507 pmic and the voltage can go all the way to 1.3V
>>> so the maximum supported rate should be 456MHz.
>>
>> My understanding is that only certain revisions of the silicon can go
>> to 456MHz. The L138's Datasheet lists both a 456 and 375 version. I
>> cannot find a way to read a register to determine which version of the
>> silicon is available. Maybe Sekhar can confirm.
>>
>
> Commit 28bd2c341120 ("davinci: am18x/da850/omap-l138 evm: add support
> for higher speed grades") mentions the following:
>
> ---
> U-Boot on the EVM sets up ATAG_REVISION to inform the OS
> regarding the speed grade supported by the silicon. We use
> this information to pass on the speed grade information to
> the SoC code.
> ---
>
> Should the system_rev somehow reflect that revision? Any way I can check it?
Can you check if the procedure in doc/README.davinci in U-Boot sources
still works?
Environment Variables
=
The DA850 EVM allows the user to specify the maximum cpu clock allowed by the
silicon, in Hz, via an environment variable "maxcpuclk".
The maximum clock rate allowed depends on the silicon populated on the EVM.
Please make sure you understand the restrictions placed on this clock in the
device specific datasheet before setting up this variable. This information is
passed to the Linux kernel using the ATAG_REVISION atag.
If "maxcpuclk" is not defined, the configuration CONFIG_DA850_EVM_MAX_CPU_CLK
is used to obtain this information.
Thanks,
Sekhar
Re: [PATCH v4 00/37] ARM: davinci: modernize the irq support
On 18/02/19 7:49 PM, Marc Zyngier wrote: > On Thu, 14 Feb 2019 15:51:54 +0100 > Bartosz Golaszewski wrote: > >> From: Bartosz Golaszewski >> >> This series ports the davinci platform to using SPARSE_IRQ, cleans up >> the irqchip drivers and moves them over to drivers/irqchip. > > [...] > > For the irqchip parts: > > Acked-by: Marc Zyngier > > Please route this via the appropriate tree. Thanks all of the reviews and testing. I have added acked-by and reviewed-by. Also made some changes pointed to by David locally. Pull request sent to ARM SoC maintainers. Thanks, Sekhar
Re: [PATCH] cpufreq: davinci: move configuration to include/linux/platform_data
On 18/02/19 11:46 AM, Viresh Kumar wrote: > Applied. Thanks. Here is a belated ack from my side. Acked-by: Sekhar Nori Thanks, Sekhar
Re: [PATCH v4 00/37] ARM: davinci: modernize the irq support
Marc, On 14/02/19 8:21 PM, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski > > This series ports the davinci platform to using SPARSE_IRQ, cleans up > the irqchip drivers and moves them over to drivers/irqchip. > > The series can be logically split into five parts. The first patch > preemptively fixes a problem in an input driver that would have caused > problems later. Patches (2-9) aim at introducing support for SPARSE_IRQ. > They contain a couple changes required for that functionality and do some > cleanup at the end. > > Third part (10-22) makes the aintc driver suitable for drivers/irqchip > and eventually moves it over there. > > Part 4 (23-36) does the same for the cp-intc driver. > > Last patch removes unnecessary code. > > The series has been tested on da850-lcdk (for cp-intc) and > dm365-evm (for aintc). Do you have any further comments? If no, I would like to apply for v5.1 with your ack. Thanks, Sekhar
Re: [PATCH v3 01/37] input: davinci_keyscan: remove unnecessary includes
+ Dmitry for his ack On 12/02/19 4:07 PM, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski > > The mach/ and asm/ includes are not needed in davinci_keyscan, but they > will cause build problems once we make mach/irqs.h a private header for > mach-davinci. > > Remove all unused header includes. > > Signed-off-by: Bartosz Golaszewski > --- > drivers/input/keyboard/davinci_keyscan.c | 4 > 1 file changed, 4 deletions(-) > > diff --git a/drivers/input/keyboard/davinci_keyscan.c > b/drivers/input/keyboard/davinci_keyscan.c > index b20a5d044caa..b4db72f833ca 100644 > --- a/drivers/input/keyboard/davinci_keyscan.c > +++ b/drivers/input/keyboard/davinci_keyscan.c > @@ -32,10 +32,6 @@ > #include > #include > > -#include > - > -#include > -#include > #include > > /* Key scan registers */ > -- > 2.20.1 >
Re: [PATCH v3 20/37] ARM: davinci: aintc: move timer-specific irq_set_handler() out of irq.c
On 14/02/19 4:27 PM, Marc Zyngier wrote: > On Tue, 12 Feb 2019 10:38:18 +, > Bartosz Golaszewski wrote: >> >> From: Bartosz Golaszewski >> >> I've been unable to figure out exactly why, but it seems that the >> IRQ_TINT1_TINT34 interrupt for timer 1 needs to be handled as a >> level irq, not edge like all others. >> >> Let's move the handler setup out of the aintc driver where it's lived >> since the beginning and into the dm* SoC-specific files where it >> belongs. >> >> Signed-off-by: Bartosz Golaszewski >> --- >> arch/arm/mach-davinci/dm355.c | 8 >> arch/arm/mach-davinci/dm365.c | 8 >> arch/arm/mach-davinci/dm644x.c | 8 >> arch/arm/mach-davinci/dm646x.c | 8 >> arch/arm/mach-davinci/irq.c| 3 --- >> 5 files changed, 32 insertions(+), 3 deletions(-) >> >> diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c >> index c7cd765114af..a732f2ea1d9a 100644 >> --- a/arch/arm/mach-davinci/dm355.c >> +++ b/arch/arm/mach-davinci/dm355.c >> @@ -15,6 +15,7 @@ >> #include >> #include >> #include >> +#include >> #include >> #include >> #include >> @@ -744,6 +745,13 @@ void __init dm355_init_time(void) >> psc = ioremap(DAVINCI_PWR_SLEEP_CNTRL_BASE, SZ_4K); >> dm355_psc_init(NULL, psc); >> >> +/* >> + * Nobody knows why anymore, but this interrupt has been handled as >> + * a level irq from the very beginning of davinci support in mainline >> + * linux. >> + */ >> +irq_set_handler(DAVINCI_INTC_IRQ(IRQ_TINT1_TINT34), handle_level_irq); >> + > > I've said it on v2, I'm repeating it on v3. There is no point in > duplicating this pointless hack on and on again. If there is a driver > using this interrupt, move the setup there, and fix the irq_set_type > callback. > > If nothing is using it, remove it altogether. Alright, fine with me as well. Dropping the hack is fine. And I think that just boils down to discarding this patch. Thanks, Sekhar
Re: [RESEND PATCH v2 08/33] ARM: davinci: make irqs.h a local header
On 11/02/19 5:55 PM, Bartosz Golaszewski wrote: > diff --git a/arch/arm/mach-davinci/usb.c b/arch/arm/mach-davinci/usb.c > index 9d4a58a3113a..cde72ba35dc3 100644 > --- a/arch/arm/mach-davinci/usb.c > +++ b/arch/arm/mach-davinci/usb.c > @@ -5,13 +5,14 @@ > #include > #include > #include > - > +#include > #include > > #include > -#include > #include > -#include > + > + Drop one extra empty line here. > +#include "irqs.h" Thanks, Sekhar
Re: [RESEND PATCH v2 02/33] ARM: davinci: aintc: use irq domain
On 11/02/19 5:55 PM, Bartosz Golaszewski wrote:
> @@ -74,6 +75,7 @@ void __init davinci_irq_init(void)
> {
> unsigned i, j;
> const u8 *davinci_def_priorities = davinci_soc_info.intc_irq_prios;
> + int rv, irq_base;
>
> davinci_intc_type = DAVINCI_INTC_TYPE_AINTC;
> davinci_intc_base = ioremap(davinci_soc_info.intc_base, SZ_4K);
> @@ -110,8 +112,25 @@ void __init davinci_irq_init(void)
> davinci_irq_writel(pri, i);
> }
>
> + irq_base = irq_alloc_descs(-1, 0, davinci_soc_info.intc_irq_num, 0);
> + if (WARN_ON(irq_base < 0))
> + return;
> +
> + davinci_irq_domain = irq_domain_add_legacy(NULL,
> + davinci_soc_info.intc_irq_num,
> + irq_base, 0, _domain_simple_ops,
> + NULL);
> + if (WARN_ON(!davinci_irq_domain))
> + return;
> +
> + rv = irq_alloc_domain_generic_chips(davinci_irq_domain, 32, 1,
> + "AINTC", handle_edge_irq,
> + IRQ_NOREQUEST | IRQ_NOPROBE, 0, 0);
> + if (WARN_ON(rv))
> + return;
Like you have done in other places, use "ret" instead of "rv" for
consistency.
Thanks,
Sekhar
Re: [RESEND PATCH v2 00/33] ARM: davinci: modernize the irq support
On 11/02/19 5:55 PM, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski > > NOTE: resending due to missing irqchip maintainers in Cc > > This series ports the davinci platform to using SPARSE_IRQ, cleans up > the irqchip drivers and moves them over to drivers/irqchip. > > The series can be logically split into four parts. The first (1-8) aims > at introducing support for SPARSE_IRQ. It contains a couple changes > required for that functionality and the final patch actually selecting > it. > > Second part (9-19) makes the aintc driver suitable for drivers/irqchip > and eventually moves it over there. > > Part 3 (20-32) does the same for the cp-intc driver. > > Last patch removes unnecessary code. > > The series has been tested on da850-lcdk (for cp-intc) and > dm365-evm (for aintc). There is build breakage in drivers/input/keyboard/davinci_keyscan.c after this series due to removal. Thanks, Sekhar
Re: [PATCH] ARM: davinci: da850-evm: use GPIO hogs instead of the legacy API
On 05/02/19 6:11 PM, Linus Walleij wrote: > On Tue, Feb 5, 2019 at 10:49 AM Bartosz Golaszewski wrote: >> From: Bartosz Golaszewski >> >> In order to drop the hard-coded GPIO base values from the davinci GPIO >> driver's platform data, we first need to get rid of all calls to the >> legacy GPIO functions. Convert the mdio configuration to hogging the >> relevant GPIO line in the da850-evm board file. >> >> Signed-off-by: Bartosz Golaszewski > > Reviewed-by: Linus Walleij Applied to my v5.1/soc branch. Thanks, Sekhar
Re: [PATCH v2 5/8] usb: ohci-da8xx: add vbus and overcurrent gpios
On 11/02/19 4:06 PM, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski > > There are two users upstream which register external callbacks for > switching the port power on/off and overcurrent protection. Both > users only use two GPIOs for that. Instead of having that functionality > in the board files, move the logic into the OHCI driver - including > the interrupt handler for overcurrent detection. > > Signed-off-by: Bartosz Golaszewski > Acked-by: Alan Stern > --- > drivers/usb/host/ohci-da8xx.c | 99 ++- > 1 file changed, 50 insertions(+), 49 deletions(-) > > diff --git a/drivers/usb/host/ohci-da8xx.c b/drivers/usb/host/ohci-da8xx.c > index e8ede0b5e3f0..80c23307fbfe 100644 > --- a/drivers/usb/host/ohci-da8xx.c > +++ b/drivers/usb/host/ohci-da8xx.c > @@ -12,6 +12,7 @@ > #include > #include > #include > +#include > #include > #include > #include Added the new include in alphabetical order. With that minor fix, series is applied to my v5.1/soc branch. Thanks, Sekhar
Re: [RESEND PATCH v2 17/33] ARM: davinci: aintc: move timer-specific irq_set_handler() out of irq.c
On 11/02/19 6:30 PM, Marc Zyngier wrote: > On 11/02/2019 12:25, Bartosz Golaszewski wrote: >> +/* >> + * Nobody knows why anymore, but this interrupt has been handled as >> + * a level irq from the very beginning of davinci support in mainline >> + * linux. >> + */ >> +irq_set_handler(DAVINCI_INTC_IRQ(IRQ_TINT1_TINT34), handle_level_irq); >> + > > Now, the real question is: why isn't that set as part of the > set_irq_type() callback, instead of hardcoding it in the platform? > > This is exactly the kind of information that should come as part of the > DT or from the driver as one of the request_irq() flags. > > It would save quite a bit of boilerplate code. True, but I would keep this series feature/bug compatible with existing code. Without that, tracking regression reports will be a nightmare. Its a pretty major change already. We can (and should) fix this, but I prefer thats done as follow-up patch after this series is merged. That way a revert is easy. BTW, I don't quite see which in-kernel module uses this interrupt. It might be some out-of-tree code, or some code that since got removed from kernel. Thanks, Sekhar
Re: [PATCH v2 00/33] ARM: davinci: modernize the irq support
+ Jason, Marc Thomas, Jason, Marc, On 08/02/19 11:04 PM, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski > > This series ports the davinci platform to using SPARSE_IRQ, cleans up > the irqchip drivers and moves them over to drivers/irqchip. > > The series can be logically split into four parts. The first (1-8) aims > at introducing support for SPARSE_IRQ. It contains a couple changes > required for that functionality and the final patch actually selecting > it. > > Second part (9-19) makes the aintc driver suitable for drivers/irqchip > and eventually moves it over there. > > Part 3 (20-32) does the same for the cp-intc driver. > > Last patch removes unnecessary code. > > The series has been tested on da850-lcdk (for cp-intc) and > dm365-evm (for aintc). With your ack, I would like to try get it merged to v5.1 via ARM SoC tree. Bartosz, I noticed that Jason and Marc were not originally CCed. You may have to resend if they don't have the series in their inbox. Thanks, Sekhar
