From: "Frank Schäfer" <fschaefer.oss@googlemail.com>
To: Devin Heitmueller <dheitmueller@kernellabs.com>
Cc: Linux Media Mailing List <linux-media@vger.kernel.org>
Subject: Re: [PATCH 0/9] em28xx: refactor the frame data processing code
Date: Thu, 13 Dec 2012 18:56:59 +0100 [thread overview]
Message-ID: <50CA16EB.7060201@googlemail.com> (raw)
In-Reply-To: <CAGoCfiw1wN+KgvNLqDSmbz5AwswPT9K48XOM4RnfKvHkmmR59g@mail.gmail.com>
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... ;)
Yes, there will likely be heavy merge conflicts...
In which tree are the videobuf2 patches ?
Regards,
Frank
>
> Cheers,
>
> Devin
>
> --
> Devin J. Heitmueller - Kernel Labs
> http://www.kernellabs.com
next prev parent reply other threads:[~2012-12-13 17:56 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-08 15:31 [PATCH 0/9] em28xx: refactor the frame data processing code Frank Schäfer
2012-12-08 15:31 ` [PATCH 1/9] em28xx: refactor get_next_buf() and use it for vbi data, too Frank Schäfer
2012-12-08 15:31 ` [PATCH 2/9] em28xx: use common function for video and vbi buffer completion Frank Schäfer
2012-12-08 15:31 ` [PATCH 3/9] em28xx: remove obsolete field 'frame' from struct em28xx_buffer Frank Schäfer
2012-12-08 15:31 ` [PATCH 4/9] em28xx: move field 'pos' from struct em28xx_dmaqueue to " Frank Schäfer
2012-12-08 15:31 ` [PATCH 5/9] em28xx: refactor VBI data processing code in em28xx_urb_data_copy() Frank Schäfer
2012-12-08 15:31 ` [PATCH 6/9] em28xx: move caching of pointer to vmalloc memory in videobuf to struct em28xx_buffer Frank Schäfer
2012-12-08 15:31 ` [PATCH 7/9] em28xx: em28xx_urb_data_copy(): move duplicate code for capture_type=0 and capture_type=2 to a function Frank Schäfer
2012-12-08 15:31 ` [PATCH 8/9] em28xx: move the em2710/em2750/em28xx specific frame data processing code to a separate function Frank Schäfer
2012-12-08 15:31 ` [PATCH 9/9] em28xx: clean up and unify functions em28xx_copy_vbi() em28xx_copy_video() Frank Schäfer
[not found] ` <CAGoCfiw1wN+KgvNLqDSmbz5AwswPT9K48XOM4RnfKvHkmmR59g@mail.gmail.com>
2012-12-13 17:56 ` Frank Schäfer [this message]
2012-12-13 18:16 ` [PATCH 0/9] em28xx: refactor the frame data processing code Devin Heitmueller
2012-12-14 15:24 ` Frank Schäfer
2012-12-14 15:29 ` Devin Heitmueller
2012-12-14 15:45 ` Frank Schäfer
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=50CA16EB.7060201@googlemail.com \
--to=fschaefer.oss@googlemail.com \
--cc=dheitmueller@kernellabs.com \
--cc=linux-media@vger.kernel.org \
/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).