ep93xx: Move SoC private bits to core
v4 cover ep93xx: Move SoC private bits to core
This patch series is an effort to move the ep93xx SoC specific code out of drivers and include/mach into arch/arm/mach-ep93xx. This work involves the following changes:
- Create a new private header called soc.h to replace most of mach/include/ep93xx-regs.h
- Move the Maverick crunch code from arch/arm/kernel to mach-ep93xx
- Convert the ep93xx backlight and watchdog drivers to properly ioremap memory.
- Move all system controller access to the ep93xx core code
The only defines left in ep93xx-regs.h are for the APB UARTS which are also needed in include/mach/uncompress.h and include/mach/debug-macro.S.
Patch 2 has already been merged to the ASoC tree and patch 5 has already been merged to the watchdog tree. Neither patch has been modified since they were applied, and are included here for completeness and to avoid build errors.
All of the patches are against v3.3-rc7 and now have reviewed-by and/or acked-by tags except for patch 4 which has been changed since the last version. Arnd, once I get an ack for the final patch I can prepare a git branch for you to pull. I understand if this is now too late for v3.4.
Changes since v3:
- Removed the request_mem_region calls from both the backlight and framebuffer drivers since it causes problems due to the fact that the two drivers sharing parts of the same register space. This needs to be fixed properly in future.
Changes since v2:
- Added Hartley's patch to convert watchdog driver to a proper platform driver
- Fix the backlight driver to pass a proper memory resource, and ioremap, but not request it.
Changes since v1:
- Moved syscon access functions to the bottom of soc.h
- Don't include soc.h in crunch in the same patch as moving it
- Removed unnecessary whitespace
- Added commit message to gpio define move patch
- Remove the arch_reset change since this is already done by the reset rework
H Hartley Sweeten (1):
ep93xx: Convert the watchdog driver into a platform device.
Ryan Mallon (10):
ep93xx: Move PHYS_BASE defines to local SoC header file
ep93xx: Don't use system controller defines in audio drivers
ep93xx: Move GPIO defines to gpio-ep93xx.h
ep93xx: Use ioremap for backlight driver
ep93xx: Move peripheral defines to local SoC header
ep93xx: Configure GPIO ports in core code
ep93xx: Make syscon access functions private to SoC
ep93xx: Move crunch code to mach-ep93xx directory
ep93xx: Move EP93XX_SYSCON defines to SoC private header
ep93xx: Remove unnecessary includes of ep93xx-regs.h
arch/arm/kernel/Makefile | 3 - arch/arm/kernel/crunch-bits.S | 305 ----------------------- arch/arm/kernel/crunch.c | 88 ------- arch/arm/mach-ep93xx/Makefile | 3 + arch/arm/mach-ep93xx/adssphere.c | 1 + arch/arm/mach-ep93xx/clock.c | 1 + arch/arm/mach-ep93xx/core.c | 54 +++-- arch/arm/mach-ep93xx/crunch-bits.S | 305 +++++++++++++++++++++++ arch/arm/mach-ep93xx/crunch.c | 90 +++++++ arch/arm/mach-ep93xx/dma.c | 2 + arch/arm/mach-ep93xx/edb93xx.c | 1 + arch/arm/mach-ep93xx/gesbc9312.c | 1 + arch/arm/mach-ep93xx/include/mach/ep93xx-regs.h | 191 +-------------- arch/arm/mach-ep93xx/include/mach/gpio-ep93xx.h | 10 + arch/arm/mach-ep93xx/include/mach/hardware.h | 1 - arch/arm/mach-ep93xx/include/mach/platform.h | 16 +-- arch/arm/mach-ep93xx/micro9.c | 1 + arch/arm/mach-ep93xx/simone.c | 2 + arch/arm/mach-ep93xx/snappercl15.c | 2 + arch/arm/mach-ep93xx/soc.h | 213 ++++++++++++++++ arch/arm/mach-ep93xx/ts72xx.c | 1 + arch/arm/mach-ep93xx/vision_ep9307.c | 2 + drivers/gpio/gpio-ep93xx.c | 7 - drivers/video/backlight/ep93xx_bl.c | 25 +- drivers/video/ep93xx-fb.c | 15 +- drivers/watchdog/ep93xx_wdt.c | 51 +++- sound/soc/ep93xx/edb93xx.c | 4 +- sound/soc/ep93xx/snappercl15.c | 4 +- 28 files changed, 736 insertions(+), 663 deletions(-) delete mode 100644 arch/arm/kernel/crunch-bits.S delete mode 100644 arch/arm/kernel/crunch.c create mode 100644 arch/arm/mach-ep93xx/crunch-bits.S create mode 100644 arch/arm/mach-ep93xx/crunch.c create mode 100644 arch/arm/mach-ep93xx/soc.h
v4 cover ep93xx: Move SoC private bits to core
Quoted 11 lines · Ryan Mallon
This patch series is an effort to move the ep93xx SoC specific code out of drivers and
include/machintoarch/arm/mach-ep93xx. This work involves the following changes:- Create a new private header called
soc.hto replace most ofmach/include/ep93xx-regs.h
- Move the Maverick crunch code fromarch/arm/kernelto mach-ep93xx
- Convert the ep93xx backlight and watchdog drivers to properly ioremap memory.
- Move all system controller access to the ep93xx core code
Quoted 8 lines
The only defines left in
ep93xx-regs.hare for the APB UARTS which are also needed ininclude/mach/uncompress.handinclude/mach/debug-macro.S.Patch 2 has already been merged to the ASoC tree and patch 5 has already been merged to the watchdog tree. Neither patch has been modified since they were applied, and are included here for completeness and to avoid build errors.
Looks all very nice, great work!
Quoted 5 lines
All of the patches are against v3.3-rc7 and now have reviewed-by and/or acked-by tags except for patch 4 which has been changed since the last version. Arnd, once I get an ack for the final patch I can prepare a git branch for you to pull. I understand if this is now too late for v3.4.
If there are no conflicts against the for-next branch and Olof agrees, I would probably let this one go in for v3.4. It's a nice cleanup and it will be easier to do your v3.5 patches if it's all merged.
On a related note, I would like to understand better what your plans are for the future of ep93xx. My undestanding is that the product line is a dead end and there won't be any other compatible socs, but the Linux support is very much alive and supports all the existing hardware, is that correct?
There are currently eight board files (since all the dev boards got merged into one file), which seems very manageable and there should be no problem adding a few more over the years to come, if necessary.
At the same time, the platform seems simple enough that you could also do a device tree port in rather in a fairly short time if you like, which would let you obsolete all the board files and add new machines just through device tree blobs.
Arnd
v4 cover ep93xx: Move SoC private bits to core
Quoted 29 lines · Arnd Bergmann
Quoted 11 lines · Ryan Mallon
This patch series is an effort to move the ep93xx SoC specific code out of drivers and
include/machintoarch/arm/mach-ep93xx. This work involves the following changes:- Create a new private header called
soc.hto replace most ofmach/include/ep93xx-regs.h
- Move the Maverick crunch code fromarch/arm/kernelto mach-ep93xx
- Convert the ep93xx backlight and watchdog drivers to properly ioremap memory.
- Move all system controller access to the ep93xx core codeQuoted 8 lines
The only defines left in
ep93xx-regs.hare for the APB UARTS which are also needed ininclude/mach/uncompress.handinclude/mach/debug-macro.S.Patch 2 has already been merged to the ASoC tree and patch 5 has already been merged to the watchdog tree. Neither patch has been modified since they were applied, and are included here for completeness and to avoid build errors.
Looks all very nice, great work!
Quoted 5 lines
All of the patches are against v3.3-rc7 and now have reviewed-by and/or acked-by tags except for patch 4 which has been changed since the last version. Arnd, once I get an ack for the final patch I can prepare a git branch for you to pull. I understand if this is now too late for v3.4.
Quoted 3 lines
If there are no conflicts against the for-next branch and Olof agrees, I would probably let this one go in for v3.4. It's a nice cleanup and it will be easier to do your v3.5 patches if it's all merged.
Okay thanks. I'll try and fix up the minor bits and pieces that you and Hartley pointed out and send a pull request later tonight.
I'm planning on using my tree for future ep93xx development, so that I can aggregate any patches there to be included in arm-soc.
Quoted 6 lines
On a related note, I would like to understand better what your plans are for the future of ep93xx. My undestanding is that the product line is a dead end and there won't be any other compatible socs, but the Linux support is very much alive and supports all the existing hardware, is that correct?
Yeah, the product line is dead, but there are a handful of boards still being used in production systems and we now support most of the peripherals, I think IDE is the only major device missing support.
Quoted 3 lines
There are currently eight board files (since all the dev boards got merged into one file), which seems very manageable and there should be no problem adding a few more over the years to come, if necessary.
I doubt there will be many new boards added.
Quoted 4 lines
At the same time, the platform seems simple enough that you could also do a device tree port in rather in a fairly short time if you like, which would let you obsolete all the board files and add new machines just through device tree blobs.
Yeah, converting to device tree is one of my goals. I need to spend some time reading through the device tree specification first.
~Ryan
v4 cover ep93xx: Move SoC private bits to core
Quoted 6 lines · Ryan Mallon
Quoted 3 lines
There are currently eight board files (since all the dev boards got merged into one file), which seems very manageable and there should be no problem adding a few more over the years to come, if necessary.
I doubt there will be many new boards added.
Quoted 8 lines
Quoted 4 lines
At the same time, the platform seems simple enough that you could also do a device tree port in rather in a fairly short time if you like, which would let you obsolete all the board files and add new machines just through device tree blobs.
Yeah, converting to device tree is one of my goals. I need to spend some time reading through the device tree specification first.
Ok, great!
A number of ARM9 and XScale based platforms have started the conversion now, and there is a lot you can learn by looking at the others. I would recommend waiting for 3.4-rc1 before you get serious with this, because patches are pending in various trees at the moment.
There is no strict need for you to do the conversion, because you say that the platform is basically dead and there is not much churn to be expected in the future, but you are definitely welcome to join in.
As the first steps (after reading Documentation/devicetree/booting-without-of.txt) the best way forward is probably to take you favourite board file and add a DT_MACHINE_START section so you can boot the same machine
when passing an empty devicetree rather than ATAGS. Then add the interrupt controller (should be simple for VIC), followed by gpio (needs bindings, see Documentation/devicetree/bindings/gpio/*.txt), i2c and spi. After you have all that infrastructure in place, you can convert every other device, one at a time. Some (anything without platform_data) will be trivial, others require you to come up with a new binding document and properties to replace the platform_data. Many people try to do the ones from board files first because it lets them remove the board files, and only after that look at converting the core devices, but you can do any order you like.
Arnd
v4 cover ep93xx: Move SoC private bits to core
Quoted 27 lines · Arnd Bergmann
Quoted 6 lines · Ryan Mallon
Quoted 3 lines
There are currently eight board files (since all the dev boards got merged into one file), which seems very manageable and there should be no problem adding a few more over the years to come, if necessary.
I doubt there will be many new boards added.
Quoted 8 lines
Quoted 4 lines
At the same time, the platform seems simple enough that you could also do a device tree port in rather in a fairly short time if you like, which would let you obsolete all the board files and add new machines just through device tree blobs.
Yeah, converting to device tree is one of my goals. I need to spend some time reading through the device tree specification first.
Ok, great!
A number of ARM9 and XScale based platforms have started the conversion now, and there is a lot you can learn by looking at the others. I would recommend waiting for 3.4-rc1 before you get serious with this, because patches are pending in various trees at the moment.
There is no strict need for you to do the conversion, because you say that the platform is basically dead and there is not much churn to be expected in the future, but you are definitely welcome to join in.
Quoted 13 lines
As the first steps (after reading
Documentation/devicetree/booting-without-of.txt) the best way forward is probably to take you favourite board file and add aDT_MACHINE_STARTsection so you can boot the same machine
when passing an empty devicetree rather than ATAGS. Then add the interrupt controller (should be simple for VIC), followed by gpio (needs bindings, seeDocumentation/devicetree/bindings/gpio/*.txt), i2c and spi. After you have all that infrastructure in place, you can convert every other device, one at a time. Some (anything withoutplatform_data) will be Trivial, others require you to come up with a new binding document and properties to replace theplatform_data. Many people try to do the ones from board files first because it lets them remove the board files, and only after that look at converting the core devices, but you can do any order you like.
The main problem I see with converting the ep93xx platform to device tree is that it requires modifying the bootloader. Correct me if I am wrong.
Most of the ep93xx boards use RedBoot for the bootloader. Unfortunately Cirrus never released the ep93xx port to eCos so the source is not available. You can dig it out of the stuff Cirrus has on http://arm.cirrus.com but it's based on a pretty old version of eCos/RedBoot and might be quite a task getting it current.
A couple years ago I tried getting Cirrus to release the source to eCos. It got to the point where it appeared they would but nothing ever happened.
Some of the ep93xx boards use U-Boot for the bootloader but I think that port has recently been dropped from the tree.
Regards,
Hartley
v4 cover ep93xx: Move SoC private bits to core
Quoted 16 lines · H Hartley Sweeten
Quoted 5 lines · Arnd Bergmann
As the first steps (after reading
Documentation/devicetree/booting-without-of.txt) the best way forward is probably to take you favourite board file and add aDT_MACHINE_STARTsection so you can boot the same machine
when passing an empty devicetree rather than ATAGS. Then add the interrupt controller (should be simple for VIC), followed by gpio (needs bindings,Quoted 8 lines
see
Documentation/devicetree/bindings/gpio/*.txt), i2c and spi. After you have all that infrastructure in place, you can convert every other device, one at a time. Some (anything withoutplatform_data) will be Trivial, others require you to come up with a new binding document and properties to replace theplatform_data. Many people try to do the ones from board files first because it lets them remove the board files, and only after that look at converting the core devices, but you can do any order you like.
Quoted 2 lines
The main problem I see with converting the ep93xx platform to device tree is that it requires modifying the bootloader. Correct me if I am wrong.
You can always use legacy bootloaders with an appended device tree. It's slightly less interesting that way but it still works. You can also use a second-stage boot loader, but that would require having one that supports your platform.
Arnd