linux-omap.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Overo broken after recent mainline merge
@ 2009-03-14 13:24 Steve Sakoman
  2009-03-14 16:12 ` Tony Lindgren
  0 siblings, 1 reply; 19+ messages in thread
From: Steve Sakoman @ 2009-03-14 13:24 UTC (permalink / raw)
  To: linux-omap

Building from current top of tree I get the following at boot:

mmci-omap-hs mmci-omap-hs.0: Failed to get debounce clock
regulator: Unable to get requested regulator: vmmc
------------[ cut here ]------------
WARNING: at drivers/gpio/gpiolib.c:826 gpio_free+0x2c/0xe0()
Modules linked in:
[<c04456f8>] (dump_stack+0x0/0x14) from [<c0114b1c>] (warn_slowpath+0x68/0x9c)
[<c0114ab4>] (warn_slowpath+0x0/0x9c) from [<c0281dec>] (gpio_free+0x2c/0xe0)
 r3:00000000 r2:00000000
 r7:ffffffea r6:c05874fc r5:c79a8500 r4:ffffffed
[<c0281dc0>] (gpio_free+0x0/0xe0) from [<c01003c4>]
(twl_mmc_late_init+0xe4/0x130)
 r8:c05874fc r7:c79a7008 r6:c05874fc r5:c79a8500 r4:ffffffed
[<c01002e0>] (twl_mmc_late_init+0x0/0x130) from [<c0024158>]
(omap_mmc_probe+0x36c/0x560)
[<c0023dec>] (omap_mmc_probe+0x0/0x560) from [<c02c71c0>]
(platform_drv_probe+0x20/0x24)
[<c02c71a0>] (platform_drv_probe+0x0/0x24) from [<c02c631c>]
(driver_probe_device+0xd4/0x1a0)
[<c02c6248>] (driver_probe_device+0x0/0x1a0) from [<c02c6454>]
(__driver_attach+0x6c/0x90)
 r7:c7817eb0 r6:c057b0b8 r5:c79a7090 r4:c79a7008
[<c02c63e8>] (__driver_attach+0x0/0x90) from [<c02c5bb0>]
(bus_for_each_dev+0x54/0x90)
 r6:c057b0b8 r5:c02c63e8 r4:00000000
[<c02c5b5c>] (bus_for_each_dev+0x0/0x90) from [<c02c615c>]
(driver_attach+0x20/0x28)
 r7:c7a3bf80 r6:c057b0b8 r5:c002b7e8 r4:00000000
[<c02c613c>] (driver_attach+0x0/0x28) from [<c02c5430>]
(bus_add_driver+0xa8/0x20c)
[<c02c5388>] (bus_add_driver+0x0/0x20c) from [<c02c66a0>]
(driver_register+0xb4/0x140)
 r8:00000000 r7:c0023dd0 r6:c057b0b8 r5:c002b7e8 r4:c002b6c0
[<c02c65ec>] (driver_register+0x0/0x140) from [<c02c7644>]
(platform_driver_register+0x6c/0x88)
 r8:00000000 r7:c0023dd0 r6:00000000 r5:c002b7e8 r4:c002b6c0
[<c02c75d8>] (platform_driver_register+0x0/0x88) from [<c0023de4>]
(omap_mmc_init+0x14/0x1c)
[<c0023dd0>] (omap_mmc_init+0x0/0x1c) from [<c00f22b0>]
(do_one_initcall+0x58/0x198)
[<c00f2258>] (do_one_initcall+0x0/0x198) from [<c00083f8>]
(kernel_init+0x80/0xf0)
 r8:00000000 r7:00000000 r6:00000000 r5:c002b7e8 r4:c002b6c0
[<c0008378>] (kernel_init+0x0/0xf0) from [<c0117ac4>] (do_exit+0x0/0x688)
 r5:00000000 r4:00000000
---[ end trace b8b5cc211eafb14f ]---
mmci-omap-hs mmci-omap-hs.0: err -19 configuring card detect
mmci-omap-hs mmci-omap-hs.1: Failed to get debounce clock
regulator: Unable to get requested regulator: vmmc

I've collected Dave's recent recent regulator patches and will try
again with those applied.

Steve

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Overo broken after recent mainline merge
  2009-03-14 13:24 Overo broken after recent mainline merge Steve Sakoman
@ 2009-03-14 16:12 ` Tony Lindgren
  2009-03-14 19:08   ` David Brownell
  0 siblings, 1 reply; 19+ messages in thread
From: Tony Lindgren @ 2009-03-14 16:12 UTC (permalink / raw)
  To: Steve Sakoman; +Cc: linux-omap

* Steve Sakoman <sakoman@gmail.com> [090314 06:25]:
> Building from current top of tree I get the following at boot:
> 
> mmci-omap-hs mmci-omap-hs.0: Failed to get debounce clock
> regulator: Unable to get requested regulator: vmmc
> ------------[ cut here ]------------
> WARNING: at drivers/gpio/gpiolib.c:826 gpio_free+0x2c/0xe0()
> Modules linked in:
> [<c04456f8>] (dump_stack+0x0/0x14) from [<c0114b1c>] (warn_slowpath+0x68/0x9c)
> [<c0114ab4>] (warn_slowpath+0x0/0x9c) from [<c0281dec>] (gpio_free+0x2c/0xe0)
>  r3:00000000 r2:00000000
>  r7:ffffffea r6:c05874fc r5:c79a8500 r4:ffffffed
> [<c0281dc0>] (gpio_free+0x0/0xe0) from [<c01003c4>]
> (twl_mmc_late_init+0xe4/0x130)
>  r8:c05874fc r7:c79a7008 r6:c05874fc r5:c79a8500 r4:ffffffed
> [<c01002e0>] (twl_mmc_late_init+0x0/0x130) from [<c0024158>]
> (omap_mmc_probe+0x36c/0x560)
> [<c0023dec>] (omap_mmc_probe+0x0/0x560) from [<c02c71c0>]
> (platform_drv_probe+0x20/0x24)
> [<c02c71a0>] (platform_drv_probe+0x0/0x24) from [<c02c631c>]
> (driver_probe_device+0xd4/0x1a0)
> [<c02c6248>] (driver_probe_device+0x0/0x1a0) from [<c02c6454>]
> (__driver_attach+0x6c/0x90)
>  r7:c7817eb0 r6:c057b0b8 r5:c79a7090 r4:c79a7008
> [<c02c63e8>] (__driver_attach+0x0/0x90) from [<c02c5bb0>]
> (bus_for_each_dev+0x54/0x90)
>  r6:c057b0b8 r5:c02c63e8 r4:00000000
> [<c02c5b5c>] (bus_for_each_dev+0x0/0x90) from [<c02c615c>]
> (driver_attach+0x20/0x28)
>  r7:c7a3bf80 r6:c057b0b8 r5:c002b7e8 r4:00000000
> [<c02c613c>] (driver_attach+0x0/0x28) from [<c02c5430>]
> (bus_add_driver+0xa8/0x20c)
> [<c02c5388>] (bus_add_driver+0x0/0x20c) from [<c02c66a0>]
> (driver_register+0xb4/0x140)
>  r8:00000000 r7:c0023dd0 r6:c057b0b8 r5:c002b7e8 r4:c002b6c0
> [<c02c65ec>] (driver_register+0x0/0x140) from [<c02c7644>]
> (platform_driver_register+0x6c/0x88)
>  r8:00000000 r7:c0023dd0 r6:00000000 r5:c002b7e8 r4:c002b6c0
> [<c02c75d8>] (platform_driver_register+0x0/0x88) from [<c0023de4>]
> (omap_mmc_init+0x14/0x1c)
> [<c0023dd0>] (omap_mmc_init+0x0/0x1c) from [<c00f22b0>]
> (do_one_initcall+0x58/0x198)
> [<c00f2258>] (do_one_initcall+0x0/0x198) from [<c00083f8>]
> (kernel_init+0x80/0xf0)
>  r8:00000000 r7:00000000 r6:00000000 r5:c002b7e8 r4:c002b6c0
> [<c0008378>] (kernel_init+0x0/0xf0) from [<c0117ac4>] (do_exit+0x0/0x688)
>  r5:00000000 r4:00000000
> ---[ end trace b8b5cc211eafb14f ]---
> mmci-omap-hs mmci-omap-hs.0: err -19 configuring card detect
> mmci-omap-hs mmci-omap-hs.1: Failed to get debounce clock
> regulator: Unable to get requested regulator: vmmc
> 
> I've collected Dave's recent recent regulator patches and will try
> again with those applied.

Thanks, let me know what we're missing in l-o tree.. I probably
won't have a chance to look at it until Monday.

Tony

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Overo broken after recent mainline merge
  2009-03-14 16:12 ` Tony Lindgren
@ 2009-03-14 19:08   ` David Brownell
  2009-03-14 20:22     ` Mark Brown
                       ` (2 more replies)
  0 siblings, 3 replies; 19+ messages in thread
From: David Brownell @ 2009-03-14 19:08 UTC (permalink / raw)
  To: Tony Lindgren, Steve Sakoman; +Cc: linux-omap

On Saturday 14 March 2009, Tony Lindgren wrote:
> 
> > I've collected Dave's recent recent regulator patches and will try
> > again with those applied.
> 
> Thanks, let me know what we're missing in l-o tree.. I probably
> won't have a chance to look at it until Monday.

I suggest this as the current solution ... though the "right"
long term fix is still an open question.

The basic problem is that still-unfixed goofage in the regulator
framework:  it seriously mis-handles regulators that bootloaders
leave enabled.  This can be teased apart into at least two bugs,
possibly as many as four.  The fix for one of them is queued in
the regulator-next tree.

One workable solution is to use the twl4030-power driver to
initialize power resources including VMMC1 (I'll send a sample
patch) but that requires lots of per-board updates.  That will
remove the need for regulator-core fixes.

- Dave


====== CUT HERE
From: David Brownell <dbrownell@users.sourceforge.net>

Make the regulator setup code simpler and more consistent:

 - The only difference between "boot_on" and "always_on" is
   that an "always_on" regulator won't be disabled.  Both will
   be active (and usecount will be 1) on return from setup.

 - Regulators not marked as "boot_on" or "always_on" won't
   be active (and usecount will be 0) on return from setup.

The exception to that simple policy is when there's a non-Linux
interface to the regulator ... e.g. if either a DSP or the CPU
running Linux can enable the regulator, and the DSP needs it to
be on, then it will be on.

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
---
 drivers/regulator/core.c |   47 +++++++++++++++++++++++++++++----------------
 1 file changed, 31 insertions(+), 16 deletions(-)

--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -711,6 +711,7 @@ static int set_machine_constraints(struc
 	int ret = 0;
 	const char *name;
 	struct regulator_ops *ops = rdev->desc->ops;
+	int enable = 0;
 
 	if (constraints->name)
 		name = constraints->name;
@@ -799,10 +800,6 @@ static int set_machine_constraints(struc
 			}
 	}
 
-	/* are we enabled at boot time by firmware / bootloader */
-	if (rdev->constraints->boot_on)
-		rdev->use_count = 1;
-
 	/* do we need to setup our suspend state */
 	if (constraints->initial_state) {
 		ret = suspend_prepare(rdev, constraints->initial_state);
@@ -814,21 +811,39 @@ static int set_machine_constraints(struc
 		}
 	}
 
-	/* if always_on is set then turn the regulator on if it's not
-	 * already on. */
-	if (constraints->always_on && ops->enable &&
-	    ((ops->is_enabled && !ops->is_enabled(rdev)) ||
-	     (!ops->is_enabled && !constraints->boot_on))) {
-		ret = ops->enable(rdev);
-		if (ret < 0) {
-			printk(KERN_ERR "%s: failed to enable %s\n",
-			       __func__, name);
-			rdev->constraints = NULL;
-			goto out;
+	/* Should this be enabled when we return from here?  The difference
+	 * between "boot_on" and "always_on" is that "always_on" regulators
+	 * won't ever be disabled.
+	 */
+	if (constraints->boot_on || constraints->always_on)
+		enable = 1;
+
+	/* Make sure the regulator isn't wrongly enabled or disabled.
+	 * Bootloaders are often sloppy about leaving things on; and
+	 * sometimes Linux wants to use a different model.
+	 */
+	if (enable) {
+		if (ops->enable) {
+			ret = ops->enable(rdev);
+			if (ret < 0)
+				pr_warning("%s: %s disable --> %d\n",
+					       __func__, name, ret);
+		}
+		if (ret >= 0)
+			rdev->use_count = 1;
+	} else {
+		if (ops->disable) {
+			ret = ops->disable(rdev);
+			if (ret < 0)
+				pr_warning("%s: %s disable --> %d\n",
+					       __func__, name, ret);
 		}
 	}
 
-	print_constraints(rdev);
+	if (ret < 0)
+		rdev->constraints = NULL;
+	else
+		print_constraints(rdev);
 out:
 	return ret;
 }



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Overo broken after recent mainline merge
  2009-03-14 19:08   ` David Brownell
@ 2009-03-14 20:22     ` Mark Brown
  2009-03-14 21:14       ` David Brownell
  2009-03-14 23:47     ` Steve Sakoman
  2009-03-20 19:18     ` [APPLIED] " Tony Lindgren
  2 siblings, 1 reply; 19+ messages in thread
From: Mark Brown @ 2009-03-14 20:22 UTC (permalink / raw)
  To: David Brownell; +Cc: Tony Lindgren, Steve Sakoman, linux-omap

On Sat, Mar 14, 2009 at 12:08:30PM -0700, David Brownell wrote:

> The basic problem is that still-unfixed goofage in the regulator
> framework:  it seriously mis-handles regulators that bootloaders
> leave enabled.  This can be teased apart into at least two bugs,
> possibly as many as four.  The fix for one of them is queued in
> the regulator-next tree.

For clarity, what David is referring to here is that it's not currently
possible for the machine constraints to turn off a regulator that has
been left enabled when the kernel starts.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Overo broken after recent mainline merge
  2009-03-14 20:22     ` Mark Brown
@ 2009-03-14 21:14       ` David Brownell
  2009-03-14 22:34         ` Mark Brown
  0 siblings, 1 reply; 19+ messages in thread
From: David Brownell @ 2009-03-14 21:14 UTC (permalink / raw)
  To: Mark Brown; +Cc: Tony Lindgren, Steve Sakoman, linux-omap

On Saturday 14 March 2009, Mark Brown wrote:
> On Sat, Mar 14, 2009 at 12:08:30PM -0700, David Brownell wrote:
> 
> > The basic problem is that still-unfixed goofage in the regulator
> > framework:  it seriously mis-handles regulators that bootloaders
> > leave enabled.  This can be teased apart into at least two bugs,
> > possibly as many as four.  The fix for one of them is queued in
> > the regulator-next tree.
> 
> For clarity, what David is referring to here is that it's not currently
> possible for the machine constraints to turn off a regulator that has
> been left enabled when the kernel starts.

Not quite -- that would be one solution, for the first
several cases I had to deal with.

But thinking about how to handle the video support makes
it clear that's not always the best solution.  One needs
bootloaders to be able to throw a splash screen which
stays active until the window system kicks in ... but
turning off video regulators would clearly blacken the
screen, which is the wrong model.  (And marking them as
"always on" or "boot_on" is wrong for other reasons.)

The way clocks handle that is with a late disable,
so drivers have a chance to start up.  You rejected
the REGULATOR_DISABLE_UNUSED patch I sent, applying
that model ... and that's why I started to think about
other approaches, as in the "early disable" patch I
sent earlier in this thread.

A third approach (after applying that one patch that's
in the regulator-next tree) would be

	if (rdev->is_enabled() > 0)
		rdev->use_count = 1;

when initializing regulators.  I updated the TWL4030
code so is_enabled() checks only the Linux enables,
while get_status() reports the true state, so maybe
that would be a solution you'd accept.

Of course that makes use_count be even more of a
misnomer, but that's a separate issue ... refcounts
should be handled by the driver model.

- Dave



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Overo broken after recent mainline merge
  2009-03-14 21:14       ` David Brownell
@ 2009-03-14 22:34         ` Mark Brown
  2009-03-15  3:18           ` David Brownell
  2009-03-15  3:36           ` David Brownell
  0 siblings, 2 replies; 19+ messages in thread
From: Mark Brown @ 2009-03-14 22:34 UTC (permalink / raw)
  To: David Brownell; +Cc: Tony Lindgren, Steve Sakoman, linux-omap

On Sat, Mar 14, 2009 at 02:14:05PM -0700, David Brownell wrote:

> But thinking about how to handle the video support makes
> it clear that's not always the best solution.  One needs
> bootloaders to be able to throw a splash screen which
> stays active until the window system kicks in ... but
> turning off video regulators would clearly blacken the
> screen, which is the wrong model.  (And marking them as
> "always on" or "boot_on" is wrong for other reasons.)

Yes, this sounds like one of those cases where just leaving the
regulator alone and letting the drivers figure things out will probably
work best.

> The way clocks handle that is with a late disable,
> so drivers have a chance to start up.  You rejected

This behaviour is specific to the OMAP implementation of the clock API
(and is an optional feature of that from the looks of it).  It's
probably also worth rembembering that the clock API is working in a very
much more controlled domain (in that it mostly only covers well known
devices on a given architecture), requires little if any per-machine
setup and isn't an optional feature.  Most of the clock API setup is a
feature of the SoC CPU rather than of the board.

> the REGULATOR_DISABLE_UNUSED patch I sent, applying
> that model ... and that's why I started to think about
> other approaches, as in the "early disable" patch I
> sent earlier in this thread.

I didn't reject the concept - I asked for some changes in the interface
to make it be something that the machine drivers can control rather than
have it be a Kconfig option that's selected by end users and can't be
part of the power description that the machine has to have anyway.  As I
said at the time if it were something that could be enabled by the
machine driver, either per regulator or per system, then I'd be happy
with this approach.  I think that it is a better approach than the one
you're currently going for.

Unlike the clock API the machines are going to have to provide some
configuration for the regulators for this feature to be useful (to
specify the supplies that are actually in use) so there is little
additional cost to them in requesting this feature.  If it were only a
Kconfig option then people building the kernel have to know somehow how
well set up the regulators are for their system and some people will end
up with suboptimal configurations because they don't
know if they can turn the option on or not.

> A third approach (after applying that one patch that's
> in the regulator-next tree) would be

> 	if (rdev->is_enabled() > 0)
> 		rdev->use_count = 1;

That won't work with consumers that can share their supply - they can't
tell if the regulator was enabled because it was left on at startup or
if it was enabled by some other consumer.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Overo broken after recent mainline merge
  2009-03-14 19:08   ` David Brownell
  2009-03-14 20:22     ` Mark Brown
@ 2009-03-14 23:47     ` Steve Sakoman
  2009-03-15  2:00       ` David Brownell
  2009-03-20 19:18     ` [APPLIED] " Tony Lindgren
  2 siblings, 1 reply; 19+ messages in thread
