* [PATCH] arm64: dma-mapping: clear buffers allocated with FORCE_CONTIGUOUS flag
From: Marek Szyprowski @ 2018-06-11 5:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CGME20180611051352eucas1p1f256a2a303da85a1e0923f012d709e39@eucas1p1.samsung.com>
dma_alloc_*() buffers might be exposed to userspace via mmap() call, so
they should be cleared on allocation. In case of IOMMU-based dma-mapping
implementation such buffer clearing was missing in the code path for
DMA_ATTR_FORCE_CONTIGUOUS flag handling. This patch fixes this issue. For
more information on clearing buffers allocated by dma_alloc_* functions,
see commit 44176bb38fa4 ("arm64: dma-mapping: always clear allocated
buffers").
Fixes: 44176bb38fa4 ("arm64: Add support for DMA_ATTR_FORCE_CONTIGUOUS to IOMMU")
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
arch/arm64/mm/dma-mapping.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 632d32109755..aa0037a3185f 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -629,13 +629,14 @@ static void *__iommu_alloc_attrs(struct device *dev, size_t size,
size >> PAGE_SHIFT);
return NULL;
}
- if (!coherent)
- __dma_flush_area(page_to_virt(page), iosize);
-
addr = dma_common_contiguous_remap(page, size, VM_USERMAP,
prot,
__builtin_return_address(0));
- if (!addr) {
+ if (addr) {
+ memset(addr, 0, size);
+ if (!coherent)
+ __dma_flush_area(page_to_virt(page), iosize);
+ } else {
iommu_dma_unmap_page(dev, *handle, iosize, 0, attrs);
dma_release_from_contiguous(dev, page,
size >> PAGE_SHIFT);
--
2.17.1
^ permalink raw reply related
* [PATCH v2] ARM: DTS: imx53: Add support for imx53 HSC/DDC boards from K+P
From: Shawn Guo @ 2018-06-11 5:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180519121506.32344-1-lukma@denx.de>
On Sat, May 19, 2018 at 02:15:06PM +0200, Lukasz Majewski wrote:
> This commit provides support for HSC and DDC boards from
> Kieback&Peter GmbH vendor.
>
> Signed-off-by: Lukasz Majewski <lukma@denx.de>
> ---
> Changes for v2:
>
> - Remove not needed #address-cells and #size-cells in
> the gpio_buttons node to pass make W=1
> - Rename button@{12} to button_{kalt|pwr} nodes to pass make W=1
> - Include #include <dt-bindings/input/input.h> to use KEY_F6|F7 directly
>
> ---
> arch/arm/boot/dts/Makefile | 2 +
> arch/arm/boot/dts/imx53-kp-ddc.dts | 146 ++++++++++++++++++++++++++++
> arch/arm/boot/dts/imx53-kp-hsc.dts | 51 ++++++++++
> arch/arm/boot/dts/imx53-kp.dtsi | 190 +++++++++++++++++++++++++++++++++++++
> 4 files changed, 389 insertions(+)
> create mode 100644 arch/arm/boot/dts/imx53-kp-ddc.dts
> create mode 100644 arch/arm/boot/dts/imx53-kp-hsc.dts
> create mode 100644 arch/arm/boot/dts/imx53-kp.dtsi
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index fbc04b0db781..00854a5b6ac4 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -360,6 +360,8 @@ dtb-$(CONFIG_SOC_IMX51) += \
> dtb-$(CONFIG_SOC_IMX53) += \
> imx53-ard.dtb \
> imx53-cx9020.dtb \
> + imx53-kp-ddc.dtb \
> + imx53-kp-hsc.dtb \
> imx53-m53evk.dtb \
> imx53-mba53.dtb \
> imx53-ppd.dtb \
> diff --git a/arch/arm/boot/dts/imx53-kp-ddc.dts b/arch/arm/boot/dts/imx53-kp-ddc.dts
> new file mode 100644
> index 000000000000..acaf477a52c5
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx53-kp-ddc.dts
> @@ -0,0 +1,146 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright 2018
> + * Lukasz Majewski, DENX Software Engineering, lukma at denx.de
> + */
> +
> +/dts-v1/;
> +#include "imx53-kp.dtsi"
> +
> +/ {
> + model = "K+P imx53 DDC";
> + compatible = "kiebackpeter,imx53-ddc", "fsl,imx53";
> +
> + backlight_lcd: backlight {
> + compatible = "pwm-backlight";
> + pwms = <&pwm2 0 50000>;
> + power-supply = <®_backlight>;
> + brightness-levels = <0 24 28 32 36
> + 40 44 48 52 56
> + 60 64 68 72 76
> + 80 84 88 92 96 100>;
> + default-brightness-level = <20>;
> + };
> +
> + lcd_display: disp1 {
display for node node.
> + compatible = "fsl,imx-parallel-display";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interface-pix-fmt = "rgb24";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_disp>;
> +
> + port at 0 {
> + reg = <0>;
> +
> + display1_in: endpoint {
> + remote-endpoint = <&ipu_di1_disp1>;
> + };
> + };
> +
> + port at 1 {
> + reg = <1>;
> +
> + lcd_display_out: endpoint {
> + remote-endpoint = <&lcd_panel_in>;
> + };
> + };
> + };
> +
> + lcd_panel: lcd-panel {
> + compatible = "koe,tx14d24vm1bpa";
Undefined compatible?
> + backlight = <&backlight_lcd>;
> + power-supply = <®_3v3>;
> +
> + port {
> + lcd_panel_in: endpoint {
> + remote-endpoint = <&lcd_display_out>;
> + };
> + };
> + };
> +
> + reg_backlight: regulator-backlight {
> + compatible = "regulator-fixed";
> + regulator-name = "backlight-supply";
> + regulator-min-microvolt = <15000000>;
> + regulator-max-microvolt = <15000000>;
> + regulator-always-on;
> + };
> +};
> +
> +&i2c3 {
> + adc at 48 {
> + compatible = "ti,ads1015";
> + reg = <0x48>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + channel at 4 {
> + reg = <4>;
> + ti,gain = <2>;
> + ti,datarate = <4>;
> + };
> +
> + channel at 6 {
> + reg = <6>;
> + ti,gain = <2>;
> + ti,datarate = <4>;
> + };
> + };
> +
> + gpio_expander2 at 21 {
Use hyphen instead of underscore in node name.
> + compatible = "nxp,pcf8574";
> + reg = <0x21>;
> + interrupts = <109>;
> + #gpio-cells = <2>;
> + gpio-controller;
> + };
> +};
> +
> +&iomuxc {
> + imx53-kp-ddc {
> + pinctrl_disp: dispgrp {
> + fsl,pins = <
> + MX53_PAD_EIM_A16__IPU_DI1_DISP_CLK 0x4
> + MX53_PAD_EIM_DA10__IPU_DI1_PIN15 0x4
> + MX53_PAD_EIM_DA9__IPU_DISP1_DAT_0 0x4
> + MX53_PAD_EIM_DA8__IPU_DISP1_DAT_1 0x4
> + MX53_PAD_EIM_DA7__IPU_DISP1_DAT_2 0x4
> + MX53_PAD_EIM_DA6__IPU_DISP1_DAT_3 0x4
> + MX53_PAD_EIM_DA5__IPU_DISP1_DAT_4 0x4
> + MX53_PAD_EIM_DA4__IPU_DISP1_DAT_5 0x4
> + MX53_PAD_EIM_DA3__IPU_DISP1_DAT_6 0x4
> + MX53_PAD_EIM_DA2__IPU_DISP1_DAT_7 0x4
> + MX53_PAD_EIM_DA1__IPU_DISP1_DAT_8 0x4
> + MX53_PAD_EIM_DA0__IPU_DISP1_DAT_9 0x4
> + MX53_PAD_EIM_EB1__IPU_DISP1_DAT_10 0x4
> + MX53_PAD_EIM_EB0__IPU_DISP1_DAT_11 0x4
> + MX53_PAD_EIM_A17__IPU_DISP1_DAT_12 0x4
> + MX53_PAD_EIM_A18__IPU_DISP1_DAT_13 0x4
> + MX53_PAD_EIM_A19__IPU_DISP1_DAT_14 0x4
> + MX53_PAD_EIM_A20__IPU_DISP1_DAT_15 0x4
> + MX53_PAD_EIM_A21__IPU_DISP1_DAT_16 0x4
> + MX53_PAD_EIM_A22__IPU_DISP1_DAT_17 0x4
> + MX53_PAD_EIM_A23__IPU_DISP1_DAT_18 0x4
> + MX53_PAD_EIM_A24__IPU_DISP1_DAT_19 0x4
> + MX53_PAD_EIM_D31__IPU_DISP1_DAT_20 0x4
> + MX53_PAD_EIM_D30__IPU_DISP1_DAT_21 0x4
> + MX53_PAD_EIM_D26__IPU_DISP1_DAT_22 0x4
> + MX53_PAD_EIM_D27__IPU_DISP1_DAT_23 0x4
> + MX53_PAD_GPIO_1__PWM2_PWMO 0x4
> + >;
> + };
> + };
> +};
> +
> +&ipu_di1_disp1 {
> + remote-endpoint = <&display1_in>;
> +};
> +
> +&fec {
> + status = "okay";
> +};
Sort the labeled nodes alphabetically in label name.
> +
> +&pmic {
> + fsl,mc13xxx-uses-touch;
> +};
> diff --git a/arch/arm/boot/dts/imx53-kp-hsc.dts b/arch/arm/boot/dts/imx53-kp-hsc.dts
> new file mode 100644
> index 000000000000..d68cdd5da819
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx53-kp-hsc.dts
> @@ -0,0 +1,51 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright 2018
> + * Lukasz Majewski, DENX Software Engineering, lukma at denx.de
> + */
> +
> +/dts-v1/;
> +#include "imx53-kp.dtsi"
> +
> +/ {
> + model = "K+P imx53 HSC";
> + compatible = "kiebackpeter,imx53-hsc", "fsl,imx53";
> +};
> +
> +&fec {
> + status = "okay";
Have a newline between property list and child node.
> + fixed-link { /* RMII fixed link to LAN9303 */
> + speed = <100>;
> + full-duplex;
> + };
> +};
> +
> +&i2c3 {
> + switch: switch at a {
> + compatible = "smsc,lan9303-i2c";
> + reg = <0xa>;
> + reset-gpios = <&gpio7 6 GPIO_ACTIVE_LOW>;
> + reset-duration = <400>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port at 0 { /* RMII fixed link to master */
> + reg = <0>;
> + label = "cpu";
> + ethernet = <&fec>;
> + };
> +
> + port at 1 { /* external port 1 */
> + reg = <1>;
> + label = "lan1";
> + };
> +
> + port at 2 { /* external port 2 */
> + reg = <2>;
> + label = "lan2";
> + };
> + };
> + };
> +};
> diff --git a/arch/arm/boot/dts/imx53-kp.dtsi b/arch/arm/boot/dts/imx53-kp.dtsi
> new file mode 100644
> index 000000000000..f87266843842
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx53-kp.dtsi
> @@ -0,0 +1,190 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright 2018
> + * Lukasz Majewski, DENX Software Engineering, lukma at denx.de
> + */
> +
> +/dts-v1/;
> +#include "imx53-tqma53.dtsi"
> +#include <dt-bindings/input/input.h>
> +
> +/ {
> + buzzer {
> + compatible = "pwm-beeper";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_buzzer>;
> +
Drop this newline.
> + pwms = <&pwm1 0 500000>;
> + };
> +
> + gpio_buttons {
Use hyphen.
> + compatible = "gpio-keys";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_gpiobuttons>;
> +
> + button_kalt {
Ditto
> + label = "Kaltstart";
> + linux,code = <KEY_F6>;
> + gpios = <&gpio2 26 GPIO_ACTIVE_HIGH>;
> + };
> +
> + button_pwr {
Ditto
> + label = "PowerFailInterrupt";
> + linux,code = <KEY_F7>;
> + gpios = <&gpio3 22 GPIO_ACTIVE_HIGH>;
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_leds>;
> +
> + led_bus {
Ditto
> + label = "bus";
> + gpios = <&gpio2 30 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "gpio";
> + default-state = "off";
> + };
> +
> + led_error {
Ditto
> + label = "error";
> + gpios = <&gpio3 28 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "gpio";
> + default-state = "off";
> + };
> +
> + led_flash {
Ditto
> + label = "flash";
> + gpios = <&gpio5 0 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "heartbeat";
> + };
> + };
> +
> + reg_3v3: regulator-3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "3V3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-always-on;
> + };
> +};
> +
> +&can1 {
> + status = "okay";
> +};
> +
> +&can2 {
> + status = "okay";
> +};
> +
> +&i2c3 {
> + status = "okay";
> +
> + gpio_expander1 at 22 {
Ditto
Shawn
> + compatible = "nxp,pcf8574";
> + reg = <0x22>;
> + interrupts = <109>;
> + #gpio-cells = <2>;
> + gpio-controller;
> + };
> +
> + rtc at 51 {
> + compatible = "nxp,pcf8563";
> + reg = <0x51>;
> + };
> +};
> +
> +&iomuxc {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_kp_common>;
> +
> + imx53-kp-common {
> + pinctrl_buzzer: buzzergrp {
> + fsl,pins = <
> + MX53_PAD_SD1_DATA3__PWM1_PWMO 0x1e4
> + >;
> + };
> +
> + pinctrl_gpiobuttons: gpiobuttonsgrp {
> + fsl,pins = <
> + MX53_PAD_EIM_RW__GPIO2_26 0x1e4
> + MX53_PAD_EIM_D22__GPIO3_22 0x1e4
> + >;
> + };
> +
> + pinctrl_kp_common: kpcommongrp {
> + fsl,pins = <
> + MX53_PAD_EIM_CS0__GPIO2_23 0x1e4
> + MX53_PAD_GPIO_19__GPIO4_5 0x1e4
> + MX53_PAD_PATA_DATA6__GPIO2_6 0x1e4
> + MX53_PAD_PATA_DATA7__GPIO2_7 0xe0
> + MX53_PAD_CSI0_DAT14__GPIO6_0 0x1e4
> + MX53_PAD_CSI0_DAT16__GPIO6_2 0x1e4
> + MX53_PAD_CSI0_DAT18__GPIO6_4 0x1e4
> + MX53_PAD_EIM_D17__GPIO3_17 0x1e4
> + MX53_PAD_EIM_D18__GPIO3_18 0x1e4
> + MX53_PAD_EIM_D21__GPIO3_21 0x1e4
> + MX53_PAD_EIM_D29__GPIO3_29 0x1e4
> + MX53_PAD_EIM_DA11__GPIO3_11 0x1e4
> + MX53_PAD_EIM_DA13__GPIO3_13 0x1e4
> + MX53_PAD_EIM_DA14__GPIO3_14 0x1e4
> + MX53_PAD_SD1_DATA0__GPIO1_16 0x1e4
> + MX53_PAD_SD1_CMD__GPIO1_18 0x1e4
> + MX53_PAD_SD1_CLK__GPIO1_20 0x1e4
> + >;
> + };
> +
> + pinctrl_leds: ledgrp {
> + fsl,pins = <
> + MX53_PAD_EIM_EB2__GPIO2_30 0x1d4
> + MX53_PAD_EIM_D28__GPIO3_28 0x1d4
> + MX53_PAD_EIM_WAIT__GPIO5_0 0x1d4
> + >;
> + };
> +
> + pinctrl_uart4: uart4grp {
> + fsl,pins = <
> + MX53_PAD_CSI0_DAT12__UART4_TXD_MUX 0x1e4
> + MX53_PAD_CSI0_DAT13__UART4_RXD_MUX 0x1e4
> + >;
> + };
> + };
> +};
> +
> +&pinctrl_uart1 {
> + fsl,pins = <
> + MX53_PAD_EIM_D23__GPIO3_23 0x1e4
> + MX53_PAD_EIM_EB3__GPIO2_31 0x1e4
> + MX53_PAD_EIM_D24__GPIO3_24 0x1e4
> + MX53_PAD_EIM_D25__GPIO3_25 0x1e4
> + MX53_PAD_EIM_D19__GPIO3_19 0x1e4
> + MX53_PAD_EIM_D20__GPIO3_20 0x1e4
> + >;
> +};
> +
> +&uart1 {
> + status = "okay";
> +};
> +
> +&uart2 {
> + status = "okay";
> +};
> +
> +&uart3 {
> + status = "okay";
> +};
> +
> +&uart4 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_uart4>;
> + status = "okay";
> +};
> +
> +&usbh1 {
> + status = "okay";
> +};
> +
> +&usbphy0 {
> + status = "disabled";
> +};
> --
> 2.11.0
>
^ permalink raw reply
* [PATCH v2 1/3] ASoC: simple-card-utils: move hp and mic detect gpios from simple-card
From: Katsuhiro Suzuki @ 2018-06-11 5:15 UTC (permalink / raw)
To: linux-arm-kernel
This patch moves headphone and microphone jack detection gpios from
simple-card driver. It is preparing for using this feature from other
drivers.
Signed-off-by: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
---
Changes from v1:
- Move changes of audio-graph-card to other patch
---
include/sound/simple_card_utils.h | 15 +++++++
sound/soc/generic/simple-card-utils.c | 59 ++++++++++++++++++++++++
sound/soc/generic/simple-card.c | 64 ---------------------------
3 files changed, 74 insertions(+), 64 deletions(-)
diff --git a/include/sound/simple_card_utils.h b/include/sound/simple_card_utils.h
index 7e25afce6566..f82acef3b992 100644
--- a/include/sound/simple_card_utils.h
+++ b/include/sound/simple_card_utils.h
@@ -12,6 +12,11 @@
#include <sound/soc.h>
+#define asoc_simple_card_init_hp(card, sjack, prefix) \
+ asoc_simple_card_init_jack(card, sjack, 1, prefix)
+#define asoc_simple_card_init_mic(card, sjack, prefix) \
+ asoc_simple_card_init_jack(card, sjack, 0, prefix)
+
struct asoc_simple_dai {
const char *name;
unsigned int sysclk;
@@ -28,6 +33,12 @@ struct asoc_simple_card_data {
u32 convert_channels;
};
+struct asoc_simple_jack {
+ struct snd_soc_jack jack;
+ struct snd_soc_jack_pin pin;
+ struct snd_soc_jack_gpio gpio;
+};
+
int asoc_simple_card_parse_daifmt(struct device *dev,
struct device_node *node,
struct device_node *codec,
@@ -107,4 +118,8 @@ int asoc_simple_card_of_parse_routing(struct snd_soc_card *card,
int asoc_simple_card_of_parse_widgets(struct snd_soc_card *card,
char *prefix);
+int asoc_simple_card_init_jack(struct snd_soc_card *card,
+ struct asoc_simple_jack *sjack,
+ int is_hp, char *prefix);
+
#endif /* __SIMPLE_CARD_UTILS_H */
diff --git a/sound/soc/generic/simple-card-utils.c b/sound/soc/generic/simple-card-utils.c
index 3751a07de6aa..4398c9580929 100644
--- a/sound/soc/generic/simple-card-utils.c
+++ b/sound/soc/generic/simple-card-utils.c
@@ -8,9 +8,13 @@
* published by the Free Software Foundation.
*/
#include <linux/clk.h>
+#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
#include <linux/module.h>
#include <linux/of.h>
+#include <linux/of_gpio.h>
#include <linux/of_graph.h>
+#include <sound/jack.h>
#include <sound/simple_card_utils.h>
void asoc_simple_card_convert_fixup(struct asoc_simple_card_data *data,
@@ -419,6 +423,61 @@ int asoc_simple_card_of_parse_widgets(struct snd_soc_card *card,
}
EXPORT_SYMBOL_GPL(asoc_simple_card_of_parse_widgets);
+int asoc_simple_card_init_jack(struct snd_soc_card *card,
+ struct asoc_simple_jack *sjack,
+ int is_hp, char *prefix)
+{
+ struct device *dev = card->dev;
+ enum of_gpio_flags flags;
+ char prop[128];
+ char *pin_name;
+ char *gpio_name;
+ int mask;
+ int det;
+
+ if (!prefix)
+ prefix = "";
+
+ sjack->gpio.gpio = -ENOENT;
+
+ if (is_hp) {
+ snprintf(prop, sizeof(prop), "%shp-det-gpio", prefix);
+ pin_name = "Headphones";
+ gpio_name = "Headphone detection";
+ mask = SND_JACK_HEADPHONE;
+ } else {
+ snprintf(prop, sizeof(prop), "%smic-det-gpio", prefix);
+ pin_name = "Mic Jack";
+ gpio_name = "Mic detection";
+ mask = SND_JACK_MICROPHONE;
+ }
+
+ det = of_get_named_gpio_flags(dev->of_node, prop, 0, &flags);
+ if (det == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+
+ if (gpio_is_valid(det)) {
+ sjack->pin.pin = pin_name;
+ sjack->pin.mask = mask;
+
+ sjack->gpio.name = gpio_name;
+ sjack->gpio.report = mask;
+ sjack->gpio.gpio = det;
+ sjack->gpio.invert = !!(flags & OF_GPIO_ACTIVE_LOW);
+ sjack->gpio.debounce_time = 150;
+
+ snd_soc_card_jack_new(card, pin_name, mask,
+ &sjack->jack,
+ &sjack->pin, 1);
+
+ snd_soc_jack_add_gpios(&sjack->jack, 1,
+ &sjack->gpio);
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(asoc_simple_card_init_jack);
+
/* Module information */
MODULE_AUTHOR("Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>");
MODULE_DESCRIPTION("ALSA SoC Simple Card Utils");
diff --git a/sound/soc/generic/simple-card.c b/sound/soc/generic/simple-card.c
index 4a516c428b3d..1bbd9e46bf2a 100644
--- a/sound/soc/generic/simple-card.c
+++ b/sound/soc/generic/simple-card.c
@@ -10,23 +10,14 @@
*/
#include <linux/clk.h>
#include <linux/device.h>
-#include <linux/gpio.h>
#include <linux/module.h>
#include <linux/of.h>
-#include <linux/of_gpio.h>
#include <linux/platform_device.h>
#include <linux/string.h>
-#include <sound/jack.h>
#include <sound/simple_card.h>
#include <sound/soc-dai.h>
#include <sound/soc.h>
-struct asoc_simple_jack {
- struct snd_soc_jack jack;
- struct snd_soc_jack_pin pin;
- struct snd_soc_jack_gpio gpio;
-};
-
struct simple_card_data {
struct snd_soc_card snd_card;
struct simple_dai_props {
@@ -49,61 +40,6 @@ struct simple_card_data {
#define CELL "#sound-dai-cells"
#define PREFIX "simple-audio-card,"
-#define asoc_simple_card_init_hp(card, sjack, prefix)\
- asoc_simple_card_init_jack(card, sjack, 1, prefix)
-#define asoc_simple_card_init_mic(card, sjack, prefix)\
- asoc_simple_card_init_jack(card, sjack, 0, prefix)
-static int asoc_simple_card_init_jack(struct snd_soc_card *card,
- struct asoc_simple_jack *sjack,
- int is_hp, char *prefix)
-{
- struct device *dev = card->dev;
- enum of_gpio_flags flags;
- char prop[128];
- char *pin_name;
- char *gpio_name;
- int mask;
- int det;
-
- sjack->gpio.gpio = -ENOENT;
-
- if (is_hp) {
- snprintf(prop, sizeof(prop), "%shp-det-gpio", prefix);
- pin_name = "Headphones";
- gpio_name = "Headphone detection";
- mask = SND_JACK_HEADPHONE;
- } else {
- snprintf(prop, sizeof(prop), "%smic-det-gpio", prefix);
- pin_name = "Mic Jack";
- gpio_name = "Mic detection";
- mask = SND_JACK_MICROPHONE;
- }
-
- det = of_get_named_gpio_flags(dev->of_node, prop, 0, &flags);
- if (det == -EPROBE_DEFER)
- return -EPROBE_DEFER;
-
- if (gpio_is_valid(det)) {
- sjack->pin.pin = pin_name;
- sjack->pin.mask = mask;
-
- sjack->gpio.name = gpio_name;
- sjack->gpio.report = mask;
- sjack->gpio.gpio = det;
- sjack->gpio.invert = !!(flags & OF_GPIO_ACTIVE_LOW);
- sjack->gpio.debounce_time = 150;
-
- snd_soc_card_jack_new(card, pin_name, mask,
- &sjack->jack,
- &sjack->pin, 1);
-
- snd_soc_jack_add_gpios(&sjack->jack, 1,
- &sjack->gpio);
- }
-
- return 0;
-}
-
static int asoc_simple_card_startup(struct snd_pcm_substream *substream)
{
struct snd_soc_pcm_runtime *rtd = substream->private_data;
--
2.17.1
^ permalink raw reply related
* [PATCH v2 2/3] ASoC: simple-card: move hp and mic detection to soc_card probe
From: Katsuhiro Suzuki @ 2018-06-11 5:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180611051559.18082-1-suzuki.katsuhiro@socionext.com>
This patch moves headphone and microphone detection to probe() of
snd_soc_card from init() of snd_soc_dai_link. This is because init()
is called (and an input device /dev/input/eventX is created too)
twice or above if simple card has two or more DAI links.
Signed-off-by: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
---
Changes from v1:
- Newly added
---
sound/soc/generic/simple-card.c | 25 +++++++++++++++++--------
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/sound/soc/generic/simple-card.c b/sound/soc/generic/simple-card.c
index 1bbd9e46bf2a..9eb26ee06892 100644
--- a/sound/soc/generic/simple-card.c
+++ b/sound/soc/generic/simple-card.c
@@ -149,14 +149,6 @@ static int asoc_simple_card_dai_init(struct snd_soc_pcm_runtime *rtd)
if (ret < 0)
return ret;
- ret = asoc_simple_card_init_hp(rtd->card, &priv->hp_jack, PREFIX);
- if (ret < 0)
- return ret;
-
- ret = asoc_simple_card_init_mic(rtd->card, &priv->mic_jack, PREFIX);
- if (ret < 0)
- return ret;
-
return 0;
}
@@ -350,6 +342,22 @@ static int asoc_simple_card_parse_of(struct simple_card_data *priv)
return ret;
}
+static int asoc_simple_soc_card_probe(struct snd_soc_card *card)
+{
+ struct simple_card_data *priv = snd_soc_card_get_drvdata(card);
+ int ret;
+
+ ret = asoc_simple_card_init_hp(card, &priv->hp_jack, NULL);
+ if (ret < 0)
+ return ret;
+
+ ret = asoc_simple_card_init_mic(card, &priv->mic_jack, NULL);
+ if (ret < 0)
+ return ret;
+
+ return 0;
+}
+
static int asoc_simple_card_probe(struct platform_device *pdev)
{
struct simple_card_data *priv;
@@ -385,6 +393,7 @@ static int asoc_simple_card_probe(struct platform_device *pdev)
card->dev = dev;
card->dai_link = priv->dai_link;
card->num_links = num;
+ card->probe = asoc_simple_soc_card_probe;
if (np && of_device_is_available(np)) {
--
2.17.1
^ permalink raw reply related
* [PATCH v2 3/3] ASoC: audio-graph-card: add hp and mic detect gpios same as simple-card
From: Katsuhiro Suzuki @ 2018-06-11 5:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180611051559.18082-1-suzuki.katsuhiro@socionext.com>
This patch adds headphone and microphone jack detection gpios as same
as simple-card driver.
Signed-off-by: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
---
Changes from v1:
- Move changes of audio-graph-card to other patch
---
sound/soc/generic/audio-graph-card.c | 20 +++++++++++++++++++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/sound/soc/generic/audio-graph-card.c b/sound/soc/generic/audio-graph-card.c
index 1b6164249341..2baa60d3b3cc 100644
--- a/sound/soc/generic/audio-graph-card.c
+++ b/sound/soc/generic/audio-graph-card.c
@@ -21,7 +21,6 @@
#include <linux/of_graph.h>
#include <linux/platform_device.h>
#include <linux/string.h>
-#include <sound/jack.h>
#include <sound/simple_card_utils.h>
struct graph_card_data {
@@ -32,6 +31,8 @@ struct graph_card_data {
unsigned int mclk_fs;
} *dai_props;
unsigned int mclk_fs;
+ struct asoc_simple_jack hp_jack;
+ struct asoc_simple_jack mic_jack;
struct snd_soc_dai_link *dai_link;
struct gpio_desc *pa_gpio;
};
@@ -278,6 +279,22 @@ static int asoc_graph_get_dais_count(struct device *dev)
return count;
}
+static int asoc_graph_soc_card_probe(struct snd_soc_card *card)
+{
+ struct graph_card_data *priv = snd_soc_card_get_drvdata(card);
+ int ret;
+
+ ret = asoc_simple_card_init_hp(card, &priv->hp_jack, NULL);
+ if (ret < 0)
+ return ret;
+
+ ret = asoc_simple_card_init_mic(card, &priv->mic_jack, NULL);
+ if (ret < 0)
+ return ret;
+
+ return 0;
+}
+
static int asoc_graph_card_probe(struct platform_device *pdev)
{
struct graph_card_data *priv;
@@ -319,6 +336,7 @@ static int asoc_graph_card_probe(struct platform_device *pdev)
card->num_links = num;
card->dapm_widgets = asoc_graph_card_dapm_widgets;
card->num_dapm_widgets = ARRAY_SIZE(asoc_graph_card_dapm_widgets);
+ card->probe = asoc_graph_soc_card_probe;
ret = asoc_graph_card_parse_of(priv);
if (ret < 0) {
--
2.17.1
^ permalink raw reply related
* [PATCH] ARM: dts: imx51-zii-rdu1: add rave-sp subdevices
From: Shawn Guo @ 2018-06-11 5:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180517191923.16212-1-nikita.yoush@cogentembedded.com>
On Thu, May 17, 2018 at 10:19:23PM +0300, Nikita Yushchenko wrote:
> This adds rave-sp powerbutton and backlight devices to RDU1 device tree.
>
> Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
> ---
> arch/arm/boot/dts/imx51-zii-rdu1.dts | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx51-zii-rdu1.dts b/arch/arm/boot/dts/imx51-zii-rdu1.dts
> index 0c99ac04ad08..98cc107098e0 100644
> --- a/arch/arm/boot/dts/imx51-zii-rdu1.dts
> +++ b/arch/arm/boot/dts/imx51-zii-rdu1.dts
> @@ -581,6 +581,14 @@
> watchdog {
> compatible = "zii,rave-sp-watchdog";
> };
> +
> + backlight {
> + compatible = "zii,rave-sp-backlight";
> + };
> +
> + pwrbutton {
> + compatible = "zii,rave-sp-pwrbutton";
> + };
Where are these compatibles documented?
Shawn
> };
> };
>
> --
> 2.11.0
>
^ permalink raw reply
* [PATCH v2 2/3] ASoC: simple-card: move hp and mic detection to soc_card probe
From: Kuninori Morimoto @ 2018-06-11 5:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180611051559.18082-2-suzuki.katsuhiro@socionext.com>
Hi Katsuhiro-san
> This patch moves headphone and microphone detection to probe() of
> snd_soc_card from init() of snd_soc_dai_link. This is because init()
> is called (and an input device /dev/input/eventX is created too)
> twice or above if simple card has two or more DAI links.
>
> Signed-off-by: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
or above ?
> - ret = asoc_simple_card_init_hp(rtd->card, &priv->hp_jack, PREFIX);
> - if (ret < 0)
> - return ret;
> -
> - ret = asoc_simple_card_init_mic(rtd->card, &priv->mic_jack, PREFIX);
> - if (ret < 0)
> - return ret;
(snip)
> + ret = asoc_simple_card_init_hp(card, &priv->hp_jack, NULL);
> + if (ret < 0)
> + return ret;
> +
> + ret = asoc_simple_card_init_mic(card, &priv->mic_jack, NULL);
> + if (ret < 0)
> + return ret;
I think we want to keep "PREFIX" ?
Best regards
---
Kuninori Morimoto
^ permalink raw reply
* [PATCH v3 1/3] cpufreq: imx6q: check speed grades for i.MX6ULL
From: Shawn Guo @ 2018-06-11 5:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180522062853.24799-1-sebastien.szymanski@armadeus.com>
On Tue, May 22, 2018 at 08:28:51AM +0200, S?bastien Szymanski wrote:
> Check the max speed supported from the fuses for i.MX6ULL and update the
> operating points table accordingly.
>
> Signed-off-by: S?bastien Szymanski <sebastien.szymanski@armadeus.com>
Acked-by: Shawn Guo <shawnguo@kernel.org>
^ permalink raw reply
* [PATCH v2 2/3] ASoC: simple-card: move hp and mic detection to soc_card probe
From: Katsuhiro Suzuki @ 2018-06-11 5:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87tvq96gnm.wl-kuninori.morimoto.gx@renesas.com>
Hello Morimoto-san,
> -----Original Message-----
> From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> Sent: Monday, June 11, 2018 2:27 PM
> To: Suzuki, Katsuhiro <suzuki.katsuhiro@socionext.com>
> Cc: Mark Brown <broonie@kernel.org>; alsa-devel at alsa-project.org; 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
> Subject: Re: [PATCH v2 2/3] ASoC: simple-card: move hp and mic detection to
soc_card
> probe
>
>
> Hi Katsuhiro-san
>
> > This patch moves headphone and microphone detection to probe() of
> > snd_soc_card from init() of snd_soc_dai_link. This is because init()
> > is called (and an input device /dev/input/eventX is created too)
> > twice or above if simple card has two or more DAI links.
> >
> > Signed-off-by: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
>
> or above ?
>
It seems if simple card has multiple DAI links, it creates multiple input
devices.
For example simple card has 3-links, 3 input devices /dev/input/event0,
event1, event2 are created. Is it correct?
> > - ret = asoc_simple_card_init_hp(rtd->card, &priv->hp_jack, PREFIX);
> > - if (ret < 0)
> > - return ret;
> > -
> > - ret = asoc_simple_card_init_mic(rtd->card, &priv->mic_jack, PREFIX);
> > - if (ret < 0)
> > - return ret;
> (snip)
> > + ret = asoc_simple_card_init_hp(card, &priv->hp_jack, NULL);
> > + if (ret < 0)
> > + return ret;
> > +
> > + ret = asoc_simple_card_init_mic(card, &priv->mic_jack, NULL);
> > + if (ret < 0)
> > + return ret;
>
> I think we want to keep "PREFIX" ?
>
Oops... Thank you. I'll fix it.
Regards,
--
Katsuhiro Suzuki
>
> Best regards
> ---
> Kuninori Morimoto
^ permalink raw reply
* [PATCH] arm: Initialize hrtimer-based broadcast clockevent
From: Jan Kiszka @ 2018-06-11 5:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <35966a15-8312-5ba9-ef76-33a6cfda1f32@siemens.com>
On 2018-04-04 17:54, Jan Kiszka wrote:
> On 2018-03-01 07:04, Jan Kiszka wrote:
>> On 2018-01-22 07:06, Jan Kiszka wrote:
>>> Analogously to 9358d755bd5c, this registers a broadcast clockevent in
>>> case no hardware broadcast timer is available and the per-CPU timers can
>>> be stopped in deep power states.
>>>
>>> Partitions of the Jailhouse hypervisor fall in this category.
>>> Registering the workaround timer allows to enter high-resolution mode in
>>> that case.
>>>
>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>>> ---
>>> arch/arm/kernel/time.c | 3 +++
>>> 1 file changed, 3 insertions(+)
>>>
>>> diff --git a/arch/arm/kernel/time.c b/arch/arm/kernel/time.c
>>> index 629f8e9981f1..0a45d861ef8e 100644
>>> --- a/arch/arm/kernel/time.c
>>> +++ b/arch/arm/kernel/time.c
>>> @@ -12,6 +12,7 @@
>>> * reading the RTC at bootup, etc...
>>> */
>>> #include <linux/clk-provider.h>
>>> +#include <linux/clockchips.h>
>>> #include <linux/clocksource.h>
>>> #include <linux/errno.h>
>>> #include <linux/export.h>
>>> @@ -121,5 +122,7 @@ void __init time_init(void)
>>> of_clk_init(NULL);
>>> #endif
>>> timer_probe();
>>> +
>>> + tick_setup_hrtimer_broadcast();
>>> }
>>> }
>>>
>>
>> Gentle ping, just to avoid that this falls through the cracks because
>> it's so small.
>>
>
> 2nd ping. Should this patch be routed via ARM or rather some tip/timers
> tree?
>
3rd try: Could someone have a look at this and merge it - or at least
ack it in order to move forward?
Thanks,
Jan
^ permalink raw reply
* [PATCH v2 2/3] ASoC: simple-card: move hp and mic detection to soc_card probe
From: Kuninori Morimoto @ 2018-06-11 5:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <007401d40146$9ddaaec0$d9900c40$@socionext.com>
Hi Katsuhiro
> > > This patch moves headphone and microphone detection to probe() of
> > > snd_soc_card from init() of snd_soc_dai_link. This is because init()
> > > is called (and an input device /dev/input/eventX is created too)
> > > twice or above if simple card has two or more DAI links.
(snip)
> It seems if simple card has multiple DAI links, it creates multiple input
> devices.
>
> For example simple card has 3-links, 3 input devices /dev/input/event0,
> event1, event2 are created. Is it correct?
Oh, I see, fair enough.
I'm sorry, it was my English skill error.
Best regards
---
Kuninori Morimoto
^ permalink raw reply
* [PATCH v3 4/6] bus: ti-sysc: Add support for software reset
From: Faiz Abbas @ 2018-06-11 6:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180608062158.GI5738@atomide.com>
Hi Tony,
On Friday 08 June 2018 11:51 AM, Tony Lindgren wrote:
> * Faiz Abbas <faiz_abbas@ti.com> [180607 10:24]:
>> Hi,
>>
>> On Thursday 07 June 2018 01:05 PM, Tony Lindgren wrote:
>>> * Faiz Abbas <faiz_abbas@ti.com> [180606 06:14]:
>>>> +static int sysc_reset(struct sysc *ddata)
>>>> +{
>>>> + int offset = ddata->offsets[SYSC_SYSCONFIG];
>>>> + int val = sysc_read(ddata, offset);
>>>> +
>>>> + val |= (0x1 << ddata->cap->regbits->srst_shift);
>>>> + sysc_write(ddata, offset, val);
>>>> +
>>>> + /* Poll on reset status */
>>>> + if (ddata->cfg.quirks & SYSC_QUIRK_RESET_STATUS) {
>>>> + offset = ddata->offsets[SYSC_SYSSTATUS];
>>>> +
>>>> + return readl_poll_timeout(ddata->module_va + offset, val,
>>>> + (val & ddata->cfg.syss_mask) == 0x0,
>>>> + 100, MAX_MODULE_SOFTRESET_WAIT);
>>>> + }
>>>> +
>>>> + return 0;
>>>> +}
>>>
>>> I wonder if we should also add SYSS_QUIRK_RESET_STATUS in
>>> addition to SYSC_QUIRK_RESET status to make it easy to
>>> read the right register?
>>
>> I assumed SYSC_QUIRK is the prefix to indicate the ti-sysc driver not
>> the register. Are there layouts in which the reset status bit is in the
>> sysconfig register rather than the sysstatus register?
>
> Yes we can have reset status bit in either syss or syssconfig register.
You mean sysstatus and sysconfig right?
> We detect that in sysc_init_syss_mask() but we should also set something
> at that point to make it clear which reset to use. But as we don't need
> the quirk flag, it's probably set a function pointer after the detection.
> So how about let's have two functions sysc_reset() and sysc_syss_reset()
> and then we can implement sysc_syss_reset() in a separate patch after
> testing it when we have a non-platform data using example for
> sysc_syss_reset().
>
Shouldn't the function I add be called sysc_syss_reset()? The reset
status bit is in the sysstatus.
Thanks,
Faiz
^ permalink raw reply
* [PATCH v3 4/6] bus: ti-sysc: Add support for software reset
From: Tony Lindgren @ 2018-06-11 6:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <acdfef83-8778-e8f4-e423-ed04a9a8a649@ti.com>
* Faiz Abbas <faiz_abbas@ti.com> [180611 06:09]:
> Hi Tony,
>
> On Friday 08 June 2018 11:51 AM, Tony Lindgren wrote:
> > * Faiz Abbas <faiz_abbas@ti.com> [180607 10:24]:
> >> Hi,
> >>
> >> On Thursday 07 June 2018 01:05 PM, Tony Lindgren wrote:
> >>> * Faiz Abbas <faiz_abbas@ti.com> [180606 06:14]:
> >>>> +static int sysc_reset(struct sysc *ddata)
> >>>> +{
> >>>> + int offset = ddata->offsets[SYSC_SYSCONFIG];
> >>>> + int val = sysc_read(ddata, offset);
> >>>> +
> >>>> + val |= (0x1 << ddata->cap->regbits->srst_shift);
> >>>> + sysc_write(ddata, offset, val);
> >>>> +
> >>>> + /* Poll on reset status */
> >>>> + if (ddata->cfg.quirks & SYSC_QUIRK_RESET_STATUS) {
> >>>> + offset = ddata->offsets[SYSC_SYSSTATUS];
> >>>> +
> >>>> + return readl_poll_timeout(ddata->module_va + offset, val,
> >>>> + (val & ddata->cfg.syss_mask) == 0x0,
> >>>> + 100, MAX_MODULE_SOFTRESET_WAIT);
> >>>> + }
> >>>> +
> >>>> + return 0;
> >>>> +}
> >>>
> >>> I wonder if we should also add SYSS_QUIRK_RESET_STATUS in
> >>> addition to SYSC_QUIRK_RESET status to make it easy to
> >>> read the right register?
> >>
> >> I assumed SYSC_QUIRK is the prefix to indicate the ti-sysc driver not
> >> the register. Are there layouts in which the reset status bit is in the
> >> sysconfig register rather than the sysstatus register?
> >
> > Yes we can have reset status bit in either syss or syssconfig register.
>
> You mean sysstatus and sysconfig right?
Yup.
> > We detect that in sysc_init_syss_mask() but we should also set something
> > at that point to make it clear which reset to use. But as we don't need
> > the quirk flag, it's probably set a function pointer after the detection.
> > So how about let's have two functions sysc_reset() and sysc_syss_reset()
> > and then we can implement sysc_syss_reset() in a separate patch after
> > testing it when we have a non-platform data using example for
> > sysc_syss_reset().
> >
>
> Shouldn't the function I add be called sysc_syss_reset()? The reset
> status bit is in the sysstatus.
Yes
Tony
^ permalink raw reply
* [PATCH v3 4/6] bus: ti-sysc: Add support for software reset
From: Faiz Abbas @ 2018-06-11 6:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180611060957.GN5738@atomide.com>
On Monday 11 June 2018 11:39 AM, Tony Lindgren wrote:
> * Faiz Abbas <faiz_abbas@ti.com> [180611 06:09]:
>> Hi Tony,
>>
>> On Friday 08 June 2018 11:51 AM, Tony Lindgren wrote:
>>> * Faiz Abbas <faiz_abbas@ti.com> [180607 10:24]:
>>>> Hi,
>>>>
>>>> On Thursday 07 June 2018 01:05 PM, Tony Lindgren wrote:
>>>>> * Faiz Abbas <faiz_abbas@ti.com> [180606 06:14]:
>>>>>> +static int sysc_reset(struct sysc *ddata)
>>>>>> +{
>>>>>> + int offset = ddata->offsets[SYSC_SYSCONFIG];
>>>>>> + int val = sysc_read(ddata, offset);
>>>>>> +
>>>>>> + val |= (0x1 << ddata->cap->regbits->srst_shift);
>>>>>> + sysc_write(ddata, offset, val);
>>>>>> +
>>>>>> + /* Poll on reset status */
>>>>>> + if (ddata->cfg.quirks & SYSC_QUIRK_RESET_STATUS) {
>>>>>> + offset = ddata->offsets[SYSC_SYSSTATUS];
>>>>>> +
>>>>>> + return readl_poll_timeout(ddata->module_va + offset, val,
>>>>>> + (val & ddata->cfg.syss_mask) == 0x0,
>>>>>> + 100, MAX_MODULE_SOFTRESET_WAIT);
>>>>>> + }
>>>>>> +
>>>>>> + return 0;
>>>>>> +}
>>>>>
>>>>> I wonder if we should also add SYSS_QUIRK_RESET_STATUS in
>>>>> addition to SYSC_QUIRK_RESET status to make it easy to
>>>>> read the right register?
>>>>
>>>> I assumed SYSC_QUIRK is the prefix to indicate the ti-sysc driver not
>>>> the register. Are there layouts in which the reset status bit is in the
>>>> sysconfig register rather than the sysstatus register?
>>>
>>> Yes we can have reset status bit in either syss or syssconfig register.
>>
>> You mean sysstatus and sysconfig right?
>
> Yup.
>
>>> We detect that in sysc_init_syss_mask() but we should also set something
>>> at that point to make it clear which reset to use. But as we don't need
>>> the quirk flag, it's probably set a function pointer after the detection.
>>> So how about let's have two functions sysc_reset() and sysc_syss_reset()
>>> and then we can implement sysc_syss_reset() in a separate patch after
>>> testing it when we have a non-platform data using example for
>>> sysc_syss_reset().
>>>
>>
>> Shouldn't the function I add be called sysc_syss_reset()? The reset
>> status bit is in the sysstatus.
>
> Yes
>
Great. I thought I completely misunderstood you. But I don't see what
adding another function will accomplish. A QUIRK flag used in the same
function would work well enough.
Regards,
Faiz
^ permalink raw reply
* [PATCH v3 4/6] bus: ti-sysc: Add support for software reset
From: Tony Lindgren @ 2018-06-11 6:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f460481f-85a9-2a41-a894-6f25122dee8a@ti.com>
* Faiz Abbas <faiz_abbas@ti.com> [180611 06:28]:
> Great. I thought I completely misunderstood you. But I don't see what
> adding another function will accomplish. A QUIRK flag used in the same
> function would work well enough.
Fine with me as long as the function stays simple for both
syss and sysc reset.
Regards,
Tony
^ permalink raw reply
* [PATCH] ARM: dts: imx6q: Use correct SDMA script for SPI5 core
From: Shawn Guo @ 2018-06-11 6:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180522174509.18154-1-sean.nyekjaer@prevas.dk>
On Tue, May 22, 2018 at 07:45:09PM +0200, Sean Nyekjaer wrote:
> According to the reference manual the shp_2_mcu / mcu_2_shp
> scripts must be used for devices connected through the SPBA.
>
> This fixes an issue we saw with DMA transfers.
> Sometimes the SPI controller RX FIFO was not empty after a DMA
> transfer and the driver got stuck in the next PIO transfer when
> it read one word more than expected.
>
> commit dd4b487b32a35 ("ARM: dts: imx6: Use correct SDMA script
> for SPI cores") is fixing the same issue but only for SPI1 - 4.
>
> Fixes: 677940258dd8e ("ARM: dts: imx6q: enable dma for ecspi5")
> Signed-off-by: Sean Nyekjaer <sean.nyekjaer@prevas.dk>
Applied, thanks.
^ permalink raw reply
* [PATCH v2 1/2] media: v4l2-ctrl: Add control for VP9 profile
From: Keiichi Watanabe @ 2018-06-11 6:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKQmDh8MnArB1jCD6STh9FgLX+H4ZsEnH+coOJe-4A=FNPGshA@mail.gmail.com>
Hi, Hans.
Thank you for the review.
Your idea sounds good.
However, I think that changing V4L2_CID_MPEG_VIDEO_VPX_PROFILE to an enum
breaks both of s5p-mfc and venus drivers. This is because they call
'v4l2_ctrl_new_std' for it. For menu controls,
'v4l2_ctrl_new_std_menu' must be used.
https://elixir.bootlin.com/linux/latest/source/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c#L2678
https://elixir.bootlin.com/linux/latest/source/drivers/media/platform/qcom/venus/vdec_ctrls.c#L133
I can fix them within the commit for adding VP8_PROFILE control, but
cannot confirm that it works on real devices since I don't have them.
What should I do?
Best regards,
Keiichi
On Fri, Jun 8, 2018 at 10:00 PM Nicolas Dufresne <nicolas@ndufresne.ca> wrote:
>
>
>
> Le ven. 8 juin 2018 08:56, Stanimir Varbanov <stanimir.varbanov@linaro.org> a ?crit :
>>
>> Hi Hans,
>>
>> On 06/08/2018 12:29 PM, Hans Verkuil wrote:
>> > On 05/30/2018 09:16 AM, Keiichi Watanabe wrote:
>> >> Add a new control V4L2_CID_MPEG_VIDEO_VP9_PROFILE for selecting desired
>> >> profile for VP9 encoder and querying for supported profiles by VP9 encoder
>> >> or decoder.
>> >>
>> >> An existing control V4L2_CID_MPEG_VIDEO_VPX_PROFILE 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_VP9_PROFILE is a menu control as
>> >> with controls for other codec profiles. (e.g. H264)
>> >
>> > Please ignore my reply to patch 2/2. I looked at this a bit more and what you
>> > should do is to change the type of V4L2_CID_MPEG_VIDEO_VPX_PROFILE to enum.
>> >
>> > All other codec profile controls are all enums, so the fact that VPX_PROFILE
>> > isn't is a bug. Changing the type should not cause any problems since the same
>> > control value is used when you set the control.
>> >
>> > Sylwester: I see that s5p-mfc uses this control, but it is explicitly added
>> > as an integer type control, so the s5p-mfc driver should not be affected by
>> > changing the type of this control.
>> >
>> > Stanimir: this will slightly change the venus driver, but since it is a very
>> > recent driver I think we can get away with changing the core type of the
>> > VPX_PROFILE control. I think that's better than ending up with two controls
>> > that do the same thing.
>>
>> I agree. Actually the changes shouldn't be so much in venus driver.
>
>
> Also fine on userspace side, since profiles enumeration isn't implemented yet in FFMPEG, GStreamer, Chrome
>
>
>>
>> --
>> regards,
>> Stan
^ permalink raw reply
* [PATCH v3 4/6] bus: ti-sysc: Add support for software reset
From: Faiz Abbas @ 2018-06-11 6:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180611062904.GO5738@atomide.com>
Hi,
On Monday 11 June 2018 11:59 AM, Tony Lindgren wrote:
> * Faiz Abbas <faiz_abbas@ti.com> [180611 06:28]:
>> Great. I thought I completely misunderstood you. But I don't see what
>> adding another function will accomplish. A QUIRK flag used in the same
>> function would work well enough>
> Fine with me as long as the function stays simple for both
> syss and sysc reset.
>
In general a reset status bit being in sysstatus is the norm and it
being in sysconfig should be the "quirk" for which a flag needs to be
added. What do you think?
As an aside, naming bitshifts by the name of the platform they were
originally added in seems weird. There should be some generic mask
saying "soft reset is the 0th bit". Currently I am using
SYSC_OMAP4_SOFTRESET for a dra76x module. I guess it depends on how many
different sysconfig types we have.
Thanks,
Faiz
^ permalink raw reply
* [RFC PATCH] iio: adc: at91-sama5d2_adc: add support for oversampling resolution
From: Eugen Hristev @ 2018-06-11 6:52 UTC (permalink / raw)
To: linux-arm-kernel
This is implements oversampling support for the SAMA5D2 ADC
device.
Enabling oversampling : OSR can improve resolution from 12 bits to
13 or 14 bits.
To not modify the scan element of the buffer , from 12 bits to 13 or 14,
I have added the extra bit(s) as MICRO values to the INT value from the
conversion.
Special care was required for the triggered buffer scenario (+ DMA).
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
---
Hello Jonathan,
I marked this patch as RFC because I am not confident in the best way to handle
this oversampling support.
I modified the return value of the channels to use IIO_VALUE_INT_PLUS_MICRO
instead of IIO_VALUE_INT, so I can add an extra bit or two bits in there to the
INT value (0/500000 or 0/250000/500000/7500000) .
You know of a better way to add this support?
Looks like the iio channel spec cannot be modified at
runtime. Would be best if the real bits in the channel spec would be changed to
13 or 14, but then, the buffer would be confused, as the buffer spec is now
le:u12/16>>0 so how can I change that to reflect oversampling, or,
IIO_VALUE_INT_PLUS_MICRO ?
And I am not sure how to handle this w.r.t ABI and userspace changes.
At this moment I added the micro values just to the software trigger readings,
and triggered buffer + DMA does not provide the extra bits, but, I need
to shift all values with 2 bits to the right . The code is rather ugly
right now, but I can change it to look prettier if this is the proper way
to do it.
Thanks for all the feedback,
Eugen
drivers/iio/adc/at91-sama5d2_adc.c | 198 ++++++++++++++++++++++++++++++++-----
1 file changed, 172 insertions(+), 26 deletions(-)
diff --git a/drivers/iio/adc/at91-sama5d2_adc.c b/drivers/iio/adc/at91-sama5d2_adc.c
index 58c4c2b..f1a89b7 100644
--- a/drivers/iio/adc/at91-sama5d2_adc.c
+++ b/drivers/iio/adc/at91-sama5d2_adc.c
@@ -130,6 +130,15 @@
#define AT91_SAMA5D2_OVER 0x3c
/* Extended Mode Register */
#define AT91_SAMA5D2_EMR 0x40
+/* Extended Mode Register - Oversampling rate */
+#define AT91_SAMA5D2_EMR_OSR(V) ((V) << 16)
+#define AT91_SAMA5D2_EMR_OSR_MASK GENMASK(17, 16)
+#define AT91_SAMA5D2_EMR_OSR_0SAMPLES 0
+#define AT91_SAMA5D2_EMR_OSR_4SAMPLES 1
+#define AT91_SAMA5D2_EMR_OSR_16SAMPLES 2
+
+/* Extended Mode Register - Averaging on single trigger event */
+#define AT91_SAMA5D2_EMR_ASTE(V) ((V) << 20)
/* Compare Window Register */
#define AT91_SAMA5D2_CWR 0x44
/* Channel Gain Register */
@@ -248,6 +257,14 @@
#define AT91_HWFIFO_MAX_SIZE_STR "128"
#define AT91_HWFIFO_MAX_SIZE 128
+/* Possible values for oversampling ratio, and the string equivalent */
+#define AT91_OSR_0SAMPLES 0
+#define AT91_OSR_0SAMPLES_STR "0"
+#define AT91_OSR_4SAMPLES 4
+#define AT91_OSR_4SAMPLES_STR "4"
+#define AT91_OSR_16SAMPLES 16
+#define AT91_OSR_16SAMPLES_STR "16"
+
#define AT91_SAMA5D2_CHAN_SINGLE(num, addr) \
{ \
.type = IIO_VOLTAGE, \
@@ -261,7 +278,8 @@
}, \
.info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
.info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
- .info_mask_shared_by_all = BIT(IIO_CHAN_INFO_SAMP_FREQ),\
+ .info_mask_shared_by_all = BIT(IIO_CHAN_INFO_SAMP_FREQ)|\
+ BIT(IIO_CHAN_INFO_OVERSAMPLING_RATIO), \
.datasheet_name = "CH"#num, \
.indexed = 1, \
}
@@ -281,7 +299,8 @@
}, \
.info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
.info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
- .info_mask_shared_by_all = BIT(IIO_CHAN_INFO_SAMP_FREQ),\
+ .info_mask_shared_by_all = BIT(IIO_CHAN_INFO_SAMP_FREQ)|\
+ BIT(IIO_CHAN_INFO_OVERSAMPLING_RATIO), \
.datasheet_name = "CH"#num"-CH"#num2, \
.indexed = 1, \
}
@@ -299,7 +318,8 @@
.storagebits = 16, \
}, \
.info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
- .info_mask_shared_by_all = BIT(IIO_CHAN_INFO_SAMP_FREQ),\
+ .info_mask_shared_by_all = BIT(IIO_CHAN_INFO_SAMP_FREQ)|\
+ BIT(IIO_CHAN_INFO_OVERSAMPLING_RATIO), \
.datasheet_name = name, \
}
#define AT91_SAMA5D2_CHAN_PRESSURE(num, name) \
@@ -313,7 +333,8 @@
.storagebits = 16, \
}, \
.info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
- .info_mask_shared_by_all = BIT(IIO_CHAN_INFO_SAMP_FREQ),\
+ .info_mask_shared_by_all = BIT(IIO_CHAN_INFO_SAMP_FREQ)|\
+ BIT(IIO_CHAN_INFO_OVERSAMPLING_RATIO), \
.datasheet_name = name, \
}
@@ -384,6 +405,7 @@ struct at91_adc_state {
const struct iio_chan_spec *chan;
bool conversion_done;
u32 conversion_value;
+ unsigned int oversampling_ratio;
struct at91_adc_soc_info soc_info;
wait_queue_head_t wq_data_available;
struct at91_adc_dma dma_st;
@@ -475,6 +497,76 @@ static inline int at91_adc_of_xlate(struct iio_dev *indio_dev,
return at91_adc_chan_xlate(indio_dev, iiospec->args[0]);
}
+static void at91_adc_config_emr(struct at91_adc_state *st)
+{
+ /* configure the extended mode register */
+ unsigned int emr = at91_adc_readl(st, AT91_SAMA5D2_EMR);
+
+ /* select oversampling per single trigger event */
+ emr |= AT91_SAMA5D2_EMR_ASTE(1);
+
+ /* delete leftover content if it's the case */
+ emr &= ~AT91_SAMA5D2_EMR_OSR_MASK;
+
+ /* select oversampling ratio from configuration */
+ switch (st->oversampling_ratio) {
+ case AT91_OSR_0SAMPLES:
+ emr |= AT91_SAMA5D2_EMR_OSR(AT91_SAMA5D2_EMR_OSR_0SAMPLES) &
+ AT91_SAMA5D2_EMR_OSR_MASK;
+ break;
+ case AT91_OSR_4SAMPLES:
+ emr |= AT91_SAMA5D2_EMR_OSR(AT91_SAMA5D2_EMR_OSR_4SAMPLES) &
+ AT91_SAMA5D2_EMR_OSR_MASK;
+ break;
+ case AT91_OSR_16SAMPLES:
+ emr |= AT91_SAMA5D2_EMR_OSR(AT91_SAMA5D2_EMR_OSR_16SAMPLES) &
+ AT91_SAMA5D2_EMR_OSR_MASK;
+ break;
+ };
+
+ at91_adc_writel(st, AT91_SAMA5D2_EMR, emr);
+}
+
+static int at91_adc_adjust_val_osr(struct at91_adc_state *st, int *val,
+ int *val2)
+{
+ u8 extra_bits;
+
+ switch (st->oversampling_ratio) {
+ case AT91_OSR_4SAMPLES:
+ /* in this case we need to report 1 extra bit */
+ extra_bits = *val & 0x1;
+ if (extra_bits)
+ *val2 = 500000;
+ else
+ *val2 = 0;
+ *val >>= 1; /* keep just 12 bits */
+ return IIO_VAL_INT_PLUS_MICRO;
+
+ case AT91_OSR_16SAMPLES:
+ /* in this case we need to report 2 extra bits */
+ extra_bits = *val & 0x3;
+ switch (extra_bits) {
+ case 0:
+ *val2 = 0;
+ break;
+ case 1:
+ *val2 = 250000;
+ break;
+ case 2:
+ *val2 = 500000;
+ break;
+ case 3:
+ *val2 = 750000;
+ break;
+ };
+ *val >>= 2; /* keep just 12 bits */
+ return IIO_VAL_INT_PLUS_MICRO;
+ };
+
+ return IIO_VAL_INT;
+}
+
static int at91_adc_configure_touch(struct at91_adc_state *st, bool state)
{
u32 clk_khz = st->current_sample_rate / 1000;
@@ -916,6 +1008,9 @@ static void at91_adc_trigger_handler_nodma(struct iio_dev *indio_dev,
{
struct at91_adc_state *st = iio_priv(indio_dev);
int i = 0;
+ /* micro value for oversampling data */
+ int micro;
+ int val;
u8 bit;
for_each_set_bit(bit, indio_dev->active_scan_mask,
@@ -936,7 +1031,9 @@ static void at91_adc_trigger_handler_nodma(struct iio_dev *indio_dev,
* Thus, emit a warning.
*/
if (chan->type == IIO_VOLTAGE) {
- st->buffer[i] = at91_adc_readl(st, chan->address);
+ val = at91_adc_readl(st, chan->address);
+ at91_adc_adjust_val_osr(st, &val, µ);
+ st->buffer[i] = val;
} else {
st->buffer[i] = 0;
WARN(true, "This trigger cannot handle this type of channel");
@@ -954,6 +1051,9 @@ static void at91_adc_trigger_handler_dma(struct iio_dev *indio_dev)
s64 ns = iio_get_time_ns(indio_dev);
s64 interval;
int sample_index = 0, sample_count, sample_size;
+ /* micro value for oversampling data */
+ int micro;
+ int val, j;
u32 status = at91_adc_readl(st, AT91_SAMA5D2_ISR);
/* if we reached this point, we cannot sample faster */
@@ -972,6 +1072,17 @@ static void at91_adc_trigger_handler_dma(struct iio_dev *indio_dev)
interval = div_s64((ns - st->dma_st.dma_ts), sample_count);
while (transferred_len >= sample_size) {
+ /*
+ * for all the values in the current sample,
+ * adjust the values inside the buffer for oversampling
+ */
+ for (j = 0; j < sample_size / 2; j++) {
+ /* buffer is byte-based. we need the whole value */
+ val = *((u16 *)&st->dma_st.rx_buf[st->dma_st.buf_idx + j * 2]);
+ at91_adc_adjust_val_osr(st, &val, µ);
+ *((u16 *)&st->dma_st.rx_buf[st->dma_st.buf_idx + j * 2]) = val;
+ }
+
iio_push_to_buffers_with_timestamp(indio_dev,
(st->dma_st.rx_buf + st->dma_st.buf_idx),
(st->dma_st.dma_ts + interval * sample_index));
@@ -1190,8 +1301,10 @@ static irqreturn_t at91_adc_interrupt(int irq, void *private)
return IRQ_HANDLED;
}
+
static int at91_adc_read_info_raw(struct iio_dev *indio_dev,
- struct iio_chan_spec const *chan, int *val)
+ struct iio_chan_spec const *chan, int *val,
+ int *val2)
{
struct at91_adc_state *st = iio_priv(indio_dev);
u32 cor = 0;
@@ -1212,7 +1325,7 @@ static int at91_adc_read_info_raw(struct iio_dev *indio_dev,
mutex_unlock(&st->lock);
iio_device_release_direct_mode(indio_dev);
- return ret;
+ return at91_adc_adjust_val_osr(st, val, val2);
}
if (chan->type == IIO_PRESSURE) {
ret = iio_device_claim_direct_mode(indio_dev);
@@ -1225,7 +1338,7 @@ static int at91_adc_read_info_raw(struct iio_dev *indio_dev,
mutex_unlock(&st->lock);
iio_device_release_direct_mode(indio_dev);
- return ret;
+ return at91_adc_adjust_val_osr(st, val, val2);
}
/* in this case we have a voltage channel */
@@ -1254,9 +1367,9 @@ static int at91_adc_read_info_raw(struct iio_dev *indio_dev,
if (ret > 0) {
*val = st->conversion_value;
+ ret = at91_adc_adjust_val_osr(st, val, val2);
if (chan->scan_type.sign == 's')
*val = sign_extend32(*val, 11);
- ret = IIO_VAL_INT;
st->conversion_done = false;
}
@@ -1280,7 +1393,7 @@ static int at91_adc_read_raw(struct iio_dev *indio_dev,
switch (mask) {
case IIO_CHAN_INFO_RAW:
- return at91_adc_read_info_raw(indio_dev, chan, val);
+ return at91_adc_read_info_raw(indio_dev, chan, val, val2);
case IIO_CHAN_INFO_SCALE:
*val = st->vref_uv / 1000;
if (chan->differential)
@@ -1292,6 +1405,10 @@ static int at91_adc_read_raw(struct iio_dev *indio_dev,
*val = at91_adc_get_sample_freq(st);
return IIO_VAL_INT;
+ case IIO_CHAN_INFO_OVERSAMPLING_RATIO:
+ *val = st->oversampling_ratio;
+ return IIO_VAL_INT;
+
default:
return -EINVAL;
}
@@ -1303,16 +1420,28 @@ static int at91_adc_write_raw(struct iio_dev *indio_dev,
{
struct at91_adc_state *st = iio_priv(indio_dev);
- if (mask != IIO_CHAN_INFO_SAMP_FREQ)
- return -EINVAL;
+ switch (mask) {
+ case IIO_CHAN_INFO_OVERSAMPLING_RATIO:
+ if ((val != AT91_OSR_0SAMPLES) && (val != AT91_OSR_4SAMPLES) &&
+ (val != AT91_OSR_16SAMPLES))
+ return -EINVAL;
+ /* if no change, optimize out */
+ if (val == st->oversampling_ratio)
+ return 0;
+ st->oversampling_ratio = val;
+ /* update ratio */
+ at91_adc_config_emr(st);
+ return 0;
+ case IIO_CHAN_INFO_SAMP_FREQ:
+ if (val < st->soc_info.min_sample_rate ||
+ val > st->soc_info.max_sample_rate)
+ return -EINVAL;
- if (val < st->soc_info.min_sample_rate ||
- val > st->soc_info.max_sample_rate)
+ at91_adc_setup_samp_freq(st, val);
+ return 0;
+ default:
return -EINVAL;
-
- at91_adc_setup_samp_freq(st, val);
-
- return 0;
+ };
}
static void at91_adc_dma_init(struct platform_device *pdev)
@@ -1446,14 +1575,6 @@ static int at91_adc_update_scan_mode(struct iio_dev *indio_dev,
return 0;
}
-static const struct iio_info at91_adc_info = {
- .read_raw = &at91_adc_read_raw,
- .write_raw = &at91_adc_write_raw,
- .update_scan_mode = &at91_adc_update_scan_mode,
- .of_xlate = &at91_adc_of_xlate,
- .hwfifo_set_watermark = &at91_adc_set_watermark,
-};
-
static void at91_adc_hw_init(struct at91_adc_state *st)
{
at91_adc_writel(st, AT91_SAMA5D2_CR, AT91_SAMA5D2_CR_SWRST);
@@ -1466,6 +1587,9 @@ static void at91_adc_hw_init(struct at91_adc_state *st)
AT91_SAMA5D2_MR_TRANSFER(2) | AT91_SAMA5D2_MR_ANACH);
at91_adc_setup_samp_freq(st, st->soc_info.min_sample_rate);
+
+ /* configure extended mode register */
+ at91_adc_config_emr(st);
}
static ssize_t at91_adc_get_fifo_state(struct device *dev,
@@ -1496,6 +1620,19 @@ static IIO_DEVICE_ATTR(hwfifo_watermark, 0444,
static IIO_CONST_ATTR(hwfifo_watermark_min, "2");
static IIO_CONST_ATTR(hwfifo_watermark_max, AT91_HWFIFO_MAX_SIZE_STR);
+static IIO_CONST_ATTR(oversampling_ratio_available,
+ AT91_OSR_0SAMPLES_STR " " AT91_OSR_4SAMPLES_STR " "
+ AT91_OSR_16SAMPLES_STR);
+
+static struct attribute *at91_adc_attributes[] = {
+ &iio_const_attr_oversampling_ratio_available.dev_attr.attr,
+ NULL,
+};
+
+static const struct attribute_group at91_adc_attribute_group = {
+ .attrs = at91_adc_attributes,
+};
+
static const struct attribute *at91_adc_fifo_attributes[] = {
&iio_const_attr_hwfifo_watermark_min.dev_attr.attr,
&iio_const_attr_hwfifo_watermark_max.dev_attr.attr,
@@ -1504,6 +1641,15 @@ static const struct attribute *at91_adc_fifo_attributes[] = {
NULL,
};
+static const struct iio_info at91_adc_info = {
+ .attrs = &at91_adc_attribute_group,
+ .read_raw = &at91_adc_read_raw,
+ .write_raw = &at91_adc_write_raw,
+ .update_scan_mode = &at91_adc_update_scan_mode,
+ .of_xlate = &at91_adc_of_xlate,
+ .hwfifo_set_watermark = &at91_adc_set_watermark,
+};
+
static int at91_adc_probe(struct platform_device *pdev)
{
struct iio_dev *indio_dev;
--
2.7.4
^ permalink raw reply related
* [PATCH v3 4/6] bus: ti-sysc: Add support for software reset
From: Tony Lindgren @ 2018-06-11 7:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <89d55b0b-fe9e-793b-2694-25755ac2bc15@ti.com>
* Faiz Abbas <faiz_abbas@ti.com> [180611 06:48]:
> Hi,
>
> On Monday 11 June 2018 11:59 AM, Tony Lindgren wrote:
> > * Faiz Abbas <faiz_abbas@ti.com> [180611 06:28]:
> >> Great. I thought I completely misunderstood you. But I don't see what
> >> adding another function will accomplish. A QUIRK flag used in the same
> >> function would work well enough>
> > Fine with me as long as the function stays simple for both
> > syss and sysc reset.
> >
>
>
> In general a reset status bit being in sysstatus is the norm and it
> being in sysconfig should be the "quirk" for which a flag needs to be
> added. What do you think?
Sure makes sense to me.
> As an aside, naming bitshifts by the name of the platform they were
> originally added in seems weird. There should be some generic mask
> saying "soft reset is the 0th bit". Currently I am using
> SYSC_OMAP4_SOFTRESET for a dra76x module. I guess it depends on how many
> different sysconfig types we have.
Sure we could have a macro for that.
Regards,
Tony
^ permalink raw reply
* [PATCH v2 1/2] media: v4l2-ctrl: Add control for VP9 profile
From: Hans Verkuil @ 2018-06-11 7:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANb2CJFXhY+mzEV7AnM5EQcvqyeAH7G=t3Bi_9_d9_+_Kce9RQ@mail.gmail.com>
On 11/06/18 08:44, Keiichi Watanabe wrote:
> Hi, Hans.
> Thank you for the review.
> Your idea sounds good.
>
> However, I think that changing V4L2_CID_MPEG_VIDEO_VPX_PROFILE to an enum
> breaks both of s5p-mfc and venus drivers. This is because they call
> 'v4l2_ctrl_new_std' for it. For menu controls,
> 'v4l2_ctrl_new_std_menu' must be used.
>
> https://elixir.bootlin.com/linux/latest/source/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c#L2678
> https://elixir.bootlin.com/linux/latest/source/drivers/media/platform/qcom/venus/vdec_ctrls.c#L133
>
> I can fix them within the commit for adding VP8_PROFILE control, but
> cannot confirm that it works on real devices since I don't have them.
> What should I do?
Fix it in both drivers with a Cc to stanimir.varbanov at linaro.org (venus) and
s.nawrocki at samsung.com (s5p) to let them test/ack the patch.
Venus is no problem, the s5p driver can decide to keep the old INT control
since it has been in use for such a long time, but that is up to Sylwester to
decide.
Regards,
Hans
>
> Best regards,
> Keiichi
> On Fri, Jun 8, 2018 at 10:00 PM Nicolas Dufresne <nicolas@ndufresne.ca> wrote:
>>
>>
>>
>> Le ven. 8 juin 2018 08:56, Stanimir Varbanov <stanimir.varbanov@linaro.org> a ?crit :
>>>
>>> Hi Hans,
>>>
>>> On 06/08/2018 12:29 PM, Hans Verkuil wrote:
>>>> On 05/30/2018 09:16 AM, Keiichi Watanabe wrote:
>>>>> Add a new control V4L2_CID_MPEG_VIDEO_VP9_PROFILE for selecting desired
>>>>> profile for VP9 encoder and querying for supported profiles by VP9 encoder
>>>>> or decoder.
>>>>>
>>>>> An existing control V4L2_CID_MPEG_VIDEO_VPX_PROFILE 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_VP9_PROFILE is a menu control as
>>>>> with controls for other codec profiles. (e.g. H264)
>>>>
>>>> Please ignore my reply to patch 2/2. I looked at this a bit more and what you
>>>> should do is to change the type of V4L2_CID_MPEG_VIDEO_VPX_PROFILE to enum.
>>>>
>>>> All other codec profile controls are all enums, so the fact that VPX_PROFILE
>>>> isn't is a bug. Changing the type should not cause any problems since the same
>>>> control value is used when you set the control.
>>>>
>>>> Sylwester: I see that s5p-mfc uses this control, but it is explicitly added
>>>> as an integer type control, so the s5p-mfc driver should not be affected by
>>>> changing the type of this control.
>>>>
>>>> Stanimir: this will slightly change the venus driver, but since it is a very
>>>> recent driver I think we can get away with changing the core type of the
>>>> VPX_PROFILE control. I think that's better than ending up with two controls
>>>> that do the same thing.
>>>
>>> I agree. Actually the changes shouldn't be so much in venus driver.
>>
>>
>> Also fine on userspace side, since profiles enumeration isn't implemented yet in FFMPEG, GStreamer, Chrome
>>
>>
>>>
>>> --
>>> regards,
>>> Stan
^ permalink raw reply
* [PATCH 1/2] ARM: dts: imx6: make edt-ft5x06 a wakeup source for imx6 boards
From: Shawn Guo @ 2018-06-11 7:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180523083013.7570-1-daniel@zonque.org>
On Wed, May 23, 2018 at 10:30:12AM +0200, Daniel Mack wrote:
> The touchscreen driver no longer configures the device as wakeup source by
> default. A "wakeup-source" property is needed.
>
> Signed-off-by: Daniel Mack <daniel@zonque.org>
Applied, thanks.
^ permalink raw reply
* [PATCH 2/2] ARM: dts: am437x: make edt-ft5x06 a wakeup source for imx6 boards
From: Shawn Guo @ 2018-06-11 7:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180523083013.7570-2-daniel@zonque.org>
On Wed, May 23, 2018 at 10:30:13AM +0200, Daniel Mack wrote:
> The touchscreen driver no longer configures the device as wakeup source by
> default. A "wakeup-source" property is needed.
>
> Signed-off-by: Daniel Mack <daniel@zonque.org>
This is not an imx6 board, and I have to leave it to relevant platform
maintainer. The patch subject should be fixed to drop 'imx6'.
Shawn
> ---
> arch/arm/boot/dts/am437x-sk-evm.dts | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/boot/dts/am437x-sk-evm.dts b/arch/arm/boot/dts/am437x-sk-evm.dts
> index 4118802b7fea..f17ed89da06b 100644
> --- a/arch/arm/boot/dts/am437x-sk-evm.dts
> +++ b/arch/arm/boot/dts/am437x-sk-evm.dts
> @@ -537,6 +537,8 @@
>
> touchscreen-size-x = <480>;
> touchscreen-size-y = <272>;
> +
> + wakeup-source;
> };
>
> tlv320aic3106: tlv320aic3106 at 1b {
> --
> 2.14.3
>
^ permalink raw reply
* [PATCH 04/24] 32-bit userspace ABI: introduce ARCH_32BIT_OFF_T config option
From: Arnd Bergmann @ 2018-06-11 7:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180609074227.GA6810@yury-thinkpad>
On Sat, Jun 9, 2018 at 9:42 AM, Yury Norov <ynorov@caviumnetworks.com> wrote:
> On Fri, Jun 08, 2018 at 06:32:07PM +0100, Catalin Marinas wrote:
>> On Wed, May 16, 2018 at 11:18:49AM +0300, Yury Norov wrote:
>> > diff --git a/arch/Kconfig b/arch/Kconfig
>> > index 76c0b54443b1..ee079244dc3c 100644
>> > --- a/arch/Kconfig
>> > +++ b/arch/Kconfig
>> > @@ -264,6 +264,21 @@ config ARCH_THREAD_STACK_ALLOCATOR
>> > config ARCH_WANTS_DYNAMIC_TASK_STRUCT
>> > bool
>> >
>> > +config ARCH_32BIT_OFF_T
>> > + bool
>> > + depends on !64BIT
>> > + help
>> > + All new 32-bit architectures should have 64-bit off_t type on
>> > + userspace side which corresponds to the loff_t kernel type. This
>> > + is the requirement for modern ABIs. Some existing architectures
>> > + already have 32-bit off_t. This option is enabled for all such
>> > + architectures explicitly. Namely: arc, arm, blackfin, cris, frv,
>> > + h8300, hexagon, m32r, m68k, metag, microblaze, mips32, mn10300,
>> > + nios2, openrisc, parisc32, powerpc32, score, sh, sparc, tile32,
>> > + unicore32, x86_32 and xtensa. This is the complete list. Any
>> > + new 32-bit architecture should declare 64-bit off_t type on user
>> > + side and so should not enable this option.
>>
>> Do you know if this is the case for riscv and nds32, merged in the
>> meantime? If not, I suggest you drop this patch altogether and just
>> define force_o_largefile() for arm64/ilp32 as we don't seem to stick to
>> "all new 32-bit architectures should have 64-bit off_t".
>
> I wrote this patch at request of Arnd Bergmann. This is actually his
> words that all new 32-bit architectures should have 64-bit off_t. So
> I was surprized when riscv was merged with 32-bit off_t (and I didn't
> follow nds32).
>
> If this rule is still in force, we'd better add new exceptions to this
> patch. Otherwise, we can drop it.
>
> Arnd, could you please comment it?
I completely forgot about it and had assumed that it was merged long
ago, sorry about that.
Arnd
^ permalink raw reply
* [GIT PULL] Allwinner clock changes for 4.18
From: Chen-Yu Tsai @ 2018-06-11 7:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK7LNASgetmPKKS8AhYXqSSEFCi+q0ASZ68M0SECJT5EbAU4XQ@mail.gmail.com>
Hi,
On Mon, Jun 11, 2018 at 10:00 AM, Masahiro Yamada
<yamada.masahiro@socionext.com> wrote:
> Hi Maxime,
>
>
> 2018-05-21 20:59 GMT+09:00 Maxime Ripard <maxime.ripard@bootlin.com>:
>> Hi Mike, Stephen,
>>
>> Please merge the following changes for the next merge window, thanks!
>>
>> Maxime
>>
>> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>>
>> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>>
>> are available in the Git repository at:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git tags/sunxi-clk-for-4.18
>>
>> for you to fetch changes up to 17de4c857b1f74b90967f7e7fd5ff81be61dc044:
>>
>> clk: sunxi-ng: r40: export a regmap to access the GMAC register (2018-05-17 14:02:07 +0800)
>>
>> ----------------------------------------------------------------
>> Allwinner clock changes for 4.18
>>
>> Not a lot of changes for this release, but two quite important features
>> were added: the H6 PRCM clock support, and the needed changes to the R40
>> clock driver to allow for the EMAC to operate.
>>
>> ----------------------------------------------------------------
>> Icenowy Zheng (3):
>> clk: sunxi-ng: add support for H6 PRCM CCU
>> clk: sunxi-ng: r40: rewrite init code to a platform driver
>> clk: sunxi-ng: r40: export a regmap to access the GMAC register
>>
>
>
>
> Why was my patch "clk: sunxi-ng: replace lib-y with obj-y"
> not included in the pull request?
>
>
> You said "I've picked it up"
> https://patchwork.kernel.org/patch/10348031/
It looks like it was accidentally dropped after a rebase.
Not quite sure what happened there. Maxime?
ChenYu
^ 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