Franck Bui-Huu [Fri, 11 Aug 2006 15:51:53 +0000 (17:51 +0200)]
[MIPS] setup.c: use early_param() for early command line parsing
There's no point to rewrite some logic to parse command line
to pass initrd parameters or to declare a user memory area.
We could use instead parse_early_param() that does the same
thing.
Franck Bui-Huu [Fri, 18 Aug 2006 14:18:09 +0000 (16:18 +0200)]
[MIPS] get_wchan(): remove uses of mfinfo[64]
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
Franck Bui-Huu [Fri, 18 Aug 2006 14:18:08 +0000 (16:18 +0200)]
[MIPS] get_frame_info(): null function size means size is unknown
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.
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>
[MIPS] The o32 fstatat syscall behaves differently on 32 and 64 bit kernels
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>
Peter Watkins [Wed, 23 Aug 2006 15:15:49 +0000 (11:15 -0400)]
[MIPS] Fix USER_PTRS_PER_PGD for 64K page size.
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>
[MIPS] Add configuration variables for RM9xxx processor
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>
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 [Tue, 1 Aug 2006 22:39:42 +0000 (23:39 +0100)]
[MIPS] c-r4k: Convert init functions from inline to __init.
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.
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 [Tue, 12 Sep 2006 10:08:08 +0000 (12:08 +0200)]
[MIPS] Patch to arch/mips/mips-boards/generic/time.c
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 [Wed, 7 Jun 2006 16:09:01 +0000 (01:09 +0900)]
[MIPS] Reduce race between cpu_wait() and need_resched() checking
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.
Alexander Bigga [Tue, 29 Aug 2006 14:48:34 +0000 (16:48 +0200)]
[MIPS] Fix for pci config_access on alchemy au1x000
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:
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.
Atsushi Nemoto [Tue, 29 Aug 2006 03:10:22 +0000 (12:10 +0900)]
[MIPS] Make prepare_frametrace() not clobber v0
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.
Atsushi Nemoto [Fri, 25 Aug 2006 08:55:31 +0000 (17:55 +0900)]
[MIPS] Do not use drop_mmu_context to flusing other task's VIPT I-cache.
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.
Ralf Baechle [Sat, 12 Aug 2006 15:40:08 +0000 (16:40 +0100)]
[MIPS] Retire flush_icache_page from mm use.
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.
Ralf Baechle [Tue, 8 Aug 2006 02:47:01 +0000 (03:47 +0100)]
[MIPS] Avoid double signal restarting.
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: Maciej W. Rozycki <macro@mips.com> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Franck Bui-Huu [Thu, 3 Aug 2006 07:29:21 +0000 (09:29 +0200)]
[MIPS] Improve unwind_stack()
This patch allows unwind_stack() to return ra for leaf function.
But it tries to detects cases where get_frame_info() wrongly
consider nested function as a leaf one.
It also pass 'unsinged long *sp' instead of 'unsigned long **sp'
as second parameter. The code looks cleaner.
Franck Bui-Huu [Thu, 3 Aug 2006 07:29:20 +0000 (09:29 +0200)]
[MIPS] Make get_frame_info() more robust
Now get_frame_info() wants to detect move sp instruction first. It
assumes that the save ra in the stack instruction can't happen
before allocating frame size space into the stack.
Franck Bui-Huu [Thu, 3 Aug 2006 07:29:17 +0000 (09:29 +0200)]
[MIPS] Miscellaneous cleanup in prologue analysis code
We usually use backtrace term for dumping a call tree during
debug. Therefore this patch renames show_frametrace() into
show_backtrace() and show_trace() into show_raw_backtrace().
[MIPS] dump_stack() based on prologue code analysis
Instead of dump all possible address in the stack, unwind the stack frame
based on prologue code analysis, as like as get_wchan() does. While the
code analysis might fail for some reason, there is a new kernel option
"raw_show_trace" to disable this feature.
This patch fixes the problem that trying to enable already enabled
slot disables the slot by returning the proper value from
pciehp_enable_slot()/pciehp_disable_slot().
We need to assign resources to ioapics being hot-added. This patch
changes pbus_assign_resources_sorted() to assign resources if the
ioapic has no assigned resources.
Currently acpiphp calls pci_enable_device() against all
hot-added bridges, but acpiphp does not call pci_disable_device()
against them in hot-remove. So ioapic hot-remove would fail.
This patch fixes this issue.
Contrary to PCI bridge hot-add, we need to follow the sequence below
for PCI bridge hot-removal.
(1) Stop devices (detach drivers, remove from the global list, etc.)
(2) Unbind ACPI node from the devices (remove the _PRT entries)
(3) Remove devices (remove from the device list, etc.)
This patch fixes acpiphp driver to follow above sequence for P2P
bridge hot-removal.
This patch adds pci_stop_bus_device() which stops a PCI device (detach
the driver, remove from the global list and so on) and any children.
This is needed for ACPI based PCI-to-PCI bridge hot-remove, and it will
be also needed for ACPI based PCI root bridge hot-remove.
Currently acpiphp initializes all ioapics under the bus on which
hot-add event occured. It also initializes already working ioapics.
This patch fixes this bug.
Alan Cox [Wed, 16 Aug 2006 16:42:18 +0000 (17:42 +0100)]
PCI: Multiprobe sanitizer
There are numerous drivers that can use multithreaded probing but having
some kind of global flag as the way to control this makes migration to
threaded probing hard and since it enables it everywhere and is almost
as likely to cause serious pain as holding a clog dance in a minefield.
If we have a pci_driver multithread_probe flag to inherit you can turn
it on for one driver at a time.
From playing so far however I think we need a different model at the
device layer which serializes until the called probe function says "ok
you can start another one now". That would need some kind of flag and
semaphore plus a helper function.
Anyway in the absence of that this is a starting point to usefully play
with this stuff
Signed-off-by: Alan Cox <alan@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
PCI-Express AER implemetation: AER core and aerdriver
Patch 3 implements the core part of PCI-Express AER and aerdrv
port service driver.
When a root port service device is probed, the aerdrv will call
request_irq to register irq handler for AER error interrupt.
When a device sends an PCI-Express error message to the root port,
the root port will trigger an interrupt, by either MSI or IO-APIC,
then kernel would run the irq handler. The handler collects root
error status register and schedules a work. The work will call
the core part to process the error based on its type
(Correctable/non-fatal/fatal).
As for Correctable errors, the patch chooses to just clear the correctable
error status register of the device.
As for the non-fatal error, the patch follows generic PCI error handler
rules to call the error callback functions of the endpoint's driver. If
the device is a bridge, the patch chooses to broadcast the error to
downstream devices.
As for the fatal error, the patch resets the pci-express link and
follows generic PCI error handler rules to call the error callback
functions of the endpoint's driver. If the device is a bridge, the patch
chooses to broadcast the error to downstream devices.
PCI-Express AER (Advanced Error Reporting) provides more robust error reporting.
The series of patches enable kernel support to AER.
The initial patches were written by Tom Long Nguyen. I ported them to the kernel
2.6.18-rc3. Many thanks to Rajesh Shah and Narayanan Chandramouli for their great
review comments and testing help.
Patch 1 consists of the pciaer-howto.txt document.
Brice Goglin [Thu, 31 Aug 2006 05:55:32 +0000 (01:55 -0400)]
MSI: Blacklist PCI-E chipsets depending on Hypertransport MSI capability
Introduce msi_ht_cap_enabled() to check the MSI capability in the
Hypertransport configuration space.
It is used in a generic quirk quirk_msi_ht_cap() to check whether
MSI is enabled on hypertransport chipset, and a nVidia specific quirk
quirk_nvidia_ck804_msi_ht_cap() where two 2 HT MSI mappings have to
be checked.
Both quirks set the PCI_BUS_FLAGS_NO_MSI bus flag when MSI is disabled.
Brice Goglin [Thu, 31 Aug 2006 05:55:24 +0000 (01:55 -0400)]
MSI: Rename PCI_CAP_ID_HT_IRQCONF into PCI_CAP_ID_HT
0x08 is the HT capability, while PCI_CAP_ID_HT_IRQCONF would be
the subtype 0x80 that mpic_scan_ht_pic() uses.
Rename PCI_CAP_ID_HT_IRQCONF into PCI_CAP_ID_HT.
And by the way, use it in the ipath driver instead of defining its
own HT_CAPABILITY_ID.
Brice Goglin [Thu, 31 Aug 2006 05:55:15 +0000 (01:55 -0400)]
MSI: Export the PCI_BUS_FLAGS_NO_MSI flag in sysfs
Export the PCI_BUS_FLAGS_NO_MSI flag of a PCI bus in the sysfs files
of its parent device and make it writable. Could be used to:
* disable MSI on a device which has not been blacklisted yet
* allow MSI when some setpci hacks enable MSI support (for instance
on the ServerWorks HT2000 chipset where the MSI HT cap is disabled
by default).
Architecture where some bus have no parent chipset cannot use this
strategy to change MSI support.
If the chipset does not have a subordinate bus, its 'bus_msi' file
is empty.
Also document and warn about the possible danger of changing the flag.
Brice Goglin [Thu, 31 Aug 2006 05:55:07 +0000 (01:55 -0400)]
MSI: Factorize common code in pci_msi_supported()
pci_enable_msi() and pci_enable_msix() use the same code to detect
whether MSI might be enabled on this device. Factorize this code in
pci_msi_supported(). And improve the documentation about the fact
that only the root chipset must support MSI, but it is hard to
find the root bus so we check all parent busses MSI flags.
Brice Goglin [Thu, 31 Aug 2006 05:54:56 +0000 (01:54 -0400)]
MSI: Cleanup existing MSI quirks
Move MSI quirks in CONFIG_PCI_MSI, document why the serverworks quirk
does not simply set PCI_BUS_FLAGS_NO_MSI, and create a generic quirk
for other chipsets where setting PCI_BUS_FLAGS_NO_MSI is fine.
projects / linux-2.6 / log