On Thu, 2009-07-02 at 18:45 +0100, Steve Firth wrote:
> Andy
>
> I've fixed the problem with my tuners, ....... (my mythtv SQL
> database simply {ahem....} needed to be repaired).
>
> .....so now back to the plot.......
>
>
> I've extracted the .fw as mentioned previously and copied it
> to /lib/firmware
>
> I've loaded/compiled/installed the "repo".
>
> I've re-tuned both cards and I can report that everything seems to
> work again. Cards are recognised,
> there are no error messages (that I can see) in dmesg
> or /var/log/messages.
>
> Summary : I can watch DVB-T on the ACER Idea 500 using your last
> repo
>
OK, good. I'll assemble a cleaned-up patch for the DVB-T and basic
board support and have it pulled to the main v4l-dvb repository.
> Is there any other verification that I need to do ? (EEPROM
> notwithstanding, which I know you still want me to do)
Not at the moment, unless you really want to use, and hence are
motivated to test, the various analog inputs: CVBS, SVideo, audio line
in.
I don't needed 7 MHz DVB-T tested yet either. The latest v4l-dvb just
pulled a patch I made for the XC3028 for 7 MHz DVB-T. So if, you test 7
MHz DVB-T right now and run into any problems, I'm just going to tell
you to wait until everything makes it to the main v4l-dvb repository.
In the near future, I'll give you one more patch for the EEPROM dump, to
see if I can get that right this time. :)
> I've included "grep mt3" sections of messages and dmesg below. If
> you prefer the full files I can send them
> under seperate cover. I tried "grep-ing" for cx18 but the filesize was
> above the limit
>
>
> >>grep mt3 messages dmesg_2ndJulacer500_repo
>
> messages:Jul 2 18:00:02 Cinema kernel: [ 1729.925082] cx18
> 0000:02:00.0: firmware: requesting dvb-cx18-mpc718-mt352.fw
> messages:Jul 2 18:00:30 Cinema kernel: [ 1757.601593] cx18
> 0000:02:00.0: firmware: requesting dvb-cx18-mpc718-mt352.fw
> messages:Jul 2 18:00:30 Cinema kernel: [ 1757.650917] cx18
> 0000:02:01.0: firmware: requesting dvb-cx18-mpc718-mt352.fw
> messages:Jul 2 18:00:56 Cinema kernel: [ 1783.216400] cx18
> 0000:02:00.0: firmware: requesting dvb-cx18-mpc718-mt352.fw
> messages:Jul 2 18:01:20 Cinema kernel: [ 1806.985972] cx18
> 0000:02:00.0: firmware: requesting dvb-cx18-mpc718-mt352.fw
> messages:Jul 2 18:01:20 Cinema kernel: [ 1807.019274] cx18
> 0000:02:01.0: firmware: requesting dvb-cx18-mpc718-mt352.fw
> messages:Jul 2 18:03:33 Cinema kernel: [ 1940.822311] cx18
> 0000:02:00.0: firmware: requesting dvb-cx18-mpc718-mt352.fw
> messages:Jul 2 18:07:34 Cinema kernel: [ 2181.400237] cx18
> 0000:02:01.0: firmware: requesting dvb-cx18-mpc718-mt352.fw
> messages:Jul 2 18:12:00 Cinema kernel: [ 2447.921560] cx18
> 0000:02:00.0: firmware: requesting dvb-cx18-mpc718-mt352.fw
> messages:Jul 2 18:12:00 Cinema kernel: [ 2448.071017] cx18
> 0000:02:01.0: firmware: requesting dvb-cx18-mpc718-mt352.fw
> messages:Jul 2 18:16:12 Cinema kernel: [ 32.208000] cx18
> 0000:02:00.0: firmware: requesting dvb-cx18-mpc718-mt352.fw
> messages:Jul 2 18:16:14 Cinema kernel: [ 34.228119] cx18
> 0000:02:01.0: firmware: requesting dvb-cx18-mpc718-mt352.fw
> dmesg_2ndJulacer500_repo:[ 32.205722] mt352: mt352_init: hello
> dmesg_2ndJulacer500_repo:[ 32.208000] cx18 0000:02:00.0: firmware:
> requesting dvb-cx18-mpc718-mt352.fw
> dmesg_2ndJulacer500_repo:[ 32.276915] mt352:
> mt352_calc_nominal_rate: bw 8, adc_clock 20480 => 0x7249
> dmesg_2ndJulacer500_repo:[ 32.276920] mt352: mt352_calc_input_freq:
> if2 4560, ife 4560, adc_clock 20480 => -3645 / 0x31c3
> dmesg_2ndJulacer500_repo:[ 34.225843] mt352: mt352_init: hello
> dmesg_2ndJulacer500_repo:[ 34.228119] cx18 0000:02:01.0: firmware:
> requesting dvb-cx18-mpc718-mt352.fw
Hmmm. What events trip those firmware loads: channel changes, or
open/close, or something else? I wasn't quite sure how often the mt352
driver module would call my init function. If it's excessively going
back and forth to the filesystem, I may work up something to cache the
firmware (it's only 48 bytes or so).
Regards,
Andy
>
>
>
>
> ----- Original message -----
> Sent: 2009/07/02 00:25:36
> Subject: Re:Re: [ivtv-devel] cx18: MPC718 MT352 "firmware" load needs
> testing (Re: Acer aspire idea 500?)
>
> On Wed, 2009-07-01 at 22:36 +0100, Steve Firth wrote:
> >
> > Hi Andy,
> > Thanks for the clarification, I now have a better idea of what
> > you're trying to achieve here.
> >
> > I think that the new repo worked but I need to do some more work.
> >
> > Compilation/installation worked fine. I
> see /dev/dvb/adaptor*/......
> > devices mounted correctly. But I cannot tune
> > in one of my cards I get a "No tables" and timeout error on the one
> > card. Hope I haven't popped it earlier!
> >
> > I did see video on the second tuner card, but there was no sound. I
> > think I now have some problems unrelated to your firmware trials
> > which I need to address, I'll take a more detailed look as soon as
> > possible.
> >
> > Question: How can I be sure that I'm now really using the latest
> > firmware not the original ones?
>
> The original v4l-cx23418-* firmware files are still nedded.
>
>
> To see if the new, additional dvb-cx18-mpc718-mt352.fw file is being
> used, hmm....
>
> On my kernel, the kernel would emit something like:
>
> "firmware: requesting dvb-cx18-mpc718-mt352.fw"
>
> at the "info" level in dmesg or /var/log/messages.
>
>
> And following that, you *should not* see something like this in dmesg
> or /var/log/messages being emitted by the cx18 driver:
>
> "Unable to open firmware file dvb-cx18-mpc718-mt352.fw"
>
> "Firmware dvb-cx18-mpc718-mt352.fw has a bad size: 100 bytes"
>
> "The MPC718 board variant with the MT352 DVB-T demodualtor will not
> work without it"
> "Run 'linux/Documentation/dvb/get_dvb_firmware mpc718' if you need the
> firmware"
>
> "frontend initialization failed"
>
>
> Regards,
> Andy
>
> > Steve
> >
> >
> > ----- Original message -----
> > Sent: 2009/07/01 20:37:17
> > Subject: Re:Re: [ivtv-devel] cx18: MPC718 MT352 "firmware" load
> needs
> > testing (Re: Acer aspire idea 500?)
> >
> > Andy Walls wrote:
> > > Those latest changes look for the "dvb-cx18-mpc718-mt352.fw" file
> > to
> > > load and initialize the MT352 DVB-T demodulator chip.
> > >
> > > It has to be done this way to avoid any software license
> problems.
> > The
> > > information to properly initialize the MT352 is not publicly
> > available,
> > > and we musn't hardcode into the Linux kernel an initialization
> > sequence
> > > extracted from the Windows driver.
> > >
> > > What you have tested previously and have reported as working,
> > *cannot*
> > > be included in the Linux kernel. These latest changes in my
> > cx18-mpc718
> > > repo *can* be included in the Linux kernel.
> >
> >
> > _______________________________________________
> > ivtv-devel mailing list
> > [email protected]
> > http://ivtvdriver.org/mailman/listinfo/ivtv-devel
>
>
> _______________________________________________
> ivtv-devel mailing list
> [email protected]
> http://ivtvdriver.org/mailman/listinfo/ivtv-devel
> _______________________________________________
> ivtv-devel mailing list
> [email protected]
> http://ivtvdriver.org/mailman/listinfo/ivtv-devel
_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel