* Re: snd-aoa status update / automatic driver loading
From: Paul Collins @ 2006-05-19 15:13 UTC (permalink / raw)
To: Johannes Berg; +Cc: debian-powerpc, Eddy Petrişor, linuxppc-dev list
In-Reply-To: <1148050189.6228.13.camel@johannes.berg>
Johannes Berg <johannes@sipsolutions.net> writes:
> On Sat, 2006-05-20 at 00:40 +1000, Paul Collins wrote:
>
>> Here's the dmesg after "modprobe i2sbus":
>>
>> May 20 00:35:51 briny kernel: i2sbus: mapped i2s control registers
>> May 20 00:35:51 briny kernel: i2sbus: control register contents:
>> May 20 00:35:51 briny kernel: i2sbus: fcr0 = 0x0
>> May 20 00:35:51 briny kernel: i2sbus: cell_control = 0x0
>> May 20 00:35:51 briny kernel: i2sbus: fcr2 = 0x4ef1c25
>> May 20 00:35:51 briny kernel: i2sbus: fcr3 = 0x0
>> May 20 00:35:51 briny kernel: i2sbus: clock_control = 0x0
>> May 20 00:35:51 briny kernel: layout id is 51
>
> Did you have the changed modules installed? Otherwise you'd also have to
> manually load snd_aoa_fabric_layout and possibly snd_aoa_codec_tas or
> so. If you had them installed the MODULE_ALIAS("sound-layout-51");
> should have made it load automatically.
Yep, I did make install after the build. And modinfo
/lib/modules/`uname -r`/kernel/sound/aoa/snd-aoa-fabric-layout.ko
shows ones of the aliases as "sound-layout-51".
I did a fresh boot with snd-powermac renamed out of the way, and now I
get even less action: nothing logged in dmesg, and when I unload all
five modules and probe snd-powermac (having renamed it back) I get
May 20 01:08:29 briny kernel: snd: can't request rsrc 0 (Sound Control: 0x80010000:80010fff)
Then when I removed snd-powermac and probed i2sbus I got the same
May 20 01:10:00 briny kernel: i2sbus: mapped i2s control registers
May 20 01:10:00 briny kernel: i2sbus: control register contents:
May 20 01:10:00 briny kernel: i2sbus: fcr0 = 0x0
May 20 01:10:00 briny kernel: i2sbus: cell_control = 0x0
May 20 01:10:00 briny kernel: i2sbus: fcr2 = 0xb7f53c
May 20 01:10:00 briny kernel: i2sbus: fcr3 = 0x0
May 20 01:10:00 briny kernel: i2sbus: clock_control = 0x0
May 20 01:10:00 briny kernel: layout id is 51
May 20 01:10:00 briny kernel: i2sbus control destroyed
Probing snd_aoa_fabric_layout and snd_aoa_codec_tas yielded no further
dmesg output and /proc/asounds/cards remains "no soundcards".
--
Dag vijandelijk luchtschip de huismeester is dood
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Johannes Berg @ 2006-05-19 14:49 UTC (permalink / raw)
To: Paul Collins; +Cc: debian-powerpc, Eddy Petrişor, linuxppc-dev list
In-Reply-To: <87zmhef57o.fsf@briny.internal.ondioline.org>
[-- Attachment #1: Type: text/plain, Size: 860 bytes --]
On Sat, 2006-05-20 at 00:40 +1000, Paul Collins wrote:
> Here's the dmesg after "modprobe i2sbus":
>
> May 20 00:35:51 briny kernel: i2sbus: mapped i2s control registers
> May 20 00:35:51 briny kernel: i2sbus: control register contents:
> May 20 00:35:51 briny kernel: i2sbus: fcr0 = 0x0
> May 20 00:35:51 briny kernel: i2sbus: cell_control = 0x0
> May 20 00:35:51 briny kernel: i2sbus: fcr2 = 0x4ef1c25
> May 20 00:35:51 briny kernel: i2sbus: fcr3 = 0x0
> May 20 00:35:51 briny kernel: i2sbus: clock_control = 0x0
> May 20 00:35:51 briny kernel: layout id is 51
Did you have the changed modules installed? Otherwise you'd also have to
manually load snd_aoa_fabric_layout and possibly snd_aoa_codec_tas or
so. If you had them installed the MODULE_ALIAS("sound-layout-51");
should have made it load automatically.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Paul Collins @ 2006-05-19 14:40 UTC (permalink / raw)
To: Johannes Berg; +Cc: debian-powerpc, Eddy Petrişor, linuxppc-dev list
In-Reply-To: <1148046418.3864.14.camel@johannes.berg>
Johannes Berg <johannes@sipsolutions.net> writes:
> On Fri, 2006-05-19 at 23:20 +1000, Paul Collins wrote:
>
>> I have a PowerBook5,4 here and I'd be happy to test support for it.
>> The hardware is identified by snd-powermac as "PowerMac Snapper" and
>> the layout ID appears to be "3".
>
> Try downloading snd-aoa and in snd-aoa-fabric-layout.c change the two
> occurrences of '70' to '3'. If it works, let me know and I'll add the
> proper entry for it.
When I probed i2sbus nothing much seemed to happen, so I added a
printk to see what layout ID was being returned, and I'm getting 51,
not 3 as found in the device tree. However, when I use 51 instead of
3 in those two places, I still don't get much happening.
Here's the dmesg after "modprobe i2sbus":
May 20 00:35:51 briny kernel: i2sbus: mapped i2s control registers
May 20 00:35:51 briny kernel: i2sbus: control register contents:
May 20 00:35:51 briny kernel: i2sbus: fcr0 = 0x0
May 20 00:35:51 briny kernel: i2sbus: cell_control = 0x0
May 20 00:35:51 briny kernel: i2sbus: fcr2 = 0x4ef1c25
May 20 00:35:51 briny kernel: i2sbus: fcr3 = 0x0
May 20 00:35:51 briny kernel: i2sbus: clock_control = 0x0
May 20 00:35:51 briny kernel: layout id is 51
May 20 00:35:51 briny kernel: i2sbus control destroyed
And lsmod:
Module Size Used by
i2sbus 21632 0
soundbus 8132 1 i2sbus
radeon 129896 0
drm 82968 1 radeon
snd_usb_audio 90624 0
snd_usb_lib 19232 1 snd_usb_audio
snd_rawmidi 29280 1 snd_usb_lib
snd_hwdep 11012 1 snd_usb_audio
hci_usb 14164 3
snd_pcm_oss 50816 0
snd_pcm 103588 3 i2sbus,snd_usb_audio,snd_pcm_oss
snd_timer 27140 1 snd_pcm
snd_page_alloc 11432 1 snd_pcm
pcmcia 45776 0
ehci_hcd 37224 0
bcm43xx 448916 0
ieee80211softmac 32384 1 bcm43xx
uninorth_agp 11112 1
agpgart 38484 2 drm,uninorth_agp
ohci_hcd 24452 0
ieee80211 36776 2 bcm43xx,ieee80211softmac
ieee80211_crypt 6880 1 ieee80211
yenta_socket 30412 1
rsrc_nonstatic 13472 1 yenta_socket
pcmcia_core 49592 3 pcmcia,yenta_socket,rsrc_nonstatic
Here are the changes I made.
diff --git a/aoa/fabrics/snd-aoa-fabric-layout.c b/aoa/fabrics/snd-aoa-fabric-layout.c
index 65cda87..180dca4 100644
--- a/aoa/fabrics/snd-aoa-fabric-layout.c
+++ b/aoa/fabrics/snd-aoa-fabric-layout.c
@@ -84,7 +84,7 @@ MODULE_ALIAS("sound-layout-64");
MODULE_ALIAS("sound-layout-65");
MODULE_ALIAS("sound-layout-68");
MODULE_ALIAS("sound-layout-69");
-MODULE_ALIAS("sound-layout-70");
+MODULE_ALIAS("sound-layout-51");
MODULE_ALIAS("sound-layout-72");
MODULE_ALIAS("sound-layout-86");
MODULE_ALIAS("sound-layout-84");
@@ -214,7 +214,7 @@ static struct layout layouts[] = {
},
.busname = "digital in", .pcmid = 1 },
/* Early 2005 PowerBook */
- { .layout_id = 70,
+ { .layout_id = 51,
.codecs[0] = {
.name = "tas",
.connections = tas_connections_nolineout,
diff --git a/soundbus/i2sbus/i2sbus-core.c b/soundbus/i2sbus/i2sbus-core.c
index f6463cb..ff5b52e 100644
--- a/soundbus/i2sbus/i2sbus-core.c
+++ b/soundbus/i2sbus/i2sbus-core.c
@@ -130,7 +130,10 @@ static int i2sbus_add_dev(struct macio_d
u32 *layout_id;
layout_id = (u32*) get_property(sound, "layout-id", NULL);
if (layout_id) {
+ printk(KERN_INFO "layout id is %d\n", *layout_id);
snprintf(dev->sound.modalias, 32, "sound-layout-%d", *layout_id);
+ } else {
+ printk(KERN_INFO "no layout id!?\n");
}
}
--
Dag vijandelijk luchtschip de huismeester is dood
^ permalink raw reply related
* Re: snd-aoa status update / automatic driver loading
From: Johannes Berg @ 2006-05-19 14:40 UTC (permalink / raw)
To: Wolfgang Pfeiffer; +Cc: linuxppc-dev list, debian-powerpc
In-Reply-To: <20060519144028.GA2831@localhost>
[-- Attachment #1: Type: text/plain, Size: 552 bytes --]
On Fri, 2006-05-19 at 16:40 +0200, Wolfgang Pfeiffer wrote:
> ... because it's the job of alsaconf, too, to figure that
> out. IINM. And because I thought it might help to mention the issue,
> when I was already at it .. :)
:)
I never used alsaconf, and frankly, for PCI cards and anything else
that's sensible I don't see the point since the kernel along with
hotplugging can get it just to work. With ISA, well, yea, maybe. Or does
alsaconf have any other function than detecting the hardware and loading
the right modules?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Wolfgang Pfeiffer @ 2006-05-19 14:40 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list, debian-powerpc
In-Reply-To: <1148043018.3864.6.camel@johannes.berg>
On Fri, May 19, 2006 at 02:50:18PM +0200, Johannes Berg wrote:
> On Thu, 2006-05-18 at 20:17 +0200, Wolfgang Pfeiffer wrote:
>
> > BTW: Is there a way to let 'alsaconf' detect the soundcard on this
> > PB5,8 ?
> > So far that's impossible, as it seems. But this could also be
> > related to mistakes I made in my modules files, or wherever.
>
> No idea, but I don't see why you'd want alsaconf to figure it out
... because it's the job of alsaconf, too, to figure that
out. IINM. And because I thought it might help to mention the issue,
when I was already at it .. :)
But yes, it does not bother me if the kernel itself knows what's going
on .. :)
Best Regards
Wolfgang
--
Wolfgang Pfeiffer: /ICQ: 286585973/ + + + /AIM: crashinglinux/
http://profiles.yahoo.com/wolfgangpfeiffer
Key ID: E3037113
http://keyserver.mine.nu/pks/lookup?search=0xE3037113&fingerprint=on
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Johannes Berg @ 2006-05-19 14:37 UTC (permalink / raw)
To: Andreas Schwab; +Cc: list, debian-powerpc, Eddy Petrişor
In-Reply-To: <jemzdenkyg.fsf@sykes.suse.de>
[-- Attachment #1: Type: text/plain, Size: 327 bytes --]
On Fri, 2006-05-19 at 16:33 +0200, Andreas Schwab wrote:
> > [briny(device-tree)] od -c pci@f2000000/mac-io@17/i2s@10000/i2s-a@10000/sound/layout-id
> > 0000000 \0 \0 \0 3
> > 0000004
>
> Apparently the layout-id on your system is 51 (decimal).
Eh, right, replace 70 by 51 of course. Thanks Andreas.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Andreas Schwab @ 2006-05-19 14:33 UTC (permalink / raw)
To: Paul Collins; +Cc: list, Johannes Berg, debian-powerpc, Eddy Petrişor
In-Reply-To: <87wtcirw0y.fsf@briny.internal.ondioline.org>
Paul Collins <paul@briny.ondioline.org> writes:
> Johannes Berg <johannes@sipsolutions.net> writes:
>
>> On Thu, 2006-05-18 at 10:25 +0300, Eddy Petri=BAor wrote:
>>
>>> Any chance for 5,2 ? What is needed for it? Codec only?
>>
>> I don't know. If you try loading the modules, the kernel will tell you
>> something about an unhandled layout id. Alternatively, you can find the
>> layout-id file in your /proc/device-tree/ and tell me the number in it.
>> The rest I can figure out.
>
> I have a PowerBook5,4 here and I'd be happy to test support for it.
> The hardware is identified by snd-powermac as "PowerMac Snapper" and
> the layout ID appears to be "3".
>
> [briny(device-tree)] od -c pci@f2000000/mac-io@17/i2s@10000/i2s-a@10000/s=
ound/layout-id
> 0000000 \0 \0 \0 3
> 0000004
Apparently the layout-id on your system is 51 (decimal).
Andreas.
--=20
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstra=DFe 5, 90409 N=FCrnberg, Germany
PGP key fingerprint =3D 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: PowerMac7,3 sound (was: PowerBook5,4 -- no sound?)
From: Johannes Berg @ 2006-05-19 14:32 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev
In-Reply-To: <jer72qnl38.fsf@sykes.suse.de>
[-- Attachment #1: Type: text/plain, Size: 169 bytes --]
On Fri, 2006-05-19 at 16:30 +0200, Andreas Schwab wrote:
> Yes, sound is fully supported by snd-powermac on my system.
Alright, I'll look at it then.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: PowerMac7,3 sound (was: PowerBook5,4 -- no sound?)
From: Andreas Schwab @ 2006-05-19 14:30 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev
In-Reply-To: <1148046512.3864.17.camel@johannes.berg>
Johannes Berg <johannes@sipsolutions.net> writes:
> On Fri, 2006-05-19 at 15:30 +0200, Andreas Schwab wrote:
>
>> >> Yes, that's while I had that loaded. Of course, I unloaded it before I
>> >> tried snd-aoa.
>> >
>> > Ok, but is that the correct stuff, i.e. does it work?
>>
>> Sorry, I can't quite figure out what "it" refers to in your question.
>
> Sorry. I was trying to ask if you get sound with snd-powermac, i.e. if
> the items
>
>>> 80008000-800083ff : 0.00010000:i2s
>>> 80008000-800083ff : Sound DMA
>>> 80010000-80010fff : 0.00010000:i2s
>>> 80010000-80010fff : Sound Control
>
> are correct.
Yes, sound is fully supported by snd-powermac on my system.
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."
^ permalink raw reply
* Re: [PATCH 5/6] Have ia64 use add_active_range() and free_area_init_nodes
From: Andy Whitcroft @ 2006-05-19 14:23 UTC (permalink / raw)
To: Mel Gorman
Cc: Andrew Morton, davej, tony.luck, linuxppc-dev, linux-kernel,
bob.picco, ak, linux-mm
In-Reply-To: <Pine.LNX.4.64.0605191447060.29077@skynet.skynet.ie>
Mel Gorman wrote:
> On Sun, 14 May 2006, Andrew Morton wrote:
>
>> Mel Gorman <mel@csn.ul.ie> wrote:
>>
>>>
>>> Size zones and holes in an architecture independent manner for ia64.
>>>
>>
>> This one makes my ia64 die very early in boot. The trace is pretty
>> useless.
>>
>> config at http://www.zip.com.au/~akpm/linux/patches/stuff/config-ia64
>>
>
> An indirect fix for this has been set out with a patchset with the
> subject "[PATCH 0/2] Fixes for node alignment and flatmem assumptions" .
> For arch-independent-zone-sizing, the issue was that FLATMEM assumes
> that NODE_DATA(0)->node_start_pfn == 0. This is not the case with
> arch-independent-zone-sizing and IA64. With
> arch-independent-zone-sizing, a nodes node_start_pfn will be at the
> first valid PFN.
>
>> <log snipped>
>>
>> Note the misaligned pfns.
>>
>
> You will still get the message about misaligned PFNs on IA64. This is
> because the lowest zone starts at the lowest available PFN which may not
> be 0 or any other aligned number. It shouldn't make a different - or at
> least I couldn't cause any problems.
With the updates I sent out to the zone alignment checks yesterday this
should now be ignored correctly without comment. The first zone is
allowed to be misaligned because we expect alignment of the mem_map.
With bob picco's patch from your set we ensure it is so.
-apw
^ permalink raw reply
* Re: [PATCH 5/6] Have ia64 use add_active_range() and free_area_init_nodes
From: Mel Gorman @ 2006-05-19 14:03 UTC (permalink / raw)
To: Andrew Morton
Cc: davej, tony.luck, linuxppc-dev, ak, bob.picco, linux-kernel,
linux-mm
In-Reply-To: <20060514203158.216a966e.akpm@osdl.org>
On Sun, 14 May 2006, Andrew Morton wrote:
> Mel Gorman <mel@csn.ul.ie> wrote:
>>
>> Size zones and holes in an architecture independent manner for ia64.
>>
>
> This one makes my ia64 die very early in boot. The trace is pretty useless.
>
> config at http://www.zip.com.au/~akpm/linux/patches/stuff/config-ia64
>
An indirect fix for this has been set out with a patchset with the subject
"[PATCH 0/2] Fixes for node alignment and flatmem assumptions" . For
arch-independent-zone-sizing, the issue was that FLATMEM assumes that
NODE_DATA(0)->node_start_pfn == 0. This is not the case with
arch-independent-zone-sizing and IA64. With arch-independent-zone-sizing,
a nodes node_start_pfn will be at the first valid PFN.
> <log snipped>
>
> Note the misaligned pfns.
>
You will still get the message about misaligned PFNs on IA64. This is
because the lowest zone starts at the lowest available PFN which may not
be 0 or any other aligned number. It shouldn't make a different - or at
least I couldn't cause any problems.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* libspe update
From: D. Herrendoerfer @ 2006-05-19 13:56 UTC (permalink / raw)
To: linuxppc64-dev
[-- Attachment #1: Type: text/plain, Size: 307 bytes --]
***********************
Warning: Your file, libspe-1.1.0-20060519.tar.gz, contains more than 32 files after decompression and cannot be scanned.
***********************
This is the current version of libspe matching the current spufs
implementation
posted by Arnd Bergmann this week.
D. Herrendoerfer
[-- Attachment #2: libspe-1.1.0-20060519.tar.gz --]
[-- Type: application/x-gzip, Size: 53352 bytes --]
^ permalink raw reply
* Re: PowerMac7,3 sound (was: PowerBook5,4 -- no sound?)
From: Johannes Berg @ 2006-05-19 13:48 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev
In-Reply-To: <jey7wynnux.fsf@sykes.suse.de>
[-- Attachment #1: Type: text/plain, Size: 668 bytes --]
On Fri, 2006-05-19 at 15:30 +0200, Andreas Schwab wrote:
> >> Yes, that's while I had that loaded. Of course, I unloaded it before I
> >> tried snd-aoa.
> >
> > Ok, but is that the correct stuff, i.e. does it work?
>
> Sorry, I can't quite figure out what "it" refers to in your question.
Sorry. I was trying to ask if you get sound with snd-powermac, i.e. if
the items
>> 80008000-800083ff : 0.00010000:i2s
>> 80008000-800083ff : Sound DMA
>> 80010000-80010fff : 0.00010000:i2s
>> 80010000-80010fff : Sound Control
are correct. I'll have to investigate a bit more what happens on your
machine.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Johannes Berg @ 2006-05-19 13:46 UTC (permalink / raw)
To: Paul Collins; +Cc: linuxppc-dev list, debian-powerpc, Eddy Petrişor
In-Reply-To: <87wtcirw0y.fsf@briny.internal.ondioline.org>
[-- Attachment #1: Type: text/plain, Size: 415 bytes --]
On Fri, 2006-05-19 at 23:20 +1000, Paul Collins wrote:
> I have a PowerBook5,4 here and I'd be happy to test support for it.
> The hardware is identified by snd-powermac as "PowerMac Snapper" and
> the layout ID appears to be "3".
Try downloading snd-aoa and in snd-aoa-fabric-layout.c change the two
occurrences of '70' to '3'. If it works, let me know and I'll add the
proper entry for it.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: PowerMac7,3 sound (was: PowerBook5,4 -- no sound?)
From: Andreas Schwab @ 2006-05-19 13:30 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev
In-Reply-To: <1148042866.3864.3.camel@johannes.berg>
Johannes Berg <johannes@sipsolutions.net> writes:
> On Thu, 2006-05-18 at 14:48 +0200, Andreas Schwab wrote:
>
>> Yes, that's while I had that loaded. Of course, I unloaded it before I
>> tried snd-aoa.
>
> Ok, but is that the correct stuff, i.e. does it work?
Sorry, I can't quite figure out what "it" refers to in your question.
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."
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Paul Collins @ 2006-05-19 13:20 UTC (permalink / raw)
To: Johannes Berg; +Cc: list, Eddy Petrişor, debian-powerpc
In-Reply-To: <1147947784.15507.46.camel@johannes>
Johannes Berg <johannes@sipsolutions.net> writes:
> On Thu, 2006-05-18 at 10:25 +0300, Eddy Petri=C5=9For wrote:
>
>> Any chance for 5,2 ? What is needed for it? Codec only?
>
> I don't know. If you try loading the modules, the kernel will tell you
> something about an unhandled layout id. Alternatively, you can find the
> layout-id file in your /proc/device-tree/ and tell me the number in it.
> The rest I can figure out.
I have a PowerBook5,4 here and I'd be happy to test support for it.
The hardware is identified by snd-powermac as "PowerMac Snapper" and
the layout ID appears to be "3".
[briny(device-tree)] od -c pci@f2000000/mac-io@17/i2s@10000/i2s-a@10000/sou=
nd/layout-id
0000000 \0 \0 \0 3
0000004
--=20
Dag vijandelijk luchtschip de huismeester is dood
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Johannes Berg @ 2006-05-19 12:50 UTC (permalink / raw)
To: Wolfgang Pfeiffer; +Cc: linuxppc-dev list, debian-powerpc
In-Reply-To: <20060518181748.GA2836@localhost>
[-- Attachment #1: Type: text/plain, Size: 386 bytes --]
On Thu, 2006-05-18 at 20:17 +0200, Wolfgang Pfeiffer wrote:
> BTW: Is there a way to let 'alsaconf' detect the soundcard on this
> PB5,8 ?
> So far that's impossible, as it seems. But this could also be
> related to mistakes I made in my modules files, or wherever.
No idea, but I don't see why you'd want alsaconf to figure it out if the
kernel can by itself...
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: PowerMac7,3 sound (was: PowerBook5,4 -- no sound?)
From: Johannes Berg @ 2006-05-19 12:47 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev
In-Reply-To: <jek68jqz1l.fsf@sykes.suse.de>
[-- Attachment #1: Type: text/plain, Size: 222 bytes --]
On Thu, 2006-05-18 at 14:48 +0200, Andreas Schwab wrote:
> Yes, that's while I had that loaded. Of course, I unloaded it before I
> tried snd-aoa.
Ok, but is that the correct stuff, i.e. does it work?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Johannes Berg @ 2006-05-19 10:22 UTC (permalink / raw)
To: Tony Vroon; +Cc: linuxppc-dev list, Benjamin Berg, debian-powerpc
In-Reply-To: <446B721D.8020203@gentoo.org>
[-- Attachment #1: Type: text/plain, Size: 4514 bytes --]
On Wed, 2006-05-17 at 19:57 +0100, Tony Vroon wrote:
> When writing documentation, you might want to add that the ALSA-plugin
> in XMMS & Audacious requires a period time of 100ms instead of the
> default of 50ms, as otherwise the sou*click*nd is n*click*ot ver*click*y
> good.
> (A look at the current code of that plugin, to see how the volume
> control code can be fixed would be highly appreciated)
How's that related to snd-aoa? You can currently buffer up to 131072
bytes which at 96KHz and 32 bits is ~171ms. At the regular 44100Hz/16bit
it is ~743ms. But you can easily increase that in i2sbus-pcm.c line
126ff:
/* these are somewhat arbitrary */
hw->buffer_bytes_max = 131072;
hw->period_bytes_min = 256;
hw->period_bytes_max = 16384;
The thing is just that this memory area is essentially mlock()ed so if I
did indeed allow 16k per period and 32 periods the stream would mlock
512K. What would others say is appropriate?
Ah then again I can see how this might be related to snd-aoa -- we only
update the pcm position on each period so maybe we should increase the
minimum number of periods. Can you try that? Go into i2sbus-pcm.c line
130 and change
hw->periods_min = 3;
to maybe 6. Or just try binary search for smallest value that makes it
work (if it ever does, but I think it should, if this is indeed the
issue). Indeed, at 50ms buffer you have just 8820 bytes which can even
be divided by 3 so that probably means that xmms used 3 periods. Maybe
that's a bit tight. Do you see the same issue with snd-powermac? (it
uses the same period setup)
> Not seen this, although I must say it does not resume from sleep as
> gracefully as I have seen you describe it.
What happens? I just fixed tas resume from sleep (by completely
re-initialising the codec) and something similar should be done for the
onyx probably (or do I do that already?) for suspend to disk, but other
than that... Oh I just realised that it'll lose some sound due to
restarting the dma command ring at the beginning. Hmm. I suppose I can
change that easily, will have to do some testing.
Benjamin (Berg), can we do that even with the lost interrupt issue?
Maybe both of these issues can be fixed by using the frame count
register instead to count how many samples were played? Below is a small
patch to print out a lot of frame count numbers, Benjamin, I'd
appreciate if you could look how this interacted with the lost
interrupts.
Note that for this to work we'd of course have to sample the frame count
register right before starting the DMA engine, it increases even while
we're not playing because we don't stop the clocks. We probably should
do that too for powersaving. Humm. Lots to do :) Oh and this probably
means that yes, it works fine even when we do lose interrupts.
Alternatively we could use the register just to detect if we lost
interrupts, i.e. calculate how many frames we have per period and then
see if the frame count increased approximately by that much (I've seen
+- a few frames probably due to timing, with higher samplerates we'll
probably see a bit more error) and if it increased by much more we could
estimate how many interrupts we lost. What do you think?
johannes
--- snd-aoa.orig/soundbus/i2sbus/i2sbus-pcm.c 2006-05-19 12:10:16.919474526 +0200
+++ snd-aoa/soundbus/i2sbus/i2sbus-pcm.c 2006-05-19 12:11:22.119474526 +0200
@@ -488,12 +488,17 @@ static snd_pcm_uframes_t i2sbus_pcm_poin
static inline void handle_interrupt(struct i2sbus_dev *i2sdev, int in)
{
struct pcm_info *pi;
+ u32 fc;
get_pcm_info(i2sdev, in, &pi, NULL);
if (!pi->substream) {
printk(KERN_INFO "i2sbus: got %s irq while not active!\n", in?"rx":"tx");
return;
}
+ fc = in_le32(&i2sdev->intfregs->frame_count);
+ printk(KERN_DEBUG "i2sbus: frame count is %d\n", fc);
+ printk(KERN_DEBUG "i2sbus: delta fc = %d\n", fc - i2sdev->fc);
+ i2sdev->fc = fc;
pi->current_period = (pi->current_period+1) % (pi->periods);
snd_pcm_period_elapsed(pi->substream);
}
--- snd-aoa.orig/soundbus/i2sbus/i2sbus.h 2006-05-19 12:10:16.919474526 +0200
+++ snd-aoa/soundbus/i2sbus/i2sbus.h 2006-05-19 12:11:22.119474526 +0200
@@ -50,6 +50,7 @@ struct i2sbus_dev {
struct macio_dev *macio;
struct i2sbus_control *control;
volatile struct i2s_interface_regs __iomem *intfregs;
+ u32 fc;
int resource_allocated; /* bitmask of resources */
struct resource resources[3];
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* i2sbus transfer foo
From: Johannes Berg @ 2006-05-19 11:36 UTC (permalink / raw)
To: linuxppc-dev list
[-- Attachment #1: Type: text/plain, Size: 4292 bytes --]
Sorry for the vague subject :) I don't really know what to say...
Let me introduce some things first. First of all, the i2sbus controllers
Apple has in their mac-io chip are capable of doing (among others we
don't care about) 16-bit transfers in 32x and 64x i2s modes, and 24-bit
transfers in 64x i2s mode. For the latter, the chip requires that the
inputs are actually 32-bit aligned, which means that it's a bit weird
that it doesn't actually transfer all the 32 bits. But that's another
issue, maybe there's a way to make it transfer 32 bits that I don't
know. Or maybe it even does and we just don't have a codec capable of
using or creating data in those remaining 8 bits.
Anyway, let's dive right in, here's a sample capture where I was
capturing an 880Hz sine wave generated with gstreamer on another machine
via a direct cable:
00007910 f8 36 48 00 f7 a1 cc 00 f7 a1 cc 00 f7 2e ea 00 |.6H.............|
00007920 f7 2e ea 00 f6 df 58 00 f6 df 58 00 f6 b4 ee 00 |......X...X.....|
00007930 f6 b4 ee 00 f6 af 78 00 f6 af 78 00 f6 cf 59 00 |......x...x...Y.|
The hexdump above is directly from the DMA memory area, not gone through
alsa, I made a debugfs file that gives me access to the buffer area
straight away.
Let me start arecord again:
$ arecord -r 44100 -f S32_LE -c2 > /tmp/test.wav
Dumping the dma area again yields:
00008680 e4 00 ff bd e4 00 fe 93 22 00 fe 93 22 00 fd 6f |........"..."..o|
00008690 2b 00 fd 6f 2b 00 fc 55 62 00 fc 55 62 00 fb 49 |+..o+..Ub..Ub..I|
000086a0 76 00 fb 49 76 00 fa 52 49 00 fa 52 49 00 f9 71 |v..Iv..RI..RI..q|
000086b0 1f 00 f9 71 1f 00 f8 aa 2c 00 f8 aa 2c 00 f7 ff |...q....,...,...|
and a 3rd time:
0000ff60 00 07 3a 12 00 06 6f 77 00 06 6f 77 00 05 89 d9 |..:...ow..ow....|
0000ff70 00 05 89 d9 00 04 8e 73 00 04 8e 73 00 03 80 4a |.......s...s...J|
0000ff80 00 03 80 4a 00 02 64 b0 00 02 64 b0 00 01 3e c0 |...J..d...d...>.|
0000ff90 00 01 3e c0 00 00 16 65 00 00 16 65 00 fe ea b6 |..>....e...e....|
4th time it's like 3rd, 5th like first, but 6th time:
0000bc60 e8 39 00 00 13 60 00 00 13 60 00 01 3d 96 00 01 |.9...`...`..=...|
0000bc70 3d 96 00 02 63 55 00 02 63 55 00 03 7f f5 00 03 |=...cU..cU......|
0000bc80 7f f5 00 04 8b 73 00 04 8b 73 00 05 87 84 00 05 |.....s...s......|
0000bc90 87 84 00 06 6d cc 00 06 6d cc 00 07 37 ae 00 07 |....m...m...7...|
See the problem?
When I actually manage to have it aligned like in #3 above,
SNDRV_PCM_FORMAT_S24_BE would be correct. And in that case, I once even
got a nice wav file that audacity can downsample to 16 bit and play
properly. But in all other cases I get mangled sound for obvious
reasons.
The correct data layout seems to be the first though, because when I
transfer that *to* the chip for playback (by making i2sbus announce
32bit big-endian format to alsa) I get proper sound with the correct
volume, hence I just changed i2sbus to always announce 16 and 32-bit BE
formats which also no longer mangles sound with gstreamer (except for
clicking every once a while on some streams[1]).
Oh, and note that those 4 cases aren't all possible cases. If you think
about it you'll notice that there are 8 cases because we have two
channels. I think I even mixed them in the dumps above, not sure.
Some looking at snd-powermac code later I now changed the i2sbus code to
do a dbdma-programmed engine stop in hope that would synchronize (as a
comment in snd-powermac implies) but that doesn't seem to be correct
either. I now more often get the first case though not all the time.
I'm out of ideas. I don't have a clue how to get this thing synchronized
properly. If anyone has a solution let me know, otherwise I'll probably
just disable 24-bit recording for good, then at least the chances of
getting sound that makes sense (even if left and right might be
switched) are 1/2 as opposed to 1/4 assuming even distribution... Also,
the question is why this does not happen on playback, or at least so
much less frequently that I haven't seen it yet...
johannes
[1] only happens with gstreamer on some streams, and then only if I use
alsasink without giving it the latency-time option, even if I give it
the default it doesn't click. very strange.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: [Cbe-oss-dev] Cell and new CPU feature bits
From: Arnd Bergmann @ 2006-05-19 10:11 UTC (permalink / raw)
To: cbe-oss-dev; +Cc: linuxppc-dev list
In-Reply-To: <1148011621.13249.7.camel@localhost.localdomain>
On Friday 19 May 2006 06:07, Benjamin Herrenschmidt wrote:
> - Extended implementation of dcbt. (Another bit ? Or sould we just have
> a "CELL" bit ? In which case should it cover the altivec additions too
> or are those likely to exist in future non-Cell processors ?)
Isn't that already covered by PPC_FEATURE_CELL? Git log shows
| commit a7ddc5e85351931b67a48afa22788d77763837d8
| Author: Paul Mackerras <paulus@samba.org>
| Date: Thu Nov 10 14:29:18 2005 +1100
|
| powerpc: Add user CPU features for POWER4, POWER5, POWER5+ and Cell.
|
| This is at the request of the glibc folks, who want to use these bits
| to select libraries optimized for the microarchitecture and new
| instructions in these processors.
|
| Signed-off-by: Paul Mackerras <paulus@samba.org>
Arnd <><
^ permalink raw reply
* Re: Cell and new CPU feature bits
From: Gabriel Paubert @ 2006-05-19 8:16 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev list, Paul Mackerras, cbe-oss-dev, Arnd Bergmann
In-Reply-To: <1148011621.13249.7.camel@localhost.localdomain>
On Fri, May 19, 2006 at 02:07:01PM +1000, Benjamin Herrenschmidt wrote:
> The Cell has a couple of "features" that should be exposed to userland
> in a way or another. That raises some questions however about how those
> should be done. Among others that come to mind:
>
> - The timebase errata (should we use a separate aux vector for "bugs"
> than for "features" ?
Is this bug really going to be exposed in the wild or is it
an early silicon bug that will only bite early-testers?
> - Additional Altivec instructions (load/store right/left). A new
> feature bit for these ?
Yes. So IBM was not happy with Altivec instructions to generate
vsel control words and got their inspiration from MIPS?
> - Lack of data stream instructions. Until now, it was assumed that
> those were tied to the presence
> of an Altivec (and they are documented in the Altivec manual). Maybe
> we should split that to a
> new bit. I don't know if existing applications use them though, if
> they do, there will be a
> problem to get them updated as the new bit isn't present on older
> kernels...
Is it really important? These instructions become nop on Cell, so their
impact on performance should be minimal while they may be useful in
code designed to run on any processor having Altivec.
> - Extended implementation of dcbt. (Another bit ? Or sould we just have
> a "CELL" bit ? In which
> case should it cover the altivec additions too or are those likely to
> exist in future non-Cell
> processors ?)
I believe that a Cell bit would be useful. After all you need a bit
that tell you that you have the SPUs and related infrastructure?
> - Not strictly Cell specific but we currently don't expose the support
> for optional instructions
> fres and frsqte (which are supported by Cell)
Should be exposed IMHO. But these instructions have been present
in a lot of PPC processors AFAIR, they are in my original 603 and
604 manuals from 1994 (fsel is also marked as optional and is not
implemented on the 601, but I'm not sure it's really supported
anymore). I don't know about Power processors.
> Part of the problem is that we only have 32 userland feature bits and
> for some reason decided to put the microarchitecture in there, thus we
> are running out fast...
It will have to be extended and perhaps become a variable length
structure, better sooner than later.
Regards,
Gabriel
^ permalink raw reply
* Re: MPC8xx: resolution of gettimeofday() ?
From: Steven Scholz @ 2006-05-19 8:08 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20060518164812.GA21075@gate.ebshome.net>
Eugene,
>> what is the resolution of gettimeofday() for an MPC8xx?
>>
>> IIUC then the "decrementer" is used to generate the timer interrupts every 10ms.
>>
>> This decrementer runs at cpuclk/16. Thus with 80MHz CPU clock has a
>> resolution of 16/80MHz = 200ns and overflows every 50000 ticks.
>>
>> But is this decrementer used to update xtime?
>> Will gettimeofday() have a resolution of 200ns?
>>
>> How about linux 2.4 where xtime is a "struct timeval" rather then "struct
>> timespec"?
>>
>
> Usually on PPC we use timebase to interpolate time between Decrementer
> interrupts. In this case gettimeofday resolution is determined by
> timebase resolution which is quite high (megahertz range).
Sorry. I don't understand. What do you mean with "timebase"? Is there a
second timer/counter?
--
Steven
^ permalink raw reply
* Re: [Cbe-oss-dev] Cell and new CPU feature bits
From: Segher Boessenkool @ 2006-05-19 7:49 UTC (permalink / raw)
To: Andrew Pinski
Cc: Olof Johansson, linuxppc-dev list, cbe-oss-dev, Arnd Bergmann
In-Reply-To: <11D4E003-85A4-48A0-9654-BEAE5600B89C@physics.uc.edu>
>> I'm assuming you mean the instructions described under "AltiVec
>> Memory
>> Bandwidth Management" in secion 5.2 of the Altivec PEM -- dst, dstt,
>> dstst, dss and dssall?
>
> They are nops on the Cell though.
And that is a compliant implementation. I don't see a need
or real use for a feature bit here, esp. if we do get one for
the extended dcbt insns (which often are used as a replacement
for the data streaming insns).
> They are also microcoded on the 970.
No, they are cracked, instead. Much lower hit. They are completion
serialized though, so the only insn in an issue group, etc.
Segher
^ permalink raw reply
* [PATCH 14/14] powerpc: cleanup of iSeries flat device tree
From: Stephen Rothwell @ 2006-05-19 7:06 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
In-Reply-To: <20060519164249.2dc43bc4.sfr@canb.auug.org.au>
Consolidate the vio device node creation. Make some parameters const.
Make a few more things __initdata. Get the device_type strings out of
the device tree blob.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/platforms/iseries/dt.c | 199 ++++++++++++++++++-----------------
1 files changed, 101 insertions(+), 98 deletions(-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
89435c92f9a6d37d8d47bf40acde012726780f7f
diff --git a/arch/powerpc/platforms/iseries/dt.c b/arch/powerpc/platforms/iseries/dt.c
index 2a51ec1..d3444aa 100644
--- a/arch/powerpc/platforms/iseries/dt.c
+++ b/arch/powerpc/platforms/iseries/dt.c
@@ -47,16 +47,34 @@ #else
#define DBG(fmt...)
#endif
+/*
+ * These are created by the linker script at the start and end
+ * of the section containing all the strings from this file.
+ */
extern char __dt_strings_start[];
extern char __dt_strings_end[];
struct iseries_flat_dt {
struct boot_param_header header;
u64 reserve_map[2];
- void *data;
};
-static struct iseries_flat_dt *iseries_dt;
+static void * __initdata dt_data;
+
+/*
+ * Putting these strings here keeps them out of the section
+ * that we rename to .dt_strings using objcopy and capture
+ * for the strings blob of the flattened device tree.
+ */
+static char __initdata device_type_cpu[] = "cpu";
+static char __initdata device_type_memory[] = "memory";
+static char __initdata device_type_serial[] = "serial";
+static char __initdata device_type_network[] = "network";
+static char __initdata device_type_block[] = "block";
+static char __initdata device_type_byte[] = "byte";
+static char __initdata device_type_pci[] = "pci";
+static char __initdata device_type_vdevice[] = "vdevice";
+static char __initdata device_type_vscsi[] = "vscsi";
static struct iseries_flat_dt * __init dt_init(void)
{
@@ -70,7 +88,7 @@ static struct iseries_flat_dt * __init d
dt->header.off_dt_strings = ALIGN(sizeof(*dt), 8);
dt->header.off_dt_struct = dt->header.off_dt_strings
+ ALIGN(str_len, 8);
- dt->data = (void *)((unsigned long)dt + dt->header.off_dt_struct);
+ dt_data = (void *)((unsigned long)dt + dt->header.off_dt_struct);
dt->header.dt_strings_size = str_len;
/* There is no notion of hardware cpu id on iSeries */
@@ -91,26 +109,26 @@ static struct iseries_flat_dt * __init d
static void __init dt_push_u32(struct iseries_flat_dt *dt, u32 value)
{
- *((u32 *)dt->data) = value;
- dt->data += sizeof(u32);
+ *((u32 *)dt_data) = value;
+ dt_data += sizeof(u32);
}
#ifdef notyet
static void __init dt_push_u64(struct iseries_flat_dt *dt, u64 value)
{
- *((u64 *)dt->data) = value;
- dt->data += sizeof(u64);
+ *((u64 *)dt_data) = value;
+ dt_data += sizeof(u64);
}
#endif
-static void __init dt_push_bytes(struct iseries_flat_dt *dt, char *data,
+static void __init dt_push_bytes(struct iseries_flat_dt *dt, const char *data,
int len)
{
- memcpy(dt->data, data, len);
- dt->data += ALIGN(len, 4);
+ memcpy(dt_data, data, len);
+ dt_data += ALIGN(len, 4);
}
-static void __init dt_start_node(struct iseries_flat_dt *dt, char *name)
+static void __init dt_start_node(struct iseries_flat_dt *dt, const char *name)
{
dt_push_u32(dt, OF_DT_BEGIN_NODE);
dt_push_bytes(dt, name, strlen(name) + 1);
@@ -118,8 +136,8 @@ static void __init dt_start_node(struct
#define dt_end_node(dt) dt_push_u32(dt, OF_DT_END_NODE)
-static void __init dt_prop(struct iseries_flat_dt *dt, char *name,
- void *data, int len)
+static void __init dt_prop(struct iseries_flat_dt *dt, const char *name,
+ const void *data, int len)
{
unsigned long offset;
@@ -137,36 +155,40 @@ static void __init dt_prop(struct iserie
dt_push_bytes(dt, data, len);
}
-static void __init dt_prop_str(struct iseries_flat_dt *dt, char *name,
- char *data)
+static void __init dt_prop_str(struct iseries_flat_dt *dt, const char *name,
+ const char *data)
{
dt_prop(dt, name, data, strlen(data) + 1); /* + 1 for NULL */
}
-static void __init dt_prop_u32(struct iseries_flat_dt *dt, char *name, u32 data)
+static void __init dt_prop_u32(struct iseries_flat_dt *dt, const char *name,
+ u32 data)
{
dt_prop(dt, name, &data, sizeof(u32));
}
-static void __init dt_prop_u64(struct iseries_flat_dt *dt, char *name, u64 data)
+#ifdef notyet
+static void __init dt_prop_u64(struct iseries_flat_dt *dt, const char *name,
+ u64 data)
{
dt_prop(dt, name, &data, sizeof(u64));
}
+#endif
-static void __init dt_prop_u64_list(struct iseries_flat_dt *dt, char *name,
- u64 *data, int n)
+static void __init dt_prop_u64_list(struct iseries_flat_dt *dt,
+ const char *name, u64 *data, int n)
{
dt_prop(dt, name, data, sizeof(u64) * n);
}
-static void __init dt_prop_u32_list(struct iseries_flat_dt *dt, char *name,
- u32 *data, int n)
+static void __init dt_prop_u32_list(struct iseries_flat_dt *dt,
+ const char *name, u32 *data, int n)
{
dt_prop(dt, name, data, sizeof(u32) * n);
}
#ifdef notyet
-static void __init dt_prop_empty(struct iseries_flat_dt *dt, char *name)
+static void __init dt_prop_empty(struct iseries_flat_dt *dt, const char *name)
{
dt_prop(dt, name, NULL, 0);
}
@@ -199,7 +221,7 @@ static void __init dt_cpus(struct iserie
snprintf(p, 32 - (p - buf), "@%d", i);
dt_start_node(dt, buf);
- dt_prop_str(dt, "device_type", "cpu");
+ dt_prop_str(dt, "device_type", device_type_cpu);
index = lppaca[i].dyn_hv_phys_proc_index;
d = &xIoHriProcessorVpd[index];
@@ -244,32 +266,41 @@ static void __init dt_model(struct iseri
dt_prop_str(dt, "compatible", "IBM,iSeries");
}
+static void __init dt_do_vdevice(struct iseries_flat_dt *dt,
+ const char *name, u32 reg, int unit,
+ const char *type, const char *compat, int end)
+{
+ char buf[32];
+
+ snprintf(buf, 32, "%s@%08x", name, reg + ((unit >= 0) ? unit : 0));
+ dt_start_node(dt, buf);
+ dt_prop_str(dt, "device_type", type);
+ if (compat)
+ dt_prop_str(dt, "compatible", compat);
+ dt_prop_u32(dt, "reg", reg + ((unit >= 0) ? unit : 0));
+ if (unit >= 0)
+ dt_prop_u32(dt, "linux,unit_address", unit);
+ if (end)
+ dt_end_node(dt);
+}
+
static void __init dt_vdevices(struct iseries_flat_dt *dt)
{
u32 reg = 0;
HvLpIndexMap vlan_map;
int i;
- char buf[32];
dt_start_node(dt, "vdevice");
- dt_prop_str(dt, "device_type", "vdevice");
+ dt_prop_str(dt, "device_type", device_type_vdevice);
dt_prop_str(dt, "compatible", "IBM,iSeries-vdevice");
dt_prop_u32(dt, "#address-cells", 1);
dt_prop_u32(dt, "#size-cells", 0);
- snprintf(buf, sizeof(buf), "vty@%08x", reg);
- dt_start_node(dt, buf);
- dt_prop_str(dt, "device_type", "serial");
- dt_prop_u32(dt, "reg", reg);
- dt_end_node(dt);
+ dt_do_vdevice(dt, "vty", reg, -1, device_type_serial, NULL, 1);
reg++;
- snprintf(buf, sizeof(buf), "v-scsi@%08x", reg);
- dt_start_node(dt, buf);
- dt_prop_str(dt, "device_type", "vscsi");
- dt_prop_str(dt, "compatible", "IBM,v-scsi");
- dt_prop_u32(dt, "reg", reg);
- dt_end_node(dt);
+ dt_do_vdevice(dt, "v-scsi", reg, -1, device_type_vscsi,
+ "IBM,v-scsi", 1);
reg++;
vlan_map = HvLpConfig_getVirtualLanIndexMap();
@@ -278,13 +309,8 @@ static void __init dt_vdevices(struct is
if ((vlan_map & (0x8000 >> i)) == 0)
continue;
- snprintf(buf, 32, "l-lan@%08x", reg + i);
- dt_start_node(dt, buf);
- dt_prop_str(dt, "device_type", "network");
- dt_prop_str(dt, "compatible", "IBM,iSeries-l-lan");
- dt_prop_u32(dt, "reg", reg + i);
- dt_prop_u32(dt, "linux,unit_address", i);
-
+ dt_do_vdevice(dt, "l-lan", reg, i, device_type_network,
+ "IBM,iSeries-l-lan", 0);
mac_addr[0] = 0x02;
mac_addr[1] = 0x01;
mac_addr[2] = 0xff;
@@ -300,47 +326,31 @@ static void __init dt_vdevices(struct is
}
reg += HVMAXARCHITECTEDVIRTUALLANS;
- for (i = 0; i < HVMAXARCHITECTEDVIRTUALDISKS; i++) {
- snprintf(buf, 32, "viodasd@%08x", reg + i);
- dt_start_node(dt, buf);
- dt_prop_str(dt, "device_type", "block");
- dt_prop_str(dt, "compatible", "IBM,iSeries-viodasd");
- dt_prop_u32(dt, "reg", reg + i);
- dt_prop_u32(dt, "linux,unit_address", i);
- dt_end_node(dt);
- }
+ for (i = 0; i < HVMAXARCHITECTEDVIRTUALDISKS; i++)
+ dt_do_vdevice(dt, "viodasd", reg, i, device_type_block,
+ "IBM,iSeries-viodasd", 1);
reg += HVMAXARCHITECTEDVIRTUALDISKS;
- for (i = 0; i < HVMAXARCHITECTEDVIRTUALCDROMS; i++) {
- snprintf(buf, 32, "viocd@%08x", reg + i);
- dt_start_node(dt, buf);
- dt_prop_str(dt, "device_type", "block");
- dt_prop_str(dt, "compatible", "IBM,iSeries-viocd");
- dt_prop_u32(dt, "reg", reg + i);
- dt_prop_u32(dt, "linux,unit_address", i);
- dt_end_node(dt);
- }
+
+ for (i = 0; i < HVMAXARCHITECTEDVIRTUALCDROMS; i++)
+ dt_do_vdevice(dt, "viocd", reg, i, device_type_block,
+ "IBM,iSeries-viocd", 1);
reg += HVMAXARCHITECTEDVIRTUALCDROMS;
- for (i = 0; i < HVMAXARCHITECTEDVIRTUALTAPES; i++) {
- snprintf(buf, 32, "viotape@%08x", reg + i);
- dt_start_node(dt, buf);
- dt_prop_str(dt, "device_type", "byte");
- dt_prop_str(dt, "compatible", "IBM,iSeries-viotape");
- dt_prop_u32(dt, "reg", reg + i);
- dt_prop_u32(dt, "linux,unit_address", i);
- dt_end_node(dt);
- }
+
+ for (i = 0; i < HVMAXARCHITECTEDVIRTUALTAPES; i++)
+ dt_do_vdevice(dt, "viotape", reg, i, device_type_byte,
+ "IBM,iSeries-viotape", 1);
dt_end_node(dt);
}
struct pci_class_name {
u16 code;
- char *name;
- char *type;
+ const char *name;
+ const char *type;
};
static struct pci_class_name __initdata pci_class_name[] = {
- { PCI_CLASS_NETWORK_ETHERNET, "ethernet", "network" },
+ { PCI_CLASS_NETWORK_ETHERNET, "ethernet", device_type_network },
};
static struct pci_class_name * __init dt_find_pci_class_name(u16 class_code)
@@ -384,9 +394,7 @@ static void __init scan_bridge_slot(stru
agent_id, 0);
if (err) {
if (err != 0x302)
- printk(KERN_DEBUG
- "connectBusUnit(%x, %x, %x) "
- "== %x\n",
+ DBG("connectBusUnit(%x, %x, %x) %x\n",
bus, sub_bus, agent_id, err);
continue;
}
@@ -394,24 +402,21 @@ static void __init scan_bridge_slot(stru
err = HvCallPci_configLoad16(bus, sub_bus, agent_id,
PCI_VENDOR_ID, &vendor_id);
if (err) {
- printk(KERN_DEBUG
- "ReadVendor(%x, %x, %x) == %x\n",
+ DBG("ReadVendor(%x, %x, %x) %x\n",
bus, sub_bus, agent_id, err);
continue;
}
err = HvCallPci_configLoad16(bus, sub_bus, agent_id,
PCI_DEVICE_ID, &device_id);
if (err) {
- printk(KERN_DEBUG
- "ReadDevice(%x, %x, %x) == %x\n",
+ DBG("ReadDevice(%x, %x, %x) %x\n",
bus, sub_bus, agent_id, err);
continue;
}
err = HvCallPci_configLoad32(bus, sub_bus, agent_id,
PCI_CLASS_REVISION , &class_id);
if (err) {
- printk(KERN_DEBUG
- "ReadClass(%x, %x, %x) == %x\n",
+ DBG("ReadClass(%x, %x, %x) %x\n",
bus, sub_bus, agent_id, err);
continue;
}
@@ -470,19 +475,18 @@ static void __init scan_bridge(struct is
ret = HvCallXm_connectBusUnit(bus, sub_bus, agent_id, 0);
if (ret != 0) {
if (ret != 0xb)
- printk(KERN_DEBUG "connectBusUnit(%x, %x, %x) "
- "== %x\n",
+ DBG("connectBusUnit(%x, %x, %x) %x\n",
bus, sub_bus, agent_id, ret);
continue;
}
- printk("found device at bus %d idsel %d func %d (AgentId %x)\n",
+ DBG("found device at bus %d idsel %d func %d (AgentId %x)\n",
bus, id_sel, function, agent_id);
ret = HvCallPci_getBusUnitInfo(bus, sub_bus, agent_id,
iseries_hv_addr(&bridge_info),
sizeof(struct HvCallPci_BridgeInfo));
if (ret != 0)
continue;
- printk("bridge info: type %x subbus %x "
+ DBG("bridge info: type %x subbus %x "
"maxAgents %x maxsubbus %x logslot %x\n",
bridge_info.busUnitInfo.deviceType,
bridge_info.subBusNumber,
@@ -493,7 +497,7 @@ static void __init scan_bridge(struct is
HvCallPci_BridgeDevice)
scan_bridge_slot(dt, bus, &bridge_info);
else
- printk("PCI: Invalid Bridge Configuration(0x%02X)",
+ DBG("PCI: Invalid Bridge Configuration(0x%02X)",
bridge_info.busUnitInfo.deviceType);
}
}
@@ -515,13 +519,12 @@ static void __init scan_phb(struct iseri
sizeof(struct HvCallPci_DeviceInfo));
if (err) {
if (err != 0x302)
- printk(KERN_DEBUG "getDeviceInfo(%x, %x, %x) "
- "== %x\n",
+ DBG("getDeviceInfo(%x, %x, %x) %x\n",
bus, sub_bus, id_sel, err);
continue;
}
if (dev_info.deviceType != HvCallPci_NodeDevice) {
- printk(KERN_DEBUG "PCI: Invalid System Configuration"
+ DBG("PCI: Invalid System Configuration"
"(0x%02X) for bus 0x%02x id 0x%02x.\n",
dev_info.deviceType, bus, id_sel);
continue;
@@ -547,14 +550,14 @@ static void __init dt_pci_devices(struct
* something has gone wrong.
*/
if (err != 0x0301)
- printk(KERN_ERR "Unexpected Return on Probe"
- "(0x%02X): 0x%04X", bus, err);
+ DBG("Unexpected Return on Probe(0x%02X) "
+ "0x%04X\n", bus, err);
continue;
}
- printk("bus %d appears to exist\n", bus);
+ DBG("bus %d appears to exist\n", bus);
snprintf(buf, 32, "pci@%d", phb_num);
dt_start_node(dt, buf);
- dt_prop_str(dt, "device_type", "pci");
+ dt_prop_str(dt, "device_type", device_type_pci);
dt_prop_str(dt, "compatible", "IBM,iSeries-Logical-PHB");
dt_prop_u32(dt, "#address-cells", 3);
dt_prop_u32(dt, "#size-cells", 2);
@@ -569,12 +572,13 @@ static void __init dt_pci_devices(struct
static void dt_finish(struct iseries_flat_dt *dt)
{
dt_push_u32(dt, OF_DT_END);
- dt->header.totalsize = (unsigned long)dt->data - (unsigned long)dt;
- klimit = ALIGN((unsigned long)dt->data, 8);
+ dt->header.totalsize = (unsigned long)dt_data - (unsigned long)dt;
+ klimit = ALIGN((unsigned long)dt_data, 8);
}
void * __init build_flat_dt(unsigned long phys_mem_size)
{
+ struct iseries_flat_dt *iseries_dt;
u64 tmp[2];
iseries_dt = dt_init();
@@ -587,8 +591,7 @@ void * __init build_flat_dt(unsigned lon
/* /memory */
dt_start_node(iseries_dt, "memory@0");
- dt_prop_str(iseries_dt, "name", "memory");
- dt_prop_str(iseries_dt, "device_type", "memory");
+ dt_prop_str(iseries_dt, "device_type", device_type_memory);
tmp[0] = 0;
tmp[1] = phys_mem_size;
dt_prop_u64_list(iseries_dt, "reg", tmp, 2);
--
1.3.1.ge923
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox