- 26 9月, 2007 1 次提交
-
-
由 Jochen Friedrich 提交于
cpm_dpram_addr returns physical memory of the DP RAM instead of iomapped virtual memory. As there usually is a 1:1 MMU map of the IMMR area, this is often not noticed. However, cpm_dpram_phys assumes this iomapped virtual memory and returns garbage on the 1:1 mapped memory causing CPM1 uart console to fail. This patch fixes the problem (copied from the powerpc tree). Signed-off-by: NJochen Friedrich <jochen@scram.de>
-
- 12 5月, 2007 1 次提交
-
-
由 Simon Arlott 提交于
Spelling fixes in arch/ppc/. Signed-off-by: NSimon Arlott <simon@fire.lp0.eu> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 10 5月, 2007 1 次提交
-
-
由 Timur Tabi 提交于
The rheap allocation functions return a pointer, but the actual value is based on how the heap was initialized, and so it can be anything, e.g. an offset into a buffer. A ulong is a better representation of the value returned by the allocation functions. This patch changes all of the relevant rheap functions to use a unsigned long integers instead of a pointer. In case of an error, the value returned is a negative error code that has been cast to an unsigned long. The caller can use the IS_ERR_VALUE() macro to check for this. All code which calls the rheap functions is updated accordingly. Macros IS_MURAM_ERR() and IS_DPERR(), have been deleted in favor of IS_ERR_VALUE(). Also added error checking to rh_attach_region(). Signed-off-by: NTimur Tabi <timur@freescale.com> Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
-
- 13 4月, 2007 1 次提交
-
-
由 Vitaly Bordug 提交于
Fix compilation of mpc866ads_setup.c Signed-off-by: NVitaly Bordug <vbordug@ru.mvista.com> Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
-
- 10 10月, 2006 1 次提交
-
-
由 Al Viro 提交于
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 30 6月, 2006 1 次提交
-
-
由 Ingo Molnar 提交于
This patch-queue improves the generic IRQ layer to be truly generic, by adding various abstractions and features to it, without impacting existing functionality. While the queue can be best described as "fix and improve everything in the generic IRQ layer that we could think of", and thus it consists of many smaller features and lots of cleanups, the one feature that stands out most is the new 'irq chip' abstraction. The irq-chip abstraction is about describing and coding and IRQ controller driver by mapping its raw hardware capabilities [and quirks, if needed] in a straightforward way, without having to think about "IRQ flow" (level/edge/etc.) type of details. This stands in contrast with the current 'irq-type' model of genirq architectures, which 'mixes' raw hardware capabilities with 'flow' details. The patchset supports both types of irq controller designs at once, and converts i386 and x86_64 to the new irq-chip design. As a bonus side-effect of the irq-chip approach, chained interrupt controllers (master/slave PIC constructs, etc.) are now supported by design as well. The end result of this patchset intends to be simpler architecture-level code and more consolidation between architectures. We reused many bits of code and many concepts from Russell King's ARM IRQ layer, the merging of which was one of the motivations for this patchset. This patch: rename desc->handler to desc->chip. Originally i did not want to do this, because it's a big patch. But having both "desc->handler", "desc->handle_irq" and "action->handler" caused a large degree of confusion and made the code appear alot less clean than it truly is. I have also attempted a dual approach as well by introducing a desc->chip alias - but that just wasnt robust enough and broke frequently. So lets get over with this quickly. The conversion was done automatically via scripts and converts all the code in the kernel. This renaming patch is the first one amongst the patches, so that the remaining patches can stay flexible and can be merged and split up without having some big monolithic patch act as a merge barrier. [akpm@osdl.org: build fix] [akpm@osdl.org: another build fix] Signed-off-by: NIngo Molnar <mingo@elte.hu> Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 20 1月, 2006 1 次提交
-
-
由 Vitaly Bordug 提交于
This adds setbitsXX/clrbitsXX macro for read-modify-write operations and converts the 8xx core and drivers to use them. Signed-off-by: NVitaly Bordug <vbordug@ru.mvista.com> Signed-off-by: NMarcelo Tosatti <marcelo.tosatti@cyclades.com> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 03 11月, 2005 1 次提交
-
-
由 Marcelo Tosatti 提交于
Current comment on top of m8xx_cpm_dpinit is wrong. Signed-off-by: NMarcelo Tosatti <marcelo.tosatti@cyclades.com> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 29 10月, 2005 1 次提交
-
-
由 Marcelo Tosatti 提交于
Convert core 8xx drivers to use in_xxxbe/in_xxx macros instead of direct memory references. Other than making IO accesses explicit (which is a plus for readability), a common set of macros provides a unified place for the volatile flag to constraint compiler code reordering. There are several unlucky places at the moment which lack the volatile flag. Signed-off-by: NMarcelo Tosatti <marcelo.tosatti@cyclades.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 08 8月, 2005 2 次提交
-
-
由 Marcelo Tosatti 提交于
Touching the pte directly causes the 8Mbyte TLB entry to be invalidated. This has been fixed in v2.4 for ages. Signed-off-by: NMarcelo Tosatti <marcelo.tosatti@cyclades.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
8xx: commproc.c: kill unused variable Signed-off-by: NAristeu Sergio Rozanski Filho <aris@cathedrallabs.org> Signed-off-by: NMarcelo Tosatti <marcelo.tosatti@cyclades.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 17 4月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
-