Re: i.MX6 status for IPU/VPU/GPU

[Steve Longerbeam <steve_longerbeam@mentor.com>]

On 08/27/2014 12:13 AM, Jean-Michel Hautbois wrote:
> Hi Phillip,
>
> 2014-08-04 13:54 GMT+02:00 Philipp Zabel <p.zabel@pengutronix.de>:
>> We should take this step by step. First I'd like to get Steve's ipu-v3
>> series in, those don't have any major issues and are a prerequisite for
>> the media patches anyway.
>>
>> The capture patches had a few more issues than just missing media device
>> support. But this is indeed the biggest one, especially where it
>> involves a userspace interface that we don't want to have to support in
>> the future.
>> My RFC series wasn't without problems either. I'll work on the IPU this
>> week and then post another RFC.
> Any news about this ? I saw your patchset from june 12th.
> What is the current status of this RFC and is there a way to help
> integrating/testing it ? Do you have a public git repository I can
> fetch and merge in order to test ?
>
>

Hi Jean-Michel, Phillip,

I've done some work on Philipp's June 12 patchset, converting
the CSI driver to a CSI subdev entity, and fixing some issues here
and there. This June 12 patchset doesn't appear to be a fully working
driver, Phillip correct me if I am wrong. I can post this work as it
exists, it is incomplete but compiles.

I've also worked out what I think is a workable video pipeline graph for i.MX,
suitable for defining the entities, pads, and links. Unfortunately I haven't
been able to spend as much time as I'd like on it.

The complete driver I posted to the list does have some minor issues
mostly suggested by Hans Verkuil (switch to new selection API instead
of cropping API for example). It is a full featured driver but it does not
implement the media device framework, i.e. user does not have direct
control of the video pipeline, rather the driver chooses the pipeline based
on the traditional inputs from user (video format and controls).

If there is interest I can submit another version of the traditional driver
to resolve the issues. But media device is a major rework, so I don't
know whether it would make sense to start from the traditional driver
and then implement media device on top later, since media device
is almost a complete rewrite.

Steve