From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.0 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SIGNED_OFF_BY,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9E856C10F13 for ; Thu, 11 Apr 2019 06:38:49 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 6B3062133D for ; Thu, 11 Apr 2019 06:38:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="JnhAZgCG" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6B3062133D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=sntech.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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:References:In-Reply-To: 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: List-Owner; bh=YWIbCUG2moXMP245ooYIehGA8bH0yoD98J0csCTWvVk=; b=JnhAZgCGYwj7AG SljgViBwn3I2VzOzEZoVY07hn74h7Opt+9DDIv1iFLauUonUxs+r6DLPqFliAbPuHUZeTinYxidlr 4FoYIzMkUV0uSiCW3r0RBtd/uXsqGYyknIuZe0PgFm3sNyLwnbk1uh48KFFb2wbxYLzUdNtoyE1sH fac4xI+riBym0kFLItkdDhc7dA0/P4Cdazb31kO0tWrgTqSmovczqUO83ZZrPRLmxegvUjUUYXmrV jP583wCHGXyOlBgNWWWqf7OyJgYYWo0DjI7h7qaG3uc38S+ieg2QGBQIev6uuh7mMvIKOHC7Or44e pBw1CjeWU5/cFGKfxRtg==; 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 1hETM9-0001jz-2x; Thu, 11 Apr 2019 06:38:41 +0000 Received: from gloria.sntech.de ([185.11.138.130]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hETM5-0001j4-73; Thu, 11 Apr 2019 06:38:39 +0000 Received: from ip5f5a6320.dynamic.kabel-deutschland.de ([95.90.99.32] helo=diego.localnet) by gloria.sntech.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hETLp-00061w-2W; Thu, 11 Apr 2019 08:38:21 +0200 From: Heiko =?ISO-8859-1?Q?St=FCbner?= To: Doug Anderson Subject: Re: [PATCH] clk: rockchip: Fix video codec clocks on rk3288 Date: Thu, 11 Apr 2019 08:38:20 +0200 Message-ID: <3815078.yV5O778F5b@diego> In-Reply-To: References: <20190329215455.159717-1-dianders@chromium.org> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190410_233837_409220_E887D464 X-CRM114-Status: GOOD ( 30.94 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Ziyuan Xu , Jonas Karlman , Stephen Boyd , Michael Turquette , Elaine Zhang , LKML , Tomasz Figa , "open list:ARM/Rockchip SoC..." , Matthias Kaehlcke , Ryan Case , Ezequiel Garcia , linux-clk , Linux ARM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Doug, Am Donnerstag, 11. April 2019, 01:37:33 CEST schrieb Doug Anderson: > Hi, > > On Wed, Apr 10, 2019 at 11:38 AM Jonas Karlman wrote: > > > > On 2019-04-10 17:45, Doug Anderson wrote: > > > Hi, > > > > > > On Fri, Mar 29, 2019 at 2:55 PM Douglas Anderson wrote: > > >> 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(-) > > > Any thoughts about this patch? I'm 99.9% certain it's correct and > > > it'd be nice to get it landed. Heiko: I assume you're still > > > collecting Rockchip clock patches and would be the one to apply it and > > > (at some point) send a pull request to the clock tree? > > > > > > -Doug > > > > This clk fix is needed to make MPEG-2 decoding work on my RK3288 Tinker Board using the > > rockchip vpu patchset and a patch to add RK3288 specific MPEG-2 code [1]. > > > > Also note that the same change was suggested in a previous patch [2] from by ayaka. > > > > If possible please also add the CLK_SET_RATE_PARENT change from [3] in a possible v2, > > that fixes assigning the aclk_vcodec clk to 400Mhz in the rockchip vpu driver. > > > > [1] https://github.com/Kwiboo/linux-rockchip/commit/1f78093e05c7360515a185f48b7c5cb8ba1e3e15 > > [2] https://patchwork.kernel.org/patch/9725553/ > > [3] https://github.com/Kwiboo/linux-rockchip/commit/9216da3f1521a0be5889235abe7fa093a4894160 > > Thanks for the pointers! Now I'm 99.9999% certain that my patch is > correct instead of just 99.9%. ;-) > > IMO the CLK_SET_RATE_PARENT should probably be a separate patch but it > does seem like we need it. ...and actually the patch adding it should > have a Fixes tag of the same commit. Prior to that commit the parent > of "aclk_vcodec" was "aclk_vdpu". As a gate clock it would > automatically have CLK_SET_RATE_PARENT so you could easily set the > rate. ...and it looks as if the downstream video codec driver in > Chrome OS relies on this too. > > I'm happy to add that in a v2 if Heiko is happy with it. Sounds very sensible to me to combine these 2 parts. Heiko _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel