From: Mark Brown <broonie@kernel.org>
To: Nicolin Chen <Guangyu.Chen@freescale.com>
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
alsa-devel@alsa-project.org, shawn.guo@linaro.org,
pawel.moll@arm.com, ijc+devicetree@hellion.org.uk, tiwai@suse.de,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
timur@tabi.org, lgirdwood@gmail.com, robh+dt@kernel.org,
rob@landley.net, galak@codeaurora.org, grant.likely@linaro.org,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v2] ASoC: fsl_esai: Add ESAI CPU DAI driver
Date: Fri, 10 Jan 2014 12:04:39 +0000 [thread overview]
Message-ID: <20140110120439.GG29039@sirena.org.uk> (raw)
In-Reply-To: <20140110023537.GB16467@MrMyself>
[-- Attachment #1.1: Type: text/plain, Size: 1722 bytes --]
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 #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Mark Brown <broonie@kernel.org>
To: Nicolin Chen <Guangyu.Chen@freescale.com>
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
alsa-devel@alsa-project.org, shawn.guo@linaro.org,
pawel.moll@arm.com, ijc+devicetree@hellion.org.uk, tiwai@suse.de,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
timur@tabi.org, lgirdwood@gmail.com, robh+dt@kernel.org,
rob@landley.net, galak@codeaurora.org, grant.likely@linaro.org,
perex@perex.cz, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v2] ASoC: fsl_esai: Add ESAI CPU DAI driver
Date: Fri, 10 Jan 2014 12:04:39 +0000 [thread overview]
Message-ID: <20140110120439.GG29039@sirena.org.uk> (raw)
In-Reply-To: <20140110023537.GB16467@MrMyself>
[-- Attachment #1: Type: text/plain, Size: 1722 bytes --]
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 #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Mark Brown <broonie@kernel.org>
To: Nicolin Chen <Guangyu.Chen@freescale.com>
Cc: timur@tabi.org, alsa-devel@alsa-project.org, robh+dt@kernel.org,
pawel.moll@arm.com, mark.rutland@arm.com,
ijc+devicetree@hellion.org.uk, galak@codeaurora.org,
rob@landley.net, lgirdwood@gmail.com, perex@perex.cz,
tiwai@suse.de, grant.likely@linaro.org, shawn.guo@linaro.org,
devicetree@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v2] ASoC: fsl_esai: Add ESAI CPU DAI driver
Date: Fri, 10 Jan 2014 12:04:39 +0000 [thread overview]
Message-ID: <20140110120439.GG29039@sirena.org.uk> (raw)
In-Reply-To: <20140110023537.GB16467@MrMyself>
[-- Attachment #1: Type: text/plain, Size: 1722 bytes --]
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 #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2014-01-10 12:04 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-09 10:57 [PATCH v2] ASoC: fsl_esai: Add ESAI CPU DAI driver Nicolin Chen
2014-01-09 10:57 ` Nicolin Chen
2014-01-09 10:57 ` Nicolin Chen
2014-01-09 18:44 ` Mark Brown
2014-01-09 18:44 ` Mark Brown
2014-01-09 18:44 ` Mark Brown
[not found] ` <20140110023252.GA16467@MrMyself>
2014-01-10 2:35 ` Nicolin Chen
2014-01-10 2:35 ` Nicolin Chen
2014-01-10 2:35 ` Nicolin Chen
2014-01-10 12:04 ` Mark Brown [this message]
2014-01-10 12:04 ` Mark Brown
2014-01-10 12:04 ` Mark Brown
2014-01-10 13:03 ` Nicolin Chen
2014-01-10 13:03 ` Nicolin Chen
2014-01-10 13:03 ` Nicolin Chen
2014-01-10 13:26 ` Mark Brown
2014-01-10 13:26 ` Mark Brown
2014-01-10 15:48 ` Nicolin Chen
2014-01-10 15:48 ` Nicolin Chen
2014-01-10 15:48 ` Nicolin Chen
2014-01-10 16:52 ` Mark Brown
2014-01-10 16:52 ` Mark Brown
2014-01-10 16:45 ` Nicolin Chen
2014-01-10 16:45 ` Nicolin Chen
2014-01-10 16:45 ` Nicolin Chen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140110120439.GG29039@sirena.org.uk \
--to=broonie@kernel.org \
--cc=Guangyu.Chen@freescale.com \
--cc=alsa-devel@alsa-project.org \
--cc=devicetree@vger.kernel.org \
--cc=galak@codeaurora.org \
--cc=grant.likely@linaro.org \
--cc=ijc+devicetree@hellion.org.uk \
--cc=lgirdwood@gmail.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mark.rutland@arm.com \
--cc=pawel.moll@arm.com \
--cc=rob@landley.net \
--cc=robh+dt@kernel.org \
--cc=shawn.guo@linaro.org \
--cc=timur@tabi.org \
--cc=tiwai@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.