[PATCH] via-cuda (CUDA_COMBINED_FORMAT_IIC)

[PATCH] via-cuda (CUDA_COMBINED_FORMAT_IIC)

[Iain Sandoe]

[-- Attachment #1: Type: text/plain, Size: 1412 bytes --]

hi,

Attached are:

1/ a patch that adds CUDA_COMBINED_FORMAT_IIC support (at the moment to
2.2.17 - although it should go into 2.4.0 relatively easily).  This allows
you to dump the contents of things on the i2c bus (where it is supported)
using via-cuda.

This has meant a modification of the cuda state machine, in the process I've
made it a bit more paranoid about passed params & buffer overflows etc.

This release has an amount of (ifdef'd) debugging printks that will be
removed if no-one reports any serious problems.

files patched:
   drivers/macintosh/via-cuda.c
   include/asm-ppc/adb.h
   include/asm-ppc/cuda.h

It also adds support for using cuda adb in xmon for 2.2.x (separate patch to
follow) - this is already done in 2.4.0.

2/  a small code fragment showing the use of the COMBINED_FORMAT_IIC command
(you *must* set the adb request reply length to limit what you want back -
since the cuda does not seem to stop sending voluntarily).

3/ the output of this when run on my G3-beige.

Unfortunately, the one chip I *really* want to probe (the TDA7433 on the
audio card -  i2c address 0x8a) doesn't seem to give a proper response... so
if anyone knows more about this - I'd be interested.

Patches against linuxcare linux-pmac-benh as of approx. 00:00 BST
29/09/2000.
Should be equally OK against linux-pmac-stable.

I'll post them on sourceforge linuxppc & update my web page later...

Iain.

[-- Attachment #2: i2c-probe.txt.bz2 --]
[-- Type: application/binary, Size: 937 bytes --]

[-- Attachment #3: cuda-combined-code-frag.txt.bz2 --]
[-- Type: application/binary, Size: 1102 bytes --]

[-- Attachment #4: cuda-CF-2-2-17p20b1-a.diff.bz2 --]
[-- Type: application/binary, Size: 7570 bytes --]

Re: [PATCH] via-cuda (CUDA_COMBINED_FORMAT_IIC)

[Michel Lanners]

Hi Iain,

On  30 Aug, this message from Iain Sandoe echoed through cyberspace:
> Unfortunately, the one chip I *really* want to probe (the TDA7433 on the
> audio card -  i2c address 0x8a) doesn't seem to give a proper response... so
> if anyone knows more about this - I'd be interested.

Hmm, are you sure it is actually attached to the CUDA's I2C bus? The
7x00/8x00 series have a video input chip on an I2C bus as well, but not
on CUDA... it's on PlanB, which includes its own I2C implementation. I
don't know about the sound chips in those boxes, however. My first bet
would be looking around AWACS if there is no I2C bus hidden there
somewhere.

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [PATCH] via-cuda (CUDA_COMBINED_FORMAT_IIC)

[Iain Sandoe]

Hi Michel,
On Wed, Aug 30, 2000, Michel Lanners wrote:
> On  30 Aug, this message from Iain Sandoe echoed through cyberspace:
>> Unfortunately, the one chip I *really* want to probe (the TDA7433 on the
>> audio card -  i2c address 0x8a) doesn't seem to give a proper response... so
>> if anyone knows more about this - I'd be interested.
>
> Hmm, are you sure it is actually attached to the CUDA's I2C bus? The
> 7x00/8x00 series have a video input chip on an I2C bus as well, but not
> on CUDA... it's on PlanB, which includes its own I2C implementation. I
> don't know about the sound chips in those boxes, however. My first bet
> would be looking around AWACS if there is no I2C bus hidden there
> somewhere.

Well, you could be right... I'm only going on Apple's h'ware docs (& the
existing Linux & Darwin drivers ;-).

The G3-beige has a perch slot and in the perch slot is one of three types of
card... all of these have either AWACS or Burgundy - but also a "tone
control" chip controlled by i2c.  The so called "tone control" chip does a
fair bit of the level & routing control (which is why I want to access it's
settings)

Apple's stuff from Darwin refers to this as an SGS7433 (and, after looking
at SGS/Thompson's web site) I came up with the TDA7433 which does the right
things.  It has i2c address 0x8a - which is the address that the dmasound
driver writes to to set the volume on g3-beige (using the GET_SET_IIC
command).

With the modified driver posted, the CUDA_COMBINED_FORMAT_IIC command
recognises that there is a device at address 0x8a - but returns all 0xff
bytes instead of the hoped for register contents :-(

I checked the TDA7433 data sheet and it should be able to do
COMBINED_FORMAT...

ah well...

Yes, there are different implementations for i2c on different models...
CUDA, PMU (PlanB and other mac-IO implementations).... and on the newer
machines "cereal" (and multiple i2c busses)...  if the ability to probe the
i2c bus is useful, I guess we'll have a few more drivers to update... :-)

Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [PATCH] via-cuda (CUDA_COMBINED_FORMAT_IIC)

[Michel Lanners]

Hi Iain,

> Hi Michel,
> The G3-beige has a perch slot and in the perch slot is one of three types of
> card... all of these have either AWACS or Burgundy - but also a "tone
> control" chip controlled by i2c.  The so called "tone control" chip does a
> fair bit of the level & routing control (which is why I want to access it's
> settings)
>
> Apple's stuff from Darwin refers to this as an SGS7433 (and, after looking
> at SGS/Thompson's web site) I came up with the TDA7433 which does the right
> things.  It has i2c address 0x8a - which is the address that the dmasound
> driver writes to to set the volume on g3-beige (using the GET_SET_IIC
> command).
>
> With the modified driver posted, the CUDA_COMBINED_FORMAT_IIC command
> recognises that there is a device at address 0x8a - but returns all 0xff
> bytes instead of the hoped for register contents :-(

Ah, ok. So you have been able to see the device... Are you sure that it does
return register contents? I'm no I2C specialist, but for PlanB, the video
chip on I2C can only return a single byte on a read request, not a stream of
data (like a register file). Also, that chip uses bit 0 of the address as
R/W flag, and, IIRC, bit 0 set to one indicates read. So, have you tried
reading from address 0x8b?

> I checked the TDA7433 data sheet and it should be able to do
> COMBINED_FORMAT...

What exactly is COMBINED_FORMAT?

> Yes, there are different implementations for i2c on different models...
> CUDA, PMU (PlanB and other mac-IO implementations).... and on the newer
> machines "cereal" (and multiple i2c busses)...  if the ability to probe the
> i2c bus is useful, I guess we'll have a few more drivers to update... :-)

We could even provide a generic I2C interface (isn't that available on i386
already?)... Give the different buses numbers, ala PCI, have a list of
devices found on the bus, etc... Wouldn't that be a nice overkill? ;-))


Michel
--
.sig home alone

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [PATCH] via-cuda (CUDA_COMBINED_FORMAT_IIC)

[Iain Sandoe]

Hi Michel,

>> With the modified driver posted, the CUDA_COMBINED_FORMAT_IIC command
>> recognises that there is a device at address 0x8a - but returns all 0xff
>> bytes instead of the hoped for register contents :-(
>
> Ah, ok. So you have been able to see the device... Are you sure that it does
> return register contents? I'm no I2C specialist, but for PlanB, the video
> chip on I2C can only return a single byte on a read request, not a stream of
> data (like a register file). Also, that chip uses bit 0 of the address as
> R/W flag, and, IIRC, bit 0 set to one indicates read. So, have you tried
> reading from address 0x8b?

I'm no i2c specialist either :-)  [just doing the Linux standard - learning
about it as a consequence of wanting to to something completely different]

The LSB being 1/0 (R/~W) is specified by the i2c standard.  The TDA7433
should be able to do auto-increment (by setting 0x10 as the sub-address).
However... I'm not sure (exactly) of the syntax of the
CUDA_COMBINED_FORMAT_IIC command - I posted darwin-dev... but no useful
replies.

>> I checked the TDA7433 data sheet and it should be able to do
>> COMBINED_FORMAT...
>
> What exactly is COMBINED_FORMAT?

Allows you to write to the chip followed by read (or vice versa) without
changing i2c bus mastership - so you do something like

aa ss <dd> aa|1  - which tells device aa that you want sub address ss (and
maybe want to write data <dd> and then you read it...

>From the name of the command - I might have thought that I could read the
regs with GET_SET_IIC - but I can't seem to make that work for any chip
address (the COMBINED_FORMAT_IIC *does* work for a number of the addresses).

>
>> Yes, there are different implementations for i2c on different models...
>> CUDA, PMU (PlanB and other mac-IO implementations).... and on the newer
>> machines "cereal" (and multiple i2c busses)...  if the ability to probe the
>> i2c bus is useful, I guess we'll have a few more drivers to update... :-)
>
> We could even provide a generic I2C interface (isn't that available on i386
> already?)... Give the different buses numbers, ala PCI, have a list of
> devices found on the bus, etc... Wouldn't that be a nice overkill? ;-))

A common method is a good idea (in spite of your smilie...)   At the moment
we have umpteen platform-dependent ways of doing power-down etc. etc.

Apple have a "Platform Expert" motif where you call PE_read_IIC() and it
buries the actual 'which driver' issue underneath...

Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [PATCH] via-cuda (CUDA_COMBINED_FORMAT_IIC)

[Geert Uytterhoeven]

On Wed, 30 Aug 2000, Michel Lanners wrote:
> > Yes, there are different implementations for i2c on different models...
> > CUDA, PMU (PlanB and other mac-IO implementations).... and on the newer
> > machines "cereal" (and multiple i2c busses)...  if the ability to probe the
> > i2c bus is useful, I guess we'll have a few more drivers to update... :-)
>
> We could even provide a generic I2C interface (isn't that available on i386
> already?)... Give the different buses numbers, ala PCI, have a list of
> devices found on the bus, etc... Wouldn't that be a nice overkill? ;-))

The generic i2c subsystem works (at least `used to work') on PPC as well. I
once wrote an i2c `driver' (something that can read from and write to 2 signal
lines, very very complex :-) for the Hydra Mac I/O and was able to read the SPD
(Serial Presence Detect) EEPROMs on my DIMMs. The code is not present in the
standard kernel tree, but it's part of the LM Sensors project (sorry, no URL
for it in my bookmarks file here).

Actually the generic i2c subsystem is quite powerful and layered nicely: it
supports all kind of i2c hardware, ranging from simple hardware banging
control lines to more intelligent dedicated i2c hardware. I'm quite sure a
driver for CUDA or PMU would easily fit in it.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [PATCH] via-cuda (CUDA_COMBINED_FORMAT_IIC)

[Iain Sandoe]

On Wed, Aug 30, 2000, Geert Uytterhoeven
> The generic i2c subsystem works (at least `used to work') on PPC as well. I
> once wrote an i2c `driver' (something that can read from and write to 2 signal
> lines, very very complex :-)

Well, today I wish I could get at SDA/SCL - because I think I would have a
working solution to my need (to read the TDA7433).

Maybe it's complex - or at least tedious - because of working within the OS
- but it is also specified by the i2c spec - so a solvable problem.

All the time on this patch has been spent second-guessing what the CUDA does
with its command packets... and at the end I still can't read the chip (lots
of info from the SPDs & other devices ;-)

CUDA is also on m68k? (I see some conditionals in the 2.4.0 stuff for
CONFIG_MAC)

I really would be very grateful if anyone has any more sources of info on
the command packets contents for it (CUDA)...

Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [PATCH] via-cuda (CUDA_COMBINED_FORMAT_IIC)

[David A. Gatwood]

On Wed, 30 Aug 2000, Iain Sandoe wrote:

> CUDA is also on m68k? (I see some conditionals in the 2.4.0 stuff for
> CONFIG_MAC)

Yeah.  AV Quadras, IIRC.  And the Q630 probably does (or at least its
descendents in the PPC line do).


> I really would be very grateful if anyone has any more sources of info
> on the command packets contents for it (CUDA)...

Like what sort of info, and what sort of command?


David

---------------------------------------------------------------------
A brief Haiku:

Microsoft is bad.
It seems secure at first glance.
Then you read your mail.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [PATCH] via-cuda (CUDA_COMBINED_FORMAT_IIC)

[Iain Sandoe]

On  Wed, Aug 30, 2000, David A. Gatwood wrote:
> On Wed, 30 Aug 2000, Iain Sandoe wrote:
>> I really would be very grateful if anyone has any more sources of info
>> on the command packets contents for it (CUDA)...
>
> Like what sort of info, and what sort of command?

OK. I want to read the contents of an I2c chip.
I checked the data sheet for the chip - it can do it.

I look in cuda.h - we have a command called CUDA_GET_SET_IIC - which is used
by the dmasound driver to set values in the chip.  The name implies I can
read values using it... but.. with the (several) permutations I tried
(guesswork) - no joy.

So then someone tells me that what I need is COMBINED_FORMAT_IIC - so I've
implemented it - which involves a re-jig of the CUDA state machine... this
is the patch.

I was very happy to see data streaming out of the i2c bus... and then very
disappointed that several devices (including the one I want) return nothing
but 0xff...

now the COMBINED_FORMAT_IIC command is of the form:

[0x01, 0x25] aa ?? aa|1

Looking at the i2c spec. ?? is probably the sub address (or the second byte
for a 10 bit address)... but when I try other than 00 in this - often the
CUDA becomes confused...   So I wonder whether there are different command
lengths I can try and, ....... many permutations (and re-boots) later I
conclude that:

00 is the only reliable working value for ??
COMBINED_FORMAT_IIC commands must be 5 bytes long (0x01, 0x25, aa, ??, aa|1)
or they do not work (or lock up the CUDA)...

**of course** I'm guessing and there could just be one bit I need to set
somewhere to make it work... but I've run out of time for trying random
permutations....

=====
In general...

The command works properly - when there is no i2c device on the bus it
returns an error.  BUT something is wrong with the command for four devices
on the bus in my g3-beige - they only return an endless stream of 0xff.


A long response (sorry) - but the answer is:
(a) Either some hint on how to use the GET_SET_IIC command for the purpose
or
(b) some hint on what extra needs to be done with COMBINED_FORMAT_IIC for
the job.

TIA,
Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/