Received: by 2002:a05:6a10:17d3:0:0:0:0 with SMTP id hz19csp2104565pxb; Sun, 18 Apr 2021 19:06:47 -0700 (PDT) X-Google-Smtp-Source: ABdhPJznSBD74jIGZ6byNogVhq+hTZkjWpnMgru5WqJvn5IlOluR0jBNRjdJOq3n8Zu9CcwHPlyO X-Received: by 2002:a50:ec97:: with SMTP id e23mr2047183edr.98.1618798007625; Sun, 18 Apr 2021 19:06:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1618798007; cv=none; d=google.com; s=arc-20160816; b=wXOjbPGmhCmLX6vJjDvxWzkQxl8trRELDqlzti62ugod/LKCTkPN4P9dJLjMB4CMuE qYRHZss7M6QGYtAeaVyZqsqjNK2Ik34NF8gE1u8MXgr9FlaodGjI1p8oc9BXzxYDQdFT 2gdDryAFeVCdn2NPJqzr27LLka3tGb0eMAFUplJQTuOO5l4hh7qEsi1P+AB99gBhjFV5 dACh84Tcea0VSltMjhjmki8Akoz5feSHqd0op+NR47rtcg1u1e1LfAC9Vt7j0CJd8Paf bjsMW6AnnTwCR3wj37iboyDSSwsM0v5C0GLPRHqVA5d4DinBV12NPgzB4jh3CZAvufs6 Hwrg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=uirSUe5i5SncM883fWpP6XrPYcwXOGQboyUyg+739s4=; b=wc6JvesHns4ov5hM07J4OT/3iM0sgBi9LHcPtwuaZQ9kVZD1rPYFRamAaEydia+naN Zf+ZaHUtP+JxYA9cOVz1p6ANJmN3YiwvwTracnkiIqGVVZZoUz+hmtccANA79NQQv1jU 8m8ZO2AhE0qQqWiNvTkBVybsBOLhqzFNECkxlGbMnA7XAUPD9nHrhCCuI9XfWZEi4+0r A0JP4ff89Yas9PKbnH6TEfynQO2S51B2DuUKawW1MaGtOzgGS0T9pMRzSu2XM6H7hRfR HNrs8PiaiBAlcM4dWoB8KL2jSILAWYQ0VF2k/+xVqxUmLFX33ZAmnnQ/9mkKw0Vw76xB P12g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=SN8tRN1f; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i23si4070036eds.533.2021.04.18.19.06.25; Sun, 18 Apr 2021 19:06:47 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=SN8tRN1f; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237227AbhDSCEv (ORCPT + 99 others); Sun, 18 Apr 2021 22:04:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52048 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232288AbhDSCEv (ORCPT ); Sun, 18 Apr 2021 22:04:51 -0400 Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1B33AC06174A for ; Sun, 18 Apr 2021 19:04:21 -0700 (PDT) Received: by mail-pj1-x1032.google.com with SMTP id lr7so865978pjb.2 for ; Sun, 18 Apr 2021 19:04:21 -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:mime-version :content-transfer-encoding; bh=uirSUe5i5SncM883fWpP6XrPYcwXOGQboyUyg+739s4=; b=SN8tRN1fbyRPMccAQaweS/FgRo7idRwbKhr31MhNWGAAeE6SjUuOxh1gKwcmQOU5bH mEqntLoyx7ff7jNX0RZVUmD55z6tNMLkscxwZ4xTmQxXufJHrh52JVX0JRDFBVGQQ6KV XEeE7ZfHWFSsmjqCNe9DNPN+K8A2QWc+79cbxEj3mfP31sxA77K6kTxZX02yu8KR5D6e 6iSOqYMrUSyhX116JIi90kno+0mdtmK9k3Z4HB2Df8S/kUF4h6ru9hZfOcq/QWOiX0hL Of5S9SywuaMo0/ZXcDu4ot6/JdI70exzVr1MpjlTuYNn+HXqFmq1yV2o4vuBr3+aKzeo LkAQ== 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=uirSUe5i5SncM883fWpP6XrPYcwXOGQboyUyg+739s4=; b=mKDLafUivVTnnLlXQl2QV+isc43hoo5viUSvB2Dc7pwWyiybN69nyqckkCsN4cKLJk YcBH7IN1T2Y1jIz2ejU32YblgfnU9awU8HDlzkC1lXNTVd/aqxsmsaaHccynXAbI5Edq +5usv5ibHSmDInz9KUJpIoUTPw2yCWoaevxPU0FZx+4Oh8cn9Ab9Kq/sI1IaqoCzCTxX XWWGdEesv/ziX+Jl+AQf9+okzdqrcr1uFlvH5r3laO+lRZJYANU87Wa20iU8Lr3tlpHa 7ruuux0QSne7OaJe9ztoyAlwoqoa4zXO/C1pl8iEOF91sftD72GsH/j1a2sioZmSHaY2 JUZg== X-Gm-Message-State: AOAM531HBpZaw59pqLFDu6vabOR6JJx5vRQlzmbeYdRSDZcoNvqG9Z3Q ohh0Cr5lNF6vjGfCRzMxNrOI0hEcO/3ePXx0 X-Received: by 2002:a17:90a:f309:: with SMTP id ca9mr22337813pjb.200.1618797860475; Sun, 18 Apr 2021 19:04:20 -0700 (PDT) Received: from glados.. ([2601:647:6000:3e5b::a27]) by smtp.gmail.com with ESMTPSA id r3sm8745308pfl.159.2021.04.18.19.04.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 18 Apr 2021 19:04:20 -0700 (PDT) From: Thomas Hebb To: linux-kernel@vger.kernel.org, Nickey Yang , Heiko Stuebner , Andrzej Hajda Cc: Thomas Hebb , Brian Norris , Daniel Vetter , David Airlie , Sandy Huang , Sean Paul , dri-devel@lists.freedesktop.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org Subject: [RESEND PATCH] drm/rockchip: dsi: move all lane config except LCDC mux to bind() Date: Sun, 18 Apr 2021 19:04:10 -0700 Message-Id: <55fe7f3454d8c91dc3837ba5aa741d4a0e67378f.1618797813.git.tommyhebb@gmail.com> X-Mailer: git-send-email 2.30.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org When we first enable the DSI encoder, we currently program some per-chip configuration that we look up in rk3399_chip_data based on the device tree compatible we match. This data configures various parameters of the MIPI lanes, including on RK3399 whether DSI1 is slaved to DSI0 in a dual-mode configuration. It also selects which LCDC (i.e. VOP) to scan out from. This causes a problem in RK3399 dual-mode configurations, though: panel prepare() callbacks run before the encoder gets enabled and expect to be able to write commands to the DSI bus, but the bus isn't fully functional until the lane and master/slave configuration have been programmed. As a result, dual-mode panels (and possibly others too) fail to turn on when the rockchipdrm driver is initially loaded. Because the LCDC mux is the only thing we don't know until enable time (and is the only thing that can ever change), we can actually move most of the initialization to bind() and get it out of the way early. That's what this change does. (Rockchip's 4.4 BSP kernel does it in mode_set(), which also avoids the issue, but bind() seems like the more correct place to me.) Tested on a Google Scarlet board (Acer Chromebook Tab 10), which has a Kingdisplay KD097D04 dual-mode panel. Prior to this change, the panel's backlight would turn on but no image would appear when initially loading rockchipdrm. If I kept rockchipdrm loaded and reloaded the panel driver, it would come on. With this change, the panel successfully turns on during initial rockchipdrm load as expected. Fixes: 2d4f7bdafd70 ("drm/rockchip: dsi: migrate to use dw-mipi-dsi bridge driver") Signed-off-by: Thomas Hebb --- .../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 36 ++++++++++++++----- 1 file changed, 28 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c index 8cc81d5b82f0..520a0a0cd2b5 100644 --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c @@ -691,13 +691,8 @@ static const struct dw_mipi_dsi_phy_ops dw_mipi_dsi_rockchip_phy_ops = { .get_timing = dw_mipi_dsi_phy_get_timing, }; -static void dw_mipi_dsi_rockchip_config(struct dw_mipi_dsi_rockchip *dsi, - int mux) +static void dw_mipi_dsi_rockchip_config(struct dw_mipi_dsi_rockchip *dsi) { - if (dsi->cdata->lcdsel_grf_reg) - regmap_write(dsi->grf_regmap, dsi->cdata->lcdsel_grf_reg, - mux ? dsi->cdata->lcdsel_lit : dsi->cdata->lcdsel_big); - if (dsi->cdata->lanecfg1_grf_reg) regmap_write(dsi->grf_regmap, dsi->cdata->lanecfg1_grf_reg, dsi->cdata->lanecfg1); @@ -711,6 +706,13 @@ static void dw_mipi_dsi_rockchip_config(struct dw_mipi_dsi_rockchip *dsi, dsi->cdata->enable); } +static void dw_mipi_dsi_rockchip_set_lcdsel(struct dw_mipi_dsi_rockchip *dsi, + int mux) +{ + regmap_write(dsi->grf_regmap, dsi->cdata->lcdsel_grf_reg, + mux ? dsi->cdata->lcdsel_lit : dsi->cdata->lcdsel_big); +} + static int dw_mipi_dsi_encoder_atomic_check(struct drm_encoder *encoder, struct drm_crtc_state *crtc_state, @@ -766,9 +768,9 @@ static void dw_mipi_dsi_encoder_enable(struct drm_encoder *encoder) return; } - dw_mipi_dsi_rockchip_config(dsi, mux); + dw_mipi_dsi_rockchip_set_lcdsel(dsi, mux); if (dsi->slave) - dw_mipi_dsi_rockchip_config(dsi->slave, mux); + dw_mipi_dsi_rockchip_set_lcdsel(dsi->slave, mux); clk_disable_unprepare(dsi->grf_clk); } @@ -922,6 +924,24 @@ static int dw_mipi_dsi_rockchip_bind(struct device *dev, return ret; } + /* + * With the GRF clock running, write lane and dual-mode configurations + * that won't change immediately. If we waited until enable() to do + * this, things like panel preparation would not be able to send + * commands over DSI. + */ + ret = clk_prepare_enable(dsi->grf_clk); + if (ret) { + DRM_DEV_ERROR(dsi->dev, "Failed to enable grf_clk: %d\n", ret); + return ret; + } + + dw_mipi_dsi_rockchip_config(dsi); + if (dsi->slave) + dw_mipi_dsi_rockchip_config(dsi->slave); + + clk_disable_unprepare(dsi->grf_clk); + ret = rockchip_dsi_drm_create_encoder(dsi, drm_dev); if (ret) { DRM_DEV_ERROR(dev, "Failed to create drm encoder\n"); -- 2.30.0