Hi Uwe, Thanks for your support. Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx> writes: >> No strong feeling on that point. ISL12008 on which this driver is based >> has a similar logic. > Some time ago I already had the feeling that there is much "rank growth" > in the rtc drivers. I guess this is because maintenance of the rtc > subsystem isn't optimal and there are no guidelines (at least I'm not > aware of any) about detail questions. I had that feeling too when I pushed the ISL12057 driver. >> > None of the alarm functionality checks to see if there's actually an IRQ >> > - is that OK? I'd at least expect the alarm interrupt enable call to >> > check if the interrupt is wired up. >> >> I can add those check BUT I would like some directions in order to >> support the following use case too. >> >> Current three in-tree users of ISL12057 are NAS devices (Netgear >> ReadyNAS 102, 104 and 2120). All of them *do not have* the interrupt pin > I assume you don't have schematics of the devices, right? If so, do you > think it might be worth to try to get them from Netgear? Just to make > sure that there really is no pin connected to the SoC. I'll ask but I am skeptical: I already tested all the MPP of the SoC so unless I missed something, it's unlikely. >> of the RTC chip connected to an interrupt line of the SoC. Nonetheless, >> the IRQ line of the chip being connected to a PMIC on the board (TI >> TPS65251 [1] on ReadyNAS 102 and 104, I do not know for ReadyNAS > Looking over the manual it seems there is no way to let the PMIC forward > the irq either. > >> 2120). When the device is off and the alarm rings, the device gets >> powered on. AFAICT, the IRQ coming on the TPS65251 is not replicated on >> any line of the SoC. >> >> I think it's possible w/ some soldering to get somewhere where the RTC >> framework wants me to be and finish the alarm part to have it merged >> upstream but that's of limited interest if in-tree user cannot use it to >> fit their need, i.e. configure an alarm value and enable the associated >> interrupt which is routed externally, i.e. not visible by the SoC. > Do you need to enable the irq somewhere else (apart from in the RTC > device)? I guess not. This is the problem: I just need to enable the interrupt in the ISL12057 (flag in regs) but w/o dealing with SoC/system interrupt, i.e. w/o having a client->irq passed to the driver. In current RTC framework, alarm support requires a client->irq and a working interrupt line w/ the SoC. >> 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? yes. > Is it "only" that the alarm is missed? In practice, yes. But RTC framework does not support that. Or maybe there is some trick a maintainer would be aware of to support that scenario. Something involving: - returning some specific value in alarm_irq_enable handler - calling device_init_wakeup(dev, true); w/o having an IRQ line - extend workaround started in c9f5c7e7a84f and 4a649903f91232 and expose those via dt - ... > Irq polling probably isn't sensible? > > 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. Now, we're two to think that way ;-) > 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). Yes, but I wanted to handle the problem at hand before soldering IRQ#1 on my RN102 and add more feature. a+ -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
