arm-soc + rmk's tree boot failure on OMAP4430SDP

arm-soc + rmk's tree boot failure on OMAP4430SDP

[Russell King - ARM Linux]

Sometime during the last week, the OMAP4430SDP stopped booting - it now
stops with no kernel messages output:

http://www.arm.linux.org.uk/developer/build/result.php?type=boot&idx=69

The previously booted version:

http://www.arm.linux.org.uk/developer/build/result.php?type=boot&idx=57

worked fine - though this log will only be available for about 3 hours.

I've re-checked my tree, and the OMAP4430SDP boots fine, so it's either
breakage coming from arm-soc or a result of merging the two trees
together.

Re: arm-soc + rmk's tree boot failure on OMAP4430SDP

[Tony Lindgren]

Hi,

Adding Tomi to this thread.

* Russell King - ARM Linux <linux@arm.linux.org.uk> [120316 16:14]:
> Sometime during the last week, the OMAP4430SDP stopped booting - it now
> stops with no kernel messages output:
> 
> http://www.arm.linux.org.uk/developer/build/result.php?type=boot&idx=69
> 
> The previously booted version:
> 
> http://www.arm.linux.org.uk/developer/build/result.php?type=boot&idx=57
> 
> worked fine - though this log will only be available for about 3 hours.
> 
> I've re-checked my tree, and the OMAP4430SDP boots fine, so it's either
> breakage coming from arm-soc or a result of merging the two trees
> together.

Based on initcall_debug with current linux-next, it seems to hang at
omap_dss_init2. And leaving out CONFIG_OMAP2_DSS makes devices boot
again.

Tomi, can you please investigate?

To reproduce this problem, just set CONFIG_OMAP2_DSS=y in
omap2plus_defconfig, and try to boot. It hangs at least on
blaze and zoom3.

Regards,

Tony

Re: arm-soc + rmk's tree boot failure on OMAP4430SDP

[Russell King - ARM Linux]

On Fri, Mar 16, 2012 at 05:47:06PM -0700, Tony Lindgren wrote:
> Hi,
> 
> Adding Tomi to this thread.
> 
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [120316 16:14]:
> > Sometime during the last week, the OMAP4430SDP stopped booting - it now
> > stops with no kernel messages output:
> > 
> > http://www.arm.linux.org.uk/developer/build/result.php?type=boot&idx=69
> > 
> > The previously booted version:
> > 
> > http://www.arm.linux.org.uk/developer/build/result.php?type=boot&idx=57
> > 
> > worked fine - though this log will only be available for about 3 hours.
> > 
> > I've re-checked my tree, and the OMAP4430SDP boots fine, so it's either
> > breakage coming from arm-soc or a result of merging the two trees
> > together.
> 
> Based on initcall_debug with current linux-next, it seems to hang at
> omap_dss_init2. And leaving out CONFIG_OMAP2_DSS makes devices boot
> again.

Well, if I put my printk hack in, then I get:

Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
<6>msgmni has been set to 995
<6>io scheduler noop registered
<6>io scheduler deadline registered
<6>io scheduler cfq registered (default)
<3>INFO: task swapper/0:1 blocked for more than 120 seconds.
<3>"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
<6>swapper/0       D<c> c03237b0 <c>    0     1      0 0x00000000
Backtrace: 
[<c03233b4>] (__schedule+0x0/0x4d0) from [<c03239c4>] (schedule+0x74/0x78)
[<c0323950>] (schedule+0x0/0x78) from [<c0322404>] (__mutex_lock_slowpath+0x140/
0x19c)
[<c03222c4>] (__mutex_lock_slowpath+0x0/0x19c) from [<c032248c>] (mutex_lock+0x2
c/0x40)
[<c0322460>] (mutex_lock+0x0/0x40) from [<c01f8f68>] (__driver_attach+0x48/0x90)
 r4:df4f2808
[<c01f8f20>] (__driver_attach+0x0/0x90) from [<c01f77b0>] (bus_for_each_dev+0x58
/0x98)
 r6:c0475634 r5:c01f8f20 r4:00000000
[<c01f7758>] (bus_for_each_dev+0x0/0x98) from [<c01f8c58>] (driver_attach+0x20/0
x28)
 r7:df472780 r6:c0475634 r5:c0475634 r4:c045ea28
[<c01f8c38>] (driver_attach+0x0/0x28) from [<c01f8034>] (bus_add_driver+0xb4/0x2
30)
[<c01f7f80>] (bus_add_driver+0x0/0x230) from [<c01f9614>] (driver_register+0xac/
0x138)
[<c01f9568>] (driver_register+0x0/0x138) from [<c01fa678>] (platform_driver_regi
ster+0x4c/0x60)
 r8:c046c0d8 r7:c04755a4 r6:c04755a4 r5:c045ea30 r4:c045ea28
[<c01fa62c>] (platform_driver_register+0x0/0x60) from [<c01a7ae4>] (dss_init_pla
tform_driver+0x14/0x1c)
[<c01a7ad0>] (dss_init_platform_driver+0x0/0x1c) from [<c01a742c>] (omap_dss_pro
be+0x3c/0x200)
[<c01a73f0>] (omap_dss_probe+0x0/0x200) from [<c01fa2e8>] (platform_drv_probe+0x
20/0x24)
[<c01fa2c8>] (platform_drv_probe+0x0/0x24) from [<c01f8e3c>] (driver_probe_devic
e+0xd0/0x1b4)
[<c01f8d6c>] (driver_probe_device+0x0/0x1b4) from [<c01f8f8c>] (__driver_attach+
0x6c/0x90)
 r7:df443ef0 r6:c04755a4 r5:c045ea64 r4:c045ea30
[<c01f8f20>] (__driver_attach+0x0/0x90) from [<c01f77b0>] (bus_for_each_dev+0x58
/0x98)
 r6:c04755a4 r5:c01f8f20 r4:00000000
[<c01f7758>] (bus_for_each_dev+0x0/0x98) from [<c01f8c58>] (driver_attach+0x20/0
x28)
 r7:df472800 r6:c04755a4 r5:c04755a4 r4:c043e388
[<c01f8c38>] (driver_attach+0x0/0x28) from [<c01f8034>] (bus_add_driver+0xb4/0x2
30)
[<c01f7f80>] (bus_add_driver+0x0/0x230) from [<c01f9614>] (driver_register+0xac/
0x138)
[<c01f9568>] (driver_register+0x0/0x138) from [<c01fa678>] (platform_driver_regi
ster+0x4c/0x60)
 r8:00000000 r7:00000013 r6:c00373ec r5:c043e464 r4:c043e388
[<c01fa62c>] (platform_driver_register+0x0/0x60) from [<c042a0fc>] (omap_dss_ini
t2+0x14/0x1c)
[<c042a0e8>] (omap_dss_init2+0x0/0x1c) from [<c0008770>] (do_one_initcall+0x9c/0
x164)
[<c00086d4>] (do_one_initcall+0x0/0x164) from [<c04122f4>] (kernel_init+0x90/0x1
38)
[<c0412264>] (kernel_init+0x0/0x138) from [<c00373ec>] (do_exit+0x0/0x6c4)
 r5:c0412264 r4:00000000

And the reason is that a platform _driver_ (omapdss_dss) is being
registered while a platform device (omapdss) is being probed.

This is a very bad idea.  There is absolutely no reason to register
drivers from within a probe function - to put it another way, this
code is absolutely insane.

Why?  Because you're destroying the whole idea that drivers only ever
get registered once.  If you happen to have two omapdss devices (okay
that probably won't happen yet) then you'll register those device
structures twice which will cause all hell to break lose.

Moreover - and this is why it's failing - when devices are probed, their
mutex is held.  But not just _their_ mutex, but also their direct parent's
mutex as well.

So, when the omapdss_dss driver is registered while the omapdss device is
being probed, and there's already an omapdss_dss platform device present,
the driver model tries to bind the omapdss_dss platform device with the
newly registered omapdss_dss platform driver.

That binding wants to take the mutex on the omapdss device, but wait,
that's already held by the thread registering the omapdss_dss platform
driver.  Hence, deadlock.

This mess has been created by all those
	"DSS2: xxx: create platform_driver, move init, exit to driver"

commits, and they're all _wrong_ for the above reason.

However, I doubt simply moving the driver registration calls out of the
probe function will be enough - "OMAP: DSS2: Fix init and unit sequence"
hints that there's a dependence in the driver initialization order.
That's another finger pointing at the approach being wrong, because
there is _no_ guarantee as to the order in which drivers or devices are
probed by the driver model.

Re: arm-soc + rmk's tree boot failure on OMAP4430SDP

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 3259 bytes --]

