linux-kernel - Re: [PATCH 0/2] Cygnus Audio Driver

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, 8 Apr 2015 19:54:20 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Lori Hikichi <lhikichi@...adcom.com>
Cc:	Scott Branden <sbranden@...adcom.com>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	Liam Girdwood <lgirdwood@...il.com>,
	Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.de>,
	alsa-devel@...a-project.org, linux-kernel@...r.kernel.org,
	devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	bcm-kernel-feedback-list@...adcom.com,
	Dmitry Torokhov <dtor@...gle.com>,
	Anatol Pomazao <anatol@...gle.com>, abrestic@...gle.com,
	bryeung@...gle.com, olofj@...gle.com, pwestin@...gle.com
Subject: Re: [PATCH 0/2] Cygnus Audio Driver

On Tue, Apr 07, 2015 at 07:28:40PM -0700, Lori Hikichi wrote:
> On 15-04-06 02:58 AM, Mark Brown wrote:

> >OK, then it's going to need to be a clock provider at some point - the
> >clock will be going into external devices which are going to need to be
> >able to interact with the clock (for example, to get the rate).

> Currently, the ASoC machine driver is responsible for requesting a certain
> frequency of MCLK be generated from our driver and then also sending the
> frequency information along to the external device (codec).
> This is done via the snd_soc_dai_set_sysclk.  That is the only clock
> interaction we have needed for the core part of the driver.  For enhanced

I have some passing familiarity with ASoC...  if you look at newer
drivers, especially those for DT systems, you'll see that we're
transitioning CODEC drivers to use the clock API for their clocks since
this makes integrating with both generic ASoC things like simple card
and non-ASoC clocks.

> features, we also have the need to make minor adjustments (tweaks) to the
> PLL.  The tweaks are used to make the PLLs output frequency match as closely
> as possible to a true reference frequency. As such, we would like to provide
> the finest adjustment resolution as possible. The clocking framework only
> seems to allow for a 1 Hz adjustment. This limitation and the fact that no
> other device seems to need to interact directly will the PLL are why we have
> not put it in the clocking framework.

That's going to be an issue no matter where you put the control - the
ASoC specific clocking APIs don't have any control here either.  I don't
know if we want to add the functionality for doing very fine grained
adjustments into the clock API or not (the use cases seem limited though
I'm sure they exist), though I do think we should have that discussion
if only to confirm, but that's a separate thing to how we expose any
userspace control - the clock API is a kernel internal thing.

Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)