From: Ricard Wanderlof <ricard.wanderlof@axis.com>
To: Boris Brezillon <boris.brezillon@free-electrons.com>
Cc: Brian Norris <computersforpeace@gmail.com>,
David Woodhouse <dwmw2@infradead.org>,
Benoit Cousson <bcousson@baylibre.com>,
Tony Lindgren <tony@atomide.com>, <devicetree@vger.kernel.org>,
Linux mtd <linux-mtd@lists.infradead.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/4] of: Add device tree bindings for Evatronix
Date: Fri, 10 Jun 2016 19:14:38 +0200 [thread overview]
Message-ID: <alpine.DEB.2.02.1606101906110.30757@lnxricardw1.se.axis.com> (raw)
In-Reply-To: <20160610190357.5f10c00f@bbrezillon>
On Fri, 10 Jun 2016, Boris Brezillon wrote:
> > Basically, in the general case, the controller can handle a matrix of
> > nand flash chips. There can be a number of banks, each of which can
> > have a number of individual CS lines. For the (in this case academic)
> > case of 3 banks and 4 chip selects per bank, there would be a total of
> > 3 x 4 = 12 CS lines.
> >
> > For the IP configuration the driver was written for, there are only 2
> > CS lines, and we can configure if they are to be viewed by the
> > controller as 2 CS lines within the same single bank, or 2 separate
> > banks with one CS each. This is what the DT property is intended to
> > express. It basically translates directly into a register write in the
> > IP.
>
> Okay, got it. I guess we should just expose the chip select in a linear
> way (3 banks of 4 CS means the controller should support up to 12
> chips), unless you really have a way to change the CS pins routing
> internally.
When I go through the driver I will also revisit this and give it some
more thought if there's a set of bindings which would make sense both for
the case we have now and for a general configuration of the IP.
> > Yes, that makes sense of course, but what if someone would want to
> > override the automatic settings, for whatever reason, using an
> > optional DT property? I can think of several reasons either way,
> > that's why I'm asking.
>
> You mean reducing the timings because the board design prevents using
> the highest supported mode for example? That would actually be a valid
> use case, and I guess we could make a generic property for that
> (without the vendor prefix).
Yes, either that, or if the automatic selection fails for some reason, say
in a given case we know that the chips we are using support mode 2 timing,
but one of them gets misidentified as mode 0. Sure, that is a bug and
should be fixed of course, but I can imagine commercial situations where
it may not be feasable to update the kernel, but where a new DT would be
ok.
/Ricard
--
Ricard Wolf Wanderlöf ricardw(at)axis.com
Axis Communications AB, Lund, Sweden www.axis.com
Phone +46 46 272 2016 Fax +46 46 13 61 30
prev parent reply other threads:[~2016-06-10 17:14 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-02 7:47 [PATCH 1/4] of: Add device tree bindings for Evatronix Ricard Wanderlof
2016-06-03 14:22 ` Boris Brezillon
2016-06-07 15:01 ` Ricard Wanderlof
2016-06-08 15:50 ` Boris Brezillon
2016-06-10 15:35 ` Ricard Wanderlof
2016-06-10 15:54 ` Boris Brezillon
2016-06-10 16:46 ` Ricard Wanderlof
2016-06-10 17:03 ` Boris Brezillon
2016-06-10 17:14 ` Ricard Wanderlof [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=alpine.DEB.2.02.1606101906110.30757@lnxricardw1.se.axis.com \
--to=ricard.wanderlof@axis.com \
--cc=bcousson@baylibre.com \
--cc=boris.brezillon@free-electrons.com \
--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=tony@atomide.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
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).