* Re: J5000 LCD heartbeat [not found] ` <200503192233.26991.dmp@davidmpye.dyndns.org> @ 2005-03-19 23:19 ` Grant Grundler [not found] ` <20050319231911.GB21898@colo.lackof.org> 1 sibling, 0 replies; 17+ messages in thread From: Grant Grundler @ 2005-03-19 23:19 UTC (permalink / raw) To: David Pye; +Cc: debian-hppa, parisc-linux 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
[parent not found: <20050319231911.GB21898@colo.lackof.org>]
* [parisc-linux] Re: J5000 LCD heartbeat [not found] ` <20050319231911.GB21898@colo.lackof.org> @ 2005-03-20 19:18 ` David Pye 2005-03-20 19:18 ` David Pye [not found] ` <200503201918.31808.dmp@davidmpye.dyndns.org> 2 siblings, 0 replies; 17+ messages in thread From: David Pye @ 2005-03-20 19:18 UTC (permalink / raw) To: Grant Grundler; +Cc: parisc-linux, debian-hppa [-- 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: J5000 LCD heartbeat [not found] ` <20050319231911.GB21898@colo.lackof.org> 2005-03-20 19:18 ` [parisc-linux] " David Pye @ 2005-03-20 19:18 ` David Pye [not found] ` <200503201918.31808.dmp@davidmpye.dyndns.org> 2 siblings, 0 replies; 17+ messages in thread From: David Pye @ 2005-03-20 19:18 UTC (permalink / raw) To: Grant Grundler; +Cc: debian-hppa, parisc-linux [-- 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 --] ^ permalink raw reply [flat|nested] 17+ messages in thread
[parent not found: <200503201918.31808.dmp@davidmpye.dyndns.org>]
* Re: J5000 LCD heartbeat [not found] ` <200503201918.31808.dmp@davidmpye.dyndns.org> @ 2005-03-20 19:40 ` Thibaut VARENE 2005-03-20 19:40 ` [parisc-linux] " Thibaut VARENE [not found] ` <20050320204032.3ed40468@Tatooine.r3z0> 2 siblings, 0 replies; 17+ messages in thread From: Thibaut VARENE @ 2005-03-20 19:40 UTC (permalink / raw) To: dmp; +Cc: Grant Grundler, debian-hppa, parisc-linux 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* [parisc-linux] Re: J5000 LCD heartbeat [not found] ` <200503201918.31808.dmp@davidmpye.dyndns.org> 2005-03-20 19:40 ` Thibaut VARENE @ 2005-03-20 19:40 ` Thibaut VARENE [not found] ` <20050320204032.3ed40468@Tatooine.r3z0> 2 siblings, 0 replies; 17+ messages in thread From: Thibaut VARENE @ 2005-03-20 19:40 UTC (permalink / raw) To: dmp; +Cc: parisc-linux, debian-hppa 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
[parent not found: <20050320204032.3ed40468@Tatooine.r3z0>]
* Re: J5000 LCD heartbeat [not found] ` <20050320204032.3ed40468@Tatooine.r3z0> @ 2005-03-20 19:52 ` David Pye 2005-03-20 19:52 ` [parisc-linux] " David Pye [not found] ` <200503201952.31465.dmp@davidmpye.dyndns.org> 2 siblings, 0 replies; 17+ messages in thread From: David Pye @ 2005-03-20 19:52 UTC (permalink / raw) To: Thibaut VARENE; +Cc: Grant Grundler, debian-hppa, parisc-linux [-- 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 --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* [parisc-linux] Re: J5000 LCD heartbeat [not found] ` <20050320204032.3ed40468@Tatooine.r3z0> 2005-03-20 19:52 ` David Pye @ 2005-03-20 19:52 ` David Pye [not found] ` <200503201952.31465.dmp@davidmpye.dyndns.org> 2 siblings, 0 replies; 17+ messages in thread From: David Pye @ 2005-03-20 19:52 UTC (permalink / raw) To: Thibaut VARENE; +Cc: parisc-linux, debian-hppa [-- 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
[parent not found: <200503201952.31465.dmp@davidmpye.dyndns.org>]
* [parisc-linux] Re: J5000 LCD heartbeat [not found] ` <200503201952.31465.dmp@davidmpye.dyndns.org> @ 2005-03-20 20:03 ` Thibaut VARENE 2005-03-20 20:03 ` Thibaut VARENE [not found] ` <20050320210357.53534d01@Tatooine.r3z0> 2 siblings, 0 replies; 17+ messages in thread From: Thibaut VARENE @ 2005-03-20 20:03 UTC (permalink / raw) To: dmp; +Cc: parisc-linux, debian-hppa 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: J5000 LCD heartbeat [not found] ` <200503201952.31465.dmp@davidmpye.dyndns.org> 2005-03-20 20:03 ` Thibaut VARENE @ 2005-03-20 20:03 ` Thibaut VARENE [not found] ` <20050320210357.53534d01@Tatooine.r3z0> 2 siblings, 0 replies; 17+ messages in thread From: Thibaut VARENE @ 2005-03-20 20:03 UTC (permalink / raw) To: dmp; +Cc: Grant Grundler, debian-hppa, parisc-linux 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
[parent not found: <20050320210357.53534d01@Tatooine.r3z0>]
* Re: [parisc-linux] Re: J5000 LCD heartbeat [not found] ` <20050320210357.53534d01@Tatooine.r3z0> @ 2005-03-20 21:52 ` Stuart Brady [not found] ` <200503202257.31924.dmp@davidmpye.dyndns.org> 1 sibling, 0 replies; 17+ messages in thread From: Stuart Brady @ 2005-03-20 21:52 UTC (permalink / raw) To: parisc-linux, debian-hppa 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
[parent not found: <200503202257.31924.dmp@davidmpye.dyndns.org>]
* Re: J5000 LCD heartbeat [not found] ` <200503202257.31924.dmp@davidmpye.dyndns.org> @ 2005-03-20 23:17 ` David Pye 2005-03-20 23:17 ` [parisc-linux] " David Pye [not found] ` <200503202317.05481.dmp@davidmpye.dyndns.org> 2 siblings, 0 replies; 17+ messages in thread From: David Pye @ 2005-03-20 23:17 UTC (permalink / raw) To: debian-hppa; +Cc: parisc-linux [-- 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 --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* [parisc-linux] Re: J5000 LCD heartbeat [not found] ` <200503202257.31924.dmp@davidmpye.dyndns.org> 2005-03-20 23:17 ` David Pye @ 2005-03-20 23:17 ` David Pye [not found] ` <200503202317.05481.dmp@davidmpye.dyndns.org> 2 siblings, 0 replies; 17+ messages in thread From: David Pye @ 2005-03-20 23:17 UTC (permalink / raw) To: debian-hppa; +Cc: parisc-linux [-- 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
[parent not found: <200503202317.05481.dmp@davidmpye.dyndns.org>]
* [parisc-linux] Re: J5000 LCD heartbeat [not found] ` <200503202317.05481.dmp@davidmpye.dyndns.org> @ 2005-03-21 4:55 ` Stuart Brady 2005-03-21 7:19 ` Grant Grundler 0 siblings, 1 reply; 17+ messages in thread From: Stuart Brady @ 2005-03-21 4:55 UTC (permalink / raw) To: parisc-linux 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [parisc-linux] Re: J5000 LCD heartbeat 2005-03-21 4:55 ` Stuart Brady @ 2005-03-21 7:19 ` Grant Grundler 2005-03-21 13:43 ` [parisc-linux] " Stuart Brady 2005-03-22 6:29 ` [parisc-linux] " Grant Grundler 0 siblings, 2 replies; 17+ messages in thread From: Grant Grundler @ 2005-03-21 7:19 UTC (permalink / raw) To: parisc-linux 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [parisc-linux] J5000 LCD heartbeat 2005-03-21 7:19 ` Grant Grundler @ 2005-03-21 13:43 ` Stuart Brady 2005-03-21 18:42 ` Grant Grundler 2005-03-22 6:29 ` [parisc-linux] " Grant Grundler 1 sibling, 1 reply; 17+ messages in thread From: Stuart Brady @ 2005-03-21 13:43 UTC (permalink / raw) To: parisc-linux 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [parisc-linux] J5000 LCD heartbeat 2005-03-21 13:43 ` [parisc-linux] " Stuart Brady @ 2005-03-21 18:42 ` Grant Grundler 0 siblings, 0 replies; 17+ messages in thread From: Grant Grundler @ 2005-03-21 18:42 UTC (permalink / raw) To: parisc-linux 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [parisc-linux] Re: J5000 LCD heartbeat 2005-03-21 7:19 ` Grant Grundler 2005-03-21 13:43 ` [parisc-linux] " Stuart Brady @ 2005-03-22 6:29 ` Grant Grundler 1 sibling, 0 replies; 17+ messages in thread From: Grant Grundler @ 2005-03-22 6:29 UTC (permalink / raw) To: parisc-linux 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2005-03-22 6:29 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <200503191959.05972.dmp@davidmpye.dyndns.org>
[not found] ` <423C8881.6020702@tiscali.be>
[not found] ` <200503192233.26991.dmp@davidmpye.dyndns.org>
2005-03-19 23:19 ` J5000 LCD heartbeat Grant Grundler
[not found] ` <20050319231911.GB21898@colo.lackof.org>
2005-03-20 19:18 ` [parisc-linux] " David Pye
2005-03-20 19:18 ` David Pye
[not found] ` <200503201918.31808.dmp@davidmpye.dyndns.org>
2005-03-20 19:40 ` Thibaut VARENE
2005-03-20 19:40 ` [parisc-linux] " Thibaut VARENE
[not found] ` <20050320204032.3ed40468@Tatooine.r3z0>
2005-03-20 19:52 ` David Pye
2005-03-20 19:52 ` [parisc-linux] " David Pye
[not found] ` <200503201952.31465.dmp@davidmpye.dyndns.org>
2005-03-20 20:03 ` Thibaut VARENE
2005-03-20 20:03 ` Thibaut VARENE
[not found] ` <20050320210357.53534d01@Tatooine.r3z0>
2005-03-20 21:52 ` [parisc-linux] " Stuart Brady
[not found] ` <200503202257.31924.dmp@davidmpye.dyndns.org>
2005-03-20 23:17 ` David Pye
2005-03-20 23:17 ` [parisc-linux] " David Pye
[not found] ` <200503202317.05481.dmp@davidmpye.dyndns.org>
2005-03-21 4:55 ` Stuart Brady
2005-03-21 7:19 ` Grant Grundler
2005-03-21 13:43 ` [parisc-linux] " Stuart Brady
2005-03-21 18:42 ` Grant Grundler
2005-03-22 6:29 ` [parisc-linux] " Grant Grundler
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox