bkgpl/cyb4_linux
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Creation of Cybook 2416 (actually Gen4) repository

Browse Source
This commit is contained in:
mlt
2009-12-18 17:10:00 +00:00
committed by godzil
commit 76f20f4d40
13791 changed files with 6812321 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

172
Documentation/mips/AU1xxx_IDE.README Normal file
View File

@@ -0,0 +1,172 @@
README for MIPS AU1XXX IDE driver - Released 2005-07-15
ABOUT
-----
This file describes the 'drivers/ide/mips/au1xxx-ide.c', related files and the
services they provide.
If you are short in patience and just want to know how to add your hard disc to
the white or black list, go to the 'ADD NEW HARD DISC TO WHITE OR BLACK LIST'
section.
LICENSE
-------
Copyright (c) 2003-2005 AMD, Personal Connectivity Solutions
This program is free software; you can redistribute it and/or modify it under
the terms of the GNU General Public License as published by the Free Software
Foundation; either version 2 of the License, or (at your option) any later
version.
THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR
BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.
You should have received a copy of the GNU General Public License along with
this program; if not, write to the Free Software Foundation, Inc.,
675 Mass Ave, Cambridge, MA 02139, USA.
Note: for more information, please refer "AMD Alchemy Au1200/Au1550 IDE
Interface and Linux Device Driver" Application Note.
FILES, CONFIGS AND COMPATABILITY
--------------------------------
Two files are introduced:
a) 'include/asm-mips/mach-au1x00/au1xxx_ide.h'
containes : struct _auide_hwif
struct drive_list_entry dma_white_list
struct drive_list_entry dma_black_list
timing parameters for PIO mode 0/1/2/3/4
timing parameters for MWDMA 0/1/2
b) 'drivers/ide/mips/au1xxx-ide.c'
contains the functionality of the AU1XXX IDE driver
Four configs variables are introduced:
CONFIG_BLK_DEV_IDE_AU1XXX_PIO_DBDMA - enable the PIO+DBDMA mode
CONFIG_BLK_DEV_IDE_AU1XXX_MDMA2_DBDMA - enable the MWDMA mode
CONFIG_BLK_DEV_IDE_AU1XXX_BURSTABLE_ON - set Burstable FIFO in DBDMA
controler
CONFIG_BLK_DEV_IDE_AU1XXX_SEQTS_PER_RQ - maximum transfer size
per descriptor
If MWDMA is enabled and the connected hard disc is not on the white list, the
kernel switches to a "safe mwdma mode" at boot time. In this mode the IDE
performance is substantial slower then in full speed mwdma. In this case
please add your hard disc to the white list (follow instruction from 'ADD NEW
HARD DISC TO WHITE OR BLACK LIST' section).
SUPPORTED IDE MODES
-------------------
The AU1XXX IDE driver supported all PIO modes - PIO mode 0/1/2/3/4 - and all
MWDMA modes - MWDMA 0/1/2 -. There is no support for SWDMA and UDMA mode.
To change the PIO mode use the program hdparm with option -p, e.g.
'hdparm -p0 [device]' for PIO mode 0. To enable the MWDMA mode use the option
-X, e.g. 'hdparm -X32 [device]' for MWDMA mode 0.
PERFORMANCE CONFIGURATIONS
--------------------------
If the used system doesn't need USB support enable the following kernel configs:
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
CONFIG_IDE_GENERIC=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_BLK_DEV_GENERIC=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_IDE_AU1XXX=y
CONFIG_BLK_DEV_IDE_AU1XXX_MDMA2_DBDMA=y
CONFIG_BLK_DEV_IDE_AU1XXX_SEQTS_PER_RQ=128
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_IDEDMA_AUTO=y
Also define 'IDE_AU1XXX_BURSTMODE' in 'drivers/ide/mips/au1xxx-ide.c' to enable
the burst support on DBDMA controller.
If the used system need the USB support enable the following kernel configs for
high IDE to USB throughput.
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDE_GENERIC=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_BLK_DEV_GENERIC=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_IDE_AU1XXX=y
CONFIG_BLK_DEV_IDE_AU1XXX_MDMA2_DBDMA=y
CONFIG_BLK_DEV_IDE_AU1XXX_SEQTS_PER_RQ=128
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_IDEDMA_AUTO=y
Also undefine 'IDE_AU1XXX_BURSTMODE' in 'drivers/ide/mips/au1xxx-ide.c' to
disable the burst support on DBDMA controller.
ADD NEW HARD DISC TO WHITE OR BLACK LIST
----------------------------------------
Step 1 : detect the model name of your hard disc
a) connect your hard disc to the AU1XXX
b) boot your kernel and get the hard disc model.
Example boot log:
--snipped--
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx
Au1xxx IDE(builtin) configured for MWDMA2
Probing IDE interface ide0...
hda: Maxtor 6E040L0, ATA DISK drive
ide0 at 0xac800000-0xac800007,0xac8001c0 on irq 64
hda: max request size: 64KiB
hda: 80293248 sectors (41110 MB) w/2048KiB Cache, CHS=65535/16/63, (U)DMA
--snipped--
In this example 'Maxtor 6E040L0'.
Step 2 : edit 'include/asm-mips/mach-au1x00/au1xxx_ide.h'
Add your hard disc to the dma_white_list or dma_black_list structur.
Step 3 : Recompile the kernel
Enable MWDMA support in the kernel configuration. Recompile the kernel and
reboot.
Step 4 : Tests
If you have add a hard disc to the white list, please run some stress tests
for verification.
ACKNOWLEDGMENTS
---------------
These drivers wouldn't have been done without the base of kernel 2.4.x AU1XXX
IDE driver from AMD.
Additional input also from:
Matthias Lenk <matthias.lenk@amd.com>
Happy hacking!
Enrico Walther <enrico.walther@amd.com>

65
Documentation/mips/GT64120.README Normal file
View File

@@ -0,0 +1,65 @@
README for arch/mips/gt64120 directory and subdirectories
Jun Sun, jsun@mvista.com or jsun@junsun.net
01/27, 2001
MOTIVATION
----------
Many MIPS boards share the same system controller (or CPU companian chip),
such as GT-64120. It is highly desirable to let these boards share
the same controller code instead of duplicating them.
This directory is meant to hold all MIPS boards that use GT-64120 or GT-64120A.
HOW TO ADD A BOARD
------------------
. Create a subdirectory include/asm/gt64120/<board>.
. Create a file called gt64120_dep.h under that directory.
. Modify include/asm/gt64120/gt64120.h file to include the new gt64120_dep.h
based on config options. The board-dep section is at the end of
include/asm/gt64120/gt64120.h file. There you can find all required
definitions include/asm/gt64120/<board>/gt64120_dep.h file must supply.
. Create a subdirectory arch/mips/gt64120/<board> directory to hold
board specific routines.
. The GT-64120 common code is supplied under arch/mips/gt64120/common directory.
It includes:
1) arch/mips/gt64120/pci.c -
common PCI routine, include the top-level pcibios_init()
2) arch/mips/gt64120/irq.c -
common IRQ routine, include the top-level do_IRQ()
[This part really belongs to arch/mips/kernel. jsun]
3) arch/mips/gt64120/gt_irq.c -
common IRQ routines for GT-64120 chip. Currently it only handles
the timer interrupt.
. Board-specific routines are supplied under arch/mips/gt64120/<board> dir.
1) arch/mips/gt64120/<board>/pci.c - it provides bus fixup routine
2) arch/mips/gt64120/<board>/irq.c - it provides enable/disable irqs
and board irq setup routine (irq_setup)
3) arch/mips/gt64120/<board>/int-handler.S -
The first-level interrupt dispatching routine.
4) a bunch of other "normal" stuff (setup, prom, dbg_io, reset, etc)
. Follow other "normal" procedure to modify configuration files, etc.
TO-DO LIST
----------
. Expand arch/mips/gt64120/gt_irq.c to handle all GT-64120 interrupts.
We probably need to introduce GT_IRQ_BASE in board-dep header file,
which is used the starting irq_nr for all GT irqs.
A function, gt64120_handle_irq(), will be added so that the first-level
irq dispatcher will call this function if it detects an interrupt
from GT-64120.
. More support for GT-64120 PCI features (2nd PCI bus, perhaps)

54
Documentation/mips/pci/pci.README Normal file
View File

@@ -0,0 +1,54 @@
Pete Popov, ppopov@pacbell.net
07/11/2001
This README briefly explains how to use the pci and pci_auto
code in arch/mips/kernel. The code was ported from PowerPC and
modified slightly. It has been tested pretty well on PPC on some
rather complex systems with multiple bridges and devices behind
each bridge. However, at the time this README was written, the
mips port was tested only on boards with a single pci bus and
no P2P bridges. It's very possible that on boards with P2P
bridges some modifications have to be made. The code will
evolve, no doubt, but currently every single mips board
is doing its own pcibios thing and it has become a big
mess. This generic pci code is meant to clean up the mips
pci mess and make it easier to add pci support to new boards.
inside the define for your board in arch/mips/config.in.
For example, the Galileo EV96100 board looks like this:
if [ "$CONFIG_MIPS_EV96100" = "y" ]; then
define_bool CONFIG_PCI y
define_bool CONFIG_MIPS_GT96100 y
define_bool CONFIG_NEW_PCI y
define_bool CONFIG_SWAP_IO_SPACE y
fi
Next, if you want to use the arch/mips/kernel/pci code, which has the
pcibios_init() function, add
define_bool CONFIG_NEW_PCI y
inside the define for your board. Again, the EV96100 example above
show NEW_PCI turned on.
Now you need to add your files to hook in your pci configuration
cycles. Usually you'll need only a couple of files named something
like pci_fixups.c and pci_ops.c. You can copy the templates
provided and fill in the code.
The file pci_ops.c should contain the pci configuration cycles routines.
It also has the mips_pci_channels[] array which contains the descriptors
of each pci controller.
The file pci_fixups.c contains a few routines to do interrupt fixups,
resources fixups, and, if needed, pci bios fixups.
Usually you'll put your pci_fixups.c file in your board specific directory,
since the functions in that file are board specific. The functions in
pci_ops.c, on the other hand, are usually pci controller specific so that
file could be shared among a few different boards using the same
pci controller.

173
Documentation/mips/time.README Normal file
View File

@@ -0,0 +1,173 @@
README for MIPS time services
Jun Sun
jsun@mvista.com or jsun@junsun.net
ABOUT
-----
This file describes the new arch/mips/kernel/time.c, related files and the
services they provide.
If you are short in patience and just want to know how to use time.c for a
new board or convert an existing board, go to the last section.
FILES, COMPATABILITY AND CONFIGS
---------------------------------
The old arch/mips/kernel/time.c is renamed to old-time.c.
A new time.c is put there, together with include/asm-mips/time.h.
Two configs variables are introduced, CONFIG_OLD_TIME_C and CONFIG_NEW_TIME_C.
So we allow boards using
1) old time.c (CONFIG_OLD_TIME_C)
2) new time.c (CONFIG_NEW_TIME_C)
3) neither (their own private time.c)
However, it is expected every board will move to the new time.c in the near
future.
WHAT THE NEW CODE PROVIDES?
---------------------------
The new time code provide the following services:
a) Implements functions required by Linux common code:
time_init
b) provides an abstraction of RTC and null RTC implementation as default.
extern unsigned long (*rtc_get_time)(void);
extern int (*rtc_set_time)(unsigned long);
c) high-level and low-level timer interrupt routines where the timer
interrupt source may or may not be the CPU timer. The high-level
routine is dispatched through do_IRQ() while the low-level is
dispatched in assemably code (usually int-handler.S)
WHAT THE NEW CODE REQUIRES?
---------------------------
For the new code to work properly, each board implementation needs to supply
the following functions or values:
a) board_time_init - a function pointer. Invoked at the beginnig of
time_init(). It is optional.
1. (optional) set up RTC routines
2. (optional) calibrate and set the mips_hpt_frequency
b) plat_timer_setup - a function pointer. Invoked at the end of time_init()
1. (optional) over-ride any decisions made in time_init()
2. set up the irqaction for timer interrupt.
3. enable the timer interrupt
c) (optional) board-specific RTC routines.
d) (optional) mips_hpt_frequency - It must be definied if the board
is using CPU counter for timer interrupt.
PORTING GUIDE
-------------
Step 1: decide how you like to implement the time services.
a) does this board have a RTC? If yes, implement the two RTC funcs.
b) does the CPU have counter/compare registers?
If the answer is no, you need a timer to provide the timer interrupt
at 100 HZ speed.
c) The following sub steps assume your CPU has counter register.
Do you plan to use the CPU counter register as the timer interrupt
or use an exnternal timer?
In order to use CPU counter register as the timer interrupt source, you
must know the counter speed (mips_hpt_frequency). It is usually the
same as the CPU speed or an integral divisor of it.
d) decide on whether you want to use high-level or low-level timer
interrupt routines. The low-level one is presumably faster, but should
not make too mcuh difference.
Step 2: the machine setup() function
If you supply board_time_init(), set the function poointer.
Step 3: implement rtc routines, board_time_init() and plat_timer_setup()
if needed.
board_time_init() -
a) (optional) set up RTC routines,
b) (optional) calibrate and set the mips_hpt_frequency
(only needed if you intended to use cpu counter as timer interrupt
source)
plat_timer_setup() -
a) (optional) over-write any choices made above by time_init().
b) machine specific code should setup the timer irqaction.
c) enable the timer interrupt
If the RTC chip is a common chip, I suggest the routines are put under
arch/mips/libs. For example, for DS1386 chip, one would create
rtc-ds1386.c under arch/mips/lib directory. Add the following line to
the arch/mips/lib/Makefile:
obj-$(CONFIG_DDB5476) += rtc-ds1386.o
Step 4: if you are using low-level timer interrupt, change your interrupt
dispathcing code to check for timer interrupt and jump to
ll_timer_interrupt() directly if one is detected.
Step 5: Modify arch/mips/config.in and add CONFIG_NEW_TIME_C to your machine.
Modify the appropriate defconfig if applicable.
Final notes:
For some tricky cases, you may need to add your own wrapper functions
for some of the functions in time.c.
For example, you may define your own timer interrupt routine, which does
some of its own processing and then calls timer_interrupt().
You can also over-ride any of the built-in functions (RTC routines
and/or timer interrupt routine).
PORTING NOTES FOR SMP
----------------------
If you have a SMP box, things are slightly more complicated.
The time service running every jiffy is logically divided into two parts:
1) the one for the whole system (defined in timer_interrupt())
2) the one that should run for each CPU (defined in local_timer_interrupt())
You need to decide on your timer interrupt sources.
case 1) - whole system has only one timer interrupt delivered to one CPU
In this case, you set up timer interrupt as in UP systems. In addtion,
you need to set emulate_local_timer_interrupt to 1 so that other
CPUs get to call local_timer_interrupt().
THIS IS CURRENTLY NOT IMPLEMNETED. However, it is rather easy to write
one should such a need arise. You simply make a IPI call.
case 2) - each CPU has a separate timer interrupt
In this case, you need to set up IRQ such that each of them will
call local_timer_interrupt(). In addition, you need to arrange
one and only one of them to call timer_interrupt().
You can also do the low-level version of those interrupt routines,
following similar dispatching routes described above.