All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Ujfalusi <peter.ujfalusi@ti.com>
To: 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>,
	"Kristo, Tero" <t-kristo@ti.com>, <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 14:52:11 +0300	[thread overview]
Message-ID: <571A106B.8040301@ti.com> (raw)
In-Reply-To: <20160421222911.GE13149@codeaurora.org>

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.

-- 
Péter

WARNING: multiple messages have this Message-ID (diff)
From: Peter Ujfalusi <peter.ujfalusi@ti.com>
To: 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>,
	"Kristo, Tero" <t-kristo@ti.com>,
	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 14:52:11 +0300	[thread overview]
Message-ID: <571A106B.8040301@ti.com> (raw)
In-Reply-To: <20160421222911.GE13149@codeaurora.org>

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.

-- 
Péter

  reply	other threads:[~2016-04-22 11:52 UTC|newest]

Thread overview: 30+ 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 [this message]
2016-04-22 11:52                         ` Peter Ujfalusi
2016-04-22 12:08                         ` Tero Kristo
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-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=571A106B.8040301@ti.com \
    --to=peter.ujfalusi@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=sboyd@codeaurora.org \
    --cc=t-kristo@ti.com \
    /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.