On 03/27/2013 05:31 AM, Arun Kumar K wrote:
> On Wed, Mar 27, 2013 at 4:21 AM, Sylwester Nawrocki
> <sylvester.nawrocki@xxxxxxxxx> wrote:
>> On 03/26/2013 01:17 PM, Arun Kumar K wrote:
[...]
> Only issue is with the context sharing.
> Right now you can see that the fimc-is context is shared between all
> the subdevs.
> As all of them are part of the same driver, it is possible.
> If sensor is made as an independent i2c device, a separate probe will
> be called for it.
> For ISP sensor subdev to work independently, it needs to call the
> fimc_is_pipeline_* calls
> for FW initialization and other configurations for which it needs the
> fimc-is main context.
>
> Now there is a workaround here by calling a get_context() macro in
> sensor's probe
> to get the fimc-is context. This will cause the same context to be
> shared and updated by
> 2 drivers though both are part of fimc-is.
> Is this acceptable? Or am I missing some other simple solution of implementing
> it in a better way?
OK, thanks for the explanation.
I can think of at least one possible way to get hold of the fimc-is
context in the subdev. For instance, in subdev's .registered callback
you get a pointer to struct v4l2_device, which is normally embedded
in a top level driver's private data. Then with container_of()
you could get hold of required data at the fimc-is driver.
But... to make the subdev drivers reuse possible subdevs should
normally not be required to know the internals of a host driver they
are registered to. And it looks a bit unusual to have fimc_pipeline_*
calls in the sensor's operation handlers.
I thought that the subdevs could provide basic methods and it would
be the top level media driver that would resolve any dependencies
in calling required subdev ops, according to media graph configuration
done by the user on /dev/media?.
The media driver has a list of media entities (subdevices and video
nodes) and I though it could coordinate any requests involving whole
video/image processing pipeline originating from /dev/video ioctls/fops.
So for instance if /dev/video in this pipeline is opened
sensor (sd) -> mipi-csis (sd) -> fimc-lite (sd) -> memory (/dev/video)
it would call s_power operation on the above subdevs and additionally
on e.g. the isp subdev (or any other we choose as a main subdev
implementing the FIMC-IS slave interface).
Then couldn't it be done that video node ioctls invoke pipeline
operations, and the media device resolves any dependencies/calls
order, as in case of the exynos4 driver ?
As a side note, I'm working on adding a generic method to get any
v4l2_subdev/video_device from a struct media_entity instance, so
it is easier to handle link_notify events, power/streaming enable/
disable sequences, etc. Currently I have a data structure like:
struct exynos_iss_entity {
struct video_device vdev;
struct v4l2_subdev subdev;
struct exynos_iss_pipeline pipe;
};
Regards,
Sylwester
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
