On Fri, Jul 27, 2018 at 10:50:34AM -0600, Rob Herring wrote:
> On Fri, Jul 27, 2018 at 8:18 AM Robin Murphy wrote:
> >
> > On 27/07/18 15:20, Christoph Hellwig wrote:
> > > On Fri, Jul 27, 2018 at 03:14:15PM +0100, Robin Murphy wrote:
> > >> This shouldn't strictly depend on the changes currently
On Fri, Jul 27, 2018 at 8:18 AM Robin Murphy wrote:
>
> On 27/07/18 15:20, Christoph Hellwig wrote:
> > On Fri, Jul 27, 2018 at 03:14:15PM +0100, Robin Murphy wrote:
> >> This shouldn't strictly depend on the changes currently queued in the
> >> dma-mapping tree, so should be OK to go through the
On 27/07/18 15:20, Christoph Hellwig wrote:
On Fri, Jul 27, 2018 at 03:14:15PM +0100, Robin Murphy wrote:
This shouldn't strictly depend on the changes currently queued in the
dma-mapping tree, so should be OK to go through the DT tree in parallel.
Ideally we'd fix all DMA-capable drivers to
On Fri, Jul 27, 2018 at 03:14:15PM +0100, Robin Murphy wrote:
> This shouldn't strictly depend on the changes currently queued in the
> dma-mapping tree, so should be OK to go through the DT tree in parallel.
> Ideally we'd fix all DMA-capable drivers to set their masks correctly,
> but in the
When of_dma_configure() was first born in 591c1ee465ce ("of: configure
the platform device dma parameters"), everything DMA-related was
factored out of of_platform_device_create_pdata() as seemed appropriate
at the time. However, now that of_dma_configure() has grown into the
generic handler for
