linux-arm-kernel.lists.infradead.org archive mirror
 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 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).