From patchwork Fri Sep 28 12:05:55 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Neil Armstrong X-Patchwork-Id: 10619843 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 51587913 for ; Fri, 28 Sep 2018 12:06:13 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 3509928534 for ; Fri, 28 Sep 2018 12:06:13 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 286A92ABD8; Fri, 28 Sep 2018 12:06:13 +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=-5.2 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED 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 E798428534 for ; Fri, 28 Sep 2018 12:06:11 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 772046E0A6; Fri, 28 Sep 2018 12:06:09 +0000 (UTC) X-Original-To: dri-devel@lists.freedesktop.org Delivered-To: dri-devel@lists.freedesktop.org Received: from mail-wr1-x444.google.com (mail-wr1-x444.google.com [IPv6:2a00:1450:4864:20::444]) by gabe.freedesktop.org (Postfix) with ESMTPS id D55856E0A6 for ; Fri, 28 Sep 2018 12:06:07 +0000 (UTC) Received: by mail-wr1-x444.google.com with SMTP id f10-v6so6149647wrs.0 for ; Fri, 28 Sep 2018 05:06:07 -0700 (PDT) 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:mime-version :content-transfer-encoding; bh=M09g9Sd2hqlApIfGJWkhsXXaXkKFGNEK6j6i38UMQIU=; b=uUKK+Ps2NKoZY8f/nReHxiX420K/ZU0L8/Hc1PQSPN8hQs1a7qNWuYEUVrcF+3g2WT rer8Z9R9nxDM+RH2vxuAzHzo/I4nmVYaHOiabemGwJ5TPG6sZmX0AiRtgxmPgmrNxCfi HPULpormIQYSCCacqF1WmgsAbTcpwYcI6Fh6RZC8frQCotU2T2T+95pJfmlZ0ckyMju6 6a4tQ9FRWMrROibUP5OYfKDgrI33qnAWw55o1easNc4bh7Y+hic1FfazpjSugBWjDrPm 46nsqVtG4JLCUsxWqWkjV0mH5aCyQOzmxgZ+XizuCc0brc8vg/lkTXZTsfd0UlrVYk4B P5NA== X-Gm-Message-State: ABuFfoi8EMP2zaU8vIMlRFc9/0gbvtYqV+8GH+ZyCMW/zmzP0fCzzBtM K/cB4droC+3j4C6hQomCBs9c/OGdH0M= X-Google-Smtp-Source: ACcGV605cvxkAiBfHhw2oQENPF8Vw8L5HU9cOAlGaiW+D5yjdFQ9SifE1tkC0vC2Q3/Syd+LYc6VxQ== X-Received: by 2002:adf:8567:: with SMTP id 94-v6mr12664440wrh.223.1538136365648; Fri, 28 Sep 2018 05:06:05 -0700 (PDT) Received: from bender.home ([2a01:cb1d:4ce:ea00:6c78:1f23:6bb3:14f6]) by smtp.gmail.com with ESMTPSA id t14-v6sm1702381wmi.35.2018.09.28.05.06.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 28 Sep 2018 05:06:04 -0700 (PDT) From: Neil Armstrong To: dri-devel@lists.freedesktop.org Subject: [PATCH v2] drm/fb_helper: Allow leaking fbdev smem_start Date: Fri, 28 Sep 2018 14:05:55 +0200 Message-Id: <1538136355-15383-1-git-send-email-narmstrong@baylibre.com> X-Mailer: git-send-email 2.7.4 MIME-Version: 1.0 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Bartlomiej Zolnierkiewicz , Maxime Ripard , Daniel Vetter , Neil Armstrong , =?utf-8?q?Christian_K=C3=B6nig?= Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" X-Virus-Scanned: ClamAV using ClamSMTP Since "drm/fb: Stop leaking physical address", the default behaviour of the DRM fbdev emulation is to set the smem_base to 0 and pass the new FBINFO_HIDE_SMEM_START flag. The main reason is to avoid leaking physical addresse to user-space, and it follows a general move over the kernel code to avoid user-space to manipulate physical addresses and then use some other mechanisms like dma-buf to transfer physical buffer handles over multiple subsystems. But, a lot of devices depends on closed sources binaries to enable OpenGL hardware acceleration that uses this smem_start value to pass physical addresses to out-of-tree modules in order to render into these physical adresses. These should use dma-buf buffers allocated from the DRM display device instead and stop relying on fbdev overallocation to gather DMA memory (some HW vendors delivers GBM and Wayland capable binaries, but older unsupported devices won't have these new binaries and are doomed until an Open Source solution like Lima finalizes). Since these devices heavily depends on this kind of software and because the smem_start population was available for years, it's a breakage to stop leaking smem_start without any alternative solutions. This patch adds a Kconfig depending on the EXPERT config and an unsafe kernel module parameter tainting the kernel when enabled. A clear comment and Kconfig help text was added to clarify why and when this patch should be reverted, but in the meantime it's a necessary feature to keep. Cc: Dave Airlie Cc: Daniel Vetter Cc: Bartlomiej Zolnierkiewicz Cc: Noralf Trønnes Cc: Maxime Ripard Cc: Eric Anholt Cc: Lucas Stach Cc: Rob Clark Cc: Ben Skeggs Cc: Christian König Signed-off-by: Neil Armstrong Reviewed-by: Maxime Ripard Tested-by: Maxime Ripard Acked-by: Daniel Vetter --- drivers/gpu/drm/Kconfig | 20 ++++++++++++++++++++ drivers/gpu/drm/drm_fb_helper.c | 33 +++++++++++++++++++++++++++++++-- 2 files changed, 51 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 8871b3f..0b4067f 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -110,6 +110,26 @@ config DRM_FBDEV_OVERALLOC is 100. Typical values for double buffering will be 200, triple buffering 300. +config DRM_FBDEV_LEAK_PHYS_SMEM + bool "Shamelessly allow leaking of fbdev physical address (DANGEROUS)" + depends on DRM_FBDEV_EMULATION && EXPERT + default n + help + In order to keep user-space compatibility, we want in certain + use-cases to keep leaking the fbdev physical address to the + user-space program handling the fbdev buffer. + This affects, not only, Amlogic, Allwinner or Rockchip devices + with ARM Mali GPUs using an userspace Blob. + This option is not supported by upstream developers and should be + removed as soon as possible and be considered as a broken and + legacy behaviour from a modern fbdev device driver. + + Please send any bug reports when using this to your proprietary + software vendor that requires this. + + If in doubt, say "N" or spread the word to your closed source + library vendor. + config DRM_LOAD_EDID_FIRMWARE bool "Allow to specify an EDID data set instead of probing for it" depends on DRM diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index bf2190c..61a0d2b 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -56,6 +56,25 @@ MODULE_PARM_DESC(drm_fbdev_overalloc, "Overallocation of the fbdev buffer (%) [default=" __MODULE_STRING(CONFIG_DRM_FBDEV_OVERALLOC) "]"); +/* + * In order to keep user-space compatibility, we want in certain use-cases + * to keep leaking the fbdev physical address to the user-space program + * handling the fbdev buffer. + * This is a bad habit essentially kept into closed source opengl driver + * that should really be moved into open-source upstream projects instead + * of using legacy physical addresses in user space to communicate with + * other out-of-tree kernel modules. + * + * This module_param *should* be removed as soon as possible and be + * considered as a broken and legacy behaviour from a modern fbdev device. + */ +#if IS_ENABLED(CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM) +static bool drm_leak_fbdev_smem = false; +module_param_unsafe(drm_leak_fbdev_smem, bool, 0600); +MODULE_PARM_DESC(fbdev_emulation, + "Allow unsafe leaking fbdev physical smem address [default=false]"); +#endif + static LIST_HEAD(kernel_fb_helper_list); static DEFINE_MUTEX(kernel_fb_helper_lock); @@ -2673,8 +2692,12 @@ __drm_fb_helper_initial_config_and_unlock(struct drm_fb_helper *fb_helper, info = fb_helper->fbdev; info->var.pixclock = 0; - /* don't leak any physical addresses to userspace */ - info->flags |= FBINFO_HIDE_SMEM_START; + /* Shamelessly allow physical address leaking to userspace */ +#if IS_ENABLED(CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM) + if (!drm_leak_fbdev_smem) +#endif + /* don't leak any physical addresses to userspace */ + info->flags |= FBINFO_HIDE_SMEM_START; /* Need to drop locks to avoid recursive deadlock in * register_framebuffer. This is ok because the only thing left to do is @@ -3084,6 +3107,12 @@ int drm_fb_helper_generic_probe(struct drm_fb_helper *fb_helper, fbi->screen_size = fb->height * fb->pitches[0]; fbi->fix.smem_len = fbi->screen_size; fbi->screen_buffer = buffer->vaddr; + /* Shamelessly leak the physical address to user-space */ +#if IS_ENABLED(CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM) + if (drm_leak_fbdev_smem && fbi->fix.smem_start == 0) + fbi->fix.smem_start = + page_to_phys(virt_to_page(fbi->screen_buffer)); +#endif strcpy(fbi->fix.id, "DRM emulated"); drm_fb_helper_fill_fix(fbi, fb->pitches[0], fb->format->depth);