All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rafael Antognolli <rafael.antognolli@intel.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v8 2/2] drm/dp: Set aux.dev to the drm_connector device, instead of drm_device.
Date: Tue, 1 Dec 2015 16:37:43 -0800	[thread overview]
Message-ID: <20151202003743.GA16041@intel.com> (raw)
In-Reply-To: <20151124203141.GL4437@intel.com>

On Tue, Nov 24, 2015 at 10:31:41PM +0200, Ville Syrjälä wrote:
> On Mon, Nov 02, 2015 at 12:33:48PM -0800, Rafael Antognolli wrote:
> > So far, the i915 driver and some other drivers set it to the drm_device,
> > which doesn't allow one to know which DP a given aux channel is related
> > to. Changing this to be the drm_connector provides proper nesting, still
> > allowing one to get the drm_device from it. Some drivers already set it
> > to the drm_connector.
> > 
> > This also removes the need to add a sysfs link for the i2c device under
> > the connector, as it will already be there.
> > 
> > Signed-off-by: Rafael Antognolli <rafael.antognolli@intel.com>
> 
> I gave aux_dev a bit of a testing here, and it appaers to work quite
> splendidly.
> 
> This patch however causes lots of WARN spew if I unload the driver
> while in middle of dumping the DPCD via the aux_dev. It appears we
> we clean up things the wrong order now.

It looks like device_destroy is being called twice on the drm_aux_dev
and i2c adapter devices.

If I understood correctly, this is happening because I changed the
parent device, from the drm_device to the drm_connector, but the
drm_connector is being destroyed before the drm_aux_dev and i2c adapter
devices, which already causes them to be destroyed too.

Changing the drm_dp_aux_unregister() from inside intel_dp_aux_fini() to
intel_dp_connector_unregister(), right before
intel_connector_unregister(), seems to fix everything, and it still
makes sense in my opinion, since the auxdev is going to be unregistered
before we destroy the drm_connector. Do you think that would be ok?

> > ---
> >  drivers/gpu/drm/i915/intel_dp.c | 19 ++-----------------
> >  1 file changed, 2 insertions(+), 17 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> > index 8287df4..7aacc08 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -1078,36 +1078,21 @@ intel_dp_aux_init(struct intel_dp *intel_dp, struct intel_connector *connector)
> >  		intel_dp->aux_ch_ctl_reg = intel_dp->output_reg + 0x10;
> >  
> >  	intel_dp->aux.name = name;
> > -	intel_dp->aux.dev = dev->dev;
> > +	intel_dp->aux.dev = connector->base.kdev;
> >  	intel_dp->aux.transfer = intel_dp_aux_transfer;
> >  
> >  	DRM_DEBUG_KMS("registering %s bus for %s\n", name,
> >  		      connector->base.kdev->kobj.name);
> >  
> >  	ret = drm_dp_aux_register(&intel_dp->aux);
> > -	if (ret < 0) {
> > +	if (ret < 0)
> >  		DRM_ERROR("drm_dp_aux_register() for %s failed (%d)\n",
> >  			  name, ret);
> > -		return;
> > -	}
> > -
> > -	ret = sysfs_create_link(&connector->base.kdev->kobj,
> > -				&intel_dp->aux.ddc.dev.kobj,
> > -				intel_dp->aux.ddc.dev.kobj.name);
> > -	if (ret < 0) {
> > -		DRM_ERROR("sysfs_create_link() for %s failed (%d)\n", name, ret);
> > -		drm_dp_aux_unregister(&intel_dp->aux);
> > -	}
> >  }
> >  
> >  static void
> >  intel_dp_connector_unregister(struct intel_connector *intel_connector)
> >  {
> > -	struct intel_dp *intel_dp = intel_attached_dp(&intel_connector->base);
> > -
> > -	if (!intel_connector->mst_port)
> > -		sysfs_remove_link(&intel_connector->base.kdev->kobj,
> > -				  intel_dp->aux.ddc.dev.kobj.name);
> >  	intel_connector_unregister(intel_connector);
> >  }
> >  
> > -- 
> > 2.4.3
> > 
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Ville Syrjälä
> Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

      reply	other threads:[~2015-12-02  0:37 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-02 20:33 [PATCH v8 0/2] Add drm_dp_aux chardev support Rafael Antognolli
2015-11-02 20:33 ` [PATCH v8 1/2] drm/dp: Add a drm_aux-dev module for reading/writing dpcd registers Rafael Antognolli
2015-11-24 20:28   ` Ville Syrjälä
2015-11-25 13:02   ` [Intel-gfx] " Ville Syrjälä
2015-11-02 20:33 ` [PATCH v8 2/2] drm/dp: Set aux.dev to the drm_connector device, instead of drm_device Rafael Antognolli
2015-11-24 20:31   ` Ville Syrjälä
2015-12-02  0:37     ` Rafael Antognolli [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=20151202003743.GA16041@intel.com \
    --to=rafael.antognolli@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=ville.syrjala@linux.intel.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.