From: Steve Sakoman @ 2009-03-14 23:47 UTC (permalink / raw)
  To: David Brownell, Tony Lindgren, linux-omap

On Sat, Mar 14, 2009 at 12:08 PM, David Brownell <david-b@pacbell.net> wrote:
> On Saturday 14 March 2009, Tony Lindgren wrote:
>>
>> > I've collected Dave's recent recent regulator patches and will try
>> > again with those applied.
>>
>> Thanks, let me know what we're missing in l-o tree.. I probably
>> won't have a chance to look at it until Monday.
>
> I suggest this as the current solution ... though the "right"
> long term fix is still an open question.
>
> The basic problem is that still-unfixed goofage in the regulator
> framework:  it seriously mis-handles regulators that bootloaders
> leave enabled.  This can be teased apart into at least two bugs,
> possibly as many as four.  The fix for one of them is queued in
> the regulator-next tree.
>
> One workable solution is to use the twl4030-power driver to
> initialize power resources including VMMC1 (I'll send a sample
> patch) but that requires lots of per-board updates.  That will
> remove the need for regulator-core fixes.

Dave,

I tried another build with three of your patches that didn't seem to
applied yet:

1. This patch hooks up the twl4030 MMC1 regulator on Overo . . .
2. Make the regulator setup code simpler and more consistent . . .
3. Fix some refcounting issues in the regulator framework . . .

My build also includes a patch for DSS2, but I don't believe that to
be an issue.

I don't get the warning now, but mmc0 is still broken (boot log below)

Steve

Linux version 2.6.29-rc8-omap1 (sakoman@tera) (gcc version 4.3.1 (GCC)
) #1 Sat Mar 14 11:23:06 PDT 2009
CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=10c5387f
CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
Machine: Gumstix Overo
omapfb_early_vram, 12582912, 0x0
Memory policy: ECC disabled, Data cache writeback
OMAP3430 ES2.1
SRAM: Mapped pa 0x40200000 to va 0xd7000000 size: 0x100000
Reserving 12582912 bytes SDRAM for VRAM
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 32512
Kernel command line: console=ttyS2,115200n8 vram=12M
omapfb.mode=dvi:1024x768MR-16@60 omapfb.debug=y omapdss.def_disp=dvi
root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait
Clocking rate (Crystal/DPLL/ARM core): 26.0/331/500 MHz
GPMC revision 5.0
IRQ: Found an INTC at 0xd8200000 (revision 4.0) with 96 interrupts
Total of 96 interrupts on 1 active controller
OMAP34xx GPIO hardware version 2.5
PID hash table entries: 512 (order: 9, 2048 bytes)
OMAP clockevent source: GPTIMER1 at 32768 Hz
Console: colour dummy device 80x30
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 128MB = 128MB total
Memory: 111516KB available (4468K code, 531K data, 936K init)
Calibrating delay loop... 499.92 BogoMIPS (lpj=1949696)
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
net_namespace: 764 bytes
regulator: core version 0.5
NET: Registered protocol family 16
Found NAND on CS0
Registering NAND on CS0
OMAP DMA hardware revision 4.0
bio: create slab <bio-0> at 0
OMAP DSS rev 2.0
OMAP DISPC rev 3.0
OMAP VENC rev 2
i2c_omap i2c_omap.1: bus 1 rev3.12 at 2600 kHz
twl4030: PIH (irq 7) chaining IRQs 368..375
twl4030: power (irq 373) chaining IRQs 376..383
twl4030: gpio (irq 368) chaining IRQs 384..401
set_machine_constraints: disable 'VMMC1' --> 0
regulator: VMMC1: 1850 <--> 3150 mV normal standby
set_machine_constraints: disable 'VUSB1V5' --> 0
regulator: VUSB1V5: 1500 <--> 0 mV normal standby
set_machine_constraints: disable 'VUSB1V8' --> 0
regulator: VUSB1V8: 1800 <--> 0 mV normal standby
set_machine_constraints: disable 'VUSB3V1' --> 0
regulator: VUSB3V1: 3100 <--> 0 mV normal standby
i2c_omap i2c_omap.3: bus 3 rev3.12 at 400 kHz
SCSI subsystem initialized
twl4030_usb twl4030_usb: Initialized TWL4030 USB module
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
Bluetooth: Core ver 2.14
NET: Registered protocol family 31
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
cfg80211: Using static regulatory domain info
cfg80211: Regulatory domain: US
	(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
	(2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2700 mBm)
	(5170000 KHz - 5190000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
	(5190000 KHz - 5210000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
	(5210000 KHz - 5230000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
	(5230000 KHz - 5330000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
	(5735000 KHz - 5835000 KHz @ 40000 KHz), (600 mBi, 3000 mBm)
cfg80211: Calling CRDA for country: US
musb_hdrc: version 6.0, musb-dma, host, debug=0
musb_hdrc: USB Host mode controller at d80ab000 using DMA, IRQ 92
musb_hdrc musb_hdrc: MUSB HDRC host driver
musb_hdrc musb_hdrc: new USB bus registered, assigned bus number 1
usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: MUSB HDRC host driver
usb usb1: Manufacturer: Linux 2.6.29-rc8-omap1 musb-hcd
usb usb1: SerialNumber: musb_hdrc
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 4096 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
TCP reno registered
NET: Registered protocol family 1
VFS: Disk quotas dquot_6.5.2
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
JFFS2 version 2.2. (NAND) (SUMMARY)  © 2001-2006 Red Hat, Inc.
msgmni has been set to 218
alg: No test for stdrng (krng)
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
serial8250.0: ttyS0 at MMIO 0x4806a000 (irq = 72) is a ST16654
serial8250.0: ttyS1 at MMIO 0x4806c000 (irq = 73) is a ST16654
serial8250.0: ttyS2 at MMIO 0x49020000 (irq = 74) is a ST16654
console [ttyS2] enabled
brd: module loaded
loop: module loaded
usbcore: registered new interface driver asix
usbcore: registered new interface driver cdc_ether
i2c /dev entries driver
Driver 'sd' needs updating - please use bus_type methods
omap2-nand driver initializing
NAND device: Manufacturer ID: 0x2c, Chip ID: 0xba (Micron NAND 256MiB
1,8V 16-bit)
cmdlinepart partition parsing not available
Creating 5 MTD partitions on "omap2-nand":
0x000000000000-0x000000080000 : "xloader"
0x000000080000-0x000000240000 : "uboot"
0x000000240000-0x000000280000 : "uboot environment"
0x000000280000-0x000000680000 : "linux"
0x000000680000-0x000010000000 : "rootfs"
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci-omap ehci-omap.0: OMAP-EHCI Host Controller
ehci-omap ehci-omap.0: new USB bus registered, assigned bus number 2
ehci-omap ehci-omap.0: irq 77, io mem 0x48064800
ehci-omap ehci-omap.0: USB 2.0 started, EHCI 1.00
usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb2: Product: OMAP-EHCI Host Controller
usb usb2: Manufacturer: Linux 2.6.29-rc8-omap1 ehci_hcd
usb usb2: SerialNumber: ehci-omap.0
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 3 ports detected
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
udc: OMAP UDC driver, version: 4 October 2004 (iso) (dma)
mice: PS/2 mouse device common for all mice
twl4030_rtc twl4030_rtc: rtc core: registered twl4030_rtc as rtc0
twl4030_rtc twl4030_rtc: Enabling TWL4030-RTC.
OMAP Watchdog Timer Rev 0x31: initial timeout 60 sec
Bluetooth: HCI UART driver ver 2.2
Bluetooth: HCI H4 protocol initialized
Bluetooth: HCI BCSP protocol initialized
Bluetooth: Broadcom Blutonium firmware driver ver 1.2
usbcore: registered new interface driver bcm203x
Bluetooth: Digianswer Bluetooth USB driver ver 0.10
usbcore: registered new interface driver bpa10x
sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
mmci-omap-hs mmci-omap-hs.0: Failed to get debounce clock
regulator: Unable to get requested regulator: vmmc_aux
mmci-omap-hs mmci-omap-hs.1: Failed to get debounce clock
regulator: Unable to get requested regulator: vmmc
mmc_rescan: card ocr from io_op=0x90ff8000, err = 0
usbcore: registered new interface driver usbhid
usbhid: v2.6:USB HID core driver
Advanced Linux Sound Architecture Driver Version 1.0.18a.
usbcore: registered new interface driver snd-usb-audio
No device for DAI twl4030
No device for DAI omap-mcbsp-dai-0
No device for DAI omap-mcbsp-dai-1
No device for DAI omap-mcbsp-dai-2
No device for DAI omap-mcbsp-dai-3
No device for DAI omap-mcbsp-dai-4
overo SoC init
TWL4030 Audio Codec init
asoc: twl4030 <-> omap-mcbsp-dai-0 mapping ok
ALSA device list:
  #0: overo (twl4030)
oprofile: using arm/armv7
TCP cubic registered
NET: Registered protocol family 17
NET: Registered protocol family 15
Bluetooth: L2CAP ver 2.11
Bluetooth: L2CAP socket layer initialized
Bluetooth: SCO (Voice Link) ver 0.6
Bluetooth: SCO socket layer initialized
Bluetooth: RFCOMM socket layer initialized
Bluetooth: RFCOMM TTY layer initialized
Bluetooth: RFCOMM ver 1.10
Bluetooth: BNEP (Ethernet Emulation) ver 1.3
Bluetooth: BNEP filters: protocol multicast
Bluetooth: HIDP (Human Interface Emulation) ver 1.2
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
ThumbEE CPU extension supported.
Power Management for TI OMAP3.
SmartReflex driver initialized
VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 1
fbcvt: 1024x768@60: CVT Name - .786M3-R
Console: switching to colour frame buffer device 128x48
clock: clksel_round_rate_div: dpll4_m4_ck target_rate 86400000
clock: new_div = 5, new_rate = 86400000
twl4030_rtc twl4030_rtc: setting system clock to 2000-01-01 00:00:00
UTC (946684800)
Waiting for root device /dev/mmcblk0p2...
mmc1: new SDIO card at address 0001
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Overo broken after recent mainline merge
  2009-03-14 23:47     ` Steve Sakoman
@ 2009-03-15  2:00       ` David Brownell
  2009-03-15  3:56         ` Steve Sakoman
  2009-03-15 19:56         ` Steve Sakoman
  0 siblings, 2 replies; 19+ messages in thread
From: David Brownell @ 2009-03-15  2:00 UTC (permalink / raw)
  To: Steve Sakoman; +Cc: Tony Lindgren, linux-omap

On Saturday 14 March 2009, Steve Sakoman wrote:
> On Sat, Mar 14, 2009 at 12:08 PM, David Brownell <david-b@pacbell.net> wrote:
> > On Saturday 14 March 2009, Tony Lindgren wrote:
> >>
> >> > I've collected Dave's recent recent regulator patches and will try
> >> > again with those applied.
> >>
> >> Thanks, let me know what we're missing in l-o tree.. I probably
> >> won't have a chance to look at it until Monday.
> >
> > I suggest this as the current solution ... though the "right"
> > long term fix is still an open question.
> >
> > The basic problem is that still-unfixed goofage in the regulator
> > framework:  it seriously mis-handles regulators that bootloaders
> > leave enabled.  This can be teased apart into at least two bugs,
> > possibly as many as four.  The fix for one of them is queued in
> > the regulator-next tree.
> >
> > One workable solution is to use the twl4030-power driver to
> > initialize power resources including VMMC1 (I'll send a sample
> > patch) but that requires lots of per-board updates.  That will
> > remove the need for regulator-core fixes.
> 
> Dave,
> 
> I tried another build with three of your patches that didn't seem to
> applied yet:
> 
> 1. This patch hooks up the twl4030 MMC1 regulator on Overo . . .

Right.


> 2. Make the regulator setup code simpler and more consistent . . .

Which I sent on this thread.


> 3. Fix some refcounting issues in the regulator framework . . .

Not sure which one that is.  Sounds like one that I sent
against regulator-next, which wouldn't be needed given #2
above (regulator-next has two refcount fix patches).

 
> My build also includes a patch for DSS2, but I don't believe that to
> be an issue.

Right.


> I don't get the warning now, but mmc0 is still broken (boot log below)

Works for me, and I think you've got all the patches that
should matter.   This is against today's GIT, yes?
Does taking #3 away help?


> Steve
> 
> Linux version 2.6.29-rc8-omap1 (sakoman@tera) (gcc version 4.3.1 (GCC)
> ) #1 Sat Mar 14 11:23:06 PDT 2009
> CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=10c5387f
> CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
> Machine: Gumstix Overo
> omapfb_early_vram, 12582912, 0x0
> Memory policy: ECC disabled, Data cache writeback
> OMAP3430 ES2.1

I hear ES3.1 will have better-working EHCI.  ;)

> SRAM: Mapped pa 0x40200000 to va 0xd7000000 size: 0x100000
> Reserving 12582912 bytes SDRAM for VRAM
> Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 32512
> Kernel command line: console=ttyS2,115200n8 vram=12M
> omapfb.mode=dvi:1024x768MR-16@60 omapfb.debug=y omapdss.def_disp=dvi
> root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait
> Clocking rate (Crystal/DPLL/ARM core): 26.0/331/500 MHz
> GPMC revision 5.0
> IRQ: Found an INTC at 0xd8200000 (revision 4.0) with 96 interrupts
> Total of 96 interrupts on 1 active controller
> OMAP34xx GPIO hardware version 2.5
> PID hash table entries: 512 (order: 9, 2048 bytes)
> OMAP clockevent source: GPTIMER1 at 32768 Hz
> Console: colour dummy device 80x30
> Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
> Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
> Memory: 128MB = 128MB total
> Memory: 111516KB available (4468K code, 531K data, 936K init)
> Calibrating delay loop... 499.92 BogoMIPS (lpj=1949696)
> Mount-cache hash table entries: 512
> CPU: Testing write buffer coherency: ok
> net_namespace: 764 bytes
> regulator: core version 0.5
> NET: Registered protocol family 16
> Found NAND on CS0
> Registering NAND on CS0
> OMAP DMA hardware revision 4.0
> bio: create slab <bio-0> at 0
> OMAP DSS rev 2.0
> OMAP DISPC rev 3.0
> OMAP VENC rev 2
> i2c_omap i2c_omap.1: bus 1 rev3.12 at 2600 kHz
> twl4030: PIH (irq 7) chaining IRQs 368..375
> twl4030: power (irq 373) chaining IRQs 376..383
> twl4030: gpio (irq 368) chaining IRQs 384..401
> set_machine_constraints: disable 'VMMC1' --> 0

So the initial state is as expected, good ...

> regulator: VMMC1: 1850 <--> 3150 mV normal standby
> set_machine_constraints: disable 'VUSB1V5' --> 0
> regulator: VUSB1V5: 1500 <--> 0 mV normal standby
> set_machine_constraints: disable 'VUSB1V8' --> 0
> regulator: VUSB1V8: 1800 <--> 0 mV normal standby
> set_machine_constraints: disable 'VUSB3V1' --> 0
> regulator: VUSB3V1: 3100 <--> 0 mV normal standby
> i2c_omap i2c_omap.3: bus 3 rev3.12 at 400 kHz
> SCSI subsystem initialized
> twl4030_usb twl4030_usb: Initialized TWL4030 USB module
> usbcore: registered new interface driver usbfs
> usbcore: registered new interface driver hub
> usbcore: registered new device driver usb
> Bluetooth: Core ver 2.14
> NET: Registered protocol family 31
> Bluetooth: HCI device and connection manager initialized
> Bluetooth: HCI socket layer initialized
> cfg80211: Using static regulatory domain info
> cfg80211: Regulatory domain: US
> 	(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
> 	(2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2700 mBm)
> 	(5170000 KHz - 5190000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
> 	(5190000 KHz - 5210000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
> 	(5210000 KHz - 5230000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
> 	(5230000 KHz - 5330000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
> 	(5735000 KHz - 5835000 KHz @ 40000 KHz), (600 mBi, 3000 mBm)
> cfg80211: Calling CRDA for country: US
> musb_hdrc: version 6.0, musb-dma, host, debug=0
> musb_hdrc: USB Host mode controller at d80ab000 using DMA, IRQ 92
> musb_hdrc musb_hdrc: MUSB HDRC host driver
> musb_hdrc musb_hdrc: new USB bus registered, assigned bus number 1
> usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
> usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> usb usb1: Product: MUSB HDRC host driver
> usb usb1: Manufacturer: Linux 2.6.29-rc8-omap1 musb-hcd
> usb usb1: SerialNumber: musb_hdrc
> usb usb1: configuration #1 chosen from 1 choice
> hub 1-0:1.0: USB hub found
> hub 1-0:1.0: 1 port detected
> NET: Registered protocol family 2
> IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
> TCP established hash table entries: 4096 (order: 3, 32768 bytes)
> TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
> TCP: Hash tables configured (established 4096 bind 4096)
> TCP reno registered
> NET: Registered protocol family 1
> VFS: Disk quotas dquot_6.5.2
> Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
> JFFS2 version 2.2. (NAND) (SUMMARY)  © 2001-2006 Red Hat, Inc.
> msgmni has been set to 218
> alg: No test for stdrng (krng)
> io scheduler noop registered
> io scheduler anticipatory registered (default)
> io scheduler deadline registered
> io scheduler cfq registered
> Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
> serial8250.0: ttyS0 at MMIO 0x4806a000 (irq = 72) is a ST16654
> serial8250.0: ttyS1 at MMIO 0x4806c000 (irq = 73) is a ST16654
> serial8250.0: ttyS2 at MMIO 0x49020000 (irq = 74) is a ST16654
> console [ttyS2] enabled
> brd: module loaded
> loop: module loaded
> usbcore: registered new interface driver asix
> usbcore: registered new interface driver cdc_ether
> i2c /dev entries driver
> Driver 'sd' needs updating - please use bus_type methods
> omap2-nand driver initializing
> NAND device: Manufacturer ID: 0x2c, Chip ID: 0xba (Micron NAND 256MiB
> 1,8V 16-bit)
> cmdlinepart partition parsing not available
> Creating 5 MTD partitions on "omap2-nand":
> 0x000000000000-0x000000080000 : "xloader"
> 0x000000080000-0x000000240000 : "uboot"
> 0x000000240000-0x000000280000 : "uboot environment"
> 0x000000280000-0x000000680000 : "linux"
> 0x000000680000-0x000010000000 : "rootfs"
> ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> ehci-omap ehci-omap.0: OMAP-EHCI Host Controller
> ehci-omap ehci-omap.0: new USB bus registered, assigned bus number 2
> ehci-omap ehci-omap.0: irq 77, io mem 0x48064800
> ehci-omap ehci-omap.0: USB 2.0 started, EHCI 1.00
> usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
> usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> usb usb2: Product: OMAP-EHCI Host Controller
> usb usb2: Manufacturer: Linux 2.6.29-rc8-omap1 ehci_hcd
> usb usb2: SerialNumber: ehci-omap.0
> usb usb2: configuration #1 chosen from 1 choice
> hub 2-0:1.0: USB hub found
> hub 2-0:1.0: 3 ports detected
> Initializing USB Mass Storage driver...
> usbcore: registered new interface driver usb-storage
> USB Mass Storage support registered.
> udc: OMAP UDC driver, version: 4 October 2004 (iso) (dma)
> mice: PS/2 mouse device common for all mice
> twl4030_rtc twl4030_rtc: rtc core: registered twl4030_rtc as rtc0
> twl4030_rtc twl4030_rtc: Enabling TWL4030-RTC.
> OMAP Watchdog Timer Rev 0x31: initial timeout 60 sec
> Bluetooth: HCI UART driver ver 2.2
> Bluetooth: HCI H4 protocol initialized
> Bluetooth: HCI BCSP protocol initialized
> Bluetooth: Broadcom Blutonium firmware driver ver 1.2
> usbcore: registered new interface driver bcm203x
> Bluetooth: Digianswer Bluetooth USB driver ver 0.10
> usbcore: registered new interface driver bpa10x
> sdhci: Secure Digital Host Controller Interface driver
> sdhci: Copyright(c) Pierre Ossman

Why do you have SDHCI configured??


> mmci-omap-hs mmci-omap-hs.0: Failed to get debounce clock
> regulator: Unable to get requested regulator: vmmc_aux

Right -- mmci-omap-hs.0 only has vmmc (twl4030 VMMC1).


> mmci-omap-hs mmci-omap-hs.1: Failed to get debounce clock
> regulator: Unable to get requested regulator: vmmc

And mmci-omap-hs.1 doesn't have any regulators at all;
a "fixed.c" regulator would make sense, but it's not
going to be usable till 2.6.30.


> mmc_rescan: card ocr from io_op=0x90ff8000, err = 0

Nothing looking odd there, although ISTR complaints about
the debounce clock are recent additions.

Which slot reports that mmc_rescan() thing though?  I take
it that's your diagnostic.  More important ... why are you
only getting one such message?  I hope you really *do* have
an uSD card in that slot.  ;)


Try sticking diagnostics where it's checking whether there
is a card in the slot.  And then where it turns on the
regulator for mmc0 ... I'm thinking the latter doesn't seem
to be happening, 


> usbcore: registered new interface driver usbhid
> usbhid: v2.6:USB HID core driver
> Advanced Linux Sound Architecture Driver Version 1.0.18a.
> usbcore: registered new interface driver snd-usb-audio
> No device for DAI twl4030
> No device for DAI omap-mcbsp-dai-0
> No device for DAI omap-mcbsp-dai-1
> No device for DAI omap-mcbsp-dai-2
> No device for DAI omap-mcbsp-dai-3
> No device for DAI omap-mcbsp-dai-4
> overo SoC init
> TWL4030 Audio Codec init
> asoc: twl4030 <-> omap-mcbsp-dai-0 mapping ok
> ALSA device list:
>   #0: overo (twl4030)
> oprofile: using arm/armv7
> TCP cubic registered
> NET: Registered protocol family 17
> NET: Registered protocol family 15
> Bluetooth: L2CAP ver 2.11
> Bluetooth: L2CAP socket layer initialized
> Bluetooth: SCO (Voice Link) ver 0.6
> Bluetooth: SCO socket layer initialized
> Bluetooth: RFCOMM socket layer initialized
> Bluetooth: RFCOMM TTY layer initialized
> Bluetooth: RFCOMM ver 1.10
> Bluetooth: BNEP (Ethernet Emulation) ver 1.3
> Bluetooth: BNEP filters: protocol multicast
> Bluetooth: HIDP (Human Interface Emulation) ver 1.2
> RPC: Registered udp transport module.
> RPC: Registered tcp transport module.
> ThumbEE CPU extension supported.
> Power Management for TI OMAP3.
> SmartReflex driver initialized
> VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 1
> fbcvt: 1024x768@60: CVT Name - .786M3-R
> Console: switching to colour frame buffer device 128x48
> clock: clksel_round_rate_div: dpll4_m4_ck target_rate 86400000
> clock: new_div = 5, new_rate = 86400000

I don't hook up the framebuffer, but here I get an MMC diagnostic
I've added:

mmc0: voltage mask 0f0000 (orig ff8000, use 010000)


> twl4030_rtc twl4030_rtc: setting system clock to 2000-01-01 00:00:00
> UTC (946684800)
> Waiting for root device /dev/mmcblk0p2...
> mmc1: new SDIO card at address 0001
> 
> 

At that point I get:

Waiting for root device /dev/mmcblk0p2...
mmc0: host does not support reading read-only switch. assuming write-enable.
mmc0: new high speed SD card at address 3395
mmcblk0: mmc0:3395 SD02G 1.83 GiB 
 mmcblk0: p1 p2
mmc1: voltage mask 100000 (orig ff8000, use 100000)
usb 2-1: new high speed USB device using musb_hdrc and address 2
mmc1: new SDIO card at address 0001
libertas_sdio mmc1:0001:1: firmware: using built-in firmware sd8686_helper.bin
libertas_sdio mmc1:0001:1: firmware: using built-in firmware sd8686.bin


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Overo broken after recent mainline merge
  2009-03-14 22:34         ` Mark Brown
@ 2009-03-15  3:18           ` David Brownell
  2009-03-15  3:36           ` David Brownell
  1 sibling, 0 replies; 19+ messages in thread
From: David Brownell @ 2009-03-15  3:18 UTC (permalink / raw)
  To: Mark Brown; +Cc: Tony Lindgren, Steve Sakoman, linux-omap

On Saturday 14 March 2009, Mark Brown wrote:
> > A third approach (after applying that one patch that's
> > in the regulator-next tree) would be
> 
> >       if (rdev->is_enabled() > 0)
> >               rdev->use_count = 1;
> 
> That won't work with consumers that can share their supply - they can't
> tell if the regulator was enabled because it was left on at startup or
> if it was enabled by some other consumer.

It works *exactly* like it would if the bootloader were
able to poke the "boot_on" flag for each regulator it
left enabled.

It also helps that the typical scenario I need to care
about is where there's only one consumer ... but in any
case, the change sketched above can't add new problems.

- Dave

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Overo broken after recent mainline merge
  2009-03-14 22:34         ` Mark Brown
  2009-03-15  3:18           ` David Brownell
@ 2009-03-15  3:36           ` David Brownell
  1 sibling, 0 replies; 19+ messages in thread
From: David Brownell @ 2009-03-15  3:36 UTC (permalink / raw)
  To: Mark Brown; +Cc: linux-omap

[ this being afield from over-specific issues, I dropped the
extra copies to Steve and Tony ... ]


On Saturday 14 March 2009, Mark Brown wrote:
> On Sat, Mar 14, 2009 at 02:14:05PM -0700, David Brownell wrote:
> 
> > But thinking about how to handle the video support makes
> > it clear that's not always the best solution.  One needs
> > bootloaders to be able to throw a splash screen which
> > stays active until the window system kicks in ... but
> > turning off video regulators would clearly blacken the
> > screen, which is the wrong model.  (And marking them as
> > "always on" or "boot_on" is wrong for other reasons.)
> 
> Yes, this sounds like one of those cases where just leaving the
> regulator alone and letting the drivers figure things out will probably
> work best.

But the regulator framework needs to change before the drivers
can do that.  Right now, that framework creates self-inconsistent
state (at init time) for that type of regulator.  And it's not
realistic to expect *every* driver to "figure things out".


> > The way clocks handle that is with a late disable,
> > so drivers have a chance to start up.  You rejected
> 
> This behaviour is specific to the OMAP implementation of the clock API
> (and is an optional feature of that from the looks of it).

No; the AT91 clock framework does it too.  Non-conditionally.

Ditto the DaVinci clock framework (the new saner code that looks
to merge in 2.6.30, not the initial incomplete dm644x-only stuff
currently in mainline).  There, it's conditional.

And MSM, and surely others (just looking at ARM code for now).
Some of the S3C platforms do "early" disable, not late.  Most
of the non-TI versions seem to be non-conditional.

Basically any platform that's serious about power management
will be disabling unused clocks as one of the strategies used
to conserve power.

I think the OMAP code does it conditionally since getting it
all right is so much work ... it's an order of magnitude more
complex than most of other platforms, if not more, and getting
all the hardware automagic to behave involves cooperation from
drivers that may not yet be ready to cooperate.


> It's 
> probably also worth rembembering that the clock API is working in a very
> much more controlled domain (in that it mostly only covers well known
> devices on a given architecture), requires little if any per-machine
> setup and isn't an optional feature.  Most of the clock API setup is a
> feature of the SoC CPU rather than of the board.

I see your point, but I don't think there's really all that
much of a difference.  In the end, drivers need to be given
a sane initial configuration ... and the framework needs to
behave consistently.

(But the regulator framework is now self-inconsistent.)


> > the REGULATOR_DISABLE_UNUSED patch I sent, applying
> > that model ... and that's why I started to think about
> > other approaches, as in the "early disable" patch I
> > sent earlier in this thread.
> 
> I didn't reject the concept - I asked for some changes in the interface
> to make it be something that the machine drivers can control rather than
> have it be a Kconfig option that's selected by end users and can't be
> part of the power description that the machine has to have anyway.

Poking Kconfig was more of a quick hack following one
existing model, to show how simple a fix might be, than
claiming that the right fix looked that way.

The problem with needing to put *anything* into a machine
description is that it leaves unfixed that basic hole in
the regulator framework:  self-inconsistent initialization.

If it's guaranteed that regulator_register() returns a
device that's either (a) disabled, with enable count == 0,
else (b) enabled, with enable count == 1 ... the rest can
be dealt with as a configuration issue.


> As I 
> said at the time if it were something that could be enabled by the
> machine driver, either per regulator or per system, then I'd be happy
> with this approach.  I think that it is a better approach than the one
> you're currently going for.

I'll disagree.  Any approach that promotes self-inconsistent
initialization of the regulator framework is a big problem.
Not "better" in any way.  And *requiring* folk to set a flag
just to get the behavior they legitimately expect in the first
place ... not even vaguely better.

- Dave




^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Overo broken after recent mainline merge
  2009-03-15  2:00       ` David Brownell
@ 2009-03-15  3:56         ` Steve Sakoman
  2009-03-15 19:56         ` Steve Sakoman
  1 sibling, 0 replies; 19+ messages in thread
From: Steve Sakoman @ 2009-03-15  3:56 UTC (permalink / raw)
  To: David Brownell, linux-omap

On Sat, Mar 14, 2009 at 7:00 PM, David Brownell <david-b@pacbell.net> wrote:

>> I don't get the warning now, but mmc0 is still broken (boot log below)
>
> Works for me, and I think you've got all the patches that
> should matter.   This is against today's GIT, yes?
> Does taking #3 away help?

Yes, this is against today's top of tree
(a504a838e680d623745d3ad9cee1405ddbc4cbf9).

I've rebuilt without patch 3 -- same result (boot log attached below).
 Is there any chance I might be missing some new kconfig option?  I
didn't notice any patches changing defconfig.

>> OMAP3430 ES2.1
>
> I hear ES3.1 will have better-working EHCI.  ;)

I get the crufty old protos to work with :-)

>> sdhci: Secure Digital Host Controller Interface driver
>> sdhci: Copyright(c) Pierre Ossman
>
> Why do you have SDHCI configured??

Damn good question!  I have no idea when that snuck in there!  It is
removed in the new build.

> Which slot reports that mmc_rescan() thing though?  I take
> it that's your diagnostic.  More important ... why are you
> only getting one such message?  I hope you really *do* have
> an uSD card in that slot.  ;)

Yes, there is a uSD card in the slot :-)  U-boot and uImage are
loading from the card so I know it is there!

That is my diagnostic left over from trying to track down the SDIO
issue.  Why we only see one message is a good question.  I would also
expect to see two.

> Try sticking diagnostics where it's checking whether there
> is a card in the slot.  And then where it turns on the
> regulator for mmc0 ... I'm thinking the latter doesn't seem
> to be happening,

OK, will get another build going with those diagnostics.

>> Waiting for root device /dev/mmcblk0p2...
>> mmc1: new SDIO card at address 0001
>>
> At that point I get:
>
> Waiting for root device /dev/mmcblk0p2...
> mmc0: host does not support reading read-only switch. assuming write-enable.
> mmc0: new high speed SD card at address 3395
> mmcblk0: mmc0:3395 SD02G 1.83 GiB
>  mmcblk0: p1 p2
> mmc1: voltage mask 100000 (orig ff8000, use 100000)
> usb 2-1: new high speed USB device using musb_hdrc and address 2
> mmc1: new SDIO card at address 0001
> libertas_sdio mmc1:0001:1: firmware: using built-in firmware sd8686_helper.bin
> libertas_sdio mmc1:0001:1: firmware: using built-in firmware sd8686.bin

That is what I used to see too.

Thanks for helping me track this down!

Steve


Linux version 2.6.29-rc8-omap1 (sakoman@tera) (gcc version 4.3.1 (GCC)
) #1 Sat Mar 14 20:36:14 PDT 2009
CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=10c5387f
CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
Machine: Gumstix Overo
omapfb_early_vram, 12582912, 0x0
Memory policy: ECC disabled, Data cache writeback
OMAP3430 ES2.1
SRAM: Mapped pa 0x40200000 to va 0xd7000000 size: 0x100000
Reserving 12582912 bytes SDRAM for VRAM
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 65024
Kernel command line: console=ttyS2,115200n8 vram=12M
omapfb.mode=dvi:1024x768MR-16@60 omapfb.debug=y omapdss.def_disp=dvi
root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait
Clocking rate (Crystal/DPLL/ARM core): 26.0/331/500 MHz
GPMC revision 5.0
IRQ: Found an INTC at 0xd8200000 (revision 4.0) with 96 interrupts
Total of 96 interrupts on 1 active controller
OMAP34xx GPIO hardware version 2.5
PID hash table entries: 1024 (order: 10, 4096 bytes)
OMAP clockevent source: GPTIMER1 at 32768 Hz
Console: colour dummy device 80x30
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 128MB 128MB = 256MB total
Memory: 241408KB available (4460K code, 531K data, 936K init)
Calibrating delay loop... 499.92 BogoMIPS (lpj=1949696)
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
net_namespace: 764 bytes
regulator: core version 0.5
NET: Registered protocol family 16
Found NAND on CS0
Registering NAND on CS0
OMAP DMA hardware revision 4.0
bio: create slab <bio-0> at 0
OMAP DSS rev 2.0
OMAP DISPC rev 3.0
OMAP VENC rev 2
i2c_omap i2c_omap.1: bus 1 rev3.12 at 2600 kHz
twl4030: PIH (irq 7) chaining IRQs 368..375
twl4030: power (irq 373) chaining IRQs 376..383
twl4030: gpio (irq 368) chaining IRQs 384..401
set_machine_constraints: disable 'VMMC1' --> 0
regulator: VMMC1: 1850 <--> 3150 mV normal standby
set_machine_constraints: disable 'VUSB1V5' --> 0
regulator: VUSB1V5: 1500 <--> 0 mV normal standby
set_machine_constraints: disable 'VUSB1V8' --> 0
regulator: VUSB1V8: 1800 <--> 0 mV normal standby
set_machine_constraints: disable 'VUSB3V1' --> 0
regulator: VUSB3V1: 3100 <--> 0 mV normal standby
i2c_omap i2c_omap.3: bus 3 rev3.12 at 400 kHz
SCSI subsystem initialized
twl4030_usb twl4030_usb: Initialized TWL4030 USB module
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
Bluetooth: Core ver 2.14
NET: Registered protocol family 31
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
cfg80211: Using static regulatory domain info
cfg80211: Regulatory domain: US
	(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
	(2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2700 mBm)
	(5170000 KHz - 5190000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
	(5190000 KHz - 5210000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
	(5210000 KHz - 5230000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
	(5230000 KHz - 5330000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
	(5735000 KHz - 5835000 KHz @ 40000 KHz), (600 mBi, 3000 mBm)
cfg80211: Calling CRDA for country: US
musb_hdrc: version 6.0, musb-dma, host, debug=0
musb_hdrc: USB Host mode controller at d80ab000 using DMA, IRQ 92
musb_hdrc musb_hdrc: MUSB HDRC host driver
musb_hdrc musb_hdrc: new USB bus registered, assigned bus number 1
usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: MUSB HDRC host driver
usb usb1: Manufacturer: Linux 2.6.29-rc8-omap1 musb-hcd
usb usb1: SerialNumber: musb_hdrc
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP reno registered
NET: Registered protocol family 1
VFS: Disk quotas dquot_6.5.2
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
JFFS2 version 2.2. (NAND) (SUMMARY)  © 2001-2006 Red Hat, Inc.
msgmni has been set to 471
alg: No test for stdrng (krng)
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
serial8250.0: ttyS0 at MMIO 0x4806a000 (irq = 72) is a ST16654
serial8250.0: ttyS1 at MMIO 0x4806c000 (irq = 73) is a ST16654
serial8250.0: ttyS2 at MMIO 0x49020000 (irq = 74) is a ST16654
console [ttyS2] enabled
brd: module loaded
loop: module loaded
usbcore: registered new interface driver asix
usbcore: registered new interface driver cdc_ether
i2c /dev entries driver
Driver 'sd' needs updating - please use bus_type methods
omap2-nand driver initializing
NAND device: Manufacturer ID: 0x2c, Chip ID: 0xba (Micron NAND 256MiB
1,8V 16-bit)
cmdlinepart partition parsing not available
Creating 5 MTD partitions on "omap2-nand":
0x000000000000-0x000000080000 : "xloader"
0x000000080000-0x000000240000 : "uboot"
0x000000240000-0x000000280000 : "uboot environment"
0x000000280000-0x000000680000 : "linux"
0x000000680000-0x000010000000 : "rootfs"
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci-omap ehci-omap.0: OMAP-EHCI Host Controller
ehci-omap ehci-omap.0: new USB bus registered, assigned bus number 2
ehci-omap ehci-omap.0: irq 77, io mem 0x48064800
ehci-omap ehci-omap.0: USB 2.0 started, EHCI 1.00
usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb2: Product: OMAP-EHCI Host Controller
usb usb2: Manufacturer: Linux 2.6.29-rc8-omap1 ehci_hcd
usb usb2: SerialNumber: ehci-omap.0
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 3 ports detected
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
udc: OMAP UDC driver, version: 4 October 2004 (iso) (dma)
mice: PS/2 mouse device common for all mice
twl4030_rtc twl4030_rtc: rtc core: registered twl4030_rtc as rtc0
OMAP Watchdog Timer Rev 0x31: initial timeout 60 sec
Bluetooth: HCI UART driver ver 2.2
Bluetooth: HCI H4 protocol initialized
Bluetooth: HCI BCSP protocol initialized
Bluetooth: Broadcom Blutonium firmware driver ver 1.2
usbcore: registered new interface driver bcm203x
Bluetooth: Digianswer Bluetooth USB driver ver 0.10
usbcore: registered new interface driver bpa10x
mmci-omap-hs mmci-omap-hs.0: Failed to get debounce clock
regulator: Unable to get requested regulator: vmmc_aux
mmci-omap-hs mmci-omap-hs.1: Failed to get debounce clock
regulator: Unable to get requested regulator: vmmc
mmc_rescan: card ocr from io_op=0x90ff8000, err = 0
usbcore: registered new interface driver usbhid
usbhid: v2.6:USB HID core driver
Advanced Linux Sound Architecture Driver Version 1.0.18a.
usbcore: registered new interface driver snd-usb-audio
No device for DAI twl4030
No device for DAI omap-mcbsp-dai-0
No device for DAI omap-mcbsp-dai-1
No device for DAI omap-mcbsp-dai-2
No device for DAI omap-mcbsp-dai-3
No device for DAI omap-mcbsp-dai-4
overo SoC init
TWL4030 Audio Codec init
asoc: twl4030 <-> omap-mcbsp-dai-0 mapping ok
ALSA device list:
  #0: overo (twl4030)
oprofile: using arm/armv7
TCP cubic registered
NET: Registered protocol family 17
NET: Registered protocol family 15
Bluetooth: L2CAP ver 2.11
Bluetooth: L2CAP socket layer initialized
Bluetooth: SCO (Voice Link) ver 0.6
Bluetooth: SCO socket layer initialized
Bluetooth: RFCOMM socket layer initialized
Bluetooth: RFCOMM TTY layer initialized
Bluetooth: RFCOMM ver 1.10
Bluetooth: BNEP (Ethernet Emulation) ver 1.3
Bluetooth: BNEP filters: protocol multicast
Bluetooth: HIDP (Human Interface Emulation) ver 1.2
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
ThumbEE CPU extension supported.
Power Management for TI OMAP3.
SmartReflex driver initialized
VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 1
fbcvt: 1024x768@60: CVT Name - .786M3-R
Console: switching to colour frame buffer device 128x48
clock: clksel_round_rate_div: dpll4_m4_ck target_rate 86400000
clock: new_div = 5, new_rate = 86400000
twl4030_rtc twl4030_rtc: setting system clock to 2000-01-01 00:12:36
UTC (946685556)
Waiting for root device /dev/mmcblk0p2...
mmc1: new SDIO card at address 0001
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Overo broken after recent mainline merge
  2009-03-15  2:00       ` David Brownell
  2009-03-15  3:56         ` Steve Sakoman
@ 2009-03-15 19:56         ` Steve Sakoman
  2009-03-15 22:15           ` Steve Sakoman
  2009-03-15 23:16           ` David Brownell
  1 sibling, 2 replies; 19+ messages in thread
From: Steve Sakoman @ 2009-03-15 19:56 UTC (permalink / raw)
  To: David Brownell, linux-omap, Tony Lindgren

On Sat, Mar 14, 2009 at 7:00 PM, David Brownell <david-b@pacbell.net> wrote:

> Works for me, and I think you've got all the patches that
> should matter.   This is against today's GIT, yes?
> Does taking #3 away help?

I'm not sure why it is working for you!  Perhaps you have some patches
that aren't included in the current tree?

I believe the root issue is in your recent Overo patch
(http://marc.info/?l=linux-omap&m=123679791627030&w=2)

In particular, these lines:

+	/* gpio + 0 is "mmc0_cd" (input/IRQ) */
+	mmc[0].gpio_cd = gpio + 0;

Overo, having a microSD slot, doesn't have a card detect switch. The
other part of your patch sets gpio_cd properly:

+static struct twl4030_hsmmc_info mmc[] = {
+	{
+		.mmc		= 1,
+		.wires		= 4,
+		.gpio_cd	= -EINVAL,
+		.gpio_wp	= -EINVAL,
+	},
+	{
+		.mmc		= 2,
+		.wires		= 4,
+		.gpio_cd	= -EINVAL,
+		.gpio_wp	= -EINVAL,
+		.transceiver	= true,
+		.ocr_mask	= 0x00100000,	/* 3.3V */
+	},
+	{}	/* Terminator */
+};

So all I had to do was remove the above 2 lines to get a successful boot.

Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Overo broken after recent mainline merge
  2009-03-15 19:56         ` Steve Sakoman
@ 2009-03-15 22:15           ` Steve Sakoman
  2009-03-15 22:32             ` Steve Sakoman
  2009-03-15 23:16           ` David Brownell
  1 sibling, 1 reply; 19+ messages in thread
From: Steve Sakoman @ 2009-03-15 22:15 UTC (permalink / raw)
  To: David Brownell, linux-omap, Tony Lindgren

On Sun, Mar 15, 2009 at 12:56 PM, Steve Sakoman <sakoman@gmail.com> wrote:
> On Sat, Mar 14, 2009 at 7:00 PM, David Brownell <david-b@pacbell.net> wrote:
>
>> Works for me, and I think you've got all the patches that
>> should matter.   This is against today's GIT, yes?
>> Does taking #3 away help?
>
> I'm not sure why it is working for you!  Perhaps you have some patches
> that aren't included in the current tree?
>
> I believe the root issue is in your recent Overo patch
> (http://marc.info/?l=linux-omap&m=123679791627030&w=2)
>
> In particular, these lines:
>
> +       /* gpio + 0 is "mmc0_cd" (input/IRQ) */
> +       mmc[0].gpio_cd = gpio + 0;
>
> Overo, having a microSD slot, doesn't have a card detect switch. The
> other part of your patch sets gpio_cd properly:
>
> +static struct twl4030_hsmmc_info mmc[] = {
> +       {
> +               .mmc            = 1,
> +               .wires          = 4,
> +               .gpio_cd        = -EINVAL,
> +               .gpio_wp        = -EINVAL,
> +       },
> +       {
> +               .mmc            = 2,
> +               .wires          = 4,
> +               .gpio_cd        = -EINVAL,
> +               .gpio_wp        = -EINVAL,
> +               .transceiver    = true,
> +               .ocr_mask       = 0x00100000,   /* 3.3V */
> +       },
> +       {}      /* Terminator */
> +};
>
> So all I had to do was remove the above 2 lines to get a successful boot.

I spoke a little too soon :-)

The above fix does get me past the mmc issue, and everything looks
fine from the serial console.  But I just noticed that DVI is broken
-- I suspect that some regulator magic may be required in the video
driver too :-(

Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Overo broken after recent mainline merge
  2009-03-15 22:15           ` Steve Sakoman
@ 2009-03-15 22:32             ` Steve Sakoman
  0 siblings, 0 replies; 19+ messages in thread
From: Steve Sakoman @ 2009-03-15 22:32 UTC (permalink / raw)
  To: David Brownell, linux-omap, Tony Lindgren

On Sun, Mar 15, 2009 at 3:15 PM, Steve Sakoman <sakoman@gmail.com> wrote:

> I spoke a little too soon :-)
>
> The above fix does get me past the mmc issue, and everything looks
> fine from the serial console.  But I just noticed that DVI is broken
> -- I suspect that some regulator magic may be required in the video
> driver too :-(

Heh, remember that comment about the crufty old protos I work with?

False alarm.  I was using one that had a "broken dvi" tag on it :-)

Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Overo broken after recent mainline merge
  2009-03-15 19:56         ` Steve Sakoman
  2009-03-15 22:15           ` Steve Sakoman
@ 2009-03-15 23:16           ` David Brownell
  1 sibling, 0 replies; 19+ messages in thread
From: David Brownell @ 2009-03-15 23:16 UTC (permalink / raw)
  To: Steve Sakoman; +Cc: linux-omap, Tony Lindgren

On Sunday 15 March 2009, Steve Sakoman wrote:
> +       /* gpio + 0 is "mmc0_cd" (input/IRQ) */
> +       mmc[0].gpio_cd = gpio + 0;
> 
> Overo, having a microSD slot, doesn't have a card detect switch. The
> other part of your patch sets gpio_cd properly:

Hmm, the board I have seems to work fine with those lines.

microSD slots can support card detect just fine ... but
I think you're probably right that those lines should
be removed.

I recall testing microSD card detect with that board:
eject after loading kernel, bootm, and verify the kernel
waits politely for re-insert.

But I tried that just now, and it doesn't work.  Odd.

Can you resend an updated patch with your s-o-b?

- Dave
 
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 19+ messages in thread

* [APPLIED] Overo broken after recent mainline merge
  2009-03-14 19:08   ` David Brownell
  2009-03-14 20:22     ` Mark Brown
  2009-03-14 23:47     ` Steve Sakoman
@ 2009-03-20 19:18     ` Tony Lindgren
  2009-03-20 22:33       ` David Brownell
  2 siblings, 1 reply; 19+ messages in thread
From: Tony Lindgren @ 2009-03-20 19:18 UTC (permalink / raw)
  To: linux-omap

This patch has been applied to the linux-omap
by youw fwiendly patch wobot.

Commit: f4223ec219313d631c3f620220ed23670c158a34

PatchWorks
http://patchwork.kernel.org/patch/12140/

Git
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=f4223ec219313d631c3f620220ed23670c158a34



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [APPLIED] Overo broken after recent mainline merge
  2009-03-20 19:18     ` [APPLIED] " Tony Lindgren
@ 2009-03-20 22:33       ` David Brownell
  2009-03-23 16:00         ` Mark Brown
  2009-03-23 19:27         ` [APPLIED] " Tony Lindgren
  0 siblings, 2 replies; 19+ messages in thread
From: David Brownell @ 2009-03-20 22:33 UTC (permalink / raw)
  To: Tony Lindgren; +Cc: linux-omap

On Friday 20 March 2009, Tony Lindgren wrote:
> This patch has been applied to the linux-omap
> by youw fwiendly patch wobot.
> 
> Commit: f4223ec219313d631c3f620220ed23670c158a34
> 
> PatchWorks
> http://patchwork.kernel.org/patch/12140/
> 

To avoid needless divergence from mainline, the appended
patch would probably work better ... it doesn't actually
fix the bug in the regulator core, but it's a workaround
that could go to mainline until that core gets fixed.

(Oh, and it includes a real, albeit minor, bugfix.)

- Dave

=============
From: David Brownell <dbrownell@users.sourceforge.net>

Updates to the mmc-twl4030 code:

 - Partial workaround for the bug fixed more comprehensively
   by f4223ec219313d631c3f620220ed23670c158a34 ... workaround
   applies only to MMC devs using this code.

 - Fix a cut'n'paste bug as noted by Adrian Hunter:  the intent
   was to "disable" not (re)"enable".

The reason to want this workaround is lack of faith that any
sane fix for that regulator framework bug will ever merge,
while still wanting to see things work in mainline.

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
---
I suggest reverting f4223ec219313d631c3f620220ed23670c158a34
after applying this ...

 arch/arm/mach-omap2/mmc-twl4030.c |   23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

--- a/arch/arm/mach-omap2/mmc-twl4030.c
+++ b/arch/arm/mach-omap2/mmc-twl4030.c
@@ -128,6 +128,27 @@ static int twl_mmc_late_init(struct devi
 			reg = regulator_get(dev, "vmmc_aux");
 			hsmmc[i].vcc_aux = IS_ERR(reg) ? NULL : reg;
 
+			/* UGLY HACK:  workaround regulator framework bugs.
+			 * When the bootloader leaves a supply active, it's
+			 * initialized with zero usecount ... and we can't
+			 * disable it without first disabling it.  Until the
+			 * framework is fixed, we need a workaround like this
+			 * (which is safe for MMC, but not in general).
+			 */
+			if (regulator_is_enabled(hsmmc[i].vcc) > 0) {
+				dev_warn(dev, "APPLY REGULATOR HACK for vmmc\n");
+				regulator_enable(hsmmc[i].vcc);
+				regulator_disable(hsmmc[i].vcc);
+			}
+			if (hsmmc[i].vcc_aux) {
+				if (regulator_is_enabled(reg) > 0) {
+					dev_warn(dev, "APPLY REGULATOR HACK "
+						"for vmmc_aux\n");
+					regulator_enable(reg);
+					regulator_disable(reg);
+				}
+			}
+
 			break;
 		}
 	}
@@ -285,7 +306,7 @@ static int twl_mmc23_set_power(struct de
 		}
 	} else {
 		if (c->vcc_aux)
-			ret = regulator_enable(c->vcc_aux);
+			ret = regulator_disable(c->vcc_aux);
 		if (ret == 0)
 			ret = mmc_regulator_set_ocr(c->vcc, 0);
 	}


^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [APPLIED] Overo broken after recent mainline merge
  2009-03-20 22:33       ` David Brownell
@ 2009-03-23 16:00         ` Mark Brown
  2009-03-23 19:27         ` [APPLIED] " Tony Lindgren
  1 sibling, 0 replies; 19+ messages in thread
From: Mark Brown @ 2009-03-23 16:00 UTC (permalink / raw)
  To: David Brownell; +Cc: Tony Lindgren, linux-omap

On Fri, Mar 20, 2009 at 03:33:24PM -0700, David Brownell wrote:

> +				dev_warn(dev, "APPLY REGULATOR HACK for vmmc\n");

...

> +					dev_warn(dev, "APPLY REGULATOR HACK "
> +						"for vmmc_aux\n");

Please remove these hunks, it's not useful to the users to log this.  No
action is required on their part and this is expected behaviour.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* [APPLIED] [APPLIED] Overo broken after recent mainline merge
  2009-03-20 22:33       ` David Brownell
  2009-03-23 16:00         ` Mark Brown
@ 2009-03-23 19:27         ` Tony Lindgren
  1 sibling, 0 replies; 19+ messages in thread
From: Tony Lindgren @ 2009-03-23 19:27 UTC (permalink / raw)
  To: linux-omap

This patch has been applied to the linux-omap
by youw fwiendly patch wobot.

Commit: 3404491eb5a3232dc33b131da470840f4cc76a32

PatchWorks
http://patchwork.kernel.org/patch/13403/

Git
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=3404491eb5a3232dc33b131da470840f4cc76a32



^ permalink raw reply	[flat|nested] 19+ messages in thread

end of thread, other threads:[~2009-03-23 19:27 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-03-14 13:24 Overo broken after recent mainline merge Steve Sakoman
2009-03-14 16:12 ` Tony Lindgren
2009-03-14 19:08   ` David Brownell
2009-03-14 20:22     ` Mark Brown
2009-03-14 21:14       ` David Brownell
2009-03-14 22:34         ` Mark Brown
2009-03-15  3:18           ` David Brownell
2009-03-15  3:36           ` David Brownell
2009-03-14 23:47     ` Steve Sakoman
2009-03-15  2:00       ` David Brownell
2009-03-15  3:56         ` Steve Sakoman
2009-03-15 19:56         ` Steve Sakoman
2009-03-15 22:15           ` Steve Sakoman
2009-03-15 22:32             ` Steve Sakoman
2009-03-15 23:16           ` David Brownell
2009-03-20 19:18     ` [APPLIED] " Tony Lindgren
2009-03-20 22:33       ` David Brownell
2009-03-23 16:00         ` Mark Brown
2009-03-23 19:27         ` [APPLIED] " Tony Lindgren

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).