Hi,
> > + *
> > + * The constants a and b are calculated using two triplets of int values PTAT
> > + * and THCODE. PTAT and THCODE can either be read from hardware or use hard
> > + * coded values from driver. The formula to calculate a and b are taken from
> > + * BSP and sparsely documented and understood.
> > + *
>
> hmmm.. OK. that gets a bit more interesting.
>
> So you can get a and b queried from hardware. cool.
>
> but you can also get those hardcoded in the code. In that case, I would
> suggest hardcode them in DT, instead, using the coefficients property.
It is only the engineering samples which have the coeffs hardcoded. All
future revisions of the same SoC will have the values as fuses from
registers. Sadly, we won't have access to newer versions for a while. To
avoid having seperate DTSI per engineering sample revision, I planned
for using the new soc_device_match() mechanism which was introduced for
exactly such use cases.
> > +static int rcar_gen3_thermal_get_temp(void *devdata, int *temp)
> > +{
> > + struct rcar_gen3_thermal_tsc *tsc = devdata;
> > + int mcelsius, val1, val2;
> > + u32 reg;
> > +
> > + /* Read register and convert to mili Celsius */
> > + mutex_lock(&tsc->lock);
> > +
> > + reg = rcar_gen3_thermal_read(tsc, REG_GEN3_TEMP) & CTEMP_MASK;
> > +
> > + val1 = SCALE_DIV(SCALE_INT(reg) - tsc->coef.b1, tsc->coef.a1);
> > + val2 = SCALE_DIV(SCALE_INT(reg) - tsc->coef.b2, tsc->coef.a2);
>
> I see. there are actually two sensors here, and
Really? val1 and val2 are both based on 'reg'. Also, the datasheet
explicitly mentions 'three sensors in the LSI'.
Thanks for the fast response!
Wolfram
Attachment:
signature.asc
Description: PGP signature
