Re: Patch update notification: 37 patches updated

Re: Patch update notification: 37 patches updated

[Frank Schäfer]

Hi Mauro,

Am 23.12.2012 01:08, schrieb Patchwork:
> Hello,
>
> The following patches (submitted by you) have been updated in patchwork:
>
>  * [3/6] em28xx: fix capture type setting in em28xx_urb_data_copy_vbi()
>      - http://patchwork.linuxtv.org/patch/15651/
>     was: New
>     now: Accepted
>
>  * [8/9] em28xx: move the em2710/em2750/em28xx specific frame data processing code to a separate function
>      - http://patchwork.linuxtv.org/patch/15798/
>     was: New
>     now: Accepted
>
>  * [4/6] em28xx: fix/improve frame field handling in em28xx_urb_data_copy_vbi()
>      - http://patchwork.linuxtv.org/patch/15652/
>     was: New
>     now: Accepted

This patch has not been applied yet to the media-tree.
Without this patch, frame data processing for non-interlaced devices is
broken.

Regards,
Frank

>  * [v2,18/21] em28xx: add fields for analog and DVB USB transfer type selection to struct em28xx
>      - http://patchwork.linuxtv.org/patch/15400/
>     was: New
>     now: Accepted
>
>  * [v2,07/21] em28xx: update description of em28xx_irq_callback
>      - http://patchwork.linuxtv.org/patch/15389/
>     was: New
>     now: Accepted
>
>  * [v2,15/21] em28xx: rename function em28xx_dvb_isoc_copy and extend for USB bulk transfers
>      - http://patchwork.linuxtv.org/patch/15397/
>     was: New
>     now: Accepted
>
>  * [v2,11/21] em28xx: clear USB halt/stall condition in em28xx_init_usb_xfer when using bulk transfers
>      - http://patchwork.linuxtv.org/patch/15393/
>     was: New
>     now: Accepted
>
>  * [7/9] em28xx: em28xx_urb_data_copy(): move duplicate code for capture_type=0 and capture_type=2 to a function
>      - http://patchwork.linuxtv.org/patch/15797/
>     was: New
>     now: Accepted
>
>  * [v2,05/21] em28xx: rename struct em28xx_usb_isoc_ctl to em28xx_usb_ctl
>      - http://patchwork.linuxtv.org/patch/15387/
>     was: New
>     now: Accepted
>
>  * [v2,19/21] em28xx: set USB alternate settings for analog video bulk transfers properly
>      - http://patchwork.linuxtv.org/patch/15401/
>     was: New
>     now: Accepted
>
>  * [v2,08/21] em28xx: rename function em28xx_uninit_isoc to em28xx_uninit_usb_xfer
>      - http://patchwork.linuxtv.org/patch/15390/
>     was: New
>     now: Accepted
>
>  * [1/6] em28xx: fix video data start position calculation in em28xx_urb_data_copy_vbi()
>      - http://patchwork.linuxtv.org/patch/15649/
>     was: New
>     now: Accepted
>
>  * [v2,10/21] em28xx: create a common function for isoc and bulk USB transfer initialization
>      - http://patchwork.linuxtv.org/patch/15392/
>     was: New
>     now: Accepted
>
>  * [6/9] em28xx: move caching of pointer to vmalloc memory in videobuf to struct em28xx_buffer
>      - http://patchwork.linuxtv.org/patch/15796/
>     was: New
>     now: Accepted
>
>  * [2/6] em28xx: make sure the packet size is >= 4 before checking for headers in em28xx_urb_data_copy_vbi()
>      - http://patchwork.linuxtv.org/patch/15650/
>     was: New
>     now: Accepted
>
>  * [1/9] em28xx: refactor get_next_buf() and use it for vbi data, too
>      - http://patchwork.linuxtv.org/patch/15793/
>     was: New
>     now: Accepted
>
>  * [v2,09/21] em28xx: create a common function for isoc and bulk URB allocation and setup
>      - http://patchwork.linuxtv.org/patch/15391/
>     was: New
>     now: Accepted
>
>  * [v2,21/21] em28xx: add module parameter for selection of the preferred USB transfer type
>      - http://patchwork.linuxtv.org/patch/15403/
>     was: New
>     now: Accepted
>
>  * [v2,04/21] em28xx: rename struct em28xx_usb_isoc_bufs to em28xx_usb_bufs
>      - http://patchwork.linuxtv.org/patch/15386/
>     was: New
>     now: Accepted
>
>  * [5/9] em28xx: refactor VBI data processing code in em28xx_urb_data_copy()
>      - http://patchwork.linuxtv.org/patch/15795/
>     was: New
>     now: Accepted
>
>  * [3/9] em28xx: remove obsolete field 'frame' from struct em28xx_buffer
>      - http://patchwork.linuxtv.org/patch/15794/
>     was: New
>     now: Accepted
>
>  * [6/6] em28xx: use common urb data copying function for vbi and non-vbi data streams
>      - http://patchwork.linuxtv.org/patch/15654/
>     was: New
>     now: Accepted
>
>  * [v2,20/21] em28xx: improve USB endpoint logic, also use bulk transfers
>      - http://patchwork.linuxtv.org/patch/15402/
>     was: New
>     now: Accepted
>
>  * [v2,02/21] em28xx: clarify meaning of field 'progressive' in struct em28xx
>      - http://patchwork.linuxtv.org/patch/15384/
>     was: New
>     now: Accepted
>
>  * [4/9] em28xx: move field 'pos' from struct em28xx_dmaqueue to struct em28xx_buffer
>      - http://patchwork.linuxtv.org/patch/15801/
>     was: New
>     now: Accepted
>
>  * [2/9] em28xx: use common function for video and vbi buffer completion
>      - http://patchwork.linuxtv.org/patch/15800/
>     was: New
>     now: Accepted
>
>  * [v2,1/5] em28xx: clean up the data type mess of the i2c transfer function parameters
>      - http://patchwork.linuxtv.org/patch/15914/
>     was: New
>     now: Accepted
>
>  * [v2,03/21] em28xx: rename isoc packet number constants and parameters
>      - http://patchwork.linuxtv.org/patch/15385/
>     was: New
>     now: Accepted
>
>  * [v2,14/21] em28xx: rename function em28xx_isoc_copy_vbi and extend for USB bulk transfers
>      - http://patchwork.linuxtv.org/patch/15396/
>     was: New
>     now: Accepted
>
>  * [5/6] em28xx: em28xx_urb_data_copy_vbi(): calculate vbi_size only if needed
>      - http://patchwork.linuxtv.org/patch/15653/
>     was: New
>     now: Accepted
>
>  * [v2,17/21] em28xx: rename some USB parameter fields in struct em28xx to clarify their role
>      - http://patchwork.linuxtv.org/patch/15399/
>     was: New
>     now: Accepted
>
>  * [v2,12/21] em28xx: remove double checks for urb->status == -ENOENT in urb_data_copy functions
>      - http://patchwork.linuxtv.org/patch/15394/
>     was: New
>     now: Accepted
>
>  * [9/9] em28xx: clean up and unify functions em28xx_copy_vbi() em28xx_copy_video()
>      - http://patchwork.linuxtv.org/patch/15799/
>     was: New
>     now: Accepted
>
>  * [v2,01/21] em28xx: fix wrong data offset for non-interlaced mode in em28xx_copy_video
>      - http://patchwork.linuxtv.org/patch/15383/
>     was: New
>     now: Accepted
>
>  * [v2,13/21] em28xx: rename function em28xx_isoc_copy and extend for USB bulk transfers
>      - http://patchwork.linuxtv.org/patch/15395/
>     was: New
>     now: Accepted
>
>  * [v2,06/21] em28xx: remove obsolete #define EM28XX_URB_TIMEOUT
>      - http://patchwork.linuxtv.org/patch/15388/
>     was: New
>     now: Accepted
>
>  * [v2,16/21] em28xx: rename usb debugging module parameter and macro
>      - http://patchwork.linuxtv.org/patch/15398/
>     was: New
>     now: Rejected
>
> This email is a notification only - you do not need to respond.
>
> -
>
> Patches submitted to linux-media@vger.kernel.org have the following
> possible states:
>
> New: Patches not yet reviewed (typically new patches);
>
> Under review: When it is expected that someone is reviewing it (typically,
> 	      the driver's author or maintainer). Unfortunately, patchwork
> 	      doesn't have a field to indicate who is the driver maintainer.
> 	      If in doubt about who is the driver maintainer please check the
> 	      MAINTAINERS file or ask at the ML;
>
> Superseded: when the same patch is sent twice, or a new version of the
> 	    same patch is sent, and the maintainer identified it, the first
> 	    version is marked as such. It is also used when a patch was
> 	    superseeded by a git pull request.
>
> Obsoleted: patch doesn't apply anymore, because the modified code doesn't
> 	   exist anymore.
>
> Changes requested: when someone requests changes at the patch;
>
> Rejected: When the patch is wrong or doesn't apply. Most of the
> 	  time, 'rejected' and 'changes requested' means the same thing
> 	  for the developer: he'll need to re-work on the patch.
>
> RFC: patches marked as such and other patches that are also RFC, but the
>      patch author was not nice enough to mark them as such. That includes:
> 	- patches sent by a driver's maintainer who send patches
> 	  via git pull requests;
> 	- patches with a very active community (typically from developers
> 	  working with embedded devices), where lots of versions are
> 	  needed for the driver maintainer and/or the community to be
> 	  happy with.
>
> Not Applicable: for patches that aren't meant to be applicable via 
> 	        the media-tree.git.
>
> Accepted: when some driver maintainer says that the patch will be applied
> 	  via his tree, or when everything is ok and it got applied
> 	  either at the main tree or via some other tree (fixes tree;
> 	  some other maintainer's tree - when it belongs to other subsystems,
> 	  etc);
>
> If you think any status change is a mistake, please send an email to the ML.
>
> -
>
> This is an automated mail sent by the patchwork system at
> patchwork.linuxtv.org. To stop receiving these notifications, edit
> your mail settings at:
>   http://patchwork.linuxtv.org/mail/

Re: Patch update notification: 37 patches updated

[Mauro Carvalho Chehab]

Em Sun, 23 Dec 2012 14:45:31 +0100
Frank Schäfer <fschaefer.oss@googlemail.com> escreveu:

> Hi Mauro,
> 
> Am 23.12.2012 01:08, schrieb Patchwork:
> > Hello,
> >
> > The following patches (submitted by you) have been updated in patchwork:
> >
> >  * [3/6] em28xx: fix capture type setting in em28xx_urb_data_copy_vbi()
> >      - http://patchwork.linuxtv.org/patch/15651/
> >     was: New
> >     now: Accepted
> >
> >  * [8/9] em28xx: move the em2710/em2750/em28xx specific frame data processing code to a separate function
> >      - http://patchwork.linuxtv.org/patch/15798/
> >     was: New
> >     now: Accepted
> >
> >  * [4/6] em28xx: fix/improve frame field handling in em28xx_urb_data_copy_vbi()
> >      - http://patchwork.linuxtv.org/patch/15652/
> >     was: New
> >     now: Accepted
> 
> This patch has not been applied yet to the media-tree.
> Without this patch, frame data processing for non-interlaced devices is
> broken.

Not sure what happened there: I couldn't see this specific patch. Yet,
at least some of the changes there seem to be applied. My guess is that
somehow, this patch got merged with some other patch, or maybe the
conflicts solving when the vbi-merge patches got applied (partially)
fixed it.

In any case, you'll need to rebase it, as it doesn't apply anymore.


Cheers,
Mauro

Re: Patch update notification: 37 patches updated

[Frank Schäfer]

Am 23.12.2012 15:57, schrieb Mauro Carvalho Chehab:
> Em Sun, 23 Dec 2012 14:45:31 +0100
> Frank Schäfer <fschaefer.oss@googlemail.com> escreveu:
>
>> Hi Mauro,
>>
>> Am 23.12.2012 01:08, schrieb Patchwork:
>>> Hello,
>>>
>>> The following patches (submitted by you) have been updated in patchwork:
>>>
>>>  * [3/6] em28xx: fix capture type setting in em28xx_urb_data_copy_vbi()
>>>      - http://patchwork.linuxtv.org/patch/15651/
>>>     was: New
>>>     now: Accepted
>>>
>>>  * [8/9] em28xx: move the em2710/em2750/em28xx specific frame data processing code to a separate function
>>>      - http://patchwork.linuxtv.org/patch/15798/
>>>     was: New
>>>     now: Accepted
>>>
>>>  * [4/6] em28xx: fix/improve frame field handling in em28xx_urb_data_copy_vbi()
>>>      - http://patchwork.linuxtv.org/patch/15652/
>>>     was: New
>>>     now: Accepted
>> This patch has not been applied yet to the media-tree.
>> Without this patch, frame data processing for non-interlaced devices is
>> broken.
> Not sure what happened there: I couldn't see this specific patch. Yet,
> at least some of the changes there seem to be applied. My guess is that
> somehow, this patch got merged with some other patch, or maybe the
> conflicts solving when the vbi-merge patches got applied (partially)
> fixed it.
>
> In any case, you'll need to rebase it, as it doesn't apply anymore.

Ok, I did a git diff against my local version and all changes (except
the remaining i2c stuff) seem to be applied.

One thing I noticed: you fixed strings with lines > 80 characters.
This is handled differently everywhere...
I know splitting strings breaks grepping, OTOH checkpatch complains.
So you prefer violating the 80 chars rule ?

Regards,
Frank

> Cheers,
> Mauro

Re: Patch update notification: 37 patches updated

[Mauro Carvalho Chehab]

Em Mon, 24 Dec 2012 11:56:22 +0100
Frank Schäfer <fschaefer.oss@googlemail.com> escreveu:

> Am 23.12.2012 15:57, schrieb Mauro Carvalho Chehab:
> > Em Sun, 23 Dec 2012 14:45:31 +0100
> > Frank Schäfer <fschaefer.oss@googlemail.com> escreveu:
> >
> >> Hi Mauro,
> >>
> >> Am 23.12.2012 01:08, schrieb Patchwork:
> >>> Hello,
> >>>
> >>> The following patches (submitted by you) have been updated in patchwork:
> >>>
> >>>  * [3/6] em28xx: fix capture type setting in em28xx_urb_data_copy_vbi()
> >>>      - http://patchwork.linuxtv.org/patch/15651/
> >>>     was: New
> >>>     now: Accepted
> >>>
> >>>  * [8/9] em28xx: move the em2710/em2750/em28xx specific frame data processing code to a separate function
> >>>      - http://patchwork.linuxtv.org/patch/15798/
> >>>     was: New
> >>>     now: Accepted
> >>>
> >>>  * [4/6] em28xx: fix/improve frame field handling in em28xx_urb_data_copy_vbi()
> >>>      - http://patchwork.linuxtv.org/patch/15652/
> >>>     was: New
> >>>     now: Accepted
> >> This patch has not been applied yet to the media-tree.
> >> Without this patch, frame data processing for non-interlaced devices is
> >> broken.
> > Not sure what happened there: I couldn't see this specific patch. Yet,
> > at least some of the changes there seem to be applied. My guess is that
> > somehow, this patch got merged with some other patch, or maybe the
> > conflicts solving when the vbi-merge patches got applied (partially)
> > fixed it.
> >
> > In any case, you'll need to rebase it, as it doesn't apply anymore.
> 
> Ok, I did a git diff against my local version and all changes (except
> the remaining i2c stuff) seem to be applied.
> 
> One thing I noticed: you fixed strings with lines > 80 characters.
> This is handled differently everywhere...
> I know splitting strings breaks grepping, OTOH checkpatch complains.
> So you prefer violating the 80 chars rule ?

80-chars is a warning, and, from time to time, it rises discussions here
and at LKML, as there are know cases where this is violated for good.

We prefer to not break long string lines due to grep. It also can makes the
code a little more obfuscate (like on one place on your patchset where
the same string was broken into 3 or 4 lines).

The hole idea of the 80 cols rule is to avoid obfuscation, by avoiding
having complex logic inside the Kernel, and not to create more obfuscation ;)

Of course, we don't want a big "style fix" patch changing it, but, as the
code is being touched, we fix those style stuff.

Regards,
Mauro