Re: First steps towards PCMCIA support on the PB190
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
Reply to: