On Mon, Nov 30, 2009 at 02:10:29PM +1100, Finn Thain wrote:
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@xxxxxxxxxxxxxxxxxxxx on
this sort of topic.
I think that is an alias for linux-m68k@xxxxxxxxxxxxxxx
I've added the CC.
Yes, it should be the same. I just copied that from some other email
that made it to the list.
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.
I think the right way to do it is to actually register ranges into a
generic framework with their properties (byte swap needed, real base
address for MMIO mappings) to allocate the in/out ranges. Then have
the macros in io.h call into the functions to lookup the entry in
the table and pass through to the right real range. I'm sure that
somebody will disagree, but it seems reasonable to me.
It appears that my Farallon Etherwave card has issues with byte ordering
(smc91c92_cs driver) when used with Diego's TRex patch.
I have a Macsense MPC-10, but I haven't actually tried it with the Linux
PCMCIA stack to know what driver could use it. Most likely the byte
order issues are generic, and the card being used originally wasn't
sensitive to byte order. I haven't looked at either driver. It's
possible that one or the other driver doesn't use the byte swap
operations it should be using. I'm not 100% sure what the proper usage
is for the APIs of the PCMCIA core.
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?
I'm not sure I understand enough of the PCMCIA core code to comment on
this. I'll have to read some more code to be useful there.
Brad Boyer
flar@xxxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
