RE: [PATCH 4/5] arm64: dts: renesas: r9a07g044: Add DMAC support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Geert,

Thanks for the feedback.

> Subject: Re: [PATCH 4/5] arm64: dts: renesas: r9a07g044: Add DMAC support
> 
> Hi Biju,
> 
> On Mon, Jun 14, 2021 at 3:02 PM Biju Das <biju.das.jz@xxxxxxxxxxxxxx>
> wrote:
> > > Subject: Re: [PATCH 4/5] arm64: dts: renesas: r9a07g044: Add DMAC
> > > support On Fri, Jun 11, 2021 at 1:36 PM Biju Das
> > > <biju.das.jz@xxxxxxxxxxxxxx>
> > > wrote:
> > > > Add DMAC support to RZ/G2L SoC DT.
> > > >
> > > > Signed-off-by: Biju Das <biju.das.jz@xxxxxxxxxxxxxx>
> > > > Reviewed-by: Lad Prabhakar
> > > > <prabhakar.mahadev-lad.rj@xxxxxxxxxxxxxx>
> > >
> > > Thanks for your patch!
> > >
> > > > --- a/arch/arm64/boot/dts/renesas/r9a07g044.dtsi
> > > > +++ b/arch/arm64/boot/dts/renesas/r9a07g044.dtsi
> > > > @@ -8,6 +8,10 @@
> > > >  #include <dt-bindings/interrupt-controller/arm-gic.h>
> > > >  #include <dt-bindings/clock/r9a07g044-cpg.h>
> > > >
> > > > +#define CH_CFG(reqd, loen, hien, lvl, am, sds, dds, tm) \
> > > > +       ((((tm) << 22) | ((dds) << 16) | ((sds) << 12) | ((am) << 8)
> | \
> > > > +       ((lvl) << 6) | ((hien) << 5) | ((loen) << 4) | ((reqd) <<
> > > > +3)) & 0x004FF778)
> > > > +
> > >
> > > I assume the above will be removed?
> >
> > Basically the macro simplifies the channel configuration values in Table
> 16.4 page 569 of the hardware manual.
> >
> > Client driver will use MID+RID, and pass (Src address or dest address
> > along with the channel configuration values For configuring DMA channel.
> >
> > For eg:-
> >
> >                 ssi0: ssi@10049c00 {
> >                         compatible = "renesas,r9a07g044-ssi",
> >                                      "renesas,rz-ssi";
> >                         reg = <0 0x10049c00 0 0x400>;
> >                         interrupts = <GIC_SPI 326 IRQ_TYPE_LEVEL_HIGH>,
> >                                      <GIC_SPI 327 IRQ_TYPE_EDGE_RISING>,
> >                                      <GIC_SPI 328 IRQ_TYPE_EDGE_RISING>;
> >                         interrupt-names = "int", "rx", "tx";
> >                         clocks = <&cpg CPG_MOD R9A07G044_CLK_SSI0>,
> >                                  <&audio_clk1>,
> >                                  <&audio_clk2>;
> >                         clock-names = "ssi", "audio_clk1", "audio_clk2";
> >                         resets = <&cpg R9A07G044_CLK_SSI0>;
> >                         dmas = <&dmac 0x255 0x10049c18
> CH_CFG(0x1,0x0,0x1,0x0,0x2,0x1,0x1,0x0)>,
> >                                <&dmac 0x256 0x10049c1c
> CH_CFG(0x0,0x0,0x1,0x0,0x2,0x1,0x1,0x0)>;
> >                         dma-names = "tx", "rx";
> >                         power-domains = <&cpg>;
> >                         #sound-dai-cells = <0>;
> >                         status = "disabled";
> >                 };
> >
> > Please let me know your thoughts on this.
> 
> How will this work with (existing) drivers?
> E.g. drivers/tty/serial/sh-sci.c:sci_request_dma_chan() already knows the
> source and destination addresses.
> The other CHCFG bits may be new, though.

OK will use only MID+RID for the next version and will drop CH_CFG Macro.
CH_CFG values can be supplied through DMA api's.

Regards,
Biju




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux