Merge branch 'main' into zstd-next

   :maxdepth: 1

   initrd_table_override

   dsdt-override

   ssdt-overlays

   cppc_sysfs

   fan_performance_states

  For retrieving device info via ``ublksrv_ctrl_dev_info``. It is the server's

  responsibility to save IO target specific info in userspace.

- ``UBLK_CMD_START_USER_RECOVERY``

  This command is valid if ``UBLK_F_USER_RECOVERY`` feature is enabled. This

  command is accepted after the old process has exited, ublk device is quiesced

  and ``/dev/ublkc*`` is released. User should send this command before he starts

  a new process which re-opens ``/dev/ublkc*``. When this command returns, the

  ublk device is ready for the new process.

- ``UBLK_CMD_END_USER_RECOVERY``

  This command is valid if ``UBLK_F_USER_RECOVERY`` feature is enabled. This

  command is accepted after ublk device is quiesced and a new process has

  opened ``/dev/ublkc*`` and get all ublk queues be ready. When this command

  returns, ublk device is unquiesced and new I/O requests are passed to the

  new process.

- user recovery feature description

  Two new features are added for user recovery: ``UBLK_F_USER_RECOVERY`` and

  ``UBLK_F_USER_RECOVERY_REISSUE``.

  With ``UBLK_F_USER_RECOVERY`` set, after one ubq_daemon(ublk server's io

  handler) is dying, ublk does not delete ``/dev/ublkb*`` during the whole

  recovery stage and ublk device ID is kept. It is ublk server's

  responsibility to recover the device context by its own knowledge.

  Requests which have not been issued to userspace are requeued. Requests

  which have been issued to userspace are aborted.

  With ``UBLK_F_USER_RECOVERY_REISSUE`` set, after one ubq_daemon(ublk

  server's io handler) is dying, contrary to ``UBLK_F_USER_RECOVERY``,

  requests which have been issued to userspace are requeued and will be

  re-issued to the new process after handling ``UBLK_CMD_END_USER_RECOVERY``.

  ``UBLK_F_USER_RECOVERY_REISSUE`` is designed for backends who tolerate

  double-write since the driver may issue the same I/O request twice. It

  might be useful to a read-only FS or a VM backend.

Data plane

----------

Dongwoon Anatech DW9714 camera voice coil lens driver

DW9174 is a 10-bit DAC with current sink capability. It is intended

for driving voice coil lenses in camera modules.

Mandatory properties:

- compatible: "dongwoon,dw9714"

- reg: I²C slave address

# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause

%YAML 1.2

---

$id: http://devicetree.org/schemas/media/i2c/dongwoon,dw9714.yaml#

$schema: http://devicetree.org/meta-schemas/core.yaml#

title: Dongwoon Anatech DW9714 camera voice coil lens driver

maintainers:

  - Krzysztof Kozlowski <krzk@kernel.org>

description:

  DW9174 is a 10-bit DAC with current sink capability. It is intended for

  driving voice coil lenses in camera modules.

properties:

  compatible:

    const: dongwoon,dw9714

  reg:

    maxItems: 1

  powerdown-gpios:

    description:

      XSD pin for shutdown (active low)

  vcc-supply:

    description: VDD power supply

required:

  - compatible

  - reg

additionalProperties: false

examples:

  - |

    i2c {

        #address-cells = <1>;

        #size-cells = <0>;

        camera-lens@c {

            compatible = "dongwoon,dw9714";

            reg = <0x0c>;

            vcc-supply = <&reg_csi_1v8>;

        };

    };

Pipelines and media streams

^^^^^^^^^^^^^^^^^^^^^^^^^^^

A media stream is a stream of pixels or metadata originating from one or more

source devices (such as a sensors) and flowing through media entity pads

towards the final sinks. The stream can be modified on the route by the

devices (e.g. scaling or pixel format conversions), or it can be split into

multiple branches, or multiple branches can be merged.

A media pipeline is a set of media streams which are interdependent. This

interdependency can be caused by the hardware (e.g. configuration of a second

stream cannot be changed if the first stream has been enabled) or by the driver

due to the software design. Most commonly a media pipeline consists of a single

stream which does not branch.

When starting streaming, drivers must notify all entities in the pipeline to

prevent link states from being modified during streaming by calling

:c:func:`media_pipeline_start()`.

The function will mark all entities connected to the given entity through

enabled links, either directly or indirectly, as streaming.

The function will mark all the pads which are part of the pipeline as streaming.

The struct media_pipeline instance pointed to by

the pipe argument will be stored in every entity in the pipeline.

the pipe argument will be stored in every pad in the pipeline.

Drivers should embed the struct media_pipeline

in higher-level pipeline structures and can then access the

pipeline through the struct media_entity

pipeline through the struct media_pad

pipe field.

Calls to :c:func:`media_pipeline_start()` can be nested.