[snd] looking for layout-ids

[snd] looking for layout-ids

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1028 bytes --]

Hey,

In order to replace snd-powermac for the newer machines where the
'sound' node has the 'layout-id' property, I'm looking for testers on
machines that have a layout-id [1] property with one of the following
values: 0x24, 0x29, 0x33, 0x50 and 0x3a.

Once I have all these, I will, along with submitting snd-aoa [2], submit
a patch to snd-powermac that makes it refuse loading in presence of a
layout-id property as a first step to migrate to snd-aoa.

At the same time, I'll probably make i2sbus refuse attaching to a device
unless there's a layout-id property so that it doesn't claim devices aoa
doesn't handle yet.

johannes

[1] to find your layout-id, execute the following:

  find /proc/device-tree/ -name layout-id | xargs hexdump -e '1/4 "0x%x\n"'

If you get no output, you have no layout-id property. If you do get
output, it will look like this:
  0x46
This is the layout-id of your sound node.

[2] Before you ask: I will not do this before snd-aoa supports headphone
detection :)


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]

Re: [snd] looking for layout-ids

[Andreas Schwab]

Johannes Berg <johannes@sipsolutions.net> writes:

> In order to replace snd-powermac for the newer machines where the
> 'sound' node has the 'layout-id' property, I'm looking for testers on
> machines that have a layout-id [1] property with one of the following
> values: 0x24

That would be mine, but it has the problem of the broken device tree, so
i2sbus doesn't work yet.

> [2] Before you ask: I will not do this before snd-aoa supports headphone
> detection :)

Another important feature would be DRC, IMHO.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [snd] looking for layout-ids

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1005 bytes --]


> > In order to replace snd-powermac for the newer machines where the
> > 'sound' node has the 'layout-id' property, I'm looking for testers on
> > machines that have a layout-id [1] property with one of the following
> > values: 0x24
> 
> That would be mine, but it has the problem of the broken device tree, so
> i2sbus doesn't work yet.

Ah, right. I'll have to check with Ben a bit more when he comes back. He
seemed to have half of a plan ;)

> > [2] Before you ask: I will not do this before snd-aoa supports headphone
> > detection :)
> 
> Another important feature would be DRC, IMHO.

Yeah, I guess, but that's only doable with the tas codec. I don't think
it's hard, if anyone wnats to try: the tas datasheet is in my
repository, and all you need to do is modify the tas codec to show the
controls for that. Could also use some bass/treble controls.

If we want DRC even for the other machines, that's an alsa userspace
thing since it needs a soft-DSP then.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]

Re: [snd] looking for layout-ids

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 908 bytes --]

Hey,

>  How about 0x3c and 0x3d (PowerMac9,1) ?  I can't see anything in
> snd-aoa-fabric-layout that matches 60 or 61.  I last tried to play
> with this a few weeks ago, but gave up with what I assumed were
> config problems (undefined symbols) and had too many other things to
> get on with.

undefined symbols are usually because alsa isn't configured, or snd-pcm
isn't loaded.

>  Certainly, this is one of the machines where loading snd-powermac
> is catastrophic.

Catastrophic? How so? Anyway, I don't care much :)

Anyway, if you want to give it a spin, try the latest snd-aoa (see
http://johannes.sipsolutions.net/Projects/snd-aoa/ for a description).
It should report an unknown layout, which are those two ones you
described above. I think you probably have a tas and topaz combination,
so if you get i2sbus to load, I might be able to give you a patch to
test.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]

Re: [snd] looking for layout-ids

[Paul Collins]

Johannes Berg <johannes@sipsolutions.net> writes:

> Hey,
>
> In order to replace snd-powermac for the newer machines where the
> 'sound' node has the 'layout-id' property, I'm looking for testers on
> machines that have a layout-id [1] property with one of the following
> values: 0x24, 0x29, 0x33, 0x50 and 0x3a.

0x33 here.

-- 
Dag vijandelijk luchtschip de huismeester is dood

Re: [snd] looking for layout-ids

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 995 bytes --]

On Thu, 2006-05-25 at 23:11 +0100, Ken Moffat wrote:

>  it seemed to build fine with this morning's git.  There were some
> messages during the build which might be important (I'm using
> gcc-4.1.0) but I guess they are probably standard alsa things :
> 
>   CC [M]  /home/ken/snd-aoa/soundbus/core.o
> In file included from /home/ken/snd-aoa/soundbus/soundbus.h:12,
>                  from /home/ken/snd-aoa/soundbus/core.c:12:
> include/sound/pcm.h:59: warning: ‘struct snd_pcm_substream’ declared
> inside parameter list
> include/sound/pcm.h:59: warning: its scope is only this definition
> or declaration, which is probably not what you want
> include/sound/pcm.h:60: warning: ‘struct snd_pcm_substream’ declared
> inside parameter list

Nah, those should not happen. What kernel are you building against?

> i2sbus: !!!!! WARNING !!!!!
> i2sbus: control: couldn't allocate resource
> i2sbus: going ahead anyway

That's fine. Everyone gets it :)

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]

Re: [snd] looking for layout-ids

[Johannes Berg]

On Thu, 2006-05-25 at 23:49 +0100, Ken Moffat wrote:
> > >   CC [M]  /home/ken/snd-aoa/soundbus/core.o
> > > In file included from /home/ken/snd-aoa/soundbus/soundbus.h:12,
> > >                  from /home/ken/snd-aoa/soundbus/core.c:12:
> > > include/sound/pcm.h:59: warning: =E2=80=98struct snd_pcm_substream=E2=
=80=99 declared
> > > inside parameter list
> > > include/sound/pcm.h:59: warning: its scope is only this definition
> > > or declaration, which is probably not what you want
> > > include/sound/pcm.h:60: warning: =E2=80=98struct snd_pcm_substream=E2=
=80=99 declared
> > > inside parameter list
> >=20
> > Nah, those should not happen. What kernel are you building against?
> >=20
>  2.6.17-rc5.  I had similar messages when I first tried snd-aoa,
> which would have been around 2.6.16.5.

Hm, ok, I'm currently testing against 2.6.17-rc4 so that ought to be
fine unless they had a large alsa code drop which can't really be
between -rc4 and -rc5 :)

>  Must be the headers causing the problem then.  I wonder if it's
> somehow using userspace headers - I might have had some 'unvalidated'
> headers in /usr/include/sound [1].  Will take a look tomorrow,
> although I've installed alsa lib after building snd-aoa, so that
> probably updated the headers.

Very strange, I don't think it should be trying to include *anything*
from /usr/include for userspace. And the line numbers match the kernel
line numbers.

But looking at the header file again, I don't quite understand why it
should even work at all.

It (pcm.h) first uses struct snd_pcm_substream:
struct snd_pcm_ops {
        int (*open)(struct snd_pcm_substream *substream);
        int (*close)(struct snd_pcm_substream *substream);
(these are the lines that give the warnings above)

and then defines it much much later in line 344... Odd. I suppose gcc
4.1.0 is more struct. Try adding to pcm.h, around line 57, just the
definition like so:

struct snd_pcm_substream;

In any case, I don't think that's the actual problem. I think the point
is that your machine isn't supported yet, can you try the patch below?

But please let me know if _noheadphones is correct, it probably isn't
and you need to tell me what connectors you have on the outside of the
box.

johannes

--- snd-aoa.orig/aoa/fabrics/snd-aoa-fabric-layout.c	2006-05-26 01:01:17.18=
9771119 +0200
+++ snd-aoa/aoa/fabrics/snd-aoa-fabric-layout.c	2006-05-26 01:01:42.8197711=
19 +0200
@@ -80,6 +80,8 @@ struct layout {
=20
 MODULE_ALIAS("sound-layout-82");
 MODULE_ALIAS("sound-layout-45");
+MODULE_ALIAS("sound-layout-60");
+MODULE_ALIAS("sound-layout-61");
 MODULE_ALIAS("sound-layout-64");
 MODULE_ALIAS("sound-layout-65");
 MODULE_ALIAS("sound-layout-68");
@@ -161,6 +163,21 @@ static struct layout layouts[] =3D {
 		.connections =3D NULL /* TBD */,
 	  },
 	},
+	/* PowerMac9,1 */
+	{ .layout_id =3D 60,
+	  .flags =3D LAYOUT_FLAG_COMBO_LINEOUT_SPDIF,
+	  .codecs[0] =3D {
+		.name =3D "onyx",
+		.connections =3D onyx_connections_noheadphones,
+	  },
+	},
+	/* PowerMac9,1 */
+	{ .layout_id =3D 61,
+	  .codecs[0] =3D {
+		.name =3D "topaz",
+		.connections =3D NULL, /* TBD */
+	  },
+	},
 	/* PowerBook5,7 */
 	{ .layout_id =3D 64,
 	  .flags =3D LAYOUT_FLAG_COMBO_LINEOUT_SPDIF,

Re: [snd] looking for layout-ids

[Benjamin Herrenschmidt]

On Thu, 2006-05-25 at 12:43 +0200, Johannes Berg wrote:
> Hey,
> 
> In order to replace snd-powermac for the newer machines where the
> 'sound' node has the 'layout-id' property, I'm looking for testers on
> machines that have a layout-id [1] property with one of the following
> values: 0x24, 0x29, 0x33, 0x50 and 0x3a.

Some tips:

 0x24 is old G5's (PowerMac7,2 and 7,3) primary i2s bus
 0x29 is not in my list so I don't know what machine it is 
 0x33 is aluminium powerbook 15" rev. 2 (PowerMac5,4)
 0x3a is mac mini (I can test that one one of these days but we'll need
the
	        toonie codec, which is basically a "null" codec with only
	        the amps GPIOs available)
 0x50 is not in my list

Also not in your list nor in the driver:

 0x3c is recent single CPU desktop G5 (PowerMac9,1) (SMU based) bus
i2s-a
 0x3d is same as above bus i2s-c

The later is a onyx + topaz setup iirc, possibly similar to the quad.

> Once I have all these, I will, along with submitting snd-aoa [2], submit
> a patch to snd-powermac that makes it refuse loading in presence of a
> layout-id property as a first step to migrate to snd-aoa.
> 
> At the same time, I'll probably make i2sbus refuse attaching to a device
> unless there's a layout-id property so that it doesn't claim devices aoa
> doesn't handle yet.
> 
> johannes
> 
> [1] to find your layout-id, execute the following:
> 
>   find /proc/device-tree/ -name layout-id | xargs hexdump -e '1/4 "0x%x\n"'
> 
> If you get no output, you have no layout-id property. If you do get
> output, it will look like this:
>   0x46
> This is the layout-id of your sound node.
> 
> [2] Before you ask: I will not do this before snd-aoa supports headphone
> detection :)
> 
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [snd] looking for layout-ids

[Benjamin Herrenschmidt]

> Once I have all these, I will, along with submitting snd-aoa [2], submit
> a patch to snd-powermac that makes it refuse loading in presence of a
> layout-id property as a first step to migrate to snd-aoa.
> 
> At the same time, I'll probably make i2sbus refuse attaching to a device
> unless there's a layout-id property so that it doesn't claim devices aoa
> doesn't handle yet.

I think we need to be careful about a couple other things:

 - We need non-pmf GPIO. Some layout-id based machines do need that,
like the mac mini
 - I'm tempted to rename soundbus/i2sbus to snd-aoa-soundbus and
snd-aoa-i2sbus (at least the module names) for now. 

Ben.

Re: [snd] looking for layout-ids

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 584 bytes --]

On Fri, 2006-05-26 at 11:17 +1000, Benjamin Herrenschmidt wrote:

> I think we need to be careful about a couple other things:
> 
>  - We need non-pmf GPIO. Some layout-id based machines do need that,
> like the mac mini

Yeah, I saw that, but I need more insight into how that should work with
a feature call or so...

>  - I'm tempted to rename soundbus/i2sbus to snd-aoa-soundbus and
> snd-aoa-i2sbus (at least the module names) for now. 

Yeah, I guess that ought to be done. Not just the module names, also the
sysfs visible part (though that's easy).

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]

Re: [snd] looking for layout-ids

[Benjamin Herrenschmidt]

On Fri, 2006-05-26 at 09:28 +0200, Johannes Berg wrote:
> On Fri, 2006-05-26 at 11:17 +1000, Benjamin Herrenschmidt wrote:
> 
> > I think we need to be careful about a couple other things:
> > 
> >  - We need non-pmf GPIO. Some layout-id based machines do need that,
> > like the mac mini
> 
> Yeah, I saw that, but I need more insight into how that should work with
> a feature call or so...

Well, look at the tumbler code. The address you pass to the feature call
is the GPIO offset from the beginning of mac-io. Since Apple stuff isn't
always consistent, you have 2 ways of getting to it:

 - Use the "reg" property as normally expected... except that Apple has
bugs there where that property contains an offset that is either
relative to the beginning of the GPIO block (which itself is at 0x50 in
mac-io) or to the beginning of mac-io. It _seems_ however that they are
consistent with the bug in the sense that most GPIOs are relative to the
GPIO block except the audio ones that are relative to the beginning of
mac-io. The "trick" you can use is that since the GPIO block is less
than 0x50 bytes long, you can take the value of "reg" and do something
like:

	offset = (reg >= 0x50) ? reg : (reg + 0x50);

It's ugly but will work I think will all incarnations of mac-io

 - Specifically for audio-GPIOs it seems that they also have an
AAPL,address property that contains the physical address of the GPIO
within mac-io. For example, headphone-detect on the mac-mini contains:

	AAPL,address     80000067

In that case, what you can do is take that property and strip off the
top bits

	offset = aapl_addr & 0xff;

In both case, the resulting offset can then be passed to the feature
calls to access the GPIOs. Now there is the problem of the format of the
8 bits value you read/write. It's not exactly the same between keylargo
and k2/shasta (wether you have a G5 or not). However, since the later
always use platform functions afaik, it's a non-issue and thus you only
have to handle the old-style ones.

#define KEYLARGO_GPIO_OUTPUT_ENABLE     0x04
#define KEYLARGO_GPIO_OUTOUT_DATA       0x01
#define KEYLARGO_GPIO_INPUT_DATA        0x02

So to configure a GPIO as an input, make sure 0x04 is cleared. You can
read the input value then on bit 0x02. For some GPIOs, you want to leave
them as open collector (that is asserted to 0 or floating). In that
case, asserted to 0 is 0x04 (output enabled set to 1 and output data set
to 0) and floating (high-Z) is 0x00 (configurd as input). If you want to
always assert the GPIO, then use 0x04 and 0x05 as 0 and 1 values. (Look
what darwin does there).

You may want to have a look at the gpio code from Ben Collins too,
though it could be simplified now that we only deal with old-style ones.
On those old-style ones, there is a property "audio-gpio-active-state"
that gives you the polarity of the output.

In addition, look for "has-anded-reset" property (in the "sound" node).
Some platforms have that to tell you that setting both mutes at the same
time resets the codec. Thus you may have to be especially careful. Have
also a look at AppleMacRISC2PE since I think it adds or removes that
property on some machines.

> >  - I'm tempted to rename soundbus/i2sbus to snd-aoa-soundbus and
> > snd-aoa-i2sbus (at least the module names) for now. 
> 
> Yeah, I guess that ought to be done. Not just the module names, also the
> sysfs visible part (though that's easy).

Yup.

Ben.

Re: [snd] looking for layout-ids

[Eddy Petrişor]

T24gNS8yNS8wNiwgSm9oYW5uZXMgQmVyZyA8am9oYW5uZXNAc2lwc29sdXRpb25zLm5ldD4gd3Jv
dGU6Cj4gSGV5LAoKSGksCgo+IFsxXSB0byBmaW5kIHlvdXIgbGF5b3V0LWlkLCBleGVjdXRlIHRo
ZSBmb2xsb3dpbmc6Cj4KPiAgIGZpbmQgL3Byb2MvZGV2aWNlLXRyZWUvIC1uYW1lIGxheW91dC1p
ZCB8IHhhcmdzIGhleGR1bXAgLWUgJzEvNCAiMHgleFxuIicKPgo+IElmIHlvdSBnZXQgbm8gb3V0
cHV0LCB5b3UgaGF2ZSBubyBsYXlvdXQtaWQgcHJvcGVydHkuIElmIHlvdSBkbyBnZXQKCldoYXQg
YXJlIHRoZSBwbGFucyBmb3IgbWFjaGluZXMgd2l0aG91dCBsYXlvdXQtaWQsIGxpa2UgdGhlIDUs
MiBtb2RlbD8KV2lsbCB0aGVyZSBiZSBhbnkgYWxzYS9hb2Egc3VwcG9ydCBhdCBzb21lIHBvaW50
PwoKLS0gClJlZ2FyZHMsCkVkZHlQCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PQoiSW1hZ2luYXRpb24gaXMgbW9yZSBpbXBvcnRhbnQgdGhhbiBrbm93bGVkZ2Ui
IEEuRWluc3RlaW4K

Re: [snd] looking for layout-ids

[Benjamin Herrenschmidt]

On Fri, 2006-05-26 at 19:02 +0300, Eddy Petrişor wrote:
> On 5/25/06, Johannes Berg <johannes@sipsolutions.net> wrote:
> > Hey,
> 
> Hi,
> 
> > [1] to find your layout-id, execute the following:
> >
> >   find /proc/device-tree/ -name layout-id | xargs hexdump -e '1/4 "0x%x\n"'
> >
> > If you get no output, you have no layout-id property. If you do get
> 
> What are the plans for machines without layout-id, like the 5,2 model?
> Will there be any alsa/aoa support at some point?

There will be, but let's get the ones with layout-id first since
snd-powermac should work on the older ones.

Ben.

Re: [snd] looking for layout-ids

[Michael Schmitz]

> > > If you get no output, you have no layout-id property. If you do get
> >
> > What are the plans for machines without layout-id, like the 5,2 model?
> > Will there be any alsa/aoa support at some point?
>
> There will be, but let's get the ones with layout-id first since
> snd-powermac should work on the older ones.

It sure does (5,5 at least).

	Michael