You may need to add printk statements to log to dmesg which stages are actually reached…this is tedious, but will show you exactly which part of your code is not executing…or that it is executing and not doing what is expected. Map out progression through the driver this way.
The basic difference between threaded and non-threaded is that threaded uses the kernel “kthread” mechanism to service that portion of the driver…this can migrate to different cores like any other thread and becomes managed by the scheduler (thread priorities can be manipulated or given CPU affinity to a particular core). This would typically be desirable for all portions of the driver which do not mandate disabling interrupts…only CPU0 can be used for direct hardware servicing, it’s wise to migrate other parts of the driver to other cores…this is a “good thing” with threaded (you need hard wires to CPU0 for I/O with the device, but processing data from the I/O already completed can go to any CPU…all hardware competes for CPU0). There is the basis of why you will see far more CPU0 interrupts in “/proc/interrupts” versus other cores.
Note that if you are trying to run driver code when interrupts are disabled by another section of code you won’t get what you want (threaded does not disable interrupts, non-threaded does).