Re: [PATCH] em28xx: Fix height setting on non-progressive captures
Em 04-08-2012 05:53, llar...@gmx.net escreveu:
Wait a minute, unless I completely misunderstood the bug (which is
possible),
I think this patch is straightforward.
By the look of this hunk on commit c2a6b54a:
-8--
diff --git a/drivers/media/video/em28xx/em28xx-core.c
b/drivers/media/video/em28xx/em28xx-core.c
index 5b78e19..339fffd 100644
--- a/drivers/media/video/em28xx/em28xx-core.c
+++ b/drivers/media/video/em28xx/em28xx-core.c
@@ -720,7 +720,10 @@ int em28xx_resolution_set(struct em28xx *dev)
{
int width, height;
width = norm_maxw(dev);
- height = norm_maxh(dev) 1;
+ height = norm_maxh(dev);
+
+ if (!dev-progressive)
+ height = norm_maxh(dev);
-8--
It seems to me that for non-progressive the height should just be
height = height / 2 (or height = height 1)
as was before, and as my patch is doing. It seems to driver will
merge the interlaced
frames and so the expected height is half the real height.
I hope I got it right.
That said and no matter how straightforward may be, which I'm not sure,
I also want the patch to get tested before being accepted.
I own a Terratec Cinergy XS USB in two flavors: 0ccd:005e and
0ccd:0042. I work with Fedora F17. If somebody gives me an advice what
code to patch (git or a tarball from
http://linuxtv.org/downloads/drivers/) and what to test, I can make a
try.
Thanks for your offering, but this should affect only em28xx-based
webcams (like the Silvercrest one).
I have a few here. I'll do the testing.
Regards,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linaro-mm-sig] [PATCH 2/4] dma-fence: dma-buf synchronization (v8 )
On Fri, Aug 10, 2012 at 04:57:52PM +0200, Maarten Lankhorst wrote:
A dma-fence can be attached to a buffer which is being filled or consumed
by hw, to allow userspace to pass the buffer without waiting to another
device. For example, userspace can call page_flip ioctl to display the
next frame of graphics after kicking the GPU but while the GPU is still
rendering. The display device sharing the buffer with the GPU would
attach a callback to get notified when the GPU's rendering-complete IRQ
fires, to update the scan-out address of the display, without having to
wake up userspace.
A dma-fence is transient, one-shot deal. It is allocated and attached
to one or more dma-buf's. When the one that attached it is done, with
the pending operation, it can signal the fence.
+ dma_fence_signal()
The dma-buf-mgr handles tracking, and waiting on, the fences associated
with a dma-buf.
TODO maybe need some helper fxn for simple devices, like a display-
only drm/kms device which simply wants to wait for exclusive fence to
be signaled, and then attach a non-exclusive fence while scanout is in
progress.
The one pending on the fence can add an async callback:
+ dma_fence_add_callback()
The callback can optionally be cancelled with remove_wait_queue()
Or wait synchronously (optionally with timeout or interruptible):
+ dma_fence_wait()
A default software-only implementation is provided, which can be used
by drivers attaching a fence to a buffer when they have no other means
for hw sync. But a memory backed fence is also envisioned, because it
is common that GPU's can write to, or poll on some memory location for
synchronization. For example:
fence = dma_buf_get_fence(dmabuf);
if (fence-ops == bikeshed_fence_ops) {
dma_buf *fence_buf;
dma_bikeshed_fence_get_buf(fence, fence_buf, offset);
... tell the hw the memory location to wait on ...
} else {
/* fall-back to sw sync * /
dma_fence_add_callback(fence, my_cb);
}
On SoC platforms, if some other hw mechanism is provided for synchronizing
between IP blocks, it could be supported as an alternate implementation
with it's own fence ops in a similar way.
To facilitate other non-sw implementations, the enable_signaling callback
can be used to keep track if a device not supporting hw sync is waiting
on the fence, and in this case should arrange to call dma_fence_signal()
at some point after the condition has changed, to notify other devices
waiting on the fence. If there are no sw waiters, this can be skipped to
avoid waking the CPU unnecessarily. The handler of the enable_signaling
op should take a refcount until the fence is signaled, then release its ref.
The intention is to provide a userspace interface (presumably via eventfd)
later, to be used in conjunction with dma-buf's mmap support for sw access
to buffers (or for userspace apps that would prefer to do their own
synchronization).
v1: Original
v2: After discussion w/ danvet and mlankhorst on #dri-devel, we decided
that dma-fence didn't need to care about the sw-hw signaling path
(it can be handled same as sw-sw case), and therefore the fence-ops
can be simplified and more handled in the core. So remove the signal,
add_callback, cancel_callback, and wait ops, and replace with a simple
enable_signaling() op which can be used to inform a fence supporting
hw-hw signaling that one or more devices which do not support hw
signaling are waiting (and therefore it should enable an irq or do
whatever is necessary in order that the CPU is notified when the
fence is passed).
v3: Fix locking fail in attach_fence() and get_fence()
v4: Remove tie-in w/ dma-buf.. after discussion w/ danvet and mlankorst
we decided that we need to be able to attach one fence to N dma-buf's,
so using the list_head in dma-fence struct would be problematic.
v5: [ Maarten Lankhorst ] Updated for dma-bikeshed-fence and dma-buf-manager.
v6: [ Maarten Lankhorst ] I removed dma_fence_cancel_callback and some
comments
about checking if fence fired or not. This is broken by design.
waitqueue_active during destruction is now fatal, since the signaller
should be holding a reference in enable_signalling until it signalled
the fence. Pass the original dma_fence_cb along, and call __remove_wait
in the dma_fence_callback handler, so that no cleanup needs to be
performed.
v7: [ Maarten Lankhorst ] Set cb-func and only enable sw signaling if
fence wasn't signaled yet, for example for hardware fences that may
choose to signal blindly.
v8: [ Maarten Lankhorst ] Tons of tiny fixes, moved __dma_fence_init to
header and fixed include mess. dma-fence.h now includes dma-buf.h
All members are now initialized, so kmalloc can be used for
allocating a dma-fence. More documentation added.
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
Re: [PATCH] em28xx: Fix height setting on non-progressive captures
Em 03-08-2012 14:52, Ezequiel Garcia escreveu: This was introduced on commit c2a6b54a9: em28xx: fix: don't do image interlacing on webcams It is a known bug that has already been reported several times and confirmed by Mauro. Thanks for reminding us about that. Tested by compilation only. Signed-off-by: Ezequiel Garcia elezegar...@gmail.com --- Hi, I have no idea why this hasn't been fixed before. The reason was because that patch didn't work ;) See this mail for Mauro's confirmation http://www.digipedia.pl/usenet/thread/18550/7691/#post7685 where he requested a patch on reporter. I guess the patch never came in. Did some tests here with both TV and Webcam (progressive) devices. The enclosed patch fixes the issue. Regards, Mauro. [media] em28xx: Fix height setting on non-progressive captures This was introduced on commit c2a6b54a9: em28xx: fix: don't do image interlacing on webcams The proposed patch by Ezequiel is wrong. The right fix here is to just don't bother here if either the image is progressive or not. Reported-by: Ezequiel Garcia elezegar...@gmail.com Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com diff --git a/drivers/media/video/em28xx/em28xx-core.c b/drivers/media/video/em28xx/em28xx-core.c index de2cb20..bed07a6 100644 --- a/drivers/media/video/em28xx/em28xx-core.c +++ b/drivers/media/video/em28xx/em28xx-core.c @@ -785,12 +785,8 @@ int em28xx_resolution_set(struct em28xx *dev) else dev-vbi_height = 18; - if (!dev-progressive) - height = norm_maxh(dev); - em28xx_set_outfmt(dev); - em28xx_accumulator_set(dev, 1, (width - 4) 2, 1, (height - 4) 2); /* If we don't set the start position to 2 in VBI mode, we end up -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] Add core TMC (Traffic Message Channel) support
Hi,
Looks good to me.
Regards,
Hans
On 08/10/2012 07:04 PM, Konke Radlow wrote:
Signed-off-by: Konke Radlow korad...@gmail.com
---
lib/include/libv4l2rds.h| 64
lib/libv4l2rds/libv4l2rds.c | 340 ++-
utils/rds-ctl/rds-ctl.cpp | 31 +++-
3 files changed, 432 insertions(+), 3 deletions(-)
diff --git a/lib/include/libv4l2rds.h b/lib/include/libv4l2rds.h
index 37bdd2f..caefc1a 100644
--- a/lib/include/libv4l2rds.h
+++ b/lib/include/libv4l2rds.h
@@ -63,6 +63,9 @@ extern C {
#define V4L2_RDS_AF 0x800 /* AF (alternative freq) available */
#define V4L2_RDS_ECC 0x1000 /* Extended County Code */
#define V4L2_RDS_LC 0x2000 /* Language Code */
+#define V4L2_RDS_TMC_SG0x4000 /* RDS-TMC single group */
+#define V4L2_RDS_TMC_MG0x8000 /* RDS-TMC multi group */
+#define V4L2_RDS_TMC_SYS 0x1 /* RDS-TMC system information */
/* Define Constants for the state of the RDS decoding process
* used to address the relevant bit in the decode_information bitmask */
@@ -76,6 +79,11 @@ extern C {
#define V4L2_RDS_FLAG_COMPRESSED 0x04
#define V4L2_RDS_FLAG_STATIC_PTY 0x08
+/* TMC related codes
+ * used to extract TMC fields from RDS groups */
+#define V4L2_TMC_TUNING_INFO 0x08
+#define V4L2_TMC_SINGLE_GROUP 0x04
+
/* struct to encapsulate one complete RDS group */
/* This structure is used internally to store data until a complete RDS
* group was received and group id dependent decoding can be done.
@@ -137,6 +145,61 @@ struct v4l2_rds_af_set {
uint32_t af[MAX_AF_CNT];/* AFs defined in Hz */
};
+/* struct to encapsulate an additional data field in a TMC message */
+struct v4l2_tmc_additional {
+ uint8_t label;
+ uint16_t data;
+};
+
+/* struct to encapsulate an arbitrary number of additional data fields
+ * belonging to one TMC message */
+struct v4l2_tmc_additional_set {
+ uint8_t size;
+ /* 28 is the maximal possible number of fields. Additional data
+* is limited to 112 bit, and the smallest optional tuple has
+* a size of 4 bit (4 bit identifier + 0 bits of data) */
+ struct v4l2_tmc_additional fields[28];
+};
+
+/* struct to encapsulate a decoded TMC message with optional additional
+ * data field (in case of a multi-group TMC message) */
+struct v4l2_rds_tmc_msg {
+ uint8_t length; /* length of multi-group message (0..4) */
+ uint8_t sid;/* service identifier at time of reception */
+ uint8_t extent;
+ uint8_t dp; /* duration and persistence */
+ uint16_t event; /* TMC event code */
+ uint16_t location; /* TMC event location */
+ bool follow_diversion; /* indicates if the driver is adviced to
+* follow the diversion */
+ bool neg_direction; /* indicates negative / positive direction */
+
+ /* decoded additional information (only available in multi-group
+* messages) */
+ struct v4l2_tmc_additional_set additional;
+};
+
+/* struct to encapsulate all TMC related information, including TMC System
+ * Information, TMC Tuning information and a buffer for the last decoded
+ * TMC messages */
+struct v4l2_rds_tmc {
+ uint8_t ltn;/* location_table_number */
+ bool afi; /* alternative frequency indicator */
+ bool enhanced_mode; /* mode of transmission,
+* if false - basic = gaps between tmc groups
+* gap defines timing behavior
+* if true - enhanced = t_a, t_w and t_d
+* define timing behavior of tmc groups */
+ uint8_t mgs;/* message geographical scope */
+ uint8_t sid;/* service identifier (unique ID on national
level) */
+ uint8_t gap;/* Gap parameters */
+ uint8_t t_a;/* activity time (only if mode = enhanced) */
+ uint8_t t_w;/* window time (only if mode = enhanced */
+ uint8_t t_d;/* delay time (only if mode = enhanced */
+ uint8_t spn[9]; /* service provider name */
+ struct v4l2_rds_tmc_msg tmc_msg;
+};
+
/* struct to encapsulate state and RDS information for current decoding
process */
/* This is the structure that will be used by external applications, to
* communicate with the library and get access to RDS data */
@@ -172,6 +235,7 @@ struct v4l2_rds {
struct v4l2_rds_statistics rds_statistics;
struct v4l2_rds_oda_set rds_oda;/* Open Data Services */
struct v4l2_rds_af_set rds_af; /* Alternative Frequencies */
+ struct v4l2_rds_tmc tmc;/* TMC information */
};
/* v4l2_rds_init() - initializes a new decoding process
diff --git a/lib/libv4l2rds/libv4l2rds.c
Re: [PATCH] staging: media: cxd2099: remove memcpy of similar structure variables
Em 06-08-2012 07:40, Ezequiel Garcia escreveu: On Mon, Aug 6, 2012 at 2:28 AM, Devendra Naga develkernel412...@gmail.com wrote: Hi Ezequiel, On Mon, Aug 6, 2012 at 3:36 AM, Ezequiel Garcia elezegar...@gmail.com wrote: Hi Devendra, Thanks for the patch, On Sun, Aug 5, 2012 at 5:40 PM, Devendra Naga develkernel412...@gmail.com wrote: structure variables can be assigned, no memcpy needed, remove the memcpy and use assignment for the cfg and en variables. Tested by Compilation Only Suggested-by: Ezequiel Garcia elezegar...@gmail.com I'm not sure this is completely valid or useful. If you read Documentation/SubmittingPatches (which you should) you will find references to Acked-by, Reported-by, Tested-by, but not this one. You don't need to give me credit for the patch: it's *your* patch, all I did was a very simple suggestion :-) Ok. I will remove the Suggested-by line and send out the patch again with PATCH RESEND subject line. Is it ok? I'm not entirely sure. Perhaps you can leave it as it is, and let Mauro remove that line. I prefer keeping it, to preserve this patch history. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[git:v4l-dvb/for_v3.7] [media] cpia2: Declare MODULE_FIRMWARE usage
This is an automatic generated email to let you know that the following patch
were queued at the
http://git.linuxtv.org/media_tree.git tree:
Subject: [media] cpia2: Declare MODULE_FIRMWARE usage
Author: Tim Gardner tim.gard...@canonical.com
Date:Fri Aug 3 13:39:28 2012 -0300
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: Hans Verkuil hans.verk...@cisco.com
Cc: linux-media@vger.kernel.org
Signed-off-by: Tim Gardner tim.gard...@canonical.com
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
drivers/media/video/cpia2/cpia2_core.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
---
http://git.linuxtv.org/media_tree.git?a=commitdiff;h=229fd7d2f19c650c34034885180f91574e837bbb
diff --git a/drivers/media/video/cpia2/cpia2_core.c
b/drivers/media/video/cpia2/cpia2_core.c
index 17188e2..187012c 100644
--- a/drivers/media/video/cpia2/cpia2_core.c
+++ b/drivers/media/video/cpia2/cpia2_core.c
@@ -31,11 +31,15 @@
#include cpia2.h
+#include linux/module.h
#include linux/slab.h
#include linux/mm.h
#include linux/vmalloc.h
#include linux/firmware.h
+#define FIRMWARE cpia2/stv0672_vp4.bin
+MODULE_FIRMWARE(FIRMWARE);
+
/* #define _CPIA2_DEBUG_ */
#ifdef _CPIA2_DEBUG_
@@ -898,7 +902,7 @@ static int cpia2_send_onebyte_command(struct camera_data
*cam,
static int apply_vp_patch(struct camera_data *cam)
{
const struct firmware *fw;
- const char fw_name[] = cpia2/stv0672_vp4.bin;
+ const char fw_name[] = FIRMWARE;
int i, ret;
struct cpia2_command cmd;
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Patchwork notifications for '[RESEND,media] v4l2: define V4L2_PIX_FMT_NV16M and V4L2_PIX_FMT_NV24M pixel formats'
Hi, On Sun, Aug 12, 2012 at 2:58 AM, Patchwork patchw...@linuxtv.org wrote: Hello, The following patches (submitted by you) have been updated in patchwork: * [RESEND,media] v4l2: define V4L2_PIX_FMT_NV16M and V4L2_PIX_FMT_NV24M pixel formats - http://patchwork.linuxtv.org/patch/13555/ was: New now: Superseded * [RESEND,media] v4l2: define V4L2_PIX_FMT_NV16M and V4L2_PIX_FMT_NV24M pixel formats - http://patchwork.linuxtv.org/patch/13556/ was: New now: Changes Requested Patchwork has moved my V4L2_PIX_FMT_NV16M and V4L2_PIX_FMT_NV24M definitions patch (http://patchwork.linuxtv.org/patch/13556) from New to Changes Requested, but I couldn't look-up what changes need to be made. Where can I find such feedback? Just for the record, in a previous conversation with Mauro, he suggested that new pixel formats don't get defined in the kernel unless a v4l2 device driver is actually using them (so suggesting to also upstream the driver, which isn't immediately possible). -Ilyes 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; 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/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] DocBook validation fixes
More validation fixes as reported by xmllint.
There are still three xmllint errors remaining after this patch regarding SVG
file support.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
Documentation/DocBook/media/Makefile |2 +-
Documentation/DocBook/media/dvb/dvbproperty.xml| 20 +-
Documentation/DocBook/media/dvb/frontend.xml | 20 ++
Documentation/DocBook/media/v4l/controls.xml |4 +++-
Documentation/DocBook/media/v4l/dev-subdev.xml | 20 +-
.../DocBook/media/v4l/pixfmt-srggb10dpcm8.xml |3 +--
Documentation/DocBook/media/v4l/selection-api.xml | 22 ++--
.../DocBook/media/v4l/vidioc-g-selection.xml |9
Documentation/DocBook/media/v4l/vidioc-qbuf.xml|2 ++
.../media/v4l/vidioc-subdev-g-selection.xml|8 +++
10 files changed, 57 insertions(+), 53 deletions(-)
diff --git a/Documentation/DocBook/media/Makefile
b/Documentation/DocBook/media/Makefile
index 3625209..9b7e4c5 100644
--- a/Documentation/DocBook/media/Makefile
+++ b/Documentation/DocBook/media/Makefile
@@ -300,7 +300,7 @@ $(MEDIA_OBJ_DIR)/media-entities.tmpl:
$(MEDIA_OBJ_DIR)/v4l2.xml
@( \
for ident in $(IOCTLS) ; do \
entity=`echo $$ident | tr _ -` ; \
- id=`grep refname$$ident $(MEDIA_OBJ_DIR)/vidioc-*.xml | sed -r
s,^.*/(.*).xml.*,\1,` ; \
+ id=`grep refname$$ident $(MEDIA_OBJ_DIR)/vidioc-*.xml
$(MEDIA_OBJ_DIR)/media-ioc-*.xml | sed -r s,^.*/(.*).xml.*,\1,` ; \
echo !ENTITY $$entity \link \
linkend='$$id'constant$$ident/constant/link\ \
$@ ;\
diff --git a/Documentation/DocBook/media/dvb/dvbproperty.xml
b/Documentation/DocBook/media/dvb/dvbproperty.xml
index bb4777a..8adab98 100644
--- a/Documentation/DocBook/media/dvb/dvbproperty.xml
+++ b/Documentation/DocBook/media/dvb/dvbproperty.xml
@@ -567,33 +567,33 @@ typedef enum fe_delivery_system {
titleconstantDTV_ATSCMH_RS_FRAME_MODE/constant/title
paraRS frame mode./para
paraPossible values are:/para
- section id=atscmh-rs-frame-mode
+ para id=atscmh-rs-frame-mode
programlisting
typedef enum atscmh_rs_frame_mode {
ATSCMH_RSFRAME_PRI_ONLY = 0,
ATSCMH_RSFRAME_PRI_SEC = 1,
} atscmh_rs_frame_mode_t;
/programlisting
- /section
+ /para
/section
section id=DTV-ATSCMH-RS-FRAME-ENSEMBLE
titleconstantDTV_ATSCMH_RS_FRAME_ENSEMBLE/constant/title
paraRS frame ensemble./para
paraPossible values are:/para
- section id=atscmh-rs-frame-ensemble
+ para id=atscmh-rs-frame-ensemble
programlisting
typedef enum atscmh_rs_frame_ensemble {
ATSCMH_RSFRAME_ENS_PRI = 0,
ATSCMH_RSFRAME_ENS_SEC = 1,
} atscmh_rs_frame_ensemble_t;
/programlisting
- /section
+ /para
/section
section id=DTV-ATSCMH-RS-CODE-MODE-PRI
titleconstantDTV_ATSCMH_RS_CODE_MODE_PRI/constant/title
paraRS code mode (primary)./para
paraPossible values are:/para
- section id=atscmh-rs-code-mode
+ para id=atscmh-rs-code-mode
programlisting
typedef enum atscmh_rs_code_mode {
ATSCMH_RSCODE_211_187= 0,
@@ -601,7 +601,7 @@ typedef enum atscmh_rs_code_mode {
ATSCMH_RSCODE_235_187= 2,
} atscmh_rs_code_mode_t;
/programlisting
- /section
+ /para
/section
section id=DTV-ATSCMH-RS-CODE-MODE-SEC
titleconstantDTV_ATSCMH_RS_CODE_MODE_SEC/constant/title
@@ -619,27 +619,27 @@ typedef enum atscmh_rs_code_mode {
titleconstantDTV_ATSCMH_SCCC_BLOCK_MODE/constant/title
paraSeries Concatenated Convolutional Code Block
Mode./para
paraPossible values are:/para
- section id=atscmh-sccc-block-mode
+ para id=atscmh-sccc-block-mode
programlisting
typedef enum atscmh_sccc_block_mode {
ATSCMH_SCCC_BLK_SEP = 0,
ATSCMH_SCCC_BLK_COMB = 1,
} atscmh_sccc_block_mode_t;
/programlisting
- /section
+ /para
/section
section id=DTV-ATSCMH-SCCC-CODE-MODE-A
titleconstantDTV_ATSCMH_SCCC_CODE_MODE_A/constant/title
paraSeries Concatenated Convolutional Code
Rate./para
Re: [RFC PATCH] Add core TMC (Traffic Message Channel) support
On Fri August 10 2012 19:04:52 Konke Radlow wrote:
Signed-off-by: Konke Radlow korad...@gmail.com
---
lib/include/libv4l2rds.h| 64
lib/libv4l2rds/libv4l2rds.c | 340
++-
utils/rds-ctl/rds-ctl.cpp | 31 +++-
3 files changed, 432 insertions(+), 3 deletions(-)
diff --git a/lib/include/libv4l2rds.h b/lib/include/libv4l2rds.h
index 37bdd2f..caefc1a 100644
--- a/lib/include/libv4l2rds.h
+++ b/lib/include/libv4l2rds.h
@@ -63,6 +63,9 @@ extern C {
#define V4L2_RDS_AF 0x800 /* AF (alternative freq) available */
#define V4L2_RDS_ECC 0x1000 /* Extended County Code */
#define V4L2_RDS_LC 0x2000 /* Language Code */
+#define V4L2_RDS_TMC_SG 0x4000 /* RDS-TMC single group */
+#define V4L2_RDS_TMC_MG 0x8000 /* RDS-TMC multi group */
+#define V4L2_RDS_TMC_SYS 0x1 /* RDS-TMC system information */
/* Define Constants for the state of the RDS decoding process
* used to address the relevant bit in the decode_information bitmask */
@@ -76,6 +79,11 @@ extern C {
#define V4L2_RDS_FLAG_COMPRESSED 0x04
#define V4L2_RDS_FLAG_STATIC_PTY 0x08
+/* TMC related codes
+ * used to extract TMC fields from RDS groups */
+#define V4L2_TMC_TUNING_INFO 0x08
+#define V4L2_TMC_SINGLE_GROUP0x04
+
/* struct to encapsulate one complete RDS group */
/* This structure is used internally to store data until a complete RDS
* group was received and group id dependent decoding can be done.
@@ -137,6 +145,61 @@ struct v4l2_rds_af_set {
uint32_t af[MAX_AF_CNT];/* AFs defined in Hz */
};
+/* struct to encapsulate an additional data field in a TMC message */
+struct v4l2_tmc_additional {
+ uint8_t label;
+ uint16_t data;
+};
+
+/* struct to encapsulate an arbitrary number of additional data fields
+ * belonging to one TMC message */
+struct v4l2_tmc_additional_set {
+ uint8_t size;
+ /* 28 is the maximal possible number of fields. Additional data
28 should be a define instead of being hardcoded.
+ * is limited to 112 bit, and the smallest optional tuple has
+ * a size of 4 bit (4 bit identifier + 0 bits of data) */
+ struct v4l2_tmc_additional fields[28];
+};
+
+/* struct to encapsulate a decoded TMC message with optional additional
+ * data field (in case of a multi-group TMC message) */
+struct v4l2_rds_tmc_msg {
+ uint8_t length; /* length of multi-group message (0..4) */
+ uint8_t sid;/* service identifier at time of reception */
+ uint8_t extent;
+ uint8_t dp; /* duration and persistence */
+ uint16_t event; /* TMC event code */
+ uint16_t location; /* TMC event location */
+ bool follow_diversion; /* indicates if the driver is adviced to
+ * follow the diversion */
+ bool neg_direction; /* indicates negative / positive direction */
+
+ /* decoded additional information (only available in multi-group
+ * messages) */
+ struct v4l2_tmc_additional_set additional;
+};
+
+/* struct to encapsulate all TMC related information, including TMC System
+ * Information, TMC Tuning information and a buffer for the last decoded
+ * TMC messages */
+struct v4l2_rds_tmc {
+ uint8_t ltn;/* location_table_number */
+ bool afi; /* alternative frequency indicator */
+ bool enhanced_mode; /* mode of transmission,
+ * if false - basic = gaps between tmc groups
+ * gap defines timing behavior
+ * if true - enhanced = t_a, t_w and t_d
+ * define timing behavior of tmc groups */
+ uint8_t mgs;/* message geographical scope */
+ uint8_t sid;/* service identifier (unique ID on national
level) */
+ uint8_t gap;/* Gap parameters */
+ uint8_t t_a;/* activity time (only if mode = enhanced) */
+ uint8_t t_w;/* window time (only if mode = enhanced */
+ uint8_t t_d;/* delay time (only if mode = enhanced */
+ uint8_t spn[9]; /* service provider name */
+ struct v4l2_rds_tmc_msg tmc_msg;
+};
+
/* struct to encapsulate state and RDS information for current decoding
process */
/* This is the structure that will be used by external applications, to
* communicate with the library and get access to RDS data */
@@ -172,6 +235,7 @@ struct v4l2_rds {
struct v4l2_rds_statistics rds_statistics;
struct v4l2_rds_oda_set rds_oda;/* Open Data Services */
struct v4l2_rds_af_set rds_af; /* Alternative Frequencies */
+ struct v4l2_rds_tmc tmc;/* TMC information */
};
/* v4l2_rds_init() - initializes a new decoding process
diff --git
[GIT PULL FOR v3.7] uvcvideo patches
Hi Mauro, The following changes since commit 518c267f4ca4c45cc51bd582b4aef9f0b9f01eba: [media] saa7164: use native print_hex_dump() instead of custom one (2012-08-12 07:58:54 -0300) are available in the git repository at: git://linuxtv.org/pinchartl/uvcvideo.git uvcvideo-next Jayakrishnan Memana (1): uvcvideo: Reset the bytesused field when recycling an erroneous buffer Laurent Pinchart (2): uvcvideo: Support super speed endpoints uvcvideo: Add support for Ophir Optronics SPCAM 620U cameras Stefan Muenzel (1): uvcvideo: Support 10bit, 12bit and alternate 8bit greyscale formats drivers/media/video/uvc/uvc_driver.c | 28 ++-- drivers/media/video/uvc/uvc_queue.c |1 + drivers/media/video/uvc/uvc_video.c | 30 -- drivers/media/video/uvc/uvcvideo.h |9 + 4 files changed, 60 insertions(+), 8 deletions(-) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 3/3] dvb_frontend: do not allow statistic IOCTLs when sleeping
Em 09-08-2012 19:25, Antti Palosaari escreveu:
Demodulator cannot perform statistic IOCTLs when it is not tuned.
Return -EPERM in such case.
While, in general, doing it makes sense, -EPERM is a very bad return code.
It is used to indicate when accessing some resources would require root access.
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/dvb/dvb-core/dvb_frontend.c | 34
+++
1 file changed, 25 insertions(+), 9 deletions(-)
diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c
b/drivers/media/dvb/dvb-core/dvb_frontend.c
index 4fc11eb..40efcde 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -2157,27 +2157,43 @@ static int dvb_frontend_ioctl_legacy(struct file
*file,
err = fe-ops.read_status(fe, status);
break;
}
+
case FE_READ_BER:
- if (fe-ops.read_ber)
- err = fe-ops.read_ber(fe, (__u32*) parg);
+ if (fe-ops.read_ber) {
+ if (fepriv-thread)
+ err = fe-ops.read_ber(fe, (__u32 *) parg);
+ else
+ err = -EPERM;
+ }
break;
case FE_READ_SIGNAL_STRENGTH:
- if (fe-ops.read_signal_strength)
- err = fe-ops.read_signal_strength(fe, (__u16*) parg);
+ if (fe-ops.read_signal_strength) {
+ if (fepriv-thread)
+ err = fe-ops.read_signal_strength(fe, (__u16
*) parg);
+ else
+ err = -EPERM;
+ }
break;
Signal strength can still be available even without locking.
case FE_READ_SNR:
- if (fe-ops.read_snr)
- err = fe-ops.read_snr(fe, (__u16*) parg);
+ if (fe-ops.read_snr) {
+ if (fepriv-thread)
+ err = fe-ops.read_snr(fe, (__u16 *) parg);
+ else
+ err = -EPERM;
+ }
break;
case FE_READ_UNCORRECTED_BLOCKS:
- if (fe-ops.read_ucblocks)
- err = fe-ops.read_ucblocks(fe, (__u32*) parg);
+ if (fe-ops.read_ucblocks) {
+ if (fepriv-thread)
+ err = fe-ops.read_ucblocks(fe, (__u32 *) parg);
+ else
+ err = -EPERM;
+ }
break;
-
case FE_DISEQC_RESET_OVERLOAD:
if (fe-ops.diseqc_reset_overload) {
err = fe-ops.diseqc_reset_overload(fe);
Regards,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 2/3] dvb_frontend: return -ENOTTY for unimplement IOCTL
Em 09-08-2012 19:25, Antti Palosaari escreveu:
Earlier it was returning -EOPNOTSUPP.
This change makes all sense to me. We just need to be sure that this won't
cause any regressions on userspace apps.
Regards,
Mauro
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/dvb/dvb-core/dvb_frontend.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c
b/drivers/media/dvb/dvb-core/dvb_frontend.c
index 4548fc9..4fc11eb 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -1830,7 +1830,7 @@ static int dvb_frontend_ioctl(struct file *file,
struct dvb_frontend *fe = dvbdev-priv;
struct dtv_frontend_properties *c = fe-dtv_property_cache;
struct dvb_frontend_private *fepriv = fe-frontend_priv;
- int err = -EOPNOTSUPP;
+ int err = -ENOTTY;
dev_dbg(fe-dvb-device, %s: (%d)\n, __func__, _IOC_NR(cmd));
if (fepriv-exit != DVB_FE_NO_EXIT)
@@ -1948,7 +1948,7 @@ static int dvb_frontend_ioctl_properties(struct file
*file,
}
} else
- err = -EOPNOTSUPP;
+ err = -ENOTTY;
out:
kfree(tvp);
@@ -2081,7 +2081,7 @@ static int dvb_frontend_ioctl_legacy(struct file *file,
struct dvb_frontend *fe = dvbdev-priv;
struct dvb_frontend_private *fepriv = fe-frontend_priv;
struct dtv_frontend_properties *c = fe-dtv_property_cache;
- int cb_err, err = -EOPNOTSUPP;
+ int cb_err, err = -ENOTTY;
if (fe-dvb-fe_ioctl_override) {
cb_err = fe-dvb-fe_ioctl_override(fe, cmd, parg,
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 1/3] dvb_frontend: use Kernel dev_* logging
Em 09-08-2012 19:24, Antti Palosaari escreveu: Signed-off-by: Antti Palosaari cr...@iki.fi That looks ok for me. --- drivers/media/dvb/dvb-core/dvb_frontend.c | 226 +++--- 1 file changed, 116 insertions(+), 110 deletions(-) diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c b/drivers/media/dvb/dvb-core/dvb_frontend.c index 13cf4d2..4548fc9 100644 --- a/drivers/media/dvb/dvb-core/dvb_frontend.c +++ b/drivers/media/dvb/dvb-core/dvb_frontend.c @@ -66,8 +66,6 @@ MODULE_PARM_DESC(dvb_powerdown_on_sleep, 0: do not power down, 1: turn LNB volt module_param(dvb_mfe_wait_time, int, 0644); MODULE_PARM_DESC(dvb_mfe_wait_time, Wait up to mfe_wait_time seconds on open() for multi-frontend to become available (default:5 seconds)); -#define dprintk if (dvb_frontend_debug) printk - #define FESTATE_IDLE 1 #define FESTATE_RETUNE 2 #define FESTATE_TUNING_FAST 4 @@ -207,7 +205,7 @@ static void dvb_frontend_add_event(struct dvb_frontend *fe, fe_status_t status) struct dvb_frontend_event *e; int wp; - dprintk (%s\n, __func__); + dev_dbg(fe-dvb-device, %s:\n, __func__); Just one small issue that it might have... some of those core printk facilities add a \n at the end. Can't remember if dev_*() are the ones that do it. If so, you'll need to remove the \n from each line. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 3/3] dvb_frontend: do not allow statistic IOCTLs when sleeping
On 08/12/2012 06:28 PM, Mauro Carvalho Chehab wrote:
Em 09-08-2012 19:25, Antti Palosaari escreveu:
Demodulator cannot perform statistic IOCTLs when it is not tuned.
Return -EPERM in such case.
While, in general, doing it makes sense, -EPERM is a very bad return code.
It is used to indicate when accessing some resources would require root access.
OK, makes sense. As I mentioned in coder letter I selected that due to
V4L2 usage to keep consistent.
VIDIOC_DECODER_CMD, VIDIOC_TRY_DECODER_CMD
VIDIOC_ENCODER_CMD, VIDIOC_TRY_ENCODER_CMD
Cover letter also lists all the other error codes I found suitable.
Which one you prefer?
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/dvb/dvb-core/dvb_frontend.c | 34 +++
1 file changed, 25 insertions(+), 9 deletions(-)
diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c
b/drivers/media/dvb/dvb-core/dvb_frontend.c
index 4fc11eb..40efcde 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -2157,27 +2157,43 @@ static int dvb_frontend_ioctl_legacy(struct file *file,
err = fe-ops.read_status(fe, status);
break;
}
+
case FE_READ_BER:
- if (fe-ops.read_ber)
- err = fe-ops.read_ber(fe, (__u32*) parg);
+ if (fe-ops.read_ber) {
+ if (fepriv-thread)
+ err = fe-ops.read_ber(fe, (__u32 *) parg);
+ else
+ err = -EPERM;
+ }
break;
case FE_READ_SIGNAL_STRENGTH:
- if (fe-ops.read_signal_strength)
- err = fe-ops.read_signal_strength(fe, (__u16*) parg);
+ if (fe-ops.read_signal_strength) {
+ if (fepriv-thread)
+ err = fe-ops.read_signal_strength(fe, (__u16
*) parg);
+ else
+ err = -EPERM;
+ }
break;
Signal strength can still be available even without locking.
So it is correct. :)
It checks if frontend thread is running, not demodulator lock flags.
Actually, my original plan was to use demod lock flags but after looking
various demod drivers I ended-up conclusion it is not wise. Many demod
drivers just set all flags at the same time when there is full lock
gained and never provide more accurate info - all or nothing.
Anyhow, that solution prevents I/O errors when demod is so deep sleep
state (like reset) it cannot even answer at all.
case FE_READ_SNR:
- if (fe-ops.read_snr)
- err = fe-ops.read_snr(fe, (__u16*) parg);
+ if (fe-ops.read_snr) {
+ if (fepriv-thread)
+ err = fe-ops.read_snr(fe, (__u16 *) parg);
+ else
+ err = -EPERM;
+ }
break;
case FE_READ_UNCORRECTED_BLOCKS:
- if (fe-ops.read_ucblocks)
- err = fe-ops.read_ucblocks(fe, (__u32*) parg);
+ if (fe-ops.read_ucblocks) {
+ if (fepriv-thread)
+ err = fe-ops.read_ucblocks(fe, (__u32 *) parg);
+ else
+ err = -EPERM;
+ }
break;
-
case FE_DISEQC_RESET_OVERLOAD:
if (fe-ops.diseqc_reset_overload) {
err = fe-ops.diseqc_reset_overload(fe);
Regards,
Mauro
regards
Antti
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
suitable IOCTL error code when device is in state IOCTL cannot performed
Subject says it all. Which one error value is most suitable / generic ? Here are few ones I found which could be possible: #define EPERM1 /* Operation not permitted */ #define EAGAIN 11 /* Try again */ #define EACCES 13 /* Permission denied */ #define EBUSY 16 /* Device or resource busy */ #define ENODATA 61 /* No data available */ #define ECANCELED 125 /* Operation Canceled */ regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] [media] iguanair: Fix return value on transmit
Em 11-08-2012 17:52, Sean Young escreveu: On Fri, Aug 10, 2012 at 08:28:03PM +0100, Sean Young wrote: Transmit returned 0 after sending and failed to send anything if the amount exceeded its buffer size. Also fix some minor errors. Signed-off-by: Sean Young s...@mess.org I'm sorry, this patch series wasn't diffed against the right tree, so it won't apply. I'll need to rediff and retest. In the mean time any review comments would be appreciated. Ok, I'll mark them as rejected at patchwork per your request. Regards, Mauro Sean -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Patchwork notifications for '[RESEND,media] v4l2: define V4L2_PIX_FMT_NV16M and V4L2_PIX_FMT_NV24M pixel formats'
Em 12-08-2012 08:55, Ilyes Gouta escreveu: Hi, On Sun, Aug 12, 2012 at 2:58 AM, Patchwork patchw...@linuxtv.org wrote: Hello, The following patches (submitted by you) have been updated in patchwork: * [RESEND,media] v4l2: define V4L2_PIX_FMT_NV16M and V4L2_PIX_FMT_NV24M pixel formats - http://patchwork.linuxtv.org/patch/13555/ was: New now: Superseded * [RESEND,media] v4l2: define V4L2_PIX_FMT_NV16M and V4L2_PIX_FMT_NV24M pixel formats - http://patchwork.linuxtv.org/patch/13556/ was: New now: Changes Requested Patchwork has moved my V4L2_PIX_FMT_NV16M and V4L2_PIX_FMT_NV24M definitions patch (http://patchwork.linuxtv.org/patch/13556) from New to Changes Requested, but I couldn't look-up what changes need to be made. Where can I find such feedback? Just for the record, in a previous conversation with Mauro, he suggested that new pixel formats don't get defined in the kernel unless a v4l2 device driver is actually using them (so suggesting to also upstream the driver, which isn't immediately possible). Yes, that's the changes requested: to submit it together with the driver, when you're ready for that. While changes requested is not an exact match for postpone submission, it fits a little better than rejected/accepted/under review/rfc/obsoleted/... Keeping it as new doesn't make sense, as I need to cleanup my pending queue. I might have created yet-another-status-tag for patchwork for this case, but having a lot of status is confusing for everybody. Also, at the time you'll be re-submitting it, you may need to rebase the patch, as it might conflict with some other changes. So, changes may be needed anyway. So, what I do is, when someone, including me, requests any type of action from the driver's author (in this case, to put it together with the patches that require those API additions, when you're done), I mark it as changes requested. Regards, Mauro PS.: I'm following this logic since when we started with patchwork; the only thing that changed is that patchwork is now posting e-mails to help developers to track on what's the merging status of their work. -Ilyes 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; 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/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Sun Aug 12 19:00:30 CEST 2012 git hash:e0e52d4e9f5bce7ea887027c127473eb654a5a04 gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: WARNINGS linux-git-arm-eabi-exynos: OK linux-git-arm-eabi-omap: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: ERRORS linux-2.6.33-x86_64: ERRORS linux-2.6.34-x86_64: ERRORS linux-2.6.35.3-x86_64: ERRORS linux-2.6.36-x86_64: ERRORS linux-2.6.37-x86_64: ERRORS linux-2.6.38.2-x86_64: ERRORS linux-2.6.39.1-x86_64: ERRORS linux-3.0-x86_64: ERRORS linux-3.1-x86_64: ERRORS linux-3.2.1-x86_64: ERRORS linux-3.3-x86_64: ERRORS linux-3.4-x86_64: ERRORS linux-3.5-x86_64: ERRORS linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: ERRORS linux-2.6.33-i686: ERRORS linux-2.6.34-i686: ERRORS linux-2.6.35.3-i686: ERRORS linux-2.6.36-i686: ERRORS linux-2.6.37-i686: ERRORS linux-2.6.38.2-i686: ERRORS linux-2.6.39.1-i686: ERRORS linux-3.0-i686: ERRORS linux-3.1-i686: ERRORS linux-3.2.1-i686: ERRORS linux-3.3-i686: ERRORS linux-3.4-i686: ERRORS linux-3.5-i686: ERRORS apps: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: suitable IOCTL error code when device is in state IOCTL cannot performed
Em 12-08-2012 13:38, Antti Palosaari escreveu: Subject says it all. Which one error value is most suitable / generic ? Here are few ones I found which could be possible: #define EPERM1 /* Operation not permitted */ #define EAGAIN 11 /* Try again */ #define EACCES 13 /* Permission denied */ #define EBUSY 16 /* Device or resource busy */ #define ENODATA 61 /* No data available */ #define ECANCELED 125 /* Operation Canceled */ IMHO, EAGAIN, EBUSY or ENODATA are the most pertinent ones. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] iguanair: various fixes
On Sat, Aug 11, 2012 at 09:35:29PM -0300, Mauro Carvalho Chehab wrote: Em 31-07-2012 07:37, Sean Young escreveu: This fixes: - rx_overflow while holding down any down button on a nec remote - suspend/resume - stop receiver on rmmod - advertise rx_resolution and timeout properly - code simplify - ignore unsupported firmware versions Please don't mix several different things on the same patch; it makes harder for review and, if any of these changes break, a git revert would change a lot of unrelated things. It also makes hard for bug disect. That makes a lot of sense. I'll rework the patch. Tip: git citool helps a lot to break messy patches into smaller, concise ones. Thank you very much, I'll try that. Sean -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] DVB-S2 multistream support
Ok, done :) Look like DTV_DVBT2_PLP_ID not implemented for CXD2820r ?
12.08.2012, 03:00, Antti Palosaari cr...@iki.fi:
We asked you to merge isdbs_ts_id, dvbt2_plp_id and dvbs2_mis_id to one
as those are logically same thing from the user-point of view.
Technically those differs, but that is userspace API so underlying
technique should not matter.
It is some more work for you, but it should not be such big issue you
cannot do. So please use few hours and merge all those. I think correct
name is DTV_STREAM_ID. So remove isdbs_ts_id, dvbt2_plp_id and
dvbs2_mis_id. Add new variable stream_id. As DTV_ISDBS_TS_ID and
DTV_DVBT2_PLP_ID already exists you should make some logic those could
be still used.
Signed-off-by: Evgeny Plehov evgenyple...@ukr.net
diff --git a/include/linux/dvb/frontend.h b/include/linux/dvb/frontend.h
index f50d405..32d51bc 100644
--- a/include/linux/dvb/frontend.h
+++ b/include/linux/dvb/frontend.h
@@ -62,6 +62,7 @@ typedef enum fe_caps {
FE_CAN_8VSB = 0x20,
FE_CAN_16VSB= 0x40,
FE_HAS_EXTENDED_CAPS= 0x80, /* We need more bitspace
for newer APIs, indicate this. */
+ FE_CAN_MULTISTREAM = 0x400, /* frontend supports
DVB-S2 multistream filtering */
FE_CAN_TURBO_FEC= 0x800, /* frontend supports
turbo fec modulation */
FE_CAN_2G_MODULATION= 0x1000, /* frontend supports 2nd
generation modulation (DVB-S2) */
FE_NEEDS_BENDING= 0x2000, /* not supported anymore,
don't use (frontend requires frequency bending) */
@@ -314,9 +315,10 @@ struct dvb_frontend_event {
#define DTV_ISDBT_LAYER_ENABLED41
-#define DTV_ISDBS_TS_ID42
-
-#define DTV_DVBT2_PLP_ID 43
+#define DTV_STREAM_ID 42
+#define DTV_ISDBS_TS_IDDTV_STREAM_ID
+#define DTV_DVBT2_PLP_ID DTV_STREAM_ID
+#define DTV_DVBS2_MIS_ID DTV_STREAM_ID
#define DTV_ENUM_DELSYS44
diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c
b/drivers/media/dvb/dvb-core/dvb_frontend.c
index aebcdf2..8fb7eac 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -946,8 +946,7 @@ static int dvb_frontend_clear_cache(struct dvb_frontend *fe)
c-layer[i].segment_count = 0;
}
- c-isdbs_ts_id = 0;
- c-dvbt2_plp_id = 0;
+ c-stream_id = -1;
switch (c-delivery_system) {
case SYS_DVBS:
@@ -1017,8 +1016,7 @@ static struct dtv_cmds_h dtv_cmds[DTV_MAX_COMMAND + 1] = {
_DTV_CMD(DTV_ISDBT_LAYERC_SEGMENT_COUNT, 1, 0),
_DTV_CMD(DTV_ISDBT_LAYERC_TIME_INTERLEAVING, 1, 0),
- _DTV_CMD(DTV_ISDBS_TS_ID, 1, 0),
- _DTV_CMD(DTV_DVBT2_PLP_ID, 1, 0),
+ _DTV_CMD(DTV_STREAM_ID, 1, 0),
/* Get */
_DTV_CMD(DTV_DISEQC_SLAVE_REPLY, 0, 1),
@@ -1382,11 +1380,9 @@ static int dtv_property_process_get(struct dvb_frontend
*fe,
case DTV_ISDBT_LAYERC_TIME_INTERLEAVING:
tvp-u.data = c-layer[2].interleaving;
break;
- case DTV_ISDBS_TS_ID:
- tvp-u.data = c-isdbs_ts_id;
- break;
- case DTV_DVBT2_PLP_ID:
- tvp-u.data = c-dvbt2_plp_id;
+
+ case DTV_STREAM_ID:
+ tvp-u.data = c-stream_id;
break;
/* ATSC-MH */
@@ -1771,11 +1767,8 @@ static int dtv_property_process_set(struct dvb_frontend
*fe,
case DTV_ISDBT_LAYERC_TIME_INTERLEAVING:
c-layer[2].interleaving = tvp-u.data;
break;
- case DTV_ISDBS_TS_ID:
- c-isdbs_ts_id = tvp-u.data;
- break;
- case DTV_DVBT2_PLP_ID:
- c-dvbt2_plp_id = tvp-u.data;
+ case DTV_STREAM_ID:
+ c-stream_id = tvp-u.data;
break;
/* ATSC-MH */
diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.h
b/drivers/media/dvb/dvb-core/dvb_frontend.h
index 7c64c09..bec0cda 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.h
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.h
@@ -368,11 +368,8 @@ struct dtv_frontend_properties {
u8 interleaving;
} layer[3];
- /* ISDB-T specifics */
- u32 isdbs_ts_id;
-
- /* DVB-T2 specifics */
- u32 dvbt2_plp_id;
+ /* Multistream specifics */
+ u32 stream_id;
/* ATSC-MH specifics */
u8 atscmh_fic_ver;
diff --git a/drivers/media/dvb/frontends/stv090x.c
b/drivers/media/dvb/frontends/stv090x.c
index ea86a56..13caec0 100644
--- a/drivers/media/dvb/frontends/stv090x.c
+++ b/drivers/media/dvb/frontends/stv090x.c
@@ -3425,6 +3425,33 @@ err:
return -1;
}
+static int stv090x_set_mis(struct stv090x_state *state, int mis)
+{
+ u32 reg;
+
+ if (mis 0 ||
Re: [PATCH] DVB-S2 multistream support
On 08/12/2012 09:33 PM, CrazyCat wrote:
Ok, done :) Look like DTV_DVBT2_PLP_ID not implemented for CXD2820r ?
yes, true. It uses always PLP 0. I didn't have signal source that uses
multiple PLPs. I didn't even add that PLP ID to API.
12.08.2012, 03:00, Antti Palosaari cr...@iki.fi:
We asked you to merge isdbs_ts_id, dvbt2_plp_id and dvbs2_mis_id to one
as those are logically same thing from the user-point of view.
Technically those differs, but that is userspace API so underlying
technique should not matter.
It is some more work for you, but it should not be such big issue you
cannot do. So please use few hours and merge all those. I think correct
name is DTV_STREAM_ID. So remove isdbs_ts_id, dvbt2_plp_id and
dvbs2_mis_id. Add new variable stream_id. As DTV_ISDBS_TS_ID and
DTV_DVBT2_PLP_ID already exists you should make some logic those could
be still used.
Signed-off-by: Evgeny Plehov evgenyple...@ukr.net
diff --git a/include/linux/dvb/frontend.h b/include/linux/dvb/frontend.h
index f50d405..32d51bc 100644
--- a/include/linux/dvb/frontend.h
+++ b/include/linux/dvb/frontend.h
@@ -62,6 +62,7 @@ typedef enum fe_caps {
FE_CAN_8VSB = 0x20,
FE_CAN_16VSB= 0x40,
FE_HAS_EXTENDED_CAPS= 0x80, /* We need more bitspace
for newer APIs, indicate this. */
+ FE_CAN_MULTISTREAM = 0x400, /* frontend supports
DVB-S2 multistream filtering */
FE_CAN_TURBO_FEC= 0x800, /* frontend supports turbo
fec modulation */
FE_CAN_2G_MODULATION= 0x1000, /* frontend supports 2nd
generation modulation (DVB-S2) */
FE_NEEDS_BENDING= 0x2000, /* not supported anymore,
don't use (frontend requires frequency bending) */
@@ -314,9 +315,10 @@ struct dvb_frontend_event {
#define DTV_ISDBT_LAYER_ENABLED 41
-#define DTV_ISDBS_TS_ID42
-
-#define DTV_DVBT2_PLP_ID 43
+#define DTV_STREAM_ID 42
+#define DTV_ISDBS_TS_IDDTV_STREAM_ID
+#define DTV_DVBT2_PLP_ID DTV_STREAM_ID
+#define DTV_DVBS2_MIS_ID DTV_STREAM_ID
Do not define command DTV_DVBS2_MIS_ID at all. It is not never released
thus no need to support.
I suspect DTV_DVBT2_PLP_ID is never used by any application, but still
it is not possible to change command number from 43 to 42 as this does.
I am not sure what kind of procedures are needed to remove existing API
command number, but surely it is not possible like that. So you have to
reserve command 43. Both commands 42 and 43 should continue working.
DTV_DVBT2_PLP_ID should be marked as deprecated and after that it could
be removed somewhere in future.
#define DTV_ENUM_DELSYS 44
diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c
b/drivers/media/dvb/dvb-core/dvb_frontend.c
index aebcdf2..8fb7eac 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -946,8 +946,7 @@ static int dvb_frontend_clear_cache(struct dvb_frontend *fe)
c-layer[i].segment_count = 0;
}
- c-isdbs_ts_id = 0;
- c-dvbt2_plp_id = 0;
+ c-stream_id = -1;
You have defined it as a unsigned 32 thus -1 is not possible value.
Maybe 0 is still good default choice.
switch (c-delivery_system) {
case SYS_DVBS:
@@ -1017,8 +1016,7 @@ static struct dtv_cmds_h dtv_cmds[DTV_MAX_COMMAND + 1] = {
_DTV_CMD(DTV_ISDBT_LAYERC_SEGMENT_COUNT, 1, 0),
_DTV_CMD(DTV_ISDBT_LAYERC_TIME_INTERLEAVING, 1, 0),
- _DTV_CMD(DTV_ISDBS_TS_ID, 1, 0),
- _DTV_CMD(DTV_DVBT2_PLP_ID, 1, 0),
DTV_DVBT2_PLP_ID cannot be removed yet (but DTV_ISDBS_TS_ID can be as it
is renamed, it is OK).
+ _DTV_CMD(DTV_STREAM_ID, 1, 0),
/* Get */
_DTV_CMD(DTV_DISEQC_SLAVE_REPLY, 0, 1),
@@ -1382,11 +1380,9 @@ static int dtv_property_process_get(struct dvb_frontend
*fe,
case DTV_ISDBT_LAYERC_TIME_INTERLEAVING:
tvp-u.data = c-layer[2].interleaving;
break;
- case DTV_ISDBS_TS_ID:
- tvp-u.data = c-isdbs_ts_id;
- break;
- case DTV_DVBT2_PLP_ID:
- tvp-u.data = c-dvbt2_plp_id;
DTV_DVBT2_PLP_ID cannot be removed yet (but DTV_ISDBS_TS_ID can be as it
is renamed, it is OK).
+
+ case DTV_STREAM_ID:
+ tvp-u.data = c-stream_id;
break;
/* ATSC-MH */
@@ -1771,11 +1767,8 @@ static int dtv_property_process_set(struct dvb_frontend
*fe,
case DTV_ISDBT_LAYERC_TIME_INTERLEAVING:
c-layer[2].interleaving = tvp-u.data;
break;
- case DTV_ISDBS_TS_ID:
- c-isdbs_ts_id = tvp-u.data;
- break;
- case DTV_DVBT2_PLP_ID:
- c-dvbt2_plp_id = tvp-u.data;
DTV_DVBT2_PLP_ID cannot be removed yet (but DTV_ISDBS_TS_ID can be as it
is renamed, it is OK).
+
Re: [PATCH] DVB-S2 multistream support
On Mon, Aug 13, 2012 at 12:20 AM, Antti Palosaari cr...@iki.fi wrote: On 08/12/2012 09:33 PM, CrazyCat wrote: Ok, done :) Look like DTV_DVBT2_PLP_ID not implemented for CXD2820r ? yes, true. It uses always PLP 0. I didn't have signal source that uses multiple PLPs. I didn't even add that PLP ID to API. CXD2820 works only with PLP Type 1 or Type A in some other terminology. PLP Type Common and PLP Type 2 are not supported by the hardware. ie, it fails to acquire a LOCK with anything else. Issue confirmed by Sony as well. Regards, Manu -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: boot slow down
On Sat, Aug 11, 2012 at 9:06 PM, Andy Walls awa...@md.metrocast.net wrote: On Wed, 2012-08-08 at 13:18 -0400, bjloc...@lockie.ca wrote: How hard would it be to get an official kernel option not to load firmware Submit a patch for the cx23885 driver to the list. It could add a module option so the user can specify not to load cx23885-av firmware (and maybe CX23417 firmware too). The new module option could be set on your kernel commandline: cx23885.no_firmware_load=1 Honestly though such a patch problably won't fly. The real solution, that the cx23885 driver needs anyway, is to inhibit the load of all firmware during the device probe by the kernel, and load them on the first device open (like the ivtv and cx18 drivers do for analog). There are at least 2 places in the PCI device probe routine of the cx23885 driver, where firmware is requested. Here is the call chain: cx23885_initdev() cx23885_dev_setup() cx23885_card_setup() v4l2_subdev_call(dev-sd_cx25840, core, load_fw); cx25840_load_fw() cx23885_initialize() cx25840_work_handler() cx25840_loadfw() request_firmware() cx23885_417_register() cx23885_initialize_codec() cx23885_load_firmware() request_firmware() The calls to v4l2_subdev_call(dev-sd_cx25840, core, load_fw); This one should be really easy, right? The subdev can be created on probe and then the call to load_fw can be done on first open. It is remarkable this is documented in a comment placed just above cx25840_load_fw: Since loading the firmware is often problematic when the driver is compiled into the kernel I recommend postponing calling this function until the first open of the video device. Another reason for postponing it is that loading this firmware takes a long time (seconds) due to the slow i2c bus speed. So it will speed up the boot process if you can avoid loading the fw as long as the video device isn't used. If you want to, I can try that patch. Of course, someone must commit to test it. Regards, Ezequiel. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Patchwork notifications for '[RESEND,media] v4l2: define V4L2_PIX_FMT_NV16M and V4L2_PIX_FMT_NV24M pixel formats'
Hi Mauro, On Sun, Aug 12, 2012 at 6:15 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Yes, that's the changes requested: to submit it together with the driver, when you're ready for that. While changes requested is not an exact match for postpone submission, it fits a little better than rejected/accepted/under review/rfc/obsoleted/... Keeping it as new doesn't make sense, as I need to cleanup my pending queue. I might have created yet-another-status-tag for patchwork for this case, but having a lot of status is confusing for everybody. Also, at the time you'll be re-submitting it, you may need to rebase the patch, as it might conflict with some other changes. So, changes may be needed anyway. So, what I do is, when someone, including me, requests any type of action from the driver's author (in this case, to put it together with the patches that require those API additions, when you're done), I mark it as changes requested. OK, that all looks good. Again, thanks for the explanations! Regards, -Ilyes Regards, Mauro PS.: I'm following this logic since when we started with patchwork; the only thing that changed is that patchwork is now posting e-mails to help developers to track on what's the merging status of their work. -Ilyes 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; 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/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] ViewCast O820E capture support added
Hi Mauro, A new PCIe bridge driver below. It was released a couple of months ago to the public, probably about time we got this into the request queue. I'll review the linux-firmware additions shortly, I have a firmware blob and flexible license for the distros. The following changes since commit da2cd767f537082be0a02d83f87e0da4270e25b2: [media] ttpci: add support for Omicom S2 PCI (2012-08-12 14:41:26 -0300) are available in the git repository at: git://git.kernellabs.com/stoth/media_tree.git o820e Steven Toth (1): [media] vc8x0: Add support for the ViewCast O820E card. drivers/media/video/Kconfig |2 + drivers/media/video/Makefile|1 + drivers/media/video/vc8x0/Kconfig | 14 + drivers/media/video/vc8x0/Makefile | 10 + drivers/media/video/vc8x0/vc8x0-ad7441.c| 3057 +++ drivers/media/video/vc8x0/vc8x0-audio.c | 736 +++ drivers/media/video/vc8x0/vc8x0-buffer.c| 338 +++ drivers/media/video/vc8x0/vc8x0-cards.c | 138 ++ drivers/media/video/vc8x0/vc8x0-channel.c | 934 drivers/media/video/vc8x0/vc8x0-core.c | 887 drivers/media/video/vc8x0/vc8x0-display.c | 1359 drivers/media/video/vc8x0/vc8x0-dma.c | 2677 +++ drivers/media/video/vc8x0/vc8x0-eeprom.c| 71 + drivers/media/video/vc8x0/vc8x0-fw.c| 429 drivers/media/video/vc8x0/vc8x0-i2c.c | 290 +++ drivers/media/video/vc8x0/vc8x0-pcm3052.c | 192 ++ drivers/media/video/vc8x0/vc8x0-reg.h | 214 ++ drivers/media/video/vc8x0/vc8x0-timestamp.c | 156 ++ drivers/media/video/vc8x0/vc8x0-vga.c | 430 drivers/media/video/vc8x0/vc8x0-video.c | 2650 +++ drivers/media/video/vc8x0/vc8x0.h | 995 + 21 files changed, 15580 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/vc8x0/Kconfig create mode 100644 drivers/media/video/vc8x0/Makefile create mode 100644 drivers/media/video/vc8x0/vc8x0-ad7441.c create mode 100644 drivers/media/video/vc8x0/vc8x0-audio.c create mode 100644 drivers/media/video/vc8x0/vc8x0-buffer.c create mode 100644 drivers/media/video/vc8x0/vc8x0-cards.c create mode 100644 drivers/media/video/vc8x0/vc8x0-channel.c create mode 100644 drivers/media/video/vc8x0/vc8x0-core.c create mode 100644 drivers/media/video/vc8x0/vc8x0-display.c create mode 100644 drivers/media/video/vc8x0/vc8x0-dma.c create mode 100644 drivers/media/video/vc8x0/vc8x0-eeprom.c create mode 100644 drivers/media/video/vc8x0/vc8x0-fw.c create mode 100644 drivers/media/video/vc8x0/vc8x0-i2c.c create mode 100644 drivers/media/video/vc8x0/vc8x0-pcm3052.c create mode 100644 drivers/media/video/vc8x0/vc8x0-reg.h create mode 100644 drivers/media/video/vc8x0/vc8x0-timestamp.c create mode 100644 drivers/media/video/vc8x0/vc8x0-vga.c create mode 100644 drivers/media/video/vc8x0/vc8x0-video.c create mode 100644 drivers/media/video/vc8x0/vc8x0.h Regards, - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL / Firmware] O820E firmware release
Mauro, The firmware related to the O820 driver addition below. I'm not sure how you deal with this but here's the license and firmware blob. I don't see a direct git repo for linux-firmware on linuxtv.org, so this comes from kernel.org dwmw2/linux-firmware.git The following changes since commit 7560108a2c94a62056fa82d912282b901aa0904f: Add syscfg (different frequency) and patch for AR3002 2.2.1. (2012-07-19 04:02:52 +0100) are available in the git repository at: git://git.kernellabs.com/stoth/linux-firmware.git master Steven Toth (1): [media] vc8x0: Adding the firmware for the FPGA LICENSE.vc8x0 | 18 ++ v4l-osprey-820e-firmware-v1.5.0.rom | Bin 0 - 1932760 bytes 2 files changed, 18 insertions(+), 0 deletions(-) create mode 100644 LICENSE.vc8x0 create mode 100644 v4l-osprey-820e-firmware-v1.5.0.rom Regards, - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] rtl28xxu: generalize streaming control
Move rtl2831u LED from streaming control to power control. It
changes LED behavior slightly but who cares :)
After that same streaming control can be used for both rtl2831u
and rtl2832u.
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/dvb/dvb-usb-v2/rtl28xxu.c | 44 -
1 file changed, 5 insertions(+), 39 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb-v2/rtl28xxu.c
b/drivers/media/dvb/dvb-usb-v2/rtl28xxu.c
index 493d531..a2d1e5b 100644
--- a/drivers/media/dvb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/dvb/dvb-usb-v2/rtl28xxu.c
@@ -823,43 +823,7 @@ err:
return ret;
}
-static int rtl2831u_streaming_ctrl(struct dvb_frontend *fe , int onoff)
-{
- int ret;
- u8 buf[2], gpio;
- struct dvb_usb_device *d = fe_to_d(fe);
-
- dev_dbg(d-udev-dev, %s: onoff=%d\n, __func__, onoff);
-
- ret = rtl28xx_rd_reg(d, SYS_GPIO_OUT_VAL, gpio);
- if (ret)
- goto err;
-
- if (onoff) {
- buf[0] = 0x00;
- buf[1] = 0x00;
- gpio |= 0x04; /* LED on */
- } else {
- buf[0] = 0x10; /* stall EPA */
- buf[1] = 0x02; /* reset EPA */
- gpio = (~0x04); /* LED off */
- }
-
- ret = rtl28xx_wr_reg(d, SYS_GPIO_OUT_VAL, gpio);
- if (ret)
- goto err;
-
- ret = rtl28xx_wr_regs(d, USB_EPA_CTL, buf, 2);
- if (ret)
- goto err;
-
- return ret;
-err:
- dev_dbg(d-udev-dev, %s: failed=%d\n, __func__, ret);
- return ret;
-}
-
-static int rtl2832u_streaming_ctrl(struct dvb_frontend *fe , int onoff)
+static int rtl28xxu_streaming_ctrl(struct dvb_frontend *fe , int onoff)
{
int ret;
u8 buf[2];
@@ -908,11 +872,13 @@ static int rtl2831u_power_ctrl(struct dvb_usb_device *d,
int onoff)
if (onoff) {
gpio |= 0x01; /* GPIO0 = 1 */
gpio = (~0x10); /* GPIO4 = 0 */
+ gpio |= 0x04; /* GPIO2 = 1, LED on */
sys0 = sys0 0x0f;
sys0 |= 0xe0;
} else {
gpio = (~0x01); /* GPIO0 = 0 */
gpio |= 0x10; /* GPIO4 = 1 */
+ gpio = (~0x04); /* GPIO2 = 1, LED off */
sys0 = sys0 (~0xc0);
}
@@ -1224,7 +1190,7 @@ static const struct dvb_usb_device_properties
rtl2831u_props = {
.tuner_attach = rtl2831u_tuner_attach,
.init = rtl28xxu_init,
.get_rc_config = rtl2831u_get_rc_config,
- .streaming_ctrl = rtl2831u_streaming_ctrl,
+ .streaming_ctrl = rtl28xxu_streaming_ctrl,
.num_adapters = 1,
.adapter = {
@@ -1246,7 +1212,7 @@ static const struct dvb_usb_device_properties
rtl2832u_props = {
.tuner_attach = rtl2832u_tuner_attach,
.init = rtl28xxu_init,
.get_rc_config = rtl2832u_get_rc_config,
- .streaming_ctrl = rtl2832u_streaming_ctrl,
+ .streaming_ctrl = rtl28xxu_streaming_ctrl,
.num_adapters = 1,
.adapter = {
--
1.7.11.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] add DTMB support for DVB API
I think it is ready. As a last minute change I added INTERLEAVING_AUTO but such trivial and meaningless change I don't see necessary even ran PATCH RFC for it (interlaving was new enum added for DTMB). Antti Palosaari (2): add DTMB support for DVB API DVB API: add INTERLEAVING_AUTO Documentation/DocBook/media/dvb/dvbproperty.xml | 41 - drivers/media/dvb/dvb-core/dvb_frontend.c | 14 +++-- drivers/media/dvb/dvb-core/dvb_frontend.h | 2 ++ drivers/media/dvb/frontends/atbm8830.c | 2 +- drivers/media/dvb/frontends/lgs8gl5.c | 2 +- drivers/media/dvb/frontends/lgs8gxx.c | 2 +- include/linux/dvb/frontend.h| 22 +++-- include/linux/dvb/version.h | 2 +- 8 files changed, 76 insertions(+), 11 deletions(-) -- 1.7.11.2 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] add DTMB support for DVB API
Cc: Patrick Boettcher pboettc...@kernellabs.com
Cc: Andreas Oberritter o...@linuxtv.org
Cc: Mauro Carvalho Chehab mche...@redhat.com
Acked-by: Patrick Boettcher pboettc...@kernellabs.com
Signed-off-by: Antti Palosaari cr...@iki.fi
---
Documentation/DocBook/media/dvb/dvbproperty.xml | 40 -
drivers/media/dvb/dvb-core/dvb_frontend.c | 14 +++--
drivers/media/dvb/dvb-core/dvb_frontend.h | 2 ++
drivers/media/dvb/frontends/atbm8830.c | 2 +-
drivers/media/dvb/frontends/lgs8gl5.c | 2 +-
drivers/media/dvb/frontends/lgs8gxx.c | 2 +-
include/linux/dvb/frontend.h| 21 +++--
include/linux/dvb/version.h | 2 +-
8 files changed, 74 insertions(+), 11 deletions(-)
diff --git a/Documentation/DocBook/media/dvb/dvbproperty.xml
b/Documentation/DocBook/media/dvb/dvbproperty.xml
index bb4777a..5aea35e 100644
--- a/Documentation/DocBook/media/dvb/dvbproperty.xml
+++ b/Documentation/DocBook/media/dvb/dvbproperty.xml
@@ -194,6 +194,7 @@ get/set up to 64 properties. The actual meaning of each
property is described on
APSK_16,
APSK_32,
DQPSK,
+ QAM_4_NR,
} fe_modulation_t;
/programlisting
/section
@@ -265,6 +266,7 @@ typedef enum fe_code_rate {
FEC_AUTO,
FEC_3_5,
FEC_9_10,
+ FEC_2_5,
} fe_code_rate_t;
/programlisting
parawhich correspond to error correction rates of 1/2, 2/3, etc.,
@@ -351,7 +353,7 @@ typedef enum fe_delivery_system {
SYS_ISDBC,
SYS_ATSC,
SYS_ATSCMH,
- SYS_DMBTH,
+ SYS_DTMB,
SYS_CMMB,
SYS_DAB,
SYS_DVBT2,
@@ -735,6 +737,9 @@ typedef enum fe_guard_interval {
GUARD_INTERVAL_1_128,
GUARD_INTERVAL_19_128,
GUARD_INTERVAL_19_256,
+ GUARD_INTERVAL_PN420,
+ GUARD_INTERVAL_PN595,
+ GUARD_INTERVAL_PN945,
} fe_guard_interval_t;
/programlisting
@@ -743,6 +748,7 @@ typedef enum fe_guard_interval {
try to find the correct guard interval (if capable) and
will use TMCC to fill
in the missing parameters./para
para2) Intervals 1/128, 19/128 and 19/256 are used only for
DVB-T2 at present/para
+ para3) DTMB specifies PN420, PN595 and PN945./para
/section
section id=DTV-TRANSMISSION-MODE
titleconstantDTV_TRANSMISSION_MODE/constant/title
@@ -759,6 +765,8 @@ typedef enum fe_transmit_mode {
TRANSMISSION_MODE_1K,
TRANSMISSION_MODE_16K,
TRANSMISSION_MODE_32K,
+ TRANSMISSION_MODE_C1,
+ TRANSMISSION_MODE_C3780,
} fe_transmit_mode_t;
/programlisting
paraNotes:/para
@@ -770,6 +778,7 @@ typedef enum fe_transmit_mode {
use TMCC to fill in the missing parameters./para
para3) DVB-T specifies 2K and 8K as valid sizes./para
para4) DVB-T2 specifies 1K, 2K, 4K, 8K, 16K and 32K./para
+ para5) DTMB specifies C1 and C3780./para
/section
section id=DTV-HIERARCHY
titleconstantDTV_HIERARCHY/constant/title
@@ -806,6 +815,17 @@ typedef enum fe_hierarchy {
FE_GET_INFO. In the case of a legacy frontend, the
result is just the same
as with FE_GET_INFO, but in a more structured format
/para
/section
+ section id=DTV-INTERLEAVING
+ titleconstantDTV_INTERLEAVING/constant/title
+ paraInterleaving mode/para
+ programlisting
+enum fe_interleaving {
+ INTERLEAVING_NONE,
+ INTERLEAVING_240,
+ INTERLEAVING_720,
+};
+ /programlisting
+ /section
/section
section id=frontend-property-terrestrial-systems
titleProperties used on terrestrial delivery systems/title
@@ -944,6 +964,24 @@ typedef enum fe_hierarchy {
listitemparalink
linkend=DTV-ATSCMH-SCCC-CODE-MODE-DconstantDTV_ATSCMH_SCCC_CODE_MODE_D/constant/link/para/listitem
/itemizedlist
/section
+ section id=dtmb-params
+ titleDTMB delivery system/title
+ paraThe following parameters are valid for
DTMB:/para
+ itemizedlist mark='opencircle'
+ listitemparalink
linkend=DTV-API-VERSIONconstantDTV_API_VERSION/constant/link/para/listitem
+ listitemparalink
linkend=DTV-DELIVERY-SYSTEMconstantDTV_DELIVERY_SYSTEM/constant/link/para/listitem
+ listitemparalink
linkend=DTV-TUNEconstantDTV_TUNE/constant/link/para/listitem
+ listitemparalink
linkend=DTV-CLEARconstantDTV_CLEAR/constant/link/para/listitem
+ listitemparalink
linkend=DTV-FREQUENCYconstantDTV_FREQUENCY/constant/link/para/listitem
+
[PATCH 2/2] DVB API: add INTERLEAVING_AUTO
After thinking twice, I ended up adding own value for AUTO
interleaving instead of using NONE.
API minor number is not needed to increase as that patch should
be the same Kernel as interleaving parameter is initially added.
Signed-off-by: Antti Palosaari cr...@iki.fi
---
Documentation/DocBook/media/dvb/dvbproperty.xml | 1 +
include/linux/dvb/frontend.h| 1 +
2 files changed, 2 insertions(+)
diff --git a/Documentation/DocBook/media/dvb/dvbproperty.xml
b/Documentation/DocBook/media/dvb/dvbproperty.xml
index 5aea35e..eddfe6f 100644
--- a/Documentation/DocBook/media/dvb/dvbproperty.xml
+++ b/Documentation/DocBook/media/dvb/dvbproperty.xml
@@ -821,6 +821,7 @@ typedef enum fe_hierarchy {
programlisting
enum fe_interleaving {
INTERLEAVING_NONE,
+ INTERLEAVING_AUTO,
INTERLEAVING_240,
INTERLEAVING_720,
};
diff --git a/include/linux/dvb/frontend.h b/include/linux/dvb/frontend.h
index 2dd5823..c92b4d6 100644
--- a/include/linux/dvb/frontend.h
+++ b/include/linux/dvb/frontend.h
@@ -222,6 +222,7 @@ typedef enum fe_hierarchy {
enum fe_interleaving {
INTERLEAVING_NONE,
+ INTERLEAVING_AUTO,
INTERLEAVING_240,
INTERLEAVING_720,
};
--
1.7.11.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
