Oh, the many joys of MTD...

Oh, the many joys of MTD...

[Kevin Jacobs]

Hello everyone!

  I'm new to working on MTD and would like to start by thanking everyone who
has contributed to it.  Its a fine addition to Linux and has made my life
much easier.  However, I am having a few problems and was hoping for some
kinds souls to enlighten me a little.

Let me also say that I am somewhat new to hardware driver development and
have some rather odd gaps in my knowledge.

My first questions is likely something fairly basic.  I've read over much of
the MTD source and it seems that many of the erase and write functions do
not deal with concurrent access and CPU cache issues.  What happens when a
{read,write,erase} request comes in for a sector that is being
{written,erased}?

Also, is it assumed that the memory mapped for MTD devices will not be
cached by the CPU?  If so, is it feasible to add support.  If not, where is
code to flush/update the cache after a write or erase operation?

Thanks,
-Kevin

--
Kevin Jacobs
The OPAL Group - Enterprise Systems Architect
Voice: (216) 986-0710 x 19         E-mail: jacobs@theopalgroup.com
Fax:   (216) 986-0714              WWW:    http://www.theopalgroup.com




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Oh, the many joys of MTD...

[David Woodhouse]

jacobs@penguin.theopalgroup.com said:
>  My first questions is likely something fairly basic.  I've read over
> much of the MTD source and it seems that many of the erase and write
> functions do not deal with concurrent access and CPU cache issues.
> What happens when a {read,write,erase} request comes in for a sector
> that is being {written,erased}?

See the state machine in cfi_cmdset_000[12].c. We wait until the operation 
which is currently in progress has completed. Theoretical support for 
interruption of erases and writes is there, but it's not yet implemented.

> Also, is it assumed that the memory mapped for MTD devices will not be
> cached by the CPU?  If so, is it feasible to add support.  If not,
> where is code to flush/update the cache after a write or erase
> operation? 

It's assumed that it won't be cached, you are correct. 

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Oh, the many joys of MTD...

[Kevin Jacobs]

On Thu, 8 Mar 2001, David Woodhouse wrote:
> jacobs@penguin.theopalgroup.com said:
> >  My first questions is likely something fairly basic.  I've read over
> > much of the MTD source and it seems that many of the erase and write
> > functions do not deal with concurrent access and CPU cache issues.
> > What happens when a {read,write,erase} request comes in for a sector
> > that is being {written,erased}?
> 
> See the state machine in cfi_cmdset_000[12].c. We wait until the operation 
> which is currently in progress has completed. Theoretical support for 
> interruption of erases and writes is there, but it's not yet implemented.

That seems to be a feature of the cfi_cmdset_* but not of jedec.c,
amd_flash.c, among others.


> > Also, is it assumed that the memory mapped for MTD devices will not be
> > cached by the CPU?  If so, is it feasible to add support.  If not,
> > where is code to flush/update the cache after a write or erase
> > operation? 
> 
> It's assumed that it won't be cached, you are correct. 

If a flash device was cached then writes should be fine, correct?  Erase
operations would require Writing 0xFF to erased sectors should make the
cache coherent, right?

-Kevin

--
Kevin Jacobs
The OPAL Group - Enterprise Systems Architect
Voice: (216) 986-0710 x 19         E-mail: jacobs@the
Fax:   (216) 986-0714              WWW:    http://www.theopalgroup.com




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Oh, the many joys of MTD...

[Nicolas Pitre]

On Thu, 8 Mar 2001, Kevin Jacobs wrote:

> Hello everyone!
>
>   I'm new to working on MTD and would like to start by thanking everyone who
> has contributed to it.  Its a fine addition to Linux and has made my life
> much easier.  However, I am having a few problems and was hoping for some
> kinds souls to enlighten me a little.
>
> Let me also say that I am somewhat new to hardware driver development and
> have some rather odd gaps in my knowledge.
>
> My first questions is likely something fairly basic.  I've read over much of
> the MTD source and it seems that many of the erase and write functions do
> not deal with concurrent access and CPU cache issues.  What happens when a
> {read,write,erase} request comes in for a sector that is being
> {written,erased}?

