* Re: [PATCH 1/5] powerpc: consolidate feature fixup code
From: Paul Mackerras @ 2006-10-23 10:40 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1161308835.10524.108.camel@localhost.localdomain>
Benjamin Herrenschmidt writes:
> There are currently two versions of the functions for applying the
> feature fixups, one for CPU features and one for firmware features. In
> addition, they are both in assembly and with separate implementations
> for 32 and 64 bits. identify_cpu() is also implemented in assembly and
> separately for 32 and 64 bits.
>
> This patch replaces them with a pair of C functions. The call sites are
> slightly moved on ppc64 as well to be called from C instead of from
> assembly, though it's a very small change, and thus shouldn't cause any
> problem.
Unfortunately this:
> Index: linux-cell/include/asm-powerpc/cputable.h
> ===================================================================
> --- linux-cell.orig/include/asm-powerpc/cputable.h 2006-10-13 16:00:28.000000000 +1000
> +++ linux-cell/include/asm-powerpc/cputable.h 2006-10-13 16:19:51.000000000 +1000
> @@ -89,8 +89,7 @@ struct cpu_spec {
>
> extern struct cpu_spec *cur_cpu_spec;
>
> -extern void identify_cpu(unsigned long offset, unsigned long cpu);
> -extern void do_cpu_ftr_fixups(unsigned long offset);
> +extern struct cpu_spec *identify_cpu(unsigned long offset);
... breaks the ARCH=ppc build.
Paul.
^ permalink raw reply
* [PATCH] cell: use ppc_md->power_save instead of cbe_idle_loop
From: Arnd Bergmann @ 2006-10-23 11:50 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus, cbe-oss-dev, Anthony J Marsala
In-Reply-To: <1161598587.10524.455.camel@localhost.localdomain>
This moves the cell idle function to use the default cpu_idle
with a special power_save callback, like all other platforms
except iSeries already do.
It also makes it possible to disable this power_save function
with a new powerpc-specific boot option "powersave=off".
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
---
On Monday 23 October 2006 12:16, Benjamin Herrenschmidt wrote:
> I disagree here... this should be done in setup_cpu() for non-boot CPUs,
> and sometime in setup_arch for the boot CPU.
ok, good point.
> Another option is to have the pm_control bit done once for all CPUs at
> boot in setup_arch() or such, and the TSC_CELL SPR bit done
> unconditionally in powersave...
How about this then?
diff --git a/arch/powerpc/kernel/idle.c b/arch/powerpc/kernel/idle.c
index 4180c39..8994af3 100644
--- a/arch/powerpc/kernel/idle.c
+++ b/arch/powerpc/kernel/idle.c
@@ -39,6 +39,13 @@
#define cpu_should_die() 0
#endif
+static int __init powersave_off(char *arg)
+{
+ ppc_md.power_save = NULL;
+ return 0;
+}
+__setup("powersave=off", powersave_off);
+
/*
* The body of the idle task.
*/
diff --git a/arch/powerpc/platforms/cell/pervasive.c b/arch/powerpc/platforms/cell/pervasive.c
index 9f2e4ed..10b150a 100644
--- a/arch/powerpc/platforms/cell/pervasive.c
+++ b/arch/powerpc/platforms/cell/pervasive.c
@@ -38,32 +38,16 @@
#include "pervasive.h"
#include "cbe_regs.h"
-static DEFINE_SPINLOCK(cbe_pervasive_lock);
-
-static void __init cbe_enable_pause_zero(void)
+static void cbe_power_save(void)
{
- unsigned long thread_switch_control;
- unsigned long temp_register;
- struct cbe_pmd_regs __iomem *pregs;
-
- spin_lock_irq(&cbe_pervasive_lock);
- pregs = cbe_get_cpu_pmd_regs(smp_processor_id());
- if (pregs == NULL)
- goto out;
-
- pr_debug("Power Management: CPU %d\n", smp_processor_id());
-
- /* Enable Pause(0) control bit */
- temp_register = in_be64(&pregs->pm_control);
-
- out_be64(&pregs->pm_control,
- temp_register | CBE_PMD_PAUSE_ZERO_CONTROL);
+ unsigned long ctrl, thread_switch_control;
+ ctrl = mfspr(SPRN_CTRLF);
/* Enable DEC and EE interrupt request */
thread_switch_control = mfspr(SPRN_TSC_CELL);
thread_switch_control |= TSC_CELL_EE_ENABLE | TSC_CELL_EE_BOOST;
- switch ((mfspr(SPRN_CTRLF) & CTRL_CT)) {
+ switch (ctrl & CTRL_CT) {
case CTRL_CT0:
thread_switch_control |= TSC_CELL_DEC_ENABLE_0;
break;
@@ -75,58 +59,21 @@ static void __init cbe_enable_pause_zero
__FUNCTION__);
break;
}
-
mtspr(SPRN_TSC_CELL, thread_switch_control);
-out:
- spin_unlock_irq(&cbe_pervasive_lock);
-}
-
-static void cbe_idle(void)
-{
- unsigned long ctrl;
-
- /* Why do we do that on every idle ? Couldn't that be done once for
- * all or do we lose the state some way ? Also, the pm_control
- * register setting, that can't be set once at boot ? We really want
- * to move that away in order to implement a simple powersave
+ /*
+ * go into low thread priority, medium priority will be
+ * restored for us after wake-up.
*/
- cbe_enable_pause_zero();
+ HMT_low();
- while (1) {
- if (!need_resched()) {
- local_irq_disable();
- while (!need_resched()) {
- /* go into low thread priority */
- HMT_low();
-
- /*
- * atomically disable thread execution
- * and runlatch.
- * External and Decrementer exceptions
- * are still handled when the thread
- * is disabled but now enter in
- * cbe_system_reset_exception()
- */
- ctrl = mfspr(SPRN_CTRLF);
- ctrl &= ~(CTRL_RUNLATCH | CTRL_TE);
- mtspr(SPRN_CTRLT, ctrl);
- }
- /* restore thread prio */
- HMT_medium();
- local_irq_enable();
- }
-
- /*
- * turn runlatch on again before scheduling the
- * process we just woke up
- */
- ppc64_runlatch_on();
-
- preempt_enable_no_resched();
- schedule();
- preempt_disable();
- }
+ /*
+ * atomically disable thread execution and runlatch.
+ * External and Decrementer exceptions are still handled when the
+ * thread is disabled but now enter in cbe_system_reset_exception()
+ */
+ ctrl &= ~(CTRL_RUNLATCH | CTRL_TE);
+ mtspr(SPRN_CTRLT, ctrl);
}
static int cbe_system_reset_exception(struct pt_regs *regs)
@@ -158,9 +105,20 @@ static int cbe_system_reset_exception(st
void __init cbe_pervasive_init(void)
{
+ int cpu;
if (!cpu_has_feature(CPU_FTR_PAUSE_ZERO))
return;
- ppc_md.idle_loop = cbe_idle;
+ for_each_possible_cpu(cpu) {
+ struct cbe_pmd_regs __iomem *regs = cbe_get_cpu_pmd_regs(cpu);
+ if (!regs)
+ continue;
+
+ /* Enable Pause(0) control bit */
+ out_be64(®s->pm_control, in_be64(®s->pm_control) |
+ CBE_PMD_PAUSE_ZERO_CONTROL);
+ }
+
+ ppc_md.power_save = cbe_power_save;
ppc_md.system_reset_exception = cbe_system_reset_exception;
}
^ permalink raw reply related
* Re: [PATCH] General CHRP/MPC5K2 Platform and drivers support - to comment
From: Matt Sealey @ 2006-10-23 14:47 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1161585371.10524.444.camel@localhost.localdomain>
Curious question.
What are you guys going to do when the PowerPC name is defunct?
Like, last month :)
Power Architecture is where it is at. The trademark is even going to
lapse. It's a bit too late for the ppc->powerpc tree breakout now,
but wouldn't it just confuse people to be using a "Power Architecture"
processor or SoC of some type, using collections of definitions from
the Power ISA 2.03 and have this "powerpc" thing pop up?
It confused me even before, because ppc and ppc64 have also been
used to support real POWER (with a capital P, O, W, E and R) processors,
and now these are lumped in with powerpc which is no better than
ppc64 in these terms?
Just flexing my marketing exec muscles, see if they work, never done
it before. Oh... *crack*.. that wasn't a good noise :]
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
Benjamin Herrenschmidt wrote:
> Ok, here's a batch of comments. They go on top of the comments I sent
> about your device-tree, which you might want to make public.
>
> Also note that the size of the patch is partially due to stale ##
> and .orig files :)
>
> In general, one big thing is: Don't bother with re-using the arch/ppc
> code, API, .h etc... There is not enough re-use there to justify it (FEC
> driver is new, serial can easily be changed, as for USB).
>
> * /proc/ppc64/rtas changes: we need to continue that discussion
> separately and ask for paulus point of view. I prefer /proc/powerpc
> personally with a /proc/ppc64->/proc/powerpc symlink on 64 bits machines
> only.
>
[snip]
^ permalink raw reply
* Re: [PATCH] qe_ic: Do a sync when masking interrupts.
From: Scott Wood @ 2006-10-23 15:19 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17724.15919.790114.628418@cargo.ozlabs.ibm.com>
Paul Mackerras wrote:
> Hmmm. In general a sync having completed doesn't mean that previous
> MMIO stores have actually got to the device. Reading from a device
> register generally does ensure that previous writes have actually got
> to the device though - could you do that instead? I'm concerned that
> adding the sync is not a robust fix and is possibly only working due
> to fortuitous timing.
Possibly -- but the only problem on the rare occasions where the timing
is not fortuitous is a spurious interrupt; the only reason the sync
needs to be there at all is to avoid the overhead of the extra interrupt
(and to avoid user complaints that they're getting "BAD" interrupts).
Note that many/most interrupt controller drivers don't even do that
much; they just have more fortuitous timing than the QE (and/or the
spurious interrupt is non-cascaded, and thus gets caught in
handle_level_irq and doesn't increment the spurious interrupt count).
-Scott
^ permalink raw reply
* Re: [PATCH] qe_ic: Do a sync when masking interrupts.
From: Scott Wood @ 2006-10-23 15:29 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <453CDD70.9010100@freescale.com>
Scott Wood wrote:
> Note that many/most interrupt controller drivers don't even do that
> much; they just have more fortuitous timing than the QE (and/or the
> spurious interrupt is non-cascaded, and thus gets caught in
> handle_level_irq and doesn't increment the spurious interrupt count).
Ignore that last bit about non-cascaded interrupts; if it makes a
difference at all, it's because of added delays (getting back to the
fortuitous timing thing).
-Scott
^ permalink raw reply
* Re: 2.6.19-rc2: known unfixed regressions (v3)
From: Meelis Roos @ 2006-10-23 15:20 UTC (permalink / raw)
To: Adrian Bunk
Cc: Andrew Morton, linuxppc-dev, Linus Torvalds, paulus,
Linux Kernel Mailing List
In-Reply-To: <20061022122355.GC3502@stusta.de>
> Subject : ppc prep boot hang
> References : http://lkml.org/lkml/2006/10/14/58
> Submitter : Meelis Roos <mroos@linux.ee>
> Status : unknown
Seems to be fixed in 2.6.19-rc2+git as of 20061022.
--
Meelis Roos
^ permalink raw reply
* Re: [PATCH] General CHRP/MPC5K2 Platform and drivers support - to comment
From: Christoph Hellwig @ 2006-10-23 15:52 UTC (permalink / raw)
To: Matt Sealey; +Cc: linuxppc-dev
In-Reply-To: <453CD615.4050401@genesi-usa.com>
On Mon, Oct 23, 2006 at 04:47:49PM +0200, Matt Sealey wrote:
> Curious question.
>
> What are you guys going to do when the PowerPC name is defunct?
>
> Like, last month :)
>
> Power Architecture is where it is at. The trademark is even going to
> lapse. It's a bit too late for the ppc->powerpc tree breakout now,
> but wouldn't it just confuse people to be using a "Power Architecture"
> processor or SoC of some type, using collections of definitions from
> the Power ISA 2.03 and have this "powerpc" thing pop up?
Who the f***k cares. We've always given a chip what the newspeak party
line of the days is, and we will here aswell. If the IBM/Mot/PowerYodda
overlords are unhappy with that it's their problem, not ours.
^ permalink raw reply
* RE: CPM2 (MPC8260) SMC problem. Please help.
From: Greg Lopp @ 2006-10-23 16:02 UTC (permalink / raw)
To: linuxppc-embedded
> On Wed, 18 Oct 2006 22:40:31 +0200
> Boris Shteinbock <boris at fabiotec.com> wrote:
>
> > Hi ppl.
> >
> > I have discovered very very odd problem with SMC2 on my 8260 board.
> > kernel version is 2.6.17.
> >
> > The board is 8260 with serial ports on SMC1 and SMC 2 (SMC1 - console)
> >
> > Now if I use SMC2 for communicating with remote device, ( some protocol)
> > I am sending packets and wait for a response.
> > However if the packet I send is SMALLER than 5 bytes, SMC goes
> > completely crazy.
> > write() doesn't return error, but the next read() hangs completely, and the
> > process moves to D state and it is impossible to kill it by any means.
> > It only happens when consequent writes of smaller than 5 bytes.
> > I tried to check the driver, but couldn't find any clues to what goes wrong.
> >
> > I tried both compatibility and platform-based modes with the same results.
> >
> > Any help on the issue would be highliy appreciated.
> >
> >
>
> I think that should be walked along the cpm_uart driver, TX part to see is sending stuff
> do not indicate any error in the CPM registers, or at least discover exact track leading to the endless loop.
HI. I'm new here, but I encounted a very similar problem late last week....
Boris, I am willing to bet that your problem lies with the return
value from cpm_uart_tx_pump(). Here's the last few lines of that
function from 2.6.17 :
693 if (uart_circ_empty(xmit)) {
694 cpm_uart_stop_tx(port);
695 return 0;
696 }
697
698 return 1;
699 }
Note that return value is 0 if there is no more data in the tty's
circular queue (uart_circ_empty() returns true) This is the case when
you send a small packet. It seems appropriate to turn off the
transmitter (cpm_uart_stop_tx()) in the general case, but the problem
is that you never turned on the transmitter in the first place.....you
called cpm_uart_tx_pump() from cpm_uart_start_tx() like so:
195 if (cpm_uart_tx_pump(port) != 0) {
196 if (IS_SMC(pinfo)) {
197 smcp->smc_smcm |= SMCM_TX;
198 smcp->smc_smcmr |= SMCMR_TEN;
199 } else {
200 sccp->scc_sccm |= UART_SCCM_TX;
201 pinfo->sccp->scc_gsmrl |= SCC_GSMRL_ENT;
202 }
203 }
When you then attempt to close the port, you'll get stuck here, in
cpm_uart_shutdown():
455 /* Wait for all the BDs marked sent */
456 while(!cpm_uart_tx_empty(port)) {
457 set_current_state(TASK_UNINTERRUPTIBLE);
458 schedule_timeout(2);
459 }
Because the transmitter was never turned on, the bd will never be
processed by the CPM and cpm_uart_tx_empty() will always return false.
Recommendation: Change the first block of code above to: "return
(count != 0);" Now cpm_uart_tx_pump() will return true if data was
placed in a bd, instead of true when there is more data to be
processed later. This code works for me - but there are folks on this
list who would have a better idea about possible side
effects........anyone?
^ permalink raw reply
* Re: CPM2 (MPC8260) SMC problem. Please help.
From: Pantelis Antoniou @ 2006-10-23 16:09 UTC (permalink / raw)
To: Greg Lopp; +Cc: linuxppc-embedded
In-Reply-To: <f20416350610230902y78bd6740qc34e407004d6d511@mail.gmail.com>
On 23 =CE=9F=CE=BA=CF=84 2006, at 7:02 =CE=9C=CE=9C, Greg Lopp wrote:
>> On Wed, 18 Oct 2006 22:40:31 +0200
>> Boris Shteinbock <boris at fabiotec.com> wrote:
>>
>>> Hi ppl.
>>>
>>> I have discovered very very odd problem with SMC2 on my 8260 board.
>>> kernel version is 2.6.17.
>>>
>>> The board is 8260 with serial ports on SMC1 and SMC 2 (SMC1 - =20
>>> console)
>>>
>>> Now if I use SMC2 for communicating with remote device, ( some =20
>>> protocol)
>>> I am sending packets and wait for a response.
>>> However if the packet I send is SMALLER than 5 bytes, SMC goes
>>> completely crazy.
>>> write() doesn't return error, but the next read() hangs =20
>>> completely, and the
>>> process moves to D state and it is impossible to kill it by any =20
>>> means.
>>> It only happens when consequent writes of smaller than 5 bytes.
>>> I tried to check the driver, but couldn't find any clues to what =20
>>> goes wrong.
>>>
>>> I tried both compatibility and platform-based modes with the same =20=
>>> results.
>>>
>>> Any help on the issue would be highliy appreciated.
>>>
>>>
>>
>> I think that should be walked along the cpm_uart driver, TX part =20
>> to see is sending stuff
>> do not indicate any error in the CPM registers, or at least =20
>> discover exact track leading to the endless loop.
>
> HI. I'm new here, but I encounted a very similar problem late last =20
> week....
>
> Boris, I am willing to bet that your problem lies with the return
> value from cpm_uart_tx_pump(). Here's the last few lines of that
> function from 2.6.17 :
> 693 if (uart_circ_empty(xmit)) {
> 694 cpm_uart_stop_tx(port);
> 695 return 0;
> 696 }
> 697
> 698 return 1;
> 699 }
> Note that return value is 0 if there is no more data in the tty's
> circular queue (uart_circ_empty() returns true) This is the case when
> you send a small packet. It seems appropriate to turn off the
> transmitter (cpm_uart_stop_tx()) in the general case, but the problem
> is that you never turned on the transmitter in the first place.....you
> called cpm_uart_tx_pump() from cpm_uart_start_tx() like so:
> 195 if (cpm_uart_tx_pump(port) !=3D 0) {
> 196 if (IS_SMC(pinfo)) {
> 197 smcp->smc_smcm |=3D SMCM_TX;
> 198 smcp->smc_smcmr |=3D SMCMR_TEN;
> 199 } else {
> 200 sccp->scc_sccm |=3D UART_SCCM_TX;
> 201 pinfo->sccp->scc_gsmrl |=3D SCC_GSMRL_ENT;
> 202 }
> 203 }
>
> When you then attempt to close the port, you'll get stuck here, in
> cpm_uart_shutdown():
> 455 /* Wait for all the BDs marked sent */
> 456 while(!cpm_uart_tx_empty(port)) {
> 457 set_current_state(TASK_UNINTERRUPTIBLE);
> 458 schedule_timeout(2);
> 459 }
> Because the transmitter was never turned on, the bd will never be
> processed by the CPM and cpm_uart_tx_empty() will always return false.
>
> Recommendation: Change the first block of code above to: "return
> (count !=3D 0);" Now cpm_uart_tx_pump() will return true if data was
> placed in a bd, instead of true when there is more data to be
> processed later. This code works for me - but there are folks on this
> list who would have a better idea about possible side
> effects........anyone?
Yes, sounds true.
Since I was responsible for that, hand me the brown paper bag...
/me wears it.
Please send me a patch to process it.
Regards
Pantelis
^ permalink raw reply
* Re: [PATCH] General CHRP/MPC5K2 Platform and drivers support - to comment
From: Matt Sealey @ 2006-10-23 16:25 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linuxppc-dev
In-Reply-To: <20061023155257.GC15028@lst.de>
Very eloquently put.
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
Christoph Hellwig wrote:
> On Mon, Oct 23, 2006 at 04:47:49PM +0200, Matt Sealey wrote:
>> Curious question.
>>
>> What are you guys going to do when the PowerPC name is defunct?
>>
>> Like, last month :)
>>
>> Power Architecture is where it is at. The trademark is even going to
>> lapse. It's a bit too late for the ppc->powerpc tree breakout now,
>> but wouldn't it just confuse people to be using a "Power Architecture"
>> processor or SoC of some type, using collections of definitions from
>> the Power ISA 2.03 and have this "powerpc" thing pop up?
>
> Who the f***k cares. We've always given a chip what the newspeak party
> line of the days is, and we will here aswell. If the IBM/Mot/PowerYodda
> overlords are unhappy with that it's their problem, not ours.
>
^ permalink raw reply
* Re: RE: [PATCH] qe_ic: Do a sync when masking interrupts.
From: Michael R. Zucca @ 2006-10-23 15:30 UTC (permalink / raw)
To: Li Yang-r58472, Paul Mackerras, Wood Scott-B07421; +Cc: linuxppc-dev
>From: Li Yang-r58472 <LeoLi@freescale.com>
>
>But an i/o read will be considerably slower than a sync, and it is in
>the critical path of interrupt. I have tested the patch under
>relatively heavy Ethernet load, and there is no spurious interrupt.
>Maybe it is because the device is an SOC device and MMIO store completes
>faster. I'm wondering if there is a standard test method to show if the
>faster approach is sufficient or not.
All a sync tells you is that an I/O made it out of the CPU. The problem is, there may be other places a write could get hung up. For instance, sometimes devices sit behind a bridge with a write FIFO. In such a scenario, you can't be sure a write has made it to the device until you do a read to flush the FIFO.
If you're trying to figure out the minimum thing to do (eieio, sync, read-back, etc.) you have to understand what your system is doing between the store and the bits going into the register.
It may be that a sync is enough, but you won't know until you fully understand the system's bus/bridge topolgy between the CPU and the device.
^ permalink raw reply
* Re: RE: [PATCH] qe_ic: Do a sync when masking interrupts.
From: Michael R. Zucca @ 2006-10-23 15:32 UTC (permalink / raw)
To: Li Yang-r58472, Paul Mackerras, Wood Scott-B07421; +Cc: linuxppc-dev
>From: Li Yang-r58472 <LeoLi@freescale.com>
>
>But an i/o read will be considerably slower than a sync, and it is in
>the critical path of interrupt. I have tested the patch under
>relatively heavy Ethernet load, and there is no spurious interrupt.
>Maybe it is because the device is an SOC device and MMIO store completes
>faster. I'm wondering if there is a standard test method to show if the
>faster approach is sufficient or not.
All a sync tells you is that an I/O made it out of the CPU. The problem is, there may be other places a write could get hung up. For instance, sometimes devices sit behind a bridge with a write FIFO. In such a scenario, you can't be sure a write has made it to the device until you do a read to flush the FIFO.
If you're trying to figure out the minimum thing to do (eieio, sync, read-back, etc.) you have to understand what your system is doing between the store and the bits going into the register.
It may be that a sync is enough, but you won't know until you fully understand the system's bus/bridge topolgy between the CPU and the device.
^ permalink raw reply
* [PATCH] IPIC: Don't call set_irq_handler with desc->lock held.
From: Scott Wood @ 2006-10-23 16:35 UTC (permalink / raw)
To: linuxppc-dev
This patch causes ipic_set_irq_type to set the handler directly rather
than call set_irq_handler, which causes spinlock recursion because
the lock is already held when ipic_set_irq_type is called.
I'm also not convinced that ipic_set_irq_type should be changing the
handler at all. There seem to be several controllers that don't and
several that do. Those that do would break what appears to be a common
usage of calling set_irq_chip_and_handler followed by set_irq_type, if a
non-standard handler were to be used. OTOH, irq_create_of_mapping()
doesn't set the handler, but only calls set_irq_type().
This patch gets things working in the spinlock-debugging-enabled case,
but I'm curious as to where the handler setting is ideally supposed to be
done. I don't see any documentation on set_irq_type() that clarifies
what the semantics are supposed to be.
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
arch/powerpc/sysdev/ipic.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/sysdev/ipic.c b/arch/powerpc/sysdev/ipic.c
index bc4d4a7..746f78c 100644
--- a/arch/powerpc/sysdev/ipic.c
+++ b/arch/powerpc/sysdev/ipic.c
@@ -473,9 +473,9 @@ static int ipic_set_irq_type(unsigned in
desc->status |= flow_type & IRQ_TYPE_SENSE_MASK;
if (flow_type & IRQ_TYPE_LEVEL_LOW) {
desc->status |= IRQ_LEVEL;
- set_irq_handler(virq, handle_level_irq);
+ desc->handle_irq = handle_level_irq;
} else {
- set_irq_handler(virq, handle_edge_irq);
+ desc->handle_irq = handle_edge_irq;
}
/* only EXT IRQ senses are programmable on ipic
--
1.4.2.3
^ permalink raw reply related
* Re: [PATCH] General CHRP/MPC5K2 Platform and drivers support - to comment
From: Segher Boessenkool @ 2006-10-23 16:40 UTC (permalink / raw)
To: Matt Sealey; +Cc: linuxppc-dev
In-Reply-To: <453CD615.4050401@genesi-usa.com>
> What are you guys going to do when the PowerPC name is defunct?
>
> Like, last month :)
If some marketeers want to rewrite history, let them try; but we
cannot, simply because we use Git. Keeps people honest ;-)
Segher
^ permalink raw reply
* Re: [PATCH] qe_ic: Do a sync when masking interrupts.
From: Segher Boessenkool @ 2006-10-23 16:49 UTC (permalink / raw)
To: mrz5149; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <11892067.4322551161617453238.JavaMail.root@vms069.mailsrvcs.net>
> ll a sync tells you is that an I/O made it out of the CPU. The
> problem is, there may be other places a write could get hung up.
> For instance, sometimes devices sit behind a bridge with a write
> FIFO. In such a scenario, you can't be sure a write has made it to
> the device until you do a read to flush the FIFO.
It's not enough that a write made it to the device even -- you
have to make sure the device has acted on it.
> If you're trying to figure out the minimum thing to do (eieio,
> sync, read-back, etc.) you have to understand what your system is
> doing between the store and the bits going into the register.
What the system is doing, and also what exactly you want to
accomplish (what ordering and what completion you depend on).
> It may be that a sync is enough, but you won't know until you fully
> understand the system's bus/bridge topolgy between the CPU and the
> device.
If a sync after an MMIO write is enough, then (in almost all
cases) so is an eieio.
Segher
^ permalink raw reply
* ARCH=powerpc: IRQ numbers change mysteriously
From: Fredrik Roubert @ 2006-10-23 16:41 UTC (permalink / raw)
To: linuxppc-embedded
Hi!
On my MPC8439 based board, running Linux 2.6.18 with ARCH=powerpc, the
IRQ's for the I2C behave in a for me mysterious way.
In my DTS file, I have the following:
i2c@3000 {
device_type = "i2c";
compatible = "fsl-i2c";
reg = <3000 100>;
interrupts = <e 8>;
interrupt-parent = <&/soc8349@ff400000/pic@700>;
dfsrr;
};
i2c@3100 {
device_type = "i2c";
compatible = "fsl-i2c";
reg = <3000 100>;
interrupts = <f 8>;
interrupt-parent = <&/soc8349@ff400000/pic@700>;
dfsrr;
};
But when I boot the system and cat /proc/interrupts, the output says:
18: 61 IPIC Level i2c-mpc
19: 0 IPIC Level i2c-mpc
This doesn't make sense to me. Why are the IRQ numbers changed? They are
still adjacent, so it seems to be some logic to the change. Does anyone
know what this is?
Cheers // Fredrik Roubert
--
Barco Medical Imaging | +32 56 233549
http://www.barco.com/medical/ | fredrik.roubert@barco.com
^ permalink raw reply
* Re: CPM2 (MPC8260) SMC problem. Please help.
From: Vitaly Bordug @ 2006-10-23 17:23 UTC (permalink / raw)
To: Pantelis Antoniou; +Cc: linuxppc-embedded
In-Reply-To: <247D8ECE-79CC-4BA2-A902-D86802E50335@gmail.com>
[...]
> >>
> >> I think that should be walked along the cpm_uart driver, TX part
> >> to see is sending stuff
> >> do not indicate any error in the CPM registers, or at least
> >> discover exact track leading to the endless loop.
> >
> > HI. I'm new here, but I encounted a very similar problem late last
> > week....
> >
> > Boris, I am willing to bet that your problem lies with the return
> > value from cpm_uart_tx_pump(). Here's the last few lines of that
> > function from 2.6.17 :
> > 693 if (uart_circ_empty(xmit)) {
> > 694 cpm_uart_stop_tx(port);
> > 695 return 0;
> > 696 }
> > 697
> > 698 return 1;
> > 699 }
> > Note that return value is 0 if there is no more data in the tty's
> > circular queue (uart_circ_empty() returns true) This is the case when
> > you send a small packet. It seems appropriate to turn off the
> > transmitter (cpm_uart_stop_tx()) in the general case, but the problem
> > is that you never turned on the transmitter in the first place.....you
> > called cpm_uart_tx_pump() from cpm_uart_start_tx() like so:
> > 195 if (cpm_uart_tx_pump(port) != 0) {
> > 196 if (IS_SMC(pinfo)) {
> > 197 smcp->smc_smcm |= SMCM_TX;
> > 198 smcp->smc_smcmr |= SMCMR_TEN;
> > 199 } else {
> > 200 sccp->scc_sccm |= UART_SCCM_TX;
> > 201 pinfo->sccp->scc_gsmrl |= SCC_GSMRL_ENT;
> > 202 }
> > 203 }
> >
> > When you then attempt to close the port, you'll get stuck here, in
> > cpm_uart_shutdown():
> > 455 /* Wait for all the BDs marked sent */
> > 456 while(!cpm_uart_tx_empty(port)) {
> > 457 set_current_state(TASK_UNINTERRUPTIBLE);
> > 458 schedule_timeout(2);
> > 459 }
> > Because the transmitter was never turned on, the bd will never be
> > processed by the CPM and cpm_uart_tx_empty() will always return false.
> >
> > Recommendation: Change the first block of code above to: "return
> > (count != 0);" Now cpm_uart_tx_pump() will return true if data was
> > placed in a bd, instead of true when there is more data to be
> > processed later. This code works for me - but there are folks on this
> > list who would have a better idea about possible side
> > effects........anyone?
>
> Yes, sounds true.
>
> Since I was responsible for that, hand me the brown paper bag...
>
> /me wears it.
>
> Please send me a patch to process it.
>
Hey, not that rough :)
I used to add some bits and "cpm_uart_tx_empty() will always return false" is mine as well.
Greg:
Patch/code snippet from working tree welcome, and I'll address it anyway since it looks like generic issue.
Thanks.
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: [PATCH] qe_ic: Do a sync when masking interrupts.
From: Kumar Gala @ 2006-10-23 17:52 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <453CDD70.9010100@freescale.com>
On Oct 23, 2006, at 10:19 AM, Scott Wood wrote:
> Paul Mackerras wrote:
>> Hmmm. In general a sync having completed doesn't mean that previous
>> MMIO stores have actually got to the device. Reading from a device
>> register generally does ensure that previous writes have actually got
>> to the device though - could you do that instead? I'm concerned that
>> adding the sync is not a robust fix and is possibly only working due
>> to fortuitous timing.
>
> Possibly -- but the only problem on the rare occasions where the
> timing
> is not fortuitous is a spurious interrupt; the only reason the sync
> needs to be there at all is to avoid the overhead of the extra
> interrupt
> (and to avoid user complaints that they're getting "BAD" interrupts).
Why wouldn't the read accomplish the same thing in a more robust way
than the sync?
- k
^ permalink raw reply
* Re: [PATCH] qe_ic: Do a sync when masking interrupts.
From: Scott Wood @ 2006-10-23 18:22 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <E8190CD2-1898-473E-812A-AE2CBD85D73A@kernel.crashing.org>
Kumar Gala wrote:
>
> On Oct 23, 2006, at 10:19 AM, Scott Wood wrote:
>> Possibly -- but the only problem on the rare occasions where the timing
>> is not fortuitous is a spurious interrupt; the only reason the sync
>> needs to be there at all is to avoid the overhead of the extra interrupt
>> (and to avoid user complaints that they're getting "BAD" interrupts).
>
>
> Why wouldn't the read accomplish the same thing in a more robust way
> than the sync?
It would. However, it also adds a small amount of overhead to every QE
interrupt, and the only thing that that overhead buys is avoiding
possible but empirically very rare spurious interrupts; it'd cost more
than simply accepting that a spurious interrupt might happen once in a
great while.
Without any type of sync, spurious interrupts happen fairly regularly
(about 5-10% of legitimate interrupts), so adding the sync should be a
net gain over doing nothing.
If the consensus is that a read should be done anyway, I can resumbit
the patch that way; I just think it's overkill given that a 100%
guarantee isn't required for correctness.
-Scott
^ permalink raw reply
* Re: [PATCH] qe_ic: Do a sync when masking interrupts.
From: Scott Wood @ 2006-10-23 18:27 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Paul Mackerras, linuxppc-dev
In-Reply-To: <F886CBFA-4710-4185-AA99-92EDEE3F2FE8@kernel.crashing.org>
Segher Boessenkool wrote:
> If a sync after an MMIO write is enough, then (in almost all
> cases) so is an eieio.
In this case, the spurious interrupts still happen with eieio, but not
with sync. It's probably synchronizing the MMIO write with some
unrelated load from memory (such as reading the stack frame to return
from the mask function, or reading action->flags to determine whether to
check for IRQ_DISABLED).
-Scott
^ permalink raw reply
* Re: [PATCH] qe_ic: Do a sync when masking interrupts.
From: Segher Boessenkool @ 2006-10-23 18:46 UTC (permalink / raw)
To: Scott Wood; +Cc: Paul Mackerras, linuxppc-dev
In-Reply-To: <453D097D.6090603@freescale.com>
>> If a sync after an MMIO write is enough, then (in almost all
>> cases) so is an eieio.
>
> In this case, the spurious interrupts still happen with eieio, but
> not with sync. It's probably synchronizing the MMIO write with
> some unrelated load from memory (such as reading the stack frame to
> return from the mask function, or reading action->flags to
> determine whether to check for IRQ_DISABLED).
Yes, it sure sounds like the only reason the sync insn helps
is that it causes a (small) delay. If you document this (and
also that it isn't required for correctness) in the code, I
don't think anyone will complain / be curious about it anymore.
Segher
^ permalink raw reply
* xapp902 with 2.6.17 -- uartlite & ramdisk problems
From: robert corley @ 2006-10-23 18:49 UTC (permalink / raw)
To: David Bolcsfoldi; +Cc: linux linuxppc-embedded
David et al;=0A=0AIn my seemingly neverending effort to get linux up on the=
ML403, I went the route David B. did and worked with the xapp902 reference=
desing. I have met with a little success and appeal for some assistance..=
.=0A=0A1. The uart is dog slow. I suspect it has to do with interrupts =
(note the console dump below). I see this line:=0A=0A [ 2.637345] u=
artlite.0: ttyUL0 at MMIO 0xa0000000 (irq =3D =0A=0A and I think that th=
e interrupt isn't properly registered with the PIC. What do you think?=0A=
=0A2. Can you look below and comment on the ram disk size? I am not sur=
e what this value should be. My ramdisk=0A image is 4658942 bytes. I r=
ecall reading somewhere that the value for the initrd ram disk should be ab=
out 10k larger =0A than the ramdisk size to allow for decompression. Th=
e # of pages and page size is throwing me off. Comments?=0A=0A-corley=0A=
=0A=0A=0A=0A=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
console dump =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=0A[ 0.000000] Linux version 2.6.17.1 (rdcorle@athe=
na) (gcc version 3.4.2) #2 Mon Oct 23 17:58:11 UTC 2006 =
=0A[ 0.000000] Xilinx ML403 Reference System (Virtex-4 FX) =
=0A[ 0.000000] Built 1=
zonelists =0A[ 0.000000] Kernel command =
line: console=3DttyUL0 single ip=3Doff root=3D/dev/ram rw =0A[ 0.000000]=
Xilinx INTC #0 at 0xD1000FC0 mapped to 0xFDFFFFC0 =
=0A[ 0.000000] PID hash table ent=
ries: 512 (order: 9, 2048 bytes) =
=0A[ 0.000151] Console: colour dummy device 80x25 =
=0A[ 0.000560] Dentry ca=
che hash table entries: 8192 =
=0A[ 0.001271] Inode-cache hash table entries: 4096 (order: 2, 1638=
4 bytes) =
=0A[ 0.013924] Memory: 58572k available (1348k kernel code, 344k=
data, 80k init, 0k highmem) =0A[ 0.200435] Mount-cache hash =
table entries: 512 =0A[ =
0.203108] checking if image is initramfs...it isn't (no cpio magic); looks=
like an initrd =0A[ 2.504612] Freeing initrd memory: 4549k=
freed =0A[ 2.508719] NE=
T: Registered protocol family 16 =
=0A[ 2.518260] NET: Registered protocol family 2 =
=0A[ 2.583989] IP route cache hash table e=
ntries: 51 =0A[ 2.58446=
7] TCP established hash table entries: 2048 (order: 3, 32768 bytes) =
=0A[=
2.584936] TCP bind hash table entries: 1024 (order: 2, 20480 bytes) =
=0A[ =
2.585222] TCP: Hash tables configured (established 2048 bind 1024) =
=0A[ 2.58=
5257] TCP reno registered =0A[ 2.591657=
] io scheduler noop registered =
=0A[ 2.591817] io scheduler anticipatory registered (default) =
=0A[ 2.591912] io sche=
duler deadline registered =0A=
[ 2.592049] io scheduler cfq registered =
=0A[ 2.637345] uartlite.0: ttyUL0 at MMIO 0xa0000000 (irq =3D =
=0A[ 40.942337] R=
AMDISK driver initialized: 16 RAM disks of 4096K size 1024 block size =
=0A[ 42.944862] eth%d: XTemac using sgDMA mode. =
=0A[ 44.072738] eth%d: XTemac buffer_descriptor_space=
: phy: 0xbb8000, virt: 0xff1 00000, size: 0x5000 =0A[ 4=
6.424830] eth0: Xilinx TEMAC #0 at 0x60000000 mapped to 0xC5008000, irq=3D0=
=
=0A[ 48.289878] mice: PS/2 mouse device common for all mice =
=0A[ 49.694042] TCP bic re=
gistered =0A[ 50.524157] RAMDISK: Compres=
sed image found at block 0 =
=0A[ 52.672304] RAMDISK: incomplete write (-28 !=3D 3276 =
=0A[ 56.000551] VFS: Mounted ro=
ot (ext2 filesystem). =0A=
[ 57.243671] Freeing unused kernel memory: 80k init =
=0A[ 58.579050] attempt to access beyond e=
nd of device =0A[ 59.=
867968] ram0: rw=3D0, want=3D10018, limit=3D8192 =
=0A[ 61.064912] Buffer I/O error on device ram0, lo=
gical block 5008 =
=0A[ 62.653149] attempt to access beyond end of device =
=0A[ 63.942154] ram0: rw=3D0, wa=
nt=3D10020, limit=3D8192 =
=0A[ 65.139082] Buffer I/O error on device ram0, logical block 5009 =
=0A[ 66.72730=
5] attempt to access beyond end of device =
=0A[ 68.016306] ram0: rw=3D0, want=3D10022, limit=3D81=
92 =0A[ 69.212688] BUG: s=
oft lockup detected on CPU#0! =
=0A[ 69.212711] Call Trace: =0A[ 69.212733=
] [C024F780] [C000906C] show_stack+0x48/0x194 (unreliable) =
=0A[ 69.212808] [C0=
24F7C0] [C0031874] softlockup_tick+0xb4/0xd0 =
=0A[ 69.212853] [C024F7E0] [C001DDE8] run_=
local_timers+0x18/0x28 =
=0A[ 69.212905] [C024F7F0] [C001DE70] update_process_times+0x78=
/0xb4 =0A=
[ 69.212956] [C024F810] [C00045B4] timer_interrupt+0xd4/0x204 =
=0A[ 69.213000] [C024F=
850] [C000351C] ret_from_except+0x0/ =
=0A[ 69.213043] [C024F910] [C0015A9C] release_console_se=
m+0xe0/0x284 =
=0A[ 69.213105] [C024F950] [C0015DF4] vprintk+0x1b4/0x384 =
=0A[ 69.213149] [C024F9F0] [C=
0016014] printk+0x50/0x60 =
=0A[ 69.213189] [C024FA70] [C00B98DC] generic_make_request+0xc0/0x20c =
=0A[ 6=
9.213252] [C024FAB0] [C00B9AA8] submit_bio+0x80/0xd8 =
=0A[ 69.213294] [C024FAF0] [C005602C] s=
ubmit_bh+0x14c/0x1a0 =
=0A[ 69.213342] [C024FB10] [C005854C] block_read_full_page+0x310/0x328=
=0A[ =
69.213391] [C024FB80] [C007D4FC] do_mpage_readpage+0x38c/0x538 =
=0A[ 69.213437] [C0=
24FC00] [C007D880] mpage_readpage+0x50/0x78 =
=0A[ 69.213477] [C024FC50] [C00B0120] ext2_r=
eadpage+0x1c/0x2c =
=0A[ 69.213516] [C024FC60] [C0034824] read_cache_page+0xf8/0x208 =
=0A[ 69.213562] [=
C024FC90] [C00AD490] ext2_get_page+0x24/0x308 =
=0A[ 69.213623] [C024FCC0] [C00ADAE8] ext2=
_find_entry+0x7c/0x17c =0A[ 69.213663] [C024FD10] [C00ADC=
78] ext2_inode_by_name+0x18/0x58=0A[ 69.213704] [C024FD30] [C00B191C] ext=
2_lookup+0x54/0xd8=0A[ 69.213744] [C024FD50] [C0062E4C] do_lookup+0x138/0=
x19c=0A[ 69.213793] [C024FD80] [C0063918] __link_path_walk+0x8f4/0x1014=
=0A[ 69.213837] [C024FDD0] [C00640C0] link_path_walk+0x88/0x150=0A[ 69.=
213879] [C024FE40] [C006432C] do_path_lookup+0x1a4/0x2b8=0A[ 69.213924] [=
C024FE70] [C006452C] __path_lookup_intent_open+0x58/0xb8=0A[ 69.213971] [=
C024FEA0] [C0064F14] open_namei+0x70/0x6dc=0A[ 69.214015] [C024FEE0] [C00=
519E4] do_filp_open+0x30/0x78=0A[ 69.214056] [C024FF50] [C0051E04] do_sys=
_open+0x70/0x10c=0A[ 69.214095] [C024FF80] [C0002618] init+0x274/0x2e0=0A=
[ 69.214137] [C024FFF0] [C00051FC] kernel_thread+0x44/0x60=0A[ 117.44526=
1] Buffer I/O error on device ram0, logical block 5010=0A[ 119.033233] att=
empt to access beyond end of device=0A[ 120.322015] ram0: rw=3D0, want=3D1=
0018, limit=3D8192=0A[ 121.518738] Buffer I/O error on device ram0, logica=
l block 5008=0A[ 123.106686] attempt to access beyond end of device=0A[ 1=
24.395468] ram0: rw=3D0, want=3D10020, limit=3D8192=0A[ 125.592200] Buffer=
I/O error on device ram0, logical block 5009=0A[ 127.180152] attempt to a=
ccess beyond end of device=0A[ 128.468929] ram0: rw=3D0, want=3D10022, lim=
it=3D8192=0A[ 129.665650] Buffer I/O error on device ram0, logical block 5=
010=0A[ 131.253675] attempt to access beyond end of device=0A[ 132.542475=
] ram0: rw=3D0, want=3D100=0A=0A
^ permalink raw reply
* [PATCH] qe_ic: Do a sync when masking interrupts.
From: Scott Wood @ 2006-10-23 18:53 UTC (permalink / raw)
To: linuxppc-dev
This patch causes a sync do be done after masking a QE interrupt, to
ensure that the masking has completed before interrupts are enabled.
This allows the masking of the cascade IRQ to be removed without causing
spurious interrupts.
The mask_and_ack function is also removed and set to the mask function,
as the two are identical.
This is the second version of this patch; this version clarifies why a
sync was chosen rather than a read-back, and it fixes unused variable
warnings where the cascade mask was removed.
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
arch/powerpc/sysdev/qe_lib/qe_ic.c | 40 +++++++++---------------------------
1 files changed, 10 insertions(+), 30 deletions(-)
diff --git a/arch/powerpc/sysdev/qe_lib/qe_ic.c b/arch/powerpc/sysdev/qe_lib/qe_ic.c
index 6995f51..74e48d9 100644
--- a/arch/powerpc/sysdev/qe_lib/qe_ic.c
+++ b/arch/powerpc/sysdev/qe_lib/qe_ic.c
@@ -223,23 +223,15 @@ static void qe_ic_mask_irq(unsigned int
qe_ic_write(qe_ic->regs, qe_ic_info[src].mask_reg,
temp & ~qe_ic_info[src].mask);
- spin_unlock_irqrestore(&qe_ic_lock, flags);
-}
-
-static void qe_ic_mask_irq_and_ack(unsigned int virq)
-{
- struct qe_ic *qe_ic = qe_ic_from_irq(virq);
- unsigned int src = virq_to_hw(virq);
- unsigned long flags;
- u32 temp;
-
- spin_lock_irqsave(&qe_ic_lock, flags);
-
- temp = qe_ic_read(qe_ic->regs, qe_ic_info[src].mask_reg);
- qe_ic_write(qe_ic->regs, qe_ic_info[src].mask_reg,
- temp & ~qe_ic_info[src].mask);
-
- /* There is nothing to do for ack here, ack is handled in ISR */
+ /* Flush the above write before enabling interrupts; otherwise,
+ * spurious interrupts will sometimes happen. To be 100% sure
+ * that the write has reached the device before interrupts are
+ * enabled, the mask register would have to be read back; however,
+ * this is not required for correctness, only to avoid wasting
+ * time on a large number of spurious interrupts. In testing,
+ * a sync reduced the observed spurious interrupts to zero.
+ */
+ mb();
spin_unlock_irqrestore(&qe_ic_lock, flags);
}
@@ -248,7 +240,7 @@ static struct irq_chip qe_ic_irq_chip =
.typename = " QEIC ",
.unmask = qe_ic_unmask_irq,
.mask = qe_ic_mask_irq,
- .mask_ack = qe_ic_mask_irq_and_ack,
+ .mask_ack = qe_ic_mask_irq,
};
static int qe_ic_host_match(struct irq_host *h, struct device_node *node)
@@ -331,34 +323,22 @@ unsigned int qe_ic_get_high_irq(struct q
return irq_linear_revmap(qe_ic->irqhost, irq);
}
-/* FIXME: We mask all the QE Low interrupts while handling. We should
- * let other interrupt come in, but BAD interrupts are generated */
void fastcall qe_ic_cascade_low(unsigned int irq, struct irq_desc *desc)
{
struct qe_ic *qe_ic = desc->handler_data;
- struct irq_chip *chip = irq_desc[irq].chip;
-
unsigned int cascade_irq = qe_ic_get_low_irq(qe_ic);
- chip->mask_ack(irq);
if (cascade_irq != NO_IRQ)
generic_handle_irq(cascade_irq);
- chip->unmask(irq);
}
-/* FIXME: We mask all the QE High interrupts while handling. We should
- * let other interrupt come in, but BAD interrupts are generated */
void fastcall qe_ic_cascade_high(unsigned int irq, struct irq_desc *desc)
{
struct qe_ic *qe_ic = desc->handler_data;
- struct irq_chip *chip = irq_desc[irq].chip;
-
unsigned int cascade_irq = qe_ic_get_high_irq(qe_ic);
- chip->mask_ack(irq);
if (cascade_irq != NO_IRQ)
generic_handle_irq(cascade_irq);
- chip->unmask(irq);
}
void __init qe_ic_init(struct device_node *node, unsigned int flags)
--
1.4.2.3
^ permalink raw reply related
* Crash with highmem support enabled
From: Gerhard Pircher @ 2006-10-23 18:57 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1161474692.10524.266.camel@localhost.localdomain>
Hi,
I'm trying to get highmem support working on my AmigaOne. The machine is equipped with 1.5G RAM. Unfortunately the kernel crashes early in the boot process, so I couldn't save the crash log. But it seems to crash during the initialization of the radeonfb driver.
I guess this has something to do with the IO block mapping, which is implemented in the amigaone_setup.c file and looks like this:
{
/* Remap ISA/PCI IO space first to get it mapped by BATs. */
io_block_mapping(0xfe000000, 0xfe000000, 0x01000000, _PAGE_IO);
/* Remap ISA memory for framebuffer (U-boot framebuffer). */
io_block_mapping(0xfd000000, 0xfd000000, 0x01000000, _PAGE_IO);
/* Remap PROM I/O space to 0xfc000000, to get a window for non
* cache coherent DMA support at 0xff100000.
*/
io_block_mapping(0xfc000000, 0xff000000, 0x01000000, _PAGE_IO);
}
The addresses below 0xfc000000 belong to the PCI memory space (0x80000000-0xfbffffff).
Thus I moved the highmem base to 0xfc000000, since the PCI memory is not ioremap'd. But the kernel still crashes.
Can somebody give me a hint how to get highmem working? I'm not sure what the real problem is, as also other platforms (PReP, sandpoint) ioremap the address space from 0xfe000000 to 0xffffffff.
Gerhard
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
^ permalink raw reply
* [PATCH] Fixed some missing files to be deleted when running make clean
From: Matthew McClintock @ 2006-10-23 19:26 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20061012013223.GA9143@mag.az.mvista.com>
Fixed some missing files to be deleted when running make clean
Signed-off-by: Matthew McClintock <msm@freescale.com>
---
These patches apply against the latest series of Mark's bootwrapper
patches. They fix some missing files that need to be cleaned.
commit b05c2cae79ba02edd7263e19fe5f722c67c3c5cb
tree 3016e7e0f0b84d36ded2ec1c1ff5efe98cc94d4c
parent 44ae8267b3597965b485669885ff68384640b95a
author Matthew McClintock <msm@freescale.com> Mon, 23 Oct 2006 14:09:47
-0500
committer Matthew McClintock <msm@freescale.com> Mon, 23 Oct 2006
14:09:47 -0500
arch/powerpc/boot/Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 8e33890..43507ca 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -75,7 +75,7 @@ quiet_cmd_copy_zliblinuxheader = COPY
@cp $< $@
clean-files := $(zlib) $(zlibheader) $(zliblinuxheader) \
- $(obj)/empty.c
+ empty.c zImage.coff.lds zImage.lds zImage.sandpoint
quiet_cmd_bootcc = BOOTCC $@
cmd_bootcc = $(CROSS32CC) -Wp,-MD,$(depfile) $(BOOTCFLAGS) -c -o
$@ $<
^ permalink raw reply related
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