On Thursday 13 September 2012 08:07 PM, Arnd Bergmann wrote: > On Thursday 13 September 2012, Rajanikanth HV wrote: >> On Wednesday 12 September 2012 09:06 PM, Arnd Bergmann wrote:> > >>> 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. > > Ok, so you want to just remove the property from the device tree, > or do you want to establish a different method to specify these > connections? > >>> 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. > > I wasn't correlating them. I just mentioned that unlike the supplied-to > property, the battery type property does seem to belong into the device > tree. > >> 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. > > Ok. > > If you want to make the battery type a generic property, it's probably > best to start a separate binding document for this in > Documentation/devicetree/bindings/power-supply/common.txt > and document a string for each of these. > > If we expect the property to be needed only for ab8500, please use > a vendor prefix like 'stericsson,'. it is fine to have battery-name in the battery-type property as said above and to have binding document, the basic requirement is to maintain the battery type information for a specified battery also within the same technology of battery method, battery parameters may vary. Presently battery-type and its dependent information is maintained in the drivers/power/ folder as per the arnd review sometimes back.
> > Arnd > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
