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 [email protected] on > this sort of topic. I think that is an alias for [email protected] 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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
