alsa-devel.alsa-project.org archive mirror
 help / color / mirror / Atom feed
From: Timur Tabi <timur@freescale.com>
To: Liam Girdwood <lg@opensource.wolfsonmicro.com>
Cc: alsa-devel@alsa-project.org
Subject: Re: Question on snd_soc_dai_link
Date: Mon, 28 May 2007 20:36:52 -0500	[thread overview]
Message-ID: <465B83B4.4000801@freescale.com> (raw)
In-Reply-To: <1180354777.5816.39.camel@a10072.wolfsonmicro.main>

Liam Girdwood wrote:

>> The problem I'm having with this approach is that everything is hard-coded.  On PowerPC, 
>> this approach doesn't work well, because we have a "device tree" that dictates what 
>> devices are present on the SOC.
> 
> Fwiw, ASoC was designed to only handle static DAI mappings between a
> codec and SoC CPU. 

On PowerPC, the mapping *is* static, but unknown until boot time.  OK, maybe that's not what you meant by static.

> This is because the audio codec was never intended to
> physically change DAI at runtime or be probed (most codecs don't support
> any device readback). The DAI mapping between CPU and codec was constant
> and always known to the machine driver.

On PowerPC, the device tree contains information about the board that cannot be obtained via probing the hardware.  Well, sometimes it contains information that *could* be obtained by probing, but that information is there only for probing.  The idea is that we can use a device tree to store device-specific information (like the I2C bus address) instead of passing command-line parameters to the device drivers.

> Although, I can now see the need for a more dynamic approach for PowerPC
> based systems. Btw, I'm not very familiar with PowerPC, would you be
> able to point me at some example "device tree" initialisation code.

All of the device trees are in arch/powerpc/boot/dts/.  A detailed description of the layout can be found in booting_without_of.txt.

In summary, the device tree is a hierarchy of "nodes", where each node lists a device (usually some controller on the SOC or some peripheral on the board), its address (e.g. the base address of the device's memory mapped registers), and a bunch of properties that the driver needs to initialize and communicate with the device.

I have not yet figured out how to represent the codec in the device tree.  In this particular case, the problem is unusual in that there is no I2C bus connected, so there's no way to control the codec, and so there's not much need for a node.

  reply	other threads:[~2007-05-29  1:35 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-25 21:55 Question on snd_soc_dai_link Timur Tabi
2007-05-28 12:19 ` Liam Girdwood
2007-05-29  1:36   ` Timur Tabi [this message]
2007-05-29 14:19     ` Liam Girdwood
2007-05-29 14:36       ` Timur Tabi
2007-05-29 14:51         ` Liam Girdwood

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=465B83B4.4000801@freescale.com \
    --to=timur@freescale.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=lg@opensource.wolfsonmicro.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).