[PATCH v4 00/11] ep93xx: Move SoC private bits to core

[PATCH v4 00/11] ep93xx: Move SoC private bits to core

[Ryan Mallon]

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

[PATCH v4 00/11] ep93xx: Move SoC private bits to core

[Arnd Bergmann]

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

[PATCH v4 00/11] ep93xx: Move SoC private bits to core

[Ryan Mallon]

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

[PATCH v4 00/11] ep93xx: Move SoC private bits to core

[Arnd Bergmann]

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

[PATCH v4 00/11] ep93xx: Move SoC private bits to core

[H Hartley Sweeten]

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

[PATCH v4 00/11] ep93xx: Move SoC private bits to core

[Arnd Bergmann]

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