Initial commit
This commit is contained in:
commit
169c65d57e
51358 changed files with 23120455 additions and 0 deletions
75
Documentation/arm/Samsung-S3C24XX/CPUfreq.txt
Normal file
75
Documentation/arm/Samsung-S3C24XX/CPUfreq.txt
Normal file
|
@ -0,0 +1,75 @@
|
|||
S3C24XX CPUfreq support
|
||||
=======================
|
||||
|
||||
Introduction
|
||||
------------
|
||||
|
||||
The S3C24XX series support a number of power saving systems, such as
|
||||
the ability to change the core, memory and peripheral operating
|
||||
frequencies. The core control is exported via the CPUFreq driver
|
||||
which has a number of different manual or automatic controls over the
|
||||
rate the core is running at.
|
||||
|
||||
There are two forms of the driver depending on the specific CPU and
|
||||
how the clocks are arranged. The first implementation used as single
|
||||
PLL to feed the ARM, memory and peripherals via a series of dividers
|
||||
and muxes and this is the implementation that is documented here. A
|
||||
newer version where there is a separate PLL and clock divider for the
|
||||
ARM core is available as a separate driver.
|
||||
|
||||
|
||||
Layout
|
||||
------
|
||||
|
||||
The code core manages the CPU specific drivers, any data that they
|
||||
need to register and the interface to the generic drivers/cpufreq
|
||||
system. Each CPU registers a driver to control the PLL, clock dividers
|
||||
and anything else associated with it. Any board that wants to use this
|
||||
framework needs to supply at least basic details of what is required.
|
||||
|
||||
The core registers with drivers/cpufreq at init time if all the data
|
||||
necessary has been supplied.
|
||||
|
||||
|
||||
CPU support
|
||||
-----------
|
||||
|
||||
The support for each CPU depends on the facilities provided by the
|
||||
SoC and the driver as each device has different PLL and clock chains
|
||||
associated with it.
|
||||
|
||||
|
||||
Slow Mode
|
||||
---------
|
||||
|
||||
The SLOW mode where the PLL is turned off altogether and the
|
||||
system is fed by the external crystal input is currently not
|
||||
supported.
|
||||
|
||||
|
||||
sysfs
|
||||
-----
|
||||
|
||||
The core code exports extra information via sysfs in the directory
|
||||
devices/system/cpu/cpu0/arch-freq.
|
||||
|
||||
|
||||
Board Support
|
||||
-------------
|
||||
|
||||
Each board that wants to use the cpufreq code must register some basic
|
||||
information with the core driver to provide information about what the
|
||||
board requires and any restrictions being placed on it.
|
||||
|
||||
The board needs to supply information about whether it needs the IO bank
|
||||
timings changing, any maximum frequency limits and information about the
|
||||
SDRAM refresh rate.
|
||||
|
||||
|
||||
|
||||
|
||||
Document Author
|
||||
---------------
|
||||
|
||||
Ben Dooks, Copyright 2009 Simtec Electronics
|
||||
Licensed under GPLv2
|
46
Documentation/arm/Samsung-S3C24XX/DMA.txt
Normal file
46
Documentation/arm/Samsung-S3C24XX/DMA.txt
Normal file
|
@ -0,0 +1,46 @@
|
|||
S3C2410 DMA
|
||||
===========
|
||||
|
||||
Introduction
|
||||
------------
|
||||
|
||||
The kernel provides an interface to manage DMA transfers
|
||||
using the DMA channels in the CPU, so that the central
|
||||
duty of managing channel mappings, and programming the
|
||||
channel generators is in one place.
|
||||
|
||||
|
||||
DMA Channel Ordering
|
||||
--------------------
|
||||
|
||||
Many of the range do not have connections for the DMA
|
||||
channels to all sources, which means that some devices
|
||||
have a restricted number of channels that can be used.
|
||||
|
||||
To allow flexibility for each CPU type and board, the
|
||||
DMA code can be given a DMA ordering structure which
|
||||
allows the order of channel search to be specified, as
|
||||
well as allowing the prohibition of certain claims.
|
||||
|
||||
struct s3c24xx_dma_order has a list of channels, and
|
||||
each channel within has a slot for a list of DMA
|
||||
channel numbers. The slots are searched in order for
|
||||
the presence of a DMA channel number with DMA_CH_VALID
|
||||
or-ed in.
|
||||
|
||||
If the order has the flag DMA_CH_NEVER set, then after
|
||||
checking the channel list, the system will return no
|
||||
found channel, thus denying the request.
|
||||
|
||||
A board support file can call s3c24xx_dma_order_set()
|
||||
to register a complete ordering set. The routine will
|
||||
copy the data, so the original can be discarded with
|
||||
__initdata.
|
||||
|
||||
|
||||
Authour
|
||||
-------
|
||||
|
||||
Ben Dooks,
|
||||
Copyright (c) 2007 Ben Dooks, Simtec Electronics
|
||||
Licensed under the GPL v2
|
58
Documentation/arm/Samsung-S3C24XX/EB2410ITX.txt
Normal file
58
Documentation/arm/Samsung-S3C24XX/EB2410ITX.txt
Normal file
|
@ -0,0 +1,58 @@
|
|||
Simtec Electronics EB2410ITX (BAST)
|
||||
===================================
|
||||
|
||||
http://www.simtec.co.uk/products/EB2410ITX/
|
||||
|
||||
Introduction
|
||||
------------
|
||||
|
||||
The EB2410ITX is a S3C2410 based development board with a variety of
|
||||
peripherals and expansion connectors. This board is also known by
|
||||
the shortened name of Bast.
|
||||
|
||||
|
||||
Configuration
|
||||
-------------
|
||||
|
||||
To set the default configuration, use `make bast_defconfig` which
|
||||
supports the commonly used features of this board.
|
||||
|
||||
|
||||
Support
|
||||
-------
|
||||
|
||||
Official support information can be found on the Simtec Electronics
|
||||
website, at the product page http://www.simtec.co.uk/products/EB2410ITX/
|
||||
|
||||
Useful links:
|
||||
|
||||
- Resources Page http://www.simtec.co.uk/products/EB2410ITX/resources.html
|
||||
|
||||
- Board FAQ at http://www.simtec.co.uk/products/EB2410ITX/faq.html
|
||||
|
||||
- Bootloader info http://www.simtec.co.uk/products/SWABLE/resources.html
|
||||
and FAQ http://www.simtec.co.uk/products/SWABLE/faq.html
|
||||
|
||||
|
||||
MTD
|
||||
---
|
||||
|
||||
The NAND and NOR support has been merged from the linux-mtd project.
|
||||
Any problems, see http://www.linux-mtd.infradead.org/ for more
|
||||
information or up-to-date versions of linux-mtd.
|
||||
|
||||
|
||||
IDE
|
||||
---
|
||||
|
||||
Both onboard IDE ports are supported, however there is no support for
|
||||
changing speed of devices, PIO Mode 4 capable drives should be used.
|
||||
|
||||
|
||||
Maintainers
|
||||
-----------
|
||||
|
||||
This board is maintained by Simtec Electronics.
|
||||
|
||||
|
||||
Copyright 2004 Ben Dooks, Simtec Electronics
|
182
Documentation/arm/Samsung-S3C24XX/GPIO.txt
Normal file
182
Documentation/arm/Samsung-S3C24XX/GPIO.txt
Normal file
|
@ -0,0 +1,182 @@
|
|||
S3C24XX GPIO Control
|
||||
====================
|
||||
|
||||
Introduction
|
||||
------------
|
||||
|
||||
The s3c2410 kernel provides an interface to configure and
|
||||
manipulate the state of the GPIO pins, and find out other
|
||||
information about them.
|
||||
|
||||
There are a number of conditions attached to the configuration
|
||||
of the s3c2410 GPIO system, please read the Samsung provided
|
||||
data-sheet/users manual to find out the complete list.
|
||||
|
||||
See Documentation/arm/Samsung/GPIO.txt for the core implementation.
|
||||
|
||||
|
||||
GPIOLIB
|
||||
-------
|
||||
|
||||
With the event of the GPIOLIB in drivers/gpio, support for some
|
||||
of the GPIO functions such as reading and writing a pin will
|
||||
be removed in favour of this common access method.
|
||||
|
||||
Once all the extant drivers have been converted, the functions
|
||||
listed below will be removed (they may be marked as __deprecated
|
||||
in the near future).
|
||||
|
||||
The following functions now either have a s3c_ specific variant
|
||||
or are merged into gpiolib. See the definitions in
|
||||
arch/arm/plat-samsung/include/plat/gpio-cfg.h:
|
||||
|
||||
s3c2410_gpio_setpin() gpio_set_value() or gpio_direction_output()
|
||||
s3c2410_gpio_getpin() gpio_get_value() or gpio_direction_input()
|
||||
s3c2410_gpio_getirq() gpio_to_irq()
|
||||
s3c2410_gpio_cfgpin() s3c_gpio_cfgpin()
|
||||
s3c2410_gpio_getcfg() s3c_gpio_getcfg()
|
||||
s3c2410_gpio_pullup() s3c_gpio_setpull()
|
||||
|
||||
|
||||
GPIOLIB conversion
|
||||
------------------
|
||||
|
||||
If you need to convert your board or driver to use gpiolib from the phased
|
||||
out s3c2410 API, then here are some notes on the process.
|
||||
|
||||
1) If your board is exclusively using an GPIO, say to control peripheral
|
||||
power, then it will require to claim the gpio with gpio_request() before
|
||||
it can use it.
|
||||
|
||||
It is recommended to check the return value, with at least WARN_ON()
|
||||
during initialisation.
|
||||
|
||||
2) The s3c2410_gpio_cfgpin() can be directly replaced with s3c_gpio_cfgpin()
|
||||
as they have the same arguments, and can either take the pin specific
|
||||
values, or the more generic special-function-number arguments.
|
||||
|
||||
3) s3c2410_gpio_pullup() changes have the problem that whilst the
|
||||
s3c2410_gpio_pullup(x, 1) can be easily translated to the
|
||||
s3c_gpio_setpull(x, S3C_GPIO_PULL_NONE), the s3c2410_gpio_pullup(x, 0)
|
||||
are not so easy.
|
||||
|
||||
The s3c2410_gpio_pullup(x, 0) case enables the pull-up (or in the case
|
||||
of some of the devices, a pull-down) and as such the new API distinguishes
|
||||
between the UP and DOWN case. There is currently no 'just turn on' setting
|
||||
which may be required if this becomes a problem.
|
||||
|
||||
4) s3c2410_gpio_setpin() can be replaced by gpio_set_value(), the old call
|
||||
does not implicitly configure the relevant gpio to output. The gpio
|
||||
direction should be changed before using gpio_set_value().
|
||||
|
||||
5) s3c2410_gpio_getpin() is replaceable by gpio_get_value() if the pin
|
||||
has been set to input. It is currently unknown what the behaviour is
|
||||
when using gpio_get_value() on an output pin (s3c2410_gpio_getpin
|
||||
would return the value the pin is supposed to be outputting).
|
||||
|
||||
6) s3c2410_gpio_getirq() should be directly replaceable with the
|
||||
gpio_to_irq() call.
|
||||
|
||||
The s3c2410_gpio and gpio_ calls have always operated on the same gpio
|
||||
numberspace, so there is no problem with converting the gpio numbering
|
||||
between the calls.
|
||||
|
||||
|
||||
Headers
|
||||
-------
|
||||
|
||||
See arch/arm/mach-s3c2410/include/mach/regs-gpio.h for the list
|
||||
of GPIO pins, and the configuration values for them. This
|
||||
is included by using #include <mach/regs-gpio.h>
|
||||
|
||||
The GPIO management functions are defined in the hardware
|
||||
header arch/arm/mach-s3c2410/include/mach/hardware.h which can be
|
||||
included by #include <mach/hardware.h>
|
||||
|
||||
A useful amount of documentation can be found in the hardware
|
||||
header on how the GPIO functions (and others) work.
|
||||
|
||||
Whilst a number of these functions do make some checks on what
|
||||
is passed to them, for speed of use, they may not always ensure
|
||||
that the user supplied data to them is correct.
|
||||
|
||||
|
||||
PIN Numbers
|
||||
-----------
|
||||
|
||||
Each pin has an unique number associated with it in regs-gpio.h,
|
||||
e.g. S3C2410_GPA(0) or S3C2410_GPF(1). These defines are used to tell
|
||||
the GPIO functions which pin is to be used.
|
||||
|
||||
With the conversion to gpiolib, there is no longer a direct conversion
|
||||
from gpio pin number to register base address as in earlier kernels. This
|
||||
is due to the number space required for newer SoCs where the later
|
||||
GPIOs are not contiguous.
|
||||
|
||||
|
||||
Configuring a pin
|
||||
-----------------
|
||||
|
||||
The following function allows the configuration of a given pin to
|
||||
be changed.
|
||||
|
||||
void s3c_gpio_cfgpin(unsigned int pin, unsigned int function);
|
||||
|
||||
e.g.:
|
||||
|
||||
s3c_gpio_cfgpin(S3C2410_GPA(0), S3C_GPIO_SFN(1));
|
||||
s3c_gpio_cfgpin(S3C2410_GPE(8), S3C_GPIO_SFN(2));
|
||||
|
||||
which would turn GPA(0) into the lowest Address line A0, and set
|
||||
GPE(8) to be connected to the SDIO/MMC controller's SDDAT1 line.
|
||||
|
||||
|
||||
Reading the current configuration
|
||||
---------------------------------
|
||||
|
||||
The current configuration of a pin can be read by using standard
|
||||
gpiolib function:
|
||||
|
||||
s3c_gpio_getcfg(unsigned int pin);
|
||||
|
||||
The return value will be from the same set of values which can be
|
||||
passed to s3c_gpio_cfgpin().
|
||||
|
||||
|
||||
Configuring a pull-up resistor
|
||||
------------------------------
|
||||
|
||||
A large proportion of the GPIO pins on the S3C2410 can have weak
|
||||
pull-up resistors enabled. This can be configured by the following
|
||||
function:
|
||||
|
||||
void s3c_gpio_setpull(unsigned int pin, unsigned int to);
|
||||
|
||||
Where the to value is S3C_GPIO_PULL_NONE to set the pull-up off,
|
||||
and S3C_GPIO_PULL_UP to enable the specified pull-up. Any other
|
||||
values are currently undefined.
|
||||
|
||||
|
||||
Getting and setting the state of a PIN
|
||||
--------------------------------------
|
||||
|
||||
These calls are now implemented by the relevant gpiolib calls, convert
|
||||
your board or driver to use gpiolib.
|
||||
|
||||
|
||||
Getting the IRQ number associated with a PIN
|
||||
--------------------------------------------
|
||||
|
||||
A standard gpiolib function can map the given pin number to an IRQ
|
||||
number to pass to the IRQ system.
|
||||
|
||||
int gpio_to_irq(unsigned int pin);
|
||||
|
||||
Note, not all pins have an IRQ.
|
||||
|
||||
|
||||
Author
|
||||
-------
|
||||
|
||||
Ben Dooks, 03 October 2004
|
||||
Copyright 2004 Ben Dooks, Simtec Electronics
|
40
Documentation/arm/Samsung-S3C24XX/H1940.txt
Normal file
40
Documentation/arm/Samsung-S3C24XX/H1940.txt
Normal file
|
@ -0,0 +1,40 @@
|
|||
HP IPAQ H1940
|
||||
=============
|
||||
|
||||
http://www.handhelds.org/projects/h1940.html
|
||||
|
||||
Introduction
|
||||
------------
|
||||
|
||||
The HP H1940 is a S3C2410 based handheld device, with
|
||||
bluetooth connectivity.
|
||||
|
||||
|
||||
Support
|
||||
-------
|
||||
|
||||
A variety of information is available
|
||||
|
||||
handhelds.org project page:
|
||||
|
||||
http://www.handhelds.org/projects/h1940.html
|
||||
|
||||
handhelds.org wiki page:
|
||||
|
||||
http://handhelds.org/moin/moin.cgi/HpIpaqH1940
|
||||
|
||||
Herbert Pötzl pages:
|
||||
|
||||
http://vserver.13thfloor.at/H1940/
|
||||
|
||||
|
||||
Maintainers
|
||||
-----------
|
||||
|
||||
This project is being maintained and developed by a variety
|
||||
of people, including Ben Dooks, Arnaud Patard, and Herbert Pötzl.
|
||||
|
||||
Thanks to the many others who have also provided support.
|
||||
|
||||
|
||||
(c) 2005 Ben Dooks
|
30
Documentation/arm/Samsung-S3C24XX/NAND.txt
Normal file
30
Documentation/arm/Samsung-S3C24XX/NAND.txt
Normal file
|
@ -0,0 +1,30 @@
|
|||
S3C24XX NAND Support
|
||||
====================
|
||||
|
||||
Introduction
|
||||
------------
|
||||
|
||||
Small Page NAND
|
||||
---------------
|
||||
|
||||
The driver uses a 512 byte (1 page) ECC code for this setup. The
|
||||
ECC code is not directly compatible with the default kernel ECC
|
||||
code, so the driver enforces its own OOB layout and ECC parameters
|
||||
|
||||
Large Page NAND
|
||||
---------------
|
||||
|
||||
The driver is capable of handling NAND flash with a 2KiB page
|
||||
size, with support for hardware ECC generation and correction.
|
||||
|
||||
Unlike the 512byte page mode, the driver generates ECC data for
|
||||
each 256 byte block in an 2KiB page. This means that more than
|
||||
one error in a page can be rectified. It also means that the
|
||||
OOB layout remains the default kernel layout for these flashes.
|
||||
|
||||
|
||||
Document Author
|
||||
---------------
|
||||
|
||||
Ben Dooks, Copyright 2007 Simtec Electronics
|
||||
|
318
Documentation/arm/Samsung-S3C24XX/Overview.txt
Normal file
318
Documentation/arm/Samsung-S3C24XX/Overview.txt
Normal file
|
@ -0,0 +1,318 @@
|
|||
S3C24XX ARM Linux Overview
|
||||
==========================
|
||||
|
||||
|
||||
|
||||
Introduction
|
||||
------------
|
||||
|
||||
The Samsung S3C24XX range of ARM9 System-on-Chip CPUs are supported
|
||||
by the 's3c2410' architecture of ARM Linux. Currently the S3C2410,
|
||||
S3C2412, S3C2413, S3C2416, S3C2440, S3C2442, S3C2443 and S3C2450 devices
|
||||
are supported.
|
||||
|
||||
Support for the S3C2400 and S3C24A0 series was never completed and the
|
||||
corresponding code has been removed after a while. If someone wishes to
|
||||
revive this effort, partial support can be retrieved from earlier Linux
|
||||
versions.
|
||||
|
||||
The S3C2416 and S3C2450 devices are very similar and S3C2450 support is
|
||||
included under the arch/arm/mach-s3c2416 directory. Note, whilst core
|
||||
support for these SoCs is in, work on some of the extra peripherals
|
||||
and extra interrupts is still ongoing.
|
||||
|
||||
|
||||
Configuration
|
||||
-------------
|
||||
|
||||
A generic S3C2410 configuration is provided, and can be used as the
|
||||
default by `make s3c2410_defconfig`. This configuration has support
|
||||
for all the machines, and the commonly used features on them.
|
||||
|
||||
Certain machines may have their own default configurations as well,
|
||||
please check the machine specific documentation.
|
||||
|
||||
|
||||
Layout
|
||||
------
|
||||
|
||||
The core support files are located in the platform code contained in
|
||||
arch/arm/plat-s3c24xx with headers in include/asm-arm/plat-s3c24xx.
|
||||
This directory should be kept to items shared between the platform
|
||||
code (arch/arm/plat-s3c24xx) and the arch/arm/mach-s3c24* code.
|
||||
|
||||
Each cpu has a directory with the support files for it, and the
|
||||
machines that carry the device. For example S3C2410 is contained
|
||||
in arch/arm/mach-s3c2410 and S3C2440 in arch/arm/mach-s3c2440
|
||||
|
||||
Register, kernel and platform data definitions are held in the
|
||||
arch/arm/mach-s3c2410 directory./include/mach
|
||||
|
||||
arch/arm/plat-s3c24xx:
|
||||
|
||||
Files in here are either common to all the s3c24xx family,
|
||||
or are common to only some of them with names to indicate this
|
||||
status. The files that are not common to all are generally named
|
||||
with the initial cpu they support in the series to ensure a short
|
||||
name without any possibility of confusion with newer devices.
|
||||
|
||||
As an example, initially s3c244x would cover s3c2440 and s3c2442, but
|
||||
with the s3c2443 which does not share many of the same drivers in
|
||||
this directory, the name becomes invalid. We stick to s3c2440-<x>
|
||||
to indicate a driver that is s3c2440 and s3c2442 compatible.
|
||||
|
||||
This does mean that to find the status of any given SoC, a number
|
||||
of directories may need to be searched.
|
||||
|
||||
|
||||
Machines
|
||||
--------
|
||||
|
||||
The currently supported machines are as follows:
|
||||
|
||||
Simtec Electronics EB2410ITX (BAST)
|
||||
|
||||
A general purpose development board, see EB2410ITX.txt for further
|
||||
details
|
||||
|
||||
Simtec Electronics IM2440D20 (Osiris)
|
||||
|
||||
CPU Module from Simtec Electronics, with a S3C2440A CPU, nand flash
|
||||
and a PCMCIA controller.
|
||||
|
||||
Samsung SMDK2410
|
||||
|
||||
Samsung's own development board, geared for PDA work.
|
||||
|
||||
Samsung/Aiji SMDK2412
|
||||
|
||||
The S3C2412 version of the SMDK2440.
|
||||
|
||||
Samsung/Aiji SMDK2413
|
||||
|
||||
The S3C2412 version of the SMDK2440.
|
||||
|
||||
Samsung/Meritech SMDK2440
|
||||
|
||||
The S3C2440 compatible version of the SMDK2440, which has the
|
||||
option of an S3C2440 or S3C2442 CPU module.
|
||||
|
||||
Thorcom VR1000
|
||||
|
||||
Custom embedded board
|
||||
|
||||
HP IPAQ 1940
|
||||
|
||||
Handheld (IPAQ), available in several varieties
|
||||
|
||||
HP iPAQ rx3715
|
||||
|
||||
S3C2440 based IPAQ, with a number of variations depending on
|
||||
features shipped.
|
||||
|
||||
Acer N30
|
||||
|
||||
A S3C2410 based PDA from Acer. There is a Wiki page at
|
||||
http://handhelds.org/moin/moin.cgi/AcerN30Documentation .
|
||||
|
||||
AML M5900
|
||||
|
||||
American Microsystems' M5900
|
||||
|
||||
Nex Vision Nexcoder
|
||||
Nex Vision Otom
|
||||
|
||||
Two machines by Nex Vision
|
||||
|
||||
|
||||
Adding New Machines
|
||||
-------------------
|
||||
|
||||
The architecture has been designed to support as many machines as can
|
||||
be configured for it in one kernel build, and any future additions
|
||||
should keep this in mind before altering items outside of their own
|
||||
machine files.
|
||||
|
||||
Machine definitions should be kept in linux/arch/arm/mach-s3c2410,
|
||||
and there are a number of examples that can be looked at.
|
||||
|
||||
Read the kernel patch submission policies as well as the
|
||||
Documentation/arm directory before submitting patches. The
|
||||
ARM kernel series is managed by Russell King, and has a patch system
|
||||
located at http://www.arm.linux.org.uk/developer/patches/
|
||||
as well as mailing lists that can be found from the same site.
|
||||
|
||||
As a courtesy, please notify <ben-linux@fluff.org> of any new
|
||||
machines or other modifications.
|
||||
|
||||
Any large scale modifications, or new drivers should be discussed
|
||||
on the ARM kernel mailing list (linux-arm-kernel) before being
|
||||
attempted. See http://www.arm.linux.org.uk/mailinglists/ for the
|
||||
mailing list information.
|
||||
|
||||
|
||||
I2C
|
||||
---
|
||||
|
||||
The hardware I2C core in the CPU is supported in single master
|
||||
mode, and can be configured via platform data.
|
||||
|
||||
|
||||
RTC
|
||||
---
|
||||
|
||||
Support for the onboard RTC unit, including alarm function.
|
||||
|
||||
This has recently been upgraded to use the new RTC core,
|
||||
and the module has been renamed to rtc-s3c to fit in with
|
||||
the new rtc naming scheme.
|
||||
|
||||
|
||||
Watchdog
|
||||
--------
|
||||
|
||||
The onchip watchdog is available via the standard watchdog
|
||||
interface.
|
||||
|
||||
|
||||
NAND
|
||||
----
|
||||
|
||||
The current kernels now have support for the s3c2410 NAND
|
||||
controller. If there are any problems the latest linux-mtd
|
||||
code can be found from http://www.linux-mtd.infradead.org/
|
||||
|
||||
For more information see Documentation/arm/Samsung-S3C24XX/NAND.txt
|
||||
|
||||
|
||||
SD/MMC
|
||||
------
|
||||
|
||||
The SD/MMC hardware pre S3C2443 is supported in the current
|
||||
kernel, the driver is drivers/mmc/host/s3cmci.c and supports
|
||||
1 and 4 bit SD or MMC cards.
|
||||
|
||||
The SDIO behaviour of this driver has not been fully tested. There is no
|
||||
current support for hardware SDIO interrupts.
|
||||
|
||||
|
||||
Serial
|
||||
------
|
||||
|
||||
The s3c2410 serial driver provides support for the internal
|
||||
serial ports. These devices appear as /dev/ttySAC0 through 3.
|
||||
|
||||
To create device nodes for these, use the following commands
|
||||
|
||||
mknod ttySAC0 c 204 64
|
||||
mknod ttySAC1 c 204 65
|
||||
mknod ttySAC2 c 204 66
|
||||
|
||||
|
||||
GPIO
|
||||
----
|
||||
|
||||
The core contains support for manipulating the GPIO, see the
|
||||
documentation in GPIO.txt in the same directory as this file.
|
||||
|
||||
Newer kernels carry GPIOLIB, and support is being moved towards
|
||||
this with some of the older support in line to be removed.
|
||||
|
||||
As of v2.6.34, the move towards using gpiolib support is almost
|
||||
complete, and very little of the old calls are left.
|
||||
|
||||
See Documentation/arm/Samsung-S3C24XX/GPIO.txt for the S3C24XX specific
|
||||
support and Documentation/arm/Samsung/GPIO.txt for the core Samsung
|
||||
implementation.
|
||||
|
||||
|
||||
Clock Management
|
||||
----------------
|
||||
|
||||
The core provides the interface defined in the header file
|
||||
include/asm-arm/hardware/clock.h, to allow control over the
|
||||
various clock units
|
||||
|
||||
|
||||
Suspend to RAM
|
||||
--------------
|
||||
|
||||
For boards that provide support for suspend to RAM, the
|
||||
system can be placed into low power suspend.
|
||||
|
||||
See Suspend.txt for more information.
|
||||
|
||||
|
||||
SPI
|
||||
---
|
||||
|
||||
SPI drivers are available for both the in-built hardware
|
||||
(although there is no DMA support yet) and a generic
|
||||
GPIO based solution.
|
||||
|
||||
|
||||
LEDs
|
||||
----
|
||||
|
||||
There is support for GPIO based LEDs via a platform driver
|
||||
in the LED subsystem.
|
||||
|
||||
|
||||
Platform Data
|
||||
-------------
|
||||
|
||||
Whenever a device has platform specific data that is specified
|
||||
on a per-machine basis, care should be taken to ensure the
|
||||
following:
|
||||
|
||||
1) that default data is not left in the device to confuse the
|
||||
driver if a machine does not set it at startup
|
||||
|
||||
2) the data should (if possible) be marked as __initdata,
|
||||
to ensure that the data is thrown away if the machine is
|
||||
not the one currently in use.
|
||||
|
||||
The best way of doing this is to make a function that
|
||||
kmalloc()s an area of memory, and copies the __initdata
|
||||
and then sets the relevant device's platform data. Making
|
||||
the function `__init` takes care of ensuring it is discarded
|
||||
with the rest of the initialisation code
|
||||
|
||||
static __init void s3c24xx_xxx_set_platdata(struct xxx_data *pd)
|
||||
{
|
||||
struct s3c2410_xxx_mach_info *npd;
|
||||
|
||||
npd = kmalloc(sizeof(struct s3c2410_xxx_mach_info), GFP_KERNEL);
|
||||
if (npd) {
|
||||
memcpy(npd, pd, sizeof(struct s3c2410_xxx_mach_info));
|
||||
s3c_device_xxx.dev.platform_data = npd;
|
||||
} else {
|
||||
printk(KERN_ERR "no memory for xxx platform data\n");
|
||||
}
|
||||
}
|
||||
|
||||
Note, since the code is marked as __init, it should not be
|
||||
exported outside arch/arm/mach-s3c2410/, or exported to
|
||||
modules via EXPORT_SYMBOL() and related functions.
|
||||
|
||||
|
||||
Port Contributors
|
||||
-----------------
|
||||
|
||||
Ben Dooks (BJD)
|
||||
Vincent Sanders
|
||||
Herbert Potzl
|
||||
Arnaud Patard (RTP)
|
||||
Roc Wu
|
||||
Klaus Fetscher
|
||||
Dimitry Andric
|
||||
Shannon Holland
|
||||
Guillaume Gourat (NexVision)
|
||||
Christer Weinigel (wingel) (Acer N30)
|
||||
Lucas Correia Villa Real (S3C2400 port)
|
||||
|
||||
|
||||
Document Author
|
||||
---------------
|
||||
|
||||
Ben Dooks, Copyright 2004-2006 Simtec Electronics
|
120
Documentation/arm/Samsung-S3C24XX/S3C2412.txt
Normal file
120
Documentation/arm/Samsung-S3C24XX/S3C2412.txt
Normal file
|
@ -0,0 +1,120 @@
|
|||
S3C2412 ARM Linux Overview
|
||||
==========================
|
||||
|
||||
Introduction
|
||||
------------
|
||||
|
||||
The S3C2412 is part of the S3C24XX range of ARM9 System-on-Chip CPUs
|
||||
from Samsung. This part has an ARM926-EJS core, capable of running up
|
||||
to 266MHz (see data-sheet for more information)
|
||||
|
||||
|
||||
Clock
|
||||
-----
|
||||
|
||||
The core clock code provides a set of clocks to the drivers, and allows
|
||||
for source selection and a number of other features.
|
||||
|
||||
|
||||
Power
|
||||
-----
|
||||
|
||||
No support for suspend/resume to RAM in the current system.
|
||||
|
||||
|
||||
DMA
|
||||
---
|
||||
|
||||
No current support for DMA.
|
||||
|
||||
|
||||
GPIO
|
||||
----
|
||||
|
||||
There is support for setting the GPIO to input/output/special function
|
||||
and reading or writing to them.
|
||||
|
||||
|
||||
UART
|
||||
----
|
||||
|
||||
The UART hardware is similar to the S3C2440, and is supported by the
|
||||
s3c2410 driver in the drivers/serial directory.
|
||||
|
||||
|
||||
NAND
|
||||
----
|
||||
|
||||
The NAND hardware is similar to the S3C2440, and is supported by the
|
||||
s3c2410 driver in the drivers/mtd/nand directory.
|
||||
|
||||
|
||||
USB Host
|
||||
--------
|
||||
|
||||
The USB hardware is similar to the S3C2410, with extended clock source
|
||||
control. The OHCI portion is supported by the ohci-s3c2410 driver, and
|
||||
the clock control selection is supported by the core clock code.
|
||||
|
||||
|
||||
USB Device
|
||||
----------
|
||||
|
||||
No current support in the kernel
|
||||
|
||||
|
||||
IRQs
|
||||
----
|
||||
|
||||
All the standard, and external interrupt sources are supported. The
|
||||
extra sub-sources are not yet supported.
|
||||
|
||||
|
||||
RTC
|
||||
---
|
||||
|
||||
The RTC hardware is similar to the S3C2410, and is supported by the
|
||||
s3c2410-rtc driver.
|
||||
|
||||
|
||||
Watchdog
|
||||
--------
|
||||
|
||||
The watchdog hardware is the same as the S3C2410, and is supported by
|
||||
the s3c2410_wdt driver.
|
||||
|
||||
|
||||
MMC/SD/SDIO
|
||||
-----------
|
||||
|
||||
No current support for the MMC/SD/SDIO block.
|
||||
|
||||
IIC
|
||||
---
|
||||
|
||||
The IIC hardware is the same as the S3C2410, and is supported by the
|
||||
i2c-s3c24xx driver.
|
||||
|
||||
|
||||
IIS
|
||||
---
|
||||
|
||||
No current support for the IIS interface.
|
||||
|
||||
|
||||
SPI
|
||||
---
|
||||
|
||||
No current support for the SPI interfaces.
|
||||
|
||||
|
||||
ATA
|
||||
---
|
||||
|
||||
No current support for the on-board ATA block.
|
||||
|
||||
|
||||
Document Author
|
||||
---------------
|
||||
|
||||
Ben Dooks, Copyright 2006 Simtec Electronics
|
21
Documentation/arm/Samsung-S3C24XX/S3C2413.txt
Normal file
21
Documentation/arm/Samsung-S3C24XX/S3C2413.txt
Normal file
|
@ -0,0 +1,21 @@
|
|||
S3C2413 ARM Linux Overview
|
||||
==========================
|
||||
|
||||
Introduction
|
||||
------------
|
||||
|
||||
The S3C2413 is an extended version of the S3C2412, with an camera
|
||||
interface and mobile DDR memory support. See the S3C2412 support
|
||||
documentation for more information.
|
||||
|
||||
|
||||
Camera Interface
|
||||
---------------
|
||||
|
||||
This block is currently not supported.
|
||||
|
||||
|
||||
Document Author
|
||||
---------------
|
||||
|
||||
Ben Dooks, Copyright 2006 Simtec Electronics
|
56
Documentation/arm/Samsung-S3C24XX/SMDK2440.txt
Normal file
56
Documentation/arm/Samsung-S3C24XX/SMDK2440.txt
Normal file
|
@ -0,0 +1,56 @@
|
|||
Samsung/Meritech SMDK2440
|
||||
=========================
|
||||
|
||||
Introduction
|
||||
------------
|
||||
|
||||
The SMDK2440 is a two part evaluation board for the Samsung S3C2440
|
||||
processor. It includes support for LCD, SmartMedia, Audio, SD and
|
||||
10MBit Ethernet, and expansion headers for various signals, including
|
||||
the camera and unused GPIO.
|
||||
|
||||
|
||||
Configuration
|
||||
-------------
|
||||
|
||||
To set the default configuration, use `make smdk2440_defconfig` which
|
||||
will configure the common features of this board, or use
|
||||
`make s3c2410_config` to include support for all s3c2410/s3c2440 machines
|
||||
|
||||
|
||||
Support
|
||||
-------
|
||||
|
||||
Ben Dooks' SMDK2440 site at http://www.fluff.org/ben/smdk2440/ which
|
||||
includes linux based USB download tools.
|
||||
|
||||
Some of the h1940 patches that can be found from the H1940 project
|
||||
site at http://www.handhelds.org/projects/h1940.html can also be
|
||||
applied to this board.
|
||||
|
||||
|
||||
Peripherals
|
||||
-----------
|
||||
|
||||
There is no current support for any of the extra peripherals on the
|
||||
base-board itself.
|
||||
|
||||
|
||||
MTD
|
||||
---
|
||||
|
||||
The NAND flash should be supported by the in kernel MTD NAND support,
|
||||
NOR flash will be added later.
|
||||
|
||||
|
||||
Maintainers
|
||||
-----------
|
||||
|
||||
This board is being maintained by Ben Dooks, for more info, see
|
||||
http://www.fluff.org/ben/smdk2440/
|
||||
|
||||
Many thanks to Dimitry Andric of TomTom for the loan of the SMDK2440,
|
||||
and to Simtec Electronics for allowing me time to work on this.
|
||||
|
||||
|
||||
(c) 2004 Ben Dooks
|
137
Documentation/arm/Samsung-S3C24XX/Suspend.txt
Normal file
137
Documentation/arm/Samsung-S3C24XX/Suspend.txt
Normal file
|
@ -0,0 +1,137 @@
|
|||
S3C24XX Suspend Support
|
||||
=======================
|
||||
|
||||
|
||||
Introduction
|
||||
------------
|
||||
|
||||
The S3C24XX supports a low-power suspend mode, where the SDRAM is kept
|
||||
in Self-Refresh mode, and all but the essential peripheral blocks are
|
||||
powered down. For more information on how this works, please look
|
||||
at the relevant CPU datasheet from Samsung.
|
||||
|
||||
|
||||
Requirements
|
||||
------------
|
||||
|
||||
1) A bootloader that can support the necessary resume operation
|
||||
|
||||
2) Support for at least 1 source for resume
|
||||
|
||||
3) CONFIG_PM enabled in the kernel
|
||||
|
||||
4) Any peripherals that are going to be powered down at the same
|
||||
time require suspend/resume support.
|
||||
|
||||
|
||||
Resuming
|
||||
--------
|
||||
|
||||
The S3C2410 user manual defines the process of sending the CPU to
|
||||
sleep and how it resumes. The default behaviour of the Linux code
|
||||
is to set the GSTATUS3 register to the physical address of the
|
||||
code to resume Linux operation.
|
||||
|
||||
GSTATUS4 is currently left alone by the sleep code, and is free to
|
||||
use for any other purposes (for example, the EB2410ITX uses this to
|
||||
save memory configuration in).
|
||||
|
||||
|
||||
Machine Support
|
||||
---------------
|
||||
|
||||
The machine specific functions must call the s3c_pm_init() function
|
||||
to say that its bootloader is capable of resuming. This can be as
|
||||
simple as adding the following to the machine's definition:
|
||||
|
||||
INITMACHINE(s3c_pm_init)
|
||||
|
||||
A board can do its own setup before calling s3c_pm_init, if it
|
||||
needs to setup anything else for power management support.
|
||||
|
||||
There is currently no support for over-riding the default method of
|
||||
saving the resume address, if your board requires it, then contact
|
||||
the maintainer and discuss what is required.
|
||||
|
||||
Note, the original method of adding an late_initcall() is wrong,
|
||||
and will end up initialising all compiled machines' pm init!
|
||||
|
||||
The following is an example of code used for testing wakeup from
|
||||
an falling edge on IRQ_EINT0:
|
||||
|
||||
|
||||
static irqreturn_t button_irq(int irq, void *pw)
|
||||
{
|
||||
return IRQ_HANDLED;
|
||||
}
|
||||
|
||||
statuc void __init machine_init(void)
|
||||
{
|
||||
...
|
||||
|
||||
request_irq(IRQ_EINT0, button_irq, IRQF_TRIGGER_FALLING,
|
||||
"button-irq-eint0", NULL);
|
||||
|
||||
enable_irq_wake(IRQ_EINT0);
|
||||
|
||||
s3c_pm_init();
|
||||
}
|
||||
|
||||
|
||||
Debugging
|
||||
---------
|
||||
|
||||
There are several important things to remember when using PM suspend:
|
||||
|
||||
1) The uart drivers will disable the clocks to the UART blocks when
|
||||
suspending, which means that use of printascii() or similar direct
|
||||
access to the UARTs will cause the debug to stop.
|
||||
|
||||
2) Whilst the pm code itself will attempt to re-enable the UART clocks,
|
||||
care should be taken that any external clock sources that the UARTs
|
||||
rely on are still enabled at that point.
|
||||
|
||||
3) If any debugging is placed in the resume path, then it must have the
|
||||
relevant clocks and peripherals setup before use (ie, bootloader).
|
||||
|
||||
For example, if you transmit a character from the UART, the baud
|
||||
rate and uart controls must be setup beforehand.
|
||||
|
||||
|
||||
Configuration
|
||||
-------------
|
||||
|
||||
The S3C2410 specific configuration in `System Type` defines various
|
||||
aspects of how the S3C2410 suspend and resume support is configured
|
||||
|
||||
`S3C2410 PM Suspend debug`
|
||||
|
||||
This option prints messages to the serial console before and after
|
||||
the actual suspend, giving detailed information on what is
|
||||
happening
|
||||
|
||||
|
||||
`S3C2410 PM Suspend Memory CRC`
|
||||
|
||||
Allows the entire memory to be checksummed before and after the
|
||||
suspend to see if there has been any corruption of the contents.
|
||||
|
||||
Note, the time to calculate the CRC is dependent on the CPU speed
|
||||
and the size of memory. For an 64Mbyte RAM area on an 200MHz
|
||||
S3C2410, this can take approximately 4 seconds to complete.
|
||||
|
||||
This support requires the CRC32 function to be enabled.
|
||||
|
||||
|
||||
`S3C2410 PM Suspend CRC Chunksize (KiB)`
|
||||
|
||||
Defines the size of memory each CRC chunk covers. A smaller value
|
||||
will mean that the CRC data block will take more memory, but will
|
||||
identify any faults with better precision
|
||||
|
||||
|
||||
Document Author
|
||||
---------------
|
||||
|
||||
Ben Dooks, Copyright 2004 Simtec Electronics
|
||||
|
93
Documentation/arm/Samsung-S3C24XX/USB-Host.txt
Normal file
93
Documentation/arm/Samsung-S3C24XX/USB-Host.txt
Normal file
|
@ -0,0 +1,93 @@
|
|||
S3C24XX USB Host support
|
||||
========================
|
||||
|
||||
|
||||
|
||||
Introduction
|
||||
------------
|
||||
|
||||
This document details the S3C2410/S3C2440 in-built OHCI USB host support.
|
||||
|
||||
Configuration
|
||||
-------------
|
||||
|
||||
Enable at least the following kernel options:
|
||||
|
||||
menuconfig:
|
||||
|
||||
Device Drivers --->
|
||||
USB support --->
|
||||
<*> Support for Host-side USB
|
||||
<*> OHCI HCD support
|
||||
|
||||
|
||||
.config:
|
||||
CONFIG_USB
|
||||
CONFIG_USB_OHCI_HCD
|
||||
|
||||
|
||||
Once these options are configured, the standard set of USB device
|
||||
drivers can be configured and used.
|
||||
|
||||
|
||||
Board Support
|
||||
-------------
|
||||
|
||||
The driver attaches to a platform device, which will need to be
|
||||
added by the board specific support file in linux/arch/arm/mach-s3c2410,
|
||||
such as mach-bast.c or mach-smdk2410.c
|
||||
|
||||
The platform device's platform_data field is only needed if the
|
||||
board implements extra power control or over-current monitoring.
|
||||
|
||||
The OHCI driver does not ensure the state of the S3C2410's MISCCTRL
|
||||
register, so if both ports are to be used for the host, then it is
|
||||
the board support file's responsibility to ensure that the second
|
||||
port is configured to be connected to the OHCI core.
|
||||
|
||||
|
||||
Platform Data
|
||||
-------------
|
||||
|
||||
See arch/arm/mach-s3c2410/include/mach/usb-control.h for the
|
||||
descriptions of the platform device data. An implementation
|
||||
can be found in linux/arch/arm/mach-s3c2410/usb-simtec.c .
|
||||
|
||||
The `struct s3c2410_hcd_info` contains a pair of functions
|
||||
that get called to enable over-current detection, and to
|
||||
control the port power status.
|
||||
|
||||
The ports are numbered 0 and 1.
|
||||
|
||||
power_control:
|
||||
|
||||
Called to enable or disable the power on the port.
|
||||
|
||||
enable_oc:
|
||||
|
||||
Called to enable or disable the over-current monitoring.
|
||||
This should claim or release the resources being used to
|
||||
check the power condition on the port, such as an IRQ.
|
||||
|
||||
report_oc:
|
||||
|
||||
The OHCI driver fills this field in for the over-current code
|
||||
to call when there is a change to the over-current state on
|
||||
an port. The ports argument is a bitmask of 1 bit per port,
|
||||
with bit X being 1 for an over-current on port X.
|
||||
|
||||
The function s3c2410_usb_report_oc() has been provided to
|
||||
ensure this is called correctly.
|
||||
|
||||
port[x]:
|
||||
|
||||
This is struct describes each port, 0 or 1. The platform driver
|
||||
should set the flags field of each port to S3C_HCDFLG_USED if
|
||||
the port is enabled.
|
||||
|
||||
|
||||
|
||||
Document Author
|
||||
---------------
|
||||
|
||||
Ben Dooks, Copyright 2005 Simtec Electronics
|
Loading…
Add table
Add a link
Reference in a new issue