From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Jon Smirl <jonsmirl@gmail.com>
Cc: alsa-devel@alsa-project.org, Timur Tabi <timur@freescale.com>
Subject: Re: [PATCH][ASoC v2] Update Freescale MPC8610HPCD fabric driver to support multiple codecs
Date: Fri, 13 Jun 2008 19:59:42 +0100 [thread overview]
Message-ID: <20080613185942.GB12536@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <9e4733910806130959m5cfbefbbo747642789190c285@mail.gmail.com>
On Fri, Jun 13, 2008 at 12:59:44PM -0400, Jon Smirl wrote:
> In the PowerPC world the ssi drivers are loaded based on the device
> tree. When the ssi driver loads it gets passed in it's device tree
> node and can see what codecs are on its bus.
> Codecs get loaded two ways, if they are i2c based the i2c subsystem
> loaded them. That's because of the PowerPC rule that the controlling
> bus should load the driver. If it is an AC97/HDA codec, the ssi code
> needs to trigger the loading since the AC97/HDA bus is the controlling
> bus.
This is no different to any other system.
> After the codec is loaded it may need parameters from the device tree.
> My though was to have two mechanisms. First a very simple one where
> the SSI driver just copies the parameters from the device tree into
> the codec. That removes the need for platform specific code from the
> codec driver. The simple copy should be enough for AC97/HDA.
> In the second case the SSI would have a call out into the fabric code.
> If the simple copy isn't enough the fabric code can do whatever
> complicated things it needs to do. This is the case in my hardware,
> the fabric driver needs to set up the external clock chip.
I'm not seeing much substantial difference between the two cases here:
in both of them you look at the system and load a machine driver, it's
just that in the first case the machine driver happens to be a generic
one that gets more of what it needs from the device tree.
> The basic concept is that there is one SSI driver per device and a
> single global fabric driver. So anything that needs to be done on a
> per ssi case needs to go into the ssi driver. Making the soc
> structures and attaching the codec is a per ssi task, so the code
Remember that if there's more than one SSI<->codec link they may not be
independant of each other. For example, a six channel DAC could be
connected to three stereo I2S ports on the SoC with shared clock
signals. You can also get codec<->codec links (for example, separate
ADC and DAC parts or Bluetooth devices) which bypass the SoC entirely.
It may be that you just intend to wrap all these cases up in your "or
load a machine driver" case, I'm not clear.
> should go into the ssi driver. There's on a single, global fabric
> driver, that's why Timur had to add a loop initializing the ssi
> drivers.
There's one machine driver per system in V1, but one of the intentions
going forward is to remove that limitation. IIRC it may already be
possible to have more than one SoC card in V2 but I don't know if anyone
actually did that yet.
next prev parent reply other threads:[~2008-06-13 18:59 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-13 0:01 [PATCH][ASoC v2] Update Freescale MPC8610HPCD fabric driver to support multiple codecs Timur Tabi
2008-06-13 2:22 ` Jon Smirl
2008-06-13 12:08 ` Timur Tabi
2008-06-13 2:57 ` Jon Smirl
2008-06-13 3:16 ` Jon Smirl
2008-06-13 3:36 ` Jon Smirl
2008-06-13 12:17 ` Timur Tabi
2008-06-13 15:04 ` Mark Brown
2008-06-13 15:10 ` Jon Smirl
2008-06-13 15:13 ` Timur Tabi
2008-06-13 15:26 ` Jon Smirl
2008-06-13 15:57 ` Mark Brown
2008-06-13 16:59 ` Jon Smirl
2008-06-13 18:40 ` Timur Tabi
2008-06-13 18:59 ` Mark Brown [this message]
2008-06-13 19:25 ` Jon Smirl
2008-06-13 20:04 ` Liam Girdwood
2008-06-13 22:42 ` Mark Brown
2008-06-13 12:11 ` Timur Tabi
2008-06-13 13:42 ` Mark Brown
2008-06-13 14:10 ` Jon Smirl
2008-06-13 14:26 ` Timur Tabi
2008-06-13 14:29 ` Jon Smirl
2008-06-13 14:32 ` Timur Tabi
2008-06-13 14:36 ` Jon Smirl
2008-06-13 14:39 ` Timur Tabi
2008-06-13 9:53 ` Mark Brown
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=20080613185942.GB12536@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=alsa-devel@alsa-project.org \
--cc=jonsmirl@gmail.com \
--cc=timur@freescale.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.