[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5773736D.3060405@lge.com>
Date: Wed, 29 Jun 2016 16:06:21 +0900
From: Jongsung Kim <neidhard.kim@....com>
To: Michael Turquette <mturquette@...libre.com>,
Rob Herring <robh@...nel.org>
Cc: Maxime Ripard <maxime.ripard@...e-electrons.com>,
Stephen Boyd <sboyd@...eaurora.org>, linux-clk@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
Chanho Min <chanho.min@....com>
Subject: Re: [PATCH v2] clk: fixed-factor: add optional dt-binding clock-flags
On 2016년 06월 29일 06:18, Michael Turquette wrote:
> Quoting Rob Herring (2016-06-28 13:55:18)
>> On Fri, Jun 24, 2016 at 01:12:52PM +0900, Jongsung Kim wrote:
>>> There is no way to set additional flags for a DT-initialized fixed-
>>> factor-clock, and it can be problematic i.e., when the clock rate
>>> needs to be changed. [1][2]
>>>
>>> This patch introduces an optional dt-binding named "clock-flags" to
>>> be used for passing any needed flags from dts.
>> I don't think we want this in DT. If we did, the flags would need some
>> documentation about what the flags mean.
> Flags are specific to Linux implementation, so I agree with Rob. Better
> to create a compatible string for your hardware that bakes in the flags.
Thank you for your comment, Mike. This conversation starts from lacking method to set CLK_SET_RATE_PARENT from DT. I understand compatible string can be a solution. But.. if someone starts talking about lacking method to set another flag, i.e., CLK_SET_PARENT_GATE, then we'll need another compatible string list.
How do you think about defining possible required subset of the flags and using some more neutral flag-names acceptable in DT?
Powered by blists - more mailing lists