From: Piotr Sroka <piotrs@cadence.com>
To: Boris Brezillon <bbrezillon@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
devicetree@vger.kernel.org, Richard Weinberger <richard@nod.at>,
linux-kernel@vger.kernel.org, Marek Vasut <marek.vasut@gmail.com>,
Rob Herring <robh+dt@kernel.org>,
linux-mtd@lists.infradead.org,
BrianNorris <computersforpeace@gmail.com>,
David Woodhouse <dwmw2@infradead.org>
Subject: Re: [PATCH 2/2] dt-bindings: nand: Add Cadence NAND controller driver
Date: Tue, 5 Feb 2019 17:08:14 +0000 [thread overview]
Message-ID: <20190205170812.GA18748@global.cadence.com> (raw)
In-Reply-To: <20190129182100.2fcb4e9f@bbrezillon>
The 01/29/2019 18:21, Boris Brezillon wrote:
>> +Optional properties:
>> +Driver calculates controller timings base on NAND flash memory timings and
>> +the following delays in picoseconds.
>> + - cdns,if-skew : Skew value of the output signals of the NAND Flash interface
>> + - cdns,nand2-delay : Delay value of one NAND2 gate from which
>> + the delay element is build
>> + - cdns,board-delay : Estimated Board delay. The value includes the total
>> + round trip delay for the signals and is used for deciding on values
>> + associated with data read capture. The example formula for SDR mode is
>> + the following:
>> + board_delay = RE#PAD_delay + PCB trace to device + PCB trace from device
>> + + DQ PAD delay
>
>The unit of those props is not defined, and if possible I'd like to
>avoid specifying custom timing adjustment values in the DT. Looks like
>some of these values are SoC specific (depends on the integration of
>this IP in a SoC) and others are board specific. For SoC specific
>values, this should be attached to the SoC specific compatible at the
>driver level. For board-specific values, I'd prefer to have a generic
>way to describe boards constraints.
Moving SoC specific delays from DTS to the driver data is clear for me. I do not know how to handle a board delay. Could you give me an example how it may be implemented? Where this board related stuff could be placed?
--
--
Regards
Piotr Sroka
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
prev parent reply other threads:[~2019-02-05 17:08 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-29 16:03 [PATCH 0/2] mtd: nand: Add Cadence NAND controller driver Piotr Sroka
2019-01-29 16:07 ` [PATCH 1/2] " Piotr Sroka
2019-01-29 18:19 ` Boris Brezillon
2019-02-07 13:20 ` Piotr Sroka
2019-01-29 16:10 ` [PATCH 2/2] dt-bindings: " Piotr Sroka
2019-01-29 17:21 ` Boris Brezillon
2019-02-05 17:08 ` Piotr Sroka [this message]
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=20190205170812.GA18748@global.cadence.com \
--to=piotrs@cadence.com \
--cc=bbrezillon@kernel.org \
--cc=computersforpeace@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=dwmw2@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=marek.vasut@gmail.com \
--cc=mark.rutland@arm.com \
--cc=richard@nod.at \
--cc=robh+dt@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).