From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
Jingoo Han <jg1.han@samsung.com>
Subject: Re: linux-next: manual merge of the omap_dss2 tree with Linus' tree
Date: Tue, 9 Apr 2013 13:10:45 +0300 [thread overview]
Message-ID: <5163E925.4060601@ti.com> (raw)
In-Reply-To: <20130408143623.bbf18647b96df42b8b8ec6a0@canb.auug.org.au>
[-- 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 --]
WARNING: multiple messages have this Message-ID (diff)
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: <linux-next@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
Jingoo Han <jg1.han@samsung.com>
Subject: Re: linux-next: manual merge of the omap_dss2 tree with Linus' tree
Date: Tue, 9 Apr 2013 13:10:45 +0300 [thread overview]
Message-ID: <5163E925.4060601@ti.com> (raw)
In-Reply-To: <20130408143623.bbf18647b96df42b8b8ec6a0@canb.auug.org.au>
[-- 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 --]
next prev parent reply other threads:[~2013-04-09 10:10 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-08 4:36 linux-next: manual merge of the omap_dss2 tree with Linus' tree Stephen Rothwell
2013-04-09 10:10 ` Tomi Valkeinen [this message]
2013-04-09 10:10 ` Tomi Valkeinen
2013-04-10 0:13 ` Stephen Rothwell
2013-04-10 0:13 ` Stephen Rothwell
2013-04-10 0:41 ` Linus Torvalds
-- strict thread matches above, loose matches on Subject: below --
2012-11-26 5:22 Stephen Rothwell
2012-11-27 11:24 ` Tomi Valkeinen
2012-11-27 11:24 ` Tomi Valkeinen
2012-09-07 3:29 Stephen Rothwell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5163E925.4060601@ti.com \
--to=tomi.valkeinen@ti.com \
--cc=jg1.han@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=sfr@canb.auug.org.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.