[PATCHES] move code for !STATIC_MAP to extra module

[David Hinds]

On Mon, Nov 08, 2004 at 11:30:54PM +0000, Russell King wrote:
> > 
> > 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.

There is no physical windowing on the host side.  There is still the
notion of an IO window because cards do their own IO address decoding.

> > 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.

In your specific example... yes that's true.

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

Consider a dual port card that is PCMCIA MFC compliant.  The CIS says,
for each card function, that the card requires a block of 8 IO ports,
positioned at any base address.  It is the responsibility of the host
to choose two suitable ranges of 8 IO ports (which I am loosely
calling "windows" above), and after choosing these ranges, to write
the base addresses of the ranges to the card's IO base registers.

The client driver tells the PCMCIA core, "give me two blocks of 8 IO
ports, anywhere".  The PCMCIA core needs to satisfy both requests.
This is a (trivial) resource allocation problem, even in the static
map case: how to choose two ranges that don't conflict.  There is no
opportunity for the client driver to intervene and call request_region
between the two allocations.

Here is a related bug report, for a dual serial card on an iPAQ:

http://sourceforge.net/tracker/index.php?func=detail&aid=562976&group_id=2405&atid=102405

I admit, this is a pretty simple resource allocation problem (there
is at most one other IO window that the allocator has to worry about)

> > 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.

Mmm, forget everything I said about a problem with memory windows: I
was misremembering how this worked.  I also think your bug should not
apply, for properly written client drivers.  The interfaces do not
actually assume that memory addresses can be arbitrarily remapped,
though some drivers may.  The socket driver describes the mapping
granularity, and for static mapped sockets, that granularity can (and
should) be set to the size of the entire PCMCIA address space.  A
client driver can (and should) call RequestWindow with Size=0, which
means, give the smallest available window size, whatever that is.

So when a driver asks for a memory window, and finds out it has
received one that is 64MB in size, it will naturally never need to
remap that window.

-- Dave