Initial commit

This commit is contained in:
Ole André Vadla Ravnås 2022-05-07 01:01:45 +02:00
commit 169c65d57e
51358 changed files with 23120455 additions and 0 deletions

View 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

View 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

View 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

View 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

View 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

View 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

View 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

View 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

View 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

View 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

View 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

View 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