Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Takashi Iwai <tiwai@suse.de>, alsa-devel@alsa-project.org
Cc: Mark Brown <broonie@kernel.org>
Subject: Re: [PATCH 2/2] ASoC: Intel: Add machine driver for CX2072X on BYT/CHT platforms
Date: Tue, 23 Apr 2019 12:20:24 -0700	[thread overview]
Message-ID: <f241c576-8c37-24d1-48c7-04bb36a7c565@linux.intel.com> (raw)
In-Reply-To: <20190423141336.12568-3-tiwai@suse.de>

On 4/23/19 9:13 AM, Takashi Iwai wrote:
> This is an implementation of a machine driver needed for Conexant
> CX2072X codec on Intel Baytrail and Cherrytrail platforms.  The
> current patch is based on the initial work by Pierre-Louis Bossart and
> the other Intel machine drivers.
> 
> The jack detection support (driven via the standard GPIO) was added on
> top of the original work.
> 
> No SOF support yet, so the corresponding entries are commented out.

SOF support is trivial to add, can we help you here?


> +config SND_SOC_INTEL_BYT_CHT_CX2072X_MACH
> +	tristate "Baytrail & Cherrytrail with CX2072X codec"
> +	depends on X86_INTEL_LPSS && I2C && ACPI

Didn't Mark recently split this in two, with X86_INTEL_LPSS || COMPILE_TEST?

