mirror of https://gitee.com/openkylin/linux.git
Merge branch 'linus' into x86/cleanups
This commit is contained in:
Ingo Molnar
commit
6de9c70882
|
|
@ -89,8 +89,6 @@ cciss.txt
|
|||
- info, major/minor #'s for Compaq's SMART Array Controllers.
|
||||
cdrom/
|
||||
- directory with information on the CD-ROM drivers that Linux has.
|
||||
cli-sti-removal.txt
|
||||
- cli()/sti() removal guide.
|
||||
computone.txt
|
||||
- info on Computone Intelliport II/Plus Multiport Serial Driver.
|
||||
connector/
|
||||
|
|
|
|||
|
|
@ -0,0 +1,315 @@
|
|||
What: /sys/class/regulator/.../state
|
||||
Date: April 2008
|
||||
KernelVersion: 2.6.26
|
||||
Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com>
|
||||
Description:
|
||||
Each regulator directory will contain a field called
|
||||
state. This holds the regulator output state.
|
||||
|
||||
This will be one of the following strings:
|
||||
|
||||
'enabled'
|
||||
'disabled'
|
||||
'unknown'
|
||||
|
||||
'enabled' means the regulator output is ON and is supplying
|
||||
power to the system.
|
||||
|
||||
'disabled' means the regulator output is OFF and is not
|
||||
supplying power to the system..
|
||||
|
||||
'unknown' means software cannot determine the state.
|
||||
|
||||
NOTE: this field can be used in conjunction with microvolts
|
||||
and microamps to determine regulator output levels.
|
||||
|
||||
|
||||
What: /sys/class/regulator/.../type
|
||||
Date: April 2008
|
||||
KernelVersion: 2.6.26
|
||||
Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com>
|
||||
Description:
|
||||
Each regulator directory will contain a field called
|
||||
type. This holds the regulator type.
|
||||
|
||||
This will be one of the following strings:
|
||||
|
||||
'voltage'
|
||||
'current'
|
||||
'unknown'
|
||||
|
||||
'voltage' means the regulator output voltage can be controlled
|
||||
by software.
|
||||
|
||||
'current' means the regulator output current limit can be
|
||||
controlled by software.
|
||||
|
||||
'unknown' means software cannot control either voltage or
|
||||
current limit.
|
||||
|
||||
|
||||
What: /sys/class/regulator/.../microvolts
|
||||
Date: April 2008
|
||||
KernelVersion: 2.6.26
|
||||
Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com>
|
||||
Description:
|
||||
Each regulator directory will contain a field called
|
||||
microvolts. This holds the regulator output voltage setting
|
||||
measured in microvolts (i.e. E-6 Volts).
|
||||
|
||||
NOTE: This value should not be used to determine the regulator
|
||||
output voltage level as this value is the same regardless of
|
||||
whether the regulator is enabled or disabled.
|
||||
|
||||
|
||||
What: /sys/class/regulator/.../microamps
|
||||
Date: April 2008
|
||||
KernelVersion: 2.6.26
|
||||
Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com>
|
||||
Description:
|
||||
Each regulator directory will contain a field called
|
||||
microamps. This holds the regulator output current limit
|
||||
setting measured in microamps (i.e. E-6 Amps).
|
||||
|
||||
NOTE: This value should not be used to determine the regulator
|
||||
output current level as this value is the same regardless of
|
||||
whether the regulator is enabled or disabled.
|
||||
|
||||
|
||||
What: /sys/class/regulator/.../opmode
|
||||
Date: April 2008
|
||||
KernelVersion: 2.6.26
|
||||
Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com>
|
||||
Description:
|
||||
Each regulator directory will contain a field called
|
||||
opmode. This holds the regulator operating mode setting.
|
||||
|
||||
The opmode value can be one of the following strings:
|
||||
|
||||
'fast'
|
||||
'normal'
|
||||
'idle'
|
||||
'standby'
|
||||
'unknown'
|
||||
|
||||
The modes are described in include/linux/regulator/regulator.h
|
||||
|
||||
NOTE: This value should not be used to determine the regulator
|
||||
output operating mode as this value is the same regardless of
|
||||
whether the regulator is enabled or disabled.
|
||||
|
||||
|
||||
What: /sys/class/regulator/.../min_microvolts
|
||||
Date: April 2008
|
||||
KernelVersion: 2.6.26
|
||||
Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com>
|
||||
Description:
|
||||
Each regulator directory will contain a field called
|
||||
min_microvolts. This holds the minimum safe working regulator
|
||||
output voltage setting for this domain measured in microvolts.
|
||||
|
||||
NOTE: this will return the string 'constraint not defined' if
|
||||
the power domain has no min microvolts constraint defined by
|
||||
platform code.
|
||||
|
||||
|
||||
What: /sys/class/regulator/.../max_microvolts
|
||||
Date: April 2008
|
||||
KernelVersion: 2.6.26
|
||||
Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com>
|
||||
Description:
|
||||
Each regulator directory will contain a field called
|
||||
max_microvolts. This holds the maximum safe working regulator
|
||||
output voltage setting for this domain measured in microvolts.
|
||||
|
||||
NOTE: this will return the string 'constraint not defined' if
|
||||
the power domain has no max microvolts constraint defined by
|
||||
platform code.
|
||||
|
||||
|
||||
What: /sys/class/regulator/.../min_microamps
|
||||
Date: April 2008
|
||||
KernelVersion: 2.6.26
|
||||
Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com>
|
||||
Description:
|
||||
Each regulator directory will contain a field called
|
||||
min_microamps. This holds the minimum safe working regulator
|
||||
output current limit setting for this domain measured in
|
||||
microamps.
|
||||
|
||||
NOTE: this will return the string 'constraint not defined' if
|
||||
the power domain has no min microamps constraint defined by
|
||||
platform code.
|
||||
|
||||
|
||||
What: /sys/class/regulator/.../max_microamps
|
||||
Date: April 2008
|
||||
KernelVersion: 2.6.26
|
||||
Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com>
|
||||
Description:
|
||||
Each regulator directory will contain a field called
|
||||
max_microamps. This holds the maximum safe working regulator
|
||||
output current limit setting for this domain measured in
|
||||
microamps.
|
||||
|
||||
NOTE: this will return the string 'constraint not defined' if
|
||||
the power domain has no max microamps constraint defined by
|
||||
platform code.
|
||||
|
||||
|
||||
What: /sys/class/regulator/.../num_users
|
||||
Date: April 2008
|
||||
KernelVersion: 2.6.26
|
||||
Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com>
|
||||
Description:
|
||||
Each regulator directory will contain a field called
|
||||
num_users. This holds the number of consumer devices that
|
||||
have called regulator_enable() on this regulator.
|
||||
|
||||
|
||||
What: /sys/class/regulator/.../requested_microamps
|
||||
Date: April 2008
|
||||
KernelVersion: 2.6.26
|
||||
Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com>
|
||||
Description:
|
||||
Each regulator directory will contain a field called
|
||||
requested_microamps. This holds the total requested load
|
||||
current in microamps for this regulator from all its consumer
|
||||
devices.
|
||||
|
||||
|
||||
What: /sys/class/regulator/.../parent
|
||||
Date: April 2008
|
||||
KernelVersion: 2.6.26
|
||||
Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com>
|
||||
Description:
|
||||
Some regulator directories will contain a link called parent.
|
||||
This points to the parent or supply regulator if one exists.
|
||||
|
||||
What: /sys/class/regulator/.../suspend_mem_microvolts
|
||||
Date: May 2008
|
||||
KernelVersion: 2.6.26
|
||||
Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com>
|
||||
Description:
|
||||
Each regulator directory will contain a field called
|
||||
suspend_mem_microvolts. This holds the regulator output
|
||||
voltage setting for this domain measured in microvolts when
|
||||
the system is suspended to memory.
|
||||
|
||||
NOTE: this will return the string 'not defined' if
|
||||
the power domain has no suspend to memory voltage defined by
|
||||
platform code.
|
||||
|
||||
What: /sys/class/regulator/.../suspend_disk_microvolts
|
||||
Date: May 2008
|
||||
KernelVersion: 2.6.26
|
||||
Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com>
|
||||
Description:
|
||||
Each regulator directory will contain a field called
|
||||
suspend_disk_microvolts. This holds the regulator output
|
||||
voltage setting for this domain measured in microvolts when
|
||||
the system is suspended to disk.
|
||||
|
||||
NOTE: this will return the string 'not defined' if
|
||||
the power domain has no suspend to disk voltage defined by
|
||||
platform code.
|
||||
|
||||
What: /sys/class/regulator/.../suspend_standby_microvolts
|
||||
Date: May 2008
|
||||
KernelVersion: 2.6.26
|
||||
Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com>
|
||||
Description:
|
||||
Each regulator directory will contain a field called
|
||||
suspend_standby_microvolts. This holds the regulator output
|
||||
voltage setting for this domain measured in microvolts when
|
||||
the system is suspended to standby.
|
||||
|
||||
NOTE: this will return the string 'not defined' if
|
||||
the power domain has no suspend to standby voltage defined by
|
||||
platform code.
|
||||
|
||||
What: /sys/class/regulator/.../suspend_mem_mode
|
||||
Date: May 2008
|
||||
KernelVersion: 2.6.26
|
||||
Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com>
|
||||
Description:
|
||||
Each regulator directory will contain a field called
|
||||
suspend_mem_mode. This holds the regulator operating mode
|
||||
setting for this domain when the system is suspended to
|
||||
memory.
|
||||
|
||||
NOTE: this will return the string 'not defined' if
|
||||
the power domain has no suspend to memory mode defined by
|
||||
platform code.
|
||||
|
||||
What: /sys/class/regulator/.../suspend_disk_mode
|
||||
Date: May 2008
|
||||
KernelVersion: 2.6.26
|
||||
Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com>
|
||||
Description:
|
||||
Each regulator directory will contain a field called
|
||||
suspend_disk_mode. This holds the regulator operating mode
|
||||
setting for this domain when the system is suspended to disk.
|
||||
|
||||
NOTE: this will return the string 'not defined' if
|
||||
the power domain has no suspend to disk mode defined by
|
||||
platform code.
|
||||
|
||||
What: /sys/class/regulator/.../suspend_standby_mode
|
||||
Date: May 2008
|
||||
KernelVersion: 2.6.26
|
||||
Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com>
|
||||
Description:
|
||||
Each regulator directory will contain a field called
|
||||
suspend_standby_mode. This holds the regulator operating mode
|
||||
setting for this domain when the system is suspended to
|
||||
standby.
|
||||
|
||||
NOTE: this will return the string 'not defined' if
|
||||
the power domain has no suspend to standby mode defined by
|
||||
platform code.
|
||||
|
||||
What: /sys/class/regulator/.../suspend_mem_state
|
||||
Date: May 2008
|
||||
KernelVersion: 2.6.26
|
||||
Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com>
|
||||
Description:
|
||||
Each regulator directory will contain a field called
|
||||
suspend_mem_state. This holds the regulator operating state
|
||||
when suspended to memory.
|
||||
|
||||
This will be one of the following strings:
|
||||
|
||||
'enabled'
|
||||
'disabled'
|
||||
'not defined'
|
||||
|
||||
What: /sys/class/regulator/.../suspend_disk_state
|
||||
Date: May 2008
|
||||
KernelVersion: 2.6.26
|
||||
Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com>
|
||||
Description:
|
||||
Each regulator directory will contain a field called
|
||||
suspend_disk_state. This holds the regulator operating state
|
||||
when suspended to disk.
|
||||
|
||||
This will be one of the following strings:
|
||||
|
||||
'enabled'
|
||||
'disabled'
|
||||
'not defined'
|
||||
|
||||
What: /sys/class/regulator/.../suspend_standby_state
|
||||
Date: May 2008
|
||||
KernelVersion: 2.6.26
|
||||
Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com>
|
||||
Description:
|
||||
Each regulator directory will contain a field called
|
||||
suspend_standby_state. This holds the regulator operating
|
||||
state when suspended to standby.
|
||||
|
||||
This will be one of the following strings:
|
||||
|
||||
'enabled'
|
||||
'disabled'
|
||||
'not defined'
|
||||
|
|
@ -298,10 +298,10 @@ recommended that you never use these unless you really know what the
|
|||
cache width is.
|
||||
|
||||
int
|
||||
dma_mapping_error(dma_addr_t dma_addr)
|
||||
dma_mapping_error(struct device *dev, dma_addr_t dma_addr)
|
||||
|
||||
int
|
||||
pci_dma_mapping_error(dma_addr_t dma_addr)
|
||||
pci_dma_mapping_error(struct pci_dev *hwdev, dma_addr_t dma_addr)
|
||||
|
||||
In some circumstances dma_map_single and dma_map_page will fail to create
|
||||
a mapping. A driver can check for these errors by testing the returned
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ DOCBOOKS := wanbook.xml z8530book.xml mcabook.xml videobook.xml \
|
|||
kernel-api.xml filesystems.xml lsm.xml usb.xml kgdb.xml \
|
||||
gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \
|
||||
genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml \
|
||||
mac80211.xml debugobjects.xml
|
||||
mac80211.xml debugobjects.xml sh.xml
|
||||
|
||||
###
|
||||
# The build process is as follows (targets):
|
||||
|
|
|
|||
|
|
@ -98,6 +98,24 @@
|
|||
"Kernel debugging" select "KGDB: kernel debugging with remote gdb".
|
||||
</para>
|
||||
<para>
|
||||
It is advised, but not required that you turn on the
|
||||
CONFIG_FRAME_POINTER kernel option. This option inserts code to
|
||||
into the compiled executable which saves the frame information in
|
||||
registers or on the stack at different points which will allow a
|
||||
debugger such as gdb to more accurately construct stack back traces
|
||||
while debugging the kernel.
|
||||
</para>
|
||||
<para>
|
||||
If the architecture that you are using supports the kernel option
|
||||
CONFIG_DEBUG_RODATA, you should consider turning it off. This
|
||||
option will prevent the use of software breakpoints because it
|
||||
marks certain regions of the kernel's memory space as read-only.
|
||||
If kgdb supports it for the architecture you are using, you can
|
||||
use hardware breakpoints if you desire to run with the
|
||||
CONFIG_DEBUG_RODATA option turned on, else you need to turn off
|
||||
this option.
|
||||
</para>
|
||||
<para>
|
||||
Next you should choose one of more I/O drivers to interconnect debugging
|
||||
host and debugged target. Early boot debugging requires a KGDB
|
||||
I/O driver that supports early debugging and the driver must be
|
||||
|
|
|
|||
|
|
@ -100,7 +100,7 @@
|
|||
the hardware structures represented here, please consult the Principles
|
||||
of Operation.
|
||||
</para>
|
||||
!Iinclude/asm-s390/cio.h
|
||||
!Iarch/s390/include/asm/cio.h
|
||||
</sect1>
|
||||
<sect1 id="ccwdev">
|
||||
<title>ccw devices</title>
|
||||
|
|
@ -114,7 +114,7 @@
|
|||
ccw device structure. Device drivers must not bypass those functions
|
||||
or strange side effects may happen.
|
||||
</para>
|
||||
!Iinclude/asm-s390/ccwdev.h
|
||||
!Iarch/s390/include/asm/ccwdev.h
|
||||
!Edrivers/s390/cio/device.c
|
||||
!Edrivers/s390/cio/device_ops.c
|
||||
</sect1>
|
||||
|
|
@ -125,7 +125,7 @@
|
|||
measurement data which is made available by the channel subsystem
|
||||
for each channel attached device.
|
||||
</para>
|
||||
!Iinclude/asm-s390/cmb.h
|
||||
!Iarch/s390/include/asm/cmb.h
|
||||
!Edrivers/s390/cio/cmf.c
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
|
@ -142,7 +142,7 @@
|
|||
</para>
|
||||
<sect1 id="ccwgroupdevices">
|
||||
<title>ccw group devices</title>
|
||||
!Iinclude/asm-s390/ccwgroup.h
|
||||
!Iarch/s390/include/asm/ccwgroup.h
|
||||
!Edrivers/s390/cio/ccwgroup.c
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
|
|
|||
|
|
@ -0,0 +1,105 @@
|
|||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []>
|
||||
|
||||
<book id="sh-drivers">
|
||||
<bookinfo>
|
||||
<title>SuperH Interfaces Guide</title>
|
||||
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>Paul</firstname>
|
||||
<surname>Mundt</surname>
|
||||
<affiliation>
|
||||
<address>
|
||||
<email>lethal@linux-sh.org</email>
|
||||
</address>
|
||||
</affiliation>
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<copyright>
|
||||
<year>2008</year>
|
||||
<holder>Paul Mundt</holder>
|
||||
</copyright>
|
||||
<copyright>
|
||||
<year>2008</year>
|
||||
<holder>Renesas Technology Corp.</holder>
|
||||
</copyright>
|
||||
|
||||
<legalnotice>
|
||||
<para>
|
||||
This documentation 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.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
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.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
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
|
||||
</para>
|
||||
|
||||
<para>
|
||||
For more details see the file COPYING in the source
|
||||
distribution of Linux.
|
||||
</para>
|
||||
</legalnotice>
|
||||
</bookinfo>
|
||||
|
||||
<toc></toc>
|
||||
|
||||
<chapter id="mm">
|
||||
<title>Memory Management</title>
|
||||
<sect1 id="sh4">
|
||||
<title>SH-4</title>
|
||||
<sect2 id="sq">
|
||||
<title>Store Queue API</title>
|
||||
!Earch/sh/kernel/cpu/sh4/sq.c
|
||||
</sect2>
|
||||
</sect1>
|
||||
<sect1 id="sh5">
|
||||
<title>SH-5</title>
|
||||
<sect2 id="tlb">
|
||||
<title>TLB Interfaces</title>
|
||||
!Iarch/sh/mm/tlb-sh5.c
|
||||
!Iarch/sh/include/asm/tlb_64.h
|
||||
</sect2>
|
||||
</sect1>
|
||||
</chapter>
|
||||
<chapter id="clk">
|
||||
<title>Clock Framework Extensions</title>
|
||||
!Iarch/sh/include/asm/clock.h
|
||||
</chapter>
|
||||
<chapter id="mach">
|
||||
<title>Machine Specific Interfaces</title>
|
||||
<sect1 id="dreamcast">
|
||||
<title>mach-dreamcast</title>
|
||||
!Iarch/sh/boards/mach-dreamcast/rtc.c
|
||||
</sect1>
|
||||
<sect1 id="x3proto">
|
||||
<title>mach-x3proto</title>
|
||||
!Earch/sh/boards/mach-x3proto/ilsel.c
|
||||
</sect1>
|
||||
</chapter>
|
||||
<chapter id="busses">
|
||||
<title>Busses</title>
|
||||
<sect1 id="superhyway">
|
||||
<title>SuperHyway</title>
|
||||
!Edrivers/sh/superhyway/superhyway.c
|
||||
</sect1>
|
||||
|
||||
<sect1 id="maple">
|
||||
<title>Maple</title>
|
||||
!Edrivers/sh/maple/maple.c
|
||||
</sect1>
|
||||
</chapter>
|
||||
</book>
|
||||
|
|
@ -1648,7 +1648,7 @@ static struct video_buffer capture_fb;
|
|||
|
||||
<chapter id="pubfunctions">
|
||||
<title>Public Functions Provided</title>
|
||||
!Edrivers/media/video/videodev.c
|
||||
!Edrivers/media/video/v4l2-dev.c
|
||||
</chapter>
|
||||
|
||||
</book>
|
||||
|
|
|
|||
|
|
@ -69,12 +69,6 @@
|
|||
device to be used as both a tty interface and as a synchronous
|
||||
controller is a project for Linux post the 2.4 release
|
||||
</para>
|
||||
<para>
|
||||
The support code handles most common card configurations and
|
||||
supports running both Cisco HDLC and Synchronous PPP. With extra
|
||||
glue the frame relay and X.25 protocols can also be used with this
|
||||
driver.
|
||||
</para>
|
||||
</chapter>
|
||||
|
||||
<chapter id="Driver_Modes">
|
||||
|
|
@ -179,35 +173,27 @@
|
|||
<para>
|
||||
If you wish to use the network interface facilities of the driver,
|
||||
then you need to attach a network device to each channel that is
|
||||
present and in use. In addition to use the SyncPPP and Cisco HDLC
|
||||
present and in use. In addition to use the generic HDLC
|
||||
you need to follow some additional plumbing rules. They may seem
|
||||
complex but a look at the example hostess_sv11 driver should
|
||||
reassure you.
|
||||
</para>
|
||||
<para>
|
||||
The network device used for each channel should be pointed to by
|
||||
the netdevice field of each channel. The dev-> priv field of the
|
||||
the netdevice field of each channel. The hdlc-> priv field of the
|
||||
network device points to your private data - you will need to be
|
||||
able to find your ppp device from this. In addition to use the
|
||||
sync ppp layer the private data must start with a void * pointer
|
||||
to the syncppp structures.
|
||||
able to find your private data from this.
|
||||
</para>
|
||||
<para>
|
||||
The way most drivers approach this particular problem is to
|
||||
create a structure holding the Z8530 device definition and
|
||||
put that and the syncppp pointer into the private field of
|
||||
the network device. The network device fields of the channels
|
||||
then point back to the network devices. The ppp_device can also
|
||||
be put in the private structure conveniently.
|
||||
put that into the private field of the network device. The
|
||||
network device fields of the channels then point back to the
|
||||
network devices.
|
||||
</para>
|
||||
<para>
|
||||
If you wish to use the synchronous ppp then you need to attach
|
||||
the syncppp layer to the network device. You should do this before
|
||||
you register the network device. The
|
||||
<function>sppp_attach</function> requires that the first void *
|
||||
pointer in your private data is pointing to an empty struct
|
||||
ppp_device. The function fills in the initial data for the
|
||||
ppp/hdlc layer.
|
||||
If you wish to use the generic HDLC then you need to register
|
||||
the HDLC device.
|
||||
</para>
|
||||
<para>
|
||||
Before you register your network device you will also need to
|
||||
|
|
@ -314,10 +300,10 @@
|
|||
buffer in sk_buff format and queues it for transmission. The
|
||||
caller must provide the entire packet with the exception of the
|
||||
bitstuffing and CRC. This is normally done by the caller via
|
||||
the syncppp interface layer. It returns 0 if the buffer has been
|
||||
queued and non zero values for queue full. If the function accepts
|
||||
the buffer it becomes property of the Z8530 layer and the caller
|
||||
should not free it.
|
||||
the generic HDLC interface layer. It returns 0 if the buffer has been
|
||||
queued and non zero values for queue full. If the function accepts
|
||||
the buffer it becomes property of the Z8530 layer and the caller
|
||||
should not free it.
|
||||
</para>
|
||||
<para>
|
||||
The function <function>z8530_get_stats</function> returns a pointer
|
||||
|
|
|
|||
|
|
@ -48,7 +48,7 @@ IOVA generation is pretty generic. We used the same technique as vmalloc()
|
|||
but these are not global address spaces, but separate for each domain.
|
||||
Different DMA engines may support different number of domains.
|
||||
|
||||
We also allocate gaurd pages with each mapping, so we can attempt to catch
|
||||
We also allocate guard pages with each mapping, so we can attempt to catch
|
||||
any overflow that might happen.
|
||||
|
||||
|
||||
|
|
@ -112,4 +112,4 @@ TBD
|
|||
|
||||
- For compatibility testing, could use unity map domain for all devices, just
|
||||
provide a 1-1 for all useful memory under a single domain for all devices.
|
||||
- API for paravirt ops for abstracting functionlity for VMM folks.
|
||||
- API for paravirt ops for abstracting functionality for VMM folks.
|
||||
|
|
|
|||
|
|
@ -528,7 +528,33 @@ See more details on the proper patch format in the following
|
|||
references.
|
||||
|
||||
|
||||
16) Sending "git pull" requests (from Linus emails)
|
||||
|
||||
Please write the git repo address and branch name alone on the same line
|
||||
so that I can't even by mistake pull from the wrong branch, and so
|
||||
that a triple-click just selects the whole thing.
|
||||
|
||||
So the proper format is something along the lines of:
|
||||
|
||||
"Please pull from
|
||||
|
||||
git://jdelvare.pck.nerim.net/jdelvare-2.6 i2c-for-linus
|
||||
|
||||
to get these changes:"
|
||||
|
||||
so that I don't have to hunt-and-peck for the address and inevitably
|
||||
get it wrong (actually, I've only gotten it wrong a few times, and
|
||||
checking against the diffstat tells me when I get it wrong, but I'm
|
||||
just a lot more comfortable when I don't have to "look for" the right
|
||||
thing to pull, and double-check that I have the right branch-name).
|
||||
|
||||
|
||||
Please use "git diff -M --stat --summary" to generate the diffstat:
|
||||
the -M enables rename detection, and the summary enables a summary of
|
||||
new/deleted or renamed files.
|
||||
|
||||
With rename detection, the statistics are rather different [...]
|
||||
because git will notice that a fair number of the changes are renames.
|
||||
|
||||
-----------------------------------
|
||||
SECTION 2 - HINTS, TIPS, AND TRICKS
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ This document contains an explanation of the struct taskstats fields.
|
|||
There are three different groups of fields in the struct taskstats:
|
||||
|
||||
1) Common and basic accounting fields
|
||||
If CONFIG_TASKSTATS is set, the taskstats inteface is enabled and
|
||||
If CONFIG_TASKSTATS is set, the taskstats interface is enabled and
|
||||
the common fields and basic accounting fields are collected for
|
||||
delivery at do_exit() of a task.
|
||||
2) Delay accounting fields
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ Linux currently supports the following features on the IXP4xx chips:
|
|||
- Flash access (MTD/JFFS)
|
||||
- I2C through GPIO on IXP42x
|
||||
- GPIO for input/output/interrupts
|
||||
See include/asm-arm/arch-ixp4xx/platform.h for access functions.
|
||||
See arch/arm/mach-ixp4xx/include/mach/platform.h for access functions.
|
||||
- Timers (watchdog, OS)
|
||||
|
||||
The following components of the chips are not supported by Linux and
|
||||
|
|
|
|||
|
|
@ -138,14 +138,8 @@ So, what's changed?
|
|||
|
||||
Set active the IRQ edge(s)/level. This replaces the
|
||||
SA1111 INTPOL manipulation, and the set_GPIO_IRQ_edge()
|
||||
function. Type should be one of the following:
|
||||
|
||||
#define IRQT_NOEDGE (0)
|
||||
#define IRQT_RISING (__IRQT_RISEDGE)
|
||||
#define IRQT_FALLING (__IRQT_FALEDGE)
|
||||
#define IRQT_BOTHEDGE (__IRQT_RISEDGE|__IRQT_FALEDGE)
|
||||
#define IRQT_LOW (__IRQT_LOWLVL)
|
||||
#define IRQT_HIGH (__IRQT_HIGHLVL)
|
||||
function. Type should be one of IRQ_TYPE_xxx defined in
|
||||
<linux/irq.h>
|
||||
|
||||
3. set_GPIO_IRQ_edge() is obsolete, and should be replaced by set_irq_type.
|
||||
|
||||
|
|
@ -164,7 +158,7 @@ So, what's changed?
|
|||
be re-checked for pending events. (see the Neponset IRQ handler for
|
||||
details).
|
||||
|
||||
7. fixup_irq() is gone, as is include/asm-arm/arch-*/irq.h
|
||||
7. fixup_irq() is gone, as is arch/arm/mach-*/include/mach/irq.h
|
||||
|
||||
Please note that this will not solve all problems - some of them are
|
||||
hardware based. Mixing level-based and edge-based IRQs on the same
|
||||
|
|
|
|||
|
|
@ -79,7 +79,7 @@ Machine/Platform support
|
|||
To this end, we now have arch/arm/mach-$(MACHINE) directories which are
|
||||
designed to house the non-driver files for a particular machine (eg, PCI,
|
||||
memory management, architecture definitions etc). For all future
|
||||
machines, there should be a corresponding include/asm-arm/arch-$(MACHINE)
|
||||
machines, there should be a corresponding arch/arm/mach-$(MACHINE)/include/mach
|
||||
directory.
|
||||
|
||||
|
||||
|
|
@ -176,7 +176,7 @@ Kernel entry (head.S)
|
|||
class typically based around one or more system on a chip devices, and
|
||||
acts as a natural container around the actual implementations. These
|
||||
classes are given directories - arch/arm/mach-<class> and
|
||||
include/asm-arm/arch-<class> - which contain the source files to
|
||||
arch/arm/mach-<class> - which contain the source files to/include/mach
|
||||
support the machine class. This directories also contain any machine
|
||||
specific supporting code.
|
||||
|
||||
|
|
|
|||
|
|
@ -16,13 +16,13 @@ Introduction
|
|||
Headers
|
||||
-------
|
||||
|
||||
See include/asm-arm/arch-s3c2410/regs-gpio.h for the list
|
||||
See arch/arm/mach-s3c2410/include/mach/regs-gpio.h for the list
|
||||
of GPIO pins, and the configuration values for them. This
|
||||
is included by using #include <asm/arch/regs-gpio.h>
|
||||
is included by using #include <mach/regs-gpio.h>
|
||||
|
||||
The GPIO management functions are defined in the hardware
|
||||
header include/asm-arm/arch-s3c2410/hardware.h which can be
|
||||
included by #include <asm/arch/hardware.h>
|
||||
header arch/arm/mach-s3c2410/include/mach/hardware.h which can be
|
||||
included by #include <mach/hardware.h>
|
||||
|
||||
A useful amount of documentation can be found in the hardware
|
||||
header on how the GPIO functions (and others) work.
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ Layout
|
|||
in arch/arm/mach-s3c2410 and S3C2440 in arch/arm/mach-s3c2440
|
||||
|
||||
Register, kernel and platform data definitions are held in the
|
||||
include/asm-arm/arch-s3c2410 directory.
|
||||
arch/arm/mach-s3c2410 directory./include/mach
|
||||
|
||||
|
||||
Machines
|
||||
|
|
|
|||
|
|
@ -49,7 +49,7 @@ Board Support
|
|||
Platform Data
|
||||
-------------
|
||||
|
||||
See linux/include/asm-arm/arch-s3c2410/usb-control.h for the
|
||||
See arch/arm/mach-s3c2410/include/mach/usb-control.h for the
|
||||
descriptions of the platform device data. An implementation
|
||||
can be found in linux/arch/arm/mach-s3c2410/usb-simtec.c .
|
||||
|
||||
|
|
|
|||
|
|
@ -112,27 +112,18 @@ Hot plug support for SCSI tape drives
|
|||
|
||||
Hot plugging of SCSI tape drives is supported, with some caveats.
|
||||
The cciss driver must be informed that changes to the SCSI bus
|
||||
have been made, in addition to and prior to informing the SCSI
|
||||
mid layer. This may be done via the /proc filesystem. For example:
|
||||
have been made. This may be done via the /proc filesystem.
|
||||
For example:
|
||||
|
||||
echo "rescan" > /proc/scsi/cciss0/1
|
||||
|
||||
This causes the adapter to query the adapter about changes to the
|
||||
physical SCSI buses and/or fibre channel arbitrated loop and the
|
||||
This causes the driver to query the adapter about changes to the
|
||||
physical SCSI buses and/or fibre channel arbitrated loop and the
|
||||
driver to make note of any new or removed sequential access devices
|
||||
or medium changers. The driver will output messages indicating what
|
||||
devices have been added or removed and the controller, bus, target and
|
||||
lun used to address the device. Once this is done, the SCSI mid layer
|
||||
can be informed of changes to the virtual SCSI bus which the driver
|
||||
presents to it in the usual way. For example:
|
||||
|
||||
echo scsi add-single-device 3 2 1 0 > /proc/scsi/scsi
|
||||
|
||||
to add a device on controller 3, bus 2, target 1, lun 0. Note that
|
||||
the driver makes an effort to preserve the devices positions
|
||||
in the virtual SCSI bus, so if you are only moving tape drives
|
||||
around on the same adapter and not adding or removing tape drives
|
||||
from the adapter, informing the SCSI mid layer may not be necessary.
|
||||
lun used to address the device. It then notifies the SCSI mid layer
|
||||
of these changes.
|
||||
|
||||
Note that the naming convention of the /proc filesystem entries
|
||||
contains a number in addition to the driver name. (E.g. "cciss0"
|
||||
|
|
|
|||
|
|
@ -1,133 +0,0 @@
|
|||
|
||||
#### cli()/sti() removal guide, started by Ingo Molnar <mingo@redhat.com>
|
||||
|
||||
|
||||
as of 2.5.28, five popular macros have been removed on SMP, and
|
||||
are being phased out on UP:
|
||||
|
||||
cli(), sti(), save_flags(flags), save_flags_cli(flags), restore_flags(flags)
|
||||
|
||||
until now it was possible to protect driver code against interrupt
|
||||
handlers via a cli(), but from now on other, more lightweight methods
|
||||
have to be used for synchronization, such as spinlocks or semaphores.
|
||||
|
||||
for example, driver code that used to do something like:
|
||||
|
||||
struct driver_data;
|
||||
|
||||
irq_handler (...)
|
||||
{
|
||||
....
|
||||
driver_data.finish = 1;
|
||||
driver_data.new_work = 0;
|
||||
....
|
||||
}
|
||||
|
||||
...
|
||||
|
||||
ioctl_func (...)
|
||||
{
|
||||
...
|
||||
cli();
|
||||
...
|
||||
driver_data.finish = 0;
|
||||
driver_data.new_work = 2;
|
||||
...
|
||||
sti();
|
||||
...
|
||||
}
|
||||
|
||||
was SMP-correct because the cli() function ensured that no
|
||||
interrupt handler (amongst them the above irq_handler()) function
|
||||
would execute while the cli()-ed section is executing.
|
||||
|
||||
but from now on a more direct method of locking has to be used:
|
||||
|
||||
DEFINE_SPINLOCK(driver_lock);
|
||||
struct driver_data;
|
||||
|
||||
irq_handler (...)
|
||||
{
|
||||
unsigned long flags;
|
||||
....
|
||||
spin_lock_irqsave(&driver_lock, flags);
|
||||
....
|
||||
driver_data.finish = 1;
|
||||
driver_data.new_work = 0;
|
||||
....
|
||||
spin_unlock_irqrestore(&driver_lock, flags);
|
||||
....
|
||||
}
|
||||
|
||||
...
|
||||
|
||||
ioctl_func (...)
|
||||
{
|
||||
...
|
||||
spin_lock_irq(&driver_lock);
|
||||
...
|
||||
driver_data.finish = 0;
|
||||
driver_data.new_work = 2;
|
||||
...
|
||||
spin_unlock_irq(&driver_lock);
|
||||
...
|
||||
}
|
||||
|
||||
the above code has a number of advantages:
|
||||
|
||||
- the locking relation is easier to understand - actual lock usage
|
||||
pinpoints the critical sections. cli() usage is too opaque.
|
||||
Easier to understand means it's easier to debug.
|
||||
|
||||
- it's faster, because spinlocks are faster to acquire than the
|
||||
potentially heavily-used IRQ lock. Furthermore, your driver does
|
||||
not have to wait eg. for a big heavy SCSI interrupt to finish,
|
||||
because the driver_lock spinlock is only used by your driver.
|
||||
cli() on the other hand was used by many drivers, and extended
|
||||
the critical section to the whole IRQ handler function - creating
|
||||
serious lock contention.
|
||||
|
||||
|
||||
to make the transition easier, we've still kept the cli(), sti(),
|
||||
save_flags(), save_flags_cli() and restore_flags() macros defined
|
||||
on UP systems - but their usage will be phased out until 2.6 is
|
||||
released.
|
||||
|
||||
drivers that want to disable local interrupts (interrupts on the
|
||||
current CPU), can use the following five macros:
|
||||
|
||||
local_irq_disable(), local_irq_enable(), local_save_flags(flags),
|
||||
local_irq_save(flags), local_irq_restore(flags)
|
||||
|
||||
but beware, their meaning and semantics are much simpler, far from
|
||||
that of the old cli(), sti(), save_flags(flags) and restore_flags(flags)
|
||||
SMP meaning:
|
||||
|
||||
local_irq_disable() => turn local IRQs off
|
||||
|
||||
local_irq_enable() => turn local IRQs on
|
||||
|
||||
local_save_flags(flags) => save the current IRQ state into flags. The
|
||||
state can be on or off. (on some
|
||||
architectures there's even more bits in it.)
|
||||
|
||||
local_irq_save(flags) => save the current IRQ state into flags and
|
||||
disable interrupts.
|
||||
|
||||
local_irq_restore(flags) => restore the IRQ state from flags.
|
||||
|
||||
(local_irq_save can save both irqs on and irqs off state, and
|
||||
local_irq_restore can restore into both irqs on and irqs off state.)
|
||||
|
||||
another related change is that synchronize_irq() now takes a parameter:
|
||||
synchronize_irq(irq). This change too has the purpose of making SMP
|
||||
synchronization more lightweight - this way you can wait for your own
|
||||
interrupt handler to finish, no need to wait for other IRQ sources.
|
||||
|
||||
|
||||
why were these changes done? The main reason was the architectural burden
|
||||
of maintaining the cli()/sti() interface - it became a real problem. The
|
||||
new interrupt system is much more streamlined, easier to understand, debug,
|
||||
and it's also a bit faster - the same happened to it that will happen to
|
||||
cli()/sti() using drivers once they convert to spinlocks :-)
|
||||
|
||||
|
|
@ -122,7 +122,7 @@ around '10000' or more.
|
|||
show_sampling_rate_(min|max): the minimum and maximum sampling rates
|
||||
available that you may set 'sampling_rate' to.
|
||||
|
||||
up_threshold: defines what the average CPU usaged between the samplings
|
||||
up_threshold: defines what the average CPU usage between the samplings
|
||||
of 'sampling_rate' needs to be for the kernel to make a decision on
|
||||
whether it should increase the frequency. For example when it is set
|
||||
to its default value of '80' it means that between the checking
|
||||
|
|
|
|||
|
|
@ -327,7 +327,7 @@ 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
|
||||
rate is set by writing a minimum bandwidth in bytes/sec to the attribute
|
||||
file. The rate will be translated to an internal value that gives at
|
||||
least the specified rate.
|
||||
|
||||
|
|
|
|||
|
|
@ -47,6 +47,30 @@ Who: Mauro Carvalho Chehab <mchehab@infradead.org>
|
|||
|
||||
---------------------------
|
||||
|
||||
What: old tuner-3036 i2c driver
|
||||
When: 2.6.28
|
||||
Why: This driver is for VERY old i2c-over-parallel port teletext receiver
|
||||
boxes. Rather then spending effort on converting this driver to V4L2,
|
||||
and since it is extremely unlikely that anyone still uses one of these
|
||||
devices, it was decided to drop it.
|
||||
Who: Hans Verkuil <hverkuil@xs4all.nl>
|
||||
Mauro Carvalho Chehab <mchehab@infradead.org>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: V4L2 dpc7146 driver
|
||||
When: 2.6.28
|
||||
Why: Old driver for the dpc7146 demonstration board that is no longer
|
||||
relevant. The last time this was tested on actual hardware was
|
||||
probably around 2002. Since this is a driver for a demonstration
|
||||
board the decision was made to remove it rather than spending a
|
||||
lot of effort continually updating this driver to stay in sync
|
||||
with the latest internal V4L2 or I2C API.
|
||||
Who: Hans Verkuil <hverkuil@xs4all.nl>
|
||||
Mauro Carvalho Chehab <mchehab@infradead.org>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: PCMCIA control ioctl (needed for pcmcia-cs [cardmgr, cardctl])
|
||||
When: November 2005
|
||||
Files: drivers/pcmcia/: pcmcia_ioctl.c
|
||||
|
|
|
|||
|
|
@ -311,9 +311,20 @@ the subsystem must be ready for it.
|
|||
[An Example]
|
||||
|
||||
The best example of these basic concepts is the simple_children
|
||||
subsystem/group and the simple_child item in configfs_example.c It
|
||||
shows a trivial object displaying and storing an attribute, and a simple
|
||||
group creating and destroying these children.
|
||||
subsystem/group and the simple_child item in configfs_example_explicit.c
|
||||
and configfs_example_macros.c. It shows a trivial object displaying and
|
||||
storing an attribute, and a simple group creating and destroying these
|
||||
children.
|
||||
|
||||
The only difference between configfs_example_explicit.c and
|
||||
configfs_example_macros.c is how the attributes of the childless item
|
||||
are defined. The childless item has extended attributes, each with
|
||||
their own show()/store() operation. This follows a convention commonly
|
||||
used in sysfs. configfs_example_explicit.c creates these attributes
|
||||
by explicitly defining the structures involved. Conversely
|
||||
configfs_example_macros.c uses some convenience macros from configfs.h
|
||||
to define the attributes. These macros are similar to their sysfs
|
||||
counterparts.
|
||||
|
||||
[Hierarchy Navigation and the Subsystem Mutex]
|
||||
|
||||
|
|
|
|||
|
|
@ -1,8 +1,10 @@
|
|||
/*
|
||||
* vim: noexpandtab ts=8 sts=0 sw=8:
|
||||
*
|
||||
* configfs_example.c - This file is a demonstration module containing
|
||||
* a number of configfs subsystems.
|
||||
* configfs_example_explicit.c - This file is a demonstration module
|
||||
* containing a number of configfs subsystems. It explicitly defines
|
||||
* each structure without using the helper macros defined in
|
||||
* configfs.h.
|
||||
*
|
||||
* This program is free software; you can redistribute it and/or
|
||||
* modify it under the terms of the GNU General Public
|
||||
|
|
@ -281,7 +283,6 @@ static struct config_item *simple_children_make_item(struct config_group *group,
|
|||
if (!simple_child)
|
||||
return ERR_PTR(-ENOMEM);
|
||||
|
||||
|
||||
config_item_init_type_name(&simple_child->item, name,
|
||||
&simple_child_type);
|
||||
|
||||
|
|
@ -302,8 +303,8 @@ static struct configfs_attribute *simple_children_attrs[] = {
|
|||
};
|
||||
|
||||
static ssize_t simple_children_attr_show(struct config_item *item,
|
||||
struct configfs_attribute *attr,
|
||||
char *page)
|
||||
struct configfs_attribute *attr,
|
||||
char *page)
|
||||
{
|
||||
return sprintf(page,
|
||||
"[02-simple-children]\n"
|
||||
|
|
@ -318,7 +319,7 @@ static void simple_children_release(struct config_item *item)
|
|||
}
|
||||
|
||||
static struct configfs_item_operations simple_children_item_ops = {
|
||||
.release = simple_children_release,
|
||||
.release = simple_children_release,
|
||||
.show_attribute = simple_children_attr_show,
|
||||
};
|
||||
|
||||
|
|
@ -368,7 +369,6 @@ static struct config_group *group_children_make_group(struct config_group *group
|
|||
if (!simple_children)
|
||||
return ERR_PTR(-ENOMEM);
|
||||
|
||||
|
||||
config_group_init_type_name(&simple_children->group, name,
|
||||
&simple_children_type);
|
||||
|
||||
|
|
@ -387,8 +387,8 @@ static struct configfs_attribute *group_children_attrs[] = {
|
|||
};
|
||||
|
||||
static ssize_t group_children_attr_show(struct config_item *item,
|
||||
struct configfs_attribute *attr,
|
||||
char *page)
|
||||
struct configfs_attribute *attr,
|
||||
char *page)
|
||||
{
|
||||
return sprintf(page,
|
||||
"[03-group-children]\n"
|
||||
|
|
@ -0,0 +1,448 @@
|
|||
/*
|
||||
* vim: noexpandtab ts=8 sts=0 sw=8:
|
||||
*
|
||||
* configfs_example_macros.c - This file is a demonstration module
|
||||
* containing a number of configfs subsystems. It uses the helper
|
||||
* macros defined by configfs.h
|
||||
*
|
||||
* This program is free software; you can redistribute it and/or
|
||||
* modify it under the terms of the GNU General Public
|
||||
* License as published by the Free Software Foundation; either
|
||||
* version 2 of the License, or (at your option) any later version.
|
||||
*
|
||||
* 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 021110-1307, USA.
|
||||
*
|
||||
* Based on sysfs:
|
||||
* sysfs is Copyright (C) 2001, 2002, 2003 Patrick Mochel
|
||||
*
|
||||
* configfs Copyright (C) 2005 Oracle. All rights reserved.
|
||||
*/
|
||||
|
||||
#include <linux/init.h>
|
||||
#include <linux/module.h>
|
||||
#include <linux/slab.h>
|
||||
|
||||
#include <linux/configfs.h>
|
||||
|
||||
|
||||
|
||||
/*
|
||||
* 01-childless
|
||||
*
|
||||
* This first example is a childless subsystem. It cannot create
|
||||
* any config_items. It just has attributes.
|
||||
*
|
||||
* Note that we are enclosing the configfs_subsystem inside a container.
|
||||
* This is not necessary if a subsystem has no attributes directly
|
||||
* on the subsystem. See the next example, 02-simple-children, for
|
||||
* such a subsystem.
|
||||
*/
|
||||
|
||||
struct childless {
|
||||
struct configfs_subsystem subsys;
|
||||
int showme;
|
||||
int storeme;
|
||||
};
|
||||
|
||||
static inline struct childless *to_childless(struct config_item *item)
|
||||
{
|
||||
return item ? container_of(to_configfs_subsystem(to_config_group(item)), struct childless, subsys) : NULL;
|
||||
}
|
||||
|
||||
CONFIGFS_ATTR_STRUCT(childless);
|
||||
#define CHILDLESS_ATTR(_name, _mode, _show, _store) \
|
||||
struct childless_attribute childless_attr_##_name = __CONFIGFS_ATTR(_name, _mode, _show, _store)
|
||||
#define CHILDLESS_ATTR_RO(_name, _show) \
|
||||
struct childless_attribute childless_attr_##_name = __CONFIGFS_ATTR_RO(_name, _show);
|
||||
|
||||
static ssize_t childless_showme_read(struct childless *childless,
|
||||
char *page)
|
||||
{
|
||||
ssize_t pos;
|
||||
|
||||
pos = sprintf(page, "%d\n", childless->showme);
|
||||
childless->showme++;
|
||||
|
||||
return pos;
|
||||
}
|
||||
|
||||
static ssize_t childless_storeme_read(struct childless *childless,
|
||||
char *page)
|
||||
{
|
||||
return sprintf(page, "%d\n", childless->storeme);
|
||||
}
|
||||
|
||||
static ssize_t childless_storeme_write(struct childless *childless,
|
||||
const char *page,
|
||||
size_t count)
|
||||
{
|
||||
unsigned long tmp;
|
||||
char *p = (char *) page;
|
||||
|
||||
tmp = simple_strtoul(p, &p, 10);
|
||||
if (!p || (*p && (*p != '\n')))
|
||||
return -EINVAL;
|
||||
|
||||
if (tmp > INT_MAX)
|
||||
return -ERANGE;
|
||||
|
||||
childless->storeme = tmp;
|
||||
|
||||
return count;
|
||||
}
|
||||
|
||||
static ssize_t childless_description_read(struct childless *childless,
|
||||
char *page)
|
||||
{
|
||||
return sprintf(page,
|
||||
"[01-childless]\n"
|
||||
"\n"
|
||||
"The childless subsystem is the simplest possible subsystem in\n"
|
||||
"configfs. It does not support the creation of child config_items.\n"
|
||||
"It only has a few attributes. In fact, it isn't much different\n"
|
||||
"than a directory in /proc.\n");
|
||||
}
|
||||
|
||||
CHILDLESS_ATTR_RO(showme, childless_showme_read);
|
||||
CHILDLESS_ATTR(storeme, S_IRUGO | S_IWUSR, childless_storeme_read,
|
||||
childless_storeme_write);
|
||||
CHILDLESS_ATTR_RO(description, childless_description_read);
|
||||
|
||||
static struct configfs_attribute *childless_attrs[] = {
|
||||
&childless_attr_showme.attr,
|
||||
&childless_attr_storeme.attr,
|
||||
&childless_attr_description.attr,
|
||||
NULL,
|
||||
};
|
||||
|
||||
CONFIGFS_ATTR_OPS(childless);
|
||||
static struct configfs_item_operations childless_item_ops = {
|
||||
.show_attribute = childless_attr_show,
|
||||
.store_attribute = childless_attr_store,
|
||||
};
|
||||
|
||||
static struct config_item_type childless_type = {
|
||||
.ct_item_ops = &childless_item_ops,
|
||||
.ct_attrs = childless_attrs,
|
||||
.ct_owner = THIS_MODULE,
|
||||
};
|
||||
|
||||
static struct childless childless_subsys = {
|
||||
.subsys = {
|
||||
.su_group = {
|
||||
.cg_item = {
|
||||
.ci_namebuf = "01-childless",
|
||||
.ci_type = &childless_type,
|
||||
},
|
||||
},
|
||||
},
|
||||
};
|
||||
|
||||
|
||||
/* ----------------------------------------------------------------- */
|
||||
|
||||
/*
|
||||
* 02-simple-children
|
||||
*
|
||||
* This example merely has a simple one-attribute child. Note that
|
||||
* there is no extra attribute structure, as the child's attribute is
|
||||
* known from the get-go. Also, there is no container for the
|
||||
* subsystem, as it has no attributes of its own.
|
||||
*/
|
||||
|
||||
struct simple_child {
|
||||
struct config_item item;
|
||||
int storeme;
|
||||
};
|
||||
|
||||
static inline struct simple_child *to_simple_child(struct config_item *item)
|
||||
{
|
||||
return item ? container_of(item, struct simple_child, item) : NULL;
|
||||
}
|
||||
|
||||
static struct configfs_attribute simple_child_attr_storeme = {
|
||||
.ca_owner = THIS_MODULE,
|
||||
.ca_name = "storeme",
|
||||
.ca_mode = S_IRUGO | S_IWUSR,
|
||||
};
|
||||
|
||||
static struct configfs_attribute *simple_child_attrs[] = {
|
||||
&simple_child_attr_storeme,
|
||||
NULL,
|
||||
};
|
||||
|
||||
static ssize_t simple_child_attr_show(struct config_item *item,
|
||||
struct configfs_attribute *attr,
|
||||
char *page)
|
||||
{
|
||||
ssize_t count;
|
||||
struct simple_child *simple_child = to_simple_child(item);
|
||||
|
||||
count = sprintf(page, "%d\n", simple_child->storeme);
|
||||
|
||||
return count;
|
||||
}
|
||||
|
||||
static ssize_t simple_child_attr_store(struct config_item *item,
|
||||
struct configfs_attribute *attr,
|
||||
const char *page, size_t count)
|
||||
{
|
||||
struct simple_child *simple_child = to_simple_child(item);
|
||||
unsigned long tmp;
|
||||
char *p = (char *) page;
|
||||
|
||||
tmp = simple_strtoul(p, &p, 10);
|
||||
if (!p || (*p && (*p != '\n')))
|
||||
return -EINVAL;
|
||||
|
||||
if (tmp > INT_MAX)
|
||||
return -ERANGE;
|
||||
|
||||
simple_child->storeme = tmp;
|
||||
|
||||
return count;
|
||||
}
|
||||
|
||||
static void simple_child_release(struct config_item *item)
|
||||
{
|
||||
kfree(to_simple_child(item));
|
||||
}
|
||||
|
||||
static struct configfs_item_operations simple_child_item_ops = {
|
||||
.release = simple_child_release,
|
||||
.show_attribute = simple_child_attr_show,
|
||||
.store_attribute = simple_child_attr_store,
|
||||
};
|
||||
|
||||
static struct config_item_type simple_child_type = {
|
||||
.ct_item_ops = &simple_child_item_ops,
|
||||
.ct_attrs = simple_child_attrs,
|
||||
.ct_owner = THIS_MODULE,
|
||||
};
|
||||
|
||||
|
||||
struct simple_children {
|
||||
struct config_group group;
|
||||
};
|
||||
|
||||
static inline struct simple_children *to_simple_children(struct config_item *item)
|
||||
{
|
||||
return item ? container_of(to_config_group(item), struct simple_children, group) : NULL;
|
||||
}
|
||||
|
||||
static struct config_item *simple_children_make_item(struct config_group *group, const char *name)
|
||||
{
|
||||
struct simple_child *simple_child;
|
||||
|
||||
simple_child = kzalloc(sizeof(struct simple_child), GFP_KERNEL);
|
||||
if (!simple_child)
|
||||
return ERR_PTR(-ENOMEM);
|
||||
|
||||
config_item_init_type_name(&simple_child->item, name,
|
||||
&simple_child_type);
|
||||
|
||||
simple_child->storeme = 0;
|
||||
|
||||
return &simple_child->item;
|
||||
}
|
||||
|
||||
static struct configfs_attribute simple_children_attr_description = {
|
||||
.ca_owner = THIS_MODULE,
|
||||
.ca_name = "description",
|
||||
.ca_mode = S_IRUGO,
|
||||
};
|
||||
|
||||
static struct configfs_attribute *simple_children_attrs[] = {
|
||||
&simple_children_attr_description,
|
||||
NULL,
|
||||
};
|
||||
|
||||
static ssize_t simple_children_attr_show(struct config_item *item,
|
||||
struct configfs_attribute *attr,
|
||||
char *page)
|
||||
{
|
||||
return sprintf(page,
|
||||
"[02-simple-children]\n"
|
||||
"\n"
|
||||
"This subsystem allows the creation of child config_items. These\n"
|
||||
"items have only one attribute that is readable and writeable.\n");
|
||||
}
|
||||
|
||||
static void simple_children_release(struct config_item *item)
|
||||
{
|
||||
kfree(to_simple_children(item));
|
||||
}
|
||||
|
||||
static struct configfs_item_operations simple_children_item_ops = {
|
||||
.release = simple_children_release,
|
||||
.show_attribute = simple_children_attr_show,
|
||||
};
|
||||
|
||||
/*
|
||||
* Note that, since no extra work is required on ->drop_item(),
|
||||
* no ->drop_item() is provided.
|
||||
*/
|
||||
static struct configfs_group_operations simple_children_group_ops = {
|
||||
.make_item = simple_children_make_item,
|
||||
};
|
||||
|
||||
static struct config_item_type simple_children_type = {
|
||||
.ct_item_ops = &simple_children_item_ops,
|
||||
.ct_group_ops = &simple_children_group_ops,
|
||||
.ct_attrs = simple_children_attrs,
|
||||
.ct_owner = THIS_MODULE,
|
||||
};
|
||||
|
||||
static struct configfs_subsystem simple_children_subsys = {
|
||||
.su_group = {
|
||||
.cg_item = {
|
||||
.ci_namebuf = "02-simple-children",
|
||||
.ci_type = &simple_children_type,
|
||||
},
|
||||
},
|
||||
};
|
||||
|
||||
|
||||
/* ----------------------------------------------------------------- */
|
||||
|
||||
/*
|
||||
* 03-group-children
|
||||
*
|
||||
* This example reuses the simple_children group from above. However,
|
||||
* the simple_children group is not the subsystem itself, it is a
|
||||
* child of the subsystem. Creation of a group in the subsystem creates
|
||||
* a new simple_children group. That group can then have simple_child
|
||||
* children of its own.
|
||||
*/
|
||||
|
||||
static struct config_group *group_children_make_group(struct config_group *group, const char *name)
|
||||
{
|
||||
struct simple_children *simple_children;
|
||||
|
||||
simple_children = kzalloc(sizeof(struct simple_children),
|
||||
GFP_KERNEL);
|
||||
if (!simple_children)
|
||||
return ERR_PTR(-ENOMEM);
|
||||
|
||||
config_group_init_type_name(&simple_children->group, name,
|
||||
&simple_children_type);
|
||||
|
||||
return &simple_children->group;
|
||||
}
|
||||
|
||||
static struct configfs_attribute group_children_attr_description = {
|
||||
.ca_owner = THIS_MODULE,
|
||||
.ca_name = "description",
|
||||
.ca_mode = S_IRUGO,
|
||||
};
|
||||
|
||||
static struct configfs_attribute *group_children_attrs[] = {
|
||||
&group_children_attr_description,
|
||||
NULL,
|
||||
};
|
||||
|
||||
static ssize_t group_children_attr_show(struct config_item *item,
|
||||
struct configfs_attribute *attr,
|
||||
char *page)
|
||||
{
|
||||
return sprintf(page,
|
||||
"[03-group-children]\n"
|
||||
"\n"
|
||||
"This subsystem allows the creation of child config_groups. These\n"
|
||||
"groups are like the subsystem simple-children.\n");
|
||||
}
|
||||
|
||||
static struct configfs_item_operations group_children_item_ops = {
|
||||
.show_attribute = group_children_attr_show,
|
||||
};
|
||||
|
||||
/*
|
||||
* Note that, since no extra work is required on ->drop_item(),
|
||||
* no ->drop_item() is provided.
|
||||
*/
|
||||
static struct configfs_group_operations group_children_group_ops = {
|
||||
.make_group = group_children_make_group,
|
||||
};
|
||||
|
||||
static struct config_item_type group_children_type = {
|
||||
.ct_item_ops = &group_children_item_ops,
|
||||
.ct_group_ops = &group_children_group_ops,
|
||||
.ct_attrs = group_children_attrs,
|
||||
.ct_owner = THIS_MODULE,
|
||||
};
|
||||
|
||||
static struct configfs_subsystem group_children_subsys = {
|
||||
.su_group = {
|
||||
.cg_item = {
|
||||
.ci_namebuf = "03-group-children",
|
||||
.ci_type = &group_children_type,
|
||||
},
|
||||
},
|
||||
};
|
||||
|
||||
/* ----------------------------------------------------------------- */
|
||||
|
||||
/*
|
||||
* We're now done with our subsystem definitions.
|
||||
* For convenience in this module, here's a list of them all. It
|
||||
* allows the init function to easily register them. Most modules
|
||||
* will only have one subsystem, and will only call register_subsystem
|
||||
* on it directly.
|
||||
*/
|
||||
static struct configfs_subsystem *example_subsys[] = {
|
||||
&childless_subsys.subsys,
|
||||
&simple_children_subsys,
|
||||
&group_children_subsys,
|
||||
NULL,
|
||||
};
|
||||
|
||||
static int __init configfs_example_init(void)
|
||||
{
|
||||
int ret;
|
||||
int i;
|
||||
struct configfs_subsystem *subsys;
|
||||
|
||||
for (i = 0; example_subsys[i]; i++) {
|
||||
subsys = example_subsys[i];
|
||||
|
||||
config_group_init(&subsys->su_group);
|
||||
mutex_init(&subsys->su_mutex);
|
||||
ret = configfs_register_subsystem(subsys);
|
||||
if (ret) {
|
||||
printk(KERN_ERR "Error %d while registering subsystem %s\n",
|
||||
ret,
|
||||
subsys->su_group.cg_item.ci_namebuf);
|
||||
goto out_unregister;
|
||||
}
|
||||
}
|
||||
|
||||
return 0;
|
||||
|
||||
out_unregister:
|
||||
for (; i >= 0; i--) {
|
||||
configfs_unregister_subsystem(example_subsys[i]);
|
||||
}
|
||||
|
||||
return ret;
|
||||
}
|
||||
|
||||
static void __exit configfs_example_exit(void)
|
||||
{
|
||||
int i;
|
||||
|
||||
for (i = 0; example_subsys[i]; i++) {
|
||||
configfs_unregister_subsystem(example_subsys[i]);
|
||||
}
|
||||
}
|
||||
|
||||
module_init(configfs_example_init);
|
||||
module_exit(configfs_example_exit);
|
||||
MODULE_LICENSE("GPL");
|
||||
|
|
@ -0,0 +1,106 @@
|
|||
Optimized MPEG Filesystem (OMFS)
|
||||
|
||||
Overview
|
||||
========
|
||||
|
||||
OMFS is a filesystem created by SonicBlue for use in the ReplayTV DVR
|
||||
and Rio Karma MP3 player. The filesystem is extent-based, utilizing
|
||||
block sizes from 2k to 8k, with hash-based directories. This
|
||||
filesystem driver may be used to read and write disks from these
|
||||
devices.
|
||||
|
||||
Note, it is not recommended that this FS be used in place of a general
|
||||
filesystem for your own streaming media device. Native Linux filesystems
|
||||
will likely perform better.
|
||||
|
||||
More information is available at:
|
||||
|
||||
http://linux-karma.sf.net/
|
||||
|
||||
Various utilities, including mkomfs and omfsck, are included with
|
||||
omfsprogs, available at:
|
||||
|
||||
http://bobcopeland.com/karma/
|
||||
|
||||
Instructions are included in its README.
|
||||
|
||||
Options
|
||||
=======
|
||||
|
||||
OMFS supports the following mount-time options:
|
||||
|
||||
uid=n - make all files owned by specified user
|
||||
gid=n - make all files owned by specified group
|
||||
umask=xxx - set permission umask to xxx
|
||||
fmask=xxx - set umask to xxx for files
|
||||
dmask=xxx - set umask to xxx for directories
|
||||
|
||||
Disk format
|
||||
===========
|
||||
|
||||
OMFS discriminates between "sysblocks" and normal data blocks. The sysblock
|
||||
group consists of super block information, file metadata, directory structures,
|
||||
and extents. Each sysblock has a header containing CRCs of the entire
|
||||
sysblock, and may be mirrored in successive blocks on the disk. A sysblock may
|
||||
have a smaller size than a data block, but since they are both addressed by the
|
||||
same 64-bit block number, any remaining space in the smaller sysblock is
|
||||
unused.
|
||||
|
||||
Sysblock header information:
|
||||
|
||||
struct omfs_header {
|
||||
__be64 h_self; /* FS block where this is located */
|
||||
__be32 h_body_size; /* size of useful data after header */
|
||||
__be16 h_crc; /* crc-ccitt of body_size bytes */
|
||||
char h_fill1[2];
|
||||
u8 h_version; /* version, always 1 */
|
||||
char h_type; /* OMFS_INODE_X */
|
||||
u8 h_magic; /* OMFS_IMAGIC */
|
||||
u8 h_check_xor; /* XOR of header bytes before this */
|
||||
__be32 h_fill2;
|
||||
};
|
||||
|
||||
Files and directories are both represented by omfs_inode:
|
||||
|
||||
struct omfs_inode {
|
||||
struct omfs_header i_head; /* header */
|
||||
__be64 i_parent; /* parent containing this inode */
|
||||
__be64 i_sibling; /* next inode in hash bucket */
|
||||
__be64 i_ctime; /* ctime, in milliseconds */
|
||||
char i_fill1[35];
|
||||
char i_type; /* OMFS_[DIR,FILE] */
|
||||
__be32 i_fill2;
|
||||
char i_fill3[64];
|
||||
char i_name[OMFS_NAMELEN]; /* filename */
|
||||
__be64 i_size; /* size of file, in bytes */
|
||||
};
|
||||
|
||||
Directories in OMFS are implemented as a large hash table. Filenames are
|
||||
hashed then prepended into the bucket list beginning at OMFS_DIR_START.
|
||||
Lookup requires hashing the filename, then seeking across i_sibling pointers
|
||||
until a match is found on i_name. Empty buckets are represented by block
|
||||
pointers with all-1s (~0).
|
||||
|
||||
A file is an omfs_inode structure followed by an extent table beginning at
|
||||
OMFS_EXTENT_START:
|
||||
|
||||
struct omfs_extent_entry {
|
||||
__be64 e_cluster; /* start location of a set of blocks */
|
||||
__be64 e_blocks; /* number of blocks after e_cluster */
|
||||
};
|
||||
|
||||
struct omfs_extent {
|
||||
__be64 e_next; /* next extent table location */
|
||||
__be32 e_extent_count; /* total # extents in this table */
|
||||
__be32 e_fill;
|
||||
struct omfs_extent_entry e_entry; /* start of extent entries */
|
||||
};
|
||||
|
||||
Each extent holds the block offset followed by number of blocks allocated to
|
||||
the extent. The final extent in each table is a terminator with e_cluster
|
||||
being ~0 and e_blocks being ones'-complement of the total number of blocks
|
||||
in the table.
|
||||
|
||||
If this table overflows, a continuation inode is written and pointed to by
|
||||
e_next. These have a header but lack the rest of the inode structure.
|
||||
|
||||
|
|
@ -931,7 +931,7 @@ group_prealloc max_to_scan mb_groups mb_history min_to_scan order2_req
|
|||
stats stream_req
|
||||
|
||||
mb_groups:
|
||||
This file gives the details of mutiblock allocator buddy cache of free blocks
|
||||
This file gives the details of multiblock allocator buddy cache of free blocks
|
||||
|
||||
mb_history:
|
||||
Multiblock allocation history.
|
||||
|
|
@ -1474,7 +1474,7 @@ used because pages_free(1355) is smaller than watermark + protection[2]
|
|||
normal page requirement. If requirement is DMA zone(index=0), protection[0]
|
||||
(=0) is used.
|
||||
|
||||
zone[i]'s protection[j] is calculated by following exprssion.
|
||||
zone[i]'s protection[j] is calculated by following expression.
|
||||
|
||||
(i < j):
|
||||
zone[i]->protection[j]
|
||||
|
|
|
|||
|
|
@ -294,6 +294,16 @@ user-defined data with a channel, and is immediately available
|
|||
(including in create_buf_file()) via chan->private_data or
|
||||
buf->chan->private_data.
|
||||
|
||||
Buffer-only channels
|
||||
--------------------
|
||||
|
||||
These channels have no files associated and can be created with
|
||||
relay_open(NULL, NULL, ...). Such channels are useful in scenarios such
|
||||
as when doing early tracing in the kernel, before the VFS is up. In these
|
||||
cases, one may open a buffer-only channel and then call
|
||||
relay_late_setup_files() when the kernel is ready to handle files,
|
||||
to expose the buffered data to the userspace.
|
||||
|
||||
Channel 'modes'
|
||||
---------------
|
||||
|
||||
|
|
|
|||
|
|
@ -143,7 +143,7 @@ struct file_system_type {
|
|||
|
||||
The get_sb() method has the following arguments:
|
||||
|
||||
struct file_system_type *fs_type: decribes the filesystem, partly initialized
|
||||
struct file_system_type *fs_type: describes the filesystem, partly initialized
|
||||
by the specific filesystem code
|
||||
|
||||
int flags: mount flags
|
||||
|
|
@ -895,9 +895,9 @@ struct dentry_operations {
|
|||
iput() yourself
|
||||
|
||||
d_dname: called when the pathname of a dentry should be generated.
|
||||
Usefull for some pseudo filesystems (sockfs, pipefs, ...) to delay
|
||||
Useful for some pseudo filesystems (sockfs, pipefs, ...) to delay
|
||||
pathname generation. (Instead of doing it when dentry is created,
|
||||
its done only when the path is needed.). Real filesystems probably
|
||||
it's done only when the path is needed.). Real filesystems probably
|
||||
dont want to use it, because their dentries are present in global
|
||||
dcache hash, so their hash should be an invariant. As no lock is
|
||||
held, d_dname() should not try to modify the dentry itself, unless
|
||||
|
|
|
|||
|
|
@ -4,6 +4,7 @@
|
|||
Copyright 2008 Red Hat Inc.
|
||||
Author: Steven Rostedt <srostedt@redhat.com>
|
||||
License: The GNU Free Documentation License, Version 1.2
|
||||
(dual licensed under the GPL v2)
|
||||
Reviewers: Elias Oltmanns, Randy Dunlap, Andrew Morton,
|
||||
John Kacur, and David Teigland.
|
||||
|
||||
|
|
|
|||
|
|
@ -10,6 +10,10 @@ Supported chips:
|
|||
Prefix: 'sch311x'
|
||||
Addresses scanned: none, address read from Super-I/O config space
|
||||
Datasheet: http://www.nuhorizons.com/FeaturedProducts/Volume1/SMSC/311x.pdf
|
||||
* SMSC SCH5027
|
||||
Prefix: 'sch5027'
|
||||
Addresses scanned: I2C 0x2c, 0x2d, 0x2e
|
||||
Datasheet: Provided by SMSC upon request and under NDA
|
||||
|
||||
Authors:
|
||||
Juerg Haefliger <juergh@gmail.com>
|
||||
|
|
@ -22,34 +26,36 @@ Module Parameters
|
|||
and PWM output control functions. Using this parameter
|
||||
shouldn't be required since the BIOS usually takes care
|
||||
of this.
|
||||
|
||||
Note that there is no need to use this parameter if the driver loads without
|
||||
complaining. The driver will say so if it is necessary.
|
||||
* probe_all_addr: bool Include non-standard LPC addresses 0x162e and 0x164e
|
||||
when probing for ISA devices. This is required for the
|
||||
following boards:
|
||||
- VIA EPIA SN18000
|
||||
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
This driver implements support for the hardware monitoring capabilities of the
|
||||
SMSC DME1737 and Asus A8000 (which are the same) and SMSC SCH311x Super-I/O
|
||||
chips. These chips feature monitoring of 3 temp sensors temp[1-3] (2 remote
|
||||
diodes and 1 internal), 7 voltages in[0-6] (6 external and 1 internal) and up
|
||||
to 6 fan speeds fan[1-6]. Additionally, the chips implement up to 5 PWM
|
||||
outputs pwm[1-3,5-6] for controlling fan speeds both manually and
|
||||
SMSC DME1737 and Asus A8000 (which are the same), SMSC SCH5027, and SMSC
|
||||
SCH311x Super-I/O chips. These chips feature monitoring of 3 temp sensors
|
||||
temp[1-3] (2 remote diodes and 1 internal), 7 voltages in[0-6] (6 external and
|
||||
1 internal) and up to 6 fan speeds fan[1-6]. Additionally, the chips implement
|
||||
up to 5 PWM outputs pwm[1-3,5-6] for controlling fan speeds both manually and
|
||||
automatically.
|
||||
|
||||
For the DME1737 and A8000, fan[1-2] and pwm[1-2] are always present. Fan[3-6]
|
||||
and pwm[3,5-6] are optional features and their availability depends on the
|
||||
configuration of the chip. The driver will detect which features are present
|
||||
during initialization and create the sysfs attributes accordingly.
|
||||
For the DME1737, A8000 and SCH5027, fan[1-2] and pwm[1-2] are always present.
|
||||
Fan[3-6] and pwm[3,5-6] are optional features and their availability depends on
|
||||
the configuration of the chip. The driver will detect which features are
|
||||
present during initialization and create the sysfs attributes accordingly.
|
||||
|
||||
For the SCH311x, fan[1-3] and pwm[1-3] are always present and fan[4-6] and
|
||||
pwm[5-6] don't exist.
|
||||
|
||||
The hardware monitoring features of the DME1737 and A8000 are only accessible
|
||||
via SMBus, while the SCH311x only provides access via the ISA bus. The driver
|
||||
will therefore register itself as an I2C client driver if it detects a DME1737
|
||||
or A8000 and as a platform driver if it detects a SCH311x chip.
|
||||
The hardware monitoring features of the DME1737, A8000, and SCH5027 are only
|
||||
accessible via SMBus, while the SCH311x only provides access via the ISA bus.
|
||||
The driver will therefore register itself as an I2C client driver if it detects
|
||||
a DME1737, A8000, or SCH5027 and as a platform driver if it detects a SCH311x
|
||||
chip.
|
||||
|
||||
|
||||
Voltage Monitoring
|
||||
|
|
@ -60,6 +66,7 @@ scaling resistors. The values returned by the driver therefore reflect true
|
|||
millivolts and don't need scaling. The voltage inputs are mapped as follows
|
||||
(the last column indicates the input ranges):
|
||||
|
||||
DME1737, A8000:
|
||||
in0: +5VTR (+5V standby) 0V - 6.64V
|
||||
in1: Vccp (processor core) 0V - 3V
|
||||
in2: VCC (internal +3.3V) 0V - 4.38V
|
||||
|
|
@ -68,6 +75,24 @@ millivolts and don't need scaling. The voltage inputs are mapped as follows
|
|||
in5: VTR (+3.3V standby) 0V - 4.38V
|
||||
in6: Vbat (+3.0V) 0V - 4.38V
|
||||
|
||||
SCH311x:
|
||||
in0: +2.5V 0V - 6.64V
|
||||
in1: Vccp (processor core) 0V - 2V
|
||||
in2: VCC (internal +3.3V) 0V - 4.38V
|
||||
in3: +5V 0V - 6.64V
|
||||
in4: +12V 0V - 16V
|
||||
in5: VTR (+3.3V standby) 0V - 4.38V
|
||||
in6: Vbat (+3.0V) 0V - 4.38V
|
||||
|
||||
SCH5027:
|
||||
in0: +5VTR (+5V standby) 0V - 6.64V
|
||||
in1: Vccp (processor core) 0V - 3V
|
||||
in2: VCC (internal +3.3V) 0V - 4.38V
|
||||
in3: V2_IN 0V - 1.5V
|
||||
in4: V1_IN 0V - 1.5V
|
||||
in5: VTR (+3.3V standby) 0V - 4.38V
|
||||
in6: Vbat (+3.0V) 0V - 4.38V
|
||||
|
||||
Each voltage input has associated min and max limits which trigger an alarm
|
||||
when crossed.
|
||||
|
||||
|
|
|
|||
|
|
@ -6,12 +6,14 @@ Supported chips:
|
|||
Prefix: 'it87'
|
||||
Addresses scanned: from Super I/O config space (8 I/O ports)
|
||||
Datasheet: Publicly available at the ITE website
|
||||
http://www.ite.com.tw/
|
||||
http://www.ite.com.tw/product_info/file/pc/IT8705F_V.0.4.1.pdf
|
||||
* IT8712F
|
||||
Prefix: 'it8712'
|
||||
Addresses scanned: from Super I/O config space (8 I/O ports)
|
||||
Datasheet: Publicly available at the ITE website
|
||||
http://www.ite.com.tw/
|
||||
http://www.ite.com.tw/product_info/file/pc/IT8712F_V0.9.1.pdf
|
||||
http://www.ite.com.tw/product_info/file/pc/Errata%20V0.1%20for%20IT8712F%20V0.9.1.pdf
|
||||
http://www.ite.com.tw/product_info/file/pc/IT8712F_V0.9.3.pdf
|
||||
* IT8716F/IT8726F
|
||||
Prefix: 'it8716'
|
||||
Addresses scanned: from Super I/O config space (8 I/O ports)
|
||||
|
|
@ -90,14 +92,13 @@ upper VID bits share their pins with voltage inputs (in5 and in6) so you
|
|||
can't have both on a given board.
|
||||
|
||||
The IT8716F, IT8718F and later IT8712F revisions have support for
|
||||
2 additional fans. They are supported by the driver for the IT8716F and
|
||||
IT8718F but not for the IT8712F
|
||||
2 additional fans. The additional fans are supported by the driver.
|
||||
|
||||
The IT8716F and IT8718F, and late IT8712F and IT8705F also have optional
|
||||
16-bit tachometer counters for fans 1 to 3. This is better (no more fan
|
||||
clock divider mess) but not compatible with the older chips and
|
||||
revisions. For now, the driver only uses the 16-bit mode on the
|
||||
IT8716F and IT8718F.
|
||||
revisions. The 16-bit tachometer mode is enabled by the driver when one
|
||||
of the above chips is detected.
|
||||
|
||||
The IT8726F is just bit enhanced IT8716F with additional hardware
|
||||
for AMD power sequencing. Therefore the chip will appear as IT8716F
|
||||
|
|
|
|||
|
|
@ -96,11 +96,6 @@ initial testing of the ADM1027 it was 1.00 degC steps. Analog Devices has
|
|||
confirmed this "bug". The ADT7463 is reported to work as described in the
|
||||
documentation. The current lm85 driver does not show the offset register.
|
||||
|
||||
The ADT7463 has a THERM asserted counter. This counter has a 22.76ms
|
||||
resolution and a range of 5.8 seconds. The driver implements a 32-bit
|
||||
accumulator of the counter value to extend the range to over a year. The
|
||||
counter will stay at it's max value until read.
|
||||
|
||||
See the vendor datasheets for more information. There is application note
|
||||
from National (AN-1260) with some additional information about the LM85.
|
||||
The Analog Devices datasheet is very detailed and describes a procedure for
|
||||
|
|
@ -206,13 +201,15 @@ Configuration choices:
|
|||
|
||||
The National LM85's have two vendor specific configuration
|
||||
features. Tach. mode and Spinup Control. For more details on these,
|
||||
see the LM85 datasheet or Application Note AN-1260.
|
||||
see the LM85 datasheet or Application Note AN-1260. These features
|
||||
are not currently supported by the lm85 driver.
|
||||
|
||||
The Analog Devices ADM1027 has several vendor specific enhancements.
|
||||
The number of pulses-per-rev of the fans can be set, Tach monitoring
|
||||
can be optimized for PWM operation, and an offset can be applied to
|
||||
the temperatures to compensate for systemic errors in the
|
||||
measurements.
|
||||
measurements. These features are not currently supported by the lm85
|
||||
driver.
|
||||
|
||||
In addition to the ADM1027 features, the ADT7463 also has Tmin control
|
||||
and THERM asserted counts. Automatic Tmin control acts to adjust the
|
||||
|
|
|
|||
|
|
@ -40,10 +40,6 @@ Module Parameters
|
|||
(default is 1)
|
||||
Use 'init=0' to bypass initializing the chip.
|
||||
Try this if your computer crashes when you load the module.
|
||||
* reset: int
|
||||
(default is 0)
|
||||
The driver used to reset the chip on load, but does no more. Use
|
||||
'reset=1' to restore the old behavior. Report if you need to do this.
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
|
|
|||
|
|
@ -22,6 +22,7 @@ Credits:
|
|||
|
||||
Additional contributors:
|
||||
Sven Anders <anders@anduras.de>
|
||||
Marc Hulsman <m.hulsman@tudelft.nl>
|
||||
|
||||
Module Parameters
|
||||
-----------------
|
||||
|
|
@ -67,9 +68,8 @@ on until the temperature falls below the Hysteresis value.
|
|||
|
||||
Fan rotation speeds are reported in RPM (rotations per minute). An alarm is
|
||||
triggered if the rotation speed has dropped below a programmable limit. Fan
|
||||
readings can be divided by a programmable divider (1, 2, 4, 8 for fan 1/2/3
|
||||
and 1, 2, 4, 8, 16, 32, 64 or 128 for fan 4/5) to give the readings more
|
||||
range or accuracy.
|
||||
readings can be divided by a programmable divider (1, 2, 4, 8, 16,
|
||||
32, 64 or 128 for all fans) to give the readings more range or accuracy.
|
||||
|
||||
Voltage sensors (also known as IN sensors) report their values in millivolts.
|
||||
An alarm is triggered if the voltage has crossed a programmable minimum
|
||||
|
|
|
|||
|
|
@ -0,0 +1,281 @@
|
|||
Upgrading I2C Drivers to the new 2.6 Driver Model
|
||||
=================================================
|
||||
|
||||
Ben Dooks <ben-linux@fluff.org>
|
||||
|
||||
Introduction
|
||||
------------
|
||||
|
||||
This guide outlines how to alter existing Linux 2.6 client drivers from
|
||||
the old to the new new binding methods.
|
||||
|
||||
|
||||
Example old-style driver
|
||||
------------------------
|
||||
|
||||
|
||||
struct example_state {
|
||||
struct i2c_client client;
|
||||
....
|
||||
};
|
||||
|
||||
static struct i2c_driver example_driver;
|
||||
|
||||
static unsigned short ignore[] = { I2C_CLIENT_END };
|
||||
static unsigned short normal_addr[] = { OUR_ADDR, I2C_CLIENT_END };
|
||||
|
||||
I2C_CLIENT_INSMOD;
|
||||
|
||||
static int example_attach(struct i2c_adapter *adap, int addr, int kind)
|
||||
{
|
||||
struct example_state *state;
|
||||
struct device *dev = &adap->dev; /* to use for dev_ reports */
|
||||
int ret;
|
||||
|
||||
state = kzalloc(sizeof(struct example_state), GFP_KERNEL);
|
||||
if (state == NULL) {
|
||||
dev_err(dev, "failed to create our state\n");
|
||||
return -ENOMEM;
|
||||
}
|
||||
|
||||
example->client.addr = addr;
|
||||
example->client.flags = 0;
|
||||
example->client.adapter = adap;
|
||||
|
||||
i2c_set_clientdata(&state->i2c_client, state);
|
||||
strlcpy(client->i2c_client.name, "example", I2C_NAME_SIZE);
|
||||
|
||||
ret = i2c_attach_client(&state->i2c_client);
|
||||
if (ret < 0) {
|
||||
dev_err(dev, "failed to attach client\n");
|
||||
kfree(state);
|
||||
return ret;
|
||||
}
|
||||
|
||||
dev = &state->i2c_client.dev;
|
||||
|
||||
/* rest of the initialisation goes here. */
|
||||
|
||||
dev_info(dev, "example client created\n");
|
||||
|
||||
return 0;
|
||||
}
|
||||
|
||||
static int __devexit example_detach(struct i2c_client *client)
|
||||
{
|
||||
struct example_state *state = i2c_get_clientdata(client);
|
||||
|
||||
i2c_detach_client(client);
|
||||
kfree(state);
|
||||
return 0;
|
||||
}
|
||||
|
||||
static int example_attach_adapter(struct i2c_adapter *adap)
|
||||
{
|
||||
return i2c_probe(adap, &addr_data, example_attach);
|
||||
}
|
||||
|
||||
static struct i2c_driver example_driver = {
|
||||
.driver = {
|
||||
.owner = THIS_MODULE,
|
||||
.name = "example",
|
||||
},
|
||||
.attach_adapter = example_attach_adapter,
|
||||
.detach_client = __devexit_p(example_detach),
|
||||
.suspend = example_suspend,
|
||||
.resume = example_resume,
|
||||
};
|
||||
|
||||
|
||||
Updating the client
|
||||
-------------------
|
||||
|
||||
The new style binding model will check against a list of supported
|
||||
devices and their associated address supplied by the code registering
|
||||
the busses. This means that the driver .attach_adapter and
|
||||
.detach_adapter methods can be removed, along with the addr_data,
|
||||
as follows:
|
||||
|
||||
- static struct i2c_driver example_driver;
|
||||
|
||||
- static unsigned short ignore[] = { I2C_CLIENT_END };
|
||||
- static unsigned short normal_addr[] = { OUR_ADDR, I2C_CLIENT_END };
|
||||
|
||||
- I2C_CLIENT_INSMOD;
|
||||
|
||||
- static int example_attach_adapter(struct i2c_adapter *adap)
|
||||
- {
|
||||
- return i2c_probe(adap, &addr_data, example_attach);
|
||||
- }
|
||||
|
||||
static struct i2c_driver example_driver = {
|
||||
- .attach_adapter = example_attach_adapter,
|
||||
- .detach_client = __devexit_p(example_detach),
|
||||
}
|
||||
|
||||
Add the probe and remove methods to the i2c_driver, as so:
|
||||
|
||||
static struct i2c_driver example_driver = {
|
||||
+ .probe = example_probe,
|
||||
+ .remove = __devexit_p(example_remove),
|
||||
}
|
||||
|
||||
Change the example_attach method to accept the new parameters
|
||||
which include the i2c_client that it will be working with:
|
||||
|
||||
- static int example_attach(struct i2c_adapter *adap, int addr, int kind)
|
||||
+ static int example_probe(struct i2c_client *client,
|
||||
+ const struct i2c_device_id *id)
|
||||
|
||||
Change the name of example_attach to example_probe to align it with the
|
||||
i2c_driver entry names. The rest of the probe routine will now need to be
|
||||
changed as the i2c_client has already been setup for use.
|
||||
|
||||
The necessary client fields have already been setup before
|
||||
the probe function is called, so the following client setup
|
||||
can be removed:
|
||||
|
||||
- example->client.addr = addr;
|
||||
- example->client.flags = 0;
|
||||
- example->client.adapter = adap;
|
||||
-
|
||||
- strlcpy(client->i2c_client.name, "example", I2C_NAME_SIZE);
|
||||
|
||||
The i2c_set_clientdata is now:
|
||||
|
||||
- i2c_set_clientdata(&state->client, state);
|
||||
+ i2c_set_clientdata(client, state);
|
||||
|
||||
The call to i2c_attach_client is no longer needed, if the probe
|
||||
routine exits successfully, then the driver will be automatically
|
||||
attached by the core. Change the probe routine as so:
|
||||
|
||||
- ret = i2c_attach_client(&state->i2c_client);
|
||||
- if (ret < 0) {
|
||||
- dev_err(dev, "failed to attach client\n");
|
||||
- kfree(state);
|
||||
- return ret;
|
||||
- }
|
||||
|
||||
|
||||
Remove the storage of 'struct i2c_client' from the 'struct example_state'
|
||||
as we are provided with the i2c_client in our example_probe. Instead we
|
||||
store a pointer to it for when it is needed.
|
||||
|
||||
struct example_state {
|
||||
- struct i2c_client client;
|
||||
+ struct i2c_client *client;
|
||||
|
||||
the new i2c client as so:
|
||||
|
||||
- struct device *dev = &adap->dev; /* to use for dev_ reports */
|
||||
+ struct device *dev = &i2c_client->dev; /* to use for dev_ reports */
|
||||
|
||||
And remove the change after our client is attached, as the driver no
|
||||
longer needs to register a new client structure with the core:
|
||||
|
||||
- dev = &state->i2c_client.dev;
|
||||
|
||||
In the probe routine, ensure that the new state has the client stored
|
||||
in it:
|
||||
|
||||
static int example_probe(struct i2c_client *i2c_client,
|
||||
const struct i2c_device_id *id)
|
||||
{
|
||||
struct example_state *state;
|
||||
struct device *dev = &i2c_client->dev;
|
||||
int ret;
|
||||
|
||||
state = kzalloc(sizeof(struct example_state), GFP_KERNEL);
|
||||
if (state == NULL) {
|
||||
dev_err(dev, "failed to create our state\n");
|
||||
return -ENOMEM;
|
||||
}
|
||||
|
||||
+ state->client = i2c_client;
|
||||
|
||||
Update the detach method, by changing the name to _remove and
|
||||
to delete the i2c_detach_client call. It is possible that you
|
||||
can also remove the ret variable as it is not not needed for
|
||||
any of the core functions.
|
||||
|
||||
- static int __devexit example_detach(struct i2c_client *client)
|
||||
+ static int __devexit example_remove(struct i2c_client *client)
|
||||
{
|
||||
struct example_state *state = i2c_get_clientdata(client);
|
||||
|
||||
- i2c_detach_client(client);
|
||||
|
||||
And finally ensure that we have the correct ID table for the i2c-core
|
||||
and other utilities:
|
||||
|
||||
+ struct i2c_device_id example_idtable[] = {
|
||||
+ { "example", 0 },
|
||||
+ { }
|
||||
+};
|
||||
+
|
||||
+MODULE_DEVICE_TABLE(i2c, example_idtable);
|
||||
|
||||
static struct i2c_driver example_driver = {
|
||||
.driver = {
|
||||
.owner = THIS_MODULE,
|
||||
.name = "example",
|
||||
},
|
||||
+ .id_table = example_ids,
|
||||
|
||||
|
||||
Our driver should now look like this:
|
||||
|
||||
struct example_state {
|
||||
struct i2c_client *client;
|
||||
....
|
||||
};
|
||||
|
||||
static int example_probe(struct i2c_client *client,
|
||||
const struct i2c_device_id *id)
|
||||
{
|
||||
struct example_state *state;
|
||||
struct device *dev = &client->dev;
|
||||
|
||||
state = kzalloc(sizeof(struct example_state), GFP_KERNEL);
|
||||
if (state == NULL) {
|
||||
dev_err(dev, "failed to create our state\n");
|
||||
return -ENOMEM;
|
||||
}
|
||||
|
||||
state->client = client;
|
||||
i2c_set_clientdata(client, state);
|
||||
|
||||
/* rest of the initialisation goes here. */
|
||||
|
||||
dev_info(dev, "example client created\n");
|
||||
|
||||
return 0;
|
||||
}
|
||||
|
||||
static int __devexit example_remove(struct i2c_client *client)
|
||||
{
|
||||
struct example_state *state = i2c_get_clientdata(client);
|
||||
|
||||
kfree(state);
|
||||
return 0;
|
||||
}
|
||||
|
||||
static struct i2c_device_id example_idtable[] = {
|
||||
{ "example", 0 },
|
||||
{ }
|
||||
};
|
||||
|
||||
MODULE_DEVICE_TABLE(i2c, example_idtable);
|
||||
|
||||
static struct i2c_driver example_driver = {
|
||||
.driver = {
|
||||
.owner = THIS_MODULE,
|
||||
.name = "example",
|
||||
},
|
||||
.id_table = example_idtable,
|
||||
.probe = example_probe,
|
||||
.remove = __devexit_p(example_remove),
|
||||
.suspend = example_suspend,
|
||||
.resume = example_resume,
|
||||
};
|
||||
|
|
@ -50,9 +50,9 @@ Note: For step 2, please make sure that host page size == TARGET_PAGE_SIZE of qe
|
|||
/usr/local/bin/qemu-system-ia64 -smp xx -m 512 -hda $your_image
|
||||
(xx is the number of virtual processors for the guest, now the maximum value is 4)
|
||||
|
||||
5. Known possibile issue on some platforms with old Firmware.
|
||||
5. Known possible issue on some platforms with old Firmware.
|
||||
|
||||
If meet strange host crashe issues, try to solve it through either of the following ways:
|
||||
In the event of strange host crash issues, try to solve it through either of the following ways:
|
||||
|
||||
(1): Upgrade your Firmware to the latest one.
|
||||
|
||||
|
|
@ -65,8 +65,8 @@ index 0b53344..f02b0f7 100644
|
|||
mov ar.pfs = loc1
|
||||
mov rp = loc0
|
||||
;;
|
||||
- srlz.d // seralize restoration of psr.l
|
||||
+ srlz.i // seralize restoration of psr.l
|
||||
- srlz.d // serialize restoration of psr.l
|
||||
+ srlz.i // serialize restoration of psr.l
|
||||
+ ;;
|
||||
br.ret.sptk.many b0
|
||||
END(ia64_pal_call_static)
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ The driver works with ALSA drivers simultaneously. For example, the xracer
|
|||
uses joystick as input device and PCM device as sound output in one time.
|
||||
There are no sound or input collisions detected. The source code have
|
||||
comments about them; but I've found the joystick can be initialized
|
||||
separately of ALSA modules. So, you canm use only one joystick driver
|
||||
separately of ALSA modules. So, you can use only one joystick driver
|
||||
without ALSA drivers. The ALSA drivers are not needed to compile or
|
||||
run this driver.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
To decode a hex IOCTL code:
|
||||
|
||||
Most architecures use this generic format, but check
|
||||
Most architectures use this generic format, but check
|
||||
include/ARCH/ioctl.h for specifics, e.g. powerpc
|
||||
uses 3 bits to encode read/write and 13 bits for size.
|
||||
|
||||
|
|
@ -18,7 +18,7 @@ uses 3 bits to encode read/write and 13 bits for size.
|
|||
7-0 function #
|
||||
|
||||
|
||||
So for example 0x82187201 is a read with arg length of 0x218,
|
||||
So for example 0x82187201 is a read with arg length of 0x218,
|
||||
character 'r' function 1. Grepping the source reveals this is:
|
||||
|
||||
#define VFAT_IOCTL_READDIR_BOTH _IOR('r', 1, struct dirent [2])
|
||||
|
|
|
|||
|
|
@ -143,7 +143,7 @@ disk and partition statistics are consistent again. Since we still don't
|
|||
keep record of the partition-relative address, an operation is attributed to
|
||||
the partition which contains the first sector of the request after the
|
||||
eventual merges. As requests can be merged across partition, this could lead
|
||||
to some (probably insignificant) innacuracy.
|
||||
to some (probably insignificant) inaccuracy.
|
||||
|
||||
Additional notes
|
||||
----------------
|
||||
|
|
|
|||
|
|
@ -0,0 +1,6 @@
|
|||
mISDN is a new modular ISDN driver, in the long term it should replace
|
||||
the old I4L driver architecture for passiv ISDN cards.
|
||||
It was designed to allow a broad range of applications and interfaces
|
||||
but only have the basic function in kernel, the interface to the user
|
||||
space is based on sockets with a own address family AF_ISDN.
|
||||
|
||||
|
|
@ -65,26 +65,26 @@ Install kexec-tools
|
|||
|
||||
2) Download the kexec-tools user-space package from the following URL:
|
||||
|
||||
http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/kexec-tools-testing.tar.gz
|
||||
http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/kexec-tools.tar.gz
|
||||
|
||||
This is a symlink to the latest version, which at the time of writing is
|
||||
20061214, the only release of kexec-tools-testing so far. As other versions
|
||||
are released, the older ones will remain available at
|
||||
http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/
|
||||
This is a symlink to the latest version.
|
||||
|
||||
Note: Latest kexec-tools-testing git tree is available at
|
||||
The latest kexec-tools git tree is available at:
|
||||
|
||||
git://git.kernel.org/pub/scm/linux/kernel/git/horms/kexec-tools-testing.git
|
||||
git://git.kernel.org/pub/scm/linux/kernel/git/horms/kexec-tools.git
|
||||
or
|
||||
http://www.kernel.org/git/?p=linux/kernel/git/horms/kexec-tools-testing.git;a=summary
|
||||
http://www.kernel.org/git/?p=linux/kernel/git/horms/kexec-tools.git
|
||||
|
||||
More information about kexec-tools can be found at
|
||||
http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/README.html
|
||||
|
||||
3) Unpack the tarball with the tar command, as follows:
|
||||
|
||||
tar xvpzf kexec-tools-testing.tar.gz
|
||||
tar xvpzf kexec-tools.tar.gz
|
||||
|
||||
4) Change to the kexec-tools directory, as follows:
|
||||
|
||||
cd kexec-tools-testing-VERSION
|
||||
cd kexec-tools-VERSION
|
||||
|
||||
5) Configure the package, as follows:
|
||||
|
||||
|
|
|
|||
|
|
@ -864,7 +864,7 @@ payload contents" for more information.
|
|||
request_key_with_auxdata() respectively.
|
||||
|
||||
These two functions return with the key potentially still under
|
||||
construction. To wait for contruction completion, the following should be
|
||||
construction. To wait for construction completion, the following should be
|
||||
called:
|
||||
|
||||
int wait_for_key_construction(struct key *key, bool intr);
|
||||
|
|
|
|||
|
|
@ -59,7 +59,7 @@ Hardware accelerated blink of LEDs
|
|||
|
||||
Some LEDs can be programmed to blink without any CPU interaction. To
|
||||
support this feature, a LED driver can optionally implement the
|
||||
blink_set() function (see <linux/leds.h>). If implemeted, triggers can
|
||||
blink_set() function (see <linux/leds.h>). If implemented, triggers can
|
||||
attempt to use it before falling back to software timers. The blink_set()
|
||||
function should return 0 if the blink setting is supported, or -EINVAL
|
||||
otherwise, which means that LED blinking will be handled by software.
|
||||
|
|
|
|||
|
|
@ -36,11 +36,13 @@
|
|||
#include <sched.h>
|
||||
#include <limits.h>
|
||||
#include <stddef.h>
|
||||
#include <signal.h>
|
||||
#include "linux/lguest_launcher.h"
|
||||
#include "linux/virtio_config.h"
|
||||
#include "linux/virtio_net.h"
|
||||
#include "linux/virtio_blk.h"
|
||||
#include "linux/virtio_console.h"
|
||||
#include "linux/virtio_rng.h"
|
||||
#include "linux/virtio_ring.h"
|
||||
#include "asm-x86/bootparam.h"
|
||||
/*L:110 We can ignore the 39 include files we need for this program, but I do
|
||||
|
|
@ -64,8 +66,8 @@ typedef uint8_t u8;
|
|||
#endif
|
||||
/* We can have up to 256 pages for devices. */
|
||||
#define DEVICE_PAGES 256
|
||||
/* This will occupy 2 pages: it must be a power of 2. */
|
||||
#define VIRTQUEUE_NUM 128
|
||||
/* This will occupy 3 pages: it must be a power of 2. */
|
||||
#define VIRTQUEUE_NUM 256
|
||||
|
||||
/*L:120 verbose is both a global flag and a macro. The C preprocessor allows
|
||||
* this, and although I wouldn't recommend it, it works quite nicely here. */
|
||||
|
|
@ -74,12 +76,19 @@ static bool verbose;
|
|||
do { if (verbose) printf(args); } while(0)
|
||||
/*:*/
|
||||
|
||||
/* The pipe to send commands to the waker process */
|
||||
static int waker_fd;
|
||||
/* File descriptors for the Waker. */
|
||||
struct {
|
||||
int pipe[2];
|
||||
int lguest_fd;
|
||||
} waker_fds;
|
||||
|
||||
/* The pointer to the start of guest memory. */
|
||||
static void *guest_base;
|
||||
/* The maximum guest physical address allowed, and maximum possible. */
|
||||
static unsigned long guest_limit, guest_max;
|
||||
/* The pipe for signal hander to write to. */
|
||||
static int timeoutpipe[2];
|
||||
static unsigned int timeout_usec = 500;
|
||||
|
||||
/* a per-cpu variable indicating whose vcpu is currently running */
|
||||
static unsigned int __thread cpu_id;
|
||||
|
|
@ -155,11 +164,14 @@ struct virtqueue
|
|||
/* Last available index we saw. */
|
||||
u16 last_avail_idx;
|
||||
|
||||
/* The routine to call when the Guest pings us. */
|
||||
void (*handle_output)(int fd, struct virtqueue *me);
|
||||
/* The routine to call when the Guest pings us, or timeout. */
|
||||
void (*handle_output)(int fd, struct virtqueue *me, bool timeout);
|
||||
|
||||
/* Outstanding buffers */
|
||||
unsigned int inflight;
|
||||
|
||||
/* Is this blocked awaiting a timer? */
|
||||
bool blocked;
|
||||
};
|
||||
|
||||
/* Remember the arguments to the program so we can "reboot" */
|
||||
|
|
@ -190,6 +202,9 @@ static void *_convert(struct iovec *iov, size_t size, size_t align,
|
|||
return iov->iov_base;
|
||||
}
|
||||
|
||||
/* Wrapper for the last available index. Makes it easier to change. */
|
||||
#define lg_last_avail(vq) ((vq)->last_avail_idx)
|
||||
|
||||
/* The virtio configuration space is defined to be little-endian. x86 is
|
||||
* little-endian too, but it's nice to be explicit so we have these helpers. */
|
||||
#define cpu_to_le16(v16) (v16)
|
||||
|
|
@ -199,6 +214,33 @@ static void *_convert(struct iovec *iov, size_t size, size_t align,
|
|||
#define le32_to_cpu(v32) (v32)
|
||||
#define le64_to_cpu(v64) (v64)
|
||||
|
||||
/* Is this iovec empty? */
|
||||
static bool iov_empty(const struct iovec iov[], unsigned int num_iov)
|
||||
{
|
||||
unsigned int i;
|
||||
|
||||
for (i = 0; i < num_iov; i++)
|
||||
if (iov[i].iov_len)
|
||||
return false;
|
||||
return true;
|
||||
}
|
||||
|
||||
/* Take len bytes from the front of this iovec. */
|
||||
static void iov_consume(struct iovec iov[], unsigned num_iov, unsigned len)
|
||||
{
|
||||
unsigned int i;
|
||||
|
||||
for (i = 0; i < num_iov; i++) {
|
||||
unsigned int used;
|
||||
|
||||
used = iov[i].iov_len < len ? iov[i].iov_len : len;
|
||||
iov[i].iov_base += used;
|
||||
iov[i].iov_len -= used;
|
||||
len -= used;
|
||||
}
|
||||
assert(len == 0);
|
||||
}
|
||||
|
||||
/* The device virtqueue descriptors are followed by feature bitmasks. */
|
||||
static u8 *get_feature_bits(struct device *dev)
|
||||
{
|
||||
|
|
@ -254,6 +296,7 @@ static void *map_zeroed_pages(unsigned int num)
|
|||
PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE, fd, 0);
|
||||
if (addr == MAP_FAILED)
|
||||
err(1, "Mmaping %u pages of /dev/zero", num);
|
||||
close(fd);
|
||||
|
||||
return addr;
|
||||
}
|
||||
|
|
@ -540,69 +583,64 @@ static void add_device_fd(int fd)
|
|||
* watch, but handing a file descriptor mask through to the kernel is fairly
|
||||
* icky.
|
||||
*
|
||||
* Instead, we fork off a process which watches the file descriptors and writes
|
||||
* Instead, we clone off a thread which watches the file descriptors and writes
|
||||
* the LHREQ_BREAK command to the /dev/lguest file descriptor to tell the Host
|
||||
* stop running the Guest. This causes the Launcher to return from the
|
||||
* /dev/lguest read with -EAGAIN, where it will write to /dev/lguest to reset
|
||||
* the LHREQ_BREAK and wake us up again.
|
||||
*
|
||||
* This, of course, is merely a different *kind* of icky.
|
||||
*
|
||||
* Given my well-known antipathy to threads, I'd prefer to use processes. But
|
||||
* it's easier to share Guest memory with threads, and trivial to share the
|
||||
* devices.infds as the Launcher changes it.
|
||||
*/
|
||||
static void wake_parent(int pipefd, int lguest_fd)
|
||||
static int waker(void *unused)
|
||||
{
|
||||
/* Add the pipe from the Launcher to the fdset in the device_list, so
|
||||
* we watch it, too. */
|
||||
add_device_fd(pipefd);
|
||||
/* Close the write end of the pipe: only the Launcher has it open. */
|
||||
close(waker_fds.pipe[1]);
|
||||
|
||||
for (;;) {
|
||||
fd_set rfds = devices.infds;
|
||||
unsigned long args[] = { LHREQ_BREAK, 1 };
|
||||
unsigned int maxfd = devices.max_infd;
|
||||
|
||||
/* We also listen to the pipe from the Launcher. */
|
||||
FD_SET(waker_fds.pipe[0], &rfds);
|
||||
if (waker_fds.pipe[0] > maxfd)
|
||||
maxfd = waker_fds.pipe[0];
|
||||
|
||||
/* Wait until input is ready from one of the devices. */
|
||||
select(devices.max_infd+1, &rfds, NULL, NULL, NULL);
|
||||
/* Is it a message from the Launcher? */
|
||||
if (FD_ISSET(pipefd, &rfds)) {
|
||||
int fd;
|
||||
/* If read() returns 0, it means the Launcher has
|
||||
* exited. We silently follow. */
|
||||
if (read(pipefd, &fd, sizeof(fd)) == 0)
|
||||
exit(0);
|
||||
/* Otherwise it's telling us to change what file
|
||||
* descriptors we're to listen to. Positive means
|
||||
* listen to a new one, negative means stop
|
||||
* listening. */
|
||||
if (fd >= 0)
|
||||
FD_SET(fd, &devices.infds);
|
||||
else
|
||||
FD_CLR(-fd - 1, &devices.infds);
|
||||
} else /* Send LHREQ_BREAK command. */
|
||||
pwrite(lguest_fd, args, sizeof(args), cpu_id);
|
||||
select(maxfd+1, &rfds, NULL, NULL, NULL);
|
||||
|
||||
/* Message from Launcher? */
|
||||
if (FD_ISSET(waker_fds.pipe[0], &rfds)) {
|
||||
char c;
|
||||
/* If this fails, then assume Launcher has exited.
|
||||
* Don't do anything on exit: we're just a thread! */
|
||||
if (read(waker_fds.pipe[0], &c, 1) != 1)
|
||||
_exit(0);
|
||||
continue;
|
||||
}
|
||||
|
||||
/* Send LHREQ_BREAK command to snap the Launcher out of it. */
|
||||
pwrite(waker_fds.lguest_fd, args, sizeof(args), cpu_id);
|
||||
}
|
||||
return 0;
|
||||
}
|
||||
|
||||
/* This routine just sets up a pipe to the Waker process. */
|
||||
static int setup_waker(int lguest_fd)
|
||||
static void setup_waker(int lguest_fd)
|
||||
{
|
||||
int pipefd[2], child;
|
||||
/* This pipe is closed when Launcher dies, telling Waker. */
|
||||
if (pipe(waker_fds.pipe) != 0)
|
||||
err(1, "Creating pipe for Waker");
|
||||
|
||||
/* We create a pipe to talk to the Waker, and also so it knows when the
|
||||
* Launcher dies (and closes pipe). */
|
||||
pipe(pipefd);
|
||||
child = fork();
|
||||
if (child == -1)
|
||||
err(1, "forking");
|
||||
/* Waker also needs to know the lguest fd */
|
||||
waker_fds.lguest_fd = lguest_fd;
|
||||
|
||||
if (child == 0) {
|
||||
/* We are the Waker: close the "writing" end of our copy of the
|
||||
* pipe and start waiting for input. */
|
||||
close(pipefd[1]);
|
||||
wake_parent(pipefd[0], lguest_fd);
|
||||
}
|
||||
/* Close the reading end of our copy of the pipe. */
|
||||
close(pipefd[0]);
|
||||
|
||||
/* Here is the fd used to talk to the waker. */
|
||||
return pipefd[1];
|
||||
if (clone(waker, malloc(4096) + 4096, CLONE_VM | SIGCHLD, NULL) == -1)
|
||||
err(1, "Creating Waker");
|
||||
}
|
||||
|
||||
/*
|
||||
|
|
@ -661,19 +699,22 @@ static unsigned get_vq_desc(struct virtqueue *vq,
|
|||
unsigned int *out_num, unsigned int *in_num)
|
||||
{
|
||||
unsigned int i, head;
|
||||
u16 last_avail;
|
||||
|
||||
/* Check it isn't doing very strange things with descriptor numbers. */
|
||||
if ((u16)(vq->vring.avail->idx - vq->last_avail_idx) > vq->vring.num)
|
||||
last_avail = lg_last_avail(vq);
|
||||
if ((u16)(vq->vring.avail->idx - last_avail) > vq->vring.num)
|
||||
errx(1, "Guest moved used index from %u to %u",
|
||||
vq->last_avail_idx, vq->vring.avail->idx);
|
||||
last_avail, vq->vring.avail->idx);
|
||||
|
||||
/* If there's nothing new since last we looked, return invalid. */
|
||||
if (vq->vring.avail->idx == vq->last_avail_idx)
|
||||
if (vq->vring.avail->idx == last_avail)
|
||||
return vq->vring.num;
|
||||
|
||||
/* Grab the next descriptor number they're advertising, and increment
|
||||
* the index we've seen. */
|
||||
head = vq->vring.avail->ring[vq->last_avail_idx++ % vq->vring.num];
|
||||
head = vq->vring.avail->ring[last_avail % vq->vring.num];
|
||||
lg_last_avail(vq)++;
|
||||
|
||||
/* If their number is silly, that's a fatal mistake. */
|
||||
if (head >= vq->vring.num)
|
||||
|
|
@ -821,8 +862,8 @@ static bool handle_console_input(int fd, struct device *dev)
|
|||
unsigned long args[] = { LHREQ_BREAK, 0 };
|
||||
/* Close the fd so Waker will know it has to
|
||||
* exit. */
|
||||
close(waker_fd);
|
||||
/* Just in case waker is blocked in BREAK, send
|
||||
close(waker_fds.pipe[1]);
|
||||
/* Just in case Waker is blocked in BREAK, send
|
||||
* unbreak now. */
|
||||
write(fd, args, sizeof(args));
|
||||
exit(2);
|
||||
|
|
@ -839,7 +880,7 @@ static bool handle_console_input(int fd, struct device *dev)
|
|||
|
||||
/* Handling output for console is simple: we just get all the output buffers
|
||||
* and write them to stdout. */
|
||||
static void handle_console_output(int fd, struct virtqueue *vq)
|
||||
static void handle_console_output(int fd, struct virtqueue *vq, bool timeout)
|
||||
{
|
||||
unsigned int head, out, in;
|
||||
int len;
|
||||
|
|
@ -854,6 +895,21 @@ static void handle_console_output(int fd, struct virtqueue *vq)
|
|||
}
|
||||
}
|
||||
|
||||
static void block_vq(struct virtqueue *vq)
|
||||
{
|
||||
struct itimerval itm;
|
||||
|
||||
vq->vring.used->flags |= VRING_USED_F_NO_NOTIFY;
|
||||
vq->blocked = true;
|
||||
|
||||
itm.it_interval.tv_sec = 0;
|
||||
itm.it_interval.tv_usec = 0;
|
||||
itm.it_value.tv_sec = 0;
|
||||
itm.it_value.tv_usec = timeout_usec;
|
||||
|
||||
setitimer(ITIMER_REAL, &itm, NULL);
|
||||
}
|
||||
|
||||
/*
|
||||
* The Network
|
||||
*
|
||||
|
|
@ -861,22 +917,34 @@ static void handle_console_output(int fd, struct virtqueue *vq)
|
|||
* and write them (ignoring the first element) to this device's file descriptor
|
||||
* (/dev/net/tun).
|
||||
*/
|
||||
static void handle_net_output(int fd, struct virtqueue *vq)
|
||||
static void handle_net_output(int fd, struct virtqueue *vq, bool timeout)
|
||||
{
|
||||
unsigned int head, out, in;
|
||||
unsigned int head, out, in, num = 0;
|
||||
int len;
|
||||
struct iovec iov[vq->vring.num];
|
||||
static int last_timeout_num;
|
||||
|
||||
/* Keep getting output buffers from the Guest until we run out. */
|
||||
while ((head = get_vq_desc(vq, iov, &out, &in)) != vq->vring.num) {
|
||||
if (in)
|
||||
errx(1, "Input buffers in output queue?");
|
||||
/* Check header, but otherwise ignore it (we told the Guest we
|
||||
* supported no features, so it shouldn't have anything
|
||||
* interesting). */
|
||||
(void)convert(&iov[0], struct virtio_net_hdr);
|
||||
len = writev(vq->dev->fd, iov+1, out-1);
|
||||
len = writev(vq->dev->fd, iov, out);
|
||||
if (len < 0)
|
||||
err(1, "Writing network packet to tun");
|
||||
add_used_and_trigger(fd, vq, head, len);
|
||||
num++;
|
||||
}
|
||||
|
||||
/* Block further kicks and set up a timer if we saw anything. */
|
||||
if (!timeout && num)
|
||||
block_vq(vq);
|
||||
|
||||
if (timeout) {
|
||||
if (num < last_timeout_num)
|
||||
timeout_usec += 10;
|
||||
else if (timeout_usec > 1)
|
||||
timeout_usec--;
|
||||
last_timeout_num = num;
|
||||
}
|
||||
}
|
||||
|
||||
|
|
@ -887,7 +955,6 @@ static bool handle_tun_input(int fd, struct device *dev)
|
|||
unsigned int head, in_num, out_num;
|
||||
int len;
|
||||
struct iovec iov[dev->vq->vring.num];
|
||||
struct virtio_net_hdr *hdr;
|
||||
|
||||
/* First we need a network buffer from the Guests's recv virtqueue. */
|
||||
head = get_vq_desc(dev->vq, iov, &out_num, &in_num);
|
||||
|
|
@ -896,25 +963,23 @@ static bool handle_tun_input(int fd, struct device *dev)
|
|||
* early, the Guest won't be ready yet. Wait until the device
|
||||
* status says it's ready. */
|
||||
/* FIXME: Actually want DRIVER_ACTIVE here. */
|
||||
if (dev->desc->status & VIRTIO_CONFIG_S_DRIVER_OK)
|
||||
warn("network: no dma buffer!");
|
||||
|
||||
/* Now tell it we want to know if new things appear. */
|
||||
dev->vq->vring.used->flags &= ~VRING_USED_F_NO_NOTIFY;
|
||||
wmb();
|
||||
|
||||
/* We'll turn this back on if input buffers are registered. */
|
||||
return false;
|
||||
} else if (out_num)
|
||||
errx(1, "Output buffers in network recv queue?");
|
||||
|
||||
/* First element is the header: we set it to 0 (no features). */
|
||||
hdr = convert(&iov[0], struct virtio_net_hdr);
|
||||
hdr->flags = 0;
|
||||
hdr->gso_type = VIRTIO_NET_HDR_GSO_NONE;
|
||||
|
||||
/* Read the packet from the device directly into the Guest's buffer. */
|
||||
len = readv(dev->fd, iov+1, in_num-1);
|
||||
len = readv(dev->fd, iov, in_num);
|
||||
if (len <= 0)
|
||||
err(1, "reading network");
|
||||
|
||||
/* Tell the Guest about the new packet. */
|
||||
add_used_and_trigger(fd, dev->vq, head, sizeof(*hdr) + len);
|
||||
add_used_and_trigger(fd, dev->vq, head, len);
|
||||
|
||||
verbose("tun input packet len %i [%02x %02x] (%s)\n", len,
|
||||
((u8 *)iov[1].iov_base)[0], ((u8 *)iov[1].iov_base)[1],
|
||||
|
|
@ -927,11 +992,18 @@ static bool handle_tun_input(int fd, struct device *dev)
|
|||
/*L:215 This is the callback attached to the network and console input
|
||||
* virtqueues: it ensures we try again, in case we stopped console or net
|
||||
* delivery because Guest didn't have any buffers. */
|
||||
static void enable_fd(int fd, struct virtqueue *vq)
|
||||
static void enable_fd(int fd, struct virtqueue *vq, bool timeout)
|
||||
{
|
||||
add_device_fd(vq->dev->fd);
|
||||
/* Tell waker to listen to it again */
|
||||
write(waker_fd, &vq->dev->fd, sizeof(vq->dev->fd));
|
||||
/* Snap the Waker out of its select loop. */
|
||||
write(waker_fds.pipe[1], "", 1);
|
||||
}
|
||||
|
||||
static void net_enable_fd(int fd, struct virtqueue *vq, bool timeout)
|
||||
{
|
||||
/* We don't need to know again when Guest refills receive buffer. */
|
||||
vq->vring.used->flags |= VRING_USED_F_NO_NOTIFY;
|
||||
enable_fd(fd, vq, timeout);
|
||||
}
|
||||
|
||||
/* When the Guest tells us they updated the status field, we handle it. */
|
||||
|
|
@ -951,7 +1023,7 @@ static void update_device_status(struct device *dev)
|
|||
for (vq = dev->vq; vq; vq = vq->next) {
|
||||
memset(vq->vring.desc, 0,
|
||||
vring_size(vq->config.num, getpagesize()));
|
||||
vq->last_avail_idx = 0;
|
||||
lg_last_avail(vq) = 0;
|
||||
}
|
||||
} else if (dev->desc->status & VIRTIO_CONFIG_S_FAILED) {
|
||||
warnx("Device %s configuration FAILED", dev->name);
|
||||
|
|
@ -960,10 +1032,10 @@ static void update_device_status(struct device *dev)
|
|||
|
||||
verbose("Device %s OK: offered", dev->name);
|
||||
for (i = 0; i < dev->desc->feature_len; i++)
|
||||
verbose(" %08x", get_feature_bits(dev)[i]);
|
||||
verbose(" %02x", get_feature_bits(dev)[i]);
|
||||
verbose(", accepted");
|
||||
for (i = 0; i < dev->desc->feature_len; i++)
|
||||
verbose(" %08x", get_feature_bits(dev)
|
||||
verbose(" %02x", get_feature_bits(dev)
|
||||
[dev->desc->feature_len+i]);
|
||||
|
||||
if (dev->ready)
|
||||
|
|
@ -1000,7 +1072,7 @@ static void handle_output(int fd, unsigned long addr)
|
|||
if (strcmp(vq->dev->name, "console") != 0)
|
||||
verbose("Output to %s\n", vq->dev->name);
|
||||
if (vq->handle_output)
|
||||
vq->handle_output(fd, vq);
|
||||
vq->handle_output(fd, vq, false);
|
||||
return;
|
||||
}
|
||||
}
|
||||
|
|
@ -1014,6 +1086,29 @@ static void handle_output(int fd, unsigned long addr)
|
|||
strnlen(from_guest_phys(addr), guest_limit - addr));
|
||||
}
|
||||
|
||||
static void handle_timeout(int fd)
|
||||
{
|
||||
char buf[32];
|
||||
struct device *i;
|
||||
struct virtqueue *vq;
|
||||
|
||||
/* Clear the pipe */
|
||||
read(timeoutpipe[0], buf, sizeof(buf));
|
||||
|
||||
/* Check each device and virtqueue: flush blocked ones. */
|
||||
for (i = devices.dev; i; i = i->next) {
|
||||
for (vq = i->vq; vq; vq = vq->next) {
|
||||
if (!vq->blocked)
|
||||
continue;
|
||||
|
||||
vq->vring.used->flags &= ~VRING_USED_F_NO_NOTIFY;
|
||||
vq->blocked = false;
|
||||
if (vq->handle_output)
|
||||
vq->handle_output(fd, vq, true);
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
/* This is called when the Waker wakes us up: check for incoming file
|
||||
* descriptors. */
|
||||
static void handle_input(int fd)
|
||||
|
|
@ -1024,16 +1119,20 @@ static void handle_input(int fd)
|
|||
for (;;) {
|
||||
struct device *i;
|
||||
fd_set fds = devices.infds;
|
||||
int num;
|
||||
|
||||
num = select(devices.max_infd+1, &fds, NULL, NULL, &poll);
|
||||
/* Could get interrupted */
|
||||
if (num < 0)
|
||||
continue;
|
||||
/* If nothing is ready, we're done. */
|
||||
if (select(devices.max_infd+1, &fds, NULL, NULL, &poll) == 0)
|
||||
if (num == 0)
|
||||
break;
|
||||
|
||||
/* Otherwise, call the device(s) which have readable file
|
||||
* descriptors and a method of handling them. */
|
||||
for (i = devices.dev; i; i = i->next) {
|
||||
if (i->handle_input && FD_ISSET(i->fd, &fds)) {
|
||||
int dev_fd;
|
||||
if (i->handle_input(fd, i))
|
||||
continue;
|
||||
|
||||
|
|
@ -1043,13 +1142,12 @@ static void handle_input(int fd)
|
|||
* buffers to deliver into. Console also uses
|
||||
* it when it discovers that stdin is closed. */
|
||||
FD_CLR(i->fd, &devices.infds);
|
||||
/* Tell waker to ignore it too, by sending a
|
||||
* negative fd number (-1, since 0 is a valid
|
||||
* FD number). */
|
||||
dev_fd = -i->fd - 1;
|
||||
write(waker_fd, &dev_fd, sizeof(dev_fd));
|
||||
}
|
||||
}
|
||||
|
||||
/* Is this the timeout fd? */
|
||||
if (FD_ISSET(timeoutpipe[0], &fds))
|
||||
handle_timeout(fd);
|
||||
}
|
||||
}
|
||||
|
||||
|
|
@ -1098,7 +1196,7 @@ static struct lguest_device_desc *new_dev_desc(u16 type)
|
|||
/* Each device descriptor is followed by the description of its virtqueues. We
|
||||
* specify how many descriptors the virtqueue is to have. */
|
||||
static void add_virtqueue(struct device *dev, unsigned int num_descs,
|
||||
void (*handle_output)(int fd, struct virtqueue *me))
|
||||
void (*handle_output)(int, struct virtqueue *, bool))
|
||||
{
|
||||
unsigned int pages;
|
||||
struct virtqueue **i, *vq = malloc(sizeof(*vq));
|
||||
|
|
@ -1114,6 +1212,7 @@ static void add_virtqueue(struct device *dev, unsigned int num_descs,
|
|||
vq->last_avail_idx = 0;
|
||||
vq->dev = dev;
|
||||
vq->inflight = 0;
|
||||
vq->blocked = false;
|
||||
|
||||
/* Initialize the configuration. */
|
||||
vq->config.num = num_descs;
|
||||
|
|
@ -1246,6 +1345,24 @@ static void setup_console(void)
|
|||
}
|
||||
/*:*/
|
||||
|
||||
static void timeout_alarm(int sig)
|
||||
{
|
||||
write(timeoutpipe[1], "", 1);
|
||||
}
|
||||
|
||||
static void setup_timeout(void)
|
||||
{
|
||||
if (pipe(timeoutpipe) != 0)
|
||||
err(1, "Creating timeout pipe");
|
||||
|
||||
if (fcntl(timeoutpipe[1], F_SETFL,
|
||||
fcntl(timeoutpipe[1], F_GETFL) | O_NONBLOCK) != 0)
|
||||
err(1, "Making timeout pipe nonblocking");
|
||||
|
||||
add_device_fd(timeoutpipe[0]);
|
||||
signal(SIGALRM, timeout_alarm);
|
||||
}
|
||||
|
||||
/*M:010 Inter-guest networking is an interesting area. Simplest is to have a
|
||||
* --sharenet=<name> option which opens or creates a named pipe. This can be
|
||||
* used to send packets to another guest in a 1:1 manner.
|
||||
|
|
@ -1264,10 +1381,25 @@ static void setup_console(void)
|
|||
|
||||
static u32 str2ip(const char *ipaddr)
|
||||
{
|
||||
unsigned int byte[4];
|
||||
unsigned int b[4];
|
||||
|
||||
sscanf(ipaddr, "%u.%u.%u.%u", &byte[0], &byte[1], &byte[2], &byte[3]);
|
||||
return (byte[0] << 24) | (byte[1] << 16) | (byte[2] << 8) | byte[3];
|
||||
if (sscanf(ipaddr, "%u.%u.%u.%u", &b[0], &b[1], &b[2], &b[3]) != 4)
|
||||
errx(1, "Failed to parse IP address '%s'", ipaddr);
|
||||
return (b[0] << 24) | (b[1] << 16) | (b[2] << 8) | b[3];
|
||||
}
|
||||
|
||||
static void str2mac(const char *macaddr, unsigned char mac[6])
|
||||
{
|
||||
unsigned int m[6];
|
||||
if (sscanf(macaddr, "%02x:%02x:%02x:%02x:%02x:%02x",
|
||||
&m[0], &m[1], &m[2], &m[3], &m[4], &m[5]) != 6)
|
||||
errx(1, "Failed to parse mac address '%s'", macaddr);
|
||||
mac[0] = m[0];
|
||||
mac[1] = m[1];
|
||||
mac[2] = m[2];
|
||||
mac[3] = m[3];
|
||||
mac[4] = m[4];
|
||||
mac[5] = m[5];
|
||||
}
|
||||
|
||||
/* This code is "adapted" from libbridge: it attaches the Host end of the
|
||||
|
|
@ -1288,6 +1420,7 @@ static void add_to_bridge(int fd, const char *if_name, const char *br_name)
|
|||
errx(1, "interface %s does not exist!", if_name);
|
||||
|
||||
strncpy(ifr.ifr_name, br_name, IFNAMSIZ);
|
||||
ifr.ifr_name[IFNAMSIZ-1] = '\0';
|
||||
ifr.ifr_ifindex = ifidx;
|
||||
if (ioctl(fd, SIOCBRADDIF, &ifr) < 0)
|
||||
err(1, "can't add %s to bridge %s", if_name, br_name);
|
||||
|
|
@ -1296,64 +1429,90 @@ static void add_to_bridge(int fd, const char *if_name, const char *br_name)
|
|||
/* This sets up the Host end of the network device with an IP address, brings
|
||||
* it up so packets will flow, the copies the MAC address into the hwaddr
|
||||
* pointer. */
|
||||
static void configure_device(int fd, const char *devname, u32 ipaddr,
|
||||
unsigned char hwaddr[6])
|
||||
static void configure_device(int fd, const char *tapif, u32 ipaddr)
|
||||
{
|
||||
struct ifreq ifr;
|
||||
struct sockaddr_in *sin = (struct sockaddr_in *)&ifr.ifr_addr;
|
||||
|
||||
/* Don't read these incantations. Just cut & paste them like I did! */
|
||||
memset(&ifr, 0, sizeof(ifr));
|
||||
strcpy(ifr.ifr_name, devname);
|
||||
strcpy(ifr.ifr_name, tapif);
|
||||
|
||||
/* Don't read these incantations. Just cut & paste them like I did! */
|
||||
sin->sin_family = AF_INET;
|
||||
sin->sin_addr.s_addr = htonl(ipaddr);
|
||||
if (ioctl(fd, SIOCSIFADDR, &ifr) != 0)
|
||||
err(1, "Setting %s interface address", devname);
|
||||
err(1, "Setting %s interface address", tapif);
|
||||
ifr.ifr_flags = IFF_UP;
|
||||
if (ioctl(fd, SIOCSIFFLAGS, &ifr) != 0)
|
||||
err(1, "Bringing interface %s up", devname);
|
||||
err(1, "Bringing interface %s up", tapif);
|
||||
}
|
||||
|
||||
static void get_mac(int fd, const char *tapif, unsigned char hwaddr[6])
|
||||
{
|
||||
struct ifreq ifr;
|
||||
|
||||
memset(&ifr, 0, sizeof(ifr));
|
||||
strcpy(ifr.ifr_name, tapif);
|
||||
|
||||
/* SIOC stands for Socket I/O Control. G means Get (vs S for Set
|
||||
* above). IF means Interface, and HWADDR is hardware address.
|
||||
* Simple! */
|
||||
if (ioctl(fd, SIOCGIFHWADDR, &ifr) != 0)
|
||||
err(1, "getting hw address for %s", devname);
|
||||
err(1, "getting hw address for %s", tapif);
|
||||
memcpy(hwaddr, ifr.ifr_hwaddr.sa_data, 6);
|
||||
}
|
||||
|
||||
/*L:195 Our network is a Host<->Guest network. This can either use bridging or
|
||||
* routing, but the principle is the same: it uses the "tun" device to inject
|
||||
* packets into the Host as if they came in from a normal network card. We
|
||||
* just shunt packets between the Guest and the tun device. */
|
||||
static void setup_tun_net(const char *arg)
|
||||
static int get_tun_device(char tapif[IFNAMSIZ])
|
||||
{
|
||||
struct device *dev;
|
||||
struct ifreq ifr;
|
||||
int netfd, ipfd;
|
||||
u32 ip;
|
||||
const char *br_name = NULL;
|
||||
struct virtio_net_config conf;
|
||||
int netfd;
|
||||
|
||||
/* Start with this zeroed. Messy but sure. */
|
||||
memset(&ifr, 0, sizeof(ifr));
|
||||
|
||||
/* We open the /dev/net/tun device and tell it we want a tap device. A
|
||||
* tap device is like a tun device, only somehow different. To tell
|
||||
* the truth, I completely blundered my way through this code, but it
|
||||
* works now! */
|
||||
netfd = open_or_die("/dev/net/tun", O_RDWR);
|
||||
memset(&ifr, 0, sizeof(ifr));
|
||||
ifr.ifr_flags = IFF_TAP | IFF_NO_PI;
|
||||
ifr.ifr_flags = IFF_TAP | IFF_NO_PI | IFF_VNET_HDR;
|
||||
strcpy(ifr.ifr_name, "tap%d");
|
||||
if (ioctl(netfd, TUNSETIFF, &ifr) != 0)
|
||||
err(1, "configuring /dev/net/tun");
|
||||
|
||||
if (ioctl(netfd, TUNSETOFFLOAD,
|
||||
TUN_F_CSUM|TUN_F_TSO4|TUN_F_TSO6|TUN_F_TSO_ECN) != 0)
|
||||
err(1, "Could not set features for tun device");
|
||||
|
||||
/* We don't need checksums calculated for packets coming in this
|
||||
* device: trust us! */
|
||||
ioctl(netfd, TUNSETNOCSUM, 1);
|
||||
|
||||
memcpy(tapif, ifr.ifr_name, IFNAMSIZ);
|
||||
return netfd;
|
||||
}
|
||||
|
||||
/*L:195 Our network is a Host<->Guest network. This can either use bridging or
|
||||
* routing, but the principle is the same: it uses the "tun" device to inject
|
||||
* packets into the Host as if they came in from a normal network card. We
|
||||
* just shunt packets between the Guest and the tun device. */
|
||||
static void setup_tun_net(char *arg)
|
||||
{
|
||||
struct device *dev;
|
||||
int netfd, ipfd;
|
||||
u32 ip = INADDR_ANY;
|
||||
bool bridging = false;
|
||||
char tapif[IFNAMSIZ], *p;
|
||||
struct virtio_net_config conf;
|
||||
|
||||
netfd = get_tun_device(tapif);
|
||||
|
||||
/* First we create a new network device. */
|
||||
dev = new_device("net", VIRTIO_ID_NET, netfd, handle_tun_input);
|
||||
|
||||
/* Network devices need a receive and a send queue, just like
|
||||
* console. */
|
||||
add_virtqueue(dev, VIRTQUEUE_NUM, enable_fd);
|
||||
add_virtqueue(dev, VIRTQUEUE_NUM, net_enable_fd);
|
||||
add_virtqueue(dev, VIRTQUEUE_NUM, handle_net_output);
|
||||
|
||||
/* We need a socket to perform the magic network ioctls to bring up the
|
||||
|
|
@ -1364,28 +1523,56 @@ static void setup_tun_net(const char *arg)
|
|||
|
||||
/* If the command line was --tunnet=bridge:<name> do bridging. */
|
||||
if (!strncmp(BRIDGE_PFX, arg, strlen(BRIDGE_PFX))) {
|
||||
ip = INADDR_ANY;
|
||||
br_name = arg + strlen(BRIDGE_PFX);
|
||||
add_to_bridge(ipfd, ifr.ifr_name, br_name);
|
||||
} else /* It is an IP address to set up the device with */
|
||||
arg += strlen(BRIDGE_PFX);
|
||||
bridging = true;
|
||||
}
|
||||
|
||||
/* A mac address may follow the bridge name or IP address */
|
||||
p = strchr(arg, ':');
|
||||
if (p) {
|
||||
str2mac(p+1, conf.mac);
|
||||
*p = '\0';
|
||||
} else {
|
||||
p = arg + strlen(arg);
|
||||
/* None supplied; query the randomly assigned mac. */
|
||||
get_mac(ipfd, tapif, conf.mac);
|
||||
}
|
||||
|
||||
/* arg is now either an IP address or a bridge name */
|
||||
if (bridging)
|
||||
add_to_bridge(ipfd, tapif, arg);
|
||||
else
|
||||
ip = str2ip(arg);
|
||||
|
||||
/* Set up the tun device, and get the mac address for the interface. */
|
||||
configure_device(ipfd, ifr.ifr_name, ip, conf.mac);
|
||||
/* Set up the tun device. */
|
||||
configure_device(ipfd, tapif, ip);
|
||||
|
||||
/* Tell Guest what MAC address to use. */
|
||||
add_feature(dev, VIRTIO_NET_F_MAC);
|
||||
add_feature(dev, VIRTIO_F_NOTIFY_ON_EMPTY);
|
||||
/* Expect Guest to handle everything except UFO */
|
||||
add_feature(dev, VIRTIO_NET_F_CSUM);
|
||||
add_feature(dev, VIRTIO_NET_F_GUEST_CSUM);
|
||||
add_feature(dev, VIRTIO_NET_F_MAC);
|
||||
add_feature(dev, VIRTIO_NET_F_GUEST_TSO4);
|
||||
add_feature(dev, VIRTIO_NET_F_GUEST_TSO6);
|
||||
add_feature(dev, VIRTIO_NET_F_GUEST_ECN);
|
||||
add_feature(dev, VIRTIO_NET_F_HOST_TSO4);
|
||||
add_feature(dev, VIRTIO_NET_F_HOST_TSO6);
|
||||
add_feature(dev, VIRTIO_NET_F_HOST_ECN);
|
||||
set_config(dev, sizeof(conf), &conf);
|
||||
|
||||
/* We don't need the socket any more; setup is done. */
|
||||
close(ipfd);
|
||||
|
||||
verbose("device %u: tun net %u.%u.%u.%u\n",
|
||||
devices.device_num++,
|
||||
(u8)(ip>>24),(u8)(ip>>16),(u8)(ip>>8),(u8)ip);
|
||||
if (br_name)
|
||||
verbose("attached to bridge: %s\n", br_name);
|
||||
devices.device_num++;
|
||||
|
||||
if (bridging)
|
||||
verbose("device %u: tun %s attached to bridge: %s\n",
|
||||
devices.device_num, tapif, arg);
|
||||
else
|
||||
verbose("device %u: tun %s: %s\n",
|
||||
devices.device_num, tapif, arg);
|
||||
}
|
||||
|
||||
/* Our block (disk) device should be really simple: the Guest asks for a block
|
||||
|
|
@ -1550,7 +1737,7 @@ static bool handle_io_finish(int fd, struct device *dev)
|
|||
}
|
||||
|
||||
/* When the Guest submits some I/O, we just need to wake the I/O thread. */
|
||||
static void handle_virtblk_output(int fd, struct virtqueue *vq)
|
||||
static void handle_virtblk_output(int fd, struct virtqueue *vq, bool timeout)
|
||||
{
|
||||
struct vblk_info *vblk = vq->dev->priv;
|
||||
char c = 0;
|
||||
|
|
@ -1621,6 +1808,64 @@ static void setup_block_file(const char *filename)
|
|||
verbose("device %u: virtblock %llu sectors\n",
|
||||
devices.device_num, le64_to_cpu(conf.capacity));
|
||||
}
|
||||
|
||||
/* Our random number generator device reads from /dev/random into the Guest's
|
||||
* input buffers. The usual case is that the Guest doesn't want random numbers
|
||||
* and so has no buffers although /dev/random is still readable, whereas
|
||||
* console is the reverse.
|
||||
*
|
||||
* The same logic applies, however. */
|
||||
static bool handle_rng_input(int fd, struct device *dev)
|
||||
{
|
||||
int len;
|
||||
unsigned int head, in_num, out_num, totlen = 0;
|
||||
struct iovec iov[dev->vq->vring.num];
|
||||
|
||||
/* First we need a buffer from the Guests's virtqueue. */
|
||||
head = get_vq_desc(dev->vq, iov, &out_num, &in_num);
|
||||
|
||||
/* If they're not ready for input, stop listening to this file
|
||||
* descriptor. We'll start again once they add an input buffer. */
|
||||
if (head == dev->vq->vring.num)
|
||||
return false;
|
||||
|
||||
if (out_num)
|
||||
errx(1, "Output buffers in rng?");
|
||||
|
||||
/* This is why we convert to iovecs: the readv() call uses them, and so
|
||||
* it reads straight into the Guest's buffer. We loop to make sure we
|
||||
* fill it. */
|
||||
while (!iov_empty(iov, in_num)) {
|
||||
len = readv(dev->fd, iov, in_num);
|
||||
if (len <= 0)
|
||||
err(1, "Read from /dev/random gave %i", len);
|
||||
iov_consume(iov, in_num, len);
|
||||
totlen += len;
|
||||
}
|
||||
|
||||
/* Tell the Guest about the new input. */
|
||||
add_used_and_trigger(fd, dev->vq, head, totlen);
|
||||
|
||||
/* Everything went OK! */
|
||||
return true;
|
||||
}
|
||||
|
||||
/* And this creates a "hardware" random number device for the Guest. */
|
||||
static void setup_rng(void)
|
||||
{
|
||||
struct device *dev;
|
||||
int fd;
|
||||
|
||||
fd = open_or_die("/dev/random", O_RDONLY);
|
||||
|
||||
/* The device responds to return from I/O thread. */
|
||||
dev = new_device("rng", VIRTIO_ID_RNG, fd, handle_rng_input);
|
||||
|
||||
/* The device has one virtqueue, where the Guest places inbufs. */
|
||||
add_virtqueue(dev, VIRTQUEUE_NUM, enable_fd);
|
||||
|
||||
verbose("device %u: rng\n", devices.device_num++);
|
||||
}
|
||||
/* That's the end of device setup. */
|
||||
|
||||
/*L:230 Reboot is pretty easy: clean up and exec() the Launcher afresh. */
|
||||
|
|
@ -1628,11 +1873,12 @@ static void __attribute__((noreturn)) restart_guest(void)
|
|||
{
|
||||
unsigned int i;
|
||||
|
||||
/* Closing pipes causes the Waker thread and io_threads to die, and
|
||||
* closing /dev/lguest cleans up the Guest. Since we don't track all
|
||||
* open fds, we simply close everything beyond stderr. */
|
||||
/* Since we don't track all open fds, we simply close everything beyond
|
||||
* stderr. */
|
||||
for (i = 3; i < FD_SETSIZE; i++)
|
||||
close(i);
|
||||
|
||||
/* The exec automatically gets rid of the I/O and Waker threads. */
|
||||
execv(main_args[0], main_args);
|
||||
err(1, "Could not exec %s", main_args[0]);
|
||||
}
|
||||
|
|
@ -1663,7 +1909,7 @@ static void __attribute__((noreturn)) run_guest(int lguest_fd)
|
|||
/* ERESTART means that we need to reboot the guest */
|
||||
} else if (errno == ERESTART) {
|
||||
restart_guest();
|
||||
/* EAGAIN means the Waker wanted us to look at some input.
|
||||
/* EAGAIN means a signal (timeout).
|
||||
* Anything else means a bug or incompatible change. */
|
||||
} else if (errno != EAGAIN)
|
||||
err(1, "Running guest failed");
|
||||
|
|
@ -1691,13 +1937,14 @@ static struct option opts[] = {
|
|||
{ "verbose", 0, NULL, 'v' },
|
||||
{ "tunnet", 1, NULL, 't' },
|
||||
{ "block", 1, NULL, 'b' },
|
||||
{ "rng", 0, NULL, 'r' },
|
||||
{ "initrd", 1, NULL, 'i' },
|
||||
{ NULL },
|
||||
};
|
||||
static void usage(void)
|
||||
{
|
||||
errx(1, "Usage: lguest [--verbose] "
|
||||
"[--tunnet=(<ipaddr>|bridge:<bridgename>)\n"
|
||||
"[--tunnet=(<ipaddr>:<macaddr>|bridge:<bridgename>:<macaddr>)\n"
|
||||
"|--block=<filename>|--initrd=<filename>]...\n"
|
||||
"<mem-in-mb> vmlinux [args...]");
|
||||
}
|
||||
|
|
@ -1765,6 +2012,9 @@ int main(int argc, char *argv[])
|
|||
case 'b':
|
||||
setup_block_file(optarg);
|
||||
break;
|
||||
case 'r':
|
||||
setup_rng();
|
||||
break;
|
||||
case 'i':
|
||||
initrd_name = optarg;
|
||||
break;
|
||||
|
|
@ -1783,6 +2033,9 @@ int main(int argc, char *argv[])
|
|||
/* We always have a console device */
|
||||
setup_console();
|
||||
|
||||
/* We can timeout waiting for Guest network transmit. */
|
||||
setup_timeout();
|
||||
|
||||
/* Now we load the kernel */
|
||||
start = load_kernel(open_or_die(argv[optind+1], O_RDONLY));
|
||||
|
||||
|
|
@ -1826,10 +2079,10 @@ int main(int argc, char *argv[])
|
|||
* /dev/lguest file descriptor. */
|
||||
lguest_fd = tell_kernel(pgdir, start);
|
||||
|
||||
/* We fork off a child process, which wakes the Launcher whenever one
|
||||
* of the input file descriptors needs attention. We call this the
|
||||
* Waker, and we'll cover it in a moment. */
|
||||
waker_fd = setup_waker(lguest_fd);
|
||||
/* We clone off a thread, which wakes the Launcher whenever one of the
|
||||
* input file descriptors needs attention. We call this the Waker, and
|
||||
* we'll cover it in a moment. */
|
||||
setup_waker(lguest_fd);
|
||||
|
||||
/* Finally, run the Guest. This doesn't return. */
|
||||
run_guest(lguest_fd);
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ It can be done by slightly modifying the standard atomic operations : only
|
|||
their UP variant must be kept. It typically means removing LOCK prefix (on
|
||||
i386 and x86_64) and any SMP sychronization barrier. If the architecture does
|
||||
not have a different behavior between SMP and UP, including asm-generic/local.h
|
||||
in your archtecture's local.h is sufficient.
|
||||
in your architecture's local.h is sufficient.
|
||||
|
||||
The local_t type is defined as an opaque signed long by embedding an
|
||||
atomic_long_t inside a structure. This is made so a cast from this type to a
|
||||
|
|
|
|||
|
|
@ -631,7 +631,7 @@ xmit_hash_policy
|
|||
in environments where a layer3 gateway device is
|
||||
required to reach most destinations.
|
||||
|
||||
This algorithm is 802.3ad complient.
|
||||
This algorithm is 802.3ad compliant.
|
||||
|
||||
layer3+4
|
||||
|
||||
|
|
|
|||
|
|
@ -186,7 +186,7 @@ solution for a couple of reasons:
|
|||
|
||||
The Linux network devices (by default) just can handle the
|
||||
transmission and reception of media dependent frames. Due to the
|
||||
arbritration on the CAN bus the transmission of a low prio CAN-ID
|
||||
arbitration on the CAN bus the transmission of a low prio CAN-ID
|
||||
may be delayed by the reception of a high prio CAN frame. To
|
||||
reflect the correct* traffic on the node the loopback of the sent
|
||||
data has to be performed right after a successful transmission. If
|
||||
|
|
@ -481,7 +481,7 @@ solution for a couple of reasons:
|
|||
- stats_timer: To calculate the Socket CAN core statistics
|
||||
(e.g. current/maximum frames per second) this 1 second timer is
|
||||
invoked at can.ko module start time by default. This timer can be
|
||||
disabled by using stattimer=0 on the module comandline.
|
||||
disabled by using stattimer=0 on the module commandline.
|
||||
|
||||
- debug: (removed since SocketCAN SVN r546)
|
||||
|
||||
|
|
|
|||
|
|
@ -326,7 +326,7 @@ just one call to mmap is needed:
|
|||
mmap(0, size, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
|
||||
|
||||
If tp_frame_size is a divisor of tp_block_size frames will be
|
||||
contiguosly spaced by tp_frame_size bytes. If not, each
|
||||
contiguously spaced by tp_frame_size bytes. If not, each
|
||||
tp_block_size/tp_frame_size frames there will be a gap between
|
||||
the frames. This is because a frame cannot be spawn across two
|
||||
blocks.
|
||||
|
|
|
|||
|
|
@ -4,26 +4,27 @@ The "enviromental" rules for authors of any new tc actions are:
|
|||
1) If you stealeth or borroweth any packet thou shalt be branching
|
||||
from the righteous path and thou shalt cloneth.
|
||||
|
||||
For example if your action queues a packet to be processed later
|
||||
or intentionaly branches by redirecting a packet then you need to
|
||||
For example if your action queues a packet to be processed later,
|
||||
or intentionally branches by redirecting a packet, then you need to
|
||||
clone the packet.
|
||||
|
||||
There are certain fields in the skb tc_verd that need to be reset so we
|
||||
avoid loops etc. A few are generic enough so much so that skb_act_clone()
|
||||
resets them for you. So invoke skb_act_clone() rather than skb_clone()
|
||||
avoid loops, etc. A few are generic enough that skb_act_clone()
|
||||
resets them for you, so invoke skb_act_clone() rather than skb_clone().
|
||||
|
||||
2) If you munge any packet thou shalt call pskb_expand_head in the case
|
||||
someone else is referencing the skb. After that you "own" the skb.
|
||||
You must also tell us if it is ok to munge the packet (TC_OK2MUNGE),
|
||||
this way any action downstream can stomp on the packet.
|
||||
|
||||
3) dropping packets you dont own is a nono. You simply return
|
||||
3) Dropping packets you don't own is a no-no. You simply return
|
||||
TC_ACT_SHOT to the caller and they will drop it.
|
||||
|
||||
The "enviromental" rules for callers of actions (qdiscs etc) are:
|
||||
|
||||
*) thou art responsible for freeing anything returned as being
|
||||
*) Thou art responsible for freeing anything returned as being
|
||||
TC_ACT_SHOT/STOLEN/QUEUED. If none of TC_ACT_SHOT/STOLEN/QUEUED is
|
||||
returned then all is great and you dont need to do anything.
|
||||
returned, then all is great and you don't need to do anything.
|
||||
|
||||
Post on netdev if something is unclear.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
PM quality of Service interface.
|
||||
PM Quality Of Service Interface.
|
||||
|
||||
This interface provides a kernel and user mode interface for registering
|
||||
performance expectations by drivers, subsystems and user space applications on
|
||||
|
|
@ -7,6 +7,11 @@ one of the parameters.
|
|||
Currently we have {cpu_dma_latency, network_latency, network_throughput} as the
|
||||
initial set of pm_qos parameters.
|
||||
|
||||
Each parameters have defined units:
|
||||
* latency: usec
|
||||
* timeout: usec
|
||||
* throughput: kbs (kilo bit / sec)
|
||||
|
||||
The infrastructure exposes multiple misc device nodes one per implemented
|
||||
parameter. The set of parameters implement is defined by pm_qos_power_init()
|
||||
and pm_qos_params.h. This is done because having the available parameters
|
||||
|
|
|
|||
|
|
@ -101,6 +101,10 @@ of charge when battery became full/empty". It also could mean "value of
|
|||
charge when battery considered full/empty at given conditions (temperature,
|
||||
age)". I.e. these attributes represents real thresholds, not design values.
|
||||
|
||||
CHARGE_COUNTER - the current charge counter (in µAh). This could easily
|
||||
be negative; there is no empty or full value. It is only useful for
|
||||
relative, time-based measurements.
|
||||
|
||||
ENERGY_FULL, ENERGY_EMPTY - same as above but for energy.
|
||||
|
||||
CAPACITY - capacity in percents.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,182 @@
|
|||
Regulator Consumer Driver Interface
|
||||
===================================
|
||||
|
||||
This text describes the regulator interface for consumer device drivers.
|
||||
Please see overview.txt for a description of the terms used in this text.
|
||||
|
||||
|
||||
1. Consumer Regulator Access (static & dynamic drivers)
|
||||
=======================================================
|
||||
|
||||
A consumer driver can get access to it's supply regulator by calling :-
|
||||
|
||||
regulator = regulator_get(dev, "Vcc");
|
||||
|
||||
The consumer passes in it's struct device pointer and power supply ID. The core
|
||||
then finds the correct regulator by consulting a machine specific lookup table.
|
||||
If the lookup is successful then this call will return a pointer to the struct
|
||||
regulator that supplies this consumer.
|
||||
|
||||
To release the regulator the consumer driver should call :-
|
||||
|
||||
regulator_put(regulator);
|
||||
|
||||
Consumers can be supplied by more than one regulator e.g. codec consumer with
|
||||
analog and digital supplies :-
|
||||
|
||||
digital = regulator_get(dev, "Vcc"); /* digital core */
|
||||
analog = regulator_get(dev, "Avdd"); /* analog */
|
||||
|
||||
The regulator access functions regulator_get() and regulator_put() will
|
||||
usually be called in your device drivers probe() and remove() respectively.
|
||||
|
||||
|
||||
2. Regulator Output Enable & Disable (static & dynamic drivers)
|
||||
====================================================================
|
||||
|
||||
A consumer can enable it's power supply by calling:-
|
||||
|
||||
int regulator_enable(regulator);
|
||||
|
||||
NOTE: The supply may already be enabled before regulator_enabled() is called.
|
||||
This may happen if the consumer shares the regulator or the regulator has been
|
||||
previously enabled by bootloader or kernel board initialization code.
|
||||
|
||||
A consumer can determine if a regulator is enabled by calling :-
|
||||
|
||||
int regulator_is_enabled(regulator);
|
||||
|
||||
This will return > zero when the regulator is enabled.
|
||||
|
||||
|
||||
A consumer can disable it's supply when no longer needed by calling :-
|
||||
|
||||
int regulator_disable(regulator);
|
||||
|
||||
NOTE: This may not disable the supply if it's shared with other consumers. The
|
||||
regulator will only be disabled when the enabled reference count is zero.
|
||||
|
||||
Finally, a regulator can be forcefully disabled in the case of an emergency :-
|
||||
|
||||
int regulator_force_disable(regulator);
|
||||
|
||||
NOTE: this will immediately and forcefully shutdown the regulator output. All
|
||||
consumers will be powered off.
|
||||
|
||||
|
||||
3. Regulator Voltage Control & Status (dynamic drivers)
|
||||
======================================================
|
||||
|
||||
Some consumer drivers need to be able to dynamically change their supply
|
||||
voltage to match system operating points. e.g. CPUfreq drivers can scale
|
||||
voltage along with frequency to save power, SD drivers may need to select the
|
||||
correct card voltage, etc.
|
||||
|
||||
Consumers can control their supply voltage by calling :-
|
||||
|
||||
int regulator_set_voltage(regulator, min_uV, max_uV);
|
||||
|
||||
Where min_uV and max_uV are the minimum and maximum acceptable voltages in
|
||||
microvolts.
|
||||
|
||||
NOTE: this can be called when the regulator is enabled or disabled. If called
|
||||
when enabled, then the voltage changes instantly, otherwise the voltage
|
||||
configuration changes and the voltage is physically set when the regulator is
|
||||
next enabled.
|
||||
|
||||
The regulators configured voltage output can be found by calling :-
|
||||
|
||||
int regulator_get_voltage(regulator);
|
||||
|
||||
NOTE: get_voltage() will return the configured output voltage whether the
|
||||
regulator is enabled or disabled and should NOT be used to determine regulator
|
||||
output state. However this can be used in conjunction with is_enabled() to
|
||||
determine the regulator physical output voltage.
|
||||
|
||||
|
||||
4. Regulator Current Limit Control & Status (dynamic drivers)
|
||||
===========================================================
|
||||
|
||||
Some consumer drivers need to be able to dynamically change their supply
|
||||
current limit to match system operating points. e.g. LCD backlight driver can
|
||||
change the current limit to vary the backlight brightness, USB drivers may want
|
||||
to set the limit to 500mA when supplying power.
|
||||
|
||||
Consumers can control their supply current limit by calling :-
|
||||
|
||||
int regulator_set_current_limit(regulator, min_uV, max_uV);
|
||||
|
||||
Where min_uA and max_uA are the minimum and maximum acceptable current limit in
|
||||
microamps.
|
||||
|
||||
NOTE: this can be called when the regulator is enabled or disabled. If called
|
||||
when enabled, then the current limit changes instantly, otherwise the current
|
||||
limit configuration changes and the current limit is physically set when the
|
||||
regulator is next enabled.
|
||||
|
||||
A regulators current limit can be found by calling :-
|
||||
|
||||
int regulator_get_current_limit(regulator);
|
||||
|
||||
NOTE: get_current_limit() will return the current limit whether the regulator
|
||||
is enabled or disabled and should not be used to determine regulator current
|
||||
load.
|
||||
|
||||
|
||||
5. Regulator Operating Mode Control & Status (dynamic drivers)
|
||||
=============================================================
|
||||
|
||||
Some consumers can further save system power by changing the operating mode of
|
||||
their supply regulator to be more efficient when the consumers operating state
|
||||
changes. e.g. consumer driver is idle and subsequently draws less current
|
||||
|
||||
Regulator operating mode can be changed indirectly or directly.
|
||||
|
||||
Indirect operating mode control.
|
||||
--------------------------------
|
||||
Consumer drivers can request a change in their supply regulator operating mode
|
||||
by calling :-
|
||||
|
||||
int regulator_set_optimum_mode(struct regulator *regulator, int load_uA);
|
||||
|
||||
This will cause the core to recalculate the total load on the regulator (based
|
||||
on all it's consumers) and change operating mode (if necessary and permitted)
|
||||
to best match the current operating load.
|
||||
|
||||
The load_uA value can be determined from the consumers datasheet. e.g.most
|
||||
datasheets have tables showing the max current consumed in certain situations.
|
||||
|
||||
Most consumers will use indirect operating mode control since they have no
|
||||
knowledge of the regulator or whether the regulator is shared with other
|
||||
consumers.
|
||||
|
||||
Direct operating mode control.
|
||||
------------------------------
|
||||
Bespoke or tightly coupled drivers may want to directly control regulator
|
||||
operating mode depending on their operating point. This can be achieved by
|
||||
calling :-
|
||||
|
||||
int regulator_set_mode(struct regulator *regulator, unsigned int mode);
|
||||
unsigned int regulator_get_mode(struct regulator *regulator);
|
||||
|
||||
Direct mode will only be used by consumers that *know* about the regulator and
|
||||
are not sharing the regulator with other consumers.
|
||||
|
||||
|
||||
6. Regulator Events
|
||||
===================
|
||||
Regulators can notify consumers of external events. Events could be received by
|
||||
consumers under regulator stress or failure conditions.
|
||||
|
||||
Consumers can register interest in regulator events by calling :-
|
||||
|
||||
int regulator_register_notifier(struct regulator *regulator,
|
||||
struct notifier_block *nb);
|
||||
|
||||
Consumers can uregister interest by calling :-
|
||||
|
||||
int regulator_unregister_notifier(struct regulator *regulator,
|
||||
struct notifier_block *nb);
|
||||
|
||||
Regulators use the kernel notifier framework to send event to thier interested
|
||||
consumers.
|
||||
|
|
@ -0,0 +1,101 @@
|
|||
Regulator Machine Driver Interface
|
||||
===================================
|
||||
|
||||
The regulator machine driver interface is intended for board/machine specific
|
||||
initialisation code to configure the regulator subsystem. Typical things that
|
||||
machine drivers would do are :-
|
||||
|
||||
1. Regulator -> Device mapping.
|
||||
2. Regulator supply configuration.
|
||||
3. Power Domain constraint setting.
|
||||
|
||||
|
||||
|
||||
1. Regulator -> device mapping
|
||||
==============================
|
||||
Consider the following machine :-
|
||||
|
||||
Regulator-1 -+-> Regulator-2 --> [Consumer A @ 1.8 - 2.0V]
|
||||
|
|
||||
+-> [Consumer B @ 3.3V]
|
||||
|
||||
The drivers for consumers A & B must be mapped to the correct regulator in
|
||||
order to control their power supply. This mapping can be achieved in machine
|
||||
initialisation code by calling :-
|
||||
|
||||
int regulator_set_device_supply(const char *regulator, struct device *dev,
|
||||
const char *supply);
|
||||
|
||||
and is shown with the following code :-
|
||||
|
||||
regulator_set_device_supply("Regulator-1", devB, "Vcc");
|
||||
regulator_set_device_supply("Regulator-2", devA, "Vcc");
|
||||
|
||||
This maps Regulator-1 to the 'Vcc' supply for Consumer B and maps Regulator-2
|
||||
to the 'Vcc' supply for Consumer A.
|
||||
|
||||
|
||||
2. Regulator supply configuration.
|
||||
==================================
|
||||
Consider the following machine (again) :-
|
||||
|
||||
Regulator-1 -+-> Regulator-2 --> [Consumer A @ 1.8 - 2.0V]
|
||||
|
|
||||
+-> [Consumer B @ 3.3V]
|
||||
|
||||
Regulator-1 supplies power to Regulator-2. This relationship must be registered
|
||||
with the core so that Regulator-1 is also enabled when Consumer A enables it's
|
||||
supply (Regulator-2).
|
||||
|
||||
This relationship can be register with the core via :-
|
||||
|
||||
int regulator_set_supply(const char *regulator, const char *regulator_supply);
|
||||
|
||||
In this example we would use the following code :-
|
||||
|
||||
regulator_set_supply("Regulator-2", "Regulator-1");
|
||||
|
||||
Relationships can be queried by calling :-
|
||||
|
||||
const char *regulator_get_supply(const char *regulator);
|
||||
|
||||
|
||||
3. Power Domain constraint setting.
|
||||
===================================
|
||||
Each power domain within a system has physical constraints on voltage and
|
||||
current. This must be defined in software so that the power domain is always
|
||||
operated within specifications.
|
||||
|
||||
Consider the following machine (again) :-
|
||||
|
||||
Regulator-1 -+-> Regulator-2 --> [Consumer A @ 1.8 - 2.0V]
|
||||
|
|
||||
+-> [Consumer B @ 3.3V]
|
||||
|
||||
This gives us two regulators and two power domains:
|
||||
|
||||
Domain 1: Regulator-2, Consumer B.
|
||||
Domain 2: Consumer A.
|
||||
|
||||
Constraints can be registered by calling :-
|
||||
|
||||
int regulator_set_platform_constraints(const char *regulator,
|
||||
struct regulation_constraints *constraints);
|
||||
|
||||
The example is defined as follows :-
|
||||
|
||||
struct regulation_constraints domain_1 = {
|
||||
.min_uV = 3300000,
|
||||
.max_uV = 3300000,
|
||||
.valid_modes_mask = REGULATOR_MODE_NORMAL,
|
||||
};
|
||||
|
||||
struct regulation_constraints domain_2 = {
|
||||
.min_uV = 1800000,
|
||||
.max_uV = 2000000,
|
||||
.valid_ops_mask = REGULATOR_CHANGE_VOLTAGE,
|
||||
.valid_modes_mask = REGULATOR_MODE_NORMAL,
|
||||
};
|
||||
|
||||
regulator_set_platform_constraints("Regulator-1", &domain_1);
|
||||
regulator_set_platform_constraints("Regulator-2", &domain_2);
|
||||
|
|
@ -0,0 +1,171 @@
|
|||
Linux voltage and current regulator framework
|
||||
=============================================
|
||||
|
||||
About
|
||||
=====
|
||||
|
||||
This framework is designed to provide a standard kernel interface to control
|
||||
voltage and current regulators.
|
||||
|
||||
The intention is to allow systems to dynamically control regulator power output
|
||||
in order to save power and prolong battery life. This applies to both voltage
|
||||
regulators (where voltage output is controllable) and current sinks (where
|
||||
current limit is controllable).
|
||||
|
||||
(C) 2008 Wolfson Microelectronics PLC.
|
||||
Author: Liam Girdwood <lg@opensource.wolfsonmicro.com>
|
||||
|
||||
|
||||
Nomenclature
|
||||
============
|
||||
|
||||
Some terms used in this document:-
|
||||
|
||||
o Regulator - Electronic device that supplies power to other devices.
|
||||
Most regulators can enable and disable their output whilst
|
||||
some can control their output voltage and or current.
|
||||
|
||||
Input Voltage -> Regulator -> Output Voltage
|
||||
|
||||
|
||||
o PMIC - Power Management IC. An IC that contains numerous regulators
|
||||
and often contains other susbsystems.
|
||||
|
||||
|
||||
o Consumer - Electronic device that is supplied power by a regulator.
|
||||
Consumers can be classified into two types:-
|
||||
|
||||
Static: consumer does not change it's supply voltage or
|
||||
current limit. It only needs to enable or disable it's
|
||||
power supply. It's supply voltage is set by the hardware,
|
||||
bootloader, firmware or kernel board initialisation code.
|
||||
|
||||
Dynamic: consumer needs to change it's supply voltage or
|
||||
current limit to meet operation demands.
|
||||
|
||||
|
||||
o Power Domain - Electronic circuit that is supplied it's input power by the
|
||||
output power of a regulator, switch or by another power
|
||||
domain.
|
||||
|
||||
The supply regulator may be behind a switch(s). i.e.
|
||||
|
||||
Regulator -+-> Switch-1 -+-> Switch-2 --> [Consumer A]
|
||||
| |
|
||||
| +-> [Consumer B], [Consumer C]
|
||||
|
|
||||
+-> [Consumer D], [Consumer E]
|
||||
|
||||
That is one regulator and three power domains:
|
||||
|
||||
Domain 1: Switch-1, Consumers D & E.
|
||||
Domain 2: Switch-2, Consumers B & C.
|
||||
Domain 3: Consumer A.
|
||||
|
||||
and this represents a "supplies" relationship:
|
||||
|
||||
Domain-1 --> Domain-2 --> Domain-3.
|
||||
|
||||
A power domain may have regulators that are supplied power
|
||||
by other regulators. i.e.
|
||||
|
||||
Regulator-1 -+-> Regulator-2 -+-> [Consumer A]
|
||||
|
|
||||
+-> [Consumer B]
|
||||
|
||||
This gives us two regulators and two power domains:
|
||||
|
||||
Domain 1: Regulator-2, Consumer B.
|
||||
Domain 2: Consumer A.
|
||||
|
||||
and a "supplies" relationship:
|
||||
|
||||
Domain-1 --> Domain-2
|
||||
|
||||
|
||||
o Constraints - Constraints are used to define power levels for performance
|
||||
and hardware protection. Constraints exist at three levels:
|
||||
|
||||
Regulator Level: This is defined by the regulator hardware
|
||||
operating parameters and is specified in the regulator
|
||||
datasheet. i.e.
|
||||
|
||||
- voltage output is in the range 800mV -> 3500mV.
|
||||
- regulator current output limit is 20mA @ 5V but is
|
||||
10mA @ 10V.
|
||||
|
||||
Power Domain Level: This is defined in software by kernel
|
||||
level board initialisation code. It is used to constrain a
|
||||
power domain to a particular power range. i.e.
|
||||
|
||||
- Domain-1 voltage is 3300mV
|
||||
- Domain-2 voltage is 1400mV -> 1600mV
|
||||
- Domain-3 current limit is 0mA -> 20mA.
|
||||
|
||||
Consumer Level: This is defined by consumer drivers
|
||||
dynamically setting voltage or current limit levels.
|
||||
|
||||
e.g. a consumer backlight driver asks for a current increase
|
||||
from 5mA to 10mA to increase LCD illumination. This passes
|
||||
to through the levels as follows :-
|
||||
|
||||
Consumer: need to increase LCD brightness. Lookup and
|
||||
request next current mA value in brightness table (the
|
||||
consumer driver could be used on several different
|
||||
personalities based upon the same reference device).
|
||||
|
||||
Power Domain: is the new current limit within the domain
|
||||
operating limits for this domain and system state (e.g.
|
||||
battery power, USB power)
|
||||
|
||||
Regulator Domains: is the new current limit within the
|
||||
regulator operating parameters for input/ouput voltage.
|
||||
|
||||
If the regulator request passes all the constraint tests
|
||||
then the new regulator value is applied.
|
||||
|
||||
|
||||
Design
|
||||
======
|
||||
|
||||
The framework is designed and targeted at SoC based devices but may also be
|
||||
relevant to non SoC devices and is split into the following four interfaces:-
|
||||
|
||||
|
||||
1. Consumer driver interface.
|
||||
|
||||
This uses a similar API to the kernel clock interface in that consumer
|
||||
drivers can get and put a regulator (like they can with clocks atm) and
|
||||
get/set voltage, current limit, mode, enable and disable. This should
|
||||
allow consumers complete control over their supply voltage and current
|
||||
limit. This also compiles out if not in use so drivers can be reused in
|
||||
systems with no regulator based power control.
|
||||
|
||||
See Documentation/power/regulator/consumer.txt
|
||||
|
||||
2. Regulator driver interface.
|
||||
|
||||
This allows regulator drivers to register their regulators and provide
|
||||
operations to the core. It also has a notifier call chain for propagating
|
||||
regulator events to clients.
|
||||
|
||||
See Documentation/power/regulator/regulator.txt
|
||||
|
||||
3. Machine interface.
|
||||
|
||||
This interface is for machine specific code and allows the creation of
|
||||
voltage/current domains (with constraints) for each regulator. It can
|
||||
provide regulator constraints that will prevent device damage through
|
||||
overvoltage or over current caused by buggy client drivers. It also
|
||||
allows the creation of a regulator tree whereby some regulators are
|
||||
supplied by others (similar to a clock tree).
|
||||
|
||||
See Documentation/power/regulator/machine.txt
|
||||
|
||||
4. Userspace ABI.
|
||||
|
||||
The framework also exports a lot of useful voltage/current/opmode data to
|
||||
userspace via sysfs. This could be used to help monitor device power
|
||||
consumption and status.
|
||||
|
||||
See Documentation/ABI/testing/regulator-sysfs.txt
|
||||
|
|
@ -0,0 +1,30 @@
|
|||
Regulator Driver Interface
|
||||
==========================
|
||||
|
||||
The regulator driver interface is relatively simple and designed to allow
|
||||
regulator drivers to register their services with the core framework.
|
||||
|
||||
|
||||
Registration
|
||||
============
|
||||
|
||||
Drivers can register a regulator by calling :-
|
||||
|
||||
struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc,
|
||||
void *reg_data);
|
||||
|
||||
This will register the regulators capabilities and operations the regulator
|
||||
core. The core does not touch reg_data (private to regulator driver).
|
||||
|
||||
Regulators can be unregistered by calling :-
|
||||
|
||||
void regulator_unregister(struct regulator_dev *rdev);
|
||||
|
||||
|
||||
Regulator Events
|
||||
================
|
||||
Regulators can send events (e.g. over temp, under voltage, etc) to consumer
|
||||
drivers by calling :-
|
||||
|
||||
int regulator_notifier_call_chain(struct regulator_dev *rdev,
|
||||
unsigned long event, void *data);
|
||||
|
|
@ -20,8 +20,6 @@ mpc52xx-device-tree-bindings.txt
|
|||
- MPC5200 Device Tree Bindings
|
||||
ppc_htab.txt
|
||||
- info about the Linux/PPC /proc/ppc_htab entry
|
||||
SBC8260_memory_mapping.txt
|
||||
- EST SBC8260 board info
|
||||
smp.txt
|
||||
- use and state info about Linux/PPC on MP machines
|
||||
sound.txt
|
||||
|
|
|
|||
|
|
@ -1,197 +0,0 @@
|
|||
Please mail me (Jon Diekema, diekema_jon@si.com or diekema@cideas.com)
|
||||
if you have questions, comments or corrections.
|
||||
|
||||
* EST SBC8260 Linux memory mapping rules
|
||||
|
||||
http://www.estc.com/
|
||||
http://www.estc.com/products/boards/SBC8260-8240_ds.html
|
||||
|
||||
Initial conditions:
|
||||
-------------------
|
||||
|
||||
Tasks that need to be perform by the boot ROM before control is
|
||||
transferred to zImage (compressed Linux kernel):
|
||||
|
||||
- Define the IMMR to 0xf0000000
|
||||
|
||||
- Initialize the memory controller so that RAM is available at
|
||||
physical address 0x00000000. On the SBC8260 is this 16M (64M)
|
||||
SDRAM.
|
||||
|
||||
- The boot ROM should only clear the RAM that it is using.
|
||||
|
||||
The reason for doing this is to enhances the chances of a
|
||||
successful post mortem on a Linux panic. One of the first
|
||||
items to examine is the 16k (LOG_BUF_LEN) circular console
|
||||
buffer called log_buf which is defined in kernel/printk.c.
|
||||
|
||||
- To enhance boot ROM performance, the I-cache can be enabled.
|
||||
|
||||
Date: Mon, 22 May 2000 14:21:10 -0700
|
||||
From: Neil Russell <caret@c-side.com>
|
||||
|
||||
LiMon (LInux MONitor) runs with and starts Linux with MMU
|
||||
off, I-cache enabled, D-cache disabled. The I-cache doesn't
|
||||
need hints from the MMU to work correctly as the D-cache
|
||||
does. No D-cache means no special code to handle devices in
|
||||
the presence of cache (no snooping, etc). The use of the
|
||||
I-cache means that the monitor can run acceptably fast
|
||||
directly from ROM, rather than having to copy it to RAM.
|
||||
|
||||
- Build the board information structure (see
|
||||
include/asm-ppc/est8260.h for its definition)
|
||||
|
||||
- The compressed Linux kernel (zImage) contains a bootstrap loader
|
||||
that is position independent; you can load it into any RAM,
|
||||
ROM or FLASH memory address >= 0x00500000 (above 5 MB), or
|
||||
at its link address of 0x00400000 (4 MB).
|
||||
|
||||
Note: If zImage is loaded at its link address of 0x00400000 (4 MB),
|
||||
then zImage will skip the step of moving itself to
|
||||
its link address.
|
||||
|
||||
- Load R3 with the address of the board information structure
|
||||
|
||||
- Transfer control to zImage
|
||||
|
||||
- The Linux console port is SMC1, and the baud rate is controlled
|
||||
from the bi_baudrate field of the board information structure.
|
||||
On thing to keep in mind when picking the baud rate, is that
|
||||
there is no flow control on the SMC ports. I would stick
|
||||
with something safe and standard like 19200.
|
||||
|
||||
On the EST SBC8260, the SMC1 port is on the COM1 connector of
|
||||
the board.
|
||||
|
||||
|
||||
EST SBC8260 defaults:
|
||||
---------------------
|
||||
|
||||
Chip
|
||||
Memory Sel Bus Use
|
||||
--------------------- --- --- ----------------------------------
|
||||
0x00000000-0x03FFFFFF CS2 60x (16M or 64M)/64M SDRAM
|
||||
0x04000000-0x04FFFFFF CS4 local 4M/16M SDRAM (soldered to the board)
|
||||
0x21000000-0x21000000 CS7 60x 1B/64K Flash present detect (from the flash SIMM)
|
||||
0x21000001-0x21000001 CS7 60x 1B/64K Switches (read) and LEDs (write)
|
||||
0x22000000-0x2200FFFF CS5 60x 8K/64K EEPROM
|
||||
0xFC000000-0xFCFFFFFF CS6 60x 2M/16M flash (8 bits wide, soldered to the board)
|
||||
0xFE000000-0xFFFFFFFF CS0 60x 4M/16M flash (SIMM)
|
||||
|
||||
Notes:
|
||||
------
|
||||
|
||||
- The chip selects can map 32K blocks and up (powers of 2)
|
||||
|
||||
- The SDRAM machine can handled up to 128Mbytes per chip select
|
||||
|
||||
- Linux uses the 60x bus memory (the SDRAM DIMM) for the
|
||||
communications buffers.
|
||||
|
||||
- BATs can map 128K-256Mbytes each. There are four data BATs and
|
||||
four instruction BATs. Generally the data and instruction BATs
|
||||
are mapped the same.
|
||||
|
||||
- The IMMR must be set above the kernel virtual memory addresses,
|
||||
which start at 0xC0000000. Otherwise, the kernel may crash as
|
||||
soon as you start any threads or processes due to VM collisions
|
||||
in the kernel or user process space.
|
||||
|
||||
|
||||
Details from Dan Malek <dan_malek@mvista.com> on 10/29/1999:
|
||||
|
||||
The user application virtual space consumes the first 2 Gbytes
|
||||
(0x00000000 to 0x7FFFFFFF). The kernel virtual text starts at
|
||||
0xC0000000, with data following. There is a "protection hole"
|
||||
between the end of kernel data and the start of the kernel
|
||||
dynamically allocated space, but this space is still within
|
||||
0xCxxxxxxx.
|
||||
|
||||
Obviously the kernel can't map any physical addresses 1:1 in
|
||||
these ranges.
|
||||
|
||||
|
||||
Details from Dan Malek <dan_malek@mvista.com> on 5/19/2000:
|
||||
|
||||
During the early kernel initialization, the kernel virtual
|
||||
memory allocator is not operational. Prior to this KVM
|
||||
initialization, we choose to map virtual to physical addresses
|
||||
1:1. That is, the kernel virtual address exactly matches the
|
||||
physical address on the bus. These mappings are typically done
|
||||
in arch/ppc/kernel/head.S, or arch/ppc/mm/init.c. Only
|
||||
absolutely necessary mappings should be done at this time, for
|
||||
example board control registers or a serial uart. Normal device
|
||||
driver initialization should map resources later when necessary.
|
||||
|
||||
Although platform dependent, and certainly the case for embedded
|
||||
8xx, traditionally memory is mapped at physical address zero,
|
||||
and I/O devices above physical address 0x80000000. The lowest
|
||||
and highest (above 0xf0000000) I/O addresses are traditionally
|
||||
used for devices or registers we need to map during kernel
|
||||
initialization and prior to KVM operation. For this reason,
|
||||
and since it followed prior PowerPC platform examples, I chose
|
||||
to map the embedded 8xx kernel to the 0xc0000000 virtual address.
|
||||
This way, we can enable the MMU to map the kernel for proper
|
||||
operation, and still map a few windows before the KVM is operational.
|
||||
|
||||
On some systems, you could possibly run the kernel at the
|
||||
0x80000000 or any other virtual address. It just depends upon
|
||||
mapping that must be done prior to KVM operational. You can never
|
||||
map devices or kernel spaces that overlap with the user virtual
|
||||
space. This is why default IMMR mapping used by most BDM tools
|
||||
won't work. They put the IMMR at something like 0x10000000 or
|
||||
0x02000000 for example. You simply can't map these addresses early
|
||||
in the kernel, and continue proper system operation.
|
||||
|
||||
The embedded 8xx/82xx kernel is mature enough that all you should
|
||||
need to do is map the IMMR someplace at or above 0xf0000000 and it
|
||||
should boot far enough to get serial console messages and KGDB
|
||||
connected on any platform. There are lots of other subtle memory
|
||||
management design features that you simply don't need to worry
|
||||
about. If you are changing functions related to MMU initialization,
|
||||
you are likely breaking things that are known to work and are
|
||||
heading down a path of disaster and frustration. Your changes
|
||||
should be to make the flexibility of the processor fit Linux,
|
||||
not force arbitrary and non-workable memory mappings into Linux.
|
||||
|
||||
- You don't want to change KERNELLOAD or KERNELBASE, otherwise the
|
||||
virtual memory and MMU code will get confused.
|
||||
|
||||
arch/ppc/Makefile:KERNELLOAD = 0xc0000000
|
||||
|
||||
include/asm-ppc/page.h:#define PAGE_OFFSET 0xc0000000
|
||||
include/asm-ppc/page.h:#define KERNELBASE PAGE_OFFSET
|
||||
|
||||
- RAM is at physical address 0x00000000, and gets mapped to
|
||||
virtual address 0xC0000000 for the kernel.
|
||||
|
||||
|
||||
Physical addresses used by the Linux kernel:
|
||||
--------------------------------------------
|
||||
|
||||
0x00000000-0x3FFFFFFF 1GB reserved for RAM
|
||||
0xF0000000-0xF001FFFF 128K IMMR 64K used for dual port memory,
|
||||
64K for 8260 registers
|
||||
|
||||
|
||||
Logical addresses used by the Linux kernel:
|
||||
-------------------------------------------
|
||||
|
||||
0xF0000000-0xFFFFFFFF 256M BAT0 (IMMR: dual port RAM, registers)
|
||||
0xE0000000-0xEFFFFFFF 256M BAT1 (I/O space for custom boards)
|
||||
0xC0000000-0xCFFFFFFF 256M BAT2 (RAM)
|
||||
0xD0000000-0xDFFFFFFF 256M BAT3 (if RAM > 256MByte)
|
||||
|
||||
|
||||
EST SBC8260 Linux mapping:
|
||||
--------------------------
|
||||
|
||||
DBAT0, IBAT0, cache inhibited:
|
||||
|
||||
Chip
|
||||
Memory Sel Use
|
||||
--------------------- --- ---------------------------------
|
||||
0xF0000000-0xF001FFFF n/a IMMR: dual port RAM, registers
|
||||
|
||||
DBAT1, IBAT1, cache inhibited:
|
||||
|
||||
|
|
@ -278,7 +278,7 @@ it with special cases.
|
|||
a 64-bit platform.
|
||||
|
||||
d) request and get assigned a platform number (see PLATFORM_*
|
||||
constants in include/asm-powerpc/processor.h
|
||||
constants in arch/powerpc/include/asm/processor.h
|
||||
|
||||
32-bit embedded kernels:
|
||||
|
||||
|
|
@ -340,7 +340,7 @@ the block to RAM before passing it to the kernel.
|
|||
---------
|
||||
|
||||
The kernel is entered with r3 pointing to an area of memory that is
|
||||
roughly described in include/asm-powerpc/prom.h by the structure
|
||||
roughly described in arch/powerpc/include/asm/prom.h by the structure
|
||||
boot_param_header:
|
||||
|
||||
struct boot_param_header {
|
||||
|
|
@ -708,7 +708,7 @@ device or bus to be described by the device tree.
|
|||
In general, the format of an address for a device is defined by the
|
||||
parent bus type, based on the #address-cells and #size-cells
|
||||
properties. Note that the parent's parent definitions of #address-cells
|
||||
and #size-cells are not inhereted so every node with children must specify
|
||||
and #size-cells are not inherited so every node with children must specify
|
||||
them. The kernel requires the root node to have those properties defining
|
||||
addresses format for devices directly mapped on the processor bus.
|
||||
|
||||
|
|
@ -1777,7 +1777,7 @@ platforms are moved over to use the flattened-device-tree model.
|
|||
|
||||
Xilinx uartlite devices are simple fixed speed serial ports.
|
||||
|
||||
Requred properties:
|
||||
Required properties:
|
||||
- current-speed : Baud rate of uartlite
|
||||
|
||||
v) Xilinx hwicap
|
||||
|
|
@ -1799,7 +1799,7 @@ platforms are moved over to use the flattened-device-tree model.
|
|||
Xilinx UART 16550 devices are very similar to the NS16550 but with
|
||||
different register spacing and an offset from the base address.
|
||||
|
||||
Requred properties:
|
||||
Required properties:
|
||||
- clock-frequency : Frequency of the clock input
|
||||
- reg-offset : A value of 3 is required
|
||||
- reg-shift : A value of 2 is required
|
||||
|
|
@ -1953,7 +1953,7 @@ prefixed with the string "marvell,", for Marvell Technology Group Ltd.
|
|||
1) The /system-controller node
|
||||
|
||||
This node is used to represent the system-controller and must be
|
||||
present when the system uses a system contller chip. The top-level
|
||||
present when the system uses a system controller chip. The top-level
|
||||
system-controller node contains information that is global to all
|
||||
devices within the system controller chip. The node name begins
|
||||
with "system-controller" followed by the unit address, which is
|
||||
|
|
|
|||
|
|
@ -7,6 +7,15 @@ Currently defined compatibles:
|
|||
- fsl,cpm2-scc-uart
|
||||
- fsl,qe-uart
|
||||
|
||||
Modem control lines connected to GPIO controllers are listed in the gpios
|
||||
property as described in booting-without-of.txt, section IX.1 in the following
|
||||
order:
|
||||
|
||||
CTS, RTS, DCD, DSR, DTR, and RI.
|
||||
|
||||
The gpios property is optional and can be left out when control lines are
|
||||
not used.
|
||||
|
||||
Example:
|
||||
|
||||
serial@11a00 {
|
||||
|
|
@ -18,4 +27,6 @@ Example:
|
|||
interrupt-parent = <&PIC>;
|
||||
fsl,cpm-brg = <1>;
|
||||
fsl,cpm-command = <00800000>;
|
||||
gpios = <&gpio_c 15 0
|
||||
&gpio_d 29 0>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -133,7 +133,7 @@ error. Given an arbitrary address, the routine
|
|||
pci_get_device_by_addr() will find the pci device associated
|
||||
with that address (if any).
|
||||
|
||||
The default include/asm-powerpc/io.h macros readb(), inb(), insb(),
|
||||
The default arch/powerpc/include/asm/io.h macros readb(), inb(), insb(),
|
||||
etc. include a check to see if the i/o read returned all-0xff's.
|
||||
If so, these make a call to eeh_dn_check_failure(), which in turn
|
||||
asks the firmware if the all-ff's value is the sign of a true EEH
|
||||
|
|
|
|||
|
|
@ -217,7 +217,7 @@ Although it is not recommended, you can specify '0' in the soc.model
|
|||
field to skip matching SOCs altogether.
|
||||
|
||||
The 'model' field is a 16-bit number that matches the actual SOC. The
|
||||
'major' and 'minor' fields are the major and minor revision numbrs,
|
||||
'major' and 'minor' fields are the major and minor revision numbers,
|
||||
respectively, of the SOC.
|
||||
|
||||
For example, to match the 8323, revision 1.0:
|
||||
|
|
|
|||
|
|
@ -390,9 +390,10 @@ rfkill lines are inactive, it must return RFKILL_STATE_SOFT_BLOCKED if its soft
|
|||
rfkill input line is active. Only if none of the rfkill input lines are
|
||||
active, will it return RFKILL_STATE_UNBLOCKED.
|
||||
|
||||
If it doesn't implement the get_state() hook, it must make sure that its calls
|
||||
to rfkill_force_state() are enough to keep the status always up-to-date, and it
|
||||
must do a rfkill_force_state() on resume from sleep.
|
||||
Since the device has a hardware rfkill line, it IS subject to state changes
|
||||
external to rfkill. Therefore, the driver must make sure that it calls
|
||||
rfkill_force_state() to keep the status always up-to-date, and it must do a
|
||||
rfkill_force_state() on resume from sleep.
|
||||
|
||||
Every time the driver gets a notification from the card that one of its rfkill
|
||||
lines changed state (polling might be needed on badly designed cards that don't
|
||||
|
|
@ -422,13 +423,24 @@ of the hardware is unknown), or read-write (where the hardware can be queried
|
|||
about its current state).
|
||||
|
||||
The rfkill class will call the get_state hook of a device every time it needs
|
||||
to know the *real* current state of the hardware. This can happen often.
|
||||
to know the *real* current state of the hardware. This can happen often, but
|
||||
it does not do any polling, so it is not enough on hardware that is subject
|
||||
to state changes outside of the rfkill subsystem.
|
||||
|
||||
Therefore, calling rfkill_force_state() when a state change happens is
|
||||
mandatory when the device has a hardware rfkill line, or when something else
|
||||
like the firmware could cause its state to be changed without going through the
|
||||
rfkill class.
|
||||
|
||||
Some hardware provides events when its status changes. In these cases, it is
|
||||
best for the driver to not provide a get_state hook, and instead register the
|
||||
rfkill class *already* with the correct status, and keep it updated using
|
||||
rfkill_force_state() when it gets an event from the hardware.
|
||||
|
||||
rfkill_force_state() must be used on the device resume handlers to update the
|
||||
rfkill status, should there be any chance of the device status changing during
|
||||
the sleep.
|
||||
|
||||
There is no provision for a statically-allocated rfkill struct. You must
|
||||
use rfkill_allocate() to allocate one.
|
||||
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ device 4711 via subchannel 1 in subchannel set 0, and subchannel 2 is a non-I/O
|
|||
subchannel. Device 1234 is accessed via subchannel 0 in subchannel set 1.
|
||||
|
||||
The subchannel named 'defunct' does not represent any real subchannel on the
|
||||
system; it is a pseudo subchannel where disconnnected ccw devices are moved to
|
||||
system; it is a pseudo subchannel where disconnected ccw devices are moved to
|
||||
if they are displaced by another ccw device becoming operational on their
|
||||
former subchannel. The ccw devices will be moved again to a proper subchannel
|
||||
if they become operational again on that subchannel.
|
||||
|
|
|
|||
|
|
@ -524,7 +524,7 @@
|
|||
- Michael Lang
|
||||
|
||||
June 25 1997: (v1.8b)
|
||||
1) Some cosmetical changes for the handling of SCSI-device-types.
|
||||
1) Some cosmetic changes for the handling of SCSI-device-types.
|
||||
Now, also CD-Burners / WORMs and SCSI-scanners should work. For
|
||||
MO-drives I have no experience, therefore not yet supported.
|
||||
In logical_devices I changed from different type-variables to one
|
||||
|
|
@ -914,7 +914,7 @@
|
|||
in version 4.0. This was never really necessary, as all troubles were
|
||||
based on non-command related reasons up to now, so bypassing commands
|
||||
did not help to avoid any bugs. It is kept in 3.2X for debugging reasons.
|
||||
5) Dynamical reassignment of ldns was again verified and analyzed to be
|
||||
5) Dynamic reassignment of ldns was again verified and analyzed to be
|
||||
completely inoperational. This is corrected and should work now.
|
||||
6) All commands that get sent to the SCSI adapter were verified and
|
||||
completed in such a way, that they are now completely conform to the
|
||||
|
|
@ -1386,7 +1386,7 @@
|
|||
concerning the Linux-kernel in special, this SCSI-driver comes without any
|
||||
warranty. Its functionality is tested as good as possible on certain
|
||||
machines and combinations of computer hardware, which does not exclude,
|
||||
that dataloss or severe damage of hardware is possible while using this
|
||||
that data loss or severe damage of hardware is possible while using this
|
||||
part of software on some arbitrary computer hardware or in combination
|
||||
with other software packages. It is highly recommended to make backup
|
||||
copies of your data before using this software. Furthermore, personal
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ Cable pull and temporary device Loss:
|
|||
being removed, a switch rebooting, or a device reboot), the driver could
|
||||
hide the disappearance of the device from the midlayer. I/O's issued to
|
||||
the LLDD would simply be queued for a short duration, allowing the device
|
||||
to reappear or link come back alive, with no inadvertant side effects
|
||||
to reappear or link come back alive, with no inadvertent side effects
|
||||
to the system. If the driver did not hide these conditions, i/o would be
|
||||
errored by the driver, the mid-layer would exhaust its retries, and the
|
||||
device would be taken offline. Manual intervention would be required to
|
||||
|
|
|
|||
|
|
@ -65,7 +65,7 @@ Overview:
|
|||
discussion will concentrate on NPIV.
|
||||
|
||||
Note: World Wide Name assignment (and uniqueness guarantees) are left
|
||||
up to an administrative entity controling the vport. For example,
|
||||
up to an administrative entity controlling the vport. For example,
|
||||
if vports are to be associated with virtual machines, a XEN mgmt
|
||||
utility would be responsible for creating wwpn/wwnn's for the vport,
|
||||
using it's own naming authority and OUI. (Note: it already does this
|
||||
|
|
@ -91,7 +91,7 @@ Device Trees and Vport Objects:
|
|||
Here's what to expect in the device tree :
|
||||
The typical Physical Port's Scsi_Host:
|
||||
/sys/devices/.../host17/
|
||||
and it has the typical decendent tree:
|
||||
and it has the typical descendant tree:
|
||||
/sys/devices/.../host17/rport-17:0-0/target17:0:0/17:0:0:0:
|
||||
and then the vport is created on the Physical Port:
|
||||
/sys/devices/.../host17/vport-17:0-0
|
||||
|
|
@ -192,7 +192,7 @@ Vport States:
|
|||
independent of the adapter's link state.
|
||||
- Instantiation of the vport on the FC link via ELS traffic, etc.
|
||||
This is equivalent to a "link up" and successfull link initialization.
|
||||
Futher information can be found in the interfaces section below for
|
||||
Further information can be found in the interfaces section below for
|
||||
Vport Creation.
|
||||
|
||||
Once a vport has been instantiated with the kernel/LLDD, a vport state
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ means no changes to adjanced clock
|
|||
Internally, the clk_set_rate_ex forwards request to clk->ops->set_rate method,
|
||||
if it is present in ops structure. The method should set the clock rate and adjust
|
||||
all needed clocks according to the passed algo_id.
|
||||
Exact values for algo_id are machine-dependend. For the sh7722, the following
|
||||
Exact values for algo_id are machine-dependent. For the sh7722, the following
|
||||
values are defined:
|
||||
|
||||
NO_CHANGE = 0,
|
||||
|
|
|
|||
|
|
@ -1024,6 +1024,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
|||
intel-mac-v3 Intel Mac Type 3
|
||||
intel-mac-v4 Intel Mac Type 4
|
||||
intel-mac-v5 Intel Mac Type 5
|
||||
intel-mac-auto Intel Mac (detect type according to subsystem id)
|
||||
macmini Intel Mac Mini (equivalent with type 3)
|
||||
macbook Intel Mac Book (eq. type 5)
|
||||
macbook-pro-v1 Intel Mac Book Pro 1st generation (eq. type 3)
|
||||
|
|
|
|||
|
|
@ -236,15 +236,15 @@ The parameter can be given:
|
|||
alias snd-card-1 snd-usb-audio
|
||||
options snd-usb-audio index=1 device_setup=0x09
|
||||
|
||||
CAUTION when initializaing the device
|
||||
CAUTION when initializing the device
|
||||
-------------------------------------
|
||||
|
||||
* Correct initialization on the device requires that device_setup is given to
|
||||
the module BEFORE the device is turned on. So, if you use the "manual probing"
|
||||
method described above, take care to power-on the device AFTER this initialization.
|
||||
|
||||
* Failing to respect this will lead in a misconfiguration of the device. In this case
|
||||
turn off the device, unproble the snd-usb-audio module, then probe it again with
|
||||
* Failing to respect this will lead to a misconfiguration of the device. In this case
|
||||
turn off the device, unprobe the snd-usb-audio module, then probe it again with
|
||||
correct device_setup parameter and then (and only then) turn on the device again.
|
||||
|
||||
* If you've correctly initialized the device in a valid mode and then want to switch
|
||||
|
|
@ -388,9 +388,9 @@ There are 2 main potential issues when using Jackd with the device:
|
|||
|
||||
Jack supports big endian devices only in recent versions (thanks to
|
||||
Andreas Steinmetz for his first big-endian patch). I can't remember
|
||||
extacly when this support was released into jackd, let's just say that
|
||||
exactly when this support was released into jackd, let's just say that
|
||||
with jackd version 0.103.0 it's almost ok (just a small bug is affecting
|
||||
16bits Big-Endian devices, but since you've read carefully the above
|
||||
16bits Big-Endian devices, but since you've read carefully the above
|
||||
paragraphs, you're now using kernel >= 2.6.23 and your 16bits devices
|
||||
are now Little Endians ;-) ).
|
||||
|
||||
|
|
|
|||
|
|
@ -67,7 +67,7 @@ CONFIG_SND_HDA_POWER_SAVE kconfig. It's called when the codec needs
|
|||
to power up or may power down. The controller should check the all
|
||||
belonging codecs on the bus whether they are actually powered off
|
||||
(check codec->power_on), and optionally the driver may power down the
|
||||
contoller side, too.
|
||||
controller side, too.
|
||||
|
||||
The bus instance is created via snd_hda_bus_new(). You need to pass
|
||||
the card instance, the template, and the pointer to store the
|
||||
|
|
|
|||
|
|
@ -68,7 +68,7 @@ Audio DAPM widgets fall into a number of types:-
|
|||
(Widgets are defined in include/sound/soc-dapm.h)
|
||||
|
||||
Widgets are usually added in the codec driver and the machine driver. There are
|
||||
convience macros defined in soc-dapm.h that can be used to quickly build a
|
||||
convenience macros defined in soc-dapm.h that can be used to quickly build a
|
||||
list of widgets of the codecs and machines DAPM widgets.
|
||||
|
||||
Most widgets have a name, register, shift and invert. Some widgets have extra
|
||||
|
|
|
|||
|
|
@ -73,10 +73,10 @@ recompiled, or use "make C=2" to run sparse on the files whether they need to
|
|||
be recompiled or not. The latter is a fast way to check the whole tree if you
|
||||
have already built it.
|
||||
|
||||
The optional make variable CHECKFLAGS can be used to pass arguments to sparse.
|
||||
The build system passes -Wbitwise to sparse automatically. To perform
|
||||
endianness checks, you may define __CHECK_ENDIAN__:
|
||||
The optional make variable CF can be used to pass arguments to sparse. The
|
||||
build system passes -Wbitwise to sparse automatically. To perform endianness
|
||||
checks, you may define __CHECK_ENDIAN__:
|
||||
|
||||
make C=2 CHECKFLAGS="-D__CHECK_ENDIAN__"
|
||||
make C=2 CF="-D__CHECK_ENDIAN__"
|
||||
|
||||
These checks are disabled by default as they generate a host of warnings.
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ Declaring PXA2xx Master Controllers
|
|||
-----------------------------------
|
||||
Typically a SPI master is defined in the arch/.../mach-*/board-*.c as a
|
||||
"platform device". The master configuration is passed to the driver via a table
|
||||
found in include/asm-arm/arch-pxa/pxa2xx_spi.h:
|
||||
found in arch/arm/mach-pxa/include/mach/pxa2xx_spi.h:
|
||||
|
||||
struct pxa2xx_spi_master {
|
||||
enum pxa_ssp_type ssp_type;
|
||||
|
|
@ -94,7 +94,7 @@ using the "spi_board_info" structure found in "linux/spi/spi.h". See
|
|||
|
||||
Each slave device attached to the PXA must provide slave specific configuration
|
||||
information via the structure "pxa2xx_spi_chip" found in
|
||||
"include/asm-arm/arch-pxa/pxa2xx_spi.h". The pxa2xx_spi master controller driver
|
||||
"arch/arm/mach-pxa/include/mach/pxa2xx_spi.h". The pxa2xx_spi master controller driver
|
||||
will uses the configuration whenever the driver communicates with the slave
|
||||
device.
|
||||
|
||||
|
|
|
|||
|
|
@ -210,7 +210,7 @@ board should normally be set up and registered.
|
|||
|
||||
So for example arch/.../mach-*/board-*.c files might have code like:
|
||||
|
||||
#include <asm/arch/spi.h> /* for mysoc_spi_data */
|
||||
#include <mach/spi.h> /* for mysoc_spi_data */
|
||||
|
||||
/* if your mach-* infrastructure doesn't support kernels that can
|
||||
* run on multiple boards, pdata wouldn't benefit from "__init".
|
||||
|
|
@ -227,7 +227,7 @@ So for example arch/.../mach-*/board-*.c files might have code like:
|
|||
|
||||
And SOC-specific utility code might look something like:
|
||||
|
||||
#include <asm/arch/spi.h>
|
||||
#include <mach/spi.h>
|
||||
|
||||
static struct platform_device spi2 = { ... };
|
||||
|
||||
|
|
|
|||
|
|
@ -116,7 +116,7 @@ of kilobytes free. The VM uses this number to compute a pages_min
|
|||
value for each lowmem zone in the system. Each lowmem zone gets
|
||||
a number of reserved free pages based proportionally on its size.
|
||||
|
||||
Some minimal ammount of memory is needed to satisfy PF_MEMALLOC
|
||||
Some minimal amount of memory is needed to satisfy PF_MEMALLOC
|
||||
allocations; if you set this to lower than 1024KB, your system will
|
||||
become subtly broken, and prone to deadlock under high loads.
|
||||
|
||||
|
|
|
|||
|
|
@ -125,7 +125,7 @@ increase of flexibility and the avoidance of duplicated code across
|
|||
architectures justifies the slight increase of the binary size.
|
||||
|
||||
The conversion of an architecture has no functional impact, but allows to
|
||||
utilize the high resolution and dynamic tick functionalites without any change
|
||||
utilize the high resolution and dynamic tick functionalities without any change
|
||||
to the clock event device and timer interrupt code. After the conversion the
|
||||
enabling of high resolution timers and dynamic ticks is simply provided by
|
||||
adding the kernel/time/Kconfig file to the architecture specific Kconfig and
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ not) in a system. This feature will allow you to implement a lock-down
|
|||
of USB devices, fully controlled by user space.
|
||||
|
||||
As of now, when a USB device is connected it is configured and
|
||||
it's interfaces inmediately made available to the users. With this
|
||||
its interfaces are immediately made available to the users. With this
|
||||
modification, only if root authorizes the device to be configured will
|
||||
then it be possible to use it.
|
||||
|
||||
|
|
|
|||
|
|
@ -2,3 +2,4 @@
|
|||
1 -> Hauppauge HVR950Q (au0828) [2040:7200,2040:7210,2040:7217,2040:721b,2040:721f,2040:7280,0fd9:0008]
|
||||
2 -> Hauppauge HVR850 (au0828) [2040:7240]
|
||||
3 -> DViCO FusionHDTV USB (au0828) [0fe9:d620]
|
||||
4 -> Hauppauge HVR950Q rev xxF8 (au0828) [2040:7201,2040:7211,2040:7281]
|
||||
|
|
|
|||
|
|
@ -1,11 +1,11 @@
|
|||
0 -> Unknown EM2800 video grabber (em2800) [eb1a:2800]
|
||||
1 -> Unknown EM2750/28xx video grabber (em2820/em2840) [eb1a:2750,eb1a:2820,eb1a:2821,eb1a:2860,eb1a:2861,eb1a:2870,eb1a:2881,eb1a:2883]
|
||||
1 -> Unknown EM2750/28xx video grabber (em2820/em2840) [eb1a:2820,eb1a:2821,eb1a:2860,eb1a:2861,eb1a:2870,eb1a:2881,eb1a:2883]
|
||||
2 -> Terratec Cinergy 250 USB (em2820/em2840) [0ccd:0036]
|
||||
3 -> Pinnacle PCTV USB 2 (em2820/em2840) [2304:0208]
|
||||
4 -> Hauppauge WinTV USB 2 (em2820/em2840) [2040:4200,2040:4201]
|
||||
5 -> MSI VOX USB 2.0 (em2820/em2840)
|
||||
6 -> Terratec Cinergy 200 USB (em2800)
|
||||
7 -> Leadtek Winfast USB II (em2800)
|
||||
7 -> Leadtek Winfast USB II (em2800) [0413:6023]
|
||||
8 -> Kworld USB2800 (em2800)
|
||||
9 -> Pinnacle Dazzle DVC 90/DVC 100 (em2820/em2840) [2304:0207,2304:021a]
|
||||
10 -> Hauppauge WinTV HVR 900 (em2880) [2040:6500]
|
||||
|
|
@ -14,7 +14,46 @@
|
|||
13 -> Terratec Prodigy XS (em2880) [0ccd:0047]
|
||||
14 -> Pixelview Prolink PlayTV USB 2.0 (em2820/em2840)
|
||||
15 -> V-Gear PocketTV (em2800)
|
||||
16 -> Hauppauge WinTV HVR 950 (em2880) [2040:6513,2040:6517,2040:651b,2040:651f]
|
||||
16 -> Hauppauge WinTV HVR 950 (em2883) [2040:6513,2040:6517,2040:651b,2040:651f]
|
||||
17 -> Pinnacle PCTV HD Pro Stick (em2880) [2304:0227]
|
||||
18 -> Hauppauge WinTV HVR 900 (R2) (em2880) [2040:6502]
|
||||
19 -> PointNix Intra-Oral Camera (em2860)
|
||||
20 -> AMD ATI TV Wonder HD 600 (em2880) [0438:b002]
|
||||
21 -> eMPIA Technology, Inc. GrabBeeX+ Video Encoder (em2800) [eb1a:2801]
|
||||
22 -> Unknown EM2750/EM2751 webcam grabber (em2750) [eb1a:2750,eb1a:2751]
|
||||
23 -> Huaqi DLCW-130 (em2750)
|
||||
24 -> D-Link DUB-T210 TV Tuner (em2820/em2840) [2001:f112]
|
||||
25 -> Gadmei UTV310 (em2820/em2840)
|
||||
26 -> Hercules Smart TV USB 2.0 (em2820/em2840)
|
||||
27 -> Pinnacle PCTV USB 2 (Philips FM1216ME) (em2820/em2840)
|
||||
28 -> Leadtek Winfast USB II Deluxe (em2820/em2840)
|
||||
29 -> Pinnacle Dazzle DVC 100 (em2820/em2840)
|
||||
30 -> Videology 20K14XUSB USB2.0 (em2820/em2840)
|
||||
31 -> Usbgear VD204v9 (em2821)
|
||||
32 -> Supercomp USB 2.0 TV (em2821)
|
||||
33 -> SIIG AVTuner-PVR/Prolink PlayTV USB 2.0 (em2821)
|
||||
34 -> Terratec Cinergy A Hybrid XS (em2860) [0ccd:004f]
|
||||
35 -> Typhoon DVD Maker (em2860)
|
||||
36 -> NetGMBH Cam (em2860)
|
||||
37 -> Gadmei UTV330 (em2860)
|
||||
38 -> Yakumo MovieMixer (em2861)
|
||||
39 -> KWorld PVRTV 300U (em2861) [eb1a:e300]
|
||||
40 -> Plextor ConvertX PX-TV100U (em2861) [093b:a005]
|
||||
41 -> Kworld 350 U DVB-T (em2870) [eb1a:e350]
|
||||
42 -> Kworld 355 U DVB-T (em2870) [eb1a:e355,eb1a:e357]
|
||||
43 -> Terratec Cinergy T XS (em2870) [0ccd:0043]
|
||||
44 -> Terratec Cinergy T XS (MT2060) (em2870)
|
||||
45 -> Pinnacle PCTV DVB-T (em2870)
|
||||
46 -> Compro, VideoMate U3 (em2870) [185b:2870]
|
||||
47 -> KWorld DVB-T 305U (em2880) [eb1a:e305]
|
||||
48 -> KWorld DVB-T 310U (em2880)
|
||||
49 -> MSI DigiVox A/D (em2880) [eb1a:e310]
|
||||
50 -> MSI DigiVox A/D II (em2880) [eb1a:e320]
|
||||
51 -> Terratec Hybrid XS Secam (em2880) [0ccd:004c]
|
||||
52 -> DNT DA2 Hybrid (em2881)
|
||||
53 -> Pinnacle Hybrid Pro (em2881)
|
||||
54 -> Kworld VS-DVB-T 323UR (em2882) [eb1a:e323]
|
||||
55 -> Terratec Hybrid XS (em2882) (em2882) [0ccd:005e]
|
||||
56 -> Pinnacle Hybrid Pro (2) (em2882) [2304:0226]
|
||||
57 -> Kworld PlusTV HD Hybrid 330 (em2883) [eb1a:a316]
|
||||
58 -> Compro VideoMate ForYou/Stereo (em2820/em2840) [185b:2041]
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
List of the webcams know by gspca.
|
||||
List of the webcams known by gspca.
|
||||
|
||||
The modules are:
|
||||
gspca_main main driver
|
||||
|
|
@ -226,6 +226,7 @@ sonixj 0c45:6130 Sonix Pccam
|
|||
sonixj 0c45:6138 Sn9c120 Mo4000
|
||||
sonixj 0c45:613b Surfer SN-206
|
||||
sonixj 0c45:613c Sonix Pccam168
|
||||
sonixj 0c45:6143 Sonix Pccam168
|
||||
sunplus 0d64:0303 Sunplus FashionCam DXG
|
||||
etoms 102c:6151 Qcam Sangha CIF
|
||||
etoms 102c:6251 Qcam xxxxxx VGA
|
||||
|
|
|
|||
|
|
@ -157,7 +157,7 @@ Loading can be done as shown below:
|
|||
|
||||
[root@localhost home]# modprobe sn9c102
|
||||
|
||||
Note that the module is called "sn9c102" for historic reasons, althought it
|
||||
Note that the module is called "sn9c102" for historic reasons, although it
|
||||
does not just support the SN9C102.
|
||||
|
||||
At this point all the devices supported by the driver and connected to the USB
|
||||
|
|
|
|||
|
|
@ -77,7 +77,7 @@ memory that is preset in system at this time. System administrators may want
|
|||
to put this command in one of the local rc init files. This will enable the
|
||||
kernel to request huge pages early in the boot process (when the possibility
|
||||
of getting physical contiguous pages is still very high). In either
|
||||
case, adminstrators will want to verify the number of hugepages actually
|
||||
case, administrators will want to verify the number of hugepages actually
|
||||
allocated by checking the sysctl or meminfo.
|
||||
|
||||
/proc/sys/vm/nr_overcommit_hugepages indicates how large the pool of
|
||||
|
|
|
|||
|
|
@ -58,7 +58,7 @@ most general to most specific:
|
|||
the policy at the time they were allocated.
|
||||
|
||||
VMA Policy: A "VMA" or "Virtual Memory Area" refers to a range of a task's
|
||||
virtual adddress space. A task may define a specific policy for a range
|
||||
virtual address space. A task may define a specific policy for a range
|
||||
of its virtual address space. See the MEMORY POLICIES APIS section,
|
||||
below, for an overview of the mbind() system call used to set a VMA
|
||||
policy.
|
||||
|
|
@ -353,7 +353,7 @@ follows:
|
|||
|
||||
Because of this extra reference counting, and because we must lookup
|
||||
shared policies in a tree structure under spinlock, shared policies are
|
||||
more expensive to use in the page allocation path. This is expecially
|
||||
more expensive to use in the page allocation path. This is especially
|
||||
true for shared policies on shared memory regions shared by tasks running
|
||||
on different NUMA nodes. This extra overhead can be avoided by always
|
||||
falling back to task or system default policy for shared memory regions,
|
||||
|
|
|
|||
|
|
@ -114,6 +114,6 @@ CREDITS
|
|||
|
||||
Original impetus and research by Randy Dunlap
|
||||
Written by Jonathan Corbet
|
||||
Improvements via coments from Satyam Sharma, Johannes Stezenbach, Jesper
|
||||
Improvements via comments from Satyam Sharma, Johannes Stezenbach, Jesper
|
||||
Juhl, Heikki Orsila, H. Peter Anvin, Philipp Hahn, and Stefan
|
||||
Richter.
|
||||
|
|
|
|||
3
Kbuild
3
Kbuild
|
|
@ -43,7 +43,7 @@ $(obj)/$(bounds-file): kernel/bounds.s Kbuild
|
|||
# 2) Generate asm-offsets.h
|
||||
#
|
||||
|
||||
offsets-file := include/asm-$(SRCARCH)/asm-offsets.h
|
||||
offsets-file := include/asm/asm-offsets.h
|
||||
|
||||
always += $(offsets-file)
|
||||
targets += $(offsets-file)
|
||||
|
|
@ -81,7 +81,6 @@ arch/$(SRCARCH)/kernel/asm-offsets.s: arch/$(SRCARCH)/kernel/asm-offsets.c \
|
|||
$(call if_changed_dep,cc_s_c)
|
||||
|
||||
$(obj)/$(offsets-file): arch/$(SRCARCH)/kernel/asm-offsets.s Kbuild
|
||||
$(Q)mkdir -p $(dir $@)
|
||||
$(call cmd,offsets)
|
||||
|
||||
#####
|
||||
|
|
|
|||
51
MAINTAINERS
51
MAINTAINERS
|
|
@ -502,6 +502,12 @@ L: openezx-devel@lists.openezx.org (subscribers-only)
|
|||
W: http://www.openezx.org/
|
||||
S: Maintained
|
||||
|
||||
ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
|
||||
P: Sascha Hauer
|
||||
M: kernel@pengutronix.de
|
||||
L: linux-arm-kernel@lists.arm.linux.org.uk (subscribers-only)
|
||||
S: Maintained
|
||||
|
||||
ARM/GLOMATION GESBC9312SX MACHINE SUPPORT
|
||||
P: Lennert Buytenhek
|
||||
M: kernel@wantstofly.org
|
||||
|
|
@ -588,6 +594,11 @@ M: kernel@wantstofly.org
|
|||
L: linux-arm-kernel@lists.arm.linux.org.uk (subscribers-only)
|
||||
S: Maintained
|
||||
|
||||
ARM/MAGICIAN MACHINE SUPPORT
|
||||
P: Philipp Zabel
|
||||
M: philipp.zabel@gmail.com
|
||||
S: Maintained
|
||||
|
||||
ARM/TOSA MACHINE SUPPORT
|
||||
P: Dmitry Baryshkov
|
||||
M: dbaryshkov@gmail.com
|
||||
|
|
@ -714,6 +725,15 @@ L: linux-wireless@vger.kernel.org
|
|||
L: ath5k-devel@lists.ath5k.org
|
||||
S: Maintained
|
||||
|
||||
ATHEROS ATH9K WIRELESS DRIVER
|
||||
P: Luis R. Rodriguez
|
||||
M: lrodriguez@atheros.com
|
||||
P: Jouni Malinen
|
||||
M: jmalinen@atheros.com
|
||||
L: linux-wireless@vger.kernel.org
|
||||
L: ath9k-devel@lists.ath9k.org
|
||||
S: Supported
|
||||
|
||||
ATI_REMOTE2 DRIVER
|
||||
P: Ville Syrjala
|
||||
M: syrjala@sci.fi
|
||||
|
|
@ -1229,7 +1249,7 @@ S: Maintained
|
|||
CPU FREQUENCY DRIVERS
|
||||
P: Dave Jones
|
||||
M: davej@codemonkey.org.uk
|
||||
L: cpufreq@lists.linux.org.uk
|
||||
L: cpufreq@vger.kernel.org
|
||||
W: http://www.codemonkey.org.uk/projects/cpufreq/
|
||||
T: git kernel.org/pub/scm/linux/kernel/git/davej/cpufreq.git
|
||||
S: Maintained
|
||||
|
|
@ -1878,13 +1898,9 @@ W: http://gigaset307x.sourceforge.net/
|
|||
S: Maintained
|
||||
|
||||
HARDWARE MONITORING
|
||||
P: Mark M. Hoffman
|
||||
M: mhoffman@lightlink.com
|
||||
L: lm-sensors@lm-sensors.org
|
||||
W: http://www.lm-sensors.org/
|
||||
T: git lm-sensors.org:/kernel/mhoffman/hwmon-2.6.git testing
|
||||
T: git lm-sensors.org:/kernel/mhoffman/hwmon-2.6.git release
|
||||
S: Maintained
|
||||
S: Orphaned
|
||||
|
||||
HARDWARE RANDOM NUMBER GENERATOR CORE
|
||||
S: Orphaned
|
||||
|
|
@ -3123,6 +3139,12 @@ W: http://oss.oracle.com/projects/ocfs2/
|
|||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mfasheh/ocfs2.git
|
||||
S: Supported
|
||||
|
||||
OMFS FILESYSTEM
|
||||
P: Bob Copeland
|
||||
M: me@bobcopeland.com
|
||||
L: linux-karma-devel@lists.sourceforge.net
|
||||
S: Maintained
|
||||
|
||||
OMNIKEY CARDMAN 4000 DRIVER
|
||||
P: Harald Welte
|
||||
M: laforge@gnumonks.org
|
||||
|
|
@ -3790,6 +3812,12 @@ P: Ben Nizette
|
|||
M: bn@niasdigital.com
|
||||
S: Maintained
|
||||
|
||||
SOC-CAMERA V4L2 SUBSYSTEM
|
||||
P: Guennadi Liakhovetski
|
||||
M: g.liakhovetski@gmx.de
|
||||
L: video4linux-list@redhat.com
|
||||
S: Maintained
|
||||
|
||||
SOFTWARE RAID (Multiple Disks) SUPPORT
|
||||
P: Ingo Molnar
|
||||
M: mingo@redhat.com
|
||||
|
|
@ -3956,7 +3984,7 @@ M: lethal@linux-sh.org
|
|||
L: linux-sh@vger.kernel.org
|
||||
W: http://www.linux-sh.org
|
||||
T: git kernel.org:/pub/scm/linux/kernel/git/lethal/sh-2.6.git
|
||||
S: Maintained
|
||||
S: Supported
|
||||
|
||||
SUN3/3X
|
||||
P: Sam Creasey
|
||||
|
|
@ -4492,6 +4520,15 @@ M: kaber@trash.net
|
|||
L: netdev@vger.kernel.org
|
||||
S: Maintained
|
||||
|
||||
VOLTAGE AND CURRENT REGULATOR FRAMEWORK
|
||||
P: Liam Girdwood
|
||||
M: lg@opensource.wolfsonmicro.com
|
||||
P: Mark Brown
|
||||
M: broonie@opensource.wolfsonmicro.com
|
||||
W: http://opensource.wolfsonmicro.com/node/15
|
||||
T: git kernel.org/pub/scm/linux/kernel/git/lrg/voltage-2.6.git
|
||||
S: Supported
|
||||
|
||||
VT1211 HARDWARE MONITOR DRIVER
|
||||
P: Juerg Haefliger
|
||||
M: juergh@gmail.com
|
||||
|
|
|
|||
127
Makefile
127
Makefile
|
|
@ -1,7 +1,7 @@
|
|||
VERSION = 2
|
||||
PATCHLEVEL = 6
|
||||
SUBLEVEL = 26
|
||||
EXTRAVERSION =
|
||||
SUBLEVEL = 27
|
||||
EXTRAVERSION = -rc2
|
||||
NAME = Rotary Wombat
|
||||
|
||||
# *DOCUMENTATION*
|
||||
|
|
@ -205,6 +205,13 @@ ifeq ($(ARCH),x86_64)
|
|||
SRCARCH := x86
|
||||
endif
|
||||
|
||||
# Where to locate arch specific headers
|
||||
ifeq ($(ARCH),sparc64)
|
||||
hdr-arch := sparc
|
||||
else
|
||||
hdr-arch := $(SRCARCH)
|
||||
endif
|
||||
|
||||
KCONFIG_CONFIG ?= .config
|
||||
|
||||
# SHELL used by kbuild
|
||||
|
|
@ -326,7 +333,8 @@ AFLAGS_KERNEL =
|
|||
# Needed to be compatible with the O= option
|
||||
LINUXINCLUDE := -Iinclude \
|
||||
$(if $(KBUILD_SRC),-Iinclude2 -I$(srctree)/include) \
|
||||
-include include/linux/autoconf.h
|
||||
-I$(srctree)/arch/$(hdr-arch)/include \
|
||||
-include include/linux/autoconf.h
|
||||
|
||||
KBUILD_CPPFLAGS := -D__KERNEL__ $(LINUXINCLUDE)
|
||||
|
||||
|
|
@ -921,8 +929,10 @@ ifneq ($(KBUILD_SRC),)
|
|||
echo " in the '$(srctree)' directory.";\
|
||||
/bin/false; \
|
||||
fi;
|
||||
$(Q)if [ ! -d include2 ]; then mkdir -p include2; fi;
|
||||
$(Q)ln -fsn $(srctree)/include/asm-$(SRCARCH) include2/asm
|
||||
$(Q)if [ ! -d include2 ]; then \
|
||||
mkdir -p include2; \
|
||||
ln -fsn $(srctree)/include/asm-$(SRCARCH) include2/asm; \
|
||||
fi
|
||||
endif
|
||||
|
||||
# prepare2 creates a makefile if using a separate output directory
|
||||
|
|
@ -948,22 +958,34 @@ export CPPFLAGS_vmlinux.lds += -P -C -U$(ARCH)
|
|||
|
||||
# The asm symlink changes when $(ARCH) changes.
|
||||
# Detect this and ask user to run make mrproper
|
||||
|
||||
include/asm: FORCE
|
||||
$(Q)set -e; asmlink=`readlink include/asm | cut -d '-' -f 2`; \
|
||||
if [ -L include/asm ]; then \
|
||||
if [ "$$asmlink" != "$(SRCARCH)" ]; then \
|
||||
define check-symlink
|
||||
set -e; \
|
||||
if [ -L include/asm ]; then \
|
||||
asmlink=`readlink include/asm | cut -d '-' -f 2`; \
|
||||
if [ "$$asmlink" != "$(SRCARCH)" ]; then \
|
||||
echo "ERROR: the symlink $@ points to asm-$$asmlink but asm-$(SRCARCH) was expected"; \
|
||||
echo " set ARCH or save .config and run 'make mrproper' to fix it"; \
|
||||
exit 1; \
|
||||
fi; \
|
||||
else \
|
||||
echo ' SYMLINK $@ -> include/asm-$(SRCARCH)'; \
|
||||
if [ ! -d include ]; then \
|
||||
mkdir -p include; \
|
||||
fi; \
|
||||
ln -fsn asm-$(SRCARCH) $@; \
|
||||
exit 1; \
|
||||
fi; \
|
||||
fi
|
||||
endef
|
||||
|
||||
# We create the target directory of the symlink if it does
|
||||
# not exist so the test in chack-symlink works and we have a
|
||||
# directory for generated filesas used by some architectures.
|
||||
define create-symlink
|
||||
if [ ! -L include/asm ]; then \
|
||||
echo ' SYMLINK $@ -> include/asm-$(SRCARCH)'; \
|
||||
if [ ! -d include/asm-$(SRCARCH) ]; then \
|
||||
mkdir -p include/asm-$(SRCARCH); \
|
||||
fi; \
|
||||
ln -fsn asm-$(SRCARCH) $@; \
|
||||
fi
|
||||
endef
|
||||
|
||||
include/asm: FORCE
|
||||
$(Q)$(check-symlink)
|
||||
$(Q)$(create-symlink)
|
||||
|
||||
# Generate some files
|
||||
# ---------------------------------------------------------------------------
|
||||
|
|
@ -1010,36 +1032,43 @@ firmware_install: FORCE
|
|||
|
||||
# ---------------------------------------------------------------------------
|
||||
# Kernel headers
|
||||
INSTALL_HDR_PATH=$(objtree)/usr
|
||||
export INSTALL_HDR_PATH
|
||||
|
||||
HDRFILTER=generic i386 x86_64
|
||||
HDRARCHES=$(filter-out $(HDRFILTER),$(patsubst $(srctree)/include/asm-%/Kbuild,%,$(wildcard $(srctree)/include/asm-*/Kbuild)))
|
||||
#Default location for installed headers
|
||||
export INSTALL_HDR_PATH = $(objtree)/usr
|
||||
|
||||
hdr-inst := -rR -f $(srctree)/scripts/Makefile.headersinst obj
|
||||
# Find out where the Kbuild file is located to support
|
||||
# arch/$(ARCH)/include/asm
|
||||
hdr-dir = $(strip \
|
||||
$(if $(wildcard $(srctree)/arch/$(hdr-arch)/include/asm/Kbuild), \
|
||||
arch/$(hdr-arch)/include/asm, include/asm-$(hdr-arch)))
|
||||
|
||||
# If we do an all arch process set dst to asm-$(hdr-arch)
|
||||
hdr-dst = $(if $(KBUILD_HEADERS), dst=include/asm-$(hdr-arch), dst=include/asm)
|
||||
|
||||
PHONY += __headers
|
||||
__headers: include/linux/version.h scripts_basic FORCE
|
||||
$(Q)$(MAKE) $(build)=scripts scripts/unifdef
|
||||
|
||||
PHONY += headers_install_all
|
||||
headers_install_all: include/linux/version.h scripts_basic FORCE
|
||||
$(Q)$(MAKE) $(build)=scripts scripts/unifdef
|
||||
$(Q)for arch in $(HDRARCHES); do \
|
||||
$(MAKE) ARCH=$$arch -f $(srctree)/scripts/Makefile.headersinst obj=include BIASMDIR=-bi-$$arch ;\
|
||||
done
|
||||
headers_install_all:
|
||||
$(Q)$(CONFIG_SHELL) $(srctree)/scripts/headers.sh install
|
||||
|
||||
PHONY += headers_install
|
||||
headers_install: include/linux/version.h scripts_basic FORCE
|
||||
@if [ ! -r $(srctree)/include/asm-$(SRCARCH)/Kbuild ]; then \
|
||||
echo '*** Error: Headers not exportable for this architecture ($(SRCARCH))'; \
|
||||
exit 1 ; fi
|
||||
$(Q)$(MAKE) $(build)=scripts scripts/unifdef
|
||||
$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.headersinst ARCH=$(SRCARCH) obj=include
|
||||
headers_install: __headers
|
||||
$(if $(wildcard $(srctree)/$(hdr-dir)/Kbuild),, \
|
||||
$(error Headers not exportable for the $(SRCARCH) architecture))
|
||||
$(Q)$(MAKE) $(hdr-inst)=include
|
||||
$(Q)$(MAKE) $(hdr-inst)=$(hdr-dir) $(hdr-dst)
|
||||
|
||||
PHONY += headers_check_all
|
||||
headers_check_all: headers_install_all
|
||||
$(Q)for arch in $(HDRARCHES); do \
|
||||
$(MAKE) ARCH=$$arch -f $(srctree)/scripts/Makefile.headersinst obj=include BIASMDIR=-bi-$$arch HDRCHECK=1 ;\
|
||||
done
|
||||
$(Q)$(CONFIG_SHELL) $(srctree)/scripts/headers.sh check
|
||||
|
||||
PHONY += headers_check
|
||||
headers_check: headers_install
|
||||
$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.headersinst ARCH=$(SRCARCH) obj=include HDRCHECK=1
|
||||
$(Q)$(MAKE) $(hdr-inst)=include HDRCHECK=1
|
||||
$(Q)$(MAKE) $(hdr-inst)=$(hdr-dir) $(hdr-dst) HDRCHECK=1
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# Modules
|
||||
|
|
@ -1131,7 +1160,7 @@ MRPROPER_FILES += .config .config.old include/asm .version .old_version \
|
|||
include/linux/autoconf.h include/linux/version.h \
|
||||
include/linux/utsrelease.h \
|
||||
include/linux/bounds.h include/asm*/asm-offsets.h \
|
||||
Module.symvers tags TAGS cscope*
|
||||
Module.symvers Module.markers tags TAGS cscope*
|
||||
|
||||
# clean - Delete most, but leave enough to build external modules
|
||||
#
|
||||
|
|
@ -1150,7 +1179,7 @@ clean: archclean $(clean-dirs)
|
|||
\( -name '*.[oas]' -o -name '*.ko' -o -name '.*.cmd' \
|
||||
-o -name '.*.d' -o -name '.*.tmp' -o -name '*.mod.c' \
|
||||
-o -name '*.symtypes' -o -name 'modules.order' \
|
||||
-o -name 'Module.markers' \) \
|
||||
-o -name 'Module.markers' -o -name '.tmp_*.o.*' \) \
|
||||
-type f -print | xargs rm -f
|
||||
|
||||
# mrproper - Delete all generated files, including .config
|
||||
|
|
@ -1224,21 +1253,17 @@ help:
|
|||
@echo ' cscope - Generate cscope index'
|
||||
@echo ' kernelrelease - Output the release version string'
|
||||
@echo ' kernelversion - Output the version stored in Makefile'
|
||||
@if [ -r $(srctree)/include/asm-$(SRCARCH)/Kbuild ]; then \
|
||||
echo ' headers_install - Install sanitised kernel headers to INSTALL_HDR_PATH'; \
|
||||
@echo ' headers_install - Install sanitised kernel headers to INSTALL_HDR_PATH'; \
|
||||
echo ' (default: $(INSTALL_HDR_PATH))'; \
|
||||
fi
|
||||
@echo ''
|
||||
echo ''
|
||||
@echo 'Static analysers'
|
||||
@echo ' checkstack - Generate a list of stack hogs'
|
||||
@echo ' namespacecheck - Name space analysis on compiled kernel'
|
||||
@echo ' versioncheck - Sanity check on version.h usage'
|
||||
@echo ' includecheck - Check for duplicate included header files'
|
||||
@echo ' export_report - List the usages of all exported symbols'
|
||||
@if [ -r $(srctree)/include/asm-$(SRCARCH)/Kbuild ]; then \
|
||||
echo ' headers_check - Sanity check on exported headers'; \
|
||||
fi
|
||||
@echo ''
|
||||
@echo ' headers_check - Sanity check on exported headers'; \
|
||||
echo ''
|
||||
@echo 'Kernel packaging:'
|
||||
@$(MAKE) $(build)=$(package-dir) help
|
||||
@echo ''
|
||||
|
|
@ -1411,7 +1436,11 @@ define find-sources
|
|||
\( -name config -o -name 'asm-*' \) -prune \
|
||||
-o -name $1 -print; \
|
||||
for arch in $(ALLINCLUDE_ARCHS) ; do \
|
||||
find $(__srctree)include/asm-$${arch} $(RCS_FIND_IGNORE) \
|
||||
test -e $(__srctree)include/asm-$${arch} && \
|
||||
find $(__srctree)include/asm-$${arch} $(RCS_FIND_IGNORE) \
|
||||
-name $1 -print; \
|
||||
test -e $(__srctree)arch/$${arch}/include/asm && \
|
||||
find $(__srctree)arch/$${arch}/include/asm $(RCS_FIND_IGNORE) \
|
||||
-name $1 -print; \
|
||||
done ; \
|
||||
find $(__srctree)include/asm-generic $(RCS_FIND_IGNORE) \
|
||||
|
|
@ -1463,7 +1492,7 @@ quiet_cmd_cscope-file = FILELST cscope.files
|
|||
cmd_cscope-file = (echo \-k; echo \-q; $(all-sources)) > cscope.files
|
||||
|
||||
quiet_cmd_cscope = MAKE cscope.out
|
||||
cmd_cscope = cscope -b
|
||||
cmd_cscope = cscope -b -f cscope.out
|
||||
|
||||
cscope: FORCE
|
||||
$(call cmd,cscope-file)
|
||||
|
|
|
|||
18
arch/Kconfig
18
arch/Kconfig
|
|
@ -59,6 +59,24 @@ config HAVE_KPROBES
|
|||
config HAVE_KRETPROBES
|
||||
def_bool n
|
||||
|
||||
#
|
||||
# An arch should select this if it provides all these things:
|
||||
#
|
||||
# task_pt_regs() in asm/processor.h or asm/ptrace.h
|
||||
# arch_has_single_step() if there is hardware single-step support
|
||||
# arch_has_block_step() if there is hardware block-step support
|
||||
# arch_ptrace() and not #define __ARCH_SYS_PTRACE
|
||||
# compat_arch_ptrace() and #define __ARCH_WANT_COMPAT_SYS_PTRACE
|
||||
# asm/syscall.h supplying asm-generic/syscall.h interface
|
||||
# linux/regset.h user_regset interfaces
|
||||
# CORE_DUMP_USE_REGSET #define'd in linux/elf.h
|
||||
# TIF_SYSCALL_TRACE calls tracehook_report_syscall_{entry,exit}
|
||||
# TIF_NOTIFY_RESUME calls tracehook_notify_resume()
|
||||
# signal delivery calls tracehook_signal_handler()
|
||||
#
|
||||
config HAVE_ARCH_TRACEHOOK
|
||||
def_bool n
|
||||
|
||||
config HAVE_DMA_ATTRS
|
||||
def_bool n
|
||||
|
||||
|
|
|
|||
|
|
@ -253,15 +253,15 @@ do_osf_statfs(struct dentry * dentry, struct osf_statfs __user *buffer,
|
|||
}
|
||||
|
||||
asmlinkage int
|
||||
osf_statfs(char __user *path, struct osf_statfs __user *buffer, unsigned long bufsiz)
|
||||
osf_statfs(char __user *pathname, struct osf_statfs __user *buffer, unsigned long bufsiz)
|
||||
{
|
||||
struct nameidata nd;
|
||||
struct path path;
|
||||
int retval;
|
||||
|
||||
retval = user_path_walk(path, &nd);
|
||||
retval = user_path(pathname, &path);
|
||||
if (!retval) {
|
||||
retval = do_osf_statfs(nd.path.dentry, buffer, bufsiz);
|
||||
path_put(&nd.path);
|
||||
retval = do_osf_statfs(path.dentry, buffer, bufsiz);
|
||||
path_put(&path);
|
||||
}
|
||||
return retval;
|
||||
}
|
||||
|
|
|
|||
|
|
@ -94,36 +94,6 @@ __bad_page(void)
|
|||
return pte_mkdirty(mk_pte(virt_to_page(EMPTY_PGE), PAGE_SHARED));
|
||||
}
|
||||
|
||||
#ifndef CONFIG_DISCONTIGMEM
|
||||
void
|
||||
show_mem(void)
|
||||
{
|
||||
long i,free = 0,total = 0,reserved = 0;
|
||||
long shared = 0, cached = 0;
|
||||
|
||||
printk("\nMem-info:\n");
|
||||
show_free_areas();
|
||||
printk("Free swap: %6ldkB\n", nr_swap_pages<<(PAGE_SHIFT-10));
|
||||
i = max_mapnr;
|
||||
while (i-- > 0) {
|
||||
total++;
|
||||
if (PageReserved(mem_map+i))
|
||||
reserved++;
|
||||
else if (PageSwapCache(mem_map+i))
|
||||
cached++;
|
||||
else if (!page_count(mem_map+i))
|
||||
free++;
|
||||
else
|
||||
shared += page_count(mem_map + i) - 1;
|
||||
}
|
||||
printk("%ld pages of RAM\n",total);
|
||||
printk("%ld free pages\n",free);
|
||||
printk("%ld reserved pages\n",reserved);
|
||||
printk("%ld pages shared\n",shared);
|
||||
printk("%ld pages swap cached\n",cached);
|
||||
}
|
||||
#endif
|
||||
|
||||
static inline unsigned long
|
||||
load_PCB(struct pcb_struct *pcb)
|
||||
{
|
||||
|
|
|
|||
|
|
@ -359,38 +359,3 @@ void __init mem_init(void)
|
|||
mem_stress();
|
||||
#endif
|
||||
}
|
||||
|
||||
void
|
||||
show_mem(void)
|
||||
{
|
||||
long i,free = 0,total = 0,reserved = 0;
|
||||
long shared = 0, cached = 0;
|
||||
int nid;
|
||||
|
||||
printk("\nMem-info:\n");
|
||||
show_free_areas();
|
||||
printk("Free swap: %6ldkB\n", nr_swap_pages<<(PAGE_SHIFT-10));
|
||||
for_each_online_node(nid) {
|
||||
unsigned long flags;
|
||||
pgdat_resize_lock(NODE_DATA(nid), &flags);
|
||||
i = node_spanned_pages(nid);
|
||||
while (i-- > 0) {
|
||||
struct page *page = nid_page_nr(nid, i);
|
||||
total++;
|
||||
if (PageReserved(page))
|
||||
reserved++;
|
||||
else if (PageSwapCache(page))
|
||||
cached++;
|
||||
else if (!page_count(page))
|
||||
free++;
|
||||
else
|
||||
shared += page_count(page) - 1;
|
||||
}
|
||||
pgdat_resize_unlock(NODE_DATA(nid), &flags);
|
||||
}
|
||||
printk("%ld pages of RAM\n",total);
|
||||
printk("%ld free pages\n",free);
|
||||
printk("%ld reserved pages\n",reserved);
|
||||
printk("%ld pages shared\n",shared);
|
||||
printk("%ld pages swap cached\n",cached);
|
||||
}
|
||||
|
|
|
|||
|
|
@ -17,6 +17,7 @@ config ARM
|
|||
select HAVE_KRETPROBES if (HAVE_KPROBES)
|
||||
select HAVE_FTRACE if (!XIP_KERNEL)
|
||||
select HAVE_DYNAMIC_FTRACE if (HAVE_FTRACE)
|
||||
select HAVE_GENERIC_DMA_COHERENT
|
||||
help
|
||||
The ARM series is a line of low-power-consumption RISC chip designs
|
||||
licensed by ARM Ltd and targeted at embedded applications and
|
||||
|
|
@ -234,6 +235,7 @@ config ARCH_VERSATILE
|
|||
config ARCH_AT91
|
||||
bool "Atmel AT91"
|
||||
select GENERIC_GPIO
|
||||
select HAVE_CLK
|
||||
help
|
||||
This enables support for systems based on the Atmel AT91RM9200,
|
||||
AT91SAM9 and AT91CAP9 processors.
|
||||
|
|
@ -267,7 +269,6 @@ config ARCH_EP93XX
|
|||
select ARM_VIC
|
||||
select GENERIC_GPIO
|
||||
select HAVE_CLK
|
||||
select HAVE_CLK
|
||||
select ARCH_REQUIRE_GPIOLIB
|
||||
help
|
||||
This enables support for the Cirrus EP93xx series of CPUs.
|
||||
|
|
@ -314,7 +315,7 @@ config ARCH_IOP32X
|
|||
select PLAT_IOP
|
||||
select PCI
|
||||
select GENERIC_GPIO
|
||||
select HAVE_GPIO_LIB
|
||||
select ARCH_REQUIRE_GPIOLIB
|
||||
help
|
||||
Support for Intel's 80219 and IOP32X (XScale) family of
|
||||
processors.
|
||||
|
|
@ -325,7 +326,7 @@ config ARCH_IOP33X
|
|||
select PLAT_IOP
|
||||
select PCI
|
||||
select GENERIC_GPIO
|
||||
select HAVE_GPIO_LIB
|
||||
select ARCH_REQUIRE_GPIOLIB
|
||||
help
|
||||
Support for Intel's IOP33X (XScale) family of processors.
|
||||
|
||||
|
|
@ -418,7 +419,7 @@ config ARCH_MXC
|
|||
select GENERIC_CLOCKEVENTS
|
||||
select ARCH_MTD_XIP
|
||||
select GENERIC_GPIO
|
||||
select HAVE_GPIO_LIB
|
||||
select ARCH_REQUIRE_GPIOLIB
|
||||
help
|
||||
Support for Freescale MXC/iMX-based family of processors
|
||||
|
||||
|
|
@ -1224,6 +1225,8 @@ source "drivers/dma/Kconfig"
|
|||
|
||||
source "drivers/dca/Kconfig"
|
||||
|
||||
source "drivers/regulator/Kconfig"
|
||||
|
||||
source "drivers/uio/Kconfig"
|
||||
|
||||
endmenu
|
||||
|
|
|
|||
|
|
@ -67,7 +67,7 @@ tune-$(CONFIG_CPU_ARM720T) :=-mtune=arm7tdmi
|
|||
tune-$(CONFIG_CPU_ARM740T) :=-mtune=arm7tdmi
|
||||
tune-$(CONFIG_CPU_ARM9TDMI) :=-mtune=arm9tdmi
|
||||
tune-$(CONFIG_CPU_ARM940T) :=-mtune=arm9tdmi
|
||||
tune-$(CONFIG_CPU_ARM946T) :=$(call cc-option,-mtune=arm9e,-mtune=arm9tdmi)
|
||||
tune-$(CONFIG_CPU_ARM946E) :=$(call cc-option,-mtune=arm9e,-mtune=arm9tdmi)
|
||||
tune-$(CONFIG_CPU_ARM920T) :=-mtune=arm9tdmi
|
||||
tune-$(CONFIG_CPU_ARM922T) :=-mtune=arm9tdmi
|
||||
tune-$(CONFIG_CPU_ARM925T) :=-mtune=arm9tdmi
|
||||
|
|
@ -97,9 +97,7 @@ textofs-y := 0x00008000
|
|||
machine-$(CONFIG_ARCH_RPC) := rpc
|
||||
machine-$(CONFIG_ARCH_EBSA110) := ebsa110
|
||||
machine-$(CONFIG_ARCH_CLPS7500) := clps7500
|
||||
incdir-$(CONFIG_ARCH_CLPS7500) := cl7500
|
||||
machine-$(CONFIG_FOOTBRIDGE) := footbridge
|
||||
incdir-$(CONFIG_FOOTBRIDGE) := ebsa285
|
||||
machine-$(CONFIG_ARCH_SHARK) := shark
|
||||
machine-$(CONFIG_ARCH_SA1100) := sa1100
|
||||
ifeq ($(CONFIG_ARCH_SA1100),y)
|
||||
|
|
@ -114,13 +112,15 @@ endif
|
|||
machine-$(CONFIG_ARCH_IOP32X) := iop32x
|
||||
machine-$(CONFIG_ARCH_IOP33X) := iop33x
|
||||
machine-$(CONFIG_ARCH_IOP13XX) := iop13xx
|
||||
plat-$(CONFIG_PLAT_IOP) := iop
|
||||
machine-$(CONFIG_ARCH_IXP4XX) := ixp4xx
|
||||
machine-$(CONFIG_ARCH_IXP2000) := ixp2000
|
||||
machine-$(CONFIG_ARCH_IXP23XX) := ixp23xx
|
||||
machine-$(CONFIG_ARCH_OMAP1) := omap1
|
||||
machine-$(CONFIG_ARCH_OMAP2) := omap2
|
||||
incdir-$(CONFIG_ARCH_OMAP) := omap
|
||||
machine-$(CONFIG_ARCH_S3C2410) := s3c2410
|
||||
plat-$(CONFIG_ARCH_OMAP) := omap
|
||||
machine-$(CONFIG_ARCH_S3C2410) := s3c2410 s3c2400 s3c2412 s3c2440 s3c2442 s3c2443
|
||||
plat-$(CONFIG_PLAT_S3C24XX) := s3c24xx
|
||||
machine-$(CONFIG_ARCH_LH7A40X) := lh7a40x
|
||||
machine-$(CONFIG_ARCH_VERSATILE) := versatile
|
||||
machine-$(CONFIG_ARCH_IMX) := imx
|
||||
|
|
@ -135,10 +135,11 @@ endif
|
|||
machine-$(CONFIG_ARCH_DAVINCI) := davinci
|
||||
machine-$(CONFIG_ARCH_KIRKWOOD) := kirkwood
|
||||
machine-$(CONFIG_ARCH_KS8695) := ks8695
|
||||
incdir-$(CONFIG_ARCH_MXC) := mxc
|
||||
plat-$(CONFIG_ARCH_MXC) := mxc
|
||||
machine-$(CONFIG_ARCH_MX2) := mx2
|
||||
machine-$(CONFIG_ARCH_MX3) := mx3
|
||||
machine-$(CONFIG_ARCH_ORION5X) := orion5x
|
||||
plat-$(CONFIG_PLAT_ORION) := orion
|
||||
machine-$(CONFIG_ARCH_MSM7X00A) := msm
|
||||
machine-$(CONFIG_ARCH_LOKI) := loki
|
||||
machine-$(CONFIG_ARCH_MV78XX0) := mv78xx0
|
||||
|
|
@ -153,17 +154,22 @@ endif
|
|||
# The byte offset of the kernel image in RAM from the start of RAM.
|
||||
TEXT_OFFSET := $(textofs-y)
|
||||
|
||||
ifeq ($(incdir-y),)
|
||||
incdir-y := $(machine-y)
|
||||
endif
|
||||
INCDIR := arch-$(incdir-y)
|
||||
|
||||
# The first directory contains additional information for the boot setup code
|
||||
ifneq ($(machine-y),)
|
||||
MACHINE := arch/arm/mach-$(machine-y)/
|
||||
MACHINE := arch/arm/mach-$(word 1,$(machine-y))/
|
||||
else
|
||||
MACHINE :=
|
||||
endif
|
||||
|
||||
machdirs := $(patsubst %,arch/arm/mach-%/,$(machine-y))
|
||||
platdirs := $(patsubst %,arch/arm/plat-%/,$(plat-y))
|
||||
|
||||
ifeq ($(KBUILD_SRC),)
|
||||
KBUILD_CPPFLAGS += $(patsubst %,-I%include,$(machdirs) $(platdirs))
|
||||
else
|
||||
KBUILD_CPPFLAGS += $(patsubst %,-I$(srctree)/%include,$(machdirs) $(platdirs))
|
||||
endif
|
||||
|
||||
export TEXT_OFFSET GZFLAGS MMUEXT
|
||||
|
||||
# Do we have FASTFPE?
|
||||
|
|
@ -174,23 +180,11 @@ endif
|
|||
|
||||
# If we have a machine-specific directory, then include it in the build.
|
||||
core-y += arch/arm/kernel/ arch/arm/mm/ arch/arm/common/
|
||||
core-y += $(MACHINE)
|
||||
core-$(CONFIG_ARCH_S3C2410) += arch/arm/mach-s3c2400/
|
||||
core-$(CONFIG_ARCH_S3C2410) += arch/arm/mach-s3c2412/
|
||||
core-$(CONFIG_ARCH_S3C2410) += arch/arm/mach-s3c2440/
|
||||
core-$(CONFIG_ARCH_S3C2410) += arch/arm/mach-s3c2442/
|
||||
core-$(CONFIG_ARCH_S3C2410) += arch/arm/mach-s3c2443/
|
||||
core-y += $(machdirs) $(platdirs)
|
||||
core-$(CONFIG_FPE_NWFPE) += arch/arm/nwfpe/
|
||||
core-$(CONFIG_FPE_FASTFPE) += $(FASTFPE_OBJ)
|
||||
core-$(CONFIG_VFP) += arch/arm/vfp/
|
||||
|
||||
# If we have a common platform directory, then include it in the build.
|
||||
core-$(CONFIG_PLAT_IOP) += arch/arm/plat-iop/
|
||||
core-$(CONFIG_PLAT_ORION) += arch/arm/plat-orion/
|
||||
core-$(CONFIG_ARCH_OMAP) += arch/arm/plat-omap/
|
||||
core-$(CONFIG_PLAT_S3C24XX) += arch/arm/plat-s3c24xx/
|
||||
core-$(CONFIG_ARCH_MXC) += arch/arm/plat-mxc/
|
||||
|
||||
drivers-$(CONFIG_OPROFILE) += arch/arm/oprofile/
|
||||
|
||||
libs-y := arch/arm/lib/ $(libs-y)
|
||||
|
|
@ -210,20 +204,10 @@ boot := arch/arm/boot
|
|||
# them changed. We use .arch to indicate when they were updated
|
||||
# last, otherwise make uses the target directory mtime.
|
||||
|
||||
include/asm-arm/.arch: $(wildcard include/config/arch/*.h) include/config/auto.conf
|
||||
@echo ' SYMLINK include/asm-arm/arch -> include/asm-arm/$(INCDIR)'
|
||||
ifneq ($(KBUILD_SRC),)
|
||||
$(Q)mkdir -p include/asm-arm
|
||||
$(Q)ln -fsn $(srctree)/include/asm-arm/$(INCDIR) include/asm-arm/arch
|
||||
else
|
||||
$(Q)ln -fsn $(INCDIR) include/asm-arm/arch
|
||||
endif
|
||||
@touch $@
|
||||
|
||||
archprepare: maketools
|
||||
|
||||
PHONY += maketools FORCE
|
||||
maketools: include/linux/version.h include/asm-arm/.arch FORCE
|
||||
maketools: include/linux/version.h FORCE
|
||||
$(Q)$(MAKE) $(build)=arch/arm/tools include/asm-arm/mach-types.h
|
||||
|
||||
# Convert bzImage to zImage
|
||||
|
|
|
|||
|
|
@ -112,6 +112,3 @@ $(obj)/font.c: $(FONTC)
|
|||
|
||||
$(obj)/vmlinux.lds: $(obj)/vmlinux.lds.in arch/arm/boot/Makefile .config
|
||||
@sed "$(SEDFLAGS)" < $< > $@
|
||||
|
||||
$(obj)/misc.o: $(obj)/misc.c include/asm/arch/uncompress.h lib/inflate.c
|
||||
|
||||
|
|
|
|||
|
|
@ -6,7 +6,6 @@
|
|||
*/
|
||||
|
||||
#include <linux/linkage.h>
|
||||
#include <asm/mach-types.h>
|
||||
|
||||
.section ".start", "ax"
|
||||
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@
|
|||
|
||||
#else
|
||||
|
||||
#include <asm/arch/debug-macro.S>
|
||||
#include <mach/debug-macro.S>
|
||||
|
||||
.macro writeb, ch, rb
|
||||
senduart \ch, \rb
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ unsigned int __machine_arch_type;
|
|||
static void putstr(const char *ptr);
|
||||
|
||||
#include <linux/compiler.h>
|
||||
#include <asm/arch/uncompress.h>
|
||||
#include <mach/uncompress.h>
|
||||
|
||||
#ifdef CONFIG_DEBUG_ICEDCC
|
||||
|
||||
|
|
|
|||
|
|
@ -280,7 +280,7 @@ unmap_single(struct device *dev, dma_addr_t dma_addr, size_t size,
|
|||
/*
|
||||
* Trying to unmap an invalid mapping
|
||||
*/
|
||||
if (dma_mapping_error(dma_addr)) {
|
||||
if (dma_mapping_error(dev, dma_addr)) {
|
||||
dev_err(dev, "Trying to unmap invalid mapping\n");
|
||||
return;
|
||||
}
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue