Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp809872pxk; Mon, 31 Aug 2020 01:20:29 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy5ZbNkC5aYZV8COhtcKw26fEkAL8K5Hn74EU0TpVRKI7Cmu9HcG/ZpMaETIqXoOVfjsluy X-Received: by 2002:a05:6402:114d:: with SMTP id g13mr133650edw.157.1598862029624; Mon, 31 Aug 2020 01:20:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1598862029; cv=none; d=google.com; s=arc-20160816; b=ddtthaAxCciqxKu6IocGsMJzNvtsqMEC223fKTH20URiqM4AggAsyxn4yiA7Sk9zh0 D/+v9i06eVVlOQkKm0LvwymV2bBjGdJOwvPfcc2n9bmeRhsJuQmyYj/RCix1Lzsh00tj Ijva67RXcxWtiaIptVWvOzUszUNry9W8uUxXdZFe0+7FZzL4+HtnYNtr+eAgo23JN/6h zpBaf36B2iPPDoNCW5Nk2UVcA+YU+YK86AtXlW5XGafTqsaLeAaigtCvibkFv05QkTQ2 DtDJiLStixgpXwgp8JqgQitGbAzNyIcwdBN5OeZBSIeOMI0Bw0EEEjMWdO+StCABbrSw np0Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=Cqrk1bBlfTS3BPtOTE3s4vilkxanbVUMadQ6BMq95XQ=; b=kuMVJveBUt7MwV4dxMIjrVaE+b8mzGge+WOmwij3HrUipI4pX0zWn9Vzt1jyRurXFK p0UidE9PlW5hklmgbV8UuZY3sAIMgmO7FuWzEQKRQunawizqO5GM4ukykTr5yQdt/iW0 A+5+uGEW3d1T9SPAOLk8LHiZEfrN7NJQlQRgOvKoSZ/ZZ3gR5mlk5MR4NUdKiL7MEZtG KOMzpdfi8WCYy+/q0yLZ6z6pWlGRQ4mzZ+PnRAsHywd4NlsstY6TDv6OXLUUg3/e/f4s ofCxS5+jUErn/I6kh8tESRfQ9FS4Au+QbgYg5sMzFu0YC0S4Jc851MdNEMaMxqBKU8Bg KkgQ== ARC-Authentication-Results: i=1; mx.google.com; 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=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id o17si5216066ejg.156.2020.08.31.01.20.06; Mon, 31 Aug 2020 01:20:29 -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; 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=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727806AbgHaITO (ORCPT + 99 others); Mon, 31 Aug 2020 04:19:14 -0400 Received: from mail-ej1-f67.google.com ([209.85.218.67]:36354 "EHLO mail-ej1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725829AbgHaITM (ORCPT ); Mon, 31 Aug 2020 04:19:12 -0400 Received: by mail-ej1-f67.google.com with SMTP id e23so1809440eja.3; Mon, 31 Aug 2020 01:19:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=Cqrk1bBlfTS3BPtOTE3s4vilkxanbVUMadQ6BMq95XQ=; b=bzfjvLzlIiONuVg+R5UoCfdMYf9OiP7YcOcxvQlm3fcekQW3fKxUOqM8RCDlYU0Wd+ yh6KoMlP2nrC+ls91gJpErP/8WfOhsgb9s3OQmdSc7QifcsTnQXrb9CPQFtIFRA46ZEW oGKA+1iUzobLAXea03dxDusmAOB8fVGapMy5sHWFSqRBjfgJh5ioFgCslrFroJqRnp7l scWh1eno+dHW8jF6A0vY2y36aVKEuyDl14XVSBViwOixX1RqStCBixg9+1xipYSwa37x P4yawGK3GPN/sNk36tQvs11odOrXq43QartPuxhB5WnIo2A6dGSdTinRwcSEukvGAtQm v7Gg== X-Gm-Message-State: AOAM532R7UcVkPYHmjUW7qGhLbSTkROi6pqLazmLR9xntFmzBJptwGGH jBUvNflbpzbEzdsFL+vgU+I= X-Received: by 2002:a17:906:180b:: with SMTP id v11mr47877eje.427.1598861949932; Mon, 31 Aug 2020 01:19:09 -0700 (PDT) Received: from kozik-lap ([194.230.155.216]) by smtp.googlemail.com with ESMTPSA id d2sm7482261ejm.19.2020.08.31.01.19.08 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Mon, 31 Aug 2020 01:19:09 -0700 (PDT) Date: Mon, 31 Aug 2020 10:19:06 +0200 From: Krzysztof Kozlowski To: Marek Szyprowski Cc: Thierry Reding , Sam Ravnborg , David Airlie , Daniel Vetter , Rob Herring , Kukjin Kim , Hoegeun Kwon , dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org, Bartlomiej Zolnierkiewicz , Sylwester Nawrocki Subject: Re: [RFT 3/4] ARM: dts: exynos: Move CMU assigned ISP clocks to buses in Exynos3250 Message-ID: <20200831081906.GA11513@kozik-lap> References: <20200829172532.29358-1-krzk@kernel.org> <20200829172532.29358-3-krzk@kernel.org> <6ed67a82-0f29-7384-203d-dcb2e58c5a8d@samsung.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <6ed67a82-0f29-7384-203d-dcb2e58c5a8d@samsung.com> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 31, 2020 at 10:11:02AM +0200, Marek Szyprowski wrote: > Hi Krzysztof, > > On 29.08.2020 19:25, Krzysztof Kozlowski wrote: > > Commit 52005dece527 ("ARM: dts: Add assigned clock parents to CMU node > > for exynos3250") added assigned clocks under Clock Management Unit to > > fix hangs when accessing ISP registers. > > > > This is not the place for it as CMU does not have a required "clocks" > > property: > > > > arch/arm/boot/dts/exynos3250-artik5-eval.dt.yaml: clock-controller@10030000: 'clocks' is a dependency of 'assigned-clocks' > > > > Signed-off-by: Krzysztof Kozlowski > > > > --- > > > > Not tested and I wonder whether actually correct. For example, what will > > happen if devfreq (exynos-bus) is not built in? > > > > Could someone verify it? > > Sorry, but this patch is not correct. Those clocks has noting with > bus-freq. The assigned clocks property should stay where it is. Maybe > one need to fix the schemas for dts verification. Those clocks has to be > set (and so generic clock framework does) according to the assigned > clocks properties once the clock controller is instantiated. > > The only alternative would be to add exynos-subcmu variant to properly > link CMU with the ISP power domain, but assuming that there is no Exynos > 3250 ISP driver in mainline (and probably never will be), it is safe to > keep those clocks sourced from 24MHz crystal. Thanks for the clarification. Another solution to silence the warning could be to add a "clocks" property for FIN_PLL, although the driver actually does not take it. This is the only remaining dtschema check warning on Exynos3250 so it would be nice to at least silence it. My goal is to have all them schema-correct, or as close as possible (for Exynos4 the camera node is a trouble). Best regards, Krzysztof