From: alexandre.belloni@free-electrons.com (Alexandre Belloni)
To: linux-arm-kernel@lists.infradead.org
Subject: Atmel SoCs and the newly added CONFIG_DELAY_DEVICE_PROBES option
Date: Fri, 16 Oct 2015 23:54:39 +0200 [thread overview]
Message-ID: <20151016215439.GR3421@piout.net> (raw)
In-Reply-To: <CAAObsKBn5DaXT3J9CG6j_f0RxJpo+WQcj-8w5xz_N64OWEYesw@mail.gmail.com>
On 16/10/2015 at 21:29:25 +0200, Tomeu Vizoso wrote :
> On 16 October 2015 at 20:11, Sylvain Rochet <sylvain.rochet@finsecur.com> wrote:
> > Hi,
> >
> > FYI, to save you a git bisect, the recently added
> > CONFIG_DELAY_DEVICE_PROBES (enabled by default) breaks Atmel SoCs.
> >
> > For a few of quickly noticeable issues:
> > - PM is not working: at91_pm_sram_init: sram pool unavailable!
> > - Watchdog is not even probed
> > - on -ek boards the wm8904 is not probed either.
> >
> > Disabling CONFIG_DELAY_DEVICE_PROBES fixes all issues.
> >
> > Tomeu, what should I provide to help find out what's happening ?
>
> Hi Sylvain, I believe I can do some testing via kernelci on those
> boards, latest on monday.
>
This also probably broke PM on i.mx5 and i.mx6 (and I think socfpga)
boards as they use the sram driver the same way. That is why sram_init
is a postcore_initcall.
> It will probably involve moving some initcalls, and probing more kinds
> of devices on-demand. Sometimes the proper solution is to move code
> from initcalls into proper drivers which can defer their probe if some
> dependency isn't there at that point, but that's likely to be more
> invasive than wanted at this point.
>
I guess that the PM code will be really difficult to move into drivers
but I'd be happy to see that done on AT91 as this is the only thing left
in mach-at91.
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
prev parent reply other threads:[~2015-10-16 21:54 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-16 18:11 Atmel SoCs and the newly added CONFIG_DELAY_DEVICE_PROBES option Sylvain Rochet
2015-10-16 19:29 ` Tomeu Vizoso
2015-10-16 21:54 ` Alexandre Belloni [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=20151016215439.GR3421@piout.net \
--to=alexandre.belloni@free-electrons.com \
--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).