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?
Attachment:
signature.asc
Description: Digital signature