Those are exclusively protected by state machines and locks.  For example,
see the usage of chip->state in cfi_cmdset_0001.c.

> Also, is it assumed that the memory mapped for MTD devices will not be
> cached by the CPU?  If so, is it feasible to add support.  If not, where is
> code to flush/update the cache after a write or erase operation?

The device mapping is done with the ioremap() call which is responsible for
providing a non-cacheable mapping.


Nicolas



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Oh, the many joys of MTD...

[Kevin Jacobs]

On Thu, 8 Mar 2001, Nicolas Pitre wrote:
> > My first questions is likely something fairly basic.  I've read over much of
> > the MTD source and it seems that many of the erase and write functions do
> > not deal with concurrent access and CPU cache issues.  What happens when a
> > {read,write,erase} request comes in for a sector that is being
> > {written,erased}?
> 
> Those are exclusively protected by state machines and locks.  For example,
> see the usage of chip->state in cfi_cmdset_0001.c.

Only cfi_cmdset_* does this.  jedec, amd_flash, etc. do not.

> 
> > Also, is it assumed that the memory mapped for MTD devices will not be
> > cached by the CPU?  If so, is it feasible to add support.  If not, where is
> > code to flush/update the cache after a write or erase operation?
> 
> The device mapping is done with the ioremap() call which is responsible for
> providing a non-cacheable mapping.

Then what does ioremap_nocache do?

-Kevin



--
Kevin Jacobs
The OPAL Group - Enterprise Systems Architect
Voice: (216) 986-0710 x 19         E-mail: jacobs@theopalgroup.com
Fax:   (216) 986-0714              WWW:    http://www.theopalgroup.com




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Oh, the many joys of MTD...

[Vipin Malik]

>
> The device mapping is done with the ioremap() call which is responsible for
> providing a non-cacheable mapping.

Actually I had to use ioremap_nocache() call with my ELANSC520 processor (which
has a processor I&D cache).
This is even with caching actually disabled for the flash banks inside the
processor (by the startup processor init code).

Does ioremap() do any caching of it's own? What's the diff between the two?

Vipin




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Oh, the many joys of MTD...

[Kevin Jacobs]

On Thu, 8 Mar 2001, Vipin Malik wrote:
> > The device mapping is done with the ioremap() call which is responsible for
> > providing a non-cacheable mapping.
> 
> Actually I had to use ioremap_nocache() call with my ELANSC520 processor
> (which has a processor I&D cache). This is even with caching actually
> disabled for the flash banks inside the processor (by the startup
> processor init code).

This is exactly the configuration I have -- its a Lineo SecureEdge (NETtel)
2580 which is based on an AMD Elan SC520 chip.

> Does ioremap() do any caching of it's own? What's the diff between the two?

The difference is:

extern inline void * ioremap (unsigned long offset, unsigned long size)
{
        return __ioremap(offset, size, 0);
}

and 

extern inline void * ioremap_nocache (unsigned long offset, unsigned long size)
{
        return __ioremap(offset, size, _PAGE_PCD);
}

This in turn adds _PAGE_PCD to the set_pte() call in __ioremap.  This turns
off the page cache for the mapped area.  I'm still not sure why this matters
though I think its inspired me to re-read the literature on the fiddly bits
of i386 architecture.

-Kevin

--
Kevin Jacobs
The OPAL Group - Enterprise Systems Architect
Voice: (216) 986-0710 x 19         E-mail: jacobs@theopalgroup.com
Fax:   (216) 986-0714              WWW:    http://www.theopalgroup.com




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Oh, the many joys of MTD...

[Alice Hennessy]

Kevin Jacobs wrote:

> On Thu, 8 Mar 2001, Vipin Malik wrote:
> > > The device mapping is done with the ioremap() call which is responsible for
> > > providing a non-cacheable mapping.
> >
> > Actually I had to use ioremap_nocache() call with my ELANSC520 processor
> > (which has a processor I&D cache). This is even with caching actually
> > disabled for the flash banks inside the processor (by the startup
> > processor init code).
>
> This is exactly the configuration I have -- its a Lineo SecureEdge (NETtel)
> 2580 which is based on an AMD Elan SC520 chip.
>
> > Does ioremap() do any caching of it's own? What's the diff between the two?
>
> The difference is:
>
> extern inline void * ioremap (unsigned long offset, unsigned long size)
> {
>         return __ioremap(offset, size, 0);
> }
>
> and
>
> extern inline void * ioremap_nocache (unsigned long offset, unsigned long size)
> {
>         return __ioremap(offset, size, _PAGE_PCD);
> }
>
> This in turn adds _PAGE_PCD to the set_pte() call in __ioremap.  This turns
> off the page cache for the mapped area.  I'm still not sure why this matters
> though I think its inspired me to re-read the literature on the fiddly bits
> of i386 architecture.
>
> -Kevin
>
> --
> Kevin Jacobs
> The OPAL Group - Enterprise Systems Architect
> Voice: (216) 986-0710 x 19         E-mail: jacobs@theopalgroup.com
> Fax:   (216) 986-0714              WWW:    http://www.theopalgroup.com
>
> To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Looks like ioremap is implemented inconsistently over the architectures.  Both
mips
and ppc return no-cache addresses for ioremap at the moment.  i386 looks like it
doesn't.
Perhaps ioremap_nocache is the way to go.

Alice




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Oh, the many joys of MTD...

[Robert Kaiser]

On Don, 08 Mär 2001 you wrote:
> >
> > The device mapping is done with the ioremap() call which is responsible for
> > providing a non-cacheable mapping.
> 
> Actually I had to use ioremap_nocache() call with my ELANSC520 processor (which
> has a processor I&D cache).

Strange, I had just the opposite experience here. I'm using the SC520 CDP board.

> This is even with caching actually disabled for the flash banks inside the
> processor (by the startup processor init code).

My board's BIOS provides options to enable/disable write buffering and to
set cache operation to write-back/write-through. No matter how I set these,
the mtd code always seemed to work, even if I used plain ioremap() . The SC520
has a set of PAR registers which allow to set individual cachability attributes
for ROM (i.e. chips that are selected by the ROMCS[12] and BOOTCS signals).
These are always set to non-cacheable by my BIOS. Then there are also the
cacheability attributes in the page table (this is what ioremap()  and
ioremap_nocache() differ in).

So there are several obscure places where one can enable/disable cacheing for
a given address region  on an SC520. Question is which of them takes
precedence in case they contradict.

Nevertheless, since everybody seems to agree that FlashROM needs to be
non-cached for the MTD code to work, I guess it's safer to generally use
ioremap_nocache().

Rob

----------------------------------------------------------------
Robert Kaiser                         email: rkaiser@sysgo.de
SYSGO RTS GmbH
Am Pfaffenstein 14                    phone: (49) 6136 9948-762
D-55270 Klein-Winternheim / Germany   fax:   (49) 6136 9948-10


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

RE: Oh, the many joys of MTD...

[Jonas Holmberg]

> On Thu, 8 Mar 2001, Nicolas Pitre wrote:
> > > My first questions is likely something fairly basic.  
> I've read over much of
> > > the MTD source and it seems that many of the erase and 
> write functions do
> > > not deal with concurrent access and CPU cache issues.  
> What happens when a
> > > {read,write,erase} request comes in for a sector that is being
> > > {written,erased}?
> > 
> > Those are exclusively protected by state machines and 
> locks.  For example,
> > see the usage of chip->state in cfi_cmdset_0001.c.
> 
> Only cfi_cmdset_* does this.  jedec, amd_flash, etc. do not.

amd_flash: I think it does (or have you found a bug?).

/Jonas


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org