Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[PATCH] imx-drm: Fix probe failure

101 views
Skip to first unread message

Fabio Estevam

unread,
Aug 27, 2013, 10:50:01 PM8/27/13
to
From: Fabio Estevam <fabio....@freescale.com>

Since commit b5dc0d10 (drm/imx: kill firstopen callback) the following probe
failure is seen:

[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] No driver support for vblank timestamp query.
[drm] Initialized imx-drm 1.0.0 20120507 on minor 0
imx-ldb ldb.10: adding encoder failed with -16
imx-ldb: probe of ldb.10 failed with error -16
imx-ipuv3 2400000.ipu: IPUv3H probed
imx-ipuv3 2800000.ipu: IPUv3H probed
imx-ipuv3-crtc imx-ipuv3-crtc.0: adding crtc failed with -16.
imx-ipuv3-crtc: probe of imx-ipuv3-crtc.0 failed with error -16
imx-ipuv3-crtc imx-ipuv3-crtc.1: adding crtc failed with -16.
imx-ipuv3-crtc: probe of imx-ipuv3-crtc.1 failed with error -16
imx-ipuv3-crtc imx-ipuv3-crtc.2: adding crtc failed with -16.
imx-ipuv3-crtc: probe of imx-ipuv3-crtc.2 failed with error -16
imx-ipuv3-crtc imx-ipuv3-crtc.3: adding crtc failed with -16.
imx-ipuv3-crtc: probe of imx-ipuv3-crtc.3 failed with error -16

'imxdrm->references' is not keeping the references correctly, causing the probe
to fail, so let's get rid of it.

After this patch, lvds panel is functional on a mx6qsabrelite board.

Signed-off-by: Fabio Estevam <fabio....@freescale.com>
---
drivers/staging/imx-drm/imx-drm-core.c | 25 +------------------------
1 file changed, 1 insertion(+), 24 deletions(-)

diff --git a/drivers/staging/imx-drm/imx-drm-core.c b/drivers/staging/imx-drm/imx-drm-core.c
index 47c5888..98eac33 100644
--- a/drivers/staging/imx-drm/imx-drm-core.c
+++ b/drivers/staging/imx-drm/imx-drm-core.c
@@ -41,7 +41,6 @@ struct imx_drm_device {
struct list_head encoder_list;
struct list_head connector_list;
struct mutex mutex;
- int references;
int pipes;
struct drm_fbdev_cma *fbhelper;
};
@@ -241,8 +240,6 @@ struct drm_device *imx_drm_device_get(void)
}
}

- imxdrm->references++;
-
return imxdrm->drm;

unwind_crtc:
@@ -280,8 +277,6 @@ void imx_drm_device_put(void)
list_for_each_entry(enc, &imxdrm->encoder_list, list)
module_put(enc->owner);

- imxdrm->references--;
-
mutex_unlock(&imxdrm->mutex);
}
EXPORT_SYMBOL_GPL(imx_drm_device_put);
@@ -485,11 +480,6 @@ int imx_drm_add_crtc(struct drm_crtc *crtc,

mutex_lock(&imxdrm->mutex);

- if (imxdrm->references) {
- ret = -EBUSY;
- goto err_busy;
- }
-
imx_drm_crtc = kzalloc(sizeof(*imx_drm_crtc), GFP_KERNEL);
if (!imx_drm_crtc) {
ret = -ENOMEM;
@@ -523,7 +513,6 @@ int imx_drm_add_crtc(struct drm_crtc *crtc,
err_register:
kfree(imx_drm_crtc);
err_alloc:
-err_busy:
mutex_unlock(&imxdrm->mutex);
return ret;
}
@@ -564,11 +553,6 @@ int imx_drm_add_encoder(struct drm_encoder *encoder,

mutex_lock(&imxdrm->mutex);

- if (imxdrm->references) {
- ret = -EBUSY;
- goto err_busy;
- }
-
imx_drm_encoder = kzalloc(sizeof(*imx_drm_encoder), GFP_KERNEL);
if (!imx_drm_encoder) {
ret = -ENOMEM;
@@ -583,7 +567,7 @@ int imx_drm_add_encoder(struct drm_encoder *encoder,
ret = -ENOMEM;
goto err_register;
}
-
+
list_add_tail(&imx_drm_encoder->list, &imxdrm->encoder_list);

*newenc = imx_drm_encoder;
@@ -595,7 +579,6 @@ int imx_drm_add_encoder(struct drm_encoder *encoder,
err_register:
kfree(imx_drm_encoder);
err_alloc:
-err_busy:
mutex_unlock(&imxdrm->mutex);

return ret;
@@ -709,11 +692,6 @@ int imx_drm_add_connector(struct drm_connector *connector,

mutex_lock(&imxdrm->mutex);

- if (imxdrm->references) {
- ret = -EBUSY;
- goto err_busy;
- }
-
imx_drm_connector = kzalloc(sizeof(*imx_drm_connector), GFP_KERNEL);
if (!imx_drm_connector) {
ret = -ENOMEM;
@@ -738,7 +716,6 @@ int imx_drm_add_connector(struct drm_connector *connector,
err_register:
kfree(imx_drm_connector);
err_alloc:
-err_busy:
mutex_unlock(&imxdrm->mutex);

return ret;
--
1.8.1.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Greg KH

unread,
Aug 27, 2013, 11:10:02 PM8/27/13
to
On Tue, Aug 27, 2013 at 11:32:43PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio....@freescale.com>
>
> Since commit b5dc0d10 (drm/imx: kill firstopen callback) the following probe
> failure is seen:

I don't have that commit in any tree I control, so I can't apply this
patch. What tree is this commit in?

thanks,

greg k-h

Fabio Estevam

unread,
Aug 27, 2013, 11:30:01 PM8/27/13
to
Hi Greg,

On Wed, Aug 28, 2013 at 12:11 AM, Greg KH <gre...@linuxfoundation.org> wrote:
> On Tue, Aug 27, 2013 at 11:32:43PM -0300, Fabio Estevam wrote:
>> From: Fabio Estevam <fabio....@freescale.com>
>>
>> Since commit b5dc0d10 (drm/imx: kill firstopen callback) the following probe
>> failure is seen:
>
> I don't have that commit in any tree I control, so I can't apply this
> patch. What tree is this commit in?

Ok, understood.

Just realized that this commit reached linux-next via Dave Airlie's tree:

commit b5dc0d108cd3c0b50ddcb6f6c54be1
bea4c39e01
Author: Daniel Vetter <daniel...@ffwll.ch>
Date: Thu Aug 8 15:41:13 2013 +0200

drm/imx: kill firstopen callback

This thing seems to do some kind of delayed setup. Really, real kms
drivers shouldn't do that at all. Either stuff needs to be dynamically
hotplugged or the driver setup sequence needs to be fixed.

This patch here just moves the setup at the very end of the driver
load callback, with the locking adjusted accordingly.

v2: Also move the corresponding put from ->lastclose to ->unload.

Cc: Sascha Hauer <s.h...@pengutronix.de>
Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
Signed-off-by: Daniel Vetter <daniel...@ffwll.ch>
Acked-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
Signed-off-by: Dave Airlie <air...@redhat.com>

Will resend it to Dave then.

Thanks,

Fabio Estevam

Sascha Hauer

unread,
Aug 28, 2013, 1:30:01 AM8/28/13
to
On Tue, Aug 27, 2013 at 11:32:43PM -0300, Fabio Estevam wrote:
Nack. We need the references to prevent that encoders/connectors are
(de)registered while the device is active. Simply dropping this code is
no solution.

Sascha

--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |

Fabio Estevam

unread,
Aug 28, 2013, 10:40:02 AM8/28/13
to
On Wed, Aug 28, 2013 at 2:27 AM, Sascha Hauer <s.h...@pengutronix.de> wrote:

> Nack. We need the references to prevent that encoders/connectors are
> (de)registered while the device is active. Simply dropping this code is
> no solution.

Any suggestions about a proper way of handling this?

After b5dc0d10, imx_drm_device_get() is called from
imx_drm_driver_load(), which increments the 'references' very early
now.

Then when we check:

if (imxdrm->references) {
ret = -EBUSY;
goto err_busy;
}

,it will fail always.

Not sure where is a proper location to increment/decrement
'imxdrm->references' though.

Tried to look at other drm drivers, but could not find examples on how
to deal with such references.

Regards,

Fabio Estevam

Sascha Hauer

unread,
Aug 28, 2013, 3:00:03 PM8/28/13
to
On Wed, Aug 28, 2013 at 11:39:11AM -0300, Fabio Estevam wrote:
> On Wed, Aug 28, 2013 at 2:27 AM, Sascha Hauer <s.h...@pengutronix.de> wrote:
>
> > Nack. We need the references to prevent that encoders/connectors are
> > (de)registered while the device is active. Simply dropping this code is
> > no solution.
>
> Any suggestions about a proper way of handling this?
>
> After b5dc0d10, imx_drm_device_get() is called from
> imx_drm_driver_load(), which increments the 'references' very early
> now.

Do the open/close callbacks work?

Sascha

--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |

Fabio Estevam

unread,
Aug 28, 2013, 4:20:02 PM8/28/13
to
On Wed, Aug 28, 2013 at 3:54 PM, Sascha Hauer <s.h...@pengutronix.de> wrote:

> Do the open/close callbacks work?

The 'open' callback maps to the generic 'drm_open', so we cannot use it.

Shouldn't we rely on the refcount done by the drm core instead of
doing this manually in imx-drm?

Sascha Hauer

unread,
Aug 28, 2013, 4:40:02 PM8/28/13
to
On Wed, Aug 28, 2013 at 05:10:16PM -0300, Fabio Estevam wrote:
> On Wed, Aug 28, 2013 at 3:54 PM, Sascha Hauer <s.h...@pengutronix.de> wrote:
>
> > Do the open/close callbacks work?
>
> The 'open' callback maps to the generic 'drm_open', so we cannot use it.

We could replace this, but...

>
> Shouldn't we rely on the refcount done by the drm core instead of
> doing this manually in imx-drm?

...This could be a better solution.

you mean (struct drm_device)->open_count, right?

Sascha

--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |

Fabio Estevam

unread,
Aug 28, 2013, 6:40:01 PM8/28/13
to
On Wed, Aug 28, 2013 at 5:34 PM, Sascha Hauer <s.h...@pengutronix.de> wrote:
> On Wed, Aug 28, 2013 at 05:10:16PM -0300, Fabio Estevam wrote:
>> On Wed, Aug 28, 2013 at 3:54 PM, Sascha Hauer <s.h...@pengutronix.de> wrote:
>>
>> > Do the open/close callbacks work?
>>
>> The 'open' callback maps to the generic 'drm_open', so we cannot use it.
>
> We could replace this, but...
>
>>
>> Shouldn't we rely on the refcount done by the drm core instead of
>> doing this manually in imx-drm?
>
> ...This could be a better solution.
>
> you mean (struct drm_device)->open_count, right?

Yes, and open_count is already handled by drm_open/drm_release
callbacks, which is something we currently use inside imx-drm-core.

Fabio Estevam

unread,
Aug 29, 2013, 10:00:02 AM8/29/13
to
Since commit b5dc0d10 (drm/imx: kill firstopen callback) the following probe
failure is seen:

[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] No driver support for vblank timestamp query.
[drm] Initialized imx-drm 1.0.0 20120507 on minor 0
imx-ldb ldb.10: adding encoder failed with -16
imx-ldb: probe of ldb.10 failed with error -16
imx-ipuv3 2400000.ipu: IPUv3H probed
imx-ipuv3 2800000.ipu: IPUv3H probed
imx-ipuv3-crtc imx-ipuv3-crtc.0: adding crtc failed with -16.
imx-ipuv3-crtc: probe of imx-ipuv3-crtc.0 failed with error -16
imx-ipuv3-crtc imx-ipuv3-crtc.1: adding crtc failed with -16.
imx-ipuv3-crtc: probe of imx-ipuv3-crtc.1 failed with error -16
imx-ipuv3-crtc imx-ipuv3-crtc.2: adding crtc failed with -16.
imx-ipuv3-crtc: probe of imx-ipuv3-crtc.2 failed with error -16
imx-ipuv3-crtc imx-ipuv3-crtc.3: adding crtc failed with -16.
imx-ipuv3-crtc: probe of imx-ipuv3-crtc.3 failed with error -16

The reason for the probe failure is that now 'imxdrm->references' is incremented
early in imx_drm_driver_load(), so the following checks in imx_drm_add_crtc()
and imx_drm_add_encoder():

if (imxdrm->references) {
ret = -EBUSY;
goto err_busy;
}

,will always fail.

Let the drm core handle the references instead of doing this manually in
imx-drm. In imx-drm-core the open and close callbacks map to drm_open and
drm_close, which handle the references via open_count.

After this patch, lvds panel is functional on a mx6qsabrelite board.

Signed-off-by: Fabio Estevam <fabio....@freescale.com>
---
Changes since v1:
- Improved commit log by providing an explanation to the probe failure
- Cc'ed Dave/Daniel

drivers/staging/imx-drm/imx-drm-core.c | 23 -----------------------
1 file changed, 23 deletions(-)

diff --git a/drivers/staging/imx-drm/imx-drm-core.c b/drivers/staging/imx-drm/imx-drm-core.c
index 47c5888..6f0d24c 100644
--- a/drivers/staging/imx-drm/imx-drm-core.c
+++ b/drivers/staging/imx-drm/imx-drm-core.c
@@ -41,7 +41,6 @@ struct imx_drm_device {
struct list_head encoder_list;
struct list_head connector_list;
struct mutex mutex;
- int references;

Daniel Vetter

unread,
Aug 29, 2013, 11:30:02 AM8/29/13
to
Yeah, just ripping out the imxdrm->references stuff will restore imx, but
of course all the funny races are still fundamentally there. So we still
rely on userspace being really careful to obey the right module loading
sequence and not start any drm client before that has all completed. So

Reviewed-by: Daniel Vetter <daniel...@ffwll.ch>

Greg, when you slurp this in can you pls also add the imx todo entry from
the other thread?

http://www.mail-archive.com/dri-...@lists.freedesktop.org/msg43698.html

Or do you want me to send in a real patch?

Thanks, Daniel
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Sascha Hauer

unread,
Aug 29, 2013, 2:20:03 PM8/29/13
to
On Thu, Aug 29, 2013 at 10:59:22AM -0300, Fabio Estevam wrote:
> @@ -485,11 +480,6 @@ int imx_drm_add_crtc(struct drm_crtc *crtc,
>
> mutex_lock(&imxdrm->mutex);
>
> - if (imxdrm->references) {
> - ret = -EBUSY;
> - goto err_busy;
> - }

As I told in v1: Simply removing the code is not an option. We agreed
that we use the drm core reference counting, so you must actually test
for it here...

> @@ -564,11 +553,6 @@ int imx_drm_add_encoder(struct drm_encoder *encoder,
>
> mutex_lock(&imxdrm->mutex);
>
> - if (imxdrm->references) {
> - ret = -EBUSY;
> - goto err_busy;
> - }

...here...

> mutex_lock(&imxdrm->mutex);
>
> - if (imxdrm->references) {
> - ret = -EBUSY;
> - goto err_busy;
> - }

...and here.

Sascha

--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |

Sascha Hauer

unread,
Aug 29, 2013, 2:40:01 PM8/29/13
to
You said there:

> +- Fix up the driver load sequence to make sure all submodules for encoders/crtcs
> + are fully loaded before the drm driver is registered.

We can't know when all submodules are registered and really I think this
is not necessary. The driver will use the components available during
open time. When being opened no components will be registered/deregistered.
So a user will always get a functional drm device with the components he
actually loaded.

Sascha

--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |

Fabio Estevam

unread,
Aug 29, 2013, 2:40:01 PM8/29/13
to
Yes, we did, but after reading a separate thread on this topic, I
learned that drm core does not support it currently.

Daniel mentions [1]: "And I wouldn't worry about module unloading and
refcounting for
now since core drm is terminally broken in that area already anyway"

[1] http://www.mail-archive.com/dri-...@lists.freedesktop.org/msg43698.html

Can't we just apply this patch so that imx-drm can be functional again
and fix module unloading/refcount later?

Sascha Hauer

unread,
Aug 29, 2013, 2:40:03 PM8/29/13
to
On Thu, Aug 29, 2013 at 03:30:12PM -0300, Fabio Estevam wrote:
> >> @@ -485,11 +480,6 @@ int imx_drm_add_crtc(struct drm_crtc *crtc,
> >>
> >> mutex_lock(&imxdrm->mutex);
> >>
> >> - if (imxdrm->references) {
> >> - ret = -EBUSY;
> >> - goto err_busy;
> >> - }
> >
> > As I told in v1: Simply removing the code is not an option. We agreed
> > that we use the drm core reference counting, so you must actually test
> > for it here...
>
> Yes, we did, but after reading a separate thread on this topic, I
> learned that drm core does not support it currently.
>
> Daniel mentions [1]: "And I wouldn't worry about module unloading and
> refcounting for
> now since core drm is terminally broken in that area already anyway"
>
> [1] http://www.mail-archive.com/dri-...@lists.freedesktop.org/msg43698.html
>
> Can't we just apply this patch so that imx-drm can be functional again
> and fix module unloading/refcount later?

It's not about the module refcount. It's only that a on a drm device
which is in use you better do not add/remove components.

Again: The imx-drm driver does *not* do hotplugging. It will *not* add
or remove components when the device is opened. The code you remove
exactly makes (or made before Daniels patch) that sure.

Sascha

--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |

Fabio Estevam

unread,
Aug 30, 2013, 12:10:03 PM8/30/13
to
Hi Sascha,

On Thu, Aug 29, 2013 at 3:37 PM, Sascha Hauer <s.h...@pengutronix.de> wrote:
> It's not about the module refcount. It's only that a on a drm device
> which is in use you better do not add/remove components.
>
> Again: The imx-drm driver does *not* do hotplugging. It will *not* add
> or remove components when the device is opened. The code you remove
> exactly makes (or made before Daniels patch) that sure.

I am not sure what would be the correct fix for this.

What about this?

--- a/drivers/staging/imx-drm/imx-drm-core.c
+++ b/drivers/staging/imx-drm/imx-drm-core.c
@@ -438,6 +438,8 @@ static int imx_drm_driver_load(struct drm_device
*drm, unsigned long flags)
ret = -EINVAL;

ret = 0;
+
+ imxdrm->references = -1;

err_init:
mutex_unlock(&imxdrm->mutex);
@@ -485,7 +487,7 @@ int imx_drm_add_crtc(struct drm_crtc *crtc,

mutex_lock(&imxdrm->mutex);

- if (imxdrm->references) {
+ if (imxdrm->references > 0) {
ret = -EBUSY;
goto err_busy;
}
@@ -564,7 +566,7 @@ int imx_drm_add_encoder(struct drm_encoder *encoder,

mutex_lock(&imxdrm->mutex);

- if (imxdrm->references) {
+ if (imxdrm->references > 0) {
ret = -EBUSY;
goto err_busy;
}
@@ -709,7 +711,7 @@ int imx_drm_add_connector(struct drm_connector *connector,

mutex_lock(&imxdrm->mutex);

- if (imxdrm->references) {
+ if (imxdrm->references > 0) {
ret = -EBUSY;
goto err_busy;
}

Sascha Hauer

unread,
Aug 30, 2013, 1:10:02 PM8/30/13
to
On Fri, Aug 30, 2013 at 01:08:14PM -0300, Fabio Estevam wrote:
> Hi Sascha,
>
> On Thu, Aug 29, 2013 at 3:37 PM, Sascha Hauer <s.h...@pengutronix.de> wrote:
> > It's not about the module refcount. It's only that a on a drm device
> > which is in use you better do not add/remove components.
> >
> > Again: The imx-drm driver does *not* do hotplugging. It will *not* add
> > or remove components when the device is opened. The code you remove
> > exactly makes (or made before Daniels patch) that sure.
>
> I am not sure what would be the correct fix for this.

Why not use (struct drm_device)->open_count as suggested earlier?

Sascha

--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |

Fabio Estevam

unread,
Aug 30, 2013, 2:00:02 PM8/30/13
to
From: Fabio Estevam <fabio....@freescale.com>

Since commit b5dc0d10 (drm/imx: kill firstopen callback) the following probe
failure is seen:

[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] No driver support for vblank timestamp query.
[drm] Initialized imx-drm 1.0.0 20120507 on minor 0
imx-ldb ldb.10: adding encoder failed with -16
imx-ldb: probe of ldb.10 failed with error -16
imx-ipuv3 2400000.ipu: IPUv3H probed
imx-ipuv3 2800000.ipu: IPUv3H probed
imx-ipuv3-crtc imx-ipuv3-crtc.0: adding crtc failed with -16.
imx-ipuv3-crtc: probe of imx-ipuv3-crtc.0 failed with error -16
imx-ipuv3-crtc imx-ipuv3-crtc.1: adding crtc failed with -16.
imx-ipuv3-crtc: probe of imx-ipuv3-crtc.1 failed with error -16
imx-ipuv3-crtc imx-ipuv3-crtc.2: adding crtc failed with -16.
imx-ipuv3-crtc: probe of imx-ipuv3-crtc.2 failed with error -16
imx-ipuv3-crtc imx-ipuv3-crtc.3: adding crtc failed with -16.
imx-ipuv3-crtc: probe of imx-ipuv3-crtc.3 failed with error -16

The reason for the probe failure is that now 'imxdrm->references' is incremented
early in imx_drm_driver_load(), so the following checks in imx_drm_add_crtc()
and imx_drm_add_encoder():

if (imxdrm->references) {
ret = -EBUSY;
goto err_busy;
}

,will always fail.

Instead of manually keeping the references in the imx-drm driver, let's use
drm->open_count.

After this patch, lvds panel is functional on a mx6qsabrelite board.

Signed-off-by: Fabio Estevam <fabio....@freescale.com>
---
This one should go via Dave Airlie's tree instead of Greg's tree because
b5dc0d10 is in Dave's tree.

Changes since v2:
- Use imxdrm->drm->open_count for checking the references
Changes since v1:
- Improved commit log by providing an explanation to the probe failure
- Cc'ed Dave/Daniel

drivers/staging/imx-drm/imx-drm-core.c | 11 +++--------
1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/imx-drm/imx-drm-core.c b/drivers/staging/imx-drm/imx-drm-core.c
index 47c5888..a2e52a0 100644
--- a/drivers/staging/imx-drm/imx-drm-core.c
+++ b/drivers/staging/imx-drm/imx-drm-core.c
@@ -41,7 +41,6 @@ struct imx_drm_device {
struct list_head encoder_list;
struct list_head connector_list;
struct mutex mutex;
- int references;
int pipes;
struct drm_fbdev_cma *fbhelper;
};
@@ -241,8 +240,6 @@ struct drm_device *imx_drm_device_get(void)
}
}

- imxdrm->references++;
-
return imxdrm->drm;

unwind_crtc:
@@ -280,8 +277,6 @@ void imx_drm_device_put(void)
list_for_each_entry(enc, &imxdrm->encoder_list, list)
module_put(enc->owner);

- imxdrm->references--;
-
mutex_unlock(&imxdrm->mutex);
}
EXPORT_SYMBOL_GPL(imx_drm_device_put);
@@ -485,7 +480,7 @@ int imx_drm_add_crtc(struct drm_crtc *crtc,

mutex_lock(&imxdrm->mutex);

- if (imxdrm->references) {
+ if (imxdrm->drm->open_count) {
ret = -EBUSY;
goto err_busy;
}
@@ -564,7 +559,7 @@ int imx_drm_add_encoder(struct drm_encoder *encoder,

mutex_lock(&imxdrm->mutex);

- if (imxdrm->references) {
+ if (imxdrm->drm->open_count) {
ret = -EBUSY;
goto err_busy;
}
@@ -709,7 +704,7 @@ int imx_drm_add_connector(struct drm_connector *connector,

mutex_lock(&imxdrm->mutex);

- if (imxdrm->references) {
+ if (imxdrm->drm->open_count) {
ret = -EBUSY;
goto err_busy;
}
--
1.8.1.2

Sascha Hauer

unread,
Sep 2, 2013, 4:30:01 AM9/2/13
to
Acked-by: Sascha Hauer <s.h...@pengutronix.de>

Sascha


--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
0 new messages