linux-next: manual merge of the omap_dss2 tree with Linus' tree

linux-next: manual merge of the omap_dss2 tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1332 bytes --]

Hi Tomi,

Today's linux-next merge of the omap_dss2 tree got a conflict in
drivers/video/fbmon.c between commit 477fc03f5baa ("fbmon: use
VESA_DMT_VSYNC_HIGH to fix typo") from Linus' tree and commit
06a3307975aa ("videomode: combine videomode dmt_flags and data_flags")
from the omap_dss2 tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

diff --cc drivers/video/fbmon.c
index 7f67099,e5cc2fd..0000000
--- a/drivers/video/fbmon.c
+++ b/drivers/video/fbmon.c
@@@ -1398,13 -1398,13 +1398,13 @@@ int fb_videomode_from_videomode(const s
  
  	fbmode->sync = 0;
  	fbmode->vmode = 0;
- 	if (vm->dmt_flags & VESA_DMT_HSYNC_HIGH)
+ 	if (vm->flags & DISPLAY_FLAGS_HSYNC_HIGH)
  		fbmode->sync |= FB_SYNC_HOR_HIGH_ACT;
- 	if (vm->dmt_flags & VESA_DMT_VSYNC_HIGH)
 -	if (vm->flags & DISPLAY_FLAGS_HSYNC_HIGH)
++	if (vm->flags & DISPLAY_FLAGS_VSYNC_HIGH)
  		fbmode->sync |= FB_SYNC_VERT_HIGH_ACT;
- 	if (vm->data_flags & DISPLAY_FLAGS_INTERLACED)
+ 	if (vm->flags & DISPLAY_FLAGS_INTERLACED)
  		fbmode->vmode |= FB_VMODE_INTERLACED;
- 	if (vm->data_flags & DISPLAY_FLAGS_DOUBLESCAN)
+ 	if (vm->flags & DISPLAY_FLAGS_DOUBLESCAN)
  		fbmode->vmode |= FB_VMODE_DOUBLE;
  	fbmode->flag = 0;
  
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: manual merge of the omap_dss2 tree with Linus' tree

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 1835 bytes --]

Hi,

On 2013-04-08 07:36, Stephen Rothwell wrote:
> Hi Tomi,
> 
> Today's linux-next merge of the omap_dss2 tree got a conflict in
> drivers/video/fbmon.c between commit 477fc03f5baa ("fbmon: use
> VESA_DMT_VSYNC_HIGH to fix typo") from Linus' tree and commit
> 06a3307975aa ("videomode: combine videomode dmt_flags and data_flags")
> from the omap_dss2 tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
> 
> diff --cc drivers/video/fbmon.c
> index 7f67099,e5cc2fd..0000000
> --- a/drivers/video/fbmon.c
> +++ b/drivers/video/fbmon.c
> @@@ -1398,13 -1398,13 +1398,13 @@@ int fb_videomode_from_videomode(const s
>   
>   	fbmode->sync = 0;
>   	fbmode->vmode = 0;
> - 	if (vm->dmt_flags & VESA_DMT_HSYNC_HIGH)
> + 	if (vm->flags & DISPLAY_FLAGS_HSYNC_HIGH)
>   		fbmode->sync |= FB_SYNC_HOR_HIGH_ACT;
> - 	if (vm->dmt_flags & VESA_DMT_VSYNC_HIGH)
>  -	if (vm->flags & DISPLAY_FLAGS_HSYNC_HIGH)
> ++	if (vm->flags & DISPLAY_FLAGS_VSYNC_HIGH)
>   		fbmode->sync |= FB_SYNC_VERT_HIGH_ACT;
> - 	if (vm->data_flags & DISPLAY_FLAGS_INTERLACED)
> + 	if (vm->flags & DISPLAY_FLAGS_INTERLACED)
>   		fbmode->vmode |= FB_VMODE_INTERLACED;
> - 	if (vm->data_flags & DISPLAY_FLAGS_DOUBLESCAN)
> + 	if (vm->flags & DISPLAY_FLAGS_DOUBLESCAN)
>   		fbmode->vmode |= FB_VMODE_DOUBLE;
>   	fbmode->flag = 0;

Thanks, looks correct.

I wonder what I should do about this conflict. Both the fix in Linus'
tree and the new code come from fbdev tree (I'm currently handling fbdev
patches), and it feels a bit silly to have conflicts between the fixes
and new commits from the same subsystem tree.

I could just leave the conflict be, or I could merge the fix into the
fbdev-next branch. Do you know if there's a rule of thumb I should
follow here?

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]

Re: linux-next: manual merge of the omap_dss2 tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1184 bytes --]

Hi Tomi,

On Tue, 9 Apr 2013 13:10:45 +0300 Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>
> I wonder what I should do about this conflict. Both the fix in Linus'
> tree and the new code come from fbdev tree (I'm currently handling fbdev
> patches), and it feels a bit silly to have conflicts between the fixes
> and new commits from the same subsystem tree.

Since you really should have that fix in your -next branch as well (for
testing), I would merge the same branch that Linus merged i.e. I would
merge commit 090da752cdd6 ("video:uvesafb: Fix dereference NULL pointer
code path") since that is already in your tree (presumably as a separate
branch or tag).  I would also put a comment in the merge commit itself
explaining why you did it.

> I could just leave the conflict be, or I could merge the fix into the
> fbdev-next branch. Do you know if there's a rule of thumb I should
> follow here?

The normal rule is to leave it to me and Linus, but since both sides of
the conflict came your own tree, I think the above makes more sense.

[cc'd Linus for any conflicting opinion]
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: manual merge of the omap_dss2 tree with Linus' tree

[Linus Torvalds]

On Tue, Apr 9, 2013 at 5:13 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Since you really should have that fix in your -next branch as well (for
> testing), I would merge the same branch that Linus merged i.e. I would
> merge commit 090da752cdd6 ("video:uvesafb: Fix dereference NULL pointer
> code path") since that is already in your tree (presumably as a separate
> branch or tag).  I would also put a comment in the merge commit itself
> explaining why you did it.

I'd actually prefer people *not* do this unless they really have to.
Just fixing a merge conflict is not a good enough reason to add
another merge.

If you really really need the particular fix for some other reason (ie
that bug creates real problems for you and you need the bugfix in
order to test all the other development you've done), then yes, doing
the merge is worth it. But just to resolve a merge conflct early? No.

                   Linus

Re: linux-next: manual merge of the omap_dss2 tree with Linus' tree

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 581 bytes --]

Hi,

On 2012-11-26 07:22, Stephen Rothwell wrote:
> Hi Tomi,
> 
> Today's linux-next merge of the omap_dss2 tree got a conflict in
> drivers/video/omap2/dss/dss.c between commit f65e384bec59 ("omapdss: dss:
> Fix clocks on OMAP363x") from Linus' tree and commit bd81ed081887
> ("OMAPDSS: DSS: use omapdss_version") from the omap_dss2 tree.
> 
> I fixed it up (using the omap_dss2 tree version) and can carry the fix as
> necessary (no action is required).

Thanks. I've now pulled the omapdss fixes that were merged in -rc7, and
resolved the conflicts.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]

linux-next: manual merge of the omap_dss2 tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 471 bytes --]

Hi Tomi,

Today's linux-next merge of the omap_dss2 tree got a conflict in
drivers/video/omap2/dss/dss.c between commit f65e384bec59 ("omapdss: dss:
Fix clocks on OMAP363x") from Linus' tree and commit bd81ed081887
("OMAPDSS: DSS: use omapdss_version") from the omap_dss2 tree.

I fixed it up (using the omap_dss2 tree version) and can carry the fix as
necessary (no action is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the omap_dss2 tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1540 bytes --]

Hi Tomi,

Today's linux-next merge of the omap_dss2 tree got a conflict in drivers/video/omap2/dss/sdi.c between commit 35d678664873 ("OMAPDSS: Fix SDI PLL locking") from Linus' tree and commit 889b4fd7eed2 ("OMAPDSS: SDI: Maintain copy of data pairs in driver data") from the omap_dss2 tree.

Just context changes.  I fixed it up (see below) and can carry the fix as
necessary (no action is required).
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/video/omap2/dss/sdi.c
index f43bfe1,3bf1bfe..0000000
--- a/drivers/video/omap2/dss/sdi.c
+++ b/drivers/video/omap2/dss/sdi.c
@@@ -105,21 -107,8 +107,22 @@@ int omapdss_sdi_display_enable(struct o
  
  	sdi_config_lcd_manager(dssdev);
  
 +	/*
 +	 * LCLK and PCLK divisors are located in shadow registers, and we
 +	 * normally write them to DISPC registers when enabling the output.
 +	 * However, SDI uses pck-free as source clock for its PLL, and pck-free
 +	 * is affected by the divisors. And as we need the PLL before enabling
 +	 * the output, we need to write the divisors early.
 +	 *
 +	 * It seems just writing to the DISPC register is enough, and we don't
 +	 * need to care about the shadow register mechanism for pck-free. The
 +	 * exact reason for this is unknown.
 +	 */
 +	dispc_mgr_set_clock_div(dssdev->manager->id,
 +			&sdi.mgr_config.clock_info);
 +
- 	dss_sdi_init(dssdev->phy.sdi.datapairs);
+ 	dss_sdi_init(sdi.datapairs);
+ 
  	r = dss_sdi_enable();
  	if (r)
  		goto err_sdi_enable;

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]