* [PATCH] [MT6660] Mediatek Smart Amplifier Driver
From: richtek.jeff.chang @ 2019-09-03 7:08 UTC (permalink / raw)
To: lgirdwood
Cc: alsa-devel, linux-kernel, tiwai, perex, Richtek Jeff Chang,
broonie, linux-mediatek, matthias.bgg, linux-arm-kernel
From: Richtek Jeff Chang <richtek.jeff.chang@gmail.com>
Signed-off-by: Richtek Jeff Chang <richtek.jeff.chang@gmail.com>
---
sound/soc/codecs/Kconfig | 13 +
sound/soc/codecs/Makefile | 2 +
sound/soc/codecs/mt6660.c | 802 ++++++++++++++++++++++++++++++++++++++++++++++
sound/soc/codecs/mt6660.h | 68 ++++
4 files changed, 885 insertions(+)
create mode 100644 sound/soc/codecs/mt6660.c
create mode 100644 sound/soc/codecs/mt6660.h
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 9f89a53..3407436 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -120,6 +120,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_ML26124 if I2C
select SND_SOC_MT6351 if MTK_PMIC_WRAP
select SND_SOC_MT6358 if MTK_PMIC_WRAP
+ select SND_SOC_MT6660 if I2C
select SND_SOC_NAU8540 if I2C
select SND_SOC_NAU8810 if I2C
select SND_SOC_NAU8822 if I2C
@@ -1444,6 +1445,18 @@ config SND_SOC_MT6358
Enable support for the platform which uses MT6358 as
external codec device.
+config SND_SOC_MT6660
+ tristate "MediaTek MT6660 Speaker amplifier"
+ depends on I2C
+ select CRC32
+ select CRYPTO_SHA256
+ select CRYPTO_RSA
+ help
+ MediaTek MT6660 is a smart power amplifier which contain
+ speaker protection, multi-band DRC, equalizer functions.
+ Select N if you don't have MT6660 on board.
+ Select M to build this as module.
+
config SND_SOC_NAU8540
tristate "Nuvoton Technology Corporation NAU85L40 CODEC"
depends on I2C
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index 5b4bb8c..e6a8054 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -117,6 +117,7 @@ snd-soc-msm8916-analog-objs := msm8916-wcd-analog.o
snd-soc-msm8916-digital-objs := msm8916-wcd-digital.o
snd-soc-mt6351-objs := mt6351.o
snd-soc-mt6358-objs := mt6358.o
+snd-soc-mt6660-objs := mt6660.o
snd-soc-nau8540-objs := nau8540.o
snd-soc-nau8810-objs := nau8810.o
snd-soc-nau8822-objs := nau8822.o
@@ -398,6 +399,7 @@ obj-$(CONFIG_SND_SOC_MSM8916_WCD_ANALOG) +=snd-soc-msm8916-analog.o
obj-$(CONFIG_SND_SOC_MSM8916_WCD_DIGITAL) +=snd-soc-msm8916-digital.o
obj-$(CONFIG_SND_SOC_MT6351) += snd-soc-mt6351.o
obj-$(CONFIG_SND_SOC_MT6358) += snd-soc-mt6358.o
+obj-$(CONFIG_SND_SOC_MT6660) += snd-soc-mt6660.o
obj-$(CONFIG_SND_SOC_NAU8540) += snd-soc-nau8540.o
obj-$(CONFIG_SND_SOC_NAU8810) += snd-soc-nau8810.o
obj-$(CONFIG_SND_SOC_NAU8822) += snd-soc-nau8822.o
diff --git a/sound/soc/codecs/mt6660.c b/sound/soc/codecs/mt6660.c
new file mode 100644
index 0000000..b82cf03
--- /dev/null
+++ b/sound/soc/codecs/mt6660.c
@@ -0,0 +1,802 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019 MediaTek Inc.
+ */
+
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/version.h>
+#include <linux/err.h>
+#include <linux/i2c.h>
+#include <linux/delay.h>
+#include <sound/soc.h>
+#include <sound/tlv.h>
+#include <sound/pcm_params.h>
+#include <linux/debugfs.h>
+
+#include "mt6660.h"
+
+union mt6660_multi_byte_data {
+ u32 data_u32;
+ u16 data_u16;
+ u8 data_u8;
+ u8 data[4];
+};
+
+struct codec_reg_val {
+ u32 addr;
+ u32 mask;
+ u32 data;
+};
+
+struct reg_size_table {
+ u32 addr;
+ u8 size;
+};
+
+static const struct reg_size_table mt6660_reg_size_table[] = {
+ { MT6660_REG_HPF1_COEF, 4 },
+ { MT6660_REG_HPF2_COEF, 4 },
+ { MT6660_REG_TDM_CFG3, 2 },
+ { MT6660_REG_RESV17, 2 },
+ { MT6660_REG_RESV23, 2 },
+ { MT6660_REG_SIGMAX, 2 },
+ { MT6660_REG_DEVID, 2},
+ { MT6660_REG_TDM_CFG3, 2},
+ { MT6660_REG_HCLIP_CTRL, 2},
+ { MT6660_REG_DA_GAIN, 2},
+};
+
+static int mt6660_get_reg_size(uint32_t addr)
+{
+ int i = 0;
+
+ for (i = 0; i < ARRAY_SIZE(mt6660_reg_size_table); i++) {
+ if (mt6660_reg_size_table[i].addr == addr)
+ return mt6660_reg_size_table[i].size;
+ }
+ return 1;
+}
+
+static int32_t mt6660_i2c_update_bits(struct mt6660_chip *chip,
+ uint32_t addr, uint32_t mask, uint32_t data)
+{
+ int ret = 0;
+ uint32_t value;
+ int size = mt6660_get_reg_size(addr);
+ union mt6660_multi_byte_data mdata;
+
+ memcpy(&mdata, &data, sizeof(uint32_t));
+
+ mutex_lock(&chip->io_lock);
+ ret = i2c_smbus_read_i2c_block_data(
+ chip->i2c, addr, size, (u8 *)&value);
+ if (ret < 0) {
+ mutex_unlock(&chip->io_lock);
+ return ret;
+ }
+ switch (size) {
+ case 1:
+ value &= ~mask;
+ value |= (mdata.data_u8 & mask);
+ break;
+ case 2:
+ value = be16_to_cpu(value);
+ value &= ~mask;
+ value |= (mdata.data_u16 & mask);
+ value = be16_to_cpu(value);
+ break;
+ case 4:
+ value = be32_to_cpu(value);
+ value &= ~mask;
+ value |= (mdata.data_u32 & mask);
+ value = be32_to_cpu(value);
+ break;
+ default:
+ dev_err(chip->dev, "%s Invalid bytes\n", __func__);
+ break;
+ }
+
+ ret = i2c_smbus_write_i2c_block_data(
+ chip->i2c, addr, size, (u8 *)&value);
+ if (ret < 0) {
+ mutex_unlock(&chip->io_lock);
+ return ret;
+ }
+ mutex_unlock(&chip->io_lock);
+
+ return 0;
+}
+
+static int mt6660_i2c_read(struct mt6660_chip *chip, unsigned int reg)
+{
+ int size = mt6660_get_reg_size(reg);
+ int i = 0, ret = 0;
+ u8 data[4] = {0};
+ u32 reg_data = 0;
+
+ ret = i2c_smbus_read_i2c_block_data(chip->i2c, reg, size, data);
+ if (ret < 0)
+ return ret;
+ for (i = 0; i < size; i++) {
+ reg_data <<= 8;
+ reg_data |= data[i];
+ }
+ return reg_data;
+}
+
+static unsigned int mt6660_component_io_read(
+ struct snd_soc_component *component, unsigned int reg)
+{
+ struct mt6660_chip *chip = snd_soc_component_get_drvdata(component);
+
+ return mt6660_i2c_read(chip, reg);
+}
+
+static int mt6660_component_io_write(struct snd_soc_component *component,
+ unsigned int reg, unsigned int data)
+{
+ struct mt6660_chip *chip = snd_soc_component_get_drvdata(component);
+ int size = mt6660_get_reg_size(reg);
+ u8 reg_data[4] = {0};
+ int i = 0;
+
+ for (i = 0; i < size; i++)
+ reg_data[size - i - 1] = (data >> (8 * i)) & 0xff;
+
+ return i2c_smbus_write_i2c_block_data(chip->i2c, reg, size, reg_data);
+}
+
+static const int mt6660_dump_table[] = {
+ MT6660_REG_DEVID,
+ MT6660_REG_SYSTEM_CTRL,
+ MT6660_REG_IRQ_STATUS1,
+ MT6660_REG_SERIAL_CFG1,
+ MT6660_REG_DATAO_SEL,
+ MT6660_REG_TDM_CFG3,
+ MT6660_REG_HPF_CTRL,
+ MT6660_REG_HPF1_COEF,
+ MT6660_REG_HPF2_COEF,
+ MT6660_REG_PATH_BYPASS,
+ MT6660_REG_WDT_CTRL,
+ MT6660_REG_HCLIP_CTRL,
+ MT6660_REG_VOL_CTRL,
+ MT6660_REG_SPS_CTRL,
+ MT6660_REG_SIGMAX,
+ MT6660_REG_CALI_T0,
+ MT6660_REG_BST_CTRL,
+ MT6660_REG_PROTECTION_CFG,
+ MT6660_REG_DA_GAIN,
+ MT6660_REG_AUDIO_IN2_SEL,
+ MT6660_REG_SIG_GAIN,
+ MT6660_REG_PLL_CFG1,
+ MT6660_REG_DRE_CTRL,
+ MT6660_REG_DRE_THDMODE,
+ MT6660_REG_DRE_CORASE,
+ MT6660_REG_PWM_CTRL,
+ MT6660_REG_DC_PROTECT_CTRL,
+ MT6660_REG_ADC_USB_MODE,
+ MT6660_REG_INTERNAL_CFG,
+ MT6660_REG_RESV0,
+ MT6660_REG_RESV1,
+ MT6660_REG_RESV2,
+ MT6660_REG_RESV3,
+ MT6660_REG_RESV7,
+ MT6660_REG_RESV10,
+ MT6660_REG_RESV11,
+ MT6660_REG_RESV16,
+ MT6660_REG_RESV17,
+ MT6660_REG_RESV19,
+ MT6660_REG_RESV21,
+ MT6660_REG_RESV23,
+ MT6660_REG_RESV31,
+ MT6660_REG_RESV40,
+};
+
+static const struct codec_reg_val e4_reg_inits[] = {
+ { MT6660_REG_WDT_CTRL, 0x80, 0x00 },
+ { MT6660_REG_SPS_CTRL, 0x01, 0x01 },
+ { MT6660_REG_AUDIO_IN2_SEL, 0x1c, 0x04 },
+ { MT6660_REG_RESV11, 0x0c, 0x00 },
+ { MT6660_REG_RESV31, 0x03, 0x03 },
+ { MT6660_REG_RESV40, 0x01, 0x00 },
+ { MT6660_REG_RESV0, 0x44, 0x04 },
+ { MT6660_REG_RESV19, 0xff, 0x82 },
+ { MT6660_REG_RESV17, 0x7777, 0x7273 },
+ { MT6660_REG_RESV16, 0x07, 0x03 },
+ { MT6660_REG_DRE_CORASE, 0xe0, 0x20 },
+ { MT6660_REG_ADDA_CLOCK, 0xff, 0x70 },
+ { MT6660_REG_RESV21, 0xff, 0x20 },
+ { MT6660_REG_DRE_THDMODE, 0xff, 0x40 },
+ { MT6660_REG_RESV23, 0xffff, 0x17f8 },
+ { MT6660_REG_PWM_CTRL, 0xff, 0x15 },
+ { MT6660_REG_ADC_USB_MODE, 0xff, 0x00 },
+ { MT6660_REG_PROTECTION_CFG, 0xff, 0x1d },
+ { MT6660_REG_HPF1_COEF, 0xffffffff, 0x7fdb7ffe },
+ { MT6660_REG_HPF2_COEF, 0xffffffff, 0x7fdb7ffe },
+ { MT6660_REG_SIG_GAIN, 0xff, 0x58 },
+ { MT6660_REG_RESV6, 0xff, 0xce },
+ { MT6660_REG_SIGMAX, 0xffff, 0x7fff },
+ { MT6660_REG_DA_GAIN, 0xffff, 0x0116 },
+ { MT6660_REG_TDM_CFG3, 0x1800, 0x0800 },
+ { MT6660_REG_DRE_CTRL, 0x1f, 0x07 },
+};
+
+static int mt6660_i2c_init_setting(struct mt6660_chip *chip)
+{
+ int i, len, ret;
+ const struct codec_reg_val *init_table;
+
+ init_table = e4_reg_inits;
+ len = ARRAY_SIZE(e4_reg_inits);
+
+ for (i = 0; i < len; i++) {
+ ret = mt6660_i2c_update_bits(chip, init_table[i].addr,
+ init_table[i].mask, init_table[i].data);
+ if (ret < 0)
+ return ret;
+ }
+ return 0;
+}
+
+static int mt6660_chip_power_on(
+ struct snd_soc_component *component, int on_off)
+{
+ struct mt6660_chip *chip = (struct mt6660_chip *)
+ snd_soc_component_get_drvdata(component);
+ int ret = 0;
+ unsigned int val;
+
+ dev_dbg(component->dev, "%s: on_off = %d\n", __func__, on_off);
+ mutex_lock(&chip->var_lock);
+ if (on_off) {
+ if (chip->pwr_cnt == 0) {
+ ret = mt6660_i2c_update_bits(chip,
+ MT6660_REG_SYSTEM_CTRL, 0x01, 0x00);
+ val = mt6660_i2c_read(chip, MT6660_REG_IRQ_STATUS1);
+ dev_info(chip->dev,
+ "%s reg0x05 = 0x%x\n", __func__, val);
+ }
+ chip->pwr_cnt++;
+ } else {
+ chip->pwr_cnt--;
+ if (chip->pwr_cnt == 0) {
+ ret = mt6660_i2c_update_bits(chip,
+ MT6660_REG_SYSTEM_CTRL, 0x01, 0xff);
+ }
+ if (chip->pwr_cnt < 0) {
+ dev_warn(chip->dev, "not paired on/off\n");
+ chip->pwr_cnt = 0;
+ }
+ }
+ mutex_unlock(&chip->var_lock);
+ if (ret < 0)
+ pr_err("%s ret = %d\n", __func__, ret);
+ return ret;
+}
+
+static int mt6660_component_set_bias_level(struct snd_soc_component *component,
+ enum snd_soc_bias_level level)
+{
+ struct snd_soc_dapm_context *dapm =
+ snd_soc_component_get_dapm(component);
+ int ret;
+ unsigned int val;
+ struct mt6660_chip *chip = snd_soc_component_get_drvdata(component);
+
+ if (dapm->bias_level == level) {
+ dev_warn(component->dev, "%s: repeat level change\n", __func__);
+ return 0;
+ }
+ switch (level) {
+ case SND_SOC_BIAS_ON:
+ case SND_SOC_BIAS_PREPARE:
+ break;
+ case SND_SOC_BIAS_STANDBY:
+ if (dapm->bias_level != SND_SOC_BIAS_OFF)
+ break;
+ dev_dbg(component->dev, "exit low power mode\n");
+ ret = mt6660_chip_power_on(component, 1);
+ if (ret < 0) {
+ dev_err(component->dev, "power on fail\n");
+ return ret;
+ }
+ break;
+ case SND_SOC_BIAS_OFF:
+ dev_dbg(component->dev, "enter low power mode\n");
+ val = mt6660_i2c_read(chip, MT6660_REG_IRQ_STATUS1);
+ dev_info(component->dev,
+ "%s reg0x05 = 0x%x\n", __func__, val);
+ ret = mt6660_chip_power_on(component, 0);
+ if (ret < 0) {
+ dev_err(component->dev, "power off fail\n");
+ return ret;
+ }
+ break;
+ default:
+ return -EINVAL;
+ }
+ dapm->bias_level = level;
+ dev_dbg(component->dev, "c bias_level = %d\n", level);
+ return 0;
+}
+
+static int mt6660_component_probe(struct snd_soc_component *component)
+{
+ struct mt6660_chip *chip = snd_soc_component_get_drvdata(component);
+ int ret = 0;
+
+ ret = mt6660_component_set_bias_level(component, SND_SOC_BIAS_STANDBY);
+ if (ret < 0) {
+ dev_err(component->dev, "config bias standby fail\n");
+ return ret;
+ }
+
+ ret = mt6660_component_set_bias_level(component, SND_SOC_BIAS_OFF);
+ if (ret < 0) {
+ dev_err(component->dev, "config bias off fail\n");
+ return ret;
+ }
+ chip->component = component;
+ return 0;
+}
+
+static void mt6660_component_remove(struct snd_soc_component *component)
+{
+ struct mt6660_chip *chip = snd_soc_component_get_drvdata(component);
+
+ dev_dbg(component->dev, "%s++\n", __func__);
+ chip->component = NULL;
+ dev_dbg(component->dev, "%s--\n", __func__);
+}
+
+static int mt6660_codec_dac_event(struct snd_soc_dapm_widget *w,
+ struct snd_kcontrol *kcontrol, int event)
+{
+ switch (event) {
+ case SND_SOC_DAPM_POST_PMU:
+ usleep_range(1000, 1100);
+ break;
+ }
+ return 0;
+}
+
+static int mt6660_codec_classd_event(struct snd_soc_dapm_widget *w,
+ struct snd_kcontrol *kcontrol, int event)
+{
+ struct snd_soc_component *component =
+ snd_soc_dapm_to_component(w->dapm);
+ int ret = 0;
+
+ switch (event) {
+ case SND_SOC_DAPM_PRE_PMU:
+ dev_dbg(component->dev,
+ "%s: before classd turn on\n", __func__);
+ /* config to adaptive mode */
+ ret = snd_soc_component_update_bits(component,
+ MT6660_REG_BST_CTRL, 0x03, 0x03);
+ if (ret < 0) {
+ dev_err(component->dev, "config mode adaptive fail\n");
+ return ret;
+ }
+ break;
+ case SND_SOC_DAPM_POST_PMU:
+ /* voltage sensing enable */
+ ret = snd_soc_component_update_bits(component,
+ MT6660_REG_RESV7, 0x04, 0x04);
+ if (ret < 0) {
+ dev_err(component->dev,
+ "enable voltage sensing fail\n");
+ return ret;
+ }
+ break;
+ case SND_SOC_DAPM_PRE_PMD:
+ /* voltage sensing disable */
+ ret = snd_soc_component_update_bits(component,
+ MT6660_REG_RESV7, 0x04, 0x00);
+ if (ret < 0) {
+ dev_err(component->dev,
+ "disable voltage sensing fail\n");
+ return ret;
+ }
+ /* pop-noise improvement 1 */
+ ret = snd_soc_component_update_bits(component,
+ MT6660_REG_RESV10, 0x10, 0x10);
+ if (ret < 0) {
+ dev_err(component->dev,
+ "pop-noise improvement 1 fail\n");
+ return ret;
+ }
+ break;
+ case SND_SOC_DAPM_POST_PMD:
+ dev_dbg(component->dev,
+ "%s: after classd turn off\n", __func__);
+ /* pop-noise improvement 2 */
+ ret = snd_soc_component_update_bits(component,
+ MT6660_REG_RESV10, 0x10, 0x00);
+ if (ret < 0) {
+ dev_err(component->dev,
+ "pop-noise improvement 2 fail\n");
+ return ret;
+ }
+ /* config to off mode */
+ ret = snd_soc_component_update_bits(component,
+ MT6660_REG_BST_CTRL, 0x03, 0x00);
+ if (ret < 0) {
+ dev_err(component->dev, "config mode off fail\n");
+ return ret;
+ }
+ break;
+ }
+ return 0;
+}
+
+static const struct snd_soc_dapm_widget mt6660_component_dapm_widgets[] = {
+ SND_SOC_DAPM_DAC_E("DAC", NULL, MT6660_REG_PLL_CFG1,
+ 0, 1, mt6660_codec_dac_event, SND_SOC_DAPM_POST_PMU),
+ SND_SOC_DAPM_ADC("VI ADC", NULL, SND_SOC_NOPM, 0, 0),
+ SND_SOC_DAPM_PGA("PGA", SND_SOC_NOPM, 0, 0, NULL, 0),
+ SND_SOC_DAPM_OUT_DRV_E("ClassD", MT6660_REG_SYSTEM_CTRL, 2, 0,
+ NULL, 0, mt6660_codec_classd_event,
+ SND_SOC_DAPM_PRE_PMU | SND_SOC_DAPM_POST_PMU |
+ SND_SOC_DAPM_PRE_PMD | SND_SOC_DAPM_POST_PMD),
+ SND_SOC_DAPM_SPK("SPK", NULL),
+};
+
+static const struct snd_soc_dapm_route mt6660_component_dapm_routes[] = {
+ { "DAC", NULL, "aif_playback"},
+ { "PGA", NULL, "DAC"},
+ { "ClassD", NULL, "PGA"},
+ { "SPK", NULL, "ClassD"},
+ { "VI ADC", NULL, "ClassD"},
+ { "aif_capture", NULL, "VI ADC"},
+};
+
+static int mt6660_component_put_volsw(struct snd_kcontrol *kcontrol,
+ struct snd_ctl_elem_value *ucontrol)
+{
+ struct snd_soc_component *component =
+ snd_soc_kcontrol_component(kcontrol);
+ int ret, put_ret = 0;
+
+ ret = mt6660_chip_power_on(component, 1);
+ if (ret < 0)
+ dev_err(component->dev, "%s: pwr on fail\n", __func__);
+ put_ret = snd_soc_put_volsw(kcontrol, ucontrol);
+ if (ret < 0)
+ return ret;
+ ret = mt6660_chip_power_on(component, 0);
+ if (ret < 0)
+ dev_err(component->dev, "%s: pwr off fail\n", __func__);
+ return put_ret;
+}
+
+static int mt6660_component_get_volsw(struct snd_kcontrol *kcontrol,
+ struct snd_ctl_elem_value *ucontrol)
+{
+ struct snd_soc_component *component =
+ snd_soc_kcontrol_component(kcontrol);
+ struct mt6660_chip *chip = (struct mt6660_chip *)
+ snd_soc_component_get_drvdata(component);
+ int ret = -EINVAL;
+
+ if (!strcmp(kcontrol->id.name, "Chip_Rev")) {
+ ucontrol->value.integer.value[0] = chip->chip_rev & 0x0f;
+ ret = 0;
+ }
+ return ret;
+}
+
+static const DECLARE_TLV_DB_SCALE(vol_ctl_tlv, -1155, 5, 0);
+
+static const struct snd_kcontrol_new mt6660_component_snd_controls[] = {
+ SOC_SINGLE_EXT_TLV("Volume_Ctrl", MT6660_REG_VOL_CTRL, 0, 255,
+ 1, snd_soc_get_volsw, mt6660_component_put_volsw,
+ vol_ctl_tlv),
+ SOC_SINGLE_EXT("WDT_Enable", MT6660_REG_WDT_CTRL, 7, 1, 0,
+ snd_soc_get_volsw, mt6660_component_put_volsw),
+ SOC_SINGLE_EXT("Hard_Clip_Enable", MT6660_REG_HCLIP_CTRL, 8, 1, 0,
+ snd_soc_get_volsw, mt6660_component_put_volsw),
+ SOC_SINGLE_EXT("Clip_Enable", MT6660_REG_SPS_CTRL, 0, 1, 0,
+ snd_soc_get_volsw, mt6660_component_put_volsw),
+ SOC_SINGLE_EXT("BoostMode", MT6660_REG_BST_CTRL, 0, 3, 0,
+ snd_soc_get_volsw, mt6660_component_put_volsw),
+ SOC_SINGLE_EXT("DRE_Enable", MT6660_REG_DRE_CTRL, 0, 1, 0,
+ snd_soc_get_volsw, mt6660_component_put_volsw),
+ SOC_SINGLE_EXT("DC_Protect_Enable",
+ MT6660_REG_DC_PROTECT_CTRL, 3, 1, 0,
+ snd_soc_get_volsw, mt6660_component_put_volsw),
+ SOC_SINGLE_EXT("I2SLRS", MT6660_REG_DATAO_SEL, 6, 3, 0,
+ snd_soc_get_volsw, mt6660_component_put_volsw),
+ SOC_SINGLE_EXT("I2SDOLS", MT6660_REG_DATAO_SEL, 3, 7, 0,
+ snd_soc_get_volsw, mt6660_component_put_volsw),
+ SOC_SINGLE_EXT("I2SDORS", MT6660_REG_DATAO_SEL, 0, 7, 0,
+ snd_soc_get_volsw, mt6660_component_put_volsw),
+ /* for debug purpose */
+ SOC_SINGLE_EXT("HPF_AUD_IN_EN", MT6660_REG_HPF_CTRL, 0, 1, 0,
+ snd_soc_get_volsw, mt6660_component_put_volsw),
+ SOC_SINGLE_EXT("AUD_LOOP_BACK", MT6660_REG_PATH_BYPASS, 4, 1, 0,
+ snd_soc_get_volsw, mt6660_component_put_volsw),
+ SOC_SINGLE_EXT("Mute_Enable", MT6660_REG_SYSTEM_CTRL, 1, 1, 0,
+ snd_soc_get_volsw, mt6660_component_put_volsw),
+ SOC_SINGLE_EXT("CS_Comp_Disable", MT6660_REG_PATH_BYPASS, 2, 1, 0,
+ snd_soc_get_volsw, mt6660_component_put_volsw),
+ SOC_SINGLE_EXT("T0_SEL", MT6660_REG_CALI_T0, 0, 7, 0,
+ snd_soc_get_volsw, NULL),
+ SOC_SINGLE_EXT("Chip_Rev", SND_SOC_NOPM, 0, 16, 0,
+ mt6660_component_get_volsw, NULL),
+};
+
+
+static const struct snd_soc_component_driver mt6660_component_driver = {
+ .probe = mt6660_component_probe,
+ .remove = mt6660_component_remove,
+
+ .read = mt6660_component_io_read,
+ .write = mt6660_component_io_write,
+
+ .controls = mt6660_component_snd_controls,
+ .num_controls = ARRAY_SIZE(mt6660_component_snd_controls),
+ .dapm_widgets = mt6660_component_dapm_widgets,
+ .num_dapm_widgets = ARRAY_SIZE(mt6660_component_dapm_widgets),
+ .dapm_routes = mt6660_component_dapm_routes,
+ .num_dapm_routes = ARRAY_SIZE(mt6660_component_dapm_routes),
+
+ .set_bias_level = mt6660_component_set_bias_level,
+ .idle_bias_on = false, /* idle_bias_off = true */
+};
+
+static int mt6660_component_aif_startup(struct snd_pcm_substream *substream,
+ struct snd_soc_dai *dai)
+{
+ struct snd_soc_dapm_context *dapm =
+ snd_soc_component_get_dapm(dai->component);
+ int ret = 0;
+
+ dev_dbg(dai->dev, "%s\n", __func__);
+ if (dapm->bias_level == SND_SOC_BIAS_OFF)
+ ret = mt6660_component_set_bias_level(dai->component,
+ SND_SOC_BIAS_STANDBY);
+ return ret;
+}
+
+static int mt6660_component_aif_hw_params(struct snd_pcm_substream *substream,
+ struct snd_pcm_hw_params *hw_params, struct snd_soc_dai *dai)
+{
+ int word_len = params_physical_width(hw_params);
+ int aud_bit = params_width(hw_params);
+ u16 reg_data = 0;
+ int ret = 0;
+
+ dev_dbg(dai->dev, "%s: ++\n", __func__);
+ dev_dbg(dai->dev, "format: 0x%08x\n", params_format(hw_params));
+ dev_dbg(dai->dev, "rate: 0x%08x\n", params_rate(hw_params));
+ dev_dbg(dai->dev, "word_len: %d, aud_bit: %d\n", word_len, aud_bit);
+ if (word_len > 32 || word_len < 16) {
+ dev_err(dai->dev, "not supported word length\n");
+ return -ENOTSUPP;
+ }
+ switch (aud_bit) {
+ case 16:
+ reg_data = 3;
+ break;
+ case 18:
+ reg_data = 2;
+ break;
+ case 20:
+ reg_data = 1;
+ break;
+ case 24:
+ case 32:
+ reg_data = 0;
+ break;
+ default:
+ return -ENOTSUPP;
+ }
+ ret = snd_soc_component_update_bits(dai->component,
+ MT6660_REG_SERIAL_CFG1, 0xc0, (reg_data << 6));
+ if (ret < 0) {
+ dev_err(dai->dev, "config aud bit fail\n");
+ return ret;
+ }
+ ret = snd_soc_component_update_bits(dai->component,
+ MT6660_REG_TDM_CFG3, 0x3f0, word_len << 4);
+ if (ret < 0) {
+ dev_err(dai->dev, "config word len fail\n");
+ return ret;
+ }
+ dev_dbg(dai->dev, "%s: --\n", __func__);
+ return 0;
+}
+
+static const struct snd_soc_dai_ops mt6660_component_aif_ops = {
+ .startup = mt6660_component_aif_startup,
+ .hw_params = mt6660_component_aif_hw_params,
+};
+
+#define STUB_RATES SNDRV_PCM_RATE_8000_192000
+#define STUB_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | \
+ SNDRV_PCM_FMTBIT_U16_LE | \
+ SNDRV_PCM_FMTBIT_S24_LE | \
+ SNDRV_PCM_FMTBIT_U24_LE | \
+ SNDRV_PCM_FMTBIT_S32_LE | \
+ SNDRV_PCM_FMTBIT_U32_LE)
+
+static struct snd_soc_dai_driver mt6660_codec_dai = {
+ .name = "mt6660-aif",
+ .playback = {
+ .stream_name = "aif_playback",
+ .channels_min = 1,
+ .channels_max = 2,
+ .rates = STUB_RATES,
+ .formats = STUB_FORMATS,
+ },
+ .capture = {
+ .stream_name = "aif_capture",
+ .channels_min = 1,
+ .channels_max = 2,
+ .rates = STUB_RATES,
+ .formats = STUB_FORMATS,
+ },
+ /* dai properties */
+ .symmetric_rates = 1,
+ .symmetric_channels = 1,
+ .symmetric_samplebits = 1,
+ /* dai operations */
+ .ops = &mt6660_component_aif_ops,
+};
+
+static inline int mt6660_chip_id_check(struct i2c_client *i2c)
+{
+ u8 id[2] = {0};
+ int ret = 0;
+
+ i2c_smbus_write_byte_data(i2c, 0x03, 0x00);
+ ret = i2c_smbus_read_i2c_block_data(i2c, MT6660_REG_DEVID, 2, id);
+ if (ret < 0)
+ return ret;
+ ret = (id[0] << 8) + id[1];
+ ret &= 0x0ff0;
+ if (ret != 0x00e0 && ret != 0x01e0)
+ return -ENODEV;
+ i2c_smbus_write_byte_data(i2c, 0x03, 0x01);
+ return 0;
+}
+
+static inline int _mt6660_chip_sw_reset(struct mt6660_chip *chip)
+{
+ i2c_smbus_write_byte_data(chip->i2c, MT6660_REG_SYSTEM_CTRL, 0x80);
+ msleep(30);
+ return 0;
+}
+
+static inline int _mt6660_chip_power_on(struct mt6660_chip *chip, int on_off)
+{
+ u8 reg_data = 0;
+ int ret = 0;
+
+ ret = i2c_smbus_read_byte_data(chip->i2c, MT6660_REG_SYSTEM_CTRL);
+ if (ret < 0)
+ return ret;
+ reg_data = (u8)ret;
+ if (on_off)
+ reg_data &= (~0x01);
+ else
+ reg_data |= 0x01;
+ return i2c_smbus_write_byte_data(
+ chip->i2c, MT6660_REG_SYSTEM_CTRL, reg_data);
+}
+
+static inline int _mt6660_read_chip_revision(struct mt6660_chip *chip)
+{
+ u8 reg_data[2] = {0};
+ int ret = 0;
+
+ ret = i2c_smbus_read_i2c_block_data(
+ chip->i2c, MT6660_REG_DEVID, 2, reg_data);
+ if (ret < 0) {
+ dev_err(chip->dev, "get chip revision fail\n");
+ return ret;
+ }
+ chip->chip_rev = reg_data[1];
+ return 0;
+}
+
+int mt6660_i2c_probe(struct i2c_client *client, const struct i2c_device_id *id)
+{
+ struct mt6660_chip *chip = NULL;
+ int ret = 0;
+
+ ret = mt6660_chip_id_check(client);
+ if (ret < 0) {
+ dev_err(&client->dev, "chip id check fail\n");
+ return ret;
+ }
+ chip = devm_kzalloc(&client->dev, sizeof(*chip), GFP_KERNEL);
+ if (!chip)
+ return -ENOMEM;
+ chip->i2c = client;
+ chip->dev = &client->dev;
+ mutex_init(&chip->var_lock);
+ mutex_init(&chip->io_lock);
+ i2c_set_clientdata(client, chip);
+
+ /* chip power on */
+ ret = _mt6660_chip_power_on(chip, 1);
+ if (ret < 0) {
+ dev_err(chip->dev, "chip power on 1 fail\n");
+ goto probe_fail;
+ }
+ /* chip reset first */
+ ret = _mt6660_chip_sw_reset(chip);
+ if (ret < 0) {
+ dev_err(chip->dev, "chip reset fail\n");
+ goto probe_fail;
+ }
+ /* chip power on */
+ ret = _mt6660_chip_power_on(chip, 1);
+ if (ret < 0) {
+ dev_err(chip->dev, "chip power on 2 fail\n");
+ goto probe_fail;
+ }
+ ret = _mt6660_read_chip_revision(chip);
+ if (ret < 0) {
+ dev_err(chip->dev, "read chip revision fail\n");
+ goto probe_fail;
+ }
+ ret = mt6660_i2c_init_setting(chip);
+ if (ret < 0) {
+ dev_err(chip->dev, "chip i2c init setting fail\n");
+ goto probe_fail;
+ }
+ ret = _mt6660_chip_power_on(chip, 0);
+ if (ret < 0) {
+ dev_err(chip->dev, "chip power off fail\n");
+ goto probe_fail;
+ }
+ return snd_soc_register_component(chip->dev,
+ &mt6660_component_driver, &mt6660_codec_dai, 1);
+probe_fail:
+ mutex_destroy(&chip->var_lock);
+ return ret;
+}
+
+int mt6660_i2c_remove(struct i2c_client *client)
+{
+ struct mt6660_chip *chip = i2c_get_clientdata(client);
+
+ dev_dbg(chip->dev, "%s++\n", __func__);
+ snd_soc_unregister_component(chip->dev);
+ mutex_destroy(&chip->var_lock);
+ dev_dbg(chip->dev, "%s--\n", __func__);
+ return 0;
+}
+
+static const struct of_device_id __maybe_unused mt6660_of_id[] = {
+ { .compatible = "mediatek,mt6660",},
+ {},
+};
+MODULE_DEVICE_TABLE(of, mt6660_of_id);
+
+static const struct i2c_device_id mt6660_i2c_id[] = {
+ {"mt6660", 0 },
+ {},
+};
+MODULE_DEVICE_TABLE(i2c, mt6660_i2c_id);
+
+static struct i2c_driver mt6660_i2c_driver = {
+ .driver = {
+ .name = "mt6660",
+ .owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(mt6660_of_id),
+ },
+ .probe = mt6660_i2c_probe,
+ .remove = mt6660_i2c_remove,
+ .id_table = mt6660_i2c_id,
+};
+module_i2c_driver(mt6660_i2c_driver);
+
+MODULE_AUTHOR("Jeff Chang <jeff_chang@richtek.com");
+MODULE_DESCRIPTION("MT6660 SPKAMP Driver");
+MODULE_LICENSE("GPL");
+MODULE_VERSION("1.0.6_G");
diff --git a/sound/soc/codecs/mt6660.h b/sound/soc/codecs/mt6660.h
new file mode 100644
index 0000000..4d5cc16
--- /dev/null
+++ b/sound/soc/codecs/mt6660.h
@@ -0,0 +1,68 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2019 MediaTek Inc.
+ */
+
+#ifndef __SND_SOC_MT6660_H
+#define __SND_SOC_MT6660_H
+
+#include <linux/mutex.h>
+
+struct mt6660_chip {
+ struct i2c_client *i2c;
+ struct device *dev;
+ struct snd_soc_component *component;
+ struct platform_device *param_dev;
+ struct mutex var_lock;
+ struct mutex io_lock;
+ u16 chip_rev;
+ int pwr_cnt;
+};
+
+#define MT6660_REG_DEVID (0x00)
+#define MT6660_REG_SYSTEM_CTRL (0x03)
+#define MT6660_REG_IRQ_STATUS1 (0x05)
+#define MT6660_REG_ADDA_CLOCK (0x07)
+#define MT6660_REG_SERIAL_CFG1 (0x10)
+#define MT6660_REG_DATAO_SEL (0x12)
+#define MT6660_REG_TDM_CFG3 (0x15)
+#define MT6660_REG_HPF_CTRL (0x18)
+#define MT6660_REG_HPF1_COEF (0x1A)
+#define MT6660_REG_HPF2_COEF (0x1B)
+#define MT6660_REG_PATH_BYPASS (0x1E)
+#define MT6660_REG_WDT_CTRL (0x20)
+#define MT6660_REG_HCLIP_CTRL (0x24)
+#define MT6660_REG_VOL_CTRL (0x29)
+#define MT6660_REG_SPS_CTRL (0x30)
+#define MT6660_REG_SIGMAX (0x33)
+#define MT6660_REG_CALI_T0 (0x3F)
+#define MT6660_REG_BST_CTRL (0x40)
+#define MT6660_REG_PROTECTION_CFG (0x46)
+#define MT6660_REG_DA_GAIN (0x4c)
+#define MT6660_REG_AUDIO_IN2_SEL (0x50)
+#define MT6660_REG_SIG_GAIN (0x51)
+#define MT6660_REG_PLL_CFG1 (0x60)
+#define MT6660_REG_DRE_CTRL (0x68)
+#define MT6660_REG_DRE_THDMODE (0x69)
+#define MT6660_REG_DRE_CORASE (0x6B)
+#define MT6660_REG_PWM_CTRL (0x70)
+#define MT6660_REG_DC_PROTECT_CTRL (0x74)
+#define MT6660_REG_ADC_USB_MODE (0x7c)
+#define MT6660_REG_INTERNAL_CFG (0x88)
+#define MT6660_REG_RESV0 (0x98)
+#define MT6660_REG_RESV1 (0x99)
+#define MT6660_REG_RESV2 (0x9A)
+#define MT6660_REG_RESV3 (0x9B)
+#define MT6660_REG_RESV6 (0xA2)
+#define MT6660_REG_RESV7 (0xA3)
+#define MT6660_REG_RESV10 (0xB0)
+#define MT6660_REG_RESV11 (0xB1)
+#define MT6660_REG_RESV16 (0xB6)
+#define MT6660_REG_RESV17 (0xB7)
+#define MT6660_REG_RESV19 (0xB9)
+#define MT6660_REG_RESV21 (0xBB)
+#define MT6660_REG_RESV23 (0xBD)
+#define MT6660_REG_RESV31 (0xD3)
+#define MT6660_REG_RESV40 (0xE0)
+
+#endif /* __SND_SOC_MT6660_H */
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH V3 1/5] dt-bindings: gpu: mali-midgard: Add samsung exynos5250 compatible
From: Krzysztof Kozlowski @ 2019-09-03 7:04 UTC (permalink / raw)
To: Guillaume Gardet
Cc: linux-samsung-soc@vger.kernel.org, Kukjin Kim,
linux-arm-kernel@lists.infradead.org, Marek Szyprowski
In-Reply-To: <VE1PR08MB468570F2B6851C4CD3E80A5083B90@VE1PR08MB4685.eurprd08.prod.outlook.com>
On Tue, 3 Sep 2019 at 09:03, Guillaume Gardet <Guillaume.Gardet@arm.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Krzysztof Kozlowski <krzk@kernel.org>
> > Sent: 03 September 2019 08:56
> > To: Guillaume Gardet <Guillaume.Gardet@arm.com>
> > Cc: linux-samsung-soc@vger.kernel.org; Kukjin Kim <kgene@kernel.org>;
> > Marek Szyprowski <m.szyprowski@samsung.com>; linux-arm-
> > kernel@lists.infradead.org
> > Subject: Re: [PATCH V3 1/5] dt-bindings: gpu: mali-midgard: Add samsung
> > exynos5250 compatible
> >
> > On Mon, 2 Sep 2019 at 17:31, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > >
> > > On Fri, Aug 30, 2019 at 12:44:58PM +0200, Guillaume Gardet wrote:
> > > > Add "samsung,exynos5250-mali" binding.
> > > >
> > > > Signed-off-by: Guillaume Gardet <guillaume.gardet@arm.com>
> > > >
> > > > Cc: Kukjin Kim <kgene@kernel.org>
> > > > Cc: Krzysztof Kozlowski <krzk@kernel.org>
> > > > Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> > > > Cc: linux-arm-kernel@lists.infradead.org
> > > > ---
> > > > V3 changes:
> > > > * add dt-bindings before node in device tree
> > > > V2 changes:
> > > > * new file
> > > >
> > > > Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt | 1 +
> > >
> > > Thanks, entire set applied (with re-ordering and minor description
> > > changes).
> >
> > Hi Guillaume,
>
> Hi,
>
> >
> > I applied yesterday entire patchset but this dt-bindings patch causes big
> > merge conflict which will not be reasonable to resolve by Linus.
> > Can you rebase this patch on top of latest linux-next? Basically you would
> > need to add respective entries to new YAML file:
> > Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml
> >
> > Send it to regular dt-bindings maintainers (scripts/get_maintainers.pl).
>
> IIUC, I just need to resend this patch (1/5) rebased to use yaml, instead of txt, no need to resend other patches, right?
Yes, correct. Just remember to send it to proper maintainers (previous
one skipped DT guys).
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH V3 1/5] dt-bindings: gpu: mali-midgard: Add samsung exynos5250 compatible
From: Guillaume Gardet @ 2019-09-03 7:02 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-samsung-soc@vger.kernel.org, Kukjin Kim,
linux-arm-kernel@lists.infradead.org, Marek Szyprowski
In-Reply-To: <CAJKOXPe8QDzDoM4sKva0qrVUA7EMTR7FO5jGut+Paw9mAcdfAw@mail.gmail.com>
> -----Original Message-----
> From: Krzysztof Kozlowski <krzk@kernel.org>
> Sent: 03 September 2019 08:56
> To: Guillaume Gardet <Guillaume.Gardet@arm.com>
> Cc: linux-samsung-soc@vger.kernel.org; Kukjin Kim <kgene@kernel.org>;
> Marek Szyprowski <m.szyprowski@samsung.com>; linux-arm-
> kernel@lists.infradead.org
> Subject: Re: [PATCH V3 1/5] dt-bindings: gpu: mali-midgard: Add samsung
> exynos5250 compatible
>
> On Mon, 2 Sep 2019 at 17:31, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >
> > On Fri, Aug 30, 2019 at 12:44:58PM +0200, Guillaume Gardet wrote:
> > > Add "samsung,exynos5250-mali" binding.
> > >
> > > Signed-off-by: Guillaume Gardet <guillaume.gardet@arm.com>
> > >
> > > Cc: Kukjin Kim <kgene@kernel.org>
> > > Cc: Krzysztof Kozlowski <krzk@kernel.org>
> > > Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> > > Cc: linux-arm-kernel@lists.infradead.org
> > > ---
> > > V3 changes:
> > > * add dt-bindings before node in device tree
> > > V2 changes:
> > > * new file
> > >
> > > Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt | 1 +
> >
> > Thanks, entire set applied (with re-ordering and minor description
> > changes).
>
> Hi Guillaume,
Hi,
>
> I applied yesterday entire patchset but this dt-bindings patch causes big
> merge conflict which will not be reasonable to resolve by Linus.
> Can you rebase this patch on top of latest linux-next? Basically you would
> need to add respective entries to new YAML file:
> Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml
>
> Send it to regular dt-bindings maintainers (scripts/get_maintainers.pl).
IIUC, I just need to resend this patch (1/5) rebased to use yaml, instead of txt, no need to resend other patches, right?
Regards,
Guillaume
>
> Best regards,
> Krzysztof
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] crypto: arm64: Use PTR_ERR_OR_ZERO rather than its implementation.
From: zhong jiang @ 2019-09-03 6:54 UTC (permalink / raw)
To: herbert, davem, catalin.marinas
Cc: zhongjiang, will, linux-crypto, linux-arm-kernel, linux-kernel
PTR_ERR_OR_ZERO contains if(IS_ERR(...)) + PTR_ERR. It is better to
use it directly. hence just replace it.
Signed-off-by: zhong jiang <zhongjiang@huawei.com>
---
arch/arm64/crypto/aes-glue.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/arm64/crypto/aes-glue.c b/arch/arm64/crypto/aes-glue.c
index ca0c84d..2a2e0a3 100644
--- a/arch/arm64/crypto/aes-glue.c
+++ b/arch/arm64/crypto/aes-glue.c
@@ -409,10 +409,8 @@ static int essiv_cbc_init_tfm(struct crypto_skcipher *tfm)
struct crypto_aes_essiv_cbc_ctx *ctx = crypto_skcipher_ctx(tfm);
ctx->hash = crypto_alloc_shash("sha256", 0, 0);
- if (IS_ERR(ctx->hash))
- return PTR_ERR(ctx->hash);
- return 0;
+ return PTR_ERR_OR_ZERO(ctx->hash);
}
static void essiv_cbc_exit_tfm(struct crypto_skcipher *tfm)
--
1.7.12.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH V3 1/5] dt-bindings: gpu: mali-midgard: Add samsung exynos5250 compatible
From: Krzysztof Kozlowski @ 2019-09-03 6:56 UTC (permalink / raw)
To: Guillaume Gardet
Cc: linux-samsung-soc@vger.kernel.org, Kukjin Kim, linux-arm-kernel,
Marek Szyprowski
In-Reply-To: <20190902153146.GB9289@kozik-lap>
On Mon, 2 Sep 2019 at 17:31, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On Fri, Aug 30, 2019 at 12:44:58PM +0200, Guillaume Gardet wrote:
> > Add "samsung,exynos5250-mali" binding.
> >
> > Signed-off-by: Guillaume Gardet <guillaume.gardet@arm.com>
> >
> > Cc: Kukjin Kim <kgene@kernel.org>
> > Cc: Krzysztof Kozlowski <krzk@kernel.org>
> > Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> > Cc: linux-arm-kernel@lists.infradead.org
> > ---
> > V3 changes:
> > * add dt-bindings before node in device tree
> > V2 changes:
> > * new file
> >
> > Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt | 1 +
>
> Thanks, entire set applied (with re-ordering and minor description
> changes).
Hi Guillaume,
I applied yesterday entire patchset but this dt-bindings patch causes
big merge conflict which will not be reasonable to resolve by Linus.
Can you rebase this patch on top of latest linux-next? Basically you
would need to add respective entries to new YAML file:
Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml
Send it to regular dt-bindings maintainers (scripts/get_maintainers.pl).
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH V2 1/5] dt-bindings: fsl: scu: add scu power key binding
From: Anson Huang @ 2019-09-03 6:55 UTC (permalink / raw)
To: Oleksij Rempel, robh+dt@kernel.org, mark.rutland@arm.com,
shawnguo@kernel.org, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com,
catalin.marinas@arm.com, will@kernel.org,
dmitry.torokhov@gmail.com, Aisheng Dong, ulf.hansson@linaro.org,
Andy Duan, Peng Fan, Daniel Baluta, Leonard Crestez,
mripard@kernel.org, olof@lixom.net, arnd@arndb.de,
jagan@amarulasolutions.com, bjorn.andersson@linaro.org,
dinguyen@kernel.org, marcin.juszkiewicz@linaro.org,
stefan@agner.ch, gregkh@linuxfoundation.org,
andriy.shevchenko@linux.intel.com, yuehaibing@huawei.com,
tglx@linutronix.de, ronald@innovation.ch, m.felsch@pengutronix.de,
Jacky Bai, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-input@vger.kernel.org
Cc: dl-linux-imx
In-Reply-To: <7c3b6ae3-9f22-11f8-2464-79d02ac656f3@pengutronix.de>
Hi, Oleksij
> On 03.09.19 08:37, Anson Huang wrote:
> > Hi, Oleksij
> >
> >> On 03.09.19 16:03, Anson Huang wrote:
> >>> NXP i.MX8QXP is an ARMv8 SoC with a Cortex-M4 core inside as system
> >>> controller, the system controller is in charge of system power,
> >>> clock and power key event etc. management, Linux kernel has to
> >>> communicate with system controller via MU (message unit) IPC to get
> >>> power key event, add binding doc for i.MX system controller power key
> driver.
> >>>
> >>> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> >>> ---
> >>> Changes since V1:
> >>> - remove "wakeup-source" property, as it is NOT needed for SCU
> >> interrupt;
> >>> - remove "status" in example.
> >>> ---
> >>> .../devicetree/bindings/arm/freescale/fsl,scu.txt | 14
> >> ++++++++++++++
> >>> 1 file changed, 14 insertions(+)
> >>>
> >>> diff --git
> >>> a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> >>> b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> >>> index c149fad..f93e2e4 100644
> >>> --- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> >>> +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> >>> @@ -157,6 +157,15 @@ Required properties:
> >>> Optional properties:
> >>> - timeout-sec: contains the watchdog timeout in seconds.
> >>>
> >>> +Power key bindings based on SCU Message Protocol
> >>> +------------------------------------------------------------
> >>> +
> >>> +Required properties:
> >>> +- compatible: should be:
> >>> + "fsl,imx8qxp-sc-pwrkey"
> >>> + followed by "fsl,imx-sc-pwrkey";
> >>> +- linux,keycodes: See
> >>> +Documentation/devicetree/bindings/input/keys.txt
> >>
> >> linux,keycodes is required parameter. So, this kay cab be anything.
> >> Why the compatible is called pwrkey? Probably it is better to call it "*-sc-
> key"
> >
> > This key is kind of special, it is ON/OFF button which is designed for
> > power key purpose, it has HW function such as long pressing it would
> > shutdown the system power, so we always use it as power key, NOT
> general key, does it make sense?
>
> I assume, OF devs will argue: DT is describing hardware not software.
> On other hand, software will get notification about assertion/deassertion of
> this key. So, it is just normal key. If, for some reason, it will trigger world
> destruction, if it is pressed too long... probably no body cares.
> You can provide fsl,imx-sc-key as additional compatible. In case linux will
> need some quirks, we still can fall back to more precise compatible
> "fsl,imx8qxp-sc-pwrkey".
I am OK with that, so I will use "fsl,imx-sc-key" as additional compatible and also
present in driver.
Anson.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 5/5] iommu: virt: Use iommu_put_resv_regions_simple()
From: Christoph Hellwig @ 2019-09-03 6:54 UTC (permalink / raw)
To: Thierry Reding
Cc: Jean-Philippe Brucker, Robin Murphy, Joerg Roedel, linux-kernel,
virtualization, iommu, Will Deacon, David Woodhouse,
linux-arm-kernel
In-Reply-To: <20190829111752.17513-6-thierry.reding@gmail.com>
I think the subject should say virtio instead of virt.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/3] ASoC: xlnx: add Xilinx logicPD-I2S FPGA IP support
From: Michal Simek @ 2019-09-03 6:51 UTC (permalink / raw)
To: Miquel Raynal, Michal Simek
Cc: Mark Rutland, devicetree, alsa-devel,
Maruthi Srinivas Bayyavarapu, Takashi Iwai, Rob Herring,
Liam Girdwood, Mark Brown, Thomas Petazzoni, praveenv,
Jaroslav Kysela, alexandre, linux-arm-kernel
In-Reply-To: <20190902222111.045ede17@xps13>
On 02. 09. 19 22:21, Miquel Raynal wrote:
> Hi Michal,
>
> Michal Simek <michal.simek@xilinx.com> wrote on Mon, 2 Sep 2019
> 09:39:11 +0200:
>
>> Hi Miquel
>>
>> On 30. 08. 19 23:06, Miquel Raynal wrote:
>>> This IP is very simple so this driver manage both the DAI and the PCM
>>> streams, hence the presence of both components in this driver.
>>>
>>> There are plenty available interruptions when capturing or playing
>>> back audio that can be triggered but the only one that fits the ALSA
>>> sound system is the XFER_DONE which is used to bound sound
>>> periods. Other interrupts are masked. Please note that capture and
>>> playback are not possible at the same time though.
>>>
>>> Capture seems to work (at least it creates a file with something
>>> inside) but I have no capture mechanism on the board to actually test
>>> that it works correctly.
>>>
>>> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
>>> ---
>>>
>>> Hello,
>>>
>>> This is my first contribution in the sound subsystem, I hope I've
>>> understood the core but I might be entirely wrong as well, so please
>>> do not hesitate to be critical on my choices.
>>>
>>> Thanks,
>>> Miquèl
>>>
>>> sound/soc/xilinx/Kconfig | 7 +
>>> sound/soc/xilinx/Makefile | 2 +
>>> sound/soc/xilinx/xlnx-logicpd-i2s.c | 468 ++++++++++++++++++++++++++++
>>
>> What IP is this?
>> https://www.xilinx.com/products/intellectual-property/audio-i2s.html
>>
>> https://github.com/Xilinx/linux-xlnx/blob/master/sound/soc/xilinx/xlnx_i2s.c
>>
>> Anyway I am adding Praveen and Maruthi to take a look.
>
> Actually I have been tricked by a datasheet with the wrong title: this
> is a LogicPD IP, it is not from Xilinx. I will resubmit with a new
> driver name/compatible and add the relevant people.
ok. Great.
M
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 4/4] arm64: dts: add support for A1 based Amlogic AD401
From: Jianxin Pan @ 2019-09-03 6:51 UTC (permalink / raw)
To: Kevin Hilman, linux-amlogic
Cc: devicetree, Hanjie Lin, Victor Wan, Jianxin Pan, Neil Armstrong,
Martin Blumenstingl, linux-kernel, Qiufang Dai, Rob Herring,
Jian Hu, Xingyu Chen, Carlo Caione, Tao Zeng, linux-arm-kernel,
Jerome Brunet
In-Reply-To: <1567493475-75451-1-git-send-email-jianxin.pan@amlogic.com>
Add basic support for the Amlogic A1 based Amlogic AD401 board:
which describe components as follows: Reserve Memory, CPU, GIC, IRQ,
Timer, UART. It's capable of booting up into the serial console.
Signed-off-by: Jianxin Pan <jianxin.pan@amlogic.com>
---
arch/arm64/boot/dts/amlogic/Makefile | 1 +
arch/arm64/boot/dts/amlogic/meson-a1-ad401.dts | 30 ++++++
arch/arm64/boot/dts/amlogic/meson-a1.dtsi | 121 +++++++++++++++++++++++++
3 files changed, 152 insertions(+)
create mode 100644 arch/arm64/boot/dts/amlogic/meson-a1-ad401.dts
create mode 100644 arch/arm64/boot/dts/amlogic/meson-a1.dtsi
diff --git a/arch/arm64/boot/dts/amlogic/Makefile b/arch/arm64/boot/dts/amlogic/Makefile
index edbf128..1720c45 100644
--- a/arch/arm64/boot/dts/amlogic/Makefile
+++ b/arch/arm64/boot/dts/amlogic/Makefile
@@ -36,3 +36,4 @@ dtb-$(CONFIG_ARCH_MESON) += meson-gxm-rbox-pro.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-gxm-vega-s96.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-sm1-sei610.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-sm1-khadas-vim3l.dtb
+dtb-$(CONFIG_ARCH_MESON) += meson-a1-ad401.dtb
diff --git a/arch/arm64/boot/dts/amlogic/meson-a1-ad401.dts b/arch/arm64/boot/dts/amlogic/meson-a1-ad401.dts
new file mode 100644
index 00000000..3c05cc0
--- /dev/null
+++ b/arch/arm64/boot/dts/amlogic/meson-a1-ad401.dts
@@ -0,0 +1,30 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 Amlogic, Inc. All rights reserved.
+ */
+
+/dts-v1/;
+
+#include "meson-a1.dtsi"
+
+/ {
+ compatible = "amlogic,ad401", "amlogic,a1";
+ model = "Amlogic Meson A1 AD401 Development Board";
+
+ aliases {
+ serial0 = &uart_AO_B;
+ };
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+ memory@0 {
+ device_type = "memory";
+ linux,usable-memory = <0x0 0x0 0x0 0x8000000>;
+ };
+};
+
+&uart_AO_B {
+ status = "okay";
+ /*pinctrl-0 = <&uart_ao_a_pins>;*/
+ /*pinctrl-names = "default";*/
+};
diff --git a/arch/arm64/boot/dts/amlogic/meson-a1.dtsi b/arch/arm64/boot/dts/amlogic/meson-a1.dtsi
new file mode 100644
index 00000000..b98d648
--- /dev/null
+++ b/arch/arm64/boot/dts/amlogic/meson-a1.dtsi
@@ -0,0 +1,121 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 Amlogic, Inc. All rights reserved.
+ */
+
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/ {
+ compatible = "amlogic,a1";
+
+ interrupt-parent = <&gic>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ cpus {
+ #address-cells = <0x2>;
+ #size-cells = <0x0>;
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a35";
+ reg = <0x0 0x0>;
+ enable-method = "psci";
+ next-level-cache = <&l2>;
+ };
+
+ cpu1: cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a35";
+ reg = <0x0 0x1>;
+ enable-method = "psci";
+ next-level-cache = <&l2>;
+ };
+
+ l2: l2-cache0 {
+ compatible = "cache";
+ };
+ };
+ psci {
+ compatible = "arm,psci-1.0";
+ method = "smc";
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ linux,cma {
+ compatible = "shared-dma-pool";
+ reusable;
+ size = <0x0 0x800000>;
+ alignment = <0x0 0x400000>;
+ linux,cma-default;
+ };
+ };
+
+ sm: secure-monitor {
+ compatible = "amlogic,meson-gxbb-sm";
+ };
+
+ soc {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ uart_AO: serial@fe001c00 {
+ compatible = "amlogic,meson-gx-uart",
+ "amlogic,meson-ao-uart";
+ reg = <0x0 0xfe001c00 0x0 0x18>;
+ interrupts = <GIC_SPI 25 IRQ_TYPE_EDGE_RISING>;
+ clocks = <&xtal>, <&xtal>, <&xtal>;
+ clock-names = "xtal", "pclk", "baud";
+ status = "disabled";
+ };
+
+ uart_AO_B: serial@fe002000 {
+ compatible = "amlogic,meson-gx-uart",
+ "amlogic,meson-ao-uart";
+ reg = <0x0 0xfe002000 0x0 0x18>;
+ interrupts = <GIC_SPI 26 IRQ_TYPE_EDGE_RISING>;
+ clocks = <&xtal>, <&xtal>, <&xtal>;
+ clock-names = "xtal", "pclk", "baud";
+ status = "disabled";
+ };
+
+ gic: interrupt-controller@ff901000 {
+ compatible = "arm,gic-400";
+ reg = <0x0 0xff901000 0x0 0x1000>,
+ <0x0 0xff902000 0x0 0x2000>,
+ <0x0 0xff904000 0x0 0x2000>,
+ <0x0 0xff906000 0x0 0x2000>;
+ interrupt-controller;
+ interrupts = <GIC_PPI 9
+ (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_HIGH)>;
+ #interrupt-cells = <3>;
+ #address-cells = <0>;
+ };
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupts = <GIC_PPI 13
+ (GIC_CPU_MASK_RAW(0xff) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 14
+ (GIC_CPU_MASK_RAW(0xff) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 11
+ (GIC_CPU_MASK_RAW(0xff) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 10
+ (GIC_CPU_MASK_RAW(0xff) | IRQ_TYPE_LEVEL_LOW)>;
+ };
+
+ xtal: xtal-clk {
+ compatible = "fixed-clock";
+ clock-frequency = <24000000>;
+ clock-output-names = "xtal";
+ #clock-cells = <0>;
+ };
+};
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 -next] iommu/arm-smmu-v3: Fix build error without CONFIG_PCI_ATS
From: YueHaibing @ 2019-09-03 6:50 UTC (permalink / raw)
To: will, robin.murphy, joro
Cc: iommu, YueHaibing, linux-kernel, linux-arm-kernel
In-Reply-To: <20190903024212.20300-1-yuehaibing@huawei.com>
If CONFIG_PCI_ATS is not set, building fails:
drivers/iommu/arm-smmu-v3.c: In function arm_smmu_ats_supported:
drivers/iommu/arm-smmu-v3.c:2325:35: error: struct pci_dev has no member named ats_cap; did you mean msi_cap?
return !pdev->untrusted && pdev->ats_cap;
^~~~~~~
ats_cap should only used when CONFIG_PCI_ATS is defined,
so use #ifdef block to guard this.
Fixes: bfff88ec1afe ("iommu/arm-smmu-v3: Rework enabling/disabling of ATS for PCI masters")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
v2: Add arm_smmu_ats_supported() of no CONFIG_PCI_ATS
---
drivers/iommu/arm-smmu-v3.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index 66bf641..8da93e7 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -2311,6 +2311,7 @@ static void arm_smmu_install_ste_for_dev(struct arm_smmu_master *master)
}
}
+#ifdef CONFIG_PCI_ATS
static bool arm_smmu_ats_supported(struct arm_smmu_master *master)
{
struct pci_dev *pdev;
@@ -2324,6 +2325,12 @@ static bool arm_smmu_ats_supported(struct arm_smmu_master *master)
pdev = to_pci_dev(master->dev);
return !pdev->untrusted && pdev->ats_cap;
}
+#else
+static bool arm_smmu_ats_supported(struct arm_smmu_master *master)
+{
+ return false;
+}
+#endif
static void arm_smmu_enable_ats(struct arm_smmu_master *master)
{
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 3/4] dt-bindings: arm: amlogic: add Amlogic AD401 bindings
From: Jianxin Pan @ 2019-09-03 6:51 UTC (permalink / raw)
To: Kevin Hilman, linux-amlogic
Cc: devicetree, Hanjie Lin, Victor Wan, Jianxin Pan, Neil Armstrong,
Martin Blumenstingl, linux-kernel, Qiufang Dai, Rob Herring,
Jian Hu, Xingyu Chen, Carlo Caione, Tao Zeng, linux-arm-kernel,
Jerome Brunet
In-Reply-To: <1567493475-75451-1-git-send-email-jianxin.pan@amlogic.com>
Add the compatible for the Amlogic A1 Based AD401 board.
Signed-off-by: Jianxin Pan <jianxin.pan@amlogic.com>
---
Documentation/devicetree/bindings/arm/amlogic.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml
index aa07b76..dc4abce 100644
--- a/Documentation/devicetree/bindings/arm/amlogic.yaml
+++ b/Documentation/devicetree/bindings/arm/amlogic.yaml
@@ -158,5 +158,7 @@ properties:
- description: Boards with the Amlogic Meson A1 A113L SoC
items:
+ - enum:
+ - amlogic,ad401
- const: amlogic,a1
...
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/4] dt-bindings: arm: amlogic: add A1 bindings
From: Jianxin Pan @ 2019-09-03 6:51 UTC (permalink / raw)
To: Kevin Hilman, linux-amlogic
Cc: devicetree, Hanjie Lin, Victor Wan, Jianxin Pan, Neil Armstrong,
Martin Blumenstingl, linux-kernel, Qiufang Dai, Rob Herring,
Jian Hu, Xingyu Chen, Carlo Caione, Tao Zeng, linux-arm-kernel,
Jerome Brunet
In-Reply-To: <1567493475-75451-1-git-send-email-jianxin.pan@amlogic.com>
Add bindings for the new Amlogic A1 SoC family.
A1 is an application processor designed for smart audio and IoT applications,
with dual core Cortex-A35.
Signed-off-by: Jianxin Pan <jianxin.pan@amlogic.com>
---
Documentation/devicetree/bindings/arm/amlogic.yaml | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml
index b48ea1e..aa07b76 100644
--- a/Documentation/devicetree/bindings/arm/amlogic.yaml
+++ b/Documentation/devicetree/bindings/arm/amlogic.yaml
@@ -155,4 +155,8 @@ properties:
- seirobotics,sei610
- khadas,vim3l
- const: amlogic,sm1
+
+ - description: Boards with the Amlogic Meson A1 A113L SoC
+ items:
+ - const: amlogic,a1
...
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/4] soc: amlogic: meson-gx-socinfo: Add A1 and A113L IDs
From: Jianxin Pan @ 2019-09-03 6:51 UTC (permalink / raw)
To: Kevin Hilman, linux-amlogic
Cc: devicetree, Hanjie Lin, Victor Wan, Jianxin Pan, Neil Armstrong,
Martin Blumenstingl, linux-kernel, Qiufang Dai, Rob Herring,
Jian Hu, Xingyu Chen, Carlo Caione, Tao Zeng, linux-arm-kernel,
Jerome Brunet
In-Reply-To: <1567493475-75451-1-git-send-email-jianxin.pan@amlogic.com>
Add the SoC IDs for the A113L Amlogic A1 SoC.
Signed-off-by: Jianxin Pan <jianxin.pan@amlogic.com>
---
drivers/soc/amlogic/meson-gx-socinfo.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/soc/amlogic/meson-gx-socinfo.c b/drivers/soc/amlogic/meson-gx-socinfo.c
index 6d0d04f..3c86d8d 100644
--- a/drivers/soc/amlogic/meson-gx-socinfo.c
+++ b/drivers/soc/amlogic/meson-gx-socinfo.c
@@ -40,6 +40,7 @@ static const struct meson_gx_soc_id {
{ "G12A", 0x28 },
{ "G12B", 0x29 },
{ "SM1", 0x2b },
+ { "A1", 0x2c },
};
static const struct meson_gx_package_id {
@@ -68,6 +69,7 @@ static const struct meson_gx_package_id {
{ "S922X", 0x29, 0x40, 0xf0 },
{ "A311D", 0x29, 0x10, 0xf0 },
{ "S905X3", 0x2b, 0x5, 0xf },
+ { "A113L", 0x2c, 0x0, 0xf8 },
};
static inline unsigned int socinfo_to_major(u32 socinfo)
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 0/4] arm64: Add basic support for Amlogic A1 SoC Family
From: Jianxin Pan @ 2019-09-03 6:51 UTC (permalink / raw)
To: Kevin Hilman, linux-amlogic
Cc: devicetree, Hanjie Lin, Victor Wan, Jianxin Pan, Neil Armstrong,
Martin Blumenstingl, linux-kernel, Qiufang Dai, Rob Herring,
Jian Hu, Xingyu Chen, Carlo Caione, Tao Zeng, linux-arm-kernel,
Jerome Brunet
A1 is an application processor designed for smart audio and IoT applications,
with Dual core ARM Cortex-A35 CPU. Unlike the previous GXL and G12 series,
there is no Cortex-M3 AO CPU in it.
This serial add basic support for the Amlogic A1 based Amlogic AD401 board:
which describe components as follows: Reserve Memory, CPU, GIC, IRQ,
Timer, UART. It's capable of booting up into the serial console.
The pclk for uart_AO_B need to be fixed once A1 clock driver is merged.
In this version, it rely on bootloader to enable the pclk gate
Jianxin Pan (4):
soc: amlogic: meson-gx-socinfo: Add A1 and A113L IDs
dt-bindings: arm: amlogic: add A1 bindings
dt-bindings: arm: amlogic: add Amlogic AD401 bindings
arm64: dts: add support for A1 based Amlogic AD401
Documentation/devicetree/bindings/arm/amlogic.yaml | 6 +
arch/arm64/boot/dts/amlogic/Makefile | 1 +
arch/arm64/boot/dts/amlogic/meson-a1-ad401.dts | 30 +++++
arch/arm64/boot/dts/amlogic/meson-a1.dtsi | 121 +++++++++++++++++++++
drivers/soc/amlogic/meson-gx-socinfo.c | 2 +
5 files changed, 160 insertions(+)
create mode 100644 arch/arm64/boot/dts/amlogic/meson-a1-ad401.dts
create mode 100644 arch/arm64/boot/dts/amlogic/meson-a1.dtsi
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH V2 2/5] input: keyboard: imx_sc: Add i.MX system controller power key support
From: Anson Huang @ 2019-09-03 6:48 UTC (permalink / raw)
To: Oleksij Rempel, robh+dt@kernel.org, mark.rutland@arm.com,
shawnguo@kernel.org, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com,
catalin.marinas@arm.com, will@kernel.org,
dmitry.torokhov@gmail.com, Aisheng Dong, ulf.hansson@linaro.org,
Andy Duan, Peng Fan, Daniel Baluta, Leonard Crestez,
mripard@kernel.org, olof@lixom.net, arnd@arndb.de,
jagan@amarulasolutions.com, bjorn.andersson@linaro.org,
dinguyen@kernel.org, marcin.juszkiewicz@linaro.org,
stefan@agner.ch, gregkh@linuxfoundation.org,
andriy.shevchenko@linux.intel.com, yuehaibing@huawei.com,
tglx@linutronix.de, ronald@innovation.ch, m.felsch@pengutronix.de,
Jacky Bai, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-input@vger.kernel.org
Cc: dl-linux-imx
In-Reply-To: <6d8dd5df-02da-b4cd-e61d-a4a15d0bf0c8@pengutronix.de>
Hi, Oleksij
> On 03.09.19 16:03, Anson Huang wrote:
> > i.MX8QXP is an ARMv8 SoC which has a Cortex-M4 system controller
> > inside, the system controller is in charge of controlling power, clock
> > and power key etc..
> >
> > Adds i.MX system controller power key driver support, Linux kernel has
> > to communicate with system controller via MU (message unit) IPC to get
> > power key's status.
> >
> > Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> > ---
> > Changes since V1:
> > - remove "wakeup-source" property operation, scu power key uses
> generic scu irq,
> > no need to have this property for device wakeup operation.
> > ---
> > drivers/input/keyboard/Kconfig | 7 ++
> > drivers/input/keyboard/Makefile | 1 +
> > drivers/input/keyboard/imx_sc_pwrkey.c | 169
> +++++++++++++++++++++++++++++++++
> > 3 files changed, 177 insertions(+)
> > create mode 100644 drivers/input/keyboard/imx_sc_pwrkey.c
> >
> > diff --git a/drivers/input/keyboard/Kconfig
> > b/drivers/input/keyboard/Kconfig index 2e6d288..3aaeb9c 100644
> > --- a/drivers/input/keyboard/Kconfig
> > +++ b/drivers/input/keyboard/Kconfig
> > @@ -469,6 +469,13 @@ config KEYBOARD_IMX
> > To compile this driver as a module, choose M here: the
> > module will be called imx_keypad.
> >
> > +config KEYBOARD_IMX_SC_PWRKEY
> > + tristate "IMX SCU Power Key Driver"
> > + depends on IMX_SCU
> > + help
> > + This is the system controller powerkey driver for NXP i.MX SoCs with
> > + system controller inside.
>
> The KEY is configurable over devicetree, why is it called PWRKEY? It looks for
> me as generic SCU key handler.
We always use it as power key, NOT a generic key, as it has HW function designed
for power key purpose.
>
> > config KEYBOARD_NEWTON
> > tristate "Newton keyboard"
> > select SERIO
> > diff --git a/drivers/input/keyboard/Makefile
> > b/drivers/input/keyboard/Makefile index 9510325..9ea5585 100644
> > --- a/drivers/input/keyboard/Makefile
> > +++ b/drivers/input/keyboard/Makefile
> > @@ -29,6 +29,7 @@ obj-$(CONFIG_KEYBOARD_HIL) += hil_kbd.o
> > obj-$(CONFIG_KEYBOARD_HIL_OLD) += hilkbd.o
> > obj-$(CONFIG_KEYBOARD_IPAQ_MICRO) += ipaq-micro-keys.o
> > obj-$(CONFIG_KEYBOARD_IMX) += imx_keypad.o
> > +obj-$(CONFIG_KEYBOARD_IMX_SC_PWRKEY) += imx_sc_pwrkey.o
> > obj-$(CONFIG_KEYBOARD_HP6XX) += jornada680_kbd.o
> > obj-$(CONFIG_KEYBOARD_HP7XX) += jornada720_kbd.o
> > obj-$(CONFIG_KEYBOARD_LKKBD) += lkkbd.o
> > diff --git a/drivers/input/keyboard/imx_sc_pwrkey.c
> > b/drivers/input/keyboard/imx_sc_pwrkey.c
> > new file mode 100644
> > index 0000000..53aa9a4
> > --- /dev/null
> > +++ b/drivers/input/keyboard/imx_sc_pwrkey.c
> > @@ -0,0 +1,169 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright 2019 NXP.
> > + */
> > +
> > +#include <linux/device.h>
> > +#include <linux/err.h>
> > +#include <linux/firmware/imx/sci.h>
> > +#include <linux/init.h>
> > +#include <linux/input.h>
> > +#include <linux/interrupt.h>
> > +#include <linux/jiffies.h>
> > +#include <linux/kernel.h>
> > +#include <linux/module.h>
> > +#include <linux/of.h>
> > +#include <linux/of_address.h>
> > +#include <linux/platform_device.h>
> > +
> > +#define DEBOUNCE_TIME 100
> > +#define REPEAT_INTERVAL 60
> > +
> > +#define SC_IRQ_BUTTON 1
> > +#define SC_IRQ_GROUP_WAKE 3
> > +#define IMX_SC_MISC_FUNC_GET_BUTTON_STATUS 18
> > +
> > +struct imx_pwrkey_drv_data {
> > + int keycode;
> > + bool keystate; /* 1: pressed, 0: release */
> > + bool delay_check;
> > + struct delayed_work check_work;
> > + struct input_dev *input;
> > +};
> > +
> > +struct imx_sc_msg_pwrkey {
> > + struct imx_sc_rpc_msg hdr;
> > + u8 state;
> > +};
> > +static struct imx_pwrkey_drv_data *pdata;
>
> Why is it global struct? It seems to be flexible configurable over devicetree.
> So I would assume it should be able to handle more then one button. Please
> remove global variables, make it allocatable per OF node.
There is ONLY one button available for SC key, but yes, I think I can make the structure
private and get all necessary data from the structure using container_of.
>
> Please use different name "pdata" is usually used as platform data. Please,
> use "priv".
OK.
>
> > +static struct imx_sc_ipc *pwrkey_ipc_handle;
>
> same as before, no global variables.
Will move it into private platform data structure.
>
> > +
> > +static int imx_sc_pwrkey_notify(struct notifier_block *nb,
> > + unsigned long event, void *group) {
> > + if ((event & SC_IRQ_BUTTON) && (*(u8 *)group ==
> SC_IRQ_GROUP_WAKE)
> > + && !pdata->delay_check) {
> > + pdata->delay_check = 1;
> > + schedule_delayed_work(&pdata->check_work,
> > + msecs_to_jiffies(REPEAT_INTERVAL));
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static void imx_sc_check_for_events(struct work_struct *work) {
> > + struct input_dev *input = pdata->input;
> > + struct imx_sc_msg_pwrkey msg;
> > + struct imx_sc_rpc_msg *hdr = &msg.hdr;
> > + bool state;
> > +
> > + hdr->ver = IMX_SC_RPC_VERSION;
> > + hdr->svc = IMX_SC_RPC_SVC_MISC;
> > + hdr->func = IMX_SC_MISC_FUNC_GET_BUTTON_STATUS;
> > + hdr->size = 1;
> > +
> > + /*
> > + * Current SCU firmware does NOT have return value for
> > + * this API, that means it is always successful.
> > + */
>
> It is not true for the kernel part:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Felixir.
> bootlin.com%2Flinux%2Flatest%2Fsource%2Fdrivers%2Ffirmware%2Fimx%2F
> imx-
> scu.c%23L157&data=02%7C01%7Canson.huang%40nxp.com%7C7a5ed3
> ef3b2541e61be808d7303810a9%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C
> 0%7C0%7C637030889669489141&sdata=d3uw6x6WCPeavJu3QYf9o9cxx
> Rx4mJar04fQFLF9EhE%3D&reserved=0
>
> imx_scu_call_rpc() may fail in different ways and provide proper error value.
> Please use it.
There are about 3 APIs are special, this API is one of them, this API has no return value
from SCU FW API, but it has response data from it, so that means if we set the response
to false, the stack will be free and mailbox will have NULL pointer issue when response
data passed from SCU FW. If we set the response to true, as the SCU FW has no return value,
the return value will be the msg->func which will be already failed, that is why we have to skip
the return value check. This is one restriction/bug of SCU FW, we will notify SCU FW owner to
fix/improve.
>
> > + imx_scu_call_rpc(pwrkey_ipc_handle, &msg, true); > + state =
> msg.state;
>
> the conversation u8 to bool should be done here.
OK.
>
> > +
> > + if (!state && !pdata->keystate)
> > + state = true;
> > +
> > + if (state ^ pdata->keystate) {
> > + pm_wakeup_event(input->dev.parent, 0);
> > + pdata->keystate = !!state;
>
> the state is already bool. Why do you need extra
> conversations?
Will remove it.
>
> > + input_event(input, EV_KEY, pdata->keycode, !!state);
>
> same here.
Will remove it.
>
> > + input_sync(input);
> > + if (!state)
> > + pdata->delay_check = 0;
> > + pm_relax(pdata->input->dev.parent);
> > + }
> > +
> > + if (state)
> > + schedule_delayed_work(&pdata->check_work,
> > + msecs_to_jiffies(DEBOUNCE_TIME)); }
> > +
> > +static struct notifier_block imx_sc_pwrkey_notifier = {
> > + .notifier_call = imx_sc_pwrkey_notify, };
> > +
> > +static int imx_sc_pwrkey_probe(struct platform_device *pdev) {
> > + struct device_node *np = pdev->dev.of_node;
> > + struct input_dev *input;
> > + int ret;
> > +
> > + ret = imx_scu_get_handle(&pwrkey_ipc_handle);
> > + if (ret)
> > + return ret;
> > +
> > + pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
> > + if (!pdata)
> > + return -ENOMEM;
> > +
> > + if (of_property_read_u32(np, "linux,keycode", &pdata->keycode) > +
> pdata->keycode = KEY_POWER;
>
> According binding documentation, linux,keycode is requered parameter, in
> this case you should fail if it is not set.
Agreed, will add it in V3.
Thanks,
Anson.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V2 1/5] dt-bindings: fsl: scu: add scu power key binding
From: Oleksij Rempel @ 2019-09-03 6:47 UTC (permalink / raw)
To: Anson Huang, robh+dt@kernel.org, mark.rutland@arm.com,
shawnguo@kernel.org, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com,
catalin.marinas@arm.com, will@kernel.org,
dmitry.torokhov@gmail.com, Aisheng Dong, ulf.hansson@linaro.org,
Andy Duan, Peng Fan, Daniel Baluta, Leonard Crestez,
mripard@kernel.org, olof@lixom.net, arnd@arndb.de,
jagan@amarulasolutions.com, bjorn.andersson@linaro.org,
dinguyen@kernel.org, marcin.juszkiewicz@linaro.org,
stefan@agner.ch, gregkh@linuxfoundation.org,
andriy.shevchenko@linux.intel.com, yuehaibing@huawei.com,
tglx@linutronix.de, ronald@innovation.ch, m.felsch@pengutronix.de,
Jacky Bai, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-input@vger.kernel.org
Cc: dl-linux-imx
In-Reply-To: <DB3PR0402MB391656FC3603B30300ADBF27F5B90@DB3PR0402MB3916.eurprd04.prod.outlook.com>
On 03.09.19 08:37, Anson Huang wrote:
> Hi, Oleksij
>
>> On 03.09.19 16:03, Anson Huang wrote:
>>> NXP i.MX8QXP is an ARMv8 SoC with a Cortex-M4 core inside as system
>>> controller, the system controller is in charge of system power, clock
>>> and power key event etc. management, Linux kernel has to communicate
>>> with system controller via MU (message unit) IPC to get power key
>>> event, add binding doc for i.MX system controller power key driver.
>>>
>>> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
>>> ---
>>> Changes since V1:
>>> - remove "wakeup-source" property, as it is NOT needed for SCU
>> interrupt;
>>> - remove "status" in example.
>>> ---
>>> .../devicetree/bindings/arm/freescale/fsl,scu.txt | 14
>> ++++++++++++++
>>> 1 file changed, 14 insertions(+)
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
>>> b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
>>> index c149fad..f93e2e4 100644
>>> --- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
>>> +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
>>> @@ -157,6 +157,15 @@ Required properties:
>>> Optional properties:
>>> - timeout-sec: contains the watchdog timeout in seconds.
>>>
>>> +Power key bindings based on SCU Message Protocol
>>> +------------------------------------------------------------
>>> +
>>> +Required properties:
>>> +- compatible: should be:
>>> + "fsl,imx8qxp-sc-pwrkey"
>>> + followed by "fsl,imx-sc-pwrkey";
>>> +- linux,keycodes: See
>>> +Documentation/devicetree/bindings/input/keys.txt
>>
>> linux,keycodes is required parameter. So, this kay cab be anything. Why the
>> compatible is called pwrkey? Probably it is better to call it "*-sc-key"
>
> This key is kind of special, it is ON/OFF button which is designed for power key
> purpose, it has HW function such as long pressing it would shutdown the system power,
> so we always use it as power key, NOT general key, does it make sense?
I assume, OF devs will argue: DT is describing hardware not software.
On other hand, software will get notification about assertion/deassertion of this key. So,
it is just normal key. If, for some reason, it will trigger world destruction, if it is
pressed too long... probably no body cares.
You can provide fsl,imx-sc-key as additional compatible. In case linux will need some
quirks, we still can fall back to more precise compatible "fsl,imx8qxp-sc-pwrkey".
Kind regards,
Oleksij Rempel
--
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 |
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH V2 4/4] platform: mtk-isp: Add Mediatek FD driver
From: Jerry-ch Chen @ 2019-09-03 6:44 UTC (permalink / raw)
To: Tomasz Figa
Cc: devicetree@vger.kernel.org, Sean Cheng (鄭昇弘),
laurent.pinchart+renesas@ideasonboard.com,
Rynn Wu (吳育恩), srv_heupstream,
Po-Yang Huang (黃柏陽), mchehab@kernel.org,
suleiman@chromium.org, shik@chromium.org,
Jungo Lin (林明俊),
Sj Huang (黃信璋), yuzhao@chromium.org,
linux-mediatek@lists.infradead.org, zwisler@chromium.org,
matthias.bgg@gmail.com, Christie Yu (游雅惠),
Frederic Chen (陳俊元), hans.verkuil@cisco.com,
linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org
In-Reply-To: <CAAFQd5AGgeFbto6V1KkL0dp1QPziOKV3pWQDU2OJ+S1QKvnBdg@mail.gmail.com>
On Tue, 2019-09-03 at 13:19 +0800, Tomasz Figa wrote:
> On Mon, Sep 2, 2019 at 8:47 PM Jerry-ch Chen <Jerry-ch.Chen@mediatek.com> wrote:
> >
> > Hi Tomasz,
> >
> > On Fri, 2019-08-30 at 16:33 +0800, Tomasz Figa wrote:
> > > On Wed, Aug 28, 2019 at 11:00 AM Jerry-ch Chen
> > > <Jerry-ch.Chen@mediatek.com> wrote:
> > > >
> > > > Hi Tomasz,
> > > >
> > > > On Mon, 2019-08-26 at 14:36 +0800, Tomasz Figa wrote:
> > > > > Hi Jerry,
> > > > >
> > > > > On Sun, Aug 25, 2019 at 6:18 PM Jerry-ch Chen
> > > > > <Jerry-ch.Chen@mediatek.com> wrote:
> > > > > >
> > > > > > Hi Tomasz,
> > > > > >
> > > > > > On Fri, 2019-08-02 at 16:28 +0800, Tomasz Figa wrote:
> > > > > > > Hi Jerry,
> > > > > > >
> > > > > > > On Tue, Jul 09, 2019 at 04:41:12PM +0800, Jerry-ch Chen wrote:
> [snip]
> > > > static int mtk_fd_vb2_queue_setup(struct vb2_queue *vq,
> > > > unsigned int *num_buffers,
> > > > unsigned int *num_planes,
> > > > unsigned int sizes[],
> > > > struct device *alloc_devs[])
> > > > {
> > > > struct mtk_fd_ctx *ctx = vb2_get_drv_priv(vq);
> > > > struct device *dev = ctx->dev;
> > > > unsigned int size[2];
> > > >
> > > > switch (vq->type) {
> > > > case V4L2_BUF_TYPE_META_CAPTURE:
> > > > size[0] = ctx->dst_fmt.buffersize;
> > > > break;
> > > > case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE:
> > > > size[0] = ctx->src_fmt.plane_fmt[0].sizeimage;
> > > > if (*num_planes == 2)
> > > > size[1] = ctx->src_fmt.plane_fmt[1].sizeimage;
> > > > break;
> > > > }
> > > >
> > > > if (*num_planes == 1) {
> > > > if (sizes[0] < size[0])
> > > > return -EINVAL;
> > > > } else if (*num_planes == 2) {
> > > > if ((sizes[0] < size[0]) && (sizes[1] < size[1]))
> > > > return -EINVAL;
> > >
> > > Can we just use a loop here and combine the 2 cases above?
> > >
> > > Also, we need to fail with -EINVAL if *num_planes is > 2.
> > >
> > > > } else {
> > > > *num_planes = 1;
> > > > sizes[0] = size[0];
> > >
> > > This should be the case if *num_planes == 0 and the number of planes
> > > and sizes should match the currently active format.
> > >
> > I appreciate your comments,
> >
> > Ok, I will update as following:
> > static int mtk_fd_vb2_queue_setup(struct vb2_queue *vq,
> > unsigned int *num_buffers,
> > unsigned int *num_planes,
> > unsigned int sizes[],
> > struct device *alloc_devs[])
> > {
> > struct mtk_fd_ctx *ctx = vb2_get_drv_priv(vq);
> > unsigned int size[2];
> > unsigned int plane;
> >
> > switch (vq->type) {
> > case V4L2_BUF_TYPE_META_CAPTURE:
> > size[0] = ctx->dst_fmt.buffersize;
> > break;
> > case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE:
> > size[0] = ctx->src_fmt.plane_fmt[0].sizeimage;
> > if (*num_planes == 2)
> > size[1] = ctx->src_fmt.plane_fmt[1].sizeimage;
> > break;
> > }
> >
> > if (*num_planes > 2)
> > return -EINVAL;
> > if (*num_planes == 0) {
> > if (vq->type == V4L2_BUF_TYPE_META_CAPTURE) {
> > sizes[0] = ctx->dst_fmt.buffersize;
> > *num_planes = 1;
> > return 0;
> > }
> >
> > *num_planes = ctx->src_fmt.num_planes;
> > for (plane = 0; plane < *num_planes; plane++)
> > sizes[plane] = ctx->src_fmt.plane_fmt[plane].sizeimage;
> > return 0;
> > }
> >
> > for (plane = 0; plane < *num_planes; plane++) {
> > if(sizes[plane] < size[plane])
> > return -EINVAL;
> > }
> > return 0;
> > }
> >
>
> Looks good, thanks!
>
> > > > }
> > > >
> > > > return 0;
> > > > }
> > > >
> > > > > [snip]
> > > > >
> > > > > > > > +static void mtk_fd_vb2_stop_streaming(struct vb2_queue *vq)
> > > > > > > > +{
> > > > > > > > + struct mtk_fd_ctx *ctx = vb2_get_drv_priv(vq);
> > > > > > > > + struct vb2_buffer *vb;
> > > > > > >
> > > > > > > How do we guarantee here that the hardware isn't still accessing the buffers
> > > > > > > removed below?
> > > > > > >
> > > > > > Maybe we can check the driver state flag and aborting the unfinished
> > > > > > jobs?
> > > > > > (fd_hw->state == FD_ENQ)
> > > > > >
> > > > >
> > > > > Yes, we need to either cancel or wait for the currently processing
> > > > > job. It depends on hardware capabilities, but cancelling is generally
> > > > > preferred for the lower latency.
> > > > >
> > > > Ok, it the state is ENQ, then we can disable the FD hw by controlling
> > > > the registers.
> > > >
> > > > for example:
> > > > writel(0x0, fd->fd_base + FD_HW_ENABLE);
> > > > writel(0x0, fd->fd_base + FD_INT_EN);
> > > >
> > >
> > > What's exactly the effect of writing 0 to FD_HW_ENABLE?
> > >
> > Sorry, my last reply didn't solve the question,
> > we should implement a mtk_fd_job_abort() for v4l2_m2m_ops().
> >
> > which is able to readl_poll_timeout_atomic()
> > and check the HW busy bits in the register FD_INT_EN;
> >
> > if they are not cleared until timeout, we could handle the last
> > processing job.
> > Otherwise, the FD irq handler should have handled the last processing
> > job and we could continue the stop_streaming().
> >
> > For job_abort():
> > static void mtk_fd_job_abort(void *priv)
> > {
> > struct mtk_fd_ctx *ctx = priv;
> > struct mtk_fd_dev *fd = ctx->fd_dev;
> > u32 val;
> > u32 ret;
> >
> > ret = readl_poll_timeout_atomic(fd->fd_base + MTK_FD_REG_OFFSET_INT_EN,
> > val,
> > (val & MTK_FD_HW_BUSY_MASK) ==
> > MTK_FD_HW_STATE_IS_BUSY,
> > USEC_PER_MSEC, MTK_FD_STOP_HW_TIMEOUT);
>
> Hmm, would it be possible to avoid the busy wait by having a
> completion that could be signalled from the interrupt handler?
>
> Best regards,
> Tomasz
I suppose that would be wakeup a wait queue in the interrupt handler,
the the wait_event_interrupt_timeout() will be used in here and system
suspend e.g. mtk_fd_suspend().
Or do you suggest to wait_event_interrupt_timeout() every frame in the
mtk_fd_ipi_handler()?
I think maybe the readl_poll_timeout_atomic would be good enough.
One more thing, for the mtk_fd_video_device_register()
Sorry that I would need to use intermediate variable here since the 80
columns check.
function = MEDIA_ENT_F_PROC_VIDEO_STATISTICS;
ret = v4l2_m2m_register_media_controller(m2m_dev, vfd, function);
if (ret) {
dev_err(dev, "Failed to init mem2mem media controller\n");
goto err_unreg_video;
}
Thanks and Best regards,
Jerry
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: "Rework enabling/disabling of ATS for PCI masters" failed to compile on arm64
From: Will Deacon @ 2019-09-03 6:40 UTC (permalink / raw)
To: Qian Cai
Cc: iommu, Joerg Roedel, Robin Murphy, linux-kernel, linux-arm-kernel
In-Reply-To: <63FF6963-E1D9-4C65-AD2E-0E4938D08584@lca.pw>
On Mon, Sep 02, 2019 at 10:10:30PM -0400, Qian Cai wrote:
> The linux-next commit “iommu/arm-smmu-v3: Rework enabling/disabling of ATS for PCI masters” [1] causes a compilation error when PCI_ATS=n on arm64.
>
> [1] https://lore.kernel.org/linux-iommu/20190820154549.17018-3-will@kernel.org/
>
> drivers/iommu/arm-smmu-v3.c:2325:35: error: no member named 'ats_cap' in 'struct pci_dev'
> return !pdev->untrusted && pdev->ats_cap;
> ~~~~ ^
>
> For example,
>
> Symbol: PCI_ATS [=n]
> │ Type : bool
> │ Defined at drivers/pci/Kconfig:118
> │ Depends on: PCI [=y]
> │ Selected by [n]:
> │ - PCI_IOV [=n] && PCI [=y]
> │ - PCI_PRI [=n] && PCI [=y]│
> │ - PCI_PASID [=n] && PCI [=y] │
> │ - AMD_IOMMU [=n] && IOMMU_SUPPORT [=y] && X86_64 && PCI [=y] && ACPI [=y]
https://lkml.kernel.org/r/20190903063028.6ryuk5dmaohi2fqa@willie-the-truck
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 03/10] arm64: atomics: avoid out-of-line ll/sc atomics
From: Will Deacon @ 2019-09-03 6:39 UTC (permalink / raw)
To: Nathan Chancellor
Cc: mark.rutland, peterz, catalin.marinas, ndesaulniers,
Ard.Biesheuvel, andrew.murray, robin.murphy, linux-arm-kernel
In-Reply-To: <20190903060011.GA60737@archlinux-threadripper>
On Mon, Sep 02, 2019 at 11:00:11PM -0700, Nathan Chancellor wrote:
> On Thu, Aug 29, 2019 at 04:48:27PM +0100, Will Deacon wrote:
> > From: Andrew Murray <andrew.murray@arm.com>
> >
> > When building for LSE atomics (CONFIG_ARM64_LSE_ATOMICS), if the hardware
> > or toolchain doesn't support it the existing code will fallback to ll/sc
> > atomics. It achieves this by branching from inline assembly to a function
> > that is built with special compile flags. Further this results in the
> > clobbering of registers even when the fallback isn't used increasing
> > register pressure.
> >
> > Improve this by providing inline implementations of both LSE and
> > ll/sc and use a static key to select between them, which allows for the
> > compiler to generate better atomics code. Put the LL/SC fallback atomics
> > in their own subsection to improve icache performance.
> >
> > Signed-off-by: Andrew Murray <andrew.murray@arm.com>
> > Signed-off-by: Will Deacon <will@kernel.org>
>
> For some reason, this causes a clang built kernel to fail to boot in
> QEMU. There are no logs, it just never starts. I am off for the next two
> days so I am going to try to look into this but you might have some
> immediate ideas.
Hmm, so unfortunately this series isn't bisectable, since I realised this
when I was merging the patches from Andrew, hence this:
https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/commit/?h=for-next/atomics&id=b32baf91f60fb9c7010bff87e68132f2ce31d9a8
so if you're seeing a failure with the whole branch, this commit is probably
just a red herring.
> There is another weird failure that might be somewhat related but I have
> no idea.
>
> https://github.com/ClangBuiltLinux/linux/issues/648
Interesting. Looks like KASAN is causing a cmpxchg() call on something
which isn't 1, 2, 4 or 8 bytes in size :/
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH V2 1/5] dt-bindings: fsl: scu: add scu power key binding
From: Anson Huang @ 2019-09-03 6:37 UTC (permalink / raw)
To: Oleksij Rempel, robh+dt@kernel.org, mark.rutland@arm.com,
shawnguo@kernel.org, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com,
catalin.marinas@arm.com, will@kernel.org,
dmitry.torokhov@gmail.com, Aisheng Dong, ulf.hansson@linaro.org,
Andy Duan, Peng Fan, Daniel Baluta, Leonard Crestez,
mripard@kernel.org, olof@lixom.net, arnd@arndb.de,
jagan@amarulasolutions.com, bjorn.andersson@linaro.org,
dinguyen@kernel.org, marcin.juszkiewicz@linaro.org,
stefan@agner.ch, gregkh@linuxfoundation.org,
andriy.shevchenko@linux.intel.com, yuehaibing@huawei.com,
tglx@linutronix.de, ronald@innovation.ch, m.felsch@pengutronix.de,
Jacky Bai, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-input@vger.kernel.org
Cc: dl-linux-imx
In-Reply-To: <21d2e400-976a-35c3-6875-4cc0c476fdf2@pengutronix.de>
Hi, Oleksij
> On 03.09.19 16:03, Anson Huang wrote:
> > NXP i.MX8QXP is an ARMv8 SoC with a Cortex-M4 core inside as system
> > controller, the system controller is in charge of system power, clock
> > and power key event etc. management, Linux kernel has to communicate
> > with system controller via MU (message unit) IPC to get power key
> > event, add binding doc for i.MX system controller power key driver.
> >
> > Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> > ---
> > Changes since V1:
> > - remove "wakeup-source" property, as it is NOT needed for SCU
> interrupt;
> > - remove "status" in example.
> > ---
> > .../devicetree/bindings/arm/freescale/fsl,scu.txt | 14
> ++++++++++++++
> > 1 file changed, 14 insertions(+)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> > b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> > index c149fad..f93e2e4 100644
> > --- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> > +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> > @@ -157,6 +157,15 @@ Required properties:
> > Optional properties:
> > - timeout-sec: contains the watchdog timeout in seconds.
> >
> > +Power key bindings based on SCU Message Protocol
> > +------------------------------------------------------------
> > +
> > +Required properties:
> > +- compatible: should be:
> > + "fsl,imx8qxp-sc-pwrkey"
> > + followed by "fsl,imx-sc-pwrkey";
> > +- linux,keycodes: See
> > +Documentation/devicetree/bindings/input/keys.txt
>
> linux,keycodes is required parameter. So, this kay cab be anything. Why the
> compatible is called pwrkey? Probably it is better to call it "*-sc-key"
This key is kind of special, it is ON/OFF button which is designed for power key
purpose, it has HW function such as long pressing it would shutdown the system power,
so we always use it as power key, NOT general key, does it make sense?
Thanks,
Anson.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH -next] iommu/arm-smmu-v3: Fix build error without CONFIG_PCI_ATS
From: Yuehaibing @ 2019-09-03 6:34 UTC (permalink / raw)
To: Will Deacon; +Cc: joro, robin.murphy, iommu, linux-arm-kernel, linux-kernel
In-Reply-To: <20190903063028.6ryuk5dmaohi2fqa@willie-the-truck>
On 2019/9/3 14:30, Will Deacon wrote:
> On Tue, Sep 03, 2019 at 10:42:12AM +0800, YueHaibing wrote:
>> If CONFIG_PCI_ATS is not set, building fails:
>>
>> drivers/iommu/arm-smmu-v3.c: In function arm_smmu_ats_supported:
>> drivers/iommu/arm-smmu-v3.c:2325:35: error: struct pci_dev has no member named ats_cap; did you mean msi_cap?
>> return !pdev->untrusted && pdev->ats_cap;
>> ^~~~~~~
>>
>> ats_cap should only used when CONFIG_PCI_ATS is defined,
>> so use #ifdef block to guard this.
>>
>> Fixes: bfff88ec1afe ("iommu/arm-smmu-v3: Rework enabling/disabling of ATS for PCI masters")
>> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
>> ---
>> drivers/iommu/arm-smmu-v3.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
>> index 66bf641..44ac9ac 100644
>> --- a/drivers/iommu/arm-smmu-v3.c
>> +++ b/drivers/iommu/arm-smmu-v3.c
>> @@ -2313,7 +2313,7 @@ static void arm_smmu_install_ste_for_dev(struct arm_smmu_master *master)
>>
>> static bool arm_smmu_ats_supported(struct arm_smmu_master *master)
>> {
>> - struct pci_dev *pdev;
>> + struct pci_dev *pdev __maybe_unused;
>> struct arm_smmu_device *smmu = master->smmu;
>> struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(master->dev);
>>
>> @@ -2321,8 +2321,10 @@ static bool arm_smmu_ats_supported(struct arm_smmu_master *master)
>> !(fwspec->flags & IOMMU_FWSPEC_PCI_RC_ATS) || pci_ats_disabled())
>> return false;
>>
>> +#ifdef CONFIG_PCI_ATS
>> pdev = to_pci_dev(master->dev);
>> return !pdev->untrusted && pdev->ats_cap;
>> +#endif
>> }
>
> Hmm, I really don't like the missing return statement here, even though we
> never get this far thanks to the feature not getting set during ->probe().
> I'd actually prefer just to duplicate the function:
>
> #ifndef CONFIG_PCI_ATS
> static bool
> arm_smmu_ats_supported(struct arm_smmu_master *master) { return false; }
> #else
> <current code here>
> #endif
>
> Can you send a v2 like that, please?
Ok, will send v2 as your suggestion.
>
> Will
>
> .
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V2 1/5] dt-bindings: fsl: scu: add scu power key binding
From: Oleksij Rempel @ 2019-09-03 6:32 UTC (permalink / raw)
To: Anson Huang, robh+dt, mark.rutland, shawnguo, s.hauer, kernel,
festevam, catalin.marinas, will, dmitry.torokhov, aisheng.dong,
ulf.hansson, fugang.duan, peng.fan, daniel.baluta,
leonard.crestez, mripard, olof, arnd, jagan, bjorn.andersson,
dinguyen, marcin.juszkiewicz, stefan, gregkh, andriy.shevchenko,
yuehaibing, tglx, ronald, m.felsch, ping.bai, devicetree,
linux-kernel, linux-arm-kernel, linux-input
Cc: Linux-imx
In-Reply-To: <1567519424-32271-1-git-send-email-Anson.Huang@nxp.com>
On 03.09.19 16:03, Anson Huang wrote:
> NXP i.MX8QXP is an ARMv8 SoC with a Cortex-M4 core inside as
> system controller, the system controller is in charge of system
> power, clock and power key event etc. management, Linux kernel
> has to communicate with system controller via MU (message unit)
> IPC to get power key event, add binding doc for i.MX system
> controller power key driver.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> Changes since V1:
> - remove "wakeup-source" property, as it is NOT needed for SCU interrupt;
> - remove "status" in example.
> ---
> .../devicetree/bindings/arm/freescale/fsl,scu.txt | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> index c149fad..f93e2e4 100644
> --- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> @@ -157,6 +157,15 @@ Required properties:
> Optional properties:
> - timeout-sec: contains the watchdog timeout in seconds.
>
> +Power key bindings based on SCU Message Protocol
> +------------------------------------------------------------
> +
> +Required properties:
> +- compatible: should be:
> + "fsl,imx8qxp-sc-pwrkey"
> + followed by "fsl,imx-sc-pwrkey";
> +- linux,keycodes: See Documentation/devicetree/bindings/input/keys.txt
linux,keycodes is required parameter. So, this kay cab be anything. Why the compatible is
called pwrkey? Probably it is better to call it "*-sc-key"
> +
> Example (imx8qxp):
> -------------
> aliases {
> @@ -220,6 +229,11 @@ firmware {
> compatible = "fsl,imx8qxp-sc-rtc";
> };
>
> + scu_pwrkey: scu-pwrkey {
> + compatible = "fsl,imx8qxp-sc-pwrkey", "fsl,imx-sc-pwrkey";
> + linux,keycode = <KEY_POWER>;
> + };
> +
> watchdog {
> compatible = "fsl,imx8qxp-sc-wdt", "fsl,imx-sc-wdt";
> timeout-sec = <60>;
>
Kind regards,
Oleksij Rempel
--
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 |
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH -next] iommu/arm-smmu-v3: Fix build error without CONFIG_PCI_ATS
From: Will Deacon @ 2019-09-03 6:30 UTC (permalink / raw)
To: YueHaibing; +Cc: joro, robin.murphy, iommu, linux-arm-kernel, linux-kernel
In-Reply-To: <20190903024212.20300-1-yuehaibing@huawei.com>
On Tue, Sep 03, 2019 at 10:42:12AM +0800, YueHaibing wrote:
> If CONFIG_PCI_ATS is not set, building fails:
>
> drivers/iommu/arm-smmu-v3.c: In function arm_smmu_ats_supported:
> drivers/iommu/arm-smmu-v3.c:2325:35: error: struct pci_dev has no member named ats_cap; did you mean msi_cap?
> return !pdev->untrusted && pdev->ats_cap;
> ^~~~~~~
>
> ats_cap should only used when CONFIG_PCI_ATS is defined,
> so use #ifdef block to guard this.
>
> Fixes: bfff88ec1afe ("iommu/arm-smmu-v3: Rework enabling/disabling of ATS for PCI masters")
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> ---
> drivers/iommu/arm-smmu-v3.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
> index 66bf641..44ac9ac 100644
> --- a/drivers/iommu/arm-smmu-v3.c
> +++ b/drivers/iommu/arm-smmu-v3.c
> @@ -2313,7 +2313,7 @@ static void arm_smmu_install_ste_for_dev(struct arm_smmu_master *master)
>
> static bool arm_smmu_ats_supported(struct arm_smmu_master *master)
> {
> - struct pci_dev *pdev;
> + struct pci_dev *pdev __maybe_unused;
> struct arm_smmu_device *smmu = master->smmu;
> struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(master->dev);
>
> @@ -2321,8 +2321,10 @@ static bool arm_smmu_ats_supported(struct arm_smmu_master *master)
> !(fwspec->flags & IOMMU_FWSPEC_PCI_RC_ATS) || pci_ats_disabled())
> return false;
>
> +#ifdef CONFIG_PCI_ATS
> pdev = to_pci_dev(master->dev);
> return !pdev->untrusted && pdev->ats_cap;
> +#endif
> }
Hmm, I really don't like the missing return statement here, even though we
never get this far thanks to the feature not getting set during ->probe().
I'd actually prefer just to duplicate the function:
#ifndef CONFIG_PCI_ATS
static bool
arm_smmu_ats_supported(struct arm_smmu_master *master) { return false; }
#else
<current code here>
#endif
Can you send a v2 like that, please?
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V2 2/5] input: keyboard: imx_sc: Add i.MX system controller power key support
From: Oleksij Rempel @ 2019-09-03 6:29 UTC (permalink / raw)
To: Anson Huang, robh+dt, mark.rutland, shawnguo, s.hauer, kernel,
festevam, catalin.marinas, will, dmitry.torokhov, aisheng.dong,
ulf.hansson, fugang.duan, peng.fan, daniel.baluta,
leonard.crestez, mripard, olof, arnd, jagan, bjorn.andersson,
dinguyen, marcin.juszkiewicz, stefan, gregkh, andriy.shevchenko,
yuehaibing, tglx, ronald, m.felsch, ping.bai, devicetree,
linux-kernel, linux-arm-kernel, linux-input
Cc: Linux-imx
In-Reply-To: <1567519424-32271-2-git-send-email-Anson.Huang@nxp.com>
Hi,
On 03.09.19 16:03, Anson Huang wrote:
> i.MX8QXP is an ARMv8 SoC which has a Cortex-M4 system controller
> inside, the system controller is in charge of controlling power,
> clock and power key etc..
>
> Adds i.MX system controller power key driver support, Linux kernel
> has to communicate with system controller via MU (message unit) IPC
> to get power key's status.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> Changes since V1:
> - remove "wakeup-source" property operation, scu power key uses generic scu irq,
> no need to have this property for device wakeup operation.
> ---
> drivers/input/keyboard/Kconfig | 7 ++
> drivers/input/keyboard/Makefile | 1 +
> drivers/input/keyboard/imx_sc_pwrkey.c | 169 +++++++++++++++++++++++++++++++++
> 3 files changed, 177 insertions(+)
> create mode 100644 drivers/input/keyboard/imx_sc_pwrkey.c
>
> diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
> index 2e6d288..3aaeb9c 100644
> --- a/drivers/input/keyboard/Kconfig
> +++ b/drivers/input/keyboard/Kconfig
> @@ -469,6 +469,13 @@ config KEYBOARD_IMX
> To compile this driver as a module, choose M here: the
> module will be called imx_keypad.
>
> +config KEYBOARD_IMX_SC_PWRKEY
> + tristate "IMX SCU Power Key Driver"
> + depends on IMX_SCU
> + help
> + This is the system controller powerkey driver for NXP i.MX SoCs with
> + system controller inside.
The KEY is configurable over devicetree, why is it called PWRKEY? It looks for me as
generic SCU key handler.
> config KEYBOARD_NEWTON
> tristate "Newton keyboard"
> select SERIO
> diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
> index 9510325..9ea5585 100644
> --- a/drivers/input/keyboard/Makefile
> +++ b/drivers/input/keyboard/Makefile
> @@ -29,6 +29,7 @@ obj-$(CONFIG_KEYBOARD_HIL) += hil_kbd.o
> obj-$(CONFIG_KEYBOARD_HIL_OLD) += hilkbd.o
> obj-$(CONFIG_KEYBOARD_IPAQ_MICRO) += ipaq-micro-keys.o
> obj-$(CONFIG_KEYBOARD_IMX) += imx_keypad.o
> +obj-$(CONFIG_KEYBOARD_IMX_SC_PWRKEY) += imx_sc_pwrkey.o
> obj-$(CONFIG_KEYBOARD_HP6XX) += jornada680_kbd.o
> obj-$(CONFIG_KEYBOARD_HP7XX) += jornada720_kbd.o
> obj-$(CONFIG_KEYBOARD_LKKBD) += lkkbd.o
> diff --git a/drivers/input/keyboard/imx_sc_pwrkey.c b/drivers/input/keyboard/imx_sc_pwrkey.c
> new file mode 100644
> index 0000000..53aa9a4
> --- /dev/null
> +++ b/drivers/input/keyboard/imx_sc_pwrkey.c
> @@ -0,0 +1,169 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright 2019 NXP.
> + */
> +
> +#include <linux/device.h>
> +#include <linux/err.h>
> +#include <linux/firmware/imx/sci.h>
> +#include <linux/init.h>
> +#include <linux/input.h>
> +#include <linux/interrupt.h>
> +#include <linux/jiffies.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/platform_device.h>
> +
> +#define DEBOUNCE_TIME 100
> +#define REPEAT_INTERVAL 60
> +
> +#define SC_IRQ_BUTTON 1
> +#define SC_IRQ_GROUP_WAKE 3
> +#define IMX_SC_MISC_FUNC_GET_BUTTON_STATUS 18
> +
> +struct imx_pwrkey_drv_data {
> + int keycode;
> + bool keystate; /* 1: pressed, 0: release */
> + bool delay_check;
> + struct delayed_work check_work;
> + struct input_dev *input;
> +};
> +
> +struct imx_sc_msg_pwrkey {
> + struct imx_sc_rpc_msg hdr;
> + u8 state;
> +};
> +static struct imx_pwrkey_drv_data *pdata;
Why is it global struct? It seems to be flexible configurable over devicetree. So I would
assume it should be able to handle more then one button. Please remove global variables,
make it allocatable per OF node.
Please use different name "pdata" is usually used as platform data. Please, use "priv".
> +static struct imx_sc_ipc *pwrkey_ipc_handle;
same as before, no global variables.
> +
> +static int imx_sc_pwrkey_notify(struct notifier_block *nb,
> + unsigned long event, void *group)
> +{
> + if ((event & SC_IRQ_BUTTON) && (*(u8 *)group == SC_IRQ_GROUP_WAKE)
> + && !pdata->delay_check) {
> + pdata->delay_check = 1;
> + schedule_delayed_work(&pdata->check_work,
> + msecs_to_jiffies(REPEAT_INTERVAL));
> + }
> +
> + return 0;
> +}
> +
> +static void imx_sc_check_for_events(struct work_struct *work)
> +{
> + struct input_dev *input = pdata->input;
> + struct imx_sc_msg_pwrkey msg;
> + struct imx_sc_rpc_msg *hdr = &msg.hdr;
> + bool state;
> +
> + hdr->ver = IMX_SC_RPC_VERSION;
> + hdr->svc = IMX_SC_RPC_SVC_MISC;
> + hdr->func = IMX_SC_MISC_FUNC_GET_BUTTON_STATUS;
> + hdr->size = 1;
> +
> + /*
> + * Current SCU firmware does NOT have return value for
> + * this API, that means it is always successful.
> + */
It is not true for the kernel part:
https://elixir.bootlin.com/linux/latest/source/drivers/firmware/imx/imx-scu.c#L157
imx_scu_call_rpc() may fail in different ways and provide proper error value. Please use it.
> + imx_scu_call_rpc(pwrkey_ipc_handle, &msg, true); > + state = msg.state;
the conversation u8 to bool should be done here.
> +
> + if (!state && !pdata->keystate)
> + state = true;
> +
> + if (state ^ pdata->keystate) {
> + pm_wakeup_event(input->dev.parent, 0);
> + pdata->keystate = !!state;
the state is already bool. Why do you need extra conversations?
> + input_event(input, EV_KEY, pdata->keycode, !!state);
same here.
> + input_sync(input);
> + if (!state)
> + pdata->delay_check = 0;
> + pm_relax(pdata->input->dev.parent);
> + }
> +
> + if (state)
> + schedule_delayed_work(&pdata->check_work,
> + msecs_to_jiffies(DEBOUNCE_TIME));
> +}
> +
> +static struct notifier_block imx_sc_pwrkey_notifier = {
> + .notifier_call = imx_sc_pwrkey_notify,
> +};
> +
> +static int imx_sc_pwrkey_probe(struct platform_device *pdev)
> +{
> + struct device_node *np = pdev->dev.of_node;
> + struct input_dev *input;
> + int ret;
> +
> + ret = imx_scu_get_handle(&pwrkey_ipc_handle);
> + if (ret)
> + return ret;
> +
> + pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
> + if (!pdata)
> + return -ENOMEM;
> +
> + if (of_property_read_u32(np, "linux,keycode", &pdata->keycode) > + pdata->keycode = KEY_POWER;
According binding documentation, linux,keycode is requered parameter, in this case you
should fail if it is not set.
> + dev_warn(&pdev->dev, "KEY_POWER without setting in dts\n");
> + }
> +
> + INIT_DELAYED_WORK(&pdata->check_work, imx_sc_check_for_events);
> +
> + input = devm_input_allocate_device(&pdev->dev);
> + if (!input) {
> + dev_err(&pdev->dev, "failed to allocate the input device\n");
> + return -ENOMEM;
> + }
> +
> + input->name = pdev->name;
> + input->phys = "imx-sc-pwrkey/input0";
> + input->id.bustype = BUS_HOST;
> +
> + input_set_capability(input, EV_KEY, pdata->keycode);
> +
> + ret = input_register_device(input);
> + if (ret < 0) {
> + dev_err(&pdev->dev, "failed to register input device\n");
> + return ret;
> + }
> +
> + pdata->input = input;
> + platform_set_drvdata(pdev, pdata);
> +
> + ret = imx_scu_irq_group_enable(SC_IRQ_GROUP_WAKE, SC_IRQ_BUTTON, true);
> + if (ret) {
> + dev_warn(&pdev->dev, "enable scu group irq failed\n");
> + return ret;
> + }
> +
> + ret = imx_scu_irq_register_notifier(&imx_sc_pwrkey_notifier);
> + if (ret) {
> + imx_scu_irq_group_enable(SC_IRQ_GROUP_WAKE, SC_IRQ_BUTTON, false);
> + dev_warn(&pdev->dev, "register scu notifier failed\n");
> + }
> +
> + return ret;
> +}
> +
> +static const struct of_device_id imx_sc_pwrkey_ids[] = {
> + { .compatible = "fsl,imx-sc-pwrkey" },
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, imx_sc_pwrkey_ids);
> +
> +static struct platform_driver imx_sc_pwrkey_driver = {
> + .driver = {
> + .name = "imx-sc-pwrkey",
> + .of_match_table = imx_sc_pwrkey_ids,
> + },
> + .probe = imx_sc_pwrkey_probe,
> +};
> +module_platform_driver(imx_sc_pwrkey_driver);
> +
> +MODULE_AUTHOR("Anson Huang <Anson.Huang@nxp.com>");
> +MODULE_DESCRIPTION("i.MX System Controller Power Key Driver");
> +MODULE_LICENSE("GPL v2");
>
Kind regards,
Oleksij Rempel
--
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 |
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/1] arm64: dts: qcom: Add Lenovo Yoga C630
From: Lee Jones @ 2019-09-03 6:21 UTC (permalink / raw)
To: Bjorn Andersson
Cc: mark.rutland, devicetree, linux-arm-msm, linux-kernel, robh+dt,
agross, linux-arm-kernel
In-Reply-To: <20190903062040.GC26880@dell>
On Tue, 03 Sep 2019, Lee Jones wrote:
> On Mon, 02 Sep 2019, Bjorn Andersson wrote:
>
> > On Mon 02 Sep 06:24 PDT 2019, Lee Jones wrote:
> >
> > > From: Bjorn Andersson <bjorn.andersson@linaro.org>
> > >
> > > The Lenovo Yoga C630 is built on the SDM850 from Qualcomm, but this seem
> > > to be similar enough to the SDM845 that we can reuse the sdm845.dtsi.
> > >
> > > Supported by this patch is: keyboard, battery monitoring, UFS storage,
> > > USB host and Bluetooth.
> >
> > Applied this to next-20190829 and booted it, got a little bit of EFI FB,
> > then the screen goes blank and after a while I'm back in GRUB.
> >
> > I've not been able to figure out what's causing this though.
>
> Probably DMA. There is still an issue in the COM GENI Serial Engine
> Driver which reboots the system when a DMA transaction is initiated.
>
> However, with a workaround patch applied to the Serial Engine driver
> (drivers/soc/qcom/qcom-geni-se.c) this DTS has no issue booting the
> system.
>
> We have ~12 weeks to either fix or elegantly work around the Serial
> Engine issue. IMHO is makes no sense to hold back this enablement
> patch (which cannot go in via the -rcs) for something which is likely
> to be fixed and applied during v3.4-rcX.
NB: If you're worried about other entities thinking the platform boots
fault free due to this DTS patch being applied, I would suggest we
place a little "NB:" note in the changelog to explain the situation.
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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