On Tue, Sep 11, 2012 at 01:18:24PM +0800, Jerry wrote:
Hi Kim,
Thank you for your kindness. Let me clarify this:
On ARM architecture, there are 32 bits physical addresses space. However,
the addresses space is divided into 8 banks normally. Each bank
disabled/enabled by a chip selector
Best Regards
Jerry Huang
-Original Message-
From: Chris Ball [mailto:c...@laptop.org]
Sent: Wednesday, September 12, 2012 4:59 AM
To: Kumar Gala
Cc: Huang Changming-R66093; linuxppc-dev@lists.ozlabs.org list; linux-
m...@vger.kernel.org; Anton Vorontsov
Subject: Re: [PATCH 2/3]
This was originally motivated by a desire to see the mapping between
logical and hardware cpu numbers.
But it seemed that it made more sense to just add a command to dump
(most of) the paca.
With no arguments dp will dump the paca for all possible cpus. If
there are no possible cpus, like early
On 09/11/2012 01:51 PM, Benjamin Herrenschmidt wrote:
On Tue, 2012-09-11 at 10:20 +0800, Tiejun Chen wrote:
We can't emulate stwu since that may corrupt current exception stack.
So we will have to do real store operation in the exception return code.
Firstly we'll allocate a trampoline
We need to add a new thread flag, TIF_EMULATE_STACK_STORE,
for emulating stack store operation while exiting exception.
Signed-off-by: Tiejun Chen tiejun.c...@windriver.com
---
arch/powerpc/include/asm/thread_info.h |3 +++
1 file changed, 3 insertions(+)
diff --git
Somewhere we need this simple copy_and_flush().
Signed-off-by: Tiejun Chen tiejun.c...@windriver.com
---
arch/powerpc/kernel/entry_32.S | 27 +++
arch/powerpc/kernel/head_32.S | 26 --
2 files changed, 27 insertions(+), 26 deletions(-)
diff
We can't emulate stwu since that may corrupt current exception stack.
So we will have to do real store operation in the exception return code.
Firstly we'll allocate a trampoline exception frame below the kprobed
function stack and copy the current exception frame to the trampoline.
Then we can
We don't do the real store operation for kprobing 'stwu Rx,(y)R1'
since this may corrupt the exception frame, now we will do this
operation safely in exception return code after migrate current
exception frame below the kprobed function stack.
So we only update gpr[1] here and trigger a thread
On Wed, 2012-09-12 at 16:38 +0800, tiejun.chen wrote:
So you need to store that old r1 somewhere fist then retrieve it
after the memcpy call. That or open-code the memcpy to avoid all
the clobbering problems.
Maybe we can use copy_and_flush() since looks copy_and_flush() only
clobber r0,
On Wed, 2012-09-12 at 17:52 +1000, Michael Ellerman wrote:
This was originally motivated by a desire to see the mapping between
logical and hardware cpu numbers.
But it seemed that it made more sense to just add a command to dump
(most of) the paca.
With no arguments dp will dump the paca
On 09/12/2012 04:43 PM, Benjamin Herrenschmidt wrote:
On Wed, 2012-09-12 at 16:38 +0800, tiejun.chen wrote:
So you need to store that old r1 somewhere fist then retrieve it
after the memcpy call. That or open-code the memcpy to avoid all
the clobbering problems.
Maybe we can use
Will this engine be coordinating with another to handle memory copies?
The dma mapping code for async_tx/raid is broken when dma mapping
requests overlap or cross dma device boundaries [1].
[1]: http://marc.info/?l=linux-arm-kernelm=129407269402930w=2
Yes, it needs fsl-dma to handle
Hi,
Any feedback?
--
Kirill A. Shutemov
signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Wed, 2012-09-12 at 16:55 +0800, tiejun.chen wrote:
to worry about nor stack frame to create etc...
If you don't like this v4, let me know and then I can go back memcpy
for next
version.
Just open code the whole copy. It should be easy really. As I said, you
have the src and dst
Hi Michael,
On Wed, 12 Sep 2012 17:52:40 +1000 Michael Ellerman mich...@ellerman.id.au
wrote:
+#define DUMP(name, format) \
+ printf( %-*s = %#-*format\t(0x%lx)\n, 16, #name, 18, p-name, \
+ (u64)((void *)(p-name) - (void *)p));
I must say that I hate macros that reference
Device node adt7461 was wrongly added in p5040ds.dts, it should be added
into i2c instead of localbus, when build p5040ds.dtb, a warning will dump:
Warning (reg_format): reg property in
/localbus@ffe124000/nand@2,0/adt7461@4c has invalid length (4 bytes)
(#address-cells == 1, #size-cells == 1)
-Original Message-
From: Felipe Balbi [mailto:ba...@ti.com]
Sent: Thursday, September 06, 2012 10:28 PM
To: Enrico Scholz
Cc: ba...@ti.com; Chen Peter-B29397; linux-...@vger.kernel.org; linuxppc-
d...@lists.ozlabs.org; Li Yang-R58472; gre...@linuxfoundation.org
Subject: Re:
On Sep 12, 2012, at 1:18 AM, Huang Changming-R66093 wrote:
Best Regards
Jerry Huang
-Original Message-
From: Chris Ball [mailto:c...@laptop.org]
Sent: Wednesday, September 12, 2012 4:59 AM
To: Kumar Gala
Cc: Huang Changming-R66093; linuxppc-dev@lists.ozlabs.org list;
The current form of DO_KVM macro restricts its use to one call per input
parameter set. This is caused by kvmppc_resume_\intno\()_\srr1 symbol
definition.
Duplicate calls of DO_KVM are required by distinct implementations of
exeption handlers which are delegated at runtime. Use a rare label number
On Tue, Sep 11, 2012 at 10:14:46PM -0400, Eric Millbrandt wrote:
The mpc5200_psc_ac97 and mpc5200_psc_i2s modules rely on shared platform data
with mpc5200_dma.
This looks good but depends on patch 1 so I can't apply it - if you can
rebase things so this is patch 1 I'll apply it.
Hi Mark,
On 2012-09-11 Mark Brown wrote:
On Tue, Sep 11, 2012 at 10:14:49PM -0400, Eric Millbrandt wrote:
MPC5200 ASoC setup can now be done in the device tree.
I only noticed DT bindings being added for pcm030, not for efika?
When I looked I didn't see the Efika (PPC 5200B) DT in-tree. It
Hi Mark,
On 2012-09-11 Mark Brown wrote:
--- a/arch/powerpc/platforms/52xx/Kconfig
+++ b/arch/powerpc/platforms/52xx/Kconfig
@@ -1,6 +1,7 @@
config PPC_MPC52xx bool 52xx-based boardsdepends on 6xx +
select
FSL_SOC select PPC_CLOCKselect PPC_PCI_CHOICE
This
I'm reviving an old patch from 2009 that adds support for GXT4000P and GXT6500P
adapter to the gxt4500 driver.
See threads at http://marc.info/?l=linux-fbdev-develm=124345080216952w=2
and https://lists.ozlabs.org/pipermail/linuxppc-dev/2009-June/072672.html
for more details.
This patch adds
On Wed, Sep 12, 2012 at 6:05 PM, Cyril Chemparathy cy...@ti.com wrote:
On some PAE architectures, the entire range of physical memory could reside
outside the 32-bit limit. These systems need the ability to specify the
initrd location using 64-bit numbers.
This patch globally modifies the
I'm reviving an old patch from 2009 that adds support for GXT4000P and GXT6500P
adapter to the gxt4500 driver.
See threads at http://marc.info/?l=linux-fbdev-develm=124345080216952w=2
and https://lists.ozlabs.org/pipermail/linuxppc-dev/2009-June/072672.html
for more details.
This patch adds
I'm reviving an old patch from 2009 that adds support for GXT4000P and GXT6500P
adapter to the gxt4500 driver.
See threads at http://marc.info/?l=linux-fbdev-develm=124345080216952w=2
and https://lists.ozlabs.org/pipermail/linuxppc-dev/2009-June/072672.html
for more details.
This patch adds
On some PAE architectures, the entire range of physical memory could reside
outside the 32-bit limit. These systems need the ability to specify the
initrd location using 64-bit numbers.
This patch globally modifies the early_init_dt_setup_initrd_arch() function to
use 64-bit numbers instead of
Hi Mark,
On 2012-09-12 Mark Brown wrote:
On Tue, Sep 11, 2012 at 10:14:46PM -0400, Eric Millbrandt wrote:
The mpc5200_psc_ac97 and mpc5200_psc_i2s modules rely on shared
platform data with mpc5200_dma.
This looks good but depends on patch 1 so I can't apply it - if you can
rebase things so
Hi,
On Wed, Sep 12, 2012 at 01:20:28PM +0800, Wen Congyang wrote:
On Mon, Sep 10, 2012 at 10:01:44AM +0800, Wen Congyang wrote:
At 09/10/2012 09:46 AM, Yasuaki Ishimatsu Wrote:
How do you test the patch? As Andrew says, for hot-removing memory,
we need a particular hardware. I think so
Anticipating growth in coming years, we should ensure we are getting a
good lead on testing.
Signed-off-by: Nishanth Aravamudan n...@us.ibm.com
diff --git a/arch/powerpc/configs/pseries_defconfig
b/arch/powerpc/configs/pseries_defconfig
index 1f65b3c..a0e0e53 100644
---
This patch removed the tasklet and moved the wait queue into the
private structure. It also cleaned up the response CRQ path.
Signed-off-by: Ashley Lai ad...@us.ibm.com
---
James,
This patch is based on your next branch.
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git
On 9/12/2012 12:16 PM, Geert Uytterhoeven wrote:
On Wed, Sep 12, 2012 at 6:05 PM, Cyril Chemparathy cy...@ti.com wrote:
On some PAE architectures, the entire range of physical memory could reside
outside the 32-bit limit. These systems need the ability to specify the
initrd location using
On 12.09.2012, at 15:18, Mihai Caraman mihai.cara...@freescale.com wrote:
The current form of DO_KVM macro restricts its use to one call per input
parameter set. This is caused by kvmppc_resume_\intno\()_\srr1 symbol
definition.
Duplicate calls of DO_KVM are required by distinct
On Sep 12, 2012, at 5:36 AM, Shaohui Xie wrote:
Device node adt7461 was wrongly added in p5040ds.dts, it should be added
into i2c instead of localbus, when build p5040ds.dtb, a warning will dump:
Warning (reg_format): reg property in
/localbus@ffe124000/nand@2,0/adt7461@4c has invalid
On Aug 28, 2012, at 2:44 AM, Jia Hongtao wrote:
We unified the Freescale pci/pcie initialization by changing the fsl_pci
to a platform driver. In previous PCI code architecture the initialization
routine is called at board_setup_arch stage. Now the initialization is done
in probe function
On Sep 3, 2012, at 4:22 AM, Roy Zang wrote:
Signed-off-by: Roy Zang tie-fei.z...@freescale.com
---
arch/powerpc/sysdev/fsl_pci.h |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
applied to next
- k
___
Linuxppc-dev mailing list
On Sep 3, 2012, at 4:22 AM, Roy Zang wrote:
Freescale PCIe IP block revision bigger than rev2.2 will also need
redefine the sequence of inbound windows. So change to use IP block
revision instead of compatible for the judgment.
Signed-off-by: Roy Zang tie-fei.z...@freescale.com
---
On 09/12/2012 11:05 AM, Cyril Chemparathy wrote:
On some PAE architectures, the entire range of physical memory could reside
outside the 32-bit limit. These systems need the ability to specify the
initrd location using 64-bit numbers.
This patch globally modifies the
On 09/12/2012 08:02 PM, Cyril Chemparathy wrote:
-void __init early_init_dt_setup_initrd_arch(unsigned long start,
unsigned long end)
+void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
Why not phys_addr_t?
The rest of the memory specific bits of the device-tree code use u64
On 09/12/2012 03:31 PM, Nicolas Pitre wrote:
On Wed, 12 Sep 2012, Rob Herring wrote:
On 09/12/2012 11:05 AM, Cyril Chemparathy wrote:
On some PAE architectures, the entire range of physical memory could reside
outside the 32-bit limit. These systems need the ability to specify the
initrd
On 09/12/2012 01:56 PM, Alexander Graf wrote:
On 12.09.2012, at 15:18, Mihai Caraman mihai.cara...@freescale.com wrote:
The current form of DO_KVM macro restricts its use to one call per input
parameter set. This is caused by kvmppc_resume_\intno\()_\srr1 symbol
definition.
Duplicate
On 12.09.2012, at 23:38, Scott Wood scottw...@freescale.com wrote:
On 09/12/2012 01:56 PM, Alexander Graf wrote:
On 12.09.2012, at 15:18, Mihai Caraman mihai.cara...@freescale.com wrote:
The current form of DO_KVM macro restricts its use to one call per input
parameter set. This is
On 09/12/2012 04:45 PM, Alexander Graf wrote:
On 12.09.2012, at 23:38, Scott Wood scottw...@freescale.com wrote:
On 09/12/2012 01:56 PM, Alexander Graf wrote:
On 12.09.2012, at 15:18, Mihai Caraman mihai.cara...@freescale.com wrote:
The current form of DO_KVM macro restricts its use
On 09/12/2012 02:58 PM, Sebastian Andrzej Siewior wrote:
On 09/12/2012 08:02 PM, Cyril Chemparathy wrote:
-void __init early_init_dt_setup_initrd_arch(unsigned long start,
unsigned long end)
+void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
Why not phys_addr_t?
The rest of
On Wed, 12 Sep 2012, Rob Herring wrote:
On 09/12/2012 11:05 AM, Cyril Chemparathy wrote:
On some PAE architectures, the entire range of physical memory could reside
outside the 32-bit limit. These systems need the ability to specify the
initrd location using 64-bit numbers.
This
Right, as far as i'm concerced that patch always worked without issues.
--nico
On Wed, 12 Sep 2012 18:06:44 +0200
Dan Horák d...@danny.cz wrote:
I'm reviving an old patch from 2009 that adds support for GXT4000P and
GXT6500P
adapter to the gxt4500 driver.
See threads at
PTRS_PER_PUD should be based on PUD_INDEX_SIZE, not PMD_INDEX_SIZE. We
got away with it because PUD and PMD had the same index size, but this is
no longer true with Aneesh's patchset to support a 46-bit user effective
address space.
Signed-off-by: Scott Wood scottw...@freescale.com
---
On Wed, 2012-09-12 at 18:00 -0500, Scott Wood wrote:
PTRS_PER_PUD should be based on PUD_INDEX_SIZE, not PMD_INDEX_SIZE. We
got away with it because PUD and PMD had the same index size, but this is
no longer true with Aneesh's patchset to support a 46-bit user effective
address space.
Ah, my
On 9/12/2012 4:23 PM, Rob Herring wrote:
On 09/12/2012 11:05 AM, Cyril Chemparathy wrote:
On some PAE architectures, the entire range of physical memory could reside
outside the 32-bit limit. These systems need the ability to specify the
initrd location using 64-bit numbers.
This patch
On Wed, 2012-09-12 at 14:20 +0200, Dan Horák wrote:
I'm reviving an old patch from 2009 that adds support for GXT4000P and
GXT6500P
adapter to the gxt4500 driver.
Who is the original author ?
Cheers,
Ben.
See threads at http://marc.info/?l=linux-fbdev-develm=124345080216952w=2
and
-Original Message-
From: Chris Ball [mailto:c...@laptop.org]
Sent: Wednesday, September 12, 2012 4:59 AM
To: Kumar Gala
Cc: Huang Changming-R66093; linuxppc-dev@lists.ozlabs.org list;
linux- m...@vger.kernel.org; Anton Vorontsov
Subject: Re: [PATCH 2/3] powerpc/esdhc: add
On Wed, Sep 12, 2012 at 10:05:33AM -0400, Eric Millbrandt wrote:
Please fix your mailer to word wrap within paragraphs.
On 2012-09-11 Mark Brown wrote:
I only noticed DT bindings being added for pcm030, not for efika?
When I looked I didn't see the Efika (PPC 5200B) DT in-tree. It only
On Thu, Sep 13, 2012 at 2:01 AM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Wed, 2012-09-12 at 14:20 +0200, Dan Horák wrote:
I'm reviving an old patch from 2009 that adds support for GXT4000P and
GXT6500P
adapter to the gxt4500 driver.
Who is the original author ?
53 matches
Mail list logo
