* [PATCH 04/20 v3] powerpc/mm/fault.c: Port OOM changes to do_page_fault
From: Kautuk Consul @ 2012-03-20 16:01 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Jimi Xenidis, Ingo Molnar,
Peter Zijlstra, Christian Dietrich
Cc: linuxppc-dev, linux-kernel, Mohd. Faris, Kautuk Consul
Commit d065bd810b6deb67d4897a14bfe21f8eb526ba99
(mm: retry page fault when blocking on disk transfer) and
commit 37b23e0525d393d48a7d59f870b3bc061a30ccdb
(x86,mm: make pagefault killable)
The above commits introduced changes into the x86 pagefault handler
for making the page fault handler retryable as well as killable.
These changes reduce the mmap_sem hold time, which is crucial
during OOM killer invocation.
Port these changes to powerpc.
Signed-off-by: Mohd. Faris <mohdfarisq2010@gmail.com>
Signed-off-by: Kautuk Consul <consul.kautuk@gmail.com>
---
arch/powerpc/mm/fault.c | 51 +++++++++++++++++++++++++++++++++-------------
1 files changed, 36 insertions(+), 15 deletions(-)
diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
index 2f0d1b0..a3b1176 100644
--- a/arch/powerpc/mm/fault.c
+++ b/arch/powerpc/mm/fault.c
@@ -129,6 +129,7 @@ int __kprobes do_page_fault(struct pt_regs *regs, unsigned long address,
int is_write = 0, ret;
int trap = TRAP(regs);
int is_exec = trap == 0x400;
+ unsigned int flags = FAULT_FLAG_ALLOW_RETRY | FAULT_FLAG_KILLABLE;
#if !(defined(CONFIG_4xx) || defined(CONFIG_BOOKE))
/*
@@ -212,6 +213,7 @@ int __kprobes do_page_fault(struct pt_regs *regs, unsigned long address,
if (!user_mode(regs) && !search_exception_tables(regs->nip))
goto bad_area_nosemaphore;
+retry:
down_read(&mm->mmap_sem);
}
@@ -313,6 +315,7 @@ good_area:
} else if (is_write) {
if (!(vma->vm_flags & VM_WRITE))
goto bad_area;
+ flags |= FAULT_FLAG_WRITE;
/* a read */
} else {
/* protection fault */
@@ -327,7 +330,11 @@ good_area:
* make sure we exit gracefully rather than endlessly redo
* the fault.
*/
- ret = handle_mm_fault(mm, vma, address, is_write ? FAULT_FLAG_WRITE : 0);
+ ret = handle_mm_fault(mm, vma, address, flags);
+
+ if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current))
+ return 0;
+
if (unlikely(ret & VM_FAULT_ERROR)) {
if (ret & VM_FAULT_OOM)
goto out_of_memory;
@@ -335,22 +342,36 @@ good_area:
goto do_sigbus;
BUG();
}
- if (ret & VM_FAULT_MAJOR) {
- current->maj_flt++;
- perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS_MAJ, 1,
- regs, address);
-#ifdef CONFIG_PPC_SMLPAR
- if (firmware_has_feature(FW_FEATURE_CMO)) {
- preempt_disable();
- get_lppaca()->page_ins += (1 << PAGE_FACTOR);
- preempt_enable();
+ if (flags & FAULT_FLAG_ALLOW_RETRY) {
+ if (ret & VM_FAULT_MAJOR) {
+ current->maj_flt++;
+ perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS_MAJ, 1,
+ regs, address);
+#ifdef CONFIG_PPC_SMLPAR
+ if (firmware_has_feature(FW_FEATURE_CMO)) {
+ preempt_disable();
+ get_lppaca()->page_ins += (1 << PAGE_FACTOR);
+ preempt_enable();
+ }
+#endif
+ } else {
+ current->min_flt++;
+ perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS_MIN, 1,
+ regs, address);
+ }
+ if (fault & VM_FAULT_RETRY) {
+ flags &= ~FAULT_FLAG_ALLOW_RETRY;
+
+ /*
+ * No need to up_read(&mm->mmap_sem) as we would
+ * have already released it in __lock_page_or_retry
+ * in mm/filemap.c.
+ */
+
+ goto retry;
}
-#endif
- } else {
- current->min_flt++;
- perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS_MIN, 1,
- regs, address);
}
+
up_read(&mm->mmap_sem);
return 0;
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH 5/5] powerpc/5200: convert mpc5200 to use of_platform_populate()
From: Anatolij Gustschin @ 2012-03-20 16:20 UTC (permalink / raw)
To: Grant Likely; +Cc: devicetree-discuss, linuxppc-dev
In-Reply-To: <20110621184513.18176.24174.stgit@ponder>
On Tue, 21 Jun 2011 12:45:13 -0600
Grant Likely <grant.likely@secretlab.ca> wrote:
> of_platform_populate() also handles nodes at the root of the tree,
> which is wanted for things like describing the sound complex. This
> patch converts mpc5200 support to use of_platform_populate() instead
> of of_platform_bus_probe().
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> ---
> arch/powerpc/platforms/52xx/mpc52xx_common.c | 10 ++++------
> 1 files changed, 4 insertions(+), 6 deletions(-)
Applied for mpc5xxx next, thanks.
Anatolij
^ permalink raw reply
* Re: [PATCH] powerpc/mpc52xx: setup port_config and CDM settings through DT
From: Anatolij Gustschin @ 2012-03-20 16:28 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Heiko Schocher, Grant Likely, Wolfgang Denk
In-Reply-To: <1332147082-4363-1-git-send-email-agust@denx.de>
On Mon, 19 Mar 2012 09:51:22 +0100
Anatolij Gustschin <agust@denx.de> wrote:
> From: Heiko Schocher <hs@denx.de>
>
> If firmware does not setup the "GPS Port Configuration Register"
> and the "CDM 48MHz Fractional Divider Configuration Register",
> it can be corrected by additional properties in the device tree.
> Add appropriate code to utility functions and document used
> bindings.
>
> Signed-off-by: Heiko Schocher <hs@denx.de>
> cc: devicetree-discuss@lists.ozlabs.org
> cc: linuxppc-dev@lists.ozlabs.org
> cc: Grant Likely <glikely@secretlab.ca>
> cc: Wolfgang Denk <wd@denx.de>
> Signed-off-by: Anatolij Gustschin <agust@denx.de>
> ---
> .../devicetree/bindings/powerpc/fsl/mpc5200.txt | 17 ++++++++++++
> arch/powerpc/platforms/52xx/mpc52xx_common.c | 27 ++++++++++++++++++++
> 2 files changed, 44 insertions(+), 0 deletions(-)
Applied for mpc5xxx next, thanks.
Anatolij
^ permalink raw reply
* Please pull 'next' branch of 5xxx tree
From: Anatolij Gustschin @ 2012-03-20 17:04 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
Hi Ben,
please pull some mpc5xxx patches for linux-next. Thanks!
Anatolij
The following changes since commit 01e8ec4417d3c484986af0adaa0ae6632e0a59cd:
powerpc: Fix power4/970 idle code regression with lockdep (2012-03-16 09:28:17 +1100)
are available in the git repository at:
git://git.denx.de/linux-2.6-agust.git next
Andrea Gelmini (1):
Documentation/powerpc/mpc52xx.txt: Checkpatch cleanup
Grant Likely (1):
powerpc/5200: convert mpc5200 to use of_platform_populate()
Heiko Schocher (4):
powerpc/mpc5200: update mpc5200_defconfig to fit for charon board
powerpc/mpc52xx: setup port_config and CDM settings through DT
powerpc/mpc52xx: add a4m072 board support
powerpc/mpc5200: add options to mpc5200_defconfig
.../devicetree/bindings/powerpc/fsl/mpc5200.txt | 17 ++
Documentation/powerpc/mpc52xx.txt | 12 +-
arch/powerpc/boot/dts/a4m072.dts | 168 ++++++++++++++++++++
arch/powerpc/configs/mpc5200_defconfig | 27 ++--
arch/powerpc/platforms/52xx/mpc5200_simple.c | 1 +
arch/powerpc/platforms/52xx/mpc52xx_common.c | 37 ++++-
6 files changed, 236 insertions(+), 26 deletions(-)
create mode 100644 arch/powerpc/boot/dts/a4m072.dts
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: don't call of_platform_bus_probe() twice
From: Grant Likely @ 2012-03-20 17:09 UTC (permalink / raw)
To: Timur Tabi; +Cc: Scott Wood, Dmitry Eremin-Solenikov, linuxppc-dev list
In-Reply-To: <4F677E51.8030905@freescale.com>
On Mon, 19 Mar 2012 13:43:29 -0500, Timur Tabi <timur@freescale.com> wrote:
> Grant Likely wrote:
> > The problem is that you want to create devices for grandchildren
> > nodes when the bus ids passed in don't match any of the child nodes so
> > the of_platform_bus_probe() doesn't iterate down to that level. This
> > is correct and expected behaviour.
>
> Well, I'm not still not 100% sure on what I'm supposed to do, so I tried this:
>
> static struct of_device_id __initdata p1022_ds_ids[] = {
> /* The audio driver probes the SSI DMA channels individually */
> { .compatible = "fsl,ssi-dma-channel", },
> {},
> };
>
> static int __init p1022_ds_publish_devices(void)
> {
> struct device_node *np;
> int ret;
>
> mpc85xx_common_publish_devices();
>
> for_each_compatible_node(np, NULL, "fsl,eloplus-dma") {
> ret = of_platform_bus_probe(np, p1022_ds_ids, NULL);
> if (ret)
> return ret;
Does a driver bind against "fsl,eloplus-dma"? If so, then I would
call of_platform_populate() from within the fsl,eloplus-dma driver's
probe method.
g.
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: don't call of_platform_bus_probe() twice
From: Timur Tabi @ 2012-03-20 17:25 UTC (permalink / raw)
To: Grant Likely; +Cc: Scott Wood, Dmitry Eremin-Solenikov, linuxppc-dev list
In-Reply-To: <20120320170942.0C4143E2834@localhost>
Grant Likely wrote:
> Does a driver bind against "fsl,eloplus-dma"? If so, then I would
> call of_platform_populate() from within the fsl,eloplus-dma driver's
> probe method.
Well, there are two "DMA" drivers.
The one in drivers/dma binds on fsl,eloplus-dma, and then manually scans
for children with the "fsl,eloplus-dma-channel" compatible. This driver
works today because the fsl,eloplus-dma nodes are children of the SOC
node, which is already probed.
The other is in sound/soc/fsl and binds on "fsl,ssi-dma-channel". These
are also children of the fsl,eloplus-dma node. This driver does NOT work
today, because the fsl,eloplus-dma is not probed.
I do not want the two drivers to depend on each other. They are
completely separate. So I don't want to call of_platform_populate() from
the drivers/dma driver. I could call it from the sound/soc/fsl driver,
however. I will try to see if that works.
They only problem I see with this is that I am thinking about modifying
the drivers/dma driver to probe on "fsl,eloplus-dma-channel" channels
directly. If I do that, then who should call of_platform_populate()?
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH] powerpc/crypto: caam - add backward compatible string sec4.0
From: Kumar Gala @ 2012-03-20 21:08 UTC (permalink / raw)
To: Shengzhou Liu; +Cc: linuxppc-dev@lists.ozlabs.org list, stable
In-Reply-To: <1332137973-32660-1-git-send-email-Shengzhou.Liu@freescale.com>
On Mar 19, 2012, at 1:19 AM, Shengzhou Liu wrote:
> In some device trees of previous version, there were string "fsl,sec4.0".
> To be backward compatible with device trees, we have CAAM driver first
> check "fsl,sec-v4.0", if it fails, then check for "fsl,sec4.0".
>
> Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
> ---
> drivers/crypto/caam/caamalg.c | 14 ++++++++++----
> drivers/crypto/caam/ctrl.c | 16 ++++++++++++++++
> 2 files changed, 26 insertions(+), 4 deletions(-)
Should be sent to the linux crypto list & maintainer.
- k
^ permalink raw reply
* Re: [PATCH 04/20 v3] powerpc/mm/fault.c: Port OOM changes to do_page_fault
From: Benjamin Herrenschmidt @ 2012-03-20 21:28 UTC (permalink / raw)
To: Kautuk Consul
Cc: Peter Zijlstra, linux-kernel, Christian Dietrich, Paul Mackerras,
Mohd. Faris, Ingo Molnar, linuxppc-dev
In-Reply-To: <1332259260-1943-1-git-send-email-consul.kautuk@gmail.com>
On Tue, 2012-03-20 at 12:01 -0400, Kautuk Consul wrote:
> Commit d065bd810b6deb67d4897a14bfe21f8eb526ba99
> (mm: retry page fault when blocking on disk transfer) and
> commit 37b23e0525d393d48a7d59f870b3bc061a30ccdb
> (x86,mm: make pagefault killable)
>
> The above commits introduced changes into the x86 pagefault handler
> for making the page fault handler retryable as well as killable.
>
> These changes reduce the mmap_sem hold time, which is crucial
> during OOM killer invocation.
>
> Port these changes to powerpc.
I have done that port already :-) It's in powerpc-next which I will send
to Linus to pull today or tomorrow....
Cheers,
Ben.
> Signed-off-by: Mohd. Faris <mohdfarisq2010@gmail.com>
> Signed-off-by: Kautuk Consul <consul.kautuk@gmail.com>
> ---
> arch/powerpc/mm/fault.c | 51 +++++++++++++++++++++++++++++++++-------------
> 1 files changed, 36 insertions(+), 15 deletions(-)
>
> diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
> index 2f0d1b0..a3b1176 100644
> --- a/arch/powerpc/mm/fault.c
> +++ b/arch/powerpc/mm/fault.c
> @@ -129,6 +129,7 @@ int __kprobes do_page_fault(struct pt_regs *regs, unsigned long address,
> int is_write = 0, ret;
> int trap = TRAP(regs);
> int is_exec = trap == 0x400;
> + unsigned int flags = FAULT_FLAG_ALLOW_RETRY | FAULT_FLAG_KILLABLE;
>
> #if !(defined(CONFIG_4xx) || defined(CONFIG_BOOKE))
> /*
> @@ -212,6 +213,7 @@ int __kprobes do_page_fault(struct pt_regs *regs, unsigned long address,
> if (!user_mode(regs) && !search_exception_tables(regs->nip))
> goto bad_area_nosemaphore;
>
> +retry:
> down_read(&mm->mmap_sem);
> }
>
> @@ -313,6 +315,7 @@ good_area:
> } else if (is_write) {
> if (!(vma->vm_flags & VM_WRITE))
> goto bad_area;
> + flags |= FAULT_FLAG_WRITE;
> /* a read */
> } else {
> /* protection fault */
> @@ -327,7 +330,11 @@ good_area:
> * make sure we exit gracefully rather than endlessly redo
> * the fault.
> */
> - ret = handle_mm_fault(mm, vma, address, is_write ? FAULT_FLAG_WRITE : 0);
> + ret = handle_mm_fault(mm, vma, address, flags);
> +
> + if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current))
> + return 0;
> +
> if (unlikely(ret & VM_FAULT_ERROR)) {
> if (ret & VM_FAULT_OOM)
> goto out_of_memory;
> @@ -335,22 +342,36 @@ good_area:
> goto do_sigbus;
> BUG();
> }
> - if (ret & VM_FAULT_MAJOR) {
> - current->maj_flt++;
> - perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS_MAJ, 1,
> - regs, address);
> -#ifdef CONFIG_PPC_SMLPAR
> - if (firmware_has_feature(FW_FEATURE_CMO)) {
> - preempt_disable();
> - get_lppaca()->page_ins += (1 << PAGE_FACTOR);
> - preempt_enable();
> + if (flags & FAULT_FLAG_ALLOW_RETRY) {
> + if (ret & VM_FAULT_MAJOR) {
> + current->maj_flt++;
> + perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS_MAJ, 1,
> + regs, address);
> +#ifdef CONFIG_PPC_SMLPAR
> + if (firmware_has_feature(FW_FEATURE_CMO)) {
> + preempt_disable();
> + get_lppaca()->page_ins += (1 << PAGE_FACTOR);
> + preempt_enable();
> + }
> +#endif
> + } else {
> + current->min_flt++;
> + perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS_MIN, 1,
> + regs, address);
> + }
> + if (fault & VM_FAULT_RETRY) {
> + flags &= ~FAULT_FLAG_ALLOW_RETRY;
> +
> + /*
> + * No need to up_read(&mm->mmap_sem) as we would
> + * have already released it in __lock_page_or_retry
> + * in mm/filemap.c.
> + */
> +
> + goto retry;
> }
> -#endif
> - } else {
> - current->min_flt++;
> - perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS_MIN, 1,
> - regs, address);
> }
> +
> up_read(&mm->mmap_sem);
> return 0;
>
^ permalink raw reply
* Re: [PATCH 04/20 v3] powerpc/mm/fault.c: Port OOM changes to do_page_fault
From: Benjamin Herrenschmidt @ 2012-03-20 21:29 UTC (permalink / raw)
To: Kautuk Consul
Cc: Peter Zijlstra, linux-kernel, Christian Dietrich, Paul Mackerras,
Mohd. Faris, Ingo Molnar, linuxppc-dev
In-Reply-To: <1332278936.2982.23.camel@pasglop>
On Wed, 2012-03-21 at 08:28 +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2012-03-20 at 12:01 -0400, Kautuk Consul wrote:
> > Commit d065bd810b6deb67d4897a14bfe21f8eb526ba99
> > (mm: retry page fault when blocking on disk transfer) and
> > commit 37b23e0525d393d48a7d59f870b3bc061a30ccdb
> > (x86,mm: make pagefault killable)
> >
> > The above commits introduced changes into the x86 pagefault handler
> > for making the page fault handler retryable as well as killable.
> >
> > These changes reduce the mmap_sem hold time, which is crucial
> > during OOM killer invocation.
> >
> > Port these changes to powerpc.
>
> I have done that port already :-) It's in powerpc-next which I will send
> to Linus to pull today or tomorrow....
BTW. Feel free to review what I've done, it's quite possible that I have
screwed something up ...
Cheers,
Ben.
> Cheers,
> Ben.
>
> > Signed-off-by: Mohd. Faris <mohdfarisq2010@gmail.com>
> > Signed-off-by: Kautuk Consul <consul.kautuk@gmail.com>
> > ---
> > arch/powerpc/mm/fault.c | 51 +++++++++++++++++++++++++++++++++-------------
> > 1 files changed, 36 insertions(+), 15 deletions(-)
> >
> > diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
> > index 2f0d1b0..a3b1176 100644
> > --- a/arch/powerpc/mm/fault.c
> > +++ b/arch/powerpc/mm/fault.c
> > @@ -129,6 +129,7 @@ int __kprobes do_page_fault(struct pt_regs *regs, unsigned long address,
> > int is_write = 0, ret;
> > int trap = TRAP(regs);
> > int is_exec = trap == 0x400;
> > + unsigned int flags = FAULT_FLAG_ALLOW_RETRY | FAULT_FLAG_KILLABLE;
> >
> > #if !(defined(CONFIG_4xx) || defined(CONFIG_BOOKE))
> > /*
> > @@ -212,6 +213,7 @@ int __kprobes do_page_fault(struct pt_regs *regs, unsigned long address,
> > if (!user_mode(regs) && !search_exception_tables(regs->nip))
> > goto bad_area_nosemaphore;
> >
> > +retry:
> > down_read(&mm->mmap_sem);
> > }
> >
> > @@ -313,6 +315,7 @@ good_area:
> > } else if (is_write) {
> > if (!(vma->vm_flags & VM_WRITE))
> > goto bad_area;
> > + flags |= FAULT_FLAG_WRITE;
> > /* a read */
> > } else {
> > /* protection fault */
> > @@ -327,7 +330,11 @@ good_area:
> > * make sure we exit gracefully rather than endlessly redo
> > * the fault.
> > */
> > - ret = handle_mm_fault(mm, vma, address, is_write ? FAULT_FLAG_WRITE : 0);
> > + ret = handle_mm_fault(mm, vma, address, flags);
> > +
> > + if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current))
> > + return 0;
> > +
> > if (unlikely(ret & VM_FAULT_ERROR)) {
> > if (ret & VM_FAULT_OOM)
> > goto out_of_memory;
> > @@ -335,22 +342,36 @@ good_area:
> > goto do_sigbus;
> > BUG();
> > }
> > - if (ret & VM_FAULT_MAJOR) {
> > - current->maj_flt++;
> > - perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS_MAJ, 1,
> > - regs, address);
> > -#ifdef CONFIG_PPC_SMLPAR
> > - if (firmware_has_feature(FW_FEATURE_CMO)) {
> > - preempt_disable();
> > - get_lppaca()->page_ins += (1 << PAGE_FACTOR);
> > - preempt_enable();
> > + if (flags & FAULT_FLAG_ALLOW_RETRY) {
> > + if (ret & VM_FAULT_MAJOR) {
> > + current->maj_flt++;
> > + perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS_MAJ, 1,
> > + regs, address);
> > +#ifdef CONFIG_PPC_SMLPAR
> > + if (firmware_has_feature(FW_FEATURE_CMO)) {
> > + preempt_disable();
> > + get_lppaca()->page_ins += (1 << PAGE_FACTOR);
> > + preempt_enable();
> > + }
> > +#endif
> > + } else {
> > + current->min_flt++;
> > + perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS_MIN, 1,
> > + regs, address);
> > + }
> > + if (fault & VM_FAULT_RETRY) {
> > + flags &= ~FAULT_FLAG_ALLOW_RETRY;
> > +
> > + /*
> > + * No need to up_read(&mm->mmap_sem) as we would
> > + * have already released it in __lock_page_or_retry
> > + * in mm/filemap.c.
> > + */
> > +
> > + goto retry;
> > }
> > -#endif
> > - } else {
> > - current->min_flt++;
> > - perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS_MIN, 1,
> > - regs, address);
> > }
> > +
> > up_read(&mm->mmap_sem);
> > return 0;
> >
>
^ permalink raw reply
* Re: Please pull 'next' branch of 5xxx tree
From: Wolfram Sang @ 2012-03-20 22:30 UTC (permalink / raw)
To: Anatolij Gustschin; +Cc: linuxppc-dev
In-Reply-To: <20120320180450.5f6dffe4@wker>
[-- Attachment #1: Type: text/plain, Size: 838 bytes --]
Hi,
> powerpc/mpc52xx: setup port_config and CDM settings through DT
Can we skip this patch for 3.5? Between posting it and pushing it upstream were
about 24 hours, so one didn't have much chance of reviewing (and no linux-next
exposure).
I think the bindings leave space for questions, e.g. is it really desirable to
have the fractional divide ratios encoded like in the bits in the register? Why
not encode it like e.g. <11 11 11 11> (the actual divisor) or so? I could
imagine there are examples for setting dividers somewhere. Poking values into
registers tends to be suspicious, so I'd vote for giving all this more
exposure.
Thanks,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: Please pull 'next' branch of 5xxx tree
From: Benjamin Herrenschmidt @ 2012-03-20 23:32 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev, Anatolij Gustschin, Stephen Rothwell
In-Reply-To: <20120320223017.GB6292@pengutronix.de>
On Tue, 2012-03-20 at 23:30 +0100, Wolfram Sang wrote:
> Hi,
>
> > powerpc/mpc52xx: setup port_config and CDM settings through DT
>
> Can we skip this patch for 3.5? Between posting it and pushing it upstream were
> about 24 hours, so one didn't have much chance of reviewing (and no linux-next
> exposure).
>
> I think the bindings leave space for questions, e.g. is it really desirable to
> have the fractional divide ratios encoded like in the bits in the register? Why
> not encode it like e.g. <11 11 11 11> (the actual divisor) or so? I could
> imagine there are examples for setting dividers somewhere. Poking values into
> registers tends to be suspicious, so I'd vote for giving all this more
> exposure.
I'll drop it from what I merge, thanks.
Anatolij, Can you organize with Stephen (CC) so that you tree is part of
linux-next for the next cycle ? Either that or make sure you send me
pull requests really early :-)
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] EEH: remove eeh device from OF node
From: Benjamin Herrenschmidt @ 2012-03-21 0:14 UTC (permalink / raw)
To: Gavin Shan; +Cc: sfr, linux-kernel, linux-next, paulus, linuxppc-dev
In-Reply-To: <1331721086-4314-1-git-send-email-shangw@linux.vnet.ibm.com>
On Wed, 2012-03-14 at 18:31 +0800, Gavin Shan wrote:
> Originally, the PCI sensitive OF node is tracing the eeh device
> through struct device_node::edev. However, it was regarded as
> bad idea.
>
> The patch removes struct device_node::edev. In addition, the
> global list of eeh devices is introduced, and do retrival of
> eeh device according to the given OF node through the global
> list.
So I'm not too happy with that. The main problem I see is that
the code -constantly- calls of_node_to_eeh_dev.
IE. On any MMIO that happens to return all 1's, we'll call
eeh_check_failure() for example, which does that. In fact for a hot path
it's pretty horrid, it will:
- Do an address cache lookup to get the pci_dev
- Get the device-node frokm the pci_dev
- Lookup your list to get the eeh_dev
Shouldn't we instead change the address cache to contain eeh_dev
instead ? And if you prefer keeping pci_dev, then it shouldn't be hard
to stick a pointer to the eeh_dev in there via either struct archdata or
maybe platform_data.
The EEH code still, even after your rework, constantly pass "dn"'s as
argument to functions just to convert it back to a struct eeh_dev rather
than trying to pass the eeh_dev.
So turning that into a list lookup will slow things down to a crawl.
Also your patch never seems to remove anything from your list, which
doesn't look right vs. hotplug.
I suggest we fix that with a two phase approach:
1- ASAP so we can still get that into 3.4, move the eeh_dev pointer to
struct pci_dn instead of struct device_node. This structure is
accessible directly via dn->data and is ppc specific, that will be a
better temporary solution and and adding stuff to the generic struct
device_node.
2- Then, what we need to do is generalize the use of eeh_dev rather
than device_node as the main object being worked on in the eeh layer and
thus as the argument to most functions.
Cheers,
Ben.
> Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
> ---
> arch/powerpc/include/asm/eeh.h | 7 +++++++
> arch/powerpc/platforms/pseries/eeh_dev.c | 29 ++++++++++++++++++++++++++++-
> include/linux/of.h | 10 ----------
> 3 files changed, 35 insertions(+), 11 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/eeh.h b/arch/powerpc/include/asm/eeh.h
> index d60f998..591e0a1 100644
> --- a/arch/powerpc/include/asm/eeh.h
> +++ b/arch/powerpc/include/asm/eeh.h
> @@ -56,6 +56,7 @@ struct eeh_dev {
> struct pci_controller *phb; /* Associated PHB */
> struct device_node *dn; /* Associated device node */
> struct pci_dev *pdev; /* Associated PCI device */
> + struct list_head list; /* Form the global link list */
> };
>
> static inline struct device_node *eeh_dev_to_of_node(struct eeh_dev *edev)
> @@ -115,6 +116,7 @@ extern int eeh_subsystem_enabled;
> */
> #define EEH_MAX_ALLOWED_FREEZES 5
>
> +struct eeh_dev *eeh_dev_from_of_node(struct device_node *dn);
> void * __devinit eeh_dev_init(struct device_node *dn, void *data);
> void __devinit eeh_dev_phb_init_dynamic(struct pci_controller *phb);
> void __init eeh_dev_phb_init(void);
> @@ -132,6 +134,11 @@ void eeh_add_device_tree_early(struct device_node *);
> void eeh_add_device_tree_late(struct pci_bus *);
> void eeh_remove_bus_device(struct pci_dev *);
>
> +static inline struct eeh_dev *of_node_to_eeh_dev(struct device_node *dn)
> +{
> + return eeh_dev_from_of_node(dn);
> +}
> +
> /**
> * EEH_POSSIBLE_ERROR() -- test for possible MMIO failure.
> *
> diff --git a/arch/powerpc/platforms/pseries/eeh_dev.c b/arch/powerpc/platforms/pseries/eeh_dev.c
> index f3aed7d..925d3a3 100644
> --- a/arch/powerpc/platforms/pseries/eeh_dev.c
> +++ b/arch/powerpc/platforms/pseries/eeh_dev.c
> @@ -34,6 +34,7 @@
> #include <linux/export.h>
> #include <linux/gfp.h>
> #include <linux/init.h>
> +#include <linux/list.h>
> #include <linux/kernel.h>
> #include <linux/pci.h>
> #include <linux/string.h>
> @@ -41,6 +42,30 @@
> #include <asm/pci-bridge.h>
> #include <asm/ppc-pci.h>
>
> +/* eeh device list */
> +static LIST_HEAD(eeh_dev_list);
> +
> +/**
> + * eeh_dev_from_of_node - Retrieve EEH device according to OF node
> + * @dn: OF node
> + *
> + * All existing eeh devices have been put into the global list.
> + * In addition, the eeh device is tracing the corresponding
> + * OF node. The function is used to retrieve the corresponding
> + * eeh device according to the given OF node.
> + */
> +struct eeh_dev *eeh_dev_from_of_node(struct device_node *dn)
> +{
> + struct eeh_dev *edev = NULL;
> +
> + list_for_each_entry(edev, &eeh_dev_list, list) {
> + if (edev->dn && edev->dn == dn)
> + return edev;
> + }
> +
> + return NULL;
> +}
> +
> /**
> * eeh_dev_init - Create EEH device according to OF node
> * @dn: device node
> @@ -62,10 +87,12 @@ void * __devinit eeh_dev_init(struct device_node *dn, void *data)
> }
>
> /* Associate EEH device with OF node */
> - dn->edev = edev;
> edev->dn = dn;
> edev->phb = phb;
>
> + /* Add to global list */
> + list_add_tail(&edev->list, &eeh_dev_list);
> +
> return NULL;
> }
>
> diff --git a/include/linux/of.h b/include/linux/of.h
> index 3e710d8..a75a831 100644
> --- a/include/linux/of.h
> +++ b/include/linux/of.h
> @@ -58,9 +58,6 @@ struct device_node {
> struct kref kref;
> unsigned long _flags;
> void *data;
> -#if defined(CONFIG_EEH)
> - struct eeh_dev *edev;
> -#endif
> #if defined(CONFIG_SPARC)
> char *path_component_name;
> unsigned int unique_id;
> @@ -75,13 +72,6 @@ struct of_phandle_args {
> uint32_t args[MAX_PHANDLE_ARGS];
> };
>
> -#if defined(CONFIG_EEH)
> -static inline struct eeh_dev *of_node_to_eeh_dev(struct device_node *dn)
> -{
> - return dn->edev;
> -}
> -#endif
> -
> #if defined(CONFIG_SPARC) || !defined(CONFIG_OF)
> /* Dummy ref counting routines - to be implemented later */
> static inline struct device_node *of_node_get(struct device_node *node)
^ permalink raw reply
* Re: Please pull 'next' branch of 5xxx tree
From: Anatolij Gustschin @ 2012-03-21 0:18 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <1332286341.2982.26.camel@pasglop>
On Wed, 21 Mar 2012 10:32:21 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
...
> Anatolij, Can you organize with Stephen (CC) so that you tree is part of
> linux-next for the next cycle ? Either that or make sure you send me
> pull requests really early :-)
Yes. Stephen, could you please change linux-next to pull from my
mpc5xxx tree
git://git.denx.de/linux-2.6-agust.git next
Thanks,
Anatolij
^ permalink raw reply
* Re: Please pull 'next' branch of 5xxx tree
From: Anatolij Gustschin @ 2012-03-21 0:56 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev
In-Reply-To: <20120320223017.GB6292@pengutronix.de>
Hi,
On Tue, 20 Mar 2012 23:30:17 +0100
Wolfram Sang <w.sang@pengutronix.de> wrote:
> Hi,
>
> > powerpc/mpc52xx: setup port_config and CDM settings through DT
>
> Can we skip this patch for 3.5? Between posting it and pushing it upstream were
> about 24 hours, so one didn't have much chance of reviewing (and no linux-next
> exposure).
Pretty much similar patch was posted nearly one year ago, so my
assumption was that people have had enough time to comment on it :-).
But I've dropped this patch from the next branch for now.
> I think the bindings leave space for questions, e.g. is it really desirable to
> have the fractional divide ratios encoded like in the bits in the register? Why
> not encode it like e.g. <11 11 11 11> (the actual divisor) or so? I could
> imagine there are examples for setting dividers somewhere. Poking values into
> registers tends to be suspicious, so I'd vote for giving all this more
> exposure.
At the end we will be poking values into registers anyway :-),
but I'm open for suggestions and discussion about them.
Thanks,
Anatolij
^ permalink raw reply
* [PATCH] powerpc/44x: Support CPM for Maui APM821xxx SoC and Bluestone board
From: Mai La @ 2012-03-21 2:21 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Josh Boyer, Matt Porter,
Tirumala R Marri, Grant Likely, Michael Neuling, Kumar Gala,
Anton Blanchard, linuxppc-dev, linux-kernel
Cc: Mai La
In this patch:
- Add CPM node for Maui APM821xxx SoC and Bluestone board in DTS
Signed-off-by: Mai La <mla@apm.com>
---
arch/powerpc/boot/dts/bluestone.dts | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/bluestone.dts b/arch/powerpc/boot/dts/bluestone.dts
index 2a56a0d..15a9516 100644
--- a/arch/powerpc/boot/dts/bluestone.dts
+++ b/arch/powerpc/boot/dts/bluestone.dts
@@ -117,6 +117,15 @@
dcr-reg = <0x00c 0x002>;
};
+ CPM0: cpm {
+ compatible = "ibm, cpm-apm821xx", "ibm,cpm";
+ cell-index = <0>;
+ dcr-reg = <0x160 0x003>;
+ er-offset = <0>;
+ idle-doze = <0x02000000>;
+ standby = <0x302570F0>;
+ };
+
plb {
compatible = "ibm,plb4";
#address-cells = <2>;
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH 04/20 v3] powerpc/mm/fault.c: Port OOM changes to do_page_fault
From: Kautuk Consul @ 2012-03-21 3:27 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Peter Zijlstra, linux-kernel, Christian Dietrich, Paul Mackerras,
Mohd. Faris, Ingo Molnar, linuxppc-dev
In-Reply-To: <1332278973.2982.24.camel@pasglop>
>>
>> I have done that port already :-) It's in powerpc-next which I will send
>> to Linus to pull today or tomorrow....
Oops, sorry I didn't know that as I don't regularly follow the powerpc tree.
I just did this change for all architectures. :)
>
> BTW. Feel free to review what I've done, it's quite possible that I have
> screwed something up ...
Okay, I'll take a look at it. Thanks again. :)
>
> Cheers,
> Ben.
^ permalink raw reply
* [PATCH] Disable /dev/port interface on powerpc systems
From: Haren Myneni @ 2012-03-21 5:37 UTC (permalink / raw)
To: benh, linuxppc-dev, anton
Some power systems do not have legacy ISA devices. So, /dev/port is not
a valid interface on these systems. User level tools such as kbdrate is
trying to access the device using this interface which is causing the
system crash.
This patch will fix this issue by not creating this interface on these
powerpc systems.
Signed-off-by: Haren Myneni <haren@us.ibm.com>
diff -Naurp linux.orig/arch/powerpc/kernel/isa-bridge.c
linux/arch/powerpc/kernel/isa-bridge.c
--- linux.orig/arch/powerpc/kernel/isa-bridge.c 2012-02-11
02:08:08.780005293 -0800
+++ linux/arch/powerpc/kernel/isa-bridge.c 2012-02-11 02:16:25.080003386
-0800
@@ -255,6 +255,14 @@ static struct notifier_block isa_bridge_
.notifier_call = isa_bridge_notify
};
+int __init legacy_isa_device_found(void)
+{
+ if (isa_bridge_pcidev)
+ return 1;
+
+ return 0;
+}
+
/**
* isa_bridge_init - register to be notified of ISA bridge
addition/removal
*
diff -Naurp linux.orig/drivers/char/mem.c linux/drivers/char/mem.c
--- linux.orig/drivers/char/mem.c 2012-02-11 02:08:42.710002440 -0800
+++ linux/drivers/char/mem.c 2012-03-20 20:40:43.650000003 -0700
@@ -35,6 +35,8 @@
# include <linux/efi.h>
#endif
+#define DEVPORT_MINOR 4
+
static inline unsigned long size_inside_page(unsigned long start,
unsigned long size)
{
@@ -910,6 +912,11 @@ static char *mem_devnode(struct device *
static struct class *mem_class;
+int __init __weak legacy_isa_device_found(void)
+{
+ return 1;
+}
+
static int __init chr_dev_init(void)
{
int minor;
@@ -930,6 +937,13 @@ static int __init chr_dev_init(void)
for (minor = 1; minor < ARRAY_SIZE(devlist); minor++) {
if (!devlist[minor].name)
continue;
+
+ /*
+ * Create /dev/port?
+ */
+ if ((minor == DEVPORT_MINOR) && !legacy_isa_device_found())
+ continue;
+
device_create(mem_class, NULL, MKDEV(MEM_MAJOR, minor),
NULL, devlist[minor].name);
}
diff -Naurp linux.orig/include/linux/isa.h linux/include/linux/isa.h
--- linux.orig/include/linux/isa.h 2012-02-11 02:07:52.030019810 -0800
+++ linux/include/linux/isa.h 2012-02-11 02:16:49.810002296 -0800
@@ -36,4 +36,5 @@ static inline void isa_unregister_driver
}
#endif
+extern int __init legacy_isa_device_found(void);
#endif /* __LINUX_ISA_H */
^ permalink raw reply
* [PATCH 10/16] mm/powerpc: use vm_flags_t for vma flags
From: Konstantin Khlebnikov @ 2012-03-21 6:56 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-mm, linuxppc-dev, linux-kernel, Paul Mackerras
In-Reply-To: <20120321065140.13852.52315.stgit@zurg>
Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/include/asm/mman.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/mman.h b/arch/powerpc/include/asm/mman.h
index d4a7f64..451de1c 100644
--- a/arch/powerpc/include/asm/mman.h
+++ b/arch/powerpc/include/asm/mman.h
@@ -44,7 +44,7 @@ static inline unsigned long arch_calc_vm_prot_bits(unsigned long prot)
}
#define arch_calc_vm_prot_bits(prot) arch_calc_vm_prot_bits(prot)
-static inline pgprot_t arch_vm_get_page_prot(unsigned long vm_flags)
+static inline pgprot_t arch_vm_get_page_prot(vm_flags_t vm_flags)
{
return (vm_flags & VM_SAO) ? __pgprot(_PAGE_SAO) : __pgprot(0);
}
^ permalink raw reply related
* Re: [PATCH] Disable /dev/port interface on powerpc systems
From: Benjamin Herrenschmidt @ 2012-03-21 7:23 UTC (permalink / raw)
To: Haren Myneni; +Cc: linuxppc-dev, anton
In-Reply-To: <1332308237.23222.49.camel@hbabu-laptop>
On Tue, 2012-03-20 at 22:37 -0700, Haren Myneni wrote:
> Some power systems do not have legacy ISA devices. So, /dev/port is not
> a valid interface on these systems. User level tools such as kbdrate is
> trying to access the device using this interface which is causing the
> system crash.
>
> This patch will fix this issue by not creating this interface on these
> powerpc systems.
Doesn't fix 32-bit... not a big deal for now I suppose... But I'd rather
you change the patch a tiny bit to change legacy_isa_device_found() to
arch_has_dev_port() instead. There may be other reason than legacy ISA
to enable dev/port or not so let's make the arch hook more generic.
Another approach which might be even better is to filter per-access,
ie for each read/write to /dev/port, have a hook to check if that
specific port is valid, but that may be overkill for what is
essentially a legacy interface that should have died a long time ago :)
Cheers,
Ben.
> Signed-off-by: Haren Myneni <haren@us.ibm.com>
>
>
> diff -Naurp linux.orig/arch/powerpc/kernel/isa-bridge.c
> linux/arch/powerpc/kernel/isa-bridge.c
> --- linux.orig/arch/powerpc/kernel/isa-bridge.c 2012-02-11
> 02:08:08.780005293 -0800
> +++ linux/arch/powerpc/kernel/isa-bridge.c 2012-02-11 02:16:25.080003386
> -0800
> @@ -255,6 +255,14 @@ static struct notifier_block isa_bridge_
> .notifier_call = isa_bridge_notify
> };
>
> +int __init legacy_isa_device_found(void)
> +{
> + if (isa_bridge_pcidev)
> + return 1;
> +
> + return 0;
> +}
> +
> /**
> * isa_bridge_init - register to be notified of ISA bridge
> addition/removal
> *
> diff -Naurp linux.orig/drivers/char/mem.c linux/drivers/char/mem.c
> --- linux.orig/drivers/char/mem.c 2012-02-11 02:08:42.710002440 -0800
> +++ linux/drivers/char/mem.c 2012-03-20 20:40:43.650000003 -0700
> @@ -35,6 +35,8 @@
> # include <linux/efi.h>
> #endif
>
> +#define DEVPORT_MINOR 4
> +
> static inline unsigned long size_inside_page(unsigned long start,
> unsigned long size)
> {
> @@ -910,6 +912,11 @@ static char *mem_devnode(struct device *
>
> static struct class *mem_class;
>
> +int __init __weak legacy_isa_device_found(void)
> +{
> + return 1;
> +}
> +
> static int __init chr_dev_init(void)
> {
> int minor;
> @@ -930,6 +937,13 @@ static int __init chr_dev_init(void)
> for (minor = 1; minor < ARRAY_SIZE(devlist); minor++) {
> if (!devlist[minor].name)
> continue;
> +
> + /*
> + * Create /dev/port?
> + */
> + if ((minor == DEVPORT_MINOR) && !legacy_isa_device_found())
> + continue;
> +
> device_create(mem_class, NULL, MKDEV(MEM_MAJOR, minor),
> NULL, devlist[minor].name);
> }
> diff -Naurp linux.orig/include/linux/isa.h linux/include/linux/isa.h
> --- linux.orig/include/linux/isa.h 2012-02-11 02:07:52.030019810 -0800
> +++ linux/include/linux/isa.h 2012-02-11 02:16:49.810002296 -0800
> @@ -36,4 +36,5 @@ static inline void isa_unregister_driver
> }
> #endif
>
> +extern int __init legacy_isa_device_found(void);
> #endif /* __LINUX_ISA_H */
>
^ permalink raw reply
* kilauea compilation breaks with v3.3 kernel and ELDK 4.2
From: Robert Berger @ 2012-03-21 12:10 UTC (permalink / raw)
To: linuxppc-dev
Hi,
Up to 3.2.x I was able to compile a mainline kernel for the kilauea
board, but...
http://git.denx.de/?p=linux-denx.git;a=commitdiff;h=075bcf5879225d0c2a119c23d8046b890e051e81
shows, that mfdcrx was introduced in the v3.3 kernel.
The problem is that for ppc-linux-gcc (GCC) 4.2.2 (which comes with the
ELDK 4.2) this assembly instruction is not known and the build breaks.
There are some obvious workarounds, like using a more recent toolchain
(e.g ELDK 5.x) or use make -k to keep on compiling even when there is an
error as much as possible;)
What puzzles me is that also stuff for boards is being compiled which is
not really needed like treeboot-currituck.c even when I configure the
kernel for a kilauea board.
Is this on purpose and if so why?
Please advise.
Regards,
Robert
..."But I have a slowly coagulating theory that the size of a project is
directly proportional to the possibility that significant bugs will crop
up. Exponentiate for each additional programmer involved." - Steven K.
Halliburton
My public pgp key is available at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1
^ permalink raw reply
* Re: kilauea compilation breaks with v3.3 kernel and ELDK 4.2
From: Josh Boyer @ 2012-03-21 13:29 UTC (permalink / raw)
To: robert.karl.berger; +Cc: linuxppc-dev
In-Reply-To: <4F69C553.6070409@gmail.com>
On Wed, Mar 21, 2012 at 8:10 AM, Robert Berger
<robert.karl.berger@gmail.com> wrote:
> Hi,
>
> Up to 3.2.x I was able to compile a mainline kernel for the kilauea
> board, but...
>
> http://git.denx.de/?p=linux-denx.git;a=commitdiff;h=075bcf5879225d0c2a119c23d8046b890e051e81
>
> shows, that mfdcrx was introduced in the v3.3 kernel.
>
> The problem is that for ppc-linux-gcc (GCC) 4.2.2 (which comes with the
> ELDK 4.2) this assembly instruction is not known and the build breaks.
Sigh. GCC 4.2 is pretty old at this point.
> There are some obvious workarounds, like using a more recent toolchain
> (e.g ELDK 5.x) or use make -k to keep on compiling even when there is an
> error as much as possible;)
That would be the most expedient option, yes.
> What puzzles me is that also stuff for boards is being compiled which is
> not really needed like treeboot-currituck.c even when I configure the
> kernel for a kilauea board.
>
> Is this on purpose and if so why?
All of the stuff in arch/powerpc/boot/ is built regardless of the
configured board and stuffed into a wrapper.a archive. Then the
individual board targets are built and the necessary pieces are pulled
from the wrapper.a file.
> Please advise.
If upgrading ELDK is an option for you, it will get you the quickest
solution. Otherwise we'll need to figure out how to stub out the
instruction in boot/dcr.h and use the asm long trick. Ew. I can look
at that next week.
josh
^ permalink raw reply
* RE: [GIT PULL] DMA-mapping framework updates for 3.4
From: Marek Szyprowski @ 2012-03-21 13:43 UTC (permalink / raw)
To: Marek Szyprowski, 'Linus Torvalds'
Cc: linux-mips, linux-ia64, linux-sh, linux-mm, sparclinux,
linux-arch, 'Jonathan Corbet', x86,
'Arnd Bergmann', microblaze-uclinux, linaro-mm-sig,
Andrzej Pietrasiewicz, 'Thomas Gleixner',
linux-arm-kernel, discuss, linux-kernel,
'FUJITA Tomonori', 'Kyungmin Park', linux-alpha,
'Andrew Morton', linuxppc-dev
In-Reply-To: <1332228283-29077-1-git-send-email-m.szyprowski@samsung.com>
Hello,
On Tuesday, March 20, 2012 8:25 AM Marek Szyprowski wrote:
> Hi Linus,
>
> Please pull the dma-mapping framework updates for v3.4 since commit
> c16fa4f2ad19908a47c63d8fa436a1178438c7e7:
>
> Linux 3.3
>
> with the top-most commit e749a9f707f1102735e02338fa564be86be3bb69
>
> common: DMA-mapping: add NON-CONSISTENT attribute
>
> from the git repository at:
>
> git://git.infradead.org/users/kmpark/linux-samsung dma-mapping-next
>
> Those patches introduce a new alloc method (with support for memory
> attributes) in dma_map_ops structure, which will later replace
> dma_alloc_coherent and dma_alloc_writecombine functions.
I've been pointed out that this summary is quite short and misses the main
rationale for the proposed changes.
A few limitations have been identified in the current dma-mapping design and
its implementations for various architectures. There exist more than one function
for allocating and freeing the buffers: currently these 3 are used dma_{alloc,
free}_coherent, dma_{alloc,free}_writecombine, dma_{alloc,free}_noncoherent.
For most of the systems these calls are almost equivalent and can be interchanged.
For others, especially the truly non-coherent ones (like ARM), the difference can
be easily noticed in overall driver performance. Sadly not all architectures
provide implementations for all of them, so the drivers might need to be adapted
and cannot be easily shared between different architectures. The provided patches
unify all these functions and hide the differences under the already existing
dma attributes concept. The thread with more references is available here:
http://www.spinics.net/lists/linux-sh/msg09777.html
These patches are also a prerequisite for unifying DMA-mapping implementation
on ARM architecture with the common one provided by dma_map_ops structure and
extending it with IOMMU support. More information is available in the following
thread: http://thread.gmane.org/gmane.linux.kernel.cross-arch/12819
More works on dma-mapping framework are planned, especially in the area of buffer
sharing and managing the shared mappings (together with the recently introduced
dma_buf interface: commit d15bd7ee445d0702ad801fdaece348fdb79e6581 "dma-buf:
Introduce dma buffer sharing mechanism" ).
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
^ permalink raw reply
* Re: Please pull 'next' branch of 5xxx tree
From: Stephen Rothwell @ 2012-03-21 14:08 UTC (permalink / raw)
To: Anatolij Gustschin; +Cc: linuxppc-dev
In-Reply-To: <20120321011830.20e20ca0@wker>
[-- Attachment #1: Type: text/plain, Size: 1917 bytes --]
Hi Anatolij,
On Wed, 21 Mar 2012 01:18:30 +0100 Anatolij Gustschin <agust@denx.de> wrote:
>
> Yes. Stephen, could you please change linux-next to pull from my
> mpc5xxx tree
>
> git://git.denx.de/linux-2.6-agust.git next
I have replaced the 52xx-and-virtex tree with this (and called it simply
mpc5xxx). I have also removed the 52xx-and-virtex-current tree.
Thanks for adding your subsystem tree as a participant of linux-next. As
you may know, this is not a judgment of your code. The purpose of
linux-next is for integration testing and to lower the impact of
conflicts between subsystems in the next merge window.
You will need to ensure that the patches/commits in your tree/series have
been:
* submitted under GPL v2 (or later) and include the Contributor's
Signed-off-by,
* posted to the relevant mailing list,
* reviewed by you (or another maintainer of your subsystem tree),
* successfully unit tested, and
* destined for the current or next Linux merge window.
Basically, this should be just what you would send to Linus (or ask him
to fetch). It is allowed to be rebased if you deem it necessary.
--
Cheers,
Stephen Rothwell
sfr@canb.auug.org.au
Legal Stuff:
By participating in linux-next, your subsystem tree contributions are
public and will be included in the linux-next trees. You may be sent
e-mail messages indicating errors or other issues when the
patches/commits from your subsystem tree are merged and tested in
linux-next. These messages may also be cross-posted to the linux-next
mailing list, the linux-kernel mailing list, etc. The linux-next tree
project and IBM (my employer) make no warranties regarding the linux-next
project, the testing procedures, the results, the e-mails, etc. If you
don't agree to these ground rules, let me know and I'll remove your tree
from participation in linux-next.
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: don't call of_platform_bus_probe() twice
From: Kumar Gala @ 2012-03-21 15:08 UTC (permalink / raw)
To: Grant Likely
Cc: Scott Wood, Dmitry Eremin-Solenikov, Timur Tabi,
linuxppc-dev list
In-Reply-To: <20120319160452.B57D13E05A5@localhost>
On Mar 19, 2012, at 11:04 AM, Grant Likely wrote:
> On Fri, 16 Mar 2012 15:50:44 -0500, Timur Tabi <timur@freescale.com> =
wrote:
>> Kumar Gala wrote:
>>=20
>>> This seems like paper taping over the real issue. We should be able =
to call of_platform_bus_probe() multiple times.
>>=20
>> I tried debugging it, but I couldn't figure it out. My guess is that =
the
>> nodes probed by of_platform_bus_probe() are somehow "reserved", so =
that
>> the second time it's called, they're skipped. I figured that this =
was
>> just a side-effect of the way the OF layer works.
>=20
> The problem is that you want to create devices for grandchildren
> nodes when the bus ids passed in don't match any of the child nodes so
> the of_platform_bus_probe() doesn't iterate down to that level. This
> is correct and expected behaviour.
>=20
> g.
Does of_platform_populate() handle this?
- k=
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: don't call of_platform_bus_probe() twice
From: Timur Tabi @ 2012-03-21 15:15 UTC (permalink / raw)
To: Grant Likely; +Cc: Scott Wood, Dmitry Eremin-Solenikov, linuxppc-dev list
In-Reply-To: <4F68BD6F.2090008@freescale.com>
Timur Tabi wrote:
> They only problem I see with this is that I am thinking about modifying
> the drivers/dma driver to probe on "fsl,eloplus-dma-channel" channels
> directly. If I do that, then who should call of_platform_populate()?
Grant, could you tell me if there's anything actually work with my patch?
All I'm doing is adding a couple more commonly used entries to
mpc85xx_common_ids[]. After all, they're common IDs, so don't they belong
into an array called common_ids?
I've been waiting for months for this problem to be fixed, and 3.3 is
broken without it. We've already established that you cannot actually
call of_platform_bus_probe() twice on the same level, so it's not like my
patch description is wrong or anything.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox