* [PATCH v4 00/11] ep93xx: Move SoC private bits to core @ 2012-03-12 22:48 Ryan Mallon 2012-03-13 12:35 ` Arnd Bergmann 0 siblings, 1 reply; 6+ messages in thread From: Ryan Mallon @ 2012-03-12 22:48 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH v4 00/11] ep93xx: Move SoC private bits to core 2012-03-12 22:48 [PATCH v4 00/11] ep93xx: Move SoC private bits to core Ryan Mallon @ 2012-03-13 12:35 ` Arnd Bergmann 2012-03-13 22:22 ` Ryan Mallon 0 siblings, 1 reply; 6+ messages in thread From: Arnd Bergmann @ 2012-03-13 12:35 UTC (permalink / raw) To: linux-arm-kernel On Monday 12 March 2012, Ryan Mallon wrote: > 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. Looks all very nice, great work! > 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH v4 00/11] ep93xx: Move SoC private bits to core 2012-03-13 12:35 ` Arnd Bergmann @ 2012-03-13 22:22 ` Ryan Mallon 2012-03-14 13:51 ` Arnd Bergmann 0 siblings, 1 reply; 6+ messages in thread From: Ryan Mallon @ 2012-03-13 22:22 UTC (permalink / raw) To: linux-arm-kernel On 13/03/12 23:35, Arnd Bergmann wrote: > On Monday 12 March 2012, Ryan Mallon wrote: >> 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. > > Looks all very nice, great work! > >> 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. 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. > > 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. > 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. > 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH v4 00/11] ep93xx: Move SoC private bits to core 2012-03-13 22:22 ` Ryan Mallon @ 2012-03-14 13:51 ` Arnd Bergmann 2012-03-14 16:20 ` H Hartley Sweeten 0 siblings, 1 reply; 6+ messages in thread From: Arnd Bergmann @ 2012-03-14 13:51 UTC (permalink / raw) To: linux-arm-kernel On Tuesday 13 March 2012, Ryan Mallon wrote: > > 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. > > > 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH v4 00/11] ep93xx: Move SoC private bits to core 2012-03-14 13:51 ` Arnd Bergmann @ 2012-03-14 16:20 ` H Hartley Sweeten 2012-03-14 17:00 ` Arnd Bergmann 0 siblings, 1 reply; 6+ messages in thread From: H Hartley Sweeten @ 2012-03-14 16:20 UTC (permalink / raw) To: linux-arm-kernel On Wednesday, March 14, 2012 6:51 AM, Arnd Bergmann wrote: > On Tuesday 13 March 2012, Ryan Mallon wrote: >>> 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. >> >>> 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. 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH v4 00/11] ep93xx: Move SoC private bits to core 2012-03-14 16:20 ` H Hartley Sweeten @ 2012-03-14 17:00 ` Arnd Bergmann 0 siblings, 0 replies; 6+ messages in thread From: Arnd Bergmann @ 2012-03-14 17:00 UTC (permalink / raw) To: linux-arm-kernel On Wednesday 14 March 2012, H Hartley Sweeten wrote: > On Wednesday, March 14, 2012 6:51 AM, Arnd Bergmann wrote: > > 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. > > 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-03-14 17:00 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-03-12 22:48 [PATCH v4 00/11] ep93xx: Move SoC private bits to core Ryan Mallon 2012-03-13 12:35 ` Arnd Bergmann 2012-03-13 22:22 ` Ryan Mallon 2012-03-14 13:51 ` Arnd Bergmann 2012-03-14 16:20 ` H Hartley Sweeten 2012-03-14 17:00 ` Arnd Bergmann
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.