Fix omap builds

Hi,

Here are two patches to fix omap builds.

From: Jarkko Nikula <[email protected]>
Date: Wed, 7 Jan 2009 12:54:34 +0200
Subject: [PATCH] ARM: OMAP: Fix gpio by switching to generic gpio calls

Fix compile by removing remaining omap specific gpio calls. Based on earlier patches by Jarkko Nikula.

Quoted 7 lines · On Wed, 7 Jan 2009 13:17:45 +0200 "ext Tony Lindgren" <[email protected]> wrote:

From: Jarkko Nikula <[email protected]>
Date: Wed, 7 Jan 2009 12:54:34 +0200
Subject: [PATCH] ARM: OMAP: Fix gpio by switching to generic gpio calls

Fix compile by removing remaining omap specific gpio calls. Based on earlier patches by Jarkko Nikula.

Thanks Tony!

drivers/mtd/onenand/omap2.c

Quoted 5 lines

drivers/mtd/onenand/omap2.c +0 -0

index 96ecc17..77a4f14 100644

I think this was already handed over to mtd list by Adrian?

Quoted 10 lines · Jarkko Nikula

Quoted 7 lines · On Wed, 7 Jan 2009 13:17:45 +0200 "ext Tony Lindgren" <[email protected]> wrote:

From: Jarkko Nikula <[email protected]>
Date: Wed, 7 Jan 2009 12:54:34 +0200
Subject: [PATCH] ARM: OMAP: Fix gpio by switching to generic gpio calls

Fix compile by removing remaining omap specific gpio calls. Based on earlier patches by Jarkko Nikula.

Quoted 8 lines

Thanks Tony!

drivers/mtd/onenand/omap2.c

Quoted 5 lines

drivers/mtd/onenand/omap2.c +0 -0

index 96ecc17..77a4f14 100644

I think this was already handed over to mtd list by Adrian?

Oops, sorry. Adrian, do you want me to drop the compile fix for onenand?

Regards,

Tony

Quoted 22 lines · Tony Lindgren

Quoted 10 lines · Jarkko Nikula

Quoted 7 lines · On Wed, 7 Jan 2009 13:17:45 +0200 "ext Tony Lindgren" <[email protected]> wrote:

From: Jarkko Nikula <[email protected]>
Date: Wed, 7 Jan 2009 12:54:34 +0200
Subject: [PATCH] ARM: OMAP: Fix gpio by switching to generic gpio calls

Fix compile by removing remaining omap specific gpio calls. Based on earlier patches by Jarkko Nikula.

Quoted 8 lines

Thanks Tony!

drivers/mtd/onenand/omap2.c

Quoted 5 lines

drivers/mtd/onenand/omap2.c +0 -0

index 96ecc17..77a4f14 100644

I think this was already handed over to mtd list by Adrian?

Oops, sorry. Adrian, do you want me to drop the compile fix for onenand?

Quoted 4 lines

Regards,

Tony

No, those changes have not been sent to mainline before. Please go ahead.

Review

Quoted 4 lines · Tony Lindgren

(quoted diff) +2 -2

