May 2019 - Alsa-devel - mailman.alsa-project.org

Re: [alsa-devel] [PATCH 1/2] ASoC: Add support for Conexant CX2072X CODEC
by Takashi Iwai 03 May '19

03 May '19

On Fri, 03 May 2019 08:47:29 +0200, Mark Brown wrote: > > > > > +#define cx2072x_plbk_eq_en_info snd_ctl_boolean_mono_info > > > > Why not just use the function directly rather than hiding it? > > > Just a standard idiom. Can be replaced if preferred. > > Please. BTW, a good reason for the style above is that it makes code more undrestandable. For defining a ctl element, typically we define three callback functions, info, get and put, in that order: static int foo_info() { .... } static int foo_get() { .... } static int foo_put() { ... }; and often the actual snd_kcontrol_new table containing these callbacks appears much later, where you'd need to scroll down a few screens to read that point. In the above, especially defining the info callback at the beginning is important. By reading foo_init() at first, readers can know which type (int, boolean, enum, etc) and the number of elements to be used in get/put callbacks beforehand. It's a commonly seen mistake, for example, that a wrong type (e.g. integer) is passed to info callback while enum type is used in the get/put. The #define above keeps this foo_info() definition while optimizing with the standard helper. If we drop this and set snd_ctl_boolean_mono_info directly in the snd_kcontrol_new entry, you'll have to go and back the screen just to take a look at the info callback. That's why I called it a standard idiom. It's not strictly necessary, but often help reading / reviewing the code. Though, it's just another bikeshed theme, so I'm not sticking with this style. thanks, Takashi

1 0

Re: [alsa-devel] [PATCH 1/2] ASoC: Add support for Conexant CX2072X CODEC
by Takashi Iwai 03 May '19

03 May '19

On Fri, 03 May 2019 08:47:29 +0200, Mark Brown wrote: > > On Thu, May 02, 2019 at 09:04:06AM +0200, Takashi Iwai wrote: > > Mark Brown wrote: > > > On Tue, Apr 23, 2019 at 04:13:35PM +0200, Takashi Iwai wrote: > > > > This looks *very* much like board configuration rather than a patch - > > > there's no kind of test bit and the comments talk specifically about > > > things like gain settings and pad configuration which look very board > > > specific. Register patches are supposed to be for things like early > > > revisions of the chip which have different register defaults or magic > > > sequences that vendors tell you to run on startup, usually to tune test > > > registers. > > > OK, will replace with the straight regmap_multi_reg_write(). > > That's probably not addressing the issue, a lot of that stuff just > doesn't seem like it should be in some fixed configuration table at all. So what's your alternative suggestion? > > > > +#define cx2072x_plbk_eq_en_info snd_ctl_boolean_mono_info > > > > Why not just use the function directly rather than hiding it? > > > Just a standard idiom. Can be replaced if preferred. > > Please. > > > > > +int snd_soc_cx2072x_enable_jack_detect(struct snd_soc_component *codec) > > > > +{ > > > > + struct cx2072x_priv *cx2072x = snd_soc_component_get_drvdata(codec); > > > > + struct snd_soc_dapm_context *dapm = snd_soc_component_get_dapm(codec); > > > > + > > > > + /* No-sticky input type */ > > > > + regmap_write(cx2072x->regmap, CX2072X_GPIO_STICKY_MASK, 0x1f); > > > > + > > > > + /* Use GPOI0 as interrupt pin */ > > > > + regmap_write(cx2072x->regmap, CX2072X_UM_INTERRUPT_CRTL_E, 0x12 << 24); > > > > This isn't board specific is it? > > > I have no idea. It's been so from the original code, and there > > doesn't seem any other hardware implementations. > > Oh, joy. What's the story here? Do you have a datasheet for the part? Not at all. I just refreshed the already submitted patches since I have a laptop with the codec. I tried to contact Conexant, but in vain, so I decided to submit the renewed one. > > The jack detection in ASoC is anyway a bit funky, especially when > > involved with PM... > > What do you mean here? I'm not aware of any issues and the systems I've > worked with seemed robust... There are tons of different ways of implementation for jack controls, with different API usages. IOW, no consistency. > > > > + dev_dbg(codec->dev, "CX2072X_HSDETECT type=0x%X,Jack state = %x\n", > > > > + type, state); > > > > + return state; > > > > +} > > > > +EXPORT_SYMBOL_GPL(snd_soc_cx2072x_get_jack_state); > > > > Why is this symbol exported? > > > It's called from the machine driver. > > snd_soc_jack_add_gpios() is called in the machine driver side, and it > > needs the jack_status_check callback that calls this function. > > That code shouldn't be in the machine driver, the CODEC driver should > request any interrupts it needs itself. The similar things are done on many other Intel SST board drivers. The current patch just follows the pattern. > > > > + /* use flat eq by default */ > > > > + for (ch = 0 ; ch < 2 ; ch++) { > > > > + for (band = 0; band < CX2072X_PLBK_EQ_BAND_NUM; band++) { > > > > + cx2072x->plbk_eq[ch][band][1] = 64; > > > > + cx2072x->plbk_eq[ch][band][10] = 3; > > > > + } > > > > + } > > > > Why not use the register defaults? > > > Because it'll become too messy for put flatten array values? > > The initialization using loop makes more sense in such a case, IMO. > > No, that's not the question. The question is why there is any > initialization at all? Again, no idea. These are likely no default values of the hardware registers, and we need to set up some. I *guess* ditto for the initial register table in the above, too. thanks, Takashi

