Re: [PATCH] media: vimc: add configfs API to configure the topology

From: Hans Verkuil <hverkuil@xs4all.nl>
To: Helen Koike <helen.koike@collabora.com>, linux-media@vger.kernel.org
Cc: mchehab@kernel.org, lkcamp@lists.libreplanetbr.org,
	kernel@collabora.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] media: vimc: add configfs API to configure the topology
Date: Mon, 10 Dec 2018 18:13:41 +0100	[thread overview]
Message-ID: <159b0f0c-8e75-385d-08de-117d50ab70e3@xs4all.nl> (raw)
In-Reply-To: <1cf814ac-60e1-bff7-4e9b-72b2c393d49a@collabora.com>

On 12/10/18 5:14 PM, Helen Koike wrote:
> Hi Hans,
> 
> On 12/10/18 9:31 AM, Hans Verkuil wrote:
>> On 12/7/18 7:22 PM, Helen Koike wrote:

<snip>

> 
>>
>> The previewer is effectively similar to a debayer block.
> 
> You mean the image it outputs?

Yes. It takes a bayer image and outputs a non-bayer format on the omap3.

> 
>>
>> AEWB, AF and histogram are for auto-whitebalance, autofocus and histogram statistics.
>> This isn't supported by vimc, and is a 'nice-to-have' for the future.
> 
> Right, I need to check how to include those. I am a bit confused as in
> the omap3 topology they are seems to be just configuration points (I
> mean, they are not really part of the image pipeline).

Typically the SoC analyzes the image and produces statistics of various kinds that
are given to userspace via devices like this. It is used as input to auto-whitebalance,
auto-focus and auto-gain algorithms running in userspace that feedback the results to
sensor config changes.

The format is usually very SoC-specific.

> 
> I was reading this
> https://linuxtv.org/downloads/v4l-dvb-apis-new/v4l-drivers/omap3isp.html?highlight=histogram#statistic-blocks-ioctls
> It says:
> "The statistics are dequeueable by the user from the statistics subdev
> nodes using private IOCTLs"
> 
> I suppose we should emulate those private IOCTLs in vimc? If you could
> provide me some pointers in where I can find docs on these private
> IOCTLs it would be great.

No, just ignore these statistics devices for now. And if we make them, we
can design a vimc-specific format.

> 
>>
>> The main missing bits in vimc are a CSI block and a splitter block. It should be simple
>> to add the CSI block since it really doesn't do anything in an emulated environment.
> 
> CSI would be just a dummy entity with one sink pad and one source pad right?

Right.

> 
>>
>> A splitter might be more complicated, I'm not sure.
> 
> splitter shouldn't that complicated in the current state of vimc, but
> when we start optimizing the pipeline then it is going to be more
> complicated.

Right.

Regards,

	Hans