On Friday 25 July 2003 03:00 am, you wrote:
> > i2c-tsunami does not compile, and its fix is more than just
> > a one-liner. It requires the <linux/slab.h> include, plus
> > the <linux/pci.h> include, plus some changes in static
> > struct initialization to accomodate recent gcc versions.
>
> Hm... And that's the problem exactly? I'm currently not
> suscribed to the list, but will try to recompile this code...
Here's a snippet of my current patch to give you an idea:
static struct i2c_algo_bit_data tsunami_i2c_bit_data = {
-
- bit_tsunami_setsda,
- bit_tsunami_setscl,
- bit_tsunami_getsda,
- bit_tsunami_getscl,
- 10, 10, HZ/2 /* delays/timeout */
+ .setsda = bit_tsunami_setsda,
+ .setscl = bit_tsunami_setscl,
+ .getsda = bit_tsunami_getsda,
+ .getscl = bit_tsunami_getscl,
+ .udelay = 10,
+ .mdelay = 10,
+ .timeout = HZ/2,
};
Apparently gcc-3.2.3/alpha doesn't grok the original method of
static initialization. It choked on it badly until I switched
it. gcc-2.95.3/x86 seems to like either way just fine.
Maybe the C standard has changed, or maybe gcc3 is just being a
fruitcake. But as the other static structs use a different form
of initialization, I decided to accomodate gcc3 and introduce
proper consistency in one fell swoop.
(Other lm_sensors drivers have small problems compiling on alpha,
mostly one-liner fixes that I've been able to handle on my end.
I was planning to finish it out and send the full patch
upstream, but I hit a stumbling block on i2c-tsunami.)
> > Its biggest problem, though, is that it's missing a
> > tsunami_ids struct (list of PCI IDs), and this is REALLY a
> > problem. I have no clue what the Tsunami/Typhoon (2127x)
> > PCI IDs are. I know that they're the core logic controller
> > chips on such motherboards as the DP264 and the UP2000
> > series. I also looked in the <linux/pci_ids.h> header for
> > 2.4.2[01], and the closest macro I could find for this PCI
> > device ID is
> > PCI_DEVICE_ID_DEC_21285. I'm fairly certain that won't do
> > at all.
>
> Tsunami/Typhoon chips are not PCI devices. They are core
> logic which is transparent to PCI stuff. The only visible
> parts on the UP2000/DS20 boards is the "real" hardware stuff:
> -----------
> 00:05.0 ISA bridge: Contaq Microsystems 82c693
> 00:05.1 IDE interface: Contaq Microsystems 82c693
> 00:05.2 IDE interface: Contaq Microsystems 82c693
> 00:05.3 USB Controller: Contaq Microsystems 82c693
> 00:06.0 SCSI storage controller: Adaptec AHA-2940U2/W / 7890
> (rev 01) ----------
Hmmm...well, part of the tsunami_driver struct requires a PCI ID
table (tsunami_ids). I'm not sure what's supposed to go in that
table?
Could it be that someone tried to port the driver to the new API,
half-finished it, and left it for dead? lm_sensors-2.7.0 makes
no mention of the tsunami_driver struct or the tsunami_ids
table. Maybe that little struct arrangement isn't supposed to
be there?
> > CVS, as of 20030724, is no better. Last entry for this
> > driver was apparently back in January.
> >
> > This is especially annoying, as the Tsunami driver is the
> > primary driver that makes lm_sensors useful at all on Alpha.
>
> Just FYI. Tsunami i2c bus provides an access to a SPD
> chips only. Other stuff (such as lm75, adm9240) are accessed
> via i2c-elektor module. So, in fact UP2000 has to different
> i2c buses.
Ah, I never knew about that. Good info to have, thanks.
What Alpha motherboards support sensors like that, btw?
> > Unfortunately, I have no such motherboard with this chipset.
> > I'd like to make the driver work anyways. Can people with
> > Typhoon/Tsunami motherboards please volunteer the PCI IDs
> > for these chips? I'd prefer to merge them with the
> > <linux/pci_ids.h> file, then add some #ifdefs to
> > i2c-tsunami.c to make sure the PCI ID macros get defined
> > even on older kernel versions.
>
> Wrong way. ;-))
Eh? Wrong way how? I suppose I'm missing something about
contributing kernel macros for PCI IDs?
(Wouldn't surprise me if I was. I'm not all _that_ much of a
kernel hacker.)
> > Also, the i2c-tsunami driver itself
> > looks...well...unmaintained. Does anyone maintain it now?
> > If it's been abandoned, I can happily take over maintenance,
> > assuming someone can loan or donate enough to build a
> > sufficiently-working Typhoon/Tsunami motherboard setup.
>
> Yes. It's unmaintained due to the fact we have used
> kernels 2.2.x on our site, but now we are moving to 2.4
> series.
Ah, so that's where you've been. ;) How's the upgrade going so
far?
--
Kelledin
"If a server crashes in a server farm and no one pings it, does
it still cost four figures to fix?"
