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

Archit Taneja archit at ti.com
Mon Oct 7 11:38:11 CEST 2013


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



More information about the dri-devel mailing list