Friday 24 September 2010 08:57:06 Guennadi Liakhovetski napisaÅ(a): > On Thu, 23 Sep 2010, Tony Lindgren wrote: > > * Janusz Krzysztofik <jkrzyszt@xxxxxxxxxxxx> [100923 16:52]: > > > Friday 24 September 2010 01:26:17 Tony Lindgren napisaÅ(a): > > > > * Tony Lindgren <tony@xxxxxxxxxxx> [100923 16:06]: > > > > > * Janusz Krzysztofik <jkrzyszt@xxxxxxxxxxxx> [100910 18:20]: > > > > > > This patch adds configuration data and initialization code > > > > > > required for camera support to the Amstrad Delta board. > > > > > > > > > > > > Three devices are declared: SoC camera, OMAP1 camera interface > > > > > > and OV6650 sensor. > > > > > > > > > > > > Default 12MHz clock has been selected for driving the sensor. > > > > > > Pixel clock has been limited to get reasonable frame rates, not > > > > > > exceeding the board capabilities. Since both devices (interface > > > > > > and sensor) support both pixel clock polarities, decision on > > > > > > polarity selection has been left to drivers. Interface GPIO line > > > > > > has been found not functional, thus not configured. > > > > > > > > > > > > Created and tested against linux-2.6.36-rc3. > > > > > > > > > > > > Works on top of previous patches from the series, at least 1/6, > > > > > > 2/6 and 3/6. > > > > > > > > > > Queuing these last two patches of the series (5/6 and 6/6) for the > > > > > upcoming merge window. > > > > > > > > BTW, these still depend on updated 2/6 to make compile happy. > > > > > > Not so simple: still depends on struct omap1_cam_platform_data > > > definition from <media/omap1_camera.h>, included from <mach/camera.h>. > > > Are you ready to accept another temporary workaround? > > > > Heh I guess so. Or do you want to queue everything via linux-media? AFAIK we can expect my arch/arm/mach-omap1/devices.c changes already resulting in a confilct with some ASoC OMAP related changes going via the sound tree, so the 2/6 should be better queued via the OMAP tree for Tony to keep control over it, with the rest of the seriers going either way. > Yes, we often have to select via which tree to go, then the maintainer of > the other tree just acks the patches. Sometimes we push them via different > trees and try to enforce a specific merge order... What about + void omap1_set_camera_info(struct omap1_cam_platform_data *); put temporarily into to the arch/arm/mach-omap1/board-ams-delta.c instead of including <mach/camera.h>, that could be replaced with <media/omap1_camera.h> then? May sound better than redefining struct omap1_cam_platform_data there, and should be safe to push everything except 2/6 via the media tree. Then, replace the above hack back with #include <mach/camera.h> as a fix after both are merged. Thanks, Janusz -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
