diff options
Diffstat (limited to 'Documentation')
116 files changed, 4981 insertions, 2828 deletions
diff --git a/Documentation/ABI/testing/sysfs-devices-platform-ipmi b/Documentation/ABI/testing/sysfs-devices-platform-ipmi index 2a781e7513b7..afb5db856e1c 100644 --- a/Documentation/ABI/testing/sysfs-devices-platform-ipmi +++ b/Documentation/ABI/testing/sysfs-devices-platform-ipmi @@ -212,7 +212,7 @@ Description: Messages may be broken into parts if they are long. - receieved_messages: (RO) Number of message responses + received_messages: (RO) Number of message responses received. received_message_parts: (RO) Number of message fragments diff --git a/Documentation/ABI/testing/sysfs-driver-ucsi-ccg b/Documentation/ABI/testing/sysfs-driver-ucsi-ccg new file mode 100644 index 000000000000..45cf62ad89e9 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-ucsi-ccg @@ -0,0 +1,6 @@ +What: /sys/bus/i2c/drivers/ucsi_ccg/.../do_flash +Date: May 2019 +Contact: Ajay Gupta <ajayg@nvidia.com> +Description: + Tell the driver for Cypress CCGx Type-C controller to attempt + firmware upgrade by writing [Yy1] to the file. diff --git a/Documentation/ABI/testing/usb-uevent b/Documentation/ABI/testing/usb-uevent new file mode 100644 index 000000000000..d35c3cad892c --- /dev/null +++ b/Documentation/ABI/testing/usb-uevent @@ -0,0 +1,27 @@ +What: Raise a uevent when a USB Host Controller has died +Date: 2019-04-17 +KernelVersion: 5.2 +Contact: linux-usb@vger.kernel.org +Description: When the USB Host Controller has entered a state where it is no + longer functional a uevent will be raised. The uevent will + contain ACTION=offline and ERROR=DEAD. + + Here is an example taken using udevadm monitor -p: + + KERNEL[130.428945] offline /devices/pci0000:00/0000:00:10.0/usb2 (usb) + ACTION=offline + BUSNUM=002 + DEVNAME=/dev/bus/usb/002/001 + DEVNUM=001 + DEVPATH=/devices/pci0000:00/0000:00:10.0/usb2 + DEVTYPE=usb_device + DRIVER=usb + ERROR=DEAD + MAJOR=189 + MINOR=128 + PRODUCT=1d6b/2/414 + SEQNUM=2168 + SUBSYSTEM=usb + TYPE=9/0/1 + +Users: chromium-os-dev@chromium.org diff --git a/Documentation/devicetree/bindings/media/aspeed-video.txt b/Documentation/devicetree/bindings/media/aspeed-video.txt index 78b464ae2672..ce2894506e1f 100644 --- a/Documentation/devicetree/bindings/media/aspeed-video.txt +++ b/Documentation/devicetree/bindings/media/aspeed-video.txt @@ -14,6 +14,11 @@ Required properties: the VE - interrupts: the interrupt associated with the VE on this platform +Optional properties: + - memory-region: + phandle to a memory region to allocate from, as defined in + Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt + Example: video-engine@1e700000 { @@ -23,4 +28,5 @@ video-engine@1e700000 { clock-names = "vclk", "eclk"; resets = <&syscon ASPEED_RESET_VIDEO>; interrupts = <7>; + memory-region = <&video_engine_memory>; }; diff --git a/Documentation/devicetree/bindings/media/cedrus.txt b/Documentation/devicetree/bindings/media/cedrus.txt index bce0705df953..20c82fb0c343 100644 --- a/Documentation/devicetree/bindings/media/cedrus.txt +++ b/Documentation/devicetree/bindings/media/cedrus.txt @@ -13,6 +13,7 @@ Required properties: - "allwinner,sun8i-h3-video-engine" - "allwinner,sun50i-a64-video-engine" - "allwinner,sun50i-h5-video-engine" + - "allwinner,sun50i-h6-video-engine" - reg : register base and length of VE; - clocks : list of clock specifiers, corresponding to entries in the clock-names property; diff --git a/Documentation/devicetree/bindings/media/i2c/st,st-mipid02.txt b/Documentation/devicetree/bindings/media/i2c/st,st-mipid02.txt new file mode 100644 index 000000000000..7976e6c40a80 --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/st,st-mipid02.txt @@ -0,0 +1,82 @@ +STMicroelectronics MIPID02 CSI-2 to PARALLEL bridge + +MIPID02 has two CSI-2 input ports, only one of those ports can be active at a +time. Active port input stream will be de-serialized and its content outputted +through PARALLEL output port. +CSI-2 first input port is a dual lane 800Mbps per lane whereas CSI-2 second +input port is a single lane 800Mbps. Both ports support clock and data lane +polarity swap. First port also supports data lane swap. +PARALLEL output port has a maximum width of 12 bits. +Supported formats are RAW6, RAW7, RAW8, RAW10, RAW12, RGB565, RGB888, RGB444, +YUV420 8-bit, YUV422 8-bit and YUV420 10-bit. + +Required Properties: +- compatible: shall be "st,st-mipid02" +- clocks: reference to the xclk input clock. +- clock-names: shall be "xclk". +- VDDE-supply: sensor digital IO supply. Must be 1.8 volts. +- VDDIN-supply: sensor internal regulator supply. Must be 1.8 volts. + +Optional Properties: +- reset-gpios: reference to the GPIO connected to the xsdn pin, if any. + This is an active low signal to the mipid02. + +Required subnodes: + - ports: A ports node with one port child node per device input and output + port, in accordance with the video interface bindings defined in + Documentation/devicetree/bindings/media/video-interfaces.txt. The + port nodes are numbered as follows: + + Port Description + ----------------------------- + 0 CSI-2 first input port + 1 CSI-2 second input port + 2 PARALLEL output + +Endpoint node required property for CSI-2 connection is: +- data-lanes: shall be <1> for Port 1. for Port 0 dual-lane operation shall be +<1 2> or <2 1>. For Port 0 single-lane operation shall be <1> or <2>. +Endpoint node optional property for CSI-2 connection is: +- lane-polarities: any lane can be inverted or not. + +Endpoint node required property for PARALLEL connection is: +- bus-width: shall be set to <6>, <7>, <8>, <10> or <12>. +Endpoint node optional properties for PARALLEL connection are: +- hsync-active: active state of the HSYNC signal, 0/1 for LOW/HIGH respectively. +LOW being the default. +- vsync-active: active state of the VSYNC signal, 0/1 for LOW/HIGH respectively. +LOW being the default. + +Example: + +mipid02: csi2rx@14 { + compatible = "st,st-mipid02"; + reg = <0x14>; + status = "okay"; + clocks = <&clk_ext_camera_12>; + clock-names = "xclk"; + VDDE-supply = <&vdd>; + VDDIN-supply = <&vdd>; + ports { + #address-cells = <1>; + #size-cells = <0>; + port@0 { + reg = <0>; + + ep0: endpoint { + data-lanes = <1 2>; + remote-endpoint = <&mipi_csi2_in>; + }; + }; + port@2 { + reg = <2>; + + ep2: endpoint { + bus-width = <8>; + hsync-active = <0>; + vsync-active = <0>; + remote-endpoint = <¶llel_out>; + }; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/media/meson-ao-cec.txt b/Documentation/devicetree/bindings/media/meson-ao-cec.txt index 8671bdb08080..c67fc41d4aa2 100644 --- a/Documentation/devicetree/bindings/media/meson-ao-cec.txt +++ b/Documentation/devicetree/bindings/media/meson-ao-cec.txt @@ -4,16 +4,23 @@ The Amlogic Meson AO-CEC module is present is Amlogic SoCs and its purpose is to handle communication between HDMI connected devices over the CEC bus. Required properties: - - compatible : value should be following + - compatible : value should be following depending on the SoC : + For GXBB, GXL, GXM and G12A (AO_CEC_A module) : "amlogic,meson-gx-ao-cec" + For G12A (AO_CEC_B module) : + "amlogic,meson-g12a-ao-cec" - reg : Physical base address of the IP registers and length of memory mapped region. - interrupts : AO-CEC interrupt number to the CPU. - clocks : from common clock binding: handle to AO-CEC clock. - - clock-names : from common clock binding: must contain "core", - corresponding to entry in the clocks property. + - clock-names : from common clock binding, must contain : + For GXBB, GXL, GXM and G12A (AO_CEC_A module) : + - "core" + For G12A (AO_CEC_B module) : + - "oscin" + corresponding to entry in the clocks property. - hdmi-phandle: phandle to the HDMI controller Example: diff --git a/Documentation/devicetree/bindings/media/rcar_imr.txt b/Documentation/devicetree/bindings/media/rcar_imr.txt new file mode 100644 index 000000000000..b0614153ed36 --- /dev/null +++ b/Documentation/devicetree/bindings/media/rcar_imr.txt @@ -0,0 +1,31 @@ +Renesas R-Car Image Renderer (Distortion Correction Engine) +----------------------------------------------------------- + +The image renderer, or the distortion correction engine, is a drawing processor +with a simple instruction system capable of referencing video capture data or +data in an external memory as 2D texture data and performing texture mapping +and drawing with respect to any shape that is split into triangular objects. + +Required properties: + +- compatible: "renesas,<soctype>-imr-lx4", "renesas,imr-lx4" as a fallback for + the image renderer light extended 4 (IMR-LX4) found in the R-Car gen3 SoCs, + where the examples with <soctype> are: + - "renesas,r8a7795-imr-lx4" for R-Car H3, + - "renesas,r8a7796-imr-lx4" for R-Car M3-W. +- reg: offset and length of the register block; +- interrupts: single interrupt specifier; +- clocks: single clock phandle/specifier pair; +- power-domains: power domain phandle/specifier pair; +- resets: reset phandle/specifier pair. + +Example: + + imr-lx4@fe860000 { + compatible = "renesas,r8a7795-imr-lx4", "renesas,imr-lx4"; + reg = <0 0xfe860000 0 0x2000>; + interrupts = <GIC_SPI 192 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cpg CPG_MOD 823>; + power-domains = <&sysc R8A7795_PD_A3VC>; + resets = <&cpg 823>; + }; diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt b/Documentation/devicetree/bindings/media/rcar_vin.txt index 224a4615b418..aa217b096279 100644 --- a/Documentation/devicetree/bindings/media/rcar_vin.txt +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt @@ -13,6 +13,7 @@ on Gen3 and RZ/G2 platforms to a CSI-2 receiver. - "renesas,vin-r8a7743" for the R8A7743 device - "renesas,vin-r8a7744" for the R8A7744 device - "renesas,vin-r8a7745" for the R8A7745 device + - "renesas,vin-r8a774a1" for the R8A774A1 device - "renesas,vin-r8a774c0" for the R8A774C0 device - "renesas,vin-r8a7778" for the R8A7778 device - "renesas,vin-r8a7779" for the R8A7779 device diff --git a/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt b/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt index d63275e17afd..331409259752 100644 --- a/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt +++ b/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt @@ -8,6 +8,7 @@ R-Car VIN module, which provides the video capture capabilities. Mandatory properties -------------------- - compatible: Must be one or more of the following + - "renesas,r8a774a1-csi2" for the R8A774A1 device. - "renesas,r8a774c0-csi2" for the R8A774C0 device. - "renesas,r8a7795-csi2" for the R8A7795 device. - "renesas,r8a7796-csi2" for the R8A7796 device. @@ -18,7 +19,8 @@ Mandatory properties - reg: the register base and size for the device registers - interrupts: the interrupt for the device - - clocks: reference to the parent clock + - clocks: A phandle + clock specifier for the module clock + - resets: A phandle + reset specifier for the module reset The device node shall contain two 'port' child nodes according to the bindings defined in Documentation/devicetree/bindings/media/ diff --git a/Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt b/Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt new file mode 100644 index 000000000000..4ba298966af9 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt @@ -0,0 +1,32 @@ +Broadcom Stingray USB PHY + +Required properties: + - compatible : should be one of the listed compatibles + - "brcm,sr-usb-combo-phy" is combo PHY has two PHYs, one SS and one HS. + - "brcm,sr-usb-hs-phy" is a single HS PHY. + - reg: offset and length of the PHY blocks registers + - #phy-cells: + - Must be 1 for brcm,sr-usb-combo-phy as it expects one argument to indicate + the PHY number of two PHYs. 0 for HS PHY and 1 for SS PHY. + - Must be 0 for brcm,sr-usb-hs-phy. + +Refer to phy/phy-bindings.txt for the generic PHY binding properties + +Example: + usbphy0: usb-phy@0 { + compatible = "brcm,sr-usb-combo-phy"; + reg = <0x00000000 0x100>; + #phy-cells = <1>; + }; + + usbphy1: usb-phy@10000 { + compatible = "brcm,sr-usb-combo-phy"; + reg = <0x00010000 0x100>, + #phy-cells = <1>; + }; + + usbphy2: usb-phy@20000 { + compatible = "brcm,sr-usb-hs-phy"; + reg = <0x00020000 0x100>, + #phy-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.txt b/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.txt index a22e853d710c..ed47e5cd067e 100644 --- a/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.txt +++ b/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.txt @@ -7,6 +7,9 @@ Required properties: - clocks: phandles to the clocks for each clock listed in clock-names - clock-names: must contain "phy" +Optional properties: +- vbus-supply: A phandle to the regulator for USB VBUS. + Example: usb3_phy0: phy@381f0040 { compatible = "fsl,imx8mq-usb-phy"; diff --git a/Documentation/devicetree/bindings/phy/meson-g12a-usb2-phy.txt b/Documentation/devicetree/bindings/phy/meson-g12a-usb2-phy.txt new file mode 100644 index 000000000000..a6ebc3dea159 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/meson-g12a-usb2-phy.txt @@ -0,0 +1,22 @@ +* Amlogic G12A USB2 PHY binding + +Required properties: +- compatible: Should be "amlogic,meson-g12a-usb2-phy" +- reg: The base address and length of the registers +- #phys-cells: must be 0 (see phy-bindings.txt in this directory) +- clocks: a phandle to the clock of this PHY +- clock-names: must be "xtal" +- resets: a phandle to the reset line of this PHY +- reset-names: must be "phy" +- phy-supply: see phy-bindings.txt in this directory + +Example: + usb2_phy0: phy@36000 { + compatible = "amlogic,g12a-usb2-phy"; + reg = <0x0 0x36000 0x0 0x2000>; + clocks = <&xtal>; + clock-names = "xtal"; + resets = <&reset RESET_USB_PHY21>; + reset-names = "phy"; + #phy-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/phy/meson-g12a-usb3-pcie-phy.txt b/Documentation/devicetree/bindings/phy/meson-g12a-usb3-pcie-phy.txt new file mode 100644 index 000000000000..7cfc17e2df31 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/meson-g12a-usb3-pcie-phy.txt @@ -0,0 +1,22 @@ +* Amlogic G12A USB3 + PCIE Combo PHY binding + +Required properties: +- compatible: Should be "amlogic,meson-g12a-usb3-pcie-phy" +- #phys-cells: must be 1. The cell number is used to select the phy mode + as defined in <dt-bindings/phy/phy.h> between PHY_TYPE_USB3 and PHY_TYPE_PCIE +- reg: The base address and length of the registers +- clocks: a phandle to the 100MHz reference clock of this PHY +- clock-names: must be "ref_clk" +- resets: phandle to the reset lines for the PHY control +- reset-names: must be "phy" + +Example: + usb3_pcie_phy: phy@46000 { + compatible = "amlogic,g12a-usb3-pcie-phy"; + reg = <0x0 0x46000 0x0 0x2000>; + clocks = <&clkc CLKID_PCIE_PLL>; + clock-names = "ref_clk"; + resets = <&reset RESET_PCIE_PHY>; + reset-names = "phy"; + #phy-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.txt b/Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.txt index 3742c152c467..daedb15f322e 100644 --- a/Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.txt +++ b/Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.txt @@ -36,11 +36,20 @@ Required properties: - Tegra124: "nvidia,tegra124-xusb-padctl" - Tegra132: "nvidia,tegra132-xusb-padctl", "nvidia,tegra124-xusb-padctl" - Tegra210: "nvidia,tegra210-xusb-padctl" + - Tegra186: "nvidia,tegra186-xusb-padctl" - reg: Physical base address and length of the controller's registers. - resets: Must contain an entry for each entry in reset-names. - reset-names: Must include the following entries: - "padctl" +For Tegra186: +- avdd-pll-erefeut-supply: UPHY brick and reference clock as well as UTMI PHY + power supply. Must supply 1.8 V. +- avdd-usb-supply: USB I/Os, VBUS, ID, REXT, D+/D- power supply. Must supply + 3.3 V. +- vclamp-usb-supply: Bias rail for USB pad. Must supply 1.8 V. +- vddio-hsic-supply: HSIC PHY power supply. Must supply 1.2 V. + Pad nodes: ========== diff --git a/Documentation/devicetree/bindings/phy/phy-hi3660-usb3.txt b/Documentation/devicetree/bindings/phy/phy-hi3660-usb3.txt new file mode 100644 index 000000000000..e88ba7d92dcb --- /dev/null +++ b/Documentation/devicetree/bindings/phy/phy-hi3660-usb3.txt @@ -0,0 +1,26 @@ +Hisilicon hi3660 USB PHY +----------------------- + +Required properties: +- compatible: should be "hisilicon,hi3660-usb-phy" +- #phy-cells: must be 0 +- hisilicon,pericrg-syscon: phandle of syscon used to control phy. +- hisilicon,pctrl-syscon: phandle of syscon used to control phy. +- hisilicon,eye-diagram-param: parameter set for phy +Refer to phy/phy-bindings.txt for the generic PHY binding properties + +This is a subnode of usb3_otg_bc register node. + +Example: + usb3_otg_bc: usb3_otg_bc@ff200000 { + compatible = "syscon", "simple-mfd"; + reg = <0x0 0xff200000 0x0 0x1000>; + + usb-phy { + compatible = "hisilicon,hi3660-usb-phy"; + #phy-cells = <0>; + hisilicon,pericrg-syscon = <&crg_ctrl>; + hisilicon,pctrl-syscon = <&pctrl>; + hisilicon,eye-diagram-param = <0x22466e4>; + }; + }; diff --git a/Documentation/devicetree/bindings/phy/phy-mtk-ufs.txt b/Documentation/devicetree/bindings/phy/phy-mtk-ufs.txt new file mode 100644 index 000000000000..5789029a1d42 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/phy-mtk-ufs.txt @@ -0,0 +1,38 @@ +MediaTek Universal Flash Storage (UFS) M-PHY binding +-------------------------------------------------------- + +UFS M-PHY nodes are defined to describe on-chip UFS M-PHY hardware macro. +Each UFS M-PHY node should have its own node. + +To bind UFS M-PHY with UFS host controller, the controller node should +contain a phandle reference to UFS M-PHY node. + +Required properties for UFS M-PHY nodes: +- compatible : Compatible list, contains the following controller: + "mediatek,mt8183-ufsphy" for ufs phy + persent on MT81xx chipsets. +- reg : Address and length of the UFS M-PHY register set. +- #phy-cells : This property shall be set to 0. +- clocks : List of phandle and clock specifier pairs. +- clock-names : List of clock input name strings sorted in the same + order as the clocks property. Following clocks are + mandatory. + "unipro": Unipro core control clock. + "mp": M-PHY core control clock. + +Example: + + ufsphy: phy@11fa0000 { + compatible = "mediatek,mt8183-ufsphy"; + reg = <0 0x11fa0000 0 0xc000>; + #phy-cells = <0>; + + clocks = <&infracfg_ao INFRACFG_AO_UNIPRO_SCK_CG>, + <&infracfg_ao INFRACFG_AO_UFS_MP_SAP_BCLK_CG>; + clock-names = "unipro", "mp"; + }; + + ufshci@11270000 { + ... + phys = <&ufsphy>; + }; diff --git a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt index 5d181fc3cc18..085fbd676cfc 100644 --- a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt +++ b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt @@ -11,6 +11,7 @@ Required properties: "qcom,msm8996-qmp-usb3-phy" for 14nm USB3 phy on msm8996, "qcom,msm8998-qmp-usb3-phy" for USB3 QMP V3 phy on msm8998, "qcom,msm8998-qmp-ufs-phy" for UFS QMP phy on msm8998, + "qcom,msm8998-qmp-pcie-phy" for PCIe QMP phy on msm8998, "qcom,sdm845-qmp-usb3-phy" for USB3 QMP V3 phy on sdm845, "qcom,sdm845-qmp-usb3-uni-phy" for USB3 QMP V3 UNI phy on sdm845, "qcom,sdm845-qmp-ufs-phy" for UFS QMP phy on sdm845. @@ -48,6 +49,8 @@ Required properties: "aux", "cfg_ahb", "ref". For "qcom,msm8998-qmp-ufs-phy" must contain: "ref", "ref_aux". + For "qcom,msm8998-qmp-pcie-phy" must contain: + "aux", "cfg_ahb", "ref". For "qcom,sdm845-qmp-usb3-phy" must contain: "aux", "cfg_ahb", "ref", "com_aux". For "qcom,sdm845-qmp-usb3-uni-phy" must contain: @@ -59,7 +62,8 @@ Required properties: one for each entry in reset-names. - reset-names: "phy" for reset of phy block, "common" for phy common block reset, - "cfg" for phy's ahb cfg block reset. + "cfg" for phy's ahb cfg block reset, + "ufsphy" for the PHY reset in the UFS controller. For "qcom,ipq8074-qmp-pcie-phy" must contain: "phy", "common". @@ -69,12 +73,16 @@ Required properties: "phy", "common". For "qcom,msm8998-qmp-usb3-phy" must contain "phy", "common". - For "qcom,msm8998-qmp-ufs-phy": no resets are listed. + For "qcom,msm8998-qmp-ufs-phy": must contain: + "ufsphy". + For "qcom,msm8998-qmp-pcie-phy" must contain: + "phy", "common". For "qcom,sdm845-qmp-usb3-phy" must contain: "phy", "common". For "qcom,sdm845-qmp-usb3-uni-phy" must contain: "phy", "common". - For "qcom,sdm845-qmp-ufs-phy": no resets are listed. + For "qcom,sdm845-qmp-ufs-phy": must contain: + "ufsphy". - vdda-phy-supply: Phandle to a regulator supply to PHY core block. - vdda-pll-supply: Phandle to 1.8V regulator supply to PHY refclk pll block. diff --git a/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt b/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt index 4f0879a0ca12..ac96d6481bb8 100644 --- a/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt +++ b/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt @@ -7,6 +7,7 @@ Required properties: - compatible: "renesas,usb-phy-r8a7743" if the device is a part of R8A7743 SoC. "renesas,usb-phy-r8a7744" if the device is a part of R8A7744 SoC. "renesas,usb-phy-r8a7745" if the device is a part of R8A7745 SoC. + "renesas,usb-phy-r8a77470" if the device is a part of R8A77470 SoC. "renesas,usb-phy-r8a7790" if the device is a part of R8A7790 SoC. "renesas,usb-phy-r8a7791" if the device is a part of R8A7791 SoC. "renesas,usb-phy-r8a7794" if the device is a part of R8A7794 SoC. @@ -30,7 +31,7 @@ channels. These subnodes must contain the following properties: - #phy-cells: see phy-bindings.txt in the same directory, must be <1>. The phandle's argument in the PHY specifier is the USB controller selector for -the USB channel; see the selector meanings below: +the USB channel other than r8a77470 SoC; see the selector meanings below: +-----------+---------------+---------------+ |\ Selector | | | @@ -41,6 +42,16 @@ the USB channel; see the selector meanings below: | 2 | PCI EHCI/OHCI | xHCI | +-----------+---------------+---------------+ +For r8a77470 SoC;see the selector meaning below: + ++-----------+---------------+---------------+ +|\ Selector | | | ++ --------- + 0 | 1 | +| Channel \| | | ++-----------+---------------+---------------+ +| 0 | EHCI/OHCI | HS-USB | ++-----------+---------------+---------------+ + Example (Lager board): usb-phy@e6590100 { @@ -48,15 +59,53 @@ Example (Lager board): reg = <0 0xe6590100 0 0x100>; #address-cells = <1>; #size-cells = <0>; - clocks = <&mstp7_clks R8A7790_CLK_HSUSB>; + clocks = <&cpg CPG_MOD 704>; clock-names = "usbhs"; + power-domains = <&sysc R8A7790_PD_ALWAYS_ON>; + resets = <&cpg 704>; - usb-channel@0 { + usb0: usb-channel@0 { reg = <0>; #phy-cells = <1>; }; - usb-channel@2 { + usb2: usb-channel@2 { reg = <2>; #phy-cells = <1>; }; }; + +Example (iWave RZ/G1C sbc): + + usbphy0: usb-phy0@e6590100 { + compatible = "renesas,usb-phy-r8a77470", + "renesas,rcar-gen2-usb-phy"; + reg = <0 0xe6590100 0 0x100>; + #address-cells = <1>; + #size-cells = <0>; + clocks = <&cpg CPG_MOD 704>; + clock-names = "usbhs"; + power-domains = <&sysc R8A77470_PD_ALWAYS_ON>; + resets = <&cpg 704>; + + usb0: usb-channel@0 { + reg = <0>; + #phy-cells = <1>; + }; + }; + + usbphy1: usb-phy@e6598100 { + compatible = "renesas,usb-phy-r8a77470", + "renesas,rcar-gen2-usb-phy"; + reg = <0 0xe6598100 0 0x100>; + #address-cells = <1>; + #size-cells = <0>; + clocks = <&cpg CPG_MOD 706>; + clock-names = "usbhs"; + power-domains = <&sysc R8A77470_PD_ALWAYS_ON>; + resets = <&cpg 706>; + + usb1: usb-channel@0 { + reg = <0>; + #phy-cells = <1>; + }; + }; diff --git a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt index ad9c290d8f15..d46188f450bf 100644 --- a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt +++ b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt @@ -1,10 +1,12 @@ * Renesas R-Car generation 3 USB 2.0 PHY This file provides information on what the device node for the R-Car generation -3 and RZ/G2 USB 2.0 PHY contain. +3, RZ/G1C and RZ/G2 USB 2.0 PHY contain. Required properties: -- compatible: "renesas,usb2-phy-r8a774a1" if the device is a part of an R8A774A1 +- compatible: "renesas,usb2-phy-r8a77470" if the device is a part of an R8A77470 + SoC. + "renesas,usb2-phy-r8a774a1" if the device is a part of an R8A774A1 SoC. "renesas,usb2-phy-r8a774c0" if the device is a part of an R8A774C0 SoC. @@ -27,7 +29,13 @@ Required properties: - reg: offset and length of the partial USB 2.0 Host register block. - clocks: clock phandle and specifier pair(s). -- #phy-cells: see phy-bindings.txt in the same directory, must be <0>. +- #phy-cells: see phy-bindings.txt in the same directory, must be <1> (and + using <0> is deprecated). + +The phandle's argument in the PHY specifier is the INT_STATUS bit of controller: +- 1 = USBH_INTA (OHCI) +- 2 = USBH_INTB (EHCI) +- 3 = UCOM_INT (OTG and BC) Optional properties: To use a USB channel where USB 2.0 Host and HSUSB (USB 2.0 Peripheral) are diff --git a/Documentation/devicetree/bindings/phy/rockchip-emmc-phy.txt b/Documentation/devicetree/bindings/phy/rockchip-emmc-phy.txt index e3ea55763b0a..e728786f21e0 100644 --- a/Documentation/devicetree/bindings/phy/rockchip-emmc-phy.txt +++ b/Documentation/devicetree/bindings/phy/rockchip-emmc-phy.txt @@ -7,12 +7,15 @@ Required properties: - reg: PHY register address offset and length in "general register files" -Optional clocks using the clock bindings (see ../clock/clock-bindings.txt), -specified by name: +Optional properties: - clock-names: Should contain "emmcclk". Although this is listed as optional (because most boards can get basic functionality without having access to it), it is strongly suggested. + See ../clock/clock-bindings.txt for details. - clocks: Should have a phandle to the card clock exported by the SDHCI driver. + - drive-impedance-ohm: Specifies the drive impedance in Ohm. + Possible values are 33, 40, 50, 66 and 100. + If not set, the default value of 50 will be applied. Example: @@ -29,6 +32,7 @@ grf: syscon@ff770000 { reg = <0xf780 0x20>; clocks = <&sdhci>; clock-names = "emmcclk"; + drive-impedance-ohm = <50>; #phy-cells = <0>; }; }; diff --git a/Documentation/devicetree/bindings/phy/ti,phy-am654-serdes.txt b/Documentation/devicetree/bindings/phy/ti,phy-am654-serdes.txt new file mode 100644 index 000000000000..64b286d2d398 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/ti,phy-am654-serdes.txt @@ -0,0 +1,82 @@ +TI AM654 SERDES + +Required properties: + - compatible: Should be "ti,phy-am654-serdes" + - reg : Address and length of the register set for the device. + - #phy-cells: determine the number of cells that should be given in the + phandle while referencing this phy. Should be "2". The 1st cell + corresponds to the phy type (should be one of the types specified in + include/dt-bindings/phy/phy.h) and the 2nd cell should be the serdes + lane function. + If SERDES0 is referenced 2nd cell should be: + 0 - USB3 + 1 - PCIe0 Lane0 + 2 - ICSS2 SGMII Lane0 + If SERDES1 is referenced 2nd cell should be: + 0 - PCIe1 Lane0 + 1 - PCIe0 Lane1 + 2 - ICSS2 SGMII Lane1 + - power-domains: As documented by the generic PM domain bindings in + Documentation/devicetree/bindings/power/power_domain.txt. + - clocks: List of clock-specifiers representing the input to the SERDES. + Should have 3 items representing the left input clock, external + reference clock and right input clock in that order. + - clock-output-names: List of clock names for each of the clock outputs of + SERDES. Should have 3 items for CMU reference clock, + left output clock and right output clock in that order. + - assigned-clocks: As defined in + Documentation/devicetree/bindings/clock/clock-bindings.txt + - assigned-clock-parents: As defined in + Documentation/devicetree/bindings/clock/clock-bindings.txt + - #clock-cells: Should be <1> to choose between the 3 output clocks. + Defined in Documentation/devicetree/bindings/clock/clock-bindings.txt + + The following macros are defined in dt-bindings/phy/phy-am654-serdes.h + for selecting the correct reference clock. This can be used while + specifying the clocks created by SERDES. + => AM654_SERDES_CMU_REFCLK + => AM654_SERDES_LO_REFCLK + => AM654_SERDES_RO_REFCLK + + - mux-controls: Phandle to the multiplexer that is used to select the lane + function. See #phy-cells above to see the multiplex values. + +Example: + +Example for SERDES0 is given below. It has 3 clock inputs; +left input reference clock as indicated by <&k3_clks 153 4>, external +reference clock as indicated by <&k3_clks 153 1> and right input +reference clock as indicated by <&serdes1 AM654_SERDES_LO_REFCLK>. (The +right input of SERDES0 is connected to the left output of SERDES1). + +SERDES0 registers 3 clock outputs as indicated in clock-output-names. The +first refers to the CMU reference clock, second refers to the left output +reference clock and the third refers to the right output reference clock. + +The assigned-clocks and assigned-clock-parents is used here to set the +parent of left input reference clock to MAINHSDIV_CLKOUT4 and parent of +CMU reference clock to left input reference clock. + +serdes0: serdes@900000 { + compatible = "ti,phy-am654-serdes"; + reg = <0x0 0x900000 0x0 0x2000>; + reg-names = "serdes"; + #phy-cells = <2>; + power-domains = <&k3_pds 153>; + clocks = <&k3_clks 153 4>, <&k3_clks 153 1>, + <&serdes1 AM654_SERDES_LO_REFCLK>; + clock-output-names = "serdes0_cmu_refclk", "serdes0_lo_refclk", + "serdes0_ro_refclk"; + assigned-clocks = <&k3_clks 153 4>, <&serdes0 AM654_SERDES_CMU_REFCLK>; + assigned-clock-parents = <&k3_clks 153 8>, <&k3_clks 153 4>; + ti,serdes-clk = <&serdes0_clk>; + mux-controls = <&serdes_mux 0>; + #clock-cells = <1>; +}; + +Example for PCIe consumer node using the SERDES PHY specifier is given below. +&pcie0_rc { + num-lanes = <2>; + phys = <&serdes0 PHY_TYPE_PCIE 1>, <&serdes1 PHY_TYPE_PCIE 1>; + phy-names = "pcie-phy0", "pcie-phy1"; +}; diff --git a/Documentation/devicetree/bindings/pinctrl/bitmain,bm1880-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/bitmain,bm1880-pinctrl.txt new file mode 100644 index 000000000000..ed34bb1ee81c --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/bitmain,bm1880-pinctrl.txt @@ -0,0 +1,98 @@ +Bitmain BM1880 Pin Controller + +This binding describes the pin controller found in the BM1880 SoC. + +Required Properties: + +- compatible: Should be "bitmain,bm1880-pinctrl" +- reg: Offset and length of pinctrl space in SCTRL. + +Please refer to pinctrl-bindings.txt in this directory for details of the +common pinctrl bindings used by client devices, including the meaning of the +phrase "pin configuration node". + +The pin configuration nodes act as a container for an arbitrary number of +subnodes. Each of these subnodes represents some desired configuration for a +pin, a group, or a list of pins or groups. This configuration for BM1880 SoC +includes only pinmux as there is no pinconf support available in SoC. + +Each configuration node can consist of multiple nodes describing the pinmux +options. The name of each subnode is not important; all subnodes should be +enumerated and processed purely based on their content. + +The following generic properties as defined in pinctrl-bindings.txt are valid +to specify in a pinmux subnode: + +Required Properties: + +- pins: An array of strings, each string containing the name of a pin. + Valid values for pins are: + + MIO0 - MIO111 + +- groups: An array of strings, each string containing the name of a pin + group. Valid values for groups are: + + nand_grp, spi_grp, emmc_grp, sdio_grp, eth0_grp, pwm0_grp, + pwm1_grp, pwm2_grp, pwm3_grp, pwm4_grp, pwm5_grp, pwm6_grp, + pwm7_grp, pwm8_grp, pwm9_grp, pwm10_grp, pwm11_grp, pwm12_grp, + pwm13_grp, pwm14_grp, pwm15_grp, pwm16_grp, pwm17_grp, + pwm18_grp, pwm19_grp, pwm20_grp, pwm21_grp, pwm22_grp, + pwm23_grp, pwm24_grp, pwm25_grp, pwm26_grp, pwm27_grp, + pwm28_grp, pwm29_grp, pwm30_grp, pwm31_grp, pwm32_grp, + pwm33_grp, pwm34_grp, pwm35_grp, pwm36_grp, i2c0_grp, + i2c1_grp, i2c2_grp, i2c3_grp, i2c4_grp, uart0_grp, uart1_grp, + uart2_grp, uart3_grp, uart4_grp, uart5_grp, uart6_grp, + uart7_grp, uart8_grp, uart9_grp, uart10_grp, uart11_grp, + uart12_grp, uart13_grp, uart14_grp, uart15_grp, gpio0_grp, + gpio1_grp, gpio2_grp, gpio3_grp, gpio4_grp, gpio5_grp, + gpio6_grp, gpio7_grp, gpio8_grp, gpio9_grp, gpio10_grp, + gpio11_grp, gpio12_grp, gpio13_grp, gpio14_grp, gpio15_grp, + gpio16_grp, gpio17_grp, gpio18_grp, gpio19_grp, gpio20_grp, + gpio21_grp, gpio22_grp, gpio23_grp, gpio24_grp, gpio25_grp, + gpio26_grp, gpio27_grp, gpio28_grp, gpio29_grp, gpio30_grp, + gpio31_grp, gpio32_grp, gpio33_grp, gpio34_grp, gpio35_grp, + gpio36_grp, gpio37_grp, gpio38_grp, gpio39_grp, gpio40_grp, + gpio41_grp, gpio42_grp, gpio43_grp, gpio44_grp, gpio45_grp, + gpio46_grp, gpio47_grp, gpio48_grp, gpio49_grp, gpio50_grp, + gpio51_grp, gpio52_grp, gpio53_grp, gpio54_grp, gpio55_grp, + gpio56_grp, gpio57_grp, gpio58_grp, gpio59_grp, gpio60_grp, + gpio61_grp, gpio62_grp, gpio63_grp, gpio64_grp, gpio65_grp, + gpio66_grp, gpio67_grp, eth1_grp, i2s0_grp, i2s0_mclkin_grp, + i2s1_grp, i2s1_mclkin_grp, spi0_grp + +- function: An array of strings, each string containing the name of the + pinmux functions. The following are the list of pinmux + functions available: + + nand, spi, emmc, sdio, eth0, pwm0, pwm1, pwm2, pwm3, pwm4, + pwm5, pwm6, pwm7, pwm8, pwm9, pwm10, pwm11, pwm12, pwm13, + pwm14, pwm15, pwm16, pwm17, pwm18, pwm19, pwm20, pwm21, pwm22, + pwm23, pwm24, pwm25, pwm26, pwm27, pwm28, pwm29, pwm30, pwm31, + pwm32, pwm33, pwm34, pwm35, pwm36, i2c0, i2c1, i2c2, i2c3, + i2c4, uart0, uart1, uart2, uart3, uart4, uart5, uart6, uart7, + uart8, uart9, uart10, uart11, uart12, uart13, uart14, uart15, + gpio0, gpio1, gpio2, gpio3, gpio4, gpio5, gpio6, gpio7, gpio8, + gpio9, gpio10, gpio11, gpio12, gpio13, gpio14, gpio15, gpio16, + gpio17, gpio18, gpio19, gpio20, gpio21, gpio22, gpio23, + gpio24, gpio25, gpio26, gpio27, gpio28, gpio29, gpio30, + gpio31, gpio32, gpio33, gpio34, gpio35, gpio36, gpio37, + gpio38, gpio39, gpio40, gpio41, gpio42, gpio43, gpio44, + gpio45, gpio46, gpio47, gpio48, gpio49, gpio50, gpio51, + gpio52, gpio53, gpio54, gpio55, gpio56, gpio57, gpio58, + gpio59, gpio60, gpio61, gpio62, gpio63, gpio64, gpio65, + gpio66, gpio67, eth1, i2s0, i2s0_mclkin, i2s1, i2s1_mclkin, + spi0 + +Example: + pinctrl: pinctrl@50 { + compatible = "bitmain,bm1880-pinctrl"; + reg = <0x50 0x4B0>; + + pinctrl_uart0_default: uart0-default { + pinmux { + groups = "uart0_grp"; + function = "uart0"; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/cirrus,lochnagar.txt b/Documentation/devicetree/bindings/pinctrl/cirrus,lochnagar.txt new file mode 100644 index 000000000000..a87447180e83 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/cirrus,lochnagar.txt @@ -0,0 +1,141 @@ +Cirrus Logic Lochnagar Audio Development Board + +Lochnagar is an evaluation and development board for Cirrus Logic +Smart CODEC and Amp devices. It allows the connection of most Cirrus +Logic devices on mini-cards, as well as allowing connection of +various application processor systems to provide a full evaluation +platform. Audio system topology, clocking and power can all be +controlled through the Lochnagar, allowing the device under test +to be used in a variety of possible use cases. + +This binding document describes the binding for the pinctrl portion +of the driver. + +Also see these documents for generic binding information: + [1] GPIO : ../gpio/gpio.txt + [2] Pinctrl: ../pinctrl/pinctrl-bindings.txt + +And these for relevant defines: + [3] include/dt-bindings/pinctrl/lochnagar.h + +This binding must be part of the Lochnagar MFD binding: + [4] ../mfd/cirrus,lochnagar.txt + +Required properties: + + - compatible : One of the following strings: + "cirrus,lochnagar-pinctrl" + + - gpio-controller : Indicates this device is a GPIO controller. + - #gpio-cells : Must be 2. The first cell is the pin number, see + [3] for available pins and the second cell is used to specify + optional parameters, see [1]. + - gpio-ranges : Range of pins managed by the GPIO controller, see + [1]. Both the GPIO and Pinctrl base should be set to zero and the + count to the appropriate of the LOCHNAGARx_PIN_NUM_GPIOS define, + see [3]. + + - pinctrl-names : A pinctrl state named "default" must be defined. + - pinctrl-0 : A phandle to the default pinctrl state. + +Required sub-nodes: + +The pin configurations are defined as a child of the pinctrl states +node, see [2]. Each sub-node can have the following properties: + - groups : A list of groups to select (either this or "pins" must be + specified), available groups: + codec-aif1, codec-aif2, codec-aif3, dsp-aif1, dsp-aif2, psia1, + psia2, gf-aif1, gf-aif2, gf-aif3, gf-aif4, spdif-aif, usb-aif1, + usb-aif2, adat-aif, soundcard-aif + - pins : A list of pin names to select (either this or "groups" must + be specified), available pins: + fpga-gpio1, fpga-gpio2, fpga-gpio3, fpga-gpio4, fpga-gpio5, + fpga-gpio6, codec-gpio1, codec-gpio2, codec-gpio3, codec-gpio4, + codec-gpio5, codec-gpio6, codec-gpio7, codec-gpio8, dsp-gpio1, + dsp-gpio2, dsp-gpio3, dsp-gpio4, dsp-gpio5, dsp-gpio6, gf-gpio2, + gf-gpio3, gf-gpio7, codec-aif1-bclk, codec-aif1-rxdat, + codec-aif1-lrclk, codec-aif1-txdat, codec-aif2-bclk, + codec-aif2-rxdat, codec-aif2-lrclk, codec-aif2-txdat, + codec-aif3-bclk, codec-aif3-rxdat, codec-aif3-lrclk, + codec-aif3-txdat, dsp-aif1-bclk, dsp-aif1-rxdat, dsp-aif1-lrclk, + dsp-aif1-txdat, dsp-aif2-bclk, dsp-aif2-rxdat, + dsp-aif2-lrclk, dsp-aif2-txdat, psia1-bclk, psia1-rxdat, + psia1-lrclk, psia1-txdat, psia2-bclk, psia2-rxdat, psia2-lrclk, + psia2-txdat, gf-aif3-bclk, gf-aif3-rxdat, gf-aif3-lrclk, + gf-aif3-txdat, gf-aif4-bclk, gf-aif4-rxdat, gf-aif4-lrclk, + gf-aif4-txdat, gf-aif1-bclk, gf-aif1-rxdat, gf-aif1-lrclk, + gf-aif1-txdat, gf-aif2-bclk, gf-aif2-rxdat, gf-aif2-lrclk, + gf-aif2-txdat, dsp-uart1-rx, dsp-uart1-tx, dsp-uart2-rx, + dsp-uart2-tx, gf-uart2-rx, gf-uart2-tx, usb-uart-rx, + codec-pdmclk1, codec-pdmdat1, codec-pdmclk2, codec-pdmdat2, + codec-dmicclk1, codec-dmicdat1, codec-dmicclk2, codec-dmicdat2, + codec-dmicclk3, codec-dmicdat3, codec-dmicclk4, codec-dmicdat4, + dsp-dmicclk1, dsp-dmicdat1, dsp-dmicclk2, dsp-dmicdat2, i2c2-scl, + i2c2-sda, i2c3-scl, i2c3-sda, i2c4-scl, i2c4-sda, dsp-standby, + codec-mclk1, codec-mclk2, dsp-clkin, psia1-mclk, psia2-mclk, + gf-gpio1, gf-gpio5, dsp-gpio20, led1, led2 + - function : The mux function to select, available functions: + aif, fpga-gpio1, fpga-gpio2, fpga-gpio3, fpga-gpio4, fpga-gpio5, + fpga-gpio6, codec-gpio1, codec-gpio2, codec-gpio3, codec-gpio4, + codec-gpio5, codec-gpio6, codec-gpio7, codec-gpio8, dsp-gpio1, + dsp-gpio2, dsp-gpio3, dsp-gpio4, dsp-gpio5, dsp-gpio6, gf-gpio2, + gf-gpio3, gf-gpio7, gf-gpio1, gf-gpio5, dsp-gpio20, codec-clkout, + dsp-clkout, pmic-32k, spdif-clkout, clk-12m288, clk-11m2986, + clk-24m576, clk-22m5792, xmos-mclk, gf-clkout1, gf-mclk1, + gf-mclk3, gf-mclk2, gf-clkout2, codec-mclk1, codec-mclk2, + dsp-clkin, psia1-mclk, psia2-mclk, spdif-mclk, codec-irq, + codec-reset, dsp-reset, dsp-irq, dsp-standby, codec-pdmclk1, + codec-pdmdat1, codec-pdmclk2, codec-pdmdat2, codec-dmicclk1, + codec-dmicdat1, codec-dmicclk2, codec-dmicdat2, codec-dmicclk3, + codec-dmicdat3, codec-dmicclk4, codec-dmicdat4, dsp-dmicclk1, + dsp-dmicdat1, dsp-dmicclk2, dsp-dmicdat2, dsp-uart1-rx, + dsp-uart1-tx, dsp-uart2-rx, dsp-uart2-tx, gf-uart2-rx, + gf-uart2-tx, usb-uart-rx, usb-uart-tx, i2c2-scl, i2c2-sda, + i2c3-scl, i2c3-sda, i2c4-scl, i2c4-sda, spdif-aif, psia1, + psia1-bclk, psia1-lrclk, psia1-rxdat, psia1-txdat, psia2, + psia2-bclk, psia2-lrclk, psia2-rxdat, psia2-txdat, codec-aif1, + codec-aif1-bclk, codec-aif1-lrclk, codec-aif1-rxdat, + codec-aif1-txdat, codec-aif2, codec-aif2-bclk, codec-aif2-lrclk, + codec-aif2-rxdat, codec-aif2-txdat, codec-aif3, codec-aif3-bclk, + codec-aif3-lrclk, codec-aif3-rxdat, codec-aif3-txdat, dsp-aif1, + dsp-aif1-bclk, dsp-aif1-lrclk, dsp-aif1-rxdat, dsp-aif1-txdat, + dsp-aif2, dsp-aif2-bclk, dsp-aif2-lrclk, dsp-aif2-rxdat, + dsp-aif2-txdat, gf-aif3, gf-aif3-bclk, gf-aif3-lrclk, + gf-aif3-rxdat, gf-aif3-txdat, gf-aif4, gf-aif4-bclk, + gf-aif4-lrclk, gf-aif4-rxdat, gf-aif4-txdat, gf-aif1, + gf-aif1-bclk, gf-aif1-lrclk, gf-aif1-rxdat, gf-aif1-txdat, + gf-aif2, gf-aif2-bclk, gf-aif2-lrclk, gf-aif2-rxdat, + gf-aif2-txdat, usb-aif1, usb-aif2, adat-aif, soundcard-aif, + + - output-enable : Specifies that an AIF group will be used as a master + interface (either this or input-enable is required if a group is + being muxed to an AIF) + - input-enable : Specifies that an AIF group will be used as a slave + interface (either this or output-enable is required if a group is + being muxed to an AIF) + +Example: + +lochnagar-pinctrl { + compatible = "cirrus,lochnagar-pinctrl"; + + gpio-controller; + #gpio-cells = <2>; + gpio-ranges = <&lochnagar 0 0 LOCHNAGAR2_PIN_NUM_GPIOS>; + + pinctrl-names = "default"; + pinctrl-0 = <&pin-settings>; + + pin-settings: pin-settings { + ap-aif { + input-enable; + groups = "gf-aif1"; + function = "codec-aif3"; + }; + codec-aif { + output-enable; + groups = "codec-aif3"; + function = "gf-aif1"; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx7d-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx7d-pinctrl.txt index 6666277c3acb..8ac1d0851a0f 100644 --- a/Documentation/devicetree/bindings/pinctrl/fsl,imx7d-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx7d-pinctrl.txt @@ -48,9 +48,9 @@ PAD_CTL_HYS (1 << 3) PAD_CTL_SRE_SLOW (1 << 2) PAD_CTL_SRE_FAST (0 << 2) PAD_CTL_DSE_X1 (0 << 0) -PAD_CTL_DSE_X2 (1 << 0) -PAD_CTL_DSE_X3 (2 << 0) -PAD_CTL_DSE_X4 (3 << 0) +PAD_CTL_DSE_X4 (1 << 0) +PAD_CTL_DSE_X2 (2 << 0) +PAD_CTL_DSE_X6 (3 << 0) Examples: While iomuxc-lpsr is intended to be used by dedicated peripherals to take diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt index e7d6f81c227f..205be98ae078 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt @@ -11,6 +11,7 @@ Required properties: "mediatek,mt8127-pinctrl", compatible with mt8127 pinctrl. "mediatek,mt8135-pinctrl", compatible with mt8135 pinctrl. "mediatek,mt8173-pinctrl", compatible with mt8173 pinctrl. + "mediatek,mt8516-pinctrl", compatible with mt8516 pinctrl. - pins-are-numbered: Specify the subnodes are using numbered pinmux to specify pins. - gpio-controller : Marks the device node as a gpio controller. diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8183.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8183.txt new file mode 100644 index 000000000000..eccbe3f55d3f --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8183.txt @@ -0,0 +1,132 @@ +* Mediatek MT8183 Pin Controller + +The Mediatek's Pin controller is used to control SoC pins. + +Required properties: +- compatible: value should be one of the following. + "mediatek,mt8183-pinctrl", compatible with mt8183 pinctrl. +- gpio-controller : Marks the device node as a gpio controller. +- #gpio-cells: number of cells in GPIO specifier. Since the generic GPIO + binding is used, the amount of cells must be specified as 2. See the below + mentioned gpio binding representation for description of particular cells. +- gpio-ranges : gpio valid number range. +- reg: physical address base for gpio base registers. There are 10 GPIO + physical address base in mt8183. + +Optional properties: +- reg-names: gpio base register names. There are 10 gpio base register + names in mt8183. They are "iocfg0", "iocfg1", "iocfg2", "iocfg3", "iocfg4", + "iocfg5", "iocfg6", "iocfg7", "iocfg8", "eint". +- interrupt-controller: Marks the device node as an interrupt controller +- #interrupt-cells: Should be two. +- interrupts : The interrupt outputs to sysirq. + +Please refer to pinctrl-bindings.txt in this directory for details of the +common pinctrl bindings used by client devices. + +Subnode format +A pinctrl node should contain at least one subnodes representing the +pinctrl groups available on the machine. Each subnode will list the +pins it needs, and how they should be configured, with regard to muxer +configuration, pullups, drive strength, input enable/disable and input schmitt. + + node { + pinmux = <PIN_NUMBER_PINMUX>; + GENERIC_PINCONFIG; + }; + +Required properties: +- pinmux: integer array, represents gpio pin number and mux setting. + Supported pin number and mux varies for different SoCs, and are defined + as macros in boot/dts/<soc>-pinfunc.h directly. + +Optional properties: +- GENERIC_PINCONFIG: is the generic pinconfig options to use, bias-disable, + bias-pull-down, bias-pull-up, input-enable, input-disable, output-low, + output-high, input-schmitt-enable, input-schmitt-disable + and drive-strength are valid. + + Some special pins have extra pull up strength, there are R0 and R1 pull-up + resistors available, but for user, it's only need to set R1R0 as 00, 01, + 10 or 11. So It needs config "mediatek,pull-up-adv" or + "mediatek,pull-down-adv" to support arguments for those special pins. + Valid arguments are from 0 to 3. + + mediatek,tdsel: An integer describing the steps for output level shifter + duty cycle when asserted (high pulse width adjustment). Valid arguments + are from 0 to 15. + mediatek,rdsel: An integer describing the steps for input level shifter + duty cycle when asserted (high pulse width adjustment). Valid arguments + are from 0 to 63. + + When config drive-strength, it can support some arguments, such as + MTK_DRIVE_4mA, MTK_DRIVE_6mA, etc. See dt-bindings/pinctrl/mt65xx.h. + It can only support 2/4/6/8/10/12/14/16mA in mt8183. + For I2C pins, there are existing generic driving setup and the specific + driving setup. I2C pins can only support 2/4/6/8/10/12/14/16mA driving + adjustment in generic driving setup. But in specific driving setup, + they can support 0.125/0.25/0.5/1mA adjustment. If we enable specific + driving setup for I2C pins, the existing generic driving setup will be + disabled. For some special features, we need the I2C pins specific + driving setup. The specific driving setup is controlled by E1E0EN. + So we need add extra vendor driving preperty instead of + the generic driving property. + We can add "mediatek,drive-strength-adv = <XXX>;" to describe the specific + driving setup property. "XXX" means the value of E1E0EN. EN is 0 or 1. + It is used to enable or disable the specific driving setup. + E1E0 is used to describe the detail strength specification of the I2C pin. + When E1=0/E0=0, the strength is 0.125mA. + When E1=0/E0=1, the strength is 0.25mA. + When E1=1/E0=0, the strength is 0.5mA. + When E1=1/E0=1, the strength is 1mA. + So the valid arguments of "mediatek,drive-strength-adv" are from 0 to 7. + +Examples: + +#include "mt8183-pinfunc.h" + +... +{ + pio: pinctrl@10005000 { + compatible = "mediatek,mt8183-pinctrl"; + reg = <0 0x10005000 0 0x1000>, + <0 0x11f20000 0 0x1000>, + <0 0x11e80000 0 0x1000>, + <0 0x11e70000 0 0x1000>, + <0 0x11e90000 0 0x1000>, + <0 0x11d30000 0 0x1000>, + <0 0x11d20000 0 0x1000>, + <0 0x11c50000 0 0x1000>, + <0 0x11f30000 0 0x1000>, + <0 0x1000b000 0 0x1000>; + reg-names = "iocfg0", "iocfg1", "iocfg2", + "iocfg3", "iocfg4", "iocfg5", + "iocfg6", "iocfg7", "iocfg8", + "eint"; + gpio-controller; + #gpio-cells = <2>; + gpio-ranges = <&pio 0 0 192>; + interrupt-controller; + interrupts = <GIC_SPI 177 IRQ_TYPE_LEVEL_HIGH>; + #interrupt-cells = <2>; + + i2c0_pins_a: i2c0 { + pins1 { + pinmux = <PINMUX_GPIO48__FUNC_SCL5>, + <PINMUX_GPIO49__FUNC_SDA5>; + mediatek,pull-up-adv = <3>; + mediatek,drive-strength-adv = <7>; + }; + }; + + i2c1_pins_a: i2c1 { + pins { + pinmux = <PINMUX_GPIO50__FUNC_SCL3>, + <PINMUX_GPIO51__FUNC_SDA3>; + mediatek,pull-down-adv = <2>; + mediatek,drive-strength-adv = <4>; + }; + }; + ... + }; +}; diff --git a/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt index 48df30a36b01..00169255e48c 100644 --- a/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt @@ -57,6 +57,8 @@ Optional properties: - st,bank-ioport: should correspond to the EXTI IOport selection (EXTI line used to select GPIOs as interrupts). - hwlocks: reference to a phandle of a hardware spinlock provider node. + - st,package: Indicates the SOC package used. + More details in include/dt-bindings/pinctrl/stm32-pinfunc.h Example 1: #include <dt-bindings/pinctrl/stm32f429-pinfunc.h> diff --git a/Documentation/devicetree/bindings/serial/cdns,uart.txt b/Documentation/devicetree/bindings/serial/cdns,uart.txt index 227bb770b027..4efc560f90ab 100644 --- a/Documentation/devicetree/bindings/serial/cdns,uart.txt +++ b/Documentation/devicetree/bindings/serial/cdns,uart.txt @@ -12,6 +12,11 @@ Required properties: See ../clocks/clock-bindings.txt for details. +Optional properties: +- cts-override : Override the CTS modem status signal. This signal will + always be reported as active instead of being obtained from the modem status + register. Define this if your serial port does not use this pin + Example: uart@e0000000 { compatible = "cdns,uart-r1p8"; diff --git a/Documentation/devicetree/bindings/serial/nxp,sc16is7xx.txt b/Documentation/devicetree/bindings/serial/nxp,sc16is7xx.txt index e7921a8e276b..c1091a923a89 100644 --- a/Documentation/devicetree/bindings/serial/nxp,sc16is7xx.txt +++ b/Documentation/devicetree/bindings/serial/nxp,sc16is7xx.txt @@ -12,6 +12,8 @@ Required properties: - reg: I2C address of the SC16IS7xx device. - interrupts: Should contain the UART interrupt - clocks: Reference to the IC source clock. + OR (when there is no clock provider visible to the platform) +- clock-frequency: The source clock frequency for the IC. Optional properties: - gpio-controller: Marks the device node as a GPIO controller. diff --git a/Documentation/devicetree/bindings/serial/sifive-serial.txt b/Documentation/devicetree/bindings/serial/sifive-serial.txt new file mode 100644 index 000000000000..c86b1e524159 --- /dev/null +++ b/Documentation/devicetree/bindings/serial/sifive-serial.txt @@ -0,0 +1,33 @@ +SiFive asynchronous serial interface (UART) + +Required properties: + +- compatible: should be something similar to + "sifive,<chip>-uart" for the UART as integrated + on a particular chip, and "sifive,uart<version>" for the + general UART IP block programming model. Supported + compatible strings as of the date of this writing are: + "sifive,fu540-c000-uart" for the SiFive UART v0 as + integrated onto the SiFive FU540 chip, or "sifive,uart0" + for the SiFive UART v0 IP block with no chip integration + tweaks (if any) +- reg: address and length of the register space +- interrupts: Should contain the UART interrupt identifier +- clocks: Should contain a clock identifier for the UART's parent clock + + +UART HDL that corresponds to the IP block version numbers can be found +here: + +https://github.com/sifive/sifive-blocks/tree/master/src/main/scala/devices/uart + + +Example: + +uart0: serial@10010000 { + compatible = "sifive,fu540-c000-uart", "sifive,uart0"; + interrupt-parent = <&plic0>; + interrupts = <80>; + reg = <0x0 0x10010000 0x0 0x1000>; + clocks = <&prci PRCI_CLK_TLCLK>; +}; diff --git a/Documentation/devicetree/bindings/serial/sprd-uart.txt b/Documentation/devicetree/bindings/serial/sprd-uart.txt index cab40f0f6f49..9607dc616205 100644 --- a/Documentation/devicetree/bindings/serial/sprd-uart.txt +++ b/Documentation/devicetree/bindings/serial/sprd-uart.txt @@ -7,7 +7,17 @@ Required properties: - reg: offset and length of the register set for the device - interrupts: exactly one interrupt specifier -- clocks: phandles to input clocks. +- clock-names: Should contain following entries: + "enable" for UART module enable clock, + "uart" for UART clock, + "source" for UART source (parent) clock. +- clocks: Should contain a clock specifier for each entry in clock-names. + UART clock and source clock are optional properties, but enable clock + is required. + +Optional properties: +- dma-names: Should contain "rx" for receive and "tx" for transmit channels. +- dmas: A list of dma specifiers, one for each entry in dma-names. Example: uart0: serial@0 { @@ -15,5 +25,8 @@ Example: "sprd,sc9836-uart"; reg = <0x0 0x100>; interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&ext_26m>; + dma-names = "rx", "tx"; + dmas = <&ap_dma 19>, <&ap_dma 20>; + clock-names = "enable", "uart", "source"; + clocks = <&clk_ap_apb_gates 9>, <&clk_uart0>, <&ext_26m>; }; diff --git a/Documentation/devicetree/bindings/ufs/cdns,ufshc.txt b/Documentation/devicetree/bindings/ufs/cdns,ufshc.txt index a04a4989ec7f..02347b017abd 100644 --- a/Documentation/devicetree/bindings/ufs/cdns,ufshc.txt +++ b/Documentation/devicetree/bindings/ufs/cdns,ufshc.txt @@ -5,8 +5,9 @@ Each UFS controller instance should have its own node. Please see the ufshcd-pltfrm.txt for a list of all available properties. Required properties: -- compatible : Compatible list, contains the following controller: - "cdns,ufshc" +- compatible : Compatible list, contains one of the following controllers: + "cdns,ufshc" - Generic CDNS HCI, + "cdns,ufshc-m31-16nm" - CDNS UFS HC + M31 16nm PHY complemented with the JEDEC version: "jedec,ufs-2.0" diff --git a/Documentation/devicetree/bindings/ufs/ufs-mediatek.txt b/Documentation/devicetree/bindings/ufs/ufs-mediatek.txt new file mode 100644 index 000000000000..72aab8547308 --- /dev/null +++ b/Documentation/devicetree/bindings/ufs/ufs-mediatek.txt @@ -0,0 +1,43 @@ +* Mediatek Universal Flash Storage (UFS) Host Controller + +UFS nodes are defined to describe on-chip UFS hardware macro. +Each UFS Host Controller should have its own node. + +To bind UFS PHY with UFS host controller, the controller node should +contain a phandle reference to UFS M-PHY node. + +Required properties for UFS nodes: +- compatible : Compatible list, contains the following controller: + "mediatek,mt8183-ufshci" for MediaTek UFS host controller + present on MT81xx chipsets. +- reg : Address and length of the UFS register set. +- phys : phandle to m-phy. +- clocks : List of phandle and clock specifier pairs. +- clock-names : List of clock input name strings sorted in the same + order as the clocks property. "ufs" is mandatory. + "ufs": ufshci core control clock. +- freq-table-hz : Array of <min max> operating frequencies stored in the same + order as the clocks property. If this property is not + defined or a value in the array is "0" then it is assumed + that the frequency is set by the parent clock or a + fixed rate clock source. +- vcc-supply : phandle to VCC supply regulator node. + +Example: + + ufsphy: phy@11fa0000 { + ... + }; + + ufshci@11270000 { + compatible = "mediatek,mt8183-ufshci"; + reg = <0 0x11270000 0 0x2300>; + interrupts = <GIC_SPI 104 IRQ_TYPE_LEVEL_LOW>; + phys = <&ufsphy>; + + clocks = <&infracfg_ao INFRACFG_AO_UFS_CG>; + clock-names = "ufs"; + freq-table-hz = <0 0>; + + vcc-supply = <&mt_pmic_vemc_ldo_reg>; + }; diff --git a/Documentation/devicetree/bindings/ufs/ufs-qcom.txt b/Documentation/devicetree/bindings/ufs/ufs-qcom.txt index 21d9a93db2e9..fd59f93e9556 100644 --- a/Documentation/devicetree/bindings/ufs/ufs-qcom.txt +++ b/Documentation/devicetree/bindings/ufs/ufs-qcom.txt @@ -29,6 +29,7 @@ Optional properties: - vdda-pll-max-microamp : specifies max. load that can be drawn from pll supply - vddp-ref-clk-supply : phandle to UFS device ref_clk pad power supply - vddp-ref-clk-max-microamp : specifies max. load that can be drawn from this supply +- resets : specifies the PHY reset in the UFS controller Example: @@ -51,9 +52,11 @@ Example: <&clock_gcc clk_ufs_phy_ldo>, <&clock_gcc clk_gcc_ufs_tx_cfg_clk>, <&clock_gcc clk_gcc_ufs_rx_cfg_clk>; + resets = <&ufshc 0>; }; - ufshc@fc598000 { + ufshc: ufshc@fc598000 { + #reset-cells = <1>; ... phys = <&ufsphy1>; phy-names = "ufsphy"; diff --git a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt index 5111e9130bc3..56bccde9953a 100644 --- a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt +++ b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt @@ -31,7 +31,6 @@ Optional properties: - vcc-max-microamp : specifies max. load that can be drawn from vcc supply - vccq-max-microamp : specifies max. load that can be drawn from vccq supply - vccq2-max-microamp : specifies max. load that can be drawn from vccq2 supply -- <name>-fixed-regulator : boolean property specifying that <name>-supply is a fixed regulator - clocks : List of phandle and clock specifier pairs - clock-names : List of clock input name strings sorted in the same @@ -50,6 +49,8 @@ Optional properties: -lanes-per-direction : number of lanes available per direction - either 1 or 2. Note that it is assume same number of lanes is used both directions at once. If not specified, default is 2 lanes per direction. +- #reset-cells : Must be <1> for Qualcomm UFS controllers that expose + PHY reset from the UFS controller. - resets : reset node register - reset-names : describe reset node register, the "rst" corresponds to reset the whole UFS IP. @@ -63,7 +64,6 @@ Example: interrupts = <0 28 0>; vdd-hba-supply = <&xxx_reg0>; - vdd-hba-fixed-regulator; vcc-supply = <&xxx_reg1>; vcc-supply-1p8; vccq-supply = <&xxx_reg2>; @@ -79,4 +79,5 @@ Example: reset-names = "rst"; phys = <&ufsphy1>; phy-names = "ufsphy"; + #reset-cells = <1>; }; diff --git a/Documentation/devicetree/bindings/usb/amlogic,dwc3.txt b/Documentation/devicetree/bindings/usb/amlogic,dwc3.txt index 9a8b631904fd..b9f04e617eb7 100644 --- a/Documentation/devicetree/bindings/usb/amlogic,dwc3.txt +++ b/Documentation/devicetree/bindings/usb/amlogic,dwc3.txt @@ -40,3 +40,91 @@ Example device nodes: phy-names = "usb2-phy", "usb3-phy"; }; }; + +Amlogic Meson G12A DWC3 USB SoC Controller Glue + +The Amlogic G12A embeds a DWC3 USB IP Core configured for USB2 and USB3 +in host-only mode, and a DWC2 IP Core configured for USB2 peripheral mode +only. + +A glue connects the DWC3 core to USB2 PHYs and optionnaly to an USB3 PHY. + +One of the USB2 PHY can be re-routed in peripheral mode to a DWC2 USB IP. + +The DWC3 Glue controls the PHY routing and power, an interrupt line is +connected to the Glue to serve as OTG ID change detection. + +Required properties: +- compatible: Should be "amlogic,meson-g12a-usb-ctrl" +- clocks: a handle for the "USB" clock +- resets: a handle for the shared "USB" reset line +- reg: The base address and length of the registers +- interrupts: the interrupt specifier for the OTG detection +- phys: handle to used PHYs on the system + - a <0> phandle can be used if a PHY is not used +- phy-names: names of the used PHYs on the system : + - "usb2-phy0" for USB2 PHY0 if USBHOST_A port is used + - "usb2-phy1" for USB2 PHY1 if USBOTG_B port is used + - "usb3-phy0" for USB3 PHY if USB3_0 is used +- dr_mode: should be "host", "peripheral", or "otg" depending on + the usage and configuration of the OTG Capable port. + - "host" and "peripheral" means a fixed Host or Device only connection + - "otg" means the port can be used as both Host or Device and + be switched automatically using the OTG ID pin. + +Optional properties: +- vbus-supply: should be a phandle to the regulator controlling the VBUS + power supply when used in OTG switchable mode + +Required child nodes: + +A child node must exist to represent the core DWC3 IP block. The name of +the node is not important. The content of the node is defined in dwc3.txt. + +A child node must exist to represent the core DWC2 IP block. The name of +the node is not important. The content of the node is defined in dwc2.txt. + +PHY documentation is provided in the following places: +- Documentation/devicetree/bindings/phy/meson-g12a-usb2-phy.txt +- Documentation/devicetree/bindings/phy/meson-g12a-usb3-pcie-phy.txt + +Example device nodes: + usb: usb@ffe09000 { + compatible = "amlogic,meson-g12a-usb-ctrl"; + reg = <0x0 0xffe09000 0x0 0xa0>; + interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>; + #address-cells = <2>; + #size-cells = <2>; + ranges; + + clocks = <&clkc CLKID_USB>; + resets = <&reset RESET_USB>; + + dr_mode = "otg"; + + phys = <&usb2_phy0>, <&usb2_phy1>, + <&usb3_pcie_phy PHY_TYPE_USB3>; + phy-names = "usb2-phy0", "usb2-phy1", "usb3-phy0"; + + dwc2: usb@ff400000 { + compatible = "amlogic,meson-g12a-usb", "snps,dwc2"; + reg = <0x0 0xff400000 0x0 0x40000>; + interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clkc CLKID_USB1_DDR_BRIDGE>; + clock-names = "ddr"; + phys = <&usb2_phy1>; + dr_mode = "peripheral"; + g-rx-fifo-size = <192>; + g-np-tx-fifo-size = <128>; + g-tx-fifo-size = <128 128 16 16 16>; + }; + + dwc3: usb@ff500000 { + compatible = "snps,dwc3"; + reg = <0x0 0xff500000 0x0 0x100000>; + interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>; + dr_mode = "host"; + snps,dis_u2_susphy_quirk; + snps,quirk-frame-length-adjustment; + }; + }; diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt b/Documentation/devicetree/bindings/usb/dwc2.txt index 6dc3c4a34483..49eac0dc86b0 100644 --- a/Documentation/devicetree/bindings/usb/dwc2.txt +++ b/Documentation/devicetree/bindings/usb/dwc2.txt @@ -14,6 +14,7 @@ Required properties: - "amlogic,meson8-usb": The DWC2 USB controller instance in Amlogic Meson8 SoCs; - "amlogic,meson8b-usb": The DWC2 USB controller instance in Amlogic Meson8b SoCs; - "amlogic,meson-gxbb-usb": The DWC2 USB controller instance in Amlogic S905 SoCs; + - "amlogic,meson-g12a-usb": The DWC2 USB controller instance in Amlogic G12A SoCs; - "amcc,dwc-otg": The DWC2 USB controller instance in AMCC Canyonlands 460EX SoCs; - snps,dwc2: A generic DWC2 USB controller with default parameters. - "st,stm32f4x9-fsotg": The DWC2 USB FS/HS controller instance in STM32F4x9 SoCs @@ -31,12 +32,18 @@ Refer to clk/clock-bindings.txt for generic clock consumer properties Optional properties: - phys: phy provider specifier - phy-names: shall be "usb2-phy" +- vbus-supply: reference to the VBUS regulator. Depending on the current mode + this is enabled (in "host" mode") or disabled (in "peripheral" mode). The + regulator is updated if the controller is configured in "otg" mode and the + status changes between "host" and "peripheral". Refer to phy/phy-bindings.txt for generic phy consumer properties - dr_mode: shall be one of "host", "peripheral" and "otg" Refer to usb/generic.txt - g-rx-fifo-size: size of rx fifo size in gadget mode. - g-np-tx-fifo-size: size of non-periodic tx fifo size in gadget mode. - g-tx-fifo-size: size of periodic tx fifo per endpoint (except ep0) in gadget mode. +- snps,reset-phy-on-wake: If present indicates that we need to reset the PHY when + we detect a wakeup. This is due to a hardware errata. Deprecated properties: - g-use-dma: gadget DMA mode is automatically detected diff --git a/Documentation/devicetree/bindings/usb/generic-ehci.yaml b/Documentation/devicetree/bindings/usb/generic-ehci.yaml new file mode 100644 index 000000000000..d3b4f6415920 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/generic-ehci.yaml @@ -0,0 +1,95 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/generic-ehci.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: USB EHCI Controller Device Tree Bindings + +allOf: + - $ref: "usb-hcd.yaml" + +maintainers: + - Greg Kroah-Hartman <gregkh@linuxfoundation.org> + +properties: + compatible: + contains: + const: generic-ehci + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + resets: + minItems: 1 + maxItems: 4 + + clocks: + minItems: 1 + maxItems: 4 + description: | + In case the Renesas R-Car Gen3 SoCs: + - if a host only channel: first clock should be host. + - if a USB DRD channel: first clock should be host and second + one should be peripheral + + big-endian: + $ref: /schemas/types.yaml#/definitions/flag + description: + Set this flag for HCDs with big endian descriptors and big + endian registers. + + big-endian-desc: + $ref: /schemas/types.yaml#/definitions/flag + description: + Set this flag for HCDs with big endian descriptors. + + big-endian-regs: + $ref: /schemas/types.yaml#/definitions/flag + description: + Set this flag for HCDs with big endian registers. + + has-transaction-translator: + $ref: /schemas/types.yaml#/definitions/flag + description: + Set this flag if EHCI has a Transaction Translator built into + the root hub. + + needs-reset-on-resume: + $ref: /schemas/types.yaml#/definitions/flag + description: + Set this flag to force EHCI reset after resume. + + phys: true + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +examples: + - | + ehci@e0000300 { + compatible = "ibm,usb-ehci-440epx", "generic-ehci"; + interrupt-parent = <&UIC0>; + interrupts = <0x1a 4>; + reg = <0 0xe0000300 90 0 0xe0000390 70>; + big-endian; + }; + + - | + ehci0: usb@1c14000 { + compatible = "allwinner,sun4i-a10-ehci", "generic-ehci"; + reg = <0x01c14000 0x100>; + interrupts = <39>; + clocks = <&ahb_gates 1>; + phys = <&usbphy 1>; + phy-names = "usb"; + }; + +... diff --git a/Documentation/devicetree/bindings/usb/generic-ohci.yaml b/Documentation/devicetree/bindings/usb/generic-ohci.yaml new file mode 100644 index 000000000000..da5a14becbe5 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/generic-ohci.yaml @@ -0,0 +1,89 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/generic-ohci.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: USB OHCI Controller Device Tree Bindings + +allOf: + - $ref: "usb-hcd.yaml" + +maintainers: + - Greg Kroah-Hartman <gregkh@linuxfoundation.org> + +properties: + compatible: + contains: + const: generic-ohci + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + resets: + minItems: 1 + maxItems: 2 + + clocks: + minItems: 1 + maxItems: 3 + description: | + In case the Renesas R-Car Gen3 SoCs: + - if a host only channel: first clock should be host. + - if a USB DRD channel: first clock should be host and second + one should be peripheral + + big-endian: + $ref: /schemas/types.yaml#/definitions/flag + description: + Set this flag for HCDs with big endian descriptors and big + endian registers. + + big-endian-desc: + $ref: /schemas/types.yaml#/definitions/flag + description: + Set this flag for HCDs with big endian descriptors. + + big-endian-regs: + $ref: /schemas/types.yaml#/definitions/flag + description: + Set this flag for HCDs with big endian registers. + + remote-wakeup-connected: + $ref: /schemas/types.yaml#/definitions/flag + description: + Remote wakeup is wired on the platform. + + no-big-frame-no: + $ref: /schemas/types.yaml#/definitions/flag + description: + Set if frame_no lives in bits [15:0] of HCCA + + num-ports: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Overrides the detected port count + + phys: true + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +examples: + - | + ohci0: usb@1c14400 { + compatible = "allwinner,sun4i-a10-ohci", "generic-ohci"; + reg = <0x01c14400 0x100>; + interrupts = <64>; + clocks = <&usb_clk 6>, <&ahb_gates 2>; + phys = <&usbphy 1>; + }; + +... diff --git a/Documentation/devicetree/bindings/usb/ingenic,jz4740-musb.txt b/Documentation/devicetree/bindings/usb/ingenic,jz4740-musb.txt index 620355cee63f..16808721f3ff 100644 --- a/Documentation/devicetree/bindings/usb/ingenic,jz4740-musb.txt +++ b/Documentation/devicetree/bindings/usb/ingenic,jz4740-musb.txt @@ -8,9 +8,15 @@ Required properties: - interrupt-names: must be "mc" - clocks: phandle to the "udc" clock - clock-names: must be "udc" +- phys: phandle to the USB PHY Example: +usb_phy: usb-phy@0 { + compatible = "usb-nop-xceiv"; + #phy-cells = <0>; +}; + udc: usb@13040000 { compatible = "ingenic,jz4740-musb"; reg = <0x13040000 0x10000>; @@ -21,4 +27,6 @@ udc: usb@13040000 { clocks = <&cgu JZ4740_CLK_UDC>; clock-names = "udc"; + + phys = <&usb_phy>; }; diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/usb/nvidia,tegra124-xusb.txt index 4156c3e181c5..5bfcc0b4d6b9 100644 --- a/Documentation/devicetree/bindings/usb/nvidia,tegra124-xusb.txt +++ b/Documentation/devicetree/bindings/usb/nvidia,tegra124-xusb.txt @@ -10,6 +10,7 @@ Required properties: - Tegra124: "nvidia,tegra124-xusb" - Tegra132: "nvidia,tegra132-xusb", "nvidia,tegra124-xusb" - Tegra210: "nvidia,tegra210-xusb" + - Tegra186: "nvidia,tegra186-xusb" - reg: Must contain the base and length of the xHCI host registers, XUSB FPCI registers and XUSB IPFS registers. - reg-names: Must contain the following entries: @@ -59,6 +60,8 @@ For Tegra210: - avdd-pll-uerefe-supply: PLLE reference PLL power supply. Must supply 1.05 V. - dvdd-pex-pll-supply: PCIe/USB3 PLL power supply. Must supply 1.05 V. - hvdd-pex-pll-e-supply: High-voltage PLLE power supply. Must supply 1.8 V. + +For Tegra210 and Tegra186: - power-domains: A list of PM domain specifiers that reference each power-domain used by the xHCI controller. This list must comprise of a specifier for the XUSBA and XUSBC power-domains. See ../power/power_domain.txt and @@ -78,6 +81,7 @@ Optional properties: - Tegra132: usb2-0, usb2-1, usb2-2, hsic-0, hsic-1, usb3-0, usb3-1 - Tegra210: usb2-0, usb2-1, usb2-2, usb2-3, hsic-0, usb3-0, usb3-1, usb3-2, usb3-3 + - Tegra186: usb2-0, usb2-1, usb2-2, hsic-0, usb3-0, usb3-1, usb3-2 Example: -------- diff --git a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt index d93b6a1504f2..b8acc2a994a8 100644 --- a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt +++ b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt @@ -6,6 +6,7 @@ Required properties: - "renesas,usbhs-r8a7743" for r8a7743 (RZ/G1M) compatible device - "renesas,usbhs-r8a7744" for r8a7744 (RZ/G1N) compatible device - "renesas,usbhs-r8a7745" for r8a7745 (RZ/G1E) compatible device + - "renesas,usbhs-r8a77470" for r8a77470 (RZ/G1C) compatible device - "renesas,usbhs-r8a774a1" for r8a774a1 (RZ/G2M) compatible device - "renesas,usbhs-r8a774c0" for r8a774c0 (RZ/G2E) compatible device - "renesas,usbhs-r8a7790" for r8a7790 (R-Car H2) compatible device diff --git a/Documentation/devicetree/bindings/usb/usb-ehci.txt b/Documentation/devicetree/bindings/usb/usb-ehci.txt deleted file mode 100644 index 406252d14c6b..000000000000 --- a/Documentation/devicetree/bindings/usb/usb-ehci.txt +++ /dev/null @@ -1,46 +0,0 @@ -USB EHCI controllers - -Required properties: - - compatible : should be "generic-ehci". - - reg : should contain at least address and length of the standard EHCI - register set for the device. Optional platform-dependent registers - (debug-port or other) can be also specified here, but only after - definition of standard EHCI registers. - - interrupts : one EHCI interrupt should be described here. - -Optional properties: - - big-endian-regs : boolean, set this for hcds with big-endian registers - - big-endian-desc : boolean, set this for hcds with big-endian descriptors - - big-endian : boolean, for hcds with big-endian-regs + big-endian-desc - - needs-reset-on-resume : boolean, set this to force EHCI reset after resume - - has-transaction-translator : boolean, set this if EHCI have a Transaction - Translator built into the root hub. - - clocks : a list of phandle + clock specifier pairs. In case of Renesas - R-Car Gen3 SoCs: - - if a host only channel: first clock should be host. - - if a USB DRD channel: first clock should be host and second one - should be peripheral. - - phys : see usb-hcd.txt in the current directory - - resets : phandle + reset specifier pair - -additionally the properties from usb-hcd.txt (in the current directory) are -supported. - -Example (Sequoia 440EPx): - ehci@e0000300 { - compatible = "ibm,usb-ehci-440epx", "usb-ehci"; - interrupt-parent = <&UIC0>; - interrupts = <1a 4>; - reg = <0 e0000300 90 0 e0000390 70>; - big-endian; - }; - -Example (Allwinner sun4i A10 SoC): - ehci0: usb@1c14000 { - compatible = "allwinner,sun4i-a10-ehci", "generic-ehci"; - reg = <0x01c14000 0x100>; - interrupts = <39>; - clocks = <&ahb_gates 1>; - phys = <&usbphy 1>; - phy-names = "usb"; - }; diff --git a/Documentation/devicetree/bindings/usb/usb-hcd.txt b/Documentation/devicetree/bindings/usb/usb-hcd.txt deleted file mode 100644 index 50529b838c9c..000000000000 --- a/Documentation/devicetree/bindings/usb/usb-hcd.txt +++ /dev/null @@ -1,9 +0,0 @@ -Generic USB HCD (Host Controller Device) Properties - -Optional properties: -- phys: a list of all USB PHYs on this HCD - -Example: - &usb1 { - phys = <&usb2_phy1>, <&usb3_phy1>; - }; diff --git a/Documentation/devicetree/bindings/usb/usb-hcd.yaml b/Documentation/devicetree/bindings/usb/usb-hcd.yaml new file mode 100644 index 000000000000..9c8c56d3a792 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/usb-hcd.yaml @@ -0,0 +1,25 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/usb-hcd.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Generic USB Host Controller Device Tree Bindings + +maintainers: + - Greg Kroah-Hartman <gregkh@linuxfoundation.org> + +properties: + $nodename: + pattern: "^usb(@.*)?" + + phys: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: + List of all the USB PHYs on this HCD + +examples: + - | + usb { + phys = <&usb2_phy1>, <&usb3_phy1>; + }; diff --git a/Documentation/devicetree/bindings/usb/usb-ohci.txt b/Documentation/devicetree/bindings/usb/usb-ohci.txt deleted file mode 100644 index aaaa5255c972..000000000000 --- a/Documentation/devicetree/bindings/usb/usb-ohci.txt +++ /dev/null @@ -1,35 +0,0 @@ -USB OHCI controllers - -Required properties: -- compatible : "generic-ohci" -- reg : ohci controller register range (address and length) -- interrupts : ohci controller interrupt - -Optional properties: -- big-endian-regs : boolean, set this for hcds with big-endian registers -- big-endian-desc : boolean, set this for hcds with big-endian descriptors -- big-endian : boolean, for hcds with big-endian-regs + big-endian-desc -- no-big-frame-no : boolean, set if frame_no lives in bits [15:0] of HCCA -- remote-wakeup-connected: remote wakeup is wired on the platform -- num-ports : u32, to override the detected port count -- clocks : a list of phandle + clock specifier pairs. In case of Renesas - R-Car Gen3 SoCs: - - if a host only channel: first clock should be host. - - if a USB DRD channel: first clock should be host and second one - should be peripheral. -- phys : see usb-hcd.txt in the current directory -- resets : a list of phandle + reset specifier pairs - -additionally the properties from usb-hcd.txt (in the current directory) are -supported. - -Example: - - ohci0: usb@1c14400 { - compatible = "allwinner,sun4i-a10-ohci", "generic-ohci"; - reg = <0x01c14400 0x100>; - interrupts = <64>; - clocks = <&usb_clk 6>, <&ahb_gates 2>; - phys = <&usbphy 1>; - phy-names = "usb"; - }; diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt b/Documentation/devicetree/bindings/usb/usb-xhci.txt index fea8b1545751..97400e8f8605 100644 --- a/Documentation/devicetree/bindings/usb/usb-xhci.txt +++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt @@ -10,6 +10,7 @@ Required properties: - "renesas,xhci-r8a7743" for r8a7743 SoC - "renesas,xhci-r8a7744" for r8a7744 SoC - "renesas,xhci-r8a774a1" for r8a774a1 SoC + - "renesas,xhci-r8a774c0" for r8a774c0 SoC - "renesas,xhci-r8a7790" for r8a7790 SoC - "renesas,xhci-r8a7791" for r8a7791 SoC - "renesas,xhci-r8a7793" for r8a7793 SoC diff --git a/Documentation/devicetree/bindings/usb/usb251xb.txt b/Documentation/devicetree/bindings/usb/usb251xb.txt index 17915f64b8ee..bc7945e9dbfe 100644 --- a/Documentation/devicetree/bindings/usb/usb251xb.txt +++ b/Documentation/devicetree/bindings/usb/usb251xb.txt @@ -64,8 +64,10 @@ Optional properties : - power-on-time-ms : Specifies the time it takes from the time the host initiates the power-on sequence to a port until the port has adequate power. The value is given in ms in a 0 - 510 range (default is 100ms). - - swap-dx-lanes : Specifies the ports which will swap the differential-pair - (D+/D-), default is not-swapped. + - swap-dx-lanes : Specifies the downstream ports which will swap the + differential-pair (D+/D-), default is not-swapped. + - swap-us-lanes : Selects the upstream port differential-pair (D+/D-) + swapping (boolean, default is not-swapped) Examples: usb2512b@2c { diff --git a/Documentation/media/index.rst b/Documentation/media/index.rst index 0a222fc1d7ca..0301c25ff887 100644 --- a/Documentation/media/index.rst +++ b/Documentation/media/index.rst @@ -18,7 +18,7 @@ Linux Media Subsystem Documentation v4l-drivers/index cec-drivers/index -.. only:: subproject +.. only:: html and subproject Indices ======= diff --git a/Documentation/media/kapi/mc-core.rst b/Documentation/media/kapi/mc-core.rst index f930725e0d6b..05bba0b61748 100644 --- a/Documentation/media/kapi/mc-core.rst +++ b/Documentation/media/kapi/mc-core.rst @@ -259,6 +259,45 @@ Subsystems should facilitate link validation by providing subsystem specific helper functions to provide easy access for commonly needed information, and in the end provide a way to use driver-specific callbacks. +Media Controller Device Allocator API +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +When the media device belongs to more than one driver, the shared media +device is allocated with the shared struct device as the key for look ups. + +The shared media device should stay in registered state until the last +driver unregisters it. In addition, the media device should be released when +all the references are released. Each driver gets a reference to the media +device during probe, when it allocates the media device. If media device is +already allocated, the allocate API bumps up the refcount and returns the +existing media device. The driver puts the reference back in its disconnect +routine when it calls :c:func:`media_device_delete()`. + +The media device is unregistered and cleaned up from the kref put handler to +ensure that the media device stays in registered state until the last driver +unregisters the media device. + +**Driver Usage** + +Drivers should use the appropriate media-core routines to manage the shared +media device life-time handling the two states: +1. allocate -> register -> delete +2. get reference to already registered device -> delete + +call :c:func:`media_device_delete()` routine to make sure the shared media +device delete is handled correctly. + +**driver probe:** +Call :c:func:`media_device_usb_allocate()` to allocate or get a reference +Call :c:func:`media_device_register()`, if media devnode isn't registered + +**driver disconnect:** +Call :c:func:`media_device_delete()` to free the media_device. Freeing is +handled by the kref put handler. + +API Definitions +^^^^^^^^^^^^^^^ + .. kernel-doc:: include/media/media-device.h .. kernel-doc:: include/media/media-devnode.h @@ -266,3 +305,5 @@ in the end provide a way to use driver-specific callbacks. .. kernel-doc:: include/media/media-entity.h .. kernel-doc:: include/media/media-request.h + +.. kernel-doc:: include/media/media-dev-allocator.h diff --git a/Documentation/media/lirc.h.rst.exceptions b/Documentation/media/lirc.h.rst.exceptions index 7a8b8ff4f076..ac768d769113 100644 --- a/Documentation/media/lirc.h.rst.exceptions +++ b/Documentation/media/lirc.h.rst.exceptions @@ -63,6 +63,7 @@ ignore symbol RC_PROTO_IMON ignore symbol RC_PROTO_RCMM12 ignore symbol RC_PROTO_RCMM24 ignore symbol RC_PROTO_RCMM32 +ignore symbol RC_PROTO_XBOX_DVD # Undocumented macros diff --git a/Documentation/media/uapi/mediactl/request-api.rst b/Documentation/media/uapi/mediactl/request-api.rst index 1ad631e549fe..a74c82d95609 100644 --- a/Documentation/media/uapi/mediactl/request-api.rst +++ b/Documentation/media/uapi/mediactl/request-api.rst @@ -93,7 +93,7 @@ A queued request cannot be modified anymore. .. caution:: For :ref:`memory-to-memory devices <mem2mem>` you can use requests only for output buffers, not for capture buffers. Attempting to add a capture buffer - to a request will result in an ``EACCES`` error. + to a request will result in an ``EBADR`` error. If the request contains configurations for multiple entities, individual drivers may synchronize so the requested pipeline's topology is applied before the diff --git a/Documentation/media/uapi/v4l/buffer.rst b/Documentation/media/uapi/v4l/buffer.rst index 81ffdcb89057..1cbd9cde57f3 100644 --- a/Documentation/media/uapi/v4l/buffer.rst +++ b/Documentation/media/uapi/v4l/buffer.rst @@ -165,7 +165,7 @@ of appropriately sized buffers for each use case). struct v4l2_buffer ================== -.. tabularcolumns:: |p{2.8cm}|p{2.5cm}|p{1.3cm}|p{10.5cm}| +.. tabularcolumns:: |p{2.8cm}|p{2.5cm}|p{1.6cm}|p{10.2cm}| .. cssclass:: longtable @@ -326,7 +326,7 @@ struct v4l2_buffer Applications should not set ``V4L2_BUF_FLAG_REQUEST_FD`` for any ioctls other than :ref:`VIDIOC_QBUF <VIDIOC_QBUF>`. - If the device does not support requests, then ``EACCES`` will be returned. + If the device does not support requests, then ``EBADR`` will be returned. If requests are supported but an invalid request file descriptor is given, then ``EINVAL`` will be returned. @@ -420,7 +420,7 @@ enum v4l2_buf_type .. cssclass:: longtable -.. tabularcolumns:: |p{7.2cm}|p{0.6cm}|p{9.7cm}| +.. tabularcolumns:: |p{7.8cm}|p{0.6cm}|p{9.1cm}| .. flat-table:: :header-rows: 0 @@ -482,7 +482,11 @@ enum v4l2_buf_type Buffer Flags ============ -.. tabularcolumns:: |p{7.0cm}|p{2.2cm}|p{8.3cm}| +.. raw:: latex + + \small + +.. tabularcolumns:: |p{7.0cm}|p{2.1cm}|p{8.4cm}| .. cssclass:: longtable @@ -681,6 +685,9 @@ Buffer Flags exposure of the frame has begun. This is only valid for the ``V4L2_BUF_TYPE_VIDEO_CAPTURE`` buffer type. +.. raw:: latex + + \normalsize .. c:type:: v4l2_memory @@ -688,7 +695,7 @@ Buffer Flags enum v4l2_memory ================ -.. tabularcolumns:: |p{6.6cm}|p{2.2cm}|p{8.7cm}| +.. tabularcolumns:: |p{5.0cm}|p{0.8cm}|p{11.7cm}| .. flat-table:: :header-rows: 0 @@ -724,7 +731,7 @@ The :c:type:`v4l2_buffer_timecode` structure is designed to hold a struct v4l2_timecode -------------------- -.. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}| +.. tabularcolumns:: |p{1.4cm}|p{2.8cm}|p{12.3cm}| .. flat-table:: :header-rows: 0 @@ -761,7 +768,7 @@ struct v4l2_timecode Timecode Types -------------- -.. tabularcolumns:: |p{6.6cm}|p{2.2cm}|p{8.7cm}| +.. tabularcolumns:: |p{5.6cm}|p{0.8cm}|p{11.1cm}| .. flat-table:: :header-rows: 0 diff --git a/Documentation/media/uapi/v4l/colorspaces-defs.rst b/Documentation/media/uapi/v4l/colorspaces-defs.rst index c4e8fc620379..e122bbe3d799 100644 --- a/Documentation/media/uapi/v4l/colorspaces-defs.rst +++ b/Documentation/media/uapi/v4l/colorspaces-defs.rst @@ -39,7 +39,7 @@ whole range, 0-255, dividing the angular value by 1.41. The enum colorspaces except for BT.2020 which uses limited range R'G'B' quantization. -.. tabularcolumns:: |p{6.0cm}|p{11.5cm}| +.. tabularcolumns:: |p{6.7cm}|p{10.8cm}| .. c:type:: v4l2_colorspace @@ -112,7 +112,7 @@ whole range, 0-255, dividing the angular value by 1.41. The enum .. c:type:: v4l2_ycbcr_encoding -.. tabularcolumns:: |p{6.5cm}|p{11.0cm}| +.. tabularcolumns:: |p{7.2cm}|p{10.3cm}| .. flat-table:: V4L2 Y'CbCr Encodings :header-rows: 1 diff --git a/Documentation/media/uapi/v4l/colorspaces.rst b/Documentation/media/uapi/v4l/colorspaces.rst index c5a560f0c13d..4f6c82fa057f 100644 --- a/Documentation/media/uapi/v4l/colorspaces.rst +++ b/Documentation/media/uapi/v4l/colorspaces.rst @@ -56,9 +56,9 @@ The Y value in the CIE XYZ colorspace corresponds to luminance. Often the CIE XYZ colorspace is transformed to the normalized CIE xyY colorspace: -x = X / (X + Y + Z) + x = X / (X + Y + Z) -y = Y / (X + Y + Z) + y = Y / (X + Y + Z) The x and y values are the chromaticity coordinates and can be used to define a color without the luminance component Y. It is very confusing diff --git a/Documentation/media/uapi/v4l/dev-raw-vbi.rst b/Documentation/media/uapi/v4l/dev-raw-vbi.rst index d6a707f0b24f..e06b03ca2ab2 100644 --- a/Documentation/media/uapi/v4l/dev-raw-vbi.rst +++ b/Documentation/media/uapi/v4l/dev-raw-vbi.rst @@ -106,7 +106,7 @@ VBI devices must implement both the :ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>` and and always returns default parameters as :ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>` does. :ref:`VIDIOC_TRY_FMT <VIDIOC_G_FMT>` is optional. -.. tabularcolumns:: |p{2.4cm}|p{4.4cm}|p{10.7cm}| +.. tabularcolumns:: |p{1.6cm}|p{4.2cm}|p{11.7cm}| .. c:type:: v4l2_vbi_format @@ -190,7 +190,7 @@ and always returns default parameters as :ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>` does applications must set it to zero. -.. tabularcolumns:: |p{4.0cm}|p{1.5cm}|p{12.0cm}| +.. tabularcolumns:: |p{4.4cm}|p{1.5cm}|p{11.6cm}| .. _vbifmt-flags: diff --git a/Documentation/media/uapi/v4l/dev-rds.rst b/Documentation/media/uapi/v4l/dev-rds.rst index 624d6f95b842..64a724ef58f5 100644 --- a/Documentation/media/uapi/v4l/dev-rds.rst +++ b/Documentation/media/uapi/v4l/dev-rds.rst @@ -146,7 +146,7 @@ RDS datastructures .. _v4l2-rds-block-codes: -.. tabularcolumns:: |p{5.6cm}|p{2.0cm}|p{1.5cm}|p{7.0cm}| +.. tabularcolumns:: |p{6.4cm}|p{2.0cm}|p{1.2cm}|p{7.9cm}| .. flat-table:: Block defines :header-rows: 0 diff --git a/Documentation/media/uapi/v4l/dev-sliced-vbi.rst b/Documentation/media/uapi/v4l/dev-sliced-vbi.rst index 0aa6cb8a272b..e86346f66017 100644 --- a/Documentation/media/uapi/v4l/dev-sliced-vbi.rst +++ b/Documentation/media/uapi/v4l/dev-sliced-vbi.rst @@ -118,7 +118,7 @@ struct v4l2_sliced_vbi_format \scriptsize \setlength{\tabcolsep}{2pt} -.. tabularcolumns:: |p{.75cm}|p{3.3cm}|p{3.4cm}|p{3.4cm}|p{3.4cm}| +.. tabularcolumns:: |p{.85cm}|p{3.3cm}|p{4.4cm}|p{4.4cm}|p{4.4cm}| .. cssclass:: longtable @@ -223,7 +223,7 @@ Sliced VBI services .. raw:: latex - \footnotesize + \scriptsize .. tabularcolumns:: |p{4.1cm}|p{1.1cm}|p{2.4cm}|p{2.0cm}|p{7.3cm}| @@ -541,7 +541,7 @@ Magic Constants for struct v4l2_mpeg_vbi_fmt_ivtv magic field structs v4l2_mpeg_vbi_itv0 and v4l2_mpeg_vbi_ITV0 ------------------------------------------------- -.. tabularcolumns:: |p{4.9cm}|p{2.4cm}|p{10.2cm}| +.. tabularcolumns:: |p{5.2cm}|p{2.4cm}|p{9.9cm}| .. flat-table:: :header-rows: 0 @@ -561,12 +561,12 @@ structs v4l2_mpeg_vbi_itv0 and v4l2_mpeg_vbi_ITV0 :: - linemask[0] b0: line 6 first field - linemask[0] b17: line 23 first field - linemask[0] b18: line 6 second field - linemask[0] b31: line 19 second field - linemask[1] b0: line 20 second field - linemask[1] b3: line 23 second field + linemask[0] b0: line 6 first field + linemask[0] b17: line 23 first field + linemask[0] b18: line 6 second field + linemask[0] b31: line 19 second field + linemask[1] b0: line 20 second field + linemask[1] b3: line 23 second field linemask[1] b4-b31: unused and set to 0 * - struct :c:type:`v4l2_mpeg_vbi_itv0_line` @@ -590,7 +590,7 @@ structs v4l2_mpeg_vbi_itv0 and v4l2_mpeg_vbi_ITV0 struct v4l2_mpeg_vbi_ITV0 ------------------------- -.. tabularcolumns:: |p{4.9cm}|p{4.4cm}|p{8.2cm}| +.. tabularcolumns:: |p{5.2cm}|p{2.4cm}|p{9.9cm}| .. flat-table:: :header-rows: 0 @@ -635,7 +635,7 @@ struct v4l2_mpeg_vbi_itv0_line Line Identifiers for struct v4l2_mpeg_vbi_itv0_line id field ------------------------------------------------------------ -.. tabularcolumns:: |p{6.6cm}|p{2.2cm}|p{8.7cm}| +.. tabularcolumns:: |p{7.0cm}|p{1.8cm}|p{8.7cm}| .. flat-table:: :header-rows: 1 diff --git a/Documentation/media/uapi/v4l/dev-subdev.rst b/Documentation/media/uapi/v4l/dev-subdev.rst index 2c2768c7343b..029bb2d9928a 100644 --- a/Documentation/media/uapi/v4l/dev-subdev.rst +++ b/Documentation/media/uapi/v4l/dev-subdev.rst @@ -211,7 +211,7 @@ list entity names and pad numbers). .. raw:: latex - \tiny + \scriptsize .. tabularcolumns:: |p{2.0cm}|p{2.3cm}|p{2.3cm}|p{2.3cm}|p{2.3cm}|p{2.3cm}|p{2.3cm}| @@ -223,40 +223,80 @@ list entity names and pad numbers). :widths: 5 5 5 5 5 5 5 * - - - Sensor/0 format - - Frontend/0 format - - Frontend/1 format - - Scaler/0 format - - Scaler/0 compose selection rectangle - - Scaler/1 format + - Sensor/0 + + format + - Frontend/0 + + format + - Frontend/1 + + format + - Scaler/0 + + format + - Scaler/0 + + compose selection rectangle + - Scaler/1 + + format * - Initial state - - 2048x1536/SGRBG8_1X8 + - 2048x1536 + + SGRBG8_1X8 - (default) - (default) - (default) - (default) - (default) * - Configure frontend sink format - - 2048x1536/SGRBG8_1X8 - - *2048x1536/SGRBG8_1X8* - - *2046x1534/SGRBG8_1X8* + - 2048x1536 + + SGRBG8_1X8 + - *2048x1536* + + *SGRBG8_1X8* + - *2046x1534* + + *SGRBG8_1X8* - (default) - (default) - (default) * - Configure scaler sink format - - 2048x1536/SGRBG8_1X8 - - 2048x1536/SGRBG8_1X8 - - 2046x1534/SGRBG8_1X8 - - *2046x1534/SGRBG8_1X8* + - 2048x1536 + + SGRBG8_1X8 + - 2048x1536 + + SGRBG8_1X8 + - 2046x1534 + + SGRBG8_1X8 + - *2046x1534* + + *SGRBG8_1X8* - *0,0/2046x1534* - - *2046x1534/SGRBG8_1X8* + - *2046x1534* + + *SGRBG8_1X8* * - Configure scaler sink compose selection - - 2048x1536/SGRBG8_1X8 - - 2048x1536/SGRBG8_1X8 - - 2046x1534/SGRBG8_1X8 - - 2046x1534/SGRBG8_1X8 + - 2048x1536 + + SGRBG8_1X8 + - 2048x1536 + + SGRBG8_1X8 + - 2046x1534 + + SGRBG8_1X8 + - 2046x1534 + + SGRBG8_1X8 - *0,0/1280x960* - - *1280x960/SGRBG8_1X8* + - *1280x960* + + *SGRBG8_1X8* .. raw:: latex diff --git a/Documentation/media/uapi/v4l/ext-ctrls-camera.rst b/Documentation/media/uapi/v4l/ext-ctrls-camera.rst index d3a553cd86c9..51c1d5c9eb00 100644 --- a/Documentation/media/uapi/v4l/ext-ctrls-camera.rst +++ b/Documentation/media/uapi/v4l/ext-ctrls-camera.rst @@ -88,7 +88,7 @@ enum v4l2_exposure_metering - Determines how the camera measures the amount of light available for the frame exposure. Possible values are: -.. tabularcolumns:: |p{8.5cm}|p{9.0cm}| +.. tabularcolumns:: |p{8.7cm}|p{8.8cm}| .. flat-table:: :header-rows: 0 @@ -180,7 +180,7 @@ enum v4l2_exposure_metering - control may stop updates of the ``V4L2_CID_AUTO_FOCUS_STATUS`` control value. -.. tabularcolumns:: |p{6.5cm}|p{11.0cm}| +.. tabularcolumns:: |p{6.7cm}|p{10.8cm}| .. flat-table:: :header-rows: 0 @@ -206,7 +206,7 @@ enum v4l2_exposure_metering - enum v4l2_auto_focus_range - Determines auto focus distance range for which lens may be adjusted. -.. tabularcolumns:: |p{6.5cm}|p{11.0cm}| +.. tabularcolumns:: |p{6.8cm}|p{10.7cm}| .. flat-table:: :header-rows: 0 @@ -281,7 +281,7 @@ enum v4l2_auto_n_preset_white_balance - representation. The following white balance presets are listed in order of increasing color temperature. -.. tabularcolumns:: |p{7.0 cm}|p{10.5cm}| +.. tabularcolumns:: |p{7.2 cm}|p{10.3cm}| .. flat-table:: :header-rows: 0 @@ -387,7 +387,11 @@ enum v4l2_scene_mode - to ``V4L2_SCENE_MODE_NONE`` to make sure the other possibly related controls are accessible. The following scene programs are defined: -.. tabularcolumns:: |p{6.0cm}|p{11.5cm}| +.. raw:: latex + + \small + +.. tabularcolumns:: |p{5.9cm}|p{11.5cm}| .. flat-table:: :header-rows: 0 @@ -459,6 +463,9 @@ enum v4l2_scene_mode - may be switched to close-up mode and this setting may also involve some lens-distortion correction. +.. raw:: latex + + \normalsize ``V4L2_CID_3A_LOCK (bitmask)`` diff --git a/Documentation/media/uapi/v4l/ext-ctrls-codec.rst b/Documentation/media/uapi/v4l/ext-ctrls-codec.rst index c97fb7923be5..4a8446203085 100644 --- a/Documentation/media/uapi/v4l/ext-ctrls-codec.rst +++ b/Documentation/media/uapi/v4l/ext-ctrls-codec.rst @@ -105,7 +105,7 @@ enum v4l2_mpeg_stream_vbi_fmt - -.. tabularcolumns:: |p{6 cm}|p{11.5cm}| +.. tabularcolumns:: |p{6.6 cm}|p{10.9cm}| .. flat-table:: :header-rows: 0 @@ -477,7 +477,7 @@ enum v4l2_mpeg_audio_dec_playback - -.. tabularcolumns:: |p{9.0cm}|p{8.5cm}| +.. tabularcolumns:: |p{9.8cm}|p{7.7cm}| .. flat-table:: :header-rows: 0 @@ -888,7 +888,7 @@ enum v4l2_mpeg_video_multi_slice_mode - -.. tabularcolumns:: |p{8.7cm}|p{8.8cm}| +.. tabularcolumns:: |p{9.6cm}|p{7.9cm}| .. flat-table:: :header-rows: 0 @@ -923,9 +923,11 @@ enum v4l2_mpeg_video_multi_slice_mode - enum v4l2_mpeg_video_h264_loop_filter_mode - Loop filter mode for H264 encoder. Possible values are: +.. raw:: latex + \small -.. tabularcolumns:: |p{14.0cm}|p{3.5cm}| +.. tabularcolumns:: |p{13.6cm}|p{3.9cm}| .. flat-table:: :header-rows: 0 @@ -938,6 +940,9 @@ enum v4l2_mpeg_video_h264_loop_filter_mode - * - ``V4L2_MPEG_VIDEO_H264_LOOP_FILTER_MODE_DISABLED_AT_SLICE_BOUNDARY`` - Loop filter is disabled at the slice boundary. +.. raw:: latex + + \normalsize ``V4L2_CID_MPEG_VIDEO_H264_LOOP_FILTER_ALPHA (integer)`` @@ -964,6 +969,8 @@ enum v4l2_mpeg_video_h264_entropy_mode - encoder. Possible values are: +.. tabularcolumns:: |p{9.0cm}|p{8.5cm}| + .. flat-table:: :header-rows: 0 @@ -1048,6 +1055,30 @@ enum v4l2_mpeg_video_h264_entropy_mode - Quantization parameter for an B frame for H264. Valid range: from 0 to 51. +``V4L2_CID_MPEG_VIDEO_H264_I_FRAME_MIN_QP (integer)`` + Minimum quantization parameter for the H264 I frame to limit I frame + quality to a range. Valid range: from 0 to 51. If + V4L2_CID_MPEG_VIDEO_H264_MIN_QP is also set, the quantization parameter + should be chosen to meet both requirements. + +``V4L2_CID_MPEG_VIDEO_H264_I_FRAME_MAX_QP (integer)`` + Maximum quantization parameter for the H264 I frame to limit I frame + quality to a range. Valid range: from 0 to 51. If + V4L2_CID_MPEG_VIDEO_H264_MAX_QP is also set, the quantization parameter + should be chosen to meet both requirements. + +``V4L2_CID_MPEG_VIDEO_H264_P_FRAME_MIN_QP (integer)`` + Minimum quantization parameter for the H264 P frame to limit P frame + quality to a range. Valid range: from 0 to 51. If + V4L2_CID_MPEG_VIDEO_H264_MIN_QP is also set, the quantization parameter + should be chosen to meet both requirements. + +``V4L2_CID_MPEG_VIDEO_H264_P_FRAME_MAX_QP (integer)`` + Maximum quantization parameter for the H264 P frame to limit P frame + quality to a range. Valid range: from 0 to 51. If + V4L2_CID_MPEG_VIDEO_H264_MAX_QP is also set, the quantization parameter + should be chosen to meet both requirements. + ``V4L2_CID_MPEG_VIDEO_MPEG4_I_FRAME_QP (integer)`` Quantization parameter for an I frame for MPEG4. Valid range: from 1 to 31. @@ -1129,7 +1160,9 @@ enum v4l2_mpeg_video_header_mode - it returned together with the first frame. Applicable to encoders. Possible values are: +.. raw:: latex + \small .. tabularcolumns:: |p{10.3cm}|p{7.2cm}| @@ -1143,6 +1176,9 @@ enum v4l2_mpeg_video_header_mode - - The stream header is returned together with the first encoded frame. +.. raw:: latex + + \normalsize ``V4L2_CID_MPEG_VIDEO_REPEAT_SEQ_HEADER (boolean)`` @@ -1181,6 +1217,10 @@ enum v4l2_mpeg_video_h264_sei_fp_arrangement_type - Frame packing arrangement type for H264 SEI. Applicable to the H264 encoder. Possible values are: +.. raw:: latex + + \small + .. tabularcolumns:: |p{12cm}|p{5.5cm}| .. flat-table:: @@ -1200,6 +1240,10 @@ enum v4l2_mpeg_video_h264_sei_fp_arrangement_type - * - ``V4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_TEMPORAL`` - One view per frame. +.. raw:: latex + + \normalsize + ``V4L2_CID_MPEG_VIDEO_H264_FMO (boolean)`` @@ -1217,6 +1261,10 @@ enum v4l2_mpeg_video_h264_fmo_map_type - patterns of macroblocks. Applicable to the H264 encoder. Possible values are: +.. raw:: latex + + \small + .. tabularcolumns:: |p{12.5cm}|p{5.0cm}| .. flat-table:: @@ -1240,6 +1288,10 @@ enum v4l2_mpeg_video_h264_fmo_map_type - * - ``V4L2_MPEG_VIDEO_H264_FMO_MAP_TYPE_EXPLICIT`` - User defined map type. +.. raw:: latex + + \normalsize + ``V4L2_CID_MPEG_VIDEO_H264_FMO_SLICE_GROUP (integer)`` @@ -1361,6 +1413,8 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type - .. cssclass:: longtable +.. tabularcolumns:: |p{5.8cm}|p{4.8cm}|p{6.6cm}| + .. flat-table:: struct v4l2_ctrl_mpeg2_slice_params :header-rows: 0 :stub-columns: 0 @@ -1402,6 +1456,8 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type - .. cssclass:: longtable +.. tabularcolumns:: |p{1.5cm}|p{6.3cm}|p{9.4cm}| + .. flat-table:: struct v4l2_mpeg2_sequence :header-rows: 0 :stub-columns: 0 @@ -1433,6 +1489,8 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type - .. cssclass:: longtable +.. tabularcolumns:: |p{1.5cm}|p{6.3cm}|p{9.4cm}| + .. flat-table:: struct v4l2_mpeg2_picture :header-rows: 0 :stub-columns: 0 @@ -1492,6 +1550,12 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type - .. cssclass:: longtable +.. tabularcolumns:: |p{1.2cm}|p{8.0cm}|p{7.4cm}| + +.. raw:: latex + + \small + .. flat-table:: struct v4l2_ctrl_mpeg2_quantization :header-rows: 0 :stub-columns: 0 @@ -1537,6 +1601,19 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type - non-intra-coded frames, in zigzag scanning order. Only relevant for non-4:2:0 YUV formats. +``V4L2_CID_FWHT_I_FRAME_QP (integer)`` + Quantization parameter for an I frame for FWHT. Valid range: from 1 + to 31. + +``V4L2_CID_FWHT_P_FRAME_QP (integer)`` + Quantization parameter for a P frame for FWHT. Valid range: from 1 + to 31. + +.. raw:: latex + + \normalsize + + MFC 5.1 MPEG Controls ===================== @@ -1644,7 +1721,11 @@ enum v4l2_mpeg_mfc51_video_frame_skip_mode - are: -.. tabularcolumns:: |p{9.0cm}|p{8.5cm}| +.. tabularcolumns:: |p{9.2cm}|p{8.3cm}| + +.. raw:: latex + + \small .. flat-table:: :header-rows: 0 @@ -1659,7 +1740,9 @@ enum v4l2_mpeg_mfc51_video_frame_skip_mode - - Frame skip mode enabled and buffer limit is set by the VBV (MPEG1/2/4) or CPB (H264) buffer size control. +.. raw:: latex + \normalsize ``V4L2_CID_MPEG_MFC51_VIDEO_RC_FIXED_TARGET_BIT (integer)`` Enable rate-control with fixed target bit. If this setting is @@ -1682,7 +1765,7 @@ enum v4l2_mpeg_mfc51_video_force_frame_type - Force a frame type for the next queued buffer. Applicable to encoders. Possible values are: - +.. tabularcolumns:: |p{9.5cm}|p{8.0cm}| .. flat-table:: :header-rows: 0 @@ -1696,6 +1779,125 @@ enum v4l2_mpeg_mfc51_video_force_frame_type - - Force a non-coded frame. +.. _v4l2-mpeg-fwht: + +``V4L2_CID_MPEG_VIDEO_FWHT_PARAMS (struct)`` + Specifies the fwht parameters (as extracted from the bitstream) for the + associated FWHT data. This includes the necessary parameters for + configuring a stateless hardware decoding pipeline for FWHT. + + .. note:: + + This compound control is not yet part of the public kernel API and + it is expected to change. + +.. c:type:: v4l2_ctrl_fwht_params + +.. cssclass:: longtable + +.. tabularcolumns:: |p{1.4cm}|p{4.3cm}|p{11.8cm}| + +.. flat-table:: struct v4l2_ctrl_fwht_params + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - __u64 + - ``backward_ref_ts`` + - Timestamp of the V4L2 capture buffer to use as backward reference, used + with P-coded frames. The timestamp refers to the + ``timestamp`` field in struct :c:type:`v4l2_buffer`. Use the + :c:func:`v4l2_timeval_to_ns()` function to convert the struct + :c:type:`timeval` in struct :c:type:`v4l2_buffer` to a __u64. + * - __u32 + - ``version`` + - The version of the codec + * - __u32 + - ``width`` + - The width of the frame + * - __u32 + - ``height`` + - The height of the frame + * - __u32 + - ``flags`` + - The flags of the frame, see :ref:`fwht-flags`. + * - __u32 + - ``colorspace`` + - The colorspace of the frame, from enum :c:type:`v4l2_colorspace`. + * - __u32 + - ``xfer_func`` + - The transfer function, from enum :c:type:`v4l2_xfer_func`. + * - __u32 + - ``ycbcr_enc`` + - The Y'CbCr encoding, from enum :c:type:`v4l2_ycbcr_encoding`. + * - __u32 + - ``quantization`` + - The quantization range, from enum :c:type:`v4l2_quantization`. + + + +.. _fwht-flags: + +FWHT Flags +============ + +.. cssclass:: longtable + +.. tabularcolumns:: |p{6.8cm}|p{2.4cm}|p{8.3cm}| + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + :widths: 3 1 4 + + * - ``FWHT_FL_IS_INTERLACED`` + - 0x00000001 + - Set if this is an interlaced format + * - ``FWHT_FL_IS_BOTTOM_FIRST`` + - 0x00000002 + - Set if this is a bottom-first (NTSC) interlaced format + * - ``FWHT_FL_IS_ALTERNATE`` + - 0x00000004 + - Set if each 'frame' contains just one field + * - ``FWHT_FL_IS_BOTTOM_FIELD`` + - 0x00000008 + - If FWHT_FL_IS_ALTERNATE was set, then this is set if this 'frame' is the + bottom field, else it is the top field. + * - ``FWHT_FL_LUMA_IS_UNCOMPRESSED`` + - 0x00000010 + - Set if the luma plane is uncompressed + * - ``FWHT_FL_CB_IS_UNCOMPRESSED`` + - 0x00000020 + - Set if the cb plane is uncompressed + * - ``FWHT_FL_CR_IS_UNCOMPRESSED`` + - 0x00000040 + - Set if the cr plane is uncompressed + * - ``FWHT_FL_CHROMA_FULL_HEIGHT`` + - 0x00000080 + - Set if the chroma plane has the same height as the luma plane, + else the chroma plane is half the height of the luma plane + * - ``FWHT_FL_CHROMA_FULL_WIDTH`` + - 0x00000100 + - Set if the chroma plane has the same width as the luma plane, + else the chroma plane is half the width of the luma plane + * - ``FWHT_FL_ALPHA_IS_UNCOMPRESSED`` + - 0x00000200 + - Set if the alpha plane is uncompressed + * - ``FWHT_FL_I_FRAME`` + - 0x00000400 + - Set if this is an I-frame + * - ``FWHT_FL_COMPONENTS_NUM_MSK`` + - 0x00070000 + - A 4-values flag - the number of components - 1 + * - ``FWHT_FL_PIXENC_YUV`` + - 0x00080000 + - Set if the pixel encoding is YUV + * - ``FWHT_FL_PIXENC_RGB`` + - 0x00100000 + - Set if the pixel encoding is RGB + * - ``FWHT_FL_PIXENC_HSV`` + - 0x00180000 + - Set if the pixel encoding is HSV CX2341x MPEG Controls @@ -1745,9 +1947,11 @@ enum v4l2_mpeg_cx2341x_video_luma_spatial_filter_type - Select the algorithm to use for the Luma Spatial Filter (default ``1D_HOR``). Possible values: +.. tabularcolumns:: |p{14.5cm}|p{3.0cm}| +.. raw:: latex -.. tabularcolumns:: |p{14.5cm}|p{3.0cm}| + \small .. flat-table:: :header-rows: 0 @@ -1764,6 +1968,10 @@ enum v4l2_mpeg_cx2341x_video_luma_spatial_filter_type - * - ``V4L2_MPEG_CX2341X_VIDEO_LUMA_SPATIAL_FILTER_TYPE_2D_SYM_NON_SEPARABLE`` - Two-dimensional symmetrical non-separable +.. raw:: latex + + \normalsize + .. _chroma-spatial-filter-type: @@ -1776,6 +1984,7 @@ enum v4l2_mpeg_cx2341x_video_chroma_spatial_filter_type - ``1D_HOR``). Possible values are: +.. tabularcolumns:: |p{14.0cm}|p{3.5cm}| .. flat-table:: :header-rows: 0 @@ -1918,6 +2127,10 @@ enum v4l2_vp8_num_ref_frames - .. tabularcolumns:: |p{7.9cm}|p{9.6cm}| +.. raw:: latex + + \small + .. flat-table:: :header-rows: 0 :stub-columns: 0 @@ -1932,6 +2145,10 @@ enum v4l2_vp8_num_ref_frames - - The last encoded frame, the golden frame and the altref frame will be searched. +.. raw:: latex + + \normalsize + ``V4L2_CID_MPEG_VIDEO_VPX_FILTER_LEVEL (integer)`` @@ -1961,7 +2178,7 @@ enum v4l2_vp8_golden_frame_sel - .. raw:: latex - \footnotesize + \scriptsize .. tabularcolumns:: |p{9.0cm}|p{8.0cm}| @@ -2283,7 +2500,7 @@ enum v4l2_mpeg_video_hevc_loop_filter_mode - \footnotesize -.. tabularcolumns:: |p{10.7cm}|p{6.3cm}| +.. tabularcolumns:: |p{12.1cm}|p{5.4cm}| .. flat-table:: :header-rows: 0 diff --git a/Documentation/media/uapi/v4l/ext-ctrls-detect.rst b/Documentation/media/uapi/v4l/ext-ctrls-detect.rst index 8a45ce642829..80981d0cff42 100644 --- a/Documentation/media/uapi/v4l/ext-ctrls-detect.rst +++ b/Documentation/media/uapi/v4l/ext-ctrls-detect.rst @@ -30,7 +30,7 @@ Detect Control IDs ``V4L2_CID_DETECT_MD_MODE (menu)`` Sets the motion detection mode. -.. tabularcolumns:: |p{7.5cm}|p{10.0cm}| +.. tabularcolumns:: |p{7.7cm}|p{9.8cm}| .. flat-table:: :header-rows: 0 diff --git a/Documentation/media/uapi/v4l/ext-ctrls-dv.rst b/Documentation/media/uapi/v4l/ext-ctrls-dv.rst index 57edf211875c..5c70ac98f710 100644 --- a/Documentation/media/uapi/v4l/ext-ctrls-dv.rst +++ b/Documentation/media/uapi/v4l/ext-ctrls-dv.rst @@ -106,7 +106,7 @@ enum v4l2_dv_it_content_type - or an analog source. The enum v4l2_dv_it_content_type defines the possible content types: -.. tabularcolumns:: |p{7.0cm}|p{10.5cm}| +.. tabularcolumns:: |p{7.3cm}|p{10.4cm}| .. flat-table:: :header-rows: 0 diff --git a/Documentation/media/uapi/v4l/ext-ctrls-flash.rst b/Documentation/media/uapi/v4l/ext-ctrls-flash.rst index 5f30791c35b5..eff056b17167 100644 --- a/Documentation/media/uapi/v4l/ext-ctrls-flash.rst +++ b/Documentation/media/uapi/v4l/ext-ctrls-flash.rst @@ -87,7 +87,7 @@ Flash Control IDs ``V4L2_CID_FLASH_STROBE_SOURCE (menu)`` Defines the source of the flash LED strobe. -.. tabularcolumns:: |p{7.0cm}|p{10.5cm}| +.. tabularcolumns:: |p{7.5cm}|p{10.0cm}| .. flat-table:: :header-rows: 0 @@ -146,7 +146,7 @@ Flash Control IDs an effect is chip dependent. Reading the faults resets the control and returns the chip to a usable state if possible. -.. tabularcolumns:: |p{8.0cm}|p{9.5cm}| +.. tabularcolumns:: |p{8.4cm}|p{9.1cm}| .. flat-table:: :header-rows: 0 diff --git a/Documentation/media/uapi/v4l/ext-ctrls-jpeg.rst b/Documentation/media/uapi/v4l/ext-ctrls-jpeg.rst index cf9cd8a9f9b4..60ce3f949319 100644 --- a/Documentation/media/uapi/v4l/ext-ctrls-jpeg.rst +++ b/Documentation/media/uapi/v4l/ext-ctrls-jpeg.rst @@ -37,7 +37,7 @@ JPEG Control IDs how Cb and Cr components are downsampled after converting an input image from RGB to Y'CbCr color space. -.. tabularcolumns:: |p{7.0cm}|p{10.5cm}| +.. tabularcolumns:: |p{7.5cm}|p{10.0cm}| .. flat-table:: :header-rows: 0 diff --git a/Documentation/media/uapi/v4l/field-order.rst b/Documentation/media/uapi/v4l/field-order.rst index 8415268d439c..3fb473e3b8e2 100644 --- a/Documentation/media/uapi/v4l/field-order.rst +++ b/Documentation/media/uapi/v4l/field-order.rst @@ -64,7 +64,9 @@ enum v4l2_field .. c:type:: v4l2_field -.. tabularcolumns:: |p{6.6cm}|p{2.2cm}|p{8.7cm}| +.. tabularcolumns:: |p{5.8cm}|p{0.6cm}|p{11.1cm}| + +.. cssclass:: longtable .. flat-table:: :header-rows: 0 diff --git a/Documentation/media/uapi/v4l/pixfmt-compressed.rst b/Documentation/media/uapi/v4l/pixfmt-compressed.rst index 2675bef3eefe..6c961cfb74da 100644 --- a/Documentation/media/uapi/v4l/pixfmt-compressed.rst +++ b/Documentation/media/uapi/v4l/pixfmt-compressed.rst @@ -125,3 +125,9 @@ Compressed Formats - Video elementary stream using a codec based on the Fast Walsh Hadamard Transform. This codec is implemented by the vicodec ('Virtual Codec') driver. See the codec-fwht.h header for more details. + * .. _V4L2-PIX-FMT-FWHT-STATELESS: + + - ``V4L2_PIX_FMT_FWHT_STATELESS`` + - 'SFWH' + - Same format as V4L2_PIX_FMT_FWHT but requires stateless codec implementation. + See the :ref:`associated Codec Control IDs <v4l2-mpeg-fwht>`. diff --git a/Documentation/media/uapi/v4l/pixfmt-meta-d4xx.rst b/Documentation/media/uapi/v4l/pixfmt-meta-d4xx.rst index 862e1f327150..87e8fd7d5d02 100644 --- a/Documentation/media/uapi/v4l/pixfmt-meta-d4xx.rst +++ b/Documentation/media/uapi/v4l/pixfmt-meta-d4xx.rst @@ -36,13 +36,16 @@ per frame, therefore their headers cannot be larger than 255 bytes. Below are proprietary Microsoft style metadata types, used by D4xx cameras, where all fields are in little endian order: +.. tabularcolumns:: |p{5.0cm}|p{12.5cm}| + + .. flat-table:: D4xx metadata - :widths: 1 4 + :widths: 1 2 :header-rows: 1 :stub-columns: 0 - * - Field - - Description + * - **Field** + - **Description** * - :cspan:`1` *Depth Control* * - __u32 ID - 0x80000000 diff --git a/Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgt.rst b/Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgt.rst index 2ebccdcca95d..d1a341af9c48 100644 --- a/Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgt.rst +++ b/Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgt.rst @@ -41,6 +41,10 @@ The Hue position **m** (0 - 5) of the bucket in the matrix depends on how the HGT Hue areas are configured. There are 6 user configurable Hue Areas which can be configured to cover overlapping Hue values: +.. raw:: latex + + \small + :: Area 0 Area 1 Area 2 Area 3 Area 4 Area 5 @@ -53,6 +57,11 @@ Areas which can be configured to cover overlapping Hue values: 5U 0L 0U 1L 1U 2L 2U 3L 3U 4L 4U 5L 5U 0L <0..............................Hue Value............................255> + +.. raw:: latex + + \normalsize + When two consecutive areas don't overlap (n+1L is equal to nU) the boundary value is considered as part of the lower area. diff --git a/Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst b/Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst index 38b1895a509f..dfc4a8367b3d 100644 --- a/Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst +++ b/Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst @@ -31,7 +31,7 @@ The values are packed in 24 or 32 bit formats. \tiny \setlength{\tabcolsep}{2pt} -.. tabularcolumns:: |p{2.0cm}|p{0.54cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}| +.. tabularcolumns:: |p{2.6cm}|p{0.8cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}| .. _packed-hsv-formats: diff --git a/Documentation/media/uapi/v4l/pixfmt-packed-rgb.rst b/Documentation/media/uapi/v4l/pixfmt-packed-rgb.rst index 6b3781c04dd5..738bb14c0ee2 100644 --- a/Documentation/media/uapi/v4l/pixfmt-packed-rgb.rst +++ b/Documentation/media/uapi/v4l/pixfmt-packed-rgb.rst @@ -27,7 +27,7 @@ next to each other in memory. \tiny \setlength{\tabcolsep}{2pt} -.. tabularcolumns:: |p{2.3cm}|p{1.6cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}| +.. tabularcolumns:: |p{2.8cm}|p{2.0cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}| .. _rgb-formats: @@ -139,6 +139,144 @@ next to each other in memory. - r\ :sub:`1` - r\ :sub:`0` - + * .. _V4L2-PIX-FMT-RGBA444: + + - ``V4L2_PIX_FMT_RGBA444`` + - 'RA12' + + - b\ :sub:`3` + - b\ :sub:`2` + - b\ :sub:`1` + - b\ :sub:`0` + - a\ :sub:`3` + - a\ :sub:`2` + - a\ :sub:`1` + - a\ :sub:`0` + + - r\ :sub:`3` + - r\ :sub:`2` + - r\ :sub:`1` + - r\ :sub:`0` + - g\ :sub:`3` + - g\ :sub:`2` + - g\ :sub:`1` + - g\ :sub:`0` + - + * .. _V4L2-PIX-FMT-RGBX444: + + - ``V4L2_PIX_FMT_RGBX444`` + - 'RX12' + + - b\ :sub:`3` + - b\ :sub:`2` + - b\ :sub:`1` + - b\ :sub:`0` + - + - + - + - + + - r\ :sub:`3` + - r\ :sub:`2` + - r\ :sub:`1` + - r\ :sub:`0` + - g\ :sub:`3` + - g\ :sub:`2` + - g\ :sub:`1` + - g\ :sub:`0` + - + * .. _V4L2-PIX-FMT-ABGR444: + + - ``V4L2_PIX_FMT_ABGR444`` + - 'AB12' + + - g\ :sub:`3` + - g\ :sub:`2` + - g\ :sub:`1` + - g\ :sub:`0` + - r\ :sub:`3` + - r\ :sub:`2` + - r\ :sub:`1` + - r\ :sub:`0` + + - a\ :sub:`3` + - a\ :sub:`2` + - a\ :sub:`1` + - a\ :sub:`0` + - b\ :sub:`3` + - b\ :sub:`2` + - b\ :sub:`1` + - b\ :sub:`0` + - + * .. _V4L2-PIX-FMT-XBGR444: + + - ``V4L2_PIX_FMT_XBGR444`` + - 'XB12' + + - g\ :sub:`3` + - g\ :sub:`2` + - g\ :sub:`1` + - g\ :sub:`0` + - r\ :sub:`3` + - r\ :sub:`2` + - r\ :sub:`1` + - r\ :sub:`0` + + - + - + - + - + - b\ :sub:`3` + - b\ :sub:`2` + - b\ :sub:`1` + - b\ :sub:`0` + - + * .. _V4L2-PIX-FMT-BGRA444: + + - ``V4L2_PIX_FMT_BGRA444`` + - 'BA12' + + - r\ :sub:`3` + - r\ :sub:`2` + - r\ :sub:`1` + - r\ :sub:`0` + - a\ :sub:`3` + - a\ :sub:`2` + - a\ :sub:`1` + - a\ :sub:`0` + + - b\ :sub:`3` + - b\ :sub:`2` + - b\ :sub:`1` + - b\ :sub:`0` + - g\ :sub:`3` + - g\ :sub:`2` + - g\ :sub:`1` + - g\ :sub:`0` + - + * .. _V4L2-PIX-FMT-BGRX444: + + - ``V4L2_PIX_FMT_BGRX444`` + - 'BX12' + + - r\ :sub:`3` + - r\ :sub:`2` + - r\ :sub:`1` + - r\ :sub:`0` + - + - + - + - + + - b\ :sub:`3` + - b\ :sub:`2` + - b\ :sub:`1` + - b\ :sub:`0` + - g\ :sub:`3` + - g\ :sub:`2` + - g\ :sub:`1` + - g\ :sub:`0` + - * .. _V4L2-PIX-FMT-ARGB555: - ``V4L2_PIX_FMT_ARGB555`` @@ -185,6 +323,144 @@ next to each other in memory. - g\ :sub:`4` - g\ :sub:`3` - + * .. _V4L2-PIX-FMT-RGBA555: + + - ``V4L2_PIX_FMT_RGBA555`` + - 'RA15' + + - g\ :sub:`1` + - g\ :sub:`0` + - b\ :sub:`4` + - b\ :sub:`3` + - b\ :sub:`2` + - b\ :sub:`1` + - b\ :sub:`0` + - a + + - r\ :sub:`4` + - r\ :sub:`3` + - r\ :sub:`2` + - r\ :sub:`1` + - r\ :sub:`0` + - g\ :sub:`4` + - g\ :sub:`3` + - g\ :sub:`2` + - + * .. _V4L2-PIX-FMT-RGBX555: + + - ``V4L2_PIX_FMT_RGBX555`` + - 'RX15' + + - g\ :sub:`1` + - g\ :sub:`0` + - b\ :sub:`4` + - b\ :sub:`3` + - b\ :sub:`2` + - b\ :sub:`1` + - b\ :sub:`0` + - + + - r\ :sub:`4` + - r\ :sub:`3` + - r\ :sub:`2` + - r\ :sub:`1` + - r\ :sub:`0` + - g\ :sub:`4` + - g\ :sub:`3` + - g\ :sub:`2` + - + * .. _V4L2-PIX-FMT-ABGR555: + + - ``V4L2_PIX_FMT_ABGR555`` + - 'AB15' + + - g\ :sub:`2` + - g\ :sub:`1` + - g\ :sub:`0` + - r\ :sub:`4` + - r\ :sub:`3` + - r\ :sub:`2` + - r\ :sub:`1` + - r\ :sub:`0` + + - a + - b\ :sub:`4` + - b\ :sub:`3` + - b\ :sub:`2` + - b\ :sub:`1` + - b\ :sub:`0` + - g\ :sub:`4` + - g\ :sub:`3` + - + * .. _V4L2-PIX-FMT-XBGR555: + + - ``V4L2_PIX_FMT_XBGR555`` + - 'XB15' + + - g\ :sub:`2` + - g\ :sub:`1` + - g\ :sub:`0` + - r\ :sub:`4` + - r\ :sub:`3` + - r\ :sub:`2` + - r\ :sub:`1` + - r\ :sub:`0` + + - + - b\ :sub:`4` + - b\ :sub:`3` + - b\ :sub:`2` + - b\ :sub:`1` + - b\ :sub:`0` + - g\ :sub:`4` + - g\ :sub:`3` + - + * .. _V4L2-PIX-FMT-BGRA555: + + - ``V4L2_PIX_FMT_BGRA555`` + - 'BA15' + + - g\ :sub:`1` + - g\ :sub:`0` + - r\ :sub:`4` + - r\ :sub:`3` + - r\ :sub:`2` + - r\ :sub:`1` + - r\ :sub:`0` + - a + + - b\ :sub:`4` + - b\ :sub:`3` + - b\ :sub:`2` + - b\ :sub:`1` + - b\ :sub:`0` + - g\ :sub:`4` + - g\ :sub:`3` + - g\ :sub:`2` + - + * .. _V4L2-PIX-FMT-BGRX555: + + - ``V4L2_PIX_FMT_BGRX555`` + - 'BX15' + + - g\ :sub:`1` + - g\ :sub:`0` + - r\ :sub:`4` + - r\ :sub:`3` + - r\ :sub:`2` + - r\ :sub:`1` + - r\ :sub:`0` + - + + - b\ :sub:`4` + - b\ :sub:`3` + - b\ :sub:`2` + - b\ :sub:`1` + - b\ :sub:`0` + - g\ :sub:`4` + - g\ :sub:`3` + - g\ :sub:`2` + - * .. _V4L2-PIX-FMT-RGB565: - ``V4L2_PIX_FMT_RGB565`` @@ -461,6 +737,166 @@ next to each other in memory. - - - + * .. _V4L2-PIX-FMT-BGRA32: + + - ``V4L2_PIX_FMT_BGRA32`` + - 'RA24' + + - a\ :sub:`7` + - a\ :sub:`6` + - a\ :sub:`5` + - a\ :sub:`4` + - a\ :sub:`3` + - a\ :sub:`2` + - a\ :sub:`1` + - a\ :sub:`0` + + - b\ :sub:`7` + - b\ :sub:`6` + - b\ :sub:`5` + - b\ :sub:`4` + - b\ :sub:`3` + - b\ :sub:`2` + - b\ :sub:`1` + - b\ :sub:`0` + + - g\ :sub:`7` + - g\ :sub:`6` + - g\ :sub:`5` + - g\ :sub:`4` + - g\ :sub:`3` + - g\ :sub:`2` + - g\ :sub:`1` + - g\ :sub:`0` + + - r\ :sub:`7` + - r\ :sub:`6` + - r\ :sub:`5` + - r\ :sub:`4` + - r\ :sub:`3` + - r\ :sub:`2` + - r\ :sub:`1` + - r\ :sub:`0` + * .. _V4L2-PIX-FMT-BGRX32: + + - ``V4L2_PIX_FMT_BGRX32`` + - 'RX24' + + - + - + - + - + - + - + - + - + + - b\ :sub:`7` + - b\ :sub:`6` + - b\ :sub:`5` + - b\ :sub:`4` + - b\ :sub:`3` + - b\ :sub:`2` + - b\ :sub:`1` + - b\ :sub:`0` + + - g\ :sub:`7` + - g\ :sub:`6` + - g\ :sub:`5` + - g\ :sub:`4` + - g\ :sub:`3` + - g\ :sub:`2` + - g\ :sub:`1` + - g\ :sub:`0` + + - r\ :sub:`7` + - r\ :sub:`6` + - r\ :sub:`5` + - r\ :sub:`4` + - r\ :sub:`3` + - r\ :sub:`2` + - r\ :sub:`1` + - r\ :sub:`0` + * .. _V4L2-PIX-FMT-RGBA32: + + - ``V4L2_PIX_FMT_RGBA32`` + - 'AB24' + + - r\ :sub:`7` + - r\ :sub:`6` + - r\ :sub:`5` + - r\ :sub:`4` + - r\ :sub:`3` + - r\ :sub:`2` + - r\ :sub:`1` + - r\ :sub:`0` + + - g\ :sub:`7` + - g\ :sub:`6` + - g\ :sub:`5` + - g\ :sub:`4` + - g\ :sub:`3` + - g\ :sub:`2` + - g\ :sub:`1` + - g\ :sub:`0` + + - b\ :sub:`7` + - b\ :sub:`6` + - b\ :sub:`5` + - b\ :sub:`4` + - b\ :sub:`3` + - b\ :sub:`2` + - b\ :sub:`1` + - b\ :sub:`0` + + - a\ :sub:`7` + - a\ :sub:`6` + - a\ :sub:`5` + - a\ :sub:`4` + - a\ :sub:`3` + - a\ :sub:`2` + - a\ :sub:`1` + - a\ :sub:`0` + * .. _V4L2-PIX-FMT-RGBX32: + + - ``V4L2_PIX_FMT_RGBX32`` + - 'XB24' + + - r\ :sub:`7` + - r\ :sub:`6` + - r\ :sub:`5` + - r\ :sub:`4` + - r\ :sub:`3` + - r\ :sub:`2` + - r\ :sub:`1` + - r\ :sub:`0` + + - g\ :sub:`7` + - g\ :sub:`6` + - g\ :sub:`5` + - g\ :sub:`4` + - g\ :sub:`3` + - g\ :sub:`2` + - g\ :sub:`1` + - g\ :sub:`0` + + - b\ :sub:`7` + - b\ :sub:`6` + - b\ :sub:`5` + - b\ :sub:`4` + - b\ :sub:`3` + - b\ :sub:`2` + - b\ :sub:`1` + - b\ :sub:`0` + + - + - + - + - + - + - + - + - * .. _V4L2-PIX-FMT-ARGB32: - ``V4L2_PIX_FMT_ARGB32`` @@ -656,7 +1092,7 @@ either the corresponding ARGB or XRGB format, depending on the driver. \tiny \setlength{\tabcolsep}{2pt} -.. tabularcolumns:: |p{2.2cm}|p{0.60cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}| +.. tabularcolumns:: |p{2.6cm}|p{0.70cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}| .. _rgb-formats-deprecated: diff --git a/Documentation/media/uapi/v4l/pixfmt-packed-yuv.rst b/Documentation/media/uapi/v4l/pixfmt-packed-yuv.rst index 7fcee1c11ac4..41b60fae703a 100644 --- a/Documentation/media/uapi/v4l/pixfmt-packed-yuv.rst +++ b/Documentation/media/uapi/v4l/pixfmt-packed-yuv.rst @@ -28,7 +28,7 @@ component of each pixel in one 16 or 32 bit word. .. _packed-yuv-formats: -.. tabularcolumns:: |p{2.0cm}|p{0.67cm}|p{0.29cm}|p{0.29cm}|p{0.29cm}|p{0.29cm}|p{0.29cm}|p{0.29cm}|p{0.29cm}|p{0.29cm}|p{0.29cm}|p{0.29cm}|p{0.29cm}|p{0.29cm}|p{0.29cm}|p{0.29cm}|p{0.29cm}|p{0.29cm}|p{0.29cm}|p{0.29cm}|p{0.29cm}|p{0.29cm}|p{0.29cm}|p{0.29cm}|p{0.29cm}|p{0.29cm}|p{0.29cm}|p{0.29cm}|p{0.29cm}|p{0.29cm}|p{0.29cm}|p{0.29cm}|p{0.29cm}|p{0.29cm}| +.. tabularcolumns:: |p{2.5cm}|p{0.69cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}| .. flat-table:: Packed YUV Image Formats :header-rows: 2 @@ -44,6 +44,7 @@ component of each pixel in one 16 or 32 bit word. - :cspan:`7` Byte 2 - :cspan:`7` Byte 3 + * - - - 7 @@ -81,6 +82,7 @@ component of each pixel in one 16 or 32 bit word. - 2 - 1 - 0 + * .. _V4L2-PIX-FMT-YUV444: - ``V4L2_PIX_FMT_YUV444`` @@ -103,7 +105,9 @@ component of each pixel in one 16 or 32 bit word. - Y'\ :sub:`2` - Y'\ :sub:`1` - Y'\ :sub:`0` - - + + - :cspan:`15` + * .. _V4L2-PIX-FMT-YUV555: - ``V4L2_PIX_FMT_YUV555`` @@ -126,7 +130,8 @@ component of each pixel in one 16 or 32 bit word. - Y'\ :sub:`0` - Cb\ :sub:`4` - Cb\ :sub:`3` - - + + - :cspan:`15` * .. _V4L2-PIX-FMT-YUV565: - ``V4L2_PIX_FMT_YUV565`` @@ -149,7 +154,9 @@ component of each pixel in one 16 or 32 bit word. - Cb\ :sub:`5` - Cb\ :sub:`4` - Cb\ :sub:`3` - - + + - :cspan:`15` + * .. _V4L2-PIX-FMT-YUV32: - ``V4L2_PIX_FMT_YUV32`` @@ -190,7 +197,7 @@ component of each pixel in one 16 or 32 bit word. - Cr\ :sub:`2` - Cr\ :sub:`1` - Cr\ :sub:`0` - - + * .. _V4L2-PIX-FMT-AYUV32: - ``V4L2_PIX_FMT_AYUV32`` @@ -231,7 +238,7 @@ component of each pixel in one 16 or 32 bit word. - Cr\ :sub:`2` - Cr\ :sub:`1` - Cr\ :sub:`0` - - + * .. _V4L2-PIX-FMT-XYUV32: - ``V4L2_PIX_FMT_XYUV32`` @@ -272,7 +279,7 @@ component of each pixel in one 16 or 32 bit word. - Cr\ :sub:`2` - Cr\ :sub:`1` - Cr\ :sub:`0` - - + * .. _V4L2-PIX-FMT-VUYA32: - ``V4L2_PIX_FMT_VUYA32`` @@ -313,7 +320,7 @@ component of each pixel in one 16 or 32 bit word. - a\ :sub:`2` - a\ :sub:`1` - a\ :sub:`0` - - + * .. _V4L2-PIX-FMT-VUYX32: - ``V4L2_PIX_FMT_VUYX32`` diff --git a/Documentation/media/uapi/v4l/pixfmt-srggb10p.rst b/Documentation/media/uapi/v4l/pixfmt-srggb10p.rst index cdb70ac26126..fd32660a3766 100644 --- a/Documentation/media/uapi/v4l/pixfmt-srggb10p.rst +++ b/Documentation/media/uapi/v4l/pixfmt-srggb10p.rst @@ -40,7 +40,7 @@ of a small V4L2_PIX_FMT_SBGGR10P image: **Byte Order.** Each cell is one byte. -.. tabularcolumns:: |p{2.0cm}|p{1.0cm}|p{1.0cm}|p{1.0cm}|p{1.0cm}|p{5.4cm}| +.. tabularcolumns:: |p{2.4cm}|p{1.4cm}|p{1.2cm}|p{1.2cm}|p{1.2cm}|p{6.4cm}| .. flat-table:: :header-rows: 0 diff --git a/Documentation/media/uapi/v4l/pixfmt-srggb12p.rst b/Documentation/media/uapi/v4l/pixfmt-srggb12p.rst index 01413be12916..960851275f23 100644 --- a/Documentation/media/uapi/v4l/pixfmt-srggb12p.rst +++ b/Documentation/media/uapi/v4l/pixfmt-srggb12p.rst @@ -18,6 +18,7 @@ V4L2_PIX_FMT_SRGGB12P ('pRAA'), V4L2_PIX_FMT_SGRBG12P ('pgAA'), V4L2_PIX_FMT_SGB 12-bit packed Bayer formats +--------------------------- Description @@ -37,7 +38,7 @@ Below is an example of a small V4L2_PIX_FMT_SBGGR12P image: **Byte Order.** Each cell is one byte. -.. tabularcolumns:: |p{2.0cm}|p{1.0cm}|p{1.0cm}|p{2.7cm}|p{1.0cm}|p{1.0cm}|p{2.7cm}| +.. tabularcolumns:: |p{2.2cm}|p{1.2cm}|p{1.2cm}|p{3.1cm}|p{1.2cm}|p{1.2cm}|p{3.1cm}| .. flat-table:: diff --git a/Documentation/media/uapi/v4l/pixfmt-srggb14p.rst b/Documentation/media/uapi/v4l/pixfmt-srggb14p.rst index b583531c2853..1a988d7e7ff8 100644 --- a/Documentation/media/uapi/v4l/pixfmt-srggb14p.rst +++ b/Documentation/media/uapi/v4l/pixfmt-srggb14p.rst @@ -41,17 +41,21 @@ of one of these formats: **Byte Order.** Each cell is one byte. +.. raw:: latex + \footnotesize + +.. tabularcolumns:: |p{1.8cm}|p{1.0cm}|p{1.0cm}|p{1.0cm}|p{1.1cm}|p{3.3cm}|p{3.3cm}|p{3.3cm}| .. flat-table:: :header-rows: 0 :stub-columns: 0 - :widths: 2 1 1 1 1 1 1 1 + :widths: 2 1 1 1 1 3 3 3 - .. row 1 - - start + 0: + - start + 0 - B\ :sub:`00high` @@ -62,17 +66,20 @@ Each cell is one byte. - G\ :sub:`03high` - G\ :sub:`01low bits 1--0`\ (bits 7--6) + B\ :sub:`00low bits 5--0`\ (bits 5--0) - R\ :sub:`02low bits 3--0`\ (bits 7--4) + G\ :sub:`01low bits 5--2`\ (bits 3--0) - G\ :sub:`03low bits 5--0`\ (bits 7--2) + R\ :sub:`02low bits 5--4`\ (bits 1--0) - .. row 2 - - start + 7: + - start + 7 - G\ :sub:`00high` @@ -83,12 +90,15 @@ Each cell is one byte. - R\ :sub:`03high` - R\ :sub:`01low bits 1--0`\ (bits 7--6) + G\ :sub:`00low bits 5--0`\ (bits 5--0) - G\ :sub:`02low bits 3--0`\ (bits 7--4) + R\ :sub:`01low bits 5--2`\ (bits 3--0) - R\ :sub:`03low bits 5--0`\ (bits 7--2) + G\ :sub:`02low bits 5--4`\ (bits 1--0) - .. row 3 @@ -104,12 +114,15 @@ Each cell is one byte. - G\ :sub:`23high` - G\ :sub:`21low bits 1--0`\ (bits 7--6) + B\ :sub:`20low bits 5--0`\ (bits 5--0) - R\ :sub:`22low bits 3--0`\ (bits 7--4) + G\ :sub:`21low bits 5--2`\ (bits 3--0) - G\ :sub:`23low bits 5--0`\ (bits 7--2) + R\ :sub:`22low bits 5--4`\ (bits 1--0) - .. row 4 @@ -132,3 +145,8 @@ Each cell is one byte. - R\ :sub:`33low bits 5--0`\ (bits 7--2) G\ :sub:`32low bits 5--4`\ (bits 1--0) + +.. raw:: latex + + \normalsize + diff --git a/Documentation/media/uapi/v4l/pixfmt-v4l2-mplane.rst b/Documentation/media/uapi/v4l/pixfmt-v4l2-mplane.rst index 7f82dad9013a..5688c816e334 100644 --- a/Documentation/media/uapi/v4l/pixfmt-v4l2-mplane.rst +++ b/Documentation/media/uapi/v4l/pixfmt-v4l2-mplane.rst @@ -19,6 +19,7 @@ array of struct :c:type:`v4l2_plane_pix_format` structures, describing all planes of that format. + .. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}| .. c:type:: v4l2_plane_pix_format @@ -41,6 +42,10 @@ describing all planes of that format. applications. +.. raw:: latex + + \small + .. tabularcolumns:: |p{4.4cm}|p{5.6cm}|p{7.5cm}| .. c:type:: v4l2_pix_format_mplane @@ -82,9 +87,7 @@ describing all planes of that format. * - __u8 - ``flags`` - Flags set by the application or driver, see :ref:`format-flags`. - * - union { - - (anonymous) - - + * - :cspan:`2` union { (anonymous) * - __u8 - ``ycbcr_enc`` - Y'CbCr encoding, from enum :c:type:`v4l2_ycbcr_encoding`. @@ -97,9 +100,7 @@ describing all planes of that format. This information supplements the ``colorspace`` and must be set by the driver for capture streams and by the application for output streams, see :ref:`colorspaces`. - * - } - - - - + * - :cspan:`2` } * - __u8 - ``quantization`` - Quantization range, from enum :c:type:`v4l2_quantization`. @@ -116,3 +117,7 @@ describing all planes of that format. - ``reserved[7]`` - Reserved for future extensions. Should be zeroed by drivers and applications. + +.. raw:: latex + + \normalsize diff --git a/Documentation/media/uapi/v4l/pixfmt-y10p.rst b/Documentation/media/uapi/v4l/pixfmt-y10p.rst index 7893642faee3..39cd789dcb59 100644 --- a/Documentation/media/uapi/v4l/pixfmt-y10p.rst +++ b/Documentation/media/uapi/v4l/pixfmt-y10p.rst @@ -27,6 +27,12 @@ in the same order. **Bit-packed representation.** +.. raw:: latex + + \small + +.. tabularcolumns:: |p{1.2cm}||p{1.2cm}||p{1.2cm}||p{1.2cm}|p{3.2cm}|p{3.2cm}| + .. flat-table:: :header-rows: 0 :stub-columns: 0 @@ -38,3 +44,7 @@ in the same order. - Y'\ :sub:`03[9:2]` - Y'\ :sub:`03[1:0]`\ (bits 7--6) Y'\ :sub:`02[1:0]`\ (bits 5--4) Y'\ :sub:`01[1:0]`\ (bits 3--2) Y'\ :sub:`00[1:0]`\ (bits 1--0) + +.. raw:: latex + + \normalsize diff --git a/Documentation/media/uapi/v4l/subdev-formats.rst b/Documentation/media/uapi/v4l/subdev-formats.rst index f5440d55d510..ab1a48a5ae80 100644 --- a/Documentation/media/uapi/v4l/subdev-formats.rst +++ b/Documentation/media/uapi/v4l/subdev-formats.rst @@ -980,6 +980,113 @@ The following tables list existing packed RGB formats. - r\ :sub:`2` - r\ :sub:`1` - r\ :sub:`0` + * .. _MEDIA-BUS-FMT-BGR888-3X8: + + - MEDIA_BUS_FMT_BGR888_3X8 + - 0x101b + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - b\ :sub:`7` + - b\ :sub:`6` + - b\ :sub:`5` + - b\ :sub:`4` + - b\ :sub:`3` + - b\ :sub:`2` + - b\ :sub:`1` + - b\ :sub:`0` + * - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - g\ :sub:`7` + - g\ :sub:`6` + - g\ :sub:`5` + - g\ :sub:`4` + - g\ :sub:`3` + - g\ :sub:`2` + - g\ :sub:`1` + - g\ :sub:`0` + * - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - r\ :sub:`7` + - r\ :sub:`6` + - r\ :sub:`5` + - r\ :sub:`4` + - r\ :sub:`3` + - r\ :sub:`2` + - r\ :sub:`1` + - r\ :sub:`0` * .. _MEDIA-BUS-FMT-GBR888-1X24: - MEDIA_BUS_FMT_GBR888_1X24 @@ -7414,7 +7521,7 @@ The following table lists existing HSV/HSL formats. \tiny \setlength{\tabcolsep}{2pt} -.. tabularcolumns:: |p{3.0cm}|p{0.60cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}| +.. tabularcolumns:: |p{3.9cm}|p{0.73cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}| .. _v4l2-mbus-pixelcode-hsv: @@ -7524,7 +7631,7 @@ The following table lists existing JPEG compressed formats. .. _v4l2-mbus-pixelcode-jpeg: -.. tabularcolumns:: |p{5.4cm}|p{1.4cm}|p{10.7cm}| +.. tabularcolumns:: |p{6.0cm}|p{1.4cm}|p{10.1cm}| .. flat-table:: JPEG Formats :header-rows: 1 @@ -7557,7 +7664,7 @@ formats. .. _v4l2-mbus-pixelcode-vendor-specific: -.. tabularcolumns:: |p{6.8cm}|p{1.4cm}|p{9.3cm}| +.. tabularcolumns:: |p{8.0cm}|p{1.4cm}|p{7.7cm}| .. flat-table:: Vendor and device specific formats :header-rows: 1 diff --git a/Documentation/media/uapi/v4l/vidioc-qbuf.rst b/Documentation/media/uapi/v4l/vidioc-qbuf.rst index c138d149faea..dbf7b445a27b 100644 --- a/Documentation/media/uapi/v4l/vidioc-qbuf.rst +++ b/Documentation/media/uapi/v4l/vidioc-qbuf.rst @@ -111,7 +111,7 @@ in use. Setting it means that the buffer will not be passed to the driver until the request itself is queued. Also, the driver will apply any settings associated with the request for this buffer. This field will be ignored unless the ``V4L2_BUF_FLAG_REQUEST_FD`` flag is set. -If the device does not support requests, then ``EACCES`` will be returned. +If the device does not support requests, then ``EBADR`` will be returned. If requests are supported but an invalid request file descriptor is given, then ``EINVAL`` will be returned. @@ -125,7 +125,7 @@ then ``EINVAL`` will be returned. For :ref:`memory-to-memory devices <mem2mem>` you can specify the ``request_fd`` only for output buffers, not for capture buffers. Attempting - to specify this for a capture buffer will result in an ``EACCES`` error. + to specify this for a capture buffer will result in an ``EBADR`` error. Applications call the ``VIDIOC_DQBUF`` ioctl to dequeue a filled (capturing) or displayed (output) buffer from the driver's outgoing @@ -185,9 +185,11 @@ EPIPE codecs if a buffer with the ``V4L2_BUF_FLAG_LAST`` was already dequeued and no new buffers are expected to become available. -EACCES +EBADR The ``V4L2_BUF_FLAG_REQUEST_FD`` flag was set but the device does not - support requests for the given buffer type. + support requests for the given buffer type, or + the ``V4L2_BUF_FLAG_REQUEST_FD`` flag was not set but the device requires + that the buffer is part of a request. EBUSY The first buffer was queued via a request, but the application now tries diff --git a/Documentation/media/v4l-drivers/index.rst b/Documentation/media/v4l-drivers/index.rst index dfd4b205937c..33a055907258 100644 --- a/Documentation/media/v4l-drivers/index.rst +++ b/Documentation/media/v4l-drivers/index.rst @@ -65,5 +65,4 @@ For more details see the file COPYING in the source distribution of Linux. soc-camera uvcvideo vivid - zoran zr364xx diff --git a/Documentation/media/v4l-drivers/zoran.rst b/Documentation/media/v4l-drivers/zoran.rst deleted file mode 100644 index d2724a863d1d..000000000000 --- a/Documentation/media/v4l-drivers/zoran.rst +++ /dev/null @@ -1,583 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -The Zoran driver -================ - -unified zoran driver (zr360x7, zoran, buz, dc10(+), dc30(+), lml33) - -website: http://mjpeg.sourceforge.net/driver-zoran/ - - -Frequently Asked Questions --------------------------- - -What cards are supported ------------------------- - -Iomega Buz, Linux Media Labs LML33/LML33R10, Pinnacle/Miro -DC10/DC10+/DC30/DC30+ and related boards (available under various names). - -Iomega Buz -~~~~~~~~~~ - -* Zoran zr36067 PCI controller -* Zoran zr36060 MJPEG codec -* Philips saa7111 TV decoder -* Philips saa7185 TV encoder - -Drivers to use: videodev, i2c-core, i2c-algo-bit, -videocodec, saa7111, saa7185, zr36060, zr36067 - -Inputs/outputs: Composite and S-video - -Norms: PAL, SECAM (720x576 @ 25 fps), NTSC (720x480 @ 29.97 fps) - -Card number: 7 - -AverMedia 6 Eyes AVS6EYES -~~~~~~~~~~~~~~~~~~~~~~~~~ - -* Zoran zr36067 PCI controller -* Zoran zr36060 MJPEG codec -* Samsung ks0127 TV decoder -* Conexant bt866 TV encoder - -Drivers to use: videodev, i2c-core, i2c-algo-bit, -videocodec, ks0127, bt866, zr36060, zr36067 - -Inputs/outputs: - Six physical inputs. 1-6 are composite, - 1-2, 3-4, 5-6 doubles as S-video, - 1-3 triples as component. - One composite output. - -Norms: PAL, SECAM (720x576 @ 25 fps), NTSC (720x480 @ 29.97 fps) - -Card number: 8 - -.. note:: - - Not autodetected, card=8 is necessary. - -Linux Media Labs LML33 -~~~~~~~~~~~~~~~~~~~~~~ - -* Zoran zr36067 PCI controller -* Zoran zr36060 MJPEG codec -* Brooktree bt819 TV decoder -* Brooktree bt856 TV encoder - -Drivers to use: videodev, i2c-core, i2c-algo-bit, -videocodec, bt819, bt856, zr36060, zr36067 - -Inputs/outputs: Composite and S-video - -Norms: PAL (720x576 @ 25 fps), NTSC (720x480 @ 29.97 fps) - -Card number: 5 - -Linux Media Labs LML33R10 -~~~~~~~~~~~~~~~~~~~~~~~~~ - -* Zoran zr36067 PCI controller -* Zoran zr36060 MJPEG codec -* Philips saa7114 TV decoder -* Analog Devices adv7170 TV encoder - -Drivers to use: videodev, i2c-core, i2c-algo-bit, -videocodec, saa7114, adv7170, zr36060, zr36067 - -Inputs/outputs: Composite and S-video - -Norms: PAL (720x576 @ 25 fps), NTSC (720x480 @ 29.97 fps) - -Card number: 6 - -Pinnacle/Miro DC10(new) -~~~~~~~~~~~~~~~~~~~~~~~ - -* Zoran zr36057 PCI controller -* Zoran zr36060 MJPEG codec -* Philips saa7110a TV decoder -* Analog Devices adv7176 TV encoder - -Drivers to use: videodev, i2c-core, i2c-algo-bit, -videocodec, saa7110, adv7175, zr36060, zr36067 - -Inputs/outputs: Composite, S-video and Internal - -Norms: PAL, SECAM (768x576 @ 25 fps), NTSC (640x480 @ 29.97 fps) - -Card number: 1 - -Pinnacle/Miro DC10+ -~~~~~~~~~~~~~~~~~~~ - -* Zoran zr36067 PCI controller -* Zoran zr36060 MJPEG codec -* Philips saa7110a TV decoder -* Analog Devices adv7176 TV encoder - -Drivers to use: videodev, i2c-core, i2c-algo-bit, -videocodec, sa7110, adv7175, zr36060, zr36067 - -Inputs/outputs: Composite, S-video and Internal - -Norms: PAL, SECAM (768x576 @ 25 fps), NTSC (640x480 @ 29.97 fps) - -Card number: 2 - -Pinnacle/Miro DC10(old) -~~~~~~~~~~~~~~~~~~~~~~~ - -* Zoran zr36057 PCI controller -* Zoran zr36050 MJPEG codec -* Zoran zr36016 Video Front End or Fuji md0211 Video Front End (clone?) -* Micronas vpx3220a TV decoder -* mse3000 TV encoder or Analog Devices adv7176 TV encoder - -Drivers to use: videodev, i2c-core, i2c-algo-bit, -videocodec, vpx3220, mse3000/adv7175, zr36050, zr36016, zr36067 - -Inputs/outputs: Composite, S-video and Internal - -Norms: PAL, SECAM (768x576 @ 25 fps), NTSC (640x480 @ 29.97 fps) - -Card number: 0 - -Pinnacle/Miro DC30 -~~~~~~~~~~~~~~~~~~ - -* Zoran zr36057 PCI controller -* Zoran zr36050 MJPEG codec -* Zoran zr36016 Video Front End -* Micronas vpx3225d/vpx3220a/vpx3216b TV decoder -* Analog Devices adv7176 TV encoder - -Drivers to use: videodev, i2c-core, i2c-algo-bit, -videocodec, vpx3220/vpx3224, adv7175, zr36050, zr36016, zr36067 - -Inputs/outputs: Composite, S-video and Internal - -Norms: PAL, SECAM (768x576 @ 25 fps), NTSC (640x480 @ 29.97 fps) - -Card number: 3 - -Pinnacle/Miro DC30+ -~~~~~~~~~~~~~~~~~~~ - -* Zoran zr36067 PCI controller -* Zoran zr36050 MJPEG codec -* Zoran zr36016 Video Front End -* Micronas vpx3225d/vpx3220a/vpx3216b TV decoder -* Analog Devices adv7176 TV encoder - -Drivers to use: videodev, i2c-core, i2c-algo-bit, -videocodec, vpx3220/vpx3224, adv7175, zr36050, zr36015, zr36067 - -Inputs/outputs: Composite, S-video and Internal - -Norms: PAL, SECAM (768x576 @ 25 fps), NTSC (640x480 @ 29.97 fps) - -Card number: 4 - -.. note:: - - #) No module for the mse3000 is available yet - #) No module for the vpx3224 is available yet - -1.1 What the TV decoder can do an what not ------------------------------------------- - -The best know TV standards are NTSC/PAL/SECAM. but for decoding a frame that -information is not enough. There are several formats of the TV standards. -And not every TV decoder is able to handle every format. Also the every -combination is supported by the driver. There are currently 11 different -tv broadcast formats all aver the world. - -The CCIR defines parameters needed for broadcasting the signal. -The CCIR has defined different standards: A,B,D,E,F,G,D,H,I,K,K1,L,M,N,... -The CCIR says not much about the colorsystem used !!! -And talking about a colorsystem says not to much about how it is broadcast. - -The CCIR standards A,E,F are not used any more. - -When you speak about NTSC, you usually mean the standard: CCIR - M using -the NTSC colorsystem which is used in the USA, Japan, Mexico, Canada -and a few others. - -When you talk about PAL, you usually mean: CCIR - B/G using the PAL -colorsystem which is used in many Countries. - -When you talk about SECAM, you mean: CCIR - L using the SECAM Colorsystem -which is used in France, and a few others. - -There the other version of SECAM, CCIR - D/K is used in Bulgaria, China, -Slovakai, Hungary, Korea (Rep.), Poland, Rumania and a others. - -The CCIR - H uses the PAL colorsystem (sometimes SECAM) and is used in -Egypt, Libya, Sri Lanka, Syrain Arab. Rep. - -The CCIR - I uses the PAL colorsystem, and is used in Great Britain, Hong Kong, -Ireland, Nigeria, South Africa. - -The CCIR - N uses the PAL colorsystem and PAL frame size but the NTSC framerate, -and is used in Argentinia, Uruguay, an a few others - -We do not talk about how the audio is broadcast ! - -A rather good sites about the TV standards are: -http://www.sony.jp/support/ -http://info.electronicwerkstatt.de/bereiche/fernsehtechnik/frequenzen_und_normen/Fernsehnormen/ -and http://www.cabl.com/restaurant/channel.html - -Other weird things around: NTSC 4.43 is a modificated NTSC, which is mainly -used in PAL VCR's that are able to play back NTSC. PAL 60 seems to be the same -as NTSC 4.43 . The Datasheets also talk about NTSC 44, It seems as if it would -be the same as NTSC 4.43. -NTSC Combs seems to be a decoder mode where the decoder uses a comb filter -to split coma and luma instead of a Delay line. - -But I did not defiantly find out what NTSC Comb is. - -Philips saa7111 TV decoder -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -- was introduced in 1997, is used in the BUZ and -- can handle: PAL B/G/H/I, PAL N, PAL M, NTSC M, NTSC N, NTSC 4.43 and SECAM - -Philips saa7110a TV decoder -~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -- was introduced in 1995, is used in the Pinnacle/Miro DC10(new), DC10+ and -- can handle: PAL B/G, NTSC M and SECAM - -Philips saa7114 TV decoder -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -- was introduced in 2000, is used in the LML33R10 and -- can handle: PAL B/G/D/H/I/N, PAL N, PAL M, NTSC M, NTSC 4.43 and SECAM - -Brooktree bt819 TV decoder -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -- was introduced in 1996, and is used in the LML33 and -- can handle: PAL B/D/G/H/I, NTSC M - -Micronas vpx3220a TV decoder -~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -- was introduced in 1996, is used in the DC30 and DC30+ and -- can handle: PAL B/G/H/I, PAL N, PAL M, NTSC M, NTSC 44, PAL 60, SECAM,NTSC Comb - -Samsung ks0127 TV decoder -~~~~~~~~~~~~~~~~~~~~~~~~~ - -- is used in the AVS6EYES card and -- can handle: NTSC-M/N/44, PAL-M/N/B/G/H/I/D/K/L and SECAM - - -What the TV encoder can do an what not --------------------------------------- - -The TV encoder are doing the "same" as the decoder, but in the oder direction. -You feed them digital data and the generate a Composite or SVHS signal. -For information about the colorsystems and TV norm take a look in the -TV decoder section. - -Philips saa7185 TV Encoder -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -- was introduced in 1996, is used in the BUZ -- can generate: PAL B/G, NTSC M - -Brooktree bt856 TV Encoder -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -- was introduced in 1994, is used in the LML33 -- can generate: PAL B/D/G/H/I/N, PAL M, NTSC M, PAL-N (Argentina) - -Analog Devices adv7170 TV Encoder -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -- was introduced in 2000, is used in the LML300R10 -- can generate: PAL B/D/G/H/I/N, PAL M, NTSC M, PAL 60 - -Analog Devices adv7175 TV Encoder -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -- was introduced in 1996, is used in the DC10, DC10+, DC10 old, DC30, DC30+ -- can generate: PAL B/D/G/H/I/N, PAL M, NTSC M - -ITT mse3000 TV encoder -~~~~~~~~~~~~~~~~~~~~~~ - -- was introduced in 1991, is used in the DC10 old -- can generate: PAL , NTSC , SECAM - -Conexant bt866 TV encoder -~~~~~~~~~~~~~~~~~~~~~~~~~ - -- is used in AVS6EYES, and -- can generate: NTSC/PAL, PALÂM, PALÂN - -The adv717x, should be able to produce PAL N. But you find nothing PAL N -specific in the registers. Seem that you have to reuse a other standard -to generate PAL N, maybe it would work if you use the PAL M settings. - -How do I get this damn thing to work ------------------------------------- - -Load zr36067.o. If it can't autodetect your card, use the card=X insmod -option with X being the card number as given in the previous section. -To have more than one card, use card=X1[,X2[,X3,[X4[..]]]] - -To automate this, add the following to your /etc/modprobe.d/zoran.conf: - -options zr36067 card=X1[,X2[,X3[,X4[..]]]] -alias char-major-81-0 zr36067 - -One thing to keep in mind is that this doesn't load zr36067.o itself yet. It -just automates loading. If you start using xawtv, the device won't load on -some systems, since you're trying to load modules as a user, which is not -allowed ("permission denied"). A quick workaround is to add 'Load "v4l"' to -XF86Config-4 when you use X by default, or to run 'v4l-conf -c <device>' in -one of your startup scripts (normally rc.local) if you don't use X. Both -make sure that the modules are loaded on startup, under the root account. - -What mainboard should I use (or why doesn't my card work) ---------------------------------------------------------- - - -<insert lousy disclaimer here>. In short: good=SiS/Intel, bad=VIA. - -Experience tells us that people with a Buz, on average, have more problems -than users with a DC10+/LML33. Also, it tells us that people owning a VIA- -based mainboard (ktXXX, MVP3) have more problems than users with a mainboard -based on a different chipset. Here's some notes from Andrew Stevens: - -Here's my experience of using LML33 and Buz on various motherboards: - -- VIA MVP3 - - Forget it. Pointless. Doesn't work. -- Intel 430FX (Pentium 200) - - LML33 perfect, Buz tolerable (3 or 4 frames dropped per movie) -- Intel 440BX (early stepping) - - LML33 tolerable. Buz starting to get annoying (6-10 frames/hour) -- Intel 440BX (late stepping) - - Buz tolerable, LML3 almost perfect (occasional single frame drops) -- SiS735 - - LML33 perfect, Buz tolerable. -- VIA KT133(*) - - LML33 starting to get annoying, Buz poor enough that I have up. - -- Both 440BX boards were dual CPU versions. - -Bernhard Praschinger later added: - -- AMD 751 - - Buz perfect-tolerable -- AMD 760 - - Buz perfect-tolerable - -In general, people on the user mailinglist won't give you much of a chance -if you have a VIA-based motherboard. They may be cheap, but sometimes, you'd -rather want to spend some more money on better boards. In general, VIA -mainboard's IDE/PCI performance will also suck badly compared to others. -You'll noticed the DC10+/DC30+ aren't mentioned anywhere in the overview. -Basically, you can assume that if the Buz works, the LML33 will work too. If -the LML33 works, the DC10+/DC30+ will work too. They're most tolerant to -different mainboard chipsets from all of the supported cards. - -If you experience timeouts during capture, buy a better mainboard or lower -the quality/buffersize during capture (see 'Concerning buffer sizes, quality, -output size etc.'). If it hangs, there's little we can do as of now. Check -your IRQs and make sure the card has its own interrupts. - -Programming interface ---------------------- - -This driver conforms to video4linux2. Support for V4L1 and for the custom -zoran ioctls has been removed in kernel 2.6.38. - -For programming example, please, look at lavrec.c and lavplay.c code in -the MJPEG-tools (http://mjpeg.sf.net/). - -Additional notes for software developers: - - The driver returns maxwidth and maxheight parameters according to - the current TV standard (norm). Therefore, the software which - communicates with the driver and "asks" for these parameters should - first set the correct norm. Well, it seems logically correct: TV - standard is "more constant" for current country than geometry - settings of a variety of TV capture cards which may work in ITU or - square pixel format. - -Applications ------------- - -Applications known to work with this driver: - -TV viewing: - -* xawtv -* kwintv -* probably any TV application that supports video4linux or video4linux2. - -MJPEG capture/playback: - -* mjpegtools/lavtools (or Linux Video Studio) -* gstreamer -* mplayer - -General raw capture: - -* xawtv -* gstreamer -* probably any application that supports video4linux or video4linux2 - -Video editing: - -* Cinelerra -* MainActor -* mjpegtools (or Linux Video Studio) - - -Concerning buffer sizes, quality, output size etc. --------------------------------------------------- - - -The zr36060 can do 1:2 JPEG compression. This is really the theoretical -maximum that the chipset can reach. The driver can, however, limit compression -to a maximum (size) of 1:4. The reason for this is that some cards (e.g. Buz) -can't handle 1:2 compression without stopping capture after only a few minutes. -With 1:4, it'll mostly work. If you have a Buz, use 'low_bitrate=1' to go into -1:4 max. compression mode. - -100% JPEG quality is thus 1:2 compression in practice. So for a full PAL frame -(size 720x576). The JPEG fields are stored in YUY2 format, so the size of the -fields are 720x288x16/2 bits/field (2 fields/frame) = 207360 bytes/field x 2 = -414720 bytes/frame (add some more bytes for headers and DHT (huffman)/DQT -(quantization) tables, and you'll get to something like 512kB per frame for -1:2 compression. For 1:4 compression, you'd have frames of half this size. - -Some additional explanation by Martin Samuelsson, which also explains the -importance of buffer sizes: --- -> Hmm, I do not think it is really that way. With the current (downloaded -> at 18:00 Monday) driver I get that output sizes for 10 sec: -> -q 50 -b 128 : 24.283.332 Bytes -> -q 50 -b 256 : 48.442.368 -> -q 25 -b 128 : 24.655.992 -> -q 25 -b 256 : 25.859.820 - -I woke up, and can't go to sleep again. I'll kill some time explaining why -this doesn't look strange to me. - -Let's do some math using a width of 704 pixels. I'm not sure whether the Buz -actually use that number or not, but that's not too important right now. - -704x288 pixels, one field, is 202752 pixels. Divided by 64 pixels per block; -3168 blocks per field. Each pixel consist of two bytes; 128 bytes per block; -1024 bits per block. 100% in the new driver mean 1:2 compression; the maximum -output becomes 512 bits per block. Actually 510, but 512 is simpler to use -for calculations. - -Let's say that we specify d1q50. We thus want 256 bits per block; times 3168 -becomes 811008 bits; 101376 bytes per field. We're talking raw bits and bytes -here, so we don't need to do any fancy corrections for bits-per-pixel or such -things. 101376 bytes per field. - -d1 video contains two fields per frame. Those sum up to 202752 bytes per -frame, and one of those frames goes into each buffer. - -But wait a second! -b128 gives 128kB buffers! It's not possible to cram -202752 bytes of JPEG data into 128kB! - -This is what the driver notice and automatically compensate for in your -examples. Let's do some math using this information: - -128kB is 131072 bytes. In this buffer, we want to store two fields, which -leaves 65536 bytes for each field. Using 3168 blocks per field, we get -20.68686868... available bytes per block; 165 bits. We can't allow the -request for 256 bits per block when there's only 165 bits available! The -q50 -option is silently overridden, and the -b128 option takes precedence, leaving -us with the equivalence of -q32. - -This gives us a data rate of 165 bits per block, which, times 3168, sums up -to 65340 bytes per field, out of the allowed 65536. The current driver has -another level of rate limiting; it won't accept -q values that fill more than -6/8 of the specified buffers. (I'm not sure why. "Playing it safe" seem to be -a safe bet. Personally, I think I would have lowered requested-bits-per-block -by one, or something like that.) We can't use 165 bits per block, but have to -lower it again, to 6/8 of the available buffer space: We end up with 124 bits -per block, the equivalence of -q24. With 128kB buffers, you can't use greater -than -q24 at -d1. (And PAL, and 704 pixels width...) - -The third example is limited to -q24 through the same process. The second -example, using very similar calculations, is limited to -q48. The only -example that actually grab at the specified -q value is the last one, which -is clearly visible, looking at the file size. --- - -Conclusion: the quality of the resulting movie depends on buffer size, quality, -whether or not you use 'low_bitrate=1' as insmod option for the zr36060.c -module to do 1:4 instead of 1:2 compression, etc. - -If you experience timeouts, lowering the quality/buffersize or using -'low_bitrate=1 as insmod option for zr36060.o might actually help, as is -proven by the Buz. - -It hangs/crashes/fails/whatevers! Help! ---------------------------------------- - -Make sure that the card has its own interrupts (see /proc/interrupts), check -the output of dmesg at high verbosity (load zr36067.o with debug=2, -load all other modules with debug=1). Check that your mainboard is favorable -(see question 2) and if not, test the card in another computer. Also see the -notes given in question 3 and try lowering quality/buffersize/capturesize -if recording fails after a period of time. - -If all this doesn't help, give a clear description of the problem including -detailed hardware information (memory+brand, mainboard+chipset+brand, which -MJPEG card, processor, other PCI cards that might be of interest), give the -system PnP information (/proc/interrupts, /proc/dma, /proc/devices), and give -the kernel version, driver version, glibc version, gcc version and any other -information that might possibly be of interest. Also provide the dmesg output -at high verbosity. See 'Contacting' on how to contact the developers. - -Maintainers/Contacting ----------------------- - -The driver is currently maintained by Laurent Pinchart and Ronald Bultje -(<laurent.pinchart@skynet.be> and <rbultje@ronald.bitfreak.net>). For bug -reports or questions, please contact the mailinglist instead of the developers -individually. For user questions (i.e. bug reports or how-to questions), send -an email to <mjpeg-users@lists.sf.net>, for developers (i.e. if you want to -help programming), send an email to <mjpeg-developer@lists.sf.net>. See -http://www.sf.net/projects/mjpeg/ for subscription information. - -For bug reports, be sure to include all the information as described in -the section 'It hangs/crashes/fails/whatevers! Help!'. Please make sure -you're using the latest version (http://mjpeg.sf.net/driver-zoran/). - -Previous maintainers/developers of this driver include Serguei Miridonov -<mirsev@cicese.mx>, Wolfgang Scherr <scherr@net4you.net>, Dave Perks -<dperks@ibm.net> and Rainer Johanni <Rainer@Johanni.de>. - -Driver's License ----------------- - - This driver is distributed under the terms of the General Public License. - - This program is free software; you can redistribute it and/or modify - it under the terms of the GNU General Public License as published by - the Free Software Foundation; either version 2 of the License, or - (at your option) any later version. - - This program is distributed in the hope that it will be useful, - but WITHOUT ANY WARRANTY; without even the implied warranty of - MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - GNU General Public License for more details. - -See http://www.gnu.org/ for more information. diff --git a/Documentation/serial/README.cycladesZ b/Documentation/serial/cyclades_z.rst index 024a69443cc2..532ff67e2f1c 100644 --- a/Documentation/serial/README.cycladesZ +++ b/Documentation/serial/cyclades_z.rst @@ -1,8 +1,11 @@ +================ +Cyclades-Z notes +================ The Cyclades-Z must have firmware loaded onto the card before it will operate. This operation should be performed during system startup, The firmware, loader program and the latest device driver code are available from Cyclades at - ftp://ftp.cyclades.com/pub/cyclades/cyclades-z/linux/ + ftp://ftp.cyclades.com/pub/cyclades/cyclades-z/linux/ diff --git a/Documentation/serial/driver b/Documentation/serial/driver.rst index 86e47c19a924..4537119bf624 100644 --- a/Documentation/serial/driver +++ b/Documentation/serial/driver.rst @@ -1,6 +1,6 @@ - - Low Level Serial API - -------------------- +==================== +Low Level Serial API +==================== This document is meant as a brief overview of some aspects of the new serial @@ -44,7 +44,7 @@ are described in the uart_ops listing below.) There are two locks. A per-port spinlock, and an overall semaphore. From the core driver perspective, the port->lock locks the following -data: +data:: port->mctrl port->icount @@ -75,41 +75,51 @@ hardware. return TIOCSER_TEMT. Locking: none. + Interrupts: caller dependent. + This call must not sleep set_mctrl(port, mctrl) This function sets the modem control lines for port described by 'port' to the state described by mctrl. The relevant bits of mctrl are: + - TIOCM_RTS RTS signal. - TIOCM_DTR DTR signal. - TIOCM_OUT1 OUT1 signal. - TIOCM_OUT2 OUT2 signal. - TIOCM_LOOP Set the port into loopback mode. + If the appropriate bit is set, the signal should be driven active. If the bit is clear, the signal should be driven inactive. Locking: port->lock taken. + Interrupts: locally disabled. + This call must not sleep get_mctrl(port) Returns the current state of modem control inputs. The state of the outputs should not be returned, since the core keeps track of their state. The state information should include: + - TIOCM_CAR state of DCD signal - TIOCM_CTS state of CTS signal - TIOCM_DSR state of DSR signal - TIOCM_RI state of RI signal + The bit is set if the signal is currently driven active. If the port does not support CTS, DCD or DSR, the driver should indicate that the signal is permanently active. If RI is not available, the signal should not be indicated as active. Locking: port->lock taken. + Interrupts: locally disabled. + This call must not sleep stop_tx(port) @@ -121,14 +131,18 @@ hardware. possible. Locking: port->lock taken. + Interrupts: locally disabled. + This call must not sleep start_tx(port) Start transmitting characters. Locking: port->lock taken. + Interrupts: locally disabled. + This call must not sleep throttle(port) @@ -138,16 +152,17 @@ hardware. This will be called only if hardware assisted flow control is enabled. Locking: serialized with .unthrottle() and termios modification by the - tty layer. + tty layer. unthrottle(port) Notify the serial driver that characters can now be sent to the serial port without fear of overrunning the input buffers of the line disciplines. + This will be called only if hardware assisted flow control is enabled. Locking: serialized with .throttle() and termios modification by the - tty layer. + tty layer. send_xchar(port,ch) Transmit a high priority character, even if the port is stopped. @@ -159,6 +174,7 @@ hardware. Do not transmit if ch == '\0' (__DISABLED_CHAR). Locking: none. + Interrupts: caller dependent. stop_rx(port) @@ -166,7 +182,9 @@ hardware. being closed. Locking: port->lock taken. + Interrupts: locally disabled. + This call must not sleep enable_ms(port) @@ -177,7 +195,9 @@ hardware. called. Locking: port->lock taken. + Interrupts: locally disabled. + This call must not sleep break_ctl(port,ctl) @@ -196,6 +216,7 @@ hardware. This method will only be called when the port is initially opened. Locking: port_sem taken. + Interrupts: globally disabled. shutdown(port) @@ -210,6 +231,7 @@ hardware. this port. Locking: port_sem taken. + Interrupts: caller dependent. flush_buffer(port) @@ -220,7 +242,9 @@ hardware. buffer is cleared. Locking: port->lock taken. + Interrupts: locally disabled. + This call must not sleep set_termios(port,termios,oldtermios) @@ -228,29 +252,46 @@ hardware. bits. Update read_status_mask and ignore_status_mask to indicate the types of events we are interested in receiving. Relevant termios->c_cflag bits are: - CSIZE - word size - CSTOPB - 2 stop bits - PARENB - parity enable - PARODD - odd parity (when PARENB is in force) - CREAD - enable reception of characters (if not set, + + CSIZE + - word size + CSTOPB + - 2 stop bits + PARENB + - parity enable + PARODD + - odd parity (when PARENB is in force) + CREAD + - enable reception of characters (if not set, still receive characters from the port, but throw them away. - CRTSCTS - if set, enable CTS status change reporting - CLOCAL - if not set, enable modem status change + CRTSCTS + - if set, enable CTS status change reporting + CLOCAL + - if not set, enable modem status change reporting. + Relevant termios->c_iflag bits are: - INPCK - enable frame and parity error events to be + + INPCK + - enable frame and parity error events to be passed to the TTY layer. - BRKINT - PARMRK - both of these enable break events to be + BRKINT / PARMRK + - both of these enable break events to be passed to the TTY layer. - IGNPAR - ignore parity and framing errors - IGNBRK - ignore break errors, If IGNPAR is also + IGNPAR + - ignore parity and framing errors + IGNBRK + - ignore break errors, If IGNPAR is also set, ignore overrun errors as well. + The interaction of the iflag bits is as follows (parity error given as an example): + + =============== ======= ====== ============================= Parity error INPCK IGNPAR + =============== ======= ====== ============================= n/a 0 n/a character received, marked as TTY_NORMAL None 1 n/a character received, marked as @@ -258,16 +299,19 @@ hardware. Yes 1 0 character received, marked as TTY_PARITY Yes 1 1 character discarded + =============== ======= ====== ============================= Other flags may be used (eg, xon/xoff characters) if your hardware supports hardware "soft" flow control. Locking: caller holds tty_port->mutex + Interrupts: caller dependent. + This call must not sleep set_ldisc(port,termios) - Notifier for discipline change. See Documentation/serial/tty.txt. + Notifier for discipline change. See Documentation/serial/tty.rst. Locking: caller holds tty_port->mutex @@ -283,6 +327,7 @@ hardware. will occur even if CONFIG_PM is not set. Locking: none. + Interrupts: caller dependent. type(port) @@ -291,6 +336,7 @@ hardware. substituted. Locking: none. + Interrupts: caller dependent. release_port(port) @@ -298,6 +344,7 @@ hardware. the port. Locking: none. + Interrupts: caller dependent. request_port(port) @@ -306,6 +353,7 @@ hardware. returns, and it should return -EBUSY on failure. Locking: none. + Interrupts: caller dependent. config_port(port,type) @@ -321,6 +369,7 @@ hardware. internally hard wired (eg, system on a chip implementations). Locking: none. + Interrupts: caller dependent. verify_port(port,serinfo) @@ -328,6 +377,7 @@ hardware. suitable for this port type. Locking: none. + Interrupts: caller dependent. ioctl(port,cmd,arg) @@ -335,6 +385,7 @@ hardware. using the standard numbering system found in <asm/ioctl.h> Locking: none. + Interrupts: caller dependent. poll_init(port) @@ -343,6 +394,7 @@ hardware. this should not request interrupts. Locking: tty_mutex and tty_port->mutex taken. + Interrupts: n/a. poll_put_char(port,ch) @@ -350,7 +402,9 @@ hardware. port. It can and should block until there is space in the TX FIFO. Locking: none. + Interrupts: caller dependent. + This call must not sleep poll_get_char(port) @@ -359,7 +413,9 @@ hardware. the function should return NO_POLL_CHAR immediately. Locking: none. + Interrupts: caller dependent. + This call must not sleep Other functions @@ -370,6 +426,7 @@ uart_update_timeout(port,cflag,baud) number of bits, parity, stop bits and baud rate. Locking: caller is expected to take port->lock + Interrupts: n/a uart_get_baud_rate(port,termios,old,min,max) @@ -385,6 +442,7 @@ uart_get_baud_rate(port,termios,old,min,max) Note: min..max must always allow 9600 baud to be selected. Locking: caller dependent. + Interrupts: n/a uart_get_divisor(port,baud) @@ -395,6 +453,7 @@ uart_get_divisor(port,baud) custom divisor instead. Locking: caller dependent. + Interrupts: n/a uart_match_port(port1,port2) @@ -402,6 +461,7 @@ uart_match_port(port1,port2) uart_port structures describe the same port. Locking: n/a + Interrupts: n/a uart_write_wakeup(port) @@ -409,6 +469,7 @@ uart_write_wakeup(port) characters in the transmit buffer have dropped below a threshold. Locking: port->lock should be held. + Interrupts: n/a uart_register_driver(drv) @@ -419,6 +480,7 @@ uart_register_driver(drv) registered using uart_add_one_port after this call has succeeded. Locking: none + Interrupts: enabled uart_unregister_driver() @@ -427,15 +489,16 @@ uart_unregister_driver() uart_remove_one_port() if it registered them with uart_add_one_port(). Locking: none + Interrupts: enabled -uart_suspend_port() +**uart_suspend_port()** -uart_resume_port() +**uart_resume_port()** -uart_add_one_port() +**uart_add_one_port()** -uart_remove_one_port() +**uart_remove_one_port()** Other notes ----------- @@ -444,7 +507,7 @@ It is intended some day to drop the 'unused' entries from uart_port, and allow low level drivers to register their own individual uart_port's with the core. This will allow drivers to use uart_port as a pointer to a structure containing both the uart_port entry with their own extensions, -thus: +thus:: struct my_port { struct uart_port port; @@ -459,14 +522,14 @@ Some helpers are provided in order to set/get modem control lines via GPIO. mctrl_gpio_init(port, idx): This will get the {cts,rts,...}-gpios from device tree if they are present and request them, set direction etc, and return an - allocated structure. devm_* functions are used, so there's no need + allocated structure. `devm_*` functions are used, so there's no need to call mctrl_gpio_free(). As this sets up the irq handling make sure to not handle changes to the gpio input lines in your driver, too. mctrl_gpio_free(dev, gpios): This will free the requested gpios in mctrl_gpio_init(). - As devm_* functions are used, there's generally no need to call + As `devm_*` functions are used, there's generally no need to call this function. mctrl_gpio_to_gpiod(gpios, gidx) diff --git a/Documentation/serial/index.rst b/Documentation/serial/index.rst new file mode 100644 index 000000000000..d0ba22ea23bf --- /dev/null +++ b/Documentation/serial/index.rst @@ -0,0 +1,32 @@ +:orphan: + +========================== +Support for Serial devices +========================== + +.. toctree:: + :maxdepth: 1 + + + driver + tty + +Serial drivers +============== + +.. toctree:: + :maxdepth: 1 + + cyclades_z + moxa-smartio + n_gsm + rocket + serial-iso7816 + serial-rs485 + +.. only:: subproject and html + + Indices + ======= + + * :ref:`genindex` diff --git a/Documentation/serial/moxa-smartio b/Documentation/serial/moxa-smartio deleted file mode 100644 index 5d2a33be0bd8..000000000000 --- a/Documentation/serial/moxa-smartio +++ /dev/null @@ -1,523 +0,0 @@ -============================================================================= - MOXA Smartio/Industio Family Device Driver Installation Guide - for Linux Kernel 2.4.x, 2.6.x - Copyright (C) 2008, Moxa Inc. -============================================================================= -Date: 01/21/2008 - -Content - -1. Introduction -2. System Requirement -3. Installation - 3.1 Hardware installation - 3.2 Driver files - 3.3 Device naming convention - 3.4 Module driver configuration - 3.5 Static driver configuration for Linux kernel 2.4.x and 2.6.x. - 3.6 Custom configuration - 3.7 Verify driver installation -4. Utilities -5. Setserial -6. Troubleshooting - ------------------------------------------------------------------------------ -1. Introduction - - The Smartio/Industio/UPCI family Linux driver supports following multiport - boards. - - - 2 ports multiport board - CP-102U, CP-102UL, CP-102UF - CP-132U-I, CP-132UL, - CP-132, CP-132I, CP132S, CP-132IS, - CI-132, CI-132I, CI-132IS, - (C102H, C102HI, C102HIS, C102P, CP-102, CP-102S) - - - 4 ports multiport board - CP-104EL, - CP-104UL, CP-104JU, - CP-134U, CP-134U-I, - C104H/PCI, C104HS/PCI, - CP-114, CP-114I, CP-114S, CP-114IS, CP-114UL, - C104H, C104HS, - CI-104J, CI-104JS, - CI-134, CI-134I, CI-134IS, - (C114HI, CT-114I, C104P) - POS-104UL, - CB-114, - CB-134I - - - 8 ports multiport board - CP-118EL, CP-168EL, - CP-118U, CP-168U, - C168H/PCI, - C168H, C168HS, - (C168P), - CB-108 - - This driver and installation procedure have been developed upon Linux Kernel - 2.4.x and 2.6.x. This driver supports Intel x86 hardware platform. In order - to maintain compatibility, this version has also been properly tested with - RedHat, Mandrake, Fedora and S.u.S.E Linux. However, if compatibility problem - occurs, please contact Moxa at support@moxa.com.tw. - - In addition to device driver, useful utilities are also provided in this - version. They are - - msdiag Diagnostic program for displaying installed Moxa - Smartio/Industio boards. - - msmon Monitor program to observe data count and line status signals. - - msterm A simple terminal program which is useful in testing serial - ports. - - io-irq.exe Configuration program to setup ISA boards. Please note that - this program can only be executed under DOS. - - All the drivers and utilities are published in form of source code under - GNU General Public License in this version. Please refer to GNU General - Public License announcement in each source code file for more detail. - - In Moxa's Web sites, you may always find latest driver at http://www.moxa.com/. - - This version of driver can be installed as Loadable Module (Module driver) - or built-in into kernel (Static driver). You may refer to following - installation procedure for suitable one. Before you install the driver, - please refer to hardware installation procedure in the User's Manual. - - We assume the user should be familiar with following documents. - - Serial-HOWTO - - Kernel-HOWTO - ------------------------------------------------------------------------------ -2. System Requirement - - Hardware platform: Intel x86 machine - - Kernel version: 2.4.x or 2.6.x - - gcc version 2.72 or later - - Maximum 4 boards can be installed in combination - ------------------------------------------------------------------------------ -3. Installation - - 3.1 Hardware installation - 3.2 Driver files - 3.3 Device naming convention - 3.4 Module driver configuration - 3.5 Static driver configuration for Linux kernel 2.4.x, 2.6.x. - 3.6 Custom configuration - 3.7 Verify driver installation - - - 3.1 Hardware installation - - There are two types of buses, ISA and PCI, for Smartio/Industio - family multiport board. - - ISA board - --------- - You'll have to configure CAP address, I/O address, Interrupt Vector - as well as IRQ before installing this driver. Please refer to hardware - installation procedure in User's Manual before proceed any further. - Please make sure the JP1 is open after the ISA board is set properly. - - PCI/UPCI board - -------------- - You may need to adjust IRQ usage in BIOS to avoid from IRQ conflict - with other ISA devices. Please refer to hardware installation - procedure in User's Manual in advance. - - PCI IRQ Sharing - ----------- - Each port within the same multiport board shares the same IRQ. Up to - 4 Moxa Smartio/Industio PCI Family multiport boards can be installed - together on one system and they can share the same IRQ. - - - 3.2 Driver files - - The driver file may be obtained from ftp, CD-ROM or floppy disk. The - first step, anyway, is to copy driver file "mxser.tgz" into specified - directory. e.g. /moxa. The execute commands as below. - - # cd / - # mkdir moxa - # cd /moxa - # tar xvf /dev/fd0 - - or - - # cd / - # mkdir moxa - # cd /moxa - # cp /mnt/cdrom/<driver directory>/mxser.tgz . - # tar xvfz mxser.tgz - - - 3.3 Device naming convention - - You may find all the driver and utilities files in /moxa/mxser. - Following installation procedure depends on the model you'd like to - run the driver. If you prefer module driver, please refer to 3.4. - If static driver is required, please refer to 3.5. - - Dialin and callout port - ----------------------- - This driver remains traditional serial device properties. There are - two special file name for each serial port. One is dial-in port - which is named "ttyMxx". For callout port, the naming convention - is "cumxx". - - Device naming when more than 2 boards installed - ----------------------------------------------- - Naming convention for each Smartio/Industio multiport board is - pre-defined as below. - - Board Num. Dial-in Port Callout port - 1st board ttyM0 - ttyM7 cum0 - cum7 - 2nd board ttyM8 - ttyM15 cum8 - cum15 - 3rd board ttyM16 - ttyM23 cum16 - cum23 - 4th board ttyM24 - ttym31 cum24 - cum31 - - - !!!!!!!!!!!!!!!!!!!! NOTE !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! - Under Kernel 2.6 the cum Device is Obsolete. So use ttyM* - device instead. - !!!!!!!!!!!!!!!!!!!! NOTE !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! - - Board sequence - -------------- - This driver will activate ISA boards according to the parameter set - in the driver. After all specified ISA board activated, PCI board - will be installed in the system automatically driven. - Therefore the board number is sorted by the CAP address of ISA boards. - For PCI boards, their sequence will be after ISA boards and C168H/PCI - has higher priority than C104H/PCI boards. - - 3.4 Module driver configuration - Module driver is easiest way to install. If you prefer static driver - installation, please skip this paragraph. - - - ------------- Prepare to use the MOXA driver-------------------- - 3.4.1 Create tty device with correct major number - Before using MOXA driver, your system must have the tty devices - which are created with driver's major number. We offer one shell - script "msmknod" to simplify the procedure. - This step is only needed to be executed once. But you still - need to do this procedure when: - a. You change the driver's major number. Please refer the "3.7" - section. - b. Your total installed MOXA boards number is changed. Maybe you - add/delete one MOXA board. - c. You want to change the tty name. This needs to modify the - shell script "msmknod" - - The procedure is: - # cd /moxa/mxser/driver - # ./msmknod - - This shell script will require the major number for dial-in - device and callout device to create tty device. You also need - to specify the total installed MOXA board number. Default major - numbers for dial-in device and callout device are 30, 35. If - you need to change to other number, please refer section "3.7" - for more detailed procedure. - Msmknod will delete any special files occupying the same device - naming. - - 3.4.2 Build the MOXA driver and utilities - Before using the MOXA driver and utilities, you need compile the - all the source code. This step is only need to be executed once. - But you still re-compile the source code if you modify the source - code. For example, if you change the driver's major number (see - "3.7" section), then you need to do this step again. - - Find "Makefile" in /moxa/mxser, then run - - # make clean; make install - - !!!!!!!!!! NOTE !!!!!!!!!!!!!!!!! - For Red Hat 9, Red Hat Enterprise Linux AS3/ES3/WS3 & Fedora Core1: - # make clean; make installsp1 - - For Red Hat Enterprise Linux AS4/ES4/WS4: - # make clean; make installsp2 - !!!!!!!!!! NOTE !!!!!!!!!!!!!!!!! - - The driver files "mxser.o" and utilities will be properly compiled - and copied to system directories respectively. - - ------------- Load MOXA driver-------------------- - 3.4.3 Load the MOXA driver - - # modprobe mxser <argument> - - will activate the module driver. You may run "lsmod" to check - if "mxser" is activated. If the MOXA board is ISA board, the - <argument> is needed. Please refer to section "3.4.5" for more - information. - - - ------------- Load MOXA driver on boot -------------------- - 3.4.4 For the above description, you may manually execute - "modprobe mxser" to activate this driver and run - "rmmod mxser" to remove it. - However, it's better to have a boot time configuration to - eliminate manual operation. Boot time configuration can be - achieved by rc file. We offer one "rc.mxser" file to simplify - the procedure under "moxa/mxser/driver". - - But if you use ISA board, please modify the "modprobe ..." command - to add the argument (see "3.4.5" section). After modifying the - rc.mxser, please try to execute "/moxa/mxser/driver/rc.mxser" - manually to make sure the modification is ok. If any error - encountered, please try to modify again. If the modification is - completed, follow the below step. - - Run following command for setting rc files. - - # cd /moxa/mxser/driver - # cp ./rc.mxser /etc/rc.d - # cd /etc/rc.d - - Check "rc.serial" is existed or not. If "rc.serial" doesn't exist, - create it by vi, run "chmod 755 rc.serial" to change the permission. - Add "/etc/rc.d/rc.mxser" in last line, - - Reboot and check if moxa.o activated by "lsmod" command. - - 3.4.5. If you'd like to drive Smartio/Industio ISA boards in the system, - you'll have to add parameter to specify CAP address of given - board while activating "mxser.o". The format for parameters are - as follows. - - modprobe mxser ioaddr=0x???,0x???,0x???,0x??? - | | | | - | | | +- 4th ISA board - | | +------ 3rd ISA board - | +------------ 2nd ISA board - +------------------- 1st ISA board - - 3.5 Static driver configuration for Linux kernel 2.4.x and 2.6.x - - Note: To use static driver, you must install the linux kernel - source package. - - 3.5.1 Backup the built-in driver in the kernel. - # cd /usr/src/linux/drivers/char - # mv mxser.c mxser.c.old - - For Red Hat 7.x user, you need to create link: - # cd /usr/src - # ln -s linux-2.4 linux - - 3.5.2 Create link - # cd /usr/src/linux/drivers/char - # ln -s /moxa/mxser/driver/mxser.c mxser.c - - 3.5.3 Add CAP address list for ISA boards. For PCI boards user, - please skip this step. - - In module mode, the CAP address for ISA board is given by - parameter. In static driver configuration, you'll have to - assign it within driver's source code. If you will not - install any ISA boards, you may skip to next portion. - The instructions to modify driver source code are as - below. - a. # cd /moxa/mxser/driver - # vi mxser.c - b. Find the array mxserBoardCAP[] as below. - - static int mxserBoardCAP[] - = {0x00, 0x00, 0x00, 0x00}; - - c. Change the address within this array using vi. For - example, to driver 2 ISA boards with CAP address - 0x280 and 0x180 as 1st and 2nd board. Just to change - the source code as follows. - - static int mxserBoardCAP[] - = {0x280, 0x180, 0x00, 0x00}; - - 3.5.4 Setup kernel configuration - - Configure the kernel: - - # cd /usr/src/linux - # make menuconfig - - You will go into a menu-driven system. Please select [Character - devices][Non-standard serial port support], enable the [Moxa - SmartIO support] driver with "[*]" for built-in (not "[M]"), then - select [Exit] to exit this program. - - 3.5.5 Rebuild kernel - The following are for Linux kernel rebuilding, for your - reference only. - For appropriate details, please refer to the Linux document. - - a. cd /usr/src/linux - b. make clean /* take a few minutes */ - c. make dep /* take a few minutes */ - d. make bzImage /* take probably 10-20 minutes */ - e. make install /* copy boot image to correct position */ - f. Please make sure the boot kernel (vmlinuz) is in the - correct position. - g. If you use 'lilo' utility, you should check /etc/lilo.conf - 'image' item specified the path which is the 'vmlinuz' path, - or you will load wrong (or old) boot kernel image (vmlinuz). - After checking /etc/lilo.conf, please run "lilo". - - Note that if the result of "make bzImage" is ERROR, then you have to - go back to Linux configuration Setup. Type "make menuconfig" in - directory /usr/src/linux. - - - 3.5.6 Make tty device and special file - # cd /moxa/mxser/driver - # ./msmknod - - 3.5.7 Make utility - # cd /moxa/mxser/utility - # make clean; make install - - 3.5.8 Reboot - - - - 3.6 Custom configuration - Although this driver already provides you default configuration, you - still can change the device name and major number. The instruction to - change these parameters are shown as below. - - Change Device name - ------------------ - If you'd like to use other device names instead of default naming - convention, all you have to do is to modify the internal code - within the shell script "msmknod". First, you have to open "msmknod" - by vi. Locate each line contains "ttyM" and "cum" and change them - to the device name you desired. "msmknod" creates the device names - you need next time executed. - - Change Major number - ------------------- - If major number 30 and 35 had been occupied, you may have to select - 2 free major numbers for this driver. There are 3 steps to change - major numbers. - - 3.6.1 Find free major numbers - In /proc/devices, you may find all the major numbers occupied - in the system. Please select 2 major numbers that are available. - e.g. 40, 45. - 3.6.2 Create special files - Run /moxa/mxser/driver/msmknod to create special files with - specified major numbers. - 3.6.3 Modify driver with new major number - Run vi to open /moxa/mxser/driver/mxser.c. Locate the line - contains "MXSERMAJOR". Change the content as below. - #define MXSERMAJOR 40 - #define MXSERCUMAJOR 45 - 3.6.4 Run "make clean; make install" in /moxa/mxser/driver. - - 3.7 Verify driver installation - You may refer to /var/log/messages to check the latest status - log reported by this driver whenever it's activated. - ------------------------------------------------------------------------------ -4. Utilities - There are 3 utilities contained in this driver. They are msdiag, msmon and - msterm. These 3 utilities are released in form of source code. They should - be compiled into executable file and copied into /usr/bin. - - Before using these utilities, please load driver (refer 3.4 & 3.5) and - make sure you had run the "msmknod" utility. - - msdiag - Diagnostic - -------------------- - This utility provides the function to display what Moxa Smartio/Industio - board found by driver in the system. - - msmon - Port Monitoring - ----------------------- - This utility gives the user a quick view about all the MOXA ports' - activities. One can easily learn each port's total received/transmitted - (Rx/Tx) character count since the time when the monitoring is started. - Rx/Tx throughputs per second are also reported in interval basis (e.g. - the last 5 seconds) and in average basis (since the time the monitoring - is started). You can reset all ports' count by <HOME> key. <+> <-> - (plus/minus) keys to change the displaying time interval. Press <ENTER> - on the port, that cursor stay, to view the port's communication - parameters, signal status, and input/output queue. - - msterm - Terminal Emulation - --------------------------- - This utility provides data sending and receiving ability of all tty ports, - especially for MOXA ports. It is quite useful for testing simple - application, for example, sending AT command to a modem connected to the - port or used as a terminal for login purpose. Note that this is only a - dumb terminal emulation without handling full screen operation. - ------------------------------------------------------------------------------ -5. Setserial - - Supported Setserial parameters are listed as below. - - uart set UART type(16450-->disable FIFO, 16550A-->enable FIFO) - close_delay set the amount of time(in 1/100 of a second) that DTR - should be kept low while being closed. - closing_wait set the amount of time(in 1/100 of a second) that the - serial port should wait for data to be drained while - being closed, before the receiver is disable. - spd_hi Use 57.6kb when the application requests 38.4kb. - spd_vhi Use 115.2kb when the application requests 38.4kb. - spd_shi Use 230.4kb when the application requests 38.4kb. - spd_warp Use 460.8kb when the application requests 38.4kb. - spd_normal Use 38.4kb when the application requests 38.4kb. - spd_cust Use the custom divisor to set the speed when the - application requests 38.4kb. - divisor This option set the custom division. - baud_base This option set the base baud rate. - ------------------------------------------------------------------------------ -6. Troubleshooting - - The boot time error messages and solutions are stated as clearly as - possible. If all the possible solutions fail, please contact our technical - support team to get more help. - - - Error msg: More than 4 Moxa Smartio/Industio family boards found. Fifth board - and after are ignored. - Solution: - To avoid this problem, please unplug fifth and after board, because Moxa - driver supports up to 4 boards. - - Error msg: Request_irq fail, IRQ(?) may be conflict with another device. - Solution: - Other PCI or ISA devices occupy the assigned IRQ. If you are not sure - which device causes the situation, please check /proc/interrupts to find - free IRQ and simply change another free IRQ for Moxa board. - - Error msg: Board #: C1xx Series(CAP=xxx) interrupt number invalid. - Solution: - Each port within the same multiport board shares the same IRQ. Please set - one IRQ (IRQ doesn't equal to zero) for one Moxa board. - - Error msg: No interrupt vector be set for Moxa ISA board(CAP=xxx). - Solution: - Moxa ISA board needs an interrupt vector.Please refer to user's manual - "Hardware Installation" chapter to set interrupt vector. - - Error msg: Couldn't install MOXA Smartio/Industio family driver! - Solution: - Load Moxa driver fail, the major number may conflict with other devices. - Please refer to previous section 3.7 to change a free major number for - Moxa driver. - - Error msg: Couldn't install MOXA Smartio/Industio family callout driver! - Solution: - Load Moxa callout driver fail, the callout device major number may - conflict with other devices. Please refer to previous section 3.7 to - change a free callout device major number for Moxa driver. - - ------------------------------------------------------------------------------ - diff --git a/Documentation/serial/moxa-smartio.rst b/Documentation/serial/moxa-smartio.rst new file mode 100644 index 000000000000..156100f17c3f --- /dev/null +++ b/Documentation/serial/moxa-smartio.rst @@ -0,0 +1,615 @@ +============================================================= +MOXA Smartio/Industio Family Device Driver Installation Guide +============================================================= + +.. note:: + + This file is outdated. It needs some care in order to make it + updated to Kernel 5.0 and upper + +Copyright (C) 2008, Moxa Inc. + +Date: 01/21/2008 + +.. Content + + 1. Introduction + 2. System Requirement + 3. Installation + 3.1 Hardware installation + 3.2 Driver files + 3.3 Device naming convention + 3.4 Module driver configuration + 3.5 Static driver configuration for Linux kernel 2.4.x and 2.6.x. + 3.6 Custom configuration + 3.7 Verify driver installation + 4. Utilities + 5. Setserial + 6. Troubleshooting + +1. Introduction +^^^^^^^^^^^^^^^ + + The Smartio/Industio/UPCI family Linux driver supports following multiport + boards. + + - 2 ports multiport board + CP-102U, CP-102UL, CP-102UF + CP-132U-I, CP-132UL, + CP-132, CP-132I, CP132S, CP-132IS, + CI-132, CI-132I, CI-132IS, + (C102H, C102HI, C102HIS, C102P, CP-102, CP-102S) + + - 4 ports multiport board + CP-104EL, + CP-104UL, CP-104JU, + CP-134U, CP-134U-I, + C104H/PCI, C104HS/PCI, + CP-114, CP-114I, CP-114S, CP-114IS, CP-114UL, + C104H, C104HS, + CI-104J, CI-104JS, + CI-134, CI-134I, CI-134IS, + (C114HI, CT-114I, C104P), + POS-104UL, + CB-114, + CB-134I + + - 8 ports multiport board + CP-118EL, CP-168EL, + CP-118U, CP-168U, + C168H/PCI, + C168H, C168HS, + (C168P), + CB-108 + + This driver and installation procedure have been developed upon Linux Kernel + 2.4.x and 2.6.x. This driver supports Intel x86 hardware platform. In order + to maintain compatibility, this version has also been properly tested with + RedHat, Mandrake, Fedora and S.u.S.E Linux. However, if compatibility problem + occurs, please contact Moxa at support@moxa.com.tw. + + In addition to device driver, useful utilities are also provided in this + version. They are: + + - msdiag + Diagnostic program for displaying installed Moxa + Smartio/Industio boards. + - msmon + Monitor program to observe data count and line status signals. + - msterm A simple terminal program which is useful in testing serial + ports. + - io-irq.exe + Configuration program to setup ISA boards. Please note that + this program can only be executed under DOS. + + All the drivers and utilities are published in form of source code under + GNU General Public License in this version. Please refer to GNU General + Public License announcement in each source code file for more detail. + + In Moxa's Web sites, you may always find latest driver at http://www.moxa.com/. + + This version of driver can be installed as Loadable Module (Module driver) + or built-in into kernel (Static driver). You may refer to following + installation procedure for suitable one. Before you install the driver, + please refer to hardware installation procedure in the User's Manual. + + We assume the user should be familiar with following documents. + + - Serial-HOWTO + - Kernel-HOWTO + +2. System Requirement +^^^^^^^^^^^^^^^^^^^^^ + + - Hardware platform: Intel x86 machine + - Kernel version: 2.4.x or 2.6.x + - gcc version 2.72 or later + - Maximum 4 boards can be installed in combination + +3. Installation +^^^^^^^^^^^^^^^ + +3.1 Hardware installation +========================= + + There are two types of buses, ISA and PCI, for Smartio/Industio + family multiport board. + +ISA board +--------- + + You'll have to configure CAP address, I/O address, Interrupt Vector + as well as IRQ before installing this driver. Please refer to hardware + installation procedure in User's Manual before proceed any further. + Please make sure the JP1 is open after the ISA board is set properly. + +PCI/UPCI board +-------------- + + You may need to adjust IRQ usage in BIOS to avoid from IRQ conflict + with other ISA devices. Please refer to hardware installation + procedure in User's Manual in advance. + +PCI IRQ Sharing +--------------- + + Each port within the same multiport board shares the same IRQ. Up to + 4 Moxa Smartio/Industio PCI Family multiport boards can be installed + together on one system and they can share the same IRQ. + + +3.2 Driver files +================ + + The driver file may be obtained from ftp, CD-ROM or floppy disk. The + first step, anyway, is to copy driver file "mxser.tgz" into specified + directory. e.g. /moxa. The execute commands as below:: + + # cd / + # mkdir moxa + # cd /moxa + # tar xvf /dev/fd0 + +or:: + + # cd / + # mkdir moxa + # cd /moxa + # cp /mnt/cdrom/<driver directory>/mxser.tgz . + # tar xvfz mxser.tgz + + +3.3 Device naming convention +============================ + + You may find all the driver and utilities files in /moxa/mxser. + Following installation procedure depends on the model you'd like to + run the driver. If you prefer module driver, please refer to 3.4. + If static driver is required, please refer to 3.5. + +Dialin and callout port +----------------------- + + This driver remains traditional serial device properties. There are + two special file name for each serial port. One is dial-in port + which is named "ttyMxx". For callout port, the naming convention + is "cumxx". + +Device naming when more than 2 boards installed +----------------------------------------------- + + Naming convention for each Smartio/Industio multiport board is + pre-defined as below. + + ============ =============== ============== + Board Num. Dial-in Port Callout port + 1st board ttyM0 - ttyM7 cum0 - cum7 + 2nd board ttyM8 - ttyM15 cum8 - cum15 + 3rd board ttyM16 - ttyM23 cum16 - cum23 + 4th board ttyM24 - ttym31 cum24 - cum31 + ============ =============== ============== + +.. note:: + + Under Kernel 2.6 and upper, the cum Device is Obsolete. So use ttyM* + device instead. + +Board sequence +-------------- + + This driver will activate ISA boards according to the parameter set + in the driver. After all specified ISA board activated, PCI board + will be installed in the system automatically driven. + Therefore the board number is sorted by the CAP address of ISA boards. + For PCI boards, their sequence will be after ISA boards and C168H/PCI + has higher priority than C104H/PCI boards. + +3.4 Module driver configuration +=============================== + + Module driver is easiest way to install. If you prefer static driver + installation, please skip this paragraph. + + + ------------- Prepare to use the MOXA driver -------------------- + +3.4.1 Create tty device with correct major number +------------------------------------------------- + + Before using MOXA driver, your system must have the tty devices + which are created with driver's major number. We offer one shell + script "msmknod" to simplify the procedure. + This step is only needed to be executed once. But you still + need to do this procedure when: + + a. You change the driver's major number. Please refer the "3.7" + section. + b. Your total installed MOXA boards number is changed. Maybe you + add/delete one MOXA board. + c. You want to change the tty name. This needs to modify the + shell script "msmknod" + + The procedure is:: + + # cd /moxa/mxser/driver + # ./msmknod + + This shell script will require the major number for dial-in + device and callout device to create tty device. You also need + to specify the total installed MOXA board number. Default major + numbers for dial-in device and callout device are 30, 35. If + you need to change to other number, please refer section "3.7" + for more detailed procedure. + Msmknod will delete any special files occupying the same device + naming. + +3.4.2 Build the MOXA driver and utilities +----------------------------------------- + + Before using the MOXA driver and utilities, you need compile the + all the source code. This step is only need to be executed once. + But you still re-compile the source code if you modify the source + code. For example, if you change the driver's major number (see + "3.7" section), then you need to do this step again. + + Find "Makefile" in /moxa/mxser, then run + + # make clean; make install + + ..note:: + + For Red Hat 9, Red Hat Enterprise Linux AS3/ES3/WS3 & Fedora Core1: + # make clean; make installsp1 + + For Red Hat Enterprise Linux AS4/ES4/WS4: + # make clean; make installsp2 + + The driver files "mxser.o" and utilities will be properly compiled + and copied to system directories respectively. + +------------- Load MOXA driver-------------------- + +3.4.3 Load the MOXA driver +-------------------------- + + :: + + # modprobe mxser <argument> + + will activate the module driver. You may run "lsmod" to check + if "mxser" is activated. If the MOXA board is ISA board, the + <argument> is needed. Please refer to section "3.4.5" for more + information. + +------------- Load MOXA driver on boot -------------------- + +3.4.4 Load the mxser driver +--------------------------- + + + For the above description, you may manually execute + "modprobe mxser" to activate this driver and run + "rmmod mxser" to remove it. + + However, it's better to have a boot time configuration to + eliminate manual operation. Boot time configuration can be + achieved by rc file. We offer one "rc.mxser" file to simplify + the procedure under "moxa/mxser/driver". + + But if you use ISA board, please modify the "modprobe ..." command + to add the argument (see "3.4.5" section). After modifying the + rc.mxser, please try to execute "/moxa/mxser/driver/rc.mxser" + manually to make sure the modification is ok. If any error + encountered, please try to modify again. If the modification is + completed, follow the below step. + + Run following command for setting rc files:: + + # cd /moxa/mxser/driver + # cp ./rc.mxser /etc/rc.d + # cd /etc/rc.d + + Check "rc.serial" is existed or not. If "rc.serial" doesn't exist, + create it by vi, run "chmod 755 rc.serial" to change the permission. + + Add "/etc/rc.d/rc.mxser" in last line. + + Reboot and check if moxa.o activated by "lsmod" command. + +3.4.5. specify CAP address +-------------------------- + + If you'd like to drive Smartio/Industio ISA boards in the system, + you'll have to add parameter to specify CAP address of given + board while activating "mxser.o". The format for parameters are + as follows.:: + + modprobe mxser ioaddr=0x???,0x???,0x???,0x??? + | | | | + | | | +- 4th ISA board + | | +------ 3rd ISA board + | +------------ 2nd ISA board + +-------------------1st ISA board + +3.5 Static driver configuration for Linux kernel 2.4.x and 2.6.x +================================================================ + + Note: + To use static driver, you must install the linux kernel + source package. + +3.5.1 Backup the built-in driver in the kernel +---------------------------------------------- + + :: + + # cd /usr/src/linux/drivers/char + # mv mxser.c mxser.c.old + + For Red Hat 7.x user, you need to create link: + # cd /usr/src + # ln -s linux-2.4 linux + +3.5.2 Create link +----------------- + :: + + # cd /usr/src/linux/drivers/char + # ln -s /moxa/mxser/driver/mxser.c mxser.c + +3.5.3 Add CAP address list for ISA boards. +------------------------------------------ + + For PCI boards user, please skip this step. + + In module mode, the CAP address for ISA board is given by + parameter. In static driver configuration, you'll have to + assign it within driver's source code. If you will not + install any ISA boards, you may skip to next portion. + The instructions to modify driver source code are as + below. + + a. run:: + + # cd /moxa/mxser/driver + # vi mxser.c + + b. Find the array mxserBoardCAP[] as below:: + + static int mxserBoardCAP[] = {0x00, 0x00, 0x00, 0x00}; + + c. Change the address within this array using vi. For + example, to driver 2 ISA boards with CAP address + 0x280 and 0x180 as 1st and 2nd board. Just to change + the source code as follows:: + + static int mxserBoardCAP[] = {0x280, 0x180, 0x00, 0x00}; + +3.5.4 Setup kernel configuration +-------------------------------- + + Configure the kernel:: + + # cd /usr/src/linux + # make menuconfig + + You will go into a menu-driven system. Please select [Character + devices][Non-standard serial port support], enable the [Moxa + SmartIO support] driver with "[*]" for built-in (not "[M]"), then + select [Exit] to exit this program. + +3.5.5 Rebuild kernel +-------------------- + + The following are for Linux kernel rebuilding, for your + reference only. + + For appropriate details, please refer to the Linux document: + + a. Run the following commands:: + + cd /usr/src/linux + make clean # take a few minutes + make dep # take a few minutes + make bzImage # take probably 10-20 minutes + make install # copy boot image to correct position + + f. Please make sure the boot kernel (vmlinuz) is in the + correct position. + g. If you use 'lilo' utility, you should check /etc/lilo.conf + 'image' item specified the path which is the 'vmlinuz' path, + or you will load wrong (or old) boot kernel image (vmlinuz). + After checking /etc/lilo.conf, please run "lilo". + + Note that if the result of "make bzImage" is ERROR, then you have to + go back to Linux configuration Setup. Type "make menuconfig" in + directory /usr/src/linux. + + +3.5.6 Make tty device and special file +-------------------------------------- + + :: + # cd /moxa/mxser/driver + # ./msmknod + +3.5.7 Make utility +------------------ + + :: + + # cd /moxa/mxser/utility + # make clean; make install + +3.5.8 Reboot +------------ + + + +3.6 Custom configuration +======================== + + Although this driver already provides you default configuration, you + still can change the device name and major number. The instruction to + change these parameters are shown as below. + +a. Change Device name + + If you'd like to use other device names instead of default naming + convention, all you have to do is to modify the internal code + within the shell script "msmknod". First, you have to open "msmknod" + by vi. Locate each line contains "ttyM" and "cum" and change them + to the device name you desired. "msmknod" creates the device names + you need next time executed. + +b. Change Major number + + If major number 30 and 35 had been occupied, you may have to select + 2 free major numbers for this driver. There are 3 steps to change + major numbers. + +3.6.1 Find free major numbers +----------------------------- + + In /proc/devices, you may find all the major numbers occupied + in the system. Please select 2 major numbers that are available. + e.g. 40, 45. + +3.6.2 Create special files +-------------------------- + + Run /moxa/mxser/driver/msmknod to create special files with + specified major numbers. + +3.6.3 Modify driver with new major number +----------------------------------------- + + Run vi to open /moxa/mxser/driver/mxser.c. Locate the line + contains "MXSERMAJOR". Change the content as below:: + + #define MXSERMAJOR 40 + #define MXSERCUMAJOR 45 + + 3.6.4 Run "make clean; make install" in /moxa/mxser/driver. + +3.7 Verify driver installation +============================== + + You may refer to /var/log/messages to check the latest status + log reported by this driver whenever it's activated. + +4. Utilities +^^^^^^^^^^^^ + + There are 3 utilities contained in this driver. They are msdiag, msmon and + msterm. These 3 utilities are released in form of source code. They should + be compiled into executable file and copied into /usr/bin. + + Before using these utilities, please load driver (refer 3.4 & 3.5) and + make sure you had run the "msmknod" utility. + +msdiag - Diagnostic +=================== + + This utility provides the function to display what Moxa Smartio/Industio + board found by driver in the system. + +msmon - Port Monitoring +======================= + + This utility gives the user a quick view about all the MOXA ports' + activities. One can easily learn each port's total received/transmitted + (Rx/Tx) character count since the time when the monitoring is started. + + Rx/Tx throughputs per second are also reported in interval basis (e.g. + the last 5 seconds) and in average basis (since the time the monitoring + is started). You can reset all ports' count by <HOME> key. <+> <-> + (plus/minus) keys to change the displaying time interval. Press <ENTER> + on the port, that cursor stay, to view the port's communication + parameters, signal status, and input/output queue. + +msterm - Terminal Emulation +=========================== + + This utility provides data sending and receiving ability of all tty ports, + especially for MOXA ports. It is quite useful for testing simple + application, for example, sending AT command to a modem connected to the + port or used as a terminal for login purpose. Note that this is only a + dumb terminal emulation without handling full screen operation. + +5. Setserial +^^^^^^^^^^^^ + + Supported Setserial parameters are listed as below. + + ============== ========================================================= + uart set UART type(16450-->disable FIFO, 16550A-->enable FIFO) + close_delay set the amount of time(in 1/100 of a second) that DTR + should be kept low while being closed. + closing_wait set the amount of time(in 1/100 of a second) that the + serial port should wait for data to be drained while + being closed, before the receiver is disable. + spd_hi Use 57.6kb when the application requests 38.4kb. + spd_vhi Use 115.2kb when the application requests 38.4kb. + spd_shi Use 230.4kb when the application requests 38.4kb. + spd_warp Use 460.8kb when the application requests 38.4kb. + spd_normal Use 38.4kb when the application requests 38.4kb. + spd_cust Use the custom divisor to set the speed when the + application requests 38.4kb. + divisor This option set the custom division. + baud_base This option set the base baud rate. + ============== ========================================================= + +6. Troubleshooting +^^^^^^^^^^^^^^^^^^ + + The boot time error messages and solutions are stated as clearly as + possible. If all the possible solutions fail, please contact our technical + support team to get more help. + + + Error msg: + More than 4 Moxa Smartio/Industio family boards found. Fifth board + and after are ignored. + + Solution: + To avoid this problem, please unplug fifth and after board, because Moxa + driver supports up to 4 boards. + + Error msg: + Request_irq fail, IRQ(?) may be conflict with another device. + + Solution: + Other PCI or ISA devices occupy the assigned IRQ. If you are not sure + which device causes the situation, please check /proc/interrupts to find + free IRQ and simply change another free IRQ for Moxa board. + + Error msg: + Board #: C1xx Series(CAP=xxx) interrupt number invalid. + + Solution: + Each port within the same multiport board shares the same IRQ. Please set + one IRQ (IRQ doesn't equal to zero) for one Moxa board. + + Error msg: + No interrupt vector be set for Moxa ISA board(CAP=xxx). + + Solution: + Moxa ISA board needs an interrupt vector.Please refer to user's manual + "Hardware Installation" chapter to set interrupt vector. + + Error msg: + Couldn't install MOXA Smartio/Industio family driver! + + Solution: + Load Moxa driver fail, the major number may conflict with other devices. + Please refer to previous section 3.7 to change a free major number for + Moxa driver. + + Error msg: + Couldn't install MOXA Smartio/Industio family callout driver! + + Solution: + Load Moxa callout driver fail, the callout device major number may + conflict with other devices. Please refer to previous section 3.7 to + change a free callout device major number for Moxa driver. diff --git a/Documentation/serial/n_gsm.rst b/Documentation/serial/n_gsm.rst new file mode 100644 index 000000000000..f3ad9fd26408 --- /dev/null +++ b/Documentation/serial/n_gsm.rst @@ -0,0 +1,103 @@ +============================== +GSM 0710 tty multiplexor HOWTO +============================== + +This line discipline implements the GSM 07.10 multiplexing protocol +detailed in the following 3GPP document: + + http://www.3gpp.org/ftp/Specs/archive/07_series/07.10/0710-720.zip + +This document give some hints on how to use this driver with GPRS and 3G +modems connected to a physical serial port. + +How to use it +------------- +1. initialize the modem in 0710 mux mode (usually AT+CMUX= command) through + its serial port. Depending on the modem used, you can pass more or less + parameters to this command, +2. switch the serial line to using the n_gsm line discipline by using + TIOCSETD ioctl, +3. configure the mux using GSMIOC_GETCONF / GSMIOC_SETCONF ioctl, + +Major parts of the initialization program : +(a good starting point is util-linux-ng/sys-utils/ldattach.c):: + + #include <linux/gsmmux.h> + #define N_GSM0710 21 /* GSM 0710 Mux */ + #define DEFAULT_SPEED B115200 + #define SERIAL_PORT /dev/ttyS0 + + int ldisc = N_GSM0710; + struct gsm_config c; + struct termios configuration; + + /* open the serial port connected to the modem */ + fd = open(SERIAL_PORT, O_RDWR | O_NOCTTY | O_NDELAY); + + /* configure the serial port : speed, flow control ... */ + + /* send the AT commands to switch the modem to CMUX mode + and check that it's successful (should return OK) */ + write(fd, "AT+CMUX=0\r", 10); + + /* experience showed that some modems need some time before + being able to answer to the first MUX packet so a delay + may be needed here in some case */ + sleep(3); + + /* use n_gsm line discipline */ + ioctl(fd, TIOCSETD, &ldisc); + + /* get n_gsm configuration */ + ioctl(fd, GSMIOC_GETCONF, &c); + /* we are initiator and need encoding 0 (basic) */ + c.initiator = 1; + c.encapsulation = 0; + /* our modem defaults to a maximum size of 127 bytes */ + c.mru = 127; + c.mtu = 127; + /* set the new configuration */ + ioctl(fd, GSMIOC_SETCONF, &c); + + /* and wait for ever to keep the line discipline enabled */ + daemon(0,0); + pause(); + +4. create the devices corresponding to the "virtual" serial ports (take care, + each modem has its configuration and some DLC have dedicated functions, + for example GPS), starting with minor 1 (DLC0 is reserved for the management + of the mux):: + + MAJOR=`cat /proc/devices |grep gsmtty | awk '{print $1}` + for i in `seq 1 4`; do + mknod /dev/ttygsm$i c $MAJOR $i + done + +5. use these devices as plain serial ports. + + for example, it's possible: + + - and to use gnokii to send / receive SMS on ttygsm1 + - to use ppp to establish a datalink on ttygsm2 + +6. first close all virtual ports before closing the physical port. + + Note that after closing the physical port the modem is still in multiplexing + mode. This may prevent a successful re-opening of the port later. To avoid + this situation either reset the modem if your hardware allows that or send + a disconnect command frame manually before initializing the multiplexing mode + for the second time. The byte sequence for the disconnect command frame is:: + + 0xf9, 0x03, 0xef, 0x03, 0xc3, 0x16, 0xf9. + +Additional Documentation +------------------------ +More practical details on the protocol and how it's supported by industrial +modems can be found in the following documents : + +- http://www.telit.com/module/infopool/download.php?id=616 +- http://www.u-blox.com/images/downloads/Product_Docs/LEON-G100-G200-MuxImplementation_ApplicationNote_%28GSM%20G1-CS-10002%29.pdf +- http://www.sierrawireless.com/Support/Downloads/AirPrime/WMP_Series/~/media/Support_Downloads/AirPrime/Application_notes/CMUX_Feature_Application_Note-Rev004.ashx +- http://wm.sim.com/sim/News/photo/2010721161442.pdf + +11-03-08 - Eric Bénard - <eric@eukrea.com> diff --git a/Documentation/serial/n_gsm.txt b/Documentation/serial/n_gsm.txt deleted file mode 100644 index 875361bb7cb4..000000000000 --- a/Documentation/serial/n_gsm.txt +++ /dev/null @@ -1,96 +0,0 @@ -n_gsm.c GSM 0710 tty multiplexor HOWTO -=================================================== - -This line discipline implements the GSM 07.10 multiplexing protocol -detailed in the following 3GPP document : -http://www.3gpp.org/ftp/Specs/archive/07_series/07.10/0710-720.zip - -This document give some hints on how to use this driver with GPRS and 3G -modems connected to a physical serial port. - -How to use it -------------- -1- initialize the modem in 0710 mux mode (usually AT+CMUX= command) through -its serial port. Depending on the modem used, you can pass more or less -parameters to this command, -2- switch the serial line to using the n_gsm line discipline by using -TIOCSETD ioctl, -3- configure the mux using GSMIOC_GETCONF / GSMIOC_SETCONF ioctl, - -Major parts of the initialization program : -(a good starting point is util-linux-ng/sys-utils/ldattach.c) -#include <linux/gsmmux.h> -#define N_GSM0710 21 /* GSM 0710 Mux */ -#define DEFAULT_SPEED B115200 -#define SERIAL_PORT /dev/ttyS0 - - int ldisc = N_GSM0710; - struct gsm_config c; - struct termios configuration; - - /* open the serial port connected to the modem */ - fd = open(SERIAL_PORT, O_RDWR | O_NOCTTY | O_NDELAY); - - /* configure the serial port : speed, flow control ... */ - - /* send the AT commands to switch the modem to CMUX mode - and check that it's successful (should return OK) */ - write(fd, "AT+CMUX=0\r", 10); - - /* experience showed that some modems need some time before - being able to answer to the first MUX packet so a delay - may be needed here in some case */ - sleep(3); - - /* use n_gsm line discipline */ - ioctl(fd, TIOCSETD, &ldisc); - - /* get n_gsm configuration */ - ioctl(fd, GSMIOC_GETCONF, &c); - /* we are initiator and need encoding 0 (basic) */ - c.initiator = 1; - c.encapsulation = 0; - /* our modem defaults to a maximum size of 127 bytes */ - c.mru = 127; - c.mtu = 127; - /* set the new configuration */ - ioctl(fd, GSMIOC_SETCONF, &c); - - /* and wait for ever to keep the line discipline enabled */ - daemon(0,0); - pause(); - -4- create the devices corresponding to the "virtual" serial ports (take care, -each modem has its configuration and some DLC have dedicated functions, -for example GPS), starting with minor 1 (DLC0 is reserved for the management -of the mux) - -MAJOR=`cat /proc/devices |grep gsmtty | awk '{print $1}` -for i in `seq 1 4`; do - mknod /dev/ttygsm$i c $MAJOR $i -done - -5- use these devices as plain serial ports. -for example, it's possible : -- and to use gnokii to send / receive SMS on ttygsm1 -- to use ppp to establish a datalink on ttygsm2 - -6- first close all virtual ports before closing the physical port. - -Note that after closing the physical port the modem is still in multiplexing -mode. This may prevent a successful re-opening of the port later. To avoid -this situation either reset the modem if your hardware allows that or send -a disconnect command frame manually before initializing the multiplexing mode -for the second time. The byte sequence for the disconnect command frame is: -0xf9, 0x03, 0xef, 0x03, 0xc3, 0x16, 0xf9. - -Additional Documentation ------------------------- -More practical details on the protocol and how it's supported by industrial -modems can be found in the following documents : -http://www.telit.com/module/infopool/download.php?id=616 -http://www.u-blox.com/images/downloads/Product_Docs/LEON-G100-G200-MuxImplementation_ApplicationNote_%28GSM%20G1-CS-10002%29.pdf -http://www.sierrawireless.com/Support/Downloads/AirPrime/WMP_Series/~/media/Support_Downloads/AirPrime/Application_notes/CMUX_Feature_Application_Note-Rev004.ashx -http://wm.sim.com/sim/News/photo/2010721161442.pdf - -11-03-08 - Eric Bénard - <eric@eukrea.com> diff --git a/Documentation/serial/rocket.txt b/Documentation/serial/rocket.rst index 60b039891057..23761eae4282 100644 --- a/Documentation/serial/rocket.txt +++ b/Documentation/serial/rocket.rst @@ -1,20 +1,22 @@ -Comtrol(tm) RocketPort(R)/RocketModem(TM) Series -Device Driver for the Linux Operating System +================================================ +Comtrol(tm) RocketPort(R)/RocketModem(TM) Series +================================================ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- +Device Driver for the Linux Operating System +============================================ -PRODUCT OVERVIEW +Product overview ---------------- This driver provides a loadable kernel driver for the Comtrol RocketPort -and RocketModem PCI boards. These boards provide, 2, 4, 8, 16, or 32 +and RocketModem PCI boards. These boards provide, 2, 4, 8, 16, or 32 high-speed serial ports or modems. This driver supports up to a combination of four RocketPort or RocketModems boards in one machine simultaneously. This file assumes that you are using the RocketPort driver which is -integrated into the kernel sources. +integrated into the kernel sources. -The driver can also be installed as an external module using the usual -"make;make install" routine. This external module driver, obtainable +The driver can also be installed as an external module using the usual +"make;make install" routine. This external module driver, obtainable from the Comtrol website listed below, is useful for updating the driver or installing it into kernels which do not have the driver configured into them. Installations instructions for the external module @@ -29,57 +31,59 @@ information on how to set the DIP switches. You pass the I/O port to the driver using the following module parameters: -board1 : I/O port for the first ISA board -board2 : I/O port for the second ISA board -board3 : I/O port for the third ISA board -board4 : I/O port for the fourth ISA board +board1: + I/O port for the first ISA board +board2: + I/O port for the second ISA board +board3: + I/O port for the third ISA board +board4: + I/O port for the fourth ISA board There is a set of utilities and scripts provided with the external driver -( downloadable from http://www.comtrol.com ) that ease the configuration and +(downloadable from http://www.comtrol.com) that ease the configuration and setup of the ISA cards. The RocketModem II PCI boards require firmware to be loaded into the card before it will function. The driver has only been tested as a module for this board. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - -INSTALLATION PROCEDURES +Installation Procedures ----------------------- -RocketPort/RocketModem PCI cards require no driver configuration, they are +RocketPort/RocketModem PCI cards require no driver configuration, they are automatically detected and configured. -The RocketPort driver can be installed as a module (recommended) or built +The RocketPort driver can be installed as a module (recommended) or built into the kernel. This is selected, as for other drivers, through the `make config` -command from the root of the Linux source tree during the kernel build process. +command from the root of the Linux source tree during the kernel build process. The RocketPort/RocketModem serial ports installed by this driver are assigned -device major number 46, and will be named /dev/ttyRx, where x is the port number +device major number 46, and will be named /dev/ttyRx, where x is the port number starting at zero (ex. /dev/ttyR0, /devttyR1, ...). If you have multiple cards installed in the system, the mapping of port names to serial ports is displayed in the system log at /var/log/messages. If installed as a module, the module must be loaded. This can be done manually by entering "modprobe rocket". To have the module loaded automatically -upon system boot, edit a /etc/modprobe.d/*.conf file and add the line +upon system boot, edit a `/etc/modprobe.d/*.conf` file and add the line "alias char-major-46 rocket". In order to use the ports, their device names (nodes) must be created with mknod. -This is only required once, the system will retain the names once created. To -create the RocketPort/RocketModem device names, use the command -"mknod /dev/ttyRx c 46 x" where x is the port number starting at zero. For example: +This is only required once, the system will retain the names once created. To +create the RocketPort/RocketModem device names, use the command +"mknod /dev/ttyRx c 46 x" where x is the port number starting at zero. ->mknod /dev/ttyR0 c 46 0 ->mknod /dev/ttyR1 c 46 1 ->mknod /dev/ttyR2 c 46 2 +For example:: -The Linux script MAKEDEV will create the first 16 ttyRx device names (nodes) -for you: + > mknod /dev/ttyR0 c 46 0 + > mknod /dev/ttyR1 c 46 1 + > mknod /dev/ttyR2 c 46 2 ->/dev/MAKEDEV ttyR +The Linux script MAKEDEV will create the first 16 ttyRx device names (nodes) +for you:: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- + >/dev/MAKEDEV ttyR ISA Rocketport Boards --------------------- @@ -89,7 +93,7 @@ card before installing and using it. This is done by setting a set of DIP switches on the Rocketport board. -SETTING THE I/O ADDRESS +Setting the I/O address ----------------------- Before installing RocketPort(R) or RocketPort RA boards, you must find @@ -130,40 +134,36 @@ the first 4 bytes of that range are used by the first board. You would need to set the second, third, or fourth board to one of the next available blocks such as 0x180. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - -RocketPort and RocketPort RA SW1 Settings: - - +-------------------------------+ - | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | - +-------+-------+---------------+ - | Unused| Card | I/O Port Block| - +-------------------------------+ - -DIP Switches DIP Switches -7 8 6 5 -=================== =================== -On On UNUSED, MUST BE ON. On On First Card <==== Default - On Off Second Card - Off On Third Card - Off Off Fourth Card - -DIP Switches I/O Address Range -4 3 2 1 Used by the First Card -===================================== -On Off On Off 100-143 -On Off Off On 140-183 -On Off Off Off 180-1C3 <==== Default -Off On On Off 200-243 -Off On Off On 240-283 -Off On Off Off 280-2C3 -Off Off On Off 300-343 -Off Off Off On 340-383 -Off Off Off Off 380-3C3 - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - -REPORTING BUGS +RocketPort and RocketPort RA SW1 Settings:: + + +-------------------------------+ + | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | + +-------+-------+---------------+ + | Unused| Card | I/O Port Block| + +-------------------------------+ + + DIP Switches DIP Switches + 7 8 6 5 + =================== =================== + On On UNUSED, MUST BE ON. On On First Card <==== Default + On Off Second Card + Off On Third Card + Off Off Fourth Card + + DIP Switches I/O Address Range + 4 3 2 1 Used by the First Card + ===================================== + On Off On Off 100-143 + On Off Off On 140-183 + On Off Off Off 180-1C3 <==== Default + Off On On Off 200-243 + Off On Off On 240-283 + Off On Off Off 280-2C3 + Off Off On Off 300-343 + Off Off Off On 340-383 + Off Off Off Off 380-3C3 + +Reporting Bugs -------------- For technical support, please provide the following @@ -171,19 +171,15 @@ information: Driver version, kernel release, distribution of kernel, and type of board you are using. Error messages and log printouts port configuration details are especially helpful. -USA - Phone: (612) 494-4100 - FAX: (612) 494-4199 - email: support@comtrol.com +USA: + :Phone: (612) 494-4100 + :FAX: (612) 494-4199 + :email: support@comtrol.com -Comtrol Europe - Phone: +44 (0) 1 869 323-220 - FAX: +44 (0) 1 869 323-211 - email: support@comtrol.co.uk +Comtrol Europe: + :Phone: +44 (0) 1 869 323-220 + :FAX: +44 (0) 1 869 323-211 + :email: support@comtrol.co.uk Web: http://www.comtrol.com FTP: ftp.comtrol.com - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - diff --git a/Documentation/serial/serial-iso7816.txt b/Documentation/serial/serial-iso7816.rst index 3193d24a2b0f..d990143de0c6 100644 --- a/Documentation/serial/serial-iso7816.txt +++ b/Documentation/serial/serial-iso7816.rst @@ -1,11 +1,15 @@ - ISO7816 SERIAL COMMUNICATIONS +============================= +ISO7816 Serial Communications +============================= -1. INTRODUCTION +1. Introduction +=============== ISO/IEC7816 is a series of standards specifying integrated circuit cards (ICC) also known as smart cards. -2. HARDWARE-RELATED CONSIDERATIONS +2. Hardware-related considerations +================================== Some CPUs/UARTs (e.g., Microchip AT91) contain a built-in mode capable of handling communication with a smart card. @@ -15,7 +19,8 @@ available at user-level to allow switching from one mode to the other, and vice versa. -3. DATA STRUCTURES ALREADY AVAILABLE IN THE KERNEL +3. Data Structures Already Available in the Kernel +================================================== The Linux kernel provides the serial_iso7816 structure (see [1]) to handle ISO7816 communications. This data structure is used to set and configure @@ -27,10 +32,11 @@ to TIOCGISO7816 and TIOCSISO7816 ioctls (see below). The iso7816_config callback receives a pointer to struct serial_iso7816. -4. USAGE FROM USER-LEVEL +4. Usage from user-level +======================== From user-level, ISO7816 configuration can be get/set using the previous - ioctls. For instance, to set ISO7816 you can use the following code: + ioctls. For instance, to set ISO7816 you can use the following code:: #include <linux/serial.h> @@ -78,6 +84,7 @@ /* Error handling. See errno. */ } -5. REFERENCES +5. References +============= [1] include/uapi/linux/serial.h diff --git a/Documentation/serial/serial-rs485.txt b/Documentation/serial/serial-rs485.rst index ce0c1a9b8aab..6bc824f948f9 100644 --- a/Documentation/serial/serial-rs485.txt +++ b/Documentation/serial/serial-rs485.rst @@ -1,6 +1,9 @@ - RS485 SERIAL COMMUNICATIONS +=========================== +RS485 Serial Communications +=========================== -1. INTRODUCTION +1. Introduction +=============== EIA-485, also known as TIA/EIA-485 or RS-485, is a standard defining the electrical characteristics of drivers and receivers for use in balanced @@ -9,7 +12,8 @@ because it can be used effectively over long distances and in electrically noisy environments. -2. HARDWARE-RELATED CONSIDERATIONS +2. Hardware-related Considerations +================================== Some CPUs/UARTs (e.g., Atmel AT91 or 16C950 UART) contain a built-in half-duplex mode capable of automatically controlling line direction by @@ -22,7 +26,8 @@ available at user-level to allow switching from one mode to the other, and vice versa. -3. DATA STRUCTURES ALREADY AVAILABLE IN THE KERNEL +3. Data Structures Already Available in the Kernel +================================================== The Linux kernel provides the serial_rs485 structure (see [1]) to handle RS485 communications. This data structure is used to set and configure RS485 @@ -38,10 +43,11 @@ to TIOCSRS485 and TIOCGRS485 ioctls (see below). The rs485_config callback receives a pointer to struct serial_rs485. -4. USAGE FROM USER-LEVEL +4. Usage from user-level +======================== From user-level, RS485 configuration can be get/set using the previous - ioctls. For instance, to set RS485 you can use the following code: + ioctls. For instance, to set RS485 you can use the following code:: #include <linux/serial.h> @@ -89,7 +95,9 @@ /* Error handling. See errno. */ } -5. REFERENCES +5. References +============= [1] include/uapi/linux/serial.h + [2] Documentation/devicetree/bindings/serial/rs485.txt diff --git a/Documentation/serial/tty.txt b/Documentation/serial/tty.rst index b48780977a68..dd972caacf3e 100644 --- a/Documentation/serial/tty.txt +++ b/Documentation/serial/tty.rst @@ -1,5 +1,6 @@ - - The Lockronomicon +================= +The Lockronomicon +================= Your guide to the ancient and twisted locking policies of the tty layer and the warped logic behind them. Beware all ye who read on. @@ -9,12 +10,12 @@ Line Discipline --------------- Line disciplines are registered with tty_register_ldisc() passing the -discipline number and the ldisc structure. At the point of registration the +discipline number and the ldisc structure. At the point of registration the discipline must be ready to use and it is possible it will get used before the call returns success. If the call returns an error then it won't get called. Do not re-use ldisc numbers as they are part of the userspace ABI and writing over an existing ldisc will cause demons to eat your computer. -After the return the ldisc data has been copied so you may free your own +After the return the ldisc data has been copied so you may free your own copy of the structure. You must not re-register over the top of the line discipline even with the same data or your computer again will be eaten by demons. @@ -26,7 +27,7 @@ code manages the module counts this should not usually be a concern. Heed this warning: the reference count field of the registered copies of the tty_ldisc structure in the ldisc table counts the number of lines using this -discipline. The reference count of the tty_ldisc structure within a tty +discipline. The reference count of the tty_ldisc structure within a tty counts the number of active users of the ldisc at this instant. In effect it counts the number of threads of execution within an ldisc method (plus those about to enter and exit although this detail matters not). @@ -34,9 +35,11 @@ about to enter and exit although this detail matters not). Line Discipline Methods ----------------------- -TTY side interfaces: +TTY side interfaces +^^^^^^^^^^^^^^^^^^^ -open() - Called when the line discipline is attached to +======================= ======================================================= +open() Called when the line discipline is attached to the terminal. No other call into the line discipline for this tty will occur until it completes successfully. Should initialize any @@ -47,66 +50,69 @@ open() - Called when the line discipline is attached to Returning an error will prevent the ldisc from being attached. Can sleep. -close() - This is called on a terminal when the line +close() This is called on a terminal when the line discipline is being unplugged. At the point of execution no further users will enter the ldisc code for this tty. Can sleep. -hangup() - Called when the tty line is hung up. +hangup() Called when the tty line is hung up. The line discipline should cease I/O to the tty. No further calls into the ldisc code will occur. The return value is ignored. Can sleep. -read() - (optional) A process requests reading data from +read() (optional) A process requests reading data from the line. Multiple read calls may occur in parallel and the ldisc must deal with serialization issues. If not defined, the process will receive an EIO error. May sleep. -write() - (optional) A process requests writing data to the +write() (optional) A process requests writing data to the line. Multiple write calls are serialized by the tty layer for the ldisc. If not defined, the process will receive an EIO error. May sleep. -flush_buffer() - (optional) May be called at any point between +flush_buffer() (optional) May be called at any point between open and close, and instructs the line discipline to empty its input buffer. -set_termios() - (optional) Called on termios structure changes. +set_termios() (optional) Called on termios structure changes. The caller passes the old termios data and the current data is in the tty. Called under the termios semaphore so allowed to sleep. Serialized against itself only. -poll() - (optional) Check the status for the poll/select +poll() (optional) Check the status for the poll/select calls. Multiple poll calls may occur in parallel. May sleep. -ioctl() - (optional) Called when an ioctl is handed to the +ioctl() (optional) Called when an ioctl is handed to the tty layer that might be for the ldisc. Multiple ioctl calls may occur in parallel. May sleep. -compat_ioctl() - (optional) Called when a 32 bit ioctl is handed +compat_ioctl() (optional) Called when a 32 bit ioctl is handed to the tty layer that might be for the ldisc. Multiple ioctl calls may occur in parallel. May sleep. +======================= ======================================================= -Driver Side Interfaces: +Driver Side Interfaces +^^^^^^^^^^^^^^^^^^^^^^ -receive_buf() - (optional) Called by the low-level driver to hand +======================= ======================================================= +receive_buf() (optional) Called by the low-level driver to hand a buffer of received bytes to the ldisc for processing. The number of bytes is guaranteed not to exceed the current value of tty->receive_room. All bytes must be processed. -receive_buf2() - (optional) Called by the low-level driver to hand +receive_buf2() (optional) Called by the low-level driver to hand a buffer of received bytes to the ldisc for processing. Returns the number of bytes processed. If both receive_buf() and receive_buf2() are defined, receive_buf2() should be preferred. -write_wakeup() - May be called at any point between open and close. +write_wakeup() May be called at any point between open and close. The TTY_DO_WRITE_WAKEUP flag indicates if a call is needed but always races versus calls. Thus the ldisc must be careful about setting order and to @@ -117,17 +123,20 @@ write_wakeup() - May be called at any point between open and close. is permitted to call the driver write method from this function. In such a situation defer it. -dcd_change() - Report to the tty line the current DCD pin status +dcd_change() Report to the tty line the current DCD pin status changes and the relative timestamp. The timestamp cannot be NULL. +======================= ======================================================= Driver Access +^^^^^^^^^^^^^ Line discipline methods can call the following methods of the underlying hardware driver through the function pointers within the tty->driver structure: +======================= ======================================================= write() Write a block of characters to the tty device. Returns the number of characters accepted. The character buffer passed to this method is already @@ -189,13 +198,16 @@ wait_until_sent() Waits until the device has written out all of the characters in its transmitter FIFO. send_xchar() Send a high-priority XON/XOFF character to the device. +======================= ======================================================= Flags +^^^^^ Line discipline methods have access to tty->flags field containing the following interesting flags: +======================= ======================================================= TTY_THROTTLED Driver input is throttled. The ldisc should call tty->driver->unthrottle() in order to resume reception when it is ready to process more data. @@ -212,102 +224,105 @@ TTY_OTHER_CLOSED Device is a pty and the other side has closed. TTY_NO_WRITE_SPLIT Prevent driver from splitting up writes into smaller chunks. +======================= ======================================================= Locking +^^^^^^^ Callers to the line discipline functions from the tty layer are required to take line discipline locks. The same is true of calls from the driver side but not yet enforced. -Three calls are now provided +Three calls are now provided:: ldisc = tty_ldisc_ref(tty); takes a handle to the line discipline in the tty and returns it. If no ldisc is currently attached or the ldisc is being closed and re-opened at this point then NULL is returned. While this handle is held the ldisc will not -change or go away. +change or go away:: tty_ldisc_deref(ldisc) Returns the ldisc reference and allows the ldisc to be closed. Returning the reference takes away your right to call the ldisc functions until you take -a new reference. +a new reference:: ldisc = tty_ldisc_ref_wait(tty); Performs the same function as tty_ldisc_ref except that it will wait for an -ldisc change to complete and then return a reference to the new ldisc. +ldisc change to complete and then return a reference to the new ldisc. While these functions are slightly slower than the old code they should have minimal impact as most receive logic uses the flip buffers and they only need to take a reference when they push bits up through the driver. -A caution: The ldisc->open(), ldisc->close() and driver->set_ldisc +A caution: The ldisc->open(), ldisc->close() and driver->set_ldisc functions are called with the ldisc unavailable. Thus tty_ldisc_ref will fail in this situation if used within these functions. Ldisc and driver -code calling its own functions must be careful in this case. +code calling its own functions must be careful in this case. Driver Interface ---------------- -open() - Called when a device is opened. May sleep +======================= ======================================================= +open() Called when a device is opened. May sleep -close() - Called when a device is closed. At the point of - return from this call the driver must make no +close() Called when a device is closed. At the point of + return from this call the driver must make no further ldisc calls of any kind. May sleep -write() - Called to write bytes to the device. May not - sleep. May occur in parallel in special cases. +write() Called to write bytes to the device. May not + sleep. May occur in parallel in special cases. Because this includes panic paths drivers generally shouldn't try and do clever locking here. -put_char() - Stuff a single character onto the queue. The +put_char() Stuff a single character onto the queue. The driver is guaranteed following up calls to flush_chars. -flush_chars() - Ask the kernel to write put_char queue +flush_chars() Ask the kernel to write put_char queue -write_room() - Return the number of characters that can be stuffed +write_room() Return the number of characters that can be stuffed into the port buffers without overflow (or less). The ldisc is responsible for being intelligent - about multi-threading of write_room/write calls + about multi-threading of write_room/write calls -ioctl() - Called when an ioctl may be for the driver +ioctl() Called when an ioctl may be for the driver -set_termios() - Called on termios change, serialized against +set_termios() Called on termios change, serialized against itself by a semaphore. May sleep. -set_ldisc() - Notifier for discipline change. At the point this +set_ldisc() Notifier for discipline change. At the point this is done the discipline is not yet usable. Can now sleep (I think) -throttle() - Called by the ldisc to ask the driver to do flow +throttle() Called by the ldisc to ask the driver to do flow control. Serialization including with unthrottle is the job of the ldisc layer. -unthrottle() - Called by the ldisc to ask the driver to stop flow +unthrottle() Called by the ldisc to ask the driver to stop flow control. -stop() - Ldisc notifier to the driver to stop output. As with +stop() Ldisc notifier to the driver to stop output. As with throttle the serializations with start() are down to the ldisc layer. -start() - Ldisc notifier to the driver to start output. +start() Ldisc notifier to the driver to start output. -hangup() - Ask the tty driver to cause a hangup initiated +hangup() Ask the tty driver to cause a hangup initiated from the host side. [Can sleep ??] -break_ctl() - Send RS232 break. Can sleep. Can get called in +break_ctl() Send RS232 break. Can sleep. Can get called in parallel, driver must serialize (for now), and with write calls. -wait_until_sent() - Wait for characters to exit the hardware queue +wait_until_sent() Wait for characters to exit the hardware queue of the driver. Can sleep -send_xchar() - Send XON/XOFF and if possible jump the queue with +send_xchar() Send XON/XOFF and if possible jump the queue with it in order to get fast flow control responses. Cannot sleep ?? - +======================= ======================================================= diff --git a/Documentation/usb/WUSB-Design-overview.txt b/Documentation/usb/WUSB-Design-overview.txt index fdb47637720e..dc5e21609bb5 100644 --- a/Documentation/usb/WUSB-Design-overview.txt +++ b/Documentation/usb/WUSB-Design-overview.txt @@ -1,7 +1,9 @@ - +================================ Linux UWB + Wireless USB + WiNET +================================ + + Copyright (C) 2005-2006 Intel Corporation - (C) 2005-2006 Intel Corporation Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com> This program is free software; you can redistribute it and/or @@ -29,6 +31,7 @@ drivers for the USB based UWB radio controllers defined in the Wireless USB 1.0 specification (including Wireless USB host controller and an Intel WiNET controller). +.. Contents 1. Introduction 1. HWA: Host Wire adapters, your Wireless USB dongle @@ -51,7 +54,8 @@ and an Intel WiNET controller). 4. Glossary - Introduction +Introduction +============ UWB is a wide-band communication protocol that is to serve also as the low-level protocol for others (much like TCP sits on IP). Currently @@ -93,7 +97,8 @@ The different logical parts of this driver are: do the actual WUSB. - HWA: Host Wire adapters, your Wireless USB dongle +HWA: Host Wire adapters, your Wireless USB dongle +------------------------------------------------- WUSB also defines a device called a Host Wire Adaptor (HWA), which in mere terms is a USB dongle that enables your PC to have UWB and Wireless @@ -125,7 +130,8 @@ The HWA itself is broken in two or three main interfaces: their type and kick into gear. - DWA: Device Wired Adaptor, a Wireless USB hub for wired devices +DWA: Device Wired Adaptor, a Wireless USB hub for wired devices +--------------------------------------------------------------- These are the complement to HWAs. They are a USB host for connecting wired devices, but it is connected to your PC connected via Wireless @@ -137,7 +143,8 @@ code with the HWA-RC driver; there is a bunch of factorization work that has been done to support that in upcoming releases. - WHCI: Wireless Host Controller Interface, the PCI WUSB host adapter +WHCI: Wireless Host Controller Interface, the PCI WUSB host adapter +------------------------------------------------------------------- This is your usual PCI device that implements WHCI. Similar in concept to EHCI, it allows your wireless USB devices (including DWAs) to connect @@ -148,7 +155,8 @@ There is still no driver support for this, but will be in upcoming releases. - The UWB stack +The UWB stack +============= The main mission of the UWB stack is to keep a tally of which devices are in radio proximity to allow drivers to connect to them. As well, it @@ -156,7 +164,8 @@ provides an API for controlling the local radio controllers (RCs from now on), such as to start/stop beaconing, scan, allocate bandwidth, etc. - Devices and hosts: the basic structure +Devices and hosts: the basic structure +-------------------------------------- The main building block here is the UWB device (struct uwb_dev). For each device that pops up in radio presence (ie: the UWB host receives a @@ -187,7 +196,8 @@ the USB connected HWA. Eventually, drivers/whci-rc.c will do the same for the PCI connected WHCI controller. - Host Controller life cycle +Host Controller life cycle +-------------------------- So let's say we connect a dongle to the system: it is detected and firmware uploaded if needed [for Intel's i1480 @@ -209,7 +219,8 @@ When a dongle is disconnected, /drivers/uwb/hwa-rc.c:hwarc_disconnect()/ takes time of tearing everything down safely (or not...). - On the air: beacons and enumerating the radio neighborhood +On the air: beacons and enumerating the radio neighborhood +---------------------------------------------------------- So assuming we have devices and we have agreed for a channel to connect on (let's say 9), we put the new RC to beacon: @@ -235,12 +246,14 @@ are received in some time, the device is considered gone and wiped out the beacon cache of dead devices]. - Device lists +Device lists +------------ All UWB devices are kept in the list of the struct bus_type uwb_bus_type. - Bandwidth allocation +Bandwidth allocation +-------------------- The UWB stack maintains a local copy of DRP availability through processing of incoming *DRP Availability Change* notifications. This @@ -260,7 +273,8 @@ completion. [Note: The bandwidth reservation work is in progress and subject to change.] - Wireless USB Host Controller drivers +Wireless USB Host Controller drivers +==================================== *WARNING* This section needs a lot of work! @@ -296,7 +310,8 @@ starts sending MMCs. Now it all depends on external stimuli. -*New device connection* +New device connection +--------------------- A new device pops up, it scans the radio looking for MMCs that give out the existence of Wireless USB channels. Once one (or more) are found, @@ -322,7 +337,8 @@ has seen the port status changes, as we have been toggling them. It will start enumerating and doing transfers through usb_hcd->urb_enqueue() to read descriptors and move our data. -*Device life cycle and keep alives* +Device life cycle and keep alives +--------------------------------- Every time there is a successful transfer to/from a device, we update a per-device activity timestamp. If not, every now and then we check and @@ -340,7 +356,8 @@ device list looking for whom needs refreshing. If the device wants to disconnect, it will either die (ugly) or send a /DN_Disconnect/ that will prompt a disconnection from the system. -*Sending and receiving data* +Sending and receiving data +-------------------------- Data is sent and received through /Remote Pipes/ (rpipes). An rpipe is /aimed/ at an endpoint in a WUSB device. This is the same for HWAs and @@ -394,7 +411,8 @@ finalize the transfer. For IN xfers, we only issue URBs for the segments we want to read and then wait for the xfer result data. -*URB mapping into xfers* +URB mapping into xfers +^^^^^^^^^^^^^^^^^^^^^^ This is done by hwahc_op_urb_[en|de]queue(). In enqueue() we aim an rpipe to the endpoint where we have to transmit, create a transfer @@ -407,7 +425,8 @@ and not yet done and when all that is done, the xfer callback will be called--this will call the URB callback. - Glossary +Glossary +======== *DWA* -- Device Wire Adapter @@ -436,4 +455,3 @@ the host. Design-overview.txt-1.8 (last edited 2006-11-04 12:22:24 by InakyPerezGonzalez) - diff --git a/Documentation/usb/acm.txt b/Documentation/usb/acm.txt index 903abca10517..e8bda98e9b51 100644 --- a/Documentation/usb/acm.txt +++ b/Documentation/usb/acm.txt @@ -1,127 +1,131 @@ - Linux ACM driver v0.16 - (c) 1999 Vojtech Pavlik <vojtech@suse.cz> - Sponsored by SuSE ----------------------------------------------------------------------------- +====================== +Linux ACM driver v0.16 +====================== + +Copyright (c) 1999 Vojtech Pavlik <vojtech@suse.cz> + +Sponsored by SuSE 0. Disclaimer ~~~~~~~~~~~~~ - This program is free software; you can redistribute it and/or modify it +This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. - This program is distributed in the hope that it will be useful, but +This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. - You should have received a copy of the GNU General Public License along +You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA - Should you need to contact me, the author, you can do so either by e-mail -- mail your message to <vojtech@suse.cz>, or by paper mail: Vojtech Pavlik, +Should you need to contact me, the author, you can do so either by e-mail - +mail your message to <vojtech@suse.cz>, or by paper mail: Vojtech Pavlik, Ucitelska 1576, Prague 8, 182 00 Czech Republic - For your convenience, the GNU General Public License version 2 is included +For your convenience, the GNU General Public License version 2 is included in the package: See the file COPYING. 1. Usage ~~~~~~~~ - The drivers/usb/class/cdc-acm.c drivers works with USB modems and USB ISDN terminal +The drivers/usb/class/cdc-acm.c drivers works with USB modems and USB ISDN terminal adapters that conform to the Universal Serial Bus Communication Device Class Abstract Control Model (USB CDC ACM) specification. - Many modems do, here is a list of those I know of: +Many modems do, here is a list of those I know of: - 3Com OfficeConnect 56k - 3Com Voice FaxModem Pro - 3Com Sportster - MultiTech MultiModem 56k - Zoom 2986L FaxModem - Compaq 56k FaxModem - ELSA Microlink 56k + - 3Com OfficeConnect 56k + - 3Com Voice FaxModem Pro + - 3Com Sportster + - MultiTech MultiModem 56k + - Zoom 2986L FaxModem + - Compaq 56k FaxModem + - ELSA Microlink 56k - I know of one ISDN TA that does work with the acm driver: +I know of one ISDN TA that does work with the acm driver: - 3Com USR ISDN Pro TA + - 3Com USR ISDN Pro TA - Some cell phones also connect via USB. I know the following phones work: +Some cell phones also connect via USB. I know the following phones work: - SonyEricsson K800i + - SonyEricsson K800i - Unfortunately many modems and most ISDN TAs use proprietary interfaces and +Unfortunately many modems and most ISDN TAs use proprietary interfaces and thus won't work with this drivers. Check for ACM compliance before buying. - To use the modems you need these modules loaded: +To use the modems you need these modules loaded:: usbcore.ko uhci-hcd.ko ohci-hcd.ko or ehci-hcd.ko cdc-acm.ko - After that, the modem[s] should be accessible. You should be able to use +After that, the modem[s] should be accessible. You should be able to use minicom, ppp and mgetty with them. 2. Verifying that it works ~~~~~~~~~~~~~~~~~~~~~~~~~~ - The first step would be to check /sys/kernel/debug/usb/devices, it should look -like this: - -T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 -B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0 -D: Ver= 1.00 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 -P: Vendor=0000 ProdID=0000 Rev= 0.00 -S: Product=USB UHCI Root Hub -S: SerialNumber=6800 -C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA -I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub -E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=255ms -T: Bus=01 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 -D: Ver= 1.00 Cls=02(comm.) Sub=00 Prot=00 MxPS= 8 #Cfgs= 2 -P: Vendor=04c1 ProdID=008f Rev= 2.07 -S: Manufacturer=3Com Inc. -S: Product=3Com U.S. Robotics Pro ISDN TA -S: SerialNumber=UFT53A49BVT7 -C: #Ifs= 1 Cfg#= 1 Atr=60 MxPwr= 0mA -I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=acm -E: Ad=85(I) Atr=02(Bulk) MxPS= 64 Ivl= 0ms -E: Ad=04(O) Atr=02(Bulk) MxPS= 64 Ivl= 0ms -E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=128ms -C:* #Ifs= 2 Cfg#= 2 Atr=60 MxPwr= 0mA -I: If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=02 Prot=01 Driver=acm -E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=128ms -I: If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=acm -E: Ad=85(I) Atr=02(Bulk) MxPS= 64 Ivl= 0ms -E: Ad=04(O) Atr=02(Bulk) MxPS= 64 Ivl= 0ms + +The first step would be to check /sys/kernel/debug/usb/devices, it should look +like this:: + + T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 + B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0 + D: Ver= 1.00 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 + P: Vendor=0000 ProdID=0000 Rev= 0.00 + S: Product=USB UHCI Root Hub + S: SerialNumber=6800 + C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA + I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub + E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=255ms + T: Bus=01 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 + D: Ver= 1.00 Cls=02(comm.) Sub=00 Prot=00 MxPS= 8 #Cfgs= 2 + P: Vendor=04c1 ProdID=008f Rev= 2.07 + S: Manufacturer=3Com Inc. + S: Product=3Com U.S. Robotics Pro ISDN TA + S: SerialNumber=UFT53A49BVT7 + C: #Ifs= 1 Cfg#= 1 Atr=60 MxPwr= 0mA + I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=acm + E: Ad=85(I) Atr=02(Bulk) MxPS= 64 Ivl= 0ms + E: Ad=04(O) Atr=02(Bulk) MxPS= 64 Ivl= 0ms + E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=128ms + C:* #Ifs= 2 Cfg#= 2 Atr=60 MxPwr= 0mA + I: If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=02 Prot=01 Driver=acm + E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=128ms + I: If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=acm + E: Ad=85(I) Atr=02(Bulk) MxPS= 64 Ivl= 0ms + E: Ad=04(O) Atr=02(Bulk) MxPS= 64 Ivl= 0ms The presence of these three lines (and the Cls= 'comm' and 'data' classes) is important, it means it's an ACM device. The Driver=acm means the acm driver is used for the device. If you see only Cls=ff(vend.) then you're out -of luck, you have a device with vendor specific-interface. - -D: Ver= 1.00 Cls=02(comm.) Sub=00 Prot=00 MxPS= 8 #Cfgs= 2 -I: If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=02 Prot=01 Driver=acm -I: If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=acm - -In the system log you should see: - -usb.c: USB new device connect, assigned device number 2 -usb.c: kmalloc IF c7691fa0, numif 1 -usb.c: kmalloc IF c7b5f3e0, numif 2 -usb.c: skipped 4 class/vendor specific interface descriptors -usb.c: new device strings: Mfr=1, Product=2, SerialNumber=3 -usb.c: USB device number 2 default language ID 0x409 -Manufacturer: 3Com Inc. -Product: 3Com U.S. Robotics Pro ISDN TA -SerialNumber: UFT53A49BVT7 -acm.c: probing config 1 -acm.c: probing config 2 -ttyACM0: USB ACM device -acm.c: acm_control_msg: rq: 0x22 val: 0x0 len: 0x0 result: 0 -acm.c: acm_control_msg: rq: 0x20 val: 0x0 len: 0x7 result: 7 -usb.c: acm driver claimed interface c7b5f3e0 -usb.c: acm driver claimed interface c7b5f3f8 -usb.c: acm driver claimed interface c7691fa0 +of luck, you have a device with vendor specific-interface:: + + D: Ver= 1.00 Cls=02(comm.) Sub=00 Prot=00 MxPS= 8 #Cfgs= 2 + I: If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=02 Prot=01 Driver=acm + I: If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=acm + +In the system log you should see:: + + usb.c: USB new device connect, assigned device number 2 + usb.c: kmalloc IF c7691fa0, numif 1 + usb.c: kmalloc IF c7b5f3e0, numif 2 + usb.c: skipped 4 class/vendor specific interface descriptors + usb.c: new device strings: Mfr=1, Product=2, SerialNumber=3 + usb.c: USB device number 2 default language ID 0x409 + Manufacturer: 3Com Inc. + Product: 3Com U.S. Robotics Pro ISDN TA + SerialNumber: UFT53A49BVT7 + acm.c: probing config 1 + acm.c: probing config 2 + ttyACM0: USB ACM device + acm.c: acm_control_msg: rq: 0x22 val: 0x0 len: 0x0 result: 0 + acm.c: acm_control_msg: rq: 0x20 val: 0x0 len: 0x7 result: 7 + usb.c: acm driver claimed interface c7b5f3e0 + usb.c: acm driver claimed interface c7b5f3f8 + usb.c: acm driver claimed interface c7691fa0 If all this seems to be OK, fire up minicom and set it to talk to the ttyACM device and try typing 'at'. If it responds with 'OK', then everything is diff --git a/Documentation/usb/authorization.txt b/Documentation/usb/authorization.txt index 9dd1dc7b1009..9e53909d04c2 100644 --- a/Documentation/usb/authorization.txt +++ b/Documentation/usb/authorization.txt @@ -1,7 +1,8 @@ - +============================================================== Authorizing (or not) your USB devices to connect to the system +============================================================== -(C) 2007 Inaky Perez-Gonzalez <inaky@linux.intel.com> Intel Corporation +Copyright (C) 2007 Inaky Perez-Gonzalez <inaky@linux.intel.com> Intel Corporation This feature allows you to control if a USB device can be used (or not) in a system. This feature will allow you to implement a lock-down @@ -12,24 +13,25 @@ its interfaces are immediately made available to the users. With this modification, only if root authorizes the device to be configured will then it be possible to use it. -Usage: +Usage +===== -Authorize a device to connect: +Authorize a device to connect:: -$ echo 1 > /sys/bus/usb/devices/DEVICE/authorized + $ echo 1 > /sys/bus/usb/devices/DEVICE/authorized -Deauthorize a device: +De-authorize a device:: -$ echo 0 > /sys/bus/usb/devices/DEVICE/authorized + $ echo 0 > /sys/bus/usb/devices/DEVICE/authorized Set new devices connected to hostX to be deauthorized by default (ie: -lock down): +lock down):: -$ echo 0 > /sys/bus/usb/devices/usbX/authorized_default + $ echo 0 > /sys/bus/usb/devices/usbX/authorized_default -Remove the lock down: +Remove the lock down:: -$ echo 1 > /sys/bus/usb/devices/usbX/authorized_default + $ echo 1 > /sys/bus/usb/devices/usbX/authorized_default By default, Wired USB devices are authorized by default to connect. Wireless USB hosts deauthorize by default all new connected @@ -40,21 +42,21 @@ USB ports. Example system lockdown (lame) ------------------------ +------------------------------ Imagine you want to implement a lockdown so only devices of type XYZ can be connected (for example, it is a kiosk machine with a visible -USB port): +USB port):: -boot up -rc.local -> + boot up + rc.local -> - for host in /sys/bus/usb/devices/usb* - do - echo 0 > $host/authorized_default - done + for host in /sys/bus/usb/devices/usb* + do + echo 0 > $host/authorized_default + done -Hookup an script to udev, for new USB devices +Hookup an script to udev, for new USB devices:: if device_is_my_type $DEV then @@ -67,10 +69,10 @@ checking if the class, type and protocol match something is the worse security verification you can make (or the best, for someone willing to break it). If you need something secure, use crypto and Certificate Authentication or stuff like that. Something simple for an storage key -could be: +could be:: -function device_is_my_type() -{ + function device_is_my_type() + { echo 1 > authorized # temporarily authorize it # FIXME: make sure none can mount it mount DEVICENODE /mntpoint @@ -83,7 +85,7 @@ function device_is_my_type() else echo 0 > authorized fi -} + } Of course, this is lame, you'd want to do a real certificate @@ -95,30 +97,35 @@ welcome. Interface authorization ----------------------- + There is a similar approach to allow or deny specific USB interfaces. That allows to block only a subset of an USB device. -Authorize an interface: -$ echo 1 > /sys/bus/usb/devices/INTERFACE/authorized +Authorize an interface:: -Deauthorize an interface: -$ echo 0 > /sys/bus/usb/devices/INTERFACE/authorized + $ echo 1 > /sys/bus/usb/devices/INTERFACE/authorized + +Deauthorize an interface:: + + $ echo 0 > /sys/bus/usb/devices/INTERFACE/authorized The default value for new interfaces on a particular USB bus can be changed, too. -Allow interfaces per default: -$ echo 1 > /sys/bus/usb/devices/usbX/interface_authorized_default +Allow interfaces per default:: + + $ echo 1 > /sys/bus/usb/devices/usbX/interface_authorized_default + +Deny interfaces per default:: -Deny interfaces per default: -$ echo 0 > /sys/bus/usb/devices/usbX/interface_authorized_default + $ echo 0 > /sys/bus/usb/devices/usbX/interface_authorized_default Per default the interface_authorized_default bit is 1. So all interfaces would authorized per default. Note: -If a deauthorized interface will be authorized so the driver probing must -be triggered manually by writing INTERFACE to /sys/bus/usb/drivers_probe + If a deauthorized interface will be authorized so the driver probing must + be triggered manually by writing INTERFACE to /sys/bus/usb/drivers_probe For drivers that need multiple interfaces all needed interfaces should be authorized first. After that the drivers should be probed. diff --git a/Documentation/usb/chipidea.txt b/Documentation/usb/chipidea.txt index d1eedc01b00a..68473abe2823 100644 --- a/Documentation/usb/chipidea.txt +++ b/Documentation/usb/chipidea.txt @@ -1,22 +1,37 @@ +============================================== +ChipIdea Highspeed Dual Role Controller Driver +============================================== + 1. How to test OTG FSM(HNP and SRP) ----------------------------------- + To show how to demo OTG HNP and SRP functions via sys input files with 2 Freescale i.MX6Q sabre SD boards. 1.1 How to enable OTG FSM ---------------------------------------- +------------------------- + 1.1.1 Select CONFIG_USB_OTG_FSM in menuconfig, rebuild kernel +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + Image and modules. If you want to check some internal variables for otg fsm, mount debugfs, there are 2 files -which can show otg fsm variables and some controller registers value: -cat /sys/kernel/debug/ci_hdrc.0/otg -cat /sys/kernel/debug/ci_hdrc.0/registers +which can show otg fsm variables and some controller registers value:: + + cat /sys/kernel/debug/ci_hdrc.0/otg + cat /sys/kernel/debug/ci_hdrc.0/registers + 1.1.2 Add below entries in your dts file for your controller node +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +:: + otg-rev = <0x0200>; adp-disable; 1.2 Test operations ------------------- + 1) Power up 2 Freescale i.MX6Q sabre SD boards with gadget class driver loaded (e.g. g_mass_storage). @@ -26,19 +41,24 @@ cat /sys/kernel/debug/ci_hdrc.0/registers The A-device(with micro A plug inserted) should enumerate B-device. 3) Role switch - On B-device: - echo 1 > /sys/bus/platform/devices/ci_hdrc.0/inputs/b_bus_req + + On B-device:: + + echo 1 > /sys/bus/platform/devices/ci_hdrc.0/inputs/b_bus_req B-device should take host role and enumerate A-device. 4) A-device switch back to host. - On B-device: - echo 0 > /sys/bus/platform/devices/ci_hdrc.0/inputs/b_bus_req + + On B-device:: + + echo 0 > /sys/bus/platform/devices/ci_hdrc.0/inputs/b_bus_req or, by introducing HNP polling, B-Host can know when A-peripheral wish to be host role, so this role switch also can be trigged in A-peripheral - side by answering the polling from B-Host, this can be done on A-device: - echo 1 > /sys/bus/platform/devices/ci_hdrc.0/inputs/a_bus_req + side by answering the polling from B-Host, this can be done on A-device:: + + echo 1 > /sys/bus/platform/devices/ci_hdrc.0/inputs/a_bus_req A-device should switch back to host and enumerate B-device. @@ -49,23 +69,31 @@ cat /sys/kernel/debug/ci_hdrc.0/registers A-device should NOT enumerate B-device. if A-device wants to use bus: - On A-device: - echo 0 > /sys/bus/platform/devices/ci_hdrc.0/inputs/a_bus_drop - echo 1 > /sys/bus/platform/devices/ci_hdrc.0/inputs/a_bus_req + + On A-device:: + + echo 0 > /sys/bus/platform/devices/ci_hdrc.0/inputs/a_bus_drop + echo 1 > /sys/bus/platform/devices/ci_hdrc.0/inputs/a_bus_req if B-device wants to use bus: - On B-device: - echo 1 > /sys/bus/platform/devices/ci_hdrc.0/inputs/b_bus_req + + On B-device:: + + echo 1 > /sys/bus/platform/devices/ci_hdrc.0/inputs/b_bus_req 7) A-device power down the bus. - On A-device: - echo 1 > /sys/bus/platform/devices/ci_hdrc.0/inputs/a_bus_drop + + On A-device:: + + echo 1 > /sys/bus/platform/devices/ci_hdrc.0/inputs/a_bus_drop A-device should disconnect with B-device and power down the bus. 8) B-device does data pulse for SRP. - On B-device: - echo 1 > /sys/bus/platform/devices/ci_hdrc.0/inputs/b_bus_req + + On B-device:: + + echo 1 > /sys/bus/platform/devices/ci_hdrc.0/inputs/b_bus_req A-device should resume usb bus and enumerate B-device. @@ -75,22 +103,31 @@ cat /sys/kernel/debug/ci_hdrc.0/registers July 27, 2012 Revision 2.0 version 1.1a" 2. How to enable USB as system wakeup source ------------------------------------ +-------------------------------------------- Below is the example for how to enable USB as system wakeup source at imx6 platform. -2.1 Enable core's wakeup -echo enabled > /sys/bus/platform/devices/ci_hdrc.0/power/wakeup -2.2 Enable glue layer's wakeup -echo enabled > /sys/bus/platform/devices/2184000.usb/power/wakeup -2.3 Enable PHY's wakeup (optional) -echo enabled > /sys/bus/platform/devices/20c9000.usbphy/power/wakeup -2.4 Enable roothub's wakeup -echo enabled > /sys/bus/usb/devices/usb1/power/wakeup -2.5 Enable related device's wakeup -echo enabled > /sys/bus/usb/devices/1-1/power/wakeup +2.1 Enable core's wakeup:: + + echo enabled > /sys/bus/platform/devices/ci_hdrc.0/power/wakeup + +2.2 Enable glue layer's wakeup:: + + echo enabled > /sys/bus/platform/devices/2184000.usb/power/wakeup + +2.3 Enable PHY's wakeup (optional):: + + echo enabled > /sys/bus/platform/devices/20c9000.usbphy/power/wakeup + +2.4 Enable roothub's wakeup:: + + echo enabled > /sys/bus/usb/devices/usb1/power/wakeup + +2.5 Enable related device's wakeup:: + + echo enabled > /sys/bus/usb/devices/1-1/power/wakeup If the system has only one usb port, and you want usb wakeup at this port, you -can use below script to enable usb wakeup. -for i in $(find /sys -name wakeup | grep usb);do echo enabled > $i;done; +can use below script to enable usb wakeup:: + for i in $(find /sys -name wakeup | grep usb);do echo enabled > $i;done; diff --git a/Documentation/usb/dwc3.txt b/Documentation/usb/dwc3.txt index 1d02c01d1c7c..f94a7ba16573 100644 --- a/Documentation/usb/dwc3.txt +++ b/Documentation/usb/dwc3.txt @@ -1,6 +1,11 @@ +=========== +DWC3 driver +=========== + + +TODO +~~~~ - TODO -~~~~~~ Please pick something while reading :) - Convert interrupt handler to per-ep-thread-irq @@ -9,6 +14,7 @@ Please pick something while reading :) until the command completes which is bad. Implementation idea: + - dwc core implements a demultiplexing irq chip for interrupts per endpoint. The interrupt numbers are allocated during probe and belong to the device. If MSI provides per-endpoint interrupt this dummy @@ -19,6 +25,7 @@ Please pick something while reading :) - dwc3_send_gadget_ep_cmd() will sleep in wait_for_completion_timeout() until the command completes. - the interrupt handler is split into the following pieces: + - primary handler of the device goes through every event and calls generic_handle_irq() for event it. On return from generic_handle_irq() in acknowledges the event @@ -40,6 +47,7 @@ Please pick something while reading :) for command completion. Latency: + There should be no increase in latency since the interrupt-thread has a high priority and will be run before an average task in user land (except the user changed priorities). diff --git a/Documentation/usb/ehci.txt b/Documentation/usb/ehci.txt index 160bd6c3ab7b..31f650e7c1b4 100644 --- a/Documentation/usb/ehci.txt +++ b/Documentation/usb/ehci.txt @@ -1,3 +1,7 @@ +=========== +EHCI driver +=========== + 27-Dec-2002 The EHCI driver is used to talk to high speed USB 2.0 devices using @@ -40,7 +44,8 @@ APIs exposed to USB device drivers. <dbrownell@users.sourceforge.net> -FUNCTIONALITY +Functionality +============= This driver is regularly tested on x86 hardware, and has also been used on PPC hardware so big/little endianness issues should be gone. @@ -48,6 +53,7 @@ It's believed to do all the right PCI magic so that I/O works even on systems with interesting DMA mapping issues. Transfer Types +-------------- At this writing the driver should comfortably handle all control, bulk, and interrupt transfers, including requests to USB 1.1 devices through @@ -63,6 +69,7 @@ since EHCI represents these with a different data structure. So for now, most USB audio and video devices can't be connected to high speed buses. Driver Behavior +--------------- Transfers of all types can be queued. This means that control transfers from a driver on one interface (or through usbfs) won't interfere with @@ -83,14 +90,15 @@ limits on the number of periodic transactions that can be scheduled, and prevent use of polling intervals of less than one frame. -USE BY +Use by +====== Assuming you have an EHCI controller (on a PCI card or motherboard) -and have compiled this driver as a module, load this like: +and have compiled this driver as a module, load this like:: # modprobe ehci-hcd -and remove it by: +and remove it by:: # rmmod ehci-hcd @@ -112,13 +120,16 @@ If you're using this driver on a 2.5 kernel, and you've enabled USB debugging support, you'll see three files in the "sysfs" directory for any EHCI controller: - "async" dumps the asynchronous schedule, used for control + "async" + dumps the asynchronous schedule, used for control and bulk transfers. Shows each active qh and the qtds pending, usually one qtd per urb. (Look at it with usb-storage doing disk I/O; watch the request queues!) - "periodic" dumps the periodic schedule, used for interrupt + "periodic" + dumps the periodic schedule, used for interrupt and isochronous transfers. Doesn't show qtds. - "registers" show controller register state, and + "registers" + show controller register state, and The contents of those files can help identify driver problems. @@ -136,7 +147,8 @@ transaction translators are in use; some drivers have been seen to behave badly when they see different faults than OHCI or UHCI report. -PERFORMANCE +Performance +=========== USB 2.0 throughput is gated by two main factors: how fast the host controller can process requests, and how fast devices can respond to @@ -156,6 +168,7 @@ hardware and device driver software allow it. Periodic transfer modes approach the quoted 480 MBit/sec transfer rate. Hardware Performance +-------------------- At this writing, individual USB 2.0 devices tend to max out at around 20 MByte/sec transfer rates. This is of course subject to change; @@ -183,6 +196,7 @@ you issue a control or bulk request you can often expect to learn that it completed in less than 250 usec (depending on transfer size). Software Performance +-------------------- To get even 20 MByte/sec transfer rates, Linux-USB device drivers will need to keep the EHCI queue full. That means issuing large requests, @@ -206,9 +220,11 @@ mapping (which might apply an IOMMU) and IRQ reduction, all of which will help make high speed transfers run as fast as they can. -TBD: Interrupt and ISO transfer performance issues. Those periodic -transfers are fully scheduled, so the main issue is likely to be how -to trigger "high bandwidth" modes. +TBD: + Interrupt and ISO transfer performance issues. Those periodic + transfers are fully scheduled, so the main issue is likely to be how + to trigger "high bandwidth" modes. -TBD: More than standard 80% periodic bandwidth allocation is possible -through sysfs uframe_periodic_max parameter. Describe that. +TBD: + More than standard 80% periodic bandwidth allocation is possible + through sysfs uframe_periodic_max parameter. Describe that. diff --git a/Documentation/usb/functionfs.txt b/Documentation/usb/functionfs.txt index eaaaea019fc7..7fdc6d840ac5 100644 --- a/Documentation/usb/functionfs.txt +++ b/Documentation/usb/functionfs.txt @@ -1,4 +1,6 @@ -*How FunctionFS works* +==================== +How FunctionFS works +==================== From kernel point of view it is just a composite function with some unique behaviour. It may be added to an USB configuration only after @@ -38,13 +40,13 @@ when mounting. One can imagine a gadget that has an Ethernet, MTP and HID interfaces where the last two are implemented via FunctionFS. On user space -level it would look like this: +level it would look like this:: -$ insmod g_ffs.ko idVendor=<ID> iSerialNumber=<string> functions=mtp,hid -$ mkdir /dev/ffs-mtp && mount -t functionfs mtp /dev/ffs-mtp -$ ( cd /dev/ffs-mtp && mtp-daemon ) & -$ mkdir /dev/ffs-hid && mount -t functionfs hid /dev/ffs-hid -$ ( cd /dev/ffs-hid && hid-daemon ) & + $ insmod g_ffs.ko idVendor=<ID> iSerialNumber=<string> functions=mtp,hid + $ mkdir /dev/ffs-mtp && mount -t functionfs mtp /dev/ffs-mtp + $ ( cd /dev/ffs-mtp && mtp-daemon ) & + $ mkdir /dev/ffs-hid && mount -t functionfs hid /dev/ffs-hid + $ ( cd /dev/ffs-hid && hid-daemon ) & On kernel level the gadget checks ffs_data->dev_name to identify whether it's FunctionFS designed for MTP ("mtp") or HID ("hid"). @@ -64,4 +66,3 @@ have been written to their ep0's. Conversely, the gadget is unregistered after the first USB function closes its endpoints. - diff --git a/Documentation/usb/gadget-testing.txt b/Documentation/usb/gadget-testing.txt index 5908a21fddb6..7d7f2340af42 100644 --- a/Documentation/usb/gadget-testing.txt +++ b/Documentation/usb/gadget-testing.txt @@ -1,26 +1,32 @@ +============== +Gadget Testing +============== + This file summarizes information on basic testing of USB functions provided by gadgets. -1. ACM function -2. ECM function -3. ECM subset function -4. EEM function -5. FFS function -6. HID function -7. LOOPBACK function -8. MASS STORAGE function -9. MIDI function -10. NCM function -11. OBEX function -12. PHONET function -13. RNDIS function -14. SERIAL function -15. SOURCESINK function -16. UAC1 function (legacy implementation) -17. UAC2 function -18. UVC function -19. PRINTER function -20. UAC1 function (new API) +.. contents + + 1. ACM function + 2. ECM function + 3. ECM subset function + 4. EEM function + 5. FFS function + 6. HID function + 7. LOOPBACK function + 8. MASS STORAGE function + 9. MIDI function + 10. NCM function + 11. OBEX function + 12. PHONET function + 13. RNDIS function + 14. SERIAL function + 15. SOURCESINK function + 16. UAC1 function (legacy implementation) + 17. UAC2 function + 18. UVC function + 19. PRINTER function + 20. UAC1 function (new API) 1. ACM function @@ -44,13 +50,23 @@ There can be at most 4 ACM/generic serial/OBEX ports in the system. Testing the ACM function ------------------------ -On the host: cat > /dev/ttyACM<X> -On the device : cat /dev/ttyGS<Y> +On the host:: + + cat > /dev/ttyACM<X> + +On the device:: + + cat /dev/ttyGS<Y> then the other way round -On the device: cat > /dev/ttyGS<Y> -On the host: cat /dev/ttyACM<X> +On the device:: + + cat > /dev/ttyGS<Y> + +On the host:: + + cat /dev/ttyACM<X> 2. ECM function =============== @@ -63,13 +79,15 @@ Function-specific configfs interface The function name to use when creating the function directory is "ecm". The ECM function provides these attributes in its function directory: - ifname - network device interface name associated with this + =============== ================================================== + ifname network device interface name associated with this function instance - qmult - queue length multiplier for high and super speed - host_addr - MAC address of host's end of this + qmult queue length multiplier for high and super speed + host_addr MAC address of host's end of this Ethernet over USB link - dev_addr - MAC address of device's end of this + dev_addr MAC address of device's end of this Ethernet over USB link + =============== ================================================== and after creating the functions/ecm.<instance name> they contain default values: qmult is 5, dev_addr and host_addr are randomly selected. @@ -82,8 +100,13 @@ Testing the ECM function Configure IP addresses of the device and the host. Then: -On the device: ping <host's IP> -On the host: ping <device's IP> +On the device:: + + ping <host's IP> + +On the host:: + + ping <device's IP> 3. ECM subset function ====================== @@ -96,13 +119,15 @@ Function-specific configfs interface The function name to use when creating the function directory is "geth". The ECM subset function provides these attributes in its function directory: - ifname - network device interface name associated with this + =============== ================================================== + ifname network device interface name associated with this function instance - qmult - queue length multiplier for high and super speed - host_addr - MAC address of host's end of this + qmult queue length multiplier for high and super speed + host_addr MAC address of host's end of this Ethernet over USB link - dev_addr - MAC address of device's end of this + dev_addr MAC address of device's end of this Ethernet over USB link + =============== ================================================== and after creating the functions/ecm.<instance name> they contain default values: qmult is 5, dev_addr and host_addr are randomly selected. @@ -115,8 +140,13 @@ Testing the ECM subset function Configure IP addresses of the device and the host. Then: -On the device: ping <host's IP> -On the host: ping <device's IP> +On the device:: + + ping <host's IP> + +On the host:: + + ping <device's IP> 4. EEM function =============== @@ -129,13 +159,15 @@ Function-specific configfs interface The function name to use when creating the function directory is "eem". The EEM function provides these attributes in its function directory: - ifname - network device interface name associated with this + =============== ================================================== + ifname network device interface name associated with this function instance - qmult - queue length multiplier for high and super speed - host_addr - MAC address of host's end of this + qmult queue length multiplier for high and super speed + host_addr MAC address of host's end of this Ethernet over USB link - dev_addr - MAC address of device's end of this + dev_addr MAC address of device's end of this Ethernet over USB link + =============== ================================================== and after creating the functions/eem.<instance name> they contain default values: qmult is 5, dev_addr and host_addr are randomly selected. @@ -148,8 +180,13 @@ Testing the EEM function Configure IP addresses of the device and the host. Then: -On the device: ping <host's IP> -On the host: ping <device's IP> +On the device:: + + ping <host's IP> + +On the host:: + + ping <device's IP> 5. FFS function =============== @@ -172,6 +209,7 @@ Testing the FFS function ------------------------ On the device: start the function's userspace daemon, enable the gadget + On the host: use the USB function provided by the device 6. HID function @@ -185,39 +223,43 @@ Function-specific configfs interface The function name to use when creating the function directory is "hid". The HID function provides these attributes in its function directory: - protocol - HID protocol to use - report_desc - data to be used in HID reports, except data + =============== =========================================== + protocol HID protocol to use + report_desc data to be used in HID reports, except data passed with /dev/hidg<X> - report_length - HID report length - subclass - HID subclass to use + report_length HID report length + subclass HID subclass to use + =============== =========================================== For a keyboard the protocol and the subclass are 1, the report_length is 8, -while the report_desc is: +while the report_desc is:: -$ hd my_report_desc -00000000 05 01 09 06 a1 01 05 07 19 e0 29 e7 15 00 25 01 |..........)...%.| -00000010 75 01 95 08 81 02 95 01 75 08 81 03 95 05 75 01 |u.......u.....u.| -00000020 05 08 19 01 29 05 91 02 95 01 75 03 91 03 95 06 |....).....u.....| -00000030 75 08 15 00 25 65 05 07 19 00 29 65 81 00 c0 |u...%e....)e...| -0000003f + $ hd my_report_desc + 00000000 05 01 09 06 a1 01 05 07 19 e0 29 e7 15 00 25 01 |..........)...%.| + 00000010 75 01 95 08 81 02 95 01 75 08 81 03 95 05 75 01 |u.......u.....u.| + 00000020 05 08 19 01 29 05 91 02 95 01 75 03 91 03 95 06 |....).....u.....| + 00000030 75 08 15 00 25 65 05 07 19 00 29 65 81 00 c0 |u...%e....)e...| + 0000003f -Such a sequence of bytes can be stored to the attribute with echo: +Such a sequence of bytes can be stored to the attribute with echo:: -$ echo -ne \\x05\\x01\\x09\\x06\\xa1..... + $ echo -ne \\x05\\x01\\x09\\x06\\xa1..... Testing the HID function ------------------------ Device: + - create the gadget - connect the gadget to a host, preferably not the one used -to control the gadget + to control the gadget - run a program which writes to /dev/hidg<N>, e.g. -a userspace program found in Documentation/usb/gadget_hid.txt: + a userspace program found in Documentation/usb/gadget_hid.txt:: -$ ./hid_gadget_test /dev/hidg0 keyboard + $ ./hid_gadget_test /dev/hidg0 keyboard Host: + - observe the keystrokes from the gadget 7. LOOPBACK function @@ -231,13 +273,16 @@ Function-specific configfs interface The function name to use when creating the function directory is "Loopback". The LOOPBACK function provides these attributes in its function directory: - qlen - depth of loopback queue - bulk_buflen - buffer length + =============== ======================= + qlen depth of loopback queue + bulk_buflen buffer length + =============== ======================= Testing the LOOPBACK function ----------------------------- device: run the gadget + host: test-usb (tools/usb/testusb.c) 8. MASS STORAGE function @@ -252,18 +297,20 @@ The function name to use when creating the function directory is "mass_storage". The MASS STORAGE function provides these attributes in its directory: files: - stall - Set to permit function to halt bulk endpoints. + =============== ============================================== + stall Set to permit function to halt bulk endpoints. Disabled on some USB devices known not to work correctly. You should set it to true. - num_buffers - Number of pipeline buffers. Valid numbers + num_buffers Number of pipeline buffers. Valid numbers are 2..4. Available only if CONFIG_USB_GADGET_DEBUG_FILES is set. + =============== ============================================== and a default lun.0 directory corresponding to SCSI LUN #0. -A new lun can be added with mkdir: +A new lun can be added with mkdir:: -$ mkdir functions/mass_storage.0/partition.5 + $ mkdir functions/mass_storage.0/partition.5 Lun numbering does not have to be continuous, except for lun #0 which is created by default. A maximum of 8 luns can be specified and they all must be @@ -273,18 +320,20 @@ although it is not mandatory. In each lun directory there are the following attribute files: - file - The path to the backing file for the LUN. + =============== ============================================== + file The path to the backing file for the LUN. Required if LUN is not marked as removable. - ro - Flag specifying access to the LUN shall be + ro Flag specifying access to the LUN shall be read-only. This is implied if CD-ROM emulation is enabled as well as when it was impossible to open "filename" in R/W mode. - removable - Flag specifying that LUN shall be indicated as + removable Flag specifying that LUN shall be indicated as being removable. - cdrom - Flag specifying that LUN shall be reported as + cdrom Flag specifying that LUN shall be reported as being a CD-ROM. - nofua - Flag specifying that FUA flag + nofua Flag specifying that FUA flag in SCSI WRITE(10,12) + =============== ============================================== Testing the MASS STORAGE function --------------------------------- @@ -304,12 +353,14 @@ Function-specific configfs interface The function name to use when creating the function directory is "midi". The MIDI function provides these attributes in its function directory: - buflen - MIDI buffer length - id - ID string for the USB MIDI adapter - in_ports - number of MIDI input ports - index - index value for the USB MIDI adapter - out_ports - number of MIDI output ports - qlen - USB read request queue length + =============== ==================================== + buflen MIDI buffer length + id ID string for the USB MIDI adapter + in_ports number of MIDI input ports + index index value for the USB MIDI adapter + out_ports number of MIDI output ports + qlen USB read request queue length + =============== ==================================== Testing the MIDI function ------------------------- @@ -317,60 +368,63 @@ Testing the MIDI function There are two cases: playing a mid from the gadget to the host and playing a mid from the host to the gadget. -1) Playing a mid from the gadget to the host -host) +1) Playing a mid from the gadget to the host: + +host:: -$ arecordmidi -l - Port Client name Port name - 14:0 Midi Through Midi Through Port-0 - 24:0 MIDI Gadget MIDI Gadget MIDI 1 -$ arecordmidi -p 24:0 from_gadget.mid + $ arecordmidi -l + Port Client name Port name + 14:0 Midi Through Midi Through Port-0 + 24:0 MIDI Gadget MIDI Gadget MIDI 1 + $ arecordmidi -p 24:0 from_gadget.mid -gadget) +gadget:: -$ aplaymidi -l - Port Client name Port name - 20:0 f_midi f_midi + $ aplaymidi -l + Port Client name Port name + 20:0 f_midi f_midi -$ aplaymidi -p 20:0 to_host.mid + $ aplaymidi -p 20:0 to_host.mid 2) Playing a mid from the host to the gadget -gadget) -$ arecordmidi -l - Port Client name Port name - 20:0 f_midi f_midi +gadget:: + + $ arecordmidi -l + Port Client name Port name + 20:0 f_midi f_midi -$ arecordmidi -p 20:0 from_host.mid + $ arecordmidi -p 20:0 from_host.mid -host) +host:: -$ aplaymidi -l - Port Client name Port name - 14:0 Midi Through Midi Through Port-0 - 24:0 MIDI Gadget MIDI Gadget MIDI 1 + $ aplaymidi -l + Port Client name Port name + 14:0 Midi Through Midi Through Port-0 + 24:0 MIDI Gadget MIDI Gadget MIDI 1 -$ aplaymidi -p24:0 to_gadget.mid + $ aplaymidi -p24:0 to_gadget.mid The from_gadget.mid should sound identical to the to_host.mid. + The from_host.id should sound identical to the to_gadget.mid. -MIDI files can be played to speakers/headphones with e.g. timidity installed +MIDI files can be played to speakers/headphones with e.g. timidity installed:: -$ aplaymidi -l - Port Client name Port name - 14:0 Midi Through Midi Through Port-0 - 24:0 MIDI Gadget MIDI Gadget MIDI 1 -128:0 TiMidity TiMidity port 0 -128:1 TiMidity TiMidity port 1 -128:2 TiMidity TiMidity port 2 -128:3 TiMidity TiMidity port 3 + $ aplaymidi -l + Port Client name Port name + 14:0 Midi Through Midi Through Port-0 + 24:0 MIDI Gadget MIDI Gadget MIDI 1 + 128:0 TiMidity TiMidity port 0 + 128:1 TiMidity TiMidity port 1 + 128:2 TiMidity TiMidity port 2 + 128:3 TiMidity TiMidity port 3 -$ aplaymidi -p 128:0 file.mid + $ aplaymidi -p 128:0 file.mid -MIDI ports can be logically connected using the aconnect utility, e.g.: +MIDI ports can be logically connected using the aconnect utility, e.g.:: -$ aconnect 24:0 128:0 # try it on the host + $ aconnect 24:0 128:0 # try it on the host After the gadget's MIDI port is connected to timidity's MIDI port, whatever is played at the gadget side with aplaymidi -l is audible @@ -387,13 +441,15 @@ Function-specific configfs interface The function name to use when creating the function directory is "ncm". The NCM function provides these attributes in its function directory: - ifname - network device interface name associated with this + =============== ================================================== + ifname network device interface name associated with this function instance - qmult - queue length multiplier for high and super speed - host_addr - MAC address of host's end of this + qmult queue length multiplier for high and super speed + host_addr MAC address of host's end of this Ethernet over USB link - dev_addr - MAC address of device's end of this + dev_addr MAC address of device's end of this Ethernet over USB link + =============== ================================================== and after creating the functions/ncm.<instance name> they contain default values: qmult is 5, dev_addr and host_addr are randomly selected. @@ -406,8 +462,13 @@ Testing the NCM function Configure IP addresses of the device and the host. Then: -On the device: ping <host's IP> -On the host: ping <device's IP> +On the device:: + + ping <host's IP> + +On the host:: + + ping <device's IP> 11. OBEX function ================= @@ -429,13 +490,18 @@ There can be at most 4 ACM/generic serial/OBEX ports in the system. Testing the OBEX function ------------------------- -On device: seriald -f /dev/ttyGS<Y> -s 1024 -On host: serialc -v <vendorID> -p <productID> -i<interface#> -a1 -s1024 \ - -t<out endpoint addr> -r<in endpoint addr> +On device:: + + seriald -f /dev/ttyGS<Y> -s 1024 + +On host:: + + serialc -v <vendorID> -p <productID> -i<interface#> -a1 -s1024 \ + -t<out endpoint addr> -r<in endpoint addr> where seriald and serialc are Felipe's utilities found here: -https://github.com/felipebalbi/usb-tools.git master + https://github.com/felipebalbi/usb-tools.git master 12. PHONET function =================== @@ -448,8 +514,10 @@ Function-specific configfs interface The function name to use when creating the function directory is "phonet". The PHONET function provides just one attribute in its function directory: - ifname - network device interface name associated with this + =============== ================================================== + ifname network device interface name associated with this function instance + =============== ================================================== Testing the PHONET function --------------------------- @@ -464,41 +532,41 @@ These tools are required: git://git.gitorious.org/meego-cellular/phonet-utils.git -On the host: +On the host:: -$ ./phonet -a 0x10 -i usbpn0 -$ ./pnroute add 0x6c usbpn0 -$./pnroute add 0x10 usbpn0 -$ ifconfig usbpn0 up + $ ./phonet -a 0x10 -i usbpn0 + $ ./pnroute add 0x6c usbpn0 + $./pnroute add 0x10 usbpn0 + $ ifconfig usbpn0 up -On the device: +On the device:: -$ ./phonet -a 0x6c -i upnlink0 -$ ./pnroute add 0x10 upnlink0 -$ ifconfig upnlink0 up + $ ./phonet -a 0x6c -i upnlink0 + $ ./pnroute add 0x10 upnlink0 + $ ifconfig upnlink0 up -Then a test program can be used: +Then a test program can be used:: -http://www.spinics.net/lists/linux-usb/msg85690.html + http://www.spinics.net/lists/linux-usb/msg85690.html -On the device: +On the device:: -$ ./pnxmit -a 0x6c -r + $ ./pnxmit -a 0x6c -r -On the host: +On the host:: -$ ./pnxmit -a 0x10 -s 0x6c + $ ./pnxmit -a 0x10 -s 0x6c As a result some data should be sent from host to device. Then the other way round: -On the host: +On the host:: -$ ./pnxmit -a 0x10 -r + $ ./pnxmit -a 0x10 -r -On the device: +On the device:: -$ ./pnxmit -a 0x6c -s 0x10 + $ ./pnxmit -a 0x6c -s 0x10 13. RNDIS function ================== @@ -511,13 +579,15 @@ Function-specific configfs interface The function name to use when creating the function directory is "rndis". The RNDIS function provides these attributes in its function directory: - ifname - network device interface name associated with this + =============== ================================================== + ifname network device interface name associated with this function instance - qmult - queue length multiplier for high and super speed - host_addr - MAC address of host's end of this + qmult queue length multiplier for high and super speed + host_addr MAC address of host's end of this Ethernet over USB link - dev_addr - MAC address of device's end of this + dev_addr MAC address of device's end of this Ethernet over USB link + =============== ================================================== and after creating the functions/rndis.<instance name> they contain default values: qmult is 5, dev_addr and host_addr are randomly selected. @@ -530,8 +600,13 @@ Testing the RNDIS function Configure IP addresses of the device and the host. Then: -On the device: ping <host's IP> -On the host: ping <device's IP> +On the device:: + + ping <host's IP> + +On the host:: + + ping <device's IP> 14. SERIAL function =================== @@ -553,15 +628,28 @@ There can be at most 4 ACM/generic serial/OBEX ports in the system. Testing the SERIAL function --------------------------- -On host: insmod usbserial - echo VID PID >/sys/bus/usb-serial/drivers/generic/new_id -On host: cat > /dev/ttyUSB<X> -On target: cat /dev/ttyGS<Y> +On host:: + + insmod usbserial + echo VID PID >/sys/bus/usb-serial/drivers/generic/new_id + +On host:: + + cat > /dev/ttyUSB<X> + +On target:: + + cat /dev/ttyGS<Y> then the other way round -On target: cat > /dev/ttyGS<Y> -On host: cat /dev/ttyUSB<X> +On target:: + + cat > /dev/ttyGS<Y> + +On host:: + + cat /dev/ttyUSB<X> 15. SOURCESINK function ======================= @@ -574,24 +662,27 @@ Function-specific configfs interface The function name to use when creating the function directory is "SourceSink". The SOURCESINK function provides these attributes in its function directory: - pattern - 0 (all zeros), 1 (mod63), 2 (none) - isoc_interval - 1..16 - isoc_maxpacket - 0 - 1023 (fs), 0 - 1024 (hs/ss) - isoc_mult - 0..2 (hs/ss only) - isoc_maxburst - 0..15 (ss only) - bulk_buflen - buffer length - bulk_qlen - depth of queue for bulk - iso_qlen - depth of queue for iso + =============== ================================== + pattern 0 (all zeros), 1 (mod63), 2 (none) + isoc_interval 1..16 + isoc_maxpacket 0 - 1023 (fs), 0 - 1024 (hs/ss) + isoc_mult 0..2 (hs/ss only) + isoc_maxburst 0..15 (ss only) + bulk_buflen buffer length + bulk_qlen depth of queue for bulk + iso_qlen depth of queue for iso + =============== ================================== Testing the SOURCESINK function ------------------------------- device: run the gadget + host: test-usb (tools/usb/testusb.c) 16. UAC1 function (legacy implementation) -================= +========================================= The function is provided by usb_f_uac1_legacy.ko module. @@ -602,12 +693,14 @@ The function name to use when creating the function directory is "uac1_legacy". The uac1 function provides these attributes in its function directory: - audio_buf_size - audio buffer size - fn_cap - capture pcm device file name - fn_cntl - control device file name - fn_play - playback pcm device file name - req_buf_size - ISO OUT endpoint request buffer size - req_count - ISO OUT endpoint request count + =============== ==================================== + audio_buf_size audio buffer size + fn_cap capture pcm device file name + fn_cntl control device file name + fn_play playback pcm device file name + req_buf_size ISO OUT endpoint request buffer size + req_count ISO OUT endpoint request count + =============== ==================================== The attributes have sane default values. @@ -615,7 +708,10 @@ Testing the UAC1 function ------------------------- device: run the gadget -host: aplay -l # should list our USB Audio Gadget + +host:: + + aplay -l # should list our USB Audio Gadget 17. UAC2 function ================= @@ -628,14 +724,16 @@ Function-specific configfs interface The function name to use when creating the function directory is "uac2". The uac2 function provides these attributes in its function directory: - c_chmask - capture channel mask - c_srate - capture sampling rate - c_ssize - capture sample size (bytes) - p_chmask - playback channel mask - p_srate - playback sampling rate - p_ssize - playback sample size (bytes) - req_number - the number of pre-allocated request for both capture - and playback + =============== ==================================================== + c_chmask capture channel mask + c_srate capture sampling rate + c_ssize capture sample size (bytes) + p_chmask playback channel mask + p_srate playback sampling rate + p_ssize playback sample size (bytes) + req_number the number of pre-allocated request for both capture + and playback + =============== ==================================================== The attributes have sane default values. @@ -648,14 +746,14 @@ host: aplay -l # should list our USB Audio Gadget This function does not require real hardware support, it just sends a stream of audio data to/from the host. In order to actually hear something at the device side, a command similar -to this must be used at the device side: +to this must be used at the device side:: -$ arecord -f dat -t wav -D hw:2,0 | aplay -D hw:0,0 & + $ arecord -f dat -t wav -D hw:2,0 | aplay -D hw:0,0 & -e.g.: +e.g.:: -$ arecord -f dat -t wav -D hw:CARD=UAC2Gadget,DEV=0 | \ -aplay -D default:CARD=OdroidU3 + $ arecord -f dat -t wav -D hw:CARD=UAC2Gadget,DEV=0 | \ + aplay -D default:CARD=OdroidU3 18. UVC function ================ @@ -668,66 +766,73 @@ Function-specific configfs interface The function name to use when creating the function directory is "uvc". The uvc function provides these attributes in its function directory: - streaming_interval - interval for polling endpoint for data transfers - streaming_maxburst - bMaxBurst for super speed companion descriptor - streaming_maxpacket - maximum packet size this endpoint is capable of - sending or receiving when this configuration is - selected + =================== ================================================ + streaming_interval interval for polling endpoint for data transfers + streaming_maxburst bMaxBurst for super speed companion descriptor + streaming_maxpacket maximum packet size this endpoint is capable of + sending or receiving when this configuration is + selected + =================== ================================================ There are also "control" and "streaming" subdirectories, each of which contain a number of their subdirectories. There are some sane defaults provided, but the user must provide the following: - control header - create in control/header, link from control/class/fs - and/or control/class/ss - streaming header - create in streaming/header, link from - streaming/class/fs and/or streaming/class/hs and/or - streaming/class/ss - format description - create in streaming/mjpeg and/or - streaming/uncompressed - frame description - create in streaming/mjpeg/<format> and/or in - streaming/uncompressed/<format> + ================== ==================================================== + control header create in control/header, link from control/class/fs + and/or control/class/ss + streaming header create in streaming/header, link from + streaming/class/fs and/or streaming/class/hs and/or + streaming/class/ss + format description create in streaming/mjpeg and/or + streaming/uncompressed + frame description create in streaming/mjpeg/<format> and/or in + streaming/uncompressed/<format> + ================== ==================================================== Each frame description contains frame interval specification, and each such specification consists of a number of lines with an inverval value -in each line. The rules stated above are best illustrated with an example: - -# mkdir functions/uvc.usb0/control/header/h -# cd functions/uvc.usb0/control/ -# ln -s header/h class/fs -# ln -s header/h class/ss -# mkdir -p functions/uvc.usb0/streaming/uncompressed/u/360p -# cat <<EOF > functions/uvc.usb0/streaming/uncompressed/u/360p/dwFrameInterval -666666 -1000000 -5000000 -EOF -# cd $GADGET_CONFIGFS_ROOT -# mkdir functions/uvc.usb0/streaming/header/h -# cd functions/uvc.usb0/streaming/header/h -# ln -s ../../uncompressed/u -# cd ../../class/fs -# ln -s ../../header/h -# cd ../../class/hs -# ln -s ../../header/h -# cd ../../class/ss -# ln -s ../../header/h +in each line. The rules stated above are best illustrated with an example:: + + # mkdir functions/uvc.usb0/control/header/h + # cd functions/uvc.usb0/control/ + # ln -s header/h class/fs + # ln -s header/h class/ss + # mkdir -p functions/uvc.usb0/streaming/uncompressed/u/360p + # cat <<EOF > functions/uvc.usb0/streaming/uncompressed/u/360p/dwFrameInterval + 666666 + 1000000 + 5000000 + EOF + # cd $GADGET_CONFIGFS_ROOT + # mkdir functions/uvc.usb0/streaming/header/h + # cd functions/uvc.usb0/streaming/header/h + # ln -s ../../uncompressed/u + # cd ../../class/fs + # ln -s ../../header/h + # cd ../../class/hs + # ln -s ../../header/h + # cd ../../class/ss + # ln -s ../../header/h Testing the UVC function ------------------------ -device: run the gadget, modprobe vivid +device: run the gadget, modprobe vivid:: -# uvc-gadget -u /dev/video<uvc video node #> -v /dev/video<vivid video node #> + # uvc-gadget -u /dev/video<uvc video node #> -v /dev/video<vivid video node #> where uvc-gadget is this program: -http://git.ideasonboard.org/uvc-gadget.git + http://git.ideasonboard.org/uvc-gadget.git with these patches: -http://www.spinics.net/lists/linux-usb/msg99220.html -host: luvcview -f yuv + http://www.spinics.net/lists/linux-usb/msg99220.html + +host:: + + luvcview -f yuv 19. PRINTER function ==================== @@ -740,16 +845,19 @@ Function-specific configfs interface The function name to use when creating the function directory is "printer". The printer function provides these attributes in its function directory: - pnp_string - Data to be passed to the host in pnp string - q_len - Number of requests per endpoint + ========== =========================================== + pnp_string Data to be passed to the host in pnp string + q_len Number of requests per endpoint + ========== =========================================== Testing the PRINTER function ---------------------------- The most basic testing: -device: run the gadget -# ls -l /devices/virtual/usb_printer_gadget/ +device: run the gadget:: + + # ls -l /devices/virtual/usb_printer_gadget/ should show g_printer<number>. @@ -761,23 +869,28 @@ If udev is active, then e.g. /dev/usb/lp0 should appear. host->device transmission: -device: -# cat /dev/g_printer<number> -host: -# cat > /dev/usb/lp0 +device:: -device->host transmission: + # cat /dev/g_printer<number> -# cat > /dev/g_printer<number> -host: -# cat /dev/usb/lp0 +host:: + + # cat > /dev/usb/lp0 + +device->host transmission:: + + # cat > /dev/g_printer<number> + +host:: + + # cat /dev/usb/lp0 More advanced testing can be done with the prn_example described in Documentation/usb/gadget_printer.txt. 20. UAC1 function (virtual ALSA card, using u_audio API) -================= +======================================================== The function is provided by usb_f_uac1.ko module. It will create a virtual ALSA card and the audio streams are simply @@ -789,14 +902,16 @@ Function-specific configfs interface The function name to use when creating the function directory is "uac1". The uac1 function provides these attributes in its function directory: - c_chmask - capture channel mask - c_srate - capture sampling rate - c_ssize - capture sample size (bytes) - p_chmask - playback channel mask - p_srate - playback sampling rate - p_ssize - playback sample size (bytes) - req_number - the number of pre-allocated request for both capture - and playback + ========== ==================================================== + c_chmask capture channel mask + c_srate capture sampling rate + c_ssize capture sample size (bytes) + p_chmask playback channel mask + p_srate playback sampling rate + p_ssize playback sample size (bytes) + req_number the number of pre-allocated request for both capture + and playback + ========== ==================================================== The attributes have sane default values. @@ -809,11 +924,11 @@ host: aplay -l # should list our USB Audio Gadget This function does not require real hardware support, it just sends a stream of audio data to/from the host. In order to actually hear something at the device side, a command similar -to this must be used at the device side: +to this must be used at the device side:: -$ arecord -f dat -t wav -D hw:2,0 | aplay -D hw:0,0 & + $ arecord -f dat -t wav -D hw:2,0 | aplay -D hw:0,0 & -e.g.: +e.g.:: -$ arecord -f dat -t wav -D hw:CARD=UAC1Gadget,DEV=0 | \ -aplay -D default:CARD=OdroidU3 + $ arecord -f dat -t wav -D hw:CARD=UAC1Gadget,DEV=0 | \ + aplay -D default:CARD=OdroidU3 diff --git a/Documentation/usb/gadget_configfs.txt b/Documentation/usb/gadget_configfs.txt index b8cb38a98c19..54fb08baae22 100644 --- a/Documentation/usb/gadget_configfs.txt +++ b/Documentation/usb/gadget_configfs.txt @@ -1,11 +1,9 @@ +============================================ +Linux USB gadget configured through configfs +============================================ - - - Linux USB gadget configured through configfs - - - 25th April 2013 +25th April 2013 @@ -26,7 +24,7 @@ Linux provides a number of functions for gadgets to use. Creating a gadget means deciding what configurations there will be and which functions each configuration will provide. -Configfs (please see Documentation/filesystems/configfs/*) lends itself nicely +Configfs (please see `Documentation/filesystems/configfs/*`) lends itself nicely for the purpose of telling the kernel about the above mentioned decision. This document is about how to do it. @@ -51,44 +49,46 @@ Usage made available through configfs can be seen here: http://www.spinics.net/lists/linux-usb/msg76388.html) -$ modprobe libcomposite -$ mount none $CONFIGFS_HOME -t configfs +:: + + $ modprobe libcomposite + $ mount none $CONFIGFS_HOME -t configfs where CONFIGFS_HOME is the mount point for configfs 1. Creating the gadgets ----------------------- -For each gadget to be created its corresponding directory must be created: +For each gadget to be created its corresponding directory must be created:: -$ mkdir $CONFIGFS_HOME/usb_gadget/<gadget name> + $ mkdir $CONFIGFS_HOME/usb_gadget/<gadget name> -e.g.: +e.g.:: -$ mkdir $CONFIGFS_HOME/usb_gadget/g1 + $ mkdir $CONFIGFS_HOME/usb_gadget/g1 -... -... -... + ... + ... + ... -$ cd $CONFIGFS_HOME/usb_gadget/g1 + $ cd $CONFIGFS_HOME/usb_gadget/g1 -Each gadget needs to have its vendor id <VID> and product id <PID> specified: +Each gadget needs to have its vendor id <VID> and product id <PID> specified:: -$ echo <VID> > idVendor -$ echo <PID> > idProduct + $ echo <VID> > idVendor + $ echo <PID> > idProduct A gadget also needs its serial number, manufacturer and product strings. In order to have a place to store them, a strings subdirectory must be created -for each language, e.g.: +for each language, e.g.:: -$ mkdir strings/0x409 + $ mkdir strings/0x409 -Then the strings can be specified: +Then the strings can be specified:: -$ echo <serial number> > strings/0x409/serialnumber -$ echo <manufacturer> > strings/0x409/manufacturer -$ echo <product> > strings/0x409/product + $ echo <serial number> > strings/0x409/serialnumber + $ echo <manufacturer> > strings/0x409/manufacturer + $ echo <product> > strings/0x409/product 2. Creating the configurations ------------------------------ @@ -99,43 +99,43 @@ directories must be created: $ mkdir configs/<name>.<number> where <name> can be any string which is legal in a filesystem and the -<number> is the configuration's number, e.g.: +<number> is the configuration's number, e.g.:: -$ mkdir configs/c.1 + $ mkdir configs/c.1 -... -... -... + ... + ... + ... Each configuration also needs its strings, so a subdirectory must be created -for each language, e.g.: +for each language, e.g.:: -$ mkdir configs/c.1/strings/0x409 + $ mkdir configs/c.1/strings/0x409 -Then the configuration string can be specified: +Then the configuration string can be specified:: -$ echo <configuration> > configs/c.1/strings/0x409/configuration + $ echo <configuration> > configs/c.1/strings/0x409/configuration -Some attributes can also be set for a configuration, e.g.: +Some attributes can also be set for a configuration, e.g.:: -$ echo 120 > configs/c.1/MaxPower + $ echo 120 > configs/c.1/MaxPower 3. Creating the functions ------------------------- The gadget will provide some functions, for each function its corresponding -directory must be created: +directory must be created:: -$ mkdir functions/<name>.<instance name> + $ mkdir functions/<name>.<instance name> where <name> corresponds to one of allowed function names and instance name -is an arbitrary string allowed in a filesystem, e.g.: +is an arbitrary string allowed in a filesystem, e.g.:: -$ mkdir functions/ncm.usb0 # usb_f_ncm.ko gets loaded with request_module() + $ mkdir functions/ncm.usb0 # usb_f_ncm.ko gets loaded with request_module() -... -... -... + ... + ... + ... Each function provides its specific set of attributes, with either read-only or read-write access. Where applicable they need to be written to as @@ -149,17 +149,17 @@ At this moment a number of gadgets is created, each of which has a number of configurations specified and a number of functions available. What remains is specifying which function is available in which configuration (the same function can be used in multiple configurations). This is achieved with -creating symbolic links: +creating symbolic links:: -$ ln -s functions/<name>.<instance name> configs/<name>.<number> + $ ln -s functions/<name>.<instance name> configs/<name>.<number> -e.g.: +e.g.:: -$ ln -s functions/ncm.usb0 configs/c.1 + $ ln -s functions/ncm.usb0 configs/c.1 -... -... -... + ... + ... + ... 5. Enabling the gadget ---------------------- @@ -167,123 +167,127 @@ $ ln -s functions/ncm.usb0 configs/c.1 All the above steps serve the purpose of composing the gadget of configurations and functions. -An example directory structure might look like this: - -. -./strings -./strings/0x409 -./strings/0x409/serialnumber -./strings/0x409/product -./strings/0x409/manufacturer -./configs -./configs/c.1 -./configs/c.1/ncm.usb0 -> ../../../../usb_gadget/g1/functions/ncm.usb0 -./configs/c.1/strings -./configs/c.1/strings/0x409 -./configs/c.1/strings/0x409/configuration -./configs/c.1/bmAttributes -./configs/c.1/MaxPower -./functions -./functions/ncm.usb0 -./functions/ncm.usb0/ifname -./functions/ncm.usb0/qmult -./functions/ncm.usb0/host_addr -./functions/ncm.usb0/dev_addr -./UDC -./bcdUSB -./bcdDevice -./idProduct -./idVendor -./bMaxPacketSize0 -./bDeviceProtocol -./bDeviceSubClass -./bDeviceClass +An example directory structure might look like this:: + + . + ./strings + ./strings/0x409 + ./strings/0x409/serialnumber + ./strings/0x409/product + ./strings/0x409/manufacturer + ./configs + ./configs/c.1 + ./configs/c.1/ncm.usb0 -> ../../../../usb_gadget/g1/functions/ncm.usb0 + ./configs/c.1/strings + ./configs/c.1/strings/0x409 + ./configs/c.1/strings/0x409/configuration + ./configs/c.1/bmAttributes + ./configs/c.1/MaxPower + ./functions + ./functions/ncm.usb0 + ./functions/ncm.usb0/ifname + ./functions/ncm.usb0/qmult + ./functions/ncm.usb0/host_addr + ./functions/ncm.usb0/dev_addr + ./UDC + ./bcdUSB + ./bcdDevice + ./idProduct + ./idVendor + ./bMaxPacketSize0 + ./bDeviceProtocol + ./bDeviceSubClass + ./bDeviceClass Such a gadget must be finally enabled so that the USB host can enumerate it. -In order to enable the gadget it must be bound to a UDC (USB Device Controller). -$ echo <udc name> > UDC +In order to enable the gadget it must be bound to a UDC (USB Device +Controller):: + + $ echo <udc name> > UDC where <udc name> is one of those found in /sys/class/udc/* -e.g.: +e.g.:: -$ echo s3c-hsotg > UDC + $ echo s3c-hsotg > UDC 6. Disabling the gadget ----------------------- -$ echo "" > UDC +:: + + $ echo "" > UDC 7. Cleaning up -------------- -Remove functions from configurations: +Remove functions from configurations:: -$ rm configs/<config name>.<number>/<function> + $ rm configs/<config name>.<number>/<function> where <config name>.<number> specify the configuration and <function> is -a symlink to a function being removed from the configuration, e.g.: +a symlink to a function being removed from the configuration, e.g.:: -$ rm configs/c.1/ncm.usb0 + $ rm configs/c.1/ncm.usb0 -... -... -... + ... + ... + ... -Remove strings directories in configurations +Remove strings directories in configurations: -$ rmdir configs/<config name>.<number>/strings/<lang> + $ rmdir configs/<config name>.<number>/strings/<lang> -e.g.: +e.g.:: -$ rmdir configs/c.1/strings/0x409 + $ rmdir configs/c.1/strings/0x409 -... -... -... + ... + ... + ... -and remove the configurations +and remove the configurations:: -$ rmdir configs/<config name>.<number> + $ rmdir configs/<config name>.<number> -e.g.: +e.g.:: -rmdir configs/c.1 + rmdir configs/c.1 -... -... -... + ... + ... + ... -Remove functions (function modules are not unloaded, though) +Remove functions (function modules are not unloaded, though): -$ rmdir functions/<name>.<instance name> + $ rmdir functions/<name>.<instance name> -e.g.: +e.g.:: -$ rmdir functions/ncm.usb0 + $ rmdir functions/ncm.usb0 -... -... -... + ... + ... + ... -Remove strings directories in the gadget +Remove strings directories in the gadget:: -$ rmdir strings/<lang> + $ rmdir strings/<lang> -e.g.: +e.g.:: -$ rmdir strings/0x409 + $ rmdir strings/0x409 -and finally remove the gadget: +and finally remove the gadget:: -$ cd .. -$ rmdir <gadget name> + $ cd .. + $ rmdir <gadget name> -e.g.: +e.g.:: -$ rmdir g1 + $ rmdir g1 @@ -305,16 +309,16 @@ configured elements. However, they are embedded in usage-specific larger structures. In the picture below there is a "cs" which contains a config_item and an "sa" which contains a configfs_attribute. -The filesystem view would be like this: +The filesystem view would be like this:: -./ -./cs (directory) - | - +--sa (file) - | - . - . - . + ./ + ./cs (directory) + | + +--sa (file) + | + . + . + . Whenever a user reads/writes the "sa" file, a function is called which accepts a struct config_item and a struct configfs_attribute. @@ -326,29 +330,31 @@ buffer), while the "store" is for modifying the file's contents (copy data from the buffer to the cs), but it is up to the implementer of the two functions to decide what they actually do. -typedef struct configured_structure cs; -typedef struct specific_attribute sa; - - sa - +----------------------------------+ - cs | (*show)(cs *, buffer); | -+-----------------+ | (*store)(cs *, buffer, length); | -| | | | -| +-------------+ | | +------------------+ | -| | struct |-|----|------>|struct | | -| | config_item | | | |configfs_attribute| | -| +-------------+ | | +------------------+ | -| | +----------------------------------+ -| data to be set | . -| | . -+-----------------+ . +:: + + typedef struct configured_structure cs; + typedef struct specific_attribute sa; + + sa + +----------------------------------+ + cs | (*show)(cs *, buffer); | + +-----------------+ | (*store)(cs *, buffer, length); | + | | | | + | +-------------+ | | +------------------+ | + | | struct |-|----|------>|struct | | + | | config_item | | | |configfs_attribute| | + | +-------------+ | | +------------------+ | + | | +----------------------------------+ + | data to be set | . + | | . + +-----------------+ . The file names are decided by the config item/group designer, while the directories in general can be named at will. A group can have a number of its default sub-groups created automatically. For more information on configfs please see -Documentation/filesystems/configfs/*. +`Documentation/filesystems/configfs/*`. The concepts described above translate to USB gadgets like this: diff --git a/Documentation/usb/gadget_hid.txt b/Documentation/usb/gadget_hid.txt index 7a0fb8e16e27..098d563040cc 100644 --- a/Documentation/usb/gadget_hid.txt +++ b/Documentation/usb/gadget_hid.txt @@ -1,28 +1,31 @@ - - Linux USB HID gadget driver +=========================== +Linux USB HID gadget driver +=========================== Introduction +============ - The HID Gadget driver provides emulation of USB Human Interface - Devices (HID). The basic HID handling is done in the kernel, - and HID reports can be sent/received through I/O on the - /dev/hidgX character devices. +The HID Gadget driver provides emulation of USB Human Interface +Devices (HID). The basic HID handling is done in the kernel, +and HID reports can be sent/received through I/O on the +/dev/hidgX character devices. - For more details about HID, see the developer page on - http://www.usb.org/developers/hidpage/ +For more details about HID, see the developer page on +http://www.usb.org/developers/hidpage/ Configuration +============= - g_hid is a platform driver, so to use it you need to add - struct platform_device(s) to your platform code defining the - HID function descriptors you want to use - E.G. something - like: +g_hid is a platform driver, so to use it you need to add +struct platform_device(s) to your platform code defining the +HID function descriptors you want to use - E.G. something +like:: -#include <linux/platform_device.h> -#include <linux/usb/g_hid.h> + #include <linux/platform_device.h> + #include <linux/usb/g_hid.h> -/* hid descriptor for a keyboard */ -static struct hidg_func_descriptor my_hid_data = { + /* hid descriptor for a keyboard */ + static struct hidg_func_descriptor my_hid_data = { .subclass = 0, /* No subclass */ .protocol = 1, /* Keyboard */ .report_length = 8, @@ -61,85 +64,87 @@ static struct hidg_func_descriptor my_hid_data = { 0x81, 0x00, /* INPUT (Data,Ary,Abs) */ 0xc0 /* END_COLLECTION */ } -}; + }; -static struct platform_device my_hid = { + static struct platform_device my_hid = { .name = "hidg", .id = 0, .num_resources = 0, .resource = 0, .dev.platform_data = &my_hid_data, -}; + }; - You can add as many HID functions as you want, only limited by - the amount of interrupt endpoints your gadget driver supports. +You can add as many HID functions as you want, only limited by +the amount of interrupt endpoints your gadget driver supports. Configuration with configfs +=========================== - Instead of adding fake platform devices and drivers in order to pass - some data to the kernel, if HID is a part of a gadget composed with - configfs the hidg_func_descriptor.report_desc is passed to the kernel - by writing the appropriate stream of bytes to a configfs attribute. +Instead of adding fake platform devices and drivers in order to pass +some data to the kernel, if HID is a part of a gadget composed with +configfs the hidg_func_descriptor.report_desc is passed to the kernel +by writing the appropriate stream of bytes to a configfs attribute. Send and receive HID reports +============================ - HID reports can be sent/received using read/write on the - /dev/hidgX character devices. See below for an example program - to do this. +HID reports can be sent/received using read/write on the +/dev/hidgX character devices. See below for an example program +to do this. - hid_gadget_test is a small interactive program to test the HID - gadget driver. To use, point it at a hidg device and set the - device type (keyboard / mouse / joystick) - E.G.: +hid_gadget_test is a small interactive program to test the HID +gadget driver. To use, point it at a hidg device and set the +device type (keyboard / mouse / joystick) - E.G.:: - # hid_gadget_test /dev/hidg0 keyboard + # hid_gadget_test /dev/hidg0 keyboard - You are now in the prompt of hid_gadget_test. You can type any - combination of options and values. Available options and - values are listed at program start. In keyboard mode you can - send up to six values. +You are now in the prompt of hid_gadget_test. You can type any +combination of options and values. Available options and +values are listed at program start. In keyboard mode you can +send up to six values. - For example type: g i s t r --left-shift +For example type: g i s t r --left-shift - Hit return and the corresponding report will be sent by the - HID gadget. +Hit return and the corresponding report will be sent by the +HID gadget. - Another interesting example is the caps lock test. Type - --caps-lock and hit return. A report is then sent by the - gadget and you should receive the host answer, corresponding - to the caps lock LED status. +Another interesting example is the caps lock test. Type +--caps-lock and hit return. A report is then sent by the +gadget and you should receive the host answer, corresponding +to the caps lock LED status:: - --caps-lock - recv report:2 + --caps-lock + recv report:2 - With this command: +With this command:: - # hid_gadget_test /dev/hidg1 mouse + # hid_gadget_test /dev/hidg1 mouse - You can test the mouse emulation. Values are two signed numbers. +You can test the mouse emulation. Values are two signed numbers. -Sample code +Sample code:: -/* hid_gadget_test */ + /* hid_gadget_test */ -#include <pthread.h> -#include <string.h> -#include <stdio.h> -#include <ctype.h> -#include <fcntl.h> -#include <errno.h> -#include <stdio.h> -#include <stdlib.h> -#include <unistd.h> + #include <pthread.h> + #include <string.h> + #include <stdio.h> + #include <ctype.h> + #include <fcntl.h> + #include <errno.h> + #include <stdio.h> + #include <stdlib.h> + #include <unistd.h> -#define BUF_LEN 512 + #define BUF_LEN 512 -struct options { + struct options { const char *opt; unsigned char val; -}; + }; -static struct options kmod[] = { + static struct options kmod[] = { {.opt = "--left-ctrl", .val = 0x01}, {.opt = "--right-ctrl", .val = 0x10}, {.opt = "--left-shift", .val = 0x02}, @@ -149,9 +154,9 @@ static struct options kmod[] = { {.opt = "--left-meta", .val = 0x08}, {.opt = "--right-meta", .val = 0x80}, {.opt = NULL} -}; + }; -static struct options kval[] = { + static struct options kval[] = { {.opt = "--return", .val = 0x28}, {.opt = "--esc", .val = 0x29}, {.opt = "--bckspc", .val = 0x2a}, @@ -183,10 +188,10 @@ static struct options kval[] = { {.opt = "--up", .val = 0x52}, {.opt = "--num-lock", .val = 0x53}, {.opt = NULL} -}; + }; -int keyboard_fill_report(char report[8], char buf[BUF_LEN], int *hold) -{ + int keyboard_fill_report(char report[8], char buf[BUF_LEN], int *hold) + { char *tok = strtok(buf, " "); int key = 0; int i = 0; @@ -229,17 +234,17 @@ int keyboard_fill_report(char report[8], char buf[BUF_LEN], int *hold) fprintf(stderr, "unknown option: %s\n", tok); } return 8; -} + } -static struct options mmod[] = { + static struct options mmod[] = { {.opt = "--b1", .val = 0x01}, {.opt = "--b2", .val = 0x02}, {.opt = "--b3", .val = 0x04}, {.opt = NULL} -}; + }; -int mouse_fill_report(char report[8], char buf[BUF_LEN], int *hold) -{ + int mouse_fill_report(char report[8], char buf[BUF_LEN], int *hold) + { char *tok = strtok(buf, " "); int mvt = 0; int i = 0; @@ -274,9 +279,9 @@ int mouse_fill_report(char report[8], char buf[BUF_LEN], int *hold) fprintf(stderr, "unknown option: %s\n", tok); } return 3; -} + } -static struct options jmod[] = { + static struct options jmod[] = { {.opt = "--b1", .val = 0x10}, {.opt = "--b2", .val = 0x20}, {.opt = "--b3", .val = 0x40}, @@ -287,10 +292,10 @@ static struct options jmod[] = { {.opt = "--hat4", .val = 0x03}, {.opt = "--hatneutral", .val = 0x04}, {.opt = NULL} -}; + }; -int joystick_fill_report(char report[8], char buf[BUF_LEN], int *hold) -{ + int joystick_fill_report(char report[8], char buf[BUF_LEN], int *hold) + { char *tok = strtok(buf, " "); int mvt = 0; int i = 0; @@ -326,10 +331,10 @@ int joystick_fill_report(char report[8], char buf[BUF_LEN], int *hold) fprintf(stderr, "unknown option: %s\n", tok); } return 4; -} + } -void print_options(char c) -{ + void print_options(char c) + { int i = 0; if (c == 'k') { @@ -358,10 +363,10 @@ void print_options(char c) " three signed numbers\n" "--quit to close\n"); } -} + } -int main(int argc, const char *argv[]) -{ + int main(int argc, const char *argv[]) + { const char *filename = NULL; int fd = 0; char buf[BUF_LEN]; @@ -449,4 +454,4 @@ int main(int argc, const char *argv[]) close(fd); return 0; -} + } diff --git a/Documentation/usb/gadget_multi.txt b/Documentation/usb/gadget_multi.txt index b3146dd7aa43..9806b55af301 100644 --- a/Documentation/usb/gadget_multi.txt +++ b/Documentation/usb/gadget_multi.txt @@ -1,6 +1,9 @@ - -*- org -*- +============================== +Multifunction Composite Gadget +============================== -* Overview +Overview +======== The Multifunction Composite Gadget (or g_multi) is a composite gadget that makes extensive use of the composite framework to provide @@ -17,13 +20,15 @@ have two configurations -- one with RNDIS and another with CDC ECM[3]. Please note that if you use non-standard configuration (that is enable CDC ECM) you may need to change vendor and/or product ID. -* Host drivers +Host drivers +============ To make use of the gadget one needs to make it work on host side -- without that there's no hope of achieving anything with the gadget. As one might expect, things one need to do very from system to system. -** Linux host drivers +Linux host drivers +------------------ Since the gadget uses standard composite framework and appears as such to Linux host it does not need any additional drivers on Linux host @@ -34,11 +39,13 @@ This is also true for two configuration set-up with RNDIS configuration being the first one. Linux host will use the second configuration with CDC ECM which should work better under Linux. -** Windows host drivers +Windows host drivers +-------------------- For the gadget to work under Windows two conditions have to be met: -*** Detecting as composite gadget +Detecting as composite gadget +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ First of all, Windows need to detect the gadget as an USB composite gadget which on its own have some conditions[4]. If they are met, @@ -53,7 +60,8 @@ The only thing to worry is that the gadget has to have a single configuration so a dual RNDIS and CDC ECM gadget won't work unless you create a proper INF -- and of course, if you do submit it! -*** Installing drivers for each function +Installing drivers for each function +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The other, trickier thing is making Windows install drivers for each individual function. @@ -63,7 +71,8 @@ implementing USB Mass Storage class and selects appropriate driver. Things are harder with RDNIS and CDC ACM. -**** RNDIS +RNDIS +..... To make Windows select RNDIS drivers for the first function in the gadget, one needs to use the [[file:linux.inf]] file provided with this @@ -75,11 +84,13 @@ RNDIS was not the first interface. You do not need to worry abut it unless you are trying to develop your own gadget in which case watch out for this bug. -**** CDC ACM +CDC ACM +....... Similarly, [[file:linux-cdc-acm.inf]] is provided for CDC ACM. -**** Customising the gadget +Customising the gadget +...................... If you intend to hack the g_multi gadget be advised that rearranging functions will obviously change interface numbers for each of the @@ -97,14 +108,16 @@ things don't work as intended before realising Windows have cached some drivers information (changing USB port may sometimes help plus you might try using USBDeview[8] to remove the phantom device). -**** INF testing +INF testing +........... Provided INF files have been tested on Windows XP SP3, Windows Vista and Windows 7, all 32-bit versions. It should work on 64-bit versions as well. It most likely won't work on Windows prior to Windows XP SP2. -** Other systems +Other systems +------------- At this moment, drivers for any other systems have not been tested. Knowing how MacOS is based on BSD and BSD is an Open Source it is @@ -115,7 +128,8 @@ For more exotic systems I have even less to say... Any testing and drivers *are* *welcome*! -* Authors +Authors +======= This document has been written by Michal Nazarewicz ([[mailto:mina86@mina86.com]]). INF files have been hacked with @@ -124,7 +138,8 @@ Xiaofan Chen ([[mailto:xiaofanc@gmail.com]]) basing on the MS RNDIS template[9], Microchip's CDC ACM INF file and David Brownell's ([[mailto:dbrownell@users.sourceforge.net]]) original INF files. -* Footnotes +Footnotes +========= [1] Remote Network Driver Interface Specification, [[http://msdn.microsoft.com/en-us/library/ee484414.aspx]]. diff --git a/Documentation/usb/gadget_printer.txt b/Documentation/usb/gadget_printer.txt index ad995bf0db41..5e5516c69075 100644 --- a/Documentation/usb/gadget_printer.txt +++ b/Documentation/usb/gadget_printer.txt @@ -1,12 +1,14 @@ +=============================== +Linux USB Printer Gadget Driver +=============================== - Linux USB Printer Gadget Driver - 06/04/2007 +06/04/2007 - Copyright (C) 2007 Craig W. Nadler <craig@nadler.us> +Copyright (C) 2007 Craig W. Nadler <craig@nadler.us> -GENERAL +General ======= This driver may be used if you are writing printer firmware using Linux as @@ -29,52 +31,60 @@ user space firmware can read or write this status byte using a device file -HOWTO USE THIS DRIVER +Howto Use This Driver ===================== To load the USB device controller driver and the printer gadget driver. The -following example uses the Netchip 2280 USB device controller driver: +following example uses the Netchip 2280 USB device controller driver:: -modprobe net2280 -modprobe g_printer + modprobe net2280 + modprobe g_printer The follow command line parameter can be used when loading the printer gadget (ex: modprobe g_printer idVendor=0x0525 idProduct=0xa4a8 ): -idVendor - This is the Vendor ID used in the device descriptor. The default is +idVendor + This is the Vendor ID used in the device descriptor. The default is the Netchip vendor id 0x0525. YOU MUST CHANGE TO YOUR OWN VENDOR ID BEFORE RELEASING A PRODUCT. If you plan to release a product and don't already have a Vendor ID please see www.usb.org for details on how to get one. -idProduct - This is the Product ID used in the device descriptor. The default +idProduct + This is the Product ID used in the device descriptor. The default is 0xa4a8, you should change this to an ID that's not used by any of your other USB products if you have any. It would be a good idea to start numbering your products starting with say 0x0001. -bcdDevice - This is the version number of your product. It would be a good idea +bcdDevice + This is the version number of your product. It would be a good idea to put your firmware version here. -iManufacturer - A string containing the name of the Vendor. +iManufacturer + A string containing the name of the Vendor. -iProduct - A string containing the Product Name. +iProduct + A string containing the Product Name. -iSerialNum - A string containing the Serial Number. This should be changed for +iSerialNum + A string containing the Serial Number. This should be changed for each unit of your product. -iPNPstring - The PNP ID string used for this printer. You will want to set +iPNPstring + The PNP ID string used for this printer. You will want to set either on the command line or hard code the PNP ID string used for your printer product. -qlen - The number of 8k buffers to use per endpoint. The default is 10, you +qlen + The number of 8k buffers to use per endpoint. The default is 10, you should tune this for your product. You may also want to tune the size of each buffer for your product. -USING THE EXAMPLE CODE +Using The Example Code ====================== This example code talks to stdout, instead of a print engine. @@ -82,22 +92,23 @@ This example code talks to stdout, instead of a print engine. To compile the test code below: 1) save it to a file called prn_example.c -2) compile the code with the follow command: +2) compile the code with the follow command:: + gcc prn_example.c -o prn_example -To read printer data from the host to stdout: +To read printer data from the host to stdout:: # prn_example -read_data -To write printer data from a file (data_file) to the host: +To write printer data from a file (data_file) to the host:: # cat data_file | prn_example -write_data -To get the current printer status for the gadget driver: +To get the current printer status for the gadget driver::: # prn_example -get_status @@ -107,60 +118,62 @@ To get the current printer status for the gadget driver: Printer OK -To set printer to Selected/On-line: +To set printer to Selected/On-line:: # prn_example -selected -To set printer to Not Selected/Off-line: +To set printer to Not Selected/Off-line:: # prn_example -not_selected -To set paper status to paper out: +To set paper status to paper out:: # prn_example -paper_out -To set paper status to paper loaded: +To set paper status to paper loaded:: # prn_example -paper_loaded -To set error status to printer OK: +To set error status to printer OK:: # prn_example -no_error -To set error status to ERROR: +To set error status to ERROR:: # prn_example -error -EXAMPLE CODE +Example Code ============ +:: + -#include <stdio.h> -#include <stdlib.h> -#include <fcntl.h> -#include <linux/poll.h> -#include <sys/ioctl.h> -#include <linux/usb/g_printer.h> + #include <stdio.h> + #include <stdlib.h> + #include <fcntl.h> + #include <linux/poll.h> + #include <sys/ioctl.h> + #include <linux/usb/g_printer.h> -#define PRINTER_FILE "/dev/g_printer" -#define BUF_SIZE 512 + #define PRINTER_FILE "/dev/g_printer" + #define BUF_SIZE 512 -/* - * 'usage()' - Show program usage. - */ + /* + * 'usage()' - Show program usage. + */ -static void -usage(const char *option) /* I - Option string or NULL */ -{ + static void + usage(const char *option) /* I - Option string or NULL */ + { if (option) { fprintf(stderr,"prn_example: Unknown option \"%s\"!\n", option); @@ -186,12 +199,12 @@ usage(const char *option) /* I - Option string or NULL */ fputs("\n\n", stderr); exit(1); -} + } -static int -read_printer_data() -{ + static int + read_printer_data() + { struct pollfd fd[1]; /* Open device file for printer gadget. */ @@ -236,12 +249,12 @@ read_printer_data() close(fd[0].fd); return 0; -} + } -static int -write_printer_data() -{ + static int + write_printer_data() + { struct pollfd fd[1]; /* Open device file for printer gadget. */ @@ -295,12 +308,12 @@ write_printer_data() close(fd[0].fd); return 0; -} + } -static int -read_NB_printer_data() -{ + static int + read_NB_printer_data() + { int fd; static char buf[BUF_SIZE]; int bytes_read; @@ -329,12 +342,12 @@ read_NB_printer_data() close(fd); return 0; -} + } -static int -get_printer_status() -{ + static int + get_printer_status() + { int retval; int fd; @@ -357,12 +370,12 @@ get_printer_status() close(fd); return(retval); -} + } -static int -set_printer_status(unsigned char buf, int clear_printer_status_bit) -{ + static int + set_printer_status(unsigned char buf, int clear_printer_status_bit) + { int retval; int fd; @@ -397,12 +410,12 @@ set_printer_status(unsigned char buf, int clear_printer_status_bit) close(fd); return 0; -} + } -static int -display_printer_status() -{ + static int + display_printer_status() + { char printer_status; printer_status = get_printer_status(); @@ -429,12 +442,12 @@ display_printer_status() } return(0); -} + } -int -main(int argc, char *argv[]) -{ + int + main(int argc, char *argv[]) + { int i; /* Looping var */ int retval = 0; @@ -507,4 +520,4 @@ main(int argc, char *argv[]) } exit(retval); -} + } diff --git a/Documentation/usb/gadget_serial.txt b/Documentation/usb/gadget_serial.txt index d1def3186782..dce8bc1fb1f2 100644 --- a/Documentation/usb/gadget_serial.txt +++ b/Documentation/usb/gadget_serial.txt @@ -1,7 +1,10 @@ +=============================== +Linux Gadget Serial Driver v2.0 +=============================== - Linux Gadget Serial Driver v2.0 - 11/20/2004 - (updated 8-May-2008 for v2.3) +11/20/2004 + +(updated 8-May-2008 for v2.3) License and Disclaimer @@ -56,7 +59,7 @@ hardware; for example, a PDA, an embedded Linux system, or a PC with a USB development card. The gadget serial driver talks over USB to either a CDC ACM driver -or a generic USB serial driver running on a host PC. +or a generic USB serial driver running on a host PC:: Host -------------------------------------- @@ -112,11 +115,11 @@ configuring the kernel. Then rebuild and install the kernel or modules. Then you must load the gadget serial driver. To load it as an -ACM device (recommended for interoperability), do this: +ACM device (recommended for interoperability), do this:: modprobe g_serial -To load it as a vendor specific bulk in/out device, do this: +To load it as a vendor specific bulk in/out device, do this:: modprobe g_serial use_acm=0 @@ -127,7 +130,7 @@ desired. Your system should use mdev (from busybox) or udev to make the device nodes. After this gadget driver has been set up you should -then see a /dev/ttyGS0 node: +then see a /dev/ttyGS0 node:: # ls -l /dev/ttyGS0 | cat crw-rw---- 1 root root 253, 0 May 8 14:10 /dev/ttyGS0 @@ -187,24 +190,24 @@ support". Once the gadget serial driver is loaded and the USB device connected to the Linux host with a USB cable, the host system should recognize -the gadget serial device. For example, the command +the gadget serial device. For example, the command:: cat /sys/kernel/debug/usb/devices -should show something like this: - -T: Bus=01 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#= 5 Spd=480 MxCh= 0 -D: Ver= 2.00 Cls=02(comm.) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 -P: Vendor=0525 ProdID=a4a7 Rev= 2.01 -S: Manufacturer=Linux 2.6.8.1 with net2280 -S: Product=Gadget Serial -S: SerialNumber=0 -C:* #Ifs= 2 Cfg#= 2 Atr=c0 MxPwr= 2mA -I: If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=02 Prot=01 Driver=acm -E: Ad=83(I) Atr=03(Int.) MxPS= 8 Ivl=32ms -I: If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=acm -E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms -E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms +should show something like this::: + + T: Bus=01 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#= 5 Spd=480 MxCh= 0 + D: Ver= 2.00 Cls=02(comm.) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 + P: Vendor=0525 ProdID=a4a7 Rev= 2.01 + S: Manufacturer=Linux 2.6.8.1 with net2280 + S: Product=Gadget Serial + S: SerialNumber=0 + C:* #Ifs= 2 Cfg#= 2 Atr=c0 MxPwr= 2mA + I: If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=02 Prot=01 Driver=acm + E: Ad=83(I) Atr=03(Int.) MxPS= 8 Ivl=32ms + I: If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=acm + E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms + E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms If the host side Linux system is configured properly, the ACM driver should be loaded automatically. The command "lsmod" should show the @@ -219,29 +222,29 @@ Serial Converter support", and for the "USB Generic Serial Driver". Once the gadget serial driver is loaded and the USB device connected to the Linux host with a USB cable, the host system should recognize -the gadget serial device. For example, the command +the gadget serial device. For example, the command:: cat /sys/kernel/debug/usb/devices -should show something like this: +should show something like this::: -T: Bus=01 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#= 6 Spd=480 MxCh= 0 -D: Ver= 2.00 Cls=ff(vend.) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 -P: Vendor=0525 ProdID=a4a6 Rev= 2.01 -S: Manufacturer=Linux 2.6.8.1 with net2280 -S: Product=Gadget Serial -S: SerialNumber=0 -C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr= 2mA -I: If#= 0 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=serial -E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms -E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms + T: Bus=01 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#= 6 Spd=480 MxCh= 0 + D: Ver= 2.00 Cls=ff(vend.) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 + P: Vendor=0525 ProdID=a4a6 Rev= 2.01 + S: Manufacturer=Linux 2.6.8.1 with net2280 + S: Product=Gadget Serial + S: SerialNumber=0 + C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr= 2mA + I: If#= 0 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=serial + E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms + E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms You must load the usbserial driver and explicitly set its parameters -to configure it to recognize the gadget serial device, like this: +to configure it to recognize the gadget serial device, like this:: echo 0x0525 0xA4A6 >/sys/bus/usb-serial/drivers/generic/new_id -The legacy way is to use module parameters: +The legacy way is to use module parameters:: modprobe usbserial vendor=0x0525 product=0xA4A6 diff --git a/Documentation/usb/iuu_phoenix.txt b/Documentation/usb/iuu_phoenix.txt index e5f048067da4..b76268728450 100644 --- a/Documentation/usb/iuu_phoenix.txt +++ b/Documentation/usb/iuu_phoenix.txt @@ -1,5 +1,6 @@ +============================= Infinity Usb Unlimited Readme ------------------------------ +============================= Hi all, @@ -19,7 +20,8 @@ have his own device file(/dev/ttyUSB0,/dev/ttyUSB1,...) -How to tune the reader speed ? +How to tune the reader speed? +============================= A few parameters can be used at load time To use parameters, just unload the module if it is @@ -27,26 +29,33 @@ How to tune the reader speed ? In case of prebuilt module, use the command insmod iuu_phoenix param=value. - Example: + Example:: - modprobe iuu_phoenix clockmode=3 + modprobe iuu_phoenix clockmode=3 The parameters are: - parm: clockmode:1=3Mhz579,2=3Mhz680,3=6Mhz (int) - parm: boost:overclock boost percent 100 to 500 (int) - parm: cdmode:Card detect mode 0=none, 1=CD, 2=!CD, 3=DSR, 4=!DSR, 5=CTS, 6=!CTS, 7=RING, 8=!RING (int) - parm: xmas:xmas color enabled or not (bool) - parm: debug:Debug enabled or not (bool) +clockmode: + 1=3Mhz579,2=3Mhz680,3=6Mhz (int) +boost: + overclock boost percent 100 to 500 (int) +cdmode: + Card detect mode + 0=none, 1=CD, 2=!CD, 3=DSR, 4=!DSR, 5=CTS, 6=!CTS, 7=RING, 8=!RING (int) +xmas: + xmas color enabled or not (bool) +debug: + Debug enabled or not (bool) - clockmode will provide 3 different base settings commonly adopted by different software: - 1. 3Mhz579 + + 1. 3Mhz579 2. 3Mhz680 3. 6Mhz - boost provide a way to overclock the reader ( my favorite :-) ) - For example to have best performance than a simple clockmode=3, try this: + For example to have best performance than a simple clockmode=3, try this:: modprobe boost=195 @@ -66,7 +75,8 @@ How to tune the reader speed ? - debug will produce a lot of debugging messages... - Last notes: +Last notes +========== Don't worry about the serial settings, the serial emulation is an abstraction, so use any speed or parity setting will diff --git a/Documentation/usb/mass-storage.txt b/Documentation/usb/mass-storage.txt index e89803a5a960..d181b47c3cb6 100644 --- a/Documentation/usb/mass-storage.txt +++ b/Documentation/usb/mass-storage.txt @@ -1,4 +1,9 @@ -* Overview +========================= +Mass Storage Gadget (MSG) +========================= + +Overview +======== Mass Storage Gadget (or MSG) acts as a USB Mass Storage device, appearing to the host as a disk or a CD-ROM drive. It supports @@ -24,7 +29,8 @@ (which is no longer included in Linux). It will talk only briefly about how to use MSF within composite gadgets. -* Module parameters +Module parameters +================= The mass storage gadget accepts the following mass storage specific module parameters: @@ -146,7 +152,8 @@ - iProduct -- USB Product string (string) - iSerialNumber -- SerialNumber string (sting) -* sysfs entries +sysfs entries +============= For each logical unit, the gadget creates a directory in the sysfs hierarchy. Inside of it the following three files are created: @@ -177,7 +184,8 @@ Other then those, as usual, the values of module parameters can be read from /sys/module/g_mass_storage/parameters/* files. -* Other gadgets using mass storage function +Other gadgets using mass storage function +========================================= The Mass Storage Gadget uses the Mass Storage Function to handle mass storage protocol. As a composite function, MSF may be used by @@ -193,7 +201,8 @@ may take a look at mass_storage.c, acm_ms.c and multi.c (sorted by complexity). -* Relation to file storage gadget +Relation to file storage gadget +=============================== The Mass Storage Function and thus the Mass Storage Gadget has been based on the File Storage Gadget. The difference between the two is diff --git a/Documentation/usb/misc_usbsevseg.txt b/Documentation/usb/misc_usbsevseg.txt index 0f6be4f9930b..6274aee083ed 100644 --- a/Documentation/usb/misc_usbsevseg.txt +++ b/Documentation/usb/misc_usbsevseg.txt @@ -1,4 +1,7 @@ +============================= USB 7-Segment Numeric Display +============================= + Manufactured by Delcom Engineering Device Information @@ -13,9 +16,13 @@ Device Modes ------------ By default, the driver assumes the display is only 6 characters The mode for 6 characters is: + MSB 0x06; LSB 0x3f + For the 8 character display: + MSB 0x08; LSB 0xff + The device can accept "text" either in raw, hex, or ascii textmode. raw controls each segment manually, hex expects a value between 0-15 per character, @@ -42,5 +49,3 @@ Device Operation To set multiple decimals points sum up each power. For example, to set the 0th and 3rd decimal place echo 1001 > /sys/bus/usb/.../decimals - - diff --git a/Documentation/usb/mtouchusb.txt b/Documentation/usb/mtouchusb.txt index a91adb26ea7b..d1111b74bf75 100644 --- a/Documentation/usb/mtouchusb.txt +++ b/Documentation/usb/mtouchusb.txt @@ -1,19 +1,27 @@ -CHANGES +================ +mtouchusb driver +================ + +Changes +======= - 0.3 - Created based off of scanner & INSTALL from the original touchscreen driver on freecode (http://freecode.com/projects/3mtouchscreendriver) - Amended for linux-2.4.18, then 2.4.19 - 0.5 - Complete rewrite using Linux Input in 2.6.3 - Unfortunately no calibration support at this time + Unfortunately no calibration support at this time - 1.4 - Multiple changes to support the EXII 5000UC and house cleaning - Changed reset from standard USB dev reset to vendor reset - Changed data sent to host from compensated to raw coordinates - Eliminated vendor/product module params - Performed multiple successful tests with an EXII-5010UC + Changed reset from standard USB dev reset to vendor reset + Changed data sent to host from compensated to raw coordinates + Eliminated vendor/product module params + Performed multiple successful tests with an EXII-5010UC + +Supported Hardware +================== -SUPPORTED HARDWARE: +:: All controllers have the Vendor: 0x0596 & Product: 0x0001 @@ -29,9 +37,10 @@ SUPPORTED HARDWARE: USB Capacitive - Black Case EXII-5030UC USB Capacitive - No Case EXII-5050UC -DRIVER NOTES: +Driver Notes +============ -Installation is simple, you only need to add Linux Input, Linux USB, and the +Installation is simple, you only need to add Linux Input, Linux USB, and the driver to the kernel. The driver can also be optionally built as a module. This driver appears to be one of possible 2 Linux USB Input Touchscreen @@ -49,24 +58,27 @@ The controller screen resolution is now 0 to 16384 for both X and Y reporting the raw touch data. This is the same for the old and new capacitive USB controllers. -Perhaps at some point an abstract function will be placed into evdev so -generic functions like calibrations, resets, and vendor information can be +Perhaps at some point an abstract function will be placed into evdev so +generic functions like calibrations, resets, and vendor information can be requested from the userspace (And the drivers would handle the vendor specific tasks). -TODO: +TODO +==== Implement a control urb again to handle requests to and from the device such as calibration, etc once/if it becomes available. -DISCLAIMER: +Disclaimer +========== -I am not a MicroTouch/3M employee, nor have I ever been. 3M does not support +I am not a MicroTouch/3M employee, nor have I ever been. 3M does not support this driver! If you want touch drivers only supported within X, please go to: http://www.3m.com/3MTouchSystems/ -THANKS: +Thanks +====== A huge thank you to 3M Touch Systems for the EXII-5010UC controllers for testing! diff --git a/Documentation/usb/ohci.txt b/Documentation/usb/ohci.txt index 99320d9fa523..bb3c49719e6b 100644 --- a/Documentation/usb/ohci.txt +++ b/Documentation/usb/ohci.txt @@ -1,3 +1,7 @@ +==== +OHCI +==== + 23-Aug-2002 The "ohci-hcd" driver is a USB Host Controller Driver (HCD) that is derived @@ -29,4 +33,3 @@ work on while the OS is getting around to the relevant IRQ processing. - David Brownell <dbrownell@users.sourceforge.net> - diff --git a/Documentation/usb/rio.txt b/Documentation/usb/rio.txt index aee715af7db7..ca9adcf56355 100644 --- a/Documentation/usb/rio.txt +++ b/Documentation/usb/rio.txt @@ -1,72 +1,80 @@ +============ +Diamonds Rio +============ + Copyright (C) 1999, 2000 Bruce Tenison + Portions Copyright (C) 1999, 2000 David Nelson + Thanks to David Nelson for guidance and the usage of the scanner.txt and scanner.c files to model our driver and this informative file. Mar. 2, 2000 -CHANGES +Changes +======= - Initial Revision -OVERVIEW +Overview +======== This README will address issues regarding how to configure the kernel -to access a RIO 500 mp3 player. +to access a RIO 500 mp3 player. Before I explain how to use this to access the Rio500 please be warned: -W A R N I N G: --------------- +.. warning:: -Please note that this software is still under development. The authors -are in no way responsible for any damage that may occur, no matter how -inconsequential. + Please note that this software is still under development. The authors + are in no way responsible for any damage that may occur, no matter how + inconsequential. It seems that the Rio has a problem when sending .mp3 with low batteries. I suggest when the batteries are low and you want to transfer stuff that you replace it with a fresh one. In my case, what happened is I lost two 16kb blocks (they are no longer usable to store information to it). But I don't -know if that's normal or not; it could simply be a problem with the flash +know if that's normal or not; it could simply be a problem with the flash memory. -In an extreme case, I left my Rio playing overnight and the batteries wore -down to nothing and appear to have corrupted the flash memory. My RIO -needed to be replaced as a result. Diamond tech support is aware of the -problem. Do NOT allow your batteries to wear down to nothing before -changing them. It appears RIO 500 firmware does not handle low battery -power well at all. +In an extreme case, I left my Rio playing overnight and the batteries wore +down to nothing and appear to have corrupted the flash memory. My RIO +needed to be replaced as a result. Diamond tech support is aware of the +problem. Do NOT allow your batteries to wear down to nothing before +changing them. It appears RIO 500 firmware does not handle low battery +power well at all. -On systems with OHCI controllers, the kernel OHCI code appears to have -power on problems with some chipsets. If you are having problems -connecting to your RIO 500, try turning it on first and then plugging it -into the USB cable. +On systems with OHCI controllers, the kernel OHCI code appears to have +power on problems with some chipsets. If you are having problems +connecting to your RIO 500, try turning it on first and then plugging it +into the USB cable. -Contact information: --------------------- +Contact Information +------------------- The main page for the project is hosted at sourceforge.net in the following URL: <http://rio500.sourceforge.net>. You can also go to the project's sourceforge home page at: <http://sourceforge.net/projects/rio500/>. There is also a mailing list: rio500-users@lists.sourceforge.net -Authors: +Authors ------- -Most of the code was written by Cesar Miquel <miquel@df.uba.ar>. Keith +Most of the code was written by Cesar Miquel <miquel@df.uba.ar>. Keith Clayton <kclayton@jps.net> is incharge of the PPC port and making sure things work there. Bruce Tenison <btenison@dibbs.net> is adding support for .fon files and also does testing. The program will mostly sure be re-written and Pete Ikusz along with the rest will re-design it. I would -also like to thank Tri Nguyen <tmn_3022000@hotmail.com> who provided use +also like to thank Tri Nguyen <tmn_3022000@hotmail.com> who provided use with some important information regarding the communication with the Rio. -ADDITIONAL INFORMATION and Userspace tools +Additional Information and userspace tools -http://rio500.sourceforge.net/ + http://rio500.sourceforge.net/ -REQUIREMENTS +Requirements +============ A host with a USB port. Ideally, either a UHCI (Intel) or OHCI (Compaq and others) hardware port should work. @@ -80,11 +88,11 @@ A Linux kernel with RIO 500 support enabled. 'lspci' which is only needed to determine the type of USB hardware available in your machine. -CONFIGURATION +Configuration Using `lspci -v`, determine the type of USB hardware available. - If you see something like: + If you see something like:: USB Controller: ...... Flags: ..... @@ -92,7 +100,7 @@ Using `lspci -v`, determine the type of USB hardware available. Then you have a UHCI based controller. - If you see something like: + If you see something like:: USB Controller: ..... Flags: .... @@ -107,8 +115,9 @@ hardware (determined from the steps above), 'USB Diamond Rio500 support', and (you may need to execute `depmod -a` to update the module dependencies). -Add a device for the USB rio500: - `mknod /dev/usb/rio500 c 180 64` +Add a device for the USB rio500:: + + mknod /dev/usb/rio500 c 180 64 Set appropriate permissions for /dev/usb/rio500 (don't forget about group and world permissions). Both read and write permissions are @@ -116,12 +125,14 @@ required for proper operation. Load the appropriate modules (if compiled as modules): - OHCI: + OHCI:: + modprobe usbcore modprobe usb-ohci modprobe rio500 - UHCI: + UHCI:: + modprobe usbcore modprobe usb-uhci (or uhci) modprobe rio500 @@ -129,10 +140,10 @@ Load the appropriate modules (if compiled as modules): That's it. The Rio500 Utils at: http://rio500.sourceforge.net should be able to access the rio500. -BUGS +Bugs +==== If you encounter any problems feel free to drop me an email. Bruce Tenison btenison@dibbs.net - diff --git a/Documentation/usb/usb-help.txt b/Documentation/usb/usb-help.txt index 4273ca2b86ba..dc23ecd4d802 100644 --- a/Documentation/usb/usb-help.txt +++ b/Documentation/usb/usb-help.txt @@ -1,16 +1,17 @@ -usb-help.txt +============== +USB references +============== + 2008-Mar-7 For USB help other than the readme files that are located in -Documentation/usb/*, see the following: +`Documentation/usb/*`, see the following: -Linux-USB project: http://www.linux-usb.org - mirrors at http://usb.in.tum.de/linux-usb/ - and http://it.linux-usb.org -Linux USB Guide: http://linux-usb.sourceforge.net -Linux-USB device overview (working devices and drivers): - http://www.qbik.ch/usb/devices/ +- Linux-USB project: http://www.linux-usb.org + mirrors at http://usb.in.tum.de/linux-usb/ + and http://it.linux-usb.org +- Linux USB Guide: http://linux-usb.sourceforge.net +- Linux-USB device overview (working devices and drivers): + http://www.qbik.ch/usb/devices/ The Linux-USB mailing list is at linux-usb@vger.kernel.org - -### diff --git a/Documentation/usb/usb-serial.txt b/Documentation/usb/usb-serial.txt index ab100d6ee436..8fa7dbd3da9a 100644 --- a/Documentation/usb/usb-serial.txt +++ b/Documentation/usb/usb-serial.txt @@ -1,4 +1,9 @@ -INTRODUCTION +========== +USB serial +========== + +Introduction +============ The USB serial driver currently supports a number of different USB to serial converter products, as well as some devices that use a serial @@ -8,13 +13,15 @@ INTRODUCTION the different devices. -CONFIGURATION +Configuration +============= Currently the driver can handle up to 256 different serial interfaces at - one time. + one time. The major number that the driver uses is 188 so to use the driver, - create the following nodes: + create the following nodes:: + mknod /dev/ttyUSB0 c 188 0 mknod /dev/ttyUSB1 c 188 1 mknod /dev/ttyUSB2 c 188 2 @@ -28,12 +35,14 @@ CONFIGURATION When the device is connected and recognized by the driver, the driver will print to the system log, which node(s) the device has been bound to. - -SPECIFIC DEVICES SUPPORTED + +Specific Devices Supported +========================== ConnectTech WhiteHEAT 4 port converter +-------------------------------------- ConnectTech has been very forthcoming with information about their device, including providing a unit to test with. @@ -46,6 +55,7 @@ ConnectTech WhiteHEAT 4 port converter HandSpring Visor, Palm USB, and Clié USB driver +----------------------------------------------- This driver works with all HandSpring USB, Palm USB, and Sony Clié USB devices. @@ -62,7 +72,7 @@ HandSpring Visor, Palm USB, and Clié USB driver This goes against the current documentation for pilot-xfer and other packages, but is the only way that it will work due to the hardware in the device. - + When the device is connected, try talking to it on the second port (this is usually /dev/ttyUSB1 if you do not have any other usb-serial devices in the system.) The system log should tell you which port is @@ -78,10 +88,10 @@ HandSpring Visor, Palm USB, and Clié USB driver try resetting the device, first a hot reset, and then a cold reset if necessary. Some devices need this before they can talk to the USB port properly. - + Devices that are not compiled into the kernel can be specified with module parameters. e.g. modprobe visor vendor=0x54c product=0x66 - + There is a webpage and mailing lists for this portion of the driver at: http://sourceforge.net/projects/usbvisor/ @@ -90,6 +100,7 @@ HandSpring Visor, Palm USB, and Clié USB driver PocketPC PDA Driver +------------------- This driver can be used to connect to Compaq iPAQ, HP Jornada, Casio EM500 and other PDAs running Windows CE 3.0 or PocketPC 2002 using a USB @@ -135,12 +146,13 @@ PocketPC PDA Driver be used to flash the ROM, as well as the microP code.. so much for needing Toshiba's $350 serial cable for flashing!! :D NOTE: This has NOT been tested. Use at your own risk. - + For any questions or problems with the driver, please contact Ganesh Varadarajan <ganesh@veritas.com> Keyspan PDA Serial Adapter +-------------------------- Single port DB-9 serial adapter, pushed as a PDA adapter for iMacs (mostly sold in Macintosh catalogs, comes in a translucent white/green dongle). @@ -148,32 +160,37 @@ Keyspan PDA Serial Adapter This driver also works for the Xircom/Entrega single port serial adapter. Current status: + Things that work: - basic input/output (tested with 'cu') - blocking write when serial line can't keep up - changing baud rates (up to 115200) - getting/setting modem control pins (TIOCM{GET,SET,BIS,BIC}) - sending break (although duration looks suspect) + - basic input/output (tested with 'cu') + - blocking write when serial line can't keep up + - changing baud rates (up to 115200) + - getting/setting modem control pins (TIOCM{GET,SET,BIS,BIC}) + - sending break (although duration looks suspect) + Things that don't: - device strings (as logged by kernel) have trailing binary garbage - device ID isn't right, might collide with other Keyspan products - changing baud rates ought to flush tx/rx to avoid mangled half characters + - device strings (as logged by kernel) have trailing binary garbage + - device ID isn't right, might collide with other Keyspan products + - changing baud rates ought to flush tx/rx to avoid mangled half characters + Big Things on the todo list: - parity, 7 vs 8 bits per char, 1 or 2 stop bits - HW flow control - not all of the standard USB descriptors are handled: Get_Status, Set_Feature - O_NONBLOCK, select() + - parity, 7 vs 8 bits per char, 1 or 2 stop bits + - HW flow control + - not all of the standard USB descriptors are handled: + Get_Status, Set_Feature, O_NONBLOCK, select() For any questions or problems with this driver, please contact Brian - Warner at warner@lothar.com + Warner at warner@lothar.com Keyspan USA-series Serial Adapters +---------------------------------- - Single, Dual and Quad port adapters - driver uses Keyspan supplied + Single, Dual and Quad port adapters - driver uses Keyspan supplied firmware and is being developed with their support. - + Current status: + The USA-18X, USA-28X, USA-19, USA-19W and USA-49W are supported and have been pretty thoroughly tested at various baud rates with 8-N-1 character settings. Other character lengths and parity setups are @@ -182,32 +199,37 @@ Keyspan USA-series Serial Adapters The USA-28 isn't yet supported though doing so should be pretty straightforward. Contact the maintainer if you require this functionality. - + More information is available at: + http://www.carnationsoftware.com/carnation/Keyspan.html - + For any questions or problems with this driver, please contact Hugh Blemings at hugh@misc.nu FTDI Single Port Serial Driver +------------------------------ This is a single port DB-25 serial adapter. Devices supported include: - -TripNav TN-200 USB GPS - -Navis Engineering Bureau CH-4711 USB GPS + + - TripNav TN-200 USB GPS + - Navis Engineering Bureau CH-4711 USB GPS For any questions or problems with this driver, please contact Bill Ryder. ZyXEL omni.net lcd plus ISDN TA +------------------------------- This is an ISDN TA. Please report both successes and troubles to azummo@towertech.it Cypress M8 CY4601 Family Serial Driver +-------------------------------------- This driver was in most part developed by Neil "koyama" Whelchel. It has been improved since that previous form to support dynamic serial @@ -215,18 +237,19 @@ Cypress M8 CY4601 Family Serial Driver part stable and has been tested on an smp machine. (dual p2) Chipsets supported under CY4601 family: - + CY7C63723, CY7C63742, CY7C63743, CY7C64013 Devices supported: - -DeLorme's USB Earthmate GPS (SiRF Star II lp arch) - -Cypress HID->COM RS232 adapter - - Note: Cypress Semiconductor claims no affiliation with the + - DeLorme's USB Earthmate GPS (SiRF Star II lp arch) + - Cypress HID->COM RS232 adapter + + Note: + Cypress Semiconductor claims no affiliation with the hid->com device. - Most devices using chipsets under the CY4601 family should + Most devices using chipsets under the CY4601 family should work with the driver. As long as they stay true to the CY4601 usbserial specification. @@ -236,8 +259,9 @@ Cypress M8 CY4601 Family Serial Driver upon start init to this setting. usbserial core provides the rest of the termios settings, along with some custom termios so that the output is in proper format and parsable. - - The device can be put into sirf mode by issuing NMEA command: + + The device can be put into sirf mode by issuing NMEA command:: + $PSRF100,<protocol>,<baud>,<databits>,<stopbits>,<parity>*CHECKSUM $PSRF100,0,9600,8,1,0*0C @@ -259,11 +283,14 @@ Cypress M8 CY4601 Family Serial Driver If you have any questions, problems, patches, feature requests, etc. you can contact me here via email: + dignome@gmail.com + (your problems/patches can alternately be submitted to usb-devel) Digi AccelePort Driver +---------------------- This driver supports the Digi AccelePort USB 2 and 4 devices, 2 port (plus a parallel port) and 4 port USB serial converters. The driver @@ -285,42 +312,49 @@ Digi AccelePort Driver Belkin USB Serial Adapter F5U103 +-------------------------------- Single port DB-9/PS-2 serial adapter from Belkin with firmware by eTEK Labs. The Peracom single port serial adapter also works with this driver, as well as the GoHubs adapter. Current status: + The following have been tested and work: - Baud rate 300-230400 - Data bits 5-8 - Stop bits 1-2 - Parity N,E,O,M,S - Handshake None, Software (XON/XOFF), Hardware (CTSRTS,CTSDTR)* - Break Set and clear - Line control Input/Output query and control ** - - * Hardware input flow control is only enabled for firmware + + - Baud rate 300-230400 + - Data bits 5-8 + - Stop bits 1-2 + - Parity N,E,O,M,S + - Handshake None, Software (XON/XOFF), Hardware (CTSRTS,CTSDTR) [1]_ + - Break Set and clear + - Line control Input/Output query and control [2]_ + + .. [1] + Hardware input flow control is only enabled for firmware levels above 2.06. Read source code comments describing Belkin firmware errata. Hardware output flow control is working for all firmware versions. - ** Queries of inputs (CTS,DSR,CD,RI) show the last + + .. [2] + Queries of inputs (CTS,DSR,CD,RI) show the last reported state. Queries of outputs (DTR,RTS) show the last requested state and may not reflect current state as set by automatic hardware flow control. TO DO List: - -- Add true modem control line query capability. Currently tracks the - states reported by the interrupt and the states requested. - -- Add error reporting back to application for UART error conditions. - -- Add support for flush ioctls. - -- Add everything else that is missing :) + - Add true modem control line query capability. Currently tracks the + states reported by the interrupt and the states requested. + - Add error reporting back to application for UART error conditions. + - Add support for flush ioctls. + - Add everything else that is missing :) For any questions or problems with this driver, please contact William Greathouse at wgreathouse@smva.com Empeg empeg-car Mark I/II Driver +-------------------------------- This is an experimental driver to provide connectivity support for the client synchronization tools for an Empeg empeg-car mp3 player. @@ -335,6 +369,7 @@ Empeg empeg-car Mark I/II Driver MCT USB Single Port Serial Adapter U232 +--------------------------------------- This driver is for the MCT USB-RS232 Converter (25 pin, Model No. U232-P25) from Magic Control Technology Corp. (there is also a 9 pin @@ -355,35 +390,39 @@ MCT USB Single Port Serial Adapter U232 Inside Out Networks Edgeport Driver +----------------------------------- This driver supports all devices made by Inside Out Networks, specifically the following models: - Edgeport/4 - Rapidport/4 - Edgeport/4t - Edgeport/2 - Edgeport/4i - Edgeport/2i - Edgeport/421 - Edgeport/21 - Edgeport/8 - Edgeport/8 Dual - Edgeport/2D8 - Edgeport/4D8 - Edgeport/8i - Edgeport/2 DIN - Edgeport/4 DIN - Edgeport/16 Dual + + - Edgeport/4 + - Rapidport/4 + - Edgeport/4t + - Edgeport/2 + - Edgeport/4i + - Edgeport/2i + - Edgeport/421 + - Edgeport/21 + - Edgeport/8 + - Edgeport/8 Dual + - Edgeport/2D8 + - Edgeport/4D8 + - Edgeport/8i + - Edgeport/2 DIN + - Edgeport/4 DIN + - Edgeport/16 Dual For any questions or problems with this driver, please contact Greg Kroah-Hartman at greg@kroah.com REINER SCT cyberJack pinpad/e-com USB chipcard reader - +----------------------------------------------------- + Interface to ISO 7816 compatible contactbased chipcards, e.g. GSM SIMs. - + Current status: + This is the kernel part of the driver for this USB card reader. There is also a user part for a CT-API driver available. A site for downloading is TBA. For now, you can request it from the @@ -394,6 +433,7 @@ REINER SCT cyberJack pinpad/e-com USB chipcard reader Prolific PL2303 Driver +---------------------- This driver supports any device that has the PL2303 chip from Prolific in it. This includes a number of single port USB to serial converters, @@ -403,11 +443,13 @@ Prolific PL2303 Driver For any questions or problems with this driver, please contact Greg Kroah-Hartman at greg@kroah.com - + KL5KUSB105 chipset / PalmConnect USB single-port adapter - +-------------------------------------------------------- + Current status: + The driver was put together by looking at the usb bus transactions done by Palm's driver under Windows, so a lot of functionality is still missing. Notably, serial ioctls are sometimes faked or not yet @@ -417,21 +459,25 @@ Current status: are supported, but handshaking (software or hardware) is not, which is why it is wise to cut down on the rate used is wise for large transfers until this is settled. - + See http://www.uuhaus.de/linux/palmconnect.html for up-to-date information on this driver. Winchiphead CH341 Driver +------------------------ This driver is for the Winchiphead CH341 USB-RS232 Converter. This chip also implements an IEEE 1284 parallel port, I2C and SPI, but that is not supported by the driver. The protocol was analyzed from the behaviour of the Windows driver, no datasheet is available at present. + The manufacturer's website: http://www.winchiphead.com/. + For any questions or problems with this driver, please contact frank@kingswood-consulting.co.uk. Moschip MCS7720, MCS7715 driver +------------------------------- These chips are present in devices sold by various manufacturers, such as Syba and Cables Unlimited. There may be others. The 7720 provides two serial @@ -449,20 +495,24 @@ Moschip MCS7720, MCS7715 driver don't have one of these devices, so I can't say for sure. Generic Serial driver +--------------------- If your device is not one of the above listed devices, compatible with the above models, you can try out the "generic" interface. This interface does not provide any type of control messages sent to the device, and does not support any kind of device flow control. All that is required of your device is that it has at least one bulk in endpoint, - or one bulk out endpoint. + or one bulk out endpoint. + + To enable the generic driver to recognize your device, provide:: - To enable the generic driver to recognize your device, provide echo <vid> <pid> >/sys/bus/usb-serial/drivers/generic/new_id + where the <vid> and <pid> is replaced with the hex representation of your device's vendor id and product id. If the driver is compiled as a module you can also provide one id when - loading the module + loading the module:: + insmod usbserial vendor=0x#### product=0x#### This driver has been successfully used to connect to the NetChip USB @@ -473,7 +523,8 @@ Generic Serial driver Kroah-Hartman at greg@kroah.com -CONTACT: +Contact +======= If anyone has any problems using these drivers, with any of the above specified products, please contact the specific driver's author listed diff --git a/Documentation/usb/usbip_protocol.txt b/Documentation/usb/usbip_protocol.txt index c7a0f4c7e7f1..988c832166cd 100644 --- a/Documentation/usb/usbip_protocol.txt +++ b/Documentation/usb/usbip_protocol.txt @@ -1,3 +1,7 @@ +=============== +USB/IP protocol +=============== + PRELIMINARY DRAFT, MAY CONTAIN MISTAKES! 28 Jun 2011 @@ -12,6 +16,8 @@ in one or more pieces at the low level transport layer). The server sends back the OP_REP_DEVLIST packet which lists the exported USB devices. Finally the TCP/IP connection is closed. +:: + virtual host controller usb host "client" "server" (imports USB devices) (exports USB devices) @@ -32,6 +38,8 @@ send two types of packets: the USBIP_CMD_SUBMIT to submit an URB, and USBIP_CMD_UNLINK to unlink a previously submitted URB. The answers of the server may be USBIP_RET_SUBMIT and USBIP_RET_UNLINK respectively. +:: + virtual host controller usb host "client" "server" (imports USB devices) (exports USB devices) @@ -88,270 +96,316 @@ The fields are in network (big endian) byte order meaning that the most signific byte (MSB) is stored at the lowest address. -OP_REQ_DEVLIST: Retrieve the list of exported USB devices. +OP_REQ_DEVLIST: + Retrieve the list of exported USB devices. - Offset | Length | Value | Description ------------+--------+------------+--------------------------------------------------- - 0 | 2 | 0x0100 | Binary-coded decimal USBIP version number: v1.0.0 ------------+--------+------------+--------------------------------------------------- - 2 | 2 | 0x8005 | Command code: Retrieve the list of exported USB - | | | devices. ------------+--------+------------+--------------------------------------------------- - 4 | 4 | 0x00000000 | Status: unused, shall be set to 0 ++-----------+--------+------------+---------------------------------------------------+ +| Offset | Length | Value | Description | ++===========+========+============+===================================================+ +| 0 | 2 | 0x0100 | Binary-coded decimal USBIP version number: v1.0.0 | ++-----------+--------+------------+---------------------------------------------------+ +| 2 | 2 | 0x8005 | Command code: Retrieve the list of exported USB | +| | | | devices. | ++-----------+--------+------------+---------------------------------------------------+ +| 4 | 4 | 0x00000000 | Status: unused, shall be set to 0 | ++-----------+--------+------------+---------------------------------------------------+ -OP_REP_DEVLIST: Reply with the list of exported USB devices. +OP_REP_DEVLIST: + Reply with the list of exported USB devices. - Offset | Length | Value | Description ------------+--------+------------+--------------------------------------------------- - 0 | 2 | 0x0100 | Binary-coded decimal USBIP version number: v1.0.0. ------------+--------+------------+--------------------------------------------------- - 2 | 2 | 0x0005 | Reply code: The list of exported USB devices. ------------+--------+------------+--------------------------------------------------- - 4 | 4 | 0x00000000 | Status: 0 for OK ------------+--------+------------+--------------------------------------------------- - 8 | 4 | n | Number of exported devices: 0 means no exported - | | | devices. ------------+--------+------------+--------------------------------------------------- - 0x0C | | | From now on the exported n devices are described, - | | | if any. If no devices are exported the message - | | | ends with the previous "number of exported - | | | devices" field. ------------+--------+------------+--------------------------------------------------- - | 256 | | path: Path of the device on the host exporting the - | | | USB device, string closed with zero byte, e.g. - | | | "/sys/devices/pci0000:00/0000:00:1d.1/usb3/3-2" - | | | The unused bytes shall be filled with zero - | | | bytes. ------------+--------+------------+--------------------------------------------------- - 0x10C | 32 | | busid: Bus ID of the exported device, string - | | | closed with zero byte, e.g. "3-2". The unused - | | | bytes shall be filled with zero bytes. ------------+--------+------------+--------------------------------------------------- - 0x12C | 4 | | busnum ------------+--------+------------+--------------------------------------------------- - 0x130 | 4 | | devnum ------------+--------+------------+--------------------------------------------------- - 0x134 | 4 | | speed ------------+--------+------------+--------------------------------------------------- - 0x138 | 2 | | idVendor ------------+--------+------------+--------------------------------------------------- - 0x13A | 2 | | idProduct ------------+--------+------------+--------------------------------------------------- - 0x13C | 2 | | bcdDevice ------------+--------+------------+--------------------------------------------------- - 0x13E | 1 | | bDeviceClass ------------+--------+------------+--------------------------------------------------- - 0x13F | 1 | | bDeviceSubClass ------------+--------+------------+--------------------------------------------------- - 0x140 | 1 | | bDeviceProtocol ------------+--------+------------+--------------------------------------------------- - 0x141 | 1 | | bConfigurationValue ------------+--------+------------+--------------------------------------------------- - 0x142 | 1 | | bNumConfigurations ------------+--------+------------+--------------------------------------------------- - 0x143 | 1 | | bNumInterfaces ------------+--------+------------+--------------------------------------------------- - 0x144 | | m_0 | From now on each interface is described, all - | | | together bNumInterfaces times, with the - | | | the following 4 fields: ------------+--------+------------+--------------------------------------------------- - | 1 | | bInterfaceClass ------------+--------+------------+--------------------------------------------------- - 0x145 | 1 | | bInterfaceSubClass ------------+--------+------------+--------------------------------------------------- - 0x146 | 1 | | bInterfaceProtocol ------------+--------+------------+--------------------------------------------------- - 0x147 | 1 | | padding byte for alignment, shall be set to zero ------------+--------+------------+--------------------------------------------------- - 0xC + | | | The second exported USB device starts at i=1 - i*0x138 + | | | with the busid field. - m_(i-1)*4 | | | ++-----------+--------+------------+---------------------------------------------------+ +| Offset | Length | Value | Description | ++===========+========+============+===================================================+ +| 0 | 2 | 0x0100 | Binary-coded decimal USBIP version number: v1.0.0.| ++-----------+--------+------------+---------------------------------------------------+ +| 2 | 2 | 0x0005 | Reply code: The list of exported USB devices. | ++-----------+--------+------------+---------------------------------------------------+ +| 4 | 4 | 0x00000000 | Status: 0 for OK | ++-----------+--------+------------+---------------------------------------------------+ +| 8 | 4 | n | Number of exported devices: 0 means no exported | +| | | | devices. | ++-----------+--------+------------+---------------------------------------------------+ +| 0x0C | | | From now on the exported n devices are described, | +| | | | if any. If no devices are exported the message | +| | | | ends with the previous "number of exported | +| | | | devices" field. | ++-----------+--------+------------+---------------------------------------------------+ +| | 256 | | path: Path of the device on the host exporting the| +| | | | USB device, string closed with zero byte, e.g. | +| | | | "/sys/devices/pci0000:00/0000:00:1d.1/usb3/3-2" | +| | | | The unused bytes shall be filled with zero | +| | | | bytes. | ++-----------+--------+------------+---------------------------------------------------+ +| 0x10C | 32 | | busid: Bus ID of the exported device, string | +| | | | closed with zero byte, e.g. "3-2". The unused | +| | | | bytes shall be filled with zero bytes. | ++-----------+--------+------------+---------------------------------------------------+ +| 0x12C | 4 | | busnum | ++-----------+--------+------------+---------------------------------------------------+ +| 0x130 | 4 | | devnum | ++-----------+--------+------------+---------------------------------------------------+ +| 0x134 | 4 | | speed | ++-----------+--------+------------+---------------------------------------------------+ +| 0x138 | 2 | | idVendor | ++-----------+--------+------------+---------------------------------------------------+ +| 0x13A | 2 | | idProduct | ++-----------+--------+------------+---------------------------------------------------+ +| 0x13C | 2 | | bcdDevice | ++-----------+--------+------------+---------------------------------------------------+ +| 0x13E | 1 | | bDeviceClass | ++-----------+--------+------------+---------------------------------------------------+ +| 0x13F | 1 | | bDeviceSubClass | ++-----------+--------+------------+---------------------------------------------------+ +| 0x140 | 1 | | bDeviceProtocol | ++-----------+--------+------------+---------------------------------------------------+ +| 0x141 | 1 | | bConfigurationValue | ++-----------+--------+------------+---------------------------------------------------+ +| 0x142 | 1 | | bNumConfigurations | ++-----------+--------+------------+---------------------------------------------------+ +| 0x143 | 1 | | bNumInterfaces | ++-----------+--------+------------+---------------------------------------------------+ +| 0x144 | | m_0 | From now on each interface is described, all | +| | | | together bNumInterfaces times, with the | +| | | | the following 4 fields: | ++-----------+--------+------------+---------------------------------------------------+ +| | 1 | | bInterfaceClass | ++-----------+--------+------------+---------------------------------------------------+ +| 0x145 | 1 | | bInterfaceSubClass | ++-----------+--------+------------+---------------------------------------------------+ +| 0x146 | 1 | | bInterfaceProtocol | ++-----------+--------+------------+---------------------------------------------------+ +| 0x147 | 1 | | padding byte for alignment, shall be set to zero | ++-----------+--------+------------+---------------------------------------------------+ +| 0xC + | | | The second exported USB device starts at i=1 | +| i*0x138 + | | | with the busid field. | +| m_(i-1)*4 | | | | ++-----------+--------+------------+---------------------------------------------------+ -OP_REQ_IMPORT: Request to import (attach) a remote USB device. +OP_REQ_IMPORT: + Request to import (attach) a remote USB device. - Offset | Length | Value | Description ------------+--------+------------+--------------------------------------------------- - 0 | 2 | 0x0100 | Binary-coded decimal USBIP version number: v1.0.0 ------------+--------+------------+--------------------------------------------------- - 2 | 2 | 0x8003 | Command code: import a remote USB device. ------------+--------+------------+--------------------------------------------------- - 4 | 4 | 0x00000000 | Status: unused, shall be set to 0 ------------+--------+------------+--------------------------------------------------- - 8 | 32 | | busid: the busid of the exported device on the - | | | remote host. The possible values are taken - | | | from the message field OP_REP_DEVLIST.busid. - | | | A string closed with zero, the unused bytes - | | | shall be filled with zeros. ------------+--------+------------+--------------------------------------------------- ++-----------+--------+------------+---------------------------------------------------+ +| Offset | Length | Value | Description | ++===========+========+============+===================================================+ +| 0 | 2 | 0x0100 | Binary-coded decimal USBIP version number: v1.0.0 | ++-----------+--------+------------+---------------------------------------------------+ +| 2 | 2 | 0x8003 | Command code: import a remote USB device. | ++-----------+--------+------------+---------------------------------------------------+ +| 4 | 4 | 0x00000000 | Status: unused, shall be set to 0 | ++-----------+--------+------------+---------------------------------------------------+ +| 8 | 32 | | busid: the busid of the exported device on the | +| | | | remote host. The possible values are taken | +| | | | from the message field OP_REP_DEVLIST.busid. | +| | | | A string closed with zero, the unused bytes | +| | | | shall be filled with zeros. | ++-----------+--------+------------+---------------------------------------------------+ -OP_REP_IMPORT: Reply to import (attach) a remote USB device. +OP_REP_IMPORT: + Reply to import (attach) a remote USB device. - Offset | Length | Value | Description ------------+--------+------------+--------------------------------------------------- - 0 | 2 | 0x0100 | Binary-coded decimal USBIP version number: v1.0.0 ------------+--------+------------+--------------------------------------------------- - 2 | 2 | 0x0003 | Reply code: Reply to import. ------------+--------+------------+--------------------------------------------------- - 4 | 4 | 0x00000000 | Status: 0 for OK - | | | 1 for error ------------+--------+------------+--------------------------------------------------- - 8 | | | From now on comes the details of the imported - | | | device, if the previous status field was OK (0), - | | | otherwise the reply ends with the status field. ------------+--------+------------+--------------------------------------------------- - | 256 | | path: Path of the device on the host exporting the - | | | USB device, string closed with zero byte, e.g. - | | | "/sys/devices/pci0000:00/0000:00:1d.1/usb3/3-2" - | | | The unused bytes shall be filled with zero - | | | bytes. ------------+--------+------------+--------------------------------------------------- - 0x108 | 32 | | busid: Bus ID of the exported device, string - | | | closed with zero byte, e.g. "3-2". The unused - | | | bytes shall be filled with zero bytes. ------------+--------+------------+--------------------------------------------------- - 0x128 | 4 | | busnum ------------+--------+------------+--------------------------------------------------- - 0x12C | 4 | | devnum ------------+--------+------------+--------------------------------------------------- - 0x130 | 4 | | speed ------------+--------+------------+--------------------------------------------------- - 0x134 | 2 | | idVendor ------------+--------+------------+--------------------------------------------------- - 0x136 | 2 | | idProduct ------------+--------+------------+--------------------------------------------------- - 0x138 | 2 | | bcdDevice ------------+--------+------------+--------------------------------------------------- - 0x139 | 1 | | bDeviceClass ------------+--------+------------+--------------------------------------------------- - 0x13A | 1 | | bDeviceSubClass ------------+--------+------------+--------------------------------------------------- - 0x13B | 1 | | bDeviceProtocol ------------+--------+------------+--------------------------------------------------- - 0x13C | 1 | | bConfigurationValue ------------+--------+------------+--------------------------------------------------- - 0x13D | 1 | | bNumConfigurations ------------+--------+------------+--------------------------------------------------- - 0x13E | 1 | | bNumInterfaces ++-----------+--------+------------+---------------------------------------------------+ +| Offset | Length | Value | Description | ++===========+========+============+===================================================+ +| 0 | 2 | 0x0100 | Binary-coded decimal USBIP version number: v1.0.0 | ++-----------+--------+------------+---------------------------------------------------+ +| 2 | 2 | 0x0003 | Reply code: Reply to import. | ++-----------+--------+------------+---------------------------------------------------+ +| 4 | 4 | 0x00000000 | Status: | +| | | | | +| | | | - 0 for OK | +| | | | - 1 for error | ++-----------+--------+------------+---------------------------------------------------+ +| 8 | | | From now on comes the details of the imported | +| | | | device, if the previous status field was OK (0), | +| | | | otherwise the reply ends with the status field. | ++-----------+--------+------------+---------------------------------------------------+ +| | 256 | | path: Path of the device on the host exporting the| +| | | | USB device, string closed with zero byte, e.g. | +| | | | "/sys/devices/pci0000:00/0000:00:1d.1/usb3/3-2" | +| | | | The unused bytes shall be filled with zero | +| | | | bytes. | ++-----------+--------+------------+---------------------------------------------------+ +| 0x108 | 32 | | busid: Bus ID of the exported device, string | +| | | | closed with zero byte, e.g. "3-2". The unused | +| | | | bytes shall be filled with zero bytes. | ++-----------+--------+------------+---------------------------------------------------+ +| 0x128 | 4 | | busnum | ++-----------+--------+------------+---------------------------------------------------+ +| 0x12C | 4 | | devnum | ++-----------+--------+------------+---------------------------------------------------+ +| 0x130 | 4 | | speed | ++-----------+--------+------------+---------------------------------------------------+ +| 0x134 | 2 | | idVendor | ++-----------+--------+------------+---------------------------------------------------+ +| 0x136 | 2 | | idProduct | ++-----------+--------+------------+---------------------------------------------------+ +| 0x138 | 2 | | bcdDevice | ++-----------+--------+------------+---------------------------------------------------+ +| 0x139 | 1 | | bDeviceClass | ++-----------+--------+------------+---------------------------------------------------+ +| 0x13A | 1 | | bDeviceSubClass | ++-----------+--------+------------+---------------------------------------------------+ +| 0x13B | 1 | | bDeviceProtocol | ++-----------+--------+------------+---------------------------------------------------+ +| 0x13C | 1 | | bConfigurationValue | ++-----------+--------+------------+---------------------------------------------------+ +| 0x13D | 1 | | bNumConfigurations | ++-----------+--------+------------+---------------------------------------------------+ +| 0x13E | 1 | | bNumInterfaces | ++-----------+--------+------------+---------------------------------------------------+ -USBIP_CMD_SUBMIT: Submit an URB +USBIP_CMD_SUBMIT: + Submit an URB - Offset | Length | Value | Description ------------+--------+------------+--------------------------------------------------- - 0 | 4 | 0x00000001 | command: Submit an URB ------------+--------+------------+--------------------------------------------------- - 4 | 4 | | seqnum: the sequence number of the URB to submit ------------+--------+------------+--------------------------------------------------- - 8 | 4 | | devid ------------+--------+------------+--------------------------------------------------- - 0xC | 4 | | direction: 0: USBIP_DIR_OUT - | | | 1: USBIP_DIR_IN ------------+--------+------------+--------------------------------------------------- - 0x10 | 4 | | ep: endpoint number, possible values are: 0...15 ------------+--------+------------+--------------------------------------------------- - 0x14 | 4 | | transfer_flags: possible values depend on the - | | | URB transfer type, see below ------------+--------+------------+--------------------------------------------------- - 0x18 | 4 | | transfer_buffer_length ------------+--------+------------+--------------------------------------------------- - 0x1C | 4 | | start_frame: specify the selected frame to - | | | transmit an ISO frame, ignored if URB_ISO_ASAP - | | | is specified at transfer_flags ------------+--------+------------+--------------------------------------------------- - 0x20 | 4 | | number_of_packets: number of ISO packets ------------+--------+------------+--------------------------------------------------- - 0x24 | 4 | | interval: maximum time for the request on the - | | | server-side host controller ------------+--------+------------+--------------------------------------------------- - 0x28 | 8 | | setup: data bytes for USB setup, filled with - | | | zeros if not used ------------+--------+------------+--------------------------------------------------- - 0x30 | | | URB data. For ISO transfers the padding between - | | | each ISO packets is not transmitted. ++-----------+--------+------------+---------------------------------------------------+ +| Offset | Length | Value | Description | ++===========+========+============+===================================================+ +| 0 | 4 | 0x00000001 | command: Submit an URB | ++-----------+--------+------------+---------------------------------------------------+ +| 4 | 4 | | seqnum: the sequence number of the URB to submit | ++-----------+--------+------------+---------------------------------------------------+ +| 8 | 4 | | devid | ++-----------+--------+------------+---------------------------------------------------+ +| 0xC | 4 | | direction: | +| | | | | +| | | | - 0: USBIP_DIR_OUT | +| | | | - 1: USBIP_DIR_IN | ++-----------+--------+------------+---------------------------------------------------+ +| 0x10 | 4 | | ep: endpoint number, possible values are: 0...15 | ++-----------+--------+------------+---------------------------------------------------+ +| 0x14 | 4 | | transfer_flags: possible values depend on the | +| | | | URB transfer type, see below | ++-----------+--------+------------+---------------------------------------------------+ +| 0x18 | 4 | | transfer_buffer_length | ++-----------+--------+------------+---------------------------------------------------+ +| 0x1C | 4 | | start_frame: specify the selected frame to | +| | | | transmit an ISO frame, ignored if URB_ISO_ASAP | +| | | | is specified at transfer_flags | ++-----------+--------+------------+---------------------------------------------------+ +| 0x20 | 4 | | number_of_packets: number of ISO packets | ++-----------+--------+------------+---------------------------------------------------+ +| 0x24 | 4 | | interval: maximum time for the request on the | +| | | | server-side host controller | ++-----------+--------+------------+---------------------------------------------------+ +| 0x28 | 8 | | setup: data bytes for USB setup, filled with | +| | | | zeros if not used | ++-----------+--------+------------+---------------------------------------------------+ +| 0x30 | | | URB data. For ISO transfers the padding between | +| | | | each ISO packets is not transmitted. | ++-----------+--------+------------+---------------------------------------------------+ - Allowed transfer_flags | value | control | interrupt | bulk | isochronous - -------------------------+------------+---------+-----------+----------+------------- - URB_SHORT_NOT_OK | 0x00000001 | only in | only in | only in | no - URB_ISO_ASAP | 0x00000002 | no | no | no | yes - URB_NO_TRANSFER_DMA_MAP | 0x00000004 | yes | yes | yes | yes - URB_ZERO_PACKET | 0x00000040 | no | no | only out | no - URB_NO_INTERRUPT | 0x00000080 | yes | yes | yes | yes - URB_FREE_BUFFER | 0x00000100 | yes | yes | yes | yes - URB_DIR_MASK | 0x00000200 | yes | yes | yes | yes + +-------------------------+------------+---------+-----------+----------+-------------+ + | Allowed transfer_flags | value | control | interrupt | bulk | isochronous | + +=========================+============+=========+===========+==========+=============+ + | URB_SHORT_NOT_OK | 0x00000001 | only in | only in | only in | no | + +-------------------------+------------+---------+-----------+----------+-------------+ + | URB_ISO_ASAP | 0x00000002 | no | no | no | yes | + +-------------------------+------------+---------+-----------+----------+-------------+ + | URB_NO_TRANSFER_DMA_MAP | 0x00000004 | yes | yes | yes | yes | + +-------------------------+------------+---------+-----------+----------+-------------+ + | URB_ZERO_PACKET | 0x00000040 | no | no | only out | no | + +-------------------------+------------+---------+-----------+----------+-------------+ + | URB_NO_INTERRUPT | 0x00000080 | yes | yes | yes | yes | + +-------------------------+------------+---------+-----------+----------+-------------+ + | URB_FREE_BUFFER | 0x00000100 | yes | yes | yes | yes | + +-------------------------+------------+---------+-----------+----------+-------------+ + | URB_DIR_MASK | 0x00000200 | yes | yes | yes | yes | + +-------------------------+------------+---------+-----------+----------+-------------+ -USBIP_RET_SUBMIT: Reply for submitting an URB +USBIP_RET_SUBMIT: + Reply for submitting an URB - Offset | Length | Value | Description ------------+--------+------------+--------------------------------------------------- - 0 | 4 | 0x00000003 | command ------------+--------+------------+--------------------------------------------------- - 4 | 4 | | seqnum: URB sequence number ------------+--------+------------+--------------------------------------------------- - 8 | 4 | | devid ------------+--------+------------+--------------------------------------------------- - 0xC | 4 | | direction: 0: USBIP_DIR_OUT - | | | 1: USBIP_DIR_IN ------------+--------+------------+--------------------------------------------------- - 0x10 | 4 | | ep: endpoint number ------------+--------+------------+--------------------------------------------------- - 0x14 | 4 | | status: zero for successful URB transaction, - | | | otherwise some kind of error happened. ------------+--------+------------+--------------------------------------------------- - 0x18 | 4 | n | actual_length: number of URB data bytes ------------+--------+------------+--------------------------------------------------- - 0x1C | 4 | | start_frame: for an ISO frame the actually - | | | selected frame for transmit. ------------+--------+------------+--------------------------------------------------- - 0x20 | 4 | | number_of_packets ------------+--------+------------+--------------------------------------------------- - 0x24 | 4 | | error_count ------------+--------+------------+--------------------------------------------------- - 0x28 | 8 | | setup: data bytes for USB setup, filled with - | | | zeros if not used ------------+--------+------------+--------------------------------------------------- - 0x30 | n | | URB data bytes. For ISO transfers the padding - | | | between each ISO packets is not transmitted. ++-----------+--------+------------+---------------------------------------------------+ +| Offset | Length | Value | Description | ++===========+========+============+===================================================+ +| 0 | 4 | 0x00000003 | command | ++-----------+--------+------------+---------------------------------------------------+ +| 4 | 4 | | seqnum: URB sequence number | ++-----------+--------+------------+---------------------------------------------------+ +| 8 | 4 | | devid | ++-----------+--------+------------+---------------------------------------------------+ +| 0xC | 4 | | direction: | +| | | | | +| | | | - 0: USBIP_DIR_OUT | +| | | | - 1: USBIP_DIR_IN | ++-----------+--------+------------+---------------------------------------------------+ +| 0x10 | 4 | | ep: endpoint number | ++-----------+--------+------------+---------------------------------------------------+ +| 0x14 | 4 | | status: zero for successful URB transaction, | +| | | | otherwise some kind of error happened. | ++-----------+--------+------------+---------------------------------------------------+ +| 0x18 | 4 | n | actual_length: number of URB data bytes | ++-----------+--------+------------+---------------------------------------------------+ +| 0x1C | 4 | | start_frame: for an ISO frame the actually | +| | | | selected frame for transmit. | ++-----------+--------+------------+---------------------------------------------------+ +| 0x20 | 4 | | number_of_packets | ++-----------+--------+------------+---------------------------------------------------+ +| 0x24 | 4 | | error_count | ++-----------+--------+------------+---------------------------------------------------+ +| 0x28 | 8 | | setup: data bytes for USB setup, filled with | +| | | | zeros if not used | ++-----------+--------+------------+---------------------------------------------------+ +| 0x30 | n | | URB data bytes. For ISO transfers the padding | +| | | | between each ISO packets is not transmitted. | ++-----------+--------+------------+---------------------------------------------------+ -USBIP_CMD_UNLINK: Unlink an URB +USBIP_CMD_UNLINK: + Unlink an URB - Offset | Length | Value | Description ------------+--------+------------+--------------------------------------------------- - 0 | 4 | 0x00000002 | command: URB unlink command ------------+--------+------------+--------------------------------------------------- - 4 | 4 | | seqnum: URB sequence number to unlink: FIXME: is this so? ------------+--------+------------+--------------------------------------------------- - 8 | 4 | | devid ------------+--------+------------+--------------------------------------------------- - 0xC | 4 | | direction: 0: USBIP_DIR_OUT - | | | 1: USBIP_DIR_IN ------------+--------+------------+--------------------------------------------------- - 0x10 | 4 | | ep: endpoint number: zero ------------+--------+------------+--------------------------------------------------- - 0x14 | 4 | | seqnum: the URB sequence number given previously - | | | at USBIP_CMD_SUBMIT.seqnum field ------------+--------+------------+--------------------------------------------------- - 0x30 | n | | URB data bytes. For ISO transfers the padding - | | | between each ISO packets is not transmitted. ++-----------+--------+------------+---------------------------------------------------+ +| Offset | Length | Value | Description | ++===========+========+============+===================================================+ +| 0 | 4 | 0x00000002 | command: URB unlink command | ++-----------+--------+------------+---------------------------------------------------+ +| 4 | 4 | | seqnum: URB sequence number to unlink: | +| | | | | +| | | | FIXME: | +| | | | is this so? | ++-----------+--------+------------+---------------------------------------------------+ +| 8 | 4 | | devid | ++-----------+--------+------------+---------------------------------------------------+ +| 0xC | 4 | | direction: | +| | | | | +| | | | - 0: USBIP_DIR_OUT | +| | | | - 1: USBIP_DIR_IN | ++-----------+--------+------------+---------------------------------------------------+ +| 0x10 | 4 | | ep: endpoint number: zero | ++-----------+--------+------------+---------------------------------------------------+ +| 0x14 | 4 | | seqnum: the URB sequence number given previously | +| | | | at USBIP_CMD_SUBMIT.seqnum field | ++-----------+--------+------------+---------------------------------------------------+ +| 0x30 | n | | URB data bytes. For ISO transfers the padding | +| | | | between each ISO packets is not transmitted. | ++-----------+--------+------------+---------------------------------------------------+ -USBIP_RET_UNLINK: Reply for URB unlink +USBIP_RET_UNLINK: + Reply for URB unlink - Offset | Length | Value | Description ------------+--------+------------+--------------------------------------------------- - 0 | 4 | 0x00000004 | command: reply for the URB unlink command ------------+--------+------------+--------------------------------------------------- - 4 | 4 | | seqnum: the unlinked URB sequence number ------------+--------+------------+--------------------------------------------------- - 8 | 4 | | devid ------------+--------+------------+--------------------------------------------------- - 0xC | 4 | | direction: 0: USBIP_DIR_OUT - | | | 1: USBIP_DIR_IN ------------+--------+------------+--------------------------------------------------- - 0x10 | 4 | | ep: endpoint number ------------+--------+------------+--------------------------------------------------- - 0x14 | 4 | | status: This is the value contained in the - | | | urb->status in the URB completition handler. - | | | FIXME: a better explanation needed. ------------+--------+------------+--------------------------------------------------- - 0x30 | n | | URB data bytes. For ISO transfers the padding - | | | between each ISO packets is not transmitted. ++-----------+--------+------------+---------------------------------------------------+ +| Offset | Length | Value | Description | ++===========+========+============+===================================================+ +| 0 | 4 | 0x00000004 | command: reply for the URB unlink command | ++-----------+--------+------------+---------------------------------------------------+ +| 4 | 4 | | seqnum: the unlinked URB sequence number | ++-----------+--------+------------+---------------------------------------------------+ +| 8 | 4 | | devid | ++-----------+--------+------------+---------------------------------------------------+ +| 0xC | 4 | | direction: | +| | | | | +| | | | - 0: USBIP_DIR_OUT | +| | | | - 1: USBIP_DIR_IN | ++-----------+--------+------------+---------------------------------------------------+ +| 0x10 | 4 | | ep: endpoint number | ++-----------+--------+------------+---------------------------------------------------+ +| 0x14 | 4 | | status: This is the value contained in the | +| | | | urb->status in the URB completition handler. | +| | | | | +| | | | FIXME: | +| | | | a better explanation needed. | ++-----------+--------+------------+---------------------------------------------------+ +| 0x30 | n | | URB data bytes. For ISO transfers the padding | +| | | | between each ISO packets is not transmitted. | ++-----------+--------+------------+---------------------------------------------------+ diff --git a/Documentation/usb/usbmon.txt b/Documentation/usb/usbmon.txt index 28425f736756..b0bd51080799 100644 --- a/Documentation/usb/usbmon.txt +++ b/Documentation/usb/usbmon.txt @@ -1,4 +1,9 @@ -* Introduction +====== +usbmon +====== + +Introduction +============ The name "usbmon" in lowercase refers to a facility in kernel which is used to collect traces of I/O on the USB bus. This function is analogous @@ -16,7 +21,8 @@ Two APIs are currently implemented: "text" and "binary". The binary API is available through a character device in /dev namespace and is an ABI. The text API is deprecated since 2.6.35, but available for convenience. -* How to use usbmon to collect raw text traces +How to use usbmon to collect raw text traces +============================================ Unlike the packet socket, usbmon has an interface which provides traces in a text format. This is used for two purposes. First, it serves as a @@ -26,38 +32,41 @@ are finalized. Second, humans can read it in case tools are not available. To collect a raw text trace, execute following steps. 1. Prepare +---------- Mount debugfs (it has to be enabled in your kernel configuration), and load the usbmon module (if built as module). The second step is skipped -if usbmon is built into the kernel. +if usbmon is built into the kernel:: -# mount -t debugfs none_debugs /sys/kernel/debug -# modprobe usbmon -# + # mount -t debugfs none_debugs /sys/kernel/debug + # modprobe usbmon + # -Verify that bus sockets are present. +Verify that bus sockets are present: -# ls /sys/kernel/debug/usb/usbmon -0s 0u 1s 1t 1u 2s 2t 2u 3s 3t 3u 4s 4t 4u -# + # ls /sys/kernel/debug/usb/usbmon + 0s 0u 1s 1t 1u 2s 2t 2u 3s 3t 3u 4s 4t 4u + # Now you can choose to either use the socket '0u' (to capture packets on all buses), and skip to step #3, or find the bus used by your device with step #2. This allows to filter away annoying devices that talk continuously. 2. Find which bus connects to the desired device +------------------------------------------------ Run "cat /sys/kernel/debug/usb/devices", and find the T-line which corresponds to the device. Usually you do it by looking for the vendor string. If you have many similar devices, unplug one and compare the two /sys/kernel/debug/usb/devices outputs. The T-line will have a bus number. -Example: -T: Bus=03 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 -D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 -P: Vendor=0557 ProdID=2004 Rev= 1.00 -S: Manufacturer=ATEN -S: Product=UC100KM V2.00 +Example:: + + T: Bus=03 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 + D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 + P: Vendor=0557 ProdID=2004 Rev= 1.00 + S: Manufacturer=ATEN + S: Product=UC100KM V2.00 "Bus=03" means it's bus 3. Alternatively, you can look at the output from "lsusb" and get the bus number from the appropriate line. Example: @@ -65,23 +74,28 @@ S: Product=UC100KM V2.00 Bus 003 Device 002: ID 0557:2004 ATEN UC100KM V2.00 3. Start 'cat' +-------------- + +:: -# cat /sys/kernel/debug/usb/usbmon/3u > /tmp/1.mon.out + # cat /sys/kernel/debug/usb/usbmon/3u > /tmp/1.mon.out -to listen on a single bus, otherwise, to listen on all buses, type: +to listen on a single bus, otherwise, to listen on all buses, type:: -# cat /sys/kernel/debug/usb/usbmon/0u > /tmp/1.mon.out + # cat /sys/kernel/debug/usb/usbmon/0u > /tmp/1.mon.out This process will read until it is killed. Naturally, the output can be redirected to a desirable location. This is preferred, because it is going to be quite long. 4. Perform the desired operation on the USB bus +----------------------------------------------- This is where you do something that creates the traffic: plug in a flash key, copy files, control a webcam, etc. 5. Kill cat +----------- Usually it's done with a keyboard interrupt (Control-C). @@ -89,7 +103,8 @@ At this point the output file (/tmp/1.mon.out in this example) can be saved, sent by e-mail, or inspected with a text editor. In the last case make sure that the file size is not excessive for your favourite editor. -* Raw text data format +Raw text data format +==================== Two formats are supported currently: the original, or '1t' format, and the '1u' format. The '1t' format is deprecated in kernel 2.6.21. The '1u' @@ -122,10 +137,14 @@ Here is the list of words, from left to right: - "Address" word (formerly a "pipe"). It consists of four fields, separated by colons: URB type and direction, Bus number, Device address, Endpoint number. Type and direction are encoded with two bytes in the following manner: + + == == ============================= Ci Co Control input and output Zi Zo Isochronous input and output Ii Io Interrupt input and output Bi Bo Bulk input and output + == == ============================= + Bus number, Device address, and Endpoint are decimal numbers, but they may have leading zeros, for the sake of human readers. @@ -178,24 +197,25 @@ Here is the list of words, from left to right: Examples: -An input control transfer to get a port status. +An input control transfer to get a port status:: -d5ea89a0 3575914555 S Ci:1:001:0 s a3 00 0000 0003 0004 4 < -d5ea89a0 3575914560 C Ci:1:001:0 0 4 = 01050000 + d5ea89a0 3575914555 S Ci:1:001:0 s a3 00 0000 0003 0004 4 < + d5ea89a0 3575914560 C Ci:1:001:0 0 4 = 01050000 An output bulk transfer to send a SCSI command 0x28 (READ_10) in a 31-byte -Bulk wrapper to a storage device at address 5: +Bulk wrapper to a storage device at address 5:: -dd65f0e8 4128379752 S Bo:1:005:2 -115 31 = 55534243 ad000000 00800000 80010a28 20000000 20000040 00000000 000000 -dd65f0e8 4128379808 C Bo:1:005:2 0 31 > + dd65f0e8 4128379752 S Bo:1:005:2 -115 31 = 55534243 ad000000 00800000 80010a28 20000000 20000040 00000000 000000 + dd65f0e8 4128379808 C Bo:1:005:2 0 31 > -* Raw binary format and API +Raw binary format and API +========================= The overall architecture of the API is about the same as the one above, only the events are delivered in binary format. Each event is sent in -the following structure (its name is made up, so that we can refer to it): +the following structure (its name is made up, so that we can refer to it):: -struct usbmon_packet { + struct usbmon_packet { u64 id; /* 0: URB ID - from submission to callback */ unsigned char type; /* 8: Same as text; extensible. */ unsigned char xfer_type; /* ISO (0), Intr, Control, Bulk (3) */ @@ -220,7 +240,7 @@ struct usbmon_packet { int start_frame; /* 52: For ISO */ unsigned int xfer_flags; /* 56: copy of URB's transfer_flags */ unsigned int ndesc; /* 60: Actual number of ISO descriptors */ -}; /* 64 total length */ + }; /* 64 total length */ These events can be received from a character device by reading with read(2), with an ioctl(2), or by accessing the buffer with mmap. However, read(2) @@ -244,12 +264,12 @@ no events are available. MON_IOCG_STATS, defined as _IOR(MON_IOC_MAGIC, 3, struct mon_bin_stats) -The argument is a pointer to the following structure: +The argument is a pointer to the following structure:: -struct mon_bin_stats { + struct mon_bin_stats { u32 queued; u32 dropped; -}; + }; The member "queued" refers to the number of events currently queued in the buffer (and not to the number of events processed since the last reset). @@ -273,13 +293,13 @@ This call returns the current size of the buffer in bytes. These calls wait for events to arrive if none were in the kernel buffer, then return the first event. The argument is a pointer to the following -structure: +structure:: -struct mon_get_arg { + struct mon_get_arg { struct usbmon_packet *hdr; void *data; size_t alloc; /* Length of data (can be zero) */ -}; + }; Before the call, hdr, data, and alloc should be filled. Upon return, the area pointed by hdr contains the next event structure, and the data buffer contains @@ -290,13 +310,13 @@ The MON_IOCX_GET copies 48 bytes to hdr area, MON_IOCX_GETX copies 64 bytes. MON_IOCX_MFETCH, defined as _IOWR(MON_IOC_MAGIC, 7, struct mon_mfetch_arg) This ioctl is primarily used when the application accesses the buffer -with mmap(2). Its argument is a pointer to the following structure: +with mmap(2). Its argument is a pointer to the following structure:: -struct mon_mfetch_arg { + struct mon_mfetch_arg { uint32_t *offvec; /* Vector of events fetched */ uint32_t nfetch; /* Number of events to fetch (out: fetched) */ uint32_t nflush; /* Number of events to flush */ -}; + }; The ioctl operates in 3 stages. @@ -329,7 +349,7 @@ be polled with select(2) and poll(2). But lseek(2) does not work. The basic idea is simple: To prepare, map the buffer by getting the current size, then using mmap(2). -Then, execute a loop similar to the one written in pseudo-code below: +Then, execute a loop similar to the one written in pseudo-code below:: struct mon_mfetch_arg fetch; struct usbmon_packet *hdr; |