[PATCH v4 3/6] Documentation: DT: Document twl4030-madc-battery bindings
Pavel Machek
pavel at ucw.cz
Tue Mar 31 00:26:43 PDT 2015
Hi!
> > >> + io-channels = <&twl_madc 1>,
> > >> + <&twl_madc 10>,
> > >> + <&twl_madc 12>;
> > >> + io-channel-names = "temp",
> > >> + "ichg",
> > >> + "vbat";
> > >> + };
> > >
> > > Rather than just making platform_data into device tree properties..
> > >
> > > Can't you hide the these custom properties behind the compatible flag?
> > >
> > > You can initialize that data in the driver based on the compatible
> > > flag and the match data.
> > >
> > > This makes sense if you can group things to similar configurations.
> >
> > Maybe I have not completely understood your proposal.
> >
> > Do you mean to go back to have big parameter tables for each device/battery
> > combination in the driver code and the compatible flag (e.g. compatible = “board17”)
> > chooses the right data set for the charging map and channels?
>
> If you can somehow group them, then yes. Not for every board if there
> are many of them naturally.
>
> > I thought this is what the DT was introduced for - to have the same driver
> > code but adapt to different boards depending on hardware variations.
>
> Yeah but you also need to consider the issues related to introducing
> new device tree properties. The device tree properties introduced
> should be generic where possible.
>
> > And batteries have very different characteristics and vary between devices…
>
> Right. Maybe that has been already agreed on to use capacity-uah for
> batteries in general? In that case I have not problem with that as
> it's a generic property :)
>
> > The charging maps are depending on the battery type connected to the twl4030
> > and which madc channel is which value is also a little hardware dependent
> > (although the twl4030 doesn’t give much choice).
>
> Just to consider alternatives before introducing driver specific
> property for the maps.. Maybe here you could have few different type
> of maps and select something safe by default? Of course it could be this
> is higly board specific, I think some devices may be able to run below
> 3.3V for example..
As I explained in some other mail, those tables should not be
neccessary at all. They can be computed from li-ion characteristics
and internal resistance, and assumed current during charge and
discharge.
Running below 3.3V.. not really. At that point, the battery is really
_empty_, and voltage is going down really really fast.
Plus, you are damaging the battery at that point.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
More information about the linux-arm-kernel
mailing list