From: Rob Clark rob@ti.com
Not sure what triggered the change in behavior, but seems to result in recursively acquiring a mutex and hanging on boot. But omap_drm_init() seems a much more sane place to register the driver for the DMM sub-device. --- drivers/staging/omapdrm/omap_drv.c | 7 ++++--- 1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/omapdrm/omap_drv.c b/drivers/staging/omapdrm/omap_drv.c index 3df5b4c..620b8d5 100644 --- a/drivers/staging/omapdrm/omap_drv.c +++ b/drivers/staging/omapdrm/omap_drv.c @@ -803,9 +803,6 @@ static void pdev_shutdown(struct platform_device *device) static int pdev_probe(struct platform_device *device) { DBG("%s", device->name); - if (platform_driver_register(&omap_dmm_driver)) - dev_err(&device->dev, "DMM registration failed\n"); - return drm_platform_init(&omap_drm_driver, device); }
@@ -833,6 +830,10 @@ struct platform_driver pdev = { static int __init omap_drm_init(void) { DBG("init"); + if (platform_driver_register(&omap_dmm_driver)) { + /* we can continue on without DMM.. so not fatal */ + dev_err(NULL, "DMM registration failed\n"); + } return platform_driver_register(&pdev); }
On Thu, Apr 05, 2012 at 10:34:56AM -0500, Rob Clark wrote:
From: Rob Clark rob@ti.com
Not sure what triggered the change in behavior, but seems to result in recursively acquiring a mutex and hanging on boot. But omap_drm_init() seems a much more sane place to register the driver for the DMM sub-device.
drivers/staging/omapdrm/omap_drv.c | 7 ++++--- 1 files changed, 4 insertions(+), 3 deletions(-)
Is this needed for 3.4-final? Any older kernels like 3.3 as well?
thanks,
greg k-h
On Thu, Apr 5, 2012 at 11:41 AM, Greg KH greg@kroah.com wrote:
On Thu, Apr 05, 2012 at 10:34:56AM -0500, Rob Clark wrote:
From: Rob Clark rob@ti.com
Not sure what triggered the change in behavior, but seems to result in recursively acquiring a mutex and hanging on boot. But omap_drm_init() seems a much more sane place to register the driver for the DMM sub-device.
drivers/staging/omapdrm/omap_drv.c | 7 ++++--- 1 files changed, 4 insertions(+), 3 deletions(-)
Is this needed for 3.4-final? Any older kernels like 3.3 as well?
Yeah, it is needed for 3.4-final.. I need to check on 3.3 (it was fine circa 3.3-rc6 or rc7)
BR, -R
thanks,
greg k-h _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Thu, Apr 05, 2012 at 11:51:30AM -0500, Rob Clark wrote:
On Thu, Apr 5, 2012 at 11:41 AM, Greg KH greg@kroah.com wrote:
On Thu, Apr 05, 2012 at 10:34:56AM -0500, Rob Clark wrote:
From: Rob Clark rob@ti.com
Not sure what triggered the change in behavior, but seems to result in recursively acquiring a mutex and hanging on boot. But omap_drm_init() seems a much more sane place to register the driver for the DMM sub-device.
drivers/staging/omapdrm/omap_drv.c | 7 ++++--- 1 files changed, 4 insertions(+), 3 deletions(-)
Is this needed for 3.4-final? Any older kernels like 3.3 as well?
Yeah, it is needed for 3.4-final.. I need to check on 3.3 (it was fine circa 3.3-rc6 or rc7)
Ok, I'll queue it up for 3.4-final, let me know if it's also needed in 3.3 if you get the chance.
greg k-h
On Thu, Apr 5, 2012 at 11:58 AM, Greg KH greg@kroah.com wrote:
On Thu, Apr 05, 2012 at 11:51:30AM -0500, Rob Clark wrote:
On Thu, Apr 5, 2012 at 11:41 AM, Greg KH greg@kroah.com wrote:
On Thu, Apr 05, 2012 at 10:34:56AM -0500, Rob Clark wrote:
From: Rob Clark rob@ti.com
Not sure what triggered the change in behavior, but seems to result in recursively acquiring a mutex and hanging on boot. But omap_drm_init() seems a much more sane place to register the driver for the DMM sub-device.
drivers/staging/omapdrm/omap_drv.c | 7 ++++--- 1 files changed, 4 insertions(+), 3 deletions(-)
Is this needed for 3.4-final? Any older kernels like 3.3 as well?
Yeah, it is needed for 3.4-final.. I need to check on 3.3 (it was fine circa 3.3-rc6 or rc7)
Ok, I'll queue it up for 3.4-final, let me know if it's also needed in 3.3 if you get the chance.
oh, duh.. I realized that patch that split DMM into a sub-device (for hwmod) was actually part of the patches for 3.4, so the problem didn't exist yet in 3.3 :-)
BR, -R
greg k-h
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
dri-devel@lists.freedesktop.org
-
Greg KH -
Rob Clark