How to exploit STS pin of Strata Flash

How to exploit STS pin of Strata Flash

[llandre]

Hi,

I have a question about STS pin of Strata Flash.
I'd like to implement a function in the low-level map driver
in order to exploit the STS pin to read the ready/busy
status (NAND-like).
How should I hack the code? It seems there is
no <board>_device_ready or something like that ...



TIA,

llandre

DAVE Electronics System House - R&D Department
web:   http://www.dave-tech.it
email: r&d2@dave-tech.it

Re: How to exploit STS pin of Strata Flash

[Jared Hulbert]

On Mon, 27 Dec 2004 12:23:18 +0100, llandre <r&d2@dave-tech.it> wrote:
> Hi,
> 
> I have a question about STS pin of Strata Flash.
> I'd like to implement a function in the low-level map driver
> in order to exploit the STS pin to read the ready/busy
> status (NAND-like).
> How should I hack the code? It seems there is
> no <board>_device_ready or something like that ...

Why?

How?  Connect it to a irq line?

Re: How to exploit STS pin of Strata Flash

[llandre]

> > I have a question about STS pin of Strata Flash.
> > I'd like to implement a function in the low-level map driver
> > in order to exploit the STS pin to read the ready/busy
> > status (NAND-like).
> > How should I hack the code? It seems there is
> > no <board>_device_ready or something like that ...
>
>Why?

To avoid the bus accesses to detect the end of erase/write operations.
This wastes a lot of bus bandwidth.


>How?  Connect it to a irq line?

Is this supported by MTD? How to enable this feature in the low-level driver?
I had a look at the existing drivers but it neems no one uses interrupt ...


Regards,

llandre

DAVE Electronics System House - R&D Department
web:   http://www.dave-tech.it
email: r&d2@dave-tech.it

Re: How to exploit STS pin of Strata Flash

[Jared Hulbert]

> To avoid the bus accesses to detect the end of erase/write operations.
> This wastes a lot of bus bandwidth.

I believe the current StrataFlash drivers actually sleep() for an
appropriate amount of time in both the write and erase routines.  I'm
not sure that they are actually going to be wasting that much useful
bus time.  I'm curious to know if you have any data to suggest this
bus usage has any significant impact on system performance.
 
> >How?  Connect it to a irq line?
> 
> Is this supported by MTD? How to enable this feature in the low-level driver?
> I had a look at the existing drivers but it neems no one uses interrupt ...

No.  I was just curious what you were thinking of.  It could be done. 
If you really think its worth it.

,Jared

Re: How to exploit STS pin of Strata Flash

[llandre]

> > To avoid the bus accesses to detect the end of erase/write operations.
> > This wastes a lot of bus bandwidth.
>
>I believe the current StrataFlash drivers actually sleep() for an
>appropriate amount of time in both the write and erase routines.  I'm
>not sure that they are actually going to be wasting that much useful
>bus time.  I'm curious to know if you have any data to suggest this
>bus usage has any significant impact on system performance.
>
> > >How?  Connect it to a irq line?
> >
> > Is this supported by MTD? How to enable this feature in the low-level 
> driver?
> > I had a look at the existing drivers but it neems no one uses interrupt ...
>
>No.  I was just curious what you were thinking of.  It could be done.
>If you really think its worth it.

Jared,

when I helped Thomas Gleixner to debug the code to support 2k-page NAND 
devices, I
discussed with him about this subject. For NAND chips there are three 
possibilities:
1) if the driver can not read the ready/busy pin, MTD waits the maximum 
delay required
by the device to perform such operations (this clearly reduces performance)
2) if the driver can read the ready/busy pin, MTD polls this pin in order to
detect the end of operation (no accesses on the bus)
3) if the ready/busy ping is connected to an IRQ line, the driver can 
"sleep" until
the processor receives an interrupt from the NAND (I never implemented this 
solution so far)

I don't know how NOR/Strata Flash drivers work and I thouhgt they implement
the well-known data polling algorithm to detect the end of operation.
However, if they actually "sleeps" as you pointed out, I
clearly am wrong. If I'm right instead, the data-polling algorithm wastes 
bandwidth
because it performs a lot of read accesses just to read the value of a bit.
This can lead to problems for example when you have a bus-demanding 
peripheral such
as a LCD controller. In this case the wasted bandwith can lead to flickering.
In conclusion, to avoid data-polling algorithm, it is possible to implement the
same ready/busy pin strategy used for NAND chips.


Regards,

llandre

DAVE Electronics System House - R&D Department
web:   http://www.dave-tech.it
email: r&d2@dave-tech.it

Re: How to exploit STS pin of Strata Flash

[Jared Hulbert]

> when I helped Thomas Gleixner to debug the code to support 2k-page NAND
> devices, I
> discussed with him about this subject. For NAND chips there are three
> possibilities:
> 1) if the driver can not read the ready/busy pin, MTD waits the maximum
> delay required
> by the device to perform such operations (this clearly reduces performance)
> 2) if the driver can read the ready/busy pin, MTD polls this pin in order to
> detect the end of operation (no accesses on the bus)
> 3) if the ready/busy ping is connected to an IRQ line, the driver can
> "sleep" until
> the processor receives an interrupt from the NAND (I never implemented this
> solution so far)

My biggest concern is this STS pin is not something supported on many
strataflash chips.   Though this might be an elegant solution for a
system with irq lines to spare using these particular chips I don't
think it would be used often enough to be supportable.

> I don't know how NOR/Strata Flash drivers work and I thouhgt they implement
> the well-known data polling algorithm to detect the end of operation.
> However, if they actually "sleeps" as you pointed out, I
> clearly am wrong. If I'm right instead, the data-polling algorithm wastes
> bandwidth
> because it performs a lot of read accesses just to read the value of a bit.

in 2.6.10 drivers/mtd/chips/
cfi_cmdset_0001.c:1065  sleeps for the word write if I understand
cfi_udelay() correctly
cfi_cmdset_0001.c:1308  sleeps for the buffered write if I understand
cfi_udelay() correctly
cfi_cmdset_0001.c:1470  sleeps for the erase

> This can lead to problems for example when you have a bus-demanding
> peripheral such
> as a LCD controller. In this case the wasted bandwith can lead to flickering.
> In conclusion, to avoid data-polling algorithm, it is possible to implement the
> same ready/busy pin strategy used for NAND chips.

I can imagine that happens, but does it?  I'm never been able to see
that kind of effect, have you?  Maybe the sleeps work good enough.  If
this sort of thing happens and we can prove it... well maybe we can
influence the chipheads who design this stuff.

,Jared

Re: How to exploit STS pin of Strata Flash

[llandre]

>My biggest concern is this STS pin is not something supported on many
>strataflash chips.   Though this might be an elegant solution for a
>system with irq lines to spare using these particular chips I don't
>think it would be used often enough to be supportable.

I see. So far I worked with Intel StrataFlash only.

> > I don't know how NOR/Strata Flash drivers work and I thouhgt they implement
> > the well-known data polling algorithm to detect the end of operation.
> > However, if they actually "sleeps" as you pointed out, I
> > clearly am wrong. If I'm right instead, the data-polling algorithm wastes
> > bandwidth
> > because it performs a lot of read accesses just to read the value of a bit.
>
>in 2.6.10 drivers/mtd/chips/
>cfi_cmdset_0001.c:1065  sleeps for the word write if I understand
>cfi_udelay() correctly
>cfi_cmdset_0001.c:1308  sleeps for the buffered write if I understand
>cfi_udelay() correctly
>cfi_cmdset_0001.c:1470  sleeps for the erase

Ok, so I was wrong.

> > This can lead to problems for example when you have a bus-demanding
> > peripheral such
> > as a LCD controller. In this case the wasted bandwith can lead to 
> flickering.
> > In conclusion, to avoid data-polling algorithm, it is possible to 
> implement the
> > same ready/busy pin strategy used for NAND chips.
>
>I can imagine that happens, but does it?  I'm never been able to see
>that kind of effect, have you?

Yes, I have encountered this problem with a Frescale MC9328MXL processor.
The flickering occurs when JFFS2 performs erase/write operations on the
StrataFlash. This happens with Linux 2.6 only. When running
Linux 2.4 LCD exhibits no flickering.




llandre

DAVE Electronics System House - R&D Department
web:   http://www.dave-tech.it
email: r&d2@dave-tech.it

Re: How to exploit STS pin of Strata Flash

[Jared Hulbert]

> I see. So far I worked with Intel StrataFlash only.

Even some new Intel StrataFlash does not have this pin.

> Yes, I have encountered this problem with a Frescale MC9328MXL processor.
> The flickering occurs when JFFS2 performs erase/write operations on the
> StrataFlash. This happens with Linux 2.6 only. When running
> Linux 2.4 LCD exhibits no flickering.

Uh oh.  Same bootloader, hardware and everything?  I wonder what
changed from 2.4 to 2.6 that would change that.

Anybody have any ideas?

Re: How to exploit STS pin of Strata Flash

[llandre]

Jared,

first of all happy new year!

>Even some new Intel StrataFlash does not have this pin.

I see.

> > Yes, I have encountered this problem with a Frescale MC9328MXL processor.
> > The flickering occurs when JFFS2 performs erase/write operations on the
> > StrataFlash. This happens with Linux 2.6 only. When running
> > Linux 2.4 LCD exhibits no flickering.
>
>Uh oh.  Same bootloader, hardware and everything?  I wonder what
>changed from 2.4 to 2.6 that would change that.

I encountered this problem several monts ago. I don't remember exactly
the configuration because JFFS2 has been temporarily used during software
development. After it has been abandoned, we "forgot" about the flickering.
I think I'll have the chance to have the hands on that project again in 2005.
In this case I'll compare the configuration with the one that works and
I'll post the differences.


Thanks for your cooperation and regards,

llandre

DAVE Electronics System House - R&D Department
web:   http://www.dave-tech.it
email: r&d2@dave-tech.it