On Monday 23 February 2009, Mark Brown wrote:
> > > Yeah, I kind of agree. To avoid confusion from changing the names I'd
> > > be tempted to go for something like "regulator driver constraints" but
> > > it's not desparately nice.
>
> > Hence my suggestion: {regulator,machine,consumer} constraints,
> > going from bottom up. They aren't driver constraints; they
> > are hardware constraints: regulators can't supply arbitrary
> > voltages.
>
> Trouble is that the term regulator gets very overloaded and causes
> confusion.
That's why one of the *first* jobs in architecture is to
ensure the terminology doesn't easily overload ... there's
always trouble when it isn't. Despite early groans from
peanut galleries about "language lawyering" and "wanting
to code in C not English", etc. ;)
Thing is, there's already overloading here. Two types
of regulator -- "struct regulator_dev" wrapping hardware,
and the "struct regulator" is a client/consumer handle.
(And thus confusing to me, since it sounds like the more
fundamental concept, but instead it's a few layers up.)
If you're concerned about overloading terminology, then
best to address it sooner than later. I've noticed you
using the "consumer", "machine", and "regulator" terms
more or less like I suggested, and those make sense; but
the current struct names don't encourage that usage. It's
possible to adjust usage before changing names in "C".
Thankfully, in Linux global name struct changes are not
rejected out of hand.
> There's also fun and games to be had with accuracy once you
> start looking too closely at the discrete voltages.
Yes; the patch I sent is explicitly making those available.
But I ignored issues like "+/- 3% accurate output" for LDOs
(or switchers) ... if anyone really needs to address them,
patches will be needed. For now I only care that a 3.1 Volt
output can match both MMC_VDD_30_31 and MMC_VDD_31_32! ;)
- Dave
--
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
