On Thursday 10 April 2008, Zhao Yakui wrote: > At the same time there is another question about this. > alm.enabled is related with AIE flag. When alarm is fired, the AIE flag > won't be cleared automatically. Are you sure? I thought that bug was fixed... alarms should be one-shot, not periodic. > If we want to set alarm again, should we > turn off the alarm firstly? As a rule, yes. We want to present a portable model for RTC alarms, which fire exactly once. The PC/AT model, with wildcarding for hh:mm:ss (and maybe MM:DD, allowed by ACPI extensions) is not very portable. (By the way, if someone wants to take rtc-cmos off my hands, I'd be glad to offload it ... my interest was just to try to get the PC platform to play in the same RTC space the other Linux platforms do!) > > That's a fair question. I don't think there's a good answer > > to that with today's infrastructure. Arguably, there should > > be the notion of a number of clients, each of which get told > > when the alarm they request fires. But today, there's only > > a single alarm, and a single client. > > Agree. Now there is only one alarm and current infrastruture can't > support more than two clients. I don't see how it could be claimed to support two clients. The second one clobbers the first ... Now, there *ARE* some RTCs that support multiple alarms. It's common in discrete I2C and SPI chips. But that's a capability that's not currently exposed by Linux; one of many, as noted in the current rtc(4) man page (dated 2006-11-26 in my copy). - Dave -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
