Hans Verkuil wrote:
> On Monday 14 December 2009 21:41:20 Guennadi Liakhovetski wrote:
>> On Mon, 14 Dec 2009, Jonathan Cameron wrote:
> Having bridge-specific code in a sub-device driver will be a disaster in the
> long run. Well, we've seen what happens when you do it that way.


> As far as I know the only soc-dependency left now is for bus configuration.
> Proposals were made some time ago and we should pick that up again and remove
> that last dependency.

We should really go on that direction. V4L i2c drivers shouldn't depend on
platform_data. I've experienced some very bad time fixing conflicts
and waiting for arch merges in order to try to avoid conflicts related
to platform_data changes that should be reflected into V4L drivers.

Even after migrating to -git, this problem won't solve, since the header
files that holds platform_data are highly volatile: on all kernel versions,
they had several changes, and the platform_data patch made while changing
the V4L code needs to be changed during the next merge window.

Due to that, I don't doubt that some earlier merges had broke git bisect
capabilities on those drivers that rely on the highly volatile platform_data
header files applied on arch tree and a separate patch applied on v4l tree.

It seems that we'll need to have some code that will be responsible to
handle arch/platform_data glue, to be merged in the same subsystem that
holds the *.h files, taking care on the required differences for drivers
that need platform_data to work, and a separate code to handle the V4L

In other words, drivers like soc_camera and omap core should be broken
internally into two separate files (or modules), one with V4L bits and
the other with arch/platform_data glue, where the second one should be
be maintained together with the corresponding arch code.

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

Reply via email to