Message ID | 20230612113059.247275-1-linux@rasmusvillemoes.dk |
---|---|
Headers | show |
Series | rtc: isl12022: battery backup voltage and clock support | expand |
The current handling of the low-battery bits in the status register is wrong. The first six patches fix that and implement proper support for RTC_VL_READ. The last two patches allow describing the isl12022 as a clock provider, for now just as a fixed 32kHz clock. They are also tangentially related to the backup battery, in that when the isl12022 is not used as a clock source, one can save some power consumption in battery mode by setting the FOx bits to 0. v2 changes: Patch 2: add Alexandre as maintainer [Rob's bot]. Patch 4: On arm64, <linux/bitfield.h> apparently ends up being included implicitly, but not so on arm [kernel test robot]. Use the more common post-increment in for loops [Andy]. Patch 5: Drop RTC_VL_CLR, just do RTC_VL_READ [Alexandre]. Patch 6: Set the TSE bit to trigger a manual detection, but drop the part reading the SR register and issuing a dev_warn() in case of low battery [Alexandre]. Patch 7: (Hopefully) properly describe the "at most one of interrupts and #clock-cells" [thanks Krzysztof]. Patch 8: Drop a useless dev_warn() in case clearing the FOx bits fails. Rasmus Villemoes (8): rtc: isl12022: remove wrong warning for low battery level dt-bindings: rtc: Move isil,isl12022 from trivial-rtc.yaml into own schema file dt-bindings: rtc: isl12022: add bindings for battery alarm trip levels rtc: isl12022: add support for trip level DT bindings rtc: isl12022: implement RTC_VL_READ ioctl rtc: isl12022: trigger battery level detection during probe dt-bindings: rtc: isl12022: add #clock-cells property rtc: isl12022: implement support for the #clock-cells DT property .../bindings/rtc/intersil,isl12022.yaml | 69 ++++++++++ .../devicetree/bindings/rtc/trivial-rtc.yaml | 2 - drivers/rtc/rtc-isl12022.c | 118 +++++++++++++++++- 3 files changed, 181 insertions(+), 8 deletions(-) create mode 100644 Documentation/devicetree/bindings/rtc/intersil,isl12022.yaml
On Tue, Jun 13, 2023 at 03:00:02PM +0200, Rasmus Villemoes wrote: > The current handling of the low-battery bits in the status register is > wrong. The first six patches fix that and implement proper support for > RTC_VL_READ. > > The last two patches allow describing the isl12022 as a clock > provider, for now just as a fixed 32kHz clock. They are also > tangentially related to the backup battery, in that when the isl12022 > is not used as a clock source, one can save some power consumption in > battery mode by setting the FOx bits to 0. > v2 changes: A nit-pick regarding to the process. You used In-reply-to email header and this a bit inconvenient if you operate with a threads in MUA, for example, I would like to delete old thread, but in this case it automatically marks v2 for deletion (I'm using classical mutt).
On 13/06/2023 15:00, Rasmus Villemoes wrote: > The current handling of the low-battery bits in the status register is > wrong. The first six patches fix that and implement proper support for > RTC_VL_READ. > > The last two patches allow describing the isl12022 as a clock > provider, for now just as a fixed 32kHz clock. They are also > tangentially related to the backup battery, in that when the isl12022 > is not used as a clock source, one can save some power consumption in > battery mode by setting the FOx bits to 0. > > v2 changes: Do not attach (thread) your patchsets to some other threads (unrelated or older versions). This buries them deep in the mailbox and might interfere with applying entire sets. Best regards, Krzysztof
On 13/06/2023 21.06, Krzysztof Kozlowski wrote: > On 13/06/2023 15:00, Rasmus Villemoes wrote: >> The current handling of the low-battery bits in the status register is >> wrong. The first six patches fix that and implement proper support for >> RTC_VL_READ. >> >> The last two patches allow describing the isl12022 as a clock >> provider, for now just as a fixed 32kHz clock. They are also >> tangentially related to the backup battery, in that when the isl12022 >> is not used as a clock source, one can save some power consumption in >> battery mode by setting the FOx bits to 0. >> >> v2 changes: > > Do not attach (thread) your patchsets to some other threads (unrelated > or older versions). This buries them deep in the mailbox and might > interfere with applying entire sets. > Arrgh, I really didn't mean to do that with v3, but I reused the 'git send-email' from my shell history and overlooked that I had that --in-reply-to :( Sorry folks! Rasmus