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