Re: [PATCH 0/9] em28xx: refactor the frame data processing code

["Frank Schäfer" <fschaefer.oss@googlemail.com>]

Am 13.12.2012 19:16, schrieb Devin Heitmueller:
> On Thu, Dec 13, 2012 at 12:56 PM, Frank Schäfer
> <fschaefer.oss@googlemail.com> wrote:
>> Am 13.12.2012 18:36, schrieb Devin Heitmueller:
>>> On Sat, Dec 8, 2012 at 10:31 AM, Frank Schäfer
>>> <fschaefer.oss@googlemail.com> wrote:
>>>> This patch series refactors the frame data processing code in em28xx-video.c to
>>>> - reduce code duplication
>>>> - fix a bug in vbi data processing
>>>> - prepare for adding em25xx/em276x frame data processing support
>>>> - clean up the code and make it easier to understand
>>> Hi Frank,
>>>
>>> Do you have these patches in a git tree somewhere that I can do a git
>>> pull from?  If not then that's fine - I'll just save off the patches
>>> and apply them by hand.
>> No, I have no public git tree.
>>
>>> I've basically got your patches, fixes Hans did for v4l2 compliance,
>>> and I've got a tree that converts the driver to videobuf2 (which
>>> obviously heavily conflicts with the URB handler cleanup you did).
>>> Plan is to suck them all into a single tree, deal with the merge
>>> issues, then issue a pull request to Mauro.
>> Ahhh, videobuf2 !
>> Good to know, because I've put this on my TODO list... ;)
> It's harder than it looks.  There are currently no other devices
> ported to vb2 which have VBI and/or radio devices.  Hence I have to
> refactor the locking a bit (since the URB callback feeds two different
> VB2 queues).  In other words, there's no other driver to look at as a
> model and copy the business logic from.

Yeah, that's one of the reasons why I decided to do it later ;)

>
>> Yes, there will likely be heavy merge conflicts...
>> In which tree are the videobuf2 patches ?
> It's in a private tree right now, and it doesn't support VBI
> currently.  Once I've setup a public tree with yours and Hans changes,
> I'll start merging in my changes.

I suggest to do the conversion on top of my patches, as they should make
things much easier for you.
I unified the handling of the VBI and video buffers, leaving just a few
common functions dealing with the videobuf stuff.

In any case, we should develop against a common tree with a minimum
number of pending patches.
And we should coordinate development.
I don't work on further changes of the frame processing stuff at the moment.
Some I2C fixes/changes will be next. After that, I will try to fix
support for remote controls with external IR IC (connected via i2c).

> Obviously it would be great for you to test with your webcam and make
> sure I didn't break anything along the way.

Sure, I will be glad to test your changes.

> I've also got changes to support V4L2_FIELD_SEQ_TB, which is needed in
> order to take the output and feed to certain hardware deinterlacers.
> In reality this is pretty much just a matter of treating the video
> data as progressive but changing the field type indicator.

Ok, so I assume most of the changes will happen in em28xx_copy_video().
Maybe we can then use a common copy function for video and VBI. Placing
the field data sequentially in the videobuf is what we already do with
the VBI data in em28xx_copy_vbi()

Regards,
Frank

> I'm generally pretty easy to find in #linuxtv or #v4l if you want to
> discuss further.
>
> Cheers,
>
> Devin
>
> --
> Devin J. Heitmueller - Kernel Labs
> http://www.kernellabs.com