[PATCH 0/90] Post 2.6.21 OMAP update

[PATCH 0/90] Post 2.6.21 OMAP update

[Tony Lindgren]

Hi all,

Attached is a rather large OMAP update for post 2.6.21.

OMAP is a series of ARM processors from Texas Instruments
used in various cell phones and PDAs.

The patch series is based on code that has been brewing
in the linux-omap tree since last fall.

We'd like to switch the linux-omap tree to use the mainline
tree for core omap stuff, and this series attemps to do it
for most part. 

As the patch series is big, Andrew Morton asked me to post
it to LKML instead of linux-arm-kernel list for a wider review,
so please comment on the patches if you have a chance!

The patches touch only omap specific code at:

arch/arm/Kconfig
arch/arm/plat-omap
arch/arm/mach-omap1
arch/arm/mach-omap2
include/asm-arm/arch-omap

Regards,

Tony

[PATCH 1/90] ARM: OMAP: Place SMS and SDRC into smart idle mode

[Tony Lindgren]

From: Juha Yrjola <juha.yrjola@solidboot.com>

Place SMS and SDRC into smart idle mode

Signed-off-by: Juha Yrjola <juha.yrjola@solidboot.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 arch/arm/mach-omap2/io.c     |    2 +
 arch/arm/mach-omap2/memory.c |   48 ++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 50 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index a0728c3..748920f 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -26,6 +26,7 @@
 extern void omap_sram_init(void);
 extern int omap2_clk_init(void);
 extern void omap2_check_revision(void);
+extern void omap2_init_memory(void);
 extern void gpmc_init(void);
 
 /*
@@ -67,5 +68,6 @@ void __init omap2_init_common_hw(void)
 {
 	omap2_mux_init();
 	omap2_clk_init();
+	omap2_init_memory();
 	gpmc_init();
 }
diff --git a/arch/arm/mach-omap2/memory.c b/arch/arm/mach-omap2/memory.c
index 85cbc2a..f173aa8 100644
--- a/arch/arm/mach-omap2/memory.c
+++ b/arch/arm/mach-omap2/memory.c
@@ -30,6 +30,38 @@
 #include "prcm-regs.h"
 #include "memory.h"
 
+#define SMS_BASE		0x68008000
+#define SMS_SYSCONFIG		0x010
+
+#define SDRC_BASE		0x68009000
+#define SDRC_SYSCONFIG		0x010
+#define SDRC_SYSSTATUS		0x014
+
+static const u32 sms_base = IO_ADDRESS(SMS_BASE);
+static const u32 sdrc_base = IO_ADDRESS(SDRC_BASE);
+
+
+static inline void sms_write_reg(int idx, u32 val)
+{
+	__raw_writel(val, sms_base + idx);
+}
+
+static inline u32 sms_read_reg(int idx)
+{
+	return __raw_readl(sms_base + idx);
+}
+
+static inline void sdrc_write_reg(int idx, u32 val)
+{
+	__raw_writel(val, sdrc_base + idx);
+}
+
+static inline u32 sdrc_read_reg(int idx)
+{
+	return __raw_readl(sdrc_base + idx);
+}
+
+
 static struct memory_timings mem_timings;
 
 u32 omap2_memory_get_slow_dll_ctrl(void)
@@ -99,3 +131,19 @@ void omap2_init_memory_params(u32 force_lock_to_unlock_mode)
 	/* 90 degree phase for anything below 133Mhz + disable DLL filter */
 	mem_timings.slow_dll_ctrl |= ((1 << 1) | (3 << 8));
 }
+
+void __init omap2_init_memory(void)
+{
+	u32 l;
+
+	l = sms_read_reg(SMS_SYSCONFIG);
+	l &= ~(0x3 << 3);
+	l |= (0x2 << 3);
+	sms_write_reg(SMS_SYSCONFIG, l);
+
+	l = sdrc_read_reg(SDRC_SYSCONFIG);
+	l &= ~(0x3 << 3);
+	l |= (0x2 << 3);
+	sdrc_write_reg(SDRC_SYSCONFIG, l);
+
+}
-- 
1.4.4.2

[PATCH 2/90] ARM: OMAP: Force APLLs always active

[Tony Lindgren]

From: Juha Yrjola <juha.yrjola@solidboot.com>

The APLLs are most efficiently idled by hardware.

Signed-off-by: Juha Yrjola <juha.yrjola@solidboot.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 arch/arm/mach-omap2/clock.c |   13 ++-----------
 1 files changed, 2 insertions(+), 11 deletions(-)

diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index 5170481..0306507 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -1160,8 +1160,8 @@ int __init omap2_clk_init(void)
 	clk_enable(&sync_32k_ick);
 	clk_enable(&omapctrl_ick);
 
-	/* Force the APLLs active during bootup to avoid disabling and
-	 * enabling them unnecessarily. */
+	/* Force the APLLs always active. The clocks are idled
+	 * automatically by hardware. */
 	clk_enable(&apll96_ck);
 	clk_enable(&apll54_ck);
 
@@ -1174,12 +1174,3 @@ int __init omap2_clk_init(void)
 
 	return 0;
 }
-
-static int __init omap2_disable_aplls(void)
-{
-	clk_disable(&apll96_ck);
-	clk_disable(&apll54_ck);
-
-	return 0;
-}
-late_initcall(omap2_disable_aplls);
-- 
1.4.4.2

[PATCH 3/90] ARM: OMAP: Add DMA IRQ sanity checks

[Tony Lindgren]

From: Juha Yrjola <juha.yrjola@solidboot.com>

Add DMA IRQ sanity checks

Signed-off-by: Juha Yrjola <juha.yrjola@solidboot.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 arch/arm/plat-omap/dma.c |   25 ++++++++++++++++++-------
 1 files changed, 18 insertions(+), 7 deletions(-)

diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index f3f84fb..2d86b10 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -925,10 +925,17 @@ static int omap2_dma_handle_ch(int ch)
 {
 	u32 status = OMAP_DMA_CSR_REG(ch);
 
-	if (!status)
+	if (!status) {
+		if (printk_ratelimit())
+			printk(KERN_WARNING "Spurious DMA IRQ for lch %d\n", ch);
 		return 0;
-	if (unlikely(dma_chan[ch].dev_id == -1))
+	}
+	if (unlikely(dma_chan[ch].dev_id == -1)) {
+		if (printk_ratelimit())
+			printk(KERN_WARNING "IRQ %04x for non-allocated DMA"
+					"channel %d\n", status, ch);
 		return 0;
+	}
 	if (unlikely(status & OMAP_DMA_DROP_IRQ))
 		printk(KERN_INFO
 		       "DMA synchronization event drop occurred with device "
@@ -959,11 +966,15 @@ static irqreturn_t omap2_dma_irq_handler(int irq, void *dev_id)
 	int i;
 
 	val = omap_readl(OMAP_DMA4_IRQSTATUS_L0);
-
-	for (i = 1; i <= OMAP_LOGICAL_DMA_CH_COUNT; i++) {
-		int active = val & (1 << (i - 1));
-		if (active)
-			omap2_dma_handle_ch(i - 1);
+	if (val == 0) {
+		if (printk_ratelimit())
+			printk(KERN_WARNING "Spurious DMA IRQ\n");
+		return IRQ_HANDLED;
+	}
+	for (i = 0; i < OMAP_LOGICAL_DMA_CH_COUNT && val != 0; i++) {
+		if (val & 1)
+			omap2_dma_handle_ch(i);
+		val >>= 1;
 	}
 
 	return IRQ_HANDLED;
-- 
1.4.4.2

[PATCH 4/90] ARM: OMAP: Enable 24xx GPIO autoidling

[Tony Lindgren]

From: Juha Yrjola <juha.yrjola@solidboot.com>

Enable 24xx GPIO autoidling

Signed-off-by: Juha Yrjola <juha.yrjola@solidboot.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 arch/arm/plat-omap/gpio.c |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index b8c01de..e2547a7 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -1083,6 +1083,10 @@ static int __init _omap_gpio_init(void)
 		if (bank->method == METHOD_GPIO_24XX) {
 			__raw_writel(0x00000000, bank->base + OMAP24XX_GPIO_IRQENABLE1);
 			__raw_writel(0xffffffff, bank->base + OMAP24XX_GPIO_IRQSTATUS1);
+			__raw_writew(0x0015, bank->base + OMAP24XX_GPIO_SYSCONFIG);
+
+			/* Initialize interface clock ungated, module enabled */
+			__raw_writel(0, bank->base + OMAP24XX_GPIO_CTRL);
 
 			gpio_count = 32;
 		}
@@ -1105,6 +1109,12 @@ static int __init _omap_gpio_init(void)
 	if (cpu_is_omap16xx())
 		omap_writel(omap_readl(ULPD_CAM_CLK_CTRL) | 0x04, ULPD_CAM_CLK_CTRL);
 
+#ifdef CONFIG_ARCH_OMAP24XX
+	/* Enable autoidle for the OCP interface */
+	if (cpu_is_omap24xx())
+		omap_writel(1 << 0, 0x48019010);
+#endif
+
 	return 0;
 }
 
-- 
1.4.4.2

[PATCH 5/90] ARM: OMAP: Add function to print clock usecounts

[Tony Lindgren]

From: Juha Yrjola <juha.yrjola@solidboot.com>

Useful for debugging power management code.

Signed-off-by: Juha Yrjola <juha.yrjola@solidboot.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 arch/arm/plat-omap/clock.c |   35 +++++++++++++++++++++++++++++++++++
 1 files changed, 35 insertions(+), 0 deletions(-)

diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c
index f1179ad..3d017b0 100644
--- a/arch/arm/plat-omap/clock.c
+++ b/arch/arm/plat-omap/clock.c
@@ -33,6 +33,41 @@ static DEFINE_SPINLOCK(clockfw_lock);
 
 static struct clk_functions *arch_clock;
 
+#ifdef CONFIG_PM_DEBUG
+
+static void print_parents(struct clk *clk)
+{
+	struct clk *p;
+	int printed = 0;
+
+	list_for_each_entry(p, &clocks, node) {
+		if (p->parent == clk && p->usecount) {
+			if (!clk->usecount && !printed) {
+				printk("MISMATCH: %s\n", clk->name);
+				printed = 1;
+			}
+			printk("\t%-15s\n", p->name);
+		}
+	}
+}
+
+void clk_print_usecounts(void)
+{
+	unsigned long flags;
+	struct clk *p;
+
+	spin_lock_irqsave(&clockfw_lock, flags);
+	list_for_each_entry(p, &clocks, node) {
+		if (p->usecount)
+			printk("%-15s: %d\n", p->name, p->usecount);
+		print_parents(p);
+
+	}
+	spin_unlock_irqrestore(&clockfw_lock, flags);
+}
+
+#endif
+
 /*-------------------------------------------------------------------------
  * Standard clock functions defined in include/linux/clk.h
  *-------------------------------------------------------------------------*/
-- 
1.4.4.2

[PATCH 6/90] ARM: OMAP: Enable serial idling and wakeup features

[Tony Lindgren]

From: Juha Yrjola <juha.yrjola@solidboot.com>

Enable serial idling and wakeup features

Signed-off-by: Juha Yrjola <juha.yrjola@solidboot.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 arch/arm/mach-omap2/serial.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index aaa5589..e9c367f 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -84,7 +84,7 @@ static inline void __init omap_serial_reset(struct plat_serial8250_port *p)
 	serial_write_reg(p, UART_OMAP_MDR1, 0x07);
 	serial_write_reg(p, UART_OMAP_SCR, 0x08);
 	serial_write_reg(p, UART_OMAP_MDR1, 0x00);
-	serial_write_reg(p, UART_OMAP_SYSC, 0x01);
+	serial_write_reg(p, UART_OMAP_SYSC, (0x02 << 3) | (1 << 2) | (1 << 0));
 }
 
 void __init omap_serial_init()
-- 
1.4.4.2

[PATCH 7/90] ARM: OMAP: Optimize INTC register accesses and enable autoidling

[Tony Lindgren]

From: Juha Yrjola <juha.yrjola@solidboot.com>

Use virtual addresses directly instead of physical addresses to
avoid having to recalculate the virtual address with every
register access.

Signed-off-by: Juha Yrjola <juha.yrjola@solidboot.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 arch/arm/mach-omap2/irq.c |   19 +++++++++++--------
 1 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
index a39d306..f064f72 100644
--- a/arch/arm/mach-omap2/irq.c
+++ b/arch/arm/mach-omap2/irq.c
@@ -37,7 +37,7 @@ static struct omap_irq_bank {
 } __attribute__ ((aligned(4))) irq_banks[] = {
 	{
 		/* MPU INTC */
-		.base_reg	= OMAP24XX_IC_BASE,
+		.base_reg	= IO_ADDRESS(OMAP24XX_IC_BASE),
 		.nr_irqs	= 96,
 	}, {
 		/* XXX: DSP INTC */
@@ -47,7 +47,7 @@ static struct omap_irq_bank {
 /* XXX: FIQ and additional INTC support (only MPU at the moment) */
 static void omap_ack_irq(unsigned int irq)
 {
-	omap_writel(0x1, irq_banks[0].base_reg + INTC_CONTROL);
+	__raw_writel(0x1, irq_banks[0].base_reg + INTC_CONTROL);
 }
 
 static void omap_mask_irq(unsigned int irq)
@@ -60,7 +60,7 @@ static void omap_mask_irq(unsigned int irq)
 		irq %= 32;
 	}
 
-	omap_writel(1 << irq, irq_banks[0].base_reg + INTC_MIR_SET0 + offset);
+	__raw_writel(1 << irq, irq_banks[0].base_reg + INTC_MIR_SET0 + offset);
 }
 
 static void omap_unmask_irq(unsigned int irq)
@@ -73,7 +73,7 @@ static void omap_unmask_irq(unsigned int irq)
 		irq %= 32;
 	}
 
-	omap_writel(1 << irq, irq_banks[0].base_reg + INTC_MIR_CLEAR0 + offset);
+	__raw_writel(1 << irq, irq_banks[0].base_reg + INTC_MIR_CLEAR0 + offset);
 }
 
 static void omap_mask_ack_irq(unsigned int irq)
@@ -93,17 +93,20 @@ static void __init omap_irq_bank_init_one(struct omap_irq_bank *bank)
 {
 	unsigned long tmp;
 
-	tmp = omap_readl(bank->base_reg + INTC_REVISION) & 0xff;
+	tmp = __raw_readl(bank->base_reg + INTC_REVISION) & 0xff;
 	printk(KERN_INFO "IRQ: Found an INTC at 0x%08lx "
 			 "(revision %ld.%ld) with %d interrupts\n",
 			 bank->base_reg, tmp >> 4, tmp & 0xf, bank->nr_irqs);
 
-	tmp = omap_readl(bank->base_reg + INTC_SYSCONFIG);
+	tmp = __raw_readl(bank->base_reg + INTC_SYSCONFIG);
 	tmp |= 1 << 1;	/* soft reset */
-	omap_writel(tmp, bank->base_reg + INTC_SYSCONFIG);
+	__raw_writel(tmp, bank->base_reg + INTC_SYSCONFIG);
 
-	while (!(omap_readl(bank->base_reg + INTC_SYSSTATUS) & 0x1))
+	while (!(__raw_readl(bank->base_reg + INTC_SYSSTATUS) & 0x1))
 		/* Wait for reset to complete */;
+
+	/* Enable autoidle */
+	__raw_writel(1 << 0, bank->base_reg + INTC_SYSCONFIG);
 }
 
 void __init omap_init_irq(void)
-- 
1.4.4.2

[PATCH 8/90] ARM: OMAP: FB: add controller platform data

[Tony Lindgren]

From: Imre Deak <imre.deak@solidboot.com>

Add controller platform data

Signed-off-by: Imre Deak <imre.deak@solidboot.com>
Signed-off-by: Juha Yrjola <juha.yrjola@solidboot.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 arch/arm/plat-omap/fb.c            |    5 +++++
 include/asm-arm/arch-omap/omapfb.h |    8 +++++---
 2 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/arch/arm/plat-omap/fb.c b/arch/arm/plat-omap/fb.c
index 56acb87..91ebdaf 100644
--- a/arch/arm/plat-omap/fb.c
+++ b/arch/arm/plat-omap/fb.c
@@ -55,6 +55,11 @@ void omapfb_reserve_mem(void)
 	}
 }
 
+void omapfb_set_ctrl_platform_data(void *data)
+{
+	omapfb_config.ctrl_platform_data = data;
+}
+
 static inline int omap_init_fb(void)
 {
 	const struct omap_lcd_config *conf;
diff --git a/include/asm-arm/arch-omap/omapfb.h b/include/asm-arm/arch-omap/omapfb.h
index fccdb3d..ce80a71 100644
--- a/include/asm-arm/arch-omap/omapfb.h
+++ b/include/asm-arm/arch-omap/omapfb.h
@@ -292,8 +292,9 @@ struct omapfb_device {
 };
 
 struct omapfb_platform_data {
-	struct omap_lcd_config   lcd;
-	struct omap_fbmem_config fbmem;
+	struct omap_lcd_config	lcd;
+	struct omapfb_mem_desc	mem_desc;
+	void			*ctrl_platform_data;
 };
 
 #define OMAPFB_EVENT_READY	1
@@ -317,8 +318,9 @@ extern int  omapfb_update_window_async(struct omapfb_update_window *win,
 					void (*callback)(void *),
 					void *callback_data);
 
-/* in arch/arm/plat-omap/devices.c */
+/* in arch/arm/plat-omap/fb.c */
 extern void omapfb_reserve_mem(void);
+extern void omapfb_set_ctrl_platform_data(void *pdata);
 
 #endif /* __KERNEL__ */
 
-- 
1.4.4.2

Re: [PATCH 0/90] Post 2.6.21 OMAP update

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [070404 14:02]:
> Hi all,
> 
> Attached is a rather large OMAP update for post 2.6.21.
> 
> OMAP is a series of ARM processors from Texas Instruments
> used in various cell phones and PDAs.
> 
> The patch series is based on code that has been brewing
> in the linux-omap tree since last fall.
> 
> We'd like to switch the linux-omap tree to use the mainline
> tree for core omap stuff, and this series attemps to do it
> for most part. 
> 
> As the patch series is big, Andrew Morton asked me to post
> it to LKML instead of linux-arm-kernel list for a wider review,
> so please comment on the patches if you have a chance!
> 
> The patches touch only omap specific code at:
> 
> arch/arm/Kconfig
> arch/arm/plat-omap
> arch/arm/mach-omap1
> arch/arm/mach-omap2
> include/asm-arm/arch-omap

Looks like using git-send-email --chain-reply-to with this many
messages is not a good idea... The threading gets nested too wide :)

For mutt users, changing the view temporarily can be done with:

:set sort=date

instead of

:set sort=threads

Regards,

Tony

Re: [PATCH 0/90] Post 2.6.21 OMAP update

[Randy Dunlap]

On Wed, 4 Apr 2007 14:27:30 -0400 Tony Lindgren wrote:

> * Tony Lindgren <tony@atomide.com> [070404 14:02]:
> > Hi all,
> > 
> > Attached is a rather large OMAP update for post 2.6.21.
> > 
> > OMAP is a series of ARM processors from Texas Instruments
> > used in various cell phones and PDAs.
> > 
> > The patch series is based on code that has been brewing
> > in the linux-omap tree since last fall.
> > 
> > We'd like to switch the linux-omap tree to use the mainline
> > tree for core omap stuff, and this series attemps to do it
> > for most part. 
> > 
> > As the patch series is big, Andrew Morton asked me to post
> > it to LKML instead of linux-arm-kernel list for a wider review,
> > so please comment on the patches if you have a chance!
> > 
> > The patches touch only omap specific code at:
> > 
> > arch/arm/Kconfig
> > arch/arm/plat-omap
> > arch/arm/mach-omap1
> > arch/arm/mach-omap2
> > include/asm-arm/arch-omap
> 
> Looks like using git-send-email --chain-reply-to with this many
> messages is not a good idea... The threading gets nested too wide :)

That's only a problem when there are <too many> patches to be
reviewed.  Hence, do more frequent postings of fewer patches per series.
That will likely also get you more reviewers.

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: [PATCH 0/90] Post 2.6.21 OMAP update

[Tony Lindgren]

