[alsa-devel] [PATCH v5 1/4] ASoC: tlv320aic32x4: Support for master clock

[Markus Pargmann]

Hi,

On Wed, Feb 19, 2014 at 12:54:06PM +0900, Mark Brown wrote:
> On Tue, Feb 18, 2014 at 09:46:46PM +0100, Markus Pargmann wrote:
> > On Tue, Feb 18, 2014 at 10:23:29AM +0900, Mark Brown wrote:
> 
> > > Looking at the code the clock isn't physically optional, why not make it
> > > mandatory?  There's only one mainline user, it looks like it should be
> > > straightforward to update with a fixed clock.
> 
> > The masterclock is physically optional. There are several modes to use
> > this codec without master clock. The PLL can use different clock inputs,
> > BCLK, MCLK, etc. and even the PLL is not necessary. Instead BCLK and so
> > on can be used as direct codec clock input. However, most of this is not
> > supported by the driver yet and I can't test these cases.
> 
> Are any of these modes supported by the driver yet?  If there's modes
> that don't use MCLK supported then I'd expect them to only enable MCLK
> if it's actively being used in the current configuration (triggered via
> set_sysclk()).

It seems none of these modes are supported yet. aic32x4_hw_params setups
the clock tree relying on a master clock to be used for the PLL.
Otherwise hw_params fails. So currently mclk is not optional for the
driver. But it is still optional for the real hardware.

What do you think about declaring the mclk as optional property in the
DT bindings documentation but to handle it as a required clock in the
driver?

Thanks,

Markus



-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20140220/5b6c015d/attachment.sig>