linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: boris.brezillon@free-electrons.com (Boris Brezillon)
To: linux-arm-kernel@lists.infradead.org
Subject: [RESEND PATCH 1/3] mtd: nand: Pass the CS line to ->setup_data_interface()
Date: Tue, 21 Feb 2017 13:47:43 +0100	[thread overview]
Message-ID: <20170221134743.3c88472e@bbrezillon> (raw)
In-Reply-To: <45a843fb-c43e-711f-ce3a-4c0d44c48144@sigmadesigns.com>

On Tue, 21 Feb 2017 13:02:48 +0100
Marc Gonzalez <marc_gonzalez@sigmadesigns.com> wrote:

> On 21/02/2017 12:06, Boris Brezillon wrote:
> 
> > Marc Gonzalez wrote:
> >   
> >> On 20/02/2017 22:12, Boris Brezillon wrote:
> >>  
> >>> Some NAND controllers can assign different NAND timings to different
> >>> CS lines. Pass the CS line information to ->setup_data_interface() so
> >>> that the NAND controller driver knows which CS line is concerned by
> >>> the setup_data_interface() request.    
> >>
> >> I'm confused, because I thought I was already doing that.
> >> On my platform, I have different timings for each chip.
> >> (thus, for each CS, right?)
> >>
> >> In chip->select_chip, I program the appropriate timings
> >> which the controller will be using.
> >>
> >> What am I missing?  
> > 
> > Maybe you don't have multi-dies chips, which is the case I'm fixing
> > here. If you have 2 separate chips, the existing hook should work just
> > fine.  
> 
> Right. You asked me to add an explicit:
> 
> 	res = of_property_count_u32_elems(np, "reg");
> 	if (res < 0)
> 		return res;
> 
> 	if (res != 1)
> 		return -ENOTSUPP; /* Multi-CS chips are not supported */
> 
> I was under the impression that multi-die chips are seen as a single
> larger "composite" chip. And I had assumed that different dies would
> not only require identical timings, but would also be identical in
> all other aspects. This it incorrect?

This is correct, except some chips (that's true at least for ONFI
compatible ones) allow dynamic configuration of timings, and each die
can be configured in a different timing mode.

That's what's happening when you reset dies. They will automatically
enter timing mode 0 (the slowest mode), and you have to explicitly set
them back to timing mode X (the fastest supported mode). While doing
that, you'll have some of your dies configured in timing 0, while
others have already been switched to timing mode X, and that's the main
reason for having per-die timing configuration.

  reply	other threads:[~2017-02-21 12:47 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-20 21:12 [RESEND PATCH 0/3] mtd: nand: atmel: Add ->setup_data_interface() + PM ops Boris Brezillon
2017-02-20 21:12 ` [RESEND PATCH 1/3] mtd: nand: Pass the CS line to ->setup_data_interface() Boris Brezillon
2017-02-21 10:57   ` Marc Gonzalez
2017-02-21 11:06     ` Boris Brezillon
2017-02-21 12:02       ` Marc Gonzalez
2017-02-21 12:47         ` Boris Brezillon [this message]
2017-02-20 21:12 ` [RESEND PATCH 2/3] mtd: nand: atmel: Add ->setup_data_interface() hooks Boris Brezillon
2017-02-20 22:47   ` Marek Vasut
2017-02-21  8:13     ` Boris Brezillon
2017-02-20 21:12 ` [RESEND PATCH 3/3] mtd: nand: atmel: Add PM ops Boris Brezillon

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=20170221134743.3c88472e@bbrezillon \
    --to=boris.brezillon@free-electrons.com \
    --cc=linux-arm-kernel@lists.infradead.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).