From: robert.jarzmik@free.fr (Robert Jarzmik)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/4] Migrate PXA27x platforms to clock framework
Date: Mon, 30 Jun 2014 20:38:49 +0200 [thread overview]
Message-ID: <877g3yp7ie.fsf@free.fr> (raw)
In-Reply-To: <7034630.fvV46PN35C@wuerfel> (Arnd Bergmann's message of "Mon, 30 Jun 2014 08:55:15 +0200")
Arnd Bergmann <arnd@arndb.de> 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) ?
> 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.
> 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.
Cheers.
--
Robert
WARNING: multiple messages have this Message-ID (diff)
From: Robert Jarzmik <robert.jarzmik-GANU6spQydw@public.gmane.org>
To: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Mike Turquette
<mturquette-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
Haojian Zhuang
<haojian.zhuang-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Eric Miao <eric.y.miao-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
Subject: Re: [PATCH 0/4] Migrate PXA27x platforms to clock framework
Date: Mon, 30 Jun 2014 20:38:49 +0200 [thread overview]
Message-ID: <877g3yp7ie.fsf@free.fr> (raw)
In-Reply-To: <7034630.fvV46PN35C@wuerfel> (Arnd Bergmann's message of "Mon, 30 Jun 2014 08:55:15 +0200")
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) ?
> 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.
> 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.
Cheers.
--
Robert
--
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
next prev parent reply other threads:[~2014-06-30 18:38 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-29 18:32 [PATCH 0/4] Migrate PXA27x platforms to clock framework Robert Jarzmik
2014-06-29 18:32 ` Robert Jarzmik
2014-06-29 18:32 ` [PATCH 1/4] clk: add pxa27x clock drivers Robert Jarzmik
2014-06-29 18:32 ` Robert Jarzmik
2014-07-03 6:12 ` Haojian Zhuang
2014-07-03 6:12 ` Haojian Zhuang
2014-07-03 22:28 ` Robert Jarzmik
2014-07-03 22:28 ` Robert Jarzmik
2014-06-29 18:32 ` [PATCH 2/4] dts: add devicetree bindings for pxa27x clocks Robert Jarzmik
2014-06-29 18:32 ` Robert Jarzmik
2014-07-03 6:14 ` Haojian Zhuang
2014-07-03 6:14 ` Haojian Zhuang
2014-07-03 22:03 ` Mike Turquette
2014-07-03 22:03 ` Mike Turquette
2014-07-04 19:38 ` Robert Jarzmik
2014-07-04 19:38 ` Robert Jarzmik
2014-06-29 18:32 ` [PATCH 3/4] arm: pxa: Transition pxa27x to clk framework Robert Jarzmik
2014-06-29 18:32 ` Robert Jarzmik
2014-06-29 18:32 ` [PATCH 4/4] clk: dts: document pxa27x clock binding Robert Jarzmik
2014-06-29 18:32 ` Robert Jarzmik
2014-06-30 6:55 ` [PATCH 0/4] Migrate PXA27x platforms to clock framework Arnd Bergmann
2014-06-30 6:55 ` Arnd Bergmann
2014-06-30 18:38 ` Robert Jarzmik [this message]
2014-06-30 18:38 ` Robert Jarzmik
2014-06-30 20:14 ` Arnd Bergmann
2014-06-30 20:14 ` Arnd Bergmann
2014-07-03 6:21 ` Haojian Zhuang
2014-07-03 6:21 ` Haojian Zhuang
2014-07-03 22:14 ` Robert Jarzmik
2014-07-03 22:14 ` Robert Jarzmik
2014-07-04 2:39 ` Haojian Zhuang
2014-07-04 2:39 ` Haojian Zhuang
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=877g3yp7ie.fsf@free.fr \
--to=robert.jarzmik@free.fr \
--cc=linux-arm-kernel@lists.infradead.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.