- 27 Sep, 2006 40 commits
-
-
Ralf Baechle authored
Mostly based on patch by Chris Dearman and cleanups from Yoichi. Signed-off-by:Ralf Baechle <ralf@linux-mips.org>
-
Ralf Baechle authored
Signed-off-by: -
Peter Watkins authored
The code in pgtable-64.h assumes TASK_SIZE is always bigger than a first level PGDIR_SIZE. This is not the case for 64K pages, where task size is 40 bits (1TB) and a pgd entry can map 42 bits. This leads to USER_PTRS_PER_PGD being zero for 64K pages. Signed-off-by:
Peter Watkins <treestem@gmail.com> Signed-off-by:
-
thomas@koeller.dyndns.org authored
This patch introduces a number of configuration variables. These allow to specify presence/absence of integrated peripherals found on the MIPS RM9xxx processor family, based on the particular processor model used. Signed-off-by:
Thomas Koeller <thomas.koeller@baslerweb.com> Signed-off-by:
-
thomas@koeller.dyndns.org authored
excite_fpga.h, like all platform headers, really belongs in the platform header directory. Signed-off-by:
-
thomas@koeller.dyndns.org authored
The excite platform exports hardware resources for device drivers to use. Any driver wanting to use these resources will look up them by their names. Since these resources are declared to have static linkage, but are not used in the source file defining them, the compiler used to emit an 'unused' warning, which this patch suppresses. Signed-off-by:
-
Ralf Baechle authored
Signed-off-by: -
Atsushi Nemoto authored
Signed-off-by:
Atsushi Nemoto <anemo@mba.ocn.ne.jp> Signed-off-by:
-
Yoichi Yuasa authored
Signed-off-by:
Yoichi Yuasa <yoichi_yuasa@tripeaks.co.jp> Signed-off-by:
-
Ralf Baechle authored
Signed-off-by: -
Yoichi Yuasa authored
Signed-off-by:
-
Ralf Baechle authored
With more recent compilers inline doesn't necessarily means a function will always be inlined. So leave that decission to the compiler and make the function as __init. Signed-off-by: -
Ralf Baechle authored
Signed-off-by: -
Ralf Baechle authored
There is no need for a compat version. Signed-off-by: -
Ralf Baechle authored
-
Maciej W. Rozycki authored
The following change updates the Atlas interrupt handling to match that of Malta. Tested with a 5Kc and a 34Kf successfully. Signed-off-by:
Maciej W. Rozycki <macro@mips.com> Signed-off-by:
-
Maciej W. Rozycki authored
Atlas maps its RTC chip in the host mmio space rather than using the "traditional" location in the PCI/ISA port space. A change that has happened to the generic RTC header requires to define ARCH_RTC_LOCATION now. Signed-off-by:
-
Kevin D. Kissell authored
In hooking up the perf counter overflow interrupt to the experimental deprecated-real-soon-now /proc/perf interface last night, I had to revisit arch/mips/mips-boards/generic/time.c, and discovered that when the 2.6.9-based SMTC prototype was merged with the more recent tree, it was missed that arch/mips/kernel/time.c had changed so that even in SMP kernels, timer_interrupt() calls local_timer_interrupt(), so there is no longer a need to invoke it directly from mips_timer_interrupt() in those cases where timer_interrupt() has been called. So I got rid of that, and added the invocation of perf_irq() if Cause.PCI is set, more-or-less following the same logic as in the non-SMTC case, with the modifications that (a) a runtime check for Release 2 isn't done, because it's redundant in SMTC), and (b) we check for a clock interrupt regardless of the value returned by the perf counter service - I don't understand why we'd want to control that with perf_irq(), but maybe one of you knows the story. I also got rid of the stupid warning about the unused variable when compiled for SMTC (another artifact of the merge). The result hasn't been beaten to death, but boots, seems stable, and supports extended precision event counting. Signed-off-by:
Kevin D. Kissell <kevink@mips.com> Signed-off-by:
-
Atsushi Nemoto authored
If a thread became runnable between need_resched() and the WAIT instruction, switching to the thread will delay until a next interrupt. Some CPUs can execute the WAIT instruction with interrupt disabled, so we can get rid of this race on them (at least UP case). Original Patch by Atsushi with fixing up for MIPS Technology's cores by Ralf based on feedback from the RTL designers. Signed-off-by:
-
Atsushi Nemoto authored
Signed-off-by:
-
Atsushi Nemoto authored
* export asm/sgidefs.h * include asm/isadep.h only if in kernel * do not export contents of asm/timex.h and asm/user.h Signed-off-by:
-
Ralf Baechle authored
Signed-off-by: -
Ralf Baechle authored
generic__raw_read_trylock() is a defect generic function actually doing a __raw_read_lock ... Signed-off-by: -
Maciej W. Rozycki authored
Signed-off-by:
-
Alexander Bigga authored
I've encountered a serious problem with PCI config space access on Au1x000 platforms with recent 2.6.x-kernel. With 2.4.31 the same hardware works fine. So I was looking for the differences: Symptoms: - no PCI-device is seen on bootup though two or three cards are present - lspci output is empty - OR: lspci shows 20 times the same device (- OR: in some slot-configurations it worked anyhow) System(s): 1. platform with Au1500 and three PCI-devices (actually a mycable XXS1500 with backplane for three PCI-devices) 2. platform with Au1550 and two PCI-devices (custom board) Debugging: I digged down to the config_access() of the au1xxx-processors in arch/mips/pci/ops-au1000.c and switched on DEBUG. The code of config_access() seems to be almost the same as of the 2.4.x-kernel. But the "pci_cfg_vm->addr" returned by get_vm_area(0x2000, 0) once on booting is different. That's of course not forbidden. But the alignment seems to be wrong. In my case, I received: 2.4.31: pci_cfg_vm->addr = c0000000 2.6.18-rc5: pci_cfg_vm->addr = c0101000 To make it short: With 2.6.x it fails on the first config-access with: "PCI ERR detected: status 83a00356". Fixup: My fix is now, to use the VM_IOREMAP-flag in the get_vm_area call. This flag seems to be introduced in mm/vmalloc.c a long time ago (in 2.6.7-bk13, I found in gitweb). Now, the returned address is pci_cfg_vm->addr = c0104000 and everything works fine. Signed-off-by: -
Atsushi Nemoto authored
Since lmo commit 323a380bf9e1a1679a774a2b053e3c1f2aa3f179 ("Simplify dump_stack()") made prepare_frametrace() always inlined, using $2 (v0) in __asm__ is not safe anymore. We can use $1 (at) instead. Also we should use "dla" instead of "la" for 64-bit kernel. Signed-off-by: -
Atsushi Nemoto authored
c-r4k.c and c-sb1.c use drop_mmu_context() to flush virtually tagged I-caches, but this does not work for flushing other task's icache. This is for example triggered by copy_to_user_page() called from ptrace(2). Use indexed flush for such cases. Signed-off-by:
-
Elizabeth Oldham authored
XTC can only be set if VPA is clear, which it may not be. There is also the possibility of a back to back c0 register access hazard to take care of. Signed-off-by: -
Ralf Baechle authored
Signed-off-by: -
Ralf Baechle authored
dclz() expects its 64-bit argument being passed as a single register but on 32-bit kernels it'll actually be in a register pair. Signed-off-by: -
Ralf Baechle authored
... kconfig will do weird stuff. Signed-off-by: -
Ralf Baechle authored
The driver has not been merged yet so selecting it results in a warning message. Signed-off-by: -
Ralf Baechle authored
On the 34K the redundant cache operations were causing excessive stalls resulting in realtime code running on the second VPE missing its deadline. For all other platforms this patch is just a significant performance improvment as illustrated by below benchmark numbers. Processor, Processes - times in microseconds - smaller is better ------------------------------------------------------------------------------ Host OS Mhz null null open slct sig sig fork exec sh call I/O stat clos TCP inst hndl proc proc proc --------- ------------- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- 25Kf 2.6.18-rc4 533 0.49 1.16 7.57 33.4 30.5 1.34 12.4 5497 17.K 54.K 25Kf 2.6.18-rc4-p 533 0.49 1.16 6.68 23.0 30.7 1.36 8.55 5030 16.K 48.K 4Kc 2.6.18-rc4 80 4.21 15.0 131. 289. 261. 16.5 258. 18.K 70.K 227K 4Kc 2.6.18-rc4-p 80 4.34 13.1 128. 285. 262. 18.2 258. 12.K 52.K 176K 34Kc 2.6.18-rc4 40 5.01 14.0 61.6 90.0 477. 17.9 94.7 29.K 108K 342K 34Kc 2.6.18-rc4-p 40 4.98 13.9 61.2 89.7 475. 17.6 93.7 8758 44.K 158K BCM1480 2.6.18-rc4 700 0.28 0.60 3.68 5.92 16.0 0.78 5.08 931. 3163 15.K BCM1480 2.6.18-rc4-p 700 0.28 0.61 3.65 5.85 16.0 0.79 5.20 395. 1464 8385 TX49-16K 2.6.18-rc3 197 0.73 2.41 19.0 37.8 82.9 2.94 17.5 4438 14.K 56.K TX49-16K 2.6.18-rc3-p 197 0.73 2.40 19.9 36.3 82.9 2.94 23.4 2577 9103 38.K TX49-32K 2.6.18-rc3 396 0.36 1.19 6.80 11.8 41.0 1.46 8.17 2738 8465 32.K TX49-32K 2.6.18-rc3-p 396 0.36 1.19 6.82 10.2 41.0 1.46 8.18 1330 4638 18.K Original patch by me with enhancements by Atsushi Nemoto. Signed-off-by: -
Ralf Baechle authored
In entry.S resume_userspace ... jal do_notify_resume form a loop through which the kernel will iterate as long as work is pending. If we iterate through this loop more than once with no signal pending for at least one but the last iteration we will take do the syscall restarting multiple times resulting in a syscall return prior to the the syscall instruction in userspace. This may happen when debugging a multithreaded program. Debugging and original fix by Maciej; extended to other ABIs by me. Signed-off-by:
-
Chris Dearman authored
Recent 34Ks come out of reset with WP enabled on VPE 1 so we take an immediate exception when starting the second VPE. Signed-off-by:
Chris Dearman <chris@mips.com> Signed-off-by:
-
Yoichi Yuasa authored
Signed-off-by:
-
Ralf Baechle authored
Signed-off-by: -
Ralf Baechle authored
Signed-off-by: -
Ralf Baechle authored
Signed-off-by: -
Ralf Baechle authored
CONFIG_IRQ_PER_CPU now controls the IRQ_PER_CPU stuff. Signed-off-by:
-
