diff options
Diffstat (limited to 'Documentation')
31 files changed, 1246 insertions, 380 deletions
diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile index e69b3d2e788..87da3478fad 100644 --- a/Documentation/DocBook/Makefile +++ b/Documentation/DocBook/Makefile @@ -8,7 +8,7 @@ DOCBOOKS := wanbook.xml z8530book.xml mcabook.xml videobook.xml \ kernel-hacking.xml kernel-locking.xml deviceiobook.xml \ - procfs-guide.xml writing_usb_driver.xml scsidrivers.xml \ + procfs-guide.xml writing_usb_driver.xml \ sis900.xml kernel-api.xml journal-api.xml lsm.xml usb.xml \ gadget.xml libata.xml mtdnand.xml librs.xml diff --git a/Documentation/DocBook/kernel-api.tmpl b/Documentation/DocBook/kernel-api.tmpl index 757cef8f849..bb6a0106be1 100644 --- a/Documentation/DocBook/kernel-api.tmpl +++ b/Documentation/DocBook/kernel-api.tmpl @@ -338,7 +338,6 @@ X!Earch/i386/kernel/mca.c X!Iinclude/linux/device.h --> !Edrivers/base/driver.c -!Edrivers/base/class_simple.c !Edrivers/base/core.c !Edrivers/base/firmware_class.c !Edrivers/base/transport_class.c diff --git a/Documentation/DocBook/libata.tmpl b/Documentation/DocBook/libata.tmpl index cf2fce7707d..6df1dfd18b6 100644 --- a/Documentation/DocBook/libata.tmpl +++ b/Documentation/DocBook/libata.tmpl @@ -14,7 +14,7 @@ </authorgroup> <copyright> - <year>2003</year> + <year>2003-2005</year> <holder>Jeff Garzik</holder> </copyright> @@ -44,30 +44,38 @@ <toc></toc> - <chapter id="libataThanks"> - <title>Thanks</title> + <chapter id="libataIntroduction"> + <title>Introduction</title> <para> - The bulk of the ATA knowledge comes thanks to long conversations with - Andre Hedrick (www.linux-ide.org). + libATA is a library used inside the Linux kernel to support ATA host + controllers and devices. libATA provides an ATA driver API, class + transports for ATA and ATAPI devices, and SCSI<->ATA translation + for ATA devices according to the T10 SAT specification. </para> <para> - Thanks to Alan Cox for pointing out similarities - between SATA and SCSI, and in general for motivation to hack on - libata. - </para> - <para> - libata's device detection - method, ata_pio_devchk, and in general all the early probing was - based on extensive study of Hale Landis's probe/reset code in his - ATADRVR driver (www.ata-atapi.com). + This Guide documents the libATA driver API, library functions, library + internals, and a couple sample ATA low-level drivers. </para> </chapter> <chapter id="libataDriverApi"> <title>libata Driver API</title> + <para> + struct ata_port_operations is defined for every low-level libata + hardware driver, and it controls how the low-level driver + interfaces with the ATA and SCSI layers. + </para> + <para> + FIS-based drivers will hook into the system with ->qc_prep() and + ->qc_issue() high-level hooks. Hardware which behaves in a manner + similar to PCI IDE hardware may utilize several generic helpers, + defining at a bare minimum the bus I/O addresses of the ATA shadow + register blocks. + </para> <sect1> <title>struct ata_port_operations</title> + <sect2><title>Disable ATA port</title> <programlisting> void (*port_disable) (struct ata_port *); </programlisting> @@ -78,6 +86,9 @@ void (*port_disable) (struct ata_port *); unplug). </para> + </sect2> + + <sect2><title>Post-IDENTIFY device configuration</title> <programlisting> void (*dev_config) (struct ata_port *, struct ata_device *); </programlisting> @@ -88,6 +99,9 @@ void (*dev_config) (struct ata_port *, struct ata_device *); issue of SET FEATURES - XFER MODE, and prior to operation. </para> + </sect2> + + <sect2><title>Set PIO/DMA mode</title> <programlisting> void (*set_piomode) (struct ata_port *, struct ata_device *); void (*set_dmamode) (struct ata_port *, struct ata_device *); @@ -108,6 +122,9 @@ void (*post_set_mode) (struct ata_port *ap); ->set_dma_mode() is only called if DMA is possible. </para> + </sect2> + + <sect2><title>Taskfile read/write</title> <programlisting> void (*tf_load) (struct ata_port *ap, struct ata_taskfile *tf); void (*tf_read) (struct ata_port *ap, struct ata_taskfile *tf); @@ -120,6 +137,9 @@ void (*tf_read) (struct ata_port *ap, struct ata_taskfile *tf); taskfile register values. </para> + </sect2> + + <sect2><title>ATA command execute</title> <programlisting> void (*exec_command)(struct ata_port *ap, struct ata_taskfile *tf); </programlisting> @@ -129,17 +149,37 @@ void (*exec_command)(struct ata_port *ap, struct ata_taskfile *tf); ->tf_load(), to be initiated in hardware. </para> + </sect2> + + <sect2><title>Per-cmd ATAPI DMA capabilities filter</title> + <programlisting> +int (*check_atapi_dma) (struct ata_queued_cmd *qc); + </programlisting> + + <para> +Allow low-level driver to filter ATA PACKET commands, returning a status +indicating whether or not it is OK to use DMA for the supplied PACKET +command. + </para> + + </sect2> + + <sect2><title>Read specific ATA shadow registers</title> <programlisting> u8 (*check_status)(struct ata_port *ap); -void (*dev_select)(struct ata_port *ap, unsigned int device); +u8 (*check_altstatus)(struct ata_port *ap); +u8 (*check_err)(struct ata_port *ap); </programlisting> <para> - Reads the Status ATA shadow register from hardware. On some - hardware, this has the side effect of clearing the interrupt - condition. + Reads the Status/AltStatus/Error ATA shadow register from + hardware. On some hardware, reading the Status register has + the side effect of clearing the interrupt condition. </para> + </sect2> + + <sect2><title>Select ATA device on bus</title> <programlisting> void (*dev_select)(struct ata_port *ap, unsigned int device); </programlisting> @@ -147,9 +187,13 @@ void (*dev_select)(struct ata_port *ap, unsigned int device); <para> Issues the low-level hardware command(s) that causes one of N hardware devices to be considered 'selected' (active and - available for use) on the ATA bus. + available for use) on the ATA bus. This generally has no +meaning on FIS-based devices. </para> + </sect2> + + <sect2><title>Reset ATA bus</title> <programlisting> void (*phy_reset) (struct ata_port *ap); </programlisting> @@ -162,17 +206,31 @@ void (*phy_reset) (struct ata_port *ap); functions ata_bus_reset() or sata_phy_reset() for this hook. </para> + </sect2> + + <sect2><title>Control PCI IDE BMDMA engine</title> <programlisting> void (*bmdma_setup) (struct ata_queued_cmd *qc); void (*bmdma_start) (struct ata_queued_cmd *qc); +void (*bmdma_stop) (struct ata_port *ap); +u8 (*bmdma_status) (struct ata_port *ap); </programlisting> <para> - When setting up an IDE BMDMA transaction, these hooks arm - (->bmdma_setup) and fire (->bmdma_start) the hardware's DMA - engine. +When setting up an IDE BMDMA transaction, these hooks arm +(->bmdma_setup), fire (->bmdma_start), and halt (->bmdma_stop) +the hardware's DMA engine. ->bmdma_status is used to read the standard +PCI IDE DMA Status register. </para> + <para> +These hooks are typically either no-ops, or simply not implemented, in +FIS-based drivers. + </para> + + </sect2> + + <sect2><title>High-level taskfile hooks</title> <programlisting> void (*qc_prep) (struct ata_queued_cmd *qc); int (*qc_issue) (struct ata_queued_cmd *qc); @@ -190,20 +248,26 @@ int (*qc_issue) (struct ata_queued_cmd *qc); ->qc_issue is used to make a command active, once the hardware and S/G tables have been prepared. IDE BMDMA drivers use the helper function ata_qc_issue_prot() for taskfile protocol-based - dispatch. More advanced drivers roll their own ->qc_issue - implementation, using this as the "issue new ATA command to - hardware" hook. + dispatch. More advanced drivers implement their own ->qc_issue. </para> + </sect2> + + <sect2><title>Timeout (error) handling</title> <programlisting> void (*eng_timeout) (struct ata_port *ap); </programlisting> <para> - This is a high level error handling function, called from the - error handling thread, when a command times out. +This is a high level error handling function, called from the +error handling thread, when a command times out. Most newer +hardware will implement its own error handling code here. IDE BMDMA +drivers may use the helper function ata_eng_timeout(). </para> + </sect2> + + <sect2><title>Hardware interrupt handling</title> <programlisting> irqreturn_t (*irq_handler)(int, void *, struct pt_regs *); void (*irq_clear) (struct ata_port *); @@ -216,6 +280,9 @@ void (*irq_clear) (struct ata_port *); is quiet. </para> + </sect2> + + <sect2><title>SATA phy read/write</title> <programlisting> u32 (*scr_read) (struct ata_port *ap, unsigned int sc_reg); void (*scr_write) (struct ata_port *ap, unsigned int sc_reg, @@ -227,6 +294,9 @@ void (*scr_write) (struct ata_port *ap, unsigned int sc_reg, if ->phy_reset hook called the sata_phy_reset() helper function. </para> + </sect2> + + <sect2><title>Init and shutdown</title> <programlisting> int (*port_start) (struct ata_port *ap); void (*port_stop) (struct ata_port *ap); @@ -240,15 +310,17 @@ void (*host_stop) (struct ata_host_set *host_set); tasks. </para> <para> - ->host_stop() is called when the rmmod or hot unplug process - begins. The hook must stop all hardware interrupts, DMA - engines, etc. - </para> - <para> ->port_stop() is called after ->host_stop(). It's sole function is to release DMA/memory resources, now that they are no longer actively being used. </para> + <para> + ->host_stop() is called after all ->port_stop() calls +have completed. The hook must finalize hardware shutdown, release DMA +and other resources, etc. + </para> + + </sect2> </sect1> </chapter> @@ -279,4 +351,24 @@ void (*host_stop) (struct ata_host_set *host_set); !Idrivers/scsi/sata_sil.c </chapter> + <chapter id="libataThanks"> + <title>Thanks</title> + <para> + The bulk of the ATA knowledge comes thanks to long conversations with + Andre Hedrick (www.linux-ide.org), and long hours pondering the ATA + and SCSI specifications. + </para> + <para> + Thanks to Alan Cox for pointing out similarities + between SATA and SCSI, and in general for motivation to hack on + libata. + </para> + <para> + libata's device detection + method, ata_pio_devchk, and in general all the early probing was + based on extensive study of Hale Landis's probe/reset code in his + ATADRVR driver (www.ata-atapi.com). + </para> + </chapter> + </book> diff --git a/Documentation/DocBook/scsidrivers.tmpl b/Documentation/DocBook/scsidrivers.tmpl deleted file mode 100644 index d058e65daf1..00000000000 --- a/Documentation/DocBook/scsidrivers.tmpl +++ /dev/null @@ -1,193 +0,0 @@ -<?xml version="1.0" encoding="UTF-8"?> -<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" - "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []> - -<book id="scsidrivers"> - <bookinfo> - <title>SCSI Subsystem Interfaces</title> - - <authorgroup> - <author> - <firstname>Douglas</firstname> - <surname>Gilbert</surname> - <affiliation> - <address> - <email>dgilbert@interlog.com</email> - </address> - </affiliation> - </author> - </authorgroup> - <pubdate>2003-08-11</pubdate> - - <copyright> - <year>2002</year> - <year>2003</year> - <holder>Douglas Gilbert</holder> - </copyright> - - <legalnotice> - <para> - This documentation 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. - </para> - - <para> - This program is distributed in the hope that it will be - useful, but WITHOUT ANY WARRANTY; without even the implied - warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. - See the GNU General Public License for more details. - </para> - - <para> - 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., 59 Temple Place, Suite 330, Boston, - MA 02111-1307 USA - </para> - - <para> - For more details see the file COPYING in the source - distribution of Linux. - </para> - </legalnotice> - - </bookinfo> - -<toc></toc> - - <chapter id="intro"> - <title>Introduction</title> - <para> -This document outlines the interface between the Linux scsi mid level -and lower level drivers. Lower level drivers are variously called HBA -(host bus adapter) drivers, host drivers (HD) or pseudo adapter drivers. -The latter alludes to the fact that a lower level driver may be a -bridge to another IO subsystem (and the "ide-scsi" driver is an example -of this). There can be many lower level drivers active in a running -system, but only one per hardware type. For example, the aic7xxx driver -controls adaptec controllers based on the 7xxx chip series. Most lower -level drivers can control one or more scsi hosts (a.k.a. scsi initiators). - </para> -<para> -This document can been found in an ASCII text file in the linux kernel -source: <filename>Documentation/scsi/scsi_mid_low_api.txt</filename> . -It currently hold a little more information than this document. The -<filename>drivers/scsi/hosts.h</filename> and <filename> -drivers/scsi/scsi.h</filename> headers contain descriptions of members -of important structures for the scsi subsystem. -</para> - </chapter> - - <chapter id="driver-struct"> - <title>Driver structure</title> - <para> -Traditionally a lower level driver for the scsi subsystem has been -at least two files in the drivers/scsi directory. For example, a -driver called "xyz" has a header file "xyz.h" and a source file -"xyz.c". [Actually there is no good reason why this couldn't all -be in one file.] Some drivers that have been ported to several operating -systems (e.g. aic7xxx which has separate files for generic and -OS-specific code) have more than two files. Such drivers tend to have -their own directory under the drivers/scsi directory. - </para> - <para> -scsi_module.c is normally included at the end of a lower -level driver. For it to work a declaration like this is needed before -it is included: -<programlisting> - static Scsi_Host_Template driver_template = DRIVER_TEMPLATE; - /* DRIVER_TEMPLATE should contain pointers to supported interface - functions. Scsi_Host_Template is defined hosts.h */ - #include "scsi_module.c" -</programlisting> - </para> - <para> -The scsi_module.c assumes the name "driver_template" is appropriately -defined. It contains 2 functions: -<orderedlist> -<listitem><para> - init_this_scsi_driver() called during builtin and module driver - initialization: invokes mid level's scsi_register_host() -</para></listitem> -<listitem><para> - exit_this_scsi_driver() called during closedown: invokes - mid level's scsi_unregister_host() -</para></listitem> -</orderedlist> - </para> -<para> -When a new, lower level driver is being added to Linux, the following -files (all found in the drivers/scsi directory) will need some attention: -Makefile, Config.help and Config.in . It is probably best to look at what -an existing lower level driver does in this regard. -</para> - </chapter> - - <chapter id="intfunctions"> - <title>Interface Functions</title> -!EDocumentation/scsi/scsi_mid_low_api.txt - </chapter> - - <chapter id="locks"> - <title>Locks</title> -<para> -Each Scsi_Host instance has a spin_lock called Scsi_Host::default_lock -which is initialized in scsi_register() [found in hosts.c]. Within the -same function the Scsi_Host::host_lock pointer is initialized to point -at default_lock with the scsi_assign_lock() function. Thereafter -lock and unlock operations performed by the mid level use the -Scsi_Host::host_lock pointer. -</para> -<para> -Lower level drivers can override the use of Scsi_Host::default_lock by -using scsi_assign_lock(). The earliest opportunity to do this would -be in the detect() function after it has invoked scsi_register(). It -could be replaced by a coarser grain lock (e.g. per driver) or a -lock of equal granularity (i.e. per host). Using finer grain locks -(e.g. per scsi device) may be possible by juggling locks in -queuecommand(). -</para> - </chapter> - - <chapter id="changes"> - <title>Changes since lk 2.4 series</title> -<para> -io_request_lock has been replaced by several finer grained locks. The lock -relevant to lower level drivers is Scsi_Host::host_lock and there is one -per scsi host. -</para> -<para> -The older error handling mechanism has been removed. This means the -lower level interface functions abort() and reset() have been removed. -</para> -<para> -In the 2.4 series the scsi subsystem configuration descriptions were -aggregated with the configuration descriptions from all other Linux -subsystems in the Documentation/Configure.help file. In the 2.5 series, -the scsi subsystem now has its own (much smaller) drivers/scsi/Config.help -file. -</para> - </chapter> - - <chapter id="credits"> - <title>Credits</title> -<para> -The following people have contributed to this document: -<orderedlist> -<listitem><para> -Mike Anderson <email>andmike@us.ibm.com</email> -</para></listitem> -<listitem><para> -James Bottomley <email>James.Bottomley@steeleye.com</email> -</para></listitem> -<listitem><para> -Patrick Mansfield <email>patmans@us.ibm.com</email> -</para></listitem> -</orderedlist> -</para> - </chapter> - -</book> diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index 9838d32b2fe..4d35562b1cf 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -271,7 +271,7 @@ patch, which certifies that you wrote it or otherwise have the right to pass it on as a open-source patch. The rules are pretty simple: if you can certify the below: - Developer's Certificate of Origin 1.0 + Developer's Certificate of Origin 1.1 By making a contribution to this project, I certify that: @@ -291,6 +291,12 @@ can certify the below: person who certified (a), (b) or (c) and I have not modified it. + (d) I understand and agree that this project and the contribution + are public and that a record of the contribution (including all + personal information I submit with it, including my sign-off) is + maintained indefinitely and may be redistributed consistent with + this project or the open source license(s) involved. + then you just add a line saying Signed-off-by: Random J Developer <random@developer.org> diff --git a/Documentation/cpu-freq/cpufreq-stats.txt b/Documentation/cpu-freq/cpufreq-stats.txt new file mode 100644 index 00000000000..e2d1e760b4b --- /dev/null +++ b/Documentation/cpu-freq/cpufreq-stats.txt @@ -0,0 +1,128 @@ + + CPU frequency and voltage scaling statictics in the Linux(TM) kernel + + + L i n u x c p u f r e q - s t a t s d r i v e r + + - information for users - + + + Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> + +Contents +1. Introduction +2. Statistics Provided (with example) +3. Configuring cpufreq-stats + + +1. Introduction + +cpufreq-stats is a driver that provices CPU frequency statistics for each CPU. +This statistics is provided in /sysfs as a bunch of read_only interfaces. This +interface (when configured) will appear in a seperate directory under cpufreq +in /sysfs (<sysfs root>/devices/system/cpu/cpuX/cpufreq/stats/) for each CPU. +Various statistics will form read_only files under this directory. + +This driver is designed to be independent of any particular cpufreq_driver +that may be running on your CPU. So, it will work with any cpufreq_driver. + + +2. Statistics Provided (with example) + +cpufreq stats provides following statistics (explained in detail below). +- time_in_state +- total_trans +- trans_table + +All the statistics will be from the time the stats driver has been inserted +to the time when a read of a particular statistic is done. Obviously, stats +driver will not have any information about the the frequcny transitions before +the stats driver insertion. + +-------------------------------------------------------------------------------- +<mysystem>:/sys/devices/system/cpu/cpu0/cpufreq/stats # ls -l +total 0 +drwxr-xr-x 2 root root 0 May 14 16:06 . +drwxr-xr-x 3 root root 0 May 14 15:58 .. +-r--r--r-- 1 root root 4096 May 14 16:06 time_in_state +-r--r--r-- 1 root root 4096 May 14 16:06 total_trans +-r--r--r-- 1 root root 4096 May 14 16:06 trans_table +-------------------------------------------------------------------------------- + +- time_in_state +This gives the amount of time spent in each of the frequencies supported by +this CPU. The cat output will have "<frequency> <time>" pair in each line, which +will mean this CPU spent <time> usertime units of time at <frequency>. Output +will have one line for each of the supported freuencies. usertime units here +is 10mS (similar to other time exported in /proc). + +-------------------------------------------------------------------------------- +<mysystem>:/sys/devices/system/cpu/cpu0/cpufreq/stats # cat time_in_state +3600000 2089 +3400000 136 +3200000 34 +3000000 67 +2800000 172488 +-------------------------------------------------------------------------------- + + +- total_trans +This gives the total number of frequency transitions on this CPU. The cat +output will have a single count which is the total number of frequency +transitions. + +-------------------------------------------------------------------------------- +<mysystem>:/sys/devices/system/cpu/cpu0/cpufreq/stats # cat total_trans +20 +-------------------------------------------------------------------------------- + +- trans_table +This will give a fine grained information about all the CPU frequency +transitions. The cat output here is a two dimensional matrix, where an entry +<i,j> (row i, column j) represents the count of number of transitions from +Freq_i to Freq_j. Freq_i is in descending order with increasing rows and +Freq_j is in descending order with increasing columns. The output here also +contains the actual freq values for each row and column for better readability. + +-------------------------------------------------------------------------------- +<mysystem>:/sys/devices/system/cpu/cpu0/cpufreq/stats # cat trans_table + From : To + : 3600000 3400000 3200000 3000000 2800000 + 3600000: 0 5 0 0 0 + 3400000: 4 0 2 0 0 + 3200000: 0 1 0 2 0 + 3000000: 0 0 1 0 3 + 2800000: 0 0 0 2 0 +-------------------------------------------------------------------------------- + + +3. Configuring cpufreq-stats + +To configure cpufreq-stats in your kernel +Config Main Menu + Power management options (ACPI, APM) ---> + CPU Frequency scaling ---> + [*] CPU Frequency scaling + <*> CPU frequency translation statistics + [*] CPU frequency translation statistics details + + +"CPU Frequency scaling" (CONFIG_CPU_FREQ) should be enabled to configure +cpufreq-stats. + +"CPU frequency translation statistics" (CONFIG_CPU_FREQ_STAT) provides the +basic statistics which includes time_in_state and total_trans. + +"CPU frequency translation statistics details" (CONFIG_CPU_FREQ_STAT_DETAILS) +provides fine grained cpufreq stats by trans_table. The reason for having a +seperate config option for trans_table is: +- trans_table goes against the traditional /sysfs rule of one value per + interface. It provides a whole bunch of value in a 2 dimensional matrix + form. + +Once these two options are enabled and your CPU supports cpufrequency, you +will be able to see the CPU frequency statistics in /sysfs. + + + + diff --git a/Documentation/cpusets.txt b/Documentation/cpusets.txt index 1ad26d2c20a..2f8f24eaefd 100644 --- a/Documentation/cpusets.txt +++ b/Documentation/cpusets.txt @@ -252,8 +252,7 @@ in a tasks processor placement. There is an exception to the above. If hotplug funtionality is used to remove all the CPUs that are currently assigned to a cpuset, then the kernel will automatically update the cpus_allowed of all -tasks attached to CPUs in that cpuset with the online CPUs of the -nearest parent cpuset that still has some CPUs online. When memory +tasks attached to CPUs in that cpuset to allow all CPUs. When memory hotplug functionality for removing Memory Nodes is available, a similar exception is expected to apply there as well. In general, the kernel prefers to violate cpuset placement, over starving a task diff --git a/Documentation/driver-model/device.txt b/Documentation/driver-model/device.txt index 58cc5dc8fd3..a05ec50f800 100644 --- a/Documentation/driver-model/device.txt +++ b/Documentation/driver-model/device.txt @@ -76,6 +76,14 @@ driver_data: Driver-specific data. platform_data: Platform data specific to the device. + Example: for devices on custom boards, as typical of embedded + and SOC based hardware, Linux often uses platform_data to point + to board-specific structures describing devices and how they + are wired. That can include what ports are available, chip + variants, which GPIO pins act in what additional roles, and so + on. This shrinks the "Board Support Packages" (BSPs) and + minimizes board-specific #ifdefs in drivers. + current_state: Current power state of the device. saved_state: Pointer to saved state of the device. This is usable by diff --git a/Documentation/driver-model/driver.txt b/Documentation/driver-model/driver.txt index 6031a68dd3f..fabaca1ab1b 100644 --- a/Documentation/driver-model/driver.txt +++ b/Documentation/driver-model/driver.txt @@ -5,21 +5,17 @@ struct device_driver { char * name; struct bus_type * bus; - rwlock_t lock; - atomic_t refcount; - - list_t bus_list; + struct completion unloaded; + struct kobject kobj; list_t devices; - struct driver_dir_entry dir; + struct module *owner; int (*probe) (struct device * dev); int (*remove) (struct device * dev); int (*suspend) (struct device * dev, pm_message_t state, u32 level); int (*resume) (struct device * dev, u32 level); - - void (*release) (struct device_driver * drv); }; @@ -51,7 +47,6 @@ being converted completely to the new model. static struct device_driver eepro100_driver = { .name = "eepro100", .bus = &pci_bus_type, - .devclass = ðernet_devclass, /* when it's implemented */ .probe = eepro100_probe, .remove = eepro100_remove, @@ -85,7 +80,6 @@ static struct pci_driver eepro100_driver = { .driver = { .name = "eepro100", .bus = &pci_bus_type, - .devclass = ðernet_devclass, /* when it's implemented */ .probe = eepro100_probe, .remove = eepro100_remove, .suspend = eepro100_suspend, @@ -166,27 +160,32 @@ Callbacks int (*probe) (struct device * dev); -probe is called to verify the existence of a certain type of -hardware. This is called during the driver binding process, after the -bus has verified that the device ID of a device matches one of the -device IDs supported by the driver. - -This callback only verifies that there actually is supported hardware -present. It may allocate a driver-specific structure, but it should -not do any initialization of the hardware itself. The device-specific -structure may be stored in the device's driver_data field. - - int (*init) (struct device * dev); - -init is called during the binding stage. It is called after probe has -successfully returned and the device has been registered with its -class. It is responsible for initializing the hardware. +The probe() entry is called in task context, with the bus's rwsem locked +and the driver partially bound to the device. Drivers commonly use +container_of() to convert "dev" to a bus-specific type, both in probe() +and other routines. That type often provides device resource data, such +as pci_dev.resource[] or platform_device.resources, which is used in +addition to dev->platform_data to initialize the driver. + +This callback holds the driver-specific logic to bind the driver to a +given device. That includes verifying that the device is present, that +it's a version the driver can handle, that driver data structures can +be allocated and initialized, and that any hardware can be initialized. +Drivers often store a pointer to their state with dev_set_drvdata(). +When the driver has successfully bound itself to that device, then probe() +returns zero and the driver model code will finish its part of binding +the driver to that device. + +A driver's probe() may return a negative errno value to indicate that +the driver did not bind to this device, in which case it should have +released all reasources it allocated. int (*remove) (struct device * dev); -remove is called to dissociate a driver with a device. This may be +remove is called to unbind a driver from a device. This may be called if a device is physically removed from the system, if the -driver module is being unloaded, or during a reboot sequence. +driver module is being unloaded, during a reboot sequence, or +in other cases. It is up to the driver to determine if the device is present or not. It should free any resources allocated specifically for the diff --git a/Documentation/dvb/README.flexcop b/Documentation/dvb/README.flexcop new file mode 100644 index 00000000000..a50c70f9ca7 --- /dev/null +++ b/Documentation/dvb/README.flexcop @@ -0,0 +1,205 @@ +This README escorted the skystar2-driver rewriting procedure. It describes the +state of the new flexcop-driver set and some internals are written down here +too. + +This document hopefully describes things about the flexcop and its +device-offsprings. Goal was to write an easy-to-write and easy-to-read set of +drivers based on the skystar2.c and other information. + +Remark: flexcop-pci.c was a copy of skystar2.c, but every line has been +touched and rewritten. + +History & News +============== + 2005-04-01 - correct USB ISOC transfers (thanks to Vadim Catana) + + + + +General coding processing +========================= + +We should proceed as follows (as long as no one complains): + +0) Think before start writing code! + +1) rewriting the skystar2.c with the help of the flexcop register descriptions +and splitting up the files to a pci-bus-part and a flexcop-part. +The new driver will be called b2c2-flexcop-pci.ko/b2c2-flexcop-usb.ko for the +device-specific part and b2c2-flexcop.ko for the common flexcop-functions. + +2) Search for errors in the leftover of flexcop-pci.c (compare with pluto2.c +and other pci drivers) + +3) make some beautification (see 'Improvements when rewriting (refactoring) is +done') + +4) Testing the new driver and maybe substitute the skystar2.c with it, to reach +a wider tester audience. + +5) creating an usb-bus-part using the already written flexcop code for the pci +card. + +Idea: create a kernel-object for the flexcop and export all important +functions. This option saves kernel-memory, but maybe a lot of functions have +to be exported to kernel namespace. + + +Current situation +================= + +0) Done :) +1) Done (some minor issues left) +2) Done +3) Not ready yet, more information is necessary +4) next to be done (see the table below) +5) USB driver is working (yes, there are some minor issues) + +What seems to be ready? +----------------------- + +1) Rewriting +1a) i2c is cut off from the flexcop-pci.c and seems to work +1b) moved tuner and demod stuff from flexcop-pci.c to flexcop-tuner-fe.c +1c) moved lnb and diseqc stuff from flexcop-pci.c to flexcop-tuner-fe.c +1e) eeprom (reading MAC address) +1d) sram (no dynamic sll size detection (commented out) (using default as JJ told me)) +1f) misc. register accesses for reading parameters (e.g. resetting, revision) +1g) pid/mac filter (flexcop-hw-filter.c) +1i) dvb-stuff initialization in flexcop.c (done) +1h) dma stuff (now just using the size-irq, instead of all-together, to be done) +1j) remove flexcop initialization from flexcop-pci.c completely (done) +1l) use a well working dma IRQ method (done, see 'Known bugs and problems and TODO') +1k) cleanup flexcop-files (remove unused EXPORT_SYMBOLs, make static from +non-static where possible, moved code to proper places) + +2) Search for errors in the leftover of flexcop-pci.c (partially done) +5a) add MAC address reading +5c) feeding of ISOC data to the software demux (format of the isochronous data +and speed optimization, no real error) (thanks to Vadim Catana) + +What to do in the near future? +-------------------------------------- +(no special order here) + +5) USB driver +5b) optimize isoc-transfer (submitting/killing isoc URBs when transfer is starting) + +Testing changes +--------------- + +O = item is working +P = item is partially working +X = item is not working +N = item does not apply here +<empty field> = item need to be examined + + | PCI | USB +item | mt352 | nxt2002 | stv0299 | mt312 | mt352 | nxt2002 | stv0299 | mt312 +-------+-------+---------+---------+-------+-------+---------+---------+------- +1a) | O | | | | N | N | N | N +1b) | O | | | | | | O | +1c) | N | N | | | N | N | O | +1d) | O | O +1e) | O | O +1f) | P +1g) | O +1h) | P | +1i) | O | N +1j) | O | N +1l) | O | N +2) | O | N +5a) | N | O +5b)* | N | +5c) | N | O + +* - not done yet + +Known bugs and problems and TODO +-------------------------------- + +1g/h/l) when pid filtering is enabled on the pci card + +DMA usage currently: + The DMA is splitted in 2 equal-sized subbuffers. The Flexcop writes to first + address and triggers an IRQ when it's full and starts writing to the second + address. When the second address is full, the IRQ is triggered again, and + the flexcop writes to first address again, and so on. + The buffersize of each address is currently 640*188 bytes. + + Problem is, when using hw-pid-filtering and doing some low-bandwidth + operation (like scanning) the buffers won't be filled enough to trigger + the IRQ. That's why: + + When PID filtering is activated, the timer IRQ is used. Every 1.97 ms the IRQ + is triggered. Is the current write address of DMA1 different to the one + during the last IRQ, then the data is passed to the demuxer. + + There is an additional DMA-IRQ-method: packet count IRQ. This isn't + implemented correctly yet. + + The solution is to disable HW PID filtering, but I don't know how the DVB + API software demux behaves on slow systems with 45MBit/s TS. + +Solved bugs :) +-------------- +1g) pid-filtering (somehow pid index 4 and 5 (EMM_PID and ECM_PID) aren't +working) +SOLUTION: also index 0 was affected, because net_translation is done for +these indexes by default + +5b) isochronous transfer does only work in the first attempt (for the Sky2PC +USB, Air2PC is working) SOLUTION: the flexcop was going asleep and never really +woke up again (don't know if this need fixes, see +flexcop-fe-tuner.c:flexcop_sleep) + +NEWS: when the driver is loaded and unloaded and loaded again (w/o doing +anything in the while the driver is loaded the first time), no transfers take +place anymore. + +Improvements when rewriting (refactoring) is done +================================================= + +- split sleeping of the flexcop (misc_204.ACPI3_sig = 1;) from lnb_control + (enable sleeping for other demods than dvb-s) +- add support for CableStar (stv0297 Microtune 203x/ALPS) (almost done, incompatibilities with the Nexus-CA) + +Debugging +--------- +- add verbose debugging to skystar2.c (dump the reg_dw_data) and compare it + with this flexcop, this is important, because i2c is now using the + flexcop_ibi_value union from flexcop-reg.h (do you have a better idea for + that, please tell us so). + +Everything which is identical in the following table, can be put into a common +flexcop-module. + + PCI USB +------------------------------------------------------------------------------- +Different: +Register access: accessing IO memory USB control message +I2C bus: I2C bus of the FC USB control message +Data transfer: DMA isochronous transfer +EEPROM transfer: through i2c bus not clear yet + +Identical: +Streaming: accessing registers +PID Filtering: accessing registers +Sram destinations: accessing registers +Tuner/Demod: I2C bus +DVB-stuff: can be written for common use + +Acknowledgements (just for the rewriting part) +================ + +Bjarne Steinsbo thought a lot in the first place of the pci part for this code +sharing idea. + +Andreas Oberritter for providing a recent PCI initialization template +(pluto2.c). + +Boleslaw Ciesielski for pointing out a problem with firmware loader. + +Vadim Catana for correcting the USB transfer. + +comments, critics and ideas to linux-dvb@linuxtv.org. diff --git a/Documentation/dvb/bt8xx.txt b/Documentation/dvb/bt8xx.txt index e3cacf4f234..d64430bf4bb 100644 --- a/Documentation/dvb/bt8xx.txt +++ b/Documentation/dvb/bt8xx.txt @@ -17,74 +17,53 @@ Because of this, you need to enable "Device drivers" => "Multimedia devices" => "Video For Linux" => "BT848 Video For Linux" +Furthermore you need to enable +"Device drivers" => "Multimedia devices" => "Digital Video Broadcasting Devices" + => "DVB for Linux" "DVB Core Support" "Nebula/Pinnacle PCTV/TwinHan PCI Cards" + 2) Loading Modules ================== In general you need to load the bttv driver, which will handle the gpio and -i2c communication for us. Next you need the common dvb-bt8xx device driver -and one frontend driver. - -The bttv driver will HANG YOUR SYSTEM IF YOU DO NOT SPECIFY THE CORRECT -CARD ID! - -(If you don't get your card running and you suspect that the card id you're -using is wrong, have a look at "bttv-cards.c" for a list of possible card -ids.) - -Pay attention to failures when you load the frontend drivers -(e.g. dmesg, /var/log/messages). +i2c communication for us, plus the common dvb-bt8xx device driver. +The frontends for Nebula (nxt6000), Pinnacle PCTV (cx24110) and +TwinHan (dst) are loaded automatically by the dvb-bt8xx device driver. 3a) Nebula / Pinnacle PCTV -------------------------- - $ modprobe bttv i2c_hw=1 card=0x68 - $ modprobe dvb-bt8xx - -For Nebula cards use the "nxt6000" frontend driver: - $ modprobe nxt6000 + $ modprobe bttv (normally bttv is being loaded automatically by kmod) + $ modprobe dvb-bt8xx (or just place dvb-bt8xx in /etc/modules for automatic loading) -For Pinnacle PCTV cards use the "cx24110" frontend driver: - $ modprobe cx24110 -3b) TwinHan ------------ +3b) TwinHan and Clones +-------------------------- $ modprobe bttv i2c_hw=1 card=0x71 $ modprobe dvb-bt8xx $ modprobe dst -The value 0x71 will override the PCI type detection for dvb-bt8xx, which -is necessary for TwinHan cards.# +The value 0x71 will override the PCI type detection for dvb-bt8xx, +which is necessary for TwinHan cards. -If you're having an older card (blue color circuit) and card=0x71 locks your -machine, try using 0x68, too. If that does not work, ask on the DVB mailing list. +If you're having an older card (blue color circuit) and card=0x71 locks +your machine, try using 0x68, too. If that does not work, ask on the +mailing list. -The DST module takes a couple of useful parameters, in case the -dst drivers fails to detect your type of card correctly. +The DST module takes a couple of useful parameters. -dst_type takes values 0 (satellite), 1 (terrestial TV), 2 (cable). +verbose takes values 0 to 5. These values control the verbosity level. -dst_type_flags takes bit combined values: -1 = new tuner type packets. You can use this if your card is detected - and you have debug and you continually see the tuner packets not - working (make sure not a basic problem like dish alignment etc.) +debug takes values 0 and 1. You can either disable or enable debugging. -2 = TS 204. If your card tunes OK, but the picture is terrible, seemingly - breaking up in one half continually, and crc fails a lot, then - this is worth a try (or trying to turn off) +dst_addons takes values 0 and 0x20. A value of 0 means it is a FTA card. +0x20 means it has a Conditional Access slot. -4 = has symdiv. Some cards, mostly without new tuner packets, require - a symbol division algorithm. Doesn't apply to terrestial TV. - -You can also specify a value to have the autodetected values turned off -(e.g. 0). The autodected values are determined bythe cards 'response +The autodected values are determined bythe cards 'response string' which you can see in your logs e.g. -dst_check_ci: recognize DST-MOT - -or +dst_get_device_id: Recognise [DSTMCI] -dst_check_ci: unable to recognize DSTXCI or STXCI -- -Authors: Richard Walker, Jamie Honan, Michael Hunold +Authors: Richard Walker, Jamie Honan, Michael Hunold, Manu Abraham diff --git a/Documentation/dvb/ci.txt b/Documentation/dvb/ci.txt new file mode 100644 index 00000000000..62e0701b542 --- /dev/null +++ b/Documentation/dvb/ci.txt @@ -0,0 +1,219 @@ +* For the user +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +NOTE: This document describes the usage of the high level CI API as +in accordance to the Linux DVB API. This is a not a documentation for the, +existing low level CI API. +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +To utilize the High Level CI capabilities, + +(1*) This point is valid only for the Twinhan/clones + For the Twinhan/Twinhan clones, the dst_ca module handles the CI + hardware handling.This module is loaded automatically if a CI + (Common Interface, that holds the CAM (Conditional Access Module) + is detected. + +(2) one requires a userspace application, ca_zap. This small userland + application is in charge of sending the descrambling related information + to the CAM. + +This application requires the following to function properly as of now. + + (a) Tune to a valid channel, with szap. + eg: $ szap -c channels.conf -r "TMC" -x + + (b) a channels.conf containing a valid PMT PID + + eg: TMC:11996:h:0:27500:278:512:650:321 + + here 278 is a valid PMT PID. the rest of the values are the + same ones that szap uses. + + (c) after running a szap, you have to run ca_zap, for the + descrambler to function, + + eg: $ ca_zap patched_channels.conf "TMC" + + The patched means a patch to apply to scan, such that scan can + generate a channels.conf_with pmt, which has this PMT PID info + (NOTE: szap cannot use this channels.conf with the PMT_PID) + + + (d) Hopeflly Enjoy your favourite subscribed channel as you do with + a FTA card. + +(3) Currently ca_zap, and dst_test, both are meant for demonstration + purposes only, they can become full fledged applications if necessary. + + +* Cards that fall in this category +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +At present the cards that fall in this category are the Twinhan and it's +clones, these cards are available as VVMER, Tomato, Hercules, Orange and +so on. + +* CI modules that are supported +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +The CI module support is largely dependant upon the firmware on the cards +Some cards do support almost all of the available CI modules. There is +nothing much that can be done in order to make additional CI modules +working with these cards. + +Modules that have been tested by this driver at present are + +(1) Irdeto 1 and 2 from SCM +(2) Viaccess from SCM +(3) Dragoncam + +* The High level CI API +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* For the programmer +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +With the High Level CI approach any new card with almost any random +architecture can be implemented with this style, the definitions +insidethe switch statement can be easily adapted for any card, thereby +eliminating the need for any additional ioctls. + +The disadvantage is that the driver/hardware has to manage the rest. For +the application programmer it would be as simple as sending/receiving an +array to/from the CI ioctls as defined in the Linux DVB API. No changes +have been made in the API to accomodate this feature. + + +* Why the need for another CI interface ? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +This is one of the most commonly asked question. Well a nice question. +Strictly speaking this is not a new interface. + +The CI interface is defined in the DVB API in ca.h as + +typedef struct ca_slot_info { + int num; /* slot number */ + + int type; /* CA interface this slot supports */ +#define CA_CI 1 /* CI high level interface */ +#define CA_CI_LINK 2 /* CI link layer level interface */ +#define CA_CI_PHYS 4 /* CI physical layer level interface */ +#define CA_DESCR 8 /* built-in descrambler */ +#define CA_SC 128 /* simple smart card interface */ + + unsigned int flags; +#define CA_CI_MODULE_PRESENT 1 /* module (or card) inserted */ +#define CA_CI_MODULE_READY 2 +} ca_slot_info_t; + + + +This CI interface follows the CI high level interface, which is not +implemented by most applications. Hence this area is revisited. + +This CI interface is quite different in the case that it tries to +accomodate all other CI based devices, that fall into the other categories + +This means that this CI interface handles the EN50221 style tags in the +Application layer only and no session management is taken care of by the +application. The driver/hardware will take care of all that. + +This interface is purely an EN50221 interface exchanging APDU's. This +means that no session management, link layer or a transport layer do +exist in this case in the application to driver communication. It is +as simple as that. The driver/hardware has to take care of that. + + +With this High Level CI interface, the interface can be defined with the +regular ioctls. + +All these ioctls are also valid for the High level CI interface + +#define CA_RESET _IO('o', 128) +#define CA_GET_CAP _IOR('o', 129, ca_caps_t) +#define CA_GET_SLOT_INFO _IOR('o', 130, ca_slot_info_t) +#define CA_GET_DESCR_INFO _IOR('o', 131, ca_descr_info_t) +#define CA_GET_MSG _IOR('o', 132, ca_msg_t) +#define CA_SEND_MSG _IOW('o', 133, ca_msg_t) +#define CA_SET_DESCR _IOW('o', 134, ca_descr_t) +#define CA_SET_PID _IOW('o', 135, ca_pid_t) + + +On querying the device, the device yields information thus + +CA_GET_SLOT_INFO +---------------------------- +Command = [info] +APP: Number=[1] +APP: Type=[1] +APP: flags=[1] +APP: CI High level interface +APP: CA/CI Module Present + +CA_GET_CAP +---------------------------- +Command = [caps] +APP: Slots=[1] +APP: Type=[1] +APP: Descrambler keys=[16] +APP: Type=[1] + +CA_SEND_MSG +---------------------------- +Descriptors(Program Level)=[ 09 06 06 04 05 50 ff f1] +Found CA descriptor @ program level + +(20) ES type=[2] ES pid=[201] ES length =[0 (0x0)] +(25) ES type=[4] ES pid=[301] ES length =[0 (0x0)] +ca_message length is 25 (0x19) bytes +EN50221 CA MSG=[ 9f 80 32 19 03 01 2d d1 f0 08 01 09 06 06 04 05 50 ff f1 02 e0 c9 00 00 04 e1 2d 00 00] + + +Not all ioctl's are implemented in the driver from the API, the other +features of the hardware that cannot be implemented by the API are achieved +using the CA_GET_MSG and CA_SEND_MSG ioctls. An EN50221 style wrapper is +used to exchange the data to maintain compatibility with other hardware. + + +/* a message to/from a CI-CAM */ +typedef struct ca_msg { + unsigned int index; + unsigned int type; + unsigned int length; + unsigned char msg[256]; +} ca_msg_t; + + +The flow of data can be described thus, + + + + + + App (User) + ----- + parse + | + | + v + en50221 APDU (package) + -------------------------------------- + | | | High Level CI driver + | | | + | v | + | en50221 APDU (unpackage) | + | | | + | | | + | v | + | sanity checks | + | | | + | | | + | v | + | do (H/W dep) | + -------------------------------------- + | Hardware + | + v + + + + +The High Level CI interface uses the EN50221 DVB standard, following a +standard ensures futureproofness. diff --git a/Documentation/dvb/get_dvb_firmware b/Documentation/dvb/get_dvb_firmware index 3ffdcb39429..a750f0101d9 100644 --- a/Documentation/dvb/get_dvb_firmware +++ b/Documentation/dvb/get_dvb_firmware @@ -107,7 +107,7 @@ sub tda10045 { sub tda10046 { my $sourcefile = "tt_budget_217g.zip"; my $url = "http://www.technotrend.de/new/217g/$sourcefile"; - my $hash = "a25b579e37109af60f4a36c37893957c"; + my $hash = "6a7e1e2f2644b162ff0502367553c72d"; my $outfile = "dvb-fe-tda10046.fw"; my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 1); @@ -115,7 +115,7 @@ sub tda10046 { wgetfile($sourcefile, $url); unzip($sourcefile, $tmpdir); - extract("$tmpdir/software/OEM/PCI/App/ttlcdacc.dll", 0x3f731, 24479, "$tmpdir/fwtmp"); + extract("$tmpdir/software/OEM/PCI/App/ttlcdacc.dll", 0x3f731, 24478, "$tmpdir/fwtmp"); verify("$tmpdir/fwtmp", $hash); copy("$tmpdir/fwtmp", $outfile); diff --git a/Documentation/fb/intelfb.txt b/Documentation/fb/intelfb.txt new file mode 100644 index 00000000000..c12d39a23c3 --- /dev/null +++ b/Documentation/fb/intelfb.txt @@ -0,0 +1,135 @@ +Intel 830M/845G/852GM/855GM/865G/915G Framebuffer driver +================================================================ + +A. Introduction + This is a framebuffer driver for various Intel 810/815 compatible +graphics devices. These would include: + + Intel 830M + Intel 810E845G + Intel 852GM + Intel 855GM + Intel 865G + Intel 915G + +B. List of available options + + a. "video=intelfb" + enables the intelfb driver + + Recommendation: required + + b. "mode=<xres>x<yres>[-<bpp>][@<refresh>]" + select mode + + Recommendation: user preference + (default = 1024x768-32@70) + + c. "vram=<value>" + select amount of system RAM in MB to allocate for the video memory + if not enough RAM was already allocated by the BIOS. + + Recommendation: 1 - 4 MB. + (default = 4 MB) + + d. "voffset=<value>" + select at what offset in MB of the logical memory to allocate the + framebuffer memory. The intent is to avoid the memory blocks + used by standard graphics applications (XFree86). Depending on your + usage, adjust the value up or down, (0 for maximum usage, 63/127 MB + for the least amount). Note, an arbitrary setting may conflict + with XFree86. + + Recommendation: do not set + (default = 48 MB) + + e. "accel" + enable text acceleration. This can be enabled/reenabled anytime + by using 'fbset -accel true/false'. + + Recommendation: enable + (default = set) + + f. "hwcursor" + enable cursor acceleration. + + Recommendation: enable + (default = set) + + g. "mtrr" + enable MTRR. This allows data transfers to the framebuffer memory + to occur in bursts which can significantly increase performance. + Not very helpful with the intel chips because of 'shared memory'. + + Recommendation: set + (default = set) + + h. "fixed" + disable mode switching. + + Recommendation: do not set + (default = not set) + + The binary parameters can be unset with a "no" prefix, example "noaccel". + The default parameter (not named) is the mode. + +C. Kernel booting + +Separate each option/option-pair by commas (,) and the option from its value +with an equals sign (=) as in the following: + +video=i810fb:option1,option2=value2 + +Sample Usage +------------ + +In /etc/lilo.conf, add the line: + +append="video=intelfb:800x600-32@75,accel,hwcursor,vram=8" + +This will initialize the framebuffer to 800x600 at 32bpp and 75Hz. The +framebuffer will use 8 MB of System RAM. hw acceleration of text and cursor +will be enabled. + +D. Module options + + The module parameters are essentially similar to the kernel +parameters. The main difference is that you need to include a Boolean value +(1 for TRUE, and 0 for FALSE) for those options which don't need a value. + +Example, to enable MTRR, include "mtrr=1". + +Sample Usage +------------ + +Using the same setup as described above, load the module like this: + + modprobe intelfb mode=800x600-32@75 vram=8 accel=1 hwcursor=1 + +Or just add the following to /etc/modprobe.conf + + options intelfb mode=800x600-32@75 vram=8 accel=1 hwcursor=1 + +and just do a + + modprobe intelfb + + +E. Acknowledgment: + + 1. Geert Uytterhoeven - his excellent howto and the virtual + framebuffer driver code made this possible. + + 2. Jeff Hartmann for his agpgart code. + + 3. David Dawes for his original kernel 2.4 code. + + 4. The X developers. Insights were provided just by reading the + XFree86 source code. + + 5. Antonino A. Daplas for his inspiring i810fb driver. + + 6. Andrew Morton for his kernel patches maintenance. + +########################### +Sylvain diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index d3c52dd24a2..b9eb209318a 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -63,3 +63,23 @@ Why: Outside of Linux, the only implementations of anything even people, who might be using implementations that I am not aware of, to adjust to this upcoming change. Who: Paul E. McKenney <paulmck@us.ibm.com> + +--------------------------- + +What: IEEE1394 Audio and Music Data Transmission Protocol driver, + Connection Management Procedures driver +When: November 2005 +Files: drivers/ieee1394/{amdtp,cmp}* +Why: These are incomplete, have never worked, and are better implemented + in userland via raw1394 (see http://freebob.sourceforge.net/ for + example.) +Who: Jody McIntyre <scjody@steamballoon.com> + +--------------------------- + +What: raw1394: requests of type RAW1394_REQ_ISO_SEND, RAW1394_REQ_ISO_LISTEN +When: November 2005 +Why: Deprecated in favour of the new ioctl-based rawiso interface, which is + more efficient. You should really be using libraw1394 for raw1394 + access anyway. +Who: Jody McIntyre <scjody@steamballoon.com> diff --git a/Documentation/filesystems/isofs.txt b/Documentation/filesystems/isofs.txt index f64a1050668..424585ff6ea 100644 --- a/Documentation/filesystems/isofs.txt +++ b/Documentation/filesystems/isofs.txt @@ -26,7 +26,11 @@ Mount options unique to the isofs filesystem. mode=xxx Sets the permissions on files to xxx nojoliet Ignore Joliet extensions if they are present. norock Ignore Rock Ridge extensions if they are present. - unhide Show hidden files. + hide Completely strip hidden files from the file system. + showassoc Show files marked with the 'associated' bit + unhide Deprecated; showing hidden files is now default; + If given, it is a synonym for 'showassoc' which will + recreate previous unhide behavior session=x Select number of session on multisession CD sbsector=xxx Session begins from sector xxx diff --git a/Documentation/filesystems/sysfs-pci.txt b/Documentation/filesystems/sysfs-pci.txt index e97d024eae7..988a62fae11 100644 --- a/Documentation/filesystems/sysfs-pci.txt +++ b/Documentation/filesystems/sysfs-pci.txt @@ -7,7 +7,6 @@ that support it. For example, a given bus might look like this: |-- 0000:17:00.0 | |-- class | |-- config - | |-- detach_state | |-- device | |-- irq | |-- local_cpus @@ -19,7 +18,7 @@ that support it. For example, a given bus might look like this: | |-- subsystem_device | |-- subsystem_vendor | `-- vendor - `-- detach_state + `-- ... The topmost element describes the PCI domain and bus number. In this case, the domain number is 0000 and the bus number is 17 (both values are in hex). @@ -31,7 +30,6 @@ files, each with their own function. ---- -------- class PCI class (ascii, ro) config PCI config space (binary, rw) - detach_state connection status (bool, rw) device PCI device (ascii, ro) irq IRQ number (ascii, ro) local_cpus nearby CPU mask (cpumask, ro) @@ -85,4 +83,4 @@ useful return codes should be provided. Legacy resources are protected by the HAVE_PCI_LEGACY define. Platforms wishing to support legacy functionality should define it and provide -pci_legacy_read, pci_legacy_write and pci_mmap_legacy_page_range functions.
\ No newline at end of file +pci_legacy_read, pci_legacy_write and pci_mmap_legacy_page_range functions. diff --git a/Documentation/filesystems/sysfs.txt b/Documentation/filesystems/sysfs.txt index 60f6c2c4d47..dc276598a65 100644 --- a/Documentation/filesystems/sysfs.txt +++ b/Documentation/filesystems/sysfs.txt @@ -214,7 +214,7 @@ Other notes: A very simple (and naive) implementation of a device attribute is: -static ssize_t show_name(struct device * dev, char * buf) +static ssize_t show_name(struct device *dev, struct device_attribute *attr, char *buf) { return sprintf(buf,"%s\n",dev->name); } diff --git a/Documentation/filesystems/tmpfs.txt b/Documentation/filesystems/tmpfs.txt index 417e3095fe3..0d783c504ea 100644 --- a/Documentation/filesystems/tmpfs.txt +++ b/Documentation/filesystems/tmpfs.txt @@ -71,8 +71,8 @@ can be changed on remount. The size parameter also accepts a suffix % to limit this tmpfs instance to that percentage of your physical RAM: the default, when neither size nor nr_blocks is specified, is size=50% -If both nr_blocks (or size) and nr_inodes are set to 0, neither blocks -nor inodes will be limited in that instance. It is generally unwise to +If nr_blocks=0 (or size=0), blocks will not be limited in that instance; +if nr_inodes=0, inodes will not be limited. It is generally unwise to mount with such options, since it allows any user with write access to use up all the memory on the machine; but enhances the scalability of that instance in a system with many cpus making intensive use of it. @@ -97,4 +97,4 @@ RAM/SWAP in 10240 inodes and it is only accessible by root. Author: Christoph Rohland <cr@sap.com>, 1.12.01 Updated: - Hugh Dickins <hugh@veritas.com>, 01 September 2004 + Hugh Dickins <hugh@veritas.com>, 13 March 2005 diff --git a/Documentation/networking/generic-hdlc.txt b/Documentation/networking/generic-hdlc.txt index 7d1dc6b884f..31bc8b759b7 100644 --- a/Documentation/networking/generic-hdlc.txt +++ b/Documentation/networking/generic-hdlc.txt @@ -1,21 +1,21 @@ Generic HDLC layer Krzysztof Halasa <khc@pm.waw.pl> -January, 2003 Generic HDLC layer currently supports: -- Frame Relay (ANSI, CCITT and no LMI), with ARP support (no InARP). - Normal (routed) and Ethernet-bridged (Ethernet device emulation) - interfaces can share a single PVC. -- raw HDLC - either IP (IPv4) interface or Ethernet device emulation. -- Cisco HDLC, -- PPP (uses syncppp.c), -- X.25 (uses X.25 routines). - -There are hardware drivers for the following cards: -- C101 by Moxa Technologies Co., Ltd. -- RISCom/N2 by SDL Communications Inc. -- and others, some not in the official kernel. +1. Frame Relay (ANSI, CCITT, Cisco and no LMI). + - Normal (routed) and Ethernet-bridged (Ethernet device emulation) + interfaces can share a single PVC. + - ARP support (no InARP support in the kernel - there is an + experimental InARP user-space daemon available on: + http://www.kernel.org/pub/linux/utils/net/hdlc/). +2. raw HDLC - either IP (IPv4) interface or Ethernet device emulation. +3. Cisco HDLC. +4. PPP (uses syncppp.c). +5. X.25 (uses X.25 routines). + +Generic HDLC is a protocol driver only - it needs a low-level driver +for your particular hardware. Ethernet device emulation (using HDLC or Frame-Relay PVC) is compatible with IEEE 802.1Q (VLANs) and 802.1D (Ethernet bridging). @@ -24,7 +24,7 @@ with IEEE 802.1Q (VLANs) and 802.1D (Ethernet bridging). Make sure the hdlc.o and the hardware driver are loaded. It should create a number of "hdlc" (hdlc0 etc) network devices, one for each WAN port. You'll need the "sethdlc" utility, get it from: - http://hq.pm.waw.pl/hdlc/ + http://www.kernel.org/pub/linux/utils/net/hdlc/ Compile sethdlc.c utility: gcc -O2 -Wall -o sethdlc sethdlc.c @@ -52,12 +52,12 @@ Setting interface: * v35 | rs232 | x21 | t1 | e1 - sets physical interface for a given port if the card has software-selectable interfaces loopback - activate hardware loopback (for testing only) -* clock ext - external clock (uses DTE RX and TX clock) -* clock int - internal clock (provides clock signal on DCE clock output) -* clock txint - TX internal, RX external (provides TX clock on DCE output) -* clock txfromrx - TX clock derived from RX clock (TX clock on DCE output) -* rate - sets clock rate in bps (not required for external clock or - for txfromrx) +* clock ext - both RX clock and TX clock external +* clock int - both RX clock and TX clock internal +* clock txint - RX clock external, TX clock internal +* clock txfromrx - RX clock external, TX clock derived from RX clock +* rate - sets clock rate in bps (for "int" or "txint" clock only) + Setting protocol: @@ -79,7 +79,7 @@ Setting protocol: * x25 - sets X.25 mode * fr - Frame Relay mode - lmi ansi / ccitt / none - LMI (link management) type + lmi ansi / ccitt / cisco / none - LMI (link management) type dce - Frame Relay DCE (network) side LMI instead of default DTE (user). It has nothing to do with clocks! t391 - link integrity verification polling timer (in seconds) - user @@ -119,13 +119,14 @@ or -If you have a problem with N2 or C101 card, you can issue the "private" -command to see port's packet descriptor rings (in kernel logs): +If you have a problem with N2, C101 or PLX200SYN card, you can issue the +"private" command to see port's packet descriptor rings (in kernel logs): sethdlc hdlc0 private -The hardware driver has to be build with CONFIG_HDLC_DEBUG_RINGS. +The hardware driver has to be build with #define DEBUG_RINGS. Attaching this info to bug reports would be helpful. Anyway, let me know if you have problems using this. -For patches and other info look at http://hq.pm.waw.pl/hdlc/ +For patches and other info look at: +<http://www.kernel.org/pub/linux/utils/net/hdlc/>. diff --git a/Documentation/networking/multicast.txt b/Documentation/networking/multicast.txt index 5049a64313d..b06c8c69266 100644 --- a/Documentation/networking/multicast.txt +++ b/Documentation/networking/multicast.txt @@ -47,7 +47,6 @@ ni52 <------------------ Buggy ------------------> ni65 YES YES YES Software(#) seeq NO NO NO N/A sgiseek <------------------ Buggy ------------------> -sk_g16 NO NO YES N/A smc-ultra YES YES YES Hardware sunlance YES YES YES Hardware tulip YES YES YES Hardware diff --git a/Documentation/networking/net-modules.txt b/Documentation/networking/net-modules.txt index 3830a83513d..0b27863f155 100644 --- a/Documentation/networking/net-modules.txt +++ b/Documentation/networking/net-modules.txt @@ -284,9 +284,6 @@ ppp.c: seeq8005.c: *Not modularized* (Probes ports: 0x300, 0x320, 0x340, 0x360) -sk_g16.c: *Not modularized* - (Probes ports: 0x100, 0x180, 0x208, 0x220m 0x288, 0x320, 0x328, 0x390) - skeleton.c: *Skeleton* slhc.c: diff --git a/Documentation/networking/vortex.txt b/Documentation/networking/vortex.txt index fa12a9e4abd..80e1cb19609 100644 --- a/Documentation/networking/vortex.txt +++ b/Documentation/networking/vortex.txt @@ -12,7 +12,7 @@ Don is no longer the prime maintainer of this version of the driver. Please report problems to one or more of: Andrew Morton <andrewm@uow.edu.au> - Netdev mailing list <netdev@oss.sgi.com> + Netdev mailing list <netdev@vger.kernel.org> Linux kernel mailing list <linux-kernel@vger.kernel.org> Please note the 'Reporting and Diagnosing Problems' section at the end diff --git a/Documentation/power/devices.txt b/Documentation/power/devices.txt index 5d4ae9a39f1..f987afe43e2 100644 --- a/Documentation/power/devices.txt +++ b/Documentation/power/devices.txt @@ -207,27 +207,6 @@ SYSTEM_SHUTDOWN, I do not understand this one too much. probably event #READY_AFTER_RESUME # -Driver Detach Power Management - -The kernel now supports the ability to place a device in a low-power -state when it is detached from its driver, which happens when its -module is removed. - -Each device contains a 'detach_state' file in its sysfs directory -which can be used to control this state. Reading from this file -displays what the current detach state is set to. This is 0 (On) by -default. A user may write a positive integer value to this file in the -range of 1-4 inclusive. - -A value of 1-3 will indicate the device should be placed in that -low-power state, which will cause ->suspend() to be called for that -device. A value of 4 indicates that the device should be shutdown, so -->shutdown() will be called for that device. - -The driver is responsible for reinitializing the device when the -module is re-inserted during it's ->probe() (or equivalent) method. -The driver core will not call any extra functions when binding the -device to the driver. pm_message_t meaning diff --git a/Documentation/powerpc/hvcs.txt b/Documentation/powerpc/hvcs.txt index c0a62e116e6..dca75cbda6f 100644 --- a/Documentation/powerpc/hvcs.txt +++ b/Documentation/powerpc/hvcs.txt @@ -347,8 +347,8 @@ address that is created by firmware. An example vty-server sysfs entry looks like the following: Pow5:/sys/bus/vio/drivers/hvcs/30000004 # ls - . current_vty devspec name partner_vtys - .. detach_state index partner_clcs vterm_state + . current_vty devspec name partner_vtys + .. index partner_clcs vterm_state Each entry is provided, by default with a "name" attribute. Reading the "name" attribute will reveal the device type as shown in the following diff --git a/Documentation/s390/CommonIO b/Documentation/s390/CommonIO index a831d9ae5a5..59d1166d41e 100644 --- a/Documentation/s390/CommonIO +++ b/Documentation/s390/CommonIO @@ -30,7 +30,7 @@ Command line parameters device numbers (0xabcd or abcd, for 2.4 backward compatibility). You can use the 'all' keyword to ignore all devices. The '!' operator will cause the I/O-layer to _not_ ignore a device. - The order on the command line is not important. + The command line is parsed from left to right. For example, cio_ignore=0.0.0023-0.0.0042,0.0.4711 @@ -72,13 +72,14 @@ Command line parameters /proc/cio_ignore; "add <device range>, <device range>, ..." will ignore the specified devices. - Note: Already known devices cannot be ignored. + Note: While already known devices can be added to the list of devices to be + ignored, there will be no effect on then. However, if such a device + disappears and then reappeares, it will then be ignored. - For example, if device 0.0.abcd is already known and all other devices - 0.0.a000-0.0.afff are not known, + For example, "echo add 0.0.a000-0.0.accc, 0.0.af00-0.0.afff > /proc/cio_ignore" - will add 0.0.a000-0.0.abcc, 0.0.abce-0.0.accc and 0.0.af00-0.0.afff to the - list of ignored devices and skip 0.0.abcd. + will add 0.0.a000-0.0.accc and 0.0.af00-0.0.afff to the list of ignored + devices. The devices can be specified either by bus id (0.0.abcd) or, for 2.4 backward compatibilty, by the device number in hexadecimal (0xabcd or abcd). @@ -98,7 +99,8 @@ Command line parameters - /proc/s390dbf/cio_trace/hex_ascii Logs the calling of functions in the common I/O-layer and, if applicable, - which subchannel they were called for. + which subchannel they were called for, as well as dumps of some data + structures (like irb in an error case). The level of logging can be changed to be more or less verbose by piping to /proc/s390dbf/cio_*/level a number between 0 and 6; see the documentation on diff --git a/Documentation/scsi/ChangeLog.megaraid b/Documentation/scsi/ChangeLog.megaraid index a9356c63b80..5331d91432c 100644 --- a/Documentation/scsi/ChangeLog.megaraid +++ b/Documentation/scsi/ChangeLog.megaraid @@ -1,3 +1,69 @@ +Release Date : Mon Mar 07 12:27:22 EST 2005 - Seokmann Ju <sju@lsil.com> +Current Version : 2.20.4.6 (scsi module), 2.20.2.6 (cmm module) +Older Version : 2.20.4.5 (scsi module), 2.20.2.5 (cmm module) + +1. Added IOCTL backward compatibility. + Convert megaraid_mm driver to new compat_ioctl entry points. + I don't have easy access to hardware, so only compile tested. + - Signed-off-by:Andi Kleen <ak@muc.de> + +2. megaraid_mbox fix: wrong order of arguments in memset() + That, BTW, shows why cross-builds are useful-the only indication of + problem had been a new warning showing up in sparse output on alpha + build (number of exceeding 256 got truncated). + - Signed-off-by: Al Viro + <viro@parcelfarce.linux.theplanet.co.uk> + +3. Convert pci_module_init to pci_register_driver + Convert from pci_module_init to pci_register_driver + (from:http://kerneljanitors.org/TODO) + - Signed-off-by: Domen Puncer <domen@coderock.org> + +4. Use the pre defined DMA mask constants from dma-mapping.h + Use the DMA_{64,32}BIT_MASK constants from dma-mapping.h when calling + pci_set_dma_mask() or pci_set_consistend_dma_mask(). See + http://marc.theaimsgroup.com/?t=108001993000001&r=1&w=2 for more + details. + Signed-off-by: Tobias Klauser <tklauser@nuerscht.ch> + Signed-off-by: Domen Puncer <domen@coderock.org> + +5. Remove SSID checking for Dobson, Lindsay, and Verde based products. + Checking the SSVID/SSID for controllers which have Dobson, Lindsay, + and Verde is unnecessary because device ID has been assigned by LSI + and it is unique value. So, all controllers with these IOPs have to be + supported by the driver regardless SSVID/SSID. + +6. Date Thu, 27 Jan 2005 04:31:09 +0100 + From Herbert Poetzl <> + Subject RFC: assert_spin_locked() for 2.6 + + Greetings! + + overcautious programming will kill your kernel ;) + ever thought about checking a spin_lock or even + asserting that it must be held (maybe just for + spinlock debugging?) ... + + there are several checks present in the kernel + where somebody does a variation on the following: + + BUG_ON(!spin_is_locked(&some_lock)); + + so what's wrong about that? nothing, unless you + compile the code with CONFIG_DEBUG_SPINLOCK but + without CONFIG_SMP ... in which case the BUG() + will kill your kernel ... + + maybe it's not advised to make such assertions, + but here is a solution which works for me ... + (compile tested for sh, x86_64 and x86, boot/run + tested for x86 only) + + best, + Herbert + + - Herbert Poetzl <herbert@13thfloor.at>, Thu, 27 Jan 2005 + Release Date : Thu Feb 03 12:27:22 EST 2005 - Seokmann Ju <sju@lsil.com> Current Version : 2.20.4.5 (scsi module), 2.20.2.5 (cmm module) Older Version : 2.20.4.4 (scsi module), 2.20.2.4 (cmm module) diff --git a/Documentation/scsi/scsi-changer.txt b/Documentation/scsi/scsi-changer.txt new file mode 100644 index 00000000000..c132687b017 --- /dev/null +++ b/Documentation/scsi/scsi-changer.txt @@ -0,0 +1,180 @@ + +README for the SCSI media changer driver +======================================== + +This is a driver for SCSI Medium Changer devices, which are listed +with "Type: Medium Changer" in /proc/scsi/scsi. + +This is for *real* Jukeboxes. It is *not* supported to work with +common small CD-ROM changers, neither one-lun-per-slot SCSI changers +nor IDE drives. + +Userland tools available from here: + http://linux.bytesex.org/misc/changer.html + + +General Information +------------------- + +First some words about how changers work: A changer has 2 (possibly +more) SCSI ID's. One for the changer device which controls the robot, +and one for the device which actually reads and writes the data. The +later may be anything, a MOD, a CD-ROM, a tape or whatever. For the +changer device this is a "don't care", he *only* shuffles around the +media, nothing else. + + +The SCSI changer model is complex, compared to - for example - IDE-CD +changers. But it allows to handle nearly all possible cases. It knows +4 different types of changer elements: + + media transport - this one shuffles around the media, i.e. the + transport arm. Also known as "picker". + storage - a slot which can hold a media. + import/export - the same as above, but is accessable from outside, + i.e. there the operator (you !) can use this to + fill in and remove media from the changer. + Sometimes named "mailslot". + data transfer - this is the device which reads/writes, i.e. the + CD-ROM / Tape / whatever drive. + +None of these is limited to one: A huge Jukebox could have slots for +123 CD-ROM's, 5 CD-ROM readers (and therefore 6 SCSI ID's: the changer +and each CD-ROM) and 2 transport arms. No problem to handle. + + +How it is implemented +--------------------- + +I implemented the driver as character device driver with a NetBSD-like +ioctl interface. Just grabbed NetBSD's header file and one of the +other linux SCSI device drivers as starting point. The interface +should be source code compatible with NetBSD. So if there is any +software (anybody knows ???) which supports a BSDish changer driver, +it should work with this driver too. + +Over time a few more ioctls where added, volume tag support for example +wasn't covered by the NetBSD ioctl API. + + +Current State +------------- + +Support for more than one transport arm is not implemented yet (and +nobody asked for it so far...). + +I test and use the driver myself with a 35 slot cdrom jukebox from +Grundig. I got some reports telling it works ok with tape autoloaders +(Exabyte, HP and DEC). Some People use this driver with amanda. It +works fine with small (11 slots) and a huge (4 MOs, 88 slots) +magneto-optical Jukebox. Probably with lots of other changers too, most +(but not all :-) people mail me only if it does *not* work... + +I don't have any device lists, neither black-list nor white-list. Thus +it is quite useless to ask me whenever a specific device is supported or +not. In theory every changer device which supports the SCSI-2 media +changer command set should work out-of-the-box with this driver. If it +doesn't, it is a bug. Either within the driver or within the firmware +of the changer device. + + +Using it +-------- + +This is a character device with major number is 86, so use +"mknod /dev/sch0 c 86 0" to create the special file for the driver. + +If the module finds the changer, it prints some messages about the +device [ try "dmesg" if you don't see anything ] and should show up in +/proc/devices. If not.... some changers use ID ? / LUN 0 for the +device and ID ? / LUN 1 for the robot mechanism. But Linux does *not* +look for LUN's other than 0 as default, becauce there are to many +broken devices. So you can try: + + 1) echo "scsi add-single-device 0 0 ID 1" > /proc/scsi/scsi + (replace ID with the SCSI-ID of the device) + 2) boot the kernel with "max_scsi_luns=1" on the command line + (append="max_scsi_luns=1" in lilo.conf should do the trick) + + +Trouble? +-------- + +If you insmod the driver with "insmod debug=1", it will be verbose and +prints a lot of stuff to the syslog. Compiling the kernel with +CONFIG_SCSI_CONSTANTS=y improves the quality of the error messages alot +because the kernel will translate the error codes into human-readable +strings then. + +You can display these messages with the dmesg command (or check the +logfiles). If you email me some question becauce of a problem with the +driver, please include these messages. + + +Insmod options +-------------- + +debug=0/1 + Enable debug messages (see above, default: 0). + +verbose=0/1 + Be verbose (default: 1). + +init=0/1 + Send INITIALIZE ELEMENT STATUS command to the changer + at insmod time (default: 1). + +timeout_init=<seconds> + timeout for the INITIALIZE ELEMENT STATUS command + (default: 3600). + +timeout_move=<seconds> + timeout for all other commands (default: 120). + +dt_id=<id1>,<id2>,... +dt_lun=<lun1>,<lun2>,... + These two allow to specify the SCSI ID and LUN for the data + transfer elements. You likely don't need this as the jukebox + should provide this information. But some devices don't ... + +vendor_firsts= +vendor_counts= +vendor_labels= + These insmod options can be used to tell the driver that there + are some vendor-specific element types. Grundig for example + does this. Some jukeboxes have a printer to label fresh burned + CDs, which is addressed as element 0xc000 (type 5). To tell the + driver about this vendor-specific element, use this: + $ insmod ch \ + vendor_firsts=0xc000 \ + vendor_counts=1 \ + vendor_labels=printer + All three insmod options accept up to four comma-separated + values, this way you can configure the element types 5-8. + You likely need the SCSI specs for the device in question to + find the correct values as they are not covered by the SCSI-2 + standard. + + +Credits +------- + +I wrote this driver using the famous mailing-patches-around-the-world +method. With (more or less) help from: + + Daniel Moehwald <moehwald@hdg.de> + Dane Jasper <dane@sonic.net> + R. Scott Bailey <sbailey@dsddi.eds.com> + Jonathan Corbet <corbet@lwn.net> + +Special thanks go to + Martin Kuehne <martin.kuehne@bnbt.de> +for a old, second-hand (but full functional) cdrom jukebox which I use +to develop/test driver and tools now. + +Have fun, + + Gerd + +-- +Gerd Knorr <kraxel@bytesex.org> diff --git a/Documentation/scsi/scsi_mid_low_api.txt b/Documentation/scsi/scsi_mid_low_api.txt index e41703d7d24..da176c95d0f 100644 --- a/Documentation/scsi/scsi_mid_low_api.txt +++ b/Documentation/scsi/scsi_mid_low_api.txt @@ -936,8 +936,7 @@ Details: * * Returns SUCCESS if command aborted else FAILED * - * Locks: struct Scsi_Host::host_lock held (with irqsave) on entry - * and assumed to be held on return. + * Locks: None held * * Calling context: kernel thread * @@ -955,8 +954,7 @@ Details: * * Returns SUCCESS if command aborted else FAILED * - * Locks: struct Scsi_Host::host_lock held (with irqsave) on entry - * and assumed to be held on return. + * Locks: None held * * Calling context: kernel thread * @@ -974,8 +972,7 @@ Details: * * Returns SUCCESS if command aborted else FAILED * - * Locks: struct Scsi_Host::host_lock held (with irqsave) on entry - * and assumed to be held on return. + * Locks: None held * * Calling context: kernel thread * @@ -993,8 +990,7 @@ Details: * * Returns SUCCESS if command aborted else FAILED * - * Locks: struct Scsi_Host::host_lock held (with irqsave) on entry - * and assumed to be held on return. + * Locks: None held * * Calling context: kernel thread * diff --git a/Documentation/sgi-ioc4.txt b/Documentation/sgi-ioc4.txt new file mode 100644 index 00000000000..876c96ae38d --- /dev/null +++ b/Documentation/sgi-ioc4.txt @@ -0,0 +1,45 @@ +The SGI IOC4 PCI device is a bit of a strange beast, so some notes on +it are in order. + +First, even though the IOC4 performs multiple functions, such as an +IDE controller, a serial controller, a PS/2 keyboard/mouse controller, +and an external interrupt mechanism, it's not implemented as a +multifunction device. The consequence of this from a software +standpoint is that all these functions share a single IRQ, and +they can't all register to own the same PCI device ID. To make +matters a bit worse, some of the register blocks (and even registers +themselves) present in IOC4 are mixed-purpose between these several +functions, meaning that there's no clear "owning" device driver. + +The solution is to organize the IOC4 driver into several independent +drivers, "ioc4", "sgiioc4", and "ioc4_serial". Note that there is no +PS/2 controller driver as this functionality has never been wired up +on a shipping IO card. + +ioc4 +==== +This is the core (or shim) driver for IOC4. It is responsible for +initializing the basic functionality of the chip, and allocating +the PCI resources that are shared between the IOC4 functions. + +This driver also provides registration functions that the other +IOC4 drivers can call to make their presence known. Each driver +needs to provide a probe and remove function, which are invoked +by the core driver at appropriate times. The interface of these +IOC4 function probe and remove operations isn't precisely the same +as PCI device probe and remove operations, but is logically the +same operation. + +sgiioc4 +======= +This is the IDE driver for IOC4. Its name isn't very descriptive +simply for historical reasons (it used to be the only IOC4 driver +component). There's not much to say about it other than it hooks +up to the ioc4 driver via the appropriate registration, probe, and +remove functions. + +ioc4_serial +=========== +This is the serial driver for IOC4. There's not much to say about it +other than it hooks up to the ioc4 driver via the appropriate registration, +probe, and remove functions. diff --git a/Documentation/x86_64/boot-options.txt b/Documentation/x86_64/boot-options.txt index 44b6eea60ec..b9e6be00cad 100644 --- a/Documentation/x86_64/boot-options.txt +++ b/Documentation/x86_64/boot-options.txt @@ -25,6 +25,9 @@ APICs noapictimer Don't set up the APIC timer + no_timer_check Don't check the IO-APIC timer. This can work around + problems with incorrect timer initialization on some boards. + Early Console syntax: earlyprintk=vga |