| Message ID | 20220629184343.3438856-1-mail@conchuod.ie |
|---|---|
| Headers | show |
| Series | Canaan devicetree fixes | expand |
On Wed, Jun 29, 2022 at 07:43:29PM +0100, Conor Dooley wrote: > From: Conor Dooley <conor.dooley@microchip.com> > > Hey all, > This series should rid us of dtbs_check errors for the RISC-V Canaan k210 > based boards. To make keeping it that way a little easier, I changed the > Canaan devicetree Makefile so that it would build all of the devicetrees > in the directory if SOC_CANAAN. > > I *DO NOT* have any Canaan hardware so I have not tested any of this in > action. Since I sent v1, I tried to buy some since it's cheap - but could > out of the limited stockists none seemed to want to deliver to Ireland :( > I based the series on next-20220617. > I first tried to apply your series on top of next-20220630, but was greeted by a bunch of different warnings on boot, including endless RCU stall warnings. However, even when booting next-20220630 without your patches, I got the same warnings and RCU stall. So I tested your series on top of v5.19-rc4 + commit 0397d50f4cad ("spi: dt-bindings: Move 'rx-sample-delay-ns' to spi-peripheral-props.yaml") cherry-picked, (in order to avoid conflicts when applying your series,) and the board was working as intended, no warnings or RCU stalls. I tried both booting both via u-boot (with u-boots DTB) and booting the kernel (with an initrd) directly. I could successfully read data from the MMC in both cases. Therefore: Tested-by: Niklas Cassel <niklas.cassel@wdc.com>
On 30/06/2022 17:28, Niklas Cassel wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > On Wed, Jun 29, 2022 at 07:43:29PM +0100, Conor Dooley wrote: >> From: Conor Dooley <conor.dooley@microchip.com> >> >> Hey all, >> This series should rid us of dtbs_check errors for the RISC-V Canaan k210 >> based boards. To make keeping it that way a little easier, I changed the >> Canaan devicetree Makefile so that it would build all of the devicetrees >> in the directory if SOC_CANAAN. >> >> I *DO NOT* have any Canaan hardware so I have not tested any of this in >> action. Since I sent v1, I tried to buy some since it's cheap - but could >> out of the limited stockists none seemed to want to deliver to Ireland :( >> I based the series on next-20220617. >> > > I first tried to apply your series on top of next-20220630, > but was greeted by a bunch of different warnings on boot, > including endless RCU stall warnings. > However, even when booting next-20220630 without your patches, > I got the same warnings and RCU stall. > > So I tested your series on top of v5.19-rc4 + > commit 0397d50f4cad ("spi: dt-bindings: Move 'rx-sample-delay-ns' to > spi-peripheral-props.yaml") cherry-picked, > (in order to avoid conflicts when applying your series,) > and the board was working as intended, no warnings or RCU stalls. > > I tried both booting both via u-boot (with u-boots DTB) > and booting the kernel (with an initrd) directly. > I could successfully read data from the MMC in both cases. > > Therefore: > Tested-by: Niklas Cassel <niklas.cassel@wdc.com> Thanks Niklas.
On Wed, Jun 29, 2022 at 07:43:42PM +0100, Conor Dooley wrote: > From: Conor Dooley <conor.dooley@microchip.com> > > The k210 devicetrees warn about missing/empty reg and/or ranges > properties: > arch/riscv/boot/dts/canaan/k210.dtsi:408.22-460.5: Warning (unit_address_vs_reg): /soc/bus@52000000: node has a unit name, but no reg or ranges property > arch/riscv/boot/dts/canaan/k210.dtsi:352.22-406.5: Warning (simple_bus_reg): /soc/bus@50400000: missing or empty reg/ranges property > > Add reg and ranges properties that naively cap the buses after the > allocation of their last devices. > > Signed-off-by: Conor Dooley <conor.dooley@microchip.com> > --- > arch/riscv/boot/dts/canaan/k210.dtsi | 9 ++++++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > > diff --git a/arch/riscv/boot/dts/canaan/k210.dtsi b/arch/riscv/boot/dts/canaan/k210.dtsi > index 948dc235e39d..6a34dc4f3e51 100644 > --- a/arch/riscv/boot/dts/canaan/k210.dtsi > +++ b/arch/riscv/boot/dts/canaan/k210.dtsi > @@ -163,7 +163,8 @@ apb0: bus@50200000 { > #address-cells = <1>; > #size-cells = <1>; > compatible = "simple-pm-bus"; > - ranges; > + regs = <0x50200000 0x200000>; > + ranges = <0x50200000 0x50200000 0x200000>; This looks wrong. The property is called "reg" not "regs". And I don't think that you should provide "reg" at all, simply supplying "ranges" should be sufficient, no? Kind regards, Niklas > clocks = <&sysclk K210_CLK_APB0>; > > gpio1: gpio@50200000 { > @@ -382,7 +383,8 @@ apb1: bus@50400000 { > #address-cells = <1>; > #size-cells = <1>; > compatible = "simple-pm-bus"; > - ranges; > + regs = <0x50400000 0x40100>; > + ranges = <0x50400000 0x50400000 0x40100>; > clocks = <&sysclk K210_CLK_APB1>; > > wdt0: watchdog@50400000 { > @@ -437,7 +439,8 @@ apb2: bus@52000000 { > #address-cells = <1>; > #size-cells = <1>; > compatible = "simple-pm-bus"; > - ranges; > + regs = <0x52000000 0x2000200>; > + ranges = <0x52000000 0x52000000 0x2000200>; > clocks = <&sysclk K210_CLK_APB2>; > > spi0: spi@52000000 { > -- > 2.36.1 >
On 30/06/2022 17:49, Niklas Cassel wrote: > On Wed, Jun 29, 2022 at 07:43:42PM +0100, Conor Dooley wrote: >> From: Conor Dooley <conor.dooley@microchip.com> >> >> The k210 devicetrees warn about missing/empty reg and/or ranges >> properties: >> arch/riscv/boot/dts/canaan/k210.dtsi:408.22-460.5: Warning (unit_address_vs_reg): /soc/bus@52000000: node has a unit name, but no reg or ranges property >> arch/riscv/boot/dts/canaan/k210.dtsi:352.22-406.5: Warning (simple_bus_reg): /soc/bus@50400000: missing or empty reg/ranges property >> >> Add reg and ranges properties that naively cap the buses after the >> allocation of their last devices. >> >> Signed-off-by: Conor Dooley <conor.dooley@microchip.com> >> --- >> arch/riscv/boot/dts/canaan/k210.dtsi | 9 ++++++--- >> 1 file changed, 6 insertions(+), 3 deletions(-) >> >> diff --git a/arch/riscv/boot/dts/canaan/k210.dtsi b/arch/riscv/boot/dts/canaan/k210.dtsi >> index 948dc235e39d..6a34dc4f3e51 100644 >> --- a/arch/riscv/boot/dts/canaan/k210.dtsi >> +++ b/arch/riscv/boot/dts/canaan/k210.dtsi >> @@ -163,7 +163,8 @@ apb0: bus@50200000 { >> #address-cells = <1>; >> #size-cells = <1>; >> compatible = "simple-pm-bus"; >> - ranges; >> + regs = <0x50200000 0x200000>; >> + ranges = <0x50200000 0x50200000 0x200000>; > > This looks wrong. > > The property is called "reg" not "regs". Yeah... > > And I don't think that you should provide "reg" at all, > simply supplying "ranges" should be sufficient, no? I don't recall why I put the regs in, I'll drop it if possible & respond if I can't. IIRC, it did actually complain. > > > Kind regards, > Niklas > >> clocks = <&sysclk K210_CLK_APB0>; >> >> gpio1: gpio@50200000 { >> @@ -382,7 +383,8 @@ apb1: bus@50400000 { >> #address-cells = <1>; >> #size-cells = <1>; >> compatible = "simple-pm-bus"; >> - ranges; >> + regs = <0x50400000 0x40100>; >> + ranges = <0x50400000 0x50400000 0x40100>; >> clocks = <&sysclk K210_CLK_APB1>; >> >> wdt0: watchdog@50400000 { >> @@ -437,7 +439,8 @@ apb2: bus@52000000 { >> #address-cells = <1>; >> #size-cells = <1>; >> compatible = "simple-pm-bus"; >> - ranges; >> + regs = <0x52000000 0x2000200>; >> + ranges = <0x52000000 0x52000000 0x2000200>; >> clocks = <&sysclk K210_CLK_APB2>; >> >> spi0: spi@52000000 { >> -- >> 2.36.1
On Thu, Jun 30, 2022 at 04:28:26PM +0000, Niklas Cassel wrote: > On Wed, Jun 29, 2022 at 07:43:29PM +0100, Conor Dooley wrote: > > From: Conor Dooley <conor.dooley@microchip.com> > > > > Hey all, > > This series should rid us of dtbs_check errors for the RISC-V Canaan k210 > > based boards. To make keeping it that way a little easier, I changed the > > Canaan devicetree Makefile so that it would build all of the devicetrees > > in the directory if SOC_CANAAN. > > > > I *DO NOT* have any Canaan hardware so I have not tested any of this in > > action. Since I sent v1, I tried to buy some since it's cheap - but could > > out of the limited stockists none seemed to want to deliver to Ireland :( > > I based the series on next-20220617. > > > > I first tried to apply your series on top of next-20220630, > but was greeted by a bunch of different warnings on boot, > including endless RCU stall warnings. > However, even when booting next-20220630 without your patches, > I got the same warnings and RCU stall. > Is it possible to share the boot logs please ? Conor is having issues with my arch_topology/cacheinfo updates in -next. I would like to know if your issue is related to that or not ? > So I tested your series on top of v5.19-rc4 + > commit 0397d50f4cad ("spi: dt-bindings: Move 'rx-sample-delay-ns' to > spi-peripheral-props.yaml") cherry-picked, > (in order to avoid conflicts when applying your series,) > and the board was working as intended, no warnings or RCU stalls. > If possible can you give this branch[1] a try where my changes are and doesn't have any other changes from -next. Sorry to bother you. Conor seem to have issue with this commit[2], so if you get issues try to check if [3] works. Regards, Sudeep [1] https://git.kernel.org/sudeep.holla/c/ae85abf284e7 [2] https://git.kernel.org/sudeep.holla/c/155bd845d17b [3] https://git.kernel.org/sudeep.holla/c/009297d29faa
On 30/06/2022 18:53, Sudeep Holla wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > On Thu, Jun 30, 2022 at 04:28:26PM +0000, Niklas Cassel wrote: >> On Wed, Jun 29, 2022 at 07:43:29PM +0100, Conor Dooley wrote: >>> From: Conor Dooley <conor.dooley@microchip.com> >>> >>> Hey all, >>> This series should rid us of dtbs_check errors for the RISC-V Canaan k210 >>> based boards. To make keeping it that way a little easier, I changed the >>> Canaan devicetree Makefile so that it would build all of the devicetrees >>> in the directory if SOC_CANAAN. >>> >>> I *DO NOT* have any Canaan hardware so I have not tested any of this in >>> action. Since I sent v1, I tried to buy some since it's cheap - but could >>> out of the limited stockists none seemed to want to deliver to Ireland :( >>> I based the series on next-20220617. >>> >> >> I first tried to apply your series on top of next-20220630, >> but was greeted by a bunch of different warnings on boot, >> including endless RCU stall warnings. >> However, even when booting next-20220630 without your patches, >> I got the same warnings and RCU stall. >> > > Is it possible to share the boot logs please ? > Conor is having issues with my arch_topology/cacheinfo updates in -next. > I would like to know if your issue is related to that or not ? > >> So I tested your series on top of v5.19-rc4 + >> commit 0397d50f4cad ("spi: dt-bindings: Move 'rx-sample-delay-ns' to >> spi-peripheral-props.yaml") cherry-picked, >> (in order to avoid conflicts when applying your series,) >> and the board was working as intended, no warnings or RCU stalls. >> > > If possible can you give this branch[1] a try where my changes are and doesn't > have any other changes from -next. Sorry to bother you. > > Conor seem to have issue with this commit[2], so if you get issues try to > check if [3] works. FWIW, my problems with that are not on canaan hw. Thanks, Conor. > > Regards, > Sudeep > > [1] https://git.kernel.org/sudeep.holla/c/ae85abf284e7 > [2] https://git.kernel.org/sudeep.holla/c/155bd845d17b > [3] https://git.kernel.org/sudeep.holla/c/009297d29faa
On Thu, Jun 30, 2022 at 06:01:09PM +0000, Conor.Dooley@microchip.com wrote: > On 30/06/2022 18:53, Sudeep Holla wrote: > > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > > > On Thu, Jun 30, 2022 at 04:28:26PM +0000, Niklas Cassel wrote: > >> On Wed, Jun 29, 2022 at 07:43:29PM +0100, Conor Dooley wrote: > >>> From: Conor Dooley <conor.dooley@microchip.com> > >>> > >>> Hey all, > >>> This series should rid us of dtbs_check errors for the RISC-V Canaan k210 > >>> based boards. To make keeping it that way a little easier, I changed the > >>> Canaan devicetree Makefile so that it would build all of the devicetrees > >>> in the directory if SOC_CANAAN. > >>> > >>> I *DO NOT* have any Canaan hardware so I have not tested any of this in > >>> action. Since I sent v1, I tried to buy some since it's cheap - but could > >>> out of the limited stockists none seemed to want to deliver to Ireland :( > >>> I based the series on next-20220617. > >>> > >> > >> I first tried to apply your series on top of next-20220630, > >> but was greeted by a bunch of different warnings on boot, > >> including endless RCU stall warnings. > >> However, even when booting next-20220630 without your patches, > >> I got the same warnings and RCU stall. > >> > > > > Is it possible to share the boot logs please ? > > Conor is having issues with my arch_topology/cacheinfo updates in -next. > > I would like to know if your issue is related to that or not ? > > > >> So I tested your series on top of v5.19-rc4 + > >> commit 0397d50f4cad ("spi: dt-bindings: Move 'rx-sample-delay-ns' to > >> spi-peripheral-props.yaml") cherry-picked, > >> (in order to avoid conflicts when applying your series,) > >> and the board was working as intended, no warnings or RCU stalls. > >> > > > > If possible can you give this branch[1] a try where my changes are and doesn't > > have any other changes from -next. Sorry to bother you. > > > > Conor seem to have issue with this commit[2], so if you get issues try to > > check if [3] works. > > FWIW, my problems with that are not on canaan hw. I understand that, just helps to eliminate and see what are the possible issues.
On 30/06/2022 19:21, Sudeep Holla wrote: > On Thu, Jun 30, 2022 at 06:01:09PM +0000, Conor.Dooley@microchip.com wrote: >> On 30/06/2022 18:53, Sudeep Holla wrote: >>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe >>> >>> On Thu, Jun 30, 2022 at 04:28:26PM +0000, Niklas Cassel wrote: >>>> On Wed, Jun 29, 2022 at 07:43:29PM +0100, Conor Dooley wrote: >>>>> From: Conor Dooley <conor.dooley@microchip.com> >>>>> >>>>> Hey all, >>>>> This series should rid us of dtbs_check errors for the RISC-V Canaan k210 >>>>> based boards. To make keeping it that way a little easier, I changed the >>>>> Canaan devicetree Makefile so that it would build all of the devicetrees >>>>> in the directory if SOC_CANAAN. >>>>> >>>>> I *DO NOT* have any Canaan hardware so I have not tested any of this in >>>>> action. Since I sent v1, I tried to buy some since it's cheap - but could >>>>> out of the limited stockists none seemed to want to deliver to Ireland :( >>>>> I based the series on next-20220617. >>>>> >>>> >>>> I first tried to apply your series on top of next-20220630, >>>> but was greeted by a bunch of different warnings on boot, >>>> including endless RCU stall warnings. >>>> However, even when booting next-20220630 without your patches, >>>> I got the same warnings and RCU stall. >>>> >>> >>> Is it possible to share the boot logs please ? >>> Conor is having issues with my arch_topology/cacheinfo updates in -next. >>> I would like to know if your issue is related to that or not ? >>> >>>> So I tested your series on top of v5.19-rc4 + >>>> commit 0397d50f4cad ("spi: dt-bindings: Move 'rx-sample-delay-ns' to >>>> spi-peripheral-props.yaml") cherry-picked, >>>> (in order to avoid conflicts when applying your series,) >>>> and the board was working as intended, no warnings or RCU stalls. >>>> >>> >>> If possible can you give this branch[1] a try where my changes are and doesn't >>> have any other changes from -next. Sorry to bother you. >>> >>> Conor seem to have issue with this commit[2], so if you get issues try to >>> check if [3] works. >> >> FWIW, my problems with that are not on canaan hw. > > I understand that, just helps to eliminate and see what are the possible > issues. No no, I meant that for Niklas' benefit not yours. I get why you wanna know :)
On 30/06/2022 18:02, Conor Dooley wrote: > > > On 30/06/2022 17:49, Niklas Cassel wrote: >> On Wed, Jun 29, 2022 at 07:43:42PM +0100, Conor Dooley wrote: >>> From: Conor Dooley <conor.dooley@microchip.com> >>> >>> The k210 devicetrees warn about missing/empty reg and/or ranges >>> properties: >>> arch/riscv/boot/dts/canaan/k210.dtsi:408.22-460.5: Warning (unit_address_vs_reg): /soc/bus@52000000: node has a unit name, but no reg or ranges property >>> arch/riscv/boot/dts/canaan/k210.dtsi:352.22-406.5: Warning (simple_bus_reg): /soc/bus@50400000: missing or empty reg/ranges property >>> >>> Add reg and ranges properties that naively cap the buses after the >>> allocation of their last devices. >>> >>> Signed-off-by: Conor Dooley <conor.dooley@microchip.com> >>> --- >>> arch/riscv/boot/dts/canaan/k210.dtsi | 9 ++++++--- >>> 1 file changed, 6 insertions(+), 3 deletions(-) >>> >>> diff --git a/arch/riscv/boot/dts/canaan/k210.dtsi b/arch/riscv/boot/dts/canaan/k210.dtsi >>> index 948dc235e39d..6a34dc4f3e51 100644 >>> --- a/arch/riscv/boot/dts/canaan/k210.dtsi >>> +++ b/arch/riscv/boot/dts/canaan/k210.dtsi >>> @@ -163,7 +163,8 @@ apb0: bus@50200000 { >>> #address-cells = <1>; >>> #size-cells = <1>; >>> compatible = "simple-pm-bus"; >>> - ranges; >>> + regs = <0x50200000 0x200000>; >>> + ranges = <0x50200000 0x50200000 0x200000>; >> >> This looks wrong. >> >> The property is called "reg" not "regs". > > Yeah... > >> >> And I don't think that you should provide "reg" at all, >> simply supplying "ranges" should be sufficient, no? > > I don't recall why I put the regs in, I'll drop it if > possible & respond if I can't. > IIRC, it did actually complain. It does not complain. Good spot, thanks. I'll drop "regs" for v4. Conor.
On 7/1/22 02:53, Sudeep Holla wrote: > On Thu, Jun 30, 2022 at 04:28:26PM +0000, Niklas Cassel wrote: >> On Wed, Jun 29, 2022 at 07:43:29PM +0100, Conor Dooley wrote: >>> From: Conor Dooley <conor.dooley@microchip.com> >>> >>> Hey all, >>> This series should rid us of dtbs_check errors for the RISC-V Canaan k210 >>> based boards. To make keeping it that way a little easier, I changed the >>> Canaan devicetree Makefile so that it would build all of the devicetrees >>> in the directory if SOC_CANAAN. >>> >>> I *DO NOT* have any Canaan hardware so I have not tested any of this in >>> action. Since I sent v1, I tried to buy some since it's cheap - but could >>> out of the limited stockists none seemed to want to deliver to Ireland :( >>> I based the series on next-20220617. >>> >> >> I first tried to apply your series on top of next-20220630, >> but was greeted by a bunch of different warnings on boot, >> including endless RCU stall warnings. >> However, even when booting next-20220630 without your patches, >> I got the same warnings and RCU stall. >> > > Is it possible to share the boot logs please ? > Conor is having issues with my arch_topology/cacheinfo updates in -next. > I would like to know if your issue is related to that or not ? FYI, I see rcu warnings on boot on my dual-socket 8-cores Xeon system, but the same kernel does not have the rcu warnings with an AMD Epyc single socket 16-cores box. > >> So I tested your series on top of v5.19-rc4 + >> commit 0397d50f4cad ("spi: dt-bindings: Move 'rx-sample-delay-ns' to >> spi-peripheral-props.yaml") cherry-picked, >> (in order to avoid conflicts when applying your series,) >> and the board was working as intended, no warnings or RCU stalls. >> > > If possible can you give this branch[1] a try where my changes are and doesn't > have any other changes from -next. Sorry to bother you. > > Conor seem to have issue with this commit[2], so if you get issues try to > check if [3] works. > > Regards, > Sudeep > > [1] https://git.kernel.org/sudeep.holla/c/ae85abf284e7 > [2] https://git.kernel.org/sudeep.holla/c/155bd845d17b > [3] https://git.kernel.org/sudeep.holla/c/009297d29faa
On Wed, Jun 29, 2022 at 07:43:37PM +0100, Conor Dooley wrote: > From: Conor Dooley <conor.dooley@microchip.com> > > The timers on the k210 have non standard interrupt configurations, > which leads to dtbs_check warnings: > > k210_generic.dtb: timer@502d0000: interrupts: [[14], [15]] is too long > From schema: Documentation/devicetree/bindings/timer/snps,dw-apb-timer.yaml > > Split the timer nodes in two, so that the second timer in the IP block > can actually be accessed & in the process solve the dtbs_check warning. Reviewed-by: Serge Semin <fancer.lancer@gmail.com> Just to note. IMO the DW APB Timer driver has been incorrectly designed in the first place. The dts-node is supposed to describe the whole IP-core timers set as the original Canaan k210 DT-file expected, since there are common CSRs in the registers range, which currently get to be unreachable. But since the DT-bindings has already been defined that way in the framework of DW APB Timer driver alas there is nothing we can do to fix it. -Sergey > > Signed-off-by: Conor Dooley <conor.dooley@microchip.com> > --- > arch/riscv/boot/dts/canaan/k210.dtsi | 46 +++++++++++++++++++++++----- > 1 file changed, 38 insertions(+), 8 deletions(-) > > diff --git a/arch/riscv/boot/dts/canaan/k210.dtsi b/arch/riscv/boot/dts/canaan/k210.dtsi > index cd4eae82d8b2..72f70128d751 100644 > --- a/arch/riscv/boot/dts/canaan/k210.dtsi > +++ b/arch/riscv/boot/dts/canaan/k210.dtsi > @@ -319,28 +319,58 @@ fpioa: pinmux@502b0000 { > > timer0: timer@502d0000 { > compatible = "snps,dw-apb-timer"; > - reg = <0x502D0000 0x100>; > - interrupts = <14>, <15>; > + reg = <0x502D0000 0x14>; > + interrupts = <14>; > clocks = <&sysclk K210_CLK_TIMER0>, > <&sysclk K210_CLK_APB0>; > clock-names = "timer", "pclk"; > resets = <&sysrst K210_RST_TIMER0>; > }; > > - timer1: timer@502e0000 { > + timer1: timer@502d0014 { > compatible = "snps,dw-apb-timer"; > - reg = <0x502E0000 0x100>; > - interrupts = <16>, <17>; > + reg = <0x502D0014 0x14>; > + interrupts = <15>; > + clocks = <&sysclk K210_CLK_TIMER0>, > + <&sysclk K210_CLK_APB0>; > + clock-names = "timer", "pclk"; > + resets = <&sysrst K210_RST_TIMER0>; > + }; > + > + timer2: timer@502e0000 { > + compatible = "snps,dw-apb-timer"; > + reg = <0x502E0000 0x14>; > + interrupts = <16>; > clocks = <&sysclk K210_CLK_TIMER1>, > <&sysclk K210_CLK_APB0>; > clock-names = "timer", "pclk"; > resets = <&sysrst K210_RST_TIMER1>; > }; > > - timer2: timer@502f0000 { > + timer3: timer@502e0014 { > + compatible = "snps,dw-apb-timer"; > + reg = <0x502E0014 0x114>; > + interrupts = <17>; > + clocks = <&sysclk K210_CLK_TIMER1>, > + <&sysclk K210_CLK_APB0>; > + clock-names = "timer", "pclk"; > + resets = <&sysrst K210_RST_TIMER1>; > + }; > + > + timer4: timer@502f0000 { > + compatible = "snps,dw-apb-timer"; > + reg = <0x502F0000 0x14>; > + interrupts = <18>; > + clocks = <&sysclk K210_CLK_TIMER2>, > + <&sysclk K210_CLK_APB0>; > + clock-names = "timer", "pclk"; > + resets = <&sysrst K210_RST_TIMER2>; > + }; > + > + timer5: timer@502f0014 { > compatible = "snps,dw-apb-timer"; > - reg = <0x502F0000 0x100>; > - interrupts = <18>, <19>; > + reg = <0x502F0014 0x14>; > + interrupts = <19>; > clocks = <&sysclk K210_CLK_TIMER2>, > <&sysclk K210_CLK_APB0>; > clock-names = "timer", "pclk"; > -- > 2.36.1 >
On Wed, Jun 29, 2022 at 07:43:34PM +0100, Conor Dooley wrote: > From: Conor Dooley <conor.dooley@microchip.com> > > The Canaan k210 apparently has a Sysnopsys Designware AXI DMA > controller, but according to the documentation & devicetree it has 6 > interrupts rather than the standard one. Support the 6 interrupt > configuration by unconditionally extending the binding to a maximum of > 8 per-channel interrupts thereby matching the number of possible > channels. > > Link: https://canaan-creative.com/wp-content/uploads/2020/03/kendryte_standalone_programming_guide_20190311144158_en.pdf #Page 51 > Signed-off-by: Conor Dooley <conor.dooley@microchip.com> > --- > Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml b/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml > index 4324a94b26b2..e33ef22aec9c 100644 > --- a/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml > +++ b/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml > @@ -34,7 +34,9 @@ properties: > - const: axidma_apb_regs > > interrupts: > - maxItems: 1 > + description: per channel interrupts Description is inaccurate. It's either combined or per-channel IRQs. Other than that: Reviewed-by: Serge Semin <fancer.lancer@gmail.com> -Sergey > + minItems: 1 > + maxItems: 8 > > clocks: > items: > -- > 2.36.1 >
On 30/06/2022 22:55, Serge Semin wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > On Wed, Jun 29, 2022 at 07:43:34PM +0100, Conor Dooley wrote: >> From: Conor Dooley <conor.dooley@microchip.com> >> >> The Canaan k210 apparently has a Sysnopsys Designware AXI DMA >> controller, but according to the documentation & devicetree it has 6 >> interrupts rather than the standard one. Support the 6 interrupt >> configuration by unconditionally extending the binding to a maximum of >> 8 per-channel interrupts thereby matching the number of possible >> channels. >> >> Link: https://canaan-creative.com/wp-content/uploads/2020/03/kendryte_standalone_programming_guide_20190311144158_en.pdf #Page 51 >> Signed-off-by: Conor Dooley <conor.dooley@microchip.com> >> --- >> Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml | 4 +++- >> 1 file changed, 3 insertions(+), 1 deletion(-) >> >> diff --git a/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml b/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml >> index 4324a94b26b2..e33ef22aec9c 100644 >> --- a/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml >> +++ b/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml >> @@ -34,7 +34,9 @@ properties: >> - const: axidma_apb_regs >> >> interrupts: > >> - maxItems: 1 >> + description: per channel interrupts > > Description is inaccurate. It's either combined or per-channel IRQs. I will change it to: interrupts: description: | If the IP-core synthesis parameter DMAX_INTR_IO_TYPE is set to 1, this will be per-channel interrupts. Otherwise, this is a single combined IRQ for all channels. minItems: 1 maxItems: 8 How's that sound? > > Other than that: > Reviewed-by: Serge Semin <fancer.lancer@gmail.com> > > -Sergey > >> + minItems: 1 >> + maxItems: 8 >> >> clocks: >> items: >> -- >> 2.36.1 >>
On Wed, 29 Jun 2022 19:43:29 +0100, Conor Dooley wrote: > From: Conor Dooley <conor.dooley@microchip.com> > > Hey all, > This series should rid us of dtbs_check errors for the RISC-V Canaan k210 > based boards. To make keeping it that way a little easier, I changed the > Canaan devicetree Makefile so that it would build all of the devicetrees > in the directory if SOC_CANAAN. > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next Thanks! [04/15] spi: dt-bindings: dw-apb-ssi: update spi-{r,t}x-bus-width commit: 8b037cabc4966b010c44a76e05a43d276318bc49 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
On Fri, Jul 01, 2022 at 06:16:14AM +0900, Damien Le Moal wrote: > On 7/1/22 02:53, Sudeep Holla wrote: > > On Thu, Jun 30, 2022 at 04:28:26PM +0000, Niklas Cassel wrote: > >> On Wed, Jun 29, 2022 at 07:43:29PM +0100, Conor Dooley wrote: > >>> From: Conor Dooley <conor.dooley@microchip.com> > >>> > >>> Hey all, > >>> This series should rid us of dtbs_check errors for the RISC-V Canaan k210 > >>> based boards. To make keeping it that way a little easier, I changed the > >>> Canaan devicetree Makefile so that it would build all of the devicetrees > >>> in the directory if SOC_CANAAN. > >>> > >>> I *DO NOT* have any Canaan hardware so I have not tested any of this in > >>> action. Since I sent v1, I tried to buy some since it's cheap - but could > >>> out of the limited stockists none seemed to want to deliver to Ireland :( > >>> I based the series on next-20220617. > >>> > >> > >> I first tried to apply your series on top of next-20220630, > >> but was greeted by a bunch of different warnings on boot, > >> including endless RCU stall warnings. > >> However, even when booting next-20220630 without your patches, > >> I got the same warnings and RCU stall. > >> > > > > Is it possible to share the boot logs please ? > > Conor is having issues with my arch_topology/cacheinfo updates in -next. > > I would like to know if your issue is related to that or not ? > > FYI, I see rcu warnings on boot on my dual-socket 8-cores Xeon system, but > the same kernel does not have the rcu warnings with an AMD Epyc single > socket 16-cores box. And any chances of seeing the logs ?
On Wed, 29 Jun 2022 19:43:32 +0100, Conor Dooley wrote: > From: Conor Dooley <conor.dooley@microchip.com> > > Convert the Synopsys DesignWare I2S controller binding to dt-schema. > There was no listed maintainer but Jose Abreu was the last editor of the > txt binding so add him as maintainer. > > Signed-off-by: Conor Dooley <conor.dooley@microchip.com> > --- > .../bindings/sound/designware-i2s.txt | 35 ------- > .../bindings/sound/snps,designware-i2s.yaml | 94 +++++++++++++++++++ > 2 files changed, 94 insertions(+), 35 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/sound/designware-i2s.txt > create mode 100644 Documentation/devicetree/bindings/sound/snps,designware-i2s.yaml > Reviewed-by: Rob Herring <robh@kernel.org>
On Thu, Jun 30, 2022 at 11:12:53PM +0000, Conor.Dooley@microchip.com wrote: > On 30/06/2022 22:55, Serge Semin wrote: > > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > > > On Wed, Jun 29, 2022 at 07:43:34PM +0100, Conor Dooley wrote: > >> From: Conor Dooley <conor.dooley@microchip.com> > >> > >> The Canaan k210 apparently has a Sysnopsys Designware AXI DMA > >> controller, but according to the documentation & devicetree it has 6 > >> interrupts rather than the standard one. Support the 6 interrupt > >> configuration by unconditionally extending the binding to a maximum of > >> 8 per-channel interrupts thereby matching the number of possible > >> channels. > >> > >> Link: https://canaan-creative.com/wp-content/uploads/2020/03/kendryte_standalone_programming_guide_20190311144158_en.pdf #Page 51 > >> Signed-off-by: Conor Dooley <conor.dooley@microchip.com> > >> --- > >> Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml | 4 +++- > >> 1 file changed, 3 insertions(+), 1 deletion(-) > >> > >> diff --git a/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml b/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml > >> index 4324a94b26b2..e33ef22aec9c 100644 > >> --- a/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml > >> +++ b/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml > >> @@ -34,7 +34,9 @@ properties: > >> - const: axidma_apb_regs > >> > >> interrupts: > > > >> - maxItems: 1 > >> + description: per channel interrupts > > > > Description is inaccurate. It's either combined or per-channel IRQs. > > I will change it to: > interrupts: > description: | Don't need '|'. > If the IP-core synthesis parameter DMAX_INTR_IO_TYPE is set to 1, this > will be per-channel interrupts. Otherwise, this is a single combined IRQ > for all channels. > minItems: 1 > maxItems: 8 > > How's that sound? With that, Reviewed-by: Rob Herring <robh@kernel.org>
From: Conor Dooley <conor.dooley@microchip.com> Hey all, This series should rid us of dtbs_check errors for the RISC-V Canaan k210 based boards. To make keeping it that way a little easier, I changed the Canaan devicetree Makefile so that it would build all of the devicetrees in the directory if SOC_CANAAN. I *DO NOT* have any Canaan hardware so I have not tested any of this in action. Since I sent v1, I tried to buy some since it's cheap - but could out of the limited stockists none seemed to want to deliver to Ireland :( I based the series on next-20220617. Thanks, Conor. Changes since v2: - i2s: added clocks maxItems - dma: unconditionally extended the interrupts & dropped canaan compatible - timer: as per Sergey, split the timer dts nodes in 2 & drop the binding patch - ili9341: add a canaan specific compatible to the binding and dts Changes since v1: - I added a new dt node & compatible for the SRAM memory controller due Damien's wish to preserve the inter-op with U-Boot. - The dw-apb-ssi binding now uses the default rx/tx widths - A new patch fixes bus {ranges,reg} warnings - Rearranged the patches in a slightly more logical order Conor Dooley (15): dt-bindings: display: convert ilitek,ili9341.txt to dt-schema dt-bindings: display: ili9341: document canaan kd233's lcd ASoC: dt-bindings: convert designware-i2s to dt-schema spi: dt-bindings: dw-apb-ssi: update spi-{r,t}x-bus-width dt-bindings: dma: dw-axi-dmac: extend the number of interrupts dt-bindings: memory-controllers: add canaan k210 sram controller riscv: dts: canaan: fix the k210's memory node riscv: dts: canaan: fix the k210's timer nodes riscv: dts: canaan: fix mmc node names riscv: dts: canaan: fix kd233 display spi frequency riscv: dts: canaan: use custom compatible for k210 i2s riscv: dts: canaan: remove spi-max-frequency from controllers riscv: dts: canaan: fix bus {ranges,reg} warnings riscv: dts: canaan: add specific compatible for kd233's LCD riscv: dts: canaan: build all devicetress if SOC_CANAAN .../bindings/display/ilitek,ili9341.txt | 27 ------ .../display/panel/ilitek,ili9341.yaml | 49 +++++++--- .../bindings/dma/snps,dw-axi-dmac.yaml | 4 +- .../memory-controllers/canaan,k210-sram.yaml | 52 ++++++++++ .../bindings/sound/designware-i2s.txt | 35 ------- .../bindings/sound/snps,designware-i2s.yaml | 94 +++++++++++++++++++ .../bindings/spi/snps,dw-apb-ssi.yaml | 6 -- arch/riscv/boot/dts/canaan/Makefile | 10 +- arch/riscv/boot/dts/canaan/canaan_kd233.dts | 6 +- arch/riscv/boot/dts/canaan/k210.dtsi | 76 ++++++++++----- .../riscv/boot/dts/canaan/sipeed_maix_bit.dts | 2 +- .../boot/dts/canaan/sipeed_maix_dock.dts | 2 +- arch/riscv/boot/dts/canaan/sipeed_maix_go.dts | 2 +- .../boot/dts/canaan/sipeed_maixduino.dts | 2 +- 14 files changed, 253 insertions(+), 114 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/ilitek,ili9341.txt create mode 100644 Documentation/devicetree/bindings/memory-controllers/canaan,k210-sram.yaml delete mode 100644 Documentation/devicetree/bindings/sound/designware-i2s.txt create mode 100644 Documentation/devicetree/bindings/sound/snps,designware-i2s.yaml base-commit: 07dc787be2316e243a16a33d0a9b734cd9365bd3