summaryrefslogtreecommitdiffstats
path: root/include/asm-powerpc/fs_pd.h
AgeCommit message (Collapse)Author
2007-10-11[POWERPC] 85xx: Killed <asm/mpc85xx.h>Kumar Gala
asm-powerpc/mpc85xx.h was really a hold over from arch/ppc. Now that more decoupling has occurred we can remove <asm/mpc85xx.h> and some of its legacy. As part of this we moved the definition of CPM_MAP_ADDR into cpm2.h for 85xx platforms. This is a stop gap until drivers stop using CPM_MAP_ADDR. Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
2007-10-04[POWERPC] cpm2: Infrastructure code cleanup.Scott Wood
Mostly sparse fixes (__iomem annotations, etc); also, cpm2_immr is used rather than creating many temporary mappings. Signed-off-by: Scott Wood <scottwood@freescale.com> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
2007-10-03[POWERPC] 8xx: Infrastructure code cleanup.Scott Wood
1. Keep a global mpc8xx_immr mapping, rather than constantly creating temporary mappings. 2. Look for new fsl,cpm1 and fsl,cpm1-pic names. 3. Always reset the CPM when not using the udbg console; this is required in case the firmware initialized a device that is incompatible with one that the kernel is about to use. 4. Remove some superfluous casts and header includes. 5. Change a usage of IMAP_ADDR to get_immrbase(). 6. Use phys_addr_t, not uint, for dpram_pbase. 7. Various sparse-related fixes, such as __iomem annotations. 8. Remove mpc8xx_show_cpuinfo, which doesn't provide anything useful beyond the generic cpuinfo handler. 9. Move prototypes for 8xx support functions from board files to sysdev/commproc.h. Signed-off-by: Scott Wood <scottwood@freescale.com> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
2007-02-07[POWERPC] Fix kernel build errors for mpc8272ads and mpc8560adsVitaly Bordug
Recent update of asm-powerpc/io.h caused cpm-related stuff to break in the current kernel. Current patch fixes it, as well as other inconsistencies expressed, that do not permit targets from working properly: - Updated dts with a chosen node with interrupt controller, - fixed messed device IDs among CPM2 SoC devices, - corrected odd header name and fixed type in defines, - Added 82xx subdir to the powerpc/platforms Makefile, missed during initial commit, - new solely-powerpc header file for 8260 family (was using one from arch/ppc, this one cleaned up from the extra stuff), in fact for now a placeholder to get the board-specific includes for stuff not yet capable to live with devicetree peeks only - Fixed couple of misprints in reference mpc8272 dts. Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-02-07[POWERPC] 8xx: powerpc port of core CPM PICVitaly Bordug
This covers common CPM access functions, CPM interrupt controller code, micropatch and a few compatibility things to kee the same driver base working with arch/ppc. This version is refined with all the comments (mostly PIC-related) addressed. Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-21POWERPC: Get rid of remapping the whole immrVitaly Bordug
The stuff below cleans up the code attempting to remap the whole cpm2_immr early, as well as places happily assuming that fact. This is more like the 2.4 legacy stuff, and is at least confusing and unclear now. To keep the world comfortable, a new mechanism is introduced: before accessing specific immr register/register set, one needs to map it, using cpm2_map(<reg>), for instance, access to CPM command register will look like volatile cpm_cpm2_t *cp = cpm2_map(im_cpm); keeping the code clear, yet without "already defined somewhere" cpm2_immr. So far, unmapping code is not implemented, but it's not a big deal to add it, if the whole idea makes sense. Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
2006-09-21cpm_uart: make it possible to utilize from powerpcVitaly Bordug
Driver core has been updated to make use of the new powerpc OF-inspired platform devices, yet keeping compatibility to the vast board list from ppc. Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>