[RFC] OMAP1: Massive clean up of omap730/omap850 code

[RFC] OMAP1: Massive clean up of omap730/omap850 code

[Alistair Buxton]

Hello from the Linwizard project,

We have been working on supporting omap850 smartphones from HTC such
as Wizard, Herald etc. We have found that omap730 and omap850 are
almost exactly the same. As far as what is supported in linux-omap so
far, they are identical. Currently there are seperate code paths for
730 and 850, and this is causing us a lot of problems when one is
changed and the other isn't. I also noticed that OMAP F-Sample board
uses ARCH_OMAP730 even though it has a OMAP850 SoC.

In order to try to clean this up I have produced a patch series which
removes all cpu_is_omap730/850 and replaces them with unified
cpu_is_omap7xx() blocks, and similarly merges CONFIG checks. Here is a
random example:

-#ifdef CONFIG_ARCH_OMAP730
- if (cpu_is_omap730()) {
+#if defined(CONFIG_ARCH_OMAP730) || defined(CONFIG_ARCH_OMAP850)
+ if (cpu_is_omap7xx()) {
irq_banks = omap730_irq_banks;
irq_bank_count = ARRAY_SIZE(omap730_irq_banks);
}
#endif
-#ifdef CONFIG_ARCH_OMAP850
- if (cpu_is_omap850()) {
- irq_banks = omap850_irq_banks;
- irq_bank_count = ARRAY_SIZE(omap850_irq_banks);
- }
-#endif

Drilling down through the variables shows they are always equivalent
for 730 and 850, except where there is a bug.

The patch series converts all 730/850 specific code to omap7xx as
above. Then all variables and defines have been renamed to refer to
7xx. omap730.h and omap850.h are removed and replaced with omap7xx.h.
ARCH_OMAP730 and ARCH_OMAP850 are still distinct, as there are a few
differences - but only things that haven't been implemented yet.

This makes several bugs go away for us on omap850, including the
MPUIO_VBASE bug, and the lack of working IRQs - since these bugs arn't
in the 730 paths. It would hopefully prevent similar bugs from showing
up in the future too.

I did everything as small patches, so I won't spam all 35+ patches on
the list. The work is available in branch omap7xx here:

http://ali1234.homelinux.net/linwizard-kernel.git/

git diff-tree --stat linux-omap/master omap7xx

arch/arm/mach-omap1/board-fsample.c           |   18 +-
arch/arm/mach-omap1/board-perseus2.c          |   18 +-
arch/arm/mach-omap1/clock.c                   |   22 ++-
arch/arm/mach-omap1/clock.h                   |   30 ++++
arch/arm/mach-omap1/io.c                      |   45 ++----
arch/arm/mach-omap1/irq.c                     |   32 +---
arch/arm/mach-omap1/mcbsp.c                   |   32 ++--
arch/arm/mach-omap1/mux.c                     |   70 +++-----
arch/arm/mach-omap1/pm.c                      |  100 ++++++------
arch/arm/mach-omap1/pm.h                      |   53 +++---
arch/arm/mach-omap1/serial.c                  |   13 +-
arch/arm/mach-omap1/sleep.S                   |   22 ++--
arch/arm/plat-omap/common.c                   |    6 +-
arch/arm/plat-omap/devices.c                  |   22 ++--
arch/arm/plat-omap/gpio.c                     |  227 +++++++------------------
arch/arm/plat-omap/include/mach/entry-macro.S |    8 +-
arch/arm/plat-omap/include/mach/hardware.h    |    2 +-
arch/arm/plat-omap/include/mach/irqs.h        |  229 ++++++++-----------------
arch/arm/plat-omap/include/mach/mcbsp.h       |    6 +-
arch/arm/plat-omap/include/mach/mux.h         |  100 +++--------
arch/arm/plat-omap/include/mach/omap730.h     |  102 -----------
arch/arm/plat-omap/include/mach/omap7xx.h     |  102 +++++++++++
arch/arm/plat-omap/include/mach/omap850.h     |  102 -----------
arch/arm/plat-omap/include/mach/uncompress.h  |    3 +-
arch/arm/plat-omap/io.c                       |   14 +-
arch/arm/plat-omap/usb.c                      |   10 +-
drivers/rtc/Kconfig                           |    2 +-
drivers/spi/omap_uwire.c                      |    8 +-
28 files changed, 513 insertions(+), 885 deletions(-)

--
Alistair Buxton
a.j.buxton@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] OMAP1: Massive clean up of omap730/omap850 code

[Tony Lindgren]

* Alistair Buxton <a.j.buxton@gmail.com> [090919 21:07]:
> Hello from the Linwizard project,
> 
> We have been working on supporting omap850 smartphones from HTC such
> as Wizard, Herald etc. We have found that omap730 and omap850 are
> almost exactly the same. As far as what is supported in linux-omap so
> far, they are identical. Currently there are seperate code paths for
> 730 and 850, and this is causing us a lot of problems when one is
> changed and the other isn't. I also noticed that OMAP F-Sample board
> uses ARCH_OMAP730 even though it has a OMAP850 SoC.
> 
> In order to try to clean this up I have produced a patch series which
> removes all cpu_is_omap730/850 and replaces them with unified
> cpu_is_omap7xx() blocks, and similarly merges CONFIG checks. Here is a
> random example:
> 
> -#ifdef CONFIG_ARCH_OMAP730
> - if (cpu_is_omap730()) {
> +#if defined(CONFIG_ARCH_OMAP730) || defined(CONFIG_ARCH_OMAP850)
> + if (cpu_is_omap7xx()) {
> irq_banks = omap730_irq_banks;
> irq_bank_count = ARRAY_SIZE(omap730_irq_banks);
> }
> #endif
> -#ifdef CONFIG_ARCH_OMAP850
> - if (cpu_is_omap850()) {
> - irq_banks = omap850_irq_banks;
> - irq_bank_count = ARRAY_SIZE(omap850_irq_banks);
> - }
> -#endif
> 
> Drilling down through the variables shows they are always equivalent
> for 730 and 850, except where there is a bug.
> 
> The patch series converts all 730/850 specific code to omap7xx as
> above. Then all variables and defines have been renamed to refer to
> 7xx. omap730.h and omap850.h are removed and replaced with omap7xx.h.
> ARCH_OMAP730 and ARCH_OMAP850 are still distinct, as there are a few
> differences - but only things that haven't been implemented yet.
> 
> This makes several bugs go away for us on omap850, including the
> MPUIO_VBASE bug, and the lack of working IRQs - since these bugs arn't
> in the 730 paths. It would hopefully prevent similar bugs from showing
> up in the future too.
> 
> I did everything as small patches, so I won't spam all 35+ patches on
> the list. The work is available in branch omap7xx here:
> 
> http://ali1234.homelinux.net/linwizard-kernel.git/

Looks good to me. Let's plan on queuing these early so we can test it
in the linux-omap tree to make sure the patches don't break anyting for
other omaps. Then let's get them to the mainline tree the next merge
window after this current one.

To me it looks like we could queue "OMAP7XX] irq.c: Missed a cpu_is_omap850()"
and "OMAP7XX] PM: Add another ARCH_OMAP850 check" already during the -rc
cycle as fixes?

Then assuming you're done with the 7xx patches, could you please
combine all the trivial 730 to 7xx rename patches into just one patch?
This will make it easier for people to read through the whole series ;)

Regards,

Tony


 
> git diff-tree --stat linux-omap/master omap7xx
> 
> arch/arm/mach-omap1/board-fsample.c           |   18 +-
> arch/arm/mach-omap1/board-perseus2.c          |   18 +-
> arch/arm/mach-omap1/clock.c                   |   22 ++-
> arch/arm/mach-omap1/clock.h                   |   30 ++++
> arch/arm/mach-omap1/io.c                      |   45 ++----
> arch/arm/mach-omap1/irq.c                     |   32 +---
> arch/arm/mach-omap1/mcbsp.c                   |   32 ++--
> arch/arm/mach-omap1/mux.c                     |   70 +++-----
> arch/arm/mach-omap1/pm.c                      |  100 ++++++------
> arch/arm/mach-omap1/pm.h                      |   53 +++---
> arch/arm/mach-omap1/serial.c                  |   13 +-
> arch/arm/mach-omap1/sleep.S                   |   22 ++--
> arch/arm/plat-omap/common.c                   |    6 +-
> arch/arm/plat-omap/devices.c                  |   22 ++--
> arch/arm/plat-omap/gpio.c                     |  227 +++++++------------------
> arch/arm/plat-omap/include/mach/entry-macro.S |    8 +-
> arch/arm/plat-omap/include/mach/hardware.h    |    2 +-
> arch/arm/plat-omap/include/mach/irqs.h        |  229 ++++++++-----------------
> arch/arm/plat-omap/include/mach/mcbsp.h       |    6 +-
> arch/arm/plat-omap/include/mach/mux.h         |  100 +++--------
> arch/arm/plat-omap/include/mach/omap730.h     |  102 -----------
> arch/arm/plat-omap/include/mach/omap7xx.h     |  102 +++++++++++
> arch/arm/plat-omap/include/mach/omap850.h     |  102 -----------
> arch/arm/plat-omap/include/mach/uncompress.h  |    3 +-
> arch/arm/plat-omap/io.c                       |   14 +-
> arch/arm/plat-omap/usb.c                      |   10 +-
> drivers/rtc/Kconfig                           |    2 +-
> drivers/spi/omap_uwire.c                      |    8 +-
> 28 files changed, 513 insertions(+), 885 deletions(-)
> 
> --
> Alistair Buxton
> a.j.buxton@gmail.com
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] OMAP1: Massive clean up of omap730/omap850 code

[Alistair Buxton]

2009/9/22 Tony Lindgren <tony@atomide.com>:

> Looks good to me. Let's plan on queuing these early so we can test it
> in the linux-omap tree to make sure the patches don't break anyting for
> other omaps. Then let's get them to the mainline tree the next merge
> window after this current one.
>
> To me it looks like we could queue "OMAP7XX] irq.c: Missed a cpu_is_omap850()"
> and "OMAP7XX] PM: Add another ARCH_OMAP850 check" already during the -rc
> cycle as fixes?
>
> Then assuming you're done with the 7xx patches, could you please
> combine all the trivial 730 to 7xx rename patches into just one patch?
> This will make it easier for people to read through the whole series ;)

Hi,

I've done a cleaned up version of the series now, available in branch
omap7xx-fortony (against 2.6.31) or omap7xx-fortony-rc1 (against
linux-omap/master, 945044d1...) The end result is the same whichever
you apply: the conflicting code in gpio.c just gets deleted anyway.

The first 9 patches do the clean up. The next 2 create omap7xx.h and
swap over the core files. Then the big rename is done in two parts.
Finally, a separate patch for the uwire driver. After that comes misc
fixes for omap850 and 7xx. That puts omap7xx into a state where it
boots for us with only the addition of a board file.

http://ali1234.homelinux.net/linwizard-kernel.git/

Thanks

-- 
Alistair Buxton
a.j.buxton@gmail.com

Re: [RFC] OMAP1: Massive clean up of omap730/omap850 code

[Tony Lindgren]

* Alistair Buxton <a.j.buxton@gmail.com> [090923 11:26]:
> 2009/9/22 Tony Lindgren <tony@atomide.com>:
> 
> > Looks good to me. Let's plan on queuing these early so we can test it
> > in the linux-omap tree to make sure the patches don't break anyting for
> > other omaps. Then let's get them to the mainline tree the next merge
> > window after this current one.
> >
> > To me it looks like we could queue "OMAP7XX] irq.c: Missed a cpu_is_omap850()"
> > and "OMAP7XX] PM: Add another ARCH_OMAP850 check" already during the -rc
> > cycle as fixes?
> >
> > Then assuming you're done with the 7xx patches, could you please
> > combine all the trivial 730 to 7xx rename patches into just one patch?
> > This will make it easier for people to read through the whole series ;)
> 
> Hi,
> 
> I've done a cleaned up version of the series now, available in branch
> omap7xx-fortony (against 2.6.31) or omap7xx-fortony-rc1 (against
> linux-omap/master, 945044d1...) The end result is the same whichever
> you apply: the conflicting code in gpio.c just gets deleted anyway.
> 
> The first 9 patches do the clean up. The next 2 create omap7xx.h and
> swap over the core files. Then the big rename is done in two parts.
> Finally, a separate patch for the uwire driver. After that comes misc
> fixes for omap850 and 7xx. That puts omap7xx into a state where it
> boots for us with only the addition of a board file.

Thanks, looks good to me.

Can you please rebase against the mainline 2.6.32-rc1 once it gets
tagged?

Then please keep your branch around until it all gets merged into the
mainline tree. There should not be any need for you to rebase it,
but I may need to pull it several times as I rebase the various
upstream queues after each -rc.

Regards,

Tony

> 
> http://ali1234.homelinux.net/linwizard-kernel.git/
> 
> Thanks
> 
> -- 
> Alistair Buxton
> a.j.buxton@gmail.com

Re: [RFC] OMAP1: Massive clean up of omap730/omap850 code

[Alistair Buxton]

2009/9/23 Tony Lindgren <tony@atomide.com>:
>
> Thanks, looks good to me.
>
> Can you please rebase against the mainline 2.6.32-rc1 once it gets
> tagged?
>
> Then please keep your branch around until it all gets merged into the
> mainline tree. There should not be any need for you to rebase it,
> but I may need to pull it several times as I rebase the various
> upstream queues after each -rc.

Done. ZMC has now reviewed it, and I've mirrored it to a proper hosted
server too:

git://robotfuzz.com/linwizard-kernel.git
branch: omap7xx-fortony-rc1

Confirmed booting to a shell with the addition of the patches in
branch omap7xx-test2 - but those patches aren't ready to go as we
still need workarounds for a serial bug in order to know that we have
booted.

Thanks,
-- 
Alistair Buxton
a.j.buxton@gmail.com

Re: [RFC] OMAP1: Massive clean up of omap730/omap850 code

[Tony Lindgren]

* Alistair Buxton <a.j.buxton@gmail.com> [090928 14:19]:
> 2009/9/23 Tony Lindgren <tony@atomide.com>:
> >
> > Thanks, looks good to me.
> >
> > Can you please rebase against the mainline 2.6.32-rc1 once it gets
> > tagged?
> >
> > Then please keep your branch around until it all gets merged into the
> > mainline tree. There should not be any need for you to rebase it,
> > but I may need to pull it several times as I rebase the various
> > upstream queues after each -rc.
> 
> Done. ZMC has now reviewed it, and I've mirrored it to a proper hosted
> server too:
> 
> git://robotfuzz.com/linwizard-kernel.git
> branch: omap7xx-fortony-rc1
> 
> Confirmed booting to a shell with the addition of the patches in
> branch omap7xx-test2 - but those patches aren't ready to go as we
> still need workarounds for a serial bug in order to know that we have
> booted.

Can you please rebase on v2.6.32-rc3 and let me know when you have
your new branch ready? There's one merge conflict merging that branch
from -rc1, I've kind of tweaked my scripts to work around that but
it still needs manual merging ;)

Regards,

Tony

Re: [RFC] OMAP1: Massive clean up of omap730/omap850 code

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [091007 10:57]:
> * Alistair Buxton <a.j.buxton@gmail.com> [090928 14:19]:
> > 2009/9/23 Tony Lindgren <tony@atomide.com>:
> > >
> > > Thanks, looks good to me.
> > >
> > > Can you please rebase against the mainline 2.6.32-rc1 once it gets
> > > tagged?
> > >
> > > Then please keep your branch around until it all gets merged into the
> > > mainline tree. There should not be any need for you to rebase it,
> > > but I may need to pull it several times as I rebase the various
> > > upstream queues after each -rc.
> > 
> > Done. ZMC has now reviewed it, and I've mirrored it to a proper hosted
> > server too:
> > 
> > git://robotfuzz.com/linwizard-kernel.git
> > branch: omap7xx-fortony-rc1
> > 
> > Confirmed booting to a shell with the addition of the patches in
> > branch omap7xx-test2 - but those patches aren't ready to go as we
> > still need workarounds for a serial bug in order to know that we have
> > booted.
> 
> Can you please rebase on v2.6.32-rc3 and let me know when you have
> your new branch ready? There's one merge conflict merging that branch
> from -rc1, I've kind of tweaked my scripts to work around that but
> it still needs manual merging ;)

Thanks for doing that, I don't think there any more need to rebase
your set. And I finally got my merge scripts sorted out to rebuild
the linux-omap tree cleanly.

One more request: Can you please repost your whole series one more time
to linux-arm-kernel@lists.infradead.org with linux-omap@vger.kernel.org
list Cc'd?

This is to make sure everybody who wants to review these patches gets
a chance.

And that way I don't have to repost your series for review since the
series will get merged directly from your tree anyways :)

Regards,

Tony