* [PATCH 4/4] arm: dts: add support for Laird SOM60 module and DVK boards
From: Ben Whitten @ 2018-06-14 8:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528966340-23216-1-git-send-email-ben.whitten@lairdtech.com>
Signed-off-by: Ben Whitten <ben.whitten@lairdtech.com>
---
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/at91-dvk_som60.dts | 95 +++++++++++
arch/arm/boot/dts/at91-dvk_su60_somc.dtsi | 159 ++++++++++++++++++
arch/arm/boot/dts/at91-dvk_su60_somc_lcm.dtsi | 96 +++++++++++
arch/arm/boot/dts/at91-som60.dtsi | 229 ++++++++++++++++++++++++++
5 files changed, 581 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/at91-dvk_som60.dts
create mode 100644 arch/arm/boot/dts/at91-dvk_su60_somc.dtsi
create mode 100644 arch/arm/boot/dts/at91-dvk_su60_somc_lcm.dtsi
create mode 100644 arch/arm/boot/dts/at91-som60.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 486ab59..4d3d9ca 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -63,7 +63,8 @@ dtb-$(CONFIG_SOC_SAM_V7) += \
at91-sama5d4ek.dtb \
at91-vinco.dtb \
at91-wb50n.dtb \
- at91-gatwick.dtb
+ at91-gatwick.dtb \
+ at91-dvk_som60.dtb
dtb-$(CONFIG_ARCH_ATLAS6) += \
atlas6-evb.dtb
dtb-$(CONFIG_ARCH_ATLAS7) += \
diff --git a/arch/arm/boot/dts/at91-dvk_som60.dts b/arch/arm/boot/dts/at91-dvk_som60.dts
new file mode 100644
index 0000000..ededd5b
--- /dev/null
+++ b/arch/arm/boot/dts/at91-dvk_som60.dts
@@ -0,0 +1,95 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * at91-dvk_som60.dts - Device Tree file for the DVK SOM60 board
+ *
+ * Copyright (C) 2018 Laird,
+ * 2018 Ben Whitten <ben.whitten@lairdtech.com>
+ *
+ */
+/dts-v1/;
+#include "at91-som60.dtsi"
+#include "at91-dvk_su60_somc.dtsi"
+#include "at91-dvk_su60_somc_lcm.dtsi"
+
+/ {
+ model = "Laird DVK SOM60";
+ compatible = "laird,dvk-som60", "laird,som60", "atmel,sama5d36", "atmel,sama5d3", "atmel,sama5";
+
+ chosen {
+ stdout-path = &dbgu;
+ tick-timer = &pit;
+ };
+};
+
+&mmc0 {
+ status = "okay";
+};
+
+&spi0 {
+ status = "okay";
+};
+
+&ssc0 {
+ status = "okay";
+};
+
+&i2c0 {
+ status = "okay";
+};
+
+&i2c1 {
+ status = "okay";
+};
+
+&usart1 {
+ status = "okay";
+};
+
+&usart2 {
+ status = "okay";
+};
+
+&usart3 {
+ status = "okay";
+};
+
+&uart0 {
+ status = "okay";
+};
+
+&dbgu {
+ status = "okay";
+};
+
+&pit {
+ status = "okay";
+};
+
+&adc0 {
+ status = "okay";
+};
+
+&can1 {
+ status = "okay";
+};
+
+&macb0 {
+ status = "okay";
+};
+
+&macb1 {
+ status = "okay";
+};
+
+&usb0 {
+ status = "okay";
+};
+
+&usb1 {
+ status = "okay";
+};
+
+&usb2 {
+ status = "okay";
+};
+
diff --git a/arch/arm/boot/dts/at91-dvk_su60_somc.dtsi b/arch/arm/boot/dts/at91-dvk_su60_somc.dtsi
new file mode 100644
index 0000000..6031c2f
--- /dev/null
+++ b/arch/arm/boot/dts/at91-dvk_su60_somc.dtsi
@@ -0,0 +1,159 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * at91-dvk_su60_somc.dtsi - Device Tree file for the DVK SOM60 base board
+ *
+ * Copyright (C) 2018 Laird,
+ * 2018 Ben Whitten <ben.whitten@lairdtech.com>
+ *
+ */
+
+/ {
+ sound {
+ compatible = "atmel,asoc-wm8904";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pck2_as_audio_mck>;
+
+ atmel,model = "wm8904 @ DVK-SOM60";
+ atmel,audio-routing =
+ "Headphone Jack", "HPOUTL",
+ "Headphone Jack", "HPOUTR",
+ "IN2L", "Line In Jack",
+ "IN2R", "Line In Jack",
+ "Mic", "MICBIAS",
+ "IN1L", "Mic";
+
+ atmel,ssc-controller = <&ssc0>;
+ atmel,audio-codec = <&wm8904>;
+
+ status = "okay";
+ };
+};
+
+&mmc0 {
+ status = "okay";
+
+ pinctrl-0 = <&pinctrl_mmc0_clk_cmd_dat0 &pinctrl_mmc0_dat1_3 &pinctrl_mmc0_cd>;
+ slot at 0 {
+ bus-width = <4>;
+ cd-gpios = <&pioE 31 GPIO_ACTIVE_HIGH>;
+ cd-inverted;
+ };
+};
+
+&spi0 {
+ status = "okay";
+
+ /* spi0.0: 4M Flash Macronix MX25R4035FM1IL0 */
+ spi-flash at 0 {
+ compatible = "mxicy,mx25u4035", "jedec,spi-nor";
+ spi-max-frequency = <33000000>;
+ reg = <0>;
+ };
+};
+
+&ssc0 {
+ atmel,clk-from-rk-pin;
+ status = "okay";
+};
+
+&i2c0 {
+ status = "okay";
+
+ wm8904: wm8904 at 1a {
+ compatible = "wlf,wm8904";
+ reg = <0x1a>;
+ clocks = <&pck2>;
+ clock-names = "mclk";
+ };
+};
+
+&i2c1 {
+ status = "okay";
+
+ eeprom at 87 {
+ compatible = "giantec,24c32";
+ reg = <87>;
+ pagesize = <32>;
+ };
+};
+
+&usart1 {
+ status = "okay";
+};
+
+&usart2 {
+ status = "okay";
+};
+
+&usart3 {
+ status = "okay";
+};
+
+&uart0 {
+ status = "okay";
+};
+
+&dbgu {
+ status = "okay";
+};
+
+&pit {
+ status = "okay";
+};
+
+&adc0 {
+ status = "okay";
+};
+
+&can1 {
+ status = "okay";
+};
+
+&macb0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ ethernet-phy at 7 {
+ reg = <7>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_geth_int>;
+ interrupt-parent = <&pioB>;
+ interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
+ txen-skew-ps = <800>;
+ txc-skew-ps = <3000>;
+ rxdv-skew-ps = <400>;
+ rxc-skew-ps = <3000>;
+ rxd0-skew-ps = <400>;
+ rxd1-skew-ps = <400>;
+ rxd2-skew-ps = <400>;
+ rxd3-skew-ps = <400>;
+ };
+};
+
+&macb1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ ethernet-phy at 1 {
+ reg = <1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_eth_int>;
+ interrupt-parent = <&pioC>;
+ interrupts = <10 IRQ_TYPE_EDGE_FALLING>;
+ };
+};
+
+&usb0 {
+ status = "okay";
+};
+
+&usb1 {
+ status = "okay";
+};
+
+&usb2 {
+ status = "okay";
+};
+
diff --git a/arch/arm/boot/dts/at91-dvk_su60_somc_lcm.dtsi b/arch/arm/boot/dts/at91-dvk_su60_somc_lcm.dtsi
new file mode 100644
index 0000000..d98c644
--- /dev/null
+++ b/arch/arm/boot/dts/at91-dvk_su60_somc_lcm.dtsi
@@ -0,0 +1,96 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * at91-dvk_su60_somc_lcm.dtsi - Device Tree file for the DVK SOM60 LCD board
+ *
+ * Copyright (C) 2018 Laird,
+ * 2018 Ben Whitten <ben.whitten@lairdtech.com>
+ *
+ */
+
+/ {
+ ahb {
+ apb {
+ pinctrl at fffff200 {
+ board {
+ pinctrl_lcd_ctp_int: lcd_ctp_int {
+ atmel,pins =
+ <AT91_PIOC 28 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP_DEGLITCH>;
+ };
+ };
+ };
+ };
+ };
+
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <&hlcdc_pwm 0 50000 0>;
+ brightness-levels = <0 4 8 16 32 64 128 255>;
+ default-brightness-level = <6>;
+ status = "okay";
+ };
+
+ panel: panel {
+ /* Actually Winstar WF70GTIAGDNG0 */
+ compatible = "innolux,at070tn92", "simple-panel";
+ backlight = <&backlight>;
+ power-supply = <&vcc_lcd_reg>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ port at 0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ panel_input: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&hlcdc_panel_output>;
+ };
+ };
+ };
+
+ vcc_lcd_reg: fixedregulator_lcd {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC LCM";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-boot-on;
+ regulator-always-on;
+ status = "okay";
+ };
+};
+
+&i2c1 {
+ status = "okay";
+
+ ft5426 at 56 {
+ /* Actually FT5426 */
+ compatible = "edt,edt-ft5406";
+ reg = <56>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lcd_ctp_int>;
+
+ interrupt-parent = <&pioC>;
+ interrupts = <28 IRQ_TYPE_EDGE_FALLING>;
+
+ touchscreen-size-x = <800>;
+ touchscreen-size-y = <480>;
+ };
+};
+
+&hlcdc {
+ status = "okay";
+
+ hlcdc-display-controller {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lcd_base &pinctrl_lcd_rgb888>;
+
+ port at 0 {
+ hlcdc_panel_output: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&panel_input>;
+ };
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/at91-som60.dtsi b/arch/arm/boot/dts/at91-som60.dtsi
new file mode 100644
index 0000000..1843284
--- /dev/null
+++ b/arch/arm/boot/dts/at91-som60.dtsi
@@ -0,0 +1,229 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * at91-som60.dtsi - Device Tree file for the SOM60 module
+ *
+ * Copyright (C) 2018 Laird,
+ * 2018 Ben Whitten <ben.whitten@lairdtech.com>
+ *
+ */
+#include "sama5d36.dtsi"
+
+/ {
+ model = "Laird SOM60";
+ compatible = "laird,som60", "atmel,sama5d36", "atmel,sama5d3", "atmel,sama5";
+
+ chosen {
+ stdout-path = &dbgu;
+ };
+
+ memory {
+ reg = <0x20000000 0x8000000>;
+ };
+
+ clocks {
+ slow_xtal {
+ clock-frequency = <32768>;
+ };
+
+ main_xtal {
+ clock-frequency = <12000000>;
+ };
+ };
+
+ ahb {
+ apb {
+ pinctrl at fffff200 {
+ board {
+ pinctrl_mmc0_cd: mmc0_cd {
+ atmel,pins =
+ <AT91_PIOE 31 AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>;
+ };
+
+ pinctrl_mmc0_en: mmc0_en {
+ atmel,pins =
+ <AT91_PIOE 30 AT91_PERIPH_GPIO AT91_PINCTRL_NONE>;
+ };
+
+ pinctrl_nand0_wp: nand0_wp {
+ atmel,pins =
+ <AT91_PIOE 14 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP>;
+ };
+
+ pinctrl_usb_vbus: usb_vbus {
+ atmel,pins =
+ <AT91_PIOE 20 AT91_PERIPH_GPIO AT91_PINCTRL_NONE>; /* Conflicts with USART2_SCK */
+ };
+
+ pinctrl_usart2_sck: usart2_sck {
+ atmel,pins =
+ <AT91_PIOE 20 AT91_PERIPH_B AT91_PINCTRL_NONE>; /* Conflicts with USB_VBUS */
+ };
+
+ pinctrl_usb_oc: usb_oc {
+ atmel,pins =
+ <AT91_PIOE 15 AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>; /* Conflicts with USART3_SCK */
+ };
+
+ pinctrl_usart3_sck: usart3_sck {
+ atmel,pins =
+ <AT91_PIOE 15 AT91_PERIPH_B AT91_PINCTRL_NONE>; /* Conflicts with USB_OC */
+ };
+
+ pinctrl_usba_vbus: usba_vbus {
+ atmel,pins =
+ <AT91_PIOC 14 AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>;
+ };
+
+ pinctrl_geth_int: geth_int {
+ atmel,pins =
+ <AT91_PIOB 25 AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>; /* Conflicts with USART1_SCK */
+ };
+
+ pinctrl_usart1_sck: usart1_sck {
+ atmel,pins =
+ <AT91_PIOB 25 AT91_PERIPH_A AT91_PINCTRL_NONE>; /* Conflicts with GETH_INT */
+ };
+
+ pinctrl_eth_int: eth_int {
+ atmel,pins =
+ <AT91_PIOC 10 AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>;
+ };
+
+ pinctrl_pck2_as_audio_mck: pck2_as_audio_mck {
+ atmel,pins =
+ <AT91_PIOC 15 AT91_PERIPH_B AT91_PINCTRL_NONE>;
+ };
+ };
+ };
+ };
+ };
+};
+
+&mmc0 {
+ slot at 0 {
+ reg = <0>;
+ bus-width = <8>;
+ };
+};
+
+&mmc1 {
+ status = "okay";
+ slot at 0 {
+ reg = <0>;
+ bus-width = <4>;
+ };
+};
+
+&spi0 {
+ cs-gpios = <&pioD 13 0>, <0>, <0>, <0>;
+};
+
+&usart0 {
+ atmel,use-dma-rx;
+ atmel,use-dma-tx;
+ status = "okay";
+ pinctrl-0 = <&pinctrl_usart0 &pinctrl_usart0_rts_cts>;
+};
+
+&usart1 {
+ pinctrl-0 = <&pinctrl_usart1 &pinctrl_usart1_rts_cts>;
+};
+
+&usart2 {
+ pinctrl-0 = <&pinctrl_usart2 &pinctrl_usart2_rts_cts>;
+};
+
+&usart3 {
+ pinctrl-0 = <&pinctrl_usart3 &pinctrl_usart3_rts_cts>;
+};
+
+&adc0 {
+ pinctrl-0 = <
+ &pinctrl_adc0_adtrg
+ &pinctrl_adc0_ad0
+ &pinctrl_adc0_ad1
+ &pinctrl_adc0_ad2
+ &pinctrl_adc0_ad3
+ &pinctrl_adc0_ad4
+ &pinctrl_adc0_ad5
+ >;
+};
+
+&macb0 {
+ phy-mode = "rgmii";
+};
+
+&macb1 {
+ phy-mode = "rmii";
+};
+
+
+&ebi {
+ pinctrl-0 = <&pinctrl_ebi_nand_addr>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&nand_controller {
+ status = "okay";
+
+ nand: nand at 3 {
+ reg = <0x3 0x0 0x2>;
+ atmel,rb = <0>;
+ nand-bus-width = <8>;
+ nand-ecc-mode = "hw";
+ nand-ecc-strength = <8>;
+ nand-ecc-step-size = <512>;
+ nand-on-flash-bbt;
+ label = "atmel_nand";
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ ubootspl at 0 {
+ label = "u-boot-spl";
+ reg = <0x0 0x20000>;
+ };
+
+ uboot at 20000 {
+ label = "u-boot";
+ reg = <0x20000 0x80000>;
+ };
+
+ ubootenv at a0000 {
+ label = "u-boot-env";
+ reg = <0xa0000 0x20000>;
+ };
+
+ ubootenv at c0000 {
+ label = "u-boot-env";
+ reg = <0xc0000 0x20000>;
+ };
+
+ ubi at e0000 {
+ label = "ubi";
+ reg = <0xe0000 0xfe00000>;
+ };
+ };
+ };
+};
+
+&usb0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usba_vbus>;
+ atmel,vbus-gpio = <&pioC 14 GPIO_ACTIVE_HIGH>;
+};
+
+&usb1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usb_vbus &pinctrl_usb_oc>;
+ num-ports = <3>;
+ atmel,vbus-gpio = <0
+ &pioE 20 GPIO_ACTIVE_HIGH
+ 0>;
+ atmel,oc-gpio = <0
+ &pioE 15 GPIO_ACTIVE_LOW
+ 0>;
+};
--
2.7.4
^ permalink raw reply related
* [PATCH 3/4] arm: dts: add support for Gatwick board based on WB50N
From: Ben Whitten @ 2018-06-14 8:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528966340-23216-1-git-send-email-ben.whitten@lairdtech.com>
Signed-off-by: Ben Whitten <ben.whitten@lairdtech.com>
---
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/at91-gatwick.dts | 125 +++++++++++++++++++++++++++++++++++++
2 files changed, 127 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/at91-gatwick.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index fd5f8a6..486ab59 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -62,7 +62,8 @@ dtb-$(CONFIG_SOC_SAM_V7) += \
at91-sama5d4_xplained.dtb \
at91-sama5d4ek.dtb \
at91-vinco.dtb \
- at91-wb50n.dtb
+ at91-wb50n.dtb \
+ at91-gatwick.dtb
dtb-$(CONFIG_ARCH_ATLAS6) += \
atlas6-evb.dtb
dtb-$(CONFIG_ARCH_ATLAS7) += \
diff --git a/arch/arm/boot/dts/at91-gatwick.dts b/arch/arm/boot/dts/at91-gatwick.dts
new file mode 100644
index 0000000..1350c08
--- /dev/null
+++ b/arch/arm/boot/dts/at91-gatwick.dts
@@ -0,0 +1,125 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * at91-gatwick.dts - Device Tree file for the Gatwick board
+ *
+ * Copyright (C) 2018 Laird
+ *
+ */
+/dts-v1/;
+#include "at91-wb50n.dtsi"
+#include <dt-bindings/input/input.h>
+
+/ {
+ model = "Laird Workgroup Bridge 50N - Project Gatwick";
+ compatible = "laird,gatwick", "laird,wb50n", "atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
+
+ ahb {
+ apb {
+ pinctrl at fffff200 {
+ board {
+ pinctrl_key_gpio: key_gpio_0 {
+ atmel,pins =
+ <AT91_PIOE 31 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP_DEGLITCH>; /* PE31 GPIO with pullup deglitch */
+ };
+ };
+ };
+ };
+ };
+
+ gpio_keys {
+ compatible = "gpio-keys";
+ autorepeat;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_key_gpio>;
+
+ reset-button {
+ label = "Reset Button";
+ linux,code = <KEY_SETUP>;
+ gpios = <&pioE 31 GPIO_ACTIVE_LOW>;
+ wakeup-source;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ ethernet {
+ label = "gatwick:yellow:ethernet";
+ gpios = <&pioA 10 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ };
+
+ wifi {
+ label = "gatwick:green:wifi";
+ gpios = <&pioA 28 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ };
+
+ ble {
+ label = "gatwick:blue:ble";
+ gpios = <&pioA 22 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ };
+
+ lora {
+ label = "gatwick:orange:lora";
+ gpios = <&pioA 26 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ };
+
+ blank {
+ label = "gatwick:green:blank";
+ gpios = <&pioA 24 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ };
+
+ user {
+ label = "gatwick:yellow:user";
+ gpios = <&pioA 12 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ };
+ };
+};
+
+&mmc0 {
+ status = "okay";
+};
+
+&macb1 {
+ status = "okay";
+};
+
+&dbgu {
+ status = "okay";
+};
+
+/* FTDI USART */
+&usart0 {
+ status = "okay";
+};
+
+/* GPS USART */
+&usart1 {
+ pinctrl-0 = <&pinctrl_usart1>;
+ status = "okay";
+};
+
+&spi1 {
+ status = "okay";
+
+ spidev at 0 {
+ compatible = "semtech,sx1301";
+ reg = <0>;
+ spi-max-frequency = <8000000>;
+ };
+};
+
+&usb1 {
+ status = "okay";
+ /delete-property/atmel,oc-gpio;
+};
+
+&usb2 {
+ status = "okay";
+};
--
2.7.4
^ permalink raw reply related
* [PATCH 2/4] arm: dts: add support for Laird WB50N cpu module and DVK
From: Ben Whitten @ 2018-06-14 8:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528966340-23216-1-git-send-email-ben.whitten@lairdtech.com>
Signed-off-by: Ben Whitten <ben.whitten@lairdtech.com>
---
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/at91-wb50n.dts | 116 ++++++++++++++++++++++
arch/arm/boot/dts/at91-wb50n.dtsi | 202 ++++++++++++++++++++++++++++++++++++++
3 files changed, 320 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/at91-wb50n.dts
create mode 100644 arch/arm/boot/dts/at91-wb50n.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 1ee94ee..fd5f8a6 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -61,7 +61,8 @@ dtb-$(CONFIG_SOC_SAM_V7) += \
at91-sama5d4_ma5d4evk.dtb \
at91-sama5d4_xplained.dtb \
at91-sama5d4ek.dtb \
- at91-vinco.dtb
+ at91-vinco.dtb \
+ at91-wb50n.dtb
dtb-$(CONFIG_ARCH_ATLAS6) += \
atlas6-evb.dtb
dtb-$(CONFIG_ARCH_ATLAS7) += \
diff --git a/arch/arm/boot/dts/at91-wb50n.dts b/arch/arm/boot/dts/at91-wb50n.dts
new file mode 100644
index 0000000..ee4f823
--- /dev/null
+++ b/arch/arm/boot/dts/at91-wb50n.dts
@@ -0,0 +1,116 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * at91-wb50n.dts - Device Tree file for wb50n evaluation board
+ *
+ * Copyright (C) 2018 Laird
+ *
+ */
+
+/dts-v1/;
+#include "at91-wb50n.dtsi"
+
+/ {
+ model = "Laird Workgroup Bridge 50N - Atmel SAMA5D";
+ compatible = "laird,wb50n", "atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
+
+ ahb {
+ apb {
+ watchdog at fffffe40 {
+ compatible = "atmel,at91sam9260-wdt";
+ reg = <0xfffffe40 0x10>;
+ clocks = <&clk32k>;
+ status = "okay";
+ };
+ };
+ };
+
+ gpio_keys {
+ compatible = "gpio-keys";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ btn0 at pa10 {
+ label = "BTNESC";
+ linux,code = <1>; /* ESC button */
+ gpios = <&pioA 10 GPIO_ACTIVE_LOW>;
+ gpio-key,wakeup = <1>;
+ };
+
+ irqbtn at pe31 {
+ label = "IRQBTN";
+ linux,code = <99>; /* SysReq button */
+ gpios = <&pioE 31 GPIO_ACTIVE_LOW>;
+ gpio-key,wakeup = <1>;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led0 {
+ label = "wb50n:blue:led0";
+ gpios = <&pioA 12 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ };
+
+ led1 {
+ label = "wb50n:green:led1";
+ gpios = <&pioA 24 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ };
+
+ led2 {
+ label = "wb50n:red:led2";
+ gpios = <&pioA 26 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ };
+ };
+};
+
+&mmc0 {
+ status = "okay";
+};
+
+&macb1 {
+ status = "okay";
+};
+
+&dbgu {
+ status = "okay";
+};
+
+/* On BB40 this port is labeled UART1 */
+&usart0 {
+ status = "okay";
+};
+
+/* On BB40 this port is labeled UART0 */
+&usart1 {
+ status = "okay";
+};
+
+&i2c0 {
+ status = "okay";
+};
+
+&spi1 {
+ status = "okay";
+
+ spidev at 0 {
+ compatible = "spidev";
+ reg = <0>;
+ spi-max-frequency = <8000000>;
+ };
+};
+
+&usb0 {
+ status = "okay";
+};
+
+&usb1 {
+ status = "okay";
+};
+
+&usb2 {
+ status = "okay";
+};
+
diff --git a/arch/arm/boot/dts/at91-wb50n.dtsi b/arch/arm/boot/dts/at91-wb50n.dtsi
new file mode 100644
index 0000000..11d8cc1
--- /dev/null
+++ b/arch/arm/boot/dts/at91-wb50n.dtsi
@@ -0,0 +1,202 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * at91-wb50n.dtsi - Device Tree include file for wb50n cpu module
+ *
+ * Copyright (C) 2018 Laird
+ *
+ */
+
+#include "sama5d31.dtsi"
+
+/ {
+ model = "Laird Workgroup Bridge 50N - Atmel SAMA5D";
+ compatible = "laird,wb50n", "atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
+
+ chosen {
+ bootargs = "ubi.mtd=6 root=ubi0:rootfs rootfstype=ubifs rw";
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory {
+ reg = <0x20000000 0x4000000>;
+ };
+
+ ahb {
+ apb {
+ pinctrl at fffff200 {
+ board {
+ pinctrl_mmc0_cd: mmc0_cd {
+ atmel,pins = <AT91_PIOC 26 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP_DEGLITCH>; /* PC26 GPIO with pullup deglitch */
+ };
+
+ pinctrl_usba_vbus: usba_vbus {
+ atmel,pins = <AT91_PIOB 13 AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>; /* PB13 GPIO with deglitch */
+ };
+ };
+ };
+ };
+ };
+};
+
+&slow_xtal {
+ clock-frequency = <32768>;
+};
+
+&main_xtal {
+ clock-frequency = <12000000>;
+};
+
+&slow_osc {
+ atmel,osc-bypass;
+};
+
+&usart1_clk {
+ atmel,clk-output-range = <0 132000000>;
+};
+
+&mmc0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_mmc0_clk_cmd_dat0 &pinctrl_mmc0_dat1_3 &pinctrl_mmc0_cd>;
+ cd-gpios = <&pioC 26 GPIO_ACTIVE_LOW>;
+ slot at 0 {
+ reg = <0>;
+ bus-width = <4>;
+ };
+};
+
+&mmc1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_mmc1_clk_cmd_dat0 &pinctrl_mmc1_dat1_3>;
+ status = "okay";
+ atheros at 0 {
+ compatible = "atheros,ath6kl";
+ atheros,board-id = "SD32";
+ reg = <0>;
+ bus-width = <4>;
+ };
+};
+
+&macb1 {
+ phy-mode = "rmii";
+};
+
+&dbgu {
+ dmas = <0>, <0>; /* Do not use DMA for dbgu */
+};
+
+/* On BB40 this port is labeled UART1 */
+&usart0 {
+ atmel,use-dma-rx;
+ atmel,use-dma-tx;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usart0 &pinctrl_usart0_rts_cts>;
+};
+
+/* On BB40 this port is labeled UART0 */
+&usart1 {
+ atmel,use-dma-rx;
+ atmel,use-dma-tx;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usart1 &pinctrl_usart1_rts_cts>;
+ dtr-gpios = <&pioD 13 GPIO_ACTIVE_LOW>;
+ dsr-gpios = <&pioD 11 GPIO_ACTIVE_LOW>;
+ dcd-gpios = <&pioD 7 GPIO_ACTIVE_LOW>;
+ rng-gpios = <&pioD 8 GPIO_ACTIVE_LOW>;
+};
+
+/* USART3 is direct-connect to the Bluetooth UART on the radio SIP */
+&usart3 {
+ atmel,use-dma-rx;
+ atmel,use-dma-tx;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usart3 &pinctrl_usart3_rts_cts>;
+ status = "okay";
+};
+
+&spi1 {
+ cs-gpios = <&pioC 25 0>, <0>, <0>, <0>;
+};
+
+&ebi {
+ pinctrl-0 = <&pinctrl_ebi_nand_addr>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&nand_controller {
+ status = "okay";
+
+ nand: nand at 3 {
+ reg = <0x3 0x0 0x2>;
+ atmel,rb = <0>;
+ nand-bus-width = <8>;
+ nand-ecc-mode = "hw";
+ nand-ecc-strength = <8>;
+ nand-ecc-step-size = <512>;
+ nand-on-flash-bbt;
+ label = "atmel_nand";
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ at91bootstrap at 0 {
+ label = "at91bs";
+ reg = <0x0 0x20000>;
+ };
+
+ uboot at 20000 {
+ label = "u-boot";
+ reg = <0x20000 0x80000>;
+ };
+
+ ubootenv at a0000 {
+ label = "u-boot-env";
+ reg = <0xa0000 0x20000>;
+ };
+
+ ubootenv at c0000 {
+ label = "u-boot-env";
+ reg = <0xc0000 0x20000>;
+ };
+
+ kernel-a at e0000 {
+ label = "kernel-a";
+ reg = <0xe0000 0x500000>;
+ };
+
+ kernel-b at 5e0000 {
+ label = "kernel-b";
+ reg = <0x5e0000 0x500000>;
+ };
+
+ rootfs-a at ae0000 {
+ label = "rootfs-a";
+ reg = <0xae0000 0x3000000>;
+ };
+
+ rootfs-b at 3ae0000 {
+ label = "rootfs-b";
+ reg = <0x3ae0000 0x3000000>;
+ };
+
+ user at 6ae0000 {
+ label = "user";
+ reg = <0x6ae0000 0x14e0000>;
+ };
+ };
+ };
+};
+
+&usb0 {
+ atmel,vbus-gpio = <&pioB 13 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usba_vbus>;
+};
+
+&usb1 {
+ num-ports = <3>;
+ atmel,vbus-gpio = <&pioA 2 GPIO_ACTIVE_LOW>;
+ atmel,oc-gpio = <&pioA 4 GPIO_ACTIVE_LOW>;
+};
--
2.7.4
^ permalink raw reply related
* [PATCH 1/4] arm: dts: add support for Laird WB45N cpu module and DVK
From: Ben Whitten @ 2018-06-14 8:51 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Ben Whitten <ben.whitten@lairdtech.com>
---
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/at91-wb45n.dts | 66 +++++++++++++++
arch/arm/boot/dts/at91-wb45n.dtsi | 169 ++++++++++++++++++++++++++++++++++++++
3 files changed, 237 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/at91-wb45n.dts
create mode 100644 arch/arm/boot/dts/at91-wb45n.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 7e24249..1ee94ee 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -42,7 +42,8 @@ dtb-$(CONFIG_SOC_AT91SAM9) += \
at91sam9g25ek.dtb \
at91sam9g35ek.dtb \
at91sam9x25ek.dtb \
- at91sam9x35ek.dtb
+ at91sam9x35ek.dtb \
+ at91-wb45n.dtb
dtb-$(CONFIG_SOC_SAM_V7) += \
at91-kizbox2.dtb \
at91-nattis-2-natte-2.dtb \
diff --git a/arch/arm/boot/dts/at91-wb45n.dts b/arch/arm/boot/dts/at91-wb45n.dts
new file mode 100644
index 0000000..4e88815
--- /dev/null
+++ b/arch/arm/boot/dts/at91-wb45n.dts
@@ -0,0 +1,66 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * at91-wb45n.dts - Device Tree file for WB45NBT board
+ *
+ * Copyright (C) 2018 Laird
+ *
+*/
+/dts-v1/;
+#include "at91-wb45n.dtsi"
+
+/ {
+ model = "Laird Workgroup Bridge 45N - Atmel AT91SAM (dt)";
+ compatible = "laird,wb45n", "laird,wbxx", "atmel,at91sam9x5", "atmel,at91sam9";
+
+ ahb {
+ apb {
+ watchdog at fffffe40 {
+ status = "okay";
+ };
+ };
+ };
+
+ gpio_keys {
+ compatible = "gpio-keys";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ irqbtn at pb18 {
+ label = "IRQBTN";
+ linux,code = <99>;
+ gpios = <&pioB 18 GPIO_ACTIVE_LOW>;
+ gpio-key,wakeup = <1>;
+ };
+ };
+};
+
+&usb0 {
+ status = "okay";
+};
+
+&mmc0 {
+ status = "okay";
+};
+
+&spi0 {
+ status = "okay";
+};
+
+&macb0 {
+ status = "okay";
+};
+
+&dbgu {
+ status = "okay";
+};
+
+&usart0 {
+ status = "okay";
+};
+
+&usart3 {
+ status = "okay";
+};
+
+&i2c1 {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/at91-wb45n.dtsi b/arch/arm/boot/dts/at91-wb45n.dtsi
new file mode 100644
index 0000000..2fa58e2
--- /dev/null
+++ b/arch/arm/boot/dts/at91-wb45n.dtsi
@@ -0,0 +1,169 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * at91-wb45n.dtsi - Device Tree file for WB45NBT board
+ *
+ * Copyright (C) 2018 Laird
+ *
+ */
+
+#include "at91sam9g25.dtsi"
+
+/ {
+ model = "Laird Workgroup Bridge 45N - Atmel AT91SAM (dt)";
+ compatible = "laird,wb45n", "laird,wbxx", "atmel,at91sam9x5", "atmel,at91sam9";
+
+ chosen {
+ bootargs = "ubi.mtd=6 root=ubi0:rootfs rootfstype=ubifs rw";
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory {
+ reg = <0x20000000 0x4000000>;
+ };
+
+ ahb {
+ apb {
+ shdwc at fffffe10 {
+ atmel,wakeup-mode = "low";
+ };
+
+ pinctrl at fffff400 {
+ usb2 {
+ pinctrl_board_usb2: usb2-board {
+ atmel,pins =
+ <AT91_PIOB 11 AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>; /* PB11 gpio vbus sense, deglitch */
+ };
+ };
+ };
+
+ rstc at fffffe00 {
+ compatible = "atmel,sama5d3-rstc";
+ };
+
+ };
+ };
+
+ atheros {
+ compatible = "atheros,ath6kl";
+ atheros,board-id = "SD32";
+ };
+};
+
+&slow_xtal {
+ clock-frequency = <32768>;
+};
+
+&main_xtal {
+ clock-frequency = <12000000>;
+};
+
+&ebi {
+ status = "okay";
+ nand_controller: nand-controller {
+ pinctrl-0 = <&pinctrl_nand_cs &pinctrl_nand_rb &pinctrl_nand_oe_we>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ nand at 3 {
+ reg = <0x3 0x0 0x800000>;
+ rb-gpios = <&pioD 5 GPIO_ACTIVE_HIGH>;
+ cs-gpios = <&pioD 4 GPIO_ACTIVE_HIGH>;
+ nand-bus-width = <8>;
+ nand-ecc-mode = "hw";
+ nand-ecc-strength = <4>;
+ nand-ecc-step-size = <512>;
+ nand-on-flash-bbt;
+ label = "atmel_nand";
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ at91bootstrap at 0 {
+ label = "at91bs";
+ reg = <0x0 0x20000>;
+ };
+
+ uboot at 20000 {
+ label = "u-boot";
+ reg = <0x20000 0x80000>;
+ };
+
+ ubootenv at a0000 {
+ label = "u-boot-env";
+ reg = <0xa0000 0x20000>;
+ };
+
+ ubootenv at c0000 {
+ label = "redund-env";
+ reg = <0xc0000 0x20000>;
+ };
+
+ kernel-a at e0000 {
+ label = "kernel-a";
+ reg = <0xe0000 0x280000>;
+ };
+
+ kernel-b at 360000 {
+ label = "kernel-b";
+ reg = <0x360000 0x280000>;
+ };
+
+ rootfs-a at 5e0000 {
+ label = "rootfs-a";
+ reg = <0x5e0000 0x2600000>;
+ };
+
+ rootfs-b at 2be0000 {
+ label = "rootfs-b";
+ reg = <0x2be0000 0x2600000>;
+ };
+
+ user at 51e0000 {
+ label = "user";
+ reg = <0x51e0000 0x2dc0000>;
+ };
+
+ logs at 7fa0000 {
+ label = "logs";
+ reg = <0x7fa0000 0x60000>;
+ };
+
+ };
+ };
+ };
+};
+
+&usb0 {
+ num-ports = <2>;
+ atmel,vbus-gpio = <
+ &pioB 12 GPIO_ACTIVE_HIGH
+ &pioA 31 GPIO_ACTIVE_HIGH
+ >;
+ atmel,oc-gpio = <&pioB 13 GPIO_ACTIVE_LOW>;
+};
+
+&macb0 {
+ phy-mode = "rmii";
+};
+
+&spi0 {
+ cs-gpios = <&pioA 14 0>, <&pioA 7 0>, <0>, <0>;
+};
+
+&usb2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_board_usb2>;
+ atmel,vbus-gpio = <&pioB 11 GPIO_ACTIVE_HIGH>;
+};
+
+&mmc0 {
+ pinctrl-0 = <
+ &pinctrl_mmc0_slot0_clk_cmd_dat0
+ &pinctrl_mmc0_slot0_dat1_3>;
+ slot at 0 {
+ reg = <0>;
+ bus-width = <4>;
+ };
+};
--
2.7.4
^ permalink raw reply related
* [PATCH 06/10] ARM: OMAP1: ams-delta FIQ: don't use static GPIO numbers
From: Linus Walleij @ 2018-06-14 8:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180609140224.32606-6-jmkrzyszt@gmail.com>
On Sat, Jun 9, 2018 at 4:02 PM, Janusz Krzysztofik <jmkrzyszt@gmail.com> wrote:
> With introduction of GPIO lookup tables to Amstrad Delta board init
> file, semantics of symbols representing OMAP GPIO pins defined in
> <mach/board-ams-delta.h> changed from statically assigned global GPIO
> numbers to hardware pin numbers local to OMAP "gpio-0-15" chip.
>
> This patch modifies deferred FIQ interrupt handler so it no longer uses
> static GPIO numbers in favour of IRQ data descriptors obtained at FIQ
> initialization time from descriptor of the GPIO chip with use of its
> hardware pin numbers. The chip descriptor is passed from the board
> init file.
>
> As a benefit, the deferred FIQ handler should work faster.
>
> Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
Making the kernel a better place, so:
Acked-by: Linus Walleij <linus.walleij@linaro.org>
> +/*
> + * Some drivers may not use GPIO lookup tables but need to be provided
> + * with GPIO numbers. The same applies to GPIO based IRQ lines - some
> + * drivers may even not use GPIO layer but expect just IRQ numbers.
> + * We could either define GPIO lookup tables then use them on behalf
> + * of those devices, or we can use GPIO driver level methods for
> + * identification of GPIO and IRQ numbers. For the purpose of the latter,
> + * defina a helper function which identifies GPIO chips by their labels.
> + */
> +static int gpiochip_match_by_label(struct gpio_chip *chip, void *data)
> +{
> + char *label = data;
> +
> + return !strcmp(label, chip->label);
> +}
> +
> +/*
> + * The purpose of this function is to take care of proper initialization of
> + * devices and data structures which depend on GPIO lines provided by OMAP GPIO
> + * banks but their drivers don't use GPIO lookup tables or GPIO layer at all.
> + * The function may be called as soon as OMAP GPIO devices are probed.
> + * Since that happens at postcore_initcall, it can be called successfully
> + * from init_machine or later.
> + * Dependent devices may be registered from within this function or later.
> + */
> +static void __init omap_gpio_deps_init(void)
> +{
> + struct gpio_chip *chip;
> +
> + chip = gpiochip_find(OMAP_GPIO_LABEL, gpiochip_match_by_label);
> + if (!chip) {
> + pr_err("%s: OMAP GPIO chip not found\n", __func__);
> + return;
> + }
> +
> + ams_delta_init_fiq(chip);
> +}
This is some real stunt work isn't it.
We should really think about ways to get gpiolib more helpful for board
setups like this, but it seems complex.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] pinctrl: actions: Fix uninitialized error in owl_pin_config_set()
From: Linus Walleij @ 2018-06-14 8:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528452347-23986-1-git-send-email-geert@linux-m68k.org>
On Fri, Jun 8, 2018 at 12:05 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> With gcc 4.1.2:
>
> drivers/pinctrl/actions/pinctrl-owl.c: In function ?owl_pin_config_set?:
> drivers/pinctrl/actions/pinctrl-owl.c:336: warning: ?ret? may be used uninitialized in this function
>
> Indeed, if num_configs is zero, the uninitialized value will be returned
> as an error code.
>
> Fix this by preinitializing it to zero.
>
> Fixes: 2242ddfbf4d699b5 ("pinctrl: actions: Add Actions S900 pinctrl driver")
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Patch applied with Manivannan's ACK.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] pinctrl: pinctrl-single: Avoid divisions in context save/restore
From: Linus Walleij @ 2018-06-14 8:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528374274-26385-1-git-send-email-geert+renesas@glider.be>
On Thu, Jun 7, 2018 at 2:24 PM, Geert Uytterhoeven
<geert+renesas@glider.be> wrote:
> The divisions (and multiplications) can be avoided by changing the loops
> to use increments of mux_bytes instead of 1.
> While at it, remove the unneeded casts when assigning void pointers.
>
> This saves +100 bytes of kernel size on arm32/arm64.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Patch applied for v4.19.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v7 3/6] mfd: at91-usart: added mfd driver for usart
From: Alexandre Belloni @ 2018-06-14 8:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1086330e-40e4-8d9b-50aa-1ae9bf48aa22@microchip.com>
On 14/06/2018 11:22:25+0300, Radu Pirea wrote:
> On 06/14/2018 10:58 AM, Ludovic Desroches wrote:
> > > +static int at91_usart_mode_probe(struct platform_device *pdev)
> > > +{
> > > + struct mfd_cell cell;
> > > + u32 opmode = AT91_USART_MODE_SERIAL;
> > > +
> > > + device_property_read_u32(&pdev->dev, "atmel,usart-mode", &opmode);
> > > +
> > > + switch (opmode) {
> > > + case AT91_USART_MODE_SPI:
> > > + cell = at91_usart_spi_subdev;
> > > + break;
> > > + case AT91_USART_MODE_SERIAL:
> > > + cell = at91_usart_serial_subdev;
> > > + break;
> > > + default:
> > > + break;
> >
> > If there is an invalid opmode from the DT, you will pass a non initialized cell
> > to mfd_add_device().
> >
> > Regards
> >
> > Ludovic
>
> Hi Ludovic,
>
> Tnx. That's true. How is better to do if atmel,usart-mode has an invalid
> value? To initialize cell with at91_usart_serial_subdev or to print an error
> message and return -EINVAL?
>
Returning an error is probably the correct choice because it means the
DT has an invalid value (something was done and is wrong).
--
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH][next] pinctrl: pinctrl-single: add allocation failure checking of saved_vals
From: Linus Walleij @ 2018-06-14 8:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180606134338.4645-1-colin.king@canonical.com>
On Wed, Jun 6, 2018 at 3:43 PM, Colin King <colin.king@canonical.com> wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Currently saved_vals is being allocated and there is no check for
> failed allocation (which is more likely than normal when using
> GFP_ATOMIC). Fix this by checking for a failed allocation and
> propagating this error return down the the caller chain.
>
> Detected by CoverityScan, CID#1469841 ("Dereference null return value")
>
> Fixes: 88a1dbdec682 ("pinctrl: pinctrl-single: Add functions to save and restore pinctrl context")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Patch applied with Johan's and Tony's ACKs.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2] net: ethernet: stmmac: dwmac-rk: Add GMAC support for PX30
From: Heiko Stübner @ 2018-06-14 8:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3aa2445f-ab2a-93b6-3a49-36be6c98d327@rock-chips.com>
Am Donnerstag, 14. Juni 2018, 10:14:31 CEST schrieb David Wu:
> Hi Heiko,
>
> ? 2018?06?14? 15:54, Heiko St?bner ??:
> > I don't see that new clock documented in the dt-binding.
> > Also, which clock from the clock-controller does this connect to?
>
> The clock is the "SCLK_GMAC_RMII" at the clock-controller, which could
> be set rate by the link speed.
Hmm, while these huge number of clocks are somewhat strange,
shouldn't it be named something with _rmii instead of _speed then?
Also, I don't see any clk_enable action for that new clock, so you could
end up with being off?
And someone could convert the driver to use the new clk-bulk APIs [0],
so the large number of clk_prepare_enable calls would be a bit
trimmed down.
Heiko
[0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/clk/clk-bulk.c
^ permalink raw reply
* [PATCH v1 4/4] mailbox: Add support for i.MX7D messaging unit
From: Dong Aisheng @ 2018-06-14 8:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180613124850.w3bzerkpkbql6ite@pengutronix.de>
Hi Sascha,
On Wed, Jun 13, 2018 at 8:48 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> On Wed, Jun 13, 2018 at 08:21:10PM +0800, Dong Aisheng wrote:
>> Hi Oleksij,
>>
>> On Fri, Jun 1, 2018 at 2:58 PM, Oleksij Rempel <o.rempel@pengutronix.de> wrote:
>> > The Mailbox controller is able to send messages (up to 4 32 bit words)
>> > between the endpoints.
>>
>> Could we really be able to send up to 4 42bit words with this driver?
>>
>> It looks to me the current Mailbox framework is more designed for share mem
>> transfer which does not fit i.MX MU well.
>
> The mailbox framework just defines channels and messages. A message is a
> void * which may contain arbitrary data or even no data at all; some
> drivers simply ignore the message pointer, so in fact they act as a
> doorbell unit only.
>
> There's nothing about shared memory in the mailbox framework, but of
> course you can combine a mailbox driver and shared memory to a remote
> message mechanism. That could be done with the i.MX MU aswell and would
> indeed be a good match for the hardware.
>
Yes, you're right. My earlier reply is less accurate.
It seems the actual data type is interpreted by the underlying MU driver.
Regards
Dong Aisheng
> Sascha
>
> --
> Pengutronix e.K. | |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH v7 3/6] mfd: at91-usart: added mfd driver for usart
From: Radu Pirea @ 2018-06-14 8:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180614075849.dfiqwcu6rtzgpzq7@rfolt0960.corp.atmel.com>
On 06/14/2018 10:58 AM, Ludovic Desroches wrote:
> On Wed, Jun 13, 2018 at 07:36:18PM +0300, Radu Pirea wrote:
>> This mfd driver is just a wrapper over atmel_serial driver and
>> spi-at91-usart driver. Selection of one of the drivers is based on a
>> property from device tree. If the property is not specified, the default
>> driver is atmel_serial.
>>
>> Signed-off-by: Radu Pirea <radu.pirea@microchip.com>
>> Acked-by: Rob Herring <robh@kernel.org>
>> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
>> Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
>> ---
>> drivers/mfd/Kconfig | 9 ++++++
>> drivers/mfd/Makefile | 1 +
>> drivers/mfd/at91-usart.c | 69 ++++++++++++++++++++++++++++++++++++++++
>> 3 files changed, 79 insertions(+)
>> create mode 100644 drivers/mfd/at91-usart.c
>>
>> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
>> index b860eb5aa194..a886672b960d 100644
>> --- a/drivers/mfd/Kconfig
>> +++ b/drivers/mfd/Kconfig
>> @@ -99,6 +99,15 @@ config MFD_AAT2870_CORE
>> additional drivers must be enabled in order to use the
>> functionality of the device.
>>
>> +config MFD_AT91_USART
>> + tristate "AT91 USART Driver"
>> + select MFD_CORE
>> + help
>> + Select this to get support for AT91 USART IP. This is a wrapper
>> + over at91-usart-serial driver and usart-spi-driver. Only one function
>> + can be used at a time. The choice is done at boot time by the probe
>> + function of this MFD driver according to a device tree property.
>> +
>> config MFD_ATMEL_FLEXCOM
>> tristate "Atmel Flexcom (Flexible Serial Communication Unit)"
>> select MFD_CORE
>> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
>> index d9d2cf0d32ef..db1332aa96db 100644
>> --- a/drivers/mfd/Makefile
>> +++ b/drivers/mfd/Makefile
>> @@ -185,6 +185,7 @@ obj-$(CONFIG_MFD_SPMI_PMIC) += qcom-spmi-pmic.o
>> obj-$(CONFIG_TPS65911_COMPARATOR) += tps65911-comparator.o
>> obj-$(CONFIG_MFD_TPS65090) += tps65090.o
>> obj-$(CONFIG_MFD_AAT2870_CORE) += aat2870-core.o
>> +obj-$(CONFIG_MFD_AT91_USART) += at91-usart.o
>> obj-$(CONFIG_MFD_ATMEL_FLEXCOM) += atmel-flexcom.o
>> obj-$(CONFIG_MFD_ATMEL_HLCDC) += atmel-hlcdc.o
>> obj-$(CONFIG_MFD_ATMEL_SMC) += atmel-smc.o
>> diff --git a/drivers/mfd/at91-usart.c b/drivers/mfd/at91-usart.c
>> new file mode 100644
>> index 000000000000..3014ce532644
>> --- /dev/null
>> +++ b/drivers/mfd/at91-usart.c
>> @@ -0,0 +1,69 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Driver for AT91 USART
>> + *
>> + * Copyright (C) 2018 Microchip Technology
>> + *
>> + * Author: Radu Pirea <radu.pirea@microchip.com>
>> + *
>> + */
>> +
>> +#include <dt-bindings/mfd/at91-usart.h>
>> +
>> +#include <linux/module.h>
>> +#include <linux/mfd/core.h>
>> +#include <linux/property.h>
>> +
>> +static struct mfd_cell at91_usart_spi_subdev = {
>> + .name = "at91_usart_spi",
>> + .of_compatible = "microchip,at91sam9g45-usart-spi",
>> + };
>> +
>> +static struct mfd_cell at91_usart_serial_subdev = {
>> + .name = "atmel_usart_serial",
>> + .of_compatible = "atmel,at91rm9200-usart-serial",
>> + };
>> +
>> +static int at91_usart_mode_probe(struct platform_device *pdev)
>> +{
>> + struct mfd_cell cell;
>> + u32 opmode = AT91_USART_MODE_SERIAL;
>> +
>> + device_property_read_u32(&pdev->dev, "atmel,usart-mode", &opmode);
>> +
>> + switch (opmode) {
>> + case AT91_USART_MODE_SPI:
>> + cell = at91_usart_spi_subdev;
>> + break;
>> + case AT91_USART_MODE_SERIAL:
>> + cell = at91_usart_serial_subdev;
>> + break;
>> + default:
>> + break;
>
> If there is an invalid opmode from the DT, you will pass a non initialized cell
> to mfd_add_device().
>
> Regards
>
> Ludovic
Hi Ludovic,
Tnx. That's true. How is better to do if atmel,usart-mode has an invalid
value? To initialize cell with at91_usart_serial_subdev or to print an
error message and return -EINVAL?
Regards.
Radu Pirea
>
>> + }
>> +
>> + return devm_mfd_add_devices(&pdev->dev, PLATFORM_DEVID_AUTO, &cell, 1,
>> + NULL, 0, NULL);
>> +}
>> +
>> +static const struct of_device_id at91_usart_mode_of_match[] = {
>> + { .compatible = "atmel,at91rm9200-usart" },
>> + { .compatible = "atmel,at91sam9260-usart" },
>> + { /* sentinel */ }
>> +};
>> +
>> +MODULE_DEVICE_TABLE(of, at91_flexcom_of_match);
>> +
>> +static struct platform_driver at91_usart_mfd = {
>> + .probe = at91_usart_mode_probe,
>> + .driver = {
>> + .name = "at91_usart_mode",
>> + .of_match_table = at91_usart_mode_of_match,
>> + },
>> +};
>> +
>> +module_platform_driver(at91_usart_mfd);
>> +
>> +MODULE_AUTHOR("Radu Pirea <radu.pirea@microchip.com>");
>> +MODULE_DESCRIPTION("AT91 USART MFD driver");
>> +MODULE_LICENSE("GPL v2");
>> --
>> 2.17.1
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2] net: ethernet: stmmac: dwmac-rk: Add GMAC support for PX30
From: David Wu @ 2018-06-14 8:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1961033.25ax7s0Z5i@diego>
Hi Heiko,
? 2018?06?14? 15:54, Heiko St?bner ??:
> I don't see that new clock documented in the dt-binding.
> Also, which clock from the clock-controller does this connect to?
The clock is the "SCLK_GMAC_RMII" at the clock-controller, which could
be set rate by the link speed.
^ permalink raw reply
* [PATCH v3 1/3] media: v4l2-ctrl: Change control for VP8 profile to menu control
From: Keiichi Watanabe @ 2018-06-14 8:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2c5a4dbf-6640-052b-a873-76b4c50abe73@linaro.org>
Thanks, Stanimir
On Thu, Jun 14, 2018 at 5:04 PM, Stanimir Varbanov
<stanimir.varbanov@linaro.org> wrote:
> Hi Keiichi,
>
> On 06/14/2018 10:46 AM, Keiichi Watanabe wrote:
>> Add a menu control V4L2_CID_MPEG_VIDEO_VP8_PROFILE for VP8 profile and
>> make V4L2_CID_MPEG_VIDEO_VPX_PROFILE an alias of it. This new control
>> is used to select a desired profile for VP8 encoder, and query for
>> supported profiles by VP8 encoder/decoder.
>>
>> Though we have originally a control V4L2_CID_MPEG_VIDEO_VPX_PROFILE and its name
>> contains 'VPX', it works only for VP8 because supported profiles usually differ
>> between VP8 and VP9. In addition, this contorol cannot be used for querying
>> since it is not a menu control but an integer control, which cannot return an
>> arbitrary set of supported profiles.
>>
>> The new control V4L2_CID_MPEG_VIDEO_VP8_PROFILE is a menu control as with
>> controls for other codec profiles. (e.g. H264)
>>
>> In addition, this patch also fixes the use of
>> V4L2_CID_MPEG_VIDEO_VPX_PROFILE in drivers of Qualcomm's venus and
>> Samsung's s5p-mfc.
>>
>> Signed-off-by: Keiichi Watanabe <keiichiw@chromium.org>
>> ---
>> .../media/uapi/v4l/extended-controls.rst | 27 ++++++++++++++++---
>> drivers/media/platform/qcom/venus/core.h | 2 +-
>> .../media/platform/qcom/venus/hfi_helper.h | 12 ++++-----
>> .../media/platform/qcom/venus/vdec_ctrls.c | 10 ++++---
>> drivers/media/platform/qcom/venus/venc.c | 14 +++++-----
>> .../media/platform/qcom/venus/venc_ctrls.c | 12 +++++----
>> drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 15 +++++------
>> drivers/media/v4l2-core/v4l2-ctrls.c | 12 ++++++++-
>> include/uapi/linux/v4l2-controls.h | 11 +++++++-
>> 9 files changed, 79 insertions(+), 36 deletions(-)
>>
>> diff --git a/Documentation/media/uapi/v4l/extended-controls.rst b/Documentation/media/uapi/v4l/extended-controls.rst
>> index 03931f9b1285..de99eafb0872 100644
>> --- a/Documentation/media/uapi/v4l/extended-controls.rst
>> +++ b/Documentation/media/uapi/v4l/extended-controls.rst
>> @@ -1955,9 +1955,30 @@ enum v4l2_vp8_golden_frame_sel -
>> ``V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP (integer)``
>> Quantization parameter for a P frame for VP8.
>>
>> -``V4L2_CID_MPEG_VIDEO_VPX_PROFILE (integer)``
>> - Select the desired profile for VPx encoder. Acceptable values are 0,
>> - 1, 2 and 3 corresponding to encoder profiles 0, 1, 2 and 3.
>> +.. _v4l2-mpeg-video-vp8-profile:
>> +
>> +``V4L2_CID_MPEG_VIDEO_VP8_PROFILE``
>> + (enum)
>> +
>> +enum v4l2_mpeg_video_vp8_profile -
>> + This control allows to select the profile for VP8 encoder.
>> + This is also used to enumerate supported profiles by VP8 encoder or decoder.
>> + Possible values are:
>> +
>> +
>> +
>> +.. flat-table::
>> + :header-rows: 0
>> + :stub-columns: 0
>> +
>> + * - ``V4L2_MPEG_VIDEO_VP8_PROFILE_0``
>> + - Profile 0
>> + * - ``V4L2_MPEG_VIDEO_VP8_PROFILE_1``
>> + - Profile 1
>> + * - ``V4L2_MPEG_VIDEO_VP8_PROFILE_2``
>> + - Profile 2
>> + * - ``V4L2_MPEG_VIDEO_VP8_PROFILE_3``
>> + - Profile 3
>>
>>
>> High Efficiency Video Coding (HEVC/H.265) Control Reference
>> diff --git a/drivers/media/platform/qcom/venus/core.h b/drivers/media/platform/qcom/venus/core.h
>> index 0360d295f4c8..f242e7f9f6a2 100644
>> --- a/drivers/media/platform/qcom/venus/core.h
>> +++ b/drivers/media/platform/qcom/venus/core.h
>> @@ -159,7 +159,7 @@ struct venc_controls {
>> struct {
>> u32 mpeg4;
>> u32 h264;
>> - u32 vpx;
>> + u32 vp8;
>> } profile;
>> struct {
>> u32 mpeg4;
>> diff --git a/drivers/media/platform/qcom/venus/hfi_helper.h b/drivers/media/platform/qcom/venus/hfi_helper.h
>> index 55d8eb21403a..07bf49dd2ec6 100644
>> --- a/drivers/media/platform/qcom/venus/hfi_helper.h
>> +++ b/drivers/media/platform/qcom/venus/hfi_helper.h
>> @@ -333,12 +333,12 @@
>> #define HFI_VC1_LEVEL_3 0x00000040
>> #define HFI_VC1_LEVEL_4 0x00000080
>>
>> -#define HFI_VPX_PROFILE_SIMPLE 0x00000001
>> -#define HFI_VPX_PROFILE_ADVANCED 0x00000002
>> -#define HFI_VPX_PROFILE_VERSION_0 0x00000004
>> -#define HFI_VPX_PROFILE_VERSION_1 0x00000008
>> -#define HFI_VPX_PROFILE_VERSION_2 0x00000010
>> -#define HFI_VPX_PROFILE_VERSION_3 0x00000020
>> +#define HFI_VP8_PROFILE_SIMPLE 0x00000001
>> +#define HFI_VP8_PROFILE_ADVANCED 0x00000002
>> +#define HFI_VP8_PROFILE_VERSION_0 0x00000004
>> +#define HFI_VP8_PROFILE_VERSION_1 0x00000008
>> +#define HFI_VP8_PROFILE_VERSION_2 0x00000010
>> +#define HFI_VP8_PROFILE_VERSION_3 0x00000020
>
> Please do not rename these driver internal defines, just leave VPX as it
> is now.
>
I got it. I'll fix it in the next revision of the patch.
Best regards,
Keiichi
>
> --
> regards,
> Stan
^ permalink raw reply
* [PATCH v3 2/3] media: v4l2-ctrl: Add control for VP9 profile
From: Stanimir Varbanov @ 2018-06-14 8:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180614074652.162796-3-keiichiw@chromium.org>
Hi Keiichi,
On 06/14/2018 10:46 AM, Keiichi Watanabe wrote:
> Add a new control V4L2_CID_MPEG_VIDEO_VP9_PROFILE for VP9
> profiles. This control allows to select a desired profile for VP9
> encoder and query for supported profiles by VP9 encoder/decoder.
>
> Though this control is similar to V4L2_CID_MPEG_VIDEO_VP8_PROFILE, we need to
> separate this control from it because supported profiles usually differ between
> VP8 and VP9.
>
> Signed-off-by: Keiichi Watanabe <keiichiw@chromium.org>
> ---
> .../media/uapi/v4l/extended-controls.rst | 25 +++++++++++++++++++
> drivers/media/v4l2-core/v4l2-ctrls.c | 11 ++++++++
> include/uapi/linux/v4l2-controls.h | 7 ++++++
> 3 files changed, 43 insertions(+)
>
> diff --git a/Documentation/media/uapi/v4l/extended-controls.rst b/Documentation/media/uapi/v4l/extended-controls.rst
> index de99eafb0872..095b42e9d6fe 100644
> --- a/Documentation/media/uapi/v4l/extended-controls.rst
> +++ b/Documentation/media/uapi/v4l/extended-controls.rst
> @@ -1980,6 +1980,31 @@ enum v4l2_mpeg_video_vp8_profile -
> * - ``V4L2_MPEG_VIDEO_VP8_PROFILE_3``
> - Profile 3
>
> +.. _v4l2-mpeg-video-vp9-profile:
> +
> +``V4L2_CID_MPEG_VIDEO_VP9_PROFILE``
> + (enum)
> +
> +enum v4l2_mpeg_video_vp9_profile -
what about vp9 levels, shouldn't we add them too? Or we will add it when
there is a user.
--
regards,
Stan
^ permalink raw reply
* [PATCH v3 1/3] media: v4l2-ctrl: Change control for VP8 profile to menu control
From: Stanimir Varbanov @ 2018-06-14 8:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180614074652.162796-2-keiichiw@chromium.org>
Hi Keiichi,
On 06/14/2018 10:46 AM, Keiichi Watanabe wrote:
> Add a menu control V4L2_CID_MPEG_VIDEO_VP8_PROFILE for VP8 profile and
> make V4L2_CID_MPEG_VIDEO_VPX_PROFILE an alias of it. This new control
> is used to select a desired profile for VP8 encoder, and query for
> supported profiles by VP8 encoder/decoder.
>
> Though we have originally a control V4L2_CID_MPEG_VIDEO_VPX_PROFILE and its name
> contains 'VPX', it works only for VP8 because supported profiles usually differ
> between VP8 and VP9. In addition, this contorol cannot be used for querying
> since it is not a menu control but an integer control, which cannot return an
> arbitrary set of supported profiles.
>
> The new control V4L2_CID_MPEG_VIDEO_VP8_PROFILE is a menu control as with
> controls for other codec profiles. (e.g. H264)
>
> In addition, this patch also fixes the use of
> V4L2_CID_MPEG_VIDEO_VPX_PROFILE in drivers of Qualcomm's venus and
> Samsung's s5p-mfc.
>
> Signed-off-by: Keiichi Watanabe <keiichiw@chromium.org>
> ---
> .../media/uapi/v4l/extended-controls.rst | 27 ++++++++++++++++---
> drivers/media/platform/qcom/venus/core.h | 2 +-
> .../media/platform/qcom/venus/hfi_helper.h | 12 ++++-----
> .../media/platform/qcom/venus/vdec_ctrls.c | 10 ++++---
> drivers/media/platform/qcom/venus/venc.c | 14 +++++-----
> .../media/platform/qcom/venus/venc_ctrls.c | 12 +++++----
> drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 15 +++++------
> drivers/media/v4l2-core/v4l2-ctrls.c | 12 ++++++++-
> include/uapi/linux/v4l2-controls.h | 11 +++++++-
> 9 files changed, 79 insertions(+), 36 deletions(-)
>
> diff --git a/Documentation/media/uapi/v4l/extended-controls.rst b/Documentation/media/uapi/v4l/extended-controls.rst
> index 03931f9b1285..de99eafb0872 100644
> --- a/Documentation/media/uapi/v4l/extended-controls.rst
> +++ b/Documentation/media/uapi/v4l/extended-controls.rst
> @@ -1955,9 +1955,30 @@ enum v4l2_vp8_golden_frame_sel -
> ``V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP (integer)``
> Quantization parameter for a P frame for VP8.
>
> -``V4L2_CID_MPEG_VIDEO_VPX_PROFILE (integer)``
> - Select the desired profile for VPx encoder. Acceptable values are 0,
> - 1, 2 and 3 corresponding to encoder profiles 0, 1, 2 and 3.
> +.. _v4l2-mpeg-video-vp8-profile:
> +
> +``V4L2_CID_MPEG_VIDEO_VP8_PROFILE``
> + (enum)
> +
> +enum v4l2_mpeg_video_vp8_profile -
> + This control allows to select the profile for VP8 encoder.
> + This is also used to enumerate supported profiles by VP8 encoder or decoder.
> + Possible values are:
> +
> +
> +
> +.. flat-table::
> + :header-rows: 0
> + :stub-columns: 0
> +
> + * - ``V4L2_MPEG_VIDEO_VP8_PROFILE_0``
> + - Profile 0
> + * - ``V4L2_MPEG_VIDEO_VP8_PROFILE_1``
> + - Profile 1
> + * - ``V4L2_MPEG_VIDEO_VP8_PROFILE_2``
> + - Profile 2
> + * - ``V4L2_MPEG_VIDEO_VP8_PROFILE_3``
> + - Profile 3
>
>
> High Efficiency Video Coding (HEVC/H.265) Control Reference
> diff --git a/drivers/media/platform/qcom/venus/core.h b/drivers/media/platform/qcom/venus/core.h
> index 0360d295f4c8..f242e7f9f6a2 100644
> --- a/drivers/media/platform/qcom/venus/core.h
> +++ b/drivers/media/platform/qcom/venus/core.h
> @@ -159,7 +159,7 @@ struct venc_controls {
> struct {
> u32 mpeg4;
> u32 h264;
> - u32 vpx;
> + u32 vp8;
> } profile;
> struct {
> u32 mpeg4;
> diff --git a/drivers/media/platform/qcom/venus/hfi_helper.h b/drivers/media/platform/qcom/venus/hfi_helper.h
> index 55d8eb21403a..07bf49dd2ec6 100644
> --- a/drivers/media/platform/qcom/venus/hfi_helper.h
> +++ b/drivers/media/platform/qcom/venus/hfi_helper.h
> @@ -333,12 +333,12 @@
> #define HFI_VC1_LEVEL_3 0x00000040
> #define HFI_VC1_LEVEL_4 0x00000080
>
> -#define HFI_VPX_PROFILE_SIMPLE 0x00000001
> -#define HFI_VPX_PROFILE_ADVANCED 0x00000002
> -#define HFI_VPX_PROFILE_VERSION_0 0x00000004
> -#define HFI_VPX_PROFILE_VERSION_1 0x00000008
> -#define HFI_VPX_PROFILE_VERSION_2 0x00000010
> -#define HFI_VPX_PROFILE_VERSION_3 0x00000020
> +#define HFI_VP8_PROFILE_SIMPLE 0x00000001
> +#define HFI_VP8_PROFILE_ADVANCED 0x00000002
> +#define HFI_VP8_PROFILE_VERSION_0 0x00000004
> +#define HFI_VP8_PROFILE_VERSION_1 0x00000008
> +#define HFI_VP8_PROFILE_VERSION_2 0x00000010
> +#define HFI_VP8_PROFILE_VERSION_3 0x00000020
Please do not rename these driver internal defines, just leave VPX as it
is now.
--
regards,
Stan
^ permalink raw reply
* [PATCH v7 3/6] mfd: at91-usart: added mfd driver for usart
From: Ludovic Desroches @ 2018-06-14 7:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180613163621.23995-4-radu.pirea@microchip.com>
On Wed, Jun 13, 2018 at 07:36:18PM +0300, Radu Pirea wrote:
> This mfd driver is just a wrapper over atmel_serial driver and
> spi-at91-usart driver. Selection of one of the drivers is based on a
> property from device tree. If the property is not specified, the default
> driver is atmel_serial.
>
> Signed-off-by: Radu Pirea <radu.pirea@microchip.com>
> Acked-by: Rob Herring <robh@kernel.org>
> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> ---
> drivers/mfd/Kconfig | 9 ++++++
> drivers/mfd/Makefile | 1 +
> drivers/mfd/at91-usart.c | 69 ++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 79 insertions(+)
> create mode 100644 drivers/mfd/at91-usart.c
>
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index b860eb5aa194..a886672b960d 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -99,6 +99,15 @@ config MFD_AAT2870_CORE
> additional drivers must be enabled in order to use the
> functionality of the device.
>
> +config MFD_AT91_USART
> + tristate "AT91 USART Driver"
> + select MFD_CORE
> + help
> + Select this to get support for AT91 USART IP. This is a wrapper
> + over at91-usart-serial driver and usart-spi-driver. Only one function
> + can be used at a time. The choice is done at boot time by the probe
> + function of this MFD driver according to a device tree property.
> +
> config MFD_ATMEL_FLEXCOM
> tristate "Atmel Flexcom (Flexible Serial Communication Unit)"
> select MFD_CORE
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index d9d2cf0d32ef..db1332aa96db 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -185,6 +185,7 @@ obj-$(CONFIG_MFD_SPMI_PMIC) += qcom-spmi-pmic.o
> obj-$(CONFIG_TPS65911_COMPARATOR) += tps65911-comparator.o
> obj-$(CONFIG_MFD_TPS65090) += tps65090.o
> obj-$(CONFIG_MFD_AAT2870_CORE) += aat2870-core.o
> +obj-$(CONFIG_MFD_AT91_USART) += at91-usart.o
> obj-$(CONFIG_MFD_ATMEL_FLEXCOM) += atmel-flexcom.o
> obj-$(CONFIG_MFD_ATMEL_HLCDC) += atmel-hlcdc.o
> obj-$(CONFIG_MFD_ATMEL_SMC) += atmel-smc.o
> diff --git a/drivers/mfd/at91-usart.c b/drivers/mfd/at91-usart.c
> new file mode 100644
> index 000000000000..3014ce532644
> --- /dev/null
> +++ b/drivers/mfd/at91-usart.c
> @@ -0,0 +1,69 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Driver for AT91 USART
> + *
> + * Copyright (C) 2018 Microchip Technology
> + *
> + * Author: Radu Pirea <radu.pirea@microchip.com>
> + *
> + */
> +
> +#include <dt-bindings/mfd/at91-usart.h>
> +
> +#include <linux/module.h>
> +#include <linux/mfd/core.h>
> +#include <linux/property.h>
> +
> +static struct mfd_cell at91_usart_spi_subdev = {
> + .name = "at91_usart_spi",
> + .of_compatible = "microchip,at91sam9g45-usart-spi",
> + };
> +
> +static struct mfd_cell at91_usart_serial_subdev = {
> + .name = "atmel_usart_serial",
> + .of_compatible = "atmel,at91rm9200-usart-serial",
> + };
> +
> +static int at91_usart_mode_probe(struct platform_device *pdev)
> +{
> + struct mfd_cell cell;
> + u32 opmode = AT91_USART_MODE_SERIAL;
> +
> + device_property_read_u32(&pdev->dev, "atmel,usart-mode", &opmode);
> +
> + switch (opmode) {
> + case AT91_USART_MODE_SPI:
> + cell = at91_usart_spi_subdev;
> + break;
> + case AT91_USART_MODE_SERIAL:
> + cell = at91_usart_serial_subdev;
> + break;
> + default:
> + break;
If there is an invalid opmode from the DT, you will pass a non initialized cell
to mfd_add_device().
Regards
Ludovic
> + }
> +
> + return devm_mfd_add_devices(&pdev->dev, PLATFORM_DEVID_AUTO, &cell, 1,
> + NULL, 0, NULL);
> +}
> +
> +static const struct of_device_id at91_usart_mode_of_match[] = {
> + { .compatible = "atmel,at91rm9200-usart" },
> + { .compatible = "atmel,at91sam9260-usart" },
> + { /* sentinel */ }
> +};
> +
> +MODULE_DEVICE_TABLE(of, at91_flexcom_of_match);
> +
> +static struct platform_driver at91_usart_mfd = {
> + .probe = at91_usart_mode_probe,
> + .driver = {
> + .name = "at91_usart_mode",
> + .of_match_table = at91_usart_mode_of_match,
> + },
> +};
> +
> +module_platform_driver(at91_usart_mfd);
> +
> +MODULE_AUTHOR("Radu Pirea <radu.pirea@microchip.com>");
> +MODULE_DESCRIPTION("AT91 USART MFD driver");
> +MODULE_LICENSE("GPL v2");
> --
> 2.17.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2] net: ethernet: stmmac: dwmac-rk: Add GMAC support for PX30
From: Heiko Stübner @ 2018-06-14 7:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528956927-32440-1-git-send-email-david.wu@rock-chips.com>
Hi David,
Am Donnerstag, 14. Juni 2018, 08:15:27 CEST schrieb David Wu:
> Add constants and callback functions for the dwmac on PX30 Soc.
> The base structure is the same, but registers and the bits in
> them are moved slightly, and add the clk_mac_speed for selecting
> mac speed.
>
> Signed-off-by: David Wu <david.wu@rock-chips.com>
[...]
> @@ -1042,6 +1101,10 @@ static int rk_gmac_clk_init(struct
> plat_stmmacenet_data *plat) }
> }
>
> + bsp_priv->clk_mac_speed = devm_clk_get(dev, "clk_mac_speed");
> + if (IS_ERR(bsp_priv->clk_mac_speed))
> + dev_err(dev, "cannot get clock %s\n", "clk_mac_speed");
> +
I don't see that new clock documented in the dt-binding.
Also, which clock from the clock-controller does this connect to?
Thanks
Heiko
^ permalink raw reply
* [PATCH] arm64/mm: Introduce a variable to hold base address of linear region
From: Bhupesh Sharma @ 2018-06-14 7:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3a05cd0e-466e-4fb6-a78a-4b363e21aaab@arm.com>
Hello James,
Thanks for your inputs, please see my responses inline.
On Wed, Jun 13, 2018 at 3:59 PM, James Morse <james.morse@arm.com> wrote:
> Hi Bhupesh,
>
> On 13/06/18 06:16, Bhupesh Sharma wrote:
>> On Tue, Jun 12, 2018 at 3:42 PM, James Morse <james.morse@arm.com> wrote:
>>> On 12/06/18 09:25, Bhupesh Sharma wrote:
>>>> On Tue, Jun 12, 2018 at 12:23 PM, Ard Biesheuvel wrote:
>>>>> Userland code that assumes that the linear map cannot have a hole at
>>>>> the beginning should be fixed.
>
>>>> That is a separate case (although that needs fixing as well via a
>>>> kernel patch probably as the user-space tools rely on '/proc/iomem'
>>>> contents to determine the first System RAM/reserved range).
>>>
>>> This is for kexec-tools generating the kdump vmcore ELF headers in user-space?
>>
>> Yes, but again, I would like to reiterate that the case where I see a
>> hole at the start of the System RAM range (as I listed above) is just
>> a specific case, which probably deserves a separate patch. The current
>> patch though is for a generic issue (please see more details below).
>
>
>>>> # readelf -l vmcore
>>>>
>>>> ELF Header:
>>>> ........................
>>>>
>>>> Program Headers:
>>>> Type Offset VirtAddr PhysAddr
>>>> FileSiz MemSiz Flags Align
>>>> ..............................................................................................................................................................
>>>> LOAD 0x0000000076d40000 0xffff80017fe00000 0x0000000180000000
>>>> 0x0000001680000000 0x0000001680000000 RWE 0
>>>>
>>>> 3. So if we do a simple calculation:
>>>>
>>>> (VirtAddr + MemSiz) = 0xffff80017fe00000 + 0x0000001680000000 =
>>>> 0xFFFF8017FFE00000 != 0xffff801800000000.
>>>>
>>>> which indicates that the end virtual memory nodes are not the same
>>>> between vmlinux and vmcore.
>>>
>>> If I've followed this properly: the problem is that to generate the ELF headers
>>> in the post-kdump vmcore, at kdump-load-time kexec-tools has to guess the
>>> virtual addresses of the 'System RAM' regions it can see in /proc/iomem.
>>>
>>> The problem you are hitting is an invisible hole at the beginning of RAM,
>>> meaning user-space's guess_phys_to_virt() is off by the size of this hole.
>>>
>>> Isn't KASLR a special case for this? You must have to correct for that after
>>> kdump has happened, based on an elf-note in the vmcore. Can't we always do this?
>>
>> No, I hit this issue both for the KASLR and non-KASLR boot cases.
>
> Because in both cases there is a hole at the beginning of the linear-map. KASLR
> is a special-case of this as the kernel adds a variable sized hole to do the
> randomization.
>
> Surely treating this as one case makes your user-space code simpler.
Ok.
>> Fixing this in kernel space seems better to me as the definition of
>
> Is there a kernel bug? Changing the definitions of internal kernel variables for
> the benefit of code digging in /proc/kcore|/dev/mem isn't going to fly.
Indeed, I am not advocating to change the kernel space code just to
suit the user-space tools. However in this particular case the
'memstart_addr' and PHY_OFFSET value are computed as 0 which IMO is
not the real representation of the start of System RAM as the 1st
memory block available in Linux starts from 2MB [as confirmed by the
'memblock_start_of_DRAM()' value of 0x200000] and indicated by
'/proc/iomem':
# head -1 /proc/iomem
00200000-0021ffff : reserved
I think reading the kernel code and finding 'memstart_addr' and
PHY_OFFSET as 0, one gets the notion that the base of System RAM
starts from 0, which is incorrect in the above case as it starts from
2MB as the 1st block is of the type EfiReservedMemType
>> 'memstart_addr' is that it indicates the start of the physical ram,
>> but since in this case there is a hole at the start of the system ram
>> visible in Linux (and thus to user-space), but 'memstart_addr' is
>> still 0 which seems contradictory at the least. This causes PHY_OFFSET
>> to be 0 as well, which is again contradictory.
>
>
>>>> This happens because the kexec-tools rely on 'proc/iomem' contents
>>>> while 'memstart_addr' is computed as 0 by kernel (as value of
>>>> memblock_start_of_DRAM() < ARM64_MEMSTART_ALIGN).
>>>
>>>> Returning back to this patch, this is a generic requirement where we
>>>> need the linear region start/base addresses in user-space applications
>>>> which is used to read addresses which lie in the linear region (for
>>>> e.g. when we read /proc/kcore contents).
>
> [...]
>
>>> This patch adds a variable that nothing uses, its going to be removed. You can't
>>> depend on reading this via /dev/mem.
>>>
>>> Could you add the information you need as an elf-note to the vmcore instead? You
>>> must already pick these up to handle kaslr. (from memory, this is where the
>>> kaslr-offset is described to user-space after we kdump).
>
>
>> No you are mixing up the two cases (please see above), the issue which
>> this patch fixes is for use cases where we don't have the vmcore
>> available in case of 'live' debugging via makedumpfile and crash tools
>> (we only have '/proc/kcore' or 'vmlinux' available in such cases). I
>> detailed the use case in [1] better (in a reply to Ard), I will detail
>> the use-case again below:
>
> Okay, so not kdump...
>
>
>> One specific use case that I am working on at the moment is the
>> makedumpfile '--mem-usage', which allows one to see the page numbers
>> of current system (1st kernel) in different use (please see
>> MAKEDUMPFILE(8) for more details).
>
> https://linux.die.net/man/8/makedumpfile :
> | Name: makedumpfile - make a small dumpfile of kdump
>
> ... but now we are talking about kdump again ...
>
>
>> Using this we can know how many pages are dumpable when different
>> dump_level is specified when invoking the makedumpfile.
>>
>> Normally, makedumpfile analyses the contents of '/proc/kcore' (while
>> excluding the crashkernel range), and then calculates the page number
>> of different kind per vmcoreinfo.
>
> $ apt-get source makedumpfile
> $ cd makedumpfile-1.5.3
> $ grep -r "kcore" .
> $
>
> I suspect there are two pieces of software with the same name here.
Here is the makedumpfile upstream git tree -
git://git.code.sf.net/p/makedumpfile/code
$ grep -r "kcore" .
./elf_info.c:int set_kcore_vmcoreinfo(uint64_t vmcoreinfo_addr,
uint64_t vmcoreinfo_len)
<..snip..>
./makedumpfile.8:# makedumpfile \-f \-\-mem\-usage /proc/kcore
<..snip..>
>> This use case requires directly reading the '/proc/kcore' and the
>> hence the PAGE_OFFSET value is used to determine the base address of
>> the linear region, whose value is not static in case of KASLR boot.
>
> Eh? I thought PAGE_OFFSET was a compile-time constant, and it was PHYS_OFFSET
> has a value other the aligned base of memory for KASLR.
Indeed, I tried to capture the dilemma in [1], just to recap:
'arch/arm64/include/asm/memory.h' defines PAGE_OFFSET as:
/*
* PAGE_OFFSET - the virtual address of the start of the linear map (top
* (VA_BITS - 1))
*/
#define PAGE_OFFSET (UL(0xffffffffffffffff) - \
(UL(1) << (VA_BITS - 1)) + 1)
However, for the KASLR case, we set the 'memstart_offset_seed ' to
use the 16-bits of the 'kaslr-seed' to randomize the linear region in
'arch/arm64/kernel/kaslr.c' :
u64 __init kaslr_early_init(u64 dt_phys)
{
<snip..>
/* use the top 16 bits to randomize the linear region */
memstart_offset_seed = seed >> 48;
<snip..>
}
So, either we should have a uniform way of representing the virtual
base of the linear range both in KASLR and non-KASLR boot cases (macro
or variable?). or we should rather look at removing the PAGE_OFFSET
usage from
the kernel (or atleast the confusing comment from 'memory.h') - again
please see [1] for the suggested approaches (bottom part of the query)
>
>> Another use-case is where the crash-utility uses the PAGE_OFFSET value
>> to perform a virtual-to-physical conversion for the address lying in
>> the linear region:
>
> In all cases the problem you have is assuming the first 'System RAM' value in
> /proc/iomem is the base of DRAM, which you can use a PHYS_OFFSET in your
> user-space phys2virt() calculation.
>
> What information do you need to make this work?
>
> You can evidently read kernel variables, why can't you read memstart_addr and do:
> | #define __phys_to_virt(x) \
> | ((unsigned long)((x) - memstart_addr) | PAGE_OFFSET)
>
> based on the physical addresses in /proc/iomem, and PAGE_OFFSET pulled out of
> the vmlinux.
>
> Reading memstart_addr is fragile, we might need to rename it
> wednesday_memstart_addr. If user-space needs this value to work with
> /proc/{kcore,vmcore} we should expose something like 'p2v_offset' as an elf-note
> on those files. (looks like they both have elf-headers).
Again I had suggested reading memstart_addr as one of the approaches
in [1], but seems we couldn't reach a conclusion, so I sent out this
approach to trigger another round of discussion.
BTW adding 'p2v_offset' as an elf-note seems like a good idea. If this
seems suitable, I can try and spin patch(es) using this approach (both
for the kernel and user-space tools).
Please share your views,
[1] https://www.spinics.net/lists/arm-kernel/msg655933.html
Thanks,
Bhupesh
^ permalink raw reply
* [PATCH v3 3/3] media: mtk-vcodec: Support VP9 profile in decoder
From: Keiichi Watanabe @ 2018-06-14 7:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180614074652.162796-1-keiichiw@chromium.org>
Add V4L2_CID_MPEG_VIDEO_VP9_PROFILE control in MediaTek decoder's
driver.
MediaTek decoder only supports profile 0 for now.
Signed-off-by: Keiichi Watanabe <keiichiw@chromium.org>
---
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
index 86f0a7134365..ba986232b953 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
@@ -1400,6 +1400,11 @@ int mtk_vcodec_dec_ctrls_setup(struct mtk_vcodec_ctx *ctx)
V4L2_CID_MIN_BUFFERS_FOR_CAPTURE,
0, 32, 1, 1);
ctrl->flags |= V4L2_CTRL_FLAG_VOLATILE;
+ v4l2_ctrl_new_std_menu(&ctx->ctrl_hdl,
+ &mtk_vcodec_dec_ctrl_ops,
+ V4L2_CID_MPEG_VIDEO_VP9_PROFILE,
+ V4L2_MPEG_VIDEO_VP9_PROFILE_0,
+ 0, V4L2_MPEG_VIDEO_VP9_PROFILE_0);
if (ctx->ctrl_hdl.error) {
mtk_v4l2_err("Adding control failed %d",
--
2.18.0.rc1.242.g61856ae69a-goog
^ permalink raw reply related
* [PATCH v3 2/3] media: v4l2-ctrl: Add control for VP9 profile
From: Keiichi Watanabe @ 2018-06-14 7:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180614074652.162796-1-keiichiw@chromium.org>
Add a new control V4L2_CID_MPEG_VIDEO_VP9_PROFILE for VP9
profiles. This control allows to select a desired profile for VP9
encoder and query for supported profiles by VP9 encoder/decoder.
Though this control is similar to V4L2_CID_MPEG_VIDEO_VP8_PROFILE, we need to
separate this control from it because supported profiles usually differ between
VP8 and VP9.
Signed-off-by: Keiichi Watanabe <keiichiw@chromium.org>
---
.../media/uapi/v4l/extended-controls.rst | 25 +++++++++++++++++++
drivers/media/v4l2-core/v4l2-ctrls.c | 11 ++++++++
include/uapi/linux/v4l2-controls.h | 7 ++++++
3 files changed, 43 insertions(+)
diff --git a/Documentation/media/uapi/v4l/extended-controls.rst b/Documentation/media/uapi/v4l/extended-controls.rst
index de99eafb0872..095b42e9d6fe 100644
--- a/Documentation/media/uapi/v4l/extended-controls.rst
+++ b/Documentation/media/uapi/v4l/extended-controls.rst
@@ -1980,6 +1980,31 @@ enum v4l2_mpeg_video_vp8_profile -
* - ``V4L2_MPEG_VIDEO_VP8_PROFILE_3``
- Profile 3
+.. _v4l2-mpeg-video-vp9-profile:
+
+``V4L2_CID_MPEG_VIDEO_VP9_PROFILE``
+ (enum)
+
+enum v4l2_mpeg_video_vp9_profile -
+ This control allows to select the profile for VP9 encoder.
+ This is also used to enumerate supported profiles by VP9 encoder or decoder.
+ Possible values are:
+
+
+
+.. flat-table::
+ :header-rows: 0
+ :stub-columns: 0
+
+ * - ``V4L2_MPEG_VIDEO_VP9_PROFILE_0``
+ - Profile 0
+ * - ``V4L2_MPEG_VIDEO_VP9_PROFILE_1``
+ - Profile 1
+ * - ``V4L2_MPEG_VIDEO_VP9_PROFILE_2``
+ - Profile 2
+ * - ``V4L2_MPEG_VIDEO_VP9_PROFILE_3``
+ - Profile 3
+
High Efficiency Video Coding (HEVC/H.265) Control Reference
-----------------------------------------------------------
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c b/drivers/media/v4l2-core/v4l2-ctrls.c
index e7e6340b395e..eacfab7574dc 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -438,6 +438,13 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
"3",
NULL,
};
+ static const char * const vp9_profile[] = {
+ "0",
+ "1",
+ "2",
+ "3",
+ NULL,
+ };
static const char * const flash_led_mode[] = {
"Off",
@@ -623,6 +630,8 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
return vpx_golden_frame_sel;
case V4L2_CID_MPEG_VIDEO_VP8_PROFILE:
return vp8_profile;
+ case V4L2_CID_MPEG_VIDEO_VP9_PROFILE:
+ return vp9_profile;
case V4L2_CID_JPEG_CHROMA_SUBSAMPLING:
return jpeg_chroma_subsampling;
case V4L2_CID_DV_TX_MODE:
@@ -849,6 +858,7 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_MPEG_VIDEO_VPX_I_FRAME_QP: return "VPX I-Frame QP Value";
case V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP: return "VPX P-Frame QP Value";
case V4L2_CID_MPEG_VIDEO_VP8_PROFILE: return "VP8 Profile";
+ case V4L2_CID_MPEG_VIDEO_VP9_PROFILE: return "VP9 Profile";
/* HEVC controls */
case V4L2_CID_MPEG_VIDEO_HEVC_I_FRAME_QP: return "HEVC I-Frame QP Value";
@@ -1190,6 +1200,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum v4l2_ctrl_type *type,
case V4L2_CID_TUNE_DEEMPHASIS:
case V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_SEL:
case V4L2_CID_MPEG_VIDEO_VP8_PROFILE:
+ case V4L2_CID_MPEG_VIDEO_VP9_PROFILE:
case V4L2_CID_DETECT_MD_MODE:
case V4L2_CID_MPEG_VIDEO_HEVC_PROFILE:
case V4L2_CID_MPEG_VIDEO_HEVC_LEVEL:
diff --git a/include/uapi/linux/v4l2-controls.h b/include/uapi/linux/v4l2-controls.h
index 2001823c3072..f03d3214eec2 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -597,6 +597,13 @@ enum v4l2_mpeg_video_vp8_profile {
};
/* Deprecated alias for compatibility reasons. */
#define V4L2_CID_MPEG_VIDEO_VPX_PROFILE V4L2_CID_MPEG_VIDEO_VP8_PROFILE
+#define V4L2_CID_MPEG_VIDEO_VP9_PROFILE (V4L2_CID_MPEG_BASE+512)
+enum v4l2_mpeg_video_vp9_profile {
+ V4L2_MPEG_VIDEO_VP9_PROFILE_0 = 0,
+ V4L2_MPEG_VIDEO_VP9_PROFILE_1 = 1,
+ V4L2_MPEG_VIDEO_VP9_PROFILE_2 = 2,
+ V4L2_MPEG_VIDEO_VP9_PROFILE_3 = 3,
+};
/* CIDs for HEVC encoding. */
--
2.18.0.rc1.242.g61856ae69a-goog
^ permalink raw reply related
* [PATCH v3 1/3] media: v4l2-ctrl: Change control for VP8 profile to menu control
From: Keiichi Watanabe @ 2018-06-14 7:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180614074652.162796-1-keiichiw@chromium.org>
Add a menu control V4L2_CID_MPEG_VIDEO_VP8_PROFILE for VP8 profile and
make V4L2_CID_MPEG_VIDEO_VPX_PROFILE an alias of it. This new control
is used to select a desired profile for VP8 encoder, and query for
supported profiles by VP8 encoder/decoder.
Though we have originally a control V4L2_CID_MPEG_VIDEO_VPX_PROFILE and its name
contains 'VPX', it works only for VP8 because supported profiles usually differ
between VP8 and VP9. In addition, this contorol cannot be used for querying
since it is not a menu control but an integer control, which cannot return an
arbitrary set of supported profiles.
The new control V4L2_CID_MPEG_VIDEO_VP8_PROFILE is a menu control as with
controls for other codec profiles. (e.g. H264)
In addition, this patch also fixes the use of
V4L2_CID_MPEG_VIDEO_VPX_PROFILE in drivers of Qualcomm's venus and
Samsung's s5p-mfc.
Signed-off-by: Keiichi Watanabe <keiichiw@chromium.org>
---
.../media/uapi/v4l/extended-controls.rst | 27 ++++++++++++++++---
drivers/media/platform/qcom/venus/core.h | 2 +-
.../media/platform/qcom/venus/hfi_helper.h | 12 ++++-----
.../media/platform/qcom/venus/vdec_ctrls.c | 10 ++++---
drivers/media/platform/qcom/venus/venc.c | 14 +++++-----
.../media/platform/qcom/venus/venc_ctrls.c | 12 +++++----
drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 15 +++++------
drivers/media/v4l2-core/v4l2-ctrls.c | 12 ++++++++-
include/uapi/linux/v4l2-controls.h | 11 +++++++-
9 files changed, 79 insertions(+), 36 deletions(-)
diff --git a/Documentation/media/uapi/v4l/extended-controls.rst b/Documentation/media/uapi/v4l/extended-controls.rst
index 03931f9b1285..de99eafb0872 100644
--- a/Documentation/media/uapi/v4l/extended-controls.rst
+++ b/Documentation/media/uapi/v4l/extended-controls.rst
@@ -1955,9 +1955,30 @@ enum v4l2_vp8_golden_frame_sel -
``V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP (integer)``
Quantization parameter for a P frame for VP8.
-``V4L2_CID_MPEG_VIDEO_VPX_PROFILE (integer)``
- Select the desired profile for VPx encoder. Acceptable values are 0,
- 1, 2 and 3 corresponding to encoder profiles 0, 1, 2 and 3.
+.. _v4l2-mpeg-video-vp8-profile:
+
+``V4L2_CID_MPEG_VIDEO_VP8_PROFILE``
+ (enum)
+
+enum v4l2_mpeg_video_vp8_profile -
+ This control allows to select the profile for VP8 encoder.
+ This is also used to enumerate supported profiles by VP8 encoder or decoder.
+ Possible values are:
+
+
+
+.. flat-table::
+ :header-rows: 0
+ :stub-columns: 0
+
+ * - ``V4L2_MPEG_VIDEO_VP8_PROFILE_0``
+ - Profile 0
+ * - ``V4L2_MPEG_VIDEO_VP8_PROFILE_1``
+ - Profile 1
+ * - ``V4L2_MPEG_VIDEO_VP8_PROFILE_2``
+ - Profile 2
+ * - ``V4L2_MPEG_VIDEO_VP8_PROFILE_3``
+ - Profile 3
High Efficiency Video Coding (HEVC/H.265) Control Reference
diff --git a/drivers/media/platform/qcom/venus/core.h b/drivers/media/platform/qcom/venus/core.h
index 0360d295f4c8..f242e7f9f6a2 100644
--- a/drivers/media/platform/qcom/venus/core.h
+++ b/drivers/media/platform/qcom/venus/core.h
@@ -159,7 +159,7 @@ struct venc_controls {
struct {
u32 mpeg4;
u32 h264;
- u32 vpx;
+ u32 vp8;
} profile;
struct {
u32 mpeg4;
diff --git a/drivers/media/platform/qcom/venus/hfi_helper.h b/drivers/media/platform/qcom/venus/hfi_helper.h
index 55d8eb21403a..07bf49dd2ec6 100644
--- a/drivers/media/platform/qcom/venus/hfi_helper.h
+++ b/drivers/media/platform/qcom/venus/hfi_helper.h
@@ -333,12 +333,12 @@
#define HFI_VC1_LEVEL_3 0x00000040
#define HFI_VC1_LEVEL_4 0x00000080
-#define HFI_VPX_PROFILE_SIMPLE 0x00000001
-#define HFI_VPX_PROFILE_ADVANCED 0x00000002
-#define HFI_VPX_PROFILE_VERSION_0 0x00000004
-#define HFI_VPX_PROFILE_VERSION_1 0x00000008
-#define HFI_VPX_PROFILE_VERSION_2 0x00000010
-#define HFI_VPX_PROFILE_VERSION_3 0x00000020
+#define HFI_VP8_PROFILE_SIMPLE 0x00000001
+#define HFI_VP8_PROFILE_ADVANCED 0x00000002
+#define HFI_VP8_PROFILE_VERSION_0 0x00000004
+#define HFI_VP8_PROFILE_VERSION_1 0x00000008
+#define HFI_VP8_PROFILE_VERSION_2 0x00000010
+#define HFI_VP8_PROFILE_VERSION_3 0x00000020
#define HFI_DIVX_FORMAT_4 0x1
#define HFI_DIVX_FORMAT_5 0x2
diff --git a/drivers/media/platform/qcom/venus/vdec_ctrls.c b/drivers/media/platform/qcom/venus/vdec_ctrls.c
index 032839bbc967..f4604b0cd57e 100644
--- a/drivers/media/platform/qcom/venus/vdec_ctrls.c
+++ b/drivers/media/platform/qcom/venus/vdec_ctrls.c
@@ -29,7 +29,7 @@ static int vdec_op_s_ctrl(struct v4l2_ctrl *ctrl)
break;
case V4L2_CID_MPEG_VIDEO_H264_PROFILE:
case V4L2_CID_MPEG_VIDEO_MPEG4_PROFILE:
- case V4L2_CID_MPEG_VIDEO_VPX_PROFILE:
+ case V4L2_CID_MPEG_VIDEO_VP8_PROFILE:
ctr->profile = ctrl->val;
break;
case V4L2_CID_MPEG_VIDEO_H264_LEVEL:
@@ -54,7 +54,7 @@ static int vdec_op_g_volatile_ctrl(struct v4l2_ctrl *ctrl)
switch (ctrl->id) {
case V4L2_CID_MPEG_VIDEO_H264_PROFILE:
case V4L2_CID_MPEG_VIDEO_MPEG4_PROFILE:
- case V4L2_CID_MPEG_VIDEO_VPX_PROFILE:
+ case V4L2_CID_MPEG_VIDEO_VP8_PROFILE:
ret = hfi_session_get_property(inst, ptype, &hprop);
if (!ret)
ctr->profile = hprop.profile_level.profile;
@@ -130,8 +130,10 @@ int vdec_ctrl_init(struct venus_inst *inst)
if (ctrl)
ctrl->flags |= V4L2_CTRL_FLAG_VOLATILE;
- ctrl = v4l2_ctrl_new_std(&inst->ctrl_handler, &vdec_ctrl_ops,
- V4L2_CID_MPEG_VIDEO_VPX_PROFILE, 0, 3, 1, 0);
+ ctrl = v4l2_ctrl_new_std_menu(&inst->ctrl_handler, &vdec_ctrl_ops,
+ V4L2_CID_MPEG_VIDEO_VP8_PROFILE,
+ V4L2_MPEG_VIDEO_VP8_PROFILE_3,
+ 0, V4L2_MPEG_VIDEO_VP8_PROFILE_0);
if (ctrl)
ctrl->flags |= V4L2_CTRL_FLAG_VOLATILE;
diff --git a/drivers/media/platform/qcom/venus/venc.c b/drivers/media/platform/qcom/venus/venc.c
index 6b2ce479584e..aa54dd005c3e 100644
--- a/drivers/media/platform/qcom/venus/venc.c
+++ b/drivers/media/platform/qcom/venus/venc.c
@@ -223,17 +223,17 @@ static int venc_v4l2_to_hfi(int id, int value)
case V4L2_MPEG_VIDEO_H264_ENTROPY_MODE_CABAC:
return HFI_H264_ENTROPY_CABAC;
}
- case V4L2_CID_MPEG_VIDEO_VPX_PROFILE:
+ case V4L2_CID_MPEG_VIDEO_VP8_PROFILE:
switch (value) {
case 0:
default:
- return HFI_VPX_PROFILE_VERSION_0;
+ return HFI_VP8_PROFILE_VERSION_0;
case 1:
- return HFI_VPX_PROFILE_VERSION_1;
+ return HFI_VP8_PROFILE_VERSION_1;
case 2:
- return HFI_VPX_PROFILE_VERSION_2;
+ return HFI_VP8_PROFILE_VERSION_2;
case 3:
- return HFI_VPX_PROFILE_VERSION_3;
+ return HFI_VP8_PROFILE_VERSION_3;
}
case V4L2_CID_MPEG_VIDEO_H264_LOOP_FILTER_MODE:
switch (value) {
@@ -756,8 +756,8 @@ static int venc_set_properties(struct venus_inst *inst)
level = venc_v4l2_to_hfi(V4L2_CID_MPEG_VIDEO_H264_LEVEL,
ctr->level.h264);
} else if (inst->fmt_cap->pixfmt == V4L2_PIX_FMT_VP8) {
- profile = venc_v4l2_to_hfi(V4L2_CID_MPEG_VIDEO_VPX_PROFILE,
- ctr->profile.vpx);
+ profile = venc_v4l2_to_hfi(V4L2_CID_MPEG_VIDEO_VP8_PROFILE,
+ ctr->profile.vp8);
level = 0;
} else if (inst->fmt_cap->pixfmt == V4L2_PIX_FMT_MPEG4) {
profile = venc_v4l2_to_hfi(V4L2_CID_MPEG_VIDEO_MPEG4_PROFILE,
diff --git a/drivers/media/platform/qcom/venus/venc_ctrls.c b/drivers/media/platform/qcom/venus/venc_ctrls.c
index 21e938a28662..e5162b78609d 100644
--- a/drivers/media/platform/qcom/venus/venc_ctrls.c
+++ b/drivers/media/platform/qcom/venus/venc_ctrls.c
@@ -101,8 +101,8 @@ static int venc_op_s_ctrl(struct v4l2_ctrl *ctrl)
case V4L2_CID_MPEG_VIDEO_H264_PROFILE:
ctr->profile.h264 = ctrl->val;
break;
- case V4L2_CID_MPEG_VIDEO_VPX_PROFILE:
- ctr->profile.vpx = ctrl->val;
+ case V4L2_CID_MPEG_VIDEO_VP8_PROFILE:
+ ctr->profile.vp8 = ctrl->val;
break;
case V4L2_CID_MPEG_VIDEO_MPEG4_LEVEL:
ctr->level.mpeg4 = ctrl->val;
@@ -248,6 +248,11 @@ int venc_ctrl_init(struct venus_inst *inst)
V4L2_MPEG_VIDEO_MULTI_SICE_MODE_MAX_BYTES,
0, V4L2_MPEG_VIDEO_MULTI_SLICE_MODE_SINGLE);
+ v4l2_ctrl_new_std_menu(&inst->ctrl_handler, &venc_ctrl_ops,
+ V4L2_CID_MPEG_VIDEO_VP8_PROFILE,
+ V4L2_MPEG_VIDEO_VP8_PROFILE_3,
+ 0, V4L2_MPEG_VIDEO_VP8_PROFILE_0);
+
v4l2_ctrl_new_std(&inst->ctrl_handler, &venc_ctrl_ops,
V4L2_CID_MPEG_VIDEO_BITRATE, BITRATE_MIN, BITRATE_MAX,
BITRATE_STEP, BITRATE_DEFAULT);
@@ -256,9 +261,6 @@ int venc_ctrl_init(struct venus_inst *inst)
V4L2_CID_MPEG_VIDEO_BITRATE_PEAK, BITRATE_MIN, BITRATE_MAX,
BITRATE_STEP, BITRATE_DEFAULT_PEAK);
- v4l2_ctrl_new_std(&inst->ctrl_handler, &venc_ctrl_ops,
- V4L2_CID_MPEG_VIDEO_VPX_PROFILE, 0, 3, 1, 0);
-
v4l2_ctrl_new_std(&inst->ctrl_handler, &venc_ctrl_ops,
V4L2_CID_MPEG_VIDEO_H264_I_FRAME_QP, 1, 51, 1, 26);
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
index 570f391f2cfd..3ad4f5073002 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
@@ -692,12 +692,12 @@ static struct mfc_control controls[] = {
.default_value = 10,
},
{
- .id = V4L2_CID_MPEG_VIDEO_VPX_PROFILE,
- .type = V4L2_CTRL_TYPE_INTEGER,
- .minimum = 0,
- .maximum = 3,
- .step = 1,
- .default_value = 0,
+ .id = V4L2_CID_MPEG_VIDEO_VP8_PROFILE,
+ .type = V4L2_CTRL_TYPE_MENU,
+ .minimum = V4L2_MPEG_VIDEO_VP8_PROFILE_0,
+ .maximum = V4L2_MPEG_VIDEO_VP8_PROFILE_3,
+ .default_value = V4L2_MPEG_VIDEO_VP8_PROFILE_0,
+ .menu_skip_mask = 0,
},
{
.id = V4L2_CID_MPEG_VIDEO_HEVC_I_FRAME_QP,
@@ -2057,7 +2057,7 @@ static int s5p_mfc_enc_s_ctrl(struct v4l2_ctrl *ctrl)
case V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP:
p->codec.vp8.rc_p_frame_qp = ctrl->val;
break;
- case V4L2_CID_MPEG_VIDEO_VPX_PROFILE:
+ case V4L2_CID_MPEG_VIDEO_VP8_PROFILE:
p->codec.vp8.profile = ctrl->val;
break;
case V4L2_CID_MPEG_VIDEO_HEVC_I_FRAME_QP:
@@ -2711,4 +2711,3 @@ void s5p_mfc_enc_init(struct s5p_mfc_ctx *ctx)
f.fmt.pix_mp.pixelformat = DEF_DST_FMT_ENC;
ctx->dst_fmt = find_format(&f, MFC_FMT_ENC);
}
-
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c b/drivers/media/v4l2-core/v4l2-ctrls.c
index d29e45516eb7..e7e6340b395e 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -431,6 +431,13 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
"Use Previous Specific Frame",
NULL,
};
+ static const char * const vp8_profile[] = {
+ "0",
+ "1",
+ "2",
+ "3",
+ NULL,
+ };
static const char * const flash_led_mode[] = {
"Off",
@@ -614,6 +621,8 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
return mpeg4_profile;
case V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_SEL:
return vpx_golden_frame_sel;
+ case V4L2_CID_MPEG_VIDEO_VP8_PROFILE:
+ return vp8_profile;
case V4L2_CID_JPEG_CHROMA_SUBSAMPLING:
return jpeg_chroma_subsampling;
case V4L2_CID_DV_TX_MODE:
@@ -839,7 +848,7 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_MPEG_VIDEO_VPX_MAX_QP: return "VPX Maximum QP Value";
case V4L2_CID_MPEG_VIDEO_VPX_I_FRAME_QP: return "VPX I-Frame QP Value";
case V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP: return "VPX P-Frame QP Value";
- case V4L2_CID_MPEG_VIDEO_VPX_PROFILE: return "VPX Profile";
+ case V4L2_CID_MPEG_VIDEO_VP8_PROFILE: return "VP8 Profile";
/* HEVC controls */
case V4L2_CID_MPEG_VIDEO_HEVC_I_FRAME_QP: return "HEVC I-Frame QP Value";
@@ -1180,6 +1189,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum v4l2_ctrl_type *type,
case V4L2_CID_DEINTERLACING_MODE:
case V4L2_CID_TUNE_DEEMPHASIS:
case V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_SEL:
+ case V4L2_CID_MPEG_VIDEO_VP8_PROFILE:
case V4L2_CID_DETECT_MD_MODE:
case V4L2_CID_MPEG_VIDEO_HEVC_PROFILE:
case V4L2_CID_MPEG_VIDEO_HEVC_LEVEL:
diff --git a/include/uapi/linux/v4l2-controls.h b/include/uapi/linux/v4l2-controls.h
index 8d473c979b61..2001823c3072 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -587,7 +587,16 @@ enum v4l2_vp8_golden_frame_sel {
#define V4L2_CID_MPEG_VIDEO_VPX_MAX_QP (V4L2_CID_MPEG_BASE+508)
#define V4L2_CID_MPEG_VIDEO_VPX_I_FRAME_QP (V4L2_CID_MPEG_BASE+509)
#define V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP (V4L2_CID_MPEG_BASE+510)
-#define V4L2_CID_MPEG_VIDEO_VPX_PROFILE (V4L2_CID_MPEG_BASE+511)
+
+#define V4L2_CID_MPEG_VIDEO_VP8_PROFILE (V4L2_CID_MPEG_BASE+511)
+enum v4l2_mpeg_video_vp8_profile {
+ V4L2_MPEG_VIDEO_VP8_PROFILE_0 = 0,
+ V4L2_MPEG_VIDEO_VP8_PROFILE_1 = 1,
+ V4L2_MPEG_VIDEO_VP8_PROFILE_2 = 2,
+ V4L2_MPEG_VIDEO_VP8_PROFILE_3 = 3,
+};
+/* Deprecated alias for compatibility reasons. */
+#define V4L2_CID_MPEG_VIDEO_VPX_PROFILE V4L2_CID_MPEG_VIDEO_VP8_PROFILE
/* CIDs for HEVC encoding. */
--
2.18.0.rc1.242.g61856ae69a-goog
^ permalink raw reply related
* [PATCH v3 0/3] Add controls for VP8/VP9 profile
From: Keiichi Watanabe @ 2018-06-14 7:46 UTC (permalink / raw)
To: linux-arm-kernel
This patch series add new menu controls V4L2_CID_MPEG_VIDEO_VP8_PROFILE and
V4L2_CID_MPEG_VIDEO_VP9_PROFILE for VP8/VP9 profiles. These controls can be used
to select a desired profile for VP8/VP9 encoders. In addition, they are also
used to query for supported profiles by an encoder or a decoder.
Patch 1 adds a control V4L2_CID_MPEG_VIDEO_VP8_PROFILE for VP8 profile. Though
V4L2_CID_MPEG_VIDEO_VPX_PROFILE is originally used for VP8 profile, this control
is not good by the following reasons:
(i) Despite the name contains 'VPX', it cannot be used for VP9 because supported
profiles differ between VP8 and VP9.
(ii) Unlike other controls for profiles (e.g. H264), this is not a menu control
but an integer control, which cannot be used to query for supported profiles.
Thus, V4L2_CID_MPEG_VIDEO_VPX_PROFILE is deprecated and become an alias of
V4L2_CID_MPEG_VIDEO_VP8_PROFILE. In addition, Patch 1 fixes the use of
V4L2_CID_MPEG_VIDEO_VPX_PROFILE in existing venus/s5p_mfc drivers.
Patch 2 adds a control V4L2_CID_MPEG_VIDEO_VP9_PROFILE for VP9 profile.
By patch 3, this control is supported in MediaTek decoder's driver, which
supports VP9 profile 0.
Version 3 changes:
- Add V4L2_CID_MPEG_VIDEO_VP8_PROFILE in v4l2-controls.
- Make V4L2_CID_MPEG_VIDEO_VPX_PROFILE to be an alias of
V4L2_CID_MPEG_VIDEO_VP8_PROFILE.
- Fix the use of V4L2_CID_MPEG_VIDEO_VPX_PROFILE in venus/s5p_mfc drivers.
- Small fix in mtk_vcodec_dec.
Version 2 changes:
- Support V4L2_CID_MPEG_VIDEO_VP9_PROFILE in MediaTek decoder's driver.
Version 1 changes:
- Add V4L2_CID_MPEG_VIDEO_VP9_PROFILE in v4l2-controls.
Keiichi Watanabe (3):
media: v4l2-ctrl: Change control for VP8 profile to menu control
media: v4l2-ctrl: Add control for VP9 profile
media: mtk-vcodec: Support VP9 profile in decoder
.../media/uapi/v4l/extended-controls.rst | 52 +++++++++++++++++--
.../platform/mtk-vcodec/mtk_vcodec_dec.c | 5 ++
drivers/media/platform/qcom/venus/core.h | 2 +-
.../media/platform/qcom/venus/hfi_helper.h | 12 ++---
.../media/platform/qcom/venus/vdec_ctrls.c | 10 ++--
drivers/media/platform/qcom/venus/venc.c | 14 ++---
.../media/platform/qcom/venus/venc_ctrls.c | 12 +++--
drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 15 +++---
drivers/media/v4l2-core/v4l2-ctrls.c | 23 +++++++-
include/uapi/linux/v4l2-controls.h | 18 ++++++-
10 files changed, 127 insertions(+), 36 deletions(-)
--
2.18.0.rc1.242.g61856ae69a-goog
^ permalink raw reply
* [RESEND PATCH] media: helene: fix tuning frequency of satellite
From: Katsuhiro Suzuki @ 2018-06-14 7:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529010640.18604-1-suzuki.katsuhiro@socionext.com>
Hello all,
This patch is wrong, I got a mistake.
DTV_FREQUENCY for satellite delivery systems, the frequency is in 'kHz' not 'Hz',
so original code is correct.
Please forget this patch. Sorry for confusing...
Regards,
--
Katsuhiro Suzuki
> -----Original Message-----
> From: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
> Sent: Tuesday, May 29, 2018 10:07 AM
> To: Abylay Ospan <aospan@netup.ru>; Mauro Carvalho Chehab
> <mchehab+samsung@kernel.org>; linux-media at vger.kernel.org
> Cc: Masami Hiramatsu <masami.hiramatsu@linaro.org>; Jassi Brar
> <jaswinder.singh@linaro.org>; linux-arm-kernel at lists.infradead.org;
> linux-kernel at vger.kernel.org; Suzuki, Katsuhiro/?? ??
> <suzuki.katsuhiro@socionext.com>
> Subject: [RESEND PATCH] media: helene: fix tuning frequency of satellite
>
> This patch fixes tuning frequency of satellite to kHz. That as same
> as terrestrial one.
>
> Signed-off-by: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
> ---
> drivers/media/dvb-frontends/helene.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/dvb-frontends/helene.c
> b/drivers/media/dvb-frontends/helene.c
> index 04033f0c278b..0a4f312c4368 100644
> --- a/drivers/media/dvb-frontends/helene.c
> +++ b/drivers/media/dvb-frontends/helene.c
> @@ -523,7 +523,7 @@ static int helene_set_params_s(struct dvb_frontend *fe)
> enum helene_tv_system_t tv_system;
> struct dtv_frontend_properties *p = &fe->dtv_property_cache;
> struct helene_priv *priv = fe->tuner_priv;
> - int frequencykHz = p->frequency;
> + int frequencykHz = p->frequency / 1000;
> uint32_t frequency4kHz = 0;
> u32 symbol_rate = p->symbol_rate/1000;
>
> --
> 2.17.0
^ permalink raw reply
* [PATCH] Revert "drm/sun4i: Handle DRM_BUS_FLAG_PIXDATA_*EDGE"
From: Paul Kocialkowski @ 2018-06-14 7:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d5357ae3-9dc1-b0ac-47bf-8742d55c4f3b@micronovasrl.com>
Hi,
On Wed, 2018-06-13 at 23:52 +0200, Giulio Benetti wrote:
> Hello,
>
> sorry for my ignorance.
> I don't know the right patch workflow in the case of "revert commit".
> When I fix this bug, should I have to re-submit the previous patch
> entire plus bug-fix?
>
> Or do I have to submit patch with bug-fix only?
Yes, that is usually how it works! The revert patch will be picked up by
the maintainer (Maxime), integrated in his tree and eventually merged
into Linus' tree (along with stable trees).
Fixup patches for this will need to take into account the revert patch,
so it becomes equivalent to submitting the same patch with that issue
resolved.
> Thanks in advance to everybody
Cheers !
--
Paul Kocialkowski, Bootlin (formerly Free Electrons)
Embedded Linux and kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180614/539bddbd/attachment.sig>
^ 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