[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: PowerBook 5,4 (the latest alu): cpufreq/sound/eth1394



Sebastian Henschel <debian@kodeaffe.de> wrote in message news:<203G2-3UO-23@gated-at.bofh.it>...
> sorry, but the list somehow does not like my attachments. you can
> download the tarball from
> http://kodeaffe.de/powerbook-54-device tree.tar.bz2 
> 
> ----- Forwarded message from Sebastian Henschel <debian@kodeaffe.de> -----
> 
> Date: Mon, 24 May 2004 10:02:29 +0200
> From: Sebastian Henschel <debian@kodeaffe.de>
> To: "debian-powerpc@lists.debian.org" <debian-powerpc@lists.debian.org>
> Subject: Re: PowerBook 5,4 (the latest alu): cpufreq/sound/eth1394
> X-Operating-System: Debian GNU/Linux
> User-Agent: Mutt/1.5.5.1+cvs20040105i
> 
> hello ben...
> 
> * Benjamin Herrenschmidt <benh@kernel.crashing.org> [2004-05-24 09:09 +0200
> ]:
> 
> CPUFREQ:
> 
> > > first, i thought: no problem, just pretend 5,4 to be like 5,2, but that
> > > did not work out. i modified pmac feature.c at two places so far:
> > > - line 2120ff to add an entry for 5,4
> > > - line 2624 to trigger the "bump clock speed hack"
> > 
> > DO NOT DO THAT !
> > 
> > I should add a FAT BOLD warning, it's dangerous to play blind games
> > with the clock chip. perdiod.
> 
> ok, i just thought that a younger sister of the same generation of
> powerbooks should behave similar to the older sister.
> 
> > I'll have to find out the proper values
> > for this model, you can help by sending me a tarball of
> > /proc/device-tree
> 
> attached.
> 
> 
> > > SOUND:
> > > for "snapper". so far, i found out, that this function is located in
> > > arch/ppc/syslib/prom.c. what is responsible for filling the property
> > > "compatible"? looking back at my cpufreq problem, do you think
> > > that the parsing of the openfirmware device tree somewhat fails or
> > > misbehaves? i feel like one important item has changed unexpectedly in 
>  the OF
> > > and subsequent property calls result in failures. i attached the file
> > > tree of /proc/device-tree if that could be useful.
>  
> > Or maybe you simply have a new sound chip which isn't "snapper" ? 
> 
> of course, that is possible. but why should apple replace the sound chip
> within the same generation? nevertheless, it seems quite compatible to
> snapper. i suggest you will see that in the devices-tree?
> 
> 
> thanks,
>  sebastian
> -- 
> ::: .O.
> ::: ..O
> ::: OOO
> ::: lynx -source http://www.kodeaffe.de/shensche.pub | gpg --import
> 
> 
> 
> 
> 
> ----- End forwarded message -----

was wondering how this was getting on and how as quoted earlier ("Or
maybe you simply have a new sound chip which isn't "snapper" ?") does
one know that the soundchip is "snapper"? Do you have to look in the
/proc device-tree and if so, where in particualr. I'm new to all this
actually hence my question.



Reply to: