All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tero Kristo <t-kristo@ti.com>
To: Peter Ujfalusi <peter.ujfalusi@ti.com>,
	Stephen Boyd <sboyd@codeaurora.org>,
	Mark Brown <broonie@kernel.org>
Cc: alsa-devel@alsa-project.org,
	Michael Turquette <mturquette@baylibre.com>,
	Liam Girdwood <lgirdwood@gmail.com>, Jyri Sarha <jsarha@ti.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	linux-clk@vger.kernel.org
Subject: Re: [alsa-devel] [PATCH 4/4] ASoC: simple-card: Support for selecting system clocks by ID
Date: Fri, 22 Apr 2016 15:08:43 +0300	[thread overview]
Message-ID: <571A144B.7000203@ti.com> (raw)
In-Reply-To: <571A106B.8040301@ti.com>

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

WARNING: multiple messages have this Message-ID (diff)
From: Tero Kristo <t-kristo@ti.com>
To: Peter Ujfalusi <peter.ujfalusi@ti.com>,
	Stephen Boyd <sboyd@codeaurora.org>,
	Mark Brown <broonie@kernel.org>
Cc: <alsa-devel@alsa-project.org>,
	Michael Turquette <mturquette@baylibre.com>,
	Liam Girdwood <lgirdwood@gmail.com>, Jyri Sarha <jsarha@ti.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	<linux-clk@vger.kernel.org>
Subject: Re: [alsa-devel] [PATCH 4/4] ASoC: simple-card: Support for selecting system clocks by ID
Date: Fri, 22 Apr 2016 15:08:43 +0300	[thread overview]
Message-ID: <571A144B.7000203@ti.com> (raw)
In-Reply-To: <571A106B.8040301@ti.com>

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

  reply	other threads:[~2016-04-22 12:08 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-15 14:11 [PATCH 0/4] ASoC: simple-card/davinci-mcasp: System clock configuration support Peter Ujfalusi
2016-02-15 14:11 ` [PATCH 1/4] ASoC: davinci-mcasp: Use defines for clkdiv IDs via DT binding header Peter Ujfalusi
2016-02-15 14:11 ` [PATCH 2/4] ASoC: davinci-mcasp: Improve the sysclk selection Peter Ujfalusi
2016-02-15 14:11 ` [PATCH 3/4] ASoC: simple-card: Add system-clock-direction DT parameter to dai nodes Peter Ujfalusi
2016-02-15 14:11 ` [PATCH 4/4] ASoC: simple-card: Support for selecting system clocks by ID Peter Ujfalusi
2016-02-15 15:26   ` Mark Brown
2016-02-16  9:46     ` Peter Ujfalusi
2016-02-16  9:46       ` Peter Ujfalusi
2016-02-16 13:42       ` Mark Brown
2016-02-16 19:13         ` Michael Turquette
2016-02-16 19:13           ` Michael Turquette
2016-02-17  8:13           ` Peter Ujfalusi
2016-02-17  8:13             ` Peter Ujfalusi
2016-02-17 12:07             ` Mark Brown
2016-02-17 19:52               ` Peter Ujfalusi
2016-02-17 19:52                 ` Peter Ujfalusi
2016-04-18 15:50                 ` [alsa-devel] " Peter Ujfalusi
2016-04-18 15:50                   ` Peter Ujfalusi
2016-04-18 16:29                   ` Mark Brown
2016-04-21 22:29                     ` Stephen Boyd
2016-04-22 11:52                       ` Peter Ujfalusi
2016-04-22 11:52                         ` Peter Ujfalusi
2016-04-22 12:08                         ` Tero Kristo [this message]
2016-04-22 12:08                           ` Tero Kristo
2016-02-17 11:31           ` Mark Brown
2016-02-17 14:18           ` [alsa-devel] " Ricard Wanderlof
2016-02-17 14:18             ` Ricard Wanderlof
2016-02-22  3:21             ` Mark Brown
2016-02-16 12:46     ` Andreas Irestål

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=571A144B.7000203@ti.com \
    --to=t-kristo@ti.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=jsarha@ti.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mturquette@baylibre.com \
    --cc=peter.ujfalusi@ti.com \
    --cc=sboyd@codeaurora.org \
    /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 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.