[Intel-gfx] [PATCH 08/12] drm/i915 + agp/intel-gtt: prep work for direct setup

Daniel Vetter daniel at ffwll.ch
Fri Jun 8 14:39:10 CEST 2012


On Fri, Jun 08, 2012 at 01:09:10PM +0300, Jani Nikula wrote:
> On Thu, 07 Jun 2012, Daniel Vetter <daniel.vetter at ffwll.ch> wrote:
> >  #define INTEL_GTT_GEN	intel_private.driver->gen
> > @@ -1522,14 +1523,32 @@ static int find_gmch(u16 device)
> >  	return 1;
> >  }
> >  
> > -int intel_gmch_probe(struct pci_dev *pdev,
> > -				      struct agp_bridge_data *bridge)
> > +int intel_gmch_probe(struct pci_dev *bridge_pdev, struct pci_dev *gpu_pdev,
> > +		     struct agp_bridge_data *bridge)
> >  {
> >  	int i, mask;
> > -	intel_private.driver = NULL;
> 
> A possibly clueless question: should intel_gmch_remove() do this now,
> since intel_private.driver and intel_private.refcount are linked
> together below?
> 
> > +
> > +	/*
> > +	 * Can be called from the fake agp driver but also directly from
> > +	 * drm/i915.ko. Hence we need to check whether everything is set up
> > +	 * already.
> > +	 */
> > +	if (intel_private.driver) {
> > +		intel_private.refcount++;
> > +		return 1;
> > +	}
> 
> Judging by the commit message, is it intentional that the first call to
> probe does not increase the refcount? The cleanup will now happen only
> if probe and remove are called twice or more. Should this perhaps be
> clarified in a code comment in addition to the commit message?

Yeah, things went a bit wrong here. I'll also see whether I can make the
cleanup path a bit more robust. Thanks for taking a look at this patch.
-Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48



More information about the Intel-gfx mailing list