-	set_irq_type(OMAP_GPIO_IRQ(SW_ENTER_GPIO16), IRQ_TYPE_EDGE_RISING);
-	if (request_irq(OMAP_GPIO_IRQ(SW_ENTER_GPIO16), &apollon_sw_interrupt,
+	set_irq_type(gpio_to_irq(SW_ENTER_GPIO16), IRQ_TYPE_EDGE_RISING);
+	if (request_irq(gpio_to_irq(SW_ENTER_GPIO16), &apollon_sw_interrupt,

NAK. I wonder how the f*** this got anywhere near the mainline kernel. No no no no no. set_irq_type + request_irq is utter crap and should be rejected whenever its seen. There's absolutely no need for it - request_irq is sufficient. Get rid of this set_irq_type usage from everywhere please.

From 4afb512f6a37d9ca87fb3e8d2f423ce3eaf7e407 Mon Sep 17 00:00:00 2001

Quoted 11 lines · Russell King - ARM Linux

arch/arm/mach-omap2/board-apollon.c static void __init apollon_led_init(void)

Quoted 4 lines · Tony Lindgren

arch/arm/mach-omap2/board-apollon.c +2 -2

-	set_irq_type(OMAP_GPIO_IRQ(SW_ENTER_GPIO16), IRQ_TYPE_EDGE_RISING);
-	if (request_irq(OMAP_GPIO_IRQ(SW_ENTER_GPIO16), &apollon_sw_interrupt,
+	set_irq_type(gpio_to_irq(SW_ENTER_GPIO16), IRQ_TYPE_EDGE_RISING);
+	if (request_irq(gpio_to_irq(SW_ENTER_GPIO16), &apollon_sw_interrupt,

NAK. I wonder how the f*** this got anywhere near the mainline kernel. No no no no no. set_irq_type + request_irq is utter crap and should be rejected whenever its seen. There's absolutely no need for it - request_irq is sufficient. Get rid of this set_irq_type usage from everywhere please.

Blind search and replace? :) I've removed the GPIO key code as there's already a patch to do that cleaner with gpio_keys.

Quoted 13 lines · Tony Lindgren

Quoted 11 lines · Russell King - ARM Linux

arch/arm/mach-omap2/board-apollon.c static void __init apollon_led_init(void)

Quoted 4 lines · Tony Lindgren

arch/arm/mach-omap2/board-apollon.c +2 -2

-	set_irq_type(OMAP_GPIO_IRQ(SW_ENTER_GPIO16), IRQ_TYPE_EDGE_RISING);
-	if (request_irq(OMAP_GPIO_IRQ(SW_ENTER_GPIO16), &apollon_sw_interrupt,
+	set_irq_type(gpio_to_irq(SW_ENTER_GPIO16), IRQ_TYPE_EDGE_RISING);
+	if (request_irq(gpio_to_irq(SW_ENTER_GPIO16), &apollon_sw_interrupt,

NAK. I wonder how the f*** this got anywhere near the mainline kernel. No no no no no. set_irq_type + request_irq is utter crap and should be rejected whenever its seen. There's absolutely no need for it - request_irq is sufficient. Get rid of this set_irq_type usage from everywhere please.

Quoted 2 lines

Blind search and replace? :) I've removed the GPIO key code as there's already a patch to do that cleaner with gpio_keys.

Revised patch is fine.

From: Jarkko Nikula <[email protected]>
Date: Wed, 7 Jan 2009 12:54:34 +0200
Subject: [PATCH] ARM: OMAP: Fix gpio by switching to generic gpio calls

Fix compile by removing remaining omap specific gpio calls. Based on earlier patches by Jarkko Nikula.

OK, here's the pull request again:

The following changes since commit ede6f5aea054d3fb67c78857f7abdee602302043:
Linus Torvalds (1):
Fix up 64-bit byte swaps for most 32-bit architectures

are available in the git repository at:

git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git omap-misc-for-rmk

Hiroshi DOYU (10):
omap mailbox: cleanup omap2 register definition with macro omap mailbox: add initial omap3 support
omap mailbox: print hardware revision at startup omap mailbox: fix empty struct device for omap_mbox omap mailbox: fix empty struct device for omap1 omap mailbox: fix empty struct device for omap2 omap mailbox: add save_/restore_ctx() for PM
omap mailbox: move mailbox.h into mailbox.c
omap mailbox: convert sequence bit checking to module paramter omap mailbox: remove unnecessary header file inclusion

Jarkko Nikula (1):
ARM: OMAP: Fix gpio by switching to generic gpio calls, v2

Madhusudhan Chikkature (1):
omap mmc: Add new omap hsmmc controller for 2430 and 34xx, v3

Tony Lindgren (1):
ARM: OMAP: Fix missing includes

Hi Tony,

Quoted 8 lines · Tony Lindgren

drivers/mfd/twl4030-core.c +0 -0

index b59c385..18179ac 100644
@@ -38,6 +38,7 @@
 #include <linux/i2c.h>
 #include <linux/i2c/twl4030.h>
 

drivers/mfd/twl4030-core.c line 41

Quoted 1 line

drivers/mfd/twl4030-core.c +1 -0

+#include <mach/cpu.h>

That will break the build on !ARM for this driver.

Quoted 11 lines · Samuel Ortiz

Hi Tony,

Quoted 8 lines · Tony Lindgren

drivers/mfd/twl4030-core.c +0 -0

index b59c385..18179ac 100644
@@ -38,6 +38,7 @@
 #include <linux/i2c.h>
 #include <linux/i2c/twl4030.h>
 

Quoted 2 lines

drivers/mfd/twl4030-core.c line 41

Quoted 1 line

drivers/mfd/twl4030-core.c +1 -0

+#include <mach/cpu.h>

That will break the build on !ARM for this driver.

... which in itself is an argument for making it use the clk API properly so that these kinds of CPU specific dependencies are kept out of the driver.

In other words:

        if (cpu_is_omap2430())
                osc = clk_get(NULL, "osc_ck");
        else
                osc = clk_get(NULL, "osc_sys_ck");

becomes:

        osc = clk_get(dev, "hfclk");

since "hfclk" is the name of the input on the device, or it should be NULL if it is the only input on the device (iow, you don't want to distinguish it from the 32kHz clock.)

And that eliminates the need for any platform specific includes (which is the whole point of the clk API - giving drivers a _generic_ way to get at clock information without resorting to platform specific crap.)

Quoted 15 lines · Russell King - ARM Linux

Quoted 13 lines · Samuel Ortiz

Hi Tony,

drivers/mfd/twl4030-core.c line 41

Quoted 9 lines · Tony Lindgren

drivers/mfd/twl4030-core.c +1 -0

index b59c385..18179ac 100644
@@ -38,6 +38,7 @@
 #include <linux/i2c.h>
 #include <linux/i2c/twl4030.h>
 
+#include <mach/cpu.h>

That will break the build on !ARM for this driver.

Quoted 3 lines

... which in itself is an argument for making it use the clk API properly so that these kinds of CPU specific dependencies are kept out of the driver.

I agree.
Until that gets done, if we really need to include a header file to fix this build, I would rather go for a generic one, <linux/io.h> for example.

Quoted 7 lines

drivers/mfd/twl4030-core.c +0 -0

@@ -38,6 +38,7 @@
  #include <linux/i2c.h>
  #include <linux/i2c/twl4030.h>

+#include <mach/cpu.h>

That will break the build on !ARM for this driver.

In other words:

        if (cpu_is_omap2430())
                osc = clk_get(NULL, "osc_ck");
        else
                osc = clk_get(NULL, "osc_sys_ck");

becomes:

        osc = clk_get(dev, "hfclk");

since "hfclk" is the name of the input on the device, or it should be NULL if it is the only input on the device (iow, you don't want to distinguish it from the 32kHz clock.)

And that eliminates the need for any platform specific includes (which is the whole point of the clk API - giving drivers a _generic_ way to get at clock information without resorting to platform specific crap.)

Quoted 8 lines · Samuel Ortiz

Quoted 7 lines

drivers/mfd/twl4030-core.c +0 -0

@@ -38,6 +38,7 @@
  #include <linux/i2c.h>
  #include <linux/i2c/twl4030.h>

+#include <mach/cpu.h>

That will break the build on !ARM for this driver.

What needs to happen with twl4030-core.c is IMO this:

- Near term:
* revert 6354ab5c63bc986bf539026a1b289cc142f6e87c and just make the driver depend on HAVE_CLK

* #ifdef CONFIG_ARM do the #include <mach/cpu.h>

Quoted 2 lines · Tony Lindgren

Madhusudhan Chikkature (1):
omap mmc: Add new omap hsmmc controller for 2430 and 34xx, v3

This I'd argue falls into the same category, but since its well known between us and Pierre who's acked it, I think it has sufficiently low impact that it can be accepted.

Quoted 7 lines · Russell King - ARM Linux

Quoted 2 lines · Tony Lindgren

Madhusudhan Chikkature (1):
omap mmc: Add new omap hsmmc controller for 2430 and 34xx, v3

This I'd argue falls into the same category, but since its well known between us and Pierre who's acked it, I think it has sufficiently low impact that it can be accepted.

... and now -rc1 is out, it's now too late for this.

Quoted 10 lines · Tony Lindgren

OK, here's the pull request again:

The following changes since commit ede6f5aea054d3fb67c78857f7abdee602302043:
Linus Torvalds (1):
Fix up 64-bit byte swaps for most 32-bit architectures

are available in the git repository at:

git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git omap-misc-for-rmk

Quoted 11 lines

Hiroshi DOYU (10):
omap mailbox: cleanup omap2 register definition with macro omap mailbox: add initial omap3 support
omap mailbox: print hardware revision at startup omap mailbox: fix empty struct device for omap_mbox omap mailbox: fix empty struct device for omap1 omap mailbox: fix empty struct device for omap2 omap mailbox: add save_/restore_ctx() for PM
omap mailbox: move mailbox.h into mailbox.c
omap mailbox: convert sequence bit checking to module paramter omap mailbox: remove unnecessary header file inclusion

I'd rather avoid adding new stuff this late in the merge window - it's had no exposure in linux-next, etc.

Quoted 12 lines · David Brownell

Quoted 8 lines · Samuel Ortiz

Quoted 7 lines

drivers/mfd/twl4030-core.c +0 -0

@@ -38,6 +38,7 @@
  #include <linux/i2c.h>
  #include <linux/i2c/twl4030.h>

+#include <mach/cpu.h>

That will break the build on !ARM for this driver.

What needs to happen with twl4030-core.c is IMO this:

Quoted 3 lines

- Near term:
* revert 6354ab5c63bc986bf539026a1b289cc142f6e87c and just make the driver depend on HAVE_CLK

Yep, I'll do that afer the merge window.

Quoted 1 line

* #ifdef CONFIG_ARM do the #include <mach/cpu.h>

Not too pretty, but a good enough compromise for me. I'll push that.

Quoted 16 lines · Samuel Ortiz

Quoted 15 lines · Russell King - ARM Linux

Quoted 13 lines · Samuel Ortiz

Hi Tony,

drivers/mfd/twl4030-core.c line 41

Quoted 9 lines · Tony Lindgren

drivers/mfd/twl4030-core.c +1 -0

index b59c385..18179ac 100644
@@ -38,6 +38,7 @@
 #include <linux/i2c.h>
 #include <linux/i2c/twl4030.h>
 
+#include <mach/cpu.h>

That will break the build on !ARM for this driver.

Quoted 7 lines

Quoted 3 lines

... which in itself is an argument for making it use the clk API properly so that these kinds of CPU specific dependencies are kept out of the driver.

I agree.
Until that gets done, if we really need to include a header file to fix this build, I would rather go for a generic one, <linux/io.h> for example.

I fear that such an approach will result in the current situation persisting.

I've tried to tackle the OMAP clock implementation, and ended up giving up because other people are busy fiddling with it as well. I was rather hoping that these other changes were going to make it into the mainline kernel so I could resume my work on it, but alas that's not happened.

And note that I _only_ work with the mainline kernel, so having work sitting in other peoples trees derived from Tony's tree is completely useless.

Of course, I could say "sod it, waited long enough, I'm merging my omap-clks1 branch" for the next merge window.

Quoted 4 lines · Tony Lindgren

From: Jarkko Nikula <[email protected]>
Date: Wed, 7 Jan 2009 12:54:34 +0200
Subject: [PATCH] ARM: OMAP: Fix gpio by switching to generic gpio calls

Quoted 2 lines

Fix compile by removing remaining omap specific gpio calls. Based on earlier patches by Jarkko Nikula.

This isn't the whole story... There's another build error related to the OMAP GPIO changes which remain unaddressed:

arch/arm/plat-omap/gpio.c:1792: error: 'struct gpio_bank' has no member named 'suspend_wakeup'

and there's also the unrelated:

arch/arm/mach-omap1/board-palmte.c:198: error: variable 'palmte_mmc_config' has initializer but incomplete type

Quoted 5 lines · Russell King - ARM Linux

Quoted 4 lines · Russell King - ARM Linux

Quoted 2 lines · Tony Lindgren

Madhusudhan Chikkature (1):
omap mmc: Add new omap hsmmc controller for 2430 and 34xx, v3

Quoted 5 lines

Quoted 3 lines

This I'd argue falls into the same category, but since its well known between us and Pierre who's acked it, I think it has sufficiently low impact that it can be accepted.

... and now -rc1 is out, it's now too late for this.

Oh well. Will resubmit it later on LKML for Pierre, at least the MMC init code is mostly dealt with now.

Quoted 10 lines · Tony Lindgren

Quoted 9 lines · Russell King - ARM Linux

Quoted 7 lines · Russell King - ARM Linux

Quoted 2 lines · Tony Lindgren

Madhusudhan Chikkature (1):
omap mmc: Add new omap hsmmc controller for 2430 and 34xx, v3

This I'd argue falls into the same category, but since its well known between us and Pierre who's acked it, I think it has sufficiently low impact that it can be accepted.

Quoted 4 lines

Quoted 1 line

... and now -rc1 is out, it's now too late for this.

Oh well. Will resubmit it later on LKML for Pierre, at least the MMC init code is mostly dealt with now.

Actually, as Pierre is okay with it coming via my tree, I'd prefer that so I can sanely run my devel branch on the LDP.

Quoted 13 lines · Russell King - ARM Linux

Quoted 12 lines · Tony Lindgren

Quoted 10 lines · Russell King - ARM Linux

Quoted 7 lines · Russell King - ARM Linux

Quoted 2 lines · Tony Lindgren

Madhusudhan Chikkature (1):
omap mmc: Add new omap hsmmc controller for 2430 and 34xx, v3

This I'd argue falls into the same category, but since its well known between us and Pierre who's acked it, I think it has sufficiently low impact that it can be accepted.

... and now -rc1 is out, it's now too late for this.

Quoted 5 lines

Quoted 2 lines

Oh well. Will resubmit it later on LKML for Pierre, at least the MMC init code is mostly dealt with now.

Actually, as Pierre is okay with it coming via my tree, I'd prefer that so I can sanely run my devel branch on the LDP.

OK, will start putting together for-next branch.

Quoted 17 lines · Tony Lindgren

Quoted 16 lines · Russell King - ARM Linux

Quoted 14 lines · Tony Lindgren

Quoted 10 lines · Russell King - ARM Linux

Quoted 7 lines · Russell King - ARM Linux

Quoted 2 lines · Tony Lindgren

Madhusudhan Chikkature (1):
omap mmc: Add new omap hsmmc controller for 2430 and 34xx, v3

This I'd argue falls into the same category, but since its well known between us and Pierre who's acked it, I think it has sufficiently low impact that it can be accepted.

... and now -rc1 is out, it's now too late for this.

Oh well. Will resubmit it later on LKML for Pierre, at least the MMC init code is mostly dealt with now.

Quoted 4 lines

Quoted 2 lines

Actually, as Pierre is okay with it coming via my tree, I'd prefer that so I can sanely run my devel branch on the LDP.

OK, will start putting together for-next branch.

I'd like the MMC driver on its own please.