* 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: 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: 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: 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
* 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: [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
* 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: 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: 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: 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: 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: 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: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: 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: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 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
* [RFC] snd-aoa and interrupts (headphone detection etc)
From: Johannes Berg @ 2006-05-19 16:15 UTC (permalink / raw)
To: linuxppc-dev list
[-- Attachment #1: Type: text/plain, Size: 2668 bytes --]
Hey,
I thought about this a bit, but I'm not sure what the right way to
handle this is. First, I guess an introduction is on order about how the
fabrics and codecs currently work together.
As codecs can have arbitrary inputs and outputs, we have to keep this
generic enough. The tas for example has one analog output, and two
analog inputs (line-in and microphone). The analog output it has is
connected to the amps and then you can select where you want to hear
sound (possibly line-out, headphone, speakers) by controlling the amps
via the GPIOs.
On the other hand, the onyx for example has digital and analog output
along with two analog inputs. Instead of limiting myself to any fixed
items I decided to keep this generic. I probably should change this to
introduce fixed bits for various items though.
Anyway, the fabric has the hardcoded list of how things are hooked up,
and then creates a bitmap of which in/outputs of a codec are connected
and gives this bitmap to the codec driver which creates the appropriate
controls if applicable. This is currently only implemented properly for
the Onyx chip though.
Now, in- and output detection comes into play. The interrupt is always
generated via GPIOs.
Headphone detection is easy: We make the fabric register the interrupt
via the GPIO layer and when we get an interrupt we actually simply do
whatever the user wanted (this ought to be controllable).
The problematic part is things that the codec must control. Say we want
line-in detection to automatically switch to line-in if microphone is
selected (does anyone ever want this?). Then the problem is that the
interrupt arrives at the GPIO layer, and I can easily make it seen in
the fabric too. However, then propagating it to the codec is a bit
harder. Or we don't have it in the fabric but have the codec register
for that interrupt (through our GPIO layer). This is the first option.
The second option is changing the whole in-/output control code that we
have and moving it from the codec to the fabric layer. The fabric
already knows what in- and outputs a codec has (in order to know what is
connected), hence if we added a codec driver function to turn on/off any
in- or output we could have the fabric control this. But then we'd also
have to make known to the codec which of those are mutually exclusive,
and generally make it more complicated.
I currently favour the first option, the codec driver can know when it
makes sense to try registering the interrupt (if it isn't present it
fails anyway) and then do the appropriate stuff (possibly giving the
user a choice).
Comments?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: Cell and new CPU feature bits
From: Olof Johansson @ 2006-05-19 16:18 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev list, paulus, cbe-oss-dev
In-Reply-To: <200605191211.18737.arnd@arndb.de>
On Fri, May 19, 2006 at 12:11:18PM +0200, Arnd Bergmann wrote:
> 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
First, please don't use the cell bit for this since other processors
seem to implement the same things.
Second, the quoted information is 6 months old, and seemingly stale by
now. When Paulus pushed the POWER6 patch, he switched from the notion
of it signifying processor model to being base arch version. See:
http://ozlabs.org/pipermail/linuxppc-dev/2006-April/022525.html
(My patch to rename the existing POWER* bits to ARCH_2_* wasn't picked
up, I'll resend)
-Olof
^ permalink raw reply
* To connect USB Bluetooth Dongle with embedded linux platform MPC 5200 Lite
From: jabir.kannath @ 2006-05-19 15:53 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
=0D
We are in need of re-building Linux kernel 2.4.25 to support USB
Bluetooth Dongle for the embedded platform MPC 5200 Lite.
=0D
With the new kernel running and on connecting USB Bluetooth Dongle to
icecube (MPC5200 Lite EVM) running embedded Linux from Denx, error "USB
device not accepting new address". We would appreciate any kind of help
towards solving the issue.
=0D
We added USB and Bluetooth support with the configurations available in
the file icecube_5200_defconfig and rebuild the kernel using 'make
uImage'. For USB setting, we have referred icecube_5200_CoralPdefconfig
file. Kindly help us in identifying the reason for the issue.
=0D
Please see the boot up log as follows:
=0D
........................................................................
..................
=0D
=0D
=0D
U-Boot 1.1.3 (May 20 2005 - 18:29:54)
=0D
=0D
=0D
CPU: MPC5200 v1.2 at 396 MHz
=0D
Bus 132 MHz, IPB 66 MHz, PCI 33 MHz
=0D
Board: Motorola MPC5200 (IceCube)
=0D
I2C: 85 kHz, ready
=0D
DRAM: 64 MB
=0D
FLASH: 16 MB
=0D
PCI: Bus Dev VenId DevId Class Int
=0D
00 1a 1057 5803 0680 00
=0D
In: serial
=0D
Out: serial
=0D
Err: serial
=0D
Net: FEC ETHERNET
=0D
IDE: Bus 0: OK
=0D
Device 0: Model: ST340015A Firm: 3.15 Ser#: 5LAMQLQ6
=0D
Type: Hard Disk
=0D
Capacity: 38166.6 MB =3D 37.2 GB (78165360 x 512)
=0D
Device 1: not available
=0D
=0D
=0D
Type "run flash_nfs" to mount root filesystem over NFS
=0D
=0D
=0D
Hit any key to stop autoboot: 0
=0D
## Booting image at fff00000 ...
=0D
Image Name: Linux PPC MPC5200 2.4
=0D
Image Type: PowerPC Linux Kernel Image (gzip compressed)
=0D
Data Size: 931083 Bytes =3D 909.3 kB
=0D
Load Address: 00000000
=0D
Entry Point: 00000000
=0D
Verifying Checksum ... OK
=0D
Uncompressing Kernel Image ... OK
=0D
Memory BAT mapping: BAT2=3D64Mb, BAT3=3D0Mb, residual: 0Mb
=0D
Linux version 2.4.25 (root@M4-110822) (gcc version 3.3.3 (DENX ELDK
3.1.1 3.3.3-10)) #1 Wed May 17 19:02:37 IST 2006
=0D
On node 0 totalpages: 16384
=0D
zone(0): 16384 pages.
=0D
zone(1): 0 pages.
=0D
zone(2): 0 pages.
=0D
Kernel command line: root=3D/dev/hda1 rw
ip=3D10.114.105.162:10.114.105.41:10.114.105.41:255.255.255.0:icecube:eth0
:off panic=3D1
=0D
Calibrating delay loop... 263.78 BogoMIPS
=0D
Memory: 62088k available (1564k kernel code, 524k data, 76k init, 0k
highmem)
=0D
Dentry cache hash table entries: 8192 (order: 4, 65536 bytes)
=0D
Inode cache hash table entries: 4096 (order: 3, 32768 bytes)
=0D
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
=0D
Buffer cache hash table entries: 4096 (order: 2, 16384 bytes)
=0D
Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
=0D
POSIX conformance testing by UNIFIX
=0D
PCI: Probing PCI hardware
=0D
PCI: Cannot allocate resource region 0 of device 00:1a.0
=0D
Linux NET4.0 for Linux 2.4
=0D
Based upon Swansea University Computer Society NET3.039
=0D
Initializing RT netlink socket
=0D
Starting kswapd
=0D
Journalled Block Device driver loaded
=0D
JFFS2 version 2.2. (C) 2001-2003 Red Hat, Inc.
=0D
pty: 256 Unix98 ptys configured
=0D
ttyS0 on PSC1
=0D
ttyS1 on PSC2
=0D
ttyS2 on PSC3
=0D
RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize
=0D
loop: loaded (max 8 devices)
=0D
Uniform Multi-Platform E-IDE driver Revision: 7.00beta4-2.4
=0D
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=3Dxx
=0D
Port Config is: 0x11050004
=0D
ipb=3D66MHz, set clock period to 15
=0D
GPIO config: 11050004
=0D
ATA invalid: 00800000
=0D
ATA hostcnf: 03000000
=0D
ATA pio1 : 100a0a00
=0D
ATA pio2 : 02040600
=0D
XLB Arb cnf: 0000a366
=0D
mpc5xxx_ide: Setting up IDE interface ide0...
=0D
ATA DMA task: 5
=0D
Probing IDE interface ide0...
=0D
hda: ST340015A, ATA DISK drive
=0D
hda: Setting UDMA 2 timings
=0D
hda: Setting PIO 4 timings
=0D
ide0 at 0xf0003a60-0xf0003a67,0xf0003a5c on irq 45
=0D
hda: attached ide-disk driver.
=0D
hda: host protected area =3D> 1
=0D
hda: 78165360 sectors (40021 MB) w/2048KiB Cache, CHS=3D77545/16/63,
UDMA(33)
=0D
Partition check:
=0D
hda:<7>Unhandled interrupt 1a, disabled
=0D
hda1 hda2
=0D
Icecube Bank 0: Found 1 x8 devices at 0x0 in 8-bit mode
=0D
Icecube Bank 0: Found 1 x8 devices at 0x800000 in 8-bit mode
=0D
Amd/Fujitsu Extended Query Table at 0x0040
=0D
Icecube Bank 0: CFI does not contain boot bank location. Assuming top.
=0D
number of CFI chips: 2
=0D
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
=0D
Icecube flash bank 0: Using static image partition definition
=0D
Creating 5 MTD partitions on "Icecube Bank 0":
=0D
0x00000000-0x00800000 : "Spare"
=0D
0x00800000-0x00900000 : "kernel"
=0D
0x00900000-0x00c00000 : "initrd"
=0D
0x00c00000-0x00f00000 : "jffs"
=0D
0x00f00000-0x01000000 : "Firmware"
=0D
usb.c: registered new driver usbdevfs
=0D
usb.c: registered new driver hub
=0D
host/usb-ohci.c: USB OHCI at membase 0xf0001000, IRQ 44
=0D
host/usb-ohci.c: usb-0, Built-In ohci
=0D
usb.c: new USB bus registered, assigned bus number 1
=0D
hub.c: USB hub found
=0D
hub.c: 2 ports detected
=0D
usb.c: registered new driver hiddev
=0D
usb.c: registered new driver hid
=0D
hid-core.c: v1.8.1 Andreas Gal, Vojtech Pavlik <vojtech@suse.cz>
=0D
hid-core.c: USB HID support drivers
=0D
NET4: Linux TCP/IP 1.0 for NET4.0
=0D
eth0: Phy @ 0x0, type LXT971 (0x001378e2)
=0D
IP Protocols: ICMP, UDP, TCP, IGMP
=0D
IP: routing cache hash table of 512 buckets, 4Kbytes
=0D
TCP: Hash tables configured (established 4096 bind 8192)
=0D
eth0: config: auto-negotiation on, 100FDX, 100HDX, 10FDX, 10HDX.
=0D
IP-Config: Complete:
=0D
device=3Deth0, addr=3D10.114.105.162, mask=3D255.255.255.0,
gw=3D10.114.105.41,
=0D
host=3Dicecube, domain=3D, nis-domain=3D(none),
=0D
bootserver=3D10.114.105.41, rootserver=3D10.114.105.41, rootpath=3D
=0D
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
=0D
hub.c: new USB device 0-1, assigned address 2
=0D
usb.c: USB device not accepting new address=3D2 (error=3D-110)
=0D
hub.c: new USB device 0-1, assigned address 3
=0D
usb.c: USB device not accepting new address=3D3 (error=3D-110)
=0D
kjournald starting. Commit interval 5 seconds
=0D
EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,1), internal journal
=0D
EXT3-fs: recovery complete.
=0D
EXT3-fs: mounted filesystem with ordered data mode.
=0D
VFS: Mounted root (ext3 filesystem).
=0D
Freeing unused kernel memory: 76k init
=0D
modprobe: Note: /etc/modules.conf is more recent than
/lib/modules/2.4.25/modules.dep
=0D
INIT: version 2.86 booting
=0D
eth0: status: link up, 100 Mbps Full Duplex, auto-negotiation complete.
=0D
Setting parameters of disc:hda: Setting UDMA 2 timings
=0D
hda: Setting PIO 4 timings
=0D
hda: DMA disabled
=0D
/dev/hda.
=0D
Activating swap.
=0D
Unable to find swap-space signature
=0D
Checking root file system...
=0D
fsck 1.38 (30-Jun-2005)
=0D
/dev/hda1: clean, 58172/2011296 files, 376931/4015864 blocks
=0D
EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,1), internal journal
=0D
RTC_RD_TIME: Invalid argument
=0D
ioctl() to /dev/rtc to read the time failed.
=0D
System time was Thu Jan 1 00:00:07 UTC 1970.
=0D
Setting the System Clock using the Hardware Clock as reference...
=0D
RTC_RD_TIME: Invalid argument
=0D
ioctl() to /dev/rtc to read the time failed.
=0D
System Clock set. System local time is now Thu Jan 1 00:00:07 UTC 1970.
=0D
Calculating module dependencies...done.
=0D
Loading modules:
=0D
Note: /etc/modules.conf is more recent than
/lib/modules/2.4.25/modules.dep
=0D
modprobe: Can't locate module *
=0D
Checking all file systems...
=0D
fsck 1.38 (30-Jun-2005)
=0D
Setting kernel variables ...
=0D
... done.
=0D
Mounting local filesystems...
=0D
Unable to find swap-space signature
=0D
Cleaning /tmpfind: warning: you have specified the -maxdepth option
after a non-option argument -perm, but options are not p.
=0D
find: warning: you have specified the -depth option after a non-option
argument !, but options are not positional (-depth af.
=0D
find: warning: you have specified the -depth option after a non-option
argument !, but options are not positional (-depth af.
=0D
/var/run /var/lock.
=0D
Running 0dns-down to make sure resolv.conf is ok...done.
=0D
Setting up networking...done.
=0D
Kernel hotplug support not enabled.
=0D
Setting up IP spoofing protection: rp_filter.
=0D
Configuring network interfaces...done.
=0D
Starting portmap daemon: portmap.
=0D
Loading the saved-state of the serial devices...
=0D
=0D
=0D
Setting the System Clock using the Hardware Clock as reference...
=0D
RTC_RD_TIME: Invalid argument
=0D
ioctl() to /dev/rtc to read the time failed.
=0D
System Clock set. Local time: Thu Jan 1 01:00:17 CET 1970
=0D
=0D
=0D
Running ntpdate to synchronize clockmodprobe: Note: /etc/modules.conf is
more recent than /lib/modules/2.4.25/modules.dep
=0D
modprobe: Note: /etc/modules.conf is more recent than
/lib/modules/2.4.25/modules.dep
=0D
.
=0D
Initializing random number generator...done.
=0D
Recovering nvi editor sessions... done.
=0D
Setting up X server socket directory /tmp/.X11-unix...done.
=0D
Setting up ICE socket directory /tmp/.ICE-unix...done.
=0D
INIT: Entering runlevel: 2
=0D
Starting system log daemon: syslogd.
=0D
Starting kernel log daemon: klogd.
=0D
Starting portmap daemon: portmap.
=0D
Starting automounter:.
=0D
Starting system message bus: dbus-1.
=0D
Starting internet superserver: inetd.
=0D
Starting printer spooler: lpd .
=0D
Starting PCMCIA services: Note: /etc/modules.conf is more recent than
/lib/modules/2.4.25/modules.dep
=0D
modprobe: Can't locate module pcmcia_core
=0D
Error: Failed to load pcmcia_core
=0D
Starting OpenBSD Secure Shell server: sshd.
=0D
Starting NFS common utilities: statd.
=0D
Starting NTP server: ntpd.
=0D
Starting bluez-utils: hcid sdpdBlueZ Core ver 2.3 Copyright (C)
2000,2001 Qualcomm Inc
=0D
Written 2000,2001 by Maxim Krasnyansky <maxk@qualcomm.com>
=0D
Can't open RFCOMM control socket: No such file or directory
=0D
rfcomm.
=0D
Starting deferred execution scheduler: atd.
=0D
Starting periodic command scheduler: cron.
=0D
=0D
=0D
Debian GNU/Linux testing/unstable lite5200revA_no2 ttyS0
=0D
=0D
=0D
lite5200revA_no2 login: =0D
=0D
=0D
=0D
........................................................................
.....................
=0D
=0D
The information contained in this electronic message and any attachments to=
this message are intended for the exclusive use of the addressee(s) and=
may contain proprietary, confidential or privileged information. If you=
are not the intended recipient, you should not disseminate, distribute or=
copy this e-mail. Please notify the sender immediately and destroy all=
copies of this message and any attachments.=0D
WARNING: Computer viruses can be transmitted via email. The recipient=
should check this email and any attachments for the presence of viruses.=
The company accepts no liability for any damage caused by any virus=
transmitted by this email.
=0D
www.wipro.com
^ permalink raw reply
* Re: PPC host with a PCI root-complex
From: Linas Vepstas @ 2006-05-19 16:23 UTC (permalink / raw)
To: Srinivas Murthy; +Cc: linuxppc-dev
In-Reply-To: <7cb1293c0605181456p3c1726e2n56942dfbd4217f70@mail.gmail.com>
On Thu, May 18, 2006 at 02:56:31PM -0700, Srinivas Murthy wrote:
> Hi,
>
> We have a ppc host with a PCI root-complex across which there are multiple
> PCI end points.
>
> An application running on the ppc host reading one of the device memory
> regions (not DMA access but direct CPU read) causes a parity error on the
> PCI interface controller.
>
> We think that the error should be propagated up as a machine-check which is
> considered a non-recoverable system-wide error. However with multiple PCI
> devices present we think that this is too generic and could be reduced to be
> a critical-error which could be recovered from.
The "PCI Error Recovery" API was created to deal with this kind of a
situation. See Documentation/pci-error-recovery.txt
In breif: if something like a PCI parity error is detected by the
hardware, then some arch-specific code runs; for example,
arch/powerpc/platforms/pseries/eeh.c.
This code notifies the PCI device driver (via generic callbacks in
include/linux/pci.h) about the error. The device driver may ask the
arch to have the pci device/bus/link/etc/ get reset, or not. If/when
the PCI bus/link is back to normal, the PCI device driver is notified
via callback, and resumes normal operation.
If you have questions/suggestions, let me know, I've been maintaining
this code, and am interested in seeing how well it can be adapted
to a broader range of hardware.
--linas
^ permalink raw reply
* I2C bus issues on MPC8248
From: Heiko Schocher @ 2006-05-19 16:37 UTC (permalink / raw)
To: linuxppc-embedded
Hello Laurent,
on Thu, 18 May 2006 14:33:58, Laurent Pinchart wrote:
> I'm trying to use the MPC8248 hardware I2C bus in a 2.6.16 kernel. The
> mailing
> list archives mention a driver for the MPC8260
> (http://ozlabs.org/pipermail/linuxppc-embedded/2006-May/022837.html) which I
> modified to reflect the memory map differences between the MPC8260 and the
> MPC8248, as mentionned in the e-mail.
>
> The good news is that the driver works. The bad news is that it doesn't work
OK.
> correctly.
:-(
> The Linux I2C layer probes the I2C bus for peripherals when drivers are
> loaded. The probing function writes a single byte with the device address and
> check if the data is acked. I monitored the SCL and SDA lines using an
[...]
> Using that code, no data is sent on the bus, the BD_SC_READY bit is never
> cleared and no interrupt is generated. Once again I suspected a CPM bug when
> writing a single byte on the bus, so I increased cbd_datlen to 2:
>
> tbdf[0].cbd_bufaddr = __pa(tb);
> tbdf[0].cbd_datlen = 2;
> tbdf[0].cbd_sc = count ? BD_SC_READY | BD_IIC_START :
> BD_SC_READY | BD_IIC_START | BD_SC_INTRPT |
> BD_SC_LAST | BD_SC_WRAP;
>
> This worked, and two bytes were written on the bus, leading me to believe that
> the CPM was at fault.
I don t know, if this is a CPM Bug, but it seems so to me ...
> Has anyone noticed the same behaviour ? Is there a workaround available ? I
> tried searching Freescale's website for CPM microcode updates but haven't
> found anything related to the I2C controller.
Yes, Holger Speck had the same problem. He solved it by doing the following:
If the cpm_iic_write is called with count = 0. He made a read with count = 1
I think this is safer than writing 2 Bytes to the Slave.
Could you try this?
Best regards
Heiko
^ permalink raw reply
* Re: MPC8xx: resolution of gettimeofday() ?
From: Eugene Surovegin @ 2006-05-19 17:55 UTC (permalink / raw)
To: Steven Scholz; +Cc: linuxppc-embedded
In-Reply-To: <446D7CFA.5060505@imc-berlin.de>
On Fri, May 19, 2006 at 10:08:26AM +0200, Steven Scholz wrote:
> 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?
PowerPC has a facility called timebase. This is 64-bit counter which
can be accessed using special instructions (mftb, mftbu on 32-bit PPC).
Counter resolution depends on particular chip implementation, some
use core clock, other use bus clock...
It's similar to the time-stamp counter in Intel CPUs (accessed
with rdtsc instruction).
Please, refer to PPC arch manuals for more information. Also, if you
really interested in how gettimeofday() is implemented, why don't you
look at the source code yourself?
--
Eugene
^ permalink raw reply
* Re: To connect USB Bluetooth Dongle with embedded linux platform MPC 5200 Lite
From: Wolfgang Denk @ 2006-05-19 19:15 UTC (permalink / raw)
To: jabir.kannath; +Cc: linuxppc-embedded
In-Reply-To: <41CB8F9678E6F0498DA096429793FA850D2379@blr-m3-msg.wipro.com>
In message <41CB8F9678E6F0498DA096429793FA850D2379@blr-m3-msg.wipro.com> you wrote:
>
> We are in need of re-building Linux kernel 2.4.25 to support USB
> Bluetooth Dongle for the embedded platform MPC 5200 Lite.
Have you checked that your BT dongle is really working in Linux? See
http://www.qbik.ch/usb/devices/search_res.php?pattern=bluetooth
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
An armed society is a polite society.
^ permalink raw reply
* Re: [PATCH] remove powerpc bitops infavor of existing generic bitops
From: Jon Mason @ 2006-05-19 20:35 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17517.20729.170817.242398@cargo.ozlabs.ibm.com>
On Fri, May 19, 2006 at 03:00:41PM +1000, Paul Mackerras wrote:
> Jon Mason writes:
>
> > There already exists a big endian safe bitops implementation in
> > lib/find_next_bit.c. The code in it is 90%+ common with the powerpc
> > specific version, so the powerpc version is redundant. This patch
> > makes the necessary changes to use the generic bitops in powerpc, and
> > removes the powerpc specific version.
>
> This patch breaks ARCH=ppc builds. Please resubmit with the necessary
> changes to arch/ppc/Kconfig as well.
>
> Paul.
Sorry. Here is the patch with the necessary correction.
Thanks,
Jon
Signed-off-by: Jon Mason <jdmason@us.ibm.com>
diff -r a89fd2f124df arch/powerpc/Kconfig
--- a/arch/powerpc/Kconfig Fri May 19 16:17:18 2006 +0700
+++ b/arch/powerpc/Kconfig Fri May 19 15:34:39 2006 -0500
@@ -42,6 +42,10 @@ config GENERIC_HWEIGHT
default y
config GENERIC_CALIBRATE_DELAY
+ bool
+ default y
+
+config GENERIC_FIND_NEXT_BIT
bool
default y
diff -r a89fd2f124df arch/powerpc/lib/Makefile
--- a/arch/powerpc/lib/Makefile Fri May 19 16:17:18 2006 +0700
+++ b/arch/powerpc/lib/Makefile Fri May 19 15:34:39 2006 -0500
@@ -7,7 +7,6 @@ obj-$(CONFIG_PPC32) += div64.o copy_32.o
obj-$(CONFIG_PPC32) += div64.o copy_32.o checksum_32.o
endif
-obj-y += bitops.o
obj-$(CONFIG_PPC64) += checksum_64.o copypage_64.o copyuser_64.o \
memcpy_64.o usercopy_64.o mem_64.o string.o \
strcase.o
diff -r a89fd2f124df arch/ppc/Kconfig
--- a/arch/ppc/Kconfig Fri May 19 16:17:18 2006 +0700
+++ b/arch/ppc/Kconfig Fri May 19 15:34:39 2006 -0500
@@ -37,6 +37,10 @@ config PPC32
# All PPCs use generic nvram driver through ppc_md
config GENERIC_NVRAM
+ bool
+ default y
+
+config GENERIC_FIND_NEXT_BIT
bool
default y
diff -r a89fd2f124df include/asm-powerpc/bitops.h
--- a/include/asm-powerpc/bitops.h Fri May 19 16:17:18 2006 +0700
+++ b/include/asm-powerpc/bitops.h Fri May 19 15:34:39 2006 -0500
@@ -288,8 +288,8 @@ static __inline__ int test_le_bit(unsign
#define __test_and_clear_le_bit(nr, addr) \
__test_and_clear_bit((nr) ^ BITOP_LE_SWIZZLE, (addr))
-#define find_first_zero_le_bit(addr, size) find_next_zero_le_bit((addr), (size), 0)
-unsigned long find_next_zero_le_bit(const unsigned long *addr,
+#define find_first_zero_le_bit(addr, size) generic_find_next_zero_le_bit((addr), (size), 0)
+unsigned long generic_find_next_zero_le_bit(const unsigned long *addr,
unsigned long size, unsigned long offset);
/* Bitmap functions for the ext2 filesystem */
@@ -309,7 +309,7 @@ unsigned long find_next_zero_le_bit(cons
#define ext2_find_first_zero_bit(addr, size) \
find_first_zero_le_bit((unsigned long*)addr, size)
#define ext2_find_next_zero_bit(addr, size, off) \
- find_next_zero_le_bit((unsigned long*)addr, size, off)
+ generic_find_next_zero_le_bit((unsigned long*)addr, size, off)
/* Bitmap functions for the minix filesystem. */
diff -r a89fd2f124df arch/powerpc/lib/bitops.c
--- a/arch/powerpc/lib/bitops.c Fri May 19 16:17:18 2006 +0700
+++ /dev/null Thu Jan 1 00:00:00 1970 +0000
@@ -1,150 +0,0 @@
-#include <linux/types.h>
-#include <linux/module.h>
-#include <asm/byteorder.h>
-#include <asm/bitops.h>
-
-/**
- * find_next_bit - find the next set bit in a memory region
- * @addr: The address to base the search on
- * @offset: The bitnumber to start searching at
- * @size: The maximum size to search
- */
-unsigned long find_next_bit(const unsigned long *addr, unsigned long size,
- unsigned long offset)
-{
- const unsigned long *p = addr + BITOP_WORD(offset);
- unsigned long result = offset & ~(BITS_PER_LONG-1);
- unsigned long tmp;
-
- if (offset >= size)
- return size;
- size -= result;
- offset %= BITS_PER_LONG;
- if (offset) {
- tmp = *(p++);
- tmp &= (~0UL << offset);
- if (size < BITS_PER_LONG)
- goto found_first;
- if (tmp)
- goto found_middle;
- size -= BITS_PER_LONG;
- result += BITS_PER_LONG;
- }
- while (size & ~(BITS_PER_LONG-1)) {
- if ((tmp = *(p++)))
- goto found_middle;
- result += BITS_PER_LONG;
- size -= BITS_PER_LONG;
- }
- if (!size)
- return result;
- tmp = *p;
-
-found_first:
- tmp &= (~0UL >> (BITS_PER_LONG - size));
- if (tmp == 0UL) /* Are any bits set? */
- return result + size; /* Nope. */
-found_middle:
- return result + __ffs(tmp);
-}
-EXPORT_SYMBOL(find_next_bit);
-
-/*
- * This implementation of find_{first,next}_zero_bit was stolen from
- * Linus' asm-alpha/bitops.h.
- */
-unsigned long find_next_zero_bit(const unsigned long *addr, unsigned long size,
- unsigned long offset)
-{
- const unsigned long *p = addr + BITOP_WORD(offset);
- unsigned long result = offset & ~(BITS_PER_LONG-1);
- unsigned long tmp;
-
- if (offset >= size)
- return size;
- size -= result;
- offset %= BITS_PER_LONG;
- if (offset) {
- tmp = *(p++);
- tmp |= ~0UL >> (BITS_PER_LONG - offset);
- if (size < BITS_PER_LONG)
- goto found_first;
- if (~tmp)
- goto found_middle;
- size -= BITS_PER_LONG;
- result += BITS_PER_LONG;
- }
- while (size & ~(BITS_PER_LONG-1)) {
- if (~(tmp = *(p++)))
- goto found_middle;
- result += BITS_PER_LONG;
- size -= BITS_PER_LONG;
- }
- if (!size)
- return result;
- tmp = *p;
-
-found_first:
- tmp |= ~0UL << size;
- if (tmp == ~0UL) /* Are any bits zero? */
- return result + size; /* Nope. */
-found_middle:
- return result + ffz(tmp);
-}
-EXPORT_SYMBOL(find_next_zero_bit);
-
-static inline unsigned int ext2_ilog2(unsigned int x)
-{
- int lz;
-
- asm("cntlzw %0,%1": "=r"(lz):"r"(x));
- return 31 - lz;
-}
-
-static inline unsigned int ext2_ffz(unsigned int x)
-{
- u32 rc;
- if ((x = ~x) == 0)
- return 32;
- rc = ext2_ilog2(x & -x);
- return rc;
-}
-
-unsigned long find_next_zero_le_bit(const unsigned long *addr,
- unsigned long size, unsigned long offset)
-{
- const unsigned int *p = ((const unsigned int *)addr) + (offset >> 5);
- unsigned int result = offset & ~31;
- unsigned int tmp;
-
- if (offset >= size)
- return size;
- size -= result;
- offset &= 31;
- if (offset) {
- tmp = cpu_to_le32p(p++);
- tmp |= ~0U >> (32 - offset); /* bug or feature ? */
- if (size < 32)
- goto found_first;
- if (tmp != ~0)
- goto found_middle;
- size -= 32;
- result += 32;
- }
- while (size >= 32) {
- if ((tmp = cpu_to_le32p(p++)) != ~0)
- goto found_middle;
- result += 32;
- size -= 32;
- }
- if (!size)
- return result;
- tmp = cpu_to_le32p(p);
-found_first:
- tmp |= ~0 << size;
- if (tmp == ~0) /* Are any bits zero? */
- return result + size; /* Nope. */
-found_middle:
- return result + ext2_ffz(tmp);
-}
-EXPORT_SYMBOL(find_next_zero_le_bit);
^ permalink raw reply
* Re: PPC host with a PCI root-complex
From: Srinivas Murthy @ 2006-05-19 21:28 UTC (permalink / raw)
To: Linas Vepstas; +Cc: linuxppc-dev
In-Reply-To: <20060519162310.GI12135@austin.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 2496 bytes --]
Thanks for the reply.
I have a couple of concerns here. I would appreciate if you could provide
your thoughts.
On a PPC (44x) platform, following an error such as parity error detected by
the PCI root complex, should we cause a bus error (causing a machine-check
exception) or complete the bus transaction normally but trigger a critical
interrupt? Note that these are two diff types of interrupts as seen by the
CPU with the machine check having the highest NMI priority.
If the parity error detection was a result of say a memory read operation by
the core to a PCI device, there might be a several cycle diff between the
read and the cpu being interrupted (with the critical interrupt handler).
This may result in data corruption, etc. Is this a valid concern to have?
What is the normal approach to deal with this issue in an "enterprise" or
high-end environment?
On 5/19/06, Linas Vepstas <linas@austin.ibm.com> wrote:
>
> On Thu, May 18, 2006 at 02:56:31PM -0700, Srinivas Murthy wrote:
> > Hi,
> >
> > We have a ppc host with a PCI root-complex across which there are
> multiple
> > PCI end points.
> >
> > An application running on the ppc host reading one of the device memory
> > regions (not DMA access but direct CPU read) causes a parity error on
> the
> > PCI interface controller.
> >
> > We think that the error should be propagated up as a machine-check which
> is
> > considered a non-recoverable system-wide error. However with multiple
> PCI
> > devices present we think that this is too generic and could be reduced
> to be
> > a critical-error which could be recovered from.
>
> The "PCI Error Recovery" API was created to deal with this kind of a
> situation. See Documentation/pci-error-recovery.txt
>
> In breif: if something like a PCI parity error is detected by the
> hardware, then some arch-specific code runs; for example,
> arch/powerpc/platforms/pseries/eeh.c.
>
> This code notifies the PCI device driver (via generic callbacks in
> include/linux/pci.h) about the error. The device driver may ask the
> arch to have the pci device/bus/link/etc/ get reset, or not. If/when
> the PCI bus/link is back to normal, the PCI device driver is notified
> via callback, and resumes normal operation.
>
> If you have questions/suggestions, let me know, I've been maintaining
> this code, and am interested in seeing how well it can be adapted
> to a broader range of hardware.
>
> --linas
>
[-- Attachment #2: Type: text/html, Size: 3062 bytes --]
^ permalink raw reply
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