User:ThomasPetazzoni

From OMAPpedia

• Working on OMAP Power Management
• Contacts
  • thomas.petazzoni <at> free-electrons.com (preferred e-mail address)
  • t-petazzoni <at> ti.com (not read that often)
  • kos_tom on the #linux-omap IRC channel

• Weekly progress

Contents 1 Weekly progress 1.1 Week 24, 2010 1.2 Week 25, 2010 1.3 Week 26, 2010 1.4 Week 27, 2010 1.5 Week 28, 2010 1.6 Week 29, 2010 1.7 Week 30, 2010 1.8 Week 31, 2010 1.9 Week 32 to Week 35, 2010 1.10 Week 36, 2010 1.11 Week 37 and 38, 2010 1.12 Week 39, 2010 1.13 Week 40, 2010 1.14 Week 41 and 42, 2010 1.15 Week 43, 2010 1.16 Week 44, 2010 1.17 Week 45, 2010 1.18 Week 46, 2010 1.19 Week 47, 2010 1.20 Week 48, 2010 1.21 Week 49, 2010 1.22 Week 50, 2010

[edit] Weekly progress

[edit] Week 24, 2010

• 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

[edit] 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.

[edit] 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

[edit] Week 27, 2010

• Week off for conferences

[edit] 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.

[edit] 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

[edit] 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.

[edit] Week 31, 2010

• Holidays

[edit] Week 32 to Week 35, 2010

• Mostly on holidays, only a few days worked for TI
• Continue working on Benoît comments. Implemented some of the different TODO items, in particular a proper separate handling for SMPS regulators in the TWL regulator driver
• Blocked on the regulator integration work, due to the dependency on DVFS, asked Kevin Hilman and Benoit Cousson for other tasks to work on

[edit] Week 36, 2010

• Phone meeting with Kevin Hilman and Benoit Cousson to see other items I should work on. I'll work on:
  • Improving the PRCM interrupt handler to use a chained handler mechanism
  • Improving the regulator framework to handle multiple consumers requests with different voltage requirements
• Started working on the PRCM interrupt handler. Did a first proposal to Kevin with a shared interrupt handler, but Kevin would like a true chained handler, where the main PRCM interrupt is dispatched into several virtual interrupts for the different events. Starting looking into this, reading other implementations in other ARM/OMAP code
• Got some issues bringing a recent Git Linux kernel (from Tony or Kevin trees) working on the BeagleBoard, due to USB issue (unsolved for the moment, switched to initramfs instead) and suspend issue (was due to cpufreq being non-functional, but still enabled in omap3_defconfig)
• Three days worked for TI

[edit] Week 37 and 38, 2010

• Was unavailable for TI work, due to customer contracts signed before being hired by TI.

[edit] Week 39, 2010

• Progress on the PRCM interrupt handler muxing
• Did a first very rough proposal on the PRCM interrupt handler muxing work to Kevin Hilman, he is ok with the general direction
• Two days worked for TI

[edit] Week 40, 2010

• Continue the work on the PRCM interrupt handler
  • Solved the IRQ disabled issue. It was disabled by the suspend process, so the interrupt handlers for the demuxed IRQs needs to be registered with IRQF_NO_SUSPEND if they don't want to be disabled during suspend
  • Using the handle_simple_irq flow handler doesn't make the ->ack() irq_chip method called. Used handle_level_irq instead, but will have to check whether the interrupt is actually level or edge trigerred
  • One suspend/resume cycle works now, but all the next suspend/resume cycles do not: sending stuff over the UART doesn't trigger the wake-up.
• Reviewed the DSS/hwmod patch set on linux-omap
  • http://www.spinics.net/lists/linux-omap/msg38442.html
  • http://www.spinics.net/lists/linux-omap/msg38441.html
  • http://www.spinics.net/lists/linux-omap/msg38438.html
  • http://www.spinics.net/lists/linux-omap/msg38435.html
  • http://www.spinics.net/lists/linux-omap/msg38436.html
  • http://www.spinics.net/lists/linux-omap/msg38439.html
  • http://www.spinics.net/lists/linux-omap/msg38430.html
  • http://www.spinics.net/lists/linux-omap/msg38426.html

[edit] Week 41 and 42, 2010

• Gave an embedded Linux training in Montreal on BeagleBoard. Commitment made before starting the contract with TI.

[edit] Week 43, 2010

• Attended the Gstreamer conference, the Embedded Linux Conference Europe and Buildroot Developer Day in Cambridge, UK
• Met Benoît Cousson and Kevin Hilman there

[edit] Week 44, 2010

• Attended the Linux Plumbers conference in Cambridge, MA, USA
• Met Benoît Cousson, Kevin Hilman and Nishant Mennon there. Various discussions about OMAP and power management topics.

[edit] Week 45, 2010

• No work done for TI (due to catch up after a month of travel, closed day in France, etc.)

[edit] Week 46, 2010

• Updated my working tree to the latest l-o master branch. Got issue with resume, finally found out it was caused by no_console_suspend, reported that issue to the linux-omap mailing list.
• Restarted work on PRCM interrupt handler
  • Managed to get a working solution.
  • More testing in progress. I have to first debug why my Core Power Domain is preventing going completely into retention/off mode.
  • Sent a version to Kevin and Benoit, got feedback from Kevin
  • Taken Kevin's feedback into account (style issues, added 36xx related defines, misc implementation details)
  • Kevin finally reproduced by Core Power Domain problem, it was due to the fact that I use a more recent version of U-Boot, that leaves musb in a state that prevents it from going into the idle state. Kevin has hacky patches to fix this, but the real fix is the conversion of musb to hwmod.
  • Send a second version of the patch to the linux-omap list
  • During the weekly meeting, had some comments from Benoit and Kevin regarding the implementation
  • On Thursday, sent a new version taking comments into account
  • More comments were made
• Some review and comments on Nishant Menon set of patches to use the new OPP layer, sent to linux-omap
• Some quick review of Rajendra set of patches that generalizes the powerdomain code
• Upgraded my U-Boot and X-Loader versions to http://feeds.sakoman.com/feeds/images/beagleboard/current/, in order to use the same version as Kevin, and therefore have similar testing results
  • Reported a MMC detection bug to Steve Sakoman on IRC with this new U-Boot version
  • In fact not a bug, the command is no longer mmc init but mmcscan, I was mistaken by the fact that I did not erase my environment when upgrading to the new U-Boot version
• Started looking at multi-consumer tracking for the regulator framework
• Did some experiments to try to free up the memory consumed by data not used on the current SoC, showed a proof of concept to Kevin and Benoît. The work needs to be generalized and cleaned up a bit before being proposed on linux-omap

[edit] Week 47, 2010

• PRCM interrupt handler
  • Took into account the latest comments from Kevin and Benoît
  • Got some more comments from Kevin
  • Fixed Benoit and Kevin comments
    • Fixed OMAP4 support
    • Split out PRCM events lists into separate files
    • Made the prcm_irq_pending() function generic
  • New version sent to Kevin and Benoit on Friday
  • TODO: understand the issue reported at http://marc.info/?l=linux-omap&m=129042162527228&w=2 and fix it
• Regulator: multi-consumer tracking
  • Set-up a simple test case with two regulators, three devices in order to experiment. Done on ARM Versatile, for easy testing inside Qemu, which really reduces the build/test cycles for core kernel development
  • Started digging into the regulator internal structures to see how to implement this.
  • Implemented and tested the multi-consumer tracking. Turned out to be simpler than I thought.
  • Sent a preliminary patch to Mark Brown (one of the regulator maintainer), who seemed to be satisfied
  • TODO: send a final proper patch officially
• Integration of regulators into OMAP DVFS
  • Started digging again into the latest DVFS code from Thara in order to try to design how to integrate regulators into this
• Not working for TI on Thursday
• More PRCM work on Friday
  • New version splitting the PRCM events list into separate files, fixing OMAP4 issues found by code review, and made the code more generic to OMAP3/OMAP4
  • Sent to Kevin and Benoit
  • Got some comments from Kevin

[edit] Week 48, 2010

• Not working for TI on Monday and Tuesday
• Restart working on PRCM interrupt handling to address the latest comments from Kevin and do some more testing on OMAP3
  • Fixed some minor comments from Kevin
  • Tested the pm-otg-reset branch which was supposed to fix the USB problem that prevents my BeagleBoard to enter OFF or retention, but it doesn't work
• Sent a proper merge request for the multiple consumer feature of the regulator framework
  • The patch got acked by Mark Brown
  • And merged by Liam Girdwood. So it should show up in mainline for the next merge window

[edit] Week 49, 2010

• Not available for TI (giving a training in France)

[edit] Week 50, 2010

• Goals
  • Try to finally get a kernel that really enters OFF/retention on my BeagleBoard, in order to finish the tests of the PRCM patch
    • Finally found such a kernel
    • Discovered that different API for OMAP2/3 and OMAP4 to access PRM registers have been introduced, the consequence is that my patch needs to be reworked
    • Tried to understand the bug reported by Madhusudhan Gowda from Nokia on the existing PRCM interrupt handler and see whether it impacts the new PRCM interrupt handler implementation or not
  • Reflexion on how to convert the voltage layer to the regulator framework
• Attented the OMAP tutorial hour