Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp815310pxk; Mon, 31 Aug 2020 01:34:39 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw0SUCHP9bBMjgRSOr8dkWicNcCzxkVwhns7weakye7M5nx1QcaxIM6efsNfiasj7ZDr6fg X-Received: by 2002:a50:8709:: with SMTP id i9mr184402edb.141.1598862878981; Mon, 31 Aug 2020 01:34:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1598862878; cv=none; d=google.com; s=arc-20160816; b=nr9+0kRGKWwZxHAHfbv5lLMWpRFB5dbykvd0BCodosdmd7QwZCLrFwN4pKB/aHIKFI bW+aFeG/zaKm52EITof2zbqnfZYlWEpGYVHg5638smwaZtXZR2TFyMkgpTr0EwRXpHzl AHL2NuLJhag9JufavtfgoPIglTy8NQ9QcGDDvDFdJuPIo23ytY4VXulqdMXxyWVuHuxG QxOwFbJE3tgzn9BnjWXlzl8IToM0KlceDZoc2/jSydHscLcJ8aNDTwJmH/oSimBgB8/e mUTTM/5KnpJSQMBjyg45lkBIMw9qIa8/I0yqonA1IHUiyTjjE5mmyYEZlSTxBmyd42IT kwJQ== 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=I8c8PT+GX2bdj4Es9cku2hg+l1WawbuG/Qnvn+DarqU=; b=xhrF3fU4wxw/vInwTQkex7sK7Pv82+u/SZyxPIh5CDGXPeIIcHry/0GYvd0jOApHlx AXg59UGtch1q8mLpfF16gEdwuTmgcIs1whIbmPJtVPXGgihsuyWe++pHdW82L9MmEee7 DBlesaB56k0rHC7BBNC4V8VACr8HosWVMKSS4kYNfbOxRIVVFSecBgaulZQDlP//3iQl ypFchx6CzN+aZgK1OSP6jQoE7VRpG1ZQkfeMpg5+MAgRZXfWlrdkcIb8E9LxQlOSombe t258daIrREEcSANQosQ4JzkeQWtHPKcKxKE2i6wMZlE74Q2sI4o/bAVypoV6ctEn/ZVP u3Tw== 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 z1si4890704eja.41.2020.08.31.01.34.16; Mon, 31 Aug 2020 01:34:38 -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 S1728406AbgHaIbb (ORCPT + 99 others); Mon, 31 Aug 2020 04:31:31 -0400 Received: from mail-ej1-f67.google.com ([209.85.218.67]:43196 "EHLO mail-ej1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725978AbgHaIb2 (ORCPT ); Mon, 31 Aug 2020 04:31:28 -0400 Received: by mail-ej1-f67.google.com with SMTP id m22so7302843eje.10; Mon, 31 Aug 2020 01:31:26 -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=I8c8PT+GX2bdj4Es9cku2hg+l1WawbuG/Qnvn+DarqU=; b=srYh+chfqEqOFiiup/4HDw5LqErEERrIt+bYeGKL8QkkRmYEmSdVKuKHoypnBikqPZ Oy+sn98nWOTDut33YDk+lJ830xxTnClmr/Td0215HqHAPuOdPHFYs2F1T115STV4fQWe TQwiEyFXYeymYfsXGYsKu9wDT7QlzB7GaIM4JukDfcO/c1CbdkcOi76HsFJGdTPu7bMx FvaYvPpbRC6Xp4/QJbK1mNDzy8AXt7zkXST2CHug66LGrzzniqYz9h1gbTSKZASdnac1 d61r4TJGjfJznlZOc6aA3lhz/UmM5tDXqyBsQI7m3ZMhwaGBc7CE9VCNu32kF/4YBuoY 5gow== X-Gm-Message-State: AOAM530WCZ7nJM/nQshvUXxHPZ+jkqrlO7mz0xvhqk5xgl+wHLFLIPVx sWfNKul0DiRXbzgfRknKBXI= X-Received: by 2002:a17:906:b09a:: with SMTP id x26mr116036ejy.162.1598862685674; Mon, 31 Aug 2020 01:31:25 -0700 (PDT) Received: from kozik-lap ([194.230.155.216]) by smtp.googlemail.com with ESMTPSA id z18sm1172814ejw.94.2020.08.31.01.31.24 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Mon, 31 Aug 2020 01:31:25 -0700 (PDT) Date: Mon, 31 Aug 2020 10:31:22 +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: <20200831083122.GA12874@kozik-lap> References: <20200829172532.29358-1-krzk@kernel.org> <20200829172532.29358-3-krzk@kernel.org> <6ed67a82-0f29-7384-203d-dcb2e58c5a8d@samsung.com> <20200831081906.GA11513@kozik-lap> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200831081906.GA11513@kozik-lap> 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:19:06AM +0200, Krzysztof Kozlowski wrote: > 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). BTW, if you have some time, it would be awesome if you could test all the series (on Exynos3250 obviously with this patch reverted): https://github.com/krzk/linux/tree/for-next/dts-exynos-schema-cleanups The Exynos5 cleanup is ongoing, so there will be more patches. But Exynos3 and Exynos4 I finished. Best regards, Krzysztof