- 27 Sep, 2006 40 commits
-
-
Franck Bui-Huu authored
This function although doing simple thing is hard to follow. It's mainly due to: - a lot of #ifdef - bad local names - redundant tests So this patch try to address these issues. It also do not use max_pfn global which is marked as an unused exported symbol. As a bonus side, it's now really easy to see what part of the code is for no-numa system. There's also no point to make this function inline. Signed-off-by: Franck Bui-Huu <vagabon.xyz@gmail.com> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
-
Franck Bui-Huu authored
This array was used to 'cache' some frame info about scheduler functions to speed up get_wchan(). This array was 1Ko size and was only used when CONFIG_KALLSYMS was set but declared for all configs. Rather than make the array statement conditional, this patches removes this array and its uses. Indeed the common case doesn't seem to use this array and get_wchan() is not a critical path anyways. It results in a smaller bss and a smaller/cleaner code: text data bss dec hex filename 2543808 254148 139296 2937252 2cd1a4 vmlinux-new-get-wchan 2544080 254148 143392 2941620 2ce2b4 vmlinux~old Signed-off-by: Franck Bui-Huu <vagabon.xyz@gmail.com> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
-
Franck Bui-Huu authored
This patch adds 2 sanity checks. The first one test that the start address of the function to analyze has been set by the caller. If not return an error since nothing usefull can be done without. The second one checks that the function's size has been set. A null size can happen if CONFIG_KALLSYMS is not set and it means that we don't know the size of the function to analyze. In this case, we make it equal to 128 instructions by default. Signed-off-by: Franck Bui-Huu <vagabon.xyz@gmail.com> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
-
Franck Bui-Huu authored
Signed-off-by: Franck Bui-Huu <vagabon.xyz@gmail.com> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
-
Ralf Baechle authored
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
-
Ralf Baechle authored
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
-
Ralf Baechle authored
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
-
Richard Sandiford authored
MIPS is the only port to call its fstatat()-related syscalls "__NR_fstatat". Now I can see why that might be seen as every other port being wrong, but I think for o32, it is at best confusing. __NR_fstat provides a plain (32-bit) stat while __NR_fstatat provides a 64-bit stat. Changing the name to __NR_fstatat64 would make things more explicit, match x86, and make the glibc port slightly easier. The current name is more appropriate for n32 and n64, but it would be appropriate for other 64-bit targets too, and those targets have chosen to call it __NR_newfstatat instead. Using the same name for MIPS would again be more consistent and make the glibc port slightly easier. I'm not wedded to this idea if the current names are preferred, but FWIW... Signed-off-by: Richard Sandiford <richard@codesourcery.com> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
-
Richard Sandiford authored
While working on a glibc patch to support the fstatat() functions[1], I noticed that the o32 implementation behaves differently on 32-bit and 64-bit kernels; the former provides a stat64 while the latter provides a plain (o32) stat. I think the former is what's intended, as there is no separate fstatat64. It's also what x86 does. I think this is just a case of a compat too far. [1] I've seen Khem's patch, but I don't think it's right. Signed-off-by: Richard Sandiford <richard@codesourcery.com> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
-
Ralf Baechle authored
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
-
Ralf Baechle authored
This is the unchanged part 2 of Chris' hazard cleanup. Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
-
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: Ralf Baechle <ralf@linux-mips.org>
-
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: Ralf Baechle <ralf@linux-mips.org>
-
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: Ralf Baechle <ralf@linux-mips.org>
-
thomas@koeller.dyndns.org authored
excite_fpga.h, like all platform headers, really belongs in the platform header directory. Signed-off-by: Thomas Koeller <thomas.koeller@baslerweb.com> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
-
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: Thomas Koeller <thomas.koeller@baslerweb.com> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
-
Ralf Baechle authored
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
-
Atsushi Nemoto authored
Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
-
Yoichi Yuasa authored
Signed-off-by: Yoichi Yuasa <yoichi_yuasa@tripeaks.co.jp> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
-
Ralf Baechle authored
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
-
Yoichi Yuasa authored
Signed-off-by: Yoichi Yuasa <yoichi_yuasa@tripeaks.co.jp> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
-
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 <ralf@linux-mips.org>
-
Ralf Baechle authored
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
-
Ralf Baechle authored
There is no need for a compat version. Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
-
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: Ralf Baechle <ralf@linux-mips.org>
-
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: Maciej W. Rozycki <macro@mips.com> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
-
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: Ralf Baechle <ralf@linux-mips.org>
-
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 <anemo@mba.ocn.ne.jp> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
-
Atsushi Nemoto authored
Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
-
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: Atsushi Nemoto <anemo@mba.ocn.ne.jp> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
-
Ralf Baechle authored
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
-
Ralf Baechle authored
generic__raw_read_trylock() is a defect generic function actually doing a __raw_read_lock ... Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
-
Maciej W. Rozycki authored
Signed-off-by: Maciej W. Rozycki <macro@mips.com> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
-
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: Ralf Baechle <ralf@linux-mips.org>
-
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 <anemo@mba.ocn.ne.jp> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
-
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: Atsushi Nemoto <anemo@mba.ocn.ne.jp> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
-
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 <ralf@linux-mips.org>
-
Ralf Baechle authored
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
-