* [RFC PATCH 17/20] IA64/MSI: Use msi_chip instead of arch func to configure MSI/MSI-X
From: Yijing Wang @ 2014-08-12 7:26 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: linux-mips, linux-ia64, linux-pci, Xinwei Hu, Yijing Wang,
H. Peter Anvin, sparclinux, linux-s390, Russell King,
Joerg Roedel, x86, Sebastian Ott, xen-devel, arnab.basu,
Arnd Bergmann, Konrad Rzeszutek Wilk, Marc Zyngier, Chris Metcalf,
Thomas Gleixner, linux-arm-kernel, Tony Luck, linux-kernel, iommu,
Wuyun, linuxppc-dev, David S. Miller
In-Reply-To: <1407828373-24322-1-git-send-email-wangyijing@huawei.com>
Introduce a new struct msi_chip ia64_msi_chip instead of weak arch
functions to configure MSI/MSI-X.
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
---
arch/ia64/kernel/msi_ia64.c | 18 ++++++++++++++----
1 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/arch/ia64/kernel/msi_ia64.c b/arch/ia64/kernel/msi_ia64.c
index c430f91..6e527c4 100644
--- a/arch/ia64/kernel/msi_ia64.c
+++ b/arch/ia64/kernel/msi_ia64.c
@@ -112,15 +112,15 @@ static struct irq_chip ia64_msi_chip = {
};
-int arch_setup_msi_irq(struct pci_dev *pdev, struct msi_desc *desc)
+static int arch_ia64_setup_msi_irq(struct device *dev, struct msi_desc *desc)
{
if (platform_setup_msi_irq)
- return platform_setup_msi_irq(pdev, desc);
+ return platform_setup_msi_irq(to_pci_dev(dev), desc);
- return ia64_setup_msi_irq(pdev, desc);
+ return ia64_setup_msi_irq(to_pci_dev(dev), desc);
}
-void arch_teardown_msi_irq(unsigned int irq)
+static void arch_ia64_teardown_msi_irq(unsigned int irq)
{
if (platform_teardown_msi_irq)
return platform_teardown_msi_irq(irq);
@@ -128,6 +128,16 @@ void arch_teardown_msi_irq(unsigned int irq)
return ia64_teardown_msi_irq(irq);
}
+static struct msi_chip chip = {
+ .setup_irq = arch_ia64_setup_msi_irq,
+ .teardown_irq = arch_ia64_teardown_msi_irq,
+};
+
+struct msi_chip *arch_get_match_msi_chip(struct device *dev)
+{
+ return &chip;
+}
+
#ifdef CONFIG_INTEL_IOMMU
#ifdef CONFIG_SMP
static int dmar_msi_set_affinity(struct irq_data *data,
--
1.7.1
^ permalink raw reply related
* [RFC PATCH 15/20] s390/MSI: Use msi_chip instead of arch func to configure MSI/MSI-X
From: Yijing Wang @ 2014-08-12 7:26 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: linux-mips, linux-ia64, linux-pci, Xinwei Hu, Yijing Wang,
H. Peter Anvin, sparclinux, linux-s390, Russell King,
Joerg Roedel, x86, Sebastian Ott, xen-devel, arnab.basu,
Arnd Bergmann, Konrad Rzeszutek Wilk, Marc Zyngier, Chris Metcalf,
Thomas Gleixner, linux-arm-kernel, Tony Luck, linux-kernel, iommu,
Wuyun, linuxppc-dev, David S. Miller
In-Reply-To: <1407828373-24322-1-git-send-email-wangyijing@huawei.com>
Introduce a new struct msi_chip zpci_msi_chip instead of weak arch
functions to configure MSI/MSI-X.
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
---
arch/s390/pci/pci.c | 16 ++++++++++++++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/arch/s390/pci/pci.c b/arch/s390/pci/pci.c
index 9ddc51e..ee7b05c 100644
--- a/arch/s390/pci/pci.c
+++ b/arch/s390/pci/pci.c
@@ -398,8 +398,9 @@ static void zpci_irq_handler(struct airq_struct *airq)
}
}
-int arch_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type)
+int zpci_setup_msi_irqs(struct device *dev, int nvec, int type)
{
+ struct pci_dev *pdev = to_pci_dev(dev);
struct zpci_dev *zdev = get_zdev(pdev);
unsigned int hwirq, msi_vecs;
unsigned long aisb;
@@ -474,8 +475,9 @@ out:
return rc;
}
-void arch_teardown_msi_irqs(struct pci_dev *pdev)
+void zpci_teardown_msi_irqs(struct device *dev)
{
+ struct pci_dev *pdev = to_pci_dev(dev);
struct zpci_dev *zdev = get_zdev(pdev);
struct msi_desc *msi;
int rc;
@@ -501,6 +503,16 @@ void arch_teardown_msi_irqs(struct pci_dev *pdev)
airq_iv_free_bit(zpci_aisb_iv, zdev->aisb);
}
+struct msi_chip zpci_msi_chip = {
+ .setup_irqs = zpci_setup_msi_irqs,
+ .teardown_irqs = zpci_teardown_msi_irqs,
+};
+
+struct msi_chip *arch_get_match_msi_chip(struct device *dev)
+{
+ return &zpci_msi_chip;
+}
+
static void zpci_map_resources(struct zpci_dev *zdev)
{
struct pci_dev *pdev = zdev->pdev;
--
1.7.1
^ permalink raw reply related
* [RFC PATCH 19/20] tile/MSI: Use msi_chip instead of arch func to configure MSI/MSI-X
From: Yijing Wang @ 2014-08-12 7:26 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: linux-mips, linux-ia64, linux-pci, Xinwei Hu, Yijing Wang,
H. Peter Anvin, sparclinux, linux-s390, Russell King,
Joerg Roedel, x86, Sebastian Ott, xen-devel, arnab.basu,
Arnd Bergmann, Konrad Rzeszutek Wilk, Marc Zyngier, Chris Metcalf,
Thomas Gleixner, linux-arm-kernel, Tony Luck, linux-kernel, iommu,
Wuyun, linuxppc-dev, David S. Miller
In-Reply-To: <1407828373-24322-1-git-send-email-wangyijing@huawei.com>
Introduce a new struct msi_chip tile_msi_chip instead of weak arch
functions to configure MSI/MSI-X.
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
---
arch/tile/kernel/pci_gx.c | 20 +++++++++++++++-----
1 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/arch/tile/kernel/pci_gx.c b/arch/tile/kernel/pci_gx.c
index e39f9c5..d1f308c 100644
--- a/arch/tile/kernel/pci_gx.c
+++ b/arch/tile/kernel/pci_gx.c
@@ -1485,7 +1485,7 @@ static struct irq_chip tilegx_msi_chip = {
/* TBD: support set_affinity. */
};
-int arch_setup_msi_irq(struct pci_dev *pdev, struct msi_desc *desc)
+int tile_setup_msi_irq(struct device *dev, struct msi_desc *desc)
{
struct pci_controller *controller;
gxio_trio_context_t *trio_context;
@@ -1510,7 +1510,7 @@ int arch_setup_msi_irq(struct pci_dev *pdev, struct msi_desc *desc)
* Most PCIe endpoint devices do support 64-bit message addressing.
*/
if (desc->msi_attrib.is_64 == 0) {
- dev_printk(KERN_INFO, &pdev->dev,
+ dev_printk(KERN_INFO, dev,
"64-bit MSI message address not supported, "
"falling back to legacy interrupts.\n");
@@ -1549,7 +1549,7 @@ int arch_setup_msi_irq(struct pci_dev *pdev, struct msi_desc *desc)
/* SQ regions are out, allocate from map mem regions. */
mem_map = gxio_trio_alloc_memory_maps(trio_context, 1, 0, 0);
if (mem_map < 0) {
- dev_printk(KERN_INFO, &pdev->dev,
+ dev_printk(KERN_INFO, dev,
"%s Mem-Map alloc failure. "
"Failed to initialize MSI interrupts. "
"Falling back to legacy interrupts.\n",
@@ -1580,7 +1580,7 @@ int arch_setup_msi_irq(struct pci_dev *pdev, struct msi_desc *desc)
mem_map, mem_map_base, mem_map_limit,
trio_context->asid);
if (ret < 0) {
- dev_printk(KERN_INFO, &pdev->dev, "HV MSI config failed.\n");
+ dev_printk(KERN_INFO, dev, "HV MSI config failed.\n");
goto hv_msi_config_failure;
}
@@ -1604,7 +1604,17 @@ is_64_failure:
return ret;
}
-void arch_teardown_msi_irq(unsigned int irq)
+void tile_teardown_msi_irq(unsigned int irq)
{
irq_free_hwirq(irq);
}
+
+struct msi_chip tile_msi_chip = {
+ .setup_irq = tile_setup_msi_irq,
+ .teardown_irq = tile_teardown_msi_irq,
+};
+
+struct msi_chip *arch_get_match_msi_chip(struct device *dev)
+{
+ return &tile_msi_chip;
+}
--
1.7.1
^ permalink raw reply related
* [RFC PATCH 18/20] Sparc/MSI: Use msi_chip instead of arch func to configure MSI/MSI-X
From: Yijing Wang @ 2014-08-12 7:26 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: linux-mips, linux-ia64, linux-pci, Xinwei Hu, Yijing Wang,
H. Peter Anvin, sparclinux, linux-s390, Russell King,
Joerg Roedel, x86, Sebastian Ott, xen-devel, arnab.basu,
Arnd Bergmann, Konrad Rzeszutek Wilk, Marc Zyngier, Chris Metcalf,
Thomas Gleixner, linux-arm-kernel, Tony Luck, linux-kernel, iommu,
Wuyun, linuxppc-dev, David S. Miller
In-Reply-To: <1407828373-24322-1-git-send-email-wangyijing@huawei.com>
Introduce a new struct msi_chip sparc_msi_chip instead of weak arch
functions to configure MSI/MSI-X.
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
---
arch/sparc/kernel/pci.c | 18 ++++++++++++++----
1 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/arch/sparc/kernel/pci.c b/arch/sparc/kernel/pci.c
index 857ad77..9eabd22 100644
--- a/arch/sparc/kernel/pci.c
+++ b/arch/sparc/kernel/pci.c
@@ -839,18 +839,18 @@ int pci_domain_nr(struct pci_bus *pbus)
EXPORT_SYMBOL(pci_domain_nr);
#ifdef CONFIG_PCI_MSI
-int arch_setup_msi_irq(struct pci_dev *pdev, struct msi_desc *desc)
+int sparc_setup_msi_irq(struct device *dev, struct msi_desc *desc)
{
- struct pci_pbm_info *pbm = pdev->dev.archdata.host_controller;
+ struct pci_pbm_info *pbm = dev->archdata.host_controller;
unsigned int irq;
if (!pbm->setup_msi_irq)
return -EINVAL;
- return pbm->setup_msi_irq(&irq, pdev, desc);
+ return pbm->setup_msi_irq(&irq, to_pci_dev(dev), desc);
}
-void arch_teardown_msi_irq(unsigned int irq)
+void sparc_teardown_msi_irq(unsigned int irq)
{
struct msi_desc *entry = irq_get_msi_desc(irq);
struct pci_dev *pdev = entry->dev;
@@ -859,6 +859,16 @@ void arch_teardown_msi_irq(unsigned int irq)
if (pbm->teardown_msi_irq)
pbm->teardown_msi_irq(irq, pdev);
}
+
+struct msi_chip sparc_msi_chip = {
+ .setup_irq = sparc_setup_msi_irq,
+ .teardown_irq = sparc_teardown_msi_irq,
+};
+
+struct msi_chip *arch_get_match_msi_chip(struct device *dev)
+{
+ return &sparc_msi_chip;
+}
#endif /* !(CONFIG_PCI_MSI) */
static void ali_sound_dma_hack(struct pci_dev *pdev, int set_bit)
--
1.7.1
^ permalink raw reply related
* [RFC PATCH 14/20] Powerpc/MSI: Use msi_chip instead of arch func to configure MSI/MSI-X
From: Yijing Wang @ 2014-08-12 7:26 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: linux-mips, linux-ia64, linux-pci, Xinwei Hu, Yijing Wang,
H. Peter Anvin, sparclinux, linux-s390, Russell King,
Joerg Roedel, x86, Sebastian Ott, xen-devel, arnab.basu,
Arnd Bergmann, Konrad Rzeszutek Wilk, Marc Zyngier, Chris Metcalf,
Thomas Gleixner, linux-arm-kernel, Tony Luck, linux-kernel, iommu,
Wuyun, linuxppc-dev, David S. Miller
In-Reply-To: <1407828373-24322-1-git-send-email-wangyijing@huawei.com>
Introduce a new struct msi_chip ppc_msi_chip instead of weak arch
functions to configure MSI/MSI-X.
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
---
arch/powerpc/kernel/msi.c | 23 +++++++++++++++++------
1 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/kernel/msi.c b/arch/powerpc/kernel/msi.c
index 8bbc12d..170b02c 100644
--- a/arch/powerpc/kernel/msi.c
+++ b/arch/powerpc/kernel/msi.c
@@ -13,7 +13,7 @@
#include <asm/machdep.h>
-int arch_msi_check_device(struct pci_dev* dev, int nvec, int type)
+int ppc_msi_check_device(struct device *dev, int nvec, int type)
{
if (!ppc_md.setup_msi_irqs || !ppc_md.teardown_msi_irqs) {
pr_debug("msi: Platform doesn't provide MSI callbacks.\n");
@@ -26,18 +26,29 @@ int arch_msi_check_device(struct pci_dev* dev, int nvec, int type)
if (ppc_md.msi_check_device) {
pr_debug("msi: Using platform check routine.\n");
- return ppc_md.msi_check_device(dev, nvec, type);
+ return ppc_md.msi_check_device(to_pci_dev(dev), nvec, type);
}
return 0;
}
-int arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
+int ppc_setup_msi_irqs(struct device *dev, int nvec, int type)
{
- return ppc_md.setup_msi_irqs(dev, nvec, type);
+ return ppc_md.setup_msi_irqs(to_pci_dev(dev), nvec, type);
}
-void arch_teardown_msi_irqs(struct pci_dev *dev)
+void ppc_teardown_msi_irqs(struct device *dev)
{
- ppc_md.teardown_msi_irqs(dev);
+ ppc_md.teardown_msi_irqs(to_pci_dev(dev));
+}
+
+struct msi_chip ppc_msi_chip = {
+ .setup_irqs = ppc_setup_msi_irqs,
+ .teardown_irqs = ppc_teardown_msi_irqs,
+ .check_device = ppc_msi_check_device,
+};
+
+struct msi_chip *arch_get_match_msi_chip(struct device *dev)
+{
+ return &ppc_msi_chip;
}
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] fsl-rio: add support for mapping inbound windows
From: Martijn de Gouw @ 2014-08-12 8:48 UTC (permalink / raw)
To: Scott Wood
Cc: Alexandre.Bounine, Liu Gang, Barry.Wood, linuxppc-dev,
stef.van.os
In-Reply-To: <1407274663.7427.7.camel@snotra.buserror.net>
On 08/05/2014 11:37 PM, Scott Wood wrote:
> On Tue, 2014-08-05 at 15:52 +0200, Martijn de Gouw wrote:
>> Add support for mapping and unmapping of inbound rapidio windows.
>>
>> Signed-off-by: Martijn de Gouw <martijn.de.gouw@prodrive-technologies.com>
>
> Could you elaborate in the changelog on what this fixes or makes
> possible? E.g. did the driver previously not support inbound
> transactions at all, or did it assume the window was set up by a
> bootloader?
Something like:
fsl-rio: add support for mapping inbound windows
Add support for mapping and unmapping of inbound rapidio windows.
This allows for drivers to open up a part of local memory on the
rapidio network. Also applications can use this and tranfer blocks
of data over the network.
>
> Liu Gang, could you review this?
I'll wait for the review before I post a new version.
Gr, Martijn
--
Martijn de Gouw
Engineer
Prodrive Technologies B.V.
Mobile: +31 63 17 76 161
Phone: +31 40 26 76 200
^ permalink raw reply
* Re: [PATCH 3/5] mmc: sdhci-pltfm: Do not use parent as the host's device
From: Ulf Hansson @ 2014-08-12 8:58 UTC (permalink / raw)
To: Pawel Moll
Cc: paul@pwsan.com, Arnd Bergmann, Stephen Warren, Greg Kroah-Hartman,
Peter De Schrijver, Anton Vorontsov, linux-mmc@vger.kernel.org,
Chris Ball, linux-kernel@vger.kernel.org,
linux-tegra@vger.kernel.org, arm@kernel.org, Catalin Marinas,
Olof Johansson, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAPDyKFruZxUtzUKM+PvsK-_qqcE4OcCaKSkRJ2_01y7TuQMGkA@mail.gmail.com>
On 11 August 2014 11:32, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> On 11 August 2014 11:15, Pawel Moll <pawel.moll@arm.com> wrote:
>> On Mon, 2014-08-11 at 10:07 +0100, Ulf Hansson wrote:
>>> On 8 August 2014 18:36, Pawel Moll <pawel.moll@arm.com> wrote:
>>> > On Fri, 2014-07-25 at 15:23 +0100, Pawel Moll wrote:
>>> >> The code selecting a device for the sdhci host has been
>>> >> continuously tweaked (4b711cb13843f5082e82970dd1e8031383134a65
>>> >> "mmc: sdhci-pltfm: Add structure for host-specific data" and
>>> >> a4d2177f00a5252d825236c5124bc1e9918bdb41 "mmc: sdhci-pltfm: dt
>>> >> device does not pass parent to sdhci_alloc_host") while there
>>> >> does not seem to be any reason to use platform device's parent
>>> >> in the first place.
>>> >>
>>> >> The comment saying "Some PCI-based MFD need the parent here"
>>> >> seem to refer to Timberdale FPGA driver (the only MFD driver
>>> >> registering SDHCI cell, drivers/mfd/timberdale.c) but again,
>>> >> the only situation when parent device matter is runtime PM,
>>> >> which is not implemented for Timberdale.
>>> >>
>>> >> Cc: Chris Ball <chris@printf.net>
>>> >> Cc: Anton Vorontsov <anton@enomsg.org>
>>> >> Cc: Ulf Hansson <ulf.hansson@linaro.org>
>>> >> Cc: linux-mmc@vger.kernel.org
>>> >> Cc: linuxppc-dev@lists.ozlabs.org
>>> >> Signed-off-by: Pawel Moll <pawel.moll@arm.com>
>>> >> ---
>>> >>
>>> >> This patch is a part of effort to remove references to platform_bus
>>> >> and make it static.
>>> >>
>>> >> Chris, Anton, Ulf - could you please advise if the assumptions
>>> >> above are correct or if I'm completely wrong? Do you know what
>>> >> where the real reasons to use parent originally? The PCI comment
>>> >> seems like a red herring to me...
>>> >
>>> > Can I take the silence as a suggestion that the change looks ok-ish for
>>> > you?
>>>
>>> Sorry for the delay. I suppose this make sense, but I really don't
>>> know for sure.
>>>
>>> I guess we need some testing in linux-next, to get some confidence.
>>
>> Would you take it into -next then? Unless I'm completely wrong there
>> should be no impact on any in-tree driver...
>
> I will take it; though I think it's best to queue it for 3.18 to get
> some more testing.
This patch causes a compiler warning, could you please fix it.
Kind regards
Uffe
^ permalink raw reply
* [PATCH powerpc] use machine_subsys_initcall() for opal_hmi_handler_init()
From: Li Zhong @ 2014-08-12 9:17 UTC (permalink / raw)
To: PowerPC email list; +Cc: Michael Ellerman, mahesh, Paul Mackerras
As opal_message_init() uses machine_early_initcall(powernv, ), and
opal_hmi_handler_init() depends on that early initcall, so it also needs
use machine_* to check the machine_id.
Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
---
arch/powerpc/platforms/powernv/opal-hmi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/powernv/opal-hmi.c b/arch/powerpc/platforms/powernv/opal-hmi.c
index 97ac8dc..5e1ed15 100644
--- a/arch/powerpc/platforms/powernv/opal-hmi.c
+++ b/arch/powerpc/platforms/powernv/opal-hmi.c
@@ -28,6 +28,7 @@
#include <asm/opal.h>
#include <asm/cputable.h>
+#include <asm/machdep.h>
static int opal_hmi_handler_nb_init;
struct OpalHmiEvtNode {
@@ -185,4 +186,4 @@ static int __init opal_hmi_handler_init(void)
}
return 0;
}
-subsys_initcall(opal_hmi_handler_init);
+machine_subsys_initcall(powernv, opal_hmi_handler_init);
^ permalink raw reply related
* Re: [Xen-devel] [RFC PATCH 01/20] x86/xen/MSI: Eliminate arch_msix_mask_irq() and arch_msi_mask_irq()
From: David Vrabel @ 2014-08-12 9:09 UTC (permalink / raw)
To: Yijing Wang, Bjorn Helgaas
Cc: linux-mips, linux-ia64, linux-pci, Xinwei Hu, H. Peter Anvin,
sparclinux, linux-s390, Russell King, Joerg Roedel, x86,
Sebastian Ott, xen-devel, arnab.basu, Arnd Bergmann, Marc Zyngier,
Chris Metcalf, Thomas Gleixner, linux-arm-kernel, Tony Luck,
linux-kernel, iommu, Wuyun, linuxppc-dev, David S. Miller
In-Reply-To: <1407828373-24322-2-git-send-email-wangyijing@huawei.com>
On 12/08/14 08:25, 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. This patch
> reverted commit 0e4ccb150 and add #ifdef for x86 msi_chip to fix this
> bug for simplicity. Also this is preparation for using struct
> msi_chip instead of weak arch MSI functions in all platforms.
[...]
> static struct irq_chip msi_chip = {
> .name = "PCI-MSI",
> +#ifdef CONFIG_XEN
> + .irq_unmask = nop_unmask_msi_irq,
> + .irq_mask = nop_mask_msi_irq,
> +#else
> .irq_unmask = unmask_msi_irq,
> .irq_mask = mask_msi_irq,
> +#endif
No. CONFIG_XEN kernels can run on Xen and bare metal so this must be a
runtime option.
David
^ permalink raw reply
* [PATCH 3/5 v2] mmc: sdhci-pltfm: Do not use parent as the host's device
From: Pawel Moll @ 2014-08-12 10:37 UTC (permalink / raw)
To: Ulf Hansson
Cc: Pawel Moll, Greg Kroah-Hartman, Anton Vorontsov, linux-mmc,
Chris Ball, linux-kernel, linuxppc-dev
In-Reply-To: <CAPDyKFrb9OSbhHtn=wgbs9Yky1t453rdNBJVgGA62vER-65dYw@mail.gmail.com>
The code selecting a device for the sdhci host has been
continuously tweaked (4b711cb13843f5082e82970dd1e8031383134a65
"mmc: sdhci-pltfm: Add structure for host-specific data" and
a4d2177f00a5252d825236c5124bc1e9918bdb41 "mmc: sdhci-pltfm: dt
device does not pass parent to sdhci_alloc_host" while there
does not seem to be any reason to use platform device's parent
in the first place.
The comment saying "Some PCI-based MFD need the parent here"
seem to refer to Timberdale FPGA driver (the only MFD driver
registering SDHCI cell, drivers/mfd/timberdale.c) but again,
the only situation when parent device matter is runtime PM,
which is not implemented for Timberdale.
Signed-off-by: Pawel Moll <pawel.moll@arm.com>
---
drivers/mmc/host/sdhci-pltfm.c | 10 ++--------
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/mmc/host/sdhci-pltfm.c
index 7e834fb..c5b01d6 100644
--- a/drivers/mmc/host/sdhci-pltfm.c
+++ b/drivers/mmc/host/sdhci-pltfm.c
@@ -123,7 +123,6 @@ struct sdhci_host *sdhci_pltfm_init(struct platform_device *pdev,
size_t priv_size)
{
struct sdhci_host *host;
- struct device_node *np = pdev->dev.of_node;
struct resource *iomem;
int ret;
@@ -136,13 +135,8 @@ struct sdhci_host *sdhci_pltfm_init(struct platform_device *pdev,
if (resource_size(iomem) < 0x100)
dev_err(&pdev->dev, "Invalid iomem size!\n");
- /* Some PCI-based MFD need the parent here */
- if (pdev->dev.parent != &platform_bus && !np)
- host = sdhci_alloc_host(pdev->dev.parent,
- sizeof(struct sdhci_pltfm_host) + priv_size);
- else
- host = sdhci_alloc_host(&pdev->dev,
- sizeof(struct sdhci_pltfm_host) + priv_size);
+ host = sdhci_alloc_host(&pdev->dev,
+ sizeof(struct sdhci_pltfm_host) + priv_size);
if (IS_ERR(host)) {
ret = PTR_ERR(host);
--
1.9.1
^ permalink raw reply related
* Re: [Xen-devel] [RFC PATCH 01/20] x86/xen/MSI: Eliminate arch_msix_mask_irq() and arch_msi_mask_irq()
From: Yijing Wang @ 2014-08-12 11:11 UTC (permalink / raw)
To: David Vrabel, Bjorn Helgaas
Cc: linux-mips, linux-ia64, linux-pci, Xinwei Hu, H. Peter Anvin,
sparclinux, linux-s390, Russell King, Joerg Roedel, x86,
Sebastian Ott, xen-devel, arnab.basu, Arnd Bergmann, Marc Zyngier,
Chris Metcalf, Thomas Gleixner, linux-arm-kernel, Tony Luck,
linux-kernel, iommu, Wuyun, linuxppc-dev, David S. Miller
In-Reply-To: <53E9D9DD.3060901@citrix.com>
On 2014/8/12 17:09, David Vrabel wrote:
> On 12/08/14 08:25, 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. This patch
>> reverted commit 0e4ccb150 and add #ifdef for x86 msi_chip to fix this
>> bug for simplicity. Also this is preparation for using struct
>> msi_chip instead of weak arch MSI functions in all platforms.
> [...]
>> static struct irq_chip msi_chip = {
>> .name = "PCI-MSI",
>> +#ifdef CONFIG_XEN
>> + .irq_unmask = nop_unmask_msi_irq,
>> + .irq_mask = nop_mask_msi_irq,
>> +#else
>> .irq_unmask = unmask_msi_irq,
>> .irq_mask = mask_msi_irq,
>> +#endif
>
> No. CONFIG_XEN kernels can run on Xen and bare metal so this must be a
> runtime option.
Hi David, that's my mistake, what about export struct irq_chip msi_chip, then
change the msi_chip->irq_mask/irq_unmask() in xen init functions.
Eg.
diff --git a/arch/x86/include/asm/apic.h b/arch/x86/include/asm/apic.h
index 19b0eba..bb6af00 100644
--- a/arch/x86/include/asm/apic.h
+++ b/arch/x86/include/asm/apic.h
@@ -43,6 +43,10 @@ static inline void generic_apic_probe(void)
}
#endif
+#ifdef CONFIG_PCI_MSI
+extern struct irq_chip msi_chip;
+#endif
+
#ifdef CONFIG_X86_LOCAL_APIC
[...]
+
+#ifdef CONFIG_PCI_MSI
+void xen_nop_msi_mask(struct irq_data *data)
{
- return 0;
}
#endif
@@ -424,8 +423,8 @@ int __init pci_xen_init(void)
x86_msi.setup_msi_irqs = xen_setup_msi_irqs;
x86_msi.teardown_msi_irq = xen_teardown_msi_irq;
x86_msi.teardown_msi_irqs = xen_teardown_msi_irqs;
- x86_msi.msi_mask_irq = xen_nop_msi_mask_irq;
- x86_msi.msix_mask_irq = xen_nop_msix_mask_irq;
+ msi_chip.irq_mask = xen_nop_msi_mask;
+ msi_chip.irq_unmask = xen_nop_msi_mask;
#endif
return 0;
}
@@ -505,8 +504,8 @@ int __init pci_xen_initial_domain(void)
x86_msi.setup_msi_irqs = xen_initdom_setup_msi_irqs;
x86_msi.teardown_msi_irq = xen_teardown_msi_irq;
x86_msi.restore_msi_irqs = xen_initdom_restore_msi_irqs;
- x86_msi.msi_mask_irq = xen_nop_msi_mask_irq;
- x86_msi.msix_mask_irq = xen_nop_msix_mask_irq;
+ msi_chip.irq_mask = xen_nop_msi_mask;
+ msi_chip.irq_unmask = xen_nop_msi_mask;
#endif
xen_setup_acpi_sci();
>
> David
>
> .
>
--
Thanks!
Yijing
^ permalink raw reply related
* Re: [PATCH v3] powerpc/kvm: support to handle sw breakpoint
From: Alexander Graf @ 2014-08-12 11:19 UTC (permalink / raw)
To: Madhavan Srinivasan, Benjamin Herrenschmidt
Cc: linuxppc-dev, paulus, kvm-ppc, kvm
In-Reply-To: <53E9A383.5060009@linux.vnet.ibm.com>
On 12.08.14 07:17, Madhavan Srinivasan wrote:
> On Monday 11 August 2014 02:45 PM, Alexander Graf wrote:
>> On 11.08.14 10:51, Benjamin Herrenschmidt wrote:
>>> On Mon, 2014-08-11 at 09:26 +0200, Alexander Graf wrote:
>>>>> diff --git a/arch/powerpc/kvm/emulate.c b/arch/powerpc/kvm/emulate.c
>>>>> index da86d9b..d95014e 100644
>>>>> --- a/arch/powerpc/kvm/emulate.c
>>>>> +++ b/arch/powerpc/kvm/emulate.c
>>>> This should be book3s_emulate.c.
>>> Any reason we can't make that 00dddd00 opcode as breakpoint common to
>>> all powerpc variants ?
>> I can't think of a good reason. We use a hypercall on booke (which traps
>> into an illegal instruction for pr) today, but I don't think it has to
>> be that way.
>>
>> Given that the user space API allows us to change it dynamically, there
>> should be nothing blocking us from going with 00dddd00 always.
>>
> Kindly correct me if i am wrong. So we can still have a common code in
> emulate.c to set the env for both HV and pr incase of illegal
> instruction (i will rebase latest src). But suggestion here to use
> 00dddd00, in that case current path in embed is kvmppc_handle_exit
> (booke.c) -> BOOKE_INTERRUPT_HV_PRIV -> emulation_exit ->
> kvmppc_emulate_instruction, will change to kvmppc_handle_exit (booke.c)
> -> BOOKE_INTERRUPT_PROGRAM -> if debug instr call emulation_exit else
> send to guest?
I can't follow your description above.
With the latest git version HV KVM does not include emulate.c anymore.
Also, it would make a lot of sense of have the same soft breakpoint
instruction across all ppc targets, so it would make sense to change it
to 0x00dddd00 for booke as well.
Basically you would have handling code in emulate.c and book3s_hv.c at
the end of the day.
Alex
^ permalink raw reply
* Re: [PATCH v3] powerpc/kvm: support to handle sw breakpoint
From: Madhavan Srinivasan @ 2014-08-12 11:35 UTC (permalink / raw)
To: Alexander Graf, Benjamin Herrenschmidt; +Cc: linuxppc-dev, paulus, kvm-ppc, kvm
In-Reply-To: <53E9F824.9080906@suse.de>
On Tuesday 12 August 2014 04:49 PM, Alexander Graf wrote:
>
> On 12.08.14 07:17, Madhavan Srinivasan wrote:
>> On Monday 11 August 2014 02:45 PM, Alexander Graf wrote:
>>> On 11.08.14 10:51, Benjamin Herrenschmidt wrote:
>>>> On Mon, 2014-08-11 at 09:26 +0200, Alexander Graf wrote:
>>>>>> diff --git a/arch/powerpc/kvm/emulate.c b/arch/powerpc/kvm/emulate.c
>>>>>> index da86d9b..d95014e 100644
>>>>>> --- a/arch/powerpc/kvm/emulate.c
>>>>>> +++ b/arch/powerpc/kvm/emulate.c
>>>>> This should be book3s_emulate.c.
>>>> Any reason we can't make that 00dddd00 opcode as breakpoint common to
>>>> all powerpc variants ?
>>> I can't think of a good reason. We use a hypercall on booke (which traps
>>> into an illegal instruction for pr) today, but I don't think it has to
>>> be that way.
>>>
>>> Given that the user space API allows us to change it dynamically, there
>>> should be nothing blocking us from going with 00dddd00 always.
>>>
>> Kindly correct me if i am wrong. So we can still have a common code in
>> emulate.c to set the env for both HV and pr incase of illegal
>> instruction (i will rebase latest src). But suggestion here to use
>> 00dddd00, in that case current path in embed is kvmppc_handle_exit
>> (booke.c) -> BOOKE_INTERRUPT_HV_PRIV -> emulation_exit ->
>> kvmppc_emulate_instruction, will change to kvmppc_handle_exit (booke.c)
>> -> BOOKE_INTERRUPT_PROGRAM -> if debug instr call emulation_exit else
>> send to guest?
>
> I can't follow your description above.
>
My bad.
> With the latest git version HV KVM does not include emulate.c anymore.
>
> Also, it would make a lot of sense of have the same soft breakpoint
> instruction across all ppc targets, so it would make sense to change it
> to 0x00dddd00 for booke as well.
>
Got it. Was describing the current control flow with respect to booke
and where changes needed (for same software breakpoint inst). This is
for my understanding and wanted verify.
kvmppc_handle_exit(booke.c)
-> BOOKE_INTERRUPT_HV_PRIV
-> emulation_exit
->kvmppc_emulate_instruction
Incase of using the same software breakpoint instruction (0x00dddd00),
then we need to add code in booke something like this
kvmppc_handle_exit (booke.c)
-> BOOKE_INTERRUPT_PROGRAM
-> if debug instr
->emulation_exit
else
->send to guest?
> Basically you would have handling code in emulate.c and book3s_hv.c at
> the end of the day.
>
Yes. Will resend the patch with updated code.
>
> Alex
>
^ permalink raw reply
* Re: [PATCH 3/5 v2] mmc: sdhci-pltfm: Do not use parent as the host's device
From: Ulf Hansson @ 2014-08-12 11:51 UTC (permalink / raw)
To: Pawel Moll
Cc: Greg Kroah-Hartman, Anton Vorontsov, linux-mmc, Chris Ball,
linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1407839872-12864-1-git-send-email-pawel.moll@arm.com>
On 12 August 2014 12:37, Pawel Moll <pawel.moll@arm.com> wrote:
> The code selecting a device for the sdhci host has been
> continuously tweaked (4b711cb13843f5082e82970dd1e8031383134a65
> "mmc: sdhci-pltfm: Add structure for host-specific data" and
> a4d2177f00a5252d825236c5124bc1e9918bdb41 "mmc: sdhci-pltfm: dt
> device does not pass parent to sdhci_alloc_host" while there
> does not seem to be any reason to use platform device's parent
> in the first place.
>
> The comment saying "Some PCI-based MFD need the parent here"
> seem to refer to Timberdale FPGA driver (the only MFD driver
> registering SDHCI cell, drivers/mfd/timberdale.c) but again,
> the only situation when parent device matter is runtime PM,
> which is not implemented for Timberdale.
>
> Signed-off-by: Pawel Moll <pawel.moll@arm.com>
Thanks! Queued for 3.18.
Kind regards
Uffe
> ---
> drivers/mmc/host/sdhci-pltfm.c | 10 ++--------
> 1 file changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/mmc/host/sdhci-pltfm.c
> index 7e834fb..c5b01d6 100644
> --- a/drivers/mmc/host/sdhci-pltfm.c
> +++ b/drivers/mmc/host/sdhci-pltfm.c
> @@ -123,7 +123,6 @@ struct sdhci_host *sdhci_pltfm_init(struct platform_device *pdev,
> size_t priv_size)
> {
> struct sdhci_host *host;
> - struct device_node *np = pdev->dev.of_node;
> struct resource *iomem;
> int ret;
>
> @@ -136,13 +135,8 @@ struct sdhci_host *sdhci_pltfm_init(struct platform_device *pdev,
> if (resource_size(iomem) < 0x100)
> dev_err(&pdev->dev, "Invalid iomem size!\n");
>
> - /* Some PCI-based MFD need the parent here */
> - if (pdev->dev.parent != &platform_bus && !np)
> - host = sdhci_alloc_host(pdev->dev.parent,
> - sizeof(struct sdhci_pltfm_host) + priv_size);
> - else
> - host = sdhci_alloc_host(&pdev->dev,
> - sizeof(struct sdhci_pltfm_host) + priv_size);
> + host = sdhci_alloc_host(&pdev->dev,
> + sizeof(struct sdhci_pltfm_host) + priv_size);
>
> if (IS_ERR(host)) {
> ret = PTR_ERR(host);
> --
> 1.9.1
>
^ permalink raw reply
* Re: [PATCH v3] powerpc/kvm: support to handle sw breakpoint
From: Alexander Graf @ 2014-08-12 12:15 UTC (permalink / raw)
To: Madhavan Srinivasan, Benjamin Herrenschmidt
Cc: linuxppc-dev, paulus, kvm-ppc, kvm
In-Reply-To: <53E9FBF6.5010008@linux.vnet.ibm.com>
On 12.08.14 13:35, Madhavan Srinivasan wrote:
> On Tuesday 12 August 2014 04:49 PM, Alexander Graf wrote:
>> On 12.08.14 07:17, Madhavan Srinivasan wrote:
>>> On Monday 11 August 2014 02:45 PM, Alexander Graf wrote:
>>>> On 11.08.14 10:51, Benjamin Herrenschmidt wrote:
>>>>> On Mon, 2014-08-11 at 09:26 +0200, Alexander Graf wrote:
>>>>>>> diff --git a/arch/powerpc/kvm/emulate.c b/arch/powerpc/kvm/emulate.c
>>>>>>> index da86d9b..d95014e 100644
>>>>>>> --- a/arch/powerpc/kvm/emulate.c
>>>>>>> +++ b/arch/powerpc/kvm/emulate.c
>>>>>> This should be book3s_emulate.c.
>>>>> Any reason we can't make that 00dddd00 opcode as breakpoint common to
>>>>> all powerpc variants ?
>>>> I can't think of a good reason. We use a hypercall on booke (which traps
>>>> into an illegal instruction for pr) today, but I don't think it has to
>>>> be that way.
>>>>
>>>> Given that the user space API allows us to change it dynamically, there
>>>> should be nothing blocking us from going with 00dddd00 always.
>>>>
>>> Kindly correct me if i am wrong. So we can still have a common code in
>>> emulate.c to set the env for both HV and pr incase of illegal
>>> instruction (i will rebase latest src). But suggestion here to use
>>> 00dddd00, in that case current path in embed is kvmppc_handle_exit
>>> (booke.c) -> BOOKE_INTERRUPT_HV_PRIV -> emulation_exit ->
>>> kvmppc_emulate_instruction, will change to kvmppc_handle_exit (booke.c)
>>> -> BOOKE_INTERRUPT_PROGRAM -> if debug instr call emulation_exit else
>>> send to guest?
>> I can't follow your description above.
>>
> My bad.
>
>> With the latest git version HV KVM does not include emulate.c anymore.
>>
>> Also, it would make a lot of sense of have the same soft breakpoint
>> instruction across all ppc targets, so it would make sense to change it
>> to 0x00dddd00 for booke as well.
>>
> Got it. Was describing the current control flow with respect to booke
> and where changes needed (for same software breakpoint inst). This is
> for my understanding and wanted verify.
>
> kvmppc_handle_exit(booke.c)
> -> BOOKE_INTERRUPT_HV_PRIV
> -> emulation_exit
> ->kvmppc_emulate_instruction
>
> Incase of using the same software breakpoint instruction (0x00dddd00),
> then we need to add code in booke something like this
>
> kvmppc_handle_exit (booke.c)
> -> BOOKE_INTERRUPT_PROGRAM
> -> if debug instr
> ->emulation_exit
> else
> ->send to guest?
Bleks. I see your point. I guess you need something like this for booke:
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index 074b7fc..1fdeee0 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -876,6 +876,11 @@ int kvmppc_handle_exit(struct kvm_run *run, struct
kvm_vcpu *vcpu,
case BOOKE_INTERRUPT_HV_PRIV:
emulated = kvmppc_get_last_inst(vcpu, false, &last_inst);
break;
+ case BOOKE_INTERRUPT_PROGRAM:
+ /* SW breakpoints arrive as illegal instructions on HV */
+ if (vcpu->guest_debug & KVM_GUESTDBG_USE_SW_BP)
+ emulated = kvmppc_get_last_inst(vcpu, false, &last_inst);
+ break;
default:
break;
}
@@ -953,7 +958,8 @@ int kvmppc_handle_exit(struct kvm_run *run, struct
kvm_vcpu *vcpu,
break;
case BOOKE_INTERRUPT_PROGRAM:
- if (vcpu->arch.shared->msr & (MSR_PR | MSR_GS)) {
+ if ((vcpu->arch.shared->msr & (MSR_PR | MSR_GS)) &&
+ (last_inst != KVMPPC_INST_SOFT_BREAKPOINT)) {
/*
* Program traps generated by user-level software must
* be handled by the guest kernel.
>
>> Basically you would have handling code in emulate.c and book3s_hv.c at
>> the end of the day.
>>
> Yes. Will resend the patch with updated code.
Thanks,
Alex
^ permalink raw reply related
* Re: [PATCH v3] powerpc/kvm: support to handle sw breakpoint
From: Madhavan Srinivasan @ 2014-08-12 12:21 UTC (permalink / raw)
To: Alexander Graf, Benjamin Herrenschmidt; +Cc: linuxppc-dev, paulus, kvm-ppc, kvm
In-Reply-To: <53EA0572.1070806@suse.de>
On Tuesday 12 August 2014 05:45 PM, Alexander Graf wrote:
>
> On 12.08.14 13:35, Madhavan Srinivasan wrote:
>> On Tuesday 12 August 2014 04:49 PM, Alexander Graf wrote:
>>> On 12.08.14 07:17, Madhavan Srinivasan wrote:
>>>> On Monday 11 August 2014 02:45 PM, Alexander Graf wrote:
>>>>> On 11.08.14 10:51, Benjamin Herrenschmidt wrote:
>>>>>> On Mon, 2014-08-11 at 09:26 +0200, Alexander Graf wrote:
>>>>>>>> diff --git a/arch/powerpc/kvm/emulate.c
>>>>>>>> b/arch/powerpc/kvm/emulate.c
>>>>>>>> index da86d9b..d95014e 100644
>>>>>>>> --- a/arch/powerpc/kvm/emulate.c
>>>>>>>> +++ b/arch/powerpc/kvm/emulate.c
>>>>>>> This should be book3s_emulate.c.
>>>>>> Any reason we can't make that 00dddd00 opcode as breakpoint common to
>>>>>> all powerpc variants ?
>>>>> I can't think of a good reason. We use a hypercall on booke (which
>>>>> traps
>>>>> into an illegal instruction for pr) today, but I don't think it has to
>>>>> be that way.
>>>>>
>>>>> Given that the user space API allows us to change it dynamically,
>>>>> there
>>>>> should be nothing blocking us from going with 00dddd00 always.
>>>>>
>>>> Kindly correct me if i am wrong. So we can still have a common code in
>>>> emulate.c to set the env for both HV and pr incase of illegal
>>>> instruction (i will rebase latest src). But suggestion here to use
>>>> 00dddd00, in that case current path in embed is kvmppc_handle_exit
>>>> (booke.c) -> BOOKE_INTERRUPT_HV_PRIV -> emulation_exit ->
>>>> kvmppc_emulate_instruction, will change to kvmppc_handle_exit (booke.c)
>>>> -> BOOKE_INTERRUPT_PROGRAM -> if debug instr call emulation_exit else
>>>> send to guest?
>>> I can't follow your description above.
>>>
>> My bad.
>>
>>> With the latest git version HV KVM does not include emulate.c anymore.
>>>
>>> Also, it would make a lot of sense of have the same soft breakpoint
>>> instruction across all ppc targets, so it would make sense to change it
>>> to 0x00dddd00 for booke as well.
>>>
>> Got it. Was describing the current control flow with respect to booke
>> and where changes needed (for same software breakpoint inst). This is
>> for my understanding and wanted verify.
>>
>> kvmppc_handle_exit(booke.c)
>> -> BOOKE_INTERRUPT_HV_PRIV
>> -> emulation_exit
>> ->kvmppc_emulate_instruction
>>
>> Incase of using the same software breakpoint instruction (0x00dddd00),
>> then we need to add code in booke something like this
>>
>> kvmppc_handle_exit (booke.c)
>> -> BOOKE_INTERRUPT_PROGRAM
>> -> if debug instr
>> ->emulation_exit
>> else
>> ->send to guest?
>
> Bleks. I see your point. I guess you need something like this for booke:
>
> diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
> index 074b7fc..1fdeee0 100644
> --- a/arch/powerpc/kvm/booke.c
> +++ b/arch/powerpc/kvm/booke.c
> @@ -876,6 +876,11 @@ int kvmppc_handle_exit(struct kvm_run *run, struct
> kvm_vcpu *vcpu,
> case BOOKE_INTERRUPT_HV_PRIV:
> emulated = kvmppc_get_last_inst(vcpu, false, &last_inst);
> break;
> + case BOOKE_INTERRUPT_PROGRAM:
> + /* SW breakpoints arrive as illegal instructions on HV */
> + if (vcpu->guest_debug & KVM_GUESTDBG_USE_SW_BP)
> + emulated = kvmppc_get_last_inst(vcpu, false, &last_inst);
> + break;
> default:
> break;
> }
> @@ -953,7 +958,8 @@ int kvmppc_handle_exit(struct kvm_run *run, struct
> kvm_vcpu *vcpu,
> break;
>
> case BOOKE_INTERRUPT_PROGRAM:
> - if (vcpu->arch.shared->msr & (MSR_PR | MSR_GS)) {
> + if ((vcpu->arch.shared->msr & (MSR_PR | MSR_GS)) &&
> + (last_inst != KVMPPC_INST_SOFT_BREAKPOINT)) {
> /*
> * Program traps generated by user-level software must
> * be handled by the guest kernel.
>
>
>
Ok make sense.
Regards
Maddy
>>
>>> Basically you would have handling code in emulate.c and book3s_hv.c at
>>> the end of the day.
>>>
>> Yes. Will resend the patch with updated code.
>
> Thanks,
>
>
> Alex
>
^ permalink raw reply
* MPC8641D SMP "Processor 1 is stuck"
From: Chris Enrique @ 2014-08-12 14:29 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 3544 bytes --]
Hello,
i am currently working on a GE PPC9A board which has a MPC8641D processor.
My work on this board is currently based on the yocto project (where i also
put this issue on the mailinglist) but the issue affects mainly the
kernel's SMP feature so i want to share this issue here as well and see if
anybody can help:
i created a BSP for this board and yocto generates a fully working 3.14
kernel and rootfs as well as devicetree.
the only thing which is causing problems is SMP. i included the following
kernel options:
CONFIG_SMP=y
CONFIG_SCHED_SMT=y
CONFIG_NR_CPUS=64
Unfortunately, only one CPU is brought up during boot:
...
PID hash table entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Sorting __ex_table...
Memory: 2066916K/2097152K available (4312K kernel code, 188K rwdata, 952K
rodata, 200K init, 131K bss, 30236K reserved, 1310716K highmem)
Kernel virtual memory layout:
* 0xffbdf000..0xfffff000 : fixmap
* 0xff400000..0xff800000 : highmem PTEs
* 0xff3dd000..0xff400000 : early ioremap
* 0xf1000000..0xff3dd000 : vmalloc & ioremap
Preemptible hierarchical RCU implementation.
Dump stacks of tasks blocking RCU-preempt GP.
RCU restricting CPUs from NR_CPUS=64 to nr_cpu_ids=2.
RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2
NR_IRQS:512 nr_irqs:512 16
mpic: Setting up MPIC " MPIC " version 1.2 at fef40000, max 2 CPUs
mpic: ISU size: 256, shift: 8, mask: ff
mpic: Initializing for 256 sources
clocksource: timebase mult[7800001] shift[24] registered
Console: colour dummy device 80x25
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
mpic: requesting IPIs...
ProcePID hash table entries: 4096 (order: 12, 16384 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 2044396k/2097152k available (4464k kernel code, 51632k reserved,
148k data, 145k bss, 196k init)
Kernel virtual memory layout:
* 0xfffe0000..0xfffff000 : fixmap
* 0xff800000..0xffc00000 : highmem PTEs
* 0xff3db000..0xff800000 : early ioremap
* 0xf1000000..0xff3db000 : vmalloc & ioremap
NR_IRQS:512
mpic: Setting up MPIC " MPIC " version 1.2 at fef40000, max 2 CPUs
mpic: ISU size: 256, shift: 8, mask: ff
mpic: Initializing for 256 sources
clocksource: timebase mult[1e00000] shift[22] registered
Console: colour dummy device 80x25
Mount-cache hash table entries: 512
smp_prepare_cpus
mpic: requesting IPIs ...
smp: kicking cpu 1
Processor 1 is stuck.
Brought up 1 CPUs
NET: Registered protocol family 16
...
GE had also released a kernel for this board (2009 2.6 kernel), SMP seems
to fail there as well:
...
Kernel virtual memory layout:
* 0xfffe0000..0xfffff000 : fixmap
* 0xff800000..0xffc00000 : highmem PTEs
* 0xff3db000..0xff800000 : early ioremap
* 0xf1000000..0xff3db000 : vmalloc & ioremap
NR_IRQS:512
mpic: Setting up MPIC " MPIC " version 1.2 at fef40000, max 2 CPUs
mpic: ISU size: 256, shift: 8, mask: ff
mpic: Initializing for 256 sources
clocksource: timebase mult[1e00000] shift[22] registered
Console: colour dummy device 80x25
Mount-cache hash table entries: 512
smp_prepare_cpus
mpic: requesting IPIs ...
smp: kicking cpu 1
Processor 1 is stuck.
Brought up 1 CPUs
...
Does anybody have an idea what might cause this problem?
Kind regards,
Chris
[-- Attachment #2: Type: text/html, Size: 4074 bytes --]
^ permalink raw reply
* Re: [tip:timers/core] timekeeping: Fixup typo in update_vsyscall_old definition
From: John Stultz @ 2014-08-12 15:30 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: sfr, peterz, LKML, linuxppc-dev, Paul Mackerras, hpa, tglx,
Ingo Molnar
In-Reply-To: <1407730744.4508.67.camel@pasglop>
On 08/10/2014 09:19 PM, Benjamin Herrenschmidt wrote:
> On Wed, 2014-07-30 at 00:31 -0700, tip-bot for John Stultz wrote:
>> Commit-ID: 953dec21aed4038464fec02f96a2f1b8701a5bce
>> Gitweb: http://git.kernel.org/tip/953dec21aed4038464fec02f96a2f1b8=
701a5bce
>> Author: John Stultz <john.stultz@linaro.org>
>> AuthorDate: Fri, 25 Jul 2014 21:37:19 -0700
>> Committer: Thomas Gleixner <tglx@linutronix.de>
>> CommitDate: Wed, 30 Jul 2014 09:26:25 +0200
>>
>> timekeeping: Fixup typo in update_vsyscall_old definition
>>
>> In commit 4a0e637738f0 ("clocksource: Get rid of cycle_last"),
>> currently in the -tip tree, there was a small typo where cycles_t
>> was used intstead of cycle_t. This broke ppc64 builds.
> There's another bug in there... You fix timespec vs. timespec64 for the=
> first argument of update_vsyscall_old but not the second one ...
> (wall_to_monotonic).
>
> Also, in e2dff1ec0 you claim this is "minor", you seem to forget that
> arch/powerpc also deals with 32-bit kernels which use the same time
> keeping code, so we have a pretty serious regressions here...
Yikes. My apologies. I had missed that issue and had forgotten ppc32 has
the vsyscall support as well.
Thanks for pointing it out. I'll send a fix here shortly (though I only
have the ppc64le toolchain handy, so forgive me if its not quite right).
> BTW. Is there some documentation you can point me to to figure out what=
> replace that "_OLD" stuff so we can update to whatever is "new" ?
So there's not exactly documentation, but the idea is rather then doing:
nsecs + (mult*(now - cycle_last) >>shift);
We're preserving the sub-nanosecond precision, and doing:
(shifted_nsecs + mult*(now-cycle_last)) >> shift
This avoids the rounding up 1ns every tick, which we did to avoid errors
from truncating the precision.
I think the hard part for ppc, is if I recall, ppc's vsyscall exports
the xsec unit, which less granular then nanoseconds, so it had its own
version of the same precision truncation issues. I recall Paul working
on that, and I thought his solution was to reduce the multiplier by one
so the inter-tick time was slightly slower, then the tick update would
catch up causing a slight stair-step, which isn't ideal but is better
then the inconsistencies that came out of not-handling the precision
properly. That said, skimming the ppc code, I don't see that logic right
off, and have a fuzzy memory that maybe that solution was RHEL5 specific
or something like that.
thanks
-john
^ permalink raw reply
* Re: [RFC PATCH 07/20] x86/MSI: Use msi_chip instead of arch func to configure MSI/MSI-X
From: Konrad Rzeszutek Wilk @ 2014-08-12 19:09 UTC (permalink / raw)
To: Yijing Wang
Cc: linux-mips, linux-ia64, linux-pci, Xinwei Hu, H. Peter Anvin,
sparclinux, linux-s390, Russell King, Joerg Roedel, x86,
Sebastian Ott, xen-devel, arnab.basu, Arnd Bergmann, Marc Zyngier,
Chris Metcalf, Bjorn Helgaas, Thomas Gleixner, linux-arm-kernel,
Tony Luck, linux-kernel, iommu, Wuyun, linuxppc-dev,
David S. Miller
In-Reply-To: <1407828373-24322-8-git-send-email-wangyijing@huawei.com>
On Tue, Aug 12, 2014 at 03:26:00PM +0800, Yijing Wang wrote:
> Introduce a new struct msi_chip apic_msi_chip instead of weak arch
> functions to configure MSI/MSI-X in x86.
Why not 'x86_msi_ops' (see arch/x86/kernel/x86_init.c)
>
> Signed-off-by: Yijing Wang <wangyijing@huawei.com>
> ---
> arch/x86/include/asm/pci.h | 1 +
> arch/x86/kernel/apic/io_apic.c | 20 ++++++++++++++++----
> 2 files changed, 17 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x86/include/asm/pci.h b/arch/x86/include/asm/pci.h
> index 0892ea0..878a06d 100644
> --- a/arch/x86/include/asm/pci.h
> +++ b/arch/x86/include/asm/pci.h
> @@ -101,6 +101,7 @@ void native_teardown_msi_irq(unsigned int irq);
> void native_restore_msi_irqs(struct pci_dev *dev);
> int setup_msi_irq(struct pci_dev *dev, struct msi_desc *msidesc,
> unsigned int irq_base, unsigned int irq_offset);
> +extern struct msi_chip *x86_msi_chip;
> #else
> #define native_setup_msi_irqs NULL
> #define native_teardown_msi_irq NULL
> diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
> index 2609dcd..eb8ab7c 100644
> --- a/arch/x86/kernel/apic/io_apic.c
> +++ b/arch/x86/kernel/apic/io_apic.c
> @@ -3077,24 +3077,25 @@ int setup_msi_irq(struct pci_dev *dev, struct msi_desc *msidesc,
> return 0;
> }
>
> -int native_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
> +int native_setup_msi_irqs(struct device *dev, int nvec, int type)
> {
> struct msi_desc *msidesc;
> unsigned int irq;
> int node, ret;
> + struct pci_dev *pdev = to_pci_dev(dev);
>
> /* Multiple MSI vectors only supported with interrupt remapping */
> if (type == PCI_CAP_ID_MSI && nvec > 1)
> return 1;
>
> - node = dev_to_node(&dev->dev);
> + node = dev_to_node(dev);
>
> - list_for_each_entry(msidesc, &dev->msi_list, list) {
> + list_for_each_entry(msidesc, &pdev->msi_list, list) {
> irq = irq_alloc_hwirq(node);
> if (!irq)
> return -ENOSPC;
>
> - ret = setup_msi_irq(dev, msidesc, irq, 0);
> + ret = setup_msi_irq(pdev, msidesc, irq, 0);
> if (ret < 0) {
> irq_free_hwirq(irq);
> return ret;
> @@ -3214,6 +3215,17 @@ int default_setup_hpet_msi(unsigned int irq, unsigned int id)
> }
> #endif
>
> +struct msi_chip apic_msi_chip = {
> + .setup_irqs = native_setup_msi_irqs,
> + .teardown_irq = native_teardown_msi_irq,
> +};
> +
> +struct msi_chip *arch_get_match_msi_chip(struct device *dev)
> +{
> + return x86_msi_chip;
> +}
> +
> +struct msi_chip *x86_msi_chip = &apic_msi_chip;
> #endif /* CONFIG_PCI_MSI */
> /*
> * Hypertransport interrupt support
> --
> 1.7.1
>
^ permalink raw reply
* Re: [PATCH v3 1/2] printk: Add function to return log buffer address and size
From: Andrew Morton @ 2014-08-12 21:47 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Vasant Hegde, Linus Torvalds, linuxppc-dev, linux-kernel
In-Reply-To: <1407719612.4508.52.camel@pasglop>
On Mon, 11 Aug 2014 11:13:32 +1000 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Sat, 2014-08-09 at 11:15 +0530, Vasant Hegde wrote:
>
> > Ben,
> > - This patchset applies cleanly on powerpc next branch.
> > - Andrew Morton suggested to include this patch in powerpc tree.
> > (https://lists.ozlabs.org/pipermail/linuxppc-dev/2014-August/119802.html)
> >
>
> Ok, Andrew, can I have an Ack ?
Acked-by: Andrew Morton <akpm@linux-foundation.org>
^ permalink raw reply
* Re: [RFC PATCH 07/20] x86/MSI: Use msi_chip instead of arch func to configure MSI/MSI-X
From: Yijing Wang @ 2014-08-13 1:16 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: linux-mips, linux-ia64, linux-pci, Xinwei Hu, H. Peter Anvin,
sparclinux, linux-s390, Russell King, Joerg Roedel, x86,
Sebastian Ott, xen-devel, arnab.basu, Arnd Bergmann, Marc Zyngier,
Chris Metcalf, Bjorn Helgaas, Thomas Gleixner, linux-arm-kernel,
Tony Luck, linux-kernel, iommu, Wuyun, linuxppc-dev,
David S. Miller
In-Reply-To: <20140812190947.GD13996@laptop.dumpdata.com>
On 2014/8/13 3:09, Konrad Rzeszutek Wilk wrote:
> On Tue, Aug 12, 2014 at 03:26:00PM +0800, Yijing Wang wrote:
>> Introduce a new struct msi_chip apic_msi_chip instead of weak arch
>> functions to configure MSI/MSI-X in x86.
>
> Why not 'x86_msi_ops' (see arch/x86/kernel/x86_init.c)
Hi Konrad, I think currently lots of weak arch functions make MSI code
complex, we have following weak arch functions
arch_setup_msi_irqs
arch_setup_msi_irq
arch_msi_check_device
arch_teardown_msi_irqs
arch_teardown_msi_irq
arch_restore_msi_irqs
arch_msi_mask_irq
arch_msix_mask_irq
And Thierry Reding and Thomas Petazzoni introduce a new MSI chip infrastructure which
is used in arm platform now. Use msi_chip let us focus on implementing msi_chip ops functions(no need to implement all),
but now, we should know much of MSI enable flow, then override the weak functions.
I think use the unified MSI framework in all platforms is better.
Also this series is preparation to support Non-PCI MSI device use common MSI framework in linux. Non-PCI MSI devices
include hpet, dmar and the coming consolidator(introduced in ARM GICv3 spec, which is similar to MSI relay device).
Thanks!
Yijing.
>>
>> Signed-off-by: Yijing Wang <wangyijing@huawei.com>
>> ---
>> arch/x86/include/asm/pci.h | 1 +
>> arch/x86/kernel/apic/io_apic.c | 20 ++++++++++++++++----
>> 2 files changed, 17 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/x86/include/asm/pci.h b/arch/x86/include/asm/pci.h
>> index 0892ea0..878a06d 100644
>> --- a/arch/x86/include/asm/pci.h
>> +++ b/arch/x86/include/asm/pci.h
>> @@ -101,6 +101,7 @@ void native_teardown_msi_irq(unsigned int irq);
>> void native_restore_msi_irqs(struct pci_dev *dev);
>> int setup_msi_irq(struct pci_dev *dev, struct msi_desc *msidesc,
>> unsigned int irq_base, unsigned int irq_offset);
>> +extern struct msi_chip *x86_msi_chip;
>> #else
>> #define native_setup_msi_irqs NULL
>> #define native_teardown_msi_irq NULL
>> diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
>> index 2609dcd..eb8ab7c 100644
>> --- a/arch/x86/kernel/apic/io_apic.c
>> +++ b/arch/x86/kernel/apic/io_apic.c
>> @@ -3077,24 +3077,25 @@ int setup_msi_irq(struct pci_dev *dev, struct msi_desc *msidesc,
>> return 0;
>> }
>>
>> -int native_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
>> +int native_setup_msi_irqs(struct device *dev, int nvec, int type)
>> {
>> struct msi_desc *msidesc;
>> unsigned int irq;
>> int node, ret;
>> + struct pci_dev *pdev = to_pci_dev(dev);
>>
>> /* Multiple MSI vectors only supported with interrupt remapping */
>> if (type == PCI_CAP_ID_MSI && nvec > 1)
>> return 1;
>>
>> - node = dev_to_node(&dev->dev);
>> + node = dev_to_node(dev);
>>
>> - list_for_each_entry(msidesc, &dev->msi_list, list) {
>> + list_for_each_entry(msidesc, &pdev->msi_list, list) {
>> irq = irq_alloc_hwirq(node);
>> if (!irq)
>> return -ENOSPC;
>>
>> - ret = setup_msi_irq(dev, msidesc, irq, 0);
>> + ret = setup_msi_irq(pdev, msidesc, irq, 0);
>> if (ret < 0) {
>> irq_free_hwirq(irq);
>> return ret;
>> @@ -3214,6 +3215,17 @@ int default_setup_hpet_msi(unsigned int irq, unsigned int id)
>> }
>> #endif
>>
>> +struct msi_chip apic_msi_chip = {
>> + .setup_irqs = native_setup_msi_irqs,
>> + .teardown_irq = native_teardown_msi_irq,
>> +};
>> +
>> +struct msi_chip *arch_get_match_msi_chip(struct device *dev)
>> +{
>> + return x86_msi_chip;
>> +}
>> +
>> +struct msi_chip *x86_msi_chip = &apic_msi_chip;
>> #endif /* CONFIG_PCI_MSI */
>> /*
>> * Hypertransport interrupt support
>> --
>> 1.7.1
>>
>
> .
>
--
Thanks!
Yijing
^ permalink raw reply
* Re: [tip:timers/core] timekeeping: Fixup typo in update_vsyscall_old definition
From: Tony Breeds @ 2014-08-13 4:03 UTC (permalink / raw)
To: John Stultz
Cc: sfr, peterz, LKML, linuxppc-dev, Paul Mackerras, hpa, tglx,
Ingo Molnar
In-Reply-To: <53EA3320.90908@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 401 bytes --]
On Tue, Aug 12, 2014 at 08:30:40AM -0700, John Stultz wrote:
> Thanks for pointing it out. I'll send a fix here shortly (though I only
> have the ppc64le toolchain handy, so forgive me if its not quite right).
/me pimps the kernel.org toolchains:
https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.9.0/x86_64-gcc-4.9.0-nolibc_powerpc64-linux.tar.xz
and gets back in his box.
Yours Tony
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH] PC, KVM, CMA: Fix regression caused by wrong get_order() use
From: Alexey Kardashevskiy @ 2014-08-13 4:22 UTC (permalink / raw)
To: linuxppc-dev
Cc: kvm, Alexey Kardashevskiy, stable, Alexander Graf, kvm-ppc,
linux-kernel, Gleb Natapov, Paul Mackerras, Aneesh Kumar K.V,
Paolo Bonzini, Joonsoo Kim
fc95ca7284bc54953165cba76c3228bd2cdb9591 claims that there is no
functional change but this is not true as it calls get_order() (which
takes bytes) where it should have called ilog2() and the kernel stops
on VM_BUG_ON().
This replaces get_order() with ilog2().
Suggested-by: Paul Mackerras <paulus@samba.org>
Cc: Alexander Graf <agraf@suse.de>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
arch/powerpc/kvm/book3s_hv_builtin.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_hv_builtin.c b/arch/powerpc/kvm/book3s_hv_builtin.c
index 329d7fd..bfe9f01 100644
--- a/arch/powerpc/kvm/book3s_hv_builtin.c
+++ b/arch/powerpc/kvm/book3s_hv_builtin.c
@@ -101,7 +101,7 @@ struct kvm_rma_info *kvm_alloc_rma()
ri = kmalloc(sizeof(struct kvm_rma_info), GFP_KERNEL);
if (!ri)
return NULL;
- page = cma_alloc(kvm_cma, kvm_rma_pages, get_order(kvm_rma_pages));
+ page = cma_alloc(kvm_cma, kvm_rma_pages, ilog2(kvm_rma_pages));
if (!page)
goto err_out;
atomic_set(&ri->use_count, 1);
@@ -135,12 +135,12 @@ struct page *kvm_alloc_hpt(unsigned long nr_pages)
{
unsigned long align_pages = HPT_ALIGN_PAGES;
- VM_BUG_ON(get_order(nr_pages) < KVM_CMA_CHUNK_ORDER - PAGE_SHIFT);
+ VM_BUG_ON(ilog2(nr_pages) < KVM_CMA_CHUNK_ORDER - PAGE_SHIFT);
/* Old CPUs require HPT aligned on a multiple of its size */
if (!cpu_has_feature(CPU_FTR_ARCH_206))
align_pages = nr_pages;
- return cma_alloc(kvm_cma, nr_pages, get_order(align_pages));
+ return cma_alloc(kvm_cma, nr_pages, ilog2(align_pages));
}
EXPORT_SYMBOL_GPL(kvm_alloc_hpt);
--
2.0.0
^ permalink raw reply related
* [PATCH V2 2/8] powerpc: thp: don't recompute vsid and ssize in loop on invalidate
From: Aneesh Kumar K.V @ 2014-08-13 7:01 UTC (permalink / raw)
To: benh, paulus, mpe; +Cc: linuxppc-dev, Aneesh Kumar K.V
In-Reply-To: <1407913324-8062-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
The segment identifier and segment size will remain the same in
the loop, So we can compute it outside. We also change the
hugepage_invalidate interface so that we can use it the later patch
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/machdep.h | 6 +++---
arch/powerpc/mm/hash_native_64.c | 19 +++++--------------
arch/powerpc/mm/pgtable_64.c | 24 ++++++++++++------------
arch/powerpc/platforms/pseries/lpar.c | 20 ++++++--------------
4 files changed, 26 insertions(+), 43 deletions(-)
diff --git a/arch/powerpc/include/asm/machdep.h b/arch/powerpc/include/asm/machdep.h
index 44e90516519b..b125ceab149c 100644
--- a/arch/powerpc/include/asm/machdep.h
+++ b/arch/powerpc/include/asm/machdep.h
@@ -57,10 +57,10 @@ struct machdep_calls {
void (*hpte_removebolted)(unsigned long ea,
int psize, int ssize);
void (*flush_hash_range)(unsigned long number, int local);
- void (*hugepage_invalidate)(struct mm_struct *mm,
+ void (*hugepage_invalidate)(unsigned long vsid,
+ unsigned long addr,
unsigned char *hpte_slot_array,
- unsigned long addr, int psize);
-
+ int psize, int ssize);
/* special for kexec, to be called in real mode, linear mapping is
* destroyed as well */
void (*hpte_clear_all)(void);
diff --git a/arch/powerpc/mm/hash_native_64.c b/arch/powerpc/mm/hash_native_64.c
index cf1d325eae8b..fb89d7695a9a 100644
--- a/arch/powerpc/mm/hash_native_64.c
+++ b/arch/powerpc/mm/hash_native_64.c
@@ -412,18 +412,18 @@ static void native_hpte_invalidate(unsigned long slot, unsigned long vpn,
local_irq_restore(flags);
}
-static void native_hugepage_invalidate(struct mm_struct *mm,
+static void native_hugepage_invalidate(unsigned long vsid,
+ unsigned long addr,
unsigned char *hpte_slot_array,
- unsigned long addr, int psize)
+ int psize, int ssize)
{
- int ssize = 0, i;
- int lock_tlbie;
+ int i, lock_tlbie;
struct hash_pte *hptep;
int actual_psize = MMU_PAGE_16M;
unsigned int max_hpte_count, valid;
unsigned long flags, s_addr = addr;
unsigned long hpte_v, want_v, shift;
- unsigned long hidx, vpn = 0, vsid, hash, slot;
+ unsigned long hidx, vpn = 0, hash, slot;
shift = mmu_psize_defs[psize].shift;
max_hpte_count = 1U << (PMD_SHIFT - shift);
@@ -437,15 +437,6 @@ static void native_hugepage_invalidate(struct mm_struct *mm,
/* get the vpn */
addr = s_addr + (i * (1ul << shift));
- if (!is_kernel_addr(addr)) {
- ssize = user_segment_size(addr);
- vsid = get_vsid(mm->context.id, addr, ssize);
- WARN_ON(vsid == 0);
- } else {
- vsid = get_kernel_vsid(addr, mmu_kernel_ssize);
- ssize = mmu_kernel_ssize;
- }
-
vpn = hpt_vpn(addr, vsid, ssize);
hash = hpt_hash(vpn, shift, ssize);
if (hidx & _PTEIDX_SECONDARY)
diff --git a/arch/powerpc/mm/pgtable_64.c b/arch/powerpc/mm/pgtable_64.c
index 3b3c4d34c7a0..5039f3b04d6e 100644
--- a/arch/powerpc/mm/pgtable_64.c
+++ b/arch/powerpc/mm/pgtable_64.c
@@ -745,12 +745,21 @@ void hpte_do_hugepage_flush(struct mm_struct *mm, unsigned long addr,
if (!hpte_slot_array)
return;
- /* get the base page size */
+ /* get the base page size,vsid and segment size */
psize = get_slice_psize(mm, s_addr);
+ if (!is_kernel_addr(s_addr)) {
+ ssize = user_segment_size(s_addr);
+ vsid = get_vsid(mm->context.id, s_addr, ssize);
+ WARN_ON(vsid == 0);
+ } else {
+ vsid = get_kernel_vsid(s_addr, mmu_kernel_ssize);
+ ssize = mmu_kernel_ssize;
+ }
if (ppc_md.hugepage_invalidate)
- return ppc_md.hugepage_invalidate(mm, hpte_slot_array,
- s_addr, psize);
+ return ppc_md.hugepage_invalidate(vsid, s_addr,
+ hpte_slot_array,
+ psize, ssize);
/*
* No bluk hpte removal support, invalidate each entry
*/
@@ -768,15 +777,6 @@ void hpte_do_hugepage_flush(struct mm_struct *mm, unsigned long addr,
/* get the vpn */
addr = s_addr + (i * (1ul << shift));
- if (!is_kernel_addr(addr)) {
- ssize = user_segment_size(addr);
- vsid = get_vsid(mm->context.id, addr, ssize);
- WARN_ON(vsid == 0);
- } else {
- vsid = get_kernel_vsid(addr, mmu_kernel_ssize);
- ssize = mmu_kernel_ssize;
- }
-
vpn = hpt_vpn(addr, vsid, ssize);
hash = hpt_hash(vpn, shift, ssize);
if (hidx & _PTEIDX_SECONDARY)
diff --git a/arch/powerpc/platforms/pseries/lpar.c b/arch/powerpc/platforms/pseries/lpar.c
index fbfcef514aa7..34e64237fff9 100644
--- a/arch/powerpc/platforms/pseries/lpar.c
+++ b/arch/powerpc/platforms/pseries/lpar.c
@@ -431,16 +431,17 @@ static void __pSeries_lpar_hugepage_invalidate(unsigned long *slot,
spin_unlock_irqrestore(&pSeries_lpar_tlbie_lock, flags);
}
-static void pSeries_lpar_hugepage_invalidate(struct mm_struct *mm,
- unsigned char *hpte_slot_array,
- unsigned long addr, int psize)
+static void pSeries_lpar_hugepage_invalidate(unsigned long vsid,
+ unsigned long addr,
+ unsigned char *hpte_slot_array,
+ int psize, int ssize)
{
- int ssize = 0, i, index = 0;
+ int i, index = 0;
unsigned long s_addr = addr;
unsigned int max_hpte_count, valid;
unsigned long vpn_array[PPC64_HUGE_HPTE_BATCH];
unsigned long slot_array[PPC64_HUGE_HPTE_BATCH];
- unsigned long shift, hidx, vpn = 0, vsid, hash, slot;
+ unsigned long shift, hidx, vpn = 0, hash, slot;
shift = mmu_psize_defs[psize].shift;
max_hpte_count = 1U << (PMD_SHIFT - shift);
@@ -453,15 +454,6 @@ static void pSeries_lpar_hugepage_invalidate(struct mm_struct *mm,
/* get the vpn */
addr = s_addr + (i * (1ul << shift));
- if (!is_kernel_addr(addr)) {
- ssize = user_segment_size(addr);
- vsid = get_vsid(mm->context.id, addr, ssize);
- WARN_ON(vsid == 0);
- } else {
- vsid = get_kernel_vsid(addr, mmu_kernel_ssize);
- ssize = mmu_kernel_ssize;
- }
-
vpn = hpt_vpn(addr, vsid, ssize);
hash = hpt_hash(vpn, shift, ssize);
if (hidx & _PTEIDX_SECONDARY)
--
1.9.1
^ permalink raw reply related
* [PATCH V2 0/8] THP fixes for ppc64
From: Aneesh Kumar K.V @ 2014-08-13 7:01 UTC (permalink / raw)
To: benh, paulus, mpe; +Cc: linuxppc-dev, Aneesh Kumar K.V
Hi,
This patch series fixes machine check exception that we observed when using
transparent huge page along with 4k hash pte on power bare metal platform.
Patch "powerpc: mm: Use read barrier when creating real_pte" is not really
related to thp, but was added in the series because it is fixing a related
issue with 4k pte. That patch was not really needed to fix the MCE.
Changes from V1:
* Rebased to latest upstream
Aneesh Kumar K.V (8):
powerpc: thp: Add write barrier after updating the valid bit
powerpc: thp: don't recompute vsid and ssize in loop on invalidate
powerpc: thp: invalidate old 64K based hash page mapping before insert
of 4k pte
powerpc: thp: Handle combo pages in invalidate
powerpc: thp: inalidate with vpn in loop
powerpc: thp: use ACCESS_ONCE when loading pmdp
powerpc: mm: Use read barrier when creating real_pte
powerpc: thp: Add tracepoints to track hugepage invalidate
arch/powerpc/include/asm/machdep.h | 6 +--
arch/powerpc/include/asm/pgtable-ppc64.h | 2 +-
arch/powerpc/include/asm/pte-hash64-64k.h | 30 +++++++++--
arch/powerpc/mm/hash_native_64.c | 40 ++++----------
arch/powerpc/mm/hugepage-hash64.c | 88 +++++++++++++++++++++++++++----
arch/powerpc/mm/pgtable_64.c | 44 ++++++++++------
arch/powerpc/mm/tlb_hash64.c | 6 ++-
arch/powerpc/platforms/pseries/lpar.c | 20 +++----
include/trace/events/thp.h | 88 +++++++++++++++++++++++++++++++
9 files changed, 245 insertions(+), 79 deletions(-)
create mode 100644 include/trace/events/thp.h
--
1.9.1
^ permalink raw reply
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