Re: [PATCH] tty/serial/pmac_zilog: Fix "nobody cared" IRQ message
On Sat, Apr 28, 2012 at 06:53:49PM -0500, Larry Finger wrote:
> Following commit a79dd5a titled "tty/serial/pmac_zilog: Fix suspend & resume",
> my Powerbook G4 Titanium showed the following stack dump:
>
> [ 36.878225] irq 23: nobody cared (try booting with the "irqpoll" option)
> [ 36.878251] Call Trace:
> [ 36.878291] [dfff3f00] [c000984c] show_stack+0x7c/0x194 (unreliable)
> [ 36.878322] [dfff3f40] [c00a6868] __report_bad_irq+0x44/0xf4
> [ 36.878339] [dfff3f60] [c00a6b04] note_interrupt+0x1ec/0x2ac
> [ 36.878356] [dfff3f80] [c00a48d0] handle_irq_event_percpu+0x250/0x2b8
> [ 36.878372] [dfff3fd0] [c00a496c] handle_irq_event+0x34/0x54
> [ 36.878389] [dfff3fe0] [c00a753c] handle_fasteoi_irq+0xb4/0x124
> [ 36.878412] [dfff3ff0] [c000f5bc] call_handle_irq+0x18/0x28
> [ 36.878428] [deef1f10] [c000719c] do_IRQ+0x114/0x1cc
> [ 36.878446] [deef1f40] [c0015868] ret_from_except+0x0/0x1c
> [ 36.878484] --- Exception: 501 at 0xf497610
> [ 36.878489] LR = 0xfdc3dd0
> [ 36.878497] handlers:
> [ 36.878510] [] pmz_interrupt
> [ 36.878520] Disabling IRQ #23
>
> From an E-mail exchange about this problem, Andreas Schwab noticed a typo
> that resulted in the wrong condition being tested.
>
> The patch also corrects 2 typos that incorrectly report why an error branch
> is being taken.
>
> Signed-off-by: Larry Finger
> ---
>
> Ben,
>
> Any changes you wish to make in the commit message are OK with me.
>
> Larry
> ---
>
> Index: wireless-testing/drivers/tty/serial/pmac_zilog.c
> ===
> --- wireless-testing.orig/drivers/tty/serial/pmac_zilog.c 2012-04-28
> 15:51:38.843723074 -0500
> +++ wireless-testing/drivers/tty/serial/pmac_zilog.c 2012-04-28
> 18:34:34.053900600 -0500
> @@ -469,7 +469,7 @@
> tty = NULL;
> if (r3 & (CHAEXT | CHATxIP | CHARxIP)) {
> if (!ZS_IS_OPEN(uap_a)) {
> - pmz_debug("ChanA interrupt while open !\n");
> + pmz_debug("ChanA interrupt while not open !\n");
Hmm, I'm not a native english speaker, but I have the feeling that
it would be more grammatically correct to use "opened" instead of "open".
Of course if the message never triggers, it's less of concern :-)
> goto skip_a;
> }
> write_zsreg(uap_a, R0, RES_H_IUS);
> @@ -493,8 +493,8 @@
> spin_lock(&uap_b->port.lock);
> tty = NULL;
> if (r3 & (CHBEXT | CHBTxIP | CHBRxIP)) {
> - if (!ZS_IS_OPEN(uap_a)) {
> - pmz_debug("ChanB interrupt while open !\n");
> + if (!ZS_IS_OPEN(uap_b)) {
> + pmz_debug("ChanB interrupt while not open !\n");
Ditto.
> goto skip_b;
> }
> write_zsreg(uap_b, R0, RES_H_IUS);
Regards,
Gabriel
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH EDACv16 1/2] edac: Change internal representation to work with layers
Em 28-04-2012 06:05, Borislav Petkov escreveu: > On Fri, Apr 27, 2012 at 12:36:12PM -0300, Mauro Carvalho Chehab wrote: >> The fix for it were in another patch[1], as calling them as "rank" is >> needed also at the sysfs API. > > No, this doesn't fix it either: > > [ 10.486440] EDAC MC: DCT0 chip selects: > [ 10.486443] EDAC amd64: MC: 0: 2048MB 1: 2048MB > [ 10.486445] EDAC amd64: MC: 2: 2048MB 3: 2048MB > [ 10.486448] EDAC amd64: MC: 4: 0MB 5: 0MB > [ 10.486450] EDAC amd64: MC: 6: 0MB 7: 0MB > [ 10.486453] EDAC DEBUG: amd64_debug_display_dimm_sizes: F2x180 (DRAM Bank > Address Mapping): 0x0088 > [ 10.486455] EDAC MC: DCT1 chip selects: > [ 10.486458] EDAC amd64: MC: 0: 2048MB 1: 2048MB > [ 10.486460] EDAC amd64: MC: 2: 2048MB 3: 2048MB > [ 10.486463] EDAC amd64: MC: 4: 0MB 5: 0MB > [ 10.486465] EDAC amd64: MC: 6: 0MB 7: 0MB > [ 10.486467] EDAC amd64: using x8 syndromes. > [ 10.486469] EDAC DEBUG: amd64_dump_dramcfg_low: F2x190 (DRAM Cfg Low): > 0x00083100 > [ 10.486472] EDAC DEBUG: amd64_dump_dramcfg_low: DIMM type: buffered; all > DIMMs support ECC: yes > [ 10.486475] EDAC DEBUG: amd64_dump_dramcfg_low: PAR/ERR parity: enabled > [ 10.486478] EDAC DEBUG: amd64_dump_dramcfg_low: DCT 128bit mode width: > 64b > [ 10.486481] EDAC DEBUG: amd64_dump_dramcfg_low: x4 logical DIMMs > present: L0: yes L1: yes L2: no L3: no > [ 10.486485] EDAC DEBUG: f1x_early_channel_count: Data width is not 128 > bits - need more decoding > [ 10.486488] EDAC amd64: MCT channel count: 2 > [ 10.486493] EDAC DEBUG: new_edac_mc_alloc: new_edac_mc_alloc(): allocating > 3692 bytes for mci data (16 ranks, 16 csrows/channels) > [ 10.486501] EDAC DEBUG: new_edac_mc_alloc: new_edac_mc_alloc: 0: rank0 > (0:0:0): row 0, chan 0 > [ 10.486506] EDAC DEBUG: new_edac_mc_alloc: new_edac_mc_alloc: 1: rank1 > (0:1:0): row 0, chan 1 > [ 10.486510] EDAC DEBUG: new_edac_mc_alloc: new_edac_mc_alloc: 2: rank2 > (1:0:0): row 1, chan 0 > [ 10.486514] EDAC DEBUG: new_edac_mc_alloc: new_edac_mc_alloc: 3: rank3 > (1:1:0): row 1, chan 1 > [ 10.486518] EDAC DEBUG: new_edac_mc_alloc: new_edac_mc_alloc: 4: rank4 > (2:0:0): row 2, chan 0 > [ 10.486522] EDAC DEBUG: new_edac_mc_alloc: new_edac_mc_alloc: 5: rank5 > (2:1:0): row 2, chan 1 > [ 10.486526] EDAC DEBUG: new_edac_mc_alloc: new_edac_mc_alloc: 6: rank6 > (3:0:0): row 3, chan 0 > [ 10.486530] EDAC DEBUG: new_edac_mc_alloc: new_edac_mc_alloc: 7: rank7 > (3:1:0): row 3, chan 1 > [ 10.486534] EDAC DEBUG: new_edac_mc_alloc: new_edac_mc_alloc: 8: rank8 > (4:0:0): row 4, chan 0 > [ 10.486538] EDAC DEBUG: new_edac_mc_alloc: new_edac_mc_alloc: 9: rank9 > (4:1:0): row 4, chan 1 > [ 10.486542] EDAC DEBUG: new_edac_mc_alloc: new_edac_mc_alloc: 10: rank10 > (5:0:0): row 5, chan 0 > [ 10.486546] EDAC DEBUG: new_edac_mc_alloc: new_edac_mc_alloc: 11: rank11 > (5:1:0): row 5, chan 1 > [ 10.486550] EDAC DEBUG: new_edac_mc_alloc: new_edac_mc_alloc: 12: rank12 > (6:0:0): row 6, chan 0 > [ 10.486554] EDAC DEBUG: new_edac_mc_alloc: new_edac_mc_alloc: 13: rank13 > (6:1:0): row 6, chan 1 > [ 10.486558] EDAC DEBUG: new_edac_mc_alloc: new_edac_mc_alloc: 14: rank14 > (7:0:0): row 7, chan 0 > [ 10.486562] EDAC DEBUG: new_edac_mc_alloc: new_edac_mc_alloc: 15: rank15 > (7:1:0): row 7, chan 1 > > DCT0 has 4 ranks + DCT1 also 4 ranks = 8 ranks total. > > Now your change is showing 16 ranks. Still b0rked. > No, DCT0+DCT1 have 16 ranks, 8 filled and 8 empty. So, it is OK. As I said before when you've pointed this bug (likel at v3 review), edac_mc_alloc doesn't know how many ranks are filled, as the driver logic first calls it to allocate for the max amount of ranks, and then fills the rank with their info (or let them untouched with 0 pages, if they're empty). Regards, Mauro ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH EDACv16 1/2] edac: Change internal representation to work with layers
Em 28-04-2012 14:07, Joe Perches escreveu: > On Sat, 2012-04-28 at 11:16 +0200, Borislav Petkov wrote: >> On Fri, Apr 27, 2012 at 02:52:35PM -0300, Mauro Carvalho Chehab wrote: All those local variables should be sorted in a reverse christmas tree order: u32 this_is_the_longest_array_name[LENGTH]; void *shorter_named_variable; unsigned long size; int i; ... >>> >>> Why? There's nothing at the CodingStyle saying about how the vars should >>> be ordered. If you want to enforce some particular order, please do it >>> yourself, but apply it consistently among the entire subsystem. >> >> First of all, this way it is more readable. > > Not in my opinion, and blindly using "reverse christmas tree" > can separate variables that should be declared together. I agree with Joe. The order won't make the code easier or harder to read, nor it would improve code performance. >> Second of all, maybe we should hold it down in CodingStyle. Different developers have different opinions about how to order includes, functions, vars, etc. So, this is not at CodingStyle because there's no consensus about it, and because this is not relevant for code understanding. A reviewer should not reject a patch just because he doesn't like the order that the developer used. Regards, Mauro ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH EDACv16 1/2] edac: Change internal representation to work with layers
Em 28-04-2012 06:16, Borislav Petkov escreveu:
> On Fri, Apr 27, 2012 at 02:52:35PM -0300, Mauro Carvalho Chehab wrote:
>
>>> Also, is it valid to have n_layers == 0? The memcpy call below
>>> will do nothing.
>>
>> Changed to:
>> BUG_ON(n_layers > EDAC_MAX_LAYERS || n_layers == 0);
>
> Really? Look below.
Weird, not sure what happened here... it seems I sent the version before
this change.
The patch I've made has the correct BUG_ON at:
http://git.infradead.org/users/mchehab/edac.git/commitdiff/447b7929e633027ffe131f2f8f246bba5690cee7
>
>>
+ /*
+ * Calculate the total amount of dimms and csrows/cschannels while
+ * in the old API emulation mode
+ */
+ tot_dimms = 1;
+ tot_cschannels = 1;
+ tot_csrows = 1;
>>>
>>> Those initializations can be done above at variable declaration time.
>>
>> Yes, but the compiled code will be the same anyway, as gcc will optimize
>
> Hey, are you looking at compiled code or at source code? Because I'm
> looking at source code, and it is a pretty safe bet the majority of the
> people here do that too.
What I said is that, from source code POV, a code where the loop variables are
initialized just before the loop is easier to read it when the initialization
of those vars are on another part of the code.
That's basically why the "for" syntax starts with a var initialization clause.
The tot_dimms & friends are loop vars: their value is calculated within the
loop.
At the object code, this won't bring any difference.
>
>> it, either by using registers for those vars or by moving the initialization
>> to the top of the function.
>>
>> This function is too complex, so it is better to initialize those vars
>> just before the loops that are calculating those totals.
>
> Simply initialize those variables at declaration time and that's it.
> Initializing them before the loop doesn't make the function less complex
> - splitting it and sanitizing it does.
Initializing loop-calculated vars just before the loop makes the code easier
to read, and may avoid issues that might happen during code lifecycle.
>
>>>
+ for (i = 0; i < n_layers; i++) {
+ tot_dimms *= layers[i].size;
+ if (layers[i].is_virt_csrow)
+ tot_csrows *= layers[i].size;
+ else
+ tot_cschannels *= layers[i].size;
+ }
>
> [..]
>
>> -struct mem_ctl_info *edac_mc_alloc(unsigned sz_pvt, unsigned nr_csrows,
>> -unsigned nr_chans, int edac_index)
>> +struct mem_ctl_info *new_edac_mc_alloc(unsigned edac_index,
>> + unsigned n_layers,
>> + struct edac_mc_layer *layers,
>> + bool rev_order,
>> + unsigned sz_pvt)
>> {
>> void *ptr = NULL;
>> struct mem_ctl_info *mci;
>> -struct csrow_info *csi, *csrow;
>> +struct edac_mc_layer *layer;
>> +struct csrow_info *csi, *csr;
>> struct rank_info *chi, *chp, *chan;
>> struct dimm_info *dimm;
>> +u32 *ce_per_layer[EDAC_MAX_LAYERS], *ue_per_layer[EDAC_MAX_LAYERS];
>> void *pvt;
>> -unsigned size;
>> -int row, chn;
>> +unsigned size, tot_dimms, count, pos[EDAC_MAX_LAYERS];
>> +unsigned tot_csrows, tot_channels, tot_errcount = 0;
>> +int i, j;
>> int err;
>> +int row, chn;
>> +bool per_rank = false;
>> +
>> +BUG_ON(n_layers > EDAC_MAX_LAYERS);
>
> ^^
>
Let me re-send it, with the right BUG_ON there.
commit 447b7929e633027ffe131f2f8f246bba5690cee7
Author: Mauro Carvalho Chehab
Date: Wed Apr 18 15:20:50 2012 -0300
edac: Change internal representation to work with layers
Change the EDAC internal representation to work with non-csrow
based memory controllers.
There are lots of those memory controllers nowadays, and more
are coming. So, the EDAC internal representation needs to be
changed, in order to work with those memory controllers, while
preserving backward compatibility with the old ones.
The edac core was written with the idea that memory controllers
are able to directly access csrows.
This is not true for FB-DIMM and RAMBUS memory controllers.
Also, some recent advanced memory controllers don't present a per-csrows
view. Instead, they view memories as DIMMs, instead of ranks.
So, change the allocation and error report routines to allow
them to work with all types of architectures.
This will allow the removal of several hacks with FB-DIMM and RAMBUS
memory controllers.
Also, several tests were done on different platforms using different
x86 drivers.
TODO: a multi-rank DIMMs are currently represented by multiple DIMM
entries in struct dimm_info. That means that changing a label for one
rank won't change the same label for the other ranks at the
Re: [PATCH EDACv16 1/2] edac: Change internal representation to work with layers
Em 28-04-2012 05:52, Borislav Petkov escreveu:
> On Fri, Apr 27, 2012 at 01:07:38PM -0300, Mauro Carvalho Chehab wrote:
>> Yes. This is a common issue at the EDAC core: on several places, it calls the
>> edac debug macros (DEBUGF0...DEBUGF4) passing a __func__ as an argument,
>> while
>> the debug macros already handles that. I suspect that, in the past, the
>> __func__
>> were not at the macros, but some patch added it there, and forgot to fix the
>> occurrences of its call.
>
> The patch that added it is d357cbb445208 and you reviewed it.
And you wrote the patch that caused it.
>
>> This is something that needs to be reviewed at the entire EDAC core (and
>> likely
>> at the drivers).
>
> Looks like a job for a newbie to get her/his feet wet with kernel work.
>
>> I opted to not touch on this at the existing debug logic, as I think that the
>> better is to address all those issues on one separate patch, after fixing the
>> EDAC core bugs.
>
> No,
>
> you simply need to remove the __func__ argument in your newly added debug
> call:
>
> debugf2("%s: %d: dimm%zd (%d:%d:%d): row %d, chan %d\n",
> __func__,
> i, (dimm - mci->dimms),
> pos[0], pos[1], pos[2], row, chn);
>
> And while you're at it, remove the rest of the __func__ arguments from
> your newly added debugfX calls.
A single patch fixing this everywhere at drivers/edac is better and clearer
than adding
an unrelated fix on this patch. This is already complex enough to add more
unrelated
things there.
Also, a simple perl/coccinelle script can replace all such __func__ occurrences
on one shot.
Regards,
Mauro
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] tty/serial/pmac_zilog: Fix "nobody cared" IRQ message
On 04/29/2012 04:05 AM, Gabriel Paubert wrote: On Sat, Apr 28, 2012 at 06:53:49PM -0500, Larry Finger wrote: Hmm, I'm not a native english speaker, but I have the feeling that it would be more grammatically correct to use "opened" instead of "open". Of course if the message never triggers, it's less of concern :-) English is my native language, but that might not help. :) I would say "the device has not been opened", but "it is not open". More generally, to me "opened" denotes past tense, and "open" is used in the present. Even with the other bug, the message never triggered as I did not have debugging enabled. Given the relative rarity of PPC-based boxes running Linux, the message may never print. Thanks for the comment. Larry ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH EDACv16 1/2] edac: Change internal representation to work with layers
On Sun, 2012-04-29 at 12:11 -0300, Mauro Carvalho Chehab wrote: > Em 29-04-2012 11:25, Mauro Carvalho Chehab escreveu: > > Em 28-04-2012 05:52, Borislav Petkov escreveu: > >> On Fri, Apr 27, 2012 at 01:07:38PM -0300, Mauro Carvalho Chehab wrote: > >>> Yes. This is a common issue at the EDAC core: on several places, it calls > >>> the > >>> edac debug macros (DEBUGF0...DEBUGF4) passing a __func__ as an argument, > >>> while > >>> the debug macros already handles that. I suspect that, in the past, the > >>> __func__ > >>> were not at the macros, but some patch added it there, and forgot to fix > >>> the > >>> occurrences of its call. > >> The patch that added it is d357cbb445208 and you reviewed it. > > And you wrote the patch that caused it. And Boris should have also written the follow-on patches that removed most/all of the debugfX and __func__ uses. > > A single patch fixing this everywhere at drivers/edac is better and clearer > > than adding > > an unrelated fix on this patch. This is already complex enough to add more > > unrelated > > things there. > > > > Also, a simple perl/coccinelle script can replace all such __func__ > > occurrences > > on one shot. You make it sound simple, but it'd be a pretty complicated cocci script. Some of the changes would have to be inspected or changed by hand in any case. [] > Most of the issues can be solved with the above script-based patch. > > There are still 171 places (12 places at the core, the rest are on the > drivers) > that will require a more sophisticated patch or that requires a manual fix. [] > From: Mauro Carvalho Chehab > Date: Sun, 29 Apr 2012 11:59:14 -0300 > Subject: [PATCH] edac: Don't add __func__ or __FILE__ for debugf[0-9] msgs Thanks Mauro, you shouldn't have had to do this. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] tty/serial/pmac_zilog: Fix "nobody cared" IRQ message
On Sat, 2012-04-28 at 18:53 -0500, Larry Finger wrote:
>
> Index: wireless-testing/drivers/tty/serial/pmac_zilog.c
> ===
> --- wireless-testing.orig/drivers/tty/serial/pmac_zilog.c 2012-04-28
> 15:51:38.843723074 -0500
> +++ wireless-testing/drivers/tty/serial/pmac_zilog.c 2012-04-28
> 18:34:34.053900600 -0500
Patch seems to be wrapped... I'll apply manually this time around but
check your mailer settings :-)
Cheers,
Ben.
> @@ -469,7 +469,7 @@
> tty = NULL;
> if (r3 & (CHAEXT | CHATxIP | CHARxIP)) {
> if (!ZS_IS_OPEN(uap_a)) {
> - pmz_debug("ChanA interrupt while open !\n");
> + pmz_debug("ChanA interrupt while not open !\n");
> goto skip_a;
> }
> write_zsreg(uap_a, R0, RES_H_IUS);
> @@ -493,8 +493,8 @@
> spin_lock(&uap_b->port.lock);
> tty = NULL;
> if (r3 & (CHBEXT | CHBTxIP | CHBRxIP)) {
> - if (!ZS_IS_OPEN(uap_a)) {
> - pmz_debug("ChanB interrupt while open !\n");
> + if (!ZS_IS_OPEN(uap_b)) {
> + pmz_debug("ChanB interrupt while not open !\n");
> goto skip_b;
> }
> write_zsreg(uap_b, R0, RES_H_IUS);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] tty/serial/pmac_zilog: Fix "nobody cared" IRQ message
On 04/29/2012 07:23 PM, Benjamin Herrenschmidt wrote: On Sat, 2012-04-28 at 18:53 -0500, Larry Finger wrote: Index: wireless-testing/drivers/tty/serial/pmac_zilog.c === --- wireless-testing.orig/drivers/tty/serial/pmac_zilog.c 2012-04-28 15:51:38.843723074 -0500 +++ wireless-testing/drivers/tty/serial/pmac_zilog.c2012-04-28 18:34:34.053900600 -0500 Patch seems to be wrapped... I'll apply manually this time around but check your mailer settings :-) Sorry about that. I don't usually send patches that way, and forgot to check for wrapping. Larry ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2] powerpc/powermac: New windfarm driver for PowerMac G5 (AGP) and Xserve G5
This replaces the old therm_pm72 using the same windfarm infrastructure that was used for other PowerMac G5 models. The fan speeds and sensors should now be visible in the same location in sysfs. The driver is split into separate core modules for PowerMac7,2 (and 7,3) and RackMac3,1, with a lot of the shared code now in the separate sensor and control modules. Signed-off-by: Benjamin Herrenschmidt --- v2: - Use programmed value when reading back from FCU (like therm_pm72, behaviour is preferable and appears more in line with what OS X does) - Remove tickle code, it's annoying. Instead, don't compare programmed values with previous values, which means that the normal loops should be enough to keep the FCU from timing out. That also means that it should now be possible to manually program the slots fan from sysfs. drivers/macintosh/Kconfig | 23 +- drivers/macintosh/Makefile | 14 + drivers/macintosh/windfarm.h |3 +- drivers/macintosh/windfarm_core.c | 10 +- drivers/macintosh/windfarm_cpufreq_clamp.c |6 - drivers/macintosh/windfarm_fcu_controls.c | 10 +- drivers/macintosh/windfarm_mpu.h | 105 drivers/macintosh/windfarm_pm72.c | 847 drivers/macintosh/windfarm_rm31.c | 740 9 files changed, 1736 insertions(+), 22 deletions(-) create mode 100644 drivers/macintosh/windfarm_mpu.h create mode 100644 drivers/macintosh/windfarm_pm72.c create mode 100644 drivers/macintosh/windfarm_rm31.c diff --git a/drivers/macintosh/Kconfig b/drivers/macintosh/Kconfig index fa51af1..a555da6 100644 --- a/drivers/macintosh/Kconfig +++ b/drivers/macintosh/Kconfig @@ -204,11 +204,14 @@ config THERM_ADT746X better fan behaviour by default, and some manual control. config THERM_PM72 - tristate "Support for thermal management on PowerMac G5" + tristate "Support for thermal management on PowerMac G5 (AGP)" depends on I2C && I2C_POWERMAC && PPC_PMAC64 + default n help This driver provides thermostat and fan control for the desktop - G5 machines. + G5 machines. + + This is deprecated, use windfarm instead. config WINDFARM tristate "New PowerMac thermal control infrastructure" @@ -221,6 +224,22 @@ config WINDFARM_PM81 help This driver provides thermal control for the iMacG5 +config WINDFARM_PM72 + tristate "Support for thermal management on PowerMac G5 (AGP)" + depends on WINDFARM && I2C && CPU_FREQ_PMAC64 && ADB_PMU + select I2C_POWERMAC + help + This driver provides thermal control for the PowerMac G5 + "AGP" variants (PowerMac 7,2 and 7,3) + +config WINDFARM_RM31 + tristate "Support for thermal management on Xserve G5" + depends on WINDFARM && I2C && CPU_FREQ_PMAC64 && ADB_PMU + select I2C_POWERMAC + help + This driver provides thermal control for the Xserve G5 + (RackMac3,1) + config WINDFARM_PM91 tristate "Support for thermal management on PowerMac9,1" depends on WINDFARM && I2C && CPU_FREQ_PMAC64 && PMAC_SMU diff --git a/drivers/macintosh/Makefile b/drivers/macintosh/Makefile index 6652a6e..6753b65 100644 --- a/drivers/macintosh/Makefile +++ b/drivers/macintosh/Makefile @@ -29,6 +29,20 @@ obj-$(CONFIG_THERM_PM72) += therm_pm72.o obj-$(CONFIG_THERM_WINDTUNNEL) += therm_windtunnel.o obj-$(CONFIG_THERM_ADT746X)+= therm_adt746x.o obj-$(CONFIG_WINDFARM) += windfarm_core.o +obj-$(CONFIG_WINDFARM_PM72) += windfarm_fcu_controls.o \ + windfarm_ad7417_sensor.o \ + windfarm_lm75_sensor.o \ + windfarm_max6690_sensor.o \ + windfarm_pid.o \ + windfarm_cpufreq_clamp.o \ + windfarm_pm72.o +obj-$(CONFIG_WINDFARM_RM31) += windfarm_fcu_controls.o \ + windfarm_ad7417_sensor.o \ + windfarm_lm75_sensor.o \ + windfarm_lm87_sensor.o \ + windfarm_pid.o \ + windfarm_cpufreq_clamp.o \ + windfarm_rm31.o obj-$(CONFIG_WINDFARM_PM81) += windfarm_smu_controls.o \ windfarm_smu_sensors.o \ windfarm_lm75_sensor.o windfarm_pid.o \ diff --git a/drivers/macintosh/windfarm.h b/drivers/macintosh/windfarm.h index a9e385e..028cdac 100644 --- a/drivers/macintosh/windfarm.h +++ b/drivers/macintosh/windfarm.h @@ -17,7 +17,7 @@ #include /* Display a 16.16 fixed point value */ -#define FIX32TOPRINT(f)((f) >> 16),f) & 0x) * 1000) >> 16) +#define FIX32T
[git pull] Please pull powerpc.git merge branch
Hi Linus ! Here are a handful more fixes for powerpc. The irq stuff are all regression fixes, and Gavin's patch is a simple compile fix. Cheers, Ben. The following changes since commit 69964ea4c7b68c9399f7977aa5b9aa6539a6a98a: Linux 3.4-rc5 (2012-04-29 15:19:10 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge for you to fetch changes up to 810b4de25e53459323ff48957b0162b48d6cbd57: tty/serial/pmac_zilog: Fix "nobody cared" IRQ message (2012-04-30 10:59:58 +1000) Gavin Shan (1): powerpc/pseries: Rivet CONFIG_EEH for pSeries platform Grant Likely (2): powerpc/8xx: Fix NR_IRQ bugs and refactor 8xx interrupt controller powerpc/irqdomain: Fix broken NR_IRQ references Larry Finger (1): tty/serial/pmac_zilog: Fix "nobody cared" IRQ message arch/powerpc/include/asm/irq.h |4 -- arch/powerpc/kernel/irq.c|6 +-- arch/powerpc/kernel/machine_kexec.c |7 +-- arch/powerpc/platforms/cell/axon_msi.c |8 ++-- arch/powerpc/platforms/cell/beat_interrupt.c |2 +- arch/powerpc/platforms/powermac/pic.c|6 +-- arch/powerpc/platforms/pseries/Kconfig |4 +- arch/powerpc/sysdev/cpm2_pic.c |3 +- arch/powerpc/sysdev/mpc8xx_pic.c | 61 +- arch/powerpc/sysdev/xics/xics-common.c |7 ++- drivers/tty/serial/pmac_zilog.c |6 +-- 11 files changed, 39 insertions(+), 75 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [REGRESSION][PATCH V4 3/3] bpf jit: Let the powerpc jit handle negative offsets
On Wed, 2012-04-04 at 08:11 +1000, Benjamin Herrenschmidt wrote: > On Tue, 2012-04-03 at 18:03 -0400, David Miller wrote: > > > > Signed-off-by: Jan Seiffert > > > > > > I have only compile tested this, -ENOHARDWARE. > > > Can someone with more powerpc kung-fu review and maybe test this? > > > Esp. powerpc asm is not my strong point. I think i botched the > > > stack frame in the call setup. Help? > > > > I'm not applying this until a powerpc person tests it. > > > > Also, we have an ARM JIT in the tree which probably needs to > > be fixed similarly. > > Matt's having a look at powerpc Ok, he hasn't so I'll dig a bit. No obvious wrongness (but I'm not very familiar with bpf), though I do have a comment: sk_negative_common() and bpf_slow_path_common() should be made one and single macro which takes the fallback function as an argument. I'll mess around & try to test using Jan test case & will come back with an updated patch. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [REGRESSION][PATCH V4 3/3] bpf jit: Let the powerpc jit handle negative offsets
On Mon, 2012-04-30 at 12:43 +1000, Benjamin Herrenschmidt wrote:
> Ok, he hasn't so I'll dig a bit.
>
> No obvious wrongness (but I'm not very familiar with bpf), though I do
> have a comment: sk_negative_common() and bpf_slow_path_common() should
> be made one and single macro which takes the fallback function as an
> argument.
>
> I'll mess around & try to test using Jan test case & will come back
> with an updated patch.
Wow, hit that nasty along the way: The test program will not work
on big endian machines because of a nasty difference between
the kernel struct sock_fprog and libpcap struct bpf_program:
Kernel expects:
struct sock_fprog { /* Required for SO_ATTACH_FILTER. */
unsigned short len;/* Number of filter blocks */
struct sock_filter __user *filter;
};
libpcap provides:
struct bpf_program {
u_int bf_len;
struct bpf_insn *bf_insns;
};
Note the unsigned short vs. unsigned int there ? This totally
breaks it here.
Is it expected that one can pass a struct bpf_program directly
to the kernel or should it be "converted" by the library in which
case it's just a bug in Jan's test program ?
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [REGRESSION][PATCH V4 3/3] bpf jit: Let the powerpc jit handle negative offsets
Benjamin Herrenschmidt schrieb: > On Wed, 2012-04-04 at 08:11 +1000, Benjamin Herrenschmidt wrote: >> On Tue, 2012-04-03 at 18:03 -0400, David Miller wrote: >> Signed-off-by: Jan Seiffert I have only compile tested this, -ENOHARDWARE. Can someone with more powerpc kung-fu review and maybe test this? Esp. powerpc asm is not my strong point. I think i botched the stack frame in the call setup. Help? >>> >>> I'm not applying this until a powerpc person tests it. >>> >>> Also, we have an ARM JIT in the tree which probably needs to be >>> fixed similarly. >> >> Matt's having a look at powerpc > > Ok, he hasn't so I'll dig a bit. > That would be great Benjamin! > No obvious wrongness (but I'm not very familiar with bpf), As long as you know PPC ASM you are my man ;-) > though I do have a comment: sk_negative_common() and > bpf_slow_path_common() should be made one and single macro which > takes the fallback function as an argument. > I don't know if this is possible. The return value is different (one returns 0 on success, the other != 0, the return value of != is needed). I didn't wanted to change to much, because i'm not fluent in ppc. > I'll mess around & try to test using Jan test case & will come back > with an updated patch. > Would be great! > Cheers, Ben. > Greetings Jan -- A UDP packet walks into a ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [REGRESSION][PATCH V4 3/3] bpf jit: Let the powerpc jit handle negative offsets
On Mon, 2012-04-30 at 12:43 +1000, Benjamin Herrenschmidt wrote: > > Matt's having a look at powerpc > > Ok, he hasn't so I'll dig a bit. > > No obvious wrongness (but I'm not very familiar with bpf), though I do > have a comment: sk_negative_common() and bpf_slow_path_common() should > be made one and single macro which takes the fallback function as an > argument. Ok, with the compile fix below it seems to work for me: (Feel free to fold that into the original patch) diff --git a/arch/powerpc/net/bpf_jit.h b/arch/powerpc/net/bpf_jit.h index af1ab5e..5c3cf2d 100644 --- a/arch/powerpc/net/bpf_jit.h +++ b/arch/powerpc/net/bpf_jit.h @@ -48,7 +48,13 @@ /* * Assembly helpers from arch/powerpc/net/bpf_jit.S: */ -extern u8 sk_load_word[], sk_load_half[], sk_load_byte[], sk_load_byte_msh[]; +#define DECLARE_LOAD_FUNC(func)\ + extern u8 func[], func##_negative_offset[], func##_positive_offset[] + +DECLARE_LOAD_FUNC(sk_load_word); +DECLARE_LOAD_FUNC(sk_load_half); +DECLARE_LOAD_FUNC(sk_load_byte); +DECLARE_LOAD_FUNC(sk_load_byte_msh); #define FUNCTION_DESCR_SIZE24 Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [REGRESSION][PATCH V4 3/3] bpf jit: Let the powerpc jit handle negative offsets
Benjamin Herrenschmidt schrieb: > On Mon, 2012-04-30 at 12:43 +1000, Benjamin Herrenschmidt wrote: > >>> Matt's having a look at powerpc >> >> Ok, he hasn't so I'll dig a bit. >> >> No obvious wrongness (but I'm not very familiar with bpf), though I do >> have a comment: sk_negative_common() and bpf_slow_path_common() should >> be made one and single macro which takes the fallback function as an >> argument. > > Ok, with the compile fix below it seems to work for me: > > (Feel free to fold that into the original patch) > Should i resend the complete patch with the compile fix? [snip] > > Cheers, > Ben. > Greetings Jan PS: I am sure i compile tested the orig. patch here, hmmm, must have lost that part when moving trees, #GitIsNotMyFriend -- en.gin.eer en-ji-nir n 1: a mechanism for converting caffeine into designs. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [REGRESSION][PATCH V4 3/3] bpf jit: Let the powerpc jit handle negative offsets
On Mon, 2012-04-30 at 06:27 +0200, Jan Seiffert wrote: > Benjamin Herrenschmidt schrieb: > > On Mon, 2012-04-30 at 12:43 +1000, Benjamin Herrenschmidt wrote: > > > >>> Matt's having a look at powerpc > >> > >> Ok, he hasn't so I'll dig a bit. > >> > >> No obvious wrongness (but I'm not very familiar with bpf), though I do > >> have a comment: sk_negative_common() and bpf_slow_path_common() should > >> be made one and single macro which takes the fallback function as an > >> argument. > > > > Ok, with the compile fix below it seems to work for me: > > > > (Feel free to fold that into the original patch) > > > > Should i resend the complete patch with the compile fix? Won't hurt... BTW. Any idea about that bpf_program vs. sock_fprog issue I mentioned earlier ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [REGRESSION][PATCH V4 3/3] bpf jit: Let the powerpc jit handle negative offsets
Benjamin Herrenschmidt schrieb: > On Mon, 2012-04-30 at 06:27 +0200, Jan Seiffert wrote: >> Benjamin Herrenschmidt schrieb: >>> On Mon, 2012-04-30 at 12:43 +1000, Benjamin Herrenschmidt wrote: >>> > Matt's having a look at powerpc Ok, he hasn't so I'll dig a bit. No obvious wrongness (but I'm not very familiar with bpf), though I do have a comment: sk_negative_common() and bpf_slow_path_common() should be made one and single macro which takes the fallback function as an argument. >>> >>> Ok, with the compile fix below it seems to work for me: >>> >>> (Feel free to fold that into the original patch) >>> >> >> Should i resend the complete patch with the compile fix? > > Won't hurt... > Ok > BTW. Any idea about that bpf_program vs. sock_fprog issue I mentioned > earlier ? > No idea, i was going by the old saying: "Thou shall not include kernel header, or you will feel the wrath of angry kernel gurus." > Cheers, > Ben. > Greetings Jan -- The OO-Hype keeps on spinning, C stays. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Disable /dev/port interface on powerpc systems
On Wed, 2012-03-21 at 18:23 +1100, Benjamin Herrenschmidt wrote: > 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 :) The more I think about this the less I like it ... At the end of the day, the bug is in kbdrate (or the distro, whatever) It's just completely broken to have a bit of userspace running as root randomly whacking IO ports or MMIO registers based on the assumption that there must be some kind of ISA kbd controller there... It's going to break on more than just powerpc (ARM anyone ?). So kbdrate is busted and needs to be either fixed or removed. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[REGRESSION][PATCH V5 3/3] bpf jit: Let the powerpc jit handle negative offsets
Now the helper function from filter.c for negative offsets is exported, it can be used it in the jit to handle negative offsets. First modify the asm load helper functions to handle: - know positive offsets - know negative offsets - any offset then the compiler can be modified to explicitly use these helper when appropriate. This fixes the case of a negative X register and allows to lift the restriction that bpf programs with negative offsets can't be jited. Tested-by: Benjamin Herrenschmidt Signed-off-by: Jan Seiffert --- arch/powerpc/net/bpf_jit.h |8 +++- arch/powerpc/net/bpf_jit_64.S | 108 ++- arch/powerpc/net/bpf_jit_comp.c | 26 +++-- 3 files changed, 111 insertions(+), 31 deletions(-) diff --git a/arch/powerpc/net/bpf_jit.h b/arch/powerpc/net/bpf_jit.h index af1ab5e..5c3cf2d 100644 --- a/arch/powerpc/net/bpf_jit.h +++ b/arch/powerpc/net/bpf_jit.h @@ -48,7 +48,13 @@ /* * Assembly helpers from arch/powerpc/net/bpf_jit.S: */ -extern u8 sk_load_word[], sk_load_half[], sk_load_byte[], sk_load_byte_msh[]; +#define DECLARE_LOAD_FUNC(func)\ + extern u8 func[], func##_negative_offset[], func##_positive_offset[] + +DECLARE_LOAD_FUNC(sk_load_word); +DECLARE_LOAD_FUNC(sk_load_half); +DECLARE_LOAD_FUNC(sk_load_byte); +DECLARE_LOAD_FUNC(sk_load_byte_msh); #define FUNCTION_DESCR_SIZE24 diff --git a/arch/powerpc/net/bpf_jit_64.S b/arch/powerpc/net/bpf_jit_64.S index ff4506e..55ba385 100644 --- a/arch/powerpc/net/bpf_jit_64.S +++ b/arch/powerpc/net/bpf_jit_64.S @@ -31,14 +31,13 @@ * then branch directly to slow_path_XXX if required. (In fact, could * load a spare GPR with the address of slow_path_generic and pass size * as an argument, making the call site a mtlr, li and bllr.) - * - * Technically, the "is addr < 0" check is unnecessary & slowing down - * the ABS path, as it's statically checked on generation. */ .globl sk_load_word sk_load_word: cmpdi r_addr, 0 - blt bpf_error + blt bpf_slow_path_word_neg + .globl sk_load_word_positive_offset +sk_load_word_positive_offset: /* Are we accessing past headlen? */ subir_scratch1, r_HL, 4 cmpdr_scratch1, r_addr @@ -51,7 +50,9 @@ sk_load_word: .globl sk_load_half sk_load_half: cmpdi r_addr, 0 - blt bpf_error + blt bpf_slow_path_half_neg + .globl sk_load_half_positive_offset +sk_load_half_positive_offset: subir_scratch1, r_HL, 2 cmpdr_scratch1, r_addr blt bpf_slow_path_half @@ -61,7 +62,9 @@ sk_load_half: .globl sk_load_byte sk_load_byte: cmpdi r_addr, 0 - blt bpf_error + blt bpf_slow_path_byte_neg + .globl sk_load_byte_positive_offset +sk_load_byte_positive_offset: cmpdr_HL, r_addr ble bpf_slow_path_byte lbzxr_A, r_D, r_addr @@ -69,22 +72,20 @@ sk_load_byte: /* * BPF_S_LDX_B_MSH: ldxb 4*([offset]&0xf) - * r_addr is the offset value, already known positive + * r_addr is the offset value */ .globl sk_load_byte_msh sk_load_byte_msh: + cmpdi r_addr, 0 + blt bpf_slow_path_byte_msh_neg + .globl sk_load_byte_msh_positive_offset +sk_load_byte_msh_positive_offset: cmpdr_HL, r_addr ble bpf_slow_path_byte_msh lbzxr_X, r_D, r_addr rlwinm r_X, r_X, 2, 32-4-2, 31-2 blr -bpf_error: - /* Entered with cr0 = lt */ - li r3, 0 - /* Generated code will 'blt epilogue', returning 0. */ - blr - /* Call out to skb_copy_bits: * We'll need to back up our volatile regs first; we have * local variable space at r1+(BPF_PPC_STACK_BASIC). @@ -136,3 +137,84 @@ bpf_slow_path_byte_msh: lbz r_X, BPF_PPC_STACK_BASIC+(2*8)(r1) rlwinm r_X, r_X, 2, 32-4-2, 31-2 blr + +/* Call out to bpf_internal_load_pointer_neg_helper: + * We'll need to back up our volatile regs first; we have + * local variable space at r1+(BPF_PPC_STACK_BASIC). + * Allocate a new stack frame here to remain ABI-compliant in + * stashing LR. + */ +#define sk_negative_common(SIZE) \ + mflrr0; \ + std r0, 16(r1); \ + /* R3 goes in parameter space of caller's frame */ \ + std r_skb, (BPF_PPC_STACKFRAME+48)(r1); \ + std r_A, (BPF_PPC_STACK_BASIC+(0*8))(r1); \ + std r_X, (BPF_PPC_STACK_BASIC+(1*8))(r1); \ + stdur1, -BPF_PPC_SLOWPATH_FRAME(r1);\ + /* R3 = r_skb, as passed */ \ + mr r4, r_addr; \ + li r5, SIZE; \ + bl bpf_internal_load_pointer_neg_helper; \ + /* R3 != 0 on succ
Re: [REGRESSION][PATCH V4 3/3] bpf jit: Let the powerpc jit handle negative offsets
> No idea, i was going by the old saying: > "Thou shall not include kernel header, or you will feel the wrath of angry > kernel gurus." Heh :-) Well, googling around, it looks like there's a mix of both type of programs out there. Those using a struct bpf_program and those using a struct soft_fprog. Only the latter will work on BE machines as far as I can tell. David, what's the right way to fix that ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Support lower minimum entitlement for virtual processors
On Fri, 2012-03-23 at 16:22 -0500, Robert Jennings wrote:
> This patch changes the architecture vector to advertise support for a
> lower minimum virtual processor entitled capacity. The default
> minimum without this patch is 10%, this patch specifies 5%. This will
> allow 20 LPARs per CPU rather than only 10.
Any reason why we don't just put 1% in there and thus don't have to
change again when pHyp decides to lower their minimum ? :-)
(Can you test that it works, ie, that pHyp doesn't barf if we put 1% and
properly uses 5% in that case ?)
Cheers,
Ben.
> Signed-off-by: Robert Jennings
> ---
> arch/powerpc/kernel/prom_init.c |8 ++--
> 1 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
> index eca626e..3d882ea 100644
> --- a/arch/powerpc/kernel/prom_init.c
> +++ b/arch/powerpc/kernel/prom_init.c
> @@ -689,6 +689,9 @@ static void __init early_cmdline_parse(void)
> #define OV3_VMX 0x40/* VMX/Altivec */
> #define OV3_DFP 0x20/* decimal FP */
>
> +/* Option vector 4: IBM PAPR implementation */
> +#define OV4_MIN_ENT_CAP 0x05/* minimum VP entitled capacity
> */
> +
> /* Option vector 5: PAPR/OF options supported */
> #define OV5_LPAR 0x80/* logical partitioning supported */
> #define OV5_SPLPAR 0x40/* shared-processor LPAR supported */
> @@ -753,8 +756,9 @@ static unsigned char ibm_architecture_vec[] = {
> OV3_FP | OV3_VMX | OV3_DFP,
>
> /* option vector 4: IBM PAPR implementation */
> - 2 - 2, /* length */
> + 3 - 2, /* length */
> 0, /* don't halt */
> + OV4_MIN_ENT_CAP,/* minimum VP entitled capacity */
>
> /* option vector 5: PAPR/OF options */
> 13 - 2, /* length */
> @@ -771,7 +775,7 @@ static unsigned char ibm_architecture_vec[] = {
>* must match by the macro below. Update the definition if
>* the structure layout changes.
>*/
> -#define IBM_ARCH_VEC_NRCORES_OFFSET 100
> +#define IBM_ARCH_VEC_NRCORES_OFFSET 101
> W(NR_CPUS), /* number of cores supported */
>
> /* option vector 6: IBM PAPR hints */
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/4] powerpc: Add 64-bit CPU targets for gcc
On Wed, 2012-04-18 at 09:33 -0500, Kumar Gala wrote: > On Apr 17, 2012, at 11:45 PM, Anton Blanchard wrote: > > > > > Add a menu to select various 64-bit CPU targets for gcc. We > > default to -mtune=power7 and if gcc doesn't understand that we > > fallback to -mtune=power4. > > > > Signed-off-by: Anton Blanchard > > --- > > Can you add a target for e5500 cpu. I'm going to put Anton patch in, can you send an add-on for e5500 ? Cheers, Ben. > - k > > > > > Index: linux-build/arch/powerpc/Makefile > > === > > --- linux-build.orig/arch/powerpc/Makefile 2012-04-18 14:31:31.614666419 > > +1000 > > +++ linux-build/arch/powerpc/Makefile 2012-04-18 14:37:08.680708678 > > +1000 > > @@ -69,6 +69,16 @@ LDFLAGS_vmlinux := $(LDFLAGS_vmlinux-y) > > > > CFLAGS-$(CONFIG_PPC64) := -mminimal-toc -mtraceback=no -mcall-aixdesc > > CFLAGS-$(CONFIG_PPC32) := -ffixed-r2 -mmultiple > > + > > +CFLAGS-$(CONFIG_GENERIC_CPU) += $(call > > cc-option,-mtune=power7,-mtune=power4) > > +CFLAGS-$(CONFIG_CELL_CPU) += $(call cc-option,-mcpu=cell) > > +CFLAGS-$(CONFIG_POWER4_CPU) += $(call cc-option,-mcpu=power4) > > +CFLAGS-$(CONFIG_POWER5_CPU) += $(call cc-option,-mcpu=power5) > > +CFLAGS-$(CONFIG_POWER6_CPU) += $(call cc-option,-mcpu=power6) > > +CFLAGS-$(CONFIG_POWER7_CPU) += $(call cc-option,-mcpu=power7) > > + > > +CFLAGS-$(CONFIG_TUNE_CELL) += $(call cc-option,-mtune=cell) > > + > > KBUILD_CPPFLAGS += -Iarch/$(ARCH) > > KBUILD_AFLAGS += -Iarch/$(ARCH) > > KBUILD_CFLAGS += -msoft-float -pipe -Iarch/$(ARCH) $(CFLAGS-y) > > @@ -76,22 +86,11 @@ CPP = $(CC) -E $(KBUILD_CFLAGS) > > > > CHECKFLAGS += -m$(CONFIG_WORD_SIZE) -D__powerpc__ > > -D__powerpc$(CONFIG_WORD_SIZE)__ > > > > -ifeq ($(CONFIG_PPC64),y) > > -ifeq ($(CONFIG_POWER4_ONLY),y) > > - KBUILD_CFLAGS += $(call cc-option,-mcpu=power4) > > -else > > - KBUILD_CFLAGS += $(call cc-option,-mtune=power4) > > -endif > > -endif > > - > > KBUILD_LDFLAGS_MODULE += arch/powerpc/lib/crtsavres.o > > > > -ifeq ($(CONFIG_TUNE_CELL),y) > > - KBUILD_CFLAGS += $(call cc-option,-mtune=cell) > > -endif > > - > > -# No AltiVec instruction when building kernel > > +# No AltiVec or VSX instructions when building kernel > > KBUILD_CFLAGS += $(call cc-option,-mno-altivec) > > +KBUILD_CFLAGS += $(call cc-option,-mno-vsx) > > > > # No SPE instruction when building kernel > > # (We use all available options to help semi-broken compilers) > > Index: linux-build/arch/powerpc/platforms/Kconfig.cputype > > === > > --- linux-build.orig/arch/powerpc/platforms/Kconfig.cputype 2012-04-18 > > 14:31:25.134549903 +1000 > > +++ linux-build/arch/powerpc/platforms/Kconfig.cputype 2012-04-18 > > 14:36:40.576207829 +1000 > > @@ -78,6 +78,36 @@ config PPC_BOOK3E_64 > > > > endchoice > > > > +choice > > + prompt "CPU selection" > > + depends on PPC64 > > + default GENERIC_CPU > > + help > > + This will create a kernel which is optimised for a particular CPU. > > + The resulting kernel may not run on other CPUs, so use this with care. > > + > > + If unsure, select Generic. > > + > > +config GENERIC_CPU > > + bool "Generic" > > + > > +config CELL_CPU > > + bool "Cell Broadband Engine" > > + > > +config POWER4_CPU > > + bool "POWER4" > > + > > +config POWER5_CPU > > + bool "POWER5" > > + > > +config POWER6_CPU > > + bool "POWER6" > > + > > +config POWER7_CPU > > + bool "POWER7" > > + > > +endchoice > > + > > config PPC_BOOK3S > > def_bool y > > depends on PPC_BOOK3S_32 || PPC_BOOK3S_64 > > ___ > > Linuxppc-dev mailing list > > Linuxppc-dev@lists.ozlabs.org > > https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
