2013/4/22 Inki Dae
2013/4/22 Rafael J. Wysocki r...@sisk.pl
On Monday, April 22, 2013 12:37:36 PM Tomasz Figa wrote:
On Monday 22 of April 2013 12:17:39 Sylwester Nawrocki wrote:
On 04/22/2013 12:03 PM, Inki Dae wrote:
Also looks good to me. But what if power domain was
On Sunday 21 of April 2013 22:36:08 Inki Dae wrote:
2013/4/21 Tomasz Figa tomasz.f...@gmail.com
Hi,
On Monday 08 of April 2013 16:41:54 Viresh Kumar wrote:
On 8 April 2013 16:37, Vikas Sajjan vikas.saj...@linaro.org wrote:
While migrating to common clock framework
On Monday 22 of April 2013 10:44:00 Viresh Kumar wrote:
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
On 04/22/2013 11:56 AM, Tomasz Figa wrote:
On Monday 22 of April 2013 10:44:00 Viresh Kumar wrote:
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:
On 04/22/2013 12:03 PM, Inki Dae wrote:
Also looks good to me. But what if power domain was disabled without pm
runtime? In this case, you must enable the power domain at machine code
or
bootloader somewhere. This way would not only need some hard codes to
turn
the
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 Monday 22 of April 2013 12:17:39 Sylwester Nawrocki wrote:
On 04/22/2013 12:03 PM, Inki Dae wrote:
Also looks good to me. But what if power domain was disabled without
pm
runtime? In this case, you must enable the power domain at machine
code or
bootloader
On Monday, April 22, 2013 12:37:36 PM Tomasz Figa wrote:
On Monday 22 of April 2013 12:17:39 Sylwester Nawrocki wrote:
On 04/22/2013 12:03 PM, Inki Dae wrote:
Also looks good to me. But what if power domain was disabled without
pm
runtime? In this case, you must enable
On Monday 22 of April 2013 12:05:49 Sylwester Nawrocki wrote:
On 04/22/2013 11:56 AM, Tomasz Figa wrote:
On Monday 22 of April 2013 10:44:00 Viresh Kumar wrote:
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
Hi,
On Monday 08 of April 2013 16:41:54 Viresh Kumar wrote:
On 8 April 2013 16:37, Vikas Sajjan vikas.saj...@linaro.org wrote:
While migrating to common clock framework (CCF), I found that the FIMD
clocks were pulled down by the CCF.
If CCF finds any clock(s) which has NOT been claimed by
On Sunday 21 of April 2013 13:23:10 Viresh Kumar wrote:
On 20 April 2013 20:56, Inki Dae inki@samsung.com wrote:
Sorry for being late. I think clk_prepare/unprepare are nothing to do
yet in case of Exynos but those might be used for in the future so
your patch looks good to me as is.
Hi Inki,
On Sunday 21 of April 2013 23:05:45 Inki Dae wrote:
2013/4/21 Tomasz Figa tomasz.f...@gmail.com
On Sunday 21 of April 2013 13:23:10 Viresh Kumar wrote:
On 20 April 2013 20:56, Inki Dae inki@samsung.com wrote:
Sorry for being late. I think clk_prepare/unprepare are nothing
Hi Inki,
On Sunday 21 of April 2013 22:36:08 Inki Dae wrote:
2013/4/21 Tomasz Figa tomasz.f...@gmail.com
Hi,
On Monday 08 of April 2013 16:41:54 Viresh Kumar wrote:
On 8 April 2013 16:37, Vikas Sajjan vikas.saj...@linaro.org wrote:
While migrating to common clock framework (CCF),
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
While migrating to common clock framework (CCF), I 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.
Calling clk_prepare() for FIMD clocks fixes the issue.
This patch also
On 8 April 2013 16:37, Vikas Sajjan vikas.saj...@linaro.org wrote:
While migrating to common clock framework (CCF), I 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.
16 matches
Mail list logo
