rtl2832: PID filter support for slave demod
Subsystems (2)
RFC PATCH 1/1 rtl2832: PID filter support for slave demod
Is this structure ok for the slave pid implementation? Or should there be only one filters parameter? Will the overlaying pid filter framework properly "flush" the set pid filters ?
Note that this code currently is only compile tested.
MvH
Benjamin Larsson
Quoted 1 line
From
8efb26c18b4f9416bd516195c6a82853c9cccc24Mon Sep 17 00:00:00 2001
From: Benjamin Larsson <[email protected]>
Date: Mon, 16 Mar 2015 22:59:50 +0100
Subject: [PATCH] rtl2832: PID filter support for slave demod
Cc: Linux Media Mailing List <[email protected]>
RTL2832p supports a slave configuration with a demodulator connected to a ts input on the chip. This makes it possible to receive DVB-T2 muxes that are of larger size then what the rtl2832p usb-bridge is capable of transfering.
--- drivers/media/dvb-frontends/rtl2832.c | 40 ++++++++++++++++++++++-------- drivers/media/dvb-frontends/rtl2832_priv.h | 2 ++ 2 files changed, 32 insertions(+), 10 deletions(-)
drivers/media/dvb-frontends/rtl2832.c +30 -10
@@ -488,6 +488,8 @@ static int rtl2832_set_frontend(struct dvb_frontend *fe)if (ret) goto err; + dev->slave_demod_active =0 ; +/* If the frontend has get_if_frequency(), use it */ if (fe->ops.tuner_ops.get_if_frequency) {u32 if_freq;
@@ -1114,6 +1116,8 @@ static int rtl2832_enable_slave_ts(struct i2c_client *client)if (ret) goto err; + dev->slave_demod_active =1 ; +return 0 ; err:dev_dbg (&client->dev,"failed=%d\n" , ret);
@@ -1135,7 +1139,10 @@ static int rtl2832_pid_filter_ctrl(struct dvb_frontend *fe, int onoff)else u8tmp =0x00 ; - ret =rtl2832_update_bits (client,0x061 ,0xc0 , u8tmp); +if (dev->slave_demod_active) + ret =rtl2832_update_bits (client,0x021 ,0xc0 , u8tmp); +else + ret =rtl2832_update_bits (client,0x061 ,0xc0 , u8tmp);if (ret) goto err;
@@ -1152,6 +1159,7 @@ static int rtl2832_pid_filter(struct dvb_frontend *fe, u8 index, u16 pid,struct i2c_client *client = dev->client;int ret;u8 buf[4 ]; +unsigned long * filters;dev_dbg (&client->dev,"index=%d pid=%04x onoff=%d\n" , index, pid, onoff);
@@ -1160,24 +1168,36 @@ static int rtl2832_pid_filter(struct dvb_frontend *fe, u8 index, u16 pid,if (pid >0x1fff || index >32 )return 0 ; -if (onoff) -set_bit (index, &dev->filters); +if (dev->slave_demod_active) + filters = &dev->filters_slave;else -clear_bit (index, &dev->filters); + filters = &dev->filters; + +if (onoff) { +set_bit (index, filters); + }else { +clear_bit (index, filters); + }/* enable / disable PIDs */ - buf[0 ] = (dev->filters >>0 ) &0xff ; - buf[1 ] = (dev->filters >>8 ) &0xff ; - buf[2 ] = (dev->filters >>16 ) &0xff ; - buf[3 ] = (dev->filters >>24 ) &0xff ; - ret =rtl2832_bulk_write (client,0x062 , buf,4 ); + buf[0 ] = (*filters >>0 ) &0xff ; + buf[1 ] = (*filters >>8 ) &0xff ; + buf[2 ] = (*filters >>16 ) &0xff ; + buf[3 ] = (*filters >>24 ) &0xff ; +if (dev->slave_demod_active) + ret =rtl2832_bulk_write (client,0x022 , buf,4 ); +else + ret =rtl2832_bulk_write (client,0x062 , buf,4 );if (ret) goto err;/* add PID */ buf[0 ] = (pid >>8 ) &0xff ; buf[1 ] = (pid >>0 ) &0xff ; - ret =rtl2832_bulk_write (client,0x066 +2 * index, buf,2 ); +if (dev->slave_demod_active) + ret =rtl2832_bulk_write (client,0x026 +2 * index, buf,2 ); +else + ret =rtl2832_bulk_write (client,0x066 +2 * index, buf,2 );if (ret) goto err;
drivers/media/dvb-frontends/rtl2832_priv.h +2 -0
@@ -46,6 +46,8 @@ struct rtl2832_dev {bool sleeping;struct delayed_work i2c_gate_work;unsigned long filters;/* PID filter */ +unsigned long filters_slave;/* PID filter */ +int slave_demod_active; };struct rtl2832_reg_entry {
Signature · 1 line
2.1.0
Quoted 5 lines · Benjamin Larsson
Is this structure ok for the slave pid implementation? Or should there be only one filters parameter? Will the overlaying pid filter framework properly "flush" the set pid filters ?
Note that this code currently is only compile tested.
I am fine with it.
byw. Have you tested if your QAM256 (DVB-C or DVB-T2) stream is valid even without a PID filtering? IIRC mine stream is correct and PID filtering is not required (but surely it could be implemented if you wish).
regards
Antti
Signature · 1 line
http://palosaari.fi/
Quoted 7 lines · Antti Palosaari
Quoted 5 lines · Benjamin Larsson
Is this structure ok for the slave pid implementation? Or should there be only one filters parameter? Will the overlaying pid filter framework properly "flush" the set pid filters ?
Note that this code currently is only compile tested.
Quoted 9 lines
I am fine with it.
byw. Have you tested if your QAM256 (DVB-C or DVB-T2) stream is valid even without a PID filtering? IIRC mine stream is correct and PID filtering is not required (but surely it could be implemented if you wish).
regards
Antti
DVB-C seems fine and one of my DVB-T2 muxes is fine also. But one other DVB-T2 mux completely fails. It could be the reception but it might be that it needs pid filtering. I do get small disturbances on my DVB-C muxes. Will report back if pid filtering makes things better or not.
MvH
Benjamin Larsson
Em Tue, 17 Mar 2015 00:16:06 +0100 Benjamin Larsson <[email protected]> escreveu:
Quoted 14 lines · Antti Palosaari
Quoted 13 lines · Benjamin Larsson
Quoted 5 lines
Is this structure ok for the slave pid implementation? Or should there be only one filters parameter? Will the overlaying pid filter framework properly "flush" the set pid filters ?
Note that this code currently is only compile tested.
I am fine with it.
byw. Have you tested if your QAM256 (DVB-C or DVB-T2) stream is valid even without a PID filtering? IIRC mine stream is correct and PID filtering is not required (but surely it could be implemented if you wish).
Quoted 8 lines
Quoted 3 lines
regards
AnttiDVB-C seems fine and one of my DVB-T2 muxes is fine also. But one other DVB-T2 mux completely fails. It could be the reception but it might be that it needs pid filtering. I do get small disturbances on my DVB-C muxes. Will report back if pid filtering makes things better or not.
What's the status of this patch?
Btw, checkpatch.pl complains about a few things there:
WARNING: 'transfering' may be misspelled - perhaps 'transferring'? #31: capable of transfering.
ERROR: "foo* bar" should be "foo *bar"
#77: FILE: drivers/media/dvb-frontends/rtl2832.c:1162:
+ unsigned long* filters;
WARNING: braces {} are not necessary for any arm of this statement #93: FILE: drivers/media/dvb-frontends/rtl2832.c:1176:
+ if (onoff) {
[...]
+ } else {
[...]
total: 1 errors, 2 warnings, 87 lines checked
For now, as it was sent as RFC, I'll tag as such at patchwork.
If this is patch is pertinent, please re-send it (with the coding style issues pointed by checkpatch.pl fixed).
Regards,
Mauro
Quoted 7 lines
MvH
Benjamin Larsson
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html