Re: af9035 test needed!
Il 31/01/2013 19:52, Antti Palosaari ha scritto: > Jose, Gianluca, > > On 01/31/2013 08:40 PM, Andre Heider wrote: >> Hey, >> >> On Thu, Jan 31, 2013 at 2:59 PM, Antti Palosaari wrote: On Fri, Jan 11, 2013 at 7:38 PM, Antti Palosaari wrote: > > Could you test that (tda18218 & mxl5007t): >> >> only now I see you mentioned mxl5007t too, and with the same tree as I >> used for my 'TerraTec Cinergy T Stick Dual RC (rev. 2)', a 'AVerMedia >> HD Volar (A867)' with a mxl5007t (and an unkown rev) works too: >> >> usb 3-3.1.4: new high-speed USB device number 7 using xhci_hcd >> usb 3-3.1.4: New USB device found, idVendor=07ca, idProduct=1867 >> usb 3-3.1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 >> usb 3-3.1.4: Product: A867 >> usb 3-3.1.4: Manufacturer: AVerMedia TECHNOLOGIES, Inc >> usb 3-3.1.4: SerialNumber: 0305770200261 >> usb 3-3.1.4: af9035_identify_state: prechip_version=00 chip_version=03 >> chip_type=3802 > > Who one as able to test with non-working AF9035 + MxL5007T combination. > Does it report different chip versions? Same firmware used? Hi Antti, I finally found a friend with the Avermedia A867 (AF9035 + MxL5007T) non working revision (A867-DP7): http://forum.ubuntu-it.org/viewtopic.php?f=9&t=516182&start=60#p4301226 Apparently, there is no difference in the log file about the chip version: [ 90.047319] usb 1-1.3: New USB device found, idVendor=07ca, idProduct=a867 [ 90.047325] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 90.047330] usb 1-1.3: Product: A867 [ 90.047334] usb 1-1.3: Manufacturer: AVerMedia TECHNOLOGIES, Inc [ 90.047337] usb 1-1.3: SerialNumber: 5037944035440 [ 90.142796] usbcore: registered new interface driver dvb_usb_af9035 [ 90.143779] usb 1-1.3: af9035_identify_state: prechip_version=00 chip_version=03 chip_type=3802 [ 90.144178] usb 1-1.3: dvb_usb_v2: found a 'AVerMedia HD Volar (A867)' in cold state [ 90.170437] usb 1-1.3: dvb_usb_v2: downloading firmware from file 'dvb-usb-af9035-02.fw' [ 90.495461] usb 1-1.3: dvb_usb_af9035: firmware version=12.13.15.0 [ 90.495483] usb 1-1.3: dvb_usb_v2: found a 'AVerMedia HD Volar (A867)' in warm state [ 90.498004] usb 1-1.3: dvb_usb_v2: will pass the complete MPEG2 transport stream to the software demuxer [ 90.498046] DVB: registering new adapter (AVerMedia HD Volar (A867)) [ 90.498401] DVB: register adapter0/demux0 @ minor: 0 (0x00) [ 90.498476] DVB: register adapter0/dvr0 @ minor: 1 (0x01) [ 90.498543] DVB: register adapter0/net0 @ minor: 2 (0x02) [ 90.549788] i2c i2c-8: af9033: firmware version: LINK=12.13.15.0 OFDM=6.20.15.0 [ 90.549798] usb 1-1.3: DVB: registering adapter 0 frontend 0 (Afatech AF9033 (DVB-T))... [ 90.549903] DVB: register adapter0/frontend0 @ minor: 3 (0x03) [ 90.913945] mxl5007t 8-0060: creating new instance [ 90.929824] Registered IR keymap rc-empty [ 90.929937] input: AVerMedia HD Volar (A867) as /devices/pci:00/:00:1a.0/usb1/1-1/1-1.3/rc/rc0/input13 [ 90.930019] rc0: AVerMedia HD Volar (A867) as /devices/pci:00/:00:1a.0/usb1/1-1/1-1.3/rc/rc0 [ 90.930027] usb 1-1.3: dvb_usb_v2: schedule remote query interval to 500 msecs [ 90.930032] usb 1-1.3: dvb_usb_v2: 'AVerMedia HD Volar (A867)' successfully initialized and connected Also, the stick works fine with Jose's patch, independently from the firmware file used. Regards, Gianluca > > >> usb 3-3.1.4: dvb_usb_v2: found a 'AVerMedia HD Volar (A867)' in cold >> state >> usb 3-3.1.4: dvb_usb_v2: downloading firmware from file >> 'dvb-usb-af9035-02.fw' >> usb 3-3.1.4: dvb_usb_af9035: firmware version=11.5.9.0 >> usb 3-3.1.4: dvb_usb_v2: found a 'AVerMedia HD Volar (A867)' in warm >> state >> usb 3-3.1.4: dvb_usb_v2: will pass the complete MPEG2 transport stream >> to the software demuxer >> DVB: registering new adapter (AVerMedia HD Volar (A867)) >> i2c i2c-19: af9033: firmware version: LINK=11.5.9.0 OFDM=5.17.9.1 >> usb 3-3.1.4: DVB: registering adapter 1 frontend 0 (Afatech AF9033 >> (DVB-T))... >> mxl5007t 19-0060: creating new instance >> mxl5007t_get_chip_id: unknown rev (3f) >> mxl5007t_get_chip_id: MxL5007T detected @ 19-0060 >> Registered IR keymap rc-empty >> input: AVerMedia HD Volar (A867) as >> /devices/pci:00/:00:14.0/usb3/3-3/3-3.1/3-3.1.4/rc/rc5/input29 >> rc5: AVerMedia HD Volar (A867) as >> /devices/pci:00/:00:14.0/usb3/3-3/3-3.1/3-3.1.4/rc/rc5 >> usb 3-3.1.4: dvb_usb_v2: schedule remote query interval to 500 msecs >> usb 3-3.1.4: dvb_usb_v2: 'AVerMedia HD Volar (A867)' successfully >> initialized and connected > > regards > Antti > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: af9035 test needed!
Hi, On Thu, Jan 31, 2013 at 2:46 PM, Michael Krufky wrote: > Hey guys... somehow this email slipped through my filters :-( I see > it now, and I'll give a look over the patch this weekend. I suspect the merge window opens soon, so... *poke* ;) Any chance for 3.9? Thanks, Andre -- 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: af9035 test needed!
On Sun, Feb 3, 2013 at 3:29 PM, Antti Palosaari wrote: > On 02/03/2013 09:53 PM, Michael Krufky wrote: >> >> (history chopped cuz it got messy) >> >> quoting Antti with my responses inline. >> >> << >> I agree that it should be split multiple patches. >> >> KRUFKY: YES. >> >> 1) soft reset should be moved to attach() (it could not be on init() >> nor set_parameters() as it stops clock out and loop-through in few ms >> or so causing slave tuner errors) >> >> KRUFKY: NO. This is not the solution. If there is a bug in the >> driver, then we fix the bug. Moving the soft reset to a one time only >> call during attach can cause worse problems. If you feel strongly >> about this, then submit it in a separate patch and we can work on that >> issue separately. The soft reset needs to be done each time the tuner >> is programmed for good reason - if we are screwing up some registers, >> then it means that there is a bug - lets fix the bug. > > > You cannot do soft reset all the time. MxL5007t soft reset looks like just > jump instruction to chip reset vector, it simply clears all the registers to > the default state (I think just same state as power on reset). > > That means you taint clock output and loop-through every time you call that > soft reset. Why the hell there is such outputs offered by the chip if those > are aimed to shut off frequently by soft resetting chip? Such outputs are > useless. Due to that analogy, there will be only one conclusion: soft reset > is not aimed to be called for every tuning attempt. > > It is just easy way to ensure chip is known default state on attach(). For > example you warm boot from windows to linux and wish to ensure chip is known > state after attach(). It is driver bug if soft resetting all the registers > to default is needed frequently in order to operate normally! > > > >> 2) clock out and loop-through must be set on attach() and not touch after >> that >> >> KRUFKY: NO. attach() is called once, ever. I admit that the current >> code may be buggy but doing this would cause unpredicable behavior >> after low-power states... If this needs to be fixed then it needs to >> be fixed in a thorough way, not by moving the code away into the >> attach function where it will only be called once. Clearly this issue >> is directly related to issue number 1, so I understand if these two >> items might be the focus of future discussion :-/ > > > Shutting down clock output when not needed surely saves few mA from the > current drain. But currently there is no DVB framework support for it, so > better to leave clock out enabled always. It is relative small amount of > current you will save - there is a lot of bigger power management issues > about all the drivers currently. > > > >> 3) no_probe option should not be added unless it is really needed. If >> chip ID reading fails with some I/O error then there is two >> possibilities a) block reads like now b) add glue to AF9035 brain-dead >> I2C adapter to handle / fake such case >> >> KRUFKY: I agree -- this may be required in order to work around some >> questionable hardware implementations. If the problem is really in >> the i2c adapter, then the hack belongs there, not in the tuner driver. > > > The one thing what I think I has already mentioned for Jose - test some > other tuner IDs. There is many tuners supported by AF9035 FW and about all > of those uses register reads. So telling wrong tuner ID to AF9035 just > before attach tuner could do the trick. And after successful tuner attach > just tell AF9035 FW that MXL5007T tuner id. > > >> 4) loop_thru_enable to 3 bit wide should not be done unless really >> needed. What happens if it is left as it is? >> >> KRUFKY: Agreed. We don't make a change just because you saw something >> in 'the windows driver' As per the current Linux driver, the loop >> thru setting is 1 bit wide. If this is wrong, please provide a better >> explanation of those bits. >> >> These are the four logical changes that should be sent as own patch. >> Jose, we are waiting for you :) >> >> -Mike >> > > Antti I was just thinking and I realize fault in my own arguments where I said "No." ... Coincidentally you sent this email just as I was thinking of doing the same. I retract my "No" s :-) Let's just see a patch series and we'll evaluate each patch individually. Cheers, Mike -- 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: af9035 test needed!
On 02/03/2013 09:53 PM, Michael Krufky wrote: (history chopped cuz it got messy) quoting Antti with my responses inline. << I agree that it should be split multiple patches. KRUFKY: YES. 1) soft reset should be moved to attach() (it could not be on init() nor set_parameters() as it stops clock out and loop-through in few ms or so causing slave tuner errors) KRUFKY: NO. This is not the solution. If there is a bug in the driver, then we fix the bug. Moving the soft reset to a one time only call during attach can cause worse problems. If you feel strongly about this, then submit it in a separate patch and we can work on that issue separately. The soft reset needs to be done each time the tuner is programmed for good reason - if we are screwing up some registers, then it means that there is a bug - lets fix the bug. You cannot do soft reset all the time. MxL5007t soft reset looks like just jump instruction to chip reset vector, it simply clears all the registers to the default state (I think just same state as power on reset). That means you taint clock output and loop-through every time you call that soft reset. Why the hell there is such outputs offered by the chip if those are aimed to shut off frequently by soft resetting chip? Such outputs are useless. Due to that analogy, there will be only one conclusion: soft reset is not aimed to be called for every tuning attempt. It is just easy way to ensure chip is known default state on attach(). For example you warm boot from windows to linux and wish to ensure chip is known state after attach(). It is driver bug if soft resetting all the registers to default is needed frequently in order to operate normally! 2) clock out and loop-through must be set on attach() and not touch after that KRUFKY: NO. attach() is called once, ever. I admit that the current code may be buggy but doing this would cause unpredicable behavior after low-power states... If this needs to be fixed then it needs to be fixed in a thorough way, not by moving the code away into the attach function where it will only be called once. Clearly this issue is directly related to issue number 1, so I understand if these two items might be the focus of future discussion :-/ Shutting down clock output when not needed surely saves few mA from the current drain. But currently there is no DVB framework support for it, so better to leave clock out enabled always. It is relative small amount of current you will save - there is a lot of bigger power management issues about all the drivers currently. 3) no_probe option should not be added unless it is really needed. If chip ID reading fails with some I/O error then there is two possibilities a) block reads like now b) add glue to AF9035 brain-dead I2C adapter to handle / fake such case KRUFKY: I agree -- this may be required in order to work around some questionable hardware implementations. If the problem is really in the i2c adapter, then the hack belongs there, not in the tuner driver. The one thing what I think I has already mentioned for Jose - test some other tuner IDs. There is many tuners supported by AF9035 FW and about all of those uses register reads. So telling wrong tuner ID to AF9035 just before attach tuner could do the trick. And after successful tuner attach just tell AF9035 FW that MXL5007T tuner id. 4) loop_thru_enable to 3 bit wide should not be done unless really needed. What happens if it is left as it is? KRUFKY: Agreed. We don't make a change just because you saw something in 'the windows driver' As per the current Linux driver, the loop thru setting is 1 bit wide. If this is wrong, please provide a better explanation of those bits. These are the four logical changes that should be sent as own patch. Jose, we are waiting for you :) -Mike Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: af9035 test needed!
(history chopped cuz it got messy) quoting Antti with my responses inline. << I agree that it should be split multiple patches. KRUFKY: YES. 1) soft reset should be moved to attach() (it could not be on init() nor set_parameters() as it stops clock out and loop-through in few ms or so causing slave tuner errors) KRUFKY: NO. This is not the solution. If there is a bug in the driver, then we fix the bug. Moving the soft reset to a one time only call during attach can cause worse problems. If you feel strongly about this, then submit it in a separate patch and we can work on that issue separately. The soft reset needs to be done each time the tuner is programmed for good reason - if we are screwing up some registers, then it means that there is a bug - lets fix the bug. 2) clock out and loop-through must be set on attach() and not touch after that KRUFKY: NO. attach() is called once, ever. I admit that the current code may be buggy but doing this would cause unpredicable behavior after low-power states... If this needs to be fixed then it needs to be fixed in a thorough way, not by moving the code away into the attach function where it will only be called once. Clearly this issue is directly related to issue number 1, so I understand if these two items might be the focus of future discussion :-/ 3) no_probe option should not be added unless it is really needed. If chip ID reading fails with some I/O error then there is two possibilities a) block reads like now b) add glue to AF9035 brain-dead I2C adapter to handle / fake such case KRUFKY: I agree -- this may be required in order to work around some questionable hardware implementations. If the problem is really in the i2c adapter, then the hack belongs there, not in the tuner driver. 4) loop_thru_enable to 3 bit wide should not be done unless really needed. What happens if it is left as it is? KRUFKY: Agreed. We don't make a change just because you saw something in 'the windows driver' As per the current Linux driver, the loop thru setting is 1 bit wide. If this is wrong, please provide a better explanation of those bits. These are the four logical changes that should be sent as own patch. Jose, we are waiting for you :) >> -Mike -- 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: af9035 test needed!
On 02/03/2013 09:27 PM, Michael Krufky wrote:
On Sun, Feb 3, 2013 at 8:21 AM, Antti Palosaari wrote:
On 02/03/2013 02:04 PM, Jose Alberto Reguero wrote:
On Sábado, 2 de febrero de 2013 23:00:45 Michael Krufky escribió:
On Fri, Jan 11, 2013 at 6:45 PM, Jose Alberto Reguero
wrote:
On Viernes, 11 de enero de 2013 20:38:01 Antti Palosaari escribió:
Hello Jose and Gianluca
Could you test that (tda18218 & mxl5007t):
http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/it9135_t
une r
I wonder if ADC config logic still works for superheterodyne tuners
(tuner having IF). I changed it to adc / 2 always due to IT9135 tuner.
That makes me wonder it possible breaks tuners having IF, as ADC was
clocked just over 20MHz and if it is half then it is 10MHz. For BB that
is enough, but I think that having IF, which is 4MHz at least for 8MHz
BW it is too less.
F*ck I hate to maintain driver without a hardware! Any idea where I can
get AF9035 device having tda18218 or mxl5007t?
regards
Antti
Still pending the changes for mxl5007t. Attached is a patch for that.
Changes to make work Avermedia Twinstar with the af9035 driver.
Signed-off-by: Jose Alberto Reguero
Jose Alberto
diff -upr linux/drivers/media/tuners/mxl5007t.c
linux.new/drivers/media/tuners/mxl5007t.c
--- linux/drivers/media/tuners/mxl5007t.c 2012-08-14
05:45:22.0 +0200 +++ linux.new/drivers/media/tuners/mxl5007t.c
2013-01-10 19:23:09.247556275 +0100
@@ -374,7 +374,6 @@ static struct reg_pair_t *mxl5007t_calc_
mxl5007t_set_if_freq_bits(state, cfg->if_freq_hz,
cfg->invert_if);
mxl5007t_set_xtal_freq_bits(state, cfg->xtal_freq_hz);
- set_reg_bits(state->tab_init, 0x04, 0x01,
cfg->loop_thru_enable);
set_reg_bits(state->tab_init, 0x03, 0x08, cfg->clk_out_enable
<<
3);
set_reg_bits(state->tab_init, 0x03, 0x07, cfg->clk_out_amp);
This is a configurable option - it should not be removed, just
configure your glue code to not use that option if you dont want
it unless there's some other reason why you're removing this?
I just move the code to a mxl5007t_attach because with dual tuner until
the
code is executed, the other tuner don't work. It can be left here also.
@@ -531,9 +530,12 @@ static int mxl5007t_tuner_init(struct mx
struct reg_pair_t *init_regs;
int ret;
- ret = mxl5007t_soft_reset(state);
- if (mxl_fail(ret))
+ if (!state->config->no_reset) {
+ ret = mxl5007t_soft_reset(state);
+ if (mxl_fail(ret))
goto fail;
+ }
+
this seems wrong to me. why would you want to prevent the driver from
doing a soft reset?
That is because with my hardware and dual tuner, when one tuner do reset,
the
other one is perturbed, and the stream has errors.
/* calculate initialization reg array */
init_regs = mxl5007t_calc_init_regs(state, mode);
@@ -887,7 +889,12 @@ struct dvb_frontend *mxl5007t_attach(str
if (fe->ops.i2c_gate_ctrl)
fe->ops.i2c_gate_ctrl(fe, 1);
- ret = mxl5007t_get_chip_id(state);
+ if (!state->config->no_probe)
+ ret = mxl5007t_get_chip_id(state);
+
+ ret = mxl5007t_write_reg(state, 0x04,
+ state->config->loop_thru_enable);
+
Can you explain why this change was made? ^^
mxl5007t_get_chip_id has a read, and with the hardware I have, after the
read
operation is made, communication with the chip don't work.
if (fe->ops.i2c_gate_ctrl)
fe->ops.i2c_gate_ctrl(fe, 0);
diff -upr linux/drivers/media/tuners/mxl5007t.h
linux.new/drivers/media/tuners/mxl5007t.h
--- linux/drivers/media/tuners/mxl5007t.h 2012-08-14
05:45:22.0 +0200 +++ linux.new/drivers/media/tuners/mxl5007t.h
2013-01-10 19:19:11.204379581 +0100
@@ -73,8 +73,10 @@ struct mxl5007t_config {
enum mxl5007t_xtal_freq xtal_freq_hz;
enum mxl5007t_if_freq if_freq_hz;
unsigned int invert_if:1;
- unsigned int loop_thru_enable:1;
+ unsigned int loop_thru_enable:3;
Why widen this boolean to three bits?
I just use the value 3 for this option(taken from windows driver) and it
works
well.
Thanks for review the code.
Jose Alberto
unsigned int clk_out_enable:1;
+ unsigned int no_probe:1;
+ unsigned int no_reset:1;
};
#if defined(CONFIG_MEDIA_TUNER_MXL5007T) ||
(defined(CONFIG_MEDIA_TUNER_MXL5007T_MODULE) && defined(MODULE))
diff -upr linux/drivers/media/usb/dvb-usb-v2/af9035.c
linux.new/drivers/media/usb/dvb-usb-v2/af9035.c
--- linux/drivers/media/usb/dvb-usb-v2/af9035.c 2013-01-07
05:45:57.0 +0100
+++ linux.new/drivers/media/usb/dvb-usb-v2/af9035.c 2013-01-12
00:30:57.557310465 +0100
@@ -886,13 +886,17 @@ static struct mxl5007t_config af9035_mxl
.loop_thru_enable = 0,
Re: af9035 test needed!
On Sun, Feb 3, 2013 at 8:21 AM, Antti Palosaari wrote:
> On 02/03/2013 02:04 PM, Jose Alberto Reguero wrote:
>>
>> On Sábado, 2 de febrero de 2013 23:00:45 Michael Krufky escribió:
>>>
>>> On Fri, Jan 11, 2013 at 6:45 PM, Jose Alberto Reguero
>>>
>>> wrote:
On Viernes, 11 de enero de 2013 20:38:01 Antti Palosaari escribió:
>
> Hello Jose and Gianluca
>
> Could you test that (tda18218 & mxl5007t):
>
> http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/it9135_t
> une r
>
> I wonder if ADC config logic still works for superheterodyne tuners
> (tuner having IF). I changed it to adc / 2 always due to IT9135 tuner.
> That makes me wonder it possible breaks tuners having IF, as ADC was
> clocked just over 20MHz and if it is half then it is 10MHz. For BB that
> is enough, but I think that having IF, which is 4MHz at least for 8MHz
> BW it is too less.
>
> F*ck I hate to maintain driver without a hardware! Any idea where I can
> get AF9035 device having tda18218 or mxl5007t?
>
> regards
> Antti
Still pending the changes for mxl5007t. Attached is a patch for that.
Changes to make work Avermedia Twinstar with the af9035 driver.
Signed-off-by: Jose Alberto Reguero
Jose Alberto
diff -upr linux/drivers/media/tuners/mxl5007t.c
linux.new/drivers/media/tuners/mxl5007t.c
--- linux/drivers/media/tuners/mxl5007t.c 2012-08-14
05:45:22.0 +0200 +++ linux.new/drivers/media/tuners/mxl5007t.c
2013-01-10 19:23:09.247556275 +0100
@@ -374,7 +374,6 @@ static struct reg_pair_t *mxl5007t_calc_
mxl5007t_set_if_freq_bits(state, cfg->if_freq_hz,
cfg->invert_if);
mxl5007t_set_xtal_freq_bits(state, cfg->xtal_freq_hz);
- set_reg_bits(state->tab_init, 0x04, 0x01,
cfg->loop_thru_enable);
set_reg_bits(state->tab_init, 0x03, 0x08, cfg->clk_out_enable
<<
3);
set_reg_bits(state->tab_init, 0x03, 0x07, cfg->clk_out_amp);
>>>
>>>
>>> This is a configurable option - it should not be removed, just
>>> configure your glue code to not use that option if you dont want
>>> it unless there's some other reason why you're removing this?
>>>
>>
>> I just move the code to a mxl5007t_attach because with dual tuner until
>> the
>> code is executed, the other tuner don't work. It can be left here also.
>>
@@ -531,9 +530,12 @@ static int mxl5007t_tuner_init(struct mx
struct reg_pair_t *init_regs;
int ret;
- ret = mxl5007t_soft_reset(state);
- if (mxl_fail(ret))
+ if (!state->config->no_reset) {
+ ret = mxl5007t_soft_reset(state);
+ if (mxl_fail(ret))
goto fail;
+ }
+
>>>
>>>
>>> this seems wrong to me. why would you want to prevent the driver from
>>> doing a soft reset?
>>>
>>
>> That is because with my hardware and dual tuner, when one tuner do reset,
>> the
>> other one is perturbed, and the stream has errors.
>>
/* calculate initialization reg array */
init_regs = mxl5007t_calc_init_regs(state, mode);
@@ -887,7 +889,12 @@ struct dvb_frontend *mxl5007t_attach(str
if (fe->ops.i2c_gate_ctrl)
fe->ops.i2c_gate_ctrl(fe, 1);
- ret = mxl5007t_get_chip_id(state);
+ if (!state->config->no_probe)
+ ret = mxl5007t_get_chip_id(state);
+
+ ret = mxl5007t_write_reg(state, 0x04,
+ state->config->loop_thru_enable);
+
>>>
>>>
>>> Can you explain why this change was made? ^^
>>>
>>
>> mxl5007t_get_chip_id has a read, and with the hardware I have, after the
>> read
>> operation is made, communication with the chip don't work.
>>
if (fe->ops.i2c_gate_ctrl)
fe->ops.i2c_gate_ctrl(fe, 0);
diff -upr linux/drivers/media/tuners/mxl5007t.h
linux.new/drivers/media/tuners/mxl5007t.h
--- linux/drivers/media/tuners/mxl5007t.h 2012-08-14
05:45:22.0 +0200 +++ linux.new/drivers/media/tuners/mxl5007t.h
2013-01-10 19:19:11.204379581 +0100
@@ -73,8 +73,10 @@ struct mxl5007t_config {
enum mxl5007t_xtal_freq xtal_freq_hz;
enum mxl5007t_if_freq if_freq_hz;
unsigned int invert_if:1;
- unsigned int loop_thru_enable:1;
+ unsigned int loop_thru_enable:3;
>>>
>>>
>>> Why widen this boolean to three bits?
>>>
>>
>> I just use the value 3 for this option(taken from windows driver) and it
>> works
>> well.
>>
>>
>> Thanks for review the code.
>>
>> Jose Alberto
>>
unsigned int clk_out_enable:1;
+ unsigned int no
Re: af9035 test needed!
On 02/03/2013 02:04 PM, Jose Alberto Reguero wrote:
On Sábado, 2 de febrero de 2013 23:00:45 Michael Krufky escribió:
On Fri, Jan 11, 2013 at 6:45 PM, Jose Alberto Reguero
wrote:
On Viernes, 11 de enero de 2013 20:38:01 Antti Palosaari escribió:
Hello Jose and Gianluca
Could you test that (tda18218 & mxl5007t):
http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/it9135_t
une r
I wonder if ADC config logic still works for superheterodyne tuners
(tuner having IF). I changed it to adc / 2 always due to IT9135 tuner.
That makes me wonder it possible breaks tuners having IF, as ADC was
clocked just over 20MHz and if it is half then it is 10MHz. For BB that
is enough, but I think that having IF, which is 4MHz at least for 8MHz
BW it is too less.
F*ck I hate to maintain driver without a hardware! Any idea where I can
get AF9035 device having tda18218 or mxl5007t?
regards
Antti
Still pending the changes for mxl5007t. Attached is a patch for that.
Changes to make work Avermedia Twinstar with the af9035 driver.
Signed-off-by: Jose Alberto Reguero
Jose Alberto
diff -upr linux/drivers/media/tuners/mxl5007t.c
linux.new/drivers/media/tuners/mxl5007t.c
--- linux/drivers/media/tuners/mxl5007t.c 2012-08-14
05:45:22.0 +0200 +++ linux.new/drivers/media/tuners/mxl5007t.c
2013-01-10 19:23:09.247556275 +0100
@@ -374,7 +374,6 @@ static struct reg_pair_t *mxl5007t_calc_
mxl5007t_set_if_freq_bits(state, cfg->if_freq_hz, cfg->invert_if);
mxl5007t_set_xtal_freq_bits(state, cfg->xtal_freq_hz);
- set_reg_bits(state->tab_init, 0x04, 0x01, cfg->loop_thru_enable);
set_reg_bits(state->tab_init, 0x03, 0x08, cfg->clk_out_enable <<
3);
set_reg_bits(state->tab_init, 0x03, 0x07, cfg->clk_out_amp);
This is a configurable option - it should not be removed, just
configure your glue code to not use that option if you dont want
it unless there's some other reason why you're removing this?
I just move the code to a mxl5007t_attach because with dual tuner until the
code is executed, the other tuner don't work. It can be left here also.
@@ -531,9 +530,12 @@ static int mxl5007t_tuner_init(struct mx
struct reg_pair_t *init_regs;
int ret;
- ret = mxl5007t_soft_reset(state);
- if (mxl_fail(ret))
+ if (!state->config->no_reset) {
+ ret = mxl5007t_soft_reset(state);
+ if (mxl_fail(ret))
goto fail;
+ }
+
this seems wrong to me. why would you want to prevent the driver from
doing a soft reset?
That is because with my hardware and dual tuner, when one tuner do reset, the
other one is perturbed, and the stream has errors.
/* calculate initialization reg array */
init_regs = mxl5007t_calc_init_regs(state, mode);
@@ -887,7 +889,12 @@ struct dvb_frontend *mxl5007t_attach(str
if (fe->ops.i2c_gate_ctrl)
fe->ops.i2c_gate_ctrl(fe, 1);
- ret = mxl5007t_get_chip_id(state);
+ if (!state->config->no_probe)
+ ret = mxl5007t_get_chip_id(state);
+
+ ret = mxl5007t_write_reg(state, 0x04,
+ state->config->loop_thru_enable);
+
Can you explain why this change was made? ^^
mxl5007t_get_chip_id has a read, and with the hardware I have, after the read
operation is made, communication with the chip don't work.
if (fe->ops.i2c_gate_ctrl)
fe->ops.i2c_gate_ctrl(fe, 0);
diff -upr linux/drivers/media/tuners/mxl5007t.h
linux.new/drivers/media/tuners/mxl5007t.h
--- linux/drivers/media/tuners/mxl5007t.h 2012-08-14
05:45:22.0 +0200 +++ linux.new/drivers/media/tuners/mxl5007t.h
2013-01-10 19:19:11.204379581 +0100
@@ -73,8 +73,10 @@ struct mxl5007t_config {
enum mxl5007t_xtal_freq xtal_freq_hz;
enum mxl5007t_if_freq if_freq_hz;
unsigned int invert_if:1;
- unsigned int loop_thru_enable:1;
+ unsigned int loop_thru_enable:3;
Why widen this boolean to three bits?
I just use the value 3 for this option(taken from windows driver) and it works
well.
Thanks for review the code.
Jose Alberto
unsigned int clk_out_enable:1;
+ unsigned int no_probe:1;
+ unsigned int no_reset:1;
};
#if defined(CONFIG_MEDIA_TUNER_MXL5007T) ||
(defined(CONFIG_MEDIA_TUNER_MXL5007T_MODULE) && defined(MODULE))
diff -upr linux/drivers/media/usb/dvb-usb-v2/af9035.c
linux.new/drivers/media/usb/dvb-usb-v2/af9035.c
--- linux/drivers/media/usb/dvb-usb-v2/af9035.c 2013-01-07
05:45:57.0 +0100
+++ linux.new/drivers/media/usb/dvb-usb-v2/af9035.c 2013-01-12
00:30:57.557310465 +0100
@@ -886,13 +886,17 @@ static struct mxl5007t_config af9035_mxl
.loop_thru_enable = 0,
.clk_out_enable = 0,
.clk_out_amp = MxL_CLKOUT_AMP_0_94V,
+ .no_probe = 1,
+ .no_reset
Re: af9035 test needed!
On Sábado, 2 de febrero de 2013 23:00:45 Michael Krufky escribió:
> On Fri, Jan 11, 2013 at 6:45 PM, Jose Alberto Reguero
>
> wrote:
> > On Viernes, 11 de enero de 2013 20:38:01 Antti Palosaari escribió:
> >> Hello Jose and Gianluca
> >>
> >> Could you test that (tda18218 & mxl5007t):
> >> http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/it9135_t
> >> une r
> >>
> >> I wonder if ADC config logic still works for superheterodyne tuners
> >> (tuner having IF). I changed it to adc / 2 always due to IT9135 tuner.
> >> That makes me wonder it possible breaks tuners having IF, as ADC was
> >> clocked just over 20MHz and if it is half then it is 10MHz. For BB that
> >> is enough, but I think that having IF, which is 4MHz at least for 8MHz
> >> BW it is too less.
> >>
> >> F*ck I hate to maintain driver without a hardware! Any idea where I can
> >> get AF9035 device having tda18218 or mxl5007t?
> >>
> >> regards
> >> Antti
> >
> > Still pending the changes for mxl5007t. Attached is a patch for that.
> >
> > Changes to make work Avermedia Twinstar with the af9035 driver.
> >
> > Signed-off-by: Jose Alberto Reguero
> >
> > Jose Alberto
> >
> > diff -upr linux/drivers/media/tuners/mxl5007t.c
> > linux.new/drivers/media/tuners/mxl5007t.c
> > --- linux/drivers/media/tuners/mxl5007t.c 2012-08-14
> > 05:45:22.0 +0200 +++ linux.new/drivers/media/tuners/mxl5007t.c
> > 2013-01-10 19:23:09.247556275 +0100
> > @@ -374,7 +374,6 @@ static struct reg_pair_t *mxl5007t_calc_
> >
> > mxl5007t_set_if_freq_bits(state, cfg->if_freq_hz, cfg->invert_if);
> > mxl5007t_set_xtal_freq_bits(state, cfg->xtal_freq_hz);
> >
> > - set_reg_bits(state->tab_init, 0x04, 0x01, cfg->loop_thru_enable);
> >
> > set_reg_bits(state->tab_init, 0x03, 0x08, cfg->clk_out_enable <<
> > 3);
> > set_reg_bits(state->tab_init, 0x03, 0x07, cfg->clk_out_amp);
>
> This is a configurable option - it should not be removed, just
> configure your glue code to not use that option if you dont want
> it unless there's some other reason why you're removing this?
>
I just move the code to a mxl5007t_attach because with dual tuner until the
code is executed, the other tuner don't work. It can be left here also.
> > @@ -531,9 +530,12 @@ static int mxl5007t_tuner_init(struct mx
> >
> > struct reg_pair_t *init_regs;
> > int ret;
> >
> > - ret = mxl5007t_soft_reset(state);
> > - if (mxl_fail(ret))
> > + if (!state->config->no_reset) {
> > + ret = mxl5007t_soft_reset(state);
> > + if (mxl_fail(ret))
> >
> > goto fail;
> >
> > + }
> > +
>
> this seems wrong to me. why would you want to prevent the driver from
> doing a soft reset?
>
That is because with my hardware and dual tuner, when one tuner do reset, the
other one is perturbed, and the stream has errors.
> > /* calculate initialization reg array */
> > init_regs = mxl5007t_calc_init_regs(state, mode);
> >
> > @@ -887,7 +889,12 @@ struct dvb_frontend *mxl5007t_attach(str
> >
> > if (fe->ops.i2c_gate_ctrl)
> >
> > fe->ops.i2c_gate_ctrl(fe, 1);
> >
> > - ret = mxl5007t_get_chip_id(state);
> > + if (!state->config->no_probe)
> > + ret = mxl5007t_get_chip_id(state);
> > +
> > + ret = mxl5007t_write_reg(state, 0x04,
> > + state->config->loop_thru_enable);
> > +
>
> Can you explain why this change was made? ^^
>
mxl5007t_get_chip_id has a read, and with the hardware I have, after the read
operation is made, communication with the chip don't work.
> > if (fe->ops.i2c_gate_ctrl)
> >
> > fe->ops.i2c_gate_ctrl(fe, 0);
> >
> > diff -upr linux/drivers/media/tuners/mxl5007t.h
> > linux.new/drivers/media/tuners/mxl5007t.h
> > --- linux/drivers/media/tuners/mxl5007t.h 2012-08-14
> > 05:45:22.0 +0200 +++ linux.new/drivers/media/tuners/mxl5007t.h
> > 2013-01-10 19:19:11.204379581 +0100
> > @@ -73,8 +73,10 @@ struct mxl5007t_config {
> >
> > enum mxl5007t_xtal_freq xtal_freq_hz;
> > enum mxl5007t_if_freq if_freq_hz;
> > unsigned int invert_if:1;
> >
> > - unsigned int loop_thru_enable:1;
> > + unsigned int loop_thru_enable:3;
>
> Why widen this boolean to three bits?
>
I just use the value 3 for this option(taken from windows driver) and it works
well.
Thanks for review the code.
Jose Alberto
> > unsigned int clk_out_enable:1;
> >
> > + unsigned int no_probe:1;
> > + unsigned int no_reset:1;
> >
> > };
> >
> > #if defined(CONFIG_MEDIA_TUNER_MXL5007T) ||
> >
> > (defined(CONFIG_MEDIA_TUNER_MXL5007T_MODULE) && defined(MODULE))
> > diff -upr linux/drivers/media/usb/dvb-usb-v2/af9035.c
> > linux.new/drivers/media/usb/dvb-usb-v2/af9035.c
> > --- linux/
Re: af9035 test needed!
On Fri, Jan 11, 2013 at 6:45 PM, Jose Alberto Reguero
wrote:
> On Viernes, 11 de enero de 2013 20:38:01 Antti Palosaari escribió:
>> Hello Jose and Gianluca
>>
>> Could you test that (tda18218 & mxl5007t):
>> http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/it9135_tune
>> r
>>
>> I wonder if ADC config logic still works for superheterodyne tuners
>> (tuner having IF). I changed it to adc / 2 always due to IT9135 tuner.
>> That makes me wonder it possible breaks tuners having IF, as ADC was
>> clocked just over 20MHz and if it is half then it is 10MHz. For BB that
>> is enough, but I think that having IF, which is 4MHz at least for 8MHz
>> BW it is too less.
>>
>> F*ck I hate to maintain driver without a hardware! Any idea where I can
>> get AF9035 device having tda18218 or mxl5007t?
>>
>> regards
>> Antti
>
> Still pending the changes for mxl5007t. Attached is a patch for that.
>
> Changes to make work Avermedia Twinstar with the af9035 driver.
>
> Signed-off-by: Jose Alberto Reguero
>
> Jose Alberto
>
> diff -upr linux/drivers/media/tuners/mxl5007t.c
> linux.new/drivers/media/tuners/mxl5007t.c
> --- linux/drivers/media/tuners/mxl5007t.c 2012-08-14 05:45:22.0
> +0200
> +++ linux.new/drivers/media/tuners/mxl5007t.c 2013-01-10 19:23:09.247556275
> +0100
> @@ -374,7 +374,6 @@ static struct reg_pair_t *mxl5007t_calc_
> mxl5007t_set_if_freq_bits(state, cfg->if_freq_hz, cfg->invert_if);
> mxl5007t_set_xtal_freq_bits(state, cfg->xtal_freq_hz);
>
> - set_reg_bits(state->tab_init, 0x04, 0x01, cfg->loop_thru_enable);
> set_reg_bits(state->tab_init, 0x03, 0x08, cfg->clk_out_enable << 3);
> set_reg_bits(state->tab_init, 0x03, 0x07, cfg->clk_out_amp);
>
This is a configurable option - it should not be removed, just
configure your glue code to not use that option if you dont want
it unless there's some other reason why you're removing this?
> @@ -531,9 +530,12 @@ static int mxl5007t_tuner_init(struct mx
> struct reg_pair_t *init_regs;
> int ret;
>
> - ret = mxl5007t_soft_reset(state);
> - if (mxl_fail(ret))
> + if (!state->config->no_reset) {
> + ret = mxl5007t_soft_reset(state);
> + if (mxl_fail(ret))
> goto fail;
> + }
> +
this seems wrong to me. why would you want to prevent the driver from
doing a soft reset?
>
> /* calculate initialization reg array */
> init_regs = mxl5007t_calc_init_regs(state, mode);
> @@ -887,7 +889,12 @@ struct dvb_frontend *mxl5007t_attach(str
> if (fe->ops.i2c_gate_ctrl)
> fe->ops.i2c_gate_ctrl(fe, 1);
>
> - ret = mxl5007t_get_chip_id(state);
> + if (!state->config->no_probe)
> + ret = mxl5007t_get_chip_id(state);
> +
> + ret = mxl5007t_write_reg(state, 0x04,
> + state->config->loop_thru_enable);
> +
>
Can you explain why this change was made? ^^
> if (fe->ops.i2c_gate_ctrl)
> fe->ops.i2c_gate_ctrl(fe, 0);
> diff -upr linux/drivers/media/tuners/mxl5007t.h
> linux.new/drivers/media/tuners/mxl5007t.h
> --- linux/drivers/media/tuners/mxl5007t.h 2012-08-14 05:45:22.0
> +0200
> +++ linux.new/drivers/media/tuners/mxl5007t.h 2013-01-10 19:19:11.204379581
> +0100
> @@ -73,8 +73,10 @@ struct mxl5007t_config {
> enum mxl5007t_xtal_freq xtal_freq_hz;
> enum mxl5007t_if_freq if_freq_hz;
> unsigned int invert_if:1;
> - unsigned int loop_thru_enable:1;
> + unsigned int loop_thru_enable:3;
Why widen this boolean to three bits?
> unsigned int clk_out_enable:1;
> + unsigned int no_probe:1;
> + unsigned int no_reset:1;
> };
>
> #if defined(CONFIG_MEDIA_TUNER_MXL5007T) ||
> (defined(CONFIG_MEDIA_TUNER_MXL5007T_MODULE) && defined(MODULE))
> diff -upr linux/drivers/media/usb/dvb-usb-v2/af9035.c
> linux.new/drivers/media/usb/dvb-usb-v2/af9035.c
> --- linux/drivers/media/usb/dvb-usb-v2/af9035.c 2013-01-07 05:45:57.0
> +0100
> +++ linux.new/drivers/media/usb/dvb-usb-v2/af9035.c 2013-01-12
> 00:30:57.557310465 +0100
> @@ -886,13 +886,17 @@ static struct mxl5007t_config af9035_mxl
> .loop_thru_enable = 0,
> .clk_out_enable = 0,
> .clk_out_amp = MxL_CLKOUT_AMP_0_94V,
> + .no_probe = 1,
> + .no_reset = 1,
> }, {
> .xtal_freq_hz = MxL_XTAL_24_MHZ,
> .if_freq_hz = MxL_IF_4_57_MHZ,
> .invert_if = 0,
> - .loop_thru_enable = 1,
> + .loop_thru_enable = 3,
> .clk_out_enable = 1,
> .clk_out_amp = MxL_CLKOUT_AMP_0_94V,
> + .no_probe = 1,
> + .no_reset = 1,
> }
> };
>
This patch cannot be merged as-is. I'm sorry. If you could explain
why each change was made, then pe
Re: af9035 test needed!
On Thu, 2013-01-31 at 15:59 +0200, Antti Palosaari wrote: > On 01/31/2013 03:04 PM, Andre Heider wrote: > > Hi, > > > > On Fri, Jan 11, 2013 at 7:38 PM, Antti Palosaari wrote: > >> Could you test that (tda18218 & mxl5007t): > >> http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/it9135_tuner > > > > I got a 'TerraTec Cinergy T Stick Dual RC (rev. 2)', which is fixed by > > this series. > > Any chance to get this into 3.9 (I guess its too late for the USB > > VID/PID 'fix' for 3.8)? > > Thank you for the report! There was someone else who reported it working > too. Do you want to your name as tester for the changelog? > > I just yesterday got that TerraTec device too and I am going to add dual > tuner support. Also, for some reason IT9135 v2 devices are not working - > only v1. That is one thing I should fix before merge that stuff. Hi Antti, I am going to acknowledge this development, so you are free to copy any code from the it913x and it913x-fe driver to get this working. My time is very limited at the moment, so I will try to do testing when possible. Once everything is stable enough the dvb-usb-it913x and it913x-fe modules can be removed. Acked-by: Malcolm Priestley Regards Malcolm -- 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: af9035 test needed!
Jose, Gianluca, On 01/31/2013 08:40 PM, Andre Heider wrote: Hey, On Thu, Jan 31, 2013 at 2:59 PM, Antti Palosaari wrote: On Fri, Jan 11, 2013 at 7:38 PM, Antti Palosaari wrote: Could you test that (tda18218 & mxl5007t): only now I see you mentioned mxl5007t too, and with the same tree as I used for my 'TerraTec Cinergy T Stick Dual RC (rev. 2)', a 'AVerMedia HD Volar (A867)' with a mxl5007t (and an unkown rev) works too: usb 3-3.1.4: new high-speed USB device number 7 using xhci_hcd usb 3-3.1.4: New USB device found, idVendor=07ca, idProduct=1867 usb 3-3.1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 3-3.1.4: Product: A867 usb 3-3.1.4: Manufacturer: AVerMedia TECHNOLOGIES, Inc usb 3-3.1.4: SerialNumber: 0305770200261 usb 3-3.1.4: af9035_identify_state: prechip_version=00 chip_version=03 chip_type=3802 Who one as able to test with non-working AF9035 + MxL5007T combination. Does it report different chip versions? Same firmware used? usb 3-3.1.4: dvb_usb_v2: found a 'AVerMedia HD Volar (A867)' in cold state usb 3-3.1.4: dvb_usb_v2: downloading firmware from file 'dvb-usb-af9035-02.fw' usb 3-3.1.4: dvb_usb_af9035: firmware version=11.5.9.0 usb 3-3.1.4: dvb_usb_v2: found a 'AVerMedia HD Volar (A867)' in warm state usb 3-3.1.4: dvb_usb_v2: will pass the complete MPEG2 transport stream to the software demuxer DVB: registering new adapter (AVerMedia HD Volar (A867)) i2c i2c-19: af9033: firmware version: LINK=11.5.9.0 OFDM=5.17.9.1 usb 3-3.1.4: DVB: registering adapter 1 frontend 0 (Afatech AF9033 (DVB-T))... mxl5007t 19-0060: creating new instance mxl5007t_get_chip_id: unknown rev (3f) mxl5007t_get_chip_id: MxL5007T detected @ 19-0060 Registered IR keymap rc-empty input: AVerMedia HD Volar (A867) as /devices/pci:00/:00:14.0/usb3/3-3/3-3.1/3-3.1.4/rc/rc5/input29 rc5: AVerMedia HD Volar (A867) as /devices/pci:00/:00:14.0/usb3/3-3/3-3.1/3-3.1.4/rc/rc5 usb 3-3.1.4: dvb_usb_v2: schedule remote query interval to 500 msecs usb 3-3.1.4: dvb_usb_v2: 'AVerMedia HD Volar (A867)' successfully initialized and connected regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: af9035 test needed!
Hey, On Thu, Jan 31, 2013 at 2:59 PM, Antti Palosaari wrote: >> On Fri, Jan 11, 2013 at 7:38 PM, Antti Palosaari wrote: >>> >>> Could you test that (tda18218 & mxl5007t): only now I see you mentioned mxl5007t too, and with the same tree as I used for my 'TerraTec Cinergy T Stick Dual RC (rev. 2)', a 'AVerMedia HD Volar (A867)' with a mxl5007t (and an unkown rev) works too: usb 3-3.1.4: new high-speed USB device number 7 using xhci_hcd usb 3-3.1.4: New USB device found, idVendor=07ca, idProduct=1867 usb 3-3.1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 3-3.1.4: Product: A867 usb 3-3.1.4: Manufacturer: AVerMedia TECHNOLOGIES, Inc usb 3-3.1.4: SerialNumber: 0305770200261 usb 3-3.1.4: af9035_identify_state: prechip_version=00 chip_version=03 chip_type=3802 usb 3-3.1.4: dvb_usb_v2: found a 'AVerMedia HD Volar (A867)' in cold state usb 3-3.1.4: dvb_usb_v2: downloading firmware from file 'dvb-usb-af9035-02.fw' usb 3-3.1.4: dvb_usb_af9035: firmware version=11.5.9.0 usb 3-3.1.4: dvb_usb_v2: found a 'AVerMedia HD Volar (A867)' in warm state usb 3-3.1.4: dvb_usb_v2: will pass the complete MPEG2 transport stream to the software demuxer DVB: registering new adapter (AVerMedia HD Volar (A867)) i2c i2c-19: af9033: firmware version: LINK=11.5.9.0 OFDM=5.17.9.1 usb 3-3.1.4: DVB: registering adapter 1 frontend 0 (Afatech AF9033 (DVB-T))... mxl5007t 19-0060: creating new instance mxl5007t_get_chip_id: unknown rev (3f) mxl5007t_get_chip_id: MxL5007T detected @ 19-0060 Registered IR keymap rc-empty input: AVerMedia HD Volar (A867) as /devices/pci:00/:00:14.0/usb3/3-3/3-3.1/3-3.1.4/rc/rc5/input29 rc5: AVerMedia HD Volar (A867) as /devices/pci:00/:00:14.0/usb3/3-3/3-3.1/3-3.1.4/rc/rc5 usb 3-3.1.4: dvb_usb_v2: schedule remote query interval to 500 msecs usb 3-3.1.4: dvb_usb_v2: 'AVerMedia HD Volar (A867)' successfully initialized and connected Regards, Andre -- 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: af9035 test needed!
Hi, On Thu, Jan 31, 2013 at 2:59 PM, Antti Palosaari wrote: > Thank you for the report! There was someone else who reported it working > too. Do you want to your name as tester for the changelog? if I didn't mess up my way of testing feel free to add Tested-by: Andre Heider to these patches: af9035: merge af9035 and it9135 eeprom read routines af9035: USB1.1 support (== PID filters) af9035: constify clock tables af9035: [0ccd:0099] TerraTec Cinergy T Stick Dual RC (rev. 2) af9015: reject device TerraTec Cinergy T Stick Dual RC (rev. 2) af9035: fix af9033 demod sampling frequency af9035: add auto configuration heuristic for it9135 af9035: add support for 1st gen it9135 af9033: support for it913x tuners ITE IT913X silicon tuner driver I didn't use any media trees before, and the whole media_build.git shebang seems a little, well, unusual... So I rebased media_tree.git/staging/for_v3.9 on Linus' master and then cherry-picked the patches mentioned above. That gives me: usb 2-1.5: new high-speed USB device number 3 using ehci-pci usb 2-1.5: New USB device found, idVendor=0ccd, idProduct=0099 usb 2-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 2-1.5: Product: DVB-T TV Stick usb 2-1.5: Manufacturer: ITE Technologies, Inc. input: ITE Technologies, Inc. DVB-T TV Stick as /devices/pci:00/:00:1d.0/usb2/2-1/2-1.5/2-1.5:1.1/input/input20 usb 2-1.5: af9035_identify_state: prechip_version=83 chip_version=01 chip_type=9135 hid-generic 0003:0CCD:0099.0007: input,hidraw4: USB HID v1.01 Keyboard [ITE Technologies, Inc. DVB-T TV Stick] on usb-:00:1d.0-1.5/input1 usb 2-1.5: dvb_usb_v2: found a 'TerraTec Cinergy T Stick Dual RC (rev. 2)' in cold state usb 2-1.5: dvb_usb_v2: downloading firmware from file 'dvb-usb-it9135-01.fw' usb 2-1.5: dvb_usb_af9035: firmware version=12.54.14.0 usb 2-1.5: dvb_usb_v2: found a 'TerraTec Cinergy T Stick Dual RC (rev. 2)' in warm state usb 2-1.5: dvb_usb_af9035: driver does not support 2nd tuner and will disable it usb 2-1.5: dvb_usb_v2: will pass the complete MPEG2 transport stream to the software demuxer DVB: registering new adapter (TerraTec Cinergy T Stick Dual RC (rev. 2)) i2c i2c-18: af9033: firmware version: LINK=255.255.255.255 OFDM=2.47.14.0 usb 2-1.5: DVB: registering adapter 0 frontend 0 (Afatech AF9033 (DVB-T))... Tuner LNA type :38 it913x: ITE Tech IT913X attached usb 2-1.5: dvb_usb_v2: 'TerraTec Cinergy T Stick Dual RC (rev. 2)' successfully initialized and connected > I just yesterday got that TerraTec device too and I am going to add dual > tuner support. Also, for some reason IT9135 v2 devices are not working - > only v1. That is one thing I should fix before merge that stuff. Nice, feel free to CC me if you need any testing. Regards, Andre -- 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: af9035 test needed!
On 01/31/2013 03:04 PM, Andre Heider wrote: Hi, On Fri, Jan 11, 2013 at 7:38 PM, Antti Palosaari wrote: Could you test that (tda18218 & mxl5007t): http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/it9135_tuner I got a 'TerraTec Cinergy T Stick Dual RC (rev. 2)', which is fixed by this series. Any chance to get this into 3.9 (I guess its too late for the USB VID/PID 'fix' for 3.8)? Thank you for the report! There was someone else who reported it working too. Do you want to your name as tester for the changelog? I just yesterday got that TerraTec device too and I am going to add dual tuner support. Also, for some reason IT9135 v2 devices are not working - only v1. That is one thing I should fix before merge that stuff. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: af9035 test needed!
Hey guys... somehow this email slipped through my filters :-( I see it now, and I'll give a look over the patch this weekend. -Mike On Thu, Jan 31, 2013 at 8:04 AM, Andre Heider wrote: > Hi, > > On Fri, Jan 11, 2013 at 7:38 PM, Antti Palosaari wrote: >> Could you test that (tda18218 & mxl5007t): >> http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/it9135_tuner > > I got a 'TerraTec Cinergy T Stick Dual RC (rev. 2)', which is fixed by > this series. > Any chance to get this into 3.9 (I guess its too late for the USB > VID/PID 'fix' for 3.8)? > > Regards, > Andre > -- > 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: af9035 test needed!
Hi, On Fri, Jan 11, 2013 at 7:38 PM, Antti Palosaari wrote: > Could you test that (tda18218 & mxl5007t): > http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/it9135_tuner I got a 'TerraTec Cinergy T Stick Dual RC (rev. 2)', which is fixed by this series. Any chance to get this into 3.9 (I guess its too late for the USB VID/PID 'fix' for 3.8)? Regards, Andre -- 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: af9035 test needed!
Il 11/01/2013 19:38, Antti Palosaari ha scritto: > Hello Jose and Gianluca > > Could you test that (tda18218 & mxl5007t): > http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/it9135_tuner > > > I wonder if ADC config logic still works for superheterodyne tuners > (tuner having IF). I changed it to adc / 2 always due to IT9135 tuner. > That makes me wonder it possible breaks tuners having IF, as ADC was > clocked just over 20MHz and if it is half then it is 10MHz. For BB that > is enough, but I think that having IF, which is 4MHz at least for 8MHz > BW it is too less. Hi Antti, I tested your latest tree and both the Avermedia A835 (af9035+tda18218) and the A867 (af9035+mxl5007t) work perfectly fine. I could not find any change in the behavior of the two devices. BTW, there are reports on several Italian forums (like this: http://www.vuplus-community.net/board/threads/varie-prove-fatte-su-vu-uno-e-digital-key-a867-led-blu.9930/) that a new revision of the A867 stick (marked as "A867-DP7") does not work with the current af9035 driver, but it works perfectly fine when Jose's patch for the mxl5007t tuner is applied. I have an older "DP5" revision that always worked fine with the af9035 driver, so I cannot test the new "DP7" revision directly. > > F*ck I hate to maintain driver without a hardware! Any idea where I can > get AF9035 device having tda18218 or mxl5007t? Here are a couple of links to buy cheap af9035 sticks. Avermedia A835/B835: af9035 + tda18218, also known ad "Avermedia Volar HD" or "Avermedia Volar HD Pro" or "Avermedia Volar Green HD". The only difference between the models seems to be the presence of the remote controller and the IR sensor: http://www.amazon.it/Avermedia-Avertv-Volar-Green-Hd/dp/B003GXAMEM/ref=sr_1_2?ie=UTF8&qid=1358499827&sr=8-2 http://www.amazon.it/Avermedia-Avertv-Volar-Hd-Pro/dp/B003ACL1ZI/ref=sr_1_1?ie=UTF8&qid=1358499827&sr=8-1 Avermedia A867: af9035 + mxl5007t, also known as "Aver Media AVerTV 3D" or "Sky Digital Key with blue led". You can buy them very cheap on Ebay Italia because Sky Italia is giving away them almost for free to its subscribers, to add DVB-T support to the Skyboxes. You can find dozens of items looking for "Sky Digital Key Blu Led" on the Italian Ebay: http://www.ebay.it/sch/i.html?_trksid=p3902.m570.l1313&_nkw=sky+digital+key+blu&_sacat=0&_from=R40 or you can buy the retail model: http://www.amazon.it/Avermedia-AverTV-Volar-Entertainment-Pack/dp/B003TPW5WO/ref=sr_1_2?s=electronics&ie=UTF8&qid=1358499900&sr=1-2 As an alternative, I could ask a friend if he is willing to lend you the 2 sticks for all the time you need. He has both the A835 and the A867 "DP7" revision. Let me know if you are interested. Regards, Gianluca > > regards > Antti > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: af9035 test needed!
On Sábado, 12 de enero de 2013 22:14:07 Jose Alberto Reguero escribió:
> On Sábado, 12 de enero de 2013 01:49:21 Antti Palosaari escribió:
> > On 01/12/2013 01:45 AM, Jose Alberto Reguero wrote:
> > > On Viernes, 11 de enero de 2013 20:38:01 Antti Palosaari escribió:
> > >> Hello Jose and Gianluca
> > >>
> > >> Could you test that (tda18218 & mxl5007t):
> > >> http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/it9135_t
> > >> une r
> > >>
> > >> I wonder if ADC config logic still works for superheterodyne tuners
> > >> (tuner having IF). I changed it to adc / 2 always due to IT9135 tuner.
> > >> That makes me wonder it possible breaks tuners having IF, as ADC was
> > >> clocked just over 20MHz and if it is half then it is 10MHz. For BB that
> > >> is enough, but I think that having IF, which is 4MHz at least for 8MHz
> > >> BW it is too less.
> > >>
> > >> F*ck I hate to maintain driver without a hardware! Any idea where I can
> > >> get AF9035 device having tda18218 or mxl5007t?
> > >>
> > >> regards
> > >> Antti
> > >
> > > Still pending the changes for mxl5007t. Attached is a patch for that.
> > >
> > > Changes to make work Avermedia Twinstar with the af9035 driver.
> > >
> > > Signed-off-by: Jose Alberto Reguero
> >
> > I cannot do much about this as it changes mxl5007t driver which is not
> > maintained by me. :)
> >
> > regards
> > Antti
> >
>
> Adding CC to Michael Krufky because it is the maintainer of mxl5007t driver.
> Michael, any chance to get this patch merged?
>
> Jose Alberto
>
> > > Jose Alberto
> > >
> > > diff -upr linux/drivers/media/tuners/mxl5007t.c
> > > linux.new/drivers/media/tuners/mxl5007t.c
> > > --- linux/drivers/media/tuners/mxl5007t.c 2012-08-14 05:45:22.0
> > > +0200 +++ linux.new/drivers/media/tuners/mxl5007t.c 2013-01-10
> > > 19:23:09.247556275 +0100
> > > @@ -374,7 +374,6 @@ static struct reg_pair_t *mxl5007t_calc_
> > >
> > > mxl5007t_set_if_freq_bits(state, cfg->if_freq_hz,
> > > cfg->invert_if);
> > > mxl5007t_set_xtal_freq_bits(state, cfg->xtal_freq_hz);
> > >
> > > - set_reg_bits(state->tab_init, 0x04, 0x01, cfg->loop_thru_enable);
> > >
> > > set_reg_bits(state->tab_init, 0x03, 0x08, cfg->clk_out_enable
> > > << 3);
> > > set_reg_bits(state->tab_init, 0x03, 0x07, cfg->clk_out_amp);
> > >
> > > @@ -531,9 +530,12 @@ static int mxl5007t_tuner_init(struct mx
> > >
> > > struct reg_pair_t *init_regs;
> > > int ret;
> > >
> > > - ret = mxl5007t_soft_reset(state);
> > > - if (mxl_fail(ret))
> > > + if (!state->config->no_reset) {
> > > + ret = mxl5007t_soft_reset(state);
> > > + if (mxl_fail(ret))
> > >
> > > goto fail;
> > >
> > > + }
> > > +
> > >
> > > /* calculate initialization reg array */
> > > init_regs = mxl5007t_calc_init_regs(state, mode);
> > >
> > > @@ -887,7 +889,12 @@ struct dvb_frontend *mxl5007t_attach(str
> > >
> > > if (fe->ops.i2c_gate_ctrl)
> > >
> > > fe->ops.i2c_gate_ctrl(fe, 1);
> > >
> > > - ret = mxl5007t_get_chip_id(state);
> > > + if (!state->config->no_probe)
> > > + ret = mxl5007t_get_chip_id(state);
> > > +
> > > + ret = mxl5007t_write_reg(state, 0x04,
> > > + state->config->loop_thru_enable);
> > > +
> > >
> > > if (fe->ops.i2c_gate_ctrl)
> > >
> > > fe->ops.i2c_gate_ctrl(fe, 0);
> > >
> > > diff -upr linux/drivers/media/tuners/mxl5007t.h
> > > linux.new/drivers/media/tuners/mxl5007t.h
> > > --- linux/drivers/media/tuners/mxl5007t.h 2012-08-14 05:45:22.0
> > > +0200 +++ linux.new/drivers/media/tuners/mxl5007t.h 2013-01-10
> > > 19:19:11.204379581 +0100
> > > @@ -73,8 +73,10 @@ struct mxl5007t_config {
> > >
> > > enum mxl5007t_xtal_freq xtal_freq_hz;
> > > enum mxl5007t_if_freq if_freq_hz;
> > > unsigned int invert_if:1;
> > >
> > > - unsigned int loop_thru_enable:1;
> > > + unsigned int loop_thru_enable:3;
> > >
> > > unsigned int clk_out_enable:1;
> > >
> > > + unsigned int no_probe:1;
> > > + unsigned int no_reset:1;
> > >
> > > };
> > >
> > > #if defined(CONFIG_MEDIA_TUNER_MXL5007T) ||
> > >
> > > (defined(CONFIG_MEDIA_TUNER_MXL5007T_MODULE) && defined(MODULE))
> > > diff -upr linux/drivers/media/usb/dvb-usb-v2/af9035.c
> > > linux.new/drivers/media/usb/dvb-usb-v2/af9035.c
> > > --- linux/drivers/media/usb/dvb-usb-v2/af9035.c 2013-01-07
> > > 05:45:57.0 +0100
> > > +++ linux.new/drivers/media/usb/dvb-usb-v2/af9035.c 2013-01-12
> > > 00:30:57.557310465 +0100
> > > @@ -886,13 +886,17 @@ static struct mxl5007t_config af9035_mxl
> > >
> > > .loop_thru_enable = 0,
> > > .clk_out_enable = 0,
> > > .clk_out_amp = MxL_CLKOUT_AMP_0_94V,
> > >
> > > +
Re: af9035 test needed!
On Sábado, 12 de enero de 2013 01:49:21 Antti Palosaari escribió:
> On 01/12/2013 01:45 AM, Jose Alberto Reguero wrote:
> > On Viernes, 11 de enero de 2013 20:38:01 Antti Palosaari escribió:
> >> Hello Jose and Gianluca
> >>
> >> Could you test that (tda18218 & mxl5007t):
> >> http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/it9135_t
> >> une r
> >>
> >> I wonder if ADC config logic still works for superheterodyne tuners
> >> (tuner having IF). I changed it to adc / 2 always due to IT9135 tuner.
> >> That makes me wonder it possible breaks tuners having IF, as ADC was
> >> clocked just over 20MHz and if it is half then it is 10MHz. For BB that
> >> is enough, but I think that having IF, which is 4MHz at least for 8MHz
> >> BW it is too less.
> >>
> >> F*ck I hate to maintain driver without a hardware! Any idea where I can
> >> get AF9035 device having tda18218 or mxl5007t?
> >>
> >> regards
> >> Antti
> >
> > Still pending the changes for mxl5007t. Attached is a patch for that.
> >
> > Changes to make work Avermedia Twinstar with the af9035 driver.
> >
> > Signed-off-by: Jose Alberto Reguero
>
> I cannot do much about this as it changes mxl5007t driver which is not
> maintained by me. :)
>
> regards
> Antti
>
Adding CC to Michael Krufky because it is the maintainer of mxl5007t driver.
Michael, any chance to get this patch merged?
Jose Alberto
> > Jose Alberto
> >
> > diff -upr linux/drivers/media/tuners/mxl5007t.c
> > linux.new/drivers/media/tuners/mxl5007t.c
> > --- linux/drivers/media/tuners/mxl5007t.c 2012-08-14 05:45:22.0
> > +0200 +++ linux.new/drivers/media/tuners/mxl5007t.c 2013-01-10
> > 19:23:09.247556275 +0100
> > @@ -374,7 +374,6 @@ static struct reg_pair_t *mxl5007t_calc_
> >
> > mxl5007t_set_if_freq_bits(state, cfg->if_freq_hz, cfg->invert_if);
> > mxl5007t_set_xtal_freq_bits(state, cfg->xtal_freq_hz);
> >
> > - set_reg_bits(state->tab_init, 0x04, 0x01, cfg->loop_thru_enable);
> >
> > set_reg_bits(state->tab_init, 0x03, 0x08, cfg->clk_out_enable << 3);
> > set_reg_bits(state->tab_init, 0x03, 0x07, cfg->clk_out_amp);
> >
> > @@ -531,9 +530,12 @@ static int mxl5007t_tuner_init(struct mx
> >
> > struct reg_pair_t *init_regs;
> > int ret;
> >
> > - ret = mxl5007t_soft_reset(state);
> > - if (mxl_fail(ret))
> > + if (!state->config->no_reset) {
> > + ret = mxl5007t_soft_reset(state);
> > + if (mxl_fail(ret))
> >
> > goto fail;
> >
> > + }
> > +
> >
> > /* calculate initialization reg array */
> > init_regs = mxl5007t_calc_init_regs(state, mode);
> >
> > @@ -887,7 +889,12 @@ struct dvb_frontend *mxl5007t_attach(str
> >
> > if (fe->ops.i2c_gate_ctrl)
> >
> > fe->ops.i2c_gate_ctrl(fe, 1);
> >
> > - ret = mxl5007t_get_chip_id(state);
> > + if (!state->config->no_probe)
> > + ret = mxl5007t_get_chip_id(state);
> > +
> > + ret = mxl5007t_write_reg(state, 0x04,
> > + state->config->loop_thru_enable);
> > +
> >
> > if (fe->ops.i2c_gate_ctrl)
> >
> > fe->ops.i2c_gate_ctrl(fe, 0);
> >
> > diff -upr linux/drivers/media/tuners/mxl5007t.h
> > linux.new/drivers/media/tuners/mxl5007t.h
> > --- linux/drivers/media/tuners/mxl5007t.h 2012-08-14 05:45:22.0
> > +0200 +++ linux.new/drivers/media/tuners/mxl5007t.h 2013-01-10
> > 19:19:11.204379581 +0100
> > @@ -73,8 +73,10 @@ struct mxl5007t_config {
> >
> > enum mxl5007t_xtal_freq xtal_freq_hz;
> > enum mxl5007t_if_freq if_freq_hz;
> > unsigned int invert_if:1;
> >
> > - unsigned int loop_thru_enable:1;
> > + unsigned int loop_thru_enable:3;
> >
> > unsigned int clk_out_enable:1;
> >
> > + unsigned int no_probe:1;
> > + unsigned int no_reset:1;
> >
> > };
> >
> > #if defined(CONFIG_MEDIA_TUNER_MXL5007T) ||
> >
> > (defined(CONFIG_MEDIA_TUNER_MXL5007T_MODULE) && defined(MODULE))
> > diff -upr linux/drivers/media/usb/dvb-usb-v2/af9035.c
> > linux.new/drivers/media/usb/dvb-usb-v2/af9035.c
> > --- linux/drivers/media/usb/dvb-usb-v2/af9035.c 2013-01-07
> > 05:45:57.0 +0100
> > +++ linux.new/drivers/media/usb/dvb-usb-v2/af9035.c 2013-01-12
> > 00:30:57.557310465 +0100
> > @@ -886,13 +886,17 @@ static struct mxl5007t_config af9035_mxl
> >
> > .loop_thru_enable = 0,
> > .clk_out_enable = 0,
> > .clk_out_amp = MxL_CLKOUT_AMP_0_94V,
> >
> > + .no_probe = 1,
> > + .no_reset = 1,
> >
> > }, {
> >
> > .xtal_freq_hz = MxL_XTAL_24_MHZ,
> > .if_freq_hz = MxL_IF_4_57_MHZ,
> > .invert_if = 0,
> >
> > - .loop_thru_enable = 1,
> > + .loop_thru_enable = 3,
> >
> > .clk_out_enable = 1,
> > .clk_out_amp = MxL_CLKOUT_AMP_0_94V,
> >
> > + .no_probe = 1,
> > + .no_reset = 1,
> >
> >
Re: af9035 test needed!
On 01/12/2013 01:45 AM, Jose Alberto Reguero wrote:
On Viernes, 11 de enero de 2013 20:38:01 Antti Palosaari escribió:
Hello Jose and Gianluca
Could you test that (tda18218 & mxl5007t):
http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/it9135_tune
r
I wonder if ADC config logic still works for superheterodyne tuners
(tuner having IF). I changed it to adc / 2 always due to IT9135 tuner.
That makes me wonder it possible breaks tuners having IF, as ADC was
clocked just over 20MHz and if it is half then it is 10MHz. For BB that
is enough, but I think that having IF, which is 4MHz at least for 8MHz
BW it is too less.
F*ck I hate to maintain driver without a hardware! Any idea where I can
get AF9035 device having tda18218 or mxl5007t?
regards
Antti
Still pending the changes for mxl5007t. Attached is a patch for that.
Changes to make work Avermedia Twinstar with the af9035 driver.
Signed-off-by: Jose Alberto Reguero
I cannot do much about this as it changes mxl5007t driver which is not
maintained by me. :)
regards
Antti
Jose Alberto
diff -upr linux/drivers/media/tuners/mxl5007t.c
linux.new/drivers/media/tuners/mxl5007t.c
--- linux/drivers/media/tuners/mxl5007t.c 2012-08-14 05:45:22.0
+0200
+++ linux.new/drivers/media/tuners/mxl5007t.c 2013-01-10 19:23:09.247556275
+0100
@@ -374,7 +374,6 @@ static struct reg_pair_t *mxl5007t_calc_
mxl5007t_set_if_freq_bits(state, cfg->if_freq_hz, cfg->invert_if);
mxl5007t_set_xtal_freq_bits(state, cfg->xtal_freq_hz);
- set_reg_bits(state->tab_init, 0x04, 0x01, cfg->loop_thru_enable);
set_reg_bits(state->tab_init, 0x03, 0x08, cfg->clk_out_enable << 3);
set_reg_bits(state->tab_init, 0x03, 0x07, cfg->clk_out_amp);
@@ -531,9 +530,12 @@ static int mxl5007t_tuner_init(struct mx
struct reg_pair_t *init_regs;
int ret;
- ret = mxl5007t_soft_reset(state);
- if (mxl_fail(ret))
+ if (!state->config->no_reset) {
+ ret = mxl5007t_soft_reset(state);
+ if (mxl_fail(ret))
goto fail;
+ }
+
/* calculate initialization reg array */
init_regs = mxl5007t_calc_init_regs(state, mode);
@@ -887,7 +889,12 @@ struct dvb_frontend *mxl5007t_attach(str
if (fe->ops.i2c_gate_ctrl)
fe->ops.i2c_gate_ctrl(fe, 1);
- ret = mxl5007t_get_chip_id(state);
+ if (!state->config->no_probe)
+ ret = mxl5007t_get_chip_id(state);
+
+ ret = mxl5007t_write_reg(state, 0x04,
+ state->config->loop_thru_enable);
+
if (fe->ops.i2c_gate_ctrl)
fe->ops.i2c_gate_ctrl(fe, 0);
diff -upr linux/drivers/media/tuners/mxl5007t.h
linux.new/drivers/media/tuners/mxl5007t.h
--- linux/drivers/media/tuners/mxl5007t.h 2012-08-14 05:45:22.0
+0200
+++ linux.new/drivers/media/tuners/mxl5007t.h 2013-01-10 19:19:11.204379581
+0100
@@ -73,8 +73,10 @@ struct mxl5007t_config {
enum mxl5007t_xtal_freq xtal_freq_hz;
enum mxl5007t_if_freq if_freq_hz;
unsigned int invert_if:1;
- unsigned int loop_thru_enable:1;
+ unsigned int loop_thru_enable:3;
unsigned int clk_out_enable:1;
+ unsigned int no_probe:1;
+ unsigned int no_reset:1;
};
#if defined(CONFIG_MEDIA_TUNER_MXL5007T) ||
(defined(CONFIG_MEDIA_TUNER_MXL5007T_MODULE) && defined(MODULE))
diff -upr linux/drivers/media/usb/dvb-usb-v2/af9035.c
linux.new/drivers/media/usb/dvb-usb-v2/af9035.c
--- linux/drivers/media/usb/dvb-usb-v2/af9035.c 2013-01-07 05:45:57.0
+0100
+++ linux.new/drivers/media/usb/dvb-usb-v2/af9035.c 2013-01-12
00:30:57.557310465 +0100
@@ -886,13 +886,17 @@ static struct mxl5007t_config af9035_mxl
.loop_thru_enable = 0,
.clk_out_enable = 0,
.clk_out_amp = MxL_CLKOUT_AMP_0_94V,
+ .no_probe = 1,
+ .no_reset = 1,
}, {
.xtal_freq_hz = MxL_XTAL_24_MHZ,
.if_freq_hz = MxL_IF_4_57_MHZ,
.invert_if = 0,
- .loop_thru_enable = 1,
+ .loop_thru_enable = 3,
.clk_out_enable = 1,
.clk_out_amp = MxL_CLKOUT_AMP_0_94V,
+ .no_probe = 1,
+ .no_reset = 1,
}
};
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: af9035 test needed!
On Viernes, 11 de enero de 2013 20:38:01 Antti Palosaari escribió:
> Hello Jose and Gianluca
>
> Could you test that (tda18218 & mxl5007t):
> http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/it9135_tune
> r
>
> I wonder if ADC config logic still works for superheterodyne tuners
> (tuner having IF). I changed it to adc / 2 always due to IT9135 tuner.
> That makes me wonder it possible breaks tuners having IF, as ADC was
> clocked just over 20MHz and if it is half then it is 10MHz. For BB that
> is enough, but I think that having IF, which is 4MHz at least for 8MHz
> BW it is too less.
>
> F*ck I hate to maintain driver without a hardware! Any idea where I can
> get AF9035 device having tda18218 or mxl5007t?
>
> regards
> Antti
Still pending the changes for mxl5007t. Attached is a patch for that.
Changes to make work Avermedia Twinstar with the af9035 driver.
Signed-off-by: Jose Alberto Reguero
Jose Alberto
diff -upr linux/drivers/media/tuners/mxl5007t.c
linux.new/drivers/media/tuners/mxl5007t.c
--- linux/drivers/media/tuners/mxl5007t.c 2012-08-14 05:45:22.0
+0200
+++ linux.new/drivers/media/tuners/mxl5007t.c 2013-01-10 19:23:09.247556275
+0100
@@ -374,7 +374,6 @@ static struct reg_pair_t *mxl5007t_calc_
mxl5007t_set_if_freq_bits(state, cfg->if_freq_hz, cfg->invert_if);
mxl5007t_set_xtal_freq_bits(state, cfg->xtal_freq_hz);
- set_reg_bits(state->tab_init, 0x04, 0x01, cfg->loop_thru_enable);
set_reg_bits(state->tab_init, 0x03, 0x08, cfg->clk_out_enable << 3);
set_reg_bits(state->tab_init, 0x03, 0x07, cfg->clk_out_amp);
@@ -531,9 +530,12 @@ static int mxl5007t_tuner_init(struct mx
struct reg_pair_t *init_regs;
int ret;
- ret = mxl5007t_soft_reset(state);
- if (mxl_fail(ret))
+ if (!state->config->no_reset) {
+ ret = mxl5007t_soft_reset(state);
+ if (mxl_fail(ret))
goto fail;
+ }
+
/* calculate initialization reg array */
init_regs = mxl5007t_calc_init_regs(state, mode);
@@ -887,7 +889,12 @@ struct dvb_frontend *mxl5007t_attach(str
if (fe->ops.i2c_gate_ctrl)
fe->ops.i2c_gate_ctrl(fe, 1);
- ret = mxl5007t_get_chip_id(state);
+ if (!state->config->no_probe)
+ ret = mxl5007t_get_chip_id(state);
+
+ ret = mxl5007t_write_reg(state, 0x04,
+ state->config->loop_thru_enable);
+
if (fe->ops.i2c_gate_ctrl)
fe->ops.i2c_gate_ctrl(fe, 0);
diff -upr linux/drivers/media/tuners/mxl5007t.h
linux.new/drivers/media/tuners/mxl5007t.h
--- linux/drivers/media/tuners/mxl5007t.h 2012-08-14 05:45:22.0
+0200
+++ linux.new/drivers/media/tuners/mxl5007t.h 2013-01-10 19:19:11.204379581
+0100
@@ -73,8 +73,10 @@ struct mxl5007t_config {
enum mxl5007t_xtal_freq xtal_freq_hz;
enum mxl5007t_if_freq if_freq_hz;
unsigned int invert_if:1;
- unsigned int loop_thru_enable:1;
+ unsigned int loop_thru_enable:3;
unsigned int clk_out_enable:1;
+ unsigned int no_probe:1;
+ unsigned int no_reset:1;
};
#if defined(CONFIG_MEDIA_TUNER_MXL5007T) ||
(defined(CONFIG_MEDIA_TUNER_MXL5007T_MODULE) && defined(MODULE))
diff -upr linux/drivers/media/usb/dvb-usb-v2/af9035.c
linux.new/drivers/media/usb/dvb-usb-v2/af9035.c
--- linux/drivers/media/usb/dvb-usb-v2/af9035.c 2013-01-07 05:45:57.0
+0100
+++ linux.new/drivers/media/usb/dvb-usb-v2/af9035.c 2013-01-12
00:30:57.557310465 +0100
@@ -886,13 +886,17 @@ static struct mxl5007t_config af9035_mxl
.loop_thru_enable = 0,
.clk_out_enable = 0,
.clk_out_amp = MxL_CLKOUT_AMP_0_94V,
+ .no_probe = 1,
+ .no_reset = 1,
}, {
.xtal_freq_hz = MxL_XTAL_24_MHZ,
.if_freq_hz = MxL_IF_4_57_MHZ,
.invert_if = 0,
- .loop_thru_enable = 1,
+ .loop_thru_enable = 3,
.clk_out_enable = 1,
.clk_out_amp = MxL_CLKOUT_AMP_0_94V,
+ .no_probe = 1,
+ .no_reset = 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
af9035 test needed!
Hello Jose and Gianluca Could you test that (tda18218 & mxl5007t): http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/it9135_tuner I wonder if ADC config logic still works for superheterodyne tuners (tuner having IF). I changed it to adc / 2 always due to IT9135 tuner. That makes me wonder it possible breaks tuners having IF, as ADC was clocked just over 20MHz and if it is half then it is 10MHz. For BB that is enough, but I think that having IF, which is 4MHz at least for 8MHz BW it is too less. F*ck I hate to maintain driver without a hardware! Any idea where I can get AF9035 device having tda18218 or mxl5007t? 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
