From: valentin.longchamp@epfl.ch (Valentin Longchamp)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/2] mx31moboard for 2.6.33-rc1
Date: Mon, 21 Dec 2009 17:52:52 +0100 [thread overview]
Message-ID: <4B2FA7E4.5070700@epfl.ch> (raw)
In-Reply-To: <1261407604.2144.16.camel@climbing-alby>
Alberto Panizzo wrote:
> Il giorno lun, 21/12/2009 alle 12.17 +0100, Sascha Hauer ha scritto:
>> On Fri, Dec 18, 2009 at 06:11:31PM +0100, Valentin Longchamp wrote:
>>> I have tested mx31moboard with the first -rc. Here are two patches correcting the current problems. They should go to a next -rc.
>>>
>>> 1) The patches for usbh support were based on the bad branch, where
>>> the platform_devices had been renamed. Now this prevents the mx3
>>> config to build. The first patch reverts to the correct names.
>>>
>>> 2) The MC13783 voltage regulators with boot_on or always_on enabled
>>> hang the kernel at boot. Remove these options from mx31moboard
>>> configuration. Sascha, is this a correct behavior or is it a bug ?
>> AFAIK the boot_on indicate the regulator framework that this regulator
>> is already enabled when the kernel starts. I don't see why this makes
>> the kernel hang. Can you do a bit more debugging please?
>>
>> Sascha
>>
>
> The patch that I proposed:
> [PATCH 2/4] mfd: mc13783: When probing, unlock the mc13783 before subsystems initialisation.
> solve the problem I think.
>
> If you enable the debug output on drivers/mfd/mc13783-core and you see that the
> kernel hang on the mc13783 waiting queue, than my patch is for you.
>
> With boot_on = 1 the regulator core ensure also that the regulator is
> enabled during probe, so it call the corresponding enable function.
> That function utilise the mc13783-API that are still locked.
>
> mc13783-regulator now is probed when mc13783-core register it's regulator
> subsystem.
>
> For now that patch (acked by Uwe Kleine-K?nig) is not applied to the mfd tree.
>
I confirm what Alberto tells, this patch solves the kernel hang at boot
for both the boot_on and and always_on flags, avoiding the deadlock
explained above.
My patch is then be pointless when Alberto's patch gets merged.
Val
--
Valentin Longchamp, PhD Student, EPFL-STI-LSRO1
valentin.longchamp at epfl.ch, Phone: +41216937827
http://people.epfl.ch/valentin.longchamp
MEA3485, Station 9, CH-1015 Lausanne
prev parent reply other threads:[~2009-12-21 16:52 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-18 17:11 [PATCH 0/2] mx31moboard for 2.6.33-rc1 Valentin Longchamp
2009-12-18 17:11 ` [PATCH 1/2] mx31moboard: fix usbh device names Valentin Longchamp
2009-12-18 17:11 ` [PATCH 2/2] mx31moboard: boot_on/always_on voltage regulators hang kernel at boot Valentin Longchamp
2009-12-19 13:50 ` [PATCH 0/2] mx31moboard for 2.6.33-rc1 Alberto Panizzo
2009-12-21 11:17 ` Sascha Hauer
2009-12-21 15:00 ` Alberto Panizzo
2009-12-21 16:52 ` Valentin Longchamp [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B2FA7E4.5070700@epfl.ch \
--to=valentin.longchamp@epfl.ch \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).