[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-id: <55B588EE.4060103@samsung.com>
Date: Mon, 27 Jul 2015 10:27:10 +0900
From: Krzysztof Kozlowski <k.kozlowski@...sung.com>
To: Sebastian Reichel <sre@...nel.org>
Cc: "Pallala, Ramakrishna" <ramakrishna.pallala@...el.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
MyungJoo Ham <myungjoo.ham@...sung.com>
Subject: Re: [PATCH v2] power: max17042_battery: add HEALTH and TEMP_*
properties support
On 27.07.2015 10:22, Sebastian Reichel wrote:
> Hi,
>
> On Mon, Jul 27, 2015 at 09:34:13AM +0900, Krzysztof Kozlowski wrote:
>>>> [...]
>>>
>>> I missed this email (may be overlooked it). To have the
>>> interrupts enabled we need the config registers(0x1Dh) bit's
>>> BIT(9), BIT(4) and BIT92) should be 1 and BIT(8) should be 0.
>>>
>>> Can you dump the status(00h), Talrt(02H) Temp(08h) and
>>> config(1Dh) registers values and share?
>>
>> Thanks for responding. The issue was in BIT(8) which was set to default
>> value of 0x1. This would mean to use external sensor but the board does
>> not have it.
>>
>> This is a DT platform and there is no initial config data so all
>> registers are set to default values.
>>
>> Anyway everything seems to work as expected, thanks for explanation.
>
> So I guess the bit should be set to 0 during probe. Maybe with a
> boolean DT property "maxim,has-external-sensor" for setting it
> to 1.
Yes, something like this but it may be not sufficient. Other
configuration register may also require tuning.
This tuning happens when platform data is provided. The driver overrides
sets whole configuration (the config register and even some more
settings). Since on ARM we moved to DT-only this functionality is
crippled for us but works for Intel.
I put it on my todo list (fixing the sensor or entire configuration)...
but if anyone would like to fix this, then go ahead. I can provide a
tested-by.
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists