Hi Mark,
On Tuesday 10 December 2013 11:59 PM, Mark Brown wrote:
On Tue, Dec 10, 2013 at 07:22:10PM +0100, Marek Vasut wrote:
On Tuesday, December 10, 2013 at 05:11:43 PM, Mark Brown wrote:
There is some stuff that pushes up into the controller in that while the
device is in memory mapped mode as far as I can tell it's not safe to do
other accesses so if someone's put more than one device on the SPI bus
we need to handle interactions there.
OK, so it's either-or . That seems OK, you might want to have two drivers for
this ip block, one to handle it as a SPI block and one to handle it as a SPI-NOR
block. ... that is of course, if these two modes can't work together.
Or the client disables the memory map when it's not actively being used
and the stops other transfers starting while the mapping is in place.
I'd expect we'll have to cope with shared use at some point, hardware
engineers will probably build such systems.
So, what I am doing here in my code is that whenever I desired to use a
mmap operations I do a
a. flash_lock()
b. wait till the previous erase/write is finished
c. 'get_buf' which in turn does
- get_sync
- enable memory mapped
d. memcpy
e. 'put_buf' which in turn does
- disable memory mapped
- put_sync
f. flash_unlock
Do you see any point missing here?
On your comment about disabling transfers while doing a mmap..
Are you suggesting on having a check in qspi transfer api something like
this..
transfer_one_message {
if (mmap)
return -EINPROGRESS;
}
Where mmap can be set/unset in get_buf/put_buf respectively.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