* Randy Dunlap <randy.dunlap@oracle.com> [070404 14:37]:
> On Wed, 4 Apr 2007 14:27:30 -0400 Tony Lindgren wrote:
> 
> > * Tony Lindgren <tony@atomide.com> [070404 14:02]:
> > > Hi all,
> > > 
> > > Attached is a rather large OMAP update for post 2.6.21.
> > > 
> > > OMAP is a series of ARM processors from Texas Instruments
> > > used in various cell phones and PDAs.
> > > 
> > > The patch series is based on code that has been brewing
> > > in the linux-omap tree since last fall.
> > > 
> > > We'd like to switch the linux-omap tree to use the mainline
> > > tree for core omap stuff, and this series attemps to do it
> > > for most part. 
> > > 
> > > As the patch series is big, Andrew Morton asked me to post
> > > it to LKML instead of linux-arm-kernel list for a wider review,
> > > so please comment on the patches if you have a chance!
> > > 
> > > The patches touch only omap specific code at:
> > > 
> > > arch/arm/Kconfig
> > > arch/arm/plat-omap
> > > arch/arm/mach-omap1
> > > arch/arm/mach-omap2
> > > include/asm-arm/arch-omap
> > 
> > Looks like using git-send-email --chain-reply-to with this many
> > messages is not a good idea... The threading gets nested too wide :)
> 
> That's only a problem when there are <too many> patches to be
> reviewed.  Hence, do more frequent postings of fewer patches per series.
> That will likely also get you more reviewers.

