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:52 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 [this message]
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 ` [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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.