On Fri, Jun 08, 2012 at 06:03:57PM +0200, Jakob Bornecrantz wrote:
> On Fri, Jun 8, 2012 at 4:52 PM, Daniel Vetter
> wrote:
> > Otherwise we'll nicely leak this reference counter. Now thanks to the
> > awesome layering in the drm core, the enable call is done by the pci
> > boilerplate in drm_pci
On Fri, Jun 8, 2012 at 4:52 PM, Daniel Vetter wrote:
> Otherwise we'll nicely leak this reference counter. Now thanks to the
> awesome layering in the drm core, the enable call is done by the pci
> boilerplate in drm_pci.c. But the disable can't be done without adding
> yet another neat indirectio
Otherwise we'll nicely leak this reference counter. Now thanks to the
awesome layering in the drm core, the enable call is done by the pci
boilerplate in drm_pci.c. But the disable can't be done without adding
yet another neat indirection layer just for that.
So take the simple way and sprinkle pc
On Fri, Jun 08, 2012 at 06:03:57PM +0200, Jakob Bornecrantz wrote:
> On Fri, Jun 8, 2012 at 4:52 PM, Daniel Vetter wrote:
> > Otherwise we'll nicely leak this reference counter. Now thanks to the
> > awesome layering in the drm core, the enable call is done by the pci
> > boilerplate in drm_pci.c.
On Fri, Jun 8, 2012 at 4:52 PM, Daniel Vetter wrote:
> Otherwise we'll nicely leak this reference counter. Now thanks to the
> awesome layering in the drm core, the enable call is done by the pci
> boilerplate in drm_pci.c. But the disable can't be done without adding
> yet another neat indirectio
Otherwise we'll nicely leak this reference counter. Now thanks to the
awesome layering in the drm core, the enable call is done by the pci
boilerplate in drm_pci.c. But the disable can't be done without adding
yet another neat indirection layer just for that.
So take the simple way and sprinkle pc