On Thu, Sep 25, 2014 at 11:14:12AM +0800, Yijing Wang wrote:
> Currently, PCI drivers will initialize bus->msi in
> pcibios_add_bus(). pcibios_add_bus() will be called
> in every pci bus initialization. So the bus->msi
> assignment in pci_alloc_child_bus() is useless.
I think this should be the ot
On Thu, Sep 25, 2014 at 11:14:11AM +0800, Yijing Wang wrote:
> Msi_chip functions setup_irq/teardown_irq rarely use msi_chip
> argument.
That's not true. Out of the four drivers that you modify two use the
parameter. And the two that don't probably should be using it too.
50% is not "rarely". =)
On Thu, Sep 25, 2014 at 11:14:13AM +0800, Yijing Wang wrote:
> Currently, pcie-designware, pcie-rcar, pci-tegra drivers
> use irq chip_data to save the msi_chip pointer. They
> already call irq_set_chip_data() in their own MSI irq map
> functions. So irq_set_chip_data() in arch_setup_msi_irq()
> is
On Thu, Sep 25, 2014 at 11:14:16AM +0800, Yijing Wang wrote:
> Introduce weak arch_find_msi_chip() to find the match msi_chip.
> Currently, MSI chip associates pci bus to msi_chip. Because in
> ARM platform, there may be more than one MSI controller in system.
> Associate pci bus to msi_chip help p
On Thu, Sep 25, 2014 at 11:14:22AM +0800, Yijing Wang wrote:
[...]
> diff --git a/arch/mips/pci/msi-octeon.c b/arch/mips/pci/msi-octeon.c
[...]
> @@ -132,12 +132,12 @@ msi_irq_allocated:
> /* Make sure the search for available interrupts didn't fail */
> if (irq >= 64) {
>
On Thu, Sep 25, 2014 at 11:14:24AM +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.
Nit: s/irq/IRQ/ in the above.
> Signed-off-by: Yijing Wang
> ---
> arch/mips/pci/msi-xlp.c |
On Thu, Sep 25, 2014 at 11:14:25AM +0800, Yijing Wang wrote:
[...]
> diff --git a/arch/mips/pci/pci-xlr.c b/arch/mips/pci/pci-xlr.c
[...]
> @@ -214,11 +214,11 @@ static int get_irq_vector(const struct pci_dev *dev)
> }
>
> #ifdef CONFIG_PCI_MSI
> -void arch_teardown_msi_irq(unsigned int irq)
>
On Thu, Sep 25, 2014 at 11:14:27AM +0800, Yijing Wang wrote:
[...]
> diff --git a/arch/s390/pci/pci.c b/arch/s390/pci/pci.c
[...]
> @@ -358,7 +358,7 @@ static void zpci_irq_handler(struct airq_struct *airq)
> }
> }
>
> -int arch_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type)
> +i
On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote:
> This series is based Bjorn's pci/msi branch
> git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi
>
> Currently, there are a lot of weak arch functions in MSI code.
> Thierry Reding Introduced MSI chip framework to co
On Thu, 25 Sep 2014, Thierry Reding wrote:
> On Thu, Sep 25, 2014 at 11:14:11AM +0800, Yijing Wang wrote:
> > Msi_chip functions setup_irq/teardown_irq rarely use msi_chip
> > argument.
>
> That's not true. Out of the four drivers that you modify two use the
> parameter. And the two that don't pr
On Thu, 25 Sep 2014, Yijing Wang wrote:
> Introduce weak arch_find_msi_chip() to find the match msi_chip.
> Currently, MSI chip associates pci bus to msi_chip. Because in
> ARM platform, there may be more than one MSI controller in system.
> Associate pci bus to msi_chip help pci device to find th
Hello,
On 2014-09-24 19:06, Will Deacon wrote:
Hi Marek,
On Tue, Sep 16, 2014 at 12:54:28PM +0100, Marek Szyprowski wrote:
If device has no max_seg_size set, we assume that there is no limit and
force it to DMA_BIT_MASK(32) to always use contiguous mappings in DMA
address space.
Signed-off-by
On Mon, Sep 22, 2014 at 02:18:10PM +0100, Will Deacon wrote:
> Mitchel Humpherys (1):
> iommu/arm-smmu: fix bug in pmd construction
>
> Robin Murphy (2):
> iommu/arm-smmu: fix architecture version detection
> iommu/arm-smmu: support MMU-401
>
> Will Deacon (5):
> iommu/arm
OK ... at first glance the system seems to be operating "normally" except
for the errors every 4 seconds ... that is it's attached to and using the
iscsi target ...
Is this a problem in iommu OR the emulex driver??
On Thu, Sep 25, 2014 at 2:36 AM, Yijing Wang wrote:
> On 2014/9/25 5:56, Rob Ros
On Tue, Sep 09, 2014 at 06:45:45PM +0300, Laurent Pinchart wrote:
> The owner field is never set. Remove it.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/iommu/omap-iommu.c | 11 ---
> drivers/iommu/omap-iommu.h | 1 -
> 2 files changed, 12 deletions(-)
Applied this one to arm/o
On Thu, Sep 11, 2014 at 12:28:03PM +0200, Maurizio Lombardi wrote:
> under low memory conditions, alloc_pte() may return a NULL pointer.
> iommu_map_page() does not check it and will panic the system.
>
> Signed-off-by: Maurizio Lombardi
> ---
> drivers/iommu/amd_iommu.c | 3 +++
> 1 file change
On Thu, Sep 11, 2014 at 07:07:36PM +0530, Kiran Padwal wrote:
> Make of_device_id array const, because all OF functions handle it as const.
>
> Signed-off-by: Kiran Padwal
> ---
> drivers/iommu/arm-smmu.c |2 +-
> drivers/iommu/omap-iommu.c |2 +-
> drivers/iommu/tegra-gart.c |2 +-
On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote:
> This series is based Bjorn's pci/msi branch
> git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi
Is there a git tree for these patches?
>
> Currently, there are a lot of weak arch functions in MSI code.
> Thierry Re
On 9/25/2014 9:56 AM, Rob Roschewsk wrote:
> OK ... at first glance the system seems to be operating "normally"
> except for the errors every 4 seconds ... that is it's attached to and
> using the iscsi target ...
>
> Is this a problem in iommu OR the emulex driver??
Please make sure your BIOS
On Wed, Sep 24, 2014 at 10:21:23AM +0100, Will Deacon wrote:
> Some IOMMUs, such as the ARM SMMU, support two stages of translation.
> The idea behind such a scheme is to allow a guest operating system to
> use the IOMMU for DMA mappings in the first stage of translation, with
> the hypervisor then
On Thu, Sep 25, 2014 at 11:14:14AM +0800, Yijing Wang wrote:
> Commit 0e4ccb150 added two __weak arch functions arch_msix_mask_irq()
> and arch_msi_mask_irq() to fix a bug found when running xen in x86.
> Introduced these two funcntions make MSI code complex. And mask/unmask
"These two functions m
On Fri, Sep 19, 2014 at 10:03:00AM -0600, Alex Williamson wrote:
> We've had surprisingly little fallout from the DMA alias changes, but
> unfortunately one regression has popped up. We have an AMD system
> that seems to use the SATA controller to master transactions for the
> legacy IDE controlle
On Sun, Sep 21, 2014 at 01:58:24PM -0400, Mark Salter wrote:
> iommu_bus_init() registers a bus notifier on the given bus by using
> a statically defined notifier block:
>
> static struct notifier_block iommu_bus_nb = {
> .notifier_call = iommu_bus_notifier,
> };
>
> This same notif
On Thu, Sep 25, 2014 at 03:32:33PM +0100, Joerg Roedel wrote:
> On Wed, Sep 24, 2014 at 10:21:23AM +0100, Will Deacon wrote:
> > Some IOMMUs, such as the ARM SMMU, support two stages of translation.
> > The idea behind such a scheme is to allow a guest operating system to
> > use the IOMMU for DMA
Hi Alex,
On Wed, Sep 24, 2014 at 07:23:19PM +0100, Alex Williamson wrote:
> On Wed, 2014-09-24 at 10:21 +0100, Will Deacon wrote:
> > VFIO allows devices to be safely handed off to userspace by putting
> > them behind an IOMMU configured to ensure DMA and interrupt isolation.
> > This enables user
On Thu, 2014-09-25 at 16:47 +0200, Joerg Roedel wrote:
> On Sun, Sep 21, 2014 at 01:58:24PM -0400, Mark Salter wrote:
> > iommu_bus_init() registers a bus notifier on the given bus by using
> > a statically defined notifier block:
> >
> > static struct notifier_block iommu_bus_nb = {
> >
On Thu, Sep 25, 2014 at 03:48:55PM +0100, Liviu Dudau wrote:
> On Thu, Sep 25, 2014 at 09:42:36AM +0200, Thierry Reding wrote:
> > On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote:
> > > This series is based Bjorn's pci/msi branch
> > > git://git.kernel.org/pub/scm/linux/kernel/git/helga
On Mon, Aug 11, 2014 at 03:45:50PM -0700, Olav Haugan wrote:
> +static inline int iommu_map_sg(struct iommu_domain *domain, unsigned long
> iova,
> +struct scatterlist *sg, unsigned int nents,
> +int prot, unsigned long flags)
> +{
> + re
On Wed, Sep 17, 2014 at 05:32:19PM +0800, Yijing Wang wrote:
> Commit 71054d8841b4 ("x86, hpet: Introduce x86_msi_ops.setup_hpet_msi")
> introduced x86_msi_ops.setup_hpet_msi to setup hpet MSI irq
> when irq remapping enabled. This caused a regression of
> hpet MSI irq remapping.
>
> Original co
Hi,
On Tue, Sep 09, 2014 at 04:34:52PM +0800, Su, Friendy wrote:
> > The problem you describe here should also be fixed by this (simpler)
> > patch. Can you test this please?
>
> The running result of this patch is correct.
Okay, fine, thanks for testing. I queued this patch up for the next
merg
On Thu, Sep 25, 2014 at 09:42:36AM +0200, Thierry Reding wrote:
> On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote:
> > This series is based Bjorn's pci/msi branch
> > git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi
> >
> > Currently, there are a lot of weak arch f
On Thu, Sep 25, 2014 at 06:49:38PM +0200, Thierry Reding wrote:
> On Thu, Sep 25, 2014 at 03:48:55PM +0100, Liviu Dudau wrote:
> > On Thu, Sep 25, 2014 at 09:42:36AM +0200, Thierry Reding wrote:
> > > On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote:
> > > > This series is based Bjorn's
Hello,
This is version five of the patches I previously posted here:
RFCv1: http://permalink.gmane.org/gmane.linux.kernel.iommu/5552
RFCv2: http://permalink.gmane.org/gmane.linux.kernel.iommu/5700
v3: http://permalink.gmane.org/gmane.linux.kernel.iommu/6230
v4: http://permalink.gman
VFIO allows devices to be safely handed off to userspace by putting
them behind an IOMMU configured to ensure DMA and interrupt isolation.
This enables userspace KVM clients, such as kvmtool and qemu, to further
map the device into a virtual machine.
With IOMMUs such as the ARM SMMU, it is then po
Some IOMMUs, such as the ARM SMMU, support two stages of translation.
The idea behind such a scheme is to allow a guest operating system to
use the IOMMU for DMA mappings in the first stage of translation, with
the hypervisor then installing mappings in the second stage to provide
isolation of the
On Thu, Sep 25, 2014 at 11:43:35AM +0100, Marek Szyprowski wrote:
> On 2014-09-24 19:06, Will Deacon wrote:
> > On Tue, Sep 16, 2014 at 12:54:28PM +0100, Marek Szyprowski wrote:
> >> If device has no max_seg_size set, we assume that there is no limit and
> >> force it to DMA_BIT_MASK(32) to always
On 2014/9/25 15:06, Thierry Reding wrote:
> On Thu, Sep 25, 2014 at 11:14:12AM +0800, Yijing Wang wrote:
>> Currently, PCI drivers will initialize bus->msi in
>> pcibios_add_bus(). pcibios_add_bus() will be called
>> in every pci bus initialization. So the bus->msi
>> assignment in pci_alloc_child_
On 2014/9/25 15:15, Thierry Reding wrote:
> On Thu, Sep 25, 2014 at 11:14:11AM +0800, Yijing Wang wrote:
>> Msi_chip functions setup_irq/teardown_irq rarely use msi_chip
>> argument.
>
> That's not true. Out of the four drivers that you modify two use the
> parameter. And the two that don't probab
On 2014/9/25 15:19, Thierry Reding wrote:
> On Thu, Sep 25, 2014 at 11:14:13AM +0800, Yijing Wang wrote:
>> Currently, pcie-designware, pcie-rcar, pci-tegra drivers
>> use irq chip_data to save the msi_chip pointer. They
>> already call irq_set_chip_data() in their own MSI irq map
>> functions. So
On 2014/9/25 15:26, Thierry Reding wrote:
> On Thu, Sep 25, 2014 at 11:14:16AM +0800, Yijing Wang wrote:
>> Introduce weak arch_find_msi_chip() to find the match msi_chip.
>> Currently, MSI chip associates pci bus to msi_chip. Because in
>> ARM platform, there may be more than one MSI controller in
On 2014/9/25 15:34, Thierry Reding wrote:
> On Thu, Sep 25, 2014 at 11:14:22AM +0800, Yijing Wang wrote:
> [...]
>> diff --git a/arch/mips/pci/msi-octeon.c b/arch/mips/pci/msi-octeon.c
> [...]
>> @@ -132,12 +132,12 @@ msi_irq_allocated:
>> /* Make sure the search for available interrupts didn'
On 2014/9/25 15:38, Thierry Reding wrote:
> On Thu, Sep 25, 2014 at 11:14:27AM +0800, Yijing Wang wrote:
> [...]
>> diff --git a/arch/s390/pci/pci.c b/arch/s390/pci/pci.c
> [...]
>> @@ -358,7 +358,7 @@ static void zpci_irq_handler(struct airq_struct *airq)
>> }
>> }
>>
>> -int arch_setup_ms
On 2014/9/25 15:36, Thierry Reding wrote:
> On Thu, Sep 25, 2014 at 11:14:24AM +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.
>
> Nit: s/irq/IRQ/ in the above.
>
>> Signed-off-
On 2014/9/25 18:20, Thomas Gleixner wrote:
> On Thu, 25 Sep 2014, Thierry Reding wrote:
>
>> On Thu, Sep 25, 2014 at 11:14:11AM +0800, Yijing Wang wrote:
>>> Msi_chip functions setup_irq/teardown_irq rarely use msi_chip
>>> argument.
>>
>> That's not true. Out of the four drivers that you modify t
On 2014/9/25 15:37, Thierry Reding wrote:
> On Thu, Sep 25, 2014 at 11:14:25AM +0800, Yijing Wang wrote:
> [...]
>> diff --git a/arch/mips/pci/pci-xlr.c b/arch/mips/pci/pci-xlr.c
> [...]
>> @@ -214,11 +214,11 @@ static int get_irq_vector(const struct pci_dev *dev)
>> }
>>
>> #ifdef CONFIG_PCI_M
On 2014/9/25 18:38, Thomas Gleixner wrote:
> On Thu, 25 Sep 2014, Yijing Wang wrote:
>
>> Introduce weak arch_find_msi_chip() to find the match msi_chip.
>> Currently, MSI chip associates pci bus to msi_chip. Because in
>> ARM platform, there may be more than one MSI controller in system.
>> Assoc
On 2014/9/25 18:38, Thomas Gleixner wrote:
> On Thu, 25 Sep 2014, Yijing Wang wrote:
>
>> Introduce weak arch_find_msi_chip() to find the match msi_chip.
>> Currently, MSI chip associates pci bus to msi_chip. Because in
>> ARM platform, there may be more than one MSI controller in system.
>> Assoc
On 2014/9/25 22:23, Konrad Rzeszutek Wilk wrote:
> On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote:
>> This series is based Bjorn's pci/msi branch
>> git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi
>
> Is there a git tree for these patches?
Hi Konrad, my git tree
On 2014/9/25 22:33, Konrad Rzeszutek Wilk wrote:
> On Thu, Sep 25, 2014 at 11:14:14AM +0800, Yijing Wang wrote:
>> Commit 0e4ccb150 added two __weak arch functions arch_msix_mask_irq()
>> and arch_msi_mask_irq() to fix a bug found when running xen in x86.
>> Introduced these two funcntions make MSI
>> I am actually in disagreement with you, Thierry. I don't like the general
>> direction
>> of the patches, or at least I don't like the fact that we don't have a
>> portable
>> way of setting up the msi_chip without having to rely on weak architectural
>> hooks.
>
> Oh, good. That's actually
>> The PCI core can already deal with that. An MSI chip can be set per bus
>> and the weak pcibios_add_bus() can be used to set that. Often it might
>> not even be necessary to do it via pcibios_add_bus() if you create the
>> root bus directly, since you can attach the MSI chip at that time.
>
> B
51 matches
Mail list logo