Yeah, I agree.. We've already missed two merge windows because of the
large patch set :( The problem is that patch set just keeps growing.

Things should be to normal small patch sets once this pile is dealt
with.

Regards,

Tony

Re: [PATCH 0/90] Post 2.6.21 OMAP update

[Alan Cox]

> > That's only a problem when there are <too many> patches to be
> > reviewed.  Hence, do more frequent postings of fewer patches per series.
> > That will likely also get you more reviewers.
> 
> Yeah, I agree.. We've already missed two merge windows because of the
> large patch set :( The problem is that patch set just keeps growing.

The other problem is that GIT patch sets are completely useless for
merging and reviewing if you simply fire off a blast of 70 changesets.
Each time you do it at least one gets queried or a NAK and the lot go in
the bin again. Repeat 50 times...

It would be enormously helpful if instead we got say 15 small patch sets
which are independant so that a query or NAK means 14 sets get applied
this time around not zero.

Alan

Re: [PATCH 0/90] Post 2.6.21 OMAP update

[Tony Lindgren]

* Alan Cox <alan@lxorguk.ukuu.org.uk> [070404 17:42]:
> > > That's only a problem when there are <too many> patches to be
> > > reviewed.  Hence, do more frequent postings of fewer patches per series.
> > > That will likely also get you more reviewers.
> > 
> > Yeah, I agree.. We've already missed two merge windows because of the
> > large patch set :( The problem is that patch set just keeps growing.
> 
> The other problem is that GIT patch sets are completely useless for
> merging and reviewing if you simply fire off a blast of 70 changesets.
> Each time you do it at least one gets queried or a NAK and the lot go in
> the bin again. Repeat 50 times...

Yeah, it is also big pain to maintain patchset this large.

> It would be enormously helpful if instead we got say 15 small patch sets
> which are independant so that a query or NAK means 14 sets get applied
> this time around not zero.

I was thinking about merging the patches together more, but the end result
would not be very readable, and we would lose the original author info.

Also trying to do this 15 small patches at time would make it hard
to have it all integrated within the two week merge window.

It would be nice to get to a situation where we only have 10 - 20 small
linux-omap patches ready for every merge window, and then send fixes
during the -rc series.

Regards,

Tony

Re: [PATCH 0/90] Post 2.6.21 OMAP update

[Roland Dreier]

 > > It would be enormously helpful if instead we got say 15 small patch sets
 > > which are independant so that a query or NAK means 14 sets get applied
 > > this time around not zero.
 > 
 > I was thinking about merging the patches together more, but the end result
 > would not be very readable, and we would lose the original author info.
 > 
 > Also trying to do this 15 small patches at time would make it hard
 > to have it all integrated within the two week merge window.

I think you misunderstood the suggestion.  The idea is that you leave
the patches basically as-is (modulo any small tweaks required by
reordering), but rather than one 90-patch series, you divide the
patches up into independent subsets.  Maybe something like

 - basic OMAP fixes for bugs in core support
 - Palm platform stuff
 - ...other platform stuff
 - new features

etc.  then it's easier for people to review the stuff they're
interested in, and it's easier for at least some of the subsets to get
applied (which reduces your backlog).

 - R.

Re: [PATCH 0/90] Post 2.6.21 OMAP update

[Tony Lindgren]

* Roland Dreier <rdreier@cisco.com> [070405 12:32]:
>  > > It would be enormously helpful if instead we got say 15 small patch sets
>  > > which are independant so that a query or NAK means 14 sets get applied
>  > > this time around not zero.
>  > 
>  > I was thinking about merging the patches together more, but the end result
>  > would not be very readable, and we would lose the original author info.
>  > 
>  > Also trying to do this 15 small patches at time would make it hard
>  > to have it all integrated within the two week merge window.
> 
> I think you misunderstood the suggestion.  The idea is that you leave
> the patches basically as-is (modulo any small tweaks required by
> reordering), but rather than one 90-patch series, you divide the
> patches up into independent subsets.  Maybe something like
> 
>  - basic OMAP fixes for bugs in core support
>  - Palm platform stuff
>  - ...other platform stuff
>  - new features
> 
> etc.  then it's easier for people to review the stuff they're
> interested in, and it's easier for at least some of the subsets to get
> applied (which reduces your backlog).

Hmm, yeah I'll see if I could group them a bit. The problem there
is that the patch series contains multiple rounds of "add and fix"
cycles. Pretty much all the non-dependant fixes have already been
applied, BTW.

Tony

Re: [PATCH 0/90] Post 2.6.21 OMAP update

[Roland Dreier]

 > Hmm, yeah I'll see if I could group them a bit. The problem there
 > is that the patch series contains multiple rounds of "add and fix"
 > cycles. Pretty much all the non-dependant fixes have already been
 > applied, BTW.

I think it's nice to roll up fixes into patches that haven't been
merged upstream yet.  For example I try to avoid merging series like

  Add feature A
  Add feature B
  Fix 1 for feature A
  Fix 2 for feature A
  Fix for fix 1 for feature A

because that means I already knew the first patch was broken before it
ever got merged.  And it's better to avoid setting any more booby
traps for people trying to use git bisect or something like
that... enough bugs get merged by accident without us merging known
bugs.  So before I merge, I go back and create a new series like

  Add fixed feature A
  Add feature B

 - R.

Re: [PATCH 0/90] Post 2.6.21 OMAP update

[Tony Lindgren]

* Roland Dreier <rdreier@cisco.com> [070405 14:29]:
>  > Hmm, yeah I'll see if I could group them a bit. The problem there
>  > is that the patch series contains multiple rounds of "add and fix"
>  > cycles. Pretty much all the non-dependant fixes have already been
>  > applied, BTW.
> 
> I think it's nice to roll up fixes into patches that haven't been
> merged upstream yet.  For example I try to avoid merging series like
> 
>   Add feature A
>   Add feature B
>   Fix 1 for feature A
>   Fix 2 for feature A
>   Fix for fix 1 for feature A
> 
> because that means I already knew the first patch was broken before it
> ever got merged.  And it's better to avoid setting any more booby
> traps for people trying to use git bisect or something like
> that... enough bugs get merged by accident without us merging known
> bugs.  So before I merge, I go back and create a new series like
> 
>   Add fixed feature A
>   Add feature B

OK, done and reposted. Your suggestion got the following fixes merged
into other patches:

0022-ARM-OMAP-Fix-Amstrad-Delta-omap-keypad-usage.txt
0023-ARM-OMAP-PalmZ71-extra-brace-fix.txt
0024-ARM-OMAP-Fix-typo-in-gpio.txt
0030-ARM-OMAP-Palm-Zire71-minor-fixes.txt
0033-ARM-OMAP-This-patch-enables-I2C-2-support-for-2430-SDP.txt
0034-ARM-OMAP-Set-keypad-sense-delays-for-the-Palms.txt
0048-ARM-OMAP-I2C-1-init-fix-for-2430.txt
0049-ARM-OMAP-update-board-2430-file-for-TWL-PIH-interrupts.txt
0050-ARM-OMAP-board-sdp2430.c-Remove-unnecessary-includes.txt
0056-ARM-OMAP-Make-board-palmz71-compile-again.txt
0058-ARM-OMAP-musb_hdrc-tusb-dma-patch-minor.txt
0064-ARM-OMAP-Fix-warning-in-pm.c.txt
0065-ARM-OMAP-Convert-interrupt-flags-SA_-to-IRQF_.txt
0073-ARM-OMAP-Add-onennand-board-specific-support-for-N800.txt
0074-ARM-OMAP-N800-Update-board-specific-audio-support.txt
0079-ARM-OMAP-fix-H4-dependencies-again.txt
0081-ARM-OMAP-omap2-pm.c-build-fix.txt
0084-ARM-OMAP-Update-changed-TSC2301-config-names-in-N800-board-files.txt
0089-ARM-OMAP-Activate-MPU-retention-code-in-omap2-pm.c.txt

I also split 0040-ARM-OMAP-Sync-board-specific-files-with-linux-omap.txt
into two patches, one for OMAP1 and one for OMAP2.

So now there are somewhat smaller mountain of patches :)

Regards,

Tony

Re: [PATCH 0/90] Post 2.6.21 OMAP update

[Alan Cox]

> Hmm, yeah I'll see if I could group them a bit. The problem there
> is that the patch series contains multiple rounds of "add and fix"
> cycles. Pretty much all the non-dependant fixes have already been
> applied, BTW.

Bear in mind that it doesn't work now, so merging some stuff and being in
a "more merged but still not yet a tree to build OMAP from" is not a
regression or a problem.

Going back some time the PA-RISC merge occurred over several months until
one day it was all there.

Alan

Re: [PATCH 0/90] Post 2.6.21 OMAP update

[Russell King]

On Thu, Apr 05, 2007 at 09:27:13PM +0100, Alan Cox wrote:
> > Hmm, yeah I'll see if I could group them a bit. The problem there
> > is that the patch series contains multiple rounds of "add and fix"
> > cycles. Pretty much all the non-dependant fixes have already been
> > applied, BTW.
> 
> Bear in mind that it doesn't work now, so merging some stuff and being in
> a "more merged but still not yet a tree to build OMAP from" is not a
> regression or a problem.
> 
> Going back some time the PA-RISC merge occurred over several months until
> one day it was all there.

I think Tony's problem is the volume of changes though - I think it is
fair to say that in 2.6.18 it was fully merged and working.

Since then, for one reason or another the merge windows got missed (ISTR
it was triggered due to me not being able to devote the full 14 days to
kernel work during the 2.6.19 merge window due to going on holiday) which
has resulted in subsequent merge windows being missed, and therefore the
number of changes increasing and the problem Tony's now in.

In that respect, if it no longer "work"s now, it's technically a
regression.

Clearly the real solution is for rmk never to go on holiday during a
merge window, but I don't personally find that acceptable.  Or maybe
human cloning, but I'm sure there's people here who think that one rmk
is enough. ;)

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: [PATCH 0/90] Post 2.6.21 OMAP update

[Tony Lindgren]

Hi,

* Russell King <rmk+lkml@arm.linux.org.uk> [070406 03:19]:
> On Thu, Apr 05, 2007 at 09:27:13PM +0100, Alan Cox wrote:
> > > Hmm, yeah I'll see if I could group them a bit. The problem there
> > > is that the patch series contains multiple rounds of "add and fix"
> > > cycles. Pretty much all the non-dependant fixes have already been
> > > applied, BTW.
> > 
> > Bear in mind that it doesn't work now, so merging some stuff and being in
> > a "more merged but still not yet a tree to build OMAP from" is not a
> > regression or a problem.
> > 
> > Going back some time the PA-RISC merge occurred over several months until
> > one day it was all there.
> 
> I think Tony's problem is the volume of changes though - I think it is
> fair to say that in 2.6.18 it was fully merged and working.
> 
> Since then, for one reason or another the merge windows got missed (ISTR
> it was triggered due to me not being able to devote the full 14 days to
> kernel work during the 2.6.19 merge window due to going on holiday) which
> has resulted in subsequent merge windows being missed, and therefore the
> number of changes increasing and the problem Tony's now in.
> 
> In that respect, if it no longer "work"s now, it's technically a
> regression.

Yeah, it works, but the current omap code in the mainline kernel is still
mostly at 2.6.18 level like you mentioned.

> Clearly the real solution is for rmk never to go on holiday during a
> merge window, but I don't personally find that acceptable.  Or maybe
> human cloning, but I'm sure there's people here who think that one rmk
> is enough. ;)

Or maybe there should be a two week common code and interface merge
window, then another two weeks for merging board and driver specific
stuff?

That would make it easier to update the board and driver specific
patches to the common code and interface changes first before they
are submitted.

Regards,

Tony