On Thu, Aug 29, 2013 at 12:10 PM, Mark Brown [off-list ref] wrote:

On Thu, Aug 29, 2013 at 11:25:43AM -0700, Russ Dill wrote:

quoted

On Thu, Aug 29, 2013 at 11:01 AM, Mark Brown [off-list ref] wrote:

quoted

quoted

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.

quoted

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.

I'd not assume byte based addressing for a PMIC, it's very common but
not universal.  The difficulties here assume putting this in the device
tree as explicit register I/O - I do tend to agree with Kevin that this
doesn't seem like the right abstraction.

quoted

quoted

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.

quoted

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?

I was thinking about the majority of regulators where setting a voltage
would be a single bitfield update (plus ramp delay, which is going to
need to be accounted for in the power on case).  If we need to do longer
sequences things get a bit more tricky in terms of interface but it
seems doable.

The sequence for TPS65217 on beaglebone is rather long, it's 8
register writes. It has to write the new value to the DCDC3 register
and the apply bit to the DCDC register, but both registers are
password locked registers. The password sequence is to write the
password register, then the register, then the password register
again, then the register again.

regmap would tie in in that it already has a way of describing the
format for interactions with the device so we could just reuse the same
description, and with some work we can probably reuse the code that
generates the bitstreams for sending to the devices too (though I don't
immediately see a nice way of doing that).

Not sure if this is worth the effort or not though, but then there's the
whole DT as ABI thing to worry about...

quoted

This is VDD core, so its not related to cpuidle or the M3.

It's related to the M3 if the M3 is managing it; you can have multiple
consumers for a regulator so it doesn't need to be one or the other.

Ah.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel