Re: [RFC] ARM: OMAP2+: hwmod: add an option to disable a module

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 07/01/2016 07:08 PM, Stefan Eichenberger wrote:
On Thu, Jun 30, 2016 at 10:46:16AM +0530, Lokesh Vutla wrote:
+Dave, Tony, Keerthy,

Hi Stefan,

On Tuesday 28 June 2016 09:26 PM, Stefan Eichenberger wrote:
If a module is not available, omap_hwmod will still try to access the
registers if it is present in the hwmod_list. If the module is not
powered at all (e.g. rtc) then linux can't start. It is possible
to disable the module by setting the state to disabled and to assign
ti,hwmods an empty string but this leads to the following warning:
[    0.188255] omap_hwmod: rtc missing dt data
[    0.188273] omap_hwmod: rtc: no MPU register target found
[    0.188287] omap_hwmod: rtc: no dt node
[    0.188300] ------------[ cut here ]------------
[    0.188330] WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2493 _init+0x1fc/0x45c()
[    0.188344] omap_hwmod: rtc: doesn't have mpu register target base
[    0.188357] Modules linked in:
[    0.188388] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.4.0-00004-g17704c9-dirty #24
[    0.188402] Hardware name: Generic AM33XX (Flattened Device Tree)
[    0.188445] [<c0017c24>] (unwind_backtrace) from [<c0013f88>] (show_stack+0x10/0x14)
[    0.188474] [<c0013f88>] (show_stack) from [<c0347860>] (dump_stack+0x84/0x9c)
[    0.188508] [<c0347860>] (dump_stack) from [<c003ca40>] (warn_slowpath_common+0x78/0xb4)
[    0.188534] [<c003ca40>] (warn_slowpath_common) from [<c003caac>] (warn_slowpath_fmt+0x30/0x40)
[    0.188558] [<c003caac>] (warn_slowpath_fmt) from [<c08b76e0>] (_init+0x1fc/0x45c)
[    0.188589] [<c08b76e0>] (_init) from [<c0027844>] (omap_hwmod_for_each+0x34/0x60)
[    0.188613] [<c0027844>] (omap_hwmod_for_each) from [<c08b7d04>] (__omap_hwmod_setup_all+0x24/0x40)
[    0.188638] [<c08b7d04>] (__omap_hwmod_setup_all) from [<c00098a4>] (do_one_initcall+0x80/0x1e0)
[    0.188675] [<c00098a4>] (do_one_initcall) from [<c08a9ec0>] (kernel_init_freeable+0x214/0x2e4)
[    0.188707] [<c08a9ec0>] (kernel_init_freeable) from [<c0642f4c>] (kernel_init+0x8/0xec)
[    0.188737] [<c0642f4c>] (kernel_init) from [<c000f810>] (ret_from_fork+0x14/0x24)
[    0.188919] ---[ end trace 9e6a5f1c3af2b60d ]---

Unfortunately we cannot check of_device_is_available because timers are
set to disabled. In this case we would not setup the timer module
what leads to a crash during boot.

The same issue has been encountered on AM43x-epos evm. Dave has
submitted a similar patch[1](Complete Series[2]) to avoid hwmod handling
of sudh IPs. Not sure what happened to this thread but later it was
decided not to register such IPs to hwmod using compatible properties as
done here[3].

Probably Dave can comment more.

[1] https://patchwork.kernel.org/patch/5945961/
[2] https://www.mail-archive.com/linux-omap@xxxxxxxxxxxxxxx/msg114645.html
[3] https://patchwork.kernel.org/patch/8357011/

Thanks for that hint. As I understand the final patch, the new am438x devices
don't have the RTC enabled at all, so they can disable the RTC there.
Unfortunately in my case the RTC is not powered by hardware design, so
the chip would still support the feature and I can not do a similiar
trick.

Would it be possible to do something in the following form:
if (!of_device_is_available(np) && !of_device_is_compatible(np, "ti,omap-counter32k")) {
     oh->_state = _HWMOD_STATE_DISABLED;
     return 0;
}
Or could this have bad side-effects? I haven't it tested yet.


There was one more related thread recently, Just FYI:
 https://lkml.org/lkml/2016/4/12/706


--
regards,
-grygorii
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux