On 01-08-16, 20:01, Matwey V. Kornilov wrote:
> With this patch, there is no cpufreq directory here.
>
> Without this patch, the output is the following:
>
> nohostname:~ # uname -a
> Linux nohostname 4.6.4-3.gecd9058-default #1 SMP PREEMPT Fri Jul 15
> 08:08:50 UTC 2016 (ecd9058) armv7l armv7l
Mhz by cpufreq driver
> (as it did whet there was cpufreq driver).
>
> 2016-07-29 21:01 GMT+03:00 Matwey V. Kornilov <mat...@sai.msu.ru>:
> > Hello,
> >
> > I've found that the following commit fixes the issue:
> >
> > commit 7694ca6e1d6f01122f05039b81f70f64b1
On 22 April 2013 15:26, Tomasz Figa t.f...@samsung.com wrote:
Can you assure that in future SoCs, on which this driver will be used, this
assumption will still hold true or even that in current Exynos driver this
behavior won't be changed?
Probably yes.. Registers for enabling/disabling these
On 21 April 2013 20:13, Tomasz Figa tomasz.f...@gmail.com wrote:
3) after those two changes, all that remains is to fix compliance with
Common Clock Framework, in other words:
s/clk_enable/clk_prepare_enable/
and
s/clk_disable/clk_disable_unprepare/
We don't have to call
by Viresh Kumar viresh.ku...@linaro.org
Changes since v2:
- moved clk_prepare_enable() and clk_disable_unprepare() from
fimd_probe() to fimd_clock() as suggested by Inki Dae
inki@samsung.com
Changes since v1:
- added error checking for clk_prepare_enable
On 1 April 2013 14:13, Vikas Sajjan vikas.saj...@linaro.org wrote:
While migrating to common clock framework (CCF), found that the FIMD clocks
s/found/we found/
were pulled down by the CCF.
If CCF finds any clock(s) which has NOT been claimed by any of the
drivers, then such clock(s) are
On 19 March 2013 15:29, Vikas Sajjan vikas.saj...@linaro.org wrote:
While migrating to common clock framework (CCF), found that the FIMD clocks
were pulled down by the CCF.
If CCF finds any clock(s) which has NOT been claimed by any of the
drivers, then such clock(s) are PULLed low by CCF.