On Sat, 2012-03-17 at 21:15 +0000, Russell King - ARM Linux wrote:

> And the reason is that a platform _driver_ (omapdss_dss) is being
> registered while a platform device (omapdss) is being probed.
> 
> This is a very bad idea.  There is absolutely no reason to register
> drivers from within a probe function - to put it another way, this
> code is absolutely insane.
> 
> Why?  Because you're destroying the whole idea that drivers only ever
> get registered once.  If you happen to have two omapdss devices (okay
> that probably won't happen yet) then you'll register those device
> structures twice which will cause all hell to break lose.
> 
> Moreover - and this is why it's failing - when devices are probed, their
> mutex is held.  But not just _their_ mutex, but also their direct parent's
> mutex as well.
> 
> So, when the omapdss_dss driver is registered while the omapdss device is
> being probed, and there's already an omapdss_dss platform device present,
> the driver model tries to bind the omapdss_dss platform device with the
> newly registered omapdss_dss platform driver.
> 
> That binding wants to take the mutex on the omapdss device, but wait,
> that's already held by the thread registering the omapdss_dss platform
> driver.  Hence, deadlock.
> 
> This mess has been created by all those
> 	"DSS2: xxx: create platform_driver, move init, exit to driver"
> 
> commits, and they're all _wrong_ for the above reason.

Yep, it's totally broken. It's been working by luck, and nobody has paid
attention to it. I noticed this while I was working with device tree
adaptation, and the patches here fix the issue:

http://marc.info/?l=linux-omap&m=133112435224731&w=2

I wasn't planning to merge them yet, as it's quite late in the release
cycle, but it seems I have to. I think I'll drop some of the unrelated
patches (taal and tfp410 related) from that series, as they are just
cleanup-churn.

> However, I doubt simply moving the driver registration calls out of the
> probe function will be enough - "OMAP: DSS2: Fix init and unit sequence"
> hints that there's a dependence in the driver initialization order.
> That's another finger pointing at the approach being wrong, because
> there is _no_ guarantee as to the order in which drivers or devices are
> probed by the driver model.

True. I think the best would be to have a dynamic approach, where the
subdrivers would register themselves somewhere, and it the order
wouldn't matter. That would even allow compiling the subdrivers as
separate modules.

But that's a bigger work item, so what I did in the series above is that
I changed platform_driver_register()s to platform_driver_probe()s. All
the DSS subdevices are present at boot time and are non-hotpluggable, so
I think that should work fine.

However, there's one problem with this approach that is present in the
code: we don't know if platform_driver_probe() returns an error because
there are no devices for the driver (e.g. no HDMI on OMAP3), or because
the probe of the driver failed. In the former case we don't need to care
about the error, but in the latter case we should do something.

I'll try to find a quick solution for this also.

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: arm-soc + rmk's tree boot failure on OMAP4430SDP

[Russell King - ARM Linux]

On Mon, Mar 19, 2012 at 11:33:21AM +0200, Tomi Valkeinen wrote:
> But that's a bigger work item, so what I did in the series above is that
> I changed platform_driver_register()s to platform_driver_probe()s. All
> the DSS subdevices are present at boot time and are non-hotpluggable, so
> I think that should work fine.

platform_driver_probe() is just a wrapper around platform_driver_register() -
the difference between the two is that _probe() will temporarily set the
probe method in the passed driver structure, call platform_driver_register(),
and then NULL the probe method out.

So, merely changing platform_driver_register() for platform_driver_probe()
won't solve the deadlock.

I'm not sure what's caused this regression, as I can't see any DSS changes,
nor core driver model changes which would account for this.  Has something
changed in hwmod to cause this?

It is _very_ important that we discover what has caused this regression
and prevent it going upstream until the problem is resolved.  Until we
know that, I suggest that _no_ OMAP changes go upstream during this
merge window until we understand what's caused this.

Re: arm-soc + rmk's tree boot failure on OMAP4430SDP

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 2448 bytes --]

On Mon, 2012-03-19 at 12:30 +0000, Russell King - ARM Linux wrote:
> On Mon, Mar 19, 2012 at 11:33:21AM +0200, Tomi Valkeinen wrote:
> > But that's a bigger work item, so what I did in the series above is that
> > I changed platform_driver_register()s to platform_driver_probe()s. All
> > the DSS subdevices are present at boot time and are non-hotpluggable, so
> > I think that should work fine.
> 
> platform_driver_probe() is just a wrapper around platform_driver_register() -
> the difference between the two is that _probe() will temporarily set the
> probe method in the passed driver structure, call platform_driver_register(),
> and then NULL the probe method out.

I meant that platform_driver_probe() solves the issue with the
initialization order of the dss subdrivers.

The deadlock is solved in the series by moving the driver registration
to module_init.

> So, merely changing platform_driver_register() for platform_driver_probe()
> won't solve the deadlock.
> 
> I'm not sure what's caused this regression, as I can't see any DSS changes,
> nor core driver model changes which would account for this.  Has something
> changed in hwmod to cause this?
> 
> It is _very_ important that we discover what has caused this regression
> and prevent it going upstream until the problem is resolved.  Until we
> know that, I suggest that _no_ OMAP changes go upstream during this
> merge window until we understand what's caused this.

I didn't try yet, but it could be this:

commit 3ec2decbb6dfcdbbb6e6a8ddf5adc7edbc429ed7
Author: Kevin Hilman <khilman@ti.com>
Date:   Wed Feb 15 11:47:45 2012 -0800

    ARM: OMAP: omap_device: remove omap_device_parent
    
    Currently all omap_devices are forced to have the dummy device
    'omap_device_parent' as a parent.  This was used to distinguish
    omap_devices from "normal" platform_devices in the OMAP PM core code.
    
    Now that we implement the PM core using PM domains, this is no longer
    needed, and is removed.
    
    This also frees up omap_devices to have a more complex parent/child
    relationships that model actual device relationships.
    
    The only in-tree user of omap_device_parent was the OMAP PM layer to
    handle lost-context count for omap_devices.  That is now converted to
    use the presence of the omap_device_pm_domain instead.
    
    Signed-off-by: Kevin Hilman <khilman@ti.com>

Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: arm-soc + rmk's tree boot failure on OMAP4430SDP

[Russell King - ARM Linux]

On Mon, Mar 19, 2012 at 02:41:04PM +0200, Tomi Valkeinen wrote:
> On Mon, 2012-03-19 at 12:30 +0000, Russell King - ARM Linux wrote:
> > On Mon, Mar 19, 2012 at 11:33:21AM +0200, Tomi Valkeinen wrote:
> > > But that's a bigger work item, so what I did in the series above is that
> > > I changed platform_driver_register()s to platform_driver_probe()s. All
> > > the DSS subdevices are present at boot time and are non-hotpluggable, so
> > > I think that should work fine.
> > 
> > platform_driver_probe() is just a wrapper around platform_driver_register() -
> > the difference between the two is that _probe() will temporarily set the
> > probe method in the passed driver structure, call platform_driver_register(),
> > and then NULL the probe method out.
> 
> I meant that platform_driver_probe() solves the issue with the
> initialization order of the dss subdrivers.
> 
> The deadlock is solved in the series by moving the driver registration
> to module_init.
> 
> > So, merely changing platform_driver_register() for platform_driver_probe()
> > won't solve the deadlock.
> > 
> > I'm not sure what's caused this regression, as I can't see any DSS changes,
> > nor core driver model changes which would account for this.  Has something
> > changed in hwmod to cause this?
> > 
> > It is _very_ important that we discover what has caused this regression
> > and prevent it going upstream until the problem is resolved.  Until we
> > know that, I suggest that _no_ OMAP changes go upstream during this
> > merge window until we understand what's caused this.
> 
> I didn't try yet, but it could be this:
> 
> commit 3ec2decbb6dfcdbbb6e6a8ddf5adc7edbc429ed7
> Author: Kevin Hilman <khilman@ti.com>
> Date:   Wed Feb 15 11:47:45 2012 -0800
> 
>     ARM: OMAP: omap_device: remove omap_device_parent
>     
>     Currently all omap_devices are forced to have the dummy device
>     'omap_device_parent' as a parent.  This was used to distinguish
>     omap_devices from "normal" platform_devices in the OMAP PM core code.
>     
>     Now that we implement the PM core using PM domains, this is no longer
>     needed, and is removed.
>     
>     This also frees up omap_devices to have a more complex parent/child
>     relationships that model actual device relationships.
>     
>     The only in-tree user of omap_device_parent was the OMAP PM layer to
>     handle lost-context count for omap_devices.  That is now converted to
>     use the presence of the omap_device_pm_domain instead.
>     
>     Signed-off-by: Kevin Hilman <khilman@ti.com>

Yes, it could well be caused by this.  What would've happened before is
that the omapdss device would have been parented to the 'platform' device,
while the hwmod-built devices would've been parented to omap_device_parent.

With the above commit, both devices would be parented to the 'platform'
device, which would cause lock contention.

I've just built with this reverted (which was a relatively clean revert) -
and doing so appears to allow the kernel to boot again.

Re: arm-soc + rmk's tree boot failure on OMAP4430SDP

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 1610 bytes --]

On Mon, 2012-03-19 at 14:41 +0200, Tomi Valkeinen wrote:
> On Mon, 2012-03-19 at 12:30 +0000, Russell King - ARM Linux wrote:

> > It is _very_ important that we discover what has caused this regression
> > and prevent it going upstream until the problem is resolved.  Until we
> > know that, I suggest that _no_ OMAP changes go upstream during this
> > merge window until we understand what's caused this.
> 
> I didn't try yet, but it could be this:
> 
> commit 3ec2decbb6dfcdbbb6e6a8ddf5adc7edbc429ed7
> Author: Kevin Hilman <khilman@ti.com>
> Date:   Wed Feb 15 11:47:45 2012 -0800
> 
>     ARM: OMAP: omap_device: remove omap_device_parent

Reverting that patch makes dss work again. I don't know all the details
of device/driver registration, but I guess the problem is this:

"omapdss" device is a platform_device, and there's no hwmod for it. The
dss subdrivers (which have a corresponding hwmod) are being registered
in omapdss-driver's probe. Previously the dss subdrivers had
"omap_device_parent" device as their parent, and this avoided the
deadlock between omapdss and the subdrivers.

Now, with that patch, both omapdss and dss subdrivers have
platform_driver as parent, causing the deadlock.

The patch does make sense, though. I hope nothing else than omapdss is
using the device framework in similar braindead way.

I'll see if I can make a single patch that fixes the issue. The patch
series I mentioned earlier does lots of things, but I think just moving
the driver registration out of the probe function should be enough to
avoid the problem.

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: arm-soc + rmk's tree boot failure on OMAP4430SDP

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 6148 bytes --]

On Mon, 2012-03-19 at 15:02 +0200, Tomi Valkeinen wrote:

> I'll see if I can make a single patch that fixes the issue. The patch
> series I mentioned earlier does lots of things, but I think just moving
> the driver registration out of the probe function should be enough to
> avoid the problem.

Here's a patch that fixes the issue for me. Tested on OMAP4 Blaze with
omapdss both as module and built-in. I'll queue this up after testing it
a bit more.

This still leaves the issue of initialization order, but I think that's
not a big issue at the moment. It doesn't happen in practice, as the
current driver framework will probe the devices at driver registration
time. I'll fix this for the next merge window.

 Tomi


