diff options
Diffstat (limited to 'Documentation')
| -rw-r--r-- | Documentation/acpi-hotkey.txt | 38 | ||||
| -rw-r--r-- | Documentation/arm/Samsung-S3C24XX/DMA.txt | 46 | ||||
| -rw-r--r-- | Documentation/arm/Samsung-S3C24XX/Overview.txt | 21 | ||||
| -rw-r--r-- | Documentation/feature-removal-schedule.txt | 23 | ||||
| -rw-r--r-- | Documentation/kernel-parameters.txt | 6 | ||||
| -rw-r--r-- | Documentation/pci.txt | 4 | ||||
| -rw-r--r-- | Documentation/powerpc/booting-without-of.txt | 14 | ||||
| -rw-r--r-- | Documentation/sony-laptop.txt | 106 |
8 files changed, 180 insertions, 78 deletions
diff --git a/Documentation/acpi-hotkey.txt b/Documentation/acpi-hotkey.txt deleted file mode 100644 index 38040fa37649..000000000000 --- a/Documentation/acpi-hotkey.txt +++ /dev/null @@ -1,38 +0,0 @@ -driver/acpi/hotkey.c implement: -1. /proc/acpi/hotkey/event_config -(event based hotkey or event config interface): -a. add a event based hotkey(event) : -echo "0:bus::action:method:num:num" > event_config - -b. delete a event based hotkey(event): -echo "1:::::num:num" > event_config - -c. modify a event based hotkey(event): -echo "2:bus::action:method:num:num" > event_config - -2. /proc/acpi/hotkey/poll_config -(polling based hotkey or event config interface): -a.add a polling based hotkey(event) : -echo "0:bus:method:action:method:num" > poll_config -this adding command will create a proc file -/proc/acpi/hotkey/method, which is used to get -result of polling. - -b.delete a polling based hotkey(event): -echo "1:::::num" > event_config - -c.modify a polling based hotkey(event): -echo "2:bus:method:action:method:num" > poll_config - -3./proc/acpi/hotkey/action -(interface to call aml method associated with a -specific hotkey(event)) -echo "event_num:event_type:event_argument" > - /proc/acpi/hotkey/action. -The result of the execution of this aml method is -attached to /proc/acpi/hotkey/poll_method, which is dynamically -created. Please use command "cat /proc/acpi/hotkey/polling_method" -to retrieve it. - -Note: Use cmdline "acpi_generic_hotkey" to over-ride -platform-specific with generic driver. diff --git a/Documentation/arm/Samsung-S3C24XX/DMA.txt b/Documentation/arm/Samsung-S3C24XX/DMA.txt new file mode 100644 index 000000000000..37f4edcc5d87 --- /dev/null +++ b/Documentation/arm/Samsung-S3C24XX/DMA.txt @@ -0,0 +1,46 @@ + S3C2410 DMA + =========== + +Introduction +------------ + + The kernel provides an interface to manage DMA transfers + using the DMA channels in the cpu, so that the central + duty of managing channel mappings, and programming the + channel generators is in one place. + + +DMA Channel Ordering +-------------------- + + Many of the range do not have connections for the DMA + channels to all sources, which means that some devices + have a restricted number of channels that can be used. + + To allow flexibilty for each cpu type and board, the + dma code can be given an dma ordering structure which + allows the order of channel search to be specified, as + well as allowing the prohibition of certain claims. + + struct s3c24xx_dma_order has a list of channels, and + each channel within has a slot for a list of dma + channel numbers. The slots are searched in order, for + the presence of a dma channel number with DMA_CH_VALID + orred in. + + If the order has the flag DMA_CH_NEVER set, then after + checking the channel list, the system will return no + found channel, thus denying the request. + + A board support file can call s3c24xx_dma_order_set() + to register an complete ordering set. The routine will + copy the data, so the original can be discared with + __initdata. + + +Authour +------- + +Ben Dooks, +Copyright (c) 2007 Ben Dooks, Simtec Electronics +Licensed under the GPL v2 diff --git a/Documentation/arm/Samsung-S3C24XX/Overview.txt b/Documentation/arm/Samsung-S3C24XX/Overview.txt index 28d014714ab8..c31b76fa66c4 100644 --- a/Documentation/arm/Samsung-S3C24XX/Overview.txt +++ b/Documentation/arm/Samsung-S3C24XX/Overview.txt @@ -8,13 +8,10 @@ Introduction The Samsung S3C24XX range of ARM9 System-on-Chip CPUs are supported by the 's3c2410' architecture of ARM Linux. Currently the S3C2410, - S3C2440 and S3C2442 devices are supported. + S3C2412, S3C2413, S3C2440 and S3C2442 devices are supported. Support for the S3C2400 series is in progress. - Support for the S3C2412 and S3C2413 CPUs is being merged. - - Configuration ------------- @@ -26,6 +23,22 @@ Configuration please check the machine specific documentation. +Layout +------ + + The core support files are located in the platform code contained in + arch/arm/plat-s3c24xx with headers in include/asm-arm/plat-s3c24xx. + This directory should be kept to items shared between the platform + code (arch/arm/plat-s3c24xx) and the arch/arm/mach-s3c24* code. + + Each cpu has a directory with the support files for it, and the + machines that carry the device. For example S3C2410 is contained + in arch/arm/mach-s3c2410 and S3C2440 in arch/arm/mach-s3c2440 + + Register, kernel and platform data definitions are held in the + include/asm-arm/arch-s3c2410 directory. + + Machines -------- diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index c585aa8d62b4..28f897fd3674 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -253,29 +253,6 @@ Who: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> --------------------------- -<<<<<<< test:Documentation/feature-removal-schedule.txt -What: ACPI hotkey driver (CONFIG_ACPI_HOTKEY) -When: 2.6.21 -Why: hotkey.c was an attempt to consolidate multiple drivers that use - ACPI to implement hotkeys. However, hotkeys are not documented - in the ACPI specification, so the drivers used undocumented - vendor-specific hooks and turned out to be more different than - the same. - - Further, the keys and the features supplied by each platform - are different, so there will always be a need for - platform-specific drivers. - - So the new plan is to delete hotkey.c and instead, work on the - platform specific drivers to try to make them look the same - to the user when they supply the same features. - - hotkey.c has always depended on CONFIG_EXPERIMENTAL - -Who: Len Brown <len.brown@intel.com> - ---------------------------- - What: /sys/firmware/acpi/namespace When: 2.6.21 Why: The ACPI namespace is effectively the symbol list for diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 5bc8970b8349..35470de14a95 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -1280,6 +1280,12 @@ and is between 256 and 4096 characters. It is defined in the file This sorting is done to get a device order compatible with older (<= 2.4) kernels. nobfsort Don't sort PCI devices into breadth-first order. + cbiosize=nn[KMG] The fixed amount of bus space which is + reserved for the CardBus bridge's IO window. + The default value is 256 bytes. + cbmemsize=nn[KMG] The fixed amount of bus space which is + reserved for the CardBus bridge's memory + window. The default value is 64 megabytes. pcmv= [HW,PCMCIA] BadgePAD 4 diff --git a/Documentation/pci.txt b/Documentation/pci.txt index fd5028eca13e..cdf2f3c0ab14 100644 --- a/Documentation/pci.txt +++ b/Documentation/pci.txt @@ -205,8 +205,8 @@ Tips on when/where to use the above attributes: exclusively called by the probe() routine, can be marked __devinit. Ditto for remove() and __devexit. - o If mydriver_probe() is marked with __devinit(), then all address - references to mydriver_probe must use __devexit_p(mydriver_probe) + o If mydriver_remove() is marked with __devexit(), then all address + references to mydriver_remove must use __devexit_p(mydriver_remove) (in the struct pci_driver declaration for example). __devexit_p() will generate the function name _or_ NULL if the function will be discarded. For an example, see drivers/net/tg3.c. diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt index 3b514672b80e..b41397d6430a 100644 --- a/Documentation/powerpc/booting-without-of.txt +++ b/Documentation/powerpc/booting-without-of.txt @@ -497,7 +497,7 @@ looks like in practice. | |- device_type = "cpu" | |- reg = <0> | |- clock-frequency = <5f5e1000> - | |- linux,boot-cpu + | |- 64-bit | |- linux,phandle = <2> | o memory@0 @@ -509,7 +509,6 @@ looks like in practice. o chosen |- name = "chosen" |- bootargs = "root=/dev/sda2" - |- linux,platform = <00000600> |- linux,phandle = <4> This tree is almost a minimal tree. It pretty much contains the @@ -519,7 +518,7 @@ physical memory layout. It also includes misc information passed through /chosen, like in this example, the platform type (mandatory) and the kernel command line arguments (optional). -The /cpus/PowerPC,970@0/linux,boot-cpu property is an example of a +The /cpus/PowerPC,970@0/64-bit property is an example of a property without a value. All other properties have a value. The significance of the #address-cells and #size-cells properties will be explained in chapter IV which defines precisely the required nodes and @@ -733,8 +732,7 @@ address which can extend beyond that limit. that typically get driven by the same platform code in the kernel, you would use a different "model" property but put a value in "compatible". The kernel doesn't directly use that - value (see /chosen/linux,platform for how the kernel chooses a - platform type) but it is generally useful. + value but it is generally useful. The root node is also generally where you add additional properties specific to your board like the serial number if any, that sort of @@ -778,7 +776,6 @@ address which can extend beyond that limit. bytes - d-cache-size : one cell, size of L1 data cache in bytes - i-cache-size : one cell, size of L1 instruction cache in bytes - - linux, boot-cpu : Should be defined if this cpu is the boot cpu. Recommended properties: @@ -843,11 +840,6 @@ address which can extend beyond that limit. the prom_init() trampoline when booting with an OF client interface, but that you have to provide yourself when using the flattened format. - Required properties: - - - linux,platform : This is your platform number as assigned by the - architecture maintainers - Recommended properties: - bootargs : This zero-terminated string is passed as the kernel diff --git a/Documentation/sony-laptop.txt b/Documentation/sony-laptop.txt new file mode 100644 index 000000000000..dfd26df056f4 --- /dev/null +++ b/Documentation/sony-laptop.txt @@ -0,0 +1,106 @@ +Sony Notebook Control Driver (SNC) Readme +----------------------------------------- + Copyright (C) 2004- 2005 Stelian Pop <stelian@popies.net> + Copyright (C) 2007 Mattia Dongili <malattia@linux.it> + +This mini-driver drives the SNC device present in the ACPI BIOS of +the Sony Vaio laptops. + +It gives access to some extra laptop functionalities. In its current +form, this driver let the user set or query the screen brightness +through the backlight subsystem and remove/apply power to some devices. + +Backlight control: +------------------ +If your laptop model supports it, you will find sysfs files in the +/sys/class/backlight/sony/ +directory. You will be able to query and set the current screen +brightness: + brightness get/set screen brightness (an iteger + between 0 and 7) + actual_brightness reading from this file will query the HW + to get real brightness value + max_brightness the maximum brightness value + + +Platform specific: +------------------ +Loading the sony-laptop module will create a +/sys/devices/platform/sony-laptop/ +directory populated with some files. + +You then read/write integer values from/to those files by using +standard UNIX tools. + +The files are: + brightness_default screen brightness which will be set + when the laptop will be rebooted + cdpower power on/off the internal CD drive + audiopower power on/off the internal sound card + lanpower power on/off the internal ethernet card + (only in debug mode) + +Note that some files may be missing if they are not supported +by your particular laptop model. + +Example usage: + # echo "1" > /sys/devices/platform/sony-laptop/brightness_default +sets the lowest screen brightness for the next and later reboots, + # echo "8" > /sys/devices/platform/sony-laptop/brightness_default +sets the highest screen brightness for the next and later reboots, + # cat /sys/devices/platform/sony-laptop/brightness_default +retrieves the value. + + # echo "0" > /sys/devices/platform/sony-laptop/audiopower +powers off the sound card, + # echo "1" > /sys/devices/platform/sony-laptop/audiopower +powers on the sound card. + +Development: +------------ + +If you want to help with the development of this driver (and +you are not afraid of any side effects doing strange things with +your ACPI BIOS could have on your laptop), load the driver and +pass the option 'debug=1'. + +REPEAT: DON'T DO THIS IF YOU DON'T LIKE RISKY BUSINESS. + +In your kernel logs you will find the list of all ACPI methods +the SNC device has on your laptop. You can see the GCDP/GCDP methods +used to pwer on/off the CD drive, but there are others. + +I HAVE NO IDEA WHAT THOSE METHODS DO. + +The sony-laptop driver creates, for some of those methods (the most +current ones found on several Vaio models), an entry under +/sys/devices/platform/sony-laptop, just like the 'cdpower' one. +You can create other entries corresponding to your own laptop methods by +further editing the source (see the 'sony_acpi_values' table, and add a new +entry to this table with your get/set method names using the +HANDLE_NAMES macro). + +Your mission, should you accept it, is to try finding out what +those entries are for, by reading/writing random values from/to those +files and find out what is the impact on your laptop. + +Should you find anything interesting, please report it back to me, +I will not disavow all knowledge of your actions :) + +Bugs/Limitations: +----------------- + +* This driver is not based on official documentation from Sony + (because there is none), so there is no guarantee this driver + will work at all, or do the right thing. Although this hasn't + happened to me, this driver could do very bad things to your + laptop, including permanent damage. + +* The sony-laptop and sonypi drivers do not interact at all. In the + future, sonypi could use sony-laptop to do (part of) its business. + +* spicctrl, which is the userspace tool used to communicate with the + sonypi driver (through /dev/sonypi) does not try to use the + sony-laptop driver. In the future, spicctrl could try sonypi first, + and if it isn't present, try sony-laptop instead. + |