* [PATCH] powerpc: Check rc of notifier chain for memory remove
From: Nathan Fontenot @ 2008-08-25 19:33 UTC (permalink / raw)
To: linuxppc-dev
The return code from invocation of the notifier for
pSeries_reconfig_chain during update of the device tree is not
checked. This causes writes to /proc/ppc64/ofdt to update memory
properties (i.e. ibm,dyamic-reconfiguration-memory) to always
return success, instead of the result of the notifier chain.
This happens specifically when we remove/add memory from the
device tree on machines using memory specified in the
ibm,dynamic-reconfiguration-memory property of the device tree.
Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
---
Index: linux-2.6-paulus/arch/powerpc/platforms/pseries/reconfig.c
===================================================================
--- linux-2.6-paulus.orig/arch/powerpc/platforms/pseries/reconfig.c 2008-08-25 13:08:27.000000000 -0500
+++ linux-2.6-paulus/arch/powerpc/platforms/pseries/reconfig.c 2008-08-25 13:45:12.000000000 -0500
@@ -466,11 +466,11 @@
else
action = PSERIES_DRCONF_MEM_REMOVE;
- blocking_notifier_call_chain(&pSeries_reconfig_chain,
- action, value);
+ rc = blocking_notifier_call_chain(&pSeries_reconfig_chain,
+ action, value);
}
- return 0;
+ return rc;
}
/**
^ permalink raw reply
* Re: [PATCH 1/4] Add low level PLL config register interface module
From: Kevin Diggs @ 2008-08-25 21:30 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <5430DEC7-39DB-4316-8E7E-949CA4280403@kernel.crashing.org>
Kumar Gala wrote:
>
> On Aug 25, 2008, at 5:41 AM, Kevin Diggs wrote:
>
>> This adds a small module to handle the low level details of dealing
>> with the
>> PLL config register (HID1) found in the IBM 750GX. It provides 2
>> possible
>> interfaces, both selectable via kernel config options. One is a sysfs
>> attribute
>> and the other is a normal function API. It is called pll_if.
>>
>> The determination of the bus frequency is what worked on a PowerMac
>> 8600. Any
>> suggestions on a more general solution are welcome.
>>
>> WARNING - I used some #ifdefs - Let the fur fly!
>>
>> My name is Kevin Diggs and I approve this patch.
>
>
> This really should be split into two patches. One for the perl script
> and one for the actual kernel code.
>
First, thanks for taking the time for the review!
I can do that. But how? Do I respin everything as x/5? Do I only send out
the PERL script as 5/4? Do I redo patch 1 as 1a/4 and 1b/4 (or 1.1/4 and
1.2/4)?
> Scanning the actual kernel code you have a lot of #ifdef's that should
> be cleaned up:
>
> Can't #ifdef CONFIG_PPC_750GX_DUAL_PLL_IF_SYSFS just be #ifdef
> CONFIG_SYSFS and the same for CONFIG_PPC_750GX_DUAL_PLL_IF_HRTIMER &
> CONFIG_PPC_750GX_DUAL_PLL_IF_CPU_FREQ?
>
I like flexibility. So I allow this module to be configured with either
one or both (or none - if you just want some dead code!) of the available
interfaces. As an example, CONFIG_..._PLL_IF_SYSFS adds the sysfs
attribute to directly control the PLL from user space via writes to the
attribute file under /sys. On my system, a PowerMac 8600, this shows up in
/sys/devices/system/cpu/cpu0/ppc750gxpll. CONFIG_..._PLL_IF_CPU_FREQ adds
the public API functions that are used by the cpufreq driver.
CONFIG_..._PLL_IF_HRTIMER causes it to use the HR timer stuff. This
results in MUCH lower latencies (102 usec vs 3900 usec (HZ=250)). But I
did not want to REQUIRE HR timers (even though they are pretty cool!).
Did I mention that I like flexibility?
Seriously, should I add a check that at least one of ..._SYSFS or
..._CPU_FREQ is defined and refuse to compile otherwise? Via a pragma
or something?
> #ifdef CONFIG_PPC_OF seems unnecessary as all PPC always has this set.
>
I ... uh ... have no idea? Should I remove it?
> What's up with #define MULFIRST and the #if 0?
>
This was just some goofing off in a debug message. I was playing around
trying to see what effect various code arrangements had on accuracy.
Since this is in debug code I was kinda hoping for some leniancy.
The "#if 0" is removing code that ... prevented preemption between the
processor speed switch and the changing of the loops_per_jiffy value.
The idea was that I did not want to change any sleeps. I now think
that processor speed is not a determining factor in delays. I think
the time base register (or decrementer) are used. I don't even change
the loops_per_jiffy any more (Maybe that is incorrect?). I left this
code in there to potentially jog my memory if I find myself debugging
some problem in the future? Would a comment be helpful?
> - k
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>
At the tone the timebase will be 12499983. No trailing 0s. Very bad
for accuracy.
^ permalink raw reply
* Re: Efficient memcpy()/memmove() for G2/G3 cores...
From: Benjamin Herrenschmidt @ 2008-08-25 22:28 UTC (permalink / raw)
To: David Jander; +Cc: linuxppc-dev
In-Reply-To: <200808251506.34450.david.jander@protonic.nl>
On Mon, 2008-08-25 at 15:06 +0200, David Jander wrote:
> Hi Matt,
>
> On Monday 25 August 2008 13:00:10 Matt Sealey wrote:
> > The focus has definitely been on VMX but that's not to say lower power
> > processors were forgotten :)
>
> lower-power (pun intended) is coming strong these days, as energy-efficiency
> is getteing more important every day. And the MPC5121 is a brand-new embedded
> processor, that will pop-up in quite a lot devices around you most
> probably ;-)
It would be useful of somebody interested in getting things things
into glibc did the necessary FSF copyright assignment stuff and worked
toward integrating them.
Ben.
^ permalink raw reply
* Re: ttyS0
From: Kumar Gala @ 2008-08-26 0:33 UTC (permalink / raw)
To: Sébastien Chrétien; +Cc: linuxppc-dev
In-Reply-To: <319b0ac50808250716r4f2d42b6ud7293c6b95817048@mail.gmail.com>
man mknod
- k
On Aug 25, 2008, at 9:16 AM, S=E9bastien Chr=E9tien wrote:
> Hello,
>
> I must create a ttyS0 console for my ppc board. Can someone advice =20
> an example ?
>
> Thanks
> S=E9bastien Chr=E9tien
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] add a simple 405EP based board
From: David Gibson @ 2008-08-26 0:41 UTC (permalink / raw)
To: Markus Brunner; +Cc: linuxppc-dev
In-Reply-To: <200808211007.59965.super.firetwister@gmail.com>
On Thu, Aug 21, 2008 at 10:07:58AM +0200, Markus Brunner wrote:
> This adds support for a simple ppc405ep board.
> At the moment, there are no 405ep boards in arch/powerpc, so this can be used as a template
> for new boards, or migrating them from arch/ppc.
> I2c, UART and EMAC are working. PCI could not be tested, so it was not included in the dts.
>
> Signed-off-by: Markus Brunner <super.firetwister@googlemail.com>
[snip]
> + EMAC0: ethernet@ef600800 {
> + linux,network-index = <0>;
The network-index property is obsolete, you shouldn't need it any
more.
--
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
^ permalink raw reply
* Re: [PATCH 2/4] Add cpufreq driver for the IBM PowerPC 750GX
From: Kevin Diggs @ 2008-08-26 0:57 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <200808251343.18027.arnd@arndb.de>
Arnd Bergmann wrote:
> On Monday 25 August 2008, Kevin Diggs wrote:
>
>>+ * cf750gx.c - cpufreq driver for the dual PLLs in the 750gx
>
>
> Thanks for posting this driver and for your attention for detail
> and for documentation in particular. Few people bother to write
> documentation at this level.
>
> I don't understand enough of cpufreq or your hardware to comment
> on that, but please let me give you a few hints on coding style.
>
>
>>+ * Copyright (C) 2008 kevin Diggs
>
>
> Most people list their email address here as well
>
For reasons I'd rather not go into, my email address is not likely
to remain valid for much longer.
>
>>+#define cf750gxmChangingPll (0x80000000)
>>+#define cf750gxmChangingPllBit (31)
>>+#define cf750gxmTurningIdlePllOff (0x40000000)
>>+#define cf750gxmTurningIdlePllOffBit (30)
>
>
> constants should be ALL_CAPS, not sIllYCaPS.
>
Are cf750gxm_CHANGING_PLL and cf750gxm_CHANGING_PLL_BIT_POS ok?
>
>>+struct pll_750fgx_t {
>>+ unsigned short min_ratio; /* min bus ratio */
>>+ unsigned short max_ratio; /* max bus ratio */
>>+ unsigned int min_core; /* min core frequency per spec (KHz) */
>>+ unsigned int max_core; /* max core frequency per spec (KHz) */
>>+};
>
>
> please drop the _t at the end of the identifier.
>
done
>
>>+MODULE_AUTHOR("Kevin Diggs");
>>+MODULE_DESCRIPTION("750GX Dual PLL cpufreq driver");
>>+MODULE_LICENSE("GPL");
>
>
> Move this to the end.
>
done
>
>>+struct cf750gx_t_call_data {
>>+ struct cpufreq_freqs freqs;
>>+ unsigned long current_pll;
>>+ int idle_pll_off;
>>+};
>
>
> drop the _t here, or make explicit what is meant by it.
>
Now that I look at it the _t is supposed to be at the end. It is
meant to indicate that this is a structure tag or type. I'll
remove it.
>
>>+static const struct pll_750fgx_t __initdata pll_750fx = {
>>+ .min_ratio = 2,
>>+ .max_ratio = 20,
>>+ .min_core = 400000,
>>+ .max_core = 800000,
>>+};
>>+
>>+static const struct pll_750fgx_t __initdata pll_750gx = {
>>+ .min_ratio = 2,
>>+ .max_ratio = 20,
>>+ .min_core = 500000,
>>+ .max_core = 1000000,
>>+};
>
>
> Are these correct on any board? If they can be different
> depending on the board design, it would be better to get
> this data from the device tree.
>
They are a spceification of the processor itself. Should be
the same for any board using the 750GX (or FX).
>
>>+static DECLARE_COMPLETION(cf750gx_v_exit_completion);
>>+
>>+static unsigned int override_min_core = 0;
>>+static unsigned int override_max_core = 0;
>>+static unsigned int minmaxmode = 0;
>>+
>>+static unsigned int cf750gx_v_min_core = 0;
>>+static unsigned int cf750gx_v_max_core = 0;
>>+static int cf750gx_v_idle_pll_off = 0;
>>+static int cf750gx_v_min_max_mode = 0;
>>+static unsigned long cf750gx_v_state_bits = 0;
>
>
> Is 0 a meaningful value for these? If it just means 'uninitialized',
> then better don't initialize them in the first place, for clarity.
>
The first 3 are module parameters. For the first 2, 0 means
that they were not set. minmaxmode is a boolean. 0 is the
default of disabled.
When I was initially writing the code I figured I would
need the min and max core frequencies in several places.
As it turns out they are only used in the code
initialization routine (cf750gx_init()). I have made
them locals.
..._idle_pll_off is a boolean for a sysfs attribute. 0 is
the default of disabled.
..._min_max_mode is a boolean to hold the state of
minmaxmode. Seems to be only used to print the current
value.
..._state_bits is a global to maintain state.
Does the PowerPC suffer any performance penalties when
accessing shorts compared to ints? Can I save a few bytes
by using shorts?
>
>>+static struct cpufreq_frequency_table *cf750gx_v_f_table;
>>+static struct cpufreq_frequency_table *cf750gx_v_freq_table;
>>+static struct cpufreq_frequency_table *cf750gx_v_min_max_freq_table;
>>+
>>+static struct cf750gx_t_call_data cf750gx_v_switch_call_data;
>>+static struct cf750gx_t_call_data cf750gx_v_lock_call_data;
>>+static struct notifier_block cf750gx_v_pll_switch_nb;
>>+static struct notifier_block cf750gx_v_pll_lock_nb;
>
>
> Also, in general, try to avoid global variables here, even
> in file scope (static), but rather put all device specific
> data into a per-device data structure.
>
How big of a problem is this? I regret the decision to rip
the SMP stuff out. But it is kinda done. If absolutely
necessary I can put these into a structure?
>
>>+static int cf750gx_pll_switch_cb(struct notifier_block *nb, unsigned long
>>+ action, void *data)
>>+{
>>+struct cf750gx_t_call_data *cd;
>>+unsigned int idle_pll;
>>+unsigned int pll_off_cmd;
>>+unsigned int new_pll;
>
>
> The whitespace appears damaged here.
>
Just a coding style thing. I put declarations (or definitions -
I get the two confused?) on the same indent as the block they are
in. Is this a 15 yard illegal procedure penalty?
>
>>+ cd = (struct cf750gx_t_call_data *)data;
>
done
>
> data is a void pointer, so you don't need the cast, and shouldn't
> have it therefore.
>
>>+static int cf750gx_pll_lock_cb(struct notifier_block *nb, unsigned long action,
>>+ void *data)
>>+{
>>+struct cf750gx_t_call_data *cd;
>>+
>>+ cd = (struct cf750gx_t_call_data *)data;
>
>
> same here.
>
and done
>
>>+static int cf750gx_target(struct cpufreq_policy *policy,
>>+ unsigned int target_freq, unsigned int relation)
>>+{
>>+unsigned int next_index = 0; /* Index into freq_table */
>>+unsigned int next_freq = 0; /* next frequency from perf table */
>>+unsigned int next_perf_state = 0; /* Index from perf table */
>>+int result = 0;
>
>
> Don't initialize local variables in the declaration, as that will prevent
> the compiler from warning about uninitialized use.
>
done
>
>>+unsigned int pll;
>>+unsigned int new_pll;
>>+unsigned int active_pll;
>>+struct cpufreq_freqs freqs;
>>+struct cpufreq_frequency_table *ft = cf750gx_v_f_table;
>
>
> more whitespace damage. Maybe there is something wrong with your
> text editor.
>
Nope, just a faulty programmer ...
>
>>+ dprintk(__FILE__">%s(, %u KHz, relation %u)-%d: on cpu %d\n",
>>+ __func__, target_freq, relation, __LINE__, policy->cpu);
>>+
>>+ if (test_and_set_bit(cf750gxmChangingPllBit, &cf750gx_v_state_bits))
>>+ return -EAGAIN;
>>+
>>+ INIT_COMPLETION(cf750gx_v_exit_completion);
>>+
>>+ result = cpufreq_frequency_table_target(policy,
>>+ ft,
>>+ target_freq,
>>+ relation, &next_index);
>>+
>>+ if (unlikely(result))
>>+ goto cf750gxTargetNoFreq;
>
>
> The unlikely() here looks like overoptimization, drop it in favor of
> readability unless you can measure a real-world difference.
>
This was stolen from the ACPI Processor P-States Driver. Given the
frequency of calls I would guess it does not make a difference.
>
>>+ if (active_pll) {
>>+ unsigned int current_state;
>
>
> whitespace damage.
>
same here ...
>
>>+ dprintk(__FILE__">%s()-%d: Modifying PLL: 0x%x\n", __func__, __LINE__,
>>+ new_pll);
>
>
> Please go through all your dprintk and see if you really really need all of them.
> Usually they are useful while you are doing the initial code, but only get in the
> way as soon as it starts working.
>
This from a code readability standpoint? Or an efficiency one?
I think the cpufreq stuff has a debug configure option that
disables compilation of these unless enabled.
>
>>+cf750gxTargetOut:
>>+ return result;
>>+
>>+cf750gxTargetNoFreq:
>>+ result = -ENODEV;
>>+
>>+ goto cf750gxTargetUnlock;
>>+cf750gxTargetFreqSet:
>>+ result = 0;
>>+
>>+ goto cf750gxTargetUnlock;
>>+cf750gxTargetUnlock:
>>+ clear_bit(cf750gxmChangingPllBit, &cf750gx_v_state_bits);
>>+ complete(&cf750gx_v_exit_completion);
>>+
>>+ goto cf750gxTargetOut;
>
>
> The conventional way to write this would be:
>
> result = -ENODEV;
> if (foo)
> goto out_unlock;
>
> result = 0;
> if (bar)
> goto out_unlock;
>
> return 0;
>
> out_unlock:
> clear_bit(cf750gxmChangingPllBit, &cf750gx_v_state_bits);
> complete(&cf750gx_v_exit_completion);
> out:
> return result;
>
I'll fix this.
>
>>+/* policy->cpuinfo.transition_latency = CPUFREQ_ETERNAL; */
>>+ policy->cpuinfo.transition_latency = pllif_get_latency();
>
>
> The comment does not really explain anything. If you just want to disable
> code, use #if 0, but better drop it right away and add a comment about
> what might need changing.
>
deleted.
>
>>+ result = cpufreq_frequency_table_cpuinfo(policy, cf750gx_v_f_table);
>>+ if (result)
>>+ goto err_freqfree;
>>+
>>+ cpufreq_frequency_table_get_attr(cf750gx_v_f_table, policy->cpu);
>>+
>>+ cf750gx_v_pll_switch_nb.notifier_call = cf750gx_pll_switch_cb;
>>+ cf750gx_v_pll_switch_nb.next = (struct notifier_block *)
>>+ &cf750gx_v_switch_call_data;
>>+ cf750gx_v_pll_switch_nb.priority = 0;
>>+
>>+ result = pllif_register_pll_switch_cb(&cf750gx_v_pll_switch_nb);
>>+
>>+ cf750gx_v_pll_lock_nb.notifier_call = cf750gx_pll_lock_cb;
>>+ cf750gx_v_pll_lock_nb.next =
>>+ (struct notifier_block *)&cf750gx_v_lock_call_data;
>
>
> These casts look wrong, cf750gx_v_lock_call_data is not a notifier_block.
> What are you trying to do here?
>
Just a little sneaky. I should document in the kernel doc though.
>
>>+ cf750gx_v_pll_lock_nb.priority = 0;
>>+
>>+ result = pllif_register_pll_lock_cb(&cf750gx_v_pll_lock_nb);
>>+
>>+ return result;
>>+
>>+err_freqfree:
>>+ return result;
>>+}
>
>
> The first 'return result' is redundant, drop it.
>
done.
>
>>+
>>+static int cf750gx_cpu_exit(struct cpufreq_policy *policy)
>>+{
>>+ dprintk("%s()\n", __func__);
>>+
>>+ /*
>>+ * Wait for any active requests to ripple through before exiting
>>+ */
>>+ wait_for_completion(&cf750gx_v_exit_completion);
>
>
> This "wait for anything" use of wait_for_completion looks wrong,
> because once any other function has done the 'complete', you won't
> wait here any more.
>
> What exactly are you trying to accomplish with this?
>
Originall I had something like:
while(some_bit_is_still_set)
sleep
I think you suggested I use a completion because it is in
fact simpler than a sleep. Now that I think about it also seems
intuitive to give the system a hint as to when something will
be done. 'complete' just means there is no timer pending (unless,
of course, I screwed up the code).
>
>>+static int __init cf750gx_init(void)
>>+{
>>+int ret;
>>+unsigned int freq, i, j, rng, bus_clock;
>>+unsigned short min_ratio, max_ratio;
>>+struct cpufreq_frequency_table *tbp;
>>+const struct pll_750fgx_t *pll_defaults;
>
>
> whitespace.
>
>
>>+ dprintk("%s()\n", __func__);
>>+
>>+ if (!cpu_has_feature(CPU_FTR_DUAL_PLL_750FX))
>>+ return 0;
>
>
> Is this purely a feature of the CPU or does it need logic
> in the board design? If you need external hardware for it,
> you need to check the device tree for the presence of that
> hardware.
>
Purely a feature of the CPU. From what I know, voltage scaling
is an important part of reducing power comsumption. That would
be platform specific code. Anyone know if this is possible for
any 750GX based system? As far as I know it is not possible on
mine?
>
>>+ if (cf750gx_v_freq_table == NULL) {
>>+ ret = -ENOMEM;
>>+ goto ErrSimple;
>>+ }
>
>
> ret = -ENOMEM;
> if (!cf750gx_freq_table)
> goto err_simple;
>
done
>
> Arnd <><
>
>
^ permalink raw reply
* [PATCH][for 2.6.27] fs_enet: Fix SCC Ethernet on CPM2, and crash in fs_enet_rx_napi()
From: Kumar Gala @ 2008-08-26 1:20 UTC (permalink / raw)
To: Jeff Garzik, davem; +Cc: netdev, hs, linuxppc-dev
From: Heiko Schocher <hs@denx.de>
Signed-off-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
Updated to apply cleanly to top of linus's tree.
- k
arch/powerpc/include/asm/cpm2.h | 5 +++++
drivers/net/fs_enet/fs_enet-main.c | 8 ++++++++
drivers/net/fs_enet/mac-scc.c | 8 +++++++-
3 files changed, 20 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/cpm2.h b/arch/powerpc/include/asm/cpm2.h
index 2a6fa01..0f5e8ff 100644
--- a/arch/powerpc/include/asm/cpm2.h
+++ b/arch/powerpc/include/asm/cpm2.h
@@ -337,6 +337,11 @@ typedef struct scc_param {
uint scc_tcrc; /* Internal */
} sccp_t;
+/* Function code bits.
+*/
+#define SCC_EB ((u_char) 0x10) /* Set big endian byte order */
+#define SCC_GBL ((u_char) 0x20) /* Snooping enabled */
+
/* CPM Ethernet through SCC1.
*/
typedef struct scc_enet {
diff --git a/drivers/net/fs_enet/fs_enet-main.c b/drivers/net/fs_enet/fs_enet-main.c
index 9a51ec8..9d46182 100644
--- a/drivers/net/fs_enet/fs_enet-main.c
+++ b/drivers/net/fs_enet/fs_enet-main.c
@@ -792,6 +792,10 @@ static int fs_enet_open(struct net_device *dev)
int r;
int err;
+ /* to initialize the fep->cur_rx,... */
+ /* not doing this, will cause a crash in fs_enet_rx_napi */
+ fs_init_bds(fep->ndev);
+
if (fep->fpi->use_napi)
napi_enable(&fep->napi);
@@ -1167,6 +1171,10 @@ static struct of_device_id fs_enet_match[] = {
.compatible = "fsl,cpm1-scc-enet",
.data = (void *)&fs_scc_ops,
},
+ {
+ .compatible = "fsl,cpm2-scc-enet",
+ .data = (void *)&fs_scc_ops,
+ },
#endif
#ifdef CONFIG_FS_ENET_HAS_FCC
{
diff --git a/drivers/net/fs_enet/mac-scc.c b/drivers/net/fs_enet/mac-scc.c
index 029b3c7..22f50dd 100644
--- a/drivers/net/fs_enet/mac-scc.c
+++ b/drivers/net/fs_enet/mac-scc.c
@@ -47,7 +47,6 @@
#include "fs_enet.h"
/*************************************************/
-
#if defined(CONFIG_CPM1)
/* for a 8xx __raw_xxx's are sufficient */
#define __fs_out32(addr, x) __raw_writel(x, addr)
@@ -62,6 +61,8 @@
#define __fs_out16(addr, x) out_be16(addr, x)
#define __fs_in32(addr) in_be32(addr)
#define __fs_in16(addr) in_be16(addr)
+#define __fs_out8(addr, x) out_8(addr, x)
+#define __fs_in8(addr) in_8(addr)
#endif
/* write, read, set bits, clear bits */
@@ -262,8 +263,13 @@ static void restart(struct net_device *dev)
/* Initialize function code registers for big-endian.
*/
+#ifndef CONFIG_NOT_COHERENT_CACHE
+ W8(ep, sen_genscc.scc_rfcr, SCC_EB | SCC_GBL);
+ W8(ep, sen_genscc.scc_tfcr, SCC_EB | SCC_GBL);
+#else
W8(ep, sen_genscc.scc_rfcr, SCC_EB);
W8(ep, sen_genscc.scc_tfcr, SCC_EB);
+#endif
/* Set maximum bytes per receive buffer.
* This appears to be an Ethernet frame size, not the buffer
--
1.5.5.1
^ permalink raw reply related
* [PATCH] powerpc: Fix determining TI_CPU in power_save_ppc32_restore()
From: Kumar Gala @ 2008-08-26 1:59 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, G.Chen
The calculation to get TI_CPU based off of SPRG3 was just plain wrong.
Since we already have thread_info in r9 there is no reason to bother
to figure it out again.
This was pointed out by Chen Gong <G.Chen@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
Paul, this is in for-2.6.27 branch.
- k
arch/powerpc/kernel/idle_6xx.S | 13 +++++++------
arch/powerpc/kernel/idle_e500.S | 11 ++++++-----
2 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/kernel/idle_6xx.S b/arch/powerpc/kernel/idle_6xx.S
index 019b02d..0138d88 100644
--- a/arch/powerpc/kernel/idle_6xx.S
+++ b/arch/powerpc/kernel/idle_6xx.S
@@ -151,19 +151,20 @@ END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
* Return from NAP/DOZE mode, restore some CPU specific registers,
* we are called with DR/IR still off and r2 containing physical
* address of current. R11 points to the exception frame (physical
- * address). We have to preserve r10.
+ * address). We have to preserve r10. R9 contains the physical
+ * address of thread_info.
*/
_GLOBAL(power_save_ppc32_restore)
- lwz r9,_LINK(r11) /* interrupted in ppc6xx_idle: */
- stw r9,_NIP(r11) /* make it do a blr */
-
#ifdef CONFIG_SMP
- mfspr r12,SPRN_SPRG3
- lwz r11,TI_CPU(r12) /* get cpu number * 4 */
+ lwz r11,TI_CPU(r9) /* get cpu number * 4 */
slwi r11,r11,2
#else
li r11,0
#endif
+
+ lwz r9,_LINK(r11) /* interrupted in ppc6xx_idle: */
+ stw r9,_NIP(r11) /* make it do a blr */
+
/* Todo make sure all these are in the same page
* and load r11 (@ha part + CPU offset) only once
*/
diff --git a/arch/powerpc/kernel/idle_e500.S b/arch/powerpc/kernel/idle_e500.S
index 0630403..c9d7234 100644
--- a/arch/powerpc/kernel/idle_e500.S
+++ b/arch/powerpc/kernel/idle_e500.S
@@ -76,18 +76,19 @@ END_FTR_SECTION_IFSET(CPU_FTR_L2CSR|CPU_FTR_CAN_NAP)
/*
* Return from NAP/DOZE mode, restore some CPU specific registers,
* r2 containing physical address of current.
+ * r9 points to thread_info
* r11 points to the exception frame (physical address).
* We have to preserve r10.
*/
_GLOBAL(power_save_ppc32_restore)
- lwz r9,_LINK(r11) /* interrupted in e500_idle */
- stw r9,_NIP(r11) /* make it do a blr */
-
#ifdef CONFIG_SMP
- mfspr r12,SPRN_SPRG3
- lwz r11,TI_CPU(r12) /* get cpu number * 4 */
+ lwz r11,TI_CPU(r9) /* get cpu number * 4 */
slwi r11,r11,2
#else
li r11,0
#endif
+
+ lwz r9,_LINK(r11) /* interrupted in e500_idle */
+ stw r9,_NIP(r11) /* make it do a blr */
+
b transfer_to_handler_cont
--
1.5.5.1
^ permalink raw reply related
* [PATCH v2] powerpc: Fix determining TI_CPU in power_save_ppc32_restore()
From: Kumar Gala @ 2008-08-26 2:08 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
The calculation to get TI_CPU based off of SPRG3 was just plain wrong.
Just offset off the stack pointer (to get to thread_info) like all the
other references to TI_CPU do.
This was pointed out by Chen Gong <G.Chen@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
The first version was just brain damaged. This version should be cleaner and
doesn't assume anything about the call site having r9 setup already.
(updated for-2.6.27 w/this and rebased to top of linus).
- k
arch/powerpc/kernel/idle_6xx.S | 3 ++-
arch/powerpc/kernel/idle_e500.S | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/idle_6xx.S b/arch/powerpc/kernel/idle_6xx.S
index 019b02d..6dfcdb6 100644
--- a/arch/powerpc/kernel/idle_6xx.S
+++ b/arch/powerpc/kernel/idle_6xx.S
@@ -158,7 +158,8 @@ _GLOBAL(power_save_ppc32_restore)
stw r9,_NIP(r11) /* make it do a blr */
#ifdef CONFIG_SMP
- mfspr r12,SPRN_SPRG3
+ rlwinm r12,r1,0,0,31-THREAD_SHIFT
+ tophys(r12,r12) /* check local flags */
lwz r11,TI_CPU(r12) /* get cpu number * 4 */
slwi r11,r11,2
#else
diff --git a/arch/powerpc/kernel/idle_e500.S b/arch/powerpc/kernel/idle_e500.S
index 0630403..47a1a98 100644
--- a/arch/powerpc/kernel/idle_e500.S
+++ b/arch/powerpc/kernel/idle_e500.S
@@ -84,10 +84,11 @@ _GLOBAL(power_save_ppc32_restore)
stw r9,_NIP(r11) /* make it do a blr */
#ifdef CONFIG_SMP
- mfspr r12,SPRN_SPRG3
+ rlwinm r12,r1,0,0,31-THREAD_SHIFT
lwz r11,TI_CPU(r12) /* get cpu number * 4 */
slwi r11,r11,2
#else
li r11,0
#endif
+
b transfer_to_handler_cont
--
1.5.5.1
^ permalink raw reply related
* Please pull from 'for-2.6.27' (updated)
From: Kumar Gala @ 2008-08-26 2:09 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Please pull from 'for-2.6.27' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for-2.6.27
to receive the following updates:
arch/powerpc/boot/dts/mpc8641_hpcn.dts | 2
arch/powerpc/boot/dts/tqm8548-bigflash.dts | 8
arch/powerpc/boot/dts/tqm8548.dts | 3
arch/powerpc/boot/wrapper | 2
arch/powerpc/configs/83xx/asp8347_defconfig | 1334 +++++++++++++++++
arch/powerpc/configs/83xx/mpc8313_rdb_defconfig | 188 +-
arch/powerpc/configs/83xx/mpc8315_rdb_defconfig | 188 +-
arch/powerpc/configs/83xx/mpc832x_mds_defconfig | 172 +-
arch/powerpc/configs/83xx/mpc832x_rdb_defconfig | 176 +-
arch/powerpc/configs/83xx/mpc834x_itx_defconfig | 175 +-
arch/powerpc/configs/83xx/mpc834x_itxgp_defconfig | 172 +-
arch/powerpc/configs/83xx/mpc834x_mds_defconfig | 168 +-
arch/powerpc/configs/83xx/mpc836x_mds_defconfig | 172 +-
arch/powerpc/configs/83xx/mpc836x_rdk_defconfig | 183 +-
arch/powerpc/configs/83xx/mpc837x_mds_defconfig | 351 ++++
arch/powerpc/configs/83xx/mpc837x_rdb_defconfig | 340 ++++
arch/powerpc/configs/83xx/sbc834x_defconfig | 239 ++-
arch/powerpc/configs/85xx/ksi8560_defconfig | 95 -
arch/powerpc/configs/85xx/mpc8536_ds_defconfig | 1654 ++++++++++++++++++++++
arch/powerpc/configs/85xx/mpc8540_ads_defconfig | 71
arch/powerpc/configs/85xx/mpc8544_ds_defconfig | 178 +-
arch/powerpc/configs/85xx/mpc8560_ads_defconfig | 98 -
arch/powerpc/configs/85xx/mpc8568mds_defconfig | 121 +
arch/powerpc/configs/85xx/mpc8572_ds_defconfig | 177 +-
arch/powerpc/configs/85xx/mpc85xx_cds_defconfig | 85 -
arch/powerpc/configs/85xx/sbc8548_defconfig | 63
arch/powerpc/configs/85xx/sbc8560_defconfig | 69
arch/powerpc/configs/85xx/stx_gp3_defconfig | 163 +-
arch/powerpc/configs/85xx/tqm8540_defconfig | 112 +
arch/powerpc/configs/85xx/tqm8541_defconfig | 139 +
arch/powerpc/configs/85xx/tqm8548_defconfig | 129 +
arch/powerpc/configs/85xx/tqm8555_defconfig | 139 +
arch/powerpc/configs/85xx/tqm8560_defconfig | 139 +
arch/powerpc/configs/adder875_defconfig | 55
arch/powerpc/configs/asp8347_defconfig | 1214 ----------------
arch/powerpc/configs/c2k_defconfig | 245 +--
arch/powerpc/configs/ep8248e_defconfig | 198 ++
arch/powerpc/configs/ep88xc_defconfig | 57
arch/powerpc/configs/linkstation_defconfig | 133 +
arch/powerpc/configs/mpc7448_hpc2_defconfig | 72
arch/powerpc/configs/mpc8272_ads_defconfig | 132 +
arch/powerpc/configs/mpc83xx_defconfig | 389 ++++-
arch/powerpc/configs/mpc8536_ds_defconfig | 1637 ---------------------
arch/powerpc/configs/mpc85xx_defconfig | 207 +-
arch/powerpc/configs/mpc8610_hpcd_defconfig | 165 +-
arch/powerpc/configs/mpc8641_hpcn_defconfig | 215 +-
arch/powerpc/configs/mpc866_ads_defconfig | 61
arch/powerpc/configs/mpc885_ads_defconfig | 57
arch/powerpc/configs/pq2fads_defconfig | 147 +
arch/powerpc/configs/prpmc2800_defconfig | 125 +
arch/powerpc/configs/sbc8641d_defconfig | 173 +-
arch/powerpc/configs/storcenter_defconfig | 113 +
arch/powerpc/kernel/idle_6xx.S | 3
arch/powerpc/kernel/idle_e500.S | 3
arch/powerpc/sysdev/cpm_common.c | 37
arch/powerpc/sysdev/qe_lib/ucc_fast.c | 4
arch/powerpc/sysdev/qe_lib/ucc_slow.c | 8
57 files changed, 8097 insertions(+), 4658 deletions(-)
Kumar Gala (3):
powerpc: Fix whitespace merge in mpc8641 hpcn device tree
powerpc: Update defconfigs for FSL PPC boards
powerpc: Fix determining TI_CPU in power_save_ppc32_restore()
Laurent Pinchart (1):
cpm2: Fix race condition in CPM2 GPIO library.
Scott Wood (1):
powerpc: Add cuImage.mpc866ads to the bootwrapper as a cuboot-8xx target
Timur Tabi (1):
powerpc: fix memory leaks in QE library
Wolfgang Grandegger (1):
powerpc/85xx: TQM8548: DTS file fixes and cleanup
^ permalink raw reply
* Re: [PATCH] powerpc: Fix determining TI_CPU in power_save_ppc32_restore()
From: Kumar Gala @ 2008-08-26 2:10 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, G.Chen, Paul Mackerras
In-Reply-To: <Pine.LNX.4.64.0808252058320.21303@blarg.am.freescale.net>
> diff --git a/arch/powerpc/kernel/idle_6xx.S b/arch/powerpc/kernel/
> idle_6xx.S
> index 019b02d..0138d88 100644
> --- a/arch/powerpc/kernel/idle_6xx.S
> +++ b/arch/powerpc/kernel/idle_6xx.S
> @@ -151,19 +151,20 @@ END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
> * Return from NAP/DOZE mode, restore some CPU specific registers,
> * we are called with DR/IR still off and r2 containing physical
> * address of current. R11 points to the exception frame (physical
> - * address). We have to preserve r10.
> + * address). We have to preserve r10. R9 contains the physical
> + * address of thread_info.
> */
> _GLOBAL(power_save_ppc32_restore)
> - lwz r9,_LINK(r11) /* interrupted in ppc6xx_idle: */
> - stw r9,_NIP(r11) /* make it do a blr */
> -
> #ifdef CONFIG_SMP
> - mfspr r12,SPRN_SPRG3
> - lwz r11,TI_CPU(r12) /* get cpu number * 4 */
> + lwz r11,TI_CPU(r9) /* get cpu number * 4 */
> slwi r11,r11,2
> #else
> li r11,0
> #endif
> +
> + lwz r9,_LINK(r11) /* interrupted in ppc6xx_idle: */
> + stw r9,_NIP(r11) /* make it do a blr */
> +
this is just brain damaged as I'm clobber r11 before setting up r9
with LR. V2 of the patch does things right.
- k
^ permalink raw reply
* [git pull] Please pull powerpc.git merge branch
From: Paul Mackerras @ 2008-08-26 3:57 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev, akpm, linux-kernel
Linus,
Please pull from the 'merge' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
to get some more bug-fixes and defconfig updates for powerpc. Almost
all of the lines changed are in the defconfigs. The rest of the
changes are fixes for various regressions, build failures, and a
possible oops, plus two commits that fix memory leaks and race
conditions in code that is only used on embedded systems with
Freescale processors.
Thanks,
Paul.
arch/powerpc/boot/dts/mpc8641_hpcn.dts | 2
arch/powerpc/boot/dts/tqm8548-bigflash.dts | 8
arch/powerpc/boot/dts/tqm8548.dts | 3
arch/powerpc/boot/wrapper | 2
arch/powerpc/configs/83xx/asp8347_defconfig | 312 ++++++++++++-----
arch/powerpc/configs/83xx/mpc8313_rdb_defconfig | 188 ++++++++--
arch/powerpc/configs/83xx/mpc8315_rdb_defconfig | 188 ++++++++--
arch/powerpc/configs/83xx/mpc832x_mds_defconfig | 172 +++++++--
arch/powerpc/configs/83xx/mpc832x_rdb_defconfig | 176 +++++++---
arch/powerpc/configs/83xx/mpc834x_itx_defconfig | 175 +++++++--
arch/powerpc/configs/83xx/mpc834x_itxgp_defconfig | 172 +++++++--
arch/powerpc/configs/83xx/mpc834x_mds_defconfig | 168 +++++++--
arch/powerpc/configs/83xx/mpc836x_mds_defconfig | 172 +++++++--
arch/powerpc/configs/83xx/mpc836x_rdk_defconfig | 183 +++++++---
arch/powerpc/configs/83xx/mpc837x_mds_defconfig | 351 +++++++++++++++++--
arch/powerpc/configs/83xx/mpc837x_rdb_defconfig | 340 ++++++++++++++++--
arch/powerpc/configs/83xx/sbc834x_defconfig | 239 +++++++++++--
arch/powerpc/configs/85xx/ksi8560_defconfig | 95 ++++-
arch/powerpc/configs/85xx/mpc8536_ds_defconfig | 167 +++++----
arch/powerpc/configs/85xx/mpc8540_ads_defconfig | 71 +++-
arch/powerpc/configs/85xx/mpc8544_ds_defconfig | 178 ++++++----
arch/powerpc/configs/85xx/mpc8560_ads_defconfig | 98 ++++-
arch/powerpc/configs/85xx/mpc8568mds_defconfig | 121 +++++--
arch/powerpc/configs/85xx/mpc8572_ds_defconfig | 177 ++++++----
arch/powerpc/configs/85xx/mpc85xx_cds_defconfig | 85 +++--
arch/powerpc/configs/85xx/sbc8548_defconfig | 63 ++-
arch/powerpc/configs/85xx/sbc8560_defconfig | 69 +++-
arch/powerpc/configs/85xx/stx_gp3_defconfig | 163 ++++++---
arch/powerpc/configs/85xx/tqm8540_defconfig | 112 ++++--
arch/powerpc/configs/85xx/tqm8541_defconfig | 139 ++++++--
arch/powerpc/configs/85xx/tqm8548_defconfig | 129 +++++--
arch/powerpc/configs/85xx/tqm8555_defconfig | 139 ++++++--
arch/powerpc/configs/85xx/tqm8560_defconfig | 139 ++++++--
arch/powerpc/configs/adder875_defconfig | 55 ++-
arch/powerpc/configs/c2k_defconfig | 245 ++++++-------
arch/powerpc/configs/chrp32_defconfig | 141 +++++---
arch/powerpc/configs/ep8248e_defconfig | 198 +++++++++--
arch/powerpc/configs/ep88xc_defconfig | 57 ++-
arch/powerpc/configs/g5_defconfig | 227 +++++++-----
arch/powerpc/configs/iseries_defconfig | 87 +++--
arch/powerpc/configs/linkstation_defconfig | 133 +++++--
arch/powerpc/configs/maple_defconfig | 381 ++++++++++++++-------
arch/powerpc/configs/mpc7448_hpc2_defconfig | 72 +++-
arch/powerpc/configs/mpc8272_ads_defconfig | 132 +++++--
arch/powerpc/configs/mpc83xx_defconfig | 389 +++++++++++++++++++--
arch/powerpc/configs/mpc85xx_defconfig | 207 +++++++----
arch/powerpc/configs/mpc8610_hpcd_defconfig | 165 +++++----
arch/powerpc/configs/mpc8641_hpcn_defconfig | 215 +++++++-----
arch/powerpc/configs/mpc866_ads_defconfig | 61 ++-
arch/powerpc/configs/mpc885_ads_defconfig | 57 ++-
arch/powerpc/configs/pmac32_defconfig | 241 +++++++------
arch/powerpc/configs/ppc64_defconfig | 237 +++++++------
arch/powerpc/configs/ppc6xx_defconfig | 144 ++++----
arch/powerpc/configs/pq2fads_defconfig | 147 ++++++--
arch/powerpc/configs/prpmc2800_defconfig | 125 +++++--
arch/powerpc/configs/ps3_defconfig | 153 +++++++-
arch/powerpc/configs/pseries_defconfig | 172 +++++++--
arch/powerpc/configs/sbc8641d_defconfig | 173 +++++++--
arch/powerpc/configs/storcenter_defconfig | 113 ++++--
arch/powerpc/platforms/ps3/htab.c | 269 +++++----------
arch/powerpc/platforms/ps3/setup.c | 1
arch/powerpc/platforms/ps3/spu.c | 18 +
arch/powerpc/platforms/pseries/setup.c | 1
arch/powerpc/sysdev/cpm_common.c | 37 +-
arch/powerpc/sysdev/qe_lib/ucc_fast.c | 4
arch/powerpc/sysdev/qe_lib/ucc_slow.c | 8
drivers/oprofile/cpu_buffer.c | 4
drivers/oprofile/event_buffer.c | 2
68 files changed, 6659 insertions(+), 2808 deletions(-)
rename arch/powerpc/configs/{asp8347_defconfig => 83xx/asp8347_defconfig} (87%)
rename arch/powerpc/configs/{mpc8536_ds_defconfig => 85xx/mpc8536_ds_defconfig} (95%)
commit 9bdbb9633281b58ff483ede723f8c4a6344cab2f
Author: Paul Mackerras <paulus@samba.org>
Date: Tue Aug 26 13:31:55 2008 +1000
powerpc: Update defconfigs for most non-embedded platforms
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit d617a40227705eb0d7b7692bbb974d077f0219a9
Author: Andrew Morton <akpm@linux-foundation.org>
Date: Thu Aug 21 11:16:26 2008 +1000
powerpc: Export CMO_PageSize
This fixes an error building powerpc allmodconfig:
ERROR: "CMO_PageSize" [arch/powerpc/platforms/pseries/cmm.ko] undefined!
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit b47027795a22fe61f93de6010c120f26273fc693
Author: Masakazu Mokuno <mokuno@sm.sony.co.jp>
Date: Thu Aug 21 06:18:56 2008 +1000
powerpc/ps3: Fix ioremap of spu shadow regs
Fix the ioremap of the spu shadow regs on the PS3.
The current PS3 hypervisor requires the spu shadow regs to be
mapped with the PTE page protection bits set as read-only (PP=3).
This implementation uses the low level __ioremap() to bypass the
page protection settings inforced by ioremap_flags() to get the
needed PTE bits set for the shadow regs.
This fixes a runtime failure on the PS3 introduced by the powerpc
ioremap_prot rework of commit a1f242ff460e4b50a045fa237c3c56cce9eabf83
("powerpc ioremap_prot").
Signed-off-by: Masakazu Mokuno <mokuno@sm.sony.co.jp>
CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit 9cfeb74e93cf3549b7fa67ffe407192da625c777
Author: Masakazu Mokuno <mokuno@sm.sony.co.jp>
Date: Thu Aug 21 06:18:51 2008 +1000
powerpc/ps3: Rework htab code to remove ioremap
Rework the PS3 MMU hash table code to remove the need to ioremap the
hash table by using the HV calls lv1_insert_htab_entry() and
lv1_read_htab_entries().
This fixes a runtime failure on the PS3 introduced by the powerpc
ioremap_prot rework of commit a1f242ff460e4b50a045fa237c3c56cce9eabf83
("powerpc ioremap_prot").
Signed-off-by: Masakazu Mokuno <mokuno@sm.sony.co.jp>
CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit 98fded0728d6d65b78a7fe7d205e947ee81bb9b5
Author: Geoff Levand <geoffrey.levand@am.sony.com>
Date: Thu Aug 21 06:18:43 2008 +1000
powerpc/ps3: Update ps3_defconfig
Update ps3_defconfig.
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit f4156d1cd1dc260cca767a6c0636625f05446799
Author: Carl Love <cel@us.ibm.com>
Date: Mon Aug 11 17:25:43 2008 +1000
powerpc/cell/oprofile: Avoid double vfree of profile buffer
If an error occurs on opcontrol start, the event and per cpu buffers
are released. If later opcontrol shutdown is called then the free
function will be called again to free buffers that no longer
exist. This results in a kernel oops. The following changes
prevent the call to delete buffers that don't exist.
Signed-off-by: Carl Love <carll@us.ibm.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Robert Richter <robert.richter@amd.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit 2bb2e1db906e6e139636271d2cf46466d9e84005
Author: Kumar Gala <galak@kernel.crashing.org>
Date: Thu Aug 21 07:11:30 2008 -0500
powerpc: Update defconfigs for FSL PPC boards
Since we are updated defconfigs I went ahead and moved the
asp8347_defconfig under 83xx/ and the mpc8536_ds_defconfig under
85xx/ as that is where they should have been to start with.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
commit 8dd217b27e32081121c31d927e7c70f6dbf6f5c6
Author: Scott Wood <scottwood@freescale.com>
Date: Thu Jul 31 19:10:22 2008 +0300
powerpc: Add cuImage.mpc866ads to the bootwrapper as a cuboot-8xx target
This patch fixes the following build error with mpc866_ads_defconfig:
<-- snip -->
...
WRAP arch/powerpc/boot/cuImage.mpc866ads
powerpc64-linux-ld: arch/powerpc/boot/cuboot-mpc866ads.o: No such file: No such file or directory
make[2]: *** [arch/powerpc/boot/cuImage.mpc866ads] Error 1
<-- snip -->
Reported-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Scott Wood <scottwood@freescale.com>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
commit 639d64456e20cbfc866b18dc03cf9f9babc9c7cd
Author: Laurent Pinchart <laurentp@cse-semaphore.com>
Date: Tue Aug 19 14:20:23 2008 +0200
cpm2: Fix race condition in CPM2 GPIO library.
The CPM2 GPIO library code uses the non thread-safe clrbits32/setbits32
macros. This patch protects them with a spinlock.
Signed-off-by: Laurent Pinchart <laurentp@cse-semaphore.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
commit 61a4e9e91dd3916ef91aa4899b7271bba0248677
Author: Timur Tabi <timur@freescale.com>
Date: Wed Aug 20 10:29:09 2008 -0500
powerpc: fix memory leaks in QE library
Fix two memory leaks in the Freescale QE library: add a missing kfree() in
ucc_fast_init() and ucc_slow_init() if the ioremap() fails, and update
ucc_fast_free() and ucc_slow_free() to call iounmap() if necessary.
Based on a patch from Tony Breeds <tony@bakeyournoodle.com>.
Signed-off-by: Timur Tabi <timur@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
commit d27a736c7a62c3451e389aa8e0dfc64dab119b9b
Author: Wolfgang Grandegger <wg@grandegger.com>
Date: Sun Aug 17 10:51:25 2008 +0200
powerpc/85xx: TQM8548: DTS file fixes and cleanup
Due to the missing compatible property for the SOC, the MPC I2C buses are
not found any more. This patch fixes this issue. Furthermore it corrects
the name of the SOC node and adds the missing I2C node for the RTC.
Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
commit ba1616d921429ffe7480e8835e85f95ff041add8
Author: Kumar Gala <galak@kernel.crashing.org>
Date: Thu Jul 31 17:06:31 2008 -0500
powerpc: Fix whitespace merge in mpc8641 hpcn device tree
When we coverted the .dts to v1 we lost a space between the irq
and its polarity/sense information. This causes a bit of chaos
as the reset of the blob is off by one cell.
This was noticed by booting and getting errors w/ATA due to
lock of interrupts.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
^ permalink raw reply
* Re: [PATCH] powerpc: Fix determining TI_CPU in power_save_ppc32_restore()
From: Benjamin Herrenschmidt @ 2008-08-26 4:37 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, G.Chen, Paul Mackerras
In-Reply-To: <Pine.LNX.4.64.0808252058320.21303@blarg.am.freescale.net>
> #ifdef CONFIG_SMP
> - mfspr r12,SPRN_SPRG3
> - lwz r11,TI_CPU(r12) /* get cpu number * 4 */
> + lwz r11,TI_CPU(r9) /* get cpu number * 4 */
> slwi r11,r11,2
> #else
> li r11,0
> #endif
> +
> + lwz r9,_LINK(r11) /* interrupted in ppc6xx_idle: */
> + stw r9,_NIP(r11) /* make it do a blr */
> +
hrm... you just clobbered r11, won't work very well :-)
Ben.
> /* Todo make sure all these are in the same page
> * and load r11 (@ha part + CPU offset) only once
> */
> diff --git a/arch/powerpc/kernel/idle_e500.S b/arch/powerpc/kernel/idle_e500.S
> index 0630403..c9d7234 100644
> --- a/arch/powerpc/kernel/idle_e500.S
> +++ b/arch/powerpc/kernel/idle_e500.S
> @@ -76,18 +76,19 @@ END_FTR_SECTION_IFSET(CPU_FTR_L2CSR|CPU_FTR_CAN_NAP)
> /*
> * Return from NAP/DOZE mode, restore some CPU specific registers,
> * r2 containing physical address of current.
> + * r9 points to thread_info
> * r11 points to the exception frame (physical address).
> * We have to preserve r10.
> */
> _GLOBAL(power_save_ppc32_restore)
> - lwz r9,_LINK(r11) /* interrupted in e500_idle */
> - stw r9,_NIP(r11) /* make it do a blr */
> -
> #ifdef CONFIG_SMP
> - mfspr r12,SPRN_SPRG3
> - lwz r11,TI_CPU(r12) /* get cpu number * 4 */
> + lwz r11,TI_CPU(r9) /* get cpu number * 4 */
> slwi r11,r11,2
> #else
> li r11,0
> #endif
> +
> + lwz r9,_LINK(r11) /* interrupted in e500_idle */
> + stw r9,_NIP(r11) /* make it do a blr */
> +
> b transfer_to_handler_cont
^ permalink raw reply
* Re: [PATCH v2] powerpc: Fix determining TI_CPU in power_save_ppc32_restore()
From: Benjamin Herrenschmidt @ 2008-08-26 4:39 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, paulus
In-Reply-To: <1219716536-21643-1-git-send-email-galak@kernel.crashing.org>
On Mon, 2008-08-25 at 21:08 -0500, Kumar Gala wrote:
> The calculation to get TI_CPU based off of SPRG3 was just plain wrong.
> Just offset off the stack pointer (to get to thread_info) like all the
> other references to TI_CPU do.
>
> This was pointed out by Chen Gong <G.Chen@freescale.com>
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
^ permalink raw reply
* Re: Please pull from 'for-2.6.27' (updated)
From: Benjamin Herrenschmidt @ 2008-08-26 4:44 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <Pine.LNX.4.64.0808252100440.21525@blarg.am.freescale.net>
On Mon, 2008-08-25 at 21:09 -0500, Kumar Gala wrote:
> Kumar Gala (3):
> powerpc: Fix whitespace merge in mpc8641 hpcn device tree
> powerpc: Update defconfigs for FSL PPC boards
> powerpc: Fix determining TI_CPU in power_save_ppc32_restore()
Please, don't put a patch in a git pull request that has been out for
review exactly ... 1mn according to the email time stamps.
Cheers,
Ben.
^ permalink raw reply
* Re: [RFC PATCH 2/2] powerpc/83xx: mpc836x_mds: add support for USB Host
From: David Gibson @ 2008-08-26 5:24 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, Li Yang
In-Reply-To: <20080825152736.GB25178@oksana.dev.rtsoft.ru>
On Mon, Aug 25, 2008 at 07:27:36PM +0400, Anton Vorontsov wrote:
> Various changes to support QE USB Host on a MPC8360E-MDS board:
>
> - Update the device tree per QE USB bindings;
> - Configure QE Par IO;
> - Set up BCSR for both USB Host and Peripheral modes;
> - Add timer (GTM) node;
> - Add gpio-controller node for BCSR13 bank;
> - Select FSL_GTM, QE_GPIO and OF_SIMPLE_GPIO.
>
> The work is loosely based on Li Yang's patch[1], which is used
> to support peripheral mode only.
>
> [1] http://ozlabs.org/pipermail/linuxppc-dev/2008-August/061357.html
>
> The s-o-b line of the original patch preserved here.
>
> Signed-off-by: Li Yang <leoli@freescale.com>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> arch/powerpc/boot/dts/mpc836x_mds.dts | 44 +++++++++++++++++++++++++++-
> arch/powerpc/platforms/83xx/Kconfig | 3 ++
> arch/powerpc/platforms/83xx/mpc836x_mds.c | 31 +++++++++++++++++++-
> 3 files changed, 75 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/mpc836x_mds.dts b/arch/powerpc/boot/dts/mpc836x_mds.dts
> index ada8446..0be98f3 100644
> --- a/arch/powerpc/boot/dts/mpc836x_mds.dts
> +++ b/arch/powerpc/boot/dts/mpc836x_mds.dts
> @@ -69,8 +69,19 @@
> };
>
> bcsr@1,0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> device_type = "board-control";
Not the fault of this patch, obviously, but this device_type should
never have been here.
> reg = <1 0 0x8000>;
> + ranges = <0 1 0 0x8000>;
> +
> + bcsr13: gpio-controller@d {
> + #gpio-cells = <2>;
> + compatible = "fsl,mpc8360mds-bcsr-gpio",
> + "simple-gpio-bank";
> + reg = <0xd 1>;
> + gpio-controller;
> + };
> };
> };
>
> @@ -191,10 +202,21 @@
> };
>
> par_io@1400 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> reg = <0x1400 0x100>;
> + ranges = <0 0x1400 0x100>;
> device_type = "par_io";
Nor this one
--
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
^ permalink raw reply
* Re: MPC5200 FEC problems
From: Wolfram Sang @ 2008-08-26 6:18 UTC (permalink / raw)
To: Gary Thomas; +Cc: linuxppc-dev
In-Reply-To: <48B2D167.40008@mlbassoc.com>
[-- Attachment #1: Type: text/plain, Size: 1335 bytes --]
Hello Gary,
On Mon, Aug 25, 2008 at 09:36:07AM -0600, Gary Thomas wrote:
> I'm adding the Analogue & Micro Boa (MPC5200/B) platform to the
> public 2.6.26 tree. Under heavy network load (sometimes even
> not so heavy!), I get this error:
> net eth0: FEC_IEVENT_RFIFO_ERROR
Yeah, I know this one :(
> My question is - what exactly does this error imply? Looking at
> the MPC5200 manual doesn't give much info - just that there was
> a Rx FIFO error.
In deed, the manual seems not very helpful. The description of the set FIFO
status bit did not help me that much.
> I'm also perplexed by the fact that I have two slightly different
> Boa boards (same CPU rev, speed, etc). About the only thing that's
> different is the SDRAM setup. One board is rock solid while the
> other gets this error almost immediately.
I'm not sure if this is really of importance, but do the boards have
different PHYs?
> Note that I don't have any trouble with this platform running RedBoot
> or eCos, just Linux :-(
Try this patch and please report if it worked for you:
http://www.nabble.com/-PATCH--MPC52XX:-Don't-touch-pipelining-for-MPC5200B-td19028341.html
All the best,
Wolfram
--
Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* AMCC PPC460EX Canyonlands Hardwired interrupt
From: Henry Bausley @ 2008-08-26 7:41 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200808222144.15235.sr@denx.de>
How do I go about using one of the gpio pins for my own interrupt with the
Canyonlands board. Previously I used a yosemite (ppc) board and modified
the yosemite.c file so that IRQ0 and IRQ1 were edge sensitive and and stole
the ETH0/1 phy hardware interrupts for my own purposes and everything
worked.
I am trying to do the same with the Canyonlands (powerpc) board.but cannot
seem to enable the interrupt.
I am using the 2.6.26.2 denx kernel and xenomai 2.4.5
^ permalink raw reply
* Re: AMCC PPC460EX Canyonlands Hardwired interrupt
From: Stefan Roese @ 2008-08-26 8:00 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <02f101c9074f$26d2cd90$0109220a@deltatau.local>
On Tuesday 26 August 2008, Henry Bausley wrote:
> How do I go about using one of the gpio pins for my own interrupt with the
> Canyonlands board. Previously I used a yosemite (ppc) board and modified
> the yosemite.c file so that IRQ0 and IRQ1 were edge sensitive and and stole
> the ETH0/1 phy hardware interrupts for my own purposes and everything
> worked.
>
> I am trying to do the same with the Canyonlands (powerpc) board.but cannot
> seem to enable the interrupt.
arch/powerpc now uses virtual interrupts instead of the physical interrupts
used in arch/ppc. So you can't just use the physical interrupt number in your
request_irq() anymore. You need an of-platform driver to generate the virtual
interrupt from the physical interrupt in the device-tree
(irq_of_parse_and_map()). And you need to add this new node with the
interrupt property to your device-tree of course.
Best regards,
Stefan
^ permalink raw reply
* Re: initramfs vs initrd
From: Geert Uytterhoeven @ 2008-08-26 8:56 UTC (permalink / raw)
To: Sébastien Chrétien; +Cc: linuxppc-dev
In-Reply-To: <319b0ac50808250837r73d88349p1ecad4214d5f7ae3@mail.gmail.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=UTF-8, Size: 614 bytes --]
On Mon, 25 Aug 2008, Sébastien Chrétien wrote:
> When the kernel is booting, is it possible to check if the initrd is good ?
Sure, the kernel does some basic checking in init/do_mounts_rd.c.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply
* Re: [PATCH 4/4] Add kernel doc for the completion, fix kernel-doc-nano-HOWTO.txt
From: Ingo Molnar @ 2008-08-26 8:32 UTC (permalink / raw)
To: Kevin Diggs; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <48B29696.3070808@hypersurf.com>
* Kevin Diggs <kevdig@hypersurf.com> wrote:
> This patch adds kernel doc for the completion feature. It is in
> kernel/sched.c and include/linux/completion.h.
>
> An error in the split-man.pl PERL snippet in kernel-doc-nano-HOWTO.txt
> is also fixed.
applied to tip/sched/devel - thanks Kevin!
Ingo
^ permalink raw reply
* Linux booting problem MPC7457 based board with U-boot 1.1.4 and Linux 2.6.12.6
From: Mustafa Cayır @ 2008-08-26 9:28 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I have a custom MPC7457 based board which has been running U-boot 1.1.4. =
I am trying to port Linux 2.6.12.6 .
When booting, Linux hangs when calling "call_setup_cpu" function.
arch\ppc\kernel\head.S
/*
* Call setup_cpu for CPU 0 and initialize 6xx Idle
*/
bl reloc_offset
li r24,0 /* cpu# */
bl call_setup_cpu /* Call setup_cpu for this CPU */
Regards.
^ permalink raw reply
* Re: Early boot problem with MPC8247 and Linux 2.6.26
From: Chris Skepper @ 2008-08-26 11:17 UTC (permalink / raw)
To: Artur Barkhudaryan; +Cc: linuxppc-embedded
In-Reply-To: <1732780698.20080825104615@epygiarm.am>
>> I have a custom MPC8247 based board which has been running U-boot 1.3.5
>> and Linux 2.6.26. It has been working fine with ARCH=ppc, but I now want
>> to make it work using ARCH=powerpc.
>
>> However, using ARCH=powerpc I have encountered a problem. Whatever I do
>> it always appears to reset in the very early stages of booting the kernel.
>
> could this be the hardware watchdog resetting the CPU ? Do you disable
> it in u-boot ?
Thanks for the suggestion, but I've just double-checked and the watchdog
is disabled in U-boot. In any case, I have been using an infinite loop
flashing an LED to trace where execution gets to, and it never resets once
it has started doing that.
Any other ideas?
Cheers,
Chris.
^ permalink raw reply
* Re: [PATCH 2/4] Add cpufreq driver for the IBM PowerPC 750GX
From: Arnd Bergmann @ 2008-08-26 11:29 UTC (permalink / raw)
To: Kevin Diggs; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <48B354FC.1090001@hypersurf.com>
On Tuesday 26 August 2008, Kevin Diggs wrote:
> Arnd Bergmann wrote:
> > On Monday 25 August 2008, Kevin Diggs wrote:
> > Most people list their email address here as well
> >
> For reasons I'd rather not go into, my email address is not likely
> to remain valid for much longer.
Maybe you should get a freemail account somewhere then.
It's better if people have a way to Cc the author of
a file when they make changes to it.
> > drop the _t here, or make explicit what is meant by it.
> >
> Now that I look at it the _t is supposed to be at the end. It is
> meant to indicate that this is a structure tag or type. I'll
> remove it.
Ok, thanks for the explanation. I now saw that you also
use '_v' for variables (I guess). These should probably
go the same way.
> >>+static DECLARE_COMPLETION(cf750gx_v_exit_completion);
> >>+
> >>+static unsigned int override_min_core = 0;
> >>+static unsigned int override_max_core = 0;
> >>+static unsigned int minmaxmode = 0;
> >>+
> >>+static unsigned int cf750gx_v_min_core = 0;
> >>+static unsigned int cf750gx_v_max_core = 0;
> >>+static int cf750gx_v_idle_pll_off = 0;
> >>+static int cf750gx_v_min_max_mode = 0;
> >>+static unsigned long cf750gx_v_state_bits = 0;
> >
> >
> > Is 0 a meaningful value for these? If it just means 'uninitialized',
> > then better don't initialize them in the first place, for clarity.
> >
> The first 3 are module parameters. For the first 2, 0 means
> that they were not set. minmaxmode is a boolean. 0 is the
> default of disabled.
Then at least for the first two, the common coding style would
be to leave out the '= 0'. For minmaxmode, the most expressive
way would be to define an enum, like
enum {
MODE_NORMAL,
MODE_MINMAX,
};
int minmaxmode = MODE_NORMAL;
> When I was initially writing the code I figured I would
> need the min and max core frequencies in several places.
> As it turns out they are only used in the code
> initialization routine (cf750gx_init()). I have made
> them locals.
ah, good.
> ..._idle_pll_off is a boolean for a sysfs attribute. 0 is
> the default of disabled.
ok
> ..._min_max_mode is a boolean to hold the state of
> minmaxmode. Seems to be only used to print the current
> value.
this looks like a duplicate then. why would you need both?
It seems really confusing to have both a cpufreq attribute
and a module attribute with the same name, writing to
different variables.
> ..._state_bits is a global to maintain state.
>
> Does the PowerPC suffer any performance penalties when
> accessing shorts compared to ints? Can I save a few bytes
> by using shorts?
Don't bother. Using int is the general way to say 'some number'.
If you use short, people will wonder why you require a 16 bit
number.
> >>+static struct cpufreq_frequency_table *cf750gx_v_f_table;
> >>+static struct cpufreq_frequency_table *cf750gx_v_freq_table;
> >>+static struct cpufreq_frequency_table *cf750gx_v_min_max_freq_table;
> >>+
> >>+static struct cf750gx_t_call_data cf750gx_v_switch_call_data;
> >>+static struct cf750gx_t_call_data cf750gx_v_lock_call_data;
> >>+static struct notifier_block cf750gx_v_pll_switch_nb;
> >>+static struct notifier_block cf750gx_v_pll_lock_nb;
> >
> >
> > Also, in general, try to avoid global variables here, even
> > in file scope (static), but rather put all device specific
> > data into a per-device data structure.
> >
> How big of a problem is this? I regret the decision to rip
> the SMP stuff out. But it is kinda done. If absolutely
> necessary I can put these into a structure?
Not a huge problem in this case, because it is not strictly a
device driver to start with. In most device drivers, you want
a strict separation between global (per-driver) data and
per-instance data.
Are there even SMP boards based on a 750? I thought only 74xx
and 603/604 were SMP capable.
> >>+static int cf750gx_pll_switch_cb(struct notifier_block *nb, unsigned long
> >>+ action, void *data)
> >>+{
> >>+struct cf750gx_t_call_data *cd;
> >>+unsigned int idle_pll;
> >>+unsigned int pll_off_cmd;
> >>+unsigned int new_pll;
> >
> >
> > The whitespace appears damaged here.
> >
> Just a coding style thing. I put declarations (or definitions -
> I get the two confused?) on the same indent as the block they are
> in. Is this a 15 yard illegal procedure penalty?
I've never seen that style before. Better do what everyone
else does here, e.g. using 'indent -kr -i8'.
> >>+ dprintk(__FILE__">%s()-%d: Modifying PLL: 0x%x\n", __func__, __LINE__,
> >>+ new_pll);
> >
> >
> > Please go through all your dprintk and see if you really really need all of them.
> > Usually they are useful while you are doing the initial code, but only get in the
> > way as soon as it starts working.
> >
> This from a code readability standpoint? Or an efficiency one?
> I think the cpufreq stuff has a debug configure option that
> disables compilation of these unless enabled.
It's more about readability.
> >>+ result = pllif_register_pll_switch_cb(&cf750gx_v_pll_switch_nb);
> >>+
> >>+ cf750gx_v_pll_lock_nb.notifier_call = cf750gx_pll_lock_cb;
> >>+ cf750gx_v_pll_lock_nb.next =
> >>+ (struct notifier_block *)&cf750gx_v_lock_call_data;
> >
> >
> > These casts look wrong, cf750gx_v_lock_call_data is not a notifier_block.
> > What are you trying to do here?
> >
> Just a little sneaky. I should document in the kernel doc though.
No, better avoid such hacks instead of documenting them. I think I
now understand what you do there, and if I got it right, you should
just pass two arguments to pllif_register_pll_switch_cb.
> >>+static int cf750gx_cpu_exit(struct cpufreq_policy *policy)
> >>+{
> >>+ dprintk("%s()\n", __func__);
> >>+
> >>+ /*
> >>+ * Wait for any active requests to ripple through before exiting
> >>+ */
> >>+ wait_for_completion(&cf750gx_v_exit_completion);
> >
> >
> > This "wait for anything" use of wait_for_completion looks wrong,
> > because once any other function has done the 'complete', you won't
> > wait here any more.
> >
> > What exactly are you trying to accomplish with this?
> >
> Originall I had something like:
>
> while(some_bit_is_still_set)
> sleep
>
> I think you suggested I use a completion because it is in
> fact simpler than a sleep. Now that I think about it also seems
> intuitive to give the system a hint as to when something will
> be done. 'complete' just means there is no timer pending (unless,
> of course, I screwed up the code).
The completion would certainly be better than the sleep here, but
I think you shouldn't need that in the first place. AFAICT, you
have three different kinds of events that you need to protect
against, when some other code can call into your module:
1. timer function,
2. cpufreq notifier, and
3. sysfs attribute.
In each case, the problem is a race between two threads that you
need to close. In case of the timer, you need to call del_timer_sync
because the timers already have this method builtin. For the other
two, you already unregister the interfaces, which ought to be enough.
Arnd <><
^ permalink raw reply
* Re: Early boot problem with MPC8247 and Linux 2.6.26
From: Chris Skepper @ 2008-08-26 12:00 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-embedded
In-Reply-To: <48AEF220.7080506@freescale.com>
On Fri, 22 Aug 2008, Scott Wood wrote:
> Chris Skepper wrote:
>> Using code to flash an LED I have traced execution from the entry point in
>> head_32.S, through to call_setup_cpu in misc.S, __setup_cpu_603 and into
>> setup_common_caches in cpu_setup_6xx.S. It appears to reset when enabling
>> the cache on the CPU:
>>
>> setup_common_caches:
>> mfspr r11,SPRN_HID0
>> andi. r0,r11,HID0_DCE
>> ori r11,r11,HID0_ICE|HID0_DCE
>> ori r8,r11,HID0_ICFI
>> bne 1f /* don't invalidate the D-cache */
>> ori r8,r8,HID0_DCI /* unless it wasn't enabled */
>> 1: sync
>> /* Chris: Reaches here. */
>> mtspr SPRN_HID0,r8 /* enable and invalidate caches */
>> sync
>> mtspr SPRN_HID0,r11 /* enable caches */
>> sync
>> isync
>> /* Chris: Never gets to here. */
>> blr
>>
>> FWIW, commenting out the lines above causes it to hang when attempting to
>> enable the MMU, which is the next step in the process.
>
> How are you determining that it never gets to that point? If it's via serial
> I/O or similar, be aware that I/O isn't going to work when caches are enabled
> but the MMU is not.
Hi Scott,
I'm triggering an LED which is connected to port A. Are you saying that
wouldn't work once the caching is enabled?
Cheers,
Chris.
^ 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