Anton Vorontsov wrote:

On Wed, Apr 30, 2008 at 03:19:37PM +0200, Wolfgang Grandegger wrote:

quoted

Anton Vorontsov wrote:

quoted

On Wed, Apr 30, 2008 at 10:36:54AM +0200, Wolfgang Grandegger wrote:

quoted

Hi Anton,

[...]

quoted

quoted

+	upm@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@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.

quoted

- - - -
From: Anton Vorontsov <redacted>
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:

Too bad you need this. Oh well, you need to discuss property name with
the OF guys, or think out some other way to deliver the chip delay
value.

OK.

quoted

  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?

I did test this driver on MPC8555 and MPC8360 UPMs. They didn't need
these syncs.. quite suspicious syncs, I must say. Maybe you should
check TLB setup, for the UPM NAND it should be non-cacheable and
guarded, IIRC.

I have that. Are you sure about the e500 CPUs. I have not seen any
MPC85xx board in U-Boot or Linux BSP using FSL UPM. Sometimes these
magic sync instructions seem to be needed, e.g., in the MPC8548 manual I
find:

  "Also, an msync assembly instruction must be executed after each I2C
   register read/write access to guarantee in-order execution."

Can somebody (from freescale?) sched some light on that issue?

TIA.

Wolfgang.