All of lore.kernel.org
 help / color / mirror / Atom feed
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

      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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.