* Re: Thanks!!
From: Colin Leroy @ 2005-04-08 19:10 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <Pine.LNX.4.60.0504081039570.23066@bigrock.cs.ubc.ca>
On 08 Apr 2005 at 10h04, Dustin Lang wrote:
Hi,
> Which makes me wonder if 2.4 was running at 765 the whole time.
> Maybe because of this, 2.6 FEELS faster :)
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).
> Also, the backlight fine
> control is great! I'll play with sleep/resume this weekend and
> report my status.
You mentioned you have an nVidia GPU, so I guess you won't have much
success - nVidia cards are badly supported as they're being very secret
about their hardware.
--
Colin
^ permalink raw reply
* Re: [PATCH] Update fec_8xx to new platform device model
From: Tom Rini @ 2005-04-08 19:55 UTC (permalink / raw)
To: Pantelis Antoniou; +Cc: Jeff Garzik, linuxppc-embedded
In-Reply-To: <4254DD16.8000704@intracom.gr>
On Thu, Apr 07, 2005 at 10:11:18AM +0300, Pantelis Antoniou wrote:
> Hi all
>
> The following patch updates the in-tree fec_8xx driver
> to use the new platform device model.
Acked-by: Tom Rini <trini@kernel.crashing.org>
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Error enabling CONFIG_PPC4XX_DMA in lk2.4.27-pre3?
From: Sanjay Bajaj @ 2005-04-08 20:19 UTC (permalink / raw)
To: linuxppc-embedded
Hi! Gurus,
I tried to enable DMA in lk2.4.27-pre3 and it fails with the error =
attached to the end of the mail. On further debugging, I found that =
though CONFIG_PPC4XX_DMA is included in the .config but the =
asm/ppc4xx_dma.h includes CONFIG_PPC4XX_EDMA, which includes all the =
constants reported undeclared in the error message. Out of curiosity, =
changed .._EDMA to .._DMA in asm/ppc4xx_dma.h and still had errors. Any =
help is appreciated.
Thanks,
Sanjay
*****
ppc4xx_dma.c: In function `ppc4xx_enable_dma':
ppc4xx_dma.c:116: error: `DMA_CS0' undeclared (first use in this =
function)
ppc4xx_dma.c:116: error: (Each undeclared identifier is reported only =
once
ppc4xx_dma.c:116: error: for each function it appears in.)
ppc4xx_dma.c:116: error: `DMA_TS0' undeclared (first use in this =
function)
ppc4xx_dma.c:116: error: `DMA_CH0_ERR' undeclared (first use in this =
function)
ppc4xx_dma.c:117: error: `DMA_CS1' undeclared (first use in this =
function)
ppc4xx_dma.c:117: error: `DMA_TS1' undeclared (first use in this =
function)
ppc4xx_dma.c:117: error: `DMA_CH1_ERR' undeclared (first use in this =
function)
ppc4xx_dma.c:118: error: `DMA_CS2' undeclared (first use in this =
function)
ppc4xx_dma.c:118: error: `DMA_TS2' undeclared (first use in this =
function)
ppc4xx_dma.c:118: error: `DMA_CH2_ERR' undeclared (first use in this =
function)
ppc4xx_dma.c:119: error: `DMA_CS3' undeclared (first use in this =
function)
ppc4xx_dma.c:119: error: `DMA_TS3' undeclared (first use in this =
function)
ppc4xx_dma.c:119: error: `DMA_CH3_ERR' undeclared (first use in this =
function)
ppc4xx_dma.c: In function `ppc4xx_init_dma_channel':
ppc4xx_dma.c:624: error: `SET_DMA_CONTROL' undeclared (first use in this =
function)
ppc4xx_dma.c:629: warning: implicit declaration of function =
`GET_DMA_POLARITY'
ppc4xx_dma.c: In function `ppc4xx_get_channel_config':
ppc4xx_dma.c:726: warning: implicit declaration of function =
`GET_DMA_PRIORITY'
ppc4xx_dma.c:738: error: structure has no member named `ch_enable'
ppc4xx_dma.c:738: warning: implicit declaration of function `GET_DMA_CH'
ppc4xx_dma.c:739: error: structure has no member named `ece_enable'
ppc4xx_dma.c:740: error: structure has no member named `tcd_disable'
ppc4xx_dma.c: In function `ppc4xx_set_channel_priority':
ppc4xx_dma.c:763: error: `PRIORITY_LOW' undeclared (first use in this =
function)
ppc4xx_dma.c:764: error: `PRIORITY_MID_LOW' undeclared (first use in =
this function)
ppc4xx_dma.c:765: error: `PRIORITY_MID_HIGH' undeclared (first use in =
this function)
ppc4xx_dma.c:765: error: `PRIORITY_HIGH' undeclared (first use in this =
function)
ppc4xx_dma.c:772: warning: implicit declaration of function =
`SET_DMA_PRIORITY'
^ permalink raw reply
* Re: pte_update and 64-bit PTEs on PPC32?
From: Gabriel Paubert @ 2005-04-08 21:04 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, Paul Mackerras, linux-ppc-embedded list
In-Reply-To: <8497276598d775128a73efb06803a9ba@freescale.com>
On Fri, Apr 08, 2005 at 02:01:13PM -0500, Kumar Gala wrote:
> >Now that I read it carefully, I realize that I was wrong. But there
> >is still some room for optimization; the parameter that you don't
> >need is %3: simply replace lwzx %0,0,%3 by lwz %0,-4(%4).
>
> Doesn't help, realize that we are going to have "r3" with a pointer to
> pte. There is no way w/o an add to get to the next word for the lwarx.
I'd have to see the context. One less parameter to an asm block may
also make the compiler life easier.
>
> >But I'm not sure that OOO cannot play tricks on you, what guarantees
> > that the lwz is done after lwarx?
>
> I'm assuming since its a single asm block, gcc is not allowed to
> reorder it.
Not GCC, but the hardware. If loads can pass loads and lwarx has
more internal housekeeping overhead (obviously) than lwz. Especially
in the case of a processor with 2 LSU:
- lwarx issued to LSU1
- lwz issued LSU2 in the same clock cycle
I'm not sure at all that that you are guaranteed not to get
potentially stale data from the lwz on SMP. Loads are weekly
ordered in general wrt each other and lwarx is no exception
AFAIR. The fact that the two words are guaranteed to be in
the same cache line makes it extremely unlikely, but not
impossible.
Gabriel
^ permalink raw reply
* Re: cross-compiling under cygwin?
From: Dan Malek @ 2005-04-08 21:17 UTC (permalink / raw)
To: Howard, Marc; +Cc: Embedded PPC Linux list
In-Reply-To: <91B22F93A880FA48879475E134D6F0BEB9C02A@CA1EXCLV02.adcorp.kla-tencor.com>
On Apr 8, 2005, at 2:48 PM, Howard, Marc wrote:
> If I were Catholic I'd have to say a bunch of Hail Mary's for
> mentioning
> this but...
I've already said plenty. :-)
> Yes you can run NFS on Windows.
Oh geeze, no wonder the Pope died. He probably heard this!
(I think that sealed my fate .... )
> The other gotcha is that it can only export NTFS file systems,
> not FAT32.
So, how do I export a root file system with /dev nodes?
-- Dan
^ permalink raw reply
* Re: Thanks!!
From: Dan Malek @ 2005-04-08 21:21 UTC (permalink / raw)
To: Colin Leroy; +Cc: linuxppc-dev
In-Reply-To: <20050408211015.35350110@jack.colino.net>
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 :-)
-- Dan
^ permalink raw reply
* Re: pte_update and 64-bit PTEs on PPC32?
From: Dan Malek @ 2005-04-08 21:31 UTC (permalink / raw)
To: Gabriel Paubert
Cc: linuxppc-dev list, Paul Mackerras, linux-ppc-embedded list
In-Reply-To: <20050408210458.GA16672@iram.es>
On Apr 8, 2005, at 5:04 PM, Gabriel Paubert wrote:
> ...... Loads are weekly
^^^^^^
> ordered in general wrt each other and lwarx is no exception
> AFAIR.
Maybe that's my performance problem :-)
-- Dan
^ permalink raw reply
* Re: pte_update and 64-bit PTEs on PPC32?
From: Gabriel Paubert @ 2005-04-08 21:44 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev list, Paul Mackerras, linux-ppc-embedded list
In-Reply-To: <091e271750ba6ff4b07e0a9cb9f68dae@embeddededge.com>
On Fri, Apr 08, 2005 at 05:31:43PM -0400, Dan Malek wrote:
>
> On Apr 8, 2005, at 5:04 PM, Gabriel Paubert wrote:
>
> >...... Loads are weekly
> ^^^^^^
> >ordered in general wrt each other and lwarx is no exception
> >AFAIR.
>
> Maybe that's my performance problem :-)
Good catch ;-)
I believe it's my funniest typo to date.
Gabriel
^ permalink raw reply
* MPC8xx SCC for sync. HDLC on 2.4 kernel
From: Gigi PJ @ 2005-04-08 22:03 UTC (permalink / raw)
To: linuxppc-embedded
Jos, Ricardo,
is there any chance to share the code for high speed HDLC over MPC8260 ?
I'm not able to find any source apart the original one by Rodolfo Giometti
:(
Thanks
Regards
Gigi
^ permalink raw reply
* Re: [PATCH 2.6.12-rc2] ppc32: Fix building 32bit kernel for 64bit machines (Was: Re: linux 2.6.12-rc1-bk5 compilation error)
From: Jerome Glisse @ 2005-04-08 22:27 UTC (permalink / raw)
To: Tom Rini; +Cc: Andrew Morton, linuxppc-dev
In-Reply-To: <20050408153407.GZ3396@smtp.west.cox.net>
> OK, I think the following is a better workaround for that (based on
> arch/ppc/platforms/pmac_sleep.S):
>
> When building a ppc32 MULTIPLATFORM kernel for a 64bit pmac, we try and
> build certain files or use certain functions that make no sense in that
> context. This catches the last of these.
>
> Signed-off-by: Tom Rini <trini@kernel.crashing.org>
Works fine over here. Thx.
Jerome Glisse
^ permalink raw reply
* Re: 8xx v2.6 TLB problems and suggested workaround
From: Marcelo Tosatti @ 2005-04-08 11:07 UTC (permalink / raw)
To: Dan Malek; +Cc: Joakim Tjernlund, linuxppc-embedded
In-Reply-To: <19116173cb07648317c2a73a9c822c70@embeddededge.com>
Hi Dan,
On Thu, Apr 07, 2005 at 10:09:58PM -0400, Dan Malek wrote:
>
> On Apr 7, 2005, at 3:38 PM, Marcelo Tosatti wrote:
>
> >Would be nice to have someone from 8xx team look into this?
>
> I'll look into it and find some solution.
What do you envision as another solution?
We have two now:
1) _tlbie() on update_mmu_cache() surrounded by CONFIG_8xx #ifdef
Did you give up about it?
2) jump directly from DataTLBMiss to fault handler.
You seem to dislike it.
What else you think can be done?
> I suspect it is an interaction with the previous TLB miss and the behavior
> of the dcbst TLB look up. Perhaps, if we ensure the
> TLB entry is not valid at the time of the dcbst, it will work.
Note that the TLB entry is _not valid_ at the time of the dcbst:
BDI>rds 824
SPR 824 : 0x10011f05 268508933
BDI>rds 825
SPR 825 : 0x000001e0 480
BDI>rds 826
SPR 826 : 0x00001f00 7936
bit 18 (valid bit) of SPR 826 is not set.
So even with the TLB invalid, dcbst misbehaves.
> This is why the tlbie() I added as a hack a long time
> ago made the "problem" disappear. The other dcbxx
> instructions in the code work on already existing pages,
> while this one is a special case of a miss on a page
> that doesn't exist.
>
> Thanks.
>
> -- Dan
^ permalink raw reply
* Re: pte_update and 64-bit PTEs on PPC32?
From: Kumar Gala @ 2005-04-08 23:32 UTC (permalink / raw)
To: Gabriel Paubert
Cc: linuxppc-dev list, Paul Mackerras, linux-ppc-embedded list
In-Reply-To: <20050408210458.GA16672@iram.es>
On Apr 8, 2005, at 4:04 PM, Gabriel Paubert wrote:
> On Fri, Apr 08, 2005 at 02:01:13PM -0500, Kumar Gala wrote:
> > >Now that I read it carefully, I realize that I was wrong. But =
there
> > >is still some room for optimization; the parameter that you don't
> > >need is %3: simply replace lwzx %0,0,%3 by lwz %0,-4(%4).
> >
> > Doesn't help, realize that we are going to have "r3" with a pointer=20=
> to
> > pte.=A0 There is no way w/o an add to get to the next word for the=20=
> lwarx.
>
> I'd have to see the context. One less parameter to an asm block may
> also make the compiler life easier.
The only thing we could do is make the 4 a constant param and change=20
the lwarx to use it.. not sure if thats any better than what we are=20
doing.
> >
> > >But I'm not sure that OOO cannot play tricks on you, what =
guarantees
> > > that the lwz is done after lwarx?
> >
> > I'm assuming since its a single asm block, gcc is not allowed to
> > reorder it.
>
> Not GCC, but the hardware. If loads can pass loads and lwarx has
> more internal housekeeping overhead (obviously) than lwz. Especially
> in the case of a processor with 2 LSU:
> - lwarx issued to LSU1
> - lwz issued LSU2 in the same clock cycle
>
> I'm not sure at all that that you are guaranteed not to get
> potentially stale data from the lwz on SMP. Loads are weekly
> ordered in general wrt each other and lwarx is no exception
> AFAIR. The fact that the two words are guaranteed to be in
> the same cache line makes it extremely unlikely, but not
> impossible.
You are correct, I guess I really need an eieio in between the lwarx=20
and lwzx
- kumar=
^ permalink raw reply
* Re: [PATCH 2.6.12-rc2] ppc32: Fix building 32bit kernel for 64bit machines (Was: Re: linux 2.6.12-rc1-bk5 compilation error)
From: Benjamin Herrenschmidt @ 2005-04-08 23:47 UTC (permalink / raw)
To: Tom Rini; +Cc: Andrew Morton, linuxppc-dev list
In-Reply-To: <20050408153407.GZ3396@smtp.west.cox.net>
Go for it i
> When building a ppc32 MULTIPLATFORM kernel for a 64bit pmac, we try and
> build certain files or use certain functions that make no sense in that
> context. This catches the last of these.
>
> Signed-off-by: Tom Rini <trini@kernel.crashing.org>
>
> --- linux-2.6.orig/arch/ppc/platforms/pmac_cache.S
> +++ linux-2.6/arch/ppc/platforms/pmac_cache.S
> @@ -28,6 +28,9 @@
> */
>
> _GLOBAL(flush_disable_caches)
> +#ifndef CONFIG_6xx
> + blr
> +#else
> BEGIN_FTR_SECTION
> b flush_disable_745x
> END_FTR_SECTION_IFSET(CPU_FTR_SPEC7450)
> @@ -323,3 +326,4 @@ END_FTR_SECTION_IFSET(CPU_FTR_L3CR)
> mtmsr r11 /* restore DR and EE */
> isync
> blr
> +#endif /* CONFIG_6xx */
> --- linux-2.6.orig/arch/ppc/boot/simple/Makefile
> +++ linux-2.6/arch/ppc/boot/simple/Makefile
> @@ -123,10 +123,13 @@ zimageinitrd-$(pcore) := zImage.initrd
> end-$(pcore) := pcore
> cacheflag-$(pcore) := -include $(clear_L2_L3)
>
> +# Really only valid if CONFIG_6xx=y
> zimage-$(CONFIG_PPC_PREP) := zImage-PPLUS
> zimageinitrd-$(CONFIG_PPC_PREP) := zImage.initrd-PPLUS
> +ifeq ($(CONFIG_6xx),y)
> extra.o-$(CONFIG_PPC_PREP) := prepmap.o
> misc-$(CONFIG_PPC_PREP) += misc-prep.o mpc10x_memory.o
> +endif
> end-$(CONFIG_PPC_PREP) := prep
>
> end-$(CONFIG_SANDPOINT) := sandpoint
>
--
Benjamin Herrenschmidt <benh@kernel.crashing.org>
^ permalink raw reply
* Re: pte_update and 64-bit PTEs on PPC32?
From: Paul Mackerras @ 2005-04-09 0:32 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: linuxppc-dev list, linux-ppc-embedded list
In-Reply-To: <20050408184442.GA13709@iram.es>
Gabriel Paubert writes:
> But I'm not sure that OOO cannot play tricks on you, what guarantees
> that the lwz is done after lwarx?
Nothing, but it doesn't matter, because we have the
mm->page_table_lock, and anything that is changing the top 32 bits, or
anything in the bottom 32 bits other than the _PAGE_HASHPTE bit,
must also take the mm->page_table_lock. The low-level hash_page
routine can change the _PAGE_HASHPTE bit without having that lock,
which is why we need the atomic sequence.
Paul.
^ permalink raw reply
* Sound drivers for newer machines: need help
From: Benjamin Herrenschmidt @ 2005-04-09 0:31 UTC (permalink / raw)
To: debian-powerpc@lists.debian.org, linuxppc-dev list
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`
and
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.
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.
^ permalink raw reply
* Re: Sound drivers for newer machines: need help
From: Dustin Lang @ 2005-04-09 0:37 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, debian-powerpc@lists.debian.org
In-Reply-To: <1113006674.9568.414.camel@gaston>
Hi Ben,
> echo `cat /proc/device-tree/model`
PowerBook6,2
and the second command prints nothing.
Cheers,
dstn.
> 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`
>
> and
>
> 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.
>
> 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.
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: Sound drivers for newer machines: need help
From: Andreas Schwab @ 2005-04-09 0:53 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, debian-powerpc@lists.debian.org
In-Reply-To: <1113006674.9568.414.camel@gaston>
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> echo `cat /proc/device-tree/model`
PowerMac7,3
> for i in `find /proc/device-tree -name layout-id -print`; do echo $i && hexdump -n4 $i; done
/proc/device-tree/ht@0,f2000000/pci@1/mac-io@7/i2s@10000/i2s-a@0/sound/layout-id
0000000 0000 0024
0000004
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: Sound drivers for newer machines: need help
From: Benjamin Herrenschmidt @ 2005-04-09 0:54 UTC (permalink / raw)
To: Dustin Lang; +Cc: linuxppc-dev list, debian-powerpc@lists.debian.org
In-Reply-To: <Pine.LNX.4.60.0504081736520.26633@bigrock.cs.ubc.ca>
On Fri, 2005-04-08 at 17:37 -0700, Dustin Lang wrote:
> Hi Ben,
>
> > echo `cat /proc/device-tree/model`
> PowerBook6,2
>
> and the second command prints nothing.
Thanks.
Ben.
^ permalink raw reply
* Re: Sound drivers for newer machines: need help
From: Benjamin Herrenschmidt @ 2005-04-09 1:02 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev list, debian-powerpc@lists.debian.org
In-Reply-To: <jer7hkvkgx.fsf@sykes.suse.de>
On Sat, 2005-04-09 at 02:53 +0200, Andreas Schwab wrote:
> Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
>
> > echo `cat /proc/device-tree/model`
>
> PowerMac7,3
>
> > for i in `find /proc/device-tree -name layout-id -print`; do echo $i && hexdump -n4 $i; done
>
> /proc/device-tree/ht@0,f2000000/pci@1/mac-io@7/i2s@10000/i2s-a@0/sound/layout-id
> 0000000 0000 0024
> 0000004
Thanks.
Ben.
^ permalink raw reply
* Re: Best way to determine tb_ticks_per_jiffy inside todc_calibrate_decr()
From: Daniel Ann @ 2005-04-09 1:29 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-embedded
In-Reply-To: <4256CE41.1000404@mvista.com>
On Apr 9, 2005 3:32 AM, Mark A. Greer <mgreer@mvista.com> wrote:
> If you don't have an RTC, you shouldn't be using any todc_xxx routines.
Yeah, I figured this much :)
> There are several platform files that explicitly set tb_ticks_per_jiffy
> and tb_to_us. Did you try looking at those?
Actually that didnt occur to me since I thought it was related to the
supplied oscillator. Not knowing what their board is equiped with, I
couldnt trust their value any more than my estimated value. But
reading your next comment, it seems that it's related to processor as
well.
> Also, 33MHz does not sound right but then you don't say what processor
> you're using so who knows. You need to find the bus freq used by the
> cpu/system. Try looking for the freq of the processor's SYSCLK input.
> Then you probably have to divide that by 4 to get the frequency that the
> decrementer runs at. That's the value that you should use for the
> 'freq' variable in the example code you included in your email.
Okay guess I had all these things mixed up in head. What I should have
said is, source to PCI_SYNC_IN is 33MHz.
Anyway, following the MPC8245 hardware Spec pdf file, I was able to
find the peripheral logic/memory bus clock to be 99,000,000. Dividing
that by 4 like you said, gave me the value of 24,750,000. Which is
I've used it to get very real 1 second :)
BTW, why do you have to divide it by 4 ?
--
Daniel
^ permalink raw reply
* Re: Sound drivers for newer machines: need help
From: Tamas K Papp @ 2005-04-09 1:20 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, Apr 09, 2005 at 10:31:14AM +1000, 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`
>
> and
>
> 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.
% 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
Best,
Tamas
^ permalink raw reply
* Re: Sound drivers for newer machines: need help
From: Arnaud Delobelle @ 2005-04-09 1:45 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, debian-powerpc@lists.debian.org
In-Reply-To: <1113006674.9568.414.camel@gaston>
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`
PowerBook5,2
> for i in `find /proc/device-tree -name layout-id -print`; do echo $i && hexdump -n4 $i; done
Nothing
--
Arnaud
^ permalink raw reply
* Re: Sound drivers for newer machines: need help
From: Daniele Lacamera @ 2005-04-09 2:06 UTC (permalink / raw)
To: linuxppc-dev; +Cc: debian-powerpc@lists.debian.org
In-Reply-To: <1113006674.9568.414.camel@gaston>
On Saturday 09 April 2005 02:31, Benjamin Herrenschmidt wrote:
> echo `cat /proc/device-tree/model`
PowerBook6,8
(the newest 1.5Ghz 12" powerbook)
>
> 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
--
Daniele Lacamera
root{at}danielinux.net
^ permalink raw reply
* ATM driver for 8260 (linux 2.4.x) working!
From: Absolut Hunter @ 2005-04-09 2:13 UTC (permalink / raw)
To: linuxppc-embedded
I know this is a very old post, but was wondering if anyone still has the
ATM driver for the 8260 lying about...
I am attempting to get ATM up and running on an 8280, which should be the
same.
-R. McGuire
^ 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