RS/6000 device driver

[Lars Soltau]

In article <1991Apr9.131843.4409 at dartvax.dartmouth.edu> rj0q at eleazar.dartmouth.edu (Rodney D. Jacobson) writes:
[...]
>We have made a little progress on getting the Targa+ card to work in the
>rs/6000, but some issues remain.  Satya Rao of IBM Austin sent us some code
>which shows how a user process can read and write to the mca POS registers and
>to registers on the board.  This works and we can verify that the Targa board
>has the id it's supposed to and that we can read and write i/o registers on
>the board.
>
>
>The remaining problems are:
>
>1. how to read and write to Targa memory.
>
I can't help you there. I suppose this is only possible in the kernel
environment.

>2. how to insure that we do not set Targa i/o and memory locations on
>top of those used by other boards on the system.

Look up "Writing a [Define|Configuration] Method" in the Kernel Extensions
Programming Concepts. It made things a lot clearer for me.

As far as I have been able to deduce from the manual, for each possible MCA
card there exists an object in the PdDv class, with class="adapter",
subclass="mca" and type=<name of card>. So first you have to create this entry
in the PdDv class for your card. The define method, /etc/methods/define, is
able to handle every mca card, so you only have to enter this method into the
object as define method. At boot time, the system checks all mca slots and
reads the POS id. Then it searches for an entry in PdDv with this device ID
and calls the define method of that object, if one is found. This method
creates an object in CuDv with the actual location of the card (the slot
number).

>Issue 1 is the biggest mystery to us at this point.  We can probably solve
>issues 2 by playing dungeons and dragons with info and odme, but some
>outside help would make things much easier.

You can leave the "dungeons and dragons" to the system. Another odm class,
PdAt, contains all possible attributes for all devices, among which are the
i/o address and interrupt level for the mca boards. In the manual it says that
you are to call a routine named "busresolve()", but no further documentation
about this routine is given. I assume that it checks all devices and then
chooses the right parameters. I don't know who actually sets these parameters
and who is supposed to enter them into the CuAt class.

If anyone has found further documentation about "busresolve()", please tell me
about it. By the way, the manual says that the configure method is supposed to
call "setleds()", but this routine is also not documented anywhere. I found
out by trial and error that it's "void setleds(int)".

>The track that Satya has sent us along is to use /dev/bus0 and ioctl()
>calls.

I am very much interested in all information you have got. Please mail me the
code fragment.

>As far as avoiding conflicts with other mca boards goes, it looks like we need
>to search through odme and figure out what devices  use what addresses.
> However I have not figured out an efficient way of telling what addresses are
>currently used.  I also have not figured out how to tell the system what
>addresses the Targa board will use with a given pos register setting.

You have to create one object in the PdAt class for each attribute of your
card, like i/o address or int level. Look at the entries for the hscsi or the
ethernet adapter, then it will become clear.

As I said above, avoiding conflicts is done by "busresolve()", but don't ask
me how exactly this thing works. Is it a bug that it's not in the manuals?
-- 
Lars Soltau	lso at softpro.stgt.sub.org
#include <stddiscl.h>