linux-kernel - Re: pl330 dma failure

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150602130824.GU3140@localhost>
Date:	Tue, 2 Jun 2015 18:38:24 +0530
From:	Vinod Koul <vinod.koul@...el.com>
To:	Michal Suchanek <hramrach@...il.com>,
	Robert Baldyga <r.baldyga@...sung.com>
Cc:	dmaengine@...r.kernel.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-exynos <Linux-exynos@...ux-exynos.org>
Subject: Re: pl330 dma failure

On Sat, May 30, 2015 at 09:37:07PM +0200, Michal Suchanek wrote:
> Hello,
> 
> I was trying to read the SPI NOR flash and found that the pl330
> controller dma mysteriously fails.

Adding Robert,

> 
> There is the problem that the 256 bytes of dma program buffer does not
> suffice for the whole of 4M of the flash memory so all of it cannot be
> possibly transferred in one go with the pl330 driver as is now.
> 
> However, the practical limit is much smaller. At 1MHz or 40MHz the
> maximum transfer size that ever finishes is 64k. At 133MHz which is
> the rated flash memory clock the maximum transfer size that finishes
> is 128 bytes (only tried power of 2).
> 
> There is no obvious issue with the DMA program. 128k happens to be the
> smallest size that requires that the burst instruction is repeated in
> the cycle and also happens to be the smallest size that fails for any
> speed I tried.
> 
> Is there some obvious fix or should I just give up on transferring
> more than 64k and make the driver truncate any larger transfers?
Well dma controllers cannot transfer any size, the controllers do have
limitation on maximum transfer per block. So to transfer more data you need
to create descriptor with multiple segments (or driver should split that but
not done usually) and worst case multiple transfers

-- 
~Vinod

> 
> Thanks
> 
> Michal
> 
> [   60.726638] m25p80 spi1.0: from 0x00000000, len 65536
> [   60.726724] s3c64xx_spi_transfer_one 12d30000.spi spi1 spi1.0 xfer
> bpw 8 speed 40000000
> [   60.726730] s3c64xx_spi_transfer_one 12d30000.spi spi1 spi1.0 not using dma
> [   60.726745] s3c64xx_spi_transfer_one 12d30000.spi spi1 spi1.0 xfer
> bpw 8 speed 40000000
> [   60.726749] s3c64xx_spi_transfer_one 12d30000.spi spi1 spi1.0 using dma
> [   60.726759] bc041000:    DMAMOV CCR 0x804200
> [   60.726765] bc041006:    DMAMOV SAR 0x12d3001c
> [   60.726770] bc04100c:    DMAMOV DAR 0x68010000
> [   60.726776] bc041012:    DMALP_0 255
> [   60.726782] bc041014:    DMALP_1 255
> [   60.726787] bc041016:    DMAWFPS 4
> [   60.726792] bc041018:    DMALDPS 4
> [   60.726797] bc04101a:    DMASTA
> [   60.726802] bc04101b:    DMAFLUSHP 4
> [   60.726808] bc04101d:    DMALPENDA_1 bjmpto_7
> [   60.726813] bc04101f:    DMALPENDA_0 bjmpto_b
> [   60.726819] bc041021:    DMASEV 0
> [   60.726824] bc041023:    DMAEND
> [   60.726836] wait_for_dma 12d30000.spi spi1 (null) waiting for 46ms
> transferring 65536bytes@...00000Hz
> [   60.765700] wait_for_dma 12d30000.spi spi1 (null) waited 40 ms
> [   60.780206] m25p80 spi1.0: from 0x00000000, len 131072
> [   60.780291] s3c64xx_spi_transfer_one 12d30000.spi spi1 spi1.0 xfer
> bpw 8 speed 40000000
> [   60.780297] s3c64xx_spi_transfer_one 12d30000.spi spi1 spi1.0 not using dma
> [   60.780312] s3c64xx_spi_transfer_one 12d30000.spi spi1 spi1.0 xfer
> bpw 8 speed 40000000
> [   60.780316] s3c64xx_spi_transfer_one 12d30000.spi spi1 spi1.0 using dma
> [   60.780327] bc041000:    DMAMOV CCR 0x804200
> [   60.780333] bc041006:    DMAMOV SAR 0x12d3001c
> [   60.780338] bc04100c:    DMAMOV DAR 0x68020000
> [   60.780344] bc041012:    DMALP_0 255
> [   60.780349] bc041014:    DMALP_1 255
> [   60.780355] bc041016:    DMAWFPS 4
> [   60.780360] bc041018:    DMALDPS 4
> [   60.780365] bc04101a:    DMASTA
> [   60.780370] bc04101b:    DMAFLUSHP 4
> [   60.780375] bc04101d:    DMAWFPS 4
> [   60.780380] bc04101f:    DMALDPS 4
> [   60.780385] bc041021:    DMASTA
> [   60.780390] bc041022:    DMAFLUSHP 4
> [   60.780395] bc041024:    DMALPENDA_1 bjmpto_e
> [   60.780401] bc041026:    DMALPENDA_0 bjmpto_12
> [   60.780406] bc041028:    DMASEV 0
> [   60.780411] bc04102a:    DMAEND
> [   60.780423] wait_for_dma 12d30000.spi spi1 (null) waiting for 72ms
> transferring 131072bytes@...00000Hz
> [   60.903505] wait_for_dma 12d30000.spi spi1 (null) waited 125 ms
> [   60.903518] m25p80 spi1.0: I/O Error: rx-1 tx-0 res:rx-f tx-p len-131072
> [   60.903530] m25p80 spi1.0: SPI transfer failed: -5
> [   60.903590] spi_master spi1: failed to transfer one message from queue
> --
> To unsubscribe from this list: send the line "unsubscribe dmaengine" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/