Prev: select useful number of entries for DMA debugging v3...
Next: check name_len before down_read xattr_sem and sb_read in ext2_xattr_get
From: Mark Brown on 14 Jul 2010 11:50
On Wed, Jul 14, 2010 at 09:06:44PM +0530, Sundar R IYER wrote:

> > Which datasheet, and will the system design actually be varying them at
> > runtime - if it will how will it do so? This is the settings for the

> I am referring to the AB8500 device data sheet; not sure if its
> available open. I have taken the minimal/maximum figures as what is
> mentioned for each supplies.

OK, you're missing the point here. The system constraints say what's
going to be used on this actual system not what an individual component
is capable of supporting. Regulators are almost always vastly more
flexible than any system can use and so the constraints are used to tell
the regulator core what configurations can be used on a given system.
You need to check what makes sense on the system for the things that are
connected.

> > Again, is it really the case that this will happen in this system?

> Yes, if you are referring to regulator enable/disable.

For *all* supplies?

> > Nothing is currently able to actually do that, and unless every consumer
> > using a given supply is hooked into the regulator API things will go
> > wrong when some of them start doing so.

> As i said earlier, my intention is to hard code the machine constraints.
> The actual control in terms of enable/disable, controlling supply
> voltages will happen, as you say when consumers are hooked up.

Again, you need to think about what's actually hooked up. Permission to
do any of this stuff depends heavily on the set of consumers that are
actually hooked up - think about the example I mentioned above where
some of the consumers on a shared supply are hooked up and doing enables
and disables, for example. What happens when they cause the supply to
be disabled but another consumer is running?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Sundar R IYER on 14 Jul 2010 12:20
> OK, you're missing the point here. The system constraints say what's
> going to be used on this actual system not what an individual component
> is capable of supporting. Regulators are almost always vastly more
> flexible than any system can use and so the constraints are used to tell
> the regulator core what configurations can be used on a given system.
> You need to check what makes sense on the system for the things that are
> connected.
Ok.

> For *all* supplies?
Yes. whatever supplies I have listed here all can be enabled/disabled by
their consumers. Sorry to ask, but please help me to understand the
emphasis of the question. There are other supplies, which are controlled
outside the kernel and so I haven't exposed them here.

> Again, you need to think about what's actually hooked up. Permission to
> do any of this stuff depends heavily on the set of consumers that are
> actually hooked up - think about the example I mentioned above where
Agreed.

> some of the consumers on a shared supply are hooked up and doing enables
> and disables, for example. What happens when they cause the supply to
> be disabled but another consumer is running?
Again, sorry to ask(this is confusing :() - but isn't this managed by
the core? It is the core's responsibility to effectively disable a
supply when none of the consumers are using it; and to block a disable
even when a single consumer is still using it.

For eg, all the audio digital and analog supplies listed here can be
disabled/enabled by the consumer. Same goes for the VAUXn peripheral
supplies, which have shared consumers running at the same voltages.

Regards,
Sundar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Mark Brown on 14 Jul 2010 12:30
On Wed, Jul 14, 2010 at 09:39:42PM +0530, Sundar R IYER wrote:

> > For *all* supplies?

> Yes. whatever supplies I have listed here all can be enabled/disabled by
> their consumers. Sorry to ask, but please help me to understand the
> emphasis of the question. There are other supplies, which are controlled
> outside the kernel and so I haven't exposed them here.

Are you positive that in your system it is sensible for consumers to
enable and disable all the supplies? Usually there are restrictions on
what can sensibly be done on a given system. For example, disabling the
CPU core or RAM supplies from software would normally not work terribly
well.

> > some of the consumers on a shared supply are hooked up and doing enables
> > and disables, for example. What happens when they cause the supply to
> > be disabled but another consumer is running?

> Again, sorry to ask(this is confusing :() - but isn't this managed by
> the core? It is the core's responsibility to effectively disable a
> supply when none of the consumers are using it; and to block a disable
> even when a single consumer is still using it.

Right, but think about the case I'm talking about: if you've only hooked
up some but not all of the consumers then the core has no idea about the
consumers you didn't hook up. You can only do power control when *all*
the consumers needed are configured.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Sundar R IYER on 14 Jul 2010 12:50
> Are you positive that in your system it is sensible for consumers to
> enable and disable all the supplies? Usually there are restrictions on
> what can sensibly be done on a given system. For example, disabling the
> CPU core or RAM supplies from software would normally not work terribly
> well.
As I said earlier, there are other supplies which I havent exposed here,
simply because,
1. they are controlled out of the kernel, which makes it meaningless
to include them for kernel modules
2. Even if those were included, the risk of mis-controlling them due
to bad SW is very high as you say and hence safely out of SW control.

I assure you that such supplies are *not* included in this list.

> CPU core or RAM supplies from software would normally not work terribly
Also, usually the deepest(lowest) power state for the CPU core is
~0V(atleast on our platform); which can be possible only by switching
off the supplies to the core; thus effectively resulting in being
controlled by SW. Further, I dont see the point of running full supplies
to the RAM in a system idle state, when it is okay for the RAM to be
powered @ a half rating OIW accountable to the idle state latencies.

> Right, but think about the case I'm talking about: if you've only hooked
> up some but not all of the consumers then the core has no idea about the
> consumers you didn't hook up. You can only do power control when *all*
> the consumers needed are configured.
I see your point. But from an other perspective - it is *not* neccessary
to have power control only when *all* consumers are in. For eg: we have
2 peripherals sharing one of the VAUX supplies. At this moment, both the
peripherals drivers are integrated with the regulator APIs; which means
the core handles most of the work regarding control. If, one of the
peripherals isnt included in the final configuration, still, IMO, it
*does* make sense that the other active peripheral optimally manage the
supply control; which is gauranteed by the core. IOW & IMO, a consumer
that hasnt hooked up to the regulator and thus is *aware* that it isnt
sourced can be safely assumed to be non-existent.

Regards,
Sundar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Sundar R IYER on 14 Jul 2010 13:40
> There's userspace-consumer.c for exposing the control for userspace.
No. I wasnt referring to a user space control of critical supplies.

> OK, but your current set of supplies is *very* suspect since you're
> offering all this control to lists of consumers that don't exist, and
As said, dont exist for *now*.

> you've got every single supply on the board varying at runtime. This is
> unusual and normally means that someone's done what you were describing
> earlier and just put in the capabilities of the regulator rather than a
> set of constraints for the particular board.
The AB8500 is the companion chip for the DB8500. For our reference HW,
these set of regulator constraints map to the constraints for the
particular board. But, someone deciding to use the AB8500 as standalone
can have his set of regulators integrated (leaving out much more than
what I did), set of constraints as deemed to be fit!

Probably, I should remove the REGULATOR_CHANGE_VOLTAGE flag for the fixed
supplies (as in the driver) to clear up any confusing link. Should I?

> This is normal, but for fairly obvious reasons the very lowest power
> states are generally handled outside of the regulator API at a hardware
> level via hardware signals to the regulator. It's not normally part of
> the runtime constraints for use while the CPU is live.
Yes. But my point was that even at a lower level than kernel (BIOS/firmware?)
the switching would happen via SW. Please correct me if I am wrong!

> I'm not sure how you expect this to actually work in practice? It's
> going to be pretty hard for a driver to do anything constructive if the
> power to the hardware gets cut, for example. Unless you can guarantee
> that there will never be any use of the hardware without a driver with
> regulator support one driver's idea of optimal may not join up with what
> the other consumers need at all.
Very true. But, I think this will *enforce* drivers using/sharing
regulators to adhere to the framework to avoid surprises and sole-owner
misuses, which is good, now that the AB8500 regulators *are* supported.

> If you really can safely turn off all these supplies then presumably for
> the time being it'd be best to use regulator_has_full_constraints() so
> they can all be powered off at runtime now.
OOoops! I did have the patch for the platform data where I used this;
but dropped the patch for a later push. But, yes I am aware of this.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: select useful number of entries for DMA debugging v3...
Next: check name_len before down_read xattr_sem and sb_read in ext2_xattr_get