On Tue, Jul 1, 2014 at 2:38 AM, Robert Jarzmik <robert.jarzmik@xxxxxxx> wrote: > Arnd Bergmann <arnd@xxxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