1 0

[alsa-devel] [PATCH 0/2] ASoC: CX2072X codec support (revised)
by Takashi Iwai 03 May '19

03 May '19

Hi, it's been long time ago the first version of CX2072X codec patch was submitted, and I hoped that it'd be resubmitted, but never happened, as the original author seems to have left, unfortunately. Since I have such a laptop (ASUS E200HA), I took some time to cook and brush up the patches. The patches are for 5.2, should be applicable to ASoC tree for-next branch. Will post the corresponding UCM profile patch once when this gets accepted. thanks, Takashi === Simon Ho (1): ASoC: Add support for Conexant CX2072X CODEC Takashi Iwai (1): ASoC: Intel: Add machine driver for CX2072X on BYT/CHT platforms sound/soc/codecs/Kconfig | 7 + sound/soc/codecs/Makefile | 2 + sound/soc/codecs/cx2072x.c | 2197 +++++++++++++++++++++ sound/soc/codecs/cx2072x.h | 317 +++ sound/soc/intel/boards/Kconfig | 11 + sound/soc/intel/boards/Makefile | 2 + sound/soc/intel/boards/bytcht_cx2072x.c | 285 +++ sound/soc/intel/common/soc-acpi-intel-byt-match.c | 8 + sound/soc/intel/common/soc-acpi-intel-cht-match.c | 8 + 9 files changed, 2837 insertions(+) create mode 100644 sound/soc/codecs/cx2072x.c create mode 100644 sound/soc/codecs/cx2072x.h create mode 100644 sound/soc/intel/boards/bytcht_cx2072x.c -- 2.16.4

3 9

[alsa-devel] [PATCH v2] ASoC: mediatek: mt8516: register ADDA DAI
by Fabien Parent 03 May '19

03 May '19

Register the ADDA DAI driver into the MT8516 PCM driver. Signed-off-by: Fabien Parent <fparent(a)baylibre.com> --- This patch depends on patch serie: [PATCH 0/5] ASoC: mediatek: Add basic PCM driver for MT8516 v2: * Register ADDA before memif to fix ordering issue. --- sound/soc/mediatek/mt8516/mt8516-afe-pcm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/soc/mediatek/mt8516/mt8516-afe-pcm.c b/sound/soc/mediatek/mt8516/mt8516-afe-pcm.c index 84fbb5dbbd14..dea9221c67aa 100644 --- a/sound/soc/mediatek/mt8516/mt8516-afe-pcm.c +++ b/sound/soc/mediatek/mt8516/mt8516-afe-pcm.c @@ -10,6 +10,7 @@ #include <linux/module.h> #include <linux/of.h> +#include "mt8516-afe-common.h" #include "mt8516-afe-regs.h" #include "../common/mtk-afe-platform-driver.h" @@ -669,6 +670,7 @@ static int mt8516_dai_memif_register(struct mtk_base_afe *afe) typedef int (*dai_register_cb)(struct mtk_base_afe *); static const dai_register_cb dai_register_cbs[] = { + mt8516_dai_adda_register, mt8516_dai_memif_register, }; -- 2.20.1

2 1

[alsa-devel] [RFC PATCH] ASoC: max98357a: manage GPIO for component rebinding
by Tzung-Bi Shih 03 May '19

03 May '19

Component's probe() gets GPIO for "sdmode-gpios" via devm_gpiod_get_optional(). The GPIO binds to the device. When the component get removed but the device does not, the GPIO still binds to the device. Then, when the component be probed again, devm_gpiod_get_optional() returns EBUSY. Signed-off-by: Tzung-Bi Shih <tzungbi(a)google.com> --- Hi, We discovered the issue when rebinding sound card. We found that the rebinding failed due to the GPIO was hold by the first time component's probe() in max98357. The patch changes devm to non-devm API, because we don't have equivalent API for ASoC components (e.g. compm_). Question: we are not very sure to move from devm to non-devm, because devm should be most encouraged. Question: does it suggest not to use devm for GPIO in component's probe()? It seems there are still some such usages, for example sound/soc/codecs/dmic.c. sound/soc/codecs/max98357a.c | 42 ++++++++++++++++++++++++++++-------- 1 file changed, 33 insertions(+), 9 deletions(-) diff --git a/sound/soc/codecs/max98357a.c b/sound/soc/codecs/max98357a.c index d037a3e4d323..4e90876f6ef6 100644 --- a/sound/soc/codecs/max98357a.c +++ b/sound/soc/codecs/max98357a.c @@ -27,24 +27,28 @@ #include <sound/soc-dai.h> #include <sound/soc-dapm.h> +struct max98357a_priv { + struct gpio_desc *sdmode; +}; + static int max98357a_daiops_trigger(struct snd_pcm_substream *substream, int cmd, struct snd_soc_dai *dai) { - struct gpio_desc *sdmode = snd_soc_dai_get_drvdata(dai); + struct max98357a_priv *max98357a = snd_soc_dai_get_drvdata(dai); - if (!sdmode) + if (!max98357a->sdmode) return 0; switch (cmd) { case SNDRV_PCM_TRIGGER_START: case SNDRV_PCM_TRIGGER_RESUME: case SNDRV_PCM_TRIGGER_PAUSE_RELEASE: - gpiod_set_value(sdmode, 1); + gpiod_set_value(max98357a->sdmode, 1); break; case SNDRV_PCM_TRIGGER_STOP: case SNDRV_PCM_TRIGGER_SUSPEND: case SNDRV_PCM_TRIGGER_PAUSE_PUSH: - gpiod_set_value(sdmode, 0); + gpiod_set_value(max98357a->sdmode, 0); break; } @@ -61,19 +65,31 @@ static const struct snd_soc_dapm_route max98357a_dapm_routes[] = { static int max98357a_component_probe(struct snd_soc_component *component) { - struct gpio_desc *sdmode; + struct max98357a_priv *max98357a = + snd_soc_component_get_drvdata(component); - sdmode = devm_gpiod_get_optional(component->dev, "sdmode", GPIOD_OUT_LOW); - if (IS_ERR(sdmode)) - return PTR_ERR(sdmode); + max98357a->sdmode = gpiod_get_optional(component->dev, + "sdmode", GPIOD_OUT_LOW); + if (IS_ERR(max98357a->sdmode)) + return PTR_ERR(max98357a->sdmode); - snd_soc_component_set_drvdata(component, sdmode); + snd_soc_component_set_drvdata(component, max98357a); return 0; } +static void max98357a_component_remove(struct snd_soc_component *component) +{ + struct max98357a_priv *max98357a = + snd_soc_component_get_drvdata(component); + + if (max98357a->sdmode) + gpiod_put(max98357a->sdmode); +} + static const struct snd_soc_component_driver max98357a_component_driver = { .probe = max98357a_component_probe, + .remove = max98357a_component_remove, .dapm_widgets = max98357a_dapm_widgets, .num_dapm_widgets = ARRAY_SIZE(max98357a_dapm_widgets), .dapm_routes = max98357a_dapm_routes, @@ -112,6 +128,14 @@ static struct snd_soc_dai_driver max98357a_dai_driver = { static int max98357a_platform_probe(struct platform_device *pdev) { + struct max98357a_priv *max98357a; + + max98357a = devm_kzalloc(&pdev->dev, sizeof(*max98357a), GFP_KERNEL); + if (!max98357a) + return -ENOMEM; + + dev_set_drvdata(&pdev->dev, max98357a); + return devm_snd_soc_register_component(&pdev->dev, &max98357a_component_driver, &max98357a_dai_driver, 1); -- 2.21.0.593.g511ec345e18-goog

2 1

[alsa-devel] [PATCH] ASoC: Intel: boards: kbl_da7219_max98927: add dai_trigger function
by mac.chiang＠intel.com 03 May '19

03 May '19

From: Mac Chiang <mac.chiang(a)intel.com> amplifier feedback is not modeled as being dependent on any active output. Even when there is no playback happening, parts of the graph, specifically the IV sense->speaker protection->output remains active and this prevents the DSP from entering low-power states. This patch suggest a machine driver level approach where the speaker pins are enabled/disabled dynamically depending on stream start/stop events. DPAM graph representations show the feedback loop is indeed disabled and low-power states can be reached. Signed-off-by: Jenny TC <jenny.tc(a)intel.com> Signed-off-by: Harshapriya.n <harshapriya.n(a)intel.com> Signed-off-by: Mac Chiang <mac.chiang(a)intel.com> --- sound/soc/intel/boards/kbl_da7219_max98927.c | 73 +++++++++++++++++++++++++++- 1 file changed, 71 insertions(+), 2 deletions(-) diff --git a/sound/soc/intel/boards/kbl_da7219_max98927.c b/sound/soc/intel/boards/kbl_da7219_max98927.c index f72a7bf..1efe7fd 100644 --- a/sound/soc/intel/boards/kbl_da7219_max98927.c +++ b/sound/soc/intel/boards/kbl_da7219_max98927.c @@ -219,8 +219,60 @@ static int kabylake_ssp0_hw_params(struct snd_pcm_substream *substream, return 0; } +static int kabylake_ssp0_trigger(struct snd_pcm_substream *substream, int cmd) +{ + struct snd_soc_pcm_runtime *rtd = substream->private_data; + int j, ret; + + for (j = 0; j < rtd->num_codecs; j++) { + struct snd_soc_dai *codec_dai = rtd->codec_dais[j]; + const char *name = codec_dai->component->name; + struct snd_soc_component *component = codec_dai->component; + struct snd_soc_dapm_context *dapm = + snd_soc_component_get_dapm(component); + char pin_name[20]; + + if (strcmp(name, MAX98927_DEV0_NAME) && + strcmp(name, MAX98927_DEV1_NAME) && + strcmp(name, MAX98373_DEV0_NAME) && + strcmp(name, MAX98373_DEV1_NAME)) + continue; + + snprintf(pin_name, ARRAY_SIZE(pin_name), "%s Spk", + codec_dai->component->name_prefix); + + switch (cmd) { + case SNDRV_PCM_TRIGGER_START: + case SNDRV_PCM_TRIGGER_RESUME: + case SNDRV_PCM_TRIGGER_PAUSE_RELEASE: + ret = snd_soc_dapm_enable_pin(dapm, pin_name); + if (ret) { + dev_err(rtd->dev, "failed to enable %s: %d\n", + pin_name, ret); + return ret; + } + snd_soc_dapm_sync(dapm); + break; + case SNDRV_PCM_TRIGGER_STOP: + case SNDRV_PCM_TRIGGER_SUSPEND: + case SNDRV_PCM_TRIGGER_PAUSE_PUSH: + ret = snd_soc_dapm_disable_pin(dapm, pin_name); + if (ret) { + dev_err(rtd->dev, "failed to disable %s: %d\n", + pin_name, ret); + return ret; + } + snd_soc_dapm_sync(dapm); + break; + } + } + + return 0; +} + static struct snd_soc_ops kabylake_ssp0_ops = { .hw_params = kabylake_ssp0_hw_params, + .trigger = kabylake_ssp0_trigger, }; static int kabylake_ssp_fixup(struct snd_soc_pcm_runtime *rtd, @@ -950,6 +1002,7 @@ static int kabylake_card_late_probe(struct snd_soc_card *card) { struct kbl_codec_private *ctx = snd_soc_card_get_drvdata(card); struct kbl_hdmi_pcm *pcm; + struct snd_soc_dapm_context *dapm = &card->dapm; struct snd_soc_component *component = NULL; int err, i = 0; char jack_name[NAME_SIZE]; @@ -976,9 +1029,25 @@ static int kabylake_card_late_probe(struct snd_soc_card *card) if (!component) return -EINVAL; - return hdac_hdmi_jack_port_init(component, &card->dapm); - return 0; + err = hdac_hdmi_jack_port_init(component, &card->dapm); + + if (err < 0) + return err; + + err = snd_soc_dapm_disable_pin(dapm, "Left Spk"); + if (err) { + dev_err(card->dev, "failed to disable Left Spk: %d\n", err); + return err; + } + + err = snd_soc_dapm_disable_pin(dapm, "Right Spk"); + if (err) { + dev_err(card->dev, "failed to disable Right Spk: %d\n", err); + return err; + } + + return snd_soc_dapm_sync(dapm); } /* kabylake audio machine driver for SPT + DA7219 */ -- 2.7.4

3 2

[alsa-devel] [PATCH] ASoC: Intel: boards: kbl_da7219_max98927: add dai_trigger function
by mac.chiang＠intel.com 03 May '19

03 May '19

From: Mac Chiang <mac.chiang(a)intel.com> amplifier feedback is not modeled as being dependent on any active output. Even when there is no playback happening, parts of the graph, specifically the IV sense->speaker protection->output remains active and this prevents the DSP from entering low-power states. This patch suggest a machine driver level approach where the speaker pins are enabled/disabled dynamically depending on stream start/stop events. DPAM graph representations show the feedback loop is indeed disabled and low-power states can be reached. Signed-off-by: Jenny TC <jenny.tc(a)intel.com> Signed-off-by: Harshapriya.n <harshapriya.n(a)intel.com> Signed-off-by: Mac Chiang <mac.chiang(a)intel.com> --- Changelog: v4: - Changed device name in in kabylake_ssp0_trigger to address a conflict with recently merged patch MAXIM_DEV0_NAME -> MAX98927_DEV0_NAME ... v3: - fixed the return logic at the end of kabylake_card_late_probe() v2: - described clearly in commit message - added snd_soc_dapm_disable_pin in kabylake_card_late_probe() --- --- sound/soc/intel/boards/kbl_da7219_max98927.c | 73 +++++++++++++++++++++++++++- 1 file changed, 71 insertions(+), 2 deletions(-) diff --git a/sound/soc/intel/boards/kbl_da7219_max98927.c b/sound/soc/intel/boards/kbl_da7219_max98927.c index f72a7bf..1efe7fd 100644 --- a/sound/soc/intel/boards/kbl_da7219_max98927.c +++ b/sound/soc/intel/boards/kbl_da7219_max98927.c @@ -219,8 +219,60 @@ static int kabylake_ssp0_hw_params(struct snd_pcm_substream *substream, return 0; } +static int kabylake_ssp0_trigger(struct snd_pcm_substream *substream, int cmd) +{ + struct snd_soc_pcm_runtime *rtd = substream->private_data; + int j, ret; + + for (j = 0; j < rtd->num_codecs; j++) { + struct snd_soc_dai *codec_dai = rtd->codec_dais[j]; + const char *name = codec_dai->component->name; + struct snd_soc_component *component = codec_dai->component; + struct snd_soc_dapm_context *dapm = + snd_soc_component_get_dapm(component); + char pin_name[20]; + + if (strcmp(name, MAX98927_DEV0_NAME) && + strcmp(name, MAX98927_DEV1_NAME) && + strcmp(name, MAX98373_DEV0_NAME) && + strcmp(name, MAX98373_DEV1_NAME)) + continue; + + snprintf(pin_name, ARRAY_SIZE(pin_name), "%s Spk", + codec_dai->component->name_prefix); + + switch (cmd) { + case SNDRV_PCM_TRIGGER_START: + case SNDRV_PCM_TRIGGER_RESUME: + case SNDRV_PCM_TRIGGER_PAUSE_RELEASE: + ret = snd_soc_dapm_enable_pin(dapm, pin_name); + if (ret) { + dev_err(rtd->dev, "failed to enable %s: %d\n", + pin_name, ret); + return ret; + } + snd_soc_dapm_sync(dapm); + break; + case SNDRV_PCM_TRIGGER_STOP: + case SNDRV_PCM_TRIGGER_SUSPEND: + case SNDRV_PCM_TRIGGER_PAUSE_PUSH: + ret = snd_soc_dapm_disable_pin(dapm, pin_name); + if (ret) { + dev_err(rtd->dev, "failed to disable %s: %d\n", + pin_name, ret); + return ret; + } + snd_soc_dapm_sync(dapm); + break; + } + } + + return 0; +} + static struct snd_soc_ops kabylake_ssp0_ops = { .hw_params = kabylake_ssp0_hw_params, + .trigger = kabylake_ssp0_trigger, }; static int kabylake_ssp_fixup(struct snd_soc_pcm_runtime *rtd, @@ -950,6 +1002,7 @@ static int kabylake_card_late_probe(struct snd_soc_card *card) { struct kbl_codec_private *ctx = snd_soc_card_get_drvdata(card); struct kbl_hdmi_pcm *pcm; + struct snd_soc_dapm_context *dapm = &card->dapm; struct snd_soc_component *component = NULL; int err, i = 0; char jack_name[NAME_SIZE]; @@ -976,9 +1029,25 @@ static int kabylake_card_late_probe(struct snd_soc_card *card) if (!component) return -EINVAL; - return hdac_hdmi_jack_port_init(component, &card->dapm); - return 0; + err = hdac_hdmi_jack_port_init(component, &card->dapm); + + if (err < 0) + return err; + + err = snd_soc_dapm_disable_pin(dapm, "Left Spk"); + if (err) { + dev_err(card->dev, "failed to disable Left Spk: %d\n", err); + return err; + } + + err = snd_soc_dapm_disable_pin(dapm, "Right Spk"); + if (err) { + dev_err(card->dev, "failed to disable Right Spk: %d\n", err); + return err; + } + + return snd_soc_dapm_sync(dapm); } /* kabylake audio machine driver for SPT + DA7219 */ -- 2.7.4

1 0

[alsa-devel] [sound:topic/soc-cx2072x-5.2 1/2] sound/soc/codecs/cx2072x.c:597:18: sparse: sparse: cast to restricted __le32
by kbuild test robot 03 May '19

03 May '19

tree: https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git topic/soc-cx2072x-5.2 head: 19e7a6a1d903117b3f4520690e7f399a53852c44 commit: b3d0d3217c3c84b473918b74c33f2d626c49d267 [1/2] ASoC: Add support for Conexant CX2071X CODEC reproduce: # apt-get install sparse git checkout b3d0d3217c3c84b473918b74c33f2d626c49d267 make ARCH=x86_64 allmodconfig make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' If you fix the issue, kindly add following tag Reported-by: kbuild test robot <lkp(a)intel.com> sparse warnings: (new ones prefixed by >>) >> sound/soc/codecs/cx2072x.c:597:18: sparse: sparse: cast to restricted __le32 vim +597 sound/soc/codecs/cx2072x.c 564 565 static int cx2072x_reg_read(void *context, unsigned int reg, 566 unsigned int *value) 567 { 568 struct i2c_client *client = context; 569 struct device *dev = &client->dev; 570 unsigned int recv_buf = 0; 571 struct i2c_msg msgs[2]; 572 unsigned int size; 573 u8 send_buf[2]; 574 int ret; 575 576 size = cx2072x_register_size(reg); 577 578 send_buf[0] = reg >> 8; 579 send_buf[1] = reg & 0xff; 580 581 msgs[0].addr = client->addr; 582 msgs[0].len = sizeof(send_buf); 583 msgs[0].buf = send_buf; 584 msgs[0].flags = 0; 585 586 msgs[1].addr = client->addr; 587 msgs[1].len = size; 588 msgs[1].buf = (u8 *)&recv_buf; 589 msgs[1].flags = I2C_M_RD; 590 591 ret = i2c_transfer(client->adapter, msgs, ARRAY_SIZE(msgs)); 592 if (ret != ARRAY_SIZE(msgs)) { 593 dev_err(dev, "Failed to read register, ret = %d\n", ret); 594 return ret < 0 ? ret : -EIO; 595 } 596 > 597 *value = le32_to_cpu(recv_buf); 598 return 0; 599 } 600 --- 0-DAY kernel test infrastructure Open Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation

1 0

[alsa-devel] [PATCH] ASoC: RT5677-SPI: Disable 16Bit SPI Transfers
by Curtis Malainey 03 May '19

03 May '19

The current algorithm allows 3 types of transfers, 16bit, 32bit and burst. According to Realtek, 16bit transfers have a special restriction in that it is restricted to the memory region of 0x18020000 ~ 0x18021000. This region is the memory location of the I2C registers. The current algorithm does not uphold this restriction and therefore fails to complete writes. Since this has been broken for some time it likely no one is using it. Better to simply disable the 16 bit writes. This will allow users to properly load firmware over SPI without data corruption. CC: Ben Zhang <benzh(a)chromium.org> CC: Oder Chiou <oder_chiou(a)realtek.com> Signed-off-by: Curtis Malainey <cujomalainey(a)chromium.org> --- sound/soc/codecs/rt5677-spi.c | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/sound/soc/codecs/rt5677-spi.c b/sound/soc/codecs/rt5677-spi.c index 167a02773a0b..b296e62fdbb4 100644 --- a/sound/soc/codecs/rt5677-spi.c +++ b/sound/soc/codecs/rt5677-spi.c @@ -58,13 +58,15 @@ static DEFINE_MUTEX(spi_mutex); * RT5677_SPI_READ/WRITE_32: Transfer 4 bytes * RT5677_SPI_READ/WRITE_BURST: Transfer any multiples of 8 bytes * - * For example, reading 260 bytes at 0x60030002 uses the following commands: - * 0x60030002 RT5677_SPI_READ_16 2 bytes + * Note: + * 16 Bit writes and reads are restricted to the address range + * 0x18020000 ~ 0x18021000 + * + * For example, reading 256 bytes at 0x60030004 uses the following commands: * 0x60030004 RT5677_SPI_READ_32 4 bytes * 0x60030008 RT5677_SPI_READ_BURST 240 bytes * 0x600300F8 RT5677_SPI_READ_BURST 8 bytes * 0x60030100 RT5677_SPI_READ_32 4 bytes - * 0x60030104 RT5677_SPI_READ_16 2 bytes * * Input: * @read: true for read commands; false for write commands @@ -79,15 +81,13 @@ static u8 rt5677_spi_select_cmd(bool read, u32 align, u32 remain, u32 *len) { u8 cmd; - if (align == 2 || align == 6 || remain == 2) { - cmd = RT5677_SPI_READ_16; - *len = 2; - } else if (align == 4 || remain <= 6) { + if (align == 4 || remain <= 4) { cmd = RT5677_SPI_READ_32; *len = 4; } else { cmd = RT5677_SPI_READ_BURST; - *len = min_t(u32, remain & ~7, RT5677_SPI_BURST_LEN); + *len = (((remain - 1) >> 3) + 1) << 3; + *len = min_t(u32, *len, RT5677_SPI_BURST_LEN); } return read ? cmd : cmd + 1; } @@ -108,7 +108,7 @@ static void rt5677_spi_reverse(u8 *dst, u32 dstlen, const u8 *src, u32 srclen) } } -/* Read DSP address space using SPI. addr and len have to be 2-byte aligned. */ +/* Read DSP address space using SPI. addr and len have to be 4-byte aligned. */ int rt5677_spi_read(u32 addr, void *rxbuf, size_t len) { u32 offset; @@ -124,7 +124,7 @@ int rt5677_spi_read(u32 addr, void *rxbuf, size_t len) if (!g_spi) return -ENODEV; - if ((addr & 1) || (len & 1)) { + if ((addr & 3) || (len & 3)) { dev_err(&g_spi->dev, "Bad read align 0x%x(%zu)\n", addr, len); return -EACCES; } @@ -159,8 +159,8 @@ int rt5677_spi_read(u32 addr, void *rxbuf, size_t len) } EXPORT_SYMBOL_GPL(rt5677_spi_read); -/* Write DSP address space using SPI. addr has to be 2-byte aligned. - * If len is not 2-byte aligned, an extra byte of zero is written at the end +/* Write DSP address space using SPI. addr has to be 4-byte aligned. + * If len is not 4-byte aligned, then extra zeros are written at the end * as padding. */ int rt5677_spi_write(u32 addr, const void *txbuf, size_t len) @@ -178,7 +178,7 @@ int rt5677_spi_write(u32 addr, const void *txbuf, size_t len) if (!g_spi) return -ENODEV; - if (addr & 1) { + if (addr & 3) { dev_err(&g_spi->dev, "Bad write align 0x%x(%zu)\n", addr, len); return -EACCES; } -- 2.21.0.593.g511ec345e18-goog

3 2

[alsa-devel] Kernel patch needed for Asus Q325UAR
by ecmk 03 May '19

03 May '19

No sound combined with quickly fading sounds for a few seconds. Randomly working but with low quality distorted sound. The model needs to be added to the kernel patch listed bellow. Asus Q325UAR suffers from the same issues as discussed here: [alsa-devel] [PATCH] ALSA: hda/realtek: Enable audio jacks of ASUS UX391UA with, ALC294 https://mailman.alsa-project.org/pipermail/alsa-devel/2018-December/143282.… A detailed issue of the problem plus the solution is described here https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1784485?comments=all Thanks

2 6