Re: PCTV nanoStick T2 in stock - Driver work?
On Wed, 2011-02-23 at 12:07 -0500, Devin Heitmueller wrote: > On Wed, Feb 23, 2011 at 11:49 AM, Nicolas Will wrote: > > Hello > > > > The DVB-T2 USB stick appears to be in stock in the UK. > > > > Product page: > > http://www.pctvsystems.com/Products/ProductsEuropeAsia/Digitalproducts/PCTVnanoStickT2/tabid/248/language/en-GB/Default.aspx > > > > Play.com, Dabs and Amzon.co.uk list it as in stock. > > > > Is there any work started on a driver at this point? > > > > If no work has started, would a loan/donation of a stick help? > > > > What can be done to trigger/accelerate the provision of a driver? > > Somebody would have to break down and reverse engineer the Sony T2 > demod. I saw something over in mythtv-users where somebody took a > unit apart and photographed it, and he's suggested that he's started > working on a driver. > > http://stevekerrison.com/290e/index.html > > Devin > That would be me :) I have indeed, but don't have much to speak of seeing as when I started I'd never touched Linux kernel-space driver development. At the moment I have hardware and usb data from myself and others. I'm hoping to publish some code that at least initialises the device with the Sony demod code stub'd so that I and whoever wants to join me, can attempt to get the demod to spit out some transport streams :) Donations won't get sony to give me the datasheet, so none requested right now. I actually have a free weekend coming up (a rare occurrence) in which I hope to make some further progress... Or the short answer: No hardware/donations needed, but things might take a while! Regards, -- Steve Kerrison MEng Hons. http://stevekerrison.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
CXD2820 & PCTV nanoStick T2 290e bringup
Hello everyone, I've done some work on bringup of this device in Linux, and now have a stub for the CXD2820 demod that includes the capability to pass I2C commands through to the tuner that sits behind it. The focus was on bringup, not compatibility with linux-media or Linus' coding guidelines, but hopefully it's not so horrendous that it makes you want to cry. This isn't a formal patch submission, but anyone with an interest is welcome to read more and grab the patch here: http://stevekerrison.com/290e/index.html#20110227 taking heed of the warnings and advice where necessary :) Only I2C passthrough is supported - none of the other demodulator or frontend functions work, and it doesn't detach properly. I'd like to know what the best approach would be for me to allow others to contribute to this if they so wish? Many thanks, -- Steve Kerrison MEng Hons. http://www.stevekerrison.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
em28xx: dvb lock bug on re-plug of device?
Hi all, I wonder if Devin/Mauro could help me with something as I've run into a problem developing a driver for the PCTV 290e? First plug of the device works fine, em28xx and em28xx_dvb are loaded. However, if I disconnect and then re-plug the device, the em28xx_dvb module will hang in dvb_init() where it performs mutex_lock(&dev->lock); It looks like the code to handle udev locking runs into a problem if the em28xx_dvb is already loaded. I'm referring to this: https://patchwork.kernel.org/patch/91160/ I don't have any other em28xx DVB devices to test against at the moment. I have modified dvb_init to give up if it doesn't get a lock straight away. This is not a valid fix, but it means I can run rmmod instead of rebooting. Below is a copy of khubd's complaint about the hangup. I pulled from media_tree.git. Perhaps this is already fixed in another branch? Thanks. [31498.792677] INFO: task khubd:28 blocked for more than 120 seconds. [31498.792682] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [31498.792685] khubd D 880232d59a58 028 2 0x [31498.792689] 880232d4d6b0 0046 880232d4d600 81036bb9 [31498.792692] 00013a80 880232d596c0 880232d59a58 880232d4dfd8 [31498.792695] 880232d59a60 00013a80 880232d4c010 00013a80 [31498.792699] Call Trace: [31498.792708] [] ? default_spin_lock_flags+0x9/0x10 [31498.792714] [] __mutex_lock_slowpath+0xf7/0x180 [31498.792717] [] mutex_lock+0x2b/0x50 [31498.792722] [] dvb_init+0x69/0xc20 [em28xx_dvb] [31498.792730] [] em28xx_init_extension+0x42/0x70 [em28xx] [31498.792735] [] em28xx_usb_probe+0x6a9/0xb10 [em28xx] [31498.792741] [] usb_probe_interface+0xf3/0x210 [31498.792746] [] driver_probe_device+0x96/0x1c0 [31498.792749] [] ? __device_attach+0x0/0x60 [31498.792751] [] __device_attach+0x53/0x60 [31498.792755] [] bus_for_each_drv+0x68/0x90 [31498.792757] [] device_attach+0x8f/0xb0 [31498.792760] [] bus_probe_device+0x2d/0x50 [31498.792764] [] device_add+0x639/0x710 [31498.792767] [] ? dev_set_name+0x41/0x50 [31498.792770] [] usb_set_configuration+0x606/0x6d0 [31498.792774] [] generic_probe+0x44/0xa0 [31498.792777] [] usb_probe_device+0x30/0x60 [31498.792779] [] driver_probe_device+0x96/0x1c0 [31498.792782] [] ? __device_attach+0x0/0x60 [31498.792784] [] __device_attach+0x53/0x60 [31498.792787] [] bus_for_each_drv+0x68/0x90 [31498.792789] [] device_attach+0x8f/0xb0 [31498.792792] [] bus_probe_device+0x2d/0x50 [31498.792795] [] device_add+0x639/0x710 [31498.792797] [] ? usb_cache_string+0x99/0xb0 [31498.792800] [] usb_new_device+0x9b/0x140 [31498.792803] [] hub_thread+0xc18/0x11a0 [31498.792806] [] ? dequeue_task_fair+0x29e/0x2b0 [31498.792811] [] ? autoremove_wake_function+0x0/0x40 [31498.792813] [] ? hub_thread+0x0/0x11a0 [31498.792816] [] kthread+0x96/0xa0 [31498.792820] [] kernel_thread_helper+0x4/0x10 [31498.792823] [] ? kthread+0x0/0xa0 [31498.792825] [] ? kernel_thread_helper+0x0/0x10 [31498.792868] INFO: task usb_id:19221 blocked for more than 120 seconds. [31498.792870] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [31498.792872] usb_id D 8802016b8398 0 19221 1 0x [31498.792875] 88018ac9fda8 0082 03a65c58 [31498.792878] 00013a80 8802016b8000 8802016b8398 88018ac9ffd8 [31498.792882] 8802016b83a0 00013a80 88018ac9e010 00013a80 [31498.792885] Call Trace: [31498.792888] [] __mutex_lock_slowpath+0xf7/0x180 [31498.792891] [] mutex_lock+0x2b/0x50 [31498.792895] [] show_manufacturer+0x2f/0x70 [31498.792898] [] dev_attr_show+0x27/0x50 [31498.792904] [] ? __get_free_pages+0xe/0x50 [31498.792910] [] sysfs_read_file+0xce/0x1c0 [31498.792914] [] vfs_read+0xc5/0x190 [31498.792916] [] sys_read+0x51/0x90 [31498.792922] [] system_call_fastpath+0x16/0x1b -- Steve Kerrison MEng Hons. http://www.stevekerrison.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: em28xx: dvb lock bug on re-plug of device?
Re-sending due to HTML accident. Thank you Devin, that is useful to know. It means I can have some confidence in the problem not being caused by my actions. I will focus my efforts on getting the device working in spite of this, but might have a chance to look into this bug thereafter. Regards, -- Steve Kerrison MEng Hons. http://www.stevekerrison.com/ On Thu, 2011-03-03 at 11:07 -0500, Devin Heitmueller wrote: > On Thu, Mar 3, 2011 at 11:01 AM, Steve Kerrison > wrote: > > Hi all, > > > > I wonder if Devin/Mauro could help me with something as I've run into a > > problem developing a driver for the PCTV 290e? > > > > First plug of the device works fine, em28xx and em28xx_dvb are loaded. > > However, if I disconnect and then re-plug the device, the em28xx_dvb > > module will hang in dvb_init() where it performs mutex_lock(&dev->lock); > > Hi Steve, > > I saw this too and brought it to Mauro's attention some months ago > (because I believed strongly it was related to locking changes). It > looks like he never did anything to address it though (and I've been > working on other bridges so haven't had any time to dig into it). > > So, for what it's worth, I can confirm the problem that you are experiencing. > > Devin > -- 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
i2c_gate_ctrl question
Hi media men & women, I have a question regarding the cxd2820r I'm working on with a couple of other people. In my naivety I implemented i2c gate control for the device (to access the tuner behind it) as a separate i2c device that did the passthrough. Now that I realise this, it would make sense to use the gate_ctrl features. However, picking apart the USB data it looks as though the way the cxd2820r implements "gate control" isn't immediately compatible with the implementation seen in other devices. Example, and I2C send to the tuner at (addr << 1) of: { xx, xx, ..., xx} becomes a write to (demod_addr << 1) of : { 09, (addr << 1) | flags, xx, xx, ..., xx} And an i2c receive is implemented to a receive from the demod address, not from the tuner address. So, unless there are open and close gate commands that aren't apparent from the snoop, or there's something I've missed, all i2c transfers to the tuner have to be mangled - sorry I mean encapsulated - prior to sending. To my understanding this doesn't fit in with the gate_ctrl implementation for i2c. I haven't had time to examine all other gate control implementations in the media modules, so if anyone knows any good examples that might work in a similar way, I'd appreciate the tip-off. Otherwise, would there be any objections to my implementation of a dummy i2c device that does the encapsulation? Regards, -- Steve Kerrison MEng Hons. http://www.stevekerrison.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
First DVB-T2 tuner announced - Hauppauge PCTV Nanostick T2 290e
Hauppauge has released details of its first DVB-T2 tuner at IFA. Some scarce details are here: http://www.wegotserved.com/2010/09/04/ifa-2010-hauppauge-announces-freeview-hd-dvbt2-tuner-pc/ along with a "datasheet" (without very much data) here: http://www.wegotserved.com/2010/09/06/ifa-2010-pctv-nanostick-t2-290e-freeview-hd-tuner-full-specs-data-sheet/ Only 720p video support is claimed, but that can't be anything to do with receiving the mux so I suspect that's a software limitation in the bundled player. Does anyone have (or have a means of getting) more info on the internals of this stick to aid Linux development? I will be attempting to acquire one of these at first release in October, and will do what I can, from USB snooping through to module development - as far as my time and skill can muster. Regards, Steve Kerrison. -- 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
[PATCH 0/6] DVB-T2 API updates, documentation and accompanying small fixes
Hi Mauro, Antti, Andreas, I hope this patch set is formed appropriately - it is my first patch submission direct to the linux-media group. Following the pull of Antti's work on support for the cxd2820r and PCTV nanoStick T2 290e, this patch set implements Andreas' modifications to the API to give provisional DVB-T2 support and the removal of a workaround for this in the cxd2820r module. In addition, there are some minor fixes to compiler warnings as a result of the expanded enums. I cannot test these myself but they treat unrecognized values as *_AUTO and I can't see where a problem would be created. I have updated the documentation a little. If I've done the right thing then I guess there is incentive there for me continue to expand DVB related elements of the API docs. This patch set has been tested by me on two systems, with one running a MythTV backend utilising a long-supported DVB tuner. MythTV works fine with the old tuner and the nanoStick T2 290e works in VLC. I've yet to test the 290e in MythTV - I was more intent on making sure the patches hadn't broken userland or older devices. Feedback, testing and discussion of where to go next is welcomed! Regards, Steve Kerrison. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/6] DVB: Add basic API support for DVB-T2 and bump minor version
From: Andreas Oberritter Signed-off-by: Andreas Oberritter Signed-off-by: Steve Kerrison --- drivers/media/dvb/dvb-core/dvb_frontend.c |7 +++ include/linux/dvb/frontend.h | 20 include/linux/dvb/version.h |2 +- 3 files changed, 20 insertions(+), 9 deletions(-) diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c b/drivers/media/dvb/dvb-core/dvb_frontend.c index 31e2c0d..e30beef 100644 --- a/drivers/media/dvb/dvb-core/dvb_frontend.c +++ b/drivers/media/dvb/dvb-core/dvb_frontend.c @@ -1148,10 +1148,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_*/ -- 1.7.1 -- 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 5/6] cxd2820r: Update frontend capabilities to advertise QAM-256
This is supported in DVB-T2 mode, so added to the T/T2 frontend. Signed-off-by: Steve Kerrison --- drivers/media/dvb/frontends/cxd2820r_core.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/media/dvb/frontends/cxd2820r_core.c b/drivers/media/dvb/frontends/cxd2820r_core.c index e900c4c..0779f69 100644 --- a/drivers/media/dvb/frontends/cxd2820r_core.c +++ b/drivers/media/dvb/frontends/cxd2820r_core.c @@ -855,7 +855,8 @@ static struct dvb_frontend_ops cxd2820r_ops[2] = { FE_CAN_FEC_3_4 | FE_CAN_FEC_5_6 | FE_CAN_FEC_7_8 | FE_CAN_FEC_AUTO | FE_CAN_QPSK | FE_CAN_QAM_16 | - FE_CAN_QAM_64 | FE_CAN_QAM_AUTO | + FE_CAN_QAM_64 | FE_CAN_QAM_256 | + FE_CAN_QAM_AUTO | FE_CAN_TRANSMISSION_MODE_AUTO | FE_CAN_GUARD_INTERVAL_AUTO | FE_CAN_HIERARCHY_AUTO | -- 1.7.1 -- 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 3/6] drxd: Fix warning caused by new entries in an enum
Additional bandwidth modes have been added in frontend.h drxd_hard.c had no default case so the compiler was warning about a non-exhausive switch statement. This has been fixed by making the default behaviour the same as BANDWIDTH_AUTO, with the addition of a printk to notify if this ever happens. Signed-off-by: Steve Kerrison --- drivers/media/dvb/frontends/drxd_hard.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/drivers/media/dvb/frontends/drxd_hard.c b/drivers/media/dvb/frontends/drxd_hard.c index 30a78af..f1d64f1 100644 --- a/drivers/media/dvb/frontends/drxd_hard.c +++ b/drivers/media/dvb/frontends/drxd_hard.c @@ -2325,6 +2325,9 @@ static int DRX_Start(struct drxd_state *state, s32 off) InitEC and ResetEC functions */ switch (p->bandwidth) { + default: + printk(KERN_INFO "drxd: Unsupported bandwidth mode %u, reverting to default\n", + p->bandwidth); case BANDWIDTH_AUTO: case BANDWIDTH_8_MHZ: /* (64/7)*(8/8)*100 */ -- 1.7.1 -- 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 6/6] Documentation: Update to include DVB-T2 additions
A few new capabilities added to frontend.h for DVB-T2. Added these to the documentation plus some notes explaining that they are used by the T2 delivery system. Signed-off-by: Steve Kerrison --- Documentation/DocBook/dvb/dvbproperty.xml | 21 ++--- Documentation/DocBook/dvb/frontend.h.xml | 20 2 files changed, 34 insertions(+), 7 deletions(-) diff --git a/Documentation/DocBook/dvb/dvbproperty.xml b/Documentation/DocBook/dvb/dvbproperty.xml index 05ce603..afe204c 100644 --- a/Documentation/DocBook/dvb/dvbproperty.xml +++ b/Documentation/DocBook/dvb/dvbproperty.xml @@ -217,9 +217,12 @@ get/set up to 64 properties. The actual meaning of each property is described on Bandwidth for the channel, in HZ. Possible values: + 1712000, + 500, 600, 700, - 800. + 800, + 1000. Notes: @@ -231,6 +234,8 @@ get/set up to 64 properties. The actual meaning of each property is described on 4) Bandwidth in ISDB-T is fixed (6MHz) or can be easily derived from other parameters (DTV_ISDBT_SB_SEGMENT_IDX, DTV_ISDBT_SB_SEGMENT_COUNT). + 5) DVB-T supports 6, 7 and 8MHz. + 6) In addition, DVB-T2 supports 1.172, 5 and 10MHz. @@ -257,6 +262,7 @@ typedef enum fe_delivery_system { SYS_DMBTH, SYS_CMMB, SYS_DAB, + SYS_DVBT2, } fe_delivery_system_t; @@ -273,7 +279,10 @@ 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; @@ -284,6 +293,8 @@ typedef enum fe_transmit_mode { 2) If DTV_TRANSMISSION_MODE is set the TRANSMISSION_MODE_AUTO the hardware will try to find the correct FFT-size (if capable) and will use TMCC to fill in the missing parameters. + 3) DVB-T specifies 2K and 8K as valid sizes. + 4) DVB-T2 specifies 1K, 2K, 4K, 8K, 16K and 32K. @@ -296,7 +307,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; @@ -304,6 +318,7 @@ typedef enum fe_guard_interval { 1) If DTV_GUARD_INTERVAL is set the GUARD_INTERVAL_AUTO the hardware will try to find the correct guard interval (if capable) and will use TMCC to fill in the missing parameters. + 2) Intervals 1/128, 19/128 and 19/256 are used only for DVB-T2 at present diff --git a/Documentation/DocBook/dvb/frontend.h.xml b/Documentation/DocBook/dvb/frontend.h.xml index d08e0d4..d792f78 100644 --- a/Documentation/DocBook/dvb/frontend.h.xml +++ b/Documentation/DocBook/dvb/frontend.h.xml @@ -176,14 +176,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; @@ -192,7 +198,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; @@ -306,7 +315,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, @@ -338,6 +349,7 @@ typedef enum fe_delivery_system { SYS_DMBTH, SYS_CMMB, SYS_DAB, +SYS_DVBT2, } fe_delivery_system_t; struct dtv_cmds_h { -- 1.7.1 -- 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 4/6] mxl5005: Fix warning caused by new entries in an enum
Additional bandwidth modes have been added in frontend.h mxl5005s.c had no default case so the compiler was warning about a non-exhausive switch statement. Signed-off-by: Steve Kerrison --- drivers/media/common/tuners/mxl5005s.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/drivers/media/common/tuners/mxl5005s.c b/drivers/media/common/tuners/mxl5005s.c index 0d6e094..667e216 100644 --- a/drivers/media/common/tuners/mxl5005s.c +++ b/drivers/media/common/tuners/mxl5005s.c @@ -4020,6 +4020,9 @@ static int mxl5005s_set_params(struct dvb_frontend *fe, case BANDWIDTH_7_MHZ: req_bw = MXL5005S_BANDWIDTH_7MHZ; break; + default: + dprintk(1,"%s: Unsupported bandwidth mode %u, reverting to default\n", + __func__,params->u.ofdm.bandwidth); case BANDWIDTH_AUTO: case BANDWIDTH_8_MHZ: req_bw = MXL5005S_BANDWIDTH_8MHZ; -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/6] cxd2820r: Remove temporary T2 API hack
Unimplemented delivery system and modes were #define'd to arbitrary values for internal use. API now includes these values so we can remove this hack. Signed-off-by: Steve Kerrison --- drivers/media/dvb/frontends/cxd2820r_priv.h | 12 1 files changed, 0 insertions(+), 12 deletions(-) diff --git a/drivers/media/dvb/frontends/cxd2820r_priv.h b/drivers/media/dvb/frontends/cxd2820r_priv.h index d4e2e0b..25adbee 100644 --- a/drivers/media/dvb/frontends/cxd2820r_priv.h +++ b/drivers/media/dvb/frontends/cxd2820r_priv.h @@ -40,18 +40,6 @@ #undef warn #define warn(f, arg...) printk(KERN_WARNING LOG_PREFIX": " f "\n" , ## arg) -/* - * 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 - struct reg_val_mask { u32 reg; u8 val; -- 1.7.1 -- 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 6/6] Documentation: Update to include DVB-T2 additions
Hi Mauro > + 3) DVB-T specifies 2K and 8K as valid sizes. > > + 4) DVB-T2 specifies 1K, 2K, 4K, 8K, 16K and 32K. > > It makes sense to add here that ISDB-T specifies 2K, 4K and 8K. > (yeah, sorry, it is my fault that I didn't notice it before ;) ) Actually note 1) in that list declares the sizes supported by ISDB-T; but the patch doesn't show it. So there is no blame to assign :) > -#define DTV_MAX_COMMAND DTV_ISDBS_TS_ID > > +#define DTV_DVBT2_PLP_ID 43 > > + > > Please document the PLP_ID as well. Just like ISDB-T, the best seems to > create a section with DVB-T2 specific parameters, and add this one there, > explaining its meaning. I have created a section for DVB-T2 parameters. It's within the main ISDB-T section. If that's not appropriate I guess it can be hauled out as it grows. However, much like Antti, I don't know much about PLP or the other features of the T2 specification, so cannot contribute a great deal yet. PLP_ID isn't used by the cxd2820r driver - it's simply specified in Andreas' API patch. Regards, -- Steve Kerrison MEng Hons. http://www.stevekerrison.com/ On Sun, 2011-05-08 at 13:20 -0300, Mauro Carvalho Chehab wrote: > Em 08-05-2011 12:51, Steve Kerrison escreveu: > > A few new capabilities added to frontend.h for DVB-T2. Added these > > to the documentation plus some notes explaining that they are > > used by the T2 delivery system. > > > > Signed-off-by: Steve Kerrison > > --- > > Documentation/DocBook/dvb/dvbproperty.xml | 21 ++--- > > Documentation/DocBook/dvb/frontend.h.xml | 20 > > 2 files changed, 34 insertions(+), 7 deletions(-) > > > > diff --git a/Documentation/DocBook/dvb/dvbproperty.xml > > b/Documentation/DocBook/dvb/dvbproperty.xml > > index 05ce603..afe204c 100644 > > --- a/Documentation/DocBook/dvb/dvbproperty.xml > > +++ b/Documentation/DocBook/dvb/dvbproperty.xml > > @@ -217,9 +217,12 @@ get/set up to 64 properties. The actual meaning of > > each property is described on > > Bandwidth for the channel, in HZ. > > > > Possible values: > > + 1712000, > > + 500, > > 600, > > 700, > > - 800. > > + 800, > > + 1000. > > > > > > Notes: > > @@ -231,6 +234,8 @@ get/set up to 64 properties. The actual meaning of each > > property is described on > > 4) Bandwidth in ISDB-T is fixed (6MHz) or can be easily > > derived from > > other parameters (DTV_ISDBT_SB_SEGMENT_IDX, > > DTV_ISDBT_SB_SEGMENT_COUNT). > > + 5) DVB-T supports 6, 7 and 8MHz. > > + 6) In addition, DVB-T2 supports 1.172, 5 and 10MHz. > > > > > > > > @@ -257,6 +262,7 @@ typedef enum fe_delivery_system { > > SYS_DMBTH, > > SYS_CMMB, > > SYS_DAB, > > + SYS_DVBT2, > > } fe_delivery_system_t; > > > > > > @@ -273,7 +279,10 @@ 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; > > > > > > @@ -284,6 +293,8 @@ typedef enum fe_transmit_mode { > > 2) If DTV_TRANSMISSION_MODE is set > > the TRANSMISSION_MODE_AUTO the > > hardware will try to find the correct FFT-size (if > > capable) and will > > use TMCC to fill in the missing parameters. > > + 3) DVB-T specifies 2K and 8K as valid sizes. > > + 4) DVB-T2 specifies 1K, 2K, 4K, 8K, 16K and 32K. > > It makes sense to add here that ISDB-T specifies 2K, 4K and 8K. > (yeah, sorry, it is my fault that I didn't notice it before ;) ) > > > > > > > > @@ -296,7 +307,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; > > > > > > @@ -304,6 +318,7 @@ typedef enum fe_guard_interval
[PATCH v2 0/5] DVB-T2 API updates, documentation and accompanying small fixes
Good evening all, This is the second version of my patch set for DVB-T2 and PCTV nanoStick T2 290e support. Changes to cxd2820r_priv.h have been rolled into patch 1 as requested by Mauro. I hope I have done this in an appropriate way. I have updated my drxd and mxl5005 patches to include a comment to make clear that the default case should fall through into BANDWIDTH_AUTO for bandwidth selection. My other cxd2820r patch is trivial and unchanged from the previous submission. I considered also rolling it into the first patch in the set, but it's a separate ehancement so I've kept it as it is. Finally I've made some documentation changes. I've added a section of DVB-T2 specific parameters, but don't have the knowledge to contribute anything useful to this section yet. Any further feedback welcomed. I won't be likely to act upon it for a few days, however. The mailing list could probably do with a break from me bungling my way around git. :) Regards, Steve Kerrison. -- 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 v2 1/5] DVB: Add basic API support for DVB-T2 and bump minor version
From: Andreas Oberritter st...@stevekerrison.com: Remove private definitions from cxd2820r that existed before API was defined Signed-off-by: Andreas Oberritter Signed-off-by: Steve Kerrison --- drivers/media/dvb/dvb-core/dvb_frontend.c |7 +++ drivers/media/dvb/frontends/cxd2820r_priv.h | 12 include/linux/dvb/frontend.h| 20 include/linux/dvb/version.h |2 +- 4 files changed, 20 insertions(+), 21 deletions(-) diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c b/drivers/media/dvb/dvb-core/dvb_frontend.c index 31e2c0d..e30beef 100644 --- a/drivers/media/dvb/dvb-core/dvb_frontend.c +++ b/drivers/media/dvb/dvb-core/dvb_frontend.c @@ -1148,10 +1148,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/drivers/media/dvb/frontends/cxd2820r_priv.h b/drivers/media/dvb/frontends/cxd2820r_priv.h index d4e2e0b..25adbee 100644 --- a/drivers/media/dvb/frontends/cxd2820r_priv.h +++ b/drivers/media/dvb/frontends/cxd2820r_priv.h @@ -40,18 +40,6 @@ #undef warn #define warn(f, arg...) printk(KERN_WARNING LOG_PREFIX": " f "\n" , ## arg) -/* - * 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 - struct reg_val_mask { u32 reg; u8 val; 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_*/ -- 1.7.1 -- 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 v2 2/5] drxd: Fix warning caused by new entries in an enum
Additional bandwidth modes have been added in frontend.h drxd_hard.c had no default case so the compiler was warning about a non-exhausive switch statement. This has been fixed by making the default behaviour the same as BANDWIDTH_AUTO, with the addition of a printk to notify if this ever happens. Signed-off-by: Steve Kerrison --- drivers/media/dvb/frontends/drxd_hard.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/media/dvb/frontends/drxd_hard.c b/drivers/media/dvb/frontends/drxd_hard.c index 30a78af..b3b0704 100644 --- a/drivers/media/dvb/frontends/drxd_hard.c +++ b/drivers/media/dvb/frontends/drxd_hard.c @@ -2325,6 +2325,10 @@ static int DRX_Start(struct drxd_state *state, s32 off) InitEC and ResetEC functions */ switch (p->bandwidth) { + default: + printk(KERN_INFO "drxd: Unsupported bandwidth mode %u, reverting to default\n", + p->bandwidth); + /* Fall back to auto */ case BANDWIDTH_AUTO: case BANDWIDTH_8_MHZ: /* (64/7)*(8/8)*100 */ -- 1.7.1 -- 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 v2 3/5] mxl5005: Fix warning caused by new entries in an enum
Additional bandwidth modes have been added in frontend.h mxl5005s.c had no default case so the compiler was warning about a non-exhausive switch statement. Signed-off-by: Steve Kerrison --- drivers/media/common/tuners/mxl5005s.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/media/common/tuners/mxl5005s.c b/drivers/media/common/tuners/mxl5005s.c index 0d6e094..d80e6f3 100644 --- a/drivers/media/common/tuners/mxl5005s.c +++ b/drivers/media/common/tuners/mxl5005s.c @@ -4020,6 +4020,10 @@ static int mxl5005s_set_params(struct dvb_frontend *fe, case BANDWIDTH_7_MHZ: req_bw = MXL5005S_BANDWIDTH_7MHZ; break; + default: + dprintk(1,"%s: Unsupported bandwidth mode %u, reverting to default\n", + __func__,params->u.ofdm.bandwidth); + /* Fall back to auto */ case BANDWIDTH_AUTO: case BANDWIDTH_8_MHZ: req_bw = MXL5005S_BANDWIDTH_8MHZ; -- 1.7.1 -- 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 v2 4/5] cxd2820r: Update frontend capabilities to advertise QAM-256
This is supported in DVB-T2 mode, so added to the T/T2 frontend. Signed-off-by: Steve Kerrison --- drivers/media/dvb/frontends/cxd2820r_core.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/media/dvb/frontends/cxd2820r_core.c b/drivers/media/dvb/frontends/cxd2820r_core.c index e900c4c..0779f69 100644 --- a/drivers/media/dvb/frontends/cxd2820r_core.c +++ b/drivers/media/dvb/frontends/cxd2820r_core.c @@ -855,7 +855,8 @@ static struct dvb_frontend_ops cxd2820r_ops[2] = { FE_CAN_FEC_3_4 | FE_CAN_FEC_5_6 | FE_CAN_FEC_7_8 | FE_CAN_FEC_AUTO | FE_CAN_QPSK | FE_CAN_QAM_16 | - FE_CAN_QAM_64 | FE_CAN_QAM_AUTO | + FE_CAN_QAM_64 | FE_CAN_QAM_256 | + FE_CAN_QAM_AUTO | FE_CAN_TRANSMISSION_MODE_AUTO | FE_CAN_GUARD_INTERVAL_AUTO | FE_CAN_HIERARCHY_AUTO | -- 1.7.1 -- 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 v2 5/5] Documentation: Update to include DVB-T2 additions
A few new capabilities added to frontend.h for DVB-T2. Added these to the documentation plus some notes explaining that they are used by the T2 delivery system. Signed-off-by: Steve Kerrison --- Documentation/DocBook/dvb/dvbproperty.xml | 36 ++-- Documentation/DocBook/dvb/frontend.h.xml | 20 +--- 2 files changed, 49 insertions(+), 7 deletions(-) diff --git a/Documentation/DocBook/dvb/dvbproperty.xml b/Documentation/DocBook/dvb/dvbproperty.xml index 05ce603..52d5e3c 100644 --- a/Documentation/DocBook/dvb/dvbproperty.xml +++ b/Documentation/DocBook/dvb/dvbproperty.xml @@ -217,9 +217,12 @@ get/set up to 64 properties. The actual meaning of each property is described on Bandwidth for the channel, in HZ. Possible values: + 1712000, + 500, 600, 700, - 800. + 800, + 1000. Notes: @@ -231,6 +234,8 @@ get/set up to 64 properties. The actual meaning of each property is described on 4) Bandwidth in ISDB-T is fixed (6MHz) or can be easily derived from other parameters (DTV_ISDBT_SB_SEGMENT_IDX, DTV_ISDBT_SB_SEGMENT_COUNT). + 5) DVB-T supports 6, 7 and 8MHz. + 6) In addition, DVB-T2 supports 1.172, 5 and 10MHz. @@ -257,6 +262,7 @@ typedef enum fe_delivery_system { SYS_DMBTH, SYS_CMMB, SYS_DAB, + SYS_DVBT2, } fe_delivery_system_t; @@ -273,7 +279,10 @@ 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; @@ -284,6 +293,8 @@ typedef enum fe_transmit_mode { 2) If DTV_TRANSMISSION_MODE is set the TRANSMISSION_MODE_AUTO the hardware will try to find the correct FFT-size (if capable) and will use TMCC to fill in the missing parameters. + 3) DVB-T specifies 2K and 8K as valid sizes. + 4) DVB-T2 specifies 1K, 2K, 4K, 8K, 16K and 32K. @@ -296,7 +307,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; @@ -304,6 +318,7 @@ typedef enum fe_guard_interval { 1) If DTV_GUARD_INTERVAL is set the GUARD_INTERVAL_AUTO the hardware will try to find the correct guard interval (if capable) and will use TMCC to fill in the missing parameters. + 2) Intervals 1/128, 19/128 and 19/256 are used only for DVB-T2 at present @@ -553,5 +568,20 @@ typedef enum fe_guard_interval { + + DVB-T2 parameters + + This section covers parameters that apply only to the DVB-T2 delivery method. DVB-T2 + support is currently in the early stages development so expect this section to grow + and become more detailed with time. + + + DTV_DVBT2_PLP_ID + + DVB-T2 supports Physical Layer Pipes (PLP) to allow transmission of + many data types via a single multiplex. The API will soon support this + at which point this section will be expanded. + + diff --git a/Documentation/DocBook/dvb/frontend.h.xml b/Documentation/DocBook/dvb/frontend.h.xml index d08e0d4..d792f78 100644 --- a/Documentation/DocBook/dvb/frontend.h.xml +++ b/Documentation/DocBook/dvb/frontend.h.xml @@ -176,14 +176,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; @@ -192,7 +198,10 @@ typedef enum fe_guard_interval { GUARD_INTERVAL_1_16, GUARD_INTERVAL_1_8, GUARD_INTERVAL_1_4, -GUARD_INTERVAL_AUTO +GUARD_INTERVAL_AUTO
Re: [PATCH v2 2/5] drxd: Fix warning caused by new entries in an enum
Hi Andreas, > I'd prefer returning -EINVAL for unsupported parameters. > > [snip] > > I already had a patch for this, but forgot to submit it together with > the frontend.h bits. That seems reasonable. Do I need to do anything with this? I'm happy for Mauro to scrub my drxd and mxl patches and use yours instead. > Btw., "status = status;" looks odd. Heh, yes it does. I wonder if that was put in to deal with an "unused variable" compiler warning before the switch statement had a default case? Otherwise, perhaps it's from the department of redundancy department. Regards, -- Steve Kerrison MEng Hons. http://www.stevekerrison.com/ On Mon, 2011-05-09 at 00:10 +0200, Andreas Oberritter wrote: > On 05/08/2011 09:17 PM, Steve Kerrison wrote: > > Additional bandwidth modes have been added in frontend.h > > drxd_hard.c had no default case so the compiler was warning about > > a non-exhausive switch statement. > > > > This has been fixed by making the default behaviour the same as > > BANDWIDTH_AUTO, with the addition of a printk to notify if this > > ever happens. > > > > Signed-off-by: Steve Kerrison > > --- > > drivers/media/dvb/frontends/drxd_hard.c |4 > > 1 files changed, 4 insertions(+), 0 deletions(-) > > > > diff --git a/drivers/media/dvb/frontends/drxd_hard.c > > b/drivers/media/dvb/frontends/drxd_hard.c > > index 30a78af..b3b0704 100644 > > --- a/drivers/media/dvb/frontends/drxd_hard.c > > +++ b/drivers/media/dvb/frontends/drxd_hard.c > > @@ -2325,6 +2325,10 @@ static int DRX_Start(struct drxd_state *state, s32 > > off) > >InitEC and ResetEC > >functions */ > > switch (p->bandwidth) { > > + default: > > + printk(KERN_INFO "drxd: Unsupported bandwidth mode %u, > > reverting to default\n", > > + p->bandwidth); > > + /* Fall back to auto */ > > I'd prefer returning -EINVAL for unsupported parameters. > > > case BANDWIDTH_AUTO: > > case BANDWIDTH_8_MHZ: > > /* (64/7)*(8/8)*100 */ > > I already had a patch for this, but forgot to submit it together with the > frontend.h bits. > > From 73d630b57f584d7e35cac5e27149cbc564aedde2 Mon Sep 17 00:00:00 2001 > From: Andreas Oberritter > Date: Fri, 8 Apr 2011 16:39:20 + > Subject: [PATCH 2/2] DVB: drxd_hard: handle new bandwidths by returning > -EINVAL > > Signed-off-by: Andreas Oberritter > --- > drivers/media/dvb/frontends/drxd_hard.c |3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > > diff --git a/drivers/media/dvb/frontends/drxd_hard.c > b/drivers/media/dvb/frontends/drxd_hard.c > index 30a78af..53319f4 100644 > --- a/drivers/media/dvb/frontends/drxd_hard.c > +++ b/drivers/media/dvb/frontends/drxd_hard.c > @@ -2348,6 +2348,9 @@ static int DRX_Start(struct drxd_state *state, s32 off) > status = Write16(state, >FE_AG_REG_IND_DEL__A, 71, 0x); > break; > + default: > + status = -EINVAL; > + break; > } > status = status; > if (status < 0) -- 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 v3] DVB: Add basic API support for DVB-T2 and bump minor version
From: Andreas Oberritter st...@stevekerrison.com: Remove private definitions from cxd2820r that existed before API was defined Signed-off-by: Andreas Oberritter Signed-off-by: Steve Kerrison --- drivers/media/dvb/dvb-core/dvb_frontend.c | 13 + drivers/media/dvb/dvb-core/dvb_frontend.h |3 +++ drivers/media/dvb/frontends/cxd2820r_priv.h | 12 include/linux/dvb/frontend.h| 20 include/linux/dvb/version.h |2 +- 5 files changed, 29 insertions(+), 21 deletions(-) diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c b/drivers/media/dvb/dvb-core/dvb_frontend.c index 31e2c0d..8c9ff8a 100644 --- a/drivers/media/dvb/dvb-core/dvb_frontend.c +++ b/drivers/media/dvb/dvb-core/dvb_frontend.c @@ -1148,10 +1148,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; @@ -1324,6 +1323,9 @@ static int dtv_property_process_get(struct dvb_frontend *fe, case DTV_ISDBS_TS_ID: tvp->u.data = fe->dtv_property_cache.isdbs_ts_id; break; + case DTV_DVBT2_PLP_ID: + tvp->u.data = fe->dtv_property_cache.dvbt2_plp_id; + break; default: r = -1; } @@ -1479,6 +1481,9 @@ static int dtv_property_process_set(struct dvb_frontend *fe, case DTV_ISDBS_TS_ID: fe->dtv_property_cache.isdbs_ts_id = tvp->u.data; break; + case DTV_DVBT2_PLP_ID: + fe->dtv_property_cache.dvbt2_plp_id = tvp->u.data; + break; default: r = -1; } diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.h b/drivers/media/dvb/dvb-core/dvb_frontend.h index 3b86050..5590eb6 100644 --- a/drivers/media/dvb/dvb-core/dvb_frontend.h +++ b/drivers/media/dvb/dvb-core/dvb_frontend.h @@ -358,6 +358,9 @@ struct dtv_frontend_properties { /* ISDB-T specifics */ u32 isdbs_ts_id; + + /* DVB-T2 specifics */ + u32 dvbt2_plp_id; }; struct dvb_frontend { diff --git a/drivers/media/dvb/frontends/cxd2820r_priv.h b/drivers/media/dvb/frontends/cxd2820r_priv.h index d4e2e0b..25adbee 100644 --- a/drivers/media/dvb/frontends/cxd2820r_priv.h +++ b/drivers/media/dvb/frontends/cxd2820r_priv.h @@ -40,18 +40,6 @@ #undef warn #define warn(f, arg...) printk(KERN_WARNING LOG_PREFIX": " f "\n" , ## arg) -/* - * 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 - struct reg_val_mask { u32 reg; u8 val; 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
Re: [PATCH v2 5/5] Documentation: Update to include DVB-T2 additions
I've just realised there is some illegal whitespace in this patch here: > @@ -553,5 +568,20 @@ typedef enum fe_guard_interval { > > > > + > + DVB-T2 parameters > + > + This section covers parameters that apply only > to the DVB-T2 delivery method. DVB-T2 Auto-tab between the title and first paragraph. My apologies! If I need to do anything about this let me know. -- Steve Kerrison MEng Hons. http://www.stevekerrison.com/ On Sun, 2011-05-08 at 20:17 +0100, Steve Kerrison wrote: > A few new capabilities added to frontend.h for DVB-T2. Added these > to the documentation plus some notes explaining that they are > used by the T2 delivery system. > > Signed-off-by: Steve Kerrison > --- > Documentation/DocBook/dvb/dvbproperty.xml | 36 ++-- > Documentation/DocBook/dvb/frontend.h.xml | 20 +--- > 2 files changed, 49 insertions(+), 7 deletions(-) > > diff --git a/Documentation/DocBook/dvb/dvbproperty.xml > b/Documentation/DocBook/dvb/dvbproperty.xml > index 05ce603..52d5e3c 100644 > --- a/Documentation/DocBook/dvb/dvbproperty.xml > +++ b/Documentation/DocBook/dvb/dvbproperty.xml > @@ -217,9 +217,12 @@ get/set up to 64 properties. The actual meaning of each > property is described on > Bandwidth for the channel, in HZ. > > Possible values: > + 1712000, > + 500, > 600, > 700, > - 800. > + 800, > + 1000. > > > Notes: > @@ -231,6 +234,8 @@ get/set up to 64 properties. The actual meaning of each > property is described on > 4) Bandwidth in ISDB-T is fixed (6MHz) or can be easily > derived from > other parameters (DTV_ISDBT_SB_SEGMENT_IDX, > DTV_ISDBT_SB_SEGMENT_COUNT). > + 5) DVB-T supports 6, 7 and 8MHz. > + 6) In addition, DVB-T2 supports 1.172, 5 and 10MHz. > > > > @@ -257,6 +262,7 @@ typedef enum fe_delivery_system { > SYS_DMBTH, > SYS_CMMB, > SYS_DAB, > + SYS_DVBT2, > } fe_delivery_system_t; > > > @@ -273,7 +279,10 @@ 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; > > > @@ -284,6 +293,8 @@ typedef enum fe_transmit_mode { > 2) If DTV_TRANSMISSION_MODE is set > the TRANSMISSION_MODE_AUTO the > hardware will try to find the correct FFT-size (if > capable) and will > use TMCC to fill in the missing parameters. > + 3) DVB-T specifies 2K and 8K as valid sizes. > + 4) DVB-T2 specifies 1K, 2K, 4K, 8K, 16K and 32K. > > > > @@ -296,7 +307,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; > > > @@ -304,6 +318,7 @@ typedef enum fe_guard_interval { > 1) If DTV_GUARD_INTERVAL is set the > GUARD_INTERVAL_AUTO the hardware will > try to find the correct guard interval (if capable) and > will use TMCC to fill > in the missing parameters. > + 2) Intervals 1/128, 19/128 and 19/256 are used only for > DVB-T2 at present > > > > @@ -553,5 +568,20 @@ typedef enum fe_guard_interval { > > > > + > + DVB-T2 parameters > + > + This section covers parameters that apply only to the > DVB-T2 delivery method. DVB-T2 > + support is currently in the early stages development so > expect this section to grow > + and become more detailed with time. > + > + > + DTV_DVBT2_PLP_ID > + > + DVB-T2 supports Physical Layer Pipes (PLP) to > allow transmission of > + many data types via a single multiplex. The API > will soon support this > + at which point this se
Re: dvb: one demux per tuner or one demux per demod?
Hi Rémi, The cxd2820r supports DVB-T/T2 and also DVB-C. As such antti coded up a multiple front end (MFE) implementation for em28xx then attaches the cxd2820r in both modes. I believe you can only use one frontend at once per adapter (this is certainly enforced in the cxd2820r module), so I don't see how it would cause a problem for mappings. I think a dual tuner device would register itself as two adapters, wouldn't it? But I'm new at this, so forgive me if I've overlooked something or misunderstood the issue you've raised. Regards, -- Steve Kerrison MEng Hons. http://www.stevekerrison.com/ On Tue, 2011-05-24 at 12:55 +0200, Rémi Denis-Courmont wrote: > Hello, > > Been testing the bleeding-edge Hauppauge 290E (em28174 + Sony cxd2820r) > from Antti Palosaari and Steve Kerrison, now in linux-media GIT tree. > > It seems the device creates two frontends and only one demux/dvr nodes. > Are they not supposed to be one demux per frontend? Or how is user-space > supposed to map the demux/dvr and the frontend, on a multi-proto card? on a > multi-tuner card? > > Best regards, > -- 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: dvb: one demux per tuner or one demux per demod?
Hi Devin, > Oh wow, is that what Antti did? I didn't really give much thought but > I can appreciate why he did it (the DVB 3.x API won't allow a single > frontend to advertise support for DVB-C and DVB-T). Yup, here's a quote from his initial pull request. I guess it doesn't make completely clear why he did what he did unless you knew in advance that the demod did DVB-T and DVB-C. > Main part of this patch series is new demod driver for Sony CXD2820R. > Other big part is multi frontend (MFE) support for em28xx driver. I > don't have any other MFE device, so I cannot say if it is implemented > correctly or not. At least it seems to work. MFE locking is done in > demod driver. If there is some problems let me know and I will try to > fix those - I think there is no such big major problems still. Back to your comments: > This is one of the big things that S2API fixes (through S2API you can > specify the modulation that you want). Do we really want to be > advertising two frontends that point to the same demod, when they > cannot be used in parallel? This seems doomed to create problems with > applications not knowing that they are in fact the same frontend. Agreed, but I had thought that with a single adapter with two frontends it would be possible to obey the rules and only use one at once. If frontend0 is in use, then if you try to open either frontend0 or frontend1, you should get device busy... so I don't see it causing massive issues. Like you say, though, S2API is probably the better approach, with the frontend advertising its supported modulations and selecting one as required. > I'm tempted to say that this patch should be scapped and we should > simply say that you cannot use DVB-C on this device unless you are > using S2API. That would certainly be cleaner but it comes at the cost > of DVB-C not working with tools that haven't been converted over to > S2API yet. Seeing as the 290e is the only cxd2820r based device supported in Linux right now, combined with the fact that it isn't even advertised as a DVB-C device by PCTV Systems, that's probably an acceptable hit to take. I'd be interested to see what Antti thinks though. :) Regards, -- Steve Kerrison MEng Hons. http://www.stevekerrison.com/ On Tue, 2011-05-24 at 08:28 -0400, Devin Heitmueller wrote: > 2011/5/24 Steve Kerrison : > > Hi Rémi, > > > > The cxd2820r supports DVB-T/T2 and also DVB-C. As such antti coded up a > > multiple front end (MFE) implementation for em28xx then attaches the > > cxd2820r in both modes. > > > > I believe you can only use one frontend at once per adapter (this is > > certainly enforced in the cxd2820r module), so I don't see how it would > > cause a problem for mappings. I think a dual tuner device would register > > itself as two adapters, wouldn't it? > > > > But I'm new at this, so forgive me if I've overlooked something or > > misunderstood the issue you've raised. > > Oh wow, is that what Antti did? I didn't really give much thought but > I can appreciate why he did it (the DVB 3.x API won't allow a single > frontend to advertise support for DVB-C and DVB-T). > > This is one of the big things that S2API fixes (through S2API you can > specify the modulation that you want). Do we really want to be > advertising two frontends that point to the same demod, when they > cannot be used in parallel? This seems doomed to create problems with > applications not knowing that they are in fact the same frontend. > > I'm tempted to say that this patch should be scapped and we should > simply say that you cannot use DVB-C on this device unless you are > using S2API. That would certainly be cleaner but it comes at the cost > of DVB-C not working with tools that haven't been converted over to > S2API yet. > > Devin > -- 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: PCTV nanoStick T2 290e support - Thank you!
The demodulator chip supports T,T2 and C. Here in the UK you're not really allowed to attach cable receivers that aren't supplied by the cable company (Virgin Media). That and the fact that it has no access module for obvious reasons, I guess PCTV Systems didn't see the benefit in marketing the C functionality. I don't actually know if the windows driver supports C mode, it would be amusing if we deliver more functionality with the Linux driver :) Regards, -- Steve Kerrison MEng Hons. http://www.stevekerrison.com/ On Fri, 2011-05-27 at 13:36 +0200, Bjørn Mork wrote: > Antti Palosaari writes: > > On 05/27/2011 12:25 AM, Nicolas WILL wrote: > >> Just installed mine for MythTV. > >> > >> Works great on the first try! > >> > >> Many, many thanks! > > > > Thank you for the feedback! > > I'm a bit curious about this device. It seems to only be marketed as a > DVB-T2 device in areas where that spec is used. But looking at your > driver, it seems that the device also supports DVB-C. Is that correct? > > > > Bjørn > > -- > 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: PCTV nanoStick T2 290e support - Thank you!
Hi Bjørn, > I thought downloading the Windows driver would tell, but > a) I cannot seem to find the Windows driver for this device, and > b) this info isn't easily found in the drivers I looked at The bundled CD has the drivers on it, but I think it's also in the driver bundle on their site for their other empia based cards: ftp://ftp.pctvsystems.com/TV/driver/PCTV%2070e%2080e%20100e%20320e% 20330e%20800e/PCTV%2070e%2080e%20100e%20320e%20330e%20800e%20880e.zip Found via http://www.pctvsystems.com/tabid/62/default.aspx/Downloads/Driver/tabid/123/language/en-GB/Default.aspx I'm not sure how you'd tell, other than perhaps firing up VLC on Windows and seeing if you can open it as a DVB-C device? Regards, -- Steve Kerrison MEng Hons. http://www.stevekerrison.com/ On Fri, 2011-05-27 at 14:41 +0200, Bjørn Mork wrote: > Steve Kerrison writes: > > > The demodulator chip supports T,T2 and C. > > > > Here in the UK you're not really allowed to attach cable receivers that > > aren't supplied by the cable company (Virgin Media). That and the fact > > that it has no access module for obvious reasons, I guess PCTV Systems > > didn't see the benefit in marketing the C functionality. > > Well, I found it a bit weird that they do announce DVB-T + DVB-C support > for the "PCTV QuatroStick nano" (which has the exact same form factor > and look, and therefore obviously no CA slot either): > http://www.pctvsystems.com/Products/ProductsEuropeAsia/Hybridproducts/PCTVQuatroSticknano/tabid/254/language/en-GB/Default.aspx > > While the "PCTV nanoStick T2" is announced as only DVB-T2 + DVB-T: > http://www.pctvsystems.com/Products/ProductsEuropeAsia/Digitalproducts/PCTVnanoStickT2/tabid/248/language/en-GB/Default.aspx > > That's why I asked, even though the driver clearly supports DVB-C. But > you may be right that this is because the "nanoStick T2" currently is > targeted for the UK. > > Around here, we've actually got some cable companies supporting TV sets > with integrated receivers. Of course requiring their CAM. They > probably still don't like the thought of PC based receivers, but there > is some hope... > > > > I don't actually know if the windows driver supports C mode, it would be > > amusing if we deliver more functionality with the Linux driver :) > > I thought downloading the Windows driver would tell, but > a) I cannot seem to find the Windows driver for this device, and > b) this info isn't easily found in the drivers I looked at > > So who knows? It would certainly be amusing. > > > Bjørn > > -- > 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: [GIT PULL FOR 2.6.40] PCTV nanoStick T2 290e (Sony CXD2820R DVB-T/T2/C)
Here in the UK the mux strengths and parameters are all over the place. I have had situations in the past (with dib0700 I think) where I've had to twiddle the force_lna setting one way or the other depending on how they've decided to reconfigure my local transmitter. So I'd be cautious about flat-out enabling it the whole time. -- Steve Kerrison MEng Hons. http://www.stevekerrison.com/ On Fri, 2011-06-03 at 15:29 +0200, Bjørn Mork wrote: > Antti Palosaari writes: > > On 06/01/2011 04:27 PM, Mauro Carvalho Chehab wrote: > >> Em 25-05-2011 17:42, Antti Palosaari escreveu: > >>> Antti Palosaari (7): > >>>em28xx-dvb: add module param "options" and use it for LNA > >> > >> That patch is ugly, for several reasons: > >> > >> 1) we don't want a generic "options" parameter, whose meaning changes from > >> device to devices; > > > > I agree it is not proper solution, but in my mind it is better to > > offer some solution than no solution at all. > > > >> 2) what happens if someone has two em28xx devices plugged? > > > > It depends depends devices, currently only nanoStick T2 only looks > > that param, other just ignore. If there is two nanoStics then both > > have same LNA settings. > > > > That's just like same behaviour as for example remote controller > > polling. Or for example DiBcom driver LNA, since it does have similar > > module param already. Will you you commit it if I rename it similarly > > as DiBcom? > > > >> 3) the better would be to detect if LNA is needed, or to add a DVBS2API > >> call to enable/disable LNA. > > > > True, but it needs some research. There is many hardware which gets > > signal input from demod or tuner and makes some fine tune according to > > that. We need to define some new callbacks for demod and tuner in > > order to do this kind of actions. > > Or just add new LNA param to API use it manually. > > > Or option > 4) just enable the LNA unconditionally. > > I did some testing in my environment, and I was unable to tune anything > on either DVB-T or DVB-C without the LNA enabled. I'm of course aware > that this depends on your signal, but have you actually seen a real life > signal where tuning fails with the LNA enabled and works without it? > > I do believe that my DVB-C signal at least is pretty strong. > > > > Bjørn > > -- > 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] CXD2820R: Replace i2c message translation with repeater gate control
This patch implements an i2c_gate_ctrl op for the cxd2820r. Thanks to Robert Schlabbach for identifying the register address and field to set. The old i2c intercept code that prefixed messages with a passthrough byte has been removed and the PCTV nanoStick T2 290e entry in em28xx-dvb has been updated appropriately. Tested for DVB-T2 use; I would appreciate it if somebody with DVB-C capabilities could test it as well - from inspection I cannot see any problems. Signed-off-by: Steve Kerrison --- drivers/media/dvb/frontends/cxd2820r_core.c | 73 +++ drivers/media/dvb/frontends/cxd2820r_priv.h |1 - drivers/media/video/em28xx/em28xx-dvb.c |7 +-- 3 files changed, 10 insertions(+), 71 deletions(-) diff --git a/drivers/media/dvb/frontends/cxd2820r_core.c b/drivers/media/dvb/frontends/cxd2820r_core.c index d416e85..15bfcf4 100644 --- a/drivers/media/dvb/frontends/cxd2820r_core.c +++ b/drivers/media/dvb/frontends/cxd2820r_core.c @@ -728,69 +728,20 @@ static void cxd2820r_release(struct dvb_frontend *fe) dbg("%s", __func__); if (fe->ops.info.type == FE_OFDM) { - i2c_del_adapter(&priv->tuner_i2c_adapter); kfree(priv); } return; } -static u32 cxd2820r_tuner_i2c_func(struct i2c_adapter *adapter) -{ - return I2C_FUNC_I2C; -} - -static int cxd2820r_tuner_i2c_xfer(struct i2c_adapter *i2c_adap, - struct i2c_msg msg[], int num) -{ - struct cxd2820r_priv *priv = i2c_get_adapdata(i2c_adap); - int ret; - u8 *obuf = kmalloc(msg[0].len + 2, GFP_KERNEL); - struct i2c_msg msg2[2] = { - { - .addr = priv->cfg.i2c_address, - .flags = 0, - .len = msg[0].len + 2, - .buf = obuf, - }, { - .addr = priv->cfg.i2c_address, - .flags = I2C_M_RD, - .len = msg[1].len, - .buf = msg[1].buf, - } - }; - - if (!obuf) - return -ENOMEM; - - obuf[0] = 0x09; - obuf[1] = (msg[0].addr << 1); - if (num == 2) { /* I2C read */ - obuf[1] = (msg[0].addr << 1) | I2C_M_RD; /* I2C RD flag */ - msg2[0].len = msg[0].len + 2 - 1; /* '-1' maybe HW bug ? */ - } - memcpy(&obuf[2], msg[0].buf, msg[0].len); - - ret = i2c_transfer(priv->i2c, msg2, num); - if (ret < 0) - warn("tuner i2c failed ret:%d", ret); - - kfree(obuf); - - return ret; -} - -static struct i2c_algorithm cxd2820r_tuner_i2c_algo = { - .master_xfer = cxd2820r_tuner_i2c_xfer, - .functionality = cxd2820r_tuner_i2c_func, -}; - -struct i2c_adapter *cxd2820r_get_tuner_i2c_adapter(struct dvb_frontend *fe) +static int cxd2820r_i2c_gate_ctrl(struct dvb_frontend *fe, int enable) { struct cxd2820r_priv *priv = fe->demodulator_priv; - return &priv->tuner_i2c_adapter; + dbg("%s: %d", __func__, enable); + + /* Bit 0 of reg 0xdb in bank 0x00 controls I2C repeater */ + return cxd2820r_wr_reg_mask(priv, 0xdb, enable ? 1 : 0, 0x1); } -EXPORT_SYMBOL(cxd2820r_get_tuner_i2c_adapter); static struct dvb_frontend_ops cxd2820r_ops[2]; @@ -831,18 +782,6 @@ struct dvb_frontend *cxd2820r_attach(const struct cxd2820r_config *cfg, priv->fe[0].demodulator_priv = priv; priv->fe[1].demodulator_priv = priv; - /* create tuner i2c adapter */ - strlcpy(priv->tuner_i2c_adapter.name, - "CXD2820R tuner I2C adapter", - sizeof(priv->tuner_i2c_adapter.name)); - priv->tuner_i2c_adapter.algo = &cxd2820r_tuner_i2c_algo; - priv->tuner_i2c_adapter.algo_data = NULL; - i2c_set_adapdata(&priv->tuner_i2c_adapter, priv); - if (i2c_add_adapter(&priv->tuner_i2c_adapter) < 0) { - err("tuner I2C bus could not be initialized"); - goto error; - } - return &priv->fe[0]; } else { @@ -883,6 +822,7 @@ static struct dvb_frontend_ops cxd2820r_ops[2] = { .sleep = cxd2820r_sleep, .get_tune_settings = cxd2820r_get_tune_settings, + .i2c_gate_ctrl = cxd2820r_i2c_gate_ctrl, .get_frontend = cxd2820r_get_frontend, @@ -911,6 +851,7 @@ static struct dvb_frontend_ops cxd2820r_ops[2] = { .sleep = cxd2820r_sleep, .get_tune_settings = cxd2820r_get_tune_settings, + .i2c_gate_ctrl = cxd2820r_i2c_gate_ctrl, .set_frontend = cxd2820r_set_frontend, .get_frontend = cxd2820r_get_frontend, diff --git a/
[PATCH v2] CXD2820R: Replace i2c message translation with repeater gate control
This patch implements an i2c_gate_ctrl op for the cxd2820r. Thanks to Robert Schlabbach for identifying the register address and field to set. The old i2c intercept code that prefixed messages with a passthrough byte has been removed and the PCTV nanoStick T2 290e entry in em28xx-dvb has been updated appropriately. Tested for DVB-T2 use; I would appreciate it if somebody with DVB-C capabilities could test it as well - from inspection I cannot see any problems. This is patch v2. It fixes some schoolboy style errors and removes superfluous i2c entries in cxd2820r.h. Signed-off-by: Steve Kerrison --- drivers/media/dvb/frontends/cxd2820r.h |9 --- drivers/media/dvb/frontends/cxd2820r_c.c|1 - drivers/media/dvb/frontends/cxd2820r_core.c | 76 +++ drivers/media/dvb/frontends/cxd2820r_priv.h |1 - drivers/media/dvb/frontends/cxd2820r_t.c|1 - drivers/media/dvb/frontends/cxd2820r_t2.c |1 - drivers/media/video/em28xx/em28xx-dvb.c |7 +-- 7 files changed, 11 insertions(+), 85 deletions(-) diff --git a/drivers/media/dvb/frontends/cxd2820r.h b/drivers/media/dvb/frontends/cxd2820r.h index 2906582..03cab7b 100644 --- a/drivers/media/dvb/frontends/cxd2820r.h +++ b/drivers/media/dvb/frontends/cxd2820r.h @@ -93,9 +93,6 @@ extern struct dvb_frontend *cxd2820r_attach( struct i2c_adapter *i2c, struct dvb_frontend *fe ); -extern struct i2c_adapter *cxd2820r_get_tuner_i2c_adapter( - struct dvb_frontend *fe -); #else static inline struct dvb_frontend *cxd2820r_attach( const struct cxd2820r_config *config, @@ -106,12 +103,6 @@ static inline struct dvb_frontend *cxd2820r_attach( printk(KERN_WARNING "%s: driver disabled by Kconfig\n", __func__); return NULL; } -static inline struct i2c_adapter *cxd2820r_get_tuner_i2c_adapter( - struct dvb_frontend *fe -) -{ - return NULL; -} #endif diff --git a/drivers/media/dvb/frontends/cxd2820r_c.c b/drivers/media/dvb/frontends/cxd2820r_c.c index 3c07d40..b85f501 100644 --- a/drivers/media/dvb/frontends/cxd2820r_c.c +++ b/drivers/media/dvb/frontends/cxd2820r_c.c @@ -335,4 +335,3 @@ int cxd2820r_get_tune_settings_c(struct dvb_frontend *fe, return 0; } - diff --git a/drivers/media/dvb/frontends/cxd2820r_core.c b/drivers/media/dvb/frontends/cxd2820r_core.c index d416e85..0151267 100644 --- a/drivers/media/dvb/frontends/cxd2820r_core.c +++ b/drivers/media/dvb/frontends/cxd2820r_core.c @@ -727,70 +727,20 @@ static void cxd2820r_release(struct dvb_frontend *fe) struct cxd2820r_priv *priv = fe->demodulator_priv; dbg("%s", __func__); - if (fe->ops.info.type == FE_OFDM) { - i2c_del_adapter(&priv->tuner_i2c_adapter); + if (fe->ops.info.type == FE_OFDM) kfree(priv); - } return; } -static u32 cxd2820r_tuner_i2c_func(struct i2c_adapter *adapter) -{ - return I2C_FUNC_I2C; -} - -static int cxd2820r_tuner_i2c_xfer(struct i2c_adapter *i2c_adap, - struct i2c_msg msg[], int num) -{ - struct cxd2820r_priv *priv = i2c_get_adapdata(i2c_adap); - int ret; - u8 *obuf = kmalloc(msg[0].len + 2, GFP_KERNEL); - struct i2c_msg msg2[2] = { - { - .addr = priv->cfg.i2c_address, - .flags = 0, - .len = msg[0].len + 2, - .buf = obuf, - }, { - .addr = priv->cfg.i2c_address, - .flags = I2C_M_RD, - .len = msg[1].len, - .buf = msg[1].buf, - } - }; - - if (!obuf) - return -ENOMEM; - - obuf[0] = 0x09; - obuf[1] = (msg[0].addr << 1); - if (num == 2) { /* I2C read */ - obuf[1] = (msg[0].addr << 1) | I2C_M_RD; /* I2C RD flag */ - msg2[0].len = msg[0].len + 2 - 1; /* '-1' maybe HW bug ? */ - } - memcpy(&obuf[2], msg[0].buf, msg[0].len); - - ret = i2c_transfer(priv->i2c, msg2, num); - if (ret < 0) - warn("tuner i2c failed ret:%d", ret); - - kfree(obuf); - - return ret; -} - -static struct i2c_algorithm cxd2820r_tuner_i2c_algo = { - .master_xfer = cxd2820r_tuner_i2c_xfer, - .functionality = cxd2820r_tuner_i2c_func, -}; - -struct i2c_adapter *cxd2820r_get_tuner_i2c_adapter(struct dvb_frontend *fe) +static int cxd2820r_i2c_gate_ctrl(struct dvb_frontend *fe, int enable) { struct cxd2820r_priv *priv = fe->demodulator_priv; - return &priv->tuner_i2c_adapter; + dbg("%s: %d", __func__, enable); + + /* Bit 0 of reg 0xdb in bank 0x00 controls I2C repeater */ + return cxd2820r_wr_reg_mask(priv, 0xdb, enable ? 1 : 0, 0x1); } -EXPORT_SYMBOL(cxd2820r_get_tuner_i2c_adapter); static struct dv
Re: Anyone tested the DVB-T2 dual tuner TBS6280?
Hi Harald, Currently the controller chip on the BlackGold card is unsupported - I don't know if there's any development work going on for that in this arena or if perhaps BlackGold are working on something themselves. Perhaps somebody else here knows the full story. This TBS card has only just been brought to my attention. I cannot tell what PCIe chip it uses and if it's supported. The alleged Linux driver download for it doesn't have the cxd2820r code in it, so I can't see that having much chance of working. Perhaps ask TBS directly what the status on this one is? I don't know of anybody who has used it yet (even in Windows). Regards, -- Steve Kerrison MEng Hons. http://www.stevekerrison.com/ On Tue, 2011-08-09 at 12:35 +0200, Harald Gustafsson wrote: > Hi, > > I searched for a dual tuner PCI-e DVB-T2 card with Linux support and > found this TBS6280 card: > http://tbsdvb.blog.com/2011/07/22/tbs-6280-freeview-hd-twin-tuner-card/ > http://www.buydvb.net/tbs6280-pcie-dvbt2t-dual-tuner-card_p38.html > http://www.tbsdtv.com/english/Download.html > > Previously I have only found the blackgold product that state they > will have Linux support but have not seen any drivers yet. > > But when searching the mythtv lists and the linux dvb list I could not > find anyone using it. Do anyone have any info about this card, does it > work well with terrestrial DVB-T2 reception, is linux support working, > does it work with mythtv, etc. > > /Harald > -- > 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: PCTV 290e - assorted problems
That is most likely the em28xx locking bug. It'll happen when you plug a second em28xx device in, or plug one in for a second time. The steps you've shown include that process. Try doing `rmmod em28xx-dvb` before re-plugging the device. If that 'cures' it, you're a victim of the same problem. I'm not overtly familiar with the interactions of em28xx with the rest of the kernel & userland and why the bug manifests, but it is on my list of things to (try to) fix, although I'm hoping somebody more able than me figures it out first :) Regards, -- Steve Kerrison MEng Hons. http://www.stevekerrison.com/ On Sun, 2011-08-14 at 17:05 -0700, Chris Rankin wrote: > >> INFO: task khubd:1100 blocked for more than 120 seconds. > >> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > >> khubd D 0 1100 2 0x > >> 8801a694e930 0046 8801a691ffd8 8162b020 > >> 00010280 8801a691ffd8 4000 00010280 > >> 8801a691ffd8 8801a694e930 00010280 8801a691e000 > >> Call Trace: > >> [] ? apic_timer_interrupt+0xe/0x20 > >> [] ? memscan+0x3/0x18 > >> [] ? __mutex_lock_slowpath+0x15c/0x295 > >> [] ? mutex_lock+0x9/0x18 > >> [] ? dvb_init+0x99/0xcc8 [em28xx_dvb] > >> [] ? em28xx_init_extension+0x35/0x53 [em28xx] > >> [] ? em28xx_usb_probe+0x827/0x8df [em28xx] > > > > I think it crashes before it even goes to PCTV 290e specific part. I > > suspect it is bug somewhere in em28xx driver. > > The scenario that triggers this crash is: > a) Plug the 290e in, and allow it to initialise correctly > b) Use xine to watch any DVB-T channel successfully > c) Try switching to previously-tuned DVB-T2 channel; this makes xine hang. > d) Kill xine > e) Physically replug adapter > > em28xx re-initialisation will now fail: > > ... > tda18271: performing RF tracking filter calibration > tda18271: RF tracking filter calibration complete > usb 4-1: USB disconnect, device number 3 > em28xx #0: disconnecting em28xx #0 video > em28xx #0: V4L2 device video1 deregistered > tda18271 7-0060: destroying instance > usb 4-1: new high speed USB device number 4 using ehci_hcd > em28xx: New device PCTV Systems PCTV 290e @ 480 Mbps (2013:024f, interface 0, > class 0) > em28xx #0: chip ID is em28174 > em28xx #0: Identified as PCTV nanoStick T2 290e (card=78) > Registered IR keymap rc-pinnacle-pctv-hd > input: em28xx IR (em28xx #0) as > /devices/pci:00/:00:1d.7/usb4/4-1/rc/rc1/input8 > rc1: em28xx IR (em28xx #0) as /devices/pci:00/:00:1d.7/usb4/4-1/rc/rc1 > em28xx #0: v4l2 driver version 0.1.2 > em28xx #0: V4L2 video device registered as video1 > INFO: task khubd:1217 blocked for more than 120 seconds. > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > khubd D 0 1217 2 0x > 8801a7081ef0 0046 8801a69a9fd8 8162b020 > 00010280 8801a69a9fd8 4000 00010280 > 8801a69a9fd8 8801a7081ef0 00010280 8801a69a8000 > Call Trace: > [] ? apic_timer_interrupt+0xe/0x20 > [] ? memscan+0x3/0x18 > [] ? __mutex_lock_slowpath+0x15c/0x295 > [] ? mutex_lock+0x9/0x18 > [] ? dvb_init+0x99/0xcc8 [em28xx_dvb] > [] ? em28xx_init_extension+0x35/0x53 [em28xx] > [] ? em28xx_usb_probe+0x827/0x8df [em28xx] > > Cheers, > Chris > > -- > 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: PCTV 290e - assorted problems
Hi Chris, Take a look at this breakdown of muxes on the crystal palace transmitter: http://www.ukfree.tv/txdetail.php?a=TQ339712 You'll see mixed power levels and FFT sizes. I have the same thing (albeit with a larger range of power levels) here in Mendip and as a result its very difficult to get certain muxes. You could try a variable attenuator to see if you can trim things a bit to make the tuner/frontend happier getting a lock on all the muxes. It depends on whether the problem is a weak signal or a too strong signal. Of course it might be something else altogether, but this sort of thing is precisely the kind of rubbish we have to deal with during the UK digital switchover. Regards, -- Steve Kerrison MEng Hons. http://www.stevekerrison.com/ On Sun, 2011-08-14 at 16:56 -0700, Chris Rankin wrote: > --- On Mon, 15/8/11, Antti Palosaari wrote: > > T 55400 8MHz + auto auto auto etc. > > is enough. > > Hmm, not here it isn't: > > $ scandvb -u -vvv uk-CrystalPalace > scanning uk-CrystalPalace > using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' > initial transponder 55400 0 9 9 6 2 4 4 > >>> tune to: > >>> 55400:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_AUTO > >>> tuning status == 0x00 > >>> tuning status == 0x00 > >>> tuning status == 0x00 > >>> tuning status == 0x0f > >>> tuning status == 0x0f > >>> tuning status == 0x0f > >>> tuning status == 0x0f > >>> tuning status == 0x0f > >>> tuning status == 0x0f > >>> tuning status == 0x0f > WARNING: >>> tuning failed!!! > >>> tune to: > >>> 55400:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_AUTO > >>> (tuning failed) > >>> tuning status == 0x00 > >>> tuning status == 0x00 > >>> tuning status == 0x00 > >>> tuning status == 0x0f > >>> tuning status == 0x0f > >>> tuning status == 0x0f > >>> tuning status == 0x0f > >>> tuning status == 0x0f > >>> tuning status == 0x0f > >>> tuning status == 0x0f > WARNING: >>> tuning failed!!! > ERROR: initial tuning failed > dumping lists (0 services) > Done. > > Although it was working (briefly) on Saturday morning. > > > Have you tried it on Windows? > > No, because I don't own a Windows machine. > > Cheers, > Chris > > -- > 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: recursive locking problem
At the risk of sounding silly, why do we rely on i2c gating so much? The whole point of i2c is that you can sit a bunch of devices on the same pair of wires and talk to one at a time. Why not just open up the gates and be done with it, except for situations where the i2c chain foolishly has two devices that have the same address because somebody didn't net the address configuration pins correctly, or it's a really big system with more devices on it that a particular chip family has sub-addresses? >From a signal-driving point of view, the gate circuitry is surely a sufficient buffer. I guess the only two things I can think of as real reasons are to 1) reduce the chance of misbehaving devices from causing problems and 2) to save power by not sending clocks and data where we know they aren't needed. Can any one shed some light on this? I appreciate it's not a linux or indeed linux-media specific issue as the hardware itself is designed this way. Getting back to the subject, Antti's af9015 example demonstrates precisely when gating is needed. But I have to ask, does the MXL5003 really only support one address; can it not be reconfigured? it's a bit late to ask that question once the PCB is fabbed, I admit. Would it make any sense to haul the gate locking (or some wrapper at least) up into the uC for that particular configuration? E.g: Tuner driver wants to i2c write tuner 0 Calls i2c_gate_ctrl(open) uC checks if a gate is already open, if it is, and is the same gate as is already open, just carry on. If not, wait on a lock, then set which gate is open and proceed to the 'real' gate_ctrl op. Similar path for i2c_gate_ctrl(close), as relaxed as it needs to be to cope with how different tuner drivers work. You could wrap the checking of which gate is open in a lock for atomicity, and only wait on a device lock where necessary. This way you can also check whether you're trying to change the state of a gate or not and early-out (unless calling gate_ctrl(open) more than once does something /different/ to calling it just once, in which case we're doomed and this was nothing more than naive rambling). Cheers, -- Steve Kerrison MEng Hons. http://www.stevekerrison.com/ On Tue, 2011-09-13 at 23:59 +0300, Antti Palosaari wrote: > On 09/09/2011 01:45 PM, David Waring wrote: > > On 08/09/11 17:34, Antti Palosaari wrote: > >> [snip] > >> > >> Is there any lock can do recursive locking but unlock frees all locks? > >> > >> Like that: > >> gate_open > >> +gate_open > >> +gate_close > >> == lock is free > >> > >> AFAIK mutex can do only simple lock() + unlock(). Semaphore can do > >> recursive locking, like lock() + lock() + unlock() + unlock(). But how I > >> can do lock() + lock() + unlock() == free. > >> > > Antti, > > > > It's a very bad idea to try and use a mutex like that. The number of > > locks and unlocks must be balanced otherwise you risk accessing > > variables without a lock. > > > > Consider: > > > > static struct mutex foo_mutex; > > static int foo=3; > > > > void a() { > >mutex_lock(&foo_mutex); > >if (foo<5) foo++; > >b(); > >foo--; /*<<< still need lock here */ > >mutex_unlock(&foo_mutex); > > } > > > > void b() { > >mutex_lock(&foo_mutex); > >if (foo>6) foo=(foo>>1); > >mutex_unlock(&foo_mutex); > > } > > > > Note: this assumes mutex_lock will allow the same thread get multiple > > locks as you would like (which it doesn't). > > > > As pointed out in the code, when a() is called, you still need the lock > > for accesses to foo after the call to b() that also requires the lock. > > If we used the locks in the way you propose then foo would be accessed > > without a lock. > > > > To code properly for cases like these I usually use a wrapper functions > > to acquire the lock and call a thread unsafe version (i.e. doesn't use > > locks) of the function that only uses other thread unsafe functions. e.g. > > > > void a() { > >mutex_lock(&foo_mutex); > >__a_thr_unsafe(); > >mutex_unlock(&foo_mutex); > > } > > > > void b() { > >mutex_lock(&foo_mutex); > >__b_thr_unsafe(); > >mutex_unlock(&foo_mutex); > > } > > > > static void __a_thr_unsafe() { > >if (foo<5) foo++; > >__b_thr_unsafe(); > >foo--; > > } > > > > static void __b_thr_unsafe() { > >if (foo>6) foo=(foo>>1); > > } > > > > This way a call to a() or b() will
Re: UK Digital Switchover - w_scan results for Mendip transmitter
Hi Rupert, It looks like you're picking up more than just Mendip there; Mendip only has 6 muxes: http://www.ukfree.tv/txdetail.php?a=ST564488 Unless it's announcing other frequencies? I'll do a rescan in MythTV and see what happens. As the switchover progresses and transmit powers are increased, however, some antennae will pick up signals from more than one transmitter. So we should be careful not to assume that the muxes we see are necessarily from the transmitter we think we're pointing at! Cheers, -- Steve Kerrison MEng Hons. http://www.stevekerrison.com/ On Mon, 2011-10-10 at 18:49 +0100, Rupert Plumridge wrote: > Hi > > As part of the UK's digital switchover, it seems some of the pre-set > mux information is now out of date. I don't know the technicals here, > but for example adding channels to tvheadend git version now fails as > the mux information at my location is out of date. > > I used w_scan to check the current situaiton and it gave me the > following for the Mendip Transmitter (since that is where my antennae > is pointed): > > dumping lists (193 services) > #-- > # file automatically generated by w_scan > # > #! 20101001 1 0 OFDM GB > #-- > # location and provider: > # date (-mm-dd): 2011-10-09 > # provided by (opt): > # > # T[2] [# comment] > #-- > T 47400 8MHz AUTO AUTO AUTO AUTO AUTO AUTO > T 49000 8MHz AUTO AUTO AUTO AUTO AUTO AUTO > T 49800 8MHz AUTO AUTO AUTO AUTO AUTO AUTO > T 50600 8MHz AUTO AUTO AUTO AUTO AUTO AUTO > T 51400 8MHz AUTO AUTO AUTO AUTO AUTO AUTO > T 52200 8MHz AUTO AUTO AUTO AUTO AUTO AUTO > T 53000 8MHz AUTO AUTO AUTO AUTO AUTO AUTO > T 634167000 8MHz 2/3 NONEQAM64 8k 1/32 NONE # Wales > T 69800 8MHz 3/4 NONEQAM64 8k 1/32 NONE # Wales > T 65800 8MHz 2/3 NONEQAM64 8k 1/32 NONE # Wales > T 642167000 8MHz 2/3 NONEQAM64 8k 1/32 NONE > T 66600 8MHz 2/3 NONEQAM64 8k 1/32 NONE > T 65000 8MHz AUTO AUTO AUTO AUTO AUTO AUTO > T 69000 8MHz 2/3 NONEQAM64 8k 1/32 NONE # West > T 79400 8MHz 2/3 NONEQAM64 8k 1/32 NONE # West > T 73800 8MHz 2/3 NONEQAM64 8k 1/32 NONE # West > T 72200 8MHz 2/3 NONEQAM64 8k 1/32 NONE # West > T 75400 8MHz 2/3 NONEQAM64 8k 1/32 NONE > T 70600 8MHz AUTO AUTO AUTO AUTO AUTO AUTO > T 73000 8MHz AUTO AUTO AUTO AUTO AUTO AUTO # West > T 76200 8MHz AUTO AUTO AUTO AUTO AUTO AUTO > T 78600 8MHz AUTO AUTO AUTO AUTO AUTO AUTO > T 84200 8MHz AUTO AUTO AUTO AUTO AUTO AUTO # West > > The #West settings seem to work for me on tvheadend, ignore the #Wales > ones, unless you want all the welsh channels, which you don't. > > Hope this is useful. It is all beyond me. > Rupert > -- > 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: Very verbose message about em28174 chip.
Hi, It's normal for em28xx to give you that sort of information on device-plug - it does seem like a lot, but it's effectively "one-off" and you probably won't see much else during use of the device, under default module parameters. It's very useful log output if you have a new device or a slight variant of an existing one, as it takes very little effort to copy & paste the details here to help figure out how easy it is to support the device. But as you know, that device works already, so you can just ignore it :) Regards, Steve. On 28/07/13 14:19, Chris Rankin wrote: Hi, I plugged my PCTV 290e device into my newly compiled 3.10.3 kernel today, and found this message in the dmesg log. [ 511.041412] usb 10-4: new high-speed USB device number 3 using ehci-pci [ 511.216218] em28xx: New device PCTV Systems PCTV 290e @ 480 Mbps (2013:024f, interface 0, class 0) [ 511.223916] em28xx: DVB interface 0 found: isoc [ 511.227398] em28xx: chip ID is em28174 [ 511.548310] em28174 #0: i2c eeprom : 26 00 01 00 02 09 d8 85 80 80 e5 80 f4 f5 94 90 [ 511.54] em28174 #0: i2c eeprom 0010: 78 0d e4 f0 f5 46 12 00 5a c2 eb c2 e8 30 e9 03 [ 511.562682] em28174 #0: i2c eeprom 0020: 12 09 de 30 eb 03 12 09 10 30 ec f1 12 07 72 80 [ 511.569827] em28174 #0: i2c eeprom 0030: ec 00 60 00 e5 f5 64 01 60 09 e5 f5 64 09 60 03 [ 511.576937] em28174 #0: i2c eeprom 0040: c2 c6 22 e5 f7 b4 03 13 e5 f6 b4 87 03 02 09 92 [ 511.584138] em28174 #0: i2c eeprom 0050: e5 f6 b4 93 03 02 07 e6 c2 c6 22 c2 c6 22 12 09 [ 511.591273] em28174 #0: i2c eeprom 0060: cf 02 06 19 1a eb 67 95 13 20 4f 02 c0 13 6b 10 [ 511.598453] em28174 #0: i2c eeprom 0070: a0 1a ba 14 ce 1a 39 57 00 5c 18 00 00 00 00 00 [ 511.605572] em28174 #0: i2c eeprom 0080: 00 00 00 00 44 36 00 00 f0 10 02 00 00 00 00 00 [ 511.612694] em28174 #0: i2c eeprom 0090: 5b 23 c0 00 00 00 20 40 20 80 02 20 01 01 00 00 [ 511.619821] em28174 #0: i2c eeprom 00a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 511.627001] em28174 #0: i2c eeprom 00b0: c6 40 00 00 00 00 a7 00 00 00 00 00 00 00 00 00 [ 511.634120] em28174 #0: i2c eeprom 00c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 38 32 [ 511.641199] em28174 #0: i2c eeprom 00d0: 34 31 30 31 31 36 36 30 31 37 31 31 32 36 58 59 [ 511.648319] em28174 #0: i2c eeprom 00e0: 56 49 00 4f 53 49 30 30 33 30 38 44 30 31 30 36 [ 511.655473] em28174 #0: i2c eeprom 00f0: 58 59 56 49 00 00 00 00 00 00 00 00 00 00 30 36 [ 511.662628] em28174 #0: i2c eeprom 0100: ... (skipped) [ 511.666500] em28174 #0: EEPROM ID = 26 00 01 00, EEPROM hash = 0x1eb936d2 [ 511.672023] em28174 #0: EEPROM info: [ 511.674338] em28174 #0: microcode start address = 0x0004, boot configuration = 0x01 [ 511.705368] em28174 #0: No audio on board. [ 511.708286] em28174 #0: 500mA max power [ 511.710988] em28174 #0: Table at offset 0x00, strings=0x, 0x, 0x [ 511.717120] em28174 #0: Identified as PCTV nanoStick T2 290e (card=78) [ 511.722436] em28174 #0: v4l2 driver version 0.2.0 [ 511.731410] em28174 #0: V4L2 video device registered as video1 [ 511.736043] em28174 #0: dvb set to isoc mode. [ 511.739638] usbcore: registered new interface driver em28xx [ 511.821414] tda18271 7-0060: creating new instance [ 511.829520] TDA18271HD/C2 detected @ 7-0060 [ 512.000542] DVB: registering new adapter (em28174 #0) [ 512.004325] usb 10-4: DVB: registering adapter 0 frontend 0 (Sony CXD2820R)... [ 512.011191] em28174 #0: Successfully loaded em28xx-dvb [ 512.015077] Em28xx: Initialized (Em28xx dvb Extension) extension [ 512.056753] Registered IR keymap rc-pinnacle-pctv-hd [ 512.060784] input: em28xx IR (em28174 #0) as /devices/pci:00/:00:1d.7/usb10/10-4/rc/rc0/input16 [ 512.069167] rc0: em28xx IR (em28174 #0) as /devices/pci:00/:00:1d.7/usb10/10-4/rc/rc0 [ 512.076882] Em28xx: Initialized (Em28xx Input Extension) extension [ 552.064828] tda18271: performing RF tracking filter calibration [ 554.417676] tda18271: RF tracking filter calibration complete Presumably something this verbose is intended to be shared, so here it is. (I can't think of any other reason why this amount of information would be logged by default). Cheers, Chris -- 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 -- Steve Kerrison MEng Hons. http://www.stevekerrison.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
DVB-T2 tuner dismantled: PCTV Nanostick T2 290e
Hello everyone, One of these arrived at my door today, the world's first USB DVB-T2 tuner. So PCs can finally receive Freeview HD here in the UK... but only on Windows. My experience with Linux kernel development is more or less zilch - more of a spectator sport for me, although I've been subscribed to linux-media for a couple of months now. I will help how I can, but I expect that by myself, this would take an awful long time and never make it into the kernel. So everyone's help is appreciated. Pics to follow once my camera battery is recharged, but here is preliminary info: dmesg - [27892.030018] usb 2-2: new high speed USB device using ehci_hcd and address 54 lsusb - Bus 002 Device 054: ID 2013:024f Unknown (Pinnacle?) Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x2013 Unknown (Pinnacle?) idProduct 0x024f bcdDevice1.00 iManufacturer 1 PCTV Systems iProduct2 PCTV 290e iSerial 3 0006LL9R bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 55 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes1 Transfer TypeIsochronous Synch Type None Usage Type Data wMaxPacketSize 0x 1x 0 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x85 EP 5 IN bmAttributes1 Transfer TypeIsochronous Synch Type None Usage Type Data wMaxPacketSize 0x 1x 0 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 1 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes1 Transfer TypeIsochronous Synch Type None Usage Type Data wMaxPacketSize 0x03ac 1x 940 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x85 EP 5 IN bmAttributes1 Transfer TypeIsochronous Synch Type None Usage Type Data wMaxPacketSize 0x03ac 1x 940 bytes bInterval 1 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) PCB --- It's a very small (smaller than most USB-stick tuners) device, implemented on two PCBs sandwiched together. Tuner: NXP TDA18271HDA2 USB IC: Empia em28174 (is this part of the 2874 family, the 2871, or something else? http://www.linuxtv.org/wiki/index.php/Em28xx_devices#em2874 ) Demod: Sony CXD2820R The demod is no surprise given it's about the only T2 compatible demod out there (LSI might have one too, if memory serves). So, what's next? Any PCTV Linux driver contributors active here? I will next attempt to find a datasheet for the Sony demod, then grab some usbsnoop data, although the only Windows machine I have that can get near a fixed antenna is Atom powered... so it ain't great. Questions, requests, demands and insults are all welcomed. Regards, -- Steve Kerrison MEng Hons. http://www.stevekerrison.com/ -- To unsubscribe from this list: send the li
Re: DVB-T2 tuner dismantled: PCTV Nanostick T2 290e
Quick correction: The tuner is TDA18271HDC2 not TDA18271HDA2; it's dark and I'm tired. Photos are now available at http://www.stevekerrison.com/290e/pics.html The most interesting are the two PCB shots. Tuner: http://www.stevekerrison.com/290e/img/tuner.jpg Controller/Demod: http://www.stevekerrison.com/290e/img/hastalavista.jpg I'll put this information into the wiki when I have a chance, and when I can take some better photos in daylight. Regards, -- Steve Kerrison MEng Hons. http://www.stevekerrison.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: DVB-T2 tuner dismantled: PCTV Nanostick T2 290e
Hi Konstantin, That's an interesting observation, and a valid one given, for example, the addition of QAM-256. I don't know enough about T or T2 to know how the difference impact the tuner requirements. Nevertheless, I can receive the T2 mux that is broadcast in my area. It has to be through my roof antenna, and even when digital switchover is complete here, I doubt that portable antennas will work particularly well here then. If PCTV had the option of using the better tuner, maybe they decided not to because the cost of the Sony demod pushed up the BoM too far already. Impossible to say for sure. I guess we'll have to wait and see if somebody brings out a solution with TDA18272/Sony demod combo before we can compare reception quality. Regards, -- Steve Kerrison MEng Hons. http://www.stevekerrison.com/ -Original Message- From: Konstantin Dimitrov To: st...@stevekerrison.com Cc: Anca Emanuel , linux-media@vger.kernel.org Subject: Re: DVB-T2 tuner dismantled: PCTV Nanostick T2 290e Date: Wed, 24 Nov 2010 21:11:07 +0200 On Wed, Nov 24, 2010 at 6:44 PM, wrote: > - it looks like the demod is the only new piece of hardware to deal with and actually it makes DVB-T2 performance of that device very questionable (at least in my opinion), because NXP silicon tuner TDA18271 is old model and not DVB-T2 ready: http://www.nxp.com/#/pip/pip=[pip=TDA18271HD]|pp=[t=pip,i=TDA18271HD] like the new DVB-T2 ready NXP silicon tuner TDA18272: http://www.nxp.com/#/pip/pip=[pip=TDA18272HN_SDS]|pp=[t=pip,i=TDA18272HN_SDS] and so it's quite reasonable to assume that old silicon tuner designed for DVB-T such as TDA18271 is not capable to provide optimal performance for DVB-T2, which has high requirements for sure. --konstantin -- 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: SAA7160 (Compro E750) Drivers
I believe somewhere I have an E700. If somebody does wish to take up development on this then I am willing to ship it to them provided the cost isn't prohibitive. Otherwise I will hang on to it and respond to any requests to run tests if I can. As far as I'm aware there's not much momentum in PCIe tuner support in Linux, so this might be a slow mover, or even or a non-starter. Regards, -- Steve Kerrison MEng Hons. http://www.stevekerrison.com/ On Fri, 2010-11-26 at 20:37 +1100, Marc Bakker wrote: > Hi > > I'm no developer but I can help test. I have an Ubuntu 10.10 server and > have a Compro E750 dual DVB-T video card which isn't yet supported. I have 2 > other tuners working in the machine so I'm happy to take some time to get > this new card going because I can live without it :) > > What can I do to help? > > > A few bits of info... > > lshw > > *-multimedia UNCLAIMED > description: Multimedia controller > product: SAA7160 > vendor: Philips Semiconductors > physical id: 0 > bus info: p...@:03:00.0 > version: 03 > width: 64 bits > clock: 33MHz > capabilities: msi pciexpress pm bus_master cap_list > configuration: latency=0 > resources: memory:dff0-dfff > > > lspci > > :03:00.0 Multimedia controller: Philips Semiconductors SAA7160 (rev > 03) > Subsystem: Compro Technology, Inc. Device e750 > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR+ FastB2B- DisINTx- > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR-Latency: 0, Cache Line Size: 64 bytes > Interrupt: pin A routed to IRQ 11 > Region 0: Memory at dff0 (64-bit, non-prefetchable) [size=1M] > Capabilities: [40] MSI: Enable- Count=1/32 Maskable- 64bit+ > Address: Data: > Capabilities: [50] Express (v1) Endpoint, MSI 00 > DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <256ns, > L1 <1us > ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- > DevCtl: Report errors: Correctable- Non-Fatal- Fatal- > Unsupported- > RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop- > MaxPayload 128 bytes, MaxReadReq 128 bytes > DevSta: CorrErr- UncorrErr+ FatalErr- UnsuppReq+ AuxPwr- > TransPend- > LnkCap: Port #1, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency > L0 <4us, L1 <64us > ClockPM- Surprise- LLActRep- BwNot- > LnkCtl: ASPM Disabled; RCB 128 bytes Disabled- Retrain- CommClk- > ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- > LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk- > DLActive- BWMgmt- ABWMgmt- > Capabilities: [74] Power Management version 2 > Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA > PME(D0+,D1+,D2+,D3hot-,D3cold-) > Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- > Capabilities: [80] Vendor Specific Information: Len=50 > Capabilities: [100 v1] Vendor Specific Information: ID= Rev=0 > Len=088 > > > vendor ID's -- 1131:7160 (rev 03) > > > Cheers > Marc > > > -- > 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: DVB_T2 Multistream support (PLP)
Hi Michael, In terms of Linux support I think you will struggle. The 290e is the only DVB-T2 device with (open) driver support in Linux. I haven't tried a TBS5880 myself but the linuxtv Wiki page doesn't look promising http://www.linuxtv.org/wiki/index.php/TBS5880_USB_DVB-T2/T/C_CI_hybrid_TV_Box In any case, that device will have the same demod (CXD2820R), and if what Antti says about the Windows driver not supporting multi-PLP either (if I've read his remarks correctly), you're probably out of luck. As far as I know the CXD2820R is the only T2 demod that's made it into any USB/PCI receivers so there are no other options. There might be a datasheet somewhere that would hint at how to provide PLP selection and then it would need implementing. The question is where to find it and how much effort would be required. Regards, Steve. On 31/01/13 15:02, Michael Stilmant-Rovi wrote: Thanks, Looking for a tuner supporting multiple PLP, is it conceivable to add to the driver the possibility to pass to the hardware that value? (I don't know if that need other math though) ( I will look the sources anyway but I don't have good knowledge) If I want to look for another USB stick how could I know if the driver will support that feature? For example is TBS5880 DVB-T2 USB TV Tuner ? I understand here that the difficulties is that few people are in a MultiPLP DVB_T2 range. even myself.. . Regards, On Thu, Jan 31, 2013 at 3:39 PM, Antti Palosaari wrote: On 01/31/2013 04:27 PM, Michael Stilmant-Rovi wrote: Hello, I would like to know the support status of Multiple PLPs in DVB-T2. Is someone know if tests were performed in a broadcast with an effective Multistream? (PLP Id: 0 and 1 for example) I'm out of range of such multiplex but I'm trying some tunes on London DVB-T2 (CrystalPalace tower) "unfortunately" that mux seems Single PLP and everything work well :-( ( yes tune always succeed :-D ) I'm using DVB API 5.6. If I tune with FE_SET_PROPERTY without or with DTV_DVBT2_PLP_ID set to 0, 1 or 15. the tune succeed. I'm not sure of the expected behavior, I was expecting if I tune with plp_id 1 that the tuner would fail somewhere finding that stream. So in short I don't understand what is the requirements to be able to use the DVB_T2 Multistream support proposed in APIs: o I see that the DVB API 5.8(?) had some patch at that level and so it is maybe requested? o How can I know if my driver support that feature on DVB API 5.6? (PCTV nanoStick T2 290e)? Thank you for all indications. -Michael nanoStick T2 290e Linux driver does not support multiple PLPs. I did that driver and I has only Live signal with single TS. What I think Windows driver either supports that feature. It just tunes to first PLP regardless of whole property and that's it. regards Antti -- http://palosaari.fi/ On Thu, Jan 31, 2013 at 3:39 PM, Antti Palosaari wrote: On 01/31/2013 04:27 PM, Michael Stilmant-Rovi wrote: Hello, I would like to know the support status of Multiple PLPs in DVB-T2. Is someone know if tests were performed in a broadcast with an effective Multistream? (PLP Id: 0 and 1 for example) I'm out of range of such multiplex but I'm trying some tunes on London DVB-T2 (CrystalPalace tower) "unfortunately" that mux seems Single PLP and everything work well :-( ( yes tune always succeed :-D ) I'm using DVB API 5.6. If I tune with FE_SET_PROPERTY without or with DTV_DVBT2_PLP_ID set to 0, 1 or 15. the tune succeed. I'm not sure of the expected behavior, I was expecting if I tune with plp_id 1 that the tuner would fail somewhere finding that stream. So in short I don't understand what is the requirements to be able to use the DVB_T2 Multistream support proposed in APIs: o I see that the DVB API 5.8(?) had some patch at that level and so it is maybe requested? o How can I know if my driver support that feature on DVB API 5.6? (PCTV nanoStick T2 290e)? Thank you for all indications. -Michael nanoStick T2 290e Linux driver does not support multiple PLPs. I did that driver and I has only Live signal with single TS. What I think Windows driver either supports that feature. It just tunes to first PLP regardless of whole property and that's it. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Steve Kerrison MEng Hons. http://www.stevekerrison.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: comments for DVB LNA API
Hi Antti, On 10/07/12 17:20, Antti Palosaari wrote: I am looking how to implement LNA support for the DVB API. What we need to be configurable at least is: OFF, ON, AUTO. There is LNAs that support variable gain and likely those will be sooner or later. Actually I think there is already LNAs integrated to the RF-tuner that offers adjustable gain. Also looking to NXP catalog and you will see there is digital TV LNAs with adjustable gain. Coming from that requirements are: adjustable gain 0-xxx dB LNA OFF LNA ON LNA AUTO Setting LNA is easy but how to query capabilities of supported LNA values? eg. this device has LNA which supports Gain=5dB, Gain=8dB, LNA auto? Without having a sample of device capabilities this question may be irrelevant, but what if the gain is somewhat continuiously configurable vs. discretized? For example can some be configured just for 5,8 and 11, whilst some might have some 8-bit value that controls gain between 5 and 11? LNA ON (bypass) could be replaced with Gain=0 and LNA ON with Gain>0, Gain=-1 is for auto example. How should the API handle differences between the specified gain and the capabilities of the LNA? Round to nearest possible config if it's within the operating range; return error if out of range? regards Antti -- Steve Kerrison MEng Hons. http://www.stevekerrison.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: Display hotplug
Hi James, When I plug my laptop's (Toshiba R630, Intel i3 with integrated on-die graphics) HDMI port into a TV, the display manager in Ubuntu is able to detect it and, after a click or two, mirror or extended-desktop to it. So I would say the answer is... it already does. It's more likely that your distribution doesn't have the tools you need to do what you want, or the driver for your graphics device needs some work :) And I don't think this problem falls into the remit of linux-media; graphics drivers are dealt with elsewhere, aren't they? -- Steve Kerrison MEng Hons. http://www.stevekerrison.com/ On Tue, 2011-10-25 at 10:09 +0100, James Courtier-Dutton wrote: > Hi, > > Does anyone know when X will support display hotplug? > I have a PC connected via HDMI to a TV. > Unless I turn the TV on first, I have to reboot the PC before it > displays anything on the HDMI TV. > > Kind Regards > > James > -- > 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