Re: J5000 LCD heartbeat

Re: J5000 LCD heartbeat

[Grant Grundler]

On Sat, Mar 19, 2005 at 10:33:24PM +0000, David Pye wrote:
> The other thing is that the kernel version which is displayed on the lcd by 
> default is overwritten partly by a:
> 
> INI CC01 
> 
> It's not a huge issue for me, as I can overwrite it again by echo'ing my 
> message into /proc/pdc/lcd post boot.

This is the firmware showing the "Chassis Log" as emitted by the kernel.
Some platforms (e.g. A500/rp2470) use chassis logs to set the LED
properly.

> Is it possible to make the write to the display later in the boot process, so 
> it occurs after the INI CC01 is printed?

I would think it's possible.
You want to track down where the CC01 chassis_log is emitted then 
propose a better place to initialize LED display?

Another idea is the chassis log code might want to clear the LED
diplay when displaying a chassis log and then a few seconds later
refresh the LED display with the original contents or something.

> (Incidentally, the INI CC01 is only on the screen - /proc/pdc/led returns the 
> normal kernel version - I assume this is because the message was printed by 
> the hardware, itself?)

The firmware. IIRC, /proc/pdc/led just returns a cached value.

thanks,
grant


-- 
To UNSUBSCRIBE, email to debian-hppa-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

[parisc-linux] Re: J5000 LCD heartbeat

[David Pye]

[-- Attachment #1.1: Type: text/plain, Size: 2276 bytes --]

On Saturday 19 March 2005 23:19, Grant Grundler wrote:
> On Sat, Mar 19, 2005 at 10:33:24PM +0000, David Pye wrote:
> > The other thing is that the kernel version which is displayed on the lcd
> > by default is overwritten partly by a:
> >
> > INI CC01
> >
> > It's not a huge issue for me, as I can overwrite it again by echo'ing my
> > message into /proc/pdc/lcd post boot.
>
> This is the firmware showing the "Chassis Log" as emitted by the kernel.
> Some platforms (e.g. A500/rp2470) use chassis logs to set the LED
> properly.
>
> > Is it possible to make the write to the display later in the boot
> > process, so it occurs after the INI CC01 is printed?
>
> I would think it's possible.
> You want to track down where the CC01 chassis_log is emitted then
> propose a better place to initialize LED display?

I think I have an idea that it's related to CPU1 init, but I haven't confirmed 
this yet - depending on your feedback to the idea below, I won't bother 
tracing it down.

> Another idea is the chassis log code might want to clear the LED
> diplay when displaying a chassis log and then a few seconds later
> refresh the LED display with the original contents or something.

At the very least, I think it needs to clear the lcd display before it sends 
the chassis code to the PDC.  How does this sound:

Clear the lcd
Send the chassis code
set up a timer for 15 seconds, say, to restore the original display text

This requires a couple of changes to led.c so firmware.c can tell whether the 
machine has an LCD or not. (If it does, then do the above, otherwise just 
send the chassis code as before.)

If you agree that this is something useful, I will do some more hacking on it. 
Otherwise, I'll do the other option and arrange the the chassis log to be 
sent before the lcd has the initial text printed on it.

Another idea I had was this:

How about making the text scrollable? ie if the string is longer than the 
viewport, scroll it along at a reasonable rate.

I'm willing to have a play with this too, if people think it's something worth 
having.

Did you have any hints you could give me as to fix my very occasional 
heartbeat issue either? 

Cheers,

David

<snip>

> thanks,
> grant

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 169 bytes --]

_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: J5000 LCD heartbeat

[David Pye]

[-- Attachment #1: Type: text/plain, Size: 2276 bytes --]

On Saturday 19 March 2005 23:19, Grant Grundler wrote:
> On Sat, Mar 19, 2005 at 10:33:24PM +0000, David Pye wrote:
> > The other thing is that the kernel version which is displayed on the lcd
> > by default is overwritten partly by a:
> >
> > INI CC01
> >
> > It's not a huge issue for me, as I can overwrite it again by echo'ing my
> > message into /proc/pdc/lcd post boot.
>
> This is the firmware showing the "Chassis Log" as emitted by the kernel.
> Some platforms (e.g. A500/rp2470) use chassis logs to set the LED
> properly.
>
> > Is it possible to make the write to the display later in the boot
> > process, so it occurs after the INI CC01 is printed?
>
> I would think it's possible.
> You want to track down where the CC01 chassis_log is emitted then
> propose a better place to initialize LED display?

I think I have an idea that it's related to CPU1 init, but I haven't confirmed 
this yet - depending on your feedback to the idea below, I won't bother 
tracing it down.

> Another idea is the chassis log code might want to clear the LED
> diplay when displaying a chassis log and then a few seconds later
> refresh the LED display with the original contents or something.

At the very least, I think it needs to clear the lcd display before it sends 
the chassis code to the PDC.  How does this sound:

Clear the lcd
Send the chassis code
set up a timer for 15 seconds, say, to restore the original display text

This requires a couple of changes to led.c so firmware.c can tell whether the 
machine has an LCD or not. (If it does, then do the above, otherwise just 
send the chassis code as before.)

If you agree that this is something useful, I will do some more hacking on it. 
Otherwise, I'll do the other option and arrange the the chassis log to be 
sent before the lcd has the initial text printed on it.

Another idea I had was this:

How about making the text scrollable? ie if the string is longer than the 
viewport, scroll it along at a reasonable rate.

I'm willing to have a play with this too, if people think it's something worth 
having.

Did you have any hints you could give me as to fix my very occasional 
heartbeat issue either? 

Cheers,

David

<snip>

> thanks,
> grant

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: J5000 LCD heartbeat

[Thibaut VARENE]

On Sun, 20 Mar 2005 19:18:29 +0000
David Pye <dmp@davidmpye.dyndns.org> wrote:

> On Saturday 19 March 2005 23:19, Grant Grundler wrote:
> > On Sat, Mar 19, 2005 at 10:33:24PM +0000, David Pye wrote:
> >
> > > Is it possible to make the write to the display later in the boot
> > > process, so it occurs after the INI CC01 is printed?
> >
> > I would think it's possible.
> > You want to track down where the CC01 chassis_log is emitted then
> > propose a better place to initialize LED display?
> 
> I think I have an idea that it's related to CPU1 init, but I haven't
> confirmed this yet - depending on your feedback to the idea below, I
> won't bother tracing it down.

Don't bother. I have that kind of message left on my j5k LCD has well,
that's been there for ages, without problem.

> > Another idea is the chassis log code might want to clear the LED
> > diplay when displaying a chassis log and then a few seconds later
> > refresh the LED display with the original contents or something.
> 
> At the very least, I think it needs to clear the lcd display before it
> sends the chassis code to the PDC.  How does this sound:

If you think about the firmware code that drives the display of chassis
messages, it's firmware, changing how it works is pretty much not
possible at that point. If you think about the PDC Chassis driver, that
code doesn't work (read, "isn't activated") on j5k and other System Map
firmware machines, it only works on PDC PAT machines (eg high end
servers).

> Clear the lcd
> Send the chassis code
> set up a timer for 15 seconds, say, to restore the original display text
> 
> This requires a couple of changes to led.c so firmware.c can tell
> whether the machine has an LCD or not. (If it does, then do the above,
> otherwise just send the chassis code as before.)

AFAIK, it's not possible for the led.c driver to figure out whether the
firmware has sent anything to the LCD display.

> If you agree that this is something useful, I will do some more hacking
> on it. Otherwise, I'll do the other option and arrange the the chassis
> log to be sent before the lcd has the initial text printed on it.

I don't think this is either useful nor desirable. We want to have the
firmware messages going over whatever the led/lcd driver would have shown,
and going into such a pain for a corner case doesn't really seem worth it.

> Another idea I had was this:
> 
> How about making the text scrollable? ie if the string is longer than
> the viewport, scroll it along at a reasonable rate.

That has been considered and eventually ruled out. Remember we're in
kernel context, this is not meant to be eye candy etc. The pretty
formatting you suggest should be eventually a userland task, certainly not
a supplementary burden for the kernel.

At some point we looked after writing a complete driver for the LCD
display, but it happens that it's much more complicated than first
expected. For instance, accessing the other row of the LCD is almost
impossible. In any case, it would probably consume resource for nothing
really worth it.

> I'm willing to have a play with this too, if people think it's something
> worth having.

IMHO it's not.

> Did you have any hints you could give me as to fix my very occasional 
> heartbeat issue either? 

I recall that the LCD heartbeat is quite slow on my j5k as well, but
nothing really awful, afaicr.

HTH

Thibaut VARENE
The PA/Linux Team
http://www.pateam.org/


-- 
To UNSUBSCRIBE, email to debian-hppa-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

[parisc-linux] Re: J5000 LCD heartbeat

[Thibaut VARENE]

On Sun, 20 Mar 2005 19:18:29 +0000
David Pye <dmp@davidmpye.dyndns.org> wrote:

> On Saturday 19 March 2005 23:19, Grant Grundler wrote:
> > On Sat, Mar 19, 2005 at 10:33:24PM +0000, David Pye wrote:
> >
> > > Is it possible to make the write to the display later in the boot
> > > process, so it occurs after the INI CC01 is printed?
> >
> > I would think it's possible.
> > You want to track down where the CC01 chassis_log is emitted then
> > propose a better place to initialize LED display?
> 
> I think I have an idea that it's related to CPU1 init, but I haven't
> confirmed this yet - depending on your feedback to the idea below, I
> won't bother tracing it down.

Don't bother. I have that kind of message left on my j5k LCD has well,
that's been there for ages, without problem.

> > Another idea is the chassis log code might want to clear the LED
> > diplay when displaying a chassis log and then a few seconds later
> > refresh the LED display with the original contents or something.
> 
> At the very least, I think it needs to clear the lcd display before it
> sends the chassis code to the PDC.  How does this sound:

If you think about the firmware code that drives the display of chassis
messages, it's firmware, changing how it works is pretty much not
possible at that point. If you think about the PDC Chassis driver, that
code doesn't work (read, "isn't activated") on j5k and other System Map
firmware machines, it only works on PDC PAT machines (eg high end
servers).

> Clear the lcd
> Send the chassis code
> set up a timer for 15 seconds, say, to restore the original display text
> 
> This requires a couple of changes to led.c so firmware.c can tell
> whether the machine has an LCD or not. (If it does, then do the above,
> otherwise just send the chassis code as before.)

AFAIK, it's not possible for the led.c driver to figure out whether the
firmware has sent anything to the LCD display.

> If you agree that this is something useful, I will do some more hacking
> on it. Otherwise, I'll do the other option and arrange the the chassis
> log to be sent before the lcd has the initial text printed on it.

I don't think this is either useful nor desirable. We want to have the
firmware messages going over whatever the led/lcd driver would have shown,
and going into such a pain for a corner case doesn't really seem worth it.

> Another idea I had was this:
> 
> How about making the text scrollable? ie if the string is longer than
> the viewport, scroll it along at a reasonable rate.

That has been considered and eventually ruled out. Remember we're in
kernel context, this is not meant to be eye candy etc. The pretty
formatting you suggest should be eventually a userland task, certainly not
a supplementary burden for the kernel.

At some point we looked after writing a complete driver for the LCD
display, but it happens that it's much more complicated than first
expected. For instance, accessing the other row of the LCD is almost
impossible. In any case, it would probably consume resource for nothing
really worth it.

> I'm willing to have a play with this too, if people think it's something
> worth having.

IMHO it's not.

> Did you have any hints you could give me as to fix my very occasional 
> heartbeat issue either? 

I recall that the LCD heartbeat is quite slow on my j5k as well, but
nothing really awful, afaicr.

HTH

Thibaut VARENE
The PA/Linux Team
http://www.pateam.org/
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: J5000 LCD heartbeat

[David Pye]

[-- Attachment #1: Type: text/plain, Size: 3306 bytes --]

Hi, and thanks for your reply.

On Sunday 20 March 2005 19:40, you wrote:

> > I think I have an idea that it's related to CPU1 init, but I haven't
> > confirmed this yet - depending on your feedback to the idea below, I
> > won't bother tracing it down.
>
> Don't bother. I have that kind of message left on my j5k LCD has well,
> that's been there for ages, without problem.

Well, I'd like to see it gone myself, even though it doesn't do anything 
unpleasant. It is a little messy, at least having it mangled up with the 
Linux default text is.

If all it takes to prevent it is to make the lcd init happen slightly later in 
the boot process (ie after the chassis code was emitted), I'd have thought it 
would be an easy win.

> If you think about the firmware code that drives the display of chassis
> messages, it's firmware, changing how it works is pretty much not
> possible at that point. If you think about the PDC Chassis driver, that
> code doesn't work (read, "isn't activated") on j5k and other System Map
> firmware machines, it only works on PDC PAT machines (eg high end
> servers).

Yeah, true. So, if the PDC chassis driver isn't used on the j5k, how does the 
chassis message get sent from the kernel to the PDC?  I haven't worked that 
out yet.

> I don't think this is either useful nor desirable. We want to have the
> firmware messages going over whatever the led/lcd driver would have shown,
> and going into such a pain for a corner case doesn't really seem worth it.

At the very least, clearing the display first before the message is shown 
would have been helpful, imho.  

I'd personally like to have the firmware message displayed only for a limited 
time, though I can see a counter argument for this.  But not for having 
cleared the display first, though. (Whether this is possible depends on your 
answer as to how the PDC is told to display the message!)

> > Another idea I had was this:
> >
> > How about making the text scrollable? ie if the string is longer than
> > the viewport, scroll it along at a reasonable rate.
>
> That has been considered and eventually ruled out. Remember we're in
> kernel context, this is not meant to be eye candy etc. The pretty
> formatting you suggest should be eventually a userland task, certainly not
> a supplementary burden for the kernel.

Yep, agreed, that probably isn't a worthwhile thing to add. I was just 
thinking of other random ideas, that's all.

> > Did you have any hints you could give me as to fix my very occasional
> > heartbeat issue either?
>
> I recall that the LCD heartbeat is quite slow on my j5k as well, but
> nothing really awful, afaicr.

Well, here it's sufficiently slow to be utterly useless as a heartbeat, 
anyway. It usually flips state every 10-30 seconds, depending on how it 
feels. It certainly doesn't boot.

I realise the LCD functionality is something fairly minor, and that I'm being 
picky, but I'd be happy to invest some time to do some fine tuning.  The only 
two must-haves for me is to nail the INI CC01 message being displayed over 
the Linux kernel version display, and preferably to make my heart beat too ;)

Thanks,

David

> HTH
>
> Thibaut VARENE
> The PA/Linux Team
> http://www.pateam.org/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[parisc-linux] Re: J5000 LCD heartbeat

[David Pye]

[-- Attachment #1.1: Type: text/plain, Size: 3306 bytes --]

Hi, and thanks for your reply.

On Sunday 20 March 2005 19:40, you wrote:

> > I think I have an idea that it's related to CPU1 init, but I haven't
> > confirmed this yet - depending on your feedback to the idea below, I
> > won't bother tracing it down.
>
> Don't bother. I have that kind of message left on my j5k LCD has well,
> that's been there for ages, without problem.

Well, I'd like to see it gone myself, even though it doesn't do anything 
unpleasant. It is a little messy, at least having it mangled up with the 
Linux default text is.

If all it takes to prevent it is to make the lcd init happen slightly later in 
the boot process (ie after the chassis code was emitted), I'd have thought it 
would be an easy win.

> If you think about the firmware code that drives the display of chassis
> messages, it's firmware, changing how it works is pretty much not
> possible at that point. If you think about the PDC Chassis driver, that
> code doesn't work (read, "isn't activated") on j5k and other System Map
> firmware machines, it only works on PDC PAT machines (eg high end
> servers).

Yeah, true. So, if the PDC chassis driver isn't used on the j5k, how does the 
chassis message get sent from the kernel to the PDC?  I haven't worked that 
out yet.

> I don't think this is either useful nor desirable. We want to have the
> firmware messages going over whatever the led/lcd driver would have shown,
> and going into such a pain for a corner case doesn't really seem worth it.

At the very least, clearing the display first before the message is shown 
would have been helpful, imho.  

I'd personally like to have the firmware message displayed only for a limited 
time, though I can see a counter argument for this.  But not for having 
cleared the display first, though. (Whether this is possible depends on your 
answer as to how the PDC is told to display the message!)

> > Another idea I had was this:
> >
> > How about making the text scrollable? ie if the string is longer than
> > the viewport, scroll it along at a reasonable rate.
>
> That has been considered and eventually ruled out. Remember we're in
> kernel context, this is not meant to be eye candy etc. The pretty
> formatting you suggest should be eventually a userland task, certainly not
> a supplementary burden for the kernel.

Yep, agreed, that probably isn't a worthwhile thing to add. I was just 
thinking of other random ideas, that's all.

> > Did you have any hints you could give me as to fix my very occasional
> > heartbeat issue either?
>
> I recall that the LCD heartbeat is quite slow on my j5k as well, but
> nothing really awful, afaicr.

Well, here it's sufficiently slow to be utterly useless as a heartbeat, 
anyway. It usually flips state every 10-30 seconds, depending on how it 
feels. It certainly doesn't boot.

I realise the LCD functionality is something fairly minor, and that I'm being 
picky, but I'd be happy to invest some time to do some fine tuning.  The only 
two must-haves for me is to nail the INI CC01 message being displayed over 
the Linux kernel version display, and preferably to make my heart beat too ;)

Thanks,

David

> HTH
>
> Thibaut VARENE
> The PA/Linux Team
> http://www.pateam.org/

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 169 bytes --]

_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

[parisc-linux] Re: J5000 LCD heartbeat

[Thibaut VARENE]

On Sun, 20 Mar 2005 19:52:29 +0000
David Pye <dmp@davidmpye.dyndns.org> wrote:

> Hi, and thanks for your reply.
> 
> On Sunday 20 March 2005 19:40, you wrote:
> 
> > > I think I have an idea that it's related to CPU1 init, but I haven't
> > > confirmed this yet - depending on your feedback to the idea below, I
> > > won't bother tracing it down.
> >
> > Don't bother. I have that kind of message left on my j5k LCD has well,
> > that's been there for ages, without problem.
> 
> Well, I'd like to see it gone myself, even though it doesn't do anything
> unpleasant. It is a little messy, at least having it mangled up with the
> Linux default text is.
> 
> If all it takes to prevent it is to make the lcd init happen slightly
> later in the boot process (ie after the chassis code was emitted), I'd
> have thought it would be an easy win.

it's not that simple.
If you want to have it gone, add 
@reboot echo "" > /proc/pdc/lcd
in your root crontab :)

> > If you think about the firmware code that drives the display of
> > chassis messages, it's firmware, changing how it works is pretty much
> > not possible at that point. If you think about the PDC Chassis driver,
> > that code doesn't work (read, "isn't activated") on j5k and other
> > System Map firmware machines, it only works on PDC PAT machines (eg
> > high end servers).
> 
> Yeah, true. So, if the PDC chassis driver isn't used on the j5k, how
> does the chassis message get sent from the kernel to the PDC?  I haven't
> worked that out yet.

That message is a *firmware* one. It is send by the machine itself, not
by anything in the kernel (at least, directly).
 
> > I don't think this is either useful nor desirable. We want to have the
> > firmware messages going over whatever the led/lcd driver would have
> > shown, and going into such a pain for a corner case doesn't really
> > seem worth it.
> 
> At the very least, clearing the display first before the message is
> shown would have been helpful, imho.  

As i told you, this is not possible. The firmware doesn't know there's
already something on the display. And you don't want to rewrite the PDC
firmware, do you? :)

> I'd personally like to have the firmware message displayed only for a
> limited time, though I can see a counter argument for this.  But not for
> having cleared the display first, though. (Whether this is possible
> depends on your answer as to how the PDC is told to display the
> message!)

This is certainly not a good idea, but if you want that, add the following
to your root crontab:

*/10 * * * * echo "" > /proc/pdc/lcd

This will redraw the original message every 10mn.

> > > Did you have any hints you could give me as to fix my very
> > > occasional heartbeat issue either?
> >
> > I recall that the LCD heartbeat is quite slow on my j5k as well, but
> > nothing really awful, afaicr.
> 
> Well, here it's sufficiently slow to be utterly useless as a heartbeat, 
> anyway. It usually flips state every 10-30 seconds, depending on how it 
> feels. It certainly doesn't boot.
> 
> I realise the LCD functionality is something fairly minor, and that I'm
> being picky, but I'd be happy to invest some time to do some fine
> tuning.  The only two must-haves for me is to nail the INI CC01 message
> being displayed over the Linux kernel version display, and preferably to
> make my heart beat too ;)

The LED/LCD driver uses tasklets, which are quite CPU expensive. I think
this is one of the reason the heartbeat is slow. Though 30s seems alot to
me either.

HTH

Thibaut VARENE
The PA/Linux Team
http://www.pateam.org/
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: J5000 LCD heartbeat

[Thibaut VARENE]

On Sun, 20 Mar 2005 19:52:29 +0000
David Pye <dmp@davidmpye.dyndns.org> wrote:

> Hi, and thanks for your reply.
> 
> On Sunday 20 March 2005 19:40, you wrote:
> 
> > > I think I have an idea that it's related to CPU1 init, but I haven't
> > > confirmed this yet - depending on your feedback to the idea below, I
> > > won't bother tracing it down.
> >
> > Don't bother. I have that kind of message left on my j5k LCD has well,
> > that's been there for ages, without problem.
> 
> Well, I'd like to see it gone myself, even though it doesn't do anything
> unpleasant. It is a little messy, at least having it mangled up with the
> Linux default text is.
> 
> If all it takes to prevent it is to make the lcd init happen slightly
> later in the boot process (ie after the chassis code was emitted), I'd
> have thought it would be an easy win.

it's not that simple.
If you want to have it gone, add 
@reboot echo "" > /proc/pdc/lcd
in your root crontab :)

> > If you think about the firmware code that drives the display of
> > chassis messages, it's firmware, changing how it works is pretty much
> > not possible at that point. If you think about the PDC Chassis driver,
> > that code doesn't work (read, "isn't activated") on j5k and other
> > System Map firmware machines, it only works on PDC PAT machines (eg
> > high end servers).
> 
> Yeah, true. So, if the PDC chassis driver isn't used on the j5k, how
> does the chassis message get sent from the kernel to the PDC?  I haven't
> worked that out yet.

That message is a *firmware* one. It is send by the machine itself, not
by anything in the kernel (at least, directly).
 
> > I don't think this is either useful nor desirable. We want to have the
> > firmware messages going over whatever the led/lcd driver would have
> > shown, and going into such a pain for a corner case doesn't really
> > seem worth it.
> 
> At the very least, clearing the display first before the message is
> shown would have been helpful, imho.  

As i told you, this is not possible. The firmware doesn't know there's
already something on the display. And you don't want to rewrite the PDC
firmware, do you? :)

> I'd personally like to have the firmware message displayed only for a
> limited time, though I can see a counter argument for this.  But not for
> having cleared the display first, though. (Whether this is possible
> depends on your answer as to how the PDC is told to display the
> message!)

This is certainly not a good idea, but if you want that, add the following
to your root crontab:

*/10 * * * * echo "" > /proc/pdc/lcd

This will redraw the original message every 10mn.

> > > Did you have any hints you could give me as to fix my very
> > > occasional heartbeat issue either?
> >
> > I recall that the LCD heartbeat is quite slow on my j5k as well, but
> > nothing really awful, afaicr.
> 
> Well, here it's sufficiently slow to be utterly useless as a heartbeat, 
> anyway. It usually flips state every 10-30 seconds, depending on how it 
> feels. It certainly doesn't boot.
> 
> I realise the LCD functionality is something fairly minor, and that I'm
> being picky, but I'd be happy to invest some time to do some fine
> tuning.  The only two must-haves for me is to nail the INI CC01 message
> being displayed over the Linux kernel version display, and preferably to
> make my heart beat too ;)

The LED/LCD driver uses tasklets, which are quite CPU expensive. I think
this is one of the reason the heartbeat is slow. Though 30s seems alot to
me either.

HTH

Thibaut VARENE
The PA/Linux Team
http://www.pateam.org/


-- 
To UNSUBSCRIBE, email to debian-hppa-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Re: [parisc-linux] Re: J5000 LCD heartbeat

[Stuart Brady]

On Sun, Mar 20, 2005 at 09:03:57PM +0100, Thibaut VARENE wrote:
> it's not that simple.
> If you want to have it gone, add 
> @reboot echo "" > /proc/pdc/lcd
> in your root crontab :)

BTW, If anyone really wants scrolling, this script should do it.  It has
to use character 16 for spaces, which is a bit broken -- YMMV.

====================
#!/bin/bash

STR="Linux $(uname -r)   "
END=""

# Prevent the PDC from stripping leading spaces by
# using character 16 (octal 20) as a space...

