| Message ID | 20130322005815.GG1689@verge.net.au |
|---|---|
| State | New |
| Headers | show |
On Friday 22 March 2013, Simon Horman wrote: > Sorry about sending so many all at once. There were quite a few changes > queued up and it might have been better if I flushed some of them out > a bit earlier. > > Of the batch that I sent last week, I think you are missing the following one: > Right, I've pulled it into next/drivers now. Thanks for checking this. Arnd
On Fri, Mar 22, 2013 at 12:40:53PM +0000, Arnd Bergmann wrote: > On Friday 22 March 2013, Simon Horman wrote: > > Sorry about sending so many all at once. There were quite a few changes > > queued up and it might have been better if I flushed some of them out > > a bit earlier. > > > > Of the batch that I sent last week, I think you are missing the following one: > > > > Right, I've pulled it into next/drivers now. Thanks for checking this. Thanks. I now have no outstanding pull requests. I do have a few new patches in my tree. I plan to let a few more accumulate before sending the next pull request(s).
On Friday 22 March 2013, Simon Horman wrote: > On Fri, Mar 22, 2013 at 12:40:53PM +0000, Arnd Bergmann wrote: > > On Friday 22 March 2013, Simon Horman wrote: > > > Sorry about sending so many all at once. There were quite a few changes > > > queued up and it might have been better if I flushed some of them out > > > a bit earlier. > > > > > > Of the batch that I sent last week, I think you are missing the following one: > > > > > > > Right, I've pulled it into next/drivers now. Thanks for checking this. > > Thanks. I now have no outstanding pull requests. > > I do have a few new patches in my tree. > I plan to let a few more accumulate before sending the next pull request(s). Ok, sounds good. One general question about your plans (probably more for Magnus than for you): What is your expected time line for moving shmobile under CONFIG_ARCH_MULTIPLATFORM? It seems you are making great progress, but there is also still a lot to be done. I expect that in 3.10, we will have all ARMv6 and ARMv7 platforms converted, with the exception of realview, mmp, s5p, msm, and shmobile. I'm sure we can do realview and mmp for 3.11, possibly also s5p. For shmobile, I think most of the work would be changing drivers/sh/clk to integrate into the common clk framework, and you need to find a way to enable ARM_PATCH_PHYS_VIRT and AUTO_ZRELADDR. Are those things you think can be done for 3.11? Arnd
On Fri, Mar 22, 2013 at 03:39:39PM +0000, Arnd Bergmann wrote: > On Friday 22 March 2013, Simon Horman wrote: > > On Fri, Mar 22, 2013 at 12:40:53PM +0000, Arnd Bergmann wrote: > > > On Friday 22 March 2013, Simon Horman wrote: > > > > Sorry about sending so many all at once. There were quite a few changes > > > > queued up and it might have been better if I flushed some of them out > > > > a bit earlier. > > > > > > > > Of the batch that I sent last week, I think you are missing the following one: > > > > > > > > > > Right, I've pulled it into next/drivers now. Thanks for checking this. > > > > Thanks. I now have no outstanding pull requests. > > > > I do have a few new patches in my tree. > > I plan to let a few more accumulate before sending the next pull request(s). > > Ok, sounds good. > > One general question about your plans (probably more for Magnus than for you): Indeed, it is more for Magnus than I. > What is your expected time line for moving shmobile under > CONFIG_ARCH_MULTIPLATFORM? It seems you are making great progress, but > there is also still a lot to be done. > > I expect that in 3.10, we will have all ARMv6 and ARMv7 platforms converted, > with the exception of realview, mmp, s5p, msm, and shmobile. I'm sure we > can do realview and mmp for 3.11, possibly also s5p. For shmobile, I think > most of the work would be changing drivers/sh/clk to integrate into the common > clk framework, and you need to find a way to enable ARM_PATCH_PHYS_VIRT and > AUTO_ZRELADDR. Are those things you think can be done for 3.11?
Hi Arnd, Thanks for your email. On Sat, Mar 23, 2013 at 12:39 AM, Arnd Bergmann <arnd@arndb.de> wrote: > On Friday 22 March 2013, Simon Horman wrote: >> On Fri, Mar 22, 2013 at 12:40:53PM +0000, Arnd Bergmann wrote: >> > On Friday 22 March 2013, Simon Horman wrote: >> > > Sorry about sending so many all at once. There were quite a few changes >> > > queued up and it might have been better if I flushed some of them out >> > > a bit earlier. >> > > >> > > Of the batch that I sent last week, I think you are missing the following one: >> > > >> > >> > Right, I've pulled it into next/drivers now. Thanks for checking this. >> >> Thanks. I now have no outstanding pull requests. >> >> I do have a few new patches in my tree. >> I plan to let a few more accumulate before sending the next pull request(s). > > Ok, sounds good. > > One general question about your plans (probably more for Magnus than for you): > What is your expected time line for moving shmobile under > CONFIG_ARCH_MULTIPLATFORM? It seems you are making great progress, but > there is also still a lot to be done. Indeed, there is still a lot to be done! > I expect that in 3.10, we will have all ARMv6 and ARMv7 platforms converted, > with the exception of realview, mmp, s5p, msm, and shmobile. I'm sure we > can do realview and mmp for 3.11, possibly also s5p. For shmobile, I think > most of the work would be changing drivers/sh/clk to integrate into the common > clk framework, and you need to find a way to enable ARM_PATCH_PHYS_VIRT and > AUTO_ZRELADDR. Are those things you think can be done for 3.11? Good to hear that most ARM platforms will be converted by v3.10. This is definitely something that I want to make happen for mach-shmobile as well. Our biggest challenge now is the move to common clocks. I suspect that moving all our boards and SoCs to common clocks will take much longer than v3.11 I'm afraid. Starting with something smaller like EMEV2 may be a good first step. So somehow I'd like to start converting them one by one, perhaps also moving over the converted SoCs/boards to CONFIG_ARCH_MULTIPLATFORM in an incremental fashion. Do you happen to have any example subarch that has been migrated in an increment fashion already? Regarding ARM_PATCH_PHYS_VIRT and AUTO_ZRELADDR, I believe those should be enabled for the mach-shmobile bits that are used with CONFIG_ARCH_MULTIPLATFORM. Best way forward there is TBD, any recommendations would be very welcome! Thanks, / magnus
On Wednesday 27 March 2013, Magnus Damm wrote: > On Sat, Mar 23, 2013 at 12:39 AM, Arnd Bergmann <arnd@arndb.de> wrote: > > On Friday 22 March 2013, Simon Horman wrote: > > I expect that in 3.10, we will have all ARMv6 and ARMv7 platforms converted, > > with the exception of realview, mmp, s5p, msm, and shmobile. I'm sure we > > can do realview and mmp for 3.11, possibly also s5p. For shmobile, I think > > most of the work would be changing drivers/sh/clk to integrate into the common > > clk framework, and you need to find a way to enable ARM_PATCH_PHYS_VIRT and > > AUTO_ZRELADDR. Are those things you think can be done for 3.11? > > Good to hear that most ARM platforms will be converted by v3.10. This > is definitely something that I want to make happen for mach-shmobile > as well. > > Our biggest challenge now is the move to common clocks. I suspect that > moving all our boards and SoCs to common clocks will take much longer > than v3.11 I'm afraid. Ok, I see. If you think it's not likely to be ready for 3.12, we might need to discuss again whether there is another way of making the common clk and the sh-clk code coexist. For instance, we could rename all if the sh/shmobile specific clk functions and their users from clk_* to shclk_*, and provide a thin wrapper around them that integrates into common clk. > Starting with something smaller like EMEV2 may be a good first step. > So somehow I'd like to start converting them one by one, perhaps also > moving over the converted SoCs/boards to CONFIG_ARCH_MULTIPLATFORM in > an incremental fashion. Do you happen to have any example subarch that > has been migrated in an increment fashion already? We have had a few that were able to do both multiplatform and single-platform for some time, but then changed to multiplatform-only. I think mvebu and vt8500 are in this category. > Regarding ARM_PATCH_PHYS_VIRT and AUTO_ZRELADDR, I believe those > should be enabled for the mach-shmobile bits that are used with > CONFIG_ARCH_MULTIPLATFORM. Best way forward there is TBD, any > recommendations would be very welcome! Yes, makes sense. What I think you should do is rename CONFIG_ARCH_SHMOBILE to CONFIG_ARCH_SHMOBILE_SINGLE, and add a new symbol in arch/arm/mach-shmobile/Kconfig like config ARCH_SHMOBILE bool "Renesas SH-Mobile / R-Mobile" if ARCH_MULTI_V6_V7 default CONFIG_ARCH_SHMOBILE_SINGLE help Support for Renesas's SH-Mobile and R-Mobile ARM platforms. This way, the platform is a non-exclusive option for the multiplatform case, and a hidden enabled option when building CONFIG_ARCH_SHMOBILE_SINGLE. Every machine that is not ready for multiplatform can then add "depends on CONFIG_ARCH_SHMOBILE_SINGLE". Arnd
On Wed, Mar 27, 2013 at 8:37 PM, Arnd Bergmann <arnd@arndb.de> wrote: > > On Wednesday 27 March 2013, Magnus Damm wrote: > > On Sat, Mar 23, 2013 at 12:39 AM, Arnd Bergmann <arnd@arndb.de> wrote: > > > On Friday 22 March 2013, Simon Horman wrote: > > > I expect that in 3.10, we will have all ARMv6 and ARMv7 platforms converted, > > > with the exception of realview, mmp, s5p, msm, and shmobile. I'm sure we > > > can do realview and mmp for 3.11, possibly also s5p. For shmobile, I think > > > most of the work would be changing drivers/sh/clk to integrate into the common > > > clk framework, and you need to find a way to enable ARM_PATCH_PHYS_VIRT and > > > AUTO_ZRELADDR. Are those things you think can be done for 3.11? > > > > Good to hear that most ARM platforms will be converted by v3.10. This > > is definitely something that I want to make happen for mach-shmobile > > as well. > > > > Our biggest challenge now is the move to common clocks. I suspect that > > moving all our boards and SoCs to common clocks will take much longer > > than v3.11 I'm afraid. > > Ok, I see. If you think it's not likely to be ready for 3.12, we might > need to discuss again whether there is another way of making the > common clk and the sh-clk code coexist. For instance, we could rename > all if the sh/shmobile specific clk functions and their users from > clk_* to shclk_*, and provide a thin wrapper around them that integrates > into common clk. Yeah, I am not sure if it is likely that we will be able to convert all platforms at v3.12 timing. I actually tried to let common clocks and sh-clk coexist when the common clock framework was under heavy development. I recall it being far from trivial. One possible way to develop this could be to force the mach-shmobile "reference DT" implementations use common clocks and keep the old boards as-is. Then we can also make sure the "reference DT" implementations can be used as CONFIG_ARCH_MULTIPLATFORM. So if we only have "reference DT" code as MULTIPLATFORM and then finally kill off the old board code one by one. > > Starting with something smaller like EMEV2 may be a good first step. > > So somehow I'd like to start converting them one by one, perhaps also > > moving over the converted SoCs/boards to CONFIG_ARCH_MULTIPLATFORM in > > an incremental fashion. Do you happen to have any example subarch that > > has been migrated in an increment fashion already? > > We have had a few that were able to do both multiplatform and > single-platform for some time, but then changed to multiplatform-only. > I think mvebu and vt8500 are in this category. Thanks. > > Regarding ARM_PATCH_PHYS_VIRT and AUTO_ZRELADDR, I believe those > > should be enabled for the mach-shmobile bits that are used with > > CONFIG_ARCH_MULTIPLATFORM. Best way forward there is TBD, any > > recommendations would be very welcome! > > Yes, makes sense. > > What I think you should do is rename CONFIG_ARCH_SHMOBILE to > CONFIG_ARCH_SHMOBILE_SINGLE, and add a new symbol in > arch/arm/mach-shmobile/Kconfig like > > config ARCH_SHMOBILE > bool "Renesas SH-Mobile / R-Mobile" if ARCH_MULTI_V6_V7 > default CONFIG_ARCH_SHMOBILE_SINGLE > help > Support for Renesas's SH-Mobile and R-Mobile ARM platforms. > > This way, the platform is a non-exclusive option for the multiplatform > case, and a hidden enabled option when building CONFIG_ARCH_SHMOBILE_SINGLE. > Every machine that is not ready for multiplatform can then add "depends on > CONFIG_ARCH_SHMOBILE_SINGLE". I see, that makes sense. Thanks. Since we're on the topic of CONFIG_ARCH_MULTIPLATFORM, do you have any recommendatoin about LPAE? Judging by the ARM_LPAE help text it seems that selecting ARM_LPAE will result in a kernel only working on LPAE hardware: config ARM_LPAE [snip] Say Y if you have an ARMv7 processor supporting the LPAE page table format and you would like to access memory beyond the 4GB limit. The resulting kernel image will not run on processors without the LPA extension. With the above text it sounds to me like we should not to a "select ARM_LPAE" on each board in the case of CONFIG_ARCH_MULTIPLATFORM. I sort of expect LPAE to behave similar to x86 PAE. At least the board DT file should describe all physical memory available and depending on kernel configuration (HIGHMEM=y/n, LPAE=y/n) we get different amounts of usable memory in the kernel. Then if LPAE should be selected or not is something that the distributions have to decide. Thanks! / magnus
On Monday 01 April 2013, Magnus Damm wrote: > On Wed, Mar 27, 2013 at 8:37 PM, Arnd Bergmann <arnd@arndb.de> wrote: > > Ok, I see. If you think it's not likely to be ready for 3.12, we might > > need to discuss again whether there is another way of making the > > common clk and the sh-clk code coexist. For instance, we could rename > > all if the sh/shmobile specific clk functions and their users from > > clk_* to shclk_*, and provide a thin wrapper around them that integrates > > into common clk. > > Yeah, I am not sure if it is likely that we will be able to convert > all platforms at v3.12 timing. > > I actually tried to let common clocks and sh-clk coexist when the > common clock framework was under heavy development. I recall it being > far from trivial. > > One possible way to develop this could be to force the mach-shmobile > "reference DT" implementations use common clocks and keep the old > boards as-is. Then we can also make sure the "reference DT" > implementations can be used as CONFIG_ARCH_MULTIPLATFORM. So if we > only have "reference DT" code as MULTIPLATFORM and then finally kill > off the old board code one by one. Works for me, but wouldn't that mean that half the shmobile boards become incompatible with the other half, forcing you to build two separate kernels if you want to run on all the machines? Maybe that's not a problem for you, since you tend to have per-soc defconfigs anyway, and it will only be temporary. > Since we're on the topic of CONFIG_ARCH_MULTIPLATFORM, do you have any > recommendatoin about LPAE? > > Judging by the ARM_LPAE help text it seems that selecting ARM_LPAE > will result in a kernel only working on LPAE hardware: > > config ARM_LPAE > [snip] > Say Y if you have an ARMv7 processor supporting the LPAE page > table format and you would like to access memory beyond the > 4GB limit. The resulting kernel image will not run on > processors without the LPA extension. > > With the above text it sounds to me like we should not to a "select > ARM_LPAE" on each board in the case of CONFIG_ARCH_MULTIPLATFORM. Correct. > I sort of expect LPAE to behave similar to x86 PAE. At least the board > DT file should describe all physical memory available and depending on > kernel configuration (HIGHMEM=y/n, LPAE=y/n) we get different amounts > of usable memory in the kernel. Then if LPAE should be selected or not > is something that the distributions have to decide. Yes. I believe all distros are planning to build one non-LPAE nd one LPAE kernel. There will have to be a way to enable all LPAE-capable platforms in Kconfig, but I don't know if that exists already. Presumably, the LPAE kernel will also be using THUMB2 in the kernel, while the non-LPAE kernel may get built with ARMv6 platform support enabled, which rules out THUMB2. Also, we could enable KVM support in the non-LPAE kernel, but since all KVM capable CPU cores (Cortex-A7 and Cortex-A15) so far also come with LPAE, that's not even necessary. You can always use #address-cells=<2> in the DT root node if that helps, and you can also keep your peripherals using #address-cells=<1> with an appropriate ranges property in the soc bus node. Arnd