user/sven/linux.git/drivers/rtc/rtc-omap.c, branch v6.2.7

rtc: omap: drop unneeded MODULE_ALIAS

2021-09-25T21:26:37Z

The MODULE_DEVICE_TABLE already creates proper alias for platform driver. Having another MODULE_ALIAS causes the alias to be duplicated. Signed-off-by: Krzysztof Kozlowski Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20210916164513.134725-1-krzysztof.kozlowski@canonical.com

rtc: omap: use rtc_write to access OMAP_RTC_OSC_REG

2021-04-29T21:37:18Z

The RTC_OSC_REG register is 32-bit, but the useful information is found in the 7 least significant bits (bits 7-31 are reserved). And in fact, as you can see from the code, all read accesses are 8-bit, as well as some writes. Let's make sure all writes are 8-bit. Moreover, in contexts where consecutive reads / writes after the busy check must take place within 15 us, it is better not to waste time on useless accesses. Signed-off-by: Dario Binacchi Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20210425145924.23353-1-dariobin@libero.it

rtc: rework rtc_register_device() resource management

2020-11-19T11:50:12Z

rtc_register_device() is a managed interface but it doesn't use devres by itself - instead it marks an rtc_device as "registered" and the devres callback for devm_rtc_allocate_device() takes care of resource release. This doesn't correspond with the design behind devres where managed structures should not be aware of being managed. The correct solution here is to register a separate devres callback for unregistering the device. While at it: rename rtc_register_device() to devm_rtc_register_device() and add it to the list of managed interfaces in devres.rst. This way we can avoid any potential confusion of driver developers who may expect there to exist a corresponding unregister function. Signed-off-by: Bartosz Golaszewski Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20201109163409.24301-8-brgl@bgdev.pl

rtc: add devm_ prefix to rtc_nvmem_register()

2020-11-19T11:50:11Z

rtc_nvmem_register() is a managed interface. It doesn't require any release function to be called at driver detach. To avoid confusing driver authors, let's rename it to devm_rtc_nvmem_register() and add it to the list of managed interfaces in Documentation/. Signed-off-by: Bartosz Golaszewski Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20201109163409.24301-6-brgl@bgdev.pl

rtc: omap: use devm_pinctrl_register()

2020-11-19T11:50:11Z

Use a managed variant of pinctrl_register(). This way we can shorten the remove() callback as well as drop a goto label from probe(). Signed-off-by: Bartosz Golaszewski Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20201109163409.24301-2-brgl@bgdev.pl

rtc: omap: drop unused dt-bindings header

2020-03-23T08:27:17Z

The definitons in the dt-binding's gpio header only contains some constants to be used in device trees. It is not relevant for rtc-omap (as the gpio API hides the details) and in fact unused so it can just be dropped. Signed-off-by: Uwe Kleine-König Link: https://lore.kernel.org/r/20200321203737.29850-1-uwe@kleine-koenig.org Signed-off-by: Alexandre Belloni

rtc: omap: Remove unneeded semicolon

2019-12-23T10:16:23Z

Fixes coccicheck warning: drivers/rtc/rtc-omap.c:619:2-3: Unneeded semicolon Reported-by: Hulk Robot Signed-off-by: zhengbin Link: https://lore.kernel.org/r/1576466353-45384-1-git-send-email-zhengbin13@huawei.com Signed-off-by: Alexandre Belloni

rtc: use devm_platform_ioremap_resource() to simplify code

2019-10-06T23:07:35Z

Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Signed-off-by: YueHaibing Link: https://lore.kernel.org/r/20191006102953.57536-2-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-3-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-4-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-5-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-6-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-7-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-8-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-9-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-10-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-11-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-12-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-13-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-14-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-15-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-16-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-17-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-18-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-19-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-20-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-21-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-22-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-23-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-24-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-25-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-26-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-27-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-28-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-29-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-30-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-31-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-32-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-33-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-34-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-35-yuehaibing@huawei.com Signed-off-by: Alexandre Belloni

Merge tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc

2019-05-16T16:19:14Z

Pull ARM SoC-related driver updates from Olof Johansson: "Various driver updates for platforms and a couple of the small driver subsystems we merge through our tree: Among the larger pieces: - Power management improvements for TI am335x and am437x (RTC suspend/wake) - Misc new additions for Amlogic (socinfo updates) - ZynqMP FPGA manager - Nvidia improvements for reset/powergate handling - PMIC wrapper for Mediatek MT8516 - Misc fixes/improvements for ARM SCMI, TEE, NXP i.MX SCU drivers" * tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (57 commits) soc: aspeed: fix Kconfig soc: add aspeed folder and misc drivers spi: zynqmp: Fix build break soc: imx: Add generic i.MX8 SoC driver MAINTAINERS: Update email for Qualcomm SoC maintainer memory: tegra: Fix a typos for "fdcdwr2" mc client Revert "ARM: tegra: Restore memory arbitration on resume from LP1 on Tegra30+" memory: tegra: Replace readl-writel with mc_readl-mc_writel memory: tegra: Fix integer overflow on tick value calculation memory: tegra: Fix missed registers values latching ARM: tegra: cpuidle: Handle tick broadcasting within cpuidle core on Tegra20/30 optee: allow to work without static shared memory soc/tegra: pmc: Move powergate initialisation to probe soc/tegra: pmc: Remove reset sysfs entries on error soc/tegra: pmc: Fix reset sources and levels soc: amlogic: meson-gx-pwrc-vpu: Add support for G12A soc: amlogic: meson-gx-pwrc-vpu: Fix power on/off register bitmask fpga manager: Adding FPGA Manager support for Xilinx zynqmp dt-bindings: fpga: Add bindings for ZynqMP fpga driver firmware: xilinx: Add fpga API's ...

rtc: OMAP: Add support for rtc-only mode

2019-04-08T17:22:12Z

Prepare rtc driver for rtc-only with DDR in self-refresh mode. omap_rtc_power_off now should cater to two features: 1) RTC plus DDR in self-refresh is power a saving mode where in the entire system including the different voltage rails from PMIC are shutdown except the ones feeding on to RTC and DDR. DDR is kept in self-refresh hence the contents are preserved. RTC ALARM2 is connected to PMIC_EN line once we the ALARM2 is triggered we enter the mode with DDR in self-refresh and RTC Ticking. After a predetermined time an RTC ALARM1 triggers waking up the system[1]. The control goes to bootloader. The bootloader then checks RTC scratchpad registers to confirm it was an rtc_only wakeup and follows a different path, configure bare minimal clocks for ddr and then jumps to the resume address in another RTC scratchpad registers and transfers the control to Kernel. Kernel then restores the saved context. omap_rtc_power_off_program does the ALARM2 programming part. [1] http://www.ti.com/lit/ug/spruhl7h/spruhl7h.pdf Page 2884 2) Power-off: This is usual poweroff mode. omap_rtc_power_off calls the above omap_rtc_power_off_program function and in addition to that programs the OMAP_RTC_PMIC_REG for any external wake ups for PMIC like the pushbutton and shuts off the PMIC. Hence the split in omap_rtc_power_off. Signed-off-by: Keerthy Acked-by: Alexandre Belloni [tony@atomide.com: folded in a fix for compile warning] Signed-off-by: Tony Lindgren