STR="$(echo "$STR" | tr ' ' '\20')"

while(true); do
	echo "${STR}${END}" > /proc/pdc/lcd
	END="${END}${STR:0:1}"
	STR="${STR:1}"
	if [ -z "${STR:-}" ]; then
		STR="${END}"
		END=""
	fi
	sleep 0.25
done
====================

The character set is interesting:

1-8 for the disk/network/heartbeat symbols
32-127 are the standard ascii characters, except that:
   92 is a yen symbol
  126 is a left arrow
  127 is a right arrow
128-159 are unused
160-254 seem to be a mix of japanese, greek and accented roman letters
240 is an empty box
255 is a filled in square

Hope that helps,
-- 
Stuart Brady


-- 
To UNSUBSCRIBE, email to debian-hppa-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Re: J5000 LCD heartbeat

[David Pye]

[-- Attachment #1: Type: text/plain, Size: 1572 bytes --]

On Sunday 20 March 2005 22:57, David Pye wrote:

> Well, I've had a bit of a play with this, and think I have a feel of what
> causes it.
>
> The led_LCD_driver() fires each time the tasklet decides the led statuses
> should change, but each time it only updates at best one of the four LEDs.
>
> Every time it fires, it either updates one led, or it writes the command
> register, to avoid sleeping.   This means, that it requires eight fires of
> the tasklet (and eight times of it having decided an LCD state should flip)
> before the heartbeat will be written to.  It seems to be a rare occasion
> that these all line up (most of the time the heartbeat has pulsed back to
> its previous state before the LCD panel itself gets updated.

      
It appears my hunch was correct
  /* update the LCD/LEDs */
        if (currentleds != lastleds || led_type == LED_HASLCD) {
            led_func_ptr(currentleds);
            lastleds = currentleds;
        }

If I modify the conditional as above, so it fires the led_func_ptr each time 
the tasklet fires for LCD users (even if the leds haven't nominally changed) 
my heart beats!

Admittedly, it doesn't QUITE beat right, because of the rate the tasklet 
fires, and the rate at which the heart is supposed to beat.

I'm convinced another solution, like one of the ones I mentioned earlier, is a 
better idea, of course.

I now get:

a normal double beat, followed a single beat (repeats).

Which is better than no beats at all in my book!

Cheers,

David

> Cheers,
>
> David

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[parisc-linux] Re: J5000 LCD heartbeat

[David Pye]

[-- Attachment #1.1: Type: text/plain, Size: 1572 bytes --]

On Sunday 20 March 2005 22:57, David Pye wrote:

> Well, I've had a bit of a play with this, and think I have a feel of what
> causes it.
>
> The led_LCD_driver() fires each time the tasklet decides the led statuses
> should change, but each time it only updates at best one of the four LEDs.
>
> Every time it fires, it either updates one led, or it writes the command
> register, to avoid sleeping.   This means, that it requires eight fires of
> the tasklet (and eight times of it having decided an LCD state should flip)
> before the heartbeat will be written to.  It seems to be a rare occasion
> that these all line up (most of the time the heartbeat has pulsed back to
> its previous state before the LCD panel itself gets updated.

      
It appears my hunch was correct
  /* update the LCD/LEDs */
        if (currentleds != lastleds || led_type == LED_HASLCD) {
            led_func_ptr(currentleds);
            lastleds = currentleds;
        }

If I modify the conditional as above, so it fires the led_func_ptr each time 
the tasklet fires for LCD users (even if the leds haven't nominally changed) 
my heart beats!

Admittedly, it doesn't QUITE beat right, because of the rate the tasklet 
fires, and the rate at which the heart is supposed to beat.

I'm convinced another solution, like one of the ones I mentioned earlier, is a 
better idea, of course.

I now get:

a normal double beat, followed a single beat (repeats).

Which is better than no beats at all in my book!

Cheers,

David

> Cheers,
>
> David

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 169 bytes --]

_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

[parisc-linux] Re: J5000 LCD heartbeat

[Stuart Brady]

On Sun, Mar 20, 2005 at 11:17:03PM +0000, David Pye wrote:
> It appears my hunch was correct
>   /* update the LCD/LEDs */
>         if (currentleds != lastleds || led_type == LED_HASLCD) {
>             led_func_ptr(currentleds);
>             lastleds = currentleds;
>         }
> 
> If I modify the conditional as above, so it fires the led_func_ptr each time 
> the tasklet fires for LCD users (even if the leds haven't nominally changed) 
> my heart beats!

Ahh, fair enough.

Would it be better to test for "lcd_info.model == DISPLAY_MODEL_LCD"
rather than "led_type == LED_HASLCD"?

I wonder if it's a problem that an "LED" can be updated if it hasn't
changed (and even when there are others that actually need updating).
I think the included patch evens out the heartbeat a bit, but maybe I'm
imagining it...  Does it look okay?
-- 
Stuart Brady


Fix the virtual LEDs for LCD chassis displays.  Thanks to David Pye for
identifying the cause of the incorrect behaviour.

Signed-off-by: Stuart Brady <sdbrady@ntlworld.com>

Index: drivers/parisc/led.c
===================================================================
RCS file: /var/cvs/linux-2.6/drivers/parisc/led.c,v
retrieving revision 1.12
diff -u -r1.12 led.c
--- drivers/parisc/led.c	18 Mar 2005 13:17:10 -0000	1.12
+++ drivers/parisc/led.c	21 Mar 2005 04:09:25 -0000
@@ -297,41 +297,53 @@
 static void led_LCD_driver(unsigned char leds)
 {
 	static int last_index;	/* 0:heartbeat, 1:disk, 2:lan_in, 3:lan_out */
-	static int last_was_cmd;/* 0: CMD was written last, 1: DATA was last */
-	struct lcd_block *block_ptr;
-	int value;
-
-	switch (last_index) {
-	    case 0:	block_ptr = &lcd_info.heartbeat;
-			value = leds & LED_HEARTBEAT;
-			break;
-	    case 1:	block_ptr = &lcd_info.disk_io;
-			value = leds & LED_DISK_IO;
-			break;					
-	    case 2:	block_ptr = &lcd_info.lan_rcv;
-			value = leds & LED_LAN_RCV;
-			break;					
-	    case 3:	block_ptr = &lcd_info.lan_tx;
-			value = leds & LED_LAN_TX;
-			break;
-	    default:	/* should never happen: */
-			return;
-	}
-
-	if (last_was_cmd) {
-	    /* write the value to the LCD data port */
-    	    gsc_writeb( value ? block_ptr->on : block_ptr->off, LCD_DATA_REG );
+	static int last_was_cmd;/* 1: CMD was written last, 0: DATA was last */
+	static int first = 1;
+	static int last_leds, last_value;
+	static struct lcd_block *block_ptr;
+	int i, mask;
+
+	if (first) {
+		last_leds = ~leds;
+		first = 0;
+	}
+	
+	if (!last_was_cmd) {
+		for (i = 0; i < 4; i++) {
+			switch (last_index) {
+			    case 0:	mask = LED_HEARTBEAT;
+					block_ptr = &lcd_info.heartbeat;
+					break;
+			    case 1:	mask = LED_DISK_IO;
+					block_ptr = &lcd_info.disk_io;
+					break;
+			    case 2:	mask = LED_LAN_RCV;
+					block_ptr = &lcd_info.lan_rcv;
+					break;
+			    case 3:	mask = LED_LAN_TX;
+					block_ptr = &lcd_info.lan_tx;
+					break;
+			    default:	/* should never happen: */
+					return;
+			}
+
+			last_index++;
+			last_index %= 4;
+
+			if ((leds ^ last_leds) & mask) {
+				last_leds ^= mask; /* the bit has changed */
+				last_value = leds & mask;
+				/* write the command-byte to the LCD command register */
+		    		gsc_writeb( block_ptr->command, LCD_CMD_REG );
+				last_was_cmd = 1;
+				break;
+			}
+		}
 	} else {
-	    /* write the command-byte to the LCD command register */
-    	    gsc_writeb( block_ptr->command, LCD_CMD_REG );
+		/* write the value to the LCD data port */
+    		gsc_writeb( last_value ? block_ptr->on : block_ptr->off, LCD_DATA_REG );
+		last_was_cmd = 0;
 	}    
-	
-	/* now update the vars for the next interrupt iteration */ 
-	if (++last_was_cmd == 2) { /* switch between cmd & data */
-	    last_was_cmd = 0;
-	    if (++last_index == 4) 
-		last_index = 0;	 /* switch back to heartbeat index */
-	}
 }
 
 
@@ -481,7 +493,7 @@
 	}
 	
 	/* update the LCD/LEDs */
-	if (currentleds != lastleds) {
+	if (currentleds != lastleds || lcd_info.model == DISPLAY_MODEL_LCD) {
 	    led_func_ptr(currentleds);
 	    lastleds = currentleds;
 	}
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: J5000 LCD heartbeat

[Grant Grundler]

On Mon, Mar 21, 2005 at 04:55:06AM +0000, Stuart Brady wrote:
> I wonder if it's a problem that an "LED" can be updated if it hasn't
> changed (and even when there are others that actually need updating).
> I think the included patch evens out the heartbeat a bit, but maybe I'm
> imagining it...  Does it look okay?

Hrm...for LCD, can we program all 4 independently?
I've attached another patch based on ideas in yours that makes that
more explicit. Seems to work but I suppose locating a spec the LCD
panels would be the only way to know for sure.

On my j6k the change in LCD heartbeat was very faint.
LCD has a much slower/longer response time than an LED.
I've basically doubled the "time on" and now heart beat is easy to see.
But if someone knows the response time of the LCD panels, that
should make it obvious what the right values would be.

This difference got me wondering if we should have different tasklets
to handle LED vs LCD. If would be nice to deal with differences
in output device response times and a two step (cmd then data) update
process at a higher level than led_LCD_driver(). But I'm not volunteering
to rewrite LED/LCD driver and the patch below is Good Enough (IMHO).

Another possible improvement would be to move the code in the
"for" loop to a static inline function and just pass in all
the hard coded stuff. Wouldn't need any arrays and code is
probably compact enough that getting rid of the loop would
be a win. But someone would need to get CR16 cycle counts
before/after to prove it's better...again, more work than I'm
willing to put into it but something fun for someone to play with.

The following patch "Works for Me"(tm).
It's at risk for ignoring transitions until after the data phase is
taken care of and we send the next command. ie the gap between
when someone decides the LED should change and when it actually
changes entirely depends on how frequently led_LCD_driver gets called.

thanks,
grant

Signed-off-by: Grant Grundler <grundler@parisc-linux.org>

Index: drivers/parisc/led.c
===================================================================
RCS file: /var/cvs/linux-2.6/drivers/parisc/led.c,v
retrieving revision 1.12
diff -u -p -r1.12 led.c
--- drivers/parisc/led.c	18 Mar 2005 13:17:10 -0000	1.12
+++ drivers/parisc/led.c	21 Mar 2005 06:53:19 -0000
@@ -296,41 +296,40 @@ static void led_LASI_driver(unsigned cha
  */
 static void led_LCD_driver(unsigned char leds)
 {
-	static int last_index;	/* 0:heartbeat, 1:disk, 2:lan_in, 3:lan_out */
-	static int last_was_cmd;/* 0: CMD was written last, 1: DATA was last */
-	struct lcd_block *block_ptr;
-	int value;
-
-	switch (last_index) {
-	    case 0:	block_ptr = &lcd_info.heartbeat;
-			value = leds & LED_HEARTBEAT;
-			break;
-	    case 1:	block_ptr = &lcd_info.disk_io;
-			value = leds & LED_DISK_IO;
-			break;					
-	    case 2:	block_ptr = &lcd_info.lan_rcv;
-			value = leds & LED_LAN_RCV;
-			break;					
-	    case 3:	block_ptr = &lcd_info.lan_tx;
-			value = leds & LED_LAN_TX;
-			break;
-	    default:	/* should never happen: */
-			return;
-	}
-
-	if (last_was_cmd) {
-	    /* write the value to the LCD data port */
-    	    gsc_writeb( value ? block_ptr->on : block_ptr->off, LCD_DATA_REG );
-	} else {
-	    /* write the command-byte to the LCD command register */
-    	    gsc_writeb( block_ptr->command, LCD_CMD_REG );
-	}    
-	
-	/* now update the vars for the next interrupt iteration */ 
-	if (++last_was_cmd == 2) { /* switch between cmd & data */
-	    last_was_cmd = 0;
-	    if (++last_index == 4) 
-		last_index = 0;	 /* switch back to heartbeat index */
+	static unsigned char last_leds;
+
+	static unsigned char changed[4];
+	static unsigned char data[4];
+	static unsigned char mask[4] = { LED_HEARTBEAT, LED_DISK_IO,
+						LED_LAN_RCV, LED_LAN_TX };
+	static struct lcd_block * blockp[4] = {
+		&lcd_info.heartbeat,
+		&lcd_info.disk_io,
+		&lcd_info.lan_rcv,
+		&lcd_info.lan_tx
+	};
+
+	unsigned int i;
+
+	for (i = 0; i < 4; i++) {
+		if (changed[i]) {
+			/* finish LCD update with write to the LCD data port */
+			gsc_writeb( data[i], LCD_DATA_REG );
+			changed[i] = 0;
+		} else {
+			/* check if this "LED" changed since last time */
+			if ((leds ^ last_leds) & mask[i]) {
+				last_leds ^= mask[i];
+				data[i] = (leds & mask[i]) ?
+						blockp[i]->on :
+						blockp[i]->off;
+
+				changed[i] = 1;
+
+				/* start update by writing the cmd byte */
+		    		gsc_writeb(blockp[i]->command, LCD_CMD_REG);
+			}
+		}
 	}
 }
 
@@ -427,8 +426,8 @@ static __inline__ int led_get_diskio_act
     - optimizations
  */
 
-#define HEARTBEAT_LEN (HZ*6/100)
-#define HEARTBEAT_2ND_RANGE_START (HZ*22/100)
+#define HEARTBEAT_LEN (HZ*12/100)
+#define HEARTBEAT_2ND_RANGE_START (HZ*36/100)
 #define HEARTBEAT_2ND_RANGE_END   (HEARTBEAT_2ND_RANGE_START + HEARTBEAT_LEN)
 
 #define NORMALIZED_COUNT(count) (count/(HZ/100))
@@ -481,7 +480,7 @@ static void led_tasklet_func(unsigned lo
 	}
 	
 	/* update the LCD/LEDs */
-	if (currentleds != lastleds) {
+	if (currentleds != lastleds || lcd_info.model == DISPLAY_MODEL_LCD) {
 	    led_func_ptr(currentleds);
 	    lastleds = currentleds;
 	}
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] J5000 LCD heartbeat

[Stuart Brady]

On Mon, Mar 21, 2005 at 12:19:45AM -0700, Grant Grundler wrote:
> 
> Hrm...for LCD, can we program all 4 independently?

Surely not -- they share the same command/data registers, so the command
byte for one register could be written, with the data for another one.
If this isn't happening, that must be because only one LED is being
updated at a time, but I don't think we should rely on that.

> On my j6k the change in LCD heartbeat was very faint.
> LCD has a much slower/longer response time than an LED.
> I've basically doubled the "time on" and now heart beat is easy to see.
> But if someone knows the response time of the LCD panels, that
> should make it obvious what the right values would be.

The previous "time on" isn't great on real LEDs, either, but it looks
a bit more like a heartbeat.  I'll experiment with this, and see if I
can find a good compromise.

Thanks,
-- 
Stuart Brady
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] J5000 LCD heartbeat

[Grant Grundler]

On Mon, Mar 21, 2005 at 01:43:26PM +0000, Stuart Brady wrote:
> On Mon, Mar 21, 2005 at 12:19:45AM -0700, Grant Grundler wrote:
> > 
> > Hrm...for LCD, can we program all 4 independently?
> 
> Surely not -- they share the same command/data registers, so the command
> byte for one register could be written, with the data for another one.

*nod*
I totatlly overlooked the fact that the target of the writes was
one register pair:
	LCD display at f05d0008,f05d0000 registered


> If this isn't happening, that must be because only one LED is beingk
> updated at a time, but I don't think we should rely on that.

yeah. original scheme is on the right track.
I was not happy with the implementation but I think the
next version will address those (dealt with them offlist).

thanks,
grant
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: J5000 LCD heartbeat

[Grant Grundler]

On Mon, Mar 21, 2005 at 12:19:45AM -0700, Grant Grundler wrote:
> Hrm...for LCD, can we program all 4 independently?

ok...I'm having fun with this!

Here's another take that I *think* does it right.
LCD blinks nicely at least :^)

Stuart, how does this look to you?

(ignore the _LEN/_START values...make them whatever you want)

thanks,
grant



Index: drivers/parisc/led.c
===================================================================
RCS file: /var/cvs/linux-2.6/drivers/parisc/led.c,v
retrieving revision 1.12
diff -u -p -r1.12 led.c
--- drivers/parisc/led.c	18 Mar 2005 13:17:10 -0000	1.12
+++ drivers/parisc/led.c	22 Mar 2005 06:20:59 -0000
@@ -117,7 +117,9 @@ lcd_info __attribute__((aligned(8))) =
 
 
 /* ptr to LCD/LED-specific function */
-static void (*led_func_ptr) (unsigned char);
+static unsigned int (*led_func_ptr) (unsigned char);
+static unsigned int led_func_pending; /* more work? */
+static unsigned char led_func_last;	/* previous LED setting */
 
 #define LED_HASLCD 1
 #define LED_NOLCD  0
@@ -255,7 +257,7 @@ static int __init led_create_procfs(void
  */
 #define	LED_DATA	0x01	/* data to shift (0:on 1:off) */
 #define	LED_STROBE	0x02	/* strobe to clock data */
-static void led_ASP_driver(unsigned char leds)
+static unsigned int led_ASP_driver(unsigned char leds)
 {
 	int i;
 
@@ -267,6 +269,7 @@ static void led_ASP_driver(unsigned char
 		gsc_writeb( value | LED_STROBE,	 LED_DATA_REG );
 		leds <<= 1;
 	}
+	return 0;
 }
 
 
@@ -275,10 +278,11 @@ static void led_ASP_driver(unsigned char
    ** led_LASI_driver()
    ** 
  */
-static void led_LASI_driver(unsigned char leds)
+static unsigned int led_LASI_driver(unsigned char leds)
 {
 	leds = ~leds;
 	gsc_writeb( leds, LED_DATA_REG );
+	return 0;
 }
 
 
@@ -294,44 +298,75 @@ static void led_LASI_driver(unsigned cha
    ** TODO: check the value of "min_cmd_delay" against the value of HZ.
    **   
  */
-static void led_LCD_driver(unsigned char leds)
+static unsigned int led_LCD_driver(unsigned char leds)
 {
-	static int last_index;	/* 0:heartbeat, 1:disk, 2:lan_in, 3:lan_out */
-	static int last_was_cmd;/* 0: CMD was written last, 1: DATA was last */
-	struct lcd_block *block_ptr;
-	int value;
-
-	switch (last_index) {
-	    case 0:	block_ptr = &lcd_info.heartbeat;
-			value = leds & LED_HEARTBEAT;
-			break;
-	    case 1:	block_ptr = &lcd_info.disk_io;
-			value = leds & LED_DISK_IO;
-			break;					
-	    case 2:	block_ptr = &lcd_info.lan_rcv;
-			value = leds & LED_LAN_RCV;
-			break;					
-	    case 3:	block_ptr = &lcd_info.lan_tx;
-			value = leds & LED_LAN_TX;
-			break;
-	    default:	/* should never happen: */
-			return;
-	}
-
-	if (last_was_cmd) {
-	    /* write the value to the LCD data port */
-    	    gsc_writeb( value ? block_ptr->on : block_ptr->off, LCD_DATA_REG );
+#define LCD_BUFF_SIZE 16
+	static unsigned int data_tail, data_head;
+	static unsigned char data[LCD_BUFF_SIZE];
+	static unsigned char write_data;	/* flip-flop for cmd/data */
+
+	static unsigned char mask[4] = { LED_HEARTBEAT, LED_DISK_IO,
+						LED_LAN_RCV, LED_LAN_TX };
+	static struct lcd_block * blockp[4] = {
+		&lcd_info.heartbeat,
+		&lcd_info.disk_io,
+		&lcd_info.lan_rcv,
+		&lcd_info.lan_tx
+	};
+
+
+
+	if (led_func_pending) {
+		if (write_data) {
+			gsc_writeb( data[data_tail++], LCD_DATA_REG );
+			write_data=0;	/* do command next time */
+		} else {
+			gsc_writeb( data[data_tail++], LCD_CMD_REG );
+			write_data=1;	/* do data next time */
+		}
+		data_tail &= (LCD_BUFF_SIZE - 1);
+
+		/* avoid data[] overfull by not checking for updates
+		 * until after we've worked off pending updates.
+		 */
 	} else {
-	    /* write the command-byte to the LCD command register */
-    	    gsc_writeb( block_ptr->command, LCD_CMD_REG );
-	}    
-	
-	/* now update the vars for the next interrupt iteration */ 
-	if (++last_was_cmd == 2) { /* switch between cmd & data */
-	    last_was_cmd = 0;
-	    if (++last_index == 4) 
-		last_index = 0;	 /* switch back to heartbeat index */
+		unsigned int i;
+		unsigned char ledlast = led_func_last;
+		
+		/* update data and queue writes */
+		for (i = 0; i < 4; i++) {
+			/* check if this "LED" changed since last time */
+			if ((leds ^ ledlast) & mask[i]) {
+				ledlast ^= mask[i];
+
+				/* queue cmd/data pair */
+				data[data_head++] = blockp[i]->command;
+
+				/* Always write pairs and buffer is even size.
+				 * data_head &= (LCD_BUFF_SIZE - 1);
+				 */
+
+				data[data_head++] = (leds & mask[i]) ?
+						blockp[i]->on :
+						blockp[i]->off;
+				data_head &= (LCD_BUFF_SIZE - 1);
+			}
+		}
+
+		led_func_last = ledlast;
+
+		if (data_tail != data_head) {
+			/* start update by writing the cmd byte */
+		    	gsc_writeb(data[data_tail++], LCD_CMD_REG);
+
+			/* don't need to mask data_tail since buffer is
+			 * even sized and this is the first byte of a pair
+			 * 	data_tail &= (LCD_BUFF_SIZE - 1);
+			 */
+			write_data=1;
+		}
 	}
+	return (data_tail != data_head);
 }
 
 
@@ -427,15 +462,14 @@ static __inline__ int led_get_diskio_act
     - optimizations
  */
 
-#define HEARTBEAT_LEN (HZ*6/100)
-#define HEARTBEAT_2ND_RANGE_START (HZ*22/100)
+#define HEARTBEAT_LEN (HZ*12/100)
+#define HEARTBEAT_2ND_RANGE_START (HZ*36/100)
 #define HEARTBEAT_2ND_RANGE_END   (HEARTBEAT_2ND_RANGE_START + HEARTBEAT_LEN)
 
 #define NORMALIZED_COUNT(count) (count/(HZ/100))
 
 static void led_tasklet_func(unsigned long unused)
 {
-	static unsigned char lastleds;
 	unsigned char currentleds; /* stores current value of the LEDs */
 	static unsigned long count; /* static incremented value, not wrapped */
 	static unsigned long count_HZ; /* counter in range 0..HZ */
@@ -444,12 +478,17 @@ static void led_tasklet_func(unsigned lo
 	if (!led_func_ptr)
 	    return;
 
+	if (led_func_pending) {
+	    led_func_pending = led_func_ptr(led_func_last);
+	    return;
+	}
+
 	/* increment the local counters */
 	++count;
 	if (++count_HZ == HZ)
 	    count_HZ = 0;
 
-	currentleds = lastleds;
+	currentleds = led_func_last;
 
 	if (led_heartbeat)
 	{
@@ -480,10 +519,10 @@ static void led_tasklet_func(unsigned lo
 		currentleds = (count_HZ<=(HZ/2)) ? 0 : 0xff;
 	}
 	
-	/* update the LCD/LEDs */
-	if (currentleds != lastleds) {
-	    led_func_ptr(currentleds);
-	    lastleds = currentleds;
+	/* need to update the LCD/LEDs? */
+	if (currentleds != led_func_last) {
+	    led_func_pending = led_func_ptr(currentleds);
+	    led_func_last = currentleds;
 	}
 }
 
@@ -526,7 +565,7 @@ static int led_halt(struct notifier_bloc
 		lcd_print(txt);
 	else
 		if (led_func_ptr)
-			led_func_ptr(0xff); /* turn all LEDs ON */
+			(void) led_func_ptr(0xff); /* turn all LEDs ON */
 	
 	unregister_reboot_notifier(&led_notifier);
 	return NOTIFY_OK;
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux