linux-kernel - Re: [PATCH v2] ASoC: fsl_esai: Add ESAI CPU DAI 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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140110120439.GG29039@sirena.org.uk>
Date:	Fri, 10 Jan 2014 12:04:39 +0000
From:	Mark Brown <broonie@...nel.org>
To:	Nicolin Chen <Guangyu.Chen@...escale.com>
Cc:	timur@...i.org, alsa-devel@...a-project.org, robh+dt@...nel.org,
	pawel.moll@....com, mark.rutland@....com,
	ijc+devicetree@...lion.org.uk, galak@...eaurora.org,
	rob@...dley.net, lgirdwood@...il.com, perex@...ex.cz,
	tiwai@...e.de, grant.likely@...aro.org, shawn.guo@...aro.org,
	devicetree@...r.kernel.org, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org
Subject: Re: [PATCH v2] ASoC: fsl_esai: Add ESAI CPU DAI driver

On Fri, Jan 10, 2014 at 10:35:39AM +0800, Nicolin Chen wrote:

> Resent this because of losing attached file.

I don't think your previous mail got sent at all, or at least it must've
been caught by spam filters here...

> On Fri, Jan 10, 2014 at 10:32:52AM +0800, Nicolin Chen wrote:
> > On Thu, Jan 09, 2014 at 06:44:53PM +0000, Mark Brown wrote:

> > > Why does the machine driver have to do this by hand, being able to
> > > override is fine but having sensible defaults is easier?  Or does it
> > > actually do that and the comment just needs updating?

> > The divider part of ESAI is pretty complicated due to caring about three
> > configure bits - ETO, ETI, HCKD. (I've attached a diagram to this mail.)
> > So setting sysclk() alone is not enough to take care all the configurations.
> > That's why I designed these two interfaces at the first place. And it should
> > be hard to find a default situation.

Why is the machine driver going to be able to come up with a sensible
configuration then?  It's OK to support overriding the configuration
where needed, my concern is about providing a default.

> > But there is one approach to omit this calling for machine driver is to do
> > the set_bclk_ratio() at this CPU DAI driver. And this might be a good idea
> > because we can then separate the settings between PLAYBACK and CAPTURE, even
> > though we might then need to check the Master or Slave state to apply the
> > settings accordingly.

This is about what I'd expect but then surely the next step is for the
driver to choose a defualt BCLK ratio - that's how most drivers work,
they try to generate the exact rate that is needed to clock the data.
Are the bit clock shared between playback and capture?

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