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 tag 'v3.16-rc6' into MTD development branch
Linux 3.16-rc6
This commit is contained in:
@@ -9,6 +9,10 @@
|
|||||||
Linus
|
Linus
|
||||||
----------
|
----------
|
||||||
|
|
||||||
|
M: Matt Mackal
|
||||||
|
E: mpm@selenic.com
|
||||||
|
D: SLOB slab allocator
|
||||||
|
|
||||||
N: Matti Aarnio
|
N: Matti Aarnio
|
||||||
E: mea@nic.funet.fi
|
E: mea@nic.funet.fi
|
||||||
D: Alpha systems hacking, IPv6 and other network related stuff
|
D: Alpha systems hacking, IPv6 and other network related stuff
|
||||||
|
|||||||
@@ -280,12 +280,9 @@ that is possible.
|
|||||||
mcelog
|
mcelog
|
||||||
------
|
------
|
||||||
|
|
||||||
In Linux 2.6.31+ the i386 kernel needs to run the mcelog utility
|
On x86 kernels the mcelog utility is needed to process and log machine check
|
||||||
as a regular cronjob similar to the x86-64 kernel to process and log
|
events when CONFIG_X86_MCE is enabled. Machine check events are errors reported
|
||||||
machine check events when CONFIG_X86_NEW_MCE is enabled. Machine check
|
by the CPU. Processing them is strongly encouraged.
|
||||||
events are errors reported by the CPU. Processing them is strongly encouraged.
|
|
||||||
All x86-64 kernels since 2.6.4 require the mcelog utility to
|
|
||||||
process machine checks.
|
|
||||||
|
|
||||||
Getting updated software
|
Getting updated software
|
||||||
========================
|
========================
|
||||||
|
|||||||
@@ -708,7 +708,7 @@ hardware level details could be very different.
|
|||||||
|
|
||||||
<para>Systems need specialized hardware support to implement OTG,
|
<para>Systems need specialized hardware support to implement OTG,
|
||||||
notably including a special <emphasis>Mini-AB</emphasis> jack
|
notably including a special <emphasis>Mini-AB</emphasis> jack
|
||||||
and associated transciever to support <emphasis>Dual-Role</emphasis>
|
and associated transceiver to support <emphasis>Dual-Role</emphasis>
|
||||||
operation:
|
operation:
|
||||||
they can act either as a host, using the standard
|
they can act either as a host, using the standard
|
||||||
Linux-USB host side driver stack,
|
Linux-USB host side driver stack,
|
||||||
|
|||||||
@@ -182,7 +182,7 @@
|
|||||||
<para>
|
<para>
|
||||||
Each interrupt is described by an interrupt descriptor structure
|
Each interrupt is described by an interrupt descriptor structure
|
||||||
irq_desc. The interrupt is referenced by an 'unsigned int' numeric
|
irq_desc. The interrupt is referenced by an 'unsigned int' numeric
|
||||||
value which selects the corresponding interrupt decription structure
|
value which selects the corresponding interrupt description structure
|
||||||
in the descriptor structures array.
|
in the descriptor structures array.
|
||||||
The descriptor structure contains status information and pointers
|
The descriptor structure contains status information and pointers
|
||||||
to the interrupt flow method and the interrupt chip structure
|
to the interrupt flow method and the interrupt chip structure
|
||||||
@@ -470,7 +470,7 @@ if (desc->irq_data.chip->irq_eoi)
|
|||||||
<para>
|
<para>
|
||||||
To avoid copies of identical implementations of IRQ chips the
|
To avoid copies of identical implementations of IRQ chips the
|
||||||
core provides a configurable generic interrupt chip
|
core provides a configurable generic interrupt chip
|
||||||
implementation. Developers should check carefuly whether the
|
implementation. Developers should check carefully whether the
|
||||||
generic chip fits their needs before implementing the same
|
generic chip fits their needs before implementing the same
|
||||||
functionality slightly differently themselves.
|
functionality slightly differently themselves.
|
||||||
</para>
|
</para>
|
||||||
|
|||||||
@@ -1760,7 +1760,7 @@ as it would be on UP.
|
|||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
There is a furthur optimization possible here: remember our original
|
There is a further optimization possible here: remember our original
|
||||||
cache code, where there were no reference counts and the caller simply
|
cache code, where there were no reference counts and the caller simply
|
||||||
held the lock whenever using the object? This is still possible: if
|
held the lock whenever using the object? This is still possible: if
|
||||||
you hold the lock, no one can delete the object, so you don't need to
|
you hold the lock, no one can delete the object, so you don't need to
|
||||||
|
|||||||
@@ -677,7 +677,7 @@ and other resources, etc.
|
|||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
ATA_QCFLAG_ACTIVE is clared from qc->flags.
|
ATA_QCFLAG_ACTIVE is cleared from qc->flags.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
@@ -708,7 +708,7 @@ and other resources, etc.
|
|||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
qc->waiting is claread & completed (in that order).
|
qc->waiting is cleared & completed (in that order).
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
@@ -1163,7 +1163,7 @@ and other resources, etc.
|
|||||||
|
|
||||||
<para>
|
<para>
|
||||||
Once sense data is acquired, this type of errors can be
|
Once sense data is acquired, this type of errors can be
|
||||||
handled similary to other SCSI errors. Note that sense data
|
handled similarly to other SCSI errors. Note that sense data
|
||||||
may indicate ATA bus error (e.g. Sense Key 04h HARDWARE ERROR
|
may indicate ATA bus error (e.g. Sense Key 04h HARDWARE ERROR
|
||||||
&& ASC/ASCQ 47h/00h SCSI PARITY ERROR). In such
|
&& ASC/ASCQ 47h/00h SCSI PARITY ERROR). In such
|
||||||
cases, the error should be considered as an ATA bus error and
|
cases, the error should be considered as an ATA bus error and
|
||||||
|
|||||||
@@ -202,8 +202,8 @@ $(MEDIA_OBJ_DIR)/%: $(MEDIA_SRC_DIR)/%.b64
|
|||||||
|
|
||||||
$(MEDIA_OBJ_DIR)/v4l2.xml: $(OBJIMGFILES)
|
$(MEDIA_OBJ_DIR)/v4l2.xml: $(OBJIMGFILES)
|
||||||
@$($(quiet)gen_xml)
|
@$($(quiet)gen_xml)
|
||||||
@(ln -sf $(MEDIA_SRC_DIR)/v4l/*xml $(MEDIA_OBJ_DIR)/)
|
@(ln -sf `cd $(MEDIA_SRC_DIR) && /bin/pwd`/v4l/*xml $(MEDIA_OBJ_DIR)/)
|
||||||
@(ln -sf $(MEDIA_SRC_DIR)/dvb/*xml $(MEDIA_OBJ_DIR)/)
|
@(ln -sf `cd $(MEDIA_SRC_DIR) && /bin/pwd`/dvb/*xml $(MEDIA_OBJ_DIR)/)
|
||||||
|
|
||||||
$(MEDIA_OBJ_DIR)/videodev2.h.xml: $(srctree)/include/uapi/linux/videodev2.h $(MEDIA_OBJ_DIR)/v4l2.xml
|
$(MEDIA_OBJ_DIR)/videodev2.h.xml: $(srctree)/include/uapi/linux/videodev2.h $(MEDIA_OBJ_DIR)/v4l2.xml
|
||||||
@$($(quiet)gen_xml)
|
@$($(quiet)gen_xml)
|
||||||
|
|||||||
@@ -68,7 +68,7 @@
|
|||||||
several digital tv standards. While it is called as DVB API,
|
several digital tv standards. While it is called as DVB API,
|
||||||
in fact it covers several different video standards including
|
in fact it covers several different video standards including
|
||||||
DVB-T, DVB-S, DVB-C and ATSC. The API is currently being updated
|
DVB-T, DVB-S, DVB-C and ATSC. The API is currently being updated
|
||||||
to documment support also for DVB-S2, ISDB-T and ISDB-S.</para>
|
to document support also for DVB-S2, ISDB-T and ISDB-S.</para>
|
||||||
<para>The third part covers the Remote Controller API.</para>
|
<para>The third part covers the Remote Controller API.</para>
|
||||||
<para>The fourth part covers the Media Controller API.</para>
|
<para>The fourth part covers the Media Controller API.</para>
|
||||||
<para>For additional information and for the latest development code,
|
<para>For additional information and for the latest development code,
|
||||||
|
|||||||
@@ -91,7 +91,7 @@
|
|||||||
<listitem><para>
|
<listitem><para>
|
||||||
[MTD Interface]</para><para>
|
[MTD Interface]</para><para>
|
||||||
These functions provide the interface to the MTD kernel API.
|
These functions provide the interface to the MTD kernel API.
|
||||||
They are not replacable and provide functionality
|
They are not replaceable and provide functionality
|
||||||
which is complete hardware independent.
|
which is complete hardware independent.
|
||||||
</para></listitem>
|
</para></listitem>
|
||||||
<listitem><para>
|
<listitem><para>
|
||||||
@@ -100,14 +100,14 @@
|
|||||||
</para></listitem>
|
</para></listitem>
|
||||||
<listitem><para>
|
<listitem><para>
|
||||||
[GENERIC]</para><para>
|
[GENERIC]</para><para>
|
||||||
Generic functions are not replacable and provide functionality
|
Generic functions are not replaceable and provide functionality
|
||||||
which is complete hardware independent.
|
which is complete hardware independent.
|
||||||
</para></listitem>
|
</para></listitem>
|
||||||
<listitem><para>
|
<listitem><para>
|
||||||
[DEFAULT]</para><para>
|
[DEFAULT]</para><para>
|
||||||
Default functions provide hardware related functionality which is suitable
|
Default functions provide hardware related functionality which is suitable
|
||||||
for most of the implementations. These functions can be replaced by the
|
for most of the implementations. These functions can be replaced by the
|
||||||
board driver if neccecary. Those functions are called via pointers in the
|
board driver if necessary. Those functions are called via pointers in the
|
||||||
NAND chip description structure. The board driver can set the functions which
|
NAND chip description structure. The board driver can set the functions which
|
||||||
should be replaced by board dependent functions before calling nand_scan().
|
should be replaced by board dependent functions before calling nand_scan().
|
||||||
If the function pointer is NULL on entry to nand_scan() then the pointer
|
If the function pointer is NULL on entry to nand_scan() then the pointer
|
||||||
@@ -264,7 +264,7 @@ static void board_hwcontrol(struct mtd_info *mtd, int cmd)
|
|||||||
is set up nand_scan() is called. This function tries to
|
is set up nand_scan() is called. This function tries to
|
||||||
detect and identify then chip. If a chip is found all the
|
detect and identify then chip. If a chip is found all the
|
||||||
internal data fields are initialized accordingly.
|
internal data fields are initialized accordingly.
|
||||||
The structure(s) have to be zeroed out first and then filled with the neccecary
|
The structure(s) have to be zeroed out first and then filled with the necessary
|
||||||
information about the device.
|
information about the device.
|
||||||
</para>
|
</para>
|
||||||
<programlisting>
|
<programlisting>
|
||||||
@@ -327,7 +327,7 @@ module_init(board_init);
|
|||||||
<sect1 id="Exit_function">
|
<sect1 id="Exit_function">
|
||||||
<title>Exit function</title>
|
<title>Exit function</title>
|
||||||
<para>
|
<para>
|
||||||
The exit function is only neccecary if the driver is
|
The exit function is only necessary if the driver is
|
||||||
compiled as a module. It releases all resources which
|
compiled as a module. It releases all resources which
|
||||||
are held by the chip driver and unregisters the partitions
|
are held by the chip driver and unregisters the partitions
|
||||||
in the MTD layer.
|
in the MTD layer.
|
||||||
@@ -494,7 +494,7 @@ static void board_select_chip (struct mtd_info *mtd, int chip)
|
|||||||
in this case. See rts_from4.c and diskonchip.c for
|
in this case. See rts_from4.c and diskonchip.c for
|
||||||
implementation reference. In those cases we must also
|
implementation reference. In those cases we must also
|
||||||
use bad block tables on FLASH, because the ECC layout is
|
use bad block tables on FLASH, because the ECC layout is
|
||||||
interferring with the bad block marker positions.
|
interfering with the bad block marker positions.
|
||||||
See bad block table support for details.
|
See bad block table support for details.
|
||||||
</para>
|
</para>
|
||||||
</sect2>
|
</sect2>
|
||||||
@@ -542,7 +542,7 @@ static void board_select_chip (struct mtd_info *mtd, int chip)
|
|||||||
<para>
|
<para>
|
||||||
nand_scan() calls the function nand_default_bbt().
|
nand_scan() calls the function nand_default_bbt().
|
||||||
nand_default_bbt() selects appropriate default
|
nand_default_bbt() selects appropriate default
|
||||||
bad block table desriptors depending on the chip information
|
bad block table descriptors depending on the chip information
|
||||||
which was retrieved by nand_scan().
|
which was retrieved by nand_scan().
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
@@ -554,7 +554,7 @@ static void board_select_chip (struct mtd_info *mtd, int chip)
|
|||||||
<sect2 id="Flash_based_tables">
|
<sect2 id="Flash_based_tables">
|
||||||
<title>Flash based tables</title>
|
<title>Flash based tables</title>
|
||||||
<para>
|
<para>
|
||||||
It may be desired or neccecary to keep a bad block table in FLASH.
|
It may be desired or necessary to keep a bad block table in FLASH.
|
||||||
For AG-AND chips this is mandatory, as they have no factory marked
|
For AG-AND chips this is mandatory, as they have no factory marked
|
||||||
bad blocks. They have factory marked good blocks. The marker pattern
|
bad blocks. They have factory marked good blocks. The marker pattern
|
||||||
is erased when the block is erased to be reused. So in case of
|
is erased when the block is erased to be reused. So in case of
|
||||||
@@ -565,10 +565,10 @@ static void board_select_chip (struct mtd_info *mtd, int chip)
|
|||||||
of the blocks.
|
of the blocks.
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
The blocks in which the tables are stored are procteted against
|
The blocks in which the tables are stored are protected against
|
||||||
accidental access by marking them bad in the memory bad block
|
accidental access by marking them bad in the memory bad block
|
||||||
table. The bad block table management functions are allowed
|
table. The bad block table management functions are allowed
|
||||||
to circumvernt this protection.
|
to circumvent this protection.
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
The simplest way to activate the FLASH based bad block table support
|
The simplest way to activate the FLASH based bad block table support
|
||||||
@@ -592,7 +592,7 @@ static void board_select_chip (struct mtd_info *mtd, int chip)
|
|||||||
User defined tables are created by filling out a
|
User defined tables are created by filling out a
|
||||||
nand_bbt_descr structure and storing the pointer in the
|
nand_bbt_descr structure and storing the pointer in the
|
||||||
nand_chip structure member bbt_td before calling nand_scan().
|
nand_chip structure member bbt_td before calling nand_scan().
|
||||||
If a mirror table is neccecary a second structure must be
|
If a mirror table is necessary a second structure must be
|
||||||
created and a pointer to this structure must be stored
|
created and a pointer to this structure must be stored
|
||||||
in bbt_md inside the nand_chip structure. If the bbt_md
|
in bbt_md inside the nand_chip structure. If the bbt_md
|
||||||
member is set to NULL then only the main table is used
|
member is set to NULL then only the main table is used
|
||||||
@@ -666,7 +666,7 @@ static void board_select_chip (struct mtd_info *mtd, int chip)
|
|||||||
<para>
|
<para>
|
||||||
For automatic placement some blocks must be reserved for
|
For automatic placement some blocks must be reserved for
|
||||||
bad block table storage. The number of reserved blocks is defined
|
bad block table storage. The number of reserved blocks is defined
|
||||||
in the maxblocks member of the babd block table description structure.
|
in the maxblocks member of the bad block table description structure.
|
||||||
Reserving 4 blocks for mirrored tables should be a reasonable number.
|
Reserving 4 blocks for mirrored tables should be a reasonable number.
|
||||||
This also limits the number of blocks which are scanned for the bad
|
This also limits the number of blocks which are scanned for the bad
|
||||||
block table ident pattern.
|
block table ident pattern.
|
||||||
@@ -1068,11 +1068,11 @@ in this page</entry>
|
|||||||
<chapter id="filesystems">
|
<chapter id="filesystems">
|
||||||
<title>Filesystem support</title>
|
<title>Filesystem support</title>
|
||||||
<para>
|
<para>
|
||||||
The NAND driver provides all neccecary functions for a
|
The NAND driver provides all necessary functions for a
|
||||||
filesystem via the MTD interface.
|
filesystem via the MTD interface.
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
Filesystems must be aware of the NAND pecularities and
|
Filesystems must be aware of the NAND peculiarities and
|
||||||
restrictions. One major restrictions of NAND Flash is, that you cannot
|
restrictions. One major restrictions of NAND Flash is, that you cannot
|
||||||
write as often as you want to a page. The consecutive writes to a page,
|
write as often as you want to a page. The consecutive writes to a page,
|
||||||
before erasing it again, are restricted to 1-3 writes, depending on the
|
before erasing it again, are restricted to 1-3 writes, depending on the
|
||||||
@@ -1222,7 +1222,7 @@ in this page</entry>
|
|||||||
#define NAND_BBT_VERSION 0x00000100
|
#define NAND_BBT_VERSION 0x00000100
|
||||||
/* Create a bbt if none axists */
|
/* Create a bbt if none axists */
|
||||||
#define NAND_BBT_CREATE 0x00000200
|
#define NAND_BBT_CREATE 0x00000200
|
||||||
/* Write bbt if neccecary */
|
/* Write bbt if necessary */
|
||||||
#define NAND_BBT_WRITE 0x00001000
|
#define NAND_BBT_WRITE 0x00001000
|
||||||
/* Read and write back block contents when writing bbt */
|
/* Read and write back block contents when writing bbt */
|
||||||
#define NAND_BBT_SAVECONTENT 0x00002000
|
#define NAND_BBT_SAVECONTENT 0x00002000
|
||||||
|
|||||||
@@ -155,7 +155,7 @@
|
|||||||
release regulators. Functions are
|
release regulators. Functions are
|
||||||
provided to <link linkend='API-regulator-enable'>enable</link>
|
provided to <link linkend='API-regulator-enable'>enable</link>
|
||||||
and <link linkend='API-regulator-disable'>disable</link> the
|
and <link linkend='API-regulator-disable'>disable</link> the
|
||||||
reguator and to get and set the runtime parameters of the
|
regulator and to get and set the runtime parameters of the
|
||||||
regulator.
|
regulator.
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
|
|||||||
@@ -766,10 +766,10 @@ framework to set up sysfs files for this region. Simply leave it alone.
|
|||||||
<para>
|
<para>
|
||||||
The dynamic memory regions will be allocated when the UIO device file,
|
The dynamic memory regions will be allocated when the UIO device file,
|
||||||
<varname>/dev/uioX</varname> is opened.
|
<varname>/dev/uioX</varname> is opened.
|
||||||
Simiar to static memory resources, the memory region information for
|
Similar to static memory resources, the memory region information for
|
||||||
dynamic regions is then visible via sysfs at
|
dynamic regions is then visible via sysfs at
|
||||||
<varname>/sys/class/uio/uioX/maps/mapY/*</varname>.
|
<varname>/sys/class/uio/uioX/maps/mapY/*</varname>.
|
||||||
The dynmaic memory regions will be freed when the UIO device file is
|
The dynamic memory regions will be freed when the UIO device file is
|
||||||
closed. When no processes are holding the device file open, the address
|
closed. When no processes are holding the device file open, the address
|
||||||
returned to userspace is ~0.
|
returned to userspace is ~0.
|
||||||
</para>
|
</para>
|
||||||
|
|||||||
@@ -153,7 +153,7 @@
|
|||||||
|
|
||||||
<listitem><para>The Linux USB API supports synchronous calls for
|
<listitem><para>The Linux USB API supports synchronous calls for
|
||||||
control and bulk messages.
|
control and bulk messages.
|
||||||
It also supports asynchnous calls for all kinds of data transfer,
|
It also supports asynchronous calls for all kinds of data transfer,
|
||||||
using request structures called "URBs" (USB Request Blocks).
|
using request structures called "URBs" (USB Request Blocks).
|
||||||
</para></listitem>
|
</para></listitem>
|
||||||
|
|
||||||
|
|||||||
@@ -5696,7 +5696,7 @@ struct _snd_pcm_runtime {
|
|||||||
suspending the PCM operations via
|
suspending the PCM operations via
|
||||||
<function>snd_pcm_suspend_all()</function> or
|
<function>snd_pcm_suspend_all()</function> or
|
||||||
<function>snd_pcm_suspend()</function>. It means that the PCM
|
<function>snd_pcm_suspend()</function>. It means that the PCM
|
||||||
streams are already stoppped when the register snapshot is
|
streams are already stopped when the register snapshot is
|
||||||
taken. But, remember that you don't have to restart the PCM
|
taken. But, remember that you don't have to restart the PCM
|
||||||
stream in the resume callback. It'll be restarted via
|
stream in the resume callback. It'll be restarted via
|
||||||
trigger call with <constant>SNDRV_PCM_TRIGGER_RESUME</constant>
|
trigger call with <constant>SNDRV_PCM_TRIGGER_RESUME</constant>
|
||||||
|
|||||||
@@ -314,6 +314,7 @@ int main(int argc, char *argv[])
|
|||||||
break;
|
break;
|
||||||
case 'm':
|
case 'm':
|
||||||
strncpy(cpumask, optarg, sizeof(cpumask));
|
strncpy(cpumask, optarg, sizeof(cpumask));
|
||||||
|
cpumask[sizeof(cpumask) - 1] = '\0';
|
||||||
maskset = 1;
|
maskset = 1;
|
||||||
printf("cpumask %s maskset %d\n", cpumask, maskset);
|
printf("cpumask %s maskset %d\n", cpumask, maskset);
|
||||||
break;
|
break;
|
||||||
|
|||||||
@@ -60,12 +60,6 @@ If the driver needs to perform more complex initialization like getting and
|
|||||||
configuring GPIOs it can get its ACPI handle and extract this information
|
configuring GPIOs it can get its ACPI handle and extract this information
|
||||||
from ACPI tables.
|
from ACPI tables.
|
||||||
|
|
||||||
Currently the kernel is not able to automatically determine from which ACPI
|
|
||||||
device it should make the corresponding platform device so we need to add
|
|
||||||
the ACPI device explicitly to acpi_platform_device_ids list defined in
|
|
||||||
drivers/acpi/acpi_platform.c. This limitation is only for the platform
|
|
||||||
devices, SPI and I2C devices are created automatically as described below.
|
|
||||||
|
|
||||||
DMA support
|
DMA support
|
||||||
~~~~~~~~~~~
|
~~~~~~~~~~~
|
||||||
DMA controllers enumerated via ACPI should be registered in the system to
|
DMA controllers enumerated via ACPI should be registered in the system to
|
||||||
|
|||||||
@@ -15,10 +15,13 @@ New sysfs files for controlling P state selection have been added to
|
|||||||
/sys/devices/system/cpu/intel_pstate/
|
/sys/devices/system/cpu/intel_pstate/
|
||||||
|
|
||||||
max_perf_pct: limits the maximum P state that will be requested by
|
max_perf_pct: limits the maximum P state that will be requested by
|
||||||
the driver stated as a percentage of the available performance.
|
the driver stated as a percentage of the available performance. The
|
||||||
|
available (P states) performance may be reduced by the no_turbo
|
||||||
|
setting described below.
|
||||||
|
|
||||||
min_perf_pct: limits the minimum P state that will be requested by
|
min_perf_pct: limits the minimum P state that will be requested by
|
||||||
the driver stated as a percentage of the available performance.
|
the driver stated as a percentage of the max (non-turbo)
|
||||||
|
performance level.
|
||||||
|
|
||||||
no_turbo: limits the driver to selecting P states below the turbo
|
no_turbo: limits the driver to selecting P states below the turbo
|
||||||
frequency range.
|
frequency range.
|
||||||
|
|||||||
@@ -6,5 +6,15 @@ following property:
|
|||||||
|
|
||||||
Required root node property:
|
Required root node property:
|
||||||
|
|
||||||
- compatible: must contain either "marvell,armada380" or
|
- compatible: must contain "marvell,armada380"
|
||||||
"marvell,armada385" depending on the variant of the SoC being used.
|
|
||||||
|
In addition, boards using the Marvell Armada 385 SoC shall have the
|
||||||
|
following property before the previous one:
|
||||||
|
|
||||||
|
Required root node property:
|
||||||
|
|
||||||
|
compatible: must contain "marvell,armada385"
|
||||||
|
|
||||||
|
Example:
|
||||||
|
|
||||||
|
compatible = "marvell,a385-rd", "marvell,armada385", "marvell,armada380";
|
||||||
|
|||||||
@@ -9,6 +9,18 @@ Required Properties:
|
|||||||
- reg: physical base address of the controller and length of memory mapped
|
- reg: physical base address of the controller and length of memory mapped
|
||||||
region.
|
region.
|
||||||
|
|
||||||
|
Optional Properties:
|
||||||
|
- clocks: List of clock handles. The parent clocks of the input clocks to the
|
||||||
|
devices in this power domain are set to oscclk before power gating
|
||||||
|
and restored back after powering on a domain. This is required for
|
||||||
|
all domains which are powered on and off and not required for unused
|
||||||
|
domains.
|
||||||
|
- clock-names: The following clocks can be specified:
|
||||||
|
- oscclk: Oscillator clock.
|
||||||
|
- pclkN, clkN: Pairs of parent of input clock and input clock to the
|
||||||
|
devices in this power domain. Maximum of 4 pairs (N = 0 to 3)
|
||||||
|
are supported currently.
|
||||||
|
|
||||||
Node of a device using power domains must have a samsung,power-domain property
|
Node of a device using power domains must have a samsung,power-domain property
|
||||||
defined with a phandle to respective power domain.
|
defined with a phandle to respective power domain.
|
||||||
|
|
||||||
@@ -19,6 +31,14 @@ Example:
|
|||||||
reg = <0x10023C00 0x10>;
|
reg = <0x10023C00 0x10>;
|
||||||
};
|
};
|
||||||
|
|
||||||
|
mfc_pd: power-domain@10044060 {
|
||||||
|
compatible = "samsung,exynos4210-pd";
|
||||||
|
reg = <0x10044060 0x20>;
|
||||||
|
clocks = <&clock CLK_FIN_PLL>, <&clock CLK_MOUT_SW_ACLK333>,
|
||||||
|
<&clock CLK_MOUT_USER_ACLK333>;
|
||||||
|
clock-names = "oscclk", "pclk0", "clk0";
|
||||||
|
};
|
||||||
|
|
||||||
Example of the node using power domain:
|
Example of the node using power domain:
|
||||||
|
|
||||||
node {
|
node {
|
||||||
|
|||||||
@@ -40,6 +40,9 @@ Optional properties:
|
|||||||
- arm,filter-ranges : <start length> Starting address and length of window to
|
- arm,filter-ranges : <start length> Starting address and length of window to
|
||||||
filter. Addresses in the filter window are directed to the M1 port. Other
|
filter. Addresses in the filter window are directed to the M1 port. Other
|
||||||
addresses will go to the M0 port.
|
addresses will go to the M0 port.
|
||||||
|
- arm,io-coherent : indicates that the system is operating in an hardware
|
||||||
|
I/O coherent mode. Valid only when the arm,pl310-cache compatible
|
||||||
|
string is used.
|
||||||
- interrupts : 1 combined interrupt.
|
- interrupts : 1 combined interrupt.
|
||||||
- cache-id-part: cache id part number to be used if it is not present
|
- cache-id-part: cache id part number to be used if it is not present
|
||||||
on hardware
|
on hardware
|
||||||
|
|||||||
@@ -48,7 +48,7 @@ adc@12D10000 {
|
|||||||
|
|
||||||
/* NTC thermistor is a hwmon device */
|
/* NTC thermistor is a hwmon device */
|
||||||
ncp15wb473@0 {
|
ncp15wb473@0 {
|
||||||
compatible = "ntc,ncp15wb473";
|
compatible = "murata,ncp15wb473";
|
||||||
pullup-uv = <1800000>;
|
pullup-uv = <1800000>;
|
||||||
pullup-ohm = <47000>;
|
pullup-ohm = <47000>;
|
||||||
pulldown-ohm = <0>;
|
pulldown-ohm = <0>;
|
||||||
|
|||||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user