On 24/09/2019 04:41, Leo Li wrote:
-----Original Message-----
From: Ulf Hansson <ulf.hansson@xxxxxxxxxx>
Sent: Monday, September 23, 2019 4:27 PM
To: Russell King <rmk+kernel@xxxxxxxxxxxxxxx>
Cc: Robin Murphy <robin.murphy@xxxxxxx>; dann frazier
<dann.frazier@xxxxxxxxxxxxx>; Will Deacon <will.deacon@xxxxxxx>;
Nicolin Chen <nicoleotsuka@xxxxxxxxx>; Y.b. Lu <yangbo.lu@xxxxxxx>;
Christoph Hellwig <hch@xxxxxx>; Mark Rutland <mark.rutland@xxxxxxx>;
DTML <devicetree@xxxxxxxxxxxxxxx>; Leo Li <leoyang.li@xxxxxxx>; Rob
Herring <robh+dt@xxxxxxxxxx>; Shawn Guo <shawnguo@xxxxxxxxxx>; Linux
ARM <linux-arm-kernel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [PATCH 3/3] arm64: dts: mark lx2160a esdhc controllers dma
coherent
On Sun, 22 Sep 2019 at 12:29, Russell King <rmk+kernel@xxxxxxxxxxxxxxx>
wrote:
The LX2160A esdhc controllers are setup by the driver to be DMA
coherent, but without marking them as such in DT, Linux thinks they
are not. This can lead to random sporadic DMA errors, even to the
extent of preventing boot, such as:
mmc0: ADMA error
mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
mmc0: sdhci: Sys addr: 0x00000000 | Version: 0x00002202
mmc0: sdhci: Blk size: 0x00000008 | Blk cnt: 0x00000001
mmc0: sdhci: Argument: 0x00000000 | Trn mode: 0x00000013
mmc0: sdhci: Present: 0x01f50008 | Host ctl: 0x00000038
mmc0: sdhci: Power: 0x00000003 | Blk gap: 0x00000000
mmc0: sdhci: Wake-up: 0x00000000 | Clock: 0x000040d8
mmc0: sdhci: Timeout: 0x00000003 | Int stat: 0x00000001
mmc0: sdhci: Int enab: 0x037f108f | Sig enab: 0x037f108b
mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00002202
mmc0: sdhci: Caps: 0x35fa0000 | Caps_1: 0x0000af00
mmc0: sdhci: Cmd: 0x0000333a | Max curr: 0x00000000
mmc0: sdhci: Resp[0]: 0x00000920 | Resp[1]: 0x001d8a33
mmc0: sdhci: Resp[2]: 0x325b5900 | Resp[3]: 0x3f400e00
mmc0: sdhci: Host ctl2: 0x00000000
mmc0: sdhci: ADMA Err: 0x00000009 | ADMA Ptr: 0x000000236d43820c
mmc0: sdhci: ============================================
mmc0: error -5 whilst initialising SD card
These are caused by the device's descriptor fetch hitting
speculatively loaded CPU cache lines that the CPU does not see through
the normal, non-cacheable DMA coherent mapping that it uses for
non-coherent devices.
DT and the device must agree wrt whether the device is DMA coherent or
not.
Signed-off-by: Russell King <rmk+kernel@xxxxxxxxxxxxxxx>
As I am picking up patch1 and patch2 from this series, I can also help out and
pick up this one, if that is okay by people?
There is some concern recently from linux-next maintainer about this causing potential conflicts. https://lkml.org/lkml/2019/9/15/225
In principle, it should be fine for #2 and #3 to go via separate trees -
#3 aligns the DT with the existing behaviour of the driver, while #2
will make the driver behave correctly whichever state the DT is in.
Robin.
