Hi,
Ditch the pmu_intr printk message and it may be fine. That's what messes
up the timing (or messes up the interrupt level for a brief period,
perhaps).
That seems likely. I suppose the option to delay the output does
something like queueing the messages and that prevents taking the
time to display them immediately. I thought printk was supposed
to detect when it was being called from an interrupt handler and
behave better for performance. Perhaps that doesn't work on m68k
for some reason?
It usually works fine. Maybe the PMU driver allows interrupts to happen
(in order to catch a timeout) so printk sometimes finds interrupts enablet
when it gets called?
(I should perhaps go and look at the code in question - ADB interrupt
handlers are tricky, and I've done my share to mess them up in the past.)
FWIW, I think the pmu intr 00 are one second timer interrupts from the PMU
- is that about the size of it, as judged from the number of interrupts
generated?
There certainly are a lot of them. Perhaps this revision of the chip
is different from the one the code was written against, as the header
says that the data payload in that message should be 0x80 rather than
0x00 as it is here. My guess is that the PB190 was the source of that
Maybe it's something else then. Someone will have to count them over a
couple of minutes to make sure :-)
Are these interrupts also generated when the PMU is busy sending key
events? Apple might have used an automagically generated interrupt from
the PMU just to get into the inthandler and start polling devices, who
knows? Never underestimate the creativity of Apple engineers ...
header, and it's actually using a PMU revision that is common with
some of the newer ppc based PowerBook models. We probably should
have 3 different PMU versions in the driver instead of just 2. It
looks like we treat V1 and V2 the same in the driver in the most
recent version anyway, so it may not be that useful of a distinction.
It might be worth checking if any of them support the PMU_GET_VERSION
request that is used by via-pmu.c for the ppc models. This could
tell us which ones Apple thought had significant differences.
While you're at it, please check whether they support the common battery
state response formats as well, and perhaps sleep messages? :-) I'd even
add support for m68k powerbooks to pmud if possible ...
Michael
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
