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