On Tue, Dec 27, 2016 at 7:58 AM, Bjorn Andersson <bjorn.andersson@xxxxxxxxxx> wrote: > On Thu 15 Dec 14:48 PST 2016, Linus Walleij wrote: > I gave this a spin on one of my APQ8064 devices - with PM8921 - and I > can do measurements. Nice :) I hope the v3 patchset also gives something, hopefully more. > Several of the channels do give me reasonable readings. But the channels > in PM8921 are different than PM8058, so it looks like we need additional > prescales defined. Further more, the 8921 has several different > thermo-related channels, each with their own (post-)scaling function. I hope I have fixed this for all variants in the v3 version. > And lastly it seems that I have 2 thermo-channels on "mpp amux", but I'm > still confused to how that is supposed to work in the downstream code - > I will need to investigate this further. > > One of the channels defined in my APQ8064 device measures > ADC_MPP_1_AMUX5, a lookup table is used to convert the measured value to > a temperature. As the table depends on an external thermistor, which > seems to differ between products a number of lookup tables exists - with > 156 data points each. (...) > On my 8064 device I have 6 different temperatures (2 coming from amux'ed > mpp channels). They all have different lookup tables, which seems > calibrated based on some external resistor. Rama Krishna cleared it up a bit, then I have tried to make it even clearer. Essentially all MPP (multi-purpose pins indeed) can have any random analog value coming in, but there are some layers of enums on top of the actual hardware channels confusing things a bit. Some MPPs are used for reading battery temperature and system temperature in some systems, but this is essentially a board-specific use of a general purpose ADC and need to be above the driver, however I tried to encode the most typical usecases a bit in the different PMIC channel tables, so that MPP8 is usually set up a temperature channel. We need additional bindings to specify conversion functions from the device tree but that can be made on top of this patch set as an expansion. The approach chosen here is that this ADC driver should present "processed" (scaled etc) values, and to achieve this the scaling is done directly on the raw values read from the ADC, which are first scaled to uV from calibration and then scaled to e.g. a temperature. This is all clearer after Rama Krishna's patches. >> + /* We strictly require this voltage */ >> + ret = regulator_set_voltage(adc->vref, 2200000, 2200000); > > On 8064 the reference is L14 and it's at 1.8V, so this fails for me. I have removes this hard setting of voltage. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
