Nishanth' tech rambles

Writing a driver for a new regulator is usually fun, until you need to test the darned thing. Many of the users of the regulator is probably not yet ready in an development environment and need to test cant wait. I had recently a similar situation and found CONFIG_REGULATOR_VIRTUAL_CONSUMER You'd probably register and provide and regulator supply, but without a driver using it in a controlled environment (read shell script or so), it is hard to poke holes completely into your driver. Steps are rather simple. Assumption - you already have a regulator registered in the system and you are aware of the regulator name - You can also figure out it's name by the following (an example from 3.9-rc8 on Beagle-XM): # head /sys/class/regulator/*/name ==> /sys/class/regulator/regulator.0/name /sys/class/regulator/regulator.1/name /sys/class/regulator/regulator.2/name /sys/class/regulator/regulator.3/name /sys/class/regulator/regulator.4/name /sys/class/regulator/regulator.5/...

Googling around, I found this beautiful article that gives excellent explanation of how Adaptive Voltage behaves in the system. by the way, this is going to be part of my rewrite of smart reflex driver to make the voltage infrastructure a lot more cleaner and easy to use. General flow I am thinking is as follows(will change ofcourse): voltage driver |------------> No SR PMICs implementation thru regulator framework perhaps. \-------> Smart reflex driver |----> PMIC interface (for class 0 devices) |-----------------------------------\ \-----> Voltage processor driver -> Voltage controller driver Ofcourse things might change as I move on with the implementation (I need to think a little more on this), but once I am done, you should be able to see it here