[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160224033259.GL18327@sirena.org.uk>
Date: Wed, 24 Feb 2016 12:32:59 +0900
From: Mark Brown <broonie@...nel.org>
To: Heiko Stuebner <heiko@...ech.de>
Cc: Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
Sugar Zhang <sugar.zhang@...k-chips.com>,
Mark Rutland <mark.rutland@....com>,
Oder Chiou <oder_chiou@...ltek.com>,
alsa-devel@...a-project.org, Pawel Moll <pawel.moll@....com>,
Ian Campbell <ijc+devicetree@...lion.org.uk>,
linux-kernel@...r.kernel.org, Takashi Iwai <tiwai@...e.com>,
Liam Girdwood <lgirdwood@...il.com>,
devicetree@...r.kernel.org, Rob Herring <robh+dt@...nel.org>,
Kumar Gala <galak@...eaurora.org>,
Bard Liao <bardliao@...ltek.com>
Subject: Re: [alsa-devel] [PATCH] ASoC: rt5640: add master clock handling for
rt5640
On Wed, Feb 24, 2016 at 12:08:31AM +0100, Heiko Stuebner wrote:
> Am Dienstag, 23. Februar 2016, 08:50:04 schrieb Pierre-Louis Bossart:
> > This patch assumes that the information on mclk comes from DeviceTree.
> > The mclk may also be enabled/disabled in the machine driver with an
> > explicit transition to use an internal clock when the codec is not used.
> > I hope this patch doesn't preclude such usages or there will be a
> > conflict with the patches we are about to upstream for Baytrail/cht
> > devices.
> As you can see, the clock property itself is optional and the clk_get below
> acts accordingly of also continuing if the clock is not present.
> So it won't affect any users doing it otherwise.
That said we really do need x86 to transition to use the clock API in
order to integrate with external devices, where the machine driver does
manage clocks we want that to move to being done using the clock API
rather than custom APIs.
Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)
Powered by blists - more mailing lists