[PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support

[Mark Brown]

On Thu, Aug 29, 2013 at 11:25:43AM -0700, Russ Dill wrote:
> On Thu, Aug 29, 2013 at 11:01 AM, Mark Brown <broonie at kernel.org> wrote:

> > 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.

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.

> > 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?

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.

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...

> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130829/606d058c/attachment.sig>