Loading Documentation/SubmittingPatches +1 −1 Original line number Diff line number Diff line Loading @@ -512,7 +512,7 @@ They provide type safety, have no length limitations, no formatting limitations, and under gcc they are as cheap as macros. Macros should only be used for cases where a static inline is clearly suboptimal [there a few, isolated cases of this in fast paths], suboptimal [there are a few, isolated cases of this in fast paths], or where it is impossible to use a static inline function [such as string-izing]. Loading Documentation/fb/cmap_xfbdev.txt 0 → 100644 +53 −0 Original line number Diff line number Diff line Understanding fbdev's cmap -------------------------- These notes explain how X's dix layer uses fbdev's cmap structures. *. example of relevant structures in fbdev as used for a 3-bit grayscale cmap struct fb_var_screeninfo { .bits_per_pixel = 8, .grayscale = 1, .red = { 4, 3, 0 }, .green = { 0, 0, 0 }, .blue = { 0, 0, 0 }, } struct fb_fix_screeninfo { .visual = FB_VISUAL_STATIC_PSEUDOCOLOR, } for (i = 0; i < 8; i++) info->cmap.red[i] = (((2*i)+1)*(0xFFFF))/16; memcpy(info->cmap.green, info->cmap.red, sizeof(u16)*8); memcpy(info->cmap.blue, info->cmap.red, sizeof(u16)*8); *. X11 apps do something like the following when trying to use grayscale. for (i=0; i < 8; i++) { char colorspec[64]; memset(colorspec,0,64); sprintf(colorspec, "rgb:%x/%x/%x", i*36,i*36,i*36); if (!XParseColor(outputDisplay, testColormap, colorspec, &wantedColor)) printf("Can't get color %s\n",colorspec); XAllocColor(outputDisplay, testColormap, &wantedColor); grays[i] = wantedColor; } There's also named equivalents like gray1..x provided you have an rgb.txt. Somewhere in X's callchain, this results in a call to X code that handles the colormap. For example, Xfbdev hits the following: xc-011010/programs/Xserver/dix/colormap.c: FindBestPixel(pentFirst, size, prgb, channel) dr = (long) pent->co.local.red - prgb->red; dg = (long) pent->co.local.green - prgb->green; db = (long) pent->co.local.blue - prgb->blue; sq = dr * dr; UnsignedToBigNum (sq, &sum); BigNumAdd (&sum, &temp, &sum); co.local.red are entries that were brought in through FBIOGETCMAP which come directly from the info->cmap.red that was listed above. The prgb is the rgb that the app wants to match to. The above code is doing what looks like a least squares matching function. That's why the cmap entries can't be set to the left hand side boundaries of a color range. Documentation/fb/metronomefb.txt 0 → 100644 +38 −0 Original line number Diff line number Diff line Metronomefb ----------- Maintained by Jaya Kumar <jayakumar.lkml.gmail.com> Last revised: Nov 20, 2007 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 Vizplex display media. E-Ink hosts some details of this controller and the 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. 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 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 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 a possibility that it could have some permanent effects on the display media. I neither have access to nor know exactly what the waveform does in terms of the physical media. Metronomefb uses the deferred IO interface so that it can provide a memory mappable frame buffer. It has been tested with tinyx (Xfbdev). It is known to work at this time with xeyes, xclock, xloadimage, xpdf. Documentation/feature-removal-schedule.txt +0 −10 Original line number Diff line number Diff line Loading @@ -172,16 +172,6 @@ Who: Len Brown <len.brown@intel.com> --------------------------- What: ide-tape driver When: July 2008 Files: drivers/ide/ide-tape.c Why: This driver might not have any users anymore and maintaining it for no reason is an effort no one wants to make. Who: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>, Borislav Petkov <petkovbb@googlemail.com> --------------------------- What: libata spindown skipping and warning When: Dec 2008 Why: Some halt(8) implementations synchronize caches for and spin Loading Documentation/hw_random.txt +40 −19 Original line number Diff line number Diff line Hardware driver for Intel/AMD/VIA Random Number Generators (RNG) Copyright 2000,2001 Jeff Garzik <jgarzik@pobox.com> Copyright 2000,2001 Philipp Rumpf <prumpf@mandrakesoft.com> Introduction: The hw_random device driver is software that makes use of a The hw_random framework is software that makes use of a special hardware feature on your CPU or motherboard, a Random Number Generator (RNG). a Random Number Generator (RNG). The software has two parts: a core providing the /dev/hw_random character device and its sysfs support, plus a hardware-specific driver that plugs into that core. In order to make effective use of this device driver, you To make the most effective use of these mechanisms, you should download the support software as well. Download the latest version of the "rng-tools" package from the hw_random driver's official Web site: http://sourceforge.net/projects/gkernel/ About the Intel RNG hardware, from the firmware hub datasheet: The Firmware Hub integrates a Random Number Generator (RNG) using thermal noise generated from inherently random quantum mechanical properties of silicon. When not generating new random bits the RNG circuitry will enter a low power state. Intel will provide a binary software driver to give third party software access to our RNG for use as a security feature. At this time, the RNG is only to be used with a system in an OS-present state. Those tools use /dev/hw_random to fill the kernel entropy pool, which is used internally and exported by the /dev/urandom and /dev/random special files. Theory of operation: Character driver. Using the standard open() CHARACTER DEVICE. Using the standard open() and read() system calls, you can read random data from the hardware RNG device. This data is NOT CHECKED by any fitness tests, and could potentially be bogus (if the Loading @@ -36,9 +29,37 @@ Theory of operation: a security-conscious person would run fitness tests on the data before assuming it is truly random. /dev/hwrandom is char device major 10, minor 183. The rng-tools package uses such tests in "rngd", and lets you run them by hand with a "rngtest" utility. /dev/hw_random is char device major 10, minor 183. CLASS DEVICE. There is a /sys/class/misc/hw_random node with two unique attributes, "rng_available" and "rng_current". The "rng_available" attribute lists the hardware-specific drivers available, while "rng_current" lists the one which is currently connected to /dev/hw_random. If your system has more than one RNG available, you may change the one used by writing a name from the list in "rng_available" into "rng_current". ========================================================================== Hardware driver for Intel/AMD/VIA Random Number Generators (RNG) Copyright 2000,2001 Jeff Garzik <jgarzik@pobox.com> Copyright 2000,2001 Philipp Rumpf <prumpf@mandrakesoft.com> About the Intel RNG hardware, from the firmware hub datasheet: The Firmware Hub integrates a Random Number Generator (RNG) using thermal noise generated from inherently random quantum mechanical properties of silicon. When not generating new random bits the RNG circuitry will enter a low power state. Intel will provide a binary software driver to give third party software access to our RNG for use as a security feature. At this time, the RNG is only to be used with a system in an OS-present state. Driver notes: Intel RNG Driver notes: * FIXME: support poll(2) Loading Loading
Documentation/SubmittingPatches +1 −1 Original line number Diff line number Diff line Loading @@ -512,7 +512,7 @@ They provide type safety, have no length limitations, no formatting limitations, and under gcc they are as cheap as macros. Macros should only be used for cases where a static inline is clearly suboptimal [there a few, isolated cases of this in fast paths], suboptimal [there are a few, isolated cases of this in fast paths], or where it is impossible to use a static inline function [such as string-izing]. Loading
Documentation/fb/cmap_xfbdev.txt 0 → 100644 +53 −0 Original line number Diff line number Diff line Understanding fbdev's cmap -------------------------- These notes explain how X's dix layer uses fbdev's cmap structures. *. example of relevant structures in fbdev as used for a 3-bit grayscale cmap struct fb_var_screeninfo { .bits_per_pixel = 8, .grayscale = 1, .red = { 4, 3, 0 }, .green = { 0, 0, 0 }, .blue = { 0, 0, 0 }, } struct fb_fix_screeninfo { .visual = FB_VISUAL_STATIC_PSEUDOCOLOR, } for (i = 0; i < 8; i++) info->cmap.red[i] = (((2*i)+1)*(0xFFFF))/16; memcpy(info->cmap.green, info->cmap.red, sizeof(u16)*8); memcpy(info->cmap.blue, info->cmap.red, sizeof(u16)*8); *. X11 apps do something like the following when trying to use grayscale. for (i=0; i < 8; i++) { char colorspec[64]; memset(colorspec,0,64); sprintf(colorspec, "rgb:%x/%x/%x", i*36,i*36,i*36); if (!XParseColor(outputDisplay, testColormap, colorspec, &wantedColor)) printf("Can't get color %s\n",colorspec); XAllocColor(outputDisplay, testColormap, &wantedColor); grays[i] = wantedColor; } There's also named equivalents like gray1..x provided you have an rgb.txt. Somewhere in X's callchain, this results in a call to X code that handles the colormap. For example, Xfbdev hits the following: xc-011010/programs/Xserver/dix/colormap.c: FindBestPixel(pentFirst, size, prgb, channel) dr = (long) pent->co.local.red - prgb->red; dg = (long) pent->co.local.green - prgb->green; db = (long) pent->co.local.blue - prgb->blue; sq = dr * dr; UnsignedToBigNum (sq, &sum); BigNumAdd (&sum, &temp, &sum); co.local.red are entries that were brought in through FBIOGETCMAP which come directly from the info->cmap.red that was listed above. The prgb is the rgb that the app wants to match to. The above code is doing what looks like a least squares matching function. That's why the cmap entries can't be set to the left hand side boundaries of a color range.
Documentation/fb/metronomefb.txt 0 → 100644 +38 −0 Original line number Diff line number Diff line Metronomefb ----------- Maintained by Jaya Kumar <jayakumar.lkml.gmail.com> Last revised: Nov 20, 2007 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 Vizplex display media. E-Ink hosts some details of this controller and the 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. 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 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 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 a possibility that it could have some permanent effects on the display media. I neither have access to nor know exactly what the waveform does in terms of the physical media. Metronomefb uses the deferred IO interface so that it can provide a memory mappable frame buffer. It has been tested with tinyx (Xfbdev). It is known to work at this time with xeyes, xclock, xloadimage, xpdf.
Documentation/feature-removal-schedule.txt +0 −10 Original line number Diff line number Diff line Loading @@ -172,16 +172,6 @@ Who: Len Brown <len.brown@intel.com> --------------------------- What: ide-tape driver When: July 2008 Files: drivers/ide/ide-tape.c Why: This driver might not have any users anymore and maintaining it for no reason is an effort no one wants to make. Who: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>, Borislav Petkov <petkovbb@googlemail.com> --------------------------- What: libata spindown skipping and warning When: Dec 2008 Why: Some halt(8) implementations synchronize caches for and spin Loading
Documentation/hw_random.txt +40 −19 Original line number Diff line number Diff line Hardware driver for Intel/AMD/VIA Random Number Generators (RNG) Copyright 2000,2001 Jeff Garzik <jgarzik@pobox.com> Copyright 2000,2001 Philipp Rumpf <prumpf@mandrakesoft.com> Introduction: The hw_random device driver is software that makes use of a The hw_random framework is software that makes use of a special hardware feature on your CPU or motherboard, a Random Number Generator (RNG). a Random Number Generator (RNG). The software has two parts: a core providing the /dev/hw_random character device and its sysfs support, plus a hardware-specific driver that plugs into that core. In order to make effective use of this device driver, you To make the most effective use of these mechanisms, you should download the support software as well. Download the latest version of the "rng-tools" package from the hw_random driver's official Web site: http://sourceforge.net/projects/gkernel/ About the Intel RNG hardware, from the firmware hub datasheet: The Firmware Hub integrates a Random Number Generator (RNG) using thermal noise generated from inherently random quantum mechanical properties of silicon. When not generating new random bits the RNG circuitry will enter a low power state. Intel will provide a binary software driver to give third party software access to our RNG for use as a security feature. At this time, the RNG is only to be used with a system in an OS-present state. Those tools use /dev/hw_random to fill the kernel entropy pool, which is used internally and exported by the /dev/urandom and /dev/random special files. Theory of operation: Character driver. Using the standard open() CHARACTER DEVICE. Using the standard open() and read() system calls, you can read random data from the hardware RNG device. This data is NOT CHECKED by any fitness tests, and could potentially be bogus (if the Loading @@ -36,9 +29,37 @@ Theory of operation: a security-conscious person would run fitness tests on the data before assuming it is truly random. /dev/hwrandom is char device major 10, minor 183. The rng-tools package uses such tests in "rngd", and lets you run them by hand with a "rngtest" utility. /dev/hw_random is char device major 10, minor 183. CLASS DEVICE. There is a /sys/class/misc/hw_random node with two unique attributes, "rng_available" and "rng_current". The "rng_available" attribute lists the hardware-specific drivers available, while "rng_current" lists the one which is currently connected to /dev/hw_random. If your system has more than one RNG available, you may change the one used by writing a name from the list in "rng_available" into "rng_current". ========================================================================== Hardware driver for Intel/AMD/VIA Random Number Generators (RNG) Copyright 2000,2001 Jeff Garzik <jgarzik@pobox.com> Copyright 2000,2001 Philipp Rumpf <prumpf@mandrakesoft.com> About the Intel RNG hardware, from the firmware hub datasheet: The Firmware Hub integrates a Random Number Generator (RNG) using thermal noise generated from inherently random quantum mechanical properties of silicon. When not generating new random bits the RNG circuitry will enter a low power state. Intel will provide a binary software driver to give third party software access to our RNG for use as a security feature. At this time, the RNG is only to be used with a system in an OS-present state. Driver notes: Intel RNG Driver notes: * FIXME: support poll(2) Loading
