linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sonny Rao <sonnyrao@chromium.org>
To: Mark Brown <broonie@kernel.org>
Cc: "Jianqun Xu" <jay.xu@rock-chips.com>,
	"Liam Girdwood" <lgirdwood@gmail.com>,
	perex@perex.cz, tiwai@suse.de, "Heiko Stübner" <heiko@sntech.de>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	alsa-devel@alsa-project.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	linux-rockchip@lists.infradead.org
Subject: Re: [PATCH v2 2/2] ASoC: rockchip: i2s: add support for grabbing output clock to codec
Date: Wed, 3 Dec 2014 15:03:40 -0800	[thread overview]
Message-ID: <CAPz6YkWSQhqX-wAp5hZReo==MuG_Tju_0mk+kGrJo9XhjQ3ttA@mail.gmail.com> (raw)
In-Reply-To: <20141203200307.GM7712@sirena.org.uk>

On Wed, Dec 3, 2014 at 12:03 PM, Mark Brown <broonie@kernel.org> wrote:
> On Wed, Dec 03, 2014 at 11:38:13AM -0800, Sonny Rao wrote:
>> On Wed, Dec 3, 2014 at 11:20 AM, Mark Brown <broonie@kernel.org> wrote:
>
>> > I would expect that the clock for the CODEC should be managed by the
>> > CODEC if at all possible - that seems more logical than having the CPU
>> > I2S controller request and manage it if it's a separate clock.  Why add
>> > this to the CPU side driver?
>
>> This output clock has a mux and can either be a fixed 12Mhz output or
>> can be derived from the same fractional divider which drives the i2s
>> block.   I thought it was simpler to keep them all the same, but need
>> to put ownership in the i2s in anticipation of the i2s driver setting
>> it's own clock rate.
>
>> If you think this is an implementation detail and this output clock
>> should just be owned by the codec driver, even though I'm guessing it
>> will just have to be the same as i2s, then I think we can drop this
>> and make sure simple card (or whatever other codec driver) claims this
>> clock.
>
> simple-card obviously isn't a CODEC driver...

Yeah, sorry.

> For generality I think
> the clock does need to be exposed to the CODEC driver, otherwise this
> will work differently to how other systems are working and we can't
> substitute in a different clock on the CODEC side so easily if it
> doesn't happen to use the output from the I2S block.

Ok, then I think what we will do is abandon this patch and I will send
something that adds this functionality to the particular codec that
I'm interested in -- max98090.

I'm a little tied up at the moment so I'm not going to send that for a
little while, but will come eventually.

Thanks for the advice!

  reply	other threads:[~2014-12-03 23:04 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-02 14:49 [PATCH 0/2] rockchip: i2s: patches to add optional clock output from Jianqun Xu
2014-12-02 14:49 ` [PATCH 1/2] ASoC: rockchip-i2s: dt: add an optional property "i2s_clk_out" Jianqun Xu
2014-12-02 17:57   ` Doug Anderson
2014-12-02 14:52 ` [PATCH 2/2] ASoC: rockchip: i2s: add support for grabbing output clock to codec Jianqun Xu
2014-12-02 17:54   ` Doug Anderson
2014-12-03  1:03     ` Jianqun
2014-12-03  5:18       ` Doug Anderson
2014-12-03 12:55         ` Mark Brown
2014-12-03  7:18 ` [PATCH v2 0/2] ASoC: rockchip: i2s: driver could output "i2s-clk-out" optionally Jianqun Xu
2014-12-03  7:18   ` [PATCH v2 1/2] ASoC: dt-bindings: rockchip-i2s: add an optional property "i2s_clk_out" Jianqun Xu
2014-12-03  7:18   ` [PATCH v2 2/2] ASoC: rockchip: i2s: add support for grabbing output clock to codec Jianqun Xu
2014-12-03 19:20     ` Mark Brown
2014-12-03 19:38       ` Sonny Rao
2014-12-03 20:03         ` Mark Brown
2014-12-03 23:03           ` Sonny Rao [this message]
2014-12-03 23:22             ` [alsa-devel] " Dylan Reid
2014-12-03 23:52               ` Sonny Rao
  -- strict thread matches above, loose matches on Subject: below --
2014-11-19  3:07 [PATCH " Jianqun Xu
2014-11-19  8:09 ` [PATCH v2 " Jianqun Xu
2014-11-19 10:17   ` Heiko Stübner
2014-11-19 10:27   ` Kever Yang

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='CAPz6YkWSQhqX-wAp5hZReo==MuG_Tju_0mk+kGrJo9XhjQ3ttA@mail.gmail.com' \
    --to=sonnyrao@chromium.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=heiko@sntech.de \
    --cc=jay.xu@rock-chips.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=perex@perex.cz \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).