Re: [PATCH v4 3/6] Documentation: DT: Document twl4030-madc-battery bindings

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux