All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
To: "Gupta, Pekon" <pekon@ti.com>
Cc: "marek.belisko@gmail.com" <marek.belisko@gmail.com>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	Brian Norris <computersforpeace@gmail.com>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	"Balbi, Felipe" <balbi@ti.com>
Subject: Re: [PATCH v2 0/5] Assorted OMAP2 NAND clean-ups
Date: Fri, 25 Oct 2013 08:48:37 -0300	[thread overview]
Message-ID: <20131025114836.GD2489@localhost> (raw)
In-Reply-To: <20980858CB6D3A4BAE95CA194937D5E73EA2AE2A@DBDE04.ent.ti.com>

Pekon,

On Fri, Oct 25, 2013 at 11:15:57AM +0000, Gupta, Pekon wrote:
> Hi,
> 
> > -----Original Message-----
> > From: Ezequiel Garcia [mailto:ezequiel.garcia@free-electrons.com]
> [...]
> 
> > Pekon, Brian: Do you think this solution might work for 8-bit and 16-bit
> > devices?
> > 
> I think NAND_BUSWIDTH_AUTO (without GPMC changes) would fail in
> following scenarios..
> 
> Case-1: configuring gpmc,device-width=1 from DT when using x16 device.

... which is wrong. That's why we have a DT property to configure that.
The GPMC *must* be properly configured.

> As your NAND driver is using NAND_BUSWIDTH_AUTO, it should
> ignore this DT config, and based on ONFI params it should work as x16
> 

Hm.. I don't think so. The auto-stuff is just for the NAND driver, not
for the memory controller. I don't know much about hardware, but in my mind
I imagine them as different controllers.

> Case-2: configuring gpmc,device-width=2 from DT when using x8 device.

... which is also wrong.

Once again, you're mis-configuring the GPMC. We cannot expect the NAND
driver to work properly if the GPMC is not properly initialized, don't
you think?

> Actually having NAND_BUSWIDTH_AUTO would require change in GPMC
> driver also.. please refer my comments in.. 
> http://lists.infradead.org/pipermail/linux-mtd/2013-October/049284.html
> 

Well, I think the approach should be different and much simpler: GPMC
*must* be properly configured and then NAND can do ONFI detection
starting in 8-bit and then switching to 16-bit if needed.

This is what this patch is doing: it _fixes_ the NAND driver ONFI detection,
_provided_ the GPMC is well-prepared.

You seem to think that GPMC + NAND should be able to automagically detect
the device and work, but I don't think that's even physically possible, for
the reasons you have just exposed.

I think this fix is simple enough.

BTW: The GPMC code ignores the DT value in 'gpmc,device-width' and uses
'nand-bus-width' instead, but that's a different bug and a different fix :)
-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com

WARNING: multiple messages have this Message-ID (diff)
From: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
To: "Gupta, Pekon" <pekon@ti.com>
Cc: Brian Norris <computersforpeace@gmail.com>,
	"Balbi, Felipe" <balbi@ti.com>,
	"marek.belisko@gmail.com" <marek.belisko@gmail.com>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>
Subject: Re: [PATCH v2 0/5] Assorted OMAP2 NAND clean-ups
Date: Fri, 25 Oct 2013 08:48:37 -0300	[thread overview]
Message-ID: <20131025114836.GD2489@localhost> (raw)
In-Reply-To: <20980858CB6D3A4BAE95CA194937D5E73EA2AE2A@DBDE04.ent.ti.com>

Pekon,

On Fri, Oct 25, 2013 at 11:15:57AM +0000, Gupta, Pekon wrote:
> Hi,
> 
> > -----Original Message-----
> > From: Ezequiel Garcia [mailto:ezequiel.garcia@free-electrons.com]
> [...]
> 
> > Pekon, Brian: Do you think this solution might work for 8-bit and 16-bit
> > devices?
> > 
> I think NAND_BUSWIDTH_AUTO (without GPMC changes) would fail in
> following scenarios..
> 
> Case-1: configuring gpmc,device-width=1 from DT when using x16 device.

... which is wrong. That's why we have a DT property to configure that.
The GPMC *must* be properly configured.

> As your NAND driver is using NAND_BUSWIDTH_AUTO, it should
> ignore this DT config, and based on ONFI params it should work as x16
> 

Hm.. I don't think so. The auto-stuff is just for the NAND driver, not
for the memory controller. I don't know much about hardware, but in my mind
I imagine them as different controllers.

