Implement devicetree support for AB8500 Btemp

[Rajanikanth HV]

On Wednesday 12 September 2012 09:06 PM, Arnd Bergmann wrote:
> On Wednesday 12 September 2012, Rajanikanth HV wrote:
>> On Tuesday 11 September 2012 04:52 PM, Arnd Bergmann wrote:
>>> On Tuesday 11 September 2012, Rajanikanth HV wrote:
> 
>> Consider: USB charging:
>>             ______________________
>>            |                      |
>> --(Vbus)-->|   USB Charger with   |
>>            |  Charger FSM (h/w)   |
>>            |______________________|
>>                 |    |
>>                 |    |(Vbat and other signals)
>>                 |  __|_____
>>         to      | |        |(GaugeSense
>>      Charger FSM| | LION   | Signal)     _____________
>>                 | |Battery |----------->|FuelGauge blk|
>>                 | |________|            |{Coulomb Ctr}|
>>                 |       |                -------------
>>                 |   <Thermistor>
>>                 |       |
>>                 |       | (BatCtrl Signal)
>>                 |_______|---------->[Btemp blk]
>>                         |               |
>>                       [ADC]             |__Btemp_Low
>>                                         |__Btemp_Med
>>                                         |__Btemp_High
>>
>> Note: Charging algorithm is a logical entity.
> Ok, thanks for the explanation, this is starting to make a lot more
> sense. So the three blocks (fb, btemp, charger) are all separate
> mfd cells, each with their own register set in ab8500 and a separate
> driver in drivers/power, right?
Correct, You can have a look at ab8500 spec:
www.stericsson.com/developers/CD00291561_UM1031_AB8500_user_manual-rev5_CTDS_public.pdf
> 
> Then there is the ab8500-charalg driver which I guess is implementing
> the Charger FSM you mention above,
ab8500-charalg does not implements charger FSM, Charger FSM is a
hardware block for which any functional info is not available in the
spec. However, ab8500-charalg implements state m/c depicted in the
figure (9) of spec, implementation can be found in the code:
abx500_chargalg.c: centered around abx500_chargalg_algorithm(..)

Let me brief out what 'charger(Wall/USB)' and 'chargalg' driver does:

(a) Charger driver implements:
	- events specific to Wall(a/c) and USB Charger
	- power supply attributes handling and notification
	  to power_supply core. Ref: enum power_supply_property
	  linux/power_supply.h
	  Note: subset of power_supply_property are handled	
	- turn on/off charging led, AC and USB charging
	- Regulating Voltage and Current values for charging
	- voltage threshold check
	- Charging regulation based on btemp
all this functionality has register dependency

(b) Charging algorithm:
	- Starts by collecting power_supply properties across power
          class devices which are 'bm' devices
	- Maintains the different charging states across ac and usb
	  charging process pertaining to 'Vbus, main or Vbat', thermal,
	  btemp etc.,	
	- Implements subset of power_suppply_class properties	
Note: Do not have direct register interface

 but it doesn't have any registers
yes, but make use of power supply properties updated by other bm devs
while managing charging states.
> in the ab8500 but rather ties the other drivers together.
> 
> If this is true, I don't understand what makes the 'supplied-to'
> properties you list in the device tree binding board specific. Are
> they not always done the same way? If so, you could just leave them
> out.
Precisely 'supplied-to' is not board specific, it was maintained as
platform_data which i migrated to dt-node. It is meant to establish
dependency across bm drivers based on power_supply property and
runtime battery attributes.
Basically, 'supplied-to' provides a way of exporting change in
power_supply_property and runtime batter characteristics so that other
bm devs shall make use or refer the updated values.
Ref: external_power_changed(...) call back api.
Note: all the bm drivers handles subset of power_supply property and
      battery attributes,
      ref: include/linux/power_supply.h and get_property(...) call back
      api across bm drivers.
> 
> What does indeed seem to be needed is a place to identify the battery
> type, but it's not clear if the btemp device is the best place for
> that (maybe it is). 
I am not clear whether you are trying to correlate battery-type with
supplied-to. however, battery type is identified based on the
resistance value measured at batctrl pin which is expected to be in the
allowable limit of ab8500 device. This resistance limit varies across
battery types. This happens in btemp driver.

For this, I would suggest you give a list of
> possible batteries and require a property such as
> 
>  st-ericsson,battery-type: A string identifier for the type of battery,
> 			   which impacts how an operating system interpret
> 			   the sensor readings. Possible values include:
> 	* "none"	-- no battery connected
> 	* "li-ion-9100" -- Type 9100 Li-ION battery
> 	* <add any others that apply here>
Can do this, not precisely as "st-ericsson,battery-type", it will be as
battery-type = [unknown|NiMH|LION|...|]], reason being
allowable battery type is based on technology, as you can see the
possible types as:
POWER_SUPPLY_TECHNOLOGY_UNKNOWN = 0,
        POWER_SUPPLY_TECHNOLOGY_NiMH,
        POWER_SUPPLY_TECHNOLOGY_LION,
        POWER_SUPPLY_TECHNOLOGY_LIPO,
        POWER_SUPPLY_TECHNOLOGY_LiFe,
        POWER_SUPPLY_TECHNOLOGY_NiCd,
        POWER_SUPPLY_TECHNOLOGY_LiMn
Ref: include/linux/power_supply.h
Note: doing this will impact my of_probe(...), may slightly bloat the
code.
> 
> 	Arnd
>