From: Steve Longerbeam <slongerbeam@gmail.com>
To: Hans Verkuil <hverkuil@xs4all.nl>,
Jean-Michel Hautbois <jean-michel.hautbois@vodalys.com>,
Steve Longerbeam <steve_longerbeam@mentor.com>
Cc: Philipp Zabel <p.zabel@pengutronix.de>,
Tim Harvey <tharvey@gateworks.com>,
Robert Schwebel <r.schwebel@pengutronix.de>,
linux-media@vger.kernel.org,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Subject: Re: i.MX6 status for IPU/VPU/GPU
Date: Tue, 09 Sep 2014 09:06:06 -0700 [thread overview]
Message-ID: <540F256E.5080309@gmail.com> (raw)
In-Reply-To: <540EB1A8.9080804@xs4all.nl>
On 09/09/2014 12:52 AM, Hans Verkuil wrote:
> On 09/09/14 09:49, Jean-Michel Hautbois wrote:
>> 2014-08-27 16:23 GMT+02:00 Steve Longerbeam <steve_longerbeam@mentor.com>:
>>
>>> Hi Jean-Michel, Phillip,
>> Hi Steve,
>>
>>> 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.
>> Dos it compile against a 3.17-rc3 kernel :) ?
>>
>>> 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.
>> This is very interesting, do you have written this somewhere ?
>>
>>> 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.
>> I, at least, am interested by this driver, even in its "traditionnal"
>> form :). If you don't want to submit it directly because this is not
>> using media controller, this is ok, you can provide me a git repo in
>> order to get it, or send a patchset.
> Is it possible to create a staging driver? Even if there are bits missing,
> having the code in the kernel as a staging driver would help a lot.
Hi Hans, that's a good idea. I can post it as a staging driver.
The capture driver does require more support in the i.MX IPU driver which is
not yet merged or proposed. Phillip has forwarded most of them to drm-next,
but there are a few more required. I need to post those patches to drm-next
as a first step.
I can start working on converting the driver to staging and addressing
the earlier issues, but posting it to media-tree will need to wait until the IPU
patches are merged, unless I include the IPU patches along with the capture
driver patchset.
Steve
next prev parent reply other threads:[~2014-09-09 16:06 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-28 16:24 i.MX6 status for IPU/VPU/GPU Jean-Michel Hautbois
2014-07-28 18:59 ` Robert Schwebel
2014-07-28 21:15 ` Steve Longerbeam
2014-08-04 6:14 ` Tim Harvey
2014-08-04 11:54 ` Philipp Zabel
2014-08-05 8:07 ` Jean-Michel Hautbois
2014-08-27 7:13 ` Jean-Michel Hautbois
2014-08-27 14:23 ` Steve Longerbeam
2014-09-09 7:49 ` Jean-Michel Hautbois
2014-09-09 7:52 ` Hans Verkuil
2014-09-09 16:06 ` Steve Longerbeam [this message]
2014-09-09 16:12 ` Steve Longerbeam
2014-09-09 17:40 ` Philipp Zabel
2014-09-11 1:17 ` Steve Longerbeam
2014-09-11 13:26 ` Philipp Zabel
2014-09-15 14:13 ` Jean-Michel Hautbois
2014-10-24 13:42 ` Jean-Michel Hautbois
2015-01-27 15:00 ` Carlos Sanmartín Bustos
2014-09-09 16:28 ` Steve Longerbeam
2014-09-10 16:08 ` Jean-Michel Hautbois
2014-09-10 16:25 ` Steve Longerbeam
2014-09-11 0:37 ` Steve Longerbeam
2014-10-02 14:50 ` Jean-Michel Hautbois
2014-10-03 10:25 ` Carlos Sanmartín Bustos
[not found] ` <CAPW4HR0BJ7X0sMy78keEFtS6WXpbJjYCo75utKqWBtsDvrbUeg@mail.gmail.com>
2014-10-03 10:27 ` Jean-Michel Hautbois
2014-10-06 1:03 ` Steve Longerbeam
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=540F256E.5080309@gmail.com \
--to=slongerbeam@gmail.com \
--cc=hverkuil@xs4all.nl \
--cc=jean-michel.hautbois@vodalys.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
--cc=p.zabel@pengutronix.de \
--cc=r.schwebel@pengutronix.de \
--cc=steve_longerbeam@mentor.com \
--cc=tharvey@gateworks.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).