linux-kernel - RE: [alsa-devel] [PATCH] ASoC: atmel_ssc_dai: Track playback and capture CMR dividers separately.

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 for Android: free password hash cracker in your pocket

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

Message-ID: <a983ea457a56451a96e377d64f861a9d@EMAIL.axentia.se>
Date:	Wed, 22 Oct 2014 11:42:18 +0000
From:	Peter Rosin <peda@...ntia.se>
To:	Bo Shen <voice.shen@...el.com>
CC:	"'alsa-devel@...a-project.org'" <alsa-devel@...a-project.org>,
	"Takashi Iwai" <tiwai@...e.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Liam Girdwood <lgirdwood@...il.com>,
	"Mark Brown" <broonie@...nel.org>
Subject: RE: [alsa-devel] [PATCH] ASoC: atmel_ssc_dai: Track playback and
 capture CMR dividers separately.

Bo Chen wrote:
> with this piece of code, I reproduce your issue.
> 
> Now, I know the reason of this issue, work in oss mode, it will set the default
> clock to 8KHz, and then if change to other sample rate, for example 48KHz,
> the div is different, then it reports -EBUSY.

Indeed.

> So, I think we won't change the ATMEL_SSC_CMR_DIV to
> ATMEL_SSC_TCMR_DIV and ATMEL_SSC_RCMR_DIV, as it will affect other
> users. We just deal with this situation in ATMEL_SSC_CMR_DIV block, check
> the direction, if the same direction change the div, then accept the change,
> otherwise, return -EBUSY.

Ok.

But I'm not sure it is possible to dig out the current direction in the
.set_clkdiv callback? Perhaps the correct fix is to set the bits
.symmetric_rates, .symmetric_channels and .symmetric_samplebits
in the atmel_ssc_dai struct when the ssc dai is master? Then I
expect that other mechanisms will kick in that will render the current
CMR_DIV check pointless?

Is a dai driver allowed to change these symmetry bits after registration?
Can they be set in the .set_sysclk callback? Perhaps in the
ATMEL_SSC_CMR_DIV block itself? That callback should only be
called when the dai is master, so that would be perfect...

Yes, the limitation would be a little bit more strict than today, but is it
really common to require different modes on playback and capture?

Cheers,
Peter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/