7; ;
> >linux-arm-ker...@lists.infradead.org; m.szyprow...@samsung.com
> >Subject: Re: [PATCH V3 0/8] IOMMU probe deferral support
> >
> >On Mon, Nov 28, 2016 at 11:12:08PM +0530, Sricharan wrote:
> >
> >[...]
> >
> >> >Cool. We're rather hoping tha
a...@arm.com;
>tf...@chromium.org; iommu@lists.linux-
>foundation.org; srinivas.kandaga...@linaro.org;
>laurent.pinch...@ideasonboard.com; 'Robin Murphy' ;
>linux-arm-ker...@lists.infradead.org; m.szyprow...@samsung.com
>Subject: Re: [PATCH V3 0/8] IOMMU probe deferral support
On Mon, Nov 28, 2016 at 11:12:08PM +0530, Sricharan wrote:
[...]
> >Cool. We're rather hoping that the ACPI stuff is good to go for 4.10
> >now, so it's probably worth pulling the rest of that in (beyond the one
> >patch I picked) to make sure the of_dma_configure/acpi_dma_configure
> >paths don'
Hi Robin,
>>
>>
>>>
iommu_group_get_for_dev which gets called in the add_device
callback, increases the reference count of the iommu_group,
so we do an iommu_group_put after that. iommu_group_get_for_dev
inturn calls device_group callback and in the case of arm
On 24/11/16 16:10, Sricharan wrote:
> Hi Robin,
>
>
>
>>
>>> iommu_group_get_for_dev which gets called in the add_device
>>> callback, increases the reference count of the iommu_group,
>>> so we do an iommu_group_put after that. iommu_group_get_for_dev
>>> inturn calls device_gro
Hi Robin,
>
>> iommu_group_get_for_dev which gets called in the add_device
>> callback, increases the reference count of the iommu_group,
>> so we do an iommu_group_put after that. iommu_group_get_for_dev
>> inturn calls device_group callback and in the case of arm-smmu
>> we
On 20/11/16 15:11, Sricharan wrote:
> Hi Robin,
>
>> Hi Robin,
>>
>>> Hi Robin,
>>>
On 04/11/16 15:16, Sricharan wrote:
> Hi Robin,
>
Yikes, on second look, that definitely shouldn't be happening.
Everything below is probably the resulting fallout.
>>>
>>> [
Hi Robin,
>Hi Robin,
>
>>Hi Robin,
>>
>>>On 04/11/16 15:16, Sricharan wrote:
Hi Robin,
>>> Yikes, on second look, that definitely shouldn't be happening.
>>> Everything below is probably the resulting fallout.
>>
>> [ 40.206703] vfio-pci :08:00.0: Failed to setup io
Hi Robin,
>Hi Robin,
>
>>On 04/11/16 15:16, Sricharan wrote:
>>> Hi Robin,
>>>
>> Yikes, on second look, that definitely shouldn't be happening.
>> Everything below is probably the resulting fallout.
>
> [ 40.206703] vfio-pci :08:00.0: Failed to setup iommu ops
>
> I
On Wed, Nov 09, 2016 at 11:54:20AM +0530, Sricharan wrote:
> >> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> >> index 71ce4b6..a1d0b3c 100644
> >> --- a/drivers/iommu/arm-smmu.c
> >> +++ b/drivers/iommu/arm-smmu.c
> >> @@ -1516,8 +1516,10 @@ static struct iommu_group
> >> *ar
Hi Robin,
>On 04/11/16 15:16, Sricharan wrote:
>> Hi Robin,
>>
> Yikes, on second look, that definitely shouldn't be happening.
> Everything below is probably the resulting fallout.
[ 40.206703] vfio-pci :08:00.0: Failed to setup iommu ops
I think the above print
Hi Sricharan,
On 04/11/16 15:16, Sricharan wrote:
> Hi Robin,
>
Yikes, on second look, that definitely shouldn't be happening.
Everything below is probably the resulting fallout.
>>>
>>> [ 40.206703] vfio-pci :08:00.0: Failed to setup iommu ops
>>>
>>> I think the above print whic
On Fri, Nov 04, 2016 at 08:46:06PM +0530, Sricharan wrote:
> >>>Yikes, on second look, that definitely shouldn't be happening.
> >>>Everything below is probably the resulting fallout.
> >>
> >>[ 40.206703] vfio-pci :08:00.0: Failed to setup iommu ops
> >>
> >>I think the above print which say
Hi Robin,
>>>Yikes, on second look, that definitely shouldn't be happening.
>>>Everything below is probably the resulting fallout.
>>
>>[ 40.206703] vfio-pci :08:00.0: Failed to setup iommu ops
>>
>>I think the above print which says "failed to setup iommu_ops"
>>because the call ops->add_de
Hi Robin,
[ 39.901592] iommu: Removing device :08:00.0 from group 0
>>
>>Yikes, on second look, that definitely shouldn't be happening.
>>Everything below is probably the resulting fallout.
>
>[ 40.206703] vfio-pci :08:00.0: Failed to setup iommu ops
>
>I think the above print whi
Hi Robin,
>>
>>
>>
>>> [ 39.901592] iommu: Removing device :08:00.0 from group 0
>
>Yikes, on second look, that definitely shouldn't be happening.
>Everything below is probably the resulting fallout.
[ 40.206703] vfio-pci :08:00.0: Failed to setup iommu ops
I think the above print wh
On 26/10/16 15:44, Sricharan wrote:
> Hi Robin,
>
>> On 04/10/16 18:03, Sricharan R wrote:
>>> Initial post from Laurent Pinchart[1]. This is
>>> series calls the dma ops configuration for the devices
>>> at a generic place so that it works for all busses.
>>> The dma_configure_ops for a device is
Hi Robin,
>On 04/10/16 18:03, Sricharan R wrote:
>> Initial post from Laurent Pinchart[1]. This is
>> series calls the dma ops configuration for the devices
>> at a generic place so that it works for all busses.
>> The dma_configure_ops for a device is now called during
>> the device_attach callba
Hi Sricharan,
On 04/10/16 18:03, Sricharan R wrote:
> Initial post from Laurent Pinchart[1]. This is
> series calls the dma ops configuration for the devices
> at a generic place so that it works for all busses.
> The dma_configure_ops for a device is now called during
> the device_attach callback
On 10/04/2016 10:33 PM, Sricharan R wrote:
Initial post from Laurent Pinchart[1]. This is
series calls the dma ops configuration for the devices
at a generic place so that it works for all busses.
The dma_configure_ops for a device is now called during
the device_attach callback just before the
Hi Marek,
Initial post from Laurent Pinchart[1]. This is
series calls the dma ops configuration for the devices
at a generic place so that it works for all busses.
The dma_configure_ops for a device is now called during
the device_attach callback just before the probe of t
Hi Sricharan,
On 2016-10-12 08:24, Sricharan wrote:
On 2016-10-04 19:03, Sricharan R wrote:
Initial post from Laurent Pinchart[1]. This is
series calls the dma ops configuration for the devices
at a generic place so that it works for all busses.
The dma_configure_ops for a device is now called
bin.mur...@arm.com; j...@8bytes.org; iommu@lists.linux-
>foundation.org; linux-arm-ker...@lists.infradead.org;
>linux-arm-...@vger.kernel.org; laurent.pinch...@ideasonboard.com;
>tf...@chromium.org; srinivas.kandaga...@linaro.org
>Subject: Re: [PATCH V3 0/8] IOMMU probe deferral support
;iommu@lists.linux-foundation.org' foundation.org>; 'linux-arm-ker...@lists.infradead.org'
>; 'linux-arm-...@vger.kernel.org'
>; 'laurent.pinch...@ideasonboard.com'
>;
>'tf...@chromium.org' ; 'srinivas.kandaga...@linaro.org'
&
Hi Marek,
>Hi Sricharan,
>
>
>On 2016-10-04 19:03, Sricharan R wrote:
>> Initial post from Laurent Pinchart[1]. This is
>> series calls the dma ops configuration for the devices
>> at a generic place so that it works for all busses.
>> The dma_configure_ops for a device is now called during
>> the
Hi Sricharan,
On 2016-10-04 19:03, Sricharan R wrote:
Initial post from Laurent Pinchart[1]. This is
series calls the dma ops configuration for the devices
at a generic place so that it works for all busses.
The dma_configure_ops for a device is now called during
the device_attach callback just
Initial post from Laurent Pinchart[1]. This is
series calls the dma ops configuration for the devices
at a generic place so that it works for all busses.
The dma_configure_ops for a device is now called during
the device_attach callback just before the probe of the
bus/driver is called. Similarly d
27 matches
Mail list logo
