[PATCHES] move code for !STATIC_MAP to extra module

[Russell King]

On Mon, Nov 08, 2004 at 01:51:18PM -0800, David Hinds wrote:
> On Mon, Nov 08, 2004 at 08:00:47PM +0000, Russell King wrote:
> > No it doesn't.  There isn't a resource allocator for statically mapped
> > sockets.
> > 
> > The "two drivers accessing the same IO address" problem is solved purely
> > by the drivers doing the request_region() call and checking the return
> > value.  PCMCIA is no different in this respect on static sockets from an
> > ISA or PCI device plugged into a socket.
> 
> Perhaps we are talking about two different problems.  The problem I am
> talking about cannot be solved by the client drivers.  Consider a dual
> function card where each client driver requires its own IO window.  Or
> one driver that requires several windows with different attributes, or
> several memory windows.

On ARM systems with statically mapped sockets you can only have one
setting for the whole IO mapping.  There are no windows what so ever.

> The core PCMCIA code must be able to assign
> non-overlapping resource ranges in response to these requests.  That
> requires some level of resource management at the socket level,
> whether the socket is static mapped or not.

If the socket is statically mapped, and you want to access the card IO
space at an offset of 0x3f8 and it decodes 16 address lines, then you
can only access that at a physical memory address of SOCKET_IO_BASE +
0x3f8 and no others.

Therefore, the statically mapped case has no need what so ever for any
resource management by the socket driver.

> This is a real bug and it has been reported to me on the ARM platform
> for multifunction IO cards with the 2.4 kernel PCMCIA drivers, though
> I didn't recognize it as such at the time.

There is a big bug in the PCMCIA subsystems with the handling of memory
"windows" where the PCMCIA interfaces assume that you can setup a virtual
address mapping and can then adjust the PCMCIA socket window to retarget
that virtual address mapping to different addresses on the card.  This
is not possible with ARM platforms, and this is the only issue I'm
aware of.

> The standalone drivers
> don't have this problem for IO windows; both the standalone and kernel
> drivers are broken for managing multiple memory windows.

The reasoning you've come out with unfortunately does not match my
understanding of how the hardware on ARM systems actually works, so
can you illustrate a scenario showing how the problem would arise
please?

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core