Re: [PATCH 0/4] Migrate PXA27x platforms to clock framework

[Haojian Zhuang <haojian.zhuang-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

On Tue, Jul 1, 2014 at 2:38 AM, Robert Jarzmik <robert.jarzmik-GANU6spQydw@public.gmane.org> wrote:
> Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> writes:
>
>> On Sunday 29 June 2014 20:32:20 Robert Jarzmik wrote:
>>> As the RFC posted in [1] didn't meet an unrivaled success for
>>> review, I'm posting this serie for PXA27x transition to clock
>>> framework.
>>>
>>> This transition is needed :
>>>  - to enable device-tree drivers port, as clocks are needed almost
>>>    everywhere
>>>  - to enable the long term multi-platform kernel to support PXA
>>>
>>> As I had said before, this serie aims at :
>>>  - keeping legacy platforms working (ie. without device-tree)
>>>  - enable PXA27x to work with a device-tree kernel, and hence
>>>    open the way to drivers conversion
>>>  - be robust enough to support pxa25x and pxa3xx later inclusion
>>>    with almost no change to clk-pxa-dt.c.
>>>
>>> As this serie is holding the rest of the device-tree drivers
>>> port, I'd like it to be reviewed, even it's an old unsexy
>>> platform.
>>
>> I have one basic question about this series: if pxa27x gets moved
>> to used the common-clk framework but the others (pxa25x, pxa26x,
>> pxa3xx, pxa93x) don't, does that imply that they become mutually
>> exclusiv at compile-time?
>
> Unfortunately yes, they become exclusive.
> The reason being that arch/arm/mach-pxa/clock.c defines the function
> "clk_enable()", which of course is also defined by the clock framework.
>
>> If so, do you plan to first complete all of them before merging
>> upstream, or do you intend to have one or more kernel releases
>> that don't allow building a combined kernel for all pxa platforms?
> I intend to have first only pxa27x.
> Then in a second stage pxa27x + pxa25x + pxa3xx.
>
>> I don't object to doing the latter, but if that is the plan, you
>> need to make that very clear in the changelog and have all the
>> relevant maintainers agree to that.
> OK, that would be Haojian then, I think he maintains all PXA platforms.
>
> Haojian, are you ok with that ? And BTW, does a combined kernel for PXA
> platforms even exists (mixing pxa3xx and pxa2xx for example) ?
>

It's acceptable to me that different silicons are queued in different stages.
I only request that it won't break the compiler building & bootup.

But I think that the pxa clock driver may be shared among all PXA silicons
except for the clock table. What's your opinion?

>> Also (for my understanding) when you say that you plan to do
>> pxa25x and pxa3xx next, does that include pxa26x and pxa93x?
> I don't have the Technical Reference Manuals for these ones so the answer is
> no. And Google wasn't a great friend at providing them.
>

Converting them into new clock driver may not rely on the reference manual.

>> I assume it does as they are apparently minor revisions of the
>> former, but it's not completely clear from your description.
> My description doesn't mention them, as I have no information about them, nor
> any hardware to test on.
>

We can request others to help testing in the mailing list.

Regards
Haojian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html