apfs/linux-apfs
0
0
Fork 0
mirror of https://github.com/linux-apfs/linux-apfs.git synced 2026-05-01 15:00:59 -07:00
Code Issues Packages Projects Releases Wiki Activity

Merge remote-tracking branch 'net-next/master' into mac80211-next

Browse Source 
This brings in commit 7a7c0a6438 ("mac80211: fix TX aggregation
start/stop callback race") to allow the follow-up cleanup.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This commit is contained in:
Johannes Berg
2017-06-08 14:14:40 +02:00
parent 5d473fedd1 50dffe7fad
commit a43e61842e
1509 changed files with 43667 additions and 20474 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Documentation/ABI/testing/sysfs-class-net
+8
View File
@@ -251,3 +251,11 @@ Contact: netdev@vger.kernel.org
Description:
Indicates the unique physical switch identifier of a switch this
port belongs to, as a string.
What: /sys/class/net/<iface>/phydev
Date: May 2017
KernelVersion: 4.13
Contact: netdev@vger.kernel.org
Description:
Symbolic link to the PHY device this network device is attached
to.
Documentation/ABI/testing/sysfs-class-net-phydev
+36
View File
@@ -0,0 +1,36 @@
What: /sys/class/mdio_bus/<bus>/<device>/attached_dev
Date: May 2017
KernelVersion: 4.13
Contact: netdev@vger.kernel.org
Description:
Symbolic link to the network device this PHY device is
attached to.
What: /sys/class/mdio_bus/<bus>/<device>/phy_has_fixups
Date: February 2014
KernelVersion: 3.15
Contact: netdev@vger.kernel.org
Description:
Boolean value indicating whether the PHY device has
any fixups registered against it (phy_register_fixup)
What: /sys/class/mdio_bus/<bus>/<device>/phy_id
Date: November 2012
KernelVersion: 3.8
Contact: netdev@vger.kernel.org
Description:
32-bit hexadecimal value corresponding to the PHY device's OUI,
model and revision number.
What: /sys/class/mdio_bus/<bus>/<device>/phy_interface
Date: February 2014
KernelVersion: 3.15
Contact: netdev@vger.kernel.org
Description:
String value indicating the PHY interface, possible
values are:.
<empty> (not available), mii, gmii, sgmii, tbi, rev-mii,
rmii, rgmii, rgmii-id, rgmii-rxid, rgmii-txid, rtbi, smii
xgmii, moca, qsgmii, trgmii, 1000base-x, 2500base-x, rxaui,
xaui, 10gbase-kr, unknown
Documentation/acpi/acpi-lid.txt
+12 -4
View File
@@ -59,20 +59,28 @@ button driver uses the following 3 modes in order not to trigger issues.
If the userspace hasn't been prepared to ignore the unreliable "opened"
events and the unreliable initial state notification, Linux users can use
the following kernel parameters to handle the possible issues:
A. button.lid_init_state=open:
A. button.lid_init_state=method:
When this option is specified, the ACPI button driver reports the
initial lid state using the returning value of the _LID control method
and whether the "opened"/"closed" events are paired fully relies on the
firmware implementation.
This option can be used to fix some platforms where the returning value
of the _LID control method is reliable but the initial lid state
notification is missing.
This option is the default behavior during the period the userspace
isn't ready to handle the buggy AML tables.
B. button.lid_init_state=open:
When this option is specified, the ACPI button driver always reports the
initial lid state as "opened" and whether the "opened"/"closed" events
are paired fully relies on the firmware implementation.
This may fix some platforms where the returning value of the _LID
control method is not reliable and the initial lid state notification is
missing.
This option is the default behavior during the period the userspace
isn't ready to handle the buggy AML tables.
If the userspace has been prepared to ignore the unreliable "opened" events
and the unreliable initial state notification, Linux users should always
use the following kernel parameter:
B. button.lid_init_state=ignore:
C. button.lid_init_state=ignore:
When this option is specified, the ACPI button driver never reports the
initial lid state and there is a compensation mechanism implemented to
ensure that the reliable "closed" notifications can always be delievered
Documentation/admin-guide/pm/cpufreq.rst
+10 -9
View File
@@ -1,4 +1,5 @@
.. |struct cpufreq_policy| replace:: :c:type:`struct cpufreq_policy <cpufreq_policy>`
.. |intel_pstate| replace:: :doc:`intel_pstate <intel_pstate>`
=======================
CPU Performance Scaling
@@ -75,7 +76,7 @@ feedback registers, as that information is typically specific to the hardware
interface it comes from and may not be easily represented in an abstract,
platform-independent way. For this reason, ``CPUFreq`` allows scaling drivers
to bypass the governor layer and implement their own performance scaling
algorithms. That is done by the ``intel_pstate`` scaling driver.
algorithms. That is done by the |intel_pstate| scaling driver.
``CPUFreq`` Policy Objects
@@ -174,13 +175,13 @@ necessary to restart the scaling governor so that it can take the new online CPU
into account. That is achieved by invoking the governor's ``->stop`` and
``->start()`` callbacks, in this order, for the entire policy.
As mentioned before, the ``intel_pstate`` scaling driver bypasses the scaling
As mentioned before, the |intel_pstate| scaling driver bypasses the scaling
governor layer of ``CPUFreq`` and provides its own P-state selection algorithms.
Consequently, if ``intel_pstate`` is used, scaling governors are not attached to
Consequently, if |intel_pstate| is used, scaling governors are not attached to
new policy objects. Instead, the driver's ``->setpolicy()`` callback is invoked
to register per-CPU utilization update callbacks for each policy. These
callbacks are invoked by the CPU scheduler in the same way as for scaling
governors, but in the ``intel_pstate`` case they both determine the P-state to
governors, but in the |intel_pstate| case they both determine the P-state to
use and change the hardware configuration accordingly in one go from scheduler
context.
@@ -257,7 +258,7 @@ are the following:
``scaling_available_governors``
List of ``CPUFreq`` scaling governors present in the kernel that can
be attached to this policy or (if the ``intel_pstate`` scaling driver is
be attached to this policy or (if the |intel_pstate| scaling driver is
in use) list of scaling algorithms provided by the driver that can be
applied to this policy.
@@ -274,7 +275,7 @@ are the following:
the CPU is actually running at (due to hardware design and other
limitations).
Some scaling drivers (e.g. ``intel_pstate``) attempt to provide
Some scaling drivers (e.g. |intel_pstate|) attempt to provide
information more precisely reflecting the current CPU frequency through
this attribute, but that still may not be the exact current CPU
frequency as seen by the hardware at the moment.
@@ -284,13 +285,13 @@ are the following:
``scaling_governor``
The scaling governor currently attached to this policy or (if the
``intel_pstate`` scaling driver is in use) the scaling algorithm
|intel_pstate| scaling driver is in use) the scaling algorithm
provided by the driver that is currently applied to this policy.
This attribute is read-write and writing to it will cause a new scaling
governor to be attached to this policy or a new scaling algorithm
provided by the scaling driver to be applied to it (in the
``intel_pstate`` case), as indicated by the string written to this
|intel_pstate| case), as indicated by the string written to this
attribute (which must be one of the names listed by the
``scaling_available_governors`` attribute described above).
@@ -619,7 +620,7 @@ This file is located under :file:`/sys/devices/system/cpu/cpufreq/` and controls
the "boost" setting for the whole system. It is not present if the underlying
scaling driver does not support the frequency boost mechanism (or supports it,
but provides a driver-specific interface for controlling it, like
``intel_pstate``).
|intel_pstate|).
If the value in this file is 1, the frequency boost mechanism is enabled. This
means that either the hardware can be put into states in which it is able to
Documentation/admin-guide/pm/index.rst
+1
View File
@@ -6,6 +6,7 @@ Power Management
:maxdepth: 2
cpufreq
intel_pstate
.. only:: subproject and html
Documentation/admin-guide/pm/intel_pstate.rst
+755
View File
File diff suppressed because it is too large Load Diff
Documentation/cpu-freq/intel-pstate.txt
-281
View File
@@ -1,281 +0,0 @@
Intel P-State driver
--------------------
This driver provides an interface to control the P-State selection for the
SandyBridge+ Intel processors.
The following document explains P-States:
http://events.linuxfoundation.org/sites/events/files/slides/LinuxConEurope_2015.pdf
As stated in the document, P-State doesn’t exactly mean a frequency. However, for
the sake of the relationship with cpufreq, P-State and frequency are used
interchangeably.
Understanding the cpufreq core governors and policies are important before
discussing more details about the Intel P-State driver. Based on what callbacks
a cpufreq driver provides to the cpufreq core, it can support two types of
drivers:
- with target_index() callback: In this mode, the drivers using cpufreq core
simply provide the minimum and maximum frequency limits and an additional
interface target_index() to set the current frequency. The cpufreq subsystem
has a number of scaling governors ("performance", "powersave", "ondemand",
etc.). Depending on which governor is in use, cpufreq core will call for
transitions to a specific frequency using target_index() callback.
- setpolicy() callback: In this mode, drivers do not provide target_index()
callback, so cpufreq core can't request a transition to a specific frequency.
The driver provides minimum and maximum frequency limits and callbacks to set a
policy. The policy in cpufreq sysfs is referred to as the "scaling governor".
The cpufreq core can request the driver to operate in any of the two policies:
"performance" and "powersave". The driver decides which frequency to use based
on the above policy selection considering minimum and maximum frequency limits.
The Intel P-State driver falls under the latter category, which implements the
setpolicy() callback. This driver decides what P-State to use based on the
requested policy from the cpufreq core. If the processor is capable of
selecting its next P-State internally, then the driver will offload this
responsibility to the processor (aka HWP: Hardware P-States). If not, the
driver implements algorithms to select the next P-State.
Since these policies are implemented in the driver, they are not same as the
cpufreq scaling governors implementation, even if they have the same name in
the cpufreq sysfs (scaling_governors). For example the "performance" policy is
similar to cpufreq’s "performance" governor, but "powersave" is completely
different than the cpufreq "powersave" governor. The strategy here is similar
to cpufreq "ondemand", where the requested P-State is related to the system load.
Sysfs Interface
In addition to the frequency-controlling interfaces provided by the cpufreq
core, the driver provides its own sysfs files to control the P-State selection.
These files have been added to /sys/devices/system/cpu/intel_pstate/.
Any changes made to these files are applicable to all CPUs (even in a
multi-package system, Refer to later section on placing "Per-CPU limits").
max_perf_pct: Limits the maximum P-State that will be requested by
the driver. It states it as a percentage of the available performance. The
available (P-State) performance may be reduced by the no_turbo
setting described below.
min_perf_pct: Limits the minimum P-State that will be requested by
the driver. It states it as a percentage of the max (non-turbo)
performance level.
no_turbo: Limits the driver to selecting P-State below the turbo
frequency range.
turbo_pct: Displays the percentage of the total performance that
is supported by hardware that is in the turbo range. This number
is independent of whether turbo has been disabled or not.
num_pstates: Displays the number of P-States that are supported
by hardware. This number is independent of whether turbo has
been disabled or not.
For example, if a system has these parameters:
Max 1 core turbo ratio: 0x21 (Max 1 core ratio is the maximum P-State)
Max non turbo ratio: 0x17
Minimum ratio : 0x08 (Here the ratio is called max efficiency ratio)
Sysfs will show :
max_perf_pct:100, which corresponds to 1 core ratio
min_perf_pct:24, max_efficiency_ratio / max 1 Core ratio
no_turbo:0, turbo is not disabled
num_pstates:26 = (max 1 Core ratio - Max Efficiency Ratio + 1)
turbo_pct:39 = (max 1 core ratio - max non turbo ratio) / num_pstates
Refer to "Intel® 64 and IA-32 Architectures Software Developer’s Manual
Volume 3: System Programming Guide" to understand ratios.
There is one more sysfs attribute in /sys/devices/system/cpu/intel_pstate/
that can be used for controlling the operation mode of the driver:
status: Three settings are possible:
"off" - The driver is not in use at this time.
"active" - The driver works as a P-state governor (default).
"passive" - The driver works as a regular cpufreq one and collaborates
with the generic cpufreq governors (it sets P-states as
requested by those governors).
The current setting is returned by reads from this attribute. Writing one
of the above strings to it changes the operation mode as indicated by that
string, if possible. If HW-managed P-states (HWP) are enabled, it is not
possible to change the driver's operation mode and attempts to write to
this attribute will fail.
cpufreq sysfs for Intel P-State
Since this driver registers with cpufreq, cpufreq sysfs is also presented.
There are some important differences, which need to be considered.
scaling_cur_freq: This displays the real frequency which was used during
the last sample period instead of what is requested. Some other cpufreq driver,
like acpi-cpufreq, displays what is requested (Some changes are on the
way to fix this for acpi-cpufreq driver). The same is true for frequencies
displayed at /proc/cpuinfo.
scaling_governor: This displays current active policy. Since each CPU has a
cpufreq sysfs, it is possible to set a scaling governor to each CPU. But this
is not possible with Intel P-States, as there is one common policy for all
CPUs. Here, the last requested policy will be applicable to all CPUs. It is
suggested that one use the cpupower utility to change policy to all CPUs at the
same time.
scaling_setspeed: This attribute can never be used with Intel P-State.
scaling_max_freq/scaling_min_freq: This interface can be used similarly to
the max_perf_pct/min_perf_pct of Intel P-State sysfs. However since frequencies
are converted to nearest possible P-State, this is prone to rounding errors.
This method is not preferred to limit performance.
affected_cpus: Not used
related_cpus: Not used
For contemporary Intel processors, the frequency is controlled by the
processor itself and the P-State exposed to software is related to
performance levels. The idea that frequency can be set to a single
frequency is fictional for Intel Core processors. Even if the scaling
driver selects a single P-State, the actual frequency the processor
will run at is selected by the processor itself.
Per-CPU limits
The kernel command line option "intel_pstate=per_cpu_perf_limits" forces
the intel_pstate driver to use per-CPU performance limits. When it is set,
the sysfs control interface described above is subject to limitations.
- The following controls are not available for both read and write
/sys/devices/system/cpu/intel_pstate/max_perf_pct
/sys/devices/system/cpu/intel_pstate/min_perf_pct
- The following controls can be used to set performance limits, as far as the
architecture of the processor permits:
/sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq
/sys/devices/system/cpu/cpu*/cpufreq/scaling_min_freq
/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
- User can still observe turbo percent and number of P-States from
/sys/devices/system/cpu/intel_pstate/turbo_pct
/sys/devices/system/cpu/intel_pstate/num_pstates
- User can read write system wide turbo status
/sys/devices/system/cpu/no_turbo
Support of energy performance hints
It is possible to provide hints to the HWP algorithms in the processor
to be more performance centric to more energy centric. When the driver
is using HWP, two additional cpufreq sysfs attributes are presented for
each logical CPU.
These attributes are:
- energy_performance_available_preferences
- energy_performance_preference
To get list of supported hints:
$ cat energy_performance_available_preferences
default performance balance_performance balance_power power
The current preference can be read or changed via cpufreq sysfs
attribute "energy_performance_preference". Reading from this attribute
will display current effective setting. User can write any of the valid
preference string to this attribute. User can always restore to power-on
default by writing "default".
Since threads can migrate to different CPUs, this is possible that the
new CPU may have different energy performance preference than the previous
one. To avoid such issues, either threads can be pinned to specific CPUs
or set the same energy performance preference value to all CPUs.
Tuning Intel P-State driver
When the performance can be tuned using PID (Proportional Integral
Derivative) controller, debugfs files are provided for adjusting performance.
They are presented under:
/sys/kernel/debug/pstate_snb/
The PID tunable parameters are:
deadband
d_gain_pct
i_gain_pct
p_gain_pct
sample_rate_ms
setpoint
To adjust these parameters, some understanding of driver implementation is
necessary. There are some tweeks described here, but be very careful. Adjusting
them requires expert level understanding of power and performance relationship.
These limits are only useful when the "powersave" policy is active.
-To make the system more responsive to load changes, sample_rate_ms can
be adjusted (current default is 10ms).
-To make the system use higher performance, even if the load is lower, setpoint
can be adjusted to a lower number. This will also lead to faster ramp up time
to reach the maximum P-State.
If there are no derivative and integral coefficients, The next P-State will be
equal to:
current P-State - ((setpoint - current cpu load) * p_gain_pct)
For example, if the current PID parameters are (Which are defaults for the core
processors like SandyBridge):
deadband = 0
d_gain_pct = 0
i_gain_pct = 0
p_gain_pct = 20
sample_rate_ms = 10
setpoint = 97
If the current P-State = 0x08 and current load = 100, this will result in the
next P-State = 0x08 - ((97 - 100) * 0.2) = 8.6 (rounded to 9). Here the P-State
goes up by only 1. If during next sample interval the current load doesn't
change and still 100, then P-State goes up by one again. This process will
continue as long as the load is more than the setpoint until the maximum P-State
is reached.
For the same load at setpoint = 60, this will result in the next P-State
= 0x08 - ((60 - 100) * 0.2) = 16
So by changing the setpoint from 97 to 60, there is an increase of the
next P-State from 9 to 16. So this will make processor execute at higher
P-State for the same CPU load. If the load continues to be more than the
setpoint during next sample intervals, then P-State will go up again till the
maximum P-State is reached. But the ramp up time to reach the maximum P-State
will be much faster when the setpoint is 60 compared to 97.
Debugging Intel P-State driver
Event tracing
To debug P-State transition, the Linux event tracing interface can be used.
There are two specific events, which can be enabled (Provided the kernel
configs related to event tracing are enabled).
# cd /sys/kernel/debug/tracing/
# echo 1 > events/power/pstate_sample/enable
# echo 1 > events/power/cpu_frequency/enable
# cat trace
gnome-terminal--4510 [001] ..s. 1177.680733: pstate_sample: core_busy=107
scaled=94 from=26 to=26 mperf=1143818 aperf=1230607 tsc=29838618
freq=2474476
cat-5235 [002] ..s. 1177.681723: cpu_frequency: state=2900000 cpu_id=2
Using ftrace
If function level tracing is required, the Linux ftrace interface can be used.
For example if we want to check how often a function to set a P-State is
called, we can set ftrace filter to intel_pstate_set_pstate.
# cd /sys/kernel/debug/tracing/
# cat available_filter_functions | grep -i pstate
intel_pstate_set_pstate
intel_pstate_cpu_init
...
# echo intel_pstate_set_pstate > set_ftrace_filter
# echo function > current_tracer
# cat trace | head -15
# tracer: function
#
# entries-in-buffer/entries-written: 80/80 #P:4
#
# _-----=> irqs-off
# / _----=> need-resched
# | / _---=> hardirq/softirq
# || / _--=> preempt-depth
# ||| / delay
# TASK-PID CPU# |||| TIMESTAMP FUNCTION
# | | | |||| | |
Xorg-3129 [000] ..s. 2537.644844: intel_pstate_set_pstate <-intel_pstate_timer_func
gnome-terminal--4510 [002] ..s. 2537.649844: intel_pstate_set_pstate <-intel_pstate_timer_func
gnome-shell-3409 [001] ..s. 2537.650850: intel_pstate_set_pstate <-intel_pstate_timer_func
<idle>-0 [000] ..s. 2537.654843: intel_pstate_set_pstate <-intel_pstate_timer_func
Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
+1 -1
View File
@@ -36,7 +36,7 @@ Optional properties:
control gpios
- threshold: allows setting the "click"-threshold in the range
from 20 to 80.
from 0 to 80.
- gain: allows setting the sensitivity in the range from 0 to
31. Note that lower values indicate higher
Documentation/devicetree/bindings/mfd/hisilicon,hi655x.txt
+6
View File
@@ -16,6 +16,11 @@ Required properties:
- reg: Base address of PMIC on Hi6220 SoC.
- interrupt-controller: Hi655x has internal IRQs (has own IRQ domain).
- pmic-gpios: The GPIO used by PMIC IRQ.
- #clock-cells: From common clock binding; shall be set to 0
Optional properties:
- clock-output-names: From common clock binding to override the
default output clock name
Example:
pmic: pmic@f8000000 {
@@ -24,4 +29,5 @@ Example:
interrupt-controller;
#interrupt-cells = <2>;
pmic-gpios = <&gpio1 2 GPIO_ACTIVE_HIGH>;
#clock-cells = <0>;
}
Documentation/devicetree/bindings/misc/allwinner,syscon.txt
+19
View File
@@ -0,0 +1,19 @@
* Allwinner sun8i system controller
This file describes the bindings for the system controller present in
Allwinner SoC H3, A83T and A64.
The principal function of this syscon is to control EMAC PHY choice and
config.
Required properties for the system controller:
- reg: address and length of the register for the device.
- compatible: should be "syscon" and one of the following string:
"allwinner,sun8i-h3-system-controller"
"allwinner,sun50i-a64-system-controller"
"allwinner,sun8i-a83t-system-controller"
Example:
syscon: syscon@1c00000 {
compatible = "allwinner,sun8i-h3-system-controller", "syscon";
reg = <0x01c00000 0x1000>;
};
Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
+2
View File
@@ -18,6 +18,8 @@ Optional properties:
"ext_clock" (External clock provided to the card).
- post-power-on-delay-ms : Delay in ms after powering the card and
de-asserting the reset-gpios (if any)
- power-off-delay-us : Delay in us after asserting the reset-gpios (if any)
during power off of the card.
Example:
Documentation/devicetree/bindings/net/cortina.txt
+21
View File
@@ -0,0 +1,21 @@
Cortina Phy Driver Device Tree Bindings
---------------------------------------
CORTINA is a registered trademark of Cortina Systems, Inc.
The driver supports the Cortina Electronic Dispersion Compensation (EDC)
devices, equipped with clock and data recovery (CDR) circuits. These
devices make use of registers that are not compatible with Clause 45 or
Clause 22, therefore they need to be described using the
"ethernet-phy-id" compatible.
Since the driver only implements polling mode support, interrupts info
can be skipped.
Example (CS4340 phy):
mdio {
cs4340_phy@10 {
compatible = "ethernet-phy-id13e5.1002";
reg = <0x10>;
};
};
Documentation/devicetree/bindings/net/dsa/b53.txt
+3
View File
@@ -13,6 +13,9 @@ Required properties:
"brcm,bcm5397"
"brcm,bcm5398"
For the BCM11360 SoC, must be:
"brcm,bcm11360-srab" and the mandatory "brcm,cygnus-srab" string
For the BCM5310x SoCs with an integrated switch, must be one of:
"brcm,bcm53010-srab"
"brcm,bcm53011-srab"
Documentation/devicetree/bindings/net/dsa/ksz.txt
+72
View File
@@ -0,0 +1,72 @@
Microchip KSZ Series Ethernet switches
==================================
Required properties:
- compatible: For external switch chips, compatible string must be exactly one
of: "microchip,ksz9477"
See Documentation/devicetree/bindings/dsa/dsa.txt for a list of additional
required and optional properties.
Examples:
Ethernet switch connected via SPI to the host, CPU port wired to eth0:
eth0: ethernet@10001000 {
fixed-link {
speed = <1000>;
full-duplex;
};
};
spi1: spi@f8008000 {
pinctrl-0 = <&pinctrl_spi_ksz>;
cs-gpios = <&pioC 25 0>;
id = <1>;
status = "okay";
ksz9477: ksz9477@0 {
compatible = "microchip,ksz9477";
reg = <0>;
spi-max-frequency = <44000000>;
spi-cpha;
spi-cpol;
status = "okay";
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
label = "lan1";
};
port@1 {
reg = <1>;
label = "lan2";
};
port@2 {
reg = <2>;
label = "lan3";
};
port@3 {
reg = <3>;
label = "lan4";
};
port@4 {
reg = <4>;
label = "lan5";
};
port@5 {
reg = <5>;
label = "cpu";
ethernet = <&eth0>;
fixed-link {
speed = <1000>;
full-duplex;
};
};
};
};
};
Documentation/devicetree/bindings/net/dsa/marvell.txt
+4
View File
@@ -26,6 +26,10 @@ Optional properties:
- interrupt-controller : Indicates the switch is itself an interrupt
controller. This is used for the PHY interrupts.
#interrupt-cells = <2> : Controller uses two cells, number and flag
- eeprom-length : Set to the length of an EEPROM connected to the
switch. Must be set if the switch can not detect
the presence and/or size of a connected EEPROM,
otherwise optional.
- mdio : Container of PHY and devices on the switches MDIO
bus.
- mdio? : Container of PHYs and devices on the external MDIO
Documentation/devicetree/bindings/net/dwmac-sun8i.txt
+78
View File
@@ -0,0 +1,78 @@
* Allwinner sun8i GMAC ethernet controller
This device is a platform glue layer for stmmac.
Please see stmmac.txt for the other unchanged properties.
Required properties:
- compatible: should be one of the following string:
"allwinner,sun8i-a83t-emac"
"allwinner,sun8i-h3-emac"
"allwinner,sun50i-a64-emac"
- reg: address and length of the register for the device.
- interrupts: interrupt for the device
- interrupt-names: should be "macirq"
- clocks: A phandle to the reference clock for this device
- clock-names: should be "stmmaceth"
- resets: A phandle to the reset control for this device
- reset-names: should be "stmmaceth"
- phy-mode: See ethernet.txt
- phy-handle: See ethernet.txt
- #address-cells: shall be 1
- #size-cells: shall be 0
- syscon: A phandle to the syscon of the SoC with one of the following
compatible string:
- allwinner,sun8i-h3-system-controller
- allwinner,sun50i-a64-system-controller
- allwinner,sun8i-a83t-system-controller
Optional properties:
- allwinner,tx-delay-ps: TX clock delay chain value in ps. Range value is 0-700. Default is 0)
- allwinner,rx-delay-ps: RX clock delay chain value in ps. Range value is 0-3100. Default is 0)
Both delay properties need to be a multiple of 100. They control the delay for
external PHY.
Optional properties for "allwinner,sun8i-h3-emac":
- allwinner,leds-active-low: EPHY LEDs are active low
Required child node of emac:
- mdio bus node: should be named mdio
Required properties of the mdio node:
- #address-cells: shall be 1
- #size-cells: shall be 0
The device node referenced by "phy" or "phy-handle" should be a child node
of the mdio node. See phy.txt for the generic PHY bindings.
Required properties of the phy node with "allwinner,sun8i-h3-emac":
- clocks: a phandle to the reference clock for the EPHY
- resets: a phandle to the reset control for the EPHY
Example:
emac: ethernet@1c0b000 {
compatible = "allwinner,sun8i-h3-emac";
syscon = <&syscon>;
reg = <0x01c0b000 0x104>;
interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "macirq";
resets = <&ccu RST_BUS_EMAC>;
reset-names = "stmmaceth";
clocks = <&ccu CLK_BUS_EMAC>;
clock-names = "stmmaceth";
#address-cells = <1>;
#size-cells = <0>;
phy-handle = <&int_mii_phy>;
phy-mode = "mii";
allwinner,leds-active-low;
mdio: mdio {
#address-cells = <1>;
#size-cells = <0>;
int_mii_phy: ethernet-phy@1 {
reg = <1>;
clocks = <&ccu CLK_BUS_EPHY>;
resets = <&ccu RST_BUS_EPHY>;
};
};
};
Documentation/devicetree/bindings/net/ethernet.txt
+2
View File
@@ -32,6 +32,8 @@ The following properties are common to the Ethernet controllers:
* "2000base-x",
* "2500base-x",
* "rxaui"
* "xaui"
* "10gbase-kr" (10GBASE-KR, XFI, SFI)
- phy-connection-type: the same as "phy-mode" property but described in ePAPR;
- phy-handle: phandle, specifies a reference to a node representing a PHY
device; this property is described in ePAPR and so preferred;
Documentation/devicetree/bindings/net/fsl-fec.txt
+4
View File
@@ -15,6 +15,10 @@ Optional properties:
- phy-reset-active-high : If present then the reset sequence using the GPIO
specified in the "phy-reset-gpios" property is reversed (H=reset state,
L=operation state).
- phy-reset-post-delay : Post reset delay in milliseconds. If present then
a delay of phy-reset-post-delay milliseconds will be observed after the
phy-reset-gpios has been toggled. Can be omitted thus no delay is
observed. Delay is in range of 1ms to 1000ms. Other delays are invalid.
- phy-supply : regulator that powers the Ethernet PHY.
- phy-handle : phandle to the PHY device connected to this device.
- fixed-link : Assume a fixed link. See fixed-link.txt in the same directory.
Documentation/devicetree/bindings/net/qca,qca7000.txt
+88
View File
@@ -0,0 +1,88 @@
* Qualcomm QCA7000
The QCA7000 is a serial-to-powerline bridge with a host interface which could
be configured either as SPI or UART slave. This configuration is done by
the QCA7000 firmware.
(a) Ethernet over SPI
In order to use the QCA7000 as SPI device it must be defined as a child of a
SPI master in the device tree.
Required properties:
- compatible : Should be "qca,qca7000"
- reg : Should specify the SPI chip select
- interrupts : The first cell should specify the index of the source
interrupt and the second cell should specify the trigger
type as rising edge
- spi-cpha : Must be set
- spi-cpol : Must be set
Optional properties:
- interrupt-parent : Specify the pHandle of the source interrupt
- spi-max-frequency : Maximum frequency of the SPI bus the chip can operate at.
Numbers smaller than 1000000 or greater than 16000000
are invalid. Missing the property will set the SPI
frequency to 8000000 Hertz.
- local-mac-address : see ./ethernet.txt
- qca,legacy-mode : Set the SPI data transfer of the QCA7000 to legacy mode.
In this mode the SPI master must toggle the chip select
between each data word. In burst mode these gaps aren't
necessary, which is faster. This setting depends on how
the QCA7000 is setup via GPIO pin strapping. If the
property is missing the driver defaults to burst mode.
SPI Example:
/* Freescale i.MX28 SPI master*/
ssp2: spi@80014000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,imx28-spi";
pinctrl-names = "default";
pinctrl-0 = <&spi2_pins_a>;
status = "okay";
qca7000: ethernet@0 {
compatible = "qca,qca7000";
reg = <0x0>;
interrupt-parent = <&gpio3>; /* GPIO Bank 3 */
interrupts = <25 0x1>; /* Index: 25, rising edge */
spi-cpha; /* SPI mode: CPHA=1 */
spi-cpol; /* SPI mode: CPOL=1 */
spi-max-frequency = <8000000>; /* freq: 8 MHz */
local-mac-address = [ A0 B0 C0 D0 E0 F0 ];
};
};
(b) Ethernet over UART
In order to use the QCA7000 as UART slave it must be defined as a child of a
UART master in the device tree. It is possible to preconfigure the UART
settings of the QCA7000 firmware, but it's not possible to change them during
runtime.
Required properties:
- compatible : Should be "qca,qca7000"
Optional properties:
- local-mac-address : see ./ethernet.txt
- current-speed : current baud rate of QCA7000 which defaults to 115200
if absent, see also ../serial/slave-device.txt
UART Example:
/* Freescale i.MX28 UART */
auart0: serial@8006a000 {
compatible = "fsl,imx28-auart", "fsl,imx23-auart";
reg = <0x8006a000 0x2000>;
pinctrl-names = "default";
pinctrl-0 = <&auart0_2pins_a>;
status = "okay";
qca7000: ethernet {
compatible = "qca,qca7000";
local-mac-address = [ A0 B0 C0 D0 E0 F0 ];
current-speed = <38400>;
};
};
Documentation/devicetree/bindings/net/qca-qca7000-spi.txt
-47
View File
@@ -1,47 +0,0 @@
* Qualcomm QCA7000 (Ethernet over SPI protocol)
Note: The QCA7000 is useable as a SPI device. In this case it must be defined
as a child of a SPI master in the device tree.
Required properties:
- compatible : Should be "qca,qca7000"
- reg : Should specify the SPI chip select
- interrupts : The first cell should specify the index of the source interrupt
and the second cell should specify the trigger type as rising edge
- spi-cpha : Must be set
- spi-cpol: Must be set
Optional properties:
- interrupt-parent : Specify the pHandle of the source interrupt
- spi-max-frequency : Maximum frequency of the SPI bus the chip can operate at.
Numbers smaller than 1000000 or greater than 16000000 are invalid. Missing
the property will set the SPI frequency to 8000000 Hertz.
- local-mac-address: 6 bytes, MAC address
- qca,legacy-mode : Set the SPI data transfer of the QCA7000 to legacy mode.
In this mode the SPI master must toggle the chip select between each data
word. In burst mode these gaps aren't necessary, which is faster.
This setting depends on how the QCA7000 is setup via GPIO pin strapping.
If the property is missing the driver defaults to burst mode.
Example:
/* Freescale i.MX28 SPI master*/
ssp2: spi@80014000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,imx28-spi";
pinctrl-names = "default";
pinctrl-0 = <&spi2_pins_a>;
status = "okay";
qca7000: ethernet@0 {
compatible = "qca,qca7000";
reg = <0x0>;
interrupt-parent = <&gpio3>; /* GPIO Bank 3 */
interrupts = <25 0x1>; /* Index: 25, rising edge */
spi-cpha; /* SPI mode: CPHA=1 */
spi-cpol; /* SPI mode: CPOL=1 */
spi-max-frequency = <8000000>; /* freq: 8 MHz */
local-mac-address = [ A0 B0 C0 D0 E0 F0 ];
};
};

Some files were not shown because too many files have changed in this diff Show More