Commit cd996fb4 authored by Jens Axboe's avatar Jens Axboe

Merge tag 'v4.13-rc7' into for-4.14/block-postmerge

Linux 4.13-rc7
Signed-off-by: default avatarJens Axboe <>
parents e9a823fb cc4a41fe

Too many changes to show.

To preserve performance only 1000 of 1000+ files are displayed.
......@@ -237,6 +237,14 @@ are the following:
This attribute is not present if the scaling driver in use does not
support it.
Current frequency of the CPUs belonging to this policy as obtained from
the hardware (in KHz).
This is expected to be the frequency the hardware actually runs at.
If that frequency cannot be determined, this attribute should not
be present.
Maximum possible operating frequency the CPUs belonging to this policy
can run at (in kHz).
* Renesas R-Car SATA
Required properties:
- compatible : should contain one of the following:
- compatible : should contain one or more of the following:
- "renesas,sata-r8a7779" for R-Car H1
("renesas,rcar-sata" is deprecated)
- "renesas,sata-r8a7790-es1" for R-Car H2 ES1
- "renesas,sata-r8a7790" for R-Car H2 other than ES1
- "renesas,sata-r8a7791" for R-Car M2-W
- "renesas,sata-r8a7793" for R-Car M2-N
- "renesas,sata-r8a7795" for R-Car H3
- "renesas,rcar-gen2-sata" for a generic R-Car Gen2 compatible device
- "renesas,rcar-gen3-sata" for a generic R-Car Gen3 compatible device
- "renesas,rcar-sata" is deprecated
When compatible with the generic version nodes
must list the SoC-specific version corresponding
to the platform first followed by the generic
- reg : address and length of the SATA registers;
- interrupts : must consist of one interrupt specifier.
- clocks : must contain a reference to the functional clock.
......@@ -16,7 +24,7 @@ Required properties:
sata0: sata@ee300000 {
compatible = "renesas,sata-r8a7791";
compatible = "renesas,sata-r8a7791", "renesas,rcar-gen2-sata";
reg = <0 0xee300000 0 0x2000>;
interrupt-parent = <&gic>;
interrupts = <0 105 IRQ_TYPE_LEVEL_HIGH>;
Exportable MPIO interface of Exar UART chips
Required properties of the device:
- exar,first-pin: first exportable pins (0..15)
- ngpios: number of exportable pins (1..16)
......@@ -40,7 +40,7 @@ Optional properties:
Example for a Mali-T760:
gpu@ffa30000 {
compatible = "rockchip,rk3288-mali", "arm,mali-t760", "arm,mali-midgard";
compatible = "rockchip,rk3288-mali", "arm,mali-t760";
reg = <0xffa30000 0x10000>;
interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>,
......@@ -27,5 +27,11 @@ You have to add the following kernel parameters in your elilo.conf:
Macbook Pro 17", iMac 20" :
Accepted options:
nowc Don't map the framebuffer write combined. This can be used
to workaround side-effects and slowdowns on other CPU cores
when large amounts of console data are written.
Edgar Hucek <>
......@@ -459,7 +459,7 @@ pin controller?
This is done by registering "ranges" of pins, which are essentially
cross-reference tables. These are described in
While the pin allocation is totally managed by the pinctrl subsystem,
gpio (under gpiolib) is still maintained by gpio drivers. It may happen
Digital TV (DVB) devices
Digital TV devices are implemented by several different drivers:
- A bridge driver that is responsible to talk with the bus where the other
devices are connected (PCI, USB, SPI), bind to the other drivers and
implement the digital demux logic (either in software or in hardware);
- Frontend drivers that are usually implemented as two separate drivers:
- A tuner driver that implements the logic with commands the part of the
hardware with is reponsible to tune into a digital TV transponder or
physical channel. The output of a tuner is usually a baseband or
Intermediate Frequency (IF) signal;
- A demodulator driver (a.k.a "demod") that implements the logic with
commands the digital TV decoding hardware. The output of a demod is
a digital stream, with multiple audio, video and data channels typically
multiplexed using MPEG Transport Stream [#f1]_.
On most hardware, the frontend drivers talk with the bridge driver using an
I2C bus.
.. [#f1] Some standards use TCP/IP for multiplexing data, like DVB-H (an
abandoned standard, not used anymore) and ATSC version 3.0 current
proposals. Currently, the DVB subsystem doesn't implement those standards.
Digital TV Common functions
......@@ -55,8 +80,141 @@ Digital TV Frontend
The Digital TV Frontend kABI defines a driver-internal interface for
registering low-level, hardware specific driver to a hardware independent
frontend layer. It is only of interest for Digital TV device driver writers.
The header file for this API is named dvb_frontend.h and located in
The header file for this API is named ``dvb_frontend.h`` and located in
Demodulator driver
The demodulator driver is responsible to talk with the decoding part of the
hardware. Such driver should implement :c:type:`dvb_frontend_ops`, with
tells what type of digital TV standards are supported, and points to a
series of functions that allow the DVB core to command the hardware via
the code under ``drivers/media/dvb-core/dvb_frontend.c``.
A typical example of such struct in a driver ``foo`` is::
static struct dvb_frontend_ops foo_ops = {
.info = {
.name = "foo DVB-T/T2/C driver",
.caps = FE_CAN_FEC_1_2 |
FE_CAN_FEC_2_3 |
FE_CAN_FEC_3_4 |
FE_CAN_FEC_5_6 |
FE_CAN_FEC_7_8 |
FE_CAN_QAM_128 |
FE_CAN_QAM_256 |
.frequency_min = 42000000, /* Hz */
.frequency_max = 1002000000, /* Hz */
.symbol_rate_min = 870000,
.symbol_rate_max = 11700000
.init = foo_init,
.sleep = foo_sleep,
.release = foo_release,
.set_frontend = foo_set_frontend,
.get_frontend = foo_get_frontend,
.read_status = foo_get_status_and_stats,
.tune = foo_tune,
.i2c_gate_ctrl = foo_i2c_gate_ctrl,
.get_frontend_algo = foo_get_algo,
A typical example of such struct in a driver ``bar`` meant to be used on
Satellite TV reception is::
static const struct dvb_frontend_ops bar_ops = {
.delsys = { SYS_DVBS, SYS_DVBS2 },
.info = {
.name = "Bar DVB-S/S2 demodulator",
.frequency_min = 500000, /* KHz */
.frequency_max = 2500000, /* KHz */
.frequency_stepsize = 0,
.symbol_rate_min = 1000000,
.symbol_rate_max = 45000000,
.symbol_rate_tolerance = 500,
.init = bar_init,
.sleep = bar_sleep,
.release = bar_release,
.set_frontend = bar_set_frontend,
.get_frontend = bar_get_frontend,
.read_status = bar_get_status_and_stats,
.i2c_gate_ctrl = bar_i2c_gate_ctrl,
.get_frontend_algo = bar_get_algo,
.tune = bar_tune,
/* Satellite-specific */
.diseqc_send_master_cmd = bar_send_diseqc_msg,
.diseqc_send_burst = bar_send_burst,
.set_tone = bar_set_tone,
.set_voltage = bar_set_voltage,
.. note::
#) For satellite digital TV standards (DVB-S, DVB-S2, ISDB-S), the
frequencies are specified in kHz, while, for terrestrial and cable
standards, they're specified in Hz. Due to that, if the same frontend
supports both types, you'll need to have two separate
:c:type:`dvb_frontend_ops` structures, one for each standard.
#) The ``.i2c_gate_ctrl`` field is present only when the hardware has
allows controlling an I2C gate (either directly of via some GPIO pin),
in order to remove the tuner from the I2C bus after a channel is
#) All new drivers should implement the
:ref:`DVBv5 statistics <dvbv5_stats>` via ``.read_status``.
Yet, there are a number of callbacks meant to get statistics for
signal strength, S/N and UCB. Those are there to provide backward
compatibility with legacy applications that don't support the DVBv5
API. Implementing those callbacks are optional. Those callbacks may be
removed in the future, after we have all existing drivers supporting