>> /*
>> * Swizzle the device pin each time we cross a bridge. If a platform does
>> * not provide a swizzle function, we perform the standard PCI swizzling.
>> @@ -478,8 +464,6 @@ static void pcibios_init_hw(struct device *parent,
>> struct hw_pci *hw,
>> sys->swizzle = hw->swi
On 2014/10/23 13:41, Bjorn Helgaas wrote:
> On Wed, Oct 15, 2014 at 11:06:58AM +0800, Yijing Wang wrote:
>> Now msi chip is saved in pci_sys_data in arm,
>> we could clean the bus->msi assignment in
>> pci core.
>>
>> Signed-off-by: Yijing Wang
>> CC: Thierry Reding
>> CC: Thomas Petazzoni
>> --
>> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
>> index 22e413c..f11108c 100644
>> --- a/drivers/pci/msi.c
>> +++ b/drivers/pci/msi.c
>> @@ -35,6 +35,9 @@ int __weak arch_setup_msi_irq(struct pci_dev *dev, struct
>> msi_desc *desc)
>> struct msi_chip *chip = dev->bus->msi;
>> int
On 2014/10/23 13:18, Bjorn Helgaas wrote:
> On Wed, Oct 15, 2014 at 11:06:53AM +0800, Yijing Wang wrote:
>> Save msi chip in pci_sys_data instead of assign
>> msi chip to every pci bus in .add_bus().
>>
>> Signed-off-by: Yijing Wang
>> ---
>> drivers/pci/host/pci-tegra.c | 13 +++--
>>
On Wed, Oct 15, 2014 at 11:06:48AM +0800, Yijing Wang wrote:
> Now there are a lot of weak arch functions in MSI code.
> Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm,
> that's a better solution than overriding lots of existing weak arch
> functionsin.
> This series u
On Wed, Oct 15, 2014 at 11:06:58AM +0800, Yijing Wang wrote:
> Now msi chip is saved in pci_sys_data in arm,
> we could clean the bus->msi assignment in
> pci core.
>
> Signed-off-by: Yijing Wang
> CC: Thierry Reding
> CC: Thomas Petazzoni
> ---
> drivers/pci/probe.c |1 -
> 1 files change
On Wed, Oct 15, 2014 at 11:06:57AM +0800, Yijing Wang wrote:
> MSI chip will be saved in pci_sys_data, now we can
> clean up pcibios_add_bus() and pcibios_remove_bus()
> in arm, and use pci_find_msi_chip() to get msi chip
> in core MSI code.
>
> Signed-off-by: Yijing Wang
> ---
> arch/arm/includ
On Wed, Oct 15, 2014 at 11:06:52AM +0800, Yijing Wang wrote:
> Saving msi chip in pci_sys_data can make pci bus and
> devices don't need to know msi chip detail, it also
> make pci enumeration code be decoupled from msi chip.
> In fact, all pci devices under the same pci hostbridge
> share same msi
On Wed, Oct 15, 2014 at 11:06:53AM +0800, Yijing Wang wrote:
> Save msi chip in pci_sys_data instead of assign
> msi chip to every pci bus in .add_bus().
>
> Signed-off-by: Yijing Wang
> ---
> drivers/pci/host/pci-tegra.c | 13 +++--
> 1 files changed, 3 insertions(+), 10 deletions(-)
On 2014/10/23 12:25, Bjorn Helgaas wrote:
> On Wed, Oct 15, 2014 at 11:06:50AM +0800, Yijing Wang wrote:
>> Commit 0e4ccb1505a9 ("PCI: Add x86_msi.msi_mask_irq() and msix_mask_irq()")
>> introduced two __weak arch functions arch_msix_mask_irq() and
>> arch_msi_mask_irq() to work around a bug when r
On Wed, Oct 15, 2014 at 11:06:50AM +0800, Yijing Wang wrote:
> Commit 0e4ccb1505a9 ("PCI: Add x86_msi.msi_mask_irq() and msix_mask_irq()")
> introduced two __weak arch functions arch_msix_mask_irq() and
> arch_msi_mask_irq() to work around a bug when running xen in x86.
> These two functions made m
On 2014/10/23 7:53, Bjorn Helgaas wrote:
> On Wed, Oct 15, 2014 at 11:07:12AM +0800, Yijing Wang wrote:
>> Use MSI chip framework instead of arch MSI functions to configure
>> MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
>
> This needs slightly more detail. You're using t
On Wed, Oct 15, 2014 at 11:07:12AM +0800, Yijing Wang wrote:
> Use MSI chip framework instead of arch MSI functions to configure
> MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
This needs slightly more detail. You're using the MSI chip framework
"instead of arch MSI functi
Hi Suman,
Thank you for the patch.
On Wednesday 22 October 2014 17:22:30 Suman Anna wrote:
> The debugfs support for OMAP IOMMU is currently implemented
> as a module, warranting certain OMAP-specific IOMMU API to
> be exported. The OMAP IOMMU, when enabled, can only be built-in
> into the kernel
Any debugfs access on an OMAP IOMMU that is not enabled (done during
attach) results in a bus error due to access of registers without
the clock or the reset enabled for the respective IOMMU. So, add a
check to make sure the IOMMU is enabled/attached by a client device.
This gracefully prints a "Op
The OMAP IOMMU driver was originally designed as modules, and split
into a core module and a thin arch-specific module through the OMAP
arch-specific struct iommu_functions, to scale for both OMAP1 and
OMAP2+ IOMMU variants. The driver can only be built for OMAP2+
platforms currently, and also can
The isr_priv field is a left-over from before the IOMMU API
adaptation, this was used to store the callback data. This is
no longer relevant, so remove it.
Signed-off-by: Suman Anna
Acked-by: Laurent Pinchart
---
drivers/iommu/omap-iommu.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/driv
Hi,
This is an updated version of the OMAP IOMMU Cleanup & Consolidation
patch series [1], rebased onto 3.18-rc1. The update addresses
comments on patch 12 [2] from the previous series, there are no
changes to any of the other patches.
The series is intended for the 3.19 merge window. A reference
The exported functions omap_foreach_iommu_device() and
omap_iotlb_cr_to_e() have been deleted, as they are no
longer needed.
The function omap_foreach_iommu_device() is not required
after the consolidation of the OMAP IOMMU debug module,
and the function omap_iotlb_cr_to_e() is not required
after
The omap2_iommu_save_ctx() and omap2_iommu_restore_ctx()
performs a sanity version check against a fixed value
that is correct only for OMAP2/OMAP3 IOMMUs. This fixed check
does not scale for all OMAP2+ IOMMUs and is not absolutely
required, so it has been removed.
Signed-off-by: Suman Anna
Acked
The function omap_iommu_arch_version() is not used anymore,
and is not required either, so remove it. The .version field
in struct iommu_functions that this function uses is also
removed, as it is not really an ops to retrieve a version and
there won't be any usage for this field either.
Signed-of
The .domain field in omap_iommu struct is set properly when the
OMAP IOMMU device is attached to, but is never reset properly
on detach. Reset this properly so that the OMAP IOMMU debugfs
logic can depend on this field before allowing the debugfs
operations.
Signed-off-by: Suman Anna
Acked-by: La
The refcount field in omap_iommu object is primarily used to check
if an IOMMU device has already been enabled, but this is already
implicit in the omap_iommu_attach_dev() which ensures that only
a single device can attach to an IOMMU. This field is redundant,
and so has been cleaned up.
Signed-of
The omap_iommu_save_ctx() and omap_iommu_restore_ctx() declarations
are defined in include/linux/omap-iommu.h and do not belong in the
internal drivers/iommu/omap-iommu.h header, so remove them.
Signed-off-by: Suman Anna
Acked-by: Laurent Pinchart
---
drivers/iommu/omap-iommu.h | 3 ---
1 file
The debugfs support for OMAP IOMMU is currently implemented
as a module, warranting certain OMAP-specific IOMMU API to
be exported. The OMAP IOMMU, when enabled, can only be built-in
into the kernel, so integrate the OMAP IOMMU debug module
into the OMAP IOMMU driver. This helps in eliminating the
The debugfs entry 'pagetable' that shows the page table entry
(PTE) data currently outputs only data that can be fit into a
page. Switch the entry to use the seq_file interface so that
it can show all the valid page table entries.
The patch also corrected the output for L2 entries, and prints
the
The dev_to_omap_iommu() is local to the OMAP IOMMU modules, and
need not be defined conditionally. The CONFIG_IOMMU_API dependency
check was added in the past to fix a compilation issue back when
the header resided in the arch/arm layers, and is no longer
needed.
While at this, fix the header agai
Remove the writeability on the 'pagetable' debugfs entry,
so that the mapping/unmapping into an OMAP IOMMU is only
limited to actual client devices/drivers at kernel-level.
Signed-off-by: Suman Anna
Acked-by: Laurent Pinchart
---
drivers/iommu/omap-iommu-debug.c | 48 ++-
The following functions were exported previously for usage by
the OMAP IOMMU debug module:
omap_iommu_dump_ctx()
omap_dump_tlb_entries()
omap_iopgtable_store_entry()
These functions need not be exported anymore as the OMAP IOMMU
debugfs code is integrated with the OMAP IOMM
The permissions on the debugfs entry "nr_tlb_entries" should
have been octal, not decimal, so fix it.
Signed-off-by: Suman Anna
Acked-by: Laurent Pinchart
---
drivers/iommu/omap-iommu-debug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/omap-iommu-debug.c b/
The debugfs entry 'ver' to read the OMAP IOMMU version is
not much useful for developers, so it has been removed. The
same can be deduced from the register dump, provided by the
debugfs entry 'regs', REVISION register. This also allows us
to remove the omap_iommu_arch_revision() which is currently
The function omap2_iommu_fault_isr() does an unnecessary
recomputation of the return value. The logic relies on
setting the same bit fields as the MMU fault error status
bits, so simplify this function and remove the unneeded
macros. These macros were originally exported to notify
MMU faults to use
On Thu, 2014-10-16 at 17:54 +0200, Antonios Motakis wrote:
> This RFC's intention is to show what an interface to access device node
> properties for the VFIO platform driver can look like.
>
> If a device tree node corresponding to a platform device bound by VFIO
> PLATFORM
> or VFIO AMBA is ava
Hi Joerg,
On 10/22/2014 08:29 AM, Joerg Roedel wrote:
> On Tue, Oct 21, 2014 at 04:28:27PM -0500, Suman Anna wrote:
>> I am looking to refresh this series for 3.19, and this is the only patch
>> that may need some changes. Please let me know what your preference is,
>> and I can rework this patch
On Wed, Oct 22, 2014 at 7:21 AM, Joerg Roedel wrote:
> Hi Bjorn,
>
> On Tue, Oct 21, 2014 at 08:16:46PM -0600, Bjorn Helgaas wrote:
>> I was looking at Zhen-Hua's recent patches, trying to figure out if I
>> need to do anything with them. Resetting devices in the old kernel
>> seems like a non-st
>> If you are convinced that dropping the null tests is a good idea, then you
>> can submit the patch that makes the change to the relevant maintainers and
>> mailing lists.
>From af73fb59d5d4b2c289fb236d0752522b6b38 Mon Sep 17 00:00:00 2001
From: Markus Elfring
Date: Wed, 22 Oct 2014 19:39
On Wed, Oct 22, 2014 at 6:46 PM, Alex Williamson
wrote:
> On Wed, 2014-10-22 at 15:54 +0200, Antonios Motakis wrote:
>> On Tue, Oct 21, 2014 at 6:34 PM, Alex Williamson
>> wrote:
>> > On Mon, 2014-10-13 at 15:10 +0200, Antonios Motakis wrote:
>> >> This patch enables the IOCTLs VFIO_DEVICE_GET_RE
On Wed, Oct 22, 2014 at 10:54 AM, Alexander Duyck
wrote:
> On 10/21/2014 07:47 PM, Bjorn Helgaas wrote:
>> [+cc Joerg, Eric, Tom, David, iommu list]
>>
>> On Wed, Oct 15, 2014 at 2:14 AM, Takao Indoh
>> wrote:
>>> (2014/10/14 18:34), Li, ZhenHua wrote:
I tested on the latest stable version
On 10/21/2014 07:47 PM, Bjorn Helgaas wrote:
> [+cc Joerg, Eric, Tom, David, iommu list]
>
> On Wed, Oct 15, 2014 at 2:14 AM, Takao Indoh
> wrote:
>> (2014/10/14 18:34), Li, ZhenHua wrote:
>>> I tested on the latest stable version 3.17, it works well.
>>>
>>> On 10/10/2014 03:13 PM, Li, Zhen-Hua
On Wed, 2014-10-22 at 15:55 +0200, Antonios Motakis wrote:
> On Tue, Oct 21, 2014 at 6:51 PM, Alex Williamson
> wrote:
> > On Mon, 2014-10-13 at 15:10 +0200, Antonios Motakis wrote:
> >> Allow to memory map the MMIO regions of the device so userspace can
> >> directly access them. PIO regions are
On Wed, 2014-10-22 at 15:54 +0200, Antonios Motakis wrote:
> On Tue, Oct 21, 2014 at 6:34 PM, Alex Williamson
> wrote:
> > On Mon, 2014-10-13 at 15:10 +0200, Antonios Motakis wrote:
> >> This patch enables the IOCTLs VFIO_DEVICE_GET_REGION_INFO ioctl call,
> >> which allows the user to learn about
On Wed, Oct 22, 2014 at 04:17:29PM +0200, Joerg Roedel wrote:
> Hi Frank,
>
> On Tue, Oct 21, 2014 at 01:57:25PM +0200, Frank Blaschka wrote:
> > Add a basic iommu for the s390 platform. The code is pretty simple
> > since on s390 each PCI device has its own virtual io address space
> > starting a
On Mon, Oct 20, 2014 at 07:42:01PM +0100, Will Deacon wrote:
> On Mon, Oct 20, 2014 at 04:39:15PM +0100, Will Deacon wrote:
> > On Mon, Oct 13, 2014 at 02:06:15PM +0100, Antonios Motakis wrote:
> > > This patch series applies to Joerg Roedel's iommu/next branch, commit
> > > 09b5269a.
> > > It rep
On Wed, Oct 01, 2014 at 06:20:40PM +0800, Daniel Kurtz wrote:
> Add a driver and devicetree bindings for the IOMMU found in Rockchip RK3288
> SoCs.
>
> Daniel Kurtz (3):
> iommu/rockchip: rk3288 iommu driver
> dt-bindings: iommu: Add documentation for rockchip iommu
> ARM: dts: rk3288: add V
On Tue, Oct 14, 2014 at 04:02:40PM +0800, Daniel Kurtz wrote:
> +static void rk_iommu_detach_device(struct iommu_domain *domain,
> +struct device *dev)
> +{
> + struct rk_iommu *iommu = dev_get_drvdata(dev->archdata.iommu);
> + struct rk_iommu_domain *rk_doma
Add a basic iommu for the s390 platform. The code is pretty simple
since on s390 each PCI device has its own virtual io address space
starting at the same vio address. For this a domain could hold only
one pci device. Also there is no relation between pci devices so each
device belongs to a separat
Le mardi 16 septembre 2014 à 13:54 +0200, Marek Szyprowski a écrit :
> The driver doesn't need to do anything important in device add/remove
> callbacks, because initialization will be done from device-tree specific
> callbacks added later. IOMMU groups created by current code were never
> used.
>
On Fri, Oct 10, 2014 at 07:01:10PM +0530, Kiran Padwal wrote:
> Use the wrapper function for retrieving the platform data instead of
> accessing dev->platform_data directly.
>
> Signed-off-by: Kiran Padwal
> ---
> drivers/iommu/msm_iommu_dev.c |4 ++--
> drivers/iommu/omap-iommu.c|6
On Wed, Oct 15, 2014 at 11:10:44AM +0200, Thierry Reding wrote:
> It seems like I never got back to you on this. The reason here is that
> for Tegra the IOMMU is part of a larger IP block. The IP block is
> primarily a memory controller with a bunch of configuration knobs for
> arbitration, priorit
Hi Frank,
On Tue, Oct 21, 2014 at 01:57:25PM +0200, Frank Blaschka wrote:
> Add a basic iommu for the s390 platform. The code is pretty simple
> since on s390 each PCI device has its own virtual io address space
> starting at the same vio address.
Are there any limitations on IOVA address space f
On Wed, Oct 22, 2014 at 11:08 AM, Eric Auger wrote:
> On 10/13/2014 03:09 PM, Antonios Motakis wrote:
>> VFIO_IOMMU_TYPE1 keeps track for each domain it knows a list of protection
>> flags it always applies to all mappings in the domain. This is used for
>> domains that support IOMMU_CAP_CACHE_COH
On Tue, Oct 21, 2014 at 7:55 PM, Alex Williamson
wrote:
> On Mon, 2014-10-13 at 15:10 +0200, Antonios Motakis wrote:
>> The virqfd functionality that is used by VFIO_PCI to implement interrupt
>> masking and unmasking via an eventfd, is generic enough and can be reused
>> by another driver. Move i
On Tue, Oct 21, 2014 at 7:47 PM, Alex Williamson
wrote:
> On Mon, 2014-10-13 at 15:10 +0200, Antonios Motakis wrote:
>> Adds support to mask interrupts, and also for automasked interrupts.
>> Level sensitive interrupts are exposed as automasked interrupts and
>> are masked and disabled automatical
On Tue, Oct 21, 2014 at 6:51 PM, Alex Williamson
wrote:
> On Mon, 2014-10-13 at 15:10 +0200, Antonios Motakis wrote:
>> Allow to memory map the MMIO regions of the device so userspace can
>> directly access them. PIO regions are not being handled at this point.
>>
>> Signed-off-by: Antonios Motaki
On Tue, Oct 21, 2014 at 6:34 PM, Alex Williamson
wrote:
> On Mon, 2014-10-13 at 15:10 +0200, Antonios Motakis wrote:
>> This patch enables the IOCTLs VFIO_DEVICE_GET_REGION_INFO ioctl call,
>> which allows the user to learn about the available MMIO resources of
>> a device.
>>
>> Signed-off-by: An
On Tue, Oct 21, 2014 at 6:37 PM, Eric Auger wrote:
> On 10/21/2014 06:17 PM, Alex Williamson wrote:
>> On Mon, 2014-10-13 at 15:10 +0200, Antonios Motakis wrote:
>>> Driver to bind to Linux platform devices, and callbacks to discover their
>>> resources to be used by the main VFIO PLATFORM code.
>
On Tue, Oct 21, 2014 at 04:28:27PM -0500, Suman Anna wrote:
> I am looking to refresh this series for 3.19, and this is the only patch
> that may need some changes. Please let me know what your preference is,
> and I can rework this patch if needed. Either way,
> the plan is to not have an OMAP IOM
Hi Bjorn,
On Tue, Oct 21, 2014 at 08:16:46PM -0600, Bjorn Helgaas wrote:
> I was looking at Zhen-Hua's recent patches, trying to figure out if I
> need to do anything with them. Resetting devices in the old kernel
> seems like a non-starter. Resetting devices in the new kernel, ...,
> well, mayb
On 10/22/14 at 10:22am, Li, Zhen-Hua wrote:
>
> Hi Baoquan,
> I tested it on 3.17, it does not have these faults. There are little
> differences between this version and Bill's last version.
>
> I will test it on 3.18.0-rc1+ on my system and let you know the result.
>
> And could you send me th
Hi Baoquan,
I tested it on 3.17, it does not have these faults. There are little
differences between this version and Bill's last version.
I will test it on 3.18.0-rc1+ on my system and let you know the result.
And could you send me the result of "lspci -vvv " on your system?
Thanks
Zhenhua
>
Hi Zhenhua,
I tested your latest patch on 3.18.0-rc1+, there are still some dmar
errors. I remember it worked well with Bill's original patchset.
0console [earlya[0.00] allocate tes of page_cg 'a ong[
0.00] tsc: Fast TSC calibration using PIT
0031] Calibrating delay loop (skipped),
On 10/13/2014 03:09 PM, Antonios Motakis wrote:
> VFIO_IOMMU_TYPE1 keeps track for each domain it knows a list of protection
> flags it always applies to all mappings in the domain. This is used for
> domains that support IOMMU_CAP_CACHE_COHERENCY.
>
> Refactor this slightly, by keeping track inst
62 matches
Mail list logo
