On Fri, Nov 07, 2014 at 08:58:43AM +0100, Uwe Kleine-König wrote: > On Fri, Nov 07, 2014 at 12:30:48AM +0100, Arnaud Ebalard wrote: > > Mark Brown <broonie@xxxxxxxxxx> writes: > > FWIW, we had a similar discussion a while ago, during driver inclusion: > > > > http://marc.info/?l=devicetree&m=138109313118504&w=2 > > > > Uwe, any idea? > What is the problem of a not-wired-up irq line? Does the rtc framework > need to change to allow setting an alarm without the irq line being > hooked up? Is it "only" that the alarm is missed? Irq polling probably > isn't sensible? The problem is that we've got operations like alarm_irq_enable() which probably shouldn't be reporting success if we don't have an interrupt line. Setting the alarm with no interrupt might still be useful but that at least ought to fail I'd expect. > > I assume it's not that unusual that an rtc irq doesn't trigger a system > irq, so having that supported nicely would be great. > > Looking through the rtc's datasheet, the device is a tad more > complicated than the current driver handles. There are two irq lines and > three functions that can be routed through these (alarm1, alarm2 and > clkout; not all combinations are possible). > > Best regards > Uwe > > -- > Pengutronix e.K. | Uwe Kleine-König | > Industrial Linux Solutions | http://www.pengutronix.de/ | >
Attachment:
signature.asc
Description: Digital signature
