On Fri, Apr 30, 2010 at 4:46 PM, Timur Tabi wrote:
> When I boot Linux, I get this:
>
> asoc: cs4270 <-> /s...@e000/s...@16000 mapping ok
> sysfs: cannot create duplicate filename '/devices/platform/soc-audio/cs4270'
*sigh* never mind. The problem was that the stream_name was the same
for b
On Tue, Apr 27, 2010 at 10:20 AM, Liam Girdwood wrote:
>> Another problem is that ASoC won't let me probe the DMA channels
>> independently. That is, I cannot tell ASoC that I have a playback DMA
>> and a capture DMA. ASoC does not recognize two DMA devices for a
>> single SSI. If you can fix
On Wed, Apr 28, 2010 at 6:52 PM, Benjamin Herrenschmidt
wrote:
> On Wed, 2010-04-28 at 17:13 -0500, Timur Tabi wrote:
>> On Wed, Apr 28, 2010 at 4:58 PM, Grant Likely
>> wrote:
>>
>> > The sound0 node needs a compatible value,
>>
>> I knew I was forgetting something
>>
>> > the sound-device node
On Wed, Apr 28, 2010 at 6:36 PM, Benjamin Herrenschmidt
wrote:
> On Wed, 2010-04-28 at 13:07 +0100, Mark Brown wrote:
>> > The device-tree helps keep the platform .c file simple and devoid of too
>> > horrible hacks, it allows to easily pass various configuration data to
>> > leaf drivers such as
On Wed, 2010-04-28 at 17:13 -0500, Timur Tabi wrote:
> On Wed, Apr 28, 2010 at 4:58 PM, Grant Likely
> wrote:
>
> > The sound0 node needs a compatible value,
>
> I knew I was forgetting something
>
> > the sound-device node should
> > probably have one too.
>
> The aliases, cpus, and memory n
On Wed, 2010-04-28 at 15:35 -0500, Timur Tabi wrote:
> Second, how about this binding for the virtual sound node? It would
> be a root-level node.
>
> sound-devices {
> sound0 {
> ssi = &ssi0;
> playback-dma = &dma00;
>
On Wed, 2010-04-28 at 14:00 +0100, Mark Brown wrote:
> > The whole thing is a matter of common sense and a bit of taste :-)
>
> The impression that has been created in the past is that there are
> inflexible device tree rules which can't be varied.
I'm a bit sad this is how things have been perce
On Wed, 2010-04-28 at 13:07 +0100, Mark Brown wrote:
> > The device-tree helps keep the platform .c file simple and devoid of too
> > horrible hacks, it allows to easily pass various configuration data to
> > leaf drivers such as i2c thingies, PHY devices etc... without gross
> > hooks between thes
On Wed, Apr 28, 2010 at 4:13 PM, Timur Tabi wrote:
> On Wed, Apr 28, 2010 at 4:58 PM, Grant Likely
> wrote:
>
>> The sound0 node needs a compatible value,
>
> I knew I was forgetting something
:-)
>
>> the sound-device node should
>> probably have one too.
>
> The aliases, cpus, and memory nod
On Wed, Apr 28, 2010 at 4:58 PM, Grant Likely wrote:
> The sound0 node needs a compatible value,
I knew I was forgetting something
> the sound-device node should
> probably have one too.
The aliases, cpus, and memory node don't have a compatible property,
and I was modeling the design after th
On Wed, Apr 28, 2010 at 2:35 PM, Timur Tabi wrote:
> On Tue, Apr 27, 2010 at 5:09 AM, Benjamin Herrenschmidt
> wrote:
>
>> Keep in mind that it's perfectly kosher to create nodes for "virtual"
>> devices. IE. We could imagine a node for the "sound subsystem" that
>> doesn't actually correspond to
On Tue, Apr 27, 2010 at 5:09 AM, Benjamin Herrenschmidt
wrote:
> Keep in mind that it's perfectly kosher to create nodes for "virtual"
> devices. IE. We could imagine a node for the "sound subsystem" that
> doesn't actually correspond to any physical device but contain the
> necessary properties
Grant Likely wrote:
> Didn't you just finish saying that you cannot see any situation where
> you would want the SSI devices linked into a single audio device? So
> then if both SSIs are being used for audio, then do you not need a
> machine driver for each ssi?
That's right. But in order for m
On Wed, Apr 28, 2010 at 10:20 AM, Timur Tabi wrote:
> On Wed, Apr 28, 2010 at 8:57 AM, Grant Likely
> wrote:
>
>> I'm just saying move the registration of the machine device out of
>> arch/powerpc platform code and into the ssi driver.
>
> But the SSI driver is an OF driver, and it gets probed f
On Wed, Apr 28, 2010 at 8:57 AM, Grant Likely wrote:
> I'm just saying move the registration of the machine device out of
> arch/powerpc platform code and into the ssi driver.
But the SSI driver is an OF driver, and it gets probed for every SSI
node in the device tree. On the 8610, that means b
On Wed, Apr 28, 2010 at 7:35 AM, Timur Tabi wrote:
> On Wed, Apr 28, 2010 at 12:37 AM, Grant Likely
> wrote:
>
>> Why not? Just have the ssi driver probe routine register the fabric
>> device based on the existence of the codec-handle property. It is the
>> best way to go about things with the
On Wed, Apr 28, 2010 at 08:19:00AM -0500, Timur Tabi wrote:
> On Tue, Apr 27, 2010 at 5:29 PM, Mark Brown
> > You also want to be representing unused pins here.
> If they're unused, how do I represent them? Can you give me an example?
You should arrange for something to call snd_soc_dapm_nc_pin
On Wed, Apr 28, 2010 at 12:37 AM, Grant Likely
wrote:
> Why not? Just have the ssi driver probe routine register the fabric
> device based on the existence of the codec-handle property. It is the
> best way to go about things with the data that you've got available,
> and it is no big deal. Th
On Tue, Apr 27, 2010 at 5:29 PM, Mark Brown
wrote:
>> codec1 :co...@4f {
>> compatible = "cirrus,cs4270";
>> reg = <0x4f>;
>> /* MCLK source is a stand-alone oscillator */
>> clock-frequency = <1
On Wed, Apr 28, 2010 at 02:25:29PM +1000, Benjamin Herrenschmidt wrote:
> I'd stay stick to the basics and move incrementally up until it stops
> making sense:
> - First, the basics: nodes for actual physical devices. i2c codecs on
> their i2c busses, DMA controllers, etc...
This is already sup
On Tue, 2010-04-27 at 14:27 -0600, Grant Likely wrote:
>
> Unfortunately, I'm in the same boat. :-( However, I'll be at UDS in
> 2 weeks time, and I know audio is a big concern for the Ubuntu folks.
> A bunch of the ARM vendors will be there too. I'll schedule a session
> to talk about audio b
On Wed, Apr 28, 2010 at 02:10:11PM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2010-04-27 at 23:29 +0100, Mark Brown wrote:
> > On the other hand from a pragmatic point of view it's just much less
> > hassle to just only provide the mechanism for instantiating a machine
> > with custom code and
On Tue, Apr 27, 2010 at 08:31:18PM -0600, Grant Likely wrote:
> On Tue, Apr 27, 2010 at 4:29 PM, Mark Brown
> > On the other hand from a pragmatic point of view it's just much less
> > hassle to just only provide the mechanism for instantiating a machine
> > with custom code and use that for every
On Tue, Apr 27, 2010 at 2:46 PM, Timur Tabi wrote:
> Grant Likely wrote:
>
>> So, the current 86xx device tree binding assumes a simple layout with
>> a node describing an DAI controller, and another node describing the
>> codec with a single phandle (pointer) from the DAI to the codec. In
>> thi
On Tue, 2010-04-27 at 21:59 +0100, Mark Brown wrote:
> It's entirely possible that if the board designer intended the verious
> SSIs to be used in concert they've done something like cross wire the
> clocks which creates a board-specific interrelationship that needs to
> be dealt with.
In which c
On Tue, 2010-04-27 at 15:04 -0500, Timur Tabi wrote:
> What I need is something like a hashing function that can convert a
> "struct device_node *" into an "int". I'm going to have two functions
> that independently parse the device tree and locate a specific node.
> Both functions will "register
On Tue, 2010-04-27 at 13:15 -0600, Grant Likely wrote:
>
> Can you not dynamically assign an id? If alsa soc needs a unique id
> number, then just create a lookup function. Something like
> of_asoc_phandle_to_codec_id() that will either return a previously
> assigned id, or will assign a new id.
On Tue, 2010-04-27 at 23:29 +0100, Mark Brown wrote:
>
> On the other hand from a pragmatic point of view it's just much less
> hassle to just only provide the mechanism for instantiating a machine
> with custom code and use that for everything.
Right, that's the balance to find. A too descriptiv
On Tue, Apr 27, 2010 at 4:29 PM, Mark Brown
wrote:
> On Tue, Apr 27, 2010 at 02:24:34PM -0600, Grant Likely wrote:
>
>> However, as you and Mark rightly point out, it completely fails to
>> represent complex sound devices with weird clocking and strange
>> routes. Something like this is probably
On Tue, Apr 27, 2010 at 02:24:34PM -0600, Grant Likely wrote:
> However, as you and Mark rightly point out, it completely fails to
> represent complex sound devices with weird clocking and strange
> routes. Something like this is probably more appropriate:
>
> [...]
> codec1
On Tue, Apr 27, 2010 at 04:03:27PM -0500, Timur Tabi wrote:
[Reflowing the text into 80 columns again]
> Mark Brown wrote:
> > It's entirely possible that if the board designer intended the verious
> > SSIs to be used in concert they've done something like cross wire the
> > clocks which creates
Mark Brown wrote:
> It's entirely possible that if the board designer intended the verious
> SSIs to be used in concert they've done something like cross wire the
> clocks which creates a board-specific interrelationship that needs to be
> dealt with.
Fine, but I don't see how that can be handled
On Tue, Apr 27, 2010 at 03:46:04PM -0500, Timur Tabi wrote:
[Reflowed into 80 columns; please fix your mail client.]
> > (I've omitted the DMA nodes and some irrelevant details) This is
> > enough information for a simplistic driver registration that probably
> > makes a lot of assumptions. Suc
Grant Likely wrote:
> So, the current 86xx device tree binding assumes a simple layout with
> a node describing an DAI controller, and another node describing the
> codec with a single phandle (pointer) from the DAI to the codec. In
> this configuration, it is completely reasonable for the DAI no
On Tue, Apr 27, 2010 at 03:04:33PM -0500, Timur Tabi wrote:
[Reflowed into 80 columns]
> At least, that's the way ASoC likes to operate. AsoC takes a fixed
> string plus a unique integer. I could technically create a unique
> string for each DMA device, and have the integer always be 0.
This s
On Tue, Apr 27, 2010 at 2:07 AM, Liam Girdwood wrote:
> On Tue, 2010-04-27 at 16:36 +1000, Benjamin Herrenschmidt wrote:
>> On Mon, 2010-04-26 at 15:49 -0500, Timur Tabi wrote:
>> > An upcoming change in the architecture of ALSA SoC (ASoC) will require the
>> > MPC8610 HPCD's ASoC fabric driver to
Grant Likely wrote:
> Can you not dynamically assign an id? If alsa soc needs a unique id
> number, then just create a lookup function.
What I need is something like a hashing function that can convert a "struct
device_node *" into an "int". I'm going to have two functions that
independently
On Tue, Apr 27, 2010 at 12:32 PM, Timur Tabi wrote:
> Liam Girdwood wrote:
>
>>> I would need some way for fsl_dma_open() to get a pointer to private,
>>> DMA-specific data. I'm not sure how I can do that.
>>
>> In multi-component we now have platform_data and device private data
>> (from the reg
Liam Girdwood wrote:
>> I would need some way for fsl_dma_open() to get a pointer to private,
>> DMA-specific data. I'm not sure how I can do that.
>
> In multi-component we now have platform_data and device private data
> (from the regular driver model).
In that case, I still have the same pro
On Tue, 2010-04-27 at 10:28 -0500, Timur Tabi wrote:
> Liam Girdwood wrote:
>
> > Iirc, the SSI and DMA controllers on your SoC mean that each DMA device
> > can only do one direction (either Playback or Capture). So I'm thinking
> > we create two DAI link entries for your sound card (one for play
On Tue, Apr 27, 2010 at 10:28 AM, Timur Tabi wrote:
> I can say for certain whether that will actually work.
Ugh, I meant to write, "I can't say for certain".
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev
Liam Girdwood wrote:
> Iirc, the SSI and DMA controllers on your SoC mean that each DMA device
> can only do one direction (either Playback or Capture). So I'm thinking
> we create two DAI link entries for your sound card (one for playback and
> the other for capture) and they both use the same SS
On Tue, 2010-04-27 at 09:52 -0500, Timur Tabi wrote:
> Liam Girdwood wrote:
>
> > Now I don't know the mechanics of adding an ASoC sound card to the
> > device tree, but the device tree should be able to define an ASoC sound
> > card and also represent the relationships between the sound card and
Liam Girdwood wrote:
> I think one of the difficulties encountered here is that the device tree
> root for sound in this case is the SSI (Digital Audio Interface)
> controller and not the sound card as in ASoC. So maybe the problem is
> how do we represent an ASoC sound card in the device tree ?
On Tue, 2010-04-27 at 16:36 +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2010-04-26 at 15:49 -0500, Timur Tabi wrote:
> > An upcoming change in the architecture of ALSA SoC (ASoC) will require the
> > MPC8610 HPCD's ASoC fabric driver to register as a standard platform driver.
> > Therefore, we n
45 matches
Mail list logo
