From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Woodhouse Date: Sun, 04 Feb 2001 11:37:07 +0000 Subject: Re: Adding PCMCIA support to the kernel tree -- developers needed. Message-Id: List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.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