From: Imre Deak <imre.deak@intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: intel-gfx <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH] drm/i915: fix dp/sdvo i2c cleanup
Date: Tue, 04 Feb 2014 18:57:51 +0200 [thread overview]
Message-ID: <1391533071.19773.5.camel@intelbox> (raw)
In-Reply-To: <CAKMK7uGhx0Y3CRiZtgqB6JO6OJdU8wAMSBR0ruJQArYkbyq=hQ@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1467 bytes --]
On Tue, 2014-02-04 at 17:13 +0100, Daniel Vetter wrote:
> On Fri, Jan 24, 2014 at 10:15 AM, Imre Deak <imre.deak@intel.com> wrote:
> > Atm we try to remove the connector's i2c sysfs entry too late in the
> > encoder's destroy callback. By that time the kobject used as the parent
> > for all connector sysfs entries is already removed when we do an early
> > removal of all connector sysfs entries in intel_modeset_cleanup(). Fix
> > this by adding an early_destory encoder callback, where we remove the
> > encoder's i2c adapter.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70523
> >
> > Signed-off-by: Imre Deak <imre.deak@intel.com>
>
> Ok, I guess with Greg's clarification this seems to be the correct
> fix. But I'm not too happy about the ->early_destroy since that
> inversion of control is usually a bad sign for wrong layering. Imo
> it'd be better to push all the encoder clean down into each encoders
> ->destroy callback and then move the dp aux cleanup at the right
> place. So essentially we'd need to push the
> intel_panel_destroy_backlight and drm_sysfs_connector_remove calls
> down. That also allows us to only cleanup the backlight on edp/lvds.
>
> Comments or too insane an idea?
Agreed about ->early_destroy being hacky, it was the fast and usual
solution for reordering something in drm :)
I'll check this later / discuss with Jani about reworking this based on
your suggestion.
--Imre
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
prev parent reply other threads:[~2014-02-04 16:58 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-24 9:15 [PATCH] drm/i915: fix dp/sdvo i2c cleanup Imre Deak
2014-01-24 9:29 ` Chris Wilson
2014-01-24 12:47 ` [PATCH v2] " Imre Deak
2014-01-25 20:37 ` Daniel Vetter
2014-01-26 0:51 ` Imre Deak
2014-01-26 9:21 ` Daniel Vetter
2014-01-26 9:21 ` [Intel-gfx] " Daniel Vetter
2014-01-26 11:11 ` Imre Deak
2014-01-26 11:11 ` Imre Deak
2014-01-26 15:40 ` Greg KH
2014-01-26 15:40 ` [Intel-gfx] " Greg KH
2014-02-04 16:13 ` [PATCH] " Daniel Vetter
2014-02-04 16:57 ` Imre Deak [this message]
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=1391533071.19773.5.camel@intelbox \
--to=imre.deak@intel.com \
--cc=daniel@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.org \
/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.