Hi Shawn,

On Thu, 2018-02-22 at 23:28 +0800, Shawn Lin wrote:


> > > Stack Trace:
> > >  arc_unwind_core.constprop.1+0xd0/0xf4
> > >  dump_stack+0x68/0x80
> > >  warn_slowpath_null+0x4e/0xec
> > >  sg_miter_next+0x28/0x20c
> > >  dw_mci_read_data_pio+0x44/0x190
> > >  dw_mmc f000a000.mmc: Unexpected interrupt latency
> I think we tested SD cards but the main reason we missed
> this is that we don't use pio mode since dw_mmc decides
> the transfer mode via HCON register but we don't have one
> platform at hand then to do that. Given the data-transfer-over
> interrupt should come after the data hit the RAM, so pio mode
> could probably consume more time than IDMAC.

That's really interesting.

I was under impression that we use internal DMA controller (AKA IDMAC)
on that platform (HSDK).

This is what we typically see in bootlog (this extract is taken from
dw_mmc f000a000.mmc: 'num-slots' was deprecated.
dw_mmc f000a000.mmc: IDMAC supports 32-bit address mode.
dw_mmc f000a000.mmc: Using internal DMA controller.
dw_mmc f000a000.mmc: Version ID is 290a
dw_mmc f000a000.mmc: DW MMC controller at irq 12,32 bit host data width,16 deep 

I'm not really sure how PIO mode (which stands for non-DMA mode) got used
given we have IDMAC in the hardware.

@ Evgeniy, could you please check why IDMAC is not used?


linux-snps-arc mailing list

Reply via email to