Re: First steps towards PCMCIA support on the PB190

[Finn Thain <fthain@telegraphics.com.au>]

On Fri, 27 Nov 2009, Brad Boyer wrote:

> 
> Just as a note, I never saw the original message come across the mailing 
> list. Also, you might want to include linux-m68k@lists.linux-m68k.org on 
> this sort of topic.

I think that is an alias for linux-m68k@vger.kernel.org
I've added the CC.

> 
> On Tue, Nov 24, 2009 at 07:01:30PM -0200, diego wrote:
> 
> ...
> > There are mainly three problems l'm facing here.... The first two 
> > should be fairly easy to work out, whereas the 3rd represents a major 
> > roadblock at the moment:
> > 
> > 1. Proper mac specific definitions that wrap around ISA bus access.
> > 
> > 2. If you look at the patches to the orinoco driver, you will see that 
> > there's another enemy hiding, his name is ioport_map.
> 
> These should be relatively simple. We need to clean up some of that 
> stuff anyway. It's just a matter of taking the time to do it right. This 
> is the sort of thing that ought to be handled better in the common code 
> anyway.

Any suggestions on what needs to be done here, i.e. what needs clean up 
and what is the right way to do it? How much code is affected?

I know that the inb/outb/etc routines have come up often WRT m68k drivers, 
e.g. byteswapping on atari and so on. But I never really understood the 
issues.

It appears that my Farallon Etherwave card has issues with byte ordering 
(smc91c92_cs driver) when used with Diego's TRex patch.
 
> > 3. This has already been haunting the driver in the nubus-ppc project, 
> > and I couldn't come up with anything better either: I can't figure out 
> > how to make the TREX chip use IO memory and attribute memory 
> > simultaneously. From the little docs provided by apple it appears that 
> > it would be possible, then again they don't provide any documentation 
> > on how this chip works at the register level. The original author of 
> > the driver did find out how to switch between the two modes, but this 
> > requires the ugly patches to pcmcia_resource.c to, which in turn makes 
> > it impossible to merge this into an all-arch kernel tree. This wasn't 
> > a problem for the nubus-ppc port since they maintained their own 
> > development tree, but obviously in the case of m68k this would 
> > represent a major problem. Another thing is that it breaks some 
> > drivers that implement more exotic features like requesting card 
> > configuration changes etc.. If anyone happens to know how to program 
> > the TREX chip to use both attribute and IO mem simultaneously then 
> > this wouldn['t be an issue anymore. The alternative would be to 
> > convince the pcmcia core maintainers to have mercy with cards that 
> > need switching between these modes, but I doubt that this is a 
> > realistic alternative.

Can the switch be done with a fault handler? That is, does I/O generate an 
exception that can be used to switch the memory to I/O mode so that the 
access can be restarted? Can all attribute accesses explicitly switch to 
attribute mode within the constraints of the pcmcia core?

Finn