From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752201AbcDVMI4 (ORCPT ); Fri, 22 Apr 2016 08:08:56 -0400 Received: from arroyo.ext.ti.com ([192.94.94.40]:44616 "EHLO arroyo.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751664AbcDVMIz (ORCPT ); Fri, 22 Apr 2016 08:08:55 -0400 Subject: Re: [alsa-devel] [PATCH 4/4] ASoC: simple-card: Support for selecting system clocks by ID To: Peter Ujfalusi , Stephen Boyd , Mark Brown References: <1455545495-20292-5-git-send-email-peter.ujfalusi@ti.com> <20160215152635.GN18988@sirena.org.uk> <56C2F00C.8080809@ti.com> <20160216134233.GN18327@sirena.org.uk> <20160216191346.2278.725@quark.deferred.io> <56C42BAF.3050900@ti.com> <20160217120759.GO7544@sirena.org.uk> <56C4CF8B.5010005@ti.com> <5715025C.7070108@ti.com> <20160418162910.GG3217@sirena.org.uk> <20160421222911.GE13149@codeaurora.org> <571A106B.8040301@ti.com> CC: , Michael Turquette , Liam Girdwood , Jyri Sarha , "linux-kernel@vger.kernel.org" , From: Tero Kristo Message-ID: <571A144B.7000203@ti.com> Date: Fri, 22 Apr 2016 15:08:43 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <571A106B.8040301@ti.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 22/04/16 14:52, Peter Ujfalusi wrote: > On 04/22/16 01:29, Stephen Boyd wrote: >>>> The first issue with converting the McASP to use CCF internally for clock >>>> selection, muxing and rate configuration is that the daVinci platform does not >>>> use CCF at all. Given that the davinci-mcasp driver is used by daVinci, we >>>> need to have non CCF way supported in ASoC... >>> >>> Well, at least long term we do need daVinci converting to CCF - this is >>> going to continue to cause problems, devices not part of the SoC can and >>> do contain clocks and are going to end up being supported via the clock >>> API. >> >> Does anyone here know what's involved in converting daVinci to >> CCF? It doesn't look too far off from what is in the CCF today, >> so I'm not sure what's blocking the transition. > > Not entirely sure, but most likely new clk driver(s) for daVinci under > drivers/clk/ti/ new set of structures to describe the clocks if the ti_clk* is > not applicable I guess for starter. Support for DT, non DT boots as most of > daVinci is not booting with DT and most likely never will. > It might help to have different daVinci boards for testing the transition. I > only have OMAP-L138-evm. I don't think it is enough for testing an entire > architecture for this big change... > > Tero might have better estimates on what is involved when switching an > architecture to CCF from custom, but at least synchronized API - so we don't > need to convert drivers at least. > Davinci is currently a mutant architecture, it is overriding the common clk APIs and using its own. Converting these to CCF may open a can of worms in many ways. All the clock data should be converted to support CCF, (from arch/arm/mach-davinci/), along with whatever Peter said. This also in a situation where many/most upstream people don't even have davinci devices... Personally I have a grand total of zero davinci boards on my desk so at least I am unable to work on this right now. -Tero