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.
next prev parent 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: linkBe 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.