On Thu, Aug 29, 2013 at 11:01 AM, Mark Brown <broonie@xxxxxxxxxx> wrote: > 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. Updating bitfields in memory is pretty basic, but with I2C, each device has its own register sizes and methods of accessing registers. The first byte of an I2C sequence being a register address is pretty common though. You'd need a method of defining in the device tree piece how to modify bitfields. >> 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. It'd be a list of bitfields. So are you suggesting a regulator_ops call that would return a list of bitfield updates along with an I2C controller, an I2C device address, I2C register addressing scheme (8 bit, 16 bit, or other) and the info for each bitfield (register size)? And then each regulator driver would be updated as needed with this code. Would this be a way forward? Would regmap actually tie into this at all? This is VDD core, so its not related to cpuidle or the M3. > Just putting the sequence directly into the device tree doesn't feel > like the right abstraction. > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@xxxxxxxxxxxxxxxxxxx > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > -- 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
