On Mon, Aug 6, 2018 at 2:08 PM Christoph Hellwig wrote:
>
> On Mon, Aug 06, 2018 at 12:01:34PM +0200, Arnd Bergmann wrote:
> > There are a few subtle corner cases here, in particular in which cases
> > the new dma_set_mask() behavior on arm64 reports success or
> > failure when truncating the
On Mon, Aug 06, 2018 at 12:01:34PM +0200, Arnd Bergmann wrote:
> There are a few subtle corner cases here, in particular in which cases
> the new dma_set_mask() behavior on arm64 reports success or
> failure when truncating the mask to the bus_dma_mask.
Going forward my plan was to make
On Tue, Jul 31, 2018 at 1:30 PM Robin Murphy wrote:
> On 29/07/18 13:32, Arnd Bergmann wrote:
> > On Tue, Jul 24, 2018 at 12:16 AM, Robin Murphy wrote:
> > Thanks a lot for working on this, this has bugged me for many years,
> > and I've discussed possible solutions with lots of people over
Hi Arnd,
On 29/07/18 13:32, Arnd Bergmann wrote:
On Tue, Jul 24, 2018 at 12:16 AM, Robin Murphy wrote:
Whilst the common firmware code invoked by dma_configure() initialises
devices' DMA masks according to limitations described by the respective
properties ("dma-ranges" for OF and _DMA/IORT
On Tue, Jul 24, 2018 at 12:16 AM, Robin Murphy wrote:
> Whilst the common firmware code invoked by dma_configure() initialises
> devices' DMA masks according to limitations described by the respective
> properties ("dma-ranges" for OF and _DMA/IORT for ACPI), the nature of
> the dma_set_mask()
On 07/27/2018 05:55 AM, Robin Murphy wrote:
> Hi Grygorii,
>
> Thanks for the report.
>
> On 27/07/18 00:45, Grygorii Strashko wrote:
> [...]
>> With this series applied I can't boot TI ARM32 am574x-idk any more.
>>
>> And log output is full of "DMA mask not set" -
>
> That's somewhat
Hi Grygorii,
Thanks for the report.
On 27/07/18 00:45, Grygorii Strashko wrote:
[...]
With this series applied I can't boot TI ARM32 am574x-idk any more.
And log output is full of "DMA mask not set" -
That's somewhat expected - as the relevant commit message mentions,
there will be bugs
On 07/23/2018 05:16 PM, Robin Murphy wrote:
> Whilst the common firmware code invoked by dma_configure() initialises
> devices' DMA masks according to limitations described by the respective
> properties ("dma-ranges" for OF and _DMA/IORT for ACPI), the nature of
> the dma_set_mask() API leads
Thanks,
applied to the dma-mapping tree.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On 25 July 2018 at 13:31, Christoph Hellwig wrote:
> Hi Robin,
>
> this series looks fine to me. Do you want me to pull this into the
> dma-mapping tree? I'd like to see a few more ACKs from the ACPI/OF/
> IOMMU maintainers though.
>
This fixes the issue I reported with the on-SoC NIC of the
On Wed, Jul 25, 2018 at 01:12:56PM +0100, Robin Murphy wrote:
> On 25/07/18 12:31, Christoph Hellwig wrote:
> >Hi Robin,
> >
> >this series looks fine to me. Do you want me to pull this into the
> >dma-mapping tree? I'd like to see a few more ACKs from the ACPI/OF/
> >IOMMU maintainers though.
>
On 25/07/18 12:31, Christoph Hellwig wrote:
Hi Robin,
this series looks fine to me. Do you want me to pull this into the
dma-mapping tree? I'd like to see a few more ACKs from the ACPI/OF/
IOMMU maintainers though.
Thanks, I was indeed assuming that the dma-mapping tree would be the
best
On Wed, Jul 25, 2018 at 01:31:22PM +0200, Christoph Hellwig wrote:
> Hi Robin,
>
> this series looks fine to me. Do you want me to pull this into the
> dma-mapping tree? I'd like to see a few more ACKs from the ACPI/OF/
> IOMMU maintainers though.
For the IOMMU parts:
Acked-by: Joerg
Hi Robin,
this series looks fine to me. Do you want me to pull this into the
dma-mapping tree? I'd like to see a few more ACKs from the ACPI/OF/
IOMMU maintainers though.
___
iommu mailing list
iommu@lists.linux-foundation.org
14 matches
Mail list logo
