You've already forked linux-apfs
mirror of
https://github.com/linux-apfs/linux-apfs.git
synced 2026-05-01 15:00:59 -07:00
Merge commit 'v2.6.35-rc3' into next
This commit is contained in:
Dmitry Torokhov
@@ -28,6 +28,7 @@ modules.builtin
|
||||
*.gz
|
||||
*.bz2
|
||||
*.lzma
|
||||
*.lzo
|
||||
*.patch
|
||||
*.gcno
|
||||
|
||||
|
||||
@@ -0,0 +1,7 @@
|
||||
filesystems/dnotify_test
|
||||
laptops/dslm
|
||||
timers/hpet_example
|
||||
vm/hugepage-mmap
|
||||
vm/hugepage-shm
|
||||
vm/map_hugetlb
|
||||
|
||||
@@ -133,46 +133,6 @@ Description:
|
||||
The symbolic link points to the PCI device sysfs entry of the
|
||||
Physical Function this device associates with.
|
||||
|
||||
|
||||
What: /sys/bus/pci/slots/...
|
||||
Date: April 2005 (possibly older)
|
||||
KernelVersion: 2.6.12 (possibly older)
|
||||
Contact: linux-pci@vger.kernel.org
|
||||
Description:
|
||||
When the appropriate driver is loaded, it will create a
|
||||
directory per claimed physical PCI slot in
|
||||
/sys/bus/pci/slots/. The names of these directories are
|
||||
specific to the driver, which in turn, are specific to the
|
||||
platform, but in general, should match the label on the
|
||||
machine's physical chassis.
|
||||
|
||||
The drivers that can create slot directories include the
|
||||
PCI hotplug drivers, and as of 2.6.27, the pci_slot driver.
|
||||
|
||||
The slot directories contain, at a minimum, a file named
|
||||
'address' which contains the PCI bus:device:function tuple.
|
||||
Other files may appear as well, but are specific to the
|
||||
driver.
|
||||
|
||||
What: /sys/bus/pci/slots/.../function[0-7]
|
||||
Date: March 2010
|
||||
KernelVersion: 2.6.35
|
||||
Contact: linux-pci@vger.kernel.org
|
||||
Description:
|
||||
If PCI slot directories (as described above) are created,
|
||||
and the physical slot is actually populated with a device,
|
||||
symbolic links in the slot directory pointing to the
|
||||
device's PCI functions are created as well.
|
||||
|
||||
What: /sys/bus/pci/devices/.../slot
|
||||
Date: March 2010
|
||||
KernelVersion: 2.6.35
|
||||
Contact: linux-pci@vger.kernel.org
|
||||
Description:
|
||||
If PCI slot directories (as described above) are created,
|
||||
a symbolic link pointing to the slot directory will be
|
||||
created as well.
|
||||
|
||||
What: /sys/bus/pci/slots/.../module
|
||||
Date: June 2009
|
||||
Contact: linux-pci@vger.kernel.org
|
||||
|
||||
@@ -389,7 +389,7 @@
|
||||
</para>
|
||||
<para>
|
||||
If your driver supports memory management (it should!), you'll
|
||||
need to set that up at load time as well. How you intialize
|
||||
need to set that up at load time as well. How you initialize
|
||||
it depends on which memory manager you're using, TTM or GEM.
|
||||
</para>
|
||||
<sect3>
|
||||
@@ -399,7 +399,7 @@
|
||||
aperture space for graphics devices. TTM supports both UMA devices
|
||||
and devices with dedicated video RAM (VRAM), i.e. most discrete
|
||||
graphics devices. If your device has dedicated RAM, supporting
|
||||
TTM is desireable. TTM also integrates tightly with your
|
||||
TTM is desirable. TTM also integrates tightly with your
|
||||
driver specific buffer execution function. See the radeon
|
||||
driver for examples.
|
||||
</para>
|
||||
@@ -443,7 +443,7 @@
|
||||
likely eventually calling ttm_bo_global_init and
|
||||
ttm_bo_global_release, respectively. Also like the previous
|
||||
object, ttm_global_item_ref is used to create an initial reference
|
||||
count for the TTM, which will call your initalization function.
|
||||
count for the TTM, which will call your initialization function.
|
||||
</para>
|
||||
</sect3>
|
||||
<sect3>
|
||||
@@ -557,7 +557,7 @@ void intel_crt_init(struct drm_device *dev)
|
||||
CRT connector and encoder combination is created. A device
|
||||
specific i2c bus is also created, for fetching EDID data and
|
||||
performing monitor detection. Once the process is complete,
|
||||
the new connector is regsitered with sysfs, to make its
|
||||
the new connector is registered with sysfs, to make its
|
||||
properties available to applications.
|
||||
</para>
|
||||
<sect4>
|
||||
@@ -581,12 +581,12 @@ void intel_crt_init(struct drm_device *dev)
|
||||
<para>
|
||||
For each encoder, CRTC and connector, several functions must
|
||||
be provided, depending on the object type. Encoder objects
|
||||
need should provide a DPMS (basically on/off) function, mode fixup
|
||||
need to provide a DPMS (basically on/off) function, mode fixup
|
||||
(for converting requested modes into native hardware timings),
|
||||
and prepare, set and commit functions for use by the core DRM
|
||||
helper functions. Connector helpers need to provide mode fetch and
|
||||
validity functions as well as an encoder matching function for
|
||||
returing an ideal encoder for a given connector. The core
|
||||
returning an ideal encoder for a given connector. The core
|
||||
connector functions include a DPMS callback, (deprecated)
|
||||
save/restore routines, detection, mode probing, property handling,
|
||||
and cleanup functions.
|
||||
|
||||
@@ -58,7 +58,7 @@ MPEG stream embedded, sliced VBI data format in this specification.
|
||||
</contrib>
|
||||
<affiliation>
|
||||
<address>
|
||||
<email>awalls@radix.net</email>
|
||||
<email>awalls@md.metrocast.net</email>
|
||||
</address>
|
||||
</affiliation>
|
||||
</author>
|
||||
|
||||
@@ -53,8 +53,10 @@ input</refpurpose>
|
||||
automatically, similar to sensing the video standard. To do so, applications
|
||||
call <constant> VIDIOC_QUERY_DV_PRESET</constant> with a pointer to a
|
||||
&v4l2-dv-preset; type. Once the hardware detects a preset, that preset is
|
||||
returned in the preset field of &v4l2-dv-preset;. When detection is not
|
||||
possible or fails, the value V4L2_DV_INVALID is returned.</para>
|
||||
returned in the preset field of &v4l2-dv-preset;. If the preset could not be
|
||||
detected because there was no signal, or the signal was unreliable, or the
|
||||
signal did not map to a supported preset, then the value V4L2_DV_INVALID is
|
||||
returned.</para>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
|
||||
@@ -6,6 +6,8 @@ Written by Doug Thompson <dougthompson@xmission.com>
|
||||
7 Dec 2005
|
||||
17 Jul 2007 Updated
|
||||
|
||||
(c) Mauro Carvalho Chehab <mchehab@redhat.com>
|
||||
05 Aug 2009 Nehalem interface
|
||||
|
||||
EDAC is maintained and written by:
|
||||
|
||||
@@ -717,3 +719,153 @@ unique drivers for their hardware systems.
|
||||
The 'test_device_edac' sample driver is located at the
|
||||
bluesmoke.sourceforge.net project site for EDAC.
|
||||
|
||||
=======================================================================
|
||||
NEHALEM USAGE OF EDAC APIs
|
||||
|
||||
This chapter documents some EXPERIMENTAL mappings for EDAC API to handle
|
||||
Nehalem EDAC driver. They will likely be changed on future versions
|
||||
of the driver.
|
||||
|
||||
Due to the way Nehalem exports Memory Controller data, some adjustments
|
||||
were done at i7core_edac driver. This chapter will cover those differences
|
||||
|
||||
1) On Nehalem, there are one Memory Controller per Quick Patch Interconnect
|
||||
(QPI). At the driver, the term "socket" means one QPI. This is
|
||||
associated with a physical CPU socket.
|
||||
|
||||
Each MC have 3 physical read channels, 3 physical write channels and
|
||||
3 logic channels. The driver currenty sees it as just 3 channels.
|
||||
Each channel can have up to 3 DIMMs.
|
||||
|
||||
The minimum known unity is DIMMs. There are no information about csrows.
|
||||
As EDAC API maps the minimum unity is csrows, the driver sequencially
|
||||
maps channel/dimm into different csrows.
|
||||
|
||||
For example, suposing the following layout:
|
||||
Ch0 phy rd0, wr0 (0x063f4031): 2 ranks, UDIMMs
|
||||
dimm 0 1024 Mb offset: 0, bank: 8, rank: 1, row: 0x4000, col: 0x400
|
||||
dimm 1 1024 Mb offset: 4, bank: 8, rank: 1, row: 0x4000, col: 0x400
|
||||
Ch1 phy rd1, wr1 (0x063f4031): 2 ranks, UDIMMs
|
||||
dimm 0 1024 Mb offset: 0, bank: 8, rank: 1, row: 0x4000, col: 0x400
|
||||
Ch2 phy rd3, wr3 (0x063f4031): 2 ranks, UDIMMs
|
||||
dimm 0 1024 Mb offset: 0, bank: 8, rank: 1, row: 0x4000, col: 0x400
|
||||
The driver will map it as:
|
||||
csrow0: channel 0, dimm0
|
||||
csrow1: channel 0, dimm1
|
||||
csrow2: channel 1, dimm0
|
||||
csrow3: channel 2, dimm0
|
||||
|
||||
exports one
|
||||
DIMM per csrow.
|
||||
|
||||
Each QPI is exported as a different memory controller.
|
||||
|
||||
2) Nehalem MC has the hability to generate errors. The driver implements this
|
||||
functionality via some error injection nodes:
|
||||
|
||||
For injecting a memory error, there are some sysfs nodes, under
|
||||
/sys/devices/system/edac/mc/mc?/:
|
||||
|
||||
inject_addrmatch/*:
|
||||
Controls the error injection mask register. It is possible to specify
|
||||
several characteristics of the address to match an error code:
|
||||
dimm = the affected dimm. Numbers are relative to a channel;
|
||||
rank = the memory rank;
|
||||
channel = the channel that will generate an error;
|
||||
bank = the affected bank;
|
||||
page = the page address;
|
||||
column (or col) = the address column.
|
||||
each of the above values can be set to "any" to match any valid value.
|
||||
|
||||
At driver init, all values are set to any.
|
||||
|
||||
For example, to generate an error at rank 1 of dimm 2, for any channel,
|
||||
any bank, any page, any column:
|
||||
echo 2 >/sys/devices/system/edac/mc/mc0/inject_addrmatch/dimm
|
||||
echo 1 >/sys/devices/system/edac/mc/mc0/inject_addrmatch/rank
|
||||
|
||||
To return to the default behaviour of matching any, you can do:
|
||||
echo any >/sys/devices/system/edac/mc/mc0/inject_addrmatch/dimm
|
||||
echo any >/sys/devices/system/edac/mc/mc0/inject_addrmatch/rank
|
||||
|
||||
inject_eccmask:
|
||||
specifies what bits will have troubles,
|
||||
|
||||
inject_section:
|
||||
specifies what ECC cache section will get the error:
|
||||
3 for both
|
||||
2 for the highest
|
||||
1 for the lowest
|
||||
|
||||
inject_type:
|
||||
specifies the type of error, being a combination of the following bits:
|
||||
bit 0 - repeat
|
||||
bit 1 - ecc
|
||||
bit 2 - parity
|
||||
|
||||
inject_enable starts the error generation when something different
|
||||
than 0 is written.
|
||||
|
||||
All inject vars can be read. root permission is needed for write.
|
||||
|
||||
Datasheet states that the error will only be generated after a write on an
|
||||
address that matches inject_addrmatch. It seems, however, that reading will
|
||||
also produce an error.
|
||||
|
||||
For example, the following code will generate an error for any write access
|
||||
at socket 0, on any DIMM/address on channel 2:
|
||||
|
||||
echo 2 >/sys/devices/system/edac/mc/mc0/inject_addrmatch/channel
|
||||
echo 2 >/sys/devices/system/edac/mc/mc0/inject_type
|
||||
echo 64 >/sys/devices/system/edac/mc/mc0/inject_eccmask
|
||||
echo 3 >/sys/devices/system/edac/mc/mc0/inject_section
|
||||
echo 1 >/sys/devices/system/edac/mc/mc0/inject_enable
|
||||
dd if=/dev/mem of=/dev/null seek=16k bs=4k count=1 >& /dev/null
|
||||
|
||||
For socket 1, it is needed to replace "mc0" by "mc1" at the above
|
||||
commands.
|
||||
|
||||
The generated error message will look like:
|
||||
|
||||
EDAC MC0: UE row 0, channel-a= 0 channel-b= 0 labels "-": NON_FATAL (addr = 0x0075b980, socket=0, Dimm=0, Channel=2, syndrome=0x00000040, count=1, Err=8c0000400001009f:4000080482 (read error: read ECC error))
|
||||
|
||||
3) Nehalem specific Corrected Error memory counters
|
||||
|
||||
Nehalem have some registers to count memory errors. The driver uses those
|
||||
registers to report Corrected Errors on devices with Registered Dimms.
|
||||
|
||||
However, those counters don't work with Unregistered Dimms. As the chipset
|
||||
offers some counters that also work with UDIMMS (but with a worse level of
|
||||
granularity than the default ones), the driver exposes those registers for
|
||||
UDIMM memories.
|
||||
|
||||
They can be read by looking at the contents of all_channel_counts/
|
||||
|
||||
$ for i in /sys/devices/system/edac/mc/mc0/all_channel_counts/*; do echo $i; cat $i; done
|
||||
/sys/devices/system/edac/mc/mc0/all_channel_counts/udimm0
|
||||
0
|
||||
/sys/devices/system/edac/mc/mc0/all_channel_counts/udimm1
|
||||
0
|
||||
/sys/devices/system/edac/mc/mc0/all_channel_counts/udimm2
|
||||
0
|
||||
|
||||
What happens here is that errors on different csrows, but at the same
|
||||
dimm number will increment the same counter.
|
||||
So, in this memory mapping:
|
||||
csrow0: channel 0, dimm0
|
||||
csrow1: channel 0, dimm1
|
||||
csrow2: channel 1, dimm0
|
||||
csrow3: channel 2, dimm0
|
||||
The hardware will increment udimm0 for an error at the first dimm at either
|
||||
csrow0, csrow2 or csrow3;
|
||||
The hardware will increment udimm1 for an error at the second dimm at either
|
||||
csrow0, csrow2 or csrow3;
|
||||
The hardware will increment udimm2 for an error at the third dimm at either
|
||||
csrow0, csrow2 or csrow3;
|
||||
|
||||
4) Standard error counters
|
||||
|
||||
The standard error counters are generated when an mcelog error is received
|
||||
by the driver. Since, with udimm, this is counted by software, it is
|
||||
possible that some errors could be lost. With rdimm's, they displays the
|
||||
contents of the registers
|
||||
|
||||
@@ -578,15 +578,6 @@ Who: Avi Kivity <avi@redhat.com>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: "acpi=ht" boot option
|
||||
When: 2.6.35
|
||||
Why: Useful in 2003, implementation is a hack.
|
||||
Generally invoked by accident today.
|
||||
Seen as doing more harm than good.
|
||||
Who: Len Brown <len.brown@intel.com>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: iwlwifi 50XX module parameters
|
||||
When: 2.6.40
|
||||
Why: The "..50" modules parameters were used to configure 5000 series and
|
||||
|
||||
@@ -794,11 +794,6 @@ designed.
|
||||
|
||||
Roadmap:
|
||||
|
||||
2.6.35 Inclusion in mainline as an experimental mount option
|
||||
=> approximately 2-3 months to merge window
|
||||
=> needs to be in xfs-dev tree in 4-6 weeks
|
||||
=> code is nearing readiness for review
|
||||
|
||||
2.6.37 Remove experimental tag from mount option
|
||||
=> should be roughly 6 months after initial merge
|
||||
=> enough time to:
|
||||
|
||||
@@ -6,12 +6,12 @@ Supported adapters:
|
||||
http://www.ali.com.tw/eng/support/datasheet_request.php
|
||||
|
||||
Authors:
|
||||
Frodo Looijaard <frodol@dds.nl>,
|
||||
Frodo Looijaard <frodol@dds.nl>,
|
||||
Philip Edelbrock <phil@netroedge.com>,
|
||||
Mark D. Studebaker <mdsxyz123@yahoo.com>,
|
||||
Dan Eaton <dan.eaton@rocketlogix.com>,
|
||||
Stephen Rousset<stephen.rousset@rocketlogix.com>
|
||||
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
|
||||
@@ -18,7 +18,7 @@ For an overview of these chips see http://www.acerlabs.com
|
||||
The M1563 southbridge is deceptively similar to the M1533, with a few
|
||||
notable exceptions. One of those happens to be the fact they upgraded the
|
||||
i2c core to be SMBus 2.0 compliant, and happens to be almost identical to
|
||||
the i2c controller found in the Intel 801 south bridges.
|
||||
the i2c controller found in the Intel 801 south bridges.
|
||||
|
||||
Features
|
||||
--------
|
||||
|
||||
@@ -6,8 +6,8 @@ Supported adapters:
|
||||
http://www.ali.com.tw/eng/support/datasheet_request.php
|
||||
|
||||
Authors:
|
||||
Frodo Looijaard <frodol@dds.nl>,
|
||||
Philip Edelbrock <phil@netroedge.com>,
|
||||
Frodo Looijaard <frodol@dds.nl>,
|
||||
Philip Edelbrock <phil@netroedge.com>,
|
||||
Mark D. Studebaker <mdsxyz123@yahoo.com>
|
||||
|
||||
Module Parameters
|
||||
@@ -40,10 +40,10 @@ M1541 and M1543C South Bridges.
|
||||
The M1543C is a South bridge for desktop systems.
|
||||
The M1541 is a South bridge for portable systems.
|
||||
They are part of the following ALI chipsets:
|
||||
|
||||
* "Aladdin Pro 2" includes the M1621 Slot 1 North bridge with AGP and
|
||||
|
||||
* "Aladdin Pro 2" includes the M1621 Slot 1 North bridge with AGP and
|
||||
100MHz CPU Front Side bus
|
||||
* "Aladdin V" includes the M1541 Socket 7 North bridge with AGP and 100MHz
|
||||
* "Aladdin V" includes the M1541 Socket 7 North bridge with AGP and 100MHz
|
||||
CPU Front Side bus
|
||||
Some Aladdin V motherboards:
|
||||
Asus P5A
|
||||
@@ -77,7 +77,7 @@ output of lspci will show something similar to the following:
|
||||
** then run lspci.
|
||||
** If you see the 1533 and 5229 devices but NOT the 7101 device,
|
||||
** then you must enable ACPI, the PMU, SMB, or something similar
|
||||
** in the BIOS.
|
||||
** in the BIOS.
|
||||
** The driver won't work if it can't find the M7101 device.
|
||||
|
||||
The SMB controller is part of the M7101 device, which is an ACPI-compliant
|
||||
@@ -87,8 +87,8 @@ The whole M7101 device has to be enabled for the SMB to work. You can't
|
||||
just enable the SMB alone. The SMB and the ACPI have separate I/O spaces.
|
||||
We make sure that the SMB is enabled. We leave the ACPI alone.
|
||||
|
||||
Features
|
||||
--------
|
||||
Features
|
||||
--------
|
||||
|
||||
This driver controls the SMB Host only. The SMB Slave
|
||||
controller on the M15X3 is not enabled. This driver does not use
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
Kernel driver i2c-pca-isa
|
||||
|
||||
Supported adapters:
|
||||
This driver supports ISA boards using the Philips PCA 9564
|
||||
Parallel bus to I2C bus controller
|
||||
This driver supports ISA boards using the Philips PCA 9564
|
||||
Parallel bus to I2C bus controller
|
||||
|
||||
Author: Ian Campbell <icampbell@arcom.com>, Arcom Control Systems
|
||||
Author: Ian Campbell <icampbell@arcom.com>, Arcom Control Systems
|
||||
|
||||
Module Parameters
|
||||
-----------------
|
||||
@@ -12,12 +12,12 @@ Module Parameters
|
||||
* base int
|
||||
I/O base address
|
||||
* irq int
|
||||
IRQ interrupt
|
||||
* clock int
|
||||
IRQ interrupt
|
||||
* clock int
|
||||
Clock rate as described in table 1 of PCA9564 datasheet
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
This driver supports ISA boards using the Philips PCA 9564
|
||||
Parallel bus to I2C bus controller
|
||||
This driver supports ISA boards using the Philips PCA 9564
|
||||
Parallel bus to I2C bus controller
|
||||
|
||||
@@ -1,41 +1,41 @@
|
||||
Kernel driver i2c-sis5595
|
||||
|
||||
Authors:
|
||||
Authors:
|
||||
Frodo Looijaard <frodol@dds.nl>,
|
||||
Mark D. Studebaker <mdsxyz123@yahoo.com>,
|
||||
Philip Edelbrock <phil@netroedge.com>
|
||||
Philip Edelbrock <phil@netroedge.com>
|
||||
|
||||
Supported adapters:
|
||||
* Silicon Integrated Systems Corp. SiS5595 Southbridge
|
||||
Datasheet: Publicly available at the Silicon Integrated Systems Corp. site.
|
||||
|
||||
Note: all have mfr. ID 0x1039.
|
||||
Note: all have mfr. ID 0x1039.
|
||||
|
||||
SUPPORTED PCI ID
|
||||
5595 0008
|
||||
|
||||
Note: these chips contain a 0008 device which is incompatible with the
|
||||
5595. We recognize these by the presence of the listed
|
||||
"blacklist" PCI ID and refuse to load.
|
||||
|
||||
NOT SUPPORTED PCI ID BLACKLIST PCI ID
|
||||
540 0008 0540
|
||||
550 0008 0550
|
||||
5513 0008 5511
|
||||
5581 0008 5597
|
||||
5582 0008 5597
|
||||
5597 0008 5597
|
||||
5598 0008 5597/5598
|
||||
630 0008 0630
|
||||
645 0008 0645
|
||||
646 0008 0646
|
||||
648 0008 0648
|
||||
650 0008 0650
|
||||
651 0008 0651
|
||||
730 0008 0730
|
||||
735 0008 0735
|
||||
745 0008 0745
|
||||
746 0008 0746
|
||||
SUPPORTED PCI ID
|
||||
5595 0008
|
||||
|
||||
Note: these chips contain a 0008 device which is incompatible with the
|
||||
5595. We recognize these by the presence of the listed
|
||||
"blacklist" PCI ID and refuse to load.
|
||||
|
||||
NOT SUPPORTED PCI ID BLACKLIST PCI ID
|
||||
540 0008 0540
|
||||
550 0008 0550
|
||||
5513 0008 5511
|
||||
5581 0008 5597
|
||||
5582 0008 5597
|
||||
5597 0008 5597
|
||||
5598 0008 5597/5598
|
||||
630 0008 0630
|
||||
645 0008 0645
|
||||
646 0008 0646
|
||||
648 0008 0648
|
||||
650 0008 0650
|
||||
651 0008 0651
|
||||
730 0008 0730
|
||||
735 0008 0735
|
||||
745 0008 0745
|
||||
746 0008 0746
|
||||
|
||||
Module Parameters
|
||||
-----------------
|
||||
|
||||
@@ -14,9 +14,9 @@ Module Parameters
|
||||
* force = [1|0] Forcibly enable the SIS630. DANGEROUS!
|
||||
This can be interesting for chipsets not named
|
||||
above to check if it works for you chipset, but DANGEROUS!
|
||||
|
||||
* high_clock = [1|0] Forcibly set Host Master Clock to 56KHz (default,
|
||||
what your BIOS use). DANGEROUS! This should be a bit
|
||||
|
||||
* high_clock = [1|0] Forcibly set Host Master Clock to 56KHz (default,
|
||||
what your BIOS use). DANGEROUS! This should be a bit
|
||||
faster, but freeze some systems (i.e. my Laptop).
|
||||
|
||||
|
||||
@@ -44,6 +44,6 @@ Philip Edelbrock <phil@netroedge.com>
|
||||
- testing SiS730 support
|
||||
Mark M. Hoffman <mhoffman@lightlink.com>
|
||||
- bug fixes
|
||||
|
||||
|
||||
To anyone else which I forgot here ;), thanks!
|
||||
|
||||
|
||||
@@ -1,17 +1,17 @@
|
||||
The I2C protocol knows about two kinds of device addresses: normal 7 bit
|
||||
The I2C protocol knows about two kinds of device addresses: normal 7 bit
|
||||
addresses, and an extended set of 10 bit addresses. The sets of addresses
|
||||
do not intersect: the 7 bit address 0x10 is not the same as the 10 bit
|
||||
address 0x10 (though a single device could respond to both of them). You
|
||||
select a 10 bit address by adding an extra byte after the address
|
||||
byte:
|
||||
S Addr7 Rd/Wr ....
|
||||
S Addr7 Rd/Wr ....
|
||||
becomes
|
||||
S 11110 Addr10 Rd/Wr
|
||||
S is the start bit, Rd/Wr the read/write bit, and if you count the number
|
||||
of bits, you will see the there are 8 after the S bit for 7 bit addresses,
|
||||
and 16 after the S bit for 10 bit addresses.
|
||||
|
||||
WARNING! The current 10 bit address support is EXPERIMENTAL. There are
|
||||
WARNING! The current 10 bit address support is EXPERIMENTAL. There are
|
||||
several places in the code that will cause SEVERE PROBLEMS with 10 bit
|
||||
addresses, even though there is some basic handling and hooks. Also,
|
||||
almost no supported adapter handles the 10 bit addresses correctly.
|
||||
|
||||
@@ -65,7 +65,7 @@ CROSS_COMPILE
|
||||
Specify an optional fixed part of the binutils filename.
|
||||
CROSS_COMPILE can be a part of the filename or the full path.
|
||||
|
||||
CROSS_COMPILE is also used for ccache is some setups.
|
||||
CROSS_COMPILE is also used for ccache in some setups.
|
||||
|
||||
CF
|
||||
--------------------------------------------------
|
||||
@@ -162,3 +162,7 @@ For tags/TAGS/cscope targets, you can specify more than one arch
|
||||
to be included in the databases, separated by blank space. E.g.:
|
||||
|
||||
$ make ALLSOURCE_ARCHS="x86 mips arm" tags
|
||||
|
||||
To get all available archs you can also specify all. E.g.:
|
||||
|
||||
$ make ALLSOURCE_ARCHS=all tags
|
||||
|
||||
@@ -66,14 +66,14 @@ of advantages of mutexes:
|
||||
|
||||
c0377ccb <mutex_lock>:
|
||||
c0377ccb: f0 ff 08 lock decl (%eax)
|
||||
c0377cce: 78 0e js c0377cde <.text.lock.mutex>
|
||||
c0377cce: 78 0e js c0377cde <.text..lock.mutex>
|
||||
c0377cd0: c3 ret
|
||||
|
||||
the unlocking fastpath is equally tight:
|
||||
|
||||
c0377cd1 <mutex_unlock>:
|
||||
c0377cd1: f0 ff 00 lock incl (%eax)
|
||||
c0377cd4: 7e 0f jle c0377ce5 <.text.lock.mutex+0x7>
|
||||
c0377cd4: 7e 0f jle c0377ce5 <.text..lock.mutex+0x7>
|
||||
c0377cd6: c3 ret
|
||||
|
||||
- 'struct mutex' semantics are well-defined and are enforced if
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
obj- := dummy.o
|
||||
|
||||
# List of programs to build
|
||||
hostprogs-y := hpet_example
|
||||
hostprogs-$(CONFIG_X86) := hpet_example
|
||||
|
||||
# Tell kbuild to always build the programs
|
||||
always := $(hostprogs-y)
|
||||
|
||||
@@ -176,5 +176,6 @@
|
||||
175 -> Leadtek Winfast DTV1000S [107d:6655]
|
||||
176 -> Beholder BeholdTV 505 RDS [0000:5051]
|
||||
177 -> Hawell HW-404M7
|
||||
179 -> Beholder BeholdTV H7 [5ace:7190]
|
||||
180 -> Beholder BeholdTV A7 [5ace:7090]
|
||||
178 -> Beholder BeholdTV H7 [5ace:7190]
|
||||
179 -> Beholder BeholdTV A7 [5ace:7090]
|
||||
180 -> Avermedia M733A [1461:4155,1461:4255]
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user