All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lars-Peter Clausen <lars@metafoo.de>
To: Ricard Wanderlof <ricard.wanderlof@axis.com>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>
Subject: Re: simple-audio-card vs. platform question
Date: Thu, 29 Jan 2015 14:37:52 +0100	[thread overview]
Message-ID: <54CA37B0.2040503@metafoo.de> (raw)
In-Reply-To: <alpine.DEB.2.02.1501290938240.11532@lnxricardw1.se.axis.com>

On 01/29/2015 09:58 AM, Ricard Wanderlof wrote:
>
> On Tue, 27 Jan 2015, Lars-Peter Clausen wrote:
>
>>>> Usually in such a setup the CPU DAI driver also register the platform
>>>> component. Which then as the same of_node as the CPU DAI and so the matching
>>>> works. There are plenty of examples e.g. check the drivers using
>>>> devm_snd_dmaengine_pcm_register().
>>>
>>> Curious though, wouldn't it be more natural to bind it all together in the
>>> simple-audio-card DT entry, having a "simple-audio-card,platform"
>>> specification? Or is the idea that normally the CPU DAI driver is fairly
>>> tightly coupled to the PCM driver so it makes more sense to make that
>>> connection in the code?
>>
>> Usually there is no representation of the platform object in the devicetree.
>> E.g. typically this is a external shared DMA controller which is referenced
>> by the dmas property in the CPU DAI node.
>
> But perhaps there should be? As it is now, the I2S driver is bound in the
> code to the PCM driver using the devm_snd_dmaengine_pcm_register() call,
> which doesn't seem to fit in with the device tree philosphy of having the
> DT describe the hardware.
>
> Taking davinci-mcasp.c as an example, there's a bulk of #if's which govern
> calling the correct PCM driver depending on the setup, which is a bit
> cumbersome.
>
> Granted, having a platform description in the DT would not actually
> describe any specific hardware since as you said the DMA controller is
> normally described elsewhere, which would go against the DT philosophy.
>
> I'm not necessarily saying it would be better with a platform description
> in the DT, all things considered, just trying to understand why it may not
> be.

If you can make a compelling case that it should be added and that it 
describes the hardware that you have accurately I shouldn't be a problem to 
add it.

But in my opinion and experience the model where you have platform, CPU DAI, 
CODEC DAI is antiquated and does not match the modern hardware very well. 
We've started to restructure the ASoC framework to better accommodate the 
requirements of modern systems. And I'm hoping that once this restructuring 
is complete there will be no need for snd_soc_platform anymore.

>
> BTW, I can't find any DT in the kernel where the DMA is referenced in the
> CPU DAI node, all the DT's I can find which use simple-audio-card at least
> just reference the i2s device, which in turn references the DMA. Makes
> sense to me, perhaps that is what you meant?

Yes, that's what I meant.

- Lars

  reply	other threads:[~2015-01-29 13:37 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-27 12:01 simple-audio-card vs. platform question Ricard Wanderlof
2015-01-27 12:29 ` Lars-Peter Clausen
2015-01-27 16:31   ` Ricard Wanderlof
2015-01-27 18:11     ` Lars-Peter Clausen
2015-01-29  8:58       ` Ricard Wanderlof
2015-01-29 13:37         ` Lars-Peter Clausen [this message]
2015-01-29 17:05           ` Ricard Wanderlof

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=54CA37B0.2040503@metafoo.de \
    --to=lars@metafoo.de \
    --cc=alsa-devel@alsa-project.org \
    --cc=ricard.wanderlof@axis.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.