Loading Documentation/DocBook/kernel-api.tmpl +55 −1 Original line number Diff line number Diff line Loading @@ -119,7 +119,7 @@ X!Ilib/string.c !Elib/string.c </sect1> <sect1><title>Bit Operations</title> !Iinclude/asm-x86/bitops_32.h !Iinclude/asm-x86/bitops.h </sect1> </chapter> Loading Loading @@ -645,4 +645,58 @@ X!Idrivers/video/console/fonts.c !Edrivers/i2c/i2c-core.c </chapter> <chapter id="clk"> <title>Clock Framework</title> <para> The clock framework defines programming interfaces to support software management of the system clock tree. This framework is widely used with System-On-Chip (SOC) platforms to support power management and various devices which may need custom clock rates. Note that these "clocks" don't relate to timekeeping or real time clocks (RTCs), each of which have separate frameworks. These <structname>struct clk</structname> instances may be used to manage for example a 96 MHz signal that is used to shift bits into and out of peripherals or busses, or otherwise trigger synchronous state machine transitions in system hardware. </para> <para> Power management is supported by explicit software clock gating: unused clocks are disabled, so the system doesn't waste power changing the state of transistors that aren't in active use. On some systems this may be backed by hardware clock gating, where clocks are gated without being disabled in software. Sections of chips that are powered but not clocked may be able to retain their last state. This low power state is often called a <emphasis>retention mode</emphasis>. This mode still incurs leakage currents, especially with finer circuit geometries, but for CMOS circuits power is mostly used by clocked state changes. </para> <para> Power-aware drivers only enable their clocks when the device they manage is in active use. Also, system sleep states often differ according to which clock domains are active: while a "standby" state may allow wakeup from several active domains, a "mem" (suspend-to-RAM) state may require a more wholesale shutdown of clocks derived from higher speed PLLs and oscillators, limiting the number of possible wakeup event sources. A driver's suspend method may need to be aware of system-specific clock constraints on the target sleep state. </para> <para> Some platforms support programmable clock generators. These can be used by external chips of various kinds, such as other CPUs, multimedia codecs, and devices with strict requirements for interface clocking. </para> !Iinclude/linux/clk.h </chapter> </book> Documentation/fb/gxfb.txt 0 → 100644 +52 −0 Original line number Diff line number Diff line [This file is cloned from VesaFB/aty128fb] What is gxfb? ================= This is a graphics framebuffer driver for AMD Geode GX2 based processors. Advantages: * No need to use AMD's VSA code (or other VESA emulation layer) in the BIOS. * It provides a nice large console (128 cols + 48 lines with 1024x768) without using tiny, unreadable fonts. * You can run XF68_FBDev on top of /dev/fb0 * Most important: boot logo :-) Disadvantages: * graphic mode is slower than text mode... How to use it? ============== Switching modes is done using gxfb.mode_option=<resolution>... boot parameter or using `fbset' program. See Documentation/fb/modedb.txt for more information on modedb resolutions. X11 === XF68_FBDev should generally work fine, but it is non-accelerated. Configuration ============= You can pass kernel command line options to gxfb with gxfb.<option>. For example, gxfb.mode_option=800x600@75. Accepted options: mode_option - specify the video mode. Of the form <x>x<y>[-<bpp>][@<refresh>] vram - size of video ram (normally auto-detected) vt_switch - enable vt switching during suspend/resume. The vt switch is slow, but harmless. -- Andres Salomon <dilinger@debian.org> Documentation/fb/intelfb.txt +2 −0 Original line number Diff line number Diff line Loading @@ -14,6 +14,8 @@ graphics devices. These would include: Intel 915GM Intel 945G Intel 945GM Intel 965G Intel 965GM B. List of available options Loading Documentation/fb/lxfb.txt 0 → 100644 +52 −0 Original line number Diff line number Diff line [This file is cloned from VesaFB/aty128fb] What is lxfb? ================= This is a graphics framebuffer driver for AMD Geode LX based processors. Advantages: * No need to use AMD's VSA code (or other VESA emulation layer) in the BIOS. * It provides a nice large console (128 cols + 48 lines with 1024x768) without using tiny, unreadable fonts. * You can run XF68_FBDev on top of /dev/fb0 * Most important: boot logo :-) Disadvantages: * graphic mode is slower than text mode... How to use it? ============== Switching modes is done using lxfb.mode_option=<resolution>... boot parameter or using `fbset' program. See Documentation/fb/modedb.txt for more information on modedb resolutions. X11 === XF68_FBDev should generally work fine, but it is non-accelerated. Configuration ============= You can pass kernel command line options to lxfb with lxfb.<option>. For example, lxfb.mode_option=800x600@75. Accepted options: mode_option - specify the video mode. Of the form <x>x<y>[-<bpp>][@<refresh>] vram - size of video ram (normally auto-detected) vt_switch - enable vt switching during suspend/resume. The vt switch is slow, but harmless. -- Andres Salomon <dilinger@debian.org> Documentation/fb/metronomefb.txt +7 −9 Original line number Diff line number Diff line Metronomefb ----------- Maintained by Jaya Kumar <jayakumar.lkml.gmail.com> Last revised: Nov 20, 2007 Last revised: Mar 10, 2008 Metronomefb is a driver for the Metronome display controller. The controller is from E-Ink Corporation. It is intended to be used to drive the E-Ink Loading @@ -11,20 +11,18 @@ display media here http://www.e-ink.com/products/matrix/metronome.html . Metronome is interfaced to the host CPU through the AMLCD interface. The host CPU generates the control information and the image in a framebuffer which is then delivered to the AMLCD interface by a host specific method. Currently, that's implemented for the PXA's LCDC controller. The display and error status are each pulled through individual GPIOs. The display and error status are each pulled through individual GPIOs. Metronomefb was written for the PXA255/gumstix/lyre combination and therefore currently has board set specific code in it. If other boards based on other architectures are available, then the host specific code can be separated and abstracted out. Metronomefb is platform independent and depends on a board specific driver to do all physical IO work. Currently, an example is implemented for the PXA board used in the AM-200 EPD devkit. This example is am200epd.c Metronomefb requires waveform information which is delivered via the AMLCD interface to the metronome controller. The waveform information is expected to be delivered from userspace via the firmware class interface. The waveform file can be compressed as long as your udev or hotplug script is aware of the need to uncompress it before delivering it. metronomefb will ask for waveform.wbf which would typically go into /lib/firmware/waveform.wbf depending on your to uncompress it before delivering it. metronomefb will ask for metronome.wbf which would typically go into /lib/firmware/metronome.wbf depending on your udev/hotplug setup. I have only tested with a single waveform file which was originally labeled 23P01201_60_WT0107_MTC. I do not know what it stands for. Caution should be exercised when manipulating the waveform as there may be Loading Loading
Documentation/DocBook/kernel-api.tmpl +55 −1 Original line number Diff line number Diff line Loading @@ -119,7 +119,7 @@ X!Ilib/string.c !Elib/string.c </sect1> <sect1><title>Bit Operations</title> !Iinclude/asm-x86/bitops_32.h !Iinclude/asm-x86/bitops.h </sect1> </chapter> Loading Loading @@ -645,4 +645,58 @@ X!Idrivers/video/console/fonts.c !Edrivers/i2c/i2c-core.c </chapter> <chapter id="clk"> <title>Clock Framework</title> <para> The clock framework defines programming interfaces to support software management of the system clock tree. This framework is widely used with System-On-Chip (SOC) platforms to support power management and various devices which may need custom clock rates. Note that these "clocks" don't relate to timekeeping or real time clocks (RTCs), each of which have separate frameworks. These <structname>struct clk</structname> instances may be used to manage for example a 96 MHz signal that is used to shift bits into and out of peripherals or busses, or otherwise trigger synchronous state machine transitions in system hardware. </para> <para> Power management is supported by explicit software clock gating: unused clocks are disabled, so the system doesn't waste power changing the state of transistors that aren't in active use. On some systems this may be backed by hardware clock gating, where clocks are gated without being disabled in software. Sections of chips that are powered but not clocked may be able to retain their last state. This low power state is often called a <emphasis>retention mode</emphasis>. This mode still incurs leakage currents, especially with finer circuit geometries, but for CMOS circuits power is mostly used by clocked state changes. </para> <para> Power-aware drivers only enable their clocks when the device they manage is in active use. Also, system sleep states often differ according to which clock domains are active: while a "standby" state may allow wakeup from several active domains, a "mem" (suspend-to-RAM) state may require a more wholesale shutdown of clocks derived from higher speed PLLs and oscillators, limiting the number of possible wakeup event sources. A driver's suspend method may need to be aware of system-specific clock constraints on the target sleep state. </para> <para> Some platforms support programmable clock generators. These can be used by external chips of various kinds, such as other CPUs, multimedia codecs, and devices with strict requirements for interface clocking. </para> !Iinclude/linux/clk.h </chapter> </book>
Documentation/fb/gxfb.txt 0 → 100644 +52 −0 Original line number Diff line number Diff line [This file is cloned from VesaFB/aty128fb] What is gxfb? ================= This is a graphics framebuffer driver for AMD Geode GX2 based processors. Advantages: * No need to use AMD's VSA code (or other VESA emulation layer) in the BIOS. * It provides a nice large console (128 cols + 48 lines with 1024x768) without using tiny, unreadable fonts. * You can run XF68_FBDev on top of /dev/fb0 * Most important: boot logo :-) Disadvantages: * graphic mode is slower than text mode... How to use it? ============== Switching modes is done using gxfb.mode_option=<resolution>... boot parameter or using `fbset' program. See Documentation/fb/modedb.txt for more information on modedb resolutions. X11 === XF68_FBDev should generally work fine, but it is non-accelerated. Configuration ============= You can pass kernel command line options to gxfb with gxfb.<option>. For example, gxfb.mode_option=800x600@75. Accepted options: mode_option - specify the video mode. Of the form <x>x<y>[-<bpp>][@<refresh>] vram - size of video ram (normally auto-detected) vt_switch - enable vt switching during suspend/resume. The vt switch is slow, but harmless. -- Andres Salomon <dilinger@debian.org>
Documentation/fb/intelfb.txt +2 −0 Original line number Diff line number Diff line Loading @@ -14,6 +14,8 @@ graphics devices. These would include: Intel 915GM Intel 945G Intel 945GM Intel 965G Intel 965GM B. List of available options Loading
Documentation/fb/lxfb.txt 0 → 100644 +52 −0 Original line number Diff line number Diff line [This file is cloned from VesaFB/aty128fb] What is lxfb? ================= This is a graphics framebuffer driver for AMD Geode LX based processors. Advantages: * No need to use AMD's VSA code (or other VESA emulation layer) in the BIOS. * It provides a nice large console (128 cols + 48 lines with 1024x768) without using tiny, unreadable fonts. * You can run XF68_FBDev on top of /dev/fb0 * Most important: boot logo :-) Disadvantages: * graphic mode is slower than text mode... How to use it? ============== Switching modes is done using lxfb.mode_option=<resolution>... boot parameter or using `fbset' program. See Documentation/fb/modedb.txt for more information on modedb resolutions. X11 === XF68_FBDev should generally work fine, but it is non-accelerated. Configuration ============= You can pass kernel command line options to lxfb with lxfb.<option>. For example, lxfb.mode_option=800x600@75. Accepted options: mode_option - specify the video mode. Of the form <x>x<y>[-<bpp>][@<refresh>] vram - size of video ram (normally auto-detected) vt_switch - enable vt switching during suspend/resume. The vt switch is slow, but harmless. -- Andres Salomon <dilinger@debian.org>
Documentation/fb/metronomefb.txt +7 −9 Original line number Diff line number Diff line Metronomefb ----------- Maintained by Jaya Kumar <jayakumar.lkml.gmail.com> Last revised: Nov 20, 2007 Last revised: Mar 10, 2008 Metronomefb is a driver for the Metronome display controller. The controller is from E-Ink Corporation. It is intended to be used to drive the E-Ink Loading @@ -11,20 +11,18 @@ display media here http://www.e-ink.com/products/matrix/metronome.html . Metronome is interfaced to the host CPU through the AMLCD interface. The host CPU generates the control information and the image in a framebuffer which is then delivered to the AMLCD interface by a host specific method. Currently, that's implemented for the PXA's LCDC controller. The display and error status are each pulled through individual GPIOs. The display and error status are each pulled through individual GPIOs. Metronomefb was written for the PXA255/gumstix/lyre combination and therefore currently has board set specific code in it. If other boards based on other architectures are available, then the host specific code can be separated and abstracted out. Metronomefb is platform independent and depends on a board specific driver to do all physical IO work. Currently, an example is implemented for the PXA board used in the AM-200 EPD devkit. This example is am200epd.c Metronomefb requires waveform information which is delivered via the AMLCD interface to the metronome controller. The waveform information is expected to be delivered from userspace via the firmware class interface. The waveform file can be compressed as long as your udev or hotplug script is aware of the need to uncompress it before delivering it. metronomefb will ask for waveform.wbf which would typically go into /lib/firmware/waveform.wbf depending on your to uncompress it before delivering it. metronomefb will ask for metronome.wbf which would typically go into /lib/firmware/metronome.wbf depending on your udev/hotplug setup. I have only tested with a single waveform file which was originally labeled 23P01201_60_WT0107_MTC. I do not know what it stands for. Caution should be exercised when manipulating the waveform as there may be Loading
