Tim Bessie wrote:

>         This bit of code loops forever, as the "if (send_string[0]..." condition
>         is always true.  That is, ADBNumDevices is constantly bumped up, and
>         it is always greater than 'i', and it loops forever.  Since ADBDevTable[]
>         is only 16-elements long, this is a problem anyway.  Does anyone
>         know why this might be happening?

Probably because the PB-specific routines that are called by the
adb_op_sync routine are not working right.

I would recommend NOT changing anything in adb_reinit. It is meant to be
ADB hardware independent. If there is a problem it is most likely
because the PB-specific routines aren't returning the expected data, and
so it's seeing an (inaccurately) increasing number of devices. Likewise,
adb_op_sync is intended to be called by ANY routine, regardless of what
type of ADB hardware you are running on. You can change things within
adb_op_sync, but to the caller it should always look the same. 

There are other pieces of code that are meant to be "ADB hardware
independent" as well. The hardware specific routines typically have the
hardware version tacked onto the end. For example, the Cuda version of
adb_send (or is it send_adb? I can't remember) is adb_send_cuda, and the
IIsi version is called adb_send_IIsi. And usually these routines have a
hardware-independent version, in this example, adb_send, that can be
called regardless of the hardware type so the calling routine doesn't
have to do all the "am I on machine xxx" logic.

I suspect that the routines that adb_op_sync, calls are not working
properly, or are not returning the data in the way adb_op_sync and
adb_reinit expects. I would look into why adb_op_sync and whatever it
calls is not behaving the same way the other ADB hardware routines (II,
IIsi, Cuda) are.

>            Looking at the code just now, I noticed that adb_intr() has no
>            code for case ADB_HW_PB.  Is this desired, or has it just happened
>            that nobody's written an interrupt routine for powerbooks?

The Powerbooks use pm_intr instead of adb_intr to catch the interrupts.
You should look through the pm_direct.c code for details.

Now, forget everything I said above about how adb_direct.c works.
Because the Power Manager (PM) routines are done differently. I know
Takashi Hamada (who wrote pm_direct.c) uses hooks in adb_direct.c and
there are some things in adb_direct.c that call PM routines, but I
really don't know how the PM stuff works. There were a lot of changes to
the adb_direct.c stuff in the last change, and they may have broken how
the PM code interacts with the adb_direct.c code. Although from reports
I get it seems that the PM code in the tree has not been working for
some time. (It may be my fault, regardless. :-( )

> Any suggestions for making this stuff work would be greatly
> appreciated.  I don't know anything about apple architecture,
> so writing ADB driver code is rather out of the question,
> unless somebody can point me in the direction of good
> documenation and/or give me a list of what code needs to
> be written at this point.

Hee hee. This is sort of funny. :-) You see, the problem is there really
IS no documentation except for what we have written. There are hints in
some Apple specs, and the MkLinux code does a decent job of showing how
the Cuda ADB hardware works, but other than that it's experiment, test,
guess, etc.

If you are interested in looking at fixing the pm_direct.c code, or
improving it, I'd suggest looking through it and perhaps contacting
Takashi himself. He probably has some insite on where to start looking.

	--John