I'll be away some time.
Here is something that I know from the alpha Mantis version:
If you insert a longer sleep in the end of cu1216_set_parameters(),
the initial lock might be taken before DMA transfer initiation.
This does not seem to work always though? Maybe the exact good sleep
time depends on QAM setting or something. Maybe DVB-C needs a bit
different timings.
I liked about a smart poll: wait within cu1216_set_parameters() until
you have a lock.
Seems to have no unnecessary delays. Of course the same could be done
in dvb_core also. Would be better to do it there so that all drivers
would benefit.
Inversion heuristics in cu1216_set_parameters() is just unnecessary:
dvb_core seems to have a such heuristics already.
Regards,
Marko Ristola
Manu Abraham kirjoitti:
Hello Marko,
Marko Ristola wrote:
I didn't read emails for a few days.
I don't have any specs for the hardware either.
I'll try to figure out that what is the problem.
I think that when the DMA transfer starts, cu1216_set_parameters()
should not be called at all.
The drivers should just keep on with the data transfer.
One possible fix might be that cu1216_set_parameters()
would set the fixed values: they should not be changed during the data
transfer.
Maybe reading other similar drivers help with this.
The other thing is that is it a bug or okay when the cu1216 is
nonresponsive during the data transfer.
Manu, How is this supposed to work?
Sorry i had been away the past few days. In fact dvb-core should start
DMA only after there is a LOCK. I faced this issue (getting garbage in
the DMA queue, before there is a valid LOCK), but i was able to get a
LOCK, but that was with a DVB-S card, but the same bridge.
Need to check a bit as to what's the exact issue in there.
Regards,
Manu
_______________________________________________
linux-dvb mailing list
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
