sean at mcneil.com
Wed Aug 20 15:31:35 CEST 2008
Andy Green wrote:
> Somebody in the thread at some point said:
> | The software stack I am working with assumes:
> | 1) That the powerup of bluetooth is "1" and powerdown is "0".
> | 2) That reading back the value corresponds to the value, not opposite.
> | 3) No reset required.
> I can see we will break existing userspace assumptions if I apply this.
> I think it's better to do it your way, but how about you add a second
> sysfs node that has your semantics instead of changing behaviour of
> current one? Leave them both active.
OK, actually I don't really need reset and we can just leave it as-is
and we should certainly leave that alone. If someone does a power_on and
then sets reset=0 there should be no change. Setting power_on, however,
would do a reset now. That would mess up existing behavior possibly, but
I think users just always do both. I have no aversion to either doing an
implicit reset on power_on or having a different name. Attached is a new
patch that doesn't change semantics of reset. If a new name is
necessary, do you have a preference? power_reset? enable?
> | The following patch does this. Plus I was wondering if there is
> | something else on LDO4. Can that regulator be reduced when not powering
> | bt? Is there any power savings doing so? I've knocked it down to 0 when
> | turning off and haven't seen any problems so far.
> It won't make trouble.
Great. Does it save any power, though? Seems like the regulator is
disabled when not used so probably not.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1033 bytes
Desc: not available
Url : http://lists.openmoko.org/pipermail/openmoko-kernel/attachments/20080820/234ba58b/attachment.patch
More information about the openmoko-kernel