SR Voltage Control Migration

From OMAPpedia

(Difference between revisions)
Jump to: navigation, search
 
Line 54: Line 54:
* http://free-electrons.com/~thomas/pub/omap-regulators/0005-omap-attach-external-controller-to-VDD1-VDD2.patch
* http://free-electrons.com/~thomas/pub/omap-regulators/0005-omap-attach-external-controller-to-VDD1-VDD2.patch
-
== Weekly progress ==
+
== Status in September 2010 ==
-
=== Week 24, 2010 ===
+
The proposed design and patches seem to have gotten a generally good feedback. However, as this patch set heavily depends on the DVFS infrastructure, its integration is blocked for the moment, while the DVFS work lands into one of Kevin's trees.
-
 
+
-
* Started working for TI on Monday
+
-
* Monday: documentation and code reading on voltage, SmartReflex
+
-
* Tuesday: organization of the travel to TI Nice
+
-
* Wednesday to Friday: in TI Nice, with Benoît Cousson. Various administrative procedures, generic OMAP presentation, OMAP Power Management discussions, general ramp up
+
-
 
+
-
=== Week 25, 2010 ===
+
-
 
+
-
* Brought up a BeagleBoard to run the OMAP PM kernel. Needed a few tweaks in the hwmod database, with the help from Kevin, and quite a few tries before reaching a configuration that actually works
+
-
* More code/documentation reading, now that I have OMAP4 and PowerIC documentation
+
-
* Found out the correct test points to measure the VDD1 and VDD2 voltages and therefore check that the regulator voltage is indeed changing
+
-
* Very preliminary technical proposal for the regulator conversion sent to Kevin, Thara and Benoît. No answer so far, but as the technical description is very high-level, it might be difficult for them to validate/comment the proposal.
+
-
* Started modifying the code to
+
-
** Instantiate a regulator for VDD1
+
-
** Get this regulator to change the voltage when the OPP is changed. At the end of the week, stopped by the MPU/DSP/L3 devices being early devices and therefore not completely initialized. Got some hints from Kevin on this
+
-
** The goal of these changes is to first get the regulators to work in a software-controlled mode, before going on with adding the SmartReflex functionality.
+
-
 
+
-
=== Week 26, 2010 ===
+
-
 
+
-
* Integrate the regulators instantiations with Kevin fixes of the MPU/DSP/L3 devices initialization
+
-
* Cleanup the usage of regulators in the OPP change code
+
-
* Continued improving the twl_regulator driver to support SMPS regulators, to make them work in the basic mode where SR/VP/VC aren't used
+
-
* Day off on Friday
+
-
 
+
-
=== Week 27, 2010 ===
+
-
 
+
-
* Week off for conferences
+
-
 
+
-
=== Week 28, 2010 ===
+
-
 
+
-
* Worked only three days for TI (one day was closed in France, another one was dedicated to other projects)
+
-
* Progressed in the design of the integration of Voltage Controller / SmartReflex into the regulator driver
+
-
* Wrote down short design notes + diagram on the Wiki
+
-
* Started a rough prototype integrating the two, it seems to work properly (i.e on frequency changes, the voltage is changed accordingly, but now, the OPP change code talks to a proper regulator and not directly to the Voltage Controller code)
+
-
* Needs some input from Kevin and Benoît on how much refactoring of the Voltage Controller / SmartReflex code they want. Just the minimal changes to make it work with the regulator driver, or some more in-depth refactoring ? I'm also not sure how to synchronize this effort with the pending patch from Thara turning the vdd_ids into proper pointers.
+
-
 
+
-
=== Week 29, 2010 ===
+
-
 
+
-
* Continued working on the integration of Voltage Controller / SmartReflex into the regulator driver
+
-
* Cleaned up and sent a patch set to Benoît, Kevin and Thara with the current status of the work
+
-
* Input needed on this preliminary version in order to know how to go forward
+
-
 
+
-
=== Week 30, 2010 ===
+
-
 
+
-
* Started taking into account Benoît comments. They mainly consist in implementing the different TODO items that I listed in the patches.
+
-
 
+
-
=== Week 31, 2010 ===
+
-
 
+
-
* Holidays
+
-
 
+
-
=== Week 32, 2010 ===
+
-
 
+
-
* Continue working on Benoît comments. Objective is to send a second version of the patches by the end of the week.
+

Latest revision as of 15:16, 13 September 2010

Contents

[edit] Objective

On OMAP, several regulators of the external Power IC can be controlled either by software (by means of a control I²C link with the Power IC) or by hardware through the SmartReflex technology of the OMAP SoC (in which case the OMAP SoC communicates with the Power IC through another dedicated I²C link). On OMAP3, two regulators can be controlled by SmartReflex, three of them can be controlled by SmartReflex on OMAP4. At the moment, those regulators are not being handled by the Linux kernel regulator framework, since the concept of having a regulator being controlled by hardware doesn't fit naturally into the regulator framework design. Therefore, the objective of the work is to make this conversion happen.

[edit] Design

As SmartReflex is a technology part of the OMAP CPU and not the PowerIC, support for SmartReflex must be independent from the TWL regulator driver (currently in drivers/regulator/twl_regulator.c) : the TWL regulator driver should theorically be usable on a system that doesn't use an OMAP CPU with SmartReflex, and conversely, the SmartReflex support should theorically be usable with other PowerIC than the TWL. Integrating the SmartReflex support directly into the TWL regulator driver is therefore not an option.

However, from the rest of the system, we still want the SmartReflex-controllable regulators to look like normal regulators for the rest of the kernel, so that the regulator_get(), regulator_enable(), regulator_disable(), regulator_put(), regulator_set_voltage(), regulator_get_voltage() API (i.e the so-called consumer API, as visible in include/linux/regulator/consumer.h). The fact that a regulator is controlled by SmartReflex should be hidden behind this normal regulator API.

For these reasons, the proposed design is to add the concept of a TWL external controller, which would be described by the following structure :

struct twlreg_ext_ctrl {
       int (*set_voltage)(struct twlreg_ext_ctrl *, int min_uV, int max_uV);
       int (*get_voltage)(struct twlreg_ext_ctrl *, int min_uV, int max_uV);
       void *data;
};

The TWL regulator driver is then modified so that when such an external controller is associated to a regulator, it would call the methods of the external controller to do the voltage set and voltage get operations.

Then, such a structure needs to be attached to the regulator. We have thought of two ways to implement this :

static struct regulator_init_data beagle_vdd1 = {
        .constraints = {
                .name                   = "VDD1",
                .min_uV                 = 700000,
                .max_uV                 = 1800000,
                .valid_modes_mask       = REGULATOR_MODE_NORMAL
                                        | REGULATOR_MODE_STANDBY,
                .valid_ops_mask         = REGULATOR_CHANGE_MODE
                                        | REGULATOR_CHANGE_VOLTAGE
                                        | REGULATOR_CHANGE_STATUS,
        },
        .num_consumer_supplies  = 1,
        .consumer_supplies      = & beagle_vdd1_supply,
        .driver_data            = & reference_to_the_twlreg_ext_ctrl_structure_for_this_regulator,
};

Once the external controller is attached to the regulator, the regulator driver call backs into the external controller hooks, as shown in the following diagram.

Design of VP/SR integration into the regulator framework

[edit] Preliminary version of July, 26th

[edit] Status in September 2010

The proposed design and patches seem to have gotten a generally good feedback. However, as this patch set heavily depends on the DVFS infrastructure, its integration is blocked for the moment, while the DVFS work lands into one of Kevin's trees.

Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox