Re: [PATCH v2 5/6] OMAP1: Amstrad Delta: add support for camera

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux