Re: [PATCH] More fixes for lazy IRQ vs. idle
Benjamin Herrenschmidt b...@kernel.crashing.org wrote:
Looks like we still have issues with pSeries and Cell idle code
vs. the lazy irq state. In fact, the reset fixes that went upstream
are exposing the problem more by causing BUG_ON() to trigger (which
this patch turns into a WARN_ON instead).
Do we need to cc stable for 3.4 or is this new stuff only effecting us
since the 3.5 merge window?
Mikey
We need to be careful when using a variant of low power state that
has the side effect of turning interrupts back on, to properly set
all the SW lazy state to look as if everything is enabled before
we enter the low power state with MSR:EE off as we will return with
MSR:EE on. If not, we have a discrepancy of state which can cause
things to go very wrong later on.
This patch moves the logic into a helper and uses it from the
pseries and cell idle code. The power4/970 idle code already got
things right (in assembly even !) so I'm not touching it. The power7
bare metal idle code is subtly different and correct. Remains PA6T
and some hypervisor based Cell platforms which have questionable
code in there, but they are mostly dead platforms so I'll fix them
when I manage to get final answers from the respective maintainers
about how the low power state actually works on them.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
diff --git a/arch/powerpc/include/asm/hw_irq.h
b/arch/powerpc/include/asm/hw_irq.h
index 6eb75b8..92224b7 100644
--- a/arch/powerpc/include/asm/hw_irq.h
+++ b/arch/powerpc/include/asm/hw_irq.h
@@ -125,6 +125,8 @@ static inline bool arch_irq_disabled_regs(struct pt_regs
*regs)
return !regs-softe;
}
+extern bool prep_irq_for_idle(void);
+
#else /* CONFIG_PPC64 */
#define SET_MSR_EE(x)mtmsr(x)
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 1b41502..5dc4a80 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -286,6 +286,52 @@ void notrace restore_interrupts(void)
__hard_irq_enable();
}
+/*
+ * This is a helper to use when about to go into idle low-power
+ * when the latter has the side effect of re-enabling interrupts
+ * (such as calling H_CEDE under pHyp).
+ *
+ * You call this function with interrupts soft-disabled (this is
+ * already the case when ppc_md.power_save is called). The function
+ * will return whether to enter power save or just return.
+ *
+ * In the former case, it will have notified lockdep of interrupts
+ * being re-enabled and generally sanitized the lazy irq state,
+ * and in the latter case it will leave with interrupts hard
+ * disabled and marked as such, so the local_irq_restore() call
+ * in cpu_idle() will properly re-enable everything.
+ */
+bool prep_irq_for_idle(void)
+{
+ /*
+ * First we need to hard disable to ensure no interrupt
+ * occurs before we effectively enter the low power state
+ */
+ hard_irq_disable();
+
+ /*
+ * If anything happened while we were soft-disabled,
+ * we return now and do not enter the low power state.
+ */
+ if (lazy_irq_pending())
+ return false;
+
+ /* Tell lockdep we are about to re-enable */
+ trace_hardirqs_on();
+
+ /*
+ * Mark interrupts as soft-enabled and clear the
+ * PACA_IRQ_HARD_DIS from the pending mask since we
+ * are about to hard enable as well as a side effect
+ * of entering the low power state.
+ */
+ local_paca-irq_happened = ~PACA_IRQ_HARD_DIS;
+ local_paca-soft_enabled = 1;
+
+ /* Tell the caller to enter the low power state */
+ return true;
+}
+
#endif /* CONFIG_PPC64 */
int arch_show_interrupts(struct seq_file *p, int prec)
diff --git a/arch/powerpc/platforms/cell/pervasive.c
b/arch/powerpc/platforms/cell/pervasive.c
index efdacc8..d17e98b 100644
--- a/arch/powerpc/platforms/cell/pervasive.c
+++ b/arch/powerpc/platforms/cell/pervasive.c
@@ -42,11 +42,9 @@ static void cbe_power_save(void)
{
unsigned long ctrl, thread_switch_control;
- /*
- * We need to hard disable interrupts, the local_irq_enable() done by
- * our caller upon return will hard re-enable.
- */
- hard_irq_disable();
+ /* Ensure our interrupt state is properly tracked */
+ if (!prep_irq_for_idle())
+ return;
ctrl = mfspr(SPRN_CTRLF);
@@ -81,6 +79,9 @@ static void cbe_power_save(void)
*/
ctrl = ~(CTRL_RUNLATCH | CTRL_TE);
mtspr(SPRN_CTRLT, ctrl);
+
+ /* Re-enable interrupts in MSR */
+ __hard_irq_enable();
}
static int cbe_system_reset_exception(struct pt_regs *regs)
diff --git a/arch/powerpc/platforms/pseries/processor_idle.c
b/arch/powerpc/platforms/pseries/processor_idle.c
index a97ef66..9b51ccf 100644
--- a/arch/powerpc/platforms/pseries/processor_idle.c
+++
Re: [PATCH -V3 03/11] arch/powerpc: Convert virtual address to vpn
Stephen Rothwell s...@canb.auug.org.au writes:
Hi Aneesh,
On Mon, 9 Jul 2012 18:43:33 +0530 Aneesh Kumar K.V
aneesh.ku...@linux.vnet.ibm.com wrote:
diff --git a/arch/powerpc/include/asm/mmu-hash64.h
b/arch/powerpc/include/asm/mmu-hash64.h
index 1c65a59..1c984a6 100644
--- a/arch/powerpc/include/asm/mmu-hash64.h
+++ b/arch/powerpc/include/asm/mmu-hash64.h
@@ -154,9 +155,25 @@ struct mmu_psize_def
#define MMU_SEGSIZE_256M0
#define MMU_SEGSIZE_1T 1
+/*
+ * encode page number shift.
+ * Inorder to fit the 78 bit va in a 64 bit variable we shift the va by
+ * 12 bits. This enable us to address upto 76 bit va.
+ * For hpt hash from a va we can ignore the page size bits of va and for
+ * hpte encoding we ignore upto 23 bits of va. So ignoring lower 12 bits
ensure
+ * we work in all cases including 4k page size.
+ */
+#define VPN_SHIFT 12
+static inline unsigned long hpte_encode_avpn(unsigned long vpn, int psize,
+ int ssize)
+{
+unsigned long v;
+/*
+ * The AVA field omits the low-order 23 bits of the 78 bits VA.
+ * These bits are not needed in the PTE, because the
+ * low-order b of these bits are part of the byte offset
+ * into the virtual page and, if b 23, the high-order
+ * 23-b of these bits are always used in selecting the
+ * PTEGs to be searched
+ */
+BUG_ON(VPN_SHIFT 23);
Could/should this be BUILD_BUG_ON()?
Yes. Will update.
-aneesh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] PCI: Add pcie_irq=other to enable non MSI/INTx interrupt for port service driver
-Original Message- From: Wood Scott-B07421 Sent: Tuesday, July 10, 2012 12:39 AM To: Liu Shengzhou-B36685 Cc: bhelg...@google.com; linux-...@vger.kernel.org; linuxppc- d...@lists.ozlabs.org Subject: Re: [PATCH] PCI: Add pcie_irq=other to enable non MSI/INTx interrupt for port service driver On 07/09/2012 05:49 AM, Shengzhou Liu wrote: On some platforms, in RC mode, root port has neither MSI/MSI-X nor INTx interrupt generated, which are available only in EP mode on those platform. In this case, we try to use other interrupt if supported (i.e. there is the shared error interrupt on platform P1010, P3041, P4080, etc) to have AER, Hot-plug, etc, services to work. Signed-off-by: Shengzhou Liu shengzhou@freescale.com --- Documentation/kernel-parameters.txt |4 drivers/pci/pcie/portdrv_core.c | 19 +++ 2 files changed, 23 insertions(+), 0 deletions(-) diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index a92c5eb..af97c81 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -2218,6 +2218,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted. nomsi Do not use MSI for native PCIe PME signaling (this makes all PCIe root ports use INTx for all services). + pcie_irq= [PCIE] Native PCIe root port interrupt options: + other Try to use other interrupt when root port has + neither MSI/MSI-X nor INTx support. Why does the user need to specify this? Shouldn't this be a matter of communication between kernel internals? The other interrupt appears a non-standard interrupt way compared to MSI/MSI-X and INTx in point of PCIe spec. The intent of specifying this is to have an intervention and confirmation manually to avoid causing unexpected issue on some unknown platforms. I'm glad to remove the specified kernel parameter if it would be accepted upstream. @@ -216,6 +227,14 @@ static int init_service_irqs(struct pci_dev *dev, int *irqs, int mask) if (!pci_enable_msi(dev) || dev-pin) irq = dev-irq; + /* +* On some platforms, root port has neither MSI/MSI-X nor INTx +* interrupt support in RC mode, so try to use other interrupt(i.e. +* shared interrupt if supported). +*/ + else if (port_other_interrupt_enabled dev-irq) + irq = dev-irq; Is there any reason to not use dev-irq if it is non-zero? -Scott I guess a thinking of the original author did so is based on the point of PCIe spec, whether INTx is supported or not is decided by the PCI Express Interrupt Pin Register(Read only). Is there the case on some other unknown platforms that dev-irq is non-zero due to incorrect initialization of irq allocation, but actually it doesn't support MSI/MSIX/INTx or any other interrupt? If we don't need to consider this case, we can use dev-irq directly instead of dev-pin to support other interrupt. Thanks, Shengzhou ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH -V3 03/11] arch/powerpc: Convert virtual address to vpn
Stephen Rothwell s...@canb.auug.org.au writes:
Hi Aneesh,
On Mon, 9 Jul 2012 18:43:33 +0530 Aneesh Kumar K.V
aneesh.ku...@linux.vnet.ibm.com wrote:
diff --git a/arch/powerpc/mm/hash_native_64.c
b/arch/powerpc/mm/hash_native_64.c
index 660b8bb..308e29d 100644
--- a/arch/powerpc/mm/hash_native_64.c
+++ b/arch/powerpc/mm/hash_native_64.c
@@ -39,22 +39,33 @@
DEFINE_RAW_SPINLOCK(native_tlbie_lock);
-static inline void __tlbie(unsigned long va, int psize, int ssize)
+static inline void __tlbie(unsigned long vpn, int psize, int ssize)
{
+unsigned long va;
unsigned int penc;
+/*
+ * We need 14 to 65 bits of va for a tlibe of 4K page
+ * With vpn we ignore the lower VPN_SHIFT bits already.
+ * And top two bits are already ignored because we can
+ * only accomadate 76 bits in a 64 bit vpn with a VPN_SHIFT
+ * of 12.
+ */
+BUG_ON((77 - 65) VPN_SHIFT);
BUILD_BUG_ON() ?
Yes. I also found a bug there. It should be updated as below
BUILD_BUG_ON(VPN_SHIFT (77 - 65));
We want to make sure we are not ignoring bits above 65th bit.
-static inline void __tlbiel(unsigned long va, int psize, int ssize)
+static inline void __tlbiel(unsigned long vpn, int psize, int ssize)
{
+unsigned long va;
unsigned int penc;
+BUG_ON((77 - 65) VPN_SHIFT);
BUILD_BUG_ON() ?
-aneesh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 0/3] Raid: enable talitos xor offload for improving performance
The following 4 patches enabling fsl-dma and talitos offload raid operations for improving raid performance and balancing CPU load. Write performance will be improved by 40% tested by iozone. CPU load will be reduced by 8%. Qiang Liu (4): Talitos: move the data structure into header file Talitos: Support for async_tx XOR offload fsl-dma: support attribute of DMA_MEMORY when async_tx enabled Talitos: fix the issue of dma memory leak drivers/crypto/Kconfig |9 + drivers/crypto/talitos.c | 520 -- drivers/crypto/talitos.h | 161 ++ drivers/dma/fsldma.c | 78 +++- 4 files changed, 606 insertions(+), 162 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 0/3] Raid: enable talitos xor offload for improving performance
The following 4 patches enabling fsl-dma and talitos offload raid operations for improving raid performance and balancing CPU load. Write performance will be improved by 40% tested by iozone. CPU load will be reduced by 8%. Qiang Liu (4): Talitos: move the data structure into header file Talitos: Support for async_tx XOR offload fsl-dma: support attribute of DMA_MEMORY when async_tx enabled Talitos: fix the issue of dma memory leak drivers/crypto/Kconfig |9 + drivers/crypto/talitos.c | 520 -- drivers/crypto/talitos.h | 161 ++ drivers/dma/fsldma.c | 78 +++- 4 files changed, 606 insertions(+), 162 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/4] Talitos: move the data structure into header file
Move the declaration of talitos data structure into talitos.h.
Cc: Herbert Xu herb...@gondor.apana.org.au
Cc: David S. Miller da...@davemloft.net
Signed-off-by: Qiang Liu qiang@freescale.com
---
drivers/crypto/talitos.c | 108 --
drivers/crypto/talitos.h | 108 ++
2 files changed, 108 insertions(+), 108 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index dc641c7..cb9e4cd 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -53,114 +53,6 @@
#include talitos.h
-#define TALITOS_TIMEOUT 10
-#define TALITOS_MAX_DATA_LEN 65535
-
-#define DESC_TYPE(desc_hdr) ((be32_to_cpu(desc_hdr) 3) 0x1f)
-#define PRIMARY_EU(desc_hdr) ((be32_to_cpu(desc_hdr) 28) 0xf)
-#define SECONDARY_EU(desc_hdr) ((be32_to_cpu(desc_hdr) 16) 0xf)
-
-/* descriptor pointer entry */
-struct talitos_ptr {
- __be16 len; /* length */
- u8 j_extent;/* jump to sg link table and/or extent */
- u8 eptr;/* extended address */
- __be32 ptr; /* address */
-};
-
-static const struct talitos_ptr zero_entry = {
- .len = 0,
- .j_extent = 0,
- .eptr = 0,
- .ptr = 0
-};
-
-/* descriptor */
-struct talitos_desc {
- __be32 hdr; /* header high bits */
- __be32 hdr_lo; /* header low bits */
- struct talitos_ptr ptr[7]; /* ptr/len pair array */
-};
-
-/**
- * talitos_request - descriptor submission request
- * @desc: descriptor pointer (kernel virtual)
- * @dma_desc: descriptor's physical bus address
- * @callback: whom to call when descriptor processing is done
- * @context: caller context (optional)
- */
-struct talitos_request {
- struct talitos_desc *desc;
- dma_addr_t dma_desc;
- void (*callback) (struct device *dev, struct talitos_desc *desc,
- void *context, int error);
- void *context;
-};
-
-/* per-channel fifo management */
-struct talitos_channel {
- void __iomem *reg;
-
- /* request fifo */
- struct talitos_request *fifo;
-
- /* number of requests pending in channel h/w fifo */
- atomic_t submit_count cacheline_aligned;
-
- /* request submission (head) lock */
- spinlock_t head_lock cacheline_aligned;
- /* index to next free descriptor request */
- int head;
-
- /* request release (tail) lock */
- spinlock_t tail_lock cacheline_aligned;
- /* index to next in-progress/done descriptor request */
- int tail;
-};
-
-struct talitos_private {
- struct device *dev;
- struct platform_device *ofdev;
- void __iomem *reg;
- int irq[2];
-
- /* SEC version geometry (from device tree node) */
- unsigned int num_channels;
- unsigned int chfifo_len;
- unsigned int exec_units;
- unsigned int desc_types;
-
- /* SEC Compatibility info */
- unsigned long features;
-
- /*
-* length of the request fifo
-* fifo_len is chfifo_len rounded up to next power of 2
-* so we can use bitwise ops to wrap
-*/
- unsigned int fifo_len;
-
- struct talitos_channel *chan;
-
- /* next channel to be assigned next incoming descriptor */
- atomic_t last_chan cacheline_aligned;
-
- /* request callback tasklet */
- struct tasklet_struct done_task[2];
-
- /* list of registered algorithms */
- struct list_head alg_list;
-
- /* hwrng device */
- struct hwrng rng;
-};
-
-/* .features flag */
-#define TALITOS_FTR_SRC_LINK_TBL_LEN_INCLUDES_EXTENT 0x0001
-#define TALITOS_FTR_HW_AUTH_CHECK 0x0002
-#define TALITOS_FTR_SHA224_HWINIT 0x0004
-#define TALITOS_FTR_HMAC_OK 0x0008
-
static void to_talitos_ptr(struct talitos_ptr *talitos_ptr, dma_addr_t
dma_addr)
{
talitos_ptr-ptr = cpu_to_be32(lower_32_bits(dma_addr));
diff --git a/drivers/crypto/talitos.h b/drivers/crypto/talitos.h
index 3c17395..21934be 100644
--- a/drivers/crypto/talitos.h
+++ b/drivers/crypto/talitos.h
@@ -28,6 +28,114 @@
*
*/
+#define TALITOS_TIMEOUT 10
+#define TALITOS_MAX_DATA_LEN 65535
+
+#define DESC_TYPE(desc_hdr) ((be32_to_cpu(desc_hdr) 3) 0x1f)
+#define PRIMARY_EU(desc_hdr) ((be32_to_cpu(desc_hdr) 28) 0xf)
+#define SECONDARY_EU(desc_hdr) ((be32_to_cpu(desc_hdr) 16) 0xf)
+
+/* descriptor pointer entry */
+struct talitos_ptr {
+ __be16 len; /* length */
+ u8 j_extent;/* jump to sg link table and/or extent */
+ u8 eptr;/* extended address */
+ __be32 ptr; /* address */
+};
+
+static const struct talitos_ptr zero_entry = {
+ .len = 0,
+ .j_extent = 0,
+ .eptr = 0,
+ .ptr = 0
+};
+
+/* descriptor */
+struct talitos_desc {
+ __be32 hdr; /* header high bits */
+ __be32 hdr_lo; /* header low bits */
+
[PATCH 2/4] Talitos: Support for async_tx XOR offload
Expose Talitos's XOR functionality to be used for RAID parity
calculation via the Async_tx layer.
Cc: Herbert Xu herb...@gondor.apana.org.au
Cc: David S. Miller da...@davemloft.net
Signed-off-by: Dipen Dudhat dipen.dud...@freescale.com
Signed-off-by: Maneesh Gupta maneesh.gu...@freescale.com
Signed-off-by: Kim Phillips kim.phill...@freescale.com
Signed-off-by: Vishnu Suresh vis...@freescale.com
Signed-off-by: Qiang Liu qiang@freescale.com
---
drivers/crypto/Kconfig |9 +
drivers/crypto/talitos.c | 410 ++
drivers/crypto/talitos.h | 53 ++
3 files changed, 472 insertions(+), 0 deletions(-)
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 69fdf18..ad0cf5a 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -220,6 +220,15 @@ config CRYPTO_DEV_TALITOS
To compile this driver as a module, choose M here: the module
will be called talitos.
+config CRYPTO_DEV_TALITOS_RAIDXOR
+ bool Talitos RAID5 XOR Calculation Offload
+ default y
+ select DMA_ENGINE
+ depends on CRYPTO_DEV_TALITOS
+ help
+ Say 'Y' here to use the Freescale Security Engine (SEC) to
+ offload RAID XOR parity Calculation
+
config CRYPTO_DEV_IXP4XX
tristate Driver for IXP4xx crypto hardware acceleration
depends on ARCH_IXP4XX
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index cb9e4cd..81f8497 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -609,6 +609,396 @@ static void talitos_unregister_rng(struct device *dev)
hwrng_unregister(priv-rng);
}
+#ifdef CONFIG_CRYPTO_DEV_TALITOS_RAIDXOR
+static void talitos_release_xor(struct device *dev, struct talitos_desc
*hwdesc,
+ void *context, int error);
+
+static enum dma_status talitos_is_tx_complete(struct dma_chan *chan,
+ dma_cookie_t cookie,
+ struct dma_tx_state *state)
+{
+ struct talitos_xor_chan *xor_chan;
+ dma_cookie_t last_used;
+ dma_cookie_t last_complete;
+
+ xor_chan = container_of(chan, struct talitos_xor_chan, common);
+
+ last_used = chan-cookie;
+ last_complete = xor_chan-completed_cookie;
+
+ if (state-last)
+ state-last = last_complete;
+
+ if (state-used)
+ state-used = last_used;
+
+ return dma_async_is_complete(cookie, last_complete, last_used);
+}
+
+static void talitos_process_pending(struct talitos_xor_chan *xor_chan)
+{
+ struct talitos_xor_desc *desc, *_desc;
+ unsigned long flags;
+ int status;
+ struct talitos_private *priv;
+ int ch;
+
+ priv = dev_get_drvdata(xor_chan-dev);
+ ch = atomic_inc_return(priv-last_chan)
+ (priv-num_channels - 1);
+ spin_lock_irqsave(xor_chan-desc_lock, flags);
+
+ list_for_each_entry_safe(desc, _desc, xor_chan-pending_q, node) {
+ status = talitos_submit(xor_chan-dev, ch, desc-hwdesc,
+ talitos_release_xor, desc);
+ if (status != -EINPROGRESS)
+ break;
+
+ list_del(desc-node);
+ list_add_tail(desc-node, xor_chan-in_progress_q);
+ }
+
+ spin_unlock_irqrestore(xor_chan-desc_lock, flags);
+}
+
+static void talitos_xor_run_tx_complete_actions(struct talitos_xor_desc *desc,
+ struct talitos_xor_chan *xor_chan)
+{
+ struct device *dev = xor_chan-dev;
+ dma_addr_t dest, addr;
+ unsigned int src_cnt = desc-unmap_src_cnt;
+ unsigned int len = desc-unmap_len;
+ enum dma_ctrl_flags flags = desc-async_tx.flags;
+ struct dma_async_tx_descriptor *tx = desc-async_tx;
+
+ /* unmap dma addresses */
+ dest = desc-hwdesc.ptr[6].ptr;
+ if (likely(!(flags DMA_COMPL_SKIP_DEST_UNMAP)))
+ dma_unmap_page(dev, dest, len, DMA_BIDIRECTIONAL);
+
+ desc-idx = 6 - src_cnt;
+ while(desc-idx 6) {
+ addr = desc-hwdesc.ptr[desc-idx++].ptr;
+ if (likely(!(flags DMA_COMPL_SKIP_SRC_UNMAP)))
+ dma_unmap_page(dev, addr, len, DMA_TO_DEVICE);
+ }
+
+ /* run dependent operations */
+ dma_run_dependencies(tx);
+}
+
+static void talitos_release_xor(struct device *dev, struct talitos_desc
*hwdesc,
+ void *context, int error)
+{
+ struct talitos_xor_desc *desc = context;
+ struct talitos_xor_chan *xor_chan;
+ dma_async_tx_callback callback;
+ void *callback_param;
+
+ if (unlikely(error))
+ dev_err(dev, xor operation: talitos error %d\n, error);
+
+ xor_chan = container_of(desc-async_tx.chan, struct talitos_xor_chan,
+ common);
+ spin_lock_bh(xor_chan-desc_lock);
+ if
[PATCH 3/4] fsl-dma: support attribute of DMA_MEMORY when async_tx enabled
- delete attribute of DMA_INTERRUPT because fsl-dma doesn't support
this function, exception will be thrown if talitos is used to compute xor
at the same time;
- change the release process of dma descriptor for avoiding exception when
enable config NET_DMA, release dma descriptor from 1st to last second, the
last descriptor which is reserved in current descriptor register may not be
completed, race condition will be raised if free current descriptor;
- use spin_lock_bh to instead of spin_lock_irqsave for improving performance;
A race condition which is raised when use both of talitos and dmaengine to
offload xor is because napi scheduler will sync all pending requests in dma
channels, it will affect the process of raid operations. The descriptor is
freed which is submitted just now, but async_tx must check whether this depend
tx descriptor is acked, there are poison contents in the invalid address,
then BUG_ON() is thrown, so this descriptor will be freed in the next time.
Cc: Dan Williams dan.j.willi...@intel.com
Cc: Vinod Koul vinod.k...@intel.com
Cc: Li Yang le...@freescale.com
Signed-off-by: Qiang Liu qiang@freescale.com
---
drivers/dma/fsldma.c | 78 --
1 files changed, 25 insertions(+), 53 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index b98070c..44698c9 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -404,11 +404,9 @@ static dma_cookie_t fsl_dma_tx_submit(struct
dma_async_tx_descriptor *tx)
struct fsldma_chan *chan = to_fsl_chan(tx-chan);
struct fsl_desc_sw *desc = tx_to_fsl_desc(tx);
struct fsl_desc_sw *child;
- unsigned long flags;
dma_cookie_t cookie;
- spin_lock_irqsave(chan-desc_lock, flags);
-
+ spin_lock_bh(chan-desc_lock);
/*
* assign cookies to all of the software descriptors
* that make up this transaction
@@ -427,7 +425,7 @@ static dma_cookie_t fsl_dma_tx_submit(struct
dma_async_tx_descriptor *tx)
/* put this transaction onto the tail of the pending queue */
append_ld_queue(chan, desc);
- spin_unlock_irqrestore(chan-desc_lock, flags);
+ spin_unlock_bh(chan-desc_lock);
return cookie;
}
@@ -536,48 +534,18 @@ static void fsldma_free_desc_list_reverse(struct
fsldma_chan *chan,
static void fsl_dma_free_chan_resources(struct dma_chan *dchan)
{
struct fsldma_chan *chan = to_fsl_chan(dchan);
- unsigned long flags;
chan_dbg(chan, free all channel resources\n);
- spin_lock_irqsave(chan-desc_lock, flags);
+ spin_lock_bh(chan-desc_lock);
fsldma_free_desc_list(chan, chan-ld_pending);
fsldma_free_desc_list(chan, chan-ld_running);
- spin_unlock_irqrestore(chan-desc_lock, flags);
+ spin_unlock_bh(chan-desc_lock);
dma_pool_destroy(chan-desc_pool);
chan-desc_pool = NULL;
}
static struct dma_async_tx_descriptor *
-fsl_dma_prep_interrupt(struct dma_chan *dchan, unsigned long flags)
-{
- struct fsldma_chan *chan;
- struct fsl_desc_sw *new;
-
- if (!dchan)
- return NULL;
-
- chan = to_fsl_chan(dchan);
-
- new = fsl_dma_alloc_descriptor(chan);
- if (!new) {
- chan_err(chan, %s\n, msg_ld_oom);
- return NULL;
- }
-
- new-async_tx.cookie = -EBUSY;
- new-async_tx.flags = flags;
-
- /* Insert the link descriptor to the LD ring */
- list_add_tail(new-node, new-tx_list);
-
- /* Set End-of-link to the last link descriptor of new list */
- set_ld_eol(chan, new);
-
- return new-async_tx;
-}
-
-static struct dma_async_tx_descriptor *
fsl_dma_prep_memcpy(struct dma_chan *dchan,
dma_addr_t dma_dst, dma_addr_t dma_src,
size_t len, unsigned long flags)
@@ -788,7 +756,6 @@ static int fsl_dma_device_control(struct dma_chan *dchan,
{
struct dma_slave_config *config;
struct fsldma_chan *chan;
- unsigned long flags;
int size;
if (!dchan)
@@ -798,7 +765,7 @@ static int fsl_dma_device_control(struct dma_chan *dchan,
switch (cmd) {
case DMA_TERMINATE_ALL:
- spin_lock_irqsave(chan-desc_lock, flags);
+ spin_lock_bh(chan-desc_lock);
/* Halt the DMA engine */
dma_halt(chan);
@@ -808,7 +775,7 @@ static int fsl_dma_device_control(struct dma_chan *dchan,
fsldma_free_desc_list(chan, chan-ld_running);
chan-idle = true;
- spin_unlock_irqrestore(chan-desc_lock, flags);
+ spin_unlock_bh(chan-desc_lock);
return 0;
case DMA_SLAVE_CONFIG:
@@ -968,11 +935,10 @@ static void fsl_chan_xfer_ld_queue(struct fsldma_chan
*chan)
static void fsl_dma_memcpy_issue_pending(struct dma_chan *dchan)
{
struct fsldma_chan *chan = to_fsl_chan(dchan);
- unsigned long flags;
-
[PATCH 4/4] Talitos: fix the issue of dma memory leak
An error will be happened when test with mass data: DMA-API: device driver tries to sync DMA memory it has not allocated; DMA-API: debugging out of memory - disabling dma mapping memory of request-desc is not released by right device, it should be private-dev but not dev; Cc: Herbert Xu herb...@gondor.apana.org.au Cc: David S. Miller da...@davemloft.net Signed-off-by: Qiang Liu qiang@freescale.com --- drivers/crypto/talitos.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c index 81f8497..a7da48c 100644 --- a/drivers/crypto/talitos.c +++ b/drivers/crypto/talitos.c @@ -264,7 +264,7 @@ static void flush_channel(struct device *dev, int ch, int error, int reset_ch) else status = error; - dma_unmap_single(dev, request-dma_desc, +dma_unmap_single(priv-dev, request-dma_desc, sizeof(struct talitos_desc), DMA_BIDIRECTIONAL); -- 1.7.5.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 0/3] Raid: enable talitos xor offload for improving performance
The following 4 patches enabling fsl-dma and talitos offload raid operations for improving raid performance and balancing CPU load. Write performance will be improved by 40% tested by iozone. CPU load will be reduced by 8%. Qiang Liu (4): Talitos: move the data structure into header file Talitos: Support for async_tx XOR offload fsl-dma: support attribute of DMA_MEMORY when async_tx enabled Talitos: fix the issue of dma memory leak drivers/crypto/Kconfig |9 + drivers/crypto/talitos.c | 520 -- drivers/crypto/talitos.h | 161 ++ drivers/dma/fsldma.c | 78 +++- 4 files changed, 606 insertions(+), 162 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] powerpc/mpc8572ds: Fix eTSEC is not available on core1 of AMP boot issue
The issue log on core1 is:
root@mpc8572ds:~# ifconfig eth0 10.192.208.244
net eth0: could not attach to PHY
SIOCSIFFLAGS: No such device
To attach PHY node mdio@24520 should not be disabled in dts of core1.
Because all PHYs are controlled through this node as follows:
mdio@24520 {
phy0: ethernet-phy@0 {
interrupts = 10 1 0 0;
reg = 0x0;
};
phy1: ethernet-phy@1 {
interrupts = 10 1 0 0;
reg = 0x1;
};
phy2: ethernet-phy@2 {
interrupts = 10 1 0 0;
reg = 0x2;
};
phy3: ethernet-phy@3 {
interrupts = 10 1 0 0;
reg = 0x3;
};
tbi0: tbi-phy@11 {
reg = 0x11;
device_type = tbi-phy;
};
};
Signed-off-by: Li Yang le...@freescale.com
Signed-off-by: Jia Hongtao b38...@freescale.com
---
arch/powerpc/boot/dts/mpc8572ds_camp_core1.dts |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8572ds_camp_core1.dts
b/arch/powerpc/boot/dts/mpc8572ds_camp_core1.dts
index d6a8faf..1932396 100644
--- a/arch/powerpc/boot/dts/mpc8572ds_camp_core1.dts
+++ b/arch/powerpc/boot/dts/mpc8572ds_camp_core1.dts
@@ -67,9 +67,6 @@
ethernet@24000 {
status = disabled;
};
- mdio@24520 {
- status = disabled;
- };
ptp_clock@24e00 {
status = disabled;
};
--
1.7.5.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] powerpc/mpc8572ds: Update the MSI interrupts into 4-cell format
With 2-cell format interrupts of MSI PCIe ethernet card can not work.
Signed-off-by: Li Yang le...@freescale.com
Signed-off-by: Jia Hongtao b38...@freescale.com
---
arch/powerpc/boot/dts/mpc8572ds_camp_core0.dts |8
arch/powerpc/boot/dts/mpc8572ds_camp_core1.dts |8
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8572ds_camp_core0.dts
b/arch/powerpc/boot/dts/mpc8572ds_camp_core0.dts
index d34d127..ef9ef56 100644
--- a/arch/powerpc/boot/dts/mpc8572ds_camp_core0.dts
+++ b/arch/powerpc/boot/dts/mpc8572ds_camp_core0.dts
@@ -67,10 +67,10 @@
msi@41600 {
msi-available-ranges = 0 0x80;
interrupts =
- 0xe0 0
- 0xe1 0
- 0xe2 0
- 0xe3 0;
+ 0xe0 0 0 0
+ 0xe1 0 0 0
+ 0xe2 0 0 0
+ 0xe3 0 0 0;
};
timer@42100 {
status = disabled;
diff --git a/arch/powerpc/boot/dts/mpc8572ds_camp_core1.dts
b/arch/powerpc/boot/dts/mpc8572ds_camp_core1.dts
index 1932396..24564ee 100644
--- a/arch/powerpc/boot/dts/mpc8572ds_camp_core1.dts
+++ b/arch/powerpc/boot/dts/mpc8572ds_camp_core1.dts
@@ -97,10 +97,10 @@
msi@41600 {
msi-available-ranges = 0x80 0x80;
interrupts =
- 0xe4 0
- 0xe5 0
- 0xe6 0
- 0xe7 0;
+ 0xe4 0 0 0
+ 0xe5 0 0 0
+ 0xe6 0 0 0
+ 0xe7 0 0 0;
};
global-utilities@e {
status = disabled;
--
1.7.5.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] More fixes for lazy IRQ vs. idle
On Tue, 2012-07-10 at 16:10 +1000, Michael Neuling wrote: Benjamin Herrenschmidt b...@kernel.crashing.org wrote: Looks like we still have issues with pSeries and Cell idle code vs. the lazy irq state. In fact, the reset fixes that went upstream are exposing the problem more by causing BUG_ON() to trigger (which this patch turns into a WARN_ON instead). Do we need to cc stable for 3.4 or is this new stuff only effecting us since the 3.5 merge window? That's probably stable business, I'll check that before I send it to Linus. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/1] powerpc: add memory attribute for mfmsr()
Add memory attribute in inline assembly language as a compiler
barrier to make sure 4.6.x GCC don't reorder mfmsr().
Signed-off-by: Tiejun Chen tiejun.c...@windriver.com
---
arch/powerpc/include/asm/reg.h |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index 559da19..578e5a0 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -1016,7 +1016,8 @@
/* Macros for setting and retrieving special purpose registers */
#ifndef __ASSEMBLY__
#define mfmsr()({unsigned long rval; \
- asm volatile(mfmsr %0 : =r (rval)); rval;})
+ asm volatile(mfmsr %0 : =r (rval) : \
+ : memory); rval;})
#ifdef CONFIG_PPC_BOOK3S_64
#define __mtmsrd(v, l) asm volatile(mtmsrd %0, __stringify(l) \
: : r (v) : memory)
--
1.5.6
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/dts: Add ucc uart support for p1025rdb
From: Zhicheng Fan b32...@freescale.com
Signed-off-by: Zhicheng Fan b32...@freescale.com
---
arch/powerpc/boot/dts/fsl/p1021si-post.dtsi | 16 ++-
arch/powerpc/boot/dts/p1025rdb.dtsi | 40 +++
2 files changed, 55 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/dts/fsl/p1021si-post.dtsi
b/arch/powerpc/boot/dts/fsl/p1021si-post.dtsi
index a78e7ed..8a5993f 100644
--- a/arch/powerpc/boot/dts/fsl/p1021si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p1021si-post.dtsi
@@ -1,7 +1,7 @@
/*
* P1021/P1012 Silicon/SoC Device Tree Source (post include)
*
- * Copyright 2011 Freescale Semiconductor Inc.
+ * Copyright 2011-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:
@@ -210,6 +210,20 @@
interrupt-parent = qeic;
};
+ ucc@2600 {
+ cell-index = 7;
+ reg = 0x2600 0x200;
+ interrupts = 42;
+ interrupt-parent = qeic;
+ };
+
+ ucc@2200 {
+ cell-index = 3;
+ reg = 0x2200 0x200;
+ interrupts = 34;
+ interrupt-parent = qeic;
+ };
+
muram@1 {
#address-cells = 1;
#size-cells = 1;
diff --git a/arch/powerpc/boot/dts/p1025rdb.dtsi
b/arch/powerpc/boot/dts/p1025rdb.dtsi
index 3875661..257adf9 100644
--- a/arch/powerpc/boot/dts/p1025rdb.dtsi
+++ b/arch/powerpc/boot/dts/p1025rdb.dtsi
@@ -272,5 +272,45 @@
0x1 0x4 0x2 0x0 0x2 0x0/*
ENET5_RX_DV_SER5_CTS_B */
0x1 0x8 0x2 0x0 0x2 0x0;/*
ENET5_RX_ER_SER5_CD_B */
};
+
+ pio3: ucc_pin@03 {
+ pio-map =
+ /* port pin dir open_drain assignment has_irq */
+ 0x0 0x16 0x2 0x0 0x2 0x0/* SER7_CD_B*/
+ 0x0 0x12 0x2 0x0 0x2 0x0/* SER7_CTS_B*/
+ 0x0 0x13 0x1 0x0 0x2 0x0/* SER7_RTS_B*/
+ 0x0 0x14 0x2 0x0 0x2 0x0/* SER7_RXD0*/
+ 0x0 0x15 0x1 0x0 0x2 0x0;/* SER7_TXD0*/
+ };
+
+ pio4: ucc_pin@04 {
+ pio-map =
+ /* port pin dir open_drain assignment has_irq */
+ 0x1 0x0 0x2 0x0 0x2 0x0/* SER3_CD_B*/
+ 0x0 0x1c 0x2 0x0 0x2 0x0/* SER3_CTS_B*/
+ 0x0 0x1d 0x1 0x0 0x2 0x0/* SER3_RTS_B*/
+ 0x0 0x1e 0x2 0x0 0x2 0x0/* SER3_RXD0*/
+ 0x0 0x1f 0x1 0x0 0x2 0x0;/* SER3_TXD0*/
+ };
+ };
+};
+
+qe {
+ serial2: ucc@2600 {
+ device_type = serial;
+ compatible = ucc_uart;
+ port-number = 0;
+ rx-clock-name = brg6;
+ tx-clock-name = brg6;
+ pio-handle = pio3;
+ };
+
+ serial3: ucc@2200 {
+ device_type = serial;
+ compatible = ucc_uart;
+ port-number = 1;
+ rx-clock-name = brg2;
+ tx-clock-name = brg2;
+ pio-handle = pio4;
};
};
--
1.6.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/1] powerpc: add memory attribute for mfmsr()
On Tue, 2012-07-10 at 15:59 +0800, Tiejun Chen wrote:
Add memory attribute in inline assembly language as a compiler
barrier to make sure 4.6.x GCC don't reorder mfmsr().
Out of curiosity, did you see a case where it was re-ordered
improperly ?
Cheers,
Ben.
Signed-off-by: Tiejun Chen tiejun.c...@windriver.com
---
arch/powerpc/include/asm/reg.h |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index 559da19..578e5a0 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -1016,7 +1016,8 @@
/* Macros for setting and retrieving special purpose registers */
#ifndef __ASSEMBLY__
#define mfmsr() ({unsigned long rval; \
- asm volatile(mfmsr %0 : =r (rval)); rval;})
+ asm volatile(mfmsr %0 : =r (rval) : \
+ : memory); rval;})
#ifdef CONFIG_PPC_BOOK3S_64
#define __mtmsrd(v, l) asm volatile(mtmsrd %0, __stringify(l) \
: : r (v) : memory)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] More fixes for lazy IRQ vs. idle
- hard_irq_disable();
- if (!lazy_irq_pending())
+ if (prep_irq_for_idle()) {
cede_processor();
+#ifdef CONFIG_TRACE_IRQFLAG
this is IRQFLAGS (missing S). I'll fix it while I commit, the same
typo is in another place in irq.c as well, I'll commit a fix for that
too and shoot the whole thing to Linus.
+ /* Ensure that H_CEDE returns with IRQs on */
+ WARN_ON(!(mfmsr() MSR_EE));
+#endif
+ }
}
static int dedicated_cede_loop(struct cpuidle_device *dev,
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/1] powerpc: add memory attribute for mfmsr()
On 07/10/2012 04:19 PM, Benjamin Herrenschmidt wrote:
On Tue, 2012-07-10 at 15:59 +0800, Tiejun Chen wrote:
Add memory attribute in inline assembly language as a compiler
barrier to make sure 4.6.x GCC don't reorder mfmsr().
Out of curiosity, did you see a case where it was re-ordered
improperly ?
Yes.
In my scenario, there's one simple wrapper from local_irq_save().
--
uint32_t XX_DisableAllIntr(void)
{
unsigned long flags;
local_irq_save(flags);
return (uint32_t)flags;
}
When CONFIG_TRACE_IRQFLAGS_SUPPORT is enabled, kernel would expand
local_irq_save(). Firstly, please refer to the follows:
#define local_irq_save(flags) \
do {\
raw_local_irq_save(flags); \
trace_hardirqs_off(); \
} while (0)
#define raw_local_irq_save(flags) \
do {\
typecheck(unsigned long, flags);\
flags = arch_local_irq_save(); \
} while (0)
static inline unsigned long arch_local_irq_save(void)
{
unsigned long flags = arch_local_save_flags();
#ifdef CONFIG_BOOKE
asm volatile(wrteei 0 : : : memory);
#else
SET_MSR_EE(flags ~MSR_EE);
#endif
return flags;
}
static inline unsigned long arch_local_save_flags(void)
{
return mfmsr();
}
So local_irq_save(flags) is extended as something like:
{
#1 flags = mfmsr();
#2 asm volatile(wrteei 0 : : : memory);
#3 trace_hardirqs_off();
}
But build kernel with our 5.0 toolchain (with/without
--with-toolchain-dir=wr-toolchain),
(gdb) disassemble XX_DisableAllIntr
Dump of assembler code for function XX_DisableAllIntr:
0xc04550c0 +0: mflrr0
0xc04550c4 +4: stw r0,4(r1)
0xc04550c8 +8: bl 0xc000f060 mcount
0xc04550cc +12:stwur1,-16(r1)
0xc04550d0 +16:mflrr0
0xc04550d4 +20:stw r0,20(r1)
0xc04550d8 +24:wrteei 0
0xc04550dc +28:bl 0xc00c6c10 trace_hardirqs_off
0xc04550e0 +32:mfmsr r3
0xc04550e4 +36:lwz r0,20(r1)
0xc04550e8 +40:mtlrr0
0xc04550ec +44:addir1,r1,16
0xc04550f0 +48:blr
End of assembler dump.
You should notice #2 and #3 is reorganized before #1. This means irq is always
disabled before we check irq status via reading msr. Then kernel would work as
abnormal sometimes.
But with old toolchain (4.5.x) for this same kernel, everything is fine.
Tiejun
Cheers,
Ben.
Signed-off-by: Tiejun Chen tiejun.c...@windriver.com
---
arch/powerpc/include/asm/reg.h |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index 559da19..578e5a0 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -1016,7 +1016,8 @@
/* Macros for setting and retrieving special purpose registers */
#ifndef __ASSEMBLY__
#define mfmsr() ({unsigned long rval; \
-asm volatile(mfmsr %0 : =r (rval)); rval;})
+asm volatile(mfmsr %0 : =r (rval) : \
+: memory); rval;})
#ifdef CONFIG_PPC_BOOK3S_64
#define __mtmsrd(v, l) asm volatile(mtmsrd %0, __stringify(l) \
: : r (v) : memory)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/1] powerpc: add memory attribute for mfmsr()
On 07/10/2012 04:22 PM, tiejun.chen wrote:
On 07/10/2012 04:19 PM, Benjamin Herrenschmidt wrote:
On Tue, 2012-07-10 at 15:59 +0800, Tiejun Chen wrote:
Add memory attribute in inline assembly language as a compiler
barrier to make sure 4.6.x GCC don't reorder mfmsr().
Out of curiosity, did you see a case where it was re-ordered
improperly ?
Yes.
In my scenario, there's one simple wrapper from local_irq_save().
--
uint32_t XX_DisableAllIntr(void)
{
unsigned long flags;
local_irq_save(flags);
return (uint32_t)flags;
}
When CONFIG_TRACE_IRQFLAGS_SUPPORT is enabled, kernel would expand
local_irq_save(). Firstly, please refer to the follows:
#define local_irq_save(flags) \
do {\
raw_local_irq_save(flags); \
trace_hardirqs_off(); \
} while (0)
#define raw_local_irq_save(flags) \
do {\
typecheck(unsigned long, flags);\
flags = arch_local_irq_save(); \
} while (0)
static inline unsigned long arch_local_irq_save(void)
{
unsigned long flags = arch_local_save_flags();
#ifdef CONFIG_BOOKE
asm volatile(wrteei 0 : : : memory);
#else
SET_MSR_EE(flags ~MSR_EE);
#endif
return flags;
}
static inline unsigned long arch_local_save_flags(void)
{
return mfmsr();
}
So local_irq_save(flags) is extended as something like:
{
#1 flags = mfmsr();
#2 asm volatile(wrteei 0 : : : memory);
#3 trace_hardirqs_off();
}
But build kernel with our 5.0 toolchain (with/without
Note here this toolchain is based on 4.6.3.
Tiejun
--with-toolchain-dir=wr-toolchain),
(gdb) disassemble XX_DisableAllIntr
Dump of assembler code for function XX_DisableAllIntr:
0xc04550c0 +0: mflrr0
0xc04550c4 +4: stw r0,4(r1)
0xc04550c8 +8: bl 0xc000f060 mcount
0xc04550cc +12: stwur1,-16(r1)
0xc04550d0 +16: mflrr0
0xc04550d4 +20: stw r0,20(r1)
0xc04550d8 +24: wrteei 0
0xc04550dc +28: bl 0xc00c6c10 trace_hardirqs_off
0xc04550e0 +32: mfmsr r3
0xc04550e4 +36: lwz r0,20(r1)
0xc04550e8 +40: mtlrr0
0xc04550ec +44: addir1,r1,16
0xc04550f0 +48: blr
End of assembler dump.
You should notice #2 and #3 is reorganized before #1. This means irq is always
disabled before we check irq status via reading msr. Then kernel would work as
abnormal sometimes.
But with old toolchain (4.5.x) for this same kernel, everything is fine.
Tiejun
Cheers,
Ben.
Signed-off-by: Tiejun Chen tiejun.c...@windriver.com
---
arch/powerpc/include/asm/reg.h |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index 559da19..578e5a0 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -1016,7 +1016,8 @@
/* Macros for setting and retrieving special purpose registers */
#ifndef __ASSEMBLY__
#define mfmsr()({unsigned long rval; \
- asm volatile(mfmsr %0 : =r (rval)); rval;})
+ asm volatile(mfmsr %0 : =r (rval) : \
+ : memory); rval;})
#ifdef CONFIG_PPC_BOOK3S_64
#define __mtmsrd(v, l) asm volatile(mtmsrd %0, __stringify(l) \
: : r (v) : memory)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[git pull] Please pull powerpc.git merge branch
Hi Linus ! It looks like my rewrite of our lazy irq scheme is still exposing interesting issues left and right. The previous fixes are now causing an occasional BUG_ON to trigger (which this patch turns into a WARN_ON while at it), due to another issue of disconnect of the lazy irq state vs. the processor state in the idle loop on pseries and cell. This should fix it properly once for all moving the nasty code to a common helper function. There's also couple more fixes for some debug stuff that didn't build (and helped resolving those problems so it's worth having), along with a compile fix for newer gcc's. Cheers, Ben. The following changes since commit 2437fccfbfc83bcb868ccc7fdfe2b5310bf07835: Merge tag 'regulator-3.5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator (2012-07-09 13:43:02 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge for you to fetch changes up to 50fb31cfed9218b439360caf7c0399b00042da15: tty/hvc_opal: Fix debug function name (2012-07-10 19:16:25 +1000) Benjamin Herrenschmidt (4): powerpc: More fixes for lazy IRQ vs. idle powerpc: Fix build of some debug irq code powerpc/numa: Avoid stupid uninitialized warning from gcc tty/hvc_opal: Fix debug function name arch/powerpc/include/asm/hw_irq.h |6 ++- arch/powerpc/kernel/irq.c | 48 ++- arch/powerpc/mm/numa.c |2 +- arch/powerpc/platforms/cell/pervasive.c | 11 +++--- arch/powerpc/platforms/pseries/processor_idle.c | 17 drivers/tty/hvc/hvc_opal.c |2 +- 6 files changed, 69 insertions(+), 17 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 3/3 v2] powerpc/mpic: FSL MPIC error interrupt support.
+ u32 eisr, eimr;
+ int errint;
+ unsigned int cascade_irq;
+
+ eisr = fsl_mpic_err_read(mpic-err_regs, eisr_offset);
+ eimr = fsl_mpic_err_read(mpic-err_regs, eimr_offset);
+
+ if (!(eisr ~eimr))
+ return IRQ_NONE;
+
+ while (eisr) {
+ errint = __builtin_clz(eisr);
+ cascade_irq = irq_linear_revmap(mpic-irqhost,
+mpic-err_int_vecs[errint]);
+ WARN_ON(cascade_irq == NO_IRQ);
+ if (cascade_irq != NO_IRQ) {
+ generic_handle_irq(cascade_irq);
+ } else {
+ eimr |= 1 (31 - errint);
+ fsl_mpic_err_write(mpic-err_regs, eimr_offset, eimr);
+ }
+ eisr = ~(1 (31 - errint));
+ }
+
+ return IRQ_HANDLED;
+}
+
+int mpic_err_int_init(struct mpic *mpic, irq_hw_number_t irqnum) {
Why can't we do this during mpic_init() time?
[Sethi Varun-B16395] Don't want to hard code the error interrupt number.
+ unsigned int virq;
+ unsigned int offset = MPIC_ERR_INT_EIMR;
remove offset, just use MPIC_ERR_INT_EIMR in mpic_err_write
+ int ret;
+
+ virq = irq_create_mapping(mpic-irqhost, irqnum);
+ if (virq == NO_IRQ) {
+ pr_err(Error interrupt setup failed\n);
+ return -ENOSPC;
+ }
+
+ fsl_mpic_err_write(mpic-err_regs, offset, ~0);
Add a comment about what this line is doing
[Sethi Varun-B16395] We are masking all the error interrupts here. I
Will add a comment for this.
+
+ ret = request_irq(virq, fsl_error_int_handler, IRQF_NO_THREAD,
+ mpic-error-int, mpic);
Hmm, should we be using irq_set_chained_handler() instead of request_irq
+ if (ret) {
+ pr_err(Failed to register error interrupt handler\n);
+ return ret;
+ }
+
+ return 0;
+}
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 61c7225..7002ef3 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -1026,6 +1026,9 @@ static int mpic_host_map(struct irq_domain *h,
unsigned int virq,
return 0;
}
+ if (mpic_map_error_int(mpic, virq, hw))
+ return 0;
+
if (hw = mpic-num_sources)
return -EINVAL;
@@ -1085,7 +1088,24 @@ static int mpic_host_xlate(struct irq_domain *h,
struct device_node *ct,
*/
switch (intspec[2]) {
case 0:
- case 1: /* no EISR/EIMR support for now, treat as shared IRQ
*/
+ break;
+ case 1:
+ if (!(mpic-flags MPIC_FSL_HAS_EIMR))
+ break;
+
+ if (intspec[3] = ARRAY_SIZE(mpic-err_int_vecs))
+ return -EINVAL;
+
+ if (!mpic-err_int_config_done) {
+ int ret;
+ ret = mpic_err_int_init(mpic, intspec[0]);
+ if (ret)
+ return ret;
+ mpic-err_int_config_done = 1;
+ }
+
+ *out_hwirq = mpic-err_int_vecs[intspec[3]];
+
break;
case 2:
if (intspec[0] = ARRAY_SIZE(mpic-ipi_vecs)) @@ -
1302,6 +1322,8 @@
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, version;
+
/*
* Yes, Freescale really did put global registers in the
* magic per-cpu area -- and they don't even show up in the
@@
-1309,6 +1331,17 @@ 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);
+ version = brr1 MPIC_FSL_BRR1_VER;
+
+ /* Error interrupt mask register (EIMR) is required for
+* handling individual device error interrupts. EIMR
+* was added in MPIC version 4.1.
+*/
+ if (version = 0x401)
+ mpic_setup_error_int(mpic, intvec_top - 12);
Would really like not to have this magic 12, but a comment would be nice
if we keep it where the 12 comes from
[Sethi Varun-B16395]Obtaining vector numbers beyond ipi and timers for the
error interrupts.
Will add a comment.
-Varun
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 3/3 v2] powerpc/mpic: FSL MPIC error interrupt support.
-Original Message-
From: Kumar Gala [mailto:ga...@kernel.crashing.org]
Sent: Tuesday, July 10, 2012 7:17 AM
To: Wood Scott-B07421
Cc: Sethi Varun-B16395; Hamciuc Bogdan-BHAMCIU1; linuxppc-
d...@lists.ozlabs.org
Subject: Re: [PATCH 3/3 v2] powerpc/mpic: FSL MPIC error interrupt
support.
On Jul 9, 2012, at 3:22 PM, Scott Wood wrote:
On 07/09/2012 02:03 PM, Kumar Gala wrote:
On Jul 9, 2012, at 3:47 AM, Varun Sethi wrote:
+int mpic_err_int_init(struct mpic *mpic, irq_hw_number_t irqnum) {
Why can't we do this during mpic_init() time?
Are you willing to hardcode that IRQ 16 is the error interrupt,
without waiting to see an intspec?
I'm torn, but the bit of code in mpic_host_xlate that calls
mpic_err_int_init() is just ugly.
We could consider it similar to how we assume IPIs.
[Sethi Varun-B16395] I don't understand this point.
-Varun
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v3 0/13] memory-hotplug : hot-remove physical memory
Hi Christoph, 2012/07/10 0:18, Christoph Lameter wrote: On Mon, 9 Jul 2012, Yasuaki Ishimatsu wrote: Even if you apply these patches, you cannot remove the physical memory completely since these patches are still under development. I want you to cooperate to improve the physical memory hot-remove. So please review these patches and give your comment/idea. Could you at least give a method on how you want to do physical memory removal? We plan to release a dynamic hardware partitionable system. It will be able to hot remove/add a system board which included memory and cpu. But as you know, Linux does not support memory hot-remove on x86 box. So I try to develop it. Current plan to hot remove system board is to use container driver. Thus I define the system board in ACPI DSDT table as a container device. It have supported hot-add a container device. And if container device has _EJ0 ACPI method, eject file to remove the container device is prepared as follow: # ls -l /sys/bus/acpi/devices/ACPI0004\:01/eject --w---. 1 root root 4096 Jul 10 18:19 /sys/bus/acpi/devices/ACPI0004:01/eject When I hot-remove the container device, I echo 1 to the file as follow: #echo 1 /sys/bus/acpi/devices/ACPI0004\:02/eject Then acpi_bus_trim() is called. And it calls acpi_memory_device_remove() for removing memory device. But the code does not do nothing. So I developed the continuation of the function. You would have to remove all objects from the range you want to physically remove. That is only possible under special circumstances and with a limited set of objects. Even if you exclusively use ZONE_MOVEABLE you still may get cases where pages are pinned for a long time. I know it. So my memory hot-remove plan is as follows: 1. hot-added a system board All memory which included the system board is offline. 2. online the memory as removable page The function has not supported yet. It is being developed by Lai as follow: http://lkml.indiana.edu/hypermail/linux/kernel/1207.0/01478.html If it is supported, I will be able to create movable memory. 3. hot-remove the memory by container device's eject file Thanks, Yasuaki Ishimatsu I am not sure that these patches are useful unless we know where you are going with this. If we end up with a situation where we still cannot remove physical memory then this patchset is not helpful. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 1/2] powerpc/watchdog: move booke watchdog param related code to prom.c
Hi, All,
Is there any concern for this patch, it's been a long time.
Thanks!
Best Regards,
Shaohui Xie
-Original Message-
From: Xie Shaohui-B21989
Sent: Tuesday, May 08, 2012 2:07 PM
To: linux-watch...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
Cc: Xie Shaohui-B21989
Subject: [PATCH 1/2] powerpc/watchdog: move booke watchdog param related
code to prom.c
Currently, BOOKE watchdog code for checking wdt and wdt_period is in
setup_32.c, it cannot be used in 64-bit, so move it to a common place
prom.c, which will be shared by 32-bit and 64-bit.
Also, replace the simple_strtoul with kstrtol.
Signed-off-by: Shaohui Xie shaohui@freescale.com
---
arch/powerpc/kernel/prom.c | 27 +++
arch/powerpc/kernel/setup_32.c | 24
2 files changed, 27 insertions(+), 24 deletions(-)
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c index
f191bf0..49e1bdf 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -84,6 +84,33 @@ static int __init early_parse_mem(char *p) }
early_param(mem, early_parse_mem);
+#ifdef CONFIG_BOOKE_WDT
+extern u32 booke_wdt_enabled;
+extern u32 booke_wdt_period;
+
+/* Checks wdt=x and wdt_period=xx command-line option */ notrace int
+__init early_parse_wdt(char *p) {
+ if (p strncmp(p, 0, 1) != 0)
+ booke_wdt_enabled = 1;
+
+ return 0;
+}
+early_param(wdt, early_parse_wdt);
+
+int __init early_parse_wdt_period(char *p) {
+ unsigned long ret;
+ if (p) {
+ if (!kstrtol(p, 0, ret))
+ booke_wdt_period = ret;
+ }
+
+ return 0;
+}
+early_param(wdt_period, early_parse_wdt_period);
+#endif/* CONFIG_BOOKE_WDT */
+
/*
* overlaps_initrd - check for overlap with page aligned extension of
* initrd.
diff --git a/arch/powerpc/kernel/setup_32.c
b/arch/powerpc/kernel/setup_32.c index ec8a53f..a8f54ec 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -149,30 +149,6 @@ notrace void __init machine_init(u64 dt_ptr)
ppc_md.progress(id mach(): done, 0x200); }
-#ifdef CONFIG_BOOKE_WDT
-extern u32 booke_wdt_enabled;
-extern u32 booke_wdt_period;
-
-/* Checks wdt=x and wdt_period=xx command-line option */ -notrace int
__init early_parse_wdt(char *p) -{
- if (p strncmp(p, 0, 1) != 0)
- booke_wdt_enabled = 1;
-
- return 0;
-}
-early_param(wdt, early_parse_wdt);
-
-int __init early_parse_wdt_period (char *p) -{
- if (p)
- booke_wdt_period = simple_strtoul(p, NULL, 0);
-
- return 0;
-}
-early_param(wdt_period, early_parse_wdt_period);
-#endif/* CONFIG_BOOKE_WDT */
-
/* Checks l2cr= command-line option */ int __init
ppc_setup_l2cr(char *str) {
--
1.6.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 2/2][v2] powerpc/watchdog: replace CONFIG_FSL_BOOKE with CONFIG_PPC_FSL_BOOK3E
Hi, All, Is there any concern for this patch, it's been a long time. Thanks! Best Regards, Shaohui Xie -Original Message- From: Xie Shaohui-B21989 Sent: Friday, May 11, 2012 1:34 PM To: linux-watch...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org Cc: Xie Shaohui-B21989 Subject: [PATCH 2/2][v2] powerpc/watchdog: replace CONFIG_FSL_BOOKE with CONFIG_PPC_FSL_BOOK3E CONFIG_FSL_BOOKE is only defined in 32-bit, CONFIG_PPC_FSL_BOOK3E is defined in both 32-bit and 64-bit, so use CONFIG_PPC_FSL_BOOK3E to make driver work in 32-bit 64-bit. Signed-off-by: Shaohui Xie shaohui@freescale.com --- changes for v2: use PPC_FSL_BOOK3E instead of FSL_SOC_BOOKE. drivers/watchdog/Kconfig |8 drivers/watchdog/booke_wdt.c |4 ++-- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index 3709624..4373ca0 100644 --- a/drivers/watchdog/Kconfig +++ b/drivers/watchdog/Kconfig @@ -1094,10 +1094,10 @@ config BOOKE_WDT config BOOKE_WDT_DEFAULT_TIMEOUT int PowerPC Book-E Watchdog Timer Default Timeout depends on BOOKE_WDT - default 38 if FSL_BOOKE - range 0 63 if FSL_BOOKE - default 3 if !FSL_BOOKE - range 0 3 if !FSL_BOOKE + default 38 if PPC_FSL_BOOK3E + range 0 63 if PPC_FSL_BOOK3E + default 3 if !PPC_FSL_BOOK3E + range 0 3 if !PPC_FSL_BOOK3E help Select the default watchdog timer period to be used by the PowerPC Book-E watchdog driver. A watchdog event occurs when the bit diff --git a/drivers/watchdog/booke_wdt.c b/drivers/watchdog/booke_wdt.c index ce0ab44..338a437 100644 --- a/drivers/watchdog/booke_wdt.c +++ b/drivers/watchdog/booke_wdt.c @@ -37,7 +37,7 @@ u32 booke_wdt_enabled; u32 booke_wdt_period = CONFIG_BOOKE_WDT_DEFAULT_TIMEOUT; -#ifdefCONFIG_FSL_BOOKE +#ifdefCONFIG_PPC_FSL_BOOK3E #define WDTP(x) x)0x3)30)|(((x)0x3c)15)) #define WDTP_MASK (WDTP(0x3f)) #else @@ -190,7 +190,7 @@ static long booke_wdt_ioctl(struct file *file, case WDIOC_SETTIMEOUT: if (get_user(tmp, p)) return -EFAULT; -#ifdefCONFIG_FSL_BOOKE +#ifdefCONFIG_PPC_FSL_BOOK3E /* period of 1 gives the largest possible timeout */ if (tmp period_to_sec(1)) return -EINVAL; -- 1.6.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] powerpc/fsl: Update corenet32_smp_defconfig
* Enable NAND, MSI, PAMU, * Enable FSL RAID on P5020 * Enable general RAID features (MD + async-tx) * Enable RTC on P2041RDB * Enable UIO SRIO UIO DMA Signed-off-by: Harninder Rai harninder@freescale.com Signed-off-by: Shaohui Xie shaohui@freescale.com Signed-off-by: Minghuan Lian minghuan.l...@freescale.com Signed-off-by: Kumar Gala ga...@kernel.crashing.org Signed-off-by: Shengzhou Liu shengzhou@freescale.com --- arch/powerpc/configs/corenet32_smp_defconfig | 22 +- 1 files changed, 21 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/configs/corenet32_smp_defconfig b/arch/powerpc/configs/corenet32_smp_defconfig index 91db656..eafb64f 100644 --- a/arch/powerpc/configs/corenet32_smp_defconfig +++ b/arch/powerpc/configs/corenet32_smp_defconfig @@ -34,8 +34,10 @@ CONFIG_BINFMT_MISC=m CONFIG_KEXEC=y CONFIG_FORCE_MAX_ZONEORDER=13 CONFIG_FSL_LBC=y +CONFIG_FSL_PAMU=y CONFIG_PCI=y CONFIG_PCIEPORTBUS=y +CONFIG_PCI_MSI=y # CONFIG_PCIEASPM is not set CONFIG_RAPIDIO=y CONFIG_FSL_RIO=y @@ -76,11 +78,16 @@ CONFIG_MTD_BLOCK=y CONFIG_MTD_CFI=y CONFIG_MTD_CFI_AMDSTD=y CONFIG_MTD_PHYSMAP_OF=y +CONFIG_MTD_NAND=y +CONFIG_MTD_NAND_ECC=y +CONFIG_MTD_NAND_IDS=y +CONFIG_MTD_NAND_FSL_IFC=y +CONFIG_MTD_NAND_FSL_ELBC=y CONFIG_MTD_M25P80=y CONFIG_PROC_DEVICETREE=y CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_RAM=y -CONFIG_BLK_DEV_RAM_SIZE=131072 +CONFIG_BLK_DEV_RAM_SIZE=262144 CONFIG_MISC_DEVICES=y CONFIG_BLK_DEV_SD=y CONFIG_CHR_DEV_ST=y @@ -95,6 +102,10 @@ CONFIG_SATA_FSL=y CONFIG_SATA_SIL24=y CONFIG_SATA_SIL=y CONFIG_PATA_SIL680=y +CONFIG_MD=y +CONFIG_BLK_DEV_MD=y +CONFIG_MD_RAID456=y +CONFIG_MULTICORE_RAID456=y CONFIG_NETDEVICES=y CONFIG_FSL_PQ_MDIO=y CONFIG_E1000=y @@ -136,13 +147,21 @@ CONFIG_USB_OHCI_HCD_PPC_OF_LE=y CONFIG_USB_STORAGE=y CONFIG_MMC=y CONFIG_MMC_SDHCI=y +CONFIG_MMC_SDHCI_OF=y +CONFIG_MMC_SDHCI_OF_ESDHC=y CONFIG_EDAC=y CONFIG_EDAC_MM_EDAC=y CONFIG_EDAC_MPC85XX=y CONFIG_RTC_CLASS=y +CONFIG_RTC_DRV_DS1307=y CONFIG_RTC_DRV_DS3232=y CONFIG_RTC_DRV_CMOS=y +CONFIG_DMADEVICES=y +CONFIG_FSL_RAID=y +CONFIG_ASYNC_TX_DMA=y CONFIG_UIO=y +CONFIG_UIO_FSL_SRIO=y +CONFIG_UIO_FSL_DMA=y CONFIG_STAGING=y CONFIG_VIRT_DRIVERS=y CONFIG_FSL_HV_MANAGER=y @@ -171,6 +190,7 @@ CONFIG_MAC_PARTITION=y CONFIG_NLS_ISO8859_1=y CONFIG_NLS_UTF8=m CONFIG_MAGIC_SYSRQ=y +CONFIG_DEBUG_KERNEL=y CONFIG_DEBUG_SHIRQ=y CONFIG_DETECT_HUNG_TASK=y CONFIG_DEBUG_INFO=y -- 1.6.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] powerpc/fsl: Update corenet32_smp_defconfig
* Enable NAND, MSI, PAMU, * Enable FSL RAID on P5020 * Enable general RAID features (MD + async-tx) * Enable RTC on P2041RDB * Enable UIO SRIO UIO DMA Signed-off-by: Harninder Rai harninder@freescale.com Signed-off-by: Shaohui Xie shaohui@freescale.com Signed-off-by: Minghuan Lian minghuan.l...@freescale.com Signed-off-by: Kumar Gala ga...@kernel.crashing.org Signed-off-by: Shengzhou Liu shengzhou@freescale.com --- arch/powerpc/configs/corenet32_smp_defconfig | 22 +- 1 files changed, 21 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/configs/corenet32_smp_defconfig b/arch/powerpc/configs/corenet32_smp_defconfig index 91db656..eafb64f 100644 --- a/arch/powerpc/configs/corenet32_smp_defconfig +++ b/arch/powerpc/configs/corenet32_smp_defconfig @@ -34,8 +34,10 @@ CONFIG_BINFMT_MISC=m CONFIG_KEXEC=y CONFIG_FORCE_MAX_ZONEORDER=13 CONFIG_FSL_LBC=y +CONFIG_FSL_PAMU=y CONFIG_PCI=y CONFIG_PCIEPORTBUS=y +CONFIG_PCI_MSI=y # CONFIG_PCIEASPM is not set CONFIG_RAPIDIO=y CONFIG_FSL_RIO=y @@ -76,11 +78,16 @@ CONFIG_MTD_BLOCK=y CONFIG_MTD_CFI=y CONFIG_MTD_CFI_AMDSTD=y CONFIG_MTD_PHYSMAP_OF=y +CONFIG_MTD_NAND=y +CONFIG_MTD_NAND_ECC=y +CONFIG_MTD_NAND_IDS=y +CONFIG_MTD_NAND_FSL_IFC=y +CONFIG_MTD_NAND_FSL_ELBC=y CONFIG_MTD_M25P80=y CONFIG_PROC_DEVICETREE=y CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_RAM=y -CONFIG_BLK_DEV_RAM_SIZE=131072 +CONFIG_BLK_DEV_RAM_SIZE=262144 CONFIG_MISC_DEVICES=y CONFIG_BLK_DEV_SD=y CONFIG_CHR_DEV_ST=y @@ -95,6 +102,10 @@ CONFIG_SATA_FSL=y CONFIG_SATA_SIL24=y CONFIG_SATA_SIL=y CONFIG_PATA_SIL680=y +CONFIG_MD=y +CONFIG_BLK_DEV_MD=y +CONFIG_MD_RAID456=y +CONFIG_MULTICORE_RAID456=y CONFIG_NETDEVICES=y CONFIG_FSL_PQ_MDIO=y CONFIG_E1000=y @@ -136,13 +147,21 @@ CONFIG_USB_OHCI_HCD_PPC_OF_LE=y CONFIG_USB_STORAGE=y CONFIG_MMC=y CONFIG_MMC_SDHCI=y +CONFIG_MMC_SDHCI_OF=y +CONFIG_MMC_SDHCI_OF_ESDHC=y CONFIG_EDAC=y CONFIG_EDAC_MM_EDAC=y CONFIG_EDAC_MPC85XX=y CONFIG_RTC_CLASS=y +CONFIG_RTC_DRV_DS1307=y CONFIG_RTC_DRV_DS3232=y CONFIG_RTC_DRV_CMOS=y +CONFIG_DMADEVICES=y +CONFIG_FSL_RAID=y +CONFIG_ASYNC_TX_DMA=y CONFIG_UIO=y +CONFIG_UIO_FSL_SRIO=y +CONFIG_UIO_FSL_DMA=y CONFIG_STAGING=y CONFIG_VIRT_DRIVERS=y CONFIG_FSL_HV_MANAGER=y @@ -171,6 +190,7 @@ CONFIG_MAC_PARTITION=y CONFIG_NLS_ISO8859_1=y CONFIG_NLS_UTF8=m CONFIG_MAGIC_SYSRQ=y +CONFIG_DEBUG_KERNEL=y CONFIG_DEBUG_SHIRQ=y CONFIG_DETECT_HUNG_TASK=y CONFIG_DEBUG_INFO=y -- 1.6.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] powerpc/fsl: Update corenet64_smp_defconfig
* Enable USB, MMC, SATA, MTD, NAND, PAMU, RTC * Enable FSL RAID on P5020 * Enable general RAID features (MD + async-tx) * Enable RTC on P2041RDB * Enable UIO SRIO UIO DMA * Enable USDPAA SHMEM driver * Enable ePAPR HV support * Enable PCI-E support Signed-off-by: Haiying Wang haiying.w...@freescale.com Signed-off-by: Laurentiu Tudor laurentiu.tu...@freescale.com Signed-off-by: Harninder Rai harninder@freescale.com Signed-off-by: Minghuan Lian minghuan.l...@freescale.com Signed-off-by: Kumar Gala ga...@kernel.crashing.org Signed-off-by: Shengzhou Liu shengzhou@freescale.com --- arch/powerpc/configs/corenet64_smp_defconfig | 94 -- 1 files changed, 89 insertions(+), 5 deletions(-) diff --git a/arch/powerpc/configs/corenet64_smp_defconfig b/arch/powerpc/configs/corenet64_smp_defconfig index 6798343..14bbae7 100644 --- a/arch/powerpc/configs/corenet64_smp_defconfig +++ b/arch/powerpc/configs/corenet64_smp_defconfig @@ -5,14 +5,21 @@ CONFIG_SMP=y CONFIG_NR_CPUS=2 CONFIG_EXPERIMENTAL=y CONFIG_SYSVIPC=y +CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y +CONFIG_AUDIT=y CONFIG_SPARSE_IRQ=y +CONFIG_RCU_TRACE=y +CONFIG_RCU_FANOUT=32 CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=14 CONFIG_BLK_DEV_INITRD=y CONFIG_EXPERT=y CONFIG_KALLSYMS_ALL=y +CONFIG_EMBEDDED=y +CONFIG_PERF_EVENTS=y +CONFIG_SLAB=y CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y @@ -25,11 +32,18 @@ CONFIG_HIGH_RES_TIMERS=y CONFIG_BINFMT_MISC=m CONFIG_RAPIDIO=y CONFIG_FSL_RIO=y +CONFIG_FSL_LBC=y +CONFIG_FSL_PAMU=y +CONFIG_PCIEPORTBUS=y +CONFIG_PCI_MSI=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_UNIX=y CONFIG_XFRM_USER=y +CONFIG_XFRM_SUB_POLICY=y +CONFIG_XFRM_STATISTICS=y CONFIG_NET_KEY=y +CONFIG_NET_KEY_MIGRATE=y CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_ADVANCED_ROUTER=y @@ -45,60 +59,130 @@ CONFIG_IP_MROUTE=y CONFIG_IP_PIMSM_V1=y CONFIG_IP_PIMSM_V2=y CONFIG_ARPD=y +CONFIG_INET_AH=y CONFIG_INET_ESP=y +CONFIG_INET_IPCOMP=y # CONFIG_INET_XFRM_MODE_BEET is not set # CONFIG_INET_LRO is not set CONFIG_IPV6=y CONFIG_IP_SCTP=m CONFIG_UEVENT_HELPER_PATH=/sbin/hotplug +CONFIG_MTD=y +CONFIG_MTD_CMDLINE_PARTS=y +CONFIG_MTD_CHAR=y +CONFIG_MTD_BLOCK=y +CONFIG_MTD_CFI=y +CONFIG_MTD_CFI_AMDSTD=y +CONFIG_MTD_PHYSMAP_OF=y +CONFIG_MTD_M25P80=y CONFIG_PROC_DEVICETREE=y CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_RAM=y -CONFIG_BLK_DEV_RAM_SIZE=131072 +CONFIG_BLK_DEV_RAM_SIZE=262144 CONFIG_MISC_DEVICES=y CONFIG_EEPROM_LEGACY=y -CONFIG_NETDEVICES=y +CONFIG_BLK_DEV_SD=y +CONFIG_CHR_DEV_ST=y +CONFIG_BLK_DEV_SR=y +CONFIG_CHR_DEV_SG=y +CONFIG_SCSI_MULTI_LUN=y +CONFIG_SCSI_LOGGING=y +CONFIG_SCSI_SPI_ATTRS=y +CONFIG_ATA=y +CONFIG_SATA_FSL=y +CONFIG_SATA_SIL24=y +CONFIG_MD=y +CONFIG_BLK_DEV_MD=y +CONFIG_MD_RAID456=y +CONFIG_MULTICORE_RAID456=y CONFIG_DUMMY=y CONFIG_INPUT_FF_MEMLESS=m # CONFIG_INPUT_MOUSEDEV is not set # CONFIG_INPUT_KEYBOARD is not set # CONFIG_INPUT_MOUSE is not set CONFIG_SERIO_LIBPS2=y +CONFIG_PPC_EPAPR_HV_BYTECHAN=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_EXTENDED=y CONFIG_SERIAL_8250_MANY_PORTS=y CONFIG_SERIAL_8250_DETECT_IRQ=y CONFIG_SERIAL_8250_RSA=y +CONFIG_HW_RANDOM=y CONFIG_I2C=y CONFIG_I2C_CHARDEV=y CONFIG_I2C_MPC=y +CONFIG_SPI=y +CONFIG_SPI_GPIO=y +CONFIG_SPI_FSL_SPI=y +CONFIG_SPI_FSL_ESPI=y # CONFIG_HWMON is not set CONFIG_VIDEO_OUTPUT_CONTROL=y -# CONFIG_HID_SUPPORT is not set -# CONFIG_USB_SUPPORT is not set +CONFIG_USB_HID=m +CONFIG_USB=y +CONFIG_USB_DEVICEFS=y +CONFIG_USB_MON=y +CONFIG_USB_EHCI_HCD=y +CONFIG_USB_EHCI_FSL=y +CONFIG_USB_STORAGE=y +CONFIG_MMC=y +CONFIG_MMC_SDHCI=y +CONFIG_MMC_SDHCI_OF=y +CONFIG_MMC_SDHCI_OF_ESDHC=y +CONFIG_EDAC=y +CONFIG_EDAC_MM_EDAC=y +CONFIG_RTC_CLASS=y +CONFIG_RTC_DRV_DS3232=y +CONFIG_RTC_DRV_CMOS=y CONFIG_DMADEVICES=y CONFIG_FSL_DMA=y +CONFIG_FSL_RAID=y +CONFIG_ASYNC_TX_DMA=y +CONFIG_UIO=y +CONFIG_UIO_FSL_SRIO=y +CONFIG_UIO_FSL_DMA=y +CONFIG_STAGING=y +CONFIG_VIRT_DRIVERS=y +CONFIG_FSL_HV_MANAGER=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y -# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set +CONFIG_ISO9660_FS=m +CONFIG_JOLIET=y +CONFIG_ZISOFS=y +CONFIG_UDF_FS=m +CONFIG_MSDOS_FS=m +CONFIG_VFAT_FS=y +CONFIG_NTFS_FS=y CONFIG_PROC_KCORE=y CONFIG_TMPFS=y CONFIG_HUGETLBFS=y +CONFIG_JFFS2_FS=y +CONFIG_CRAMFS=y +CONFIG_NFS_FS=y +CONFIG_NFS_V3=y +CONFIG_NFS_V4=y +CONFIG_ROOT_NFS=y +CONFIG_NFSD=m # CONFIG_MISC_FILESYSTEMS is not set CONFIG_PARTITION_ADVANCED=y CONFIG_MAC_PARTITION=y CONFIG_NLS=y +CONFIG_NLS_ISO8859_1=y CONFIG_NLS_UTF8=m CONFIG_CRC_T10DIF=y CONFIG_CRC_ITU_T=m CONFIG_FRAME_WARN=1024 +CONFIG_MAGIC_SYSRQ=y +CONFIG_DEBUG_KERNEL=y +CONFIG_DEBUG_SHIRQ=y CONFIG_DEBUG_FS=y CONFIG_DETECT_HUNG_TASK=y CONFIG_DEBUG_INFO=y CONFIG_SYSCTL_SYSCALL_CHECK=y +CONFIG_CRYPTO_NULL=y CONFIG_IRQ_DOMAIN_DEBUG=y CONFIG_CRYPTO_PCBC=m +CONFIG_CRYPTO_MD4=y CONFIG_CRYPTO_SHA256=y CONFIG_CRYPTO_SHA512=y CONFIG_CRYPTO_AES=y -- 1.6.4
[PATCH] powerpc/85xx: Add dts files for P1021RDB-PC board
P1021RDB-PC Overview
-
1Gbyte DDR3 (on board DDR)
16Mbyte NOR flash
32Mbyte eSLC NAND Flash
256 Kbit M24256 I2C EEPROM
128 Mbit SPI Flash memory
Real-time clock on I2C bus
SD/MMC connector to interface with the SD memory card
PCIex
- x1 PCIe slot or x1 PCIe to dual SATA controller
- x1 mini-PCIe slot
USB 2.0
- ULPI PHY interface: SMSC USB3300 USB PHY and Genesys Logic’s GL850A
- Two USB2.0 Type A receptacles
- One USB2.0 signal to Mini PCIe slot
eTSEC1: Connected to RGMII PHY VSC7385
eTSEC2: Connected to SGMII PHY VSC8221
eTSEC3: Connected to SGMII PHY AR8021
DUART interface: supports two UARTs up to 115200 bps for console display
Signed-off-by: Xu Jiucheng jiucheng...@freescale.com
Signed-off-by: Matthew McClintock m...@freescale.com
---
arch/powerpc/boot/dts/p1021rdb-pc.dtsi| 236 +
arch/powerpc/boot/dts/p1021rdb-pc_32b.dts | 96
arch/powerpc/boot/dts/p1021rdb-pc_36b.dts | 96
arch/powerpc/boot/dts/p1021rdb.dts| 96
arch/powerpc/boot/dts/p1021rdb.dtsi | 236 -
arch/powerpc/boot/dts/p1021rdb_36b.dts| 96
6 files changed, 428 insertions(+), 428 deletions(-)
create mode 100644 arch/powerpc/boot/dts/p1021rdb-pc.dtsi
create mode 100644 arch/powerpc/boot/dts/p1021rdb-pc_32b.dts
create mode 100644 arch/powerpc/boot/dts/p1021rdb-pc_36b.dts
delete mode 100644 arch/powerpc/boot/dts/p1021rdb.dts
delete mode 100644 arch/powerpc/boot/dts/p1021rdb.dtsi
delete mode 100644 arch/powerpc/boot/dts/p1021rdb_36b.dts
diff --git a/arch/powerpc/boot/dts/p1021rdb-pc.dtsi
b/arch/powerpc/boot/dts/p1021rdb-pc.dtsi
new file mode 100644
index 000..b973461
--- /dev/null
+++ b/arch/powerpc/boot/dts/p1021rdb-pc.dtsi
@@ -0,0 +1,236 @@
+/*
+ * P1021 RDB Device Tree Source stub (no addresses or top-level ranges)
+ *
+ * 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.
+ */
+
+lbc {
+ nor@0,0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = cfi-flash;
+ reg = 0x0 0x0 0x100;
+ bank-width = 2;
+ device-width = 1;
+
+ partition@0 {
+ /* This location must not be altered */
+ /* 256KB for Vitesse 7385 Switch firmware */
+ reg = 0x0 0x0004;
+ label = NOR Vitesse-7385 Firmware;
+ read-only;
+ };
+
+ partition@4 {
+ /* 256KB for DTB Image */
+ reg = 0x0004 0x0004;
+ label = NOR DTB Image;
+ };
+
+ partition@8 {
+ /* 3.5 MB for Linux Kernel Image */
+ reg = 0x0008 0x0038;
+ label = NOR Linux Kernel Image;
+ };
+
+ partition@40 {
+ /* 11MB for JFFS2 based Root file System */
+ reg = 0x0040 0x00b0;
+ label = NOR JFFS2 Root File System;
+ };
+
+
[PATCH 2/2] powerpc/85xx: Create dts of each core in CAMP mode for P1021RDB-PC
Create the dts files for each core and splits the devices between
the two cores for P1021RDB-PC.
Core0 has l2, serial0, i2c, spi, gpio, tdm,dma, usb, eth0, eth1,
sdhc, crypto, global-util, message, pci0, pci1, msi, crypto.
Core1 has l2, serial1, eth2.
Signed-off-by: Xu Jiucheng jiucheng...@freescale.com
Signed-off-by: Matthew McClintock m...@freescale.com
---
arch/powerpc/boot/dts/p1021rdb-pc_camp_core0.dts | 91 +++
arch/powerpc/boot/dts/p1021rdb-pc_camp_core1.dts | 179 ++
2 files changed, 270 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/p1021rdb-pc_camp_core0.dts
create mode 100644 arch/powerpc/boot/dts/p1021rdb-pc_camp_core1.dts
diff --git a/arch/powerpc/boot/dts/p1021rdb-pc_camp_core0.dts
b/arch/powerpc/boot/dts/p1021rdb-pc_camp_core0.dts
new file mode 100644
index 000..199e94e
--- /dev/null
+++ b/arch/powerpc/boot/dts/p1021rdb-pc_camp_core0.dts
@@ -0,0 +1,91 @@
+/*
+ * P1021 RDB Core0 Device Tree Source in CAMP mode.
+ *
+ * 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.
+ *
+ * In CAMP mode, each core needs to have its own dts. Only mpic and L2 cache
+ * can be shared, all the other devices must be assigned to one core only.
+ * This dts file allows core0 to have memory, l2, serail0, i2c, spi, gpio,
+ * tdm, dma, usb, eth0, eth1, sdhc, crypto, global-util, message, pci0, pci1,
+ * msi.
+ *
+ * Please note to add -b 0 for core0's dts compiling.
+ */
+
+/include/ p1021rdb-pc_32b.dts
+
+/ {
+ model = fsl,P1021RDB;
+ compatible = fsl,P1021RDB-PC;
+
+ aliases {
+ ethernet1 = enet0;
+ ethernet2 = enet1;
+ serial0 = serial0;
+ pci0 = pci0;
+ pci1 = pci1;
+ };
+
+ cpus {
+ PowerPC,P1021@1 {
+ status = disabled;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ };
+
+ soc@ffe0 {
+ serial1: serial@4600 {
+ status = disabled;
+ };
+
+ mdio@24000 {
+ phy1: ethernet-phy@1 {
+ status = disabled;
+ };
+ };
+
+ enet2: ethernet@b2000 {
+ status = disabled;
+ };
+
+ mpic: pic@4 {
+ protected-sources =
+ 42 /* serial1 */
+ 31 32 33/* enet2-queue-group0 */
+ 25 26 27/* enet2-queue-group1 */
+ ;
+ pic-no-reset;
+ };
+ };
+};
diff --git a/arch/powerpc/boot/dts/p1021rdb-pc_camp_core1.dts
b/arch/powerpc/boot/dts/p1021rdb-pc_camp_core1.dts
new file mode 100644
index 000..dfc9105
--- /dev/null
+++ b/arch/powerpc/boot/dts/p1021rdb-pc_camp_core1.dts
@@ -0,0 +1,179 @@
+/*
+ * P1021 RDB Core1 Device Tree Source in CAMP mode.
+ *
+ * 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:
+ * *
Re: [PATCH 1/2] powerpc/watchdog: move booke watchdog param related code to prom.c
On May 8, 2012, at 10:46 PM, Bhushan Bharat-R65777 wrote: .org] On Behalf Of Shaohui Xie Sent: Tuesday, May 08, 2012 11:37 AM To: linux-watch...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org Cc: Xie Shaohui-B21989 Subject: [PATCH 1/2] powerpc/watchdog: move booke watchdog param related code to prom.c Currently, BOOKE watchdog code for checking wdt and wdt_period is in setup_32.c, it cannot be used in 64-bit, so move it to a common place prom.c, which will be shared by 32-bit and 64-bit. Also, replace the simple_strtoul with kstrtol. Signed-off-by: Shaohui Xie shaohui@freescale.com --- arch/powerpc/kernel/prom.c | 27 +++ arch/powerpc/kernel/setup_32.c | 24 2 files changed, 27 insertions(+), 24 deletions(-) Is not setup-common.c is better place to move this? Move out from setup_32.c does not mean it have to go into setup-common.c, I need better reason to do this. What I think that setup_32.c is for 32 bit, setup_64.c is for 64 bit and setup-common.c is for both. I am not saying that you move this to setup-common.c. I am asking why you have not used setup-common.c ? I am ok even with prom.c. [Xie Shaohui] I'm not a fan of prom.c, I did this because I see same kind of early parameters checking is did in this file only, so I thought maybe I should put them together. And seems setup-common.c is not the place to do command line checking (I'm not sure about this). Ok, so you are also not sure. Let us see what other guys things of this. Put it in setup-common.c. prom.c has normally been mostly OF/dts related parsing. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2][v2] powerpc/watchdog: replace CONFIG_FSL_BOOKE with CONFIG_PPC_FSL_BOOK3E
On Jul 10, 2012, at 5:22 AM, Xie Shaohui-B21989 wrote: Hi, All, Is there any concern for this patch, it's been a long time. Thanks! Best Regards, Shaohui Xie As commented, we should use PPC_FSL_BOOK3E, not CONFIG_PPC_FSL_BOOK3E. - k -Original Message- From: Xie Shaohui-B21989 Sent: Friday, May 11, 2012 1:34 PM To: linux-watch...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org Cc: Xie Shaohui-B21989 Subject: [PATCH 2/2][v2] powerpc/watchdog: replace CONFIG_FSL_BOOKE with CONFIG_PPC_FSL_BOOK3E CONFIG_FSL_BOOKE is only defined in 32-bit, CONFIG_PPC_FSL_BOOK3E is defined in both 32-bit and 64-bit, so use CONFIG_PPC_FSL_BOOK3E to make driver work in 32-bit 64-bit. Signed-off-by: Shaohui Xie shaohui@freescale.com --- changes for v2: use PPC_FSL_BOOK3E instead of FSL_SOC_BOOKE. drivers/watchdog/Kconfig |8 drivers/watchdog/booke_wdt.c |4 ++-- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index 3709624..4373ca0 100644 --- a/drivers/watchdog/Kconfig +++ b/drivers/watchdog/Kconfig @@ -1094,10 +1094,10 @@ config BOOKE_WDT config BOOKE_WDT_DEFAULT_TIMEOUT int PowerPC Book-E Watchdog Timer Default Timeout depends on BOOKE_WDT -default 38 if FSL_BOOKE -range 0 63 if FSL_BOOKE -default 3 if !FSL_BOOKE -range 0 3 if !FSL_BOOKE +default 38 if PPC_FSL_BOOK3E +range 0 63 if PPC_FSL_BOOK3E +default 3 if !PPC_FSL_BOOK3E +range 0 3 if !PPC_FSL_BOOK3E help Select the default watchdog timer period to be used by the PowerPC Book-E watchdog driver. A watchdog event occurs when the bit diff --git a/drivers/watchdog/booke_wdt.c b/drivers/watchdog/booke_wdt.c index ce0ab44..338a437 100644 --- a/drivers/watchdog/booke_wdt.c +++ b/drivers/watchdog/booke_wdt.c @@ -37,7 +37,7 @@ u32 booke_wdt_enabled; u32 booke_wdt_period = CONFIG_BOOKE_WDT_DEFAULT_TIMEOUT; -#ifdef CONFIG_FSL_BOOKE +#ifdef CONFIG_PPC_FSL_BOOK3E #define WDTP(x) x)0x3)30)|(((x)0x3c)15)) #define WDTP_MASK(WDTP(0x3f)) #else @@ -190,7 +190,7 @@ static long booke_wdt_ioctl(struct file *file, case WDIOC_SETTIMEOUT: if (get_user(tmp, p)) return -EFAULT; -#ifdef CONFIG_FSL_BOOKE +#ifdef CONFIG_PPC_FSL_BOOK3E /* period of 1 gives the largest possible timeout */ if (tmp period_to_sec(1)) return -EINVAL; -- 1.6.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2][v2] powerpc/watchdog: replace CONFIG_FSL_BOOKE with CONFIG_PPC_FSL_BOOK3E
On Jul 10, 2012, at 6:40 AM, Kumar Gala wrote: On Jul 10, 2012, at 5:22 AM, Xie Shaohui-B21989 wrote: Hi, All, Is there any concern for this patch, it's been a long time. Thanks! Best Regards, Shaohui Xie As commented, we should use PPC_FSL_BOOK3E, not CONFIG_PPC_FSL_BOOK3E. - k Sorry, was looking at the older version of this patch. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc/fsl: Update corenet32_smp_defconfig
On Jul 10, 2012, at 5:40 AM, Shengzhou Liu wrote: * Enable NAND, MSI, PAMU, * Enable FSL RAID on P5020 * Enable general RAID features (MD + async-tx) * Enable RTC on P2041RDB * Enable UIO SRIO UIO DMA Signed-off-by: Harninder Rai harninder@freescale.com Signed-off-by: Shaohui Xie shaohui@freescale.com Signed-off-by: Minghuan Lian minghuan.l...@freescale.com Signed-off-by: Kumar Gala ga...@kernel.crashing.org Signed-off-by: Shengzhou Liu shengzhou@freescale.com --- arch/powerpc/configs/corenet32_smp_defconfig | 22 +- 1 files changed, 21 insertions(+), 1 deletions(-) Is this patch really against upstream? We dont have PAMU, UIO SRIO/DMA upstream. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc/fsl: Update corenet64_smp_defconfig
On Jul 10, 2012, at 5:40 AM, Shengzhou Liu wrote: * Enable USB, MMC, SATA, MTD, NAND, PAMU, RTC * Enable FSL RAID on P5020 * Enable general RAID features (MD + async-tx) * Enable RTC on P2041RDB * Enable UIO SRIO UIO DMA * Enable USDPAA SHMEM driver * Enable ePAPR HV support * Enable PCI-E support Signed-off-by: Haiying Wang haiying.w...@freescale.com Signed-off-by: Laurentiu Tudor laurentiu.tu...@freescale.com Signed-off-by: Harninder Rai harninder@freescale.com Signed-off-by: Minghuan Lian minghuan.l...@freescale.com Signed-off-by: Kumar Gala ga...@kernel.crashing.org Signed-off-by: Shengzhou Liu shengzhou@freescale.com --- arch/powerpc/configs/corenet64_smp_defconfig | 94 -- 1 files changed, 89 insertions(+), 5 deletions(-) Is this patch really against upstream? We dont have PAMU, UIO SRIO/DMA,etc upstream. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3 v2] powerpc/mpic: FSL MPIC error interrupt support.
On Jul 10, 2012, at 4:39 AM, Sethi Varun-B16395 wrote:
-Original Message-
From: Kumar Gala [mailto:ga...@kernel.crashing.org]
Sent: Tuesday, July 10, 2012 7:17 AM
To: Wood Scott-B07421
Cc: Sethi Varun-B16395; Hamciuc Bogdan-BHAMCIU1; linuxppc-
d...@lists.ozlabs.org
Subject: Re: [PATCH 3/3 v2] powerpc/mpic: FSL MPIC error interrupt
support.
On Jul 9, 2012, at 3:22 PM, Scott Wood wrote:
On 07/09/2012 02:03 PM, Kumar Gala wrote:
On Jul 9, 2012, at 3:47 AM, Varun Sethi wrote:
+int mpic_err_int_init(struct mpic *mpic, irq_hw_number_t irqnum) {
Why can't we do this during mpic_init() time?
Are you willing to hardcode that IRQ 16 is the error interrupt,
without waiting to see an intspec?
I'm torn, but the bit of code in mpic_host_xlate that calls
mpic_err_int_init() is just ugly.
We could consider it similar to how we assume IPIs.
[Sethi Varun-B16395] I don't understand this point.
-Varun
Just that we don't parse the .dts to get the IPI interrupts. They are just
assumed as part of being OpenPIC. So, I was suggesting if you set the
MPIC_FSL_HAS_EIMR flag, we just assume the IRQ #, rather than parsing the .dts.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/85xx: Add dts files for P1021RDB-PC board
On Jul 10, 2012, at 3:39 AM, Xu Jiucheng wrote: P1021RDB-PC Overview - 1Gbyte DDR3 (on board DDR) 16Mbyte NOR flash 32Mbyte eSLC NAND Flash 256 Kbit M24256 I2C EEPROM 128 Mbit SPI Flash memory Real-time clock on I2C bus SD/MMC connector to interface with the SD memory card PCIex - x1 PCIe slot or x1 PCIe to dual SATA controller - x1 mini-PCIe slot USB 2.0 - ULPI PHY interface: SMSC USB3300 USB PHY and Genesys Logic’s GL850A - Two USB2.0 Type A receptacles - One USB2.0 signal to Mini PCIe slot eTSEC1: Connected to RGMII PHY VSC7385 eTSEC2: Connected to SGMII PHY VSC8221 eTSEC3: Connected to SGMII PHY AR8021 DUART interface: supports two UARTs up to 115200 bps for console display Signed-off-by: Xu Jiucheng jiucheng...@freescale.com Signed-off-by: Matthew McClintock m...@freescale.com --- arch/powerpc/boot/dts/p1021rdb-pc.dtsi| 236 + arch/powerpc/boot/dts/p1021rdb-pc_32b.dts | 96 arch/powerpc/boot/dts/p1021rdb-pc_36b.dts | 96 arch/powerpc/boot/dts/p1021rdb.dts| 96 arch/powerpc/boot/dts/p1021rdb.dtsi | 236 - arch/powerpc/boot/dts/p1021rdb_36b.dts| 96 6 files changed, 428 insertions(+), 428 deletions(-) create mode 100644 arch/powerpc/boot/dts/p1021rdb-pc.dtsi create mode 100644 arch/powerpc/boot/dts/p1021rdb-pc_32b.dts create mode 100644 arch/powerpc/boot/dts/p1021rdb-pc_36b.dts delete mode 100644 arch/powerpc/boot/dts/p1021rdb.dts delete mode 100644 arch/powerpc/boot/dts/p1021rdb.dtsi delete mode 100644 arch/powerpc/boot/dts/p1021rdb_36b.dts Do we really need a 32 36 bit device tree for this board? Isnt the memory fixed so why not just have 32b? Also, why are you removing the dts for the older P1021RDB?? - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] USB: ehci-fsl: Update ifdef check to work on 64-bit ppc
We need to use CONFIG_FSL_SOC_BOOKE instead of CONFIG_PPC_85xx as
CONFIG_PPC_85xx isn't defined when we build support for 64-bit embedded
FSL PPC SoCs.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
drivers/usb/host/ehci-fsl.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index 4336257..f002525 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -313,7 +313,7 @@ static void ehci_fsl_usb_setup(struct ehci_hcd *ehci)
}
if (pdata-have_sysif_regs) {
-#ifdef CONFIG_PPC_85xx
+#ifdef CONFIG_FSL_SOC_BOOKE
out_be32(non_ehci + FSL_SOC_USB_PRICTRL, 0x0008);
out_be32(non_ehci + FSL_SOC_USB_AGECNTTHRSH, 0x0080);
#else
--
1.7.3.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 1/2] powerpc/e500: make load_up_spe a normal fuction
On Feb 29, 2012, at 7:20 PM, Olivia Yin wrote: From: Liu Yu yu@freescale.com So that we can call it when improving SPE switch like book3e did for fp switch. Signed-off-by: Liu Yu yu@freescale.com Signed-off-by: Olivia Yin hong-hua@freescale.com --- v2: add Signed-off-by arch/powerpc/kernel/head_fsl_booke.S | 23 ++- 1 files changed, 6 insertions(+), 17 deletions(-) applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/3 v2] powerpc/mpic: Use the MPIC_LARGE_VECTORS flag for FSL MPIC.
On Jul 9, 2012, at 3:46 AM, Varun Sethi wrote: We should use the MPIC_LARG_VECTORS flag while intializing the MPIC. This prevents us from eating in to hardware vector number space (MSIs) while setting up internal sources. Signed-off-by: Varun Sethi varun.se...@freescale.com --- arch/powerpc/sysdev/mpic.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2][v2] powerpc/watchdog: replace CONFIG_FSL_BOOKE with CONFIG_PPC_FSL_BOOK3E
On May 11, 2012, at 12:33 AM, Shaohui Xie wrote: CONFIG_FSL_BOOKE is only defined in 32-bit, CONFIG_PPC_FSL_BOOK3E is defined in both 32-bit and 64-bit, so use CONFIG_PPC_FSL_BOOK3E to make driver work in 32-bit 64-bit. Signed-off-by: Shaohui Xie shaohui@freescale.com --- changes for v2: use PPC_FSL_BOOK3E instead of FSL_SOC_BOOKE. drivers/watchdog/Kconfig |8 drivers/watchdog/booke_wdt.c |4 ++-- 2 files changed, 6 insertions(+), 6 deletions(-) applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc/mpc8572ds: Fix eTSEC is not available on core1 of AMP boot issue
On Jul 10, 2012, at 1:08 AM, Jia Hongtao wrote:
The issue log on core1 is:
root@mpc8572ds:~# ifconfig eth0 10.192.208.244
net eth0: could not attach to PHY
SIOCSIFFLAGS: No such device
To attach PHY node mdio@24520 should not be disabled in dts of core1.
Because all PHYs are controlled through this node as follows:
mdio@24520 {
phy0: ethernet-phy@0 {
interrupts = 10 1 0 0;
reg = 0x0;
};
phy1: ethernet-phy@1 {
interrupts = 10 1 0 0;
reg = 0x1;
};
phy2: ethernet-phy@2 {
interrupts = 10 1 0 0;
reg = 0x2;
};
phy3: ethernet-phy@3 {
interrupts = 10 1 0 0;
reg = 0x3;
};
tbi0: tbi-phy@11 {
reg = 0x11;
device_type = tbi-phy;
};
};
Signed-off-by: Li Yang le...@freescale.com
Signed-off-by: Jia Hongtao b38...@freescale.com
---
arch/powerpc/boot/dts/mpc8572ds_camp_core1.dts |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
applied to next
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc/mpc8572ds: Update the MSI interrupts into 4-cell format
On Jul 10, 2012, at 1:08 AM, Jia Hongtao wrote: With 2-cell format interrupts of MSI PCIe ethernet card can not work. Signed-off-by: Li Yang le...@freescale.com Signed-off-by: Jia Hongtao b38...@freescale.com --- arch/powerpc/boot/dts/mpc8572ds_camp_core0.dts |8 arch/powerpc/boot/dts/mpc8572ds_camp_core1.dts |8 2 files changed, 8 insertions(+), 8 deletions(-) applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] P1021: set IReady in QE Microcode Upload
On Nov 11, 2011, at 10:05 AM, Kokoris, Ioannis wrote: Hi, QE Microcode Initialization using qe_upload_microcode() does not work on P1021 if the IRAM-Ready register is not set after the microcode upload. This patch adds a definition for the I-RAM Ready register and sets it uppon microcode upload completion. Signed-off-by: Ioannis Kokkoris ioannis.koko...@siemens-enterprise.com applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc/85xx: Create dts of each core in CAMP mode for P1021RDB-PC
On Tue, Jul 10, 2012 at 3:39 AM, Xu Jiucheng jiucheng...@freescale.com wrote: Create the dts files for each core and splits the devices between the two cores for P1021RDB-PC. Core0 has l2, serial0, i2c, spi, gpio, tdm,dma, usb, eth0, eth1, sdhc, crypto, global-util, message, pci0, pci1, msi, crypto. Core1 has l2, serial1, eth2. Signed-off-by: Xu Jiucheng jiucheng...@freescale.com Signed-off-by: Matthew McClintock m...@freescale.com --- Do we really want AMP device trees upstream? They're very application-specific, and AMP support has always been a hack. If anything, I think we should be deleting AMP device trees from upstream, not adding more. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/dts: Add ucc uart support for p1025rdb
On Jul 10, 2012, at 2:52 AM, Zhicheng wrote: From: Zhicheng Fan b32...@freescale.com Signed-off-by: Zhicheng Fan b32...@freescale.com --- arch/powerpc/boot/dts/fsl/p1021si-post.dtsi | 16 ++- arch/powerpc/boot/dts/p1025rdb.dtsi | 40 +++ 2 files changed, 55 insertions(+), 1 deletions(-) applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: select PPC_CLOCK unconditionally for FSL_SOC
On Mar 30, 2012, at 12:38 AM, Shawn Guo wrote: Freescale PowerPC SoCs share a number of IP blocks with Freescale ARM/IMX SoCs, FlexCAN, SSI, FEC, eSDHC, USB, etc. There are some effort consolidating those drivers to make them work for both architectures. One outstanding difference between two architectures is ARM/IMX will turn off module clocks during platform initialization for power saving and expects drivers manage clocks using clk API, while PowerPC mostly does not do that, and thus does not always build in clk API. Listing all those driver Kconfig options in select PPC_CLOCK if seems not scalable for long term maintenance, and could easily introduce Kconfig recursive dependency. This patch chooses to select PPC_CLOCK unconditionally for FSL_SOC to always build clk API for PowerPC in. Signed-off-by: Shawn Guo shawn@linaro.org --- arch/powerpc/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] PCI: Add pcie_irq=other to enable non MSI/INTx interrupt for port service driver
On 07/10/2012 01:13 AM, Liu Shengzhou-B36685 wrote: -Original Message- From: Wood Scott-B07421 Sent: Tuesday, July 10, 2012 12:39 AM To: Liu Shengzhou-B36685 Cc: bhelg...@google.com; linux-...@vger.kernel.org; linuxppc- d...@lists.ozlabs.org Subject: Re: [PATCH] PCI: Add pcie_irq=other to enable non MSI/INTx interrupt for port service driver On 07/09/2012 05:49 AM, Shengzhou Liu wrote: On some platforms, in RC mode, root port has neither MSI/MSI-X nor INTx interrupt generated, which are available only in EP mode on those platform. In this case, we try to use other interrupt if supported (i.e. there is the shared error interrupt on platform P1010, P3041, P4080, etc) to have AER, Hot-plug, etc, services to work. Signed-off-by: Shengzhou Liu shengzhou@freescale.com --- Documentation/kernel-parameters.txt |4 drivers/pci/pcie/portdrv_core.c | 19 +++ 2 files changed, 23 insertions(+), 0 deletions(-) diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index a92c5eb..af97c81 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -2218,6 +2218,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted. nomsi Do not use MSI for native PCIe PME signaling (this makes all PCIe root ports use INTx for all services). + pcie_irq= [PCIE] Native PCIe root port interrupt options: + other Try to use other interrupt when root port has + neither MSI/MSI-X nor INTx support. Why does the user need to specify this? Shouldn't this be a matter of communication between kernel internals? The other interrupt appears a non-standard interrupt way compared to MSI/MSI-X and INTx in point of PCIe spec. It still shouldn't be the user's responsibility to pass this in. The intent of specifying this is to have an intervention and confirmation manually to avoid causing unexpected issue on some unknown platforms. I'm glad to remove the specified kernel parameter if it would be accepted upstream. Hopefully someone will comment if there is harm in doing this unconditionally. If there is, then we should handle this via a quirk or similar mechanism. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] PCI: Add pcie_irq=other to enable non MSI/INTx interrupt for port service driver
On Jul 10, 2012, at 10:31 AM, Scott Wood wrote: On 07/10/2012 01:13 AM, Liu Shengzhou-B36685 wrote: -Original Message- From: Wood Scott-B07421 Sent: Tuesday, July 10, 2012 12:39 AM To: Liu Shengzhou-B36685 Cc: bhelg...@google.com; linux-...@vger.kernel.org; linuxppc- d...@lists.ozlabs.org Subject: Re: [PATCH] PCI: Add pcie_irq=other to enable non MSI/INTx interrupt for port service driver On 07/09/2012 05:49 AM, Shengzhou Liu wrote: On some platforms, in RC mode, root port has neither MSI/MSI-X nor INTx interrupt generated, which are available only in EP mode on those platform. In this case, we try to use other interrupt if supported (i.e. there is the shared error interrupt on platform P1010, P3041, P4080, etc) to have AER, Hot-plug, etc, services to work. Signed-off-by: Shengzhou Liu shengzhou@freescale.com --- Documentation/kernel-parameters.txt |4 drivers/pci/pcie/portdrv_core.c | 19 +++ 2 files changed, 23 insertions(+), 0 deletions(-) diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index a92c5eb..af97c81 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -2218,6 +2218,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted. nomsi Do not use MSI for native PCIe PME signaling (this makes all PCIe root ports use INTx for all services). + pcie_irq= [PCIE] Native PCIe root port interrupt options: + other Try to use other interrupt when root port has + neither MSI/MSI-X nor INTx support. Why does the user need to specify this? Shouldn't this be a matter of communication between kernel internals? The other interrupt appears a non-standard interrupt way compared to MSI/MSI-X and INTx in point of PCIe spec. It still shouldn't be the user's responsibility to pass this in. I agree with Scott, this should be done in board code or as a PCI fixup, not as a command line arg. The intent of specifying this is to have an intervention and confirmation manually to avoid causing unexpected issue on some unknown platforms. I'm glad to remove the specified kernel parameter if it would be accepted upstream. Hopefully someone will comment if there is harm in doing this unconditionally. If there is, then we should handle this via a quirk or similar mechanism. -Scott If we need to do it via quirk, wondering if we can use the pci_dev_flags and set the flag in a quirk. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc/85xx: Create dts of each core in CAMP mode for P1021RDB-PC
On 07/10/2012 03:39 AM, Xu Jiucheng wrote:
+ crypto@3 {
+status = disabled;
+};
Whitespace.
+
+ mpic: pic@4 {
+ protected-sources =
+ 16 /* ecm, mem, L2, pci0, pci1 */
+ 43 42 59/* i2c, serial0, spi */
+ 47 63 62/* gpio, tdm */
+ 20 21 22 23 /* dma */
+ 03 02 /* mdio */
+ 29 30 34/* enet0-queue-group0 */
+ 17 18 24/* enet0-queue-group1 */
+ 35 36 40/* enet1-queue-group0 */
+ 51 52 67/* enet1-queue-group1 */
+ 28 72 45 58 /* usb, sdhci, crypto */
+ 0xb0 0xb1 0xb2 /* message */
+ 0xb3 0xb4 0xb5
+ 0xb6 0xb7
+ 0xe0 0xe1 0xe2 /* msi */
+ 0xe3 0xe4 0xe5
+ 0xe6 0xe7 /* sdhci, crypto , pci */
+ ;
+ pic-no-reset;
+ };
Besides what Timur said, do we really need protected-sources now that we
have pic-no-reset?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v3 0/13] memory-hotplug : hot-remove physical memory
On 07/10/2012 05:58 PM, Yasuaki Ishimatsu wrote: Hi Christoph, 2012/07/10 0:18, Christoph Lameter wrote: On Mon, 9 Jul 2012, Yasuaki Ishimatsu wrote: Even if you apply these patches, you cannot remove the physical memory completely since these patches are still under development. I want you to cooperate to improve the physical memory hot-remove. So please review these patches and give your comment/idea. Could you at least give a method on how you want to do physical memory removal? We plan to release a dynamic hardware partitionable system. It will be able to hot remove/add a system board which included memory and cpu. But as you know, Linux does not support memory hot-remove on x86 box. So I try to develop it. Current plan to hot remove system board is to use container driver. Thus I define the system board in ACPI DSDT table as a container device. It have supported hot-add a container device. And if container device has _EJ0 ACPI method, eject file to remove the container device is prepared as follow: # ls -l /sys/bus/acpi/devices/ACPI0004\:01/eject --w---. 1 root root 4096 Jul 10 18:19 /sys/bus/acpi/devices/ACPI0004:01/eject When I hot-remove the container device, I echo 1 to the file as follow: #echo 1 /sys/bus/acpi/devices/ACPI0004\:02/eject Then acpi_bus_trim() is called. And it calls acpi_memory_device_remove() for removing memory device. But the code does not do nothing. So I developed the continuation of the function. You would have to remove all objects from the range you want to physically remove. That is only possible under special circumstances and with a limited set of objects. Even if you exclusively use ZONE_MOVEABLE you still may get cases where pages are pinned for a long time. I know it. So my memory hot-remove plan is as follows: 1. hot-added a system board All memory which included the system board is offline. 2. online the memory as removable page The function has not supported yet. It is being developed by Lai as follow: http://lkml.indiana.edu/hypermail/linux/kernel/1207.0/01478.html If it is supported, I will be able to create movable memory. 3. hot-remove the memory by container device's eject file We have implemented a prototype to do physical node (mem + CPU + IOH) hotplug for Itanium and is now porting it to x86. But with currently solution, memory hotplug functionality may cause 10-20% performance decrease because we concentrate all DMA/Normal memory to the first NUMA node, and all other NUMA nodes only hosts ZONE_MOVABLE. We are working on solution to minimize the performance drop now. Thanks, Yasuaki Ishimatsu I am not sure that these patches are useful unless we know where you are going with this. If we end up with a situation where we still cannot remove physical memory then this patchset is not helpful. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc/mpc8572ds: Fix eTSEC is not available on core1 of AMP boot issue
On 07/10/2012 01:08 AM, Jia Hongtao wrote: The issue log on core1 is: root@mpc8572ds:~# ifconfig eth0 10.192.208.244 net eth0: could not attach to PHY SIOCSIFFLAGS: No such device To attach PHY node mdio@24520 should not be disabled in dts of core1. Because all PHYs are controlled through this node as follows: So you grant it to both partitions? How do you deal with synchronization? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] powerpc/mpc85xx_ds: convert to unified PCI init
On Jun 27, 2012, at 6:50 PM, Scott Wood wrote: Similar to how the primary PCI bridge is identified by looking for an isa subnode, we determine whether to apply uli exclusions by looking for a uli subnode. Signed-off-by: Scott Wood scottw...@freescale.com --- Besides being an example of a real-hardware board to use the new PCI init (probably one of the more complicated examples due to the uli device exclusion), this fixes PCI under QEMU's mpc8544ds machine. QEMU was only creating one PCI bus, and it wasn't the one Linux had arbitrarily deemed primary for mpc8544ds (AFAIK, there's no legacy ISA on this board). Tested with QEMU mpc8544ds, and real-hardware mpc8572ds (with uli). arch/powerpc/platforms/85xx/mpc85xx_ds.c | 97 +- 1 files changed, 29 insertions(+), 68 deletions(-) Can you rebase against my 'next' branch.. having issues applying this. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [git pull] Please pull powerpc.git merge branch
--- On Mon, 7/2/12, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: From: Benjamin Herrenschmidt b...@kernel.crashing.org Subject: Re: [git pull] Please pull powerpc.git merge branch To: Gerhard Pircher gerhard_pirc...@gmx.net Cc: linuxppc-dev list linuxppc-...@ozlabs.org Date: Monday, July 2, 2012, 3:20 PM On Mon, 2012-07-02 at 23:38 +0200, Gerhard Pircher wrote: What about this fix:? http://patchwork.ozlabs.org/patch/166346/ At least I can't see it in the log... The module fix went in. The ftrace patch, well, it's untested and we don't even know if we have a problem with mcount yet, so no, I haven't merged it yet. Cheers, Ben. I have had a chance to test this patch. Before it is applied I get the following message when loading a module: Not a trampoline [ cut here ] WARNING: at /src/git/linux-powerpc/kernel/trace/ftrace.c:1583 Modules linked in: gpio_w1_transport(O+) NIP: c008129c LR: c0082138 CTR: c021d744 REGS: c532dd80 TRAP: 0700 Tainted: G O (3.4.3-2-g23fc8c3) MSR: 00029032 EE,ME,IR,DR,RI CR: 22082282 XER: 2000 TASK = c5256900[363] 'insmod' THREAD: c532c000 GPR00: 0001 c532de30 c5256900 ffea c907b008 c046befc 20747261 GPR08: c046be40 c045c862 8000 22082224 10019fdc 100f GPR16: 100f5678 100dc70c eac3ec00 c0011bb0 c046890c GPR24: c907b008 c70d8f80 c0443d0c c5338000 000c c907b008 c049a910 NIP [c008129c] ftrace_bug+0xc0/0x25c LR [c0082138] ftrace_process_locs+0x47c/0x608 Call Trace: [c532de30] [c008fe04] ftrace_now+0x38/0x78 (unreliable) [c532de50] [c0082138] ftrace_process_locs+0x47c/0x608 [c532dea0] [c008232c] ftrace_module_notify+0x68/0x7c [c532deb0] [c004cd80] notifier_call_chain+0x90/0xe0 [c532dee0] [c004d27c] __blocking_notifier_call_chain+0x68/0x94 [c532df10] [c004d2cc] blocking_notifier_call_chain+0x24/0x34 [c532df20] [c0073b38] sys_init_module+0xa0/0x1e0 [c532df40] [c0011254] ret_from_syscall+0x0/0x38 --- Exception: c01 at 0xff5d694 LR = 0x1cd4 Instruction dump: 90090008 48294b71 3c60c03c 7fc4f378 7fc5f378 3863874c 48294b5d 48000188 3d20c046 3929c862 88090003 6801 0f00 2f80 409e0148 3d20c001 ---[ end trace aaa9b56024f9d2b9 ]--- ftrace failed to modify [c907b008] gpio_w1_reset_bus+0x8/0xc0 [gpio_w1_transport] actual: 48:00:04:99 and the trace file dump results in: # tracer: nop # # WARNING: FUNCTION TRACING IS CORRUPTED # MAY BE MISSING FUNCTION EVENTS # entries-in-buffer/entries-written: 0/0 #P:1 # # _-= irqs-off # / _= need-resched #| / _---= hardirq/softirq #|| / _--= preempt-depth #||| / delay # TASK-PID CPU# TIMESTAMP FUNCTION # | | | | | after the patch is applied I get no messages on module loading and ftrace no longer complains, and I can trace my module's functions. So I can add Tested-By: Roger Blofeld blofel...@yahoo.com -rb ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Semantics of lv1_pause()
Hi Ben,
On Tue, 2012-07-10 at 13:20 +1000, Benjamin Herrenschmidt wrote:
regarding the precise semantics of lv1_pause() ?
Here's what's in PS3's setup.c:
static void ps3_power_save(void)
{
/*
* lv1_pause() puts the PPE thread into inactive state until an
* irq on an unmasked plug exists. MSR[EE] has no effect.
* flags: 0 = wake on DEC interrupt, 1 = ignore DEC interrupt.
*/
lv1_pause(0);
}
Just FYI, setup.c is here:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=arch/powerpc/platforms/ps3/setup.c;hb=HEAD#l72
I'm fixing various issues with our idle loops, among other things,
because we are soft-disabled when we hit ppc_md.powersave() but not
hard-disabled, there could be an interrupt marked as pending and not
taken yet.
Will that work properly ? I have this understanding that it might
not ... but heh.
The (virtual) HW thread that called lv1_pause() should become active
when any virq that had irq_chip.irq_unmask() called for it occurs.
I'm not sure what 'become active' means if that virq is setup to be
handled by the 'paused' HW thread. I guess the behavior depends on
if MSR_EE was set?
Also if I call lv1_pause() with MSR_EE off, will it work ? Will it
return with MSR_EE on like H_CEDE does on pseries ?
As above, the value of MSR_EE has no effect on activating the HW
thread, and I assume MSR_EE will still be off when lv1_pause() returns.
We can try some experiments if needed.
-Geoff
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/4] fsl-dma: support attribute of DMA_MEMORY when async_tx enabled
On Mon, Jul 9, 2012 at 10:59 PM, Qiang Liu qiang@freescale.com wrote: - delete attribute of DMA_INTERRUPT because fsl-dma doesn't support this function, exception will be thrown if talitos is used to compute xor at the same time; - change the release process of dma descriptor for avoiding exception when enable config NET_DMA, release dma descriptor from 1st to last second, the last descriptor which is reserved in current descriptor register may not be completed, race condition will be raised if free current descriptor; - use spin_lock_bh to instead of spin_lock_irqsave for improving performance; A race condition which is raised when use both of talitos and dmaengine to offload xor is because napi scheduler will sync all pending requests in dma channels, it will affect the process of raid operations. The descriptor is freed which is submitted just now, but async_tx must check whether this depend tx descriptor is acked, there are poison contents in the invalid address, then BUG_ON() is thrown, so this descriptor will be freed in the next time. Cc: Dan Williams dan.j.willi...@intel.com Cc: Vinod Koul vinod.k...@intel.com Cc: Li Yang le...@freescale.com Signed-off-by: Qiang Liu qiang@freescale.com --- From the description this sounds like 3 or 4 patches. Can you split it up? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [linuxppc-release] [PATCH 4/4] Talitos: fix the issue of dma memory leak
Qiang Liu wrote: An error will be happened when test with mass data: Please don't use the phrase fix the issue in patch summaries. It's redundant. This patch should be titled, drivers/crypto: fix memory leak in Talitos driver diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c index 81f8497..a7da48c 100644 --- a/drivers/crypto/talitos.c +++ b/drivers/crypto/talitos.c @@ -264,7 +264,7 @@ static void flush_channel(struct device *dev, int ch, int error, int reset_ch) else status = error; - dma_unmap_single(dev, request-dma_desc, + dma_unmap_single(priv-dev, request-dma_desc, You have an indentation problem here. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4] PPC: use CURRENT_THREAD_INFO instead of open coded assembly
On 05.07.2012, at 16:41, Stuart Yoder wrote: From: Stuart Yoder stuart.yo...@freescale.com Signed-off-by: Stuart Yoder stuart.yo...@freescale.com Ben, ping? Alex --- -v4: fixed build issues in exception-64s.h and exceptions-64s.S arch/powerpc/include/asm/exception-64s.h |4 ++-- arch/powerpc/include/asm/thread_info.h |6 ++ arch/powerpc/kernel/entry_32.S | 24 arch/powerpc/kernel/entry_64.S | 14 +++--- arch/powerpc/kernel/exceptions-64e.S |2 +- arch/powerpc/kernel/exceptions-64s.S |2 +- arch/powerpc/kernel/head_fsl_booke.S |2 +- arch/powerpc/kernel/idle_6xx.S |4 ++-- arch/powerpc/kernel/idle_book3e.S|2 +- arch/powerpc/kernel/idle_e500.S |4 ++-- arch/powerpc/kernel/idle_power4.S|2 +- arch/powerpc/kernel/misc_32.S|4 ++-- arch/powerpc/kvm/bookehv_interrupts.S|6 +- arch/powerpc/mm/hash_low_32.S|8 arch/powerpc/sysdev/6xx-suspend.S|2 +- 15 files changed, 44 insertions(+), 42 deletions(-) diff --git a/arch/powerpc/include/asm/exception-64s.h b/arch/powerpc/include/asm/exception-64s.h index d58fc4e..a43c147 100644 --- a/arch/powerpc/include/asm/exception-64s.h +++ b/arch/powerpc/include/asm/exception-64s.h @@ -293,7 +293,7 @@ label##_hv: \ #define RUNLATCH_ON \ BEGIN_FTR_SECTION \ - clrrdi r3,r1,THREAD_SHIFT; \ + CURRENT_THREAD_INFO(r3, r1);\ ld r4,TI_LOCAL_FLAGS(r3); \ andi. r0,r4,_TLF_RUNLATCH;\ beqlppc64_runlatch_on_trampoline; \ @@ -332,7 +332,7 @@ label##_common: \ #ifdef CONFIG_PPC_970_NAP #define FINISH_NAP\ BEGIN_FTR_SECTION \ - clrrdi r11,r1,THREAD_SHIFT;\ + CURRENT_THREAD_INFO(r11, r1); \ ld r9,TI_LOCAL_FLAGS(r11); \ andi. r10,r9,_TLF_NAPPING;\ bnelpower4_fixup_nap; \ diff --git a/arch/powerpc/include/asm/thread_info.h b/arch/powerpc/include/asm/thread_info.h index 68831e9..faf9352 100644 --- a/arch/powerpc/include/asm/thread_info.h +++ b/arch/powerpc/include/asm/thread_info.h @@ -22,6 +22,12 @@ #define THREAD_SIZE (1 THREAD_SHIFT) +#ifdef CONFIG_PPC64 +#define CURRENT_THREAD_INFO(dest, sp)clrrdi dest, sp, THREAD_SHIFT +#else +#define CURRENT_THREAD_INFO(dest, sp)rlwinm dest, sp, 0, 0, 31-THREAD_SHIFT +#endif + #ifndef __ASSEMBLY__ #include linux/cache.h #include asm/processor.h diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S index ba3aeb4..bad42e3 100644 --- a/arch/powerpc/kernel/entry_32.S +++ b/arch/powerpc/kernel/entry_32.S @@ -92,7 +92,7 @@ crit_transfer_to_handler: mfspr r8,SPRN_SPRG_THREAD lwz r0,KSP_LIMIT(r8) stw r0,SAVED_KSP_LIMIT(r11) - rlwimi r0,r1,0,0,(31-THREAD_SHIFT) + CURRENT_THREAD_INFO(r0, r1) stw r0,KSP_LIMIT(r8) /* fall through */ #endif @@ -112,7 +112,7 @@ crit_transfer_to_handler: mfspr r8,SPRN_SPRG_THREAD lwz r0,KSP_LIMIT(r8) stw r0,saved_ksp_limit@l(0) - rlwimi r0,r1,0,0,(31-THREAD_SHIFT) + CURRENT_THREAD_INFO(r0, r1) stw r0,KSP_LIMIT(r8) /* fall through */ #endif @@ -158,7 +158,7 @@ transfer_to_handler: tophys(r11,r11) addir11,r11,global_dbcr0@l #ifdef CONFIG_SMP - rlwinm r9,r1,0,0,(31-THREAD_SHIFT) + CURRENT_THREAD_INFO(r9, r1) lwz r9,TI_CPU(r9) slwir9,r9,3 add r11,r11,r9 @@ -179,7 +179,7 @@ transfer_to_handler: ble-stack_ovf /* then the kernel stack overflowed */ 5: #if defined(CONFIG_6xx) || defined(CONFIG_E500) - rlwinm r9,r1,0,0,31-THREAD_SHIFT + CURRENT_THREAD_INFO(r9, r1) tophys(r9,r9) /* check local flags */ lwz r12,TI_LOCAL_FLAGS(r9) mtcrf 0x01,r12 @@ -333,7 +333,7 @@ _GLOBAL(DoSyscall) mtmsr r11 1: #endif /* CONFIG_TRACE_IRQFLAGS */ - rlwinm r10,r1,0,0,(31-THREAD_SHIFT)/* current_thread_info() */ + CURRENT_THREAD_INFO(r10, r1) lwz r11,TI_FLAGS(r10) andi. r11,r11,_TIF_SYSCALL_T_OR_A bne-syscall_dotrace @@ -354,7 +354,7 @@ ret_from_syscall: bl do_show_syscall_exit #endif mr r6,r3 - rlwinm r12,r1,0,0,(31-THREAD_SHIFT)/* current_thread_info() */ + CURRENT_THREAD_INFO(r12, r1) /* disable interrupts so current_thread_info()-flags can't change */ LOAD_MSR_KERNEL(r10,MSR_KERNEL) /* doesn't include MSR_EE */ /* Note: We don't bother telling lockdep about
Re: [RFC PATCH v3 0/13] memory-hotplug : hot-remove physical memory
Hi Jiang, 2012/07/11 1:50, Jiang Liu wrote: On 07/10/2012 05:58 PM, Yasuaki Ishimatsu wrote: Hi Christoph, 2012/07/10 0:18, Christoph Lameter wrote: On Mon, 9 Jul 2012, Yasuaki Ishimatsu wrote: Even if you apply these patches, you cannot remove the physical memory completely since these patches are still under development. I want you to cooperate to improve the physical memory hot-remove. So please review these patches and give your comment/idea. Could you at least give a method on how you want to do physical memory removal? We plan to release a dynamic hardware partitionable system. It will be able to hot remove/add a system board which included memory and cpu. But as you know, Linux does not support memory hot-remove on x86 box. So I try to develop it. Current plan to hot remove system board is to use container driver. Thus I define the system board in ACPI DSDT table as a container device. It have supported hot-add a container device. And if container device has _EJ0 ACPI method, eject file to remove the container device is prepared as follow: # ls -l /sys/bus/acpi/devices/ACPI0004\:01/eject --w---. 1 root root 4096 Jul 10 18:19 /sys/bus/acpi/devices/ACPI0004:01/eject When I hot-remove the container device, I echo 1 to the file as follow: #echo 1 /sys/bus/acpi/devices/ACPI0004\:02/eject Then acpi_bus_trim() is called. And it calls acpi_memory_device_remove() for removing memory device. But the code does not do nothing. So I developed the continuation of the function. You would have to remove all objects from the range you want to physically remove. That is only possible under special circumstances and with a limited set of objects. Even if you exclusively use ZONE_MOVEABLE you still may get cases where pages are pinned for a long time. I know it. So my memory hot-remove plan is as follows: 1. hot-added a system board All memory which included the system board is offline. 2. online the memory as removable page The function has not supported yet. It is being developed by Lai as follow: http://lkml.indiana.edu/hypermail/linux/kernel/1207.0/01478.html If it is supported, I will be able to create movable memory. 3. hot-remove the memory by container device's eject file We have implemented a prototype to do physical node (mem + CPU + IOH) hotplug for Itanium and is now porting it to x86. But with currently solution, memory hotplug functionality may cause 10-20% performance decrease because we concentrate all DMA/Normal memory to the first NUMA node, and all other NUMA nodes only hosts ZONE_MOVABLE. We are working on solution to minimize the performance drop now. Thank you for your interesting response. I have a question. How do you move all other NUMA nodes to ZONE_MOVABLE? To use ZONE_MOVABLE, we need to use boot options like kernelcore or movablecore. But it is not enough, since the requested amount is spread evenly throughout all nodes in the system. So I think we do not have way to move all other NUMA node to ZONE_MOVABLE. Thanks, Yasuaki Ishimatsu Thanks, Yasuaki Ishimatsu I am not sure that these patches are useful unless we know where you are going with this. If we end up with a situation where we still cannot remove physical memory then this patchset is not helpful. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/4] Talitos: move the data structure into header file
On Tue, 10 Jul 2012 13:56:46 +0800 Qiang Liu qiang@freescale.com wrote: Move the declaration of talitos data structure into talitos.h. Cc: Herbert Xu herb...@gondor.apana.org.au Cc: David S. Miller da...@davemloft.net Signed-off-by: Qiang Liu qiang@freescale.com --- this patch has already been submitted [1]. Subsequent patches in this series also don't apply cleanly: can you rebase onto [2], which is based on Herbert's cryptodev tree and contain's Horia's four patches, and re-send? Also note that upstream talitos does not yet contain NAPI support [3]. Thanks, Kim [1] http://www.mail-archive.com/linux-crypto@vger.kernel.org/msg07299.html [2] git://git.freescale.com/crypto/cryptodev.git [3] http://www.mail-archive.com/linux-crypto@vger.kernel.org/msg07289.html ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v3 0/13] memory-hotplug : hot-remove physical memory
On 07/11/2012 08:09 AM, Yasuaki Ishimatsu wrote: Hi Jiang, 2012/07/11 1:50, Jiang Liu wrote: On 07/10/2012 05:58 PM, Yasuaki Ishimatsu wrote: Hi Christoph, 2012/07/10 0:18, Christoph Lameter wrote: On Mon, 9 Jul 2012, Yasuaki Ishimatsu wrote: Even if you apply these patches, you cannot remove the physical memory completely since these patches are still under development. I want you to cooperate to improve the physical memory hot-remove. So please review these patches and give your comment/idea. Could you at least give a method on how you want to do physical memory removal? We plan to release a dynamic hardware partitionable system. It will be able to hot remove/add a system board which included memory and cpu. But as you know, Linux does not support memory hot-remove on x86 box. So I try to develop it. Current plan to hot remove system board is to use container driver. Thus I define the system board in ACPI DSDT table as a container device. It have supported hot-add a container device. And if container device has _EJ0 ACPI method, eject file to remove the container device is prepared as follow: # ls -l /sys/bus/acpi/devices/ACPI0004\:01/eject --w---. 1 root root 4096 Jul 10 18:19 /sys/bus/acpi/devices/ACPI0004:01/eject When I hot-remove the container device, I echo 1 to the file as follow: #echo 1 /sys/bus/acpi/devices/ACPI0004\:02/eject Then acpi_bus_trim() is called. And it calls acpi_memory_device_remove() for removing memory device. But the code does not do nothing. So I developed the continuation of the function. You would have to remove all objects from the range you want to physically remove. That is only possible under special circumstances and with a limited set of objects. Even if you exclusively use ZONE_MOVEABLE you still may get cases where pages are pinned for a long time. I know it. So my memory hot-remove plan is as follows: 1. hot-added a system board All memory which included the system board is offline. 2. online the memory as removable page The function has not supported yet. It is being developed by Lai as follow: http://lkml.indiana.edu/hypermail/linux/kernel/1207.0/01478.html If it is supported, I will be able to create movable memory. 3. hot-remove the memory by container device's eject file We have implemented a prototype to do physical node (mem + CPU + IOH) hotplug for Itanium and is now porting it to x86. But with currently solution, memory hotplug functionality may cause 10-20% performance decrease because we concentrate all DMA/Normal memory to the first NUMA node, and all other NUMA nodes only hosts ZONE_MOVABLE. We are working on solution to minimize the performance drop now. Thank you for your interesting response. I have a question. How do you move all other NUMA nodes to ZONE_MOVABLE? To use ZONE_MOVABLE, we need to use boot options like kernelcore or movablecore. But it is not enough, since the requested amount is spread evenly throughout all nodes in the system. So I think we do not have way to move all other NUMA node to ZONE_MOVABLE. We have modified the ZONE_MOVABLE spreading and bootmem allocation. If the kernelcore or movablecore kernel parameters are present, we follow current behavior. If those parameter are absent and the platform supports physical hotplug, we will concentrate DMA/NORMAL memory to specific nodes. Thanks, Yasuaki Ishimatsu Thanks, Yasuaki Ishimatsu I am not sure that these patches are useful unless we know where you are going with this. If we end up with a situation where we still cannot remove physical memory then this patchset is not helpful. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt platform
The QEMU stuff is related to the PCI refactoring because currently we have a hard time selecting a primary bus under QEMU, and also because the generic qemu e500 platform wants a full list of FSL PCI compatibles to check. Patchset rebased on Kumar's next branch. Scott Wood (3): powerpc/fsl-pci: get PCI init out of board files powerpc/e500: add paravirt QEMU platform powerpc/mpc85xx_ds: convert to unified PCI init arch/powerpc/platforms/85xx/Kconfig | 16 + arch/powerpc/platforms/85xx/Makefile |1 + arch/powerpc/platforms/85xx/mpc85xx_ds.c | 97 +- arch/powerpc/platforms/85xx/qemu_e500.c | 72 ++ arch/powerpc/platforms/Kconfig.cputype |4 + arch/powerpc/sysdev/fsl_pci.c| 71 +- arch/powerpc/sysdev/fsl_pci.h|8 +++ 7 files changed, 200 insertions(+), 69 deletions(-) create mode 100644 arch/powerpc/platforms/85xx/qemu_e500.c -- 1.7.5.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 2/3] powerpc/e500: add paravirt QEMU platform
This gives the kernel a paravirtualized machine to target, without
requiring both sides to pretend to be targeting a specific board
that likely has little to do with the host in KVM scenarios. This
avoids the need to add new boards to QEMU just to be able to
run KVM on new CPUs.
As this is the first platform that can run with either e500v2 or
e500mc, CONFIG_PPC_E500MC is now a legitimately user configurable
option, so add a help text.
Signed-off-by: Scott Wood scottw...@freescale.com
---
v2: Added a comment about the flexible nature of this platform, and
rebased on Kumar's next
arch/powerpc/platforms/85xx/Kconfig | 16 +++
arch/powerpc/platforms/85xx/Makefile|1 +
arch/powerpc/platforms/85xx/qemu_e500.c | 72 +++
arch/powerpc/platforms/Kconfig.cputype |4 ++
4 files changed, 93 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/platforms/85xx/qemu_e500.c
diff --git a/arch/powerpc/platforms/85xx/Kconfig
b/arch/powerpc/platforms/85xx/Kconfig
index dddb3e5..159c01e 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -254,6 +254,22 @@ config P5020_DS
help
This option enables support for the P5020 DS board
+config PPC_QEMU_E500
+ bool QEMU generic e500 platform
+ depends on EXPERIMENTAL
+ select DEFAULT_UIMAGE
+ help
+ This option enables support for running as a QEMU guest using
+ QEMU's generic e500 machine. This is not required if you're
+ using a QEMU machine that targets a specific board, such as
+ mpc8544ds.
+
+ Unlike most e500 boards that target a specific CPU, this
+ platform works with any e500-family CPU that QEMU supports.
+ Thus, you'll need to make sure CONFIG_PPC_E500MC is set or
+ unset based on the emulated CPU (or actual host CPU in the case
+ of KVM).
+
endif # FSL_SOC_BOOKE
config TQM85xx
diff --git a/arch/powerpc/platforms/85xx/Makefile
b/arch/powerpc/platforms/85xx/Makefile
index 30652e0..3dfe811 100644
--- a/arch/powerpc/platforms/85xx/Makefile
+++ b/arch/powerpc/platforms/85xx/Makefile
@@ -27,3 +27,4 @@ obj-$(CONFIG_SOCRATES)+= socrates.o socrates_fpga_pic.o
obj-$(CONFIG_KSI8560)+= ksi8560.o
obj-$(CONFIG_XES_MPC85xx) += xes_mpc85xx.o
obj-$(CONFIG_GE_IMP3A) += ge_imp3a.o
+obj-$(CONFIG_PPC_QEMU_E500) += qemu_e500.o
diff --git a/arch/powerpc/platforms/85xx/qemu_e500.c
b/arch/powerpc/platforms/85xx/qemu_e500.c
new file mode 100644
index 000..95a2e53
--- /dev/null
+++ b/arch/powerpc/platforms/85xx/qemu_e500.c
@@ -0,0 +1,72 @@
+/*
+ * Paravirt target for a generic QEMU e500 machine
+ *
+ * This is intended to be a flexible device-tree-driven platform, not fixed
+ * to a particular piece of hardware or a particular spec of virtual hardware,
+ * beyond the assumption of an e500-family CPU. Some things are still
hardcoded
+ * here, such as MPIC, but this is a limitation of the current code rather than
+ * an interface contract with QEMU.
+ *
+ * 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 linux/kernel.h
+#include linux/of_fdt.h
+#include asm/machdep.h
+#include asm/time.h
+#include asm/udbg.h
+#include asm/mpic.h
+#include sysdev/fsl_soc.h
+#include sysdev/fsl_pci.h
+#include smp.h
+#include mpc85xx.h
+
+void __init qemu_e500_pic_init(void)
+{
+ struct mpic *mpic;
+
+ mpic = mpic_alloc(NULL, 0, MPIC_BIG_ENDIAN | MPIC_SINGLE_DEST_CPU,
+ 0, 256, OpenPIC );
+
+ BUG_ON(mpic == NULL);
+ mpic_init(mpic);
+}
+
+static void __init qemu_e500_setup_arch(void)
+{
+ ppc_md.progress(qemu_e500_setup_arch(), 0);
+
+ fsl_pci_init();
+ mpc85xx_smp_init();
+}
+
+/*
+ * Called very early, device-tree isn't unflattened
+ */
+static int __init qemu_e500_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+
+ return !!of_flat_dt_is_compatible(root, fsl,qemu-e500);
+}
+
+machine_device_initcall(qemu_e500, mpc85xx_common_publish_devices);
+
+define_machine(qemu_e500) {
+ .name = QEMU e500,
+ .probe = qemu_e500_probe,
+ .setup_arch = qemu_e500_setup_arch,
+ .init_IRQ = qemu_e500_pic_init,
+#ifdef CONFIG_PCI
+ .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
+#endif
+ .get_irq= mpic_get_irq,
+ .restart= fsl_rstcr_restart,
+ .calibrate_decr = generic_calibrate_decr,
+ .progress = udbg_progress,
+};
diff --git a/arch/powerpc/platforms/Kconfig.cputype
b/arch/powerpc/platforms/Kconfig.cputype
index 61c9550..30fd01d 100644
---
[PATCH v2 1/3] powerpc/fsl-pci: get PCI init out of board files
As an alternative incremental starting point to Jia Hongtao's patchset,
get the FSL PCI init out of the board files, but do not yet convert to a
platform driver.
Rather than having each board supply a magic register offset for
determining the primary bus, we look for which PCI host bridge
contains an ISA node within its subtree. If there is no ISA node,
normally that would mean there is no primary bus, but until certain
bugs are fixed we arbitrarily designate a primary in this case.
Conversion to a platform driver and related improvements can happen
after this, as the ordering issues are sorted out.
Signed-off-by: Scott Wood scottw...@freescale.com
---
v2: rebased on Kumar's next
arch/powerpc/sysdev/fsl_pci.c | 71 -
arch/powerpc/sysdev/fsl_pci.h |8 +
2 files changed, 78 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index edbf794..a7b2a60 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -1,7 +1,7 @@
/*
* MPC83xx/85xx/86xx PCI/PCIE support routing.
*
- * Copyright 2007-2011 Freescale Semiconductor, Inc.
+ * Copyright 2007-2012 Freescale Semiconductor, Inc.
* Copyright 2008-2009 MontaVista Software, Inc.
*
* Initial author: Xianghua Xiao x.x...@freescale.com
@@ -807,3 +807,72 @@ u64 fsl_pci_immrbar_base(struct pci_controller *hose)
return 0;
}
+
+#if defined(CONFIG_FSL_SOC_BOOKE) || defined(CONFIG_PPC_86xx)
+static const struct of_device_id pci_ids[] = {
+ { .compatible = fsl,mpc8540-pci, },
+ { .compatible = fsl,mpc8548-pcie, },
+ { .compatible = fsl,mpc8610-pci, },
+ { .compatible = fsl,mpc8641-pcie, },
+ { .compatible = fsl,p1022-pcie, },
+ { .compatible = fsl,p1010-pcie, },
+ { .compatible = fsl,p1023-pcie, },
+ { .compatible = fsl,p4080-pcie, },
+ { .compatible = fsl,qoriq-pcie-v2.3, },
+ { .compatible = fsl,qoriq-pcie-v2.2, },
+ {},
+};
+
+struct device_node *fsl_pci_primary;
+
+void __devinit fsl_pci_init(void)
+{
+ struct device_node *node;
+ struct pci_controller *hose;
+ dma_addr_t max = 0x;
+
+ /* Callers can specify the primary bus using other means. */
+ if (!fsl_pci_primary) {
+ /* If a PCI host bridge contains an ISA node, it's primary. */
+ node = of_find_node_by_type(NULL, isa);
+ while ((fsl_pci_primary = of_get_parent(node))) {
+ of_node_put(node);
+ node = fsl_pci_primary;
+
+ if (of_match_node(pci_ids, node))
+ break;
+ }
+ }
+
+ node = NULL;
+ for_each_node_by_type(node, pci) {
+ if (of_match_node(pci_ids, node)) {
+ /*
+* If there's no PCI host bridge with ISA, arbitrarily
+* designate one as primary. This can go away once
+* various bugs with primary-less systems are fixed.
+*/
+ if (!fsl_pci_primary)
+ fsl_pci_primary = node;
+
+ fsl_add_bridge(node, fsl_pci_primary == node);
+ hose = pci_find_hose_for_OF_device(node);
+ max = min(max, hose-dma_window_base_cur +
+ hose-dma_window_size);
+ }
+ }
+
+#ifdef CONFIG_SWIOTLB
+ /*
+* if we couldn't map all of DRAM via the dma windows
+* we need SWIOTLB to handle buffers located outside of
+* dma capable memory region
+*/
+ if (memblock_end_of_DRAM() - 1 max) {
+ ppc_swiotlb_enable = 1;
+ set_pci_dma_ops(swiotlb_dma_ops);
+ ppc_md.pci_dma_dev_setup = pci_dma_dev_setup_swiotlb;
+ }
+#endif
+}
+#endif
diff --git a/arch/powerpc/sysdev/fsl_pci.h b/arch/powerpc/sysdev/fsl_pci.h
index a39ed5c..baa0fd1 100644
--- a/arch/powerpc/sysdev/fsl_pci.h
+++ b/arch/powerpc/sysdev/fsl_pci.h
@@ -93,5 +93,13 @@ extern void fsl_pcibios_fixup_bus(struct pci_bus *bus);
extern int mpc83xx_add_bridge(struct device_node *dev);
u64 fsl_pci_immrbar_base(struct pci_controller *hose);
+extern struct device_node *fsl_pci_primary;
+
+#ifdef CONFIG_FSL_PCI
+void fsl_pci_init(void);
+#else
+static inline void fsl_pci_init(void) {}
+#endif
+
#endif /* __POWERPC_FSL_PCI_H */
#endif /* __KERNEL__ */
--
1.7.5.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 3/3] powerpc/mpc85xx_ds: convert to unified PCI init
Similar to how the primary PCI bridge is identified by looking
for an isa subnode, we determine whether to apply uli exclusions
by looking for a uli subnode.
Signed-off-by: Scott Wood scottw...@freescale.com
---
v2: Rebased on Kumar's next
arch/powerpc/platforms/85xx/mpc85xx_ds.c | 97 +-
1 files changed, 29 insertions(+), 68 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
index d30f6c4..6d3265f 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
@@ -114,71 +114,53 @@ void __init mpc85xx_ds_pic_init(void)
}
#ifdef CONFIG_PCI
-static int primary_phb_addr;
extern int uli_exclude_device(struct pci_controller *hose,
u_char bus, u_char devfn);
+static struct device_node *pci_with_uli;
+
static int mpc85xx_exclude_device(struct pci_controller *hose,
u_char bus, u_char devfn)
{
- struct device_node* node;
- struct resource rsrc;
-
- node = hose-dn;
- of_address_to_resource(node, 0, rsrc);
-
- if ((rsrc.start 0xf) == primary_phb_addr) {
+ if (hose-dn == pci_with_uli)
return uli_exclude_device(hose, bus, devfn);
- }
return PCIBIOS_SUCCESSFUL;
}
#endif /* CONFIG_PCI */
-/*
- * Setup the architecture
- */
-static void __init mpc85xx_ds_setup_arch(void)
+static void __init mpc85xx_ds_pci_init(void)
{
#ifdef CONFIG_PCI
- struct device_node *np;
- struct pci_controller *hose;
-#endif
- dma_addr_t max = 0x;
+ struct device_node *node;
- if (ppc_md.progress)
- ppc_md.progress(mpc85xx_ds_setup_arch(), 0);
+ fsl_pci_init();
-#ifdef CONFIG_PCI
- for_each_node_by_type(np, pci) {
- if (of_device_is_compatible(np, fsl,mpc8540-pci) ||
- of_device_is_compatible(np, fsl,mpc8548-pcie) ||
- of_device_is_compatible(np, fsl,p2020-pcie)) {
- struct resource rsrc;
- of_address_to_resource(np, 0, rsrc);
- if ((rsrc.start 0xf) == primary_phb_addr)
- fsl_add_bridge(np, 1);
- else
- fsl_add_bridge(np, 0);
-
- hose = pci_find_hose_for_OF_device(np);
- max = min(max, hose-dma_window_base_cur +
- hose-dma_window_size);
+ /* See if we have a ULI under the primary */
+
+ node = of_find_node_by_name(NULL, uli1575);
+ while ((pci_with_uli = of_get_parent(node))) {
+ of_node_put(node);
+ node = pci_with_uli;
+
+ if (pci_with_uli == fsl_pci_primary) {
+ ppc_md.pci_exclude_device = mpc85xx_exclude_device;
+ break;
}
}
-
- ppc_md.pci_exclude_device = mpc85xx_exclude_device;
#endif
+}
- mpc85xx_smp_init();
+/*
+ * Setup the architecture
+ */
+static void __init mpc85xx_ds_setup_arch(void)
+{
+ if (ppc_md.progress)
+ ppc_md.progress(mpc85xx_ds_setup_arch(), 0);
-#ifdef CONFIG_SWIOTLB
- if ((memblock_end_of_DRAM() - 1) max) {
- ppc_swiotlb_enable = 1;
- set_pci_dma_ops(swiotlb_dma_ops);
- ppc_md.pci_dma_dev_setup = pci_dma_dev_setup_swiotlb;
- }
-#endif
+ mpc85xx_ds_pci_init();
+ mpc85xx_smp_init();
printk(MPC85xx DS board from Freescale Semiconductor\n);
}
@@ -190,14 +172,7 @@ static int __init mpc8544_ds_probe(void)
{
unsigned long root = of_get_flat_dt_root();
- if (of_flat_dt_is_compatible(root, MPC8544DS)) {
-#ifdef CONFIG_PCI
- primary_phb_addr = 0xb000;
-#endif
- return 1;
- }
-
- return 0;
+ return !!of_flat_dt_is_compatible(root, MPC8544DS);
}
machine_device_initcall(mpc8544_ds, mpc85xx_common_publish_devices);
@@ -215,14 +190,7 @@ static int __init mpc8572_ds_probe(void)
{
unsigned long root = of_get_flat_dt_root();
- if (of_flat_dt_is_compatible(root, fsl,MPC8572DS)) {
-#ifdef CONFIG_PCI
- primary_phb_addr = 0x8000;
-#endif
- return 1;
- }
-
- return 0;
+ return !!of_flat_dt_is_compatible(root, fsl,MPC8572DS);
}
/*
@@ -232,14 +200,7 @@ static int __init p2020_ds_probe(void)
{
unsigned long root = of_get_flat_dt_root();
- if (of_flat_dt_is_compatible(root, fsl,P2020DS)) {
-#ifdef CONFIG_PCI
- primary_phb_addr = 0x9000;
-#endif
- return 1;
- }
-
- return 0;
+ return !!of_flat_dt_is_compatible(root, fsl,P2020DS);
}
define_machine(mpc8544_ds) {
--
1.7.5.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
[PATCH] powerpc/booke: Eliminate rfi from exception entry path.
Unlike classic, we don't really need the MSR change to be atomic with the branch. This eliminates a trap as a KVM guest (in the absence of hardware hypervisor extensions), where mtmsr is paravirtualized but rfi is not. For a virtualized guest without any paravirtualization, this eliminates an additional two traps (SRR0/1). Signed-off-by: Scott Wood scottw...@freescale.com --- arch/powerpc/kernel/entry_32.S | 16 1 files changed, 16 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S index ba3aeb4..6bb637c 100644 --- a/arch/powerpc/kernel/entry_32.S +++ b/arch/powerpc/kernel/entry_32.S @@ -193,6 +193,9 @@ transfer_to_handler_cont: lwz r11,0(r9) /* virtual address of handler */ lwz r9,4(r9)/* where to go when done */ #ifdef CONFIG_TRACE_IRQFLAGS +#ifdef CONFIG_BOOKE + mtmsr r10 +#else lis r12,reenable_mmu@h ori r12,r12,reenable_mmu@l mtspr SPRN_SRR0,r12 @@ -201,6 +204,7 @@ transfer_to_handler_cont: RFI reenable_mmu: /* re-enable mmu so we can */ mfmsr r10 +#endif /* !CONFIG_BOOKE */ lwz r12,_MSR(r1) xor r10,r10,r12 andi. r10,r10,MSR_EE /* Did EE change? */ @@ -247,11 +251,23 @@ reenable_mmu: /* re-enable mmu so we can */ mtlrr9 bctr/* jump to handler */ #else /* CONFIG_TRACE_IRQFLAGS */ +#ifdef CONFIG_BOOKE + /* +* We're not changing address space on Book E, and the extra rfi +* can hurt when virtualized without hardware support -- whereas +* mtmsr can be paravirtualized. +*/ + mtmsr r10 + mtctr r11 + mtlrr9 + bctr +#else mtspr SPRN_SRR0,r11 mtspr SPRN_SRR1,r10 mtlrr9 SYNC RFI /* jump to handler, enable MMU */ +#endif /* !CONFIG_BOOKE */ #endif /* CONFIG_TRACE_IRQFLAGS */ #if defined (CONFIG_6xx) || defined(CONFIG_E500) -- 1.7.5.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/booke: Eliminate rfi from exception entry path.
On Tue, 2012-07-10 at 19:34 -0500, Scott Wood wrote: Unlike classic, we don't really need the MSR change to be atomic with the branch. This eliminates a trap as a KVM guest (in the absence of hardware hypervisor extensions), where mtmsr is paravirtualized but rfi is not. For a virtualized guest without any paravirtualization, this eliminates an additional two traps (SRR0/1). In fact, I wonder, what do we write into the MSR at this point that wasn't already in it in BookE ? RI ? I wonder if we could get away without the mtmsr alltogether... Cheers, Ben. Signed-off-by: Scott Wood scottw...@freescale.com --- arch/powerpc/kernel/entry_32.S | 16 1 files changed, 16 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S index ba3aeb4..6bb637c 100644 --- a/arch/powerpc/kernel/entry_32.S +++ b/arch/powerpc/kernel/entry_32.S @@ -193,6 +193,9 @@ transfer_to_handler_cont: lwz r11,0(r9) /* virtual address of handler */ lwz r9,4(r9)/* where to go when done */ #ifdef CONFIG_TRACE_IRQFLAGS +#ifdef CONFIG_BOOKE + mtmsr r10 +#else lis r12,reenable_mmu@h ori r12,r12,reenable_mmu@l mtspr SPRN_SRR0,r12 @@ -201,6 +204,7 @@ transfer_to_handler_cont: RFI reenable_mmu:/* re-enable mmu so we can */ mfmsr r10 +#endif /* !CONFIG_BOOKE */ lwz r12,_MSR(r1) xor r10,r10,r12 andi. r10,r10,MSR_EE /* Did EE change? */ @@ -247,11 +251,23 @@ reenable_mmu: /* re-enable mmu so we can */ mtlrr9 bctr/* jump to handler */ #else /* CONFIG_TRACE_IRQFLAGS */ +#ifdef CONFIG_BOOKE + /* + * We're not changing address space on Book E, and the extra rfi + * can hurt when virtualized without hardware support -- whereas + * mtmsr can be paravirtualized. + */ + mtmsr r10 + mtctr r11 + mtlrr9 + bctr +#else mtspr SPRN_SRR0,r11 mtspr SPRN_SRR1,r10 mtlrr9 SYNC RFI /* jump to handler, enable MMU */ +#endif /* !CONFIG_BOOKE */ #endif /* CONFIG_TRACE_IRQFLAGS */ #if defined (CONFIG_6xx) || defined(CONFIG_E500) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/booke: Eliminate rfi from exception entry path.
On 07/10/2012 07:36 PM, Benjamin Herrenschmidt wrote: On Tue, 2012-07-10 at 19:34 -0500, Scott Wood wrote: Unlike classic, we don't really need the MSR change to be atomic with the branch. This eliminates a trap as a KVM guest (in the absence of hardware hypervisor extensions), where mtmsr is paravirtualized but rfi is not. For a virtualized guest without any paravirtualization, this eliminates an additional two traps (SRR0/1). In fact, I wonder, what do we write into the MSR at this point that wasn't already in it in BookE ? RI ? I wonder if we could get away without the mtmsr alltogether... Doesn't EE get set there for some exceptions? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/booke: Eliminate rfi from exception entry path.
On 11.07.2012, at 02:34, Scott Wood wrote: Unlike classic, we don't really need the MSR change to be atomic with the branch. This eliminates a trap as a KVM guest (in the absence of hardware hypervisor extensions), where mtmsr is paravirtualized but rfi is not. For a virtualized guest without any paravirtualization, this eliminates an additional two traps (SRR0/1). Signed-off-by: Scott Wood scottw...@freescale.com --- arch/powerpc/kernel/entry_32.S | 16 1 files changed, 16 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S index ba3aeb4..6bb637c 100644 --- a/arch/powerpc/kernel/entry_32.S +++ b/arch/powerpc/kernel/entry_32.S @@ -193,6 +193,9 @@ transfer_to_handler_cont: lwz r11,0(r9) /* virtual address of handler */ lwz r9,4(r9)/* where to go when done */ #ifdef CONFIG_TRACE_IRQFLAGS +#ifdef CONFIG_BOOKE + mtmsr r10 +#else lis r12,reenable_mmu@h ori r12,r12,reenable_mmu@l mtspr SPRN_SRR0,r12 @@ -201,6 +204,7 @@ transfer_to_handler_cont: RFI reenable_mmu: /* re-enable mmu so we can */ mfmsr r10 +#endif /* !CONFIG_BOOKE */ lwz r12,_MSR(r1) xor r10,r10,r12 andi. r10,r10,MSR_EE /* Did EE change? */ @@ -247,11 +251,23 @@ reenable_mmu: /* re-enable mmu so we can */ mtlrr9 bctr/* jump to handler */ #else /* CONFIG_TRACE_IRQFLAGS */ +#ifdef CONFIG_BOOKE + /* + * We're not changing address space on Book E, and the extra rfi + * can hurt when virtualized without hardware support -- whereas + * mtmsr can be paravirtualized. We can always paravirtualize RFI as well if it makes sense. Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/booke: Eliminate rfi from exception entry path.
On 07/10/2012 07:44 PM, Alexander Graf wrote: On 11.07.2012, at 02:34, Scott Wood wrote: +#ifdef CONFIG_BOOKE +/* + * We're not changing address space on Book E, and the extra rfi + * can hurt when virtualized without hardware support -- whereas + * mtmsr can be paravirtualized. We can always paravirtualize RFI as well if it makes sense. I'm not sure that's possible. We thought about it a while back, but IIRC the difficulty was not leaving a register clobbered. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/booke: Eliminate rfi from exception entry path.
On Tue, 2012-07-10 at 19:41 -0500, Scott Wood wrote: On 07/10/2012 07:36 PM, Benjamin Herrenschmidt wrote: On Tue, 2012-07-10 at 19:34 -0500, Scott Wood wrote: Unlike classic, we don't really need the MSR change to be atomic with the branch. This eliminates a trap as a KVM guest (in the absence of hardware hypervisor extensions), where mtmsr is paravirtualized but rfi is not. For a virtualized guest without any paravirtualization, this eliminates an additional two traps (SRR0/1). In fact, I wonder, what do we write into the MSR at this point that wasn't already in it in BookE ? RI ? I wonder if we could get away without the mtmsr alltogether... Doesn't EE get set there for some exceptions? It does, tho arguably it shouldn't in most cases :-) I'm happy to turn a bunch of these into explicit local_irq_enable() in the C code though which will turn into a wrteei which is more efficient on BookE. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/booke: Eliminate rfi from exception entry path.
On Tue, 2012-07-10 at 19:47 -0500, Scott Wood wrote: On 07/10/2012 07:44 PM, Alexander Graf wrote: On 11.07.2012, at 02:34, Scott Wood wrote: +#ifdef CONFIG_BOOKE + /* + * We're not changing address space on Book E, and the extra rfi + * can hurt when virtualized without hardware support -- whereas + * mtmsr can be paravirtualized. We can always paravirtualize RFI as well if it makes sense. I'm not sure that's possible. We thought about it a while back, but IIRC the difficulty was not leaving a register clobbered. Besides mtmsr is slow on real HW as well. Also paravirt as done today for complex instructions like mtmsr is racy :-) (I already had a chat about that with Alex a while back, we might want to re-consider what kind of fix can be done at some point). Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v3 0/13] memory-hotplug : hot-remove physical memory
Hi Jiang, 2012/07/11 9:21, Jiang Liu wrote: On 07/11/2012 08:09 AM, Yasuaki Ishimatsu wrote: Hi Jiang, 2012/07/11 1:50, Jiang Liu wrote: On 07/10/2012 05:58 PM, Yasuaki Ishimatsu wrote: Hi Christoph, 2012/07/10 0:18, Christoph Lameter wrote: On Mon, 9 Jul 2012, Yasuaki Ishimatsu wrote: Even if you apply these patches, you cannot remove the physical memory completely since these patches are still under development. I want you to cooperate to improve the physical memory hot-remove. So please review these patches and give your comment/idea. Could you at least give a method on how you want to do physical memory removal? We plan to release a dynamic hardware partitionable system. It will be able to hot remove/add a system board which included memory and cpu. But as you know, Linux does not support memory hot-remove on x86 box. So I try to develop it. Current plan to hot remove system board is to use container driver. Thus I define the system board in ACPI DSDT table as a container device. It have supported hot-add a container device. And if container device has _EJ0 ACPI method, eject file to remove the container device is prepared as follow: # ls -l /sys/bus/acpi/devices/ACPI0004\:01/eject --w---. 1 root root 4096 Jul 10 18:19 /sys/bus/acpi/devices/ACPI0004:01/eject When I hot-remove the container device, I echo 1 to the file as follow: #echo 1 /sys/bus/acpi/devices/ACPI0004\:02/eject Then acpi_bus_trim() is called. And it calls acpi_memory_device_remove() for removing memory device. But the code does not do nothing. So I developed the continuation of the function. You would have to remove all objects from the range you want to physically remove. That is only possible under special circumstances and with a limited set of objects. Even if you exclusively use ZONE_MOVEABLE you still may get cases where pages are pinned for a long time. I know it. So my memory hot-remove plan is as follows: 1. hot-added a system board All memory which included the system board is offline. 2. online the memory as removable page The function has not supported yet. It is being developed by Lai as follow: http://lkml.indiana.edu/hypermail/linux/kernel/1207.0/01478.html If it is supported, I will be able to create movable memory. 3. hot-remove the memory by container device's eject file We have implemented a prototype to do physical node (mem + CPU + IOH) hotplug for Itanium and is now porting it to x86. But with currently solution, memory hotplug functionality may cause 10-20% performance decrease because we concentrate all DMA/Normal memory to the first NUMA node, and all other NUMA nodes only hosts ZONE_MOVABLE. We are working on solution to minimize the performance drop now. Thank you for your interesting response. I have a question. How do you move all other NUMA nodes to ZONE_MOVABLE? To use ZONE_MOVABLE, we need to use boot options like kernelcore or movablecore. But it is not enough, since the requested amount is spread evenly throughout all nodes in the system. So I think we do not have way to move all other NUMA node to ZONE_MOVABLE. We have modified the ZONE_MOVABLE spreading and bootmem allocation. If the kernelcore or movablecore kernel parameters are present, we follow current behavior. If those parameter are absent and the platform supports physical hotplug, we will concentrate DMA/NORMAL memory to specific nodes. That's interesting. I want to know more details, if you do not mind. Current kernel doesn't do the behavior, does it? So I think you have some patches for changing the behavior. Will you merge these patches into community kernel? Thanks, Yasuaki Ishimatsu Thanks, Yasuaki Ishimatsu Thanks, Yasuaki Ishimatsu I am not sure that these patches are useful unless we know where you are going with this. If we end up with a situation where we still cannot remove physical memory then this patchset is not helpful. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v3 0/13] memory-hotplug : hot-remove physical memory
At 07/09/2012 06:21 PM, Yasuaki Ishimatsu Wrote:
This patch series aims to support physical memory hot-remove.
[RFC PATCH v3 1/13] memory-hotplug : rename remove_memory to offline_memory
[RFC PATCH v3 2/13] memory-hotplug : add physical memory hotplug code to
acpi_memory_device_remove
[RFC PATCH v3 3/13] memory-hotplug : unify argument of
firmware_map_add_early/hotplug
[RFC PATCH v3 4/13] memory-hotplug : remove /sys/firmware/memmap/X sysfs
[RFC PATCH v3 5/13] memory-hotplug : does not release memory region in
PAGES_PER_SECTION chunks
[RFC PATCH v3 6/13] memory-hotplug : add memory_block_release
[RFC PATCH v3 7/13] memory-hotplug : remove_memory calls __remove_pages
[RFC PATCH v3 8/13] memory-hotplug : check page type in get_page_bootmem
[RFC PATCH v3 9/13] memory-hotplug : move register_page_bootmem_info_node
and put_page_bootmem for
sparse-vmemmap
[RFC PATCH v3 10/13] memory-hotplug : implement
register_page_bootmem_info_section of sparse-vmemmap
[RFC PATCH v3 11/13] memory-hotplug : free memmap of sparse-vmemmap
[RFC PATCH v3 12/13] memory-hotplug : add node_device_release
[RFC PATCH v3 13/13] memory-hotplug : remove sysfs file of node
Even if you apply these patches, you cannot remove the physical memory
completely since these patches are still under development. I want you to
cooperate to improve the physical memory hot-remove. So please review these
patches and give your comment/idea.
The patches can free/remove following things:
- acpi_memory_info : [RFC PATCH 2/13]
- /sys/firmware/memmap/X/{end, start, type} : [RFC PATCH 4/13]
- iomem_resource: [RFC PATCH 5/13]
- mem_section and related sysfs files : [RFC PATCH 6-11/13]
- node and related sysfs files : [RFC PATCH 12-13/13]
The patches cannot do following things yet:
- page table of removed memory
If you find lack of function for physical memory hot-remove, please let me
know.
change log of v3:
* rebase to 3.5.0-rc6
[RFC PATCH v2 2/13]
* remove extra kobject_put()
* The patch was commented by Wen. Wen's comment is
acpi_memory_device_remove() should ignore a return value of
remove_memory() since caller does not care the return value.
But I did not change it since I think caller should care the
return value. And I am trying to fix it as follow:
https://lkml.org/lkml/2012/7/5/624
acpi_memory_device_remove() will be called not only when we write
1 to /sys/bus/acpi/devices/PNP0C80:XX/eject. When we unbind it
from the driver or remove the module acpi_memhotplug, this function
will be called too.
I will check whether your patch can work for these two cases.
Thanks
Wen Congyang
[RFC PATCH v2 4/13]
* remove a firmware_memmap_entry allocated by kzmalloc()
change log of v2:
[RFC PATCH v2 2/13]
* check whether memory block is offline or not before calling
offline_memory()
* check whether section is valid or not in is_memblk_offline()
* call kobject_put() for each memory_block in is_memblk_offline()
[RFC PATCH v2 3/13]
* unify the end argument of firmware_map_add_early/hotplug
[RFC PATCH v2 4/13]
* add release_firmware_map_entry() for freeing firmware_map_entry
[RFC PATCH v2 6/13]
* add release_memory_block() for freeing memory_block
[RFC PATCH v2 11/13]
* fix wrong arguments of free_pages()
---
arch/powerpc/platforms/pseries/hotplug-memory.c | 16 +-
arch/x86/mm/init_64.c | 144
drivers/acpi/acpi_memhotplug.c | 28
drivers/base/memory.c | 54 -
drivers/base/node.c |7 +
drivers/firmware/memmap.c | 78 -
include/linux/firmware-map.h|6 +
include/linux/memory.h |5
include/linux/memory_hotplug.h | 17 --
include/linux/mm.h |5
mm/memory_hotplug.c | 98
mm/sparse.c |5
12 files changed, 414 insertions(+), 49 deletions(-)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 1/2] powerpc/mpc8572ds: Fix eTSEC is not available on core1 of AMP boot issue
-Original Message- From: Wood Scott-B07421 Sent: Wednesday, July 11, 2012 2:15 AM To: Jia Hongtao-B38951 Cc: linuxppc-dev@lists.ozlabs.org; ga...@kernel.crashing.org Subject: Re: [PATCH 1/2] powerpc/mpc8572ds: Fix eTSEC is not available on core1 of AMP boot issue On 07/10/2012 01:08 AM, Jia Hongtao wrote: The issue log on core1 is: root@mpc8572ds:~# ifconfig eth0 10.192.208.244 net eth0: could not attach to PHY SIOCSIFFLAGS: No such device To attach PHY node mdio@24520 should not be disabled in dts of core1. Because all PHYs are controlled through this node as follows: So you grant it to both partitions? How do you deal with synchronization? -Scott PHY nodes are only used by ethernet. Each ethernet is used by only one partition (disabled in the other partition). So I think there is no synchronization issue. Thanks. -Jia Hongtao. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 3/4] fsl-dma: support attribute of DMA_MEMORY when async_tx enabled
-Original Message- From: Dan Williams [mailto:dan.j.willi...@intel.com] Sent: Wednesday, July 11, 2012 3:39 AM To: Liu Qiang-B32616 Cc: linux-cry...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; Li Yang- R58472; Phillips Kim-R1AAHA; Vinod Koul Subject: Re: [PATCH 3/4] fsl-dma: support attribute of DMA_MEMORY when async_tx enabled On Mon, Jul 9, 2012 at 10:59 PM, Qiang Liu qiang@freescale.com wrote: - delete attribute of DMA_INTERRUPT because fsl-dma doesn't support this function, exception will be thrown if talitos is used to compute xor at the same time; - change the release process of dma descriptor for avoiding exception when enable config NET_DMA, release dma descriptor from 1st to last second, the last descriptor which is reserved in current descriptor register may not be completed, race condition will be raised if free current descriptor; - use spin_lock_bh to instead of spin_lock_irqsave for improving performance; A race condition which is raised when use both of talitos and dmaengine to offload xor is because napi scheduler will sync all pending requests in dma channels, it will affect the process of raid operations. The descriptor is freed which is submitted just now, but async_tx must check whether this depend tx descriptor is acked, there are poison contents in the invalid address, then BUG_ON() is thrown, so this descriptor will be freed in the next time. Cc: Dan Williams dan.j.willi...@intel.com Cc: Vinod Koul vinod.k...@intel.com Cc: Li Yang le...@freescale.com Signed-off-by: Qiang Liu qiang@freescale.com --- From the description this sounds like 3 or 4 patches. Can you split it up? I will split this patch according to my description and resend again. Thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [linuxppc-release] [PATCH 4/4] Talitos: fix the issue of dma memory leak
-Original Message- From: Tabi Timur-B04825 Sent: Wednesday, July 11, 2012 5:26 AM To: Liu Qiang-B32616 Cc: linux-cry...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; Herbert Xu; Li Yang-R58472; David S. Miller Subject: Re: [linuxppc-release] [PATCH 4/4] Talitos: fix the issue of dma memory leak Qiang Liu wrote: An error will be happened when test with mass data: Please don't use the phrase fix the issue in patch summaries. It's redundant. This patch should be titled, drivers/crypto: fix memory leak in Talitos driver diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c index 81f8497..a7da48c 100644 --- a/drivers/crypto/talitos.c +++ b/drivers/crypto/talitos.c @@ -264,7 +264,7 @@ static void flush_channel(struct device *dev, int ch, int error, int reset_ch) else status = error; - dma_unmap_single(dev, request-dma_desc, +dma_unmap_single(priv-dev, request-dma_desc, You have an indentation problem here. My fault, I will correct it and resend again. Thanks. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v3 0/13] memory-hotplug : hot-remove physical memory
At 07/11/2012 09:52 AM, Wen Congyang Wrote:
At 07/09/2012 06:21 PM, Yasuaki Ishimatsu Wrote:
This patch series aims to support physical memory hot-remove.
[RFC PATCH v3 1/13] memory-hotplug : rename remove_memory to offline_memory
[RFC PATCH v3 2/13] memory-hotplug : add physical memory hotplug code to
acpi_memory_device_remove
[RFC PATCH v3 3/13] memory-hotplug : unify argument of
firmware_map_add_early/hotplug
[RFC PATCH v3 4/13] memory-hotplug : remove /sys/firmware/memmap/X sysfs
[RFC PATCH v3 5/13] memory-hotplug : does not release memory region in
PAGES_PER_SECTION chunks
[RFC PATCH v3 6/13] memory-hotplug : add memory_block_release
[RFC PATCH v3 7/13] memory-hotplug : remove_memory calls __remove_pages
[RFC PATCH v3 8/13] memory-hotplug : check page type in get_page_bootmem
[RFC PATCH v3 9/13] memory-hotplug : move register_page_bootmem_info_node
and put_page_bootmem for
sparse-vmemmap
[RFC PATCH v3 10/13] memory-hotplug : implement
register_page_bootmem_info_section of sparse-vmemmap
[RFC PATCH v3 11/13] memory-hotplug : free memmap of sparse-vmemmap
[RFC PATCH v3 12/13] memory-hotplug : add node_device_release
[RFC PATCH v3 13/13] memory-hotplug : remove sysfs file of node
Even if you apply these patches, you cannot remove the physical memory
completely since these patches are still under development. I want you to
cooperate to improve the physical memory hot-remove. So please review these
patches and give your comment/idea.
The patches can free/remove following things:
- acpi_memory_info : [RFC PATCH 2/13]
- /sys/firmware/memmap/X/{end, start, type} : [RFC PATCH 4/13]
- iomem_resource: [RFC PATCH 5/13]
- mem_section and related sysfs files : [RFC PATCH 6-11/13]
- node and related sysfs files : [RFC PATCH 12-13/13]
The patches cannot do following things yet:
- page table of removed memory
If you find lack of function for physical memory hot-remove, please let me
know.
change log of v3:
* rebase to 3.5.0-rc6
[RFC PATCH v2 2/13]
* remove extra kobject_put()
* The patch was commented by Wen. Wen's comment is
acpi_memory_device_remove() should ignore a return value of
remove_memory() since caller does not care the return value.
But I did not change it since I think caller should care the
return value. And I am trying to fix it as follow:
https://lkml.org/lkml/2012/7/5/624
acpi_memory_device_remove() will be called not only when we write
1 to /sys/bus/acpi/devices/PNP0C80:XX/eject. When we unbind it
from the driver or remove the module acpi_memhotplug, this function
will be called too.
I will check whether your patch can work for these two cases.
I have checked it, and I think your patch can not work for these 2 cases.
When we unbind the device from the driver(write device name to
/sys/bus/acpi/drivers/acpi_memhotplug/unbind), driver_unbind()
will be called. This function does not care the return value.
When we remove the module acpi_memhotplug, acpi_memory_device_exit()
will be called. This function does not care the return value too.
I don't know whether there are some other cases that acpi_memory_device_remove()
will be called.
Thanks
Wen Congyang
Thanks
Wen Congyang
[RFC PATCH v2 4/13]
* remove a firmware_memmap_entry allocated by kzmalloc()
change log of v2:
[RFC PATCH v2 2/13]
* check whether memory block is offline or not before calling
offline_memory()
* check whether section is valid or not in is_memblk_offline()
* call kobject_put() for each memory_block in is_memblk_offline()
[RFC PATCH v2 3/13]
* unify the end argument of firmware_map_add_early/hotplug
[RFC PATCH v2 4/13]
* add release_firmware_map_entry() for freeing firmware_map_entry
[RFC PATCH v2 6/13]
* add release_memory_block() for freeing memory_block
[RFC PATCH v2 11/13]
* fix wrong arguments of free_pages()
---
arch/powerpc/platforms/pseries/hotplug-memory.c | 16 +-
arch/x86/mm/init_64.c | 144
drivers/acpi/acpi_memhotplug.c | 28
drivers/base/memory.c | 54 -
drivers/base/node.c |7 +
drivers/firmware/memmap.c | 78 -
include/linux/firmware-map.h|6 +
include/linux/memory.h |5
include/linux/memory_hotplug.h | 17 --
include/linux/mm.h |5
mm/memory_hotplug.c | 98
mm/sparse.c |5
12 files changed, 414 insertions(+), 49 deletions(-)
--
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to majord...@vger.kernel.org
More
RE: [PATCH 1/4] Talitos: move the data structure into header file
-Original Message- From: Phillips Kim-R1AAHA Sent: Wednesday, July 11, 2012 8:11 AM To: Liu Qiang-B32616 Cc: linux-cry...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; Li Yang- R58472; Herbert Xu; David S. Miller; Geanta Neag Horia Ioan-B05471 Subject: Re: [PATCH 1/4] Talitos: move the data structure into header file On Tue, 10 Jul 2012 13:56:46 +0800 Qiang Liu qiang@freescale.com wrote: Move the declaration of talitos data structure into talitos.h. Cc: Herbert Xu herb...@gondor.apana.org.au Cc: David S. Miller da...@davemloft.net Signed-off-by: Qiang Liu qiang@freescale.com --- this patch has already been submitted [1]. Subsequent patches in this series also don't apply cleanly: can you rebase onto [2], which is based on Herbert's cryptodev tree and contain's Horia's four patches, and re-send? Kim, Thanks for your note, I will rebase the cryptodev tree and resend the patch again. Also note that upstream talitos does not yet contain NAPI support [3]. Thanks. Thanks, Kim [1] http://www.mail-archive.com/linux- cry...@vger.kernel.org/msg07299.html [2] git://git.freescale.com/crypto/cryptodev.git [3] http://www.mail-archive.com/linux- cry...@vger.kernel.org/msg07289.html ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Using alloc_coherent for caam job rings
On Wed, Jun 27, 2012 at 07:34:11PM +, Kim Phillips wrote: On Wed, 27 Jun 2012 10:58:32 +0530 Bharat Bhushan r65...@freescale.com wrote: This resolves the Linux boot crash issue when swiotlb=force is set in bootargs on systems which have memory more than 4G. Acked-by: Kim Phillips kim.phill...@freescale.com Patch applied. Thanks! -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v3 11/13] memory-hotplug : free memmap of sparse-vmemmap
At 07/09/2012 06:33 PM, Yasuaki Ishimatsu Wrote:
I don't think that all pages of virtual mapping in removed memory can be
freed, since page which type is MIX_SECTION_INFO is difficult to free.
So, the patch only frees page which type is SECTION_INFO at first.
CC: David Rientjes rient...@google.com
CC: Jiang Liu liu...@gmail.com
CC: Len Brown len.br...@intel.com
CC: Benjamin Herrenschmidt b...@kernel.crashing.org
CC: Paul Mackerras pau...@samba.org
CC: Christoph Lameter c...@linux.com
Cc: Minchan Kim minchan@gmail.com
CC: Andrew Morton a...@linux-foundation.org
CC: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
CC: Wen Congyang we...@cn.fujitsu.com
Signed-off-by: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com
---
arch/x86/mm/init_64.c | 91
++
include/linux/mm.h|2 +
mm/memory_hotplug.c |5 ++
mm/sparse.c |5 +-
4 files changed, 101 insertions(+), 2 deletions(-)
Index: linux-3.5-rc4/include/linux/mm.h
===
--- linux-3.5-rc4.orig/include/linux/mm.h 2012-07-03 14:22:18.530011567
+0900
+++ linux-3.5-rc4/include/linux/mm.h 2012-07-03 14:22:20.83872 +0900
@@ -1588,6 +1588,8 @@ int vmemmap_populate(struct page *start_
void vmemmap_populate_print_last(void);
void register_page_bootmem_memmap(unsigned long section_nr, struct page *map,
unsigned long size);
+void vmemmap_kfree(struct page *memmpa, unsigned long nr_pages);
+void vmemmap_free_bootmem(struct page *memmpa, unsigned long nr_pages);
enum mf_flags {
MF_COUNT_INCREASED = 1 0,
Index: linux-3.5-rc4/mm/sparse.c
===
--- linux-3.5-rc4.orig/mm/sparse.c2012-07-03 14:21:45.071429805 +0900
+++ linux-3.5-rc4/mm/sparse.c 2012-07-03 14:22:21.000983767 +0900
@@ -614,12 +614,13 @@ static inline struct page *kmalloc_secti
/* This will make the necessary allocations eventually. */
return sparse_mem_map_populate(pnum, nid);
}
-static void __kfree_section_memmap(struct page *memmap, unsigned long
nr_pages)
+static void __kfree_section_memmap(struct page *page, unsigned long nr_pages)
{
- return; /* XXX: Not implemented yet */
+ vmemmap_kfree(page, nr_pages);
Hmm, I think you try to free the memory allocated in kmalloc_section_memmap().
}
static void free_map_bootmem(struct page *page, unsigned long nr_pages)
{
+ vmemmap_free_bootmem(page, nr_pages);
}
Hmm, which function is the memory you try to free allocated in?
#else
static struct page *__kmalloc_section_memmap(unsigned long nr_pages)
Index: linux-3.5-rc4/arch/x86/mm/init_64.c
===
--- linux-3.5-rc4.orig/arch/x86/mm/init_64.c 2012-07-03 14:22:18.538011465
+0900
+++ linux-3.5-rc4/arch/x86/mm/init_64.c 2012-07-03 14:22:21.007983103
+0900
@@ -978,6 +978,97 @@ vmemmap_populate(struct page *start_page
return 0;
}
+unsigned long find_and_clear_pte_page(unsigned long addr, unsigned long end,
+ struct page **pp)
+{
+ pgd_t *pgd;
+ pud_t *pud;
+ pmd_t *pmd;
+ pte_t *pte;
+ unsigned long next;
+
+ *pp = NULL;
+
+ pgd = pgd_offset_k(addr);
+ if (pgd_none(*pgd))
+ return (addr + PAGE_SIZE) PAGE_MASK;
Hmm, why not goto next pgd?
+
+ pud = pud_offset(pgd, addr);
+ if (pud_none(*pud))
+ return (addr + PAGE_SIZE) PAGE_MASK;
+
+ if (!cpu_has_pse) {
+ next = (addr + PAGE_SIZE) PAGE_MASK;
+ pmd = pmd_offset(pud, addr);
+ if (pmd_none(*pmd))
+ return next;
+
+ pte = pte_offset_kernel(pmd, addr);
+ if (pte_none(*pte))
+ return next;
+
+ *pp = pte_page(*pte);
+ pte_clear(init_mm, addr, pte);
I think you should flush tlb here.
+ } else {
+ next = pmd_addr_end(addr, end);
+
+ pmd = pmd_offset(pud, addr);
+ if (pmd_none(*pmd))
+ return next;
+
+ *pp = pmd_page(*pmd);
+ pmd_clear(pmd);
+ }
+
+ return next;
+}
+
+void __meminit
+vmemmap_kfree(struct page *memmap, unsigned long nr_pages)
+{
+ unsigned long addr = (unsigned long)memmap;
+ unsigned long end = (unsigned long)(memmap + nr_pages);
+ unsigned long next;
+ unsigned int order;
+ struct page *page;
+
+ for (; addr end; addr = next) {
+ page = NULL;
+ next = find_and_clear_pte_page(addr, end, page);
+ if (!page)
+ continue;
+
+ if (is_vmalloc_addr(page_address(page)))
+ vfree(page_address(page));
Hmm, the memory is allocated in vmemmap_alloc_block(),
Re: [PATCH] [powerpc] Export memory limit via device tree
diff --git a/arch/powerpc/kernel/machine_kexec.c
b/arch/powerpc/kernel/machine_kexec.c
index c957b12..0c9695d 100644
--- a/arch/powerpc/kernel/machine_kexec.c
+++ b/arch/powerpc/kernel/machine_kexec.c
@@ -207,6 +207,12 @@ static struct property crashk_size_prop = {
.value = crashk_size,
};
+static struct property memory_limit_prop = {
+ .name = linux,memory-limit,
+ .length = sizeof(phys_addr_t),
+ .value = memory_limit,
+};
+
AFAIK. phys_addr_t can change size, so instead make it point to a known
fixes size quantity (a u64).
+
+ /* memory-limit is needed for constructing the crash regions */
+ prop = of_find_property(node, memory_limit_prop.name, NULL);
+ if (prop)
+ prom_remove_property(node, prop);
+
+ if (memory_limit)
+ prom_add_property(node, memory_limit_prop);
+
There's a patch floating around making prom_update_property properly
handle both pre-existing and non-pre-existing props, you should probably
base yourself on top of it. I'm about to stick that patch in powerpc
-next
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v3 11/13] memory-hotplug : free memmap of sparse-vmemmap
2012/07/11 14:06, Wen Congyang wrote:
Hi Wen,
At 07/09/2012 06:33 PM, Yasuaki Ishimatsu Wrote:
I don't think that all pages of virtual mapping in removed memory can be
freed, since page which type is MIX_SECTION_INFO is difficult to free.
So, the patch only frees page which type is SECTION_INFO at first.
CC: David Rientjes rient...@google.com
CC: Jiang Liu liu...@gmail.com
CC: Len Brown len.br...@intel.com
CC: Benjamin Herrenschmidt b...@kernel.crashing.org
CC: Paul Mackerras pau...@samba.org
CC: Christoph Lameter c...@linux.com
Cc: Minchan Kim minchan@gmail.com
CC: Andrew Morton a...@linux-foundation.org
CC: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
CC: Wen Congyang we...@cn.fujitsu.com
Signed-off-by: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com
---
arch/x86/mm/init_64.c | 91
++
include/linux/mm.h|2 +
mm/memory_hotplug.c |5 ++
mm/sparse.c |5 +-
4 files changed, 101 insertions(+), 2 deletions(-)
Index: linux-3.5-rc4/include/linux/mm.h
===
--- linux-3.5-rc4.orig/include/linux/mm.h2012-07-03 14:22:18.530011567
+0900
+++ linux-3.5-rc4/include/linux/mm.h 2012-07-03 14:22:20.83872 +0900
@@ -1588,6 +1588,8 @@ int vmemmap_populate(struct page *start_
void vmemmap_populate_print_last(void);
void register_page_bootmem_memmap(unsigned long section_nr, struct page
*map,
unsigned long size);
+void vmemmap_kfree(struct page *memmpa, unsigned long nr_pages);
+void vmemmap_free_bootmem(struct page *memmpa, unsigned long nr_pages);
enum mf_flags {
MF_COUNT_INCREASED = 1 0,
Index: linux-3.5-rc4/mm/sparse.c
===
--- linux-3.5-rc4.orig/mm/sparse.c 2012-07-03 14:21:45.071429805 +0900
+++ linux-3.5-rc4/mm/sparse.c2012-07-03 14:22:21.000983767 +0900
@@ -614,12 +614,13 @@ static inline struct page *kmalloc_secti
/* This will make the necessary allocations eventually. */
return sparse_mem_map_populate(pnum, nid);
}
-static void __kfree_section_memmap(struct page *memmap, unsigned long
nr_pages)
+static void __kfree_section_memmap(struct page *page, unsigned long
nr_pages)
{
-return; /* XXX: Not implemented yet */
+vmemmap_kfree(page, nr_pages);
Hmm, I think you try to free the memory allocated in kmalloc_section_memmap().
Yes.
}
static void free_map_bootmem(struct page *page, unsigned long nr_pages)
{
+vmemmap_free_bootmem(page, nr_pages);
}
Hmm, which function is the memory you try to free allocated in?
The function try to free memory allocated from bootmem. The memory has
been registered by get_page_bootmem(). So we can free the memory by
put_page_bootmem().
#else
static struct page *__kmalloc_section_memmap(unsigned long nr_pages)
Index: linux-3.5-rc4/arch/x86/mm/init_64.c
===
--- linux-3.5-rc4.orig/arch/x86/mm/init_64.c 2012-07-03 14:22:18.538011465
+0900
+++ linux-3.5-rc4/arch/x86/mm/init_64.c 2012-07-03 14:22:21.007983103
+0900
@@ -978,6 +978,97 @@ vmemmap_populate(struct page *start_page
return 0;
}
+unsigned long find_and_clear_pte_page(unsigned long addr, unsigned long end,
+ struct page **pp)
+{
+pgd_t *pgd;
+pud_t *pud;
+pmd_t *pmd;
+pte_t *pte;
+unsigned long next;
+
+*pp = NULL;
+
+pgd = pgd_offset_k(addr);
+if (pgd_none(*pgd))
+return (addr + PAGE_SIZE) PAGE_MASK;
Hmm, why not goto next pgd?
Does it mean return (addr + PGDIR_SIZE) PGDIR_MASK?
+
+pud = pud_offset(pgd, addr);
+if (pud_none(*pud))
+return (addr + PAGE_SIZE) PAGE_MASK;
+
+if (!cpu_has_pse) {
+next = (addr + PAGE_SIZE) PAGE_MASK;
+pmd = pmd_offset(pud, addr);
+if (pmd_none(*pmd))
+return next;
+
+pte = pte_offset_kernel(pmd, addr);
+if (pte_none(*pte))
+return next;
+
+*pp = pte_page(*pte);
+pte_clear(init_mm, addr, pte);
I think you should flush tlb here.
Thanks, I'll update it.
+} else {
+next = pmd_addr_end(addr, end);
+
+pmd = pmd_offset(pud, addr);
+if (pmd_none(*pmd))
+return next;
+
+*pp = pmd_page(*pmd);
+pmd_clear(pmd);
+}
+
+return next;
+}
+
+void __meminit
+vmemmap_kfree(struct page *memmap, unsigned long nr_pages)
+{
+unsigned long addr = (unsigned long)memmap;
+unsigned long end = (unsigned long)(memmap + nr_pages);
+unsigned long next;
+unsigned int order;
+struct page *page;
+
+for (; addr end; addr = next) {
+page = NULL;
+
