Hans Verkuil wrote: >> Hans Verkuil wrote: >>> Hi Mauro, >>> >>> Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci for >>> the following: >>> >>> - v4l: vpfe_capture: remove clock and ccdc resource handling >>> - v4l: vpfe capture: convert dm355 ccdc driver to a platform driver >>> - v4l: vpfe capture: convert dm644x ccdc module to a platform driver >>> >>> And after these three patches are pulled in, then this arch patch should >>> also be >>> merged for git: >>> >>> http://patchwork.kernel.org/patch/67669/ >> Hmm... It seems that git bisect will break if I merge first the conversion >> and then >> the platform_data patches. > > Murali, what is the correct merge order? I assumed that the order you gave > me was 'safe' (as in, it always compiles after each patch). I did compile > the v4l patches, but I did not check if there was any breakage if I build > the full kernel. To be safe, it needs not only to compile, but also to not break the driver, otherwise bisecting the affected drivers will not work. > So what do you want me or Murali to do? Wait until rc1 is released and > then make sure that the arch patch will apply correctly to what is in rc1? This won't solve, since, between 2.6.33-rc1 and the next open window (2.6.34 window), I bet that the *.h file will change enough for the merge to not apply. I see two ways: 1) (if it is safe to apply the platform_data patch without the v4l changes) send the patch to the -arch maintainer, as he'll handle the other changes to the same header file; 2) create a platform_data glue module/file that will handle the arch/platform_data glue for omap drivers and maintain it together with arch. All V4L specific code should be kept maintained on V4L subsystem. (2) is better, but will probably require more time to happen, but IMHO, this is the solution to avoid having troubles like that on all merge windows. 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
