On Fri, Nov 18, 2016 at 05:36:46PM +, Robin Murphy wrote:
> On 16/11/16 15:29, Lorenzo Pieralisi wrote:
> > In ACPI bases systems, in order to be able to create platform
>
> based?
Ok.
> > devices and initialize them for ARM SMMU components, the IORT
> > kernel implementation
On 16/11/16 15:29, Lorenzo Pieralisi wrote:
> In ACPI bases systems, in order to be able to create platform
based?
> devices and initialize them for ARM SMMU components, the IORT
> kernel implementation requires a set of static functions to be
> used by the IORT kernel layer to
On 18/11/16 16:00, Will Deacon wrote:
> On Wed, Nov 16, 2016 at 03:29:32PM +, Lorenzo Pieralisi wrote:
>> Current ARM SMMU probe functions intermingle HW and DT probing
>> in the initialization functions to detect and programme the ARM SMMU
>> driver features. In order to allow probing the ARM
We met the DMAR fault both on hpsa P420i and P421 SmartArray controllers
under kdump, it can be steadily reproduced on several different machines,
the dmesg log is like(running on 4.9.0-rc5+):
HP HPSA Driver (v 3.4.16-0)
hpsa :02:00.0: using doorbell to reset controller
hpsa :02:00.0:
On Wed, Nov 16, 2016 at 03:29:33PM +, Lorenzo Pieralisi wrote:
> In ACPI bases systems, in order to be able to create platform
> devices and initialize them for ARM SMMU components, the IORT
> kernel implementation requires a set of static functions to be
> used by the IORT kernel layer to
On Wed, Nov 16, 2016 at 03:29:32PM +, Lorenzo Pieralisi wrote:
> Current ARM SMMU probe functions intermingle HW and DT probing
> in the initialization functions to detect and programme the ARM SMMU
> driver features. In order to allow probing the ARM SMMU with other
> firmwares than DT, this
On Wed, Nov 16, 2016 at 03:29:31PM +, Lorenzo Pieralisi wrote:
> In ACPI bases systems, in order to be able to create platform
> devices and initialize them for ARM SMMU v3 components, the IORT
> kernel implementation requires a set of static functions to be
> used by the IORT kernel layer to
On Wed, Nov 16, 2016 at 03:29:30PM +, Lorenzo Pieralisi wrote:
> Current ARM SMMUv3 probe functions intermingle HW and DT probing in the
> initialization functions to detect and programme the ARM SMMU v3 driver
> features. In order to allow probing the ARM SMMUv3 with other firmwares
> than
On Wed, Nov 16, 2016 at 03:29:26PM +, Lorenzo Pieralisi wrote:
> Current ARM SMMU v3 driver rely on the struct device.of_node pointer for
> device look-up and iommu_ops retrieval.
>
> In preparation for ACPI probing enablement, convert the driver to use
> the struct device.fwnode member for
On Wed, Nov 16, 2016 at 03:29:25PM +, Lorenzo Pieralisi wrote:
> Current ARM SMMU driver rely on the struct device.of_node pointer for
> device look-up and iommu_ops retrieval.
>
> In preparation for ACPI probing enablement, convert the driver to use
> the struct device.fwnode member for
On Wed, Nov 16, 2016 at 03:29:24PM +, Lorenzo Pieralisi wrote:
> The of_iommu_{set/get}_ops() API is used to associate a device
> tree node with a specific set of IOMMU operations. The same
> kernel interface is required on systems booting with ACPI, where
> devices are not associated with a
On 11/17/2016 05:00 PM, Joerg Roedel wrote:
On Thu, Nov 17, 2016 at 04:53:24PM -0500, Mark Hounschell wrote:
On 11/17/2016 04:41 PM, Joerg Roedel wrote:
Hi Mark,
On Thu, Nov 17, 2016 at 02:13:59PM -0500, Mark Hounschell wrote:
Kernel version is 4.8.0. No failure when the IOMMU is disabled.
Hi Bharat,
On 18/11/2016 06:34, Bharat Bhushan wrote:
> Hi Eric,
>
> Have you sent out QEMU side patches based on this new approach? In case I
> missed please point me the patches?
Upstream QEMU works fine for PCIe/MSI passthrough on ARM since mach virt
address space does not collide with
13 matches
Mail list logo
