Re: [PATCH 13/18] hw/riscv: microchip_pfsoc: Connect a DMA controller

["Philippe Mathieu-Daudé" <f4bug@amsat.org>]

On 8/16/20 10:57 AM, Bin Meng wrote:
> Hi Philippe,
> 
> On Sat, Aug 15, 2020 at 5:00 PM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
>>
>> On 8/14/20 6:40 PM, Bin Meng wrote:
>>> From: Bin Meng <bin.meng@windriver.com>
>>>
>>> Connect a DMA controller to Microchip PolarFire SoC. Note interrupt
>>> has not been connected due to missing information in the manual how
>>> interrupts are routed to PLIC.
>>>
>>> On the Icicle Kit board, the HSS firmware utilizes the on-chip DMA
>>> controller to move the 2nd stage bootloader in the system memory.
>>>
>>> Signed-off-by: Bin Meng <bin.meng@windriver.com>
>>> ---
>>>
>>>  hw/riscv/Kconfig                   |  1 +
>>>  hw/riscv/microchip_pfsoc.c         | 10 ++++++++++
>>>  include/hw/riscv/microchip_pfsoc.h |  3 +++
>>>  3 files changed, 14 insertions(+)
>>>
>>> diff --git a/hw/riscv/Kconfig b/hw/riscv/Kconfig
>>> index 7412db9..9323701 100644
>>> --- a/hw/riscv/Kconfig
>>> +++ b/hw/riscv/Kconfig
>>> @@ -55,4 +55,5 @@ config MICROCHIP_PFSOC
>>>      select SIFIVE
>>>      select UNIMP
>>>      select MCHP_PFSOC_MMUART
>>> +    select MCHP_PFSOC_DMA
>>>      select CADENCE_SDHCI
>>> diff --git a/hw/riscv/microchip_pfsoc.c b/hw/riscv/microchip_pfsoc.c
>>> index 7c09078..1c67cbc 100644
>>> --- a/hw/riscv/microchip_pfsoc.c
>>> +++ b/hw/riscv/microchip_pfsoc.c
>>> @@ -13,6 +13,7 @@
>>>   * 2) eNVM (Embedded Non-Volatile Memory)
>>>   * 3) MMUARTs (Multi-Mode UART)
>>>   * 4) Cadence eMMC/SDHC controller and an SD card connected to it
>>> + * 5) DMA (Direct Memory Access Controller)
>>>   *
>>>   * This board currently generates devicetree dynamically that indicates at least
>>>   * two harts and up to five harts.
>>> @@ -71,6 +72,7 @@ static const struct MemmapEntry {
>>>      [MICROCHIP_PFSOC_BUSERR_UNIT4] =    {  0x1704000,     0x1000 },
>>>      [MICROCHIP_PFSOC_CLINT] =           {  0x2000000,    0x10000 },
>>>      [MICROCHIP_PFSOC_L2CC] =            {  0x2010000,     0x1000 },
>>> +    [MICROCHIP_PFSOC_DMA] =             {  0x3000000,   0x100000 },
>>>      [MICROCHIP_PFSOC_L2LIM] =           {  0x8000000,  0x2000000 },
>>>      [MICROCHIP_PFSOC_PLIC] =            {  0xc000000,  0x4000000 },
>>>      [MICROCHIP_PFSOC_MMUART0] =         { 0x20000000,     0x1000 },
>>> @@ -114,6 +116,9 @@ static void microchip_pfsoc_soc_instance_init(Object *obj)
>>>                           TYPE_RISCV_CPU_SIFIVE_U54);
>>>      qdev_prop_set_uint64(DEVICE(&s->u_cpus), "resetvec", RESET_VECTOR);
>>>
>>> +    object_initialize_child(obj, "dma-controller", &s->dma,
>>> +                            TYPE_MCHP_PFSOC_DMA);
>>> +
>>>      object_initialize_child(obj, "sd-controller", &s->sdhci,
>>>                              TYPE_CADENCE_SDHCI);
>>
>> I haven't looked at the chip specs, but maybe you can add the SD
>> controller after the DMA controller so so you can directly link
>> a DMA address space to it.
>>
> 
> I am not sure I understand what you meant about adding the SD
> controller after the DMA controller. The Cadence SD controller has its
> own built-in DMA and does not depend on this DMA controller.

Ah OK. What I'm concerned about is the SD controller do its DMA
access in a proper DMA address space.

> 
> Regards,
> Bin
>