* Re: [PATCH] powerpc/pci: fix PCI-e devices rescan issue on powerpc platform
From: Chen Yuanquan-B41889 @ 2013-04-03 4:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Yuanquan Chen, linux-pci, bhelgaas, linuxppc-dev, Hiroo Matsumoto
In-Reply-To: <1364915422.16520.8.camel@pasglop>
On 04/02/2013 11:10 PM, Benjamin Herrenschmidt wrote:
> On Tue, 2013-04-02 at 19:26 +0800, Yuanquan Chen wrote:
>> So we move the DMA & IRQ initialization code from pcibios_setup_devices() and
>> construct a new function pcibios_enable_device. We call this function in
>> pcibios_enable_device, which will be called by PCI-e rescan code. At the
>> meanwhile, we avoid the the impact on cardbus. I also validate this patch with
>> silicon's PCIe-sata which encounters the IRQ issue.
> My worry is that this delays the setup of the IRQ and DMA to very late in
> the process, possibly after the quirks have been run, which can be
> problematic. We have platform hooks that might try to "fixup" specific
> IRQ issues on some platforms (especially macs) which I worry might fail
> if delayed that way (I may be wrong, I don't have a specific case in mind,
> but I would feel better if we kept setting up these things earlier).
>
> Cheers,
> Ben.
>
Hi Ben,
I have checked all the quirk functions which are declared in kernel
arch/powerpc
with command :
grep DECLARE_PCI_FIXUP_ `find arch/powerpc/ *.[hc]`
All the quirk function are defined as DECLARE_PCI_FIXUP_EARLY ,
DECLARE_PCI_FIXUP_HEADER
and DECLARE_PCI_FIXUP_FINAL, except quirk_uli5229() in
arch/powerpc/platforms/fsl_uli1575.c, which is
defined both as DECLARE_PCI_FIXUP_HEADER and DECLARE_PCI_FIXUP_RESUME.
So the quirk_uli5229()
will also be called with PCI pm module. The quirk functions defined as
xxx_FINAL, HEADER and EARLY,
will be called in the path:
pci_scan_child_bus()->pci_scan_slot()->pci_scan_single_device()->pci_scan_device()->pci_setup_device()
->pci_device_add()
the pci_scan_slot() is called earlier than pcibios_fixup_bus() even for
the first scan of PCI-e bus, so the quirk
functions on powerpc platform is called before the DMA & IRQ fixup. So
in reality, the delay of DMA & IRQ fixup
won't affect anything.
Regards,
Yuanquan
>
>
>
^ permalink raw reply
* RE: [PATCH v2 1/4] powerpc/mpic: add irq_set_wake support
From: Wang Dongsheng-B40534 @ 2013-04-03 2:49 UTC (permalink / raw)
To: Wood Scott-B07421; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1364949416.24520.30@snotra>
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Wednesday, April 03, 2013 8:37 AM
> To: Wang Dongsheng-B40534
> Cc: linuxppc-dev@lists.ozlabs.org; Wang Dongsheng-B40534
> Subject: Re: [PATCH v2 1/4] powerpc/mpic: add irq_set_wake support
>=20
> On 04/02/2013 01:40:37 AM, Wang Dongsheng wrote:
> > Add irq_set_wake support. Just add IRQF_NO_SUSPEND to
> > desc->action->flag.
> > So the wake up interrupt will not be disable in suspend_device_irqs.
> >
> > Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com>
> > ---
> > v2:
> > * Add: Check freescale chip in mpic_irq_set_wake().
> > * Remove: Support mpic_irq_set_wake() in ht_chip.
> >
> > arch/powerpc/sysdev/mpic.c | 18 ++++++++++++++++++
> > 1 file changed, 18 insertions(+)
> >
> > diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
> > index 3b2efd4..50d1ee1 100644
> > --- a/arch/powerpc/sysdev/mpic.c
> > +++ b/arch/powerpc/sysdev/mpic.c
> > @@ -920,6 +920,22 @@ int mpic_set_irq_type(struct irq_data *d,
> > unsigned int flow_type)
> > return IRQ_SET_MASK_OK_NOCOPY;
> > }
> >
> > +static int mpic_irq_set_wake(struct irq_data *d, unsigned int on) {
> > + struct irq_desc *desc =3D container_of(d, struct irq_desc,
> > irq_data);
> > + struct mpic *mpic =3D mpic_from_irq_data(d);
> > +
> > + if (!(mpic->flags & MPIC_FSL))
> > + return -EINVAL;
>=20
> I was thinking more along the lines of using MPIC_FSL during init to
> decide whether to write this function to .irq_set_wake,
I think the static registration method is more reasonable. We must consider
readability. And mpic_irq_set_wake() will not be frequent calls. So within=
=20
mpic_irq_set_wake() to decide is reasonable.
> though that could probably wait until there's a second type of MPIC
> that needs this (if ever).
Even if the mpic_irq_set_wake() register in the first type of MPIC that is =
not
belong MPIC_FSL, the function can return errno. I think the errno should be
"-ENXIO".
See kernel/irq/manage.c, set_irq_wake_real() the return value.
The desc->irq_data.chip->irq_set_wake is null, the errno is -ENXIO.
s/-EINVAL/-ENXIO/
^ permalink raw reply
* [PATCH V2 2/2] powerpc/85xx: workaround for chips with MSI hardware errata
From: Jia Hongtao @ 2013-04-03 2:03 UTC (permalink / raw)
To: linuxppc-dev, galak; +Cc: B07421, hongtao.jia
In-Reply-To: <1364954598-31914-1-git-send-email-hongtao.jia@freescale.com>
The MPIC version 2.0 has a MSI errata (errata PIC1 of mpc8544), It causes
that neither MSI nor MSI-X can work fine. This is a workaround to allow
MSI-X to function properly.
Signed-off-by: Liu Shuo <soniccat.liu@gmail.com>
Signed-off-by: Li Yang <leoli@freescale.com>
Signed-off-by: Jia Hongtao <hongtao.jia@freescale.com>
---
Changes for V2:
* change the name of function mpic_has_errata() to mpic_has_erratum_pic1().
* move MSI_HW_ERRATA_ENDIAN define to fsl_msi.h with all other defines.
arch/powerpc/sysdev/fsl_msi.c | 40 +++++++++++++++++++++++++++++++++++++---
arch/powerpc/sysdev/fsl_msi.h | 2 ++
2 files changed, 39 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_msi.c b/arch/powerpc/sysdev/fsl_msi.c
index 178c994..ca1157a 100644
--- a/arch/powerpc/sysdev/fsl_msi.c
+++ b/arch/powerpc/sysdev/fsl_msi.c
@@ -98,8 +98,18 @@ static int fsl_msi_init_allocator(struct fsl_msi *msi_data)
static int fsl_msi_check_device(struct pci_dev *pdev, int nvec, int type)
{
- if (type == PCI_CAP_ID_MSIX)
- pr_debug("fslmsi: MSI-X untested, trying anyway.\n");
+ struct fsl_msi *msi;
+
+ if (type == PCI_CAP_ID_MSI) {
+ /*
+ * MPIC version 2.0 has erratum PIC1. For now MSI
+ * could not work. So check to prevent MSI from
+ * being used on the board with this erratum.
+ */
+ list_for_each_entry(msi, &msi_head, list)
+ if (msi->feature & MSI_HW_ERRATA_ENDIAN)
+ return -EINVAL;
+ }
return 0;
}
@@ -142,7 +152,17 @@ static void fsl_compose_msi_msg(struct pci_dev *pdev, int hwirq,
msg->address_lo = lower_32_bits(address);
msg->address_hi = upper_32_bits(address);
- msg->data = hwirq;
+ /*
+ * MPIC version 2.0 has erratum PIC1. It causes
+ * that neither MSI nor MSI-X can work fine.
+ * This is a workaround to allow MSI-X to function
+ * properly. It only works for MSI-X, we prevent
+ * MSI on buggy chips in fsl_msi_check_device().
+ */
+ if (msi_data->feature & MSI_HW_ERRATA_ENDIAN)
+ msg->data = __swab32(hwirq);
+ else
+ msg->data = hwirq;
pr_debug("%s: allocated srs: %d, ibs: %d\n",
__func__, hwirq / IRQS_PER_MSI_REG, hwirq % IRQS_PER_MSI_REG);
@@ -361,6 +381,15 @@ static int fsl_msi_setup_hwirq(struct fsl_msi *msi, struct platform_device *dev,
return 0;
}
+/* MPIC version 2.0 has erratum PIC1 */
+static int mpic_has_erratum_pic1(void)
+{
+ if (fsl_mpic_primary_get_version() == 0x0200)
+ return 1;
+
+ return 0;
+}
+
static const struct of_device_id fsl_of_msi_ids[];
static int fsl_of_msi_probe(struct platform_device *dev)
{
@@ -423,6 +452,11 @@ static int fsl_of_msi_probe(struct platform_device *dev)
msi->feature = features->fsl_pic_ip;
+ if ((features->fsl_pic_ip & FSL_PIC_IP_MASK) == FSL_PIC_IP_MPIC) {
+ if (mpic_has_erratum_pic1())
+ msi->feature |= MSI_HW_ERRATA_ENDIAN;
+ }
+
/*
* Remember the phandle, so that we can match with any PCI nodes
* that have an "fsl,msi" property.
diff --git a/arch/powerpc/sysdev/fsl_msi.h b/arch/powerpc/sysdev/fsl_msi.h
index 8225f86..7389e8e 100644
--- a/arch/powerpc/sysdev/fsl_msi.h
+++ b/arch/powerpc/sysdev/fsl_msi.h
@@ -25,6 +25,8 @@
#define FSL_PIC_IP_IPIC 0x00000002
#define FSL_PIC_IP_VMPIC 0x00000003
+#define MSI_HW_ERRATA_ENDIAN 0x00000010
+
struct fsl_msi {
struct irq_domain *irqhost;
--
1.8.0
^ permalink raw reply related
* [PATCH V3 1/2] powerpc/MPIC: Add get_version API both for internal and external use
From: Jia Hongtao @ 2013-04-03 2:03 UTC (permalink / raw)
To: linuxppc-dev, galak; +Cc: B07421, hongtao.jia
MPIC version is useful information for both mpic_alloc() and mpic_init().
The patch provide an API to get MPIC version for reusing the code.
Also, some other IP block may need MPIC version for their own use.
The API for external use is also provided.
Signed-off-by: Jia Hongtao <hongtao.jia@freescale.com>
Signed-off-by: Li Yang <leoli@freescale.com>
---
Changes for V3:
* change the name of function from mpic_primary_get_version() to
fsl_mpic_primary_get_version().
* return 0 if mpic_primary is null.
arch/powerpc/include/asm/mpic.h | 3 +++
arch/powerpc/sysdev/mpic.c | 29 ++++++++++++++++++++++-------
2 files changed, 25 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/include/asm/mpic.h b/arch/powerpc/include/asm/mpic.h
index c0f9ef9..ea6bf72 100644
--- a/arch/powerpc/include/asm/mpic.h
+++ b/arch/powerpc/include/asm/mpic.h
@@ -393,6 +393,9 @@ struct mpic
#define MPIC_REGSET_STANDARD MPIC_REGSET(0) /* Original MPIC */
#define MPIC_REGSET_TSI108 MPIC_REGSET(1) /* Tsi108/109 PIC */
+/* Get the version of primary MPIC */
+extern u32 fsl_mpic_primary_get_version(void);
+
/* Allocate the controller structure and setup the linux irq descs
* for the range if interrupts passed in. No HW initialization is
* actually performed.
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index d30e6a6..e793337 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -1165,10 +1165,30 @@ static struct irq_domain_ops mpic_host_ops = {
.xlate = mpic_host_xlate,
};
+static u32 mpic_get_version(struct mpic *mpic)
+{
+ u32 brr1;
+
+ brr1 = _mpic_read(mpic->reg_type, &mpic->thiscpuregs,
+ MPIC_FSL_BRR1);
+
+ return brr1 & MPIC_FSL_BRR1_VER;
+}
+
/*
* Exported functions
*/
+u32 fsl_mpic_primary_get_version(void)
+{
+ struct mpic *mpic = mpic_primary;
+
+ if (mpic)
+ return mpic_get_version(mpic);
+
+ return 0;
+}
+
struct mpic * __init mpic_alloc(struct device_node *node,
phys_addr_t phys_addr,
unsigned int flags,
@@ -1315,7 +1335,6 @@ struct mpic * __init mpic_alloc(struct device_node *node,
mpic_map(mpic, mpic->paddr, &mpic->tmregs, MPIC_INFO(TIMER_BASE), 0x1000);
if (mpic->flags & MPIC_FSL) {
- u32 brr1;
int ret;
/*
@@ -1326,9 +1345,7 @@ struct mpic * __init mpic_alloc(struct device_node *node,
mpic_map(mpic, mpic->paddr, &mpic->thiscpuregs,
MPIC_CPU_THISBASE, 0x1000);
- brr1 = _mpic_read(mpic->reg_type, &mpic->thiscpuregs,
- MPIC_FSL_BRR1);
- fsl_version = brr1 & MPIC_FSL_BRR1_VER;
+ fsl_version = mpic_get_version(mpic);
/* Error interrupt mask register (EIMR) is required for
* handling individual device error interrupts. EIMR
@@ -1518,9 +1535,7 @@ void __init mpic_init(struct mpic *mpic)
mpic_cpu_write(MPIC_INFO(CPU_CURRENT_TASK_PRI), 0xf);
if (mpic->flags & MPIC_FSL) {
- u32 brr1 = _mpic_read(mpic->reg_type, &mpic->thiscpuregs,
- MPIC_FSL_BRR1);
- u32 version = brr1 & MPIC_FSL_BRR1_VER;
+ u32 version = mpic_get_version(mpic);
/*
* Timer group B is present at the latest in MPIC 3.1 (e.g.
--
1.8.0
^ permalink raw reply related
* Re: [PATCH 5/5 v11] iommu/fsl: Freescale PAMU driver and iommu implementation.
From: Scott Wood @ 2013-04-03 1:52 UTC (permalink / raw)
To: Timur Tabi
Cc: Joerg Roedel, stuart.yoder, lkml, iommu, Varun Sethi,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <CAOZdJXWS50mpgMYu8o8K11yQFU6y-vNwxd9zPkqSd7euGt7XQg@mail.gmail.com>
On 04/02/2013 08:35:54 PM, Timur Tabi wrote:
> On Tue, Apr 2, 2013 at 11:18 AM, Joerg Roedel <joro@8bytes.org> wrote:
>=20
> > > + panic("\n");
> >
> > A kernel panic seems like an over-reaction to an access violation.
>=20
> We have no way to determining what code caused the violation, so we
> can't just kill the process. I agree it seems like overkill, but what
> else should we do? Does the IOMMU layer have a way for the IOMMU
> driver to stop the device that caused the problem?
At a minimum, log a message and continue. Probably turn off the LIODN, =20
at least if it continues to be noisy (otherwise we could get stuck in =20
an interrupt storm as you note). Possibly let the user know somehow, =20
especially if it's a VFIO domain.
Don't take down the whole kernel. It's not just overkill; it =20
undermines VFIO's efforts to make it safe for users to control devices.
> > Besides the device that caused the violation the system should still
> > work, no?
>=20
> Not really. The PAMU was designed to add IOMMU support to legacy
> devices, which have no concept of an MMU. If the PAMU detects an
> access violation, there's no way for the device to recover, because it
> has no idea that a violation has occurred. It's going to keep on
> writing to bad data.
I think that's only the case for posted writes (or devices which fail =20
to take a hint and stop even after they see an I/O error).
-Scott=
^ permalink raw reply
* Re: [PATCH 5/5 v11] iommu/fsl: Freescale PAMU driver and iommu implementation.
From: Timur Tabi @ 2013-04-03 1:35 UTC (permalink / raw)
To: Joerg Roedel
Cc: stuart.yoder, lkml, iommu, scottwood, Varun Sethi,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20130402161812.GI15687@8bytes.org>
On Tue, Apr 2, 2013 at 11:18 AM, Joerg Roedel <joro@8bytes.org> wrote:
> > + panic("\n");
>
> A kernel panic seems like an over-reaction to an access violation.
We have no way to determining what code caused the violation, so we
can't just kill the process. I agree it seems like overkill, but what
else should we do? Does the IOMMU layer have a way for the IOMMU
driver to stop the device that caused the problem?
> Besides the device that caused the violation the system should still
> work, no?
Not really. The PAMU was designed to add IOMMU support to legacy
devices, which have no concept of an MMU. If the PAMU detects an
access violation, there's no way for the device to recover, because it
has no idea that a violation has occurred. It's going to keep on
writing to bad data.
Maybe we need a mechanism where a driver can register a callback
function to handle IOMMU exceptions?
> > + /*
> > + * In case of devices with multiple LIODNs just store
> > + * the info for the first LIODN as all
> > + * LIODNs share the same domain
> > + */
> > + if (!old_domain_info)
> > + dev->archdata.iommu_domain = info;
> > + spin_unlock(&device_domain_lock);
>
> Don't you have to tell the hardware that a device was added to a domain?
> I don't see that, what I am missing?
I'm not sure I understand. What "hardware" do you think needs to be notified?
The PAMU reads everything it needs from the PAACT, which we update.
The PAMU does not know anything about the devices that it monitors,
and the devices don't know anything about the PAMU.
^ permalink raw reply
* Re: [PATCH v2 1/4] powerpc/mpic: add irq_set_wake support
From: Scott Wood @ 2013-04-03 0:36 UTC (permalink / raw)
To: Wang Dongsheng; +Cc: linuxppc-dev, Wang Dongsheng
In-Reply-To: <1364884840-28635-1-git-send-email-dongsheng.wang@freescale.com>
On 04/02/2013 01:40:37 AM, Wang Dongsheng wrote:
> Add irq_set_wake support. Just add IRQF_NO_SUSPEND to =20
> desc->action->flag.
> So the wake up interrupt will not be disable in suspend_device_irqs.
>=20
> Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com>
> ---
> v2:
> * Add: Check freescale chip in mpic_irq_set_wake().
> * Remove: Support mpic_irq_set_wake() in ht_chip.
>=20
> arch/powerpc/sysdev/mpic.c | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>=20
> diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
> index 3b2efd4..50d1ee1 100644
> --- a/arch/powerpc/sysdev/mpic.c
> +++ b/arch/powerpc/sysdev/mpic.c
> @@ -920,6 +920,22 @@ int mpic_set_irq_type(struct irq_data *d, =20
> unsigned int flow_type)
> return IRQ_SET_MASK_OK_NOCOPY;
> }
>=20
> +static int mpic_irq_set_wake(struct irq_data *d, unsigned int on)
> +{
> + struct irq_desc *desc =3D container_of(d, struct irq_desc, =20
> irq_data);
> + struct mpic *mpic =3D mpic_from_irq_data(d);
> +
> + if (!(mpic->flags & MPIC_FSL))
> + return -EINVAL;
I was thinking more along the lines of using MPIC_FSL during init to =20
decide whether to write this function to .irq_set_wake, though that =20
could probably wait until there's a second type of MPIC that needs this =20
(if ever).
-Scott=
^ permalink raw reply
* Re: [PATCH] powerpc: add Book E support to 64-bit hibernation
From: Scott Wood @ 2013-04-03 0:34 UTC (permalink / raw)
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421, Johannes Berg, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <ABB05CD9C9F68C46A5CEDC7F15439259ED9C2E@039-SN2MPN1-021.039d.mgd.msft.net>
On 04/02/2013 12:28:40 AM, Wang Dongsheng-B40534 wrote:
> Hi scott & Johannes,
>=20
> Thanks for reviewing.
>=20
> @scott, About this patch, could you please help ack this patch?
Please investigate the issue of whether we are loading kernel module =20
code in this step, and whether cache flushing is needed as a result.
Is there any chance we could even be loading user code here, e.g. if =20
it's mlocked and thus couldn't be swapped out?
-Scott=
^ permalink raw reply
* [PATCH] powerpc: Add HWCAP2 aux entry
From: Nishanth Aravamudan @ 2013-04-02 21:22 UTC (permalink / raw)
To: benh
Cc: michaele, Steve Munroe, linux-kernel, paulus, Ryan Arnold,
linuxppc-dev
From: Michael Neuling <michael.neuling@au1.ibm.com>
We are currently out of free bits in AT_HWCAP. With POWER8, we have
several hardware features that we need to advertise. Tested on POWER and
x86.
Signed-off-by: Michael Neuling <michael.neuling@au1.ibm.com>
Signed-off-by: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
diff --git a/arch/powerpc/include/asm/cputable.h b/arch/powerpc/include/asm/cputable.h
index fb3245e..ccadad6 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -52,6 +52,7 @@ struct cpu_spec {
char *cpu_name;
unsigned long cpu_features; /* Kernel features */
unsigned int cpu_user_features; /* Userland features */
+ unsigned int cpu_user_features2; /* Userland features v2 */
unsigned int mmu_features; /* MMU features */
/* cache line sizes */
diff --git a/arch/powerpc/include/asm/elf.h b/arch/powerpc/include/asm/elf.h
index ac9790f..cc0655a 100644
--- a/arch/powerpc/include/asm/elf.h
+++ b/arch/powerpc/include/asm/elf.h
@@ -61,6 +61,7 @@ typedef elf_vrregset_t elf_fpxregset_t;
instruction set this cpu supports. This could be done in userspace,
but it's not easy, and we've already done it here. */
# define ELF_HWCAP (cur_cpu_spec->cpu_user_features)
+# define ELF_HWCAP2 (cur_cpu_spec->cpu_user_features2)
/* This yields a string that ld.so will use to load implementation
specific libraries for optimization. This is more specific in
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 3939829..51adc23 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -140,6 +140,13 @@ static int padzero(unsigned long elf_bss)
#define ELF_BASE_PLATFORM NULL
#endif
+/*
+ * Most archs don't need this
+ */
+#ifndef ELF_HWCAP2
+#define ELF_HWCAP2 (0)
+#endif
+
static int
create_elf_tables(struct linux_binprm *bprm, struct elfhdr *exec,
unsigned long load_addr, unsigned long interp_load_addr)
@@ -240,6 +247,7 @@ create_elf_tables(struct linux_binprm *bprm, struct elfhdr *exec,
NEW_AUX_ENT(AT_EGID, from_kgid_munged(cred->user_ns, cred->egid));
NEW_AUX_ENT(AT_SECURE, security_bprm_secureexec(bprm));
NEW_AUX_ENT(AT_RANDOM, (elf_addr_t)(unsigned long)u_rand_bytes);
+ NEW_AUX_ENT(AT_HWCAP2, ELF_HWCAP2);
NEW_AUX_ENT(AT_EXECFN, bprm->exec);
if (k_platform) {
NEW_AUX_ENT(AT_PLATFORM,
diff --git a/fs/binfmt_elf_fdpic.c b/fs/binfmt_elf_fdpic.c
index 9c13e02..0b553d3 100644
--- a/fs/binfmt_elf_fdpic.c
+++ b/fs/binfmt_elf_fdpic.c
@@ -469,6 +469,13 @@ error_kill:
#endif
/*
+ * Most archs don't need this
+ */
+#ifndef ELF_HWCAP2
+#define ELF_HWCAP2 (0)
+#endif
+
+/*
* present useful information to the program by shovelling it onto the new
* process's stack
*/
@@ -483,7 +490,6 @@ static int create_elf_fdpic_tables(struct linux_binprm *bprm,
size_t platform_len = 0, len;
char *k_platform, *k_base_platform;
char __user *u_platform, *u_base_platform, *p;
- long hwcap;
int loop;
int nr; /* reset for each csp adjustment */
@@ -502,8 +508,6 @@ static int create_elf_fdpic_tables(struct linux_binprm *bprm,
return -EFAULT;
#endif
- hwcap = ELF_HWCAP;
-
/*
* If this architecture has a platform capability string, copy it
* to userspace. In some cases (Sparc), this info is impossible
@@ -617,7 +621,8 @@ static int create_elf_fdpic_tables(struct linux_binprm *bprm,
nr = 0;
csp -= DLINFO_ITEMS * 2 * sizeof(unsigned long);
- NEW_AUX_ENT(AT_HWCAP, hwcap);
+ NEW_AUX_ENT(AT_HWCAP, ELF_HWCAP);
+ NEW_AUX_ENT(AT_HWCAP2, ELF_HWCAP2);
NEW_AUX_ENT(AT_PAGESZ, PAGE_SIZE);
NEW_AUX_ENT(AT_CLKTCK, CLOCKS_PER_SEC);
NEW_AUX_ENT(AT_PHDR, exec_params->ph_addr);
diff --git a/include/uapi/linux/auxvec.h b/include/uapi/linux/auxvec.h
index 61594d5..835c065 100644
--- a/include/uapi/linux/auxvec.h
+++ b/include/uapi/linux/auxvec.h
@@ -28,6 +28,7 @@
#define AT_BASE_PLATFORM 24 /* string identifying real platform, may
* differ from AT_PLATFORM. */
#define AT_RANDOM 25 /* address of 16 random bytes */
+#define AT_HWCAP2 26 /* extension of AT_HWCAP */
#define AT_EXECFN 31 /* filename of program */
^ permalink raw reply related
* Re: [PATCH 1/5] powerpc/85xx: add SEC-5.3 device tree
From: Kim Phillips @ 2013-04-02 21:07 UTC (permalink / raw)
To: vakul; +Cc: Shaveta Leekha, linuxppc-dev
In-Reply-To: <1364886874-9580-1-git-send-email-vakul@freescale.com>
On Tue, 2 Apr 2013 12:44:34 +0530
<vakul@freescale.com> wrote:
threading seems broken between patches 1 & 2...
> +crypto: crypto@300000 {
> + compatible = "fsl,sec-v5.3", "fsl,sec-v5.0", "fsl,sec-v4.0";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + reg = <0x300000 0x10000>;
> + ranges = <0 0x300000 0x10000>;
> + interrupts = <92 2 0 0>;
what, no fsl,era? :)
Kim
^ permalink raw reply
* Re: [PATCH V4] powerpc/85xx: Add machine check handler to fix PCIe erratum on mpc85xx
From: Scott Wood @ 2013-04-02 19:46 UTC (permalink / raw)
To: Jia Hongtao-B38951
Cc: Wood Scott-B07421, David Laight, linuxppc-dev@lists.ozlabs.org,
Stuart Yoder
In-Reply-To: <412C8208B4A0464FA894C5F0C278CD5D01C3248C@039-SN1MPN1-003.039d.mgd.msft.net>
On 04/02/2013 04:28:10 AM, Jia Hongtao-B38951 wrote:
>=20
>=20
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Saturday, March 30, 2013 12:34 AM
> > To: Jia Hongtao-B38951
> > Cc: Wood Scott-B07421; David Laight; linuxppc-dev@lists.ozlabs.org;
> > Stuart Yoder
> > Subject: Re: [PATCH V4] powerpc/85xx: Add machine check handler to =20
> fix
> > PCIe erratum on mpc85xx
> >
> > On 03/29/2013 03:03:51 AM, Jia Hongtao-B38951 wrote:
> > > BTW, I'm still not sure how to deal with LD instruction with =20
> update.
> >
> > You would need to do the update yourself. Or just say that's a =20
> case you
> > don't handle, and return 0.
> >
> > Again, please check for the size of the load operation.
> >
> > -Scott
>=20
> For informing error to the process that hold the stall instruction
> we need to do:
> 1. Verify the instruction is load.
> 2. Fill the rd register with ~0UL.
> 3. Deal with the load instruction with update.
>=20
> Here is the problems:
> 1. So many load instructions to handle. There are dozens of load =20
> instructions
> and most of them with different op code. Like:
If you don't want to handle all of them, then don't, but in case you =20
run into an instruction you don't handle, don't skip it -- just let the =20
normal machine check handler run.
>=20
> lbz: 1 0 0 0 1 0
> lhz: 1 0 1 0 0 0
> lwz: 1 0 0 0 0 0
> ld : 1 1 1 0 1 0
> ...
>=20
> Is there any available API for verifying the load instruction?
I don't know of anything in terms of an *API*... after all, you're not =20
just "verifying" it, you're extracting information to determine how to =20
emulate the instruction.
As for code you could borrow from, there's KVM emulation and probably =20
other places.
> 2. For different size of load operation could we just fill the rd =20
> register with
> ~0UL?
Who knows in what ways the compiler is making assumptions about the =20
upper bits being zero after an lbz, etc...
> 3. A load instruction with update could not just verified by op code. =20
> I'd like
> to leave it along. I think we could not fix but just inform the =20
> error by
> filling the rd with ~0UL. Could you explain why should we care =20
> about the update?
If you're emulating the instruction, you need to handle all of that =20
instruction's effects. If you're not going to emulate the instruction, =20
don't skip it.
-Scott=
^ permalink raw reply
* Re: [PATCH 2/5] powerpc/fsl-booke: Add initial silicon device tree files for B4860 and B4420
From: Scott Wood @ 2013-04-02 19:19 UTC (permalink / raw)
To: Shaveta Leekha
Cc: Zhao Chenhui, Tang Yuantian, Shaveta Leekha, Vakul Garg,
Minghuan Lian, Andy Fleming, Ramneek Mehresh, Varun Sethi,
linuxppc-dev
In-Reply-To: <1364886968-9634-1-git-send-email-shaveta@freescale.com>
On 04/02/2013 02:16:05 AM, Shaveta Leekha wrote:
> +/ {
> + compatible =3D "fsl,B4860";
> +
> + cpus {
> + cpu1: PowerPC,e6500@1 {
> + device_type =3D "cpu";
> + reg =3D <2 3>;
> + next-level-cache =3D <&L2>;
> + };
> + cpu2: PowerPC,e6500@2 {
> + device_type =3D "cpu";
> + reg =3D <4 5>;
> + next-level-cache =3D <&L2>;
> + };
> + cpu3: PowerPC,e6500@3 {
> + device_type =3D "cpu";
> + reg =3D <6 7>;
> + next-level-cache =3D <&L2>;
> + };
The unit addresses need to match "reg".
-Scott=
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/85xx: workaround for chips with MSI hardware errata
From: Kumar Gala @ 2013-04-02 18:01 UTC (permalink / raw)
To: Scott Wood
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org, Li Yang-R58472,
Jia Hongtao-B38951
In-Reply-To: <1364924974.24520.8@snotra>
On Apr 2, 2013, at 12:49 PM, Scott Wood wrote:
> On 04/02/2013 01:35:05 AM, Jia Hongtao-B38951 wrote:
>> > -----Original Message-----
>> > From: Wood Scott-B07421
>> > Sent: Saturday, March 30, 2013 5:55 AM
>> > To: Jia Hongtao-B38951
>> > Cc: linuxppc-dev@lists.ozlabs.org; galak@kernel.crashing.org; Wood =
Scott-
>> > B07421; Li Yang-R58472; Jia Hongtao-B38951
>> > Subject: Re: [PATCH 2/2] powerpc/85xx: workaround for chips with =
MSI
>> > hardware errata
>> >
>> > On 03/25/2013 10:28:47 PM, Jia Hongtao wrote:
>> > > The MPIC version 2.0 has a MSI errata (errata PIC1 of mpc8544), =
It
>> > > causes that neither MSI nor MSI-X can work fine. This is a =
workaround
>> > > to allow MSI-X to function properly.
>> > >
>> > > Signed-off-by: Liu Shuo <soniccat.liu@gmail.com>
>> > > Signed-off-by: Li Yang <leoli@freescale.com>
>> > > Signed-off-by: Jia Hongtao <hongtao.jia@freescale.com>
>> > > ---
>> > > arch/powerpc/sysdev/fsl_msi.c | 47
>> > > ++++++++++++++++++++++++++++++++++++++++---
>> > > 1 file changed, 44 insertions(+), 3 deletions(-)
>> > >
>> > > diff --git a/arch/powerpc/sysdev/fsl_msi.c
>> > > b/arch/powerpc/sysdev/fsl_msi.c index 178c994..d2f8040 100644
>> > > --- a/arch/powerpc/sysdev/fsl_msi.c
>> > > +++ b/arch/powerpc/sysdev/fsl_msi.c
>> > > @@ -28,6 +28,8 @@
>> > > #include "fsl_msi.h"
>> > > #include "fsl_pci.h"
>> > >
>> > > +#define MSI_HW_ERRATA_ENDIAN 0x00000010
>> It seems Kumar like put this just in fsl_msi.c.
>> Here is the comments from Kumar few days ago:
>> "Is there any reason to put this in fsl_msi.h rather than just in
>> fsl_msi.c itself?"
>> I think the all the #defines should be together.
>> Ether all in .h or all in .c.
>> In this case I prefer your idea.
>=20
> I don't care which file they go in (though .c is probably better if =
they don't need wider visibility), just as long as they're together.
>=20
> -Scott
Agreed, I didn't realize it was with mixed with the FSL_PIC_IP_* =
defines.
So this should be with:
#define FSL_PIC_IP_MASK 0x0000000F
#define FSL_PIC_IP_MPIC 0x00000001
#define FSL_PIC_IP_IPIC 0x00000002
#define FSL_PIC_IP_VMPIC 0x00000003
in fsl_msi.h
- k=
^ permalink raw reply
* RE: [PATCH 0/5 v11] iommu/fsl: Freescale PAMU driver and IOMMU API implementation.
From: Sethi Varun-B16395 @ 2013-04-02 17:50 UTC (permalink / raw)
To: Joerg Roedel
Cc: Wood Scott-B07421, linux-kernel@vger.kernel.org,
Yoder Stuart-B08248, iommu@lists.linux-foundation.org,
Bhushan Bharat-R65777, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20130402162310.GJ15687@8bytes.org>
> -----Original Message-----
> From: Joerg Roedel [mailto:joro@8bytes.org]
> Sent: Tuesday, April 02, 2013 9:53 PM
> To: Sethi Varun-B16395
> Cc: Yoder Stuart-B08248; Wood Scott-B07421; iommu@lists.linux-
> foundation.org; linuxppc-dev@lists.ozlabs.org; linux-
> kernel@vger.kernel.org; galak@kernel.crashing.org;
> benh@kernel.crashing.org
> Subject: Re: [PATCH 0/5 v11] iommu/fsl: Freescale PAMU driver and IOMMU
> API implementation.
>=20
> On Fri, Mar 29, 2013 at 01:23:57AM +0530, Varun Sethi wrote:
> > This patchset provides the Freescale PAMU (Peripheral Access
> > Management Unit) driver and the corresponding IOMMU API
> > implementation. PAMU is the IOMMU present on Freescale QorIQ
> > platforms. PAMU can authorize memory access, remap the memory address,
> and remap the I/O transaction type.
> >
> > This set consists of the following patches:
> > 1. Make iova dma_addr_t in the iommu_iova_to_phys API.
> > 2. Addition of new field in the device (powerpc) archdata structure for
> storing iommu domain information
> > pointer.
> > 3. Add window permission flags in the iommu_domain_window_enable API.
> > 4. Add domain attributes for FSL PAMU driver.
> > 5. PAMU driver and IOMMU API implementation.
>=20
> Okay, I am about to apply patches 1 and 3 to a new ppc/pamu branch in my
> tree.
>=20
> As a general question, how did you test the IOMMU driver and what will
> you do in the future to avoid regressions?
>=20
I use a kernel module for testing the iommu_api support. The module allows =
for dynamic creation and deletion of iommu domains for the devices in the d=
evice tree. Also, the vfio support (under development) for Freescale SOCs w=
ith APMU hardware would depend on the PAMU driver.
-Varun
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/85xx: workaround for chips with MSI hardware errata
From: Scott Wood @ 2013-04-02 17:49 UTC (permalink / raw)
To: Jia Hongtao-B38951
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org, Li Yang-R58472
In-Reply-To: <412C8208B4A0464FA894C5F0C278CD5D01C32364@039-SN1MPN1-003.039d.mgd.msft.net>
On 04/02/2013 01:35:05 AM, Jia Hongtao-B38951 wrote:
>=20
>=20
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Saturday, March 30, 2013 5:55 AM
> > To: Jia Hongtao-B38951
> > Cc: linuxppc-dev@lists.ozlabs.org; galak@kernel.crashing.org; Wood =20
> Scott-
> > B07421; Li Yang-R58472; Jia Hongtao-B38951
> > Subject: Re: [PATCH 2/2] powerpc/85xx: workaround for chips with MSI
> > hardware errata
> >
> > On 03/25/2013 10:28:47 PM, Jia Hongtao wrote:
> > > The MPIC version 2.0 has a MSI errata (errata PIC1 of mpc8544), It
> > > causes that neither MSI nor MSI-X can work fine. This is a =20
> workaround
> > > to allow MSI-X to function properly.
> > >
> > > Signed-off-by: Liu Shuo <soniccat.liu@gmail.com>
> > > Signed-off-by: Li Yang <leoli@freescale.com>
> > > Signed-off-by: Jia Hongtao <hongtao.jia@freescale.com>
> > > ---
> > > arch/powerpc/sysdev/fsl_msi.c | 47
> > > ++++++++++++++++++++++++++++++++++++++++---
> > > 1 file changed, 44 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/arch/powerpc/sysdev/fsl_msi.c
> > > b/arch/powerpc/sysdev/fsl_msi.c index 178c994..d2f8040 100644
> > > --- a/arch/powerpc/sysdev/fsl_msi.c
> > > +++ b/arch/powerpc/sysdev/fsl_msi.c
> > > @@ -28,6 +28,8 @@
> > > #include "fsl_msi.h"
> > > #include "fsl_pci.h"
> > >
> > > +#define MSI_HW_ERRATA_ENDIAN 0x00000010
>=20
> It seems Kumar like put this just in fsl_msi.c.
> Here is the comments from Kumar few days ago:
>=20
> "Is there any reason to put this in fsl_msi.h rather than just in
> fsl_msi.c itself?"
>=20
> I think the all the #defines should be together.
> Ether all in .h or all in .c.
>=20
> In this case I prefer your idea.
I don't care which file they go in (though .c is probably better if =20
they don't need wider visibility), just as long as they're together.
-Scott=
^ permalink raw reply
* Re: [PATCH 0/5 v11] iommu/fsl: Freescale PAMU driver and IOMMU API implementation.
From: Joerg Roedel @ 2013-04-02 16:23 UTC (permalink / raw)
To: Varun Sethi; +Cc: linux-kernel, stuart.yoder, iommu, scottwood, linuxppc-dev
In-Reply-To: <1364500442-20927-1-git-send-email-Varun.Sethi@freescale.com>
On Fri, Mar 29, 2013 at 01:23:57AM +0530, Varun Sethi wrote:
> This patchset provides the Freescale PAMU (Peripheral Access Management Unit) driver
> and the corresponding IOMMU API implementation. PAMU is the IOMMU present on Freescale
> QorIQ platforms. PAMU can authorize memory access, remap the memory address, and remap
> the I/O transaction type.
>
> This set consists of the following patches:
> 1. Make iova dma_addr_t in the iommu_iova_to_phys API.
> 2. Addition of new field in the device (powerpc) archdata structure for storing iommu domain information
> pointer.
> 3. Add window permission flags in the iommu_domain_window_enable API.
> 4. Add domain attributes for FSL PAMU driver.
> 5. PAMU driver and IOMMU API implementation.
Okay, I am about to apply patches 1 and 3 to a new ppc/pamu branch in my
tree.
As a general question, how did you test the IOMMU driver and what will
you do in the future to avoid regressions?
Joerg
^ permalink raw reply
* Re: [PATCH 5/5 v11] iommu/fsl: Freescale PAMU driver and iommu implementation.
From: Joerg Roedel @ 2013-04-02 16:18 UTC (permalink / raw)
To: Varun Sethi
Cc: Alex Williamson, linux-kernel, stuart.yoder, iommu, scottwood,
linuxppc-dev
In-Reply-To: <1364500442-20927-6-git-send-email-Varun.Sethi@freescale.com>
Cc'ing Alex Williamson
Alex, can you please review the iommu-group part of this patch?
My comments so far are below:
On Fri, Mar 29, 2013 at 01:24:02AM +0530, Varun Sethi wrote:
> +config FSL_PAMU
> + bool "Freescale IOMMU support"
> + depends on PPC_E500MC
> + select IOMMU_API
> + select GENERIC_ALLOCATOR
> + help
> + Freescale PAMU support.
A bit lame for a help text. Can you elaborate more what PAMU is and when
it should be enabled?
> +int pamu_enable_liodn(int liodn)
> +{
> + struct paace *ppaace;
> +
> + ppaace = pamu_get_ppaace(liodn);
> + if (!ppaace) {
> + pr_err("Invalid primary paace entry\n");
> + return -ENOENT;
> + }
> +
> + if (!get_bf(ppaace->addr_bitfields, PPAACE_AF_WSE)) {
> + pr_err("liodn %d not configured\n", liodn);
> + return -EINVAL;
> + }
> +
> + /* Ensure that all other stores to the ppaace complete first */
> + mb();
> +
> + ppaace->addr_bitfields |= PAACE_V_VALID;
> + mb();
Why is it sufficient to set the bit in a variable when enabling liodn
but when disabling it set_bf needs to be called? This looks a bit
assymetric.
> +/* Derive the window size encoding for a particular PAACE entry */
> +static unsigned int map_addrspace_size_to_wse(phys_addr_t addrspace_size)
> +{
> + /* Bug if not a power of 2 */
> + BUG_ON((addrspace_size & (addrspace_size - 1)));
Please use is_power_of_2 here.
> +
> + /* window size is 2^(WSE+1) bytes */
> + return __ffs(addrspace_size >> PAMU_PAGE_SHIFT) + PAMU_PAGE_SHIFT - 1;
The PAMU_PAGE_SHIFT shifting and adding looks redundant.
> + if ((win_size & (win_size - 1)) || win_size < PAMU_PAGE_SIZE) {
> + pr_err("window size too small or not a power of two %llx\n", win_size);
> + return -EINVAL;
> + }
> +
> + if (win_addr & (win_size - 1)) {
> + pr_err("window address is not aligned with window size\n");
> + return -EINVAL;
> + }
Again, use is_power_of_2 instead of hand-coding.
> + if (~stashid != 0)
> + set_bf(paace->impl_attr, PAACE_IA_CID, stashid);
> +
> + smp_wmb();
> +
> + if (enable)
> + paace->addr_bitfields |= PAACE_V_VALID;
Havn't you written a helper funtion to set this bit?
> +irqreturn_t pamu_av_isr(int irq, void *arg)
> +{
> + struct pamu_isr_data *data = arg;
> + phys_addr_t phys;
> + unsigned int i, j;
> +
> + pr_emerg("fsl-pamu: access violation interrupt\n");
> +
> + for (i = 0; i < data->count; i++) {
> + void __iomem *p = data->pamu_reg_base + i * PAMU_OFFSET;
> + u32 pics = in_be32(p + PAMU_PICS);
> +
> + if (pics & PAMU_ACCESS_VIOLATION_STAT) {
> + pr_emerg("POES1=%08x\n", in_be32(p + PAMU_POES1));
> + pr_emerg("POES2=%08x\n", in_be32(p + PAMU_POES2));
> + pr_emerg("AVS1=%08x\n", in_be32(p + PAMU_AVS1));
> + pr_emerg("AVS2=%08x\n", in_be32(p + PAMU_AVS2));
> + pr_emerg("AVA=%016llx\n", make64(in_be32(p + PAMU_AVAH),
> + in_be32(p + PAMU_AVAL)));
> + pr_emerg("UDAD=%08x\n", in_be32(p + PAMU_UDAD));
> + pr_emerg("POEA=%016llx\n", make64(in_be32(p + PAMU_POEAH),
> + in_be32(p + PAMU_POEAL)));
> +
> + phys = make64(in_be32(p + PAMU_POEAH),
> + in_be32(p + PAMU_POEAL));
> +
> + /* Assume that POEA points to a PAACE */
> + if (phys) {
> + u32 *paace = phys_to_virt(phys);
> +
> + /* Only the first four words are relevant */
> + for (j = 0; j < 4; j++)
> + pr_emerg("PAACE[%u]=%08x\n", j, in_be32(paace + j));
> + }
> + }
> + }
> +
> + panic("\n");
A kernel panic seems like an over-reaction to an access violation.
Besides the device that caused the violation the system should still
work, no?
> +#define make64(high, low) (((u64)(high) << 32) | (low))
You redefined this make64 here.
> +static int map_subwins(int liodn, struct fsl_dma_domain *dma_domain)
> +{
> + struct dma_window *sub_win_ptr =
> + &dma_domain->win_arr[0];
> + int i, ret;
> + unsigned long rpn;
> +
> + for (i = 0; i < dma_domain->win_cnt; i++) {
> + if (sub_win_ptr[i].valid) {
> + rpn = sub_win_ptr[i].paddr >>
> + PAMU_PAGE_SHIFT;
> + spin_lock(&iommu_lock);
IOMMU code might run in interrupt context, so please use
spin_lock_irqsave for the iommu_lock.
> +static void detach_device(struct device *dev, struct fsl_dma_domain *dma_domain)
> +{
> + struct device_domain_info *info;
> + struct list_head *entry, *tmp;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&dma_domain->domain_lock, flags);
> + /* Remove the device from the domain device list */
> + if (!list_empty(&dma_domain->devices)) {
> + list_for_each_safe(entry, tmp, &dma_domain->devices) {
> + info = list_entry(entry, struct device_domain_info, link);
> + if (!dev || (info->dev == dev))
> + remove_device_ref(info, dma_domain->win_cnt);
> + }
> + }
> + spin_unlock_irqrestore(&dma_domain->domain_lock, flags);
list_empty check is not needed. You can also use
list_for_each_entry_safe.
> +static void attach_device(struct fsl_dma_domain *dma_domain, int liodn, struct device *dev)
> +{
> + struct device_domain_info *info, *old_domain_info;
> +
> + spin_lock(&device_domain_lock);
> + /*
> + * Check here if the device is already attached to domain or not.
> + * If the device is already attached to a domain detach it.
> + */
> + old_domain_info = find_domain(dev);
> + if (old_domain_info && old_domain_info->domain != dma_domain) {
> + spin_unlock(&device_domain_lock);
> + detach_device(dev, old_domain_info->domain);
> + spin_lock(&device_domain_lock);
> + }
> +
> + info = kmem_cache_zalloc(iommu_devinfo_cache, GFP_KERNEL);
> +
> + info->dev = dev;
> + info->liodn = liodn;
> + info->domain = dma_domain;
> +
> + list_add(&info->link, &dma_domain->devices);
> + /*
> + * In case of devices with multiple LIODNs just store
> + * the info for the first LIODN as all
> + * LIODNs share the same domain
> + */
> + if (!old_domain_info)
> + dev->archdata.iommu_domain = info;
> + spin_unlock(&device_domain_lock);
Don't you have to tell the hardware that a device was added to a domain?
I don't see that, what I am missing?
> +static void swap_pci_ref(struct pci_dev **from, struct pci_dev *to)
> +{
> + pci_dev_put(*from);
> + *from = to;
> +}
Hmm, looks like this function is re-implemented in a few IOMMU drivers.
Want to use the chance to consolidate these implementations?
Joerg
^ permalink raw reply
* RE: [PATCH 5/5 v11] iommu/fsl: Freescale PAMU driver and iommu implementation.
From: Yoder Stuart-B08248 @ 2013-04-02 15:29 UTC (permalink / raw)
To: Sethi Varun-B16395, joro@8bytes.org, Wood Scott-B07421,
iommu@lists.linux-foundation.org, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org, galak@kernel.crashing.org,
benh@kernel.crashing.org
In-Reply-To: <1364500442-20927-6-git-send-email-Varun.Sethi@freescale.com>
> -----Original Message-----
> From: Sethi Varun-B16395
> Sent: Thursday, March 28, 2013 2:54 PM
> To: joro@8bytes.org; Yoder Stuart-B08248; Wood Scott-B07421; iommu@lists.=
linux-foundation.org; linuxppc-
> dev@lists.ozlabs.org; linux-kernel@vger.kernel.org; galak@kernel.crashing=
.org; benh@kernel.crashing.org
> Cc: Sethi Varun-B16395
> Subject: [PATCH 5/5 v11] iommu/fsl: Freescale PAMU driver and iommu imple=
mentation.
>=20
> Following is a brief description of the PAMU hardware:
> PAMU determines what action to take and whether to authorize the action o=
n
> the basis of the memory address, a Logical IO Device Number (LIODN), and
> PAACT table (logically) indexed by LIODN and address. Hardware devices wh=
ich
> need to access memory must provide an LIODN in addition to the memory add=
ress.
>=20
> Peripheral Access Authorization and Control Tables (PAACTs) are the prima=
ry
> data structures used by PAMU. A PAACT is a table of peripheral access
> authorization and control entries (PAACE).Each PAACE defines the range of
> I/O bus address space that is accessible by the LIOD and the associated a=
ccess
> capabilities.
>=20
> There are two types of PAACTs: primary PAACT (PPAACT) and secondary PAACT
> (SPAACT).A given physical I/O device may be able to act as one or more
> independent logical I/O devices (LIODs). Each such logical I/O device is
> assigned an identifier called logical I/O device number (LIODN). A LIODN =
is
> allocated a contiguous portion of the I/O bus address space called the DS=
A window
> for performing DSA operations. The DSA window may optionally be divided i=
nto
> multiple sub-windows, each of which may be used to map to a region in sys=
tem
> storage space. The first sub-window is referred to as the primary sub-win=
dow
> and the remaining are called secondary sub-windows.
>=20
> This patch provides the PAMU driver (fsl_pamu.c) and the corresponding IO=
MMU
> API implementation (fsl_pamu_domain.c). The PAMU hardware driver (fsl_pam=
u.c)
> has been derived from the work done by Ashish Kalra and Timur Tabi.
>=20
> Signed-off-by: Timur Tabi <<timur@tabi.org>
> Signed-off-by: Varun Sethi <Varun.Sethi@freescale.com>
> ---
> changes in v11:
> - changed iova to dma_addr_t in iova_to_phys API.
> changes in v10:
> - Support for new guts compatibe string for T4 & B4 devices.
> - Modified comment about port ID and mentioned the errata number.
> - Fixed the issue where data pointer was not freed in case of a an error.
> - Pass data pointer while freeing irq.
> - Whle initializing the SPAACE entry clear the valid bit.
> changes in v9:
> - Merged and createad a single function to delete
> a device from domain list.
> - Refactored the add_device API code.
> - Renamed the paace and spaace init fucntions.
> - Renamed functions for mapping windows and subwindows.
> - Changed the MAX LIODN value to MAX value u-boot can
> program.
> - Hard coded maximum number of subwindows.
> changes in v8:
> - implemented the new API for window based IOMMUs.
> changes in v7:
> - Set max_subwidows in the geometry attribute.
> - Add checking for maximum supported LIODN value.
> - Use upper_32_bits and lower_32_bits macros while
> intializing PAMU data structures.
> changes in v6:
> - Simplified complex conditional statements.
> - Fixed indentation issues.
> - Added comments for IOMMU API implementation.
> changes in v5:
> - Addressed comments from Timur.
> changes in v4:
> - Addressed comments from Timur and Scott.
> changes in v3:
> - Addressed comments by Kumar Gala
> - dynamic fspi allocation
> - fixed alignment check in map and unmap
> arch/powerpc/sysdev/fsl_pci.h | 5 +
> drivers/iommu/Kconfig | 8 +
> drivers/iommu/Makefile | 1 +
> drivers/iommu/fsl_pamu.c | 1269 +++++++++++++++++++++++++++++++++=
++++++
> drivers/iommu/fsl_pamu.h | 405 +++++++++++++
> drivers/iommu/fsl_pamu_domain.c | 1137 +++++++++++++++++++++++++++++++++=
++
> drivers/iommu/fsl_pamu_domain.h | 85 +++
> 7 files changed, 2910 insertions(+), 0 deletions(-)
> create mode 100644 drivers/iommu/fsl_pamu.c
> create mode 100644 drivers/iommu/fsl_pamu.h
> create mode 100644 drivers/iommu/fsl_pamu_domain.c
> create mode 100644 drivers/iommu/fsl_pamu_domain.h
Ack.
Stuart
^ permalink raw reply
* Re: weird elf header issues, is it binutils or my linker script?
From: Segher Boessenkool @ 2013-04-02 15:07 UTC (permalink / raw)
To: Chris Friesen; +Cc: Paul Mackerras, linuxppc-dev
In-Reply-To: <5159A180.90000@genband.com>
>>> SECTIONS
>>> {
>>> /* Read-only sections, merged into text segment: */
>>> PROVIDE (__executable_start = 0xf2000000); . = 0xf2000000 +
>>> SIZEOF_HEADERS;
>>> .interp : { *(.interp) } :text :interp
>>> <snip>
>>> }
>>>
>>> So I'm wondering...is this something wrong with our linker script,
>>> or is there a bug in our binutils? I'm no linker expert, but the
>>> interpreter sections in the script seem to match the binutils
>>> documentation that I found and I don't see anything that would be
>>> messing with the length.
>>>
>>> Any suggestions on where to look?
>>
>> It looks like your .interp input section lacks the required
>> zero-termination.
>
> That's the weird thing....the actual interpreter string "/lib/ld.so.
> 1" is in fact null-terminated, but the length in the elf headers is
> incorrect (0x30 instead of 0xd) and so when the kernel checks the
> last character in the array it sees a nonzero value.
>
> What I don't understand is where the "/lib/ld.so.1" string is
> coming from and how the length gets set to the invalid value.
It comes from the .interp input sections, i.e. the .interp sections in
the .o files you linked together. Perhaps you have more than one of
those?
Run ld with the -M option to tell you what it does; run readelf -xN
where N is the section number of .interp to figure out what is actually
in there.
Your PT_INTERP has a memsz < filesz, which is curious to say the least.
I suspect there are multiple zero bytes in there; this is not valid in
an ELF file. It would be good if the linker complained about that.
The kernel loader is correct in refusing it (if that is what it is
doing :-) )
Segher
^ permalink raw reply
* Re: [PATCH] powerpc/pci: fix PCI-e devices rescan issue on powerpc platform
From: Benjamin Herrenschmidt @ 2013-04-02 15:10 UTC (permalink / raw)
To: Yuanquan Chen; +Cc: bhelgaas, linux-pci, linuxppc-dev, Hiroo Matsumoto
In-Reply-To: <1364902014-943-1-git-send-email-Yuanquan.Chen@freescale.com>
On Tue, 2013-04-02 at 19:26 +0800, Yuanquan Chen wrote:
> So we move the DMA & IRQ initialization code from pcibios_setup_devices() and
> construct a new function pcibios_enable_device. We call this function in
> pcibios_enable_device, which will be called by PCI-e rescan code. At the
> meanwhile, we avoid the the impact on cardbus. I also validate this patch with
> silicon's PCIe-sata which encounters the IRQ issue.
My worry is that this delays the setup of the IRQ and DMA to very late in
the process, possibly after the quirks have been run, which can be
problematic. We have platform hooks that might try to "fixup" specific
IRQ issues on some platforms (especially macs) which I worry might fail
if delayed that way (I may be wrong, I don't have a specific case in mind,
but I would feel better if we kept setting up these things earlier).
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 4/5 v11] iommu/fsl: Add additional iommu attributes required by the PAMU driver.
From: Joerg Roedel @ 2013-04-02 15:10 UTC (permalink / raw)
To: Varun Sethi; +Cc: linux-kernel, stuart.yoder, iommu, scottwood, linuxppc-dev
In-Reply-To: <1364500442-20927-5-git-send-email-Varun.Sethi@freescale.com>
On Fri, Mar 29, 2013 at 01:24:01AM +0530, Varun Sethi wrote:
> +/* cache stash targets */
> +enum stash_target {
> + IOMMU_ATTR_CACHE_L1 = 1,
> + IOMMU_ATTR_CACHE_L2,
> + IOMMU_ATTR_CACHE_L3,
> +};
> +
> +/* This attribute corresponds to IOMMUs capable of generating
> + * a stash transaction. A stash transaction is typically a
> + * hardware initiated prefetch of data from memory to cache.
> + * This attribute allows configuring stashig specific parameters
> + * in the IOMMU hardware.
> + */
> +
> +struct iommu_stash_attribute {
> + u32 cpu; /* cpu number */
> + u32 cache; /* cache to stash to: L1,L2,L3 */
> +};
> +
I would prefer these PAMU specific enum and struct to be in a
pamu-specific iommu-header.
Joerg
^ permalink raw reply
* Re: [PATCH 2/5 v11] powerpc: Add iommu domain pointer to device archdata
From: Joerg Roedel @ 2013-04-02 15:08 UTC (permalink / raw)
To: Varun Sethi; +Cc: linux-kernel, stuart.yoder, iommu, scottwood, linuxppc-dev
In-Reply-To: <1364500442-20927-3-git-send-email-Varun.Sethi@freescale.com>
On Fri, Mar 29, 2013 at 01:23:59AM +0530, Varun Sethi wrote:
> Add an iommu domain pointer to device (powerpc) archdata. Devices
> are attached to iommu domains and this pointer provides a mechanism
> to correlate between a device and the associated iommu domain. This
> field is set when a device is attached to a domain.
>
> Signed-off-by: Varun Sethi <Varun.Sethi@freescale.com>
This patch needs to be Acked by the PPC maintainers.
^ permalink raw reply
* [PATCH] powerpc/fsl-msi: use a different locklcass for the cascade interrupt
From: Sebastian Andrzej Siewior @ 2013-04-02 13:33 UTC (permalink / raw)
To: Kumar Gala; +Cc: tglx, linuxppc-dev, Sebastian Andrzej Siewior
lockdep thinks that it might deadlock because it grabs a lock of the
same class while calling the generic_irq_handler(). This annotation will
inform lockdep that it will not.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
arch/powerpc/sysdev/fsl_msi.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_msi.c b/arch/powerpc/sysdev/fsl_msi.c
index 178c994..ab02db3 100644
--- a/arch/powerpc/sysdev/fsl_msi.c
+++ b/arch/powerpc/sysdev/fsl_msi.c
@@ -333,6 +333,8 @@ static int fsl_of_msi_remove(struct platform_device *ofdev)
return 0;
}
+static struct lock_class_key fsl_msi_irq_class;
+
static int fsl_msi_setup_hwirq(struct fsl_msi *msi, struct platform_device *dev,
int offset, int irq_index)
{
@@ -351,7 +353,7 @@ static int fsl_msi_setup_hwirq(struct fsl_msi *msi, struct platform_device *dev,
dev_err(&dev->dev, "No memory for MSI cascade data\n");
return -ENOMEM;
}
-
+ irq_set_lockdep_class(virt_msir, &fsl_msi_irq_class);
msi->msi_virqs[irq_index] = virt_msir;
cascade_data->index = offset;
cascade_data->msi_data = msi;
--
1.7.6.5
^ permalink raw reply related
* [PATCH v2 3/3] powerpc/mpc512x: add platform code for MPC5125.
From: Matteo Facchinetti @ 2013-04-02 13:42 UTC (permalink / raw)
To: linuxppc-dev; +Cc: agust
Tested on MPC5125 Tower evaluation board with
mpc512x_defconfig compile configuration.
In detail, supports for:
- PSC / UART
- RTC
- ETH
- DIU
- I2C
Signed-off-by: Matteo Facchinetti <matteo.facchinetti@sirius-es.it>
---
v2:
* change mpc512x_select_psc_compat() implementation
and fix it using const char* return
* drop device_type and port-number properties in mpc5125twr.dts
* add "fsl,mpc5121" and "fsl,mpc5125" in mpc512x dts files
* change reset module name in mpc5125twr.dts (different from mpc5121)
---
arch/powerpc/boot/dts/mpc5121ads.dts | 2 +-
arch/powerpc/boot/dts/mpc5125twr.dts | 233 +++++++++++++++++++++++++
arch/powerpc/boot/dts/pdm360ng.dts | 2 +-
arch/powerpc/platforms/512x/clock.c | 9 +-
arch/powerpc/platforms/512x/mpc512x.h | 1 +
arch/powerpc/platforms/512x/mpc512x_generic.c | 1 +
arch/powerpc/platforms/512x/mpc512x_shared.c | 20 ++-
7 files changed, 264 insertions(+), 4 deletions(-)
create mode 100644 arch/powerpc/boot/dts/mpc5125twr.dts
diff --git a/arch/powerpc/boot/dts/mpc5121ads.dts b/arch/powerpc/boot/dts/mpc5121ads.dts
index f269b13..7d3cb79 100644
--- a/arch/powerpc/boot/dts/mpc5121ads.dts
+++ b/arch/powerpc/boot/dts/mpc5121ads.dts
@@ -13,7 +13,7 @@
/ {
model = "mpc5121ads";
- compatible = "fsl,mpc5121ads";
+ compatible = "fsl,mpc5121ads", "fsl,mpc5121";
nfc@40000000 {
/*
diff --git a/arch/powerpc/boot/dts/mpc5125twr.dts b/arch/powerpc/boot/dts/mpc5125twr.dts
new file mode 100644
index 0000000..c250fb5
--- /dev/null
+++ b/arch/powerpc/boot/dts/mpc5125twr.dts
@@ -0,0 +1,233 @@
+/*
+ * STx/Freescale ADS5125 MPC5125 silicon
+ *
+ * Copyright (C) 2009 Freescale Semiconductor Inc. All rights reserved.
+ *
+ * Reworked by Matteo Facchinetti (engineering@sirius-es.it)
+ * Copyright (C) 2013 Sirius Electronic Systems
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+/dts-v1/;
+
+/ {
+ model = "mpc5125twr"; // In BSP "mpc5125ads"
+ compatible = "fsl,mpc5125ads", "fsl,mpc5125";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ interrupt-parent = <&ipic>;
+
+ aliases {
+ gpio0 = &gpio0;
+ gpio1 = &gpio1;
+ ethernet0 = ð0;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,5125@0 {
+ device_type = "cpu";
+ reg = <0>;
+ d-cache-line-size = <0x20>; // 32 bytes
+ i-cache-line-size = <0x20>; // 32 bytes
+ d-cache-size = <0x8000>; // L1, 32K
+ i-cache-size = <0x8000>; // L1, 32K
+ timebase-frequency = <49500000>;// 49.5 MHz (csb/4)
+ bus-frequency = <198000000>; // 198 MHz csb bus
+ clock-frequency = <396000000>; // 396 MHz ppc core
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x00000000 0x10000000>; // 256MB at 0
+ };
+
+ sram@30000000 {
+ compatible = "fsl,mpc5121-sram";
+ reg = <0x30000000 0x08000>; // 32K at 0x30000000
+ };
+
+ soc@80000000 {
+ compatible = "fsl,mpc5121-immr";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ #interrupt-cells = <2>;
+ ranges = <0x0 0x80000000 0x400000>;
+ reg = <0x80000000 0x400000>;
+ bus-frequency = <66000000>; // 66 MHz ips bus
+
+ // IPIC
+ // interrupts cell = <intr #, sense>
+ // sense values match linux IORESOURCE_IRQ_* defines:
+ // sense == 8: Level, low assertion
+ // sense == 2: Edge, high-to-low change
+ //
+ ipic: interrupt-controller@c00 {
+ compatible = "fsl,mpc5121-ipic", "fsl,ipic";
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <2>;
+ reg = <0xc00 0x100>;
+ };
+
+ rtc@a00 { // Real time clock
+ compatible = "fsl,mpc5121-rtc";
+ reg = <0xa00 0x100>;
+ interrupts = <79 0x8 80 0x8>;
+ };
+
+ reset@e00 { // Reset module
+ compatible = "fsl,mpc5125-reset";
+ reg = <0xe00 0x100>;
+ };
+
+ clock@f00 { // Clock control
+ compatible = "fsl,mpc5121-clock";
+ reg = <0xf00 0x100>;
+ };
+
+ pmc@1000{ // Power Management Controller
+ compatible = "fsl,mpc5121-pmc";
+ reg = <0x1000 0x100>;
+ interrupts = <83 0x2>;
+ };
+
+ gpio0: gpio@1100 {
+ compatible = "fsl,mpc5125-gpio";
+ reg = <0x1100 0x080>;
+ interrupts = <78 0x8>;
+ };
+
+ gpio1: gpio@1180 {
+ compatible = "fsl,mpc5125-gpio";
+ reg = <0x1180 0x080>;
+ interrupts = <86 0x8>;
+ };
+
+ can@1300 { // CAN rev.2
+ compatible = "fsl,mpc5121-mscan";
+ interrupts = <12 0x8>;
+ reg = <0x1300 0x80>;
+ };
+
+ can@1380 {
+ compatible = "fsl,mpc5121-mscan";
+ interrupts = <13 0x8>;
+ reg = <0x1380 0x80>;
+ };
+
+ sdhc@1500 {
+ compatible = "fsl,mpc5121-sdhc";
+ interrupts = <8 0x8>;
+ reg = <0x1500 0x100>;
+ };
+
+ i2c@1700 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl-i2c";
+ reg = <0x1700 0x20>;
+ interrupts = <0x9 0x8>;
+ };
+
+ i2c@1720 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl-i2c";
+ reg = <0x1720 0x20>;
+ interrupts = <0xa 0x8>;
+ };
+
+ i2c@1740 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl-i2c";
+ reg = <0x1740 0x20>;
+ interrupts = <0xb 0x8>;
+ };
+
+ i2ccontrol@1760 {
+ compatible = "fsl,mpc5121-i2c-ctrl";
+ reg = <0x1760 0x8>;
+ };
+
+ diu@2100 {
+ compatible = "fsl,mpc5121-diu";
+ reg = <0x2100 0x100>;
+ interrupts = <64 0x8>;
+ };
+
+ mdio@2800 {
+ compatible = "fsl,mpc5121-fec-mdio";
+ reg = <0x2800 0x800>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ phy0: ethernet-phy@0 {
+ reg = <1>;
+ };
+ };
+
+ eth0: ethernet@2800 {
+ compatible = "fsl,mpc5125-fec";
+ reg = <0x2800 0x800>;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ interrupts = <4 0x8>;
+ phy-handle = < &phy0 >;
+ phy-connection-type = "rmii";
+ };
+
+ // IO control
+ ioctl@a000 {
+ compatible = "fsl,mpc5125-ioctl";
+ reg = <0xA000 0x1000>;
+ };
+
+ usb@3000 {
+ compatible = "fsl,mpc5121-usb2-dr";
+ reg = <0x3000 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <43 0x8>;
+ dr_mode = "host";
+ phy_type = "ulpi";
+ };
+
+ // 5125 PSCs are not 52xx or 5121 PSC compatible
+ // PSC1 uart0 aka ttyPSC0
+ serial@11100 {
+ compatible = "fsl,mpc5125-psc-uart", "fsl,mpc5125-psc";
+ reg = <0x11100 0x100>;
+ interrupts = <40 0x8>;
+ fsl,rx-fifo-size = <16>;
+ fsl,tx-fifo-size = <16>;
+ };
+
+ // PSC9 uart1 aka ttyPSC1
+ serial@11900 {
+ compatible = "fsl,mpc5125-psc-uart", "fsl,mpc5125-psc";
+ reg = <0x11900 0x100>;
+ interrupts = <40 0x8>;
+ fsl,rx-fifo-size = <16>;
+ fsl,tx-fifo-size = <16>;
+ };
+
+ pscfifo@11f00 {
+ compatible = "fsl,mpc5121-psc-fifo";
+ reg = <0x11f00 0x100>;
+ interrupts = <40 0x8>;
+ };
+
+ dma@14000 {
+ compatible = "fsl,mpc5121-dma"; // BSP name: "mpc512x-dma2"
+ reg = <0x14000 0x1800>;
+ interrupts = <65 0x8>;
+ };
+ };
+};
diff --git a/arch/powerpc/boot/dts/pdm360ng.dts b/arch/powerpc/boot/dts/pdm360ng.dts
index 0b06947..7433740 100644
--- a/arch/powerpc/boot/dts/pdm360ng.dts
+++ b/arch/powerpc/boot/dts/pdm360ng.dts
@@ -17,7 +17,7 @@
/ {
model = "pdm360ng";
- compatible = "ifm,pdm360ng";
+ compatible = "ifm,pdm360ng", "fsl,mpc5121";
#address-cells = <1>;
#size-cells = <1>;
interrupt-parent = <&ipic>;
diff --git a/arch/powerpc/platforms/512x/clock.c b/arch/powerpc/platforms/512x/clock.c
index 52d57d2..e504166 100644
--- a/arch/powerpc/platforms/512x/clock.c
+++ b/arch/powerpc/platforms/512x/clock.c
@@ -29,6 +29,8 @@
#include <asm/mpc5121.h>
#include <asm/clk_interface.h>
+#include "mpc512x.h"
+
#undef CLK_DEBUG
static int clocks_initialized;
@@ -683,8 +685,13 @@ static void psc_clks_init(void)
struct device_node *np;
struct platform_device *ofdev;
u32 reg;
+ const char *psc_compat;
+
+ psc_compat = mpc512x_select_psc_compat();
+ if (!psc_compat)
+ return;
- for_each_compatible_node(np, NULL, "fsl,mpc5121-psc") {
+ for_each_compatible_node(np, NULL, psc_compat) {
if (!of_property_read_u32(np, "reg", ®)) {
int pscnum = (reg & 0xf00) >> 8;
struct clk *clk = psc_dev_clk(pscnum);
diff --git a/arch/powerpc/platforms/512x/mpc512x.h b/arch/powerpc/platforms/512x/mpc512x.h
index c32b399..0a8e600 100644
--- a/arch/powerpc/platforms/512x/mpc512x.h
+++ b/arch/powerpc/platforms/512x/mpc512x.h
@@ -15,6 +15,7 @@ extern void __init mpc512x_init_IRQ(void);
extern void __init mpc512x_init(void);
extern int __init mpc5121_clk_init(void);
void __init mpc512x_declare_of_platform_devices(void);
+extern const char *mpc512x_select_psc_compat(void);
extern void mpc512x_restart(char *cmd);
#if defined(CONFIG_FB_FSL_DIU) || defined(CONFIG_FB_FSL_DIU_MODULE)
diff --git a/arch/powerpc/platforms/512x/mpc512x_generic.c b/arch/powerpc/platforms/512x/mpc512x_generic.c
index ca1ca66..1ca7b61 100644
--- a/arch/powerpc/platforms/512x/mpc512x_generic.c
+++ b/arch/powerpc/platforms/512x/mpc512x_generic.c
@@ -28,6 +28,7 @@
*/
static const char * const board[] __initconst = {
"prt,prtlvt",
+ "fsl,mpc5125ads",
NULL
};
diff --git a/arch/powerpc/platforms/512x/mpc512x_shared.c b/arch/powerpc/platforms/512x/mpc512x_shared.c
index d30235b..1ef2fa1 100644
--- a/arch/powerpc/platforms/512x/mpc512x_shared.c
+++ b/arch/powerpc/platforms/512x/mpc512x_shared.c
@@ -350,6 +350,17 @@ void __init mpc512x_declare_of_platform_devices(void)
#define DEFAULT_FIFO_SIZE 16
+const char *mpc512x_select_psc_compat(void)
+{
+ if (of_machine_is_compatible("fsl,mpc5121"))
+ return "fsl,mpc5121-psc";
+
+ if (of_machine_is_compatible("fsl,mpc5125"))
+ return "fsl,mpc5125-psc";
+
+ return NULL;
+}
+
static unsigned int __init get_fifo_size(struct device_node *np,
char *prop_name)
{
@@ -375,9 +386,16 @@ void __init mpc512x_psc_fifo_init(void)
void __iomem *psc;
unsigned int tx_fifo_size;
unsigned int rx_fifo_size;
+ const char *psc_compat;
int fifobase = 0; /* current fifo address in 32 bit words */
- for_each_compatible_node(np, NULL, "fsl,mpc5121-psc") {
+ psc_compat = mpc512x_select_psc_compat();
+ if (!psc_compat) {
+ pr_err("%s: no compatible devices found\n", __func__);
+ return;
+ }
+
+ for_each_compatible_node(np, NULL, psc_compat) {
tx_fifo_size = get_fifo_size(np, "fsl,tx-fifo-size");
rx_fifo_size = get_fifo_size(np, "fsl,rx-fifo-size");
--
1.7.10.4
^ permalink raw reply related
* [PATCH] powerpc/pci: fix PCI-e devices rescan issue on powerpc platform
From: Yuanquan Chen @ 2013-04-02 11:26 UTC (permalink / raw)
To: linuxppc-dev, linux-pci, bhelgaas; +Cc: Yuanquan Chen, Hiroo Matsumoto
Powerpc initializes the DMA and IRQ information in pci_scan_child_bus()->
pcibios_fixup_bus()->pcibios_setup_bus_devices(). But for the devices
which are hotpluged, bus->is added has been set for the first scan of the
PCI-e bus, so the initialization code won't be called. Then the hotpluged
devices' driver will fail to load.
For example :
The PCI-e device 0001:03:00.0 is the Intel PCI-e e1000e network card, remove
it from the system:
# echo 1 > /sys/bus/pci/devices/0001\:03\:00.0/remove
# e1000e 0001:03:00.0 eth0: removed PHC
Rescan it from it's bus:
# echo 1 > /sys/bus/pci/devices/0001\:02\:00.0/rescan
...
e1000e 0001:03:00.0: Disabling ASPM L0s L1
e1000e 0001:03:00.0: No usable DMA configuration, aborting
e1000e: probe of 0001:03:00.0 failed with error -5
So we move the DMA & IRQ initialization code from pcibios_setup_devices() and
construct a new function pcibios_enable_device. We call this function in
pcibios_enable_device, which will be called by PCI-e rescan code. At the
meanwhile, we avoid the the impact on cardbus. I also validate this patch with
silicon's PCIe-sata which encounters the IRQ issue.
Signed-off-by: Yuanquan Chen <Yuanquan.Chen@freescale.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Hiroo Matsumoto <matsumoto.hiroo@jp.fujitsu.com>
---
arch/powerpc/kernel/pci-common.c | 43 +++++++++++++++++++++++---------------
1 file changed, 26 insertions(+), 17 deletions(-)
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index fa12ae4..0324758 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -1023,6 +1023,27 @@ void pcibios_setup_bus_self(struct pci_bus *bus)
ppc_md.pci_dma_bus_setup(bus);
}
+void pcibios_setup_device(struct pci_dev *dev)
+{
+ /* Fixup NUMA node as it may not be setup yet by the generic
+ * code and is needed by the DMA init
+ */
+ set_dev_node(&dev->dev, pcibus_to_node(dev->bus));
+
+ /* Hook up default DMA ops */
+ set_dma_ops(&dev->dev, pci_dma_ops);
+ set_dma_offset(&dev->dev, PCI_DRAM_OFFSET);
+
+ /* Additional platform DMA/iommu setup */
+ if (ppc_md.pci_dma_dev_setup)
+ ppc_md.pci_dma_dev_setup(dev);
+
+ /* Read default IRQs and fixup if necessary */
+ pci_read_irq_line(dev);
+ if (ppc_md.pci_irq_fixup)
+ ppc_md.pci_irq_fixup(dev);
+}
+
void pcibios_setup_bus_devices(struct pci_bus *bus)
{
struct pci_dev *dev;
@@ -1037,23 +1058,7 @@ void pcibios_setup_bus_devices(struct pci_bus *bus)
if (dev->is_added)
continue;
- /* Fixup NUMA node as it may not be setup yet by the generic
- * code and is needed by the DMA init
- */
- set_dev_node(&dev->dev, pcibus_to_node(dev->bus));
-
- /* Hook up default DMA ops */
- set_dma_ops(&dev->dev, pci_dma_ops);
- set_dma_offset(&dev->dev, PCI_DRAM_OFFSET);
-
- /* Additional platform DMA/iommu setup */
- if (ppc_md.pci_dma_dev_setup)
- ppc_md.pci_dma_dev_setup(dev);
-
- /* Read default IRQs and fixup if necessary */
- pci_read_irq_line(dev);
- if (ppc_md.pci_irq_fixup)
- ppc_md.pci_irq_fixup(dev);
+ pcibios_setup_device(dev);
}
}
@@ -1494,6 +1499,10 @@ int pcibios_enable_device(struct pci_dev *dev, int mask)
if (ppc_md.pcibios_enable_device_hook(dev))
return -EINVAL;
+ /* avoid pcie irq fix up impact on cardbus */
+ if (dev->hdr_type != PCI_HEADER_TYPE_CARDBUS)
+ pcibios_setup_device(dev);
+
return pci_enable_resources(dev, mask);
}
--
1.7.9.5
^ 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