From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-out.m-online.net ([212.18.0.9]) by bombadil.infradead.org with esmtp (Exim 4.69 #1 (Red Hat Linux)) id 1LmkE5-0000Kc-DS for linux-mtd@lists.infradead.org; Thu, 26 Mar 2009 07:42:16 +0000 Message-ID: <49CB31CB.2010704@grandegger.com> Date: Thu, 26 Mar 2009 08:42:03 +0100 From: Wolfgang Grandegger MIME-Version: 1.0 To: Grant Likely Subject: Re: [PATCH v3 3/4] powerpc: NAND: FSL UPM: document new bindings References: <1237975701-23201-1-git-send-email-wg@grandegger.com> <1237975701-23201-2-git-send-email-wg@grandegger.com> <1237975701-23201-3-git-send-email-wg@grandegger.com> <1237975701-23201-4-git-send-email-wg@grandegger.com> <49CA9899.30604@grandegger.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: linuxppc-dev@ozlabs.org, devicetree-discuss list , linux-mtd@lists.infradead.org List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Grant Likely wrote: > On Wed, Mar 25, 2009 at 2:48 PM, Wolfgang Grandegger 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. >