From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jisheng Zhang Subject: Re: [RFC] spi: dw: support setting tmode dynamically Date: Wed, 6 Jan 2016 14:23:40 +0800 Message-ID: <20160106142340.34e2d334@xhacker> References: <20151223192338.128e95a4@xhacker> <20151223121512.GV16023@sirena.org.uk> <20151223202952.28be5bab@xhacker> <20160105161231.GG6588@sirena.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Mark Brown , , To: Khoa Dang Pham Return-path: In-Reply-To: Sender: linux-spi-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Dear Khoa, Mark, On Wed, 6 Jan 2016 08:45:38 +0700 Khoa Dang Pham wrote: > Hi Mark, >=20 > May I provide a bit more info about the "EEPROM read" on this control= ler? >=20 > According to the "DesignWare DW_apb_ssi Databook" (version 3.21b) pro= vided > by Synopsys, the EEPROM read is: >=20 > "When TMOD =3D 2=E2=80=98b11, the transmit data is used to transmit a= n opcode and/or > an address to the EEPROM > device. Typically this takes three data frames (8-bit opcode followed= by > 8-bit upper address and 8-bit lower > address). During the transmission of the opcode and address, no data = is > captured by the receive logic (as > long as the DW_apb_ssi master is transmitting data on its txd line, d= ata on > the rxd line is ignored). The > DW_apb_ssi master continues to transmit data until the transmit FIFO = is > empty. Therefore, you should > ONLY have enough data frames in the transmit FIFO to supply the opcod= e and > address to the EEPROM. If > more data frames are in the transmit FIFO than are needed, then read = data > is lost. > When the transmit FIFO becomes empty (all control information has bee= n > sent), data on the receive line > (rxd) is valid and is stored in the receive FIFO; the txd output is h= eld at > a constant logic level. The serial > transfer continues until the number of data frames received by the > DW_apb_ssi master matches the value of > the NDF field in the CTRLR1 register + 1." I tried the following combinations: 1. "Transmit only" to send opcode and address, "Receive only" to read t= he response 2. "Transmit and Receive" to send opcode and address, "Receive only" to= read the response 3. "Transmit and Receive" to send opcode and address, "Transmit and Rec= eive" to read the response 4. "Transmit and Receive" only to send opcode and address None of the above succeed. I only succeed when using 5. EEPROM Read to send opcode, address. I can get the correct NOR flash content from the response. Thanks, Jisheng >=20 > Regards, > Khoa Pham >=20 > On Tue, Jan 5, 2016 at 11:12 PM, Mark Brown wrote: >=20 > > On Wed, Dec 23, 2015 at 08:29:52PM +0800, Jisheng Zhang wrote: =20 > > > On Wed, 23 Dec 2015 12:15:12 +0000 Mark Brown wrote: =20 > > > > On Wed, Dec 23, 2015 at 07:23:38PM +0800, Jisheng Zhang wrote: = =20 > > =20 > > > > > Currently the spi-dw tmode is fixed to SPI_TMOD_TR if cs_cont= rol is =20 > > NULL, but we =20 > > > > > need to set it as SPI_TMOD_EPROMREAD to read nor flash, my so= lution =20 > > is to add and =20 > > > > > export one functions to set the tmode, then the nor flash dri= ver =20 > > call it =20 > > > > > before reading and set back to SPI_TMOD_TR after done. =20 > > =20 > > > > What does this mean - what is TMOD and why do we need to set it= to read > > > > NOR flash? I've no information on this controller... =20 > > =20 > > > TMOD is one field of DW_SPI_CTRL0. Its available value could be: = =20 > > =20 > > > 0: Transmit and Receive > > > 1: Transmit only > > > 2: Receive only > > > 3: EEPROM Read =20 > > =20 > > > If the one spi nor flash is connected to the SPI host, so far I c= an only =20 > > succeed =20 > > > to read the nor flash content after setting the TMOD field as 3. = =20 > > > > Why? What does this mean in practical terms at the hardware level,= what > > is "EEPROM read"? It sounds like there's some bigger issue here. > > =20 >=20 -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html