From e2495b577324938f0209b4f895c5f205c7e47854 Mon Sep 17 00:00:00 2001 From: Borislav Petkov Date: Sun, 27 Mar 2011 17:57:13 +0200 Subject: sched, doc: Beef up load balancing description Correct all function names pertaining to load balancing and explain shortly how load balancing is performed. Signed-off-by: Borislav Petkov Signed-off-by: Peter Zijlstra LKML-Reference: <1301241433-3790-1-git-send-email-bp@alien8.de> Signed-off-by: Ingo Molnar --- Documentation/scheduler/sched-domains.txt | 32 ++++++++++++++++++++++--------- 1 file changed, 23 insertions(+), 9 deletions(-) (limited to 'Documentation') diff --git a/Documentation/scheduler/sched-domains.txt b/Documentation/scheduler/sched-domains.txt index 373ceac..b7ee379 100644 --- a/Documentation/scheduler/sched-domains.txt +++ b/Documentation/scheduler/sched-domains.txt @@ -1,8 +1,7 @@ -Each CPU has a "base" scheduling domain (struct sched_domain). These are -accessed via cpu_sched_domain(i) and this_sched_domain() macros. The domain +Each CPU has a "base" scheduling domain (struct sched_domain). The domain hierarchy is built from these base domains via the ->parent pointer. ->parent -MUST be NULL terminated, and domain structures should be per-CPU as they -are locklessly updated. +MUST be NULL terminated, and domain structures should be per-CPU as they are +locklessly updated. Each scheduling domain spans a number of CPUs (stored in the ->span field). A domain's span MUST be a superset of it child's span (this restriction could @@ -26,11 +25,26 @@ is treated as one entity. The load of a group is defined as the sum of the load of each of its member CPUs, and only when the load of a group becomes out of balance are tasks moved between groups. -In kernel/sched.c, rebalance_tick is run periodically on each CPU. This -function takes its CPU's base sched domain and checks to see if has reached -its rebalance interval. If so, then it will run load_balance on that domain. -rebalance_tick then checks the parent sched_domain (if it exists), and the -parent of the parent and so forth. +In kernel/sched.c, trigger_load_balance() is run periodically on each CPU +through scheduler_tick(). It raises a softirq after the next regularly scheduled +rebalancing event for the current runqueue has arrived. The actual load +balancing workhorse, run_rebalance_domains()->rebalance_domains(), is then run +in softirq context (SCHED_SOFTIRQ). + +The latter function takes two arguments: the current CPU and whether it was idle +at the time the scheduler_tick() happened and iterates over all sched domains +our CPU is on, starting from its base domain and going up the ->parent chain. +While doing that, it checks to see if the current domain has exhausted its +rebalance interval. If so, it runs load_balance() on that domain. It then checks +the parent sched_domain (if it exists), and the parent of the parent and so +forth. + +Initially, load_balance() finds the busiest group in the current sched domain. +If it succeeds, it looks for the busiest runqueue of all the CPUs' runqueues in +that group. If it manages to find such a runqueue, it locks both our initial +CPU's runqueue and the newly found busiest one and starts moving tasks from it +to our runqueue. The exact number of tasks amounts to an imbalance previously +computed while iterating over this sched domain's groups. *** Implementing sched domains *** The "base" domain will "span" the first level of the hierarchy. In the case -- cgit v1.1 From 21b86bd5a838ee882d36d354185e29650b0757dd Mon Sep 17 00:00:00 2001 From: Daniel Baluta Date: Mon, 4 Apr 2011 14:58:03 -0700 Subject: Documentation: update kmemleak arch. info Besides x86 and arm, kmemleak now supports powerpc, sparc, sh, microblaze and tile. Signed-off-by: Daniel Baluta Acked-by: Catalin Marinas Signed-off-by: Randy Dunlap Signed-off-by: Linus Torvalds --- Documentation/kmemleak.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/kmemleak.txt b/Documentation/kmemleak.txt index 34f6638..090e6ee 100644 --- a/Documentation/kmemleak.txt +++ b/Documentation/kmemleak.txt @@ -11,6 +11,7 @@ with the difference that the orphan objects are not freed but only reported via /sys/kernel/debug/kmemleak. A similar method is used by the Valgrind tool (memcheck --leak-check) to detect the memory leaks in user-space applications. +Kmemleak is supported on x86, arm, powerpc, sparc, sh, microblaze and tile. Usage ----- @@ -178,5 +179,4 @@ block doesn't need to be freed (some cases in the init_call functions), the pointer is calculated by other methods than the usual container_of macro or the pointer is stored in a location not scanned by kmemleak. -Page allocations and ioremap are not tracked. Only the ARM and x86 -architectures are currently supported. +Page allocations and ioremap are not tracked. -- cgit v1.1 From 44a4dcf75c58157a5d036ff783dfb2254703b93e Mon Sep 17 00:00:00 2001 From: Randy Dunlap Date: Mon, 4 Apr 2011 15:02:24 -0700 Subject: Documentation: update panic parameter info Add a little more info for some of the panic-related kernel parameters. Fix "oops=panic" to fit in 80 columns. Signed-off-by: Randy Dunlap Reviewed-by: Jesper Juhl Signed-off-by: Linus Torvalds --- Documentation/kernel-parameters.txt | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index c357a31..f2e5f3f 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -1832,15 +1832,17 @@ bytes respectively. Such letter suffixes can also be entirely omitted. perfmon on Intel CPUs instead of the CPU specific event set. - oops=panic Always panic on oopses. Default is to just kill the process, - but there is a small probability of deadlocking the machine. + oops=panic Always panic on oopses. Default is to just kill the + process, but there is a small probability of + deadlocking the machine. This will also cause panics on machine check exceptions. Useful together with panic=30 to trigger a reboot. OSS [HW,OSS] See Documentation/sound/oss/oss-parameters.txt - panic= [KNL] Kernel behaviour on panic + panic= [KNL] Kernel behaviour on panic: delay + seconds before rebooting Format: parkbd.port= [HW] Parallel port number the keyboard adapter is @@ -2343,6 +2345,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted. softlockup_panic= [KNL] Should the soft-lockup detector generate panics. + Format: sonypi.*= [HW] Sony Programmable I/O Control Device driver See Documentation/sonypi.txt @@ -2529,8 +2532,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted. reported either. unknown_nmi_panic - [X86] - Set unknown_nmi_panic=1 early on boot. + [X86] Cause panic on unknown NMI. usbcore.autosuspend= [USB] The autosuspend time delay (in seconds) used -- cgit v1.1 From f65e51d740688b8a0ad15cbde34974e6c4559972 Mon Sep 17 00:00:00 2001 From: Sylvestre Ledru Date: Mon, 4 Apr 2011 15:04:46 -0700 Subject: Documentation: fix minor typos/spelling Fix some minor typos: * informations => information * there own => their own * these => this Signed-off-by: Sylvestre Ledru Signed-off-by: Randy Dunlap Signed-off-by: Linus Torvalds --- Documentation/ABI/testing/sysfs-driver-hid-roccat-kone | 2 +- Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus | 8 ++++---- Documentation/ABI/testing/sysfs-driver-hid-roccat-kovaplus | 8 ++++---- Documentation/ABI/testing/sysfs-driver-hid-roccat-pyra | 8 ++++---- Documentation/ABI/testing/sysfs-platform-asus-laptop | 2 +- Documentation/devicetree/booting-without-of.txt | 6 +++--- Documentation/dvb/udev.txt | 2 +- Documentation/edac.txt | 2 +- Documentation/kernel-parameters.txt | 4 ++-- Documentation/laptops/asus-laptop.txt | 4 ++-- Documentation/networking/batman-adv.txt | 2 +- Documentation/s390/Debugging390.txt | 2 +- Documentation/scsi/sym53c8xx_2.txt | 2 +- Documentation/sound/alsa/ALSA-Configuration.txt | 2 +- Documentation/sound/oss/AudioExcelDSP16 | 6 +++--- Documentation/sound/oss/README.ymfsb | 2 +- Documentation/video4linux/bttv/Insmod-options | 2 +- Documentation/video4linux/bttv/Sound-FAQ | 2 +- Documentation/video4linux/et61x251.txt | 4 ++-- Documentation/video4linux/sn9c102.txt | 4 ++-- Documentation/video4linux/w9968cf.txt | 2 +- Documentation/video4linux/zc0301.txt | 6 +++--- 22 files changed, 41 insertions(+), 41 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-driver-hid-roccat-kone b/Documentation/ABI/testing/sysfs-driver-hid-roccat-kone index b4c4f15..3ca39711 100644 --- a/Documentation/ABI/testing/sysfs-driver-hid-roccat-kone +++ b/Documentation/ABI/testing/sysfs-driver-hid-roccat-kone @@ -40,7 +40,7 @@ What: /sys/bus/usb/devices/-:./ Description: The mouse can store 5 profiles which can be switched by the - press of a button. A profile holds informations like button + press of a button. A profile holds information like button mappings, sensitivity, the colors of the 5 leds and light effects. When read, these files return the respective profile. The diff --git a/Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus b/Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus index 00efced..326e054 100644 --- a/Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus +++ b/Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus @@ -33,7 +33,7 @@ Date: August 2010 Contact: Stefan Achatz Description: The mouse can store 5 profiles which can be switched by the press of a button. A profile is split in settings and buttons. - profile_buttons holds informations about button layout. + profile_buttons holds information about button layout. When written, this file lets one write the respective profile buttons back to the mouse. The data has to be 77 bytes long. The mouse will reject invalid data. @@ -47,7 +47,7 @@ Date: August 2010 Contact: Stefan Achatz Description: The mouse can store 5 profiles which can be switched by the press of a button. A profile is split in settings and buttons. - profile_buttons holds informations about button layout. + profile_buttons holds information about button layout. When read, these files return the respective profile buttons. The returned data is 77 bytes in size. This file is readonly. @@ -58,7 +58,7 @@ Date: October 2010 Contact: Stefan Achatz Description: The mouse can store 5 profiles which can be switched by the press of a button. A profile is split in settings and buttons. - profile_settings holds informations like resolution, sensitivity + profile_settings holds information like resolution, sensitivity and light effects. When written, this file lets one write the respective profile settings back to the mouse. The data has to be 43 bytes long. @@ -73,7 +73,7 @@ Date: August 2010 Contact: Stefan Achatz Description: The mouse can store 5 profiles which can be switched by the press of a button. A profile is split in settings and buttons. - profile_settings holds informations like resolution, sensitivity + profile_settings holds information like resolution, sensitivity and light effects. When read, these files return the respective profile settings. The returned data is 43 bytes in size. diff --git a/Documentation/ABI/testing/sysfs-driver-hid-roccat-kovaplus b/Documentation/ABI/testing/sysfs-driver-hid-roccat-kovaplus index fdfa16f..20f937c 100644 --- a/Documentation/ABI/testing/sysfs-driver-hid-roccat-kovaplus +++ b/Documentation/ABI/testing/sysfs-driver-hid-roccat-kovaplus @@ -52,7 +52,7 @@ Date: January 2011 Contact: Stefan Achatz Description: The mouse can store 5 profiles which can be switched by the press of a button. A profile is split in settings and buttons. - profile_buttons holds informations about button layout. + profile_buttons holds information about button layout. When written, this file lets one write the respective profile buttons back to the mouse. The data has to be 23 bytes long. The mouse will reject invalid data. @@ -66,7 +66,7 @@ Date: January 2011 Contact: Stefan Achatz Description: The mouse can store 5 profiles which can be switched by the press of a button. A profile is split in settings and buttons. - profile_buttons holds informations about button layout. + profile_buttons holds information about button layout. When read, these files return the respective profile buttons. The returned data is 23 bytes in size. This file is readonly. @@ -77,7 +77,7 @@ Date: January 2011 Contact: Stefan Achatz Description: The mouse can store 5 profiles which can be switched by the press of a button. A profile is split in settings and buttons. - profile_settings holds informations like resolution, sensitivity + profile_settings holds information like resolution, sensitivity and light effects. When written, this file lets one write the respective profile settings back to the mouse. The data has to be 16 bytes long. @@ -92,7 +92,7 @@ Date: January 2011 Contact: Stefan Achatz Description: The mouse can store 5 profiles which can be switched by the press of a button. A profile is split in settings and buttons. - profile_settings holds informations like resolution, sensitivity + profile_settings holds information like resolution, sensitivity and light effects. When read, these files return the respective profile settings. The returned data is 16 bytes in size. diff --git a/Documentation/ABI/testing/sysfs-driver-hid-roccat-pyra b/Documentation/ABI/testing/sysfs-driver-hid-roccat-pyra index 5fab71a..3f8de50 100644 --- a/Documentation/ABI/testing/sysfs-driver-hid-roccat-pyra +++ b/Documentation/ABI/testing/sysfs-driver-hid-roccat-pyra @@ -39,7 +39,7 @@ Date: August 2010 Contact: Stefan Achatz Description: The mouse can store 5 profiles which can be switched by the press of a button. A profile is split in settings and buttons. - profile_settings holds informations like resolution, sensitivity + profile_settings holds information like resolution, sensitivity and light effects. When written, this file lets one write the respective profile settings back to the mouse. The data has to be 13 bytes long. @@ -54,7 +54,7 @@ Date: August 2010 Contact: Stefan Achatz Description: The mouse can store 5 profiles which can be switched by the press of a button. A profile is split in settings and buttons. - profile_settings holds informations like resolution, sensitivity + profile_settings holds information like resolution, sensitivity and light effects. When read, these files return the respective profile settings. The returned data is 13 bytes in size. @@ -66,7 +66,7 @@ Date: August 2010 Contact: Stefan Achatz Description: The mouse can store 5 profiles which can be switched by the press of a button. A profile is split in settings and buttons. - profile_buttons holds informations about button layout. + profile_buttons holds information about button layout. When written, this file lets one write the respective profile buttons back to the mouse. The data has to be 19 bytes long. The mouse will reject invalid data. @@ -80,7 +80,7 @@ Date: August 2010 Contact: Stefan Achatz Description: The mouse can store 5 profiles which can be switched by the press of a button. A profile is split in settings and buttons. - profile_buttons holds informations about button layout. + profile_buttons holds information about button layout. When read, these files return the respective profile buttons. The returned data is 19 bytes in size. This file is readonly. diff --git a/Documentation/ABI/testing/sysfs-platform-asus-laptop b/Documentation/ABI/testing/sysfs-platform-asus-laptop index 41ff8ae..cd9d667 100644 --- a/Documentation/ABI/testing/sysfs-platform-asus-laptop +++ b/Documentation/ABI/testing/sysfs-platform-asus-laptop @@ -27,7 +27,7 @@ KernelVersion: 2.6.20 Contact: "Corentin Chary" Description: Some models like the W1N have a LED display that can be - used to display several informations. + used to display several items of information. To control the LED display, use the following : echo 0x0T000DDD > /sys/devices/platform/asus_laptop/ where T control the 3 letters display, and DDD the 3 digits display. diff --git a/Documentation/devicetree/booting-without-of.txt b/Documentation/devicetree/booting-without-of.txt index 55fd262..50619a0 100644 --- a/Documentation/devicetree/booting-without-of.txt +++ b/Documentation/devicetree/booting-without-of.txt @@ -138,7 +138,7 @@ and properties to be present. This will be described in detail in section III, but, for example, the kernel does not require you to create a node for every PCI device in the system. It is a requirement to have a node for PCI host bridges in order to provide interrupt -routing informations and memory/IO ranges, among others. It is also +routing information and memory/IO ranges, among others. It is also recommended to define nodes for on chip devices and other buses that don't specifically fit in an existing OF specification. This creates a great flexibility in the way the kernel can then probe those and match @@ -385,7 +385,7 @@ struct boot_param_header { among others, by kexec. If you are on an SMP system, this value should match the content of the "reg" property of the CPU node in the device-tree corresponding to the CPU calling the kernel entry - point (see further chapters for more informations on the required + point (see further chapters for more information on the required device-tree contents) - size_dt_strings @@ -553,7 +553,7 @@ looks like in practice. This tree is almost a minimal tree. It pretty much contains the minimal set of required nodes and properties to boot a linux kernel; -that is, some basic model informations at the root, the CPUs, and the +that is, some basic model information at the root, the CPUs, and the 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). diff --git a/Documentation/dvb/udev.txt b/Documentation/dvb/udev.txt index 68ee224..412305b 100644 --- a/Documentation/dvb/udev.txt +++ b/Documentation/dvb/udev.txt @@ -1,7 +1,7 @@ The DVB subsystem currently registers to the sysfs subsystem using the "class_simple" interface. -This means that only the basic informations like module loading parameters +This means that only the basic information like module loading parameters are presented through sysfs. Other things that might be interesting are currently *not* available. diff --git a/Documentation/edac.txt b/Documentation/edac.txt index 9ee774d..ccc07c2 100644 --- a/Documentation/edac.txt +++ b/Documentation/edac.txt @@ -311,7 +311,7 @@ Total Correctable Errors count attribute file: 'ce_noinfo_count' This attribute file displays the number of CEs that - have occurred wherewith no informations as to which DIMM slot + have occurred wherewith no information as to which DIMM slot is having errors. Memory is handicapped, but operational, yet no information is available to indicate which slot the failing memory is in. This count field should be also diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index f2e5f3f..d2b5150 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -2478,8 +2478,8 @@ bytes respectively. Such letter suffixes can also be entirely omitted. topology= [S390] Format: {off | on} Specify if the kernel should make use of the cpu - topology informations if the hardware supports these. - The scheduler will make use of these informations and + topology information if the hardware supports this. + The scheduler will make use of this information and e.g. base its process migration decisions on it. Default is on. diff --git a/Documentation/laptops/asus-laptop.txt b/Documentation/laptops/asus-laptop.txt index c1c5be8..803e51f 100644 --- a/Documentation/laptops/asus-laptop.txt +++ b/Documentation/laptops/asus-laptop.txt @@ -61,7 +61,7 @@ Usage Hotkeys are also reported as input keys (like keyboards) you can check which key are supported using "xev" under X11. - You can get informations on the version of your DSDT table by reading the + You can get information on the version of your DSDT table by reading the /sys/devices/platform/asus-laptop/infos entry. If you have a question or a bug report to do, please include the output of this entry. @@ -178,7 +178,7 @@ LED display ----------- Some models like the W1N have a LED display that can be used to display - several informations. + several items of information. LED display works for the following models: W1000N diff --git a/Documentation/networking/batman-adv.txt b/Documentation/networking/batman-adv.txt index 18afcd8..ee496eb 100644 --- a/Documentation/networking/batman-adv.txt +++ b/Documentation/networking/batman-adv.txt @@ -72,7 +72,7 @@ folder: # fragmentation gw_sel_class vis_mode -There is a special folder for debugging informations: +There is a special folder for debugging information: # ls /sys/kernel/debug/batman_adv/bat0/ # gateways socket transtable_global vis_data diff --git a/Documentation/s390/Debugging390.txt b/Documentation/s390/Debugging390.txt index 86f9f74..efe998b 100644 --- a/Documentation/s390/Debugging390.txt +++ b/Documentation/s390/Debugging390.txt @@ -2273,7 +2273,7 @@ IP forwarding is on. There is a lot of useful info in here best found by going in & having a look around, so I'll take you through some entries I consider important. -All the processes running on the machine have there own entry defined by +All the processes running on the machine have their own entry defined by /proc/ So lets have a look at the init process cd /proc/1 diff --git a/Documentation/scsi/sym53c8xx_2.txt b/Documentation/scsi/sym53c8xx_2.txt index 6f63b79..6af8f7a 100644 --- a/Documentation/scsi/sym53c8xx_2.txt +++ b/Documentation/scsi/sym53c8xx_2.txt @@ -285,7 +285,7 @@ from the driver. 7. Profiling information -This driver does not provide profiling informations as did its predecessors. +This driver does not provide profiling information as did its predecessors. This feature was not this useful and added complexity to the code. As the driver code got more complex, I have decided to remove everything that didn't seem actually useful. diff --git a/Documentation/sound/alsa/ALSA-Configuration.txt b/Documentation/sound/alsa/ALSA-Configuration.txt index 3c1eddd..181ba5b 100644 --- a/Documentation/sound/alsa/ALSA-Configuration.txt +++ b/Documentation/sound/alsa/ALSA-Configuration.txt @@ -2229,7 +2229,7 @@ Proc interfaces (/proc/asound) /proc/asound/card#/pcm#[cp]/oss ------------------------------- - String "erase" - erase all additional informations about OSS applications + String "erase" - erase all additional information about OSS applications String " []" - name of application with (higher priority) or without path diff --git a/Documentation/sound/oss/AudioExcelDSP16 b/Documentation/sound/oss/AudioExcelDSP16 index c0f0892..e0dc064 100644 --- a/Documentation/sound/oss/AudioExcelDSP16 +++ b/Documentation/sound/oss/AudioExcelDSP16 @@ -1,10 +1,10 @@ Driver ------ -Informations about Audio Excel DSP 16 driver can be found in the source +Information about Audio Excel DSP 16 driver can be found in the source file aedsp16.c Please, read the head of the source before using it. It contain useful -informations. +information. Configuration ------------- @@ -68,7 +68,7 @@ Sound cards supported This driver supports the SC-6000 and SC-6600 based Gallant's sound card. It don't support the Audio Excel DSP 16 III (try the SC-6600 code). I'm working on the III version of the card: if someone have useful -informations about it, please let me know. +information about it, please let me know. For all the non-supported audio cards, you have to boot MS-DOS (or WIN95) activating the audio card with the MS-DOS device driver, then you have to -- and boot Linux. diff --git a/Documentation/sound/oss/README.ymfsb b/Documentation/sound/oss/README.ymfsb index af8a7d3..b6b7790 100644 --- a/Documentation/sound/oss/README.ymfsb +++ b/Documentation/sound/oss/README.ymfsb @@ -5,7 +5,7 @@ FIRST OF ALL ============ This code references YAMAHA's sample codes and data sheets. - I respect and thank for all people they made open the informations + I respect and thank for all people they made open the information about YMF7xx cards. And this codes heavily based on Jeff Garzik 's diff --git a/Documentation/video4linux/bttv/Insmod-options b/Documentation/video4linux/bttv/Insmod-options index bbe3ed6..14c065fa 100644 --- a/Documentation/video4linux/bttv/Insmod-options +++ b/Documentation/video4linux/bttv/Insmod-options @@ -1,5 +1,5 @@ -Note: "modinfo " prints various informations about a kernel +Note: "modinfo " prints various information about a kernel module, among them a complete and up-to-date list of insmod options. This list tends to be outdated because it is updated manually ... diff --git a/Documentation/video4linux/bttv/Sound-FAQ b/Documentation/video4linux/bttv/Sound-FAQ index 1e6328f..bc5e41d 100644 --- a/Documentation/video4linux/bttv/Sound-FAQ +++ b/Documentation/video4linux/bttv/Sound-FAQ @@ -8,7 +8,7 @@ completely by the bt8xx chip, which is common on all boards. But sound is handled in slightly different ways on each board. To handle the grabber boards correctly, there is a array tvcards[] in -bttv-cards.c, which holds the informations required for each board. +bttv-cards.c, which holds the information required for each board. Sound will work only, if the correct entry is used (for video it often makes no difference). The bttv driver prints a line to the kernel log, telling which card type is used. Like this one: diff --git a/Documentation/video4linux/et61x251.txt b/Documentation/video4linux/et61x251.txt index 1247566..e0cdae4 100644 --- a/Documentation/video4linux/et61x251.txt +++ b/Documentation/video4linux/et61x251.txt @@ -191,10 +191,10 @@ Syntax: Description: Debugging information level, from 0 to 3: 0 = none (use carefully) 1 = critical errors - 2 = significant informations + 2 = significant information 3 = more verbose messages Level 3 is useful for testing only, when only one device - is used at the same time. It also shows some more informations + is used at the same time. It also shows some more information about the hardware being detected. This module parameter can be changed at runtime thanks to the /sys filesystem interface. Default: 2 diff --git a/Documentation/video4linux/sn9c102.txt b/Documentation/video4linux/sn9c102.txt index 73de405..b4f6704 100644 --- a/Documentation/video4linux/sn9c102.txt +++ b/Documentation/video4linux/sn9c102.txt @@ -214,10 +214,10 @@ Syntax: Description: Debugging information level, from 0 to 3: 0 = none (use carefully) 1 = critical errors - 2 = significant informations + 2 = significant information 3 = more verbose messages Level 3 is useful for testing only. It also shows some more - informations about the hardware being detected. + information about the hardware being detected. This parameter can be changed at runtime thanks to the /sys filesystem interface. Default: 2 diff --git a/Documentation/video4linux/w9968cf.txt b/Documentation/video4linux/w9968cf.txt index 05138e8..9649450 100644 --- a/Documentation/video4linux/w9968cf.txt +++ b/Documentation/video4linux/w9968cf.txt @@ -413,7 +413,7 @@ Syntax: Description: Debugging information level, from 0 to 6: 0 = none (use carefully) 1 = critical errors - 2 = significant informations + 2 = significant information 3 = configuration or general messages 4 = warnings 5 = called functions diff --git a/Documentation/video4linux/zc0301.txt b/Documentation/video4linux/zc0301.txt index befdfdacd..b41c83c 100644 --- a/Documentation/video4linux/zc0301.txt +++ b/Documentation/video4linux/zc0301.txt @@ -181,10 +181,10 @@ Syntax: Description: Debugging information level, from 0 to 3: 0 = none (use carefully) 1 = critical errors - 2 = significant informations + 2 = significant information 3 = more verbose messages Level 3 is useful for testing only, when only one device - is used at the same time. It also shows some more informations + is used at the same time. It also shows some information about the hardware being detected. This module parameter can be changed at runtime thanks to the /sys filesystem interface. Default: 2 @@ -261,7 +261,7 @@ the fingerprint is: '88E8 F32F 7244 68BA 3958 5D40 99DA 5D2A FCE6 35A4'. 11. Credits =========== -- Informations about the chip internals needed to enable the I2C protocol have +- Information about the chip internals needed to enable the I2C protocol have been taken from the documentation of the ZC030x Video4Linux1 driver written by Andrew Birkett ; - The initialization values of the ZC0301 controller connected to the PAS202BCB -- cgit v1.1 From 9a684e19afc630e0763246ee79c0578c1a8eaee8 Mon Sep 17 00:00:00 2001 From: Antonio Ospite Date: Mon, 4 Apr 2011 15:08:46 -0700 Subject: Documentation: consolidate leds files to leds/ subdir leds: move leds-class documentation under the leds/ subdir. Add also a leds/00-INDEX file describing the files under leds/ Signed-off-by: Antonio Ospite Acked-by: Richard Purdie Cc: Andrew Morton Signed-off-by: Randy Dunlap Signed-off-by: Linus Torvalds --- Documentation/00-INDEX | 4 +- Documentation/leds-class.txt | 98 -------------------------------------- Documentation/leds-lp3944.txt | 50 ------------------- Documentation/leds/00-INDEX | 8 ++++ Documentation/leds/leds-class.txt | 97 +++++++++++++++++++++++++++++++++++++ Documentation/leds/leds-lp3944.txt | 50 +++++++++++++++++++ 6 files changed, 157 insertions(+), 150 deletions(-) delete mode 100644 Documentation/leds-class.txt delete mode 100644 Documentation/leds-lp3944.txt create mode 100644 Documentation/leds/00-INDEX create mode 100644 Documentation/leds/leds-class.txt create mode 100644 Documentation/leds/leds-lp3944.txt (limited to 'Documentation') diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index f607367..c17cd4b 100644 --- a/Documentation/00-INDEX +++ b/Documentation/00-INDEX @@ -206,8 +206,8 @@ laptops/ - directory with laptop related info and laptop driver documentation. ldm.txt - a brief description of LDM (Windows Dynamic Disks). -leds-class.txt - - documents LED handling under Linux. +leds/ + - directory with info about LED handling under Linux. local_ops.txt - semantics and behavior of local atomic operations. lockdep-design.txt diff --git a/Documentation/leds-class.txt b/Documentation/leds-class.txt deleted file mode 100644 index 58b266b..0000000 --- a/Documentation/leds-class.txt +++ /dev/null @@ -1,98 +0,0 @@ - -LED handling under Linux -======================== - -If you're reading this and thinking about keyboard leds, these are -handled by the input subsystem and the led class is *not* needed. - -In its simplest form, the LED class just allows control of LEDs from -userspace. LEDs appear in /sys/class/leds/. The maximum brightness of the -LED is defined in max_brightness file. The brightness file will set the brightness -of the LED (taking a value 0-max_brightness). Most LEDs don't have hardware -brightness support so will just be turned on for non-zero brightness settings. - -The class also introduces the optional concept of an LED trigger. A trigger -is a kernel based source of led events. Triggers can either be simple or -complex. A simple trigger isn't configurable and is designed to slot into -existing subsystems with minimal additional code. Examples are the ide-disk, -nand-disk and sharpsl-charge triggers. With led triggers disabled, the code -optimises away. - -Complex triggers whilst available to all LEDs have LED specific -parameters and work on a per LED basis. The timer trigger is an example. -The timer trigger will periodically change the LED brightness between -LED_OFF and the current brightness setting. The "on" and "off" time can -be specified via /sys/class/leds//delay_{on,off} in milliseconds. -You can change the brightness value of a LED independently of the timer -trigger. However, if you set the brightness value to LED_OFF it will -also disable the timer trigger. - -You can change triggers in a similar manner to the way an IO scheduler -is chosen (via /sys/class/leds//trigger). Trigger specific -parameters can appear in /sys/class/leds/ once a given trigger is -selected. - - -Design Philosophy -================= - -The underlying design philosophy is simplicity. LEDs are simple devices -and the aim is to keep a small amount of code giving as much functionality -as possible. Please keep this in mind when suggesting enhancements. - - -LED Device Naming -================= - -Is currently of the form: - -"devicename:colour:function" - -There have been calls for LED properties such as colour to be exported as -individual led class attributes. As a solution which doesn't incur as much -overhead, I suggest these become part of the device name. The naming scheme -above leaves scope for further attributes should they be needed. If sections -of the name don't apply, just leave that section blank. - - -Hardware accelerated blink of LEDs -================================== - -Some LEDs can be programmed to blink without any CPU interaction. To -support this feature, a LED driver can optionally implement the -blink_set() function (see ). To set an LED to blinking, -however, it is better to use use the API function led_blink_set(), -as it will check and implement software fallback if necessary. - -To turn off blinking again, use the API function led_brightness_set() -as that will not just set the LED brightness but also stop any software -timers that may have been required for blinking. - -The blink_set() function should choose a user friendly blinking value -if it is called with *delay_on==0 && *delay_off==0 parameters. In this -case the driver should give back the chosen value through delay_on and -delay_off parameters to the leds subsystem. - -Setting the brightness to zero with brightness_set() callback function -should completely turn off the LED and cancel the previously programmed -hardware blinking function, if any. - - -Known Issues -============ - -The LED Trigger core cannot be a module as the simple trigger functions -would cause nightmare dependency issues. I see this as a minor issue -compared to the benefits the simple trigger functionality brings. The -rest of the LED subsystem can be modular. - - -Future Development -================== - -At the moment, a trigger can't be created specifically for a single LED. -There are a number of cases where a trigger might only be mappable to a -particular LED (ACPI?). The addition of triggers provided by the LED driver -should cover this option and be possible to add without breaking the -current interface. - diff --git a/Documentation/leds-lp3944.txt b/Documentation/leds-lp3944.txt deleted file mode 100644 index c6eda18..0000000 --- a/Documentation/leds-lp3944.txt +++ /dev/null @@ -1,50 +0,0 @@ -Kernel driver lp3944 -==================== - - * National Semiconductor LP3944 Fun-light Chip - Prefix: 'lp3944' - Addresses scanned: None (see the Notes section below) - Datasheet: Publicly available at the National Semiconductor website - http://www.national.com/pf/LP/LP3944.html - -Authors: - Antonio Ospite - - -Description ------------ -The LP3944 is a helper chip that can drive up to 8 leds, with two programmable -DIM modes; it could even be used as a gpio expander but this driver assumes it -is used as a led controller. - -The DIM modes are used to set _blink_ patterns for leds, the pattern is -specified supplying two parameters: - - period: from 0s to 1.6s - - duty cycle: percentage of the period the led is on, from 0 to 100 - -Setting a led in DIM0 or DIM1 mode makes it blink according to the pattern. -See the datasheet for details. - -LP3944 can be found on Motorola A910 smartphone, where it drives the rgb -leds, the camera flash light and the lcds power. - - -Notes ------ -The chip is used mainly in embedded contexts, so this driver expects it is -registered using the i2c_board_info mechanism. - -To register the chip at address 0x60 on adapter 0, set the platform data -according to include/linux/leds-lp3944.h, set the i2c board info: - - static struct i2c_board_info __initdata a910_i2c_board_info[] = { - { - I2C_BOARD_INFO("lp3944", 0x60), - .platform_data = &a910_lp3944_leds, - }, - }; - -and register it in the platform init function - - i2c_register_board_info(0, a910_i2c_board_info, - ARRAY_SIZE(a910_i2c_board_info)); diff --git a/Documentation/leds/00-INDEX b/Documentation/leds/00-INDEX new file mode 100644 index 0000000..29f481d --- /dev/null +++ b/Documentation/leds/00-INDEX @@ -0,0 +1,8 @@ +leds-class.txt + - documents LED handling under Linux. +leds-lp3944.txt + - notes on how to use the leds-lp3944 driver. +leds-lp5521.txt + - notes on how to use the leds-lp5521 driver. +leds-lp5523.txt + - notes on how to use the leds-lp5523 driver. diff --git a/Documentation/leds/leds-class.txt b/Documentation/leds/leds-class.txt new file mode 100644 index 0000000..4996586 --- /dev/null +++ b/Documentation/leds/leds-class.txt @@ -0,0 +1,97 @@ + +LED handling under Linux +======================== + +If you're reading this and thinking about keyboard leds, these are +handled by the input subsystem and the led class is *not* needed. + +In its simplest form, the LED class just allows control of LEDs from +userspace. LEDs appear in /sys/class/leds/. The maximum brightness of the +LED is defined in max_brightness file. The brightness file will set the brightness +of the LED (taking a value 0-max_brightness). Most LEDs don't have hardware +brightness support so will just be turned on for non-zero brightness settings. + +The class also introduces the optional concept of an LED trigger. A trigger +is a kernel based source of led events. Triggers can either be simple or +complex. A simple trigger isn't configurable and is designed to slot into +existing subsystems with minimal additional code. Examples are the ide-disk, +nand-disk and sharpsl-charge triggers. With led triggers disabled, the code +optimises away. + +Complex triggers whilst available to all LEDs have LED specific +parameters and work on a per LED basis. The timer trigger is an example. +The timer trigger will periodically change the LED brightness between +LED_OFF and the current brightness setting. The "on" and "off" time can +be specified via /sys/class/leds//delay_{on,off} in milliseconds. +You can change the brightness value of a LED independently of the timer +trigger. However, if you set the brightness value to LED_OFF it will +also disable the timer trigger. + +You can change triggers in a similar manner to the way an IO scheduler +is chosen (via /sys/class/leds//trigger). Trigger specific +parameters can appear in /sys/class/leds/ once a given trigger is +selected. + + +Design Philosophy +================= + +The underlying design philosophy is simplicity. LEDs are simple devices +and the aim is to keep a small amount of code giving as much functionality +as possible. Please keep this in mind when suggesting enhancements. + + +LED Device Naming +================= + +Is currently of the form: + +"devicename:colour:function" + +There have been calls for LED properties such as colour to be exported as +individual led class attributes. As a solution which doesn't incur as much +overhead, I suggest these become part of the device name. The naming scheme +above leaves scope for further attributes should they be needed. If sections +of the name don't apply, just leave that section blank. + + +Hardware accelerated blink of LEDs +================================== + +Some LEDs can be programmed to blink without any CPU interaction. To +support this feature, a LED driver can optionally implement the +blink_set() function (see ). To set an LED to blinking, +however, it is better to use use the API function led_blink_set(), +as it will check and implement software fallback if necessary. + +To turn off blinking again, use the API function led_brightness_set() +as that will not just set the LED brightness but also stop any software +timers that may have been required for blinking. + +The blink_set() function should choose a user friendly blinking value +if it is called with *delay_on==0 && *delay_off==0 parameters. In this +case the driver should give back the chosen value through delay_on and +delay_off parameters to the leds subsystem. + +Setting the brightness to zero with brightness_set() callback function +should completely turn off the LED and cancel the previously programmed +hardware blinking function, if any. + + +Known Issues +============ + +The LED Trigger core cannot be a module as the simple trigger functions +would cause nightmare dependency issues. I see this as a minor issue +compared to the benefits the simple trigger functionality brings. The +rest of the LED subsystem can be modular. + + +Future Development +================== + +At the moment, a trigger can't be created specifically for a single LED. +There are a number of cases where a trigger might only be mappable to a +particular LED (ACPI?). The addition of triggers provided by the LED driver +should cover this option and be possible to add without breaking the +current interface. diff --git a/Documentation/leds/leds-lp3944.txt b/Documentation/leds/leds-lp3944.txt new file mode 100644 index 0000000..c6eda18 --- /dev/null +++ b/Documentation/leds/leds-lp3944.txt @@ -0,0 +1,50 @@ +Kernel driver lp3944 +==================== + + * National Semiconductor LP3944 Fun-light Chip + Prefix: 'lp3944' + Addresses scanned: None (see the Notes section below) + Datasheet: Publicly available at the National Semiconductor website + http://www.national.com/pf/LP/LP3944.html + +Authors: + Antonio Ospite + + +Description +----------- +The LP3944 is a helper chip that can drive up to 8 leds, with two programmable +DIM modes; it could even be used as a gpio expander but this driver assumes it +is used as a led controller. + +The DIM modes are used to set _blink_ patterns for leds, the pattern is +specified supplying two parameters: + - period: from 0s to 1.6s + - duty cycle: percentage of the period the led is on, from 0 to 100 + +Setting a led in DIM0 or DIM1 mode makes it blink according to the pattern. +See the datasheet for details. + +LP3944 can be found on Motorola A910 smartphone, where it drives the rgb +leds, the camera flash light and the lcds power. + + +Notes +----- +The chip is used mainly in embedded contexts, so this driver expects it is +registered using the i2c_board_info mechanism. + +To register the chip at address 0x60 on adapter 0, set the platform data +according to include/linux/leds-lp3944.h, set the i2c board info: + + static struct i2c_board_info __initdata a910_i2c_board_info[] = { + { + I2C_BOARD_INFO("lp3944", 0x60), + .platform_data = &a910_lp3944_leds, + }, + }; + +and register it in the platform init function + + i2c_register_board_info(0, a910_i2c_board_info, + ARRAY_SIZE(a910_i2c_board_info)); -- cgit v1.1 From 6ad85239da45d035b2c786f73ec3c2798352c820 Mon Sep 17 00:00:00 2001 From: Geunsik Lim Date: Mon, 4 Apr 2011 15:10:45 -0700 Subject: Documentation: update cgroups info user groups names Update suitable words to explain / understand cgroups contents. Signed-off-by: Geunsik Lim Cc: Paul Menage Signed-off-by: Randy Dunlap Signed-off-by: Linus Torvalds --- Documentation/cgroups/cgroups.txt | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/cgroups/cgroups.txt b/Documentation/cgroups/cgroups.txt index cbdfb7d..aedf1bd 100644 --- a/Documentation/cgroups/cgroups.txt +++ b/Documentation/cgroups/cgroups.txt @@ -110,22 +110,22 @@ university server with various users - students, professors, system tasks etc. The resource planning for this server could be along the following lines: - CPU : Top cpuset + CPU : "Top cpuset" / \ CPUSet1 CPUSet2 - | | - (Profs) (Students) + | | + (Professors) (Students) In addition (system tasks) are attached to topcpuset (so that they can run anywhere) with a limit of 20% - Memory : Professors (50%), students (30%), system (20%) + Memory : Professors (50%), Students (30%), system (20%) - Disk : Prof (50%), students (30%), system (20%) + Disk : Professors (50%), Students (30%), system (20%) Network : WWW browsing (20%), Network File System (60%), others (20%) / \ - Prof (15%) students (5%) + Professors (15%) students (5%) Browsers like Firefox/Lynx go into the WWW network class, while (k)nfsd go into NFS network class. -- cgit v1.1