aboutsummaryrefslogtreecommitdiff
path: root/arch/arm/mach-s3c2410/s3c2410.c
AgeCommit message (Collapse)Author
2006-12-17[ARM] 4049/1: S3C24XX: fix sparse warning due to upf_t in regs-serial.hBen Dooks
Change the include/asm-arm/arch-s3c2410/regs-serial.h platform data to use the prorper type (upf_t) for the uart_flags. Fix all the other parts of arch/arm/mach-s3c2410 to include <linux/serial_core.h> and all other uses of the include file. mach-rx3715.c:101:18: warning: incorrect type in initializer (different base types) mach-rx3715.c:101:18: expected unsigned long [unsigned] uart_flags mach-rx3715.c:101:18: got restricted unsigned int [usertype] [force] <noident> Signed-off-by: Ben Dooks <ben-linux@fluff.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-12-17[ARM] 4045/1: S3C24XX: remove old VA for non-shared areasBen Dooks
Remove old (and non-shared) VA addresses from the mappings in arch/arm/mach-s3c2410/map.h and anywhere they are being mapped in arch/arm/mach-s3c2410 Signed-off-by: Ben Dooks <ben-linux@fluff.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-09-25[ARM] 3843/1: S3C24XX: Remove modfication lines from commentsBen Dooks
Remove the redundant Modification lines from the top of the files in arch/arm/mach-s3c2410 Signed-off-by: Ben Dooks <ben-linux@fluff.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-06-22[ARM] 3627/1: S3C24XX: split s3c2410 clocks from core clocksBen Dooks
Patch from Ben Dooks Split the s3c2410 specific clocks from the core clock code, as part of the work to support more of the Samsung line of SoCs. The patch does not use the sysdev mechanism as the clocks are needed for the timer init, which is very early in the kernel init sequence. Signed-off-by: Ben Dooks <ben-linux@fluff.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-06-22[ARM] 3613/1: S3C2410: Add sysdev and sysclassBen Dooks
Patch from Ben Dooks The S3C2440 and S3C2442 both have their own sysdev and sysclass for differentiating them from the currently default S3C2410. Add a sysdev for the S3C2410 as part of the work to make the code be non-dependant on the S3C2410. Signed-off-by: Ben Dooks <ben-linux@fluff.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-06-18[ARM] 3557/1: S3C24XX: centralise and cleanup uart registrationBen Dooks
Patch from Ben Dooks All the S3C24XX based devices currently have similar uart blocks, in the same location. Make the process of adding new uart blocks easier by commonising the device definitions and adding a new init function for the cpu code. Signed-off-by: Ben Dooks <ben-linux@fluff.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-10-29Create platform_device.h to contain all the platform device details.Russell King
Convert everyone who uses platform_bus_type to include linux/platform_device.h. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-10-13[ARM] 3006/1: S3C2410 - arch/arm/mach-s3c2410 sparse fixesBen Dooks
Patch from Ben Dooks Remove an unused variable from s3c2410.c and ensure that items not needed to be exported from s3c2440.c are declared static. Signed-off-by: Ben Dooks <ben-linux@fluff.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-08-17[ARM] 2850/1: Remove duplicate UART I/O mapping from s3c2410_iodescDimitry Andric
Patch from Dimitry Andric This patch removes the initial UART I/O mapping from s3c2410_iodesc, since the same mapping is already done in the function s3c24xx_init_io in the file arch/arm/mach-s3c2410/cpu.c, through the s3c_iodesc array. I'm not sure if duplicate mappings do any harm, but it's simply redundant. Also, in s3c2440.c the UART I/O mapping is NOT done. Additionally, I put a comma behind the last mapping, to ease copy/pasting stuff around, and make the style consistent with s3c2440.c and other files. Signed-off-by: Dimitry Andric <dimitry@andric.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-04-16Linux-2.6.12-rc2Linus 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!