-------- Forwarded Message
--------
Hi,
I think meta-phosphor/sensors and
phosphor-power/phosphor-regulators interfere with each other.
When I power on chassis, journalctl shows errors from
phosphor-regulators saying the device or resource is busy and
mentions the correct i2c. It stops trying after a few attempts.
Looking at the code, I see that phosphor-regulators is using
/dev/i2c.
At the time of chassis on, the i2c has traffic on the bus, from
sensors.
Is there a way to make these play nice?
Hi,
If dbus-sensors requires use of a device driver, I'm not sure if
both applications can read sensors from the same regulator at the
same time. As noted in my other response, phosphor-regulators
communicates directly with the regulator via i2c-dev. That is
because most regulator drivers don't support regulator
configuration, which is one of the key functions of
phosphor-regulators.
phosphor-regulators supports the following sensor types: iout,
iout_peak, iout_valley, pout, temperature, temperature_peak, vout,
vout_peak, vout_valley. Does that cover the ones you want to
read? If so, could you switch to doing all of your sensor
readings from phosphor-regulators?
Otherwise, if each application is missing one or two key sensors,
perhaps dbus-sensors or phosphor-regulators could be enhanced to
provide the missing ones? I'm pretty booked right now, but
contributions are welcome.
Long term, it would be ideal for phosphor-regulators to move to
driver-based communication. That would avoid this issue. I think
we would need define a new regulator device driver framework that
provided full configuration capability. It would need to support
not just PMBus configuration but use of manufacturer-specific
interfaces or registers. Last time I read about it, the Linux
framework provided only very limited configuration and was not
intended to be used by user-space applications.
Thanks,
Shawn