You've already forked linux-apfs
mirror of
https://github.com/linux-apfs/linux-apfs.git
synced 2026-05-01 15:00:59 -07:00
Merge ARM fixes
This commit is contained in:
Russell King
Russell King
@@ -0,0 +1,96 @@
|
||||
#
|
||||
# This list is used by git-shortlog to fix a few botched name translations
|
||||
# in the git archive, either because the author's full name was messed up
|
||||
# and/or not always written the same way, making contributions from the
|
||||
# same person appearing not to be so or badly displayed.
|
||||
#
|
||||
# repo-abbrev: /pub/scm/linux/kernel/git/
|
||||
#
|
||||
|
||||
Aaron Durbin <adurbin@google.com>
|
||||
Adam Oldham <oldhamca@gmail.com>
|
||||
Adam Radford <aradford@gmail.com>
|
||||
Adrian Bunk <bunk@stusta.de>
|
||||
Alan Cox <alan@lxorguk.ukuu.org.uk>
|
||||
Alan Cox <root@hraefn.swansea.linux.org.uk>
|
||||
Aleksey Gorelov <aleksey_gorelov@phoenix.com>
|
||||
Al Viro <viro@ftp.linux.org.uk>
|
||||
Al Viro <viro@zenIV.linux.org.uk>
|
||||
Andreas Herrmann <aherrman@de.ibm.com>
|
||||
Andrew Morton <akpm@osdl.org>
|
||||
Andrew Vasquez <andrew.vasquez@qlogic.com>
|
||||
Andy Adamson <andros@citi.umich.edu>
|
||||
Arnaud Patard <arnaud.patard@rtp-net.org>
|
||||
Arnd Bergmann <arnd@arndb.de>
|
||||
Axel Dyks <xl@xlsigned.net>
|
||||
Ben Gardner <bgardner@wabtec.com>
|
||||
Ben M Cahill <ben.m.cahill@intel.com>
|
||||
Björn Steinbrink <B.Steinbrink@gmx.de>
|
||||
Brian Avery <b.avery@hp.com>
|
||||
Brian King <brking@us.ibm.com>
|
||||
Christoph Hellwig <hch@lst.de>
|
||||
Corey Minyard <minyard@acm.org>
|
||||
David Brownell <david-b@pacbell.net>
|
||||
David Woodhouse <dwmw2@shinybook.infradead.org>
|
||||
Domen Puncer <domen@coderock.org>
|
||||
Douglas Gilbert <dougg@torque.net>
|
||||
Ed L. Cashin <ecashin@coraid.com>
|
||||
Evgeniy Polyakov <johnpol@2ka.mipt.ru>
|
||||
Felipe W Damasio <felipewd@terra.com.br>
|
||||
Felix Kuhling <fxkuehl@gmx.de>
|
||||
Felix Moeller <felix@derklecks.de>
|
||||
Filipe Lautert <filipe@icewall.org>
|
||||
Franck Bui-Huu <vagabon.xyz@gmail.com>
|
||||
Frank Zago <fzago@systemfabricworks.com>
|
||||
Greg Kroah-Hartman <greg@echidna.(none)>
|
||||
Greg Kroah-Hartman <gregkh@suse.de>
|
||||
Greg Kroah-Hartman <greg@kroah.com>
|
||||
Henk Vergonet <Henk.Vergonet@gmail.com>
|
||||
Henrik Kretzschmar <henne@nachtwindheim.de>
|
||||
Herbert Xu <herbert@gondor.apana.org.au>
|
||||
Jacob Shin <Jacob.Shin@amd.com>
|
||||
James Bottomley <jejb@mulgrave.(none)>
|
||||
James Bottomley <jejb@titanic.il.steeleye.com>
|
||||
James E Wilson <wilson@specifix.com>
|
||||
James Ketrenos <jketreno@io.(none)>
|
||||
Jean Tourrilhes <jt@hpl.hp.com>
|
||||
Jeff Garzik <jgarzik@pretzel.yyz.us>
|
||||
Jens Axboe <axboe@suse.de>
|
||||
Jens Osterkamp <Jens.Osterkamp@de.ibm.com>
|
||||
John Stultz <johnstul@us.ibm.com>
|
||||
Juha Yrjola <at solidboot.com>
|
||||
Juha Yrjola <juha.yrjola@nokia.com>
|
||||
Juha Yrjola <juha.yrjola@solidboot.com>
|
||||
Kay Sievers <kay.sievers@vrfy.org>
|
||||
Kenneth W Chen <kenneth.w.chen@intel.com>
|
||||
Koushik <raghavendra.koushik@neterion.com>
|
||||
Leonid I Ananiev <leonid.i.ananiev@intel.com>
|
||||
Linas Vepstas <linas@austin.ibm.com>
|
||||
Matthieu CASTET <castet.matthieu@free.fr>
|
||||
Michel Dänzer <michel@tungstengraphics.com>
|
||||
Mitesh shah <mshah@teja.com>
|
||||
Morten Welinder <terra@gnome.org>
|
||||
Morten Welinder <welinder@anemone.rentec.com>
|
||||
Morten Welinder <welinder@darter.rentec.com>
|
||||
Morten Welinder <welinder@troll.com>
|
||||
Nguyen Anh Quynh <aquynh@gmail.com>
|
||||
Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
|
||||
Patrick Mochel <mochel@digitalimplant.org>
|
||||
Peter A Jonsson <pj@ludd.ltu.se>
|
||||
Praveen BP <praveenbp@ti.com>
|
||||
Rajesh Shah <rajesh.shah@intel.com>
|
||||
Ralf Baechle <ralf@linux-mips.org>
|
||||
Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
|
||||
Rémi Denis-Courmont <rdenis@simphalempin.com>
|
||||
Rudolf Marek <R.Marek@sh.cvut.cz>
|
||||
Rui Saraiva <rmps@joel.ist.utl.pt>
|
||||
Sachin P Sant <ssant@in.ibm.com>
|
||||
Sam Ravnborg <sam@mars.ravnborg.org>
|
||||
Simon Kelley <simon@thekelleys.org.uk>
|
||||
Stéphane Witzmann <stephane.witzmann@ubpmes.univ-bpclermont.fr>
|
||||
Stephen Hemminger <shemminger@osdl.org>
|
||||
Tejun Heo <htejun@gmail.com>
|
||||
Thomas Graf <tgraf@suug.ch>
|
||||
Tony Luck <tony.luck@intel.com>
|
||||
Tsuneo Yoshioka <Tsuneo.Yoshioka@f-secure.com>
|
||||
Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
|
||||
@@ -2571,6 +2571,16 @@ S: Subiaco, 6008
|
||||
S: Perth, Western Australia
|
||||
S: Australia
|
||||
|
||||
N: Miguel Ojeda Sandonis
|
||||
E: maxextreme@gmail.com
|
||||
D: Author: Auxiliary LCD Controller driver (ks0108)
|
||||
D: Author: Auxiliary LCD driver (cfag12864b)
|
||||
D: Author: Auxiliary LCD framebuffer driver (cfag12864bfb)
|
||||
D: Maintainer: Auxiliary display drivers tree (drivers/auxdisplay/*)
|
||||
S: C/ Mieses 20, 9-B
|
||||
S: Valladolid 47009
|
||||
S: Spain
|
||||
|
||||
N: Greg Page
|
||||
E: gpage@sovereign.org
|
||||
D: IPX development and support
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
What: /debug/pktcdvd/pktcdvd[0-7]
|
||||
Date: Oct. 2006
|
||||
KernelVersion: 2.6.19
|
||||
KernelVersion: 2.6.20
|
||||
Contact: Thomas Maier <balagi@justmail.de>
|
||||
Description:
|
||||
|
||||
@@ -11,8 +11,7 @@ The pktcdvd module (packet writing driver) creates
|
||||
these files in debugfs:
|
||||
|
||||
/debug/pktcdvd/pktcdvd[0-7]/
|
||||
info (0444) Lots of human readable driver
|
||||
statistics and infos. Multiple lines!
|
||||
info (0444) Lots of driver statistics and infos.
|
||||
|
||||
Example:
|
||||
-------
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
What: /sys/class/pktcdvd/
|
||||
Date: Oct. 2006
|
||||
KernelVersion: 2.6.19
|
||||
KernelVersion: 2.6.20
|
||||
Contact: Thomas Maier <balagi@justmail.de>
|
||||
Description:
|
||||
|
||||
|
||||
@@ -482,13 +482,13 @@ slightly.
|
||||
<para>Gadget drivers
|
||||
rely on common USB structures and constants
|
||||
defined in the
|
||||
<filename><linux/usb_ch9.h></filename>
|
||||
<filename><linux/usb/ch9.h></filename>
|
||||
header file, which is standard in Linux 2.6 kernels.
|
||||
These are the same types and constants used by host
|
||||
side drivers (and usbcore).
|
||||
</para>
|
||||
|
||||
!Iinclude/linux/usb_ch9.h
|
||||
!Iinclude/linux/usb/ch9.h
|
||||
</sect1>
|
||||
|
||||
<sect1 id="core"><title>Core Objects and Methods</title>
|
||||
|
||||
@@ -316,6 +316,9 @@ X!Earch/i386/kernel/mca.c
|
||||
<sect1><title>DMI Interfaces</title>
|
||||
!Edrivers/firmware/dmi_scan.c
|
||||
</sect1>
|
||||
<sect1><title>EDD Interfaces</title>
|
||||
!Idrivers/firmware/edd.c
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<chapter id="security">
|
||||
|
||||
@@ -4,4 +4,5 @@
|
||||
<param name="funcsynopsis.style">ansi</param>
|
||||
<param name="funcsynopsis.tabular.threshold">80</param>
|
||||
<!-- <param name="paper.type">A4</param> -->
|
||||
<param name="generate.section.toc.level">2</param>
|
||||
</stylesheet>
|
||||
|
||||
@@ -187,13 +187,13 @@
|
||||
|
||||
<chapter><title>USB-Standard Types</title>
|
||||
|
||||
<para>In <filename><linux/usb_ch9.h></filename> you will find
|
||||
<para>In <filename><linux/usb/ch9.h></filename> you will find
|
||||
the USB data types defined in chapter 9 of the USB specification.
|
||||
These data types are used throughout USB, and in APIs including
|
||||
this host side API, gadget APIs, and usbfs.
|
||||
</para>
|
||||
|
||||
!Iinclude/linux/usb_ch9.h
|
||||
!Iinclude/linux/usb/ch9.h
|
||||
|
||||
</chapter>
|
||||
|
||||
@@ -574,7 +574,7 @@ for (;;) {
|
||||
#include <asm/byteorder.h></programlisting>
|
||||
The standard USB device model requests, from "Chapter 9" of
|
||||
the USB 2.0 specification, are automatically included from
|
||||
the <filename><linux/usb_ch9.h></filename> header.
|
||||
the <filename><linux/usb/ch9.h></filename> header.
|
||||
</para>
|
||||
|
||||
<para>Unless noted otherwise, the ioctl requests
|
||||
|
||||
@@ -30,6 +30,7 @@ are not a good substitute for a solid C education and/or years of
|
||||
experience, the following books are good for, if anything, reference:
|
||||
- "The C Programming Language" by Kernighan and Ritchie [Prentice Hall]
|
||||
- "Practical C Programming" by Steve Oualline [O'Reilly]
|
||||
- "C: A Reference Manual" by Harbison and Steele [Prentice Hall]
|
||||
|
||||
The kernel is written using GNU C and the GNU toolchain. While it
|
||||
adheres to the ISO C89 standard, it uses a number of extensions that are
|
||||
|
||||
@@ -1,38 +0,0 @@
|
||||
driver/acpi/hotkey.c implement:
|
||||
1. /proc/acpi/hotkey/event_config
|
||||
(event based hotkey or event config interface):
|
||||
a. add a event based hotkey(event) :
|
||||
echo "0:bus::action:method:num:num" > event_config
|
||||
|
||||
b. delete a event based hotkey(event):
|
||||
echo "1:::::num:num" > event_config
|
||||
|
||||
c. modify a event based hotkey(event):
|
||||
echo "2:bus::action:method:num:num" > event_config
|
||||
|
||||
2. /proc/acpi/hotkey/poll_config
|
||||
(polling based hotkey or event config interface):
|
||||
a.add a polling based hotkey(event) :
|
||||
echo "0:bus:method:action:method:num" > poll_config
|
||||
this adding command will create a proc file
|
||||
/proc/acpi/hotkey/method, which is used to get
|
||||
result of polling.
|
||||
|
||||
b.delete a polling based hotkey(event):
|
||||
echo "1:::::num" > event_config
|
||||
|
||||
c.modify a polling based hotkey(event):
|
||||
echo "2:bus:method:action:method:num" > poll_config
|
||||
|
||||
3./proc/acpi/hotkey/action
|
||||
(interface to call aml method associated with a
|
||||
specific hotkey(event))
|
||||
echo "event_num:event_type:event_argument" >
|
||||
/proc/acpi/hotkey/action.
|
||||
The result of the execution of this aml method is
|
||||
attached to /proc/acpi/hotkey/poll_method, which is dynamically
|
||||
created. Please use command "cat /proc/acpi/hotkey/polling_method"
|
||||
to retrieve it.
|
||||
|
||||
Note: Use cmdline "acpi_generic_hotkey" to over-ride
|
||||
platform-specific with generic driver.
|
||||
@@ -0,0 +1,105 @@
|
||||
===================================
|
||||
cfag12864b LCD Driver Documentation
|
||||
===================================
|
||||
|
||||
License: GPLv2
|
||||
Author & Maintainer: Miguel Ojeda Sandonis <maxextreme@gmail.com>
|
||||
Date: 2006-10-27
|
||||
|
||||
|
||||
|
||||
--------
|
||||
0. INDEX
|
||||
--------
|
||||
|
||||
1. DRIVER INFORMATION
|
||||
2. DEVICE INFORMATION
|
||||
3. WIRING
|
||||
4. USERSPACE PROGRAMMING
|
||||
|
||||
|
||||
---------------------
|
||||
1. DRIVER INFORMATION
|
||||
---------------------
|
||||
|
||||
This driver support one cfag12864b display at time.
|
||||
|
||||
|
||||
---------------------
|
||||
2. DEVICE INFORMATION
|
||||
---------------------
|
||||
|
||||
Manufacturer: Crystalfontz
|
||||
Device Name: Crystalfontz 12864b LCD Series
|
||||
Device Code: cfag12864b
|
||||
Webpage: http://www.crystalfontz.com
|
||||
Device Webpage: http://www.crystalfontz.com/products/12864b/
|
||||
Type: LCD (Liquid Crystal Display)
|
||||
Width: 128
|
||||
Height: 64
|
||||
Colors: 2 (B/N)
|
||||
Controller: ks0108
|
||||
Controllers: 2
|
||||
Pages: 8 each controller
|
||||
Addresses: 64 each page
|
||||
Data size: 1 byte each address
|
||||
Memory size: 2 * 8 * 64 * 1 = 1024 bytes = 1 Kbyte
|
||||
|
||||
|
||||
---------
|
||||
3. WIRING
|
||||
---------
|
||||
|
||||
The cfag12864b LCD Series don't have official wiring.
|
||||
|
||||
The common wiring is done to the parallel port as shown:
|
||||
|
||||
Parallel Port cfag12864b
|
||||
|
||||
Name Pin# Pin# Name
|
||||
|
||||
Strobe ( 1)------------------------------(17) Enable
|
||||
Data 0 ( 2)------------------------------( 4) Data 0
|
||||
Data 1 ( 3)------------------------------( 5) Data 1
|
||||
Data 2 ( 4)------------------------------( 6) Data 2
|
||||
Data 3 ( 5)------------------------------( 7) Data 3
|
||||
Data 4 ( 6)------------------------------( 8) Data 4
|
||||
Data 5 ( 7)------------------------------( 9) Data 5
|
||||
Data 6 ( 8)------------------------------(10) Data 6
|
||||
Data 7 ( 9)------------------------------(11) Data 7
|
||||
(10) [+5v]---( 1) Vdd
|
||||
(11) [GND]---( 2) Ground
|
||||
(12) [+5v]---(14) Reset
|
||||
(13) [GND]---(15) Read / Write
|
||||
Line (14)------------------------------(13) Controller Select 1
|
||||
(15)
|
||||
Init (16)------------------------------(12) Controller Select 2
|
||||
Select (17)------------------------------(16) Data / Instruction
|
||||
Ground (18)---[GND] [+5v]---(19) LED +
|
||||
Ground (19)---[GND]
|
||||
Ground (20)---[GND] E A Values:
|
||||
Ground (21)---[GND] [GND]---[P1]---(18) Vee · R = Resistor = 22 ohm
|
||||
Ground (22)---[GND] | · P1 = Preset = 10 Kohm
|
||||
Ground (23)---[GND] ---- S ------( 3) V0 · P2 = Preset = 1 Kohm
|
||||
Ground (24)---[GND] | |
|
||||
Ground (25)---[GND] [GND]---[P2]---[R]---(20) LED -
|
||||
|
||||
|
||||
------------------------
|
||||
4. USERSPACE PROGRAMMING
|
||||
------------------------
|
||||
|
||||
The cfag12864bfb describes a framebuffer device (/dev/fbX).
|
||||
|
||||
It has a size of 1024 bytes = 1 Kbyte.
|
||||
Each bit represents one pixel. If the bit is high, the pixel will
|
||||
turn on. If the pixel is low, the pixel will turn off.
|
||||
|
||||
You can use the framebuffer as a file: fopen, fwrite, fclose...
|
||||
Although the LCD won't get updated until the next refresh time arrives.
|
||||
|
||||
Also, you can mmap the framebuffer: open & mmap, munmap & close...
|
||||
which is the best option for most uses.
|
||||
|
||||
Check Documentation/auxdisplay/cfag12864b-example.c
|
||||
for a real working userspace complete program with usage examples.
|
||||
@@ -0,0 +1,282 @@
|
||||
/*
|
||||
* Filename: cfag12864b-example.c
|
||||
* Version: 0.1.0
|
||||
* Description: cfag12864b LCD userspace example program
|
||||
* License: GPLv2
|
||||
*
|
||||
* Author: Copyright (C) Miguel Ojeda Sandonis <maxextreme@gmail.com>
|
||||
* Date: 2006-10-31
|
||||
*
|
||||
* This program is free software; you can redistribute it and/or modify
|
||||
* it under the terms of the GNU General Public License version 2 as
|
||||
* published by the Free Software Foundation.
|
||||
*
|
||||
* This program is distributed in the hope that it will be useful,
|
||||
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
* GNU General Public License for more details.
|
||||
*
|
||||
* You should have received a copy of the GNU General Public License
|
||||
* along with this program; if not, write to the Free Software
|
||||
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
|
||||
*
|
||||
*/
|
||||
|
||||
/*
|
||||
* ------------------------
|
||||
* start of cfag12864b code
|
||||
* ------------------------
|
||||
*/
|
||||
|
||||
#include <string.h>
|
||||
#include <fcntl.h>
|
||||
#include <unistd.h>
|
||||
#include <sys/types.h>
|
||||
#include <sys/stat.h>
|
||||
#include <sys/mman.h>
|
||||
|
||||
#define CFAG12864B_WIDTH (128)
|
||||
#define CFAG12864B_HEIGHT (64)
|
||||
#define CFAG12864B_SIZE (128 * 64 / 8)
|
||||
#define CFAG12864B_BPB (8)
|
||||
#define CFAG12864B_ADDRESS(x, y) ((y) * CFAG12864B_WIDTH / \
|
||||
CFAG12864B_BPB + (x) / CFAG12864B_BPB)
|
||||
#define CFAG12864B_BIT(n) (((unsigned char) 1) << (n))
|
||||
|
||||
#undef CFAG12864B_DOCHECK
|
||||
#ifdef CFAG12864B_DOCHECK
|
||||
#define CFAG12864B_CHECK(x, y) ((x) < CFAG12864B_WIDTH && \
|
||||
(y) < CFAG12864B_HEIGHT)
|
||||
#else
|
||||
#define CFAG12864B_CHECK(x, y) (1)
|
||||
#endif
|
||||
|
||||
int cfag12864b_fd;
|
||||
unsigned char * cfag12864b_mem;
|
||||
unsigned char cfag12864b_buffer[CFAG12864B_SIZE];
|
||||
|
||||
/*
|
||||
* init a cfag12864b framebuffer device
|
||||
*
|
||||
* No error: return = 0
|
||||
* Unable to open: return = -1
|
||||
* Unable to mmap: return = -2
|
||||
*/
|
||||
int cfag12864b_init(char *path)
|
||||
{
|
||||
cfag12864b_fd = open(path, O_RDWR);
|
||||
if (cfag12864b_fd == -1)
|
||||
return -1;
|
||||
|
||||
cfag12864b_mem = mmap(0, CFAG12864B_SIZE, PROT_READ | PROT_WRITE,
|
||||
MAP_SHARED, cfag12864b_fd, 0);
|
||||
if (cfag12864b_mem == MAP_FAILED) {
|
||||
close(cfag12864b_fd);
|
||||
return -2;
|
||||
}
|
||||
|
||||
return 0;
|
||||
}
|
||||
|
||||
/*
|
||||
* exit a cfag12864b framebuffer device
|
||||
*/
|
||||
void cfag12864b_exit(void)
|
||||
{
|
||||
munmap(cfag12864b_mem, CFAG12864B_SIZE);
|
||||
close(cfag12864b_fd);
|
||||
}
|
||||
|
||||
/*
|
||||
* set (x, y) pixel
|
||||
*/
|
||||
void cfag12864b_set(unsigned char x, unsigned char y)
|
||||
{
|
||||
if (CFAG12864B_CHECK(x, y))
|
||||
cfag12864b_buffer[CFAG12864B_ADDRESS(x, y)] |=
|
||||
CFAG12864B_BIT(x % CFAG12864B_BPB);
|
||||
}
|
||||
|
||||
/*
|
||||
* unset (x, y) pixel
|
||||
*/
|
||||
void cfag12864b_unset(unsigned char x, unsigned char y)
|
||||
{
|
||||
if (CFAG12864B_CHECK(x, y))
|
||||
cfag12864b_buffer[CFAG12864B_ADDRESS(x, y)] &=
|
||||
~CFAG12864B_BIT(x % CFAG12864B_BPB);
|
||||
}
|
||||
|
||||
/*
|
||||
* is set (x, y) pixel?
|
||||
*
|
||||
* Pixel off: return = 0
|
||||
* Pixel on: return = 1
|
||||
*/
|
||||
unsigned char cfag12864b_isset(unsigned char x, unsigned char y)
|
||||
{
|
||||
if (CFAG12864B_CHECK(x, y))
|
||||
if (cfag12864b_buffer[CFAG12864B_ADDRESS(x, y)] &
|
||||
CFAG12864B_BIT(x % CFAG12864B_BPB))
|
||||
return 1;
|
||||
|
||||
return 0;
|
||||
}
|
||||
|
||||
/*
|
||||
* not (x, y) pixel
|
||||
*/
|
||||
void cfag12864b_not(unsigned char x, unsigned char y)
|
||||
{
|
||||
if (cfag12864b_isset(x, y))
|
||||
cfag12864b_unset(x, y);
|
||||
else
|
||||
cfag12864b_set(x, y);
|
||||
}
|
||||
|
||||
/*
|
||||
* fill (set all pixels)
|
||||
*/
|
||||
void cfag12864b_fill(void)
|
||||
{
|
||||
unsigned short i;
|
||||
|
||||
for (i = 0; i < CFAG12864B_SIZE; i++)
|
||||
cfag12864b_buffer[i] = 0xFF;
|
||||
}
|
||||
|
||||
/*
|
||||
* clear (unset all pixels)
|
||||
*/
|
||||
void cfag12864b_clear(void)
|
||||
{
|
||||
unsigned short i;
|
||||
|
||||
for (i = 0; i < CFAG12864B_SIZE; i++)
|
||||
cfag12864b_buffer[i] = 0;
|
||||
}
|
||||
|
||||
/*
|
||||
* format a [128*64] matrix
|
||||
*
|
||||
* Pixel off: src[i] = 0
|
||||
* Pixel on: src[i] > 0
|
||||
*/
|
||||
void cfag12864b_format(unsigned char * matrix)
|
||||
{
|
||||
unsigned char i, j, n;
|
||||
|
||||
for (i = 0; i < CFAG12864B_HEIGHT; i++)
|
||||
for (j = 0; j < CFAG12864B_WIDTH / CFAG12864B_BPB; j++) {
|
||||
cfag12864b_buffer[i * CFAG12864B_WIDTH / CFAG12864B_BPB +
|
||||
j] = 0;
|
||||
for (n = 0; n < CFAG12864B_BPB; n++)
|
||||
if (matrix[i * CFAG12864B_WIDTH +
|
||||
j * CFAG12864B_BPB + n])
|
||||
cfag12864b_buffer[i * CFAG12864B_WIDTH /
|
||||
CFAG12864B_BPB + j] |=
|
||||
CFAG12864B_BIT(n);
|
||||
}
|
||||
}
|
||||
|
||||
/*
|
||||
* blit buffer to lcd
|
||||
*/
|
||||
void cfag12864b_blit(void)
|
||||
{
|
||||
memcpy(cfag12864b_mem, cfag12864b_buffer, CFAG12864B_SIZE);
|
||||
}
|
||||
|
||||
/*
|
||||
* ----------------------
|
||||
* end of cfag12864b code
|
||||
* ----------------------
|
||||
*/
|
||||
|
||||
#include <stdio.h>
|
||||
#include <string.h>
|
||||
|
||||
#define EXAMPLES 6
|
||||
|
||||
void example(unsigned char n)
|
||||
{
|
||||
unsigned short i, j;
|
||||
unsigned char matrix[CFAG12864B_WIDTH * CFAG12864B_HEIGHT];
|
||||
|
||||
if (n > EXAMPLES)
|
||||
return;
|
||||
|
||||
printf("Example %i/%i - ", n, EXAMPLES);
|
||||
|
||||
switch (n) {
|
||||
case 1:
|
||||
printf("Draw points setting bits");
|
||||
cfag12864b_clear();
|
||||
for (i = 0; i < CFAG12864B_WIDTH; i += 2)
|
||||
for (j = 0; j < CFAG12864B_HEIGHT; j += 2)
|
||||
cfag12864b_set(i, j);
|
||||
break;
|
||||
|
||||
case 2:
|
||||
printf("Clear the LCD");
|
||||
cfag12864b_clear();
|
||||
break;
|
||||
|
||||
case 3:
|
||||
printf("Draw rows formatting a [128*64] matrix");
|
||||
memset(matrix, 0, CFAG12864B_WIDTH * CFAG12864B_HEIGHT);
|
||||
for (i = 0; i < CFAG12864B_WIDTH; i++)
|
||||
for (j = 0; j < CFAG12864B_HEIGHT; j += 2)
|
||||
matrix[j * CFAG12864B_WIDTH + i] = 1;
|
||||
cfag12864b_format(matrix);
|
||||
break;
|
||||
|
||||
case 4:
|
||||
printf("Fill the lcd");
|
||||
cfag12864b_fill();
|
||||
break;
|
||||
|
||||
case 5:
|
||||
printf("Draw columns unsetting bits");
|
||||
for (i = 0; i < CFAG12864B_WIDTH; i += 2)
|
||||
for (j = 0; j < CFAG12864B_HEIGHT; j++)
|
||||
cfag12864b_unset(i, j);
|
||||
break;
|
||||
|
||||
case 6:
|
||||
printf("Do negative not-ing all bits");
|
||||
for (i = 0; i < CFAG12864B_WIDTH; i++)
|
||||
for (j = 0; j < CFAG12864B_HEIGHT; j ++)
|
||||
cfag12864b_not(i, j);
|
||||
break;
|
||||
}
|
||||
|
||||
puts(" - [Press Enter]");
|
||||
}
|
||||
|
||||
int main(int argc, char *argv[])
|
||||
{
|
||||
unsigned char n;
|
||||
|
||||
if (argc != 2) {
|
||||
printf(
|
||||
"Sintax: %s fbdev\n"
|
||||
"Usually: /dev/fb0, /dev/fb1...\n", argv[0]);
|
||||
return -1;
|
||||
}
|
||||
|
||||
if (cfag12864b_init(argv[1])) {
|
||||
printf("Can't init %s fbdev\n", argv[1]);
|
||||
return -2;
|
||||
}
|
||||
|
||||
for (n = 1; n <= EXAMPLES; n++) {
|
||||
example(n);
|
||||
cfag12864b_blit();
|
||||
while (getchar() != '\n');
|
||||
}
|
||||
|
||||
cfag12864b_exit();
|
||||
|
||||
return 0;
|
||||
}
|
||||
@@ -0,0 +1,55 @@
|
||||
==========================================
|
||||
ks0108 LCD Controller Driver Documentation
|
||||
==========================================
|
||||
|
||||
License: GPLv2
|
||||
Author & Maintainer: Miguel Ojeda Sandonis <maxextreme@gmail.com>
|
||||
Date: 2006-10-27
|
||||
|
||||
|
||||
|
||||
--------
|
||||
0. INDEX
|
||||
--------
|
||||
|
||||
1. DRIVER INFORMATION
|
||||
2. DEVICE INFORMATION
|
||||
3. WIRING
|
||||
|
||||
|
||||
---------------------
|
||||
1. DRIVER INFORMATION
|
||||
---------------------
|
||||
|
||||
This driver support the ks0108 LCD controller.
|
||||
|
||||
|
||||
---------------------
|
||||
2. DEVICE INFORMATION
|
||||
---------------------
|
||||
|
||||
Manufacturer: Samsung
|
||||
Device Name: KS0108 LCD Controller
|
||||
Device Code: ks0108
|
||||
Webpage: -
|
||||
Device Webpage: -
|
||||
Type: LCD Controller (Liquid Crystal Display Controller)
|
||||
Width: 64
|
||||
Height: 64
|
||||
Colors: 2 (B/N)
|
||||
Pages: 8
|
||||
Addresses: 64 each page
|
||||
Data size: 1 byte each address
|
||||
Memory size: 8 * 64 * 1 = 512 bytes
|
||||
|
||||
|
||||
---------
|
||||
3. WIRING
|
||||
---------
|
||||
|
||||
The driver supports data parallel port wiring.
|
||||
|
||||
If you aren't building LCD related hardware, you should check
|
||||
your LCD specific wiring information in the same folder.
|
||||
|
||||
For example, check Documentation/auxdisplay/cfag12864b.
|
||||
@@ -93,7 +93,7 @@ Notes
|
||||
Using the pktcdvd sysfs interface
|
||||
---------------------------------
|
||||
|
||||
Since Linux 2.6.19, the pktcdvd module has a sysfs interface
|
||||
Since Linux 2.6.20, the pktcdvd module has a sysfs interface
|
||||
and can be controlled by it. For example the "pktcdvd" tool uses
|
||||
this interface. (see http://people.freenet.de/BalaGi#pktcdvd )
|
||||
|
||||
|
||||
@@ -193,6 +193,7 @@ Original developers of the crypto algorithms:
|
||||
Kartikey Mahendra Bhatt (CAST6)
|
||||
Jon Oberheide (ARC4)
|
||||
Jouni Malinen (Michael MIC)
|
||||
NTT(Nippon Telegraph and Telephone Corporation) (Camellia)
|
||||
|
||||
SHA1 algorithm contributors:
|
||||
Jean-Francois Dive
|
||||
@@ -246,6 +247,9 @@ Tiger algorithm contributors:
|
||||
VIA PadLock contributors:
|
||||
Michal Ludvig
|
||||
|
||||
Camellia algorithm contributors:
|
||||
NTT(Nippon Telegraph and Telephone Corporation) (Camellia)
|
||||
|
||||
Generic scatterwalk code by Adam J. Richter <adam@yggdrasil.com>
|
||||
|
||||
Please send any credits updates or corrections to:
|
||||
|
||||
@@ -0,0 +1,268 @@
|
||||
Devres - Managed Device Resource
|
||||
================================
|
||||
|
||||
Tejun Heo <teheo@suse.de>
|
||||
|
||||
First draft 10 January 2007
|
||||
|
||||
|
||||
1. Intro : Huh? Devres?
|
||||
2. Devres : Devres in a nutshell
|
||||
3. Devres Group : Group devres'es and release them together
|
||||
4. Details : Life time rules, calling context, ...
|
||||
5. Overhead : How much do we have to pay for this?
|
||||
6. List of managed interfaces : Currently implemented managed interfaces
|
||||
|
||||
|
||||
1. Intro
|
||||
--------
|
||||
|
||||
devres came up while trying to convert libata to use iomap. Each
|
||||
iomapped address should be kept and unmapped on driver detach. For
|
||||
example, a plain SFF ATA controller (that is, good old PCI IDE) in
|
||||
native mode makes use of 5 PCI BARs and all of them should be
|
||||
maintained.
|
||||
|
||||
As with many other device drivers, libata low level drivers have
|
||||
sufficient bugs in ->remove and ->probe failure path. Well, yes,
|
||||
that's probably because libata low level driver developers are lazy
|
||||
bunch, but aren't all low level driver developers? After spending a
|
||||
day fiddling with braindamaged hardware with no document or
|
||||
braindamaged document, if it's finally working, well, it's working.
|
||||
|
||||
For one reason or another, low level drivers don't receive as much
|
||||
attention or testing as core code, and bugs on driver detach or
|
||||
initilaization failure doesn't happen often enough to be noticeable.
|
||||
Init failure path is worse because it's much less travelled while
|
||||
needs to handle multiple entry points.
|
||||
|
||||
So, many low level drivers end up leaking resources on driver detach
|
||||
and having half broken failure path implementation in ->probe() which
|
||||
would leak resources or even cause oops when failure occurs. iomap
|
||||
adds more to this mix. So do msi and msix.
|
||||
|
||||
|
||||
2. Devres
|
||||
---------
|
||||
|
||||
devres is basically linked list of arbitrarily sized memory areas
|
||||
associated with a struct device. Each devres entry is associated with
|
||||
a release function. A devres can be released in several ways. No
|
||||
matter what, all devres entries are released on driver detach. On
|
||||
release, the associated release function is invoked and then the
|
||||
devres entry is freed.
|
||||
|
||||
Managed interface is created for resources commonly used by device
|
||||
drivers using devres. For example, coherent DMA memory is acquired
|
||||
using dma_alloc_coherent(). The managed version is called
|
||||
dmam_alloc_coherent(). It is identical to dma_alloc_coherent() except
|
||||
for the DMA memory allocated using it is managed and will be
|
||||
automatically released on driver detach. Implementation looks like
|
||||
the following.
|
||||
|
||||
struct dma_devres {
|
||||
size_t size;
|
||||
void *vaddr;
|
||||
dma_addr_t dma_handle;
|
||||
};
|
||||
|
||||
static void dmam_coherent_release(struct device *dev, void *res)
|
||||
{
|
||||
struct dma_devres *this = res;
|
||||
|
||||
dma_free_coherent(dev, this->size, this->vaddr, this->dma_handle);
|
||||
}
|
||||
|
||||
dmam_alloc_coherent(dev, size, dma_handle, gfp)
|
||||
{
|
||||
struct dma_devres *dr;
|
||||
void *vaddr;
|
||||
|
||||
dr = devres_alloc(dmam_coherent_release, sizeof(*dr), gfp);
|
||||
...
|
||||
|
||||
/* alloc DMA memory as usual */
|
||||
vaddr = dma_alloc_coherent(...);
|
||||
...
|
||||
|
||||
/* record size, vaddr, dma_handle in dr */
|
||||
dr->vaddr = vaddr;
|
||||
...
|
||||
|
||||
devres_add(dev, dr);
|
||||
|
||||
return vaddr;
|
||||
}
|
||||
|
||||
If a driver uses dmam_alloc_coherent(), the area is guaranteed to be
|
||||
freed whether initialization fails half-way or the device gets
|
||||
detached. If most resources are acquired using managed interface, a
|
||||
driver can have much simpler init and exit code. Init path basically
|
||||
looks like the following.
|
||||
|
||||
my_init_one()
|
||||
{
|
||||
struct mydev *d;
|
||||
|
||||
d = devm_kzalloc(dev, sizeof(*d), GFP_KERNEL);
|
||||
if (!d)
|
||||
return -ENOMEM;
|
||||
|
||||
d->ring = dmam_alloc_coherent(...);
|
||||
if (!d->ring)
|
||||
return -ENOMEM;
|
||||
|
||||
if (check something)
|
||||
return -EINVAL;
|
||||
...
|
||||
|
||||
return register_to_upper_layer(d);
|
||||
}
|
||||
|
||||
And exit path,
|
||||
|
||||
my_remove_one()
|
||||
{
|
||||
unregister_from_upper_layer(d);
|
||||
shutdown_my_hardware();
|
||||
}
|
||||
|
||||
As shown above, low level drivers can be simplified a lot by using
|
||||
devres. Complexity is shifted from less maintained low level drivers
|
||||
to better maintained higher layer. Also, as init failure path is
|
||||
shared with exit path, both can get more testing.
|
||||
|
||||
|
||||
3. Devres group
|
||||
---------------
|
||||
|
||||
Devres entries can be grouped using devres group. When a group is
|
||||
released, all contained normal devres entries and properly nested
|
||||
groups are released. One usage is to rollback series of acquired
|
||||
resources on failure. For example,
|
||||
|
||||
if (!devres_open_group(dev, NULL, GFP_KERNEL))
|
||||
return -ENOMEM;
|
||||
|
||||
acquire A;
|
||||
if (failed)
|
||||
goto err;
|
||||
|
||||
acquire B;
|
||||
if (failed)
|
||||
goto err;
|
||||
...
|
||||
|
||||
devres_remove_group(dev, NULL);
|
||||
return 0;
|
||||
|
||||
err:
|
||||
devres_release_group(dev, NULL);
|
||||
return err_code;
|
||||
|
||||
As resource acquision failure usually means probe failure, constructs
|
||||
like above are usually useful in midlayer driver (e.g. libata core
|
||||
layer) where interface function shouldn't have side effect on failure.
|
||||
For LLDs, just returning error code suffices in most cases.
|
||||
|
||||
Each group is identified by void *id. It can either be explicitly
|
||||
specified by @id argument to devres_open_group() or automatically
|
||||
created by passing NULL as @id as in the above example. In both
|
||||
cases, devres_open_group() returns the group's id. The returned id
|
||||
can be passed to other devres functions to select the target group.
|
||||
If NULL is given to those functions, the latest open group is
|
||||
selected.
|
||||
|
||||
For example, you can do something like the following.
|
||||
|
||||
int my_midlayer_create_something()
|
||||
{
|
||||
if (!devres_open_group(dev, my_midlayer_create_something, GFP_KERNEL))
|
||||
return -ENOMEM;
|
||||
|
||||
...
|
||||
|
||||
devres_close_group(dev, my_midlayer_something);
|
||||
return 0;
|
||||
}
|
||||
|
||||
void my_midlayer_destroy_something()
|
||||
{
|
||||
devres_release_group(dev, my_midlayer_create_soemthing);
|
||||
}
|
||||
|
||||
|
||||
4. Details
|
||||
----------
|
||||
|
||||
Lifetime of a devres entry begins on devres allocation and finishes
|
||||
when it is released or destroyed (removed and freed) - no reference
|
||||
counting.
|
||||
|
||||
devres core guarantees atomicity to all basic devres operations and
|
||||
has support for single-instance devres types (atomic
|
||||
lookup-and-add-if-not-found). Other than that, synchronizing
|
||||
concurrent accesses to allocated devres data is caller's
|
||||
responsibility. This is usually non-issue because bus ops and
|
||||
resource allocations already do the job.
|
||||
|
||||
For an example of single-instance devres type, read pcim_iomap_table()
|
||||
in lib/iomap.c.
|
||||
|
||||
All devres interface functions can be called without context if the
|
||||
right gfp mask is given.
|
||||
|
||||
|
||||
5. Overhead
|
||||
-----------
|
||||
|
||||
Each devres bookkeeping info is allocated together with requested data
|
||||
area. With debug option turned off, bookkeeping info occupies 16
|
||||
bytes on 32bit machines and 24 bytes on 64bit (three pointers rounded
|
||||
up to ull alignment). If singly linked list is used, it can be
|
||||
reduced to two pointers (8 bytes on 32bit, 16 bytes on 64bit).
|
||||
|
||||
Each devres group occupies 8 pointers. It can be reduced to 6 if
|
||||
singly linked list is used.
|
||||
|
||||
Memory space overhead on ahci controller with two ports is between 300
|
||||
and 400 bytes on 32bit machine after naive conversion (we can
|
||||
certainly invest a bit more effort into libata core layer).
|
||||
|
||||
|
||||
6. List of managed interfaces
|
||||
-----------------------------
|
||||
|
||||
IO region
|
||||
devm_request_region()
|
||||
devm_request_mem_region()
|
||||
devm_release_region()
|
||||
devm_release_mem_region()
|
||||
|
||||
IRQ
|
||||
devm_request_irq()
|
||||
devm_free_irq()
|
||||
|
||||
DMA
|
||||
dmam_alloc_coherent()
|
||||
dmam_free_coherent()
|
||||
dmam_alloc_noncoherent()
|
||||
dmam_free_noncoherent()
|
||||
dmam_declare_coherent_memory()
|
||||
dmam_pool_create()
|
||||
dmam_pool_destroy()
|
||||
|
||||
PCI
|
||||
pcim_enable_device() : after success, all PCI ops become managed
|
||||
pcim_pin_device() : keep PCI device enabled after release
|
||||
|
||||
IOMAP
|
||||
devm_ioport_map()
|
||||
devm_ioport_unmap()
|
||||
devm_ioremap()
|
||||
devm_ioremap_nocache()
|
||||
devm_iounmap()
|
||||
pcim_iomap()
|
||||
pcim_iounmap()
|
||||
pcim_iomap_table() : array of mapped addresses indexed by BAR
|
||||
pcim_iomap_regions() : do request_region() and iomap() on multiple BARs
|
||||
@@ -66,7 +66,7 @@ runtime memory footprint:
|
||||
|
||||
Device Enumeration
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
As a rule, platform specific (and often board-specific) setup code wil
|
||||
As a rule, platform specific (and often board-specific) setup code will
|
||||
register platform devices:
|
||||
|
||||
int platform_device_register(struct platform_device *pdev);
|
||||
@@ -106,7 +106,7 @@ It's built from two components:
|
||||
* platform_device.id ... the device instance number, or else "-1"
|
||||
to indicate there's only one.
|
||||
|
||||
These are catenated, so name/id "serial"/0 indicates bus_id "serial.0", and
|
||||
These are concatenated, so name/id "serial"/0 indicates bus_id "serial.0", and
|
||||
"serial/3" indicates bus_id "serial.3"; both would use the platform_driver
|
||||
named "serial". While "my_rtc"/-1 would be bus_id "my_rtc" (no instance id)
|
||||
and use the platform_driver called "my_rtc".
|
||||
|
||||
@@ -339,7 +339,21 @@ Device Symlink:
|
||||
|
||||
'device'
|
||||
|
||||
Symlink to the memory controller device
|
||||
Symlink to the memory controller device.
|
||||
|
||||
Sdram memory scrubbing rate:
|
||||
|
||||
'sdram_scrub_rate'
|
||||
|
||||
Read/Write attribute file that controls memory scrubbing. The scrubbing
|
||||
rate is set by writing a minimum bandwith in bytes/sec to the attribute
|
||||
file. The rate will be translated to an internal value that gives at
|
||||
least the specified rate.
|
||||
|
||||
Reading the file will return the actual scrubbing rate employed.
|
||||
|
||||
If configuration fails or memory scrubbing is not implemented, the value
|
||||
of the attribute file will be -1.
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,78 @@
|
||||
|
||||
s3fb - fbdev driver for S3 Trio/Virge chips
|
||||
===========================================
|
||||
|
||||
|
||||
Supported Hardware
|
||||
==================
|
||||
|
||||
S3 Trio32
|
||||
S3 Trio64 (and variants V+, UV+, V2/DX, V2/GX)
|
||||
S3 Virge (and variants VX, DX, GX and GX2+)
|
||||
S3 Plato/PX (completely untested)
|
||||
S3 Aurora64V+ (completely untested)
|
||||
|
||||
- only PCI bus supported
|
||||
- only BIOS initialized VGA devices supported
|
||||
- probably not working on big endian
|
||||
|
||||
I tested s3fb on Trio64 (plain, V+ and V2/DX) and Virge (plain, VX, DX),
|
||||
all on i386.
|
||||
|
||||
|
||||
Supported Features
|
||||
==================
|
||||
|
||||
* 4 bpp pseudocolor modes (with 18bit palette, two variants)
|
||||
* 8 bpp pseudocolor mode (with 18bit palette)
|
||||
* 16 bpp truecolor modes (RGB 555 and RGB 565)
|
||||
* 24 bpp truecolor mode (RGB 888) on (only on Virge VX)
|
||||
* 32 bpp truecolor mode (RGB 888) on (not on Virge VX)
|
||||
* text mode (activated by bpp = 0)
|
||||
* interlaced mode variant (not available in text mode)
|
||||
* doublescan mode variant (not available in text mode)
|
||||
* panning in both directions
|
||||
* suspend/resume support
|
||||
* DPMS support
|
||||
|
||||
Text mode is supported even in higher resolutions, but there is limitation
|
||||
to lower pixclocks (maximum between 50-60 MHz, depending on specific hardware).
|
||||
This limitation is not enforced by driver. Text mode supports 8bit wide fonts
|
||||
only (hardware limitation) and 16bit tall fonts (driver limitation).
|
||||
|
||||
There are two 4 bpp modes. First mode (selected if nonstd == 0) is mode with
|
||||
packed pixels, high nibble first. Second mode (selected if nonstd == 1) is mode
|
||||
with interleaved planes (1 byte interleave), MSB first. Both modes support
|
||||
8bit wide fonts only (driver limitation).
|
||||
|
||||
Suspend/resume works on systems that initialize video card during resume and
|
||||
if device is active (for example used by fbcon).
|
||||
|
||||
|
||||
Missing Features
|
||||
================
|
||||
(alias TODO list)
|
||||
|
||||
* secondary (not initialized by BIOS) device support
|
||||
* big endian support
|
||||
* Zorro bus support
|
||||
* MMIO support
|
||||
* 24 bpp mode support on more cards
|
||||
* support for fontwidths != 8 in 4 bpp modes
|
||||
* support for fontheight != 16 in text mode
|
||||
* composite and external sync (is anyone able to test this?)
|
||||
* hardware cursor
|
||||
* video overlay support
|
||||
* vsync synchronization
|
||||
* feature connector support
|
||||
* acceleration support (8514-like 2D, Virge 3D, busmaster transfers)
|
||||
* better values for some magic registers (performance issues)
|
||||
|
||||
|
||||
Known bugs
|
||||
==========
|
||||
|
||||
* cursor disable in text mode doesn't work
|
||||
|
||||
--
|
||||
Ondrej Zajicek <santiago@crfreenet.org>
|
||||
@@ -50,22 +50,6 @@ Who: Dan Dennedy <dan@dennedy.org>, Stefan Richter <stefanr@s5r6.in-berlin.de>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: ieee1394 core's unused exports (CONFIG_IEEE1394_EXPORT_FULL_API)
|
||||
When: January 2007
|
||||
Why: There are no projects known to use these exported symbols, except
|
||||
dfg1394 (uses one symbol whose functionality is core-internal now).
|
||||
Who: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: ieee1394's *_oui sysfs attributes (CONFIG_IEEE1394_OUI_DB)
|
||||
When: January 2007
|
||||
Files: drivers/ieee1394/: oui.db, oui2c.sh
|
||||
Why: big size, little value
|
||||
Who: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: Video4Linux API 1 ioctls and video_decoder.h from Video devices.
|
||||
When: December 2006
|
||||
Why: V4L1 AP1 was replaced by V4L2 API. during migration from 2.4 to 2.6
|
||||
@@ -186,18 +170,6 @@ Who: Greg Kroah-Hartman <gregkh@suse.de>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: find_trylock_page
|
||||
When: January 2007
|
||||
Why: The interface no longer has any callers left in the kernel. It
|
||||
is an odd interface (compared with other find_*_page functions), in
|
||||
that it does not take a refcount to the page, only the page lock.
|
||||
It should be replaced with find_get_page or find_lock_page if possible.
|
||||
This feature removal can be reevaluated if users of the interface
|
||||
cannot cleanly use something else.
|
||||
Who: Nick Piggin <npiggin@suse.de>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: Interrupt only SA_* flags
|
||||
When: Januar 2007
|
||||
Why: The interrupt related SA_* flags are replaced by IRQF_* to move them
|
||||
@@ -243,6 +215,13 @@ Who: Jean Delvare <khali@linux-fr.org>,
|
||||
|
||||
---------------------------
|
||||
|
||||
What: drivers depending on OBSOLETE_OSS
|
||||
When: options in 2.6.22, code in 2.6.24
|
||||
Why: OSS drivers with ALSA replacements
|
||||
Who: Adrian Bunk <bunk@stusta.de>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: IPv4 only connection tracking/NAT/helpers
|
||||
When: 2.6.22
|
||||
Why: The new layer 3 independant connection tracking replaces the old
|
||||
@@ -274,28 +253,6 @@ Who: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: ACPI hotkey driver (CONFIG_ACPI_HOTKEY)
|
||||
When: 2.6.21
|
||||
Why: hotkey.c was an attempt to consolidate multiple drivers that use
|
||||
ACPI to implement hotkeys. However, hotkeys are not documented
|
||||
in the ACPI specification, so the drivers used undocumented
|
||||
vendor-specific hooks and turned out to be more different than
|
||||
the same.
|
||||
|
||||
Further, the keys and the features supplied by each platform
|
||||
are different, so there will always be a need for
|
||||
platform-specific drivers.
|
||||
|
||||
So the new plan is to delete hotkey.c and instead, work on the
|
||||
platform specific drivers to try to make them look the same
|
||||
to the user when they supply the same features.
|
||||
|
||||
hotkey.c has always depended on CONFIG_EXPERIMENTAL
|
||||
|
||||
Who: Len Brown <len.brown@intel.com>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: /sys/firmware/acpi/namespace
|
||||
When: 2.6.21
|
||||
Why: The ACPI namespace is effectively the symbol list for
|
||||
@@ -306,11 +263,18 @@ Why: The ACPI namespace is effectively the symbol list for
|
||||
the BIOS can be extracted and disassembled with acpidump
|
||||
and iasl as documented in the pmtools package here:
|
||||
http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils
|
||||
|
||||
Who: Len Brown <len.brown@intel.com>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: ACPI procfs interface
|
||||
When: July 2007
|
||||
Why: After ACPI sysfs conversion, ACPI attributes will be duplicated
|
||||
in sysfs and the ACPI procfs interface should be removed.
|
||||
Who: Zhang Rui <rui.zhang@intel.com>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: /proc/acpi/button
|
||||
When: August 2007
|
||||
Why: /proc/acpi/button has been replaced by events to the input layer
|
||||
@@ -319,9 +283,24 @@ Who: Len Brown <len.brown@intel.com>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: JFFS (version 1)
|
||||
When: 2.6.21
|
||||
Why: Unmaintained for years, superceded by JFFS2 for years.
|
||||
Who: Jeff Garzik <jeff@garzik.org>
|
||||
What: sk98lin network driver
|
||||
When: July 2007
|
||||
Why: In kernel tree version of driver is unmaintained. Sk98lin driver
|
||||
replaced by the skge driver.
|
||||
Who: Stephen Hemminger <shemminger@osdl.org>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: Compaq touchscreen device emulation
|
||||
When: Oct 2007
|
||||
Files: drivers/input/tsdev.c
|
||||
Why: The code says it was obsolete when it was written in 2001.
|
||||
tslib is a userspace library which does anything tsdev can do and
|
||||
much more besides in userspace where this code belongs. There is no
|
||||
longer any need for tsdev and applications should have converted to
|
||||
use tslib by now.
|
||||
The name "tsdev" is also extremely confusing and lots of people have
|
||||
it loaded when they don't need/use it.
|
||||
Who: Richard Purdie <rpurdie@rpsys.net>
|
||||
|
||||
---------------------------
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user