Re: [PATCH 0/8] v4l: ti-vpe: Add support for scaling and color conversion

[Archit Taneja <archit@ti.com>]

Hi,

On Tuesday 17 December 2013 05:19 PM, Hans Verkuil wrote:
> On 12/17/13 12:19, Archit Taneja wrote:
>> Hi Hans,
>>
>> On Tuesday 17 December 2013 01:30 PM, Hans Verkuil wrote:
>>> On 12/12/2013 09:35 AM, Archit Taneja wrote:
>>>> The VPE and VIP IPs in DRA7x contain common scaler and color
>>>> conversion hardware blocks. We create libraries for these
>>>> components such that the vpe driver and the vip driver(in future)
>>>> can use these library funcs to configure the blocks.
>>>>
>>>> There are some points for which I would like comments:
>>>>
>>>> - For VPE, setting the format and colorspace for the source and
>>>> destination queues is enough to determine how these blocks need
>>>> to be configured and whether they need to be bypassed or not. So
>>>> it didn't make sense to represent them as media controller
>>>> entities. For VIP(driver not upstream yet), it's possible that
>>>> there are multiple data paths which may or may not include these
>>>> blocks. However, the current use cases don't require such
>>>> flexibility. There may be a need to re-consider a media
>>>> controller like setup once we work on the VIP driver. Is it a
>>>> good idea in terms of user-space compatibilty if we use media
>>>> controller framework in the future.
>>>
>>> As long as you don't need the mc, then there is no need to
>>> implement it.
>>
>> The thing is that we want to use these blocks for a future capture
>> hardware called VIP. A VIP port can capture multiple streams from
>> different sensors in time slices, and each of those streams might be
>> sharing the same hardware, but probably in different configurations.
>> I'm not completely aware of media controller details, and whether it
>> can help us here.
>>
>> I was just wondering if it would be a problem if we later realise
>> that mc might be useful for some use cases. Would implementing it
>> then break previous user space applications which don't call mc
>> ioctls?
>
> My understanding is that in the current vpe driver the mc won't be
> needed, so there is no point adding it. When implementing the vip
> capture driver the mc might be needed, but that should not require
> the vpe to add the mc API as well. It's a decision that has to be
> made per driver.

That's right, vpe doesn't need mc. It might be needed for vip. The 
reason I brought it up now is because some of the blocks like SC/CSC are 
replicated in VIP hardware, and I created them in a 'library' sort of 
way in this series. If vip driver uses mc, these blocks might need to 
become media entities.

>
> When you start work on the vip driver it is probably a good idea to
> talk to Laurent and myself first to see whether the mc is needed or
> not.

Thanks, that'll be quite useful. I'll look up some mc documentation and 
drivers using mc myself as well.

>
> If you have a block diagram of the video hardware that you can share,
> then that will be quite useful.

Thanks for the clarification. I don't think the DRA7x documentation is 
public yet. I'll try to look for a block diagram(or create one) and 
share it with the list.

Archit