Skip to content

Commit

Permalink
---
Browse files Browse the repository at this point in the history
yaml
---
r: 108121
b: refs/heads/master
c: 1c5402b
h: refs/heads/master
i:
  108119: 6884fd2
v: v3
  • Loading branch information
Valentine Barshak authored and Josh Boyer committed Aug 5, 2008
1 parent 27ecb01 commit 318bea2
Show file tree
Hide file tree
Showing 2,874 changed files with 50,627 additions and 84,170 deletions.
2 changes: 1 addition & 1 deletion [refs]
Original file line number Diff line number Diff line change
@@ -1,2 +1,2 @@
---
refs/heads/master: a7ef6a40f700496c60b8f7206fff74fecd67b3a2
refs/heads/master: 1c5402ba55e809f0b685f07728794ea27b197f33
2 changes: 2 additions & 0 deletions trunk/Documentation/00-INDEX
Original file line number Diff line number Diff line change
Expand Up @@ -89,6 +89,8 @@ 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/
Expand Down
8 changes: 4 additions & 4 deletions trunk/Documentation/DocBook/s390-drivers.tmpl
Original file line number Diff line number Diff line change
Expand Up @@ -100,7 +100,7 @@
the hardware structures represented here, please consult the Principles
of Operation.
</para>
!Iarch/s390/include/asm/cio.h
!Iinclude/asm-s390/cio.h
</sect1>
<sect1 id="ccwdev">
<title>ccw devices</title>
Expand All @@ -114,7 +114,7 @@
ccw device structure. Device drivers must not bypass those functions
or strange side effects may happen.
</para>
!Iarch/s390/include/asm/ccwdev.h
!Iinclude/asm-s390/ccwdev.h
!Edrivers/s390/cio/device.c
!Edrivers/s390/cio/device_ops.c
</sect1>
Expand All @@ -125,7 +125,7 @@
measurement data which is made available by the channel subsystem
for each channel attached device.
</para>
!Iarch/s390/include/asm/cmb.h
!Iinclude/asm-s390/cmb.h
!Edrivers/s390/cio/cmf.c
</sect1>
</chapter>
Expand All @@ -142,7 +142,7 @@
</para>
<sect1 id="ccwgroupdevices">
<title>ccw group devices</title>
!Iarch/s390/include/asm/ccwgroup.h
!Iinclude/asm-s390/ccwgroup.h
!Edrivers/s390/cio/ccwgroup.c
</sect1>
</chapter>
Expand Down
2 changes: 1 addition & 1 deletion trunk/Documentation/DocBook/videobook.tmpl
Original file line number Diff line number Diff line change
Expand Up @@ -1648,7 +1648,7 @@ static struct video_buffer capture_fb;

<chapter id="pubfunctions">
<title>Public Functions Provided</title>
!Edrivers/media/video/v4l2-dev.c
!Edrivers/media/video/videodev.c
</chapter>

</book>
38 changes: 26 additions & 12 deletions trunk/Documentation/DocBook/z8530book.tmpl
Original file line number Diff line number Diff line change
Expand Up @@ -69,6 +69,12 @@
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">
Expand Down Expand Up @@ -173,27 +179,35 @@
<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 generic HDLC
present and in use. In addition to use the SyncPPP and Cisco 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 hdlc-&gt; priv field of the
the netdevice field of each channel. The dev-&gt; priv field of the
network device points to your private data - you will need to be
able to find your private data from this.
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.
</para>
<para>
The way most drivers approach this particular problem is to
create a structure holding the Z8530 device definition and
put that into the private field of the network device. The
network device fields of the channels then point back to the
network devices.
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.
</para>
<para>
If you wish to use the generic HDLC then you need to register
the HDLC device.
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.
</para>
<para>
Before you register your network device you will also need to
Expand Down Expand Up @@ -300,10 +314,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 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.
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.
</para>
<para>
The function <function>z8530_get_stats</function> returns a pointer
Expand Down
2 changes: 1 addition & 1 deletion trunk/Documentation/arm/IXP4xx
Original file line number Diff line number Diff line change
Expand Up @@ -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 arch/arm/mach-ixp4xx/include/mach/platform.h for access functions.
See include/asm-arm/arch-ixp4xx/platform.h for access functions.
- Timers (watchdog, OS)

The following components of the chips are not supported by Linux and
Expand Down
2 changes: 1 addition & 1 deletion trunk/Documentation/arm/Interrupts
Original file line number Diff line number Diff line change
Expand Up @@ -158,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 arch/arm/mach-*/include/mach/irq.h
7. fixup_irq() is gone, as is include/asm-arm/arch-*/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
Expand Down
4 changes: 2 additions & 2 deletions trunk/Documentation/arm/README
Original file line number Diff line number Diff line change
Expand Up @@ -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 arch/arm/mach-$(MACHINE)/include/mach
machines, there should be a corresponding include/asm-arm/arch-$(MACHINE)
directory.


Expand Down Expand Up @@ -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
arch/arm/mach-<class> - which contain the source files to/include/mach
include/asm-arm/arch-<class> - which contain the source files to
support the machine class. This directories also contain any machine
specific supporting code.

Expand Down
8 changes: 4 additions & 4 deletions trunk/Documentation/arm/Samsung-S3C24XX/GPIO.txt
Original file line number Diff line number Diff line change
Expand Up @@ -16,13 +16,13 @@ Introduction
Headers
-------

See arch/arm/mach-s3c2410/include/mach/regs-gpio.h for the list
See include/asm-arm/arch-s3c2410/regs-gpio.h for the list
of GPIO pins, and the configuration values for them. This
is included by using #include <mach/regs-gpio.h>
is included by using #include <asm/arch/regs-gpio.h>

The GPIO management functions are defined in the hardware
header arch/arm/mach-s3c2410/include/mach/hardware.h which can be
included by #include <mach/hardware.h>
header include/asm-arm/arch-s3c2410/hardware.h which can be
included by #include <asm/arch/hardware.h>

A useful amount of documentation can be found in the hardware
header on how the GPIO functions (and others) work.
Expand Down
2 changes: 1 addition & 1 deletion trunk/Documentation/arm/Samsung-S3C24XX/Overview.txt
Original file line number Diff line number Diff line change
Expand Up @@ -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
arch/arm/mach-s3c2410 directory./include/mach
include/asm-arm/arch-s3c2410 directory.


Machines
Expand Down
2 changes: 1 addition & 1 deletion trunk/Documentation/arm/Samsung-S3C24XX/USB-Host.txt
Original file line number Diff line number Diff line change
Expand Up @@ -49,7 +49,7 @@ Board Support
Platform Data
-------------

See arch/arm/mach-s3c2410/include/mach/usb-control.h for the
See linux/include/asm-arm/arch-s3c2410/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 .

Expand Down
21 changes: 15 additions & 6 deletions trunk/Documentation/cciss.txt
Original file line number Diff line number Diff line change
Expand Up @@ -112,18 +112,27 @@ 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. This may be done via the /proc filesystem.
For example:
have been made, in addition to and prior to informing the SCSI
mid layer. This may be done via the /proc filesystem. For example:

echo "rescan" > /proc/scsi/cciss0/1

This causes the driver to query the adapter about changes to the
physical SCSI buses and/or fibre channel arbitrated loop and the
This causes the adapter 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. It then notifies the SCSI mid layer
of these changes.
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.

Note that the naming convention of the /proc filesystem entries
contains a number in addition to the driver name. (E.g. "cciss0"
Expand Down
133 changes: 133 additions & 0 deletions trunk/Documentation/cli-sti-removal.txt
Original file line number Diff line number Diff line change
@@ -0,0 +1,133 @@

#### 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 :-)

Loading

0 comments on commit 318bea2

Please sign in to comment.