Thread (7 messages) flat view 7 messages, 2 authors, 2014-01-10

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

From: Nicolin Chen <hidden>
Date: 2014-01-10 13:06:53
Also in: alsa-devel, linux-devicetree, lkml

I just received the 'applied' mail. But still want to confirm this topic to
see how to refine the driver in the step ahead.

On Fri, Jan 10, 2014 at 12:04:39PM +0000, Mark Brown wrote:
On Fri, Jan 10, 2014 at 10:35:39AM +0800, Nicolin Chen wrote:
quoted
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...
quoted
On Fri, Jan 10, 2014 at 10:32:52AM +0800, Nicolin Chen wrote:
quoted
On Thu, Jan 09, 2014 at 06:44:53PM +0000, Mark Brown wrote:
quoted
quoted
quoted
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?
quoted
quoted
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.
quoted
quoted
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.
Does that mean I should call set_bclk() once in the startup() when !active
to set a default bit clock rate to suit a common sample rate like 44100Hz?
I'm a bit confused if so. Because the driver would call set_bclk() any way
in the hw_params().

But your suggestion just reminds me of the slave mode in SSI driver as
default mode. And I should patch ESAI to slave mode for default as well,
shouldn't I?
Are the bit clock shared between playback and capture?
Only shared in synchronous mode and totally individual in asynchronous mode.
Each of them can have their own HCK(MCLK) from different sources and derive
their own SCK(BCLK).

Thank you,
Nicolin
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help