[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130710100020.GA24508@sirena.org.uk>
Date: Wed, 10 Jul 2013 11:00:20 +0100
From: Mark Brown <broonie@...nel.org>
To: Richard Genoud <richard.genoud@...il.com>
Cc: Nicolas Ferre <nicolas.ferre@...el.com>,
Liam Girdwood <lgirdwood@...il.com>,
Uwe Kleine-König
<u.kleine-koenig@...gutronix.de>, Bo Shen <voice.shen@...el.com>,
Lars-Peter Clausen <lars@...afoo.de>,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
alsa-devel@...a-project.org, devicetree-discuss@...ts.ozlabs.org
Subject: Re: [PATCH v4 1/7] sound: sam9x5_wm8731: machine driver for
at91sam9x5 wm8731 boards
On Wed, Jul 10, 2013 at 11:25:37AM +0200, Richard Genoud wrote:
> 2013/7/9 Mark Brown <broonie@...nel.org>:
> > Shouldn't the SSC driver be enforcing this constraint if it comes from
> > the SSC hardware? If the clock is reprogrammable the usual convention
> > for drivers is to not constrain if the clock is set to zero so a machine
> > driver could remove the constraint.
> Actually, my comment is buggy here (or at least, unrelated to the
> authorized rates).
> The "MCLK_RATE" is the master clock of the wm8731 codec (a 12.288MHz crystal).
> According to the datasheet of wm8731, when a 12.288 crystal is used,
> the authorized rates are 8, 32, 48 and 96kHz (I have to remove 16 and
> 64kHz).
> So, is this the right place for the rates ?
No, the CODEC driver should be enforcing the restrictions if that's
where they come from.
Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)
Powered by blists - more mailing lists