* [PATCH 3/4] [MIPS] Allow platform to override default timer and performance counter interrupts
From: Thomas Koeller @ 2007-12-18 0:26 UTC (permalink / raw)
To: linux-mips; +Cc: ralf
While there was a platform hook for setting the compare timer interrupt
before, it was implemented in a somewhat arkward way, and no such hook
existed for the performance counter interrupt. This change aims at a
cleaner solution, by using the platform-supplied values right from the
beginning instead of setting up the standard irq first, and then
ignoring it.
Signed-off-by: Thomas Koeller <thomas.koeller@baslerweb.com>
diff --git a/arch/mips/kernel/cevt-r4k.c b/arch/mips/kernel/cevt-r4k.c
index 24a2d90..3b1407e 100644
--- a/arch/mips/kernel/cevt-r4k.c
+++ b/arch/mips/kernel/cevt-r4k.c
@@ -9,6 +9,7 @@
#include <linux/clockchips.h>
#include <linux/interrupt.h>
#include <linux/percpu.h>
+#include <linux/kernel.h>
#include <asm/smtc_ipi.h>
#include <asm/time.h>
@@ -76,8 +77,8 @@ static irqreturn_t c0_compare_interrupt(int irq, void
*dev_id)
{
const int r2 = cpu_has_mips_r2;
struct clock_event_device *cd;
- int cpu = smp_processor_id();
-
+ const int cpu = smp_processor_id();
+
/*
* Suckage alert:
* Before R2 of the architecture there was no way to see if a
@@ -169,9 +170,6 @@ static void mips_event_handler(struct clock_event_device
*dev)
{
}
-/*
- * FIXME: This doesn't hold for the relocated E9000 compare interrupt.
- */
static int c0_compare_int_pending(void)
{
return (read_c0_cause() >> cp0_compare_irq) & 0x100;
@@ -183,7 +181,8 @@ static int c0_compare_int_usable(void)
unsigned int cnt;
/*
- * IP7 already pending? Try to clear it by acking the timer.
+ * Compare interrupt already pending?
+ * Try to clear it by acking the timer.
*/
if (c0_compare_int_pending()) {
write_c0_compare(read_c0_count());
@@ -221,8 +220,8 @@ static int c0_compare_int_usable(void)
int __cpuinit mips_clockevent_init(void)
{
- uint64_t mips_freq = mips_hpt_frequency;
- unsigned int cpu = smp_processor_id();
+ const uint64_t mips_freq = mips_hpt_frequency;
+ const unsigned int cpu = smp_processor_id();
struct clock_event_device *cd;
unsigned int irq;
@@ -240,17 +239,12 @@ int __cpuinit mips_clockevent_init(void)
return 0;
#endif
- if (!c0_compare_int_usable())
+ if (!c0_compare_int_usable()) {
+ pr_crit("MIPS compare interrupt not working - no timer clock\n");
return -ENXIO;
+ }
- /*
- * With vectored interrupts things are getting platform specific.
- * get_c0_compare_int is a hook to allow a platform to return the
- * interrupt number of it's liking.
- */
irq = MIPS_CPU_IRQ_BASE + cp0_compare_irq;
- if (get_c0_compare_int)
- irq = get_c0_compare_int();
cd = &per_cpu(mips_clockevent_device, cpu);
diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c
index fcae667..268247d 100644
--- a/arch/mips/kernel/traps.c
+++ b/arch/mips/kernel/traps.c
@@ -1281,6 +1281,20 @@ extern void flush_tlb_handlers(void);
*/
int cp0_compare_irq;
+unsigned int __init __weak
+get_c0_compare_int(void)
+{
+ return cpu_has_mips_r2 ?
+ (read_c0_intctl() >> 29) & 7 : CP0_LEGACY_COMPARE_IRQ;
+}
+
+unsigned int __init __weak
+get_c0_perfcount_int(void)
+{
+ return cpu_has_mips_r2 ?
+ (read_c0_intctl() >> 26) & 7 : -1;
+}
+
/*
* Performance counter IRQ or -1 if shared with timer
*/
@@ -1352,21 +1366,11 @@ void __init per_cpu_trap_init(void)
set_c0_cause(CAUSEF_IV);
}
- /*
- * Before R2 both interrupt numbers were fixed to 7, so on R2 only:
- *
- * o read IntCtl.IPTI to determine the timer interrupt
- * o read IntCtl.IPPCI to determine the performance counter interrupt
- */
- if (cpu_has_mips_r2) {
- cp0_compare_irq = (read_c0_intctl() >> 29) & 7;
- cp0_perfcount_irq = (read_c0_intctl() >> 26) & 7;
- if (cp0_perfcount_irq == cp0_compare_irq)
- cp0_perfcount_irq = -1;
- } else {
- cp0_compare_irq = CP0_LEGACY_COMPARE_IRQ;
+ /* Set up timer & performance counter interrupts */
+ cp0_compare_irq = get_c0_compare_int();
+ cp0_perfcount_irq = get_c0_perfcount_int();
+ if (cp0_perfcount_irq == cp0_compare_irq)
cp0_perfcount_irq = -1;
- }
#ifdef CONFIG_MIPS_MT_SMTC
}
diff --git a/include/asm-mips/time.h b/include/asm-mips/time.h
index 7717934..be0d157 100644
--- a/include/asm-mips/time.h
+++ b/include/asm-mips/time.h
@@ -59,7 +59,8 @@ extern int (*perf_irq)(void);
*/
#ifdef CONFIG_CEVT_R4K
extern int mips_clockevent_init(void);
-extern unsigned int __weak get_c0_compare_int(void);
+extern unsigned int get_c0_compare_int(void);
+extern unsigned int get_c0_perfcount_int(void);
#else
static inline int mips_clockevent_init(void)
{
--
1.5.3.6
^ permalink raw reply related
* [PATCH 2/4] [MIPS] Fix interrupt enable/disable hazards for RM9000
From: Thomas Koeller @ 2007-12-18 0:26 UTC (permalink / raw)
To: linux-mips; +Cc: ralf
The no-op hazards present before this caused
c0_compare_int_usable() in arch/mips/kernel/cevt-r4k.c
to fail.
Signed-off-by: Thomas Koeller <thomas.koeller@baslerweb.com>
diff --git a/include/asm-mips/hazards.h b/include/asm-mips/hazards.h
index 2de638f..6454d66 100644
--- a/include/asm-mips/hazards.h
+++ b/include/asm-mips/hazards.h
@@ -176,8 +176,10 @@ ASMMACRO(tlb_probe_hazard,
_ssnop; _ssnop; _ssnop; _ssnop
)
ASMMACRO(irq_enable_hazard,
+ _ssnop; _ssnop; _ssnop; _ssnop
)
ASMMACRO(irq_disable_hazard,
+ _ssnop; _ssnop; _ssnop; _ssnop
)
ASMMACRO(back_to_back_c0_hazard,
)
--
1.5.3.6
^ permalink raw reply related
* excite patches
From: Thomas Koeller @ 2007-12-18 0:31 UTC (permalink / raw)
To: linux-mips; +Cc: ralf
Here is a series of patches to bring the excite platform up to date. In
order to achieve this, I had to apply a couple of changes to some
non-platform code as well:
Patch 1/4:
This one introduces a new configuration parameter named GPI_RM9000, used
to enable devices that depend on RM9000-style GPI hardware. This is a
re-submit, I submitted this patch before, but it has not been applied yet.
Patch 2/4:
The RM9000 hazards in include/asm-mips/hazards.h were apparently wrong; I
could not get c0_compare_int_usable() in arch/mips/kernel/cevt-r4k.c to
work. The RM9122 manual says, "When a CP0 register is changed by an MTC0
or CTC0 instruction, the contents of the changed register must not be used
for 4 cycles after the MTC0 or CTC0 is issued. Specifically, if a CP0
register is loaded, its contents must not be read back or otherwise used
until 4 cycles later." I guess this also covers the case of observing
the result of writing to a CP0 register by reading the contents of
another CP0 register, as in this case.
Patch 3/4:
Since the excite platform uses the RM9000's alternate timer interrupt, I
had to rework the compare interrupt setup. I changed the existing
get_c0_compare_int() hook to be called earlier than before, so that
cp0_compare_irq contains the correct value right from the start, and
functions like c0_compare_int_pending() and c0_compare_int_usable()
continue to function without any need for modifications. Then I added a
get_c0_perfcounter_int() hook to complement it. I also did some
minor modifications, like adding 'const' in some places, and outputting
an error message if the compare interrupt is found to be non-functional,
a condition that certainly deserves such a message.
Since the get_c0_compare_int() hook is used in
arch/mips/mips-boards/generic/time.c,
users of this file might theoretically be affected by this change. I do not
have
access to these boards, so I could not check, however, I believe the
change does not cause any breakage here.
Patch 4/4:
Finally, the excite platform has to supply the alternate compare irq, which
this patch is for.
tk
--
_______________________________
Thomas Köller, Software Developer
Basler Vision Technologies
An der Strusbek 60-62
22926 Ahrensburg
Germany
Tel. +49 (0) 4102 - 463 390
Fax +49 (0) 4102 - 463 390
mailto:thomas.koeller@baslerweb.com
http://www.baslerweb.com
Vorstand: Dr.-Ing. Dietmar Ley (Vorsitzender) · John P. Jennings · Peter
Krumhoff · Aufsichtsratsvorsitzender: Norbert Basler
Basler AG · Amtsgericht Ahrensburg HRB 4090 · Ust-IdNr.: DE 135 098 121 ·
Steuer-Nr.: 30 292 04497
_______________________________
^ permalink raw reply
* Re: [OT?] is there something strange about __builtin_ffs these days?
From: Thiemo Seufer @ 2007-12-17 21:45 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: linux-mips
In-Reply-To: <alpine.LFD.0.9999.0712171602090.13289@localhost.localdomain>
Robert P. J. Day wrote:
>
> i'm hoping i'm not abusing this list overly by asking for some help
> with debugging an OpenWRT issue. the trac ticket is here:
>
> https://dev.openwrt.org/ticket/2735
>
> and involves cross-compiling an image for the MIPS-based linksys
> WRT54GL router. i've verified that this error still exists in the
> latest svn update of openwrt and, in a nutshell, it involves the claim
> that "__builtin_ffs" is undefined:
>
> ...
> CC [M] /home/openwrt/builds/trunk_brcm47xx/build_dir/linux-brcm47xx/spca5xx-le/spca_core.o
> /home/openwrt/builds/trunk_brcm47xx/build_dir/linux-brcm47xx/spca5xx-le/spca_core.c:538:5:
> warning: "__builtin_ffs" is not defined
> /home/openwrt/builds/trunk_brcm47xx/build_dir/linux-brcm47xx/spca5xx-le/spca_core.c:538:5:
> error: missing binary operator before token "("
> ...
>
> that line in the source file is simply:
>
> #if PUD_SHIFT
>
> i have no idea what the problem is here and, as you can see from the
> trac ticket, this seems to have started because of the kernel version
> upgrade from 2.6.22 to 2.6.23. but what about that would affect the
> usage of __builtin_ffs?
>
> does anyone have an idea why something this basic might be going
> wrong now? any suggestions appreciated. thanks.
The compiler should never attempt to use __builtin_ffs by itself, because
the kernel makefile adds -ffreestanding to CFLAGS. So either your compiler
is broken, or the makefile of your kernel tree is incorrect, or somewhere
in your kernel tree there's a explicit call to __builtin_ffs (which is
also incorrect, as the compiler may invoke library functions to implement
it.)
Thiemo
^ permalink raw reply
* [OT?] is there something strange about __builtin_ffs these days?
From: Robert P. J. Day @ 2007-12-17 21:08 UTC (permalink / raw)
To: linux-mips
i'm hoping i'm not abusing this list overly by asking for some help
with debugging an OpenWRT issue. the trac ticket is here:
https://dev.openwrt.org/ticket/2735
and involves cross-compiling an image for the MIPS-based linksys
WRT54GL router. i've verified that this error still exists in the
latest svn update of openwrt and, in a nutshell, it involves the claim
that "__builtin_ffs" is undefined:
...
CC [M] /home/openwrt/builds/trunk_brcm47xx/build_dir/linux-brcm47xx/spca5xx-le/spca_core.o
/home/openwrt/builds/trunk_brcm47xx/build_dir/linux-brcm47xx/spca5xx-le/spca_core.c:538:5:
warning: "__builtin_ffs" is not defined
/home/openwrt/builds/trunk_brcm47xx/build_dir/linux-brcm47xx/spca5xx-le/spca_core.c:538:5:
error: missing binary operator before token "("
...
that line in the source file is simply:
#if PUD_SHIFT
i have no idea what the problem is here and, as you can see from the
trac ticket, this seems to have started because of the kernel version
upgrade from 2.6.22 to 2.6.23. but what about that would affect the
usage of __builtin_ffs?
does anyone have an idea why something this basic might be going
wrong now? any suggestions appreciated. thanks.
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://crashcourse.ca
========================================================================
^ permalink raw reply
* Re: [PATCH] include/asm-mips/: Spelling fixes
From: Joe Perches @ 2007-12-17 20:02 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linux-kernel, Andrew Morton, Ralf Baechle, linux-mips
In-Reply-To: <4766D3BE.7070509@ru.mvista.com>
On Mon, 2007-12-17 at 22:53 +0300, Sergei Shtylyov wrote:
> > - * PCI interrupts will come in on either the INTA or INTD interrups lines,
> > + * PCI interrupts will come in on either the INTA or INTD interrupts lines,
> "interrupt" here.
Quite right.
I did them by script and inspected, but didn't notice that one.
cheers, Joe
Signed-off-by: Joe Perches <joe@perches.com>
---
diff --git a/include/asm-mips/mach-wrppmc/mach-gt64120.h b/include/asm-mips/mach-wrppmc/mach-gt64120.h
index 00d8bf6..465234a 100644
--- a/include/asm-mips/mach-wrppmc/mach-gt64120.h
+++ b/include/asm-mips/mach-wrppmc/mach-gt64120.h
@@ -45,7 +45,7 @@
#define GT_PCI_IO_SIZE 0x02000000UL
/*
- * PCI interrupts will come in on either the INTA or INTD interrups lines,
+ * PCI interrupts will come in on either the INTA or INTD interrupt lines,
* which are mapped to the #2 and #5 interrupt pins of the MIPS. On our
* boards, they all either come in on IntD or they all come in on IntA, they
* aren't mixed. There can be numerous PCI interrupts, so we keep a list of the
^ permalink raw reply related
* Re: [PATCH] include/asm-mips/: Spelling fixes
From: Sergei Shtylyov @ 2007-12-17 19:53 UTC (permalink / raw)
To: Joe Perches; +Cc: linux-kernel, Andrew Morton, Ralf Baechle, linux-mips
In-Reply-To: <1197919875-5288-10-git-send-email-joe@perches.com>
Hello.
Joe Perches wrote:
> Signed-off-by: Joe Perches <joe@perches.com>
> diff --git a/include/asm-mips/mach-wrppmc/mach-gt64120.h b/include/asm-mips/mach-wrppmc/mach-gt64120.h
> index 00d8bf6..465234a 100644
> --- a/include/asm-mips/mach-wrppmc/mach-gt64120.h
> +++ b/include/asm-mips/mach-wrppmc/mach-gt64120.h
> @@ -45,7 +45,7 @@
> #define GT_PCI_IO_SIZE 0x02000000UL
>
> /*
> - * PCI interrupts will come in on either the INTA or INTD interrups lines,
> + * PCI interrupts will come in on either the INTA or INTD interrupts lines,
"interrupt" here.
WBR, Sergei
^ permalink raw reply
* [PATCH] include/asm-mips/: Spelling fixes
From: Joe Perches @ 2007-12-17 19:30 UTC (permalink / raw)
To: linux-kernel; +Cc: Andrew Morton, Ralf Baechle, linux-mips
Signed-off-by: Joe Perches <joe@perches.com>
---
include/asm-mips/mach-excite/excite_fpga.h | 2 +-
include/asm-mips/mach-wrppmc/mach-gt64120.h | 2 +-
include/asm-mips/sgi/ip22.h | 2 +-
include/asm-mips/sn/sn0/hubio.h | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/asm-mips/mach-excite/excite_fpga.h b/include/asm-mips/mach-excite/excite_fpga.h
index 38fcda7..0a1ef69 100644
--- a/include/asm-mips/mach-excite/excite_fpga.h
+++ b/include/asm-mips/mach-excite/excite_fpga.h
@@ -3,7 +3,7 @@
/**
- * Adress alignment of the individual FPGA bytes.
+ * Address alignment of the individual FPGA bytes.
* The address arrangement of the individual bytes of the FPGA is two
* byte aligned at the embedded MK2 platform.
*/
diff --git a/include/asm-mips/mach-wrppmc/mach-gt64120.h b/include/asm-mips/mach-wrppmc/mach-gt64120.h
index 00d8bf6..465234a 100644
--- a/include/asm-mips/mach-wrppmc/mach-gt64120.h
+++ b/include/asm-mips/mach-wrppmc/mach-gt64120.h
@@ -45,7 +45,7 @@
#define GT_PCI_IO_SIZE 0x02000000UL
/*
- * PCI interrupts will come in on either the INTA or INTD interrups lines,
+ * PCI interrupts will come in on either the INTA or INTD interrupts lines,
* which are mapped to the #2 and #5 interrupt pins of the MIPS. On our
* boards, they all either come in on IntD or they all come in on IntA, they
* aren't mixed. There can be numerous PCI interrupts, so we keep a list of the
diff --git a/include/asm-mips/sgi/ip22.h b/include/asm-mips/sgi/ip22.h
index f4981c4..c0501f9 100644
--- a/include/asm-mips/sgi/ip22.h
+++ b/include/asm-mips/sgi/ip22.h
@@ -15,7 +15,7 @@
/*
* These are the virtual IRQ numbers, we divide all IRQ's into
* 'spaces', the 'space' determines where and how to enable/disable
- * that particular IRQ on an SGI machine. HPC DMA and MC DMA interrups
+ * that particular IRQ on an SGI machine. HPC DMA and MC DMA interrupts
* are not supported this way. Driver is supposed to allocate HPC/MC
* interrupt as shareable and then look to proper status bit (see
* HAL2 driver). This will prevent many complications, trust me ;-)
diff --git a/include/asm-mips/sn/sn0/hubio.h b/include/asm-mips/sn/sn0/hubio.h
index ef91b33..0187895 100644
--- a/include/asm-mips/sn/sn0/hubio.h
+++ b/include/asm-mips/sn/sn0/hubio.h
@@ -338,7 +338,7 @@ typedef union io_perf_cnt {
#define IIO_IFDR 0x400398 /* IOQ FIFO Depth */
#define IIO_IIAP 0x4003a0 /* IIQ Arbitration Parameters */
#define IIO_IMMR IIO_IIAP
-#define IIO_ICMR 0x4003a8 /* CRB Managment Register */
+#define IIO_ICMR 0x4003a8 /* CRB Management Register */
#define IIO_ICCR 0x4003b0 /* CRB Control Register */
#define IIO_ICTO 0x4003b8 /* CRB Time Out Register */
#define IIO_ICTP 0x4003c0 /* CRB Time Out Prescalar */
--
1.5.3.7.949.g2221a6
^ permalink raw reply related
* [PATCH] arch/mips/: Spelling fixes
From: Joe Perches @ 2007-12-17 19:30 UTC (permalink / raw)
To: linux-kernel; +Cc: Andrew Morton, Ralf Baechle, linux-mips
Signed-off-by: Joe Perches <joe@perches.com>
---
arch/mips/au1000/mtx-1/board_setup.c | 2 +-
arch/mips/kernel/binfmt_elfn32.c | 2 +-
arch/mips/kernel/binfmt_elfo32.c | 2 +-
arch/mips/kernel/kspd.c | 2 +-
arch/mips/kernel/setup.c | 4 ++--
arch/mips/kernel/smtc.c | 6 +++---
arch/mips/mm/c-r4k.c | 2 +-
arch/mips/sgi-ip27/ip27-hubio.c | 2 +-
8 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/arch/mips/au1000/mtx-1/board_setup.c b/arch/mips/au1000/mtx-1/board_setup.c
index abfc4bc..310d5df 100644
--- a/arch/mips/au1000/mtx-1/board_setup.c
+++ b/arch/mips/au1000/mtx-1/board_setup.c
@@ -99,7 +99,7 @@ mtx1_pci_idsel(unsigned int devsel, int assert)
#endif
if (assert && devsel != 0) {
- // supress signal to cardbus
+ // suppress signal to cardbus
au_writel( 0x00000002, SYS_OUTPUTCLR ); // set EXT_IO3 OFF
}
else {
diff --git a/arch/mips/kernel/binfmt_elfn32.c b/arch/mips/kernel/binfmt_elfn32.c
index 9b34238..77db347 100644
--- a/arch/mips/kernel/binfmt_elfn32.c
+++ b/arch/mips/kernel/binfmt_elfn32.c
@@ -98,7 +98,7 @@ static __inline__ void
jiffies_to_compat_timeval(unsigned long jiffies, struct compat_timeval *value)
{
/*
- * Convert jiffies to nanoseconds and seperate with
+ * Convert jiffies to nanoseconds and separate with
* one divide.
*/
u64 nsec = (u64)jiffies * TICK_NSEC;
diff --git a/arch/mips/kernel/binfmt_elfo32.c b/arch/mips/kernel/binfmt_elfo32.c
index da41eac..08f4cd7 100644
--- a/arch/mips/kernel/binfmt_elfo32.c
+++ b/arch/mips/kernel/binfmt_elfo32.c
@@ -100,7 +100,7 @@ static inline void
jiffies_to_compat_timeval(unsigned long jiffies, struct compat_timeval *value)
{
/*
- * Convert jiffies to nanoseconds and seperate with
+ * Convert jiffies to nanoseconds and separate with
* one divide.
*/
u64 nsec = (u64)jiffies * TICK_NSEC;
diff --git a/arch/mips/kernel/kspd.c b/arch/mips/kernel/kspd.c
index d2c2e00..1630784 100644
--- a/arch/mips/kernel/kspd.c
+++ b/arch/mips/kernel/kspd.c
@@ -222,7 +222,7 @@ void sp_work_handle_request(void)
}
}
- /* Run the syscall at the priviledge of the user who loaded the
+ /* Run the syscall at the privilege of the user who loaded the
SP program */
if (vpe_getuid(tclimit))
diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
index 7f6ddcb..ddc2d6d 100644
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -423,13 +423,13 @@ static void __init bootmem_init(void)
#endif /* CONFIG_SGI_IP27 */
/*
- * arch_mem_init - initialize memory managment subsystem
+ * arch_mem_init - initialize memory management subsystem
*
* o plat_mem_setup() detects the memory configuration and will record detected
* memory areas using add_memory_region.
*
* At this stage the memory configuration of the system is known to the
- * kernel but generic memory managment system is still entirely uninitialized.
+ * kernel but generic memory management system is still entirely uninitialized.
*
* o bootmem_init()
* o sparse_init()
diff --git a/arch/mips/kernel/smtc.c b/arch/mips/kernel/smtc.c
index 9c92d42..37ee189 100644
--- a/arch/mips/kernel/smtc.c
+++ b/arch/mips/kernel/smtc.c
@@ -66,7 +66,7 @@ asiduse smtc_live_asid[MAX_SMTC_TLBS][MAX_SMTC_ASIDS];
static atomic_t ipi_timer_latch[NR_CPUS];
/*
- * Number of InterProcessor Interupt (IPI) message buffers to allocate
+ * Number of InterProcessor Interrupt (IPI) message buffers to allocate
*/
#define IPIBUF_PER_CPU 4
@@ -781,7 +781,7 @@ void smtc_send_ipi(int cpu, int type, unsigned int action)
if (cpu_data[cpu].vpe_id != cpu_data[smp_processor_id()].vpe_id) {
if (type == SMTC_CLOCK_TICK)
atomic_inc(&ipi_timer_latch[cpu]);
- /* If not on same VPE, enqueue and send cross-VPE interupt */
+ /* If not on same VPE, enqueue and send cross-VPE interrupt */
smtc_ipi_nq(&IPIQ[cpu], pipi);
LOCK_CORE_PRA();
settc(cpu_data[cpu].tc_id);
@@ -1064,7 +1064,7 @@ static void setup_cross_vpe_interrupts(unsigned int nvpe)
return;
if (!cpu_has_vint)
- panic("SMTC Kernel requires Vectored Interupt support");
+ panic("SMTC Kernel requires Vectored Interrupt support");
set_vi_handler(MIPS_CPU_IPI_IRQ, ipi_irq_dispatch);
diff --git a/arch/mips/mm/c-r4k.c b/arch/mips/mm/c-r4k.c
index 9355f1c..049ba7f 100644
--- a/arch/mips/mm/c-r4k.c
+++ b/arch/mips/mm/c-r4k.c
@@ -1108,7 +1108,7 @@ static void __init setup_scache(void)
/*
* Do the probing thing on R4000SC and R4400SC processors. Other
* processors don't have a S-cache that would be relevant to the
- * Linux memory managment.
+ * Linux memory management.
*/
switch (c->cputype) {
case CPU_R4000SC:
diff --git a/arch/mips/sgi-ip27/ip27-hubio.c b/arch/mips/sgi-ip27/ip27-hubio.c
index 524b371..a1fa4ab 100644
--- a/arch/mips/sgi-ip27/ip27-hubio.c
+++ b/arch/mips/sgi-ip27/ip27-hubio.c
@@ -168,7 +168,7 @@ static void hub_set_piomode(nasid_t nasid)
}
/*
- * hub_pio_init - PIO-related hub initalization
+ * hub_pio_init - PIO-related hub initialization
*
* @hub: hubinfo structure for our hub
*/
--
1.5.3.7.949.g2221a6
^ permalink raw reply related
* Re: [directfb-dev] Error in running gtk example on cross compiled GTK with DirectFB on MIPS board
From: kaka @ 2007-12-17 18:40 UTC (permalink / raw)
To: Denis Oliver Kropp
Cc: linux-mips, uclinux-dev, celinux-dev, linux-fbdev-users,
directfb-users, directfb-dev
In-Reply-To: <4766B149.5050109@directfb.org>
[-- Attachment #1: Type: text/plain, Size: 2560 bytes --]
Hi Denis,
Thanks for the reply.
I am running same example on X86 and it is running successfully and
displaying image.
On the other hand when i am running the same example on MIPS(GTK over
DirecTFB)
image is not being displayed.
Could u plz provide some clue on it.
Thanks.
Kaka
On 12/17/07, Denis Oliver Kropp <dok@directfb.org> wrote:
>
> kaka wrote:
> > HI ALL,
> >
> > We have successfully cross compiled GTK and DIRECTFB with all its
> > dependencies for MIPS board.
> > On running the basic test example of GTK, it is getting struck in the
> thread
> > loop infinitely.
> > We had put the "debug printf" statement in the gtkmain.c and debugged
> the
> > test example.
> > It is getting struck in the * g_main_loop_run (loop);* given below is
> > the code(code
> > snippet from gtkmain.c)
> >
> > void
> > gtk_main (void)
> > {
> > GList *tmp_list;
> > GList *functions;
> > GtkInitFunction *init;
> > GMainLoop *loop;
> > printf("\n%s :: %d\n",__FILE__,__LINE__);
> > gtk_main_loop_level++;
> >
> > loop = g_main_loop_new (NULL, TRUE);
> > main_loops = g_slist_prepend (main_loops, loop);
> > printf("\n%s :: %d\n",__FILE__,__LINE__);
> > tmp_list = functions = init_functions;
> > init_functions = NULL;
> >
> > while (tmp_list)
> > {
> > init = tmp_list->data;
> > tmp_list = tmp_list->next;
> >
> > (* init->function) (init->data);
> > g_free (init);
> > }
> > g_list_free (functions);
> > printf("\n%s :: %d\n",__FILE__,__LINE__);
> > if (g_main_loop_is_running (main_loops->data))
> > {
> > * printf("\n%s :: %d\n",__FILE__,__LINE__);
> > GDK_THREADS_LEAVE ();
> > g_main_loop_run (loop);
> > GDK_THREADS_ENTER ();
> > * printf("\n%s :: %d\n",__FILE__,__LINE__);
>
> That's normal. If you want runtime you have to create a timer or register
> idle or timeout functions.
>
> > gtk_container_add (GTK_CONTAINER (window), pMainWidget);
> > printf("\n\n\ngtk_container_add (GTK_CONTAINER (window),
> > pMainWidget);\n\n\n") ;
> > gtk_widget_show (window);
> > printf("\n\n\nABHISHEK START OF gtk_main\n\n\n");
> > gtk_main ();
> > printf("\n\n\nABHISHEK END OF gtk_main\n\n\n");
> > return 0;
>
> Simply/weakly put: it should not return before the application is quit.
>
> --
> Best regards,
> Denis Oliver Kropp
>
> .------------------------------------------.
> | DirectFB - Hardware accelerated graphics |
> | http://www.directfb.org/ |
> "------------------------------------------"
>
--
Thanks & Regards,
kaka
[-- Attachment #2: Type: text/html, Size: 4061 bytes --]
^ permalink raw reply
* Re: [directfb-dev] Error in running gtk example on cross compiled GTK with DirectFB on MIPS board
From: Denis Oliver Kropp @ 2007-12-17 17:26 UTC (permalink / raw)
To: kaka
Cc: linux-mips, uclinux-dev, celinux-dev, linux-fbdev-users,
directfb-users, directfb-dev
In-Reply-To: <eea8a9c90712170031i62e4ac4ak687a198200f59920@mail.gmail.com>
kaka wrote:
> HI ALL,
>
> We have successfully cross compiled GTK and DIRECTFB with all its
> dependencies for MIPS board.
> On running the basic test example of GTK, it is getting struck in the thread
> loop infinitely.
> We had put the "debug printf" statement in the gtkmain.c and debugged the
> test example.
> It is getting struck in the * g_main_loop_run (loop);* given below is
> the code(code
> snippet from gtkmain.c)
>
> void
> gtk_main (void)
> {
> GList *tmp_list;
> GList *functions;
> GtkInitFunction *init;
> GMainLoop *loop;
> printf("\n%s :: %d\n",__FILE__,__LINE__);
> gtk_main_loop_level++;
>
> loop = g_main_loop_new (NULL, TRUE);
> main_loops = g_slist_prepend (main_loops, loop);
> printf("\n%s :: %d\n",__FILE__,__LINE__);
> tmp_list = functions = init_functions;
> init_functions = NULL;
>
> while (tmp_list)
> {
> init = tmp_list->data;
> tmp_list = tmp_list->next;
>
> (* init->function) (init->data);
> g_free (init);
> }
> g_list_free (functions);
> printf("\n%s :: %d\n",__FILE__,__LINE__);
> if (g_main_loop_is_running (main_loops->data))
> {
> * printf("\n%s :: %d\n",__FILE__,__LINE__);
> GDK_THREADS_LEAVE ();
> g_main_loop_run (loop);
> GDK_THREADS_ENTER ();
> * printf("\n%s :: %d\n",__FILE__,__LINE__);
That's normal. If you want runtime you have to create a timer or register idle or timeout functions.
> gtk_container_add (GTK_CONTAINER (window), pMainWidget);
> printf("\n\n\ngtk_container_add (GTK_CONTAINER (window),
> pMainWidget);\n\n\n") ;
> gtk_widget_show (window);
> printf("\n\n\nABHISHEK START OF gtk_main\n\n\n");
> gtk_main ();
> printf("\n\n\nABHISHEK END OF gtk_main\n\n\n");
> return 0;
Simply/weakly put: it should not return before the application is quit.
--
Best regards,
Denis Oliver Kropp
.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/ |
"------------------------------------------"
^ permalink raw reply
* Re: [PATCH][MIPS] fix user_cpus_allowed assignment
From: Kevin D. Kissell @ 2007-12-17 16:40 UTC (permalink / raw)
To: Pavel Kiryukhin, linux-mips; +Cc: vksavl
In-Reply-To: <73cd086a0712170517i146a452exea775f3942c1d5da@mail.gmail.com>
This looks to be a correct fix. Long term, we really do need to convince
the scheduler maintainer to provide hooks that will allow hardware-driven
affinity to be integrated with application-driven affinity in a sensible way,
without requiring replication (and replicated maintenence) of the system
call code in private copies like this. I asked for such hooks in sched.c
when it first became apparent that dynamic FPU affinity was desirable,
but was blown off at that time, so, with regret, I perpetrated the local copy
hack. But it's silly, and MIPS can't possibly be the only architecture where
Linux is used in systems with assymmetric resources where adaptive affinity
is useful.
Regards,
Kevin K.
----- Original Message -----
From: "Pavel Kiryukhin" <vksavl@gmail.com>
To: <linux-mips@linux-mips.org>
Cc: <vksavl@gmail.com>
Sent: Monday, December 17, 2007 2:17 PM
Subject: [PATCH][MIPS] fix user_cpus_allowed assignment
> Hi,
> there seems to be a bug in affinity handling for CONFIG_MIPS_MT_FPAFF=y.
> It can be easily reproduced - for two-cpus system set new mask to 4.
> Call fails, but next sched_getaffinity() call returns 0 as current
> mask.
> Simple fix is below.
>
> Signed-off-by: Pavel Kiryukhin <vksavl@gmail.com>
>
> diff --git a/arch/mips/kernel/mips-mt-fpaff.c
> b/arch/mips/kernel/mips-mt-fpaff.cindex 892665b..774f91e 100644
> --- a/arch/mips/kernel/mips-mt-fpaff.c
> +++ b/arch/mips/kernel/mips-mt-fpaff.c
> @@ -87,9 +87,6 @@ asmlinkage long mipsmt_sys_sched_setaffinity(pid_t
> pid, unsigned int len,
> if (retval)
> goto out_unlock;
>
> - /* Record new user-specified CPU set for future reference */
> - p->thread.user_cpus_allowed = new_mask;
> -
> /* Unlock the task list */
> read_unlock(&tasklist_lock);
>
> @@ -104,6 +101,10 @@ asmlinkage long
> mipsmt_sys_sched_setaffinity(pid_t pid, unsigned int len,
> retval = set_cpus_allowed(p, new_mask);
> }
>
> + /* Record new user-specified CPU set for future reference */
> + if (!retval)
> + p->thread.user_cpus_allowed = new_mask;
> +
> out_unlock:
> put_task_struct(p);
> unlock_cpu_hotplug();
>
>
^ permalink raw reply
* Re: [PATCH][MIPS] fix user_cpus_allowed assignment
From: Kevin D. Kissell @ 2007-12-17 16:40 UTC (permalink / raw)
To: Pavel Kiryukhin, linux-mips
In-Reply-To: <73cd086a0712170517i146a452exea775f3942c1d5da@mail.gmail.com>
This looks to be a correct fix. Long term, we really do need to convince
the scheduler maintainer to provide hooks that will allow hardware-driven
affinity to be integrated with application-driven affinity in a sensible way,
without requiring replication (and replicated maintenence) of the system
call code in private copies like this. I asked for such hooks in sched.c
when it first became apparent that dynamic FPU affinity was desirable,
but was blown off at that time, so, with regret, I perpetrated the local copy
hack. But it's silly, and MIPS can't possibly be the only architecture where
Linux is used in systems with assymmetric resources where adaptive affinity
is useful.
Regards,
Kevin K.
----- Original Message -----
From: "Pavel Kiryukhin" <vksavl@gmail.com>
To: <linux-mips@linux-mips.org>
Cc: <vksavl@gmail.com>
Sent: Monday, December 17, 2007 2:17 PM
Subject: [PATCH][MIPS] fix user_cpus_allowed assignment
> Hi,
> there seems to be a bug in affinity handling for CONFIG_MIPS_MT_FPAFF=y.
> It can be easily reproduced - for two-cpus system set new mask to 4.
> Call fails, but next sched_getaffinity() call returns 0 as current
> mask.
> Simple fix is below.
>
> Signed-off-by: Pavel Kiryukhin <vksavl@gmail.com>
>
> diff --git a/arch/mips/kernel/mips-mt-fpaff.c
> b/arch/mips/kernel/mips-mt-fpaff.cindex 892665b..774f91e 100644
> --- a/arch/mips/kernel/mips-mt-fpaff.c
> +++ b/arch/mips/kernel/mips-mt-fpaff.c
> @@ -87,9 +87,6 @@ asmlinkage long mipsmt_sys_sched_setaffinity(pid_t
> pid, unsigned int len,
> if (retval)
> goto out_unlock;
>
> - /* Record new user-specified CPU set for future reference */
> - p->thread.user_cpus_allowed = new_mask;
> -
> /* Unlock the task list */
> read_unlock(&tasklist_lock);
>
> @@ -104,6 +101,10 @@ asmlinkage long
> mipsmt_sys_sched_setaffinity(pid_t pid, unsigned int len,
> retval = set_cpus_allowed(p, new_mask);
> }
>
> + /* Record new user-specified CPU set for future reference */
> + if (!retval)
> + p->thread.user_cpus_allowed = new_mask;
> +
> out_unlock:
> put_task_struct(p);
> unlock_cpu_hotplug();
>
>
^ permalink raw reply
* Re: PCI resource unavailable on mips
From: Sergei Shtylyov @ 2007-12-17 15:47 UTC (permalink / raw)
To: Jon Dufresne; +Cc: Ralf Baechle, linux-kernel, linux-mips
In-Reply-To: <1197904591.3351.5.camel@microwave.infinitevideocorporation.com>
Hello.
Jon Dufresne wrote:
> I did a bit more work and investigation on this and it turns out I could
> not read the mmio in kernel space because I had not done a
> pci_enable_device_bars() on the device. I had never done this on x86 so
> I didn't realize it was necessary.
>>The virtual address 0xc0300000 looks sensible and the physical address
>>0x24000000 is consistent with what you found in the BAR registers. So that
>>all looks reasonable but that only means not obviously wrong. So next I
>>wonder what the value of PCI_MMIO_BASE is ...
> The PCI_MMIO_BASE is a defined as:
>>#define PCI_MMIO_BASE (0x00040000)
> This is define in the technical documentation as the offset to access
> pci config space from the mmio.
From what mmio? If it's for accessing a config. space why then you're
using it as an offset from BAR?
> I am using this because I know what the
> values should be so it provides a nice sanity check.
> Any idea what I might be doing wrong? How can I access this from user
> space?
Your example doesn't make sense to me so far.
> Thanks,
> Jon
WBR, Sergei
^ permalink raw reply
* Re: PCI resource unavailable on mips
From: Jon Dufresne @ 2007-12-17 15:16 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux-kernel, linux-mips
In-Reply-To: <20071216224617.GA18613@linux-mips.org>
I did a bit more work and investigation on this and it turns out I could
not read the mmio in kernel space because I had not done a
pci_enable_device_bars() on the device. I had never done this on x86 so
I didn't realize it was necessary.
> The virtual address 0xc0300000 looks sensible and the physical address
> 0x24000000 is consistent with what you found in the BAR registers. So that
> all looks reasonable but that only means not obviously wrong. So next I
> wonder what the value of PCI_MMIO_BASE is ...
The PCI_MMIO_BASE is a defined as:
> #define PCI_MMIO_BASE (0x00040000)
This is define in the technical documentation as the offset to access
pci config space from the mmio. I am using this because I know what the
values should be so it provides a nice sanity check.
> A bus error is an exception which is signalled by agent external (often
> called system controller) to the CPU core to signal a fatal error during a
> read or write bus transaction, for example after a bus timeout or if the
> address of the read/write isn't assigned to any device. PCI master abort
> also is often mapped to a bus error exception.
So after doing pci_enable_bars() I can now access this mmio region in
kernel space. However, if I try to mmap this into user space I still
receive the bus error. I am mapping this into user space using the
example for LDD which says to use the remap_pfn_range() function. I've
tested this on the x86 and it works as expected, however every time I
access the mmio from user space using the mips, I continue to get the
bus error I previously received in kernel space.
Any idea what I might be doing wrong? How can I access this from user
space?
Thanks,
Jon
^ permalink raw reply
* [PATCH][MIPS] fix user_cpus_allowed assignment
From: Pavel Kiryukhin @ 2007-12-17 13:17 UTC (permalink / raw)
To: linux-mips; +Cc: vksavl
Hi,
there seems to be a bug in affinity handling for CONFIG_MIPS_MT_FPAFF=y.
It can be easily reproduced - for two-cpus system set new mask to 4.
Call fails, but next sched_getaffinity() call returns 0 as current
mask.
Simple fix is below.
Signed-off-by: Pavel Kiryukhin <vksavl@gmail.com>
diff --git a/arch/mips/kernel/mips-mt-fpaff.c
b/arch/mips/kernel/mips-mt-fpaff.cindex 892665b..774f91e 100644
--- a/arch/mips/kernel/mips-mt-fpaff.c
+++ b/arch/mips/kernel/mips-mt-fpaff.c
@@ -87,9 +87,6 @@ asmlinkage long mipsmt_sys_sched_setaffinity(pid_t
pid, unsigned int len,
if (retval)
goto out_unlock;
- /* Record new user-specified CPU set for future reference */
- p->thread.user_cpus_allowed = new_mask;
-
/* Unlock the task list */
read_unlock(&tasklist_lock);
@@ -104,6 +101,10 @@ asmlinkage long
mipsmt_sys_sched_setaffinity(pid_t pid, unsigned int len,
retval = set_cpus_allowed(p, new_mask);
}
+ /* Record new user-specified CPU set for future reference */
+ if (!retval)
+ p->thread.user_cpus_allowed = new_mask;
+
out_unlock:
put_task_struct(p);
unlock_cpu_hotplug();
^ permalink raw reply
* timer irq setup
From: Thomas Koeller @ 2007-12-17 10:35 UTC (permalink / raw)
To: linux-mips
In arch/mips/kernel/traps.c, per_cpu_trap_init() contains
code to set up the global cp0_compare_irq variable. Does
this make sense? I'd say that either the irq setup should
be moved to trap_init(), or cp0_compare_irq should be
changed to a per-cpu variable, depending on what the original
intention was.
tk
--
Thomas Koeller
thomas at koeller dot dyndns dot org
^ permalink raw reply
* Error in running gtk example on cross compiled GTK with DirectFB on MIPS board
From: kaka @ 2007-12-17 8:31 UTC (permalink / raw)
To: linux-mips, uclinux-dev, celinux-dev, linux-fbdev-users,
directfb-users, directfb-dev
[-- Attachment #1: Type: text/plain, Size: 2411 bytes --]
HI ALL,
We have successfully cross compiled GTK and DIRECTFB with all its
dependencies for MIPS board.
On running the basic test example of GTK, it is getting struck in the thread
loop infinitely.
We had put the "debug printf" statement in the gtkmain.c and debugged the
test example.
It is getting struck in the * g_main_loop_run (loop);* given below is
the code(code
snippet from gtkmain.c)
void
gtk_main (void)
{
GList *tmp_list;
GList *functions;
GtkInitFunction *init;
GMainLoop *loop;
printf("\n%s :: %d\n",__FILE__,__LINE__);
gtk_main_loop_level++;
loop = g_main_loop_new (NULL, TRUE);
main_loops = g_slist_prepend (main_loops, loop);
printf("\n%s :: %d\n",__FILE__,__LINE__);
tmp_list = functions = init_functions;
init_functions = NULL;
while (tmp_list)
{
init = tmp_list->data;
tmp_list = tmp_list->next;
(* init->function) (init->data);
g_free (init);
}
g_list_free (functions);
printf("\n%s :: %d\n",__FILE__,__LINE__);
if (g_main_loop_is_running (main_loops->data))
{
* printf("\n%s :: %d\n",__FILE__,__LINE__);
GDK_THREADS_LEAVE ();
g_main_loop_run (loop);
GDK_THREADS_ENTER ();
* printf("\n%s :: %d\n",__FILE__,__LINE__);
gdk_flush ();
}
printf("\n%s :: %d\n",__FILE__,__LINE__);
if (quit_functions)
{
GList *reinvoke_list = NULL;
GtkQuitFunction *quitf;
Given below is the src code for test example of GTK:
#include <gtk/gtk.h>
int main( int argc, char *argv[] )
{
GtkWidget *window;
GtkWidget *pMainWidget;
GdkPixbuf *image;
gboolean ret = 0;
gtk_init (&argc, &argv);
printf("\n\n\ngtk_init (&argc, &argv);\n\n\n");
window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
//gtk_container_set_border_width (GTK_CONTAINER (window), 10);
image = gdk_pixbuf_new_from_file ("test.gif", NULL);
if (!image)
return FALSE;
pMainWidget = gtk_image_new_from_pixbuf(image);
printf("\n\n\npMainWidget = gtk_image_new_from_pixbuf(image);\n\n\n");
gtk_widget_show (pMainWidget);
gtk_container_add (GTK_CONTAINER (window), pMainWidget);
printf("\n\n\ngtk_container_add (GTK_CONTAINER (window),
pMainWidget);\n\n\n") ;
gtk_widget_show (window);
printf("\n\n\nABHISHEK START OF gtk_main\n\n\n");
gtk_main ();
printf("\n\n\nABHISHEK END OF gtk_main\n\n\n");
return 0;
}
Can anybody Plz throw some light on it?
Thanks in advcance
--
Thanks & Regards,
kaka
[-- Attachment #2: Type: text/html, Size: 3545 bytes --]
^ permalink raw reply
* RE: GCC 3.4.5 and mftc0
From: Mikael Starvik @ 2007-12-17 6:45 UTC (permalink / raw)
To: 'Ralf Baechle', Mikael Starvik; +Cc: linux-mips
In-Reply-To: <BFECAF9E178F144FAEF2BF4CE739C668056FE63A@exmail1.se.axis.com>
Thanks!
and sorry for the spelling of simulator.
/Mikael
-----Original Message-----
From: Ralf Baechle [mailto:ralf@linux-mips.org]
Sent: Friday, December 14, 2007 5:26 PM
To: Mikael Starvik
Cc: linux-mips@linux-mips.org
Subject: Re: GCC 3.4.5 and mftc0
On Fri, Dec 14, 2007 at 10:49:40AM +0100, Mikael Starvik wrote:
> mftc0() is implemented as
>
> .word ...
> move %0, $1
>
> With at least gcc 3.4.5 the move is implemented as an addu %0, $1, $0.
> But in the MIPS sumulator this fails and %0 gets the value 0xffffffff.
> Implementing this as a or %0, $1, $0 instead gives the expected result.
I wonder what "sumulator" you're using ...
Addu is a perfectly fine implementation of move for 32-bit code. It's not
for 64-bit code but that's beside the point here. The or method is also
correct but historically the add instruction has been prefered, also
because some processor - the R4300 afair - processes arithmetic instructions
(add, sub that is not mul / div) faster than logic operations.
> Any suggestions where the problem is and what the correct solution is?
Fix the sumulator.
> After fixing this my next problem is that IPIs doesn't reach all TCs
> correctly (it seams like the code doesn't detect IXMT status correctly,
> but I am still investigating). It is likely that it is caused by
> something similar to the problem above.
The code certainly works on real silicon, so the cause must be something
local to your environment.
Cheers,
Ralf
^ permalink raw reply
* RE: GCC 3.4.5 and mftc0
From: Mikael Starvik @ 2007-12-17 6:45 UTC (permalink / raw)
To: 'Ralf Baechle', Mikael Starvik; +Cc: linux-mips
In-Reply-To: <BFECAF9E178F144FAEF2BF4CE739C668056FE63A@exmail1.se.axis.com>
Thanks!
and sorry for the spelling of simulator.
/Mikael
-----Original Message-----
From: Ralf Baechle [mailto:ralf@linux-mips.org]
Sent: Friday, December 14, 2007 5:26 PM
To: Mikael Starvik
Cc: linux-mips@linux-mips.org
Subject: Re: GCC 3.4.5 and mftc0
On Fri, Dec 14, 2007 at 10:49:40AM +0100, Mikael Starvik wrote:
> mftc0() is implemented as
>
> .word ...
> move %0, $1
>
> With at least gcc 3.4.5 the move is implemented as an addu %0, $1, $0.
> But in the MIPS sumulator this fails and %0 gets the value 0xffffffff.
> Implementing this as a or %0, $1, $0 instead gives the expected result.
I wonder what "sumulator" you're using ...
Addu is a perfectly fine implementation of move for 32-bit code. It's not
for 64-bit code but that's beside the point here. The or method is also
correct but historically the add instruction has been prefered, also
because some processor - the R4300 afair - processes arithmetic instructions
(add, sub that is not mul / div) faster than logic operations.
> Any suggestions where the problem is and what the correct solution is?
Fix the sumulator.
> After fixing this my next problem is that IPIs doesn't reach all TCs
> correctly (it seams like the code doesn't detect IXMT status correctly,
> but I am still investigating). It is likely that it is caused by
> something similar to the problem above.
The code certainly works on real silicon, so the cause must be something
local to your environment.
Cheers,
Ralf
^ permalink raw reply
* Re: PCI resource unavailable on mips
From: Ralf Baechle @ 2007-12-16 22:46 UTC (permalink / raw)
To: Jon Dufresne; +Cc: linux-kernel, linux-mips
In-Reply-To: <1197666735.3800.1.camel@microwave.infinitevideocorporation.com>
On Fri, Dec 14, 2007 at 04:12:15PM -0500, Jon Dufresne wrote:
> Hmm, I found more strange behavior with the bars that may or may not be
> related. I wrote a function that does another sanity check. It does an
> ioremap on one of the working bars, then reads one address for
> correctness. This is just to confirm that iomem is working. This is what
> the function looks like:
>
> > void dump_mmio(struct pci_dev *dev)
> > {
> > unsigned long phys, size;
> > struct resource *mem_region;
> > void __iomem *mmio;
> > u32 dword;
> >
> > phys = pci_resource_start(dev, 1);
> > size = pci_resource_len(dev, 1);
> >
> > mem_region = request_mem_region(phys, size, MODULENAME);
> > BUG_ON(!mem_region);
> > mmio = ioremap_nocache(phys, size);
> > BUG_ON(!mmio);
> >
> > printk("******************MMIO*************************************\n");
> > printk("mmio=0x%p phys=0x%08lx size=0x%08lx\n", mmio, phys, size);
> > dword = ioread32(mmio + PCI_MMIO_BASE + 0x40);
> > printk("dword=%x\n", dword);
> > printk("***********************************************************\n");
> >
> > iounmap(mmio);
> > release_mem_region(phys, size);
> > }
>
> on x86 this prints out what I would expect with the correct value which
> is:
>
> > ******************MMIO*************************************
> > mmio=0xf8e80000 phys=0xefa00000 size=0x00200000
> > dword=54061131
> > ***********************************************************
>
> on mips however this crashes the kernel with a "Data bus error" the
> exact output is below:
>
> > ******************MMIO*************************************
> > mmio=0xc0300000 phys=0x24000000 size=0x00200000
The virtual address 0xc0300000 looks sensible and the physical address
0x24000000 is consistent with what you found in the BAR registers. So that
all looks reasonable but that only means not obviously wrong. So next I
wonder what the value of PCI_MMIO_BASE is ...
> > Cpu 0
> > $ 0 : 00000000 10008400 c0340040 802e031c
> > $ 4 : 802e031c 802e0000 00000001 8019f924
> > $ 8 : 802e0000 0000020b 80320000 80320000
> > $12 : 80320000 00000001 83031be6 8031c960
> > $16 : 80086994 c0300000 24000000 00200000
> > $20 : 802e0000 802e1ae4 c025a000 8008cde4
> > $24 : 00000006 00000000
> > $28 : 83030000 83031d20 c0288aec c02799f4
> > Hi : 00000051
> > Lo : eb851f00
> > epc : c0279a00 Tainted: P
> > ra : c02799f4 Status: 10008403 KERNEL EXL IE
> > Cause : 1080001c
> > PrId : 00061200
> > Modules linked in: tmman1700(P) mousedev usbhid usb_storage phStbFB(P) phStbFBRead(P) phStbVideoRenderer(P) phStbVe
> > Process insmod (pid: 785, threadinfo=83030000, task=8109f8e8)
> > Stack : c0288b28 c0300000 24000000 00200000 810b9c54 00000003 c0290000 810b9c00
> > c0288b28 c0279ae4 83031d48 00000002 00000000 00000000 810b9c00 c0288510
> > 00000000 80373480 80177520 801774e4 810b9d1c c0288544 80177574 829f6066
> > 810b9d1c 810b9c48 c0288544 801a3d40 810b9d1c 801a4538 81091c00 8011fc70
> > 810b9d1c 810b9c48 c0288544 c0288544 801a475c 801a475c 801a2810 80168e08
> > ...
> > Call Trace:[<c0279ae4>][<80177520>][<801774e4>][<80177574>][<801a3d40>][<801a4538>][<8011fc70>][<801a475c>][<801a4]
> >
> > Code: 3c020004 34420040 02221021 <8c450000> 3c04c028 0200f809 24845164 3c04c028 0200f809
> > Segmentation fault
>
> The data bus error occurs whenever I do a ioreadX on the ioremapped area. Any idea why this doesn't work on the mips?
A bus error is an exception which is signalled by agent external (often
called system controller) to the CPU core to signal a fatal error during a
read or write bus transaction, for example after a bus timeout or if the
address of the read/write isn't assigned to any device. PCI master abort
also is often mapped to a bus error exception.
Ralf
^ permalink raw reply
* [PATCH][1/2][MIPS] remove unused struct bootloader_header
From: Yoichi Yuasa @ 2007-12-16 13:53 UTC (permalink / raw)
To: Ralf Baechle; +Cc: yoichi_yuasa, linux-mips
Removed unused struct bootloader_header.
Signed-off-by: Yoichi Yuasa <yoichi_yuasa@tripeaks.co.jp>
diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/lasat/image/head.S mips/arch/mips/lasat/image/head.S
--- mips-orig/arch/mips/lasat/image/head.S 2007-11-05 08:41:37.923119250 +0900
+++ mips/arch/mips/lasat/image/head.S 2007-11-05 08:31:39.865743000 +0900
@@ -1,4 +1,5 @@
-#include <asm/lasat/head.h>
+#define LASAT_K_MAGIC0_VAL 0xfedeabba
+#define LASAT_K_MAGIC1_VAL 0xbedead
.text
.section .text.start, "ax"
@@ -21,7 +22,6 @@
.word _kernel_entry
/* Here we have room for future flags */
-
.org 0x40
reldate:
.word TIMESTAMP
diff -pruN -X mips/Documentation/dontdiff mips-orig/include/asm-mips/lasat/head.h mips/include/asm-mips/lasat/head.h
--- mips-orig/include/asm-mips/lasat/head.h 2007-11-05 08:41:37.991123500 +0900
+++ mips/include/asm-mips/lasat/head.h 1970-01-01 09:00:00.000000000 +0900
@@ -1,22 +0,0 @@
-/*
- * Image header stuff
- */
-#ifndef _HEAD_H
-#define _HEAD_H
-
-#define LASAT_K_MAGIC0_VAL 0xfedeabba
-#define LASAT_K_MAGIC1_VAL 0x00bedead
-
-#ifndef _LANGUAGE_ASSEMBLY
-#include <linux/types.h>
-struct bootloader_header {
- u32 magic[2];
- u32 version;
- u32 image_start;
- u32 image_size;
- u32 kernel_start;
- u32 kernel_entry;
-};
-#endif
-
-#endif /* _HEAD_H */
^ permalink raw reply
* [PATCH][2/2][MIPS] remove unused lasat definitions
From: Yoichi Yuasa @ 2007-12-16 13:54 UTC (permalink / raw)
To: Ralf Baechle; +Cc: yoichi_yuasa, linux-mips
In-Reply-To: <20071216225300.6069fe55.yoichi_yuasa@tripeaks.co.jp>
Removed unused lasat definitions.
Signed-off-by: Yoichi Yuasa <yoichi_yuasa@tripeaks.co.jp>
diff -pruN -X mips/Documentation/dontdiff mips-orig/include/asm-mips/lasat/lasat.h mips/include/asm-mips/lasat/lasat.h
--- mips-orig/include/asm-mips/lasat/lasat.h 2007-12-11 23:12:53.674363750 +0900
+++ mips/include/asm-mips/lasat/lasat.h 2007-12-12 00:14:56.073369250 +0900
@@ -245,9 +245,6 @@ static inline void lasat_ndelay(unsigned
#define LASAT_SERVICEMODE_MAGIC_1 0xdeadbeef
#define LASAT_SERVICEMODE_MAGIC_2 0xfedeabba
-/* Lasat 100 boards */
-#define LASAT_GT_BASE (KSEG1ADDR(0x14000000))
-
/* Lasat 200 boards */
#define Vrc5074_PHYS_BASE 0x1fa00000
#define Vrc5074_BASE (KSEG1ADDR(Vrc5074_PHYS_BASE))
diff -pruN -X mips/Documentation/dontdiff mips-orig/include/asm-mips/mach-lasat/mach-gt64120.h mips/include/asm-mips/mach-lasat/mach-gt64120.h
--- mips-orig/include/asm-mips/mach-lasat/mach-gt64120.h 2007-12-11 23:12:54.162394250 +0900
+++ mips/include/asm-mips/mach-lasat/mach-gt64120.h 2007-12-12 00:13:39.216566000 +0900
@@ -11,17 +11,6 @@
/*
* GT64120 config space base address on Lasat 100
*/
-#define GT64120_BASE (KSEG1ADDR(0x14000000))
-
-/*
- * PCI Bus allocation
- *
- * (Guessing ...)
- */
-#define GT_PCI_MEM_BASE 0x12000000UL
-#define GT_PCI_MEM_SIZE 0x02000000UL
-#define GT_PCI_IO_BASE 0x10000000UL
-#define GT_PCI_IO_SIZE 0x02000000UL
-#define GT_ISA_IO_BASE PCI_IO_BASE
+#define GT64120_BASE KSEG1ADDR(GT_DEF_BASE)
#endif /* _ASM_GT64120_LASAT_GT64120_DEP_H */
^ permalink raw reply
* Re: Still no 2.6.24 on ip32
From: Giuseppe Sacco @ 2007-12-15 20:07 UTC (permalink / raw)
To: Ricardo Mendoza, linux-mips
In-Reply-To: <475EC648.8030906@kanux.com>
Hi Ricardo,
On Tue, Dec 11, 2007 at 01:18:00PM -0400, Ricardo Mendoza wrote:
> Giuseppe Sacco wrote:
> > On Tue, Dec 11, 2007 at 09:26:42AM -0400, Ricardo Mendoza wrote:
> >> Giuseppe Sacco wrote:
> >>
> >>> I just checked that my repository is up to date, so my problem is still
> >>> there (thus I don't know if it is the same problem you fixed).
> >>>
> >>> BTW, what was the problem you fixed? I would like to have a look to it,
> >>> to better understand what's going on there.
> >> Well I just updated to see if anything had broken in the past few days,
> >> but I don't seem to be hitting that error of yours. Could you send your
> >> config to see if I can reproduce it?
> >
> > Yes, sure: http://eppesuigoccas.homedns.org/~giuseppe/debian/config-2.6.24-rc4-ip32.bz2
> > but please note that the problem is present in every kernel since 2.6.24-rc1
> >
> > my boot stanza in arcboot is:
> >
> > label=test
> > image=/boot/vmlinux-2.6.24-rc4-gs1
> > append="root=/dev/sda1 ro video=gbefb:1024x768-16@60 debug initcall_debug console=tty0 console=ttyS1,115200"
>
> Ran it without problems, can't get into much detail right now but I the
> problem you are seeing is more than likely caused by your other patch to
> serial_core.c.
I made a few run, recompiled everything from scratch, without my patch,
but I always had the system loop on IRQ #13 while booting.
Do you test on ip32? SGI O2 R5000@200? I would like to know any difference
between our test environments.
Thanks,
Gisueppe
^ permalink raw reply
* Re: PCI resource unavailable on mips
From: Jon Dufresne @ 2007-12-14 21:12 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux-kernel, linux-mips
In-Reply-To: <20071214093945.GA25186@linux-mips.org>
> Odd. I knew the resource allocation stuff has it's issues for some
> non-trivial configuration but that one is a new one. Which makes me
> wonder if your platform runs the PCI code in probe-only mode where it
> will not actually assign resources but only inherit the whole PCI setup
> except interrupt routing from the firmware.
Hmm, I found more strange behavior with the bars that may or may not be
related. I wrote a function that does another sanity check. It does an
ioremap on one of the working bars, then reads one address for
correctness. This is just to confirm that iomem is working. This is what
the function looks like:
> void dump_mmio(struct pci_dev *dev)
> {
> unsigned long phys, size;
> struct resource *mem_region;
> void __iomem *mmio;
> u32 dword;
>
> phys = pci_resource_start(dev, 1);
> size = pci_resource_len(dev, 1);
>
> mem_region = request_mem_region(phys, size, MODULENAME);
> BUG_ON(!mem_region);
> mmio = ioremap_nocache(phys, size);
> BUG_ON(!mmio);
>
> printk("******************MMIO*************************************\n");
> printk("mmio=0x%p phys=0x%08lx size=0x%08lx\n", mmio, phys, size);
> dword = ioread32(mmio + PCI_MMIO_BASE + 0x40);
> printk("dword=%x\n", dword);
> printk("***********************************************************\n");
>
> iounmap(mmio);
> release_mem_region(phys, size);
> }
on x86 this prints out what I would expect with the correct value which
is:
> ******************MMIO*************************************
> mmio=0xf8e80000 phys=0xefa00000 size=0x00200000
> dword=54061131
> ***********************************************************
on mips however this crashes the kernel with a "Data bus error" the
exact output is below:
> ******************MMIO*************************************
> mmio=0xc0300000 phys=0x24000000 size=0x00200000
> Data bus error, epc == c0279a00, ra == c02799f4
> Oops[#1]:
> Cpu 0
> $ 0 : 00000000 10008400 c0340040 802e031c
> $ 4 : 802e031c 802e0000 00000001 8019f924
> $ 8 : 802e0000 0000020b 80320000 80320000
> $12 : 80320000 00000001 83031be6 8031c960
> $16 : 80086994 c0300000 24000000 00200000
> $20 : 802e0000 802e1ae4 c025a000 8008cde4
> $24 : 00000006 00000000
> $28 : 83030000 83031d20 c0288aec c02799f4
> Hi : 00000051
> Lo : eb851f00
> epc : c0279a00 Tainted: P
> ra : c02799f4 Status: 10008403 KERNEL EXL IE
> Cause : 1080001c
> PrId : 00061200
> Modules linked in: tmman1700(P) mousedev usbhid usb_storage phStbFB(P) phStbFBRead(P) phStbVideoRenderer(P) phStbVe
> Process insmod (pid: 785, threadinfo=83030000, task=8109f8e8)
> Stack : c0288b28 c0300000 24000000 00200000 810b9c54 00000003 c0290000 810b9c00
> c0288b28 c0279ae4 83031d48 00000002 00000000 00000000 810b9c00 c0288510
> 00000000 80373480 80177520 801774e4 810b9d1c c0288544 80177574 829f6066
> 810b9d1c 810b9c48 c0288544 801a3d40 810b9d1c 801a4538 81091c00 8011fc70
> 810b9d1c 810b9c48 c0288544 c0288544 801a475c 801a475c 801a2810 80168e08
> ...
> Call Trace:[<c0279ae4>][<80177520>][<801774e4>][<80177574>][<801a3d40>][<801a4538>][<8011fc70>][<801a475c>][<801a4]
>
> Code: 3c020004 34420040 02221021 <8c450000> 3c04c028 0200f809 24845164 3c04c028 0200f809
> Segmentation fault
The data bus error occurs whenever I do a ioreadX on the ioremapped area. Any idea why this doesn't work on the mips?
Thanks,
Jon
^ 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