From patchwork Tue Jul 11 18:20:07 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Rob Clark X-Patchwork-Id: 9835379 X-Patchwork-Delegate: sboyd@codeaurora.org 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 6E84E602A0 for ; Tue, 11 Jul 2017 18:20:31 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 6204828553 for ; Tue, 11 Jul 2017 18:20:31 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 5650428587; Tue, 11 Jul 2017 18:20:31 +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=-6.3 required=2.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, RCVD_IN_SORBS_SPAM, T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 60D1328567 for ; Tue, 11 Jul 2017 18:20:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756286AbdGKSU2 (ORCPT ); Tue, 11 Jul 2017 14:20:28 -0400 Received: from mail-qk0-f193.google.com ([209.85.220.193]:32820 "EHLO mail-qk0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756107AbdGKSU1 (ORCPT ); Tue, 11 Jul 2017 14:20:27 -0400 Received: by mail-qk0-f193.google.com with SMTP id p21so33381qke.0; Tue, 11 Jul 2017 11:20:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=MysXCzCFnsx60Lt+Z+gboTL0SV55K1RbYAtf2XHUn20=; b=bxTN84dmeOk8rE/LMppLmUEsvhcEh3BilCEtetDe7s8vGARZdJiz7lpoF8Frnynld/ 3wJ6xqon5ggFj+XVNB9K/5QIXtvX5pUJIg9Ld+CNJnIMtJAxCqmAUSjqsG5TEBo1uF62 Ng80v07x+ZAG3YXAOX3BeGwP9zXHS7w91ocDnksqaAeScjdYalc0Deoebc5EdEukXzR+ avoFbg78hXaVO7qlpy7Tf7RFJN3o1tmA73VdjTaGEUO5Vw7cDJvEWLsXtTPu8YyqsR/0 9hB0CMmluOG5GWI+baxITi4+crWEgbcMunOngiEjPGZNTSvm0C+VAD9lZFidOlkEHgbi MK3A== 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; bh=MysXCzCFnsx60Lt+Z+gboTL0SV55K1RbYAtf2XHUn20=; b=Z9Vdpirbh1yugi6YUc6NRQEMl1z/fzeXPmUlKXQscXFgdoWfP+TdeGREzypkkf7lrF ekHnWgmg6Xy5/OyMQzFBYAG/eNWHHp/pDGvh7pO+ykvErZse6jcrdyoJ4X68CcjKWIuw N2y6I1rQZOcsQyw+T8v5geZHbDdncTmsDGLynDp4YypfiD7TYkXaRoqEku3aW+2Zm9jO FhWwZR4XKZ+D+H8Ahyxxqyj0et4zhEZgfWTgQ6O3tsR5RvtcysB41QolH61YJAXXwQSh UZYsKRNrfGXR8Vgfs886imtEI9eythostJhPk+d7IX6QqU7Sur5qNKXzCRJQK7by3O1Q nlWA== X-Gm-Message-State: AIVw1132uLJcnnkA1nZuFxXNbuk/y2/Q8U4k3umJYCdWc229vs/gXgVo xMpm9RKpPMlpSQ== X-Received: by 10.55.176.133 with SMTP id z127mr1588858qke.233.1499797225443; Tue, 11 Jul 2017 11:20:25 -0700 (PDT) Received: from localhost ([2601:184:4780:aac0:25f8:dd96:a084:785a]) by smtp.gmail.com with ESMTPSA id n69sm454396qke.68.2017.07.11.11.20.24 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 11 Jul 2017 11:20:24 -0700 (PDT) From: Rob Clark To: dri-devel@lists.freedesktop.org, linux-clk@vger.kernel.org Cc: Stephen Boyd , Michael Turquette , Archit Taneja , linux-arm-msm@vger.kernel.org, viresh.kumar@linaro.org, Rob Clark Subject: [RFC 2/3] drm/msm: inherit display from bootloader Date: Tue, 11 Jul 2017 14:20:07 -0400 Message-Id: <20170711182008.28298-3-robdclark@gmail.com> X-Mailer: git-send-email 2.13.0 In-Reply-To: <20170711182008.28298-1-robdclark@gmail.com> References: <20170711182008.28298-1-robdclark@gmail.com> Sender: linux-clk-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-clk@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP It is quite common for bootloader to enable display on tablets/phones. But until now for upstream kernel we've been ignoring that since it highly confuses drm/msm, and recommending to disable the bootloader display. (Otherwise we end up trying to set rates on already enabled clks and all sorts of similar fun.) But to get grub graphical boot menu to work (and also efifb for early boot), we need to solve this properly. This could possibly be split out better. But the basic idea is to (a) determine what is enabled at probe time by looking at what clocks are enabled (ie. if display is enabled at all, mdp5's core clock will be on. If DSI output is enabled (at least in video mode) the dsi block's pixel clock will be enabled, etc. (b) For the enabled outputs, work backwards up the display pipe from output to plane (input). We need to work in this direction as we cannot (for example) read back crtc state until we know which layer-mixer is used or read plane state until we know which hw pipe is used. (But for mdp5 which drm_plane or drm_crtc is picked does not matter since they are virtualized, ie. we assign dynamically hwpipes and lm's to planes and crtcs.) So far this is only implemented for DSI video mode. For DSI command- mode I think we end up needing to get the mode from the drm_panel. (On db410c, which I'm testing this on, it is DSI video mode to an adv7533 bridge.) HDMI/eDP are unimplemented so far. We have to make some simplifications/assumptions in a few places, about how the bootloader is setting things up (ie. that there is just a single plane, and about the pixel format). I'm not sure that working backwards from hw state is completely possible in all cases without making some assumptions. (For example, the hw is flexible enough to deal with imaginary color formats like BARG5865.. and I think for 4k scanout ganging up multiple hwpipes and layermixers you end up with multiple possible sw states mapping to single hw state.) Maybe there is some room for a more generic optional framework for this (which can also be used for extra debug to validate atomic commits via hw-readback after commit), but probably best to start with some more simple display block for that. --- drivers/gpu/drm/msm/dsi/dsi.h | 1 + drivers/gpu/drm/msm/dsi/dsi_host.c | 32 ++++++ drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 5 +- drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 1 + drivers/gpu/drm/msm/dsi/pll/dsi_pll_14nm.c | 2 + drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm.c | 2 + drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm_8960.c | 2 + drivers/gpu/drm/msm/mdp/mdp5/mdp5_cmd_encoder.c | 8 ++ drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c | 21 ++++ drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c | 48 +++++++++ drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.h | 3 + drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c | 132 ++++++++++++++++++++++-- drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 79 +++++++++++++- drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h | 11 ++ drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 79 ++++++++++++++ drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.c | 45 ++++++++ drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.h | 2 + drivers/gpu/drm/msm/msm_drv.c | 3 + drivers/gpu/drm/msm/msm_drv.h | 2 + drivers/gpu/drm/msm/msm_fbdev.c | 15 ++- drivers/gpu/drm/msm/msm_kms.h | 2 + 21 files changed, 478 insertions(+), 17 deletions(-) diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h index 9e6017387efb..4340edaec8e2 100644 --- a/drivers/gpu/drm/msm/dsi/dsi.h +++ b/drivers/gpu/drm/msm/dsi/dsi.h @@ -99,6 +99,7 @@ bool msm_dsi_manager_cmd_xfer_trigger(int id, u32 dma_base, u32 len); void msm_dsi_manager_attach_dsi_device(int id, u32 device_flags); int msm_dsi_manager_register(struct msm_dsi *msm_dsi); void msm_dsi_manager_unregister(struct msm_dsi *msm_dsi); +void msm_dsi_hw_readback(struct msm_dsi *msm_dsi); /* msm dsi */ static inline bool msm_dsi_device_connected(struct msm_dsi *msm_dsi) diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c b/drivers/gpu/drm/msm/dsi/dsi_host.c index 9e9c5696bc03..71a1d3dd7eb5 100644 --- a/drivers/gpu/drm/msm/dsi/dsi_host.c +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c @@ -28,11 +28,14 @@ #include #include