From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <52328142.8080001@freescale.com> Date: Fri, 13 Sep 2013 11:06:42 +0800 From: Huang Shijie MIME-Version: 1.0 To: David Woodhouse Subject: Re: [PATCH v3 0/8] Add the Quadspi driver for vf610-twr 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> In-Reply-To: <1379003172.4210.114.camel@i7.infradead.org> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: "devicetree@vger.kernel.org" , "computersforpeace@gmail.com" , "b44548@freescale.com" , "dedekind1@gmail.com" , "linux-doc@vger.kernel.org" , "b18965@freescale.com" , "linux-spi@vger.kernel.org" , "thomas.langer@lantiq.com" , Mark Brown , "linux-mtd@lists.infradead.org" , "Gupta, Pekon" , "kernel@pengutronix.de" , "lznuaa@gmail.com" , "shawn.guo@linaro.org" , Huang Shijie , "linux-arm-kernel@lists.infradead.org" List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , =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 runtim= e, >> But there is some disadvantage if we do so: >> [1] low efficiency: >> If you want to change the LUT regitster, you should unlock the = 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 quite > quickly find yourself using things which are *already* programmed into > 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 the 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 Quadsp= i >> controller only has a 64-byte TX-FIFO, so the controller should >> write a 64bytes firstly, then sends to the NOR with a read-stat= us >> 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 the > wire" in this case? Do you really send an OPCODE_RDSR (0x05) byte on th= e > 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 runti= me, >> 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 transaction. >> >> 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 the > controller doing anything other than that? > As the time goes on, the SPI devices or SPI controllers have become more=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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: b32955@freescale.com (Huang Shijie) Date: Fri, 13 Sep 2013 11:06:42 +0800 Subject: [PATCH v3 0/8] Add the Quadspi driver for vf610-twr In-Reply-To: <1379003172.4210.114.camel@i7.infradead.org> 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> Message-ID: <52328142.8080001@freescale.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org ? 2013?09?13? 00:26, David Woodhouse ??: > 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 runtime, >> But there is some disadvantage if we do so: >> [1] low efficiency: >> If you want to change the LUT regitster, you should unlock the 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 quite > quickly find yourself using things which are *already* programmed into > 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 the 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 Quadspi >> controller only has a 64-byte TX-FIFO, so the controller should >> write a 64bytes firstly, then sends to the NOR with a read-status >> 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 the > 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 runtime, >> 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 transaction. >> >> 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 the > controller doing anything other than that? > As the time goes on, the SPI devices or SPI controllers have become more and more complicated. If the Quadspi controller can not know the SPI NOR commands explicitly, it can not fill the LUT correctly, and at last it can not work. thanks Huang Shijie 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