All of 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.