[PATCH v2 0/2] drm: omap: Fix omapdrm probe and module insertion/removal issues

[Tomi Valkeinen]

On 07/10/13 12:38, Archit Taneja wrote:
> With the new omapdss device model. The user(omapdrm/omapfb) of a 
> omap_dss_device
> has to call connect() to use the device. A connect() call can request to defer
> probe if the device(or the previous entities in the chain) have missing
> resources like a regulator or an I2C bus.
> 
> We make omapdrm defer probe by trying to first connect all panels, and request
> for deferral if any panel requests for a defer. This makes sure that all the
> panels are set up correctly when we finally proceed with omapdrm 
> initialization.
> 
> In order for omapdrm module to be removed successfully, we need to disconnect
> the panels which omapdrm connected. Another thing noticed was that omapdrm
> insertion followed by some usage results in panels getting enabled.
> 
> Trying to remove omapdrm with a panel enabled results in failure while
> disconnecting. This leaves omapdss panels in a bad state. I have added an
> explicit panel disable in the omap_encoder_destroy() op, I needed some
> suggestions on whether there is a better way to do this.
> 
> changes in v2:
> - Add special case when no panels are available to connect.
> - Make sure panels are diabled (and then disconnected) when omapdrm is removed
> 
> Archit Taneja (2):
>   drm: omap: fix: Defer probe if an omapdss device requests for it at
> connect
>   drm: omap: disconnect devices when omapdrm module is removed
> 
>  drivers/gpu/drm/omapdrm/omap_crtc.c|  5 +++
>  drivers/gpu/drm/omapdrm/omap_drv.c | 77 
> --
>  drivers/gpu/drm/omapdrm/omap_drv.h |  1 +
>  drivers/gpu/drm/omapdrm/omap_encoder.c |  3 ++
>  4 files changed, 64 insertions(+), 22 deletions(-)
> 

Acked-by: Tomi Valkeinen 

If it's not too late, it'd be nice to get these two fixes for 3.12.

 Tomi


-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: 

Re: [PATCH v2 0/2] drm: omap: Fix omapdrm probe and module insertion/removal issues

[Archit Taneja]

Hi Rob,

On Monday 07 October 2013 03:08 PM, Archit Taneja wrote:

With the new omapdss device model. The user(omapdrm/omapfb) of a omap_dss_device
has to call connect() to use the device. A connect() call can request to defer
probe if the device(or the previous entities in the chain) have missing
resources like a regulator or an I2C bus.

We make omapdrm defer probe by trying to first connect all panels, and request
for deferral if any panel requests for a defer. This makes sure that all the
panels are set up correctly when we finally proceed with omapdrm initialization.

In order for omapdrm module to be removed successfully, we need to disconnect
the panels which omapdrm connected. Another thing noticed was that omapdrm
insertion followed by some usage results in panels getting enabled.

Trying to remove omapdrm with a panel enabled results in failure while
disconnecting. This leaves omapdss panels in a bad state. I have added an
explicit panel disable in the omap_encoder_destroy() op, I needed some
suggestions on whether there is a better way to do this.

changes in v2:
- Add special case when no panels are available to connect.
- Make sure panels are diabled (and then disconnected) when omapdrm is removed


omapdrm fails when built-in in 3.12, the first patch fixes this. The 
second one fixes issues seen with successive module insertion and removals.


It'll be great if the first one can at least make it to 3.12. Could you 
have a look at it?


Thanks,
Archit

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 0/2] drm: omap: Fix omapdrm probe and module insertion/removal issues

[Archit Taneja]

With the new omapdss device model. The user(omapdrm/omapfb) of a omap_dss_device
has to call connect() to use the device. A connect() call can request to defer
probe if the device(or the previous entities in the chain) have missing
resources like a regulator or an I2C bus.

We make omapdrm defer probe by trying to first connect all panels, and request
for deferral if any panel requests for a defer. This makes sure that all the
panels are set up correctly when we finally proceed with omapdrm initialization.

In order for omapdrm module to be removed successfully, we need to disconnect
the panels which omapdrm connected. Another thing noticed was that omapdrm
insertion followed by some usage results in panels getting enabled.

Trying to remove omapdrm with a panel enabled results in failure while
disconnecting. This leaves omapdss panels in a bad state. I have added an
explicit panel disable in the omap_encoder_destroy() op, I needed some
suggestions on whether there is a better way to do this.

changes in v2:
- Add special case when no panels are available to connect.
- Make sure panels are diabled (and then disconnected) when omapdrm is removed

Archit Taneja (2):
  drm: omap: fix: Defer probe if an omapdss device requests for it at
connect
  drm: omap: disconnect devices when omapdrm module is removed

 drivers/gpu/drm/omapdrm/omap_crtc.c|  5 +++
 drivers/gpu/drm/omapdrm/omap_drv.c | 77 --
 drivers/gpu/drm/omapdrm/omap_drv.h |  1 +
 drivers/gpu/drm/omapdrm/omap_encoder.c |  3 ++
 4 files changed, 64 insertions(+), 22 deletions(-)

-- 
1.8.1.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel