All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Dong Aisheng <dongas86@gmail.com>
Cc: alsa-devel@alsa-project.org, Dong Aisheng <b29396@freescale.com>,
	s.hauer@pengutronix.de, linux-arm-kernel@lists.infradead.org,
	lrg@ti.com
Subject: Re: [PATCH 02/10] ASoc: mxs: add mxs-saif driver
Date: Sun, 10 Jul 2011 18:26:26 +0900	[thread overview]
Message-ID: <20110710092623.GB23521@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <CAA+hA=SBP3Qv0x-9KQMR+iT9nT1E6_HamyM7zeNd1p8rfE6V0g@mail.gmail.com>

On Sun, Jul 10, 2011 at 04:58:10PM +0800, Dong Aisheng wrote:
> 2011/7/10 Mark Brown <broonie@opensource.wolfsonmicro.com>:
> > On Sun, Jul 10, 2011 at 04:17:13PM +0800, Dong Aisheng wrote:

> >> The problem is that the codec may use the MCLK supplied by SAIF as its
> >> system clock for normal operations such as i2c r/w.

> > That may be true for your particular system but it is not going to be
> > true in general - most devices can handle having their MCLK removed.

> Yes, if i cover that, that may make driver a little complicated.
> Should i do that now or as the next work?

It should simply be a case of adding handling of setting the sysclk to 0
(this is how ASoC indicates clocks should be disabled).  The machine
driver is then responsible for making sure it does the refcounting
properly, and for your system where the clock is enabled all the time
that's just a case of enabling on startup and disabling on remove.

> Also i still do not have such type of codecs integrated on hand.

That's fine, audio hardware is so flexible that it's unreasonable to
expect that all possible systems have been tested.  So long as the code
looks sensible it should be fine and if there are problems people can
always come back and fix them.

> > This is the same issue as the above one with repeated enables?  You
> > should delegate the rate selection and ideally also the enable control
> > to the machine driver, it can set something in its probe() function.

> Not the same one. The repeated enables is a bug.(Will fix)

Yes, but both are a result of the requirements of your CODEC?  Just
trying to understand if the I2S controller needs this itself or if it's
only for the CODEC.

WARNING: multiple messages have this Message-ID (diff)
From: broonie@opensource.wolfsonmicro.com (Mark Brown)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 02/10] ASoc: mxs: add mxs-saif driver
Date: Sun, 10 Jul 2011 18:26:26 +0900	[thread overview]
Message-ID: <20110710092623.GB23521@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <CAA+hA=SBP3Qv0x-9KQMR+iT9nT1E6_HamyM7zeNd1p8rfE6V0g@mail.gmail.com>

On Sun, Jul 10, 2011 at 04:58:10PM +0800, Dong Aisheng wrote:
> 2011/7/10 Mark Brown <broonie@opensource.wolfsonmicro.com>:
> > On Sun, Jul 10, 2011 at 04:17:13PM +0800, Dong Aisheng wrote:

> >> The problem is that the codec may use the MCLK supplied by SAIF as its
> >> system clock for normal operations such as i2c r/w.

> > That may be true for your particular system but it is not going to be
> > true in general - most devices can handle having their MCLK removed.

> Yes, if i cover that, that may make driver a little complicated.
> Should i do that now or as the next work?

It should simply be a case of adding handling of setting the sysclk to 0
(this is how ASoC indicates clocks should be disabled).  The machine
driver is then responsible for making sure it does the refcounting
properly, and for your system where the clock is enabled all the time
that's just a case of enabling on startup and disabling on remove.

> Also i still do not have such type of codecs integrated on hand.

That's fine, audio hardware is so flexible that it's unreasonable to
expect that all possible systems have been tested.  So long as the code
looks sensible it should be fine and if there are problems people can
always come back and fix them.

> > This is the same issue as the above one with repeated enables? ?You
> > should delegate the rate selection and ideally also the enable control
> > to the machine driver, it can set something in its probe() function.

> Not the same one. The repeated enables is a bug.(Will fix)

Yes, but both are a result of the requirements of your CODEC?  Just
trying to understand if the I2S controller needs this itself or if it's
only for the CODEC.

  reply	other threads:[~2011-07-10  9:26 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-08 15:59 [PATCH 00/10] ARM: mxs: add audio support Dong Aisheng
2011-07-08 15:59 ` Dong Aisheng
2011-07-08 15:59 ` [PATCH 01/10] ASoc: mxs: add mxs-pcm driver Dong Aisheng
2011-07-08 15:59   ` Dong Aisheng
2011-07-09  2:33   ` Mark Brown
2011-07-09  2:33     ` Mark Brown
2011-07-10  6:28     ` Dong Aisheng
2011-07-10  6:28       ` Dong Aisheng
2011-07-10  8:21       ` Mark Brown
2011-07-10  8:21         ` Mark Brown
2011-07-08 15:59 ` [PATCH 02/10] ASoc: mxs: add mxs-saif driver Dong Aisheng
2011-07-08 15:59   ` Dong Aisheng
2011-07-08 16:19   ` Sascha Hauer
2011-07-08 16:19     ` Sascha Hauer
2011-07-08 17:10     ` Wolfram Sang
2011-07-08 17:10       ` Wolfram Sang
2011-07-08 18:35     ` Dong Aisheng
2011-07-08 18:35       ` Dong Aisheng
2011-07-09  2:52   ` Mark Brown
2011-07-09  2:52     ` Mark Brown
2011-07-10  8:17     ` Dong Aisheng
2011-07-10  8:17       ` Dong Aisheng
2011-07-10  8:34       ` Mark Brown
2011-07-10  8:34         ` Mark Brown
2011-07-10  8:58         ` Dong Aisheng
2011-07-10  8:58           ` Dong Aisheng
2011-07-10  9:26           ` Mark Brown [this message]
2011-07-10  9:26             ` Mark Brown
2011-07-10 11:59             ` Dong Aisheng
2011-07-10 11:59               ` Dong Aisheng
2011-07-11 10:00             ` Wolfram Sang
2011-07-11 10:00               ` Wolfram Sang
2011-07-13  3:28               ` Dong Aisheng-B29396
2011-07-13  3:28                 ` Dong Aisheng-B29396
2011-07-08 15:59 ` [PATCH 03/10] ASoc: mxs: add mxs-sgtl5000 machine driver Dong Aisheng
2011-07-08 15:59   ` Dong Aisheng
2011-07-09  3:00   ` Mark Brown
2011-07-09  3:00     ` Mark Brown
2011-07-10  8:36     ` Dong Aisheng
2011-07-10  8:36       ` Dong Aisheng
2011-07-10  8:40       ` Mark Brown
2011-07-10  8:40         ` Mark Brown
2011-07-08 15:59 ` [PATCH 04/10] ASoc: mxs: add asoc configuration files Dong Aisheng
2011-07-08 15:59   ` Dong Aisheng
2011-07-09  3:01   ` Mark Brown
2011-07-09  3:01     ` Mark Brown
2011-07-10  8:37     ` Dong Aisheng
2011-07-10  8:37       ` Dong Aisheng
2011-07-08 15:59 ` [PATCH 05/10] ARM: mxs: add saif clock Dong Aisheng
2011-07-08 15:59   ` Dong Aisheng
2011-07-08 15:59 ` [PATCH 06/10] ARM: mxs: add saif device Dong Aisheng
2011-07-08 15:59   ` Dong Aisheng
2011-07-08 15:59 ` [PATCH 07/10] ARM: mxs: add sgtl5000 i2c device Dong Aisheng
2011-07-08 15:59   ` Dong Aisheng
2011-07-08 15:59 ` [PATCH 08/10] ARM: mxs: add mxs-sgtl5000 device Dong Aisheng
2011-07-08 15:59   ` Dong Aisheng
2011-07-08 15:59 ` [PATCH 09/10] ARM: mxs: correct the using of frac div for saif Dong Aisheng
2011-07-08 15:59   ` Dong Aisheng
2011-07-08 15:59 ` [PATCH 10/10] ARM: mxs-dma: include <linux/dmaengine.h> Dong Aisheng
2011-07-08 15:59   ` Dong Aisheng

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=20110710092623.GB23521@opensource.wolfsonmicro.com \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=b29396@freescale.com \
    --cc=dongas86@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=lrg@ti.com \
    --cc=s.hauer@pengutronix.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.