Re: [PATCH v7 5/6] [media] s5p-mfc: MFCv6 register definitions
Hi Sylwester, Thank you for the comments. Will make necessary changes and post updated patchset. Regards Arun --- Original Message --- Sender : Sylwester Nawrocki Date : Sep 29, 2012 21:05 (GMT+05:30) Title : Re: [PATCH v7 5/6] [media] s5p-mfc: MFCv6 register definitions Hi Arun, I have a few minor comments. On 09/28/2012 07:04 PM, Arun Kumar K wrote: > From: Jeongtae Park > > Adds register definitions for MFC v6.x firmware > > Signed-off-by: Jeongtae Park > Signed-off-by: Janghyuck Kim > Signed-off-by: Jaeryul Oh > Signed-off-by: Naveen Krishna Chatradhi > Signed-off-by: Arun Kumar K > --- > drivers/media/platform/s5p-mfc/regs-mfc-v6.h | 408 > ++ > 1 files changed, 408 insertions(+), 0 deletions(-) > create mode 100644 drivers/media/platform/s5p-mfc/regs-mfc-v6.h > > diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v6.h > b/drivers/media/platform/s5p-mfc/regs-mfc-v6.h > new file mode 100644 > index 000..cce1841 > --- /dev/null > +++ b/drivers/media/platform/s5p-mfc/regs-mfc-v6.h > @@ -0,0 +1,408 @@ > +/* > + * Register definition file for Samsung MFC V6.x Interface (FIMV) driver > + * > + * Copyright (c) 2012 Samsung Electronics I believe the proper notation is Copyright (c) 2012 Samsung Electronics Co., Ltd. Please make sure it's correct in all files added in this series. > + * http://www.samsung.com/ > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License version 2 as > + * published by the Free Software Foundation. > + */ > + > +#ifndef _REGS_FIMV_V6_H > +#define _REGS_FIMV_V6_H Please add #include #include > +#define S5P_FIMV_REG_SIZE_V6 (S5P_FIMV_END_ADDR - S5P_FIMV_START_ADDR) > +#define S5P_FIMV_REG_COUNT_V6((S5P_FIMV_END_ADDR - > S5P_FIMV_START_ADDR) / 4) > + > +/* Number of bits that the buffer address should be shifted for particular > + * MFC buffers. */ > +#define S5P_FIMV_MEM_OFFSET_V6 0 > + > +#define S5P_FIMV_START_ADDR_V6 0x > +#define S5P_FIMV_END_ADDR_V6 0xfd80 > + > +#define S5P_FIMV_REG_CLEAR_BEGIN_V6 0xf000 > +#define S5P_FIMV_REG_CLEAR_COUNT_V6 1024 > + > +/* Codec Common Registers */ > +#define S5P_FIMV_RISC_ON_V6 0x > +#define S5P_FIMV_RISC2HOST_INT_V60x003C Could you make sure all hex numbers are in lower case in this file ? ... > +#define S5P_FIMV_NUM_TMV_BUFFERS_V6 2 > + > +#define S5P_FIMV_MAX_FRAME_SIZE_V6 (2048 * 1024) (2 * SZ_1M) > +#define S5P_FIMV_NUM_PIXELS_IN_MB_ROW_V6 16 > +#define S5P_FIMV_NUM_PIXELS_IN_MB_COL_V6 16 > + > +/* Buffer size requirements defined by hardware */ > +#define S5P_FIMV_TMV_BUFFER_SIZE_V6(w, h)((w + 1) * (h + 1) * 8) The arguments should be in parentheses in the expressions, i.e. #define S5P_FIMV_TMV_BUFFER_SIZE_V6(w, h) (((w) + 1) * ((h) + 1) * 8) > +#define S5P_FIMV_ME_BUFFER_SIZE_V6(imw, imh, mbw, mbh) \r > + (imw+63)/64) * 16) * \r > + (((imh+63)/64) * 16)) + \r > + mbw*mbh)+31)/32) * 16)) Could be rewritten as: #define S5P_FIMV_ME_BUFFER_SIZE_V6(imw, imh, mbw, mbh) \r ((ALIGN(imw, 64) * ALIGN(imh, 64) * 256) + (ALIGN((mbw) * (mbh), 32) * 16)) > +#define S5P_FIMV_SCRATCH_BUF_SIZE_H264_DEC_V6(w, h) ((w * 192) + 64) > +#define S5P_FIMV_SCRATCH_BUF_SIZE_MPEG4_DEC_V6(w, h) \r > + (w * (h * 64 + 144) + \r > + ((2048 + 15)/16 * h * 64) + \r > + ((2048 + 15)/16 * 256 + 8320)) (w * (h * 64 + 144) + (2048/16 * h * 64) + (2048/16 * 256 + 8320)) > +#define S5P_FIMV_SCRATCH_BUF_SIZE_VC1_DEC_V6(w, h) (2096 * (w + h + 1)) > +#define S5P_FIMV_SCRATCH_BUF_SIZE_H263_DEC_V6(w, h) (w * 400) > +#define S5P_FIMV_SCRATCH_BUF_SIZE_VP8_DEC_V6(w, h) \r > + (w * 32 + h * 128 + \r > + ((w + 1) / 2) * 64 + 2112) Unnecessarily broken into two lines. > +#define S5P_FIMV_SCRATCH_BUF_SIZE_H264_ENC_V6(w, h) \r > + ((w * 64) + ((w + 1) * 16) + \r > + (4096 * 16)) Ditto. > +#define S5P_FIMV_SCRATCH_BUF_SIZE_MPEG4_ENC_V6(w, h) \r > + ((w * 16) + ((w + 1) * 16)) > + > +/* MFC Context buffer sizes */ > +#define MFC_CTX_BUF_SIZE_V6 0x7000 /* 28KB */ Perhaps we could use the SZ_* macro definitions, e.g. (28 * SZ_1K) ? > +#define MFC_H264_DEC_CTX_BUF_SIZE_V6 0x20/* 1.6MB */ (1600 * SZ_1K) ... > +#define MFC_OTHER_DEC_CTX_BUF_SIZE_V60x5000 /* 20KB */ > +#define MFC_H264_ENC_CTX_BUF_SIZE_V6 0x19000
Re: [PATCH RFC] dvb: LNA implementation changes
I added few comments for things what I was a little but unsure. Please
comment.
On 10/01/2012 03:35 AM, Antti Palosaari wrote:
* use dvb property cache
* implement get
* LNA_AUTO value changed
Hans and Mauro proposed use of cache implementation of get as they
were planning to extend LNA usage for analog side too.
LNA_AUTO value was changed from (~0U) to INT_MIN as (~0U) resulted
only -1 which is waste of numeric range if need to extend that in
the future.
Reported-by: Hans Verkuil
Reported-by: Mauro Carvalho Chehab
Signed-off-by: Antti Palosaari
---
drivers/media/dvb-core/dvb_frontend.c | 18 ++
drivers/media/dvb-core/dvb_frontend.h | 4 +++-
drivers/media/usb/em28xx/em28xx-dvb.c | 9 +
include/linux/dvb/frontend.h | 2 +-
4 files changed, 23 insertions(+), 10 deletions(-)
diff --git a/drivers/media/dvb-core/dvb_frontend.c
b/drivers/media/dvb-core/dvb_frontend.c
index 8f58f24..246a3c5 100644
--- a/drivers/media/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb-core/dvb_frontend.c
@@ -966,6 +966,8 @@ static int dvb_frontend_clear_cache(struct dvb_frontend *fe)
break;
}
+ c->lna = LNA_AUTO;
+
return 0;
}
@@ -1054,6 +1056,8 @@ static struct dtv_cmds_h dtv_cmds[DTV_MAX_COMMAND + 1] = {
_DTV_CMD(DTV_ATSCMH_SCCC_CODE_MODE_B, 0, 0),
_DTV_CMD(DTV_ATSCMH_SCCC_CODE_MODE_C, 0, 0),
_DTV_CMD(DTV_ATSCMH_SCCC_CODE_MODE_D, 0, 0),
+
+ _DTV_CMD(DTV_LNA, 0, 0),
};
static void dtv_property_dump(struct dvb_frontend *fe, struct dtv_property
*tvp)
@@ -1440,6 +1444,10 @@ static int dtv_property_process_get(struct dvb_frontend
*fe,
tvp->u.data = fe->dtv_property_cache.atscmh_sccc_code_mode_d;
break;
+ case DTV_LNA:
+ tvp->u.data = c->lna;
+ break;
+
default:
return -EINVAL;
}
@@ -1731,10 +1739,6 @@ static int dtv_property_process_set(struct dvb_frontend
*fe,
case DTV_INTERLEAVING:
c->interleaving = tvp->u.data;
break;
- case DTV_LNA:
- if (fe->ops.set_lna)
- r = fe->ops.set_lna(fe, tvp->u.data);
- break;
/* ISDB-T Support here */
case DTV_ISDBT_PARTIAL_RECEPTION:
@@ -1806,6 +1810,12 @@ static int dtv_property_process_set(struct dvb_frontend
*fe,
fe->dtv_property_cache.atscmh_rs_frame_ensemble = tvp->u.data;
break;
+ case DTV_LNA:
+ c->lna = tvp->u.data;
+ if (fe->ops.set_lna)
+ r = fe->ops.set_lna(fe);
+ break;
+
default:
return -EINVAL;
}
diff --git a/drivers/media/dvb-core/dvb_frontend.h
b/drivers/media/dvb-core/dvb_frontend.h
index 44a445c..5d25953 100644
--- a/drivers/media/dvb-core/dvb_frontend.h
+++ b/drivers/media/dvb-core/dvb_frontend.h
@@ -303,7 +303,7 @@ struct dvb_frontend_ops {
int (*dishnetwork_send_legacy_command)(struct dvb_frontend* fe,
unsigned long cmd);
int (*i2c_gate_ctrl)(struct dvb_frontend* fe, int enable);
int (*ts_bus_ctrl)(struct dvb_frontend* fe, int acquire);
- int (*set_lna)(struct dvb_frontend *, int);
+ int (*set_lna)(struct dvb_frontend *);
/* These callbacks are for devices that implement their own
* tuning algorithms, rather than a simple swzigzag
@@ -391,6 +391,8 @@ struct dtv_frontend_properties {
u8 atscmh_sccc_code_mode_b;
u8 atscmh_sccc_code_mode_c;
u8 atscmh_sccc_code_mode_d;
+
+ int lna;
Is it reason or coincidence that all the other variables are unsigned here?
};
struct dvb_frontend {
diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c
b/drivers/media/usb/em28xx/em28xx-dvb.c
index 109474b..1166e8b 100644
--- a/drivers/media/usb/em28xx/em28xx-dvb.c
+++ b/drivers/media/usb/em28xx/em28xx-dvb.c
@@ -569,15 +569,16 @@ static void pctv_520e_init(struct em28xx *dev)
i2c_master_send(&dev->i2c_client, regs[i].r, regs[i].len);
};
-static int em28xx_pctv_290e_set_lna(struct dvb_frontend *fe, int val)
+static int em28xx_pctv_290e_set_lna(struct dvb_frontend *fe)
{
+ struct dtv_frontend_properties *c = &fe->dtv_property_cache;
struct em28xx *dev = fe->dvb->priv;
#ifdef CONFIG_GPIOLIB
struct em28xx_dvb *dvb = dev->dvb;
int ret;
unsigned long flags;
- if (val)
+ if (c->lna)
flags = GPIOF_OUT_INIT_LOW;
else
flags = GPIOF_OUT_INIT_HIGH;
@@ -590,8 +591,8 @@ static int em28xx_pctv_290e_set_lna(struct dvb_frontend
*fe, int val)
return ret;
#else
- dev_warn(&dev->udev->dev, "%s: LNA control is disabled\n",
- KBUILD_MODNAME);
+ dev_warn(&dev->udev->dev, "%s: LNA control is disabled (lna=%d)\n",
+
[PATCH RFC] dvb: LNA implementation changes
* use dvb property cache
* implement get
* LNA_AUTO value changed
Hans and Mauro proposed use of cache implementation of get as they
were planning to extend LNA usage for analog side too.
LNA_AUTO value was changed from (~0U) to INT_MIN as (~0U) resulted
only -1 which is waste of numeric range if need to extend that in
the future.
Reported-by: Hans Verkuil
Reported-by: Mauro Carvalho Chehab
Signed-off-by: Antti Palosaari
---
drivers/media/dvb-core/dvb_frontend.c | 18 ++
drivers/media/dvb-core/dvb_frontend.h | 4 +++-
drivers/media/usb/em28xx/em28xx-dvb.c | 9 +
include/linux/dvb/frontend.h | 2 +-
4 files changed, 23 insertions(+), 10 deletions(-)
diff --git a/drivers/media/dvb-core/dvb_frontend.c
b/drivers/media/dvb-core/dvb_frontend.c
index 8f58f24..246a3c5 100644
--- a/drivers/media/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb-core/dvb_frontend.c
@@ -966,6 +966,8 @@ static int dvb_frontend_clear_cache(struct dvb_frontend *fe)
break;
}
+ c->lna = LNA_AUTO;
+
return 0;
}
@@ -1054,6 +1056,8 @@ static struct dtv_cmds_h dtv_cmds[DTV_MAX_COMMAND + 1] = {
_DTV_CMD(DTV_ATSCMH_SCCC_CODE_MODE_B, 0, 0),
_DTV_CMD(DTV_ATSCMH_SCCC_CODE_MODE_C, 0, 0),
_DTV_CMD(DTV_ATSCMH_SCCC_CODE_MODE_D, 0, 0),
+
+ _DTV_CMD(DTV_LNA, 0, 0),
};
static void dtv_property_dump(struct dvb_frontend *fe, struct dtv_property
*tvp)
@@ -1440,6 +1444,10 @@ static int dtv_property_process_get(struct dvb_frontend
*fe,
tvp->u.data = fe->dtv_property_cache.atscmh_sccc_code_mode_d;
break;
+ case DTV_LNA:
+ tvp->u.data = c->lna;
+ break;
+
default:
return -EINVAL;
}
@@ -1731,10 +1739,6 @@ static int dtv_property_process_set(struct dvb_frontend
*fe,
case DTV_INTERLEAVING:
c->interleaving = tvp->u.data;
break;
- case DTV_LNA:
- if (fe->ops.set_lna)
- r = fe->ops.set_lna(fe, tvp->u.data);
- break;
/* ISDB-T Support here */
case DTV_ISDBT_PARTIAL_RECEPTION:
@@ -1806,6 +1810,12 @@ static int dtv_property_process_set(struct dvb_frontend
*fe,
fe->dtv_property_cache.atscmh_rs_frame_ensemble = tvp->u.data;
break;
+ case DTV_LNA:
+ c->lna = tvp->u.data;
+ if (fe->ops.set_lna)
+ r = fe->ops.set_lna(fe);
+ break;
+
default:
return -EINVAL;
}
diff --git a/drivers/media/dvb-core/dvb_frontend.h
b/drivers/media/dvb-core/dvb_frontend.h
index 44a445c..5d25953 100644
--- a/drivers/media/dvb-core/dvb_frontend.h
+++ b/drivers/media/dvb-core/dvb_frontend.h
@@ -303,7 +303,7 @@ struct dvb_frontend_ops {
int (*dishnetwork_send_legacy_command)(struct dvb_frontend* fe,
unsigned long cmd);
int (*i2c_gate_ctrl)(struct dvb_frontend* fe, int enable);
int (*ts_bus_ctrl)(struct dvb_frontend* fe, int acquire);
- int (*set_lna)(struct dvb_frontend *, int);
+ int (*set_lna)(struct dvb_frontend *);
/* These callbacks are for devices that implement their own
* tuning algorithms, rather than a simple swzigzag
@@ -391,6 +391,8 @@ struct dtv_frontend_properties {
u8 atscmh_sccc_code_mode_b;
u8 atscmh_sccc_code_mode_c;
u8 atscmh_sccc_code_mode_d;
+
+ int lna;
};
struct dvb_frontend {
diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c
b/drivers/media/usb/em28xx/em28xx-dvb.c
index 109474b..1166e8b 100644
--- a/drivers/media/usb/em28xx/em28xx-dvb.c
+++ b/drivers/media/usb/em28xx/em28xx-dvb.c
@@ -569,15 +569,16 @@ static void pctv_520e_init(struct em28xx *dev)
i2c_master_send(&dev->i2c_client, regs[i].r, regs[i].len);
};
-static int em28xx_pctv_290e_set_lna(struct dvb_frontend *fe, int val)
+static int em28xx_pctv_290e_set_lna(struct dvb_frontend *fe)
{
+ struct dtv_frontend_properties *c = &fe->dtv_property_cache;
struct em28xx *dev = fe->dvb->priv;
#ifdef CONFIG_GPIOLIB
struct em28xx_dvb *dvb = dev->dvb;
int ret;
unsigned long flags;
- if (val)
+ if (c->lna)
flags = GPIOF_OUT_INIT_LOW;
else
flags = GPIOF_OUT_INIT_HIGH;
@@ -590,8 +591,8 @@ static int em28xx_pctv_290e_set_lna(struct dvb_frontend
*fe, int val)
return ret;
#else
- dev_warn(&dev->udev->dev, "%s: LNA control is disabled\n",
- KBUILD_MODNAME);
+ dev_warn(&dev->udev->dev, "%s: LNA control is disabled (lna=%d)\n",
+ KBUILD_MODNAME, c->lna);
return 0;
#endif
}
diff --git a/include/linux/dvb/frontend.h b/include/linux/dvb/frontend.h
index c12d452..6c97457 100644
--- a/include/linux/dvb/frontend.h
+++ b/includ
Re: [PATCH 2/4] [media] marvell-ccic: core: add soc camera support on marvell-ccic mcam-core
On Sat, 29 Sep 2012 13:40:41 -0600 Jonathan Corbet wrote: > I'm glad this work is being done, but I have some high-level grumbles > to start with. I was thinking on this over the weekend, and I realized that my response may have been a bit too short and grumpy. So I wanted to add one little thing: It's really great that Marvell is putting the time into doing this work, and, my gripes notwithstanding, you're doing it right. You've sent your code out, listened to the responses you've gotten, and done the work to try to address them. Quite a bit of progress has been made here, and I don't doubt this code will be ready for merging before too much longer. Please continue on this path; we do appreciate the work you're doing. Thanks, jon -- 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
Current media_build doesn't succeed building on kernel 3.1.10
Hi all, is anybody out there who can help me with the media_build system? I'm trying to build the current modules on an openSUSE 12.1 system (kernel 3.1.10, x86_64), but I'm getting compilation errors because the s5k4ecgx driver uses function devm_regulator_bulk_get() which AFAICS has been introduced in kernel 3.4 only. When I run the ./build script compilation stops with these messages: CC [M] /root/projects/media_build/v4l/s5k4ecgx.o media_build/v4l/s5k4ecgx.c: In function 's5k4ecgx_load_firmware': media_build/v4l/s5k4ecgx.c:346:2: warning: format '%d' expects argument of \ type 'int', but argument 4 has type 'size_t' [-Wformat] media_build/v4l/s5k4ecgx.c: In function 's5k4ecgx_probe': media_build/v4l/s5k4ecgx.c:977:2: error: implicit declaration of \ function 'devm_regulator_bulk_get' [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors Probably I'll don't need module s5k4ecgx anyway, so any hint how to exclude this from build would be fine. On this page http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers#Retrieving_and_Building.2FCompiling_the_Latest_V4L-DVB_Source_Code the section "More Manually Intensive Approach" mentions steps where I can run "make menuconfig" after unpacking the sources and before the build process is started, so I could deselect the module(s) I don't need and exclude them from build. However, I've no idea what I should use for "DIR=" in the command make tar DIR= mentioned on the web page. According to theis link https://patchwork.kernel.org/patch/1267511/ the s5k4ecgx module which does not build here has just been added at the beginning of August, so if I could specify a git version of the code which is slightly older this might also work. BTW, if I understand the build environment correctly then there should be dayly test builds of the package for varions kernels. I'd expect those automated builds should also fail for kernels older than 3.4. Regards, Martin -- 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: DiBcom 7000PC: Not able to scan for services on Raspberry Pi
On Sun, Sep 30, 2012 at 4:55 AM, Devin Heitmueller wrote: > On Sat, Sep 29, 2012 at 3:34 PM, Ladislav Józsa wrote: >> Running the same on my x86_64 machine works and tvheadend sees >> multiplexes. What else information do you need from me in order to >> track the problem? > > Recompile your kernel with debug info so we can see the symbols for > the stack dump. Otherwise there is no way for anybody to know where > the oops is occurring in the driver. > > Devin > > > -- > Devin J. Heitmueller - Kernel Labs > http://www.kernellabs.com Devin, thanks for the suggestion but it won't be necessary to recompile kernel as it emerged that the TV adapter didn't have sufficient power. When connected behind an active USB hub everything works like a charm. Sorry for the noise. Ladislav . -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Sun Sep 30 19:00:20 CEST 2012 git hash:8928b6d1568eb9104cc9e2e6627d7086437b2fb3 gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: ERRORS linux-git-arm-eabi-exynos: WARNINGS linux-git-arm-eabi-omap: ERRORS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-sh: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: ERRORS linux-2.6.33-x86_64: ERRORS linux-2.6.34-x86_64: ERRORS linux-2.6.35.3-x86_64: ERRORS linux-2.6.36-x86_64: ERRORS linux-2.6.37-x86_64: ERRORS linux-2.6.38.2-x86_64: ERRORS linux-2.6.39.1-x86_64: ERRORS linux-3.0-x86_64: ERRORS linux-3.1-x86_64: ERRORS linux-3.2.1-x86_64: ERRORS linux-3.3-x86_64: ERRORS linux-3.4-x86_64: WARNINGS linux-3.5-x86_64: WARNINGS linux-3.6-rc2-x86_64: WARNINGS linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: ERRORS linux-2.6.33-i686: ERRORS linux-2.6.34-i686: ERRORS linux-2.6.35.3-i686: ERRORS linux-2.6.36-i686: ERRORS linux-2.6.37-i686: ERRORS linux-2.6.38.2-i686: ERRORS linux-2.6.39.1-i686: ERRORS linux-3.0-i686: ERRORS linux-3.1-i686: ERRORS linux-3.2.1-i686: ERRORS linux-3.3-i686: ERRORS linux-3.4-i686: WARNINGS linux-3.5-i686: WARNINGS linux-3.6-rc2-i686: WARNINGS apps: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb id addition for Terratec Cinergy T Stick Dual rev. 2
Le 29/09/2012 19:33, Mauro Carvalho Chehab a écrit : It seems that the it931x variant has bcdDevice equal to 2.00, from Damien's email: idVendor 0x0ccd TerraTec Electronic GmbH idProduct 0x0099 bcdDevice2.00 iManufacturer 1 ITE Technologies, Inc. iProduct2 DVB-T TV Stick iSerial 0 If the af9015 variant uses another bcdDevice, the fix should be simple. Alas, according to http://www.linuxtv.org/wiki/index.php/TerraTec_Cinergy_T_USB_Dual_RC the af9015 variant appears to have the same bcdDevice. I join both lsusb outputs for comparison. Regards Damien Bus 003 Device 003: ID 0ccd:0099 TerraTec Electronic GmbH Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x0ccd TerraTec Electronic GmbH idProduct 0x0099 bcdDevice2.00 iManufacturer 1 Afatech iProduct2 DVB-T 2 iSerial 3 xx bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 71 bNumInterfaces 2 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 4 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x85 EP 5 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 0 No Subclass bInterfaceProtocol 1 Keyboard iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType33 bcdHID 1.01 bCountryCode0 Not supported bNumDescriptors 1 bDescriptorType34 Report wDescriptorLength 65 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 10 Device Qualifier (for other device speed): bLength10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 bNumConfigurations 1 Device Status: 0x (Bus Powered) Bus 002 Device 003: ID 0ccd:0099 TerraTec Electronic GmbH Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interfa
Re: [PATCH 2/3] iommu/omap: Merge iommu2.h into iommu.h
On Thu, Sep 27, 2012 at 12:55:26PM -0700, Tony Lindgren wrote: > * Tony Lindgren [120927 12:54]: > > Hi Ido, > > > > * Ido Yariv [120920 22:15]: > > > Since iommu is not currently supported on OMAP1, merge plat/iommu2.h into > > > iommu.h so only one file would have to move to platform_data/ as part of > > > the > > > single zImage effort. > > > > Looks like you need patch 2.5/3 in this series too that > > makes some of the things defined in iommu.h local. > > > > We should only have platform data in include/linux/platform_data, > > so things that are private to drivers should be defined in the > > driver, and things that are private to arch/arm/mach-omap2 should > > defined locally there. > > > > Based on a quick grepping of files, looks like these should be > > defined in omap-iommu.c driver and not in the platform_data header: > > > > struct iotlb_lock > > struct iotlb_lock > > dev_to_omap_iommu > > various register defines > > omap_iommu_arch_version > > omap_iotlb_cr_to_e > > omap_iopgtable_store_entry > > omap_iommu_save_ctx > > omap_iommu_restore_ctx > > omap_foreach_iommu_device > > omap_iommu_dump_ctx > > omap_dump_tlb_entries > > And looks like while at it, you can also move plat/iopgtable.h > and put it in some drivers/iommu/*.h file that's shared by > omap-iommu*.c and omap-iovmm.c drivers ;) Sure thing, I'll post a v2 shortly. Thanks, Ido. -- 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
hdpvr driver and VIDIOC_G_FMT
I am using the Hauppauge HD PVR video-capture device with a GStreamer
"v4l2src". The HD PVR has an upstream driver called "hdpvr":
http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=tree;f=drivers/media/video/hdpvr
When the HD PVR device does not have any video on its capture input, the
VIDIOC_G_FMT ioctl fails. GStreamer ignores the error (and doesn't
report it to my application); the HD PVR fails to start up so even if
video is later established on the HD PVR's input, the GStreamer pipeline
never receives video. (Bear with me, linuxtv folks; I have plenty of
non-GStreamer questions for you.) :-)
It seems to me that the only reason the hdpvr's vidioc_g_fmt_vid_cap [1]
fails, is because it doesn't know the video width & height until it
has video on its input:
vid_info = get_video_info(dev);
if (!vid_info)
return -EFAULT;
f->type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
f->fmt.pix.pixelformat = V4L2_PIX_FMT_MPEG;
f->fmt.pix.width= vid_info->width;
f->fmt.pix.height = vid_info->height;
f->fmt.pix.sizeimage= dev->bulk_in_size;
f->fmt.pix.colorspace = 0;
f->fmt.pix.bytesperline = 0;
f->fmt.pix.field= V4L2_FIELD_ANY;
Note that the v4l2 documentation for VIDIOC_G_FMT [2] says:
Drivers should not return an error code unless the type field is
invalid, this is a mechanism to fathom device capabilities and to
approach parameters acceptable for both the application and driver.
The above discusses "device capabilities" whereas what the hdpvr driver
does in this case describes properties of the input data. The difficulty
is that the capabilities of the hardware include a whole bunch of
different resolutions and frame-rates but these modes seem only
available if they match the incoming signal.
Question 1: Is this [return -EFAULT] a bug in the hdpvr driver? If the
format is mpeg, why do we need to fill in width & height -- isn't this
something the container or codec will tell you? It seems to me that all
the other fields can be determined even without video on the device's
capture input, so this function doesn't need to fail.
Now looking at v4l2_fd_open: [3]
/* Get current cam format */
fmt.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
if (dev_ops->ioctl(dev_ops_priv, fd, VIDIOC_G_FMT, &fmt)) {
int saved_err = errno;
V4L2_LOG_ERR("getting pixformat: %s\n", strerror(errno));
v4l2_plugin_cleanup(plugin_library, dev_ops_priv, dev_ops);
errno = saved_err;
return -1;
}
Question 2: Is v4l2 mostly designed towards webcams (as the comment in
the above code implies)? What about capturing a continuous video stream
from a video-capture device, where I want to continue capturing even
when the capture device loses video input? (Say, it's connected to a
set-top box that reboots, and I want to capture the video from the
set-top box before it reboots and after it reboots, with a blank image
during the time the video was lost.)
Now to GStreamer: gst_v4l2_open [4] ignores the error from v4l2_fd_open:
libv4l2_fd = v4l2_fd_open (v4l2object->video_fd,
V4L2_ENABLE_ENUM_FMT_EMULATION);
/* Note the v4l2_xxx functions are designed so that if they get passed an
unknown fd, the will behave exactly as their regular xxx counterparts, so
if v4l2_fd_open fails, we continue as normal (missing the libv4l2 custom
cam format to normal formats conversion). Chances are big we will still
fail then though, as normally v4l2_fd_open only fails if the device is
not
a v4l2 device. */
if (libv4l2_fd != -1)
v4l2object->video_fd = libv4l2_fd;
Again a comment mentioning "cams".
Question 3: If "chances are big we will still fail" anyway, could we
instead report the error up to the GStreamer pipeline/application?
Thanks for your help, and I hope my ignorance doesn't show through too
much in my questions. :-) What we haven't tried yet is just removing the
call to get_video_info from VIDIOC_G_FMT and related calls in the kernel
to avoid the failure condition, and see what happens; but in parallel
with that task I thought I'd write to you for some guidance.
David Rothlisberger
http://stb-tester.com
[1]
http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=blob;f=drivers/media/video/hdpvr/hdpvr-video.c;h=0e9e156#l1142
[2] http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-g-fmt.html
[3]
http://git.linuxtv.org/v4l-utils.git/blob/c7ffd22:/lib/libv4l2/libv4l2.c#l612
[4]
http://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/sys/v4l2/v4l2_calls.c?id=05d4f81#n407
--
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
bttv-i2c.c wrong printk() fix
Hi all,
since i am using Linux 3.x my syslog gets flooded with tons of
[67819.884660] >
[67819.885062] >
[67819.885466] >
...
Please add these patch to v4l:
--- v4l-dvb/drivers/media/pci/bt8xx/bttv-i2c.c.orig 2012-09-30
12:54:09.611095929 +0200
+++ v4l-dvb/drivers/media/pci/bt8xx/bttv-i2c.c 2012-09-30
12:59:40.797318140 +0200
@@ -173,7 +173,7 @@
if (i2c_debug)
pr_cont(" %02x", msg->buf[cnt]);
}
- if (!(xmit & BT878_I2C_NOSTOP))
+ if (i2c_debug && !(xmit & BT878_I2C_NOSTOP))
pr_cont(">\n");
return msg->len;
Thanks and
Ciao,
Andreas
--
Andreas Kool (Dont send mail to: ubecac...@akool.de)
Transmission of this message via the Microsoft Network is prohibited
"Das Wort WINDOWS stammt aus einem alten Sioux-Dialekt und bedeutet:
Weisser Mann starrt durch Glasscheibe auf Sanduhr." (anonym)
--
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: qv4l2-bug / libv4lconvert API issue
Hi, On 09/28/2012 07:09 PM, Frank Schäfer wrote: Hi, Am 27.09.2012 21:41, schrieb Hans de Goede: Hi, On 09/27/2012 03:20 PM, Frank Schäfer wrote: What you've found is a qv4l2 bug (do you have the latest version?) Of course, I'm using the latest developer version. Even if this is just a qv4l2-bug: how do you want to fix it without removing the format selction feature ? Well, if qv4l2 can only handle rgb24 data, then it should gray out the format selection (fixing it at rgb24) when not in raw mode. So you say "just remove this feature from qv4l2". I prefer fixing the library / API instead. No I'm suggesting to keep the feature to select which input format to use when in raw mode, while at the same time disabling the feature) when in libv4l2 mode. What use is it to ask libv4l2 for say YUV420 data and then later ask libv4lconvert to convert this to RGB24, when you could have asked libv4l2 for RGB24 right away. v4lconvert_convert should only be called with src_fmt and dest_fmt parameters which are the result of a v4lconvert_try_format call, which clearly is not the case here! Why ? Because our library code is broken ? Because that is a pre-condition which v4lconvert_convert expects to be met. Not meeting that pre-condition means operating outside of the designated operating parameters, and as such weird things may happen. Is this important restriction documented somewhere ? Not explicitly, patches welcome. one is supposed to either use libv4l2, or do raw device access and then call libv4lconvert directly. Even when using libv4lconvert only, multiple frame conversions are still causing the same trouble. True, but doing multiple conversions on one frame is just crazy ... Well, I would say "not necessary in most cases". But I can certainly think of use cases (other than what qv4l2 does). At least it should be possible and I think this is what application programmers expect when using a conversion function from a library. Right, as said before libv4lconvert is not meant as a generic format conversion library, and using it as such is not necessarily a good idea as there are much better alternatives out there for doing generic format conversion (both more flexible and faster). More over libv4lconvert is specifically designed to be called once per frame. Yes another restriction that needs documenting. But saying that libv4l2 and libv4lconvert can't be used at the same (although they are separate public libraries) and that v4lconvert_convert() may only be called once per frame seems to me like a - I would say "weird" - reinterpretation of the API... I don't think this is what applications currently expect (qv4l2 doesn't ;) ) and at least this would need public clarification. Using the 2 at the same time never was the intention libv4lconvert lies *beneath* libv4l2 in the stack. Yeah, sure. Using them both at the same time would be like using some high level file io API, while at the same making lowlevel seek / read / write calls on the underlying fd and then expecting things to behave consistently. 00.9% of all apps should (and do) use the "highlevel" libv4l2 API. Some testing / developer apps like qv4l2 use libv4lconvert directly. The problem here is, that we actually have TWO high level APIs which interact in a - let's call it "unfortunate" - way. I disagree that they are both highlevel. I know of only 2 tools which use libv4lconvert directly, qv4l2 and svv, and both of them were written by kernel developers for driver testing. So in practice everyone who want a "high" level API is using libv4l2 (which is already low-level enough by it self). > This interaction is not clear for the users (due to the transparent > processing stuff) and it doesn't match not what users expect. > But I think we can fix it and gain some nice extra features as a bonus. Then lets document the interaction. I think you don't realize which can of worms you're opening when you try to make libv4lconvert more generally usable. Please read the v4lconvert_convert function very carefully, esp. the part where it hooks into v4lprocessing (software whitebalance, and gamma correction). Make sure you understand what v4lprocessing_pre_processing() does, what the difference is between convert = 1 and convert = 2, and where *all* the callers are of v4lprocessing_processing() (hint one is hiding in v4lconvert_convert_pixfmt) Make sure you understand every single line of v4lconvert_convert! Once you've done that I will welcome a proposal to make the libv4lconvert API more general usable which: 1) Does not break any existing use-cases 2) Does not slow down things in anyway (so which does not introduce any extra intermediate buffers) 2) What is the use case for having separate convert_pixfmt etc. functions available ... ? We already have them as separate functions, so the only question is: does it make sense to make them public ? I would say: yes, because this seems to be a sane way to f
