Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1249045 > unrolled thread
| Started by | Sylvain Rochet <sylvain.rochet@finsecur.com> |
|---|---|
| First post | 2015-10-16 20:20 +0200 |
| Last post | 2015-10-17 00:00 +0200 |
| Articles | 3 — 3 participants |
Back to article view | Back to linux.kernel
Atmel SoCs and the newly added CONFIG_DELAY_DEVICE_PROBES option Sylvain Rochet <sylvain.rochet@finsecur.com> - 2015-10-16 20:20 +0200
Re: Atmel SoCs and the newly added CONFIG_DELAY_DEVICE_PROBES option Tomeu Vizoso <tomeu.vizoso@collabora.com> - 2015-10-16 21:30 +0200
Re: Atmel SoCs and the newly added CONFIG_DELAY_DEVICE_PROBES option Alexandre Belloni <alexandre.belloni@free-electrons.com> - 2015-10-17 00:00 +0200
| From | Sylvain Rochet <sylvain.rochet@finsecur.com> |
|---|---|
| Date | 2015-10-16 20:20 +0200 |
| Subject | Atmel SoCs and the newly added CONFIG_DELAY_DEVICE_PROBES option |
| Message-ID | <qkhLI-5ON-11@gated-at.bofh.it> |
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 ? Sylvain -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [next] | [standalone]
| From | Tomeu Vizoso <tomeu.vizoso@collabora.com> |
|---|---|
| Date | 2015-10-16 21:30 +0200 |
| Message-ID | <qkiRt-7pv-29@gated-at.bofh.it> |
| In reply to | #1249045 |
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. 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. Regards, Tomeu > Sylvain > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Alexandre Belloni <alexandre.belloni@free-electrons.com> |
|---|---|
| Date | 2015-10-17 00:00 +0200 |
| Message-ID | <qklcC-2gb-3@gated-at.bofh.it> |
| In reply to | #1249095 |
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web