mtd/html/tech faq.html,1.2,1.3

[joern at infradead.org]

Update of /home/cvs/mtd/html/tech
In directory phoenix.infradead.org:/home/joern/mtd/html/tech

Modified Files:
	faq.html 
Log Message:
explained point() and unpoint()


Index: faq.html
===================================================================
RCS file: /home/cvs/mtd/html/tech/faq.html,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- faq.html	15 Feb 2005 18:43:51 -0000	1.2
+++ faq.html	18 Feb 2005 15:20:18 -0000	1.3
@@ -23,6 +23,20 @@
 <p>Flash doesn't match the description of either block or character devices.  They behave similar to block device, but have differences.  For example, block devices don't destinguish between write and erase operations.  Therefore, a special device type to match flash characteristics was created: mtd.</p>
 <p>So mtd is neither a block nor a char device.  There are translations to use them, as if they were.  But those translations are nowhere near the original, just like translated chinese poems.</p>
 
+<h4>What are the point() and unpoint() functions used for ?</h4>
+<p>Mainly for NOR flash.  As long as the flash is only read, it
+behaves just like normal memory.  The read() function for NOR chips is
+essentially a memcpy().  For some purposes the extra memcpy() is a
+waste of time, so things can be optimized.</p>
+<p>So the point() function does just that, it returns a pointer to the
+raw flash, so callers can operate directly on the flash.</p>
+<p>But of course, things are a little more complicated than that.  NOR
+flash chips can be in several different modes and only when in read
+mode will the above work.  Therefore point() also locks the flash chip
+in addition to returning a pointer.  And while locked, writes to the
+same flash chips have to wait.  So callers have to call unpoint() soon
+after to release the chip again.</p>
+
 <h2>NAND specific</h2>
 <h4>Can I boot from NAND Flash?</h4>
 <p>Not from a bare NAND chip. You need a glue logic around, which gives you memory access to the