Re: [rtc-linux] Re: Can someone Ack and queue a patch for RTC subsytem?
On Fri, Dec 20, 2013 at 09:23:46PM +0100, Arnaud Ebalard wrote: > I do not even know to which specific component the irq line of the chip > is connected. You can take a look at [1] to see what's on the PCB; if > you have an idea about which one could be a good candidate (TPS65251?), > I can try and check with an ohmmeter which pin is connected to confirm > your guess. Then, I could look at the datasheet (if any) to see if it > can relay the interrupt to the SoC (if the component is supported by > Linux kernel). That's a PMIC which is what I'd expect if it's able to wake the device - if it's anything like the other TI PMICs it ought to be able to act as an interrupt controller. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [rtc-linux] Re: Can someone Ack and queue a patch for RTC subsytem?
On Fri, Dec 20, 2013 at 09:23:46PM +0100, Arnaud Ebalard wrote: I do not even know to which specific component the irq line of the chip is connected. You can take a look at [1] to see what's on the PCB; if you have an idea about which one could be a good candidate (TPS65251?), I can try and check with an ohmmeter which pin is connected to confirm your guess. Then, I could look at the datasheet (if any) to see if it can relay the interrupt to the SoC (if the component is supported by Linux kernel). That's a PMIC which is what I'd expect if it's able to wake the device - if it's anything like the other TI PMICs it ought to be able to act as an interrupt controller. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [rtc-linux] Re: Can someone Ack and queue a patch for RTC subsytem?
Hi, Mark Brown writes: > On Thu, Dec 19, 2013 at 11:17:44PM +0100, Arnaud Ebalard wrote: > >> All NETGEAR ReadyNAS 102, 104 and 2120 have an ISL 12057 RTC chip which >> is used as main RTC clock but can also provide alarm. But the alarm >> interrupt line of the chip is *not* connected to the SoC. It is >> connected to some power component and can be used to wake up the NAS >> when it is completely off and the alarm rings. > > Can the PMIC or whatever function as an interrupt controller and report > the interrupt on to the SoC? I do not even know to which specific component the irq line of the chip is connected. You can take a look at [1] to see what's on the PCB; if you have an idea about which one could be a good candidate (TPS65251?), I can try and check with an ohmmeter which pin is connected to confirm your guess. Then, I could look at the datasheet (if any) to see if it can relay the interrupt to the SoC (if the component is supported by Linux kernel). But, except if we can do what you propose, there are two problems at hand: 1) I cannot currently test the IRQ handler my changes would bring because it is not connected to the SoC on my platforms 2) even if I find a solution for 1), noone ever provided any directions on what should be required to make some program like rtc-test.c happy on my platforms (alarm support but no interrupt from the RTC). e.g. some refinements like the one introduced by c9f5c7e7a84f1b7 (rtc: rtc-spear: Provide flag for no support of UIE mode). I guess it should be fairly simple for someone w/ good knowledge of the RTC subsystem to tell what is needed. I do not have that knowledge and the documentation does not help. Regarding 1), I am starting to wonder if the best way out would not be for me to connect the interrupt line of the ISL12057 to one of the GPIO line currently connected to the LCD on my RN104 (after having disconnected the LCD) and change the function of the associated MPP on the SoC to make it an interrupt line. Could that work w/o additional hardware modification? What are my chances of killing the board? But this is pointless if I do not get any clear directions about 2). Cheers, a+ [1]: http://natisbad.org/NAS2/index.html#hw -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [rtc-linux] Re: Can someone Ack and queue a patch for RTC subsytem?
On Thu, Dec 19, 2013 at 11:17:44PM +0100, Arnaud Ebalard wrote: > All NETGEAR ReadyNAS 102, 104 and 2120 have an ISL 12057 RTC chip which > is used as main RTC clock but can also provide alarm. But the alarm > interrupt line of the chip is *not* connected to the SoC. It is > connected to some power component and can be used to wake up the NAS > when it is completely off and the alarm rings. Can the PMIC or whatever function as an interrupt controller and report the interrupt on to the SoC? signature.asc Description: Digital signature
Re: [rtc-linux] Re: Can someone Ack and queue a patch for RTC subsytem?
On Thu, Dec 19, 2013 at 11:17:44PM +0100, Arnaud Ebalard wrote: All NETGEAR ReadyNAS 102, 104 and 2120 have an ISL 12057 RTC chip which is used as main RTC clock but can also provide alarm. But the alarm interrupt line of the chip is *not* connected to the SoC. It is connected to some power component and can be used to wake up the NAS when it is completely off and the alarm rings. Can the PMIC or whatever function as an interrupt controller and report the interrupt on to the SoC? signature.asc Description: Digital signature
Re: [rtc-linux] Re: Can someone Ack and queue a patch for RTC subsytem?
Hi, Mark Brown broo...@kernel.org writes: On Thu, Dec 19, 2013 at 11:17:44PM +0100, Arnaud Ebalard wrote: All NETGEAR ReadyNAS 102, 104 and 2120 have an ISL 12057 RTC chip which is used as main RTC clock but can also provide alarm. But the alarm interrupt line of the chip is *not* connected to the SoC. It is connected to some power component and can be used to wake up the NAS when it is completely off and the alarm rings. Can the PMIC or whatever function as an interrupt controller and report the interrupt on to the SoC? I do not even know to which specific component the irq line of the chip is connected. You can take a look at [1] to see what's on the PCB; if you have an idea about which one could be a good candidate (TPS65251?), I can try and check with an ohmmeter which pin is connected to confirm your guess. Then, I could look at the datasheet (if any) to see if it can relay the interrupt to the SoC (if the component is supported by Linux kernel). But, except if we can do what you propose, there are two problems at hand: 1) I cannot currently test the IRQ handler my changes would bring because it is not connected to the SoC on my platforms 2) even if I find a solution for 1), noone ever provided any directions on what should be required to make some program like rtc-test.c happy on my platforms (alarm support but no interrupt from the RTC). e.g. some refinements like the one introduced by c9f5c7e7a84f1b7 (rtc: rtc-spear: Provide flag for no support of UIE mode). I guess it should be fairly simple for someone w/ good knowledge of the RTC subsystem to tell what is needed. I do not have that knowledge and the documentation does not help. Regarding 1), I am starting to wonder if the best way out would not be for me to connect the interrupt line of the ISL12057 to one of the GPIO line currently connected to the LCD on my RN104 (after having disconnected the LCD) and change the function of the associated MPP on the SoC to make it an interrupt line. Could that work w/o additional hardware modification? What are my chances of killing the board? But this is pointless if I do not get any clear directions about 2). Cheers, a+ [1]: http://natisbad.org/NAS2/index.html#hw -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [rtc-linux] Re: Can someone Ack and queue a patch for RTC subsytem?
Hi, Alessandro Zummo writes: > On Thu, 19 Dec 2013 11:46:24 -0500 > Jason Cooper wrote: > >> In the long term, should we seek out a co-maintainer for drivers/rtc? >> Can anyone get a hold of Alessandro to get his opinion on this? > > I'd surely appreciate if someone can take some time to give > a look to the patches. Most of them go thru subsystem's tree and, as > far as I can see, I saw very relevant comments and fixes in all those > years. While I am at it, I wonder if you can give me some directions on the following to add back alarm support to the ISL12057 on the specific hardware I have. All NETGEAR ReadyNAS 102, 104 and 2120 have an ISL 12057 RTC chip which is used as main RTC clock but can also provide alarm. But the alarm interrupt line of the chip is *not* connected to the SoC. It is connected to some power component and can be used to wake up the NAS when it is completely off and the alarm rings. To me this kind of setup seems logical but it does not seem to be directly supported by current RTC logic: - first, I cannot test an interrupt handler implementation I had written as the SoC will never receive any interrupt. This limits my ability to provide one to the driver. - what can/should be done in my .dts file to indicate that the device does not have any IRQ line connected (and hence no interrupt handler) to the SoC but still supports an alarm. As a side note, the implementation I had was a working one on my hardware (i.e. was able to wake up the device at a given time) but I had to remove alarm code to get a basic driver accepted upstream. To be honest, I tried and understand what RTC subsystem expects from documentation and code w/o success. Any help appreciated on that topic. Cheers, a+ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [rtc-linux] Re: Can someone Ack and queue a patch for RTC subsytem?
On Thu, 19 Dec 2013 11:46:24 -0500 Jason Cooper wrote: > In the long term, should we seek out a co-maintainer for drivers/rtc? > Can anyone get a hold of Alessandro to get his opinion on this? I'd surely appreciate if someone can take some time to give a look to the patches. Most of them go thru subsystem's tree and, as far as I can see, I saw very relevant comments and fixes in all those years. I'd love to devote more time to Linux but I'd need to find someone that hires me just to do that the whole day :) -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [rtc-linux] Re: Can someone Ack and queue a patch for RTC subsytem?
On Thu, 19 Dec 2013 11:46:24 -0500 Jason Cooper ja...@lakedaemon.net wrote: In the long term, should we seek out a co-maintainer for drivers/rtc? Can anyone get a hold of Alessandro to get his opinion on this? I'd surely appreciate if someone can take some time to give a look to the patches. Most of them go thru subsystem's tree and, as far as I can see, I saw very relevant comments and fixes in all those years. I'd love to devote more time to Linux but I'd need to find someone that hires me just to do that the whole day :) -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [rtc-linux] Re: Can someone Ack and queue a patch for RTC subsytem?
Hi, Alessandro Zummo a.zu...@towertech.it writes: On Thu, 19 Dec 2013 11:46:24 -0500 Jason Cooper ja...@lakedaemon.net wrote: In the long term, should we seek out a co-maintainer for drivers/rtc? Can anyone get a hold of Alessandro to get his opinion on this? I'd surely appreciate if someone can take some time to give a look to the patches. Most of them go thru subsystem's tree and, as far as I can see, I saw very relevant comments and fixes in all those years. While I am at it, I wonder if you can give me some directions on the following to add back alarm support to the ISL12057 on the specific hardware I have. All NETGEAR ReadyNAS 102, 104 and 2120 have an ISL 12057 RTC chip which is used as main RTC clock but can also provide alarm. But the alarm interrupt line of the chip is *not* connected to the SoC. It is connected to some power component and can be used to wake up the NAS when it is completely off and the alarm rings. To me this kind of setup seems logical but it does not seem to be directly supported by current RTC logic: - first, I cannot test an interrupt handler implementation I had written as the SoC will never receive any interrupt. This limits my ability to provide one to the driver. - what can/should be done in my .dts file to indicate that the device does not have any IRQ line connected (and hence no interrupt handler) to the SoC but still supports an alarm. As a side note, the implementation I had was a working one on my hardware (i.e. was able to wake up the device at a given time) but I had to remove alarm code to get a basic driver accepted upstream. To be honest, I tried and understand what RTC subsystem expects from documentation and code w/o success. Any help appreciated on that topic. Cheers, a+ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
