From: Archit Taneja <archit@ti.com>
To: robdclark@gmail.com, tomi.valkeinen@ti.com
Cc: dri-devel@lists.freedesktop.org, linux-omap@vger.kernel.org,
Archit Taneja <archit@ti.com>
Subject: [PATCH v2 0/2] drm: omap: Fix omapdrm probe and module insertion/removal issues
Date: Mon, 7 Oct 2013 15:08:11 +0530 [thread overview]
Message-ID: <1381138693-23404-1-git-send-email-archit@ti.com> (raw)
In-Reply-To: <1379502502-8781-1-git-send-email-archit@ti.com>
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
next prev parent reply other threads:[~2013-10-07 9:39 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-18 11:08 [PATCH] drm: omap: fix: Defer probe if an omapdss device requests for it at connect Archit Taneja
2013-09-18 11:15 ` Archit Taneja
2013-09-18 12:41 ` Tomi Valkeinen
2013-09-18 13:17 ` Archit Taneja
2013-09-18 13:26 ` Tomi Valkeinen
2013-09-19 8:49 ` [PATCH 1/2] " Archit Taneja
2013-09-19 8:49 ` [PATCH 2/2] drm: omap: disconnect devices when omapdrm module is removed Archit Taneja
2013-09-19 10:08 ` Tomi Valkeinen
2013-09-19 10:51 ` Archit Taneja
2013-09-20 8:09 ` [PATCH] drm: omap: fix: Defer probe if an omapdss device requests for it at connect Tomi Valkeinen
2013-09-20 8:49 ` Archit Taneja
2013-09-20 8:55 ` Tomi Valkeinen
2013-09-20 10:18 ` Archit Taneja
2013-09-20 10:22 ` Tomi Valkeinen
2013-10-07 9:38 ` Archit Taneja [this message]
2013-10-07 9:38 ` [PATCH v2 1/2] " Archit Taneja
2013-10-07 9:38 ` [PATCH v2 2/2] drm: omap: disconnect devices when omapdrm module is removed Archit Taneja
2013-10-09 13:56 ` [PATCH v2 0/2] drm: omap: Fix omapdrm probe and module insertion/removal issues Archit Taneja
2013-10-21 9:38 ` Tomi Valkeinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1381138693-23404-1-git-send-email-archit@ti.com \
--to=archit@ti.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-omap@vger.kernel.org \
--cc=robdclark@gmail.com \
--cc=tomi.valkeinen@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).