Re: KWorld ATSC 115 all static

Re: KWorld ATSC 115 all static

[Hans Verkuil]

> Hans Verkuil wrote:
>> On Thursday 15 January 2009 06:01:28 CityK wrote:
>>
>>> Hans Verkuil wrote:
>>>
>>>> OK, I couldn't help myself and went ahead and tested it. It seems
>>>> fine, so please test my tree:
>>>>
>>>> http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-saa7134
>>>>
>>>> Let me know if it works.
>>>>
>>> Hi Hans,
>>>
>>> It didn't work.  No analog reception on either RF input.  (as Mauro
>>> noted, DVB is unaffected; it still works).
>>>
>>> dmesg output looks right:
>>>
>>> tuner-simple 1-0061: creating new instance
>>> tuner-simple 1-0061: type set to 68 (Philips TUV1236D ATSC/NTSC dual
>>> in)
>>>
>>> I tried backing out of the modules and then reloading them, but no
>>> change.  (including after fresh build or after rebooting)
>>>
>>
>> Can you give the full dmesg output? Also, is your board suppossed to
>> have a tda9887 as well?
>>
>
> Hans' changes are not enough to fix the ATSC115 issue.

Ah, OK.

> I believe that if you can confirm that the same problem exists, but the
> previous workaround continues to work even after Hans' changes, then I
> believe that confirms that Hans' changes Do the Right Thing (tm).
>
> ATSC115 is broken not because the tuner type assignment has been removed
> from attach_inform.
>
> This is actually a huge problem across all analog drivers now, since we
> are no longer able to remove the "tuner" module and modprobe it again --
> the second modprobe will not allow for an attach, as there will be no
> way for the module to be recognized without having the glue code needed
> inside attach_inform...

Huh? Why would you want to rmmod and modprobe tuner? Anyway, drivers that
use v4l2_subdev (like my converted saa7134) will increase the tuner module
usecount, preventing it from being rmmod'ed.

Regards,

      Hans

> ...unless somebody has a suggestion?
>
> Anyway, if the previous workaround works after Hans' changes, then I
> think his changes should be merged -- even though it doesnt fix ATSC115,
> it is indeed a step into the right direction.
>
> If the ATSC115 hack-fix patch doesn't apply anymore, please let me know
> -- I'll respin it.
>
> Regards,
>
> Mike Krufky
>


-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

Re: KWorld ATSC 115 all static

[Michael Krufky]

Hey Hans,

Hans Verkuil wrote:
>> Hans Verkuil wrote:
>>     
>>> On Thursday 15 January 2009 06:01:28 CityK wrote:
>>>
>>>       
>>>> Hans Verkuil wrote:
>>>>
>>>>         
>>>>> OK, I couldn't help myself and went ahead and tested it. It seems
>>>>> fine, so please test my tree:
>>>>>
>>>>> http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-saa7134
>>>>>
>>>>> Let me know if it works.
>>>>>
>>>>>           
>>>> Hi Hans,
>>>>
>>>> It didn't work.  No analog reception on either RF input.  (as Mauro
>>>> noted, DVB is unaffected; it still works).
>>>>
>>>> dmesg output looks right:
>>>>
>>>> tuner-simple 1-0061: creating new instance
>>>> tuner-simple 1-0061: type set to 68 (Philips TUV1236D ATSC/NTSC dual
>>>> in)
>>>>
>>>> I tried backing out of the modules and then reloading them, but no
>>>> change.  (including after fresh build or after rebooting)
>>>>
>>>>         
>>> Can you give the full dmesg output? Also, is your board suppossed to
>>> have a tda9887 as well?
>>>
>>>       
>> Hans' changes are not enough to fix the ATSC115 issue.
>>     
>
> Ah, OK.
>
>   
>> I believe that if you can confirm that the same problem exists, but the
>> previous workaround continues to work even after Hans' changes, then I
>> believe that confirms that Hans' changes Do the Right Thing (tm).
>>
>> ATSC115 is broken not because the tuner type assignment has been removed
>> from attach_inform.
>>
>> This is actually a huge problem across all analog drivers now, since we
>> are no longer able to remove the "tuner" module and modprobe it again --
>> the second modprobe will not allow for an attach, as there will be no
>> way for the module to be recognized without having the glue code needed
>> inside attach_inform...
>>     
>
> Huh? Why would you want to rmmod and modprobe tuner? Anyway, drivers that
> use v4l2_subdev (like my converted saa7134) will increase the tuner module
> usecount, preventing it from being rmmod'ed.

There was a load order dependency in the saa7134 driver.  Some users 
have to remove tuner and modprobe it again in order to make analog tv 
work.  Yes, that's a bug.

The bug got worse when Mauro made changes to attach_inform -- I believe 
this was for the sake of some xceive tuners... I don't recall the 
details now.

Anyway, long story short... there are many different bugs all 
manifesting themselves at once here.  Load order dependency -- I don't 
think we ever understood why that issue exists.  The fix for the load 
order dependency no longer works, as attach_inform no longer cares if a 
new tuner appears on the bus.

So, my ATSC115 hack-patch restored the attach_inform functionality for 
the sake of ATSC110/115 users.  I am not pushing for its merge -- this 
*will* break the boards that Mauro was working on when he changed 
attach_inform.

As I don't really understand what he was going for when he made those 
changes, I don't know how to fix this problem without creating new bugs 
on Mauro's cards.  I put out that patch in hopes that somebody else 
would put the pieces together and make a better fix that would work for 
everybody.  That hasn't happened yet :-(


-Mike

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: KWorld ATSC 115 all static

[Mauro Carvalho Chehab]

On Thu, 15 Jan 2009 09:30:35 -0500
Michael Krufky <mkrufky@linuxtv.org> wrote:

> Hey Hans,
> 
> Hans Verkuil wrote:
> >> Hans Verkuil wrote:
> >>     
> >>> On Thursday 15 January 2009 06:01:28 CityK wrote:
> >>>
> >>>       
> >>>> Hans Verkuil wrote:
> >>>>
> >>>>         
> >>>>> OK, I couldn't help myself and went ahead and tested it. It seems
> >>>>> fine, so please test my tree:
> >>>>>
> >>>>> http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-saa7134
> >>>>>
> >>>>> Let me know if it works.
> >>>>>
> >>>>>           
> >>>> Hi Hans,
> >>>>
> >>>> It didn't work.  No analog reception on either RF input.  (as Mauro
> >>>> noted, DVB is unaffected; it still works).
> >>>>
> >>>> dmesg output looks right:
> >>>>
> >>>> tuner-simple 1-0061: creating new instance
> >>>> tuner-simple 1-0061: type set to 68 (Philips TUV1236D ATSC/NTSC dual
> >>>> in)
> >>>>
> >>>> I tried backing out of the modules and then reloading them, but no
> >>>> change.  (including after fresh build or after rebooting)
> >>>>
> >>>>         
> >>> Can you give the full dmesg output? Also, is your board suppossed to
> >>> have a tda9887 as well?
> >>>
> >>>       
> >> Hans' changes are not enough to fix the ATSC115 issue.
> >>     
> >
> > Ah, OK.
> >
> >   
> >> I believe that if you can confirm that the same problem exists, but the
> >> previous workaround continues to work even after Hans' changes, then I
> >> believe that confirms that Hans' changes Do the Right Thing (tm).
> >>
> >> ATSC115 is broken not because the tuner type assignment has been removed
> >> from attach_inform.
> >>
> >> This is actually a huge problem across all analog drivers now, since we
> >> are no longer able to remove the "tuner" module and modprobe it again --
> >> the second modprobe will not allow for an attach, as there will be no
> >> way for the module to be recognized without having the glue code needed
> >> inside attach_inform...
> >>     
> >
> > Huh? Why would you want to rmmod and modprobe tuner? Anyway, drivers that
> > use v4l2_subdev (like my converted saa7134) will increase the tuner module
> > usecount, preventing it from being rmmod'ed.
> 
> There was a load order dependency in the saa7134 driver.  Some users 
> have to remove tuner and modprobe it again in order to make analog tv 
> work.  Yes, that's a bug.
> 
> The bug got worse when Mauro made changes to attach_inform -- I believe 
> this was for the sake of some xceive tuners... I don't recall the 
> details now.
> 
> Anyway, long story short... there are many different bugs all 
> manifesting themselves at once here.  Load order dependency -- I don't 
> think we ever understood why that issue exists.  The fix for the load 
> order dependency no longer works, as attach_inform no longer cares if a 
> new tuner appears on the bus.

It has nothing to do with the load order. It is related to i2c binding. With
the current approach (before Hans patch), the i2c core will try to bind the
tuner after having 2 conditions satisfied:
	1) I2C bus were registered;
	2) tuner code is available.

So, if you load tuner before saa7134 (or have it compiled in-kernel), the code
will try to probe tuners at the moment you register i2c bus. Otherwise, it will
try to bind only when request_module is handled.

Some devices with DVB has an internal i2c gate. For a subset of these, the i2c
gate is inside the tuner. So, you need to bind the tuner device before probing
for the frontends. On the other set of devices, the gate is inside the demod.
So, you need to turn the i2c gate before running the i2c address seek for tuner.

This generated lots of issues in the past, like machines with two boards
doesn't work anymore. With two boards, and a tuner module, the first board
probes tuner after opening the demod gateway. However, the second board will
try to probe tuner before opening the i2c gateway. So, tuner is not found.

-

After having Hans patches working, we need to implement the following workflow
inside the driver:

1) register the i2c bus and load tuner (the order shouldn't be relevant
anymore, since the attachment is not related anymore with i2c bus register and/or
with tuner load);
2) call the i2c open gate control, if it needs to open the demod i2c gate in
order to access the tuner;
3) tuner type is determined via eeprom and/or board entry;
3) tuner i2c address is scanned and tuner is bound with the proper type;
4) the i2c open gate control is called, if needed in order to access the demod;
5) demod is bound.

> So, my ATSC115 hack-patch restored the attach_inform functionality for 
> the sake of ATSC110/115 users.  I am not pushing for its merge -- this 
> *will* break the boards that Mauro was working on when he changed 
> attach_inform.
>
> As I don't really understand what he was going for when he made those 
> changes, I don't know how to fix this problem without creating new bugs 
> on Mauro's cards.  I put out that patch in hopes that somebody else 
> would put the pieces together and make a better fix that would work for 
> everybody.  That hasn't happened yet :-(

Hacks won't be needed anymore.

All we need is to fix the board entries, properly identifying what is needed to
access tuner and/or demod, and double check what devices need tda9887.

Cheers,
Mauro

Re: KWorld ATSC 115 all static

[Trent Piepho]

On Thu, 15 Jan 2009, Mauro Carvalho Chehab wrote:
> It has nothing to do with the load order. It is related to i2c binding. With
> the current approach (before Hans patch), the i2c core will try to bind the
> tuner after having 2 conditions satisfied:
> 	1) I2C bus were registered;
> 	2) tuner code is available.
>
> So, if you load tuner before saa7134 (or have it compiled in-kernel), the code
> will try to probe tuners at the moment you register i2c bus. Otherwise, it will
> try to bind only when request_module is handled.
>
> Some devices with DVB has an internal i2c gate. For a subset of these, the i2c
> gate is inside the tuner. So, you need to bind the tuner device before probing
> for the frontends. On the other set of devices, the gate is inside the demod.
> So, you need to turn the i2c gate before running the i2c address seek for tuner.

I wonder if a better way to fix these problems is to use virtual I2C busses
for the gate?  When a device has some kind of i2c gate, it creates a new
I2C adapter for the devices behind the gate.  The code for this virtual i2c
adapter can just open the gate, pass of the request to the main i2c
adapter, then close the gate.  Creating a new i2c adapter should trigger
the i2c drivers that scan to do so and find new devices behind the gate.

It seems like this would solve the scan order problem, since the bus the
tuner/demod/whatever is on won't exist until the gate it is behind can be
properly controlled.

There are a number of additional benefits too.  There are many devices that
can be behind many different kinds of gates.  So we have all these gate
control functions that must be called manually from all over the place.
This adds bloat and developers are always forgetting to call them, which
doesn't cause any problem they notice because their card doesn't have a
gate.

With manual gate control, we must remember to close the gate when done with
the device.  But this isn't always done and the gate is left open.  These
gates are there for a reason, to shield RF devices from noise created by
the I2C bus, and so leaving them opens impairs RF performance.

And when the gate is only controlled by the driver in the kernel, it is
hard to manually debug/test i2c devices from userspace with i2c-dev.

Re: KWorld ATSC 115 all static

[Mauro Carvalho Chehab]

On Thu, 15 Jan 2009 10:33:15 -0800 (PST)
Trent Piepho <xyzzy@speakeasy.org> wrote:

> On Thu, 15 Jan 2009, Mauro Carvalho Chehab wrote:
> > It has nothing to do with the load order. It is related to i2c binding. With
> > the current approach (before Hans patch), the i2c core will try to bind the
> > tuner after having 2 conditions satisfied:
> > 	1) I2C bus were registered;
> > 	2) tuner code is available.
> >
> > So, if you load tuner before saa7134 (or have it compiled in-kernel), the code
> > will try to probe tuners at the moment you register i2c bus. Otherwise, it will
> > try to bind only when request_module is handled.
> >
> > Some devices with DVB has an internal i2c gate. For a subset of these, the i2c
> > gate is inside the tuner. So, you need to bind the tuner device before probing
> > for the frontends. On the other set of devices, the gate is inside the demod.
> > So, you need to turn the i2c gate before running the i2c address seek for tuner.
> 
> I wonder if a better way to fix these problems is to use virtual I2C busses
> for the gate?

For now, we should finish the Hans approach, since it also helps to stop using
the legacy i2c methods. After having all drivers using it, we can do some
cleanup at the drivers.

However, I like the idea of providing a better support for those buses that
have an i2c switch inside (I don't like to call it "virtual" - it is a real i2c
bus, where part of the bus is controlled by a switch).

>  When a device has some kind of i2c gate, it creates a new
> I2C adapter for the devices behind the gate.  The code for this virtual i2c
> adapter can just open the gate, pass of the request to the main i2c
> adapter, then close the gate.  Creating a new i2c adapter should trigger
> the i2c drivers that scan to do so and find new devices behind the gate.
> 
> It seems like this would solve the scan order problem, since the bus the
> tuner/demod/whatever is on won't exist until the gate it is behind can be
> properly controlled.
> 
> There are a number of additional benefits too.  There are many devices that
> can be behind many different kinds of gates.  So we have all these gate
> control functions that must be called manually from all over the place.
> This adds bloat and developers are always forgetting to call them, which
> doesn't cause any problem they notice because their card doesn't have a
> gate.
> 
> With manual gate control, we must remember to close the gate when done with
> the device.  But this isn't always done and the gate is left open.  These
> gates are there for a reason, to shield RF devices from noise created by
> the I2C bus, and so leaving them opens impairs RF performance.
> 
> And when the gate is only controlled by the driver in the kernel, it is
> hard to manually debug/test i2c devices from userspace with i2c-dev.

I'm not sure if we should implement it inside v4l core, or at i2c-core. 

Maybe the latter could be more appropriate, since maybe some other devices could have
similar issues, like the embedded processor/controllers, where you have an i2c
bus there connected to several different devices, like those used on cellular
phones. 

I bet that some embedded devices uses the same i2c bus for more than
one subsystem (like having a radio and/or a webcam and some temperature/battery
sensors). In this case, a virtual i2c support could be interesting.

Maybe Jean could give us some suggestions about the better approach for such cases.

Cheers,
Mauro

Re: KWorld ATSC 115 all static

[Trent Piepho]

On Fri, 16 Jan 2009, Jean Delvare wrote:
> On Fri, 16 Jan 2009 05:34:59 -0800 (PST), Trent Piepho wrote:
> > On Fri, 16 Jan 2009, Jean Delvare wrote:
> > > Hi Mauro, Trent,
> > > On Fri, 16 Jan 2009 00:02:52 -0200, Mauro Carvalho Chehab wrote:
> > > > For now, we should finish the Hans approach, since it also helps to stop using
> > > > the legacy i2c methods. After having all drivers using it, we can do some
> > > > cleanup at the drivers.
> >
> > How will this work for drivers like bttv, where the i2c address of the
> > tuner chips isn't know for every supported card?
>
> Is this a problem in practice? My understanding was that I2C gates were
> relatively recent in the history of V4L devices, so I assumed that for
> devices with an I2C gate we would know where the devices are.

Changing hardware without notice is something manufactures still do, which
makes probing even for modern hardware still useful in some cases.

But the old hardware that was always probed uses the same i2c clients as
the new hardware that has gates and muxes.

> This is indeed a possible implementation. One could argue though that
> it's a bit overkill to instantiate a separate i2c_adapter just for a
> gate. There are also caveats you must pay attention to. Two things in
> particular that come to my mind:

The I2C layer doesn't have a concept for an i2c bus segment, so an
i2c_adapter is the next closest thing.  One could create an entirely new
struct i2c_bus for that, but how would it be different than the currenct
i2c_adapter?  It seems like just another layer of complexity.

> * Your proposal above, in its simple form, is incompatible with I2C
> device detection, because devices which are before the gate would be
> double-detected (once on each segment.)
>
> The first point is very easy to handle, the second is a little more
> complicated. Basically you should add an address check at the beginning
> of cx88_gate_i2c_xfer() to reject all transfers except to the device
> you know is behind the gate.

I can think of a few more ways to do.  The main adapter could get
registered with no I2C_CLASS_* (or with something like I2C_CLASS_MUX) so
clients that scan won't scan it.  Then create virtual adapters for gate
closed and gate open.  Scan gate closed first and then excluded any
addresses found from the gate open adapter.

> At which point it is no longer clear why you want to have 2
> i2c_adapters. You can have just one which opens (and closes) the gate
> automatically for the right I2C address and not for the other addresses.

The scanning order problem.  The adapter is scanned before the gate can be
controlled.  Works better with i2c-dev too.  Suppose I have a new card or a
new revision and want to scan for devices behind the gate and see if I can
figure out what they are?

> > > * At I2C bus driver level. We can have a pre-transfer handler and a
> > > post-transfer handler, which does what needs to be done (like opening
> > > and closing a gate) based on the address of the device that is being
> > > accessed. I had discussed this approach with Michael Krufky long ago.
> >
> > This won't work when muxes are used to put multiple i2c devices with the
> > same address behind a single master.
>
> Sorry for not being clear, I was only trying to address the gate issue
> here, not the (more complex) multiplexing issue. I am not aware of V4L
> devices having real I2C muxes?

I think some multi-tuner cards have real muxes.  But if the system created
for muxes can be applied to gates as well, why not use it instead of
creating something else for gates?

> > It still has the problem of probe order when one wants to scan for chips.
> > The i2c core does scanning when a new adapter is created.  But, suppose the
> > mux is an i2c device on the adapter?  In order for the scanner to find
> > anything behind the mux, it needs to be detected and working before the bus
> > is scanned.  But this may not happen.  Say one calls:
> > i2c_add_adapter(adap); i2c_new_device(adap, &the_mux);
> >
> > If the client driver for the device behind the mux uses probing, and is
> > already loaded when i2c_add_adapter() is called, then it will be probed for
> > before the i2c_new_device() call and won't be found because the mux isn't
> > working.
>
> You are right, this is a problem.
>
> > If instead the mux driver created a new i2c adapter for the segment(s)
> > behind it, which would happen when i2c_new_device() is called, then those
> > segments would be probed at the correct time.
>
> This doesn't fully solve the problem, because you have no idea in which
> state the mux is initially. If one of its segments is already selected,
> then the detection will happen when it shouldn't (the chip drivers
> thinks it has found a device on the trunk) and things will break as
> soon as the mux driver is in action (the device behind the mux will
> "move" to its actual branch.)

First adapter created with the class set to 0 or I2C_CLASS_MUX, so nothing
scans it (except a mux driver that scans).  Mux is added with
i2c_new_device() and creats new busses/adapters for each segment.  These
have the "real" class for the device and so get scanned.

> > But this isn't insolvable.  For a real mux, the driver could only switch
> > the mux when the selected segment is different from the last one.  For a
> > gate, one could reset a timer on each transfer that will close the gate
> > when it gets triggered.  That way when multiple commands arrive close
> > enough together the gate can be left open for all of them.  This has an
> > advantage over manually batching commands in that in many cases the code
> > that sends one command does not know that another command will be sent
> > immediately afterwards and so they are not batched.
>
> But this has the disadvantage to leave the gate opened for longer than
> it really has to, which could have adverse consequences on video
> quality. Anyway, I'm leaving this up to you video/media people, as I
> don't know enough myself about this to make a sane decision.

I think the gates are primarily meant to shield the device from noise
relating to i2c bus traffic for other devices.  So it shouldn't be a
problem to leave the gate open as long as it's closed when a message that
doesn't need to go behind the gate is sent.

Re: KWorld ATSC 115 all static

[Jean Delvare]

Hi Trent,

On Sat, 17 Jan 2009 11:45:57 -0800 (PST), Trent Piepho wrote:
> On Fri, 16 Jan 2009, Jean Delvare wrote:
> > On Fri, 16 Jan 2009 05:34:59 -0800 (PST), Trent Piepho wrote:
> > > How will this work for drivers like bttv, where the i2c address of the
> > > tuner chips isn't know for every supported card?
> >
> > Is this a problem in practice? My understanding was that I2C gates were
> > relatively recent in the history of V4L devices, so I assumed that for
> > devices with an I2C gate we would know where the devices are.
> 
> Changing hardware without notice is something manufactures still do, which
> makes probing even for modern hardware still useful in some cases.

But I would expect limited probing then (using
i2c_new_probed_device()), not wide probing using the .detect() method.

> But the old hardware that was always probed uses the same i2c clients as
> the new hardware that has gates and muxes.

This isn't necessarily an issue: your I2C chip driver can implement
a .detect() method for old hardware, where class is set to
I2C_CLASS_TV_ANALOG, while more recent hardware set no class and
instantiate the I2C devices explicitly. The new i2c model allows both
approaches to cohabit nicely.

> > This is indeed a possible implementation. One could argue though that
> > it's a bit overkill to instantiate a separate i2c_adapter just for a
> > gate. There are also caveats you must pay attention to. Two things in
> > particular that come to my mind:
> 
> The I2C layer doesn't have a concept for an i2c bus segment, so an
> i2c_adapter is the next closest thing.  One could create an entirely new
> struct i2c_bus for that, but how would it be different than the currenct
> i2c_adapter?  It seems like just another layer of complexity.

I agree with you, using i2c_adapter for bus segments is the plan, as
far as multiplexers are concerned. My point was whether it was worth
considering a chip behind a gate as a bus segment or not.

> > * Your proposal above, in its simple form, is incompatible with I2C
> > device detection, because devices which are before the gate would be
> > double-detected (once on each segment.)
> >
> > The first point is very easy to handle, the second is a little more
> > complicated. Basically you should add an address check at the beginning
> > of cx88_gate_i2c_xfer() to reject all transfers except to the device
> > you know is behind the gate.
> 
> I can think of a few more ways to do.  The main adapter could get
> registered with no I2C_CLASS_* (or with something like I2C_CLASS_MUX) so
> clients that scan won't scan it.  Then create virtual adapters for gate
> closed and gate open.  Scan gate closed first and then excluded any
> addresses found from the gate open adapter.

Yeah, that could work in some cases... At the cost of 3 i2c_adapter
instances. And it seems specifically tailored for hardware that need
scanning. I mean, if you do _not_ scan when gate is closed, then you
don't know what addresses must be removed from the gate-opened adapter,
so you can't allow for probing on that adapter.

But this doesn't seem to work in the general case: you may not be able
to actually scan for chips when gate is closed.  Some chips may not
respond to probing (either because they never do, or because they are
themselves behind another gate or multiplexer.) For complex topologies,
I am skeptical that your approach will be practical. It might even be
pretty confusing due to the fact that the apparent topology will be
quite different from the physical one.

(If we go that route then it does make sense to start speaking of
virtual adapters.)

Anyway, there's nothing missing from i2c-core right now to implement
this, is there?

> > At which point it is no longer clear why you want to have 2
> > i2c_adapters. You can have just one which opens (and closes) the gate
> > automatically for the right I2C address and not for the other addresses.
> 
> The scanning order problem.  The adapter is scanned before the gate can be
> controlled.  Works better with i2c-dev too.  Suppose I have a new card or a
> new revision and want to scan for devices behind the gate and see if I can
> figure out what they are?

Well, if you have a new card, you presumably don't know that it has a
gate to start with. If you have enough information about the gate, then
I expect you to also have enough information about what is behind it.

One possible requirement this discussion is bringing up, is the ability
to instantiate an i2c_adapter without any probing class set, then do
some initialization (e.g. accessing the gate chip, and close the gate)
and only then add probing classes (or have a separate function to ask
for re-probing of a given adapter.) This would fulfill your needs,
wouldn't it? Then we can stick to the physical topology.

> > Sorry for not being clear, I was only trying to address the gate issue
> > here, not the (more complex) multiplexing issue. I am not aware of V4L
> > devices having real I2C muxes?
> 
> I think some multi-tuner cards have real muxes.  But if the system created
> for muxes can be applied to gates as well, why not use it instead of
> creating something else for gates?

If we had support for muxes already, they I'd say yes, let's handle
gates the same. But the problem is that full muxes support is a
non-trivial thing, and we don't have it now, and I have no idea when we
will have it. I _hope_ before the end of the year, but I didn't even
start working on it, and I don't have any hardware to test either.

My main reason for suggesting a simple handling of gates is so that you
can have it quickly. But if you prefer to help me (and others)
implement full support for muxes instead, you're very welcome :)

> (..)
> First adapter created with the class set to 0 or I2C_CLASS_MUX, so nothing
> scans it (except a mux driver that scans).  Mux is added with
> i2c_new_device() and creats new busses/adapters for each segment.  These
> have the "real" class for the device and so get scanned.

Mux drivers should not scan. I mean, I've never see a mux chip that can
be detected. You should _know_ what mux you have on your bus.

> > But this has the disadvantage to leave the gate opened for longer than
> > it really has to, which could have adverse consequences on video
> > quality. Anyway, I'm leaving this up to you video/media people, as I
> > don't know enough myself about this to make a sane decision.
> 
> I think the gates are primarily meant to shield the device from noise
> relating to i2c bus traffic for other devices.  So it shouldn't be a
> problem to leave the gate open as long as it's closed when a message that
> doesn't need to go behind the gate is sent.

Ah, OK, I get the idea now.

-- 
Jean Delvare

Re: KWorld ATSC 115 all static

[hermann pitton]

Am Donnerstag, den 15.01.2009, 15:29 -0200 schrieb Mauro Carvalho
Chehab:
> On Thu, 15 Jan 2009 09:30:35 -0500
> Michael Krufky <mkrufky@linuxtv.org> wrote:
> 
> > Hey Hans,
> > 
> > Hans Verkuil wrote:
> > >> Hans Verkuil wrote:
> > >>     
> > >>> On Thursday 15 January 2009 06:01:28 CityK wrote:
> > >>>
> > >>>       
> > >>>> Hans Verkuil wrote:
> > >>>>
> > >>>>         
> > >>>>> OK, I couldn't help myself and went ahead and tested it. It seems
> > >>>>> fine, so please test my tree:
> > >>>>>
> > >>>>> http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-saa7134
> > >>>>>
> > >>>>> Let me know if it works.
> > >>>>>
> > >>>>>           
> > >>>> Hi Hans,
> > >>>>
> > >>>> It didn't work.  No analog reception on either RF input.  (as Mauro
> > >>>> noted, DVB is unaffected; it still works).
> > >>>>
> > >>>> dmesg output looks right:
> > >>>>
> > >>>> tuner-simple 1-0061: creating new instance
> > >>>> tuner-simple 1-0061: type set to 68 (Philips TUV1236D ATSC/NTSC dual
> > >>>> in)
> > >>>>
> > >>>> I tried backing out of the modules and then reloading them, but no
> > >>>> change.  (including after fresh build or after rebooting)
> > >>>>
> > >>>>         
> > >>> Can you give the full dmesg output? Also, is your board suppossed to
> > >>> have a tda9887 as well?
> > >>>
> > >>>       
> > >> Hans' changes are not enough to fix the ATSC115 issue.
> > >>     
> > >
> > > Ah, OK.
> > >
> > >   
> > >> I believe that if you can confirm that the same problem exists, but the
> > >> previous workaround continues to work even after Hans' changes, then I
> > >> believe that confirms that Hans' changes Do the Right Thing (tm).
> > >>
> > >> ATSC115 is broken not because the tuner type assignment has been removed
> > >> from attach_inform.
> > >>
> > >> This is actually a huge problem across all analog drivers now, since we
> > >> are no longer able to remove the "tuner" module and modprobe it again --
> > >> the second modprobe will not allow for an attach, as there will be no
> > >> way for the module to be recognized without having the glue code needed
> > >> inside attach_inform...
> > >>     
> > >
> > > Huh? Why would you want to rmmod and modprobe tuner? Anyway, drivers that
> > > use v4l2_subdev (like my converted saa7134) will increase the tuner module
> > > usecount, preventing it from being rmmod'ed.
> > 
> > There was a load order dependency in the saa7134 driver.  Some users 
> > have to remove tuner and modprobe it again in order to make analog tv 
> > work.  Yes, that's a bug.
> > 
> > The bug got worse when Mauro made changes to attach_inform -- I believe 
> > this was for the sake of some xceive tuners... I don't recall the 
> > details now.
> > 
> > Anyway, long story short... there are many different bugs all 
> > manifesting themselves at once here.  Load order dependency -- I don't 
> > think we ever understood why that issue exists.  The fix for the load 
> > order dependency no longer works, as attach_inform no longer cares if a 
> > new tuner appears on the bus.
> 
> It has nothing to do with the load order. It is related to i2c binding. With
> the current approach (before Hans patch), the i2c core will try to bind the
> tuner after having 2 conditions satisfied:
> 	1) I2C bus were registered;
> 	2) tuner code is available.
> 
> So, if you load tuner before saa7134 (or have it compiled in-kernel), the code
> will try to probe tuners at the moment you register i2c bus. Otherwise, it will
> try to bind only when request_module is handled.
> 
> Some devices with DVB has an internal i2c gate. For a subset of these, the i2c
> gate is inside the tuner. So, you need to bind the tuner device before probing
> for the frontends. On the other set of devices, the gate is inside the demod.
> So, you need to turn the i2c gate before running the i2c address seek for tuner.
> 
> This generated lots of issues in the past, like machines with two boards
> doesn't work anymore. With two boards, and a tuner module, the first board
> probes tuner after opening the demod gateway. However, the second board will
> try to probe tuner before opening the i2c gateway. So, tuner is not found.
> 
> -
> 
> After having Hans patches working, we need to implement the following workflow
> inside the driver:
> 
> 1) register the i2c bus and load tuner (the order shouldn't be relevant
> anymore, since the attachment is not related anymore with i2c bus register and/or
> with tuner load);
> 2) call the i2c open gate control, if it needs to open the demod i2c gate in
> order to access the tuner;
> 3) tuner type is determined via eeprom and/or board entry;
> 3) tuner i2c address is scanned and tuner is bound with the proper type;
> 4) the i2c open gate control is called, if needed in order to access the demod;
> 5) demod is bound.
> 
> > So, my ATSC115 hack-patch restored the attach_inform functionality for 
> > the sake of ATSC110/115 users.  I am not pushing for its merge -- this 
> > *will* break the boards that Mauro was working on when he changed 
> > attach_inform.
> >
> > As I don't really understand what he was going for when he made those 
> > changes, I don't know how to fix this problem without creating new bugs 
> > on Mauro's cards.  I put out that patch in hopes that somebody else 
> > would put the pieces together and make a better fix that would work for 
> > everybody.  That hasn't happened yet :-(
> 
> Hacks won't be needed anymore.
> 
> All we need is to fix the board entries, properly identifying what is needed to
> access tuner and/or demod, and double check what devices need tda9887.
> 
> Cheers,
> Mauro

What I see on the md7134 card=12 (about ten different devices) is not
related to missing has tda9887 something, especially not on the FMD216ME
MK3 hybrid. The tda9887 becomes only visible there at all with that
special buffer sent from tuner-core. (0x05 IIRC)

To have the tda9887 always in the kernel and never as module might fix
it. Untested ;)

Cheers,
Hermann

Re: KWorld ATSC 115 all static

[CityK]

Hans Verkuil wrote:

> is your board suppossed to have a tda9887 as well?

Hi Hans,

Yes, indeed, the device does contain the tda9887.


>> Hans' changes are not enough to fix the ATSC115 issue.
>>     
>
> Ah, OK.
>
>   
>> I believe that if you can confirm that the same problem exists, but the
>> previous workaround continues to work even after Hans' changes, then I
>> believe that confirms that Hans' changes Do the Right Thing (tm).
>>     

err, I'm afraid I might be reading to much into your statement Michael
--- if you meant to question whether, after building Hans' changes, a
"modprobe tuner -r" and "modprobe tuner " worked, then the answer is no,
such did not work. (no results in dmesg are observed either, much like
what was discussed later; specifically:

>  we are no longer able to remove the "tuner" module and modprobe it again --
> the second modprobe will not allow for an attach, as there will be no
> way for the module to be recognized 
>   

If you had meant taking Hans' source and applying your "hack" patch to
them, building and then proceeding with the modprobe steps, the answer
is that I haven't tried yet. Will test -- might not be tonight though,
as I have some other things that need attending too.

> Anyway, if the previous workaround works after Hans' changes, then I
> think his changes should be merged -- even though it doesnt fix ATSC115,
> it is indeed a step into the right direction.
>
> If the ATSC115 hack-fix patch doesn't apply anymore, please let me know
> -- I'll respin it.

Given this statement, then perhaps it was a case of the latter. As
mentioned, I will rebuild and test.

Hans, given the discussion that is developed, I don't think the dmesg
output is necessary at this point (if you really insist though I will
provide :P ).

P.S. I think Trent's idea sounds interesting/warrants some consideration.

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: KWorld ATSC 115 all static

[CityK]

CityK wrote:
> If you had meant taking Hans' source and applying your "hack" patch to
> them, building and then proceeding with the modprobe steps, the answer
> is that I haven't tried yet. Will test -- might not be tonight though,
> as I have some other things that need attending too.
>   

Okay, I lied -- given that building is really a background process, I
found time ... i.e. I cleaned up in the kitchen while the system
compiled ... kneel before me world, as I am a master multi-tasker!

>> Anyway, if the previous workaround works after Hans' changes, then I
>> think his changes should be merged -- even though it doesnt fix ATSC115,
>> it is indeed a step into the right direction.
>>
>> If the ATSC115 hack-fix patch doesn't apply anymore, please let me know
>> -- I'll respin it.
>>     

The "hack-fix" patch applies cleanly against Hans' sources. However, the
test results are negative -- the previous workaround ("modprobe tuner -r
and "modprobe tuner") fails to produce the desired result. In fact, as
similar to the results reported in the previous message, performing such
action produces no result in dmesg.

Re: KWorld ATSC 115 all static

[Mauro Carvalho Chehab]

On Thu, 15 Jan 2009 22:20:02 -0500
CityK <cityk@rogers.com> wrote:

> CityK wrote:
> > If you had meant taking Hans' source and applying your "hack" patch to
> > them, building and then proceeding with the modprobe steps, the answer
> > is that I haven't tried yet. Will test -- might not be tonight though,
> > as I have some other things that need attending too.
> >   
> 
> Okay, I lied -- given that building is really a background process, I
> found time ... i.e. I cleaned up in the kitchen while the system
> compiled ... kneel before me world, as I am a master multi-tasker!
> 
> >> Anyway, if the previous workaround works after Hans' changes, then I
> >> think his changes should be merged -- even though it doesnt fix ATSC115,
> >> it is indeed a step into the right direction.
> >>
> >> If the ATSC115 hack-fix patch doesn't apply anymore, please let me know
> >> -- I'll respin it.
> >>     
> 
> The "hack-fix" patch applies cleanly against Hans' sources. However, the
> test results are negative -- the previous workaround ("modprobe tuner -r
> and "modprobe tuner") fails to produce the desired result. In fact, as
> similar to the results reported in the previous message, performing such
> action produces no result in dmesg.

Such workarounds won't work anymore. If his patch is correct, the behaviour
should be deterministic. Could you please enable the debug messages and probe
cx88 with i2c_scan=1? Please also post the previous dmesg.

Cheers,
Mauro

Re: KWorld ATSC 115 all static

[Hans Verkuil]

On Friday 16 January 2009 04:20:02 CityK wrote:
> CityK wrote:
> > If you had meant taking Hans' source and applying your "hack" patch
> > to them, building and then proceeding with the modprobe steps, the
> > answer is that I haven't tried yet. Will test -- might not be
> > tonight though, as I have some other things that need attending
> > too.
>
> Okay, I lied -- given that building is really a background process, I
> found time ... i.e. I cleaned up in the kitchen while the system
> compiled ... kneel before me world, as I am a master multi-tasker!
>
> >> Anyway, if the previous workaround works after Hans' changes, then
> >> I think his changes should be merged -- even though it doesnt fix
> >> ATSC115, it is indeed a step into the right direction.
> >>
> >> If the ATSC115 hack-fix patch doesn't apply anymore, please let me
> >> know -- I'll respin it.
>
> The "hack-fix" patch applies cleanly against Hans' sources. However,
> the test results are negative -- the previous workaround ("modprobe
> tuner -r and "modprobe tuner") fails to produce the desired result.

If you try to run 'modprobe -r tuner' when the saa7134 module build from 
my sources is loaded, then that should not work since saa7134 increases 
the use-count of the tuner module preventing it from being unloaded.

If you can do this, then that suggests that you are perhaps not using my 
modified driver at all.

BTW, I've asked Mauro to pull from my tree 
(www.linuxtv.org/hg/~hverkuil/v4l-dvb) which contains the converted 
saa7134 and saa6752hs drivers. It's definitely something that needs to 
be done regardless.

Regards,

	Hans

> In fact, as similar to the results reported in the previous message,
> performing such action produces no result in dmesg.



-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

Re: KWorld ATSC 115 all static

[hermann pitton]

Hi,

Am Samstag, den 17.01.2009, 17:20 +0100 schrieb Hans Verkuil:
> On Friday 16 January 2009 04:20:02 CityK wrote:
> > CityK wrote:
> > > If you had meant taking Hans' source and applying your "hack" patch
> > > to them, building and then proceeding with the modprobe steps, the
> > > answer is that I haven't tried yet. Will test -- might not be
> > > tonight though, as I have some other things that need attending
> > > too.
> >
> > Okay, I lied -- given that building is really a background process, I
> > found time ... i.e. I cleaned up in the kitchen while the system
> > compiled ... kneel before me world, as I am a master multi-tasker!
> >
> > >> Anyway, if the previous workaround works after Hans' changes, then
> > >> I think his changes should be merged -- even though it doesnt fix
> > >> ATSC115, it is indeed a step into the right direction.
> > >>
> > >> If the ATSC115 hack-fix patch doesn't apply anymore, please let me
> > >> know -- I'll respin it.
> >
> > The "hack-fix" patch applies cleanly against Hans' sources. However,
> > the test results are negative -- the previous workaround ("modprobe
> > tuner -r and "modprobe tuner") fails to produce the desired result.
> 
> If you try to run 'modprobe -r tuner' when the saa7134 module build from 
> my sources is loaded, then that should not work since saa7134 increases 
> the use-count of the tuner module preventing it from being unloaded.
> 
> If you can do this, then that suggests that you are perhaps not using my 
> modified driver at all.
> 
> BTW, I've asked Mauro to pull from my tree 
> (www.linuxtv.org/hg/~hverkuil/v4l-dvb) which contains the converted 
> saa7134 and saa6752hs drivers. It's definitely something that needs to 
> be done regardless.

Hans, Mauro has pulled them in already.

For my report for the old issue with the tda9987 not loaded for the
md7134 card=12 with eeprom tuner detection and all the types with
FMD1216ME MK3 hybrid subsumed there beside the older ones with analog
only tuners (CTX917/918/925triple/946mpeg/921cardbus), the users must
just unload the saa7134 and tuner modules and then load tda9887 and
tuner before the saa7134 for now.

> Regards,
> 
> 	Hans
> 
> > In fact, as similar to the results reported in the previous message,
> > performing such action produces no result in dmesg.
> 

Cheers,
Hermann

Re: KWorld ATSC 115 all static

[Michael Krufky]

hermann pitton wrote:
> Hi,
>
> Am Samstag, den 17.01.2009, 17:20 +0100 schrieb Hans Verkuil:
>   
>> On Friday 16 January 2009 04:20:02 CityK wrote:
>>     
>>> CityK wrote:
>>>       
>>>> If you had meant taking Hans' source and applying your "hack" patch
>>>> to them, building and then proceeding with the modprobe steps, the
>>>> answer is that I haven't tried yet. Will test -- might not be
>>>> tonight though, as I have some other things that need attending
>>>> too.
>>>>         
>>> Okay, I lied -- given that building is really a background process, I
>>> found time ... i.e. I cleaned up in the kitchen while the system
>>> compiled ... kneel before me world, as I am a master multi-tasker!
>>>
>>>       
>>>>> Anyway, if the previous workaround works after Hans' changes, then
>>>>> I think his changes should be merged -- even though it doesnt fix
>>>>> ATSC115, it is indeed a step into the right direction.
>>>>>
>>>>> If the ATSC115 hack-fix patch doesn't apply anymore, please let me
>>>>> know -- I'll respin it.
>>>>>           
>>> The "hack-fix" patch applies cleanly against Hans' sources. However,
>>> the test results are negative -- the previous workaround ("modprobe
>>> tuner -r and "modprobe tuner") fails to produce the desired result.
>>>       
>> If you try to run 'modprobe -r tuner' when the saa7134 module build from 
>> my sources is loaded, then that should not work since saa7134 increases 
>> the use-count of the tuner module preventing it from being unloaded.
>>
>> If you can do this, then that suggests that you are perhaps not using my 
>> modified driver at all.
>>
>> BTW, I've asked Mauro to pull from my tree 
>> (www.linuxtv.org/hg/~hverkuil/v4l-dvb) which contains the converted 
>> saa7134 and saa6752hs drivers. It's definitely something that needs to 
>> be done regardless.
>>     
>
> Hans, Mauro has pulled them in already.
>
> For my report for the old issue with the tda9987 not loaded for the
> md7134 card=12 with eeprom tuner detection and all the types with
> FMD1216ME MK3 hybrid subsumed there beside the older ones with analog
> only tuners (CTX917/918/925triple/946mpeg/921cardbus), the users must
> just unload the saa7134 and tuner modules and then load tda9887 and
> tuner before the saa7134 for now.

That's not possible -- tda9887 is now a sub-module of tuner-core.  
tda9887, when modprobed alone, will not attach to any actual device 
without also having tuner.ko loaded in memory.  tda9887 is a separate 
module, but its interface is currently only accessed via tuner-core 
(tuner.ko)

-Mike

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: KWorld ATSC 115 all static

[hermann pitton]

Am Samstag, den 17.01.2009, 13:44 -0500 schrieb Michael Krufky:
> hermann pitton wrote:
> > Hi,
> >
> > Am Samstag, den 17.01.2009, 17:20 +0100 schrieb Hans Verkuil:
> >   
> >> On Friday 16 January 2009 04:20:02 CityK wrote:
> >>     
> >>> CityK wrote:
> >>>       
> >>>> If you had meant taking Hans' source and applying your "hack" patch
> >>>> to them, building and then proceeding with the modprobe steps, the
> >>>> answer is that I haven't tried yet. Will test -- might not be
> >>>> tonight though, as I have some other things that need attending
> >>>> too.
> >>>>         
> >>> Okay, I lied -- given that building is really a background process, I
> >>> found time ... i.e. I cleaned up in the kitchen while the system
> >>> compiled ... kneel before me world, as I am a master multi-tasker!
> >>>
> >>>       
> >>>>> Anyway, if the previous workaround works after Hans' changes, then
> >>>>> I think his changes should be merged -- even though it doesnt fix
> >>>>> ATSC115, it is indeed a step into the right direction.
> >>>>>
> >>>>> If the ATSC115 hack-fix patch doesn't apply anymore, please let me
> >>>>> know -- I'll respin it.
> >>>>>           
> >>> The "hack-fix" patch applies cleanly against Hans' sources. However,
> >>> the test results are negative -- the previous workaround ("modprobe
> >>> tuner -r and "modprobe tuner") fails to produce the desired result.
> >>>       
> >> If you try to run 'modprobe -r tuner' when the saa7134 module build from 
> >> my sources is loaded, then that should not work since saa7134 increases 
> >> the use-count of the tuner module preventing it from being unloaded.
> >>
> >> If you can do this, then that suggests that you are perhaps not using my 
> >> modified driver at all.
> >>
> >> BTW, I've asked Mauro to pull from my tree 
> >> (www.linuxtv.org/hg/~hverkuil/v4l-dvb) which contains the converted 
> >> saa7134 and saa6752hs drivers. It's definitely something that needs to 
> >> be done regardless.
> >>     
> >
> > Hans, Mauro has pulled them in already.
> >
> > For my report for the old issue with the tda9987 not loaded for the
> > md7134 card=12 with eeprom tuner detection and all the types with
> > FMD1216ME MK3 hybrid subsumed there beside the older ones with analog
> > only tuners (CTX917/918/925triple/946mpeg/921cardbus), the users must
> > just unload the saa7134 and tuner modules and then load tda9887 and
> > tuner before the saa7134 for now.
> 
> That's not possible -- tda9887 is now a sub-module of tuner-core.  
> tda9887, when modprobed alone, will not attach to any actual device 
> without also having tuner.ko loaded in memory.  tda9887 is a separate 
> module, but its interface is currently only accessed via tuner-core 
> (tuner.ko)
> 
> -Mike

Mike, please look.

You can see that the previously not loaded tda9887 is present and
initialized now.

Cheers,
Hermann

[root@pc10 ~]# modprobe -vr saa7134-dvb
rmmod /lib/modules/2.6.26.6-49.fc8/kernel/drivers/media/video/saa7134/saa7134-dvb.ko
rmmod /lib/modules/2.6.26.6-49.fc8/kernel/drivers/media/video/videobuf-dvb.ko
rmmod /lib/modules/2.6.26.6-49.fc8/kernel/drivers/media/dvb/dvb-core/dvb-core.ko
rmmod /lib/modules/2.6.26.6-49.fc8/kernel/drivers/media/video/saa7134/saa7134.ko
rmmod /lib/modules/2.6.26.6-49.fc8/kernel/drivers/media/common/ir-common.ko
rmmod /lib/modules/2.6.26.6-49.fc8/kernel/drivers/media/video/tveeprom.ko
rmmod /lib/modules/2.6.26.6-49.fc8/kernel/drivers/media/video/videobuf-dma-sg.ko
rmmod /lib/modules/2.6.26.6-49.fc8/kernel/drivers/media/video/videobuf-core.ko
[root@pc10 ~]# modprobe -vr tda9887 tuner tuner-simple
rmmod /lib/modules/2.6.26.6-49.fc8/kernel/drivers/media/video/tuner.ko
rmmod /lib/modules/2.6.26.6-49.fc8/kernel/drivers/media/video/v4l2-common.ko
rmmod /lib/modules/2.6.26.6-49.fc8/kernel/drivers/media/video/videodev.ko
rmmod /lib/modules/2.6.26.6-49.fc8/kernel/drivers/media/video/v4l1-compat.ko
rmmod /lib/modules/2.6.26.6-49.fc8/kernel/drivers/media/common/tuners/tuner-simple.ko
rmmod /lib/modules/2.6.26.6-49.fc8/kernel/drivers/media/common/tuners/tuner-types.ko
[root@pc10 ~]# modprobe -v tda9887
insmod /lib/modules/2.6.26.6-49.fc8/kernel/drivers/media/common/tuners/tda9887.ko
[root@pc10 ~]# modprobe -v tuner
insmod /lib/modules/2.6.26.6-49.fc8/kernel/drivers/media/video/v4l1-compat.ko
insmod /lib/modules/2.6.26.6-49.fc8/kernel/drivers/media/video/videodev.ko
insmod /lib/modules/2.6.26.6-49.fc8/kernel/drivers/media/video/v4l2-common.ko
insmod /lib/modules/2.6.26.6-49.fc8/kernel/drivers/media/video/tuner.ko
[root@pc10 ~]# modprobe -v saa7134
insmod /lib/modules/2.6.26.6-49.fc8/kernel/drivers/media/video/tveeprom.ko
insmod /lib/modules/2.6.26.6-49.fc8/kernel/drivers/media/video/videobuf-core.ko
insmod /lib/modules/2.6.26.6-49.fc8/kernel/drivers/media/video/videobuf-dma-sg.ko
insmod /lib/modules/2.6.26.6-49.fc8/kernel/drivers/media/common/ir-common.ko
insmod /lib/modules/2.6.26.6-49.fc8/kernel/drivers/media/video/saa7134/saa7134.ko latency=64 gbuffers=32
[root@pc10 ~]# dmesg
Initializing cgroup subsys cpuset
Linux version 2.6.26.6-49.fc8 (mockbuild@x86-2.fedora.phx.redhat.com) (gcc version 4.1.2 20070925 (Red Hat 4.1.2-33)) #1 SMP Fri Oct 17 15:59:36 EDT 2008
PAT disabled. Not yet verified on this CPU type.
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000003fff0000 (usable)
 BIOS-e820: 000000003fff0000 - 000000003fff3000 (ACPI NVS)
 BIOS-e820: 000000003fff3000 - 0000000040000000 (ACPI data)
 BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
 BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
 BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
127MB HIGHMEM available.
896MB LOWMEM available.
Using x86 segment limits to approximate NX protection
Entering add_active_range(0, 0, 262128) 0 entries of 256 used
Zone PFN ranges:
  DMA             0 ->     4096
  Normal       4096 ->   229376
  HighMem    229376 ->   262128
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
    0:        0 ->   262128
On node 0 totalpages: 262128
  DMA zone: 32 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 4064 pages, LIFO batch:0
  Normal zone: 1760 pages used for memmap
  Normal zone: 223520 pages, LIFO batch:31
  HighMem zone: 256 pages used for memmap
  HighMem zone: 32496 pages, LIFO batch:7
  Movable zone: 0 pages used for memmap
DMI 2.2 present.
Using APIC driver default
ACPI: RSDP 000F6D60, 0014 (r0 Nvidia)
ACPI: RSDT 3FFF3000, 002C (r1 Nvidia AWRDACPI 42302E31 AWRD        0)
ACPI: FACP 3FFF3040, 0074 (r1 Nvidia AWRDACPI 42302E31 AWRD        0)
ACPI: DSDT 3FFF30C0, 43F8 (r1 NVIDIA AWRDACPI     1000 MSFT  100000E)
ACPI: FACS 3FFF0000, 0040
ACPI: APIC 3FFF74C0, 005A (r1 Nvidia AWRDACPI 42302E31 AWRD        0)
Nvidia board detected. Ignoring ACPI timer override.
If you got timer trouble try acpi_use_timer_override
ACPI: PM-Timer IO Port: 0x4008
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 2, version 17, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: BIOS IRQ0 pin2 override ignored.
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: IRQ9 used by override.
Enabling APIC mode:  Flat.  Using 1 I/O APICs
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 50000000 (gap: 40000000:bec00000)
PM: Registered nosave memory: 000000000009f000 - 00000000000a0000
PM: Registered nosave memory: 00000000000a0000 - 00000000000f0000
PM: Registered nosave memory: 00000000000f0000 - 0000000000100000
SMP: Allowing 1 CPUs, 0 hotplug CPUs
PERCPU: Allocating 41384 bytes of per cpu data
NR_CPUS: 32, nr_cpu_ids: 1
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 260080
Kernel command line: ro root=LABEL=/ selinux=0
mapped APIC to ffffb000 (fee00000)
mapped IOAPIC to ffffa000 (fec00000)
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
CPU 0 irqstacks, hard=c07cb000 soft=c07ab000
PID hash table entries: 4096 (order: 12, 16384 bytes)
Detected 1829.999 MHz processor.
Console: colour VGA+ 80x25
console [tty0] enabled
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 1031092k/1048512k available (2254k kernel code, 16680k reserved, 1180k data, 284k init, 131008k highmem)
virtual kernel memory layout:
    fixmap  : 0xffc53000 - 0xfffff000   (3760 kB)
    pkmap   : 0xff400000 - 0xff800000   (4096 kB)
    vmalloc : 0xf8800000 - 0xff3fe000   ( 107 MB)
    lowmem  : 0xc0000000 - 0xf8000000   ( 896 MB)
      .init : 0xc0761000 - 0xc07a8000   ( 284 kB)
      .data : 0xc0633847 - 0xc075ab88   (1180 kB)
      .text : 0xc0400000 - 0xc0633847   (2254 kB)
Checking if this processor honours the WP bit even in supervisor mode...Ok.
CPA: page pool initialized 1 of 1 pages preallocated
SLUB: Genslabs=12, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
Calibrating delay using timer specific routine.. 3662.17 BogoMIPS (lpj=1831089)
Security Framework initialized
SELinux:  Disabled at boot.
Capability LSM initialized
Mount-cache hash table entries: 512
Initializing cgroup subsys ns
Initializing cgroup subsys cpuacct
Initializing cgroup subsys devices
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 512K (64 bytes/line)
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
Checking 'hlt' instruction... OK.
SMP alternatives: switching to UP code
Freeing SMP alternatives: 19k freed
ACPI: Core revision 20080321
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 apic1=0 pin1=0 apic2=-1 pin2=-1
CPU0: AMD Athlon(tm) XP 2500+ stepping 00
APIC calibration not consistent with PM Timer: 98ms instead of 100ms
APIC delta adjusted to PM-Timer: 2079547 (2058441)
Brought up 1 CPUs
Total of 1 processors activated (3662.17 BogoMIPS).
sizeof(vma)=84 bytes
sizeof(page)=32 bytes
sizeof(inode)=340 bytes
sizeof(dentry)=132 bytes
sizeof(ext3inode)=492 bytes
sizeof(buffer_head)=56 bytes
sizeof(skbuff)=180 bytes
sizeof(task_struct)=3188 bytes
CPU0 attaching sched-domain:
 domain 0: span 0
  groups: 0
net_namespace: 660 bytes
Booting paravirtualized kernel on bare hardware
Time: 12:32:54  Date: 01/17/09
NET: Registered protocol family 16
No dock devices found.
ACPI: bus type pci registered
PCI: PCI BIOS revision 2.10 entry at 0xfb4a0, last bus=3
PCI: Using configuration type 1 for base access
Setting up standard PCI resources
ACPI: EC: Look up EC in DSDT
ACPI: Interpreter enabled
ACPI: (supports S0 S1 S3 S4 S5)
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
pci 0000:00:00.0: nForce2 C1 Halt Disconnect fixup
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.HUB0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.AGPB._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.HUB1._PRT]
ACPI: PCI Interrupt Link [LNK1] (IRQs 3 *4 5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNK2] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNK3] (IRQs 3 4 5 6 7 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNK4] (IRQs 3 4 5 6 7 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNK5] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LUBA] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LUBB] (IRQs *3 4 5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LMAC] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LAPU] (IRQs *3 4 5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LACI] (IRQs 3 4 *5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LMCI] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LSMB] (IRQs 3 *4 5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LUB2] (IRQs 3 4 *5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LFIR] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [L3CM] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LIDE] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [APC1] (IRQs *16)
ACPI: PCI Interrupt Link [APC2] (IRQs *17)
ACPI: PCI Interrupt Link [APC3] (IRQs *18)
ACPI: PCI Interrupt Link [APC4] (IRQs *19)
ACPI: PCI Interrupt Link [APC5] (IRQs *16), disabled.
ACPI: PCI Interrupt Link [APCF] (IRQs 20 21 22) *0
ACPI: PCI Interrupt Link [APCG] (IRQs 20 21 22) *0
ACPI: PCI Interrupt Link [APCH] (IRQs 20 21 22) *0, disabled.
ACPI: PCI Interrupt Link [APCI] (IRQs 20 21 22) *0
ACPI: PCI Interrupt Link [APCJ] (IRQs 20 21 22) *0
ACPI: PCI Interrupt Link [APCK] (IRQs 20 21 22) *0, disabled.
ACPI: PCI Interrupt Link [APCS] (IRQs *23)
ACPI: PCI Interrupt Link [APCL] (IRQs 20 21 22) *0
ACPI: PCI Interrupt Link [APCM] (IRQs 20 21 22) *0, disabled.
ACPI: PCI Interrupt Link [AP3C] (IRQs 20 21 22) *0
ACPI: PCI Interrupt Link [APCZ] (IRQs 20 21 22) *0, disabled.
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
ACPI: bus type pnp registered
pnp: PnP ACPI: found 13 devices
ACPI: ACPI bus type pnp unregistered
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
PCI: Using ACPI for IRQ routing
NetLabel: Initializing
NetLabel:  domain hash size = 128
NetLabel:  protocols = UNLABELED CIPSOv4
NetLabel:  unlabeled traffic allowed by default
system 00:00: ioport range 0x4000-0x407f has been reserved
system 00:00: ioport range 0x4080-0x40ff has been reserved
system 00:00: ioport range 0x4400-0x447f has been reserved
system 00:00: ioport range 0x4480-0x44ff has been reserved
system 00:00: ioport range 0x4200-0x427f has been reserved
system 00:00: ioport range 0x4280-0x42ff has been reserved
system 00:01: ioport range 0x5000-0x503f has been reserved
system 00:01: ioport range 0x5500-0x553f has been reserved
system 00:02: iomem range 0xd0800-0xd3fff has been reserved
system 00:02: iomem range 0xf0000-0xf7fff could not be reserved
system 00:02: iomem range 0xf8000-0xfbfff could not be reserved
system 00:02: iomem range 0xfc000-0xfffff could not be reserved
system 00:02: iomem range 0x3fff0000-0x3fffffff could not be reserved
system 00:02: iomem range 0xffff0000-0xffffffff could not be reserved
system 00:02: iomem range 0x0-0x9ffff could not be reserved
system 00:02: iomem range 0x100000-0x3ffeffff could not be reserved
system 00:02: iomem range 0xfec00000-0xfec00fff could not be reserved
system 00:02: iomem range 0xfee00000-0xfee00fff could not be reserved
system 00:04: ioport range 0x4d0-0x4d1 has been reserved
PCI: Bridge: 0000:00:08.0
  IO window: disabled.
  MEM window: 0xe8000000-0xe8ffffff
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:0c.0
  IO window: d000-dfff
  MEM window: 0xe4000000-0xe5ffffff
  PREFETCH window: 0x0000000050000000-0x00000000500fffff
PCI: Bridge: 0000:00:1e.0
  IO window: disabled.
  MEM window: 0xe6000000-0xe7ffffff
  PREFETCH window: 0x00000000d0000000-0x00000000dfffffff
PCI: Setting latency timer of device 0000:00:08.0 to 64
PCI: Setting latency timer of device 0000:00:0c.0 to 64
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
TCP bind hash table entries: 65536 (order: 7, 524288 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno registered
NET: Registered protocol family 1
checking if image is initramfs... it is
Freeing initrd memory: 2988k freed
apm: BIOS version 1.2 Flags 0x07 (Driver version 1.16ac)
apm: overridden by ACPI.
audit: initializing netlink socket (disabled)
type=2000 audit(1232195573.539:1): initialized
highmem bounce pool size: 64 pages
Total HugeTLB memory allocated, 0
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
msgmni has been set to 1764
ksign: Installing public key data
Loading keyring
- Added public key 942ED0CAD7D49A2
- User ID: Red Hat, Inc. (Kernel Module GPG key)
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
pci 0000:03:00.0: Boot video device
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
input: Power Button (FF) as /class/input/input0
ACPI: Power Button (FF) [PWRF]
input: Power Button (CM) as /class/input/input1
ACPI: Power Button (CM) [PWRB]
ACPI: ACPI0007:00 is registered as cooling_device0
isapnp: Scanning for PnP cards...
Switched to high resolution mode on CPU 0
isapnp: No Plug & Play device found
Real Time Clock Driver v1.12ac
Non-volatile memory driver v1.2
Linux agpgart interface v0.103
agpgart: Detected NVIDIA nForce2 chipset
agpgart: AGP aperture is 64M @ 0xe0000000
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
brd: module loaded
input: Macintosh mouse button emulation as /class/input/input2
PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
mice: PS/2 mouse device common for all mice
cpuidle: using governor ladder
cpuidle: using governor menu
usbcore: registered new interface driver hiddev
usbcore: registered new interface driver usbhid
usbhid: v2.6:USB HID core driver
TCP cubic registered
Initializing XFRM netlink socket
NET: Registered protocol family 17
Using IPI No-Shortcut mode
registered taskstats version 1
  Magic number: 9:993:531
Freeing unused kernel memory: 284k freed
Write protecting the kernel text: 2256k
Write protecting the kernel read-only data: 960k
input: AT Translated Set 2 keyboard as /class/input/input3
ACPI: PCI Interrupt Link [APCL] enabled at IRQ 22
ACPI: PCI Interrupt 0000:00:02.2[C] -> Link [APCL] -> GSI 22 (level, high) -> IRQ 22
PCI: Setting latency timer of device 0000:00:02.2 to 64
ehci_hcd 0000:00:02.2: EHCI Host Controller
ehci_hcd 0000:00:02.2: new USB bus registered, assigned bus number 1
ehci_hcd 0000:00:02.2: selective suspend/wakeup unavailable
ehci_hcd 0000:00:02.2: debug port 1
PCI: cache line size of 64 is not supported by device 0000:00:02.2
ehci_hcd 0000:00:02.2: irq 22, io mem 0xe9081000
ehci_hcd 0000:00:02.2: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 6 ports detected
usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: EHCI Host Controller
usb usb1: Manufacturer: Linux 2.6.26.6-49.fc8 ehci_hcd
usb usb1: SerialNumber: 0000:00:02.2
ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver
ACPI: PCI Interrupt Link [APCF] enabled at IRQ 21
ACPI: PCI Interrupt 0000:00:02.0[A] -> Link [APCF] -> GSI 21 (level, high) -> IRQ 21
PCI: Setting latency timer of device 0000:00:02.0 to 64
ohci_hcd 0000:00:02.0: OHCI Host Controller
ohci_hcd 0000:00:02.0: new USB bus registered, assigned bus number 2
ohci_hcd 0000:00:02.0: irq 21, io mem 0xe9082000
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 3 ports detected
usb usb2: New USB device found, idVendor=1d6b, idProduct=0001
usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb2: Product: OHCI Host Controller
usb usb2: Manufacturer: Linux 2.6.26.6-49.fc8 ohci_hcd
usb usb2: SerialNumber: 0000:00:02.0
ACPI: PCI Interrupt Link [APCG] enabled at IRQ 20
ACPI: PCI Interrupt 0000:00:02.1[B] -> Link [APCG] -> GSI 20 (level, high) -> IRQ 20
PCI: Setting latency timer of device 0000:00:02.1 to 64
ohci_hcd 0000:00:02.1: OHCI Host Controller
ohci_hcd 0000:00:02.1: new USB bus registered, assigned bus number 3
ohci_hcd 0000:00:02.1: irq 20, io mem 0xe9080000
usb usb3: configuration #1 chosen from 1 choice
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 3 ports detected
usb usb3: New USB device found, idVendor=1d6b, idProduct=0001
usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb3: Product: OHCI Host Controller
usb usb3: Manufacturer: Linux 2.6.26.6-49.fc8 ohci_hcd
usb usb3: SerialNumber: 0000:00:02.1
USB Universal Host Controller Interface driver v3.0
input: PS/2 Generic Mouse as /class/input/input4
SCSI subsystem initialized
Driver 'sd' needs updating - please use bus_type methods
libata version 3.00 loaded.
pata_amd 0000:00:09.0: version 0.3.10
PCI: Setting latency timer of device 0000:00:09.0 to 64
scsi0 : pata_amd
scsi1 : pata_amd
ata1: PATA max UDMA/133 cmd 0x1f0 ctl 0x3f6 bmdma 0xf000 irq 14
ata2: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xf008 irq 15
ata1.00: ATA-7: SAMSUNG SP1614N, TM100-24, max UDMA/100
ata1.00: 312581808 sectors, multi 16: LBA48
ata1: nv_mode_filter: 0x3f39f&0x3f01f->0x3f01f, BIOS=0x3f000 (0xc600c000) ACPI=0x3f01f (20:600:0x13)
ata1.00: configured for UDMA/100
ata2.00: ATAPI: AOPEN   16XDVD-ROM/AMH      20021219, R17, max UDMA/33
ata2: nv_mode_filter: 0x739f&0x701f->0x701f, BIOS=0x7000 (0xc600c000) ACPI=0x701f (60:600:0x13)
ata2.00: configured for UDMA/33
scsi 0:0:0:0: Direct-Access     ATA      SAMSUNG SP1614N  TM10 PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 312581808 512-byte hardware sectors (160042 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 0:0:0:0: [sda] 312581808 512-byte hardware sectors (160042 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
 sda: sda1 sda2 < sda5 sda6 sda7 sda8 > sda3 sda4
sd 0:0:0:0: [sda] Attached SCSI disk
scsi 1:0:0:0: CD-ROM            AOPEN    16XDVD-ROM/AMH   R17  PQ: 0 ANSI: 5
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
sd 0:0:0:0: Attached scsi generic sg0 type 0
scsi 1:0:0:0: Attached scsi generic sg1 type 5
Driver 'sr' needs updating - please use bus_type methods
sr0: scsi3-mmc drive: 16x/48x cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.20
sr 1:0:0:0: Attached scsi CD-ROM sr0
i2c-adapter i2c-0: nForce2 SMBus adapter at 0x5000
i2c-adapter i2c-1: nForce2 SMBus adapter at 0x5500
input: PC Speaker as /class/input/input5
ACPI: PCI Interrupt Link [AP3C] enabled at IRQ 22
ACPI: PCI Interrupt 0000:02:01.0[A] -> Link [AP3C] -> GSI 22 (level, high) -> IRQ 22
3c59x: Donald Becker and others.
0000:02:01.0: 3Com PCI 3c920 Tornado at f88e8000.
Linux video capture interface: v2.00
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
nvidia: module license 'NVIDIA' taints kernel.
ACPI: PCI Interrupt Link [APC4] enabled at IRQ 19
ACPI: PCI Interrupt 0000:03:00.0[A] -> Link [APC4] -> GSI 19 (level, high) -> IRQ 19
NVRM: loading NVIDIA Linux x86 Kernel Module  96.43.09  Mon Oct 27 14:23:30 PST 2008
saa7130/34: v4l2 driver version 0.2.14 loaded
ACPI: PCI Interrupt 0000:01:07.0[A] -> Link [APC4] -> GSI 19 (level, high) -> IRQ 19
saa7134[0]: setting pci latency timer to 64
saa7134[0]: found at 0000:01:07.0, rev: 1, irq: 19, latency: 64, mmio: 0xe8000000
saa7134[0]: subsystem: 16be:0003, board: Medion 7134 [card=12,autodetected]
saa7134[0]: board init: gpio is 0
parport_pc 00:0a: reported by Plug and Play ACPI
parport0: PC-style at 0x378 (0x778), irq 7 [PCSPP,TRISTATE]
ACPI: PCI Interrupt Link [APCJ] enabled at IRQ 21
ACPI: PCI Interrupt 0000:00:06.0[A] -> Link [APCJ] -> GSI 21 (level, high) -> IRQ 21
PCI: Setting latency timer of device 0000:00:06.0 to 64
saa7134[0]: i2c eeprom 00: be 16 03 00 54 20 1c 00 43 43 a9 1c 55 d2 b2 92
saa7134[0]: i2c eeprom 10: 00 ff 86 0f ff 20 ff 00 01 50 32 79 01 3c ca 50
saa7134[0]: i2c eeprom 20: 01 40 01 02 02 03 01 00 06 ff 00 1f 02 51 96 2b
saa7134[0]: i2c eeprom 30: a7 58 7a 1f 03 8e 84 5e da 7a 04 b3 05 87 b2 3c
saa7134[0]: i2c eeprom 40: ff 1d 00 c2 86 10 01 01 00 00 fd 79 44 9f c2 8f
saa7134[0]: i2c eeprom 50: ff ff ff ff ff ff 06 06 0f 00 0f 00 0f 00 0f 00
saa7134[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7134[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7134[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7134[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7134[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7134[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7134[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7134[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7134[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7134[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
tuner 2-0061: chip found @ 0xc2 (saa7134[0])
saa7134[0] Board has DVB-T
saa7134[0] Tuner type is 63
tuner-simple 2-0061: creating new instance
tuner-simple 2-0061: type set to 63 (Philips FMD1216ME MK3 Hybrid Tuner)
saa7134[0]: registered device video0 [v4l2]
saa7134[0]: registered device vbi0
saa7134[0]: registered device radio0
ACPI: PCI Interrupt Link [APC3] enabled at IRQ 18
ACPI: PCI Interrupt 0000:01:08.0[A] -> Link [APC3] -> GSI 18 (level, high) -> IRQ 18
saa7133[1]: setting pci latency timer to 64
saa7133[1]: found at 0000:01:08.0, rev: 208, irq: 18, latency: 64, mmio: 0xe8001000
saa7133[1]: subsystem: 1043:4862, board: ASUSTeK P7131 Dual [card=78,autodetected]
saa7133[1]: board init: gpio is 0
input: saa7134 IR (ASUSTeK P7131 Dual) as /class/input/input6
intel8x0_measure_ac97_clock: measured 50744 usecs
intel8x0: clocking to 47449
saa7133[1]: i2c eeprom 00: 43 10 62 48 54 20 1c 00 43 43 a9 1c 55 d2 b2 92
saa7133[1]: i2c eeprom 10: 00 01 20 00 ff 20 ff ff ff ff ff ff ff ff ff ff
saa7133[1]: i2c eeprom 20: 01 40 01 02 03 01 01 03 08 ff 00 d6 ff ff ff ff
saa7133[1]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[1]: i2c eeprom 40: ff 21 00 c2 96 10 03 32 15 00 ff ff ff ff ff ff
saa7133[1]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[1]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[1]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[1]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[1]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[1]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[1]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[1]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[1]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[1]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[1]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
tuner 3-004b: chip found @ 0x96 (saa7133[1])
tda829x 3-004b: setting tuner address to 61
tda829x 3-004b: type set to tda8290+75a
saa7133[1]: registered device video1 [v4l2]
saa7133[1]: registered device vbi1
saa7133[1]: registered device radio1
ACPI: PCI Interrupt Link [APC2] enabled at IRQ 17
ACPI: PCI Interrupt 0000:01:09.0[A] -> Link [APC2] -> GSI 17 (level, high) -> IRQ 17
saa7133[2]: setting pci latency timer to 64
saa7133[2]: found at 0000:01:09.0, rev: 209, irq: 17, latency: 64, mmio: 0xe8002000
saa7133[2]: subsystem: 16be:0010, board: Medion/Creatix CTX953 Hybrid [card=134,autodetected]
saa7133[2]: board init: gpio is 0
saa7133[2]: i2c eeprom 00: be 16 10 00 54 20 1c 00 43 43 a9 1c 55 d2 b2 92
saa7133[2]: i2c eeprom 10: 00 ff 86 0f ff 20 ff 00 01 50 32 79 01 3c ca 50
saa7133[2]: i2c eeprom 20: 01 40 01 02 02 03 01 00 06 ff 00 2c 02 51 96 2b
saa7133[2]: i2c eeprom 30: a7 58 7a 1f 03 8e 84 5e da 7a 04 b3 05 87 b2 3c
saa7133[2]: i2c eeprom 40: ff 21 00 c0 96 10 03 22 15 00 fd 79 44 9f c2 8f
saa7133[2]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[2]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[2]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[2]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[2]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[2]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[2]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[2]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[2]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[2]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[2]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
tuner 4-004b: chip found @ 0x96 (saa7133[2])
tda829x 4-004b: setting tuner address to 60
tda829x 4-004b: type set to tda8290+75a
saa7133[2]: registered device video2 [v4l2]
saa7133[2]: registered device vbi2
ACPI: PCI Interrupt Link [APC1] enabled at IRQ 16
ACPI: PCI Interrupt 0000:01:0a.0[A] -> Link [APC1] -> GSI 16 (level, high) -> IRQ 16
saa7134[3]: setting pci latency timer to 64
saa7134[3]: found at 0000:01:0a.0, rev: 1, irq: 16, latency: 64, mmio: 0xe8003000
saa7134[3]: subsystem: 16be:5000, board: Medion 7134 [card=12,autodetected]
saa7134[3]: board init: gpio is 820000
saa7134[3]: i2c eeprom 00: be 16 00 50 54 20 1c 00 43 43 a9 1c 55 d2 b2 92
saa7134[3]: i2c eeprom 10: 00 ff 86 0f ff 20 ff 00 01 50 32 79 01 3c ca 50
saa7134[3]: i2c eeprom 20: 01 40 01 02 02 03 01 00 06 ff 00 6c 02 51 96 2b
saa7134[3]: i2c eeprom 30: a7 58 7a 1f 03 8e 84 5e da 7a 04 b3 05 87 b2 3c
saa7134[3]: i2c eeprom 40: ff 1d 00 c2 86 10 01 01 00 00 fd 79 44 9f c2 8f
saa7134[3]: i2c eeprom 50: ff ff ff ff ff ff 06 06 0f 00 0f 00 0f 00 0f 00
saa7134[3]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7134[3]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7134[3]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7134[3]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7134[3]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7134[3]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7134[3]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7134[3]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7134[3]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7134[3]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
tuner 5-0061: chip found @ 0xc2 (saa7134[3])
saa7134[3] Board has DVB-T
saa7134[3] Tuner type is 63
tuner-simple 5-0061: creating new instance
tuner-simple 5-0061: type set to 63 (Philips FMD1216ME MK3 Hybrid Tuner)
saa7134[3]: registered device video3 [v4l2]
saa7134[3]: registered device vbi3
saa7134[3]: registered device radio2
dvb_init() allocating 1 frontend
tuner-simple 2-0061: attaching existing instance
tuner-simple 2-0061: type set to 63 (Philips FMD1216ME MK3 Hybrid Tuner)
DVB: registering new adapter (saa7134[0])
DVB: registering adapter 0 frontend -1837029187 (Philips TDA10046H DVB-T)...
tda1004x: setting up plls for 53MHz sampling clock
device-mapper: uevent: version 1.0.3
device-mapper: ioctl: 4.13.0-ioctl (2007-10-18) initialised: dm-devel@redhat.com
device-mapper: multipath: version 1.0.5 loaded
EXT3 FS on sda4, internal journal
kjournald starting.  Commit interval 5 seconds
EXT3 FS on sda3, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
tda1004x: found firmware revision 26 -- ok
dvb_init() allocating 1 frontend
DVB: registering new adapter (saa7133[1])
DVB: registering adapter 1 frontend 1152717138 (Philips TDA10046H DVB-T)...
tda1004x: setting up plls for 48MHz sampling clock
Adding 1477940k swap on /dev/sda8.  Priority:-1 extents:1 across:1477940k
tda1004x: found firmware revision 29 -- ok
dvb_init() allocating 1 frontend
DVB: registering new adapter (saa7133[2])
DVB: registering adapter 2 frontend 0 (Philips TDA10046H DVB-T)...
tda1004x: setting up plls for 48MHz sampling clock
tda1004x: found firmware revision 26 -- ok
dvb_init() allocating 1 frontend
tuner-simple 5-0061: attaching existing instance
tuner-simple 5-0061: type set to 63 (Philips FMD1216ME MK3 Hybrid Tuner)
DVB: registering new adapter (saa7134[3])
DVB: registering adapter 3 frontend 0 (Philips TDA10046H DVB-T)...
tda1004x: setting up plls for 53MHz sampling clock
tda1004x: found firmware revision 29 -- ok
warning: process `kudzu' used the deprecated sysctl system call with 1.23.
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
ip6_tables: (C) 2000-2006 Netfilter Core Team
nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
ip_tables: (C) 2000-2006 Netfilter Core Team
eth0:  setting full-duplex.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
warning: `dbus-daemon' uses 32-bit capabilities (legacy support in use)
Bluetooth: Core ver 2.11
NET: Registered protocol family 31
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
Bluetooth: L2CAP ver 2.9
Bluetooth: L2CAP socket layer initialized
Bluetooth: RFCOMM socket layer initialized
Bluetooth: RFCOMM TTY layer initialized
Bluetooth: RFCOMM ver 1.8
Bluetooth: BNEP (Ethernet Emulation) ver 1.2
Bluetooth: BNEP filters: protocol multicast
Bridge firewalling registered
pan0: Dropping NETIF_F_UFO since no NETIF_F_HW_CSUM feature.
eth0: no IPv6 routers present
agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0.
agpgart: Putting AGP V2 device at 0000:00:00.0 into 4x mode
agpgart: Putting AGP V2 device at 0000:03:00.0 into 4x mode
tuner-simple 5-0061: destroying instance
tuner-simple 2-0061: destroying instance
Linux video capture interface: v2.00
saa7130/34: v4l2 driver version 0.2.14 loaded
saa7134[0]: setting pci latency timer to 64
saa7134[0]: found at 0000:01:07.0, rev: 1, irq: 19, latency: 64, mmio: 0xe8000000
saa7134[0]: subsystem: 16be:0003, board: Medion 7134 [card=12,autodetected]
saa7134[0]: board init: gpio is 0
saa7134[0]: i2c eeprom 00: ba 10 03 00 40 00 00 00 42 01 a0 00 00 40 80 02
saa7134[0]: i2c eeprom 10: 00 71 84 0c 3f 00 83 00 01 50 12 48 00 00 82 00
saa7134[0]: i2c eeprom 20: 00 40 00 00 00 01 01 00 00 50 00 1b 00 00 92 00
saa7134[0]: i2c eeprom 30: a6 48 20 05 02 8e 84 06 c2 00 00 20 00 06 a0 24
saa7134[0]: i2c eeprom 40: 9a 01 00 02 06 00 00 00 00 00 0c 01 40 9f 42 08
saa7134[0]: i2c eeprom 50: 5a 8d e2 00 00 50 02 06 00 00 08 00 00 00 08 00
saa7134[0]: i2c eeprom 60: 04 83 fa ff fc 58 5a 8d e2 00 00 50 21 5e 20 00
saa7134[0]: i2c eeprom 70: 09 7c 9f 5b 07 50 24 87 e7 00 03 4e fe 71 38 5f
saa7134[0]: i2c eeprom 80: 20 ff ff 41 c0 1d ff 67 90 58 fa 8d e7 00 00 51
saa7134[0]: i2c eeprom 90: c1 60 95 71 92 8e a7 5e da 5e 18 ff f6 a6 91 86
saa7134[0]: i2c eeprom a0: b2 5b 3a ad 7d 50 25 ae 7d 50 40 9f c4 9f fc 50
saa7134[0]: i2c eeprom b0: 14 a6 7d 31 01 41 c0 1e 41 40 9b 5b 00 8e b2 5e
saa7134[0]: i2c eeprom c0: da 5b 12 ac 95 50 16 3f 00 5b 07 41 c0 1d 6e 38
saa7134[0]: i2c eeprom d0: 7a 38 a4 ed 7a 00 00 50 81 79 01 3c a7 28 a9 50
saa7134[0]: i2c eeprom e0: 30 e7 53 00 01 50 10 26 53 71 38 a6 3e 5e da 71
saa7134[0]: i2c eeprom f0: a4 77 f0 77 95 5b 12 8c bb 50 14 26 7a ed 7a 00
tuner 2-0043: chip found @ 0x86 (saa7134[0])
tda9887 2-0043: creating new instance
tda9887 2-0043: tda988[5/6/7] found
tuner 2-0061: chip found @ 0xc2 (saa7134[0])
saa7134[0] Cant determine tuner type 123c from EEPROM
saa7134[0] Tuner type is 63
tuner-simple 2-0061: creating new instance
tuner-simple 2-0061: type set to 63 (Philips FMD1216ME MK3 Hybrid Tuner)
saa7134[0]: registered device video0 [v4l2]
saa7134[0]: registered device vbi0
saa7134[0]: registered device radio0
saa7133[1]: setting pci latency timer to 64
saa7133[1]: found at 0000:01:08.0, rev: 208, irq: 18, latency: 64, mmio: 0xe8001000
saa7133[1]: subsystem: 1043:4862, board: ASUSTeK P7131 Dual [card=78,autodetected]
saa7133[1]: board init: gpio is 0
input: saa7134 IR (ASUSTeK P7131 Dual) as /class/input/input7
saa7133[1]: i2c eeprom 00: 43 10 62 48 54 20 1c 00 43 43 a9 1c 55 d2 b2 92
saa7133[1]: i2c eeprom 10: 00 01 20 00 ff 20 ff ff ff ff ff ff ff ff ff ff
saa7133[1]: i2c eeprom 20: 01 40 01 02 03 01 01 03 08 ff 00 d6 ff ff ff ff
saa7133[1]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[1]: i2c eeprom 40: ff 21 00 c2 96 10 03 32 15 00 ff ff ff ff ff ff
saa7133[1]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[1]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[1]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[1]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[1]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[1]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[1]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[1]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[1]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[1]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[1]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
tuner 3-004b: chip found @ 0x96 (saa7133[1])
tda829x 3-004b: setting tuner address to 61
tda829x 3-004b: type set to tda8290+75a
saa7133[1]: registered device video1 [v4l2]
saa7133[1]: registered device vbi1
saa7133[1]: registered device radio1
saa7133[2]: setting pci latency timer to 64
saa7133[2]: found at 0000:01:09.0, rev: 209, irq: 17, latency: 64, mmio: 0xe8002000
saa7133[2]: subsystem: 16be:0010, board: Medion/Creatix CTX953 Hybrid [card=134,autodetected]
saa7133[2]: board init: gpio is 0
saa7133[2]: i2c eeprom 00: be 16 10 00 54 20 1c 00 43 43 a9 1c 55 d2 b2 92
saa7133[2]: i2c eeprom 10: 00 ff 86 0f ff 20 ff 00 01 50 32 79 01 3c ca 50
saa7133[2]: i2c eeprom 20: 01 40 01 02 02 03 01 00 06 ff 00 2c 02 51 96 2b
saa7133[2]: i2c eeprom 30: a7 58 7a 1f 03 8e 84 5e da 7a 04 b3 05 87 b2 3c
saa7133[2]: i2c eeprom 40: ff 21 00 c0 96 10 03 22 15 00 fd 79 44 9f c2 8f
saa7133[2]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[2]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[2]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[2]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[2]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[2]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[2]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[2]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[2]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[2]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[2]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
tuner 4-004b: chip found @ 0x96 (saa7133[2])
tda829x 4-004b: setting tuner address to 60
tda829x 4-004b: type set to tda8290+75a
saa7133[2]: registered device video2 [v4l2]
saa7133[2]: registered device vbi2
saa7134[3]: setting pci latency timer to 64
saa7134[3]: found at 0000:01:0a.0, rev: 1, irq: 16, latency: 64, mmio: 0xe8003000
saa7134[3]: subsystem: 16be:5000, board: Medion 7134 [card=12,autodetected]
saa7134[3]: board init: gpio is 820000
saa7134[3]: i2c eeprom 00: be 16 00 50 54 20 1c 00 43 43 a9 1c 55 d2 b2 92
saa7134[3]: i2c eeprom 10: 00 ff 86 0f ff 20 ff 00 01 50 32 79 01 3c ca 50
saa7134[3]: i2c eeprom 20: 01 40 01 02 02 03 01 00 06 ff 00 6c 02 51 96 2b
saa7134[3]: i2c eeprom 30: a7 58 7a 1f 03 8e 84 5e da 7a 04 b3 05 87 b2 3c
saa7134[3]: i2c eeprom 40: ff 1d 00 c2 86 10 01 01 00 00 fd 79 44 9f c2 8f
saa7134[3]: i2c eeprom 50: ff ff ff ff ff ff 06 06 0f 00 0f 00 0f 00 0f 00
saa7134[3]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7134[3]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7134[3]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7134[3]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7134[3]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7134[3]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7134[3]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7134[3]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7134[3]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7134[3]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
tuner 5-0043: chip found @ 0x86 (saa7134[3])
tda9887 5-0043: creating new instance
tda9887 5-0043: tda988[5/6/7] found
tuner 5-0061: chip found @ 0xc2 (saa7134[3])
saa7134[3] Board has DVB-T
saa7134[3] Tuner type is 63
tuner-simple 5-0061: creating new instance
tuner-simple 5-0061: type set to 63 (Philips FMD1216ME MK3 Hybrid Tuner)
saa7134[3]: registered device video3 [v4l2]
saa7134[3]: registered device vbi3
saa7134[3]: registered device radio2
dvb_init() allocating 1 frontend
tuner-simple 2-0061: attaching existing instance
tuner-simple 2-0061: type set to 63 (Philips FMD1216ME MK3 Hybrid Tuner)
DVB: registering new adapter (saa7134[0])
DVB: registering adapter 0 frontend 0 (Philips TDA10046H DVB-T)...
tda1004x: setting up plls for 53MHz sampling clock
tda1004x: found firmware revision 26 -- ok
dvb_init() allocating 1 frontend
DVB: registering new adapter (saa7133[1])
DVB: registering adapter 1 frontend 0 (Philips TDA10046H DVB-T)...
tda1004x: setting up plls for 48MHz sampling clock
tda1004x: found firmware revision 29 -- ok
dvb_init() allocating 1 frontend
DVB: registering new adapter (saa7133[2])
DVB: registering adapter 2 frontend 0 (Philips TDA10046H DVB-T)...
tda1004x: setting up plls for 48MHz sampling clock
tda1004x: found firmware revision 26 -- ok
dvb_init() allocating 1 frontend
tuner-simple 5-0061: attaching existing instance
tuner-simple 5-0061: type set to 63 (Philips FMD1216ME MK3 Hybrid Tuner)
DVB: registering new adapter (saa7134[3])
DVB: registering adapter 3 frontend 0 (Philips TDA10046H DVB-T)...
tda1004x: setting up plls for 53MHz sampling clock
tda1004x: found firmware revision 29 -- ok
[root@pc10 ~]#


--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: KWorld ATSC 115 all static

[CityK]

Hans Verkuil wrote:
> On Friday 16 January 2009 04:20:02 CityK wrote:
>   
>> The "hack-fix" patch applies cleanly against Hans' sources. However,
>> the test results are negative -- the previous workaround ("modprobe
>> tuner -r and "modprobe tuner") fails to produce the desired result.
>>     
>
> If you try to run 'modprobe -r tuner' when the saa7134 module build from 
> my sources is loaded, then that should not work since saa7134 increases 
> the use-count of the tuner module preventing it from being unloaded.
>
> If you can do this, then that suggests that you are perhaps not using my 
> modified driver at all.
>   

Huh?  Of course I'm using your modified driver.  As a recap:
*  I tried Hans' modified sources and the test result was negative.  I
also attempted (in a similar fashion as to the steps required when using
Mike's "hack/workaround") unloading all the modules and then modprobing
them .... as Mike later explained, the modifications Hans had made are
not enough to correct the issue
* Mike then asked whether:
(a) his "hack/workaround" still applied cleanly against Hans' source,
and stated that, if that was not the case, then he would re-spin the
"hack" patch ... I confirmed that Mike's "hack/workaround" did indeed
apply cleanly against Han's source. 
(b) I was successful in getting the analogue TV working after applying
his "hack/workaround" patch against Hans' source.  However, as I
reported, the results of this test were negative ... as Mauro later
explained, the "hack/workaround" that Mike had spun will no longer work
given the inherent changes introduced in Hans' code

As requested by Mauro, I will provide the dmesg output,  both that from
the base case and then that given when 12c_scan is employed ... but that
will have to occur either later today or sometime during the week ... at
present, I have switched back to an older changeset, as I required
having a functional second TV this weekend

> BTW, I've asked Mauro to pull from my tree 
> (www.linuxtv.org/hg/~hverkuil/v4l-dvb) which contains the converted 
> saa7134 and saa6752hs drivers. It's definitely something that needs to 
> be done regardless.
>   

Err, while I agree that the changes are something that need to be done
(I don't think anyone is in disagreement with that consensus), I don't
think that this is a case of "regardless".    In fact, I stand behind
Mike's position:

> Anyway, if the previous workaround works after Hans' changes, then I
> think his changes should be merged  

But as I have demonstrated above, and as Mauro explained, the previous
"hack/workaround" no longer works in the case of with the Hans source
code.  The "if" case fails!  Consequently, the "else" case should be
don't merge.  Why?  Because we have now gone from:
* circa pre-2.6.25, Mauro's changes that  broke the boards analog TV
support, but which could somewhat be corrected by Mike's "hack/workaround"
* to present, where merging Hans' code eliminates the usability of
Mike's "hack/workaround" ... in essence, analog TV function has now been
completely killed with these boards.

Now, if it is a case that a resolution to the problem is imminently
forthcoming, then I don't think that the merge would be much of a
problem.  However, given the breadth of the conversation so far (and I
really do appreciate the depth of Trent's and Jean's
discussion/consideration on the matter), it is entirely unclear to me
that such a resolution will be found in short order  (although, I don't
discount the possibility of it either).

And, although I may have altered some of the original text at some point
in time (and looking at it now, I see that it could stand for some even
more clean up/revision), I turn everyone's attention to the
http://www.linuxtv.org/wiki/index.php/Development:_Hints_for_Refactoring_Existing_Drivers#Please_do_never_ever_apply_big_Changes_in-place
In particular, the key passage:

> If you plan to rewrite bigger portions of the code please don't create
> a huge patch or thousands of patches but *fork the relevant code
> modules so that people can easily test them concurrently with the old
> code and are free to use the old, usually well-tested code until your
> new version has matured*.
>
> *There have been several situations in the past where the linux-dvb
> CVS was barely usable for weeks or months because we did not followed
> this principle. Please respect that other people are using the
> linux-dvb source in productive environments and rely on a working code
> base. *

If your mail reader supports the html bolding, you will see my
emphasis.  I'm wagging my finger at some of you (ahem, Mauro, to start
with).  Naughty, naughty.   :D






--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: KWorld ATSC 115 all static

[CityK]

Hans Verkuil wrote:
> On Sunday 18 January 2009 19:10:16 CityK wrote:
>   
>> merging Hans' code eliminates the usability of Mike's "hack/workaround" ... in essence, analog TV
>> function has now been completely killed with these boards.
>>     
>
> I've made a new tree http://linuxtv.org/hg/~hverkuil/v4l-dvb-kworld/ 
> that calls 'enables the tuner' before loading the module. See if that 
> works.
>
> ...
>   
> I suspect that this might fix the bug.

Hans,

Between the time of my last message and now, your title has made a turn
for the better.  I proclaim that you are no longer "Hans-the-Destroyer",
rather you should be upheld as "Hans-the-Enabler" !!

In other words, it works !!  (across reboots etc etc).

The output of dmesg is interesting (two times tuner simple initiating):

> saa7130/34: v4l2 driver version 0.2.14 loaded
> ACPI: PCI Interrupt 0000:00:09.0[A] -> GSI 19 (level, low) -> IRQ 19
> saa7133[0]: found at 0000:00:09.0, rev: 240, irq: 19, latency: 32,
> mmio: 0xfa021000
> saa7133[0]: subsystem: 17de:7350, board: Kworld ATSC110/115
> [card=90,autodetected]
> saa7133[0]: board init: gpio is 100
> saa7133[0]: i2c eeprom 00: de 17 50 73 ff ff ff ff ff ff ff ff ff ff ff ff
> saa7133[0]: i2c eeprom 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> saa7133[0]: i2c eeprom 20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> saa7133[0]: i2c eeprom 40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> tuner 1-0061: chip found @ 0xc2 (saa7133[0])
> tuner-simple 1-0061: creating new instance
> tuner-simple 1-0061: type set to 68 (Philips TUV1236D ATSC/NTSC dual in)
> saa7133[0]: registered device video0 [v4l2]
> saa7133[0]: registered device vbi0
> ACPI: PCI Interrupt Link [ALKC] enabled at IRQ 22
> ACPI: PCI Interrupt 0000:00:11.5[C] -> Link [ALKC] -> GSI 22 (level,
> low) -> IRQ 22
> PCI: Setting latency timer of device 0000:00:11.5 to 64
> dvb_init() allocating 1 frontend
> nxt200x: NXT2004 Detected
> tuner-simple 1-0061: attaching existing instance
> tuner-simple 1-0061: type set to 68 (Philips TUV1236D ATSC/NTSC dual in)
> DVB: registering new adapter (saa7133[0])
> DVB: registering adapter 0 frontend 0 (Nextwave NXT200X VSB/QAM
> frontend)...
> nxt2004: Waiting for firmware upload (dvb-fe-nxt2004.fw)...
> nxt2004: Waiting for firmware upload(2)...
> nxt2004: Firmware upload complete

Would you like to see the results of after enabling 12c_scan to see what
is going on, or is this the behaviour you expected?


Some Other Miscellanea:
1) Before this gets merged, can I ask you to also make one small change
to tuner-simple; specifically, swap the contents of lines 301 and 304.  
This will change the driver's default behaviour in regards to the
selection of which RF input to use for digital cable and digital
over-the-air.  Currently, the driver is set to use digital OTA on the
top RF input and digital cable on the lower RF input spigot.  However,
IMO, a more logical/convenient configuration is to have the digital
cable input be handled by the top RF input spigot, as this is the same
one that the analog cable is also drawn from by default. Mike had made
this change, on my request, previously, but it appears that it got
reverted after the tuner re-factoring. 

Note:  users have reported different default configurations in the past
(e.g. http://www.mythtv.org/wiki/Kworld_ATSC_110), but I actually doubt
that there has been any manufacturing difference with the TUV1236D. 
Rather, I suspect that the user experiences being reported are just
reflecting a combination of the different states of how our driver
behaved in the past and differences in driver version that they may have
been using (i.e. that version provided by/within their distro or by our
Hg).  After all, this configuration setting has gone from being handled
by saa7134-dvb.c to dvb-pll.c to tuner-simple.c, with changes in the
behaviour implemented along the way.

2) This is likely related to the discussion about the gate -- after
closing the analog TV app, the audio from the last channel being viewed
can still be heard if one turns up the volume on their system.  This
leakage has always been present.  But given that we are addressing this
issue now, it strikes me that the gate is being kept open on the audio
line after application closing/release occurs.

3) there is an issue about having two of these cards in the same system
--- IIRC, only one card will get /dev/video .... Mauro touched upon this
very briefly in one of the earlier messages; recall:

Mauro wrote:
> This generated lots of issues in the past, like machines with two boards
> doesn't work anymore. With two boards, and a tuner module, the first board
> probes tuner after opening the demod gateway. However, the second board will
> try to probe tuner before opening the i2c gateway. So, tuner is not found.

Now, I can't test for this myself, but I do know of several users on
AVSforums who have two such cards and can test if that issue is now
resolved .... do you suspect that the changes you have implemented to
date will have eliminated this bug too?

Cheers, and many much appreciation.

Re: KWorld ATSC 115 all static

[CityK]

Hans Verkuil wrote:
> On Sunday 18 January 2009 22:20:30 CityK wrote:
>   
>> The output of dmesg is interesting (two times tuner simple initiating):
> Shouldn't there be a tda9887 as well? It's what the card config says, but
> I'm not sure whether that is correct.
>  
>   
>> Would you like to see the results of after enabling 12c_scan to see what
>> is going on, or is this the behaviour you expected?
>>     
>
> It seems to be OK, although I find it a bit peculiar that the tuner type
> is set twice. Or does that have to do with it being a hybrid tuner, perhaps?
>   

The Philips TUV1236D NIM does indeed use a tda9887  (I know, because I
was the one who discovered this some four years ago (pats self on
head)).  But the module is not loading.  I can make it load, just as
Hermann demonstrated to Mike in one of the recent messages for this thread.

In regards to the tuner type being set twice, that is precisely my point
-- its peculiar and not symptomatic of normal behaviour.  That is why I
asked whether you expected it to do this

>> Some Other Miscellanea:
>> 1) Before this gets merged, can I ask you to also make one small change
>> to tuner-simple; specifically, swap the contents of lines 301 and 304.  
>> This will change the driver's default behaviour in regards to the
>> selection of which RF input to use for digital cable and digital
>> over-the-air.  Currently, the driver is set to use digital OTA on the
>> top RF input and digital cable on the lower RF input spigot.  However,
>> IMO, a more logical/convenient configuration is to have the digital
>> cable input be handled by the top RF input spigot, as this is the same
>> one that the analog cable is also drawn from by default. Mike had made
>> this change, on my request, previously, but it appears that it got
>> reverted after the tuner re-factoring. 
>>
>> Note:  users have reported different default configurations in the past
>> (e.g. http://www.mythtv.org/wiki/Kworld_ATSC_110), but I actually doubt
>> that there has been any manufacturing difference with the TUV1236D. 
>> Rather, I suspect that the user experiences being reported are just
>> reflecting a combination of the different states of how our driver
>> behaved in the past and differences in driver version that they may have
>> been using (i.e. that version provided by/within their distro or by our
>> Hg).  After all, this configuration setting has gone from being handled
>> by saa7134-dvb.c to dvb-pll.c to tuner-simple.c, with changes in the
>> behaviour implemented along the way.
>>
>>     
>
> I'm not going to merge this, it's just a quick hack for this card. This
> is something for Mike or Hermann to fix. 

Fair enough -- I will pester them a la Bart Simpson spy camera style
(see:
http://peanutbutterandpickles.blogspot.com/2008/06/wheres-my-spy-camera-wheres-my-spy.html
and for actual dialogue: http://www.snpp.com/episodes/7G10.html)  :P

It is a trivial change which I can vouch that works (after successfully
testing your new "KWorld" changeset, I immediately applied this change
and rebuilt ... with, of course, successful results).


> Someone with a better knowledge
> of this driver and these tuners should review the saa7134_board_init2()
> function and move the opening of tuner gate/muxes to a separate function.
>   
>> 2) This is likely related to the discussion about the gate -- after
>> closing the analog TV app, the audio from the last channel being viewed
>> can still be heard if one turns up the volume on their system.  This
>> leakage has always been present.  But given that we are addressing this
>> issue now, it strikes me that the gate is being kept open on the audio
>> line after application closing/release occurs.
>>     

I just did some testing in regards to point number 2 ... at first I was
thinking that maybe it was because tda9887 is not loading automatically
that, absent of fine control, the audio leakage was occurring.  But
after loading tda9887 and then removing the module, the leakage
continues.  Naturally, the other suspect is saa7134.  And, as it turns
out, if one modprobe -r saa7134-dvb (which obviously uses sa7134), then
the audio leakage immediately comes to an end, and checking lsmod,
saa7134 is no longer found.  So at least I know the source of the bug
now ... now its just a case of getting it to release properly.  Comments
from anyone on this?

>> 3) there is an issue about having two of these cards in the same system
>> --- IIRC, only one card will get /dev/video .... Mauro touched upon this
>> very briefly in one of the earlier messages; recall:
>>
>> Mauro wrote:
>>     
>>> This generated lots of issues in the past, like machines with two boards
>>> doesn't work anymore. With two boards, and a tuner module, the first board
>>> probes tuner after opening the demod gateway. However, the second board will
>>> try to probe tuner before opening the i2c gateway. So, tuner is not found.
>>>       
>> Now, I can't test for this myself, but I do know of several users on
>> AVSforums who have two such cards and can test if that issue is now
>> resolved .... do you suspect that the changes you have implemented to
>> date will have eliminated this bug too?
>>     
>
> That should have been fixed as well now that the automatic probing has
> been removed.
>   

Okay, cool!  As soon as this change gets pulled into the mail line, I'll
prompt those folks on AVS to test. 

> Hopefully the work I did on saa7134 can be ported to other drivers as well,
> since this clearly fixes a lot of tricky bugs.

Yep.

And what of the deeper discussion that evolved (re: Trent and Jean's
ideas)? 

Re: KWorld ATSC 115 all static

[Mauro Carvalho Chehab]

On Sun, 18 Jan 2009 18:36:35 -0500
CityK <cityk@rogers.com> wrote:

> Hans Verkuil wrote:
> > On Sunday 18 January 2009 22:20:30 CityK wrote:
> >   
> >> The output of dmesg is interesting (two times tuner simple initiating):
> > Shouldn't there be a tda9887 as well? It's what the card config says, but
> > I'm not sure whether that is correct.
> >  
> >   
> >> Would you like to see the results of after enabling 12c_scan to see what
> >> is going on, or is this the behaviour you expected?
> >>     
> >
> > It seems to be OK, although I find it a bit peculiar that the tuner type
> > is set twice. Or does that have to do with it being a hybrid tuner, perhaps?
> >   
> 
> The Philips TUV1236D NIM does indeed use a tda9887  (I know, because I
> was the one who discovered this some four years ago (pats self on
> head)).  But the module is not loading.  I can make it load, just as
> Hermann demonstrated to Mike in one of the recent messages for this thread.

>From what I got from the sources, nxt200x has an i2c gate. For accessing the
tuner, the gate needs to be opened. Maybe we need to close the gate in order to
access tda9887.

Unfortunately, I don't have nxt200x datasheet. Things would be clearer with the docs.

> >> Some Other Miscellanea:
> >> 1) Before this gets merged, can I ask you to also make one small change
> >> to tuner-simple; specifically, swap the contents of lines 301 and 304.  
> >> This will change the driver's default behaviour in regards to the
> >> selection of which RF input to use for digital cable and digital
> >> over-the-air.  Currently, the driver is set to use digital OTA on the
> >> top RF input and digital cable on the lower RF input spigot.  However,
> >> IMO, a more logical/convenient configuration is to have the digital
> >> cable input be handled by the top RF input spigot, as this is the same
> >> one that the analog cable is also drawn from by default. Mike had made
> >> this change, on my request, previously, but it appears that it got
> >> reverted after the tuner re-factoring. 

Could you provide a patch against the current tree?

> >>
> >> Note:  users have reported different default configurations in the past
> >> (e.g. http://www.mythtv.org/wiki/Kworld_ATSC_110), but I actually doubt
> >> that there has been any manufacturing difference with the TUV1236D. 
> >> Rather, I suspect that the user experiences being reported are just
> >> reflecting a combination of the different states of how our driver
> >> behaved in the past and differences in driver version that they may have
> >> been using (i.e. that version provided by/within their distro or by our
> >> Hg).  After all, this configuration setting has gone from being handled
> >> by saa7134-dvb.c to dvb-pll.c to tuner-simple.c, with changes in the
> >> behaviour implemented along the way.

The issue doesn't seem to be related to TUV1236D, but, instead with nxt200x.
The i2c command to enable the tuner is sent to nxt200x. If there are any
ATSC110 variant with a different demod (maybe a different version of nxt200x?),
then the users may experience different behaviors.

> > I'm not going to merge this, it's just a quick hack for this card. This
> > is something for Mike or Hermann to fix. 
> 
> Fair enough 

Please test the enclosed patch. It adds a proper gate_ctrl callback at saa7134
core, and initializes it for ATSC110. 

The gate_ctrl is close to what we currently have on cx88 driver, however with a
simpler implementation. We'll likely need to improve it, moving the i2c gate
control into nxt200x, adding the i2c close commands, and putting the gate_ctrl
initialization into saa7134-dvb.

You should notice that we don't know how to close the gate. So, the code is
still a workaroud.. However, to properly implement it, we need the help
of someone with the datasheets.

> > Someone with a better knowledge
> > of this driver and these tuners should review the saa7134_board_init2()
> > function and move the opening of tuner gate/muxes to a separate function.

This should be needed to do per board. The issue here is that we need to know
the i2c open and close cmds.

Cheers,
Mauro

---
saa7134: Fix tuner access on Kworld ATSC110

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

diff -r 0622096401ec linux/drivers/media/video/saa7134/saa7134-cards.c
--- a/linux/drivers/media/video/saa7134/saa7134-cards.c	Sun Jan 18 23:20:02 2009 -0200
+++ b/linux/drivers/media/video/saa7134/saa7134-cards.c	Mon Jan 19 08:43:36 2009 -0200
@@ -5994,6 +5994,32 @@
 }
 
 /* ----------------------------------------------------------- */
+
+static void nxt200x_gate_ctrl(struct saa7134_dev *dev, int open)
+{
+	/* enable tuner */
+	int i;
+	static const u8 buffer [][2] = { 
+		{ 0x10, 0x12 }, 
+		{ 0x13, 0x04 },
+		{ 0x16, 0x00 },
+		{ 0x14, 0x04 },
+		{ 0x17, 0x00 },
+	};
+
+	dev->i2c_client.addr = 0x0a;
+
+	/* FIXME: don't know how to close the i2c gate on NXT200x */
+	if (!open)
+		return;
+
+	for (i = 0; i < ARRAY_SIZE(buffer); i++)
+		if (2 != i2c_master_send(&dev->i2c_client,
+					 &buffer[i][0], ARRAY_SIZE(buffer[0])))
+			printk(KERN_WARNING
+			       "%s: Unable to enable tuner(%i).\n",
+			       dev->name, i);
+}
 
 int saa7134_board_init1(struct saa7134_dev *dev)
 {
@@ -6192,6 +6218,10 @@
 		       "are supported for now.\n",
 			dev->name, card(dev).name, dev->name);
 		break;
+	case SAA7134_BOARD_ADS_INSTANT_HDTV_PCI:
+	case SAA7134_BOARD_KWORLD_ATSC110:
+		dev->gate_ctrl = nxt200x_gate_ctrl;
+		break;
 	}
 	return 0;
 }
@@ -6453,22 +6483,6 @@
 		i2c_transfer(&dev->i2c_adap, &msg, 1);
 		break;
 	}
-	case SAA7134_BOARD_ADS_INSTANT_HDTV_PCI:
-	case SAA7134_BOARD_KWORLD_ATSC110:
-	{
-		/* enable tuner */
-		int i;
-		static const u8 buffer [] = { 0x10, 0x12, 0x13, 0x04, 0x16,
-					      0x00, 0x14, 0x04, 0x17, 0x00 };
-		dev->i2c_client.addr = 0x0a;
-		for (i = 0; i < 5; i++)
-			if (2 != i2c_master_send(&dev->i2c_client,
-						 &buffer[i*2], 2))
-				printk(KERN_WARNING
-				       "%s: Unable to enable tuner(%i).\n",
-				       dev->name, i);
-		break;
-	}
 	case SAA7134_BOARD_VIDEOMATE_DVBT_200:
 	case SAA7134_BOARD_VIDEOMATE_DVBT_200A:
 		/* The T200 and the T200A share the same pci id.  Consequently,
diff -r 0622096401ec linux/drivers/media/video/saa7134/saa7134.h
--- a/linux/drivers/media/video/saa7134/saa7134.h	Sun Jan 18 23:20:02 2009 -0200
+++ b/linux/drivers/media/video/saa7134/saa7134.h	Mon Jan 19 08:43:36 2009 -0200
@@ -594,6 +594,7 @@
 	int (*original_set_voltage)(struct dvb_frontend *fe, fe_sec_voltage_t voltage);
 	int (*original_set_high_voltage)(struct dvb_frontend *fe, long arg);
 #endif
+	void (*gate_ctrl)(struct saa7134_dev *dev, int open);
 };
 
 /* ----------------------------------------------------------- */
@@ -623,10 +624,24 @@
 		V4L2_STD_PAL_60)
 
 #define GRP_EMPRESS (1)
-#define saa_call_all(dev, o, f, args...) \
-	v4l2_device_call_all(&(dev)->v4l2_dev, 0, o, f , ##args)
-#define saa_call_empress(dev, o, f, args...) \
-	v4l2_device_call_until_err(&(dev)->v4l2_dev, GRP_EMPRESS, o, f , ##args)
+#define saa_call_all(dev, o, f, args...) do {				\
+	if (dev->gate_ctrl)						\
+		dev->gate_ctrl(dev, 1);					\
+	v4l2_device_call_all(&(dev)->v4l2_dev, 0, o, f , ##args);	\
+	if (dev->gate_ctrl)						\
+		dev->gate_ctrl(dev, 0);					\
+} while (0)
+
+#define saa_call_empress(dev, o, f, args...) ({				\
+	long _rc;							\
+	if (dev->gate_ctrl)						\
+		dev->gate_ctrl(dev, 1);					\
+	_rc = v4l2_device_call_until_err(&(dev)->v4l2_dev,		\
+				         GRP_EMPRESS, o, f , ##args);	\
+	if (dev->gate_ctrl)						\
+		dev->gate_ctrl(dev, 0);					\
+	_rc;								\
+})
 
 /* ----------------------------------------------------------- */
 /* saa7134-core.c                                              */

Re: KWorld ATSC 115 all static

[Mauro Carvalho Chehab]

On Mon, 19 Jan 2009 08:53:19 +0100
Hans Verkuil <hverkuil@xs4all.nl> wrote:

> On Monday 19 January 2009 00:36:35 CityK wrote:
> > Hans Verkuil wrote:
> > > On Sunday 18 January 2009 22:20:30 CityK wrote:
> > >> The output of dmesg is interesting (two times tuner simple
> > >> initiating):
> > >
> > > Shouldn't there be a tda9887 as well? It's what the card config says,
> > > but I'm not sure whether that is correct.
> > >
> > >> Would you like to see the results of after enabling 12c_scan to see
> > >> what is going on, or is this the behaviour you expected?
> > >
> > > It seems to be OK, although I find it a bit peculiar that the tuner
> > > type is set twice. Or does that have to do with it being a hybrid
> > > tuner, perhaps?
> >
> > The Philips TUV1236D NIM does indeed use a tda9887  (I know, because I
> > was the one who discovered this some four years ago (pats self on
> > head)).  But the module is not loading.  I can make it load, just as
> > Hermann demonstrated to Mike in one of the recent messages for this
> > thread.
> 
> I have no idea why the tda9887 isn't loading. 

Probably, it has something to do with the i2c gate control.

> Note that Mauro merged my saa7134 changes, so these are now in the master 
> repository.

Yes. We need to fix it asap, to avoid regressions. It is time to review also
the other codes that are touching on i2c gates at _init2().

Cheers,
Mauro

Re: KWorld ATSC 115 all static

[hermann pitton]

Hi,

Am Montag, den 19.01.2009, 09:08 -0200 schrieb Mauro Carvalho Chehab: 
> On Mon, 19 Jan 2009 08:53:19 +0100
> Hans Verkuil <hverkuil@xs4all.nl> wrote:
> 
> > On Monday 19 January 2009 00:36:35 CityK wrote:
> > > Hans Verkuil wrote:
> > > > On Sunday 18 January 2009 22:20:30 CityK wrote:
> > > >> The output of dmesg is interesting (two times tuner simple
> > > >> initiating):
> > > >
> > > > Shouldn't there be a tda9887 as well? It's what the card config says,
> > > > but I'm not sure whether that is correct.
> > > >
> > > >> Would you like to see the results of after enabling 12c_scan to see
> > > >> what is going on, or is this the behaviour you expected?
> > > >
> > > > It seems to be OK, although I find it a bit peculiar that the tuner
> > > > type is set twice. Or does that have to do with it being a hybrid
> > > > tuner, perhaps?
> > >
> > > The Philips TUV1236D NIM does indeed use a tda9887  (I know, because I
> > > was the one who discovered this some four years ago (pats self on
> > > head)).  But the module is not loading.  I can make it load, just as
> > > Hermann demonstrated to Mike in one of the recent messages for this
> > > thread.
> > 
> > I have no idea why the tda9887 isn't loading. 
> 
> Probably, it has something to do with the i2c gate control.

in my case on the md7134 cards it happens only after cold boot.
Analog of course doesn't work then.

To reload the saa7134 with "modprobe" then is also enough to get it
loaded and analog functional, likely what Mike meant.

On warm reboots it is present and functional. Some eeprom readout
corruption mostly on the first card occurs and I must force card=12.

The tda9887 is by default not visible on the FMD1216ME MK3 hybrid.

The init from Hartmut in tuner-core.c in set_tuner_type for analog.

	case TUNER_PHILIPS_FMD1216ME_MK3:
		buffer[0] = 0x0b;
		buffer[1] = 0xdc;
		buffer[2] = 0x9c;
		buffer[3] = 0x60;
		i2c_master_send(c, buffer, 4);
		mdelay(1);
		buffer[2] = 0x86;
		buffer[3] = 0x54;
		i2c_master_send(c, buffer, 4);
		if (!dvb_attach(simple_tuner_attach, &t->fe,
				t->i2c->adapter, t->i2c->addr, t->type))
			goto attach_failed;
		break;

from dmesg.

dmesg |grep "< c2"
saa7133[1]: i2c xfer: < c2 30 90 >
saa7134[3]: i2c xfer: < c2 >
saa7134[3]: i2c xfer: < c2 0b dc 9c 60 >
saa7134[3]: i2c xfer: < c2 0b dc 86 54 >

Exactly here, when the buffers are sent the second time the tda9887
becomes the first time visible on the bus. According to Hartmut the
modification of buffer[3] from 0x60 to 0x54 is that hidden switch,
IIRC. 

saa7134[3]: i2c xfer: < c2 1b 6f 86 52 >
saa7134[3]: i2c xfer: < c2 1b 6f 86 52 >
saa7134[3]: i2c xfer: < c2 1b 6f 86 52 >
saa7134[3]: i2c xfer: < c2 9c 60 85 54 >
saa7134[0]: i2c xfer: < c2 9c 60 85 54 >
saa7133[1]: i2c xfer: < c2 30 90 >
saa7134[3]: i2c xfer: < c2 9c 60 85 54 >

> > Note that Mauro merged my saa7134 changes, so these are now in the master 
> > repository.
> 
> Yes. We need to fix it asap, to avoid regressions. It is time to review also
> the other codes that are touching on i2c gates at _init2().

My other cards with tda8275a, tda8290, tda10046 and/or tda826x and
tda10086 still work and the FMD1216ME init broken is old. 

There is an old issue, maybe not reported yet, that after suspend to RAM
it seems the AGC control for DVB-T is lost, lots of artifacts. After
using analog TV or reload the saa7134 it is fixed.
Just to mention it.

Cheers,
Hermann

> Cheers,
> Mauro

Re: KWorld ATSC 115 all static

[CityK]

Hi, sorry for the delay

Hans Verkuil wrote:
> On Monday 19 January 2009 00:36:35 CityK wrote:  
>> Hans Verkuil wrote:    
>>> Shouldn't there be a tda9887 as well? It's what the card config says,
>>> but I'm not sure whether that is correct.
>> The Philips TUV1236D NIM does indeed use a tda9887  (I know, because I
>> was the one who discovered this some four years ago (pats self on
>> head)).  But the module is not loading.  I can make it load, just as
>> Hermann demonstrated to Mike in one of the recent messages for this
>> thread.
>>     
>
> I have no idea why the tda9887 isn't loading. It loads fine for my empress 
> card. Does someone know if there is something special about this? And how 
> do you manage to make analog TV work if the tda9887 isn't found? That's 
> rather peculiar.
>
> .....
>
>
> To clarify: you should see this in the dmesg output if there is a tda9887:
>
> ...
> saa7133[0]: i2c eeprom f0: 42 54 56 30 30 30 30 ff ff ff ff ff ff ff ff ff
> tuner 1-0043: chip found @ 0x86 (saa7133[0])
> tda9887 1-0043: creating new instance
> tda9887 1-0043: tda988[5/6/7] found
> ^^^^^^^^^^^^^^^

Mauro Carvalho Chehab wrote:
> Probably, it has something to do with the i2c gate control.
> ....
> From what I got from the sources, nxt200x has an i2c gate. For accessing the
> tuner, the gate needs to be opened. Maybe we need to close the gate in order to
> access tda9887.
>
> Unfortunately, I don't have nxt200x datasheet. Things would be clearer with the docs.
>   

hermann pitton wrote:
> in my case on the md7134 cards it happens only after cold boot.
> Analog of course doesn't work then.
>
> To reload the saa7134 with "modprobe" then is also enough to get it
> loaded and analog functional, likely what Mike meant.
>
> On warm reboots it is present and functional. Some eeprom readout
> corruption mostly on the first card occurs and I must force card=12.
>
> The tda9887 is by default not visible on the FMD1216ME MK3 hybrid.
>
> The init from Hartmut in tuner-core.c in set_tuner_type for analog.
>
> 	case TUNER_PHILIPS_FMD1216ME_MK3:
> 		buffer[0] = 0x0b;
> 		buffer[1] = 0xdc;
> 		buffer[2] = 0x9c;
> 		buffer[3] = 0x60;
> 		i2c_master_send(c, buffer, 4);
> 		mdelay(1);
> 		buffer[2] = 0x86;
> 		buffer[3] = 0x54;
> 		i2c_master_send(c, buffer, 4);
> 		if (!dvb_attach(simple_tuner_attach, &t->fe,
> 				t->i2c->adapter, t->i2c->addr, t->type))
> 			goto attach_failed;
> 		break;
>
> from dmesg.
>
> dmesg |grep "< c2"
> saa7133[1]: i2c xfer: < c2 30 90 >
> saa7134[3]: i2c xfer: < c2 >
> saa7134[3]: i2c xfer: < c2 0b dc 9c 60 >
> saa7134[3]: i2c xfer: < c2 0b dc 86 54 >
>
> Exactly here, when the buffers are sent the second time the tda9887
> becomes the first time visible on the bus. According to Hartmut the
> modification of buffer[3] from 0x60 to 0x54 is that hidden switch,
> IIRC. 
>
> saa7134[3]: i2c xfer: < c2 1b 6f 86 52 >
> saa7134[3]: i2c xfer: < c2 1b 6f 86 52 >
> saa7134[3]: i2c xfer: < c2 1b 6f 86 52 >
> saa7134[3]: i2c xfer: < c2 9c 60 85 54 >
> saa7134[0]: i2c xfer: < c2 9c 60 85 54 >
> saa7133[1]: i2c xfer: < c2 30 90 >
> saa7134[3]: i2c xfer: < c2 9c 60 85 54 >
>   

I believe Mauro is correct in regards to the tda9887 in that, within the
Philips TUV1236D NIM, it is behind the Nxt2004's i2c gate.  After
re-reading what Michael mentioned previously:
> tda9887 is now a sub-module of tuner-core.  tda9887, when modprobed
> alone, will not attach to any actual device without also having
> tuner.ko loaded in memory.  tda9887 is a separate module, but its
> interface is currently only accessed via tuner-core (tuner.ko) 
I believe that even in the case where I modprobe the tda9887 (such as
how Hermann demonstrated) and get the module to load, it is not
effectively attaching to the device.  So, this still begs Han's
question:  "how do you manage to make analog TV work if the tda9887
isn't found? That's rather peculiar."  I don't have an answer for that. 
The tuner-simple module, however, seems to be able to drive/provide that
functionality sufficiently enough.  Perhaps Michael can shed more light
on this.

In any regard, if anyone is interested, you can observe the internal
layout of the NIM from this Anandtech pic (warning, large image) :
http://images.anandtech.com/reviews/video/ATI/hdtvwonder/tuner.jpg   As
would happen to be the case, the labelling on the tda9887 gets washed
out in the photo, however, one can surmise from the shadow that the
insignia is the Philips badge and, with a good monitor, you can actually
make out "TDA" on the top line of print.


Mauro Carvalho Chehab wrote:
>
> CityK wrote:  
>> Note:  users have reported different default configurations in the past
>> (e.g. http://www.mythtv.org/wiki/Kworld_ATSC_110), but I actually doubt
>> that there has been any manufacturing difference with the TUV1236D. 
>> Rather, I suspect that the user experiences being reported are just
>> reflecting a combination of the different states of how our driver
>> behaved in the past and differences in driver version that they may have
>> been using (i.e. that version provided by/within their distro or by our
>> Hg).  After all, this configuration setting has gone from being handled
>> by saa7134-dvb.c to dvb-pll.c to tuner-simple.c, with changes in the
>> behaviour implemented along the way.
> The issue doesn't seem to be related to TUV1236D, but, instead with nxt200x.
> The i2c command to enable the tuner is sent to nxt200x. If there are any
> ATSC110 variant with a different demod (maybe a different version of nxt200x?),
> then the users may experience different behaviors.

Different demod? -- No, I'm pretty sure that the NIM exclusively uses
the Nxt2004. 
Different revision of the Nxt2004? -- I'd say its quite logical to
suspect that there have been a couple of fabrication spins of the demod
... it is, after all, several years old.  However, although possible, I
don't think a different revision explains the case here.  Rather, as
described above, I just think that it's a case of apples to oranges
comparisons; user experiences that reflect different snapshots of time
and driver revisions.

Though, although unlikely, another thought I have on this is the
possibility of a situation akin to a switch for railway tracks ....
especially if the user first employs the card under Windows -- my
thought is perhaps the Windows driver configures a hard routing pathway.

Anyway, there is, coincidently, a similar analogue-less variant of the
NIM, the TU1236.  As one user reports
(http://marc.info/?l=linux-dvb&m=122314219031405&w=2) it can be found on
the "VE" version of the HDTV wonder.  I believe that the TU1236 is also
differentiated from the TUV1236D by its use of the Nxt2003, as opposed
to the Nxt2004 in the later.

Hans Verkuil wrote:

> CityK wrote:
>> In regards to the tuner type being set twice, that is precisely my point
>> -- its peculiar and not symptomatic of normal behaviour.  That is why I
>> asked whether you expected it to do this    
>
> I think it is OK. The second setup is probably done by dvb_attach() in 
> saa7134-dvb.c, line 1191. Can you verify that with a debug message?  

Could not verify.  (dmesg output provided below at end).


Mauro Carvalho Chehab wrote:
>
> Please test the enclosed patch. It adds a proper gate_ctrl callback at saa7134
> core, and initializes it for ATSC110. 
>
> The gate_ctrl is close to what we currently have on cx88 driver, however with a
> simpler implementation. We'll likely need to improve it, moving the i2c gate
> control into nxt200x, adding the i2c close commands, and putting the gate_ctrl
> initialization into saa7134-dvb.
>
> You should notice that we don't know how to close the gate. So, the code is
> still a workaroud.. However, to properly implement it, we need the help
> of someone with the datasheets.
>
>   
>>> Someone with a better knowledge
>>> of this driver and these tuners should review the saa7134_board_init2()
>>> function and move the opening of tuner gate/muxes to a separate function.     
>
> This should be needed to do per board. The issue here is that we need to know
> the i2c open and close cmds.
>   

Mauro, your patch applied cleanly against mainline.  (But not against
Hans' KWorld test repo; though I don't think you meant/intended for it
to be applied against that anyway).
However, analogue TV functionality still is inoperative.   (dmesg output
provided below at end).


Mauro Carvalho Chehab wrote:
> Hans Verkuil wrote:
>> Note that Mauro merged my saa7134 changes, so these are now in the master 
>> repository.
>>     
> Yes. We need to fix it asap, to avoid regressions. It is time to review also
> the other codes that are touching on i2c gates at _init2().
>   

Thoughts on merging the changes from Hans' KWorld repo? 


----------------------------------------------------------------------------------------------------

And now, some observations:

[1] Hans KWorld repo:

A)
modprobe -r saa7134-dvb
modprobe -r tuner
modprobe saa7134 i2c_scan=1
dmesg:

tuner-simple 1-0061: destroying instance
Linux video capture interface: v2.00
saa7130/34: v4l2 driver version 0.2.14 loaded
saa7133[0]: found at 0000:00:09.0, rev: 240, irq: 19, latency: 32, mmio:
0xfa021000
saa7133[0]: subsystem: 17de:7350, board: Kworld ATSC110/115
[card=90,autodetected]
saa7133[0]: board init: gpio is 100
saa7133[0]: i2c eeprom 00: de 17 50 73 ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c scan: found device @ 0x14  [???]
saa7133[0]: i2c scan: found device @ 0x16  [???]
saa7133[0]: i2c scan: found device @ 0xa0  [eeprom]
tuner 1-0061: chip found @ 0xc2 (saa7133[0])
tuner-simple 1-0061: creating new instance
tuner-simple 1-0061: type set to 68 (Philips TUV1236D ATSC/NTSC dual in)
saa7133[0]: registered device video0 [v4l2]
saa7133[0]: registered device vbi0
dvb_init() allocating 1 frontend
nxt200x: NXT2004 Detected
tuner-simple 1-0061: attaching existing instance
tuner-simple 1-0061: type set to 68 (Philips TUV1236D ATSC/NTSC dual in)
DVB: registering new adapter (saa7133[0])
DVB: registering adapter 0 frontend 0 (Nextwave NXT200X VSB/QAM frontend)...
nxt2004: Waiting for firmware upload (dvb-fe-nxt2004.fw)...
nxt2004: Waiting for firmware upload(2)...
nxt2004: Firmware upload complete


B)
modprobe -r saa7134-dvb
modprobe -r tuner
modprobe saa7134 i2c_debug=1
dmesg:

tuner-simple 1-0061: destroying instance
Linux video capture interface: v2.00
saa7130/34: v4l2 driver version 0.2.14 loaded
saa7133[0]: found at 0000:00:09.0, rev: 240, irq: 19, latency: 32, mmio:
0xfa021000
saa7133[0]: subsystem: 17de:7350, board: Kworld ATSC110/115
[card=90,autodetected]
saa7133[0]: board init: gpio is 100
saa7133[0]: i2c xfer: < a0 00 >
saa7133[0]: i2c xfer: < a1 =de =17 =50 =73 =ff =ff =ff =ff =ff =ff =ff
=ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff
=ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff
=ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff
=ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff
=ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff
=ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff
=ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff
=ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff
=ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff
=ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff
=ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff
=ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff
=ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff
=ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff >
saa7133[0]: i2c eeprom 00: de 17 50 73 ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c xfer: < 14 10 12 >
saa7133[0]: i2c xfer: < 14 13 04 >
saa7133[0]: i2c xfer: < 14 16 00 >
saa7133[0]: i2c xfer: < 14 14 04 >
saa7133[0]: i2c xfer: < 14 17 00 >
saa7133[0]: i2c xfer: < 84 ERROR: NO_DEVICE
saa7133[0]: i2c xfer: < 86 ERROR: NO_DEVICE
saa7133[0]: i2c xfer: < 94 ERROR: NO_DEVICE
saa7133[0]: i2c xfer: < 96 ERROR: NO_DEVICE
saa7133[0]: i2c xfer: < c0 ERROR: NO_DEVICE
saa7133[0]: i2c xfer: < c2 >
tuner 1-0061: chip found @ 0xc2 (saa7133[0])
tuner i2c attach [addr=0x61,client=]
saa7133[0]: i2c xfer: < 14 10 12 >
saa7133[0]: i2c xfer: < 14 13 04 >
saa7133[0]: i2c xfer: < 14 16 00 >
saa7133[0]: i2c xfer: < 14 14 04 >
saa7133[0]: i2c xfer: < 14 17 00 >
saa7133[0]: i2c xfer: < c3 =7c >
tuner-simple 1-0061: creating new instance
tuner-simple 1-0061: type set to 68 (Philips TUV1236D ATSC/NTSC dual in)
saa7133[0]: i2c xfer: < 14 14 00 >
saa7133[0]: i2c xfer: < 14 17 00 >
saa7133[0]: i2c xfer: < c2 1b 6f ce 02 >
saa7133[0]: i2c xfer: < 14 10 12 >
saa7133[0]: i2c xfer: < 14 13 04 >
saa7133[0]: i2c xfer: < 14 16 00 >
saa7133[0]: i2c xfer: < 14 14 04 >
saa7133[0]: i2c xfer: < 14 17 00 >
saa7133[0]: i2c xfer: < 14 10 12 >
saa7133[0]: i2c xfer: < 14 13 04 >
saa7133[0]: i2c xfer: < 14 16 00 >
saa7133[0]: i2c xfer: < 14 14 04 >
saa7133[0]: i2c xfer: < 14 17 00 >
saa7133[0]: i2c xfer: < 14 14 00 >
saa7133[0]: i2c xfer: < 14 17 00 >
saa7133[0]: i2c xfer: < c2 1b 6f ce 02 >
saa7133[0]: i2c xfer: < 14 10 12 >
saa7133[0]: i2c xfer: < 14 13 04 >
saa7133[0]: i2c xfer: < 14 16 00 >
saa7133[0]: i2c xfer: < 14 14 04 >
saa7133[0]: i2c xfer: < 14 17 00 >
saa7133[0]: i2c xfer: < 14 10 12 >
saa7133[0]: i2c xfer: < 14 13 04 >
saa7133[0]: i2c xfer: < 14 16 00 >
saa7133[0]: i2c xfer: < 14 14 04 >
saa7133[0]: i2c xfer: < 14 17 00 >
saa7133[0]: i2c xfer: < 14 14 00 >
saa7133[0]: i2c xfer: < 14 17 00 >
saa7133[0]: i2c xfer: < c2 1b 6f ce 02 >
saa7133[0]: i2c xfer: < 14 10 12 >
saa7133[0]: i2c xfer: < 14 13 04 >
saa7133[0]: i2c xfer: < 14 16 00 >
saa7133[0]: i2c xfer: < 14 14 04 >
saa7133[0]: i2c xfer: < 14 17 00 >
saa7133[0]: registered device video0 [v4l2]
saa7133[0]: registered device vbi0
saa7133[0]: i2c xfer: < 14 10 12 >
saa7133[0]: i2c xfer: < 14 10 12 >
saa7133[0]: i2c xfer: < 14 13 04 >
saa7133[0]: i2c xfer: < 14 16 00 >
saa7133[0]: i2c xfer: < 14 14 04 >
saa7133[0]: i2c xfer: < 14 17 00 >
saa7133[0]: i2c xfer: < 14 14 00 >
saa7133[0]: i2c xfer: < 14 17 00 >
saa7133[0]: i2c xfer: < c2 1b 6f ce 02 >
saa7133[0]: i2c xfer: < 14 10 12 >
saa7133[0]: i2c xfer: < 14 13 04 >
saa7133[0]: i2c xfer: < 14 16 00 >
saa7133[0]: i2c xfer: < 14 14 04 >
saa7133[0]: i2c xfer: < 14 17 00 >
saa7133[0]: i2c xfer: < 14 10 12 >
saa7133[0]: i2c xfer: < 14 13 04 >
saa7133[0]: i2c xfer: < 14 16 00 >
saa7133[0]: i2c xfer: < 14 14 04 >
saa7133[0]: i2c xfer: < 14 17 00 >
saa7133[0]: i2c xfer: < 14 13 04 >
saa7133[0]: i2c xfer: < 14 16 00 >
saa7133[0]: i2c xfer: < 14 14 04 >
saa7133[0]: i2c xfer: < 14 17 00 >
saa7133[0]: i2c xfer: < 14 10 12 ><6>dvb_init() allocating 1 frontend

saa7133[0]: i2c xfer: < 14 00 [fd quirk] < 15 =05 =02 =09 =20 =01 >
nxt200x: NXT2004 Detected
saa7133[0]: i2c xfer: < c3 =7c >
tuner-simple 1-0061: attaching existing instance
tuner-simple 1-0061: type set to 68 (Philips TUV1236D ATSC/NTSC dual in)
DVB: registering new adapter (saa7133[0])
DVB: registering adapter 0 frontend 0 (Nextwave NXT200X VSB/QAM frontend)...
saa7133[0]: i2c xfer: < 14 1e 00 >
nxt2004: Waiting for firmware upload (dvb-fe-nxt2004.fw)...
saa7133[0]: i2c xfer: < 14 13 04 >
saa7133[0]: i2c xfer: < 14 16 00 >
saa7133[0]: i2c xfer: < 14 14 04 >
saa7133[0]: i2c xfer: < 14 17 00 >
saa7133[0]: i2c xfer: < 14 14 00 >
saa7133[0]: i2c xfer: < 14 17 00 >
saa7133[0]: i2c xfer: < c2 1b 6f ce 02 >
saa7133[0]: i2c xfer: < 14 10 12 >
saa7133[0]: i2c xfer: < 14 13 04 >
saa7133[0]: i2c xfer: < 14 16 00 >
saa7133[0]: i2c xfer: < 14 14 04 >
saa7133[0]: i2c xfer: < 14 17 00 >
saa7133[0]: i2c xfer: < 14 10 12 >
saa7133[0]: i2c xfer: < 14 13 04 >
saa7133[0]: i2c xfer: < 14 16 00 >
saa7133[0]: i2c xfer: < 14 14 04 >
saa7133[0]: i2c xfer: < 14 17 00 >
nxt2004: Waiting for firmware upload(2)...
saa7133[0]: i2c xfer: < 14 2b 80 >
saa7133[0]: i2c xfer: < 14 29 10 00 81 >
saa7133[0]: i2c xfer: < 14 2c 02 29 85 90 ff 21 e0 30 e5 1c 90 35 fe 74
01 f0 a3 e4 f0 7e 36 7f 00 12 2f 1d 90 ff 21 e0 54 df f0 7f 08 12 30 b0
22 00 00 00 00 02 33 cc c2 20 e4 ff 12 28 fd 7f 01 12 31 21 90 ff 08 e0
44 07 f0 e0 54 f8 f0 e4 ff 02 31 21 00 02 35 59 75 55 02 75 56 e4 e5 56
15 56 70 02 15 55 e5 56 45 55 70 f2 22 02 31 a6 02 12 a8 e8 64 80 f8 e9
33 e8 33 60 11 04 60 f0 ed 33 ec 33 70 09 e8 fc e9 fd ea fe eb ff 22 04
60 de d3 eb 9f ea 9e e9 9d e8 c2 e7 8c f0 c2 f7 95 f0 40 0c e8 cc f8 e9
cd f9 ea ce fa eb cf fb 12 12 73 85 d0 f0 58 04 70 03 20 d5 b3 e8 04 70
07 50 02 b2 d5 02 12 b2 92 d5 ec 04 60 f7 e4 cc c0 e0 c3 98 f8 60 3b 94
18 60 08 40 0d d0 e0 fb 02 12 8a e4 fb fa c9 fc 80 28 e8 30 e4 06 e4 c9
fb e4 ca fc e8 30 e3 05 e4 c9 ca cb fc e8 54 07 60 10 f8 c3 e9 13 f9 ea 13 >
saa7133[0]: i2c xfer: < 14 2c fa eb 13 fb ec 13 fc d8 f1 30 f5 2f c3 e4
9c fc ef 9b ff ee 9a fe ed 99 fd d0 e0 fb ef 4e 4d 4c 70 12 22 db 03 02
12 af ec 2c fc ef 33 ff ee 33 fe ed 33 fd ed 30 e7 eb 02 12 8a ef 2b ff
ee 3a fe ed 39 fd d0 e0 fb 50 13 0b bb 00 03 02 12 b2 ed 13 fd ee 13 fe
ef 13 ff ec 13 fc 02 12 8a 02 12 b2 ec 5d 04 60 05 e8 59 04 70 03 02 12
a8 12 12 73 58 04 60 f6 ec 48 60 f2 ec 70 04 fd fe ff 22 c8 60 db 24 81
c8 50 09 c3 98 60 02 50 06 02 12 af 98 50 ca f5 82 e9 29 4b 4a 70 05 ab
82 02 12 9e 75 f0 00 7c 1a 78 80 c3 ef 9b ee 9a ed 99 40 0d c3 ef 9b ff
ee 9a fe ed 99 fd e8 42 f0 dc 23 ac f0 d0 e0 ff d0 e0 fe d0 e0 fd ab 82
20 e7 10 1b eb 60 ba ec 2c fc ef 33 ff ee 33 fe ed 33 fd 02 12 8a e8 03
f8 30 e7 05 c0 f0 75 f0 00 ef 2f ff ee 33 fe ed 33 fd 40 b8 30 e7 c2 80 aa >
saa7133[0]: i2c xfer: < 14 2c 75 f0 20 80 0e 75 f0 10 80 05 75 f0 08 7d
00 7e 00 7f 00 33 92 d5 30 d5 03 12 13 12 ec 33 40 10 ef 33 ff ee 33 fe
ed 33 fd ec 33 fc d5 f0 ed 22 e5 f0 24 7e a2 d5 13 cc 92 e7 cd ce ff 22
ed d2 e7 cd 33 ec 33 92 d5 24 81 40 06 e4 ff fe fd fc 22 fc e4 cf ce cd
cc 24 e0 50 11 74 ff 80 ed c3 cc 13 cc cd 13 cd ce 13 ce cf 13 cf 04 70
f0 30 d5 de 02 13 12 e9 d2 e7 c9 33 e8 33 f8 92 d5 ed d2 e7 cd 33 ec 33
fc 50 02 b2 d5 22 ec 30 e7 10 0f bf 00 0c 0e be 00 08 0d bd 00 04 0b eb
60 14 a2 d5 eb 13 fc ed 92 e7 fd 22 74 ff fc fd fe ff 22 e4 80 f8 a2 d5
74 ff 13 fc 7d 80 e4 80 ef bc 00 0b be 00 29 ef 8d f0 84 ff ad f0 22 e4
cc f8 75 f0 08 ef 2f ff ee 33 fe ec 33 fc ee 9d ec 98 40 05 fc ee 9d fe
0f d5 f0 e9 e4 ce fd 22 ed f8 f5 f0 ee 84 20 d2 1c fe ad f0 75 f0 08 ef 2f >
saa7133[0]: i2c xfer: < 14 2c ff ed 33 fd 40 07 98 50 06 d5 f0 f2 22 c3
98 fd 0f d5 f0 ea 22 c3 e4 9f ff e4 9e fe e4 9d fd e4 9c fc 22 ec f0 a3
ed f0 a3 ee f0 a3 ef f0 22 a8 82 85 83 f0 d0 83 d0 82 12 13 43 12 13 43
12 13 43 12 13 43 e4 73 e4 93 a3 c5 83 c5 f0 c5 83 c8 c5 82 c8 f0 a3 c5
83 c5 f0 c5 83 c8 c5 82 c8 22 8a 83 89 82 e4 73 c9 ef c9 8c 0e 8d 0f 8a
10 8b 11 90 ff ab e0 f5 0b 90 ff 0a e0 33 92 34 30 34 11 e9 64 03 60 0c
e9 60 09 85 0f 82 85 0e 83 e4 f0 22 c2 33 75 0a 7c e9 b4 07 00 40 03 02
14 35 90 13 a4 f8 28 28 73 02 13 b9 02 13 df 02 13 ec 02 13 f7 02 14 16
02 14 21 02 14 2c e4 f5 08 75 09 0a 30 34 07 75 0a 20 d2 33 80 6c e5 0b
30 e5 05 75 0a 20 80 03 75 0a 3d e5 0b 20 e6 5a d2 33 80 56 75 08 20 75
09 3e d2 33 75 0a 20 80 49 75 08 40 75 09 4e 75 0a 20 80 3e 75 08 50 75 09 >
saa7133[0]: i2c xfer: < 14 2c 5e 30 34 07 75 0a 3c d2 33 80 2e e5 0b 30
e4 05 75 0a 40 80 24 75 0a 7c 80 1f 75 08 60 75 09 66 75 0a 5c 80 14 75
08 68 75 09 6a 75 0a 7c 80 09 75 08 6c 75 09 6e 75 0a 7c 30 33 0d e5 0a
25 e0 25 e0 f5 0b 43 0a 80 80 06 e5 0a 25 e0 f5 0b ad 0b af 11 ae 10 12
35 17 85 0f 82 85 0e 83 e5 0a f0 e9 60 03 02 15 10 e5 08 d3 95 09 40 03
02 15 10 e5 08 44 80 90 ff b1 f0 75 0c ff 75 0d b4 75 0a 04 85 0d 82 85
0c 83 e0 f5 0b 05 0d e5 0d 70 02 05 0c 30 33 1c e5 0b 25 e0 f5 0b 30 34
07 e5 08 d3 94 08 50 0a 20 34 09 e5 0a d3 94 02 50 02 05 0b e5 0b 25 e0
f5 0b 85 0d 82 85 0c 83 e0 ff e5 11 25 0b f5 82 e4 35 10 f5 83 ef f0 05
0d e5 0d 70 02 05 0c f5 82 85 0c 83 e0 ff e5 11 25 0b f5 82 e4 35 10 f5
83 a3 ef f0 05 0d e5 0d 70 02 05 0c 15 0a e5 0a 70 8a 05 08 05 08 20 34 03 >
saa7133[0]: i2c xfer: < 14 2c 02 14 63 e5 08 64 08 60 03 02 14 63 75 08
10 75 09 16 02 14 63 e9 64 01 60 03 02 15 95 e5 08 d3 95 09 50 76 e5 08
44 80 90 ff b1 f0 75 0c ff 75 0d b4 e5 08 24 e0 25 e0 25 e0 f5 0b e5 08
30 e1 06 74 fa 25 0b f5 0b 75 0a 04 05 0d e5 0d 70 02 05 0c f5 82 85 0c
83 e0 ff e5 11 25 0b f5 82 e4 35 10 f5 83 ef f0 05 0d e5 0d 70 02 05 0c
f5 82 85 0c 83 e0 ff e5 11 25 0b f5 82 e4 35 10 f5 83 a3 ef f0 05 0d e5
0d 70 02 05 0c 74 04 25 0b f5 0b d5 0a b6 05 08 05 08 80 83 e9 c3 94 02
50 03 02 16 2b e5 08 d3 95 09 40 03 02 16 2b e5 08 44 80 90 ff b1 f0 75
0c ff 75 0d b4 e4 f5 0a 85 0d 82 85 0c 83 e0 f5 0b 05 0d e5 0d 70 02 05
0c 30 34 03 63 0b 01 b9 02 0a e5 08 24 c0 25 e0 25 0a f5 0b e5 0b 25 e0
f5 0b 85 0d 82 85 0c 83 e0 ff e5 11 25 0b f5 82 e4 35 10 f5 83 ef f0 05 0d >
saa7133[0]: i2c xfer: < 14 2c e5 0d 70 02 05 0c f5 82 85 0c 83 e0 ff e5
11 25 0b f5 82 e4 35 10 f5 83 a3 ef f0 05 0d e5 0d 70 02 05 0c 05 0a e5
0a b4 04 95 05 08 05 08 02 15 9e 22 7c 24 7d d1 7b ff e4 ff 12 18 8f 90
ff 30 e0 30 e0 03 75 70 20 e5 70 60 03 02 17 ef 90 ff 3f e0 54 f0 f5 70
64 60 70 03 02 16 e7 e4 f5 60 ff 12 2c a0 12 2f b1 e4 f5 70 90 3e 00 e0
ff 7d 01 7c 3e 12 2c 39 c3 ef 94 50 ee 94 00 50 5e 90 3c 00 e0 ff 7d 01
7c 3c 12 2c 39 c3 ef 94 50 ee 94 00 50 1a 90 3b 00 e0 24 b6 ff 7d 95 7c
3b 12 2c 39 c3 ef 94 32 ee 94 00 50 03 75 70 10 90 3d 00 e0 ff 7d 01 7c
3d 12 2c 39 c3 ef 94 50 ee 94 00 50 1a 90 38 00 e0 24 f6 ff 7d 01 7c 38
12 2c 39 c3 ef 94 58 ee 94 02 50 03 43 70 20 e5 70 60 0c 44 02 ff 12 2c
a0 12 2f b1 e4 f5 70 90 ff 3f e0 54 f0 60 05 e0 54 f0 f5 70 e5 70 60 03 02 >
saa7133[0]: i2c xfer: < 14 2c 17 ef 75 70 30 90 3d 00 e0 ff 7d 01 7c 3d
12 2c 39 d3 ef 94 c8 ee 94 00 50 15 90 3e 00 e0 ff 7d 01 7c 3e 12 2c 39
d3 ef 94 c8 ee 94 00 40 06 75 70 50 02 17 ef 90 38 00 e0 ff 7d 01 7c 38
12 2c 39 c3 ef 94 c8 ee 94 00 50 73 90 3a 00 e0 ff 7d 01 7c 3a 12 2c 39
c3 ef 94 2c ee 94 01 50 5e 90 3b 00 e0 ff 7d 01 7c 3b 12 2c 39 c3 ef 94
c8 ee 94 00 50 49 90 3c 00 e0 ff 7d 01 7c 3c 12 2c 39 c3 ef 94 64 ee 94
00 50 34 90 3e 00 e0 ff 7d 01 7c 3e 12 2c 39 ee c0 e0 ef c0 e0 90 3d 00
e0 ff 7d 01 7c 3d 12 2c 39 d0 e0 2f ff d0 e0 3e fe c3 ef 94 64 ee 94 00
50 05 75 70 40 80 39 90 38 00 e0 ff 7d 01 7c 38 12 2c 39 d3 ef 94 f4 ee
94 01 40 05 75 70 10 80 1f 90 3a 00 e0 24 e5 ff 7d 01 7c 3a 12 2c 39 d3
ef 94 c8 ee 94 00 40 08 7f 32 12 2c a0 75 70 40 e5 70 24 e0 60 65 24 f0 60 >
saa7133[0]: i2c xfer: < 14 2c 42 24 f0 60 31 24 e0 60 47 24 10 70 73 90
ff a6 e0 fe a3 e0 c3 94 44 ee 94 02 50 0d 7c 2d 7d fa 7b ff e4 ff 12 18
8f 80 57 7c 2d 7d ed 7b ff e4 ff 12 18 8f 80 4a 7c 2e 7d 07 7b ff e4 ff
12 18 8f 80 3d 7c 2e 7d 17 7b ff e4 ff 12 18 8f 80 30 7f 32 12 2c a0 7c
2e 7d 07 7b ff e4 ff 12 18 8f 80 1e 7c 24 7d d1 7b ff e4 ff 12 18 8f 7f
01 12 2c a0 7c 2d 7d ca 7b ff e4 ff 12 18 8f 75 60 01 90 ff 3f e0 54 f0
f0 e0 ff e5 70 c4 54 0f fe ef 4e f0 7f 01 02 32 54 8f 66 8c 5b 8d 5c 8b
5d e5 5d 70 03 02 1a 65 85 5c 82 85 5b 83 e0 ff 54 1f f5 5a ef 54 e0 24
e0 70 03 02 19 ea 24 a0 60 76 24 e0 70 03 02 19 44 24 e0 70 03 02 19 9a
24 80 60 03 02 1a 65 05 5c e5 5c 70 02 05 5b e5 66 60 12 85 5c 82 85 5b
83 e0 24 00 f5 58 e4 34 fe f5 57 80 10 85 5c 82 85 5b 83 e0 24 00 f5 58 e4 >
saa7133[0]: i2c xfer: < 14 2c 34 ff f5 57 05 5c e5 5c 70 02 05 5b e5 5a
70 03 02 1a 60 85 5c 82 85 5b 83 e0 f5 59 85 58 82 85 57 83 f0 05 5c e5
5c 70 02 05 5b 05 58 e5 58 70 02 05 57 15 5a 80 d5 e5 5a 60 07 12 10 4e
15 5a 80 f5 05 5c e5 5c 70 02 05 5b 02 1a 60 05 5c e5 5c 70 02 05 5b e5
66 60 12 85 5c 82 85 5b 83 e0 24 00 f5 58 e4 34 fe f5 57 80 10 85 5c 82
85 5b 83 e0 24 00 f5 58 e4 34 ff f5 57 e5 5a 60 19 05 5c e5 5c 70 02 05
5b f5 82 85 5b 83 e0 85 58 82 85 57 83 f0 15 5a 80 e3 05 5c e5 5c 70 02
05 5b 02 1a 60 05 5c e5 5c 70 02 05 5b e5 66 60 12 85 5c 82 85 5b 83 e0
24 00 f5 58 e4 34 fe f5 57 80 10 85 5c 82 85 5b 83 e0 24 00 f5 58 e4 34
ff f5 57 e5 5a 60 14 85 58 82 85 57 83 e4 f0 05 58 e5 58 70 02 05 57 15
5a 80 e8 05 5c e5 5c 70 7a 05 5b 80 76 05 5c e5 5c 70 02 05 5b e5 66 60 12 >
saa7133[0]: i2c xfer: < 14 2c 85 5c 82 85 5b 83 e0 24 00 f5 58 e4 34 fe
f5 57 80 10 85 5c 82 85 5b 83 e0 24 00 f5 58 e4 34 ff f5 57 e5 5a 60 3c
85 58 82 85 57 83 e0 f5 59 05 5c e5 5c 70 02 05 5b f5 82 85 5b 83 e0 52
59 05 5c e5 5c 70 02 05 5b f5 82 85 5b 83 e0 45 59 85 58 82 85 57 83 f0
05 58 e5 58 70 02 05 57 15 5a 80 c0 05 5c e5 5c 70 02 05 5b 15 5d 02 18
97 22 90 ff 22 e0 f5 21 30 0f 18 30 2c 03 02 1b c7 d2 2c 12 10 2e d2 2b
12 35 61 90 ff 31 e0 44 10 f0 22 c2 2c 90 ff 31 e0 54 ef f0 90 ff 30 e0
54 03 f5 64 20 2b 07 65 5f 70 03 02 1b 45 c2 2b 12 10 2e d2 20 e5 64 60
65 14 60 62 24 fe 60 32 04 60 03 02 1b 3c 90 35 e6 74 ff f0 a3 74 34 f0
a3 74 e7 f0 90 35 e3 74 ff f0 a3 74 33 f0 a3 74 96 f0 90 35 e0 74 ff f0
a3 74 26 f0 a3 74 1e f0 80 56 90 35 e6 74 ff f0 a3 74 34 f0 a3 74 f7 f0 90 >
saa7133[0]: i2c xfer: < 14 2c 35 e3 74 ff f0 a3 74 33 f0 a3 74 b1 f0 90
35 e0 74 ff f0 a3 74 21 f0 a3 74 8a f0 80 2a 90 35 e6 74 ff f0 a3 74 34
f0 a3 74 d5 f0 90 35 e3 74 ff f0 a3 74 16 f0 a3 74 2c f0 90 35 e0 74 ff
f0 a3 74 20 f0 a3 74 9e f0 d2 17 c2 16 c2 15 85 64 5f 30 17 0f 7f 01 12
31 21 90 35 e6 12 31 15 c2 17 d2 16 30 16 26 20 0e 23 7f 01 12 31 21 90
35 e3 12 31 15 c2 16 d2 15 d2 2d 90 ff 31 e0 f5 5e 53 5e fc e5 60 54 03
42 5e e5 5e f0 30 15 31 20 0d 29 90 35 e0 e0 a3 e0 fa a3 e0 f9 12 13 5d
8f 63 e5 63 70 0a c2 15 7f 03 12 28 fd 12 10 2e e5 63 b4 01 0c 7f 02 12
28 fd 80 05 7f 01 12 28 fd 20 17 10 20 16 0d 20 15 0a 20 0c 07 7f 02 12
32 54 d2 17 22 90 ff 21 e0 20 e7 03 02 1d 1f 90 ff 34 e0 54 f0 f5 72 e0
54 0f f5 71 90 ff 21 e0 54 f7 f0 e5 72 24 f0 60 6e 24 f0 60 77 24 f0 70 03 >
saa7133[0]: i2c xfer: < 14 2c 02 1c 7e 24 f0 70 03 02 1c d2 24 f0 70 03
02 1c e8 24 f0 70 03 02 1d 02 24 f0 70 03 02 1d 07 24 70 60 03 02 1d 0c
90 ff 35 e0 30 e0 1b e0 ff 7b 36 7a ff ad 71 12 30 76 ef 70 03 02 1d 13
90 ff 21 e0 44 08 f0 02 1d 13 90 ff 35 e0 ff 7b 36 7a ff ad 71 12 31 d4
ef 70 03 02 1d 13 90 ff 21 e0 44 08 f0 02 1d 13 90 ff 35 e0 f5 47 a3 e0
f5 46 02 1d 13 90 ff 35 e0 24 00 ff e4 34 ff fe ab 71 7d 36 7c ff 12 34
2e 02 1d 13 75 73 36 90 ff 35 e0 f5 74 e5 71 70 03 02 1d 13 e4 25 73 ff
e4 34 ff 8f 82 f5 83 e0 f5 72 e5 74 b4 08 0b 53 72 f8 90 ff 08 e0 54 07
42 72 e5 74 b4 09 0b 53 72 f9 90 ff 09 e0 54 06 42 72 e4 25 74 ff e4 34
ff 8f 82 f5 83 e5 72 f0 05 73 05 74 15 71 80 b5 90 ff 35 e0 24 00 ff e4
34 fe fe ab 71 7d 36 7c ff 12 34 2e 80 2b 90 ff 35 e0 24 00 ff e4 34 fe fe >
saa7133[0]: i2c xfer: < 14 2c cd ef cd fc ab 71 7f 36 7e ff 12 34 2e 80
11 12 2a 0b 80 0c 12 2d 06 80 07 90 ff 21 e0 44 08 f0 90 ff 21 e0 54 7f
f0 7f 10 12 30 b0 22 e5 2d 24 80 70 03 02 1d b4 24 e0 70 03 02 1e 08 24
40 60 03 02 1e 6d 12 33 e5 8f 66 e5 66 d3 95 27 40 06 85 66 27 85 3f 34
05 3f 05 3f c3 e5 3f 64 80 94 90 40 58 e4 f5 33 90 35 f1 e0 54 c0 60 2f
e5 2b d3 94 00 40 0e e5 27 d3 94 5f 40 07 15 2b 75 2d 80 80 1d e5 2b c3
94 03 50 0e e5 27 c3 94 46 50 07 05 2b 75 2d 80 80 08 75 2d a0 80 03 75
2d a0 e5 2d b4 80 05 85 34 3f 80 11 85 3f 3e e5 34 70 05 75 3f 0f 80 05
e5 34 14 f5 3f 75 3d 04 02 1e 6d 12 33 e5 8f 66 05 33 e5 33 c3 94 02 50
11 e5 2b 94 00 40 0b e5 66 d3 94 5f 40 04 15 2b 80 30 e5 33 c3 94 02 50
12 e5 2b c3 94 03 50 0b e5 66 c3 94 46 50 04 05 2b 80 17 85 3f 3e e5 34 70 >
saa7133[0]: i2c xfer: < 14 2c 05 75 3f 0f 80 05 e5 34 14 f5 3f e4 f5 33
75 2d a0 75 3d 04 80 65 12 24 1d d3 ef 95 2a ee 95 29 40 07 8e 29 8f 2a
85 3f 3e 05 33 e5 33 c3 94 03 50 0f 05 3f e5 3f b4 10 03 e4 f5 3f 75 3d
04 80 3a 85 3e 3f 78 82 e6 90 ff 46 f0 78 7f e6 90 ff 42 f0 08 e6 ff 08
e6 90 ff 5c cf f0 a3 ef f0 90 ff 22 e5 32 f0 e4 f5 2d 53 28 fd 75 36 01
75 37 45 85 3f 35 f5 3a f5 30 75 3d 0a 02 2a 82 8c 65 8d 66 8f 82 8e 83
e4 f5 67 f5 68 f5 69 75 6a 40 74 9e f0 7d 78 af 66 ae 65 12 35 17 e4 ff
fe 90 fe 72 ef f0 a3 e0 fd 05 68 e5 68 aa 67 70 02 05 67 14 25 66 f5 82
e5 65 3a f5 83 ed f0 90 fe 74 e0 fd 05 68 e5 68 aa 67 70 02 05 67 14 25
66 f5 82 e5 65 3a f5 83 ed f0 90 fe 75 e0 fd 05 68 e5 68 aa 67 70 02 05
67 14 25 66 f5 82 e5 65 3a f5 83 ed f0 90 fe 76 e0 fd 05 68 e5 68 aa 67 70 >
saa7133[0]: i2c xfer: < 14 2c 02 05 67 14 25 66 f5 82 e5 65 3a f5 83 ed
f0 74 10 2f ff e4 3e fe d3 ef 94 f0 ee 64 80 94 80 50 03 02 1e 91 e4 fe
ff 90 fe 72 ef f0 90 fe 77 e0 fd 05 6a e5 6a aa 69 70 02 05 69 14 25 66
f5 82 e5 65 3a f5 83 ed f0 90 fe 78 e0 fd 05 6a e5 6a aa 69 70 02 05 69
14 25 66 f5 82 e5 65 3a f5 83 ed f0 90 fe 79 e0 fd 05 6a e5 6a aa 69 70
02 05 69 14 25 66 f5 82 e5 65 3a f5 83 ed f0 90 fe 7a e0 fd 05 6a e5 6a
aa 69 70 02 05 69 14 25 66 f5 82 e5 65 3a f5 83 ed f0 0f bf 00 01 0e ef
64 10 4e 70 84 22 cd eb cd cc ea cc 8c 51 8d 52 90 ff 90 74 18 f0 e4 f5
4d f5 4e f5 4f f5 50 c3 e5 4d 94 01 40 0b e4 25 4e f5 4e 74 ff 35 4d f5
4d e5 4e 24 40 f5 4c e4 35 4d f5 4b c3 94 01 40 0b e4 25 4c f5 4c 74 ff
35 4b f5 4b c3 e5 50 94 0c e5 4f 94 00 50 0e ae 50 ee 24 31 90 ff b0 f0 a3 >
saa7133[0]: i2c xfer: < 14 2c ee f0 80 08 e5 50 24 14 90 ff b1 f0 d3 e5
4c 94 80 e5 4b 94 00 50 10 e5 4c 90 27 5d 93 90 ff b2 f0 a3 74 20 f0 80
18 74 dd 25 4c f5 82 74 26 35 4b f5 83 e4 93 f4 04 90 ff b2 f0 a3 74 2f
f0 d3 e5 4e 94 80 e5 4d 94 00 50 10 e5 4e 90 27 5d 93 90 ff b2 f0 a3 74
60 f0 80 18 74 dd 25 4e f5 82 74 26 35 4d f5 83 e4 93 f4 04 90 ff b2 f0
a3 74 6f f0 ef 25 4e f5 4e e4 35 4d f5 4d 05 50 e5 50 70 02 05 4f 64 2c
45 4f 60 03 02 1f ae 90 ff 90 74 38 f0 12 35 25 90 ff a6 e0 85 52 82 85
51 83 f0 90 ff a7 e0 85 52 82 85 51 83 a3 f0 22 75 66 01 30 2d 4e c2 2d
e4 f5 6d 75 65 64 90 ff 22 e0 20 e7 0e 90 ff 9f e0 54 0c 70 06 12 10 4e
d5 65 eb e5 65 70 0e f5 66 05 6c e5 6c d3 94 02 50 03 e4 f5 70 7f 01 12
25 78 12 35 69 c2 32 e4 f5 6e 90 ff 22 e0 30 e7 03 02 21 87 90 ff f2 e4 f0 >
saa7133[0]: i2c xfer: < 14 2c 02 21 87 20 32 03 02 21 84 c2 32 90 ff 9f
e0 30 e0 31 75 65 19 e5 65 60 0c 12 10 4e 15 65 90 ff 9f e0 20 e0 f0 e5
65 70 1a f5 66 05 6c e5 6d c3 94 32 40 05 e4 f5 6c 80 0a e5 6c d3 94 02
50 03 e4 f5 70 e5 66 64 01 70 4f 05 6e e5 6e d3 94 06 40 37 15 6e e4 ff
12 25 78 ef 70 0b e5 6d c3 94 3c 50 0d 05 6d 80 09 e5 6d d3 94 00 40 02
15 6d ef d3 94 03 40 22 e4 f5 66 e5 6d 94 32 40 05 e4 f5 6c 80 14 75 6c
03 80 0f e5 6e b4 06 0a 7f 01 12 25 78 80 03 75 66 02 af 66 22 30 2d 16
c2 2d 7f 01 12 25 78 12 35 69 c2 32 90 ff ee 74 07 f0 a3 74 98 f0 20 32
03 02 22 6d 90 ff f0 e0 d3 94 40 40 08 90 ff ed 74 1f f0 80 06 90 ff ed
74 a5 f0 c2 32 e4 ff 12 25 78 12 31 46 90 ff a1 e0 54 f3 f5 76 90 ff e3
e0 f5 75 c4 54 0f ff c3 13 04 f5 75 c2 30 c3 e5 78 94 3f e5 77 94 00 50 45 >
saa7133[0]: i2c xfer: < 14 2c 30 2e 3e e5 75 b4 01 0c 43 76 0c 90 ff a2
74 01 f0 a3 e4 f0 e5 75 64 02 60 05 e5 75 b4 03 0a 90 ff a2 74 01 f0 a3
74 80 f0 e5 75 c3 94 04 40 09 90 ff a2 74 01 f0 a3 e4 f0 90 ff a1 e5 76
f0 d2 30 d2 2e 80 19 20 2e 14 43 76 04 90 ff a2 e4 f0 a3 74 80 f0 90 ff
a1 e5 76 f0 d2 30 c2 2e 30 30 07 90 ff 90 e0 44 40 f0 90 ff db e0 20 e1
0d 12 10 4e 90 ff db e0 20 e1 03 7f 00 22 7f 01 22 7f 02 22 90 ff 9f e0
30 e0 10 05 3a e5 3a d3 94 04 40 03 02 2b 66 75 3d 0a 22 e4 f5 3a 90 ff
a1 e0 ff 54 fc f0 90 ff a6 e0 f5 66 a3 e0 f5 67 90 ff a1 ef f0 e5 30 14
60 75 04 60 03 02 23 4a d3 e5 67 94 8d e5 66 94 02 50 2e e5 67 94 45 e5
66 94 01 40 45 74 8d 95 37 cf 74 02 95 36 cf 25 37 cf 35 36 fe ef 78 02
ce c3 13 ce 13 d8 f9 ff d3 e5 67 9f e5 66 9e 40 21 85 66 3b 85 67 3c 85 66 >
saa7133[0]: i2c xfer: < 14 2c 36 85 67 37 85 3f 35 e5 3f 25 2f 54 0f f5
3f 12 2a 82 75 30 01 75 3d 05 22 c3 e5 67 95 37 e5 66 95 36 50 06 85 66
36 85 67 37 75 3d 0a 22 c3 e5 67 95 3c e5 66 95 3b 50 0d 85 66 36 85 67
37 e4 f5 30 75 3d 0a 22 c3 e4 95 2f f5 2f e4 95 2e f5 2e 85 35 3f 12 2a
82 e4 f5 30 75 3d 05 22 21 08 f8 07 21 0a 3f c0 21 08 f8 00 45 66 00 4b
09 89 c4 41 87 00 a2 af 4c 00 41 c4 01 41 c6 30 41 c4 02 41 c6 31 41 c4
03 41 c6 32 41 c4 04 41 c6 33 41 c4 05 41 c6 34 41 c4 06 41 c6 35 41 c4
07 41 c6 36 41 c4 08 41 c6 37 44 b0 1b 05 00 66 41 a1 00 41 90 48 41 a0
c0 00 44 62 61 a8 00 64 41 60 c1 8a 44 62 09 c4 00 0a 8a 44 62 03 e8 00
02 82 41 61 01 41 90 68 81 44 a2 01 80 00 06 41 90 68 9e 94 44 a2 00 80
00 02 41 90 68 94 41 92 58 41 97 48 41 90 68 41 ac 55 42 ad 00 80 8f 41 c0 >
saa7133[0]: i2c xfer: < 14 2c 40 82 41 92 38 41 97 38 41 90 68 85 44 a2
00 80 00 01 41 90 68 85 41 c7 03 41 a1 04 41 90 65 8a 42 ad 04 00 41 ac
77 41 92 28 41 97 28 41 90 65 00 90 35 f4 12 13 2c 00 00 00 00 12 31 77
e4 f5 67 e4 f5 68 e5 68 60 03 b4 40 07 e5 67 25 68 ff 80 08 e5 68 24 1f
c3 95 67 ff 7c 35 7d f2 12 1f 9b 90 35 f4 e0 f8 a3 e0 f9 a3 e0 fa a3 e0
fb e8 c0 e0 e9 c0 e0 ea c0 e0 eb c0 e0 90 35 f2 e0 fc a3 e0 fd e4 12 12
03 c8 ec c8 c9 ed c9 ca ee ca cb ef cb e4 ff fe 7d 80 7c 3f 12 11 61 d0
e0 fb d0 e0 fa d0 e0 f9 d0 e0 f8 12 10 6d 90 35 f4 12 13 20 74 20 25 68
f5 68 c3 94 80 40 87 05 67 e5 67 c3 94 20 50 03 02 24 2d 90 35 f4 e0 f8
a3 e0 f9 a3 e0 fa a3 e0 fb e4 ff fe 7d c8 7c 42 12 11 61 12 12 3c 22 21
08 f8 07 21 0a 3f 00 21 08 f8 00 a2 af 6c 20 41 ab 00 43 b1 35 00 36 43 b1 >
saa7133[0]: i2c xfer: < 14 2c 35 00 70 00 50 77 02 b8 01 88 01 07 01 39
03 9c 02 0a 00 5a 02 3c 21 60 f9 06 00 41 f2 04 8a 44 62 61 a8 00 64 44
6f 61 a8 00 64 21 60 fe 01 8a 44 62 09 c4 00 0a 44 6f 09 c4 00 0a 8a 44
62 03 e8 00 02 85 21 90 9f 60 81 44 a2 00 80 00 00 21 90 bf 40 87 49 92
44 44 44 44 55 55 55 55 55 21 90 bf 40 21 ab f8 06 41 ac 44 42 ad 00 80
8a 41 c0 40 94 44 a2 00 40 00 00 45 96 44 44 44 44 44 21 90 bf 40 8a 41
c7 03 21 90 fd 02 00 ef 60 11 90 ff e8 e0 f5 7a 75 7b 02 e4 f5 79 f5 7a
02 26 14 90 ff e8 e0 f5 7a ff 90 ff 33 e0 2f ff e4 33 fe c3 ef 95 7a 74
80 f8 6e 98 40 06 e0 25 7a f0 80 06 90 ff 33 74 ff f0 e5 7a d3 94 32 40
08 74 03 25 79 f5 79 80 22 e5 7a d3 94 0a 40 06 05 79 05 79 80 15 e5 7a
d3 94 02 40 04 05 79 80 0a e5 7a 70 06 e5 79 60 02 15 79 e5 7a 70 08 e5 7b >
saa7133[0]: i2c xfer: < 14 2c 60 0c 15 7b 80 08 75 7b 02 7f 40 12 32 54
e5 7b 70 05 7f 80 12 32 54 e5 79 c3 94 03 40 07 7f 10 12 32 54 80 05 7f
20 12 32 54 e5 79 30 e7 02 15 79 af 79 22 30 2d 16 c2 2d 7f 01 12 25 78
12 35 69 c2 32 90 ff ee 74 05 f0 a3 74 48 f0 20 32 03 02 26 bd c2 32 90
ff f0 e0 d3 94 40 40 08 90 ff ed 74 1f f0 80 06 90 ff ed 74 a5 f0 e4 ff
12 25 78 12 31 46 90 ff a1 e0 54 f3 f5 76 c2 30 c3 e5 78 94 70 e5 77 94
00 50 10 30 2e 09 a3 74 01 f0 a3 e4 f0 d2 30 d2 2e 80 13 20 2e 0e 43 76
0c 90 ff a2 e4 f0 a3 74 80 f0 d2 30 c2 2e 30 30 0d 90 ff a1 e5 76 f0 90
ff 90 e0 44 40 f0 90 ff db e0 20 e1 0d 12 10 4e 90 ff db e0 20 e1 03 7f
00 22 7f 01 22 7f 02 22 90 ff 22 e0 f5 23 30 1b 15 30 2a 03 02 27 5c d2
2a 12 35 4f d2 28 90 ff 31 e0 44 40 f0 22 c2 2a 90 ff 31 e0 54 bf f0 90 ff >
saa7133[0]: i2c xfer: < 14 2c 30 e0 54 c0 f5 49 20 28 04 65 4a 60 17 c2
28 90 fe 41 e0 f5 41 e4 78 83 f6 08 f6 d2 29 c2 27 85 49 4a d2 23 30 29
0b 12 2d 6a c2 29 d2 27 d2 26 80 2c 30 27 29 20 1a 26 12 2f f4 8f 48 e5
48 70 07 c2 27 7f 03 12 2e ce e5 48 b4 01 05 7f 02 12 2e ce 20 18 09 e5
48 64 02 60 03 12 2e 7c 20 29 12 20 27 0f 20 19 0c 12 35 4f d2 29 90 ff
32 e0 44 08 f0 22 00 03 06 09 0c 10 13 16 19 1c 1f 22 25 28 2b 2e 31 33
36 39 3c 3f 41 44 47 49 4c 4e 51 53 55 58 5a 5c 5e 60 62 64 66 68 6a 6b
6d 6f 70 71 73 74 75 76 78 79 7a 7a 7b 7c 7d 7d 7e 7e 7e 7f 7f 7f 7f 7f
7f 7f 7e 7e 7e 7d 7d 7c 7b 7a 7a 79 78 76 75 74 73 71 70 6f 6d 6b 6a 68
66 64 62 60 5e 5c 5a 58 55 53 51 4e 4c 49 47 44 41 3f 3c 39 36 33 31 2e
2b 28 25 22 1f 1c 19 16 13 10 0c 09 06 03 00 0b 04 34 3a 40 46 4c 52 58 5e >
saa7133[0]: i2c xfer: < 14 2c 16 12 31 77 e4 90 35 f8 f0 a3 f0 a3 f0 a3
f0 f5 53 75 54 02 90 35 fa e0 fe a3 e0 ff c3 74 ff 9f ff 74 ff 9e fe 90
35 f8 e0 fc a3 e0 fd d3 9f ec 9e 40 03 7f 00 22 90 35 fb e0 2d f0 90 35
fa e0 3c f0 e5 54 90 27 de 93 ff 7c 35 7d f8 12 1f 9b 05 54 e5 54 70 02
05 53 90 27 de e4 93 ff c3 e5 54 9f e5 53 94 00 40 ac 90 35 fa e0 fe a3
e0 78 02 c3 33 ce 33 ce d8 f9 ff d3 90 35 f9 e0 9f 90 35 f8 e0 9e 40 03
7f 01 22 7f 00 22 21 08 f8 07 21 0a 3f 80 21 08 f8 00 45 66 00 4f 8a ca
de 41 87 00 a2 af 4c 00 44 b0 1b 05 00 66 41 a1 00 41 90 48 41 a0 c0 00
44 62 61 a8 00 64 41 60 c1 8a 44 62 09 c4 00 0a 8a 44 62 03 e8 00 02 82
41 61 01 41 90 68 81 44 a2 00 80 00 01 41 90 68 91 41 92 48 41 97 58 41
90 68 41 ac 55 42 ad 00 40 8f 41 c0 40 82 41 92 38 41 97 38 41 90 68 85 44 >
saa7133[0]: i2c xfer: < 14 2c a2 00 80 00 01 41 90 68 85 41 c7 03 41 a1
04 41 ac 77 41 90 65 00 c2 21 ef 14 60 0b 14 60 33 24 02 70 31 c2 22 80
2d 90 ff 0a e0 30 e7 19 90 ff d0 e0 30 e3 1f 90 ff db e0 30 e1 18 90 ff
eb e0 30 e1 11 d2 21 80 0d 90 ff 9f e0 20 e0 06 d2 21 80 02 d2 21 30 21
0e 90 ff 31 e0 44 20 f0 7f 04 12 32 54 80 11 90 ff 31 e0 54 df f0 7f 08
12 32 54 7f 80 12 32 54 20 20 08 a2 22 30 21 01 b3 50 1c 90 ff 22 e0 20
e7 15 c2 20 30 21 07 7f 80 12 30 b0 80 05 7f 40 12 30 b0 a2 21 92 22 22
75 81 c0 02 29 c6 02 34 b0 e4 93 a3 f8 e4 93 a3 40 03 f6 80 01 f2 08 df
f4 80 29 e4 93 a3 f8 54 07 24 0c c8 c3 33 c4 54 0f 44 20 c8 83 40 04 f4
56 80 01 46 f6 df e4 80 0b 01 02 04 08 10 20 40 80 90 33 40 e4 7e 01 93
60 bc a3 ff 54 3f 30 e5 09 54 1f fe e4 93 a3 60 01 0e cf 54 c0 25 e0 60 a8 >
saa7133[0]: i2c xfer: < 14 2c 40 b8 e4 93 a3 fa e4 93 a3 f8 e4 93 a3 c8
c5 82 c8 ca c5 83 ca f0 a3 c8 c5 82 c8 ca c5 83 ca df e9 de e7 80 be e4
f5 65 90 ff 35 e0 24 fd 60 18 14 60 2b 24 fe 60 36 14 60 42 24 07 70 4e
e5 28 25 2d 90 ff 36 f0 80 47 e5 28 20 e0 05 75 65 01 80 3d e5 38 90 ff
36 f0 e5 39 a3 f0 80 31 7e 35 7f e9 7b 09 7d 36 7c ff 12 34 2e 80 22 90
ff 36 e4 f0 12 33 e5 90 ff 37 ef f0 80 13 12 24 1d cc ee cc ec 90 ff 36
f0 ef a3 f0 80 03 75 65 01 e5 65 b4 01 07 90 ff 21 e0 44 08 f0 22 e5 3f
54 0f ff a2 e7 13 ff 24 e9 f5 82 e4 34 35 f5 83 e0 fd 7c 00 e5 3f 30 e0
0a ed 7d 00 25 e0 25 e0 fc 80 11 ed ce ec ce 78 06 c3 33 ce 33 ce d8 f9
fd cc ee cc 7d 00 cc 54 3c cc e5 2b 54 03 fb 7a 00 7e 00 78 07 c3 33 ce
33 ce d8 f9 fb ca ee ca cd 4d cd ea cc 4c cc e5 2c 60 04 cc 44 02 cc e5 31 >
saa7133[0]: i2c xfer: < 14 2c 54 7f cd 4d cd e4 cf ed cf ce ec ce 02 2a
f4 8e 68 8f 69 e4 f5 6b e5 28 20 e0 05 75 6b 01 80 5e 43 68 40 7f 03 7e
01 12 34 88 7f 4f 7e 00 12 34 9c 75 6a 0e 74 01 7e 00 a8 6a 08 80 05 c3
33 ce 33 ce d8 f9 ff e5 68 5e fe e5 69 5f 4e 60 10 7f 39 7e 00 12 34 88
7f 14 7e 00 12 34 9c 80 0e 7f 1c 7e 00 12 34 88 7f 30 7e 00 12 34 9c 15
6a c3 e5 6a 64 80 94 80 50 bc 85 68 38 85 69 39 af 6b 22 e5 28 30 e0 63
20 e1 5d 90 ff 22 e0 f5 32 44 80 f0 90 ff 46 e0 78 82 f6 90 ff 42 e0 78
7f f6 90 ff 5c e0 ff a3 e0 08 cf f6 08 ef f6 90 ff 46 74 3f f0 90 ff 42
74 70 f0 90 ff 5c 74 66 f0 a3 e4 f0 f5 27 f5 29 f5 2a f5 3f 90 35 f1 e0
54 c0 60 05 75 2b 03 80 03 e4 f5 2b 12 2a 82 75 3d 04 75 2d 60 43 28 02
7f 00 22 7f 01 22 90 ff 36 e0 70 07 53 28 f2 d2 b7 80 54 e5 28 54 09 70 4e >
saa7133[0]: i2c xfer: < 14 2c c2 b7 12 10 4e e4 f5 66 f5 67 7f c4 7e 00
12 34 88 7f 3a 7e 00 12 34 88 05 67 e5 67 70 02 05 66 c3 94 03 e5 66 94
00 40 e1 7f c4 7e 00 12 34 9c 7f 3a 7e 00 12 34 9c 75 28 01 e4 f5 3f 75
2b 03 f5 2c 75 31 02 12 2a 82 75 28 08 75 3d 14 90 ff 46 74 3f f0 22 cb
ef cb eb 30 e7 03 25 e0 fb e4 f5 12 f5 13 eb 60 50 8d 82 8c 83 e0 f5 14
a3 e0 f5 15 c3 e5 14 64 80 94 80 50 0b c3 e4 95 15 f5 15 e4 95 14 f5 14
c3 74 ff 95 13 ff 74 ff 95 12 fe c3 e5 15 9f e5 14 9e 50 0e e5 15 25 13
f5 13 e5 14 35 12 f5 12 80 05 7e ff 7f ff 22 74 02 2d fd e4 3c fc 1b 80
ad ae 12 af 13 22 8f 65 e5 65 54 0f 24 fe 60 23 04 70 43 7c 24 7d ef 7b
ff e4 ff 12 18 8f 90 ff ab 74 40 f0 90 ff cb 74 43 f0 90 ff 61 e0 44 80
f0 80 23 e5 65 30 e4 06 90 ff ab 74 10 f0 e5 65 30 e5 07 90 ff ab e0 44 20 >
saa7133[0]: i2c xfer: < 14 2c f0 e5 65 30 e6 07 90 ff ab e0 44 40 f0 7c
33 7d 33 7b ff e4 ff 12 18 8f 7c 25 7d 06 7b ff e4 ff 02 18 8f e4 f5 65
90 ff 35 e0 14 60 12 14 60 16 14 60 1a 14 60 32 24 04 70 3d 12 2b d1 80
3b 12 2b 66 8f 65 80 34 12 32 2a 8f 65 80 2d 90 ff 36 e0 fd 7c 00 7d 00
fc a3 e0 fd e4 cf ed cf ce ec ce 12 2a f4 8f 65 80 12 7c 35 7d e9 7b 09
7f 36 7e ff 12 34 2e 80 03 75 65 01 e5 65 b4 01 07 90 ff 21 e0 44 08 f0
22 12 33 fe e5 49 24 c0 60 1e 24 c0 60 2a 24 80 70 3a 90 fe 4e 74 06 f0
a3 74 82 f0 a3 74 42 f0 90 fe 7c 74 f1 f0 80 24 90 fe 4e 74 0e f0 a3 74
41 f0 a3 74 21 f0 80 14 90 fe 4e 74 17 f0 a3 74 62 f0 a3 74 34 f0 90 fe
7c 74 c1 f0 90 fe 4c e5 47 f0 a3 e5 46 f0 7c 30 7d 3b 7b ff 7f 01 02 18
8f c9 92 21 90 bf 40 41 c7 0f 21 61 3f 40 00 c9 92 44 a2 00 00 00 00 21 ab >
saa7133[0]: i2c xfer: < 14 2c f8 07 21 90 bf 40 21 61 3f 40 00 42 99 55
55 21 90 bf 40 42 ad 00 20 00 42 99 77 77 21 90 bf 40 42 ad 00 01 00 49
92 23 33 33 33 33 33 33 23 23 21 90 bf 40 00 43 96 44 55 55 21 90 bf 40
21 61 3f 80 00 90 ff 3f e0 54 f0 60 06 e4 f5 70 f5 6c 22 e5 70 b4 40 0b
e5 6f 70 07 75 6f 01 75 70 30 22 e5 70 b4 30 0b e5 6f 70 07 75 6f 01 75
70 40 22 e5 70 b4 60 13 90 ff 30 e0 30 e2 08 e4 f5 70 f5 6c f5 6f 22 75
70 20 22 e5 70 b4 20 08 e4 f5 70 f5 6c f5 6f 22 75 70 60 22 78 84 e6 ff
c4 54 f0 90 ff 32 f0 90 fe 6e e0 fc a3 e0 c3 94 8c ec 94 02 50 0d e5 48
b4 01 08 ef c3 94 04 50 2c 06 22 ef d3 94 00 40 03 78 84 16 78 84 e6 c3
94 02 50 19 18 06 e6 c3 94 05 40 02 e4 f6 78 83 e6 24 41 f8 e6 90 fe 41
f0 e4 78 84 f6 22 c2 24 ef 24 fe 60 08 24 02 70 06 c2 25 80 02 d2 24 30 24 >
saa7133[0]: i2c xfer: < 14 2c 0e 90 ff 31 e0 44 80 f0 7f 84 12 32 54 80
0c 90 ff 31 e0 54 7f f0 7f 88 12 32 54 20 23 08 a2 25 30 24 01 b3 50 15
c2 23 30 24 07 7f 02 12 30 b0 80 05 7f 01 12 30 b0 a2 24 92 25 22 cb ef
cb ca ee ca 12 31 77 75 53 00 75 54 3f e5 54 f4 04 ff 12 1f 95 74 02 2b
fb e4 3a fa e5 54 15 54 70 02 15 53 e5 54 45 53 70 e3 d3 e5 54 94 c0 e5
53 94 00 50 16 af 54 12 1f 95 74 02 2b fb e4 3a fa 05 54 e5 54 70 e3 05
53 80 df 22 90 ff 19 e0 f5 20 20 03 0b 7c 33 7d 21 7b ff e4 ff 12 18 8f
12 34 5c 90 ff 27 e4 f0 74 1f f0 c2 35 75 47 07 75 46 fe 12 34 c3 12 1a
66 12 30 e3 90 ff 19 e0 f5 20 30 02 ee 20 35 05 12 34 72 d2 35 12 26 c0
80 e1 7b 01 7a 38 7d 00 7c 38 e4 ff 12 13 63 0a 7d 00 0c 7f 01 12 13 63
0a 7d 00 0c 7f 02 12 13 63 0a 7d 00 0c 7f 03 12 13 63 0a 7d 00 0c 7f 04 12 >
saa7133[0]: i2c xfer: < 14 2c 13 63 0a 7d 00 0c 7f 05 12 13 63 0a 7d 00
0c 7f 06 02 13 63 30 26 07 c2 26 c2 31 e4 f5 7d 30 31 32 c2 31 90 fe 6e
e0 fe a3 e0 d3 94 08 ee 94 04 40 15 12 10 4e 90 fe 6e e0 fe a3 e0 d3 94
08 ee 94 04 40 03 7f 00 22 90 fe 5d e0 c3 94 45 50 03 7f 01 22 7f 02 22
21 7b fd 06 00 21 7b 00 07 81 9e 94 21 4e f9 00 44 51 06 86 54 ba 85 44
62 25 60 54 28 85 44 51 01 4d 03 66 44 62 03 a5 00 a6 8a 41 61 ad 21 60
ff 60 41 5f 25 8a 9e 9e 9e 9e 9e 21 4e ff 06 00 12 34 16 ef 44 01 ff 12
32 a1 ef 60 03 7f 01 22 19 e9 60 14 12 32 7d 8b 82 8a 83 ef f0 12 35 33
0b bb 00 01 0a 19 80 e9 12 32 7d 8b 82 8a 83 ef f0 12 35 41 12 35 07 7f
00 22 90 ff 26 e0 f5 7c ef 20 e7 03 30 e6 03 53 7c 3f ef 20 e1 03 30 e0
03 53 7c fc ef 42 7c 90 ff 26 e5 7c f0 90 ff 25 e0 55 7c 60 07 c2 b5 53 91 >
saa7133[0]: i2c xfer: < 14 2c df d2 e9 22 e5 3d 60 14 15 3d e4 f5 65 12
10 4e 05 65 c3 e5 65 64 80 94 8a 40 f2 22 e5 28 30 e3 04 75 28 01 22 e5
28 30 e1 03 02 1d 20 e5 28 30 e2 03 12 22 70 22 e0 a3 e0 fa a3 e0 f9 12
13 5d e4 ff ef 60 11 90 ff cc e0 f5 5e 90 ff e9 e0 f5 61 a3 e0 f5 62 22
90 ff cc e5 5e f0 90 ff e9 e5 61 f0 a3 e5 62 f0 22 90 ff db e0 30 e1 23
90 ff a1 e0 54 fc f5 76 f0 90 ff a6 e0 75 77 00 f5 78 75 78 00 f5 77 a3
e0 25 78 f5 78 e4 35 77 f5 77 22 75 77 7f 75 78 ff 22 90 ff 08 e0 44 07
f0 90 ff 0a e0 54 3f f0 90 ff 08 e0 54 f8 f0 90 ff a0 74 46 f0 a3 74 18
f0 90 ff af 74 6c f0 74 20 f0 90 ff 60 74 c5 f0 22 c0 e0 c0 f0 c0 83 c0
82 c0 85 c0 84 c0 86 75 86 00 c0 d0 75 d0 18 d2 32 12 35 69 c2 db d0 d0
d0 86 d0 84 d0 85 d0 82 d0 83 d0 f0 d0 e0 32 12 34 16 12 32 a1 ef 60 03 7f >
saa7133[0]: i2c xfer: < 14 2c 01 22 e9 60 17 8b 82 8a 83 e0 ff 12 32 a1
ef 60 03 7f 01 22 19 0b bb 00 01 0a 80 e6 12 35 07 7f 00 22 90 ff 21 e0
30 e6 22 12 27 e9 ef 60 09 90 ff 21 e0 44 04 f0 80 07 90 ff 21 e0 54 fb
f0 90 ff 21 e0 54 bf f0 7f 20 12 30 b0 22 90 ff 36 e0 70 05 53 28 fb ff
22 e5 28 30 e0 17 20 e2 11 75 36 01 75 37 45 e4 f5 3a 85 3f 35 f5 30 43
28 04 7f 00 22 7f 01 22 bf 01 02 d2 b2 bf 02 02 c2 b2 bf 40 02 c2 b3 bf
80 02 d2 b3 bf 04 02 c2 b4 bf 08 02 d2 b4 bf 84 02 c2 b6 bf 88 02 d2 b6
22 e4 ff 7e 08 d2 b0 12 32 c7 d2 b1 30 b1 fd 12 32 c7 ef 25 e0 ff 30 b0
04 cf 44 01 cf c2 b1 12 32 c7 de e1 22 7e 08 ef 30 e7 04 d2 b0 80 02 c2
b0 12 32 c7 d2 b1 30 b1 fd 12 32 c2 ef 25 e0 ff de e5 12 32 e2 22 12 32
c7 c2 b1 ad 16 7c 00 20 b1 08 ec a2 e7 13 fc ed 13 fd ed 4c 60 07 ed 1d 70 >
saa7133[0]: i2c xfer: < 14 2c f8 1c 80 f5 22 d2 b0 12 32 c7 d2 b1 30 b1
fd 12 32 c7 30 b0 08 c2 b1 12 32 c7 7f 01 22 c2 b1 12 32 c7 7f 00 22 90
ff 21 e0 30 e1 17 7d 01 7c 3f 7f 00 7e 3f 12 1e 70 90 ff 21 e0 54 fd f0
7f 04 12 30 b0 22 41 42 74 41 57 87 42 58 32 00 42 5c 64 00 41 41 04 00
21 90 9f 60 21 60 fe 01 21 41 fb 04 00 05 41 4a 2a 33 60 70 01 2c 00 01
31 02 01 28 00 01 3d 00 01 2d 00 01 30 00 02 2e 00 01 00 90 ff 25 e0 65
7e 60 13 e0 f5 7e a3 e0 f5 7c f0 55 7e 60 07 c2 b5 53 91 df d2 e9 22 e4
f5 7e d2 ec d2 ad d2 af f5 7d f5 c8 75 cb 5c 75 ca 74 85 cb cd 85 ca 8b
d2 ca 22 75 60 02 c2 2e 7c 33 7d 33 7b ff e4 ff 12 18 8f 7c 28 7d 9e 7b
ff e4 ff 02 18 8f 75 60 03 c2 2e 7c 33 7d 33 7b ff e4 ff 12 18 8f 7c 23
7d a5 7b ff e4 ff 02 18 8f c0 e0 c0 d0 c2 cf 05 7d e5 7d c3 94 0a 40 05 d2 >
saa7133[0]: i2c xfer: < 14 2c 31 75 7d 00 d0 d0 d0 e0 32 90 ff 58 e0 fe
a3 e0 ff c3 74 ff 9f ff 74 ff 9e fe 7c 02 7d 8f 12 12 bd 22 90 fe 7d e0
f5 40 90 ff 09 e0 44 04 f0 e0 54 fb f0 90 fe 7d e5 40 f0 22 c9 ed c9 90
ff 20 e0 54 7f f5 16 d2 b1 d2 b0 12 32 c7 c2 b0 12 32 c2 22 8e 83 8f 82
8c 85 8d 84 eb 60 0b e0 a3 05 86 f0 a3 15 86 1b 80 f2 22 90 ff 21 e0 30
e4 0f 12 2f b1 90 ff 21 e0 54 ef f0 7f 04 12 30 b0 22 90 ff 31 e4 f0 d2
2b 12 10 2e 12 35 61 12 33 7a c2 2c e4 f5 60 22 d2 28 12 35 4f c2 2a 90
ff 30 e0 54 c0 f5 4a 90 fe 41 e5 41 f0 22 e4 fd fc c3 ed 9f ec 9e 50 09
d2 b7 0d bd 00 01 0c 80 f0 22 e4 fd fc c3 ed 9f ec 9e 50 09 c2 b7 0d bd
00 01 0c 80 f0 22 53 8e f8 90 ff 05 74 04 f0 a3 e4 f0 a3 74 04 f0 02 2f
6b 12 1b c8 12 33 5e 12 10 03 12 32 00 12 34 45 02 33 02 e5 70 70 03 f5 6f >
saa7133[0]: i2c xfer: < 14 2c 22 e5 6c d3 94 02 40 03 12 2e 25 22 7c 28
7d 74 7b ff e4 ff 12 18 8f 7f 02 02 32 54 7c 23 7d 4b 7b ff e4 ff 12 18
8f 7f 02 02 32 54 c2 b0 12 32 c7 d2 b1 12 32 c7 d2 b0 12 32 c7 22 8f 82
8e 83 ed 60 06 e4 f0 a3 1d 80 f7 22 7f 94 7e 00 ef 1f 70 01 1e ef 4e 70
f7 22 c2 b0 12 32 c7 d2 b1 30 b1 fd 12 32 c2 22 d2 b0 12 32 c7 d2 b1 30
b1 fd 12 32 c2 22 c2 23 12 33 fe e4 ff 02 2e ce 53 91 df d2 b5 c2 e9 32
e4 f5 6c f5 6f f5 70 22 90 ff 27 e0 a3 e0 22 >
saa7133[0]: i2c xfer: < 14 2c f1 b2 >
saa7133[0]: i2c xfer: < 14 2c [fd quirk] < 15 =22 >
saa7133[0]: i2c xfer: < 14 2b 80 >
nxt2004: Firmware upload complete
saa7133[0]: i2c xfer: < 14 19 01 >
saa7133[0]: i2c xfer: < 14 2b 00 >
saa7133[0]: i2c xfer: < 14 34 70 >
saa7133[0]: i2c xfer: < 14 35 04 >
saa7133[0]: i2c xfer: < 14 36 01 23 45 67 89 ab cd ef c0 >
saa7133[0]: i2c xfer: < 14 21 80 >
saa7133[0]: i2c xfer: < 14 21 [fd quirk] < 15 =80 >
saa7133[0]: i2c xfer: < 14 21 [fd quirk] < 15 =80 >
saa7133[0]: i2c xfer: < 14 21 [fd quirk] < 15 =80 >
saa7133[0]: i2c xfer: < 14 21 [fd quirk] < 15 =80 >
saa7133[0]: i2c xfer: < 14 21 [fd quirk] < 15 =80 >
saa7133[0]: i2c xfer: < 14 21 [fd quirk] < 15 =00 >
saa7133[0]: i2c xfer: < 14 22 80 >
saa7133[0]: i2c xfer: < 14 31 [fd quirk] < 15 =00 >
saa7133[0]: i2c xfer: < 14 31 [fd quirk] < 15 =00 >
saa7133[0]: i2c xfer: < 14 31 [fd quirk] < 15 =00 >
saa7133[0]: i2c xfer: < 14 31 [fd quirk] < 15 =10 >
saa7133[0]: i2c xfer: < 14 22 80 >
saa7133[0]: i2c xfer: < 14 31 [fd quirk] < 15 =10 >
saa7133[0]: i2c xfer: < 14 2b 00 >
saa7133[0]: i2c xfer: < 14 34 70 >
saa7133[0]: i2c xfer: < 14 35 04 >
saa7133[0]: i2c xfer: < 14 36 01 23 45 67 89 ab cd ef c0 >
saa7133[0]: i2c xfer: < 14 21 80 >
saa7133[0]: i2c xfer: < 14 21 [fd quirk] < 15 =00 >
saa7133[0]: i2c xfer: < 14 22 80 >
saa7133[0]: i2c xfer: < 14 31 [fd quirk] < 15 =10 >
saa7133[0]: i2c xfer: < 14 35 08 >
saa7133[0]: i2c xfer: < 14 36 ff >
saa7133[0]: i2c xfer: < 14 34 31 >
saa7133[0]: i2c xfer: < 14 21 80 >
saa7133[0]: i2c xfer: < 14 21 [fd quirk] < 15 =00 >
saa7133[0]: i2c xfer: < 14 35 08 >
saa7133[0]: i2c xfer: < 14 36 00 >
saa7133[0]: i2c xfer: < 14 34 31 >
saa7133[0]: i2c xfer: < 14 21 80 >
saa7133[0]: i2c xfer: < 14 21 [fd quirk] < 15 =00 >
saa7133[0]: i2c xfer: < 14 57 d7 >
saa7133[0]: i2c xfer: < 14 35 07 fe >
saa7133[0]: i2c xfer: < 14 34 12 >
saa7133[0]: i2c xfer: < 14 21 80 >
saa7133[0]: i2c xfer: < 14 0a 21 >
saa7133[0]: i2c xfer: < 14 35 80 >
saa7133[0]: i2c xfer: < 14 36 01 >
saa7133[0]: i2c xfer: < 14 34 51 >
saa7133[0]: i2c xfer: < 14 21 80 >
saa7133[0]: i2c xfer: < 14 21 [fd quirk] < 15 =00 >
saa7133[0]: i2c xfer: < 14 e9 7e 00 >
saa7133[0]: i2c xfer: < 14 cc 00 >
saa7133[0]: i2c xfer: < 14 35 80 >
saa7133[0]: i2c xfer: < 14 34 41 >
saa7133[0]: i2c xfer: < 14 21 80 >
saa7133[0]: i2c xfer: < 14 36 [fd quirk] < 15 =01 >
saa7133[0]: i2c xfer: < 14 35 80 >
saa7133[0]: i2c xfer: < 14 36 00 >
saa7133[0]: i2c xfer: < 14 34 51 >
saa7133[0]: i2c xfer: < 14 21 80 >
saa7133[0]: i2c xfer: < 14 21 [fd quirk] < 15 =00 >
saa7133[0]: i2c xfer: < 14 35 08 >
saa7133[0]: i2c xfer: < 14 34 21 >
saa7133[0]: i2c xfer: < 14 21 80 >
saa7133[0]: i2c xfer: < 14 36 [fd quirk] < 15 =00 >
saa7133[0]: i2c xfer: < 14 35 08 >
saa7133[0]: i2c xfer: < 14 36 10 >
saa7133[0]: i2c xfer: < 14 34 31 >
saa7133[0]: i2c xfer: < 14 21 80 >
saa7133[0]: i2c xfer: < 14 21 [fd quirk] < 15 =00 >
saa7133[0]: i2c xfer: < 14 35 08 >
saa7133[0]: i2c xfer: < 14 34 21 >
saa7133[0]: i2c xfer: < 14 21 80 >
saa7133[0]: i2c xfer: < 14 36 [fd quirk] < 15 =10 >
saa7133[0]: i2c xfer: < 14 35 08 >
saa7133[0]: i2c xfer: < 14 36 00 >
saa7133[0]: i2c xfer: < 14 34 31 >
saa7133[0]: i2c xfer: < 14 21 80 >
saa7133[0]: i2c xfer: < 14 21 [fd quirk] < 15 =00 >
saa7133[0]: i2c xfer: < 14 35 80 >
saa7133[0]: i2c xfer: < 14 34 41 >
saa7133[0]: i2c xfer: < 14 21 80 >
saa7133[0]: i2c xfer: < 14 36 [fd quirk] < 15 =00 >
saa7133[0]: i2c xfer: < 14 35 80 >
saa7133[0]: i2c xfer: < 14 36 01 >
saa7133[0]: i2c xfer: < 14 34 51 >
saa7133[0]: i2c xfer: < 14 21 80 >
saa7133[0]: i2c xfer: < 14 21 [fd quirk] < 15 =00 >
saa7133[0]: i2c xfer: < 14 35 81 >
saa7133[0]: i2c xfer: < 14 36 70 >
saa7133[0]: i2c xfer: < 14 34 51 >
saa7133[0]: i2c xfer: < 14 21 80 >
saa7133[0]: i2c xfer: < 14 21 [fd quirk] < 15 =00 >
saa7133[0]: i2c xfer: < 14 35 82 >
saa7133[0]: i2c xfer: < 14 36 31 5e 66 >
saa7133[0]: i2c xfer: < 14 34 53 >
saa7133[0]: i2c xfer: < 14 21 80 >
saa7133[0]: i2c xfer: < 14 21 [fd quirk] < 15 =00 >
saa7133[0]: i2c xfer: < 14 35 88 >
saa7133[0]: i2c xfer: < 14 34 41 >
saa7133[0]: i2c xfer: < 14 21 80 >
saa7133[0]: i2c xfer: < 14 36 [fd quirk] < 15 =78 >
saa7133[0]: i2c xfer: < 14 35 88 >
saa7133[0]: i2c xfer: < 14 36 11 >
saa7133[0]: i2c xfer: < 14 34 51 >
saa7133[0]: i2c xfer: < 14 21 80 >
saa7133[0]: i2c xfer: < 14 21 [fd quirk] < 15 =00 >
saa7133[0]: i2c xfer: < 14 35 80 >
saa7133[0]: i2c xfer: < 14 34 41 >
saa7133[0]: i2c xfer: < 14 21 80 >
saa7133[0]: i2c xfer: < 14 36 [fd quirk] < 15 =01 >
saa7133[0]: i2c xfer: < 14 35 80 >
saa7133[0]: i2c xfer: < 14 36 40 >
saa7133[0]: i2c xfer: < 14 34 51 >
saa7133[0]: i2c xfer: < 14 21 80 >
saa7133[0]: i2c xfer: < 14 21 [fd quirk] < 15 =00 >
saa7133[0]: i2c xfer: < 14 10 [fd quirk] < 15 =12 >
saa7133[0]: i2c xfer: < 14 10 10 >
saa7133[0]: i2c xfer: < 14 0a [fd quirk] < 15 =21 >
saa7133[0]: i2c xfer: < 14 0a 21 >
saa7133[0]: i2c xfer: < 14 2b 00 >
saa7133[0]: i2c xfer: < 14 34 70 >
saa7133[0]: i2c xfer: < 14 35 04 >
saa7133[0]: i2c xfer: < 14 36 01 23 45 67 89 ab cd ef c0 >
saa7133[0]: i2c xfer: < 14 21 80 >
saa7133[0]: i2c xfer: < 14 21 [fd quirk] < 15 =00 >
saa7133[0]: i2c xfer: < 14 0a 21 >
saa7133[0]: i2c xfer: < 14 e9 7e >
saa7133[0]: i2c xfer: < 14 ea 00 >
saa7133[0]: i2c xfer: < 14 35 80 >
saa7133[0]: i2c xfer: < 14 34 41 >
saa7133[0]: i2c xfer: < 14 21 80 >
saa7133[0]: i2c xfer: < 14 36 [fd quirk] < 15 =40 >
saa7133[0]: i2c xfer: < 14 35 80 >
saa7133[0]: i2c xfer: < 14 36 00 >
saa7133[0]: i2c xfer: < 14 34 51 >
saa7133[0]: i2c xfer: < 14 21 80 >
saa7133[0]: i2c xfer: < 14 21 [fd quirk] < 15 =00 >
saa7133[0]: i2c xfer: < 14 35 80 >
saa7133[0]: i2c xfer: < 14 34 41 >
saa7133[0]: i2c xfer: < 14 21 80 >
saa7133[0]: i2c xfer: < 14 36 [fd quirk] < 15 =00 >
saa7133[0]: i2c xfer: < 14 35 80 >
saa7133[0]: i2c xfer: < 14 36 00 >
saa7133[0]: i2c xfer: < 14 34 51 >
saa7133[0]: i2c xfer: < 14 21 80 >
saa7133[0]: i2c xfer: < 14 21 [fd quirk] < 15 =00 >
saa7133[0]: i2c xfer: < 14 35 08 >
saa7133[0]: i2c xfer: < 14 34 21 >
saa7133[0]: i2c xfer: < 14 21 80 >
saa7133[0]: i2c xfer: < 14 36 [fd quirk] < 15 =00 >
saa7133[0]: i2c xfer: < 14 35 08 >
saa7133[0]: i2c xfer: < 14 36 10 >
saa7133[0]: i2c xfer: < 14 34 31 >
saa7133[0]: i2c xfer: < 14 21 80 >
saa7133[0]: i2c xfer: < 14 21 [fd quirk] < 15 =00 >
saa7133[0]: i2c xfer: < 14 35 08 >
saa7133[0]: i2c xfer: < 14 34 21 >
saa7133[0]: i2c xfer: < 14 21 80 >
saa7133[0]: i2c xfer: < 14 36 [fd quirk] < 15 =10 >
saa7133[0]: i2c xfer: < 14 35 08 >
saa7133[0]: i2c xfer: < 14 36 00 >
saa7133[0]: i2c xfer: < 14 34 31 >
saa7133[0]: i2c xfer: < 14 21 80 >
saa7133[0]: i2c xfer: < 14 21 [fd quirk] < 15 =00 >
saa7133[0]: i2c xfer: < 14 35 80 >
saa7133[0]: i2c xfer: < 14 34 41 >
saa7133[0]: i2c xfer: < 14 21 80 >
saa7133[0]: i2c xfer: < 14 36 [fd quirk] < 15 =00 >
saa7133[0]: i2c xfer: < 14 35 80 >
saa7133[0]: i2c xfer: < 14 36 04 >
saa7133[0]: i2c xfer: < 14 34 51 >
saa7133[0]: i2c xfer: < 14 21 80 >
saa7133[0]: i2c xfer: < 14 21 [fd quirk] < 15 =00 >
saa7133[0]: i2c xfer: < 14 35 81 >
saa7133[0]: i2c xfer: < 14 36 00 >
saa7133[0]: i2c xfer: < 14 34 51 >
saa7133[0]: i2c xfer: < 14 21 80 >
saa7133[0]: i2c xfer: < 14 21 [fd quirk] < 15 =00 >
saa7133[0]: i2c xfer: < 14 35 82 >
saa7133[0]: i2c xfer: < 14 36 80 00 00 >
saa7133[0]: i2c xfer: < 14 34 53 >
saa7133[0]: i2c xfer: < 14 21 80 >
saa7133[0]: i2c xfer: < 14 21 [fd quirk] < 15 =00 >
saa7133[0]: i2c xfer: < 14 35 88 >
saa7133[0]: i2c xfer: < 14 34 41 >
saa7133[0]: i2c xfer: < 14 21 80 >
saa7133[0]: i2c xfer: < 14 36 [fd quirk] < 15 =78 >
saa7133[0]: i2c xfer: < 14 35 88 >
saa7133[0]: i2c xfer: < 14 36 11 >
saa7133[0]: i2c xfer: < 14 34 51 >
saa7133[0]: i2c xfer: < 14 21 80 >
saa7133[0]: i2c xfer: < 14 21 [fd quirk] < 15 =00 >
saa7133[0]: i2c xfer: < 14 35 80 >
saa7133[0]: i2c xfer: < 14 34 41 >
saa7133[0]: i2c xfer: < 14 21 80 >
saa7133[0]: i2c xfer: < 14 36 [fd quirk] < 15 =04 >
saa7133[0]: i2c xfer: < 14 35 80 >
saa7133[0]: i2c xfer: < 14 36 44 >
saa7133[0]: i2c xfer: < 14 34 51 >
saa7133[0]: i2c xfer: < 14 21 80 >
saa7133[0]: i2c xfer: < 14 21 [fd quirk] < 15 =00 >
saa7133[0]: i2c xfer: < 14 10 [fd quirk] < 15 =10 >
saa7133[0]: i2c xfer: < 14 10 12 >
saa7133[0]: i2c xfer: < 14 13 04 >
saa7133[0]: i2c xfer: < 14 16 00 >
saa7133[0]: i2c xfer: < 14 14 04 >
saa7133[0]: i2c xfer: < 14 14 00 >
saa7133[0]: i2c xfer: < 14 17 00 >
saa7133[0]: i2c xfer: < 14 14 00 >
saa7133[0]: i2c xfer: < 14 17 00 >




C)
modprobe -r saa7134-dvb
modprobe -r tuner
modprobe saa7134-dvb debug=1
dmesg:

tuner-simple 1-0061: destroying instance
Linux video capture interface: v2.00
saa7130/34: v4l2 driver version 0.2.14 loaded
saa7133[0]: found at 0000:00:09.0, rev: 240, irq: 19, latency: 32, mmio:
0xfa021000
saa7133[0]: subsystem: 17de:7350, board: Kworld ATSC110/115
[card=90,autodetected]
saa7133[0]: board init: gpio is 100
saa7133[0]: i2c eeprom 00: de 17 50 73 ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
tuner 1-0061: chip found @ 0xc2 (saa7133[0])
tuner-simple 1-0061: creating new instance
tuner-simple 1-0061: type set to 68 (Philips TUV1236D ATSC/NTSC dual in)
saa7133[0]: registered device video0 [v4l2]
saa7133[0]: registered device vbi0
dvb_init() allocating 1 frontend
nxt200x: NXT2004 Detected
tuner-simple 1-0061: attaching existing instance
tuner-simple 1-0061: type set to 68 (Philips TUV1236D ATSC/NTSC dual in)
DVB: registering new adapter (saa7133[0])
DVB: registering adapter 0 frontend 0 (Nextwave NXT200X VSB/QAM frontend)...
nxt2004: Waiting for firmware upload (dvb-fe-nxt2004.fw)...
nxt2004: Waiting for firmware upload(2)...
nxt2004: Firmware upload complete


-------------

[2] Current Hg with Mauro's patch applied

A)
fresh install, no options
dmesg:

Linux video capture interface: v2.00
saa7130/34: v4l2 driver version 0.2.14 loaded
saa7133[0]: found at 0000:00:09.0, rev: 240, irq: 19, latency: 32, mmio:
0xfa021000
saa7133[0]: subsystem: 17de:7350, board: Kworld ATSC110/115
[card=90,autodetected]
saa7133[0]: board init: gpio is 100
saa7133[0]: i2c eeprom 00: de 17 50 73 ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: registered device video0 [v4l2]
saa7133[0]: registered device vbi0
dvb_init() allocating 1 frontend
nxt200x: NXT2004 Detected
tuner-simple 1-0061: creating new instance
tuner-simple 1-0061: type set to 68 (Philips TUV1236D ATSC/NTSC dual in)
DVB: registering new adapter (saa7133[0])
DVB: registering adapter 0 frontend 0 (Nextwave NXT200X VSB/QAM frontend)...
nxt2004: Waiting for firmware upload (dvb-fe-nxt2004.fw)...
nxt2004: Waiting for firmware upload(2)...
nxt2004: Firmware upload complete


B)
modprobe -r saa7134-dvb
modprobe -r tuner
modprobe saa7134 i2c_scan=1
dmesg:

tuner-simple 1-0061: destroying instance
Linux video capture interface: v2.00
saa7130/34: v4l2 driver version 0.2.14 loaded
saa7133[0]: found at 0000:00:09.0, rev: 240, irq: 19, latency: 32, mmio:
0xfa021000
saa7133[0]: subsystem: 17de:7350, board: Kworld ATSC110/115
[card=90,autodetected]
saa7133[0]: board init: gpio is 100
saa7133[0]: i2c eeprom 00: de 17 50 73 ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c scan: found device @ 0x14  [???]
saa7133[0]: i2c scan: found device @ 0x16  [???]
saa7133[0]: i2c scan: found device @ 0xa0  [eeprom]
saa7133[0]: registered device video0 [v4l2]
saa7133[0]: registered device vbi0
dvb_init() allocating 1 frontend
nxt200x: NXT2004 Detected
tuner-simple 1-0061: creating new instance
tuner-simple 1-0061: type set to 68 (Philips TUV1236D ATSC/NTSC dual in)
DVB: registering new adapter (saa7133[0])
DVB: registering adapter 0 frontend 0 (Nextwave NXT200X VSB/QAM frontend)...
nxt2004: Waiting for firmware upload (dvb-fe-nxt2004.fw)...
nxt2004: Waiting for firmware upload(2)...
nxt2004: Firmware upload complete

Re: KWorld ATSC 115 all static

[CityK]

CityK wrote:
> Hans wrote:
>> CityK wrote:
>>     
>>> In regards to the tuner type being set twice, that is precisely my point
>>> -- its peculiar and not symptomatic of normal behaviour.  That is why I
>>> asked whether you expected it to do this    
>>>       
>> I think it is OK. The second setup is probably done by dvb_attach() in 
>> saa7134-dvb.c, line 1191. Can you verify that with a debug message?  
>>     
> Could not verify.  (dmesg output provided below at end).
>   

Actually, looking at the dmesg output now, it is apparent that you are
correct:

dvb_init() allocating 1 frontend

So, its a case of a bit of redundancy now.

Re: KWorld ATSC 115 all static

[Trent Piepho]

On Sun, 25 Jan 2009, CityK wrote:
> Hans Verkuil wrote:
> > card. Does someone know if there is something special about this? And how
> > do you manage to make analog TV work if the tda9887 isn't found? That's
> > rather peculiar.

The tda9887 is a simple device with just three registers.  If they are set
to the right value when the driver loads, which wouldn't be unexpected,
then it isn't necessary to actually do anything to the chip.  If you had a
multistandard tuner (and had access to broadcasts in multiple standards!)
then I expect switching standards wouldn't work without the tda9887 driver.
Verifying both TV and radio tuning works is probably the most realistic way
to check.

> > saa7133[1]: i2c xfer: < c2 30 90 >
> > saa7134[3]: i2c xfer: < c2 >
> > saa7134[3]: i2c xfer: < c2 0b dc 9c 60 >
> > saa7134[3]: i2c xfer: < c2 0b dc 86 54 >
> >
> > Exactly here, when the buffers are sent the second time the tda9887
> > becomes the first time visible on the bus. According to Hartmut the
> > modification of buffer[3] from 0x60 to 0x54 is that hidden switch,
> > IIRC.
> >
>
> I believe Mauro is correct in regards to the tda9887 in that, within the
> Philips TUV1236D NIM, it is behind the Nxt2004's i2c gate.  After
> re-reading what Michael mentioned previously:

Address 0xc2 is the PLL, not the NXT2004.  Why would the PLL control an I2C
gate on the nxt2004?  I think what I said before about a gpio line on the
PLL being used to hold the analog demod in reset when not in use is more
likely to be correct.

> > The i2c command to enable the tuner is sent to nxt200x. If there are any
> > ATSC110 variant with a different demod (maybe a different version of nxt200x?),
> > then the users may experience different behaviors.

That command sequence is sent to the PLL, not the nxt2004, so this is
wrong.  There is another command sent to the nxt2004 (which is at address
0x0a) from code in saa7134-cards.c to "enables tuner" as well.

Re: KWorld ATSC 115 all static

[hermann pitton]

Am Sonntag, den 25.01.2009, 13:49 -0800 schrieb Trent Piepho:
> On Sun, 25 Jan 2009, CityK wrote:
> > Hans Verkuil wrote:
> > > card. Does someone know if there is something special about this? And how
> > > do you manage to make analog TV work if the tda9887 isn't found? That's
> > > rather peculiar.
> 
> The tda9887 is a simple device with just three registers.  If they are set
> to the right value when the driver loads, which wouldn't be unexpected,
> then it isn't necessary to actually do anything to the chip.  If you had a
> multistandard tuner (and had access to broadcasts in multiple standards!)
> then I expect switching standards wouldn't work without the tda9887 driver.
> Verifying both TV and radio tuning works is probably the most realistic way
> to check.

For radio you need a tda9887 and working i2c for what i can know.

Also after a cold boot the tda988x is not in a usable state for any tv
standard yet, it needs to be set by i2c first.

But for NTSC, and only NTSC, one pin can be strapped, IIRC, and then it
works without any i2c programming needed. Guess it is a tda9885 here.

> > > saa7133[1]: i2c xfer: < c2 30 90 >
> > > saa7134[3]: i2c xfer: < c2 >
> > > saa7134[3]: i2c xfer: < c2 0b dc 9c 60 >
> > > saa7134[3]: i2c xfer: < c2 0b dc 86 54 >
> > >
> > > Exactly here, when the buffers are sent the second time the tda9887
> > > becomes the first time visible on the bus. According to Hartmut the
> > > modification of buffer[3] from 0x60 to 0x54 is that hidden switch,
> > > IIRC.
> > >
> >
> > I believe Mauro is correct in regards to the tda9887 in that, within the
> > Philips TUV1236D NIM, it is behind the Nxt2004's i2c gate.  After
> > re-reading what Michael mentioned previously:
> 
> Address 0xc2 is the PLL, not the NXT2004.  Why would the PLL control an I2C
> gate on the nxt2004?  I think what I said before about a gpio line on the
> PLL being used to hold the analog demod in reset when not in use is more
> likely to be correct.

That the analog demod is enabled from the pll in case of the FMD1216ME
MK3 hybrid is what Hartmut told us.

To remeber, the Pinnacle 300i hybrid with mt32xx (3250) disables the
analog demod with tda9887 port2=0 in digital mode. That is why Gerd
re-enables it on exit of DVB. 

> > > The i2c command to enable the tuner is sent to nxt200x. If there are any
> > > ATSC110 variant with a different demod (maybe a different version of nxt200x?),
> > > then the users may experience different behaviors.
> 
> That command sequence is sent to the PLL, not the nxt2004, so this is
> wrong.  There is another command sent to the nxt2004 (which is at address
> 0x0a) from code in saa7134-cards.c to "enables tuner" as well.

Cheers,
Hermann

Re: KWorld ATSC 115 all static

[CityK]

hermann pitton wrote:
> Am Sonntag, den 25.01.2009, 13:49 -0800 schrieb Trent Piepho:
>   
>> On Sun, 25 Jan 2009, CityK wrote:
>>     
>>> Hans Verkuil wrote:
>>>
>>> this still begs Han's question: "how do you manage to make analog TV
>>> work if the tda9887 isn't found? That's rather peculiar." I don't have
>>> an answer for that. The tuner-simple module, however, seems to be able to drive/provide that functionality sufficiently enough. 
>>>
>> The tda9887 is a simple device with just three registers.  If they are set
>> to the right value when the driver loads, which wouldn't be unexpected,
>> then it isn't necessary to actually do anything to the chip.  If you had a
>> multistandard tuner (and had access to broadcasts in multiple standards!)
>> then I expect switching standards wouldn't work without the tda9887 driver.
>> Verifying both TV and radio tuning works is probably the most realistic way
>> to check.
>>     
>
> For radio you need a tda9887 and working i2c for what i can know.
>
> Also after a cold boot the tda988x is not in a usable state for any tv
> standard yet, it needs to be set by i2c first.
>
> But for NTSC, and only NTSC, one pin can be strapped, IIRC, and then it
> works without any i2c programming needed. Guess it is a tda9885 here.
>
>   

Looks like that this is the case, as described by Trent, that is
occurring. Herman, is there any difference between the tda9885 and
tda887, as I'm pretty sure this is the tda9887 package outlined on page
52 of the tda9887 datasheet.

Alas, as being exposed to just NTSC broadcasts, not able to test on the
multistandard ;)

As for the FM radio, I know that some have mentioned the possibility for
that with this device, but I don't think anyone ever has succeeded (not
surprising given the i2c situation) and so the assumption was made,
rightly or wrongly, that it is not present. I would be amused if FM
radio support could be realised for the device.

>>>> saa7133[1]: i2c xfer: < c2 30 90 >
>>>> saa7134[3]: i2c xfer: < c2 >
>>>> saa7134[3]: i2c xfer: < c2 0b dc 9c 60 >
>>>> saa7134[3]: i2c xfer: < c2 0b dc 86 54 >
>>>>
>>>> Exactly here, when the buffers are sent the second time the tda9887
>>>> becomes the first time visible on the bus. According to Hartmut the
>>>> modification of buffer[3] from 0x60 to 0x54 is that hidden switch,
>>>> IIRC.
>>>>
>>>>         
>>> I believe Mauro is correct in regards to the tda9887 in that, within the
>>> Philips TUV1236D NIM, it is behind the Nxt2004's i2c gate.  After
>>> re-reading what Michael mentioned previously:
>>>       
>> Address 0xc2 is the PLL, not the NXT2004.  Why would the PLL control an I2C
>> gate on the nxt2004?  I think what I said before about a gpio line on the
>> PLL being used to hold the analog demod in reset when not in use is more
>> likely to be correct.
>>     
>
> That the analog demod is enabled from the pll in case of the FMD1216ME
> MK3 hybrid is what Hartmut told us.
>
> To remeber, the Pinnacle 300i hybrid with mt32xx (3250) disables the
> analog demod with tda9887 port2=0 in digital mode. That is why Gerd
> re-enables it on exit of DVB. 
>
>>> The i2c command to enable the tuner is sent to nxt200x. If there are any
>>> ATSC110 variant with a different demod (maybe a different version of nxt200x?),
>>> then the users may experience different behaviors.
>>>       
>> That command sequence is sent to the PLL, not the nxt2004, so this is 
>> wrong.  There is another command sent to the nxt2004 (which is at address
>> 0x0a) from code in saa7134-cards.c to "enables tuner" as well.
>>     

Re: KWorld ATSC 115 all static

[hermann pitton]

Am Sonntag, den 25.01.2009, 18:35 -0500 schrieb CityK:
> hermann pitton wrote:
> > Am Sonntag, den 25.01.2009, 13:49 -0800 schrieb Trent Piepho:
> >   
> >> On Sun, 25 Jan 2009, CityK wrote:
> >>     
> >>> Hans Verkuil wrote:
> >>>
> >>> this still begs Han's question: "how do you manage to make analog TV
> >>> work if the tda9887 isn't found? That's rather peculiar." I don't have
> >>> an answer for that. The tuner-simple module, however, seems to be able to drive/provide that functionality sufficiently enough. 
> >>>
> >> The tda9887 is a simple device with just three registers.  If they are set
> >> to the right value when the driver loads, which wouldn't be unexpected,
> >> then it isn't necessary to actually do anything to the chip.  If you had a
> >> multistandard tuner (and had access to broadcasts in multiple standards!)
> >> then I expect switching standards wouldn't work without the tda9887 driver.
> >> Verifying both TV and radio tuning works is probably the most realistic way
> >> to check.
> >>     
> >
> > For radio you need a tda9887 and working i2c for what i can know.
> >
> > Also after a cold boot the tda988x is not in a usable state for any tv
> > standard yet, it needs to be set by i2c first.
> >
> > But for NTSC, and only NTSC, one pin can be strapped, IIRC, and then it
> > works without any i2c programming needed. Guess it is a tda9885 here.
> >
> >   
> 
> Looks like that this is the case, as described by Trent, that is
> occurring. Herman, is there any difference between the tda9885 and
> tda887, as I'm pretty sure this is the tda9887 package outlined on page
> 52 of the tda9887 datasheet.
> 
> Alas, as being exposed to just NTSC broadcasts, not able to test on the
> multistandard ;)
> 
> As for the FM radio, I know that some have mentioned the possibility for
> that with this device, but I don't think anyone ever has succeeded (not
> surprising given the i2c situation) and so the assumption was made,
> rightly or wrongly, that it is not present. I would be amused if FM
> radio support could be realised for the device.

Oh my, this is close to a decade with us and that is why I still make
noise when early developers are dropped from e-mail with all the
different possible solutions.

For the radio, I wonder why nobody ever tested it on windows ;)

On the tda9887, which only supports it, you find also a tda7240, I might
have the chip wrong and thought just to give some hints for what I
remember, but can't look up further into details right now. This one
does in radio mode the stereo separation and provides in TV mode just
MONO on both lines. You don't seem to have it, but tuner PCBs have also
a backside ;)

It reminds me on what i did try to report for DVB-S on the 0x0008 device
on the Medion Quad. All other report it is fine and don't even notice
the tuner loop through enabled.

But I report it is always at 18Volts, whereas the 0xc4 buffer should set
it to 13Volts, which is described as a prerequisite for external voltage
switching, not fulfilled and obviously not easy to reach for what I
tried and the Philips/NXP m$ driver has the same issue ;)

> >>>> saa7133[1]: i2c xfer: < c2 30 90 >
> >>>> saa7134[3]: i2c xfer: < c2 >
> >>>> saa7134[3]: i2c xfer: < c2 0b dc 9c 60 >
> >>>> saa7134[3]: i2c xfer: < c2 0b dc 86 54 >
> >>>>
> >>>> Exactly here, when the buffers are sent the second time the tda9887
> >>>> becomes the first time visible on the bus. According to Hartmut the
> >>>> modification of buffer[3] from 0x60 to 0x54 is that hidden switch,
> >>>> IIRC.
> >>>>
> >>>>         
> >>> I believe Mauro is correct in regards to the tda9887 in that, within the
> >>> Philips TUV1236D NIM, it is behind the Nxt2004's i2c gate.  After
> >>> re-reading what Michael mentioned previously:
> >>>       
> >> Address 0xc2 is the PLL, not the NXT2004.  Why would the PLL control an I2C
> >> gate on the nxt2004?  I think what I said before about a gpio line on the
> >> PLL being used to hold the analog demod in reset when not in use is more
> >> likely to be correct.
> >>     
> >
> > That the analog demod is enabled from the pll in case of the FMD1216ME
> > MK3 hybrid is what Hartmut told us.
> >
> > To remeber, the Pinnacle 300i hybrid with mt32xx (3250) disables the
> > analog demod with tda9887 port2=0 in digital mode. That is why Gerd
> > re-enables it on exit of DVB. 
> >
> >>> The i2c command to enable the tuner is sent to nxt200x. If there are any
> >>> ATSC110 variant with a different demod (maybe a different version of nxt200x?),
> >>> then the users may experience different behaviors.
> >>>       
> >> That command sequence is sent to the PLL, not the nxt2004, so this is 
> >> wrong.  There is another command sent to the nxt2004 (which is at address
> >> 0x0a) from code in saa7134-cards.c to "enables tuner" as well.
> >>     

Cheers,
Hermann

Re: KWorld ATSC 115 all static

[Mauro Carvalho Chehab]

On Sun, 25 Jan 2009 18:35:17 -0500
CityK <cityk@rogers.com> wrote:

> hermann pitton wrote:
> > Am Sonntag, den 25.01.2009, 13:49 -0800 schrieb Trent Piepho:
> >   
> >> On Sun, 25 Jan 2009, CityK wrote:
> >>     
> >>> Hans Verkuil wrote:
> >>>
> >>> this still begs Han's question: "how do you manage to make analog TV
> >>> work if the tda9887 isn't found? That's rather peculiar." I don't have
> >>> an answer for that. The tuner-simple module, however, seems to be able to drive/provide that functionality sufficiently enough. 
> >>>
> >> The tda9887 is a simple device with just three registers.  If they are set
> >> to the right value when the driver loads, which wouldn't be unexpected,
> >> then it isn't necessary to actually do anything to the chip.  If you had a
> >> multistandard tuner (and had access to broadcasts in multiple standards!)
> >> then I expect switching standards wouldn't work without the tda9887 driver.
> >> Verifying both TV and radio tuning works is probably the most realistic way
> >> to check.
> >>     
> >
> > For radio you need a tda9887 and working i2c for what i can know.
> >
> > Also after a cold boot the tda988x is not in a usable state for any tv
> > standard yet, it needs to be set by i2c first.
> >
> > But for NTSC, and only NTSC, one pin can be strapped, IIRC, and then it
> > works without any i2c programming needed. Guess it is a tda9885 here.
> >
> >   
> 
> Looks like that this is the case, as described by Trent, that is
> occurring. Herman, is there any difference between the tda9885 and
> tda887, as I'm pretty sure this is the tda9887 package outlined on page
> 52 of the tda9887 datasheet.
> 
> Alas, as being exposed to just NTSC broadcasts, not able to test on the
> multistandard ;)
> 
> As for the FM radio, I know that some have mentioned the possibility for
> that with this device, but I don't think anyone ever has succeeded (not
> surprising given the i2c situation) and so the assumption was made,
> rightly or wrongly, that it is not present. I would be amused if FM
> radio support could be realised for the device.
> 
> >>>> saa7133[1]: i2c xfer: < c2 30 90 >
> >>>> saa7134[3]: i2c xfer: < c2 >
> >>>> saa7134[3]: i2c xfer: < c2 0b dc 9c 60 >
> >>>> saa7134[3]: i2c xfer: < c2 0b dc 86 54 >
> >>>>
> >>>> Exactly here, when the buffers are sent the second time the tda9887
> >>>> becomes the first time visible on the bus. According to Hartmut the
> >>>> modification of buffer[3] from 0x60 to 0x54 is that hidden switch,
> >>>> IIRC.
> >>>>
> >>>>         
> >>> I believe Mauro is correct in regards to the tda9887 in that, within the
> >>> Philips TUV1236D NIM, it is behind the Nxt2004's i2c gate.  After
> >>> re-reading what Michael mentioned previously:
> >>>       
> >> Address 0xc2 is the PLL, not the NXT2004.  Why would the PLL control an I2C
> >> gate on the nxt2004?  I think what I said before about a gpio line on the
> >> PLL being used to hold the analog demod in reset when not in use is more
> >> likely to be correct.

I've seen i2c switches on a few different places:
	on bridge driver gpio's;
	on demod's gpio's;
	on tda9887 gpio's;
	on tuner/PLL gpio's.

In the case of tuner/PLL gpio's, you'll see some i2c switch magic inside tuner-core, like this one:
        case TUNER_PHILIPS_FMD1216ME_MK3:
                buffer[0] = 0x0b;
                buffer[1] = 0xdc;
                buffer[2] = 0x9c;
                buffer[3] = 0x60;
                i2c_master_send(c, buffer, 4);
                mdelay(1);
                buffer[2] = 0x86;
                buffer[3] = 0x54;
                i2c_master_send(c, buffer, 4);

I'm not sure what would be the better way to address all those kind of i2c
switches. Maybe we should add a field at device struct specifying what i2c
device contains the i2c bridge, in order to initialize it first.



Cheers,
Mauro

Re: KWorld ATSC 115 all static

[hermann pitton]

Am Mittwoch, den 28.01.2009, 00:23 -0200 schrieb Mauro Carvalho Chehab:
> On Sun, 25 Jan 2009 18:35:17 -0500
> CityK <cityk@rogers.com> wrote:
> 
> > hermann pitton wrote:
> > > Am Sonntag, den 25.01.2009, 13:49 -0800 schrieb Trent Piepho:
> > >   
> > >> On Sun, 25 Jan 2009, CityK wrote:
> > >>     
> > >>> Hans Verkuil wrote:
> > >>>
> > >>> this still begs Han's question: "how do you manage to make analog TV
> > >>> work if the tda9887 isn't found? That's rather peculiar." I don't have
> > >>> an answer for that. The tuner-simple module, however, seems to be able to drive/provide that functionality sufficiently enough. 
> > >>>
> > >> The tda9887 is a simple device with just three registers.  If they are set
> > >> to the right value when the driver loads, which wouldn't be unexpected,
> > >> then it isn't necessary to actually do anything to the chip.  If you had a
> > >> multistandard tuner (and had access to broadcasts in multiple standards!)
> > >> then I expect switching standards wouldn't work without the tda9887 driver.
> > >> Verifying both TV and radio tuning works is probably the most realistic way
> > >> to check.
> > >>     
> > >
> > > For radio you need a tda9887 and working i2c for what i can know.
> > >
> > > Also after a cold boot the tda988x is not in a usable state for any tv
> > > standard yet, it needs to be set by i2c first.
> > >
> > > But for NTSC, and only NTSC, one pin can be strapped, IIRC, and then it
> > > works without any i2c programming needed. Guess it is a tda9885 here.
> > >
> > >   
> > 
> > Looks like that this is the case, as described by Trent, that is
> > occurring. Herman, is there any difference between the tda9885 and
> > tda887, as I'm pretty sure this is the tda9887 package outlined on page
> > 52 of the tda9887 datasheet.
> > 
> > Alas, as being exposed to just NTSC broadcasts, not able to test on the
> > multistandard ;)
> > 
> > As for the FM radio, I know that some have mentioned the possibility for
> > that with this device, but I don't think anyone ever has succeeded (not
> > surprising given the i2c situation) and so the assumption was made,
> > rightly or wrongly, that it is not present. I would be amused if FM
> > radio support could be realised for the device.
> > 
> > >>>> saa7133[1]: i2c xfer: < c2 30 90 >
> > >>>> saa7134[3]: i2c xfer: < c2 >
> > >>>> saa7134[3]: i2c xfer: < c2 0b dc 9c 60 >
> > >>>> saa7134[3]: i2c xfer: < c2 0b dc 86 54 >
> > >>>>
> > >>>> Exactly here, when the buffers are sent the second time the tda9887
> > >>>> becomes the first time visible on the bus. According to Hartmut the
> > >>>> modification of buffer[3] from 0x60 to 0x54 is that hidden switch,
> > >>>> IIRC.
> > >>>>
> > >>>>         
> > >>> I believe Mauro is correct in regards to the tda9887 in that, within the
> > >>> Philips TUV1236D NIM, it is behind the Nxt2004's i2c gate.  After
> > >>> re-reading what Michael mentioned previously:
> > >>>       
> > >> Address 0xc2 is the PLL, not the NXT2004.  Why would the PLL control an I2C
> > >> gate on the nxt2004?  I think what I said before about a gpio line on the
> > >> PLL being used to hold the analog demod in reset when not in use is more
> > >> likely to be correct.
> 
> I've seen i2c switches on a few different places:
> 	on bridge driver gpio's;
> 	on demod's gpio's;
> 	on tda9887 gpio's;
> 	on tuner/PLL gpio's.
> 
> In the case of tuner/PLL gpio's, you'll see some i2c switch magic inside tuner-core, like this one:
>         case TUNER_PHILIPS_FMD1216ME_MK3:
>                 buffer[0] = 0x0b;
>                 buffer[1] = 0xdc;
>                 buffer[2] = 0x9c;
>                 buffer[3] = 0x60;
>                 i2c_master_send(c, buffer, 4);
>                 mdelay(1);
>                 buffer[2] = 0x86;
>                 buffer[3] = 0x54;
>                 i2c_master_send(c, buffer, 4);
> 
> I'm not sure what would be the better way to address all those kind of i2c
> switches. Maybe we should add a field at device struct specifying what i2c
> device contains the i2c bridge, in order to initialize it first.
> 

The first i2c bus master should be always first.
On PCI this will be the bridge and nothing else.

I hate to say it, but it was a PITA to argue against the "frontend"
stuff, which until today has no realistic concept for that and confuses
a lot on that side.

To see high tones on every smallest intention to do something better
about it, made it the most frustrating stuff I have seen so far.

Cheers,
Hermann

Re: KWorld ATSC 115 all static

[CityK]

CityK wrote:
> Hans Verkuil wrote:
>   
>> I've made a new tree http://linuxtv.org/hg/~hverkuil/v4l-dvb-kworld/ 
>> that calls 'enables the tuner' before loading the module. See if that 
>> works.
>>
>> ...
>>   
>> I suspect that this might fix the bug.
>>     
>
> Hans,
>
> ...  it works !!  

I may have found a problem (tvtime works perfectly; other analogue apps
like xawtv/motv, kdetv ... are not working properly now -- you can do a
channel scan with them and everything_appears_to work as expected (i.e.
channels are found and are displayed/played correctly during the scan),
BUT as soon as you actually go to use the app, it does not work
(static).  It appears that the issue is related to dga and Xv (as
passing the -nodga -noxv options with xawtv/motv actually works ...
kdetv is hit and miss -- sometimes the v4l1 mode works, other times it
doesn't (likely a pattern there but haven't found it yet), but v4l2
plugin does NOT work at all (static)).  In addition, the nvidia driver
is NOT the source of the error, as the same occurs under the nv driver
as well. 

Will have to do another test to confirm whether this error was
introduced in the KWorld repo.  Consequently:

> Mauro Carvalho Chehab wrote:
>   
>> Hans Verkuil wrote:
>>     
>>> Note that Mauro merged my saa7134 changes, so these are now in the master 
>>> repository.
>>>     
>>>       
>> Yes. We need to fix it asap, to avoid regressions. It is time to review also
>> the other codes that are touching on i2c gates at _init2().
>>   
>>     
>
> Thoughts on merging the changes from Hans' KWorld repo? 

If there were any thoughts on this, please put them on hold until I can
test further. 

Re: KWorld ATSC 115 all static

[Mauro Carvalho Chehab]

On Thu, 29 Jan 2009 18:44:44 -0500
CityK <cityk@rogers.com> wrote:

> CityK wrote:
> > Hans Verkuil wrote:
> >   
> >> I've made a new tree http://linuxtv.org/hg/~hverkuil/v4l-dvb-kworld/ 
> >> that calls 'enables the tuner' before loading the module. See if that 
> >> works.
> >>
> >> ...
> >>   
> >> I suspect that this might fix the bug.
> >>     
> >
> > Hans,
> >
> > ...  it works !!  
> 
> I may have found a problem (tvtime works perfectly; other analogue apps
> like xawtv/motv, kdetv ... are not working properly now -- you can do a
> channel scan with them and everything_appears_to work as expected (i.e.
> channels are found and are displayed/played correctly during the scan),
> BUT as soon as you actually go to use the app, it does not work
> (static).  It appears that the issue is related to dga and Xv (as
> passing the -nodga -noxv options with xawtv/motv actually works ...
> kdetv is hit and miss -- sometimes the v4l1 mode works, other times it
> doesn't (likely a pattern there but haven't found it yet), but v4l2
> plugin does NOT work at all (static)).  In addition, the nvidia driver
> is NOT the source of the error, as the same occurs under the nv driver
> as well. 

I've seen this issue happening with nvidia proprietary driver, on an old
machine I had. the open source nv driver were better (e.g. the bug were much
less frequent than with the proprietary one). This kind of trouble is not
related to the kernel driver.

> Will have to do another test to confirm whether this error was
> introduced in the KWorld repo.  Consequently:
> 
> > Mauro Carvalho Chehab wrote:
> >   
> >> Hans Verkuil wrote:
> >>     
> >>> Note that Mauro merged my saa7134 changes, so these are now in the master 
> >>> repository.
> >>>     
> >>>       
> >> Yes. We need to fix it asap, to avoid regressions. It is time to review also
> >> the other codes that are touching on i2c gates at _init2().
> >>   
> >>     
> >
> > Thoughts on merging the changes from Hans' KWorld repo? 
> 
> If there were any thoughts on this, please put them on hold until I can
> test further. 

Ok. FYI, I've committed that changeset I've proposed. Could you please confirm
that the driver is working with the v4l-dvb tree.

Cheers,
Mauro

Re: KWorld ATSC 115 all static

[Trent Piepho]

On Sun, 18 Jan 2009, Hans Verkuil wrote:
> I've taken a look at Mike's workaround and that will indeed no longer
> work. I suspect that the core problem is related to the
> SAA7134_BOARD_KWORLD_ATSC110 case in saa7134_board_init2 in
> saa7134-cards.c. There the 'tuner is enabled', whatever that means. I'm
> beginning to suspect that this code should perhaps be executed before
> the tuner module is loaded. Does anyone know more about what is going
> on here? If my analysis is correct, then this should be executed

IIRC, some hybrid cards have the ability to power down or hold in reset the
analog and/or digital demod when they are not in use.

Since the module load order between tuner and the bridge can't be depended
on, there really should be another way to make sure all i2c devices are out
of reset before scanning for them.

If the demod is controlled by a bridge gpio, then just turn it on _before_
adding the I2C adapter.  Then the chip will be there when the scan happens.
Might need to check how long the demod takes to some out of reset and add a
delay.

If one I2C chip is controlled by another I2C chip on the same bus (e.g.,
analog demod controlled by a gpio on the digital demod), then there is
currently no way to scan for it.  Maybe if the i2c core gave us a "rescan"
function?  Not a bad idea really, other busses have this.

But I think trying to making scanning work with these complex inter-device
dependencies is just perpetuating the mistake of scanning for devices in
the first place.

Much better would be if the tuner driver would let us use i2c_new_device()
or an attach function like the dvb drivers use.  One of the reasons why I
think refactoring the hybrid tuners to use the v4l-style tuner module from
dvb style attachment was a move in the wrong direction.

Re: KWorld ATSC 115 all static

[David Engel]

On Sun, Jan 18, 2009 at 01:10:16PM -0500, CityK wrote:
> But as I have demonstrated above, and as Mauro explained, the previous
> "hack/workaround" no longer works in the case of with the Hans source
> code.  The "if" case fails!  Consequently, the "else" case should be
> don't merge.  Why?  Because we have now gone from:
> * circa pre-2.6.25, Mauro's changes that  broke the boards analog TV
> support, but which could somewhat be corrected by Mike's "hack/workaround"
> * to present, where merging Hans' code eliminates the usability of
> Mike's "hack/workaround" ... in essence, analog TV function has now been
> completely killed with these boards.
> 
> Now, if it is a case that a resolution to the problem is imminently
> forthcoming, then I don't think that the merge would be much of a
> problem.  However, given the breadth of the conversation so far (and I
> really do appreciate the depth of Trent's and Jean's
> discussion/consideration on the matter), it is entirely unclear to me
> that such a resolution will be found in short order  (although, I don't
> discount the possibility of it either).

As far as I can tell, this thread petered out without a resolution.
CityK later posted on avsforum, however, that analog on his card was
after more changes by Hans.  I'm confused.  Is analog on the KWorld
115 supposed to be working again or not?  I saw that some changes by
Hans made it into the main Hg repository, but as of yesterday, analog
still didn't work for me.

David
-- 
David Engel
david@istwok.net

Re: KWorld ATSC 115 all static

[CityK]

David Engel wrote:
> As far as I can tell, this thread petered out without a resolution.  
> CityK later posted on avsforum, however, that analog on his card was
> after more changes by Hans.  I'm confused.  Is analog on the KWorld
> 115 supposed to be working again or not?  I saw that some changes by
> Hans made it into the main Hg repository, but as of yesterday, analog
> still didn't work for me.
>   

Nope, this thread is still alive and well -- I posted to it last Thurs
(?), and Mauro replied, but I haven't had time to follow up with this
since then. Anyway, here's a synopsis of the situation:

- Hans had a first go at the saa7134 (and related modules) in this work
was in his v4l-dvb-saa7134 test repo .... these initial changes,
unfortunately, were NOT sufficient on their own to get analog TV
working. These changes did, however, get pulled into the mainline of v4l-dvb

- Hans' second attempt at this is found in his v4l-dvb-kworld test repo
... testing this code revealed that analog tv did indeed work again with
tvtime ... I also noted that there seems to be a bit of redundancy now
in terms of the tuner being initialized twice

- Mauro created a patch intended to be applied against mainline ... I
tested and analog tv did NOT work

- On Sunday Jan 25th I sent a lengthy message to the list, outlining
some debug results etc. and also informing Mauro that his patch did NOT
work ... I know that, at the very least, Trent and Hermann received that
message, because they quoted from it in further discussion about the i2c
gate (the inherent underlying problem at the heart of the issue).

- A few days later, scanning through the #irc logs, I caught a
discussion, regarding Mauro's patch getting pulled into mainline, and
the discussion seemed to indicate that there was some confusion as to
what I had said worked and what doesn't. This surprised me for I had
been pretty explicit in my Jan 25th mail list message. The other
alternative was perhaps they simply had missed that message...so, in
order to clear the situation up, I went to the mailing list archive to
find a link for my message...only to discover it was NEVER
achieved/recorded....grrrrr. So I'm at a complete loss as to who
actually saw the Jan 25th message and who didn't.

- Further, somewhat concurrently, I discovered that (with Hans' kworld
test repo) analog TV was ONLY working with tvtime ... xawtv/motv and
kdetv were borked (I don't use Myth, so I have no idea what its status
would be ... though, I'd suspect that it works like tvtime). I quickly
traced this problem to be related to dga and Xv. A very similar
situation with these apps existed several years ago when the proprietary
X drivers from nvidia and ati removed dga functionality from their
respective drivers (for some background read:
http://www.nvnews.net/vbulletin/showthread.php?t=68232, and also the
relevant portion of the FAQ from the nvidia readme:
ftp://download.nvidia.com/XFree86/Linux-x86_64/180.27/README/chapter-07.html),
however, the basic nv driver would still function. Nvidia would later
provide a workaround to this issue in their driver.
So, in this modern day occurrence of this similar error/bug, the obvious
first test is to eliminate the proprietary driver from the equation.
However, the test result with the nv driver was the same -- borked
motv/xawtv and kdetv. I reported this, saying that I suspected that a
something may have been introduced somewhere resulting in this issue
with these apps resurfacing. This is why I asked that Hans' kworld repo
NOT be pulled into mainline (if there had been any thought to that --
though I don't think there was, because I now realize that I don't think
many had even seen my prior Jan 25th message !) until further testing
was performed.

- Mauro replied believing that this was unrelated to anything v4l-dvb,
but rather an artefact of the X drivers. I suspected that that was NOT
the case (the nv driver failing in my previous test was my cue). The
next obvious test was to revert back to an older v4l-dvb snapshot that
was patched with Mike Krufky's hack/workaround.

[reverting back should have been an easy task, but unfortunately I
managed to turn it into a frustrating ordeal --- in the case of Hans'
kworld source, the rminstall process did not blow away all the modules;
further, while I had been testing channel scans with xawtv/motv/kdetv, I
also tried with YAST, and unbeknownst to me, it must have saved an
attempt at configing the ir remote --- so that, later, when no v4l-dvb
modules were any longer present on the system, a config script somewhere
must have been calling for the related remote control i2c-blah-blah-blah
modules and the system would freeze, all too coincidently just when the
nvidia x driver was starting up X ... and booting to failsafe and
console mode was not working either (or at least not very well) ... so
my initial belief that the very recent nvidia driver I installed had
mucked up X, and that incorrect belief/assumption led to a masking of
the real underlying problem for a while ... plus the fact that I really
went off on a tangent messing around with xorg.conf and trying out some
of the recent xinput modules etc etc ) .. anyway, as they say, all roads
lead to Rome, and I eventually sorted everything out]

The older snapshot and Mike's patch worked as I expected it to. Removing
that and installing Hans' kworld repo again --> xawtv/motv/kdetv = fail
with Overlay. I can positively state, WITHOUT DOUBT, that there is
something in Hans code that is sourcing this issue. I have not looked at
it closely, nor do I know if I would recognise it when I do, though I
suspect that it would be from initial batch of changes (inserted into
the v4l-dvb-saa7134 repo).

--------------------------------------------------------------------
So the grand conclusion (aka state of the nation):
--------------------------------------------------------------------

- how to provide a proper solution that will resolve the underlying i2c
gate issue remains a point in discussion. In the meantime:

- Hans kworld repo:
Pros: does provide analog tv functionality for, at a minimum, tvtime.
Cons: The changes introduced result in, as testing to date has shown, a
harmless bit of duplication in the way of the tuner being loaded twice.
kdetv/motv/xawtv, at a minimum, do not work in overlay mode.

- Mainline v4l-dvb:
Pros: none ... you will achieve this thread's namesake -- all static.
Cons: since the code from Hans' v4l-dvb-saa7134 repo was merged, Mike's
hack/workaround patch has been rendered ineffective for good. Mauro's
later patch was also pulled into mainline, but it does not change the
situation analog tv (and I do not mean in relation to Mike's patch, I
mean precisely upon its own).

- Mike's hack/workaround patch
Pros: it will apply and work with snapshots of v4l-dvb up to probably ~
Jan 15th or so. All the apps that I tested with work as expected.
Cons: in order to use analog tv, upon each boot, one must do what I
termed being a dance with unloading and reloading the tuner module via
modprobe.

- And finally, as an end note, DVB does, and always has, continue to
work. As I eluded to earlier (somewhere within this growing thread), the
assignment of RF input spigots has changed several times for these cards
throughout the course of their Linux driver(s)'s lifetime. Currently, by
default:
DVB - digital cable is now accessed through the lower input. OTA/ATSC
off the top input. ... this configuration is opposite to that which
users of 2.6.24 era kernels are familiar with.
Analog TV - regardless of whether ota or through cable is also off the
top input.

Re: KWorld ATSC 115 all static

[Michael Krufky]

CityK wrote:
> - how to provide a proper solution that will resolve the underlying i2c
> gate issue remains a point in discussion. In the meantime:
>
>   

It's a load order dependency --  There is no way to toggle the i2c gate 
without first bringing up the demod, which requires firmware.  The 
ATSC11(0/5) requires the DVB bring-up to complete before bringing up the 
analog i2c clients.


> - Hans kworld repo:
> Pros: does provide analog tv functionality for, at a minimum, tvtime.
> Cons: The changes introduced result in, as testing to date has shown, a
> harmless bit of duplication in the way of the tuner being loaded twice.
> kdetv/motv/xawtv, at a minimum, do not work in overlay mode.
>   

Tuner is _not_ loaded twice.  The tuner-simple driver is displaying 
itself twice in the dmesg logs, because it is attached twice.  Once for 
analog, again for digital -- this is *by design*.

The old code used dvb-pll for the digital side, and tuner-simple for 
analog.  The common support within those two modules has been merged 
together to remove redundancy and allow us to share state between the 
two instances of the driver for the same part.

As tuner-simple registers each side of the interface, it will display a 
message to the kernel logs indicating what tuner has been attached -- 
this is what you see twice.

-Mike

Re: KWorld ATSC 115 all static ... Mike's clarification

[CityK]

CityK wrote:
> CityK wrote:
>   
>> Hans wrote:
>>     
>>> CityK wrote:
>>>     
>>>       
>>>> In regards to the tuner type being set twice, that is precisely my point
>>>> -- its peculiar and not symptomatic of normal behaviour.  That is why I
>>>> asked whether you expected it to do this    
>>>>       
>>>>         
>>> I think it is OK. The second setup is probably done by dvb_attach() in 
>>> saa7134-dvb.c, line 1191. Can you verify that with a debug message?  
>>>     
>>>       
>> Could not verify.  (dmesg output provided below at end).
>>   
>>     
>
> Actually, looking at the dmesg output now, it is apparent that you are
> correct:
>
> dvb_init() allocating 1 frontend
>
> So, its a case of a bit of redundancy now.

Michael Krufky wrote:
> CityK wrote:
>> - Hans' second attempt at this is found in his v4l-dvb-kworld test
>> repo... testing this code revealed that analog tv did indeed work
>> again withtvtime ... I also noted that there seems to be a bit of
>> redundancy nowin terms of the tuner being initialized twice
>>
>> ... [snip]...
>>
>> - Hans kworld repo:
>> Pros: does provide analog tv functionality for, at a minimum, tvtime.
>> Cons: The changes introduced result in, as testing to date has shown, a
>> harmless bit of duplication in the way of the tuner being loaded twice.
>> kdetv/motv/xawtv, at a minimum, do not work in overlay mode.  
>
> Tuner is _not_ loaded twice.  The tuner-simple driver is displaying
> itself twice in the dmesg logs, because it is attached twice. 

I actually knew that, but as a consequence of writing a long reply, late
at night, I wasn't fully coherent in my faculties and ended up
misreporting the case.

> Once for analog, again for digital -- this is *by design*.
>
> The old code used dvb-pll for the digital side, and tuner-simple for
> analog.  The common support within those two modules has been merged
> together to remove redundancy and allow us to share state between the
> two instances of the driver for the same part.
>
> As tuner-simple registers each side of the interface, it will display
> a message to the kernel logs indicating what tuner has been attached
> -- this is what you see twice.

Mike, thanks for the clarification that the behaviour is intended by
design. And looking at the events in conjunction with the above
explanation, it all makes sense:

tuner 1-0061: chip found @ 0xc2 (saa7133[0])
tuner-simple 1-0061: creating new instance
tuner-simple 1-0061: type set to 68 (Philips TUV1236D ATSC/NTSC dual in)
saa7133[0]: registered device video0 [v4l2]
saa7133[0]: registered device vbi0
dvb_init() allocating 1 frontend
nxt200x: NXT2004 Detected
tuner-simple 1-0061: attaching existing instance
tuner-simple 1-0061: type set to 68 (Philips TUV1236D ATSC/NTSC dual in)

 
hermann pitton wrote:
> For the second attach of hybrid tuners in digital mode we maybe should print something
> pointing to it.
>   

Yes, I agree -- adding something simple to the existing message here
might help any future cases of head-scratching by those less
knowledgeable of the intricacies.

Re: KWorld ATSC 115 all static

[David Engel]

On Tue, Feb 03, 2009 at 01:03:58AM -0500, CityK wrote:
> Nope, this thread is still alive and well -- I posted to it last Thurs
> (?), and Mauro replied, but I haven't had time to follow up with this
> since then. 

I never received received anythin after Jan. 18 and couldn't find
anything in the archives.  Strange.

> Anyway, here's a synopsis of the situation:

Thanks.

> - Further, somewhat concurrently, I discovered that (with Hans' kworld
> test repo) analog TV was ONLY working with tvtime ... xawtv/motv and
> kdetv were borked (I don't use Myth, so I have no idea what its status
> would be ... though, I'd suspect that it works like tvtime). I quickly

I will try it with MythTV.

David
-- 
David Engel
david@istwok.net

Re: KWorld ATSC 115 all static

[CityK]

David Engel wrote:
> I never received received anythin after Jan. 18 and couldn't find
> anything in the archives.  Strange.
>   

hermann pitton wrote:
> Am Dienstag, den 03.02.2009, 01:03 -0500 schrieb CityK:
>> - On Sunday Jan 25th I sent a lengthy message to the list... I went to the mailing list archive to
>> find a link for my message...only to discover it was NEVER achieved/recorded....grrrrr. So I'm at a complete loss as to who actually saw the Jan 25th message and who didn't.
>>     
>
> On Jan. 18 the copy to the video4linux-list was dropped.
> Some mailers by default have a limit there and the number of recipients
> must be increased manually, i don't think it was intentionally.
>
> However, all on linux-media should have received your postings and they
> are in the archives.
> http://www.spinics.net/lists/linux-media/msg00817.html
>   

LOL -- that's hilarious; I had checked both
http://www.mail-archive.com/linux-media@vger.kernel.org/thrd5.html#01125
and
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/203/focus=42489
and couldn't find it, so I didn't bother looking for it on spinics.
(Personally, I prefer neither of the 3 above archives, rather, I like
Marc, which I don't believe we've contacted yet ... I will bug Mauro
about this in a minute). I had figured that it might have been a
limitation with the message size. Anyway, good to know that the Jan 25th
message made its way to at least one archive.

>> - Further, somewhat concurrently, I discovered that (with Hans' kworld
>> test repo) analog TV was ONLY working with tvtime ... xawtv/motv and
>> kdetv were borked (I don't use Myth, so I have no idea what its status
>> would be ... though, I'd suspect that it works like tvtime).
>>     
>
> I will try it with MythTV.

Thanks David.

Re: KWorld ATSC 115 all static

[David Engel]

On Tue, Feb 03, 2009 at 11:07:56PM -0500, CityK wrote:
> David Engel wrote:
> > I will try it with MythTV.
> 
> Thanks David.

OK.  With Hans' v4l-dvb-kworld driver, MythTV works, but with a big
caveat.  I have to unload the saa7134-alsa, saa7134-dvb, saa7134 and
tuner-simple modules, reload them and then run tvtime before MythTV
works.  If I do things in any other order, MythTV doesn't report any
errors, but it only records static.  In addition, if I run MythTV
before running tvtime, tvtime only shows static too until I reload the
modules.  This pattern held for 3 reboots.

David
-- 
David Engel
david@istwok.net

Re: KWorld ATSC 115 all static

[hermann pitton]

Hi,

Am Dienstag, den 03.02.2009, 01:03 -0500 schrieb CityK:
> David Engel wrote:
> > As far as I can tell, this thread petered out without a resolution.  
> > CityK later posted on avsforum, however, that analog on his card was
> > after more changes by Hans.  I'm confused.  Is analog on the KWorld
> > 115 supposed to be working again or not?  I saw that some changes by
> > Hans made it into the main Hg repository, but as of yesterday, analog
> > still didn't work for me.
> >   
> 
> Nope, this thread is still alive and well -- I posted to it last Thurs
> (?), and Mauro replied, but I haven't had time to follow up with this
> since then. Anyway, here's a synopsis of the situation:
> 
> - Hans had a first go at the saa7134 (and related modules) in this work
> was in his v4l-dvb-saa7134 test repo .... these initial changes,
> unfortunately, were NOT sufficient on their own to get analog TV
> working. These changes did, however, get pulled into the mainline of v4l-dvb
> 
> - Hans' second attempt at this is found in his v4l-dvb-kworld test repo
> ... testing this code revealed that analog tv did indeed work again with
> tvtime ... I also noted that there seems to be a bit of redundancy now
> in terms of the tuner being initialized twice
> 
> - Mauro created a patch intended to be applied against mainline ... I
> tested and analog tv did NOT work

strange, that we don't see at least some error messages.

> - On Sunday Jan 25th I sent a lengthy message to the list, outlining
> some debug results etc. and also informing Mauro that his patch did NOT
> work ... I know that, at the very least, Trent and Hermann received that
> message, because they quoted from it in further discussion about the i2c
> gate (the inherent underlying problem at the heart of the issue).
> 
> - A few days later, scanning through the #irc logs, I caught a
> discussion, regarding Mauro's patch getting pulled into mainline, and
> the discussion seemed to indicate that there was some confusion as to
> what I had said worked and what doesn't. This surprised me for I had
> been pretty explicit in my Jan 25th mail list message. The other
> alternative was perhaps they simply had missed that message...so, in
> order to clear the situation up, I went to the mailing list archive to
> find a link for my message...only to discover it was NEVER
> achieved/recorded....grrrrr. So I'm at a complete loss as to who
> actually saw the Jan 25th message and who didn't.

On Jan. 18 the copy to the video4linux-list was dropped.
Some mailers by default have a limit there and the number of recipients
must be increased manually, i don't think it was intentionally.

However, all on linux-media should have received your postings and they
are in the archives.
http://www.spinics.net/lists/linux-media/msg00817.html

> - Further, somewhat concurrently, I discovered that (with Hans' kworld
> test repo) analog TV was ONLY working with tvtime ... xawtv/motv and
> kdetv were borked (I don't use Myth, so I have no idea what its status
> would be ... though, I'd suspect that it works like tvtime). I quickly
> traced this problem to be related to dga and Xv. A very similar
> situation with these apps existed several years ago when the proprietary
> X drivers from nvidia and ati removed dga functionality from their
> respective drivers (for some background read:
> http://www.nvnews.net/vbulletin/showthread.php?t=68232, and also the
> relevant portion of the FAQ from the nvidia readme:
> ftp://download.nvidia.com/XFree86/Linux-x86_64/180.27/README/chapter-07.html),
> however, the basic nv driver would still function. Nvidia would later
> provide a workaround to this issue in their driver.
> So, in this modern day occurrence of this similar error/bug, the obvious
> first test is to eliminate the proprietary driver from the equation.
> However, the test result with the nv driver was the same -- borked
> motv/xawtv and kdetv. I reported this, saying that I suspected that a
> something may have been introduced somewhere resulting in this issue
> with these apps resurfacing. This is why I asked that Hans' kworld repo
> NOT be pulled into mainline (if there had been any thought to that --
> though I don't think there was, because I now realize that I don't think
> many had even seen my prior Jan 25th message !) until further testing
> was performed.
> 
> - Mauro replied believing that this was unrelated to anything v4l-dvb,
> but rather an artefact of the X drivers. I suspected that that was NOT
> the case (the nv driver failing in my previous test was my cue). The
> next obvious test was to revert back to an older v4l-dvb snapshot that
> was patched with Mike Krufky's hack/workaround.
> 
> [reverting back should have been an easy task, but unfortunately I
> managed to turn it into a frustrating ordeal --- in the case of Hans'
> kworld source, the rminstall process did not blow away all the modules;
> further, while I had been testing channel scans with xawtv/motv/kdetv, I
> also tried with YAST, and unbeknownst to me, it must have saved an
> attempt at configing the ir remote --- so that, later, when no v4l-dvb
> modules were any longer present on the system, a config script somewhere
> must have been calling for the related remote control i2c-blah-blah-blah
> modules and the system would freeze, all too coincidently just when the
> nvidia x driver was starting up X ... and booting to failsafe and
> console mode was not working either (or at least not very well) ... so
> my initial belief that the very recent nvidia driver I installed had
> mucked up X, and that incorrect belief/assumption led to a masking of
> the real underlying problem for a while ... plus the fact that I really
> went off on a tangent messing around with xorg.conf and trying out some
> of the recent xinput modules etc etc ) .. anyway, as they say, all roads
> lead to Rome, and I eventually sorted everything out]
> 
> The older snapshot and Mike's patch worked as I expected it to. Removing
> that and installing Hans' kworld repo again --> xawtv/motv/kdetv = fail
> with Overlay. I can positively state, WITHOUT DOUBT, that there is
> something in Hans code that is sourcing this issue. I have not looked at
> it closely, nor do I know if I would recognise it when I do, though I
> suspect that it would be from initial batch of changes (inserted into
> the v4l-dvb-saa7134 repo).

I had a quick test on the in kernel radeon driver on Fedora 10 and
recent 2.6.27 with xawtv-3.95.

True is, that overlay-preview yields dga is not supported, but with
current v4l-dvb master and Hans' conversions mmap/grabdisplay works with
the old "xawtv -v 1 -nodga -remote -c /dev/video2" something.

Like you, I can't imagine that the earlier Kworld ATSC 110/15
initialization in Hans' kworld repo could be related to it.

> --------------------------------------------------------------------
> So the grand conclusion (aka state of the nation):
> --------------------------------------------------------------------
> 
> - how to provide a proper solution that will resolve the underlying i2c
> gate issue remains a point in discussion. In the meantime:
> 
> - Hans kworld repo:
> Pros: does provide analog tv functionality for, at a minimum, tvtime.
> Cons: The changes introduced result in, as testing to date has shown, a
> harmless bit of duplication in the way of the tuner being loaded twice.
> kdetv/motv/xawtv, at a minimum, do not work in overlay mode.

I can test on nv drivers as well next, they might have dropped support
for it too and just the x capabilies should be reported. For the second
attach of hybrid tuners in digital mode we maybe should print something
pointing to it.

> - Mainline v4l-dvb:
> Pros: none ... you will achieve this thread's namesake -- all static.
> Cons: since the code from Hans' v4l-dvb-saa7134 repo was merged, Mike's
> hack/workaround patch has been rendered ineffective for good. Mauro's
> later patch was also pulled into mainline, but it does not change the
> situation analog tv (and I do not mean in relation to Mike's patch, I
> mean precisely upon its own).
> 
> - Mike's hack/workaround patch
> Pros: it will apply and work with snapshots of v4l-dvb up to probably ~
> Jan 15th or so. All the apps that I tested with work as expected.
> Cons: in order to use analog tv, upon each boot, one must do what I
> termed being a dance with unloading and reloading the tuner module via
> modprobe.

I'm not sure if we even have the status of all devices potentially
seeing impacts, but reloading modules becomes more difficult, since we
load now saa7134-alsa by default. This will cause that apps like mixers
on runlevel 5 need to be closed before you can unload/reload
saa7134-alsa and saa7134 and then further any tuner modules.

This is fine for all the cards without such problems, but else one must
be aware off. With "options saa7134 alsa=0" the old behaviour is
restored.

Mauro also disabled saa7134-alsa support on saa7130 devices, which
simply do not support it and the deprecated saa7134-oss. Thanks! 

> - And finally, as an end note, DVB does, and always has, continue to
> work. As I eluded to earlier (somewhere within this growing thread), the
> assignment of RF input spigots has changed several times for these cards
> throughout the course of their Linux driver(s)'s lifetime. Currently, by
> default:
> DVB - digital cable is now accessed through the lower input. OTA/ATSC
> off the top input. ... this configuration is opposite to that which
> users of 2.6.24 era kernels are familiar with.
> Analog TV - regardless of whether ota or through cable is also off the
> top input.

Cheers,
Hermann

Re: KWorld ATSC 115 all static

[CityK]

hermann pitton wrote:
> Am Dienstag, den 03.02.2009, 01:03 -0500 schrieb CityK:
>   
>> - Mauro created a patch intended to be applied against mainline ... I
>> tested and analog tv did NOT work
>>     
>
> strange, that we don't see at least some error messages.
>   

Indeed, on a quick glance, the output looks entirely indifferent

hermann pitton wrote:
> I had a quick test on the in kernel radeon driver on Fedora 10 and
> recent 2.6.27 with xawtv-3.95.
> True is, that overlay-preview yields dga is not supported, but with
> current v4l-dvb master and Hans' conversions mmap/grabdisplay works with
> the old "xawtv -v 1 -nodga -remote -c /dev/video2" something.
>   
Yep, as I menitoned: 
http://www.mail-archive.com/linux-media@vger.kernel.org/msg00989.html. 
In regards the hit and miss functionality I mentioned with kdetv, the
pattern was simple:  grabdisplay v4l1 mode would work only after having
just used tvtime.  Similarly, in the v4l2 mode, after having just used
tvtime, one can observe a momentary flicker of video (i.e. lasting only
a few hundredths of a second) from a channel before it reverted to all
static.

Additionally, when the apps fail in overlay mode, and are displaying all
static, you can actually simultaneously open up one of the digital apps
(take your pick; kaffeine, MPlayer...) and successfully watch dvb.

hermann pitton wrote:
> Like you, I can't imagine that the earlier Kworld ATSC 110/15
> initialization in Hans' kworld repo could be related to it.
>   

No, no -- Mauro doubts it.  I,  on the other hand, suspect that there
has been something innocuous introduced  within the new v4l2 framework
that is causing this.

hermann pitton wrote:
> I can test on nv drivers as well next, they might have dropped support for it too and just the x capabilies should be reported.

Nope -- as I mentioned, dropping back to a snapshot from roughly 3 weeks
ago and applying Mike's patch works with both the nv and nvidia driver,
hence disproving that it is anything X related. 


>> - Mainline v4l-dvb:
>> Pros: none ... you will achieve this thread's namesake -- all static.
>> Cons: since the code from Hans' v4l-dvb-saa7134 repo was merged, Mike's
>> hack/workaround patch has been rendered ineffective for good. Mauro's
>> later patch was also pulled into mainline, but it does not change the
>> situation analog tv (and I do not mean in relation to Mike's patch, I
>> mean precisely upon its own).
>>
>> - Mike's hack/workaround patch
>> Pros: it will apply and work with snapshots of v4l-dvb up to probably ~
>> Jan 15th or so. All the apps that I tested with work as expected.
>> Cons: in order to use analog tv, upon each boot, one must do what I
>> termed being a dance with unloading and reloading the tuner module via
>> modprobe.
>>     
>
> I'm not sure if we even have the status of all devices potentially
> seeing impacts, but reloading modules becomes more difficult, since we
> load now saa7134-alsa by default. This will cause that apps like mixers
> on runlevel 5 need to be closed before you can unload/reload
> saa7134-alsa and saa7134 and then further any tuner modules.
>
> This is fine for all the cards without such problems, but else one must
> be aware off. With "options saa7134 alsa=0" the old behaviour is
> restored.
>
> Mauro also disabled saa7134-alsa support on saa7130 devices, which
> simply do not support it and the deprecated saa7134-oss. Thanks! 
>   

And speaking of alsa:

CityK wrote (Jan 19th):
> Some Other Miscellanea:
>
> 2) This is likely related to the discussion about the gate -- after
> closing the analog TV app, the audio from the last channel being viewed
> can still be heard if one turns up the volume on their system.  This
> leakage has always been present.  But given that we are addressing this
> issue now, it strikes me that the gate is being kept open on the audio
> line after application closing/release occurs.
>   

This issue seems to have been resolved since having updated to the ALSA
1.0.19 release from a couple of weeks ago (which literally contained a
zillion fixes, so I'm not going to bother trying to figure out which one
might have been the fix).. 

Re: KWorld ATSC 115 all static

[hermann pitton]

Hi,

please take this as preliminary only.

Am Mittwoch, den 04.02.2009, 00:26 -0500 schrieb CityK:
> hermann pitton wrote:
> > Am Dienstag, den 03.02.2009, 01:03 -0500 schrieb CityK:
> >   
> >> - Mauro created a patch intended to be applied against mainline ... I
> >> tested and analog tv did NOT work
> >>     
> >
> > strange, that we don't see at least some error messages.
> >   
> 
> Indeed, on a quick glance, the output looks entirely indifferent

At least the digital demod takes all without any hick up and does not
report what it is doing next. The messages are sent from the saa713x.

> hermann pitton wrote:
> > I had a quick test on the in kernel radeon driver on Fedora 10 and
> > recent 2.6.27 with xawtv-3.95.
> > True is, that overlay-preview yields dga is not supported, but with
> > current v4l-dvb master and Hans' conversions mmap/grabdisplay works with
> > the old "xawtv -v 1 -nodga -remote -c /dev/video2" something.
> >   
> Yep, as I menitoned: 
> http://www.mail-archive.com/linux-media@vger.kernel.org/msg00989.html. 
> In regards the hit and miss functionality I mentioned with kdetv, the
> pattern was simple:  grabdisplay v4l1 mode would work only after having
> just used tvtime.  Similarly, in the v4l2 mode, after having just used
> tvtime, one can observe a momentary flicker of video (i.e. lasting only
> a few hundredths of a second) from a channel before it reverted to all
> static.
> 
> Additionally, when the apps fail in overlay mode, and are displaying all
> static, you can actually simultaneously open up one of the digital apps
> (take your pick; kaffeine, MPlayer...) and successfully watch dvb.

Open simultaneously is known since ever.
Harder it becomes here.
http://bugzilla.kernel.org/show_bug.cgi?id=10036

Seems I must reread it all or you point me to something to reproduce it.

BTW, using mplayer causes troubles for some apps to get the hardware
Overlay back, not overlay-preview, but not for tvtime. 

> hermann pitton wrote:
> > Like you, I can't imagine that the earlier Kworld ATSC 110/15
> > initialization in Hans' kworld repo could be related to it.
> >   
> 
> No, no -- Mauro doubts it.  I,  on the other hand, suspect that there
> has been something innocuous introduced  within the new v4l2 framework
> that is causing this.

The latter I can't confirm so far and, IIRC, Mauro said he does not
expect that it is related to our driver.

> hermann pitton wrote:
> > I can test on nv drivers as well next, they might have dropped support for it too and just the x capabilies should be reported.
> 
> Nope -- as I mentioned, dropping back to a snapshot from roughly 3 weeks
> ago and applying Mike's patch works with both the nv and nvidia driver,
> hence disproving that it is anything X related. 
> 
> 
> >> - Mainline v4l-dvb:
> >> Pros: none ... you will achieve this thread's namesake -- all static.
> >> Cons: since the code from Hans' v4l-dvb-saa7134 repo was merged, Mike's
> >> hack/workaround patch has been rendered ineffective for good. Mauro's
> >> later patch was also pulled into mainline, but it does not change the
> >> situation analog tv (and I do not mean in relation to Mike's patch, I
> >> mean precisely upon its own).
> >>
> >> - Mike's hack/workaround patch
> >> Pros: it will apply and work with snapshots of v4l-dvb up to probably ~
> >> Jan 15th or so. All the apps that I tested with work as expected.
> >> Cons: in order to use analog tv, upon each boot, one must do what I
> >> termed being a dance with unloading and reloading the tuner module via
> >> modprobe.
> >>     
> >
> > I'm not sure if we even have the status of all devices potentially
> > seeing impacts, but reloading modules becomes more difficult, since we
> > load now saa7134-alsa by default. This will cause that apps like mixers
> > on runlevel 5 need to be closed before you can unload/reload
> > saa7134-alsa and saa7134 and then further any tuner modules.
> >
> > This is fine for all the cards without such problems, but else one must
> > be aware off. With "options saa7134 alsa=0" the old behaviour is
> > restored.
> >
> > Mauro also disabled saa7134-alsa support on saa7130 devices, which
> > simply do not support it and the deprecated saa7134-oss. Thanks! 
> >   
> 
> And speaking of alsa:
> 
> CityK wrote (Jan 19th):
> > Some Other Miscellanea:
> >
> > 2) This is likely related to the discussion about the gate -- after
> > closing the analog TV app, the audio from the last channel being viewed
> > can still be heard if one turns up the volume on their system.  This
> > leakage has always been present.  But given that we are addressing this
> > issue now, it strikes me that the gate is being kept open on the audio
> > line after application closing/release occurs.
> >   
> 
> This issue seems to have been resolved since having updated to the ALSA
> 1.0.19 release from a couple of weeks ago (which literally contained a
> zillion fixes, so I'm not going to bother trying to figure out which one
> might have been the fix).. 

This would need closer insight and I can't reproduce it either on
saa7131e. The saa7134 has some specials for mute, not to talk about the
saa7130.

It should not be related to any ALSA versions, except you might be
talking about your sound card mixer.

The hardware mute always happens in saa7134-tvaudio and saa7134-alsa
only uses an exported symbol for that (Ricardo for mythtv).

The analog and i2s/dma sound can be muted separately by different
registers. The i2s/dma was previously always enabled for possible mpeg
encoders waiting for it, but this was changed in 2005 for all the
cardbus and others without any analog audio out. Maybe not all
saa7133/35/31e chips are equally covered, but I can't tell ;)

Cheers,
Hermann

Re: KWorld ATSC 115 all static

[Mauro Carvalho Chehab]

On Wed, 04 Feb 2009 00:26:06 -0500
CityK <cityk@rogers.com> wrote:

> Nope -- as I mentioned, dropping back to a snapshot from roughly 3 weeks
> ago and applying Mike's patch works with both the nv and nvidia driver,
> hence disproving that it is anything X related. 

CityK,

It seems I missed your email with the detailed logs.

Let's go by parts: Let's first try to solve the issue with the i2c gate, in
order to have both analog and digital modes to work properly. After having it
fixed, we can go ahead and check if the issue with some softwares are a
regression at the driver (or at v4l core) or something else at X space.

Could you please send me the logs of the driver of it working (old tree +
Mike's patch) and not working (with current tip)?

Please load it with the following debug options:
	modprobe saa7134 i2c_scan=1 video_debug=3 core_debug=1 i2c_debug=1

Btw, I have one PCMCIA board with me that stopped working with Hans patches
applied at tip. So, I suspect that some regression were caused by the i2c
conversion. I'll use this board to debug the driver.

Cheers,
Mauro

Re: KWorld ATSC 115 all static

[Mauro Carvalho Chehab]

On Sun, 8 Feb 2009 08:07:47 -0200
Mauro Carvalho Chehab <mchehab@infradead.org> wrote:

> On Wed, 04 Feb 2009 00:26:06 -0500
> CityK <cityk@rogers.com> wrote:
> 
> > Nope -- as I mentioned, dropping back to a snapshot from roughly 3 weeks
> > ago and applying Mike's patch works with both the nv and nvidia driver,
> > hence disproving that it is anything X related. 
> 
> CityK,
> 
> It seems I missed your email with the detailed logs.
> 
> Let's go by parts: Let's first try to solve the issue with the i2c gate, in
> order to have both analog and digital modes to work properly. After having it
> fixed, we can go ahead and check if the issue with some softwares are a
> regression at the driver (or at v4l core) or something else at X space.
> 
> Could you please send me the logs of the driver of it working (old tree +
> Mike's patch) and not working (with current tip)?
> 
> Please load it with the following debug options:
> 	modprobe saa7134 i2c_scan=1 video_debug=3 core_debug=1 i2c_debug=1

Also, please test the new code I made available at:

	http://linuxtv.org/hg/~mchehab/saa7134

It contains a code that will hopefully fix this issue.

> Btw, I have one PCMCIA board with me that stopped working with Hans patches
> applied at tip. So, I suspect that some regression were caused by the i2c
> conversion. I'll use this board to debug the driver.

The issue here seems to be unrelated: sometimes, tda8290/tda8275 is not
detected on my MSI TV@nyware A/D NB device. The chip simply stops answering at
address 0x4b (7bit notation). Not sure why and not sure if this is a regression
or not. Anyway, while debugging it, I noticed that the i2c gate control for
those devices were broken. I wrote some patches to fix (also at the same tree),
but this didn't solve the issue (it will probably solve another issue with
sleep/wakeup on this device).

Michael,

Please take a look at the tda8290/tda827x patches

Cheers,
Mauro

Re: KWorld ATSC 115 all static

[Mauro Carvalho Chehab]

On Tue, 03 Feb 2009 01:03:58 -0500
CityK <cityk@rogers.com> wrote:

> David Engel wrote:
> > As far as I can tell, this thread petered out without a resolution.  
> > CityK later posted on avsforum, however, that analog on his card was
> > after more changes by Hans.  I'm confused.  Is analog on the KWorld
> > 115 supposed to be working again or not?  I saw that some changes by
> > Hans made it into the main Hg repository, but as of yesterday, analog
> > still didn't work for me.
> >   
> 
> Nope, this thread is still alive and well -- I posted to it last Thurs
> (?), and Mauro replied, but I haven't had time to follow up with this
> since then. Anyway, here's a synopsis of the situation:
> 
> - Hans had a first go at the saa7134 (and related modules) in this work
> was in his v4l-dvb-saa7134 test repo .... these initial changes,
> unfortunately, were NOT sufficient on their own to get analog TV
> working. These changes did, however, get pulled into the mainline of v4l-dvb
> 
> - Hans' second attempt at this is found in his v4l-dvb-kworld test repo
> ... testing this code revealed that analog tv did indeed work again with
> tvtime ... I also noted that there seems to be a bit of redundancy now
> in terms of the tuner being initialized twice
> 
> - Mauro created a patch intended to be applied against mainline ... I
> tested and analog tv did NOT work
> 
> - On Sunday Jan 25th I sent a lengthy message to the list, outlining
> some debug results etc. and also informing Mauro that his patch did NOT
> work ... I know that, at the very least, Trent and Hermann received that
> message, because they quoted from it in further discussion about the i2c
> gate (the inherent underlying problem at the heart of the issue).
> 
> - A few days later, scanning through the #irc logs, I caught a
> discussion, regarding Mauro's patch getting pulled into mainline, and
> the discussion seemed to indicate that there was some confusion as to
> what I had said worked and what doesn't. This surprised me for I had
> been pretty explicit in my Jan 25th mail list message. The other
> alternative was perhaps they simply had missed that message...so, in
> order to clear the situation up, I went to the mailing list archive to
> find a link for my message...only to discover it was NEVER
> achieved/recorded....grrrrr. So I'm at a complete loss as to who
> actually saw the Jan 25th message and who didn't.
> 
> - Further, somewhat concurrently, I discovered that (with Hans' kworld
> test repo) analog TV was ONLY working with tvtime ... xawtv/motv and
> kdetv were borked (I don't use Myth, so I have no idea what its status
> would be ... though, I'd suspect that it works like tvtime). I quickly
> traced this problem to be related to dga and Xv. A very similar
> situation with these apps existed several years ago when the proprietary
> X drivers from nvidia and ati removed dga functionality from their
> respective drivers (for some background read:
> http://www.nvnews.net/vbulletin/showthread.php?t=68232, and also the
> relevant portion of the FAQ from the nvidia readme:
> ftp://download.nvidia.com/XFree86/Linux-x86_64/180.27/README/chapter-07.html),
> however, the basic nv driver would still function. Nvidia would later
> provide a workaround to this issue in their driver.
> So, in this modern day occurrence of this similar error/bug, the obvious
> first test is to eliminate the proprietary driver from the equation.
> However, the test result with the nv driver was the same -- borked
> motv/xawtv and kdetv. I reported this, saying that I suspected that a
> something may have been introduced somewhere resulting in this issue
> with these apps resurfacing. This is why I asked that Hans' kworld repo
> NOT be pulled into mainline (if there had been any thought to that --
> though I don't think there was, because I now realize that I don't think
> many had even seen my prior Jan 25th message !) until further testing
> was performed.
> 
> - Mauro replied believing that this was unrelated to anything v4l-dvb,
> but rather an artefact of the X drivers. I suspected that that was NOT
> the case (the nv driver failing in my previous test was my cue). The
> next obvious test was to revert back to an older v4l-dvb snapshot that
> was patched with Mike Krufky's hack/workaround.

It took me some time today to bisect and trying to see what's going wrong with
some userspace apps. 

At the end, I discovered that changeset 10240 fixes a bug that affected some
userspace bad behaviour of setting defaults to zero, if a control is not found.

Due to that userspace bad behaviour, both tvtime and xawtv were using 0 for all
video controls (brightness, contrast, color, hue). The practical effect is that
a black image were displayed.

The fix were as simple as putting all controls at 50%.

Could this be your case also?

Cheers,
Mauro

Re: KWorld ATSC 115 all static

[Mauro Carvalho Chehab]

On Tue, 03 Feb 2009 01:03:58 -0500
CityK <cityk@rogers.com> wrote:

> David Engel wrote:
> > As far as I can tell, this thread petered out without a resolution.  
> > CityK later posted on avsforum, however, that analog on his card was
> > after more changes by Hans.  I'm confused.  Is analog on the KWorld
> > 115 supposed to be working again or not?  I saw that some changes by
> > Hans made it into the main Hg repository, but as of yesterday, analog
> > still didn't work for me.
> >   
> 
> Nope, this thread is still alive and well -- I posted to it last Thurs
> (?), and Mauro replied, but I haven't had time to follow up with this
> since then. Anyway, here's a synopsis of the situation:
> 
> - Hans had a first go at the saa7134 (and related modules) in this work
> was in his v4l-dvb-saa7134 test repo .... these initial changes,
> unfortunately, were NOT sufficient on their own to get analog TV
> working. These changes did, however, get pulled into the mainline of v4l-dvb
> 
> - Hans' second attempt at this is found in his v4l-dvb-kworld test repo
> ... testing this code revealed that analog tv did indeed work again with
> tvtime ... I also noted that there seems to be a bit of redundancy now
> in terms of the tuner being initialized twice
> 
> - Mauro created a patch intended to be applied against mainline ... I
> tested and analog tv did NOT work
> 
> - On Sunday Jan 25th I sent a lengthy message to the list, outlining
> some debug results etc. and also informing Mauro that his patch did NOT
> work ... I know that, at the very least, Trent and Hermann received that
> message, because they quoted from it in further discussion about the i2c
> gate (the inherent underlying problem at the heart of the issue).
> 
> - A few days later, scanning through the #irc logs, I caught a
> discussion, regarding Mauro's patch getting pulled into mainline, and
> the discussion seemed to indicate that there was some confusion as to
> what I had said worked and what doesn't. This surprised me for I had
> been pretty explicit in my Jan 25th mail list message. The other
> alternative was perhaps they simply had missed that message...so, in
> order to clear the situation up, I went to the mailing list archive to
> find a link for my message...only to discover it was NEVER
> achieved/recorded....grrrrr. So I'm at a complete loss as to who
> actually saw the Jan 25th message and who didn't.
> 
> - Further, somewhat concurrently, I discovered that (with Hans' kworld
> test repo) analog TV was ONLY working with tvtime ... xawtv/motv and
> kdetv were borked (I don't use Myth, so I have no idea what its status
> would be ... though, I'd suspect that it works like tvtime). I quickly
> traced this problem to be related to dga and Xv. A very similar
> situation with these apps existed several years ago when the proprietary
> X drivers from nvidia and ati removed dga functionality from their
> respective drivers (for some background read:
> http://www.nvnews.net/vbulletin/showthread.php?t=68232, and also the
> relevant portion of the FAQ from the nvidia readme:
> ftp://download.nvidia.com/XFree86/Linux-x86_64/180.27/README/chapter-07.html),
> however, the basic nv driver would still function. Nvidia would later
> provide a workaround to this issue in their driver.
> So, in this modern day occurrence of this similar error/bug, the obvious
> first test is to eliminate the proprietary driver from the equation.
> However, the test result with the nv driver was the same -- borked
> motv/xawtv and kdetv. I reported this, saying that I suspected that a
> something may have been introduced somewhere resulting in this issue
> with these apps resurfacing. This is why I asked that Hans' kworld repo
> NOT be pulled into mainline (if there had been any thought to that --
> though I don't think there was, because I now realize that I don't think
> many had even seen my prior Jan 25th message !) until further testing
> was performed.
> 
> - Mauro replied believing that this was unrelated to anything v4l-dvb,
> but rather an artefact of the X drivers. I suspected that that was NOT
> the case (the nv driver failing in my previous test was my cue). The
> next obvious test was to revert back to an older v4l-dvb snapshot that
> was patched with Mike Krufky's hack/workaround.

It took me some time today to bisect and trying to see what's going wrong with
some userspace apps. 

At the end, I discovered that changeset 10240 fixed a bug that affected some
userspace bad behaviour of setting defaults to zero, if a control is not found.

Due to that userspace bad behaviour, both tvtime and xawtv were using 0 for all
video controls (brightness, contrast, color, hue). The practical effect is that
a black image were displayed.

The fix were as simple as putting all controls at 50%.

Could this be your case also?

Cheers,
Mauro

Re: KWorld ATSC 115 all static

[hermann pitton]

Am Montag, den 09.02.2009, 00:43 -0200 schrieb Mauro Carvalho Chehab:
> On Tue, 03 Feb 2009 01:03:58 -0500
> CityK <cityk@rogers.com> wrote:
> 
> > David Engel wrote:
> > > As far as I can tell, this thread petered out without a resolution.  
> > > CityK later posted on avsforum, however, that analog on his card was
> > > after more changes by Hans.  I'm confused.  Is analog on the KWorld
> > > 115 supposed to be working again or not?  I saw that some changes by
> > > Hans made it into the main Hg repository, but as of yesterday, analog
> > > still didn't work for me.
> > >   
> > 
> > Nope, this thread is still alive and well -- I posted to it last Thurs
> > (?), and Mauro replied, but I haven't had time to follow up with this
> > since then. Anyway, here's a synopsis of the situation:
> > 
> > - Hans had a first go at the saa7134 (and related modules) in this work
> > was in his v4l-dvb-saa7134 test repo .... these initial changes,
> > unfortunately, were NOT sufficient on their own to get analog TV
> > working. These changes did, however, get pulled into the mainline of v4l-dvb
> > 
> > - Hans' second attempt at this is found in his v4l-dvb-kworld test repo
> > ... testing this code revealed that analog tv did indeed work again with
> > tvtime ... I also noted that there seems to be a bit of redundancy now
> > in terms of the tuner being initialized twice
> > 
> > - Mauro created a patch intended to be applied against mainline ... I
> > tested and analog tv did NOT work
> > 
> > - On Sunday Jan 25th I sent a lengthy message to the list, outlining
> > some debug results etc. and also informing Mauro that his patch did NOT
> > work ... I know that, at the very least, Trent and Hermann received that
> > message, because they quoted from it in further discussion about the i2c
> > gate (the inherent underlying problem at the heart of the issue).
> > 
> > - A few days later, scanning through the #irc logs, I caught a
> > discussion, regarding Mauro's patch getting pulled into mainline, and
> > the discussion seemed to indicate that there was some confusion as to
> > what I had said worked and what doesn't. This surprised me for I had
> > been pretty explicit in my Jan 25th mail list message. The other
> > alternative was perhaps they simply had missed that message...so, in
> > order to clear the situation up, I went to the mailing list archive to
> > find a link for my message...only to discover it was NEVER
> > achieved/recorded....grrrrr. So I'm at a complete loss as to who
> > actually saw the Jan 25th message and who didn't.
> > 
> > - Further, somewhat concurrently, I discovered that (with Hans' kworld
> > test repo) analog TV was ONLY working with tvtime ... xawtv/motv and
> > kdetv were borked (I don't use Myth, so I have no idea what its status
> > would be ... though, I'd suspect that it works like tvtime). I quickly
> > traced this problem to be related to dga and Xv. A very similar
> > situation with these apps existed several years ago when the proprietary
> > X drivers from nvidia and ati removed dga functionality from their
> > respective drivers (for some background read:
> > http://www.nvnews.net/vbulletin/showthread.php?t=68232, and also the
> > relevant portion of the FAQ from the nvidia readme:
> > ftp://download.nvidia.com/XFree86/Linux-x86_64/180.27/README/chapter-07.html),
> > however, the basic nv driver would still function. Nvidia would later
> > provide a workaround to this issue in their driver.
> > So, in this modern day occurrence of this similar error/bug, the obvious
> > first test is to eliminate the proprietary driver from the equation.
> > However, the test result with the nv driver was the same -- borked
> > motv/xawtv and kdetv. I reported this, saying that I suspected that a
> > something may have been introduced somewhere resulting in this issue
> > with these apps resurfacing. This is why I asked that Hans' kworld repo
> > NOT be pulled into mainline (if there had been any thought to that --
> > though I don't think there was, because I now realize that I don't think
> > many had even seen my prior Jan 25th message !) until further testing
> > was performed.
> > 
> > - Mauro replied believing that this was unrelated to anything v4l-dvb,
> > but rather an artefact of the X drivers. I suspected that that was NOT
> > the case (the nv driver failing in my previous test was my cue). The
> > next obvious test was to revert back to an older v4l-dvb snapshot that
> > was patched with Mike Krufky's hack/workaround.
> 
> It took me some time today to bisect and trying to see what's going wrong with
> some userspace apps. 
> 
> At the end, I discovered that changeset 10240 fixed a bug that affected some
> userspace bad behaviour of setting defaults to zero, if a control is not found.
> 
> Due to that userspace bad behaviour, both tvtime and xawtv were using 0 for all
> video controls (brightness, contrast, color, hue). The practical effect is that
> a black image were displayed.
> 
> The fix were as simple as putting all controls at 50%.
> 
> Could this be your case also?
> 
> Cheers,
> Mauro
> 

Mauro, I know you are waiting for CityK, but I can report so far that I
never did see that black screen going away by adjusting the controls and
never had that black screen.

Tvtime and xawtv were always working under my conditions so far.

The very old troubles, like tda9887 not present after boot on my md7134
devices with FMD1216ME MK3 hybrid, and the even unrelated issue with the
tda10046 not properly controlled anymore after suspend/resume,
are unchanged on your current saa7134 attempt, but also no new issues
visible so far.

Cheers,
Hermann

Re: KWorld ATSC 115 all static

[hermann pitton]

Am Dienstag, den 10.02.2009, 01:37 +0100 schrieb hermann pitton:
> Am Montag, den 09.02.2009, 00:43 -0200 schrieb Mauro Carvalho Chehab:
> > On Tue, 03 Feb 2009 01:03:58 -0500
> > CityK <cityk@rogers.com> wrote:
> > 
> > > David Engel wrote:
> > > > As far as I can tell, this thread petered out without a resolution.  
> > > > CityK later posted on avsforum, however, that analog on his card was
> > > > after more changes by Hans.  I'm confused.  Is analog on the KWorld
> > > > 115 supposed to be working again or not?  I saw that some changes by
> > > > Hans made it into the main Hg repository, but as of yesterday, analog
> > > > still didn't work for me.
> > > >   
> > > 
> > > Nope, this thread is still alive and well -- I posted to it last Thurs
> > > (?), and Mauro replied, but I haven't had time to follow up with this
> > > since then. Anyway, here's a synopsis of the situation:
> > > 
> > > - Hans had a first go at the saa7134 (and related modules) in this work
> > > was in his v4l-dvb-saa7134 test repo .... these initial changes,
> > > unfortunately, were NOT sufficient on their own to get analog TV
> > > working. These changes did, however, get pulled into the mainline of v4l-dvb
> > > 
> > > - Hans' second attempt at this is found in his v4l-dvb-kworld test repo
> > > ... testing this code revealed that analog tv did indeed work again with
> > > tvtime ... I also noted that there seems to be a bit of redundancy now
> > > in terms of the tuner being initialized twice
> > > 
> > > - Mauro created a patch intended to be applied against mainline ... I
> > > tested and analog tv did NOT work
> > > 
> > > - On Sunday Jan 25th I sent a lengthy message to the list, outlining
> > > some debug results etc. and also informing Mauro that his patch did NOT
> > > work ... I know that, at the very least, Trent and Hermann received that
> > > message, because they quoted from it in further discussion about the i2c
> > > gate (the inherent underlying problem at the heart of the issue).
> > > 
> > > - A few days later, scanning through the #irc logs, I caught a
> > > discussion, regarding Mauro's patch getting pulled into mainline, and
> > > the discussion seemed to indicate that there was some confusion as to
> > > what I had said worked and what doesn't. This surprised me for I had
> > > been pretty explicit in my Jan 25th mail list message. The other
> > > alternative was perhaps they simply had missed that message...so, in
> > > order to clear the situation up, I went to the mailing list archive to
> > > find a link for my message...only to discover it was NEVER
> > > achieved/recorded....grrrrr. So I'm at a complete loss as to who
> > > actually saw the Jan 25th message and who didn't.
> > > 
> > > - Further, somewhat concurrently, I discovered that (with Hans' kworld
> > > test repo) analog TV was ONLY working with tvtime ... xawtv/motv and
> > > kdetv were borked (I don't use Myth, so I have no idea what its status
> > > would be ... though, I'd suspect that it works like tvtime). I quickly
> > > traced this problem to be related to dga and Xv. A very similar
> > > situation with these apps existed several years ago when the proprietary
> > > X drivers from nvidia and ati removed dga functionality from their
> > > respective drivers (for some background read:
> > > http://www.nvnews.net/vbulletin/showthread.php?t=68232, and also the
> > > relevant portion of the FAQ from the nvidia readme:
> > > ftp://download.nvidia.com/XFree86/Linux-x86_64/180.27/README/chapter-07.html),
> > > however, the basic nv driver would still function. Nvidia would later
> > > provide a workaround to this issue in their driver.
> > > So, in this modern day occurrence of this similar error/bug, the obvious
> > > first test is to eliminate the proprietary driver from the equation.
> > > However, the test result with the nv driver was the same -- borked
> > > motv/xawtv and kdetv. I reported this, saying that I suspected that a
> > > something may have been introduced somewhere resulting in this issue
> > > with these apps resurfacing. This is why I asked that Hans' kworld repo
> > > NOT be pulled into mainline (if there had been any thought to that --
> > > though I don't think there was, because I now realize that I don't think
> > > many had even seen my prior Jan 25th message !) until further testing
> > > was performed.
> > > 
> > > - Mauro replied believing that this was unrelated to anything v4l-dvb,
> > > but rather an artefact of the X drivers. I suspected that that was NOT
> > > the case (the nv driver failing in my previous test was my cue). The
> > > next obvious test was to revert back to an older v4l-dvb snapshot that
> > > was patched with Mike Krufky's hack/workaround.
> > 
> > It took me some time today to bisect and trying to see what's going wrong with
> > some userspace apps. 
> > 
> > At the end, I discovered that changeset 10240 fixed a bug that affected some
> > userspace bad behaviour of setting defaults to zero, if a control is not found.
> > 
> > Due to that userspace bad behaviour, both tvtime and xawtv were using 0 for all
> > video controls (brightness, contrast, color, hue). The practical effect is that
> > a black image were displayed.
> > 
> > The fix were as simple as putting all controls at 50%.
> > 
> > Could this be your case also?
> > 
> > Cheers,
> > Mauro
> > 
> 
> Mauro, I know you are waiting for CityK, but I can report so far that I
> never did see that black screen going away by adjusting the controls and
> never had that black screen.
> 
> Tvtime and xawtv were always working under my conditions so far.
> 
> The very old troubles, like tda9887 not present after boot on my md7134
> devices with FMD1216ME MK3 hybrid, and the even unrelated issue with the
> tda10046 not properly controlled anymore after suspend/resume,
> are unchanged on your current saa7134 attempt, but also no new issues
> visible so far.
> 

BTW, just to remember.

Tvtime with signal detection on shows a blue screen without signal.
With signal detection off, just good old snow.

The tda8275/75a shows a black screen without having lock, not even snow,
if it should be related.

Cheers,
Hermann

Re: KWorld ATSC 115 all static

[hermann pitton]

Am Dienstag, den 10.02.2009, 01:54 +0100 schrieb hermann pitton:
> Am Dienstag, den 10.02.2009, 01:37 +0100 schrieb hermann pitton:
> > Am Montag, den 09.02.2009, 00:43 -0200 schrieb Mauro Carvalho Chehab:
> > > On Tue, 03 Feb 2009 01:03:58 -0500
> > > CityK <cityk@rogers.com> wrote:
> > > 
> > > > David Engel wrote:
> > > > > As far as I can tell, this thread petered out without a resolution.  
> > > > > CityK later posted on avsforum, however, that analog on his card was
> > > > > after more changes by Hans.  I'm confused.  Is analog on the KWorld
> > > > > 115 supposed to be working again or not?  I saw that some changes by
> > > > > Hans made it into the main Hg repository, but as of yesterday, analog
> > > > > still didn't work for me.
> > > > >   
> > > > 
> > > > Nope, this thread is still alive and well -- I posted to it last Thurs
> > > > (?), and Mauro replied, but I haven't had time to follow up with this
> > > > since then. Anyway, here's a synopsis of the situation:
> > > > 
> > > > - Hans had a first go at the saa7134 (and related modules) in this work
> > > > was in his v4l-dvb-saa7134 test repo .... these initial changes,
> > > > unfortunately, were NOT sufficient on their own to get analog TV
> > > > working. These changes did, however, get pulled into the mainline of v4l-dvb
> > > > 
> > > > - Hans' second attempt at this is found in his v4l-dvb-kworld test repo
> > > > ... testing this code revealed that analog tv did indeed work again with
> > > > tvtime ... I also noted that there seems to be a bit of redundancy now
> > > > in terms of the tuner being initialized twice
> > > > 
> > > > - Mauro created a patch intended to be applied against mainline ... I
> > > > tested and analog tv did NOT work
> > > > 
> > > > - On Sunday Jan 25th I sent a lengthy message to the list, outlining
> > > > some debug results etc. and also informing Mauro that his patch did NOT
> > > > work ... I know that, at the very least, Trent and Hermann received that
> > > > message, because they quoted from it in further discussion about the i2c
> > > > gate (the inherent underlying problem at the heart of the issue).
> > > > 
> > > > - A few days later, scanning through the #irc logs, I caught a
> > > > discussion, regarding Mauro's patch getting pulled into mainline, and
> > > > the discussion seemed to indicate that there was some confusion as to
> > > > what I had said worked and what doesn't. This surprised me for I had
> > > > been pretty explicit in my Jan 25th mail list message. The other
> > > > alternative was perhaps they simply had missed that message...so, in
> > > > order to clear the situation up, I went to the mailing list archive to
> > > > find a link for my message...only to discover it was NEVER
> > > > achieved/recorded....grrrrr. So I'm at a complete loss as to who
> > > > actually saw the Jan 25th message and who didn't.
> > > > 
> > > > - Further, somewhat concurrently, I discovered that (with Hans' kworld
> > > > test repo) analog TV was ONLY working with tvtime ... xawtv/motv and
> > > > kdetv were borked (I don't use Myth, so I have no idea what its status
> > > > would be ... though, I'd suspect that it works like tvtime). I quickly
> > > > traced this problem to be related to dga and Xv. A very similar
> > > > situation with these apps existed several years ago when the proprietary
> > > > X drivers from nvidia and ati removed dga functionality from their
> > > > respective drivers (for some background read:
> > > > http://www.nvnews.net/vbulletin/showthread.php?t=68232, and also the
> > > > relevant portion of the FAQ from the nvidia readme:
> > > > ftp://download.nvidia.com/XFree86/Linux-x86_64/180.27/README/chapter-07.html),
> > > > however, the basic nv driver would still function. Nvidia would later
> > > > provide a workaround to this issue in their driver.
> > > > So, in this modern day occurrence of this similar error/bug, the obvious
> > > > first test is to eliminate the proprietary driver from the equation.
> > > > However, the test result with the nv driver was the same -- borked
> > > > motv/xawtv and kdetv. I reported this, saying that I suspected that a
> > > > something may have been introduced somewhere resulting in this issue
> > > > with these apps resurfacing. This is why I asked that Hans' kworld repo
> > > > NOT be pulled into mainline (if there had been any thought to that --
> > > > though I don't think there was, because I now realize that I don't think
> > > > many had even seen my prior Jan 25th message !) until further testing
> > > > was performed.
> > > > 
> > > > - Mauro replied believing that this was unrelated to anything v4l-dvb,
> > > > but rather an artefact of the X drivers. I suspected that that was NOT
> > > > the case (the nv driver failing in my previous test was my cue). The
> > > > next obvious test was to revert back to an older v4l-dvb snapshot that
> > > > was patched with Mike Krufky's hack/workaround.
> > > 
> > > It took me some time today to bisect and trying to see what's going wrong with
> > > some userspace apps. 
> > > 
> > > At the end, I discovered that changeset 10240 fixed a bug that affected some
> > > userspace bad behaviour of setting defaults to zero, if a control is not found.
> > > 
> > > Due to that userspace bad behaviour, both tvtime and xawtv were using 0 for all
> > > video controls (brightness, contrast, color, hue). The practical effect is that
> > > a black image were displayed.
> > > 
> > > The fix were as simple as putting all controls at 50%.
> > > 
> > > Could this be your case also?
> > > 
> > > Cheers,
> > > Mauro
> > > 
> > 
> > Mauro, I know you are waiting for CityK, but I can report so far that I
> > never did see that black screen going away by adjusting the controls and
> > never had that black screen.
> > 
> > Tvtime and xawtv were always working under my conditions so far.
> > 
> > The very old troubles, like tda9887 not present after boot on my md7134
> > devices with FMD1216ME MK3 hybrid, and the even unrelated issue with the
> > tda10046 not properly controlled anymore after suspend/resume,
> > are unchanged on your current saa7134 attempt, but also no new issues
> > visible so far.
> > 
> 
> BTW, just to remember.
> 
> Tvtime with signal detection on shows a blue screen without signal.
> With signal detection off, just good old snow.
> 
> The tda8275/75a shows a black screen without having lock, not even snow,
> if it should be related.

Sorry, to add one more about "black" screens :)

Without the tda9887 loaded, the FMD1216ME MK3 hybrid also shows a black
screen, but it is slightly different from the fully black screen of the
tda8275, which is in fact an overlay like the blue screen on tvtime. It
has some white points visible and on some channels even _very_ decent
ghosting of TV.

The status of the tda9885/6/7 on the TUV1236D is still not clear to me,
until I see debug enabled on it for switching TV standards and just
nothing ever changes.

Cheers,
Hermann

Re: KWorld ATSC 115 all static

[Mauro Carvalho Chehab]

On Tue, 10 Feb 2009 02:31:00 +0100
hermann pitton <hermann-pitton@arcor.de> wrote:

> > > Mauro, I know you are waiting for CityK, but I can report so far that I
> > > never did see that black screen going away by adjusting the controls and
> > > never had that black screen.
> > > 
> > > Tvtime and xawtv were always working under my conditions so far.

Good to know.

> > > The very old troubles, like tda9887 not present after boot on my md7134
> > > devices with FMD1216ME MK3 hybrid, and the even unrelated issue with the
> > > tda10046 not properly controlled anymore after suspend/resume,
> > > are unchanged on your current saa7134 attempt, but also no new issues
> > > visible so far.

Ok, let's go by parts:

1) We need to know the sequence that enables tda9887 on md7134/fmd1216me, in
order to fix it. If someone has fmd1216me, please write me in priv or help us
to fix the code for it.

2) I bet that the issue with tda10046 is related to firmware loading. I made
some tests with a TV @nyware cardbus device that has a tda10046 + tda8290/tda8975.

What happens is that this device supports two type of firmware loads. The first
one requires an i2c eeprom with the firmware inside. The driver just writes
0x04 at register 0x07 and waits for some time. The hardware does the firmware load.

On the second mode, firmware bytes are transferred from the driver into the tda10046 memory.

At the tests I made here, on both modes, the i2c bus can't have any other
traffic during the firmware load. Otherwise, an invalid firmware will be loaded
and tda10046 will hangup.

I've started to implement some locks at saa7134 driver (on my saa7134
experimental tree), but it is not finished yet. I didn't touch at the sleep code yet.

> > > 
> > 
> > BTW, just to remember.
> > 
> > Tvtime with signal detection on shows a blue screen without signal.
> > With signal detection off, just good old snow.

So, the tda9887 or the PLL are configured wrongly.

> > The tda8275/75a shows a black screen without having lock, not even snow,
> > if it should be related.
> 
> Sorry, to add one more about "black" screens :)
> 
> Without the tda9887 loaded, the FMD1216ME MK3 hybrid also shows a black
> screen, but it is slightly different from the fully black screen of the
> tda8275, which is in fact an overlay like the blue screen on tvtime. It
> has some white points visible and on some channels even _very_ decent
> ghosting of TV.

Probably, tda9887 is configured for STD/M, instead of STD/BG. Fixing tda9887
will also fix this issue.

> The status of the tda9885/6/7 on the TUV1236D is still not clear to me,
> until I see debug enabled on it for switching TV standards and just
> nothing ever changes.

Sorry but I didn't understand what you're meaning with your TUV1236D-based device.
> 
> Cheers,
> Hermann
> 
> 




Cheers,
Mauro

Re: KWorld ATSC 115 all static

[hermann pitton]

Am Dienstag, den 10.02.2009, 00:35 -0200 schrieb Mauro Carvalho Chehab:
> On Tue, 10 Feb 2009 02:31:00 +0100
> hermann pitton <hermann-pitton@arcor.de> wrote:
> 
> > > > Mauro, I know you are waiting for CityK, but I can report so far that I
> > > > never did see that black screen going away by adjusting the controls and
> > > > never had that black screen.
> > > > 
> > > > Tvtime and xawtv were always working under my conditions so far.
> 
> Good to know.
> 
> > > > The very old troubles, like tda9887 not present after boot on my md7134
> > > > devices with FMD1216ME MK3 hybrid, and the even unrelated issue with the
> > > > tda10046 not properly controlled anymore after suspend/resume,
> > > > are unchanged on your current saa7134 attempt, but also no new issues
> > > > visible so far.
> 
> Ok, let's go by parts:
> 
> 1) We need to know the sequence that enables tda9887 on md7134/fmd1216me, in
> order to fix it. If someone has fmd1216me, please write me in priv or help us
> to fix the code for it.
> 
> 2) I bet that the issue with tda10046 is related to firmware loading. I made
> some tests with a TV @nyware cardbus device that has a tda10046 + tda8290/tda8975.
> 
> What happens is that this device supports two type of firmware loads. The first
> one requires an i2c eeprom with the firmware inside. The driver just writes
> 0x04 at register 0x07 and waits for some time. The hardware does the firmware load.
> 
> On the second mode, firmware bytes are transferred from the driver into the tda10046 memory.
> 
> At the tests I made here, on both modes, the i2c bus can't have any other
> traffic during the firmware load. Otherwise, an invalid firmware will be loaded
> and tda10046 will hangup.
> 
> I've started to implement some locks at saa7134 driver (on my saa7134
> experimental tree), but it is not finished yet. I didn't touch at the sleep code yet.
> 
> > > > 
> > > 
> > > BTW, just to remember.
> > > 
> > > Tvtime with signal detection on shows a blue screen without signal.
> > > With signal detection off, just good old snow.
> 
> So, the tda9887 or the PLL are configured wrongly.
> 
> > > The tda8275/75a shows a black screen without having lock, not even snow,
> > > if it should be related.
> > 
> > Sorry, to add one more about "black" screens :)
> > 
> > Without the tda9887 loaded, the FMD1216ME MK3 hybrid also shows a black
> > screen, but it is slightly different from the fully black screen of the
> > tda8275, which is in fact an overlay like the blue screen on tvtime. It
> > has some white points visible and on some channels even _very_ decent
> > ghosting of TV.
> 
> Probably, tda9887 is configured for STD/M, instead of STD/BG. Fixing tda9887
> will also fix this issue.
> 
> > The status of the tda9885/6/7 on the TUV1236D is still not clear to me,
> > until I see debug enabled on it for switching TV standards and just
> > nothing ever changes.
> 
> Sorry but I didn't understand what you're meaning with your TUV1236D-based device.

Just for that one for now, I'll try on the other subjects later.

I don't have any TUV1236D based device, but CityK and maybe Michael on
the Kworld _ATSC_ ! 110/15.

>From the photo provided by CityK, there is clearly a 24pin Philips
device within the IF section of this tuner, which I guess is a tda9885
NTSC only and nothing else.

As mentioned before, they can be strapped on one pin to be NTSC
(System-M) only without needing _any_ i2c programming according to the
data sheets.

With the reports so far, after years, either the tda9887 module is just
fake loaded, even that fails, or nothing ever happens, or something
happens on i2c we don't have clear.

So I would like to see if there is ever valid i2c traffic to that
tda988x device on that tuner or never...

Cheers,
Hermann

Re: KWorld ATSC 115 all static

[hermann pitton]

Am Dienstag, den 10.02.2009, 04:14 +0100 schrieb hermann pitton:
> Am Dienstag, den 10.02.2009, 00:35 -0200 schrieb Mauro Carvalho Chehab:
> > On Tue, 10 Feb 2009 02:31:00 +0100
> > hermann pitton <hermann-pitton@arcor.de> wrote:

> > > > 
> > > > BTW, just to remember.
> > > > 
> > > > Tvtime with signal detection on shows a blue screen without signal.
> > > > With signal detection off, just good old snow.
> > 
> > So, the tda9887 or the PLL are configured wrongly.
> > 

Urgh, not to add more confusion here at least.

Good old snow means the analog signal is perfect.

I stopped since long to connect a real signal to it surfing the grounds
on my stomach, but it is for sure working then and the pll is always
fine.

Cheers,
Hermann

Re: KWorld ATSC 115 all static

[Mauro Carvalho Chehab]

On Tue, 10 Feb 2009 04:43:15 +0100
hermann pitton <hermann-pitton@arcor.de> wrote:

> 
> Am Dienstag, den 10.02.2009, 04:14 +0100 schrieb hermann pitton:
> > Am Dienstag, den 10.02.2009, 00:35 -0200 schrieb Mauro Carvalho Chehab:
> > > On Tue, 10 Feb 2009 02:31:00 +0100
> > > hermann pitton <hermann-pitton@arcor.de> wrote:
> 
> > > > > 
> > > > > BTW, just to remember.
> > > > > 
> > > > > Tvtime with signal detection on shows a blue screen without signal.
> > > > > With signal detection off, just good old snow.
> > > 
> > > So, the tda9887 or the PLL are configured wrongly.
> > > 
> 
> Urgh, not to add more confusion here at least.
> 
> Good old snow means the analog signal is perfect.
> 
> I stopped since long to connect a real signal to it surfing the grounds
> on my stomach, but it is for sure working then and the pll is always
> fine.

Ah, ok. So, now, we just need CityK (or someone else with ATSC 115) to confirm
that everything is fine on their side. This patch may also fix other similar
troubles on a few devices that seem to need some i2c magic before probing the
tuner.

Cheers,
Mauro

Re: KWorld ATSC 115 all static

[Jonathan Isom]

On Tue, Feb 10, 2009 at 12:15 AM, Mauro Carvalho Chehab
<mchehab@infradead.org> wrote:
> On Tue, 10 Feb 2009 04:43:15 +0100
> hermann pitton <hermann-pitton@arcor.de> wrote:
>
>>
>> Am Dienstag, den 10.02.2009, 04:14 +0100 schrieb hermann pitton:
>> > Am Dienstag, den 10.02.2009, 00:35 -0200 schrieb Mauro Carvalho Chehab:
>> > > On Tue, 10 Feb 2009 02:31:00 +0100
>> > > hermann pitton <hermann-pitton@arcor.de> wrote:
>>
>> > > > >
>> > > > > BTW, just to remember.
>> > > > >
>> > > > > Tvtime with signal detection on shows a blue screen without signal.
>> > > > > With signal detection off, just good old snow.
>> > >
>> > > So, the tda9887 or the PLL are configured wrongly.
>> > >
>>
>> Urgh, not to add more confusion here at least.
>>
>> Good old snow means the analog signal is perfect.
>>
>> I stopped since long to connect a real signal to it surfing the grounds
>> on my stomach, but it is for sure working then and the pll is always
>> fine.
>
> Ah, ok. So, now, we just need CityK (or someone else with ATSC 115) to confirm
> that everything is fine on their side. This patch may also fix other similar
> troubles on a few devices that seem to need some i2c magic before probing the
> tuner.

Just tried the latest hg and I can confirm that both an ATSC 110 and
115 work with tvtime
and ATSC.

Later

Jonathan

> Cheers,
> Mauro
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: KWorld ATSC 115 all static

[Mauro Carvalho Chehab]

On Tue, 10 Feb 2009 06:07:51 -0600
Jonathan Isom <jeisom@gmail.com> wrote:

> On Tue, Feb 10, 2009 at 12:15 AM, Mauro Carvalho Chehab
> <mchehab@infradead.org> wrote:
> > On Tue, 10 Feb 2009 04:43:15 +0100
> > hermann pitton <hermann-pitton@arcor.de> wrote:
> >
> >>
> >> Am Dienstag, den 10.02.2009, 04:14 +0100 schrieb hermann pitton:
> >> > Am Dienstag, den 10.02.2009, 00:35 -0200 schrieb Mauro Carvalho Chehab:
> >> > > On Tue, 10 Feb 2009 02:31:00 +0100
> >> > > hermann pitton <hermann-pitton@arcor.de> wrote:
> >>
> >> > > > >
> >> > > > > BTW, just to remember.
> >> > > > >
> >> > > > > Tvtime with signal detection on shows a blue screen without signal.
> >> > > > > With signal detection off, just good old snow.
> >> > >
> >> > > So, the tda9887 or the PLL are configured wrongly.
> >> > >
> >>
> >> Urgh, not to add more confusion here at least.
> >>
> >> Good old snow means the analog signal is perfect.
> >>
> >> I stopped since long to connect a real signal to it surfing the grounds
> >> on my stomach, but it is for sure working then and the pll is always
> >> fine.
> >
> > Ah, ok. So, now, we just need CityK (or someone else with ATSC 115) to confirm
> > that everything is fine on their side. This patch may also fix other similar
> > troubles on a few devices that seem to need some i2c magic before probing the
> > tuner.
> 
> Just tried the latest hg and I can confirm that both an ATSC 110 and
> 115 work with tvtime
> and ATSC.
> 
Jonathan,

You tried the latest tree at http://linuxtv.org/hg/v4l-dvb or my saa7134 tree
(http://linuxtv.org/hg/~mchehab/saa7134)?

In the first case, could you please confirm that it works fine also with the saa7134 tree?

> Later
> 
> Jonathan
> 
> > Cheers,
> > Mauro
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-media" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >




Cheers,
Mauro

Re: KWorld ATSC 115 all static

[Jonathan Isom]

On Tue, Feb 10, 2009 at 6:27 AM, Mauro Carvalho Chehab
<mchehab@infradead.org> wrote:
> On Tue, 10 Feb 2009 06:07:51 -0600
> Jonathan Isom <jeisom@gmail.com> wrote:
>
>> On Tue, Feb 10, 2009 at 12:15 AM, Mauro Carvalho Chehab
>> <mchehab@infradead.org> wrote:
>> > On Tue, 10 Feb 2009 04:43:15 +0100
>> > hermann pitton <hermann-pitton@arcor.de> wrote:
>> >
>> >>
>> >> Am Dienstag, den 10.02.2009, 04:14 +0100 schrieb hermann pitton:
>> >> > Am Dienstag, den 10.02.2009, 00:35 -0200 schrieb Mauro Carvalho Chehab:
>> >> > > On Tue, 10 Feb 2009 02:31:00 +0100
>> >> > > hermann pitton <hermann-pitton@arcor.de> wrote:
>> >>
>> >> > > > >
>> >> > > > > BTW, just to remember.
>> >> > > > >
>> >> > > > > Tvtime with signal detection on shows a blue screen without signal.
>> >> > > > > With signal detection off, just good old snow.
>> >> > >
>> >> > > So, the tda9887 or the PLL are configured wrongly.
>> >> > >
>> >>
>> >> Urgh, not to add more confusion here at least.
>> >>
>> >> Good old snow means the analog signal is perfect.
>> >>
>> >> I stopped since long to connect a real signal to it surfing the grounds
>> >> on my stomach, but it is for sure working then and the pll is always
>> >> fine.
>> >
>> > Ah, ok. So, now, we just need CityK (or someone else with ATSC 115) to confirm
>> > that everything is fine on their side. This patch may also fix other similar
>> > troubles on a few devices that seem to need some i2c magic before probing the
>> > tuner.
>>
>> Just tried the latest hg and I can confirm that both an ATSC 110 and
>> 115 work with tvtime
>> and ATSC.
>>
> Jonathan,
>
> You tried the latest tree at http://linuxtv.org/hg/v4l-dvb or my saa7134 tree
> (http://linuxtv.org/hg/~mchehab/saa7134)?
>
> In the first case, could you please confirm that it works fine also with the saa7134 tree?

Hi
  I can confirm they work with both trees.

Later

Jonathan


>> Later
>>
>> Jonathan
>>
>> > Cheers,
>> > Mauro
>> > --
>> > To unsubscribe from this list: send the line "unsubscribe linux-media" in
>> > the body of a message to majordomo@vger.kernel.org
>> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> >
>
>
>
>
> Cheers,
> Mauro
>

Re: KWorld ATSC 115 all static

[Mauro Carvalho Chehab]

On Tue, 10 Feb 2009 06:48:12 -0600
Jonathan Isom <jeisom@gmail.com> wrote:

> > You tried the latest tree at http://linuxtv.org/hg/v4l-dvb or my saa7134 tree
> > (http://linuxtv.org/hg/~mchehab/saa7134)?
> >
> > In the first case, could you please confirm that it works fine also with the saa7134 tree?  
> 
> Hi
>   I can confirm they work with both trees.
> 
> Later


Thanks, Jonathan. I'll merge the saa7134 patches then. The method I used
previously is better fitted when we know how to enable and disable the i2c
gate, but, for ATSC 115, we only know how to open the gate.

Cheers,
Mauro

Re: KWorld ATSC 115 all static

[David Engel]

On Tue, Feb 10, 2009 at 10:27:32AM -0200, Mauro Carvalho Chehab wrote:
> On Tue, 10 Feb 2009 06:07:51 -0600
> Jonathan Isom <jeisom@gmail.com> wrote:
> > On Tue, Feb 10, 2009 at 12:15 AM, Mauro Carvalho Chehab
> > > Ah, ok. So, now, we just need CityK (or someone else with ATSC 115) to confirm
> > > that everything is fine on their side. This patch may also fix other similar
> > > troubles on a few devices that seem to need some i2c magic before probing the
> > > tuner.
> > 
> > Just tried the latest hg and I can confirm that both an ATSC 110 and
> > 115 work with tvtime
> > and ATSC.
> > 
> Jonathan,
> 
> You tried the latest tree at http://linuxtv.org/hg/v4l-dvb or my saa7134 tree
> (http://linuxtv.org/hg/~mchehab/saa7134)?
> 
> In the first case, could you please confirm that it works fine also with the saa7134 tree?

I tried both trees with my ATSC 115.  

The v4l-dvb did not work.  tvtime showed only a blue screen,
presumably due to lack of a signal.  The last commit in the tree was
as follows:

    changeset:   10503:9cb19f080660
    tag:         tip
    parent:      10495:d76f0c9b75fd
    parent:      10502:b1d0225eeec4
    user:        Mauro Carvalho Chehab <mchehab@redhat.com>
    date:        Tue Feb 10 05:26:05 2009 -0200
    summary:     merge: http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-saa7146

The saa7134 worked.  MythTV eventually worked too, but I had to do the
"unload/reload modules and run tvtime" procedure I reported earlier
when I tried Hans' kworld tree.

David
-- 
David Engel
david@istwok.net

Re: KWorld ATSC 115 all static

[hermann pitton]

Hi,

Am Dienstag, den 10.02.2009, 21:50 -0600 schrieb David Engel:
> On Tue, Feb 10, 2009 at 10:27:32AM -0200, Mauro Carvalho Chehab wrote:
> > On Tue, 10 Feb 2009 06:07:51 -0600
> > Jonathan Isom <jeisom@gmail.com> wrote:
> > > On Tue, Feb 10, 2009 at 12:15 AM, Mauro Carvalho Chehab
> > > > Ah, ok. So, now, we just need CityK (or someone else with ATSC 115) to confirm
> > > > that everything is fine on their side. This patch may also fix other similar
> > > > troubles on a few devices that seem to need some i2c magic before probing the
> > > > tuner.
> > > 
> > > Just tried the latest hg and I can confirm that both an ATSC 110 and
> > > 115 work with tvtime
> > > and ATSC.
> > > 
> > Jonathan,
> > 
> > You tried the latest tree at http://linuxtv.org/hg/v4l-dvb or my saa7134 tree
> > (http://linuxtv.org/hg/~mchehab/saa7134)?
> > 
> > In the first case, could you please confirm that it works fine also with the saa7134 tree?
> 
> I tried both trees with my ATSC 115.  
> 
> The v4l-dvb did not work.  tvtime showed only a blue screen,
> presumably due to lack of a signal.  The last commit in the tree was
> as follows:
> 
>     changeset:   10503:9cb19f080660
>     tag:         tip
>     parent:      10495:d76f0c9b75fd
>     parent:      10502:b1d0225eeec4
>     user:        Mauro Carvalho Chehab <mchehab@redhat.com>
>     date:        Tue Feb 10 05:26:05 2009 -0200
>     summary:     merge: http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-saa7146
> 
> The saa7134 worked.  MythTV eventually worked too, but I had to do the
> "unload/reload modules and run tvtime" procedure I reported earlier
> when I tried Hans' kworld tree.
> 
> David

guess that is why CityK reported already on that always with a _cold_
boot too, as discussed.

Forget about mythtv on such testing.

You likely will never catch a rabbit this way, but it is fine for to
count them all after ...

Cheers,
Hermann

Re: KWorld ATSC 115 all static

[Mauro Carvalho Chehab]

On Tue, 10 Feb 2009 21:50:16 -0600
David Engel <david@istwok.net> wrote:

> On Tue, Feb 10, 2009 at 10:27:32AM -0200, Mauro Carvalho Chehab wrote:
> > On Tue, 10 Feb 2009 06:07:51 -0600
> > Jonathan Isom <jeisom@gmail.com> wrote:
> > > On Tue, Feb 10, 2009 at 12:15 AM, Mauro Carvalho Chehab
> > > > Ah, ok. So, now, we just need CityK (or someone else with ATSC 115) to confirm
> > > > that everything is fine on their side. This patch may also fix other similar
> > > > troubles on a few devices that seem to need some i2c magic before probing the
> > > > tuner.
> > > 
> > > Just tried the latest hg and I can confirm that both an ATSC 110 and
> > > 115 work with tvtime
> > > and ATSC.
> > > 
> > Jonathan,
> > 
> > You tried the latest tree at http://linuxtv.org/hg/v4l-dvb or my saa7134 tree
> > (http://linuxtv.org/hg/~mchehab/saa7134)?
> > 
> > In the first case, could you please confirm that it works fine also with the saa7134 tree?
> 
> I tried both trees with my ATSC 115.  
> 
> The v4l-dvb did not work.  tvtime showed only a blue screen,
> presumably due to lack of a signal.  The last commit in the tree was
> as follows:
> 
>     changeset:   10503:9cb19f080660
>     tag:         tip
>     parent:      10495:d76f0c9b75fd
>     parent:      10502:b1d0225eeec4
>     user:        Mauro Carvalho Chehab <mchehab@redhat.com>
>     date:        Tue Feb 10 05:26:05 2009 -0200
>     summary:     merge: http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-saa7146
> 
> The saa7134 worked.

Ok. I've merged from saa7134 tree. This is the patch that changed the open gate
for ATSC115 (and other saa7134 devices whose i2c gate open sequences are known):

changeset:   10507:ec84c420abdd
user:        Mauro Carvalho Chehab <mchehab@redhat.com>
date:        Sun Feb 08 10:33:15 2009 -0200
summary:     saa7134: Fix analog mode on devices that need to open an i2c gate

> MythTV eventually worked too, but I had to do the
> "unload/reload modules and run tvtime" procedure I reported earlier
> when I tried Hans' kworld tree.

Maybe this is a race condition I have here with tda1004x. With tda1004x, the i2c
bus shouldn't be used by any other device during the firmware transfers,
otherwise the firmware load will fail, and tda1004x goes into an unstable
state. With this device, it even affects all subsequent i2c acesses. The only
alternative to recover tda1004x is to reboot the card (e. g. with my cardbus
device, I have to physically remove it and re-insert).

What happens is that some softwares (including udev) open the device, and send
some VIDIOC_G_TUNER in order to check some tuner characteristics. However, this
command generates some i2c transfers, to retrieve signal strength. If this
happens while the firmware is being loaded, the bug occurs.

In order to fix, a careful review of all locks on the driver is needed. We will
likely need to change the demod interface for the boards that have this
trouble, in order to be aware of when a firmware transfer started.

This lock review is currently on my TODO list.

To be sure that this is the case, could you please add this on
your /etc/modprobe (or at a file inside /etc/modprobe.d):

	options nxt200x debug=1
	options tuner-simple debug=1
	options tuner debug=1
	options dvb-core frontend_debug=1

And test again, sending us the produced logs when the device works and when it
breaks. I guess we'll discover some tuner dmesg's in the middle of the firmware
load sequence.

As a reference, this is the logs for the race condition with tda1004x:

DVB: registering frontend 0 (Philips TDA10046H DVB-T)...
tda1004x: setting up plls for 48MHz sampling clock
tda1004x: found firmware revision ff -- invalid
tda1004x: trying to boot from eeprom
tda829x 1-004b: tda8290 is locked, AGC: 241
tda829x 1-004b: adjust gain, step 1. Agc: 241, ADC stat: 108, lock: 128
tda829x 1-004b: setting tda829x to system B
tda827x: setting tda827x to system B
tda827x: AGC2 gain is: 1
tda829x 1-004b: tda8290 not locked, no signal?
tda829x 1-004b: tda8290 not locked, no signal?
tda829x 1-004b: tda8290 not locked, no signal?
tda829x 1-004b: adjust gain, step 1. Agc: 236, ADC stat: 0, lock: 0
tda829x 1-004b: adjust gain, step 2. Agc: 128, lock: 0
tda829x 1-004b: adjust gain, step 3. Agc: 128
tda829x 1-004b: setting tda829x to system B
tda829x 1-004b: setting tda829x to system B
tda1004x: found firmware revision ff -- invalid

The firmware load stops at the last message. Notice that, during the firmware
transfer, the tuner status were checked. This generated a breakage at the i2c
transfer. Maybe we'll need a sort of locking between tuner and demod i2c access
to avoid such troubles.

Cheers,
Mauro

Re: KWorld ATSC 115 all static

[David Engel]

On Wed, Feb 11, 2009 at 05:43:29AM -0200, Mauro Carvalho Chehab wrote:
> On Tue, 10 Feb 2009 21:50:16 -0600
> David Engel <david@istwok.net> wrote:
> > MythTV eventually worked too, but I had to do the
> > "unload/reload modules and run tvtime" procedure I reported earlier
> > when I tried Hans' kworld tree.
> 
> Maybe this is a race condition I have here with tda1004x. With tda1004x, the i2c
> bus shouldn't be used by any other device during the firmware transfers,
> otherwise the firmware load will fail, and tda1004x goes into an unstable
> state. With this device, it even affects all subsequent i2c acesses. The only
> alternative to recover tda1004x is to reboot the card (e. g. with my cardbus
> device, I have to physically remove it and re-insert).
> 
> What happens is that some softwares (including udev) open the device, and send
> some VIDIOC_G_TUNER in order to check some tuner characteristics. However, this
> command generates some i2c transfers, to retrieve signal strength. If this
> happens while the firmware is being loaded, the bug occurs.
> 
> In order to fix, a careful review of all locks on the driver is needed. We will
> likely need to change the demod interface for the boards that have this
> trouble, in order to be aware of when a firmware transfer started.
> 
> This lock review is currently on my TODO list.
> 
> To be sure that this is the case, could you please add this on
> your /etc/modprobe (or at a file inside /etc/modprobe.d):
> 
> 	options nxt200x debug=1
> 	options tuner-simple debug=1
> 	options tuner debug=1
> 	options dvb-core frontend_debug=1
> 
> And test again, sending us the produced logs when the device works and when it
> breaks. I guess we'll discover some tuner dmesg's in the middle of the firmware
> load sequence.

I will do this, but it will be tomorrow evening before I can get to
it.

David
-- 
David Engel
david@istwok.net

Re: KWorld ATSC 115 all static

[David Engel]

On Wed, Feb 11, 2009 at 05:21:49PM -0600, David Engel wrote:
> On Wed, Feb 11, 2009 at 05:43:29AM -0200, Mauro Carvalho Chehab wrote:
> > On Tue, 10 Feb 2009 21:50:16 -0600
> > David Engel <david@istwok.net> wrote:
> > > MythTV eventually worked too, but I had to do the
> > > "unload/reload modules and run tvtime" procedure I reported earlier
> > > when I tried Hans' kworld tree.
> > 
> > Maybe this is a race condition I have here with tda1004x. With tda1004x, the i2c
> > bus shouldn't be used by any other device during the firmware transfers,
> > otherwise the firmware load will fail, and tda1004x goes into an unstable
> > state. With this device, it even affects all subsequent i2c acesses. The only
> > alternative to recover tda1004x is to reboot the card (e. g. with my cardbus
> > device, I have to physically remove it and re-insert).
> > 
> > What happens is that some softwares (including udev) open the device, and send
> > some VIDIOC_G_TUNER in order to check some tuner characteristics. However, this
> > command generates some i2c transfers, to retrieve signal strength. If this
> > happens while the firmware is being loaded, the bug occurs.
> > 
> > In order to fix, a careful review of all locks on the driver is needed. We will
> > likely need to change the demod interface for the boards that have this
> > trouble, in order to be aware of when a firmware transfer started.
> > 
> > This lock review is currently on my TODO list.
> > 
> > To be sure that this is the case, could you please add this on
> > your /etc/modprobe (or at a file inside /etc/modprobe.d):
> > 
> > 	options nxt200x debug=1
> > 	options tuner-simple debug=1
> > 	options tuner debug=1
> > 	options dvb-core frontend_debug=1
> > 
> > And test again, sending us the produced logs when the device works and when it
> > breaks. I guess we'll discover some tuner dmesg's in the middle of the firmware
> > load sequence.
> 
> I will do this, but it will be tomorrow evening before I can get to
> it.

Here are my logs.  They are annoteded in-line with the actions I took.
I need to add that the results with MythTv aren't always consistent.
Sometimes it works right away when I don't expect it to and sometimes
it doesn't work after the reload when I do expect it to.  The results
shown below are what happens most of the time -- MythTV doesn't work
until the modules are reloaded and tvtime is run.

Cold booting.

Feb 12 20:30:54 opus kernel: Linux video capture interface: v2.00
Feb 12 20:30:54 opus kernel: saa7130/34: v4l2 driver version 0.2.14 loaded
Feb 12 20:30:54 opus kernel: saa7134 0000:04:07.0: PCI INT A -> Link[LNKB] -> GSI 18 (level, low) -> IRQ 18
Feb 12 20:30:54 opus kernel: saa7133[0]: found at 0000:04:07.0, rev: 209, irq: 18, latency: 64, mmio: 0xfebff800
Feb 12 20:30:54 opus kernel: saa7133[0]: subsystem: 17de:7352, board: Kworld ATSC110/115 [card=90,autodetected]
Feb 12 20:30:54 opus kernel: saa7133[0]: board init: gpio is 100
Feb 12 20:30:54 opus kernel: saa7133[0]: i2c eeprom 00: de 17 52 73 ff ff ff ff ff ff ff ff ff ff ff ff
Feb 12 20:30:54 opus kernel: saa7133[0]: i2c eeprom 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Feb 12 20:30:54 opus kernel: saa7133[0]: i2c eeprom 20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Feb 12 20:30:54 opus kernel: saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Feb 12 20:30:54 opus kernel: saa7133[0]: i2c eeprom 40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Feb 12 20:30:54 opus kernel: saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Feb 12 20:30:54 opus kernel: saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Feb 12 20:30:54 opus kernel: saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Feb 12 20:30:54 opus kernel: saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Feb 12 20:30:54 opus kernel: saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Feb 12 20:30:54 opus kernel: saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Feb 12 20:30:54 opus kernel: saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Feb 12 20:30:54 opus kernel: saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Feb 12 20:30:54 opus kernel: saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Feb 12 20:30:54 opus kernel: saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Feb 12 20:30:54 opus kernel: saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Feb 12 20:30:54 opus kernel: tuner 1-0061: Setting mode_mask to 0x0e
Feb 12 20:30:54 opus kernel: tuner 1-0061: chip found @ 0xc2 (saa7133[0])
Feb 12 20:30:54 opus kernel: tuner 1-0061: tuner 0x61: Tuner type absent
Feb 12 20:30:54 opus kernel: tuner 1-0061: Calling set_type_addr for type=68, addr=0xff, mode=0x0e, config=0x00
Feb 12 20:30:54 opus kernel: tuner 1-0061: defining GPIO callback
Feb 12 20:30:54 opus kernel: tuner-simple 1-0061: creating new instance
Feb 12 20:30:54 opus kernel: tuner-simple 1-0061: type set to 68 (Philips TUV1236D ATSC/NTSC dual in)
Feb 12 20:30:54 opus kernel: tuner-simple 1-0061: tuner 0 atv rf input will be autoselected
Feb 12 20:30:54 opus kernel: tuner-simple 1-0061: tuner 0 dtv rf input will be autoselected
Feb 12 20:30:54 opus kernel: tuner 1-0061: type set to Philips TUV1236D ATSC/NTSC dual in
Feb 12 20:30:54 opus kernel: tuner 1-0061: tv freq set to 400.00
Feb 12 20:30:54 opus kernel: tuner-simple 1-0061: desired params (pal) undefined for tuner 68
Feb 12 20:30:54 opus kernel: tuner-simple 1-0061: using tuner params #0 (ntsc)
Feb 12 20:30:54 opus kernel: tuner-simple 1-0061: freq = 400.00 (6400), range = 1, config = 0xce, cb = 0x02
Feb 12 20:30:54 opus kernel: tuner-simple 1-0061: Freq= 400.00 MHz, V_IF=38.93 MHz, Offset=0.00 MHz, div=7023
Feb 12 20:30:54 opus kernel: tuner-simple 1-0061: tv 0x1b 0x6f 0xce 0x02
Feb 12 20:30:54 opus kernel: tuner 1-0061: saa7133[0] tuner I2C addr 0xc2 with type 68 used for 0x0e
Feb 12 20:30:54 opus kernel: tuner 1-0061: switching to v4l2
Feb 12 20:30:54 opus kernel: tuner 1-0061: tv freq set to 400.00
Feb 12 20:30:54 opus kernel: tuner-simple 1-0061: desired params (pal) undefined for tuner 68
Feb 12 20:30:54 opus kernel: tuner-simple 1-0061: using tuner params #0 (ntsc)
Feb 12 20:30:54 opus kernel: tuner-simple 1-0061: freq = 400.00 (6400), range = 1, config = 0xce, cb = 0x02
Feb 12 20:30:54 opus kernel: tuner-simple 1-0061: Freq= 400.00 MHz, V_IF=38.93 MHz, Offset=0.00 MHz, div=7023
Feb 12 20:30:54 opus kernel: tuner-simple 1-0061: tv 0x1b 0x6f 0xce 0x02
Feb 12 20:30:54 opus kernel: tuner 1-0061: tv freq set to 400.00
Feb 12 20:30:54 opus kernel: tuner-simple 1-0061: desired params (pal) undefined for tuner 68
Feb 12 20:30:54 opus kernel: tuner-simple 1-0061: using tuner params #0 (ntsc)
Feb 12 20:30:54 opus kernel: tuner-simple 1-0061: freq = 400.00 (6400), range = 1, config = 0xce, cb = 0x02
Feb 12 20:30:54 opus kernel: tuner-simple 1-0061: Freq= 400.00 MHz, V_IF=38.93 MHz, Offset=0.00 MHz, div=7023
Feb 12 20:30:54 opus kernel: tuner-simple 1-0061: tv 0x1b 0x6f 0xce 0x02
Feb 12 20:30:54 opus kernel: tuner 1-0061: Putting tuner to sleep
Feb 12 20:30:54 opus kernel: tuner 1-0061: Cmd TUNER_SET_STANDBY accepted for analog TV
Feb 12 20:30:54 opus kernel: saa7133[0]: registered device video2 [v4l2]
Feb 12 20:30:54 opus kernel: saa7133[0]: registered device vbi2
Feb 12 20:30:54 opus kernel: dvb_init() allocating 1 frontend
Feb 12 20:30:54 opus kernel: nxt200x: NXT info: 05 02 09 20 01
Feb 12 20:30:54 opus kernel: nxt200x: NXT2004 Detected
Feb 12 20:30:54 opus kernel: tuner-simple 1-0061: attaching existing instance
Feb 12 20:30:54 opus kernel: tuner-simple 1-0061: type set to 68 (Philips TUV1236D ATSC/NTSC dual in)
Feb 12 20:30:54 opus kernel: tuner-simple 1-0061: tuner 0 atv rf input will be autoselected
Feb 12 20:30:54 opus kernel: tuner-simple 1-0061: tuner 0 dtv rf input will be autoselected
Feb 12 20:30:54 opus kernel: DVB: registering new adapter (saa7133[0])
Feb 12 20:30:54 opus kernel: dvb_register_frontend
Feb 12 20:30:54 opus kernel: DVB: registering adapter 0 frontend 0 (Nextwave NXT200X VSB/QAM frontend)...
Feb 12 20:30:54 opus kernel: nxt2004: Waiting for firmware upload (dvb-fe-nxt2004.fw)...
Feb 12 20:30:54 opus kernel: firmware: requesting dvb-fe-nxt2004.fw
Feb 12 20:30:54 opus kernel: nxt2004: Waiting for firmware upload(2)...
Feb 12 20:30:54 opus kernel: nxt200x: nxt2004_load_firmware
Feb 12 20:30:54 opus kernel: nxt200x: Firmware is 9584 bytes
Feb 12 20:30:54 opus kernel: nxt200x: firmware crc is 0xF1 0xB2
Feb 12 20:30:54 opus kernel: nxt2004: Firmware upload complete
Feb 12 20:30:54 opus kernel: nxt200x: nxt2004_microcontroller_init
Feb 12 20:30:54 opus kernel: nxt200x: nxt200x_microcontroller_stop
Feb 12 20:30:54 opus kernel: nxt200x: nxt200x_microcontroller_stop
Feb 12 20:30:54 opus kernel: nxt200x: nxt2004_microcontroller_init
Feb 12 20:30:54 opus kernel: nxt200x: nxt200x_microcontroller_stop
Feb 12 20:30:54 opus kernel: nxt200x: nxt200x_writereg_multibyte
Feb 12 20:30:54 opus kernel: nxt200x: nxt200x_writereg_multibyte
Feb 12 20:30:54 opus kernel: nxt200x: nxt200x_writereg_multibyte
Feb 12 20:30:54 opus kernel: nxt200x: nxt200x_readreg_multibyte
Feb 12 20:30:54 opus kernel: nxt200x: nxt200x_writereg_multibyte
Feb 12 20:30:54 opus kernel: nxt200x: nxt200x_readreg_multibyte
Feb 12 20:30:54 opus kernel: nxt200x: nxt200x_writereg_multibyte
Feb 12 20:30:54 opus kernel: nxt200x: nxt200x_readreg_multibyte
Feb 12 20:30:54 opus kernel: nxt200x: nxt200x_writereg_multibyte
Feb 12 20:30:54 opus kernel: nxt200x: nxt200x_readreg_multibyte
Feb 12 20:30:54 opus kernel: nxt200x: nxt200x_writereg_multibyte
Feb 12 20:30:54 opus last message repeated 2 times
Feb 12 20:30:54 opus kernel: nxt200x: nxt200x_readreg_multibyte
Feb 12 20:30:54 opus kernel: nxt200x: nxt200x_writereg_multibyte
Feb 12 20:30:54 opus kernel: nxt200x: nxt200x_readreg_multibyte
Feb 12 20:30:54 opus kernel: nxt200x: nxt200x_writereg_multibyte
Feb 12 20:30:54 opus kernel: nxt200x: nxt2004_microcontroller_init
Feb 12 20:30:54 opus kernel: nxt200x: nxt200x_readreg_multibyte
Feb 12 20:30:54 opus kernel: nxt200x: nxt200x_writereg_multibyte
Feb 12 20:30:54 opus kernel: nxt200x: nxt200x_readreg_multibyte
Feb 12 20:30:54 opus kernel: nxt200x: nxt200x_writereg_multibyte
Feb 12 20:30:54 opus kernel: nxt200x: nxt200x_readreg_multibyte
Feb 12 20:30:54 opus kernel: nxt200x: nxt200x_writereg_multibyte
Feb 12 20:30:54 opus kernel: nxt200x: nxt200x_readreg_multibyte
Feb 12 20:30:54 opus kernel: nxt200x: nxt200x_writereg_multibyte
Feb 12 20:30:54 opus kernel: nxt200x: nxt200x_readreg_multibyte
Feb 12 20:30:54 opus kernel: nxt200x: nxt200x_writereg_multibyte
Feb 12 20:30:54 opus last message repeated 2 times
Feb 12 20:30:54 opus kernel: nxt200x: nxt200x_readreg_multibyte
Feb 12 20:30:54 opus kernel: nxt200x: nxt200x_writereg_multibyte
Feb 12 20:30:54 opus kernel: nxt200x: nxt200x_readreg_multibyte
Feb 12 20:30:54 opus kernel: nxt200x: nxt200x_writereg_multibyte
Feb 12 20:30:54 opus kernel: saa7134 ALSA driver for DMA sound loaded
Feb 12 20:30:54 opus kernel: saa7133[0]/alsa: saa7133[0] at 0xfebff800 irq 18 registered as card 2
Feb 12 20:30:59 opus kernel: tuner 1-0061: Cmd VIDIOC_S_STD accepted for analog TV
Feb 12 20:30:59 opus kernel: tuner 1-0061: tv freq set to 400.00
Feb 12 20:30:59 opus kernel: tuner-simple 1-0061: desired params (pal) undefined for tuner 68
Feb 12 20:30:59 opus kernel: tuner-simple 1-0061: using tuner params #0 (ntsc)
Feb 12 20:30:59 opus kernel: tuner-simple 1-0061: freq = 400.00 (6400), range = 1, config = 0xce, cb = 0x02
Feb 12 20:30:59 opus kernel: tuner-simple 1-0061: Freq= 400.00 MHz, V_IF=38.93 MHz, Offset=0.00 MHz, div=7023
Feb 12 20:30:59 opus kernel: tuner-simple 1-0061: tv 0x1b 0x6f 0xce 0x02
Feb 12 20:30:59 opus kernel: tuner 1-0061: Putting tuner to sleep
Feb 12 20:30:59 opus kernel: tuner 1-0061: Cmd TUNER_SET_STANDBY accepted for analog TV
Feb 12 20:30:59 opus kernel: tuner 1-0061: Cmd VIDIOC_S_STD accepted for analog TV
Feb 12 20:30:59 opus kernel: tuner 1-0061: tv freq set to 400.00
Feb 12 20:30:59 opus kernel: tuner-simple 1-0061: desired params (pal) undefined for tuner 68
Feb 12 20:30:59 opus kernel: tuner-simple 1-0061: using tuner params #0 (ntsc)
Feb 12 20:30:59 opus kernel: tuner-simple 1-0061: freq = 400.00 (6400), range = 1, config = 0xce, cb = 0x02
Feb 12 20:30:59 opus kernel: tuner-simple 1-0061: Freq= 400.00 MHz, V_IF=38.93 MHz, Offset=0.00 MHz, div=7023
Feb 12 20:30:59 opus kernel: tuner-simple 1-0061: tv 0x1b 0x6f 0xce 0x02
Feb 12 20:30:59 opus kernel: tuner 1-0061: Putting tuner to sleep
Feb 12 20:30:59 opus kernel: tuner 1-0061: Cmd TUNER_SET_STANDBY accepted for analog TV


Starting tvtime.

Feb 12 20:32:14 opus kernel: tuner 1-0061: Cmd VIDIOC_S_STD accepted for analog TV
Feb 12 20:32:14 opus kernel: tuner 1-0061: tv freq set to 400.00
Feb 12 20:32:14 opus kernel: tuner-simple 1-0061: desired params (pal) undefined for tuner 68
Feb 12 20:32:14 opus kernel: tuner-simple 1-0061: using tuner params #0 (ntsc)
Feb 12 20:32:14 opus kernel: tuner-simple 1-0061: freq = 400.00 (6400), range = 1, config = 0xce, cb = 0x02
Feb 12 20:32:14 opus kernel: tuner-simple 1-0061: Freq= 400.00 MHz, V_IF=38.93 MHz, Offset=0.00 MHz, div=7023
Feb 12 20:32:14 opus kernel: tuner-simple 1-0061: tv 0x1b 0x6f 0xce 0x02
Feb 12 20:32:14 opus kernel: tuner 1-0061: tv freq set to 400.00
Feb 12 20:32:14 opus kernel: tuner-simple 1-0061: desired params (pal) undefined for tuner 68
Feb 12 20:32:14 opus kernel: tuner-simple 1-0061: using tuner params #0 (ntsc)
Feb 12 20:32:14 opus kernel: tuner-simple 1-0061: freq = 400.00 (6400), range = 1, config = 0xce, cb = 0x02
Feb 12 20:32:14 opus kernel: tuner-simple 1-0061: Freq= 400.00 MHz, V_IF=38.93 MHz, Offset=0.00 MHz, div=7023
Feb 12 20:32:14 opus kernel: tuner-simple 1-0061: tv 0x1b 0x6f 0xce 0x02
Feb 12 20:32:14 opus kernel: tuner 1-0061: tv freq set to 400.00
Feb 12 20:32:14 opus kernel: tuner-simple 1-0061: using tuner params #0 (ntsc)
Feb 12 20:32:14 opus kernel: tuner-simple 1-0061: freq = 400.00 (6400), range = 1, config = 0xce, cb = 0x02
Feb 12 20:32:14 opus kernel: tuner-simple 1-0061: Freq= 400.00 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=7132
Feb 12 20:32:14 opus kernel: tuner-simple 1-0061: tv 0x1b 0xdc 0xce 0x02
Feb 12 20:32:14 opus kernel: tuner 1-0061: tv freq set to 400.00
Feb 12 20:32:14 opus kernel: tuner-simple 1-0061: using tuner params #0 (ntsc)
Feb 12 20:32:14 opus kernel: tuner-simple 1-0061: freq = 400.00 (6400), range = 1, config = 0xce, cb = 0x02
Feb 12 20:32:14 opus kernel: tuner-simple 1-0061: Freq= 400.00 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=7132
Feb 12 20:32:14 opus kernel: tuner-simple 1-0061: tv 0x1b 0xdc 0xce 0x02
Feb 12 20:32:14 opus kernel: tuner 1-0061: tv freq set to 400.00
Feb 12 20:32:14 opus kernel: tuner-simple 1-0061: using tuner params #0 (ntsc)
Feb 12 20:32:14 opus kernel: tuner-simple 1-0061: freq = 400.00 (6400), range = 1, config = 0xce, cb = 0x02
Feb 12 20:32:14 opus kernel: tuner-simple 1-0061: Freq= 400.00 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=7132
Feb 12 20:32:14 opus kernel: tuner-simple 1-0061: tv 0x1b 0xdc 0xce 0x02
Feb 12 20:32:14 opus kernel: tuner 1-0061: tv freq set to 211.25
Feb 12 20:32:14 opus kernel: tuner-simple 1-0061: using tuner params #0 (ntsc)
Feb 12 20:32:14 opus kernel: tuner-simple 1-0061: freq = 211.25 (3380), range = 1, config = 0xce, cb = 0x02
Feb 12 20:32:14 opus kernel: tuner-simple 1-0061: Freq= 211.25 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=4112
Feb 12 20:32:14 opus kernel: tuner-simple 1-0061: tv 0x10 0x10 0xce 0x02
Feb 12 20:32:16 opus kernel: tuner 1-0061: tv freq set to 121.25
Feb 12 20:32:16 opus kernel: tuner-simple 1-0061: using tuner params #0 (ntsc)
Feb 12 20:32:16 opus kernel: tuner-simple 1-0061: freq = 121.25 (1940), range = 0, config = 0xce, cb = 0x01
Feb 12 20:32:16 opus kernel: tuner-simple 1-0061: Freq= 121.25 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=2672
Feb 12 20:32:16 opus kernel: tuner-simple 1-0061: tv 0x0a 0x70 0xce 0x01
Feb 12 20:32:17 opus kernel: tuner 1-0061: tv freq set to 127.25
Feb 12 20:32:17 opus kernel: tuner-simple 1-0061: using tuner params #0 (ntsc)
Feb 12 20:32:17 opus kernel: tuner-simple 1-0061: freq = 127.25 (2036), range = 0, config = 0xce, cb = 0x01
Feb 12 20:32:17 opus kernel: tuner-simple 1-0061: Freq= 127.25 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=2768
Feb 12 20:32:17 opus kernel: tuner-simple 1-0061: tv 0x0a 0xd0 0xce 0x01
Feb 12 20:32:19 opus kernel: tuner 1-0061: tv freq set to 133.25
Feb 12 20:32:19 opus kernel: tuner-simple 1-0061: using tuner params #0 (ntsc)
Feb 12 20:32:19 opus kernel: tuner-simple 1-0061: freq = 133.25 (2132), range = 0, config = 0xce, cb = 0x01
Feb 12 20:32:19 opus kernel: tuner-simple 1-0061: Freq= 133.25 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=2864
Feb 12 20:32:19 opus kernel: tuner-simple 1-0061: tv 0x0b 0x30 0xce 0x01
Feb 12 20:32:20 opus kernel: tuner 1-0061: tv freq set to 139.25
Feb 12 20:32:20 opus kernel: tuner-simple 1-0061: using tuner params #0 (ntsc)
Feb 12 20:32:20 opus kernel: tuner-simple 1-0061: freq = 139.25 (2228), range = 0, config = 0xce, cb = 0x01
Feb 12 20:32:20 opus kernel: tuner-simple 1-0061: Freq= 139.25 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=2960
Feb 12 20:32:20 opus kernel: tuner-simple 1-0061: tv 0x0b 0x90 0xce 0x01
Feb 12 20:32:21 opus kernel: tuner 1-0061: tv freq set to 133.25
Feb 12 20:32:21 opus kernel: tuner-simple 1-0061: using tuner params #0 (ntsc)
Feb 12 20:32:21 opus kernel: tuner-simple 1-0061: freq = 133.25 (2132), range = 0, config = 0xce, cb = 0x01
Feb 12 20:32:21 opus kernel: tuner-simple 1-0061: Freq= 133.25 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=2864
Feb 12 20:32:21 opus kernel: tuner-simple 1-0061: tv 0x0b 0x30 0xce 0x01
Feb 12 20:32:22 opus kernel: tuner 1-0061: tv freq set to 127.25
Feb 12 20:32:22 opus kernel: tuner-simple 1-0061: using tuner params #0 (ntsc)
Feb 12 20:32:22 opus kernel: tuner-simple 1-0061: freq = 127.25 (2036), range = 0, config = 0xce, cb = 0x01
Feb 12 20:32:22 opus kernel: tuner-simple 1-0061: Freq= 127.25 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=2768
Feb 12 20:32:22 opus kernel: tuner-simple 1-0061: tv 0x0a 0xd0 0xce 0x01
Feb 12 20:32:23 opus kernel: tuner 1-0061: tv freq set to 121.25
Feb 12 20:32:23 opus kernel: tuner-simple 1-0061: using tuner params #0 (ntsc)
Feb 12 20:32:23 opus kernel: tuner-simple 1-0061: freq = 121.25 (1940), range = 0, config = 0xce, cb = 0x01
Feb 12 20:32:23 opus kernel: tuner-simple 1-0061: Freq= 121.25 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=2672
Feb 12 20:32:23 opus kernel: tuner-simple 1-0061: tv 0x0a 0x70 0xce 0x01
Feb 12 20:32:24 opus kernel: tuner 1-0061: tv freq set to 211.25
Feb 12 20:32:24 opus kernel: tuner-simple 1-0061: using tuner params #0 (ntsc)
Feb 12 20:32:24 opus kernel: tuner-simple 1-0061: freq = 211.25 (3380), range = 1, config = 0xce, cb = 0x02
Feb 12 20:32:24 opus kernel: tuner-simple 1-0061: Freq= 211.25 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=4112
Feb 12 20:32:24 opus kernel: tuner-simple 1-0061: tv 0x10 0x10 0xce 0x02


Stopping tvtime.

Feb 12 20:32:25 opus kernel: tuner 1-0061: Putting tuner to sleep
Feb 12 20:32:25 opus kernel: tuner 1-0061: Cmd TUNER_SET_STANDBY accepted for analog TV


tvtime worked fine.  The video was good and changing channels worked.


Starting mythbackend.

Feb 12 20:32:52 opus kernel: dvb_frontend_open
Feb 12 20:32:52 opus kernel: dvb_frontend_start
Feb 12 20:32:52 opus kernel: dvb_frontend_thread
Feb 12 20:32:52 opus kernel: dvb_frontend_ioctl
Feb 12 20:32:52 opus kernel: DVB: initialising adapter 0 frontend 0 (Nextwave NXT200X VSB/QAM frontend)...
Feb 12 20:32:52 opus kernel: dvb_frontend_release
Feb 12 20:32:52 opus kernel: dvb_frontend_open
Feb 12 20:32:52 opus kernel: dvb_frontend_start
Feb 12 20:32:52 opus kernel: dvb_frontend_ioctl
Feb 12 20:32:52 opus kernel: dvb_frontend_release
Feb 12 20:32:52 opus kernel: dvb_frontend_open
Feb 12 20:32:52 opus kernel: dvb_frontend_start
Feb 12 20:32:52 opus kernel: dvb_frontend_ioctl
Feb 12 20:32:52 opus kernel: dvb_frontend_ioctl
Feb 12 20:32:52 opus kernel: dvb_frontend_get_event
Feb 12 20:32:52 opus kernel: dvb_frontend_ioctl
Feb 12 20:32:52 opus kernel: dvb_frontend_add_event
Feb 12 20:32:52 opus kernel: dvb_frontend_swzigzag_autotune: drift:0 inversion:0 auto_step:0 auto_sub_step:0 started_auto_step:0
Feb 12 20:32:52 opus kernel: nxt200x: nxt200x_microcontroller_stop
Feb 12 20:32:52 opus kernel: dvb_frontend_poll
Feb 12 20:32:52 opus kernel: dvb_frontend_ioctl
Feb 12 20:32:52 opus kernel: tuner-simple 1-0061: using tuner params #1 (digital)
Feb 12 20:32:52 opus kernel: tuner-simple 1-0061: freq = 693.00 (11088), range = 2, config = 0xc6, cb = 0x44
Feb 12 20:32:52 opus kernel: tuner-simple 1-0061: Philips TUV1236D ATSC/NTSC dual in: div=11792 | buf=0x2e,0x10,0xc6,0x44
Feb 12 20:32:52 opus kernel: nxt200x: nxt200x_writetuner
Feb 12 20:32:52 opus kernel: nxt200x: Tuner Bytes: 2E 10 C6 44
Feb 12 20:32:52 opus kernel: nxt200x: nxt200x_agc_reset
Feb 12 20:32:52 opus kernel: nxt200x: nxt200x_readreg_multibyte
Feb 12 20:32:52 opus kernel: nxt200x: nxt200x_writereg_multibyte
Feb 12 20:32:52 opus kernel: nxt200x: nxt200x_writereg_multibyte
Feb 12 20:32:52 opus kernel: nxt200x: nxt200x_readreg_multibyte
Feb 12 20:32:52 opus kernel: nxt200x: nxt200x_writereg_multibyte
Feb 12 20:32:52 opus kernel: nxt200x: nxt200x_readreg_multibyte
Feb 12 20:32:52 opus kernel: nxt200x: nxt200x_writereg_multibyte
Feb 12 20:32:53 opus kernel: nxt200x: nxt200x_readreg_multibyte
Feb 12 20:32:53 opus kernel: nxt200x: nxt200x_writereg_multibyte
Feb 12 20:32:53 opus kernel: nxt200x: nxt200x_readreg_multibyte
Feb 12 20:32:53 opus kernel: nxt200x: nxt200x_writereg_multibyte
Feb 12 20:32:53 opus last message repeated 2 times
Feb 12 20:32:53 opus kernel: nxt200x: nxt200x_readreg_multibyte
Feb 12 20:32:53 opus kernel: nxt200x: nxt200x_writereg_multibyte
Feb 12 20:32:53 opus kernel: nxt200x: nxt200x_readreg_multibyte
Feb 12 20:32:53 opus kernel: nxt200x: nxt200x_writereg_multibyte
Feb 12 20:32:53 opus kernel: nxt200x: nxt200x_microcontroller_start
Feb 12 20:32:53 opus kernel: nxt200x: nxt2004_microcontroller_init
Feb 12 20:32:53 opus kernel: dvb_frontend_release
Feb 12 20:32:53 opus kernel: tuner 1-0061: Cmd VIDIOC_S_STD accepted for analog TV
Feb 12 20:32:53 opus kernel: tuner 1-0061: tv freq set to 211.25
Feb 12 20:32:53 opus kernel: tuner-simple 1-0061: using tuner params #0 (ntsc)
Feb 12 20:32:53 opus kernel: tuner-simple 1-0061: freq = 211.25 (3380), range = 1, config = 0xce, cb = 0x02
Feb 12 20:32:53 opus kernel: tuner-simple 1-0061: Freq= 211.25 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=4112
Feb 12 20:32:53 opus kernel: tuner-simple 1-0061: tv 0x10 0x10 0xce 0x02
Feb 12 20:32:53 opus kernel: tuner 1-0061: tv freq set to 211.25
Feb 12 20:32:53 opus kernel: tuner-simple 1-0061: using tuner params #0 (ntsc)
Feb 12 20:32:53 opus kernel: tuner-simple 1-0061: freq = 211.25 (3380), range = 1, config = 0xce, cb = 0x02
Feb 12 20:32:53 opus kernel: tuner-simple 1-0061: Freq= 211.25 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=4112
Feb 12 20:32:53 opus kernel: tuner-simple 1-0061: tv 0x10 0x10 0xce 0x02
Feb 12 20:32:53 opus kernel: tuner 1-0061: tv freq set to 211.25
Feb 12 20:32:53 opus kernel: tuner-simple 1-0061: using tuner params #0 (ntsc)
Feb 12 20:32:53 opus kernel: tuner-simple 1-0061: freq = 211.25 (3380), range = 1, config = 0xce, cb = 0x02
Feb 12 20:32:53 opus kernel: tuner-simple 1-0061: Freq= 211.25 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=4112
Feb 12 20:32:53 opus kernel: tuner-simple 1-0061: tv 0x10 0x10 0xce 0x02
Feb 12 20:32:53 opus kernel: tuner 1-0061: tv freq set to 211.25
Feb 12 20:32:53 opus kernel: tuner-simple 1-0061: using tuner params #0 (ntsc)
Feb 12 20:32:53 opus kernel: tuner-simple 1-0061: freq = 211.25 (3380), range = 1, config = 0xce, cb = 0x02
Feb 12 20:32:53 opus kernel: tuner-simple 1-0061: Freq= 211.25 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=4112
Feb 12 20:32:53 opus kernel: tuner-simple 1-0061: tv 0x10 0x10 0xce 0x02
Feb 12 20:32:53 opus kernel: tuner 1-0061: tv freq set to 211.25
Feb 12 20:32:53 opus kernel: tuner-simple 1-0061: using tuner params #0 (ntsc)
Feb 12 20:32:53 opus kernel: tuner-simple 1-0061: freq = 211.25 (3380), range = 1, config = 0xce, cb = 0x02
Feb 12 20:32:53 opus kernel: tuner-simple 1-0061: Freq= 211.25 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=4112
Feb 12 20:32:53 opus kernel: tuner-simple 1-0061: tv 0x10 0x10 0xce 0x02
Feb 12 20:32:53 opus kernel: tuner 1-0061: tv freq set to 175.25
Feb 12 20:32:53 opus kernel: tuner-simple 1-0061: using tuner params #0 (ntsc)
Feb 12 20:32:53 opus kernel: tuner-simple 1-0061: freq = 175.25 (2804), range = 1, config = 0xce, cb = 0x02
Feb 12 20:32:53 opus kernel: tuner-simple 1-0061: Freq= 175.25 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=3536
Feb 12 20:32:53 opus kernel: tuner-simple 1-0061: tv 0x0d 0xd0 0xce 0x02
Feb 12 20:32:53 opus kernel: tuner 1-0061: Putting tuner to sleep
Feb 12 20:32:53 opus kernel: tuner 1-0061: Cmd TUNER_SET_STANDBY accepted for analog TV


Starting a mythtv recording.

Feb 12 20:34:12 opus kernel: tuner 1-0061: Cmd VIDIOC_S_STD accepted for analog TV
Feb 12 20:34:12 opus kernel: tuner 1-0061: tv freq set to 175.25
Feb 12 20:34:12 opus kernel: tuner-simple 1-0061: using tuner params #0 (ntsc)
Feb 12 20:34:12 opus kernel: tuner-simple 1-0061: freq = 175.25 (2804), range = 1, config = 0xce, cb = 0x02
Feb 12 20:34:12 opus kernel: tuner-simple 1-0061: Freq= 175.25 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=3536
Feb 12 20:34:12 opus kernel: tuner-simple 1-0061: tv 0x0d 0xd0 0xce 0x02
Feb 12 20:34:13 opus kernel: tuner 1-0061: tv freq set to 175.25
Feb 12 20:34:13 opus kernel: tuner-simple 1-0061: using tuner params #0 (ntsc)
Feb 12 20:34:13 opus kernel: tuner-simple 1-0061: freq = 175.25 (2804), range = 1, config = 0xce, cb = 0x02
Feb 12 20:34:13 opus kernel: tuner-simple 1-0061: Freq= 175.25 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=3536
Feb 12 20:34:13 opus kernel: tuner-simple 1-0061: tv 0x0d 0xd0 0xce 0x02
Feb 12 20:34:13 opus kernel: tuner 1-0061: tv freq set to 175.25
Feb 12 20:34:13 opus kernel: tuner-simple 1-0061: using tuner params #0 (ntsc)
Feb 12 20:34:13 opus kernel: tuner-simple 1-0061: freq = 175.25 (2804), range = 1, config = 0xce, cb = 0x02
Feb 12 20:34:13 opus kernel: tuner-simple 1-0061: Freq= 175.25 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=3536
Feb 12 20:34:13 opus kernel: tuner-simple 1-0061: tv 0x0d 0xd0 0xce 0x02
Feb 12 20:34:13 opus kernel: tuner 1-0061: tv freq set to 67.25
Feb 12 20:34:13 opus kernel: tuner-simple 1-0061: using tuner params #0 (ntsc)
Feb 12 20:34:13 opus kernel: tuner-simple 1-0061: freq = 67.25 (1076), range = 0, config = 0xce, cb = 0x01
Feb 12 20:34:13 opus kernel: tuner-simple 1-0061: Freq= 67.25 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=1808
Feb 12 20:34:13 opus kernel: tuner-simple 1-0061: tv 0x07 0x10 0xce 0x01
Feb 12 20:34:13 opus kernel: tuner 1-0061: Putting tuner to sleep
Feb 12 20:34:13 opus kernel: tuner 1-0061: Cmd TUNER_SET_STANDBY accepted for analog TV
Feb 12 20:34:13 opus kernel: tuner 1-0061: Cmd VIDIOC_S_STD accepted for analog TV
Feb 12 20:34:13 opus kernel: tuner 1-0061: tv freq set to 67.25
Feb 12 20:34:13 opus kernel: tuner-simple 1-0061: using tuner params #0 (ntsc)
Feb 12 20:34:13 opus kernel: tuner-simple 1-0061: freq = 67.25 (1076), range = 0, config = 0xce, cb = 0x01
Feb 12 20:34:13 opus kernel: tuner-simple 1-0061: Freq= 67.25 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=1808
Feb 12 20:34:13 opus kernel: tuner 1-0061: tv freq set to 67.25
Feb 12 20:34:13 opus kernel: tuner-simple 1-000a: using tuner params #0 (ntsc)
Feb 12 20:34:13 opus kernel: tuner-simple 1-000a: freq = 67.25 (1076), range = 0, config = 0xce, cb = 0x01
Feb 12 20:34:13 opus kernel: tuner-simple 1-000a: Freq= 67.25 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=1808
Feb 12 20:34:13 opus kernel: tuner-simple 1-0061: tv 0x07 0x10 0xce 0x01
Feb 12 20:34:13 opus kernel: tuner-simple 1-000a: tv 0x07 0x10 0xce 0x01
Feb 12 20:34:13 opus kernel: tuner 1-0061: tv freq set to 67.25
Feb 12 20:34:13 opus kernel: tuner-simple 1-000a: using tuner params #0 (ntsc)
Feb 12 20:34:13 opus kernel: tuner-simple 1-000a: freq = 67.25 (1076), range = 0, config = 0xce, cb = 0x01
Feb 12 20:34:13 opus kernel: tuner-simple 1-000a: Freq= 67.25 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=1808
Feb 12 20:34:13 opus kernel: tuner-simple 1-000a: tv 0x07 0x10 0xce 0x01


Stopping the myth recording.  

Feb 12 20:34:55 opus kernel: tuner 1-0061: Putting tuner to sleep
Feb 12 20:34:55 opus kernel: tuner 1-0061: Cmd TUNER_SET_STANDBY accepted for analog TV
Feb 12 20:34:55 opus kernel: tuner 1-0061: Putting tuner to sleep


The mythtv recording failed.  This time, the video was very poor and
from the wrong channel.  Other times, the video is all static.


Stopping mythbackend.


Unloading modules.

Feb 12 20:34:55 opus kernel: tuner 1-0061: Putting tuner to sleep
Feb 12 20:35:46 opus kernel: saa7134 ALSA driver for DMA sound unloaded
Feb 12 20:35:46 opus kernel: dvb_unregister_frontend
Feb 12 20:35:46 opus kernel: dvb_frontend_stop
Feb 12 20:35:46 opus kernel: tuner-simple 1-000a: destroying instance


Reloading modules 

Feb 12 20:36:03 opus kernel: Linux video capture interface: v2.00
Feb 12 20:36:03 opus kernel: saa7130/34: v4l2 driver version 0.2.14 loaded
Feb 12 20:36:03 opus kernel: saa7133[0]: found at 0000:04:07.0, rev: 209, irq: 18, latency: 64, mmio: 0xfebff800
Feb 12 20:36:03 opus kernel: saa7133[0]: subsystem: 17de:7352, board: Kworld ATSC110/115 [card=90,autodetected]
Feb 12 20:36:03 opus kernel: saa7133[0]: board init: gpio is 100
Feb 12 20:36:03 opus kernel: saa7133[0]: i2c eeprom 00: de 17 52 73 ff ff ff ff ff ff ff ff ff ff ff ff
Feb 12 20:36:03 opus kernel: saa7133[0]: i2c eeprom 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Feb 12 20:36:03 opus kernel: saa7133[0]: i2c eeprom 20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Feb 12 20:36:03 opus kernel: saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Feb 12 20:36:03 opus kernel: saa7133[0]: i2c eeprom 40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Feb 12 20:36:03 opus kernel: saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Feb 12 20:36:03 opus kernel: saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Feb 12 20:36:03 opus kernel: saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Feb 12 20:36:03 opus kernel: saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Feb 12 20:36:03 opus kernel: saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Feb 12 20:36:03 opus kernel: saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Feb 12 20:36:03 opus kernel: saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Feb 12 20:36:03 opus kernel: saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Feb 12 20:36:03 opus kernel: saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Feb 12 20:36:03 opus kernel: saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Feb 12 20:36:03 opus kernel: saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Feb 12 20:36:03 opus kernel: tuner 1-0061: Setting mode_mask to 0x0e
Feb 12 20:36:03 opus kernel: tuner 1-0061: chip found @ 0xc2 (saa7133[0])
Feb 12 20:36:03 opus kernel: tuner 1-0061: tuner 0x61: Tuner type absent
Feb 12 20:36:03 opus kernel: tuner 1-0061: Calling set_type_addr for type=68, addr=0xff, mode=0x0e, config=0x00
Feb 12 20:36:03 opus kernel: tuner 1-0061: defining GPIO callback
Feb 12 20:36:03 opus kernel: tuner-simple 1-0061: creating new instance
Feb 12 20:36:03 opus kernel: tuner-simple 1-0061: type set to 68 (Philips TUV1236D ATSC/NTSC dual in)
Feb 12 20:36:03 opus kernel: tuner-simple 1-0061: tuner 0 atv rf input will be autoselected
Feb 12 20:36:03 opus kernel: tuner-simple 1-0061: tuner 0 dtv rf input will be autoselected
Feb 12 20:36:03 opus kernel: tuner 1-0061: type set to Philips TUV1236D ATSC/NTSC dual in
Feb 12 20:36:03 opus kernel: tuner 1-0061: tv freq set to 400.00
Feb 12 20:36:03 opus kernel: tuner-simple 1-0061: desired params (pal) undefined for tuner 68
Feb 12 20:36:03 opus kernel: tuner-simple 1-0061: using tuner params #0 (ntsc)
Feb 12 20:36:03 opus kernel: tuner-simple 1-0061: freq = 400.00 (6400), range = 1, config = 0xce, cb = 0x02
Feb 12 20:36:03 opus kernel: tuner-simple 1-0061: Freq= 400.00 MHz, V_IF=38.93 MHz, Offset=0.00 MHz, div=7023
Feb 12 20:36:03 opus kernel: tuner-simple 1-0061: tv 0x1b 0x6f 0xce 0x02
Feb 12 20:36:03 opus kernel: tuner 1-0061: saa7133[0] tuner I2C addr 0xc2 with type 68 used for 0x0e
Feb 12 20:36:03 opus kernel: tuner 1-0061: switching to v4l2
Feb 12 20:36:03 opus kernel: tuner 1-0061: tv freq set to 400.00
Feb 12 20:36:03 opus kernel: tuner-simple 1-0061: desired params (pal) undefined for tuner 68
Feb 12 20:36:03 opus kernel: tuner-simple 1-0061: using tuner params #0 (ntsc)
Feb 12 20:36:03 opus kernel: tuner-simple 1-0061: freq = 400.00 (6400), range = 1, config = 0xce, cb = 0x02
Feb 12 20:36:03 opus kernel: tuner-simple 1-0061: Freq= 400.00 MHz, V_IF=38.93 MHz, Offset=0.00 MHz, div=7023
Feb 12 20:36:03 opus kernel: tuner-simple 1-0061: tv 0x1b 0x6f 0xce 0x02
Feb 12 20:36:03 opus kernel: tuner 1-0061: tv freq set to 400.00
Feb 12 20:36:03 opus kernel: tuner-simple 1-0061: desired params (pal) undefined for tuner 68
Feb 12 20:36:03 opus kernel: tuner-simple 1-0061: using tuner params #0 (ntsc)
Feb 12 20:36:03 opus kernel: tuner-simple 1-0061: freq = 400.00 (6400), range = 1, config = 0xce, cb = 0x02
Feb 12 20:36:03 opus kernel: tuner-simple 1-0061: Freq= 400.00 MHz, V_IF=38.93 MHz, Offset=0.00 MHz, div=7023
Feb 12 20:36:03 opus kernel: tuner-simple 1-0061: tv 0x1b 0x6f 0xce 0x02
Feb 12 20:36:03 opus kernel: tuner 1-0061: Putting tuner to sleep
Feb 12 20:36:03 opus kernel: tuner 1-0061: Cmd TUNER_SET_STANDBY accepted for analog TV
Feb 12 20:36:03 opus kernel: saa7133[0]: registered device video2 [v4l2]
Feb 12 20:36:03 opus kernel: saa7133[0]: registered device vbi2
Feb 12 20:36:03 opus kernel: saa7134 ALSA driver for DMA sound loaded
Feb 12 20:36:03 opus kernel: saa7133[0]/alsa: saa7133[0] at 0xfebff800 irq 18 registered as card 2
Feb 12 20:36:03 opus kernel: dvb_init() allocating 1 frontend
Feb 12 20:36:03 opus kernel: nxt200x: NXT info: 05 02 09 20 01
Feb 12 20:36:03 opus kernel: nxt200x: NXT2004 Detected
Feb 12 20:36:03 opus kernel: tuner-simple 1-0061: attaching existing instance
Feb 12 20:36:03 opus kernel: tuner-simple 1-0061: type set to 68 (Philips TUV1236D ATSC/NTSC dual in)
Feb 12 20:36:03 opus kernel: tuner-simple 1-0061: tuner 0 atv rf input will be autoselected
Feb 12 20:36:03 opus kernel: tuner-simple 1-0061: tuner 0 dtv rf input will be autoselected
Feb 12 20:36:03 opus kernel: DVB: registering new adapter (saa7133[0])
Feb 12 20:36:03 opus kernel: dvb_register_frontend
Feb 12 20:36:03 opus kernel: DVB: registering adapter 0 frontend 0 (Nextwave NXT200X VSB/QAM frontend)...
Feb 12 20:36:03 opus kernel: nxt2004: Waiting for firmware upload (dvb-fe-nxt2004.fw)...
Feb 12 20:36:03 opus kernel: firmware: requesting dvb-fe-nxt2004.fw
Feb 12 20:36:03 opus kernel: nxt2004: Waiting for firmware upload(2)...
Feb 12 20:36:03 opus kernel: nxt200x: nxt2004_load_firmware
Feb 12 20:36:03 opus kernel: nxt200x: Firmware is 9584 bytes
Feb 12 20:36:05 opus kernel: nxt200x: firmware crc is 0xF1 0xB2
Feb 12 20:36:05 opus kernel: nxt2004: Firmware upload complete
Feb 12 20:36:05 opus kernel: nxt200x: nxt2004_microcontroller_init
Feb 12 20:36:05 opus kernel: nxt200x: nxt200x_microcontroller_stop
Feb 12 20:36:05 opus kernel: nxt200x: nxt200x_microcontroller_stop
Feb 12 20:36:05 opus kernel: nxt200x: nxt2004_microcontroller_init
Feb 12 20:36:05 opus kernel: nxt200x: nxt200x_microcontroller_stop
Feb 12 20:36:05 opus kernel: nxt200x: nxt200x_writereg_multibyte
Feb 12 20:36:05 opus last message repeated 2 times
Feb 12 20:36:05 opus kernel: nxt200x: nxt200x_readreg_multibyte
Feb 12 20:36:05 opus kernel: nxt200x: nxt200x_writereg_multibyte
Feb 12 20:36:05 opus kernel: nxt200x: nxt200x_readreg_multibyte
Feb 12 20:36:05 opus kernel: nxt200x: nxt200x_writereg_multibyte
Feb 12 20:36:05 opus kernel: nxt200x: nxt200x_readreg_multibyte
Feb 12 20:36:05 opus kernel: nxt200x: nxt200x_writereg_multibyte
Feb 12 20:36:05 opus kernel: nxt200x: nxt200x_readreg_multibyte
Feb 12 20:36:05 opus kernel: nxt200x: nxt200x_writereg_multibyte
Feb 12 20:36:05 opus last message repeated 2 times
Feb 12 20:36:05 opus kernel: nxt200x: nxt200x_readreg_multibyte
Feb 12 20:36:05 opus kernel: nxt200x: nxt200x_writereg_multibyte
Feb 12 20:36:05 opus kernel: nxt200x: nxt200x_readreg_multibyte
Feb 12 20:36:05 opus kernel: nxt200x: nxt200x_writereg_multibyte
Feb 12 20:36:05 opus kernel: nxt200x: nxt2004_microcontroller_init
Feb 12 20:36:05 opus kernel: nxt200x: nxt200x_readreg_multibyte
Feb 12 20:36:05 opus kernel: nxt200x: nxt200x_writereg_multibyte
Feb 12 20:36:05 opus kernel: nxt200x: nxt200x_readreg_multibyte
Feb 12 20:36:05 opus kernel: nxt200x: nxt200x_writereg_multibyte
Feb 12 20:36:05 opus kernel: nxt200x: nxt200x_readreg_multibyte
Feb 12 20:36:05 opus kernel: nxt200x: nxt200x_writereg_multibyte
Feb 12 20:36:05 opus kernel: nxt200x: nxt200x_readreg_multibyte
Feb 12 20:36:05 opus kernel: nxt200x: nxt200x_writereg_multibyte
Feb 12 20:36:05 opus kernel: nxt200x: nxt200x_readreg_multibyte
Feb 12 20:36:05 opus kernel: nxt200x: nxt200x_writereg_multibyte
Feb 12 20:36:05 opus last message repeated 2 times
Feb 12 20:36:05 opus kernel: nxt200x: nxt200x_readreg_multibyte
Feb 12 20:36:05 opus kernel: nxt200x: nxt200x_writereg_multibyte
Feb 12 20:36:05 opus kernel: nxt200x: nxt200x_readreg_multibyte
Feb 12 20:36:05 opus kernel: nxt200x: nxt200x_writereg_multibyte
Feb 12 20:36:05 opus kernel: tuner 1-0061: Cmd VIDIOC_S_STD accepted for analog TV
Feb 12 20:36:05 opus kernel: tuner 1-0061: tv freq set to 400.00
Feb 12 20:36:05 opus kernel: tuner-simple 1-0061: desired params (pal) undefined for tuner 68
Feb 12 20:36:05 opus kernel: tuner-simple 1-0061: using tuner params #0 (ntsc)
Feb 12 20:36:05 opus kernel: tuner-simple 1-0061: freq = 400.00 (6400), range = 1, config = 0xce, cb = 0x02
Feb 12 20:36:05 opus kernel: tuner-simple 1-0061: Freq= 400.00 MHz, V_IF=38.93 MHz, Offset=0.00 MHz, div=7023
Feb 12 20:36:05 opus kernel: tuner-simple 1-0061: tv 0x1b 0x6f 0xce 0x02
Feb 12 20:36:05 opus kernel: tuner 1-0061: Putting tuner to sleep
Feb 12 20:36:05 opus kernel: tuner 1-0061: Cmd TUNER_SET_STANDBY accepted for analog TV
Feb 12 20:36:05 opus kernel: tuner 1-0061: Cmd VIDIOC_S_STD accepted for analog TV
Feb 12 20:36:05 opus kernel: tuner 1-0061: tv freq set to 400.00
Feb 12 20:36:05 opus kernel: tuner-simple 1-0061: desired params (pal) undefined for tuner 68
Feb 12 20:36:05 opus kernel: tuner-simple 1-0061: using tuner params #0 (ntsc)
Feb 12 20:36:05 opus kernel: tuner-simple 1-0061: freq = 400.00 (6400), range = 1, config = 0xce, cb = 0x02
Feb 12 20:36:05 opus kernel: tuner-simple 1-0061: Freq= 400.00 MHz, V_IF=38.93 MHz, Offset=0.00 MHz, div=7023
Feb 12 20:36:05 opus kernel: tuner-simple 1-0061: tv 0x1b 0x6f 0xce 0x02
Feb 12 20:36:05 opus kernel: tuner 1-0061: Putting tuner to sleep
Feb 12 20:36:05 opus kernel: tuner 1-0061: Cmd TUNER_SET_STANDBY accepted for analog TV


Starting tvtime.

Feb 12 20:36:23 opus kernel: tuner 1-0061: Cmd VIDIOC_S_STD accepted for analog TV
Feb 12 20:36:23 opus kernel: tuner 1-0061: tv freq set to 400.00
Feb 12 20:36:23 opus kernel: tuner-simple 1-0061: desired params (pal) undefined for tuner 68
Feb 12 20:36:23 opus kernel: tuner-simple 1-0061: using tuner params #0 (ntsc)
Feb 12 20:36:23 opus kernel: tuner-simple 1-0061: freq = 400.00 (6400), range = 1, config = 0xce, cb = 0x02
Feb 12 20:36:23 opus kernel: tuner-simple 1-0061: Freq= 400.00 MHz, V_IF=38.93 MHz, Offset=0.00 MHz, div=7023
Feb 12 20:36:23 opus kernel: tuner-simple 1-0061: tv 0x1b 0x6f 0xce 0x02
Feb 12 20:36:23 opus kernel: tuner 1-0061: tv freq set to 400.00
Feb 12 20:36:23 opus kernel: tuner-simple 1-0061: desired params (pal) undefined for tuner 68
Feb 12 20:36:23 opus kernel: tuner-simple 1-0061: using tuner params #0 (ntsc)
Feb 12 20:36:23 opus kernel: tuner-simple 1-0061: freq = 400.00 (6400), range = 1, config = 0xce, cb = 0x02
Feb 12 20:36:23 opus kernel: tuner-simple 1-0061: Freq= 400.00 MHz, V_IF=38.93 MHz, Offset=0.00 MHz, div=7023
Feb 12 20:36:23 opus kernel: tuner-simple 1-0061: tv 0x1b 0x6f 0xce 0x02
Feb 12 20:36:23 opus kernel: tuner 1-0061: tv freq set to 400.00
Feb 12 20:36:23 opus kernel: tuner-simple 1-0061: using tuner params #0 (ntsc)
Feb 12 20:36:23 opus kernel: tuner-simple 1-0061: freq = 400.00 (6400), range = 1, config = 0xce, cb = 0x02
Feb 12 20:36:23 opus kernel: tuner-simple 1-0061: Freq= 400.00 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=7132
Feb 12 20:36:23 opus kernel: tuner-simple 1-0061: tv 0x1b 0xdc 0xce 0x02
Feb 12 20:36:23 opus kernel: tuner 1-0061: tv freq set to 400.00
Feb 12 20:36:23 opus kernel: tuner-simple 1-0061: using tuner params #0 (ntsc)
Feb 12 20:36:23 opus kernel: tuner-simple 1-0061: freq = 400.00 (6400), range = 1, config = 0xce, cb = 0x02
Feb 12 20:36:23 opus kernel: tuner-simple 1-0061: Freq= 400.00 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=7132
Feb 12 20:36:23 opus kernel: tuner-simple 1-0061: tv 0x1b 0xdc 0xce 0x02
Feb 12 20:36:23 opus kernel: tuner 1-0061: tv freq set to 400.00
Feb 12 20:36:23 opus kernel: tuner-simple 1-0061: using tuner params #0 (ntsc)
Feb 12 20:36:23 opus kernel: tuner-simple 1-0061: freq = 400.00 (6400), range = 1, config = 0xce, cb = 0x02
Feb 12 20:36:23 opus kernel: tuner-simple 1-0061: Freq= 400.00 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=7132
Feb 12 20:36:23 opus kernel: tuner-simple 1-0061: tv 0x1b 0xdc 0xce 0x02
Feb 12 20:36:23 opus kernel: tuner 1-0061: tv freq set to 211.25
Feb 12 20:36:23 opus kernel: tuner-simple 1-0061: using tuner params #0 (ntsc)
Feb 12 20:36:23 opus kernel: tuner-simple 1-0061: freq = 211.25 (3380), range = 1, config = 0xce, cb = 0x02
Feb 12 20:36:23 opus kernel: tuner-simple 1-0061: Freq= 211.25 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=4112
Feb 12 20:36:23 opus kernel: tuner-simple 1-0061: tv 0x10 0x10 0xce 0x02
Feb 12 20:36:26 opus kernel: tuner 1-0061: tv freq set to 205.25
Feb 12 20:36:26 opus kernel: tuner-simple 1-0061: using tuner params #0 (ntsc)
Feb 12 20:36:26 opus kernel: tuner-simple 1-0061: freq = 205.25 (3284), range = 1, config = 0xce, cb = 0x02
Feb 12 20:36:26 opus kernel: tuner-simple 1-0061: Freq= 205.25 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=4016
Feb 12 20:36:26 opus kernel: tuner-simple 1-0061: tv 0x0f 0xb0 0xce 0x02
Feb 12 20:36:28 opus kernel: tuner 1-0061: tv freq set to 199.25
Feb 12 20:36:28 opus kernel: tuner-simple 1-0061: using tuner params #0 (ntsc)
Feb 12 20:36:28 opus kernel: tuner-simple 1-0061: freq = 199.25 (3188), range = 1, config = 0xce, cb = 0x02
Feb 12 20:36:28 opus kernel: tuner-simple 1-0061: Freq= 199.25 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=3920
Feb 12 20:36:28 opus kernel: tuner-simple 1-0061: tv 0x0f 0x50 0xce 0x02
Feb 12 20:36:29 opus kernel: tuner 1-0061: tv freq set to 205.25
Feb 12 20:36:29 opus kernel: tuner-simple 1-0061: using tuner params #0 (ntsc)
Feb 12 20:36:29 opus kernel: tuner-simple 1-0061: freq = 205.25 (3284), range = 1, config = 0xce, cb = 0x02
Feb 12 20:36:29 opus kernel: tuner-simple 1-0061: Freq= 205.25 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=4016
Feb 12 20:36:29 opus kernel: tuner-simple 1-0061: tv 0x0f 0xb0 0xce 0x02
Feb 12 20:36:30 opus kernel: tuner 1-0061: tv freq set to 211.25
Feb 12 20:36:30 opus kernel: tuner-simple 1-0061: using tuner params #0 (ntsc)
Feb 12 20:36:30 opus kernel: tuner-simple 1-0061: freq = 211.25 (3380), range = 1, config = 0xce, cb = 0x02
Feb 12 20:36:30 opus kernel: tuner-simple 1-0061: Freq= 211.25 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=4112
Feb 12 20:36:30 opus kernel: tuner-simple 1-0061: tv 0x10 0x10 0xce 0x02


Stopping tvtime.  

Feb 12 20:36:35 opus kernel: tuner 1-0061: Putting tuner to sleep
Feb 12 20:36:35 opus kernel: tuner 1-0061: Cmd TUNER_SET_STANDBY accepted for analog TV


tvtime worked fine, again.  The video was good and changing channels
worked.


Starting mythbackend.

Feb 12 20:37:05 opus kernel: dvb_frontend_open
Feb 12 20:37:05 opus kernel: dvb_frontend_start
Feb 12 20:37:05 opus kernel: dvb_frontend_thread
Feb 12 20:37:05 opus kernel: dvb_frontend_ioctl
Feb 12 20:37:05 opus kernel: DVB: initialising adapter 0 frontend 0 (Nextwave NXT200X VSB/QAM frontend)...
Feb 12 20:37:05 opus kernel: dvb_frontend_release
Feb 12 20:37:05 opus kernel: dvb_frontend_open
Feb 12 20:37:05 opus kernel: dvb_frontend_start
Feb 12 20:37:05 opus kernel: dvb_frontend_ioctl
Feb 12 20:37:05 opus kernel: dvb_frontend_release
Feb 12 20:37:05 opus kernel: dvb_frontend_open
Feb 12 20:37:05 opus kernel: dvb_frontend_start
Feb 12 20:37:05 opus kernel: dvb_frontend_ioctl
Feb 12 20:37:05 opus kernel: dvb_frontend_ioctl
Feb 12 20:37:05 opus kernel: dvb_frontend_get_event
Feb 12 20:37:05 opus kernel: dvb_frontend_ioctl
Feb 12 20:37:05 opus kernel: dvb_frontend_add_event
Feb 12 20:37:05 opus kernel: dvb_frontend_swzigzag_autotune: drift:0 inversion:0 auto_step:0 auto_sub_step:0 started_auto_step:0
Feb 12 20:37:05 opus kernel: nxt200x: nxt200x_microcontroller_stop
Feb 12 20:37:05 opus kernel: dvb_frontend_poll
Feb 12 20:37:05 opus kernel: dvb_frontend_ioctl
Feb 12 20:37:05 opus kernel: tuner-simple 1-0061: using tuner params #1 (digital)
Feb 12 20:37:05 opus kernel: tuner-simple 1-0061: freq = 693.00 (11088), range = 2, config = 0xc6, cb = 0x44
Feb 12 20:37:05 opus kernel: tuner-simple 1-0061: Philips TUV1236D ATSC/NTSC dual in: div=11792 | buf=0x2e,0x10,0xc6,0x44
Feb 12 20:37:05 opus kernel: nxt200x: nxt200x_writetuner
Feb 12 20:37:05 opus kernel: nxt200x: Tuner Bytes: 2E 10 C6 44
Feb 12 20:37:05 opus kernel: nxt200x: nxt200x_agc_reset
Feb 12 20:37:05 opus kernel: nxt200x: nxt200x_readreg_multibyte
Feb 12 20:37:05 opus kernel: nxt200x: nxt200x_writereg_multibyte
Feb 12 20:37:05 opus kernel: nxt200x: nxt200x_writereg_multibyte
Feb 12 20:37:06 opus kernel: nxt200x: nxt200x_readreg_multibyte
Feb 12 20:37:06 opus kernel: nxt200x: nxt200x_writereg_multibyte
Feb 12 20:37:06 opus kernel: nxt200x: nxt200x_readreg_multibyte
Feb 12 20:37:06 opus kernel: nxt200x: nxt200x_writereg_multibyte
Feb 12 20:37:06 opus kernel: nxt200x: nxt200x_readreg_multibyte
Feb 12 20:37:06 opus kernel: nxt200x: nxt200x_writereg_multibyte
Feb 12 20:37:06 opus kernel: nxt200x: nxt200x_readreg_multibyte
Feb 12 20:37:06 opus kernel: nxt200x: nxt200x_writereg_multibyte
Feb 12 20:37:06 opus last message repeated 2 times
Feb 12 20:37:06 opus kernel: nxt200x: nxt200x_readreg_multibyte
Feb 12 20:37:06 opus kernel: nxt200x: nxt200x_writereg_multibyte
Feb 12 20:37:06 opus kernel: nxt200x: nxt200x_readreg_multibyte
Feb 12 20:37:06 opus kernel: nxt200x: nxt200x_writereg_multibyte
Feb 12 20:37:06 opus kernel: nxt200x: nxt200x_microcontroller_start
Feb 12 20:37:06 opus kernel: nxt200x: nxt2004_microcontroller_init
Feb 12 20:37:06 opus kernel: dvb_frontend_release
Feb 12 20:37:06 opus kernel: tuner 1-0061: Cmd VIDIOC_S_STD accepted for analog TV
Feb 12 20:37:06 opus kernel: tuner 1-0061: tv freq set to 211.25
Feb 12 20:37:06 opus kernel: tuner-simple 1-0061: using tuner params #0 (ntsc)
Feb 12 20:37:06 opus kernel: tuner-simple 1-0061: freq = 211.25 (3380), range = 1, config = 0xce, cb = 0x02
Feb 12 20:37:06 opus kernel: tuner-simple 1-0061: Freq= 211.25 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=4112
Feb 12 20:37:06 opus kernel: tuner-simple 1-0061: tv 0x10 0x10 0xce 0x02
Feb 12 20:37:06 opus kernel: tuner 1-0061: tv freq set to 211.25
Feb 12 20:37:06 opus kernel: tuner-simple 1-0061: using tuner params #0 (ntsc)
Feb 12 20:37:06 opus kernel: tuner-simple 1-0061: freq = 211.25 (3380), range = 1, config = 0xce, cb = 0x02
Feb 12 20:37:06 opus kernel: tuner-simple 1-0061: Freq= 211.25 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=4112
Feb 12 20:37:06 opus kernel: tuner-simple 1-0061: tv 0x10 0x10 0xce 0x02
Feb 12 20:37:06 opus kernel: tuner 1-0061: tv freq set to 211.25
Feb 12 20:37:06 opus kernel: tuner-simple 1-0061: using tuner params #0 (ntsc)
Feb 12 20:37:06 opus kernel: tuner-simple 1-0061: freq = 211.25 (3380), range = 1, config = 0xce, cb = 0x02
Feb 12 20:37:06 opus kernel: tuner-simple 1-0061: Freq= 211.25 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=4112
Feb 12 20:37:06 opus kernel: tuner-simple 1-0061: tv 0x10 0x10 0xce 0x02
Feb 12 20:37:06 opus kernel: tuner 1-0061: tv freq set to 211.25
Feb 12 20:37:06 opus kernel: tuner-simple 1-0061: using tuner params #0 (ntsc)
Feb 12 20:37:06 opus kernel: tuner-simple 1-0061: freq = 211.25 (3380), range = 1, config = 0xce, cb = 0x02
Feb 12 20:37:06 opus kernel: tuner-simple 1-0061: Freq= 211.25 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=4112
Feb 12 20:37:06 opus kernel: tuner-simple 1-0061: tv 0x10 0x10 0xce 0x02
Feb 12 20:37:06 opus kernel: tuner 1-0061: tv freq set to 211.25
Feb 12 20:37:06 opus kernel: tuner-simple 1-0061: using tuner params #0 (ntsc)
Feb 12 20:37:06 opus kernel: tuner-simple 1-0061: freq = 211.25 (3380), range = 1, config = 0xce, cb = 0x02
Feb 12 20:37:06 opus kernel: tuner-simple 1-0061: Freq= 211.25 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=4112
Feb 12 20:37:06 opus kernel: tuner-simple 1-0061: tv 0x10 0x10 0xce 0x02
Feb 12 20:37:06 opus kernel: tuner 1-0061: tv freq set to 67.25
Feb 12 20:37:06 opus kernel: tuner-simple 1-0061: using tuner params #0 (ntsc)
Feb 12 20:37:06 opus kernel: tuner-simple 1-0061: freq = 67.25 (1076), range = 0, config = 0xce, cb = 0x01
Feb 12 20:37:06 opus kernel: tuner-simple 1-0061: Freq= 67.25 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=1808
Feb 12 20:37:06 opus kernel: tuner-simple 1-0061: tv 0x07 0x10 0xce 0x01
Feb 12 20:37:06 opus kernel: tuner 1-0061: Putting tuner to sleep
Feb 12 20:37:06 opus kernel: tuner 1-0061: Cmd TUNER_SET_STANDBY accepted for analog TV


Starting a mythtv recording.

Feb 12 20:37:48 opus kernel: tuner 1-0061: Cmd VIDIOC_S_STD accepted for analog TV
Feb 12 20:37:48 opus kernel: tuner 1-0061: tv freq set to 67.25
Feb 12 20:37:48 opus kernel: tuner-simple 1-0061: using tuner params #0 (ntsc)
Feb 12 20:37:48 opus kernel: tuner-simple 1-0061: freq = 67.25 (1076), range = 0, config = 0xce, cb = 0x01
Feb 12 20:37:48 opus kernel: tuner-simple 1-0061: Freq= 67.25 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=1808
Feb 12 20:37:48 opus kernel: tuner-simple 1-0061: tv 0x07 0x10 0xce 0x01
Feb 12 20:37:48 opus kernel: tuner 1-0061: tv freq set to 67.25
Feb 12 20:37:48 opus kernel: tuner-simple 1-0061: using tuner params #0 (ntsc)
Feb 12 20:37:48 opus kernel: tuner-simple 1-0061: freq = 67.25 (1076), range = 0, config = 0xce, cb = 0x01
Feb 12 20:37:48 opus kernel: tuner-simple 1-0061: Freq= 67.25 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=1808
Feb 12 20:37:48 opus kernel: tuner-simple 1-0061: tv 0x07 0x10 0xce 0x01
Feb 12 20:37:48 opus kernel: tuner 1-0061: tv freq set to 67.25
Feb 12 20:37:48 opus kernel: tuner-simple 1-0061: using tuner params #0 (ntsc)
Feb 12 20:37:48 opus kernel: tuner-simple 1-0061: freq = 67.25 (1076), range = 0, config = 0xce, cb = 0x01
Feb 12 20:37:48 opus kernel: tuner-simple 1-0061: Freq= 67.25 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=1808
Feb 12 20:37:48 opus kernel: tuner-simple 1-0061: tv 0x07 0x10 0xce 0x01
Feb 12 20:37:48 opus kernel: tuner 1-0061: tv freq set to 67.25
Feb 12 20:37:48 opus kernel: tuner-simple 1-0061: using tuner params #0 (ntsc)
Feb 12 20:37:48 opus kernel: tuner-simple 1-0061: freq = 67.25 (1076), range = 0, config = 0xce, cb = 0x01
Feb 12 20:37:48 opus kernel: tuner-simple 1-0061: Freq= 67.25 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=1808
Feb 12 20:37:48 opus kernel: tuner-simple 1-0061: tv 0x07 0x10 0xce 0x01
Feb 12 20:37:48 opus kernel: tuner 1-0061: Putting tuner to sleep
Feb 12 20:37:48 opus kernel: tuner 1-0061: Cmd TUNER_SET_STANDBY accepted for analog TV
Feb 12 20:37:48 opus kernel: tuner 1-0061: Cmd VIDIOC_S_STD accepted for analog TV
Feb 12 20:37:48 opus kernel: tuner 1-0061: tv freq set to 67.25
Feb 12 20:37:48 opus kernel: tuner-simple 1-0061: using tuner params #0 (ntsc)
Feb 12 20:37:48 opus kernel: tuner-simple 1-0061: freq = 67.25 (1076), range = 0, config = 0xce, cb = 0x01
Feb 12 20:37:48 opus kernel: tuner-simple 1-0061: Freq= 67.25 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=1808
Feb 12 20:37:48 opus kernel: tuner 1-0061: tv freq set to 67.25
Feb 12 20:37:48 opus kernel: tuner-simple 1-000a: using tuner params #0 (ntsc)
Feb 12 20:37:48 opus kernel: tuner-simple 1-000a: freq = 67.25 (1076), range = 0, config = 0xce, cb = 0x01
Feb 12 20:37:48 opus kernel: tuner-simple 1-000a: Freq= 67.25 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=1808
Feb 12 20:37:48 opus kernel: tuner-simple 1-000a: tv 0x07 0x10 0xce 0x01
Feb 12 20:37:48 opus kernel: tuner-simple 1-0061: tv 0x07 0x10 0xce 0x01
Feb 12 20:37:48 opus kernel: tuner 1-0061: tv freq set to 67.25
Feb 12 20:37:48 opus kernel: tuner-simple 1-0061: using tuner params #0 (ntsc)
Feb 12 20:37:48 opus kernel: tuner-simple 1-0061: freq = 67.25 (1076), range = 0, config = 0xce, cb = 0x01
Feb 12 20:37:48 opus kernel: tuner-simple 1-0061: Freq= 67.25 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=1808
Feb 12 20:37:48 opus kernel: tuner-simple 1-0061: tv 0x07 0x10 0xce 0x01


Stopping the mythtv recording.  

Feb 12 20:38:43 opus kernel: tuner 1-0061: Putting tuner to sleep
Feb 12 20:38:43 opus kernel: tuner 1-0061: Cmd TUNER_SET_STANDBY accepted for analog TV
Feb 12 20:38:43 opus kernel: tuner 1-0061: Putting tuner to sleep
Feb 12 20:38:43 opus kernel: tuner 1-0061: Putting tuner to sleep


The mythtv recording worked fine this time.


David
-- 
David Engel
david@istwok.net

Re: KWorld ATSC 115 all static

[Mauro Carvalho Chehab]

On Thu, 12 Feb 2009 21:07:50 -0600
David Engel <david@istwok.net> wrote:

> On Wed, Feb 11, 2009 at 05:21:49PM -0600, David Engel wrote:
> > On Wed, Feb 11, 2009 at 05:43:29AM -0200, Mauro Carvalho Chehab wrote:
> > > On Tue, 10 Feb 2009 21:50:16 -0600
> > > David Engel <david@istwok.net> wrote:
> > > > MythTV eventually worked too, but I had to do the
> > > > "unload/reload modules and run tvtime" procedure I reported earlier
> > > > when I tried Hans' kworld tree.
> > > 
> > > Maybe this is a race condition I have here with tda1004x. With tda1004x, the i2c
> > > bus shouldn't be used by any other device during the firmware transfers,
> > > otherwise the firmware load will fail, and tda1004x goes into an unstable
> > > state. With this device, it even affects all subsequent i2c acesses. The only
> > > alternative to recover tda1004x is to reboot the card (e. g. with my cardbus
> > > device, I have to physically remove it and re-insert).
> > > 
> > > What happens is that some softwares (including udev) open the device, and send
> > > some VIDIOC_G_TUNER in order to check some tuner characteristics. However, this
> > > command generates some i2c transfers, to retrieve signal strength. If this
> > > happens while the firmware is being loaded, the bug occurs.
> > > 
> > > In order to fix, a careful review of all locks on the driver is needed. We will
> > > likely need to change the demod interface for the boards that have this
> > > trouble, in order to be aware of when a firmware transfer started.
> > > 
> > > This lock review is currently on my TODO list.
> > > 
> > > To be sure that this is the case, could you please add this on
> > > your /etc/modprobe (or at a file inside /etc/modprobe.d):
> > > 
> > > 	options nxt200x debug=1
> > > 	options tuner-simple debug=1
> > > 	options tuner debug=1
> > > 	options dvb-core frontend_debug=1
> > > 
> > > And test again, sending us the produced logs when the device works and when it
> > > breaks. I guess we'll discover some tuner dmesg's in the middle of the firmware
> > > load sequence.
> > 
> > I will do this, but it will be tomorrow evening before I can get to
> > it.
> 
> Here are my logs.  They are annoteded in-line with the actions I took.
> I need to add that the results with MythTv aren't always consistent.
> Sometimes it works right away when I don't expect it to and sometimes
> it doesn't work after the reload when I do expect it to.  The results
> shown below are what happens most of the time -- MythTV doesn't work
> until the modules are reloaded and tvtime is run.

Ok, I did a diff between the two logs. On the first module probing,
saa7134-alsa were probed before than on the second log. I don't think that this
would be relevant for this issue.

However, on both logs, we see a tuner write to the wrong address (0x0a, instead
of 0x61):

First log sequence (mythtv broken):
> Feb 12 20:34:13 opus kernel: tuner-simple 1-000a: using tuner params #0 (ntsc)
> Feb 12 20:34:13 opus kernel: tuner-simple 1-000a: freq = 67.25 (1076), range = 0, config = 0xce, cb = 0x01
> Feb 12 20:34:13 opus kernel: tuner-simple 1-000a: Freq= 67.25 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=1808
> Feb 12 20:34:13 opus kernel: tuner-simple 1-0061: tv 0x07 0x10 0xce 0x01
> Feb 12 20:34:13 opus kernel: tuner-simple 1-000a: tv 0x07 0x10 0xce 0x01
> Feb 12 20:34:13 opus kernel: tuner 1-0061: tv freq set to 67.25
> Feb 12 20:34:13 opus kernel: tuner-simple 1-000a: using tuner params #0 (ntsc)
> Feb 12 20:34:13 opus kernel: tuner-simple 1-000a: freq = 67.25 (1076), range = 0, config = 0xce, cb = 0x01
> Feb 12 20:34:13 opus kernel: tuner-simple 1-000a: Freq= 67.25 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=1808
> Feb 12 20:34:13 opus kernel: tuner-simple 1-000a: tv 0x07 0x10 0xce 0x01


Second log sequence (mythtv ok):

> Feb 12 20:37:48 opus kernel: tuner-simple 1-000a: using tuner params #0 (ntsc)
> Feb 12 20:37:48 opus kernel: tuner-simple 1-000a: freq = 67.25 (1076), range = 0, config = 0xce, cb = 0x01
> Feb 12 20:37:48 opus kernel: tuner-simple 1-000a: Freq= 67.25 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=1808
> Feb 12 20:37:48 opus kernel: tuner-simple 1-000a: tv 0x07 0x10 0xce 0x01

Aparently, the second tuner call setting went to the proper i2c address:
> Feb 12 20:37:48 opus kernel: tuner-simple 1-0061: tv 0x07 0x10 0xce 0x01
> Feb 12 20:37:48 opus kernel: tuner 1-0061: tv freq set to 67.25
> Feb 12 20:37:48 opus kernel: tuner-simple 1-0061: using tuner params #0 (ntsc)
> Feb 12 20:37:48 opus kernel: tuner-simple 1-0061: freq = 67.25 (1076), range = 0, config = 0xce, cb = 0x01
> Feb 12 20:37:48 opus kernel: tuner-simple 1-0061: Freq= 67.25 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=1808
> Feb 12 20:37:48 opus kernel: tuner-simple 1-0061: tv 0x07 0x10 0xce 0x01

It seems that some parts of saa7134 (or frontend) is overriding the i2c
address,to write at the demod, causing a mess. Another alternative would be
some bug at v4l subdev interface.

I'll seek at saa7134 code to see who is causing this error.

Cheers,
Mauro

Re: KWorld ATSC 115 all static

[Mauro Carvalho Chehab]

On Fri, 13 Feb 2009 09:04:46 -0200
Mauro Carvalho Chehab <mchehab@infradead.org> wrote:

> It seems that some parts of saa7134 (or frontend) is overriding the i2c
> address,to write at the demod, causing a mess. Another alternative would be
> some bug at v4l subdev interface.
> 
> I'll seek at saa7134 code to see who is causing this error.

Ok, I found the bug. It is inside tuner-simple code. It is caused due to a hack for TUV1236.

I've just committed a fix for it:
	http://linuxtv.org/hg/v4l-dvb/rev/34ec729ed1a7

Please test.

Cheers,
Mauro

Re: KWorld ATSC 115 all static

[David Engel]

On Fri, Feb 13, 2009 at 09:28:45AM -0200, Mauro Carvalho Chehab wrote:
> On Fri, 13 Feb 2009 09:04:46 -0200
> Mauro Carvalho Chehab <mchehab@infradead.org> wrote:
> 
> > It seems that some parts of saa7134 (or frontend) is overriding the i2c
> > address,to write at the demod, causing a mess. Another alternative would be
> > some bug at v4l subdev interface.
> > 
> > I'll seek at saa7134 code to see who is causing this error.
> 
> Ok, I found the bug. It is inside tuner-simple code. It is caused due to a hack for TUV1236.
> 
> I've just committed a fix for it:
> 	http://linuxtv.org/hg/v4l-dvb/rev/34ec729ed1a7
> 
> Please test.

In limited, remote testing -- it works!  It also works on my
production MythTV backend with 2 ATSC 115s.  This is the first time
analog has ever worked on both of those cards at the same time.  I'll
do more testing over the weekend.  Thanks very much, Mauro, Hans and
everyone else involved.

David
-- 
David Engel
david@istwok.net

Re: KWorld ATSC 115 all static

[Mauro Carvalho Chehab]

On Fri, 13 Feb 2009 14:28:11 -0600
David Engel <david@istwok.net> wrote:

> On Fri, Feb 13, 2009 at 09:28:45AM -0200, Mauro Carvalho Chehab wrote:
> > On Fri, 13 Feb 2009 09:04:46 -0200
> > Mauro Carvalho Chehab <mchehab@infradead.org> wrote:
> > 
> > > It seems that some parts of saa7134 (or frontend) is overriding the i2c
> > > address,to write at the demod, causing a mess. Another alternative would be
> > > some bug at v4l subdev interface.
> > > 
> > > I'll seek at saa7134 code to see who is causing this error.
> > 
> > Ok, I found the bug. It is inside tuner-simple code. It is caused due to a hack for TUV1236.
> > 
> > I've just committed a fix for it:
> > 	http://linuxtv.org/hg/v4l-dvb/rev/34ec729ed1a7
> > 
> > Please test.
> 
> In limited, remote testing -- it works!  It also works on my
> production MythTV backend with 2 ATSC 115s.  This is the first time
> analog has ever worked on both of those cards at the same time.  I'll
> do more testing over the weekend.  Thanks very much, Mauro, Hans and
> everyone else involved.

Great news!

Cheers,
Mauro

Re: KWorld ATSC 115 all static

[David Engel]

On Fri, Feb 13, 2009 at 02:28:11PM -0600, David Engel wrote:
> On Fri, Feb 13, 2009 at 09:28:45AM -0200, Mauro Carvalho Chehab wrote:
> > Ok, I found the bug. It is inside tuner-simple code. It is caused due to a hack for TUV1236.
> > 
> > I've just committed a fix for it:
> > 	http://linuxtv.org/hg/v4l-dvb/rev/34ec729ed1a7
> > 
> > Please test.
> 
> In limited, remote testing -- it works!  It also works on my
> production MythTV backend with 2 ATSC 115s.  This is the first time
> analog has ever worked on both of those cards at the same time.  I'll
> do more testing over the weekend.  Thanks very much, Mauro, Hans and
> everyone else involved.

I didn't get to test as much as I'd hoped but I did do some.  The
fixed analog support on my ATSC 115s worked great.  Thanks again.

David
-- 
David Engel
david@istwok.net

Re: KWorld ATSC 115 all static

[Hans Verkuil]

On Tuesday 17 February 2009 16:53:29 David Engel wrote:
> On Fri, Feb 13, 2009 at 02:28:11PM -0600, David Engel wrote:
> > On Fri, Feb 13, 2009 at 09:28:45AM -0200, Mauro Carvalho Chehab wrote:
> > > Ok, I found the bug. It is inside tuner-simple code. It is caused due
> > > to a hack for TUV1236.
> > >
> > > I've just committed a fix for it:
> > > 	http://linuxtv.org/hg/v4l-dvb/rev/34ec729ed1a7
> > >
> > > Please test.
> >
> > In limited, remote testing -- it works!  It also works on my
> > production MythTV backend with 2 ATSC 115s.  This is the first time
> > analog has ever worked on both of those cards at the same time.  I'll
> > do more testing over the weekend.  Thanks very much, Mauro, Hans and
> > everyone else involved.
>
> I didn't get to test as much as I'd hoped but I did do some.  The
> fixed analog support on my ATSC 115s worked great.  Thanks again.
>
> David

Can I remove my v4l-dvb-kworld tree? I gather that it is now fixed in the 
master repo?

Regards,

	Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

Re: KWorld ATSC 115 all static

[David Engel]

On Wed, Feb 18, 2009 at 08:45:57AM +0100, Hans Verkuil wrote:
> On Tuesday 17 February 2009 16:53:29 David Engel wrote:
> > On Fri, Feb 13, 2009 at 02:28:11PM -0600, David Engel wrote:
> > > On Fri, Feb 13, 2009 at 09:28:45AM -0200, Mauro Carvalho Chehab wrote:
> > > > Ok, I found the bug. It is inside tuner-simple code. It is caused due
> > > > to a hack for TUV1236.
> > > >
> > > > I've just committed a fix for it:
> > > > 	http://linuxtv.org/hg/v4l-dvb/rev/34ec729ed1a7
> > > >
> > > > Please test.
> > >
> > > In limited, remote testing -- it works!  It also works on my
> > > production MythTV backend with 2 ATSC 115s.  This is the first time
> > > analog has ever worked on both of those cards at the same time.  I'll
> > > do more testing over the weekend.  Thanks very much, Mauro, Hans and
> > > everyone else involved.
> >
> > I didn't get to test as much as I'd hoped but I did do some.  The
> > fixed analog support on my ATSC 115s worked great.  Thanks again.
> >
> > David
> 
> Can I remove my v4l-dvb-kworld tree? I gather that it is now fixed in the 
> master repo?

That would be fine with me.

David
-- 
David Engel
david@istwok.net

Re: KWorld ATSC 115 all static

[Mauro Carvalho Chehab]

On Tue, 10 Feb 2009 04:14:03 +0100
hermann pitton <hermann-pitton@arcor.de> wrote:

> 
> Am Dienstag, den 10.02.2009, 00:35 -0200 schrieb Mauro Carvalho Chehab:
> > On Tue, 10 Feb 2009 02:31:00 +0100
> > hermann pitton <hermann-pitton@arcor.de> wrote:
> > 
> > > > > Mauro, I know you are waiting for CityK, but I can report so far that I
> > > > > never did see that black screen going away by adjusting the controls and
> > > > > never had that black screen.
> > > > > 
> > > > > Tvtime and xawtv were always working under my conditions so far.
> > 
> > Good to know.
> > 
> > > > > The very old troubles, like tda9887 not present after boot on my md7134
> > > > > devices with FMD1216ME MK3 hybrid, and the even unrelated issue with the
> > > > > tda10046 not properly controlled anymore after suspend/resume,
> > > > > are unchanged on your current saa7134 attempt, but also no new issues
> > > > > visible so far.
> > 
> > Ok, let's go by parts:
> > 
> > 1) We need to know the sequence that enables tda9887 on md7134/fmd1216me, in
> > order to fix it. If someone has fmd1216me, please write me in priv or help us
> > to fix the code for it.
> > 
> > 2) I bet that the issue with tda10046 is related to firmware loading. I made
> > some tests with a TV @nyware cardbus device that has a tda10046 + tda8290/tda8975.
> > 
> > What happens is that this device supports two type of firmware loads. The first
> > one requires an i2c eeprom with the firmware inside. The driver just writes
> > 0x04 at register 0x07 and waits for some time. The hardware does the firmware load.
> > 
> > On the second mode, firmware bytes are transferred from the driver into the tda10046 memory.
> > 
> > At the tests I made here, on both modes, the i2c bus can't have any other
> > traffic during the firmware load. Otherwise, an invalid firmware will be loaded
> > and tda10046 will hangup.
> > 
> > I've started to implement some locks at saa7134 driver (on my saa7134
> > experimental tree), but it is not finished yet. I didn't touch at the sleep code yet.
> > 
> > > > > 
> > > > 
> > > > BTW, just to remember.
> > > > 
> > > > Tvtime with signal detection on shows a blue screen without signal.
> > > > With signal detection off, just good old snow.
> > 
> > So, the tda9887 or the PLL are configured wrongly.
> > 
> > > > The tda8275/75a shows a black screen without having lock, not even snow,
> > > > if it should be related.
> > > 
> > > Sorry, to add one more about "black" screens :)
> > > 
> > > Without the tda9887 loaded, the FMD1216ME MK3 hybrid also shows a black
> > > screen, but it is slightly different from the fully black screen of the
> > > tda8275, which is in fact an overlay like the blue screen on tvtime. It
> > > has some white points visible and on some channels even _very_ decent
> > > ghosting of TV.
> > 
> > Probably, tda9887 is configured for STD/M, instead of STD/BG. Fixing tda9887
> > will also fix this issue.
> > 
> > > The status of the tda9885/6/7 on the TUV1236D is still not clear to me,
> > > until I see debug enabled on it for switching TV standards and just
> > > nothing ever changes.
> > 
> > Sorry but I didn't understand what you're meaning with your TUV1236D-based device.
> 
> Just for that one for now, I'll try on the other subjects later.
> 
> I don't have any TUV1236D based device, but CityK and maybe Michael on
> the Kworld _ATSC_ ! 110/15.
> 
> >From the photo provided by CityK, there is clearly a 24pin Philips
> device within the IF section of this tuner, which I guess is a tda9885
> NTSC only and nothing else.
> 
> As mentioned before, they can be strapped on one pin to be NTSC
> (System-M) only without needing _any_ i2c programming according to the
> data sheets.
> 
> With the reports so far, after years, either the tda9887 module is just
> fake loaded, even that fails, or nothing ever happens, or something
> happens on i2c we don't have clear.
> 
> So I would like to see if there is ever valid i2c traffic to that
> tda988x device on that tuner or never...

Maybe we don't need any extra programming for tda9885, but it won't hurt to
reprogram it to the right state. 


Cheers,
Mauro

Re: KWorld ATSC 115 all static

[hermann pitton]

Hi,

Am Dienstag, den 10.02.2009, 04:19 -0200 schrieb Mauro Carvalho Chehab:
> On Tue, 10 Feb 2009 04:14:03 +0100
> hermann pitton <hermann-pitton@arcor.de> wrote:
> 
> > 
> > Am Dienstag, den 10.02.2009, 00:35 -0200 schrieb Mauro Carvalho Chehab:
> > > On Tue, 10 Feb 2009 02:31:00 +0100
> > > hermann pitton <hermann-pitton@arcor.de> wrote:
> > > 
> > > > > > Mauro, I know you are waiting for CityK, but I can report so far that I
> > > > > > never did see that black screen going away by adjusting the controls and
> > > > > > never had that black screen.
> > > > > > 
> > > > > > Tvtime and xawtv were always working under my conditions so far.
> > > 
> > > Good to know.
> > > 
> > > > > > The very old troubles, like tda9887 not present after boot on my md7134
> > > > > > devices with FMD1216ME MK3 hybrid, and the even unrelated issue with the
> > > > > > tda10046 not properly controlled anymore after suspend/resume,
> > > > > > are unchanged on your current saa7134 attempt, but also no new issues
> > > > > > visible so far.
> > > 
> > > Ok, let's go by parts:
> > > 
> > > 1) We need to know the sequence that enables tda9887 on md7134/fmd1216me, in
> > > order to fix it. If someone has fmd1216me, please write me in priv or help us
> > > to fix the code for it.
> > > 
> > > 2) I bet that the issue with tda10046 is related to firmware loading. I made
> > > some tests with a TV @nyware cardbus device that has a tda10046 + tda8290/tda8975.
> > > 
> > > What happens is that this device supports two type of firmware loads. The first
> > > one requires an i2c eeprom with the firmware inside. The driver just writes
> > > 0x04 at register 0x07 and waits for some time. The hardware does the firmware load.
> > > 
> > > On the second mode, firmware bytes are transferred from the driver into the tda10046 memory.
> > > 
> > > At the tests I made here, on both modes, the i2c bus can't have any other
> > > traffic during the firmware load. Otherwise, an invalid firmware will be loaded
> > > and tda10046 will hangup.
> > > 
> > > I've started to implement some locks at saa7134 driver (on my saa7134
> > > experimental tree), but it is not finished yet. I didn't touch at the sleep code yet.
> > > 
> > > > > > 
> > > > > 
> > > > > BTW, just to remember.
> > > > > 
> > > > > Tvtime with signal detection on shows a blue screen without signal.
> > > > > With signal detection off, just good old snow.
> > > 
> > > So, the tda9887 or the PLL are configured wrongly.
> > > 
> > > > > The tda8275/75a shows a black screen without having lock, not even snow,
> > > > > if it should be related.
> > > > 
> > > > Sorry, to add one more about "black" screens :)
> > > > 
> > > > Without the tda9887 loaded, the FMD1216ME MK3 hybrid also shows a black
> > > > screen, but it is slightly different from the fully black screen of the
> > > > tda8275, which is in fact an overlay like the blue screen on tvtime. It
> > > > has some white points visible and on some channels even _very_ decent
> > > > ghosting of TV.
> > > 
> > > Probably, tda9887 is configured for STD/M, instead of STD/BG. Fixing tda9887
> > > will also fix this issue.
> > > 
> > > > The status of the tda9885/6/7 on the TUV1236D is still not clear to me,
> > > > until I see debug enabled on it for switching TV standards and just
> > > > nothing ever changes.
> > > 
> > > Sorry but I didn't understand what you're meaning with your TUV1236D-based device.
> > 
> > Just for that one for now, I'll try on the other subjects later.
> > 
> > I don't have any TUV1236D based device, but CityK and maybe Michael on
> > the Kworld _ATSC_ ! 110/15.
> > 
> > >From the photo provided by CityK, there is clearly a 24pin Philips
> > device within the IF section of this tuner, which I guess is a tda9885
> > NTSC only and nothing else.
> > 
> > As mentioned before, they can be strapped on one pin to be NTSC
> > (System-M) only without needing _any_ i2c programming according to the
> > data sheets.
> > 
> > With the reports so far, after years, either the tda9887 module is just
> > fake loaded, even that fails, or nothing ever happens, or something
> > happens on i2c we don't have clear.
> > 
> > So I would like to see if there is ever valid i2c traffic to that
> > tda988x device on that tuner or never...
> 
> Maybe we don't need any extra programming for tda9885, but it won't hurt to
> reprogram it to the right state. 

Mauro, for the record, it is about chapter 8.16 on page 13 in the
current tda9885/6 datasheet and the voltage delay in that case on page
14. It is the same for tda9887.
http://www.nxp.com/#/pip/pip=[pip=TDA9885_TDA9886_3]|pp=[t=pip,i=TDA9885_TDA9886_3]

Here is a link to the early discussions by Curt and CityK.
http://lists.zerezo.com/video4linux/msg09088.html

This has also the link to the high resolution photograph of the open
tuner. We see a video IF and sound IF SAW filter and can assume it has
OSS sound. No tda7040 radio stereo separator is visible so far.
(on your CTX925 it is too)
http://www.nxp.com/#/pip/pip=[pip=TDA7040T_CNV_2]|pp=[t=pip,i=TDA7040T_CNV_2]

The third SAW filter is for ATSC.

Let's keep in mind, the tda9887 on the md7134 devices with FMD1216ME MK3
hybrid it not loaded and uninitialized after boot and it needs a driver
reload.

Cheers,
Hermann

KWorld ATSC 115 all static

[Josh Borke]

After upgrading to Fedora 10 I am no longer able to tune analog or dvb 
channels using my KWorld ATSC 115. When I try to view a channel with 
tvtime all I can see is static and when I try to scandvb I keep getting 
tuning failed even though I know that there are channels being broadcast 
on the channels scanned. I have tried to find tips on the wiki of how to 
resolve my static problem but I could not find any. I'm not sure where 
to look for clues as to why it isn't working.

I have a 1-to-4 splitter with 2 outputs going to the inputs of the 
KWorld ATSC and another going to a TV so I know there is signal on the 
cable.

Any help would be really appreciated.

Thanks,
-josh

Re: KWorld ATSC 115 all static

[CityK]

Josh Borke wrote:
> After upgrading to Fedora 10 I am no longer able to tune analog or dvb
> channels using my KWorld ATSC 115. When I try to view a channel with
> tvtime all I can see is static and when I try to scandvb I keep
> getting tuning failed even though I know that there are channels being
> broadcast on the channels scanned. I have tried to find tips on the
> wiki of how to resolve my static problem but I could not find any. I'm
> not sure where to look for clues as to why it isn't working.
>
> I have a 1-to-4 splitter with 2 outputs going to the inputs of the
> KWorld ATSC and another going to a TV so I know there is signal on the
> cable.
>
> Any help would be really appreciated.

Hello everyone,

In addition to being a general broadcast message, I have cc'ed  in a
number of folks.

This (broken analog TV on, at the very minimum, the KWorld 110 and 115
cards) is a known problem that has persisted for a long time.  Far too
long now.   I last wrote about it here: 
http://marc.info/?l=linux-video&m=122809741331944&w=2.  No response was
generated from that.  So I will try again and outline what I believe is
the relevant history:

- Mauro, you introduced a regression for these boards in changeset: 
7753:67faa17a5bcb  (http://linuxtv.org/hg/v4l-dvb/rev/67faa17a5bcb). 
Since that commit, analog TV has been broken for these cards.

- Michael commented about this here:
http://marc.info/?l=linux-video&m=121243712021921&w=2

- Mauro responded here: 
http://marc.info/?l=linux-video&m=121243995927725&w=2

- Several users have brought this up since then (both here on the m/l's
and on internet forums) .

- Michael spun a stopgap solution for this (found here
:http://linuxtv.org/~mkrufky/fix-broken-atsc110-analog.patch
<http://linuxtv.org/%7Emkrufky/fix-broken-atsc110-analog.patch> ).  It
still applies cleanly.  Unfortunately, it is not a bonafide solution
because: (a) upon each reboot of the system, the user is required to
first "modprobe tuner -r" and then "modprobe tuner" before the analog
tuning will initialize and function properly.  (b) In addition,
Michael's patch may affect/break other devices, so it can not be
committed to the master repo.

- Hans, I know you have done a lot of clean ups in regards to i2c, but
do not know whether any of your work would have touched upon or have had
any impact here.  Nonetheless, I'd appreciate your input on the matter
too if you are able to comment.

I am hoping that this can be resolved to everyone's satisfaction.  In my
opinion, this should become a priority item, as this regression's life
has spanned over 4 kernels.

[For the sake of full disclosure, I am personally affected by the issue,
but I note that I use Mike's patch each and everyday (thank you Mike!),
and so, other then the minor inconvenience of having to do a modprobe
dance with the tuner module, I am not impacted too much.  Other users,
however, are left in the dark.  And, as I explained in my last message,
those AVS users that I addressed this issue with seemed entirely
hesitant about using the patch (maybe I scared them with a greivious
warning ??).  Anyway, as evidenced by Josh  (OP for this message) and
David (see his recent messages; e.g.
http://marc.info/?l=linux-video&m=123066362106086&w=2), end users
continue to encounter  this problem.  I am only surprised that we
haven't heard more about this issue.  As I noted earlier on, I believe
that its impact is greater then just upon the KWorld 11x cards.]





--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: KWorld ATSC 115 all static

[Mauro Carvalho Chehab]

On Sun, 11 Jan 2009 22:08:14 -0500
CityK <cityk@rogers.com> wrote:

> Josh Borke wrote:
> > After upgrading to Fedora 10 I am no longer able to tune analog or dvb
> > channels using my KWorld ATSC 115. When I try to view a channel with
> > tvtime all I can see is static and when I try to scandvb I keep
> > getting tuning failed even though I know that there are channels being
> > broadcast on the channels scanned. I have tried to find tips on the
> > wiki of how to resolve my static problem but I could not find any. I'm
> > not sure where to look for clues as to why it isn't working.
> >
> > I have a 1-to-4 splitter with 2 outputs going to the inputs of the
> > KWorld ATSC and another going to a TV so I know there is signal on the
> > cable.
> >
> > Any help would be really appreciated.
> 
> Hello everyone,
> 
> In addition to being a general broadcast message, I have cc'ed  in a
> number of folks.
> 
> This (broken analog TV on, at the very minimum, the KWorld 110 and 115
> cards) is a known problem that has persisted for a long time.  Far too
> long now.   I last wrote about it here: 
> http://marc.info/?l=linux-video&m=122809741331944&w=2.  No response was
> generated from that.  So I will try again and outline what I believe is
> the relevant history:
> 
> - Mauro, you introduced a regression for these boards in changeset: 
> 7753:67faa17a5bcb  (http://linuxtv.org/hg/v4l-dvb/rev/67faa17a5bcb). 
> Since that commit, analog TV has been broken for these cards.
> 
> - Michael commented about this here:
> http://marc.info/?l=linux-video&m=121243712021921&w=2
> 
> - Mauro responded here: 
> http://marc.info/?l=linux-video&m=121243995927725&w=2
> 
> - Several users have brought this up since then (both here on the m/l's
> and on internet forums) .
> 
> - Michael spun a stopgap solution for this (found here
> :http://linuxtv.org/~mkrufky/fix-broken-atsc110-analog.patch
> <http://linuxtv.org/%7Emkrufky/fix-broken-atsc110-analog.patch> ).  It
> still applies cleanly.  Unfortunately, it is not a bonafide solution
> because: (a) upon each reboot of the system, the user is required to
> first "modprobe tuner -r" and then "modprobe tuner" before the analog
> tuning will initialize and function properly.  (b) In addition,
> Michael's patch may affect/break other devices, so it can not be
> committed to the master repo.
> 
> - Hans, I know you have done a lot of clean ups in regards to i2c, but
> do not know whether any of your work would have touched upon or have had
> any impact here.  Nonetheless, I'd appreciate your input on the matter
> too if you are able to comment.
> 
> I am hoping that this can be resolved to everyone's satisfaction.  In my
> opinion, this should become a priority item, as this regression's life
> has spanned over 4 kernels.
> 
> [For the sake of full disclosure, I am personally affected by the issue,
> but I note that I use Mike's patch each and everyday (thank you Mike!),
> and so, other then the minor inconvenience of having to do a modprobe
> dance with the tuner module, I am not impacted too much.  Other users,
> however, are left in the dark.  And, as I explained in my last message,
> those AVS users that I addressed this issue with seemed entirely
> hesitant about using the patch (maybe I scared them with a greivious
> warning ??).  Anyway, as evidenced by Josh  (OP for this message) and
> David (see his recent messages; e.g.
> http://marc.info/?l=linux-video&m=123066362106086&w=2), end users
> continue to encounter  this problem.  I am only surprised that we
> haven't heard more about this issue.  As I noted earlier on, I believe
> that its impact is greater then just upon the KWorld 11x cards.]

This issue doesn't have an easy fix. The big problem is that some devices like
Kworld ATSC 115 needs to send some i2c commands before accessing the tuner.
However, depending on the load order, the tuner command can happen before the
right time. This trouble is not exclusive with saa7134. We have similar issues
with cx88 (for example, Kworld ATSC 120 suffers similar troubles).

As you noticed, applying Michael patch will likely break other drivers.

The proper fix is a major saa7134 redesign, by using the newer i2c methods.

The new i2c interfaces allow you to register the i2c bus first, then register
each driver when you want to, and not relying on a code that automatically
registers all i2c video drivers found at a random order.

So, with the new i2c approach, we can warrant that we'll first open the i2c
gate before binding the tuner and/or the demodulator.

Any other approach with the current way will break some other cards or cause
troubles on some situations, like having the driver compiled monolithically
with the kernel or if you have two boards on the machine.

The redesign of saa7134 requires lots of work. It requires to a full
understanding of Hans Verkuil approach used on ivtv. The ivtv driver is
different enough from the other drivers to allow an easy conversion. Also, his
approach changed recently with the introduction of the v4l2 subdevices. Even the
conversion of the cx18 driver (very close to ivtv) to the newer approach
doesn't seem to be that easy, as noticed recently by Andy.

IMO, the better would be if Hans could dedicate some time to convert one
of the drivers that have the more usual approach (saa7134, em28xx, cx88,
bttv) to the new approach. Then the same patch could be easily converted to the
other drivers.

Hans,

Could you help us with this?

Cheers,
Mauro

Re: KWorld ATSC 115 all static

[Hans Verkuil]

On Monday 12 January 2009 06:19:47 Mauro Carvalho Chehab wrote:
> On Sun, 11 Jan 2009 22:08:14 -0500
>
> CityK <cityk@rogers.com> wrote:
> > Josh Borke wrote:
> > > After upgrading to Fedora 10 I am no longer able to tune analog
> > > or dvb channels using my KWorld ATSC 115. When I try to view a
> > > channel with tvtime all I can see is static and when I try to
> > > scandvb I keep getting tuning failed even though I know that
> > > there are channels being broadcast on the channels scanned. I
> > > have tried to find tips on the wiki of how to resolve my static
> > > problem but I could not find any. I'm not sure where to look for
> > > clues as to why it isn't working.
> > >
> > > I have a 1-to-4 splitter with 2 outputs going to the inputs of
> > > the KWorld ATSC and another going to a TV so I know there is
> > > signal on the cable.
> > >
> > > Any help would be really appreciated.
> >
> > Hello everyone,
> >
> > In addition to being a general broadcast message, I have cc'ed  in
> > a number of folks.
> >
> > This (broken analog TV on, at the very minimum, the KWorld 110 and
> > 115 cards) is a known problem that has persisted for a long time. 
> > Far too long now.   I last wrote about it here:
> > http://marc.info/?l=linux-video&m=122809741331944&w=2.  No response
> > was generated from that.  So I will try again and outline what I
> > believe is the relevant history:
> >
> > - Mauro, you introduced a regression for these boards in changeset:
> > 7753:67faa17a5bcb 
> > (http://linuxtv.org/hg/v4l-dvb/rev/67faa17a5bcb). Since that
> > commit, analog TV has been broken for these cards.
> >
> > - Michael commented about this here:
> > http://marc.info/?l=linux-video&m=121243712021921&w=2
> >
> > - Mauro responded here:
> > http://marc.info/?l=linux-video&m=121243995927725&w=2
> >
> > - Several users have brought this up since then (both here on the
> > m/l's and on internet forums) .
> >
> > - Michael spun a stopgap solution for this (found here
> >
> > :http://linuxtv.org/~mkrufky/fix-broken-atsc110-analog.patch
> >
> > <http://linuxtv.org/%7Emkrufky/fix-broken-atsc110-analog.patch> ). 
> > It still applies cleanly.  Unfortunately, it is not a bonafide
> > solution because: (a) upon each reboot of the system, the user is
> > required to first "modprobe tuner -r" and then "modprobe tuner"
> > before the analog tuning will initialize and function properly. 
> > (b) In addition, Michael's patch may affect/break other devices, so
> > it can not be committed to the master repo.
> >
> > - Hans, I know you have done a lot of clean ups in regards to i2c,
> > but do not know whether any of your work would have touched upon or
> > have had any impact here.  Nonetheless, I'd appreciate your input
> > on the matter too if you are able to comment.
> >
> > I am hoping that this can be resolved to everyone's satisfaction. 
> > In my opinion, this should become a priority item, as this
> > regression's life has spanned over 4 kernels.
> >
> > [For the sake of full disclosure, I am personally affected by the
> > issue, but I note that I use Mike's patch each and everyday (thank
> > you Mike!), and so, other then the minor inconvenience of having to
> > do a modprobe dance with the tuner module, I am not impacted too
> > much.  Other users, however, are left in the dark.  And, as I
> > explained in my last message, those AVS users that I addressed this
> > issue with seemed entirely hesitant about using the patch (maybe I
> > scared them with a greivious warning ??).  Anyway, as evidenced by
> > Josh  (OP for this message) and David (see his recent messages;
> > e.g.
> > http://marc.info/?l=linux-video&m=123066362106086&w=2), end users
> > continue to encounter  this problem.  I am only surprised that we
> > haven't heard more about this issue.  As I noted earlier on, I
> > believe that its impact is greater then just upon the KWorld 11x
> > cards.]
>
> This issue doesn't have an easy fix. The big problem is that some
> devices like Kworld ATSC 115 needs to send some i2c commands before
> accessing the tuner. However, depending on the load order, the tuner
> command can happen before the right time. This trouble is not
> exclusive with saa7134. We have similar issues with cx88 (for
> example, Kworld ATSC 120 suffers similar troubles).
>
> As you noticed, applying Michael patch will likely break other
> drivers.
>
> The proper fix is a major saa7134 redesign, by using the newer i2c
> methods.
>
> The new i2c interfaces allow you to register the i2c bus first, then
> register each driver when you want to, and not relying on a code that
> automatically registers all i2c video drivers found at a random
> order.
>
> So, with the new i2c approach, we can warrant that we'll first open
> the i2c gate before binding the tuner and/or the demodulator.
>
> Any other approach with the current way will break some other cards
> or cause troubles on some situations, like having the driver compiled
> monolithically with the kernel or if you have two boards on the
> machine.
>
> The redesign of saa7134 requires lots of work. It requires to a full
> understanding of Hans Verkuil approach used on ivtv. The ivtv driver
> is different enough from the other drivers to allow an easy
> conversion. Also, his approach changed recently with the introduction
> of the v4l2 subdevices. Even the conversion of the cx18 driver (very
> close to ivtv) to the newer approach doesn't seem to be that easy, as
> noticed recently by Andy.
>
> IMO, the better would be if Hans could dedicate some time to convert
> one of the drivers that have the more usual approach (saa7134,
> em28xx, cx88, bttv) to the new approach. Then the same patch could be
> easily converted to the other drivers.
>
> Hans,
>
> Could you help us with this?

Yes, I can. I'll do saa7134 since I have an empress card anyway. It 
should be quite easy (the cx18 complication is not an issue here).

Regards,

	Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: KWorld ATSC 115 all static

[CityK]

Hans Verkuil wrote:
> Yes, I can. I'll do saa7134 since I have an empress card anyway. It 
> should be quite easy (the cx18 complication is not an issue here).
>
> Regards,
>
> 	Hans

Thanks Hans!

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: KWorld ATSC 115 all static

[hermann pitton]

Hi,

Am Montag, den 12.01.2009, 21:10 -0500 schrieb CityK:
> Hans Verkuil wrote:
> > Yes, I can. I'll do saa7134 since I have an empress card anyway. It 
> > should be quite easy (the cx18 complication is not an issue here).
> >
> > Regards,
> >
> > 	Hans
> 
> Thanks Hans!
> 

yes, Hans is a very fine guy.

But don't hope for too much for DVB/ATSC related stuff soon.

We know about the problems caused by switching antenna inputs from a
digital demod, it was a famous hack from Chris on cx88xx and Mike did
good work to port it to saa713x, but unfortunately there was some
ongoing loss on the other side of the planet then later.

I doubt that Hans is already aware of it at this stage, but since these
days bugs are fixed from guys without even having hardware, and this is
good progress, likely they will add new devices the same way too soon.
I seem to be far behind currently, all caused by the HDTV hype ;)

Cheers,
Hermann











--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: KWorld ATSC 115 all static

[CityK]

hermann pitton wrote:
> Hi,
>
> Am Montag, den 12.01.2009, 21:10 -0500 schrieb CityK:
>   
>> Hans Verkuil wrote:
>>     
>>> Yes, I can. I'll do saa7134 since I have an empress card anyway. It 
>>> should be quite easy (the cx18 complication is not an issue here).
>>>
>>> Regards,
>>>
>>> 	Hans
>>>       
>> Thanks Hans!
>>
>>     
>
> yes, Hans is a very fine guy.
>   

He is indeed.

> But don't hope for too much for DVB/ATSC related stuff soon.
>
> We know about the problems caused by switching antenna inputs from a
> digital demod, it was a famous hack from Chris on cx88xx and Mike did
> good work to port it to saa713x, but unfortunately there was some
> ongoing loss on the other side of the planet then later.
>
> I doubt that Hans is already aware of it at this stage, 

Consulting on irc, both Eric and myself can confirm that DVB is working
fine for the device (I can only test cable currently, but Eric
successfully checked both QAM and 8-VSB).  I'm using recent Hg and Eric
is using stock FC10 supplied drivers.  So, I'm not sure why Josh was
having problems.

> these days bugs are fixed from guys without even having hardware, 
Four letter word.  Starts with A and ends with Y  :p

> and this is good progress,
Yes, it was awfully nice of Andy to diagnose and provide a solution. 
Props to him.

>  likely they will add new devices the same way too soon.
>   

This point, however, is not a very good route to go down --- it opens up
a huge can of worms (<-- silly English expression which essentially
means that such action creates problems).
 
> I seem to be far behind currently, all caused by the HDTV hype ;)
>   

You mean you haven't upgraded to the latest 92 inch hyper plasma OXD
display yet!    Crappy broadcast content has never looked so good!

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: KWorld ATSC 115 all static

[Hans Verkuil]

On Wednesday 14 January 2009 05:41:26 CityK wrote:
> hermann pitton wrote:
> > Hi,
> >
> > Am Montag, den 12.01.2009, 21:10 -0500 schrieb CityK:
> >> Hans Verkuil wrote:
> >>> Yes, I can. I'll do saa7134 since I have an empress card anyway.
> >>> It should be quite easy (the cx18 complication is not an issue
> >>> here).
> >>>
> >>> Regards,
> >>>
> >>> 	Hans
> >>
> >> Thanks Hans!
> >
> > yes, Hans is a very fine guy.
>
> He is indeed.

Absolutely! :-)

FYI: I have a patch, but I won't have time to test it until Friday. You 
should get something from me then. The main change was actually to the 
saa6752hs.c i2c module (it wasn't yet converted to v4l2_subdev), and I 
need to test that first with my empress card.

Regards,

	Hans

> > But don't hope for too much for DVB/ATSC related stuff soon.
> >
> > We know about the problems caused by switching antenna inputs from
> > a digital demod, it was a famous hack from Chris on cx88xx and Mike
> > did good work to port it to saa713x, but unfortunately there was
> > some ongoing loss on the other side of the planet then later.
> >
> > I doubt that Hans is already aware of it at this stage,
>
> Consulting on irc, both Eric and myself can confirm that DVB is
> working fine for the device (I can only test cable currently, but
> Eric successfully checked both QAM and 8-VSB).  I'm using recent Hg
> and Eric is using stock FC10 supplied drivers.  So, I'm not sure why
> Josh was having problems.
>
> > these days bugs are fixed from guys without even having hardware,
>
> Four letter word.  Starts with A and ends with Y  :p
>
> > and this is good progress,
>
> Yes, it was awfully nice of Andy to diagnose and provide a solution.
> Props to him.
>
> >  likely they will add new devices the same way too soon.
>
> This point, however, is not a very good route to go down --- it opens
> up a huge can of worms (<-- silly English expression which
> essentially means that such action creates problems).
>
> > I seem to be far behind currently, all caused by the HDTV hype ;)
>
> You mean you haven't upgraded to the latest 92 inch hyper plasma OXD
> display yet!    Crappy broadcast content has never looked so good!



-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

Re: KWorld ATSC 115 all static

[Hans Verkuil]

On Wednesday 14 January 2009 08:37:43 Hans Verkuil wrote:
> On Wednesday 14 January 2009 05:41:26 CityK wrote:
> > hermann pitton wrote:
> > > Hi,
> > >
> > > Am Montag, den 12.01.2009, 21:10 -0500 schrieb CityK:
> > >> Hans Verkuil wrote:
> > >>> Yes, I can. I'll do saa7134 since I have an empress card
> > >>> anyway. It should be quite easy (the cx18 complication is not
> > >>> an issue here).
> > >>>
> > >>> Regards,
> > >>>
> > >>> 	Hans
> > >>
> > >> Thanks Hans!
> > >
> > > yes, Hans is a very fine guy.
> >
> > He is indeed.
>
> Absolutely! :-)
>
> FYI: I have a patch, but I won't have time to test it until Friday.
> You should get something from me then. The main change was actually
> to the saa6752hs.c i2c module (it wasn't yet converted to
> v4l2_subdev), and I need to test that first with my empress card.

OK, I couldn't help myself and went ahead and tested it. It seems fine, 
so please test my tree: 

http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-saa7134

Let me know if it works. If it does, then I'll ask Mauro to pull from my 
tree.

Thanks,

	Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: KWorld ATSC 115 all static

[hermann pitton]

Am Mittwoch, den 14.01.2009, 19:24 +0100 schrieb Hans Verkuil:
> On Wednesday 14 January 2009 08:37:43 Hans Verkuil wrote:
> > On Wednesday 14 January 2009 05:41:26 CityK wrote:
> > > hermann pitton wrote:
> > > > Hi,
> > > >
> > > > Am Montag, den 12.01.2009, 21:10 -0500 schrieb CityK:
> > > >> Hans Verkuil wrote:
> > > >>> Yes, I can. I'll do saa7134 since I have an empress card
> > > >>> anyway. It should be quite easy (the cx18 complication is not
> > > >>> an issue here).
> > > >>>
> > > >>> Regards,
> > > >>>
> > > >>> 	Hans
> > > >>
> > > >> Thanks Hans!
> > > >
> > > > yes, Hans is a very fine guy.
> > >
> > > He is indeed.
> >
> > Absolutely! :-)
> >
> > FYI: I have a patch, but I won't have time to test it until Friday.
> > You should get something from me then. The main change was actually
> > to the saa6752hs.c i2c module (it wasn't yet converted to
> > v4l2_subdev), and I need to test that first with my empress card.
> 
> OK, I couldn't help myself and went ahead and tested it. It seems fine, 
> so please test my tree: 
> 
> http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-saa7134
> 
> Let me know if it works. If it does, then I'll ask Mauro to pull from my 
> tree.

Just found your email a few hours back after a PC and internet free day,
but so far all seems to be fine and no new issues are visible. DVB-T and
DVB-S are OK too.

Just for the record, we still have the issue on FMD1216ME MK3 hybrid
tuners that the tda9887 is not loaded on boot. This still needs user
intervention.

Thanks!

Cheers,
Hermann

Re: KWorld ATSC 115 all static

[CityK]

Hans Verkuil wrote:
> OK, I couldn't help myself and went ahead and tested it. It seems fine, 
> so please test my tree: 
>
> http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-saa7134
>
> Let me know if it works. 

Hi Hans,

It didn't work.  No analog reception on either RF input.  (as Mauro
noted, DVB is unaffected; it still works).

dmesg output looks right:

tuner-simple 1-0061: creating new instance
tuner-simple 1-0061: type set to 68 (Philips TUV1236D ATSC/NTSC dual in)

I tried backing out of the modules and then reloading them, but no
change.  (including after fresh build or after rebooting)

Re: KWorld ATSC 115 all static

[Hans Verkuil]

On Thursday 15 January 2009 06:01:28 CityK wrote:
> Hans Verkuil wrote:
> > OK, I couldn't help myself and went ahead and tested it. It seems
> > fine, so please test my tree:
> >
> > http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-saa7134
> >
> > Let me know if it works.
>
> Hi Hans,
>
> It didn't work.  No analog reception on either RF input.  (as Mauro
> noted, DVB is unaffected; it still works).
>
> dmesg output looks right:
>
> tuner-simple 1-0061: creating new instance
> tuner-simple 1-0061: type set to 68 (Philips TUV1236D ATSC/NTSC dual
> in)
>
> I tried backing out of the modules and then reloading them, but no
> change.  (including after fresh build or after rebooting)

Can you give the full dmesg output? Also, is your board suppossed to 
have a tda9887 as well?

Regards,

	Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

Re: KWorld ATSC 115 all static

[Michael Krufky]

Hans Verkuil wrote:
> On Thursday 15 January 2009 06:01:28 CityK wrote:
>   
>> Hans Verkuil wrote:
>>     
>>> OK, I couldn't help myself and went ahead and tested it. It seems
>>> fine, so please test my tree:
>>>
>>> http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-saa7134
>>>
>>> Let me know if it works.
>>>       
>> Hi Hans,
>>
>> It didn't work.  No analog reception on either RF input.  (as Mauro
>> noted, DVB is unaffected; it still works).
>>
>> dmesg output looks right:
>>
>> tuner-simple 1-0061: creating new instance
>> tuner-simple 1-0061: type set to 68 (Philips TUV1236D ATSC/NTSC dual
>> in)
>>
>> I tried backing out of the modules and then reloading them, but no
>> change.  (including after fresh build or after rebooting)
>>     
>
> Can you give the full dmesg output? Also, is your board suppossed to 
> have a tda9887 as well?
>   

Hans' changes are not enough to fix the ATSC115 issue.

I believe that if you can confirm that the same problem exists, but the 
previous workaround continues to work even after Hans' changes, then I 
believe that confirms that Hans' changes Do the Right Thing (tm).

ATSC115 is broken not because the tuner type assignment has been removed 
from attach_inform.

This is actually a huge problem across all analog drivers now, since we 
are no longer able to remove the "tuner" module and modprobe it again -- 
the second modprobe will not allow for an attach, as there will be no 
way for the module to be recognized without having the glue code needed 
inside attach_inform...

...unless somebody has a suggestion?

Anyway, if the previous workaround works after Hans' changes, then I 
think his changes should be merged -- even though it doesnt fix ATSC115, 
it is indeed a step into the right direction.

If the ATSC115 hack-fix patch doesn't apply anymore, please let me know 
-- I'll respin it.

Regards,

Mike Krufky

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: KWorld ATSC 115 all static

[hermann pitton]

Hi,

Am Dienstag, den 13.01.2009, 23:41 -0500 schrieb CityK:
> hermann pitton wrote:
> > Hi,
> >
> > Am Montag, den 12.01.2009, 21:10 -0500 schrieb CityK:
> >   
> >> Hans Verkuil wrote:
> >>     
> >>> Yes, I can. I'll do saa7134 since I have an empress card anyway. It 
> >>> should be quite easy (the cx18 complication is not an issue here).
> >>>
> >>> Regards,
> >>>
> >>> 	Hans
> >>>       
> >> Thanks Hans!
> >>
> >>     
> >
> > yes, Hans is a very fine guy.
> >   
> 
> He is indeed.
> 
> > But don't hope for too much for DVB/ATSC related stuff soon.
> >
> > We know about the problems caused by switching antenna inputs from a
> > digital demod, it was a famous hack from Chris on cx88xx and Mike did
> > good work to port it to saa713x, but unfortunately there was some
> > ongoing loss on the other side of the planet then later.
> >
> > I doubt that Hans is already aware of it at this stage, 
> 
> Consulting on irc, both Eric and myself can confirm that DVB is working
> fine for the device (I can only test cable currently, but Eric
> successfully checked both QAM and 8-VSB).  I'm using recent Hg and Eric
> is using stock FC10 supplied drivers.  So, I'm not sure why Josh was
> having problems.

for me the same and I can't test on these.
The Pinnacle 310i seems to have the LNA support broken, can't test.

> > these days bugs are fixed from guys without even having hardware, 
> Four letter word.  Starts with A and ends with Y  :p
> 
> > and this is good progress,
> Yes, it was awfully nice of Andy to diagnose and provide a solution. 
> Props to him.

Yes!

> >  likely they will add new devices the same way too soon.
> >   
> 
> This point, however, is not a very good route to go down --- it opens up
> a huge can of worms (<-- silly English expression which essentially
> means that such action creates problems).

If manufacturers would confirm to the Philips/NXP drivers and what
should be in the eeprom, that would be possible on GNU/Linux too.

> > I seem to be far behind currently, all caused by the HDTV hype ;)
> >   
> 
> You mean you haven't upgraded to the latest 92 inch hyper plasma OXD
> display yet!    Crappy broadcast content has never looked so good!

No, trying on HDTV apps and also Nvidia vdpau consumed some time and I
don't have neither a 2.6.28 nor a 2.6.29-rc1 yet.

In that way I might be ranting about myself not at least to have the new
bugs :)

Cheers,
Hermann

Re: KWorld ATSC 115 all static

[Mauro Carvalho Chehab]

On Thu, 15 Jan 2009 03:32:41 +0100
hermann pitton <hermann-pitton@arcor.de> wrote:

> > Consulting on irc, both Eric and myself can confirm that DVB is working
> > fine for the device (I can only test cable currently, but Eric
> > successfully checked both QAM and 8-VSB).  I'm using recent Hg and Eric
> > is using stock FC10 supplied drivers.  So, I'm not sure why Josh was
> > having problems.  
> 
> for me the same and I can't test on these.
> The Pinnacle 310i seems to have the LNA support broken, can't test.

Hermann,

The DVB part shouldn't be affected by the patch. It changes the way that tuners
are attached at the analog part. So, the tests should be on tea5767 radio and
on analog tuner reception.

Also, his patch just changes the way tuner is binding. Manual adjustments on
saa7134 cards structs (like adding TDA9887_PRESENT flag) will be needed to fix some
issues like what you've reported (driver not loading automatically tda9887
driver).

Cheers,
Mauro

Re: KWorld ATSC 115 all static

[hermann pitton]

Am Donnerstag, den 15.01.2009, 00:54 -0200 schrieb Mauro Carvalho
Chehab:
> On Thu, 15 Jan 2009 03:32:41 +0100
> hermann pitton <hermann-pitton@arcor.de> wrote:
> 
> > > Consulting on irc, both Eric and myself can confirm that DVB is working
> > > fine for the device (I can only test cable currently, but Eric
> > > successfully checked both QAM and 8-VSB).  I'm using recent Hg and Eric
> > > is using stock FC10 supplied drivers.  So, I'm not sure why Josh was
> > > having problems.  
> > 
> > for me the same and I can't test on these.
> > The Pinnacle 310i seems to have the LNA support broken, can't test.
> 
> Hermann,
> 
> The DVB part shouldn't be affected by the patch. It changes the way that tuners
> are attached at the analog part. So, the tests should be on tea5767 radio and
> on analog tuner reception.
> 
> Also, his patch just changes the way tuner is binding. Manual adjustments on
> saa7134 cards structs (like adding TDA9887_PRESENT flag) will be needed to fix some
> issues like what you've reported (driver not loading automatically tda9887
> driver).

It won't fix the antenna input selection controlled from the digital
demod, as told before.

Cheers,
Hermann

Re: KWorld ATSC 115 all static

[CityK]

Josh Borke wrote:
> After upgrading to Fedora 10 I am no longer able to tune analog or dvb
> channels using my KWorld ATSC 115. When I try to view a channel with
> tvtime all I can see is static and when I try to scandvb I keep
> getting tuning failed even though I know that there are channels being
> broadcast on the channels scanned. I have tried to find tips on the
> wiki of how to resolve my static problem but I could not find any. I'm
> not sure where to look for clues as to why it isn't working.
>
> I have a 1-to-4 splitter with 2 outputs going to the inputs of the
> KWorld ATSC and another going to a TV so I know there is signal on the
> cable.
>
> Any help would be really appreciated.

Josh,

The analog issue was obviously addressed in my last message.

Now, in regards to the DVB handling -- there have been a number of
recent Fedora 10 related problems being reported on the lists, and you
may happen to fall within that category.  I'd suggest having a look at
your dmesg output to see if there is any error being reported.  Saving
that -- search the lists in regard to the recent rash of Fedora
problems.  And finally, try switching the RF input on which you attempt
to obtain a digital signal.