linux-kernel - RE: [PATCH v3] ASoC: Intel: kbl_rt5663_rt5514_max98927: Split be_hw_params

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 1 Jul 2020 17:00:45 +0000
From:   "N, Harshapriya" <harshapriya.n@...el.com>
To:     Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
        Łukasz Majczak <lma@...ihalf.com>
CC:     "alsa-devel@...a-project.org" <alsa-devel@...a-project.org>,
        Jie Yang <yang.jie@...ux.intel.com>,
        Radoslaw Biernacki <rad@...ihalf.com>,
        "Ross Zwisler" <zwisler@...gle.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Liam Girdwood <liam.r.girdwood@...ux.intel.com>,
        "M R, Sathya Prakash" <sathya.prakash.m.r@...el.com>,
        Bob Brandt <brndt@...gle.com>, Marcin Wojtas <mw@...ihalf.com>,
        Alex Levin <levinale@...omium.org>
Subject: RE: [PATCH v3] ASoC: Intel: kbl_rt5663_rt5514_max98927: Split
 be_hw_params_fixup function

> >>
> >>>> For speakers and headsets its 48Khz, 2 ch and 24 bit and this
> >>>> setting is done based on the front-end dai For speakers, however
> >>>> support only
> >>>> 16 bit, so we set it back to 16 bit If the front end dai is dmic,
> >>>> then the channel
> >>> is set to either 2 or 4 dmic_constraints. No other formats need to be set.
> >>>>
> >>>> All the SSP1 usages do not have the same parameters (as dmic is on
> >>>> SSP1 and its different as given above) Most parameters are same for
> >>> speakers and headset which are on different SSP. This is the reason
> >>> we had a single fixup function.
> >> On SSP1, for dmic we need to fix the channels which is derived from
> >> dmic_num of the snd_soc_acpi_mach structure based on the number of
> >> dmic on the board.
> >> The channel is something that might be different from speakers.
> >> We might not want to constraint the dmic capture to always be 48Khz as
> well.
> >> Given this, there seems to me, 2 ways to set it:
> >> 1. Derive if the fixup is being called for dmic or speaker 2. Having
> >> a new dailink
> >>
> >> If #2 is not preferred (going by Pierre's comments), can we use rtd-
> >>> cpu_dai/codec_dai->name to figure out if its for dmic or speaker?
> >> I can test this and get back to you.
> > Tested and the following is something we can use without creating a new
> dailink.
> >         	struct snd_soc_dai *codec_dai = asoc_rtd_to_codec(rtd, 0);
> > 	if (!strcmp(codec_dai->name, KBL_REALTEK_DMIC_CODEC_DAI)) {
> > 		if (params_channels(params) == 2 ||
> DMIC_CH(dmic_constraints) == 2)
> > 			channels->min = channels->max = 2;
> > 		else
> > 			channels->min = channels->max = 4;
> > 	} else {
> > 		rate->min = rate->max = 48000;
> > 		channels->min = channels->max = 2;
> > 		snd_mask_none(fmt);
> > 		snd_mask_set_format(fmt, pcm_fmt);
> > 	}
> >
> > Pierre, thoughts?
> 
> thanks Harsha, that looks like what I had in mind, but my earlier question was
> why we deal with the rates and formats only in the last case?
The speaker codec supported only 16 bit.  (Vendor mentioned)
For playback on this platform, only 48Khz was used.