Dnia niedziela 10 kwiecieÅ 2011 o 18:00:14 Guennadi Liakhovetski napisaÅ(a): > Hi Janusz > > On Sat, 9 Apr 2011, Janusz Krzysztofik wrote: > > Since commit 0e4c180d3e2cc11e248f29d4c604b6194739d05a, bytesperline > > and sizeimage memebers of v4l2_pix_format structure have no longer > > been calculated inside soc_camera_g_fmt_vid_cap(), but rather > > passed via soc_camera_device structure from a host driver callback > > invoked by soc_camera_set_fmt(). > > > > OMAP1 camera host driver has never been providing these parameters, > > so it no longer works correctly. Fix it by adding suitable > > assignments to omap1_cam_set_fmt(). > > Thanks for the patch, but now it looks like many soc-camera host > drivers are re-implementing this very same calculation in different > parts of their code - in try_fmt, set_fmt, get_fmt. Why don't we > unify them all, implement this centrally in soc_camera.c and remove > all those calculations? Wasn't it already unified before commit in question? > Could you cook up a patch or maybe several > patches - for soc_camera.c and all drivers? Perhaps I could, as soon as I found some spare time, but first I'd have to really understand why we need bytesperline or sizeimage handling being changed from how they worked before commit 0e4c180d3e2cc11e248f29d4c604b6194739d05a was introduced. I never had a need to customize bytesperline or sizeimage calculations in my driver. But even then, I think these new patches would rather qualify for next merge window, while the OMAP1 driver case is just a regression, caused by an alredy applied, unrelated change to the underlying framework, and requires a fix if that change is not going to be reverted. Maybe the author of the change, Sergio Aguirre form TI (CCing him), could rework his patch in a way which wouldn't impose, as a side effect, the new requirement of those structure members being passed from host drivers? Thanks, Janusz -- 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
