From: Jisheng Zhang <jszhang@marvell.com>
To: Khoa Dang Pham <kpham@apm.com>
Cc: Mark Brown <broonie@kernel.org>, <linux-spi@vger.kernel.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [RFC] spi: dw: support setting tmode dynamically
Date: Wed, 6 Jan 2016 15:22:01 +0800 [thread overview]
Message-ID: <20160106152201.7829bdd7@xhacker> (raw)
In-Reply-To: <CAFLsZf31bt+-uwTo3zBWkho3UxquRCeTmK3hNMrGLXkjwHanwA@mail.gmail.com>
Dear Khoa,
On Wed, 6 Jan 2016 14:04:30 +0700 Khoa Dang Pham wrote:
> Hi Jisheng,
>
> On Wed, Jan 6, 2016 at 1:23 PM, Jisheng Zhang wrote:
> > Dear Khoa, Mark,
> >
> > On Wed, 6 Jan 2016 08:45:38 +0700 Khoa Dang Pham wrote:
> >
> >> Hi Mark,
> >>
> >> May I provide a bit more info about the "EEPROM read" on this controller?
> >>
> >> According to the "DesignWare DW_apb_ssi Databook" (version 3.21b) provided
> >> by Synopsys, the EEPROM read is:
> >>
> >> "When TMOD = 2‘b11, the transmit data is used to transmit an 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, data 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 opcode 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 been
> >> sent), data on the receive line
> >> (rxd) is valid and is stored in the receive FIFO; the txd output is held 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 the
> > 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 Receive"
> > 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.
> >
>
> I met the same issue before. The issue might be caused by the CS
> signal is toggled
> when we changed the transfer modes during opcode transmission and data
> receiption.
>
> According to the document I referred before:
> "The slave select line is held high when the DW_apb_ssi is idle or
> disabled."
>
> In your first 4 options, you need to disable this controller to write
> to the CTRLR0 register
> in order to switch the transfer modes. The CS line changes from low
> level (active) to high
> level (inactive) during the configuration. The NOR flash sees this CS
> toggle as a reset and
> stops outputting requested data.
Thanks for the information. This could explain what I saw. So how to
patch the spi-dw driver to support reading from NOR flash? Except
configure the tmode dynamically, is there any other solution?
Thanks very much for your input,
Jisheng
>
> Regards,
> Khoa Pham
>
> > Thanks,
> > Jisheng
> >
> >>
> >> Regards,
> >> Khoa Pham
> >>
> >> On Tue, Jan 5, 2016 at 11:12 PM, Mark Brown wrote:
> >>
> >> > On Wed, Dec 23, 2015 at 08:29:52PM +0800, Jisheng Zhang wrote:
> >> > > On Wed, 23 Dec 2015 12:15:12 +0000 Mark Brown wrote:
> >> > > > On Wed, Dec 23, 2015 at 07:23:38PM +0800, Jisheng Zhang wrote:
> >> >
> >> > > > > Currently the spi-dw tmode is fixed to SPI_TMOD_TR if cs_control is
> >> > NULL, but we
> >> > > > > need to set it as SPI_TMOD_EPROMREAD to read nor flash, my solution
> >> > is to add and
> >> > > > > export one functions to set the tmode, then the nor flash driver
> >> > call it
> >> > > > > before reading and set back to SPI_TMOD_TR after done.
> >> >
> >> > > > 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...
> >> >
> >> > > TMOD is one field of DW_SPI_CTRL0. Its available value could be:
> >> >
> >> > > 0: Transmit and Receive
> >> > > 1: Transmit only
> >> > > 2: Receive only
> >> > > 3: EEPROM Read
> >> >
> >> > > If the one spi nor flash is connected to the SPI host, so far I can only
> >> > succeed
> >> > > to read the nor flash content after setting the TMOD field as 3.
> >> >
> >> > 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.
> >> >
> >>
> >
>
next prev parent reply other threads:[~2016-01-06 7:25 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-23 11:23 [RFC] spi: dw: support setting tmode dynamically Jisheng Zhang
2015-12-23 12:15 ` Mark Brown
2015-12-23 12:29 ` Jisheng Zhang
2016-01-05 16:12 ` Mark Brown
[not found] ` <CAFLsZf0LvrQ60GdLzp_5nPLVxSxVaPadgzT_7aL4SQzgvswQbA@mail.gmail.com>
2016-01-06 2:03 ` Khoa Dang Pham
2016-01-06 6:23 ` Jisheng Zhang
2016-01-06 7:04 ` Khoa Dang Pham
2016-01-06 7:22 ` Jisheng Zhang [this message]
2016-01-06 7:36 ` Khoa Dang Pham
2016-01-06 7:45 ` Jisheng Zhang
2016-01-06 12:13 ` Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160106152201.7829bdd7@xhacker \
--to=jszhang@marvell.com \
--cc=broonie@kernel.org \
--cc=kpham@apm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-spi@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).