joel at jms.id.au
Fri Jul 21 15:17:04 AEST 2017
On Fri, Jul 21, 2017 at 2:22 AM, Matt Spinler
<mspinler at linux.vnet.ibm.com> wrote:
> Hi Joel,
> Now that phosphor-hwmon-readd tries to read the DPS310 temp, we keep hitting
> EAGAINs from the driver.
Can you elaborate here. What happens when it hits EAGAIN?
> It turns out that the delay call within
> phosphor-hwmon doesn't always wait a full second because it pops out of the
> delay if there is some dbus work to handle. It would take a nontrivial
> refactoring to fix that properly, and I think even if we did we'd just
> barely be avoiding a race between that being done and the temp being
> available every 1s.
> What do you think of changing the rate to be faster than 1 measurement per
> second? Is that a device tree binding? In combination with that change and
> phosphor-hwmon doing retries, we should be able to get things to work.
This is not configurable with the current implementation, so changing
the sample rate would require reworking the driver. It's unfortunate
we didn't bring up this requirement before the driver was developed.
There are a set of parameters that need to be set to configure the
device's sampling rate, and the wrong combination results in invalid
readings. It took me a few days to get this right, but it might be
easier now that we have a working driver.
I'd be happy to take a patch to change this.
> Alternatively I could just add in up to a second of retries from within
> phosphor-hwmon, but that would slow down users that request data from it on
More information about the openbmc