Re: [PATCH 1/2] V4L/DVB: v4l2-dev: revert commit c29fcff3daafbf46d64a543c1950bbd206ad8c1c
Hi Bob,
On Friday 29 April 2011 12:11:34 Bob Liu wrote:
> Revert commit:
> V4L/DVB: v4l2-dev: remove get_unmapped_area(c29fcff3daafbf46d64a543c1950bb)
> to restore NOMMU arch supporting.
>
> Signed-off-by: Bob Liu
git provides a 'git revert' command to revert patches. It formats the commit
message in a standard way. I'll use it instead of applying this patch to my
tree and I'll keep your SoB line (unless you object to that).
> ---
> drivers/media/video/v4l2-dev.c | 18 ++
> include/media/v4l2-dev.h |2 ++
> 2 files changed, 20 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/media/video/v4l2-dev.c
> b/drivers/media/video/v4l2-dev.c index 6dc7196..19d5ae2 100644
> --- a/drivers/media/video/v4l2-dev.c
> +++ b/drivers/media/video/v4l2-dev.c
> @@ -352,6 +352,23 @@ static long v4l2_ioctl(struct file *filp, unsigned int
> cmd, unsigned long arg) return ret;
> }
>
> +#ifdef CONFIG_MMU
> +#define v4l2_get_unmapped_area NULL
> +#else
> +static unsigned long v4l2_get_unmapped_area(struct file *filp,
> + unsigned long addr, unsigned long len, unsigned long pgoff,
> + unsigned long flags)
> +{
> + struct video_device *vdev = video_devdata(filp);
> +
> + if (!vdev->fops->get_unmapped_area)
> + return -ENOSYS;
> + if (!video_is_registered(vdev))
> + return -ENODEV;
> + return vdev->fops->get_unmapped_area(filp, addr, len, pgoff, flags);
> +}
> +#endif
> +
> static int v4l2_mmap(struct file *filp, struct vm_area_struct *vm)
> {
> struct video_device *vdev = video_devdata(filp);
> @@ -454,6 +471,7 @@ static const struct file_operations v4l2_fops = {
> .read = v4l2_read,
> .write = v4l2_write,
> .open = v4l2_open,
> + .get_unmapped_area = v4l2_get_unmapped_area,
> .mmap = v4l2_mmap,
> .unlocked_ioctl = v4l2_ioctl,
> #ifdef CONFIG_COMPAT
> diff --git a/include/media/v4l2-dev.h b/include/media/v4l2-dev.h
> index 8266d5a..93e96fb 100644
> --- a/include/media/v4l2-dev.h
> +++ b/include/media/v4l2-dev.h
> @@ -62,6 +62,8 @@ struct v4l2_file_operations {
> unsigned int (*poll) (struct file *, struct poll_table_struct *);
> long (*ioctl) (struct file *, unsigned int, unsigned long);
> long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long);
> + unsigned long (*get_unmapped_area) (struct file *, unsigned long,
> + unsigned long, unsigned long, unsigned long);
> int (*mmap) (struct file *, struct vm_area_struct *);
> int (*open) (struct file *);
> int (*release) (struct file *);
--
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] V4L/DVB: v4l2-dev: revert commit c29fcff3daafbf46d64a543c1950bbd206ad8c1c
On Fri, May 6, 2011 at 4:22 PM, Laurent Pinchart
wrote:
> Hi Bob,
>
> On Friday 29 April 2011 12:11:34 Bob Liu wrote:
>> Revert commit:
>> V4L/DVB: v4l2-dev: remove get_unmapped_area(c29fcff3daafbf46d64a543c1950bb)
>> to restore NOMMU arch supporting.
>>
>> Signed-off-by: Bob Liu
>
> git provides a 'git revert' command to revert patches. It formats the commit
Sorry, I haven't use 'git revert' before.
> message in a standard way. I'll use it instead of applying this patch to my
> tree and I'll keep your SoB line (unless you object to that).
>
Okay, Thanks a lot.
>> ---
>> drivers/media/video/v4l2-dev.c | 18 ++
>> include/media/v4l2-dev.h | 2 ++
>> 2 files changed, 20 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/media/video/v4l2-dev.c
>> b/drivers/media/video/v4l2-dev.c index 6dc7196..19d5ae2 100644
>> --- a/drivers/media/video/v4l2-dev.c
>> +++ b/drivers/media/video/v4l2-dev.c
>> @@ -352,6 +352,23 @@ static long v4l2_ioctl(struct file *filp, unsigned int
>> cmd, unsigned long arg) return ret;
>> }
>>
>> +#ifdef CONFIG_MMU
>> +#define v4l2_get_unmapped_area NULL
>> +#else
>> +static unsigned long v4l2_get_unmapped_area(struct file *filp,
>> + unsigned long addr, unsigned long len, unsigned long pgoff,
>> + unsigned long flags)
>> +{
>> + struct video_device *vdev = video_devdata(filp);
>> +
>> + if (!vdev->fops->get_unmapped_area)
>> + return -ENOSYS;
>> + if (!video_is_registered(vdev))
>> + return -ENODEV;
>> + return vdev->fops->get_unmapped_area(filp, addr, len, pgoff, flags);
>> +}
>> +#endif
>> +
>> static int v4l2_mmap(struct file *filp, struct vm_area_struct *vm)
>> {
>> struct video_device *vdev = video_devdata(filp);
>> @@ -454,6 +471,7 @@ static const struct file_operations v4l2_fops = {
>> .read = v4l2_read,
>> .write = v4l2_write,
>> .open = v4l2_open,
>> + .get_unmapped_area = v4l2_get_unmapped_area,
>> .mmap = v4l2_mmap,
>> .unlocked_ioctl = v4l2_ioctl,
>> #ifdef CONFIG_COMPAT
>> diff --git a/include/media/v4l2-dev.h b/include/media/v4l2-dev.h
>> index 8266d5a..93e96fb 100644
>> --- a/include/media/v4l2-dev.h
>> +++ b/include/media/v4l2-dev.h
>> @@ -62,6 +62,8 @@ struct v4l2_file_operations {
>> unsigned int (*poll) (struct file *, struct poll_table_struct *);
>> long (*ioctl) (struct file *, unsigned int, unsigned long);
>> long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long);
>> + unsigned long (*get_unmapped_area) (struct file *, unsigned long,
>> + unsigned long, unsigned long, unsigned long);
>> int (*mmap) (struct file *, struct vm_area_struct *);
>> int (*open) (struct file *);
>> int (*release) (struct file *);
>
> --
> Regards,
>
> Laurent Pinchart
>
--
Regards,
--Bob
--
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 09/10] rc-core: lirc use unsigned int
On Wed, 04 May 2011 12:23:03 -0300, Mauro Carvalho Chehab
wrote:
> Em 28-04-2011 12:13, David Härdeman escreveu:
>> Durations can never be negative, so it makes sense to consistently use
>> unsigned int for LIRC transmission. Contrary to the initial impression,
>> this shouldn't actually change the userspace API.
>
> Patch looked ok to me (except for one small issue - see bellow).
>
...
>> diff --git a/drivers/media/rc/ene_ir.c b/drivers/media/rc/ene_ir.c
>> index 569b07b..2b1d2df 100644
>> --- a/drivers/media/rc/ene_ir.c
>> +++ b/drivers/media/rc/ene_ir.c
>> @@ -953,13 +953,13 @@ static void ene_set_idle(struct rc_dev *rdev,
bool
>> idle)
>> }
>>
>> /* outside interface: transmit */
>> -static int ene_transmit(struct rc_dev *rdev, int *buf, u32 n)
>> +static int ene_transmit(struct rc_dev *rdev, unsigned *buf, unsigned
n)
>> {
>> struct ene_device *dev = rdev->priv;
>> unsigned long flags;
>>
>> dev->tx_buffer = buf;
>> -dev->tx_len = n / sizeof(int);
>> +dev->tx_len = n;
>
> That hunk seems wrong to me. Or is it a bug fix that you're solving?
My fault, I didn't mention in the patch description that the third
argument of the tx function is also changed to mean array size rather
than size in number of bytes.
--
David Härdeman
--
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 07/10] rc-core: use the full 32 bits for NEC scancodes
On Wed, 04 May 2011 12:16:17 -0300, Mauro Carvalho Chehab wrote: > Em 28-04-2011 12:13, David Härdeman escreveu: >> Using the full 32 bits for all kinds of NEC scancodes simplifies rc-core >> and the nec decoder without any loss of functionality. > > This seems to be a good strategy. However, it breaks the existing NEC > keymap tables (/me is not considering patch 6/10 macros), and changes > those keytables on userspace. Not sure how to address this. The in-kernel keymaps is not a problem, they can always be updated in the same patch. Keytables provided from userspace are a bigger problem. Perhaps we could check if the set/get ioctl is done with the new rc-specific struct (that includes protocol) and assume that the scancode will be in nec32 if the protocol has been explicitly provided. This might seem like we're adding a lot of guesswork into rc-core, but I think we should/could phase out the use of legacy ioctls over a couple of kernel versions and the heuristics can then be removed at the same time. -- David Härdeman -- 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: [git:v4l-dvb/for_v2.6.40] [media] Sony CXD2820R DVB-T/T2/C demodulator driver
On 05/05/2011 12:53 PM, Mauro Carvalho Chehab wrote:
> + switch (priv->delivery_system) {
> + case SYS_UNDEFINED:
> + if (c->delivery_system == SYS_DVBT) {
> + /* SLEEP => DVB-T */
> + ret = cxd2820r_set_frontend_t(fe, p);
> + } else {
> + /* SLEEP => DVB-T2 */
> + ret = cxd2820r_set_frontend_t2(fe, p);
> + }
> + break;
> + case SYS_DVBT:
> + if (c->delivery_system == SYS_DVBT) {
> + /* DVB-T => DVB-T */
> + ret = cxd2820r_set_frontend_t(fe, p);
> + } else if (c->delivery_system == SYS_DVBT2) {
> + /* DVB-T => DVB-T2 */
> + ret = cxd2820r_sleep_t(fe);
> + ret = cxd2820r_set_frontend_t2(fe, p);
> + }
> + break;
> + case SYS_DVBT2:
> + if (c->delivery_system == SYS_DVBT2) {
Is this driver compilable? I don't see the necessary changes to
linux/dvb/frontend.h to add SYS_DVBT2 in your tree.
See below for a patch that I used for testing DVB-T2 internally.
Regards,
Andreas
--
commit e89f95641f29b7a4457e7a68649f4374933e36a2
Author: Andreas Oberritter
Date: Mon Mar 15 14:43:52 2010 +0100
DVB: Add basic API support for DVB-T2 and bump minor version
Signed-off-by: Andreas Oberritter
diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c
b/drivers/media/dvb/dvb-core/dvb_frontend.c
index f5016ae..6f06efe 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -1141,10 +1141,9 @@ static void dtv_property_adv_params_sync(struct
dvb_frontend *fe)
break;
}
- if(c->delivery_system == SYS_ISDBT) {
- /* Fake out a generic DVB-T request so we pass validation in
the ioctl */
- p->frequency = c->frequency;
- p->inversion = c->inversion;
+ /* 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)) {
p->u.ofdm.constellation = QAM_AUTO;
p->u.ofdm.code_rate_HP = FEC_AUTO;
p->u.ofdm.code_rate_LP = FEC_AUTO;
diff --git a/include/linux/dvb/frontend.h b/include/linux/dvb/frontend.h
index 493a2bf..36a3ed6 100644
--- a/include/linux/dvb/frontend.h
+++ b/include/linux/dvb/frontend.h
@@ -175,14 +175,20 @@ typedef enum fe_transmit_mode {
TRANSMISSION_MODE_2K,
TRANSMISSION_MODE_8K,
TRANSMISSION_MODE_AUTO,
- TRANSMISSION_MODE_4K
+ TRANSMISSION_MODE_4K,
+ TRANSMISSION_MODE_1K,
+ TRANSMISSION_MODE_16K,
+ TRANSMISSION_MODE_32K,
} fe_transmit_mode_t;
typedef enum fe_bandwidth {
BANDWIDTH_8_MHZ,
BANDWIDTH_7_MHZ,
BANDWIDTH_6_MHZ,
- BANDWIDTH_AUTO
+ BANDWIDTH_AUTO,
+ BANDWIDTH_5_MHZ,
+ BANDWIDTH_10_MHZ,
+ BANDWIDTH_1_712_MHZ,
} fe_bandwidth_t;
@@ -191,7 +197,10 @@ typedef enum fe_guard_interval {
GUARD_INTERVAL_1_16,
GUARD_INTERVAL_1_8,
GUARD_INTERVAL_1_4,
- GUARD_INTERVAL_AUTO
+ GUARD_INTERVAL_AUTO,
+ GUARD_INTERVAL_1_128,
+ GUARD_INTERVAL_19_128,
+ GUARD_INTERVAL_19_256,
} fe_guard_interval_t;
@@ -305,7 +314,9 @@ struct dvb_frontend_event {
#define DTV_ISDBS_TS_ID42
-#define DTV_MAX_COMMANDDTV_ISDBS_TS_ID
+#define DTV_DVBT2_PLP_ID 43
+
+#define DTV_MAX_COMMANDDTV_DVBT2_PLP_ID
typedef enum fe_pilot {
PILOT_ON,
@@ -337,6 +348,7 @@ typedef enum fe_delivery_system {
SYS_DMBTH,
SYS_CMMB,
SYS_DAB,
+ SYS_DVBT2,
} fe_delivery_system_t;
struct dtv_cmds_h {
diff --git a/include/linux/dvb/version.h b/include/linux/dvb/version.h
index 5a7546c..1421cc8 100644
--- a/include/linux/dvb/version.h
+++ b/include/linux/dvb/version.h
@@ -24,6 +24,6 @@
#define _DVBVERSION_H_
#define DVB_API_VERSION 5
-#define DVB_API_VERSION_MINOR 2
+#define DVB_API_VERSION_MINOR 3
#endif /*_DVBVERSION_H_*/
--
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 00/10] rc-core: my current patchqueue
On Wed, 04 May 2011 12:13:49 -0300, Mauro Carvalho Chehab
wrote:
> Em 29-04-2011 05:08, David Härdeman escreveu:
>> diff --git a/drivers/media/rc/keymaps/rc-videomate-s350.c
>> b/drivers/media/rc/keymaps/rc-videomate-s350.c
>> index 26ca260..2f0ec1f 100644
>> --- a/drivers/media/rc/keymaps/rc-videomate-s350.c
>> +++ b/drivers/media/rc/keymaps/rc-videomate-s350.c
>> @@ -13,57 +13,56 @@
>> #include
>>
>> static struct rc_map_table videomate_s350[] = {
>> -{ 0x00, KEY_TV},
...
>> +{ RC_TYPE_UNKNOWN, RC_SCANCODE_UNKNOWN(0x00), KEY_TV},
>> };
> However, changes like the above makes the keymaps confusing and breaks
the
> v4l-utils sync scripts without a good reason.
First of all, I've missed that there are v4l-utils sync scripts.
Second of all, I think you can ignore this patch for now. It's actually a
much better idea to keep the rc_map and rc_map_table structs the way they
are (thereby reducing the patch size) and introduce new structs to be used
in rc_dev for maintaining the actual live keytable (and store the
protocol for each scancode in the new struct instead).
That way drivers/media/rc/keymaps/ won't see so much churn.
--
David Härdeman
--
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] OMAP3: ISP: Fix unbalanced use of omap3isp_get().
Hi Laurent, > This won't work. Let's assume the following sequence of events: > > - Userspace opens the sensor subdev device node > - The sensor driver calls to board code to turn the sensor clock on > - Board code calls to the ISP driver to turn XCLK on > - The ISP driver calls isp_enable_clocks() > ... > - Userspace opens an ISP video device node > - The ISP driver calls isp_get(), incrementing the reference count > - Userspace closes the ISP video device node > - The ISP driver calls isp_put(), decrementing the reference count > - The reference count reaches 0, the ISP driver calls isp_disable_clocks() > > The sensor will then loose its clock, even though the sensor subdev device > node is still opened. Of course, you are right, I hadn't thought of it this way. > Could you please explain why the existing code doesn't work on your hardware ? Apparently, it is a mistake related to the sensor driver. Sorry about that. Just one question. As I can see from mt9v032 driver, open callback is used to enable clock and close callback is used to disable clock. Does this mean that if sensor device node is not held open video won't work? i.e, the following wouldn't work since (2) opens the sensor (enables clock) and closes it again (disables clock) and (3) only opens CCDC device node (enables clock with a wrong setting, since it was previously set to 0 by (2) ) : (1) ./media-ctl -r -l '"mt9p031 2-0048":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP CCDC":1->"OMAP3 ISP CCDC output":0[1]' (2) ./media-ctl -f '"mt9p031 2-0048":0[SGRBG8 320x240], "OMAP3 ISP CCDC":1[SGRBG8 320x240]' (3) ./yavta -f SGRBG8 -s 320x240 -n 4 --capture=100 --skip 3 -F `./media-ctl -e "OMAP3 ISP CCDC output" -- 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: [git:v4l-dvb/for_v2.6.40] [media] Sony CXD2820R DVB-T/T2/C demodulator driver
Hi Andreas,
>From cxd2820r_priv.h:
> +/*
> + * FIXME: These are totally wrong and must be added properly to the API.
> + * Only temporary solution in order to get driver compile.
> + */
> +#define SYS_DVBT2 SYS_DAB
> +#define TRANSMISSION_MODE_1K 0
> +#define TRANSMISSION_MODE_16K 0
> +#define TRANSMISSION_MODE_32K 0
> +#define GUARD_INTERVAL_1_128 0
> +#define GUARD_INTERVAL_19_128 0
> +#define GUARD_INTERVAL_19_256 0
I believe Antti didn't want to make frontent.h changes until a consensus
was reached on how to develop the API for T2 support.
Regards,
--
Steve Kerrison MEng Hons.
http://www.stevekerrison.com/
On Fri, 2011-05-06 at 12:01 +0200, Andreas Oberritter wrote:
> On 05/05/2011 12:53 PM, Mauro Carvalho Chehab wrote:
> > + switch (priv->delivery_system) {
> > + case SYS_UNDEFINED:
> > + if (c->delivery_system == SYS_DVBT) {
> > + /* SLEEP => DVB-T */
> > + ret = cxd2820r_set_frontend_t(fe, p);
> > + } else {
> > + /* SLEEP => DVB-T2 */
> > + ret = cxd2820r_set_frontend_t2(fe, p);
> > + }
> > + break;
> > + case SYS_DVBT:
> > + if (c->delivery_system == SYS_DVBT) {
> > + /* DVB-T => DVB-T */
> > + ret = cxd2820r_set_frontend_t(fe, p);
> > + } else if (c->delivery_system == SYS_DVBT2) {
> > + /* DVB-T => DVB-T2 */
> > + ret = cxd2820r_sleep_t(fe);
> > + ret = cxd2820r_set_frontend_t2(fe, p);
> > + }
> > + break;
> > + case SYS_DVBT2:
> > + if (c->delivery_system == SYS_DVBT2) {
>
> Is this driver compilable? I don't see the necessary changes to
> linux/dvb/frontend.h to add SYS_DVBT2 in your tree.
>
> See below for a patch that I used for testing DVB-T2 internally.
>
> Regards,
> Andreas
>
> --
> commit e89f95641f29b7a4457e7a68649f4374933e36a2
> Author: Andreas Oberritter
> Date: Mon Mar 15 14:43:52 2010 +0100
>
> DVB: Add basic API support for DVB-T2 and bump minor version
>
> Signed-off-by: Andreas Oberritter
>
> diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c
> b/drivers/media/dvb/dvb-core/dvb_frontend.c
> index f5016ae..6f06efe 100644
> --- a/drivers/media/dvb/dvb-core/dvb_frontend.c
> +++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
> @@ -1141,10 +1141,9 @@ static void dtv_property_adv_params_sync(struct
> dvb_frontend *fe)
> break;
> }
>
> - if(c->delivery_system == SYS_ISDBT) {
> - /* Fake out a generic DVB-T request so we pass validation in
> the ioctl */
> - p->frequency = c->frequency;
> - p->inversion = c->inversion;
> + /* 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)) {
> p->u.ofdm.constellation = QAM_AUTO;
> p->u.ofdm.code_rate_HP = FEC_AUTO;
> p->u.ofdm.code_rate_LP = FEC_AUTO;
> diff --git a/include/linux/dvb/frontend.h b/include/linux/dvb/frontend.h
> index 493a2bf..36a3ed6 100644
> --- a/include/linux/dvb/frontend.h
> +++ b/include/linux/dvb/frontend.h
> @@ -175,14 +175,20 @@ typedef enum fe_transmit_mode {
> TRANSMISSION_MODE_2K,
> TRANSMISSION_MODE_8K,
> TRANSMISSION_MODE_AUTO,
> - TRANSMISSION_MODE_4K
> + TRANSMISSION_MODE_4K,
> + TRANSMISSION_MODE_1K,
> + TRANSMISSION_MODE_16K,
> + TRANSMISSION_MODE_32K,
> } fe_transmit_mode_t;
>
> typedef enum fe_bandwidth {
> BANDWIDTH_8_MHZ,
> BANDWIDTH_7_MHZ,
> BANDWIDTH_6_MHZ,
> - BANDWIDTH_AUTO
> + BANDWIDTH_AUTO,
> + BANDWIDTH_5_MHZ,
> + BANDWIDTH_10_MHZ,
> + BANDWIDTH_1_712_MHZ,
> } fe_bandwidth_t;
>
>
> @@ -191,7 +197,10 @@ typedef enum fe_guard_interval {
> GUARD_INTERVAL_1_16,
> GUARD_INTERVAL_1_8,
> GUARD_INTERVAL_1_4,
> - GUARD_INTERVAL_AUTO
> + GUARD_INTERVAL_AUTO,
> + GUARD_INTERVAL_1_128,
> + GUARD_INTERVAL_19_128,
> + GUARD_INTERVAL_19_256,
> } fe_guard_interval_t;
>
>
> @@ -305,7 +314,9 @@ struct dvb_frontend_event {
>
> #define DTV_ISDBS_TS_ID 42
>
> -#define DTV_MAX_COMMAND DTV_ISDBS_TS_ID
> +#define DTV_DVBT2_PLP_ID 43
> +
> +#define DTV_MAX_COMMAND DTV_DVBT2_PLP_ID
>
> typedef enum fe_pilot {
> PILOT_ON,
> @@ -337,6 +348,7 @@ typedef enum fe_delivery_system {
> SYS_DMBTH,
> SYS_CMMB,
> SYS_DAB,
> + SYS_DVBT2,
> } fe_delivery_system_t;
>
> struct dtv_cmds_h {
> diff --git a/include/linux/dvb/version.h b/include/linux/dvb/version.h
> index 5a7546c..1421cc8 100644
> --- a/include/linu
Re: multiple delivery systems in one device
On 05/05/2011 12:21 PM, Ralph Metzler wrote: > Hi, > > since it seems devices with several delivery systems can be queried > with one command: > > Andreas Oberritter writes: > > > Of course it does since it is not feasible to use the same adapter > > > number even on the same card when it provides multi-standard > > > frontends which share dvr and demux devices. E.g., frontend0 and > > > frontend1 can belong to the same demod which can be DVB-C and -T > > > (or other combinations, some demods can even do DVB-C/T/S2). > > > > There's absolutely no need to have more than one frontend device per > > demod. Just add two commands, one to query the possible delivery systems > > and one to switch the system. Why would you need more than one device > > node at all, if you can only use one delivery system at a time? > > can somebody tell me how this is done and how it has to be supported > in the demod driver? Such commands don't exist yet and therefore need to be added as required. For the Dreambox, we're currently using a proprietary interface to switch between C and T, when the frontend is closed. For an implementation within the bounds of the API, the device must not be closed. Hence, I'd propose something like the following: - In the driver, implement the set_property callback. For the property DTV_DELIVERY_SYSTEM, do whatever is required to change the delivery system if required, e.g.: - Add and call a function to pause the frontend thread. - Call fe->ops->sleep(fe) et al. (c.f. dvb_powerdown_on_sleep). - Set fe->ops to the new struct dvb_frontend_ops pointer. - Call dvb_frontend_reinitialise(fe); - Fix dvb_frontend_thread() to not call ops.set_voltage and ops.set_tone unless non-null. - Add an S2API property DTV_DELIVERY_SYSTEMS which can be used to query the available delivery systems. - Add a default 'get_property' implementation to dvb_frontend.c: - tvp->u.buffer.data[0] = c->delivery_system; tvp->u.buffer.len = 1; - Implement ops.get_property in the driver, e.g.: tvp->u.buffer.data[0] = SYS_DVBC_ANNEX_AC; tvp->u.buffer.data[1] = SYS_DVBT; tvp->u.buffer.data[2] = SYS_DVBT2; tvp->u.buffer.len = 3; - Increment minor API version. Regards, Andreas -- 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 08/10] rc-core: merge rc5 and streamzap decoders
On Wed, 04 May 2011 12:19:12 -0300, Mauro Carvalho Chehab wrote: > Em 28-04-2011 12:13, David Härdeman escreveu: >> Now that the protocol is part of the scancode, it is pretty easy to merge >> the rc5 and streamzap decoders. An additional advantage is that the >> decoder >> is now stricter as it waits for the trailing silence before determining >> that >> a command is a valid rc5/streamzap command (which avoids collisions that >> I've >> seen with e.g. Sony protocols). > > Makes sense for me. > > (FYI, I probably won't be applying any patch after patch 6, due to > dependency issues). Feel free to ignore it for now, I'll include it in a refreshed patchset. -- David Härdeman -- 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] Ngene cam device name
On 05/05/2011 04:43 PM, Martin Vidovic wrote: > Hi, > > Broadly speaking, I could put issues discussed in this thread into > following categories: > > - How devices are named; > - How devices are used; > - How devices relate to one another; > - How devices are enumerated; > - How devices are described; > > Mostly we discuss category 1 and 2 with relation to nGENE CI, but > sometimes we leap to other categories as well. > > Andreas Oberritter wrote: >> On 05/04/2011 03:35 PM, Martin Vidovic wrote: >>> >>> I think there is currently no useful API to connect devices. Every few >>> months there comes a new device which deprecates how I enumerate devices >>> and determine types of FE's. >> >> Can you describe the most common problems? What do you mean by >> connecting? > > What I mean by connecting devices falls into last 3 categories (above). > I brought this up because I don't believe this is the actual problem we > need to solve here since it's not nGENE specific. > > Some examples of problems in categories 3-5: > > a) Plug two TerraTec Cinergy T RC MKII and try to distinguish between them. I don't have any USB or PCI hardware within reach, but if udev is able to create the devices, there should be some way to connect adapters to the bus id through sysfs. I guess that's how it's done with other subsystems, too. If this information is missing from sysfs, would adding it help to solve this problem? > b) Take a Hybrid terrestrial TV tuner. V4L and DVB APIs (may) use shared > resources, how does one find this out? That's a good question and the same question must be asked for video and audio decoders, which can be controlled by V4L, DVB, ALSA etc. How does V4L integrate with ALSA? > c.1) How does one know which frontend device can be used with which > demux device? I'd say by default (i.e. without DMX_SET_SOURCE, whether implemented or not) frontendX is connected to demuxX on the same adapter. You have probably faced other situations. Can you describe any? > c.2) Which CA device can be used with which frontend device? For built-in descramblers, I'd say each caX is always connected to (built into) demuxX. For CI slots, this might be different and on the Dreambox we're using a proprietary API to connect CI slots between frontends and demuxes. Is there any in-tree supported hardware, that has more than one CI slot *and* more than one frontend (usable at the same time)? I agree that an API would be nice to query and set up such things, but I had expected that the need for it was rather low for non-embedded systems. > d) How does one list all supported delivery systems for a device > (FE_GET_INFO is not general, and DTV_DELIVERY_SYSTEM can't be used to > query available delivery systems). How about this proposal? http://www.mail-archive.com/linux-media@vger.kernel.org/msg31124.html > e) the list could be extended... > > These problems are mostly not fatal, they have workarounds. Some of them > require device/driver specific knowledge. > >>> The most useful way to query devices seems to be using HAL, and I think >>> this is the correct way in Linux, but DVB-API may be lacking with >>> providing the necessary information. Maybe this is the direction we >>> should consider? Device names under /dev seem to be irrelevant nowadays. >> >> I think in the long run we should look closely at how V4L2 is solving >> similar problems. > > The best would be to create independent adapters for each independent CA > device (ca0/caio0 pair) - they are independent after all (physically and > in the way they're used). Physically, it's a general purpose TS I/O interface of the nGene chipset. It just happens to be connected to a CI slot. On another board, it might be connected to a modulator or just to some kind of socket. If the next version gets a connector for two switchable CI modules, then the physical independence is gone. You'd have two ca nodes but only one caio node. Or two caio nodes, that can't be used concurrently. Maybe the next version gets the ability to directly connect the TS input from the frontend to the TS output to the CI slot to save copying around the data, by using some kind of pin mux. Not physically independent either. It just looks physically independent in the one configuration implemented now. > What I understand you would like to see, is the ability to do direct > transfers between independent devices or parts of devices. Is this correct? Yes, between parts of devices, where the CI input can be fed by both the TS output of the frontend and from memory (e.g. userspace). Although it would be nice to have DMA transfers between independent devices, that's a different topic. Regards, Andreas -- 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 05/10] rc-core: add separate defines for protocol bitmaps and numbers
On Wed, 04 May 2011 11:56:17 -0300, Mauro Carvalho Chehab
wrote:
> Em 28-04-2011 12:13, David Härdeman escreveu:
>> The RC_TYPE_* defines are currently used both where a single protocol
is
>> expected and where a bitmap of protocols is expected. This patch tries
>> to separate the two in preparation for the following patches.
>>
>> Signed-off-by: David Härdeman
>
> Most of the patch is just renaming stuff. So, I'm commenting just the
> rc-main.c/rc-map.h changes.
>
>> diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
>> index 5b4422e..5a182b2 100644
>> --- a/drivers/media/rc/rc-main.c
>> +++ b/drivers/media/rc/rc-main.c
>> @@ -102,7 +102,7 @@ static struct rc_map_list empty_map = {
>> .map = {
>> .scan= empty,
>> .size= ARRAY_SIZE(empty),
>> -.rc_type = RC_TYPE_UNKNOWN, /* Legacy IR type */
>> +.rc_type = RC_BIT_UNKNOWN, /* Legacy IR type */
>> .name= RC_MAP_EMPTY,
>> }
>> };
>> @@ -725,14 +725,17 @@ static struct {
>> u64 type;
>> char*name;
>> } proto_names[] = {
>> -{ RC_TYPE_UNKNOWN, "unknown" },
>> -{ RC_TYPE_RC5, "rc-5" },
>> -{ RC_TYPE_NEC, "nec" },
>> -{ RC_TYPE_RC6, "rc-6" },
>> -{ RC_TYPE_JVC, "jvc" },
>> -{ RC_TYPE_SONY, "sony" },
>> -{ RC_TYPE_RC5_SZ, "rc-5-sz" },
>> -{ RC_TYPE_LIRC, "lirc" },
>> +{ RC_BIT_OTHER, "other" },
>> +{ RC_BIT_RC5, "rc-5" },
>> +{ RC_BIT_RC5X, "rc-5-x"},
>> +{ RC_BIT_RC5_SZ,"rc-5-sz" },
>> +{ RC_BIT_RC6, "rc-6" },
>> +{ RC_BIT_JVC, "jvc" },
>> +{ RC_BIT_SONY12,"sony12"},
>> +{ RC_BIT_SONY15,"sony15"},
>> +{ RC_BIT_SONY20,"sony20"},
>> +{ RC_BIT_NEC, "nec" },
>> +{ RC_BIT_LIRC, "lirc" },
>> };
>
> There are some API breakages on the above. We shouln't do it, except
> if strictly required, and, if we'll do it, we need to do it via
> Documentation/feature-removal-schedule.txt.
>
> There are two types of breakages on the above:
> 1) the removal of "unknown" and "sony" types;
We could just keep "unknown" and (optionally) also map "other" to it.
> 2) the behaviour change of "rc-5" (that, currently, means
> both rc-5 and rc-5x.
That's a change but I don't think it'll actually break user-space
since "rc-5" will still be accepted.
> Also, while you've mapped rc5/sony variants, nec variants weren't
mapped.
"nec" needs no mapping with the nec 32-bit scancode change.
> IMO, what we should do on the above is:
> 1) preserve the "unknown";
>
> 2) use "rc-5", "sony", "nec" with the meaning that they will
> enable all variants of those protocols;
>
> 3) add a new set of protocols to indicate subsets, like "sony:20",
> "rc-5:normal", "rc5:x", etc.
I can look into it...
> 4) if you're changing the interface, please submit a patch also
> to v4l-utils, adding a logic there to handle the changes.
I'll look into it when redoing the patches.
>>
>> #define PROTO_NONE "none"
>> diff --git a/include/media/rc-map.h b/include/media/rc-map.h
>> index 9184751..2c68ca6 100644
>> --- a/include/media/rc-map.h
>> +++ b/include/media/rc-map.h
>> @@ -11,19 +11,36 @@
>>
>> #include
>>
>> -#define RC_TYPE_UNKNOWN 0
>> -#define RC_TYPE_RC5 (1 << 0) /* Philips RC5 protocol */
>> -#define RC_TYPE_NEC (1 << 1)
>> -#define RC_TYPE_RC6 (1 << 2) /* Philips RC6 protocol */
>> -#define RC_TYPE_JVC (1 << 3) /* JVC protocol */
>> -#define RC_TYPE_SONY(1 << 4) /* Sony12/15/20 protocol */
>> -#define RC_TYPE_RC5_SZ (1 << 5) /* RC5 variant used by
>> Streamzap */
>> -#define RC_TYPE_LIRC(1 << 30) /* Pass raw IR to lirc
>> userspace */
>> -#define RC_TYPE_OTHER (1u << 31)
>
>> +#define RC_TYPE_UNKNOWN 0 /* Protocol not known */
>> +#define RC_TYPE_OTHER 0 /* Protocol known but
>> proprietary */
>
> This change doesn't make sense: we should either remove other or use
> different bits for different meanings.
I think that it's not necessary. Unknown and other have a
meaningful difference to the programmer but not from a code
point of view. Both mean that whatever scancode we get, we
have to accept as-is and we don't know anything about it.
For e.g. a RC5 scancode we could (though we're not doing it yet)
do sanity-checks on the scancode and set a proper timeout value
based on protocol characteristics. With other and unknown we can't.
That's the reason I merged them - we can't do anything meaningful
with the difference from a code point of view and long term
"unknown" should die (might not happen but...).
> This i
Re: [git:v4l-dvb/for_v2.6.40] [media] Sony CXD2820R DVB-T/T2/C demodulator driver
Em 06-05-2011 07:42, Steve Kerrison escreveu: > Hi Andreas, > > From cxd2820r_priv.h: > >> +/* >> + * FIXME: These are totally wrong and must be added properly to the API. >> + * Only temporary solution in order to get driver compile. >> + */ >> +#define SYS_DVBT2 SYS_DAB >> +#define TRANSMISSION_MODE_1K 0 >> +#define TRANSMISSION_MODE_16K 0 >> +#define TRANSMISSION_MODE_32K 0 >> +#define GUARD_INTERVAL_1_128 0 >> +#define GUARD_INTERVAL_19_128 0 >> +#define GUARD_INTERVAL_19_256 0 > > > I believe Antti didn't want to make frontent.h changes until a consensus > was reached on how to develop the API for T2 support. Yeah. Andreas/Antti, It seems more appropriate to remove the above hack and add Andreas patch. I've reviewed it and it seemed ok on my eyes, provided that we also update DVB specs to reflect the changes. In special, the new DVB command should be documented: +#define DTV_DVBT2_PLP_ID 43 Thanks, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git:v4l-dvb/for_v2.6.40] [media] Sony CXD2820R DVB-T/T2/C demodulator driver
On 05/06/2011 02:23 PM, Mauro Carvalho Chehab wrote: > Em 06-05-2011 07:42, Steve Kerrison escreveu: >> Hi Andreas, >> >> From cxd2820r_priv.h: >> >>> +/* >>> + * FIXME: These are totally wrong and must be added properly to the API. >>> + * Only temporary solution in order to get driver compile. >>> + */ >>> +#define SYS_DVBT2 SYS_DAB >>> +#define TRANSMISSION_MODE_1K 0 >>> +#define TRANSMISSION_MODE_16K 0 >>> +#define TRANSMISSION_MODE_32K 0 >>> +#define GUARD_INTERVAL_1_128 0 >>> +#define GUARD_INTERVAL_19_128 0 >>> +#define GUARD_INTERVAL_19_256 0 >> >> >> I believe Antti didn't want to make frontent.h changes until a consensus >> was reached on how to develop the API for T2 support. > > Yeah. > > Andreas/Antti, > > It seems more appropriate to remove the above hack and add Andreas patch. > I've reviewed it and it seemed ok on my eyes, provided that we also update > DVB specs to reflect the changes. > > In special, the new DVB command should be documented: > +#define DTV_DVBT2_PLP_ID 43 In addition to the patch, the PLP ID needs to be stored in struct dtv_frontend_properties and used by property cache functions in dvb_frontend.c. Antti, could you please complete the patch and test it with your device? This patch was adapted from an older kernel and only compile-tested few weeks ago. Regards, Andreas -- 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] mt9v022: fix pixel clock
Hello Guennadi, Am Mittwoch, den 04.05.2011, 10:17 +0200 schrieb Guennadi Liakhovetski: > Hi Teresa > > I'm adding Mauro to CC, because we were discussing adding these (this one > and mt9m111) patches to .39. > > On Thu, 14 Apr 2011, Teresa Gámez wrote: > > > The setup of the pixel clock is done wrong in the mt9v022 driver. > > The 'Invert Pixel Clock' bit has to be set to 1 for falling edge > > and not for rising. This is not clearly described in the data > > sheet. > > I finally got round to test your patch on pcm037. But sorry, I cannot > reproduce your success. What's even worth, your patch, if applied to the > stock kernel, really messes up Bayer colours for me. With your patch alone > I cannot select the Bayer filter starting pixel parameter to produce > correct colours. Without your patch colours do not look very clean, that's > true, but I always attributed it to some sensor fine-tuning issues. But at > least they are correct. Thank you for testing this. Of course the Bayer to RGB conversion can have a impact on the test result. To avoid this, it might be better to first try out the test pattern generated by the color or monochrom mtv9v022 sensor. With the test pattern no Bayer conversion should be made. Our setup in the i.MX31 controller: * Reg 0x53FC_0060 (CSI_SENS_CONF), Bit 3 (SENS_PIX_CLK_POL) = 0 pixel clock is directly applied to internal circuitry (rising edge). Which means its using rising edge (See Datasheet mcimx31 Rev3.4 10/2007 i.MX31): The timing specifications are referenced to the rising edge of SENS_PIX_CLK when the SENS_PIX_CLK_POL bit in the CSI_SENS_CONF register is cleared. When the SENS_PIX_CLK_POL is set, the clock is inverted and all timing specifications will remain the same but are referenced to the falling edge of the clock. * The MCLOCK is setup with 20MHz Setup of the camera sensor mt9v022: * Reg 0x74 Bit 4 = 0# Pixelclock at rising edge * Reg 0x7F= 0x2800 # generates vertical shade * Reg 0x70 Bit 5 = 0# disable noise correction (is nessessary for correct testpattern) Our result: test pattern verical is ok Now changed setup to: * Reg 0x74 Bit 4 = 1# Pixelclock at falling edge Our result: test pattern has errors on a closer look. We have tested this with PCM037/PCM970 on a 2.6.39-rc6. Teresa > An easy way to test colours is to point the camera > at the LED pair on the board - blinking red and constant green next to the > ethernet port. You once mentioned, that in your BSP you have the > SOCAM_SENSOR_INVERT_PCLK flag set in your platform data. Maybe you were > testing with that one? Then yes, of course, you'd have to compensate it by > inverting the bit in the sensor. In any case, your patch if applied alone, > seems to break camera on pcm037. Am I missing something? > > Thanks > Guennadi > > > > > Tested on pcm037 and pcm027/pcm990. > > > > Signed-off-by: Teresa Gámez > > --- > > drivers/media/video/mt9v022.c |2 +- > > 1 files changed, 1 insertions(+), 1 deletions(-) > > > > diff --git a/drivers/media/video/mt9v022.c b/drivers/media/video/mt9v022.c > > index 6a784c8..dec2a69 100644 > > --- a/drivers/media/video/mt9v022.c > > +++ b/drivers/media/video/mt9v022.c > > @@ -228,7 +228,7 @@ static int mt9v022_set_bus_param(struct > > soc_camera_device *icd, > > > > flags = soc_camera_apply_sensor_flags(icl, flags); > > > > - if (flags & SOCAM_PCLK_SAMPLE_RISING) > > + if (flags & SOCAM_PCLK_SAMPLE_FALLING) > > pixclk |= 0x10; > > > > if (!(flags & SOCAM_HSYNC_ACTIVE_HIGH)) > > -- > > 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: [git:v4l-dvb/for_v2.6.40] [media] Sony CXD2820R DVB-T/T2/C demodulator driver
Steve or Andreas can do it. I am now on holiday weekend, snowboarding maybe last time for this season :) I cannot do much until next week. All help is welcome! Antti -- http://palosaari.fi/ - Original message - > If antti doesn't do this before me, I will look at this over the weekend > and generate a patch against antti's current code... if that's > appropriate of course (I'm new at this ;)) > > Regards, > Steve Kerrison. > > - Reply message - > From: "Andreas Oberritter" > Date: Fri, May 6, 2011 13:36 > Subject: [git:v4l-dvb/for_v2.6.40] [media] Sony CXD2820R DVB-T/T2/C > demodulator driver To: "Mauro Carvalho Chehab" > Cc: "Steve Kerrison" , > , "Antti Palosaari" > > > On 05/06/2011 02:23 PM, Mauro Carvalho Chehab wrote: > > Em 06-05-2011 07:42, Steve Kerrison escreveu: > > > Hi Andreas, > > > > > > From cxd2820r_priv.h: > > > > > > > +/* > > > > + * FIXME: These are totally wrong and must be added properly to > > > > the API. + * Only temporary solution in order to get driver > > > > compile. + */ > > > > +#define SYS_DVBT2 SYS_DAB > > > > +#define TRANSMISSION_MODE_1K 0 > > > > +#define TRANSMISSION_MODE_16K 0 > > > > +#define TRANSMISSION_MODE_32K 0 > > > > +#define GUARD_INTERVAL_1_128 0 > > > > +#define GUARD_INTERVAL_19_128 0 > > > > +#define GUARD_INTERVAL_19_256 0 > > > > > > > > > I believe Antti didn't want to make frontent.h changes until a > > > consensus was reached on how to develop the API for T2 support. > > > > Yeah. > > > > Andreas/Antti, > > > > It seems more appropriate to remove the above hack and add Andreas > > patch. I've reviewed it and it seemed ok on my eyes, provided that we > > also update DVB specs to reflect the changes. > > > > In special, the new DVB command should be documented: > > +#define DTV_DVBT2_PLP_ID 43 > > In addition to the patch, the PLP ID needs to be stored in struct > dtv_frontend_properties and used by property cache functions in > dvb_frontend.c. > > Antti, could you please complete the patch and test it with your device? > This patch was adapted from an older kernel and only compile-tested few > weeks ago. > > Regards, > Andreas > -- > 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: [PATCH] Ngene cam device name
From: Andreas Oberritter > > The best would be to create independent adapters for each independent CA > > device (ca0/caio0 pair) - they are independent after all (physically and > > in the way they're used). > > Physically, it's a general purpose TS I/O interface of the nGene > chipset. It just happens to be connected to a CI slot. On another board, > it might be connected to a modulator or just to some kind of socket. > > If the next version gets a connector for two switchable CI modules, then > the physical independence is gone. You'd have two ca nodes but only one > caio node. Or two caio nodes, that can't be used concurrently. > > Maybe the next version gets the ability to directly connect the TS input > from the frontend to the TS output to the CI slot to save copying around > the data, by using some kind of pin mux. Not physically independent either. > > It just looks physically independent in the one configuration > implemented now. When I read the cxd2099ar datasheet, I can see that in dual slot configuration, there is still one communication channel for the TS and one for the control. Also, it seems linux en50221 stack provides for the slot selection. So, why would you need two ca nodes ? -- 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] Ngene cam device name
Hi, On Fri, 06 May 2011 14:17:11 +0200, Andreas Oberritter wrote: > On 05/05/2011 04:43 PM, Martin Vidovic wrote: >> Hi, >> >> Broadly speaking, I could put issues discussed in this thread into >> following categories: >> >> - How devices are named; >> - How devices are used; >> - How devices relate to one another; >> - How devices are enumerated; >> - How devices are described; >> >> Mostly we discuss category 1 and 2 with relation to nGENE CI, but >> sometimes we leap to other categories as well. >> I must say I really like this discussion so far. But for me to keep focus: Can someone list different options for naming/using/relating/enumerating/describing devices in relation to (multiple?ngene?) CI's. Or does that information already exist? Walter -- 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] mt9v022: fix pixel clock
Hello Teresa, On Fri, 6 May 2011, Teresa Gamez wrote: > Hello Guennadi, > > Am Mittwoch, den 04.05.2011, 10:17 +0200 schrieb Guennadi Liakhovetski: > > Hi Teresa > > > > I'm adding Mauro to CC, because we were discussing adding these (this one > > and mt9m111) patches to .39. > > > > On Thu, 14 Apr 2011, Teresa Gámez wrote: > > > > > The setup of the pixel clock is done wrong in the mt9v022 driver. > > > The 'Invert Pixel Clock' bit has to be set to 1 for falling edge > > > and not for rising. This is not clearly described in the data > > > sheet. > > > > I finally got round to test your patch on pcm037. But sorry, I cannot > > reproduce your success. What's even worth, your patch, if applied to the > > stock kernel, really messes up Bayer colours for me. With your patch alone > > I cannot select the Bayer filter starting pixel parameter to produce > > correct colours. Without your patch colours do not look very clean, that's > > true, but I always attributed it to some sensor fine-tuning issues. But at > > least they are correct. > > Thank you for testing this. Np, sorry, I only now came round to doing this, but as this is going to be a fix, it should be even possible to push it after .39 for stable. > Of course the Bayer to RGB conversion can have a impact on the test result. > > To avoid this, it might be better to first try out the test pattern > generated by the color or monochrom mtv9v022 sensor. With the test > pattern no Bayer conversion should be made. Yes, could try this. But there really seems to be a difference between our boards. If this turns out to be the case, we'll have to distinguish between the two board versions in the platform data and use the inverter flag for one of them. > Our setup in the i.MX31 controller: > * Reg 0x53FC_0060 (CSI_SENS_CONF), Bit 3 (SENS_PIX_CLK_POL) = 0 > pixel clock is directly applied to internal circuitry > (rising edge). > > Which means its using rising edge (See Datasheet mcimx31 Rev3.4 10/2007 > i.MX31): > The timing specifications are referenced to the rising > edge of SENS_PIX_CLK when the SENS_PIX_CLK_POL bit in the > CSI_SENS_CONF register is cleared. When the SENS_PIX_CLK_POL > is set, the clock is inverted and all timing specifications > will remain the same but are referenced to the falling edge of > the clock. > > * The MCLOCK is setup with 20MHz > > Setup of the camera sensor mt9v022: > * Reg 0x74 Bit 4 = 0 # Pixelclock at rising edge > * Reg 0x7F= 0x2800 # generates vertical shade > * Reg 0x70 Bit 5 = 0# disable noise correction > (is nessessary for correct testpattern) > > Our result: test pattern verical is ok > > Now changed setup to: > * Reg 0x74 Bit 4 = 1 # Pixelclock at falling edge > > Our result: test pattern has errors on a closer look. > > We have tested this with PCM037/PCM970 on a 2.6.39-rc6. Thanks for the data. There is an even better way to verify this: set bit 10 of the 0x7f register and write a specific value in bits [9-0], then you should be getting exactly this value in your video buffers. Thanks Guennadi > > Teresa > > > An easy way to test colours is to point the camera > > at the LED pair on the board - blinking red and constant green next to the > > ethernet port. You once mentioned, that in your BSP you have the > > SOCAM_SENSOR_INVERT_PCLK flag set in your platform data. Maybe you were > > testing with that one? Then yes, of course, you'd have to compensate it by > > inverting the bit in the sensor. In any case, your patch if applied alone, > > seems to break camera on pcm037. Am I missing something? > > > > Thanks > > Guennadi > > > > > > > > Tested on pcm037 and pcm027/pcm990. > > > > > > Signed-off-by: Teresa Gámez > > > --- > > > drivers/media/video/mt9v022.c |2 +- > > > 1 files changed, 1 insertions(+), 1 deletions(-) > > > > > > diff --git a/drivers/media/video/mt9v022.c b/drivers/media/video/mt9v022.c > > > index 6a784c8..dec2a69 100644 > > > --- a/drivers/media/video/mt9v022.c > > > +++ b/drivers/media/video/mt9v022.c > > > @@ -228,7 +228,7 @@ static int mt9v022_set_bus_param(struct > > > soc_camera_device *icd, > > > > > > flags = soc_camera_apply_sensor_flags(icl, flags); > > > > > > - if (flags & SOCAM_PCLK_SAMPLE_RISING) > > > + if (flags & SOCAM_PCLK_SAMPLE_FALLING) > > > pixclk |= 0x10; > > > > > > if (!(flags & SOCAM_HSYNC_ACTIVE_HIGH)) > > > -- > > > 1.7.0.4 > > > > > > > --- > > Guennadi Liakhovetski, Ph.D. > > Freelance Open-Source Software Developer > > http://www.open-technology.de/ > > --- 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
Pinnacle PCTV Stick not working MINT 9
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 007: ID eb1a:2870 eMPIA Technology, Inc. Pinnacle PCTV Stick Bus 001 Device 005: ID 045e:0040 Microsoft Corp. Wheel Mouse Optical Bus 001 Device 004: ID 046d:c317 Logitech, Inc. Bus 001 Device 003: ID 046d:080f Logitech, Inc. Bus 001 Device 002: ID 0409:0058 NEC Corp. HighSpeed Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub [ 78.096885] em28xx: New device USB 2870 Device @ 480 Mbps (eb1a:2870, interface 0, class 0) [ 78.097078] em28xx #0: chip ID is em2870 [ 78.179682] em28xx #0: i2c eeprom 00: 1a eb 67 95 1a eb 70 28 c0 12 81 00 6a 22 00 00 [ 78.179694] em28xx #0: i2c eeprom 10: 00 00 04 57 02 0d 00 00 00 00 00 00 00 00 00 00 [ 78.179705] em28xx #0: i2c eeprom 20: 44 00 00 00 f0 10 02 00 00 00 00 00 5b 00 00 00 [ 78.179716] em28xx #0: i2c eeprom 30: 00 00 20 40 20 80 02 20 01 01 00 00 c8 8c 05 49 [ 78.179727] em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 78.179738] em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 78.179748] em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 22 03 55 00 53 00 [ 78.179759] em28xx #0: i2c eeprom 70: 42 00 20 00 32 00 38 00 37 00 30 00 20 00 44 00 [ 78.179770] em28xx #0: i2c eeprom 80: 65 00 76 00 69 00 63 00 65 00 00 00 00 00 00 00 [ 78.179780] em28xx #0: i2c eeprom 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 78.179791] em28xx #0: i2c eeprom a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 78.179802] em28xx #0: i2c eeprom b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 78.179812] em28xx #0: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 78.179823] em28xx #0: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 78.179834] em28xx #0: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 78.179844] em28xx #0: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 78.179857] em28xx #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0x539bbfc0 [ 78.179859] em28xx #0: EEPROM info: [ 78.179861] em28xx #0: No audio on board. [ 78.179863] em28xx #0: 500mA max power [ 78.179865] em28xx #0: Table at 0x04, strings=0x226a, 0x, 0x [ 78.182308] em28xx #0: Identified as Unknown EM2750/28xx video grabber (card=1) [ 78.212682] em28xx #0: found i2c device @ 0xa0 [eeprom] [ 78.218682] em28xx #0: found i2c device @ 0xc0 [tuner (analog)] [ 78.230309] em28xx #0: Your board has no unique USB ID and thus need a hint to be detected. [ 78.230314] em28xx #0: You may try to use card= insmod option to workaround that. [ 78.230317] em28xx #0: Please send an email with this log to: [ 78.230319] em28xx #0: V4L Mailing List [ 78.230321] em28xx #0: Board eeprom hash is 0x539bbfc0 [ 78.230324] em28xx #0: Board i2c devicelist hash is 0x4b800080 [ 78.230326] em28xx #0: Here is a list of valid choices for the card= insmod option: [ 78.230329] em28xx #0: card=0 -> Unknown EM2800 video grabber [ 78.230332] em28xx #0: card=1 -> Unknown EM2750/28xx video grabber [ 78.230335] em28xx #0: card=2 -> Terratec Cinergy 250 USB [ 78.230337] em28xx #0: card=3 -> Pinnacle PCTV USB 2 [ 78.230340] em28xx #0: card=4 -> Hauppauge WinTV USB 2 [ 78.230343] em28xx #0: card=5 -> MSI VOX USB 2.0 [ 78.230345] em28xx #0: card=6 -> Terratec Cinergy 200 USB [ 78.230348] em28xx #0: card=7 -> Leadtek Winfast USB II [ 78.230350] em28xx #0: card=8 -> Kworld USB2800 [ 78.230353] em28xx #0: card=9 -> Pinnacle Dazzle DVC 90/100/101/107 / Kaiser Baas Video to DVD maker / Kworld DVD Maker 2 [ 78.230356] em28xx #0: card=10 -> Hauppauge WinTV HVR 900 [ 78.230359] em28xx #0: card=11 -> Terratec Hybrid XS [ 78.230362] em28xx #0: card=12 -> Kworld PVR TV 2800 RF [ 78.230364] em28xx #0: card=13 -> Terratec Prodigy XS [ 78.230367] em28xx #0: card=14 -> SIIG AVTuner-PVR / Pixelview Prolink PlayTV USB 2.0 [ 78.230370] em28xx #0: card=15 -> V-Gear PocketTV [ 78.230372] em28xx #0: card=16 -> Hauppauge WinTV HVR 950 [ 78.230375] em28xx #0: card=17 -> Pinnacle PCTV HD Pro Stick [ 78.230378] em28xx #0: card=18 -> Hauppauge WinTV HVR 900 (R2) [ 78.230381] em28xx #0: card=19 -> EM2860/SAA711X Reference Design [ 78.230383] em28xx #0: card=20 -> AMD ATI TV Wonder HD 600 [ 78.230386] em28xx #0: card=21 -> eMPIA Technology, Inc. GrabBeeX+ Video Encoder [ 78.230389] em28xx #0: card=22 -> EM2710/EM2750/EM2751 webcam grabber [ 78.230392] em28xx #0: card=23 -> Huaqi DLCW-130 [ 78.230395] em28xx #0: card=24 -> D-Link DUB-T210 TV Tuner [ 78.230398] em28xx #0: card=25 -> Gadmei UTV310 [ 78.230400] em28xx #0: card=
Re: [git:v4l-dvb/for_v2.6.40] [media] Sony CXD2820R DVB-T/T2/C demodulator driver
pe 6.5.2011 15:36 Andreas Oberritter kirjoitti: > On 05/06/2011 02:23 PM, Mauro Carvalho Chehab wrote: >> Em 06-05-2011 07:42, Steve Kerrison escreveu: >>> Hi Andreas, >>> >>> From cxd2820r_priv.h: >>> +/* + * FIXME: These are totally wrong and must be added properly to the API. + * Only temporary solution in order to get driver compile. + */ +#define SYS_DVBT2 SYS_DAB +#define TRANSMISSION_MODE_1K 0 +#define TRANSMISSION_MODE_16K 0 +#define TRANSMISSION_MODE_32K 0 +#define GUARD_INTERVAL_1_128 0 +#define GUARD_INTERVAL_19_128 0 +#define GUARD_INTERVAL_19_256 0 >>> >>> >>> I believe Antti didn't want to make frontent.h changes until a >>> consensus >>> was reached on how to develop the API for T2 support. >> >> Yeah. >> >> Andreas/Antti, >> >> It seems more appropriate to remove the above hack and add Andreas >> patch. >> I've reviewed it and it seemed ok on my eyes, provided that we also >> update >> DVB specs to reflect the changes. >> >> In special, the new DVB command should be documented: >> +#define DTV_DVBT2_PLP_ID 43 > > In addition to the patch, the PLP ID needs to be stored in struct > dtv_frontend_properties and used by property cache functions in > dvb_frontend.c. > > Antti, could you please complete the patch and test it with your device? > This patch was adapted from an older kernel and only compile-tested few > weeks ago. I can test it next week. I added also those first to the frontend.h but rebased that patch out before PULL request just since I didn't have enough time to make proper API for 2.6.40 schedule. It can be already found from my old GIT tree. As I looked DVB-T2 specs it was rather complex and large to learn. For example how to handle multiple PLPs (driver does not handle it currently). Maybe PLP_ID is enough for that. 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
Re: [PATCH] OMAP3: ISP: Fix unbalanced use of omap3isp_get().
Hi Javier, On Friday 06 May 2011 12:42:19 javier Martin wrote: > Hi Laurent, > > > This won't work. Let's assume the following sequence of events: > > > > - Userspace opens the sensor subdev device node > > - The sensor driver calls to board code to turn the sensor clock on > > - Board code calls to the ISP driver to turn XCLK on > > - The ISP driver calls isp_enable_clocks() > > ... > > - Userspace opens an ISP video device node > > - The ISP driver calls isp_get(), incrementing the reference count > > - Userspace closes the ISP video device node > > - The ISP driver calls isp_put(), decrementing the reference count > > - The reference count reaches 0, the ISP driver calls > > isp_disable_clocks() > > > > The sensor will then loose its clock, even though the sensor subdev > > device node is still opened. > > Of course, you are right, I hadn't thought of it this way. > > > Could you please explain why the existing code doesn't work on your > > hardware ? > > Apparently, it is a mistake related to the sensor driver. Sorry about that. OK. No worries. > Just one question. > As I can see from mt9v032 driver, open callback is used to enable clock and > close callback is used to disable clock. > Does this mean that if sensor device node is not held open video won't > work? i.e, the following wouldn't work since (2) opens the sensor (enables > clock) and closes it again (disables clock) and (3) only opens CCDC device > node (enables clock with a wrong setting, since it was > previously set to 0 by (2) ) : > > (1) ./media-ctl -r -l '"mt9p031 2-0048":0->"OMAP3 ISP CCDC":0[1], > "OMAP3 ISP CCDC":1->"OMAP3 ISP CCDC output":0[1]' > (2) ./media-ctl -f '"mt9p031 2-0048":0[SGRBG8 320x240], "OMAP3 ISP > CCDC":1[SGRBG8 320x240]' > (3) ./yavta -f SGRBG8 -s 320x240 -n 4 --capture=100 --skip 3 -F > `./media-ctl -e "OMAP3 ISP CCDC output" Clocks are enabled/disabled by the mt9v032_set_power() function, called both by the open() and close() handlers and by the ISP driver through the subdev core::s_power operation. If the sensor is part of the pipeline, the OMAP3 ISP driver will power it up when the output video node is opened. (3) will thus power the sensor up. -- 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: [git:v4l-dvb/for_v2.6.40] [media] Sony CXD2820R DVB-T/T2/C demodulator driver
Em 06-05-2011 09:55, Steve Kerrison escreveu: > If antti doesn't do this before me, I will look at this over the weekend and > generate a patch against antti's current code... if that's appropriate of > course (I'm new at this ;)) Feel free to do it. I suspect that Antti won't work on it during this weekend. From what I understood, he's travelling in vacations. It helps if you could also add the bits into the frontend API DocBook: Documentation/DocBook/dvb/dvbproperty.xml The chapter that describes DVBv5 extensions is at: http://linuxtv.org/downloads/v4l-dvb-apis/FE_GET_PROPERTY.html As you may realize, this chapter were originally written with a description of the ISDB-T extensions. I've imported it from a .txt file, and did just some small adjustments to glue it into the specs, but I didn't have time to make it generic enough. So, the descriptions there for FE_[GET|SET]_PROPERTY are focused on ISDB-T. Yet, it shouldn't be hard to make it generic. I'm sending right now a patch I just made that will better document those two calls. I'm not adding the other non-documented properties. So, there are still lots of other DVBv5 property types not documented there (feel free to send us patches if you have time for that), and there are other missing changes from DVB APIv3 time, but at least we reduce a little bit the differences between the code and the spec [1]. In the past, the specs were shipped on a separate tree, using LaTex format, and outside the kernel. So, they weren't changed when new code were added. Now that we have it together with the kernel, we should only extend the API together with API specs, to avoid increasing the specs gap. With the specs at the kernel, all that needs to do to re-generate is to change the xml files and run: $ make htmldocs Then look at the specs using your favourite browser with an URL like: file:///home/myhome/media-tree/Documentation/DocBook/media/FE_GET_SET_PROPERTY.html [1] From DVB API v3 to v5, the differences are at the FE_[GET/SET]_PROPERTY ioctls. Thanks! Mauro. > > Regards, > Steve Kerrison. > > - Reply message - > From: "Andreas Oberritter" > Date: Fri, May 6, 2011 13:36 > Subject: [git:v4l-dvb/for_v2.6.40] [media] Sony CXD2820R DVB-T/T2/C > demodulator driver > To: "Mauro Carvalho Chehab" > Cc: "Steve Kerrison" , > , "Antti Palosaari" > > > On 05/06/2011 02:23 PM, Mauro Carvalho Chehab wrote: >> Em 06-05-2011 07:42, Steve Kerrison escreveu: >>> Hi Andreas, >>> >>> From cxd2820r_priv.h: >>> +/* + * FIXME: These are totally wrong and must be added properly to the API. + * Only temporary solution in order to get driver compile. + */ +#define SYS_DVBT2 SYS_DAB +#define TRANSMISSION_MODE_1K 0 +#define TRANSMISSION_MODE_16K 0 +#define TRANSMISSION_MODE_32K 0 +#define GUARD_INTERVAL_1_128 0 +#define GUARD_INTERVAL_19_128 0 +#define GUARD_INTERVAL_19_256 0 >>> >>> >>> I believe Antti didn't want to make frontent.h changes until a consensus >>> was reached on how to develop the API for T2 support. >> >> Yeah. >> >> Andreas/Antti, >> >> It seems more appropriate to remove the above hack and add Andreas patch. >> I've reviewed it and it seemed ok on my eyes, provided that we also update >> DVB specs to reflect the changes. >> >> In special, the new DVB command should be documented: >> +#define DTV_DVBT2_PLP_ID 43 > > In addition to the patch, the PLP ID needs to be stored in struct > dtv_frontend_properties and used by property cache functions in > dvb_frontend.c. > > Antti, could you please complete the patch and test it with your device? > This patch was adapted from an older kernel and only compile-tested few > weeks ago. > > Regards, > Andreas > -- > 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
[PATCH] DocBook/dvb: Improve description of the DVB API v5
Signed-off-by: Mauro Carvalho Chehab
diff --git a/Documentation/DocBook/dvb/dvbapi.xml
b/Documentation/DocBook/dvb/dvbapi.xml
index ad8678d..9fad86c 100644
--- a/Documentation/DocBook/dvb/dvbapi.xml
+++ b/Documentation/DocBook/dvb/dvbapi.xml
@@ -35,6 +35,14 @@
+ 2.0.4
+ 2011-05-06
+ mcc
+
+ Add more information about DVB APIv5, better describing the
frontend GET/SET props ioctl's.
+
+
+
2.0.3
2010-07-03
mcc
diff --git a/Documentation/DocBook/dvb/dvbproperty.xml
b/Documentation/DocBook/dvb/dvbproperty.xml
index 97f397e..05ce603 100644
--- a/Documentation/DocBook/dvb/dvbproperty.xml
+++ b/Documentation/DocBook/dvb/dvbproperty.xml
@@ -1,6 +1,312 @@
-
+
FE_GET_PROPERTY/FE_SET_PROPERTY
+
+/* Reserved fields should be set to 0 */
+struct dtv_property {
+ __u32 cmd;
+ union {
+ __u32 data;
+ struct {
+ __u8 data[32];
+ __u32 len;
+ __u32 reserved1[3];
+ void *reserved2;
+ } buffer;
+ } u;
+ int result;
+} __attribute__ ((packed));
+
+/* num of properties cannot exceed DTV_IOCTL_MAX_MSGS per ioctl */
+#define DTV_IOCTL_MAX_MSGS 64
+
+struct dtv_properties {
+ __u32 num;
+ struct dtv_property *props;
+};
+
+
+
+FE_GET_PROPERTY
+DESCRIPTION
+
+
+This ioctl call returns one or more frontend properties. This call only
+ requires read-only access to the device.
+
+
+SYNOPSIS
+
+
+int ioctl(int fd, int request = FE_GET_PROPERTY,
+ dtv_properties ⋆props);
+
+
+PARAMETERS
+
+
+int fd
+
+File descriptor returned by a previous call to open().
+
+
+int num
+
+Equals FE_GET_PROPERTY for this
command.
+
+
+struct dtv_property *props
+
+Points to the location where the front-end property commands are
stored.
+
+
+ERRORS
+
+ EINVAL
+ Invalid parameter(s) received or number of
parameters out of the range.
+
+ ENOMEM
+ Out of memory.
+
+ EFAULT
+ Failure while copying data from/to
userspace.
+
+ EOPNOTSUPP
+ Property type not supported.
+
+
+
+
+FE_SET_PROPERTY
+DESCRIPTION
+
+
+This ioctl call sets one or more frontend properties. This call only
+ requires read-only access to the device.
+
+
+SYNOPSIS
+
+
+int ioctl(int fd, int request = FE_SET_PROPERTY,
+ dtv_properties ⋆props);
+
+
+PARAMETERS
+
+
+int fd
+
+File descriptor returned by a previous call to open().
+
+
+int num
+
+Equals FE_SET_PROPERTY for this
command.
+
+
+struct dtv_property *props
+
+Points to the location where the front-end property commands are
stored.
+
+
+ERRORS
+
+
+ EINVAL
+ Invalid parameter(s) received or number of
parameters out of the range.
+
+ ENOMEM
+ Out of memory.
+
+ EFAULT
+ Failure while copying data from/to
userspace.
+
+ EOPNOTSUPP
+ Property type not supported.
+
+
+
+
+On FE_GET_PROPERTY/FE_SET_PROPERTY,
+the actual action is determined by the dtv_property cmd/data pairs. With one
single ioctl, is possible to
+get/set up to 64 properties. The actual meaning of each property is described
on the next sections.
+
+
+The Available frontend property types are:
+
+#define DTV_UNDEFINED 0
+#define DTV_TUNE 1
+#define DTV_CLEAR 2
+#define DTV_FREQUENCY 3
+#define DTV_MODULATION 4
+#define DTV_BANDWIDTH_HZ 5
+#define DTV_INVERSION 6
+#define DTV_DISEQC_MASTER 7
+#define DTV_SYMBOL_RATE8
+#define DTV_INNER_FEC 9
+#define DTV_VOLTAGE10
+#define DTV_TONE 11
+#define DTV_PILOT 12
+#define DTV_ROLLOFF13
+#define DTV_DISEQC_SLAVE_REPLY 14
+#define DTV_FE_CAPABILITY_COUNT15
+#define DTV_FE_CAPABILITY 16
+#define DTV_DELIVERY_SYSTEM17
+#define DTV_ISDBT_PARTIAL_RECEPTION18
+#define DTV_ISDBT_SOUND_BROADCASTING 19
+#define DTV_ISDBT_SB_SUBCHANNEL_ID 20
+#define DTV_ISDBT_SB_SEGMENT_IDX 21
+#define DTV_ISDBT_SB_SEGMENT_COUNT 22
+#define DTV_ISDBT_LAYERA_FEC 23
+#define DTV_ISDBT_LAYERA_MODULATION24
+#define DTV_ISDBT_LAYERA_SEGMENT_COUNT 25
+#define DTV_ISDBT_LAYERA_TIME_INTERLEAVING 26
+#define DTV_ISDBT_LAYERB_FEC 27
+#define DTV_ISDBT_LAYERB_MODULATION28
+#define DTV_ISDBT_LAYERB_SEGMENT_COUNT 29
+#define DTV_ISDBT_LAYERB_TIME_INTERLEAVING 30
+#define DTV_ISDBT_LAYERC_FEC 31
+#define DTV_ISDBT_LAYERC_MODULATION32
+#define DTV_ISDBT_LAYERC_SEGMENT_COUNT 33
+#define DTV_ISDBT_LAYERC_TIME_INTERLEAVING 34
+#define DTV_API_VERSION35
+#define DTV_CODE_RATE_HP 36
+#define DTV_CODE_RATE_LP 37
+#define DTV_GUARD_INTERVAL 38
+#define DTV_TRANSMISSION_MODE 39
+#define DTV_HIERARCHY 40
+#define DTV_ISDBT_LAYER_ENABLED41
+#define DTV_ISDBS_TS_ID42
+
+
+
+ Parameters that are common to all Digital TV
Re: [git:v4l-dvb/for_v2.6.40] [media] Sony CXD2820R DVB-T/T2/C demodulator driver
Em 06-05-2011 12:30, Mauro Carvalho Chehab escreveu: > Em 06-05-2011 09:55, Steve Kerrison escreveu: >> If antti doesn't do this before me, I will look at this over the weekend and >> generate a patch against antti's current code... if that's appropriate of >> course (I'm new at this ;)) > > Feel free to do it. I suspect that Antti won't work on it during this > weekend. From > what I understood, he's travelling in vacations. > > It helps if you could also add the bits into the frontend API DocBook: > Documentation/DocBook/dvb/dvbproperty.xml > > The chapter that describes DVBv5 extensions is at: > http://linuxtv.org/downloads/v4l-dvb-apis/FE_GET_PROPERTY.html Just updated the above URL to reflect my last patch. Of course, feel free to review the patch and send comments/fixes as usual ;) Cheers, Mauro. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
On 05/06/2011 03:47 PM, Issa Gorissen wrote: > From: Andreas Oberritter >>> The best would be to create independent adapters for each independent CA >>> device (ca0/caio0 pair) - they are independent after all (physically and >>> in the way they're used). >> >> Physically, it's a general purpose TS I/O interface of the nGene >> chipset. It just happens to be connected to a CI slot. On another board, >> it might be connected to a modulator or just to some kind of socket. >> >> If the next version gets a connector for two switchable CI modules, then >> the physical independence is gone. You'd have two ca nodes but only one >> caio node. Or two caio nodes, that can't be used concurrently. >> >> Maybe the next version gets the ability to directly connect the TS input >> from the frontend to the TS output to the CI slot to save copying around >> the data, by using some kind of pin mux. Not physically independent either. >> >> It just looks physically independent in the one configuration >> implemented now. > > > When I read the cxd2099ar datasheet, I can see that in dual slot > configuration, there is still one communication channel for the TS and one for > the control. It doesn't matter how the cxd2099ar works, because I'm talking about the nGene chipset in place of any chipset having at least two TS inputs and one TS output. Btw., I don't think the cxd2099 driver has any obvious problems. It's the nGene driver that registers the sec/caio interface. > Also, it seems linux en50221 stack provides for the slot selection. So, why > would you need two ca nodes ? Because it's the most obvious way to use it. And more importantly because the API sucks, if you have more than one device per node. You can have only one reader, one writer, one poll function per node. For example, you can't use one instance of mplayer to watch one channel with fe0+dmx0+ca0 and a second instance of mplayer to watch or record another channel with fe1+dmx1+ca0. You won't know which device has an event if you use poll. The API even allows mixing multiple CI slots and built-in descramblers in the same node. But try calling CA_RESET on a specific slot or on a descrambler. It won't work. It's broken by design. Do you know any implementation that has more than one CI slot per ca device and that really is in use? Regards, Andreas -- 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: Remote control not working for Terratec Cinergy C (2.6.37 Mantis driver)
04.05.2011 01:42, Adrian C. kirjoitti: > On Wed, 2 Mar 2011, Marko Ristola wrote: > >> So this means, that my remote control works, pressing key with hex >> value 0x26 works. > > It works. > >> Unfortunately mantis_uart.c doesn't have IR input initialization at >> all > > But it does not work. How can it work and not work at the same time? The hardware device is active (it is enabled, messages are sent from the remote to the Kernel Mantis software driver. The bytes can be logged into /var/log/messages file. That's all the driver is designed to do at this point. > > > I have the Skystar HD2 (b), subsystem: 1ae4:0003 now, same chipset as > Cinergy S2 and some others, VP-1041. Lirc failed with my old COM > receiver so I tried to use the cards IR as fall-back, and of course I > failed again. This was on 2.6.38.4. > > Only information I found is 1 year old[1]. "IR was in flux" but it still > doesn't work even though mantis pulls in all those ir-* modules, no > input device is created. > > Can someone fill us in, please, will it be supported this year? Would you please ask from Manu Abraham. Maybe he gets paid for doing it. I have experimented with my remote control too a few years ago, but I think it is good if Manu gets it as a job. Regards, Marko Ristola > > > 1. http://www.mail-archive.com/linux-media@vger.kernel.org/msg14641.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 > -- 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] v4l-dvb daily build: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Fri May 6 19:05:30 CEST 2011 git hash:7e6785451a66b9da0f8553a45b5655457ce22f08 gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: OK linux-git-armv5-davinci: OK linux-git-armv5-ixp: OK linux-git-armv5-omap2: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-x86_64: OK 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.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 spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.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] Ngene cam device name
From: Andreas Oberritter > On 05/06/2011 03:47 PM, Issa Gorissen wrote: > > From: Andreas Oberritter > >>> The best would be to create independent adapters for each independent CA > >>> device (ca0/caio0 pair) - they are independent after all (physically and > >>> in the way they're used). > >> > >> Physically, it's a general purpose TS I/O interface of the nGene > >> chipset. It just happens to be connected to a CI slot. On another board, > >> it might be connected to a modulator or just to some kind of socket. > >> > >> If the next version gets a connector for two switchable CI modules, then > >> the physical independence is gone. You'd have two ca nodes but only one > >> caio node. Or two caio nodes, that can't be used concurrently. > >> > >> Maybe the next version gets the ability to directly connect the TS input > >> from the frontend to the TS output to the CI slot to save copying around > >> the data, by using some kind of pin mux. Not physically independent either. > >> > >> It just looks physically independent in the one configuration > >> implemented now. > > > > > > When I read the cxd2099ar datasheet, I can see that in dual slot > > configuration, there is still one communication channel for the TS and one for > > the control. > > It doesn't matter how the cxd2099ar works, because I'm talking about the > nGene chipset in place of any chipset having at least two TS inputs and > one TS output. Don't know the ngene bridge enough to comment on this. > > Btw., I don't think the cxd2099 driver has any obvious problems. It's > the nGene driver that registers the sec/caio interface. > > > Also, it seems linux en50221 stack provides for the slot selection. So, why > > would you need two ca nodes ? > > Because it's the most obvious way to use it. And more importantly > because the API sucks, if you have more than one device per node. You > can have only one reader, one writer, one poll function per node. For > example, you can't use one instance of mplayer to watch one channel with > fe0+dmx0+ca0 and a second instance of mplayer to watch or record another > channel with fe1+dmx1+ca0. You won't know which device has an event if > you use poll. The API even allows mixing multiple CI slots and built-in > descramblers in the same node. But try calling CA_RESET on a specific > slot or on a descrambler. It won't work. It's broken by design. You need to write a userspace soft which will handle the concurrent access of your ca device... But for your given example, is there any card allowing you to do that (one ci slot, two tuners) ? -- 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
media_build broken due to wrong indention of timberdale entry in Kconfig
Hi, 'make menuconfig' does not work anymore: [media_build]$make menuconfig make -C /usr/local/src/ARCHIVE/git-work/media_build/v4l menuconfig make[1]: Entering directory `/usr/local/src/ARCHIVE/git-work/media_build/v4l' /lib/modules/2.6.38.5/build/scripts/kconfig/mconf ./Kconfig ./Kconfig:1527: unknown option "Add" make[1]: *** [menuconfig] Error 1 make[1]: Leaving directory `/usr/local/src/ARCHIVE/git-work/media_build/v4l' make: *** [menuconfig] Error 2 Fix attached. CU Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ From 0903a2a1574541035a7fcaf7f83c95bb08a91a07 Mon Sep 17 00:00:00 2001 From: Oliver Endriss Date: Fri, 6 May 2011 20:43:27 +0200 Subject: [PATCH] Kconfig: Fix indention of ---help--- for timerdale driver Signed-off-by: Oliver Endriss --- drivers/media/video/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 3d25920..d61414e 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -689,7 +689,7 @@ config VIDEO_TIMBERDALE select VIDEO_ADV7180 select VIDEOBUF_DMA_CONTIG ---help--- - Add support for the Video In peripherial of the timberdale FPGA. + Add support for the Video In peripherial of the timberdale FPGA. source "drivers/media/video/cx88/Kconfig" -- 1.6.5.3
Re: media_build broken due to wrong indention of timberdale entry in Kconfig
Em 06-05-2011 16:04, Oliver Endriss escreveu: > Hi, > > 'make menuconfig' does not work anymore: > > [media_build]$make menuconfig > make -C /usr/local/src/ARCHIVE/git-work/media_build/v4l menuconfig > make[1]: Entering directory `/usr/local/src/ARCHIVE/git-work/media_build/v4l' > /lib/modules/2.6.38.5/build/scripts/kconfig/mconf ./Kconfig > ./Kconfig:1527: unknown option "Add" > make[1]: *** [menuconfig] Error 1 > make[1]: Leaving directory `/usr/local/src/ARCHIVE/git-work/media_build/v4l' > make: *** [menuconfig] Error 2 > > Fix attached. Added, thanks! I also added a fix for uvc, due to a header that moved to a different place. On my tests against 2.6.32, everything is compiling now, and make menuconfig is running properly. Thanks, Mauro. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] dvb-usb.h function rc5_scan
Hi,
The function "rc5_scan" in "dvb_usb.h" is returning invalid value.
The value should be returned "u16" but is returning "u8".
See example below in "drivers/media/dvb/dvb-usb/opera1.c".
/*--*/
drivers/media/dvb/dvb-usb/opera1.c
static int opera1_rc_query(struct dvb_usb_device *dev, u32 * event, int *state)
{
.
.
.
send_key = (send_key & 0x) | 0x0100;
for (i = 0; i < ARRAY_SIZE(rc_map_opera1_table); i++) {
if (rc5_scan(&rc_map_opera1_table[i]) == (send_key & 0x)) {
*state = REMOTE_KEY_PRESSED;
*event = rc_map_opera1_table[i].keycode;
opst->last_key_pressed =
rc_map_opera1_table[i].keycode;
break;
}
opst->last_key_pressed = 0;
}
}
/*--*/
Signed-off-by: Manoel Pinheiro
diff --git a/drivers/media/dvb/dvb-usb/dvb-usb.h
b/drivers/media/dvb/dvb-usb/dvb-usb.h
index 76a8096..7d35d07 100644
--- a/drivers/media/dvb/dvb-usb/dvb-usb.h
+++ b/drivers/media/dvb/dvb-usb/dvb-usb.h
@@ -85,7 +85,7 @@ static inline u8 rc5_data(struct rc_map_table *key)
return key->scancode & 0xff;
}
-static inline u8 rc5_scan(struct rc_map_table *key)
+static inline u16 rc5_scan(struct rc_map_table *key)
{
return key->scancode & 0x;
}
--
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
