Re: [PATCH 1/5] mtd: ofpart: grab device tree node directly from master device node

Boris Brezillon writes: > On Thu, 29 Oct 2015 18:23:47 +0100 > Marek Vasut wrote: > Except it's now how devices supporting 16 bits data bus are supposed to > work, which means your NAND controller will probably not be able to > send the command/address value on the higher 8 bits... Correct. >>

Re: [PATCH 1/5] mtd: ofpart: grab device tree node directly from master device node

On Thu, 29 Oct 2015 18:23:47 +0100 Marek Vasut wrote: > On Thursday, October 29, 2015 at 08:24:48 AM, Boris Brezillon wrote: > > Hi Robert, > > Hi! > > > On Thu, 29 Oct 2015 07:32:33 +0100 > > > > Robert Jarzmik wrote: > > > Marek Vasut writes: > > > >> Isn't there the case of a single NAND

Re: [PATCH 1/5] mtd: ofpart: grab device tree node directly from master device node

On Thursday, October 29, 2015 at 08:24:48 AM, Boris Brezillon wrote: > Hi Robert, Hi! > On Thu, 29 Oct 2015 07:32:33 +0100 > > Robert Jarzmik wrote: > > Marek Vasut writes: > > >> Isn't there the case of a single NAND controller with 2 identical > > >> chips, each a 8 bit NAND chip, and the

Re: [PATCH 1/5] mtd: ofpart: grab device tree node directly from master device node

Hi Robert, On Thu, 29 Oct 2015 07:32:33 +0100 Robert Jarzmik wrote: > Marek Vasut writes: > > >> Isn't there the case of a single NAND controller with 2 identical chips, > >> each a 8 bit NAND chip, and the controller aggregating them to offer the > >> OS a single 16-bit NAND chip ?

Re: [PATCH 1/5] mtd: ofpart: grab device tree node directly from master device node

Marek Vasut writes: >> Isn't there the case of a single NAND controller with 2 identical chips, >> each a 8 bit NAND chip, and the controller aggregating them to offer the >> OS a single 16-bit NAND chip ? > > Is that using 1 or 2 physical chipselect lines on the CPU (controller) ? I think it's

Re: [PATCH 1/5] mtd: ofpart: grab device tree node directly from master device node

On Thursday, October 29, 2015 at 08:24:48 AM, Boris Brezillon wrote: > Hi Robert, Hi! > On Thu, 29 Oct 2015 07:32:33 +0100 > > Robert Jarzmik wrote: > > Marek Vasut writes: > > >> Isn't there the case of a single NAND controller with 2 identical > > >>

Re: [PATCH 1/5] mtd: ofpart: grab device tree node directly from master device node

On Thu, 29 Oct 2015 18:23:47 +0100 Marek Vasut wrote: > On Thursday, October 29, 2015 at 08:24:48 AM, Boris Brezillon wrote: > > Hi Robert, > > Hi! > > > On Thu, 29 Oct 2015 07:32:33 +0100 > > > > Robert Jarzmik wrote: > > > Marek Vasut

Re: [PATCH 1/5] mtd: ofpart: grab device tree node directly from master device node

Boris Brezillon writes: > On Thu, 29 Oct 2015 18:23:47 +0100 > Marek Vasut wrote: > Except it's now how devices supporting 16 bits data bus are supposed to > work, which means your NAND controller will probably not be able to > send the

Re: [PATCH 1/5] mtd: ofpart: grab device tree node directly from master device node

Hi Robert, On Thu, 29 Oct 2015 07:32:33 +0100 Robert Jarzmik wrote: > Marek Vasut writes: > > >> Isn't there the case of a single NAND controller with 2 identical chips, > >> each a 8 bit NAND chip, and the controller aggregating them to offer the > >>

Re: [PATCH 1/5] mtd: ofpart: grab device tree node directly from master device node

Marek Vasut writes: >> Isn't there the case of a single NAND controller with 2 identical chips, >> each a 8 bit NAND chip, and the controller aggregating them to offer the >> OS a single 16-bit NAND chip ? > > Is that using 1 or 2 physical chipselect lines on the CPU (controller)

Re: [PATCH 1/5] mtd: ofpart: grab device tree node directly from master device node

On Wednesday, October 28, 2015 at 09:55:24 PM, Robert Jarzmik wrote: > Brian Norris writes: > >> > Do some sorts of chipselects come into play here ? Ie. you can have > >> > one master with multiple NAND chips connected to it. > >> > >> Most NAND controllers support interacting with several

Re: [PATCH 1/5] mtd: ofpart: grab device tree node directly from master device node

Brian Norris writes: >> > >> > Do some sorts of chipselects come into play here ? Ie. you can have one >> > master >> > with multiple NAND chips connected to it. >> >> Most NAND controllers support interacting with several chips (or >> dies in case your chip embeds several NAND dies), but I

Re: [PATCH 1/5] mtd: ofpart: grab device tree node directly from master device node

On Wednesday, October 28, 2015 at 05:32:15 PM, Boris Brezillon wrote: > Hi Marek, Hi Boris, > On Wed, 28 Oct 2015 17:11:14 +0100 > > Marek Vasut wrote: > > On Wednesday, October 28, 2015 at 08:58:13 AM, Boris Brezillon wrote: > > > Hi Brian, > > > > Hi, > > > > [...] > > > > > > Are > > > >

Re: [PATCH 1/5] mtd: ofpart: grab device tree node directly from master device node

On Wed, Oct 28, 2015 at 05:32:15PM +0100, Boris Brezillon wrote: > On Wed, 28 Oct 2015 17:11:14 +0100 > Marek Vasut wrote: > > On Wednesday, October 28, 2015 at 08:58:13 AM, Boris Brezillon wrote: > > > Hi Brian, > > > > Hi, > > > > [...] > > > > > > Are > > > > there ever cases we want more

Re: [PATCH 1/5] mtd: ofpart: grab device tree node directly from master device node

Hi Marek, On Wed, 28 Oct 2015 17:11:14 +0100 Marek Vasut wrote: > On Wednesday, October 28, 2015 at 08:58:13 AM, Boris Brezillon wrote: > > Hi Brian, > > Hi, > > [...] > > > > Are > > > there ever cases we want more than one (master) MTD per nand_chip? Or > > > vice versa? > > > > Nope, I'd

Re: [PATCH 1/5] mtd: ofpart: grab device tree node directly from master device node

On Wednesday, October 28, 2015 at 08:58:13 AM, Boris Brezillon wrote: > Hi Brian, Hi, [...] > > Are > > there ever cases we want more than one (master) MTD per nand_chip? Or > > vice versa? > > Nope, I'd say that you always have a 1:1 relationship between a master > MTD device and a NAND

Re: [PATCH 1/5] mtd: ofpart: grab device tree node directly from master device node

Hi Brian, On Tue, 27 Oct 2015 18:01:02 -0700 Brian Norris wrote: > On Tue, Oct 27, 2015 at 10:54:46AM -0700, Brian Norris wrote: > > On Tue, Oct 27, 2015 at 08:42:00AM +0100, Boris Brezillon wrote: > > > On Mon, 26 Oct 2015 19:31:06 -0700 > > > I like the idea, but how about pushing the

Re: [PATCH 1/5] mtd: ofpart: grab device tree node directly from master device node

Hi Brian, On Tue, 27 Oct 2015 10:54:46 -0700 Brian Norris wrote: > Hi Boris, > > On Tue, Oct 27, 2015 at 08:42:00AM +0100, Boris Brezillon wrote: > > On Mon, 26 Oct 2015 19:31:06 -0700 > > Brian Norris wrote: > > > > > It seems more logical to use a device node directly associated with the >

Re: [PATCH 1/5] mtd: ofpart: grab device tree node directly from master device node

Hi Brian, On Tue, 27 Oct 2015 18:01:02 -0700 Brian Norris wrote: > On Tue, Oct 27, 2015 at 10:54:46AM -0700, Brian Norris wrote: > > On Tue, Oct 27, 2015 at 08:42:00AM +0100, Boris Brezillon wrote: > > > On Mon, 26 Oct 2015 19:31:06 -0700 > > > I like the idea, but

Re: [PATCH 1/5] mtd: ofpart: grab device tree node directly from master device node

Hi Brian, On Tue, 27 Oct 2015 10:54:46 -0700 Brian Norris wrote: > Hi Boris, > > On Tue, Oct 27, 2015 at 08:42:00AM +0100, Boris Brezillon wrote: > > On Mon, 26 Oct 2015 19:31:06 -0700 > > Brian Norris wrote: > > > > > It seems more

Re: [PATCH 1/5] mtd: ofpart: grab device tree node directly from master device node

Hi Marek, On Wed, 28 Oct 2015 17:11:14 +0100 Marek Vasut wrote: > On Wednesday, October 28, 2015 at 08:58:13 AM, Boris Brezillon wrote: > > Hi Brian, > > Hi, > > [...] > > > > Are > > > there ever cases we want more than one (master) MTD per nand_chip? Or > > > vice versa? > >

Re: [PATCH 1/5] mtd: ofpart: grab device tree node directly from master device node

On Wednesday, October 28, 2015 at 08:58:13 AM, Boris Brezillon wrote: > Hi Brian, Hi, [...] > > Are > > there ever cases we want more than one (master) MTD per nand_chip? Or > > vice versa? > > Nope, I'd say that you always have a 1:1 relationship between a master > MTD device and a NAND

