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-karicheri2@xxxxxx >-----Original Message----- >From: Mauro Carvalho Chehab [mailto:mchehab@xxxxxxxxxxxxx] >Sent: Wednesday, December 30, 2009 5:25 PM >To: Karicheri, Muralidharan >Cc: Hans Verkuil; linux-media@xxxxxxxxxxxxxxx; khilman@xxxxxxxxxxxxxxxxxxx >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. ��.n��������+%������w��{.n�����{��g����^n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�m