> +static int byt_cht_cx2072x_fixup(struct snd_soc_pcm_runtime *rtd,
> +				 struct snd_pcm_hw_params *params)
> +{
> +	struct snd_interval *rate =
> +		hw_param_interval(params, SNDRV_PCM_HW_PARAM_RATE);
> +	struct snd_interval *channels =
> +		hw_param_interval(params, SNDRV_PCM_HW_PARAM_CHANNELS);
> +	int ret;
> +
> +	/* The DSP will covert the FE rate to 48k, stereo, 24bits */
> +	rate->min = rate->max = 48000;
> +	channels->min = channels->max = 2;
> +
> +	/* set SSP2 to 24-bit */
> +	params_set_format(params, SNDRV_PCM_FORMAT_S24_LE);
> +
> +	/*
> +	 * Default mode for SSP configuration is TDM 4 slot, override config
> +	 * with explicit setting to I2S 2ch 24-bit. The word length is set with
> +	 * dai_set_tdm_slot() since there is no other API exposed
> +	 */
> +	ret = snd_soc_dai_set_fmt(rtd->cpu_dai,
> +				SND_SOC_DAIFMT_I2S     |
> +				SND_SOC_DAIFMT_NB_NF   |
> +				SND_SOC_DAIFMT_CBS_CFS);
> +	if (ret < 0) {
> +		dev_err(rtd->dev, "can't set format to I2S, err %d\n", ret);
> +		return ret;
> +	}
> +
> +	ret = snd_soc_dai_set_tdm_slot(rtd->cpu_dai, 0x3, 0x3, 2, 24);
> +	if (ret < 0) {
> +		dev_err(rtd->dev, "can't set I2S config, err %d\n", ret);
> +		return ret;
> +	}
> +
> +	snd_soc_dai_set_bclk_ratio(rtd->codec_dai, 50);

that part would be problematic for SOF. IIRC we put all clock-related 
stuff in the init, and ignore the fixups to use topology-based 
information instead. If this call to _set_bclk_ratio can be moved to the 
init it's more future-proof. Is there a reason to do this here in the fixup?


> +static struct snd_soc_dai_link byt_cht_cx2072x_dais[] = {
> +	[MERR_DPCM_AUDIO] = {
> +		.name = "Audio Port",
> +		.stream_name = "Audio",
> +		.cpu_dai_name = "media-cpu-dai",
> +		.codec_dai_name = "snd-soc-dummy-dai",
> +		.codec_name = "snd-soc-dummy",
> +		.platform_name = "sst-mfld-platform",
> +		.nonatomic = true,
> +		.dynamic = 1,
> +		.dpcm_playback = 1,
> +		.dpcm_capture = 1,
> +		.ops = &byt_cht_cx2072x_aif1_ops,
> +	},
> +	[MERR_DPCM_DEEP_BUFFER] = {
> +		.name = "Deep-Buffer Audio Port",
> +		.stream_name = "Deep-Buffer Audio",
> +		.cpu_dai_name = "deepbuffer-cpu-dai",
> +		.codec_dai_name = "snd-soc-dummy-dai",
> +		.codec_name = "snd-soc-dummy",
> +		.platform_name = "sst-mfld-platform",
> +		.nonatomic = true,
> +		.dynamic = 1,
> +		.dpcm_playback = 1,
> +		.ops = &byt_cht_cx2072x_aif1_ops,
> +	},
> +	/* back ends */
> +	{
> +		.name = "SSP2-Codec",
> +		.id = 1,
> +		.cpu_dai_name = "ssp2-port",
> +		.platform_name = "sst-mfld-platform",
> +		.no_pcm = 1,
> +		.codec_dai_name = "cx2072x-hifi",
> +		.codec_name = "i2c-14F10720:00",
> +		.dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF
> +					      | SND_SOC_DAIFMT_CBS_CFS,
> +		.init = byt_cht_cx2072x_init,
> +		.be_hw_params_fixup = byt_cht_cx2072x_fixup,
> +		.nonatomic = true,

I can't recall if this .atomic is needed or not for back-ends.

> +	{
> +		.id = "14F10720",
> +		.drv_name = "bytcht_cx2072x",
> +		.fw_filename = "intel/fw_sst_0f28.bin",
> +		.board = "bytcht_cx2072x",
> +		/* .sof_fw_filename = "sof-byt.ri", */
> +		/* .sof_tplg_filename = "sof-byt-cx2072x.tplg", */
> +	},
>   #if IS_ENABLED(CONFIG_SND_SOC_INTEL_BYT_CHT_NOCODEC_MACH)
>   	/*
>   	 * This is always last in the table so that it is selected only when
> diff --git a/sound/soc/intel/common/soc-acpi-intel-cht-match.c b/sound/soc/intel/common/soc-acpi-intel-cht-match.c
> index deafd87cc764..69ecbb88c171 100644
> --- a/sound/soc/intel/common/soc-acpi-intel-cht-match.c
> +++ b/sound/soc/intel/common/soc-acpi-intel-cht-match.c
> @@ -169,6 +169,14 @@ struct snd_soc_acpi_mach  snd_soc_acpi_intel_cherrytrail_machines[] = {
>   		.sof_fw_filename = "sof-cht.ri",
>   		.sof_tplg_filename = "sof-cht-rt5651.tplg",
>   	},
> +	{
> +		.id = "14F10720",
> +		.drv_name = "bytcht_cx2072x",
> +		.fw_filename = "intel/fw_sst_22a8.bin",
> +		.board = "bytcht_cx2072x",
> +		/* .sof_fw_filename = "sof-cht.ri", */
> +		/* .sof_tplg_filename = "sof-cht-cx2072x.tplg", */
> +	},

I'd uncomment those two ACPI machine parts. There is not risk unless SOF 
is actually enabled.

  reply	other threads:[~2019-04-23 19:20 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-23 14:13 [PATCH 0/2] ASoC: CX2072X codec support (revised) Takashi Iwai
2019-04-23 14:13 ` [PATCH 1/2] ASoC: Add support for Conexant CX2072X CODEC Takashi Iwai
2019-04-27 17:59   ` Mark Brown
2019-05-02  7:04     ` Takashi Iwai
2019-05-02  7:52       ` Takashi Iwai
2019-05-03  6:52         ` Mark Brown
     [not found]       ` <20190503064729.GF14916@sirena.org.uk>
2019-05-03  7:18         ` Takashi Iwai
     [not found]           ` <20190506042625.GK14916@sirena.org.uk>
2019-05-06  9:55             ` Takashi Iwai
2019-05-06 14:05               ` Mark Brown
2019-05-06 15:26                 ` Takashi Iwai
2019-05-08  8:10                   ` Mark Brown
2019-05-08  8:16                     ` Takashi Iwai
2019-05-08  8:59                       ` Mark Brown
2019-05-08  9:16                         ` Takashi Iwai
2019-05-08 10:10                           ` Mark Brown
2019-05-03  8:05         ` Takashi Iwai
2019-04-23 14:13 ` [PATCH 2/2] ASoC: Intel: Add machine driver for CX2072X on BYT/CHT platforms Takashi Iwai
2019-04-23 19:20   ` Pierre-Louis Bossart [this message]
2019-04-23 19:39     ` Takashi Iwai
2019-04-24 13:08       ` Takashi Iwai

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f241c576-8c37-24d1-48c7-04bb36a7c565@linux.intel.com \
    --to=pierre-louis.bossart@linux.intel.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=tiwai@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox