cfi_cmdset_0001 get_chip()put_chip() contender/loaner, what does it do?

Nicolas Pitre nico at cam.org
Tue Jun 12 11:45:38 EDT 2007


On Tue, 12 Jun 2007, Joakim Tjernlund wrote:

> On Tue, 2007-06-12 at 10:50 -0400, Nicolas Pitre wrote:
> > On Tue, 12 Jun 2007, Joakim Tjernlund wrote:
> > 
> > > In the beginning of get_chip() and put_chip for the cfi_cmdset_0001
> > > driver there is this "fight" over access to the chip that I don't
> > > understand. Why is it there and why don't the other drivers need it?
> > 
> > It is there to support the Intel Sibley NOR flash chips which have the 
> > ability to allow read operations in many part of the chip at the same 
> > time as an erase or a write operation taking place in another part of 
> > the chip.  The erase and write operation, though, cannot have more than 
> > one instance on the whole chip.
> > 
> > To facilitate the driver implementation, the Sibley flash is subdivided 
> > in many "chips" corresponding to those parts mentioned above.  However, 
> > since the ability to write is shared amongst all those "chips" then it 
> > sometimes must be obtained from another chip.  The other chip might 
> > concede it or it might not.  That's the "fighting".
> 
> I see, the reason for me asking about this is that I am seeing some
> very long stalls, see the "JFFS2 appears to "freeze" during erase,
> version 2" thread and I am starting to suspect the above mentioned code,
> mostly because I don't understand this code and don't know where else
> to look. Do you see anything that could explain what I am seeing?

Do you have Sibley flash?

If no then chip->priv will be false and you need no worry about that 
code.

If you do have Sibley flash then I strongly suggest that you go have a 
look at its data sheet to understand how it works.


Nicolas



More information about the linux-mtd mailing list