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. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
