On Thu, Feb 24, 2011 at 10:58, Gulati, Shweta <shweta.gulati@xxxxxx> wrote: > Hi, > > On Sat, Feb 19, 2011 at 5:31 PM, Nishanth Menon <nm@xxxxxx> wrote: >> Voltage values can get confusing in meaning with various Smartreflex >> classes being active. Depending on the class used, the actual voltage >> selected might be a variant. Hence pass the volt_data pointers through >> the structure. Each voltage domain contains a set of volt_data structs. >> Each of those volt_data struct represents a voltage point that is supported >> for that domain. Hence, this is a more accurate representation of the >> voltage point we are interested in going to, and the actual translation >> of this voltage point to the voltage value is done inside the voltage layer >> which allows the users of the voltage layer to be blissfully ignorant >> of any complexity of the underneath layers. > Volt_data has efuse, Errgain and errminlimit other than nom_volt > How does this data differs in different SR Class implementation which > is why using volt_data is required? fair question. let me try it this way. with smart reflex class 3: a) you dont have SR enabled, you will go to volt_nominal b) you have SR enabled, you go to volt_nominal, then enable SR and expect it to adjust voltage. we dont really care about the resultant voltage(until the next scale ofcourse). but when we ask voltage layer to scale to voltage x for OPP y, it always means x is the nominal voltage for OPP y. Now with class 1.5 as introduced in http://marc.info/?l=linux-omap&m=129811707718325&w=2, a) if you are booting for the first time OR if you never enable SR, you go to volt_nominal b) if you enable SR and the OPP is calibrated, you will not enable SR again when that OPP is accessed anymore, but when you set voltage, the voltage achieved will be volt_calibrated c) if recalibration timeout triggers, the calibrated values are nullified, and you set voltage, the voltage achieved will be volt_dynamic_nominal so, voltage for that OPP you are setting has not 1 single value anymore, but 3 possible valid values depending on which state the system is at. This is the motivation of decoupling values representing voltage in this patch and instead we use a "voltage object" represented by the pointer to volt_data to decide adequately the OPP voltage we go to. The decision as to what the "voltage object" means in uVolts is left to the voltage layer. upper layers (or users of voltage layer) are not aware of the system conditions relevant to voltage - only voltage.c has that view - hence we do the translation there. [...] Regards, Nishanth Menon -- 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
