Loading Documentation/ABI/testing/sysfs-bus-usb +13 −0 Original line number Diff line number Diff line Loading @@ -144,3 +144,16 @@ Description: Write a 1 to force the device to disconnect (equivalent to unplugging a wired USB device). What: /sys/bus/usb/drivers/.../remove_id Date: November 2009 Contact: CHENG Renquan <rqcheng@smu.edu.sg> Description: Writing a device ID to this file will remove an ID that was dynamically added via the new_id sysfs entry. The format for the device ID is: idVendor idProduct. After successfully removing an ID, the driver will no longer support the device. This is useful to ensure auto probing won't match the driver to the device. For example: # echo "046d c315" > /sys/bus/usb/drivers/foo/remove_id Documentation/ABI/testing/sysfs-class-uwb_rc-wusbhc +13 −0 Original line number Diff line number Diff line Loading @@ -23,3 +23,16 @@ Description: Since this relates to security (specifically, the lifetime of PTKs and GTKs) it should not be changed from the default. What: /sys/class/uwb_rc/uwbN/wusbhc/wusb_phy_rate Date: August 2009 KernelVersion: 2.6.32 Contact: David Vrabel <david.vrabel@csr.com> Description: The maximum PHY rate to use for all connected devices. This is only of limited use for testing and development as the hardware's automatic rate adaptation is better then this simple control. Refer to [ECMA-368] section 10.3.1.1 for the value to use. Documentation/ABI/testing/sysfs-devices-system-cpu +33 −0 Original line number Diff line number Diff line Loading @@ -62,6 +62,21 @@ Description: CPU topology files that describe kernel limits related to See Documentation/cputopology.txt for more information. What: /sys/devices/system/cpu/probe /sys/devices/system/cpu/release Date: November 2009 Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org> Description: Dynamic addition and removal of CPU's. This is not hotplug removal, this is meant complete removal/addition of the CPU from the system. probe: writes to this file will dynamically add a CPU to the system. Information written to the file to add CPU's is architecture specific. release: writes to this file dynamically remove a CPU from the system. Information writtento the file to remove CPU's is architecture specific. What: /sys/devices/system/cpu/cpu#/node Date: October 2009 Loading Loading @@ -136,6 +151,24 @@ Description: Discover cpuidle policy and mechanism See files in Documentation/cpuidle/ for more information. What: /sys/devices/system/cpu/cpu#/cpufreq/* Date: pre-git history Contact: cpufreq@vger.kernel.org Description: Discover and change clock speed of CPUs Clock scaling allows you to change the clock speed of the CPUs on the fly. This is a nice method to save battery power, because the lower the clock speed, the less power the CPU consumes. There are many knobs to tweak in this directory. See files in Documentation/cpu-freq/ for more information. In particular, read Documentation/cpu-freq/user-guide.txt to learn how to control the knobs. What: /sys/devices/system/cpu/cpu*/cache/index*/cache_disable_X Date: August 2008 KernelVersion: 2.6.27 Loading Documentation/ABI/testing/sysfs-kernel-slab +58 −51 Original line number Diff line number Diff line Loading @@ -45,8 +45,9 @@ KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, Christoph Lameter <cl@linux-foundation.org> Description: The alloc_fastpath file is read-only and specifies how many objects have been allocated using the fast path. The alloc_fastpath file shows how many objects have been allocated using the fast path. It can be written to clear the current count. Available when CONFIG_SLUB_STATS is enabled. What: /sys/kernel/slab/cache/alloc_from_partial Loading @@ -55,9 +56,10 @@ KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, Christoph Lameter <cl@linux-foundation.org> Description: The alloc_from_partial file is read-only and specifies how many times a cpu slab has been full and it has been refilled by using a slab from the list of partially used slabs. The alloc_from_partial file shows how many times a cpu slab has been full and it has been refilled by using a slab from the list of partially used slabs. It can be written to clear the current count. Available when CONFIG_SLUB_STATS is enabled. What: /sys/kernel/slab/cache/alloc_refill Loading @@ -66,9 +68,9 @@ KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, Christoph Lameter <cl@linux-foundation.org> Description: The alloc_refill file is read-only and specifies how many times the per-cpu freelist was empty but there were objects available as the result of remote cpu frees. The alloc_refill file shows how many times the per-cpu freelist was empty but there were objects available as the result of remote cpu frees. It can be written to clear the current count. Available when CONFIG_SLUB_STATS is enabled. What: /sys/kernel/slab/cache/alloc_slab Loading @@ -77,8 +79,9 @@ KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, Christoph Lameter <cl@linux-foundation.org> Description: The alloc_slab file is read-only and specifies how many times a new slab had to be allocated from the page allocator. The alloc_slab file is shows how many times a new slab had to be allocated from the page allocator. It can be written to clear the current count. Available when CONFIG_SLUB_STATS is enabled. What: /sys/kernel/slab/cache/alloc_slowpath Loading @@ -87,9 +90,10 @@ KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, Christoph Lameter <cl@linux-foundation.org> Description: The alloc_slowpath file is read-only and specifies how many objects have been allocated using the slow path because of a refill or allocation from a partial or new slab. The alloc_slowpath file shows how many objects have been allocated using the slow path because of a refill or allocation from a partial or new slab. It can be written to clear the current count. Available when CONFIG_SLUB_STATS is enabled. What: /sys/kernel/slab/cache/cache_dma Loading Loading @@ -117,10 +121,11 @@ KernelVersion: 2.6.31 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, Christoph Lameter <cl@linux-foundation.org> Description: The file cpuslab_flush is read-only and specifies how many times a cache's cpu slabs have been flushed as the result of destroying or shrinking a cache, a cpu going offline, or as the result of forcing an allocation from a certain node. The file cpuslab_flush shows how many times a cache's cpu slabs have been flushed as the result of destroying or shrinking a cache, a cpu going offline, or as the result of forcing an allocation from a certain node. It can be written to clear the current count. Available when CONFIG_SLUB_STATS is enabled. What: /sys/kernel/slab/cache/ctor Loading @@ -139,8 +144,8 @@ KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, Christoph Lameter <cl@linux-foundation.org> Description: The file deactivate_empty is read-only and specifies how many times an empty cpu slab was deactivated. The deactivate_empty file shows how many times an empty cpu slab was deactivated. It can be written to clear the current count. Available when CONFIG_SLUB_STATS is enabled. What: /sys/kernel/slab/cache/deactivate_full Loading @@ -149,8 +154,8 @@ KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, Christoph Lameter <cl@linux-foundation.org> Description: The file deactivate_full is read-only and specifies how many times a full cpu slab was deactivated. The deactivate_full file shows how many times a full cpu slab was deactivated. It can be written to clear the current count. Available when CONFIG_SLUB_STATS is enabled. What: /sys/kernel/slab/cache/deactivate_remote_frees Loading @@ -159,9 +164,9 @@ KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, Christoph Lameter <cl@linux-foundation.org> Description: The file deactivate_remote_frees is read-only and specifies how many times a cpu slab has been deactivated and contained free objects that were freed remotely. The deactivate_remote_frees file shows how many times a cpu slab has been deactivated and contained free objects that were freed remotely. It can be written to clear the current count. Available when CONFIG_SLUB_STATS is enabled. What: /sys/kernel/slab/cache/deactivate_to_head Loading @@ -170,9 +175,9 @@ KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, Christoph Lameter <cl@linux-foundation.org> Description: The file deactivate_to_head is read-only and specifies how many times a partial cpu slab was deactivated and added to the head of its node's partial list. The deactivate_to_head file shows how many times a partial cpu slab was deactivated and added to the head of its node's partial list. It can be written to clear the current count. Available when CONFIG_SLUB_STATS is enabled. What: /sys/kernel/slab/cache/deactivate_to_tail Loading @@ -181,9 +186,9 @@ KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, Christoph Lameter <cl@linux-foundation.org> Description: The file deactivate_to_tail is read-only and specifies how many times a partial cpu slab was deactivated and added to the tail of its node's partial list. The deactivate_to_tail file shows how many times a partial cpu slab was deactivated and added to the tail of its node's partial list. It can be written to clear the current count. Available when CONFIG_SLUB_STATS is enabled. What: /sys/kernel/slab/cache/destroy_by_rcu Loading @@ -201,9 +206,9 @@ KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, Christoph Lameter <cl@linux-foundation.org> Description: The file free_add_partial is read-only and specifies how many times an object has been freed in a full slab so that it had to added to its node's partial list. The free_add_partial file shows how many times an object has been freed in a full slab so that it had to added to its node's partial list. It can be written to clear the current count. Available when CONFIG_SLUB_STATS is enabled. What: /sys/kernel/slab/cache/free_calls Loading @@ -222,9 +227,9 @@ KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, Christoph Lameter <cl@linux-foundation.org> Description: The free_fastpath file is read-only and specifies how many objects have been freed using the fast path because it was an object from the cpu slab. The free_fastpath file shows how many objects have been freed using the fast path because it was an object from the cpu slab. It can be written to clear the current count. Available when CONFIG_SLUB_STATS is enabled. What: /sys/kernel/slab/cache/free_frozen Loading @@ -233,9 +238,9 @@ KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, Christoph Lameter <cl@linux-foundation.org> Description: The free_frozen file is read-only and specifies how many objects have been freed to a frozen slab (i.e. a remote cpu slab). The free_frozen file shows how many objects have been freed to a frozen slab (i.e. a remote cpu slab). It can be written to clear the current count. Available when CONFIG_SLUB_STATS is enabled. What: /sys/kernel/slab/cache/free_remove_partial Loading @@ -244,9 +249,10 @@ KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, Christoph Lameter <cl@linux-foundation.org> Description: The file free_remove_partial is read-only and specifies how many times an object has been freed to a now-empty slab so that it had to be removed from its node's partial list. The free_remove_partial file shows how many times an object has been freed to a now-empty slab so that it had to be removed from its node's partial list. It can be written to clear the current count. Available when CONFIG_SLUB_STATS is enabled. What: /sys/kernel/slab/cache/free_slab Loading @@ -255,8 +261,9 @@ KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, Christoph Lameter <cl@linux-foundation.org> Description: The free_slab file is read-only and specifies how many times an empty slab has been freed back to the page allocator. The free_slab file shows how many times an empty slab has been freed back to the page allocator. It can be written to clear the current count. Available when CONFIG_SLUB_STATS is enabled. What: /sys/kernel/slab/cache/free_slowpath Loading @@ -265,9 +272,9 @@ KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, Christoph Lameter <cl@linux-foundation.org> Description: The free_slowpath file is read-only and specifies how many objects have been freed using the slow path (i.e. to a full or partial slab). The free_slowpath file shows how many objects have been freed using the slow path (i.e. to a full or partial slab). It can be written to clear the current count. Available when CONFIG_SLUB_STATS is enabled. What: /sys/kernel/slab/cache/hwcache_align Loading Loading @@ -346,10 +353,10 @@ KernelVersion: 2.6.26 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, Christoph Lameter <cl@linux-foundation.org> Description: The file order_fallback is read-only and specifies how many times an allocation of a new slab has not been possible at the cache's order and instead fallen back to its minimum possible order. The order_fallback file shows how many times an allocation of a new slab has not been possible at the cache's order and instead fallen back to its minimum possible order. It can be written to clear the current count. Available when CONFIG_SLUB_STATS is enabled. What: /sys/kernel/slab/cache/partial Loading Documentation/arm/OMAP/DSS 0 → 100644 +317 −0 Original line number Diff line number Diff line OMAP2/3 Display Subsystem ------------------------- This is an almost total rewrite of the OMAP FB driver in drivers/video/omap (let's call it DSS1). The main differences between DSS1 and DSS2 are DSI, TV-out and multiple display support, but there are lots of small improvements also. The DSS2 driver (omapdss module) is in arch/arm/plat-omap/dss/, and the FB, panel and controller drivers are in drivers/video/omap2/. DSS1 and DSS2 live currently side by side, you can choose which one to use. Features -------- Working and tested features include: - MIPI DPI (parallel) output - MIPI DSI output in command mode - MIPI DBI (RFBI) output - SDI output - TV output - All pieces can be compiled as a module or inside kernel - Use DISPC to update any of the outputs - Use CPU to update RFBI or DSI output - OMAP DISPC planes - RGB16, RGB24 packed, RGB24 unpacked - YUV2, UYVY - Scaling - Adjusting DSS FCK to find a good pixel clock - Use DSI DPLL to create DSS FCK Tested boards include: - OMAP3 SDP board - Beagle board - N810 omapdss driver -------------- The DSS driver does not itself have any support for Linux framebuffer, V4L or such like the current ones, but it has an internal kernel API that upper level drivers can use. The DSS driver models OMAP's overlays, overlay managers and displays in a flexible way to enable non-common multi-display configuration. In addition to modelling the hardware overlays, omapdss supports virtual overlays and overlay managers. These can be used when updating a display with CPU or system DMA. Panel and controller drivers ---------------------------- The drivers implement panel or controller specific functionality and are not usually visible to users except through omapfb driver. They register themselves to the DSS driver. omapfb driver ------------- The omapfb driver implements arbitrary number of standard linux framebuffers. These framebuffers can be routed flexibly to any overlays, thus allowing very dynamic display architecture. The driver exports some omapfb specific ioctls, which are compatible with the ioctls in the old driver. The rest of the non standard features are exported via sysfs. Whether the final implementation will use sysfs, or ioctls, is still open. V4L2 drivers ------------ V4L2 is being implemented in TI. From omapdss point of view the V4L2 drivers should be similar to framebuffer driver. Architecture -------------------- Some clarification what the different components do: - Framebuffer is a memory area inside OMAP's SRAM/SDRAM that contains the pixel data for the image. Framebuffer has width and height and color depth. - Overlay defines where the pixels are read from and where they go on the screen. The overlay may be smaller than framebuffer, thus displaying only part of the framebuffer. The position of the overlay may be changed if the overlay is smaller than the display. - Overlay manager combines the overlays in to one image and feeds them to display. - Display is the actual physical display device. A framebuffer can be connected to multiple overlays to show the same pixel data on all of the overlays. Note that in this case the overlay input sizes must be the same, but, in case of video overlays, the output size can be different. Any framebuffer can be connected to any overlay. An overlay can be connected to one overlay manager. Also DISPC overlays can be connected only to DISPC overlay managers, and virtual overlays can be only connected to virtual overlays. An overlay manager can be connected to one display. There are certain restrictions which kinds of displays an overlay manager can be connected: - DISPC TV overlay manager can be only connected to TV display. - Virtual overlay managers can only be connected to DBI or DSI displays. - DISPC LCD overlay manager can be connected to all displays, except TV display. Sysfs ----- The sysfs interface is mainly used for testing. I don't think sysfs interface is the best for this in the final version, but I don't quite know what would be the best interfaces for these things. The sysfs interface is divided to two parts: DSS and FB. /sys/class/graphics/fb? directory: mirror 0=off, 1=on rotate Rotation 0-3 for 0, 90, 180, 270 degrees rotate_type 0 = DMA rotation, 1 = VRFB rotation overlays List of overlay numbers to which framebuffer pixels go phys_addr Physical address of the framebuffer virt_addr Virtual address of the framebuffer size Size of the framebuffer /sys/devices/platform/omapdss/overlay? directory: enabled 0=off, 1=on input_size width,height (ie. the framebuffer size) manager Destination overlay manager name name output_size width,height position x,y screen_width width global_alpha global alpha 0-255 0=transparent 255=opaque /sys/devices/platform/omapdss/manager? directory: display Destination display name alpha_blending_enabled 0=off, 1=on trans_key_enabled 0=off, 1=on trans_key_type gfx-destination, video-source trans_key_value transparency color key (RGB24) default_color default background color (RGB24) /sys/devices/platform/omapdss/display? directory: ctrl_name Controller name mirror 0=off, 1=on update_mode 0=off, 1=auto, 2=manual enabled 0=off, 1=on name rotate Rotation 0-3 for 0, 90, 180, 270 degrees timings Display timings (pixclock,xres/hfp/hbp/hsw,yres/vfp/vbp/vsw) When writing, two special timings are accepted for tv-out: "pal" and "ntsc" panel_name tear_elim Tearing elimination 0=off, 1=on There are also some debugfs files at <debugfs>/omapdss/ which show information about clocks and registers. Examples -------- The following definitions have been made for the examples below: ovl0=/sys/devices/platform/omapdss/overlay0 ovl1=/sys/devices/platform/omapdss/overlay1 ovl2=/sys/devices/platform/omapdss/overlay2 mgr0=/sys/devices/platform/omapdss/manager0 mgr1=/sys/devices/platform/omapdss/manager1 lcd=/sys/devices/platform/omapdss/display0 dvi=/sys/devices/platform/omapdss/display1 tv=/sys/devices/platform/omapdss/display2 fb0=/sys/class/graphics/fb0 fb1=/sys/class/graphics/fb1 fb2=/sys/class/graphics/fb2 Default setup on OMAP3 SDP -------------------------- Here's the default setup on OMAP3 SDP board. All planes go to LCD. DVI and TV-out are not in use. The columns from left to right are: framebuffers, overlays, overlay managers, displays. Framebuffers are handled by omapfb, and the rest by the DSS. FB0 --- GFX -\ DVI FB1 --- VID1 --+- LCD ---- LCD FB2 --- VID2 -/ TV ----- TV Example: Switch from LCD to DVI ---------------------- w=`cat $dvi/timings | cut -d "," -f 2 | cut -d "/" -f 1` h=`cat $dvi/timings | cut -d "," -f 3 | cut -d "/" -f 1` echo "0" > $lcd/enabled echo "" > $mgr0/display fbset -fb /dev/fb0 -xres $w -yres $h -vxres $w -vyres $h # at this point you have to switch the dvi/lcd dip-switch from the omap board echo "dvi" > $mgr0/display echo "1" > $dvi/enabled After this the configuration looks like: FB0 --- GFX -\ -- DVI FB1 --- VID1 --+- LCD -/ LCD FB2 --- VID2 -/ TV ----- TV Example: Clone GFX overlay to LCD and TV ------------------------------- w=`cat $tv/timings | cut -d "," -f 2 | cut -d "/" -f 1` h=`cat $tv/timings | cut -d "," -f 3 | cut -d "/" -f 1` echo "0" > $ovl0/enabled echo "0" > $ovl1/enabled echo "" > $fb1/overlays echo "0,1" > $fb0/overlays echo "$w,$h" > $ovl1/output_size echo "tv" > $ovl1/manager echo "1" > $ovl0/enabled echo "1" > $ovl1/enabled echo "1" > $tv/enabled After this the configuration looks like (only relevant parts shown): FB0 +-- GFX ---- LCD ---- LCD \- VID1 ---- TV ---- TV Misc notes ---------- OMAP FB allocates the framebuffer memory using the OMAP VRAM allocator. Using DSI DPLL to generate pixel clock it is possible produce the pixel clock of 86.5MHz (max possible), and with that you get 1280x1024@57 output from DVI. Rotation and mirroring currently only supports RGB565 and RGB8888 modes. VRFB does not support mirroring. VRFB rotation requires much more memory than non-rotated framebuffer, so you probably need to increase your vram setting before using VRFB rotation. Also, many applications may not work with VRFB if they do not pay attention to all framebuffer parameters. Kernel boot arguments --------------------- vram=<size> - Amount of total VRAM to preallocate. For example, "10M". omapfb allocates memory for framebuffers from VRAM. omapfb.mode=<display>:<mode>[,...] - Default video mode for specified displays. For example, "dvi:800x400MR-24@60". See drivers/video/modedb.c. There are also two special modes: "pal" and "ntsc" that can be used to tv out. omapfb.vram=<fbnum>:<size>[@<physaddr>][,...] - VRAM allocated for a framebuffer. Normally omapfb allocates vram depending on the display size. With this you can manually allocate more or define the physical address of each framebuffer. For example, "1:4M" to allocate 4M for fb1. omapfb.debug=<y|n> - Enable debug printing. You have to have OMAPFB debug support enabled in kernel config. omapfb.test=<y|n> - Draw test pattern to framebuffer whenever framebuffer settings change. You need to have OMAPFB debug support enabled in kernel config. omapfb.vrfb=<y|n> - Use VRFB rotation for all framebuffers. omapfb.rotate=<angle> - Default rotation applied to all framebuffers. 0 - 0 degree rotation 1 - 90 degree rotation 2 - 180 degree rotation 3 - 270 degree rotation omapfb.mirror=<y|n> - Default mirror for all framebuffers. Only works with DMA rotation. omapdss.def_disp=<display> - Name of default display, to which all overlays will be connected. Common examples are "lcd" or "tv". omapdss.debug=<y|n> - Enable debug printing. You have to have DSS debug support enabled in kernel config. TODO ---- DSS locking Error checking - Lots of checks are missing or implemented just as BUG() System DMA update for DSI - Can be used for RGB16 and RGB24P modes. Probably not for RGB24U (how to skip the empty byte?) OMAP1 support - Not sure if needed Loading
Documentation/ABI/testing/sysfs-bus-usb +13 −0 Original line number Diff line number Diff line Loading @@ -144,3 +144,16 @@ Description: Write a 1 to force the device to disconnect (equivalent to unplugging a wired USB device). What: /sys/bus/usb/drivers/.../remove_id Date: November 2009 Contact: CHENG Renquan <rqcheng@smu.edu.sg> Description: Writing a device ID to this file will remove an ID that was dynamically added via the new_id sysfs entry. The format for the device ID is: idVendor idProduct. After successfully removing an ID, the driver will no longer support the device. This is useful to ensure auto probing won't match the driver to the device. For example: # echo "046d c315" > /sys/bus/usb/drivers/foo/remove_id
Documentation/ABI/testing/sysfs-class-uwb_rc-wusbhc +13 −0 Original line number Diff line number Diff line Loading @@ -23,3 +23,16 @@ Description: Since this relates to security (specifically, the lifetime of PTKs and GTKs) it should not be changed from the default. What: /sys/class/uwb_rc/uwbN/wusbhc/wusb_phy_rate Date: August 2009 KernelVersion: 2.6.32 Contact: David Vrabel <david.vrabel@csr.com> Description: The maximum PHY rate to use for all connected devices. This is only of limited use for testing and development as the hardware's automatic rate adaptation is better then this simple control. Refer to [ECMA-368] section 10.3.1.1 for the value to use.
Documentation/ABI/testing/sysfs-devices-system-cpu +33 −0 Original line number Diff line number Diff line Loading @@ -62,6 +62,21 @@ Description: CPU topology files that describe kernel limits related to See Documentation/cputopology.txt for more information. What: /sys/devices/system/cpu/probe /sys/devices/system/cpu/release Date: November 2009 Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org> Description: Dynamic addition and removal of CPU's. This is not hotplug removal, this is meant complete removal/addition of the CPU from the system. probe: writes to this file will dynamically add a CPU to the system. Information written to the file to add CPU's is architecture specific. release: writes to this file dynamically remove a CPU from the system. Information writtento the file to remove CPU's is architecture specific. What: /sys/devices/system/cpu/cpu#/node Date: October 2009 Loading Loading @@ -136,6 +151,24 @@ Description: Discover cpuidle policy and mechanism See files in Documentation/cpuidle/ for more information. What: /sys/devices/system/cpu/cpu#/cpufreq/* Date: pre-git history Contact: cpufreq@vger.kernel.org Description: Discover and change clock speed of CPUs Clock scaling allows you to change the clock speed of the CPUs on the fly. This is a nice method to save battery power, because the lower the clock speed, the less power the CPU consumes. There are many knobs to tweak in this directory. See files in Documentation/cpu-freq/ for more information. In particular, read Documentation/cpu-freq/user-guide.txt to learn how to control the knobs. What: /sys/devices/system/cpu/cpu*/cache/index*/cache_disable_X Date: August 2008 KernelVersion: 2.6.27 Loading
Documentation/ABI/testing/sysfs-kernel-slab +58 −51 Original line number Diff line number Diff line Loading @@ -45,8 +45,9 @@ KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, Christoph Lameter <cl@linux-foundation.org> Description: The alloc_fastpath file is read-only and specifies how many objects have been allocated using the fast path. The alloc_fastpath file shows how many objects have been allocated using the fast path. It can be written to clear the current count. Available when CONFIG_SLUB_STATS is enabled. What: /sys/kernel/slab/cache/alloc_from_partial Loading @@ -55,9 +56,10 @@ KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, Christoph Lameter <cl@linux-foundation.org> Description: The alloc_from_partial file is read-only and specifies how many times a cpu slab has been full and it has been refilled by using a slab from the list of partially used slabs. The alloc_from_partial file shows how many times a cpu slab has been full and it has been refilled by using a slab from the list of partially used slabs. It can be written to clear the current count. Available when CONFIG_SLUB_STATS is enabled. What: /sys/kernel/slab/cache/alloc_refill Loading @@ -66,9 +68,9 @@ KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, Christoph Lameter <cl@linux-foundation.org> Description: The alloc_refill file is read-only and specifies how many times the per-cpu freelist was empty but there were objects available as the result of remote cpu frees. The alloc_refill file shows how many times the per-cpu freelist was empty but there were objects available as the result of remote cpu frees. It can be written to clear the current count. Available when CONFIG_SLUB_STATS is enabled. What: /sys/kernel/slab/cache/alloc_slab Loading @@ -77,8 +79,9 @@ KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, Christoph Lameter <cl@linux-foundation.org> Description: The alloc_slab file is read-only and specifies how many times a new slab had to be allocated from the page allocator. The alloc_slab file is shows how many times a new slab had to be allocated from the page allocator. It can be written to clear the current count. Available when CONFIG_SLUB_STATS is enabled. What: /sys/kernel/slab/cache/alloc_slowpath Loading @@ -87,9 +90,10 @@ KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, Christoph Lameter <cl@linux-foundation.org> Description: The alloc_slowpath file is read-only and specifies how many objects have been allocated using the slow path because of a refill or allocation from a partial or new slab. The alloc_slowpath file shows how many objects have been allocated using the slow path because of a refill or allocation from a partial or new slab. It can be written to clear the current count. Available when CONFIG_SLUB_STATS is enabled. What: /sys/kernel/slab/cache/cache_dma Loading Loading @@ -117,10 +121,11 @@ KernelVersion: 2.6.31 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, Christoph Lameter <cl@linux-foundation.org> Description: The file cpuslab_flush is read-only and specifies how many times a cache's cpu slabs have been flushed as the result of destroying or shrinking a cache, a cpu going offline, or as the result of forcing an allocation from a certain node. The file cpuslab_flush shows how many times a cache's cpu slabs have been flushed as the result of destroying or shrinking a cache, a cpu going offline, or as the result of forcing an allocation from a certain node. It can be written to clear the current count. Available when CONFIG_SLUB_STATS is enabled. What: /sys/kernel/slab/cache/ctor Loading @@ -139,8 +144,8 @@ KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, Christoph Lameter <cl@linux-foundation.org> Description: The file deactivate_empty is read-only and specifies how many times an empty cpu slab was deactivated. The deactivate_empty file shows how many times an empty cpu slab was deactivated. It can be written to clear the current count. Available when CONFIG_SLUB_STATS is enabled. What: /sys/kernel/slab/cache/deactivate_full Loading @@ -149,8 +154,8 @@ KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, Christoph Lameter <cl@linux-foundation.org> Description: The file deactivate_full is read-only and specifies how many times a full cpu slab was deactivated. The deactivate_full file shows how many times a full cpu slab was deactivated. It can be written to clear the current count. Available when CONFIG_SLUB_STATS is enabled. What: /sys/kernel/slab/cache/deactivate_remote_frees Loading @@ -159,9 +164,9 @@ KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, Christoph Lameter <cl@linux-foundation.org> Description: The file deactivate_remote_frees is read-only and specifies how many times a cpu slab has been deactivated and contained free objects that were freed remotely. The deactivate_remote_frees file shows how many times a cpu slab has been deactivated and contained free objects that were freed remotely. It can be written to clear the current count. Available when CONFIG_SLUB_STATS is enabled. What: /sys/kernel/slab/cache/deactivate_to_head Loading @@ -170,9 +175,9 @@ KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, Christoph Lameter <cl@linux-foundation.org> Description: The file deactivate_to_head is read-only and specifies how many times a partial cpu slab was deactivated and added to the head of its node's partial list. The deactivate_to_head file shows how many times a partial cpu slab was deactivated and added to the head of its node's partial list. It can be written to clear the current count. Available when CONFIG_SLUB_STATS is enabled. What: /sys/kernel/slab/cache/deactivate_to_tail Loading @@ -181,9 +186,9 @@ KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, Christoph Lameter <cl@linux-foundation.org> Description: The file deactivate_to_tail is read-only and specifies how many times a partial cpu slab was deactivated and added to the tail of its node's partial list. The deactivate_to_tail file shows how many times a partial cpu slab was deactivated and added to the tail of its node's partial list. It can be written to clear the current count. Available when CONFIG_SLUB_STATS is enabled. What: /sys/kernel/slab/cache/destroy_by_rcu Loading @@ -201,9 +206,9 @@ KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, Christoph Lameter <cl@linux-foundation.org> Description: The file free_add_partial is read-only and specifies how many times an object has been freed in a full slab so that it had to added to its node's partial list. The free_add_partial file shows how many times an object has been freed in a full slab so that it had to added to its node's partial list. It can be written to clear the current count. Available when CONFIG_SLUB_STATS is enabled. What: /sys/kernel/slab/cache/free_calls Loading @@ -222,9 +227,9 @@ KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, Christoph Lameter <cl@linux-foundation.org> Description: The free_fastpath file is read-only and specifies how many objects have been freed using the fast path because it was an object from the cpu slab. The free_fastpath file shows how many objects have been freed using the fast path because it was an object from the cpu slab. It can be written to clear the current count. Available when CONFIG_SLUB_STATS is enabled. What: /sys/kernel/slab/cache/free_frozen Loading @@ -233,9 +238,9 @@ KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, Christoph Lameter <cl@linux-foundation.org> Description: The free_frozen file is read-only and specifies how many objects have been freed to a frozen slab (i.e. a remote cpu slab). The free_frozen file shows how many objects have been freed to a frozen slab (i.e. a remote cpu slab). It can be written to clear the current count. Available when CONFIG_SLUB_STATS is enabled. What: /sys/kernel/slab/cache/free_remove_partial Loading @@ -244,9 +249,10 @@ KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, Christoph Lameter <cl@linux-foundation.org> Description: The file free_remove_partial is read-only and specifies how many times an object has been freed to a now-empty slab so that it had to be removed from its node's partial list. The free_remove_partial file shows how many times an object has been freed to a now-empty slab so that it had to be removed from its node's partial list. It can be written to clear the current count. Available when CONFIG_SLUB_STATS is enabled. What: /sys/kernel/slab/cache/free_slab Loading @@ -255,8 +261,9 @@ KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, Christoph Lameter <cl@linux-foundation.org> Description: The free_slab file is read-only and specifies how many times an empty slab has been freed back to the page allocator. The free_slab file shows how many times an empty slab has been freed back to the page allocator. It can be written to clear the current count. Available when CONFIG_SLUB_STATS is enabled. What: /sys/kernel/slab/cache/free_slowpath Loading @@ -265,9 +272,9 @@ KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, Christoph Lameter <cl@linux-foundation.org> Description: The free_slowpath file is read-only and specifies how many objects have been freed using the slow path (i.e. to a full or partial slab). The free_slowpath file shows how many objects have been freed using the slow path (i.e. to a full or partial slab). It can be written to clear the current count. Available when CONFIG_SLUB_STATS is enabled. What: /sys/kernel/slab/cache/hwcache_align Loading Loading @@ -346,10 +353,10 @@ KernelVersion: 2.6.26 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, Christoph Lameter <cl@linux-foundation.org> Description: The file order_fallback is read-only and specifies how many times an allocation of a new slab has not been possible at the cache's order and instead fallen back to its minimum possible order. The order_fallback file shows how many times an allocation of a new slab has not been possible at the cache's order and instead fallen back to its minimum possible order. It can be written to clear the current count. Available when CONFIG_SLUB_STATS is enabled. What: /sys/kernel/slab/cache/partial Loading
Documentation/arm/OMAP/DSS 0 → 100644 +317 −0 Original line number Diff line number Diff line OMAP2/3 Display Subsystem ------------------------- This is an almost total rewrite of the OMAP FB driver in drivers/video/omap (let's call it DSS1). The main differences between DSS1 and DSS2 are DSI, TV-out and multiple display support, but there are lots of small improvements also. The DSS2 driver (omapdss module) is in arch/arm/plat-omap/dss/, and the FB, panel and controller drivers are in drivers/video/omap2/. DSS1 and DSS2 live currently side by side, you can choose which one to use. Features -------- Working and tested features include: - MIPI DPI (parallel) output - MIPI DSI output in command mode - MIPI DBI (RFBI) output - SDI output - TV output - All pieces can be compiled as a module or inside kernel - Use DISPC to update any of the outputs - Use CPU to update RFBI or DSI output - OMAP DISPC planes - RGB16, RGB24 packed, RGB24 unpacked - YUV2, UYVY - Scaling - Adjusting DSS FCK to find a good pixel clock - Use DSI DPLL to create DSS FCK Tested boards include: - OMAP3 SDP board - Beagle board - N810 omapdss driver -------------- The DSS driver does not itself have any support for Linux framebuffer, V4L or such like the current ones, but it has an internal kernel API that upper level drivers can use. The DSS driver models OMAP's overlays, overlay managers and displays in a flexible way to enable non-common multi-display configuration. In addition to modelling the hardware overlays, omapdss supports virtual overlays and overlay managers. These can be used when updating a display with CPU or system DMA. Panel and controller drivers ---------------------------- The drivers implement panel or controller specific functionality and are not usually visible to users except through omapfb driver. They register themselves to the DSS driver. omapfb driver ------------- The omapfb driver implements arbitrary number of standard linux framebuffers. These framebuffers can be routed flexibly to any overlays, thus allowing very dynamic display architecture. The driver exports some omapfb specific ioctls, which are compatible with the ioctls in the old driver. The rest of the non standard features are exported via sysfs. Whether the final implementation will use sysfs, or ioctls, is still open. V4L2 drivers ------------ V4L2 is being implemented in TI. From omapdss point of view the V4L2 drivers should be similar to framebuffer driver. Architecture -------------------- Some clarification what the different components do: - Framebuffer is a memory area inside OMAP's SRAM/SDRAM that contains the pixel data for the image. Framebuffer has width and height and color depth. - Overlay defines where the pixels are read from and where they go on the screen. The overlay may be smaller than framebuffer, thus displaying only part of the framebuffer. The position of the overlay may be changed if the overlay is smaller than the display. - Overlay manager combines the overlays in to one image and feeds them to display. - Display is the actual physical display device. A framebuffer can be connected to multiple overlays to show the same pixel data on all of the overlays. Note that in this case the overlay input sizes must be the same, but, in case of video overlays, the output size can be different. Any framebuffer can be connected to any overlay. An overlay can be connected to one overlay manager. Also DISPC overlays can be connected only to DISPC overlay managers, and virtual overlays can be only connected to virtual overlays. An overlay manager can be connected to one display. There are certain restrictions which kinds of displays an overlay manager can be connected: - DISPC TV overlay manager can be only connected to TV display. - Virtual overlay managers can only be connected to DBI or DSI displays. - DISPC LCD overlay manager can be connected to all displays, except TV display. Sysfs ----- The sysfs interface is mainly used for testing. I don't think sysfs interface is the best for this in the final version, but I don't quite know what would be the best interfaces for these things. The sysfs interface is divided to two parts: DSS and FB. /sys/class/graphics/fb? directory: mirror 0=off, 1=on rotate Rotation 0-3 for 0, 90, 180, 270 degrees rotate_type 0 = DMA rotation, 1 = VRFB rotation overlays List of overlay numbers to which framebuffer pixels go phys_addr Physical address of the framebuffer virt_addr Virtual address of the framebuffer size Size of the framebuffer /sys/devices/platform/omapdss/overlay? directory: enabled 0=off, 1=on input_size width,height (ie. the framebuffer size) manager Destination overlay manager name name output_size width,height position x,y screen_width width global_alpha global alpha 0-255 0=transparent 255=opaque /sys/devices/platform/omapdss/manager? directory: display Destination display name alpha_blending_enabled 0=off, 1=on trans_key_enabled 0=off, 1=on trans_key_type gfx-destination, video-source trans_key_value transparency color key (RGB24) default_color default background color (RGB24) /sys/devices/platform/omapdss/display? directory: ctrl_name Controller name mirror 0=off, 1=on update_mode 0=off, 1=auto, 2=manual enabled 0=off, 1=on name rotate Rotation 0-3 for 0, 90, 180, 270 degrees timings Display timings (pixclock,xres/hfp/hbp/hsw,yres/vfp/vbp/vsw) When writing, two special timings are accepted for tv-out: "pal" and "ntsc" panel_name tear_elim Tearing elimination 0=off, 1=on There are also some debugfs files at <debugfs>/omapdss/ which show information about clocks and registers. Examples -------- The following definitions have been made for the examples below: ovl0=/sys/devices/platform/omapdss/overlay0 ovl1=/sys/devices/platform/omapdss/overlay1 ovl2=/sys/devices/platform/omapdss/overlay2 mgr0=/sys/devices/platform/omapdss/manager0 mgr1=/sys/devices/platform/omapdss/manager1 lcd=/sys/devices/platform/omapdss/display0 dvi=/sys/devices/platform/omapdss/display1 tv=/sys/devices/platform/omapdss/display2 fb0=/sys/class/graphics/fb0 fb1=/sys/class/graphics/fb1 fb2=/sys/class/graphics/fb2 Default setup on OMAP3 SDP -------------------------- Here's the default setup on OMAP3 SDP board. All planes go to LCD. DVI and TV-out are not in use. The columns from left to right are: framebuffers, overlays, overlay managers, displays. Framebuffers are handled by omapfb, and the rest by the DSS. FB0 --- GFX -\ DVI FB1 --- VID1 --+- LCD ---- LCD FB2 --- VID2 -/ TV ----- TV Example: Switch from LCD to DVI ---------------------- w=`cat $dvi/timings | cut -d "," -f 2 | cut -d "/" -f 1` h=`cat $dvi/timings | cut -d "," -f 3 | cut -d "/" -f 1` echo "0" > $lcd/enabled echo "" > $mgr0/display fbset -fb /dev/fb0 -xres $w -yres $h -vxres $w -vyres $h # at this point you have to switch the dvi/lcd dip-switch from the omap board echo "dvi" > $mgr0/display echo "1" > $dvi/enabled After this the configuration looks like: FB0 --- GFX -\ -- DVI FB1 --- VID1 --+- LCD -/ LCD FB2 --- VID2 -/ TV ----- TV Example: Clone GFX overlay to LCD and TV ------------------------------- w=`cat $tv/timings | cut -d "," -f 2 | cut -d "/" -f 1` h=`cat $tv/timings | cut -d "," -f 3 | cut -d "/" -f 1` echo "0" > $ovl0/enabled echo "0" > $ovl1/enabled echo "" > $fb1/overlays echo "0,1" > $fb0/overlays echo "$w,$h" > $ovl1/output_size echo "tv" > $ovl1/manager echo "1" > $ovl0/enabled echo "1" > $ovl1/enabled echo "1" > $tv/enabled After this the configuration looks like (only relevant parts shown): FB0 +-- GFX ---- LCD ---- LCD \- VID1 ---- TV ---- TV Misc notes ---------- OMAP FB allocates the framebuffer memory using the OMAP VRAM allocator. Using DSI DPLL to generate pixel clock it is possible produce the pixel clock of 86.5MHz (max possible), and with that you get 1280x1024@57 output from DVI. Rotation and mirroring currently only supports RGB565 and RGB8888 modes. VRFB does not support mirroring. VRFB rotation requires much more memory than non-rotated framebuffer, so you probably need to increase your vram setting before using VRFB rotation. Also, many applications may not work with VRFB if they do not pay attention to all framebuffer parameters. Kernel boot arguments --------------------- vram=<size> - Amount of total VRAM to preallocate. For example, "10M". omapfb allocates memory for framebuffers from VRAM. omapfb.mode=<display>:<mode>[,...] - Default video mode for specified displays. For example, "dvi:800x400MR-24@60". See drivers/video/modedb.c. There are also two special modes: "pal" and "ntsc" that can be used to tv out. omapfb.vram=<fbnum>:<size>[@<physaddr>][,...] - VRAM allocated for a framebuffer. Normally omapfb allocates vram depending on the display size. With this you can manually allocate more or define the physical address of each framebuffer. For example, "1:4M" to allocate 4M for fb1. omapfb.debug=<y|n> - Enable debug printing. You have to have OMAPFB debug support enabled in kernel config. omapfb.test=<y|n> - Draw test pattern to framebuffer whenever framebuffer settings change. You need to have OMAPFB debug support enabled in kernel config. omapfb.vrfb=<y|n> - Use VRFB rotation for all framebuffers. omapfb.rotate=<angle> - Default rotation applied to all framebuffers. 0 - 0 degree rotation 1 - 90 degree rotation 2 - 180 degree rotation 3 - 270 degree rotation omapfb.mirror=<y|n> - Default mirror for all framebuffers. Only works with DMA rotation. omapdss.def_disp=<display> - Name of default display, to which all overlays will be connected. Common examples are "lcd" or "tv". omapdss.debug=<y|n> - Enable debug printing. You have to have DSS debug support enabled in kernel config. TODO ---- DSS locking Error checking - Lots of checks are missing or implemented just as BUG() System DMA update for DSI - Can be used for RGB16 and RGB24P modes. Probably not for RGB24U (how to skip the empty byte?) OMAP1 support - Not sure if needed