> Case-2: configuring gpmc,device-width=2 from DT when using x8 device.

... which is also wrong.

Once again, you're mis-configuring the GPMC. We cannot expect the NAND
driver to work properly if the GPMC is not properly initialized, don't
you think?

> Actually having NAND_BUSWIDTH_AUTO would require change in GPMC
> driver also.. please refer my comments in.. 
> http://lists.infradead.org/pipermail/linux-mtd/2013-October/049284.html
> 

Well, I think the approach should be different and much simpler: GPMC
*must* be properly configured and then NAND can do ONFI detection
starting in 8-bit and then switching to 16-bit if needed.

This is what this patch is doing: it _fixes_ the NAND driver ONFI detection,
_provided_ the GPMC is well-prepared.

You seem to think that GPMC + NAND should be able to automagically detect
the device and work, but I don't think that's even physically possible, for
the reasons you have just exposed.

I think this fix is simple enough.

BTW: The GPMC code ignores the DT value in 'gpmc,device-width' and uses
'nand-bus-width' instead, but that's a different bug and a different fix :)
-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2013-10-25 11:49 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-25 10:17 [PATCH v2 0/5] Assorted OMAP2 NAND clean-ups Ezequiel Garcia
2013-10-25 10:17 ` Ezequiel Garcia
2013-10-25 10:17 ` [PATCH v2 1/5] ARM: am335x-bone: Add support for 16-bit NAND cape Ezequiel Garcia
2013-10-25 10:17   ` Ezequiel Garcia
2013-10-25 10:17 ` [PATCH v2 2/5] mtd: nand: omap2: Fix device detection path Ezequiel Garcia
2013-10-25 10:17   ` Ezequiel Garcia
2013-10-25 10:17 ` [PATCH v2 3/5] mtd: nand: omap2: Fix OMAP_BCH option dependency Ezequiel Garcia
2013-10-25 10:17   ` Ezequiel Garcia
2013-10-25 11:26   ` Gupta, Pekon
2013-10-25 11:26     ` Gupta, Pekon
2013-10-25 11:49     ` Ezequiel Garcia
2013-10-25 11:49       ` Ezequiel Garcia
2013-11-12 20:45     ` Ezequiel Garcia
2013-11-12 20:45       ` Ezequiel Garcia
2013-11-12 22:56       ` Brian Norris
2013-11-12 22:56         ` Brian Norris
2013-11-12 23:10         ` Ezequiel Garcia
2013-11-12 23:10           ` Ezequiel Garcia
2013-10-25 10:17 ` [PATCH v2 4/5] mtd: nand: omap2: Use devm_kzalloc Ezequiel Garcia
2013-10-25 10:17   ` Ezequiel Garcia
2013-10-25 10:25   ` Gupta, Pekon
2013-10-25 10:25     ` Gupta, Pekon
2013-10-25 10:42     ` Ezequiel Garcia
2013-10-25 10:42       ` Ezequiel Garcia
2013-10-25 11:09       ` Gupta, Pekon
2013-10-25 11:09         ` Gupta, Pekon
2013-10-25 11:19         ` Ezequiel Garcia
2013-10-25 11:19           ` Ezequiel Garcia
2013-10-25 10:17 ` [PATCH v2 5/5] mtd: nand: omap2: Use devm_ioremap_resource Ezequiel Garcia
2013-10-25 10:17   ` Ezequiel Garcia
2013-10-25 11:15 ` [PATCH v2 0/5] Assorted OMAP2 NAND clean-ups Gupta, Pekon
2013-10-25 11:15   ` Gupta, Pekon
2013-10-25 11:48   ` Ezequiel Garcia [this message]
2013-10-25 11:48     ` Ezequiel Garcia
2013-10-29 17:12     ` Ezequiel Garcia
2013-10-29 17:12       ` Ezequiel Garcia
2013-10-29 20:14     ` Gupta, Pekon
2013-10-29 20:14       ` Gupta, Pekon
2013-10-30  0:16       ` Ezequiel Garcia
2013-10-30  0:16         ` Ezequiel Garcia

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=20131025114836.GD2489@localhost \
    --to=ezequiel.garcia@free-electrons.com \
    --cc=balbi@ti.com \
    --cc=computersforpeace@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=marek.belisko@gmail.com \
    --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.