Am 14.12.2012 16:29, schrieb Devin Heitmueller:
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
>>> 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
Am 13.12.2012 19:16, schrieb Devin Heitmueller:
> On Thu, Dec 13, 2012 at 12:56 PM, Frank Schäfer
> wrote:
>> Am 13.12.2012 18:36, schrieb Devin Heitmueller:
>>> On Sat, Dec 8, 2012 at 10:31 AM, Frank Schäfer
>>> wrote:
This patch series refactors the frame data processing code in
em28
On Thu, Dec 13, 2012 at 12:56 PM, Frank Schäfer
wrote:
> Am 13.12.2012 18:36, schrieb Devin Heitmueller:
>> On Sat, Dec 8, 2012 at 10:31 AM, Frank Schäfer
>> wrote:
>>> This patch series refactors the frame data processing code in
>>> em28xx-video.c to
>>> - reduce code duplication
>>> - fix a b
Am 13.12.2012 18:36, schrieb Devin Heitmueller:
> On Sat, Dec 8, 2012 at 10:31 AM, Frank Schäfer
> 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
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
It applies on top of my previous patch
