diff mbox

[v2,2/9] ARM: shmobile: r8a7790: add dma defines for sys and audio dmacs

Message ID 1397511312-4845-3-git-send-email-ben.dooks@codethink.co.uk (mailing list archive)
State Rejected
Delegated to: Vinod Koul
Headers show

Commit Message

Ben Dooks April 14, 2014, 9:35 p.m. UTC
Add the DMA resource IDs for the R8A7790 Audio and SYS DMA controllers
for use when specifying DMA handles.

Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
---
 include/dt-bindings/dma/r8a7790-dma.h | 228 ++++++++++++++++++++++++++++++++++
 1 file changed, 228 insertions(+)
 create mode 100644 include/dt-bindings/dma/r8a7790-dma.h

Comments

Arnd Bergmann April 14, 2014, 10:10 p.m. UTC | #1
On Monday 14 April 2014 22:35:05 Ben Dooks wrote:
> Add the DMA resource IDs for the R8A7790 Audio and SYS DMA controllers
> for use when specifying DMA handles.
> 
> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>

I really hate these lists in bindings:

> +#define R8A7790_DMA_SCIFA0_TX	(0x21)
> +#define R8A7790_DMA_SCIFA0_RX	(0x22)
> +#define R8A7790_DMA_SCIFA1_TX	(0x25)
> +#define R8A7790_DMA_SCIFA1_RX	(0x26)
> +#define R8A7790_DMA_SCIFA2_TX	(0x27)
> +#define R8A7790_DMA_SCIFA2_RX	(0x28)
> +
> +#define R8A7790_DMA_SCIFB0_TX	(0x3D)
> +#define R8A7790_DMA_SCIFB0_RX	(0x3E)
> +#define R8A7790_DMA_SCIFB1_TX	(0x19)
> +#define R8A7790_DMA_SCIFB1_RX	(0x1A)
> +#define R8A7790_DMA_SCIFB2_TX	(0x1D)
> +#define R8A7790_DMA_SCIFB2_RX	(0x1E)

These are all hardware constants, they should come from the data sheet and
get put into the dtsi file. The driver doesn't care what they are, and
the binding doesn't care, this only serves to make the binding less
generic.

> +#define CHCR_RX_32BIT	SHDMA_ARM_CHCR_RX(SHDMA_ARM_SZ_32BIT)
> +#define CHCR_TX_32BIT	SHDMA_ARM_CHCR_TX(SHDMA_ARM_SZ_32BIT)
> +#define CHCR_RX_256BIT	SHDMA_ARM_CHCR_RX(SHDMA_ARM_SZ_256BIT)
> +#define CHCR_TX_256BIT	SHDMA_ARM_CHCR_TX(SHDMA_ARM_SZ_256BIT)

For these, it's different: There is nothing wrong putting macros like
these into DT, because they will be the same across all SoCs.

However, as I mentioned in my reply to patch 8, I don't think that information
belongs into DT, and it should be in the device driver instead, because
that already knows the direction and transfer width and has to set it
through the slave config interface anyway.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe dmaengine" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Simon Horman April 14, 2014, 10:51 p.m. UTC | #2
On Tue, Apr 15, 2014 at 12:10:00AM +0200, Arnd Bergmann wrote:
> On Monday 14 April 2014 22:35:05 Ben Dooks wrote:
> > Add the DMA resource IDs for the R8A7790 Audio and SYS DMA controllers
> > for use when specifying DMA handles.
> > 
> > Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
> 
> I really hate these lists in bindings:
> 
> > +#define R8A7790_DMA_SCIFA0_TX	(0x21)
> > +#define R8A7790_DMA_SCIFA0_RX	(0x22)
> > +#define R8A7790_DMA_SCIFA1_TX	(0x25)
> > +#define R8A7790_DMA_SCIFA1_RX	(0x26)
> > +#define R8A7790_DMA_SCIFA2_TX	(0x27)
> > +#define R8A7790_DMA_SCIFA2_RX	(0x28)
> > +
> > +#define R8A7790_DMA_SCIFB0_TX	(0x3D)
> > +#define R8A7790_DMA_SCIFB0_RX	(0x3E)
> > +#define R8A7790_DMA_SCIFB1_TX	(0x19)
> > +#define R8A7790_DMA_SCIFB1_RX	(0x1A)
> > +#define R8A7790_DMA_SCIFB2_TX	(0x1D)
> > +#define R8A7790_DMA_SCIFB2_RX	(0x1E)
> 
> These are all hardware constants, they should come from the data sheet and
> get put into the dtsi file. The driver doesn't care what they are, and
> the binding doesn't care, this only serves to make the binding less
> generic.

They serve to make the dts file significantly more readable and
give some small level of compile-time checking to the dts file.

I am entirely in favour of them and its the direction that we
have been moving in for shmobile bindings.

> > +#define CHCR_RX_32BIT	SHDMA_ARM_CHCR_RX(SHDMA_ARM_SZ_32BIT)
> > +#define CHCR_TX_32BIT	SHDMA_ARM_CHCR_TX(SHDMA_ARM_SZ_32BIT)
> > +#define CHCR_RX_256BIT	SHDMA_ARM_CHCR_RX(SHDMA_ARM_SZ_256BIT)
> > +#define CHCR_TX_256BIT	SHDMA_ARM_CHCR_TX(SHDMA_ARM_SZ_256BIT)
> 
> For these, it's different: There is nothing wrong putting macros like
> these into DT, because they will be the same across all SoCs.
> 
> However, as I mentioned in my reply to patch 8, I don't think that information
> belongs into DT, and it should be in the device driver instead, because
> that already knows the direction and transfer width and has to set it
> through the slave config interface anyway.
> 
> 	Arnd
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
--
To unsubscribe from this list: send the line "unsubscribe dmaengine" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Ben Dooks April 15, 2014, 9:46 a.m. UTC | #3
On 14/04/14 23:51, Simon Horman wrote:
> On Tue, Apr 15, 2014 at 12:10:00AM +0200, Arnd Bergmann wrote:
>> On Monday 14 April 2014 22:35:05 Ben Dooks wrote:
>>> Add the DMA resource IDs for the R8A7790 Audio and SYS DMA controllers
>>> for use when specifying DMA handles.
>>>
>>> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
>>
>> I really hate these lists in bindings:
>>
>>> +#define R8A7790_DMA_SCIFA0_TX	(0x21)
>>> +#define R8A7790_DMA_SCIFA0_RX	(0x22)
>>> +#define R8A7790_DMA_SCIFA1_TX	(0x25)
>>> +#define R8A7790_DMA_SCIFA1_RX	(0x26)
>>> +#define R8A7790_DMA_SCIFA2_TX	(0x27)
>>> +#define R8A7790_DMA_SCIFA2_RX	(0x28)
>>> +
>>> +#define R8A7790_DMA_SCIFB0_TX	(0x3D)
>>> +#define R8A7790_DMA_SCIFB0_RX	(0x3E)
>>> +#define R8A7790_DMA_SCIFB1_TX	(0x19)
>>> +#define R8A7790_DMA_SCIFB1_RX	(0x1A)
>>> +#define R8A7790_DMA_SCIFB2_TX	(0x1D)
>>> +#define R8A7790_DMA_SCIFB2_RX	(0x1E)
>>
>> These are all hardware constants, they should come from the data sheet and
>> get put into the dtsi file. The driver doesn't care what they are, and
>> the binding doesn't care, this only serves to make the binding less
>> generic.
>
> They serve to make the dts file significantly more readable and
> give some small level of compile-time checking to the dts file.
>
> I am entirely in favour of them and its the direction that we
> have been moving in for shmobile bindings.

I don't really mind either way on these, when we had the
configuration for each slave in the dma-controller node
then having defines was very sensible.

>>> +#define CHCR_RX_32BIT	SHDMA_ARM_CHCR_RX(SHDMA_ARM_SZ_32BIT)
>>> +#define CHCR_TX_32BIT	SHDMA_ARM_CHCR_TX(SHDMA_ARM_SZ_32BIT)
>>> +#define CHCR_RX_256BIT	SHDMA_ARM_CHCR_RX(SHDMA_ARM_SZ_256BIT)
>>> +#define CHCR_TX_256BIT	SHDMA_ARM_CHCR_TX(SHDMA_ARM_SZ_256BIT)
>>
>> For these, it's different: There is nothing wrong putting macros like
>> these into DT, because they will be the same across all SoCs.
>>
>> However, as I mentioned in my reply to patch 8, I don't think that information
>> belongs into DT, and it should be in the device driver instead, because
>> that already knows the direction and transfer width and has to set it
>> through the slave config interface anyway.

There are a couple of issues here, firstly is that I have no idea if
any other SoCs have control bits that are not currently configurable
from the information supplied by a driver when it is bound.

The second is that the DMA for some peripherals do not match the size
of the registers, for example the SDHI blocks can do 256bit DMA to
what is specified to be a 32bit register.

I also prefer these to be in one place, to avoid the following

- Altering every $OS run on the system when you add a new dma peripheral
- Having to cross merge adding to DTS/DTSI and a driver for the same.
Geert Uytterhoeven May 13, 2014, 8:51 a.m. UTC | #4
On Mon, Apr 14, 2014 at 11:35 PM, Ben Dooks <ben.dooks@codethink.co.uk> wrote:
> --- /dev/null
> +++ b/include/dt-bindings/dma/r8a7790-dma.h
> @@ -0,0 +1,228 @@
> +/*
> + * R8A7790 System and Audio DMA channel resource identifiers
> + *
> + * Copyirght (c) 2014 Codethink Ltd.

Copyright.

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
--
To unsubscribe from this list: send the line "unsubscribe dmaengine" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Geert Uytterhoeven May 13, 2014, 10:46 a.m. UTC | #5
Hi Ben,

On Mon, Apr 14, 2014 at 11:35 PM, Ben Dooks <ben.dooks@codethink.co.uk> wrote:
> +*/
> +
> +/* System DMAC */

Missing include guards.

> +#define R8A7790_DMA_MSIOF0_TX  (0x81)
> +#define R8A7790_DMA_MSIOF0_RX  (0x82)
> +#define R8A7790_DMA_MSIOF1_TX  (0x85)
> +#define R8A7790_DMA_MSIOF1_RX  (0x86)

These are the only ones that se different for r8a7791 (0x51 etc.
compared to 0x81).
Wondering whether someone mixed up decimal and hexadecimal...

Are the System DMAC and Audio DMAC ID spaces separate
or unified? We also have in the audio section:

#define R8A7790_DMA_SSCI92_TX   (0x81)
#define R8A7790_DMA_SSCI92_RX   (0x82)
#define R8A7790_DMA_SCU0        (0x85)

> +#define R8A7790_DMA_IIC3_TX    (0x77)
> +#define R8A7790_DMA_IIC3_RX    (0x78)

In all other places, we call this "IICDVFS" instead of "IIC3".
The docs aren't always that consistent, though.

> +#define R8A7790_DMA_AXISTATR   (0xA6)
> +#define R8A7790_DMA_AXISTATS0  (0xAC)
> +#define R8A7790_DMA_AXISTATS1  (0xAA)
> +#define R8A7790_DMA_AXISTATS2  (0xA8)
> +#define R8A7790_DMA_AXISTATS3  (0xA4)

R8A7790_DMA_AXISTATS3C, to match the docs?

> +#define R8A7790_DMA_MMCIF0_TX  (0xD1)
> +#define R8A7790_DMA_MMCIF0_RX  (0xD2)
> +#define R8A7790_DMA_MMCIF1_TX  (0xE1)
> +#define R8A7790_DMA_MMCIF1_RX  (0xE2)

AXSTM is missing at the end:

#define R8A7790_DMA_AXSTM      (0xAE)

