On 08/31/16 17:44, Tejun Heo wrote: > Hello, Peter. > > On Wed, Aug 31, 2016 at 02:56:50PM +0300, Peter Ujfalusi wrote: >> On 08/30/16 21:27, Bhaktipriya Shridhar wrote: >>> The workqueue "dac33_wq" queues a single work item &dac33->work and hence >>> doesn't require ordering. Also, it is not being used on a memory reclaim >>> path. Hence, it has been converted to use system_wq. >>> >>> The work item has been flushed in dac33_soc_remove to ensure that >>> there are no pending tasks while disconnecting the driver. >> >> The reason why dac33 had it's own wq is that it is absolutely time critical >> that the work is not going to be delayed by the scheduling needs with the >> system_wq. If the work execution is delayed, we could run out of time in FIFO >> mode, which can cause the chip to hang do to FIFO underrun. > > In the current implementation of wq, which has been around for many > years now, there's no real timing advantage to using a dedicated > workqueue or rather system_wq doesn't get blocked by other work items > on it. They are all served by the same backend pools and dedicated > workqueues mostly serve as attribute, flush and mem-reclaim domains. The dac33 driver was productised with 2.6.32 kernel and there the dedicated wq was needed. I know lots have changed, so it is most likely not the case anymore. >> Unfortunately I'm no longer able to test the dac33 as I don't have the HW any >> more. >> >> If you are 100% percent sure that this is not going to delay the work, then >> I'm OK with the change, but I have used the dedicated queue at the time, >> because the system_wq given unpredictable latencies. > > What kind of time frame are we talking about? If it really needs high > priority, the right thing to do would be using a WQ_HIGHPRI workqueue. In order to be tune the performance and power saving during audio playback lower is better, but consistency matters more to be able have stable system. I have some latency compensation in the code so it could tolerate some drift, but big spikes can cause the codec to go underflow and we can not recover from that w/o hard reset of the codec. I do believe that Linux got much better over the years since I wrote the dac33 driver, so I'm fine with the move to system_wq. The most problematic mode (I think it was MODE7LP or smthing) is not upstream so this change should not break audio on the n9/n950. -- Péter _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
