* Re: [PATCH 01/17] ARM: sunxi: Register cpufreq-dt for sun[45678]i
From: Maxime Ripard @ 2015-01-06 15:55 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Dmitry Torokhov, Zhang Rui, Eduardo Valentin, Hans de Goede,
linux-input, linux-arm-kernel, linux-pm
In-Reply-To: <1420511727-8242-2-git-send-email-wens@csie.org>
[-- Attachment #1: Type: text/plain, Size: 622 bytes --]
Hi,
On Tue, Jan 06, 2015 at 10:35:11AM +0800, Chen-Yu Tsai wrote:
> On sun[45678]i, we have one cluster of identical cores sharing a
> clock, which is ideal for using cpufreq-dt. Register a platform
> device for cpufreq-dt.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
While I don't have anything against this patch, I seem to recall that
it was not necessary anymore, or that there was some work in the
direction of removing that kind of code, have you looked into that?
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 04/17] ARM: dts: sunxi: Add dtsi for AXP209 PMIC
From: Maxime Ripard @ 2015-01-06 15:58 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Dmitry Torokhov, Zhang Rui, Eduardo Valentin, Hans de Goede,
linux-input, linux-arm-kernel, linux-pm
In-Reply-To: <1420511727-8242-5-git-send-email-wens@csie.org>
[-- Attachment #1: Type: text/plain, Size: 4152 bytes --]
Hi,
On Tue, Jan 06, 2015 at 10:35:14AM +0800, Chen-Yu Tsai wrote:
> The AXP209 PMIC is used with some Allwinner SoCs. This patch adds
> a dtsi file listing all the regulator nodes. The regulators are
> initialized based on their device node names.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> ---
> arch/arm/boot/dts/axp209.dtsi | 87 +++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 87 insertions(+)
> create mode 100644 arch/arm/boot/dts/axp209.dtsi
>
> diff --git a/arch/arm/boot/dts/axp209.dtsi b/arch/arm/boot/dts/axp209.dtsi
> new file mode 100644
> index 000000000000..3c38cbafe285
> --- /dev/null
> +++ b/arch/arm/boot/dts/axp209.dtsi
> @@ -0,0 +1,87 @@
> +/*
> + * Copyright 2015 Chen-Yu Tsai
> + *
> + * Chen-Yu Tsai <wens@csie.org>
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file 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 file 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 with this file; if not, write to the Free
> + * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
> + * MA 02110-1301 USA
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/*
> + * AXP202/209 Integrated Power Management Chip
> + * http://www.x-powers.com/product/AXP20X.php
> + * http://dl.linux-sunxi.org/AXP/AXP209%20Datasheet%20v1.0_cn.pdf
> + */
> +
> +&axp209 {
> + regulators {
> + /* Default work frequency for buck regulators */
> + x-powers,dcdc-freq = <1500>;
> +
> + /* This section lists all the regulators */
I don't think this comment is necessary.
> + reg_dcdc2: dcdc2 {
> + };
> +
> + reg_dcdc3: dcdc3 {
> + };
> +
> + reg_ldo1: ldo1 {
> + /* LDO1 is a fixed output regulator */
> + regulator-always-on;
> + regulator-min-microvolt = <1300000>;
> + regulator-max-microvolt = <1300000>;
> + };
> +
> + reg_ldo2: ldo2 {
> + };
> +
> + reg_ldo3: ldo3 {
> + };
> +
> + reg_ldo4: ldo4 {
> + };
> +
> + reg_ldo5: ldo5 {
> + };
Some default names for the regulator would be great!
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 05/17] ARM: dts: sunxi: Enable thermal sensor support for RTP on sun[457]i
From: Maxime Ripard @ 2015-01-06 15:52 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Dmitry Torokhov, Zhang Rui, Eduardo Valentin, Hans de Goede,
linux-input, linux-arm-kernel, linux-pm
In-Reply-To: <1420511727-8242-6-git-send-email-wens@csie.org>
[-- Attachment #1: Type: text/plain, Size: 412 bytes --]
On Tue, Jan 06, 2015 at 10:35:15AM +0800, Chen-Yu Tsai wrote:
> Now that the resistive touchpanel driver supports thermal sensors,
> add the "#thermal-sensor-cells" property as required by the thermal
> framework.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 16/17] ARM: sunxi_defconfig: Enable TOUCHSCREEN_SUN4I, CPUFREQ_DT, CPU_THERMAL
From: Eduardo Valentin @ 2015-01-06 15:32 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Maxime Ripard, Dmitry Torokhov, Zhang Rui, Hans de Goede,
linux-input, linux-arm-kernel, linux-pm
In-Reply-To: <1420511727-8242-17-git-send-email-wens@csie.org>
[-- Attachment #1: Type: text/plain, Size: 1493 bytes --]
On Tue, Jan 06, 2015 at 10:35:26AM +0800, Chen-Yu Tsai wrote:
> This patch enables TOUCHSCREEN_SUN4I, CPUFREQ_DT, and CPU_THERMAL to
> enable cpufreq support with passive cpu cooling (thermal throttling)
> by default.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
For the thermal part:
Acked-by: Eduardo Valentin <edubezval@gmail.com>
> ---
> arch/arm/configs/sunxi_defconfig | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig
> index 7a342d2780a8..46a8688bd49a 100644
> --- a/arch/arm/configs/sunxi_defconfig
> +++ b/arch/arm/configs/sunxi_defconfig
> @@ -9,6 +9,8 @@ CONFIG_HIGHMEM=y
> CONFIG_HIGHPTE=y
> CONFIG_ARM_APPENDED_DTB=y
> CONFIG_ARM_ATAG_DTB_COMPAT=y
> +CONFIG_CPU_FREQ=y
> +CONFIG_CPUFREQ_DT=y
> CONFIG_VFP=y
> CONFIG_NEON=y
> CONFIG_PM=y
> @@ -54,6 +56,8 @@ CONFIG_STMMAC_ETH=y
> # CONFIG_INPUT_MOUSEDEV is not set
> # CONFIG_INPUT_KEYBOARD is not set
> # CONFIG_INPUT_MOUSE is not set
> +CONFIG_INPUT_TOUCHSCREEN=y
> +CONFIG_TOUCHSCREEN_SUN4I=y
> CONFIG_SERIAL_8250=y
> CONFIG_SERIAL_8250_CONSOLE=y
> CONFIG_SERIAL_8250_NR_UARTS=8
> @@ -71,7 +75,8 @@ CONFIG_GPIO_SYSFS=y
> CONFIG_POWER_SUPPLY=y
> CONFIG_POWER_RESET=y
> CONFIG_POWER_RESET_SUN6I=y
> -# CONFIG_HWMON is not set
> +CONFIG_THERMAL=y
> +CONFIG_CPU_THERMAL=y
> CONFIG_WATCHDOG=y
> CONFIG_SUNXI_WATCHDOG=y
> CONFIG_MFD_AXP20X=y
> --
> 2.1.4
>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* Re: [PATCH 17/17] ARM: multi_v7_defconfig: Enable TOUCHSCREEN_SUN4I, CPU_THERMAL
From: Eduardo Valentin @ 2015-01-06 15:31 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Maxime Ripard, Dmitry Torokhov, Zhang Rui, Hans de Goede,
linux-input, linux-arm-kernel, linux-pm
In-Reply-To: <1420511727-8242-18-git-send-email-wens@csie.org>
[-- Attachment #1: Type: text/plain, Size: 1178 bytes --]
On Tue, Jan 06, 2015 at 10:35:27AM +0800, Chen-Yu Tsai wrote:
> This patch enables TOUCHSCREEN_SUN4I and CPU_THERMAL to enable cpufreq
> support with passive cpu cooling (thermal throttling) on sunxi by default.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
for the CPU_THERMAL
Acked-by: Eduardo Valentin <edubezval@gmail.com>
> ---
> arch/arm/configs/multi_v7_defconfig | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
> index 2328fe752e9c..0e7159ad269b 100644
> --- a/arch/arm/configs/multi_v7_defconfig
> +++ b/arch/arm/configs/multi_v7_defconfig
> @@ -189,6 +189,7 @@ CONFIG_MOUSE_PS2_ELANTECH=y
> CONFIG_INPUT_TOUCHSCREEN=y
> CONFIG_TOUCHSCREEN_ATMEL_MXT=y
> CONFIG_TOUCHSCREEN_STMPE=y
> +CONFIG_TOUCHSCREEN_SUN4I=y
> CONFIG_INPUT_MISC=y
> CONFIG_INPUT_MPU3050=y
> CONFIG_SERIO_AMBAKMI=y
> @@ -267,6 +268,7 @@ CONFIG_POWER_RESET_SUN6I=y
> CONFIG_SENSORS_LM90=y
> CONFIG_SENSORS_LM95245=y
> CONFIG_THERMAL=y
> +CONFIG_CPU_THERMAL=y
> CONFIG_ARMADA_THERMAL=y
> CONFIG_ST_THERMAL_SYSCFG=y
> CONFIG_ST_THERMAL_MEMMAP=y
> --
> 2.1.4
>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* Re: [PATCH 11/17] ARM: dts: sun5i: Add cpu thermal zones to dtsi
From: Eduardo Valentin @ 2015-01-06 15:30 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Maxime Ripard, Dmitry Torokhov, Zhang Rui, Hans de Goede,
linux-input, linux-arm-kernel, linux-pm
In-Reply-To: <1420511727-8242-12-git-send-email-wens@csie.org>
[-- Attachment #1: Type: text/plain, Size: 1559 bytes --]
On Tue, Jan 06, 2015 at 10:35:21AM +0800, Chen-Yu Tsai wrote:
> The core temperature sensor now supports thermal zones. Add a thermal
> zone mapping for the cpus with passive cooling (cpufreq throttling).
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> ---
> arch/arm/boot/dts/sun5i-a13.dtsi | 32 ++++++++++++++++++++++++++++++++
> 1 file changed, 32 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun5i-a13.dtsi b/arch/arm/boot/dts/sun5i-a13.dtsi
> index dd93d227865e..9140cc7c8944 100644
> --- a/arch/arm/boot/dts/sun5i-a13.dtsi
> +++ b/arch/arm/boot/dts/sun5i-a13.dtsi
> @@ -47,6 +47,38 @@
> };
> };
>
> + thermal-zones {
> + cpu_thermal {
> + /* milliseconds */
> + polling-delay-passive = <250>;
> + polling-delay = <1000>;
> + thermal-sensors = <&rtp>;
> +
> + cooling-maps {
> + map0 {
> + trip = <&cpu_alert0>;
> + cooling-device = <&cpu0 (-1) (-1)>;
same
Could you please:
+#include <dt-bindings/thermal/thermal.h>
and
+ cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
?
> + };
> + };
> +
> + trips {
> + cpu_alert0: cpu_alert0 {
> + /* milliCelsius */
> + temperature = <850000>;
> + hysteresis = <2000>;
> + type = "passive";
> + };
> +
> + cpu_crit: cpu_crit {
> + /* milliCelsius */
> + temperature = <100000>;
> + hysteresis = <2000>;
> + type = "critical";
> + };
> + };
> + };
> + };
> +
> memory {
> reg = <0x40000000 0x20000000>;
> };
> --
> 2.1.4
>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* Re: [PATCH 14/17] ARM: dts: sun4i: Add cpu thermal zones to dtsi
From: Eduardo Valentin @ 2015-01-06 15:29 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Maxime Ripard, Dmitry Torokhov, Zhang Rui, Hans de Goede,
linux-input, linux-arm-kernel, linux-pm
In-Reply-To: <1420511727-8242-15-git-send-email-wens@csie.org>
[-- Attachment #1: Type: text/plain, Size: 1557 bytes --]
On Tue, Jan 06, 2015 at 10:35:24AM +0800, Chen-Yu Tsai wrote:
> The core temperature sensor now supports thermal zones. Add a thermal
> zone mapping for the cpus with passive cooling (cpufreq throttling).
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> ---
> arch/arm/boot/dts/sun4i-a10.dtsi | 32 ++++++++++++++++++++++++++++++++
> 1 file changed, 32 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
> index ce3af83dd80b..eb626833ac86 100644
> --- a/arch/arm/boot/dts/sun4i-a10.dtsi
> +++ b/arch/arm/boot/dts/sun4i-a10.dtsi
> @@ -64,6 +64,38 @@
> };
> };
>
> + thermal-zones {
> + cpu_thermal {
> + /* milliseconds */
> + polling-delay-passive = <250>;
> + polling-delay = <1000>;
> + thermal-sensors = <&rtp>;
> +
> + cooling-maps {
> + map0 {
> + trip = <&cpu_alert0>;
> + cooling-device = <&cpu0 (-1) (-1)>;
same
Could you please:
+#include <dt-bindings/thermal/thermal.h>
and
+ cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
?
> + };
> + };
> +
> + trips {
> + cpu_alert0: cpu_alert0 {
> + /* milliCelsius */
> + temperature = <850000>;
> + hysteresis = <2000>;
> + type = "passive";
> + };
> +
> + cpu_crit: cpu_crit {
> + /* milliCelsius */
> + temperature = <100000>;
> + hysteresis = <2000>;
> + type = "critical";
> + };
> + };
> + };
> + };
> +
> memory {
> reg = <0x40000000 0x80000000>;
> };
> --
> 2.1.4
>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* Re: [PATCH 07/17] ARM: dts: sun7i: Add cpu thermal zones to dtsi
From: Eduardo Valentin @ 2015-01-06 15:28 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Maxime Ripard, Dmitry Torokhov, Zhang Rui, Hans de Goede,
linux-input, linux-arm-kernel, linux-pm
In-Reply-To: <1420511727-8242-8-git-send-email-wens@csie.org>
[-- Attachment #1: Type: text/plain, Size: 1548 bytes --]
On Tue, Jan 06, 2015 at 10:35:17AM +0800, Chen-Yu Tsai wrote:
> The core temperature sensor now supports thermal zones. Add a thermal
> zone mapping for the cpus with passive cooling (cpufreq throttling).
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> ---
> arch/arm/boot/dts/sun7i-a20.dtsi | 32 ++++++++++++++++++++++++++++++++
> 1 file changed, 32 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
> index 887b0521bbfb..951e99ed3aa9 100644
> --- a/arch/arm/boot/dts/sun7i-a20.dtsi
> +++ b/arch/arm/boot/dts/sun7i-a20.dtsi
> @@ -111,6 +111,38 @@
> };
> };
>
> + thermal-zones {
> + cpu_thermal {
> + /* milliseconds */
> + polling-delay-passive = <250>;
> + polling-delay = <1000>;
> + thermal-sensors = <&rtp>;
> +
> + cooling-maps {
> + map0 {
> + trip = <&cpu_alert0>;
> + cooling-device = <&cpu0 (-1) (-1)>;
Could you please:
+#include <dt-bindings/thermal/thermal.h>
and
+ cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
?
> + };
> + };
> +
> + trips {
> + cpu_alert0: cpu_alert0 {
> + /* milliCelsius */
> + temperature = <75000>;
> + hysteresis = <2000>;
> + type = "passive";
> + };
> +
> + cpu_crit: cpu_crit {
> + /* milliCelsius */
> + temperature = <100000>;
> + hysteresis = <2000>;
> + type = "critical";
> + };
> + };
> + };
> + };
> +
> memory {
> reg = <0x40000000 0x80000000>;
> };
> --
> 2.1.4
>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* Re: [PATCH 05/17] ARM: dts: sunxi: Enable thermal sensor support for RTP on sun[457]i
From: Eduardo Valentin @ 2015-01-06 15:25 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Maxime Ripard, Dmitry Torokhov, Zhang Rui, Hans de Goede,
linux-input, linux-arm-kernel, linux-pm
In-Reply-To: <1420511727-8242-6-git-send-email-wens@csie.org>
[-- Attachment #1: Type: text/plain, Size: 2255 bytes --]
On Tue, Jan 06, 2015 at 10:35:15AM +0800, Chen-Yu Tsai wrote:
> Now that the resistive touchpanel driver supports thermal sensors,
> add the "#thermal-sensor-cells" property as required by the thermal
> framework.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Eduardo Valentin <edubezval@gmail.com>
> ---
> arch/arm/boot/dts/sun4i-a10.dtsi | 1 +
> arch/arm/boot/dts/sun5i-a10s.dtsi | 1 +
> arch/arm/boot/dts/sun5i-a13.dtsi | 1 +
> arch/arm/boot/dts/sun7i-a20.dtsi | 1 +
> 4 files changed, 4 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
> index 847d5e09fcfb..f92635ecb937 100644
> --- a/arch/arm/boot/dts/sun4i-a10.dtsi
> +++ b/arch/arm/boot/dts/sun4i-a10.dtsi
> @@ -712,6 +712,7 @@
> compatible = "allwinner,sun4i-a10-ts";
> reg = <0x01c25000 0x100>;
> interrupts = <29>;
> + #thermal-sensor-cells = <0>;
> };
>
> uart0: serial@01c28000 {
> diff --git a/arch/arm/boot/dts/sun5i-a10s.dtsi b/arch/arm/boot/dts/sun5i-a10s.dtsi
> index 3c3c1920788a..8d324ef7e46e 100644
> --- a/arch/arm/boot/dts/sun5i-a10s.dtsi
> +++ b/arch/arm/boot/dts/sun5i-a10s.dtsi
> @@ -535,6 +535,7 @@
> compatible = "allwinner,sun4i-a10-ts";
> reg = <0x01c25000 0x100>;
> interrupts = <29>;
> + #thermal-sensor-cells = <0>;
> };
>
> uart0: serial@01c28000 {
> diff --git a/arch/arm/boot/dts/sun5i-a13.dtsi b/arch/arm/boot/dts/sun5i-a13.dtsi
> index 2448d7f38d6b..4fe0bd192e29 100644
> --- a/arch/arm/boot/dts/sun5i-a13.dtsi
> +++ b/arch/arm/boot/dts/sun5i-a13.dtsi
> @@ -469,6 +469,7 @@
> compatible = "allwinner,sun4i-a10-ts";
> reg = <0x01c25000 0x100>;
> interrupts = <29>;
> + #thermal-sensor-cells = <0>;
> };
>
> uart1: serial@01c28400 {
> diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
> index e21ce5992d56..01c7133e699c 100644
> --- a/arch/arm/boot/dts/sun7i-a20.dtsi
> +++ b/arch/arm/boot/dts/sun7i-a20.dtsi
> @@ -926,6 +926,7 @@
> compatible = "allwinner,sun4i-a10-ts";
> reg = <0x01c25000 0x100>;
> interrupts = <0 29 4>;
> + #thermal-sensor-cells = <0>;
> };
>
> uart0: serial@01c28000 {
> --
> 2.1.4
>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* Re: [PATCH 03/17] Input: sun4i-ts: Add thermal zone sensor support
From: Eduardo Valentin @ 2015-01-06 15:24 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Maxime Ripard, Dmitry Torokhov, Zhang Rui, Hans de Goede,
linux-input, linux-arm-kernel, linux-pm
In-Reply-To: <1420511727-8242-4-git-send-email-wens@csie.org>
[-- Attachment #1: Type: text/plain, Size: 3720 bytes --]
Hello Chen-Yu,
On Tue, Jan 06, 2015 at 10:35:13AM +0800, Chen-Yu Tsai wrote:
> The touchscreen controller has a temperature sensor embedded in the SoC,
> which already has hwmon support in the driver.
>
> Add DT thermal zone support so we can use it with cpufreq for thermal
> throttling.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> ---
> .../bindings/input/touchscreen/sun4i.txt | 1 +
> drivers/input/touchscreen/sun4i-ts.c | 27 ++++++++++++++++++++++
> 2 files changed, 28 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/sun4i.txt b/Documentation/devicetree/bindings/input/touchscreen/sun4i.txt
> index aef57791f40b..7f1110adbd24 100644
> --- a/Documentation/devicetree/bindings/input/touchscreen/sun4i.txt
> +++ b/Documentation/devicetree/bindings/input/touchscreen/sun4i.txt
> @@ -5,6 +5,7 @@ Required properties:
> - compatible: "allwinner,sun4i-a10-ts"
> - reg: mmio address range of the chip
> - interrupts: interrupt to which the chip is connected
> + - #thermal-sensor-cells: shall be 0
>
You may want to update your Example section too, below.
Example:
rtp: rtp@01c25000 {
compatible = "allwinner,sun4i-a10-ts";
reg = <0x01c25000 0x100>;
interrupts = <29>;
allwinner,ts-attached;
#thermal-sensor-cells = <0>;
};
> Optional properties:
> - allwinner,ts-attached: boolean indicating that an actual touchscreen is
> diff --git a/drivers/input/touchscreen/sun4i-ts.c b/drivers/input/touchscreen/sun4i-ts.c
> index 28a06749ae42..b6e9043446d6 100644
> --- a/drivers/input/touchscreen/sun4i-ts.c
> +++ b/drivers/input/touchscreen/sun4i-ts.c
> @@ -34,6 +34,7 @@
>
> #include <linux/err.h>
> #include <linux/hwmon.h>
> +#include <linux/thermal.h>
> #include <linux/init.h>
> #include <linux/input.h>
> #include <linux/interrupt.h>
> @@ -107,6 +108,7 @@
> struct sun4i_ts_data {
> struct device *dev;
> struct input_dev *input;
> + struct thermal_zone_device *tz;
> void __iomem *base;
> unsigned int irq;
> bool ignore_fifo_data;
> @@ -180,6 +182,23 @@ static void sun4i_ts_close(struct input_dev *dev)
> writel(TEMP_IRQ_EN(1), ts->base + TP_INT_FIFOC);
> }
>
> +static int get_temp(void *data, long *temp)
> +{
> + struct sun4i_ts_data *ts = data;
> +
> + /* No temp_data until the first irq */
> + if (ts->temp_data == -1)
> + return -EAGAIN;
> +
> + *temp = (ts->temp_data - 1447) * 100;
> +
Care to explain the formula in a simple comment?
> + return 0;
> +}
> +
> +static struct thermal_zone_of_device_ops sun4i_ts_tz_ops = {
> + .get_temp = get_temp,
> +};
> +
> static ssize_t show_temp(struct device *dev, struct device_attribute *devattr,
> char *buf)
> {
> @@ -288,6 +307,11 @@ static int sun4i_ts_probe(struct platform_device *pdev)
> if (IS_ERR(hwmon))
> return PTR_ERR(hwmon);
>
> + ts->tz = thermal_zone_of_sensor_register(ts->dev, 0, ts,
> + &sun4i_ts_tz_ops);
> + if (IS_ERR(ts->tz))
> + ts->tz = NULL;
> +
> writel(TEMP_IRQ_EN(1), ts->base + TP_INT_FIFOC);
>
> if (ts_attached) {
here.. if input_register_device fails, you will keep an orphan thermal zone
registered in your system:
error = input_register_device(ts->input);
if (error) {
writel(0, ts->base + TP_INT_FIFOC);
return error;
}
...
> @@ -310,6 +334,9 @@ static int sun4i_ts_remove(struct platform_device *pdev)
> if (ts->input)
> input_unregister_device(ts->input);
>
> + if (ts->tz)
> + thermal_zone_of_sensor_unregister(ts->dev, ts->tz);
> +
> /* Deactivate all IRQs */
> writel(0, ts->base + TP_INT_FIFOC);
>
> --
> 2.1.4
>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* Re: [PATCH] hid: Initialize battery_no to -1 & correct its format string
From: Aniroop Mathur @ 2015-01-06 14:32 UTC (permalink / raw)
To: Jason Gerecke, Ping Cheng, Jiri Kosina
Cc: linux-input@vger.kernel.org, linux-kernel, a.mathur
In-Reply-To: <alpine.LNX.2.00.1412291302470.1680@pobox.suse.cz>
Dear Mr. Jason and Mr. Ping,
Please update about below patch.
Except avoiding subtraction, there is also a need to avoid negative
battery name which may come due to %ld, so need to change to %lu.
Thanks,
Aniroop
On Mon, Dec 29, 2014 at 5:33 PM, Jiri Kosina <jkosina@suse.cz> wrote:
> On Sun, 28 Dec 2014, Aniroop Mathur wrote:
>
>> From: Aniroop Mathur <a.mathur@samsung.com>
>>
>> This patch initializes battery_no to -1 to avoid extra subtraction
>> operation performed everytime wacom battery is initialized
>
> This is so femto-optimization, that I don't really care deeply. Adding
> Jason and Ping to CC. If they want this, I'll apply the patch.
>
>> and correct format string of unsigned long from %ld to %lu.
>>
>> Signed-off-by: Aniroop Mathur <a.mathur@samsung.com>
>> ---
>> drivers/hid/wacom_sys.c | 8 ++++----
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
>> index 129fd33..4b5ff84 100644
>> --- a/drivers/hid/wacom_sys.c
>> +++ b/drivers/hid/wacom_sys.c
>> @@ -919,17 +919,17 @@ static int wacom_ac_get_property(struct power_supply *psy,
>>
>> static int wacom_initialize_battery(struct wacom *wacom)
>> {
>> - static atomic_t battery_no = ATOMIC_INIT(0);
>> + static atomic_t battery_no = ATOMIC_INIT(-1);
>> int error;
>> unsigned long n;
>>
>> if (wacom->wacom_wac.features.quirks & WACOM_QUIRK_BATTERY) {
>> - n = atomic_inc_return(&battery_no) - 1;
>> + n = atomic_inc_return(&battery_no);
>>
>> wacom->battery.properties = wacom_battery_props;
>> wacom->battery.num_properties = ARRAY_SIZE(wacom_battery_props);
>> wacom->battery.get_property = wacom_battery_get_property;
>> - sprintf(wacom->wacom_wac.bat_name, "wacom_battery_%ld", n);
>> + sprintf(wacom->wacom_wac.bat_name, "wacom_battery_%lu", n);
>> wacom->battery.name = wacom->wacom_wac.bat_name;
>> wacom->battery.type = POWER_SUPPLY_TYPE_BATTERY;
>> wacom->battery.use_for_apm = 0;
>> @@ -937,7 +937,7 @@ static int wacom_initialize_battery(struct wacom *wacom)
>> wacom->ac.properties = wacom_ac_props;
>> wacom->ac.num_properties = ARRAY_SIZE(wacom_ac_props);
>> wacom->ac.get_property = wacom_ac_get_property;
>> - sprintf(wacom->wacom_wac.ac_name, "wacom_ac_%ld", n);
>> + sprintf(wacom->wacom_wac.ac_name, "wacom_ac_%lu", n);
>> wacom->ac.name = wacom->wacom_wac.ac_name;
>> wacom->ac.type = POWER_SUPPLY_TYPE_MAINS;
>> wacom->ac.use_for_apm = 0;
>> --
>> 1.9.1
>>
>
> --
> Jiri Kosina
> SUSE Labs
^ permalink raw reply
* Re: [PATCH trivial] HID: Spelling s/Keayboard/Keyboard/
From: Benjamin Tissoires @ 2015-01-06 14:28 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Jiri Kosina, linux-input, linux-kernel
In-Reply-To: <1420531753-10668-1-git-send-email-geert@linux-m68k.org>
On Jan 06 2015 or thereabouts, Geert Uytterhoeven wrote:
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Good catch.
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cheers,
Benjamin
> ---
> drivers/hid/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
> index 230b6f887cd86e9b..303b295a5413d39b 100644
> --- a/drivers/hid/Kconfig
> +++ b/drivers/hid/Kconfig
> @@ -388,7 +388,7 @@ config HID_LOGITECH_HIDPP
> Say Y if you want support for Logitech devices relying on the HID++
> specification. Such devices are the various Logitech Touchpads (T650,
> T651, TK820), some mice (Zone Touch mouse), or even keyboards (Solar
> - Keayboard).
> + Keyboard).
>
> config LOGITECH_FF
> bool "Logitech force feedback support"
> --
> 1.9.1
>
^ permalink raw reply
* Re: [PATCH] Add VID/PID for HID-type Multi-Touch Module of AFO CO., LTD.
From: Benjamin Tissoires @ 2015-01-06 14:26 UTC (permalink / raw)
To: kyhw; +Cc: Jiri Kosina, Henrik Rydberg, linux-input,
linux-kernel@vger.kernel.org
In-Reply-To: <001701d02992$37f595f0$a7e0c1d0$@co.kr>
Hi,
On Tue, Jan 6, 2015 at 4:21 AM, kyhw <kyhw@afoi.co.kr> wrote:
> Thanks.
>
> you are right. That's not necessary.
> We already processed.
>
> The final purpose of my approach is that the correct working of the AFO
> multi-Touch module in All distribution of Linux.
> Therefore, the inclusion of the VID,PID(AFO Touch Module) to the
> hid-multitouch module is basically needed also for old version of the Linux
> distribution.
Well, I'd like to keep hid-multitouch as clean as possible regarding
the specific vendor devices. So, if your device is already auto
detected in a let's say 3.18 and works as expected, (i.e. if the
CLS_SERIAL is automatically picked up), then I will oppose to your
patch. For the reference, I killed all the vendor specific useless
definitions in 0fa9c61618.
Distributions should either update to a more recent kernel (I think
the auto detection of CLS_SERIAL was in 3.10 or even before), or they
should cook their own support, or backport. There is no need to have a
useless list of devices in the upstream kernel.
Cheers,
Benjamin
>
> Ki.
>
> -----Original Message-----
> From: Jiri Kosina [mailto:jkosina@suse.cz]
> Sent: Tuesday, May 20, 2014 11:44 PM
> To: YongHwan Ki
> Cc: rydberg@euromail.se; linux-input@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: RE: [PATCH] Add VID/PID for HID-type Multi-Touch Module of AFO CO.,
> LTD.
>
> On Wed, 26 Mar 2014, YongHwan Ki wrote:
>
>> Sorry, I woud like to add the AFO defines in the Linux Kernel.
>> No afo defines exists in the current kernel tree.
>> I correctly changed the log for adding the afo defines.
>>
>> Kernel Version : linux-3.14.rc7
>> Signed-off-by: Yonghwan Ki <kyhw@afoi.co.kr>
>>
>> diff -uprN -X Documentation/dontdiff ./drivers/hid/hid-core.c
> ../linux-3.14-rc7m/drivers/hid/hid-core.c
>> --- ./drivers/hid/hid-core.c 2014-03-17 10:51:24.000000000 +0900
>> +++ ../linux-3.14-rc7m/drivers/hid/hid-core.c 2014-03-21
> 17:41:51.846939444 +0900
>> @@ -1881,6 +1881,8 @@ static const struct hid_device_id hid_ha
>> { HID_USB_DEVICE(USB_VENDOR_ID_ZEROPLUS, 0x0005) },
>> { HID_USB_DEVICE(USB_VENDOR_ID_ZEROPLUS, 0x0030) },
>> { HID_USB_DEVICE(USB_VENDOR_ID_ZYDACRON,
>> USB_DEVICE_ID_ZYDACRON_REMOTE_CONTROL) },
>> + { HID_USB_DEVICE(USB_VENDOR_ID_AFO, USB_DEVICE_ID_AFO_TCM) },
>> + { HID_USB_DEVICE(USB_VENDOR_ID_AFO, USB_DEVICE_ID_AFO_THM) },
>
> Is this really necessary? Why doesn't HID_DG_CONTACTID matching work for the
> to automatically trigger HID_GROUP_MULTITOUCH-based binding?
>
> --
> Jiri Kosina
> SUSE Labs
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: hid-replay captured data
From: Benjamin Tissoires @ 2015-01-06 14:16 UTC (permalink / raw)
To: josep.sanchez.ferreres
Cc: linux-input, Ping Cheng, Jason Gerecke, Aaron Skomra
In-Reply-To: <20150106111652.hwprplncqocwo0w0@webmail.fib.upc.es>
On Tue, Jan 6, 2015 at 5:16 AM, <josep.sanchez.ferreres@est.fib.upc.edu> wrote:
> Hello!
>
> I'm not sure about what you meant by using evemu-record to record
> the data from hidraw3. As far as I know evemu-record is only able to
> record from the /dev/input interfaces right? If you meant hid-replay, I
> wasn't able to get any data from hidraw3.
Sorry, I meant hid-replay.
I need the output of the very first lines when you open the device.
There must be 3 lines at least, one starting with R:, one with I: and
one with N:
And yes, I know no events will be sent, but I need the output still.
Cheers,
Benjamin
PS: please use "reply-all" when replying to a thread to keep the
people involved in the loop.
>
> Could you please provide a more detailed explanation so I can get the data?
>
> Thank you very much!
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] Input:Flush client events after clk_type change
From: Anshul Garg @ 2015-01-06 14:02 UTC (permalink / raw)
To: dmitry.torokhov, dtor, linux-input; +Cc: aksgarg1989, anshul.g
In-Reply-To: <anshul.g>
From: Anshul Garg <aksgarg1989@gmail.com>
Since the client clk_type is changed , flush pending
events from client buffer and queue SYN_DROPPED event.
Added check for duplicate clk_type change request.
Signed-off-by: Anshul Garg <anshul.g@samsung.com>
---
drivers/input/evdev.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
index b1a52ab..91330e1 100644
--- a/drivers/input/evdev.c
+++ b/drivers/input/evdev.c
@@ -64,6 +64,9 @@ struct evdev_client {
static int evdev_set_clk_type(struct evdev_client *client, unsigned int clkid)
{
+ if (client->clk_type == clkid)
+ return 0;
+
switch (clkid) {
case CLOCK_REALTIME:
@@ -78,7 +81,11 @@ static int evdev_set_clk_type(struct evdev_client *client, unsigned int clkid)
default:
return -EINVAL;
}
-
+
+ /* Flush clients events after clk_type is changed
+ * and queue SYN_DROPPED event.*/
+ client->packet_head = client->head = client->tail;
+ evdev_queue_syn_dropped(client);
return 0;
}
--
1.7.9.5
---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com
^ permalink raw reply related
* Re: [PATCH] input: adxl34x: Add OF match support
From: Geert Uytterhoeven @ 2015-01-06 13:28 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Wolfram Sang, Laurent Pinchart, linux-input@vger.kernel.org,
Linux-sh list, Linux I2C
In-Reply-To: <10011053.aypz0IuTJG@avalon>
Hi Laurent, Wolfram,
On Thu, Dec 18, 2014 at 8:23 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Thursday 18 December 2014 14:03:18 Geert Uytterhoeven wrote:
>> On Thu, Dec 18, 2014 at 1:49 PM, Laurent Pinchart wrote:
>> > There are three compatible strings defined for the ADXL345 and ADXL346 in
>> > Documentation/devicetree/bindings/i2c/trivial-devices.txt: "adi,adxl345",
>> > "adi,adxl346", "adi,adxl34x". Given that the last one is a fallback for
>> > the first two I don't see a need to add the specific compatible strings to
>> > the driver for now. If a new totally incompatible chip named ADXL347 comes
>> > out we will need a new driver which won't be allowed to use the
>> > "adi,adxl34x" compatible string.
>>
>> FWIW, I'm the evil person who added the adxl entries to that file...
>
> git-blame had already reported you.
>
> Do you think we should remove that compatible string ?
Remove it from trivial-devices.txt, or from the .dts?
Can't we just fix i2c_device_match(), to consider all compatible values
of the device's node instead of just the first one when doing a legacy match?
For now, I'd remove the "adi,adxl345" entry from sh73a0-kzm9g.dts,
until matching is fixed.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [RFC] [Patch] implement video driver for sur40
From: Hans Verkuil @ 2015-01-06 13:01 UTC (permalink / raw)
To: Florian Echtler; +Cc: linux-input, linux-media
In-Reply-To: <54ABD08C.7010107@butterbrot.org>
On 01/06/2015 01:09 PM, Florian Echtler wrote:
> On 06.01.2015 11:23, Hans Verkuil wrote:
>> On 01/06/2015 11:17 AM, Florian Echtler wrote:
>>>> You're not filling in the 'field' field of struct v4l2_buffer when returning a
>>>> frame. It should most likely be FIELD_NONE in your case.
>>>>> fail: v4l2-test-buffers.cpp(611): buf.check(q, last_seq)
>>>>> fail: v4l2-test-buffers.cpp(884): captureBufs(node, q, m2m_q, frame_count, false)
>>> OK, easy to fix. This will also influence the other two warnings, I assume?
>> Most likely, yes.
> Done. I would say that it's nearly ready for submission now (all tests
> from v4l2-compliance -s pass), I still have to sort out all the warnings
> from scripts/checkpatch.pl.
>
>>>>> On a different note, I'm getting occasional warnings in syslog when I run
>>>>> a regular video streaming application (e.g. cheese):
>>> Is there another possible explanation?
>> No :-)
>> You are still missing a buffer somewhere. I'd have to see your latest source code
>> to see what's wrong.
> Weirdly enough, the syslog warning/error doesn't seem to occur anymore
> since I've fixed the v4l2_buffer field. Perhaps some oddity within cheese?
>
> I'm attaching the current source again for you to maybe have another
> look; I will submit a proper patch in the next days.
Just a few quick remarks:
- run scripts/checkpatch.pl over your source, I'm fairly certain it will complain
about several constructs.
- use videobuf2-vmalloc instead of dma-contig. There is no DMA involved, so there
is no reason to use dma-contig.
- Don't set V4L2_CAP_EXT_PIX_FORMAT in querycap: it will be set automatically by
the v4l2 core.
Regards,
Hans
^ permalink raw reply
* Re: [PATCH] HID: input: fix confusion on conflicting mappings
From: David Herrmann @ 2015-01-06 12:47 UTC (permalink / raw)
To: Fredrik Hallenberg; +Cc: Christopher Head, open list:HID CORE LAYER
In-Reply-To: <CAMsZVf_UT+m_8BWqz0+aYGJB+8Z_u6xRU7efLZ-Bd7WNhn4ZYA@mail.gmail.com>
Hi
On Tue, Jan 6, 2015 at 1:37 PM, Fredrik Hallenberg <megahallon@gmail.com> wrote:
> I can confirm that the patch breaks things when not using n key
> rollover. If using the Corsair K70 in "BIOS mode" or just using a
> plain USB-keyboard keys repeat forever as reported.
>
> David, I noticed that in the first version of your patch, where the
> ignore check was done in hid-core.c, you only checked events that had
> the HID_MAIN_ITEM_VARIABLE flag set. I can see that "plain" keyboards
> don't have this bit set on the release event so if I keep this check
> in the new patch it works in both cases.
>
> So, the if-clause now looks like this:
>
> ...
> if (!(field->flags & (HID_MAIN_ITEM_RELATIVE |
> HID_MAIN_ITEM_BUFFERED_BYTE)) &&
> (field->flags & HID_MAIN_ITEM_VARIABLE) &&
> usage->usage_index < field->maxusage &&
> value == field->value[usage->usage_index]) {
> ...
Nice catch! Of course, we must not apply this to ARRAY reports. I will
send v2 tomorrow (still on the road..).
Thanks
David
^ permalink raw reply
* Re: [PATCH] HID: input: fix confusion on conflicting mappings
From: Fredrik Hallenberg @ 2015-01-06 12:37 UTC (permalink / raw)
To: Christopher Head, David Herrmann; +Cc: open list:HID CORE LAYER
In-Reply-To: <20141230165739.050cc0b9@kruskal.home.chead.ca>
I can confirm that the patch breaks things when not using n key
rollover. If using the Corsair K70 in "BIOS mode" or just using a
plain USB-keyboard keys repeat forever as reported.
David, I noticed that in the first version of your patch, where the
ignore check was done in hid-core.c, you only checked events that had
the HID_MAIN_ITEM_VARIABLE flag set. I can see that "plain" keyboards
don't have this bit set on the release event so if I keep this check
in the new patch it works in both cases.
So, the if-clause now looks like this:
...
if (!(field->flags & (HID_MAIN_ITEM_RELATIVE |
HID_MAIN_ITEM_BUFFERED_BYTE)) &&
(field->flags & HID_MAIN_ITEM_VARIABLE) &&
usage->usage_index < field->maxusage &&
value == field->value[usage->usage_index]) {
...
On Wed, Dec 31, 2014 at 1:57 AM, Christopher Head <chead@chead.ca> wrote:
> Hi,
> I tried your patch on my North American Das Keyboard 4. In N-key
> rollover mode the patch fixes the backslash problem. Unfortunately,
> with the patch applied, when in 6-key rollover mode (which, if I
> remember correctly, uses a one-byte DATA VAR ABS for modifiers and a
> six-byte DATA ARRAY ABS for other keys, as usual for keyboards), the
> last typed key repeats forever even after being released.
>
> (Apologies for the lack of In-Reply-To header; I am not subscribed to
> the list so had no message to reply to. Please CC me in replies if
> necessary.)
> --
> Christopher Head
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC] [Patch] implement video driver for sur40
From: Florian Echtler @ 2015-01-06 12:09 UTC (permalink / raw)
To: Hans Verkuil; +Cc: linux-input, linux-media
In-Reply-To: <54ABB79D.7010700@xs4all.nl>
[-- Attachment #1.1: Type: text/plain, Size: 1332 bytes --]
On 06.01.2015 11:23, Hans Verkuil wrote:
> On 01/06/2015 11:17 AM, Florian Echtler wrote:
>>> You're not filling in the 'field' field of struct v4l2_buffer when returning a
>>> frame. It should most likely be FIELD_NONE in your case.
>>>> fail: v4l2-test-buffers.cpp(611): buf.check(q, last_seq)
>>>> fail: v4l2-test-buffers.cpp(884): captureBufs(node, q, m2m_q, frame_count, false)
>> OK, easy to fix. This will also influence the other two warnings, I assume?
> Most likely, yes.
Done. I would say that it's nearly ready for submission now (all tests
from v4l2-compliance -s pass), I still have to sort out all the warnings
from scripts/checkpatch.pl.
>>>> On a different note, I'm getting occasional warnings in syslog when I run
>>>> a regular video streaming application (e.g. cheese):
>> Is there another possible explanation?
> No :-)
> You are still missing a buffer somewhere. I'd have to see your latest source code
> to see what's wrong.
Weirdly enough, the syslog warning/error doesn't seem to occur anymore
since I've fixed the v4l2_buffer field. Perhaps some oddity within cheese?
I'm attaching the current source again for you to maybe have another
look; I will submit a proper patch in the next days.
Thanks again for your help!
Best, Florian
--
SENT FROM MY DEC VT50 TERMINAL
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: sur40.c --]
[-- Type: text/x-csrc; name="sur40.c", Size: 25370 bytes --]
/*
* Surface2.0/SUR40/PixelSense input driver
*
* Copyright (c) 2013 by Florian 'floe' Echtler <floe@butterbrot.org>
*
* Derived from the USB Skeleton driver 1.1,
* Copyright (c) 2003 Greg Kroah-Hartman (greg@kroah.com)
*
* and from the Apple USB BCM5974 multitouch driver,
* Copyright (c) 2008 Henrik Rydberg (rydberg@euromail.se)
*
* and from the generic hid-multitouch driver,
* Copyright (c) 2010-2012 Stephane Chatty <chatty@enac.fr>
*
* 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.
*/
#include <linux/kernel.h>
#include <linux/errno.h>
#include <linux/delay.h>
#include <linux/init.h>
#include <linux/slab.h>
#include <linux/module.h>
#include <linux/completion.h>
#include <linux/uaccess.h>
#include <linux/usb.h>
#include <linux/printk.h>
#include <linux/input-polldev.h>
#include <linux/input/mt.h>
#include <linux/usb/input.h>
#include <linux/videodev2.h>
#include <media/v4l2-device.h>
#include <media/v4l2-dev.h>
#include <media/v4l2-ioctl.h>
#include <media/videobuf2-dma-contig.h>
/* read 512 bytes from endpoint 0x86 -> get header + blobs */
struct sur40_header {
__le16 type; /* always 0x0001 */
__le16 count; /* count of blobs (if 0: continue prev. packet) */
__le32 packet_id; /* unique ID for all packets in one frame */
__le32 timestamp; /* milliseconds (inc. by 16 or 17 each frame) */
__le32 unknown; /* "epoch?" always 02/03 00 00 00 */
} __packed;
struct sur40_blob {
__le16 blob_id;
u8 action; /* 0x02 = enter/exit, 0x03 = update (?) */
u8 unknown; /* always 0x01 or 0x02 (no idea what this is?) */
__le16 bb_pos_x; /* upper left corner of bounding box */
__le16 bb_pos_y;
__le16 bb_size_x; /* size of bounding box */
__le16 bb_size_y;
__le16 pos_x; /* finger tip position */
__le16 pos_y;
__le16 ctr_x; /* centroid position */
__le16 ctr_y;
__le16 axis_x; /* somehow related to major/minor axis, mostly: */
__le16 axis_y; /* axis_x == bb_size_y && axis_y == bb_size_x */
__le32 angle; /* orientation in radians relative to x axis -
actually an IEEE754 float, don't use in kernel */
__le32 area; /* size in pixels/pressure (?) */
u8 padding[32];
} __packed;
/* combined header/blob data */
struct sur40_data {
struct sur40_header header;
struct sur40_blob blobs[];
} __packed;
/* read 512 bytes from endpoint 0x82 -> get header below
* continue reading 16k blocks until header.size bytes read */
struct sur40_image_header {
__le32 magic; /* "SUBF" */
__le32 packet_id;
__le32 size; /* always 0x0007e900 = 960x540 */
__le32 timestamp; /* milliseconds (increases by 16 or 17 each frame) */
__le32 unknown; /* "epoch?" always 02/03 00 00 00 */
} __packed;
/* version information */
#define DRIVER_SHORT "sur40"
#define DRIVER_LONG "Samsung SUR40"
#define DRIVER_AUTHOR "Florian 'floe' Echtler <floe@butterbrot.org>"
#define DRIVER_DESC "Surface2.0/SUR40/PixelSense input driver"
/* vendor and device IDs */
#define ID_MICROSOFT 0x045e
#define ID_SUR40 0x0775
/* sensor resolution */
#define SENSOR_RES_X 1920
#define SENSOR_RES_Y 1080
/* touch data endpoint */
#define TOUCH_ENDPOINT 0x86
/* video data endpoint */
#define VIDEO_ENDPOINT 0x82
/* video header fields */
#define VIDEO_HEADER_MAGIC 0x46425553
#define VIDEO_PACKET_SIZE 16384
/* polling interval (ms) */
#define POLL_INTERVAL 10
/* maximum number of contacts FIXME: this is a guess? */
#define MAX_CONTACTS 64
/* control commands */
#define SUR40_GET_VERSION 0xb0 /* 12 bytes string */
#define SUR40_UNKNOWN1 0xb3 /* 5 bytes */
#define SUR40_UNKNOWN2 0xc1 /* 24 bytes */
#define SUR40_GET_STATE 0xc5 /* 4 bytes state (?) */
#define SUR40_GET_SENSORS 0xb1 /* 8 bytes sensors */
/*
* Note: an earlier, non-public version of this driver used USB_RECIP_ENDPOINT
* here by mistake which is very likely to have corrupted the firmware EEPROM
* on two separate SUR40 devices. Thanks to Alan Stern who spotted this bug.
* Should you ever run into a similar problem, the background story to this
* incident and instructions on how to fix the corrupted EEPROM are available
* at https://floe.butterbrot.org/matrix/hacking/surface/brick.html
*/
struct sur40_state {
struct usb_device *usbdev;
struct device *dev;
struct input_polled_dev *input;
struct v4l2_device v4l2;
struct video_device vdev;
struct mutex lock;
struct vb2_queue queue;
struct vb2_alloc_ctx *alloc_ctx;
struct list_head buf_list;
spinlock_t qlock;
int sequence;
struct sur40_data *bulk_in_buffer;
size_t bulk_in_size;
u8 bulk_in_epaddr;
char phys[64];
};
struct sur40_buffer {
struct vb2_buffer vb;
struct list_head list;
};
/* forward declarations */
static struct video_device sur40_video_device;
static struct v4l2_pix_format sur40_video_format;
static struct vb2_queue sur40_queue;
/* command wrapper */
static int sur40_command(struct sur40_state *dev,
u8 command, u16 index, void *buffer, u16 size)
{
return usb_control_msg(dev->usbdev, usb_rcvctrlpipe(dev->usbdev, 0),
command,
USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_IN,
0x00, index, buffer, size, 1000);
}
/* Initialization routine, called from sur40_open */
static int sur40_init(struct sur40_state *dev)
{
int result;
u8 buffer[24];
/* stupidly replay the original MS driver init sequence */
result = sur40_command(dev, SUR40_GET_VERSION, 0x00, buffer, 12);
if (result < 0)
return result;
result = sur40_command(dev, SUR40_GET_VERSION, 0x01, buffer, 12);
if (result < 0)
return result;
result = sur40_command(dev, SUR40_GET_VERSION, 0x02, buffer, 12);
if (result < 0)
return result;
result = sur40_command(dev, SUR40_UNKNOWN2, 0x00, buffer, 24);
if (result < 0)
return result;
result = sur40_command(dev, SUR40_UNKNOWN1, 0x00, buffer, 5);
if (result < 0)
return result;
result = sur40_command(dev, SUR40_GET_VERSION, 0x03, buffer, 12);
/*
* Discard the result buffer - no known data inside except
* some version strings, maybe extract these sometime...
*/
return result;
}
/*
* Callback routines from input_polled_dev
*/
/* Enable the device, polling will now start. */
static void sur40_open(struct input_polled_dev *polldev)
{
struct sur40_state *sur40 = polldev->private;
dev_dbg(sur40->dev, "open\n");
sur40_init(sur40);
}
/* Disable device, polling has stopped. */
static void sur40_close(struct input_polled_dev *polldev)
{
struct sur40_state *sur40 = polldev->private;
dev_dbg(sur40->dev, "close\n");
/*
* There is no known way to stop the device, so we simply
* stop polling.
*/
}
/*
* This function is called when a whole contact has been processed,
* so that it can assign it to a slot and store the data there.
*/
static void sur40_report_blob(struct sur40_blob *blob, struct input_dev *input)
{
int wide, major, minor;
int bb_size_x = le16_to_cpu(blob->bb_size_x);
int bb_size_y = le16_to_cpu(blob->bb_size_y);
int pos_x = le16_to_cpu(blob->pos_x);
int pos_y = le16_to_cpu(blob->pos_y);
int ctr_x = le16_to_cpu(blob->ctr_x);
int ctr_y = le16_to_cpu(blob->ctr_y);
int slotnum = input_mt_get_slot_by_key(input, blob->blob_id);
if (slotnum < 0 || slotnum >= MAX_CONTACTS)
return;
input_mt_slot(input, slotnum);
input_mt_report_slot_state(input, MT_TOOL_FINGER, 1);
wide = (bb_size_x > bb_size_y);
major = max(bb_size_x, bb_size_y);
minor = min(bb_size_x, bb_size_y);
input_report_abs(input, ABS_MT_POSITION_X, pos_x);
input_report_abs(input, ABS_MT_POSITION_Y, pos_y);
input_report_abs(input, ABS_MT_TOOL_X, ctr_x);
input_report_abs(input, ABS_MT_TOOL_Y, ctr_y);
/* TODO: use a better orientation measure */
input_report_abs(input, ABS_MT_ORIENTATION, wide);
input_report_abs(input, ABS_MT_TOUCH_MAJOR, major);
input_report_abs(input, ABS_MT_TOUCH_MINOR, minor);
}
/* core function: poll for new input data */
static void sur40_poll(struct input_polled_dev *polldev)
{
struct sur40_buffer *new_buf;
uint8_t *buffer;
struct sur40_state *sur40 = polldev->private;
struct input_dev *input = polldev->input;
int result, bulk_read, need_blobs, packet_blobs, i, bufpos;
u32 uninitialized_var(packet_id);
struct sur40_header *header = &sur40->bulk_in_buffer->header;
struct sur40_blob *inblob = &sur40->bulk_in_buffer->blobs[0];
struct sur40_image_header *img = (void*)(sur40->bulk_in_buffer);
dev_dbg(sur40->dev, "poll\n");
need_blobs = -1;
do {
/* perform a blocking bulk read to get data from the device */
result = usb_bulk_msg(sur40->usbdev,
usb_rcvbulkpipe(sur40->usbdev, sur40->bulk_in_epaddr),
sur40->bulk_in_buffer, sur40->bulk_in_size,
&bulk_read, 1000);
dev_dbg(sur40->dev, "received %d bytes\n", bulk_read);
if (result < 0) {
dev_err(sur40->dev, "error in usb_bulk_read\n");
return;
}
result = bulk_read - sizeof(struct sur40_header);
if (result % sizeof(struct sur40_blob) != 0) {
dev_err(sur40->dev, "transfer size mismatch\n");
return;
}
/* first packet? */
if (need_blobs == -1) {
need_blobs = le16_to_cpu(header->count);
dev_dbg(sur40->dev, "need %d blobs\n", need_blobs);
packet_id = le32_to_cpu(header->packet_id);
}
/*
* Sanity check. when video data is also being retrieved, the
* packet ID will usually increase in the middle of a series
* instead of at the end.
*/
if (packet_id != header->packet_id)
dev_warn(sur40->dev, "packet ID mismatch\n");
packet_blobs = result / sizeof(struct sur40_blob);
dev_dbg(sur40->dev, "received %d blobs\n", packet_blobs);
/* packets always contain at least 4 blobs, even if empty */
if (packet_blobs > need_blobs)
packet_blobs = need_blobs;
for (i = 0; i < packet_blobs; i++) {
need_blobs--;
dev_dbg(sur40->dev, "processing blob\n");
sur40_report_blob(&(inblob[i]), input);
}
} while (need_blobs > 0);
input_mt_sync_frame(input);
input_sync(input);
// TODO: move to separate method?
/* deal with video data here - should be moved to own method */
if (list_empty(&sur40->buf_list))
return;
/* get a new buffer from the list */
spin_lock(&sur40->qlock);
new_buf = list_entry(sur40->buf_list.next, struct sur40_buffer, list);
list_del(&new_buf->list);
spin_unlock(&sur40->qlock);
/* retrieve data via bulk read */
bufpos = 0;
// TODO: use a separate endpoint variable
result = usb_bulk_msg(sur40->usbdev,
usb_rcvbulkpipe(sur40->usbdev, VIDEO_ENDPOINT), // sur40->bulk_in_epaddr),
sur40->bulk_in_buffer, sur40->bulk_in_size,
&bulk_read, 1000);
// TODO: proper error handling & debug messages
if (result < 0) { dev_err(sur40->dev,"error in usb_bulk_read\n"); goto err_poll; }
if (bulk_read != sizeof(struct sur40_image_header)) {
dev_err(sur40->dev, "received %d bytes (%ld expected)\n", bulk_read, sizeof(struct sur40_image_header));
goto err_poll;
}
// TODO: use le32_to_cpu
if (img->magic != VIDEO_HEADER_MAGIC) { dev_err(sur40->dev,"image magic mismatch\n"); goto err_poll; }
if (img->size != sur40_video_format.sizeimage) { dev_err(sur40->dev,"image size mismatch\n"); goto err_poll; }
buffer = vb2_plane_vaddr(&new_buf->vb, 0);
while (bufpos < sur40_video_format.sizeimage) {
result = usb_bulk_msg(sur40->usbdev,
usb_rcvbulkpipe(sur40->usbdev, VIDEO_ENDPOINT), // sur40->bulk_in_epaddr),
buffer+bufpos, VIDEO_PACKET_SIZE,
&bulk_read, 1000);
if (result < 0) { dev_err(sur40->dev,"error in usb_bulk_read\n"); goto err_poll; }
bufpos += bulk_read;
}
/* mark as finished */
vb2_set_plane_payload(&new_buf->vb, 0, sur40_video_format.sizeimage); // TODO: (probably) redundant
v4l2_get_timestamp(&new_buf->vb.v4l2_buf.timestamp);
new_buf->vb.v4l2_buf.sequence = sur40->sequence++;
new_buf->vb.v4l2_buf.field = V4L2_FIELD_NONE;
vb2_buffer_done(&new_buf->vb, VB2_BUF_STATE_DONE);
return;
err_poll:
vb2_buffer_done(&new_buf->vb, VB2_BUF_STATE_ERROR);
}
/* Initialize input device parameters. */
static void sur40_input_setup(struct input_dev *input_dev)
{
__set_bit(EV_KEY, input_dev->evbit);
__set_bit(EV_ABS, input_dev->evbit);
input_set_abs_params(input_dev, ABS_MT_POSITION_X,
0, SENSOR_RES_X, 0, 0);
input_set_abs_params(input_dev, ABS_MT_POSITION_Y,
0, SENSOR_RES_Y, 0, 0);
input_set_abs_params(input_dev, ABS_MT_TOOL_X,
0, SENSOR_RES_X, 0, 0);
input_set_abs_params(input_dev, ABS_MT_TOOL_Y,
0, SENSOR_RES_Y, 0, 0);
/* max value unknown, but major/minor axis
* can never be larger than screen */
input_set_abs_params(input_dev, ABS_MT_TOUCH_MAJOR,
0, SENSOR_RES_X, 0, 0);
input_set_abs_params(input_dev, ABS_MT_TOUCH_MINOR,
0, SENSOR_RES_Y, 0, 0);
input_set_abs_params(input_dev, ABS_MT_ORIENTATION, 0, 1, 0, 0);
input_mt_init_slots(input_dev, MAX_CONTACTS,
INPUT_MT_DIRECT | INPUT_MT_DROP_UNUSED);
}
/* Check candidate USB interface. */
static int sur40_probe(struct usb_interface *interface,
const struct usb_device_id *id)
{
struct usb_device *usbdev = interface_to_usbdev(interface);
struct sur40_state *sur40;
struct usb_host_interface *iface_desc;
struct usb_endpoint_descriptor *endpoint;
struct input_polled_dev *poll_dev;
int error;
/* Check if we really have the right interface. */
iface_desc = &interface->altsetting[0];
if (iface_desc->desc.bInterfaceClass != 0xFF)
return -ENODEV;
/* Use endpoint #4 (0x86). */
endpoint = &iface_desc->endpoint[4].desc;
if (endpoint->bEndpointAddress != TOUCH_ENDPOINT)
return -ENODEV;
/* Allocate memory for our device state and initialize it. */
sur40 = kzalloc(sizeof(struct sur40_state), GFP_KERNEL);
if (!sur40)
return -ENOMEM;
poll_dev = input_allocate_polled_device();
if (!poll_dev) {
error = -ENOMEM;
goto err_free_dev;
}
/* initialize locks/lists */
INIT_LIST_HEAD(&sur40->buf_list);
spin_lock_init(&sur40->qlock);
mutex_init(&sur40->lock);
/* Set up polled input device control structure */
poll_dev->private = sur40;
poll_dev->poll_interval = POLL_INTERVAL;
poll_dev->open = sur40_open;
poll_dev->poll = sur40_poll;
poll_dev->close = sur40_close;
/* Set up regular input device structure */
sur40_input_setup(poll_dev->input);
poll_dev->input->name = DRIVER_LONG;
usb_to_input_id(usbdev, &poll_dev->input->id);
usb_make_path(usbdev, sur40->phys, sizeof(sur40->phys));
strlcat(sur40->phys, "/input0", sizeof(sur40->phys));
poll_dev->input->phys = sur40->phys;
poll_dev->input->dev.parent = &interface->dev;
sur40->usbdev = usbdev;
sur40->dev = &interface->dev;
sur40->input = poll_dev;
// TODO: save data for 2nd endpoint
/* use the bulk-in endpoint tested above */
sur40->bulk_in_size = usb_endpoint_maxp(endpoint);
sur40->bulk_in_epaddr = endpoint->bEndpointAddress;
sur40->bulk_in_buffer = kmalloc(sur40->bulk_in_size, GFP_KERNEL);
if (!sur40->bulk_in_buffer) {
dev_err(&interface->dev, "Unable to allocate input buffer.");
error = -ENOMEM;
goto err_free_polldev;
}
/* register the polled input device */
error = input_register_polled_device(poll_dev);
if (error) {
dev_err(&interface->dev,
"Unable to register polled input device.");
goto err_free_buffer;
}
/* register the video master device */
snprintf(sur40->v4l2.name, sizeof(sur40->v4l2.name), "%s", DRIVER_LONG);
error = v4l2_device_register(sur40->dev, &sur40->v4l2);
if (error) {
dev_err(&interface->dev,
"Unable to register video device.");
goto err_free_buffer;
}
/* initialize the lock and subdevice */
sur40->queue = sur40_queue;
sur40->queue.drv_priv = sur40;
sur40->queue.lock = &sur40->lock;
// init the queue
error = vb2_queue_init(&sur40->queue);
if (error)
goto err_free_buffer;
// TODO: switch to vmalloc?
sur40->alloc_ctx = vb2_dma_contig_init_ctx(sur40->dev);
if (IS_ERR(sur40->alloc_ctx)) {
dev_err(sur40->dev, "Can't allocate buffer context");
goto err_free_buffer;
}
sur40->vdev = sur40_video_device;
sur40->vdev.v4l2_dev = &sur40->v4l2;
sur40->vdev.lock = &sur40->lock;
sur40->vdev.queue = &sur40->queue;
video_set_drvdata(&sur40->vdev, sur40);
error = video_register_device(&sur40->vdev, VFL_TYPE_GRABBER, -1);
if (error)
goto err_free_buffer;
/* we can register the device now, as it is ready */
usb_set_intfdata(interface, sur40);
dev_dbg(&interface->dev, "%s is now attached\n", DRIVER_DESC);
return 0;
// TODO: proper error handling for all of these
/*v4l2_device_unregister(&sur40->v4l2);
video_unregister_device(&sur40->vdev);
vb2_dma_contig_cleanup_ctx(sur40->alloc_ctx);*/
err_free_buffer:
kfree(sur40->bulk_in_buffer);
err_free_polldev:
input_free_polled_device(sur40->input);
err_free_dev:
kfree(sur40);
return error;
}
/* Unregister device & clean up. */
static void sur40_disconnect(struct usb_interface *interface)
{
struct sur40_state *sur40 = usb_get_intfdata(interface);
v4l2_device_unregister(&sur40->v4l2);
video_unregister_device(&sur40->vdev);
// TODO: switch to vmalloc?
vb2_dma_contig_cleanup_ctx(sur40->alloc_ctx);
input_unregister_polled_device(sur40->input);
input_free_polled_device(sur40->input);
kfree(sur40->bulk_in_buffer);
kfree(sur40);
usb_set_intfdata(interface, NULL);
dev_dbg(&interface->dev, "%s is now disconnected\n", DRIVER_DESC);
}
/*
* Setup the constraints of the queue: besides setting the number of planes
* per buffer and the size and allocation context of each plane, it also
* checks if sufficient buffers have been allocated. Usually 3 is a good
* minimum number: many DMA engines need a minimum of 2 buffers in the
* queue and you need to have another available for userspace processing.
*/
static int sur40_queue_setup(struct vb2_queue *vq, const struct v4l2_format *fmt,
unsigned int *nbuffers, unsigned int *nplanes,
unsigned int sizes[], void *alloc_ctxs[])
{
struct sur40_state *sur40 = vb2_get_drv_priv(vq);
if (vq->num_buffers + *nbuffers < 3)
*nbuffers = 3 - vq->num_buffers;
if (fmt && fmt->fmt.pix.sizeimage < sur40_video_format.sizeimage)
return -EINVAL;
*nplanes = 1;
sizes[0] = fmt ? fmt->fmt.pix.sizeimage : sur40_video_format.sizeimage;
alloc_ctxs[0] = sur40->alloc_ctx;
return 0;
}
/*
* Prepare the buffer for queueing to the DMA engine: check and set the
* payload size.
*/
static int sur40_buffer_prepare(struct vb2_buffer *vb)
{
struct sur40_state *sur40 = vb2_get_drv_priv(vb->vb2_queue);
unsigned long size = sur40_video_format.sizeimage;
if (vb2_plane_size(vb, 0) < size) {
dev_err(&sur40->usbdev->dev, "buffer too small (%lu < %lu)\n",
vb2_plane_size(vb, 0), size);
return -EINVAL;
}
vb2_set_plane_payload(vb, 0, size);
return 0;
}
/*
* Queue this buffer to the DMA engine.
*/
static void sur40_buffer_queue(struct vb2_buffer *vb)
{
struct sur40_state *sur40 = vb2_get_drv_priv(vb->vb2_queue);
struct sur40_buffer *buf = (struct sur40_buffer*)(vb);
spin_lock(&sur40->qlock);
list_add_tail(&buf->list, &sur40->buf_list);
spin_unlock(&sur40->qlock);
}
static void return_all_buffers(struct sur40_state *sur40,
enum vb2_buffer_state state)
{
struct sur40_buffer *buf, *node;
spin_lock(&sur40->qlock);
list_for_each_entry_safe(buf, node, &sur40->buf_list, list) {
vb2_buffer_done(&buf->vb, state);
list_del(&buf->list);
}
spin_unlock(&sur40->qlock);
}
/*
* Start streaming. First check if the minimum number of buffers have been
* queued. If not, then return -ENOBUFS and the vb2 framework will call
* this function again the next time a buffer has been queued until enough
* buffers are available to actually start the DMA engine.
*/
static int sur40_start_streaming(struct vb2_queue *vq, unsigned int count)
{
struct sur40_state *sur40 = vb2_get_drv_priv(vq);
sur40->sequence = 0;
return 0;
}
/*
* Stop the DMA engine. Any remaining buffers in the DMA queue are dequeued
* and passed on to the vb2 framework marked as STATE_ERROR.
*/
static void sur40_stop_streaming(struct vb2_queue *vq)
{
struct sur40_state *sur40 = vb2_get_drv_priv(vq);
/* Release all active buffers */
return_all_buffers(sur40, VB2_BUF_STATE_ERROR);
}
/* V4L ioctl */
static int sur40_vidioc_querycap(struct file *file, void *priv,
struct v4l2_capability *cap)
{
struct sur40_state *sur40 = video_drvdata(file);
strlcpy(cap->driver, DRIVER_SHORT, sizeof(cap->driver));
strlcpy(cap->card, DRIVER_LONG, sizeof(cap->card));
usb_make_path(sur40->usbdev, cap->bus_info, sizeof(cap->bus_info));
cap->device_caps = V4L2_CAP_VIDEO_CAPTURE |
V4L2_CAP_EXT_PIX_FORMAT |
V4L2_CAP_READWRITE |
V4L2_CAP_STREAMING;
cap->capabilities = cap->device_caps | V4L2_CAP_DEVICE_CAPS;
return 0;
}
static int sur40_vidioc_enum_input(struct file *file, void *priv,
struct v4l2_input *i)
{
if (i->index != 0)
return -EINVAL;
i->type = V4L2_INPUT_TYPE_CAMERA;
i->std = V4L2_STD_UNKNOWN;
strlcpy(i->name, "In-Cell Sensor", sizeof(i->name));
i->capabilities = 0;
return 0;
}
static int sur40_vidioc_s_input(struct file *file, void *priv, unsigned int i)
{
return (i == 0) ? 0 : -EINVAL;
}
static int sur40_vidioc_g_input(struct file *file, void *priv, unsigned int *i)
{
*i = 0;
return 0;
}
static int sur40_vidioc_fmt(struct file *file, void *priv,
struct v4l2_format *f)
{
f->fmt.pix = sur40_video_format;
return 0;
}
static int sur40_vidioc_enum_fmt(struct file *file, void *priv,
struct v4l2_fmtdesc *f)
{
if (f->index != 0)
return -EINVAL;
strlcpy(f->description, "8-bit greyscale", sizeof(f->description));
f->pixelformat = V4L2_PIX_FMT_GREY;
f->flags = 0;
return 0;
}
static const struct usb_device_id sur40_table[] = {
{ USB_DEVICE(ID_MICROSOFT, ID_SUR40) }, /* Samsung SUR40 */
{ } /* terminating null entry */
};
MODULE_DEVICE_TABLE(usb, sur40_table);
/* V4L2 structures */
static struct vb2_ops sur40_queue_ops = {
.queue_setup = sur40_queue_setup,
.buf_prepare = sur40_buffer_prepare,
.buf_queue = sur40_buffer_queue,
.start_streaming = sur40_start_streaming,
.stop_streaming = sur40_stop_streaming,
.wait_prepare = vb2_ops_wait_prepare,
.wait_finish = vb2_ops_wait_finish,
};
static struct vb2_queue sur40_queue = {
.type = V4L2_BUF_TYPE_VIDEO_CAPTURE,
.io_modes = VB2_MMAP | VB2_DMABUF | VB2_READ,
.buf_struct_size = sizeof(struct sur40_buffer),
.ops = &sur40_queue_ops,
.mem_ops = &vb2_dma_contig_memops, // TODO: switch to vmalloc?
.timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC,
.min_buffers_needed = 3,
.gfp_flags = GFP_DMA,
};
static const struct v4l2_file_operations sur40_video_fops = {
.owner = THIS_MODULE,
.open = v4l2_fh_open,
.release = vb2_fop_release,
.unlocked_ioctl = video_ioctl2,
.read = vb2_fop_read,
.mmap = vb2_fop_mmap,
.poll = vb2_fop_poll,
};
static const struct v4l2_ioctl_ops sur40_video_ioctl_ops = {
.vidioc_querycap = sur40_vidioc_querycap,
.vidioc_enum_fmt_vid_cap = sur40_vidioc_enum_fmt,
.vidioc_try_fmt_vid_cap = sur40_vidioc_fmt,
.vidioc_s_fmt_vid_cap = sur40_vidioc_fmt,
.vidioc_g_fmt_vid_cap = sur40_vidioc_fmt,
.vidioc_enum_input = sur40_vidioc_enum_input,
.vidioc_g_input = sur40_vidioc_g_input,
.vidioc_s_input = sur40_vidioc_s_input,
.vidioc_reqbufs = vb2_ioctl_reqbufs,
.vidioc_create_bufs = vb2_ioctl_create_bufs,
.vidioc_querybuf = vb2_ioctl_querybuf,
.vidioc_qbuf = vb2_ioctl_qbuf,
.vidioc_dqbuf = vb2_ioctl_dqbuf,
.vidioc_expbuf = vb2_ioctl_expbuf,
.vidioc_streamon = vb2_ioctl_streamon,
.vidioc_streamoff = vb2_ioctl_streamoff,
};
static struct video_device sur40_video_device = {
.name = DRIVER_LONG,
.fops = &sur40_video_fops,
.ioctl_ops = &sur40_video_ioctl_ops,
.release = video_device_release_empty,
};
static struct v4l2_pix_format sur40_video_format = {
.pixelformat = V4L2_PIX_FMT_GREY,
.width = SENSOR_RES_X / 2,
.height = SENSOR_RES_Y / 2,
.field = V4L2_FIELD_NONE,
.colorspace = V4L2_COLORSPACE_SRGB,
.bytesperline = SENSOR_RES_X / 2,
.sizeimage = (SENSOR_RES_X/2) * (SENSOR_RES_Y/2),
.priv = 0,
};
/* USB-specific object needed to register this driver with the USB subsystem. */
static struct usb_driver sur40_driver = {
.name = DRIVER_SHORT,
.probe = sur40_probe,
.disconnect = sur40_disconnect,
.id_table = sur40_table,
};
module_usb_driver(sur40_driver);
MODULE_AUTHOR(DRIVER_AUTHOR);
MODULE_DESCRIPTION(DRIVER_DESC);
MODULE_LICENSE("GPL");
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [RFC] [Patch] implement video driver for sur40
From: Hans Verkuil @ 2015-01-06 10:23 UTC (permalink / raw)
To: Florian Echtler; +Cc: linux-input, linux-media
In-Reply-To: <54ABB641.7050002@butterbrot.org>
On 01/06/2015 11:17 AM, Florian Echtler wrote:
> On 06.01.2015 10:36, Hans Verkuil wrote:
>> On 01/06/2015 10:29 AM, Florian Echtler wrote:
>>> There's only one failing test left, which is this one:
>>>
>>> Streaming ioctls:
>>> test read/write: OK
>>> fail: v4l2-test-buffers.cpp(284): g_field() == V4L2_FIELD_ANY
>>
>> You're not filling in the 'field' field of struct v4l2_buffer when returning a
>> frame. It should most likely be FIELD_NONE in your case.
>>> fail: v4l2-test-buffers.cpp(611): buf.check(q, last_seq)
>>> fail: v4l2-test-buffers.cpp(884): captureBufs(node, q, m2m_q, frame_count, false)
> OK, easy to fix. This will also influence the other two warnings, I assume?
Most likely, yes.
>
>>> On a different note, I'm getting occasional warnings in syslog when I run
>>> a regular video streaming application (e.g. cheese):
>>>
>>> ------------[ cut here ]------------
> ...
>>> ---[ end trace 451ed974170f6e44 ]---
>>>
>>> Does this mean the driver consumes too much CPU resources?
>>
>> No, it means that your driver is not returning all buffers to vb2. Most
>> likely this is missing in the vb2 stop_streaming op. When that is called
>> your driver must return all buffers it has back to vb2 by calling
>> vb2_buffer_done with state ERROR. The same can happen in the start_streaming
>> op if that returns an error for some reason. In that case all buffers owned
>> by the driver should be returned to vb2 with state QUEUED. See also
>> Documentation/video4linux/v4l2-pci-skeleton.c as reference code.
> I did actually build my driver code based on v4l2-pci-skeleton.c, and
> I'm calling the exact same return_all_buffers function (see below) with
> VB2_BUF_STATE_ERROR from my stop_streaming ioctl.
>
> static void return_all_buffers(struct sur40_state *sur40,
> enum vb2_buffer_state state)
> {
> struct sur40_buffer *buf, *node;
>
> spin_lock(&sur40->qlock);
> list_for_each_entry_safe(buf, node, &sur40->buf_list, list) {
> vb2_buffer_done(&buf->vb, state);
> list_del(&buf->list);
> }
> spin_unlock(&sur40->qlock);
> }
>
> Is there another possible explanation?
No :-)
You are still missing a buffer somewhere. I'd have to see your latest source code
to see what's wrong.
Some drivers (esp. USB drivers) use a separate pointer to the active buffer, so that
buffer is no longer part of the buf_list, but still needs to be returned in stop_streaming.
Could that be the cause perhaps?
Regards,
Hans
^ permalink raw reply
* Re: [RFC] [Patch] implement video driver for sur40
From: Florian Echtler @ 2015-01-06 10:17 UTC (permalink / raw)
To: Hans Verkuil; +Cc: linux-input, linux-media
In-Reply-To: <54ABAC8C.6020401@xs4all.nl>
[-- Attachment #1: Type: text/plain, Size: 2108 bytes --]
On 06.01.2015 10:36, Hans Verkuil wrote:
> On 01/06/2015 10:29 AM, Florian Echtler wrote:
>> There's only one failing test left, which is this one:
>>
>> Streaming ioctls:
>> test read/write: OK
>> fail: v4l2-test-buffers.cpp(284): g_field() == V4L2_FIELD_ANY
>
> You're not filling in the 'field' field of struct v4l2_buffer when returning a
> frame. It should most likely be FIELD_NONE in your case.
>> fail: v4l2-test-buffers.cpp(611): buf.check(q, last_seq)
>> fail: v4l2-test-buffers.cpp(884): captureBufs(node, q, m2m_q, frame_count, false)
OK, easy to fix. This will also influence the other two warnings, I assume?
>> On a different note, I'm getting occasional warnings in syslog when I run
>> a regular video streaming application (e.g. cheese):
>>
>> ------------[ cut here ]------------
...
>> ---[ end trace 451ed974170f6e44 ]---
>>
>> Does this mean the driver consumes too much CPU resources?
>
> No, it means that your driver is not returning all buffers to vb2. Most
> likely this is missing in the vb2 stop_streaming op. When that is called
> your driver must return all buffers it has back to vb2 by calling
> vb2_buffer_done with state ERROR. The same can happen in the start_streaming
> op if that returns an error for some reason. In that case all buffers owned
> by the driver should be returned to vb2 with state QUEUED. See also
> Documentation/video4linux/v4l2-pci-skeleton.c as reference code.
I did actually build my driver code based on v4l2-pci-skeleton.c, and
I'm calling the exact same return_all_buffers function (see below) with
VB2_BUF_STATE_ERROR from my stop_streaming ioctl.
static void return_all_buffers(struct sur40_state *sur40,
enum vb2_buffer_state state)
{
struct sur40_buffer *buf, *node;
spin_lock(&sur40->qlock);
list_for_each_entry_safe(buf, node, &sur40->buf_list, list) {
vb2_buffer_done(&buf->vb, state);
list_del(&buf->list);
}
spin_unlock(&sur40->qlock);
}
Is there another possible explanation?
Thanks & best regards, Florian
--
SENT FROM MY DEC VT50 TERMINAL
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: hid-replay captured data
From: josep.sanchez.ferreres @ 2015-01-06 10:16 UTC (permalink / raw)
To: linux-input
Hello!
I'm not sure about what you meant by using evemu-record to record
the data from hidraw3. As far as I know evemu-record is only able to
record from the /dev/input interfaces right? If you meant hid-replay,
I wasn't able to get any data from hidraw3.
Could you please provide a more detailed explanation so I can get the data?
Thank you very much!
^ permalink raw reply
* Re: [RFC] [Patch] implement video driver for sur40
From: Hans Verkuil @ 2015-01-06 9:36 UTC (permalink / raw)
To: Florian Echtler; +Cc: linux-input, linux-media
In-Reply-To: <alpine.DEB.2.02.1501061018580.3223@butterbrot>
On 01/06/2015 10:29 AM, Florian Echtler wrote:
> On Fri, 19 Dec 2014, Hans Verkuil wrote:
>> drivers/media remains under heavy development, so for video capture drivers
>> like yours you should always patch against either the mainline linux tree
>> or (preferred) the media_tree.git repo (git://linuxtv.org/media_tree.git,
>> master branch).
> As per your suggestion, I've switched development to 3.18, and now I'm
> nearly there in terms of v4l2-compliance (also see attachment).
>
> There's only one failing test left, which is this one:
>
> Streaming ioctls:
> test read/write: OK
> fail: v4l2-test-buffers.cpp(284): g_field() == V4L2_FIELD_ANY
You're not filling in the 'field' field of struct v4l2_buffer when returning a
frame. It should most likely be FIELD_NONE in your case.
> fail: v4l2-test-buffers.cpp(611): buf.check(q, last_seq)
> fail: v4l2-test-buffers.cpp(884): captureBufs(node, q, m2m_q, frame_count, false)
> test MMAP: FAIL
> test USERPTR: OK (Not Supported)
> test DMABUF: Cannot test, specify --expbuf-device
>
> Total: 45, Succeeded: 44, Failed: 1, Warnings: 0
>
> Could you give some hints on what this means?
>
>
> On a different note, I'm getting occasional warnings in syslog when I run
> a regular video streaming application (e.g. cheese):
>
> ------------[ cut here ]------------
> WARNING: CPU: 1 PID: 4995 at /home/apw/COD/linux/drivers/media/v4l2-core/videobuf2-core.c:2144 __vb2_queue_cancel+0x1d0/0x240 [videobuf2_core]()
> Modules linked in: sur40(OE) videobuf2_dma_contig videobuf2_memops videobuf2_core v4l2_common videodev media dm_crypt wl(POE) snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_intel rfcomm bnep joydev input_polldev snd_hda_controller snd_hda_codec snd_hwdep kvm_amd kvm snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi edac_core snd_seq snd_seq_device serio_raw snd_timer sp5100_tco k10temp edac_mce_amd i2c_piix4 snd btusb soundcore bluetooth cfg80211 ipmi_si ppdev lp parport_pc ipmi_msghandler parport tpm_infineon mac_hid shpchp hid_apple usbhid hid uas usb_storage pata_acpi radeon i2c_algo_bit ttm psmouse drm_kms_helper pata_atiixp drm r8169 ahci mii libahci [last unloaded: sur40]
> CPU: 1 PID: 4995 Comm: cheese Tainted: P OE 3.17.1-031701-generic #201410150735
> Hardware name: Samsung SUR40/SDNE-R78BA2-20, BIOS SDNE-R78BA2-2000 11/04/2011
> 0000000000000860 ffff8800c2c1bd28 ffffffff81796c37 0000000000000007
> 0000000000000000 ffff8800c2c1bd68 ffffffff81074a3c ffff8800c2c1bd58
> fff8800c05904f8 ffff8800c05904d0 ffff8800abd65d38 ffff8800abd65d38
> Call Trace:
> [<ffffffff81796c37>] dump_stack+0x46/0x58
> [<ffffffff81074a3c>] warn_slowpath_common+0x8c/0xc0
> [<ffffffff81074a8a>] warn_slowpath_null+0x1a/0x20
> [<ffffffffc05b7a10>] __vb2_queue_cancel+0x1d0/0x240 [videobuf2_core]
> [<ffffffffc05bb3ee>] vb2_queue_release+0x1e/0x40 [videobuf2_core]
> [<ffffffffc05bb481>] _vb2_fop_release+0x71/0xb0 [videobuf2_core]
> [<ffffffffc05bb4ee>] vb2_fop_release+0x2e/0x50 [videobuf2_core]
> [<ffffffffc0c1f491>] v4l2_release+0x41/0x90 [videodev]
> [<ffffffff811eb34d>] __fput+0xbd/0x250
> [<ffffffff811eb52e>] ____fput+0xe/0x10
> [<ffffffff81091504>] task_work_run+0xc4/0xe0
> [<ffffffff810776a6>] do_exit+0x196/0x470
> [<ffffffff81082822>] ? zap_other_threads+0x82/0xa0
> [<ffffffff81077a14>] do_group_exit+0x44/0xa0
> [<ffffffff81077a87>] SyS_exit_group+0x17/0x20
> [<ffffffff817a47ad>] system_call_fastpath+0x1a/0x1f
> ---[ end trace 451ed974170f6e44 ]---
>
> Does this mean the driver consumes too much CPU resources?
No, it means that your driver is not returning all buffers to vb2. Most
likely this is missing in the vb2 stop_streaming op. When that is called
your driver must return all buffers it has back to vb2 by calling
vb2_buffer_done with state ERROR. The same can happen in the start_streaming
op if that returns an error for some reason. In that case all buffers owned
by the driver should be returned to vb2 with state QUEUED. See also
Documentation/video4linux/v4l2-pci-skeleton.c as reference code.
Regards,
Hans
>
> Thanks for your help & best regards, Florian
>
^ permalink raw reply
* Re: [RFC] [Patch] implement video driver for sur40
From: Florian Echtler @ 2015-01-06 9:29 UTC (permalink / raw)
To: Hans Verkuil; +Cc: linux-input, linux-media
In-Reply-To: <549443C9.6090900@xs4all.nl>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3453 bytes --]
On Fri, 19 Dec 2014, Hans Verkuil wrote:
> drivers/media remains under heavy development, so for video capture drivers
> like yours you should always patch against either the mainline linux tree
> or (preferred) the media_tree.git repo (git://linuxtv.org/media_tree.git,
> master branch).
As per your suggestion, I've switched development to 3.18, and now I'm
nearly there in terms of v4l2-compliance (also see attachment).
There's only one failing test left, which is this one:
Streaming ioctls:
test read/write: OK
fail: v4l2-test-buffers.cpp(284): g_field() == V4L2_FIELD_ANY
fail: v4l2-test-buffers.cpp(611): buf.check(q, last_seq)
fail: v4l2-test-buffers.cpp(884): captureBufs(node, q, m2m_q, frame_count, false)
test MMAP: FAIL
test USERPTR: OK (Not Supported)
test DMABUF: Cannot test, specify --expbuf-device
Total: 45, Succeeded: 44, Failed: 1, Warnings: 0
Could you give some hints on what this means?
On a different note, I'm getting occasional warnings in syslog when I run
a regular video streaming application (e.g. cheese):
------------[ cut here ]------------
WARNING: CPU: 1 PID: 4995 at /home/apw/COD/linux/drivers/media/v4l2-core/videobuf2-core.c:2144 __vb2_queue_cancel+0x1d0/0x240 [videobuf2_core]()
Modules linked in: sur40(OE) videobuf2_dma_contig videobuf2_memops videobuf2_core v4l2_common videodev media dm_crypt wl(POE) snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_intel rfcomm bnep joydev input_polldev snd_hda_controller snd_hda_codec snd_hwdep kvm_amd kvm snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi edac_core snd_seq snd_seq_device serio_raw snd_timer sp5100_tco k10temp edac_mce_amd i2c_piix4 snd btusb soundcore bluetooth cfg80211 ipmi_si ppdev lp parport_pc ipmi_msghandler parport tpm_infineon mac_hid shpchp hid_apple usbhid hid uas usb_storage pata_acpi radeon i2c_algo_bit ttm psmouse drm_kms_helper pata_atiixp drm r8169 ahci mii libahci [last unloaded: sur40]
CPU: 1 PID: 4995 Comm: cheese Tainted: P OE 3.17.1-031701-generic #201410150735
Hardware name: Samsung SUR40/SDNE-R78BA2-20, BIOS SDNE-R78BA2-2000 11/04/2011
0000000000000860 ffff8800c2c1bd28 ffffffff81796c37 0000000000000007
0000000000000000 ffff8800c2c1bd68 ffffffff81074a3c ffff8800c2c1bd58
fff8800c05904f8 ffff8800c05904d0 ffff8800abd65d38 ffff8800abd65d38
Call Trace:
[<ffffffff81796c37>] dump_stack+0x46/0x58
[<ffffffff81074a3c>] warn_slowpath_common+0x8c/0xc0
[<ffffffff81074a8a>] warn_slowpath_null+0x1a/0x20
[<ffffffffc05b7a10>] __vb2_queue_cancel+0x1d0/0x240 [videobuf2_core]
[<ffffffffc05bb3ee>] vb2_queue_release+0x1e/0x40 [videobuf2_core]
[<ffffffffc05bb481>] _vb2_fop_release+0x71/0xb0 [videobuf2_core]
[<ffffffffc05bb4ee>] vb2_fop_release+0x2e/0x50 [videobuf2_core]
[<ffffffffc0c1f491>] v4l2_release+0x41/0x90 [videodev]
[<ffffffff811eb34d>] __fput+0xbd/0x250
[<ffffffff811eb52e>] ____fput+0xe/0x10
[<ffffffff81091504>] task_work_run+0xc4/0xe0
[<ffffffff810776a6>] do_exit+0x196/0x470
[<ffffffff81082822>] ? zap_other_threads+0x82/0xa0
[<ffffffff81077a14>] do_group_exit+0x44/0xa0
[<ffffffff81077a87>] SyS_exit_group+0x17/0x20
[<ffffffff817a47ad>] system_call_fastpath+0x1a/0x1f
---[ end trace 451ed974170f6e44 ]---
Does this mean the driver consumes too much CPU resources?
Thanks for your help & best regards, Florian
--
"_Nothing_ brightens up my morning. Coffee simply provides a shade of
grey just above the pitch-black of the infinite depths of the _abyss_."
[-- Attachment #2: Type: TEXT/plain, Size: 3025 bytes --]
Driver Info:
Driver name : sur40
Card type : Samsung SUR40
Bus info : usb-0000:00:13.2-1
Driver version: 3.17.1
Capabilities : 0x85200001
Video Capture
Read/Write
Streaming
Extended Pix Format
Device Capabilities
Device Caps : 0x05200001
Video Capture
Read/Write
Streaming
Extended Pix Format
Compliance test for device /dev/video0 (not using libv4l2):
Required ioctls:
test VIDIOC_QUERYCAP: OK
Allow for multiple opens:
test second video open: OK
test VIDIOC_QUERYCAP: OK
test VIDIOC_G/S_PRIORITY: OK
Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
test VIDIOC_LOG_STATUS: OK (Not Supported)
Input ioctls:
test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
test VIDIOC_ENUMAUDIO: OK (Not Supported)
test VIDIOC_G/S/ENUMINPUT: OK
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 1 Audio Inputs: 0 Tuners: 0
Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_ENUMAUDOUT: OK (Not Supported)
test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0
Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
test VIDIOC_G/S_EDID: OK (Not Supported)
Test input 0:
Control ioctls:
test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
test VIDIOC_QUERYCTRL: OK (Not Supported)
test VIDIOC_G/S_CTRL: OK (Not Supported)
test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
Standard Controls: 0 Private Controls: 0
Format ioctls:
test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
test VIDIOC_G/S_PARM: OK (Not Supported)
test VIDIOC_G_FBUF: OK (Not Supported)
test VIDIOC_G_FMT: OK
test VIDIOC_TRY_FMT: OK
test VIDIOC_S_FMT: OK
test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
test Cropping: OK (Not Supported)
test Composing: OK (Not Supported)
test Scaling: OK (Not Supported)
Codec ioctls:
test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
test VIDIOC_G_ENC_INDEX: OK (Not Supported)
test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)
Buffer ioctls:
test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
test VIDIOC_EXPBUF: OK
Streaming ioctls:
test read/write: OK
fail: v4l2-test-buffers.cpp(284): g_field() == V4L2_FIELD_ANY
fail: v4l2-test-buffers.cpp(611): buf.check(q, last_seq)
fail: v4l2-test-buffers.cpp(884): captureBufs(node, q, m2m_q, frame_count, false)
test MMAP: FAIL
test USERPTR: OK (Not Supported)
test DMABUF: Cannot test, specify --expbuf-device
Total: 45, Succeeded: 44, Failed: 1, Warnings: 0
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox