DPS310 sampling

[Matt Spinler]

On 7/21/2017 12:17 AM, Joel Stanley wrote:
> 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?

The phosphor-hwmon app creates an error log and crashes, and it all goes 
downhill from there.

>
>> 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.

Alternatively, what about just putting it into 'command mode'  to do an 
on-demand read?

>
> I'd be happy to take a patch to change this.

I plan on calling into (my time's) Sunday night meeting where we can 
discuss the options.

> Cheers,
>
> Joel
>
>> 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
>> dbus.
>>