[BetterBatteryStats] Tungstwenty:
I did some more reading on how the kernel deals with interrupts and wakeups and here is some additional info. This might not be 100% accurate but I think the main idea stands.

When the drivers start and detect the devices, they register interrupt service routines (ISR) to handle the signals (interrupt requests - IRQs) sent by the hardware. Examples include battery state change, incoming wifi packet, key pressed, etc.

Each time an hw interrupt occurs, the corresponding ISR is executed. I'm guessing that if the device was in deep sleep, it is briefly waked up - just the CPU and the bare minimum devices, I guess - and the ISR will decide what to do. In some cases, it will read the state of the device it's controlling, do something really quick and return, sending back the cpu to deep sleep. In other cases, which seem to be the more usual, it acquires a KWL, schedules some work from the proper handler for the interruption, and returns.

For this 2nd case, the KWL that was acquired to make sure the secondary handler has time to do its stuff before the device sleeps again, appears to be the first one to be acquired after a wakeup, and therefore its "wc" value will increase by one. I'm not 100% sure of this because if this wakes up every driver *before* handling the ISR, there could be drivers that choose to lock some KWL by whatever reason. I very much doubt this but anyway.

Therefore, and despite the fact that I couldn't easily backtrack those KWL's wc's to the IRQ associated with the battery, by looking at the code, I did find some additional /proc entries that might be useful for this sort of stuff.

Querying /proc/interrupts I get something like this:

CPU0 CPU1
20: 116 0 s3c-uart
22: 3564 0 s3c-uart
98: 0 0 GIC s3c-pl330.0
99: 0 0 GIC s3c-pl330.1
100: 200 0 GIC s3c-pl330.2
106: 204398 0 GIC mct_tick0_irq
108: 0 0 GIC s3c2410-rtc alarm
112: 0 79884 GIC mct_tick1_irq
121: 0 0 GIC mct_comp_irq
122: 609 0 GIC s3c2440-i2c.0
123: 5330 0 GIC s3c2440-i2c.1
125: 7719 0 GIC s3c2440-i2c.3
127: 8248 0 GIC s3c2440-i2c.5
128: 1971 0 GIC s3c2440-i2c.6
129: 43 0 GIC s3c2440-i2c.7
134: 2378 0 GIC ehci_hcd:usb1
135: 134 0 GIC s3c-udc
139: 531 0 GIC mmc1
140: 0 0 GIC mmc2
141: 33909 0 GIC mmc0
142: 0 0 GIC s3c-csis0
144: 0 0 GIC s3c-csis1
148: 786 0 GIC s3c-fimc0
149: 461 0 GIC s3c-fimc1
150: 0 0 GIC s3c-fimc2
151: 0 0 GIC s3c-fimc3
152: 0 0 GIC s5p-jpeg
153: 128 0 GIC s5p-fimg2d
155: 0 0 GIC s5p-mixer
156: 0 0 GIC s5p-hdmi
158: 0 0 GIC s3c-mfc
160: 0 0 GIC samsung-rp
169: 294 0 GIC s5pv210-adc
182: 0 0 GIC mali_mmu_irq_handlers
183: 0 0 GIC mali_mmu_irq_handlers
184: 0 0 GIC mali_mmu_irq_handlers
185: 0 0 GIC mali_mmu_irq_handlers
186: 0 0 GIC mali_mmu_irq_handlers
187: 2855 0 GIC mali_core_irq_handlers
188: 2883 0 GIC mali_core_irq_handlers
189: 2942 0 GIC mali_core_irq_handlers
190: 2932 0 GIC mali_core_irq_handlers
191: 3279 0 GIC mali_core_irq_handlers
212: 0 0 COMBINER s5p-tmu interrupt
226: 0 0 COMBINER s5p-sysmmu.1
227: 0 0 COMBINER s5p-sysmmu.2
228: 0 0 COMBINER s5p-sysmmu.3
229: 0 0 COMBINER s5p-sysmmu.4
231: 0 0 COMBINER s5p-sysmmu.9
236: 0 0 COMBINER s5p-sysmmu.12
237: 0 0 COMBINER s5p-sysmmu.14
238: 0 0 COMBINER s5p-sysmmu.13
281: 2008 0 COMBINER s3cfb
353: 0 0 exynos-eint k3g
354: 0 0 exynos-eint proximity_int
356: 354 0 exynos-eint mxt224_ts
359: 0 0 exynos-eint max8997-irq
361: 176 0 exynos-eint hostwake
365: 6 0 exynos-eint
366: 3 0 exynos-eint phone_active
367: 0 0 exynos-eint pn544
368: 0 0 exynos-eint gpio_keys
369: 0 0 exynos-eint gpio_keys
370: 0 0 exynos-eint akm_int
371: 2 0 exynos-eint max17042 fuel alert
372: 1 0 exynos-eint Si4709
374: 0 0 exynos-eint bt host_wake
375: 6 0 exynos-eint gpio_keys
378: 0 0 exynos-eint sec_headset_detect
380: 0 0 exynos-eint s3c-sdhci.2
381: 2 0 exynos-eint gpio_keys
383: 1 0 exynos-eint hpd
389: 32 0 s5p_gpioint sec_touchkey
397: 0 0 s5p_gpioint sii9234
430: 0 0 max8997 chg-insert
431: 0 0 max8997 chg-remove
433: 0 0 max8997 chg-topoff
437: 0 0 max8997 rtc-alarm0
442: 0 0 max8997 muic-adc
444: 0 0 max8997 muic-adcerr
445: 0 0 max8997 muic-chgtype
449: 0 0 max8997 muic-vbvolt
IPI0: 0 0 Timer broadcast interrupts
IPI1: 42120 55187 Rescheduling interrupts
IPI2: 0 0 Function call interrupts
IPI3: 1522 1718 Single function call interrupts
IPI4: 0 0 CPU stop interrupts
IPI5: 0 0 CPU backtrace
LOC: 0 0 Local timer interrupts
Err: 0

Each of those entries (or at least most of them) corresponds to a physical device that interrupts the baby's sleep, or ongoing work.

By redirecting these to a file and after a while doing the same to a new one, comparing those one can have an idea of what kind of stuff generates activity, even if that doesn't show in KWLs.

I did it for a few seconds and noticed differences only on these ones: "mct_tick0_irq", "s3c2440-i2c.5", "ehci_hcd:usb1", "s3c-udc", "mmc0", "s5pv210-adc" and "hostwake".

The biggest increase was in "mct_tick0_irq", which looking at the sources is associated with CPU clock ticks.

One note BTW - these interrupt counts don't mean that the device was sleeping. The CPU clock ticks, for instance, is likely to be fired every x cycles, only when the CPU is running, in order to allow the preemptive multitasking mechanism to work.

Another interesting (and expected) thing is that when activating WiFi, a new IRQ entry shows up on the list and has its counts increasing. Disabling makes it go away.

Back to your particular case - could you monitor the evolution of /proc/interrupts over a certain period in order to check what might be happening (if it persists)?

The IRQ names are much more cryptic than the KWLs, but searching the sources at least the driver can be identified.