From patchwork Wed Mar 22 08:36:10 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Daniel Vetter X-Patchwork-Id: 9638261 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id EBB2D602CB for ; Wed, 22 Mar 2017 08:37:15 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id E04E72029B for ; Wed, 22 Mar 2017 08:37:15 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id D574624603; Wed, 22 Mar 2017 08:37:15 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.1 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_MED,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 6BDEF2029B for ; Wed, 22 Mar 2017 08:37:15 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 4B9AD6E817; Wed, 22 Mar 2017 08:36:38 +0000 (UTC) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::242]) by gabe.freedesktop.org (Postfix) with ESMTPS id D8E1F6E81D for ; Wed, 22 Mar 2017 08:36:34 +0000 (UTC) Received: by mail-wm0-x242.google.com with SMTP id n11so7605567wma.0 for ; Wed, 22 Mar 2017 01:36:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=Jhx6dwh3F+s1Hcpb4pR07NpTMOrBgxhibtZDR9sJo7I=; b=dOdKFOsRvZSJ3wQ/XTOi0zNQIK/9v9XpCvebFdrzF/0om3yi9TopuRWvBPhyuhLiGX yQOYxnR1kPPdIUT0R1srZ+TuPQGrvL3GDuPx+mHajSc4orWIVU7kLUxaQWyySMBeSsgu mvNdhFUD66a/PabeGmB1bxhYvGtxYoYyQ+y/o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=Jhx6dwh3F+s1Hcpb4pR07NpTMOrBgxhibtZDR9sJo7I=; b=eE1zQ9wLpUQj5N7D2KodPWwayPPZo8e6nVWqOIe3Wa728MR8VXIKMIr+A2ms+J6vEN c/GLqOEYfJy6xV1hDOyPyFiz8hs6SnX7630tO7IDzHAP0Eevdja6qKyLHW9wuPYUXvsv cVn0YsccQUX0p5TABSfOOz53aNrHVuGOtdAvhliYZh5WPAVYZAZGlH6rf7zHxPLYxb/j t5yw6ZHSlefnXV3LKAeosXxfeH5xB29Xj0zx0kQQ94RstwRSHNnj+IgRg22rl04LzGmJ pydT5r0tl+WsJlapA2f6ggFljSnTI9YDyKCXLmtep0EYSwkKhsaCQaZqDYczpfHnwIZp gWAQ== X-Gm-Message-State: AFeK/H3JkORbxXnwxzejkJioLnWSo+2az066X1mdjid/FqSSU+lm6WwAxMb1ln6K4cQ50g== X-Received: by 10.28.88.129 with SMTP id m123mr6854169wmb.28.1490171793325; Wed, 22 Mar 2017 01:36:33 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:56c9:0:decc:6e78:7e96:b452]) by smtp.gmail.com with ESMTPSA id g45sm927438wrd.11.2017.03.22.01.36.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Mar 2017 01:36:32 -0700 (PDT) From: Daniel Vetter To: Intel Graphics Development Date: Wed, 22 Mar 2017 09:36:10 +0100 Message-Id: <20170322083617.13361-10-daniel.vetter@ffwll.ch> X-Mailer: git-send-email 2.11.0 In-Reply-To: <20170322083617.13361-1-daniel.vetter@ffwll.ch> References: <20170322083617.13361-1-daniel.vetter@ffwll.ch> MIME-Version: 1.0 Cc: Daniel Vetter , =?UTF-8?q?Noralf=20Tr=C3=B8nnes?= , DRI Development , Daniel Vetter Subject: [Intel-gfx] [PATCH 09/16] drm/todo: Add tinydrm refactoring ideas X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" X-Virus-Scanned: ClamAV using ClamSMTP Discussed with Noralf on the list a bit. An open question is tinydrm vs. drm_panel, but until we have a clear idea what's really needed in that space, I think it's best to just move forward with what we have. Cc: Noralf Trønnes Signed-off-by: Daniel Vetter Acked-by: Noralf Trønnes --- Documentation/gpu/todo.rst | 70 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 70 insertions(+) diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 7dc6de07a3bc..479bb040f6d4 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -99,6 +99,30 @@ events for atomic commits correctly. But fixing these bugs is good anyway. Contact: Daniel Vetter, respective driver maintainers +Better manual-upload support for atomic +--------------------------------------- + +This would be especially useful for tinydrm: + +- Add a struct drm_rect dirty_clip to drm_crtc_state. When duplicating the + crtc state, clear that to the max values, x/y = 0 and w/h = MAX_INT, in + __drm_atomic_helper_crtc_duplicate_state(). + +- Move tinydrm_merge_clips into drm_framebuffer.c, dropping the tinydrm_ + prefix ofc and using drm_fb_. drm_framebuffer.c makes sense since this + is a function useful to implement the fb->dirty function. + +- Create a new drm_fb_dirty function which does essentially what e.g. + mipi_dbi_fb_dirty does. You can use e.g. drm_atomic_helper_update_plane as the + template. But instead of doing a simple full-screen plane update, this new + helper also sets crtc_state->dirty_clip to the right coordinates. And of + course it needs to check whether the fb is actually active (and maybe where), + so there's some book-keeping involved. There's also some good fun involved in + scaling things appropriately. For that case we might simply give up and + declare the entire area covered by the plane as dirty. + +Contact: Noralf Trønnes, Daniel Vetter + Fallout from atomic KMS ----------------------- @@ -313,5 +337,51 @@ Contact: Daniel Vetter Driver Specific =============== +tinydrm +------- + +Tinydrm is the helper driver for really simple fb drivers. The goal is to make +those drivers as simple as possible, so lots of room for refactoring: + +- backlight helpers, probably best to put them into a new drm_backlight.c. + This is because drivers/video is de-facto unmaintained. We could also + move drivers/video/backlight to drivers/gpu/backlight and take it all + over within drm-misc, but that's more work. + +- spi helpers, probably best put into spi core/helper code. Thierry said + the spi maintainer is fast&reactive, so shouldn't be a big issue. + +- extract the mipi-dbi helper (well, the non-tinydrm specific parts at + least) into a separate helper, like we have for mipi-dsi already. Or follow + one of the ideas for having a shared dsi/dbi helper, abstracting away the + transport details more. + +- tinydrm_lastclose could be drm_fb_helper_lastclose. Only thing we need + for that is to store the drm_fb_helper pointer somewhere in + drm_device->mode_config. And then we could roll that out to all the + drivers. + +- tinydrm_gem_cma_prime_import_sg_table should probably go into the cma + helpers, as a _vmapped variant (since not every driver needs the vmap). + And tinydrm_gem_cma_free_object could the be merged into + drm_gem_cma_free_object(). + +- tinydrm_fb_create we could move into drm_simple_pipe, only need to add + the fb_create hook to drm_simple_pipe_funcs, which would again simplify a + bunch of things (since it gives you a one-stop vfunc for simple drivers). + +- Quick aside: The unregister devm stuff is kinda getting the lifetimes of + a drm_device wrong. Doesn't matter, since everyone else gets it wrong + too :-) + +- With the fbdev pointer in dev->mode_config we could also make + suspend/resume helpers entirely generic, at least if we add a + dev->mode_config.suspend_state. We could even provide a generic pm_ops + structure with those. + +- also rework the drm_framebuffer_funcs->dirty hook wire-up, see above. + +Contact: Noralf Trønnes, Daniel Vetter + Outside DRM ===========