Re: EasyCAP with identifiers
Hello, Le Wed, 21 Dec 2011 13:14:55 -0500, Full Name danew...@excite.com a écrit : I just got an EasyCAP usb device with component and S-video inputs, and it doesn't match what I was expecting from reading lists about drivers. Be careful, there are several devices that the commercial name EasyCAP but that internally aren't the same thing. We had the experience of a device labelled EasyCAP, which was working fine with the easycap driver in drivers/staging. We bought another one from Amazon, also labeled EasyCAP, and even though it looked exactly the same externally, the hardware inside is completely different and is not supported by the easycap driver in drivers/staging. Regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.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
Re: [PATCH] media i.MX27 camera: add support for YUV420 format.
Hi, are there any comments on this? May I suppose you agree and it will be applied? Thank you. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.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
RE: [RFC PATCH v2 4/8] media: videobuf2: introduce VIDEOBUF2_PAGE memops
Hello, On Wednesday, December 14, 2011 3:00 PM Ming Lei wrote: DMA contig memory resource is very limited and precious, also accessing to it from CPU is very slow on some platform. For some cases(such as the comming face detection driver), DMA Streaming buffer is enough, so introduce VIDEOBUF2_PAGE to allocate continuous physical memory but letting video device driver to handle DMA buffer mapping and unmapping things. Signed-off-by: Ming Lei ming@canonical.com Could you elaborate a bit why do you think that DMA contig memory resource is so limited? If dma_alloc_coherent fails because of the memory fragmentation, the alloc_pages() call with order 0 will also fail. I understand that there might be some speed issues with coherent (uncached) userspace mappings, but I would solve it in completely different way. The interface for both coherent/uncached and non-coherent/cached contig allocator should be the same, so exchanging them is easy and will not require changes in the driver. I'm planning to introduce some design changes in memory allocator api and introduce prepare and finish callbacks in allocator ops. I hope to post the rfc after Christmas. For your face detection driver using standard dma-contig allocator shouldn't be a big issue. Your current implementation also abuses the design and api of videobuf2 memory allocators. If the allocator needs to return a custom structure to the driver you should use cookie method. vaddr is intended to provide only a pointer to kernel virtual mapping, but you pass a struct page * there. (snipped) Best regards -- Marek Szyprowski Samsung Poland RD Center -- 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: Why is the Y12 support 12-bit grey formats at the CCDC input (Y12) is truncated to Y10 at the CCDC output?
Hi James, On Thursday 22 December 2011 07:23:56 James wrote: Tried the new yavta but encountered a different situation. yavta -p -f Y12 -s 640x512 -n 2 --capture=10 --skip 5 -F `media-ctl -e OMAP3 ISP CCDC output` --file=./DCIM/Y12 yavta will hang for infinite time and only Ctrl+C will break out of the wait and a new error message appears. yavta: video_do_capture: calling ioctl.. ^C omap3isp omap3isp: CCDC stop timeout! I placed some debugging printf() and yavta wait at ret = ioctl(dev-fd, VIDIOC_DQBUF, buf); Attached is the logfile (mono640.yavta-y12.1.log) What should be the remedies? The pipeline seems to be configured correctly. My guess would be that the sensor doesn't send what the ISP expects. You should check the sensor configuration, and maybe verify the pixel clock, hsync and vsync signals with a scope. -- 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
[PATCH] v4l2: handle multiplication overflow
From: Márton Németh nm...@freemail.hu
When a V4L2 ioctl is executed the memory provided by the caller in user space
is copied to the kernel space in video_usercopy() function. To find out
how many bytes has to be copied the check_array_args() helper function is used.
This patch adds a check for multiplication overflow. Without this check the
multiplication may overflow resulting array_size to be zero. This means that
later on uninitialized value can trigger NULL pointer exception.
The overflow happens because ctrls-count is an __u32 multiplied by a constant
coming from sizeof() operator. Multiplication result of two 32bit value may
be a 64bit value, thus overflow can happen. Similarly buf-length is an __u32
multiplied by a constant coming from sizeof() operator.
The chosen error value is -ENOMEM because we are just about to allocate
kernel memory to copy data from userspace. We cannot even store the required
number of bytes in the variable of size_t type.
To trigger the error from user space use the v4l-test 0.19 [1] or essentially
the following code fragment:
struct v4l2_ext_controls controls;
memset(controls, 0, sizeof(controls));
controls.ctrl_class = V4L2_CTRL_CLASS_USER;
controls.count = 0x4000;
controls.controls = NULL;
ret = ioctl(f, VIDIOC_G_EXT_CTRLS, controls);
References:
[1] v4l-test: Test environment for Video For Linux Two (V4L2) API
http://v4l-test.sourceforge.net/
Signed-off-by: Márton Németh nm...@freemail.hu
---
I'm a little bit in doubt whether this is the correct way to check for the
multiplication overflow. In case of x86 architecture the MUL insruction [2]
can be used to multiply EAX with an other 32bit register, and the 64bit result
is placed to EDX:EAX. In case of EDX != 0 the carry and overflow flags are set.
This means that executing the MUL instruction on x86 already provides
information
whether the result fits to 32bit or not. I might use __u64 as a result of the
multiplication and check whether the upper 32bit is still zero but the optimal
would be to check for the carry or the overflow flag.
Still, there could be a special case when the constant from sizeof() operator is
a power of 2, in this case the compiler might optimize the multiplication using
a shift left. In this case something else is needed.
I couldn't really find information about the number of bits for size_t on
different architectures. If size_t happens to be at least 64bit on some
architecture
then this overflow will not happen at all and the array_size will contain the
correct value.
What do you think?
References:
[2] Intel 80386 Reference Programmer's Manual
MUL -- Unsigned Multiplication of AL or AX
http://www.scs.stanford.edu/nyu/04fa/lab/i386/MUL.htm
---
diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c
index e1da8fc..e239be8 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -2200,6 +2200,7 @@ static int check_array_args(unsigned int cmd, void *parg,
size_t *array_size,
void * __user *user_ptr, void ***kernel_ptr)
{
int ret = 0;
+ size_t size;
switch (cmd) {
case VIDIOC_QUERYBUF:
@@ -2214,8 +2215,15 @@ static int check_array_args(unsigned int cmd, void
*parg, size_t *array_size,
}
*user_ptr = (void __user *)buf-m.planes;
*kernel_ptr = (void *)buf-m.planes;
- *array_size = sizeof(struct v4l2_plane) * buf-length;
- ret = 1;
+ size = sizeof(struct v4l2_plane) * buf-length;
+ if (unlikely(size buf-length)) {
+ /* *array_size overflowed at multiplication */
+ *array_size = 0;
+ ret = -ENOMEM;
+ } else {
+ *array_size = size;
+ ret = 1;
+ }
}
break;
}
@@ -2228,9 +2236,15 @@ static int check_array_args(unsigned int cmd, void
*parg, size_t *array_size,
if (ctrls-count != 0) {
*user_ptr = (void __user *)ctrls-controls;
*kernel_ptr = (void *)ctrls-controls;
- *array_size = sizeof(struct v4l2_ext_control)
- * ctrls-count;
- ret = 1;
+ size = sizeof(struct v4l2_ext_control) * ctrls-count;
+ if (unlikely(size ctrls-count)) {
+ /* *array_size overflowed at multiplication */
+ *array_size = 0;
+ ret = -ENOMEM;
+ } else {
+ *array_size = size;
+ ret = 1;
+
Re: [PATCH 2/2] v4l2: add new pixel formats supported on dm365
Hi Guennadi,
On Wednesday 21 December 2011 23:46:24 Guennadi Liakhovetski wrote:
On Wed, 21 Dec 2011, Laurent Pinchart wrote:
On Wednesday 21 December 2011 14:56:36 Hadli, Manjunath wrote:
On Wed, Dec 21, 2011 at 05:32:08, Laurent Pinchart wrote:
On Friday 16 December 2011 14:42:48 Hadli, Manjunath wrote:
On Thu, Dec 15, 2011 at 18:30:47, Laurent Pinchart wrote:
On Thursday 15 December 2011 13:24:58 Manjunath Hadli wrote:
add new macro V4L2_PIX_FMT_SGRBG10ALAW8 to represent Bayer
format frames compressed by A-LAW alogorithm.
add V4L2_PIX_FMT_UV8 to represent storage of C (UV interleved)
only.
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
include/linux/videodev2.h |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
Could you please also document these formats in
Documentation/DocBook/media/v4l ?
I will. Sorry to have missed that out.
diff --git a/include/linux/videodev2.h
b/include/linux/videodev2.h index 4b752d5..969112d 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -338,6 +338,9 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_HM12v4l2_fourcc('H', 'M', '1', '2')
/* 8 YUV
4:2:0 16x16 macroblocks */ #define V4L2_PIX_FMT_M420
v4l2_fourcc('M', '4', '2', '0') /* 12 YUV 4:2:0 2 lines y, 1
line uv interleaved */
+/* Chrominance formats */
+#define V4L2_PIX_FMT_UV8 v4l2_fourcc('U', 'V', '8', ' ')
/* 8 UV 4:4 */ +
/* two planes -- one Y, one Cr + Cb interleaved */
#define V4L2_PIX_FMT_NV12v4l2_fourcc('N', 'V', '1', '2')
/* 12 Y/CbCr
4:2:0 */ #define V4L2_PIX_FMT_NV21v4l2_fourcc('N', 'V',
'2', '1') /* 12 Y/CrCb 4:2:0 */ @@ -366,6 +369,9 @@ struct
v4l2_pix_format { #define V4L2_PIX_FMT_SRGGB12
v4l2_fourcc('R', 'G', '1', '2') /* 12 RGRG.. GBGB.. */ /*
10bit raw bayer DPCM compressed to 8 bits */ #define
V4L2_PIX_FMT_SGRBG10DPCM8 v4l2_fourcc('B', 'D', '1', '0')
+ /* 10bit raw bayer a-law compressed to 8 bits */ #define
+V4L2_PIX_FMT_SGRBG10ALAW8 v4l2_fourcc('A', 'L', 'W', '8')
+
That's not very future-proof, how would you describe SGBRG10ALAW8
for instance ?
Maybe it's time to standardize FOURCCs for Bayer new formats. We
have 4 characters, we could start with 'B' to denote Bayer,
followed by one character for the order, one for the
compression, and one for the number of bits.
I agree.
May be ('B', 'G', 'A', '8') is fine for the above?
We need to describe at last BGGR, GBRG, GRBG and RGGB. We could use
'B', 'g', 'G' and 'R' respectively for the second character. The
third character would be 'A' for A-law and 'D' for DPCM, and the
fourth character could describe the bus width in bits from 0 to 15
with '0' - '9', 'A' - 'F'. However, I suspect that we will need
16-bit wide busses for raw Bayer at some point, and a 0 width is
definitely not useful. We could thus offset the width by some value.
This is just a preliminary idea, I'm open to suggestions.
I think it is a very good suggestion that we can go with.
B : BGGR
g : GBRG
G : GRBG
R : RGGB
and 0-F can signify 1-16.
Hans, Guennadi, Sakari, any opinion on that as well ?
Is there any risk of confusion, if we don't reserve the first character
for 'B'? I'm just trying to avoid mixed cases, I'm not a great fan of
those;-)
FOURCCs are not really supposed to be displayed anyway :-)
What if we use the first two characters for the order like GR, GB,...
AFAICS, 'G' so far only also occurs in GREY and various RGB* / BGR* / ...
formats, which we wouldn't be confusing with.
Or we could use random FOURCC values as well :-)
There could also be other non-Bayer raw formats, such as panchromatic cells or
Foveon patterns. I don't know if we need to plan for them already.
We could further reduce confusion, if we use some other character for A-law
('L' or 'W'?)
We could also have µ-law compression, L and W would be ambiguous.
--
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 1/2] [media] Staging: dt3155v4l: update to newer API
Hello,
On Thursday, December 22, 2011 7:29 AM Dan Carpenter wrote:
I changed the function definitions for dt3155_queue_setup() to match the
newer API. The dt3155_start_streaming() function didn't do anything so
I just removed it.
This silences the following gcc warnings:
drivers/staging/media/dt3155v4l/dt3155v4l.c:307:2: warning: initialization
from incompatible
pointer type [enabled by default]
drivers/staging/media/dt3155v4l/dt3155v4l.c:307:2: warning: (near
initialization for
‘q_ops.queue_setup’) [enabled by default]
drivers/staging/media/dt3155v4l/dt3155v4l.c:311:2: warning: initialization
from incompatible
pointer type [enabled by default]
drivers/staging/media/dt3155v4l/dt3155v4l.c:311:2: warning: (near
initialization for
‘q_ops.start_streaming’) [enabled by default]
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
It looks correct.
Acked-by: Marek Szyprowski m.szyprow...@samsung.com
---
Please double check that this is sufficient. I'm not very familiar with
this code.
diff --git a/drivers/staging/media/dt3155v4l/dt3155v4l.c
b/drivers/staging/media/dt3155v4l/dt3155v4l.c
index 04e93c4..25c6025 100644
--- a/drivers/staging/media/dt3155v4l/dt3155v4l.c
+++ b/drivers/staging/media/dt3155v4l/dt3155v4l.c
@@ -218,9 +218,10 @@ dt3155_start_acq(struct dt3155_priv *pd)
* driver-specific callbacks (vb2_ops)
*/
static int
-dt3155_queue_setup(struct vb2_queue *q, unsigned int *num_buffers,
- unsigned int *num_planes, unsigned long sizes[],
- void *alloc_ctxs[])
+dt3155_queue_setup(struct vb2_queue *q, const struct v4l2_format *fmt,
+ unsigned int *num_buffers, unsigned int *num_planes,
+ unsigned int sizes[], void *alloc_ctxs[])
+
{
struct dt3155_priv *pd = vb2_get_drv_priv(q);
void *ret;
@@ -262,12 +263,6 @@ dt3155_buf_prepare(struct vb2_buffer *vb)
}
static int
-dt3155_start_streaming(struct vb2_queue *q)
-{
- return 0;
-}
-
-static int
dt3155_stop_streaming(struct vb2_queue *q)
{
struct dt3155_priv *pd = vb2_get_drv_priv(q);
@@ -308,7 +303,6 @@ const struct vb2_ops q_ops = {
.wait_prepare = dt3155_wait_prepare,
.wait_finish = dt3155_wait_finish,
.buf_prepare = dt3155_buf_prepare,
- .start_streaming = dt3155_start_streaming,
.stop_streaming = dt3155_stop_streaming,
.buf_queue = dt3155_buf_queue,
};
Best regards
--
Marek Szyprowski
Samsung Poland RD Center
--
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 RFC v3 05/28] [media] tda10023: Don't use a magic numbers for QAM modulation
Convert the existing data struct to use the QAM modulation macros,
instead of assuming that they're numbered from 0 to 5.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/dvb/frontends/tda10023.c | 66 +---
1 files changed, 43 insertions(+), 23 deletions(-)
diff --git a/drivers/media/dvb/frontends/tda10023.c
b/drivers/media/dvb/frontends/tda10023.c
index a3c34ee..e6c321e 100644
--- a/drivers/media/dvb/frontends/tda10023.c
+++ b/drivers/media/dvb/frontends/tda10023.c
@@ -298,25 +298,43 @@ static int tda10023_init (struct dvb_frontend *fe)
return 0;
}
+struct qam_params {
+ u8 qam, lockthr, mseth, aref, agcrefnyq, eragnyq_thd;
+};
+
static int tda10023_set_parameters (struct dvb_frontend *fe,
struct dvb_frontend_parameters *p)
{
struct tda10023_state* state = fe-demodulator_priv;
-
- static int qamvals[6][6] = {
- // QAM LOCKTHR MSETH AREF AGCREFNYQ ERAGCNYQ_THD
- { (52), 0x78,0x8c, 0x96, 0x78, 0x4c }, // 4 QAM
- { (02), 0x87,0xa2, 0x91, 0x8c, 0x57 }, // 16 QAM
- { (12), 0x64,0x74, 0x96, 0x8c, 0x57 }, // 32 QAM
- { (22), 0x46,0x43, 0x6a, 0x6a, 0x44 }, // 64 QAM
- { (32), 0x36,0x34, 0x7e, 0x78, 0x4c }, // 128 QAM
- { (42), 0x26,0x23, 0x6c, 0x5c, 0x3c }, // 256 QAM
+ static const struct qam_params qam_params[] = {
+ /* Modulation QAMLOCKTHR MSETH AREF AGCREFNYQ
ERAGCNYQ_THD */
+ [QPSK]= { (52), 0x78,0x8c, 0x96, 0x78, 0x4c },
+ [QAM_16] = { (02), 0x87,0xa2, 0x91, 0x8c, 0x57 },
+ [QAM_32] = { (12), 0x64,0x74, 0x96, 0x8c, 0x57 },
+ [QAM_64] = { (22), 0x46,0x43, 0x6a, 0x6a, 0x44 },
+ [QAM_128] = { (32), 0x36,0x34, 0x7e, 0x78, 0x4c },
+ [QAM_256] = { (42), 0x26,0x23, 0x6c, 0x5c, 0x3c },
};
-
- int qam = p-u.qam.modulation;
-
- if (qam 0 || qam 5)
+ unsigned qam = p-u.qam.modulation;
+
+ /*
+* gcc optimizes the code bellow the same way as it would code:
+* if (qam 5) return -EINVAL;
+* Yet, the code is clearer, as it shows what QAM standards are
+* supported by the driver, and avoids the usage of magic numbers on
+* it.
+*/
+ switch (qam) {
+ case QPSK:
+ case QAM_16:
+ case QAM_32:
+ case QAM_64:
+ case QAM_128:
+ case QAM_256:
+ break;
+ default:
return -EINVAL;
+ }
if (fe-ops.tuner_ops.set_params) {
fe-ops.tuner_ops.set_params(fe, p);
@@ -324,16 +342,18 @@ static int tda10023_set_parameters (struct dvb_frontend
*fe,
}
tda10023_set_symbolrate (state, p-u.qam.symbol_rate);
- tda10023_writereg (state, 0x05, qamvals[qam][1]);
- tda10023_writereg (state, 0x08, qamvals[qam][2]);
- tda10023_writereg (state, 0x09, qamvals[qam][3]);
- tda10023_writereg (state, 0xb4, qamvals[qam][4]);
- tda10023_writereg (state, 0xb6, qamvals[qam][5]);
-
-// tda10023_writereg (state, 0x04, (p-inversion?0x12:0x32));
-// tda10023_writebit (state, 0x04, 0x60, (p-inversion?0:0x20));
- tda10023_writebit (state, 0x04, 0x40, 0x40);
- tda10023_setup_reg0 (state, qamvals[qam][0]);
+ tda10023_writereg(state, 0x05, qam_params[qam].lockthr);
+ tda10023_writereg(state, 0x08, qam_params[qam].mseth);
+ tda10023_writereg(state, 0x09, qam_params[qam].aref);
+ tda10023_writereg(state, 0xb4, qam_params[qam].agcrefnyq);
+ tda10023_writereg(state, 0xb6, qam_params[qam].eragnyq_thd);
+
+#if 0
+ tda10023_writereg(state, 0x04, (p-inversion ? 0x12 : 0x32));
+ tda10023_writebit(state, 0x04, 0x60, (p-inversion ? 0 : 0x20));
+#endif
+ tda10023_writebit(state, 0x04, 0x40, 0x40);
+ tda10023_setup_reg0(state, qam_params[qam].qam);
return 0;
}
--
1.7.8.352.g876a6
--
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 RFC v3 02/28] [media] Update documentation to reflect DVB-C Annex A/C support
Instead of using the same delivery system for both Annex A and
Annex C, split them into two separate ones. This helps to support
devices that only support Annex A.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
Documentation/DocBook/media/dvb/dvbproperty.xml | 11 +--
Documentation/DocBook/media/dvb/frontend.xml|4 ++--
2 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/Documentation/DocBook/media/dvb/dvbproperty.xml
b/Documentation/DocBook/media/dvb/dvbproperty.xml
index b812e31..ffee1fb 100644
--- a/Documentation/DocBook/media/dvb/dvbproperty.xml
+++ b/Documentation/DocBook/media/dvb/dvbproperty.xml
@@ -311,8 +311,6 @@ typedef enum fe_rolloff {
ROLLOFF_20,
ROLLOFF_25,
ROLLOFF_AUTO,
- ROLLOFF_15, /* DVB-C Annex A */
- ROLLOFF_13, /* DVB-C Annex C */
} fe_rolloff_t;
/programlisting
/section
@@ -336,9 +334,10 @@ typedef enum fe_rolloff {
titlefe_delivery_system type/title
paraPossible values: /para
programlisting
+
typedef enum fe_delivery_system {
SYS_UNDEFINED,
- SYS_DVBC_ANNEX_AC,
+ SYS_DVBC_ANNEX_A,
SYS_DVBC_ANNEX_B,
SYS_DVBT,
SYS_DSS,
@@ -355,6 +354,7 @@ typedef enum fe_delivery_system {
SYS_DAB,
SYS_DVBT2,
SYS_TURBO,
+ SYS_DVBC_ANNEX_C,
} fe_delivery_system_t;
/programlisting
/section
@@ -781,7 +781,8 @@ typedef enum fe_hierarchy {
titleProperties used on cable delivery systems/title
section id=dvbc-params
titleDVB-C delivery system/title
- paraThe DVB-C Annex-A/C is the widely used cable standard.
Transmission uses QAM modulation./para
+ paraThe DVB-C Annex-A is the widely used cable standard.
Transmission uses QAM modulation./para
+ paraThe DVB-C Annex-C is optimized for 6MHz, and is used in
Japan. It supports a subset of the Annex A modulation types, and a roll-off of
0.13, instead of 0.15/para
paraThe following parameters are valid for DVB-C Annex
A/C:/para
itemizedlist mark='opencircle'
listitemparalink
linkend=DTV-API-VERSIONconstantDTV_API_VERSION/constant/link/para/listitem
@@ -792,10 +793,8 @@ typedef enum fe_hierarchy {
listitemparalink
linkend=DTV-MODULATIONconstantDTV_MODULATION/constant/link/para/listitem
listitemparalink
linkend=DTV-INVERSIONconstantDTV_INVERSION/constant/link/para/listitem
listitemparalink
linkend=DTV-SYMBOL-RATEconstantDTV_SYMBOL_RATE/constant/link/para/listitem
- listitemparalink
linkend=DTV-ROLLOFFconstantDTV_ROLLOFF/constant/link/para/listitem
listitemparalink
linkend=DTV-INNER-FECconstantDTV_INNER_FEC/constant/link/para/listitem
/itemizedlist
- paraThe Rolloff of 0.15 (ROLLOFF_15) is assumed, as ITU-T
J.83 Annex A is more common. For Annex C, rolloff should be 0.13 (ROLLOFF_13).
All other values are invalid./para
/section
section id=dvbc-annex-b-params
titleDVB-C Annex B delivery system/title
diff --git a/Documentation/DocBook/media/dvb/frontend.xml
b/Documentation/DocBook/media/dvb/frontend.xml
index 61407ea..28d7ea5 100644
--- a/Documentation/DocBook/media/dvb/frontend.xml
+++ b/Documentation/DocBook/media/dvb/frontend.xml
@@ -45,8 +45,8 @@ transmission. The fontend types are given by fe_type_t type,
defined as:/para
/row
row
entry id=FE_QAMconstantFE_QAM/constant/entry
- entryFor DVB-C annex A/C standard/entry
- entryconstantSYS_DVBC_ANNEX_AC/constant/entry
+ entryFor DVB-C annex A standard/entry
+ entryconstantSYS_DVBC_ANNEX_A/constant/entry
/row
row
entry id=FE_OFDMconstantFE_OFDM/constant/entry
--
1.7.8.352.g876a6
--
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 RFC v3 06/28] [media] tda10023: add support for DVB-C Annex C
The difference between Annex A and C is the roll-off factor.
Properly implement it inside the driver, using the information
provided by Andreas.
Thanks-to: Andreas Oberriter o...@linuxtv.org
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/dvb/frontends/tda10023.c | 46 +++
1 files changed, 40 insertions(+), 6 deletions(-)
diff --git a/drivers/media/dvb/frontends/tda10023.c
b/drivers/media/dvb/frontends/tda10023.c
index e6c321e..af7f1b8 100644
--- a/drivers/media/dvb/frontends/tda10023.c
+++ b/drivers/media/dvb/frontends/tda10023.c
@@ -305,6 +305,10 @@ struct qam_params {
static int tda10023_set_parameters (struct dvb_frontend *fe,
struct dvb_frontend_parameters *p)
{
+ struct dtv_frontend_properties *c = fe-dtv_property_cache;
+ u32 delsys = c-delivery_system;
+ unsigned qam = c-modulation;
+ bool is_annex_c;
struct tda10023_state* state = fe-demodulator_priv;
static const struct qam_params qam_params[] = {
/* Modulation QAMLOCKTHR MSETH AREF AGCREFNYQ
ERAGCNYQ_THD */
@@ -315,7 +319,17 @@ static int tda10023_set_parameters (struct dvb_frontend
*fe,
[QAM_128] = { (32), 0x36,0x34, 0x7e, 0x78, 0x4c },
[QAM_256] = { (42), 0x26,0x23, 0x6c, 0x5c, 0x3c },
};
- unsigned qam = p-u.qam.modulation;
+
+ switch (delsys) {
+ case SYS_DVBC_ANNEX_A:
+ is_annex_c = false;
+ break;
+ case SYS_DVBC_ANNEX_C:
+ is_annex_c = true;
+ break;
+ default:
+ return -EINVAL;
+ }
/*
* gcc optimizes the code bellow the same way as it would code:
@@ -341,23 +355,43 @@ static int tda10023_set_parameters (struct dvb_frontend
*fe,
if (fe-ops.i2c_gate_ctrl) fe-ops.i2c_gate_ctrl(fe, 0);
}
- tda10023_set_symbolrate (state, p-u.qam.symbol_rate);
+ tda10023_set_symbolrate(state, c-symbol_rate);
tda10023_writereg(state, 0x05, qam_params[qam].lockthr);
tda10023_writereg(state, 0x08, qam_params[qam].mseth);
tda10023_writereg(state, 0x09, qam_params[qam].aref);
tda10023_writereg(state, 0xb4, qam_params[qam].agcrefnyq);
tda10023_writereg(state, 0xb6, qam_params[qam].eragnyq_thd);
-
#if 0
- tda10023_writereg(state, 0x04, (p-inversion ? 0x12 : 0x32));
- tda10023_writebit(state, 0x04, 0x60, (p-inversion ? 0 : 0x20));
+ tda10023_writereg(state, 0x04, (c-inversion ? 0x12 : 0x32));
+ tda10023_writebit(state, 0x04, 0x60, (c-inversion ? 0 : 0x20));
#endif
tda10023_writebit(state, 0x04, 0x40, 0x40);
+
+ if (is_annex_c)
+ tda10023_writebit(state, 0x3d, 0xfc, 0x03);
+ else
+ tda10023_writebit(state, 0x3d, 0xfc, 0x02);
+
tda10023_setup_reg0(state, qam_params[qam].qam);
return 0;
}
+static int tda10023_get_property(struct dvb_frontend *fe,
+struct dtv_property *p)
+{
+ switch (p-cmd) {
+ case DTV_ENUM_DELSYS:
+ p-u.buffer.data[0] = SYS_DVBC_ANNEX_A;
+ p-u.buffer.data[1] = SYS_DVBC_ANNEX_C;
+ p-u.buffer.len = 2;
+ break;
+ default:
+ break;
+ }
+ return 0;
+}
+
static int tda10023_read_status(struct dvb_frontend* fe, fe_status_t* status)
{
struct tda10023_state* state = fe-demodulator_priv;
@@ -577,7 +611,7 @@ static struct dvb_frontend_ops tda10023_ops = {
.set_frontend = tda10023_set_parameters,
.get_frontend = tda10023_get_frontend,
-
+ .get_property = tda10023_get_property,
.read_status = tda10023_read_status,
.read_ber = tda10023_read_ber,
.read_signal_strength = tda10023_read_signal_strength,
--
1.7.8.352.g876a6
--
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 RFC v3 04/28] [media] drx-k: report the supported delivery systems
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/dvb/frontends/drxk_hard.c | 28
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/drivers/media/dvb/frontends/drxk_hard.c
b/drivers/media/dvb/frontends/drxk_hard.c
index a2c8196..d795898 100644
--- a/drivers/media/dvb/frontends/drxk_hard.c
+++ b/drivers/media/dvb/frontends/drxk_hard.c
@@ -6364,6 +6364,32 @@ static int drxk_t_get_frontend(struct dvb_frontend *fe,
return 0;
}
+static int drxk_c_get_property(struct dvb_frontend *fe, struct dtv_property *p)
+{
+ switch (p-cmd) {
+ case DTV_ENUM_DELSYS:
+ p-u.buffer.data[0] = SYS_DVBC_ANNEX_A;
+ p-u.buffer.data[1] = SYS_DVBC_ANNEX_C;
+ p-u.buffer.len = 2;
+ break;
+ default:
+ break;
+ }
+ return 0;
+}
+static int drxk_t_get_property(struct dvb_frontend *fe, struct dtv_property *p)
+{
+ switch (p-cmd) {
+ case DTV_ENUM_DELSYS:
+ p-u.buffer.data[0] = SYS_DVBT;
+ p-u.buffer.len = 1;
+ break;
+ default:
+ break;
+ }
+ return 0;
+}
+
static struct dvb_frontend_ops drxk_c_ops = {
.info = {
.name = DRXK DVB-C,
@@ -6382,6 +6408,7 @@ static struct dvb_frontend_ops drxk_c_ops = {
.set_frontend = drxk_set_parameters,
.get_frontend = drxk_c_get_frontend,
+ .get_property = drxk_c_get_property,
.get_tune_settings = drxk_c_get_tune_settings,
.read_status = drxk_read_status,
@@ -6414,6 +6441,7 @@ static struct dvb_frontend_ops drxk_t_ops = {
.set_frontend = drxk_set_parameters,
.get_frontend = drxk_t_get_frontend,
+ .get_property = drxk_t_get_property,
.read_status = drxk_read_status,
.read_ber = drxk_read_ber,
--
1.7.8.352.g876a6
--
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 RFC v3 24/28] [media] tuner-xc2028: use DVBv5 parameters
Instead of using DVBv3 parameters, rely on DVBv5 parameters to
set the tuner.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/common/tuners/tuner-xc2028.c | 83
1 files changed, 36 insertions(+), 47 deletions(-)
diff --git a/drivers/media/common/tuners/tuner-xc2028.c
b/drivers/media/common/tuners/tuner-xc2028.c
index e531267..8c0dc6a1 100644
--- a/drivers/media/common/tuners/tuner-xc2028.c
+++ b/drivers/media/common/tuners/tuner-xc2028.c
@@ -1087,65 +1087,26 @@ static int xc2028_set_analog_freq(struct dvb_frontend
*fe,
static int xc2028_set_params(struct dvb_frontend *fe,
struct dvb_frontend_parameters *p)
{
+ struct dtv_frontend_properties *c = fe-dtv_property_cache;
+ u32 delsys = c-delivery_system;
+ u32 bw = c-bandwidth_hz;
struct xc2028_data *priv = fe-tuner_priv;
unsigned int type=0;
- fe_bandwidth_t bw = BANDWIDTH_8_MHZ;
u16demod = 0;
tuner_dbg(%s called\n, __func__);
- switch(fe-ops.info.type) {
- case FE_OFDM:
- bw = p-u.ofdm.bandwidth;
+ switch (delsys) {
+ case SYS_DVBT:
+ case SYS_DVBT2:
/*
* The only countries with 6MHz seem to be Taiwan/Uruguay.
* Both seem to require QAM firmware for OFDM decoding
* Tested in Taiwan by Terry Wu terrywu2...@gmail.com
*/
- if (bw == BANDWIDTH_6_MHZ)
+ if (bw = 600)
type |= QAM;
- break;
- case FE_ATSC:
- bw = BANDWIDTH_6_MHZ;
- /* The only ATSC firmware (at least on v2.7) is D2633 */
- type |= ATSC | D2633;
- break;
- /* DVB-S and pure QAM (FE_QAM) are not supported */
- default:
- return -EINVAL;
- }
-
- switch (bw) {
- case BANDWIDTH_8_MHZ:
- if (p-frequency 47000)
- priv-ctrl.vhfbw7 = 0;
- else
- priv-ctrl.uhfbw8 = 1;
- type |= (priv-ctrl.vhfbw7 priv-ctrl.uhfbw8) ? DTV78 : DTV8;
- type |= F8MHZ;
- break;
- case BANDWIDTH_7_MHZ:
- if (p-frequency 47000)
- priv-ctrl.vhfbw7 = 1;
- else
- priv-ctrl.uhfbw8 = 0;
- type |= (priv-ctrl.vhfbw7 priv-ctrl.uhfbw8) ? DTV78 : DTV7;
- type |= F8MHZ;
- break;
- case BANDWIDTH_6_MHZ:
- type |= DTV6;
- priv-ctrl.vhfbw7 = 0;
- priv-ctrl.uhfbw8 = 0;
- break;
- default:
- tuner_err(error: bandwidth not supported.\n);
- };
- /*
- Selects between D2633 or D2620 firmware.
- It doesn't make sense for ATSC, since it should be D2633 on all cases
-*/
- if (fe-ops.info.type != FE_ATSC) {
switch (priv-ctrl.type) {
case XC2028_D2633:
type |= D2633;
@@ -1161,6 +1122,34 @@ static int xc2028_set_params(struct dvb_frontend *fe,
else
type |= D2620;
}
+ break;
+ case SYS_ATSC:
+ /* The only ATSC firmware (at least on v2.7) is D2633 */
+ type |= ATSC | D2633;
+ break;
+ /* DVB-S and pure QAM (FE_QAM) are not supported */
+ default:
+ return -EINVAL;
+ }
+
+ if (bw = 600) {
+ type |= DTV6;
+ priv-ctrl.vhfbw7 = 0;
+ priv-ctrl.uhfbw8 = 0;
+ } else if (bw = 700) {
+ if (c-frequency 47000)
+ priv-ctrl.vhfbw7 = 1;
+ else
+ priv-ctrl.uhfbw8 = 0;
+ type |= (priv-ctrl.vhfbw7 priv-ctrl.uhfbw8) ? DTV78 : DTV7;
+ type |= F8MHZ;
+ } else {
+ if (c-frequency 47000)
+ priv-ctrl.vhfbw7 = 0;
+ else
+ priv-ctrl.uhfbw8 = 1;
+ type |= (priv-ctrl.vhfbw7 priv-ctrl.uhfbw8) ? DTV78 : DTV8;
+ type |= F8MHZ;
}
/* All S-code tables need a 200kHz shift */
@@ -1185,7 +1174,7 @@ static int xc2028_set_params(struct dvb_frontend *fe,
*/
}
- return generic_set_freq(fe, p-frequency,
+ return generic_set_freq(fe, c-frequency,
V4L2_TUNER_DIGITAL_TV, type, 0, demod);
}
--
1.7.8.352.g876a6
--
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 RFC v3 23/28] [media] tda827x: use DVBv5 parameters
Instead of using DVBv3 parameters, rely on DVBv5 parameters to
set the tuner.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/common/tuners/tda827x.c | 49 +++--
1 files changed, 28 insertions(+), 21 deletions(-)
diff --git a/drivers/media/common/tuners/tda827x.c
b/drivers/media/common/tuners/tda827x.c
index e0d5b43..7316308 100644
--- a/drivers/media/common/tuners/tda827x.c
+++ b/drivers/media/common/tuners/tda827x.c
@@ -155,9 +155,11 @@ static int tuner_transfer(struct dvb_frontend *fe,
static int tda827xo_set_params(struct dvb_frontend *fe,
struct dvb_frontend_parameters *params)
{
+ struct dtv_frontend_properties *c = fe-dtv_property_cache;
struct tda827x_priv *priv = fe-tuner_priv;
u8 buf[14];
int rc;
+ u32 band;
struct i2c_msg msg = { .addr = priv-i2c_addr, .flags = 0,
.buf = buf, .len = sizeof(buf) };
@@ -165,18 +167,20 @@ static int tda827xo_set_params(struct dvb_frontend *fe,
u32 N;
dprintk(%s:\n, __func__);
- switch (params-u.ofdm.bandwidth) {
- case BANDWIDTH_6_MHZ:
+ if (c-bandwidth_hz == 0) {
+ if_freq = 500;
+ band = BANDWIDTH_8_MHZ;
+ } else if (c-bandwidth_hz = 600) {
if_freq = 400;
- break;
- case BANDWIDTH_7_MHZ:
+ band = BANDWIDTH_6_MHZ;
+ } else if (c-bandwidth_hz = 700) {
if_freq = 450;
- break;
- default: /* 8 MHz or Auto */
+ band = BANDWIDTH_7_MHZ;
+ } else {/* 8 MHz */
if_freq = 500;
- break;
+ band = BANDWIDTH_8_MHZ;
}
- tuner_freq = params-frequency;
+ tuner_freq = c-frequency;
i = 0;
while (tda827x_table[i].lomax tuner_freq) {
@@ -220,8 +224,8 @@ static int tda827xo_set_params(struct dvb_frontend *fe,
if (rc 0)
goto err;
- priv-frequency = params-frequency;
- priv-bandwidth = (fe-ops.info.type == FE_OFDM) ?
params-u.ofdm.bandwidth : 0;
+ priv-frequency = c-frequency;
+ priv-bandwidth = band;
return 0;
@@ -516,9 +520,11 @@ static void tda827xa_lna_gain(struct dvb_frontend *fe, int
high,
static int tda827xa_set_params(struct dvb_frontend *fe,
struct dvb_frontend_parameters *params)
{
+ struct dtv_frontend_properties *c = fe-dtv_property_cache;
struct tda827x_priv *priv = fe-tuner_priv;
struct tda827xa_data *frequency_map = tda827xa_dvbt;
u8 buf[11];
+ u32 band;
struct i2c_msg msg = { .addr = priv-i2c_addr, .flags = 0,
.buf = buf, .len = sizeof(buf) };
@@ -531,18 +537,20 @@ static int tda827xa_set_params(struct dvb_frontend *fe,
tda827xa_lna_gain(fe, 1, NULL);
msleep(20);
- switch (params-u.ofdm.bandwidth) {
- case BANDWIDTH_6_MHZ:
+ if (c-bandwidth_hz == 0) {
+ if_freq = 500;
+ band = BANDWIDTH_8_MHZ;
+ } else if (c-bandwidth_hz = 600) {
if_freq = 400;
- break;
- case BANDWIDTH_7_MHZ:
+ band = BANDWIDTH_6_MHZ;
+ } else if (c-bandwidth_hz = 700) {
if_freq = 450;
- break;
- default: /* 8 MHz or Auto */
+ band = BANDWIDTH_7_MHZ;
+ } else {/* 8 MHz */
if_freq = 500;
- break;
+ band = BANDWIDTH_8_MHZ;
}
- tuner_freq = params-frequency;
+ tuner_freq = c-frequency;
if (fe-ops.info.type == FE_QAM) {
dprintk(%s select tda827xa_dvbc\n, __func__);
@@ -645,9 +653,8 @@ static int tda827xa_set_params(struct dvb_frontend *fe,
if (rc 0)
goto err;
- priv-frequency = params-frequency;
- priv-bandwidth = (fe-ops.info.type == FE_OFDM) ?
params-u.ofdm.bandwidth : 0;
-
+ priv-frequency = c-frequency;
+ priv-bandwidth = band;
return 0;
--
1.7.8.352.g876a6
--
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 RFC v3 19/28] [media] mxl5007t: use DVBv5 parameters
Instead of using DVBv3 parameters, rely on DVBv5 parameters to
set the tuner.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/common/tuners/mxl5007t.c | 53 ++--
1 files changed, 23 insertions(+), 30 deletions(-)
diff --git a/drivers/media/common/tuners/mxl5007t.c
b/drivers/media/common/tuners/mxl5007t.c
index 2f0e550..0d4f17c 100644
--- a/drivers/media/common/tuners/mxl5007t.c
+++ b/drivers/media/common/tuners/mxl5007t.c
@@ -618,44 +618,38 @@ fail:
static int mxl5007t_set_params(struct dvb_frontend *fe,
struct dvb_frontend_parameters *params)
{
+ struct dtv_frontend_properties *c = fe-dtv_property_cache;
+ u32 delsys = c-delivery_system;
struct mxl5007t_state *state = fe-tuner_priv;
enum mxl5007t_bw_mhz bw;
enum mxl5007t_mode mode;
int ret;
- u32 freq = params-frequency;
+ u32 freq = c-frequency;
+ u32 band = BANDWIDTH_6_MHZ;
- if (fe-ops.info.type == FE_ATSC) {
- switch (params-u.vsb.modulation) {
- case VSB_8:
- case VSB_16:
- mode = MxL_MODE_ATSC;
- break;
- case QAM_64:
- case QAM_256:
- mode = MxL_MODE_CABLE;
- break;
- default:
- mxl_err(modulation not set!);
- return -EINVAL;
- }
+ switch (delsys) {
+ case SYS_ATSC:
+ mode = MxL_MODE_ATSC;
bw = MxL_BW_6MHz;
- } else if (fe-ops.info.type == FE_OFDM) {
- switch (params-u.ofdm.bandwidth) {
- case BANDWIDTH_6_MHZ:
+ break;
+ case SYS_DVBC_ANNEX_B:
+ mode = MxL_MODE_CABLE;
+ bw = MxL_BW_6MHz;
+ break;
+ case SYS_DVBT:
+ case SYS_DVBT2:
+ mode = MxL_MODE_DVBT;
+ if (c-bandwidth_hz = 600) {
bw = MxL_BW_6MHz;
- break;
- case BANDWIDTH_7_MHZ:
+ } else if (c-bandwidth_hz = 700) {
bw = MxL_BW_7MHz;
- break;
- case BANDWIDTH_8_MHZ:
+ band = BANDWIDTH_7_MHZ;
+ } else {
bw = MxL_BW_8MHz;
- break;
- default:
- mxl_err(bandwidth not set!);
- return -EINVAL;
+ band = BANDWIDTH_8_MHZ;
}
- mode = MxL_MODE_DVBT;
- } else {
+ break;
+ default:
mxl_err(modulation type not supported!);
return -EINVAL;
}
@@ -674,8 +668,7 @@ static int mxl5007t_set_params(struct dvb_frontend *fe,
goto fail;
state-frequency = freq;
- state-bandwidth = (fe-ops.info.type == FE_OFDM) ?
- params-u.ofdm.bandwidth : 0;
+ state-bandwidth = band;
fail:
mutex_unlock(state-lock);
--
1.7.8.352.g876a6
--
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 RFC v3 18/28] [media] mxl5005s: fix: don't discard bandwidth changes
With the previous code, when the bandwidth changes, but using
the same delivery system, the code used to discard such changes.
This was happening because the bandwidth calculus were after the
check for delivery system changes. The previous patch changed
it to happen together with the delivery system check. So, with
a one-statement change, it is possible to force the tuner to
reconfigure, in order to adjust to bandwidth changes. this will
likely improve it when used on countries with 7MHz/8MHz
channels.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/common/tuners/mxl5005s.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/media/common/tuners/mxl5005s.c
b/drivers/media/common/tuners/mxl5005s.c
index c370220..a951011 100644
--- a/drivers/media/common/tuners/mxl5005s.c
+++ b/drivers/media/common/tuners/mxl5005s.c
@@ -4014,7 +4014,8 @@ static int mxl5005s_set_params(struct dvb_frontend *fe,
}
/* Change tuner for new modulation type if reqd */
- if (req_mode != state-current_mode) {
+ if (req_mode != state-current_mode ||
+ req_bw != state-Chan_Bandwidth) {
state-current_mode = req_mode;
ret = mxl5005s_reconfigure(fe, req_mode, req_bw);
--
1.7.8.352.g876a6
--
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 RFC v3 27/28] [media] dvb-bt8xx: use DVBv5 parameters
Instead of using DVBv3 parameters, rely on DVBv5 parameters to
set the tuner.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/dvb/bt8xx/dvb-bt8xx.c | 31 ---
1 files changed, 16 insertions(+), 15 deletions(-)
diff --git a/drivers/media/dvb/bt8xx/dvb-bt8xx.c
b/drivers/media/dvb/bt8xx/dvb-bt8xx.c
index 521d691..5948601 100644
--- a/drivers/media/dvb/bt8xx/dvb-bt8xx.c
+++ b/drivers/media/dvb/bt8xx/dvb-bt8xx.c
@@ -193,11 +193,10 @@ static struct zl10353_config
thomson_dtt7579_zl10353_config = {
static int cx24108_tuner_set_params(struct dvb_frontend* fe, struct
dvb_frontend_parameters* params)
{
- u32 freq = params-frequency;
-
+ struct dtv_frontend_properties *c = fe-dtv_property_cache;
+ u32 freq = c-frequency;
int i, a, n, pump;
u32 band, pll;
-
u32 osci[]={95,1019000,1075000,1178000,1296000,1432000,
1576000,1718000,1856000,2036000,215};
u32 bandsel[]={0,0x0002,0x0004,0x00100800,0x00101000,
@@ -269,29 +268,30 @@ static struct cx24110_config pctvsat_config = {
static int microtune_mt7202dtf_tuner_set_params(struct dvb_frontend* fe,
struct dvb_frontend_parameters* params)
{
+ struct dtv_frontend_properties *c = fe-dtv_property_cache;
struct dvb_bt8xx_card *card = (struct dvb_bt8xx_card *) fe-dvb-priv;
u8 cfg, cpump, band_select;
u8 data[4];
u32 div;
struct i2c_msg msg = { .addr = 0x60, .flags = 0, .buf = data, .len =
sizeof(data) };
- div = (3600 + params-frequency + 8) / 16;
+ div = (3600 + c-frequency + 8) / 16;
cfg = 0x88;
- if (params-frequency 17500)
+ if (c-frequency 17500)
cpump = 2;
- else if (params-frequency 39000)
+ else if (c-frequency 39000)
cpump = 1;
- else if (params-frequency 47000)
+ else if (c-frequency 47000)
cpump = 2;
- else if (params-frequency 75000)
+ else if (c-frequency 75000)
cpump = 2;
else
cpump = 3;
- if (params-frequency 17500)
+ if (c-frequency 17500)
band_select = 0x0e;
- else if (params-frequency 47000)
+ else if (c-frequency 47000)
band_select = 0x05;
else
band_select = 0x03;
@@ -463,23 +463,24 @@ static struct or51211_config or51211_config = {
static int vp3021_alps_tded4_tuner_set_params(struct dvb_frontend* fe, struct
dvb_frontend_parameters* params)
{
+ struct dtv_frontend_properties *c = fe-dtv_property_cache;
struct dvb_bt8xx_card *card = (struct dvb_bt8xx_card *) fe-dvb-priv;
u8 buf[4];
u32 div;
struct i2c_msg msg = { .addr = 0x60, .flags = 0, .buf = buf, .len =
sizeof(buf) };
- div = (params-frequency + 3617) / 17;
+ div = (c-frequency + 3617) / 17;
buf[0] = (div 8) 0x7F;
buf[1] = div 0xFF;
buf[2] = 0x85;
- if ((params-frequency = 4700) (params-frequency 15300))
+ if ((c-frequency = 4700) (c-frequency 15300))
buf[3] = 0x01;
- else if ((params-frequency = 15300) (params-frequency
43000))
+ else if ((c-frequency = 15300) (c-frequency 43000))
buf[3] = 0x02;
- else if ((params-frequency = 43000) (params-frequency
82400))
+ else if ((c-frequency = 43000) (c-frequency 82400))
buf[3] = 0x0C;
- else if ((params-frequency = 82400) (params-frequency
86300))
+ else if ((c-frequency = 82400) (c-frequency 86300))
buf[3] = 0x8C;
else
return -EINVAL;
--
1.7.8.352.g876a6
--
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 RFC v3 14/28] [media] mc44s803: use DVBv5 parameters
Instead of using DVBv3 parameters, rely on DVBv5 parameters to
set the tuner.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/common/tuners/mc44s803.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/media/common/tuners/mc44s803.c
b/drivers/media/common/tuners/mc44s803.c
index fe5c4b8..5a8758c 100644
--- a/drivers/media/common/tuners/mc44s803.c
+++ b/drivers/media/common/tuners/mc44s803.c
@@ -218,18 +218,19 @@ static int mc44s803_set_params(struct dvb_frontend *fe,
struct dvb_frontend_parameters *params)
{
struct mc44s803_priv *priv = fe-tuner_priv;
+ struct dtv_frontend_properties *c = fe-dtv_property_cache;
u32 r1, r2, n1, n2, lo1, lo2, freq, val;
int err;
- priv-frequency = params-frequency;
+ priv-frequency = c-frequency;
r1 = MC44S803_OSC / 100;
r2 = MC44S803_OSC / 10;
- n1 = (params-frequency + MC44S803_IF1 + 50) / 100;
+ n1 = (c-frequency + MC44S803_IF1 + 50) / 100;
freq = MC44S803_OSC / r1 * n1;
lo1 = ((60 * n1) + (r1 / 2)) / r1;
- freq = freq - params-frequency;
+ freq = freq - c-frequency;
n2 = (freq - MC44S803_IF2 + 5) / 10;
lo2 = ((60 * n2) + (r2 / 2)) / r2;
--
1.7.8.352.g876a6
--
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 RFC v3 16/28] [media] mt2266: use DVBv5 parameters
Instead of using DVBv3 parameters, rely on DVBv5 parameters to
set the tuner.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/common/tuners/mt2266.c | 20 +---
1 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/media/common/tuners/mt2266.c
b/drivers/media/common/tuners/mt2266.c
index 25a8ea3..d539740 100644
--- a/drivers/media/common/tuners/mt2266.c
+++ b/drivers/media/common/tuners/mt2266.c
@@ -124,6 +124,7 @@ static u8 mt2266_vhf[] = { 0x1d, 0xfe, 0x00, 0x00, 0xb4,
0x03, 0xa5, 0xa5,
static int mt2266_set_params(struct dvb_frontend *fe, struct
dvb_frontend_parameters *params)
{
+ struct dtv_frontend_properties *c = fe-dtv_property_cache;
struct mt2266_priv *priv;
int ret=0;
u32 freq;
@@ -135,31 +136,28 @@ static int mt2266_set_params(struct dvb_frontend *fe,
struct dvb_frontend_parame
priv = fe-tuner_priv;
- freq = params-frequency / 1000; // Hz - kHz
+ freq = priv-frequency / 1000; /* Hz - kHz */
if (freq 47 freq 23)
return -EINVAL; /* Gap between VHF and UHF bands */
- priv-bandwidth = (fe-ops.info.type == FE_OFDM) ?
params-u.ofdm.bandwidth : 0;
- priv-frequency = freq * 1000;
+ priv-frequency = c-frequency;
tune = 2 * freq * (8192/16) / (FREF/16);
band = (freq 30) ? MT2266_VHF : MT2266_UHF;
if (band == MT2266_VHF)
tune *= 2;
- switch (params-u.ofdm.bandwidth) {
- case BANDWIDTH_6_MHZ:
+ if (c-bandwidth_hz = 600) {
mt2266_writeregs(priv, mt2266_init_6mhz,
sizeof(mt2266_init_6mhz));
- break;
- case BANDWIDTH_7_MHZ:
+ priv-bandwidth = BANDWIDTH_6_MHZ;
+ } else if (c-bandwidth_hz = 700) {
mt2266_writeregs(priv, mt2266_init_7mhz,
sizeof(mt2266_init_7mhz));
- break;
- case BANDWIDTH_8_MHZ:
- default:
+ priv-bandwidth = BANDWIDTH_7_MHZ;
+ } else {
mt2266_writeregs(priv, mt2266_init_8mhz,
sizeof(mt2266_init_8mhz));
- break;
+ priv-bandwidth = BANDWIDTH_8_MHZ;
}
if (band == MT2266_VHF priv-band == MT2266_UHF) {
--
1.7.8.352.g876a6
--
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 RFC v3 15/28] [media] max2165: use DVBv5 parameters
Instead of using DVBv3 parameters, rely on DVBv5 parameters to
set the tuner.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/common/tuners/max2165.c | 60
1 files changed, 37 insertions(+), 23 deletions(-)
diff --git a/drivers/media/common/tuners/max2165.c
b/drivers/media/common/tuners/max2165.c
index 9883617..8558a63 100644
--- a/drivers/media/common/tuners/max2165.c
+++ b/drivers/media/common/tuners/max2165.c
@@ -150,11 +150,26 @@ static int max2165_set_osc(struct max2165_priv *priv, u8
osc /*MHz*/)
static int max2165_set_bandwidth(struct max2165_priv *priv, u32 bw)
{
u8 val;
+ u32 newbw;
- if (bw == BANDWIDTH_8_MHZ)
- val = priv-bb_filter_8mhz_cfg;
- else
+ if (bw = 700) {
val = priv-bb_filter_7mhz_cfg;
+ priv-bandwidth = BANDWIDTH_7_MHZ;
+ newbw = 700;
+ } else {
+ val = priv-bb_filter_8mhz_cfg;
+ priv-bandwidth = BANDWIDTH_8_MHZ;
+ newbw = 800;
+ }
+
+ switch (bw) {
+ case 700:
+ case 800:
+ break;
+ default:
+ printk(KERN_INFO MAX2165: bandwidth %d Hz not supported. using
%d Hz instead\n,
+ bw, newbw);
+ }
max2165_mask_write_reg(priv, REG_BASEBAND_CTRL, 0xF0, val 4);
@@ -261,35 +276,34 @@ static int max2165_set_params(struct dvb_frontend *fe,
struct dvb_frontend_parameters *params)
{
struct max2165_priv *priv = fe-tuner_priv;
+ struct dtv_frontend_properties *c = fe-dtv_property_cache;
+ u32 delsys = c-delivery_system;
int ret;
- dprintk(%s() frequency=%d (Hz)\n, __func__, params-frequency);
- if (fe-ops.info.type == FE_ATSC) {
- return -EINVAL;
- } else if (fe-ops.info.type == FE_OFDM) {
+ dprintk(%s() frequency=%d (Hz)\n, __func__, c-frequency);
+
+ switch (delsys) {
+ case SYS_DVBT:
+ case SYS_DVBT2:
dprintk(%s() OFDM\n, __func__);
- switch (params-u.ofdm.bandwidth) {
- case BANDWIDTH_6_MHZ:
- return -EINVAL;
- case BANDWIDTH_7_MHZ:
- case BANDWIDTH_8_MHZ:
- priv-frequency = params-frequency;
- priv-bandwidth = params-u.ofdm.bandwidth;
- break;
- default:
- printk(KERN_ERR MAX2165 bandwidth not set!\n);
- return -EINVAL;
- }
- } else {
- printk(KERN_ERR MAX2165 modulation type not supported!\n);
+ break;
+ /*
+* FIXME: it is likely that this would work with DVB-C as well,
+* at least for 7MHz/8MHz. If this is needed, all the code should
+* do is to add a new case SYS_DVBC_ANNEX_A line.
+*/
+ default:
+ printk(KERN_ERR MAX2165: delivery system not supported!\n);
return -EINVAL;
}
+ priv-frequency = c-frequency;
+
dprintk(%s() frequency=%d\n, __func__, priv-frequency);
if (fe-ops.i2c_gate_ctrl)
fe-ops.i2c_gate_ctrl(fe, 1);
- max2165_set_bandwidth(priv, priv-bandwidth);
+ max2165_set_bandwidth(priv, c-bandwidth_hz);
ret = max2165_set_rf(priv, priv-frequency);
mdelay(50);
max2165_debug_status(priv);
@@ -370,7 +384,7 @@ static int max2165_init(struct dvb_frontend *fe)
max2165_read_rom_table(priv);
- max2165_set_bandwidth(priv, BANDWIDTH_8_MHZ);
+ max2165_set_bandwidth(priv, 800);
if (fe-ops.i2c_gate_ctrl)
fe-ops.i2c_gate_ctrl(fe, 0);
--
1.7.8.352.g876a6
--
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 RFC v3 07/28] [media] tda10021: Don't use a magic numbers for QAM modulation
Convert the existing data struct to use the QAM modulation macros,
instead of assuming that they're numbered from 0 to 5.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/dvb/frontends/tda10021.c | 59
1 files changed, 37 insertions(+), 22 deletions(-)
diff --git a/drivers/media/dvb/frontends/tda10021.c
b/drivers/media/dvb/frontends/tda10021.c
index 6ca533e..cd9952e 100644
--- a/drivers/media/dvb/frontends/tda10021.c
+++ b/drivers/media/dvb/frontends/tda10021.c
@@ -224,27 +224,43 @@ static int tda10021_init (struct dvb_frontend *fe)
return 0;
}
+struct qam_params {
+ u8 conf, agcref, lthr, mseth, aref;
+};
+
static int tda10021_set_parameters (struct dvb_frontend *fe,
struct dvb_frontend_parameters *p)
{
struct tda10021_state* state = fe-demodulator_priv;
-
- //table for QAM4-QAM256 ready QAM4 QAM16 QAM32 QAM64 QAM128 QAM256
- //CONF
- static const u8 reg0x00 [] = { 0x14, 0x00, 0x04, 0x08, 0x0c, 0x10 };
- //AGCREF value
- static const u8 reg0x01 [] = { 0x78, 0x8c, 0x8c, 0x6a, 0x78, 0x5c };
- //LTHR value
- static const u8 reg0x05 [] = { 0x78, 0x87, 0x64, 0x46, 0x36, 0x26 };
- //MSETH
- static const u8 reg0x08 [] = { 0x8c, 0xa2, 0x74, 0x43, 0x34, 0x23 };
- //AREF
- static const u8 reg0x09 [] = { 0x96, 0x91, 0x96, 0x6a, 0x7e, 0x6b };
-
+ static const struct qam_params qam_params[] = {
+ /* Modulation Conf AGCref LTHR MSETH AREF */
+ [QPSK] = { 0x14, 0x78, 0x78, 0x8c, 0x96 },
+ [QAM_16] = { 0x00, 0x8c, 0x87, 0xa2, 0x91 },
+ [QAM_32] = { 0x04, 0x8c, 0x64, 0x74, 0x96 },
+ [QAM_64] = { 0x08, 0x6a, 0x46, 0x43, 0x6a },
+ [QAM_128] = { 0x0c, 0x78, 0x36, 0x34, 0x7e },
+ [QAM_256] = { 0x10, 0x5c, 0x26, 0x23, 0x6b },
+ };
int qam = p-u.qam.modulation;
- if (qam 0 || qam 5)
+ /*
+* gcc optimizes the code bellow the same way as it would code:
+* if (qam 5) return -EINVAL;
+* Yet, the code is clearer, as it shows what QAM standards are
+* supported by the driver, and avoids the usage of magic numbers on
+* it.
+*/
+ switch (qam) {
+ case QPSK:
+ case QAM_16:
+ case QAM_32:
+ case QAM_64:
+ case QAM_128:
+ case QAM_256:
+ break;
+ default:
return -EINVAL;
+ }
if (p-inversion != INVERSION_ON p-inversion != INVERSION_OFF)
return -EINVAL;
@@ -256,15 +272,14 @@ static int tda10021_set_parameters (struct dvb_frontend
*fe,
if (fe-ops.i2c_gate_ctrl) fe-ops.i2c_gate_ctrl(fe, 0);
}
- tda10021_set_symbolrate (state, p-u.qam.symbol_rate);
- _tda10021_writereg (state, 0x34, state-pwm);
-
- _tda10021_writereg (state, 0x01, reg0x01[qam]);
- _tda10021_writereg (state, 0x05, reg0x05[qam]);
- _tda10021_writereg (state, 0x08, reg0x08[qam]);
- _tda10021_writereg (state, 0x09, reg0x09[qam]);
+ tda10021_set_symbolrate(state, p-u.qam.symbol_rate);
+ _tda10021_writereg(state, 0x34, state-pwm);
- tda10021_setup_reg0 (state, reg0x00[qam], p-inversion);
+ _tda10021_writereg(state, 0x01, qam_params[qam].agcref);
+ _tda10021_writereg(state, 0x05, qam_params[qam].lthr);
+ _tda10021_writereg(state, 0x08, qam_params[qam].mseth);
+ _tda10021_writereg(state, 0x09, qam_params[qam].aref);
+ tda10021_setup_reg0(state, qam_params[qam].conf, p-inversion);
return 0;
}
--
1.7.8.352.g876a6
--
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 RFC v3 20/28] [media] tda18218: use DVBv5 parameters
Instead of using DVBv3 parameters, rely on DVBv5 parameters to
set the tuner.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/common/tuners/tda18218.c | 15 ++-
1 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/media/common/tuners/tda18218.c
b/drivers/media/common/tuners/tda18218.c
index 1c86595..bbed0cf 100644
--- a/drivers/media/common/tuners/tda18218.c
+++ b/drivers/media/common/tuners/tda18218.c
@@ -113,6 +113,8 @@ static int tda18218_set_params(struct dvb_frontend *fe,
struct dvb_frontend_parameters *params)
{
struct tda18218_priv *priv = fe-tuner_priv;
+ struct dtv_frontend_properties *c = fe-dtv_property_cache;
+ u32 bw = c-bandwidth_hz;
int ret;
u8 buf[3], i, BP_Filter, LP_Fc;
u32 LO_Frac;
@@ -138,23 +140,18 @@ static int tda18218_set_params(struct dvb_frontend *fe,
fe-ops.i2c_gate_ctrl(fe, 1); /* open I2C-gate */
/* low-pass filter cut-off frequency */
- switch (params-u.ofdm.bandwidth) {
- case BANDWIDTH_6_MHZ:
+ if (bw = 600) {
LP_Fc = 0;
priv-if_frequency = 400;
- break;
- case BANDWIDTH_7_MHZ:
+ } else if (bw = 700) {
LP_Fc = 1;
priv-if_frequency = 350;
- break;
- case BANDWIDTH_8_MHZ:
- default:
+ } else {
LP_Fc = 2;
priv-if_frequency = 400;
- break;
}
- LO_Frac = params-frequency + priv-if_frequency;
+ LO_Frac = c-frequency + priv-if_frequency;
/* band-pass filter */
if (LO_Frac 18800)
--
1.7.8.352.g876a6
--
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 RFC v3 22/28] [media] tda18271-fe: use DVBv5 parameters
Instead of using DVBv3 parameters, rely on DVBv5 parameters to
set the tuner.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/common/tuners/tda18271-fe.c | 74 +---
1 files changed, 34 insertions(+), 40 deletions(-)
diff --git a/drivers/media/common/tuners/tda18271-fe.c
b/drivers/media/common/tuners/tda18271-fe.c
index 3347c5b..4630154 100644
--- a/drivers/media/common/tuners/tda18271-fe.c
+++ b/drivers/media/common/tuners/tda18271-fe.c
@@ -931,56 +931,51 @@ fail:
static int tda18271_set_params(struct dvb_frontend *fe,
struct dvb_frontend_parameters *params)
{
+ struct dtv_frontend_properties *c = fe-dtv_property_cache;
+ u32 delsys = c-delivery_system;
+ u32 bw = c-bandwidth_hz;
+ u32 freq = c-frequency;
+ u32 band = BANDWIDTH_6_MHZ;
struct tda18271_priv *priv = fe-tuner_priv;
struct tda18271_std_map *std_map = priv-std;
struct tda18271_std_map_item *map;
int ret;
- u32 bw, freq = params-frequency;
priv-mode = TDA18271_DIGITAL;
- if (fe-ops.info.type == FE_ATSC) {
- switch (params-u.vsb.modulation) {
- case VSB_8:
- case VSB_16:
- map = std_map-atsc_6;
- break;
- case QAM_64:
- case QAM_256:
- map = std_map-qam_6;
- break;
- default:
- tda_warn(modulation not set!\n);
- return -EINVAL;
- }
-#if 0
- /* userspace request is already center adjusted */
- freq += 175; /* Adjust to center (+1.75MHZ) */
-#endif
+ switch (delsys) {
+ case SYS_ATSC:
+ map = std_map-atsc_6;
bw = 600;
- } else if (fe-ops.info.type == FE_OFDM) {
- switch (params-u.ofdm.bandwidth) {
- case BANDWIDTH_6_MHZ:
- bw = 600;
+ break;
+case SYS_DVBT:
+case SYS_DVBT2:
+ if (bw = 600) {
map = std_map-dvbt_6;
- break;
- case BANDWIDTH_7_MHZ:
- bw = 700;
+ } else if (bw = 700) {
map = std_map-dvbt_7;
- break;
- case BANDWIDTH_8_MHZ:
- bw = 800;
+ band = BANDWIDTH_7_MHZ;
+ } else {
map = std_map-dvbt_8;
- break;
- default:
- tda_warn(bandwidth not set!\n);
- return -EINVAL;
+ band = BANDWIDTH_8_MHZ;
}
- } else if (fe-ops.info.type == FE_QAM) {
- /* DVB-C */
- map = std_map-qam_8;
- bw = 800;
- } else {
+ break;
+ case SYS_DVBC_ANNEX_B:
+ bw = 600;
+ /* falltrough */
+case SYS_DVBC_ANNEX_A:
+case SYS_DVBC_ANNEX_C:
+ if (bw = 600) {
+ map = std_map-qam_6;
+ } else if (bw = 700) {
+ map = std_map-qam_7;
+ band = BANDWIDTH_7_MHZ;
+ } else {
+ map = std_map-qam_8;
+ band = BANDWIDTH_8_MHZ;
+ }
+ break;
+ default:
tda_warn(modulation type not supported!\n);
return -EINVAL;
}
@@ -996,8 +991,7 @@ static int tda18271_set_params(struct dvb_frontend *fe,
priv-if_freq = map-if_freq;
priv-frequency = freq;
- priv-bandwidth = (fe-ops.info.type == FE_OFDM) ?
- params-u.ofdm.bandwidth : 0;
+ priv-bandwidth = band;
fail:
return ret;
}
--
1.7.8.352.g876a6
--
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 RFC v3 03/28] [media] Remove Annex A/C selection via roll-off factor
Instead of using a roll-off factor, change DRX-K friends to select
the bandwidth filter and the Nyquist half roll-off via delivery system.
This provides a cleaner support for Annex A/C switch.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/common/tuners/xc5000.c | 137 +++
drivers/media/dvb/dvb-core/dvb_frontend.c | 25 -
drivers/media/dvb/frontends/drxk_hard.c| 15 ++-
drivers/media/dvb/frontends/tda18271c2dd.c | 44 -
include/linux/dvb/frontend.h |2 -
5 files changed, 106 insertions(+), 117 deletions(-)
diff --git a/drivers/media/common/tuners/xc5000.c
b/drivers/media/common/tuners/xc5000.c
index 97ad338..5c56d3c 100644
--- a/drivers/media/common/tuners/xc5000.c
+++ b/drivers/media/common/tuners/xc5000.c
@@ -629,11 +629,13 @@ static void xc_debug_dump(struct xc5000_priv *priv)
}
static int xc5000_set_params(struct dvb_frontend *fe,
- struct dvb_frontend_parameters *params)
+struct dvb_frontend_parameters *params)
{
+ int ret, b;
struct xc5000_priv *priv = fe-tuner_priv;
- int ret;
- u32 bw;
+ u32 bw = fe-dtv_property_cache.bandwidth_hz;
+ u32 freq = fe-dtv_property_cache.frequency;
+ u32 delsys = fe-dtv_property_cache.delivery_system;
if (xc5000_is_firmware_loaded(fe) != XC_RESULT_SUCCESS) {
if (xc_load_fw_and_init_tuner(fe) != XC_RESULT_SUCCESS) {
@@ -642,104 +644,77 @@ static int xc5000_set_params(struct dvb_frontend *fe,
}
}
- dprintk(1, %s() frequency=%d (Hz)\n, __func__, params-frequency);
+ dprintk(1, %s() frequency=%d (Hz)\n, __func__, freq);
- if (fe-ops.info.type == FE_ATSC) {
- dprintk(1, %s() ATSC\n, __func__);
- switch (params-u.vsb.modulation) {
- case VSB_8:
- case VSB_16:
- dprintk(1, %s() VSB modulation\n, __func__);
- priv-rf_mode = XC_RF_MODE_AIR;
- priv-freq_hz = params-frequency - 175;
- priv-bandwidth = BANDWIDTH_6_MHZ;
- priv-video_standard = DTV6;
- break;
- case QAM_64:
- case QAM_256:
- case QAM_AUTO:
- dprintk(1, %s() QAM modulation\n, __func__);
- priv-rf_mode = XC_RF_MODE_CABLE;
- priv-freq_hz = params-frequency - 175;
- priv-bandwidth = BANDWIDTH_6_MHZ;
- priv-video_standard = DTV6;
- break;
- default:
- return -EINVAL;
- }
- } else if (fe-ops.info.type == FE_OFDM) {
+ switch (delsys) {
+ case SYS_ATSC:
+ dprintk(1, %s() VSB modulation\n, __func__);
+ priv-rf_mode = XC_RF_MODE_AIR;
+ priv-freq_hz = freq - 175;
+ priv-bandwidth = BANDWIDTH_6_MHZ;
+ priv-video_standard = DTV6;
+ break;
+ case SYS_DVBC_ANNEX_B:
+ dprintk(1, %s() QAM modulation\n, __func__);
+ priv-rf_mode = XC_RF_MODE_CABLE;
+ priv-freq_hz = freq - 175;
+ priv-bandwidth = BANDWIDTH_6_MHZ;
+ priv-video_standard = DTV6;
+ break;
+ case SYS_DVBT:
+ case SYS_DVBT2:
dprintk(1, %s() OFDM\n, __func__);
- switch (params-u.ofdm.bandwidth) {
- case BANDWIDTH_6_MHZ:
+ switch (bw) {
+ case 600:
priv-bandwidth = BANDWIDTH_6_MHZ;
priv-video_standard = DTV6;
- priv-freq_hz = params-frequency - 175;
+ priv-freq_hz = freq - 175;
break;
- case BANDWIDTH_7_MHZ:
+ case 700:
priv-bandwidth = BANDWIDTH_7_MHZ;
priv-video_standard = DTV7;
- priv-freq_hz = params-frequency - 225;
+ priv-freq_hz = freq - 225;
break;
- case BANDWIDTH_8_MHZ:
+ case 800:
priv-bandwidth = BANDWIDTH_8_MHZ;
priv-video_standard = DTV8;
- priv-freq_hz = params-frequency - 275;
+ priv-freq_hz = freq - 275;
break;
default:
printk(KERN_ERR xc5000 bandwidth not set!\n);
return -EINVAL;
}
priv-rf_mode = XC_RF_MODE_AIR;
- } else if (fe-ops.info.type == FE_QAM) {
- switch (params-u.qam.modulation) {
- case QAM_256:
- case QAM_AUTO:
-
[PATCH RFC v3 01/28] [media] DVB: Use a unique delivery system identifier for DVBC_ANNEX_C
From: Manu Abraham abraham.m...@gmail.com
Use a unique delivery system identifier for DVBC_ANNEX_C, just like any
other.
DVBC_ANNEX_A and DVBC_ANNEX_C have slightly different parameters
and are used in 2 geographically different locations.
Signed-off-by: Manu Abraham abraham.m...@gmail.com
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
include/linux/dvb/frontend.h |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/include/linux/dvb/frontend.h b/include/linux/dvb/frontend.h
index cb114f5..b2a939f8 100644
--- a/include/linux/dvb/frontend.h
+++ b/include/linux/dvb/frontend.h
@@ -337,7 +337,7 @@ typedef enum fe_rolloff {
typedef enum fe_delivery_system {
SYS_UNDEFINED,
- SYS_DVBC_ANNEX_AC,
+ SYS_DVBC_ANNEX_A,
SYS_DVBC_ANNEX_B,
SYS_DVBT,
SYS_DSS,
@@ -354,8 +354,13 @@ typedef enum fe_delivery_system {
SYS_DAB,
SYS_DVBT2,
SYS_TURBO,
+ SYS_DVBC_ANNEX_C,
} fe_delivery_system_t;
+
+#define SYS_DVBC_ANNEX_AC SYS_DVBC_ANNEX_A
+
+
struct dtv_cmds_h {
char*name; /* A display name for debugging purposes */
--
1.7.8.352.g876a6
--
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 RFC v3 26/28] [media] tuner-simple: get rid of DVBv3 params at set_params call
Despite its name, tuner-simple has a complex logic to set freqs ;)
Basically, it can be called by two different ways: via set_params()
or via calc_regs() callbacks. Both are bound to the DVBv3 API.
Also, set_params internally calls calc_regs().
In order to get rid of DVBv3 params at set_params(), it shouldn't
call calc_regs() anymore. The code duplication is very small,
as most of the code there is just to check for invalid parameters.
With regards to calc_regs(), it should still trust on bandwidth and
frequency parameters passed via DVBv3.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/common/tuners/tuner-simple.c | 63 ---
1 files changed, 46 insertions(+), 17 deletions(-)
diff --git a/drivers/media/common/tuners/tuner-simple.c
b/drivers/media/common/tuners/tuner-simple.c
index 4092200..e6342db 100644
--- a/drivers/media/common/tuners/tuner-simple.c
+++ b/drivers/media/common/tuners/tuner-simple.c
@@ -791,24 +791,26 @@ static int simple_set_params(struct dvb_frontend *fe,
}
static void simple_set_dvb(struct dvb_frontend *fe, u8 *buf,
- const struct dvb_frontend_parameters *params)
+ const u32 delsys,
+ const u32 frequency,
+ const u32 bandwidth)
{
struct tuner_simple_priv *priv = fe-tuner_priv;
switch (priv-type) {
case TUNER_PHILIPS_FMD1216ME_MK3:
case TUNER_PHILIPS_FMD1216MEX_MK3:
- if (params-u.ofdm.bandwidth == BANDWIDTH_8_MHZ
- params-frequency = 15887)
+ if (bandwidth == 800
+ frequency = 15887)
buf[3] |= 0x08;
break;
case TUNER_PHILIPS_TD1316:
/* determine band */
- buf[3] |= (params-frequency 16100) ? 1 :
- (params-frequency 44400) ? 2 : 4;
+ buf[3] |= (frequency 16100) ? 1 :
+ (frequency 44400) ? 2 : 4;
/* setup PLL filter */
- if (params-u.ofdm.bandwidth == BANDWIDTH_8_MHZ)
+ if (bandwidth == 800)
buf[3] |= 1 3;
break;
case TUNER_PHILIPS_TUV1236D:
@@ -819,12 +821,11 @@ static void simple_set_dvb(struct dvb_frontend *fe, u8
*buf,
if (dtv_input[priv-nr])
new_rf = dtv_input[priv-nr];
else
- switch (params-u.vsb.modulation) {
- case QAM_64:
- case QAM_256:
+ switch (delsys) {
+ case SYS_DVBC_ANNEX_B:
new_rf = 1;
break;
- case VSB_8:
+ case SYS_ATSC:
default:
new_rf = 0;
break;
@@ -838,7 +839,9 @@ static void simple_set_dvb(struct dvb_frontend *fe, u8 *buf,
}
static u32 simple_dvb_configure(struct dvb_frontend *fe, u8 *buf,
- const struct dvb_frontend_parameters *params)
+ const u32 delsys,
+ const u32 freq,
+ const u32 bw)
{
/* This function returns the tuned frequency on success, 0 on error */
struct tuner_simple_priv *priv = fe-tuner_priv;
@@ -847,7 +850,7 @@ static u32 simple_dvb_configure(struct dvb_frontend *fe, u8
*buf,
u8 config, cb;
u32 div;
int ret;
- unsigned frequency = params-frequency / 62500;
+ u32 frequency = freq / 62500;
if (!tun-stepsize) {
/* tuner-core was loaded before the digital tuner was
@@ -871,7 +874,7 @@ static u32 simple_dvb_configure(struct dvb_frontend *fe, u8
*buf,
buf[2] = config;
buf[3] = cb;
- simple_set_dvb(fe, buf, params);
+ simple_set_dvb(fe, buf, delsys, freq, bw);
tuner_dbg(%s: div=%d | buf=0x%02x,0x%02x,0x%02x,0x%02x\n,
tun-name, div, buf[0], buf[1], buf[2], buf[3]);
@@ -884,13 +887,29 @@ static int simple_dvb_calc_regs(struct dvb_frontend *fe,
struct dvb_frontend_parameters *params,
u8 *buf, int buf_len)
{
+ struct dtv_frontend_properties *c = fe-dtv_property_cache;
+ u32 delsys = c-delivery_system;
+ u32 bw = c-bandwidth_hz;
struct tuner_simple_priv *priv = fe-tuner_priv;
u32 frequency;
if (buf_len 5)
return -EINVAL;
- frequency = simple_dvb_configure(fe, buf+1, params);
+ switch (delsys) {
+ case SYS_DVBT:
+ case SYS_DVBT2:
+ if (params-u.ofdm.bandwidth == BANDWIDTH_6_MHZ)
+ bw = 600;
+ if
[PATCH RFC v3 28/28] [media] dvb-pll: use DVBv5 parameters
Instead of using DVBv3 parameters, rely on DVBv5 parameters to
set the tuner.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/dvb/frontends/dvb-pll.c | 61 +---
1 files changed, 32 insertions(+), 29 deletions(-)
diff --git a/drivers/media/dvb/frontends/dvb-pll.c
b/drivers/media/dvb/frontends/dvb-pll.c
index 62a65ef..4ed7bee 100644
--- a/drivers/media/dvb/frontends/dvb-pll.c
+++ b/drivers/media/dvb/frontends/dvb-pll.c
@@ -61,8 +61,7 @@ struct dvb_pll_desc {
u32 min;
u32 max;
u32 iffreq;
- void (*set)(struct dvb_frontend *fe, u8 *buf,
- const struct dvb_frontend_parameters *params);
+ void (*set)(struct dvb_frontend *fe, u8 *buf);
u8 *initdata;
u8 *initdata2;
u8 *sleepdata;
@@ -93,10 +92,10 @@ static struct dvb_pll_desc dvb_pll_thomson_dtt7579 = {
},
};
-static void thomson_dtt759x_bw(struct dvb_frontend *fe, u8 *buf,
- const struct dvb_frontend_parameters *params)
+static void thomson_dtt759x_bw(struct dvb_frontend *fe, u8 *buf)
{
- if (BANDWIDTH_7_MHZ == params-u.ofdm.bandwidth)
+ u32 bw = fe-dtv_property_cache.bandwidth_hz;
+ if (bw == 700)
buf[3] |= 0x10;
}
@@ -186,10 +185,10 @@ static struct dvb_pll_desc dvb_pll_env57h1xd5 = {
/* Philips TDA6650/TDA6651
* used in Panasonic ENV77H11D5
*/
-static void tda665x_bw(struct dvb_frontend *fe, u8 *buf,
- const struct dvb_frontend_parameters *params)
+static void tda665x_bw(struct dvb_frontend *fe, u8 *buf)
{
- if (params-u.ofdm.bandwidth == BANDWIDTH_8_MHZ)
+ u32 bw = fe-dtv_property_cache.bandwidth_hz;
+ if (bw == 800)
buf[3] |= 0x08;
}
@@ -220,10 +219,10 @@ static struct dvb_pll_desc dvb_pll_tda665x = {
/* Infineon TUA6034
* used in LG TDTP E102P
*/
-static void tua6034_bw(struct dvb_frontend *fe, u8 *buf,
- const struct dvb_frontend_parameters *params)
+static void tua6034_bw(struct dvb_frontend *fe, u8 *buf)
{
- if (BANDWIDTH_7_MHZ != params-u.ofdm.bandwidth)
+ u32 bw = fe-dtv_property_cache.bandwidth_hz;
+ if (bw == 700)
buf[3] |= 0x08;
}
@@ -244,10 +243,10 @@ static struct dvb_pll_desc dvb_pll_tua6034 = {
/* ALPS TDED4
* used in Nebula-Cards and USB boxes
*/
-static void tded4_bw(struct dvb_frontend *fe, u8 *buf,
-const struct dvb_frontend_parameters *params)
+static void tded4_bw(struct dvb_frontend *fe, u8 *buf)
{
- if (params-u.ofdm.bandwidth == BANDWIDTH_8_MHZ)
+ u32 bw = fe-dtv_property_cache.bandwidth_hz;
+ if (bw == 800)
buf[3] |= 0x04;
}
@@ -319,11 +318,11 @@ static struct dvb_pll_desc dvb_pll_philips_sd1878_tda8261
= {
},
};
-static void opera1_bw(struct dvb_frontend *fe, u8 *buf,
- const struct dvb_frontend_parameters *params)
+static void opera1_bw(struct dvb_frontend *fe, u8 *buf)
{
+ struct dtv_frontend_properties *c = fe-dtv_property_cache;
struct dvb_pll_priv *priv = fe-tuner_priv;
- u32 b_w = (params-u.qpsk.symbol_rate * 27) / 32000;
+ u32 b_w = (c-symbol_rate * 27) / 32000;
struct i2c_msg msg = {
.addr = priv-pll_i2c_address,
.flags = 0,
@@ -392,8 +391,7 @@ static struct dvb_pll_desc dvb_pll_opera1 = {
}
};
-static void samsung_dtos403ih102a_set(struct dvb_frontend *fe, u8 *buf,
- const struct dvb_frontend_parameters *params)
+static void samsung_dtos403ih102a_set(struct dvb_frontend *fe, u8 *buf)
{
struct dvb_pll_priv *priv = fe-tuner_priv;
struct i2c_msg msg = {
@@ -537,30 +535,29 @@ static struct dvb_pll_desc *pll_list[] = {
/* code*/
static int dvb_pll_configure(struct dvb_frontend *fe, u8 *buf,
-const struct dvb_frontend_parameters *params)
+const u32 frequency)
{
struct dvb_pll_priv *priv = fe-tuner_priv;
struct dvb_pll_desc *desc = priv-pll_desc;
u32 div;
int i;
- if (params-frequency != 0 (params-frequency desc-min ||
- params-frequency desc-max))
+ if (frequency (frequency desc-min || frequency desc-max))
return -EINVAL;
for (i = 0; i desc-count; i++) {
- if (params-frequency desc-entries[i].limit)
+ if (frequency desc-entries[i].limit)
continue;
break;
}
if (debug)
printk(pll: %s: freq=%d | i=%d/%d\n, desc-name,
- params-frequency, i, desc-count);
+ frequency, i, desc-count);
if (i == desc-count)
return -EINVAL;
- div = (params-frequency + desc-iffreq +
+
[PATCH RFC v3 08/28] [media] tda10021: Add support for DVB-C Annex C
While tda10021 supports both DVB-C Annex A and C, it is currently
hard-coded to Annex A. Add support for Annex C and re-work the
code in order to report the delivery systems, thans to Andreas,
that passed us the register settings for the Roll-off factor.
Thanks-to: Andreas Oberriter o...@linuxtv.org
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/dvb/frontends/tda10021.c | 49 +--
1 files changed, 45 insertions(+), 4 deletions(-)
diff --git a/drivers/media/dvb/frontends/tda10021.c
b/drivers/media/dvb/frontends/tda10021.c
index cd9952e..2518c5a 100644
--- a/drivers/media/dvb/frontends/tda10021.c
+++ b/drivers/media/dvb/frontends/tda10021.c
@@ -231,6 +231,11 @@ struct qam_params {
static int tda10021_set_parameters (struct dvb_frontend *fe,
struct dvb_frontend_parameters *p)
{
+ struct dtv_frontend_properties *c = fe-dtv_property_cache;
+ u32 delsys = c-delivery_system;
+ unsigned qam = c-modulation;
+ bool is_annex_c;
+ u32 reg0x3d;
struct tda10021_state* state = fe-demodulator_priv;
static const struct qam_params qam_params[] = {
/* Modulation Conf AGCref LTHR MSETH AREF */
@@ -241,7 +246,17 @@ static int tda10021_set_parameters (struct dvb_frontend
*fe,
[QAM_128] = { 0x0c, 0x78, 0x36, 0x34, 0x7e },
[QAM_256] = { 0x10, 0x5c, 0x26, 0x23, 0x6b },
};
- int qam = p-u.qam.modulation;
+
+ switch (delsys) {
+ case SYS_DVBC_ANNEX_A:
+ is_annex_c = false;
+ break;
+ case SYS_DVBC_ANNEX_C:
+ is_annex_c = true;
+ break;
+ default:
+ return -EINVAL;
+ }
/*
* gcc optimizes the code bellow the same way as it would code:
@@ -262,7 +277,7 @@ static int tda10021_set_parameters (struct dvb_frontend *fe,
return -EINVAL;
}
- if (p-inversion != INVERSION_ON p-inversion != INVERSION_OFF)
+ if (c-inversion != INVERSION_ON c-inversion != INVERSION_OFF)
return -EINVAL;
//printk(tda10021: set frequency to %d qam=%d symrate=%d\n,
p-frequency,qam,p-u.qam.symbol_rate);
@@ -272,14 +287,24 @@ static int tda10021_set_parameters (struct dvb_frontend
*fe,
if (fe-ops.i2c_gate_ctrl) fe-ops.i2c_gate_ctrl(fe, 0);
}
- tda10021_set_symbolrate(state, p-u.qam.symbol_rate);
+ tda10021_set_symbolrate(state, c-symbol_rate);
_tda10021_writereg(state, 0x34, state-pwm);
_tda10021_writereg(state, 0x01, qam_params[qam].agcref);
_tda10021_writereg(state, 0x05, qam_params[qam].lthr);
_tda10021_writereg(state, 0x08, qam_params[qam].mseth);
_tda10021_writereg(state, 0x09, qam_params[qam].aref);
- tda10021_setup_reg0(state, qam_params[qam].conf, p-inversion);
+
+ /*
+* Bit 0 == 0 means roll-off = 0.15 (Annex A)
+* == 1 means roll-off = 0.13 (Annex C)
+*/
+ reg0x3d = tda10021_readreg (state, 0x3d);
+ if (is_annex_c)
+ _tda10021_writereg (state, 0x3d, 0x01 | reg0x3d);
+ else
+ _tda10021_writereg (state, 0x3d, 0xfe reg0x3d);
+ tda10021_setup_reg0(state, qam_params[qam].conf, c-inversion);
return 0;
}
@@ -458,6 +483,21 @@ error:
return NULL;
}
+static int tda10021_get_property(struct dvb_frontend *fe,
+struct dtv_property *p)
+{
+ switch (p-cmd) {
+ case DTV_ENUM_DELSYS:
+ p-u.buffer.data[0] = SYS_DVBC_ANNEX_A;
+ p-u.buffer.data[1] = SYS_DVBC_ANNEX_C;
+ p-u.buffer.len = 2;
+ break;
+ default:
+ break;
+ }
+ return 0;
+}
+
static struct dvb_frontend_ops tda10021_ops = {
.info = {
@@ -486,6 +526,7 @@ static struct dvb_frontend_ops tda10021_ops = {
.set_frontend = tda10021_set_parameters,
.get_frontend = tda10021_get_frontend,
+ .get_property = tda10021_get_property,
.read_status = tda10021_read_status,
.read_ber = tda10021_read_ber,
--
1.7.8.352.g876a6
--
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 RFC v3 21/28] [media] tda18271: add support for QAM 7 MHz map
This standard is not properly documented, but its settings are at
the tda18271dd driver, and are somewhat obvious, as they follow
the same logic as DVB-T 7MHz.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/common/tuners/tda18271-maps.c |4
drivers/media/common/tuners/tda18271.h |1 +
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/media/common/tuners/tda18271-maps.c
b/drivers/media/common/tuners/tda18271-maps.c
index 3d5b6ab..fb881c6 100644
--- a/drivers/media/common/tuners/tda18271-maps.c
+++ b/drivers/media/common/tuners/tda18271-maps.c
@@ -1213,6 +1213,8 @@ static struct tda18271_std_map tda18271c1_std_map = {
.if_lvl = 1, .rfagc_top = 0x37, }, /* EP3[4:0] 0x1e */
.qam_6= { .if_freq = 4000, .fm_rfn = 0, .agc_mode = 3, .std = 5,
.if_lvl = 1, .rfagc_top = 0x37, }, /* EP3[4:0] 0x1d */
+ .qam_7= { .if_freq = 4500, .fm_rfn = 0, .agc_mode = 3, .std = 6,
+ .if_lvl = 1, .rfagc_top = 0x37, }, /* EP3[4:0] 0x1e */
.qam_8= { .if_freq = 5000, .fm_rfn = 0, .agc_mode = 3, .std = 7,
.if_lvl = 1, .rfagc_top = 0x37, }, /* EP3[4:0] 0x1f */
};
@@ -1244,6 +1246,8 @@ static struct tda18271_std_map tda18271c2_std_map = {
.if_lvl = 1, .rfagc_top = 0x37, }, /* EP3[4:0] 0x1d */
.qam_6= { .if_freq = 4000, .fm_rfn = 0, .agc_mode = 3, .std = 5,
.if_lvl = 1, .rfagc_top = 0x37, }, /* EP3[4:0] 0x1d */
+ .qam_7= { .if_freq = 4500, .fm_rfn = 0, .agc_mode = 3, .std = 6,
+ .if_lvl = 1, .rfagc_top = 0x37, }, /* EP3[4:0] 0x1e */
.qam_8= { .if_freq = 5000, .fm_rfn = 0, .agc_mode = 3, .std = 7,
.if_lvl = 1, .rfagc_top = 0x37, }, /* EP3[4:0] 0x1f */
};
diff --git a/drivers/media/common/tuners/tda18271.h
b/drivers/media/common/tuners/tda18271.h
index 50cfa8c..640bae4 100644
--- a/drivers/media/common/tuners/tda18271.h
+++ b/drivers/media/common/tuners/tda18271.h
@@ -53,6 +53,7 @@ struct tda18271_std_map {
struct tda18271_std_map_item dvbt_7;
struct tda18271_std_map_item dvbt_8;
struct tda18271_std_map_item qam_6;
+ struct tda18271_std_map_item qam_7;
struct tda18271_std_map_item qam_8;
};
--
1.7.8.352.g876a6
--
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 RFC v3 09/28] [media] Rename set_frontend fops to set_frontend_legacy
Passing DVBv3 parameters to set_frontend is not fun, as the
core doesn't have any way to know if the driver is using the
v3 or v5 parameters. So, rename the callback and add a new
one to allow distinguish between a mixed v3/v5 paramenter call
from a pure v5 call.
After having all frontends to use the new way, the legacy
call can be removed.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/dvb/bt8xx/dst.c |8
drivers/media/dvb/dvb-core/dvb_frontend.c |8 ++--
drivers/media/dvb/dvb-core/dvb_frontend.h |3 ++-
drivers/media/dvb/dvb-usb/af9005-fe.c |2 +-
drivers/media/dvb/dvb-usb/cinergyT2-fe.c|2 +-
drivers/media/dvb/dvb-usb/dtt200u-fe.c |2 +-
drivers/media/dvb/dvb-usb/friio-fe.c|2 +-
drivers/media/dvb/dvb-usb/gp8psk-fe.c |2 +-
drivers/media/dvb/dvb-usb/mxl111sf-demod.c |2 +-
drivers/media/dvb/dvb-usb/vp702x-fe.c |2 +-
drivers/media/dvb/dvb-usb/vp7045-fe.c |2 +-
drivers/media/dvb/firewire/firedtv-fe.c |2 +-
drivers/media/dvb/frontends/af9013.c|2 +-
drivers/media/dvb/frontends/atbm8830.c |2 +-
drivers/media/dvb/frontends/au8522_dig.c|2 +-
drivers/media/dvb/frontends/bcm3510.c |2 +-
drivers/media/dvb/frontends/cx22700.c |2 +-
drivers/media/dvb/frontends/cx22702.c |2 +-
drivers/media/dvb/frontends/cx24110.c |2 +-
drivers/media/dvb/frontends/cx24116.c |2 +-
drivers/media/dvb/frontends/cx24123.c |2 +-
drivers/media/dvb/frontends/cxd2820r_core.c |2 +-
drivers/media/dvb/frontends/dib3000mb.c |2 +-
drivers/media/dvb/frontends/dib3000mc.c |2 +-
drivers/media/dvb/frontends/dib7000m.c |2 +-
drivers/media/dvb/frontends/dib7000p.c |2 +-
drivers/media/dvb/frontends/dib8000.c |2 +-
drivers/media/dvb/frontends/dib9000.c |2 +-
drivers/media/dvb/frontends/drxd_hard.c |2 +-
drivers/media/dvb/frontends/drxk_hard.c |4 ++--
drivers/media/dvb/frontends/ds3000.c|2 +-
drivers/media/dvb/frontends/dvb_dummy_fe.c |6 +++---
drivers/media/dvb/frontends/ec100.c |2 +-
drivers/media/dvb/frontends/it913x-fe.c |2 +-
drivers/media/dvb/frontends/l64781.c|2 +-
drivers/media/dvb/frontends/lgdt3305.c |4 ++--
drivers/media/dvb/frontends/lgdt330x.c |4 ++--
drivers/media/dvb/frontends/lgs8gl5.c |2 +-
drivers/media/dvb/frontends/lgs8gxx.c |2 +-
drivers/media/dvb/frontends/mb86a20s.c |2 +-
drivers/media/dvb/frontends/mt312.c |2 +-
drivers/media/dvb/frontends/mt352.c |2 +-
drivers/media/dvb/frontends/nxt200x.c |2 +-
drivers/media/dvb/frontends/nxt6000.c |2 +-
drivers/media/dvb/frontends/or51132.c |2 +-
drivers/media/dvb/frontends/or51211.c |2 +-
drivers/media/dvb/frontends/s5h1409.c |2 +-
drivers/media/dvb/frontends/s5h1411.c |2 +-
drivers/media/dvb/frontends/s5h1420.c |2 +-
drivers/media/dvb/frontends/s5h1432.c |2 +-
drivers/media/dvb/frontends/s921.c |2 +-
drivers/media/dvb/frontends/si21xx.c|2 +-
drivers/media/dvb/frontends/sp8870.c|2 +-
drivers/media/dvb/frontends/sp887x.c|2 +-
drivers/media/dvb/frontends/stv0288.c |2 +-
drivers/media/dvb/frontends/stv0297.c |2 +-
drivers/media/dvb/frontends/stv0299.c |2 +-
drivers/media/dvb/frontends/stv0367.c |4 ++--
drivers/media/dvb/frontends/tda10021.c |2 +-
drivers/media/dvb/frontends/tda10023.c |2 +-
drivers/media/dvb/frontends/tda10048.c |2 +-
drivers/media/dvb/frontends/tda1004x.c |4 ++--
drivers/media/dvb/frontends/tda10071.c |2 +-
drivers/media/dvb/frontends/tda10086.c |2 +-
drivers/media/dvb/frontends/tda8083.c |2 +-
drivers/media/dvb/frontends/ves1820.c |2 +-
drivers/media/dvb/frontends/ves1x93.c |2 +-
drivers/media/dvb/frontends/zl10353.c |2 +-
drivers/media/dvb/siano/smsdvb.c|2 +-
drivers/media/dvb/ttpci/av7110.c|2 +-
drivers/media/dvb/ttusb-dec/ttusbdecfe.c|4 ++--
drivers/media/video/tlg2300/pd-dvb.c|2 +-
drivers/staging/media/as102/as102_fe.c |2 +-
73 files changed, 90 insertions(+), 85 deletions(-)
diff --git a/drivers/media/dvb/bt8xx/dst.c b/drivers/media/dvb/bt8xx/dst.c
index caa4e18..4658bd6 100644
--- a/drivers/media/dvb/bt8xx/dst.c
+++ b/drivers/media/dvb/bt8xx/dst.c
@@ -1777,7 +1777,7 @@ static struct dvb_frontend_ops dst_dvbt_ops = {
.release = dst_release,
.init = dst_init,
.tune = dst_tune_frontend,
- .set_frontend = dst_set_frontend,
+ .set_frontend_legacy = dst_set_frontend,
.get_frontend = dst_get_frontend,
[PATCH RFC v3 10/28] [media] dvb_core: estimate bw for all non-terrestial systems
Instead of just estimating the bandwidth for DVB-C annex A/C,
also fill it at the core for ATSC and DVB-C annex B. This
simplifies the logic inside the tuners, as all non-satellite
tuners can just use c-bandwidth_hz for all supported
delivery systems.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/dvb/dvb-core/dvb_frontend.c | 35 ++--
1 files changed, 27 insertions(+), 8 deletions(-)
diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c
b/drivers/media/dvb/dvb-core/dvb_frontend.c
index 1e1bc64..9f123b3 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -1184,19 +1184,38 @@ static void dtv_property_adv_params_sync(struct
dvb_frontend *fe)
}
/*
-* On DVB-C, the bandwidth is a function of roll-off and symbol rate.
-* The bandwidth is required for DVB-C tuners, in order to avoid
-* inter-channel noise. Instead of estimating the minimal required
-* bandwidth on every single driver, calculates it here and fills
-* it at the cache bandwidth parameter.
+* Be sure that the bandwidth will be filled for all
+* non-satellite systems, as tuners need to know what
+* low pass/Nyquist half filter should be applied, in
+* order to avoid inter-channel noise.
+*
+* ISDB-T and DVB-T/T2 already sets bandwidth.
+* ATSC and DVB-C don't set, so, the core should fill it.
+*
+* On DVB-C Annex A and C, the bandwidth is a function of
+* the roll-off and symbol rate. Annex B defines different
+* roll-off factors depending on the modulation. Fortunately,
+* Annex B is only used with 6MHz, so there's no need to
+* calculate it.
+*
* While not officially supported, a side effect of handling it at
* the cache level is that a program could retrieve the bandwidth
-* via DTV_BANDWIDTH_HZ, wich may be useful for test programs.
+* via DTV_BANDWIDTH_HZ, which may be useful for test programs.
*/
- if (c-delivery_system == SYS_DVBC_ANNEX_A)
+ switch (c-delivery_system) {
+ case SYS_ATSC:
+ case SYS_DVBC_ANNEX_B:
+ c-bandwidth_hz = 600;
+ break;
+ case SYS_DVBC_ANNEX_A:
rolloff = 115;
- if (c-delivery_system == SYS_DVBC_ANNEX_C)
+ break;
+ case SYS_DVBC_ANNEX_C:
rolloff = 113;
+ break;
+ default:
+ break;
+ }
if (rolloff)
c-bandwidth_hz = (c-symbol_rate * rolloff) / 100;
}
--
1.7.8.352.g876a6
--
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 RFC v3 13/28] [media] mt2031: remove fake implementaion of get_bandwidth()
This driver implements a fake get_bandwidth() callback. In
reallity, the tuner driver won't adjust its low-pass
filter based on a bandwidth, and were just providing a fake
method for demods to read whatever was set.
This code is useless, as none of the drivers that use
this tuner seems to require a get_bandwidth() callback.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/common/tuners/mt2131.c | 17 ++---
drivers/media/common/tuners/mt2131_priv.h |1 -
2 files changed, 2 insertions(+), 16 deletions(-)
diff --git a/drivers/media/common/tuners/mt2131.c
b/drivers/media/common/tuners/mt2131.c
index a4f830b..d9cab1f 100644
--- a/drivers/media/common/tuners/mt2131.c
+++ b/drivers/media/common/tuners/mt2131.c
@@ -95,6 +95,7 @@ static int mt2131_writeregs(struct mt2131_priv *priv,u8 *buf,
u8 len)
static int mt2131_set_params(struct dvb_frontend *fe,
struct dvb_frontend_parameters *params)
{
+ struct dtv_frontend_properties *c = fe-dtv_property_cache;
struct mt2131_priv *priv;
int ret=0, i;
u32 freq;
@@ -105,12 +106,8 @@ static int mt2131_set_params(struct dvb_frontend *fe,
u8 lockval = 0;
priv = fe-tuner_priv;
- if (fe-ops.info.type == FE_OFDM)
- priv-bandwidth = params-u.ofdm.bandwidth;
- else
- priv-bandwidth = 0;
- freq = params-frequency / 1000; // Hz - kHz
+ freq = c-frequency / 1000; /* Hz - kHz */
dprintk(1, %s() freq=%d\n, __func__, freq);
f_lo1 = freq + MT2131_IF1 * 1000;
@@ -193,14 +190,6 @@ static int mt2131_get_frequency(struct dvb_frontend *fe,
u32 *frequency)
return 0;
}
-static int mt2131_get_bandwidth(struct dvb_frontend *fe, u32 *bandwidth)
-{
- struct mt2131_priv *priv = fe-tuner_priv;
- dprintk(1, %s()\n, __func__);
- *bandwidth = priv-bandwidth;
- return 0;
-}
-
static int mt2131_get_status(struct dvb_frontend *fe, u32 *status)
{
struct mt2131_priv *priv = fe-tuner_priv;
@@ -263,7 +252,6 @@ static const struct dvb_tuner_ops mt2131_tuner_ops = {
.set_params= mt2131_set_params,
.get_frequency = mt2131_get_frequency,
- .get_bandwidth = mt2131_get_bandwidth,
.get_status= mt2131_get_status
};
@@ -281,7 +269,6 @@ struct dvb_frontend * mt2131_attach(struct dvb_frontend *fe,
return NULL;
priv-cfg = cfg;
- priv-bandwidth = 600; /* 6MHz */
priv-i2c = i2c;
if (mt2131_readreg(priv, 0, id) != 0) {
diff --git a/drivers/media/common/tuners/mt2131_priv.h
b/drivers/media/common/tuners/mt2131_priv.h
index 4e05a67..62aeedf 100644
--- a/drivers/media/common/tuners/mt2131_priv.h
+++ b/drivers/media/common/tuners/mt2131_priv.h
@@ -38,7 +38,6 @@ struct mt2131_priv {
struct i2c_adapter *i2c;
u32 frequency;
- u32 bandwidth;
};
#endif /* __MT2131_PRIV_H__ */
--
1.7.8.352.g876a6
--
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 RFC v3 25/28] [media] xc4000: use DVBv5 parameters
Instead of using DVBv3 parameters, rely on DVBv5 parameters to
set the tuner.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/common/tuners/xc4000.c | 97 +++---
1 files changed, 42 insertions(+), 55 deletions(-)
diff --git a/drivers/media/common/tuners/xc4000.c
b/drivers/media/common/tuners/xc4000.c
index 634f4d9..e6acc7a 100644
--- a/drivers/media/common/tuners/xc4000.c
+++ b/drivers/media/common/tuners/xc4000.c
@@ -1124,80 +1124,67 @@ static void xc_debug_dump(struct xc4000_priv *priv)
static int xc4000_set_params(struct dvb_frontend *fe,
struct dvb_frontend_parameters *params)
{
+ struct dtv_frontend_properties *c = fe-dtv_property_cache;
+ u32 delsys = c-delivery_system;
+ u32 bw = c-bandwidth_hz;
struct xc4000_priv *priv = fe-tuner_priv;
unsigned int type;
int ret = -EREMOTEIO;
- dprintk(1, %s() frequency=%d (Hz)\n, __func__, params-frequency);
+ dprintk(1, %s() frequency=%d (Hz)\n, __func__, c-frequency);
mutex_lock(priv-lock);
- if (fe-ops.info.type == FE_ATSC) {
- dprintk(1, %s() ATSC\n, __func__);
- switch (params-u.vsb.modulation) {
- case VSB_8:
- case VSB_16:
- dprintk(1, %s() VSB modulation\n, __func__);
- priv-rf_mode = XC_RF_MODE_AIR;
- priv-freq_hz = params-frequency - 175;
- priv-bandwidth = BANDWIDTH_6_MHZ;
- priv-video_standard = XC4000_DTV6;
- type = DTV6;
- break;
- case QAM_64:
- case QAM_256:
- case QAM_AUTO:
- dprintk(1, %s() QAM modulation\n, __func__);
- priv-rf_mode = XC_RF_MODE_CABLE;
- priv-freq_hz = params-frequency - 175;
- priv-bandwidth = BANDWIDTH_6_MHZ;
- priv-video_standard = XC4000_DTV6;
- type = DTV6;
- break;
- default:
- ret = -EINVAL;
- goto fail;
- }
- } else if (fe-ops.info.type == FE_OFDM) {
+ switch (delsys) {
+ case SYS_ATSC:
+ dprintk(1, %s() VSB modulation\n, __func__);
+ priv-rf_mode = XC_RF_MODE_AIR;
+ priv-freq_hz = c-frequency - 175;
+ priv-bandwidth = BANDWIDTH_6_MHZ;
+ priv-video_standard = XC4000_DTV6;
+ type = DTV6;
+ break;
+ case SYS_DVBC_ANNEX_B:
+ dprintk(1, %s() QAM modulation\n, __func__);
+ priv-rf_mode = XC_RF_MODE_CABLE;
+ priv-freq_hz = c-frequency - 175;
+ priv-bandwidth = BANDWIDTH_6_MHZ;
+ priv-video_standard = XC4000_DTV6;
+ type = DTV6;
+ break;
+ case SYS_DVBT:
+ case SYS_DVBT2:
dprintk(1, %s() OFDM\n, __func__);
- switch (params-u.ofdm.bandwidth) {
- case BANDWIDTH_6_MHZ:
+ if (bw == 0) {
+ if (c-frequency 4) {
+ priv-bandwidth = BANDWIDTH_7_MHZ;
+ priv-freq_hz = c-frequency - 225;
+ } else {
+ priv-bandwidth = BANDWIDTH_8_MHZ;
+ priv-freq_hz = c-frequency - 275;
+ }
+ priv-video_standard = XC4000_DTV7_8;
+ type = DTV78;
+ } else if (bw = 600) {
priv-bandwidth = BANDWIDTH_6_MHZ;
priv-video_standard = XC4000_DTV6;
- priv-freq_hz = params-frequency - 175;
+ priv-freq_hz = c-frequency - 175;
type = DTV6;
- break;
- case BANDWIDTH_7_MHZ:
+ } else if (bw = 700) {
priv-bandwidth = BANDWIDTH_7_MHZ;
priv-video_standard = XC4000_DTV7;
- priv-freq_hz = params-frequency - 225;
+ priv-freq_hz = c-frequency - 225;
type = DTV7;
- break;
- case BANDWIDTH_8_MHZ:
+ } else {
priv-bandwidth = BANDWIDTH_8_MHZ;
priv-video_standard = XC4000_DTV8;
- priv-freq_hz = params-frequency - 275;
+ priv-freq_hz = c-frequency - 275;
type = DTV8;
- break;
- case BANDWIDTH_AUTO:
- if (params-frequency 4) {
- priv-bandwidth =
[PATCH RFC v3 11/28] [media] qt1010: remove fake implementaion of get_bandwidth()
This driver implements a fake get_bandwidth() callback. In
reallity, the tuner driver won't adjust its low-pass
filter based on a bandwidth, and were just providing a fake
method for demods to read whatever was set.
This code is useless, as none of the drivers that use
this tuner seems to require a get_bandwidth() callback.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/common/tuners/qt1010.c | 16
drivers/media/common/tuners/qt1010_priv.h |1 -
2 files changed, 4 insertions(+), 13 deletions(-)
diff --git a/drivers/media/common/tuners/qt1010.c
b/drivers/media/common/tuners/qt1010.c
index cd461c2..bd433ad 100644
--- a/drivers/media/common/tuners/qt1010.c
+++ b/drivers/media/common/tuners/qt1010.c
@@ -85,6 +85,7 @@ static void qt1010_dump_regs(struct qt1010_priv *priv)
static int qt1010_set_params(struct dvb_frontend *fe,
struct dvb_frontend_parameters *params)
{
+ struct dtv_frontend_properties *c = fe-dtv_property_cache;
struct qt1010_priv *priv;
int err;
u32 freq, div, mod1, mod2;
@@ -144,13 +145,11 @@ static int qt1010_set_params(struct dvb_frontend *fe,
#define FREQ2 400 /* 4 MHz Quartz oscillator in the stick? */
priv = fe-tuner_priv;
- freq = params-frequency;
+ freq = c-frequency;
div = (freq + QT1010_OFFSET) / QT1010_STEP;
freq = (div * QT1010_STEP) - QT1010_OFFSET;
mod1 = (freq + QT1010_OFFSET) % FREQ1;
mod2 = (freq + QT1010_OFFSET) % FREQ2;
- priv-bandwidth =
- (fe-ops.info.type == FE_OFDM) ? params-u.ofdm.bandwidth : 0;
priv-frequency = freq;
if (fe-ops.i2c_gate_ctrl)
@@ -321,6 +320,7 @@ static int qt1010_init(struct dvb_frontend *fe)
{
struct qt1010_priv *priv = fe-tuner_priv;
struct dvb_frontend_parameters params;
+ struct dtv_frontend_properties *c = fe-dtv_property_cache;
int err = 0;
u8 i, tmpval, *valptr = NULL;
@@ -397,7 +397,7 @@ static int qt1010_init(struct dvb_frontend *fe)
if ((err = qt1010_init_meas2(priv, i, tmpval)))
return err;
- params.frequency = 54500; /* Sigmatek DVB-110 54500 */
+ c-frequency = 54500; /* Sigmatek DVB-110 54500 */
/* MSI Megasky 580 GL861 53300 */
return qt1010_set_params(fe, params);
}
@@ -416,13 +416,6 @@ static int qt1010_get_frequency(struct dvb_frontend *fe,
u32 *frequency)
return 0;
}
-static int qt1010_get_bandwidth(struct dvb_frontend *fe, u32 *bandwidth)
-{
- struct qt1010_priv *priv = fe-tuner_priv;
- *bandwidth = priv-bandwidth;
- return 0;
-}
-
static int qt1010_get_if_frequency(struct dvb_frontend *fe, u32 *frequency)
{
*frequency = 36125000;
@@ -443,7 +436,6 @@ static const struct dvb_tuner_ops qt1010_tuner_ops = {
.set_params= qt1010_set_params,
.get_frequency = qt1010_get_frequency,
- .get_bandwidth = qt1010_get_bandwidth,
.get_if_frequency = qt1010_get_if_frequency,
};
diff --git a/drivers/media/common/tuners/qt1010_priv.h
b/drivers/media/common/tuners/qt1010_priv.h
index 090cf47..2c42d3f 100644
--- a/drivers/media/common/tuners/qt1010_priv.h
+++ b/drivers/media/common/tuners/qt1010_priv.h
@@ -99,7 +99,6 @@ struct qt1010_priv {
u8 reg25_init_val;
u32 frequency;
- u32 bandwidth;
};
#endif
--
1.7.8.352.g876a6
--
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 RFC v3 00/27] DVBv5 improvements at the drivers
This patch series were originated from Manu's changes to add support for DELSYS. It contains two parts. The first part (5 patches) adds a better way to support DVB-C Annex C, as proposed by Manu: to use a separate delivery system for Annex C. At the second part, all tuner drivers were changed to use the DVBv5 properties instead of the old DVBv3 properties that has limited support for the new delivery systems. Tuners implement a callback called set_params(), used to set the tuner properties. This struct works fine for ATSC, DVB-T/C/S, but it is not prepared for any other delivery system. This is bad, as it requires a somewhat complex logic at the dvb core in order to fake the new delivery systems in order to behave like the 4 original ones. It also requires that demod drivers for the new delivery systems to fill a wrong value at dvb_frontend_ops::info::type. On this patch series, the demods are kept untouched (well, except for one patch that renames the set_frontend callback to another name, in order to help migrating demods to the new way). What is there is a series of patches that change all tuners to work directly with the DVBv5 way. This shouldn't be a problem for applications calling via DVBv3, as the dvb core will handle the compatibility bits. As a side effect of this change, several tuners will now support DVB-T2, ISDB-T, etc, making easier to add support for those new delivery systems at the bridge drivers for the demods that support it. Please review. Regards, Mauro Manu Abraham (1): [media] DVB: Use a unique delivery system identifier for DVBC_ANNEX_C Mauro Carvalho Chehab (27): [media] Update documentation to reflect DVB-C Annex A/C support [media] Remove Annex A/C selection via roll-off factor [media] drx-k: report the supported delivery systems [media] tda10023: Don't use a magic numbers for QAM modulation [media] tda10023: add support for DVB-C Annex C [media] tda10021: Don't use a magic numbers for QAM modulation [media] tda10021: Add support for DVB-C Annex C [media] Rename set_frontend fops to set_frontend_legacy [media] dvb_core: estimate bw for all non-terrestial systems [media] qt1010: remove fake implementaion of get_bandwidth() [media] mt2060: remove fake implementaion of get_bandwidth() [media] mt2031: remove fake implementaion of get_bandwidth() [media] mc44s803: use DVBv5 parameters [media] max2165: use DVBv5 parameters [media] mt2266: use DVBv5 parameters [media] mxl5005s: use DVBv5 parameters [media] mxl5005s: fix: don't discard bandwidth changes [media] mxl5007t: use DVBv5 parameters [media] tda18218: use DVBv5 parameters [media] tda18271: add support for QAM 7 MHz map [media] tda18271-fe: use DVBv5 parameters [media] tda827x: use DVBv5 parameters [media] tuner-xc2028: use DVBv5 parameters [media] xc4000: use DVBv5 parameters [media] tuner-simple: get rid of DVBv3 params at set_params call [media] dvb-bt8xx: use DVBv5 parameters [media] dvb-pll: use DVBv5 parameters Documentation/DocBook/media/dvb/dvbproperty.xml | 11 +- Documentation/DocBook/media/dvb/frontend.xml|4 +- drivers/media/common/tuners/max2165.c | 60 ++ drivers/media/common/tuners/mc44s803.c |7 +- drivers/media/common/tuners/mt2060.c| 12 +-- drivers/media/common/tuners/mt2060_priv.h |1 - drivers/media/common/tuners/mt2131.c| 17 +--- drivers/media/common/tuners/mt2131_priv.h |1 - drivers/media/common/tuners/mt2266.c| 20 ++-- drivers/media/common/tuners/mxl5005s.c | 65 +-- drivers/media/common/tuners/mxl5007t.c | 53 - drivers/media/common/tuners/qt1010.c| 16 +-- drivers/media/common/tuners/qt1010_priv.h |1 - drivers/media/common/tuners/tda18218.c | 15 +-- drivers/media/common/tuners/tda18271-fe.c | 74 ++--- drivers/media/common/tuners/tda18271-maps.c |4 + drivers/media/common/tuners/tda18271.h |1 + drivers/media/common/tuners/tda827x.c | 49 + drivers/media/common/tuners/tuner-simple.c | 63 --- drivers/media/common/tuners/tuner-xc2028.c | 83 ++ drivers/media/common/tuners/xc4000.c| 97 +++- drivers/media/common/tuners/xc5000.c| 137 +- drivers/media/dvb/bt8xx/dst.c |8 +- drivers/media/dvb/bt8xx/dvb-bt8xx.c | 31 +++--- drivers/media/dvb/dvb-core/dvb_frontend.c | 52 - drivers/media/dvb/dvb-core/dvb_frontend.h |3 +- drivers/media/dvb/dvb-usb/af9005-fe.c |2 +- drivers/media/dvb/dvb-usb/cinergyT2-fe.c|2 +- drivers/media/dvb/dvb-usb/dtt200u-fe.c |2 +- drivers/media/dvb/dvb-usb/friio-fe.c|2 +- drivers/media/dvb/dvb-usb/gp8psk-fe.c |2 +-
[PATCH RFC v3 12/28] [media] mt2060: remove fake implementaion of get_bandwidth()
This driver implements a fake get_bandwidth() callback. In
reallity, the tuner driver won't adjust its low-pass
filter based on a bandwidth, and were just providing a fake
method for demods to read whatever was set.
This code is useless, as none of the drivers that use
this tuner seems to require a get_bandwidth() callback.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/common/tuners/mt2060.c | 12 ++--
drivers/media/common/tuners/mt2060_priv.h |1 -
2 files changed, 2 insertions(+), 11 deletions(-)
diff --git a/drivers/media/common/tuners/mt2060.c
b/drivers/media/common/tuners/mt2060.c
index 2ecaa53..6fe2ef9 100644
--- a/drivers/media/common/tuners/mt2060.c
+++ b/drivers/media/common/tuners/mt2060.c
@@ -155,6 +155,7 @@ static int mt2060_spurcheck(u32 lo1,u32 lo2,u32 if2)
static int mt2060_set_params(struct dvb_frontend *fe, struct
dvb_frontend_parameters *params)
{
+ struct dtv_frontend_properties *c = fe-dtv_property_cache;
struct mt2060_priv *priv;
int ret=0;
int i=0;
@@ -176,8 +177,7 @@ static int mt2060_set_params(struct dvb_frontend *fe,
struct dvb_frontend_parame
mt2060_writeregs(priv,b,2);
- freq = params-frequency / 1000; // Hz - kHz
- priv-bandwidth = (fe-ops.info.type == FE_OFDM) ?
params-u.ofdm.bandwidth : 0;
+ freq = c-frequency / 1000; /* Hz - kHz */
f_lo1 = freq + if1 * 1000;
f_lo1 = (f_lo1 / 250) * 250;
@@ -293,13 +293,6 @@ static int mt2060_get_frequency(struct dvb_frontend *fe,
u32 *frequency)
return 0;
}
-static int mt2060_get_bandwidth(struct dvb_frontend *fe, u32 *bandwidth)
-{
- struct mt2060_priv *priv = fe-tuner_priv;
- *bandwidth = priv-bandwidth;
- return 0;
-}
-
static int mt2060_get_if_frequency(struct dvb_frontend *fe, u32 *frequency)
{
*frequency = IF2 * 1000;
@@ -362,7 +355,6 @@ static const struct dvb_tuner_ops mt2060_tuner_ops = {
.set_params= mt2060_set_params,
.get_frequency = mt2060_get_frequency,
- .get_bandwidth = mt2060_get_bandwidth,
.get_if_frequency = mt2060_get_if_frequency,
};
diff --git a/drivers/media/common/tuners/mt2060_priv.h
b/drivers/media/common/tuners/mt2060_priv.h
index 5eaccde..2b60de6 100644
--- a/drivers/media/common/tuners/mt2060_priv.h
+++ b/drivers/media/common/tuners/mt2060_priv.h
@@ -97,7 +97,6 @@ struct mt2060_priv {
struct i2c_adapter *i2c;
u32 frequency;
- u32 bandwidth;
u16 if1_freq;
u8 fmfreq;
};
--
1.7.8.352.g876a6
--
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: [PATCHv4 1/2] v4l: Add new framesamples field to struct v4l2_mbus_framefmt
Hi Laurent, On 12/21/2011 01:20 AM, Laurent Pinchart wrote: On Wednesday 14 December 2011 13:23:07 Sylwester Nawrocki wrote: The purpose of the new field is to allow the video pipeline elements to negotiate memory buffer size for compressed data frames, where the buffer size cannot be derived from pixel width and height and the pixel code. For VIDIOC_SUBDEV_S_FMT and VIDIOC_SUBDEV_G_FMT ioctls, the framesamples parameter should be calculated by the driver from pixel width, height, color format and other parameters if required and returned to the caller. This applies to compressed data formats only. The application should propagate the framesamples value, whatever returned at the first sub-device within a data pipeline, i.e. at the pipeline's data source. For compressed data formats the host drivers should internally validate the framesamples parameter values before streaming is enabled, to make sure the memory buffer size requirements are satisfied along the pipeline. Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com ... --- a/Documentation/DocBook/media/v4l/dev-subdev.xml +++ b/Documentation/DocBook/media/v4l/dev-subdev.xml @@ -160,7 +160,13 @@ guaranteed to be supported by the device. In particular, drivers guarantee that a returned format will not be further changed if passed to an VIDIOC-SUBDEV-S-FMT; call as-is (as long as external parameters, such as - formats on other pads or links' configuration are not changed). /para + formats on other pads or links' configuration are not changed). When + a device contains a data encoder, the structfield + link linkend=v4l2-mbus-framefmt-framesamplesframesamples/link + /structfield field value may be further changed, if parameters of the + encoding process are changed after the format has been negotiated. In + such situation applications should use VIDIOC-SUBDEV-G-FMT; ioctl to + query an updated format./para Sorry for answering so late. I've been thinking about this topic (as well as the proposed new pixelclock field) quite a lot, and one question strikes me Sure, that's OK. I knew from the beginning you had your doubts about adding those new fields. here (please don't hate me): does userspace need to care about the No problem, the patch was probably good to NACK it.. ;) framesamples field ? It looks like the value is only used inside the kernel, and we're relying on on userspace to propagate those values between subdevs. It's mostly used in the kernel, yes. But I also had in mind retrieving some metadata directly from a sensor subdev, e.g. using controls. And that metadata would have relationship with maximum frame length output by the camera. But that could be handled differently, e.g. by retrieving metadata from a sensor through subdev callback and appending that to a user buffer as a separate plane. If that's the case, wouldn't it be better to have an in-kernel API to handle this ? I'm a bit concerned about forcing userspace to handle internal information to userspace if there's no reason to do so. The maximum frame length is relevant only at image source and the host (video node), hence there should not be really a need to propagate anything. The host would retrieve frame length internally from subdev. What I wanted to avoid was creating another pair of subdev callbacks that would look very similar to the pad level set_fmt/get_fmt or try/g/s_mbus_fmt operations. I've found it a bit difficult to handle VIDIOC_TRY_FMT at pipeline's final video node. By having framesamples (framelength is probably a better name) in struct v4l_mbus_framefmt the subdev has most of the information needed to calculate the framelength in one data structure and thus pad level set_fmt(TRY) can be used to ask a subdev what is framelength for given media bus pixel format. I realize this a bit cleaner in-kernel API adds complexity in user space. Which might not be worth it. But if we shouldn't have framelength in media bus format then it's even more questionable to have pixelrate there. What's the rationale between your solution, is there a need for the framesamples information in userspace ? It might be useful to control compression quality and file size trade-off directly at a sensor subdev. However this could be also done with sizeimage field at struct v4l2_pix_format. Which seems a proper way, since it's a video node that deals with memory, not a subdev. But Samsung sensors (well cameras) buffer the image data internally, mix various data (like, JPEG, YUV) in one memory plane and then send it out in one go. Thus a memory view may be also applicable for them. -- Thanks, Sylwester -- 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 v7 1/8] davinci: vpif: remove machine specific inclusion from driver
Hi Manju, On Wed, Dec 21, 2011 at 19:13:34, Hadli, Manjunath wrote: remove machine specific inclusion from the driver which comes in the way of platform code consolidation. I think it would be more readable to use the term header file here and in the headline. Just machine specific inclusion begs the question - inclusion of what? currently was seen that these header inclusions were not necessary. Sorry about nit-picking, but it is not good to talk in past tense in commit text. Past tense is natural for you to use since you write the text after making the changes, but for the reviewer it is not natural since he is seeing the commit text and the patch both at once. Also, usage of currently in above line is not necessary. It is assumed that commit text talks about current state of affairs. I would have made these changes myself after Mauro's ack, but.. Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com Cc: Mauro Carvalho Chehab mche...@infradead.org Cc: LMML linux-media@vger.kernel.org --- drivers/media/video/davinci/vpif.h |2 -- drivers/media/video/davinci/vpif_display.c |2 -- include/media/davinci/vpif_types.h |2 ++ sound/soc/codecs/cq93vc.c |2 -- .. you clubbed this unrelated sound/soc/ change in this patch. First, the change is not related to VPIF in any way so it has no business being in this patch. Second, there is no way the sound/soc folks will have a look at this patch, so basically the change will end up bypassing the right maintainers if other reviewers fail to catch it. Please separate the change into another patch. You can just post the two patches alone copying the right maintainers in each instead of posting the entire series again. Thanks, Sekhar -- 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
MEM2MEM devices: how to handle sequence number?
Hi, we have a processing chain composed of three v4l2 devices: - --- -- | v4l2 source || v4l2 fixer | | v4l2 encoder | | (capture) |--| (mem2mem)| | (mem2mem) | |___||| || v4l2 source generates consecutive sequence numbers so that we can detect whether a frame has been lost or not. v4l2 fixer and v4l2 encoder cannot lose frames because they don't interact with an external sensor. How should v4l2 fixer and v4l2 encoder behave regarding frame sequence number? Should they just copy the sequence number from the input buffer to the output buffer or should they maintain their own count for the CAPTURE queue? If the former option is chosen we should apply a patch like the following so that the sequence number of the input buffer is passed to the videobuf2 layer: diff --git a/drivers/media/video/videobuf2-core.c b/drivers/media/video/videobuf2-core.c index 1250662..7d8a88b 100644 --- a/drivers/media/video/videobuf2-core.c +++ b/drivers/media/video/videobuf2-core.c @@ -1127,6 +1127,7 @@ int vb2_qbuf(struct vb2_queue *q, struct v4l2_buffer *b) */ list_add_tail(vb-queued_entry, q-queued_list); vb-state = VB2_BUF_STATE_QUEUED; + vb-v4l2_buf.sequence = b-sequence; /* * If already streaming, give the buffer to driver for processing. Regards. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.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] media i.MX27 camera: Fix field_count handling.
To properly detect frame loss the driver must keep
track of a frame_count.
Furthermore, field_count use was erroneous because
in progressive format this must be incremented twice.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/video/mx2_camera.c |5 -
drivers/media/video/mx2_emmaprp.c | 29 ++---
2 files changed, 14 insertions(+), 20 deletions(-)
diff --git a/drivers/media/video/mx2_camera.c b/drivers/media/video/mx2_camera.c
index ea1f4dc..ca76dd2 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -255,6 +255,7 @@ struct mx2_camera_dev {
dma_addr_t discard_buffer_dma;
size_t discard_size;
struct mx2_fmt_cfg *emma_prp;
+ u32 frame_count;
};
/* buffer for one video frame */
@@ -368,6 +369,7 @@ static int mx2_camera_add_device(struct soc_camera_device
*icd)
writel(pcdev-csicr1, pcdev-base_csi + CSICR1);
pcdev-icd = icd;
+ pcdev-frame_count = 0;
dev_info(icd-parent, Camera driver attached to camera %d\n,
icd-devnum);
@@ -1211,7 +1213,8 @@ static void mx27_camera_frame_done_emma(struct
mx2_camera_dev *pcdev,
list_del(vb-queue);
vb-state = state;
do_gettimeofday(vb-ts);
- vb-field_count++;
+ vb-field_count = pcdev-frame_count * 2;
+ pcdev-frame_count++;
wake_up(vb-done);
}
diff --git a/drivers/media/video/mx2_emmaprp.c
b/drivers/media/video/mx2_emmaprp.c
index 607b73f..fb87665 100644
--- a/drivers/media/video/mx2_emmaprp.c
+++ b/drivers/media/video/mx2_emmaprp.c
@@ -16,6 +16,7 @@
* Free Software Foundation; either version 2 of the
* License, or (at your option) any later version
*/
+
#include linux/module.h
#include linux/clk.h
#include linux/slab.h
@@ -35,7 +36,7 @@ MODULE_AUTHOR(Javier Martin
javier.mar...@vista-silicon.com);
MODULE_LICENSE(GPL);
MODULE_VERSION(0.0.1);
-static bool debug;
+static bool debug = true;
module_param(debug, bool, 0644);
#define MIN_W 32
@@ -250,10 +251,11 @@ static int emmaprp_job_ready(void *priv)
{
struct emmaprp_ctx *ctx = priv;
struct emmaprp_dev *pcdev = ctx-dev;
+ struct dma_chan *chan = pcdev-dma_chan;
if ((v4l2_m2m_num_src_bufs_ready(ctx-m2m_ctx) 0)
(v4l2_m2m_num_dst_bufs_ready(ctx-m2m_ctx) 0)
-(atomic_read(pcdev-busy) == 0))
+(dma_async_memcpy_complete(chan, ctx-cookie, NULL, NULL) == 0))
return 1;
dprintk(pcdev, Task not ready to run\n);
@@ -290,10 +292,8 @@ static void emmaprp_unlock(void *priv)
static void emmaprp_dma_callback(void *data)
{
struct emmaprp_dev *pcdev = (struct emmaprp_dev *)data;
- struct dma_chan *chan = pcdev-dma_chan;
struct vb2_buffer *src_vb, *dst_vb;
struct emmaprp_ctx *curr_ctx;
- enum dma_status status;
unsigned long flags;
curr_ctx = v4l2_m2m_get_curr_priv(pcdev-m2m_dev);
@@ -306,26 +306,18 @@ static void emmaprp_dma_callback(void *data)
if (curr_ctx-aborting)
goto irq_ok;
- status = dma_async_memcpy_complete(chan, curr_ctx-cookie, NULL, NULL);
- if (status != DMA_SUCCESS) {
- v4l2_warn(pcdev-v4l2_dev,
- DMA got completion callback but status is \'%s\'\n,
- status == DMA_ERROR ? error : in progress);
- goto irq_ok;
- }
-
src_vb = v4l2_m2m_src_buf_remove(curr_ctx-m2m_ctx);
dst_vb = v4l2_m2m_dst_buf_remove(curr_ctx-m2m_ctx);
dst_vb-v4l2_buf.sequence = src_vb-v4l2_buf.sequence;
-
+printk(%s: dstbuf sequence =%d, srcbuf sequence = %d\n, __func__,
dst_vb-v4l2_buf.sequence, src_vb-v4l2_buf.sequence);
spin_lock_irqsave(pcdev-irqlock, flags);
v4l2_m2m_buf_done(src_vb, VB2_BUF_STATE_DONE);
v4l2_m2m_buf_done(dst_vb, VB2_BUF_STATE_DONE);
spin_unlock_irqrestore(pcdev-irqlock, flags);
irq_ok:
- atomic_set(pcdev-busy, 0);
v4l2_m2m_job_finish(pcdev-m2m_dev, curr_ctx-m2m_ctx);
+printk(DMA IRQ\n);
}
static void emmaprp_device_run(void *priv)
@@ -342,7 +334,6 @@ static void emmaprp_device_run(void *priv)
unsigned int d_size, s_size;
dma_addr_t p_in, p_out;
enum dma_ctrl_flags flags;
- dma_cookie_t cookie;
atomic_set(ctx-dev-busy, 1);
@@ -382,12 +373,12 @@ static void emmaprp_device_run(void *priv)
}
tx-callback = emmaprp_dma_callback;
tx-callback_param = pcdev;
- cookie = tx-tx_submit(tx);
- ctx-cookie = cookie;
- if (dma_submit_error(cookie)) {
+ ctx-cookie = tx-tx_submit(tx);
+
+ if (dma_submit_error(ctx-cookie)) {
v4l2_warn(pcdev-v4l2_dev,
DMA submit error %d with src=0x%x dst=0x%x
len=0x%x\n,
-
Re: [PATCH] media i.MX27 camera: Fix field_count handling.
Argh,
sorry, there is a file here that souldn't be included.
I'll resend it again.
On 22 December 2011 16:05, Javier Martin
javier.mar...@vista-silicon.com wrote:
To properly detect frame loss the driver must keep
track of a frame_count.
Furthermore, field_count use was erroneous because
in progressive format this must be incremented twice.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/video/mx2_camera.c | 5 -
drivers/media/video/mx2_emmaprp.c | 29 ++---
2 files changed, 14 insertions(+), 20 deletions(-)
diff --git a/drivers/media/video/mx2_camera.c
b/drivers/media/video/mx2_camera.c
index ea1f4dc..ca76dd2 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -255,6 +255,7 @@ struct mx2_camera_dev {
dma_addr_t discard_buffer_dma;
size_t discard_size;
struct mx2_fmt_cfg *emma_prp;
+ u32 frame_count;
};
/* buffer for one video frame */
@@ -368,6 +369,7 @@ static int mx2_camera_add_device(struct soc_camera_device
*icd)
writel(pcdev-csicr1, pcdev-base_csi + CSICR1);
pcdev-icd = icd;
+ pcdev-frame_count = 0;
dev_info(icd-parent, Camera driver attached to camera %d\n,
icd-devnum);
@@ -1211,7 +1213,8 @@ static void mx27_camera_frame_done_emma(struct
mx2_camera_dev *pcdev,
list_del(vb-queue);
vb-state = state;
do_gettimeofday(vb-ts);
- vb-field_count++;
+ vb-field_count = pcdev-frame_count * 2;
+ pcdev-frame_count++;
wake_up(vb-done);
}
diff --git a/drivers/media/video/mx2_emmaprp.c
b/drivers/media/video/mx2_emmaprp.c
index 607b73f..fb87665 100644
--- a/drivers/media/video/mx2_emmaprp.c
+++ b/drivers/media/video/mx2_emmaprp.c
@@ -16,6 +16,7 @@
* Free Software Foundation; either version 2 of the
* License, or (at your option) any later version
*/
+
#include linux/module.h
#include linux/clk.h
#include linux/slab.h
@@ -35,7 +36,7 @@ MODULE_AUTHOR(Javier Martin
javier.mar...@vista-silicon.com);
MODULE_LICENSE(GPL);
MODULE_VERSION(0.0.1);
-static bool debug;
+static bool debug = true;
module_param(debug, bool, 0644);
#define MIN_W 32
@@ -250,10 +251,11 @@ static int emmaprp_job_ready(void *priv)
{
struct emmaprp_ctx *ctx = priv;
struct emmaprp_dev *pcdev = ctx-dev;
+ struct dma_chan *chan = pcdev-dma_chan;
if ((v4l2_m2m_num_src_bufs_ready(ctx-m2m_ctx) 0)
(v4l2_m2m_num_dst_bufs_ready(ctx-m2m_ctx) 0)
- (atomic_read(pcdev-busy) == 0))
+ (dma_async_memcpy_complete(chan, ctx-cookie, NULL, NULL) ==
0))
return 1;
dprintk(pcdev, Task not ready to run\n);
@@ -290,10 +292,8 @@ static void emmaprp_unlock(void *priv)
static void emmaprp_dma_callback(void *data)
{
struct emmaprp_dev *pcdev = (struct emmaprp_dev *)data;
- struct dma_chan *chan = pcdev-dma_chan;
struct vb2_buffer *src_vb, *dst_vb;
struct emmaprp_ctx *curr_ctx;
- enum dma_status status;
unsigned long flags;
curr_ctx = v4l2_m2m_get_curr_priv(pcdev-m2m_dev);
@@ -306,26 +306,18 @@ static void emmaprp_dma_callback(void *data)
if (curr_ctx-aborting)
goto irq_ok;
- status = dma_async_memcpy_complete(chan, curr_ctx-cookie, NULL,
NULL);
- if (status != DMA_SUCCESS) {
- v4l2_warn(pcdev-v4l2_dev,
- DMA got completion callback but status is
\'%s\'\n,
- status == DMA_ERROR ? error : in progress);
- goto irq_ok;
- }
-
src_vb = v4l2_m2m_src_buf_remove(curr_ctx-m2m_ctx);
dst_vb = v4l2_m2m_dst_buf_remove(curr_ctx-m2m_ctx);
dst_vb-v4l2_buf.sequence = src_vb-v4l2_buf.sequence;
-
+printk(%s: dstbuf sequence =%d, srcbuf sequence = %d\n, __func__,
dst_vb-v4l2_buf.sequence, src_vb-v4l2_buf.sequence);
spin_lock_irqsave(pcdev-irqlock, flags);
v4l2_m2m_buf_done(src_vb, VB2_BUF_STATE_DONE);
v4l2_m2m_buf_done(dst_vb, VB2_BUF_STATE_DONE);
spin_unlock_irqrestore(pcdev-irqlock, flags);
irq_ok:
- atomic_set(pcdev-busy, 0);
v4l2_m2m_job_finish(pcdev-m2m_dev, curr_ctx-m2m_ctx);
+printk(DMA IRQ\n);
}
static void emmaprp_device_run(void *priv)
@@ -342,7 +334,6 @@ static void emmaprp_device_run(void *priv)
unsigned int d_size, s_size;
dma_addr_t p_in, p_out;
enum dma_ctrl_flags flags;
- dma_cookie_t cookie;
atomic_set(ctx-dev-busy, 1);
@@ -382,12 +373,12 @@ static void emmaprp_device_run(void *priv)
}
tx-callback = emmaprp_dma_callback;
tx-callback_param = pcdev;
- cookie = tx-tx_submit(tx);
- ctx-cookie = cookie;
- if
[PATCH v2] media i.MX27 camera: Fix field_count handling.
To properly detect frame loss the driver must keep
track of a frame_count.
Furthermore, field_count use was erroneous because
in progressive format this must be incremented twice.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/video/mx2_camera.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/mx2_camera.c b/drivers/media/video/mx2_camera.c
index ea1f4dc..ca76dd2 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -255,6 +255,7 @@ struct mx2_camera_dev {
dma_addr_t discard_buffer_dma;
size_t discard_size;
struct mx2_fmt_cfg *emma_prp;
+ u32 frame_count;
};
/* buffer for one video frame */
@@ -368,6 +369,7 @@ static int mx2_camera_add_device(struct soc_camera_device
*icd)
writel(pcdev-csicr1, pcdev-base_csi + CSICR1);
pcdev-icd = icd;
+ pcdev-frame_count = 0;
dev_info(icd-parent, Camera driver attached to camera %d\n,
icd-devnum);
@@ -1211,7 +1213,8 @@ static void mx27_camera_frame_done_emma(struct
mx2_camera_dev *pcdev,
list_del(vb-queue);
vb-state = state;
do_gettimeofday(vb-ts);
- vb-field_count++;
+ vb-field_count = pcdev-frame_count * 2;
+ pcdev-frame_count++;
wake_up(vb-done);
}
--
1.7.0.4
--
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: which is correct name DTMB or CTTB?
On 12/21/2011 11:53 AM, Antti Palosaari wrote: I am adding DTMB/CTTB support for the Linux Kernel DVB API. Do anyone have clear idea which correct name? Background of that discussion can be found from the following patch: http://patchwork.linuxtv.org/patch/8827/ There is already defined delivery system SYS_DMBTH. It have been from the time S2API was introduced coming from the patch: 6b73eeafbc856c0cef7166242f0e55403407f355 include/linux/dvb/frontend.h Should I change that name? Or introduce new names using define? Or just leave it as it is. No single driver is using that because all existing DTMB/CTTB/DMB-TH drivers are abusing DVB-T... I still think it is rather safe to change better one, there is likely no user space apps using that yet... 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: Add tuner_type to zl10353 config and use it for reporting signal directly from tuner.
On 12/21/2011 11:07 PM, Miroslav Slugeň wrote: XC4000 based cards are not using AGC control in normal way, so it is not possible to get signal level from AGC registres of zl10353 demodulator, instead of this i send previous patch to implement signal level directly in xc4000 tuner and now sending patch for zl10353 to implement this future for digital mode. Signal reporting is very accurate and was well tested on 3 different Leadtek XC4000 cards. I don't like that patch at all. My opinion is that you should put hacks like to the interface driver. Override demod .read_signal_strength() callback and route it to the tuner callback. No any changes for the demod driver should be done. Estimation of the signal strength is a little bit hard when looking demod point of view. Demod gets IF as input signal and thus have mainly idea of IF AGC values. Estimating RF strength is thus very inaccurate from the IF AGC gain. And those IF AGC values are tuner/demod combination dependent too. Sometimes there is also RF AGC available for the demod. With both IF and RF AGC you could estimate more better - but still very inaccurate. 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
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:Thu Dec 22 19:00:21 CET 2011 git hash:875e2e3edf48a206c64195666cf408dd3d119137 gcc version: i686-linux-gcc (GCC) 4.6.1 host hardware:x86_64 host os: 3.1-2.slh.1-amd64 linux-git-arm-eabi-enoxys: ERRORS linux-git-arm-eabi-omap: ERRORS linux-git-armv5-ixp: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2-rc1-i686: WARNINGS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2-rc1-x86_64: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.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: which is correct name DTMB or CTTB?
On 22-12-2011 14:45, Antti Palosaari wrote: On 12/21/2011 11:53 AM, Antti Palosaari wrote: I am adding DTMB/CTTB support for the Linux Kernel DVB API. Do anyone have clear idea which correct name? Background of that discussion can be found from the following patch: http://patchwork.linuxtv.org/patch/8827/ There is already defined delivery system SYS_DMBTH. It have been from the time S2API was introduced coming from the patch: 6b73eeafbc856c0cef7166242f0e55403407f355 include/linux/dvb/frontend.h Should I change that name? Or introduce new names using define? Or just leave it as it is. No single driver is using that because all existing DTMB/CTTB/DMB-TH drivers are abusing DVB-T... I still think it is rather safe to change better one, there is likely no user space apps using that yet... Feel free to change it, as nobody is using it yet. In a matter of fact, I wrote today one patch using it, but I'll rebase my patch to the name you define. regards Antti -- 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] tm6000 : improve loading speed on hauppauge 900H
- enable fast usb quirk
- use usleep_range instead on msleep for short sleep
- merge i2c out and usb delay
- do like the windows driver that upload the tuner firmware with 80 bytes
packets
Signed-off-by: Matthieu CASTET castet.matth...@free.fr
CC: Thierry Reding thierry.red...@avionic-design.de
---
drivers/media/video/tm6000/tm6000-cards.c |2 ++
drivers/media/video/tm6000/tm6000-core.c | 16 ++--
drivers/media/video/tm6000/tm6000-i2c.c |8 +---
3 files changed, 17 insertions(+), 9 deletions(-)
diff --git a/drivers/media/video/tm6000/tm6000-cards.c
b/drivers/media/video/tm6000/tm6000-cards.c
index 6b74259..3678918 100644
--- a/drivers/media/video/tm6000/tm6000-cards.c
+++ b/drivers/media/video/tm6000/tm6000-cards.c
@@ -943,6 +943,7 @@ static void tm6000_config_tuner(struct tm6000_core *dev)
case TM6010_BOARD_HAUPPAUGE_900H:
case TM6010_BOARD_TERRATEC_CINERGY_HYBRID_XE:
case TM6010_BOARD_TWINHAN_TU501:
+ ctl.max_len = 80;
ctl.fname = xc3028L-v36.fw;
break;
default:
@@ -1004,6 +1005,7 @@ static int fill_board_specific_data(struct tm6000_core
*dev)
/* setup per-model quirks */
switch (dev-model) {
case TM6010_BOARD_TERRATEC_CINERGY_HYBRID_XE:
+ case TM6010_BOARD_HAUPPAUGE_900H:
dev-quirks |= TM6000_QUIRK_NO_USB_DELAY;
break;
diff --git a/drivers/media/video/tm6000/tm6000-core.c
b/drivers/media/video/tm6000/tm6000-core.c
index 979c85b..22cc011 100644
--- a/drivers/media/video/tm6000/tm6000-core.c
+++ b/drivers/media/video/tm6000/tm6000-core.c
@@ -38,6 +38,7 @@ int tm6000_read_write_usb(struct tm6000_core *dev, u8
req_type, u8 req,
int ret, i;
unsigned int pipe;
u8 *data = NULL;
+ int delay = 5000;
mutex_lock(dev-usb_lock);
@@ -89,8 +90,19 @@ int tm6000_read_write_usb(struct tm6000_core *dev, u8
req_type, u8 req,
kfree(data);
- if ((dev-quirks TM6000_QUIRK_NO_USB_DELAY) == 0)
- msleep(5);
+ if (dev-quirks TM6000_QUIRK_NO_USB_DELAY)
+ delay = 0;
+
+ if (req == REQ_16_SET_GET_I2C_WR1_RDN !(req_type USB_DIR_IN)) {
+ unsigned int tsleep;
+ /* Calculate delay time, 14000us for 64 bytes */
+ tsleep = (len * 200) + 200;
+ if (tsleep delay)
+ tsleep = delay;
+ usleep_range(tsleep, tsleep + 1000);
+ }
+ else if (delay)
+ usleep_range(delay, delay + 1000);
mutex_unlock(dev-usb_lock);
return ret;
diff --git a/drivers/media/video/tm6000/tm6000-i2c.c
b/drivers/media/video/tm6000/tm6000-i2c.c
index 0290bbf..c7e23e3 100644
--- a/drivers/media/video/tm6000/tm6000-i2c.c
+++ b/drivers/media/video/tm6000/tm6000-i2c.c
@@ -46,11 +46,10 @@ static int tm6000_i2c_send_regs(struct tm6000_core *dev,
unsigned char addr,
__u8 reg, char *buf, int len)
{
int rc;
- unsigned int tsleep;
unsigned int i2c_packet_limit = 16;
if (dev-dev_type == TM6010)
- i2c_packet_limit = 64;
+ i2c_packet_limit = 80;
if (!buf)
return -1;
@@ -71,10 +70,6 @@ static int tm6000_i2c_send_regs(struct tm6000_core *dev,
unsigned char addr,
return rc;
}
- /* Calculate delay time, 14000us for 64 bytes */
- tsleep = ((len * 200) + 200 + 1000) / 1000;
- msleep(tsleep);
-
/* release mutex */
return rc;
}
@@ -145,7 +140,6 @@ static int tm6000_i2c_recv_regs16(struct tm6000_core *dev,
unsigned char addr,
return rc;
}
- msleep(1400 / 1000);
rc = tm6000_read_write_usb(dev, USB_DIR_IN | USB_TYPE_VENDOR |
USB_RECIP_DEVICE, REQ_35_AFTEK_TUNER_READ,
reg, 0, buf, len);
--
1.7.5.4
--
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: which is correct name DTMB or CTTB?
On 22-12-2011 17:56, Mauro Carvalho Chehab wrote:
On 22-12-2011 14:45, Antti Palosaari wrote:
On 12/21/2011 11:53 AM, Antti Palosaari wrote:
I am adding DTMB/CTTB support for the Linux Kernel DVB API. Do anyone
have clear idea which correct name?
Background of that discussion can be found from the following patch:
http://patchwork.linuxtv.org/patch/8827/
There is already defined delivery system SYS_DMBTH. It have been from the
time S2API was introduced coming from the patch:
6b73eeafbc856c0cef7166242f0e55403407f355
include/linux/dvb/frontend.h
Should I change that name? Or introduce new names using define? Or just
leave it as it is. No single driver is using that because all existing
DTMB/CTTB/DMB-TH drivers are abusing DVB-T...
I still think it is rather safe to change better one, there is likely no
user space apps using that yet...
Feel free to change it, as nobody is using it yet.
In a matter of fact, I wrote today one patch using it, but I'll rebase my
patch to
the name you define.
FYI, I'm enclosing the patch I wrote for a CTTB driver. The Idea is that,
while such drivers are lying to DVBv3 calls, they'll tell the true delivery
system, and properly honor get_frontend/set_frontend for
FE_GET_PROPERTY/FE_SETPROPERTY ioctl calls.
I'll be submitting it together with a series of patches converting the demods
to use struct dtv_frontend_properties instead of struct dvb_frontend_parameters.
This patch depends on some patches on my experimental tree:
http://git.linuxtv.org/mchehab/experimental.git/shortlog/refs/heads/DVB_v5_v2
Please, don't base any of your patches on that tree yet. There are about
70 drivers pending conversion. Only after converting everything I'll send
a RFC, and test with a few devices I have with me.
I'll likely need to rebase it a few times, in order to be sure that all
tuner drivers are converted before the demods, as I'm doing, this change,
at demod drivers I'm converting:
- fe-ops.tuner_ops.set_params(fe, params);
+ fe-ops.tuner_ops.set_params(fe, NULL);
The final step will be to remove the now legacy params argument, but
there are still a few tuners not converted (the ones that aren't at
drivers/media/common/tuners).
Regards,
Mauro
-
[PATCH] [media] atbm8830: convert set_fontend to new way and fix delivery system
This is one of the cases where the frontend changes is required:
while this device lies to applications that it is a DVB-T, it is,
in fact, a frontend for CTTB delivery system. So, the information
provided for a DVBv3 application should be different than the one
provided to a DVBv5 application.
So, fill delsys with the CTTB delivery system, and use the new
way. there aren't many changes here, as everything on this driver
is on auto mode, probably because of the lack of a proper API
for this delivery system.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/media/dvb/frontends/atbm8830.c
b/drivers/media/dvb/frontends/atbm8830.c
index e6114b4..ee69509 100644
--- a/drivers/media/dvb/frontends/atbm8830.c
+++ b/drivers/media/dvb/frontends/atbm8830.c
@@ -267,8 +267,7 @@ static void atbm8830_release(struct dvb_frontend *fe)
kfree(state);
}
-static int atbm8830_set_fe(struct dvb_frontend *fe,
- struct dvb_frontend_parameters *fe_params)
+static int atbm8830_set_fe(struct dvb_frontend *fe)
{
struct atbm_state *priv = fe-demodulator_priv;
int i;
@@ -279,7 +278,7 @@ static int atbm8830_set_fe(struct dvb_frontend *fe,
if (fe-ops.tuner_ops.set_params) {
if (fe-ops.i2c_gate_ctrl)
fe-ops.i2c_gate_ctrl(fe, 1);
- fe-ops.tuner_ops.set_params(fe, fe_params);
+ fe-ops.tuner_ops.set_params(fe, NULL);
if (fe-ops.i2c_gate_ctrl)
fe-ops.i2c_gate_ctrl(fe, 0);
}
@@ -298,31 +297,32 @@ static int atbm8830_set_fe(struct dvb_frontend *fe,
return 0;
}
-static int atbm8830_get_fe(struct dvb_frontend *fe,
- struct dvb_frontend_parameters *fe_params)
+static int atbm8830_get_fe(struct dvb_frontend *fe)
{
+ struct dtv_frontend_properties *c = fe-dtv_property_cache;
+
dprintk(%s\n, __func__);
/* TODO: get real readings from device */
/* inversion status */
- fe_params-inversion = INVERSION_OFF;
+ c-inversion = INVERSION_OFF;
/* bandwidth */
- fe_params-u.ofdm.bandwidth = BANDWIDTH_8_MHZ;
+ c-bandwidth_hz = 800;
- fe_params-u.ofdm.code_rate_HP = FEC_AUTO;
- fe_params-u.ofdm.code_rate_LP = FEC_AUTO;
+ c-code_rate_HP = FEC_AUTO;
+ c-code_rate_LP = FEC_AUTO;
- fe_params-u.ofdm.constellation = QAM_AUTO;
+ c-modulation = QAM_AUTO;
/* transmission mode */
- fe_params-u.ofdm.transmission_mode = TRANSMISSION_MODE_AUTO;
+ c-transmission_mode = TRANSMISSION_MODE_AUTO;
[RFCv1] add DTMB support for DVB API
1. I renamed it to the DTMB. I looked very many research papers and CTTB was very, very rare. DTMB seems to exists almost all documents even very recent. 2. added new values needed for the existing parameters. 3. new parameter u32 interleaving DTMB supports 240 and 720 interleavers. I added interleaving as a general parameter instead of DTMB, since there could be likely be some other modulations too that have same param. Actually ISDB-T already have. Let the 0 be AUTO or N/A. 4. new parameter u32 carrier DTMB supports two sub-carrier modes. 1, single carrier, or 3780, which is called multi-carrier. Same reasons applies here as for the interleaving. Antti Palosaari (1): add DTMB support for DVB API drivers/media/dvb/dvb-core/dvb_frontend.c | 19 ++- drivers/media/dvb/dvb-core/dvb_frontend.h |3 +++ include/linux/dvb/frontend.h | 13 +++-- include/linux/dvb/version.h |2 +- 4 files changed, 33 insertions(+), 4 deletions(-) -- 1.7.4.4 --- -- 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
[RFCv1] add DTMB support for DVB API
Rename DMB-TH to DTMB.
Add few new values for existing parameters.
Add two new parameters, interleaving and carrier.
DTMB supports interleavers: 240 and 720.
DTMB supports carriers: 1 and 3780.
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/dvb/dvb-core/dvb_frontend.c | 19 ++-
drivers/media/dvb/dvb-core/dvb_frontend.h |3 +++
include/linux/dvb/frontend.h | 13 +++--
include/linux/dvb/version.h |2 +-
4 files changed, 33 insertions(+), 4 deletions(-)
diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c
b/drivers/media/dvb/dvb-core/dvb_frontend.c
index 821b225..ec2cbae 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -924,6 +924,8 @@ static struct dtv_cmds_h dtv_cmds[DTV_MAX_COMMAND +
1] = {
_DTV_CMD(DTV_CODE_RATE_LP, 1, 0),
_DTV_CMD(DTV_GUARD_INTERVAL, 1, 0),
_DTV_CMD(DTV_TRANSMISSION_MODE, 1, 0),
+ _DTV_CMD(DTV_CARRIER, 1, 0),
+ _DTV_CMD(DTV_INTERLEAVING, 1, 0),
_DTV_CMD(DTV_ISDBT_PARTIAL_RECEPTION, 1, 0),
_DTV_CMD(DTV_ISDBT_SOUND_BROADCASTING, 1, 0),
@@ -974,6 +976,8 @@ static struct dtv_cmds_h dtv_cmds[DTV_MAX_COMMAND +
1] = {
_DTV_CMD(DTV_GUARD_INTERVAL, 0, 0),
_DTV_CMD(DTV_TRANSMISSION_MODE, 0, 0),
_DTV_CMD(DTV_HIERARCHY, 0, 0),
+ _DTV_CMD(DTV_CARRIER, 0, 0),
+ _DTV_CMD(DTV_INTERLEAVING, 0, 0),
_DTV_CMD(DTV_ENUM_DELSYS, 0, 0),
};
@@ -1162,7 +1166,8 @@ static void dtv_property_adv_params_sync(struct
dvb_frontend *fe)
/* Fake out a generic DVB-T request so we pass validation in the ioctl
*/
if ((c-delivery_system == SYS_ISDBT) ||
- (c-delivery_system == SYS_DVBT2)) {
+ (c-delivery_system == SYS_DVBT2) ||
+ (c-delivery_system == SYS_DTMB)) {
p-u.ofdm.constellation = QAM_AUTO;
p-u.ofdm.code_rate_HP = FEC_AUTO;
p-u.ofdm.code_rate_LP = FEC_AUTO;
@@ -1378,6 +1383,12 @@ static int dtv_property_process_get(struct
dvb_frontend *fe,
case DTV_DVBT2_PLP_ID:
tvp-u.data = c-dvbt2_plp_id;
break;
+ case DTV_CARRIER:
+ tvp-u.data = c-carrier;
+ break;
+ case DTV_INTERLEAVING:
+ tvp-u.data = c-interleaving;
+ break;
default:
return -EINVAL;
}
@@ -1544,6 +1555,12 @@ static int dtv_property_process_set(struct
dvb_frontend *fe,
case DTV_DVBT2_PLP_ID:
c-dvbt2_plp_id = tvp-u.data;
break;
+ case DTV_CARRIER:
+ c-carrier = tvp-u.data;
+ break;
+ case DTV_INTERLEAVING:
+ c-interleaving = tvp-u.data;
+ break;
default:
return -EINVAL;
}
diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.h
b/drivers/media/dvb/dvb-core/dvb_frontend.h
index 67bbfa7..4979ffc 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.h
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.h
@@ -343,6 +343,9 @@ struct dtv_frontend_properties {
fe_delivery_system_tdelivery_system;
+ u32 interleaving;
+ u32 carrier;
+
/* ISDB-T specifics */
u8 isdbt_partial_reception;
u8 isdbt_sb_mode;
diff --git a/include/linux/dvb/frontend.h b/include/linux/dvb/frontend.h
index cb114f5..2fa3bc5 100644
--- a/include/linux/dvb/frontend.h
+++ b/include/linux/dvb/frontend.h
@@ -152,6 +152,7 @@ typedef enum fe_code_rate {
FEC_AUTO,
FEC_3_5,
FEC_9_10,
+ FEC_2_5,
} fe_code_rate_t;
@@ -169,8 +170,11 @@ typedef enum fe_modulation {
APSK_16,
APSK_32,
DQPSK,
+ QAM_4_NR,
} fe_modulation_t;
+#define QAM_4 QPSK
+
typedef enum fe_transmit_mode {
TRANSMISSION_MODE_2K,
TRANSMISSION_MODE_8K,
@@ -201,6 +205,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;
@@ -317,8 +324,10 @@ struct dvb_frontend_event {
#define DTV_DVBT2_PLP_ID 43
#define DTV_ENUM_DELSYS44
+#define DTV_INTERLEAVING 45
+#define DTV_CARRIER46
-#define DTV_MAX_COMMANDDTV_ENUM_DELSYS
+#define DTV_MAX_COMMANDDTV_CARRIER
typedef enum fe_pilot {
PILOT_ON,
@@ -349,7 +358,7 @@ typedef enum fe_delivery_system {
SYS_ISDBC,
SYS_ATSC,
SYS_ATSCMH,
- SYS_DMBTH,
+ SYS_DTMB,
SYS_CMMB,
SYS_DAB,
SYS_DVBT2,
diff --git a/include/linux/dvb/version.h b/include/linux/dvb/version.h
index 0559e2b..43d9e8d 100644
--- a/include/linux/dvb/version.h
+++
Re: cx88: all radio tuners using xc2028 or xc4000 tuner and radio should have radio_type UNSET
Thanks Miroslav, your patches fixed the problems with my leadtek 1800H card. Radio now works again and tunes to the correct frequency. On 17/12/2011 11:55 AM, Miroslav Slugeň wrote: Fix radio for cx88 driver. -- 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: Leadtek Winfast 1800H FM Tuner
This has now been fixed after applying patches by Miroslav Slugen. On 18/04/2011 10:15 PM, Andrew Goff wrote: On 23/03/2011 7:56 PM, Mauro Carvalho Chehab wrote: Em 22-03-2011 08:54, Andrew Goff escreveu: On Tue, Mar 22, 2011 at 8:09 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Em 21-03-2011 17:46, Andrew Goff escreveu: On Tue 22-Mar-2011 4:44 AM, Mauro Carvalho Chehab wrote: Em 21-03-2011 08:35, Andrew Goff escreveu: On Mon 21-Mar-2011 9:21 PM, Mauro Carvalho Chehab wrote: Em 20-03-2011 05:18, Antti Palosaari escreveu: On 03/20/2011 02:56 AM, Andrew Goff wrote: Hi, I hope someone may be able to help me solve a problem or point me in the right direction. I have been using a Leadtek Winfast DTV1800H card (Xceive xc3028 tuner) for a while now without any issues (DTV Radio have been working well), I recently decided to get another tuner card, Leadtek Winfast DTV2000DS (Tuner: NXP TDA18211, but detected as TDA18271 by V4L drivers, Chipset: AF9015 + AF9013 ) and had to compile and install the V4L drivers to get it working. Now DTV on both cards work well but there is a problem with the radio tuner on the 1800H card. After installing the more recent V4L drivers the radio frequency is 2.7MHz out, so if I want to listen to 104.9 I need to tune the radio to 107.6. Now I could just change all my preset stations but I can not listen to my preferred stations as I need to set the frequency above 108MHz. I think there is something wrong with the FM tuner (xc3028?) or other chipset drivers used for DTV1800H. No relations to the af9015, af9013 or tda18271. tda18211 is same chip as tda18271 but only DVB-T included. If DTV1800H does not contain tda18211 or tda18271 problem cannot be either that. Yes, the problem is likely at xc3028. It has to do frequency shift for some DVB standards, and the shift is dependent on what firmware is loaded. So, you need to enable load tuner-xc2028 with debug=1, and provide us the dmesg. Mauro. Hi Mauro To do this do I just add the line options tuner-xc2028 debug=1 to the /etc/modules file. From my current dmesg file looks like the firmware is version 2.7. xc2028 1-0061: Loading 80 firmware images from xc3028-v27.fw, type: xc2028 firmware, ver 2.7 There are about 60 firmwares that are grouped inside xc3028-v27.fw. Please post the complete dmesg. We also need to know what version of the driver you were using when the driver used to work and what you're using when it broke. Thanks Mauro. Mauro, please see dmesg attached, note I have not added debug=1 yet, do I still need to do this. To get the other card working I installed this driver version http://linuxtv.org/hg/v4l-dvb/rev/abd3aac6644e The mercurial tree is there just due to historic reasons. It has _obsolete_ stuff and nobody is updating it. Please use, instead, the media_build.git (see linuxtv.org wiki). the dmesg with the debug=1 is required, otherwise, it won't produce any error about what's happening at the xc3028 driver. Mauro. HI Mauro, now using media_build.git and followed the instructions from http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers have added options tuner-xc2028 debug=1 to the /etc/modules , please see attached dmesg FM tuner has now completely stopped working. Weird: [ 36.654409] xc2028 1-0061: creating new instance [ 36.654414] xc2028 1-0061: type set to XCeive xc2028/xc3028 tuner [ 36.654419] xc2028 1-0061: destroying instance [ 36.654489] xc2028 1-0061: creating new instance [ 36.654491] xc2028 1-0061: type set to XCeive xc2028/xc3028 tuner [ 36.654494] cx88[0]: Asking xc2028/3028 to load firmware xc3028-v27.fw [ 36.745247] cx88_audio :01:06.1: firmware: requesting xc3028-v27.fw [ 36.817868] xc2028 1-0061: Loading 80 firmware images from xc3028-v27.fw, type: xc2028 firmware, ver 2.7 [ 36.817993] cx88[0]: Calling XC2028/3028 callback [ 36.966811] xc2028 1-0061: Loading firmware for type=BASE (1), id . [ 36.966815] cx88[0]: Calling XC2028/3028 callback xc2028 driver didn't try to load a standard-specific firmware... I would expect at least two load firmware lines there... one for NTSC, and another one for one of the radio-specific firmwares, when you tried to run radio on it. Please also load tuner with debug=1. Let's see what happens when you change a frequency on your radio program. AH! Very important! V4L1 API got removed, so, you need to be sure that your radio program is using V4L2 API. I had to fix xawtv3 radio program for it to work properly using V4L2 API. So, xawtv 3.95 is broken. If you're using xawtv 3.100, radio application is working fine. We had also a report that gnome-radio upstream is broken. While it does support both API's, it seems that it fails if V4L1 is not available. There's a patch fixing it on Fedora. Not sure if other distros applied the patch, but, on a quick look, the Fedora patch didn't reach upstream: http://git.gnome.org/browse/gnomeradio/ Hmm... [ 37.381526]
Re: [PATCH v2] media i.MX27 camera: Fix field_count handling.
On Thu, 22 Dec 2011, Javier Martin wrote:
To properly detect frame loss the driver must keep
track of a frame_count.
Furthermore, field_count use was erroneous because
in progressive format this must be incremented twice.
Hm, sorry, why this? I just looked at vivi.c - the version before
videobuf2 conversion - and it seems to only increment the count by one.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/video/mx2_camera.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/mx2_camera.c
b/drivers/media/video/mx2_camera.c
index ea1f4dc..ca76dd2 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -255,6 +255,7 @@ struct mx2_camera_dev {
dma_addr_t discard_buffer_dma;
size_t discard_size;
struct mx2_fmt_cfg *emma_prp;
+ u32 frame_count;
The rule I usually follow, when choosing variable type is the following:
does it really have to be fixed bit-width? The positive reply is pretty
rare, it comes mostly if (a) the variable is used to store values read
from or written to some (fixed-width) hardware registers, or (b) the
variable belongs to a fixed ABI, that has to be the same on different
(32-bit, 64-bit) systems, like (arguably) ioctl()s, data, transferred over
the network or stored on a medium (filesystems,...). This doesn't seem to
be the case here, so, I would just use an (unsigned) int.
Thanks
Guennadi
};
/* buffer for one video frame */
@@ -368,6 +369,7 @@ static int mx2_camera_add_device(struct soc_camera_device
*icd)
writel(pcdev-csicr1, pcdev-base_csi + CSICR1);
pcdev-icd = icd;
+ pcdev-frame_count = 0;
dev_info(icd-parent, Camera driver attached to camera %d\n,
icd-devnum);
@@ -1211,7 +1213,8 @@ static void mx27_camera_frame_done_emma(struct
mx2_camera_dev *pcdev,
list_del(vb-queue);
vb-state = state;
do_gettimeofday(vb-ts);
- vb-field_count++;
+ vb-field_count = pcdev-frame_count * 2;
+ pcdev-frame_count++;
wake_up(vb-done);
}
--
1.7.0.4
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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 i.MX27 camera: add support for YUV420 format.
Hi Javier On Thu, 22 Dec 2011, javier Martin wrote: Hi, are there any comments on this? May I suppose you agree and it will be applied? Yes, I've applied it to my 3.3 outgoing branch and will push it out soon. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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
Read DVB signal information directly from xc4000 based tuners
For xc4000 based tuners we can read signal directly from tuner even for demodulator. This is updated patch of id 8933. This patch depends on id 8926 (Add signal information to xc4000 tuner). -- 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: Read DVB signal information directly from xc4000 based tuners
For xc4000 based tuners we can read signal directly from tuner even
for demodulator. This is updated patch of id 8933. This patch depends
on id 8926 (Add signal information to xc4000 tuner).
From 4e51d66e51e54983b38ea556c370a7bf3dd5e273 Mon Sep 17 00:00:00 2001
From: Miroslav thunde...@email.cz
Date: Fri, 23 Dec 2011 00:35:15 +0100
Subject: [PATCH] Read DVB signal information directly from xc4000 based tuners.
---
drivers/media/video/cx23885/cx23885-dvb.c |3 +++
drivers/media/video/cx88/cx88-dvb.c |3 +++
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/cx23885/cx23885-dvb.c b/drivers/media/video/cx23885/cx23885-dvb.c
index f0482b2..7198072 100644
--- a/drivers/media/video/cx23885/cx23885-dvb.c
+++ b/drivers/media/video/cx23885/cx23885-dvb.c
@@ -945,6 +945,9 @@ static int dvb_register(struct cx23885_tsport *port)
dev-name);
goto frontend_detach;
}
+
+ /* read signal directly from tuner */
+ fe-ops.read_signal_strength = fe-ops.tuner_ops.get_rf_strength;
}
break;
case CX23885_BOARD_TBS_6920:
diff --git a/drivers/media/video/cx88/cx88-dvb.c b/drivers/media/video/cx88/cx88-dvb.c
index 592f3aa..c023a6c 100644
--- a/drivers/media/video/cx88/cx88-dvb.c
+++ b/drivers/media/video/cx88/cx88-dvb.c
@@ -635,6 +635,9 @@ static int attach_xc4000(struct cx8802_dev *dev, struct xc4000_config *cfg)
return -EINVAL;
}
+ /* read signal directly from xc4000 tuner */
+ fe-ops.read_signal_strength = fe-ops.tuner_ops.get_rf_strength;
+
printk(KERN_INFO %s/2: xc4000 attached\n, dev-core-name);
return 0;
--
1.7.2.3
Re: Add support for new Terratec DVB USB IDs
Hi,
Eduard Bloch wrote[1]:
current revision of the Cinergy S2 USB box from Terratec seems to use
another USB-IDs. The manufacturer provides patches at
http://linux.terratec.de/tv_en.html and it seems like the only
difference is really just the new ID and a couple of init flag changes.
Their patch is not exactly for the linux-3.x tree but for the current
s2-liplianin drivers, OTOH they still look similar enough and porting
the patch was straight-forward. I also added the patch for Terratec S7
which is not tested yet but shouldn't do any harm.
[...]
Eduard, meet the LinuxTV project. linux-media folks, meet Eduard.
Patch follows.
Eduard: may we have your sign-off? Please see
Documentation/SubmittingPatches, section 12 Sign your work for what
this means.
My only other hint is that it would be better to add the new device
IDs in some logical place in the list near the older ones, instead of
at the end where it is more likely to collide with other patches in
flight. So if rerolling the patches, it might be useful to do that.
-- 8 --
From: Eduard Bloch bl...@debian.org
Date: Thu, 22 Dec 2011 19:46:54 +0100
Subject: new device IDs used by some Terratec USB devices
The changes are extracted from ID patches in tarballs at
http://linux.terratec.de/tv_en.html (for S7 and Cinergy S2 USB HD), and
slightly modified to match the state of s2-liplianin tree used in linux-3.x so
far.
---
Thanks for your work,
Jonathan
[1] http://bugs.debian.org/653026
diff -urd linux-2.6-3.1.5.debian/drivers/media/dvb/dvb-usb/az6027.c
linux-2.6-3.1.5/drivers/media/dvb/dvb-usb/az6027.c
--- linux-2.6-3.1.5.debian/drivers/media/dvb/dvb-usb/az6027.c 2011-12-09
17:57:05.0 +0100
+++ linux-2.6-3.1.5/drivers/media/dvb/dvb-usb/az6027.c 2011-12-22
19:42:25.655675023 +0100
@@ -1090,6 +1090,7 @@
{ USB_DEVICE(USB_VID_TECHNISAT, USB_PID_TECHNISAT_USB2_HDCI_V1) },
{ USB_DEVICE(USB_VID_TECHNISAT, USB_PID_TECHNISAT_USB2_HDCI_V2) },
{ USB_DEVICE(USB_VID_ELGATO, USB_PID_ELGATO_EYETV_SAT) },
+ { USB_DEVICE(USB_VID_TERRATEC, USB_PID_TERRATEC_DVBS2CI_V3) },
{ },
};
@@ -1135,7 +1136,7 @@
.i2c_algo = az6027_i2c_algo,
- .num_device_descs = 6,
+ .num_device_descs = 7,
.devices = {
{
.name = AZUREWAVE DVB-S/S2 USB2.0 (AZ6027),
@@ -1161,6 +1162,10 @@
.name = Elgato EyeTV Sat,
.cold_ids = { az6027_usb_table[5], NULL },
.warm_ids = { NULL },
+ }, {
+ .name = TERRATEC S7 Rev.3,
+ .cold_ids = { az6027_usb_table[6], NULL },
+ .warm_ids = { NULL },
},
{ NULL },
}
diff -urd linux-2.6-3.1.5.debian/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
linux-2.6-3.1.5/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
--- linux-2.6-3.1.5.debian/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
2011-12-09 17:57:05.0 +0100
+++ linux-2.6-3.1.5/drivers/media/dvb/dvb-usb/dvb-usb-ids.h 2011-12-22
19:40:02.208934727 +0100
@@ -319,6 +319,7 @@
#define USB_PID_AZUREWAVE_AZ6027 0x3275
#define USB_PID_TERRATEC_DVBS2CI_V10x10a4
#define USB_PID_TERRATEC_DVBS2CI_V20x10ac
+#define USB_PID_TERRATEC_DVBS2CI_V30x10b0
#define USB_PID_TECHNISAT_USB2_HDCI_V1 0x0001
#define USB_PID_TECHNISAT_USB2_HDCI_V2 0x0002
#define USB_PID_TECHNISAT_AIRSTAR_TELESTICK_2 0x0004
diff -urd linux-2.6-3.1.5.debian/drivers/media/dvb/dvb-usb/dw2102.c
linux-2.6-3.1.5/drivers/media/dvb/dvb-usb/dw2102.c
--- linux-2.6-3.1.5.debian/drivers/media/dvb/dvb-usb/dw2102.c 2011-12-09
17:57:05.0 +0100
+++ linux-2.6-3.1.5/drivers/media/dvb/dvb-usb/dw2102.c 2011-12-22
19:43:16.588387654 +0100
@@ -1181,6 +1181,14 @@
{
u8 obuf[3] = { 0xe, 0x80, 0 };
u8 ibuf[] = { 0 };
+
+ if (dvb_usb_generic_rw(d-dev, obuf, 3, ibuf, 1, 0) 0)
+ err(command 0x0e transfer failed.);
+
+ //power on su3000
+ obuf[0] = 0xe;
+ obuf[1] = 0x02;
+ obuf[2] = 1;
if (dvb_usb_generic_rw(d-dev, obuf, 3, ibuf, 1, 0) 0)
err(command 0x0e transfer failed.);
@@ -1451,6 +1459,7 @@
{USB_DEVICE(0x9022, USB_PID_TEVII_S480_1)},
{USB_DEVICE(0x9022, USB_PID_TEVII_S480_2)},
{USB_DEVICE(0x1f4d, 0x3100)},
+ {USB_DEVICE(USB_VID_TERRATEC, 0x00b0)},
{ }
};
@@ -1824,7 +1833,7 @@
}
}
},
- .num_device_descs = 3,
+ .num_device_descs = 4,
.devices = {
{ SU3000HD DVB-S USB2.0,
{ dw2102_table[10], NULL },
@@ -1838,6 +1847,10 @@
{ dw2102_table[14], NULL },
{ NULL },
},
+ { Terratec Cinergy S2 USB HD Rev.2,
+
Re: Add tuner_type to zl10353 config and use it for reporting signal directly from tuner.
This patch is wrong, please use 8971 instead. -- 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] [RFC v3 0/2] Introduce DMA buffer sharing mechanism
On Wed, Dec 21, 2011 at 3:56 AM, Rob Clark r...@ti.com wrote: On Tue, Dec 20, 2011 at 2:20 PM, Dave Airlie airl...@gmail.com wrote: snip I think this is a really good v1 version of dma_buf. It contains all the required bits (with well-specified semantics in the doc patch) to implement some basic use-cases and start fleshing out the integration with various subsystem (like drm and v4l). All the things still under discussion like - userspace mmap support - more advanced (and more strictly specified) coherency models - and shared infrastructure for implementing exporters are imo much clearer once we have a few example drivers at hand and a better understanding of some of the insane corner cases we need to be able to handle. And I think any risk that the resulting clarifications will break a basic use-case is really minimal, so I think it'd be great if this could go into 3.3 (maybe as some kind of staging/experimental infrastructure). Hence for both patches: Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch Yeah I'm with Daniel, I like this one, I can definitely build the drm buffer sharing layer on top of this. How do we see this getting merged? I'm quite happy to push it to Linus if we don't have an identified path, though it could go via a Linaro tree as well. so feel free to add: Reviewed-by: Dave Airlie airl...@redhat.com fwiw, patches to share buffers between drm and v4l2 are here: https://github.com/robclark/kernel-omap4/commits/drmplane-dmabuf (need a bit of cleanup before the vb2 patches are submitted.. but that is unrelated to the dmabuf patches) so, Reviewed-and-Tested-by: Rob Clark rob.cl...@linaro.org Thanks Daniel, Dave, and Rob! BR, Sumit. Dave. -- 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: MEM2MEM devices: how to handle sequence number?
Hello,
On Thursday, December 22, 2011 3:34 PM Javier Martin wrote:
we have a processing chain composed of three v4l2 devices:
- ---
--
| v4l2 source || v4l2 fixer | | v4l2
encoder |
| (capture) |--| (mem2mem)| | (mem2mem) |
|___||| ||
v4l2 source generates consecutive sequence numbers so that we can
detect whether a frame has been lost or not.
v4l2 fixer and v4l2 encoder cannot lose frames because they don't
interact with an external sensor.
How should v4l2 fixer and v4l2 encoder behave regarding frame
sequence number? Should they just copy the sequence number from the
input buffer to the output buffer or should they maintain their own
count for the CAPTURE queue?
IMHO mem2mem devices, which process buffers in 1:1 way (there is always
exactly one 'capture'/destination buffer for every 'output'/source buffer)
can simply copy the sequence number from the source buffer to the
destination.
If there is no such 1:1 mapping between the buffers, drivers should maintain
their own numbers. video encoder is probably an example of such device.
A single destination ('capture') buffer with encoded video data might
contain a fraction, one or more source ('output') video buffers/frames.
If the former option is chosen we should apply a patch like the
following so that the sequence number of the input buffer is passed to
the videobuf2 layer:
diff --git a/drivers/media/video/videobuf2-core.c
b/drivers/media/video/videobuf2-core.c
index 1250662..7d8a88b 100644
--- a/drivers/media/video/videobuf2-core.c
+++ b/drivers/media/video/videobuf2-core.c
@@ -1127,6 +1127,7 @@ int vb2_qbuf(struct vb2_queue *q, struct v4l2_buffer *b)
*/
list_add_tail(vb-queued_entry, q-queued_list);
vb-state = VB2_BUF_STATE_QUEUED;
+ vb-v4l2_buf.sequence = b-sequence;
/*
* If already streaming, give the buffer to driver for processing.
Right, such patch is definitely needed. Please resend it with 'signed-off-by'
annotation.
Best regards
--
Marek Szyprowski
Samsung Poland RD Center
--
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 v2] media i.MX27 camera: Fix field_count handling.
Hi Guennadi,
thank you for your comments.
On 23 December 2011 00:17, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote:
On Thu, 22 Dec 2011, Javier Martin wrote:
To properly detect frame loss the driver must keep
track of a frame_count.
Furthermore, field_count use was erroneous because
in progressive format this must be incremented twice.
Hm, sorry, why this? I just looked at vivi.c - the version before
videobuf2 conversion - and it seems to only increment the count by one.
If you look at the videobuf-core code you'll notice that the value
assigned to v4l2_buf sequence field is (field_count 1):
http://lxr.linux.no/#linux+v3.1.6/drivers/media/video/videobuf-core.c#L370
Since mx2_camera driver only supports video formats which are either
progressive or provide both fields in the same buffer, this
field_count must be incremented twice so that the final sequence
number is OK.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/video/mx2_camera.c | 5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/mx2_camera.c
b/drivers/media/video/mx2_camera.c
index ea1f4dc..ca76dd2 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -255,6 +255,7 @@ struct mx2_camera_dev {
dma_addr_t discard_buffer_dma;
size_t discard_size;
struct mx2_fmt_cfg *emma_prp;
+ u32 frame_count;
The rule I usually follow, when choosing variable type is the following:
does it really have to be fixed bit-width? The positive reply is pretty
rare, it comes mostly if (a) the variable is used to store values read
from or written to some (fixed-width) hardware registers, or (b) the
variable belongs to a fixed ABI, that has to be the same on different
(32-bit, 64-bit) systems, like (arguably) ioctl()s, data, transferred over
the network or stored on a medium (filesystems,...). This doesn't seem to
be the case here, so, I would just use an (unsigned) int.
Thanks for the tip. I hadn't thought of it that way. I just saw that
v4l2_buf.sequence was a __u32 and I thought it was convenient to use
the same type for this variable which is closely related to it
Anyway, let me send a second version of the patch since I've just
noticed this one doesn't reflect lost frames in the field_count field.
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.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
