Messages in this thread | | | Subject | Re: sharpsl_pm: using milivolts instead of custom units? | From | Richard Purdie <> | Date | Fri, 11 Nov 2005 12:35:12 +0000 |
| |
On Fri, 2005-11-11 at 13:03 +0100, Pavel Machek wrote: > Hi! > > It seems to me that sharpsl.c is using some very custom units: > > #define SHARPSL_CHARGE_ON_VOLT 0x99 /* 2.9V */ > #define SHARPSL_CHARGE_ON_TEMP 0xe0 /* 2.9V */ > #define SHARPSL_CHARGE_ON_ACIN_HIGH 0x9b /* 6V */ > #define SHARPSL_CHARGE_ON_ACIN_LOW 0x34 /* 2V */ > #define SHARPSL_FATAL_ACIN_VOLT 182 /* 3.45V */ > #define SHARPSL_FATAL_NOACIN_VOLT 170 /* 3.40V */ > > ...what are they? Unfortunately collie uses very different units:
They're raw values as provided by the ADC. Collie will have a different ADC and hence different raw values. There's no real need to convert them to mV and back again all the time.
> #ifdef CONFIG_SA1100_COLLIE > struct battery_thresh spitz_battery_levels_noac[] = { > { 368, 100}, > { 358, 25}, > { 356, 5}, > { 0, 0}, > ... > > ...so it could get very confusing. Would it be feasible to convert to > mV as soon as possible and have all constants in milivolts? I realize > they may be slightly different for different models, but they should > at least be comparable.
The battery levels are totally different between the models and each is going to need a levels translation table as its an extremely none linear decay curve. Using ADC values here makes a lot of sense as that's as granular as the information ever gets and you don't start to lose accuracy anywhere with rounding.
I still think you've much bigger problems to worry about as this code is heavily PXA biased and is going to need a lot of changes to work on the SA1100. Its why I've put it in mach-pxa rather than common and a separate driver for collie based on this code might be easier.
Richard
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |