Re: Adding PCMCIA support to the kernel tree -- developers needed.

[David Woodhouse <dwmw2@infradead.org>]

Upon further reflection (and OK, maybe a cup of tea or two), I think I am
going to try to abstract the bus access functions. 

Rather than making pcmcia_enable_{device,resource} visible to the core 
code and card drivers to enable mapping of certain resources to the host,  
this should probably be handled internally to the socket driver.

Not everything nowadays is an i82365, the bridge chip the PCMCIA spec 
appears to have been written for. Many of the interesting toys I've 
encountered recently don't have to muck about with remapping address 
ranges - the SH3 expects you to map Area 5 and 6 to PCMCIA sockets and the 
IO/attribute lines are taken from the higher bits of the address. 

So the socket drivers should provide access functions for the socket's
address ranges - {attr,mem,io}_{read,write}{8,16,32} and
{attr,mem,io}_copy{to,from}. Mostly, they'll be a simple case of adding an
offset to the requested address and doing the requested operation.

For the now degenerate case where the bridge has to be configured to map
certain addresses, that can be handled internally to the socket driver
reasonably efficiently. The common case will be that the functions will
check, find that there's a window currently pointing at the right place,
and will use it. Sometimes they'll need to change one of the windows to
point at the requested address - but not often. 

I spent a long time trying to avoid this abstraction in the MTD code,
before someone eventually convinced me that unconditional branches really
aren't that difficult for modern CPUs to predict, and the increased
simplicity of the 'map' abstraction was better.

-- 
dwmw2




_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel