On Wed, 23 May 2012, javier Martin wrote: > Hi Guennadi, Mauro, > > >> Looks like I have missed this patch, unfortunately, it hasn't been cc'ed > >> to me. It would have been better to merge it via my soc-camera tree, also > >> because with this merge window there are a couple more changes, that > >> affect the generic soc-camera API and the mx2-camera driver in particular. > >> So far I don't see anything, what could break here, but if something does > >> - we know who will have to fix it;-) > > Sorry about that. I usually send patches for mx2-camera to you as well > but this time I missed it. The fact that your name does not appear > when executing 'get_mantainer' doesn't help me to remember either.
No idea whether there is a way to help that script deliver a better result, sorry. I certainly would rather avoid listing each soc-camera file in MAINTAINERS. I don't think it's a sufficient reason to justify moving them all into a separate subdirectory. > > I'm afraid, I get an impression, that your patch breaks support for the > > pass-through mode in the mx2-camera driver. Where previously not natively > > supported formats would be just read in by the camera interface without > > any conversion (see the first entry in the mx27_emma_prp_table[] array), > > you now return an error in mx2_camera_set_bus_param(). > > I think you are right. It seems I should provide a default for other > mbus formats instead of returning an error. It's good you noticed > because I haven't got any device to test this pass-through mode, so I > try my best to add new functionallity without breaking it. > > >If I'm write, I'll ask Mauro to revert your patch. Please correct me if I'm > >mistaken. s/write/right/ > Is this the way to proceed or should I send a fix on top of it? This > patch is merged in 'for_v3.5', if Mauro reverts it and I send a new > version, would it be also merged 'for_v3.5' or should it wait for > version 3.6? I think, it would be better to revert and re-do it for the following reason: since neither you nor me can test those pass-through cases, I think, it is easier to review patches and try to avoid regressions by looking at patches, that take you from a (presumably working) state A step by step to a state B, where each patch is seemingly correct, than by looking at a patch "a" that introduces a breakage and "b" that hopefully should fix it back. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html