* [PATCH 2/2] powerpc/pseries: Fix SMP=n build of rng.c
From: Michael Ellerman @ 2013-11-20 0:05 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1384905902-18042-1-git-send-email-mpe@ellerman.id.au>
In commit a489043 "Implement arch_get_random_long() based on H_RANDOM" I
broke the SMP=n build. We were getting plpar_wrappers.h via spinlock.h
which breaks when SMP=n.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/platforms/pseries/rng.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/platforms/pseries/rng.c b/arch/powerpc/platforms/pseries/rng.c
index a702f1c..72a1027 100644
--- a/arch/powerpc/platforms/pseries/rng.c
+++ b/arch/powerpc/platforms/pseries/rng.c
@@ -13,6 +13,7 @@
#include <linux/of.h>
#include <asm/archrandom.h>
#include <asm/machdep.h>
+#include <asm/plpar_wrappers.h>
static int pseries_get_random_long(unsigned long *v)
--
1.8.3.2
^ permalink raw reply related
* Re: [RFC PATCH powerpc] Fix a dma_mask issue of vio
From: Benjamin Herrenschmidt @ 2013-11-20 1:28 UTC (permalink / raw)
To: Li Zhong; +Cc: Paul Mackerras, PowerPC email list, rmk+kernel
In-Reply-To: <1384848697.2511.17.camel@ThinkPad-T5421>
On Tue, 2013-11-19 at 16:11 +0800, Li Zhong wrote:
> I encountered following issue:
> [ 0.283035] ibmvscsi 30000015: couldn't initialize event pool
> [ 5.688822] ibmvscsi: probe of 30000015 failed with error -1
>
> which prevents the storage from being recognized, and the machine from
> booting.
>
> After some digging, it seems that it is caused by commit 4886c399da
>
> as dma_mask pointer in viodev->dev is not set, so in
> dma_set_mask_and_coherent(), dma_set_coherent_mask() is not called
> because dma_set_mask(), which is dma_set_mask_pSeriesLP() returned EIO.
> While before the commit, dma_set_coherent_mask() is always called.
>
> I tried to replace dma_set_mask_and_coherent() with
> dma_coerce_mask_and_coherent(), and the machine could boot again.
>
> But I'm not sure whether this is the correct fix...
Russell, care to chime in ? I can't make sense of the semantics...
The original commit was fairly clear:
<<
Replace the following sequence:
dma_set_mask(dev, mask);
dma_set_coherent_mask(dev, mask);
with a call to the new helper dma_set_mask_and_coherent().
>>
It all makes sense so far ... but doesn't work for some odd reason,
and the "fix" uses a function whose name doesn't make much sense to
me ... what is the difference between "setting" and "coercing"
the mask ? And why doe replacing two "set" with a "set both" doesn't
work and require a coerce ?
I'm asking because I'm worried about breakage elsewhere...
Cheers,
Ben.
> ---
> arch/powerpc/kernel/vio.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c
> index e7d0c88..76a6482 100644
> --- a/arch/powerpc/kernel/vio.c
> +++ b/arch/powerpc/kernel/vio.c
> @@ -1419,7 +1419,7 @@ struct vio_dev *vio_register_device_node(struct device_node *of_node)
>
> /* needed to ensure proper operation of coherent allocations
> * later, in case driver doesn't set it explicitly */
> - dma_set_mask_and_coherent(&viodev->dev, DMA_BIT_MASK(64));
> + dma_coerce_mask_and_coherent(&viodev->dev, DMA_BIT_MASK(64));
> }
>
> /* register with generic device framework */
>
>
>
>
^ permalink raw reply
* Re: [RFC PATCH powerpc] Fix a dma_mask issue of vio
From: Li Zhong @ 2013-11-20 2:04 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Paul Mackerras, PowerPC email list, rmk+kernel
In-Reply-To: <1384910882.26969.57.camel@pasglop>
On Wed, 2013-11-20 at 12:28 +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2013-11-19 at 16:11 +0800, Li Zhong wrote:
> > I encountered following issue:
> > [ 0.283035] ibmvscsi 30000015: couldn't initialize event pool
> > [ 5.688822] ibmvscsi: probe of 30000015 failed with error -1
> >
> > which prevents the storage from being recognized, and the machine from
> > booting.
> >
> > After some digging, it seems that it is caused by commit 4886c399da
> >
> > as dma_mask pointer in viodev->dev is not set, so in
> > dma_set_mask_and_coherent(), dma_set_coherent_mask() is not called
> > because dma_set_mask(), which is dma_set_mask_pSeriesLP() returned EIO.
> > While before the commit, dma_set_coherent_mask() is always called.
> >
> > I tried to replace dma_set_mask_and_coherent() with
> > dma_coerce_mask_and_coherent(), and the machine could boot again.
> >
> > But I'm not sure whether this is the correct fix...
>
> Russell, care to chime in ? I can't make sense of the semantics...
>
> The original commit was fairly clear:
>
> <<
> Replace the following sequence:
>
> dma_set_mask(dev, mask);
> dma_set_coherent_mask(dev, mask);
>
> with a call to the new helper dma_set_mask_and_coherent().
> >>
>
> It all makes sense so far ... but doesn't work for some odd reason,
> and the "fix" uses a function whose name doesn't make much sense to
> me ... what is the difference between "setting" and "coercing"
> the mask ? And why doe replacing two "set" with a "set both" doesn't
> work and require a coerce ?
I think the difference is because the check of return value from
dma_set_mask in dma_coerce_mask_and_coherent():
--
int rc = dma_set_mask(dev, mask);
if (rc == 0)
dma_set_coherent_mask(dev, mask);
--
and in struct device {, dma_mask is a pointer, while coherent_dma_mask
is value (don't know why we have this difference).
And here for pseries, dma_set_mask() failed because the dma_mask pointer
still remains null.
And in dma_coerce_mask_and_coherent(), the dma_mask is set with the
address of coherent_dma_mask
--
dev->dma_mask = &dev->coherent_dma_mask;
--
Thanks, Zhong
>
> I'm asking because I'm worried about breakage elsewhere...
>
> Cheers,
> Ben.
>
> > ---
> > arch/powerpc/kernel/vio.c | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c
> > index e7d0c88..76a6482 100644
> > --- a/arch/powerpc/kernel/vio.c
> > +++ b/arch/powerpc/kernel/vio.c
> > @@ -1419,7 +1419,7 @@ struct vio_dev *vio_register_device_node(struct device_node *of_node)
> >
> > /* needed to ensure proper operation of coherent allocations
> > * later, in case driver doesn't set it explicitly */
> > - dma_set_mask_and_coherent(&viodev->dev, DMA_BIT_MASK(64));
> > + dma_coerce_mask_and_coherent(&viodev->dev, DMA_BIT_MASK(64));
> > }
> >
> > /* register with generic device framework */
> >
> >
> >
> >
>
>
^ permalink raw reply
* Re: [PATCH] powerpc/gpio: Fix the wrong GPIO input data on MPC8572/MPC8536
From: Liu Gang @ 2013-11-20 2:07 UTC (permalink / raw)
To: Anatolij Gustschin
Cc: linux-gpio, linus.walleij, linuxppc-dev, r61911, b07421
In-Reply-To: <20131119163230.70964d1f@crub>
On Tue, 2013-11-19 at 16:32 +0100, Anatolij Gustschin wrote:
> On Fri, 15 Nov 2013 15:16:29 +0800
> Liu Gang <Gang.Liu@freescale.com> wrote:
>
> > For MPC8572/MPC8536, the status of GPIOs defined as output
> > cannot be determined by reading GPDAT register, so the code
> > use shadow data register instead. But if the input pins are
> > asserted high, they will always read high due to the shadow
> > data, even if the pins are set to low.
>
> Could you please add a better description of the problem?
> I'm having some difficulties to understand the last sentence
> above. Does the issue appear if some pins were configured as
> inputs and were asserted high before booting the kernel, and
> therefore the shadow data has been initialized with these pin
> values?
>
> Or does the issue appear if some pin has been configured as output
> first and has been set to the high value, then reconfigured as
> input? Now reading the pin state will always return high even
> if the actual pin state is low?
>
> It seems the issue will appear in both cases. If so, please add
> this information to the commit message.
>
Yes, you are right.
I'll updated the description more clear.
> > val = in_be32(mm->regs + GPIO_DAT) & ~in_be32(mm->regs + GPIO_DIR);
> > + mpc8xxx_gc->data &= in_be32(mm->regs + GPIO_DIR);
>
> we can reduce one in_be32() call here, i.e.
>
> u32 out_mask;
> ...
> out_mask = in_be32(mm->regs + GPIO_DIR);
> val = in_be32(mm->regs + GPIO_DAT) & ~out_mask;
> mpc8xxx_gc->data &= out_mask;
>
> > return (val | mpc8xxx_gc->data) & mpc8xxx_gpio2mask(gpio);
> > }
>
> Thanks,
>
> Anatolij
>
Granted, it will be better to reduce one in_be32() call.
I'll improve the method based on your and Scott's comments.
Thanks
Liu Gang
^ permalink raw reply
* Re: [PATCH RESEND v4] powerpc: kvm: fix rare but potential deadlock scene
From: Liu ping fan @ 2013-11-20 2:42 UTC (permalink / raw)
To: Alexander Graf
Cc: Gleb Natapov, kvm@vger.kernel.org mailing list, kvm-ppc,
Paul Mackerras, Paolo Bonzini, linuxppc-dev
In-Reply-To: <C03A0DFC-4883-43CA-8EBB-0F80821C31BE@suse.de>
On Tue, Nov 19, 2013 at 6:39 PM, Alexander Graf <agraf@suse.de> wrote:
>
> On 19.11.2013, at 07:12, Liu Ping Fan <kernelfans@gmail.com> wrote:
>
>> Since kvmppc_hv_find_lock_hpte() is called from both virtmode and
>> realmode, so it can trigger the deadlock.
>>
>> Suppose the following scene:
>>
>> Two physical cpuM, cpuN, two VM instances A, B, each VM has a group of
>> vcpus.
>>
>> If on cpuM, vcpu_A_1 holds bitlock X (HPTE_V_HVLOCK), then is switched
>> out, and on cpuN, vcpu_A_2 try to lock X in realmode, then cpuN will be
>> caught in realmode for a long time.
>>
>> What makes things even worse if the following happens,
>> On cpuM, bitlockX is hold, on cpuN, Y is hold.
>> vcpu_B_2 try to lock Y on cpuM in realmode
>> vcpu_A_2 try to lock X on cpuN in realmode
>>
>> Oops! deadlock happens
>>
>> Signed-off-by: Liu Ping Fan <pingfank@linux.vnet.ibm.com>
>
> Any particular reason for the resend? The patch is already applied, no?
>
Oh, seems that I misunderstood your meaning. You said "Actually, I've
changed my mind and moved the patch to the for-3.13 branch instead.
Please make sure to CC kvm@vger on all patches you submit though". So
I think it is necessary to resend with cc kvm@vger
Regards,
Pingfan
^ permalink raw reply
* Re: [PATCH] powerpc/gpio: Fix the wrong GPIO input data on MPC8572/MPC8536
From: Liu Gang @ 2013-11-20 2:54 UTC (permalink / raw)
To: Scott Wood; +Cc: linux-gpio, linus.walleij, linuxppc-dev, r61911, b07421
In-Reply-To: <1384901494.1403.383.camel@snotra.buserror.net>
On Tue, 2013-11-19 at 16:51 -0600, Scott Wood wrote:
> > @@ -71,6 +71,7 @@ static int mpc8572_gpio_get(struct gpio_chip *gc, unsigned int gpio)
> > struct mpc8xxx_gpio_chip *mpc8xxx_gc = to_mpc8xxx_gpio_chip(mm);
> >
> > val = in_be32(mm->regs + GPIO_DAT) & ~in_be32(mm->regs + GPIO_DIR);
> > + mpc8xxx_gc->data &= in_be32(mm->regs + GPIO_DIR);
> >
> > return (val | mpc8xxx_gc->data) & mpc8xxx_gpio2mask(gpio);
> > }
>
> It seems odd to update ->data in a function that's supposed to be
> reading things... Perhaps it would be better to keep ->data in a good
> state from the beginning.
>
> -Scott
Yes, keeping the ->data in a good state from the beginning will be
better. But this will need more code in different functions to cover
all the scenarios.
First, we should check the direct of the pin in the function
"mpc8xxx_gpio_set", and clean the input bit in ->data after setting
operation.
In addition, we may change a output pin to input and then read the
input status. So we also should update the ->data in
"mpc8xxx_gpio_dir_in" function.
So maybe it's better to eliminate the effects of the ->data to the
input pins when reading the status, regardless of the possible changes
of the pins and the data.
Do you think so?
Best Regards,
Liu Gang
^ permalink raw reply
* [PATCH 24/34] PCI: use weak functions for MSI arch-specific functions
From: Richard Zhu @ 2013-11-20 2:50 UTC (permalink / raw)
To: r65037
Cc: linux-mips, linux-ia64, Heiko Carstens, Paul Mackerras,
H. Peter Anvin, sparclinux, linux-s390, Russell King, x86,
Ingo Molnar, Fenghua Yu, Jason Cooper, Chris Metcalf,
Thomas Gleixner, Thomas Petazzoni, Tony Luck, Ralf Baechle,
Martin Schwidefsky, linux390, linuxppc-dev, David S. Miller
In-Reply-To: <1384915853-31006-1-git-send-email-r65037@freescale.com>
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Until now, the MSI architecture-specific functions could be overloaded
using a fairly complex set of #define and compile-time
conditionals. In order to prepare for the introduction of the msi_chip
infrastructure, it is desirable to switch all those functions to use
the 'weak' mechanism. This commit converts all the architectures that
were overidding those MSI functions to use the new strategy.
Note that we keep two separate, non-weak, functions
default_teardown_msi_irqs() and default_restore_msi_irqs() for the
default behavior of the arch_teardown_msi_irqs() and
arch_restore_msi_irqs(), as the default behavior is needed by x86 PCI
code.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Tested-by: Daniel Price <daniel.price@gmail.com>
Tested-by: Thierry Reding <thierry.reding@gmail.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: linux390@de.ibm.com
Cc: linux-s390@vger.kernel.org
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: x86@kernel.org
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: linux-ia64@vger.kernel.org
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Cc: David S. Miller <davem@davemloft.net>
Cc: sparclinux@vger.kernel.org
Cc: Chris Metcalf <cmetcalf@tilera.com>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
---
arch/mips/include/asm/pci.h | 5 ----
arch/powerpc/include/asm/pci.h | 5 ----
arch/s390/include/asm/pci.h | 4 ---
arch/x86/include/asm/pci.h | 30 -------------------------
arch/x86/kernel/x86_init.c | 24 ++++++++++++++++++++
drivers/pci/msi.c | 48 ++++++++++++++++++++--------------------
include/linux/msi.h | 8 +++++-
7 files changed, 55 insertions(+), 69 deletions(-)
diff --git a/arch/mips/include/asm/pci.h b/arch/mips/include/asm/pci.h
index b8e24fd..031f4c1 100644
--- a/arch/mips/include/asm/pci.h
+++ b/arch/mips/include/asm/pci.h
@@ -137,11 +137,6 @@ static inline int pci_get_legacy_ide_irq(struct pci_dev *dev, int channel)
return channel ? 15 : 14;
}
-#ifdef CONFIG_CPU_CAVIUM_OCTEON
-/* MSI arch hook for OCTEON */
-#define arch_setup_msi_irqs arch_setup_msi_irqs
-#endif
-
extern char * (*pcibios_plat_setup)(char *str);
#ifdef CONFIG_OF
diff --git a/arch/powerpc/include/asm/pci.h b/arch/powerpc/include/asm/pci.h
index 6653f27..95145a1 100644
--- a/arch/powerpc/include/asm/pci.h
+++ b/arch/powerpc/include/asm/pci.h
@@ -113,11 +113,6 @@ extern int pci_domain_nr(struct pci_bus *bus);
/* Decide whether to display the domain number in /proc */
extern int pci_proc_domain(struct pci_bus *bus);
-/* MSI arch hooks */
-#define arch_setup_msi_irqs arch_setup_msi_irqs
-#define arch_teardown_msi_irqs arch_teardown_msi_irqs
-#define arch_msi_check_device arch_msi_check_device
-
struct vm_area_struct;
/* Map a range of PCI memory or I/O space for a device into user space */
int pci_mmap_page_range(struct pci_dev *pdev, struct vm_area_struct *vma,
diff --git a/arch/s390/include/asm/pci.h b/arch/s390/include/asm/pci.h
index 6c18012..8641e8d 100644
--- a/arch/s390/include/asm/pci.h
+++ b/arch/s390/include/asm/pci.h
@@ -21,10 +21,6 @@ void pci_iounmap(struct pci_dev *, void __iomem *);
int pci_domain_nr(struct pci_bus *);
int pci_proc_domain(struct pci_bus *);
-/* MSI arch hooks */
-#define arch_setup_msi_irqs arch_setup_msi_irqs
-#define arch_teardown_msi_irqs arch_teardown_msi_irqs
-
#define ZPCI_BUS_NR 0 /* default bus number */
#define ZPCI_DEVFN 0 /* default device number */
diff --git a/arch/x86/include/asm/pci.h b/arch/x86/include/asm/pci.h
index d9e9e6c..7d74432 100644
--- a/arch/x86/include/asm/pci.h
+++ b/arch/x86/include/asm/pci.h
@@ -100,29 +100,6 @@ static inline void early_quirks(void) { }
extern void pci_iommu_alloc(void);
#ifdef CONFIG_PCI_MSI
-/* MSI arch specific hooks */
-static inline int x86_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
-{
- return x86_msi.setup_msi_irqs(dev, nvec, type);
-}
-
-static inline void x86_teardown_msi_irqs(struct pci_dev *dev)
-{
- x86_msi.teardown_msi_irqs(dev);
-}
-
-static inline void x86_teardown_msi_irq(unsigned int irq)
-{
- x86_msi.teardown_msi_irq(irq);
-}
-static inline void x86_restore_msi_irqs(struct pci_dev *dev, int irq)
-{
- x86_msi.restore_msi_irqs(dev, irq);
-}
-#define arch_setup_msi_irqs x86_setup_msi_irqs
-#define arch_teardown_msi_irqs x86_teardown_msi_irqs
-#define arch_teardown_msi_irq x86_teardown_msi_irq
-#define arch_restore_msi_irqs x86_restore_msi_irqs
/* implemented in arch/x86/kernel/apic/io_apic. */
struct msi_desc;
int native_setup_msi_irqs(struct pci_dev *dev, int nvec, int type);
@@ -130,16 +107,9 @@ void native_teardown_msi_irq(unsigned int irq);
void native_restore_msi_irqs(struct pci_dev *dev, int irq);
int setup_msi_irq(struct pci_dev *dev, struct msi_desc *msidesc,
unsigned int irq_base, unsigned int irq_offset);
-/* default to the implementation in drivers/lib/msi.c */
-#define HAVE_DEFAULT_MSI_TEARDOWN_IRQS
-#define HAVE_DEFAULT_MSI_RESTORE_IRQS
-void default_teardown_msi_irqs(struct pci_dev *dev);
-void default_restore_msi_irqs(struct pci_dev *dev, int irq);
#else
#define native_setup_msi_irqs NULL
#define native_teardown_msi_irq NULL
-#define default_teardown_msi_irqs NULL
-#define default_restore_msi_irqs NULL
#endif
#define PCI_DMA_BUS_IS_PHYS (dma_ops->is_phys)
diff --git a/arch/x86/kernel/x86_init.c b/arch/x86/kernel/x86_init.c
index 45a14db..5587f99 100644
--- a/arch/x86/kernel/x86_init.c
+++ b/arch/x86/kernel/x86_init.c
@@ -107,6 +107,8 @@ struct x86_platform_ops x86_platform = {
};
EXPORT_SYMBOL_GPL(x86_platform);
+
+#if defined(CONFIG_PCI_MSI)
struct x86_msi_ops x86_msi = {
.setup_msi_irqs = native_setup_msi_irqs,
.compose_msi_msg = native_compose_msi_msg,
@@ -116,6 +118,28 @@ struct x86_msi_ops x86_msi = {
.setup_hpet_msi = default_setup_hpet_msi,
};
+/* MSI arch specific hooks */
+int arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
+{
+ return x86_msi.setup_msi_irqs(dev, nvec, type);
+}
+
+void arch_teardown_msi_irqs(struct pci_dev *dev)
+{
+ x86_msi.teardown_msi_irqs(dev);
+}
+
+void arch_teardown_msi_irq(unsigned int irq)
+{
+ x86_msi.teardown_msi_irq(irq);
+}
+
+void arch_restore_msi_irqs(struct pci_dev *dev, int irq)
+{
+ x86_msi.restore_msi_irqs(dev, irq);
+}
+#endif
+
struct x86_io_apic_ops x86_io_apic_ops = {
.init = native_io_apic_init_mappings,
.read = native_io_apic_read,
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index aca7578..823c386 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -30,20 +30,21 @@ static int pci_msi_enable = 1;
/* Arch hooks */
-#ifndef arch_msi_check_device
-int arch_msi_check_device(struct pci_dev *dev, int nvec, int type)
+int __weak arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc)
{
- return 0;
+ return -EINVAL;
}
-#endif
-#ifndef arch_setup_msi_irqs
-# define arch_setup_msi_irqs default_setup_msi_irqs
-# define HAVE_DEFAULT_MSI_SETUP_IRQS
-#endif
+void __weak arch_teardown_msi_irq(unsigned int irq)
+{
+}
-#ifdef HAVE_DEFAULT_MSI_SETUP_IRQS
-int default_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
+int __weak arch_msi_check_device(struct pci_dev *dev, int nvec, int type)
+{
+ return 0;
+}
+
+int __weak arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
{
struct msi_desc *entry;
int ret;
@@ -65,14 +66,11 @@ int default_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
return 0;
}
-#endif
-
-#ifndef arch_teardown_msi_irqs
-# define arch_teardown_msi_irqs default_teardown_msi_irqs
-# define HAVE_DEFAULT_MSI_TEARDOWN_IRQS
-#endif
-#ifdef HAVE_DEFAULT_MSI_TEARDOWN_IRQS
+/*
+ * We have a default implementation available as a separate non-weak
+ * function, as it is used by the Xen x86 PCI code
+ */
void default_teardown_msi_irqs(struct pci_dev *dev)
{
struct msi_desc *entry;
@@ -89,14 +87,12 @@ void default_teardown_msi_irqs(struct pci_dev *dev)
arch_teardown_msi_irq(entry->irq + i);
}
}
-#endif
-#ifndef arch_restore_msi_irqs
-# define arch_restore_msi_irqs default_restore_msi_irqs
-# define HAVE_DEFAULT_MSI_RESTORE_IRQS
-#endif
+void __weak arch_teardown_msi_irqs(struct pci_dev *dev)
+{
+ return default_teardown_msi_irqs(dev);
+}
-#ifdef HAVE_DEFAULT_MSI_RESTORE_IRQS
void default_restore_msi_irqs(struct pci_dev *dev, int irq)
{
struct msi_desc *entry;
@@ -114,7 +110,11 @@ void default_restore_msi_irqs(struct pci_dev *dev, int irq)
if (entry)
write_msi_msg(irq, &entry->msg);
}
-#endif
+
+void __weak arch_restore_msi_irqs(struct pci_dev *dev, int irq)
+{
+ return default_restore_msi_irqs(dev, irq);
+}
static void msi_set_enable(struct pci_dev *dev, int enable)
{
diff --git a/include/linux/msi.h b/include/linux/msi.h
index ee66f3a..271dfd1 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -51,12 +51,18 @@ struct msi_desc {
};
/*
- * The arch hook for setup up msi irqs
+ * The arch hooks to setup up msi irqs. Those functions are
+ * implemented as weak symbols so that they /can/ be overriden by
+ * architecture specific code if needed.
*/
int arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc);
void arch_teardown_msi_irq(unsigned int irq);
int arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type);
void arch_teardown_msi_irqs(struct pci_dev *dev);
int arch_msi_check_device(struct pci_dev* dev, int nvec, int type);
+void arch_restore_msi_irqs(struct pci_dev *dev, int irq);
+
+void default_teardown_msi_irqs(struct pci_dev *dev);
+void default_restore_msi_irqs(struct pci_dev *dev, int irq);
#endif /* LINUX_MSI_H */
--
1.7.8
^ permalink raw reply related
* Recall: [PATCH 24/34] PCI: use weak functions for MSI arch-specific functions
From: Richard Zhu @ 2013-11-20 3:23 UTC (permalink / raw)
To: Richard Zhu
Cc: linux-mips@linux-mips.org, linux-ia64@vger.kernel.org,
Heiko Carstens, Paul Mackerras, H. Peter Anvin,
sparclinux@vger.kernel.org, linux-s390@vger.kernel.org,
Russell King, x86@kernel.org, Ingo Molnar, Fenghua Yu,
Jason Cooper, Chris Metcalf, Thomas Gleixner, Thomas Petazzoni,
Tony Luck, Ralf Baechle, Martin Schwidefsky, linux390@de.ibm.com,
linuxppc-dev@lists.ozlabs.org, David S. Miller
Zhu Richard-R65037 would like to recall the message, "[PATCH 24/34] PCI: us=
e weak functions for MSI arch-specific functions".=
^ permalink raw reply
* RE: [PATCHv2 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.
From: Li Xiubo @ 2013-11-20 3:37 UTC (permalink / raw)
To: Guangyu Chen
Cc: mark.rutland@arm.com, alsa-devel@alsa-project.org,
linux-doc@vger.kernel.org, tiwai@suse.de, timur@tabi.org,
perex@perex.cz, Huan Wang, LW@KARO-electronics.de,
linux@arm.linux.org.uk, Shawn Guo, grant.likely@linaro.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
ian.campbell@citrix.com, pawel.moll@arm.com,
swarren@wwwdotorg.org, rob.herring@calxeda.com,
broonie@kernel.org, Zhengxiong Jin, oskar@scara.com,
Fabio Estevam, lgirdwood@gmail.com, linux-kernel@vger.kernel.org,
rob@landley.net, shawn.guo@linaro.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20131104043338.GA2345@MrMyself>
=20
> The udelay just doesn't make sense to what you are talking about.
>=20
> Does SAI really need 10us delay between two register-updating?
>=20
No, this is not must be.
> We basically use udelay only if the IP hardware actually needs it: some
> IP needs time to boot itself up after doing software reset for example.
> But it doesn't look reasonable to me by using udelay to make sure "the
> last enabled".
>=20
> And from the 'Synchronous mode' you just provided, there're another issue=
:
>=20
> + case SNDRV_PCM_TRIGGER_START:
> + case SNDRV_PCM_TRIGGER_RESUME:
> + case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
> + tcsr |=3D FSL_SAI_CSR_TERE;
> + rcsr |=3D FSL_SAI_CSR_TERE;
> + writel(rcsr, sai->base + FSL_SAI_RCSR);
> + udelay(10);
> + writel(tcsr, sai->base + FSL_SAI_TCSR);
> + break;
> +
> + case SNDRV_PCM_TRIGGER_STOP:
> + case SNDRV_PCM_TRIGGER_SUSPEND:
> + case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
> + if (!(dai->playback_active || dai->capture_active)) {
> + tcsr &=3D ~FSL_SAI_CSR_TERE;
> + rcsr &=3D ~FSL_SAI_CSR_TERE;
> + }
> + writel(rcsr, sai->base + FSL_SAI_RCSR);
> + udelay(10);
> + writel(tcsr, sai->base + FSL_SAI_TCSR);
> + break;
>=20
> ISSUE 1: You might make sure transmitter is the last enabled.
> However, it's not the first disabled. Is this okay?
>=20
Yes, this is just programming mistake. I'll revise it.
In this case the transmitter should be the last enabled and the first disab=
led.
> ISSUE 2: There are two cases listed in 'Synchronous mode'.
> However, your driver doesn't take care of them.
> The SAI's synchronous mode looks like more flexible
> than SSI's. The driver needs to be more sophisticated
> so that it can handle multiple cases when TX/RX clocks
> are controlled by either TX or RX, and surely, the
> asynchronous mode as well.
>=20
Because in Vybrid the transmitter bit clock and frame sync are to be used b=
y both the transmitter and receiver, and only this case can be used here, s=
o now I only handle this case.
>=20
> And there's another personal tip: I think you can first try to focus on
> this SAI driver and pend the others. There might be two many things you
> need to refine if you are doing them at the same time.
>=20
I'll implement them later if needed.
--
Best Regards,
Xiubo
^ permalink raw reply
* Re: [PATCHv2 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.
From: Nicolin Chen @ 2013-11-20 3:37 UTC (permalink / raw)
To: Xiubo Li-B47053
Cc: mark.rutland@arm.com, alsa-devel@alsa-project.org,
linux-doc@vger.kernel.org, tiwai@suse.de, timur@tabi.org,
perex@perex.cz, Wang Huan-B18965, LW@KARO-electronics.de,
linux@arm.linux.org.uk, Guo Shawn-R65073, grant.likely@linaro.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
ian.campbell@citrix.com, pawel.moll@arm.com,
swarren@wwwdotorg.org, rob.herring@calxeda.com,
broonie@kernel.org, Jin Zhengxiong-R64188, oskar@scara.com,
Estevam Fabio-R49496, lgirdwood@gmail.com,
linux-kernel@vger.kernel.org, rob@landley.net,
Chen Guangyu-B42378, shawn.guo@linaro.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1DD289F6464F0949A2FCA5AA6DC23F828AE980@039-SN2MPN1-012.039d.mgd.msft.net>
On Wed, Nov 20, 2013 at 11:37:45AM +0800, Xiubo Li-B47053 wrote:
>
> > The udelay just doesn't make sense to what you are talking about.
> >
> > Does SAI really need 10us delay between two register-updating?
> >
>
> No, this is not must be.
Then you should explain in your comments why you really put it here or just
drop it if it's just a mistake.
> > We basically use udelay only if the IP hardware actually needs it: some
> > IP needs time to boot itself up after doing software reset for example.
> > But it doesn't look reasonable to me by using udelay to make sure "the
> > last enabled".
> >
> > And from the 'Synchronous mode' you just provided, there're another issue:
> >
> > + case SNDRV_PCM_TRIGGER_START:
> > + case SNDRV_PCM_TRIGGER_RESUME:
> > + case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
> > + tcsr |= FSL_SAI_CSR_TERE;
> > + rcsr |= FSL_SAI_CSR_TERE;
> > + writel(rcsr, sai->base + FSL_SAI_RCSR);
> > + udelay(10);
> > + writel(tcsr, sai->base + FSL_SAI_TCSR);
> > + break;
> > +
> > + case SNDRV_PCM_TRIGGER_STOP:
> > + case SNDRV_PCM_TRIGGER_SUSPEND:
> > + case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
> > + if (!(dai->playback_active || dai->capture_active)) {
> > + tcsr &= ~FSL_SAI_CSR_TERE;
> > + rcsr &= ~FSL_SAI_CSR_TERE;
> > + }
> > + writel(rcsr, sai->base + FSL_SAI_RCSR);
> > + udelay(10);
> > + writel(tcsr, sai->base + FSL_SAI_TCSR);
> > + break;
> >
> > ISSUE 1: You might make sure transmitter is the last enabled.
> > However, it's not the first disabled. Is this okay?
> >
>
> Yes, this is just programming mistake. I'll revise it.
>
> In this case the transmitter should be the last enabled and the first disabled.
>
>
> > ISSUE 2: There are two cases listed in 'Synchronous mode'.
> > However, your driver doesn't take care of them.
> > The SAI's synchronous mode looks like more flexible
> > than SSI's. The driver needs to be more sophisticated
> > so that it can handle multiple cases when TX/RX clocks
> > are controlled by either TX or RX, and surely, the
> > asynchronous mode as well.
> >
>
> Because in Vybrid the transmitter bit clock and frame sync are to be used by
> both the transmitter and receiver, and only this case can be used here, so
> now I only handle this case.
It's fairly okay if adding explicit comments to indicate that currently the
driver only supports its Synchronous mode with clocks controlled by TX only.
Best,
Nicolin Chen
> >
> > And there's another personal tip: I think you can first try to focus on
> > this SAI driver and pend the others. There might be two many things you
> > need to refine if you are doing them at the same time.
> >
>
> I'll implement them later if needed.
>
>
> --
> Best Regards,
> Xiubo
>
^ permalink raw reply
* RE: [PATCHv2 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.
From: Li Xiubo @ 2013-11-20 4:16 UTC (permalink / raw)
To: Guangyu Chen
Cc: mark.rutland@arm.com, alsa-devel@alsa-project.org,
linux-doc@vger.kernel.org, tiwai@suse.de, timur@tabi.org,
perex@perex.cz, Huan Wang, LW@KARO-electronics.de,
linux@arm.linux.org.uk, Shawn Guo, grant.likely@linaro.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
ian.campbell@citrix.com, pawel.moll@arm.com,
swarren@wwwdotorg.org, rob.herring@calxeda.com,
broonie@kernel.org, Zhengxiong Jin, oskar@scara.com,
Fabio Estevam, lgirdwood@gmail.com, linux-kernel@vger.kernel.org,
rob@landley.net, shawn.guo@linaro.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20131120033745.GD11009@MrMyself>
> > > The udelay just doesn't make sense to what you are talking about.
> > >
> > > Does SAI really need 10us delay between two register-updating?
> > >
> >
> > No, this is not must be.
>=20
> Then you should explain in your comments why you really put it here or
> just drop it if it's just a mistake.
>=20
The udelay will be removed then.
> > > ISSUE 2: There are two cases listed in 'Synchronous mode'.
> > > However, your driver doesn't take care of them.
> > > The SAI's synchronous mode looks like more flexible
> > > than SSI's. The driver needs to be more sophisticated
> > > so that it can handle multiple cases when TX/RX clocks
> > > are controlled by either TX or RX, and surely, the
> > > asynchronous mode as well.
> > >
> >
> > Because in Vybrid the transmitter bit clock and frame sync are to be
> > used by both the transmitter and receiver, and only this case can be
> > used here, so now I only handle this case.
>=20
> It's fairly okay if adding explicit comments to indicate that currently
> the driver only supports its Synchronous mode with clocks controlled by
> TX only.
>=20
Just think, on other platforms maybe only the Rx's clock is available.
Thus I think there should be one DT property to control this, and then the =
SAI driver can be more flexible.
Or could you give me some more practical ideas ?
--
Best Regards,
Xiubo
^ permalink raw reply
* Re: [PATCH -V2 1/5] powerpc: Use HPTE constants when updating hpte bits
From: Paul Mackerras @ 2013-11-20 4:35 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: linuxppc-dev, linux-mm
In-Reply-To: <1384766893-10189-2-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
On Mon, Nov 18, 2013 at 02:58:09PM +0530, Aneesh Kumar K.V wrote:
> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>
> Even though we have same value for linux PTE bits and hash PTE pits
bits, not pits :)
> use the hash pte bits wen updating hash pte
when, not wen
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
If you fix the spelling errors in the patch description:
Acked-by: Paul Mackerras <paulus@samba.org>
^ permalink raw reply
* Re: [PATCH -V2 2/5] powerpc: Free up _PAGE_COHERENCE for numa fault use later
From: Paul Mackerras @ 2013-11-20 4:35 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: linuxppc-dev, linux-mm
In-Reply-To: <1384766893-10189-3-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
On Mon, Nov 18, 2013 at 02:58:10PM +0530, Aneesh Kumar K.V wrote:
> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>
> Set memory coherence always on hash64 config. If
> a platform cannot have memory coherence always set they
> can infer that from _PAGE_NO_CACHE and _PAGE_WRITETHRU
> like in lpar. So we dont' really need a separate bit
> for tracking _PAGE_COHERENCE.
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Acked-by: Paul Mackerras <paulus@samba.org>
^ permalink raw reply
* Re: [PATCH -V2 4/5] powerpc: mm: Only check for _PAGE_PRESENT in set_pte/pmd functions
From: Paul Mackerras @ 2013-11-20 4:36 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: linuxppc-dev, linux-mm
In-Reply-To: <1384766893-10189-5-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
On Mon, Nov 18, 2013 at 02:58:12PM +0530, Aneesh Kumar K.V wrote:
> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>
> We want to make sure we don't use these function when updating a pte
> or pmd entry that have a valid hpte entry, because these functions
> don't invalidate them. So limit the check to _PAGE_PRESENT bit.
> Numafault core changes use these functions for updating _PAGE_NUMA bits.
> That should be ok because when _PAGE_NUMA is set we can be sure that
> hpte entries are not present.
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Acked-by: Paul Mackerras <paulus@samba.org>
^ permalink raw reply
* Re: [PATCH -V2 5/5] powerpc: mm: book3s: Enable _PAGE_NUMA for book3s
From: Paul Mackerras @ 2013-11-20 4:37 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: linuxppc-dev, linux-mm
In-Reply-To: <1384766893-10189-6-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
On Mon, Nov 18, 2013 at 02:58:13PM +0530, Aneesh Kumar K.V wrote:
> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>
> We steal the _PAGE_COHERENCE bit and use that for indicating NUMA ptes.
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Acked-by: Paul Mackerras <paulus@samba.org>
^ permalink raw reply
* [PATCH] powerpc/signals: Mark VSX not saved with small contexts
From: Michael Neuling @ 2013-11-20 5:18 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Carlos O'Donell, Steve Best, linuxppc-dev, Michael Neuling,
Haren Myneni
The VSX MSR bit in the user context indicates if the context contains VSX
state. Currently we set this when the process has touched VSX at any stage.
Unfortunately, if the user has not provided enough space to save the VSX state,
we can't save it but we currently still set the MSR VSX bit.
This patch changes this to clear the MSR VSX bit when the user doesn't provide
enough space. This indicates that there is no valid VSX state in the user
context.
This is needed to support get/set/make/swapcontext for applications that use
VSX but only provide a small context. For example, getcontext in glibc
provides a smaller context since the VSX registers don't need to be saved over
the glibc function call. But since the program calling getcontext may have
used VSX, the kernel currently says the VSX state is valid when it's not. If
the returned context is then used in setcontext (ie. a small context without
VSX but with MSR VSX set), the kernel will refuse the context. This situation
has been reported by the glibc community.
Based on patch from Carlos O'Donell.
Tested-by: Haren Myneni <haren@linux.vnet.ibm.com>
Signed-off-by: Michael Neuling <mikey@neuling.org>
Cc: stable@vger.kernel.org
---
arch/powerpc/kernel/signal_32.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/signal_32.c b/arch/powerpc/kernel/signal_32.c
index 749778e..1844298 100644
--- a/arch/powerpc/kernel/signal_32.c
+++ b/arch/powerpc/kernel/signal_32.c
@@ -457,7 +457,15 @@ static int save_user_regs(struct pt_regs *regs, struct mcontext __user *frame,
if (copy_vsx_to_user(&frame->mc_vsregs, current))
return 1;
msr |= MSR_VSX;
- }
+ } else if (!ctx_has_vsx_region)
+ /*
+ * With a small context structure we can't hold the VSX
+ * registers, hence clear the MSR value to indicate the state
+ * was not saved.
+ */
+ msr &= ~MSR_VSX;
+
+
#endif /* CONFIG_VSX */
#ifdef CONFIG_SPE
/* save spe registers */
--
1.8.3.2
^ permalink raw reply related
* [PATCH v3] KVM: PPC: vfio kvm device: support spapr tce
From: Alexey Kardashevskiy @ 2013-11-20 5:18 UTC (permalink / raw)
To: Alex Williamson
Cc: Alexey Kardashevskiy, linuxppc-dev, kvm-ppc, linux-kernel, kvm
In addition to the external VFIO user API, a VFIO KVM device
has been introduced recently.
sPAPR TCE IOMMU is para-virtualized and the guest does map/unmap
via hypercalls which take a logical bus id (LIOBN) as a target IOMMU
identifier. LIOBNs are made up and linked to IOMMU groups by the user
space. In order to accelerate IOMMU operations in the KVM, we need
to tell KVM the information about LIOBN-to-group mapping.
For that, a new KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE_LIOBN parameter
is added. It accepts a pair of a VFIO group fd and LIOBN.
This also adds a new kvm_vfio_find_group_by_liobn() function which
receives kvm struct, LIOBN and a callback. As it increases the IOMMU
group use counter, the KVMr is required to pass a callback which
called when the VFIO group is about to be removed VFIO-KVM tracking so
the KVM is able to call iommu_group_put() to release the IOMMU group.
The KVM uses kvm_vfio_find_group_by_liobn() once per KVM run and caches
the result in kvm_arch. iommu_group_put() for all groups will be called
when KVM finishes (in the SPAPR TCE in KVM enablement patch).
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
Changes:
v3:
* total rework
* added a release callback into kvm_vfio_find_group_by_liobn so now
the user of the API can get a notification if the group is about to
disappear
---
Documentation/virtual/kvm/devices/vfio.txt | 19 ++++-
arch/powerpc/kvm/Kconfig | 1 +
arch/powerpc/kvm/Makefile | 3 +
include/linux/kvm_host.h | 18 +++++
include/uapi/linux/kvm.h | 7 ++
virt/kvm/vfio.c | 116 ++++++++++++++++++++++++++++-
6 files changed, 161 insertions(+), 3 deletions(-)
diff --git a/Documentation/virtual/kvm/devices/vfio.txt b/Documentation/virtual/kvm/devices/vfio.txt
index ef51740..7ecb3b2 100644
--- a/Documentation/virtual/kvm/devices/vfio.txt
+++ b/Documentation/virtual/kvm/devices/vfio.txt
@@ -16,7 +16,22 @@ Groups:
KVM_DEV_VFIO_GROUP attributes:
KVM_DEV_VFIO_GROUP_ADD: Add a VFIO group to VFIO-KVM device tracking
+ kvm_device_attr.addr points to an int32_t file descriptor
+ for the VFIO group.
+
KVM_DEV_VFIO_GROUP_DEL: Remove a VFIO group from VFIO-KVM device tracking
+ kvm_device_attr.addr points to an int32_t file descriptor
+ for the VFIO group.
+
+ KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE_LIOBN: sets a liobn for a VFIO group
+ kvm_device_attr.addr points to a struct:
+ struct kvm_vfio_spapr_tce_liobn {
+ __u32 argsz;
+ __u32 fd;
+ __u32 liobn;
+ };
+ where
+ @argsz is a struct size;
+ @fd is a file descriptor for a VFIO group;
+ @liobn is a logical bus id to be associated with the group.
-For each, kvm_device_attr.addr points to an int32_t file descriptor
-for the VFIO group.
diff --git a/arch/powerpc/kvm/Kconfig b/arch/powerpc/kvm/Kconfig
index 61b3535..d1b7f64 100644
--- a/arch/powerpc/kvm/Kconfig
+++ b/arch/powerpc/kvm/Kconfig
@@ -60,6 +60,7 @@ config KVM_BOOK3S_64
select KVM_BOOK3S_64_HANDLER
select KVM
select SPAPR_TCE_IOMMU
+ select KVM_VFIO
---help---
Support running unmodified book3s_64 and book3s_32 guest kernels
in virtual machines on book3s_64 host processors.
diff --git a/arch/powerpc/kvm/Makefile b/arch/powerpc/kvm/Makefile
index 6646c95..2438d2e 100644
--- a/arch/powerpc/kvm/Makefile
+++ b/arch/powerpc/kvm/Makefile
@@ -87,6 +87,9 @@ kvm-book3s_64-builtin-objs-$(CONFIG_KVM_BOOK3S_64_HV) := \
kvm-book3s_64-objs-$(CONFIG_KVM_XICS) += \
book3s_xics.o
+kvm-book3s_64-objs-$(CONFIG_KVM_VFIO) += \
+ $(KVM)/vfio.o \
+
kvm-book3s_64-module-objs := \
$(KVM)/kvm_main.o \
$(KVM)/eventfd.o \
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 88ff96a..1d2ad5e 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -1112,5 +1112,23 @@ static inline bool kvm_vcpu_eligible_for_directed_yield(struct kvm_vcpu *vcpu)
}
#endif /* CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT */
+
+typedef void (*kvm_vfio_release_group_callback)(struct kvm *kvm,
+ unsigned long liobn);
+
+#if defined(CONFIG_KVM_VFIO) && defined(CONFIG_SPAPR_TCE_IOMMU)
+
+extern struct iommu_group *kvm_vfio_find_group_by_liobn(struct kvm *kvm,
+ unsigned long liobn, kvm_vfio_release_group_callback cb);
+
+#else
+
+static inline struct iommu_group *kvm_vfio_find_group_by_liobn(struct kvm *kvm,
+ unsigned long liobn, ikvm_vfio_release_group_callback cb)
+{
+ return NULL;
+}
+#endif /* CONFIG_KVM_VFIO && CONFIG_SPAPR_TCE_IOMMU */
+
#endif
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 7c1a349..3d77dde 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -847,6 +847,13 @@ struct kvm_device_attr {
#define KVM_DEV_VFIO_GROUP 1
#define KVM_DEV_VFIO_GROUP_ADD 1
#define KVM_DEV_VFIO_GROUP_DEL 2
+#define KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE_LIOBN 3
+
+struct kvm_vfio_spapr_tce_liobn {
+ __u32 argsz;
+ __u32 fd;
+ __u32 liobn;
+};
/*
* ioctls for VM fds
diff --git a/virt/kvm/vfio.c b/virt/kvm/vfio.c
index ca4260e..448910d 100644
--- a/virt/kvm/vfio.c
+++ b/virt/kvm/vfio.c
@@ -22,6 +22,12 @@
struct kvm_vfio_group {
struct list_head node;
struct vfio_group *vfio_group;
+#ifdef CONFIG_SPAPR_TCE_IOMMU
+ struct {
+ unsigned long liobn;
+ kvm_vfio_release_group_callback cb;
+ } spapr_tce;
+#endif
};
struct kvm_vfio {
@@ -59,6 +65,51 @@ static void kvm_vfio_group_put_external_user(struct vfio_group *vfio_group)
symbol_put(vfio_group_put_external_user);
}
+#ifdef CONFIG_SPAPR_TCE_IOMMU
+struct iommu_group *kvm_vfio_find_group_by_liobn(struct kvm *kvm,
+ unsigned long liobn, kvm_vfio_release_group_callback cb)
+{
+ struct kvm_vfio_group *kvg;
+ int group_id;
+ struct iommu_group *grp;
+ struct kvm_vfio *kv = NULL;
+ struct kvm_device *tmp;
+
+ if (!cb)
+ return NULL;
+
+ /* Find a VFIO KVM device */
+ list_for_each_entry(tmp, &kvm->devices, vm_node) {
+ if (tmp->ops != &kvm_vfio_ops)
+ continue;
+
+ kv = tmp->private;
+ break;
+ }
+
+ if (!kv)
+ return NULL;
+
+ /* Find a group */
+ list_for_each_entry(kvg, &kv->group_list, node) {
+ if (kvg->spapr_tce.liobn != liobn)
+ continue;
+
+ if (kvg->spapr_tce.cb)
+ return NULL;
+
+ kvg->spapr_tce.cb = cb;
+ group_id = vfio_external_user_iommu_id(kvg->vfio_group);
+ grp = iommu_group_get_by_id(group_id);
+
+ return grp;
+ }
+
+ return NULL;
+}
+EXPORT_SYMBOL_GPL(kvm_vfio_find_group_by_liobn);
+#endif
+
/*
* Groups can use the same or different IOMMU domains. If the same then
* adding a new group may change the coherency of groups we've previously
@@ -170,6 +221,11 @@ static int kvm_vfio_set_group(struct kvm_device *dev, long attr, u64 arg)
continue;
list_del(&kvg->node);
+#ifdef CONFIG_SPAPR_TCE_IOMMU
+ if (kvg->spapr_tce.cb)
+ kvg->spapr_tce.cb(dev->kvm,
+ kvg->spapr_tce.liobn);
+#endif
kvm_vfio_group_put_external_user(kvg->vfio_group);
kfree(kvg);
ret = 0;
@@ -183,6 +239,62 @@ static int kvm_vfio_set_group(struct kvm_device *dev, long attr, u64 arg)
kvm_vfio_update_coherency(dev);
return ret;
+
+#ifdef CONFIG_SPAPR_TCE_IOMMU
+ case KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE_LIOBN: {
+ struct kvm_vfio_spapr_tce_liobn param;
+ unsigned long minsz;
+ struct kvm_vfio *kv = dev->private;
+ struct vfio_group *vfio_group;
+ struct kvm_vfio_group *kvg;
+ struct fd f;
+
+ minsz = offsetofend(struct kvm_vfio_spapr_tce_liobn, liobn);
+
+ if (copy_from_user(¶m, (void __user *)arg, minsz))
+ return -EFAULT;
+
+ if (param.argsz < minsz)
+ return -EINVAL;
+
+ if (copy_from_user(¶m, (void __user *)arg, minsz))
+ return -EFAULT;
+
+ f = fdget(param.fd);
+ if (!f.file)
+ return -EBADF;
+
+ vfio_group = kvm_vfio_group_get_external_user(f.file);
+ fdput(f);
+
+ if (IS_ERR(vfio_group))
+ return PTR_ERR(vfio_group);
+
+ ret = -ENOENT;
+
+ mutex_lock(&kv->lock);
+
+ list_for_each_entry(kvg, &kv->group_list, node) {
+ if (kvg->vfio_group != vfio_group)
+ continue;
+
+ if (kvg->spapr_tce.liobn) {
+ ret = -EBUSY;
+ break;
+ }
+
+ kvg->spapr_tce.liobn = param.liobn;
+ ret = 0;
+ break;
+ }
+
+ mutex_unlock(&kv->lock);
+
+ kvm_vfio_group_put_external_user(vfio_group);
+
+ return ret;
+ }
+#endif /* CONFIG_SPAPR_TCE_IOMMU */
}
return -ENXIO;
@@ -207,9 +319,11 @@ static int kvm_vfio_has_attr(struct kvm_device *dev,
switch (attr->attr) {
case KVM_DEV_VFIO_GROUP_ADD:
case KVM_DEV_VFIO_GROUP_DEL:
+#ifdef CONFIG_SPAPR_TCE_IOMMU
+ case KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE_LIOBN:
+#endif
return 0;
}
-
break;
}
--
1.8.4.rc4
^ permalink raw reply related
* Re: [PATCH RFC v5 2/5] dma: mpc512x: add support for peripheral transfers
From: Alexander Popov @ 2013-11-20 6:49 UTC (permalink / raw)
To: Gerhard Sittig, Dan Williams, Vinod Koul, Lars-Peter Clausen,
Arnd Bergmann, Anatolij Gustschin, linuxppc-dev, devicetree,
Alexander Popov
In-Reply-To: <20131114205810.GH17929@book.gsilab.sittig.org>
2013/11/15 Gerhard Sittig <gsi@denx.de>:
> As for the not yet addressed feedback: From the top of my head I
> can think of the execute comment which contradicts the code
> (which suggests that at least one of them is wrong), and the data
> type mismatch in the config routine (where code just happens to
> work by coincidence). And in bypassing I noticed that your
> recent submission has coding style issues (braces, indentation),
> which should no longer happen after several iterations as you
> should know how to prepare and check the next version.
I'll doublecheck this and return with improved code.
> Without feedback, reviewers
> may see several submissions which suffer from the same issues,
> and expect more to show up and thus feel that their feedback is
> getting ignored. Which quickly becomes tiring.
Thanks for your patience and comprehensive replies.
Best regards,
Alexander.
^ permalink raw reply
* RE: [PATCHv2 6/8] ASoC: fsl: add SGTL5000 based audio machine driver.
From: Li Xiubo @ 2013-11-20 7:49 UTC (permalink / raw)
To: Mark Brown
Cc: mark.rutland@arm.com, alsa-devel@alsa-project.org,
linux-doc@vger.kernel.org, tiwai@suse.de, timur@tabi.org,
perex@perex.cz, Huan Wang, LW@KARO-electronics.de,
linux@arm.linux.org.uk, Shawn Guo, grant.likely@linaro.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
ian.campbell@citrix.com, pawel.moll@arm.com,
swarren@wwwdotorg.org, rob.herring@calxeda.com, Zhengxiong Jin,
oskar@scara.com, Fabio Estevam, lgirdwood@gmail.com,
linux-kernel@vger.kernel.org, rob@landley.net, Guangyu Chen,
shawn.guo@linaro.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20131101184008.GF2493@sirena.org.uk>
> > + /* TODO: The SAI driver should figure this out for us */
> > + switch (channels) {
> > + case 2:
> > + snd_soc_dai_set_tdm_slot(cpu_dai, 0xfffffffc, 0xfffffffc, 2,
> 0);
> > + break;
> > + case 1:
> > + snd_soc_dai_set_tdm_slot(cpu_dai, 0xfffffffe, 0xfffffffe, 1,
> 0);
> > + break;
> > + default:
> > + return -EINVAL;
> > + }
>=20
> Yes, it should - this code should probably just be copied straight into
> the SAI driver. If we need to support other configurations we can do
> that later.
>=20
Well, yes.
I have considered carefully about this, It maybe nicer to move this to SAI =
driver's .hw_params.
--
Best Regards,
Xiubo
^ permalink raw reply
* Re: PCIE device errors after linux kernel upgrade
From: ravich @ 2013-11-20 7:53 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <CAErSpo49ZLfxkEanmrrwwiqHR8koiCakqe9h8My2Mu1yA4R1Ww@mail.gmail.com>
I compared the configuration hexdump of my pci controller and pci device
(FPGA) on old kernel(working 2.6.32) and new (3.8.13) and the only
difference was on the controller configuration on the memory base at Type 1
configuration header registers
.
what does it mean and could it be the trigger for my problem ?
Thanks a lot.
Leonid
--
View this message in context: http://linuxppc.10917.n7.nabble.com/Re-PCIE-device-errors-after-linux-kernel-upgrade-tp74563p78251.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* [RFC][PATCH] powerpc/CoreNet64: compile with CONFIG_E{5, 6}500_CPU well
From: Tiejun Chen @ 2013-11-20 8:35 UTC (permalink / raw)
To: scottwood; +Cc: linuxppc-dev
CONFIG_ALTIVEC is always enabled for CoreNet64. And if we
select CONFIG_E{5,6}500_CPU this may introduce -mcpu=e500mc64
into $CFLAGS. But Altivec and Spe options not allowed with
e500mc64, so :
CC arch/powerpc/lib/xor_vmx.o
arch/powerpc/lib/xor_vmx.c:1:0: error: AltiVec not supported in this target
make[1]: *** [arch/powerpc/lib/xor_vmx.o] Error 1
make: *** [arch/powerpc/lib] Error 2
Signed-off-by: Tiejun Chen <tiejun.chen@windriver.com>
---
arch/powerpc/lib/Makefile | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
index 95a20e1..641a77d 100644
--- a/arch/powerpc/lib/Makefile
+++ b/arch/powerpc/lib/Makefile
@@ -40,5 +40,8 @@ obj-y += code-patching.o
obj-y += feature-fixups.o
obj-$(CONFIG_FTR_FIXUP_SELFTEST) += feature-fixups-test.o
+# Altivec and Spe options not allowed with e500mc64 in GCC.
+ifeq ($(call cc-option-yn,-mcpu=e500mc64),n)
obj-$(CONFIG_ALTIVEC) += xor_vmx.o
CFLAGS_xor_vmx.o += -maltivec -mabi=altivec
+endif
--
1.7.9.5
^ permalink raw reply related
* [PATCH] powerpc/eeh: Dump PHB3 diag-data on frozen PE
From: Gavin Shan @ 2013-11-20 9:36 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Gavin Shan
While we detect frozen PE on PHB3, it's always meaningful to have
the dumped diag-data for further diagnosis and analysis.
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
---
arch/powerpc/platforms/powernv/eeh-ioda.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/powerpc/platforms/powernv/eeh-ioda.c b/arch/powerpc/platforms/powernv/eeh-ioda.c
index 02245ce..481528d 100644
--- a/arch/powerpc/platforms/powernv/eeh-ioda.c
+++ b/arch/powerpc/platforms/powernv/eeh-ioda.c
@@ -994,8 +994,11 @@ static int ioda_eeh_next_error(struct eeh_pe **pe)
if (ioda_eeh_get_pe(hose, frozen_pe_no, pe))
break;
+ /* It would be always indicative to have PHB diag-data */
pr_err("EEH: Frozen PE#%x on PHB#%x detected\n",
(*pe)->addr, (*pe)->phb->global_number);
+ ioda_eeh_phb_diag(hose);
+
ret = 1;
goto out;
}
--
1.7.9.5
^ permalink raw reply related
* BUG: Patch "Convert some mftb/mftbu into mfspr" breaks MPC885
From: leroy christophe @ 2013-11-20 9:37 UTC (permalink / raw)
To: Scott Wood; +Cc: LinuxPPC-dev, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 459 bytes --]
Scott,
The patch "Convert some mftb/mftbu into mfspr"
(beb2dc0a7a84be003ce54e98b95d65cc66e6e536
<https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/powerpc/include/asm/reg.h?id=beb2dc0a7a84be003ce54e98b95d65cc66e6e536>)
breaks startup on MPC885.
The CPU traps (SoftwareEmulation trap) at sched_clock() when trying to
read TBU with mfspr.
Reverting the patch solves the issue.
What's the prefered way to fix this ?
Christophe
[-- Attachment #2: Type: text/html, Size: 1160 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc/eeh: Dump PHB3 diag-data on frozen PE
From: Benjamin Herrenschmidt @ 2013-11-20 9:38 UTC (permalink / raw)
To: Gavin Shan; +Cc: linuxppc-dev
In-Reply-To: <1384940196-32514-1-git-send-email-shangw@linux.vnet.ibm.com>
On Wed, 2013-11-20 at 17:36 +0800, Gavin Shan wrote:
> While we detect frozen PE on PHB3, it's always meaningful to have
> the dumped diag-data for further diagnosis and analysis.
Don't we trip that during PCI probing ? For example if we probe behind
a PCI-X bridge (which can exist on an adapter) we'll trip EEH on every
non-existing device won't we ?
Cheers,
Ben.
> Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
> ---
> arch/powerpc/platforms/powernv/eeh-ioda.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/powerpc/platforms/powernv/eeh-ioda.c b/arch/powerpc/platforms/powernv/eeh-ioda.c
> index 02245ce..481528d 100644
> --- a/arch/powerpc/platforms/powernv/eeh-ioda.c
> +++ b/arch/powerpc/platforms/powernv/eeh-ioda.c
> @@ -994,8 +994,11 @@ static int ioda_eeh_next_error(struct eeh_pe **pe)
> if (ioda_eeh_get_pe(hose, frozen_pe_no, pe))
> break;
>
> + /* It would be always indicative to have PHB diag-data */
> pr_err("EEH: Frozen PE#%x on PHB#%x detected\n",
> (*pe)->addr, (*pe)->phb->global_number);
> + ioda_eeh_phb_diag(hose);
> +
> ret = 1;
> goto out;
> }
^ permalink raw reply
* [PATCH v7] clk: corenet: Adds the clock binding
From: Yuantian.Tang @ 2013-11-20 9:04 UTC (permalink / raw)
To: galak; +Cc: mark.rutland, devicetree, Tang Yuantian, scottwood, linuxppc-dev
From: Tang Yuantian <yuantian.tang@freescale.com>
Adds the clock bindings for Freescale PowerPC CoreNet platforms
Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com>
Signed-off-by: Li Yang <leoli@freescale.com>
---
v7:
- refined some properties' definitions
v6:
- splited the previous patch into 2 parts, one is for binding(this one),
the other is for DTS modification(will submit once this gets accepted)
- fixed typo
- refined #clock-cells and clock-output-names properties
- removed fixed-clock compatible string
v5:
- refine the binding document
- update the compatible string
v4:
- add binding document
- update compatible string
- update the reg property
v3:
- fix typo
v2:
- add t4240, b4420, b4860 support
- remove pll/4 clock from p2041, p3041 and p5020 board
.../devicetree/bindings/clock/corenet-clock.txt | 128 +++++++++++++++++++++
1 file changed, 128 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/corenet-clock.txt
diff --git a/Documentation/devicetree/bindings/clock/corenet-clock.txt b/Documentation/devicetree/bindings/clock/corenet-clock.txt
new file mode 100644
index 0000000..609ba2b
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/corenet-clock.txt
@@ -0,0 +1,128 @@
+* Clock Block on Freescale CoreNet Platforms
+
+Freescale CoreNet chips take primary clocking input from the external
+SYSCLK signal. The SYSCLK input (frequency) is multiplied using
+multiple phase locked loops (PLL) to create a variety of frequencies
+which can then be passed to a variety of internal logic, including
+cores and peripheral IP blocks.
+Please refer to the Reference Manual for details.
+
+1. Clock Block Binding
+
+Required properties:
+- compatible: Should contain a specific clock block compatible string
+ and a single chassis clock compatible string.
+ Clock block strings include, but not limited to, one of the:
+ * "fsl,p2041-clockgen"
+ * "fsl,p3041-clockgen"
+ * "fsl,p4080-clockgen"
+ * "fsl,p5020-clockgen"
+ * "fsl,p5040-clockgen"
+ * "fsl,t4240-clockgen"
+ * "fsl,b4420-clockgen"
+ * "fsl,b4860-clockgen"
+ Chassis clock strings include:
+ * "fsl,qoriq-clockgen-1.0": for chassis 1.0 clocks
+ * "fsl,qoriq-clockgen-2.0": for chassis 2.0 clocks
+- reg: Offset and length of the clock register set
+
+Recommended properties:
+- ranges: Allows valid translation between child's address space and
+ parent's. Must be present if the device has sub-nodes.
+- #address-cells: Specifies the number of cells used to represent
+ physical base addresses. Must be present if the device has
+ sub-nodes and set to 1 if present
+- #size-cells: Specifies the number of cells used to represent
+ the size of an address. Must be present if the device has
+ sub-nodes and set to 1 if present
+
+2. Clock Provider/Consumer Binding
+
+Most of the bindings are from the common clock binding[1].
+ [1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : Should include one of the following:
+ * "fsl,qoriq-core-pll-1.0" for core PLL clocks (v1.0)
+ * "fsl,qoriq-core-pll-2.0" for core PLL clocks (v2.0)
+ * "fsl,qoriq-core-mux-1.0" for core mux clocks (v1.0)
+ * "fsl,qoriq-core-mux-2.0" for core mux clocks (v2.0)
+ * "fsl,qoriq-sysclk-1.0": for input system clock (v1.0)
+ * "fsl,qoriq-sysclk-2.0": for input system clock (v2.0)
+- #clock-cells: From common clock binding. The number of cells in a
+ clock-specifier. Should be <0> for "fsl,qoriq-sysclk-[1,2].0"
+ clocks, or <1> for "fsl,qoriq-core-pll-[1,2].0" clocks.
+ For "fsl,qoriq-core-pll-[1,2].0" clocks, the single
+ clock-specifier cell may take the following values:
+ * 0 - equal to the PLL frequency
+ * 1 - equal to the PLL frequency divided by 2
+ * 2 - equal to the PLL frequency divided by 4
+
+Recommended properties:
+- clocks: Should be the phandle of input parent clock
+- clock-names: From common clock binding, indicates the clock name
+- clock-output-names: From common clock binding, indicates the names of
+ output clocks
+- reg: Should be the offset and length of clock block base address.
+ The length should be 4.
+
+Example for clock block and clock provider:
+/ {
+ clockgen: global-utilities@e1000 {
+ compatible = "fsl,p5020-clockgen", "fsl,qoriq-clockgen-1.0";
+ ranges = <0x0 0xe1000 0x1000>;
+ reg = <0xe1000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ sysclk: sysclk {
+ #clock-cells = <0>;
+ compatible = "fsl,qoriq-sysclk-1.0";
+ clock-output-names = "sysclk";
+ }
+
+ pll0: pll0@800 {
+ #clock-cells = <1>;
+ reg = <0x800 0x4>;
+ compatible = "fsl,qoriq-core-pll-1.0";
+ clocks = <&sysclk>;
+ clock-output-names = "pll0", "pll0-div2";
+ };
+
+ pll1: pll1@820 {
+ #clock-cells = <1>;
+ reg = <0x820 0x4>;
+ compatible = "fsl,qoriq-core-pll-1.0";
+ clocks = <&sysclk>;
+ clock-output-names = "pll1", "pll1-div2";
+ };
+
+ mux0: mux0@0 {
+ #clock-cells = <0>;
+ reg = <0x0 0x4>;
+ compatible = "fsl,qoriq-core-mux-1.0";
+ clocks = <&pll0 0>, <&pll0 1>, <&pll1 0>, <&pll1 1>;
+ clock-names = "pll0", "pll0-div2", "pll1", "pll1-div2";
+ clock-output-names = "cmux0";
+ };
+
+ mux1: mux1@20 {
+ #clock-cells = <0>;
+ reg = <0x20 0x4>;
+ compatible = "fsl,qoriq-core-mux-1.0";
+ clocks = <&pll0 0>, <&pll0 1>, <&pll1 0>, <&pll1 1>;
+ clock-names = "pll0", "pll0-div2", "pll1", "pll1-div2";
+ clock-output-names = "cmux1";
+ };
+ };
+ }
+
+Example for clock consumer:
+
+/ {
+ cpu0: PowerPC,e5500@0 {
+ ...
+ clocks = <&mux0>;
+ ...
+ };
+ }
--
1.8.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox