if the firmware only needs to be written once and never "disappears" afterwards, then yes.
But why then the test for a microcontroller reset?
The registers 0x94/0x95 could be used as marker for already running firmware -> Datasheet cx24116
For this driver needs just one fw. So, there's no need to load it again, once it's done.
Apologies for the delay in responding re the firmware patch. Unfortunately it does not work and the firmware never gets loaded. It also has an unfortunate side effect of causing some sort of race condition in the kernel:
[ 9.748915] cx88_dvb: cx2388x dvb driver version 1.0.0 loaded
[ 9.758082] cx8802: registering cx8802 driver, type: dvb access: shared
[ 9.811086] cx8800: registered device video0 [v4l2]
[ 9.830324] ==================================================================
[ 9.834653] BUG: KCSAN: data-race in mutex_spin_on_owner+0x56/0x110
[ 9.843218] race at unknown origin, with read to 0xffff95be81830d74 of 4 bytes by task 523 on cpu 0:
[ 9.847558] mutex_spin_on_owner+0x56/0x110
[ 9.851869] __mutex_lock.constprop.0+0x105/0x800
[ 9.856141] __mutex_lock_slowpath+0xf/0x10
[ 9.858619] cx8802: subsystem: 0070:6902, board: Hauppauge WinTV-HVR4000 DVB-S/S2/T/Hybrid [card=68]
[ 9.860388] mutex_lock+0x93/0xa0
[ 9.874595] kernfs_dop_revalidate+0x4e/0x170
[ 9.878950] lookup_fast+0x18e/0x250
[ 9.883243] walk_component+0x52/0x290
[ 9.887488] path_lookupat+0xcd/0x350
[ 9.891747] filename_lookup+0x121/0x2b0
[ 9.895947] user_path_at_empty+0x6d/0x90
[ 9.900131] do_readlinkat+0x6c/0x190
[ 9.904210] __x64_sys_readlink+0x42/0x50
[ 9.908270] do_syscall_64+0x3a/0x90
[ 9.912328] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 9.920452] Reported by Kernel Concurrency Sanitizer on:
[ 9.924475] CPU: 0 PID: 523 Comm: udevd Not tainted 5.11.6-Build #1
[ 9.928562] Hardware name: System manufacturer System Product Name/P5KPL-CM, BIOS 0512 05/19/2008
[ 9.932490] ==================================================================
Hmm, removing the patch still leaves me with KCSAN reports in dmesg so that may be a red herring.
Notwithstanding that the patch still does not work, i.e. no firmware is loaded.
On which driver base you are building the modules?
The messages in your very first post
and from today look a little different
I am using stock 5.11.6. This is the Kernel version that has worked consistently with the card now that the channels.conf entry has been corrected. I'll stich with this for now as I know it works, unless you suggest otherwise.
if it worked with this kernel drivers before, then there is no need to change it.
It rather seems, that my patch prohibits the firmware loading completely.
Try wirbels suggestion from post #21 and comment out the single line. The Firmware should then be loaded once on first frontend access.
I tried Wirbels suggestion and the firmware was loaded once as expected, but no picture.
I have noticed that when things work the firmware appears to be loaded twice in quick succession on first frontend access, and then once only each time I switch back to the satellite frontend. The following dmesg is from starting VDR and selecting the satellite channel and then shutting down immediately. The driver seems to reload the firmware within a second of the first load. I dont know if this throws any more light on whats going on.
root@Nutrigrain:/home/digitalTV# dmesg | grep "cx24116"
[29257.040177] cx24116_firmware_ondemand: Waiting for firmware upload (dvb-fe-cx24116.fw)...
[29257.068106] cx24116_firmware_ondemand: Waiting for firmware upload(2)...
[29262.364806] cx24116_load_firmware: FW version 220.127.116.11
[29262.364833] cx24116_firmware_ondemand: Firmware upload complete
[29263.564171] cx24116_firmware_ondemand: Waiting for firmware upload (dvb-fe-cx24116.fw)...
[29263.564348] cx24116_firmware_ondemand: Waiting for firmware upload(2)...
[29268.826493] cx24116_load_firmware: FW version 18.104.22.168
[29268.826521] cx24116_firmware_ondemand: Firmware upload complete
I must say that I appreciate your perseverance in getting to the bottom of this but it is not a problem for me as my system now does what I want it to do. Waiting for 5 seconds when switching to a satellite channel is not a concern for me and i'm happy with the way things are. That said, i'm happy to work with you to get to the bottom of this if you so desire.
so, probably some command to fw is needed if switching delsys, but not implemented in driver.
it is a little difficult to understand this firmware loading.
To decide whether the external firmware has to be loaded, register 0x20 is checked for a value > 0. The description of bit 1 if it is set: "Microcontroller has been reset by an abnormal event".
Maybe this means also, that a factory default firmware is loaded through this reset (and thus, a previously loaded external firmware is replaced). If so, the ondemand firmware loading would have a reason.
To find out whether it is really possible to do it without additional firmware uploads would requires more tests, but there is no guarantee that it will work at all.
Since you can live with the short delay when changing frontends, this is probably the best way for now.
OK, I'm happy with that.