RE: [PATCH 2/5] powerpc/fsl-booke: Add initial silicon device tree files for B4860 and B4420
-Original Message-
From: Wood Scott-B07421
Sent: Wednesday, April 03, 2013 12:49 AM
To: Leekha Shaveta-B20052
Cc: linuxppc-dev@lists.ozlabs.org; Zhao Chenhui-B35336; Lian Minghuan-B31939;
Leekha Shaveta-B20052; Garg Vakul-B16394; Tang Yuantian-B29983; Fleming
Andy-AFLEMING; Mehresh Ramneek-B31383; Sethi Varun-B16395
Subject: Re: [PATCH 2/5] powerpc/fsl-booke: Add initial silicon device tree
files for B4860 and B4420
On 04/02/2013 02:16:05 AM, Shaveta Leekha wrote:
> +/ {
> + compatible = "fsl,B4860";
> +
> + cpus {
> + cpu1: PowerPC,e6500@1 {
> + device_type = "cpu";
> + reg = <2 3>;
> + next-level-cache = <&L2>;
> + };
> + cpu2: PowerPC,e6500@2 {
> + device_type = "cpu";
> + reg = <4 5>;
> + next-level-cache = <&L2>;
> + };
> + cpu3: PowerPC,e6500@3 {
> + device_type = "cpu";
> + reg = <6 7>;
> + next-level-cache = <&L2>;
> + };
The unit addresses need to match "reg".
[SL] You mean "@1" should match to "reg = <2 3>" ?
As each e6500 core in B4860 is dual- threaded, reg property here represents the
thread's identifier in that PA core.
So convention used in T4 and B4 is: core 0 having threads 0 and 1,
Core 1 having <2 3> and so
on
Regards,
Shaveta
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] powerpc: add Book E support to 64-bit hibernation
> -Original Message- > From: Wood Scott-B07421 > Sent: Wednesday, April 03, 2013 8:35 AM > To: Wang Dongsheng-B40534 > Cc: Wood Scott-B07421; Johannes Berg; linuxppc-dev@lists.ozlabs.org > Subject: Re: [PATCH] powerpc: add Book E support to 64-bit hibernation > > On 04/02/2013 12:28:40 AM, Wang Dongsheng-B40534 wrote: > > Hi scott & Johannes, > > > > Thanks for reviewing. > > > > @scott, About this patch, could you please help ack this patch? > > Please investigate the issue of whether we are loading kernel module > code in this step, and whether cache flushing is needed as a result. > Sorry, I am not very clear what you mean. When the kernel boot end, modprobe some xx.ko? > Is there any chance we could even be loading user code here, e.g. if > it's mlocked and thus couldn't be swapped out? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 4/5 v11] iommu/fsl: Add additional iommu attributes required by the PAMU driver.
> -Original Message-
> From: Joerg Roedel [mailto:j...@8bytes.org]
> Sent: Tuesday, April 02, 2013 8:40 PM
> To: Sethi Varun-B16395
> Cc: Yoder Stuart-B08248; Wood Scott-B07421; iommu@lists.linux-
> foundation.org; linuxppc-dev@lists.ozlabs.org; linux-
> ker...@vger.kernel.org; ga...@kernel.crashing.org;
> b...@kernel.crashing.org
> Subject: Re: [PATCH 4/5 v11] iommu/fsl: Add additional iommu attributes
> required by the PAMU driver.
>
> 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.
>
[Sethi Varun-B16395] But, these would be used by the IOMMU API users (e.g.
VFIO), they shouldn't depend on PAMU specific headers.
-Varun
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 2/5 v11] powerpc: Add iommu domain pointer to device archdata
Kumar/Ben, Any comments? (Had checked with Ben (on IRC) sometime back, he was fine with this patch) Regards Varun > -Original Message- > From: Joerg Roedel [mailto:j...@8bytes.org] > Sent: Tuesday, April 02, 2013 8:39 PM > To: Sethi Varun-B16395 > Cc: Yoder Stuart-B08248; Wood Scott-B07421; iommu@lists.linux- > foundation.org; linuxppc-dev@lists.ozlabs.org; linux- > ker...@vger.kernel.org; ga...@kernel.crashing.org; > b...@kernel.crashing.org > Subject: Re: [PATCH 2/5 v11] powerpc: Add iommu domain pointer to device > archdata > > 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 > > This patch needs to be Acked by the PPC maintainers. > > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 5/5 v11] iommu/fsl: Freescale PAMU driver and iommu implementation.
> -Original Message-
> From: Wood Scott-B07421
> Sent: Wednesday, April 03, 2013 7:23 AM
> To: Timur Tabi
> Cc: Joerg Roedel; Sethi Varun-B16395; lkml; Kumar Gala; Yoder Stuart-
> B08248; io...@lists.linux-foundation.org; Benjamin Herrenschmidt;
> linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH 5/5 v11] iommu/fsl: Freescale PAMU driver and iommu
> implementation.
>
> On 04/02/2013 08:35:54 PM, Timur Tabi wrote:
> > On Tue, Apr 2, 2013 at 11:18 AM, Joerg Roedel 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?
>
> At a minimum, log a message and continue. Probably turn off the LIODN,
> at least if it continues to be noisy (otherwise we could get stuck in an
> interrupt storm as you note). Possibly let the user know somehow,
> especially if it's a VFIO domain.
[Sethi Varun-B16395] Can definitely log the message and disable the LIODN (to
avoid an interrupt storm), but
we definitely need a mechanism to inform vfio subsystem about the error. Also,
disabling LIODN may not be a viable
option with the new LIODN allocation scheme (where LIODN would be associated
with a domain).
>
> Don't take down the whole kernel. It's not just overkill; it 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?
> >
> > 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 to
> take a hint and stop even after they see an I/O error).
>
[Sethi Varun-B16395] Even in the case where the guest driver detects a failure,
it may not be able to fix the problem without intervention from the VFIO
subsystem.
-Varun
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/pci: fix PCI-e devices rescan issue on powerpc platform
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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v2 1/4] powerpc/mpic: add irq_set_wake support
> -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
>
> 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
> > ---
> > 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 = container_of(d, struct irq_desc,
> > irq_data);
> > + struct mpic *mpic = 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
> 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
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/
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH V2 2/2] powerpc/85xx: workaround for chips with MSI hardware errata
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
Signed-off-by: Li Yang
Signed-off-by: Jia Hongtao
---
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 0x0002
#define FSL_PIC_IP_VMPIC 0x0003
+#define MSI_HW_ERRATA_ENDIAN 0x0010
+
struct fsl_msi {
struct irq_domain *irqhost;
--
1.8.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH V3 1/2] powerpc/MPIC: Add get_version API both for internal and external use
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
Signed-off-by: Li Yang
---
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
#defineMPIC_REGSET_STANDARDMPIC_REGSET(0) /* Original
MPIC */
#defineMPIC_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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 5/5 v11] iommu/fsl: Freescale PAMU driver and iommu implementation.
On 04/02/2013 08:35:54 PM, Timur Tabi wrote:
On Tue, Apr 2, 2013 at 11:18 AM, Joerg Roedel 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?
At a minimum, log a message and continue. Probably turn off the LIODN,
at least if it continues to be noisy (otherwise we could get stuck in
an interrupt storm as you note). Possibly let the user know somehow,
especially if it's a VFIO domain.
Don't take down the whole kernel. It's not just overkill; it
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?
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
to take a hint and stop even after they see an I/O error).
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 5/5 v11] iommu/fsl: Freescale PAMU driver and iommu implementation.
On Tue, Apr 2, 2013 at 11:18 AM, Joerg Roedel 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.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 1/4] powerpc/mpic: add irq_set_wake support
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
---
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 = container_of(d, struct irq_desc,
irq_data);
+ struct mpic *mpic = 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
decide whether to write this function to .irq_set_wake, though that
could probably wait until there's a second type of MPIC that needs this
(if ever).
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: add Book E support to 64-bit hibernation
On 04/02/2013 12:28:40 AM, Wang Dongsheng-B40534 wrote: Hi scott & Johannes, Thanks for reviewing. @scott, About this patch, could you please help ack this patch? Please investigate the issue of whether we are loading kernel module 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 it's mlocked and thus couldn't be swapped out? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Add HWCAP2 aux entry
From: Michael Neuling
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
Signed-off-by: Nishanth Aravamudan
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 intcpu_user_features; /* Userland features */
+ unsigned intcpu_user_features2; /* Userland features v2 */
unsigned intmmu_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 */
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] powerpc/85xx: add SEC-5.3 device tree
On Tue, 2 Apr 2013 12:44:34 +0530
wrote:
threading seems broken between patches 1 & 2...
> +crypto: crypto@30 {
> + compatible = "fsl,sec-v5.3", "fsl,sec-v5.0", "fsl,sec-v4.0";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + reg = <0x30 0x1>;
> + ranges = <0 0x30 0x1>;
> + interrupts = <92 2 0 0>;
what, no fsl,era? :)
Kim
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V4] powerpc/85xx: Add machine check handler to fix PCIe erratum on mpc85xx
On 04/02/2013 04:28:10 AM, Jia Hongtao-B38951 wrote: > -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 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 update. > > You would need to do the update yourself. Or just say that's a case you > don't handle, and return 0. > > Again, please check for the size of the load operation. > > -Scott 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. Here is the problems: 1. So many load instructions to handle. There are dozens of load 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 run into an instruction you don't handle, don't skip it -- just let the normal machine check handler run. 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 ... 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 just "verifying" it, you're extracting information to determine how to emulate the instruction. As for code you could borrow from, there's KVM emulation and probably other places. 2. For different size of load operation could we just fill the rd register with ~0UL? Who knows in what ways the compiler is making assumptions about the upper bits being zero after an lbz, etc... 3. A load instruction with update could not just verified by op code. I'd like to leave it along. I think we could not fix but just inform the error by filling the rd with ~0UL. Could you explain why should we care about the update? If you're emulating the instruction, you need to handle all of that instruction's effects. If you're not going to emulate the instruction, don't skip it. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/5] powerpc/fsl-booke: Add initial silicon device tree files for B4860 and B4420
On 04/02/2013 02:16:05 AM, Shaveta Leekha wrote:
+/ {
+ compatible = "fsl,B4860";
+
+ cpus {
+ cpu1: PowerPC,e6500@1 {
+ device_type = "cpu";
+ reg = <2 3>;
+ next-level-cache = <&L2>;
+ };
+ cpu2: PowerPC,e6500@2 {
+ device_type = "cpu";
+ reg = <4 5>;
+ next-level-cache = <&L2>;
+ };
+ cpu3: PowerPC,e6500@3 {
+ device_type = "cpu";
+ reg = <6 7>;
+ next-level-cache = <&L2>;
+ };
The unit addresses need to match "reg".
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc/85xx: workaround for chips with MSI hardware errata
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; ga...@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 >> > > Signed-off-by: Li Yang >> > > Signed-off-by: Jia Hongtao >> > > --- >> > > 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 0x0010 >> 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. > > 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. > > -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 0x000F #define FSL_PIC_IP_MPIC 0x0001 #define FSL_PIC_IP_IPIC 0x0002 #define FSL_PIC_IP_VMPIC 0x0003 in fsl_msi.h - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 0/5 v11] iommu/fsl: Freescale PAMU driver and IOMMU API implementation.
> -Original Message- > From: Joerg Roedel [mailto:j...@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- > ker...@vger.kernel.org; ga...@kernel.crashing.org; > b...@kernel.crashing.org > Subject: Re: [PATCH 0/5 v11] iommu/fsl: Freescale PAMU driver and IOMMU > API implementation. > > 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? > 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 device tree. Also, the vfio support (under development) for Freescale SOCs with APMU hardware would depend on the PAMU driver. -Varun ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc/85xx: workaround for chips with MSI hardware errata
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; ga...@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 > > Signed-off-by: Li Yang > > Signed-off-by: Jia Hongtao > > --- > > 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 0x0010 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. 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. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/5 v11] iommu/fsl: Freescale PAMU driver and IOMMU API implementation.
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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 5/5 v11] iommu/fsl: Freescale PAMU driver and iommu implementation.
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 *entr
RE: [PATCH 5/5 v11] iommu/fsl: Freescale PAMU driver and iommu implementation.
> -Original Message- > From: Sethi Varun-B16395 > Sent: Thursday, March 28, 2013 2:54 PM > To: j...@8bytes.org; Yoder Stuart-B08248; Wood Scott-B07421; > io...@lists.linux-foundation.org; linuxppc- > d...@lists.ozlabs.org; linux-ker...@vger.kernel.org; > ga...@kernel.crashing.org; b...@kernel.crashing.org > Cc: Sethi Varun-B16395 > Subject: [PATCH 5/5 v11] iommu/fsl: Freescale PAMU driver and iommu > implementation. > > Following is a brief description of the PAMU hardware: > PAMU determines what action to take and whether to authorize the action on > the basis of the memory address, a Logical IO Device Number (LIODN), and > PAACT table (logically) indexed by LIODN and address. Hardware devices which > need to access memory must provide an LIODN in addition to the memory address. > > Peripheral Access Authorization and Control Tables (PAACTs) are the primary > 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 access > capabilities. > > 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 DSA > window > for performing DSA operations. The DSA window may optionally be divided into > multiple sub-windows, each of which may be used to map to a region in system > storage space. The first sub-window is referred to as the primary sub-window > and the remaining are called secondary sub-windows. > > This patch provides the PAMU driver (fsl_pamu.c) and the corresponding IOMMU > API implementation (fsl_pamu_domain.c). The PAMU hardware driver (fsl_pamu.c) > has been derived from the work done by Ashish Kalra and Timur Tabi. > > Signed-off-by: Timur Tabi < > Signed-off-by: Varun Sethi > --- > 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: weird elf header issues, is it binutils or my linker script?
SECTIONS
{
/* Read-only sections, merged into text segment: */
PROVIDE (__executable_start = 0xf200); . = 0xf200 +
SIZEOF_HEADERS;
.interp : { *(.interp) } :text :interp
}
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 thingthe 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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/pci: fix PCI-e devices rescan issue on powerpc platform
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. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 4/5 v11] iommu/fsl: Add additional iommu attributes required by the PAMU driver.
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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/5 v11] powerpc: Add iommu domain pointer to device archdata
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 This patch needs to be Acked by the PPC maintainers. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/fsl-msi: use a different locklcass for the cascade interrupt
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
---
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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 3/3] powerpc/mpc512x: add platform code for MPC5125.
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
---
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@4000 {
/*
diff --git a/arch/powerpc/boot/dts/mpc5125twr.dts
b/arch/powerpc/boot/dts/mpc5125twr.dts
new file mode 100644
index 000..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 (engineer...@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 = <4950>;// 49.5 MHz (csb/4)
+ bus-frequency = <19800>;// 198 MHz csb bus
+ clock-frequency = <39600>; // 396 MHz ppc core
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x 0x1000>; // 256MB at 0
+ };
+
+ sram@3000 {
+ compatible = "fsl,mpc5121-sram";
+ reg = <0x3000 0x08000>; // 32K at 0x3000
+ };
+
+ soc@8000 {
+ compatible = "fsl,mpc5121-immr";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ #interrupt-cells = <2>;
+ ranges = <0x0 0x8000 0x40>;
+ reg = <0x8000 0x40>;
+ bus-frequency = <6600>; // 66 MHz ips bus
+
+ // IPIC
+ // interrupts cell =
+ // 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>;
+
[PATCH] powerpc/pci: fix PCI-e devices rescan issue on powerpc platform
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
Cc: Benjamin Herrenschmidt
Cc: Hiroo Matsumoto
---
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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] powerpc/mpc512x: add platform code for MPC5125.
On Tue, 02 Apr 2013 11:49:22 +0200
Matteo Facchinetti wrote:
...
> > if (of_machine_is_compatible("fsl,mpc5121"))
> > return "fsl,mpc5121-psc";
> >
> > if (of_machine_is_compatible("fsl,mpc5125"))
> > return "fsl,mpc5125-psc";
> >
> > but note that it will only work if we add these compatibles
> > to the compatible list of the root nodes in 5121 and 5125
> > device trees.
>
> I agree with you.
>
> But I don't like that:
> "fsl,mpc5121" is already present in and after its
> inclusion in , compatible root node value is replaced
> by "fsl,mpc5121ads".
>
> Idea is automatically generate
> compatible = "fsl,mpc5121", "fsl,mpc5121ads";
> using dtsi hierarchy.
>
> Is there a way to extend compatible values instead of replace it?
Not that I am aware of. Note that the compatible list should
specify the compatibility from most specific to most general, so
the list in mpc5121ads.dts would look like
compatible = "fsl,mpc5121ads", "fsl,mpc5121";
We can patch in-tree mpc512x dts files accordingly.
Thanks,
Anatolij
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] powerpc/mpc512x: add platform code for MPC5125.
On 03/30/2013 11:32 PM, Anatolij Gustschin wrote:
+{
+ char *psc_compats[] = {
+ "fsl,mpc5121-psc",
+ "fsl,mpc5125-psc"
+ };
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(psc_compats); i++)
+ if (of_find_compatible_node(NULL, NULL, psc_compats[i]))
+ return psc_compats[i];
I don't like this, better would be to use something like:
if (of_machine_is_compatible("fsl,mpc5121"))
return "fsl,mpc5121-psc";
if (of_machine_is_compatible("fsl,mpc5125"))
return "fsl,mpc5125-psc";
but note that it will only work if we add these compatibles
to the compatible list of the root nodes in 5121 and 5125
device trees.
I agree with you.
But I don't like that:
"fsl,mpc5121" is already present in and after its
inclusion in , compatible root node value is replaced
by "fsl,mpc5121ads".
Idea is automatically generate
compatible = "fsl,mpc5121", "fsl,mpc5121ads";
using dtsi hierarchy.
Is there a way to extend compatible values instead of replace it?
Matteo
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH V4] powerpc/85xx: Add machine check handler to fix PCIe erratum on mpc85xx
> -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 fix
> PCIe erratum on mpc85xx
>
> On 03/29/2013 03:03:51 AM, Jia Hongtao-B38951 wrote:
> >
> >
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Saturday, March 16, 2013 12:35 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
> > fix
> > > PCIe erratum on mpc85xx
> > >
> > > On 03/14/2013 09:47:58 PM, Jia Hongtao-B38951 wrote:
> > > >
> > > > > -Original Message-
> > > > > From: Wood Scott-B07421
> > > > > Sent: Thursday, March 14, 2013 12:38 AM
> > > > > To: David Laight
> > > > > Cc: Jia Hongtao-B38951; Wood Scott-B07421;
> > > > linuxppc-dev@lists.ozlabs.org;
> > > > > Stuart Yoder
> > > > > Subject: Re: [PATCH V4] powerpc/85xx: Add machine check handler
> > to
> > > > fix
> > > > > PCIe erratum on mpc85xx
> > > > >
> > > > > On 03/13/2013 04:40:40 AM, David Laight wrote:
> > > > > > > Hmm, seems there's no probe_user_address() -- for userspace
> > we
> > > > > > > basically want the same thing minus the KERNEL_DS. See
> > > > > > > arch/powerpc/perf/callchain.c for an example.
> > > > > >
> > > > > > Isn't that just copy_from_user() ?
> > > > >
> > > > > Plus pagefault_disable/enable().
> > > > >
> > > > > -Scott
> > > >
> > > > pagefault_disable() is identical to preempt_disable(). So I think
> > this
> > > > could not avoid other cpu to swap out the instruction we want to
> > read
> > > > back.
> > > > probe_kernel_address() also have the same issue.
> > >
> > > That's not the point -- the point is to let the page fault handler
> > know
> > > that it should go directly to bad_page_fault(). Do not pass
> > > handle_mm_fault(). Do not collect a page from disk.
> > >
> > > Granted, we're already in atomic context which will have that effect
> > > due to being in the machine check handler, but it's better to be
> > > explicit about it and not depend on how pagefault_diasble() is
> > > implemented.
> > >
> > > -Scott
> >
> >
> > Based on the comments I updated the machine check handler.
> >
> > Changes from last version:
> > * Check MSR_GS state
> > * Check if the instruction is LD
> > * Handle the user space issue
> >
> > The updated machine check handler is as following:
> >
> > int fsl_pci_mcheck_exception(struct pt_regs *regs) {
> > unsigned int op, rd;
> > u32 inst;
> > int ret;
> > phys_addr_t addr = 0;
> >
> > /* Let KVM/QEMU deal with the exception */
> > if (regs->msr & MSR_GS)
> > return 0;
> >
> > #ifdef CONFIG_PHYS_64BIT
> > addr = mfspr(SPRN_MCARU);
> > addr <<= 32;
> > #endif
> > addr += mfspr(SPRN_MCAR);
> >
> > if (is_in_pci_mem_space(addr)) {
> > if (user_mode(regs)) {
> > pagefault_disable();
> > ret = copy_from_user(&(inst), (u32 __user
> > *)regs->nip, sizeof(inst));
> > pagefault_enable();
>
> You could use get_user() instead of copy_from_user().
Got it.
>
> > } else {
> > ret = probe_kernel_address(regs->nip, inst);
> > }
> >
> > op = get_op(inst);
> > /* Check if the instruction is LD */
> > if (!ret && (op == 111010)) {
> > rd = get_rt(inst);
> > regs->gpr[rd] = 0x;
> > }
> >
> > regs->nip += 4;
> > return 1;
> > }
> >
> > return 0;
> > }
> >
> > BTW, I'm still not sure how to deal with LD instruction with update.
>
> You would need to do the update yourself. Or just say that's a case you
> don't handle, and return 0.
>
> Again, please check for the size of the load operation.
>
> -Scott
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.
Here is the problems:
1. So many load instructions to handle. There are dozens of load instructions
and most of them with different op code. Like:
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
...
Is there any available API for verifying the load instruction?
2. For different size of load operation could we just fill the rd register with
~0UL?
3. A load instruction with update could not just verified by op code. I'd like
to leave it along. I think we could not fix but just inform the error by
filling the rd with ~0UL. Could you explain why should we care about the
update?
The ma
[PATCH v2 4/4] powerpc/fsl: add MPIC timer wakeup support
The driver provides a way to wake up the system by the MPIC timer.
For example,
echo 5 > /sys/devices/system/mpic/timer_wakeup
echo standby > /sys/power/state
After 5 seconds the MPIC timer will generate an interrupt to wake up
the system.
Signed-off-by: Wang Dongsheng
Signed-off-by: Zhao Chenhui
Signed-off-by: Li Yang
---
v2:
* Remove: Create mpic subsystem.
arch/powerpc/platforms/Kconfig | 9 ++
arch/powerpc/sysdev/Makefile| 1 +
arch/powerpc/sysdev/fsl_mpic_timer_wakeup.c | 161
3 files changed, 171 insertions(+)
create mode 100644 arch/powerpc/sysdev/fsl_mpic_timer_wakeup.c
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index c447b3c..3d934ba 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -99,6 +99,15 @@ config MPIC_TIMER
chip, but it can potentially support other global timers
complying with the OpenPIC standard.
+config FSL_MPIC_TIMER_WAKEUP
+ tristate "Freescale MPIC global timer wakeup driver"
+ depends on FSL_SOC && MPIC_TIMER && PM
+ default n
+ help
+ The driver provides a way to wake up the system by MPIC
+ timer.
+ e.g. "echo 5 > /sys/devices/system/mpic/timer_wakeup"
+
config PPC_EPAPR_HV_PIC
bool
default n
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index ff6184a..e1b8a80 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -5,6 +5,7 @@ ccflags-$(CONFIG_PPC64) := -mno-minimal-toc
mpic-msi-obj-$(CONFIG_PCI_MSI) += mpic_msi.o mpic_u3msi.o mpic_pasemi_msi.o
obj-$(CONFIG_MPIC) += mpic.o $(mpic-msi-obj-y)
obj-$(CONFIG_MPIC_TIMER)+= mpic_timer.o
+obj-$(CONFIG_FSL_MPIC_TIMER_WAKEUP)+= fsl_mpic_timer_wakeup.o
mpic-msgr-obj-$(CONFIG_MPIC_MSGR) += mpic_msgr.o
obj-$(CONFIG_MPIC) += mpic.o $(mpic-msi-obj-y) $(mpic-msgr-obj-y)
obj-$(CONFIG_PPC_EPAPR_HV_PIC) += ehv_pic.o
diff --git a/arch/powerpc/sysdev/fsl_mpic_timer_wakeup.c
b/arch/powerpc/sysdev/fsl_mpic_timer_wakeup.c
new file mode 100644
index 000..1707bf0
--- /dev/null
+++ b/arch/powerpc/sysdev/fsl_mpic_timer_wakeup.c
@@ -0,0 +1,161 @@
+/*
+ * MPIC timer wakeup driver
+ *
+ * Copyright 2013 Freescale Semiconductor, Inc.
+ *
+ * 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.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+struct fsl_mpic_timer_wakeup {
+ struct mpic_timer *timer;
+ struct work_struct free_work;
+};
+
+static struct fsl_mpic_timer_wakeup *fsl_wakeup;
+static DEFINE_MUTEX(sysfs_lock);
+
+static void fsl_free_resource(struct work_struct *ws)
+{
+ struct fsl_mpic_timer_wakeup *wakeup =
+ container_of(ws, struct fsl_mpic_timer_wakeup, free_work);
+
+ mutex_lock(&sysfs_lock);
+
+ if (wakeup->timer) {
+ disable_irq_wake(wakeup->timer->irq);
+ mpic_free_timer(wakeup->timer);
+ }
+
+ wakeup->timer = NULL;
+ mutex_unlock(&sysfs_lock);
+}
+
+static irqreturn_t fsl_mpic_timer_irq(int irq, void *dev_id)
+{
+ struct fsl_mpic_timer_wakeup *wakeup = dev_id;
+
+ schedule_work(&wakeup->free_work);
+
+ return wakeup->timer ? IRQ_HANDLED : IRQ_NONE;
+}
+
+static ssize_t fsl_timer_wakeup_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct timeval interval;
+ int val = 0;
+
+ mutex_lock(&sysfs_lock);
+ if (fsl_wakeup->timer) {
+ mpic_get_remain_time(fsl_wakeup->timer, &interval);
+ val = interval.tv_sec + 1;
+ }
+ mutex_unlock(&sysfs_lock);
+
+ return sprintf(buf, "%d\n", val);
+}
+
+static ssize_t fsl_timer_wakeup_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf,
+ size_t count)
+{
+ struct timeval interval;
+ int ret;
+
+ interval.tv_usec = 0;
+ if (kstrtol(buf, 0, &interval.tv_sec))
+ return -EINVAL;
+
+ mutex_lock(&sysfs_lock);
+
+ if (fsl_wakeup->timer) {
+ disable_irq_wake(fsl_wakeup->timer->irq);
+ mpic_free_timer(fsl_wakeup->timer);
+ fsl_wakeup->timer = NULL;
+ }
+
+ if (!interval.tv_sec) {
+ mutex_unlock(&sysfs_lock);
+ return count;
+ }
+
+ fsl_wakeup->timer = mpic_request_timer(fsl_mpic_timer_irq,
+ fsl_wakeup, &interval);
+ if (!fsl_wakeup->timer) {
+ mutex_unlock(&sys
[PATCH v2 3/4] powerpc/mpic: create mpic subsystem object
Register a mpic subsystem at /sys/devices/system/
Signed-off-by: Wang Dongsheng
---
arch/powerpc/include/asm/mpic.h | 2 ++
arch/powerpc/sysdev/mpic.c | 8
2 files changed, 10 insertions(+)
diff --git a/arch/powerpc/include/asm/mpic.h b/arch/powerpc/include/asm/mpic.h
index c0f9ef9..fa70e9b 100644
--- a/arch/powerpc/include/asm/mpic.h
+++ b/arch/powerpc/include/asm/mpic.h
@@ -339,6 +339,8 @@ struct mpic
#endif
};
+extern struct bus_type mpic_subsys;
+
/*
* MPIC flags (passed to mpic_alloc)
*
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 50d1ee1..f07cfe0 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -48,6 +48,12 @@
#define DBG(fmt...)
#endif
+struct bus_type mpic_subsys = {
+ .name = "mpic",
+ .dev_name = "mpic",
+};
+EXPORT_SYMBOL_GPL(mpic_subsys);
+
static struct mpic *mpics;
static struct mpic *mpic_primary;
static DEFINE_RAW_SPINLOCK(mpic_lock);
@@ -1989,6 +1995,8 @@ static struct syscore_ops mpic_syscore_ops = {
static int mpic_init_sys(void)
{
register_syscore_ops(&mpic_syscore_ops);
+ subsys_system_register(&mpic_subsys, NULL);
+
return 0;
}
--
1.8.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 2/4] powerpc/mpic: add global timer support
The MPIC global timer is a hardware timer inside the Freescale PIC complying
with OpenPIC standard. When the specified interval times out, the hardware
timer generates an interrupt. The driver currently is only tested on fsl chip,
but it can potentially support other global timers complying to OpenPIC
standard.
The two independent groups of global timer on fsl chip, group A and group B,
are identical in their functionality, except that they appear at different
locations within the PIC register map. The hardware timer can be cascaded to
create timers larger than the default 31-bit global timers. Timer cascade
fields allow configuration of up to two 63-bit timers. But These two groups
of timers cannot be cascaded together.
It can be used as a wakeup source for low power modes. It also could be used
as periodical timer for protocols, drivers and etc.
Signed-off-by: Wang Dongsheng
Signed-off-by: Li Yang
---
v2:
* Modify: Set timer clock frequency in timer_group_get_freq().
* Modify: Change some of the comments.
arch/powerpc/include/asm/mpic_timer.h | 46 +++
arch/powerpc/platforms/Kconfig| 12 +
arch/powerpc/sysdev/Makefile | 1 +
arch/powerpc/sysdev/mpic_timer.c | 593 ++
4 files changed, 652 insertions(+)
create mode 100644 arch/powerpc/include/asm/mpic_timer.h
create mode 100644 arch/powerpc/sysdev/mpic_timer.c
diff --git a/arch/powerpc/include/asm/mpic_timer.h
b/arch/powerpc/include/asm/mpic_timer.h
new file mode 100644
index 000..0e23cd4
--- /dev/null
+++ b/arch/powerpc/include/asm/mpic_timer.h
@@ -0,0 +1,46 @@
+/*
+ * arch/powerpc/include/asm/mpic_timer.h
+ *
+ * Header file for Mpic Global Timer
+ *
+ * Copyright 2013 Freescale Semiconductor, Inc.
+ *
+ * Author: Wang Dongsheng
+ *Li Yang
+ *
+ * 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.
+ */
+
+#ifndef __MPIC_TIMER__
+#define __MPIC_TIMER__
+
+#include
+#include
+
+struct mpic_timer {
+ void*dev;
+ struct cascade_priv *cascade_handle;
+ unsigned intnum;
+ unsigned intirq;
+};
+
+#ifdef CONFIG_MPIC_TIMER
+struct mpic_timer *mpic_request_timer(irq_handler_t fn, void *dev,
+ const struct timeval *time);
+void mpic_start_timer(struct mpic_timer *handle);
+void mpic_stop_timer(struct mpic_timer *handle);
+void mpic_get_remain_time(struct mpic_timer *handle, struct timeval *time);
+void mpic_free_timer(struct mpic_timer *handle);
+#else
+struct mpic_timer *mpic_request_timer(irq_handler_t fn, void *dev,
+ const struct timeval *time) { return NULL; }
+void mpic_start_timer(struct mpic_timer *handle) { }
+void mpic_stop_timer(struct mpic_timer *handle) { }
+void mpic_get_remain_time(struct mpic_timer *handle, struct timeval *time) { }
+void mpic_free_timer(struct mpic_timer *handle) { }
+#endif
+
+#endif
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index 48a920d..c447b3c 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -87,6 +87,18 @@ config MPIC
bool
default n
+config MPIC_TIMER
+ bool "MPIC Global Timer"
+ depends on MPIC && FSL_SOC
+ default n
+ help
+ The MPIC global timer is a hardware timer inside the
+ Freescale PIC complying with OpenPIC standard. When the
+ specified interval times out, the hardware timer generates
+ an interrupt. The driver currently is only tested on fsl
+ chip, but it can potentially support other global timers
+ complying with the OpenPIC standard.
+
config PPC_EPAPR_HV_PIC
bool
default n
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index a57600b..ff6184a 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -4,6 +4,7 @@ ccflags-$(CONFIG_PPC64) := -mno-minimal-toc
mpic-msi-obj-$(CONFIG_PCI_MSI) += mpic_msi.o mpic_u3msi.o mpic_pasemi_msi.o
obj-$(CONFIG_MPIC) += mpic.o $(mpic-msi-obj-y)
+obj-$(CONFIG_MPIC_TIMER)+= mpic_timer.o
mpic-msgr-obj-$(CONFIG_MPIC_MSGR) += mpic_msgr.o
obj-$(CONFIG_MPIC) += mpic.o $(mpic-msi-obj-y) $(mpic-msgr-obj-y)
obj-$(CONFIG_PPC_EPAPR_HV_PIC) += ehv_pic.o
diff --git a/arch/powerpc/sysdev/mpic_timer.c b/arch/powerpc/sysdev/mpic_timer.c
new file mode 100644
index 000..c06db92
--- /dev/null
+++ b/arch/powerpc/sysdev/mpic_timer.c
@@ -0,0 +1,593 @@
+/*
+ * MPIC timer driver
+ *
+ * Copyright 2013 Freescale Semiconductor, Inc.
+ * Author: Dongsheng Wang
+ *Li Yang
+ *
+ * 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
[PATCH v2 1/4] powerpc/mpic: add irq_set_wake support
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
---
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 = container_of(d, struct irq_desc, irq_data);
+ struct mpic *mpic = mpic_from_irq_data(d);
+
+ if (!(mpic->flags & MPIC_FSL))
+ return -EINVAL;
+
+ if (on)
+ desc->action->flags |= IRQF_NO_SUSPEND;
+ else
+ desc->action->flags &= ~IRQF_NO_SUSPEND;
+
+ return 0;
+}
+
void mpic_set_vector(unsigned int virq, unsigned int vector)
{
struct mpic *mpic = mpic_from_irq(virq);
@@ -957,6 +973,7 @@ static struct irq_chip mpic_irq_chip = {
.irq_unmask = mpic_unmask_irq,
.irq_eoi= mpic_end_irq,
.irq_set_type = mpic_set_irq_type,
+ .irq_set_wake = mpic_irq_set_wake,
};
#ifdef CONFIG_SMP
@@ -971,6 +988,7 @@ static struct irq_chip mpic_tm_chip = {
.irq_mask = mpic_mask_tm,
.irq_unmask = mpic_unmask_tm,
.irq_eoi= mpic_end_irq,
+ .irq_set_wake = mpic_irq_set_wake,
};
#ifdef CONFIG_MPIC_U3_HT_IRQS
--
1.8.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/5] powerpc/fsl-booke: Add initial silicon device tree files for B4860 and B4420
B4860 and B4420 are similar that share some commonalities
* common features have been added in b4si-pre.dtsi and b4si-post.dtsi
* differences are added in respective silicon files of B4860 and B4420
There are several things missing from the device trees of B4860 and B4420:
* DPAA related nodes (Qman, Bman, Fman, Rman)
* DSP related nodes/information
Signed-off-by: Shaveta Leekha
Signed-off-by: Zhao Chenhui
Signed-off-by: Li Yang
Signed-off-by: Tang Yuantian
Signed-off-by: Varun Sethi
Signed-off-by: Minghuan Lian
Signed-off-by: Ramneek Mehresh
Signed-off-by: Kumar Gala
Signed-off-by: Andy Fleming
Signed-off-by: Vakul Garg
---
arch/powerpc/boot/dts/fsl/b4420si-post.dtsi | 94 ++
arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi | 49 +
arch/powerpc/boot/dts/fsl/b4860si-post.dtsi | 138 ++
arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi | 59 ++
arch/powerpc/boot/dts/fsl/b4si-post.dtsi| 262 +++
arch/powerpc/boot/dts/fsl/b4si-pre.dtsi | 65 +++
6 files changed, 667 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/fsl/b4420si-post.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/b4si-post.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/b4si-pre.dtsi
diff --git a/arch/powerpc/boot/dts/fsl/b4420si-post.dtsi
b/arch/powerpc/boot/dts/fsl/b4420si-post.dtsi
new file mode 100644
index 000..bba0c03
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/b4420si-post.dtsi
@@ -0,0 +1,94 @@
+/*
+ * B4420 Silicon/SoC Device Tree Source (post include)
+ *
+ * Copyright 2012 Freescale Semiconductor, Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * This software is provided by Freescale Semiconductor "as is" and any
+ * express or implied warranties, including, but not limited to, the implied
+ * warranties of merchantability and fitness for a particular purpose are
+ * disclaimed. In no event shall Freescale Semiconductor be liable for any
+ * direct, indirect, incidental, special, exemplary, or consequential damages
+ * (including, but not limited to, procurement of substitute goods or services;
+ * loss of use, data, or profits; or business interruption) however caused and
+ * on any theory of liability, whether in contract, strict liability, or tort
+ * (including negligence or otherwise) arising in any way out of the use of
+ * this software, even if advised of the possibility of such damage.
+ */
+
+/include/ "b4si-post.dtsi"
+
+/* controller at 0x20 */
+&pci0 {
+ compatible = "fsl,b4420-pcie", "fsl,qoriq-pcie-v2.4";
+};
+
+&dcsr {
+ dcsr-epu@0 {
+ compatible = "fsl,b4420-dcsr-epu", "fsl,dcsr-epu";
+ };
+ dcsr-npc {
+ compatible = "fsl,b4420-dcsr-cnpc", "fsl,dcsr-cnpc";
+ };
+ dcsr-dpaa@9000 {
+ compatible = "fsl,b4420-dcsr-dpaa", "fsl,dcsr-dpaa";
+ };
+ dcsr-ocn@11000 {
+ compatible = "fsl,b4420-dcsr-ocn", "fsl,dcsr-ocn";
+ };
+ dcsr-nal@18000 {
+ compatible = "fsl,b4420-dcsr-nal", "fsl,dcsr-nal";
+ };
+ dcsr-rcpm@22000 {
+ compatible = "fsl,b4420-dcsr-rcpm", "fsl,dcsr-rcpm";
+ };
+ dcsr-snpc@3 {
+ compatible = "fsl,b4420-dcsr-snpc", "fsl,dcsr-snpc";
+ };
+ dcsr-snpc@31000 {
+ compatible = "fsl,b4420-dcsr-snpc", "fsl,dcsr-snpc";
+ };
+ dcsr-cpu-sb-proxy@108000 {
+ compatible = "fsl,dcsr-e6500-sb-proxy", "fsl,dcsr-cpu-sb-proxy";
+ cpu-handle = <&cpu1>;
+ reg = <0x108000 0x1000 0x109000 0x1000>;
+ };
+};
+
+&soc {
+ cpc: l3-cache-controller@1 {
+ compatible = "fsl,b4420-l3-cache-controller", "cache";
+ };
+
+ corenet-cf@18000 {
+ compatible = "fsl,b4420-corenet-cf";
[PATCH 5/5] powerpc/85xx: Update corenet64_smp_defconfig for B4_QDS
Signed-off-by: Shaveta Leekha --- arch/powerpc/configs/corenet64_smp_defconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/configs/corenet64_smp_defconfig b/arch/powerpc/configs/corenet64_smp_defconfig index 1c6eb66..6c8b020 100644 --- a/arch/powerpc/configs/corenet64_smp_defconfig +++ b/arch/powerpc/configs/corenet64_smp_defconfig @@ -21,6 +21,7 @@ CONFIG_MODVERSIONS=y # CONFIG_BLK_DEV_BSG is not set CONFIG_PARTITION_ADVANCED=y CONFIG_MAC_PARTITION=y +CONFIG_B4_QDS=y CONFIG_P5020_DS=y CONFIG_P5040_DS=y CONFIG_T4240_QDS=y -- 1.7.6.GIT ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/5] powerpc/fsl-booke: Add initial B4860QDS and B4420QDS board device tree
B4860QDS and B4420QDS share same QDS board
* common board features have been added in b4qds.dts
* various board differences are in respective files of B4860 and B4420
Signed-off-by: Shaveta Leekha
Signed-off-by: Minghuan Lian
Signed-off-by: Andy Fleming
Signed-off-by: Poonam Aggrwal
Signed-off-by: Ramneek Mehresh
Signed-off-by: Kumar Gala
---
arch/powerpc/boot/dts/b4420qds.dts | 50 +++
arch/powerpc/boot/dts/b4860qds.dts | 61 +
arch/powerpc/boot/dts/b4qds.dts| 171
3 files changed, 282 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/b4420qds.dts
create mode 100644 arch/powerpc/boot/dts/b4860qds.dts
create mode 100644 arch/powerpc/boot/dts/b4qds.dts
diff --git a/arch/powerpc/boot/dts/b4420qds.dts
b/arch/powerpc/boot/dts/b4420qds.dts
new file mode 100644
index 000..923156d
--- /dev/null
+++ b/arch/powerpc/boot/dts/b4420qds.dts
@@ -0,0 +1,50 @@
+/*
+ * B4420DS Device Tree Source
+ *
+ * Copyright 2012 Freescale Semiconductor, Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * This software is provided by Freescale Semiconductor "as is" and any
+ * express or implied warranties, including, but not limited to, the implied
+ * warranties of merchantability and fitness for a particular purpose are
+ * disclaimed. In no event shall Freescale Semiconductor be liable for any
+ * direct, indirect, incidental, special, exemplary, or consequential damages
+ * (including, but not limited to, procurement of substitute goods or services;
+ * loss of use, data, or profits; or business interruption) however caused and
+ * on any theory of liability, whether in contract, strict liability, or tort
+ * (including negligence or otherwise) arising in any way out of the use of
+ * this software, even if advised of the possibility of such damage.
+ */
+
+/include/ "fsl/b4420si-pre.dtsi"
+/include/ "b4qds.dts"
+
+/ {
+ model = "fsl,B4420QDS";
+ compatible = "fsl,B4420QDS";
+
+ ifc: localbus@ffe124000 {
+ board-control@3,0 {
+ compatible = "fsl,b4420qds-fpga", "fsl,fpga-qixis";
+ };
+ };
+
+};
+
+/include/ "fsl/b4420si-post.dtsi"
diff --git a/arch/powerpc/boot/dts/b4860qds.dts
b/arch/powerpc/boot/dts/b4860qds.dts
new file mode 100644
index 000..78907f3
--- /dev/null
+++ b/arch/powerpc/boot/dts/b4860qds.dts
@@ -0,0 +1,61 @@
+/*
+ * B4860DS Device Tree Source
+ *
+ * Copyright 2012 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUP
[PATCH 4/5] powerpc/fsl-booke: Add B4_QDS board support
- Add support for B4 board in board file b4_qds.c,
It is common for B4860, B4420 and B4220QDS as they share same QDS board
- Add B4QDS support in Kconfig and Makefile
B4860QDS is a high-performance computing evaluation, development and
test platform supporting the B4860 QorIQ Power Architecture processor,
with following major features:
- Four dual-threaded e6500 Power Architecture processors
organized in one cluster-each core runs up to 1.8 GHz
- Two DDR3/3L controllers for high-speed memory interface each
runs at up to 1866.67 MHz
- CoreNet fabric that fully supports coherency using MESI protocol
between the e6500 cores, SC3900 FVP cores, memories and
external interfaces.
- Data Path Acceleration Architecture having FMAN, QMan, BMan, SEC 5.3 and
RMAN
- Large internal cache memory with snooping and stashing capabilities
- Sixteen 10-GHz SerDes lanes that serve:
- Two SRIO interfaces. Each supports up to 4 lanes and
a total of up to 8 lanes
- Up to 8-lanes Common Public Radio Interface (CPRI) controller
for glue-less antenna connection
- Two 10-Gbit Ethernet controllers (10GEC)
- Six 1G/2.5-Gbit Ethernet controllers for network communications
- PCI Express controller
- Debug (Aurora)
- Various system peripherals
B4420 and B4220 have some differences in comparison to B4860 with fewer
core/clusters(both SC3900 and e6500),
fewer DDR controllers, fewer serdes lanes, fewer SGMII interfaces and reduced
target frequencies.
Key differences between B4860 and B4420:
B4420 has:
- Fewer e6500 cores:
1 cluster with 2 e6500 cores
- Fewer SC3900 cores/clusters:
1 cluster with 2 SC3900 cores per cluster
- Single DDRC @ 1.6GHz
- 2 X 4 lane serdes
- 3 SGMII interfaces
- no sRIO
- no 10G
Key differences between B4860 and B4220:
B4220 has:
- Fewer e6500 cores:
1 cluster with 1 e6500 core
- Fewer SC3900 cores/clusters:
1 cluster with 2 SC3900 cores per cluster
- Single DDRC @ 1.33GHz
- 2 X 2 lane serdes
- 2 SGMII interfaces
- no sRIO
- no 10G
Signed-off-by: Shaveta Leekha
---
arch/powerpc/platforms/85xx/Kconfig | 17 ++
arch/powerpc/platforms/85xx/Makefile |1 +
arch/powerpc/platforms/85xx/b4_qds.c | 102 ++
3 files changed, 120 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/platforms/85xx/b4_qds.c
diff --git a/arch/powerpc/platforms/85xx/Kconfig
b/arch/powerpc/platforms/85xx/Kconfig
index 31dc066..8f02b05 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -321,6 +321,23 @@ config T4240_QDS
help
This option enables support for the T4240 QDS board
+config B4_QDS
+ bool "Freescale B4 QDS"
+ select DEFAULT_UIMAGE
+ select E500
+ select PPC_E500MC
+ select PHYS_64BIT
+ select SWIOTLB
+ select GENERIC_GPIO
+ select ARCH_REQUIRE_GPIOLIB
+ select HAS_RAPIDIO
+ select PPC_EPAPR_HV_PIC
+ help
+ This option enables support for the B4 QDS board
+ The B4 application development system B4 QDS is a complete
+ debugging environment intended for engineers developing
+ applications for the B4.
+
endif
endif # FSL_SOC_BOOKE
diff --git a/arch/powerpc/platforms/85xx/Makefile
b/arch/powerpc/platforms/85xx/Makefile
index 712e233..2eab37e 100644
--- a/arch/powerpc/platforms/85xx/Makefile
+++ b/arch/powerpc/platforms/85xx/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_P4080_DS)+= p4080_ds.o corenet_ds.o
obj-$(CONFIG_P5020_DS)+= p5020_ds.o corenet_ds.o
obj-$(CONFIG_P5040_DS)+= p5040_ds.o corenet_ds.o
obj-$(CONFIG_T4240_QDS) += t4240_qds.o corenet_ds.o
+obj-$(CONFIG_B4_QDS) += b4_qds.o corenet_ds.o
obj-$(CONFIG_STX_GP3)+= stx_gp3.o
obj-$(CONFIG_TQM85xx)+= tqm85xx.o
obj-$(CONFIG_SBC8548) += sbc8548.o
diff --git a/arch/powerpc/platforms/85xx/b4_qds.c
b/arch/powerpc/platforms/85xx/b4_qds.c
new file mode 100644
index 000..0c6702f
--- /dev/null
+++ b/arch/powerpc/platforms/85xx/b4_qds.c
@@ -0,0 +1,102 @@
+/*
+ * B4 QDS Setup
+ * Should apply for QDS platform of B4860 and it's personalities.
+ * viz B4860/B4420/B4220QDS
+ *
+ * Copyright 2012 Freescale Semiconductor Inc.
+ *
+ * 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.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include "corenet_ds.h"
+
+/*
+ * Called very early, device-tree isn't unflattened
+ */
+static int __init b4_qds_probe(void)
+{
+ unsigned long root = o
[PATCH 1/5] powerpc/85xx: add SEC-5.3 device tree
From: Shaveta Leekha
Signed-off-by: Vakul Garg
Signed-off-by: Shaveta Leekha
---
arch/powerpc/boot/dts/fsl/qoriq-sec5.3-0.dtsi | 118 +
1 files changed, 118 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-sec5.3-0.dtsi
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-sec5.3-0.dtsi
b/arch/powerpc/boot/dts/fsl/qoriq-sec5.3-0.dtsi
new file mode 100644
index 000..0339825
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/qoriq-sec5.3-0.dtsi
@@ -0,0 +1,118 @@
+/*
+ * QorIQ Sec/Crypto 5.3 device tree stub [ controller @ offset 0x30 ]
+ *
+ * Copyright 2012 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+crypto: crypto@30 {
+ compatible = "fsl,sec-v5.3", "fsl,sec-v5.0", "fsl,sec-v4.0";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0x30 0x1>;
+ ranges = <0 0x30 0x1>;
+ interrupts = <92 2 0 0>;
+
+ sec_jr0: jr@1000 {
+ compatible = "fsl,sec-v5.3-job-ring",
+"fsl,sec-v5.0-job-ring",
+"fsl,sec-v4.0-job-ring";
+ reg = <0x1000 0x1000>;
+ interrupts = <88 2 0 0>;
+ };
+
+ sec_jr1: jr@2000 {
+ compatible = "fsl,sec-v5.3-job-ring",
+"fsl,sec-v5.0-job-ring",
+"fsl,sec-v4.0-job-ring";
+ reg = <0x2000 0x1000>;
+ interrupts = <89 2 0 0>;
+ };
+
+ sec_jr2: jr@3000 {
+ compatible = "fsl,sec-v5.3-job-ring",
+"fsl,sec-v5.0-job-ring",
+"fsl,sec-v4.0-job-ring";
+ reg = <0x3000 0x1000>;
+ interrupts = <90 2 0 0>;
+ };
+
+ sec_jr3: jr@4000 {
+ compatible = "fsl,sec-v5.3-job-ring",
+"fsl,sec-v5.0-job-ring",
+"fsl,sec-v4.0-job-ring";
+ reg = <0x4000 0x1000>;
+ interrupts = <91 2 0 0>;
+ };
+
+ rtic@6000 {
+ compatible = "fsl,sec-v5.3-rtic",
+"fsl,sec-v5.0-rtic",
+"fsl,sec-v4.0-rtic";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0x6000 0x100>;
+ ranges = <0x0 0x6100 0xe00>;
+
+ rtic_a: rtic-a@0 {
+ compatible = "fsl,sec-v5.3-rtic-memory",
+"fsl,sec-v5.0-rtic-memory",
+"fsl,sec-v4.0-rtic-memory";
+ reg = <0x00 0x20 0x100 0x80>;
+ };
+
+ rtic_b: rtic-b@20 {
+ compatible = "fsl,sec-v5.3-rtic-memory",
+"fsl,sec-v5.0-rtic-memory",
+"fsl,sec-v4.0-rtic-memory";
+ reg = <0x20 0x20 0x200 0x80>;
+ };
+
+ rtic_c: rtic-c@40 {
+ compatible = "fsl,sec-v5.3-rtic-memory",
+"fsl,sec-v5.0-rtic-memory",
+"fsl,s
