On Thu, Jun 06, 2024 at 06:05:30PM +0100, Conor Dooley wrote: > On Thu, Jun 06, 2024 at 01:32:46PM +0000, Haylen Chu wrote: > > Both accumulation-period and chop-period specify how the sensor > > measures temperature. Making these parameters up to end users brings > > extra unnecessary code complexity. Being configurable for each board > > should be enough and other thermal drivers have been doing things in > > this way. > > Other systems may well have properties for this, but something being > done in the past doesn't mean it might be the right thing to do now. > I don't really buy that this is something you set to a fixed value per > board, but rather the use case of a particular board would factor into > whether or not you would want to use a shorter or longer accumulation > period. Accumulation period and chop period do only affect the accuracy of its result, in a range about 1 Celsius degree. Changing these parameters does not mean much to end users, as this is only a thermal sensor and 1 Celsius is quite good for its usage. And users could always switch to another configuration with a dt-overlay. > > I do not catch your idea. These values directly map to raw register > > configuration, which simplify the implementation a lot. > > It should be trivial to convert them to register values in your driver. Okay, I will do this. > > > > > + default: 3 > > > > > + > > > > > + sample-cycle-us: > > > > > + description: Period between samples > > > > > + default: 1000000 > > > No constraints? > > > > Sample cycle is more flexible because of hardware designing. > > It quite likely has constraints, flexible or not. Is the hardware > capable of both 1 us and uint32_max us? It should be a value between 524 and 2^24 - 1. Will document this in next revision. > Thanks, > Conor. Best regards, Haylen Chu
