On Thu, May 09, 2013 at 08:38:28AM -0400, Jean-François Dagenais wrote:
>
> On 2013-05-08, at 11:53 PM, Guenter Roeck wrote:
>
> > Guess the real conclusion is that one should avoid two active masters
> > in the first place if possible.
>
> I agree, I can't think of any benefits worth the trouble.
>
> > Is one of the I2C adapter drivers your own ? If so, you can disable auto-detection
> > in the adapter code by setting the adapter class to 0 (specifically, don't set it
> > to I2C_CLASS_HWMON). You can do the same in the Kontron driver if you have the
> > source (it is GPL so you should be able to find it). While not perfect, that should
> > be better than disabling auto-detection in the affected chip drivers.
>
> That's great advice!! I will look into this, thanks!
>
> > Note that the Kontron driver also sets I2C_CLASS_SPD, which means EEPROMs are
> > auto-detected on address 0x50.
>
> Funny, I had to explicitly inject "I2C_BOARD_INFO("24c32", 0x50)" to see
> Kontron's JIDA chip.
>
Interesting.
> >> [...] Right now I have a working setup where some slaves are
> >> declared on bus 0 (PLD i2c master) and others on bus 1 (FPGA i2c master). I have
> >> yet to stress test the setup within the next day or so, but so far, it seems to
> >> work ok.
> >>
> > Sure, it does work, I am just not sure what the benefits are of having two
> > masters in this scenario.
>
> My thoughts exactly. I would have avoided it. Right now I am trying to improve
> and existing design.
>
> > Guess you are saying that the I2C master in the
> > Kontron PLD can not drive the AD7147 - is that correct ?
>
> Well no, it does drive it, we have it in stable production. It's just that when
> you have your finger on the wheel, CPU usage goes up to 5-15%. More intense
> polling of the sensors also takes a toll on the CPU. For different reasons other
> than the ad714x, the FPGA i2c core option suddenly became attractive.
>
> > If so, and if that
> > means you have to use your own I2C core anyway, why bother using the Kontron
> > PLD's I2C bus to start with ? You could just ignore it (ie not instantiate
>
> > or build it at all) and use your own.
>
> Yeah, we already considered that... our FPGA's reset and flash select are
> controlled by an i2c I/O expander! Hehe, so this I/O expander needs to be
> mastered from the kempld. Reality is a bummer ;)
>
> >
> > Did you tell Kontron about the problems with their PLD ? Maybe they have a
> > solution.
>
> Yes we did. If I remember correctly, the problem is the absence of an interrupt
> line from the PLD to the CPU, which explains the high CPU since the driver
> sleeps-polls for async PLD completions and statuses. ... I know...
>
Ah, that one. Yes, the higher CPU utilization is an indication that this is due
to polling, not due to power draw on the I2C lines. You might try to increase
the usleep_range interval in the Kontron driver to reduce the load a bit.
Anyway (kind of) good news - newer Kontron boards do support interrupts and no
longer have to revert to polling.
Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
