From: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
To: "Gupta, Pekon" <pekon@ti.com>
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
Brian Norris <computersforpeace@gmail.com>,
"David Woodhouse \(dwmw2@infradead.org\)" <dwmw2@infradead.org>,
"Balbi, Felipe" <balbi@ti.com>,
Artem Bityutskiy <dedekind1@gmail.com>
Subject: Re: [PATCH] mtd: nand: auto-detection of NAND bus-width from ONFI param or nand_id[]
Date: Tue, 26 Nov 2013 09:42:52 -0300 [thread overview]
Message-ID: <20131126124251.GB2344@localhost> (raw)
In-Reply-To: <20980858CB6D3A4BAE95CA194937D5E73EA4ECB8@DBDE04.ent.ti.com>
Hi Pekon,
On Tue, Nov 26, 2013 at 07:59:07AM +0000, Gupta, Pekon wrote:
>
> > From: Ezequiel Garcia [mailto:ezequiel.garcia@free-electrons.com]
> [...]
> > My point is: why don't we *remove* the devicetree property nand-bus-
> > width and
> >
> We cannot remove DT property like this, we can only deprecate its use,
> while not breaking the functionality, which is what I'm trying here..
Of course, by "remove" the property I meant make it meaningless in the
driver.
> > the NAND_BUSWIDTH_16 entirely, together with this patch?
> >
> We need this Macros, as may driver use this after nand_scan_ident()
> to configure their custom callbacks like:
> if (chip->options & NAND_BUSWIDTH_16)
> chip->read_buf = omap_read_buf16;
> else
> chip->read_buf = omap_read_buf8;
>
>
> > Sounds like the user shouldn't need to mess with any of these, since we
> > are able to auto-configure things for him.
> >
> Yes, end-user is free.. But driver still needs to x16 and x8 information
> to do some controller level optimizations..
>
Right. So, we should keep it but remove the effect on the initial
configuration. AFAICS, the bus width should be *reported* by the NAND
core and then each driver will have access to that information to set
any additional configuration.
On the other side, no driver should *advise* the bus width.
Right?
--
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
next prev parent reply other threads:[~2013-11-26 12:43 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-25 12:32 [PATCH] mtd: nand: auto-detection of NAND bus-width from ONFI param or nand_id[] Pekon Gupta
2013-11-25 12:56 ` Ezequiel Garcia
2013-11-25 13:26 ` Gupta, Pekon
2013-11-25 13:32 ` Gupta, Pekon
2013-11-25 14:52 ` Ezequiel Garcia
2013-11-26 7:59 ` Gupta, Pekon
2013-11-26 12:42 ` Ezequiel Garcia [this message]
2013-11-27 6:03 ` Gupta, Pekon
2013-11-26 7:31 ` Huang Shijie
2013-11-26 7:49 ` Gupta, Pekon
2013-11-26 9:22 ` Huang Shijie
2013-11-26 12:45 ` Ezequiel Garcia
2013-11-29 12:18 ` Ezequiel Garcia
2013-11-29 12:28 ` Gupta, Pekon
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=20131126124251.GB2344@localhost \
--to=ezequiel.garcia@free-electrons.com \
--cc=balbi@ti.com \
--cc=computersforpeace@gmail.com \
--cc=dedekind1@gmail.com \
--cc=dwmw2@infradead.org \
--cc=linux-mtd@lists.infradead.org \
--cc=pekon@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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.