Hi Trent,
On Wed, 27 May 2009, Trent Piepho wrote:
On Tue, 26 May 2009, Patrick Boettcher wrote:
MHz to 161 Mhz as welll as 439-447 MHz. Probably wrong. My guess is the
data sheet says, "low band 48 to 154 MHz, mid band 161 MHz to 439 MHz,
etc.," where 154 is the frequency of the last channel in the low band and
161 is the first channel in the mid band. Then someone translated this to
code without really understanding what's going on. It should probably be:
if (params->frequency > 443000000) bs = 0x08;
else if (params->frequency > 157500000) bs = 0x0a;
else bs = 0x09;
The tuner's limits should already be enforced elsewhere. Or just convert
this to use dvb_pll.
Thanks for pointing this out, can you please provide a patch for that?
Preferably for the dvb_pll-solution?
I've done this, but found some more mistakes in the flexcop code wrt
frontend attachment.
In patch 7469 you changed a failure path "dvb_frontend_detach(fc->fe)" into
a "fc->fe->ops->release(fc->fe)", which isn't correct. There is more stuff
dvb_frontend_detach() does besides call the main release method.
The various attach functions in flexcop-fe-tuner don't return success/fail,
which is a problem when frontend attachment partially fails. For instance
if mt352 attachment works but dvb-pll attachment then fails the driver
will think everything is ok because fc->fe is non-NULL, but the tuner will
not work. It makes more sense to consider this an error and clean up.
There are a couple other places where frontend attachment can partially
fail where I wasn't entirely sure what's right. In
skystar2_rev27_attach(), after the s5h1420 demod is attached, attachment of
a ISL6421 LNB and ITD1000 tuner is attempted. If these fail an error
message is printed but the rest of the code will consider the frontend to
be successfully attached. Can the frontend work if the ISL6421 or ITD1000
didn't attach (which can happen if the driver isn't present even if the
hardware is fine)? I'm guessing not and called these cases an error. If
it's not an error, then the err() printout should probably be warning or
info level.
Does this patch to fix these problems look ok?
In fact, everything looks correct in my eyes. I'll ask Mauro to pull any
minute from now.
I even have an explaination why the failing attach of the itd1000 was
not errored out: when I did the development I was using a userspace
proprietary driver to validate, for that I needed the demod to be
attached...
Thanks for cleaning up this mess.
best regards,
Patrick.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
