Port-sparc64 archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: envstat drivers on SUN Ultra-45?



Hi,

> I'm not sure about the first one:
> 
> > [     1.000000] env-monitor at ebus0 addr 0-41 not configured

From a quick search, I didn't find usable information about this, so I looked
at the i2c devices instead.  I couldn't get usable numbers from the LM76
chips, so I assumed that the PIC implementation of the 8584 I2C chip on the
U45 was the problem.  I found a reference to delays needed, so added a
delay after every read or write.  That seems to help, although I'm not 100%
sure that it's needed.  I'm pretty sure that the driver is working here,
because I can run:

  dd if=/dev/seeprom0 bs=1 skip=6144 count=2048 | hexdump -C

and I see (trimmed):

00000720  00 00 00 00 00 00 00 00  00 00 c0 22 03 00 0c 47  |..........."...G|
00000730  ed f0 57 f8 00 10 b7 43  d8 29 fc 4f 44 4d 2c 46  |..W....C.).ODM,F|
00000740  52 4f 4e 54 20 49 2f 4f  2c 41 37 30 00 00 00 00  |RONT I/O,A70....|
00000750  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000780  00 00 00 00 00 00 00 00  00 00 00 53 68 75 6e 64  |...........Shund|
00000790  65 2c 43 68 69 6e 61 00  00 00 00 00 00 00 00 00  |e,China.........|
000007a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

I also see references to i2c repeat start [*], which is needed if we want
to select a register to read on a multi-master machine.  We didn't do this,
but it was easy to add.  I'm not 100% sure that we need it on the U45 (I
added it whilst trying to understand why I can't read from the LM76's) but
it might help on the V210, V240 and V440 where we have a workaround when
reading from the ADM1026 chip.

> but these look like the candidates, indeed:
> 
> > [     1.000000] temperature (i2c-lm76) at iic0 addr 0x2b not configured
> > [     1.000000] temperature (i2c-lm76) at iic0 addr 0x48 not configured
> > [     1.000000] temperature (i2c-lm76) at iic0 addr 0x4f not configured
> > [     1.000000] hardware-monitor (i2c-adt7462) at iic0 addr 0x58 not configured

The device at 0x4f does look like an LM76, and I can see:

[lm76temp2]
  temperature:    68.000  160.000   -0.062   -0.062           degC

(-0.062 is register value 0xffff).

However, I always get a read error for addr 0x48, so I'm pretty sure that
there is nothing actually there.  For addr 0x2b, there is a chip there,
but the values don't make sense for an LM76.  I guess that it has 3 or 4
1-byte registers, but it returns 0 for any register address, so I' not
100% sure,

Using i2cscan, I can see additional devices:

  /dev/iic0: found device at 0x4c
  /dev/iic0: found device at 0x4d

but they look to have 4 * 1-byte registers with constant values 0x10, 0xff,
0xff, 0xff) so are not LM76 chips either.

With a quick test to read values from the ADT7462, it looks valid with
local temperature of 47 and remote temperatures of 55.75, 75.5 and 45.75.

> and I'm not sure if these have anything behind them:
> 
> > [     1.000000] i2c at mainbus0 not configured
> > [     1.000000] i2c at mainbus0 not configured

We don't have a driver for the fire-i2c, and a quick hack to make our
jbus-i2c driver attach didn't generate valid values, so I'll check if there
is information about it in one of the architecture manuals.

In summary, progress but not much useful output for envstat.  I'd like to
test the pcf8584 changes on a few more machines before committing them.

Regards,

Julian

[*] If we want to read from a chip with registers, we have to:

  send/write the register address
  read the selected registers

However, each request/reply is surrounded by start and stop, so we were
actually sending on the i2c bus:

  start
  send register address
  stop
  start
  read the selected register
  stop

and it's possible for another bus master to grab the bus between our stop
and start, which would cause our read to read a different register if the
other master also set up a read from the same chip.

Repeat start replaces the stop start pair with another start, so that no
other master can take the bus between our stop/start.

-- 


Home | Main Index | Thread Index | Old Index