Documentation/arm/Samsung-S3C24XX/Overview.txt

   1                         S3C24XX ARM Linux Overview
   2                         ==========================
   3
   4
   5
   6 Introduction
   7 ------------
   8
   9   The Samsung S3C24XX range of ARM9 System-on-Chip CPUs are supported
  10   by the 's3c2410' architecture of ARM Linux. Currently the S3C2410,
  11   S3C2412, S3C2413, S3C2440, S3C2442 and S3C2443 devices are supported.
  12
  13   Support for the S3C2400 and S3C24A0 series are in progress.
  14
  15
  16 Configuration
  17 -------------
  18
  19   A generic S3C2410 configuration is provided, and can be used as the
  20   default by `make s3c2410_defconfig`. This configuration has support
  21   for all the machines, and the commonly used features on them.
  22
  23   Certain machines may have their own default configurations as well,
  24   please check the machine specific documentation.
  25
  26
  27 Layout
  28 ------
  29
  30   The core support files are located in the platform code contained in
  31   arch/arm/plat-s3c24xx with headers in include/asm-arm/plat-s3c24xx.
  32   This directory should be kept to items shared between the platform
  33   code (arch/arm/plat-s3c24xx) and the arch/arm/mach-s3c24* code.
  34
  35   Each cpu has a directory with the support files for it, and the
  36   machines that carry the device. For example S3C2410 is contained
  37   in arch/arm/mach-s3c2410 and S3C2440 in arch/arm/mach-s3c2440
  38
  39   Register, kernel and platform data definitions are held in the
  40   arch/arm/mach-s3c2410 directory./include/mach
  41
  42 arch/arm/plat-s3c24xx:
  43
  44   Files in here are either common to all the s3c24xx family,
  45   or are common to only some of them with names to indicate this
  46   status. The files that are not common to all are generally named
  47   with the initial cpu they support in the series to ensure a short
  48   name without any possibility of confusion with newer devices.
  49
  50   As an example, initially s3c244x would cover s3c2440 and s3c2442, but
  51   with the s3c2443 which does not share many of the same drivers in
  52   this directory, the name becomes invalid. We stick to s3c2440-<x>
  53   to indicate a driver that is s3c2440 and s3c2442 compatible.
  54
  55   This does mean that to find the status of any given SoC, a number
  56   of directories may need to be searched.
  57
  58
  59 Machines
  60 --------
  61
  62   The currently supported machines are as follows:
  63
  64   Simtec Electronics EB2410ITX (BAST)
  65
  66     A general purpose development board, see EB2410ITX.txt for further
  67     details
  68
  69   Simtec Electronics IM2440D20 (Osiris)
  70
  71     CPU Module from Simtec Electronics, with a S3C2440A CPU, nand flash
  72     and a PCMCIA controller.
  73
  74   Samsung SMDK2410
  75
  76     Samsung's own development board, geared for PDA work.
  77
  78   Samsung/Aiji SMDK2412
  79
  80     The S3C2412 version of the SMDK2440.
  81
  82   Samsung/Aiji SMDK2413
  83
  84     The S3C2412 version of the SMDK2440.
  85
  86   Samsung/Meritech SMDK2440
  87
  88     The S3C2440 compatible version of the SMDK2440, which has the
  89     option of an S3C2440 or S3C2442 CPU module.
  90
  91   Thorcom VR1000
  92
  93     Custom embedded board
  94
  95   HP IPAQ 1940
  96
  97     Handheld (IPAQ), available in several varieties
  98
  99   HP iPAQ rx3715
 100
 101     S3C2440 based IPAQ, with a number of variations depending on
 102     features shipped.
 103
 104   Acer N30
 105
 106     A S3C2410 based PDA from Acer.  There is a Wiki page at
 107     http://handhelds.org/moin/moin.cgi/AcerN30Documentation .
 108
 109   AML M5900
 110
 111     American Microsystems' M5900
 112
 113   Nex Vision Nexcoder
 114   Nex Vision Otom
 115
 116     Two machines by Nex Vision
 117
 118
 119 Adding New Machines
 120 -------------------
 121
 122   The architecture has been designed to support as many machines as can
 123   be configured for it in one kernel build, and any future additions
 124   should keep this in mind before altering items outside of their own
 125   machine files.
 126
 127   Machine definitions should be kept in linux/arch/arm/mach-s3c2410,
 128   and there are a number of examples that can be looked at.
 129
 130   Read the kernel patch submission policies as well as the
 131   Documentation/arm directory before submitting patches. The
 132   ARM kernel series is managed by Russell King, and has a patch system
 133   located at http://www.arm.linux.org.uk/developer/patches/
 134   as well as mailing lists that can be found from the same site.
 135
 136   As a courtesy, please notify <ben-linux@fluff.org> of any new
 137   machines or other modifications.
 138
 139   Any large scale modifications, or new drivers should be discussed
 140   on the ARM kernel mailing list (linux-arm-kernel) before being
 141   attempted. See http://www.arm.linux.org.uk/mailinglists/ for the
 142   mailing list information.
 143
 144
 145 I2C
 146 ---
 147
 148   The hardware I2C core in the CPU is supported in single master
 149   mode, and can be configured via platform data.
 150
 151
 152 RTC
 153 ---
 154
 155   Support for the onboard RTC unit, including alarm function.
 156
 157   This has recently been upgraded to use the new RTC core,
 158   and the module has been renamed to rtc-s3c to fit in with
 159   the new rtc naming scheme.
 160
 161
 162 Watchdog
 163 --------
 164
 165   The onchip watchdog is available via the standard watchdog
 166   interface.
 167
 168
 169 NAND
 170 ----
 171
 172   The current kernels now have support for the s3c2410 NAND
 173   controller. If there are any problems the latest linux-mtd
 174   code can be found from http://www.linux-mtd.infradead.org/
 175
 176   For more information see Documentation/arm/Samsung-S3C24XX/NAND.txt
 177
 178
 179 SD/MMC
 180 ------
 181
 182   The SD/MMC hardware pre S3C2443 is supported in the current
 183   kernel, the driver is drivers/mmc/host/s3cmci.c and supports
 184   1 and 4 bit SD or MMC cards.
 185
 186   The SDIO behaviour of this driver has not been fully tested. There is no
 187   current support for hardware SDIO interrupts.
 188
 189
 190 Serial
 191 ------
 192
 193   The s3c2410 serial driver provides support for the internal
 194   serial ports. These devices appear as /dev/ttySAC0 through 3.
 195
 196   To create device nodes for these, use the following commands
 197
 198     mknod ttySAC0 c 204 64
 199     mknod ttySAC1 c 204 65
 200     mknod ttySAC2 c 204 66
 201
 202
 203 GPIO
 204 ----
 205
 206   The core contains support for manipulating the GPIO, see the
 207   documentation in GPIO.txt in the same directory as this file.
 208
 209   Newer kernels carry GPIOLIB, and support is being moved towards
 210   this with some of the older support in line to be removed.
 211
 212
 213 Clock Management
 214 ----------------
 215
 216   The core provides the interface defined in the header file
 217   include/asm-arm/hardware/clock.h, to allow control over the
 218   various clock units
 219
 220
 221 Suspend to RAM
 222 --------------
 223
 224   For boards that provide support for suspend to RAM, the
 225   system can be placed into low power suspend.
 226
 227   See Suspend.txt for more information.
 228
 229
 230 SPI
 231 ---
 232
 233   SPI drivers are available for both the in-built hardware
 234   (although there is no DMA support yet) and a generic
 235   GPIO based solution.
 236
 237
 238 LEDs
 239 ----
 240
 241   There is support for GPIO based LEDs via a platform driver
 242   in the LED subsystem.
 243
 244
 245 Platform Data
 246 -------------
 247
 248   Whenever a device has platform specific data that is specified
 249   on a per-machine basis, care should be taken to ensure the
 250   following:
 251
 252     1) that default data is not left in the device to confuse the
 253        driver if a machine does not set it at startup
 254
 255     2) the data should (if possible) be marked as __initdata,
 256        to ensure that the data is thrown away if the machine is
 257        not the one currently in use.
 258
 259        The best way of doing this is to make a function that
 260        kmalloc()s an area of memory, and copies the __initdata
 261        and then sets the relevant device's platform data. Making
 262        the function `__init` takes care of ensuring it is discarded
 263        with the rest of the initialisation code
 264
 265        static __init void s3c24xx_xxx_set_platdata(struct xxx_data *pd)
 266        {
 267            struct s3c2410_xxx_mach_info *npd;
 268
 269            npd = kmalloc(sizeof(struct s3c2410_xxx_mach_info), GFP_KERNEL);
 270            if (npd) {
 271               memcpy(npd, pd, sizeof(struct s3c2410_xxx_mach_info));
 272               s3c_device_xxx.dev.platform_data = npd;
 273            } else {
 274               printk(KERN_ERR "no memory for xxx platform data\n");
 275            }
 276         }
 277
 278         Note, since the code is marked as __init, it should not be
 279         exported outside arch/arm/mach-s3c2410/, or exported to
 280         modules via EXPORT_SYMBOL() and related functions.
 281
 282
 283 Port Contributors
 284 -----------------
 285
 286   Ben Dooks (BJD)
 287   Vincent Sanders
 288   Herbert Potzl
 289   Arnaud Patard (RTP)
 290   Roc Wu
 291   Klaus Fetscher
 292   Dimitry Andric
 293   Shannon Holland
 294   Guillaume Gourat (NexVision)
 295   Christer Weinigel (wingel) (Acer N30)
 296   Lucas Correia Villa Real (S3C2400 port)
 297
 298
 299 Document Author
 300 ---------------
 301
 302 Ben Dooks, (c) 2004-2005,2006 Simtec Electronics