[PATCH 6/6] [POWERPC] booting-without-of: add FHCI USB, FSL MCU, FSL UPM and GPIO LEDs bindings

Wolfgang Grandegger wg at grandegger.com
Wed Apr 30 23:19:37 EST 2008


Anton Vorontsov wrote:
> On Wed, Apr 30, 2008 at 10:36:54AM +0200, Wolfgang Grandegger wrote:
>> Hi Anton,
> [...]
>>> +	upm at 1,0 {
>>> +		#address-cells = <0>;
>>> +		#size-cells = <0>;
>>> +		compatible = "fsl,upm-nand";
>>> +		reg = <1 0 1>;
>>> +		fsl,upm-addr-offset = <16>;
>>> +		fsl,upm-cmd-offset = <8>;
>>> +		gpios = <&qe_pio_e 18 0>;
>>> +
>>> +		flash {
>>> +			#address-cells = <1>;
>>> +			#size-cells = <1>;
>>> +			compatible = "stmicro,NAND512W3A2BN6E";
>>> +
>>> +			partition at 0 {
>>> +				...
>>> +			};
>>> +		};
>>> +	};
>> Where can I find the code for that binding? fsl_upm_nand.c from
>> http://patchwork.ozlabs.org/linuxppc/patch?q=upm&id=17306 does not parse
>> OF partitions. Are there any plans to push the fsl_upm_nand driver
>> upstream?
> 
> David already pushed UPM NAND driver upstream, but true, it was an "old"
> version, i.e. without approved bindings. I'll send the update (inlining
> here) if/when these bindings will be applied to the powerpc tree.

OK, thanks a lot.

> - - - -
> From: Anton Vorontsov <avorontsov at ru.mvista.com>
> Subject: [NAND] update FSL UPM NAND driver for the new OF bindings
> 
> - get rid of fsl,wait-pattern and fsl,wait-write. I think this isn't
>   chip-specific, and we should always do waits. I saw one board that
>   didn't need fsl,wait-pattern, but I assume it was exception that
>   proves general rule;
> - get rid of chip-delay. Today there are no users for this, and if
>   anyone really need this they should push the OF bindings beforehand;
> - Now flash chips should be child nodes of the FSL UPM nand controller;
> - Implement OF partition parsing.

On what hardware did you test the NAND-UPM driver? Unfortunately, the
TQM8548 does not support the R/B pin and therefore GPIO support is not
needed but a chip delay. Furthermore some "asm sync" are required when
executing the run pattern:

  static inline int fsl_upm_run_pattern(struct fsl_upm *upm,
                                        void __iomem *io_base, u32 mar)
  {
        int ret = 0, i;
        unsigned long flags;

        spin_lock_irqsave(&fsl_lbc_lock, flags);

        out_be32(&fsl_lbc_regs->mar, mar << (32 - upm->width));

        asm("sync; isync; msync");

        switch (upm->width) {
        case 8:
                out_8(io_base, 0x0);
                break;
        case 16:
                out_be16(io_base, 0x0);
                break;
        case 32:
                out_be32(io_base, 0x0);
                break;
        default:
                ret = -EINVAL;
                break;
        }

        asm("sync; isync; msync");

        spin_unlock_irqrestore(&fsl_lbc_lock, flags);

        return ret;
  }


Is this a known problem with the MPC85xx? How do we handle it?

Wolfgang.




More information about the Linuxppc-dev mailing list