Am 07.06.2016 um 10:10 schrieb Michal Suchanek: > On 7 June 2016 at 08:03, Heiner Kallweit <hkallweit1@xxxxxxxxx> wrote: >> Am 07.06.2016 um 01:07 schrieb Mark Brown: >>> On Mon, Jun 06, 2016 at 08:53:10PM +0200, Heiner Kallweit wrote: >>>> Am 06.06.2016 um 19:40 schrieb Mark Brown: > >>>> Well, we could reduce the max_transfer_size exposed by the driver by >>>> the max length of a m25p80 read command in general. >>> >>> No! Apart from anything else this would be a complete and total >>> abstraction failure. This is a driver for a SPI controller, not a >>> driver for a flash controller, which means that it should not have flash >>> specific hacks in it. >>> >>>> Then we might be too strict for other SPI devices, but this may >>>> be acceptable as the current fsl-espi driver is usable with SPI NOR >>>> devices only anyway. >>> >>> What makes you say this? I'm guessing that the driver is just broken >>> but it would be good to understand the specifics. >>> >> See fsl_espi_rw_trans(): >> In case of transfers > SPCOM_TRANLEN_MAX it loops and reads in >> SPCOM_TRANLEN_MAX chunks whilst replacing bytes 2-4 of the >> message buffer with the new start address to read from. > > That's obviously bogus. Just reject anything too large and let the > upper layer deal with it. > So far the upper layer wasn't able to deal with it. Now, with the recent change set initiated by you, we can clean up the driver a little. This was also the motivation to involve myself in getting this upper layer functionality into the mtd code. > Given m25p80 and fbtft would handle this can you use DMA to gather > buffers from multiple transfers (ie command and data) or does the > buffer have to be copied together for the transfer? > The fsl-espi controller doesn't support DMA. The driver copies all transfers to a local buffer. There's just one nice feature of this controller: It supports a flash-read-optimized transfer mode, where you can configure: - first write x bytes - then read y bytes in either single or dual mode In tests with a modified driver the dual mode worked quite well. But that's something for a future extension. > Thanks > > Michal > -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html