Re: [PATCH 1/5] mtd: ofpart: grab device tree node directly from master device node

On Wed, Oct 28, 2015 at 05:32:15PM +0100, Boris Brezillon wrote: > On Wed, 28 Oct 2015 17:11:14 +0100 > Marek Vasut wrote: > > On Wednesday, October 28, 2015 at 08:58:13 AM, Boris Brezillon wrote: > > > Hi Brian, > > > > Hi, > > > > [...] > > > > > > Are > > > > there ever cases

Re: [PATCH 1/5] mtd: ofpart: grab device tree node directly from master device node

Brian Norris writes: >> > >> > Do some sorts of chipselects come into play here ? Ie. you can have one >> > master >> > with multiple NAND chips connected to it. >> >> Most NAND controllers support interacting with several chips (or >> dies in case your chip

Re: [PATCH 1/5] mtd: ofpart: grab device tree node directly from master device node

On Wednesday, October 28, 2015 at 05:32:15 PM, Boris Brezillon wrote: > Hi Marek, Hi Boris, > On Wed, 28 Oct 2015 17:11:14 +0100 > > Marek Vasut wrote: > > On Wednesday, October 28, 2015 at 08:58:13 AM, Boris Brezillon wrote: > > > Hi Brian, > > > > Hi, > > > > [...] > > > >

Re: [PATCH 1/5] mtd: ofpart: grab device tree node directly from master device node

On Wednesday, October 28, 2015 at 09:55:24 PM, Robert Jarzmik wrote: > Brian Norris writes: > >> > Do some sorts of chipselects come into play here ? Ie. you can have > >> > one master with multiple NAND chips connected to it. > >> > >> Most NAND controllers support

Re: [PATCH 1/5] mtd: ofpart: grab device tree node directly from master device node

On Tue, Oct 27, 2015 at 10:54:46AM -0700, Brian Norris wrote: > On Tue, Oct 27, 2015 at 08:42:00AM +0100, Boris Brezillon wrote: > > On Mon, 26 Oct 2015 19:31:06 -0700 > > I like the idea, but how about pushing the solution even further and > > killing the ->flash_node field which AFAICT is

Re: [PATCH 1/5] mtd: ofpart: grab device tree node directly from master device node

Hi Boris, On Tue, Oct 27, 2015 at 08:42:00AM +0100, Boris Brezillon wrote: > On Mon, 26 Oct 2015 19:31:06 -0700 > Brian Norris wrote: > > > It seems more logical to use a device node directly associated with the > > MTD master device (i.e., mtd->dev.of_node field) rather than requiring > >

Re: [PATCH 1/5] mtd: ofpart: grab device tree node directly from master device node

Hi Brian, On Mon, 26 Oct 2015 19:31:06 -0700 Brian Norris wrote: > It seems more logical to use a device node directly associated with the > MTD master device (i.e., mtd->dev.of_node field) rather than requiring > auxiliary partition parser information to be passed in by the driver in > a

Re: [PATCH 1/5] mtd: ofpart: grab device tree node directly from master device node

Hi Brian, On Mon, 26 Oct 2015 19:31:06 -0700 Brian Norris wrote: > It seems more logical to use a device node directly associated with the > MTD master device (i.e., mtd->dev.of_node field) rather than requiring > auxiliary partition parser information to be passed

Re: [PATCH 1/5] mtd: ofpart: grab device tree node directly from master device node

Hi Boris, On Tue, Oct 27, 2015 at 08:42:00AM +0100, Boris Brezillon wrote: > On Mon, 26 Oct 2015 19:31:06 -0700 > Brian Norris wrote: > > > It seems more logical to use a device node directly associated with the > > MTD master device (i.e., mtd->dev.of_node field)

Re: [PATCH 1/5] mtd: ofpart: grab device tree node directly from master device node

On Tue, Oct 27, 2015 at 10:54:46AM -0700, Brian Norris wrote: > On Tue, Oct 27, 2015 at 08:42:00AM +0100, Boris Brezillon wrote: > > On Mon, 26 Oct 2015 19:31:06 -0700 > > I like the idea, but how about pushing the solution even further and > > killing the ->flash_node field which AFAICT is

[PATCH 1/5] mtd: ofpart: grab device tree node directly from master device node

It seems more logical to use a device node directly associated with the MTD master device (i.e., mtd->dev.of_node field) rather than requiring auxiliary partition parser information to be passed in by the driver in a separate struct. This patch supports the mtd->dev.of_node field, deprecates the

[PATCH 1/5] mtd: ofpart: grab device tree node directly from master device node

It seems more logical to use a device node directly associated with the MTD master device (i.e., mtd->dev.of_node field) rather than requiring auxiliary partition parser information to be passed in by the driver in a separate struct. This patch supports the mtd->dev.of_node field, deprecates the