| Message ID | 540F1409.3070206@antcom.de |
|---|---|
| State | New |
| Headers | show |
On Tuesday 09 September 2014 16:51:53 Roland Stigge wrote: > The following changes since commit 2ce7598c9a453e0acd0e07be7be3f5eb39608ebd: > > Linux 3.17-rc4 (2014-09-07 16:09:43 -0700) > > are available in the git repository at: > > git://git.antcom.de/linux-2.6 lpc32xx/dt > > for you to fetch changes up to de1fcd7f8a6d313c92c2af476b012305d4fe6553: > > ARM: LPC32xx: Use DMA for both SSP channels (2014-09-09 15:05:31 +0200) > Hi Roland, I'm glad to see some pull requests from you again, you've been absent for a while. I have no objection to the patches, but I notice that you have just rebased them all today on the latest -rc. In general, we prefer the branches to be based on an older -rc, preferably -rc1, unless you have a dependency on a bug fix that went into a later one. Can you rebase them to -rc1 and send a new version? On a separate topic, are you still actively working with lpc32xx based machines? You cleaned up the platform a lot when you took over in 2012, but now we have move other platforms much further and I wonder if you could do some of the same changes. Most importantly, I really want most platforms to be part of ARCH_MULTIPLATFORM and build them into the same image. For lpc32xx, this is currently not possible because you are not using the common clk implementation. Would it be possible for you to look into converting that driver over and moving it to drivers/clk? There are a few other things that could be done if you are motivated, but that is the only one that I need and can't do myself. Arnd
Hi Arnd, On 09/09/2014 05:43 PM, Arnd Bergmann wrote: > I have no objection to the patches, but I notice that you have just > rebased them all today on the latest -rc. > In general, we prefer the branches to be based on an older -rc, > preferably -rc1, unless you have a dependency on a bug fix that > went into a later one. > Can you rebase them to -rc1 and send a new version? OK, sending. > On a separate topic, are you still actively working with lpc32xx > based machines? I was so busy working with it that I didn't have the time to upstream the few kernel changes to mainline... :-) Will continue this in the future also. > You cleaned up the platform a lot when you took > over in 2012, but now we have move other platforms much further > and I wonder if you could do some of the same changes. > Most importantly, I really want most platforms to be part of > ARCH_MULTIPLATFORM and build them into the same image. For > lpc32xx, this is currently not possible because you are not using > the common clk implementation. Would it be possible for you > to look into converting that driver over and moving it to > drivers/clk? It's certainly possible, but time might be scarce. What would be a good reference platform to have a look into as example? Or a hint/link? Thanks in advance, Roland
On Wednesday 10 September 2014 15:51:33 Roland Stigge wrote: > > > You cleaned up the platform a lot when you took > > over in 2012, but now we have move other platforms much further > > and I wonder if you could do some of the same changes. > > Most importantly, I really want most platforms to be part of > > ARCH_MULTIPLATFORM and build them into the same image. For > > lpc32xx, this is currently not possible because you are not using > > the common clk implementation. Would it be possible for you > > to look into converting that driver over and moving it to > > drivers/clk? > > It's certainly possible, but time might be scarce. What would be a good > reference platform to have a look into as example? Or a hint/link? I'll let Linus answer that one, he converted a couple of platform and probably has a better idea than I do. Arnd
On Wed, Sep 10, 2014 at 4:26 PM, Arnd Bergmann <arnd@arndb.de> wrote: > On Wednesday 10 September 2014 15:51:33 Roland Stigge wrote: >> >> > For >> > lpc32xx, this is currently not possible because you are not using >> > the common clk implementation. Would it be possible for you >> > to look into converting that driver over and moving it to >> > drivers/clk? >> >> It's certainly possible, but time might be scarce. What would be a good >> reference platform to have a look into as example? Or a hint/link? > > I'll let Linus answer that one, he converted a couple of platform and > probably has a better idea than I do. Step-wise conversion on U300: commit 50667d63085af108f625c83102430c1d74931d78 "ARM: u300: convert to common clock" converts to common clock *without* using device tree. commit 14c2607144c11653b27a423ead0703ffaa65d0b1 "clk: move the U300 fixed and fixed-factor to DT" commit bba5f2cc2f0fe4191ad2699c7c03a6def31f54e2 "ARM: u300: move the gated system controller clocks to DT" commit 85fb28bed813469ba56706a7e48fba596f47c253 "ARM: u300: convert MMC/SD clock to device tree" Then gradually moves those clocks over to being handled from the device tree. For an example on a platform lacking clock implementation, look at: commit ef6eb322ce574ba73658a677e83e5da3cfab301b "clk: nomadik: implement the Nomadik clocks properly" where I implement the Nomadik per-bit enabled clocks This includes device tree bindings. commit c641d4dfef6d462c6d66a6fb57700086cd2f0106 "ARM: nomadik: add the new clocks to the device tree" adds them to the device tree and make use of them. Yours, Linus Walleij
The following changes since commit 2ce7598c9a453e0acd0e07be7be3f5eb39608ebd: Linux 3.17-rc4 (2014-09-07 16:09:43 -0700) are available in the git repository at: git://git.antcom.de/linux-2.6 lpc32xx/dt for you to fetch changes up to de1fcd7f8a6d313c92c2af476b012305d4fe6553: ARM: LPC32xx: Use DMA for both SSP channels (2014-09-09 15:05:31 +0200) ---------------------------------------------------------------- Roland Stigge (1): ARM: LPC32xx: Use DMA for both SSP channels arch/arm/boot/dts/lpc32xx.dtsi | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-)