From: Archit Taneja <archit@ti.com>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>, robdclark@gmail.com
Cc: linux-omap@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 2/2] drm: omap: disconnect devices when omapdrm module is removed
Date: Thu, 19 Sep 2013 16:21:37 +0530 [thread overview]
Message-ID: <523AD739.1030801@ti.com> (raw)
In-Reply-To: <523ACD07.5020406@ti.com>
Hi,
On Thursday 19 September 2013 03:38 PM, Tomi Valkeinen wrote:
> On 19/09/13 11:49, Archit Taneja wrote:
>> omapdrm established connections for omap_dss_device devices when probed. It
>> should also be responsible to disconnect the devices. Keeping the devices
>> connected can prevent the panel driver modules from unloading, it can also
>> cause problems when omapdrm is re-inserted.
>>
>> Signed-off-by: Archit Taneja <archit@ti.com>
>> ---
>> drivers/gpu/drm/omapdrm/omap_drv.c | 14 ++++++++++----
>> 1 file changed, 10 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c b/drivers/gpu/drm/omapdrm/omap_drv.c
>> index 45fbb1c..44a1203 100644
>> --- a/drivers/gpu/drm/omapdrm/omap_drv.c
>> +++ b/drivers/gpu/drm/omapdrm/omap_drv.c
>> @@ -86,6 +86,13 @@ static bool channel_used(struct drm_device *dev, enum omap_channel channel)
>>
>> return false;
>> }
>> +static void omap_disconnect_dssdevs(void)
>> +{
>> + struct omap_dss_device *dssdev = NULL;
>> +
>> + for_each_dss_dev(dssdev)
>> + dssdev->driver->disconnect(dssdev);
>> +}
>
> With a quick test, it looks like omapdrm leaves the displays enabled
> when exiting. This can be fixed by adding to the above loop:
>
> if (dssdev->state != OMAP_DSS_DISPLAY_DISABLED)
> dssdev->driver->disable(dssdev);
>
> However... omapdrm still crashes when unloading, and it could be somehow
> related to leaving something un-removed. Disabling a CRTC should disable
> the display, and maybe omapdrm should disable (and clean-up) all CRTCs
> on exit, and maybe that would remove the crash, and also fix the issue
> of leaving displays enabled.
>
> But I'm just guessing there, I have no idea how the process of unloading
> a drm driver goes.
It seems like dev_unload is the place where we should disconnect the
dssdevs.
omap_modeset_free() calls drm_mode_config_cleanup() which calls omapdrm
specific destroy funcs for connectors, encoders and crtcs.
I don't think crtcs should disable the device. I think it's the
encoder(and connector) which is mapped to a display. The omap_encoder's
destroy op should disable the dssdev device.
I'm not sure about this though. Rob, do you have any comment on this?
Archit
next prev parent reply other threads:[~2013-09-19 10:51 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1379502502-8781-1-git-send-email-archit@ti.com>
2013-09-18 11:15 ` [PATCH] drm: omap: fix: Defer probe if an omapdss device requests for it at connect Archit Taneja
[not found] ` <52399F8F.8050104@ti.com>
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 [this message]
2013-10-07 9:38 ` [PATCH v2 0/2] drm: omap: Fix omapdrm probe and module insertion/removal issues Archit Taneja
2013-10-07 9:38 ` [PATCH v2 1/2] drm: omap: fix: Defer probe if an omapdss device requests for it at connect 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=523AD739.1030801@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).