Subject: Re: [PATCH v2] ASoC: fsl_esai: Add ESAI CPU DAI driver

From: Mark Brown <[email-masked]>
Date: Fri, 10 Jan 2014 12:04:39 +0000

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?