On Thu, Aug 29, 2013 at 08:42:11AM -0700, Russ Dill wrote: > The path I'm taking in this patchset is to just put the board specific > I2C sequences necessary for the CM3 coprocessor to write out into the > devicetree. I've made it as generic as I can so that other platforms > with similar issues can reuse the bindings. Because of the limitations > of the firmware size and the desire not to have some sort of byte > code, this is a write only sequence.
Making it write only seems to be a mistake - like I said in my other mail I'd expect you'd want bitfield updates here. The read and modify could be done earlier by Linux though. > Kevin Hilman is suggesting some way to query the regulator framework > for this sequence. There would be some call to the regulator framework > that would return a series of I2C commands that would be necessary to > program a regulator to a specific voltage. It would be called twice, > once for the suspend voltage, once for the resume voltage. The > regulator framework would then call into the driver that sets that > voltage, and by some method query the driver for the necessary I2C > sequence, either by some special new call, or some regmap magic. If it's just setting a single voltage then extracting the bitfield to update shouldn't be too hard for regmap based regulators. Off the top of my head I'd expect either the driver for the M3 or the cpuidle driver that talks to it to be a consumer of the regulator and then go from there. Just putting the sequence directly into the device tree doesn't feel like the right abstraction.
signature.asc
Description: Digital signature
