linux-kernel - Re: [alsa-devel] [PATCH] ASoC: rt5659: Add mclk controls

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, 10 Aug 2016 18:52:43 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
Cc:	Vinod Koul <vinod.koul@...el.com>, mark.rutland@....com,
	oder_chiou@...ltek.com, alsa-devel@...a-project.org,
	devicetree@...r.kernel.org, Darren Hart <dvhart@...ux.intel.com>,
	lgirdwood@...il.com, linux-kernel@...r.kernel.org,
	Nicolin Chen <nicoleotsuka@...il.com>, robh+dt@...nel.org,
	bardliao@...ltek.com
Subject: Re: [alsa-devel] [PATCH] ASoC: rt5659: Add mclk controls

On Wed, Aug 10, 2016 at 12:31:28PM -0500, Pierre-Louis Bossart wrote:

> If we want to be consistent then we need to have a framework that handles
> both the SOC clock sources and the codec internal clock tree (including
> dividers and switches)
> I wonder if what you are hinting at is the codec driver modeling its
> internal PLL/clock tree with the clock API?

I'm not just hinting at that, I've openly stated it quite a few times
now!  :P  For the simpler CODECs it's kind of marginal if you need to
bother but for anything more complex (even things with PLLs) it seems
like the way forwards.

> If we have the clock API requesting the mclk only, and the rest of the codec
> configuration is done by the machine driver there is no real progress I can
> see.

It's still useful in that we can consistently manage the clocks external
to the CODEC that way, especially when looking at systems where it is
useful to dynamically start and stop the clocks.

> > The CODEC clearly has *some* idea of what's going on here, and
> > especially for simpler CODECs the code to drive the clocking should be
> > fairly easy to generalize as there's few options.  From a clock API
> > point of view the CODEC really ought to be the one requesting the clocks
> > that go into it, though there's nothing that says it has to only use its
> > own information to do that.

> I don't get the last part, how would the codec use information it doesn't
> own or have access to?

I'd expect that a clock consumer should (like a regulator consumer can)
be able to figure out what constraints there are on the rates it has
set.  Those could be fixed restrictions but it'd be good to also have
ways for other actors in the system to change things at runtime.

> At any rate, I am only trying to define the problem statement, probably
> something to talk about at the Audio Miniconference.

Yup.  I really should chase to see if that actually got accepted or
not... 

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