Anton Vorontsov wrote:
> On Wed, Apr 30, 2008 at 03:19:37PM +0200, Wolfgang Grandegger wrote:
>> Anton Vorontsov wrote:
>>> On Wed, Apr 30, 2008 at 10:36:54AM +0200, Wolfgang Grandegger wrote:
>>>> Hi Anton,
>>> [...]
>>>>> + [EMAIL PROTECTED],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";
>>>>> +
>>>>> + [EMAIL PROTECTED] {
>>>>> + ...
>>>>> + };
>>>>> + };
>>>>> + };
>>>> 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 <[EMAIL PROTECTED]>
>>> 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.
>> 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.
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