From 39ff2ded6c79d40d09597a56ddcf584470c6e699 Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
Date: Mon, 19 Mar 2012 15:05:02 +0200
Subject: [PATCH] OMAPDSS: register dss drivers in module init

We do the dss driver registration in a rather strange way: we have the
higher level omapdss driver, and we use that driver's probe function to
register the drivers for the rest of the dss devices.

There doesn't seem to be any reason for that, and additionally the
soon-to-be-merged patch "ARM: OMAP: omap_device: remove
omap_device_parent" will break omapdss initialization with the current
registration model.

This patch changes the registration for all drivers to happen at the
same place, in the init of the module.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
 drivers/video/omap2/dss/core.c |  135 +++++++++++++++++++++++-----------------
 1 files changed, 77 insertions(+), 58 deletions(-)

diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 8613f86..e8a1207 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -183,42 +183,6 @@ static int omap_dss_probe(struct platform_device *pdev)
 	dss_init_overlay_managers(pdev);
 	dss_init_overlays(pdev);
 
-	r = dss_init_platform_driver();
-	if (r) {
-		DSSERR("Failed to initialize DSS platform driver\n");
-		goto err_dss;
-	}
-
-	r = dispc_init_platform_driver();
-	if (r) {
-		DSSERR("Failed to initialize dispc platform driver\n");
-		goto err_dispc;
-	}
-
-	r = rfbi_init_platform_driver();
-	if (r) {
-		DSSERR("Failed to initialize rfbi platform driver\n");
-		goto err_rfbi;
-	}
-
-	r = venc_init_platform_driver();
-	if (r) {
-		DSSERR("Failed to initialize venc platform driver\n");
-		goto err_venc;
-	}
-
-	r = dsi_init_platform_driver();
-	if (r) {
-		DSSERR("Failed to initialize DSI platform driver\n");
-		goto err_dsi;
-	}
-
-	r = hdmi_init_platform_driver();
-	if (r) {
-		DSSERR("Failed to initialize hdmi\n");
-		goto err_hdmi;
-	}
-
 	r = dss_initialize_debugfs();
 	if (r)
 		goto err_debugfs;
@@ -246,18 +210,6 @@ static int omap_dss_probe(struct platform_device *pdev)
 err_register:
 	dss_uninitialize_debugfs();
 err_debugfs:
-	hdmi_uninit_platform_driver();
-err_hdmi:
-	dsi_uninit_platform_driver();
-err_dsi:
-	venc_uninit_platform_driver();
-err_venc:
-	dispc_uninit_platform_driver();
-err_dispc:
-	rfbi_uninit_platform_driver();
-err_rfbi:
-	dss_uninit_platform_driver();
-err_dss:
 
 	return r;
 }
@@ -269,13 +221,6 @@ static int omap_dss_remove(struct platform_device *pdev)
 
 	dss_uninitialize_debugfs();
 
-	hdmi_uninit_platform_driver();
-	dsi_uninit_platform_driver();
-	venc_uninit_platform_driver();
-	rfbi_uninit_platform_driver();
-	dispc_uninit_platform_driver();
-	dss_uninit_platform_driver();
-
 	dss_uninit_overlays(pdev);
 	dss_uninit_overlay_managers(pdev);
 
@@ -525,6 +470,80 @@ static int omap_dss_bus_register(void)
 
 /* INIT */
 
