| Message ID | 20220406161856.1669069-1-miquel.raynal@bootlin.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | RZN1 DMA support | expand |
Quoting Miquel Raynal (2022-04-06 09:18:47) > Hello, > > Here is a first series bringing DMA support to RZN1 platforms. Soon a > second series will come with changes made to the UART controller > driver, in order to interact with the RZN1 DMA controller. > > Stephen acked the sysctrl patch (in the clk driver) but somehow I feel > like it would be good to have this patch applied on both sides > (dmaengine and clk) because more changes will depend on the addition of > this helper, that are not related to DMA at all. I'll let you folks > figure out what is best. Are you sending more patches in the next 7 weeks or so that will touch the same area? If so, then it sounds like I'll need to take the clk patch through clk tree. I don't know what is best because I don't have the information about what everyone plans to do in that file.
Hi Stephen, sboyd@kernel.org wrote on Wed, 06 Apr 2022 17:45:09 -0700: > Quoting Miquel Raynal (2022-04-06 09:18:47) > > Hello, > > > > Here is a first series bringing DMA support to RZN1 platforms. Soon a > > second series will come with changes made to the UART controller > > driver, in order to interact with the RZN1 DMA controller. > > > > Stephen acked the sysctrl patch (in the clk driver) but somehow I feel > > like it would be good to have this patch applied on both sides > > (dmaengine and clk) because more changes will depend on the addition of > > this helper, that are not related to DMA at all. I'll let you folks > > figure out what is best. > > Are you sending more patches in the next 7 weeks or so that will touch > the same area? If so, then it sounds like I'll need to take the clk > patch through clk tree. I don't know what is best because I don't have > the information about what everyone plans to do in that file. This series brings DMA support and needs to access the dmamux registers that are in the sysctrl area. I've sent an RTC series which needs to access this area as well, but it is not fully ready yet as it was advised to go for a reset controller in this case. The reset controller would be registered by the clock driver, so yes it would touch the same file. Finally, there is an USB series that is coming soon, I don't know if it will be ready for merge for 5.19, but it needs to access a specific register in this area as well (h2mode). So provided that we are able to contribute this reset driver quickly enough, I would argue that it is safer to merge the clk changes in the clk tree. Thanks, Miquèl
Hi Miquel, On Thu, Apr 7, 2022 at 10:16 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote: > sboyd@kernel.org wrote on Wed, 06 Apr 2022 17:45:09 -0700: > > Quoting Miquel Raynal (2022-04-06 09:18:47) > > > Here is a first series bringing DMA support to RZN1 platforms. Soon a > > > second series will come with changes made to the UART controller > > > driver, in order to interact with the RZN1 DMA controller. > > > > > > Stephen acked the sysctrl patch (in the clk driver) but somehow I feel > > > like it would be good to have this patch applied on both sides > > > (dmaengine and clk) because more changes will depend on the addition of > > > this helper, that are not related to DMA at all. I'll let you folks > > > figure out what is best. > > > > Are you sending more patches in the next 7 weeks or so that will touch > > the same area? If so, then it sounds like I'll need to take the clk > > patch through clk tree. I don't know what is best because I don't have > > the information about what everyone plans to do in that file. > > This series brings DMA support and needs to access the dmamux registers > that are in the sysctrl area. > > I've sent an RTC series which needs to access this area as well, but > it is not fully ready yet as it was advised to go for a reset > controller in this case. The reset controller would be registered by > the clock driver, so yes it would touch the same file. > > Finally, there is an USB series that is coming soon, I don't know if > it will be ready for merge for 5.19, but it needs to access a specific > register in this area as well (h2mode). > > So provided that we are able to contribute this reset driver quickly > enough, I would argue that it is safer to merge the clk changes in the > clk tree. The clk tree or the renesas-clk tree? ;-) Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
Hi Geert, geert@linux-m68k.org wrote on Mon, 11 Apr 2022 17:09:50 +0200: > Hi Miquel, > > On Thu, Apr 7, 2022 at 10:16 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > sboyd@kernel.org wrote on Wed, 06 Apr 2022 17:45:09 -0700: > > > Quoting Miquel Raynal (2022-04-06 09:18:47) > > > > Here is a first series bringing DMA support to RZN1 platforms. Soon a > > > > second series will come with changes made to the UART controller > > > > driver, in order to interact with the RZN1 DMA controller. > > > > > > > > Stephen acked the sysctrl patch (in the clk driver) but somehow I feel > > > > like it would be good to have this patch applied on both sides > > > > (dmaengine and clk) because more changes will depend on the addition of > > > > this helper, that are not related to DMA at all. I'll let you folks > > > > figure out what is best. > > > > > > Are you sending more patches in the next 7 weeks or so that will touch > > > the same area? If so, then it sounds like I'll need to take the clk > > > patch through clk tree. I don't know what is best because I don't have > > > the information about what everyone plans to do in that file. > > > > This series brings DMA support and needs to access the dmamux registers > > that are in the sysctrl area. > > > > I've sent an RTC series which needs to access this area as well, but > > it is not fully ready yet as it was advised to go for a reset > > controller in this case. The reset controller would be registered by > > the clock driver, so yes it would touch the same file. > > > > Finally, there is an USB series that is coming soon, I don't know if > > it will be ready for merge for 5.19, but it needs to access a specific > > register in this area as well (h2mode). > > > > So provided that we are able to contribute this reset driver quickly > > enough, I would argue that it is safer to merge the clk changes in the > > clk tree. > > The clk tree or the renesas-clk tree? ;-) Actually I forgot about this tree, would you mind to merge *all* the patches that depend on the sysctrl changes in the renesas/renesas-clk tree? This also stands for the UART and RTC for instance. Otherwise you'll need to set up immutable branches and share them with the dmaengine, serial and rtc trees. I'm fine either way, it's just much less work in the first situation IMHO. Thanks, Miquèl
Hi Miquel, On Tue, Apr 12, 2022 at 9:32 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote: > geert@linux-m68k.org wrote on Mon, 11 Apr 2022 17:09:50 +0200: > > On Thu, Apr 7, 2022 at 10:16 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > > sboyd@kernel.org wrote on Wed, 06 Apr 2022 17:45:09 -0700: > > > > Quoting Miquel Raynal (2022-04-06 09:18:47) > > > > > Here is a first series bringing DMA support to RZN1 platforms. Soon a > > > > > second series will come with changes made to the UART controller > > > > > driver, in order to interact with the RZN1 DMA controller. > > > > > > > > > > Stephen acked the sysctrl patch (in the clk driver) but somehow I feel > > > > > like it would be good to have this patch applied on both sides > > > > > (dmaengine and clk) because more changes will depend on the addition of > > > > > this helper, that are not related to DMA at all. I'll let you folks > > > > > figure out what is best. > > > > > > > > Are you sending more patches in the next 7 weeks or so that will touch > > > > the same area? If so, then it sounds like I'll need to take the clk > > > > patch through clk tree. I don't know what is best because I don't have > > > > the information about what everyone plans to do in that file. > > > > > > This series brings DMA support and needs to access the dmamux registers > > > that are in the sysctrl area. > > > > > > I've sent an RTC series which needs to access this area as well, but > > > it is not fully ready yet as it was advised to go for a reset > > > controller in this case. The reset controller would be registered by > > > the clock driver, so yes it would touch the same file. > > > > > > Finally, there is an USB series that is coming soon, I don't know if > > > it will be ready for merge for 5.19, but it needs to access a specific > > > register in this area as well (h2mode). > > > > > > So provided that we are able to contribute this reset driver quickly > > > enough, I would argue that it is safer to merge the clk changes in the > > > clk tree. > > > > The clk tree or the renesas-clk tree? ;-) > > Actually I forgot about this tree, would you mind to merge *all* the > patches that depend on the sysctrl changes in the renesas/renesas-clk > tree? This also stands for the UART and RTC for instance. Otherwise > you'll need to set up immutable branches and share them with the > dmaengine, serial and rtc trees. I'm fine either way, it's just much > less work in the first situation IMHO. Sure, I can do that, given acks from the DMA, UART, and RTC maintainers. So far I've been rather terse in giving feedback on these series, as I'm in wait-and-see mode w.r.t. what else you've planned for the sysctrl DT node[1] and clock/sys controller code... [1] Did I say I'm not that fond of child nodes? But for the dmamux, it looks like a good solution to handle this. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
Hi Geert, geert@linux-m68k.org wrote on Tue, 12 Apr 2022 09:37:22 +0200: > Hi Miquel, > > On Tue, Apr 12, 2022 at 9:32 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > geert@linux-m68k.org wrote on Mon, 11 Apr 2022 17:09:50 +0200: > > > On Thu, Apr 7, 2022 at 10:16 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > > > sboyd@kernel.org wrote on Wed, 06 Apr 2022 17:45:09 -0700: > > > > > Quoting Miquel Raynal (2022-04-06 09:18:47) > > > > > > Here is a first series bringing DMA support to RZN1 platforms. Soon a > > > > > > second series will come with changes made to the UART controller > > > > > > driver, in order to interact with the RZN1 DMA controller. > > > > > > > > > > > > Stephen acked the sysctrl patch (in the clk driver) but somehow I feel > > > > > > like it would be good to have this patch applied on both sides > > > > > > (dmaengine and clk) because more changes will depend on the addition of > > > > > > this helper, that are not related to DMA at all. I'll let you folks > > > > > > figure out what is best. > > > > > > > > > > Are you sending more patches in the next 7 weeks or so that will touch > > > > > the same area? If so, then it sounds like I'll need to take the clk > > > > > patch through clk tree. I don't know what is best because I don't have > > > > > the information about what everyone plans to do in that file. > > > > > > > > This series brings DMA support and needs to access the dmamux registers > > > > that are in the sysctrl area. > > > > > > > > I've sent an RTC series which needs to access this area as well, but > > > > it is not fully ready yet as it was advised to go for a reset > > > > controller in this case. The reset controller would be registered by > > > > the clock driver, so yes it would touch the same file. > > > > > > > > Finally, there is an USB series that is coming soon, I don't know if > > > > it will be ready for merge for 5.19, but it needs to access a specific > > > > register in this area as well (h2mode). > > > > > > > > So provided that we are able to contribute this reset driver quickly > > > > enough, I would argue that it is safer to merge the clk changes in the > > > > clk tree. > > > > > > The clk tree or the renesas-clk tree? ;-) > > > > Actually I forgot about this tree, would you mind to merge *all* the > > patches that depend on the sysctrl changes in the renesas/renesas-clk > > tree? This also stands for the UART and RTC for instance. Otherwise > > you'll need to set up immutable branches and share them with the > > dmaengine, serial and rtc trees. I'm fine either way, it's just much > > less work in the first situation IMHO. > > Sure, I can do that, given acks from the DMA, UART, and RTC > maintainers. Ok, I'll say so in the cover letter of the v9. > So far I've been rather terse in giving feedback on these series, > as I'm in wait-and-see mode w.r.t. what else you've planned for the > sysctrl DT node[1] and clock/sys controller code... > > [1] Did I say I'm not that fond of child nodes? But for the dmamux, > it looks like a good solution to handle this. O:-) I plan in the coming days to write a proper reset controller driver that will be queried by the rtc driver (as proposed by Alexandre). Which means I'll have to declare this reset controller as a child of the systrl node. If you disagree with it, you may jump-in, see this thread : Subject: Re: [PATCH 2/7] soc: renesas: rzn1-sysc: Export a function to enable/disable the RTC Date: Wed, 6 Apr 2022 10:32:31 +0200 Thanks, Miquèl
Hi Miquel, On Tue, Apr 12, 2022 at 9:43 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote: > geert@linux-m68k.org wrote on Tue, 12 Apr 2022 09:37:22 +0200: > > On Tue, Apr 12, 2022 at 9:32 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > > geert@linux-m68k.org wrote on Mon, 11 Apr 2022 17:09:50 +0200: > > > > On Thu, Apr 7, 2022 at 10:16 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > > > > sboyd@kernel.org wrote on Wed, 06 Apr 2022 17:45:09 -0700: > > > > > > Quoting Miquel Raynal (2022-04-06 09:18:47) > > > > > > > Here is a first series bringing DMA support to RZN1 platforms. Soon a > > > > > > > second series will come with changes made to the UART controller > > > > > > > driver, in order to interact with the RZN1 DMA controller. > > > > > > > > > > > > > > Stephen acked the sysctrl patch (in the clk driver) but somehow I feel > > > > > > > like it would be good to have this patch applied on both sides > > > > > > > (dmaengine and clk) because more changes will depend on the addition of > > > > > > > this helper, that are not related to DMA at all. I'll let you folks > > > > > > > figure out what is best. > > > > > > > > > > > > Are you sending more patches in the next 7 weeks or so that will touch > > > > > > the same area? If so, then it sounds like I'll need to take the clk > > > > > > patch through clk tree. I don't know what is best because I don't have > > > > > > the information about what everyone plans to do in that file. > > > > > > > > > > This series brings DMA support and needs to access the dmamux registers > > > > > that are in the sysctrl area. > > > > > > > > > > I've sent an RTC series which needs to access this area as well, but > > > > > it is not fully ready yet as it was advised to go for a reset > > > > > controller in this case. The reset controller would be registered by > > > > > the clock driver, so yes it would touch the same file. > > > > > > > > > > Finally, there is an USB series that is coming soon, I don't know if > > > > > it will be ready for merge for 5.19, but it needs to access a specific > > > > > register in this area as well (h2mode). > > > > > > > > > > So provided that we are able to contribute this reset driver quickly > > > > > enough, I would argue that it is safer to merge the clk changes in the > > > > > clk tree. > > > > > > > > The clk tree or the renesas-clk tree? ;-) > > > > > > Actually I forgot about this tree, would you mind to merge *all* the > > > patches that depend on the sysctrl changes in the renesas/renesas-clk > > > tree? This also stands for the UART and RTC for instance. Otherwise > > > you'll need to set up immutable branches and share them with the > > > dmaengine, serial and rtc trees. I'm fine either way, it's just much > > > less work in the first situation IMHO. > > > > Sure, I can do that, given acks from the DMA, UART, and RTC > > maintainers. > > Ok, I'll say so in the cover letter of the v9. > > > So far I've been rather terse in giving feedback on these series, > > as I'm in wait-and-see mode w.r.t. what else you've planned for the > > sysctrl DT node[1] and clock/sys controller code... > > > > [1] Did I say I'm not that fond of child nodes? But for the dmamux, > > it looks like a good solution to handle this. > > O:-) > > I plan in the coming days to write a proper reset controller driver > that will be queried by the rtc driver (as proposed by Alexandre). OK. > Which means I'll have to declare this reset controller as a child of > the systrl node. If you disagree with it, you may jump-in, see this > thread : > > Subject: Re: [PATCH 2/7] soc: renesas: rzn1-sysc: Export a > function to enable/disable the RTC > Date: Wed, 6 Apr 2022 10:32:31 +0200 But do you need a child node for that? All(most all) other Renesas clock drivers provide reset functionality, and none of them use a child node for that. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
Hi Geert, geert@linux-m68k.org wrote on Tue, 12 Apr 2022 09:52:25 +0200: > Hi Miquel, > > On Tue, Apr 12, 2022 at 9:43 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > geert@linux-m68k.org wrote on Tue, 12 Apr 2022 09:37:22 +0200: > > > On Tue, Apr 12, 2022 at 9:32 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > > > geert@linux-m68k.org wrote on Mon, 11 Apr 2022 17:09:50 +0200: > > > > > On Thu, Apr 7, 2022 at 10:16 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > > > > > sboyd@kernel.org wrote on Wed, 06 Apr 2022 17:45:09 -0700: > > > > > > > Quoting Miquel Raynal (2022-04-06 09:18:47) > > > > > > > > Here is a first series bringing DMA support to RZN1 platforms. Soon a > > > > > > > > second series will come with changes made to the UART controller > > > > > > > > driver, in order to interact with the RZN1 DMA controller. > > > > > > > > > > > > > > > > Stephen acked the sysctrl patch (in the clk driver) but somehow I feel > > > > > > > > like it would be good to have this patch applied on both sides > > > > > > > > (dmaengine and clk) because more changes will depend on the addition of > > > > > > > > this helper, that are not related to DMA at all. I'll let you folks > > > > > > > > figure out what is best. > > > > > > > > > > > > > > Are you sending more patches in the next 7 weeks or so that will touch > > > > > > > the same area? If so, then it sounds like I'll need to take the clk > > > > > > > patch through clk tree. I don't know what is best because I don't have > > > > > > > the information about what everyone plans to do in that file. > > > > > > > > > > > > This series brings DMA support and needs to access the dmamux registers > > > > > > that are in the sysctrl area. > > > > > > > > > > > > I've sent an RTC series which needs to access this area as well, but > > > > > > it is not fully ready yet as it was advised to go for a reset > > > > > > controller in this case. The reset controller would be registered by > > > > > > the clock driver, so yes it would touch the same file. > > > > > > > > > > > > Finally, there is an USB series that is coming soon, I don't know if > > > > > > it will be ready for merge for 5.19, but it needs to access a specific > > > > > > register in this area as well (h2mode). > > > > > > > > > > > > So provided that we are able to contribute this reset driver quickly > > > > > > enough, I would argue that it is safer to merge the clk changes in the > > > > > > clk tree. > > > > > > > > > > The clk tree or the renesas-clk tree? ;-) > > > > > > > > Actually I forgot about this tree, would you mind to merge *all* the > > > > patches that depend on the sysctrl changes in the renesas/renesas-clk > > > > tree? This also stands for the UART and RTC for instance. Otherwise > > > > you'll need to set up immutable branches and share them with the > > > > dmaengine, serial and rtc trees. I'm fine either way, it's just much > > > > less work in the first situation IMHO. > > > > > > Sure, I can do that, given acks from the DMA, UART, and RTC > > > maintainers. > > > > Ok, I'll say so in the cover letter of the v9. > > > > > So far I've been rather terse in giving feedback on these series, > > > as I'm in wait-and-see mode w.r.t. what else you've planned for the > > > sysctrl DT node[1] and clock/sys controller code... > > > > > > [1] Did I say I'm not that fond of child nodes? But for the dmamux, > > > it looks like a good solution to handle this. > > > > O:-) > > > > I plan in the coming days to write a proper reset controller driver > > that will be queried by the rtc driver (as proposed by Alexandre). > > OK. > > > Which means I'll have to declare this reset controller as a child of > > the systrl node. If you disagree with it, you may jump-in, see this > > thread : > > > > Subject: Re: [PATCH 2/7] soc: renesas: rzn1-sysc: Export a > > function to enable/disable the RTC > > Date: Wed, 6 Apr 2022 10:32:31 +0200 > > But do you need a child node for that? All(most all) other Renesas > clock drivers provide reset functionality, and none of them use a > child node for that. How do you "request" the reset handle from the consumer driver if it's not described in the DT? Do you have examples to share? Thanks, Miquèl
Hi Miquel, On Tue, Apr 12, 2022 at 10:03 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote: > geert@linux-m68k.org wrote on Tue, 12 Apr 2022 09:52:25 +0200: > > On Tue, Apr 12, 2022 at 9:43 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > > geert@linux-m68k.org wrote on Tue, 12 Apr 2022 09:37:22 +0200: > > > > So far I've been rather terse in giving feedback on these series, > > > > as I'm in wait-and-see mode w.r.t. what else you've planned for the > > > > sysctrl DT node[1] and clock/sys controller code... > > > > > > > > [1] Did I say I'm not that fond of child nodes? But for the dmamux, > > > > it looks like a good solution to handle this. > > > > > > O:-) > > > > > > I plan in the coming days to write a proper reset controller driver > > > that will be queried by the rtc driver (as proposed by Alexandre). > > > > OK. > > > > > Which means I'll have to declare this reset controller as a child of > > > the systrl node. If you disagree with it, you may jump-in, see this > > > thread : > > > > > > Subject: Re: [PATCH 2/7] soc: renesas: rzn1-sysc: Export a > > > function to enable/disable the RTC > > > Date: Wed, 6 Apr 2022 10:32:31 +0200 > > > > But do you need a child node for that? All(most all) other Renesas > > clock drivers provide reset functionality, and none of them use a > > child node for that. > > How do you "request" the reset handle from the consumer driver if it's > not described in the DT? Do you have examples to share? I didn't say it does not need to be described in DT ;-) Just add "#reset-cells = <1>" to the sysctrl node, and nodes can start referring to it using "resets = <&sysctrl N>". Currently, the sysctrl node is already a clock and power-domain provider. Documentation/devicetree/bindings/clock/renesas,cpg-mssr.yaml shows an R-Car CPG/MSSR node providing clock, power-domain, and reset functionalities. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
Hi Geert, geert@linux-m68k.org wrote on Tue, 12 Apr 2022 10:12:41 +0200: > Hi Miquel, > > On Tue, Apr 12, 2022 at 10:03 AM Miquel Raynal > <miquel.raynal@bootlin.com> wrote: > > geert@linux-m68k.org wrote on Tue, 12 Apr 2022 09:52:25 +0200: > > > On Tue, Apr 12, 2022 at 9:43 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > > > geert@linux-m68k.org wrote on Tue, 12 Apr 2022 09:37:22 +0200: > > > > > So far I've been rather terse in giving feedback on these series, > > > > > as I'm in wait-and-see mode w.r.t. what else you've planned for the > > > > > sysctrl DT node[1] and clock/sys controller code... > > > > > > > > > > [1] Did I say I'm not that fond of child nodes? But for the dmamux, > > > > > it looks like a good solution to handle this. > > > > > > > > O:-) > > > > > > > > I plan in the coming days to write a proper reset controller driver > > > > that will be queried by the rtc driver (as proposed by Alexandre). > > > > > > OK. > > > > > > > Which means I'll have to declare this reset controller as a child of > > > > the systrl node. If you disagree with it, you may jump-in, see this > > > > thread : > > > > > > > > Subject: Re: [PATCH 2/7] soc: renesas: rzn1-sysc: Export a > > > > function to enable/disable the RTC > > > > Date: Wed, 6 Apr 2022 10:32:31 +0200 > > > > > > But do you need a child node for that? All(most all) other Renesas > > > clock drivers provide reset functionality, and none of them use a > > > child node for that. > > > > How do you "request" the reset handle from the consumer driver if it's > > not described in the DT? Do you have examples to share? > > I didn't say it does not need to be described in DT ;-) > > Just add "#reset-cells = <1>" to the sysctrl node, and nodes can > start referring to it using "resets = <&sysctrl N>". > Currently, the sysctrl node is already a clock and power-domain provider. > > Documentation/devicetree/bindings/clock/renesas,cpg-mssr.yaml > shows an R-Car CPG/MSSR node providing clock, power-domain, and > reset functionalities. Ok, works for me ;) > > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > > In personal conversations with technical people, I call myself a hacker. But > when I'm talking to journalists I just say "programmer" or something like that. > -- Linus Torvalds Thanks, Miquèl
Hi Geert, geert@linux-m68k.org wrote on Tue, 12 Apr 2022 10:12:41 +0200: > Hi Miquel, > > On Tue, Apr 12, 2022 at 10:03 AM Miquel Raynal > <miquel.raynal@bootlin.com> wrote: > > geert@linux-m68k.org wrote on Tue, 12 Apr 2022 09:52:25 +0200: > > > On Tue, Apr 12, 2022 at 9:43 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > > > geert@linux-m68k.org wrote on Tue, 12 Apr 2022 09:37:22 +0200: > > > > > So far I've been rather terse in giving feedback on these series, > > > > > as I'm in wait-and-see mode w.r.t. what else you've planned for the > > > > > sysctrl DT node[1] and clock/sys controller code... > > > > > > > > > > [1] Did I say I'm not that fond of child nodes? But for the dmamux, > > > > > it looks like a good solution to handle this. > > > > > > > > O:-) > > > > > > > > I plan in the coming days to write a proper reset controller driver > > > > that will be queried by the rtc driver (as proposed by Alexandre). > > > > > > OK. > > > > > > > Which means I'll have to declare this reset controller as a child of > > > > the systrl node. If you disagree with it, you may jump-in, see this > > > > thread : > > > > > > > > Subject: Re: [PATCH 2/7] soc: renesas: rzn1-sysc: Export a > > > > function to enable/disable the RTC > > > > Date: Wed, 6 Apr 2022 10:32:31 +0200 > > > > > > But do you need a child node for that? All(most all) other Renesas > > > clock drivers provide reset functionality, and none of them use a > > > child node for that. > > > > How do you "request" the reset handle from the consumer driver if it's > > not described in the DT? Do you have examples to share? > > I didn't say it does not need to be described in DT ;-) > > Just add "#reset-cells = <1>" to the sysctrl node, and nodes can > start referring to it using "resets = <&sysctrl N>". > Currently, the sysctrl node is already a clock and power-domain provider. > > Documentation/devicetree/bindings/clock/renesas,cpg-mssr.yaml > shows an R-Car CPG/MSSR node providing clock, power-domain, and > reset functionalities. While working on implementing a reset controller driver, I realized that almost all the clocks had a reset, which was already managed by the driver as part of a number of additional possible signals (gate reset, gate master idle, gate ready...). So I actually figured out that my issue originated from an incomplete description of the RTC clock gate, which I fulfilled. Now it works without the need for an additional exported symbol. Thanks, Miquèl
Hello, Here is a first series bringing DMA support to RZN1 platforms. Soon a second series will come with changes made to the UART controller driver, in order to interact with the RZN1 DMA controller. Stephen acked the sysctrl patch (in the clk driver) but somehow I feel like it would be good to have this patch applied on both sides (dmaengine and clk) because more changes will depend on the addition of this helper, that are not related to DMA at all. I'll let you folks figure out what is best. Cheers, Miquèl Changes in v8: * Collected more tags. * Moved the Makefile line adding the dmamux driver to the bottom of the file. * Reversed the logic in a ternary operation as suggested by Andy. * Changed a bit the naming of a #define as suggested by Andy. Changes in v7: * This time, really added Stephen's Acks (sorry for the error). * Moved an error check to get rid of one mutex_unlock/lock call as suggested by Ilpo. * Split the patch adding the dmamux driver as advised by Vinod. One patch introduces the dmamux driver, the other populates the children of the system controller. As the original patch got acked by Stephen Boyd, I moved his tag to the patch touching the clock controller only. Changes in v6: * Added Stephen's acks. * Fixed an extra newline added in the middle of nowhere. * Rebased on top of v5.18-rc1. Changes in v5: * Used gotos in rzn1_dmamux_route_allocate(). * Changed the prefix to "dmaengine:". * Dropped the partial transfers fix. * Added Rob's acks. Changes in v4: * Freed "map" in the error path of the dmamux driver. * Improved a bit the style as requested by Prabhakar. * Dropped a __maybe_unused. * Reorder the includes. * Added a dependency on ARCH_RZN1. * Added Rob's Ack. * Added a reg property to the dmamux binding file. * Referenced the dmamux binding from the system controller file. * Called of_platform_populate from the end of the system controller (clock) driver probe in order to probe the dmamux if it was populated. * Added DMA properties to all the relevant UARTs. Changes in v3: * Added Reviewed-by tags. * Exported the set_dmamux* symbol properly. * Dropped a useless check in the probe and moved the sysctrl_priv assignation to the end of the probe. * Renamed the dmamux driver * Added a couple of missing MODULE_ macros in the dmamux driver. * Decided to use a regular platform init call instead of the arch_initcall() initially proposed. * s/%d/%u/ in printk's when appropriate. * Used a hardcoded value instead of dmamux->dmac_requests when appropriate. * Changed the variable name "master" to "dmac_idx" to be more descriptive. * Dropped most of the of_* calls in favor of #define's. * Fixed a typo. * Exported two symbols from 8250_dma.c. Changes in v2: * Clarified that the 'fix' regarding non aligned reads would only apply to the DEV_TO_MEM case. * Fix the DMA controller compatible string (copy-paste error). * s/syscon/sysctrl/ as advised by Geert. * Disabled irqs when taking the spinlock from the clocks driver. * Moved the DMAMUX offset inside the driver. * Removed extra commas. * Improved the style as suggested by Andy. * Removed a dupplicated check against the device node presence. * Reduced the number of lines of code by using dev_err_probe(). * Created a Kconfig symbol for DMAMUX to fix the two robot reports received and be sure there was no useless overhead with other platforms. * Exported the serial8250_{tx,rx}_dma() symbols. Miquel Raynal (9): dt-bindings: dmaengine: Introduce RZN1 dmamux bindings dt-bindings: clock: r9a06g032-sysctrl: Reference the DMAMUX subnode dt-bindings: dmaengine: Introduce RZN1 DMA compatible soc: renesas: rzn1-sysc: Export function to set dmamux dmaengine: dw: dmamux: Introduce RZN1 DMA router support clk: renesas: r9a06g032: Probe possible children dmaengine: dw: Add RZN1 compatible ARM: dts: r9a06g032: Add the two DMA nodes ARM: dts: r9a06g032: Describe the DMA router .../clock/renesas,r9a06g032-sysctrl.yaml | 11 ++ .../bindings/dma/renesas,rzn1-dmamux.yaml | 51 ++++++ .../bindings/dma/snps,dma-spear1340.yaml | 8 +- MAINTAINERS | 1 + arch/arm/boot/dts/r9a06g032.dtsi | 40 +++++ drivers/clk/renesas/r9a06g032-clocks.c | 36 +++- drivers/dma/dw/Kconfig | 9 + drivers/dma/dw/Makefile | 2 + drivers/dma/dw/platform.c | 1 + drivers/dma/dw/rzn1-dmamux.c | 157 ++++++++++++++++++ include/linux/soc/renesas/r9a06g032-sysctrl.h | 11 ++ 11 files changed, 325 insertions(+), 2 deletions(-) create mode 100644 Documentation/devicetree/bindings/dma/renesas,rzn1-dmamux.yaml create mode 100644 drivers/dma/dw/rzn1-dmamux.c create mode 100644 include/linux/soc/renesas/r9a06g032-sysctrl.h