[PATCH v3 3/4] powerpc: NAND: FSL UPM: document new bindings

[Grant Likely]

On Thu, Mar 26, 2009 at 1:42 AM, Wolfgang Grandegger <wg at grandegger.com> wrote:
> Grant Likely wrote:
>> On Wed, Mar 25, 2009 at 2:48 PM, Wolfgang Grandegger <wg at 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.

Hold on a sec.  I'm debating from my experience with device tree
bindings, but I'm fairly ignorant about the implementation of NAND on
UPM.  It *looks* to me like reg is sufficient, but if I'm wrong then
tell me so and why.  Your comment above about fsl_upm_run_pattern()
makes me doubt my position.

Does using the reg property give the driver enough information to
reliably program the MAR for NAND connections that use the address
line chip select scheme?  Related to that, should the binding include
a property that explicitly states that an address line chip select
scheme is being used?

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.