From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: [PATCH v3 1/5] spi: introduce mmap read support for spi flash devices To: "R, Vignesh" , Brian Norris References: <1447133399-25658-1-git-send-email-vigneshr@ti.com> <1447133399-25658-2-git-send-email-vigneshr@ti.com> <20151110232341.GU12143@google.com> <5642E546.3040806@ti.com> CC: Michal Suchanek , Russell King , , Tony Lindgren , , , Mark Brown , , , From: Mike Looijmans Message-ID: <5645EE7F.5040101@topic.nl> Date: Fri, 13 Nov 2015 15:06:55 +0100 MIME-Version: 1.0 In-Reply-To: <5642E546.3040806@ti.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , =EF=BB=BFOn 11-11-15 07:50, R, Vignesh wrote: > Hi Brain, > > On 11/11/2015 4:53 AM, Brian Norris wrote: >> Hi Vignesh, ... >> Also, this API doesn't actually have anything to do with memory mapping. >> It has to do with the de facto standard flash protocol. So I don't think >> mmap belongs in the name; it should be something about flash. (I know of >> at least one other controller that could probably use this API, excpet >> it doesn't use memory mapping to accomplish the accelerated flash read.) The Zynq has a similar way of accessing QSPI flash through a memory map. Th= e=20 memory window is only 16MB, so some form of paging would be needed. It's why I have been following this thread with great interest, since the Q= SPI=20 performance on the Zynq is way below what it could potentially be. > As far as TI QSPI controller is concerned, the accelerated read happens > via mmap port whereby a predefined memory address space of SoC is > exposed as QSPI mmap region. This region can be accessed like normal > RAM(via memcpy()) and the QSPI controller interface takes care of > fetching data from flash on SPI bus automatically hence, I named it as > above. But, I have no hard feelings if it needs to be generalized to > spi_mtd_read() or something else. I know that on the Zynq, you can even let the DMA controller access the QSP= I=20 flash via this memory mapping. The QSPI controller itself doesn't support a= ny=20 DMA at all. If something similar applies to the TI platform (most of the TI procs have= =20 nice DMA controllers) one could go one step further and implement a generic= =20 DMA-through-mmap access to QSPI flash. Mike. Kind regards, Mike Looijmans System Expert TOPIC Embedded Products Eindhovenseweg 32-C, NL-5683 KH Best Postbus 440, NL-5680 AK Best Telefoon: +31 (0) 499 33 69 79 Telefax: +31 (0) 499 33 69 70 E-mail: mike.looijmans@topicproducts.com Website: www.topicproducts.com Please consider the environment before printing this e-mail Visit us at : Aerospace Electrical Systems Expo Europe which will be held f= rom 17.11.2015 till 19.11.2015, Findorffstrasse 101 Bremen, Germany, Hall 5= , stand number C65 http://www.aesexpo.eu From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Looijmans Subject: Re: [PATCH v3 1/5] spi: introduce mmap read support for spi flash devices Date: Fri, 13 Nov 2015 15:06:55 +0100 Message-ID: <5645EE7F.5040101@topic.nl> References: <1447133399-25658-1-git-send-email-vigneshr@ti.com> <1447133399-25658-2-git-send-email-vigneshr@ti.com> <20151110232341.GU12143@google.com> <5642E546.3040806@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; Format="flowed" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <5642E546.3040806@ti.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: "R, Vignesh" , Brian Norris Cc: devicetree@vger.kernel.org, Michal Suchanek , Russell King , Tony Lindgren , linux-kernel@vger.kernel.org, linux-spi@vger.kernel.org, Mark Brown , linux-mtd@lists.infradead.org, linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org List-Id: linux-omap@vger.kernel.org 77u/T24gMTEtMTEtMTUgMDc6NTAsIFIsIFZpZ25lc2ggd3JvdGU6Cj4gSGkgQnJhaW4sCj4KPiBP biAxMS8xMS8yMDE1IDQ6NTMgQU0sIEJyaWFuIE5vcnJpcyB3cm90ZToKPj4gSGkgVmlnbmVzaCwK Li4uCgo+PiBBbHNvLCB0aGlzIEFQSSBkb2Vzbid0IGFjdHVhbGx5IGhhdmUgYW55dGhpbmcgdG8g ZG8gd2l0aCBtZW1vcnkgbWFwcGluZy4KPj4gSXQgaGFzIHRvIGRvIHdpdGggdGhlIGRlIGZhY3Rv IHN0YW5kYXJkIGZsYXNoIHByb3RvY29sLiBTbyBJIGRvbid0IHRoaW5rCj4+IG1tYXAgYmVsb25n cyBpbiB0aGUgbmFtZTsgaXQgc2hvdWxkIGJlIHNvbWV0aGluZyBhYm91dCBmbGFzaC4gKEkga25v dyBvZgo+PiBhdCBsZWFzdCBvbmUgb3RoZXIgY29udHJvbGxlciB0aGF0IGNvdWxkIHByb2JhYmx5 IHVzZSB0aGlzIEFQSSwgZXhjcGV0Cj4+IGl0IGRvZXNuJ3QgdXNlIG1lbW9yeSBtYXBwaW5nIHRv IGFjY29tcGxpc2ggdGhlIGFjY2VsZXJhdGVkIGZsYXNoIHJlYWQuKQoKVGhlIFp5bnEgaGFzIGEg c2ltaWxhciB3YXkgb2YgYWNjZXNzaW5nIFFTUEkgZmxhc2ggdGhyb3VnaCBhIG1lbW9yeSBtYXAu IFRoZSAKbWVtb3J5IHdpbmRvdyBpcyBvbmx5IDE2TUIsIHNvIHNvbWUgZm9ybSBvZiBwYWdpbmcg d291bGQgYmUgbmVlZGVkLgoKSXQncyB3aHkgSSBoYXZlIGJlZW4gZm9sbG93aW5nIHRoaXMgdGhy ZWFkIHdpdGggZ3JlYXQgaW50ZXJlc3QsIHNpbmNlIHRoZSBRU1BJIApwZXJmb3JtYW5jZSBvbiB0 aGUgWnlucSBpcyB3YXkgYmVsb3cgd2hhdCBpdCBjb3VsZCBwb3RlbnRpYWxseSBiZS4KCj4gQXMg ZmFyIGFzIFRJIFFTUEkgY29udHJvbGxlciBpcyBjb25jZXJuZWQsIHRoZSBhY2NlbGVyYXRlZCBy ZWFkIGhhcHBlbnMKPiB2aWEgbW1hcCBwb3J0IHdoZXJlYnkgYSBwcmVkZWZpbmVkIG1lbW9yeSBh ZGRyZXNzIHNwYWNlIG9mIFNvQyBpcwo+IGV4cG9zZWQgYXMgUVNQSSBtbWFwIHJlZ2lvbi4gVGhp cyByZWdpb24gY2FuIGJlIGFjY2Vzc2VkIGxpa2Ugbm9ybWFsCj4gUkFNKHZpYSBtZW1jcHkoKSkg YW5kIHRoZSBRU1BJIGNvbnRyb2xsZXIgaW50ZXJmYWNlIHRha2VzIGNhcmUgb2YKPiBmZXRjaGlu ZyBkYXRhIGZyb20gZmxhc2ggb24gU1BJIGJ1cyBhdXRvbWF0aWNhbGx5IGhlbmNlLCBJIG5hbWVk IGl0IGFzCj4gYWJvdmUuIEJ1dCwgSSBoYXZlIG5vIGhhcmQgZmVlbGluZ3MgaWYgaXQgbmVlZHMg dG8gYmUgZ2VuZXJhbGl6ZWQgdG8KPiBzcGlfbXRkX3JlYWQoKSBvciBzb21ldGhpbmcgZWxzZS4K Ckkga25vdyB0aGF0IG9uIHRoZSBaeW5xLCB5b3UgY2FuIGV2ZW4gbGV0IHRoZSBETUEgY29udHJv bGxlciBhY2Nlc3MgdGhlIFFTUEkgCmZsYXNoIHZpYSB0aGlzIG1lbW9yeSBtYXBwaW5nLiBUaGUg UVNQSSBjb250cm9sbGVyIGl0c2VsZiBkb2Vzbid0IHN1cHBvcnQgYW55IApETUEgYXQgYWxsLgoK SWYgc29tZXRoaW5nIHNpbWlsYXIgYXBwbGllcyB0byB0aGUgVEkgcGxhdGZvcm0gKG1vc3Qgb2Yg dGhlIFRJIHByb2NzIGhhdmUgCm5pY2UgRE1BIGNvbnRyb2xsZXJzKSBvbmUgY291bGQgZ28gb25l IHN0ZXAgZnVydGhlciBhbmQgaW1wbGVtZW50IGEgZ2VuZXJpYyAKRE1BLXRocm91Z2gtbW1hcCBh Y2Nlc3MgdG8gUVNQSSBmbGFzaC4KCk1pa2UuCgoKS2luZCByZWdhcmRzLAoKTWlrZSBMb29pam1h bnMKU3lzdGVtIEV4cGVydAoKVE9QSUMgRW1iZWRkZWQgUHJvZHVjdHMKRWluZGhvdmVuc2V3ZWcg MzItQywgTkwtNTY4MyBLSCBCZXN0ClBvc3RidXMgNDQwLCBOTC01NjgwIEFLIEJlc3QKVGVsZWZv b246ICszMSAoMCkgNDk5IDMzIDY5IDc5ClRlbGVmYXg6ICszMSAoMCkgNDk5IDMzIDY5IDcwCkUt bWFpbDogbWlrZS5sb29pam1hbnNAdG9waWNwcm9kdWN0cy5jb20KV2Vic2l0ZTogd3d3LnRvcGlj cHJvZHVjdHMuY29tCgpQbGVhc2UgY29uc2lkZXIgdGhlIGVudmlyb25tZW50IGJlZm9yZSBwcmlu dGluZyB0aGlzIGUtbWFpbAoKVmlzaXQgdXMgYXQgOiBBZXJvc3BhY2UgRWxlY3RyaWNhbCBTeXN0 ZW1zIEV4cG8gRXVyb3BlIHdoaWNoIHdpbGwgYmUgaGVsZCBmcm9tIDE3LjExLjIwMTUgdGlsbCAx OS4xMS4yMDE1LCBGaW5kb3JmZnN0cmFzc2UgMTAxIEJyZW1lbiwgR2VybWFueSwgSGFsbCA1LCBz dGFuZCBudW1iZXIgQzY1Cmh0dHA6Ly93d3cuYWVzZXhwby5ldQoKCgpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpsaW51eC1hcm0ta2VybmVsIG1haWxpbmcg bGlzdApsaW51eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmcKaHR0cDovL2xpc3RzLmlu ZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1hcm0ta2VybmVsCg== From mboxrd@z Thu Jan 1 00:00:00 1970 From: mike.looijmans@topic.nl (Mike Looijmans) Date: Fri, 13 Nov 2015 15:06:55 +0100 Subject: [PATCH v3 1/5] spi: introduce mmap read support for spi flash devices In-Reply-To: <5642E546.3040806@ti.com> References: <1447133399-25658-1-git-send-email-vigneshr@ti.com> <1447133399-25658-2-git-send-email-vigneshr@ti.com> <20151110232341.GU12143@google.com> <5642E546.3040806@ti.com> Message-ID: <5645EE7F.5040101@topic.nl> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org ?On 11-11-15 07:50, R, Vignesh wrote: > Hi Brain, > > On 11/11/2015 4:53 AM, Brian Norris wrote: >> Hi Vignesh, ... >> Also, this API doesn't actually have anything to do with memory mapping. >> It has to do with the de facto standard flash protocol. So I don't think >> mmap belongs in the name; it should be something about flash. (I know of >> at least one other controller that could probably use this API, excpet >> it doesn't use memory mapping to accomplish the accelerated flash read.) The Zynq has a similar way of accessing QSPI flash through a memory map. The memory window is only 16MB, so some form of paging would be needed. It's why I have been following this thread with great interest, since the QSPI performance on the Zynq is way below what it could potentially be. > As far as TI QSPI controller is concerned, the accelerated read happens > via mmap port whereby a predefined memory address space of SoC is > exposed as QSPI mmap region. This region can be accessed like normal > RAM(via memcpy()) and the QSPI controller interface takes care of > fetching data from flash on SPI bus automatically hence, I named it as > above. But, I have no hard feelings if it needs to be generalized to > spi_mtd_read() or something else. I know that on the Zynq, you can even let the DMA controller access the QSPI flash via this memory mapping. The QSPI controller itself doesn't support any DMA at all. If something similar applies to the TI platform (most of the TI procs have nice DMA controllers) one could go one step further and implement a generic DMA-through-mmap access to QSPI flash. Mike. Kind regards, Mike Looijmans System Expert TOPIC Embedded Products Eindhovenseweg 32-C, NL-5683 KH Best Postbus 440, NL-5680 AK Best Telefoon: +31 (0) 499 33 69 79 Telefax: +31 (0) 499 33 69 70 E-mail: mike.looijmans at topicproducts.com Website: www.topicproducts.com Please consider the environment before printing this e-mail Visit us at : Aerospace Electrical Systems Expo Europe which will be held from 17.11.2015 till 19.11.2015, Findorffstrasse 101 Bremen, Germany, Hall 5, stand number C65 http://www.aesexpo.eu