Messages in this thread | | | Date | Fri, 10 Jan 2014 12:04:39 +0000 | From | Mark Brown <> | 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? [unhandled content-type:application/pgp-signature] | |