* Re: [PATCH v2] powerpc: kernel: remove useless code which related with 'max_cpus'
From: Chen Gang @ 2013-07-25 6:30 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: chenhui.zhao, paulus@samba.org, Srivatsa S. Bhat, Thomas Gleixner,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1374732225.6142.66.camel@pasglop>
On 07/25/2013 02:03 PM, Benjamin Herrenschmidt wrote:
> On Thu, 2013-07-25 at 15:51 +1000, Benjamin Herrenschmidt wrote:
>> On Thu, 2013-07-25 at 13:24 +0800, Chen Gang wrote:
>>> For an extern function, if the performance is not sensible, better to
>>> have the return value which can indicate the failure with the negative
>>> number.
>>
>> The return value is meaningless.
>>
>> We don't have a good way to handle it. It has no defined semantics. What
>> does "failure" means in that case ? Nothing !
>>
>> So just remove it.
>
> Note: If you want to create a concept of smp_ops->probe() failing, then
> not only you need to check all the implementations, but *also* add
> something sensible to do when it fails ... such as disabling bringup of
> CPUs.
>
Hmm... if critical, use BUG(), else (none critical), just print a
warning message ?
> In this case however, we have put the burden of doing whatever makes
> sense in the probe() function itself. If can adjust the possible map if
> it fails.
>
Excuse me, my English is not quite well, I guss your meaning is: "it can
be fail in internal implementation, but has no effect with the final
result to caller", is it correct ?
If what I understand is correct, it needn't let caller know about it.
Thanks.
--
Chen Gang
^ permalink raw reply
* Re: [PATCH v2] powerpc: kernel: remove useless code which related with 'max_cpus'
From: Chen Gang @ 2013-07-25 6:17 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: chenhui.zhao, paulus@samba.org, Srivatsa S. Bhat, Thomas Gleixner,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1374731505.6142.64.camel@pasglop>
On 07/25/2013 01:51 PM, Benjamin Herrenschmidt wrote:
> On Thu, 2013-07-25 at 13:24 +0800, Chen Gang wrote:
>> For an extern function, if the performance is not sensible, better to
>> have the return value which can indicate the failure with the negative
>> number.
>
> The return value is meaningless.
>
> We don't have a good way to handle it. It has no defined semantics. What
> does "failure" means in that case ? Nothing !
>
> So just remove it.
>
Hmm... for an extern function (espeically have been implemented in
various modules), normally, we can assume it may fail in some cases
(although now, we don't know what cases can cause its failure).
If "we don't have a good way to handle the failure", "print the related
warning message" is an executable choice (or "BUG_ON()", if it is critical).
So, if the performance is not sensible, I still suggest to let extern
function have return value.
Thanks.
--
Chen Gang
^ permalink raw reply
* Re: Inbound PCI and Memory Corruption
From: Peter LaDow @ 2013-07-25 6:13 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1374703722.6142.5.camel@pasglop>
On Wed, Jul 24, 2013 at 3:08 PM, Benjamin Herrenschmidt
<benh@au1.ibm.com> wrote:
> No, they resolve to the same thing under the hood. Did you do other
> changes ? Could it be another unrelated kernel bug causing something
> like use-after-free of network buffer or similar oddity unrelated to the
> network driver ?
There are other items, such as drivers for our custom hardware modules
implemented on the FPGA. Perhaps I'll pull our drivers and run a
stock kernel. Maybe a stock 83xx configuration (such as the
MPC8349E-MITX). If we have problems even on a stock configuration...
> Have you tried with different kernel versions ?
Funny you mention it. I just tried 3.10.2 today and we still get the
same memory corruption. I was hoping that perhaps something had
changed between 3.0 and 3.10 that might clear up the problem, and then
I could bisect to find where it failed. But unfortunately, 3.10.2
exhibits the same issue.
So clearly this isn't an issue specific to the kernel version. Though
the e1000 driver looks largely unchanged in 3.10. So if the problem
is driver related, it would still be there.
Thanks,
Pete
^ permalink raw reply
* Re: [PATCH v2] powerpc: kernel: remove useless code which related with 'max_cpus'
From: Benjamin Herrenschmidt @ 2013-07-25 6:03 UTC (permalink / raw)
To: Chen Gang
Cc: chenhui.zhao, paulus@samba.org, Srivatsa S. Bhat, Thomas Gleixner,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1374731505.6142.64.camel@pasglop>
On Thu, 2013-07-25 at 15:51 +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2013-07-25 at 13:24 +0800, Chen Gang wrote:
> > For an extern function, if the performance is not sensible, better to
> > have the return value which can indicate the failure with the negative
> > number.
>
> The return value is meaningless.
>
> We don't have a good way to handle it. It has no defined semantics. What
> does "failure" means in that case ? Nothing !
>
> So just remove it.
Note: If you want to create a concept of smp_ops->probe() failing, then
not only you need to check all the implementations, but *also* add
something sensible to do when it fails ... such as disabling bringup of
CPUs.
In this case however, we have put the burden of doing whatever makes
sense in the probe() function itself. If can adjust the possible map if
it fails.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v2] powerpc: kernel: remove useless code which related with 'max_cpus'
From: Benjamin Herrenschmidt @ 2013-07-25 5:51 UTC (permalink / raw)
To: Chen Gang
Cc: chenhui.zhao, paulus@samba.org, Srivatsa S. Bhat, Thomas Gleixner,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <51F0B68F.4000402@asianux.com>
On Thu, 2013-07-25 at 13:24 +0800, Chen Gang wrote:
> For an extern function, if the performance is not sensible, better to
> have the return value which can indicate the failure with the negative
> number.
The return value is meaningless.
We don't have a good way to handle it. It has no defined semantics. What
does "failure" means in that case ? Nothing !
So just remove it.
Ben.
^ permalink raw reply
* Re: [PATCH v2] powerpc: kernel: remove useless code which related with 'max_cpus'
From: Chen Gang @ 2013-07-25 5:24 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: chenhui.zhao, paulus@samba.org, Srivatsa S. Bhat, Thomas Gleixner,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1374729381.6142.59.camel@pasglop>
On 07/25/2013 01:16 PM, Benjamin Herrenschmidt wrote:
> On Thu, 2013-07-25 at 13:15 +1000, Michael Ellerman wrote:
>>> But for API (also include the internal API), at least, better to always
>>> provide the return value which can indicate failure by negative number
>>> (if succeed can return the meanness value, e.g. the number of cpus).
>>
>> Are we still talking about this?
>>
>> There is no point returning a value when no one checks it. Which is the
>> case here.
>
> Right. The return value is historical, it dates from when we didn't have
> cpu_possible_mask etc...
>
> Nowadays, the probe() routine is just some early init, and might also
> affect those masks if needed, the return value has become obsolete.
>
> You are welcome to post a patch removing it.
>
For an extern function, if the performance is not sensible, better to
have the return value which can indicate the failure with the negative
number.
Thanks.
--
Chen Gang
^ permalink raw reply
* Re: [PATCH v2] powerpc: kernel: remove useless code which related with 'max_cpus'
From: Benjamin Herrenschmidt @ 2013-07-25 5:16 UTC (permalink / raw)
To: Michael Ellerman
Cc: chenhui.zhao, Chen Gang, paulus@samba.org, Srivatsa S. Bhat,
Thomas Gleixner, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20130725031501.GA15673@concordia>
On Thu, 2013-07-25 at 13:15 +1000, Michael Ellerman wrote:
> > But for API (also include the internal API), at least, better to always
> > provide the return value which can indicate failure by negative number
> > (if succeed can return the meanness value, e.g. the number of cpus).
>
> Are we still talking about this?
>
> There is no point returning a value when no one checks it. Which is the
> case here.
Right. The return value is historical, it dates from when we didn't have
cpu_possible_mask etc...
Nowadays, the probe() routine is just some early init, and might also
affect those masks if needed, the return value has become obsolete.
You are welcome to post a patch removing it.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] of: Feed entire flattened device tree into the random pool
From: David Gibson @ 2013-07-25 4:42 UTC (permalink / raw)
To: Anton Blanchard
Cc: devicetree, Rob Herring, Paul Mackerras, Grant Likely,
linuxppc-dev
In-Reply-To: <20130725143031.16af0a96@kryten>
[-- Attachment #1: Type: text/plain, Size: 662 bytes --]
On Thu, Jul 25, 2013 at 02:30:31PM +1000, Anton Blanchard wrote:
>
> Hi Michael,
>
> > But why not put the initcall in drivers/of/fdt.c, that way it's not
> > early but it's still common ?
>
> Good idea! How does this look? So long as it happens before
> module_init(rand_initialize) we should be good.
This must be some strange new meaning of the word "random" of which I
was not previously aware. But I guess it's marginally better than
nothing.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [PATCH] of: Feed entire flattened device tree into the random pool
From: Anton Blanchard @ 2013-07-25 4:30 UTC (permalink / raw)
To: Michael Ellerman
Cc: devicetree, Rob Herring, Paul Mackerras, Grant Likely,
linuxppc-dev
In-Reply-To: <20130725031717.GB15673@concordia>
Hi Michael,
> But why not put the initcall in drivers/of/fdt.c, that way it's not
> early but it's still common ?
Good idea! How does this look? So long as it happens before
module_init(rand_initialize) we should be good.
Anton
--
We feed the entire DMI table into the random pool to provide
better random data during early boot, so do the same with the
flattened device tree.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
v2: move to drivers/of/fdt.c as suggested by Michael Ellerman
Index: b/drivers/of/fdt.c
===================================================================
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -17,6 +17,7 @@
#include <linux/string.h>
#include <linux/errno.h>
#include <linux/slab.h>
+#include <linux/random.h>
#include <asm/setup.h> /* for COMMAND_LINE_SIZE */
#ifdef CONFIG_PPC
@@ -714,3 +715,14 @@ void __init unflatten_device_tree(void)
}
#endif /* CONFIG_OF_EARLY_FLATTREE */
+
+/* Feed entire flattened device tree into the random pool */
+static int __init add_fdt_randomness(void)
+{
+ if (initial_boot_params)
+ add_device_randomness(initial_boot_params,
+ initial_boot_params->totalsize);
+
+ return 0;
+}
+core_initcall(add_fdt_randomness);
^ permalink raw reply
* Re: [PATCH v2] powerpc: kernel: remove useless code which related with 'max_cpus'
From: Chen Gang @ 2013-07-25 4:02 UTC (permalink / raw)
To: Michael Ellerman
Cc: linuxppc-dev@lists.ozlabs.org, Thomas Gleixner, paulus@samba.org,
chenhui.zhao, Srivatsa S. Bhat
In-Reply-To: <20130725031501.GA15673@concordia>
On 07/25/2013 11:15 AM, Michael Ellerman wrote:
> On Wed, Jul 24, 2013 at 10:09:33AM +0800, Chen Gang wrote:
>> > On 07/24/2013 09:16 AM, Michael Ellerman wrote:
>>> > > On Wed, Jul 24, 2013 at 08:28:07AM +0800, Chen Gang wrote:
>>>>> > >> > On 07/23/2013 09:44 PM, Michael Ellerman wrote:
>>>>>>> > >>> > > On Mon, Jul 22, 2013 at 12:21:16PM +0530, Srivatsa S. Bhat wrote:
>>>>>>>>> > >>>> > >> On 07/22/2013 12:10 PM, Chen Gang wrote:
>>>>>>>>>>> > >>>>> > >>> Since not need 'max_cpus' after the related commit, the related code
>>>>>>>>>>> > >>>>> > >>> are useless too, need be removed.
>>>>>>> > >>> > >
>>>>>>> > >>> > > A good follow up patch, or actually series of patches, would be to
>>>>>>> > >>> > > change the prototype of smp_ops->probe() to return void, and fix all the
>>>>>>> > >>> > > implementations to no longer return anything.
>>>>>>> > >>> > >
>>>>> > >> >
>>>>> > >> > Hmm... normally, a function need have a return value, it will make it
>>>>> > >> > more extensible (especially, it is an API which need be implemented in
>>>>> > >> > various sub modules).
>>> > > A function doesn't need a return value, and if it needs one in future then
>>> > > we'll add it then. We don't carry code around "just in case".
>> >
>> > But for API (also include the internal API), at least, better to always
>> > provide the return value which can indicate failure by negative number
>> > (if succeed can return the meanness value, e.g. the number of cpus).
> Are we still talking about this?
>
> There is no point returning a value when no one checks it. Which is the
> case here.
>
> For a published API maybe it's a good idea to have a return value "just
> in case", but this is kernel internal and we own both the implementation
> and the callers of the API.
>
API is between caller and callee, but independent with who will use it
and who will implement it (may be they are the same member), and also
independent with whether "between kernel and user" or not.
Today, you are really the member for both caller and callee, but in the
future, may not.
For our case, it is really an API, it is defined in upper level, and
implement in various sub modules (extern the declaration and implement
in various sub modules).
>>>>> > >> > Even though the return value may be useless, now, if the performance is
>>>>> > >> > not quite important in our case, I still suggest to have it (especially
>>>>> > >> > each various original implementation already has it).
>>> > > It's dead code, it should be removed.
>> >
>> > For API, if not cause the real world issue, better to keep compatible
>> > (especially, the return value still can indicate failure by negative
>> > number).
> No. Dead code is a real world issue. If we ever need a return value
> we'll add one then.
Hmm... what my original saying "real world issue" is not precise, it
need change to: "if it is not an 'urgent' issue (may be a real world
issue), for API, need still keep it compatible (keep no touch) now".
"dead code for an API" does not belong to 'urgent' issue, it belongs to
'important' issue. When we are reconstructing the source code, we can
also remove them in that window (at least, it does not often happen).
(although for our case, I don't think "return value for API" is "dead
code for an API")
Thanks.
--
Chen Gang
^ permalink raw reply
* Re: [PATCH] powerpc: Feed entire flattened device tree into the random pool
From: Michael Ellerman @ 2013-07-25 3:17 UTC (permalink / raw)
To: Anton Blanchard
Cc: devicetree, Rob Herring, Paul Mackerras, Grant Likely,
linuxppc-dev
In-Reply-To: <20130725125122.78accf44@kryten>
On Thu, Jul 25, 2013 at 12:51:22PM +1000, Anton Blanchard wrote:
>
> We feed the entire DMI table into the random pool to provide
> better random data during early boot, so do the same with the
> flattened device tree.
>
> Signed-off-by: Anton Blanchard <anton@samba.org>
> ---
>
> It might be worth doing this somewhere common, but the only place
> I could find (unflatten_device_tree) is almost certainly too
> early in the boot process.
Nice.
But why not put the initcall in drivers/of/fdt.c, that way it's not
early but it's still common ?
cheers
^ permalink raw reply
* Re: [PATCH v2] powerpc: kernel: remove useless code which related with 'max_cpus'
From: Michael Ellerman @ 2013-07-25 3:15 UTC (permalink / raw)
To: Chen Gang
Cc: linuxppc-dev@lists.ozlabs.org, Thomas Gleixner, paulus@samba.org,
chenhui.zhao, Srivatsa S. Bhat
In-Reply-To: <51EF375D.9060006@asianux.com>
On Wed, Jul 24, 2013 at 10:09:33AM +0800, Chen Gang wrote:
> On 07/24/2013 09:16 AM, Michael Ellerman wrote:
> > On Wed, Jul 24, 2013 at 08:28:07AM +0800, Chen Gang wrote:
> >> > On 07/23/2013 09:44 PM, Michael Ellerman wrote:
> >>> > > On Mon, Jul 22, 2013 at 12:21:16PM +0530, Srivatsa S. Bhat wrote:
> >>>> > >> On 07/22/2013 12:10 PM, Chen Gang wrote:
> >>>>> > >>> Since not need 'max_cpus' after the related commit, the related code
> >>>>> > >>> are useless too, need be removed.
> >>> > >
> >>> > > A good follow up patch, or actually series of patches, would be to
> >>> > > change the prototype of smp_ops->probe() to return void, and fix all the
> >>> > > implementations to no longer return anything.
> >>> > >
> >> >
> >> > Hmm... normally, a function need have a return value, it will make it
> >> > more extensible (especially, it is an API which need be implemented in
> >> > various sub modules).
> > A function doesn't need a return value, and if it needs one in future then
> > we'll add it then. We don't carry code around "just in case".
>
> But for API (also include the internal API), at least, better to always
> provide the return value which can indicate failure by negative number
> (if succeed can return the meanness value, e.g. the number of cpus).
Are we still talking about this?
There is no point returning a value when no one checks it. Which is the
case here.
For a published API maybe it's a good idea to have a return value "just
in case", but this is kernel internal and we own both the implementation
and the callers of the API.
> >> > Even though the return value may be useless, now, if the performance is
> >> > not quite important in our case, I still suggest to have it (especially
> >> > each various original implementation already has it).
> > It's dead code, it should be removed.
>
> For API, if not cause the real world issue, better to keep compatible
> (especially, the return value still can indicate failure by negative
> number).
No. Dead code is a real world issue. If we ever need a return value
we'll add one then.
cheers
^ permalink raw reply
* [PATCH] powerpc: Feed entire flattened device tree into the random pool
From: Anton Blanchard @ 2013-07-25 2:51 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Grant Likely, Rob Herring
Cc: devicetree, linuxppc-dev
We feed the entire DMI table into the random pool to provide
better random data during early boot, so do the same with the
flattened device tree.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
It might be worth doing this somewhere common, but the only place
I could find (unflatten_device_tree) is almost certainly too
early in the boot process.
diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
index 63d051f..6914851 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -35,6 +35,7 @@
#include <linux/percpu.h>
#include <linux/memblock.h>
#include <linux/of_platform.h>
+#include <linux/random.h>
#include <asm/io.h>
#include <asm/paca.h>
#include <asm/prom.h>
@@ -752,3 +753,13 @@ void arch_setup_pdev_archdata(struct platform_device *pdev)
pdev->dev.dma_mask = &pdev->archdata.dma_mask;
set_dma_ops(&pdev->dev, &dma_direct_ops);
}
+
+/* Feed entire flattened device tree into the random pool */
+static int __init add_fdt_randomness(void)
+{
+ add_device_randomness(initial_boot_params,
+ initial_boot_params->totalsize);
+
+ return 0;
+}
+core_initcall(add_fdt_randomness);
^ permalink raw reply related
* Re: [PATCH] powerpc/pmac: Early debug output on screen on 64-bit macs
From: Benjamin Herrenschmidt @ 2013-07-25 2:49 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1374718352.6142.48.camel@pasglop>
On Thu, 2013-07-25 at 12:12 +1000, Benjamin Herrenschmidt wrote:
> --- a/arch/powerpc/kernel/setup_64.c
> +++ b/arch/powerpc/kernel/setup_64.c
> @@ -10,7 +10,7 @@
> * 2 of the License, or (at your option) any later version.
> */
>
> -#undef DEBUG
> +#define DEBUG
Ooops... sent the wrong version. Will send an updated one later,
if there are no other comments.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v5 4/4] DMA: Freescale: eliminate a compiling warning
From: Hongbo Zhang @ 2013-07-25 2:46 UTC (permalink / raw)
To: Scott Wood; +Cc: devicetree, vinod.koul, linux-kernel, djbw, linuxppc-dev
In-Reply-To: <1374694411.15592.63@snotra>
On 07/25/2013 03:33 AM, Scott Wood wrote:
> On 07/24/2013 01:21:09 AM, hongbo.zhang@freescale.com wrote:
>> From: Hongbo Zhang <hongbo.zhang@freescale.com>
>>
>> The variable cookie is initialized in a list_for_each_entry loop,
>> if(unlikely)
>> the list is empty, this variable will be used uninitialized, so we
>> get a gcc
>> compiling warning about this. This patch fixes this defect by setting an
>> initial value to the varialble cookie.
>>
>> Signed-off-by: Hongbo Zhang <hongbo.zhang@freescale.com>
>> ---
>> drivers/dma/fsldma.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
>> index 16a9a48..14d68a4 100644
>> --- a/drivers/dma/fsldma.c
>> +++ b/drivers/dma/fsldma.c
>> @@ -406,7 +406,7 @@ static dma_cookie_t fsl_dma_tx_submit(struct
>> dma_async_tx_descriptor *tx)
>> struct fsl_desc_sw *desc = tx_to_fsl_desc(tx);
>> struct fsl_desc_sw *child;
>> unsigned long flags;
>> - dma_cookie_t cookie;
>> + dma_cookie_t cookie = 0;
>>
>> spin_lock_irqsave(&chan->desc_lock, flags);
>
> This patch is unrelated to the rest of the patch series...
>
> What are the semantics of this function if there are multiple entries
> in the list? Returning the last cookie seems a bit odd.
>
> Is zero the proper error value? include/linux/dmaengine.h suggests
> that cookies should be < 0 to indicate error.
I found this compiling warning since the beginning of this work, it is
better somebody fixes it sooner or later, so I take it at last.
Yes it was a bit hard to define the initial value, I saw the
dmaengine.h, and I searched all the other DMA drivers with initial value
before making the decision:
drivers/dma/mv_xor.c: dma_cookie_t cookie = 0;
drivers/dma/sh/shdma-base.c: dma_cookie_t cookie = 0;
drivers/dma/mmp_pdma.c: dma_cookie_t cookie = -EBUSY;
drivers/dma/ppc4xx/adma.c: dma_cookie_t cookie = 0;
drivers/dma/iop-adma.c: dma_cookie_t cookie = 0;
most of them using 0, and only one negative value, it seems better? but
-EBUSY isn't so accurate I think.
My thought is to drop this in the next iteration, and back to this after
the first 3 get merged.
>
> -Scott
^ permalink raw reply
* [PATCH] powerpc/pmac: Early debug output on screen on 64-bit macs
From: Benjamin Herrenschmidt @ 2013-07-25 2:12 UTC (permalink / raw)
To: linuxppc-dev
We have a bunch of CONFIG_PPC_EARLY_DEBUG_* options that are intended
for bringup/debug only. They hard wire a machine specific udbg backend
very early on (before we even probe the platform), and use whatever
tricks are available on each machine/cpu to be able to get some kind
of output out there early on.
So far, on powermac with no serial ports, we have CONFIG_PPC_EARLY_DEBUG_BOOTX
to use the low-level btext engine on the screen, but it doesn't do much, at
least on 64-bit. It only really gets enabled after the platform has been
probed and the MMU enabled.
This adds a way to enable it much earlier. From prom_init.c (while still
running with Open Firmware), we grab the screen details and set things up
using the physical address of the frame buffer.
Then btext itself uses the "rm_ci" feature of the 970 processor (Real
Mode Cache Inhibited) to access it while in real mode.
We need to do a little bit of reorg of the btext code to inline things
better, in order to limit how much we touch memory while in this mode as
the consequences might be ... interesting.
This successfully allowed me to debug problems early on with the G5
(related to gold being broken vs. ppc64 kernels).
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
diff --git a/arch/powerpc/include/asm/btext.h b/arch/powerpc/include/asm/btext.h
index 906f46e..89fc382 100644
--- a/arch/powerpc/include/asm/btext.h
+++ b/arch/powerpc/include/asm/btext.h
@@ -13,6 +13,7 @@ extern void btext_update_display(unsigned long phys, int width, int height,
extern void btext_setup_display(int width, int height, int depth, int pitch,
unsigned long address);
extern void btext_prepare_BAT(void);
+extern void btext_map(void);
extern void btext_unmap(void);
extern void btext_drawchar(char c);
diff --git a/arch/powerpc/kernel/btext.c b/arch/powerpc/kernel/btext.c
index ac8f527..0428992 100644
--- a/arch/powerpc/kernel/btext.c
+++ b/arch/powerpc/kernel/btext.c
@@ -25,11 +25,6 @@
static void scrollscreen(void);
#endif
-static void draw_byte(unsigned char c, long locX, long locY);
-static void draw_byte_32(unsigned char *bits, unsigned int *base, int rb);
-static void draw_byte_16(unsigned char *bits, unsigned int *base, int rb);
-static void draw_byte_8(unsigned char *bits, unsigned int *base, int rb);
-
#define __force_data __attribute__((__section__(".data")))
static int g_loc_X __force_data;
@@ -52,6 +47,26 @@ static unsigned char vga_font[cmapsz];
int boot_text_mapped __force_data = 0;
int force_printk_to_btext = 0;
+extern void rmci_on(void);
+extern void rmci_off(void);
+
+static inline void rmci_maybe_on(void)
+{
+#ifdef CONFIG_PPC_EARLY_DEBUG_BOOTX
+ if (!(mfmsr() & MSR_DR))
+ rmci_on();
+#endif
+}
+
+static inline void rmci_maybe_off(void)
+{
+#ifdef CONFIG_PPC_EARLY_DEBUG_BOOTX
+ if (!(mfmsr() & MSR_DR))
+ rmci_off();
+#endif
+}
+
+
#ifdef CONFIG_PPC32
/* Calc BAT values for mapping the display and store them
* in disp_BAT. Those values are then used from head.S to map
@@ -134,7 +149,7 @@ void __init btext_unmap(void)
* changes.
*/
-static void map_boot_text(void)
+void btext_map(void)
{
unsigned long base, offset, size;
unsigned char *vbase;
@@ -209,7 +224,7 @@ int btext_initialize(struct device_node *np)
dispDeviceRect[2] = width;
dispDeviceRect[3] = height;
- map_boot_text();
+ btext_map();
return 0;
}
@@ -283,7 +298,7 @@ void btext_update_display(unsigned long phys, int width, int height,
iounmap(logicalDisplayBase);
boot_text_mapped = 0;
}
- map_boot_text();
+ btext_map();
g_loc_X = 0;
g_loc_Y = 0;
g_max_loc_X = width / 8;
@@ -298,6 +313,7 @@ void btext_clearscreen(void)
(dispDeviceDepth >> 3)) >> 2;
int i,j;
+ rmci_maybe_on();
for (i=0; i<(dispDeviceRect[3] - dispDeviceRect[1]); i++)
{
unsigned int *ptr = base;
@@ -305,6 +321,7 @@ void btext_clearscreen(void)
*(ptr++) = 0;
base += (dispDeviceRowBytes >> 2);
}
+ rmci_maybe_off();
}
void btext_flushscreen(void)
@@ -355,6 +372,8 @@ static void scrollscreen(void)
(dispDeviceDepth >> 3)) >> 2;
int i,j;
+ rmci_maybe_on();
+
for (i=0; i<(dispDeviceRect[3] - dispDeviceRect[1] - 16); i++)
{
unsigned int *src_ptr = src;
@@ -371,9 +390,116 @@ static void scrollscreen(void)
*(dst_ptr++) = 0;
dst += (dispDeviceRowBytes >> 2);
}
+
+ rmci_maybe_off();
}
#endif /* ndef NO_SCROLL */
+static unsigned int expand_bits_8[16] = {
+ 0x00000000,
+ 0x000000ff,
+ 0x0000ff00,
+ 0x0000ffff,
+ 0x00ff0000,
+ 0x00ff00ff,
+ 0x00ffff00,
+ 0x00ffffff,
+ 0xff000000,
+ 0xff0000ff,
+ 0xff00ff00,
+ 0xff00ffff,
+ 0xffff0000,
+ 0xffff00ff,
+ 0xffffff00,
+ 0xffffffff
+};
+
+static unsigned int expand_bits_16[4] = {
+ 0x00000000,
+ 0x0000ffff,
+ 0xffff0000,
+ 0xffffffff
+};
+
+
+static void draw_byte_32(unsigned char *font, unsigned int *base, int rb)
+{
+ int l, bits;
+ int fg = 0xFFFFFFFFUL;
+ int bg = 0x00000000UL;
+
+ for (l = 0; l < 16; ++l)
+ {
+ bits = *font++;
+ base[0] = (-(bits >> 7) & fg) ^ bg;
+ base[1] = (-((bits >> 6) & 1) & fg) ^ bg;
+ base[2] = (-((bits >> 5) & 1) & fg) ^ bg;
+ base[3] = (-((bits >> 4) & 1) & fg) ^ bg;
+ base[4] = (-((bits >> 3) & 1) & fg) ^ bg;
+ base[5] = (-((bits >> 2) & 1) & fg) ^ bg;
+ base[6] = (-((bits >> 1) & 1) & fg) ^ bg;
+ base[7] = (-(bits & 1) & fg) ^ bg;
+ base = (unsigned int *) ((char *)base + rb);
+ }
+}
+
+static inline void draw_byte_16(unsigned char *font, unsigned int *base, int rb)
+{
+ int l, bits;
+ int fg = 0xFFFFFFFFUL;
+ int bg = 0x00000000UL;
+ unsigned int *eb = (int *)expand_bits_16;
+
+ for (l = 0; l < 16; ++l)
+ {
+ bits = *font++;
+ base[0] = (eb[bits >> 6] & fg) ^ bg;
+ base[1] = (eb[(bits >> 4) & 3] & fg) ^ bg;
+ base[2] = (eb[(bits >> 2) & 3] & fg) ^ bg;
+ base[3] = (eb[bits & 3] & fg) ^ bg;
+ base = (unsigned int *) ((char *)base + rb);
+ }
+}
+
+static inline void draw_byte_8(unsigned char *font, unsigned int *base, int rb)
+{
+ int l, bits;
+ int fg = 0x0F0F0F0FUL;
+ int bg = 0x00000000UL;
+ unsigned int *eb = (int *)expand_bits_8;
+
+ for (l = 0; l < 16; ++l)
+ {
+ bits = *font++;
+ base[0] = (eb[bits >> 4] & fg) ^ bg;
+ base[1] = (eb[bits & 0xf] & fg) ^ bg;
+ base = (unsigned int *) ((char *)base + rb);
+ }
+}
+
+static noinline void draw_byte(unsigned char c, long locX, long locY)
+{
+ unsigned char *base = calc_base(locX << 3, locY << 4);
+ unsigned char *font = &vga_font[((unsigned int)c) * 16];
+ int rb = dispDeviceRowBytes;
+
+ rmci_maybe_on();
+ switch(dispDeviceDepth) {
+ case 24:
+ case 32:
+ draw_byte_32(font, (unsigned int *)base, rb);
+ break;
+ case 15:
+ case 16:
+ draw_byte_16(font, (unsigned int *)base, rb);
+ break;
+ case 8:
+ draw_byte_8(font, (unsigned int *)base, rb);
+ break;
+ }
+ rmci_maybe_off();
+}
+
void btext_drawchar(char c)
{
int cline = 0;
@@ -465,107 +591,12 @@ void btext_drawhex(unsigned long v)
btext_drawchar(' ');
}
-static void draw_byte(unsigned char c, long locX, long locY)
-{
- unsigned char *base = calc_base(locX << 3, locY << 4);
- unsigned char *font = &vga_font[((unsigned int)c) * 16];
- int rb = dispDeviceRowBytes;
-
- switch(dispDeviceDepth) {
- case 24:
- case 32:
- draw_byte_32(font, (unsigned int *)base, rb);
- break;
- case 15:
- case 16:
- draw_byte_16(font, (unsigned int *)base, rb);
- break;
- case 8:
- draw_byte_8(font, (unsigned int *)base, rb);
- break;
- }
-}
-
-static unsigned int expand_bits_8[16] = {
- 0x00000000,
- 0x000000ff,
- 0x0000ff00,
- 0x0000ffff,
- 0x00ff0000,
- 0x00ff00ff,
- 0x00ffff00,
- 0x00ffffff,
- 0xff000000,
- 0xff0000ff,
- 0xff00ff00,
- 0xff00ffff,
- 0xffff0000,
- 0xffff00ff,
- 0xffffff00,
- 0xffffffff
-};
-
-static unsigned int expand_bits_16[4] = {
- 0x00000000,
- 0x0000ffff,
- 0xffff0000,
- 0xffffffff
-};
-
-
-static void draw_byte_32(unsigned char *font, unsigned int *base, int rb)
-{
- int l, bits;
- int fg = 0xFFFFFFFFUL;
- int bg = 0x00000000UL;
-
- for (l = 0; l < 16; ++l)
- {
- bits = *font++;
- base[0] = (-(bits >> 7) & fg) ^ bg;
- base[1] = (-((bits >> 6) & 1) & fg) ^ bg;
- base[2] = (-((bits >> 5) & 1) & fg) ^ bg;
- base[3] = (-((bits >> 4) & 1) & fg) ^ bg;
- base[4] = (-((bits >> 3) & 1) & fg) ^ bg;
- base[5] = (-((bits >> 2) & 1) & fg) ^ bg;
- base[6] = (-((bits >> 1) & 1) & fg) ^ bg;
- base[7] = (-(bits & 1) & fg) ^ bg;
- base = (unsigned int *) ((char *)base + rb);
- }
-}
-
-static void draw_byte_16(unsigned char *font, unsigned int *base, int rb)
-{
- int l, bits;
- int fg = 0xFFFFFFFFUL;
- int bg = 0x00000000UL;
- unsigned int *eb = (int *)expand_bits_16;
-
- for (l = 0; l < 16; ++l)
- {
- bits = *font++;
- base[0] = (eb[bits >> 6] & fg) ^ bg;
- base[1] = (eb[(bits >> 4) & 3] & fg) ^ bg;
- base[2] = (eb[(bits >> 2) & 3] & fg) ^ bg;
- base[3] = (eb[bits & 3] & fg) ^ bg;
- base = (unsigned int *) ((char *)base + rb);
- }
-}
-
-static void draw_byte_8(unsigned char *font, unsigned int *base, int rb)
+void __init udbg_init_btext(void)
{
- int l, bits;
- int fg = 0x0F0F0F0FUL;
- int bg = 0x00000000UL;
- unsigned int *eb = (int *)expand_bits_8;
-
- for (l = 0; l < 16; ++l)
- {
- bits = *font++;
- base[0] = (eb[bits >> 4] & fg) ^ bg;
- base[1] = (eb[bits & 0xf] & fg) ^ bg;
- base = (unsigned int *) ((char *)base + rb);
- }
+ /* If btext is enabled, we might have a BAT setup for early display,
+ * thus we do enable some very basic udbg output
+ */
+ udbg_putc = btext_drawchar;
}
static unsigned char vga_font[cmapsz] = {
@@ -913,10 +944,3 @@ static unsigned char vga_font[cmapsz] = {
0x00, 0x00, 0x00, 0x00,
};
-void __init udbg_init_btext(void)
-{
- /* If btext is enabled, we might have a BAT setup for early display,
- * thus we do enable some very basic udbg output
- */
- udbg_putc = btext_drawchar;
-}
diff --git a/arch/powerpc/kernel/misc_64.S b/arch/powerpc/kernel/misc_64.S
index 6820e45..5a29bc5 100644
--- a/arch/powerpc/kernel/misc_64.S
+++ b/arch/powerpc/kernel/misc_64.S
@@ -247,6 +247,37 @@ _GLOBAL(__bswapdi2)
blr
#if defined(CONFIG_PPC_PMAC) || defined(CONFIG_PPC_MAPLE)
+
+_GLOBAL(rmci_on)
+ sync
+ isync
+ li r3,0x100
+ rldicl r3,r3,32,0
+ mfspr r5,SPRN_HID4
+ or r5,r5,r3
+ sync
+ mtspr SPRN_HID4,r5
+ isync
+ slbia
+ isync
+ sync
+ blr
+
+_GLOBAL(rmci_off)
+ sync
+ isync
+ li r3,0x100
+ rldicl r3,r3,32,0
+ mfspr r5,SPRN_HID4
+ andc r5,r5,r3
+ sync
+ mtspr SPRN_HID4,r5
+ isync
+ slbia
+ isync
+ sync
+ blr
+
/*
* Do an IO access in real mode
*/
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index 6079024..57df5cb 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -2082,6 +2082,22 @@ static void __init prom_check_displays(void)
clut[2]) != 0)
break;
#endif /* CONFIG_LOGO_LINUX_CLUT224 */
+
+#ifdef CONFIG_PPC_EARLY_DEBUG_BOOTX
+ if (prom_getprop(node, "linux,boot-display", NULL, 0) !=
+ PROM_ERROR) {
+ u32 width, height, pitch, addr;
+
+ prom_printf("Setting btext !\n");
+ prom_getprop(node, "width", &width, 4);
+ prom_getprop(node, "height", &height, 4);
+ prom_getprop(node, "linebytes", &pitch, 4);
+ prom_getprop(node, "address", &addr, 4);
+ prom_printf("W=%d H=%d LB=%d addr=0x%x\n",
+ width, height, pitch, addr);
+ btext_setup_display(width, height, 8, pitch, addr);
+ }
+#endif /* CONFIG_PPC_EARLY_DEBUG_BOOTX */
}
}
diff --git a/arch/powerpc/kernel/prom_init_check.sh b/arch/powerpc/kernel/prom_init_check.sh
index 3765da6..b0c263d 100644
--- a/arch/powerpc/kernel/prom_init_check.sh
+++ b/arch/powerpc/kernel/prom_init_check.sh
@@ -22,7 +22,8 @@ __secondary_hold_acknowledge __secondary_hold_spinloop __start
strcmp strcpy strlcpy strlen strncmp strstr logo_linux_clut224
reloc_got2 kernstart_addr memstart_addr linux_banner _stext
opal_query_takeover opal_do_takeover opal_enter_rtas opal_secondary_entry
-boot_command_line __prom_init_toc_start __prom_init_toc_end"
+boot_command_line __prom_init_toc_start __prom_init_toc_end
+btext_setup_display"
NM="$1"
OBJ="$2"
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 389fb807..7016a13 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -10,7 +10,7 @@
* 2 of the License, or (at your option) any later version.
*/
-#undef DEBUG
+#define DEBUG
#include <linux/export.h>
#include <linux/string.h>
@@ -237,6 +237,18 @@ void __init early_setup(unsigned long dt_ptr)
reserve_hugetlb_gpages();
DBG(" <- early_setup()\n");
+
+#ifdef CONFIG_PPC_EARLY_DEBUG_BOOTX
+ /*
+ * This needs to be done *last* (after the above DBG() even)
+ *
+ * Right after we return from this function, we turn on the MMU
+ * which means the real-mode access trick that btext does will
+ * no longer work, it needs to switch to using a real MMU
+ * mapping. This call will ensure that it does
+ */
+ btext_map();
+#endif /* CONFIG_PPC_EARLY_DEBUG_BOOTX */
}
#ifdef CONFIG_SMP
^ permalink raw reply related
* [PATCH 2/2 V2] mmc: esdhc: get voltage from dts file
From: Haijun Zhang @ 2013-07-25 0:38 UTC (permalink / raw)
To: linux-mmc, linuxppc-dev
Cc: scottwood, cjb, AFLEMING, Haijun Zhang, cbouatmailru
Add voltage-range support in esdhc of T4, So we can choose
to read voltages from dts file as one optional.
If we can get a valid voltage-range from device node, we use
this voltage as the final voltage support. Else we still read
from capacity or from other provider.
Signed-off-by: Haijun Zhang <haijun.zhang@freescale.com>
Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
---
changes for V2:
- change dev_info to dev_err
- share function in pltfm.c
drivers/mmc/host/sdhci-of-esdhc.c | 1 +
drivers/mmc/host/sdhci-pltfm.c | 32 ++++++++++++++++++++++++++++++++
drivers/mmc/host/sdhci-pltfm.h | 1 +
drivers/mmc/host/sdhci.c | 3 +++
include/linux/mmc/sdhci.h | 1 +
5 files changed, 38 insertions(+)
diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci-of-esdhc.c
index 15039e2..cdfb08b 100644
--- a/drivers/mmc/host/sdhci-of-esdhc.c
+++ b/drivers/mmc/host/sdhci-of-esdhc.c
@@ -304,6 +304,7 @@ static int sdhci_esdhc_probe(struct platform_device *pdev)
return PTR_ERR(host);
sdhci_get_of_property(pdev);
+ sdhci_get_voltage(pdev);
np = pdev->dev.of_node;
if (of_device_is_compatible(np, "fsl,p2020-esdhc")) {
diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/mmc/host/sdhci-pltfm.c
index e2065a4..4682aba 100644
--- a/drivers/mmc/host/sdhci-pltfm.c
+++ b/drivers/mmc/host/sdhci-pltfm.c
@@ -109,10 +109,42 @@ void sdhci_get_of_property(struct platform_device *pdev)
host->mmc->pm_caps |= MMC_PM_WAKE_SDIO_IRQ;
}
}
+
+void sdhci_get_voltage(struct platform_device *pdev)
+{
+ struct sdhci_host *host = platform_get_drvdata(pdev);
+ const u32 *voltage_ranges;
+ int num_ranges, i;
+ struct device_node *np;
+
+ np = pdev->dev.of_node;
+ voltage_ranges = of_get_property(np, "voltage-ranges", &num_ranges);
+ num_ranges = num_ranges / sizeof(*voltage_ranges) / 2;
+ if (!voltage_ranges || !num_ranges) {
+ dev_info(&pdev->dev, "OF: voltage-ranges unspecified\n");
+ return;
+ }
+
+ for (i = 0; i < num_ranges; i++) {
+ const int j = i * 2;
+ u32 mask;
+
+ mask = mmc_vddrange_to_ocrmask(be32_to_cpu(voltage_ranges[j]),
+ be32_to_cpu(voltage_ranges[j + 1]));
+ if (!mask) {
+ dev_err(&pdev->dev,
+ "OF: voltage-range #%d is invalid\n", i);
+ return;
+ }
+ host->ocr_mask |= mask;
+ }
+}
#else
void sdhci_get_of_property(struct platform_device *pdev) {}
+void sdhci_get_voltage(struct platform_device *pdev) {}
#endif /* CONFIG_OF */
EXPORT_SYMBOL_GPL(sdhci_get_of_property);
+EXPORT_SYMBOL_GPL(sdhci_get_voltage);
struct sdhci_host *sdhci_pltfm_init(struct platform_device *pdev,
const struct sdhci_pltfm_data *pdata,
diff --git a/drivers/mmc/host/sdhci-pltfm.h b/drivers/mmc/host/sdhci-pltfm.h
index e15ced79..aba8253 100644
--- a/drivers/mmc/host/sdhci-pltfm.h
+++ b/drivers/mmc/host/sdhci-pltfm.h
@@ -92,6 +92,7 @@ static inline void sdhci_be32bs_writeb(struct sdhci_host *host, u8 val, int reg)
#endif /* CONFIG_MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER */
extern void sdhci_get_of_property(struct platform_device *pdev);
+extern void sdhci_get_voltage(struct platform_device *pdev);
extern struct sdhci_host *sdhci_pltfm_init(struct platform_device *pdev,
const struct sdhci_pltfm_data *pdata,
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index a78bd4f..57541e0 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -3119,6 +3119,9 @@ int sdhci_add_host(struct sdhci_host *host)
SDHCI_MAX_CURRENT_MULTIPLIER;
}
+ if (host->ocr_mask)
+ ocr_avail = host->ocr_mask;
+
mmc->ocr_avail = ocr_avail;
mmc->ocr_avail_sdio = ocr_avail;
if (host->ocr_avail_sdio)
diff --git a/include/linux/mmc/sdhci.h b/include/linux/mmc/sdhci.h
index e3c6a74..3e781b8 100644
--- a/include/linux/mmc/sdhci.h
+++ b/include/linux/mmc/sdhci.h
@@ -171,6 +171,7 @@ struct sdhci_host {
unsigned int ocr_avail_sdio; /* OCR bit masks */
unsigned int ocr_avail_sd;
unsigned int ocr_avail_mmc;
+ u32 ocr_mask; /* available voltages */
wait_queue_head_t buf_ready_int; /* Waitqueue for Buffer Read Ready interrupt */
unsigned int tuning_done; /* Condition flag set when CMD19 succeeds */
--
1.8.0
^ permalink raw reply related
* [PATCH v3] powerpc: VPHN topology change updates all siblings
From: Robert Jennings @ 2013-07-25 1:13 UTC (permalink / raw)
To: linuxppc-dev, Benjamin Herrenschmidt, Paul Mackerras,
Nathan Fontenot, Michael Ellerman, Jan Stancek
When an associativity level change is found for one thread, the
siblings threads need to be updated as well. This is done today
for PRRN in stage_topology_update() but is missing for VPHN in
update_cpu_associativity_changes_mask(). This patch will correctly
update all thread siblings during a topology change.
Without this patch a topology update can result in a CPU in
init_sched_groups_power() getting stuck indefinitely in a loop.
This loop is built in build_sched_groups(). As a result of the thread
moving to a node separate from its siblings the struct sched_group will
have its next pointer set to point to itself rather than the sched_group
struct of the next thread. This happens because we have a domain without
the SD_OVERLAP flag, which is correct, and a topology that doesn't conform
with reality (threads on the same core assigned to different numa nodes).
When this list is traversed by init_sched_groups_power() it will reach
the thread's sched_group structure and loop indefinitely; the cpu will
be stuck at this point.
The bug was exposed when VPHN was enabled in commit b7abef0 (v3.9).
Cc: <stable@vger.kernel.org>
Reported-by: Jan Stancek <jstancek@redhat.com>
Signed-off-by: Robert Jennings <rcj@linux.vnet.ibm.com>
---
v2. cpu_sibling_mask is now defined for UP which fixes that build break.
v3. Corrected with Cc:stable under singed-off-by and improved description
of impact of this issue.
- While re-enabled only in v3.9, hardware VPHN support was available
prior to this. This could be a pervasive issue and should be considered
for the stable tree.
---
arch/powerpc/include/asm/smp.h | 4 +++ arch/powerpc/mm/numa.c |
59 +++++++++++++++++++++++++++++++----------- 2 files changed, 48
insertions(+), 15 deletions(-)
diff --git a/arch/powerpc/include/asm/smp.h b/arch/powerpc/include/asm/smp.h
index ffbaabe..48cfc85 100644
--- a/arch/powerpc/include/asm/smp.h
+++ b/arch/powerpc/include/asm/smp.h
@@ -145,6 +145,10 @@ extern void __cpu_die(unsigned int cpu);
#define smp_setup_cpu_maps()
static inline void inhibit_secondary_onlining(void) {}
static inline void uninhibit_secondary_onlining(void) {}
+static inline const struct cpumask *cpu_sibling_mask(int cpu)
+{
+ return cpumask_of(cpu);
+}
#endif /* CONFIG_SMP */
diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index 0839721..5850798 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -27,6 +27,7 @@
#include <linux/seq_file.h>
#include <linux/uaccess.h>
#include <linux/slab.h>
+#include <asm/cputhreads.h>
#include <asm/sparsemem.h>
#include <asm/prom.h>
#include <asm/smp.h>
@@ -1318,7 +1319,8 @@ static int update_cpu_associativity_changes_mask(void)
}
}
if (changed) {
- cpumask_set_cpu(cpu, changes);
+ cpumask_or(changes, changes, cpu_sibling_mask(cpu));
+ cpu = cpu_last_thread_sibling(cpu);
}
}
@@ -1426,7 +1428,7 @@ static int update_cpu_topology(void *data)
if (!data)
return -EINVAL;
- cpu = get_cpu();
+ cpu = smp_processor_id();
for (update = data; update; update = update->next) {
if (cpu != update->cpu)
@@ -1446,12 +1448,12 @@ static int update_cpu_topology(void *data)
*/
int arch_update_cpu_topology(void)
{
- unsigned int cpu, changed = 0;
+ unsigned int cpu, sibling, changed = 0;
struct topology_update_data *updates, *ud;
unsigned int associativity[VPHN_ASSOC_BUFSIZE] = {0};
cpumask_t updated_cpus;
struct device *dev;
- int weight, i = 0;
+ int weight, new_nid, i = 0;
weight = cpumask_weight(&cpu_associativity_changes_mask);
if (!weight)
@@ -1464,19 +1466,46 @@ int arch_update_cpu_topology(void)
cpumask_clear(&updated_cpus);
for_each_cpu(cpu, &cpu_associativity_changes_mask) {
- ud = &updates[i++];
- ud->cpu = cpu;
- vphn_get_associativity(cpu, associativity);
- ud->new_nid = associativity_to_nid(associativity);
-
- if (ud->new_nid < 0 || !node_online(ud->new_nid))
- ud->new_nid = first_online_node;
+ /*
+ * If siblings aren't flagged for changes, updates list
+ * will be too short. Skip on this update and set for next
+ * update.
+ */
+ if (!cpumask_subset(cpu_sibling_mask(cpu),
+ &cpu_associativity_changes_mask)) {
+ pr_info("Sibling bits not set for associativity "
+ "change, cpu%d\n", cpu);
+ cpumask_or(&cpu_associativity_changes_mask,
+ &cpu_associativity_changes_mask,
+ cpu_sibling_mask(cpu));
+ cpu = cpu_last_thread_sibling(cpu);
+ continue;
+ }
- ud->old_nid = numa_cpu_lookup_table[cpu];
- cpumask_set_cpu(cpu, &updated_cpus);
+ /* Use associativity from first thread for all siblings */
+ vphn_get_associativity(cpu, associativity);
+ new_nid = associativity_to_nid(associativity);
+ if (new_nid < 0 || !node_online(new_nid))
+ new_nid = first_online_node;
+
+ if (new_nid == numa_cpu_lookup_table[cpu]) {
+ cpumask_andnot(&cpu_associativity_changes_mask,
+ &cpu_associativity_changes_mask,
+ cpu_sibling_mask(cpu));
+ cpu = cpu_last_thread_sibling(cpu);
+ continue;
+ }
- if (i < weight)
- ud->next = &updates[i];
+ for_each_cpu(sibling, cpu_sibling_mask(cpu)) {
+ ud = &updates[i++];
+ ud->cpu = sibling;
+ ud->new_nid = new_nid;
+ ud->old_nid = numa_cpu_lookup_table[sibling];
+ cpumask_set_cpu(sibling, &updated_cpus);
+ if (i < weight)
+ ud->next = &updates[i];
+ }
+ cpu = cpu_last_thread_sibling(cpu);
}
stop_machine(update_cpu_topology, &updates[0], &updated_cpus);
--
1.8.1.2
^ permalink raw reply related
* Re: [PATCH] module: ppc64 module CRC relocation fix causes perf issues
From: Benjamin Herrenschmidt @ 2013-07-24 23:14 UTC (permalink / raw)
To: Anton Blanchard
Cc: Neil Horman, Rusty Russell, linux-kernel, Paul Mackerras,
Scott Wood, linuxppc-dev
In-Reply-To: <20130725083427.56e36010@kryten>
On Thu, 2013-07-25 at 08:34 +1000, Anton Blanchard wrote:
> > Apart from the annoying colors, is there anything specific I should
> > be looking for? Some sort of error message, or output that actually
> > makes sense?
>
> Thanks for testing! Ben, I think the patch is good to go.
Sent it yesterday to Linus, it's upstream already :-)
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 04/10] powerpc: Prepare to support kernel handling of IOMMU map/unmap
From: Benjamin Herrenschmidt @ 2013-07-24 23:13 UTC (permalink / raw)
To: Andrew Morton
Cc: Andrea Arcangeli, kvm, Yasuaki Ishimatsu, Alexey Kardashevskiy,
Alexander Graf, kvm-ppc, linux-kernel, linux-mm, Alex Williamson,
Paul Mackerras, Mel Gorman, Martin Schwidefsky, linuxppc-dev,
David Gibson
In-Reply-To: <20130724154301.2af75867c51870fc0c32819b@linux-foundation.org>
On Wed, 2013-07-24 at 15:43 -0700, Andrew Morton wrote:
> For what? The three lines of comment in page-flags.h? ack :)
>
> Manipulating page->_count directly is considered poor form. Don't
> blame us if we break your code ;)
>
> Actually, the manipulation in realmode_get_page() duplicates the
> existing get_page_unless_zero() and the one in realmode_put_page()
> could perhaps be placed in mm.h with a suitable name and some
> documentation. That would improve your form and might protect the code
> from getting broken later on.
Yes, this stuff makes me really nervous :-) If it didn't provide an order
of magnitude performance improvement in KVM I would avoid it but heh...
Alexey, I like having that stuff in generic code.
However the meaning of the words "real mode" can be ambiguous accross
architectures, it might be best to then name it "mmu_off_put_page" to
make things a bit clearer, along with a comment explaining that this is
called in a context where none of the virtual mappings are accessible
(vmalloc, vmemmap, IOs, ...), and that in the case of sparsemem vmemmap
the caller must have taken care of getting the physical address of the
struct page and of ensuring it isn't split accross two vmemmap blocks.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v2] powerpc: VPHN topology change updates all siblings
From: Benjamin Herrenschmidt @ 2013-07-24 22:49 UTC (permalink / raw)
To: Robert Jennings
Cc: stable, Paul Mackerras, Nathan Fontenot, linuxppc-dev,
Jan Stancek
In-Reply-To: <20130724150005.GB13737@linux.vnet.ibm.com>
On Wed, 2013-07-24 at 10:00 -0500, Robert Jennings wrote:
> When an associativity level change is found for one thread, the
> siblings threads need to be updated as well. This is done today
> for PRRN in stage_topology_update() but is missing for VPHN in
> update_cpu_associativity_changes_mask().
>
> All threads should be updated to move to the new node. Without this
> patch, a single thread may be flagged for a topology change, leaving it
> in a different node from its siblings, which is incorrect. This causes
> problems for the scheduler where overlapping scheduler groups are created
> and a loop is formed in those groups.
>
> Signed-off-by: Robert Jennings <rcj@linux.vnet.ibm.com>
> ---
This is big for a CC stable ... Can you be a bit more verbose on what
the consequences are of not having this patch ? Ie, what happens when "a
loop loop is formed in [the scheduler] groups" ?
Also you shouldn't CC stable on the actual patch email. You should add a
CC: <stable@vger.kernel.org> tag along with your Signed-off-by:
Also how far back in stable should this go ?
Cheers,
Ben.
> cpu_sibling_mask is now defined for UP which fixes that build break.
> ---
> arch/powerpc/include/asm/smp.h | 4 +++
> arch/powerpc/mm/numa.c | 59 +++++++++++++++++++++++++++++++-----------
> 2 files changed, 48 insertions(+), 15 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/smp.h b/arch/powerpc/include/asm/smp.h
> index ffbaabe..48cfc85 100644
> --- a/arch/powerpc/include/asm/smp.h
> +++ b/arch/powerpc/include/asm/smp.h
> @@ -145,6 +145,10 @@ extern void __cpu_die(unsigned int cpu);
> #define smp_setup_cpu_maps()
> static inline void inhibit_secondary_onlining(void) {}
> static inline void uninhibit_secondary_onlining(void) {}
> +static inline const struct cpumask *cpu_sibling_mask(int cpu)
> +{
> + return cpumask_of(cpu);
> +}
>
> #endif /* CONFIG_SMP */
>
> diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
> index 0839721..5850798 100644
> --- a/arch/powerpc/mm/numa.c
> +++ b/arch/powerpc/mm/numa.c
> @@ -27,6 +27,7 @@
> #include <linux/seq_file.h>
> #include <linux/uaccess.h>
> #include <linux/slab.h>
> +#include <asm/cputhreads.h>
> #include <asm/sparsemem.h>
> #include <asm/prom.h>
> #include <asm/smp.h>
> @@ -1318,7 +1319,8 @@ static int update_cpu_associativity_changes_mask(void)
> }
> }
> if (changed) {
> - cpumask_set_cpu(cpu, changes);
> + cpumask_or(changes, changes, cpu_sibling_mask(cpu));
> + cpu = cpu_last_thread_sibling(cpu);
> }
> }
>
> @@ -1426,7 +1428,7 @@ static int update_cpu_topology(void *data)
> if (!data)
> return -EINVAL;
>
> - cpu = get_cpu();
> + cpu = smp_processor_id();
>
> for (update = data; update; update = update->next) {
> if (cpu != update->cpu)
> @@ -1446,12 +1448,12 @@ static int update_cpu_topology(void *data)
> */
> int arch_update_cpu_topology(void)
> {
> - unsigned int cpu, changed = 0;
> + unsigned int cpu, sibling, changed = 0;
> struct topology_update_data *updates, *ud;
> unsigned int associativity[VPHN_ASSOC_BUFSIZE] = {0};
> cpumask_t updated_cpus;
> struct device *dev;
> - int weight, i = 0;
> + int weight, new_nid, i = 0;
>
> weight = cpumask_weight(&cpu_associativity_changes_mask);
> if (!weight)
> @@ -1464,19 +1466,46 @@ int arch_update_cpu_topology(void)
> cpumask_clear(&updated_cpus);
>
> for_each_cpu(cpu, &cpu_associativity_changes_mask) {
> - ud = &updates[i++];
> - ud->cpu = cpu;
> - vphn_get_associativity(cpu, associativity);
> - ud->new_nid = associativity_to_nid(associativity);
> -
> - if (ud->new_nid < 0 || !node_online(ud->new_nid))
> - ud->new_nid = first_online_node;
> + /*
> + * If siblings aren't flagged for changes, updates list
> + * will be too short. Skip on this update and set for next
> + * update.
> + */
> + if (!cpumask_subset(cpu_sibling_mask(cpu),
> + &cpu_associativity_changes_mask)) {
> + pr_info("Sibling bits not set for associativity "
> + "change, cpu%d\n", cpu);
> + cpumask_or(&cpu_associativity_changes_mask,
> + &cpu_associativity_changes_mask,
> + cpu_sibling_mask(cpu));
> + cpu = cpu_last_thread_sibling(cpu);
> + continue;
> + }
>
> - ud->old_nid = numa_cpu_lookup_table[cpu];
> - cpumask_set_cpu(cpu, &updated_cpus);
> + /* Use associativity from first thread for all siblings */
> + vphn_get_associativity(cpu, associativity);
> + new_nid = associativity_to_nid(associativity);
> + if (new_nid < 0 || !node_online(new_nid))
> + new_nid = first_online_node;
> +
> + if (new_nid == numa_cpu_lookup_table[cpu]) {
> + cpumask_andnot(&cpu_associativity_changes_mask,
> + &cpu_associativity_changes_mask,
> + cpu_sibling_mask(cpu));
> + cpu = cpu_last_thread_sibling(cpu);
> + continue;
> + }
>
> - if (i < weight)
> - ud->next = &updates[i];
> + for_each_cpu(sibling, cpu_sibling_mask(cpu)) {
> + ud = &updates[i++];
> + ud->cpu = sibling;
> + ud->new_nid = new_nid;
> + ud->old_nid = numa_cpu_lookup_table[sibling];
> + cpumask_set_cpu(sibling, &updated_cpus);
> + if (i < weight)
> + ud->next = &updates[i];
> + }
> + cpu = cpu_last_thread_sibling(cpu);
> }
>
> stop_machine(update_cpu_topology, &updates[0], &updated_cpus);
^ permalink raw reply
* Re: [PATCH 04/10] powerpc: Prepare to support kernel handling of IOMMU map/unmap
From: Andrew Morton @ 2013-07-24 22:43 UTC (permalink / raw)
To: Alexey Kardashevskiy
Cc: Andrea Arcangeli, kvm, Yasuaki Ishimatsu, Alexander Graf, kvm-ppc,
linux-kernel, linux-mm, Alex Williamson, Paul Mackerras,
Mel Gorman, Martin Schwidefsky, linuxppc-dev, David Gibson
In-Reply-To: <51EDE903.6010608@ozlabs.ru>
On Tue, 23 Jul 2013 12:22:59 +1000 Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
> Ping, anyone, please?
ew, you top-posted.
> Ben needs ack from any of MM people before proceeding with this patch. Thanks!
For what? The three lines of comment in page-flags.h? ack :)
Manipulating page->_count directly is considered poor form. Don't
blame us if we break your code ;)
Actually, the manipulation in realmode_get_page() duplicates the
existing get_page_unless_zero() and the one in realmode_put_page()
could perhaps be placed in mm.h with a suitable name and some
documentation. That would improve your form and might protect the code
from getting broken later on.
^ permalink raw reply
* Re: [PATCH] module: ppc64 module CRC relocation fix causes perf issues
From: Anton Blanchard @ 2013-07-24 22:34 UTC (permalink / raw)
To: Scott Wood
Cc: Neil Horman, Rusty Russell, linux-kernel, Paul Mackerras,
linuxppc-dev
In-Reply-To: <1374274770.5357.33@snotra>
Hi Scott,
> I'm not really sure what it's supposed to look like when "perf
> annotate" works. It spits a bunch of unreadable[1]
> dark-blue-on-black assembly code at me, all with "0.00 :" in the left
> column.
>
> Oh, wait -- some lines have "100.00 : " on the left, in
> even-more-unreadable dark-red-on-black.
>
> Apart from the annoying colors, is there anything specific I should
> be looking for? Some sort of error message, or output that actually
> makes sense?
Thanks for testing! Ben, I think the patch is good to go.
Anton
^ permalink raw reply
* Re: Inbound PCI and Memory Corruption
From: Benjamin Herrenschmidt @ 2013-07-24 22:08 UTC (permalink / raw)
To: Peter LaDow; +Cc: linuxppc-dev
In-Reply-To: <CAN8Q1EdAA6ZfYSdTJ6ieZxjuqTF7Cr9Bt6fo2qejbtXoZ=ce6g@mail.gmail.com>
On Wed, 2013-07-24 at 08:39 -0700, Peter LaDow wrote:
> A bit of history that may help. We were using an e100 (an 82559)
> part, but Intel EOL'd that part so we picked up the 82540EP (which
> they have also recently EOL'd). The e100 driver uses a different DMA
> model. It uses pci_map_single/pci_unmap_single along with
> pci_dma_sync_single_for* calls (as well as other PCI calls). The
> e1000 driver, however, does not use the pci_* calls. We have never
> had a problem with the e100 parts. I don't suppose the use of
> pci_map_* vs dma_map_* makes a difference does it?
No, they resolve to the same thing under the hood. Did you do other
changes ? Could it be another unrelated kernel bug causing something
like use-after-free of network buffer or similar oddity unrelated to the
network driver ?
Have you tried with different kernel versions ?
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 04/11] PCI/hotplug: Needn't remove EEH cache again
From: Benjamin Herrenschmidt @ 2013-07-24 21:47 UTC (permalink / raw)
To: Bjorn Helgaas; +Cc: linux-pci@vger.kernel.org, linuxppc-dev, Gavin Shan
In-Reply-To: <CAErSpo7rXF9vf=BMT1LoLeHPRiyJxT2XWbroRjdt+DH8+4QOnA@mail.gmail.com>
On Wed, 2013-07-24 at 12:02 -0600, Bjorn Helgaas wrote:
> [+cc linux-pci]
>
> On Tue, Jul 23, 2013 at 8:24 PM, Gavin Shan <shangw@linux.vnet.ibm.com> wrote:
> > Since pcibios_release_device() called by pci_stop_and_remove_bus_device()
> > has removed the EEH cache, we needn't do that again.
> >
> > Cc: Bjorn Helgaas <bhelgaas@google.com>
> > Acked-by: Bjorn Helgaas <bhelgaas@google.com>
> > Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
>
> I'll be happy to merge this if you want, or since you have my Ack
> already, you can merge it with the rest of the series. I didn't get
> the rest of the series, so I don't know if it depends on this.
>
> Just let me know what you want me to do.
Already merged :-)
Thanks !
Cheers,
Ben.
> > ---
> > drivers/pci/hotplug/rpadlpar_core.c | 1 -
> > 1 files changed, 0 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/pci/hotplug/rpadlpar_core.c b/drivers/pci/hotplug/rpadlpar_core.c
> > index b29e20b..bb7af78 100644
> > --- a/drivers/pci/hotplug/rpadlpar_core.c
> > +++ b/drivers/pci/hotplug/rpadlpar_core.c
> > @@ -388,7 +388,6 @@ int dlpar_remove_pci_slot(char *drc_name, struct device_node *dn)
> > /* Remove the EADS bridge device itself */
> > BUG_ON(!bus->self);
> > pr_debug("PCI: Now removing bridge device %s\n", pci_name(bus->self));
> > - eeh_remove_bus_device(bus->self, true);
> > pci_stop_and_remove_bus_device(bus->self);
> >
> > return 0;
> > --
> > 1.7.5.4
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ 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