From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1754821AbcHWQp2 (ORCPT <rfc822;w@1wt.eu>);
        Tue, 23 Aug 2016 12:45:28 -0400
Received: from mailout3.w1.samsung.com ([210.118.77.13]:64556 "EHLO
        mailout3.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1752266AbcHWQp0 (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 23 Aug 2016 12:45:26 -0400
X-AuditID: cbfec7f4-f796c6d000001486-68-57bc7da27d26
Subject: Re: [alsa-devel] [RFC PATCH] mfd: arizona: Add gating of external
 MCLKn clocks
To: Mark Brown <broonie@kernel.org>
References: <1471627036-19465-1-git-send-email-s.nawrocki@samsung.com>
 <20160822092233.GN21682@localhost.localdomain>
 <d47e7106-037f-b40c-71e5-099ee30874e6@samsung.com>
 <20160822174104.GT22076@sirena.org.uk>
Cc: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>,
        alsa-devel@alsa-project.org, lee.jones@linaro.org,
        linux-kernel@vger.kernel.org
From: Sylwester Nawrocki <s.nawrocki@samsung.com>
Message-id: <0c0378e7-918b-1545-1655-43293aed4c8d@samsung.com>
Date: Tue, 23 Aug 2016 18:44:57 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.2.0
MIME-version: 1.0
In-reply-to: <20160822174104.GT22076@sirena.org.uk>
Content-type: text/plain; charset=windows-1252
Content-transfer-encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsVy+t/xy7qLaveEG+z5pGhx5eIhJoupD5+w
        WfybcoPd4v7Xo4wWl3fNYXNg9djwuYnNY9OqTjaPO9f2sHm8nPibzePzJrkA1igum5TUnMyy
        1CJ9uwSujClXVjAWfGSveP7QoYFxKVsXIyeHhICJxK+vPVC2mMSFe+uBbC4OIYGljBIPvp5l
        hHCeM0p8et7JDlIlLBApsXjpJ7AOEQFliavf97KA2EICVxkldr31A2lgFuhmlJi9fTszSIJN
        wFCi92gfI4jNK2An8ebeKrAGFgFViYuzN4PZogIRErdWfYSqEZT4MfkeWJxTwFhiQ+dboDkc
        QEP1JO5f1AIJMwvIS2xe85Z5AqPALCQdsxCqZiGpWsDIvIpRNLU0uaA4KT3XUK84Mbe4NC9d
        Lzk/dxMjJJy/7GBcfMzqEKMAB6MSD29HyJ5wIdbEsuLK3EOMEhzMSiK8VtVAId6UxMqq1KL8
        +KLSnNTiQ4zSHCxK4rxzd70PERJITyxJzU5NLUgtgskycXBKNTBuYJo250qkZOd0i7eue/OX
        PLn/Quz8lIOCG76nM6+wMA84/XxDgU6KJu+HmaeifxacfnfX2CvkeAHz/Nsh72wFdig+Eky1
        Dnh7SefvfrvoILETYduPHpjOkzBNvy3P5liQV4vp2m7m6a/aAuacdT7qG7jtdHX0ln7mTMUv
        vQcFLcIrneXldBqUWIozEg21mIuKEwE3hg6DYwIAAA==
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 08/22/2016 07:41 PM, Mark Brown wrote:
> On Mon, Aug 22, 2016 at 07:22:47PM +0200, Sylwester Nawrocki wrote:
> 
>> If we provided an interface like:
> 
>> struct clk * arizona_get_mclk(struct arizona *arizona, int id);
>> void arizona_put_mclk(struct clk *clk);
> 
>> the machine driver would need to get hold of struct arizona*,
>> which is not that straightforward if we are given only CODEC
>> of_node (it can be a child of I2C or SPI bus).
> 
> We could add an interface for the machine driver to retrieve a clock
> from the CODEC as a transition measure...

That works for me. Is the long term plan to control the CODEC's clocks
through the common clock API in machine drivers and phase out calls
like snd_soc_codec_set_pll(), snd_soc_codec_set_sysclk()?

>> Then how about specifying MCLK in the sound node and using
>> regular devm_clk_get()?
> 
> This is what we're trying to avoid?

Indeed, sorry, I just started getting confused of what are acceptable
tradeoffs here.