> +#define R8A7790_DMA_SSCI20_TX  (0x63)
> +#define R8A7790_DMA_SSCI20_RX  (0x64)
> +#define R8A7790_DMA_SSCI21_TX  (0x67)
> +#define R8A7790_DMA_SSCI21_RX  (0x68)
> +#define R8A7790_DMA_SSCI22_TX  (0x6B)
> +#define R8A7790_DMA_SSCI22_RX  (0x6C)
> +#define R8A7790_DMA_SSCI23_TX  (0x6D)
> +#define R8A7790_DMA_SSCI23_RX  (0x6E)
> +
> +#define R8A7790_DMA_SSCI20_TX  (0x63)
> +#define R8A7790_DMA_SSCI20_RX  (0x64)
> +#define R8A7790_DMA_SSCI21_TX  (0x67)
> +#define R8A7790_DMA_SSCI21_RX  (0x68)
> +#define R8A7790_DMA_SSCI22_TX  (0x6B)
> +#define R8A7790_DMA_SSCI22_RX  (0x6C)
> +#define R8A7790_DMA_SSCI23_TX  (0x6D)
> +#define R8A7790_DMA_SSCI23_RX  (0x6E)

This section is duplicated.

> +#define CHCR_RX_32BIT  SHDMA_ARM_CHCR_RX(SHDMA_ARM_SZ_32BIT)
> +#define CHCR_TX_32BIT  SHDMA_ARM_CHCR_TX(SHDMA_ARM_SZ_32BIT)
> +#define CHCR_RX_256BIT SHDMA_ARM_CHCR_RX(SHDMA_ARM_SZ_256BIT)
> +#define CHCR_TX_256BIT SHDMA_ARM_CHCR_TX(SHDMA_ARM_SZ_256BIT)

From my (still-limited) understanding of the shdma driver, these look like
pure register values, not descriptions of the hardware?

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
--
To unsubscribe from this list: send the line "unsubscribe dmaengine" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Geert Uytterhoeven May 27, 2014, 8:08 a.m. UTC | #6
Hi Ben,

On Tue, May 13, 2014 at 12:46 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
>> +#define R8A7790_DMA_MSIOF0_TX  (0x81)
>> +#define R8A7790_DMA_MSIOF0_RX  (0x82)
>> +#define R8A7790_DMA_MSIOF1_TX  (0x85)
>> +#define R8A7790_DMA_MSIOF1_RX  (0x86)
>
> These are the only ones that se different for r8a7791 (0x51 etc.
> compared to 0x81).
> Wondering whether someone mixed up decimal and hexadecimal...

Confirmed. They should be 0x51, 0x52, 0x55, 0x56.

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
--
To unsubscribe from this list: send the line "unsubscribe dmaengine" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/include/dt-bindings/dma/r8a7790-dma.h b/include/dt-bindings/dma/r8a7790-dma.h
new file mode 100644
index 0000000..732422a
--- /dev/null
+++ b/include/dt-bindings/dma/r8a7790-dma.h
@@ -0,0 +1,228 @@ 
+/*
+ * R8A7790 System and Audio DMA channel resource identifiers
+ *
+ * Copyirght (c) 2014 Codethink Ltd.
+ *	Ben Dooks <ben.dooks@codethink.co.uk>
+ *
+ * Licensed under GPLv2
+*/
+
+/* System DMAC */
+
+#define R8A7790_DMA_SCIFA0_TX	(0x21)
+#define R8A7790_DMA_SCIFA0_RX	(0x22)
+#define R8A7790_DMA_SCIFA1_TX	(0x25)
+#define R8A7790_DMA_SCIFA1_RX	(0x26)
+#define R8A7790_DMA_SCIFA2_TX	(0x27)
+#define R8A7790_DMA_SCIFA2_RX	(0x28)
+
+#define R8A7790_DMA_SCIFB0_TX	(0x3D)
+#define R8A7790_DMA_SCIFB0_RX	(0x3E)
+#define R8A7790_DMA_SCIFB1_TX	(0x19)
+#define R8A7790_DMA_SCIFB1_RX	(0x1A)
+#define R8A7790_DMA_SCIFB2_TX	(0x1D)
+#define R8A7790_DMA_SCIFB2_RX	(0x1E)
+
+#define R8A7790_DMA_HSCIF0_TX	(0x39)
+#define R8A7790_DMA_HSCIF0_RX	(0x3A)
+#define R8A7790_DMA_HSCIF1_TX	(0x4D)
+#define R8A7790_DMA_HSCIF1_RX	(0x4E)
+
+#define R8A7790_DMA_SCIF0_TX	(0x29)
+#define R8A7790_DMA_SCIF0_RX	(0x2A)
+#define R8A7790_DMA_SCIF1_TX	(0x2D)
+#define R8A7790_DMA_SCIF1_RX	(0x2E)
+
+#define R8A7790_DMA_MSIOF0_TX	(0x81)
+#define R8A7790_DMA_MSIOF0_RX	(0x82)
+#define R8A7790_DMA_MSIOF1_TX	(0x85)
+#define R8A7790_DMA_MSIOF1_RX	(0x86)
+#define R8A7790_DMA_MSIOF2_TX	(0x41)
+#define R8A7790_DMA_MSIOF2_RX	(0x42)
+#define R8A7790_DMA_MSIOF3_TX	(0x45)
+#define R8A7790_DMA_MSIOF3_RX	(0x46)
+
+#define R8A7790_DMA_QSPI_TX	(0x17)
+#define R8A7790_DMA_QSPI_RX	(0x18)
+
+#define R8A7790_DMA_SIM_TX	(0xA1)
+#define R8A7790_DMA_SIM_RX	(0xA2)
+
+#define R8A7790_DMA_IIC0_TX	(0x61)
+#define R8A7790_DMA_IIC0_RX	(0x62)
+#define R8A7790_DMA_IIC1_TX	(0x65)
+#define R8A7790_DMA_IIC1_RX	(0x66)
+#define R8A7790_DMA_IIC2_TX	(0x69)
+#define R8A7790_DMA_IIC2_RX	(0x6A)
+#define R8A7790_DMA_IIC3_TX	(0x77)
+#define R8A7790_DMA_IIC3_RX	(0x78)
+
+#define R8A7790_DMA_SDHI0_TX	(0xCD)
+#define R8A7790_DMA_SDHI0_RX	(0xCE)
+#define R8A7790_DMA_SDHI1_TX	(0xC9)
+#define R8A7790_DMA_SDHI1_RX	(0xCA)
+#define R8A7790_DMA_SDHI2_TX	(0xC1)
+#define R8A7790_DMA_SDHI2_RX	(0xC2)
+#define R8A7790_DMA_SDHI2C2_TX	(0xC5)
+#define R8A7790_DMA_SDHI2C2_RX	(0xC6)
+#define R8A7790_DMA_SDHI3_TX	(0xD3)
+#define R8A7790_DMA_SDHI3_RX	(0xD4)
+#define R8A7790_DMA_SDHI3C2_TX	(0xDF)
+#define R8A7790_DMA_SDHI3C2_RX	(0xDE)
+
+#define R8A7790_DMA_TPU0	(0xF1)
+#define R8A7790_DMA_TSIF0	(0xEA)
+#define R8A7790_DMA_TSIF1	(0xF0)
+
+#define R8A7790_DMA_AXISTATR	(0xA6)
+#define R8A7790_DMA_AXISTATS0	(0xAC)
+#define R8A7790_DMA_AXISTATS1	(0xAA)
+#define R8A7790_DMA_AXISTATS2	(0xA8)
+#define R8A7790_DMA_AXISTATS3	(0xA4)
+
+#define R8A7790_DMA_MMCIF0_TX	(0xD1)
+#define R8A7790_DMA_MMCIF0_RX	(0xD2)
+#define R8A7790_DMA_MMCIF1_TX	(0xE1)
+#define R8A7790_DMA_MMCIF1_RX	(0xE2)
+
+/* Audio DMAC */
+
+#define R8A7790_DMA_DTCPC0_TX	(0xD7)
+#define R8A7790_DMA_DTCPC0_RX	(0xD8)
+#define R8A7790_DMA_DTCPC1_TX	(0xD9)
+#define R8A7790_DMA_DTCPC1_RX	(0xDA)
+#define R8A7790_DMA_DTCPP0_TX	(0xBF)
+#define R8A7790_DMA_DTCPP0_RX	(0xC0)
+#define R8A7790_DMA_DTCPP1_TX	(0xD5)
+#define R8A7790_DMA_DTCPP1_RX	(0xD6)
+
+#define R8A7790_DMA_MLM0_TX	(0xDB)
+#define R8A7790_DMA_MLM0_RX	(0xDC)
+#define R8A7790_DMA_MLM1_TX	(0xE3)
+#define R8A7790_DMA_MLM1_RX	(0xE4)
+#define R8A7790_DMA_MLM2_TX	(0xE5)
+#define R8A7790_DMA_MLM2_RX	(0xE6)
+#define R8A7790_DMA_MLM3_TX	(0xE7)
+#define R8A7790_DMA_MLM3_RX	(0xE8)
+#define R8A7790_DMA_MLM4_TX	(0xF3)
+#define R8A7790_DMA_MLM4_RX	(0xF4)
+#define R8A7790_DMA_MLM5_TX	(0xF5)
+#define R8A7790_DMA_MLM5_RX	(0xF6)
+#define R8A7790_DMA_MLM6_TX	(0xF7)
+#define R8A7790_DMA_MLM6_RX	(0xF8)
+#define R8A7790_DMA_MLM7_TX	(0xF9)
+#define R8A7790_DMA_MLM7_RX	(0xFA)
+
+#define R8A7790_DMA_SCU0	(0x85)
+#define R8A7790_DMA_SCU1	(0x87)
+#define R8A7790_DMA_SCU2	(0x89)
+#define R8A7790_DMA_SCU3	(0x8B)
+#define R8A7790_DMA_SCU4	(0x8D)
+#define R8A7790_DMA_SCU5	(0x8F)
+#define R8A7790_DMA_SCU6	(0x91)
+#define R8A7790_DMA_SCU7	(0x93)
+#define R8A7790_DMA_SCU8	(0x95)
+#define R8A7790_DMA_SCU9	(0x97)
+
+#define R8A7790_DMA_SCUCMD0	(0xBC)
+#define R8A7790_DMA_SCUCMD1	(0xBE)
+
+#define R8A7790_DMA_SCUOUT0	(0x9A)
+#define R8A7790_DMA_SCUOUT1	(0x9C)
+#define R8A7790_DMA_SCUOUT2	(0x9E)
+#define R8A7790_DMA_SCUOUT3	(0xA0)
+#define R8A7790_DMA_SCUOUT4	(0xB0)
+#define R8A7790_DMA_SCUOUT5	(0xB2)
+#define R8A7790_DMA_SCUOUT6	(0xB4)
+#define R8A7790_DMA_SCUOUT7	(0xB6)
+#define R8A7790_DMA_SCUOUT8	(0xB8)
+#define R8A7790_DMA_SCUOUT9	(0xBA)
+
+#define R8A7790_DMA_SSCI00_TX	(0x15)
+#define R8A7790_DMA_SSCI00_RX	(0x16)
+#define R8A7790_DMA_SSCI01_TX	(0x35)
+#define R8A7790_DMA_SSCI01_RX	(0x36)
+#define R8A7790_DMA_SSCI02_TX	(0x37)
+#define R8A7790_DMA_SSCI02_RX	(0x38)
+#define R8A7790_DMA_SSCI03_TX	(0x47)
+#define R8A7790_DMA_SSCI03_RX	(0x48)
+
+#define R8A7790_DMA_SSCI10_TX	(0x49)
+#define R8A7790_DMA_SSCI10_RX	(0x4A)
+#define R8A7790_DMA_SSCI11_TX	(0x4B)
+#define R8A7790_DMA_SSCI11_RX	(0x4C)
+#define R8A7790_DMA_SSCI12_TX	(0x57)
+#define R8A7790_DMA_SSCI12_RX	(0x58)
+#define R8A7790_DMA_SSCI13_TX	(0x59)
+#define R8A7790_DMA_SSCI13_RX	(0x5A)
+
+#define R8A7790_DMA_SSCI20_TX	(0x63)
+#define R8A7790_DMA_SSCI20_RX	(0x64)
+#define R8A7790_DMA_SSCI21_TX	(0x67)
+#define R8A7790_DMA_SSCI21_RX	(0x68)
+#define R8A7790_DMA_SSCI22_TX	(0x6B)
+#define R8A7790_DMA_SSCI22_RX	(0x6C)
+#define R8A7790_DMA_SSCI23_TX	(0x6D)
+#define R8A7790_DMA_SSCI23_RX	(0x6E)
+
+#define R8A7790_DMA_SSCI20_TX	(0x63)
+#define R8A7790_DMA_SSCI20_RX	(0x64)
+#define R8A7790_DMA_SSCI21_TX	(0x67)
+#define R8A7790_DMA_SSCI21_RX	(0x68)
+#define R8A7790_DMA_SSCI22_TX	(0x6B)
+#define R8A7790_DMA_SSCI22_RX	(0x6C)
+#define R8A7790_DMA_SSCI23_TX	(0x6D)
+#define R8A7790_DMA_SSCI23_RX	(0x6E)
+
+#define R8A7790_DMA_SSCI3_TX	(0x6F)
+#define R8A7790_DMA_SSCI3_RX	(0x70)
+
+#define R8A7790_DMA_SSCI4_TX	(0x71)
+#define R8A7790_DMA_SSCI4_RX	(0x72)
+
+#define R8A7790_DMA_SSCI5_TX	(0x73)
+#define R8A7790_DMA_SSCI5_RX	(0x74)
+
+#define R8A7790_DMA_SSCI6_TX	(0x75)
+#define R8A7790_DMA_SSCI6_RX	(0x76)
+
+#define R8A7790_DMA_SSCI7_TX	(0x79)
+#define R8A7790_DMA_SSCI7_RX	(0x7A)
+
+#define R8A7790_DMA_SSCI8_TX	(0x7B)
+#define R8A7790_DMA_SSCI8_RX	(0x7C)
+
+#define R8A7790_DMA_SSCI90_TX	(0x7D)
+#define R8A7790_DMA_SSCI90_RX	(0x7E)
+#define R8A7790_DMA_SSCI91_TX	(0x7F)
+#define R8A7790_DMA_SSCI91_RX	(0x80)
+#define R8A7790_DMA_SSCI92_TX	(0x81)
+#define R8A7790_DMA_SSCI92_RX	(0x82)
+#define R8A7790_DMA_SSCI93_TX	(0x83)
+#define R8A7790_DMA_SSCI93_RX	(0x84)
+
+#define R8A7790_DMA_SSIND0_TX	(0x01)
+#define R8A7790_DMA_SSIND0_RX	(0x02)
+#define R8A7790_DMA_SSIND1_TX	(0x03)
+#define R8A7790_DMA_SSIND1_RX	(0x04)
+#define R8A7790_DMA_SSIND2_TX	(0x05)
+#define R8A7790_DMA_SSIND2_RX	(0x06)
+#define R8A7790_DMA_SSIND3_TX	(0x07)
+#define R8A7790_DMA_SSIND3_RX	(0x08)
+#define R8A7790_DMA_SSIND4_TX	(0x09)
+#define R8A7790_DMA_SSIND4_RX	(0x0A)
+#define R8A7790_DMA_SSIND5_TX	(0x0B)
+#define R8A7790_DMA_SSIND5_RX	(0x0C)
+#define R8A7790_DMA_SSIND6_TX	(0x0D)
+#define R8A7790_DMA_SSIND6_RX	(0x0E)
+#define R8A7790_DMA_SSIND7_TX	(0x0F)
+#define R8A7790_DMA_SSIND7_RX	(0x10)
+#define R8A7790_DMA_SSIND8_TX	(0x11)
+#define R8A7790_DMA_SSIND8_RX	(0x12)
+#define R8A7790_DMA_SSIND9_TX	(0x13)
+#define R8A7790_DMA_SSIND9_RX	(0x14)
+
+#define CHCR_RX_32BIT	SHDMA_ARM_CHCR_RX(SHDMA_ARM_SZ_32BIT)
+#define CHCR_TX_32BIT	SHDMA_ARM_CHCR_TX(SHDMA_ARM_SZ_32BIT)
+#define CHCR_RX_256BIT	SHDMA_ARM_CHCR_RX(SHDMA_ARM_SZ_256BIT)
+#define CHCR_TX_256BIT	SHDMA_ARM_CHCR_TX(SHDMA_ARM_SZ_256BIT)