* Problem with customized MPC5200 board(copy from lite5200 design)
From: Yeo Keewee @ 2005-04-10 4:51 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20050410020004.967A967B3E@ozlabs.org>
Hi,
Our hardware group had designed a mpc5200 board using the same design
as lite5200.
Currently, we are using bdi2000(icecube config) to attempt to access
the internal registers. By using the same procedure on lite5200, we
can access the registers but we always could not do it on our board.
Besides a hardware design flaw, is there any other init procedures
that are required to use bdi2000 on our custom board?
Did anyone face this kind of problem?
rgds
Yeo Kee Wee
^ permalink raw reply
* Re: 8xx v2.6 TLB problems and suggested workaround
From: Marcelo Tosatti @ 2005-04-09 22:37 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linuxppc-embedded
In-Reply-To: <BCEFJBPJCGFCNMMMIDBHKEGMCLAA.Joakim.Tjernlund@lumentis.se>
On Sat, Apr 09, 2005 at 09:03:54PM +0200, Joakim Tjernlund wrote:
> >
> > On Apr 8, 2005, at 7:07 AM, Marcelo Tosatti wrote:
> >
> > > 1) _tlbie() on update_mmu_cache() surrounded by CONFIG_8xx #ifdef
> > > Did you give up about it?
> >
> > I think a tlbia() of the vaddr should work here. No sense blowing
> > away the whole TLB cache for this.
>
> Umm, isn't it the other way around? tlbie flushes one TLB whereas tlbia flushes
> all TLBs.
Yep
> > > What else you think can be done?
> >
> > It would be interesting to change __flush_dcache_icache()
> > to use the 8xx SPR cache operations instead of the dcbst instruction.
>
> yes, but I think these operates on physical addresses which makes it a bit harder.
Other than the fact of userspace dcbst users.
> I still think this can be resolved in fault.c. Replace
> andis. r11, r10, 0x0200 /* If set, indicates store op */
> beq 2f
> in the DTLB Error handler with
> andis. r11, r10, 0x4800 /* If set, indicates invalid pte or protection violation */
> bne 2f
Why does the current code jump to page fault handler in case of store operation?
Out of curiosity, aren't there any other valid bit combinations for DSISR other
than 0x4800 which should allow a fastpath DataTLBError ?
I can't find DSISR settings in MPC860UM.pdf neither paper manual. AFAICS it
always refer to the PEM when talking about DSISR bit assignments.
I can't find section "7-15" as you mentioned in the other email.
> In fault.c you can check if both store and invalid is set simultaneously. If it is, clear
> the store flag and continue as usual.
One point is that by changing the in-kernel dcbst implementation userspace is
still vulnerable to the problem.
Now fixing the exception handler to deal with such boggosity as Joakim proposes is
complete - it handles userspace dcbst callers.
> > I wouldn't be surprised if it worked differently, but I'd not be
> > able to explain it :-)
> >
> > Thanks.
> >
> > -- Dan
> >
^ permalink raw reply
* Re: iBook G3 owners
From: Benjamin Herrenschmidt @ 2005-04-10 0:07 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev list
In-Reply-To: <1113090515.12012.65.camel@baythorne.infradead.org>
On Sun, 2005-04-10 at 00:48 +0100, David Woodhouse wrote:
> On Sun, 2005-04-10 at 09:37 +1000, Benjamin Herrenschmidt wrote:
> > Make sure you have the 2 cpufreq related patches though, there are
> > issues with CPU voltage possibly not correct on wakeup that can cause
> > similar problems.
>
> It was those I originally applied after cpufreq stopped working. Sleep
> hasn't worked reliably since then. I've built a kernel without any of
> the four patches, and if that works I'll test some more to work out
> precisely which one makes the difference.
Can you check that you have the very latest versions of these patches ?
I updated them a couple of time since I posted the message...
Ben.
^ permalink raw reply
* Re: iBook G3 owners
From: David Woodhouse @ 2005-04-09 23:48 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1113089830.9518.444.camel@gaston>
On Sun, 2005-04-10 at 09:37 +1000, Benjamin Herrenschmidt wrote:
> Make sure you have the 2 cpufreq related patches though, there are
> issues with CPU voltage possibly not correct on wakeup that can cause
> similar problems.
It was those I originally applied after cpufreq stopped working. Sleep
hasn't worked reliably since then. I've built a kernel without any of
the four patches, and if that works I'll test some more to work out
precisely which one makes the difference.
--
dwmw2
^ permalink raw reply
* Re: iBook G3 owners
From: Benjamin Herrenschmidt @ 2005-04-09 23:37 UTC (permalink / raw)
To: David Woodhouse
Cc: fedora-ppc, linuxppc-dev list, debian-powerpc@lists.debian.org
In-Reply-To: <1113064594.4636.28.camel@localhost.localdomain>
On Sat, 2005-04-09 at 17:36 +0100, David Woodhouse wrote:
> On Mon, 2005-04-04 at 16:06 +1000, Benjamin Herrenschmidt wrote:
> > There have been various reports of issues with sleep among others on
> > iBook G3 equiped with the 750FX processor. Also, the cpufreq code on
> > these so far didn't change the CPU voltage, which limited the actual
> > power saving at low frequency.
>
> Sleep hasn't worked properly on my PowerBook G4 since I applied your
> first pair of patches. The current behaviour seems to be that short
> periods of sleep appear to work OK, but a fairly random death happens
> after a longer sleep. Last time it was ohci_hcd complaining of an
> uninitialised spinlock.
>
> I'm half inclined to suspect RAM isn't being refreshed properly -- but
> most of the kernel text still seems to be there and it manages to oops
> and panic OK, so perhaps it's just that the dcache isn't correctly
> disabled, or isn't correctly flushed when we enable it again?
That kind of sleep is usually related to cache flush issues ... the
setup of RAM auto refresh isn't under kernel code control, it's entirely
done by the chipset when entering sleep state.
What is strange however is that none of these 2 patches have _any_
effect on your machine model. Can you confirm that's indeed the patches
you were talking about ?
ppc32-750-errata-fix.diff
ppc32-pmac-sleep-fix.diff
> I'll rebuild the Fedora kernel without any of the patches to eliminate
> the possibility that it's caused by some other change.
Make sure you have the 2 cpufreq related patches though, there are
issues with CPU voltage possibly not correct on wakeup that can cause
similar problems.
Ben.
^ permalink raw reply
* Re: Sound drivers for newer machines: need help
From: Benjamin Herrenschmidt @ 2005-04-09 23:38 UTC (permalink / raw)
To: Matthew T. Atkinson; +Cc: linuxppc-dev list, debian-powerpc@lists.debian.org
In-Reply-To: <1113081689.15872.4.camel@localhost>
On Sat, 2005-04-09 at 22:21 +0100, Matthew T. Atkinson wrote:
> 'ello,
>
> On Sat, 2005-04-09 at 10:31 +1000, Benjamin Herrenschmidt wrote:
> > echo `cat /proc/device-tree/model`
>
> PowerBook5,4
>
> > for i in `find /proc/device-tree -name layout-id -print`; do echo $i && hexdump -n4 $i; done
>
> /proc/device-tree/pci@f2000000/mac-io@17/i2s@10000/i2s-a@10000/sound/layout-id
> 0000000 0000 0033
> 0000004
>
> For your information, in case this helps...
>
> I am using ALSA and it appears to work except that only one program can
> access the sound hardware at a time (so is just like OSS :-)). If I am
> playing music in XMMS and then try to aplay a .wav file, it will hang
> until XMMS is closed for example.
If you set apps like xmms to actually use alsa output, you can have
mixing but for that, you have to enable the dmix plugin in your alsa
config. Look for infos about that on this list archive.
> The trick of altering the HZ of mp3 plug-in to remove the choppiness
> doesn't seem to work for all mp3 files (thought does for the vast
> majority).
>
> Many thanks for looking into this (and all the other work you do --
> sleep support, for example, has been *incredibly* useful)!
>
> best regards,
>
>
--
Benjamin Herrenschmidt <benh@kernel.crashing.org>
^ permalink raw reply
* Re: Sound drivers for newer machines: need help
From: Benjamin Herrenschmidt @ 2005-04-09 23:27 UTC (permalink / raw)
To: Martin-Éric Racine
Cc: linuxppc-dev list, debian-powerpc@lists.debian.org
In-Reply-To: <Pine.LNX.4.21.0504091309420.18767-100000@hal.pp.fishpool.fi>
On Sat, 2005-04-09 at 13:12 +0300, Martin-Éric Racine wrote:
> On Sat, 9 Apr 2005, Benjamin Herrenschmidt wrote:
>
> > If you have a newer machine, that is a machine released on or after
> > 2002, can you please send me the output of:
>
> [...]
>
> > I'm especially interested in the various models of G5 based machines. It
> > seems apple is having all sorts of very different sound HW setups on
> > those machines, and I'm trying to figure out exactly what is where based
> > on those infos and the darwin sources.
>
> Why limit this to new hardware, though? Why not modularize the pmac ALSA
> tree and completely fix all previous hardware variants as well?
Which is what I am doing, I just need some more infos about new hardware
because the HW setup done by Apple on those is fairly confusing.
> Btw, not sound-related but nonetheless a bug in the device tree:
>
> /proc/device-tree/psuedo-hid
>
> That wouldn't be a typo now, would it?
Might be but nobody cares about this one anyway.
Ben.
^ permalink raw reply
* Re: Sound drivers for newer machines: need help
From: Gabriel Paubert @ 2005-04-09 22:06 UTC (permalink / raw)
To: Martin-Éric Racine
Cc: debian-powerpc@lists.debian.org, linuxppc-dev list
In-Reply-To: <Pine.LNX.4.21.0504091309420.18767-100000@hal.pp.fishpool.fi>
On Sat, Apr 09, 2005 at 01:12:31PM +0300, Martin-Éric Racine wrote:
> On Sat, 9 Apr 2005, Benjamin Herrenschmidt wrote:
>
> > If you have a newer machine, that is a machine released on or after
> > 2002, can you please send me the output of:
>
> [...]
>
> > I'm especially interested in the various models of G5 based machines. It
> > seems apple is having all sorts of very different sound HW setups on
> > those machines, and I'm trying to figure out exactly what is where based
> > on those infos and the darwin sources.
>
> Why limit this to new hardware, though? Why not modularize the pmac ALSA
> tree and completely fix all previous hardware variants as well?
>
> Btw, not sound-related but nonetheless a bug in the device tree:
>
> /proc/device-tree/psuedo-hid
>
> That wouldn't be a typo now, would it?
It is a typo by Apple. It is the name in the firmware of my
PowerMacG4 466 (PowerMac3,4) under the OF prompt too
(psuedo-hid and psuedo-sound).
OTOH in my Pismo (PowerBook3,1) these same name are spelled
correctly, despite the fact that it is older (but it has had
at least one firmware upgrade while the G4 has none AFAIR).
/proc/device-tree keeps the names given by OF and only adds
a few of its own, "linux,phandle" mostly.
Gabriel
^ permalink raw reply
* Re: Sound drivers for newer machines: need help
From: Matthew T. Atkinson @ 2005-04-09 21:21 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, debian-powerpc@lists.debian.org
In-Reply-To: <1113006674.9568.414.camel@gaston>
'ello,
On Sat, 2005-04-09 at 10:31 +1000, Benjamin Herrenschmidt wrote:
> echo `cat /proc/device-tree/model`
PowerBook5,4
> for i in `find /proc/device-tree -name layout-id -print`; do echo $i && hexdump -n4 $i; done
/proc/device-tree/pci@f2000000/mac-io@17/i2s@10000/i2s-a@10000/sound/layout-id
0000000 0000 0033
0000004
For your information, in case this helps...
I am using ALSA and it appears to work except that only one program can
access the sound hardware at a time (so is just like OSS :-)). If I am
playing music in XMMS and then try to aplay a .wav file, it will hang
until XMMS is closed for example.
The trick of altering the HZ of mp3 plug-in to remove the choppiness
doesn't seem to work for all mp3 files (thought does for the vast
majority).
Many thanks for looking into this (and all the other work you do --
sleep support, for example, has been *incredibly* useful)!
best regards,
--
Matthew T. Atkinson <matthew@agrip.org.uk>
^ permalink raw reply
* RE: 8xx v2.6 TLB problems and suggested workaround
From: Joakim Tjernlund @ 2005-04-09 19:03 UTC (permalink / raw)
To: Dan Malek, Marcelo Tosatti; +Cc: linuxppc-embedded
In-Reply-To: <86e2fa4b5afe5bd8afc33ca47a7ab50c@embeddededge.com>
>
> On Apr 8, 2005, at 7:07 AM, Marcelo Tosatti wrote:
>
> > 1) _tlbie() on update_mmu_cache() surrounded by CONFIG_8xx #ifdef
> > Did you give up about it?
>
> I think a tlbia() of the vaddr should work here. No sense blowing
> away the whole TLB cache for this.
Umm, isn't it the other way around? tlbie flushes one TLB whereas tlbia flushes
all TLBs.
> > What else you think can be done?
>
> It would be interesting to change __flush_dcache_icache()
> to use the 8xx SPR cache operations instead of the dcbst instruction.
yes, but I think these operates on physical addresses which makes it a bit harder.
I still think this can be resolved in fault.c. Replace
andis. r11, r10, 0x0200 /* If set, indicates store op */
beq 2f
in the DTLB Error handler with
andis. r11, r10, 0x4800 /* If set, indicates invalid pte or protection violation */
bne 2f
In fault.c you can check if both store and invalid is set simultaneously. If it is, clear
the store flag and continue as usual.
> I wouldn't be surprised if it worked differently, but I'd not be
> able to explain it :-)
>
> Thanks.
>
> -- Dan
>
^ permalink raw reply
* Re: iBook G3 owners
From: David Woodhouse @ 2005-04-09 16:36 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: fedora-ppc, linuxppc-dev list, debian-powerpc@lists.debian.org
In-Reply-To: <1112594783.26086.22.camel@gaston>
On Mon, 2005-04-04 at 16:06 +1000, Benjamin Herrenschmidt wrote:
> There have been various reports of issues with sleep among others on
> iBook G3 equiped with the 750FX processor. Also, the cpufreq code on
> these so far didn't change the CPU voltage, which limited the actual
> power saving at low frequency.
Sleep hasn't worked properly on my PowerBook G4 since I applied your
first pair of patches. The current behaviour seems to be that short
periods of sleep appear to work OK, but a fairly random death happens
after a longer sleep. Last time it was ohci_hcd complaining of an
uninitialised spinlock.
I'm half inclined to suspect RAM isn't being refreshed properly -- but
most of the kernel text still seems to be there and it manages to oops
and panic OK, so perhaps it's just that the dcache isn't correctly
disabled, or isn't correctly flushed when we enable it again?
I'll rebuild the Fedora kernel without any of the patches to eliminate
the possibility that it's caused by some other change.
--
dwmw2
^ permalink raw reply
* [PATCH 2.6.11+] ppc32: Make the Powerstack II Pro4000 boot again
From: Leigh Brown @ 2005-04-09 11:33 UTC (permalink / raw)
To: Andrew Morton, Greg KH; +Cc: linuxppc-dev, Tom Rini
In-Reply-To: <20050408155717.GB3396@smtp.west.cox.net>
On Fri, 8 Apr 2005 07:54:31 -0700 Tom Rini wrote:
> On Fri, Apr 08, 2005 at 12:36:02PM +0100, Leigh Brown wrote:
> > Tom Rini said:
> > > On Wed, Apr 06, 2005 at 03:47:13AM +0200, Christian wrote:
> > >> Tom Rini wrote:
> > >> > Can either of you verify that say 2.6.11.6 w/ "noresidual" on the
> > >> > command-line works? Thanks.
> > >>
> > >> i booted vanilla 2.6.11.6 with noresidual (and "nopresidual" too, as
> > >> Sven sugggested), but the scsi errors did not went away :(
> > >>
> > >> on a side note, and perhaps totally unrelated: i always have
> > >> PROC_PREPRESIDUAL=y in my .config, but i never had /proc/residual as
> > >> promised from the help text.
> > >
> > > Odd. I thought that only happened if you had no residual data at all
> > > (which can happen on Powerstacks, esp if netbooting the kernel). But
> > > in that case the new code shouldn't be hit at all. Leigh?
> >
> > Hi, I'm back from my holidays, and have had a look at this. As I spent
> > lots of time understanding the horrendous mess that was
> > prep_pcibios_fixup(), I'd be loath to back out the changes I made
> > (especially as they work so well for me ;-) ).
> >
> > It turns out that prep_pib_init() is the culprit. Although it would
> > appear to be coded for the non-openpic case, it obviously doesn't work.
> > The old version of prep_pcibios_fixup() only called it if there is an
> > openpic on the machine. We can restore that behaviour with the
> > following patch:
> >
> > --- prep_pci.c.orig 2005-04-08 11:49:25.743718088 +0000
> > +++ prep_pci.c 2005-04-08 12:23:00.541422280 +0000
> > @@ -1245,8 +1245,13 @@
> > pci_write_config_byte(dev, PCI_INTERRUPT_LINE, dev->irq);
> > }
> >
> > - /* Setup the Winbond or Via PIB */
> > - prep_pib_init();
> > + /* Setup the Winbond or Via PIB - prep_pib_init() is coded for
> > + * the non-openpic case, but it breaks (at least) the Utah
> > + * (Powerstack II Pro4000), so only call it if we have an
> > + * openpic.
> > + */
> > + if (have_openpic)
> > + prep_pib_init();
> > }
> >
> > static void __init
> >
> > I've no idea even what machines would be affected by this, but it
> > fixes Sven's problem and restores the old behaviour, so that
> > can't be bad.
> >
> > I guess fixing prep_pib_init() would be the better solution but
> > I wouldn't know where to start. If this band-aid is good enough
> > I can submit a proper patch, if you like.
>
> If this works, I'd like to see this get into 2.6.12. Please re-send to
> akpm / this list. Assuming it's just the above:
> Acked-by: Tom Rini <trini@kernel.crashing.org>
On Fri, 8 Apr 2005 08:57:17 -0700, Tom Rini wrote:
> On Fri, Apr 08, 2005 at 05:51:40PM +0200, Christian wrote:
> > Tom Rini wrote:
> > >
> > > If this works, I'd like to see this get into 2.6.12. Please re-send to
> > > akpm / this list. Assuming it's just the above:
> > > Acked-by: Tom Rini <trini@kernel.crashing.org>
> >
> > yes! i just applied Leigh's patch (thanks!) to a pristine 2.6.11.6 and my
> > PReP here booted fine:
> > http://www.nerdbynature.de/bits/hal/2.6.11.6/leigh/
>
> Great. Leigh, can you also submit to gregkh for 2.6.11.7? Thanks.
This patch restores the original behaviour of prep_pcibios_fixup() to
only call prep_pib_init() on machines with an openpic. This allows
the Powerstack II Pro4000 to boot again.
Signed-off-by: Leigh Brown <leigh@solinno.co.uk>
--- linux-2.6/arch/ppc/platforms/prep_pci.c.orig 2005-04-08 16:55:53.336800298 +0200
+++ linux-2.6/arch/ppc/platforms/prep_pci.c 2005-04-08 16:56:01.818070165 +0200
@@ -1245,8 +1245,13 @@
pci_write_config_byte(dev, PCI_INTERRUPT_LINE, dev->irq);
}
- /* Setup the Winbond or Via PIB */
- prep_pib_init();
+ /* Setup the Winbond or Via PIB - prep_pib_init() is coded for
+ * the non-openpic case, but it breaks (at least) the Utah
+ * (Powerstack II Pro4000), so only call it if we have an
+ * openpic.
+ */
+ if (have_openpic)
+ prep_pib_init();
}
static void __init
^ permalink raw reply
* Re: Sound drivers for newer machines: need help
From: Brad Boyer @ 2005-04-09 16:23 UTC (permalink / raw)
To: Martin-?ric Racine; +Cc: linuxppc-dev list, debian-powerpc@lists.debian.org
In-Reply-To: <Pine.LNX.4.21.0504091309420.18767-100000@hal.pp.fishpool.fi>
On Sat, Apr 09, 2005 at 01:12:31PM +0300, Martin-?ric Racine wrote:
> Btw, not sound-related but nonetheless a bug in the device tree:
>
> /proc/device-tree/psuedo-hid
>
> That wouldn't be a typo now, would it?
If it is, I suspect it's in your version of the firmware. That isn't
added by the kernel. Here's mine:
dr-xr-xr-x 5 root root 0 Apr 9 09:17 /proc/device-tree/pseudo-hid/
And in OSX, ioreg lists a top level node of pseudo-hid as well. These
are PowerMac7,2 and PowerBook5,2 respectively.
Brad Boyer
flar@allandria.com
^ permalink raw reply
* Re: Sound drivers for newer machines: need help
From: Antonio-M. Corbi Bellot @ 2005-04-09 13:54 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, debian-powerpc@lists.debian.org
In-Reply-To: <1113006674.9568.414.camel@gaston>
El sáb, 09-04-2005 a las 10:31 +1000, Benjamin Herrenschmidt escribió:
> Hi !
>
> If you have a newer machine, that is a machine released on or after
> 2002, can you please send me the output of:
Hi Ben, this is a Powerbook 12" post feb-2005.
As you know sound does not work, the card seems to be recognized and the
module "snd_powermac" is loaded, sound-applications (rhythmbox, xmms,
bmp, totem, etc...) work but nothing can't be heard:
> echo `cat /proc/device-tree/model`
PowerBook6,8
> and
>
> for i in `find /proc/device-tree -name layout-id -print`; do echo $i && hexdump -n4 $i; done
/proc/device-tree/pci@f2000000/mac-io@17/i2s@0/i2s-a@10000/sound/layout-id
0000000 0000 0048
0000004
A. Corbi
^ permalink raw reply
* Re: Sound drivers for newer machines: need help
From: Helge Kreutzmann @ 2005-04-09 13:48 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, debian-powerpc@lists.debian.org
In-Reply-To: <1113006674.9568.414.camel@gaston>
[-- Attachment #1: Type: text/plain, Size: 855 bytes --]
Hello,
On Sat, Apr 09, 2005 at 10:31:14AM +1000, Benjamin Herrenschmidt wrote:
> If you have a newer machine, that is a machine released on or after
> 2002, can you please send me the output of:
An ibook from spring 2004 (PowerBook6,5)
> echo `cat /proc/device-tree/model`
thirtyto:~# echo `cat /proc/device-tree/model`
PowerBook6,5
> for i in `find /proc/device-tree -name layout-id -print`; do echo $i && hexdump -n4 $i; done
>
> If the later returns nothing, it's fine, just tell me.
Yep, returns nothing.
Hope this helps.
Helge
--
Dr. Helge Kreutzmann, Dipl.-Phys. Helge.Kreutzmann@itp.uni-hannover.de
gpg signed mail preferred
64bit GNU powered http://www.itp.uni-hannover.de/~kreutzm
Help keep free software "libre": http://www.freepatents.org/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Sound drivers for newer machines: need help
From: Cedric Duval @ 2005-04-09 13:10 UTC (permalink / raw)
To: linuxppc-dev, debian-powerpc@lists.debian.org
In-Reply-To: <1113006674.9568.414.camel@gaston>
Hi Ben,
Just in case you didn't note it before sending the Mini back to repair... :)
Benjamin Herrenschmidt wrote:
> echo `cat /proc/device-tree/model`
PowerMac10,1
> for i in `find /proc/device-tree -name layout-id -print`; do echo $i && hexdump -n4 $i; done
/proc/device-tree/pci@f2000000/mac-io@17/i2s@10000/i2s-a@10000/sound/layout-id
0000000 0000 003a
0000004
Regards,
--
Cédric
^ permalink raw reply
* Re: Sound drivers for newer machines: need help
From: Pablo Guerrero @ 2005-04-09 11:32 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, debian-powerpc@lists.debian.org
In-Reply-To: <1113006674.9568.414.camel@gaston>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Benjamin Herrenschmidt wrote:
> Hi !
>
> If you have a newer machine, that is a machine released on or after
> 2002, can you please send me the output of:
>
> echo `cat /proc/device-tree/model`
>
PowerBook6,5
> and
>
> for i in `find /proc/device-tree -name layout-id -print`; do echo $i && hexdump -n4 $i; done
>
Nothing.
> If the later returns nothing, it's fine, just tell me.
>
> I'm especially interested in the various models of G5 based machines. It
> seems apple is having all sorts of very different sound HW setups on
> those machines, and I'm trying to figure out exactly what is where based
> on those infos and the darwin sources.
>
> Ben.
>
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCV702bc/QOFfiAIYRAqlmAJ0aZT3nARj1XNYDt8JRe7UBBkgqqACfR45q
gMVXd9LzdnYLNZKWpDOKQdg=
=1oHh
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: Sound drivers for newer machines: need help
From: Martin-Éric Racine @ 2005-04-09 10:12 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, debian-powerpc@lists.debian.org
In-Reply-To: <1113006674.9568.414.camel@gaston>
On Sat, 9 Apr 2005, Benjamin Herrenschmidt wrote:
> If you have a newer machine, that is a machine released on or after
> 2002, can you please send me the output of:
[...]
> I'm especially interested in the various models of G5 based machines. It
> seems apple is having all sorts of very different sound HW setups on
> those machines, and I'm trying to figure out exactly what is where based
> on those infos and the darwin sources.
Why limit this to new hardware, though? Why not modularize the pmac ALSA
tree and completely fix all previous hardware variants as well?
Btw, not sound-related but nonetheless a bug in the device tree:
/proc/device-tree/psuedo-hid
That wouldn't be a typo now, would it?
--=20
Martin-=C9ric Racine
http://www.iki.fi/q-funk/
^ permalink raw reply
* Re: Sound drivers for newer machines: need help
From: Daniele Menozzi @ 2005-04-09 10:21 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, debian-powerpc@lists.debian.org
In-Reply-To: <1113006674.9568.414.camel@gaston>
On 10:31:14 09/Apr , Benjamin Herrenschmidt wrote:
> echo `cat /proc/device-tree/model`
PowerBook4,3
> for i in `find /proc/device-tree -name layout-id -print`; do echo $i && hexdump -n4 $i; done
nothing
> Ben.
Thank you
Menoz
--
Free Software Enthusiast
Debian Powered Linux User #332564
http://shine.homelinux.org
^ permalink raw reply
* Re: Sound drivers for newer machines: need help
From: Johannes Berg @ 2005-04-09 8:50 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, debian-powerpc@lists.debian.org
In-Reply-To: <1113006674.9568.414.camel@gaston>
[-- Attachment #1: Type: text/plain, Size: 342 bytes --]
Hi,
You probably know/have this already but for archive's sake:
> echo `cat /proc/device-tree/model`
PowerBook5,6
> for i in `find /proc/device-tree -name layout-id -print`; do echo $i && hexdump -n4 $i; done
/proc/device-tree/pci@f2000000/mac-io@17/i2s@0/i2s-a@10000/sound/layout-id
0000000 0000 0046
0000004
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* Re: Sound drivers for newer machines: need help
From: Djoume SALVETTI @ 2005-04-09 6:50 UTC (permalink / raw)
To: linuxppc-dev; +Cc: debian-powerpc
In-Reply-To: <1113006674.9568.414.camel@gaston>
Le samedi 04/09/05 Benjamin Herrenschmidt <benh@kernel.crashing.org> a écrit :
> echo `cat /proc/device-tree/model`
PowerBook6,4
> for i in `find /proc/device-tree -name layout-id -print`; do echo $i && hexdump -n4 $i; done
return nothing.
--
Djoumé SALVETTI
^ permalink raw reply
* Re: Thanks!!
From: Colin Leroy @ 2005-04-09 7:50 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <8dccd67e3fe7b5de7cb0f3b87a4a0bef@embeddededge.com>
On 08 Apr 2005 at 17h04, Dan Malek wrote:
Hi,
>
> On Apr 8, 2005, at 3:10 PM, Colin Leroy wrote:
>
> > 2.6 feels faster on desktop for other reasons too, such as a faster
> > scheduler (at least it was the case when I switched to 2.6, maybe
> > 2.4 got a faster one too).
>
> A faster scheduler? Now, that's one I've never heard :-)
See http://kerneltrap.org/node/342 and
http://www.hpl.hp.com/research/linux/kernel/o1.php if you want more
infos.
--
Colin
^ permalink raw reply
* Re: 8xx v2.6 TLB problems and suggested workaround
From: Dan Malek @ 2005-04-09 5:16 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: Joakim Tjernlund, linuxppc-embedded
In-Reply-To: <20050408110724.GG19449@logos.cnet>
On Apr 8, 2005, at 7:07 AM, Marcelo Tosatti wrote:
> 1) _tlbie() on update_mmu_cache() surrounded by CONFIG_8xx #ifdef
> Did you give up about it?
I think a tlbia() of the vaddr should work here. No sense blowing
away the whole TLB cache for this.
> What else you think can be done?
It would be interesting to change __flush_dcache_icache()
to use the 8xx SPR cache operations instead of the dcbst instruction.
I wouldn't be surprised if it worked differently, but I'd not be
able to explain it :-)
Thanks.
-- Dan
^ permalink raw reply
* Re: Thanks!!
From: Daniele Lacamera @ 2005-04-09 2:21 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <8dccd67e3fe7b5de7cb0f3b87a4a0bef@embeddededge.com>
On Friday 08 April 2005 23:21, Dan Malek wrote:
> A faster scheduler? Now, that's one I've never heard :-)
>
If interested take a look here :
http://josh.trancesoftware.com/linux/
--
Daniele Lacamera
root at danielinux.net
^ permalink raw reply
* 8260 ATM drivers / stack
From: Russell McGuire @ 2005-04-09 2:25 UTC (permalink / raw)
To: linuxppc-embedded
I saw a while back on this list that some users had posted some luck with
getting the ATM drivers to work on an 8260. I am currently working on
getting the ATM stack to work with an 8280 CPU. I think this was back in
like '02.
Was wondering if any of those people, or others with similar experience were
still participating on this mailing list. Would appreciate any pointers,
etc..
-R. RcGuire
^ 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