linux-samsung-soc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marek Szyprowski <m.szyprowski@samsung.com>
To: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Thierry Reding <thierry.reding@gmail.com>,
	Sam Ravnborg <sam@ravnborg.org>, David Airlie <airlied@linux.ie>,
	Daniel Vetter <daniel@ffwll.ch>, Rob Herring <robh+dt@kernel.org>,
	Kukjin Kim <kgene@kernel.org>,
	Hoegeun Kwon <hoegeun.kwon@samsung.com>,
	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 <b.zolnierkie@samsung.com>,
	Sylwester Nawrocki <snawrocki@kernel.org>
Subject: Re: [RFT 3/4] ARM: dts: exynos: Move CMU assigned ISP clocks to buses in Exynos3250
Date: Mon, 31 Aug 2020 10:29:13 +0200	[thread overview]
Message-ID: <5c12e944-21f1-7e86-b5eb-421c70176b5c@samsung.com> (raw)
In-Reply-To: <20200831081906.GA11513@kozik-lap>

Hi Krzysztof,

On 31.08.2020 10:19, Krzysztof Kozlowski wrote:
> On Mon, Aug 31, 2020 at 10:11:02AM +0200, Marek Szyprowski wrote:
>> 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 <krzk@kernel.org>
>>>
>>> ---
>>>
>>> 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.

Okay, that would be fine. It would make dts match better the hardware 
and this would even help generic clock framework to always instantiate 
CMU after the oscilator fixed-clock (there have been some hacks there at 
some point for that...)

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland


  reply	other threads:[~2020-08-31  8:29 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-29 17:25 [PATCH 1/4] dt-bindings: display: samsung,amoled-mipi-dsi: Do not require enable-gpios on samsung,s6e63j0x03 Krzysztof Kozlowski
2020-08-29 17:25 ` [RFT 2/4] ARM: dts: exynos: Move fixed clocks under root node in Exynos3250 Krzysztof Kozlowski
2020-08-31 11:03   ` Marek Szyprowski
2020-09-01 10:15   ` Krzysztof Kozlowski
2020-08-29 17:25 ` [RFT 3/4] ARM: dts: exynos: Move CMU assigned ISP clocks to buses " Krzysztof Kozlowski
2020-08-31  8:11   ` Marek Szyprowski
2020-08-31  8:19     ` Krzysztof Kozlowski
2020-08-31  8:29       ` Marek Szyprowski [this message]
2020-08-31  8:31       ` Krzysztof Kozlowski
2020-08-29 17:25 ` [PATCH 4/4] ARM: dts: exynos: Remove snps,dwc2 compatible " Krzysztof Kozlowski
2020-09-02 15:35   ` Krzysztof Kozlowski
2020-08-29 21:06 ` [PATCH 1/4] dt-bindings: display: samsung,amoled-mipi-dsi: Do not require enable-gpios on samsung,s6e63j0x03 Sam Ravnborg
2020-09-14 18:16 ` [PATCH 1/4] dt-bindings: display: samsung, amoled-mipi-dsi: Do not require enable-gpios on samsung, s6e63j0x03 Rob Herring

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5c12e944-21f1-7e86-b5eb-421c70176b5c@samsung.com \
    --to=m.szyprowski@samsung.com \
    --cc=airlied@linux.ie \
    --cc=b.zolnierkie@samsung.com \
    --cc=daniel@ffwll.ch \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hoegeun.kwon@samsung.com \
    --cc=kgene@kernel.org \
    --cc=krzk@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=sam@ravnborg.org \
    --cc=snawrocki@kernel.org \
    --cc=thierry.reding@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).