Re: WARN_ON(irqs_disabled()) in dma_free_attrs?

2018-03-03 Thread Fredrik Noring
Christoph, Alan, > If it is allocating / freeing this memory all the time in the hot path > it should really use a dma pool (see include/ilinux/dmapool.h). > The dma coherent APIs aren't really built for being called in the > hot path. hcd_buffer_free uses a combination of dma pools and dma coher

Re: WARN_ON(irqs_disabled()) in dma_free_attrs?

2018-03-03 Thread Christoph Hellwig
On Sat, Mar 03, 2018 at 09:22:35AM +0100, Fredrik Noring wrote: > Critically, it performs the following calls: If it is allocating / freeing this memory all the time in the hot path it should really use a dma pool (see include/ilinux/dmapool.h). The dma coherent APIs aren't really built for being

Re: WARN_ON(irqs_disabled()) in dma_free_attrs?

2018-03-03 Thread Fredrik Noring
Hi Christoph, > Why do you want to free coherent dma allocations from irq context? > They generally are a long-term resource that as a rule of thumb should > be allocated in ->probe and freed in ->remove. The device specific HCD only does dma_declare_coherent_memory (with HCD_LOCAL_MEM) in ->prob

Re: WARN_ON(irqs_disabled()) in dma_free_attrs?

2018-03-03 Thread Fredrik Noring
Hi Robin, > Historically, that particular line of code appears to date back to commit > aa24886e379d (and tracking it's ancestry was quite fun). > > Now, I'm sure not all of the considerations of 11-and-a-half years ago still > apply, but one certainly does: ARM* still uses non-cacheable mappings