Re: [PATCH v3 00/34] dmaengine: migrate channel tasklets to WQ_BH

[Allen]

> > This series moves DMAengine client completion bottom halves from private
> > tasklets to a common per-channel API backed by WQ_BH.
> >
> > The first patch introduces the dmaengine_*_bh() API with a tasklet backend
> > and converts virt-dma to it. It also updates every driver that directly
> > accesses the removed virt_dma_chan tasklet, keeping the patch buildable on
> > its own. This separates the driver-facing API from its implementation
> > without changing callback context.
> >
> > The second patch switches that backend to a dedicated WQ_BH | WQ_PERCPU
> > workqueue. WQ_BH keeps callbacks in softirq context, while the common API
> > centralizes initialization, scheduling, and synchronization. The
> > workqueue helpers remain internal to DMAengine, and dmaengine_kill_bh()
> > drains scheduled callbacks to preserve tasklet_kill() semantics.
> >
> > The remaining patches convert driver-owned channel completion tasklets.
> > Tasklets used for controller-level processing, recovery, or other
> > non-client-callback work are deliberately left alone because the
> > appropriate replacement may differ by driver.
>
> Right, I would actually expect that virt-dma (and others will follow the
> example) will switch to threaded IRQ instead of tasklets.

Thanks, Andy.

  I had not considered a full virt-dma conversion for this series. Looking
  at the driver, that would also involve its descriptor pool, queue and
  active lists, software LLP and cyclic handling, and residue reporting. It
  would therefore be a substantially broader change than moving callback
  delivery to the common channel BH.

  My intention here was to leave the existing descriptor lifecycle and
  scheduling unchanged and only move callback invocation out of the
  controller tasklet. I think converting the driver to virt-dma would be
  better handled as a separate series with hardware testing.

  If you would prefer not to add the completed list ahead of such a
  conversion, I can drop this patch from the current series and leave the
  DW driver unchanged for now.

  Regards,
  Allen


>
> > As agreed in the RFC discussion, selecting hardirq callback delivery is a
> > separate API change and is not part of this series.
>
> --
> With Best Regards,
> Andy Shevchenko
>
>


-- 
       - Allen