Re: [PATCH v2] mmc: dw_mmc: Fix the DTO timeout overflow calculation for 32-bit systems

[Alexey Brodkin <Alexey.Brodkin@synopsys.com>]

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