[RFC/PATCH] map drivers. DCACHE option for physmap and mphysmap drivers

[Alexey, Korolev]

Jared, Josh

I looked at the map.h code. There is the only one function which 
operates cached regions. It is map_copy_from function.
This function is used for read operations only for almost all flash 
devices.
I found the only device driver which uses map_copy_from for write. It is 
AMDSTD device driver.
Josh I can bet that the cache write issues you faced were on AMDSTD 
devices. All other devices use cached regions in read only mode.
AMDSTD is obsolete and depends on CONFIG_BROKEN.
So functionally we can guarantee read only mode for cache. We can avoid 
data Cache mappings for AMDSTD or fix driver or do nothing because it's 
obsolete.

Nicolas,

Non standardized cache invalidation and mapping is a big issue for the 
kernel. I guess it's possible to provide universal interface for cahce 
operating. I don't think that it is a reason why we have to decline 
cache mapping for flash devices. I think eventually cache interfaces 
will be stadartized. I think we can do this for the first time for the 
ARM platforms. Solution with physmap and mphysmap are very flexible. For 
example we have platforms where the flash type, number of flash devices, 
band width, and map size may vary. The only good solution for these 
cases are physmap and mphysmap drivers.

Thanks,
Alexey

> On 1/27/06, Nicolas Pitre <nico at cam.org> wrote:
> > On Fri, 27 Jan 2006, Josh Boyer wrote:
> >
> > > On 1/27/06, Jared Hulbert <jaredeh at gmail.com> wrote:
> > > > When I first did a patch like this I used a very platform dependent
> > > > embedded assembly loop to _invalidate_ NOT _flush_ the specific
> > > > cachelines possibly affected by the flash program or erase.
> > >
> > > Yep, that would be better.
> >
> > No it wouldn't.  It would quickly become crufty and unreadable as more
> > architectures add their stuff.
>
> /me sighs.
>
> Yes, I misread what Jared had said.  I was solely focusing on
> "_invalidate_ NOT _flush_" and missed the embedded assembly loop part.
>
> I think you're probably right in that there is no clean way to do this
> in a non-platform specific driver.  At least not a way that would be
> worthwhile.
>
> josh
>