Mauro,

What do you suggest for the existing 2 pull requests from Hans?

I had suggested something in my last email to do this in 2 steps
based on Kevin's proposal.

1) Merge the patches (including arch patches) to linux-next tree
based on Hans's pull request.

2) When upstream merge window opens and Kevin's davinci tree is
merged to Linus tree, drop the arch patches from v4l-dvb. We could
re-work the dropped patches based on Linus tree and send the same
to you.

Do you think this is doable? If so, please merge these pull
requests to linux-next.

Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com

>-----Original Message-----
>From: Mauro Carvalho Chehab [mailto:mche...@infradead.org]
>Sent: Wednesday, December 30, 2009 5:25 PM
>To: Karicheri, Muralidharan
>Cc: Hans Verkuil; linux-media@vger.kernel.org; khil...@deeprootsystems.com
>Subject: Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci
>
>Karicheri, Muralidharan wrote:
>> Hans,
>>
>> Thanks for this pull request..
>>
>>> I gather that Murali and you have figured out the right order to merge
>this,
>>> so
>>> I leave the details to the both of you.
>>
>> Not really :( I haven't seen a response to my last email on this.
>>
>>> Note that I agree with Mauro's suggestion that the v4l parts of the
>>platform code are split off into a separate platform source. That would
>>make it much easier to make changes in the platform code for v4l devices
>>without running into conflicts with non-v4l platform code changes. We
>could >even make that v4l platform source part of the hg tree.
>>
>> Do you suggest creating separate arch part source for hg tree and
>upstream? (I see you have arch folders in the hg tree, but only few
>architectures currently supported mx*/px*). If so, how is the upstream
>merge of arch code
>> handled in your case? My question is when the v4l part is merged, the
>corresponding arch part has to be merged as well to compile the upstream
>code base. So this is not going to solve the issue that we are facing
>currently. May be I am not getting the full picture here.
>
>The issue is that non-v4l platform data changes that happens on the same
>headers where you
>have also v4l platform data changes cause lots of merge troubles.
>
>This happens with -hg, but this also would happen if I just merge from a -
>git tree.
>So, the problem is not about having a different procedure due to -hg, but
>having a
>way to avoid having merge conflicts every time an omap driver (or another
>driver that uses the platform_data stuff) is merged.
>
>On my experiences, the non-Intel arch headers used by V4L drivers got
>renamed,
>had several api changes and mixed several different subsystems at the same
>header,
>causing all sorts of merge conflicts. Since the soc_camera and omap drivers
>got
>merged, on every single kernel version, we had some sort of conflict to
>manage.
>
>On several cases, git bisect got broken, and we had even some worse case
>scenarios
>where the arch compilation got broken for some time, due to those conflicts.
>
>>
>> BTW, I am okay to have an account in the hg tree. Is there a quick
>tutorial
>> to understand the process and tools needed to get me started?
>
>I can send you one, but maybe it is a little late for it, since my
>intention is to
>start discussing and working to replace -hg to -git at the beginning of
>2010, if time
>allows me to do that.
>
>Cheers,
>Mauro.

Reply via email to