Hi Shawn,
On Thu, 2018-02-22 at 23:28 +0800, Shawn Lin wrote:
[snip]
> > > 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
4.15-r9):
--------------------------------->8--------------------------------
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 fifo
--------------------------------->8--------------------------------
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?
-Alexey
��.n��������+%������w��{.n�����{��i��)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
