From: Wolfgang Grandegger <wg@grandegger.com>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: linuxppc-dev@ozlabs.org,
devicetree-discuss list <devicetree-discuss@ozlabs.org>,
linux-mtd@lists.infradead.org
Subject: Re: [PATCH v3 3/4] powerpc: NAND: FSL UPM: document new bindings
Date: Thu, 26 Mar 2009 08:42:03 +0100 [thread overview]
Message-ID: <49CB31CB.2010704@grandegger.com> (raw)
In-Reply-To: <fa686aa40903252209r52a1bc1cn995a7da16bc3527f@mail.gmail.com>
Grant Likely wrote:
> On Wed, Mar 25, 2009 at 2:48 PM, Wolfgang Grandegger <wg@grandegger.com> wrote:
>> Grant Likely wrote:
>>> For the chip offset, it's not clear what the meaning is. First, does
>>> the UPM controller support access of multiple chips simultaneously?
>> The offset drives the corresponding address lines, which are used to
>> select the chip. That's how it's done on the TQM8548 board. In
>> principle, the chips could also be selected through dedicated GPIO pins.
>> Well, I'm not a hardware guy.
>
> Heh. I mean elaborate in the binding documentation. :-)
>
>>> If so, then can you elaborate in the description on how board design
>>> translates to a chip-offset value. If it cannot, then it might be
>>> better to have multiple tuples in the 'reg' property for each discrete
>>> chip. Multiple reg tuples would also remove the need for the
>>> num-chips property.
>> The node still describes one device mapping all relevant control
>> registers. How about using fsl,upm-chip-offsets = <0x200 0x400>. It
>> would be more generic and makes num-chips obsolete as well. And the
>> property would be reserved for that way of implementing the chip select
>> in hardware.
>
> It really sounds like this binding is describing multiple NAND chips
> mapped to different base addresses (and looking at the fsm_upm.c
> driver appears to confirm it). So, does this work? reg = <3 0x200 4
> 3 0x400 4>;
The chip-offset, and not the address, needs to be added to the MAR
register as well before running the pattern:
mar = cmd << (32 - fun->upm.width);
if (fun->chip_offset && fun->chip_number > 0)
mar |= fun->chip_number * fun->chip_offset;
fsl_upm_run_pattern(&fun->upm, chip->IO_ADDR_R, mar);
> It is true that other methods could be used for implementing the chip
> select, but that is *not* what the proposed binding describes. This
> proposed binding describes NAND chips selected by address lines
> (particular addresses), and in this case I think using reg is the
> natural description.
OK, the chips are selected by accessing a defined address range. Will
prepare a patch using the reg property.
Wolfgang.
> g.
>
WARNING: multiple messages have this Message-ID (diff)
From: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
To: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
Cc: linuxppc-dev-mnsaURCQ41sdnm+yROfE0A@public.gmane.org,
devicetree-discuss list
<devicetree-discuss-mnsaURCQ41sdnm+yROfE0A@public.gmane.org>,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH v3 3/4] powerpc: NAND: FSL UPM: document new bindings
Date: Thu, 26 Mar 2009 08:42:03 +0100 [thread overview]
Message-ID: <49CB31CB.2010704@grandegger.com> (raw)
In-Reply-To: <fa686aa40903252209r52a1bc1cn995a7da16bc3527f-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Grant Likely wrote:
> On Wed, Mar 25, 2009 at 2:48 PM, Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org> wrote:
>> Grant Likely wrote:
>>> For the chip offset, it's not clear what the meaning is. First, does
>>> the UPM controller support access of multiple chips simultaneously?
>> The offset drives the corresponding address lines, which are used to
>> select the chip. That's how it's done on the TQM8548 board. In
>> principle, the chips could also be selected through dedicated GPIO pins.
>> Well, I'm not a hardware guy.
>
> Heh. I mean elaborate in the binding documentation. :-)
>
>>> If so, then can you elaborate in the description on how board design
>>> translates to a chip-offset value. If it cannot, then it might be
>>> better to have multiple tuples in the 'reg' property for each discrete
>>> chip. Multiple reg tuples would also remove the need for the
>>> num-chips property.
>> The node still describes one device mapping all relevant control
>> registers. How about using fsl,upm-chip-offsets = <0x200 0x400>. It
>> would be more generic and makes num-chips obsolete as well. And the
>> property would be reserved for that way of implementing the chip select
>> in hardware.
>
> It really sounds like this binding is describing multiple NAND chips
> mapped to different base addresses (and looking at the fsm_upm.c
> driver appears to confirm it). So, does this work? reg = <3 0x200 4
> 3 0x400 4>;
The chip-offset, and not the address, needs to be added to the MAR
register as well before running the pattern:
mar = cmd << (32 - fun->upm.width);
if (fun->chip_offset && fun->chip_number > 0)
mar |= fun->chip_number * fun->chip_offset;
fsl_upm_run_pattern(&fun->upm, chip->IO_ADDR_R, mar);
> It is true that other methods could be used for implementing the chip
> select, but that is *not* what the proposed binding describes. This
> proposed binding describes NAND chips selected by address lines
> (particular addresses), and in this case I think using reg is the
> natural description.
OK, the chips are selected by accessing a defined address range. Will
prepare a patch using the reg property.
Wolfgang.
> g.
>
next prev parent reply other threads:[~2009-03-26 7:42 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-25 10:08 [PATCH v3 0/4] NAND: Multi-chip support for FSL-UPM for TQM8548 modules Wolfgang Grandegger
2009-03-25 10:08 ` Wolfgang Grandegger
2009-03-25 10:08 ` [PATCH v3 1/4] NAND: FSL-UPM: add multi chip support Wolfgang Grandegger
2009-03-25 10:08 ` Wolfgang Grandegger
2009-03-25 10:08 ` [PATCH v3 2/4] NAND: FSL-UPM: Add wait flags to support board/chip specific delays Wolfgang Grandegger
2009-03-25 10:08 ` Wolfgang Grandegger
2009-03-25 10:08 ` [PATCH v3 3/4] powerpc: NAND: FSL UPM: document new bindings Wolfgang Grandegger
2009-03-25 10:08 ` Wolfgang Grandegger
2009-03-25 10:08 ` [PATCH v3 4/4] powerpc/85xx: TQM8548: Update DTS file for multi-chip support Wolfgang Grandegger
2009-03-25 10:08 ` Wolfgang Grandegger
2009-03-25 15:11 ` [PATCH v3 3/4] powerpc: NAND: FSL UPM: document new bindings Anton Vorontsov
2009-03-25 15:11 ` Anton Vorontsov
2009-03-25 17:48 ` Grant Likely
2009-03-25 17:48 ` Grant Likely
2009-03-25 20:48 ` Wolfgang Grandegger
2009-03-26 5:09 ` Grant Likely
2009-03-26 5:09 ` Grant Likely
2009-03-26 7:42 ` Wolfgang Grandegger [this message]
2009-03-26 7:42 ` Wolfgang Grandegger
2009-03-26 14:27 ` Grant Likely
2009-03-26 14:27 ` Grant Likely
2009-03-26 14:27 ` Grant Likely
2009-03-26 15:33 ` Wolfgang Grandegger
2009-03-26 15:33 ` Wolfgang Grandegger
2009-03-26 16:04 ` Grant Likely
2009-03-26 16:04 ` Grant Likely
2009-03-26 16:04 ` Grant Likely
2009-03-26 16:35 ` Wolfgang Grandegger
2009-03-26 17:02 ` Grant Likely
2009-03-26 17:02 ` Grant Likely
2009-03-26 17:33 ` Anton Vorontsov
2009-03-26 17:33 ` Anton Vorontsov
2009-03-26 17:33 ` Anton Vorontsov
2009-03-26 22:14 ` Wolfgang Grandegger
2009-03-26 22:14 ` Wolfgang Grandegger
2009-03-26 23:22 ` Grant Likely
2009-03-26 23:22 ` Grant Likely
2009-03-26 23:22 ` Grant Likely
2009-03-26 23:32 ` Anton Vorontsov
2009-03-26 23:32 ` Anton Vorontsov
2009-03-26 23:32 ` Anton Vorontsov
2009-03-27 8:07 ` Wolfgang Grandegger
2009-03-27 8:07 ` Wolfgang Grandegger
2009-03-25 15:01 ` [PATCH v3 2/4] NAND: FSL-UPM: Add wait flags to support board/chip specific delays Anton Vorontsov
2009-03-25 10:43 ` [PATCH v3 1/4] NAND: FSL-UPM: add multi chip support Singh, Vimal
2009-03-25 10:43 ` Singh, Vimal
2009-03-25 10:57 ` Wolfgang Grandegger
2009-03-25 10:57 ` Wolfgang Grandegger
2009-03-25 13:31 ` Grant Likely
2009-03-25 13:31 ` Grant Likely
2009-03-25 13:32 ` Grant Likely
2009-03-25 13:32 ` Grant Likely
2009-03-25 13:32 ` Grant Likely
2009-03-25 13:43 ` Wolfgang Grandegger
2009-03-25 17:26 ` Grant Likely
2009-03-25 17:26 ` Grant Likely
2009-03-25 17:26 ` Grant Likely
2009-03-25 14:57 ` Anton Vorontsov
2009-03-25 15:25 ` Wolfgang Grandegger
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=49CB31CB.2010704@grandegger.com \
--to=wg@grandegger.com \
--cc=devicetree-discuss@ozlabs.org \
--cc=grant.likely@secretlab.ca \
--cc=linux-mtd@lists.infradead.org \
--cc=linuxppc-dev@ozlabs.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 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.