mirror of
https://github.com/BobTheBlinker/android_kernel_motorola_sm6375.git
synced 2026-10-10 06:09:23 -04:00
No description
- C 98.2%
- Assembly 1%
- Makefile 0.3%
- Shell 0.2%
- Python 0.1%
| Filename | Latest commit message | Latest commit date |
|---|---|---|
8ee90c5c3f
The Nubus subsystem should not be concerned with differences between VIA, RBV and OSS platforms. It should be portable across Macs and PowerMacs. This goal has implications for the initialization code relating to bus locking and slot interrupts. During Nubus initialization, bus transactions are "unlocked": on VIA2 and RBV machines, via_nubus_init() sets a bit in the via2[gBufB] register to allow bus-mastering Nubus cards to arbitrate for the bus. This happens upon subsys_initcall(nubus_init). But because nubus_init() has no effect on card state, this sequence is arbitrary. Moreover, when Penguin is used to boot Linux, the bus is already unlocked when Linux starts. On OSS machines there's no attempt to unlock Nubus transactions at all. (Maybe there's no benefit on that platform or maybe no-one knows how.) All of this demonstrates that there's no benefit in locking out bus-mastering cards, as yet. (If the need arises, we could lock the bus for the duration of a timing-critical operation.) NetBSD unlocks the Nubus early (at VIA initialization) and we can do the same. via_nubus_init() is also responsible for some VIA interrupt setup that should happen earlier than subsys_initcall(nubus_init). And actually, the Nubus subsystem need not be involved with slot interrupts: SLOT2IRQ works fine because Nubus slot IRQs are geographically assigned (regardless of platform). For certain platforms with PDS slots, some Nubus IRQs may be platform IRQs and this is not something that the NuBus subsystem should worry about. So let's invoke via_nubus_init() earlier and make the platform responsible for bus unlocking and interrupt setup instead of the NuBus subsystem. Tested-by: Stan Johnson <userm57@yahoo.com> Signed-off-by: Finn Thain <fthain@telegraphics.com.au> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> |
||
| arch | ||
| block | ||
| certs | ||
| crypto | ||
| Documentation | ||
| drivers | ||
| firmware | ||
| fs | ||
| include | ||
| init | ||
| ipc | ||
| kernel | ||
| lib | ||
| mm | ||
| net | ||
| samples | ||
| scripts | ||
| security | ||
| sound | ||
| tools | ||
| usr | ||
| virt | ||
| .cocciconfig | ||
| .get_maintainer.ignore | ||
| .gitattributes | ||
| .gitignore | ||
| .mailmap | ||
| COPYING | ||
| CREDITS | ||
| Kbuild | ||
| Kconfig | ||
| MAINTAINERS | ||
| Makefile | ||
| README | ||
Linux kernel ============ This file was moved to Documentation/admin-guide/README.rst Please notice that there are several guides for kernel developers and users. These guides can be rendered in a number of formats, like HTML and PDF. In order to build the documentation, use ``make htmldocs`` or ``make pdfdocs``. There are various text files in the Documentation/ subdirectory, several of them using the Restructured Text markup notation. See Documentation/00-INDEX for a list of what is contained in each file. Please read the Documentation/process/changes.rst file, as it contains the requirements for building and running the kernel, and information about the problems which may result by upgrading your kernel.