From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755140AbdLTMow convert rfc822-to-8bit (ORCPT ); Wed, 20 Dec 2017 07:44:52 -0500 Received: from mx07-00178001.pphosted.com ([62.209.51.94]:50390 "EHLO mx07-00178001.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754449AbdLTMou (ORCPT ); Wed, 20 Dec 2017 07:44:50 -0500 From: Olivier MOYSAN To: Mark Brown CC: "lgirdwood@gmail.com" , "perex@perex.cz" , "tiwai@suse.com" , "mcoquelin.stm32@gmail.com" , Alexandre TORGUE , "alsa-devel@alsa-project.org" , "linux-arm-kernel@lists.infradead.org" , "kernel@stlinux.com" , "linux-kernel@vger.kernel.org" , Arnaud POULIQUEN , Benjamin GAIGNARD , "patches@opensource.wolfsonmicro.com" Subject: Re: [RFC PATCH 2/2] ASoC: select sysclk clock from mlck clock provider in wm8994 driver Thread-Topic: [RFC PATCH 2/2] ASoC: select sysclk clock from mlck clock provider in wm8994 driver Thread-Index: AQHTdPx0zYMJOMWsoEelRgeNYpin66NDCWMAgAFq5ACABepLAIABxogA Date: Wed, 20 Dec 2017 12:42:10 +0000 Message-ID: References: <1513270438-18523-1-git-send-email-olivier.moysan@st.com> <1513270438-18523-3-git-send-email-olivier.moysan@st.com> <20171214173624.GM9788@sirena.org.uk> <43426b67-3546-8422-7fcb-9fa1ff192679@st.com> <20171219093506.GD8563@sirena.org.uk> In-Reply-To: <20171219093506.GD8563@sirena.org.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.75.127.45] Content-Type: text/plain; charset="Windows-1252" Content-ID: <1387522FCEF46D46814DDF041B87AEBA@st.com> Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-12-20_06:,, signatures=0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Mark, On 12/19/2017 10:35 AM, Mark Brown wrote: > On Fri, Dec 15, 2017 at 03:15:22PM +0000, Olivier MOYSAN wrote: > >> You are right. wm8994 allows to select either MCLK for each AIF. >> From this point of view, the current patch is too limiting. >> MCLK information in DT allows to enforce MCLK use, but an additionnal >> information is required to determine AIF MCLK assignment. >> Available properties in codec DAI node, such as clocks property, cannot >> help here. > >> Maybe a DAPM linked to a control is a better way to select AIF source, >> When source is not provided by clk_id in wm8994_set_dai_sysclk(). >> In this case, wm8994_set_dai_sysclk() would only have to check >> if clock source is not already set. > >> Please let me know if this option sounds better to you. > > What are you trying to accomplish here? You appear to be trying to move > the system clocking configuration from the machine driver to the CODEC > which is not how things are supposed to work. > As a generic machine, simple or audio graph cards are not able to manage codec clock muxing. If we exclude the management of muxing through codec controls, the remaining solution is to handle it fully through clock framework. The current patch only supports a limited range of muxing capabilities of the codec. To have a full management of the muxing, I think it is necessary to add a device tree node for each codec interface and to define an aif clock in these nodes. Then parent clock assignment of these aif clocks would allow to handle the muxing. Please, let me known if is this the right direction for you. BRs olivier From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olivier MOYSAN Subject: Re: [RFC PATCH 2/2] ASoC: select sysclk clock from mlck clock provider in wm8994 driver Date: Wed, 20 Dec 2017 12:42:10 +0000 Message-ID: References: <1513270438-18523-1-git-send-email-olivier.moysan@st.com> <1513270438-18523-3-git-send-email-olivier.moysan@st.com> <20171214173624.GM9788@sirena.org.uk> <43426b67-3546-8422-7fcb-9fa1ff192679@st.com> <20171219093506.GD8563@sirena.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx07-00178001.pphosted.com (mx07-00178001.pphosted.com [62.209.51.94]) by alsa0.perex.cz (Postfix) with ESMTP id 36575266BBC for ; Wed, 20 Dec 2017 13:42:14 +0100 (CET) In-Reply-To: <20171219093506.GD8563@sirena.org.uk> Content-Language: en-US Content-ID: <1387522FCEF46D46814DDF041B87AEBA@st.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org To: Mark Brown Cc: Benjamin GAIGNARD , "alsa-devel@alsa-project.org" , Alexandre TORGUE , "linux-kernel@vger.kernel.org" , "patches@opensource.wolfsonmicro.com" , Arnaud POULIQUEN , "tiwai@suse.com" , "lgirdwood@gmail.com" , "mcoquelin.stm32@gmail.com" , "linux-arm-kernel@lists.infradead.org" , "kernel@stlinux.com" List-Id: alsa-devel@alsa-project.org Hello Mark, On 12/19/2017 10:35 AM, Mark Brown wrote: > On Fri, Dec 15, 2017 at 03:15:22PM +0000, Olivier MOYSAN wrote: > >> You are right. wm8994 allows to select either MCLK for each AIF. >> From this point of view, the current patch is too limiting. >> MCLK information in DT allows to enforce MCLK use, but an additionnal >> information is required to determine AIF MCLK assignment. >> Available properties in codec DAI node, such as clocks property, cannot >> help here. > >> Maybe a DAPM linked to a control is a better way to select AIF source, >> When source is not provided by clk_id in wm8994_set_dai_sysclk(). >> In this case, wm8994_set_dai_sysclk() would only have to check >> if clock source is not already set. > >> Please let me know if this option sounds better to you. > > What are you trying to accomplish here? You appear to be trying to move > the system clocking configuration from the machine driver to the CODEC > which is not how things are supposed to work. > As a generic machine, simple or audio graph cards are not able to manage codec clock muxing. If we exclude the management of muxing through codec controls, the remaining solution is to handle it fully through clock framework. The current patch only supports a limited range of muxing capabilities of the codec. To have a full management of the muxing, I think it is necessary to add a device tree node for each codec interface and to define an aif clock in these nodes. Then parent clock assignment of these aif clocks would allow to handle the muxing. Please, let me known if is this the right direction for you. BRs olivier From mboxrd@z Thu Jan 1 00:00:00 1970 From: olivier.moysan@st.com (Olivier MOYSAN) Date: Wed, 20 Dec 2017 12:42:10 +0000 Subject: [RFC PATCH 2/2] ASoC: select sysclk clock from mlck clock provider in wm8994 driver In-Reply-To: <20171219093506.GD8563@sirena.org.uk> References: <1513270438-18523-1-git-send-email-olivier.moysan@st.com> <1513270438-18523-3-git-send-email-olivier.moysan@st.com> <20171214173624.GM9788@sirena.org.uk> <43426b67-3546-8422-7fcb-9fa1ff192679@st.com> <20171219093506.GD8563@sirena.org.uk> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hello Mark, On 12/19/2017 10:35 AM, Mark Brown wrote: > On Fri, Dec 15, 2017 at 03:15:22PM +0000, Olivier MOYSAN wrote: > >> You are right. wm8994 allows to select either MCLK for each AIF. >> From this point of view, the current patch is too limiting. >> MCLK information in DT allows to enforce MCLK use, but an additionnal >> information is required to determine AIF MCLK assignment. >> Available properties in codec DAI node, such as clocks property, cannot >> help here. > >> Maybe a DAPM linked to a control is a better way to select AIF source, >> When source is not provided by clk_id in wm8994_set_dai_sysclk(). >> In this case, wm8994_set_dai_sysclk() would only have to check >> if clock source is not already set. > >> Please let me know if this option sounds better to you. > > What are you trying to accomplish here? You appear to be trying to move > the system clocking configuration from the machine driver to the CODEC > which is not how things are supposed to work. > As a generic machine, simple or audio graph cards are not able to manage codec clock muxing. If we exclude the management of muxing through codec controls, the remaining solution is to handle it fully through clock framework. The current patch only supports a limited range of muxing capabilities of the codec. To have a full management of the muxing, I think it is necessary to add a device tree node for each codec interface and to define an aif clock in these nodes. Then parent clock assignment of these aif clocks would allow to handle the muxing. Please, let me known if is this the right direction for you. BRs olivier