From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [PATCH 19/19] drm/kms: don't export drm_mode_group_init_legacy_group Date: Thu, 23 Jan 2014 11:00:28 +0100 Message-ID: <20140123100028.GQ9772@phenom.ffwll.local> References: <1390467164-951-1-git-send-email-daniel.vetter@ffwll.ch> <1390467164-951-20-git-send-email-daniel.vetter@ffwll.ch> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by gabe.freedesktop.org (Postfix) with ESMTP id 2DDCEF9DF0 for ; Thu, 23 Jan 2014 02:00:33 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id g15so306000eak.17 for ; Thu, 23 Jan 2014 02:00:32 -0800 (PST) Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces@lists.freedesktop.org Errors-To: dri-devel-bounces@lists.freedesktop.org To: David Herrmann Cc: Daniel Vetter , Russell King , DRI Development , Greg Kroah-Hartman List-Id: dri-devel@lists.freedesktop.org On Thu, Jan 23, 2014 at 10:42:02AM +0100, David Herrmann wrote: > Hi > > On Thu, Jan 23, 2014 at 9:52 AM, Daniel Vetter wrote: > > Driver modules really don't have much business frobbing around with > > this: Splitting up modeset resources (if we ever get around to enable > > this for real) should be something purely controlled and managed by > > the drm core in a driver-agnostic fashion. As usual imx disagrees, but > > that's due to the convoluted setup sequence. Russell King is working > > on a proper fix for that, so this patch needs to wait for those to > > land to avoid breaking imx. > > I tried working on "modeset-object splitting" as part of the > DRM-Master rework, but that's all really racy and we'd break current > user-space. For instance the object-indices (compared to object-IDs) > need to be constant, but with our current object-lists, removing an > object will change indices (thus breaking possible_crtcs/encoders). > > There are ways to make that work, but it'd require huge drm_crtc.c > changes. And I also think our locking doesn't provide for that. > Furthermore, resource-retrieval is not atomic (we need multiple > ioctls: GetResources, GetCrtc, ...) so if we change the objects in > between, we may break running apps in a subtle way. > > So I'm all for making object-lists immutable after drm_dev_register() > was called. Imo, hardware should wait for all sub-devices to be > present and then call drm_dev_register(). Once the first sub-device is > removed, you call drm_dev_unregister(). And I think that's what > Russel's compound-device infrastructure does by hiding the sub-devices > in a compound device. > > If there's ever hardware that truly supports sub-device hotplugging, > we can support that by adding a DRM-ClientCap like 3D modes. But as I > understand, the current hardware is still a single piece of hardware > which just might get probed via different buses and thus is not an > atomic entity. So the device is still hotplugged as a whole, we just > don't get the events through a single path. Yeah, if we ever want to allow hotplugging after driver setup that's massive work to do it right. Which is why I want to plug this hole here before someone sneaks in for real ;-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch