Hi Christoph, Geoff,
[ CC-ing Geoff to give him an opportunity to chime in about the PS3 part. ]
> > Here are three other regressions related to the coherent mask WARN_ON_ONCE:
>
> They are a pretty strong indication that yes, you should really set
> the coherent mask if you ever do coherent all
Hi Christoph, Robin,
On Thu, Jul 05, 2018 at 09:36:13PM +0200, Christoph Hellwig wrote:
> > - BUG_ON(!ops);
> > - WARN_ON_ONCE(dev && !dev->coherent_dma_mask);
> > -
> > if (dma_alloc_from_dev_coherent(dev, size, dma_handle, &cpu_addr))
> > return cpu_addr;
> >
> > + BUG_ON
Hi Jürgen, Robin,
> Don't forget that the SIF DMA packets are limited and the kernel will
> block/reschedule when it is out of SIF DMA packets. The allocation is
> implemented inside the SBIOS. You may easily get a deadlock or a livelock
> when you just let it run without thinking about the design
Hi Robin,
> > Does dma_set_coherent_mask want a device object representing the IOP? Such
> > a thing is currently not implemented, but can certainly be done.
>
> Nope, just the same OHCI device as the dma_declare_coherent_memory() call.
Ah... and then some kind of dma_ops structure is needed to
Hi Robin,
On Fri, Jul 06, 2018 at 12:57:11PM +0100, Robin Murphy wrote:
> On 05/07/18 20:36, Christoph Hellwig wrote:
> > > - BUG_ON(!ops);
> > > - WARN_ON_ONCE(dev && !dev->coherent_dma_mask);
> > > -
> > > if (dma_alloc_from_dev_coherent(dev, size, dma_handle,
> > > &cpu_addr))
> > >
ite "you're doing it wrong" territory.
I have tested this patch and it corrects both problems with the PS2 OHCI
driver. I believe there is a fair chance that drivers/usb/host/ohci-sm501.c
and drivers/usb/host/ohci-tmio.c are fixed as well, since they are similar.
Tested-by: Fredr
Hi Robin, Christoph,
On Thu, Mar 15, 2018 at 01:11:03PM +, Robin Murphy wrote:
> On 15/03/18 07:58, Christoph Hellwig wrote:
> > On Wed, Mar 14, 2018 at 05:43:46PM +, Robin Murphy wrote:
> > > > So maybe for now the quick fix is to move the sleep check as suggested
> > > > earlier in this
Hi Christoph,
> The point is that you should always use a pool, period.
> dma_alloc*/dma_free* are fundamentally expensive operations on my
> architectures, so if you call them from a fast path you are doing
> something wrong.
The author's comment in commit b3476675320e "usb: dma bounce buffer su
Hi Alan Stern,
> > Alan, can dma_free_coherent be delayed to a point when IRQs are enabled?
>
> Yes, subject to the usual concerns about not being delayed for too
> long. Also, some HCDs are highly memory-constrained. I don't know if
> they use this API, but if they do then delaying a free co
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
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
except for probe and remove. How could they avoid the WARN_ON?
[ For reference, I attached the PS2 OHCI driver below. It has been tested
and works well provided the WARN_ON in dma_free_attrs is removed. ]
Fredrik
/*
* PlayStation 2 USB OHCI HCD (Host Controller Driver)
*
* Copyright (C) 2017 J
Hello DMA mapping helpers maintainers,
I'm porting the PS2 OHCI driver to v4.15 and it triggers
WARN_ON(irqs_disabled());
in include/linux/dma-mapping.h:dma_free_attrs (trace below). USB maintainer
Alan Stern notes in
https://www.spinics.net/lists/linux-usb/msg162817.html
that
13 matches
Mail list logo
