Hi Norman
I've been testing the USB driver in the RaspberryPI assigning priorities to each processes, but continue losing events. I have also tried changing the top value of cnt, but still the same result. I will continue doing some independent tests of the driver, mouse, keyboard and network independently. If you have any other suggestions?
Best regards
Hi Reinier,
I have checked the kernel warning about USB's irq, using base_hw and base_foc, and have noted (per 8000 need_trigger_sof calls): (base_hw) - kicked 5, filtered aproximatelly 7600 and triggered aproximatelly 250 IRQs (base_foc) - kicked 3, filtered aproximatelly 7700 and triggered aproximatelly 140 IRQs There is a big difference in the triggered and filtered irqs. Any idea or suggestion??
SOF interrupts are filtered unless the USB driver explicitly calls 'schedule_sof_interrupt' and thereby propagates the next frame-to-deliver via the GUID scratch register to the kernel. If, for some reason, the USB driver is not scheduled timely enough, it might miss the scheduling of a frame. This can happen if the USB driver runs concurrently with another program that consumes a lot of CPU time. In such a scenario, the scheduling of the USB driver depends on the scheduler of the kernel. Since Fiasco.OC has a different scheduler than base-hw, the effect ultimately depends on the kernel. One way to work around it is to run the USB driver at a high priority. I.e., by assigning a priority of "-1" to all components except for the USB and timer drivers. For an example of how to use priorities in Genode, please have a look at the gems/run/wm.run script. Look out for the 'prio_levels' and 'priority' attributes.
Note that this is just a guess. If the effect also occurs when not running a CPU hungry program besides the USB driver, the guess is most likely wrong.
I don't understand the use of cnt variable (need_trigger_sof). Why use 160 as counter top??
This mechanism ensures that an interrupt is delivered every now and then
- even if the USB driver has not scheduled a frame. There are 8000 IRQs
coming in per second. With the value of 160, an interrupt is forwarded to the USB driver every 20 milliseconds, which appeared to me as a low-enough rate to have a negligible effect on the system's performance.
I'm waiting fix this problem to upload the patch to GitHub. I have tested the USB driver using two versions of Fiasco.OC, the default Fiasco.OC version (https://github.com/ssumpf/foc.git) and a more recently version (https://github.com/skalk/foc.git), but have the same problem.
Furthermore I have tested succesfully the support of Genode with Fiasco.OC as microkernel for RaspberryPI using the autopilot tests: (util_mmio,ldso,timer,lwip,rm_fault,rom_blk,tar_rom,noux,libc_ffat,libc_vfs,timed_semaphore,signal,sub_rm,python,thread_join,failsafe,noux_tool_chain_auto, seoul-auto,resource_request,xml_generator,blk_cache,rump_ext2,thread,pthread, netperf_lwip, netperf_lwip_usb30, netperf_lwip_bridge, netperf_lxip, netperf_lxip_usb30, netperf_lxip_bridge) Now I'm trying to test l4linux and other more complex examples.