summaryrefslogtreecommitdiffstats
path: root/arch/mn10300/unit-asb2305 (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Separate out the proc- and unit-specific header directories from the generalDavid Howells2009-04-106-2/+353
| | | | | | | | | | | MN10300 arch headers and place them instead in the same directories as contain the .c files for the processor and unit implementations. This permits the symlinks include/asm/proc and include/asm/unit to be dispensed with. This does, however, require that #include <asm/proc/xxx.h> be converted to #include <proc/xxx.h> and similarly for asm/unit -> unit. Signed-off-by: David Howells <dhowells@redhat.com>
* mn10300: fix typo && -> || in arch/mn10300/unit-asb2305/pci.cWei Yongjun2009-02-211-1/+1
| | | | | | | | | Fix the typo && -> ||. Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com> Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* MN10300: Fix IRQ handlingDavid Howells2008-10-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix the IRQ handling on the MN10300 arch. This patch makes a number of significant changes: (1) It separates the irq_chip definition for edge-triggered interrupts from the one for level-triggered interrupts. This is necessary because the MN10300 PIC latches the IRQ channel's interrupt request bit (GxICR_REQUEST), even after the device has ceased to assert its interrupt line and the interrupt channel has been disabled in the PIC. So for level-triggered interrupts we need to clear this bit when we re-enable - which is achieved by setting GxICR_DETECT but not GxICR_REQUEST when writing to the register. Not doing this results in spurious interrupts occurring because calling mask_ack() at the start of handle_level_irq() is insufficient - it fails to clear the REQUEST latch because the device that caused the interrupt is still asserting its interrupt line at this point. (2) IRQ disablement [irq_chip::disable_irq()] shouldn't clear the interrupt request flag for edge-triggered interrupts lest it lose an interrupt. (3) IRQ unmasking [irq_chip::unmask_irq()] also shouldn't clear the interrupt request flag for edge-triggered interrupts lest it lose an interrupt. (4) The end() operation is now left to the default (no-operation) as __do_IRQ() is compiled out. This may affect misrouted_irq(), but according to Thomas Gleixner it's the correct thing to do. (5) handle_level_irq() is used for edge-triggered interrupts rather than handle_edge_irq() as the MN10300 PIC latches interrupt events even on masked IRQ channels, thus rendering IRQ_PENDING unnecessary. It is sufficient to call mask_ack() at the start and unmask() at the end. (6) For level-triggered interrupts, ack() is now NULL as it's not used, and there is no effective ACK function on the PIC. mask_ack() is now the same as mask() as the latch continues to latch, even when the channel is masked. Further, the patch discards the disable() op implementation as its now the same as the mask() op implementation, which is used instead. It also discards the enable() op implementations as they're now the same as the unmask() op implementations, which are used instead. Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* iomap: fix 64 bits resources on 32 bitsBenjamin Herrenschmidt2008-04-291-2/+2
| | | | | | | | | | | | | | Almost all implementations of pci_iomap() in the kernel, including the generic lib/iomap.c one, copies the content of a struct resource into unsigned long's which will break on 32 bits platforms with 64 bits resources. This fixes all definitions of pci_iomap() to use resource_size_t. I also "fixed" the 64bits arch for consistency. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: <linux-arch@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* PCI: remove initial bios sort of PCI devices on x86Greg Kroah-Hartman2008-04-211-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We currently keep 2 lists of PCI devices in the system, one in the driver core, and one all on its own. This second list is sorted at boot time, in "BIOS" order, to try to remain compatible with older kernels (2.2 and earlier days). There was also a "nosort" option to turn this sorting off, to remain compatible with even older kernel versions, but that just ends up being what we have been doing from 2.5 days... Unfortunately, the second list of devices is not really ever used to determine the probing order of PCI devices or drivers[1]. That is done using the driver core list instead. This change happened back in the early 2.5 days. Relying on BIOS ording for the binding of drivers to specific device names is problematic for many reasons, and userspace tools like udev exist to properly name devices in a persistant manner if that is needed, no reliance on the BIOS is needed. Matt Domsch and others at Dell noticed this back in 2006, and added a boot option to sort the PCI device lists (both of them) in a breadth-first manner to help remain compatible with the 2.4 order, if needed for any reason. This option is not going away, as some systems rely on them. This patch removes the sorting of the internal PCI device list in "BIOS" mode, as it's not needed at all anymore, and hasn't for many years. I've also removed the PCI flags for this from some other arches that for some reason defined them, but never used them. This should not change the ordering of any drivers or device probing. [1] The old-style pci_get_device and pci_find_device() still used this sorting order, but there are very few drivers that use these functions, as they are deprecated for use in this manner. If for some reason, a driver rely on the order and uses these functions, the breadth-first boot option will resolve any problem. Cc: Matt Domsch <Matt_Domsch@dell.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* mn10300: add the MN10300/AM33 architecture to the kernelDavid Howells2008-02-088-0/+1205
Add architecture support for the MN10300/AM33 CPUs produced by MEI to the kernel. This patch also adds board support for the ASB2303 with the ASB2308 daughter board, and the ASB2305. The only processor supported is the MN103E010, which is an AM33v2 core plus on-chip devices. [akpm@linux-foundation.org: nuke cvs control strings] Signed-off-by: Masakazu Urade <urade.masakazu@jp.panasonic.com> Signed-off-by: Koichi Yasutake <yasutake.koichi@jp.panasonic.com> Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>