From patchwork Fri Mar 29 21:54:55 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Doug Anderson X-Patchwork-Id: 10877743 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 1349615AC for ; Fri, 29 Mar 2019 21:55:51 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id EDE2928AA2 for ; Fri, 29 Mar 2019 21:55:50 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id E205328E5E; Fri, 29 Mar 2019 21:55:50 +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,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED autolearn=unavailable version=3.3.1 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 8DFC328A69 for ; Fri, 29 Mar 2019 21:55:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-Id:Date:Subject:To :From:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Owner; bh=9EfoIw1fkzZslcwSuTsvhF68JSX28fDuWgcXtpUkfK0=; b=oIW8bzKqArIhXw n+6a1ZZaE1Zl75hPEZ6hYi7ZF4moSDpFCCLNbOY+mwsRTbcnKoEjFP0/6UIp23BVC9Wd1JfMK4JOn ScsaYs+eeB4vuI/7ajzC27OU77FBpdgfVXTDWcUWDS6OiXBk+GZ0kdixMKJ/eq+46qJDoulC/mT89 nUQfvKmSHcadh12Q+K7Gv8rmfs6/fwqoXU9lvjwCTn2OtdHS1H3dBSEk3VhCr+/8rcWyNBmzts6Kg PenvbE6CUtOB8a0VDDZM1L3Rwy4kiF4HQnw/wHXiv2PBRCWVcTZ2l64zJTvYomNMW+nfsEn34nngX uVUeujFSVnKrlyleLR5Q==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1h9zTV-0001fS-Ly; Fri, 29 Mar 2019 21:55:45 +0000 Received: from mail-pl1-x643.google.com ([2607:f8b0:4864:20::643]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1h9zTM-0001XW-JK for linux-rockchip@lists.infradead.org; Fri, 29 Mar 2019 21:55:38 +0000 Received: by mail-pl1-x643.google.com with SMTP id bf11so1612149plb.12 for ; Fri, 29 Mar 2019 14:55:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=ecc389FYQ0L59bBTC8JbGTFUcbTIY5rYmXWozIAY7B4=; b=hnisAFtR/2zxLT/Jp/D+xocLkDC5DbBCrBqQd1WlPOllJVYBmrOsvIlBy2t0MkoFst /AdTOTF4vVNZVzBuIHXNgFku7pSkultEU3AM5taXmGWgPSCbRNEnRu8me7EUPTBQVbCs AGBgehOsiQKtwGT+s7caWz7dhIyLweX7iSqfU= 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=ecc389FYQ0L59bBTC8JbGTFUcbTIY5rYmXWozIAY7B4=; b=UNZy0L5RtstrtCTTcop2ZNZVosRDEOcV6hSq2rI0N2eI+Z6dGlPOtQCSW4IapFxywK A3xQQIQYyaM/j1JOQ/UZR3K4y1TqFT4oAinNYNJrxN+Nd9w8zMQ1omTefKD3B7RnDD3c kdM+qXKnHQmNec3LWXf+qwC6nZBMzCikffNSBfC327KVOSzrAOD3rWHJO06pReXhtck1 rnG+eJYgH6TILELcwm7QDVnS76ZMDk/eFK9cHs5z11saFwjRUzf9XnWPhc/msC+CnBmn 3NE1afJCSsCYNi/dZUyrQJDvyhaV+oXdXvz+qSg01ey/4hGScbRzpZW47hOtWZ11MfWr DYZA== X-Gm-Message-State: APjAAAXL0SnZYidAHrAzeu8RRC17W2C5RBG5dbdM9Yp2Q2gtXjtPOJXI T+LrBcy8CM7lcqjbx5oO4JY0+Q== X-Google-Smtp-Source: APXvYqzS56Wdd5AWjHRFithraHo+bIHKtALoqOiZvTC3cbnpcBptYR/yiu6zV7xXACzJgcbuF9StdQ== X-Received: by 2002:a17:902:b618:: with SMTP id b24mr48434370pls.73.1553896534506; Fri, 29 Mar 2019 14:55:34 -0700 (PDT) Received: from tictac2.mtv.corp.google.com ([2620:15c:202:1:24fa:e766:52c9:e3b2]) by smtp.gmail.com with ESMTPSA id 20sm4301146pfn.131.2019.03.29.14.55.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Mar 2019 14:55:33 -0700 (PDT) From: Douglas Anderson To: Heiko Stuebner Subject: [PATCH] clk: rockchip: Fix video codec clocks on rk3288 Date: Fri, 29 Mar 2019 14:54:55 -0700 Message-Id: <20190329215455.159717-1-dianders@chromium.org> X-Mailer: git-send-email 2.21.0.392.gf8f6787159e-goog MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190329_145536_657317_A9EC0DB1 X-CRM114-Status: GOOD ( 15.33 ) X-BeenThere: linux-rockchip@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Upstream kernel work for Rockchip platforms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Elaine Zhang , Stephen Boyd , linux-kernel@vger.kernel.org, Michael Turquette , Ziyuan Xu , Douglas Anderson , Tomasz Figa , linux-rockchip@lists.infradead.org, mka@chromium.org, ryandcase@chromium.org, Ezequiel Garcia , linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org Sender: "Linux-rockchip" Errors-To: linux-rockchip-bounces+patchwork-linux-rockchip=patchwork.kernel.org@lists.infradead.org X-Virus-Scanned: ClamAV using ClamSMTP It appears that there is a typo in the rk3288 TRM. For GRF_SOC_CON0[7] it says that 0 means "vepu" and 1 means "vdpu". It's the other way around. How do I know? Here's my evidence: 1. Prior to commit 4d3e84f99628 ("clk: rockchip: describe aclk_vcodec using the new muxgrf type on rk3288") we always pretended that we were using "aclk_vdpu" and the comment in the code said that this matched the default setting in the system. In fact the default setting is 0 according to the TRM and according to reading memory at bootup. In addition rk3288-based Chromebooks ran like this and the video codecs worked. 2. With the existing clock code if you boot up and try to enable the new VIDEO_ROCKCHIP_VPU as a module (and without "clk_ignore_unused" on the command line), you get errors like "failed to get ack on domain 'pd_video', val=0x80208". After flipping vepu/vdpu things init OK. 3. If I export and add both the vepu and vdpu to the list of clocks for RK3288_PD_VIDEO I can get past the power domain errors, but now I freeze when the vpu_mmu gets initted. 4. If I just mark the "vdpu" as IGNORE_UNUSED then everything boots up and probes OK showing that somehow the "vdpu" was important to keep enabled. This is because we were actually using it as a parent. 5. After this change I can hack "aclk_vcodec_pre" to parent from "aclk_vepu" using assigned-clocks and the video codec still probes OK. Fixes: 4d3e84f99628 ("clk: rockchip: describe aclk_vcodec using the new muxgrf type on rk3288") Signed-off-by: Douglas Anderson --- I currently have no way to test the JPEG mem2mem driver, so hopefully others can test this and make sure it's happy for them. I'm just happy not to get strange errors at boot anymore. drivers/clk/rockchip/clk-rk3288.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/clk/rockchip/clk-rk3288.c b/drivers/clk/rockchip/clk-rk3288.c index 5a67b7869960..4d767f9c3a80 100644 --- a/drivers/clk/rockchip/clk-rk3288.c +++ b/drivers/clk/rockchip/clk-rk3288.c @@ -219,7 +219,7 @@ PNAME(mux_hsadcout_p) = { "hsadc_src", "ext_hsadc" }; PNAME(mux_edp_24m_p) = { "ext_edp_24m", "xin24m" }; PNAME(mux_tspout_p) = { "cpll", "gpll", "npll", "xin27m" }; -PNAME(mux_aclk_vcodec_pre_p) = { "aclk_vepu", "aclk_vdpu" }; +PNAME(mux_aclk_vcodec_pre_p) = { "aclk_vdpu", "aclk_vepu" }; PNAME(mux_usbphy480m_p) = { "sclk_otgphy1_480m", "sclk_otgphy2_480m", "sclk_otgphy0_480m" }; PNAME(mux_hsicphy480m_p) = { "cpll", "gpll", "usbphy480m_src" };