On Sat, Jun 15, 2013 at 12:15 AM, Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> wrote: > On Fri, Jun 14, 2013 at 09:50:22PM +0200, Daniel Vetter wrote: >> On Fri, Jun 14, 2013 at 4:42 PM, Russell King - ARM Linux >> <linux@xxxxxxxxxxxxxxxx> wrote: >> > If you're happy with the patch I supplied, that's probably the minimal fix >> > which should go to stable kernels (I'm using 3.9 here) - this also counts >> > as a "user visible bug". It's something I've tripped over which causes >> > exhausts memory and can prevent the X server from starting up. >> > >> > If you want me to package the patch up with a commit message and sign-off.. >> >> Your patch doesn't fix drm/i915 (since we don't use the crtc helpers >> any more). And I don't think it's good to have the refcounting >> partially in the drm core and partially in drivers. > > Let me check what you mean by that. I hope you mean that the drm core, > drm helpers and drivers are individually responsible for dropping any > refcount that they obtain on any object. > > In other words, if the drm core takes a refcount on object X, then the > DRM core must be the code base which drops that refcount. Yeah, that's the idea. But since with the currently quirky drm core ->set_config callback the drivers need to drop the reference if any other crtc loses all its connectors. My patch also drops the ref for that fb in the drm core functions. The reason for that is that we want to switch to a global ->set_config function anyway (usually called atomic modeset) to push the configuration for all the crtcs into the hw in one step (or fail it completely ofc). The current approach leads to too much flickering and some funny hacks in drivers ... Of course such gradual transitions over mutliple kernel release (we're shuffling backend code in drm/i915 since about 3.7 for this) leaves a few ugly intermediat states. But I prefer to move into the overall right direction with a bit of ugliness than doing such big transitions in one big swoop. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
