* linux-next: manual merge of the async_tx tree with the arm tree
@ 2009-03-16 4:10 Stephen Rothwell
2009-03-16 22:18 ` Dan Williams
0 siblings, 1 reply; 11+ messages in thread
From: Stephen Rothwell @ 2009-03-16 4:10 UTC (permalink / raw)
To: Dan Williams, Russell King
Cc: linux-next, Sascha Hauer, Guennadi Liakhovetski
Hi Dan, Russell,
Today's linux-next merge of the async_tx tree got a conflict in
drivers/video/mx3fb.c between commit
9eb2eb8c40ffd30da322648c4415bae0288eb167 ("MX31 clkdev support") from the
arm tree and commits 1febd91acff907152e61eb5ad0a82dd8d7db21c6 ("Revert
"i.MX31: framebuffer driver"") and
6e1588cbd88590273300403648aef70e6bdaf5af ("i.MX31: framebuffer driver")
from the async_tx tree.
I fixed it up (see below) and can carry the fix as necessary).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
diff --cc drivers/video/mx3fb.c
index 0c27961,3e84635..0000000
--- a/drivers/video/mx3fb.c
+++ b/drivers/video/mx3fb.c
@@@ -412,162 -412,162 +412,162 @@@ static int sdc_set_window_pos(struct mx
/**
* sdc_init_panel() - initialize a synchronous LCD panel.
- * @mx3fb: mx3fb context.
- * @panel: panel type.
- * @pixel_clk: desired pixel clock frequency in Hz.
- * @width: width of panel in pixels.
- * @height: height of panel in pixels.
- * @pixel_fmt: pixel format of buffer as FOURCC ASCII code.
- * @h_start_width: number of pixel clocks between the HSYNC signal pulse
- * and the start of valid data.
- * @h_sync_width: width of the HSYNC signal in units of pixel clocks.
- * @h_end_width: number of pixel clocks between the end of valid data
- * and the HSYNC signal for next line.
- * @v_start_width: number of lines between the VSYNC signal pulse and the
- * start of valid data.
- * @v_sync_width: width of the VSYNC signal in units of lines
- * @v_end_width: number of lines between the end of valid data and the
- * VSYNC signal for next frame.
- * @sig: bitfield of signal polarities for LCD interface.
- * @return: 0 on success or negative error code on failure.
+ * @mx3fb: mx3fb context.
+ * @panel: panel type.
+ * @pixel_clk: desired pixel clock frequency in Hz.
+ * @width: width of panel in pixels.
+ * @height: height of panel in pixels.
+ * @pixel_fmt: pixel format of buffer as FOURCC ASCII code.
+ * @h_start_width: number of pixel clocks between the HSYNC signal pulse
+ * and the start of valid data.
+ * @h_sync_width: width of the HSYNC signal in units of pixel clocks.
+ * @h_end_width: number of pixel clocks between the end of valid data
+ * and the HSYNC signal for next line.
+ * @v_start_width: number of lines between the VSYNC signal pulse and the
+ * start of valid data.
+ * @v_sync_width: width of the VSYNC signal in units of lines
+ * @v_end_width: number of lines between the end of valid data and the
+ * VSYNC signal for next frame.
+ * @sig: bitfield of signal polarities for LCD interface.
+ * @return: 0 on success or negative error code on failure.
*/
static int sdc_init_panel(struct mx3fb_data *mx3fb, enum ipu_panel panel,
- uint32_t pixel_clk,
- uint16_t width, uint16_t height,
- enum pixel_fmt pixel_fmt,
- uint16_t h_start_width, uint16_t h_sync_width,
- uint16_t h_end_width, uint16_t v_start_width,
- uint16_t v_sync_width, uint16_t v_end_width,
- struct ipu_di_signal_cfg sig)
+ uint32_t pixel_clk,
+ uint16_t width, uint16_t height,
+ enum pixel_fmt pixel_fmt,
+ uint16_t h_start_width, uint16_t h_sync_width,
+ uint16_t h_end_width, uint16_t v_start_width,
+ uint16_t v_sync_width, uint16_t v_end_width,
+ struct ipu_di_signal_cfg sig)
{
- unsigned long lock_flags;
- uint32_t reg;
- uint32_t old_conf;
- uint32_t div;
- struct clk *ipu_clk;
+ unsigned long lock_flags;
+ uint32_t reg;
+ uint32_t old_conf;
+ uint32_t div;
+ struct clk *ipu_clk;
- dev_dbg(mx3fb->dev, "panel size = %d x %d", width, height);
+ dev_dbg(mx3fb->dev, "panel size = %d x %d", width, height);
- if (v_sync_width == 0 || h_sync_width == 0)
- return -EINVAL;
+ if (v_sync_width == 0 || h_sync_width == 0)
+ return -EINVAL;
- /* Init panel size and blanking periods */
- reg = ((uint32_t) (h_sync_width - 1) << 26) |
- ((uint32_t) (width + h_start_width + h_end_width - 1) << 16);
- mx3fb_write_reg(mx3fb, reg, SDC_HOR_CONF);
+ /* Init panel size and blanking periods */
+ reg = ((uint32_t) (h_sync_width - 1) << 26) |
+ ((uint32_t) (width + h_start_width + h_end_width - 1) << 16);
+ mx3fb_write_reg(mx3fb, reg, SDC_HOR_CONF);
#ifdef DEBUG
- printk(KERN_CONT " hor_conf %x,", reg);
+ printk(KERN_CONT " hor_conf %x,", reg);
#endif
- reg = ((uint32_t) (v_sync_width - 1) << 26) | SDC_V_SYNC_WIDTH_L |
- ((uint32_t) (height + v_start_width + v_end_width - 1) << 16);
- mx3fb_write_reg(mx3fb, reg, SDC_VER_CONF);
+ reg = ((uint32_t) (v_sync_width - 1) << 26) | SDC_V_SYNC_WIDTH_L |
+ ((uint32_t) (height + v_start_width + v_end_width - 1) << 16);
+ mx3fb_write_reg(mx3fb, reg, SDC_VER_CONF);
#ifdef DEBUG
- printk(KERN_CONT " ver_conf %x\n", reg);
+ printk(KERN_CONT " ver_conf %x\n", reg);
#endif
- mx3fb->h_start_width = h_start_width;
- mx3fb->v_start_width = v_start_width;
-
- switch (panel) {
- case IPU_PANEL_SHARP_TFT:
- mx3fb_write_reg(mx3fb, 0x00FD0102L, SDC_SHARP_CONF_1);
- mx3fb_write_reg(mx3fb, 0x00F500F4L, SDC_SHARP_CONF_2);
- mx3fb_write_reg(mx3fb, SDC_COM_SHARP | SDC_COM_TFT_COLOR, SDC_COM_CONF);
- break;
- case IPU_PANEL_TFT:
- mx3fb_write_reg(mx3fb, SDC_COM_TFT_COLOR, SDC_COM_CONF);
- break;
- default:
- return -EINVAL;
- }
-
- /* Init clocking */
-
- /*
- * Calculate divider: fractional part is 4 bits so simply multiple by
- * 24 to get fractional part, as long as we stay under ~250MHz and on
- * i.MX31 it (HSP_CLK) is <= 178MHz. Currently 128.267MHz
- */
- dev_dbg(mx3fb->dev, "pixel clk = %d\n", pixel_clk);
-
- ipu_clk = clk_get(mx3fb->dev, NULL);
- div = clk_get_rate(ipu_clk) * 16 / pixel_clk;
- clk_put(ipu_clk);
-
- if (div < 0x40) { /* Divider less than 4 */
- dev_dbg(mx3fb->dev,
- "InitPanel() - Pixel clock divider less than 4\n");
- div = 0x40;
- }
-
- spin_lock_irqsave(&mx3fb->lock, lock_flags);
-
- /*
- * DISP3_IF_CLK_DOWN_WR is half the divider value and 2 fraction bits
- * fewer. Subtract 1 extra from DISP3_IF_CLK_DOWN_WR based on timing
- * debug. DISP3_IF_CLK_UP_WR is 0
- */
- mx3fb_write_reg(mx3fb, (((div / 8) - 1) << 22) | div, DI_DISP3_TIME_CONF);
-
- /* DI settings */
- old_conf = mx3fb_read_reg(mx3fb, DI_DISP_IF_CONF) & 0x78FFFFFF;
- old_conf |= sig.datamask_en << DI_D3_DATAMSK_SHIFT |
- sig.clksel_en << DI_D3_CLK_SEL_SHIFT |
- sig.clkidle_en << DI_D3_CLK_IDLE_SHIFT;
- mx3fb_write_reg(mx3fb, old_conf, DI_DISP_IF_CONF);
-
- old_conf = mx3fb_read_reg(mx3fb, DI_DISP_SIG_POL) & 0xE0FFFFFF;
- old_conf |= sig.data_pol << DI_D3_DATA_POL_SHIFT |
- sig.clk_pol << DI_D3_CLK_POL_SHIFT |
- sig.enable_pol << DI_D3_DRDY_SHARP_POL_SHIFT |
- sig.Hsync_pol << DI_D3_HSYNC_POL_SHIFT |
- sig.Vsync_pol << DI_D3_VSYNC_POL_SHIFT;
- mx3fb_write_reg(mx3fb, old_conf, DI_DISP_SIG_POL);
-
- switch (pixel_fmt) {
- case IPU_PIX_FMT_RGB24:
- mx3fb_write_reg(mx3fb, di_mappings[0], DI_DISP3_B0_MAP);
- mx3fb_write_reg(mx3fb, di_mappings[1], DI_DISP3_B1_MAP);
- mx3fb_write_reg(mx3fb, di_mappings[2], DI_DISP3_B2_MAP);
- mx3fb_write_reg(mx3fb, mx3fb_read_reg(mx3fb, DI_DISP_ACC_CC) |
- ((di_mappings[3] - 1) << 12), DI_DISP_ACC_CC);
- break;
- case IPU_PIX_FMT_RGB666:
- mx3fb_write_reg(mx3fb, di_mappings[4], DI_DISP3_B0_MAP);
- mx3fb_write_reg(mx3fb, di_mappings[5], DI_DISP3_B1_MAP);
- mx3fb_write_reg(mx3fb, di_mappings[6], DI_DISP3_B2_MAP);
- mx3fb_write_reg(mx3fb, mx3fb_read_reg(mx3fb, DI_DISP_ACC_CC) |
- ((di_mappings[7] - 1) << 12), DI_DISP_ACC_CC);
- break;
- case IPU_PIX_FMT_BGR666:
- mx3fb_write_reg(mx3fb, di_mappings[8], DI_DISP3_B0_MAP);
- mx3fb_write_reg(mx3fb, di_mappings[9], DI_DISP3_B1_MAP);
- mx3fb_write_reg(mx3fb, di_mappings[10], DI_DISP3_B2_MAP);
- mx3fb_write_reg(mx3fb, mx3fb_read_reg(mx3fb, DI_DISP_ACC_CC) |
- ((di_mappings[11] - 1) << 12), DI_DISP_ACC_CC);
- break;
- default:
- mx3fb_write_reg(mx3fb, di_mappings[12], DI_DISP3_B0_MAP);
- mx3fb_write_reg(mx3fb, di_mappings[13], DI_DISP3_B1_MAP);
- mx3fb_write_reg(mx3fb, di_mappings[14], DI_DISP3_B2_MAP);
- mx3fb_write_reg(mx3fb, mx3fb_read_reg(mx3fb, DI_DISP_ACC_CC) |
- ((di_mappings[15] - 1) << 12), DI_DISP_ACC_CC);
- break;
- }
-
- spin_unlock_irqrestore(&mx3fb->lock, lock_flags);
-
- dev_dbg(mx3fb->dev, "DI_DISP_IF_CONF = 0x%08X\n",
- mx3fb_read_reg(mx3fb, DI_DISP_IF_CONF));
- dev_dbg(mx3fb->dev, "DI_DISP_SIG_POL = 0x%08X\n",
- mx3fb_read_reg(mx3fb, DI_DISP_SIG_POL));
- dev_dbg(mx3fb->dev, "DI_DISP3_TIME_CONF = 0x%08X\n",
- mx3fb_read_reg(mx3fb, DI_DISP3_TIME_CONF));
-
- return 0;
+ mx3fb->h_start_width = h_start_width;
+ mx3fb->v_start_width = v_start_width;
+
+ switch (panel) {
+ case IPU_PANEL_SHARP_TFT:
+ mx3fb_write_reg(mx3fb, 0x00FD0102L, SDC_SHARP_CONF_1);
+ mx3fb_write_reg(mx3fb, 0x00F500F4L, SDC_SHARP_CONF_2);
+ mx3fb_write_reg(mx3fb, SDC_COM_SHARP | SDC_COM_TFT_COLOR, SDC_COM_CONF);
+ break;
+ case IPU_PANEL_TFT:
+ mx3fb_write_reg(mx3fb, SDC_COM_TFT_COLOR, SDC_COM_CONF);
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ /* Init clocking */
+
+ /*
+ * Calculate divider: fractional part is 4 bits so simply multiple by
+ * 2^4 to get fractional part, as long as we stay under ~250MHz and on
+ * i.MX31 it (HSP_CLK) is <= 178MHz. Currently 128.267MHz
+ */
+ dev_dbg(mx3fb->dev, "pixel clk = %d\n", pixel_clk);
+
- ipu_clk = clk_get(mx3fb->dev, "ipu_clk");
++ ipu_clk = clk_get(mx3fb->dev, NULL);
+ div = clk_get_rate(ipu_clk) * 16 / pixel_clk;
+ clk_put(ipu_clk);
+
+ if (div < 0x40) { /* Divider less than 4 */
+ dev_dbg(mx3fb->dev,
+ "InitPanel() - Pixel clock divider less than 4\n");
+ div = 0x40;
+ }
+
+ spin_lock_irqsave(&mx3fb->lock, lock_flags);
+
+ /*
+ * DISP3_IF_CLK_DOWN_WR is half the divider value and 2 fraction bits
+ * fewer. Subtract 1 extra from DISP3_IF_CLK_DOWN_WR based on timing
+ * debug. DISP3_IF_CLK_UP_WR is 0
+ */
+ mx3fb_write_reg(mx3fb, (((div / 8) - 1) << 22) | div, DI_DISP3_TIME_CONF);
+
+ /* DI settings */
+ old_conf = mx3fb_read_reg(mx3fb, DI_DISP_IF_CONF) & 0x78FFFFFF;
+ old_conf |= sig.datamask_en << DI_D3_DATAMSK_SHIFT |
+ sig.clksel_en << DI_D3_CLK_SEL_SHIFT |
+ sig.clkidle_en << DI_D3_CLK_IDLE_SHIFT;
+ mx3fb_write_reg(mx3fb, old_conf, DI_DISP_IF_CONF);
+
+ old_conf = mx3fb_read_reg(mx3fb, DI_DISP_SIG_POL) & 0xE0FFFFFF;
+ old_conf |= sig.data_pol << DI_D3_DATA_POL_SHIFT |
+ sig.clk_pol << DI_D3_CLK_POL_SHIFT |
+ sig.enable_pol << DI_D3_DRDY_SHARP_POL_SHIFT |
+ sig.Hsync_pol << DI_D3_HSYNC_POL_SHIFT |
+ sig.Vsync_pol << DI_D3_VSYNC_POL_SHIFT;
+ mx3fb_write_reg(mx3fb, old_conf, DI_DISP_SIG_POL);
+
+ switch (pixel_fmt) {
+ case IPU_PIX_FMT_RGB24:
+ mx3fb_write_reg(mx3fb, di_mappings[0], DI_DISP3_B0_MAP);
+ mx3fb_write_reg(mx3fb, di_mappings[1], DI_DISP3_B1_MAP);
+ mx3fb_write_reg(mx3fb, di_mappings[2], DI_DISP3_B2_MAP);
+ mx3fb_write_reg(mx3fb, mx3fb_read_reg(mx3fb, DI_DISP_ACC_CC) |
+ ((di_mappings[3] - 1) << 12), DI_DISP_ACC_CC);
+ break;
+ case IPU_PIX_FMT_RGB666:
+ mx3fb_write_reg(mx3fb, di_mappings[4], DI_DISP3_B0_MAP);
+ mx3fb_write_reg(mx3fb, di_mappings[5], DI_DISP3_B1_MAP);
+ mx3fb_write_reg(mx3fb, di_mappings[6], DI_DISP3_B2_MAP);
+ mx3fb_write_reg(mx3fb, mx3fb_read_reg(mx3fb, DI_DISP_ACC_CC) |
+ ((di_mappings[7] - 1) << 12), DI_DISP_ACC_CC);
+ break;
+ case IPU_PIX_FMT_BGR666:
+ mx3fb_write_reg(mx3fb, di_mappings[8], DI_DISP3_B0_MAP);
+ mx3fb_write_reg(mx3fb, di_mappings[9], DI_DISP3_B1_MAP);
+ mx3fb_write_reg(mx3fb, di_mappings[10], DI_DISP3_B2_MAP);
+ mx3fb_write_reg(mx3fb, mx3fb_read_reg(mx3fb, DI_DISP_ACC_CC) |
+ ((di_mappings[11] - 1) << 12), DI_DISP_ACC_CC);
+ break;
+ default:
+ mx3fb_write_reg(mx3fb, di_mappings[12], DI_DISP3_B0_MAP);
+ mx3fb_write_reg(mx3fb, di_mappings[13], DI_DISP3_B1_MAP);
+ mx3fb_write_reg(mx3fb, di_mappings[14], DI_DISP3_B2_MAP);
+ mx3fb_write_reg(mx3fb, mx3fb_read_reg(mx3fb, DI_DISP_ACC_CC) |
+ ((di_mappings[15] - 1) << 12), DI_DISP_ACC_CC);
+ break;
+ }
+
+ spin_unlock_irqrestore(&mx3fb->lock, lock_flags);
+
+ dev_dbg(mx3fb->dev, "DI_DISP_IF_CONF = 0x%08X\n",
+ mx3fb_read_reg(mx3fb, DI_DISP_IF_CONF));
+ dev_dbg(mx3fb->dev, "DI_DISP_SIG_POL = 0x%08X\n",
+ mx3fb_read_reg(mx3fb, DI_DISP_SIG_POL));
+ dev_dbg(mx3fb->dev, "DI_DISP3_TIME_CONF = 0x%08X\n",
+ mx3fb_read_reg(mx3fb, DI_DISP3_TIME_CONF));
+
+ return 0;
}
/**
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: linux-next: manual merge of the async_tx tree with the arm tree
2009-03-16 4:10 linux-next: manual merge of the async_tx tree with the arm tree Stephen Rothwell
@ 2009-03-16 22:18 ` Dan Williams
2009-03-16 22:28 ` Russell King
0 siblings, 1 reply; 11+ messages in thread
From: Dan Williams @ 2009-03-16 22:18 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Russell King, linux-next@vger.kernel.org, Sascha Hauer,
Guennadi Liakhovetski
On Sun, 2009-03-15 at 21:10 -0700, Stephen Rothwell wrote:
> Hi Dan, Russell,
>
> Today's linux-next merge of the async_tx tree got a conflict in
> drivers/video/mx3fb.c between commit
> 9eb2eb8c40ffd30da322648c4415bae0288eb167 ("MX31 clkdev support") from the
> arm tree and commits 1febd91acff907152e61eb5ad0a82dd8d7db21c6 ("Revert
> "i.MX31: framebuffer driver"") and
> 6e1588cbd88590273300403648aef70e6bdaf5af ("i.MX31: framebuffer driver")
> from the async_tx tree.
>
> I fixed it up (see below) and can carry the fix as necessary).
> --
> Cheers,
> Stephen Rothwell sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/
Thanks Stephen!
Russell, if you are merging other changes for this driver it makes sense
for the tabs-to-space fix to go in through your tree as well. If you
agree please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/djbw/async_tx.git imx-fb-fix
...to receive:
Dan Williams (1):
Revert "i.MX31: framebuffer driver"
Guennadi Liakhovetski (1):
i.MX31: framebuffer driver
arch/arm/plat-mxc/include/mach/mx3fb.h | 26 +-
drivers/video/Kconfig | 20 +-
drivers/video/Makefile | 2 +-
drivers/video/mx3fb.c | 2300 ++++++++++++++++----------------
4 files changed, 1174 insertions(+), 1174 deletions(-)
Thanks,
Dan
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: linux-next: manual merge of the async_tx tree with the arm tree
2009-03-16 22:18 ` Dan Williams
@ 2009-03-16 22:28 ` Russell King
2009-03-16 23:12 ` Stephen Rothwell
0 siblings, 1 reply; 11+ messages in thread
From: Russell King @ 2009-03-16 22:28 UTC (permalink / raw)
To: Dan Williams
Cc: Stephen Rothwell, linux-next@vger.kernel.org, Sascha Hauer,
Guennadi Liakhovetski
On Mon, Mar 16, 2009 at 03:18:07PM -0700, Dan Williams wrote:
> On Sun, 2009-03-15 at 21:10 -0700, Stephen Rothwell wrote:
> > Hi Dan, Russell,
> >
> > Today's linux-next merge of the async_tx tree got a conflict in
> > drivers/video/mx3fb.c between commit
> > 9eb2eb8c40ffd30da322648c4415bae0288eb167 ("MX31 clkdev support") from the
> > arm tree and commits 1febd91acff907152e61eb5ad0a82dd8d7db21c6 ("Revert
> > "i.MX31: framebuffer driver"") and
> > 6e1588cbd88590273300403648aef70e6bdaf5af ("i.MX31: framebuffer driver")
> > from the async_tx tree.
> >
> > I fixed it up (see below) and can carry the fix as necessary).
> > --
> > Cheers,
> > Stephen Rothwell sfr@canb.auug.org.au
> > http://www.canb.auug.org.au/~sfr/
>
> Thanks Stephen!
>
> Russell, if you are merging other changes for this driver it makes sense
> for the tabs-to-space fix to go in through your tree as well. If you
> agree please pull from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/djbw/async_tx.git imx-fb-fix
Pulled.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: linux-next: manual merge of the async_tx tree with the arm tree
2009-03-16 22:28 ` Russell King
@ 2009-03-16 23:12 ` Stephen Rothwell
0 siblings, 0 replies; 11+ messages in thread
From: Stephen Rothwell @ 2009-03-16 23:12 UTC (permalink / raw)
To: Russell King
Cc: Dan Williams, linux-next@vger.kernel.org, Sascha Hauer,
Guennadi Liakhovetski
[-- Attachment #1: Type: text/plain, Size: 501 bytes --]
Hi Russell,
On Mon, 16 Mar 2009 22:28:22 +0000 Russell King <rmk@arm.linux.org.uk> wrote:
>
> > Russell, if you are merging other changes for this driver it makes sense
> > for the tabs-to-space fix to go in through your tree as well. If you
> > agree please pull from:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/djbw/async_tx.git imx-fb-fix
>
> Pulled.
Thanks.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* linux-next: manual merge of the async_tx tree with the arm tree
@ 2010-07-27 2:08 Stephen Rothwell
2010-07-28 3:58 ` Rabin VINCENT
2010-07-28 7:11 ` Dan Williams
0 siblings, 2 replies; 11+ messages in thread
From: Stephen Rothwell @ 2010-07-27 2:08 UTC (permalink / raw)
To: Dan Williams
Cc: linux-next, linux-kernel, Rabin Vincent, Russell King,
Jonas Aaberg, Linus Walleij
Hi Dan,
Today's linux-next merge of the async_tx tree got a conflict in
arch/arm/mach-ux500/devices-db8500.c between commit
6055930cba8fdb2c8855b32bae262aaf69c1fdb4 ("ARM: 6266/1: ux500: add
separate irq lists for DB8500 and DB5500") from the arm tree and commit
5aa12e8c9c57741606e52f43e62ab1b9dc8e9dcc ("DMAENGINE: ste_dma40: arch
updates for LCLA and LCPA") from the async_tx tree.
I fixed it up (I think - see below) and can carry the fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc arch/arm/mach-ux500/devices-db8500.c
index 654fca9,c62cdbe..0000000
--- a/arch/arm/mach-ux500/devices-db8500.c
+++ b/arch/arm/mach-ux500/devices-db8500.c
@@@ -119,20 -119,15 +119,15 @@@ static struct resource dma40_resources[
},
[1] = {
.start = U8500_DMA_LCPA_BASE,
- .end = U8500_DMA_LCPA_BASE + SZ_4K - 1,
+ .end = U8500_DMA_LCPA_BASE + 2 * SZ_1K - 1,
.flags = IORESOURCE_MEM,
- .name = "lcpa",
+ .name = "lcpa",
},
[2] = {
- .start = U8500_DMA_LCLA_BASE,
- .end = U8500_DMA_LCLA_BASE + 16 * 1024 - 1,
- .flags = IORESOURCE_MEM,
- .name = "lcla",
- },
- [3] = {
- .start = IRQ_DMA,
- .end = IRQ_DMA,
+ .start = IRQ_DB8500_DMA,
+ .end = IRQ_DB8500_DMA,
- .flags = IORESOURCE_IRQ}
+ .flags = IORESOURCE_IRQ,
+ }
};
/* Default configuration for physcial memcpy */
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: linux-next: manual merge of the async_tx tree with the arm tree
2010-07-27 2:08 Stephen Rothwell
@ 2010-07-28 3:58 ` Rabin VINCENT
2010-07-28 4:43 ` Stephen Rothwell
2010-07-28 7:11 ` Dan Williams
1 sibling, 1 reply; 11+ messages in thread
From: Rabin VINCENT @ 2010-07-28 3:58 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Dan Williams, linux-next@vger.kernel.org,
linux-kernel@vger.kernel.org, Russell King, Jonas ABERG,
Linus WALLEIJ
Hi Stephen,
On Tue, Jul 27, 2010 at 04:08:05 +0200, Stephen Rothwell wrote:
> Today's linux-next merge of the async_tx tree got a conflict in
> arch/arm/mach-ux500/devices-db8500.c between commit
> 6055930cba8fdb2c8855b32bae262aaf69c1fdb4 ("ARM: 6266/1: ux500: add
> separate irq lists for DB8500 and DB5500") from the arm tree and commit
> 5aa12e8c9c57741606e52f43e62ab1b9dc8e9dcc ("DMAENGINE: ste_dma40: arch
> updates for LCLA and LCPA") from the async_tx tree.
>
> I fixed it up (I think - see below) and can carry the fix as necessary.
The fixup is correct, thanks.
Rabin
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: linux-next: manual merge of the async_tx tree with the arm tree
2010-07-28 3:58 ` Rabin VINCENT
@ 2010-07-28 4:43 ` Stephen Rothwell
0 siblings, 0 replies; 11+ messages in thread
From: Stephen Rothwell @ 2010-07-28 4:43 UTC (permalink / raw)
To: Rabin VINCENT
Cc: Dan Williams, linux-next@vger.kernel.org,
linux-kernel@vger.kernel.org, Russell King, Jonas ABERG,
Linus WALLEIJ
[-- Attachment #1: Type: text/plain, Size: 278 bytes --]
Hi Rabin,
On Wed, 28 Jul 2010 09:28:49 +0530 Rabin VINCENT <rabin.vincent@stericsson.com> wrote:
>
> The fixup is correct, thanks.
Thanks for the confirmation.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: linux-next: manual merge of the async_tx tree with the arm tree
2010-07-27 2:08 Stephen Rothwell
2010-07-28 3:58 ` Rabin VINCENT
@ 2010-07-28 7:11 ` Dan Williams
2010-07-28 7:43 ` Russell King
1 sibling, 1 reply; 11+ messages in thread
From: Dan Williams @ 2010-07-28 7:11 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-next, linux-kernel, Rabin Vincent, Russell King,
Jonas Aaberg, Linus Walleij
On Mon, Jul 26, 2010 at 7:08 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Dan,
>
> Today's linux-next merge of the async_tx tree got a conflict in
> arch/arm/mach-ux500/devices-db8500.c between commit
> 6055930cba8fdb2c8855b32bae262aaf69c1fdb4 ("ARM: 6266/1: ux500: add
> separate irq lists for DB8500 and DB5500") from the arm tree and commit
> 5aa12e8c9c57741606e52f43e62ab1b9dc8e9dcc ("DMAENGINE: ste_dma40: arch
> updates for LCLA and LCPA") from the async_tx tree.
>
> I fixed it up (I think - see below) and can carry the fix as necessary.
> --
Thanks Stephen!
Russell, the dma40 driver updates and related arch fixups have been
sitting in next for a month, I'd prefer not to lose this baseline.
Assuming this change is brand new any chance the dma40 specific part
of this patch can be peeled off and sent through my tree, or are you
in a similar "can't/won't" rebase position?
--
Dan
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: linux-next: manual merge of the async_tx tree with the arm tree
2010-07-28 7:11 ` Dan Williams
@ 2010-07-28 7:43 ` Russell King
2010-07-28 23:50 ` Linus Walleij
0 siblings, 1 reply; 11+ messages in thread
From: Russell King @ 2010-07-28 7:43 UTC (permalink / raw)
To: Dan Williams
Cc: Stephen Rothwell, linux-next, linux-kernel, Rabin Vincent,
Jonas Aaberg, Linus Walleij
On Wed, Jul 28, 2010 at 12:11:19AM -0700, Dan Williams wrote:
> On Mon, Jul 26, 2010 at 7:08 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > Hi Dan,
> >
> > Today's linux-next merge of the async_tx tree got a conflict in
> > arch/arm/mach-ux500/devices-db8500.c between commit
> > 6055930cba8fdb2c8855b32bae262aaf69c1fdb4 ("ARM: 6266/1: ux500: add
> > separate irq lists for DB8500 and DB5500") from the arm tree and commit
> > 5aa12e8c9c57741606e52f43e62ab1b9dc8e9dcc ("DMAENGINE: ste_dma40: arch
> > updates for LCLA and LCPA") from the async_tx tree.
> >
> > I fixed it up (I think - see below) and can carry the fix as necessary.
> > --
>
> Thanks Stephen!
>
> Russell, the dma40 driver updates and related arch fixups have been
> sitting in next for a month, I'd prefer not to lose this baseline.
> Assuming this change is brand new any chance the dma40 specific part
> of this patch can be peeled off and sent through my tree, or are you
> in a similar "can't/won't" rebase position?
I don't see how the change in the ARM tree could be reasonably split.
Up to Rabin/Linus to decide what they want to do about this.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: linux-next: manual merge of the async_tx tree with the arm tree
2010-07-28 7:43 ` Russell King
@ 2010-07-28 23:50 ` Linus Walleij
2010-08-03 8:09 ` Dan Williams
0 siblings, 1 reply; 11+ messages in thread
From: Linus Walleij @ 2010-07-28 23:50 UTC (permalink / raw)
To: Russell King, Dan Williams, Stephen Rothwell
Cc: linux-next, linux-kernel, Rabin Vincent, Jonas Aaberg
2010/7/28 Russell King <rmk@arm.linux.org.uk>:
> On Wed, Jul 28, 2010 at 12:11:19AM -0700, Dan Williams wrote:
>> On Mon, Jul 26, 2010 at 7:08 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> > Hi Dan,
>> >
>> > Today's linux-next merge of the async_tx tree got a conflict in
>> > arch/arm/mach-ux500/devices-db8500.c between commit
>> > 6055930cba8fdb2c8855b32bae262aaf69c1fdb4 ("ARM: 6266/1: ux500: add
>> > separate irq lists for DB8500 and DB5500") from the arm tree and commit
>> > 5aa12e8c9c57741606e52f43e62ab1b9dc8e9dcc ("DMAENGINE: ste_dma40: arch
>> > updates for LCLA and LCPA") from the async_tx tree.
>> >
>> > I fixed it up (I think - see below) and can carry the fix as necessary.
>> > --
>>
>> Thanks Stephen!
>>
>> Russell, the dma40 driver updates and related arch fixups have been
>> sitting in next for a month, I'd prefer not to lose this baseline.
>> Assuming this change is brand new any chance the dma40 specific part
>> of this patch can be peeled off and sent through my tree, or are you
>> in a similar "can't/won't" rebase position?
>
> I don't see how the change in the ARM tree could be reasonably split.
> Up to Rabin/Linus to decide what they want to do about this.
Actually the way subsystem maintainers fix up conflicts and resolve them
is a bit of opaque to me, I'd be happy to help in any way possible.
Isn't it so that whoever hits the merge window first goes in and the
other apply Stephens patch before issuing any pull request and be
done with it? That was my naïve idea about these things...
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: linux-next: manual merge of the async_tx tree with the arm tree
2010-07-28 23:50 ` Linus Walleij
@ 2010-08-03 8:09 ` Dan Williams
0 siblings, 0 replies; 11+ messages in thread
From: Dan Williams @ 2010-08-03 8:09 UTC (permalink / raw)
To: Linus Walleij
Cc: Russell King, Stephen Rothwell, linux-next, linux-kernel,
Rabin Vincent, Jonas Aaberg
On Wed, Jul 28, 2010 at 4:50 PM, Linus Walleij
<linus.ml.walleij@gmail.com> wrote:
> 2010/7/28 Russell King <rmk@arm.linux.org.uk>:
>> On Wed, Jul 28, 2010 at 12:11:19AM -0700, Dan Williams wrote:
>>> On Mon, Jul 26, 2010 at 7:08 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>> > Hi Dan,
>>> >
>>> > Today's linux-next merge of the async_tx tree got a conflict in
>>> > arch/arm/mach-ux500/devices-db8500.c between commit
>>> > 6055930cba8fdb2c8855b32bae262aaf69c1fdb4 ("ARM: 6266/1: ux500: add
>>> > separate irq lists for DB8500 and DB5500") from the arm tree and commit
>>> > 5aa12e8c9c57741606e52f43e62ab1b9dc8e9dcc ("DMAENGINE: ste_dma40: arch
>>> > updates for LCLA and LCPA") from the async_tx tree.
>>> >
>>> > I fixed it up (I think - see below) and can carry the fix as necessary.
>>> > --
>>>
>>> Thanks Stephen!
>>>
>>> Russell, the dma40 driver updates and related arch fixups have been
>>> sitting in next for a month, I'd prefer not to lose this baseline.
>>> Assuming this change is brand new any chance the dma40 specific part
>>> of this patch can be peeled off and sent through my tree, or are you
>>> in a similar "can't/won't" rebase position?
>>
>> I don't see how the change in the ARM tree could be reasonably split.
>> Up to Rabin/Linus to decide what they want to do about this.
>
> Actually the way subsystem maintainers fix up conflicts and resolve them
> is a bit of opaque to me, I'd be happy to help in any way possible.
>
> Isn't it so that whoever hits the merge window first goes in and the
> other apply Stephens patch before issuing any pull request and be
> done with it? That was my naïve idea about these things...
>
It's a bag of dirty choices:
1/ Do nothing: LinusT will need to fix up the conflict in the same way
that Stephen has done.
2/ Drop the new patch from the ARM tree as the conflict could have
been seen ahead of time and send it later in the merge window after
async_tx.git has been merged, but this might involve rebasing the ARM
tree.
3/ Back merge the ARM tree after it goes upstream so the conflict is
resolved before Linus pulls async_tx.git, but this makes the history
ugly
4/ Rewind the async_tx.git tree so we at least keep the same branch
point, but this still screws up people who use git pull to track
async_tx.git.
Option 1 is probably the lesser evil as Linus has said he does not
mind the occasional conflict, but it still feels wrong to push any
pain upstream when the conflict could have been seen ahead of time.
--
Dan
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2010-08-03 8:09 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-03-16 4:10 linux-next: manual merge of the async_tx tree with the arm tree Stephen Rothwell
2009-03-16 22:18 ` Dan Williams
2009-03-16 22:28 ` Russell King
2009-03-16 23:12 ` Stephen Rothwell
-- strict thread matches above, loose matches on Subject: below --
2010-07-27 2:08 Stephen Rothwell
2010-07-28 3:58 ` Rabin VINCENT
2010-07-28 4:43 ` Stephen Rothwell
2010-07-28 7:11 ` Dan Williams
2010-07-28 7:43 ` Russell King
2010-07-28 23:50 ` Linus Walleij
2010-08-03 8:09 ` Dan Williams
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).