From mboxrd@z Thu Jan 1 00:00:00 1970 From: Huang Shijie Subject: Re: [PATCH v3 0/8] Add the Quadspi driver for vf610-twr Date: Fri, 13 Sep 2013 11:06:42 +0800 Message-ID: <52328142.8080001@freescale.com> References: <593AEF6C47F46446852B067021A273D6D984000B@MUCSE039.lantiq.com> <20130905020435.GA3970@gmail.com> <20980858CB6D3A4BAE95CA194937D5E73EA0C7F4@DBDE04.ent.ti.com> <522817D7.1010206@freescale.com> <522D3B79.3060707@freescale.com> <52318953.6090405@freescale.com> <1378979431.2627.402.camel@shinybook.infradead.org> <20130913025827.GA3051@gmail.com> <1378999322.4210.95.camel@i7.infradead.org> <20130913041208.GD3051@gmail.com> <1379003172.4210.114.camel@i7.infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <1379003172.4210.114.camel@i7.infradead.org> Sender: linux-doc-owner@vger.kernel.org To: David Woodhouse Cc: Huang Shijie , Mark Brown , "Gupta, Pekon" , "thomas.langer@lantiq.com" , "devicetree@vger.kernel.org" , "shawn.guo@linaro.org" , "b44548@freescale.com" , "dedekind1@gmail.com" , "linux-doc@vger.kernel.org" , "b18965@freescale.com" , "linux-spi@vger.kernel.org" , "linux-mtd@lists.infradead.org" , "kernel@pengutronix.de" , "lznuaa@gmail.com" , "computersforpeace@gmail.com" , "linux-arm-kernel@lists.infradead.org" List-Id: devicetree@vger.kernel.org =E4=BA=8E 2013=E5=B9=B409=E6=9C=8813=E6=97=A5 00:26, David Woodhouse =E5= =86=99=E9=81=93: > On Fri, 2013-09-13 at 00:12 -0400, Huang Shijie wrote: >> I will send you the datasheet tomorrow. > Thanks. Although according to the date header on your email, it is > *already* tomorrow. Any chance of fixing your clock, please? > I was at home then. but now i am at office. >> Mark and you want to create the LUT instruction sequence at the runt= ime, >> But there is some disadvantage if we do so: >> [1] low efficiency: >> If you want to change the LUT regitster, you should unlock th= e LUT >> register, and change the LUT regitsters, and lock the LUT >> regitsters again. > Although there aren't *that* many operations we perform, so you'd qui= te > quickly find yourself using things which are *already* programmed int= o > the LUT instead of having to re-program them again, surely? > If we can not parse out the SPI NOR commands, we can not quickly find t= he LUT which already programmed last time. >> [2] we may can not create all the LUT instruction sequence at the >> runtime. For example, the buffer program(OPCODE_PP): >> the m25p80_write() may write 256bytes at a time, but the Quad= spi >> controller only has a 64-byte TX-FIFO, so the controller shou= ld >> write a 64bytes firstly, then sends to the NOR with a read-st= atus >> command. Do you want to create a read-status LUT instruction >> sequence at run time? This is not good solution, we should >> pre-populate the read-status LUT information. > I'm not entirely sure I understand this. What *exactly* happens "on t= he > wire" in this case? Do you really send an OPCODE_RDSR (0x05) byte on = the > wire somehow, when you're supposed to be in the middle of sending the > page data to the chip? How does the chip handle that? > Yes, I really need to send an OPCODE_RDSR in the middle of sending page data (Page Program) to the chip. The NOR chip can accept the data input from 1-byte to 256bytes. So it can handle this. >> [3] We may can not create the LUT instruction sequence at the run= time, >> since we can not get enough information from the spi_transfer= {}. >> A whole LUT instruction sequence may needs the following info= : >> 1.) spi command. >> 2.) lines info: single line, dual lines, quad lines. >> 3.) Address width: 3 bytes address or 4 bytes address. >> 4.) instruction type: Read or write or other. >> 5.) length info: how many bytes for this transaction . >> 6.) dummy info: how many dummy is needed for this transactio= n. >> >> We can not get the dummy info from the spi_transfer{} > Again, what does that actually *mean*, on the wire? Please see the datasheet of the NOR: www.spansion.com/Support/Datasheets/S25FL128S_256S_00.pdf Please see the page 100, the Quad I/O Read, the figure 10.37 shows the dummy. The dummy is just a delay in a command sequence. The dummy maybe only several clock cycles, less then 8 bit. > I thought SPI was just 'send some bytes, fetch some bytes'. Why is th= e > controller doing anything other than that? > As the time goes on, the SPI devices or SPI controllers have become mor= e=20 and more complicated. If the Quadspi controller can not know the SPI NOR commands explicitly,= =20 it can not fill the LUT correctly, and at last it can not work. thanks Huang Shijie