Linux-SPI Archive on lore.kernel.org
 help / color / Atom feed
From: Michael Walle <michael@walle.cc>
To: Pratyush Yadav <p.yadav@ti.com>
Cc: Tudor.Ambarus@microchip.com, nm@ti.com, kristo@kernel.org,
	robh+dt@kernel.org, miquel.raynal@bootlin.com, richard@nod.at,
	vigneshr@ti.com, broonie@kernel.org,
	linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org,
	linux-spi@vger.kernel.org, lokeshvutla@ti.com
Subject: Re: [RFC PATCH 4/6] spi: cadence-qspi: Use PHY for DAC reads if possible
Date: Fri, 30 Apr 2021 00:20:13 +0200
Message-ID: <e17722c30deb7f2dcb94a9aa43bbc6dd@walle.cc> (raw)
In-Reply-To: <20210429181908.bwb45eljn5nxscf6@ti.com>

Am 2021-04-29 20:19, schrieb Pratyush Yadav:
> On 29/04/21 06:28PM, Michael Walle wrote:
>> Am 2021-03-12 11:17, schrieb Pratyush Yadav:
>> > On 12/03/21 09:13AM, Tudor.Ambarus@microchip.com wrote:
>> > > On 3/11/21 9:12 PM, Pratyush Yadav wrote:
>> > > > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>> > > >
>> > > > Check if a read is eligible for PHY and if it is, enable PHY and DQS.
>> > >
>> > > DQS as in data strobe? Shouldn't the upper layer inform the QSPI
>> > > controller
>> > > whether DS is required or not?
>> >
>> > Yes, DQS as in data strobe. I need to check this again, but IIRC the
>> > controller cannot run in PHY mode unless DS is used. Ideally the upper
>> > layer should indeed inform the controller whether DS is supported/in-use
>> > or not. That can be used to decide whether PHY mode (and consequently
>> > the DS line) is to be used or not.
>> >
>> > Currently there are only two flashes that use 8D-8D-8D mode (S28HS512T
>> > and MT35XU512ABA), and both of them drive the DS line.
>> 
>> The LS1028A datasheet explicitly states that the calibration is only
>> used for non-DQS flashes. Which makes sense, because it just determine 
>> at
>> which point the input data is sampled. And if the flash provides a 
>> data
>> strobe, it already know when to sample it. What I am missing here?
> 
> If there was 0 delay in transferring the signals from flash to
> SoC/controller, you would be right. But in practice there is a small 
> but
> noticeable delay from when the flash launches the signal and when it is
> received by the device. So by the time the DQS signal reaches the SoC 
> it
> might already be too late and the data lines might not be valid any
> more. The calibration accounts for these (and some others) delays.

DQS and the data signals are trace length matched, so for data reads
they will end up on the IO pad of the SoC at the same time. This is
also mentioned in [1] (Fig 1.1, point 4 and 5). So while there needs
to be a delay on the clock line for the receiving FF, the best value
for this should be half the SCK clock period.

Does this work without DQS? That should be the main purpose for a
calibration, no? Because in this case, you'll have to determine
the delay between SCK and the data signals (for reads).

Btw. I can't get my head around how the TX delay search would work.
Basically you shift the SCK to the command / data to the flash. So
the flash will either recognize a valid read command or if the delay
is too short/too long the flash will (hopefully) ignore the wrong
command, correct? Might there be any misinterpreted commands which
might be harmful? Are there any flashes which actually need a delay
between data out and SCK?

Of course, the calibration might help with broken hardware where the
SCK/DQ/DQS traces are not length matched.

-michael

> 
> See [0] for a somewhat similar discussion I had with Tudor.
> 
> [0] 
> https://lore.kernel.org/linux-mtd/20210312181447.dlecnw2oed7jtxe7@ti.com/

[1] https://www.ti.com/lit/an/spract2/spract2.pdf

  reply index

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-11 19:12 [RFC PATCH 0/6] spi: Add OSPI PHY calibration support for spi-cadence-quadspi Pratyush Yadav
2021-03-11 19:12 ` [RFC PATCH 1/6] spi: spi-mem: Tell controller when device is ready for calibration Pratyush Yadav
2021-03-23 23:07   ` Michael Walle
2021-03-24  8:08     ` Pratyush Yadav
2021-04-29 16:23       ` Michael Walle
2021-04-29 18:41         ` Pratyush Yadav
2021-04-29 22:46           ` Michael Walle
2021-03-11 19:12 ` [RFC PATCH 2/6] mtd: spi-nor: core: consolidate read op creation Pratyush Yadav
2021-03-23 23:17   ` Michael Walle
2021-03-24  8:04     ` Pratyush Yadav
2021-04-08 12:48   ` Michael Walle
2021-03-11 19:12 ` [RFC PATCH 3/6] mtd: spi-nor: core: run calibration when initialization is done Pratyush Yadav
2021-03-11 19:12 ` [RFC PATCH 4/6] spi: cadence-qspi: Use PHY for DAC reads if possible Pratyush Yadav
2021-03-12  9:13   ` Tudor.Ambarus
2021-03-12 10:17     ` Pratyush Yadav
2021-04-29 16:28       ` Michael Walle
2021-04-29 18:19         ` Pratyush Yadav
2021-04-29 22:20           ` Michael Walle [this message]
2021-05-10 11:39             ` Pratyush Yadav
2021-03-11 19:12 ` [RFC PATCH 5/6] spi: cadence-qspi: Tune PHY to allow running at higher frequencies Pratyush Yadav
2021-04-29 22:48   ` Michael Walle
2021-04-30  5:42     ` Pratyush Yadav
2021-03-11 19:12 ` [RFC PATCH 6/6] arm64: dts: ti: k3-j721e-som-p0: Enable PHY calibration Pratyush Yadav
2021-03-12  9:09 ` [RFC PATCH 0/6] spi: Add OSPI PHY calibration support for spi-cadence-quadspi Tudor.Ambarus
2021-03-12 10:10   ` Pratyush Yadav
2021-03-12 10:20     ` Michael Walle
2021-03-12 11:07       ` Pratyush Yadav
2021-03-12 13:26         ` Michael Walle
2021-03-12 11:23     ` Tudor.Ambarus
2021-03-12 18:14       ` Pratyush Yadav
2021-03-12 13:32 ` Michael Walle
2021-03-12 14:59   ` Tudor.Ambarus
2021-03-12 17:00   ` Pratyush Yadav

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=e17722c30deb7f2dcb94a9aa43bbc6dd@walle.cc \
    --to=michael@walle.cc \
    --cc=Tudor.Ambarus@microchip.com \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=kristo@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=lokeshvutla@ti.com \
    --cc=miquel.raynal@bootlin.com \
    --cc=nm@ti.com \
    --cc=p.yadav@ti.com \
    --cc=richard@nod.at \
    --cc=robh+dt@kernel.org \
    --cc=vigneshr@ti.com \
    /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

Linux-SPI Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-spi/0 linux-spi/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-spi linux-spi/ https://lore.kernel.org/linux-spi \
		linux-spi@vger.kernel.org
	public-inbox-index linux-spi

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-spi


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git