From patchwork Fri Mar 30 14:11:10 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Stone X-Patchwork-Id: 893344 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=linux-tegra-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=collabora.com Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=fooishbar-org.20150623.gappssmtp.com header.i=@fooishbar-org.20150623.gappssmtp.com header.b="CDA1YD+J"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 40CNnv2npKz9s1r for ; Sat, 31 Mar 2018 01:11:15 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750794AbeC3OLN (ORCPT ); Fri, 30 Mar 2018 10:11:13 -0400 Received: from mail-lf0-f47.google.com ([209.85.215.47]:37465 "EHLO mail-lf0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751216AbeC3OLM (ORCPT ); Fri, 30 Mar 2018 10:11:12 -0400 Received: by mail-lf0-f47.google.com with SMTP id m200-v6so6971384lfm.4 for ; Fri, 30 Mar 2018 07:11:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fooishbar-org.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:from:date:message-id:subject:to:cc; bh=TXOcxFCPLQSquZGOzsFtSKqKCWkZ23zT4uS3RChEhZU=; b=CDA1YD+JeV2+HnxiQn1ubQF0oov8Zk37jGaUxLG1wKHBQ+e0x1QKg5b9lS65r4SXsg 8Lv9bNzQa0JqTFYyh01YzKlwyRqdrZbYjKkjwAtj4pzY6O9cffLQdm+3TEJJBBU4g3iG J7CvNligjyh6CzwhJ0p+XsnO3Utaga9EPQzMC6dpzyr8RskZPct7ioeMJQwJ6Qc/PPYz 8iHyfIH35UD/aLwjzLko42V93mJIgvanC1mv45yhzYzifiuoK82+jPCG/DZDnylbafnD bzpHri/l54KzuqPQB67RLiWA7mcCl1KPNTC1+8GAmXC6j6L1tS6sFR3VdsDoHko93X8P BUBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:cc; bh=TXOcxFCPLQSquZGOzsFtSKqKCWkZ23zT4uS3RChEhZU=; b=B5zkVZNCaWO6PB4i+PWNH50tG60b/gTIc4y/ycKfZK+og4uIN4OkW/dogEPRVGyWJB AadDQpPQ0p0KU6Y42cqKbhSu0a68VxeEucLt3YeszFIrtrHvzo7GnOCt6sNb9XJ1o4EP JIWdKemiED2N1PtCpSOPlEzg0CBqdLvhngXnmVww9SnAxKp57BgtqTIL988yXJf1htIa nTxaU8scbPzW2Lm3Tju249cfP4TlfpgojAGJhVqwrhTZKMZrWp9Sarud/zEuTYaLj2Bm 9QGzuI+TgUb2/rCUC5Hl27xTDq1SKkvtoeJSZuMk0hG/qfNmpFfi6JdeDcdQLaoASSY5 Zdag== X-Gm-Message-State: AElRT7FiITUlruwa9CFpBKGdtP6zg2QGIMj/cKQWplDf/4D1X8aF4A1g bek5lG71+gMHr5pGmCR8fNwqKwhY1TNhX0iis/0FLA== X-Google-Smtp-Source: AIpwx49GgbroJtq/Rzhx0nXTHkZN1/U4x1tD9NeDEroSqNEWXlXP4jyV5OZLDdT0nhTgTt2WCdNlJ28WRdGbfSTzr9E= X-Received: by 10.46.117.2 with SMTP id q2mr8636800ljc.12.1522419071108; Fri, 30 Mar 2018 07:11:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.82.210 with HTTP; Fri, 30 Mar 2018 07:11:10 -0700 (PDT) From: Daniel Stone Date: Fri, 30 Mar 2018 15:11:10 +0100 X-Google-Sender-Auth: EI2dzG4y_RGhRCyw6wRXwW52HQ4 Message-ID: Subject: [PATCH 00/24] drm_framebuffer boilerplate removal To: dri-devel Cc: David Lechner , =?utf-8?q?Noralf_Tr=C3=B8nnes?= , Patrik Jakobsson , Russell King , Inki Dae , Joonyoung Shim , Seung-Woo Kim , Kyungmin Park , Thierry Reding , linux-tegra@vger.kernel.org, CK Hu , Philipp Zabel , Tomi Valkeinen , Dave Airlie , Gerd Hoffmann , "open list:VIRTIO CORE, NET..." , Sandy Huang , =?utf-8?q?Heiko_St=C3=BCbner?= , Rob Clark , linux-arm-msm , Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , intel-gfx , Alex Deucher , =?utf-8?q?Christian_K=C3=B6nig?= , "David (ChunMing) Zhou" , amd-gfx mailing list Sender: linux-tegra-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-tegra@vger.kernel.org Hi, I've been working on a getfb2[0] ioctl, which amongst other things supports multi-planar framebuffers as well as modifiers. getfb currently calls the framebuffer's handle_create hook, which doesn't support multiple planes. Thanks to Noralf's recent work, drivers can just store GEM objects directly in drm_framebuffer. I use this directly in getfb2: we need direct access to the GEM objects and not a vfunc in order to not hand out duplicate GEM names for the same object. This series converts all drivers except for nouveau, which was a little too non-trivial for my comfort, to storing GEM objects directly in drm_framebuffer. For those drivers whose driver_framebuffer struct was nothing but drm_framebuffer + BO, it deletes the driver-specific struct. It also makes use of Noralf's generic framebuffer helpers for create_handle and destroy where possible. I don't have the hardware for most of these drivers, so have had to settle for just staring really hard at the diff. I intend to remove create_handle when all drivers are converted over to placing BOs directly inside drm_framebuffer. For most drivers there's a relatively easy conversion to using the helpers for basically all framebuffer handling and fbdev emulation as well, though that's a bit further than I was willing to go without hardware to test on ... Cheers, Daniel [0]: https://lists.freedesktop.org/archives/dri-devel/2018-March/170512.html Acked-by: Alex Deucher --- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html