[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <5379E07B.9040507@gmail.com>
Date: Mon, 19 May 2014 12:44:11 +0200
From: Tomasz Figa <tomasz.figa@...il.com>
To: Tushar Behera <tushar.behera@...aro.org>,
Tomasz Figa <t.figa@...sung.com>
CC: Rahul Sharma <rahul.sharma@...sung.com>,
Pankaj Dubey <pankaj.dubey@...sung.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
linux-samsung-soc <linux-samsung-soc@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
Mike Turquette <mturquette@...aro.org>,
Kukjin Kim <kgene.kim@...sung.com>,
Kumar Gala <galak@...eaurora.org>,
Ian Campbell <ijc+devicetree@...lion.org.uk>,
Mark Rutland <mark.rutland@....com>,
Pawel Moll <pawel.moll@....com>,
Rob Herring <robh+dt@...nel.org>,
sunil joshi <joshi@...sung.com>,
Olof Johansson <olof@...om.net>,
Doug Anderson <dianders@...omium.org>
Subject: Re: [PATCH 1/4] clk: samsung: out: Add infrastructure to register
CLKOUT
On 19.05.2014 05:30, Tushar Behera wrote:
> On 15 May 2014 19:37, Tomasz Figa <t.figa@...sung.com> wrote:
>> Hi Rahul, Tushar,
>>
>> On 15.05.2014 15:44, Rahul Sharma wrote:
>>> Hi Tushar,
>>>
>>> Basically you are adding a new clock-type for Clkout. IMO clkout
>>> is not a special hardware. Existing clock types can be reused to
>>> support clkout. I see 3 major problem here:
>>>
>>> 1) Clkout -> (Mux + Gate). You clubbed mux and gate together, and
>>> exposing as a single clock which is something like a composite clock.
>>> IMO this is not a recommended way in CCF.
>>>
>>> 2) New Clock Type: Since clkout is just a combination of a simple
>>> mux and gate which are already supported, it is a unnecessary
>>> duplication.
>>>
>>> 3) Clkout registered along with CMU: which is not correct. Clkout is in PMU
>>> (Separate physical IP) and should be registered as a independent Clock
>>> provider which provides 1 mux and 1 gate clock (As if now). It should also be
>>> well connected with main CMU.
>>>
>>> I understand the challenge in using regmap interface for a clock provider. But
>>> we need to identify a clean solution. IMHO a independent clock provider with
>>> iomap, is relatively cleaner approach till CCF is not ready with regmap based
>>> reg access for clock registers.
>>>
>>> Experts!! please comment.
>>
>> It's quite unfortunate that Tushar has duplicated the effort to create a
>> clkout driver, considering the fact that we did have such driver
>> internally at SRPOL and it was quite nice and simple.
>>
>
> I had no idea that you had some solutions to this available to be posted :(
>
> Now that the new series is posted, I will test that at my end and
> update you later.
Again, sorry for this duplicated effort.
The biggest problem is that we (SRPOL and Linaro) don't have a way to
share our upstream TODO lists and say "hey, we have this working, if you
need it, we can upstream it \o/" or "we need it too, but don't have
resources right now to work on it :(".
Maybe we should set up some wiki or any other semi-public site for this
purpose? I need to talk with other people from my team and my manager to
see what we can do. Other guys (other Samsung teams, Chromium folks,
hobbyists) could also benefit from it.
Anyway, thanks for your understanding and testing.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists