Hi All,
On 03.08.2020 17:30, Marek Szyprowski wrote:
On 10.07.2020 21:11, Lukasz Luba wrote:
The driver can operate in two modes relaying on devfreq monitoring
mechanism which periodically checks the device status or it can use
interrupts when they are provided by loaded Device Tree. The newly
introduced module parameter can be used to choose between devfreq
monitoring and internal interrupts without modifying the Device Tree.
It also sets devfreq monitoring as default when the parameter is not set
(also the case for default when the driver is not built as a module).
Reported-by: Willy Wolff <willy.mh.wolff.ml@xxxxxxxxx>
Signed-off-by: Lukasz Luba <lukasz.luba@xxxxxxx>
I've got back from my holidays and noticed that in meantime this
commit got merged as commit 4fc9a0470d2d. It revealed that there is a
race between registering exynos5422-dmc driver and exynos-ppmu driver,
which can be observed sometimes as the following message and freeze on
Odroid XU3 with multi_v7_defconfig:
[ 8.767708] exynos5-dmc 10c20000.memory-controller: couldn't probe
performance counters
I will check this later why the EPROBE_DEFER error is not properly
propagated and why it causes a freeze.
It looks that simply propagating return value from
exynos5_counters_get() in exynos5_dmc_get_status() fixes the boot:
# dmesg | grep dmc
[ 8.838754] exynos-ppmu: new PPMU device registered 10d00000.ppmu
(ppmu-event3-dmc0_0)
[ 8.861344] exynos-ppmu: new PPMU device registered 10d10000.ppmu
(ppmu-event3-dmc0_1)
[ 8.868488] exynos5-dmc 10c20000.memory-controller: couldn't probe
performance counters
[ 8.874417] exynos-ppmu: new PPMU device registered 10d60000.ppmu
(ppmu-event3-dmc1_0)
[ 8.886612] exynos-ppmu: new PPMU device registered 10d70000.ppmu
(ppmu-event3-dmc1_1)
[ 9.396769] exynos5-dmc 10c20000.memory-controller: DMC initialized,
in irq mode: 0
I'm still curious why it freezes if getting performance counters is not
possible.
Best regards