+static int __init omap_dss_register_drivers(void)
+{
+	int r;
+
+	r = platform_driver_register(&omap_dss_driver);
+	if (r)
+		return r;
+
+	r = dss_init_platform_driver();
+	if (r) {
+		DSSERR("Failed to initialize DSS platform driver\n");
+		goto err_dss;
+	}
+
+	r = dispc_init_platform_driver();
+	if (r) {
+		DSSERR("Failed to initialize dispc platform driver\n");
+		goto err_dispc;
+	}
+
+	r = rfbi_init_platform_driver();
+	if (r) {
+		DSSERR("Failed to initialize rfbi platform driver\n");
+		goto err_rfbi;
+	}
+
+	r = venc_init_platform_driver();
+	if (r) {
+		DSSERR("Failed to initialize venc platform driver\n");
+		goto err_venc;
+	}
+
+	r = dsi_init_platform_driver();
+	if (r) {
+		DSSERR("Failed to initialize DSI platform driver\n");
+		goto err_dsi;
+	}
+
+	r = hdmi_init_platform_driver();
+	if (r) {
+		DSSERR("Failed to initialize hdmi\n");
+		goto err_hdmi;
+	}
+
+	return 0;
+
+err_hdmi:
+	dsi_uninit_platform_driver();
+err_dsi:
+	venc_uninit_platform_driver();
+err_venc:
+	rfbi_uninit_platform_driver();
+err_rfbi:
+	dispc_uninit_platform_driver();
+err_dispc:
+	dss_uninit_platform_driver();
+err_dss:
+	platform_driver_unregister(&omap_dss_driver);
+
+	return r;
+}
+
+static void __exit omap_dss_unregister_drivers(void)
+{
+	hdmi_uninit_platform_driver();
+	dsi_uninit_platform_driver();
+	venc_uninit_platform_driver();
+	rfbi_uninit_platform_driver();
+	dispc_uninit_platform_driver();
+	dss_uninit_platform_driver();
+
+	platform_driver_unregister(&omap_dss_driver);
+}
+
 #ifdef CONFIG_OMAP2_DSS_MODULE
 static void omap_dss_bus_unregister(void)
 {
@@ -541,7 +560,7 @@ static int __init omap_dss_init(void)
 	if (r)
 		return r;
 
-	r = platform_driver_register(&omap_dss_driver);
+	r = omap_dss_register_drivers();
 	if (r) {
 		omap_dss_bus_unregister();
 		return r;
@@ -562,7 +581,7 @@ static void __exit omap_dss_exit(void)
 		core.vdds_sdi_reg = NULL;
 	}
 
-	platform_driver_unregister(&omap_dss_driver);
+	omap_dss_unregister_drivers();
 
 	omap_dss_bus_unregister();
 }
@@ -577,7 +596,7 @@ static int __init omap_dss_init(void)
 
 static int __init omap_dss_init2(void)
 {
-	return platform_driver_register(&omap_dss_driver);
+	return omap_dss_register_drivers();
 }
 
 core_initcall(omap_dss_init);
-- 
1.7.4.1



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: arm-soc + rmk's tree boot failure on OMAP4430SDP

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [120319 07:01]:
> On Mon, 2012-03-19 at 15:02 +0200, Tomi Valkeinen wrote:
> 
> > I'll see if I can make a single patch that fixes the issue. The patch
> > series I mentioned earlier does lots of things, but I think just moving
> > the driver registration out of the probe function should be enough to
> > avoid the problem.
> 
> Here's a patch that fixes the issue for me. Tested on OMAP4 Blaze with
> omapdss both as module and built-in. I'll queue this up after testing it
> a bit more.

OK works for me too.
 
> This still leaves the issue of initialization order, but I think that's
> not a big issue at the moment. It doesn't happen in practice, as the
> current driver framework will probe the devices at driver registration
> time. I'll fix this for the next merge window.

Yes that's something that needs fixing.

Regards,

Tony

Re: arm-soc + rmk's tree boot failure on OMAP4430SDP

[Russ Dill]

On Mon, Mar 19, 2012 at 6:59 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On Mon, 2012-03-19 at 15:02 +0200, Tomi Valkeinen wrote:
>
>> I'll see if I can make a single patch that fixes the issue. The patch
>> series I mentioned earlier does lots of things, but I think just moving
>> the driver registration out of the probe function should be enough to
>> avoid the problem.
>
> Here's a patch that fixes the issue for me. Tested on OMAP4 Blaze with
> omapdss both as module and built-in. I'll queue this up after testing it
> a bit more.
>
> This still leaves the issue of initialization order, but I think that's
> not a big issue at the moment. It doesn't happen in practice, as the
> current driver framework will probe the devices at driver registration
> time. I'll fix this for the next merge window.

I bisected a boot failure on an am37x-evm to 3ec2decb commit as well.
This fixes it for me too.