Hi all,
after looking at the ide driver (see previous post) and with references
to my good old A4000, I felt inspired to do this little hack.
It is in works-for-me state (iBook G4), but as the actual code is
shamelessly taken from the ide driver, I suppose it to work on all the
machines where the IDE driver can blink the led.
You can use it together with the ide blinking option, although the
heartbeat will look bumpy when the hd is active (don't worry, no heart
attack ;-)
There is further optimization possible on the ppc_md.heartbeat_count
and the cnt variables.
Oh, this patch is against vanilla 2.6.10.
Bye,
Joerg
@@ -240,6 +240,37 @@staticvolatileu32*sysctrl_regs;+#ifdef CONFIG_HEARTBEAT+staticstructadb_requestpmu_blink_on,pmu_blink_off;++/* adapted from arch_m68k */+staticvoidpb_heartbeat(void)+{+staticunsignedcnt=0,period=0,dist=0;++if(cnt==0||cnt==dist){+if(pmu_blink_on.complete)+pmu_request(&pmu_blink_on,NULL,4,0xee,4,0,1);+}elseif(cnt==7||cnt==dist+7){+if(pmu_blink_off.complete)+pmu_request(&pmu_blink_off,NULL,4,0xee,4,0,0);+}++if(++cnt>period){+cnt=0;+/* The hyperbolic function below modifies the heartbeat period+*lengthindependencyofthecurrent(5min)load.Itgoes+*throughthepointsf(0)=126,f(1)=86,f(5)=51,+*f(inf)->30.*/+period=((672<<FSHIFT)/(5*avenrun[0]+(7<<FSHIFT)))+30;+dist=period/4;+}++/* keep on going on ppc and account for HZ value */+ppc_md.heartbeat_count=HZ/100;+}+#endif /* CONFIG_HEARTBEAT */+void__initpmac_setup_arch(void){
@@ -333,6 +364,26 @@ppc_md.smp_ops=&psurge_smp_ops;#endif /* CONFIG_SMP */+#ifdef CONFIG_HEARTBEAT+/* Copied from the IDE blinking code */+if(pmu_get_model()==PMU_KEYLARGO_BASED){+structdevice_node*dt;+constchar*model;++if((dt=find_devices("device-tree"))!=NULL){+if((model=(constchar*)get_property(dt,"model",NULL))!=NULL){+if(!strncmp(model,"PowerBook",strlen("PowerBook"))||+!strncmp(model,"iBook",strlen("iBook"))){+pmu_blink_on.complete=1;+pmu_blink_off.complete=1;+ppc_md.heartbeat=pb_heartbeat;+ppc_md.heartbeat_count=1;+}+}+}+}+#endif /* CONFIG_HEARTBEAT */+pci_create_OF_bus_map();}---./arch/ppc/Kconfig.hb2005-01-1723:57:40.000000000+0100+++./arch/ppc/Kconfig2005-01-1800:09:14.000000000+0100
@@ -954,7 +954,7 @@configHEARTBEATbool"Use power LED as a heartbeat"-dependsonAPUS+dependsonAPUS||(PPC_PMAC&&ADB_PMU)helpUsethepower-onLEDonyourmachineasaloadmeter.Theexactbehaviorisplatform-dependent,butnormallytheflashfrequencyis
Hello!
Joerg Dorchain [Tue, Jan 18, 2005 at 10:42:16AM +0100]:
[heartbeat blink patch]
Well, wouldn't it make much more sense to write a
/dev/frontled to access it via userspace?
Then one could enable much more features like
- xmms plugins
- num-lock led
- network-traffic
- morse-codes
- glowing when typing
- ...
Nico
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2005-01-26 13:44:58
On Wed, 2005-01-26 at 12:35 +0100, Nico Schottelius wrote:
Hello!
Joerg Dorchain [Tue, Jan 18, 2005 at 10:42:16AM +0100]:
quoted
[heartbeat blink patch]
Well, wouldn't it make much more sense to write a
/dev/frontled to access it via userspace?
Then one could enable much more features like
- xmms plugins
- num-lock led
- network-traffic
- morse-codes
- glowing when typing
- ...
One can always control the led by sending PMU command directly
via /dev/adb :) Ok, that sort-of sucks, especially since the command is
only supported by some versions of the PMU. On the other hand, I dislike
cluttering /dev ... maybe I can find some better mecanism via sysfs...
Ben.
On Wed, Jan 26, 2005 at 12:35:54PM +0100, Nico Schottelius wrote:
Joerg Dorchain [Tue, Jan 18, 2005 at 10:42:16AM +0100]:
quoted
[heartbeat blink patch]
Well, wouldn't it make much more sense to write a
/dev/frontled to access it via userspace?
Well, only some hardware supports something that can be used as a HB
LED, so IMHO yet another (misc-) device node is not completely
justified.
Then again, the current implemenation was more or less directly copied
from arch/m68k and the pmac IDE driver, my only "own" contribution was
taking the different HZ value into account, and this only in the
simplest possible way.
The original idea behing the m68k HB was to see wether the machine has
crashed so far that even interrupts weren't working any more, which is
sometime very hard to distiguish from very high load (>20). Obiously,
this is best done in kernel space. The load-dependeant blinking
frequency just made it perfect for its original purpose ;-)
I still consider it more a development aid than a real user feature.
Bye,
Joerg
Good morning!
Benjamin Herrenschmidt [Thu, Jan 27, 2005 at 12:42:26AM +1100]:
One can always control the led by sending PMU command directly
via /dev/adb :) Ok, that sort-of sucks, especially since the command is
only supported by some versions of the PMU. On the other hand, I dislike
cluttering /dev ... maybe I can find some better mecanism via sysfs...
Well, if /dev would fit best, imho, as it represents a device.
And I don't think 'not having enough major/minor numbers' is an argument
not to implement something. We have udev (and before devfs), which
should clear the old problem.
Btw, howto control it via /dev/adb? Can you point me to a document
which explains that?
Joerg Dorchain [Thu, Jan 27, 2005 at 05:36:06PM +0100]:
On Wed, Jan 26, 2005 at 12:35:54PM +0100, Nico Schottelius wrote:
quoted
Joerg Dorchain [Tue, Jan 18, 2005 at 10:42:16AM +0100]:
quoted
[heartbeat blink patch]
Well, wouldn't it make much more sense to write a
/dev/frontled to access it via userspace?
Well, only some hardware supports something that can be used as a HB
LED, so IMHO yet another (misc-) device node is not completely
justified.
Imho it would be a nice feature, for testing and for fun.
If someone gives me some pointers on howto do that, I would try to
write a driver/interface to it.
Nico
--
Keep it simple & stupid, use what's available.
Please use pgp encryption: 8D0E 27A4 is my id.
http://nico.schotteli.us | http://linux.schottelius.org
Segher Boessenkool [Mon, Feb 14, 2005 at 02:14:40PM +0100]:
quoted
Btw, howto control it via /dev/adb? Can you point me to a document
which explains that?
Write a byte 0x06 followed by the PMU packet (all in one write());
read back the PMU reply (all in one read()).
What exactly does 0x06 mean? Flash led? Isn't there some kind of
"bright-led" "5V,12V,24V" settings available? I mean I want to be able
to change the brightness.
And what is the PMU packet? One Byte, two byte, value 0x2342?
Please point me to a FM about adb.
Nico
--
Keep it simple & stupid, use what's available.
Please use pgp encryption: 8D0E 27A4 is my id.
http://nico.schotteli.us | http://linux.schottelius.org
Segher Boessenkool [Fri, Feb 18, 2005 at 01:11:00PM +0100]:
quoted
quoted
quoted
Btw, howto control it via /dev/adb? Can you point me to a document
which explains that?
Write a byte 0x06 followed by the PMU packet (all in one write());
read back the PMU reply (all in one read()).
What exactly does 0x06 mean?
6 just means "send to PMU". It is a Linux thing, nothing to do
with the PMU itself.
thought something like that.
quoted
Flash led? Isn't there some kind of
"bright-led" "5V,12V,24V" settings available? I mean I want to be able
to change the brightness.
You can't change brightness on a LED. You can however make it blink,
say, a few hundred times per second, and change the duty-cycle.
Ok, that's what I meant.
quoted
Please point me to a FM about adb.
What is a FM? And it has nothing to do with ADB.
Well, it's the last part of RTFM, so I was asking
for the "fine manual", the documentation to ADB/PMU. So I can
lookup the commands I need for setting the led on/off.
Nico
Well, it's the last part of RTFM, so I was asking
for the "fine manual", the documentation to ADB/PMU. So I can
lookup the commands I need for setting the led on/off.
There is no manual. You can look at some Darwin source code,
I guess, or there is some code in Linux to do this as well, IIRC.
Segher
Hello everybody!
Thank you everybody for the help.
I found the correct bytes in the beginning of this thread and wrote
ibook-led (should work with powerbooks, too).
The program works as following:
ei nico # ./ibook-led
ibook-led <0,1,2> <delay>
0: switch led off
1: switch led on
2: switch led on for <delay> useconds
The source code can be found on http://linux.schottelius.org/hacks/.
Sincerly,
Nico
There is some minimal documentation available. Some Apple docs:
ADB-The Untold Story: Space Aliens Ate My Mouse
http://developer.apple.com/technotes/hw/hw_01.html
Inside Macintosh: Devices / Chapter 5 - ADB Manager
http://developer.apple.com/documentation/mac/Devices/Devices-203.html
These will tell you the basic design of ADB as well as the packet
formats and information about keyboards and mice.
Note that these document ADB in a generic sense, so nothing PMU
specific is in them. Apple has been very reluctant to document
the PMU and it's functions.
ADB has nothing to do with the PMU (well, the PMU emulates an ADB
device, sort of).
The Linux kernel multiplexes the /dev/adb device to also serve as
a channel to the PMU, though. This ugliness should be fixed, some
day...
Segher
On Fri, Feb 18, 2005 at 02:00:32PM +0100, Segher Boessenkool wrote:
There is no manual. You can look at some Darwin source code,
I guess, or there is some code in Linux to do this as well, IIRC.
There is some minimal documentation available. Some Apple docs:
ADB-The Untold Story: Space Aliens Ate My Mouse
http://developer.apple.com/technotes/hw/hw_01.html
Inside Macintosh: Devices / Chapter 5 - ADB Manager
http://developer.apple.com/documentation/mac/Devices/Devices-203.html
These will tell you the basic design of ADB as well as the packet
formats and information about keyboards and mice.
Note that these document ADB in a generic sense, so nothing PMU
specific is in them. Apple has been very reluctant to document
the PMU and it's functions.
Brad Boyer
flar@allandria.com
On Fri, Feb 18, 2005 at 07:10:42PM +0100, Segher Boessenkool wrote:
ADB has nothing to do with the PMU (well, the PMU emulates an ADB
device, sort of).
The Linux kernel multiplexes the /dev/adb device to also serve as
a channel to the PMU, though. This ugliness should be fixed, some
day...
The original PMU chip (in the Macintosh Portable) was used for
several purposes, including being the ADB transceiver. Most of
the revisions of the PMU that have shipped have still driven a
real ADB chain, although that has changed in more recent models.
The /dev/adb mess is a reflection of the mess that is the current
ADB subsystem in the kernel. You can write code in the kernel
that uses adb_request() to send non-adb PMU commands, and it
works due to the way it all works underneath. I was going to work
on it, but I got sidetracked with other issues that made it hard
to debug the various ADB drivers. If noone else gets to it, I
will eventually. I'm just not sure when I will have time.
Brad Boyer
flar@allandria.com