On Tue, Oct 15, 2019 at 03:12:49PM +0200, Christian Zigotzky wrote:
> Hello Russell,
>
> You asked me about "dma-coherent" in the Cyrus device tree. Unfortunately I
> don't find the property "dma-coherent" in the dtb source files.
>
> Output of "fdtdump cyrus_p5020_eth_poweroff.dtb | grep dma":
>
> dma0 = "/soc@ffe000000/dma@100300";
> dma1 = "/soc@ffe000000/dma@101300";
> dma@100300 {
> compatible = "fsl,eloplus-dma";
> dma-channel@0 {
> compatible = "fsl,eloplus-dma-channel";
> dma-channel@80 {
> compatible = "fsl,eloplus-dma-channel";
> dma-channel@100 {
> compatible = "fsl,eloplus-dma-channel";
> dma-channel@180 {
> compatible = "fsl,eloplus-dma-channel";
> dma@101300 {
> compatible = "fsl,eloplus-dma";
> dma-channel@0 {
> compatible = "fsl,eloplus-dma-channel";
> dma-channel@80 {
> compatible = "fsl,eloplus-dma-channel";
> dma-channel@100 {
> compatible = "fsl,eloplus-dma-channel";
> dma-channel@180 {
> compatible = "fsl,eloplus-dma-channel";
Hmm, so it looks like PowerPC doesn't mark devices that are dma
coherent with a property that describes them as such.
I think this opens a wider question - what should of_dma_is_coherent()
return for PowerPC? It seems right now that it returns false for
devices that are DMA coherent, which seems to me to be a recipe for
future mistakes.
Any ideas from the PPC maintainers?
>
> Thanks,
> Christian
>
>
> On 15 October 2019 at 2:51 pm, Russell King - ARM Linux admin wrote:
> > The patch which you are reverting fixes exactly the same error on
> > ARM64 boards.
> >
> > I had tried to get some additional information from you, but I never
> > received a response to my query.
> >
> > While it is regrettable that fixing that has caused a regression
> > for yours (which we need to fix) we really need to find a way to
> > solve this for both situations.
> >
> > Merely reverting the patch and then sitting on our hands with no
> > possible solution for ARM64 isn't really an acceptable way forward.
> >
> > The only solution I can see at the moment to this is to #ifdef in
> > the driver based on whether we are building for ARM64 or PowerPC.
> >
> > Maybe someone else can come up with a better idea?
> >
> > On Tue, Oct 15, 2019 at 02:27:44PM +0200, Christian Zigotzky wrote:
> > > Hello,
> > >
> > > We have patched the RC2 [1] and RC3 [2] of kernel 5.4 with the mmc3 patch
> > > [3] and after that the onboard SD card works without any problems with them.
> > >
> > > Could you please add this patch or do you have another solution?
> > >
> > > Thanks,
> > > Christian
> > >
> > > [1] http://www.xenosoft.de/linux-image-5.4-rc2-X1000_X5000_A1222.tar.gz
> > > [2] http://www.xenosoft.de/linux-image-5.4-rc3-X1000_X5000_A1222.tar.gz
> > > [3] http://www.xenosoft.de/mmc3.patch
> > >
> > >
> > > On 05 October 2019 at 00:45 am, Christian Zigotzky wrote:
> > > > Hello,
> > > >
> > > > The onboard SD card of the Cyrus+ PowerPC board (A-EON AmigaOne X5000)
> > > > [1] doesn't work anymore after the 'mmc-v5.4-2' updates [2].
> > > >
> > > > Error messages:
> > > >
> > > > [ 12.118148] mmc0: SDHCI controller on ffe114000.sdhc [ffe114000.sdhc]
> > > > using ADMA
> > > > [ 12.232869] mmc0: ADMA error: 0x02000000
> > > > [ 12.237977] mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
> > > > [ 12.243137] mmc0: sdhci: Sys addr: 0x00000000 | Version: 0x00001301
> > > > [ 12.248307] mmc0: sdhci: Blk size: 0x00000008 | Blk cnt: 0x00000001
> > > > [ 12.253448] mmc0: sdhci: Argument: 0x00000000 | Trn mode: 0x00000013
> > > > [ 12.258530] mmc0: sdhci: Present: 0x01fd020a | Host ctl: 0x00000030
> > > > [ 12.263572] mmc0: sdhci: Power: 0x00000002 | Blk gap: 0x00000000
> > > > [ 12.268574] mmc0: sdhci: Wake-up: 0x00000000 | Clock: 0x000020f8
> > > > [ 12.273535] mmc0: sdhci: Timeout: 0x00000003 | Int stat: 0x00000001
> > > > [ 12.278461] mmc0: sdhci: Int enab: 0x037f008f | Sig enab: 0x037f008b
> > > > [ 12.283339] mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00001301
> > > > [ 12.288198] mmc0: sdhci: Caps: 0x05fa0000 | Caps_1: 0x00000000
> > > > [ 12.293032] mmc0: sdhci: Cmd: 0x0000333a | Max curr: 0x00000000
> > > > [ 12.297861] mmc0: sdhci: Resp[0]: 0x00000920 | Resp[1]: 0x001dd533
> > > > [ 12.302615] mmc0: sdhci: Resp[2]: 0x325b5900 | Resp[3]: 0x3f400e00
> > > > [ 12.307312] mmc0: sdhci: Host ctl2: 0x00000000
> > > > [ 12.311940] mmc0: sdhci: ADMA Err: 0x00000009 | ADMA Ptr: 0x7e04f208
> > > > [ 12.316573] mmc0: sdhci: ============================================
> > > > [ 12.321204] mmc0: sdhci: 7e04f200: DMA 0xfc000000, LEN 0x0008,
> > > > Attr=0x23
> > > > [ 12.326022] mmc0: error -5 whilst initialising SD card
> > > > [ 12.507466] mmc0: invalid bus width
> > > > [ 12.512154] mmc0: error -22 whilst initialising SD card
> > > > [ 12.683457] mmc0: invalid bus width
> > > > [ 12.688968] mmc0: error -22 whilst initialising SD card
> > > > [ 12.774281] mmc0: invalid bus width
> > > > [ 12.779910] mmc0: error -22 whilst initialising SD card
> > > >
> > > > -------------------------
> > > >
> > > > I have found the issue in the DMA changes of the 'mmc-v5.4-2' updates.
> > > > It's the commit "121bd08b029e03404c451bb237729cdff76eafed (mmc:
> > > > sdhci-of-esdhc: set DMA snooping based on DMA coherence)" [3].
> > > >
> > > > Please find attached a patch. This patch solves the issue.
> > > >
> > > > dmesg output after compiling with the attached patch:
> > > >
> > > > [ 12.117149] mmc0: SDHCI controller on ffe114000.sdhc [ffe114000.sdhc]
> > > > using ADMA
> > > > [ 12.208646] mmc0: new high speed SDHC card at address 59b4
> > > > [ 12.230808] mmcblk0: mmc0:59b4 USD 3.73 GiB
> > > >
> > > > -------------------------
> > > >
> > > > Please check the commit "121bd08b029e03404c451bb237729cdff76eafed" [3].
> > > >
> > > > Thanks,
> > > > Christian
> > > >
> > > >
> > > > [1] https://www.amigaos.net/hardware/133/amigaone-x5000 and
> > > > http://wiki.amiga.org/index.php?title=X5000
> > > > [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.4-rc1&id=c710364f78afdef8c2ed07556d0743c5a30ed429
> > > > [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=121bd08b029e03404c451bb237729cdff76eafed
> > > >
> > >
>
>
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
