2013/4/22 Inki Dae
> 2013/4/22 Rafael J. Wysocki
> > 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 disa
2013/4/23 myungjoo.ham
> 2013/4/22 Inki Dae
> > 2013/4/22 Rafael J. Wysocki
> > > 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
2013/4/22 Inki Dae
> 2013/4/22 Rafael J. Wysocki
> > 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 disa
2013/4/23 myungjoo.ham
> 2013/4/22 Inki Dae
> > 2013/4/22 Rafael J. Wysocki
> > > 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
2013/4/22 Rafael J. Wysocki
> 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
> > > > >
2013/4/22 Tomasz Figa
> 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 a
2013/4/22 Sylwester Nawrocki
> 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
2013/4/22 Tomasz Figa
> On Sunday 21 of April 2013 22:36:08 Inki Dae wrote:
> > > > 2013/4/21 Tomasz Figa
> > > >
> > > > > Hi,
> > > > >
> > > > > On Monday 08 of April 2013 16:41:54 Viresh Kumar wrote:
> > > > > > On 8 April 2013 16:37, Vikas Sajjan
> wrote:
> > > > > > > While migrating to c
On 22 April 2013 15:26, Tomasz Figa 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 clocks should al
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 wrote:
> >>> 3) after those two changes, all that remains is to fix compliance with
> >>>
Hi Tomasz,
CCing Mr. Ham
2013/4/21 Tomasz Figa
> Hi Inki,
>
> On Sunday 21 of April 2013 22:36:08 Inki Dae wrote:
> > 2013/4/21 Tomasz Figa
> >
> > > Hi,
> > >
> > > On Monday 08 of April 2013 16:41:54 Viresh Kumar wrote:
> > > > On 8 April 2013 16:37, Vikas Sajjan wrote:
> > > > > While mig
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
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
> >
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
> >
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 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
On Monday 22 of April 2013 10:44:00 Viresh Kumar wrote:
> On 21 April 2013 20:13, Tomasz Figa 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/
On Sunday 21 of April 2013 22:36:08 Inki Dae wrote:
> > > 2013/4/21 Tomasz Figa
> > >
> > > > Hi,
> > > >
> > > > On Monday 08 of April 2013 16:41:54 Viresh Kumar wrote:
> > > > > On 8 April 2013 16:37, Vikas Sajjan
> > > > > wrote:
> > > > > > While migrating to common clock framework (CCF), I
On 21 April 2013 20:13, Tomasz Figa 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 clk_{un}prepare() everytime fo
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 wrote:
> >>> 3) after those two changes, all that remains is to fix compliance with
> >>>
2013/4/22 Rafael J. Wysocki
> 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
> > > > >
2013/4/22 Tomasz Figa
> 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 a
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
On 22 April 2013 15:26, Tomasz Figa 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 clocks should al
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
> >
2013/4/22 Sylwester Nawrocki
> 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
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
> >
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 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
2013/4/22 Tomasz Figa
> On Sunday 21 of April 2013 22:36:08 Inki Dae wrote:
> > > > 2013/4/21 Tomasz Figa
> > > >
> > > > > Hi,
> > > > >
> > > > > On Monday 08 of April 2013 16:41:54 Viresh Kumar wrote:
> > > > > > On 8 April 2013 16:37, Vikas Sajjan
> wrote:
> > > > > > > While migrating to c
On Monday 22 of April 2013 10:44:00 Viresh Kumar wrote:
> On 21 April 2013 20:13, Tomasz Figa 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/
On Sunday 21 of April 2013 22:36:08 Inki Dae wrote:
> > > 2013/4/21 Tomasz Figa
> > >
> > > > Hi,
> > > >
> > > > On Monday 08 of April 2013 16:41:54 Viresh Kumar wrote:
> > > > > On 8 April 2013 16:37, Vikas Sajjan wrote:
> > > > > > While migrating to common clock framework (CCF), I found that
On 21 April 2013 20:13, Tomasz Figa 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 clk_{un}prepare() everytime fo
Hi Tomasz,
CCing Mr. Ham
2013/4/21 Tomasz Figa
> Hi Inki,
>
> On Sunday 21 of April 2013 22:36:08 Inki Dae wrote:
> > 2013/4/21 Tomasz Figa
> >
> > > Hi,
> > >
> > > On Monday 08 of April 2013 16:41:54 Viresh Kumar wrote:
> > > > On 8 April 2013 16:37, Vikas Sajjan wrote:
> > > > > While mig
2013/4/21 Tomasz Figa
> On Sunday 21 of April 2013 13:23:10 Viresh Kumar wrote:
> > On 20 April 2013 20:56, Inki Dae 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
2013/4/21 Tomasz Figa
> Hi,
>
> On Monday 08 of April 2013 16:41:54 Viresh Kumar wrote:
> > On 8 April 2013 16:37, Vikas Sajjan 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
Hi Inki,
On Sunday 21 of April 2013 22:36:08 Inki Dae wrote:
> 2013/4/21 Tomasz Figa
>
> > Hi,
> >
> > On Monday 08 of April 2013 16:41:54 Viresh Kumar wrote:
> > > On 8 April 2013 16:37, Vikas Sajjan wrote:
> > > > While migrating to common clock framework (CCF), I found that the
> > > > FIMD
Hi Inki,
On Sunday 21 of April 2013 23:05:45 Inki Dae wrote:
> 2013/4/21 Tomasz Figa
>
> > On Sunday 21 of April 2013 13:23:10 Viresh Kumar wrote:
> > > On 20 April 2013 20:56, Inki Dae wrote:
> > > > Sorry for being late. I think clk_prepare/unprepare are nothing to
> > > > do
> > > > yet in c
On 20 April 2013 20:56, Inki Dae 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.
>
> Applied. :)
And you think the comments i gave were incorrect then? Why?
On Apr 20, 2013 8:56 PM, "Inki Dae" wrote:
>
>
>
>
> 2013/4/19 Vikas Sajjan
>>
>> Hi Inki Dae and Viresh,
>>
>> On 8 April 2013 16:41, Viresh Kumar wrote:
>>>
>>> On 8 April 2013 16:37, Vikas Sajjan wrote:
>>> > While migrating to common clock framework (CCF), I found that the
FIMD clocks
>>> >
On Sunday 21 of April 2013 13:23:10 Viresh Kumar wrote:
> On 20 April 2013 20:56, Inki Dae 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.
> >
> > Applied
Hi,
On Monday 08 of April 2013 16:41:54 Viresh Kumar wrote:
> On 8 April 2013 16:37, Vikas Sajjan 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
> > dr
Hi Inki,
On Sunday 21 of April 2013 22:36:08 Inki Dae wrote:
> 2013/4/21 Tomasz Figa
>
> > Hi,
> >
> > On Monday 08 of April 2013 16:41:54 Viresh Kumar wrote:
> > > On 8 April 2013 16:37, Vikas Sajjan wrote:
> > > > While migrating to common clock framework (CCF), I found that the
> > > > FIMD
Hi Inki,
On Sunday 21 of April 2013 23:05:45 Inki Dae wrote:
> 2013/4/21 Tomasz Figa
>
> > On Sunday 21 of April 2013 13:23:10 Viresh Kumar wrote:
> > > On 20 April 2013 20:56, Inki Dae wrote:
> > > > Sorry for being late. I think clk_prepare/unprepare are nothing to
> > > > do
> > > > yet in c
2013/4/21 Tomasz Figa
> On Sunday 21 of April 2013 13:23:10 Viresh Kumar wrote:
> > On 20 April 2013 20:56, Inki Dae 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
2013/4/21 Tomasz Figa
> Hi,
>
> On Monday 08 of April 2013 16:41:54 Viresh Kumar wrote:
> > On 8 April 2013 16:37, Vikas Sajjan 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
On Sunday 21 of April 2013 13:23:10 Viresh Kumar wrote:
> On 20 April 2013 20:56, Inki Dae 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.
> >
> > Applied
Hi,
On Monday 08 of April 2013 16:41:54 Viresh Kumar wrote:
> On 8 April 2013 16:37, Vikas Sajjan 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
> > dr
On 20 April 2013 20:56, Inki Dae 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.
>
> Applied. :)
And you think the comments i gave were incorrect then? Why?
___
On Apr 20, 2013 8:56 PM, "Inki Dae" wrote:
>
>
>
>
> 2013/4/19 Vikas Sajjan
>>
>> Hi Inki Dae and Viresh,
>>
>> On 8 April 2013 16:41, Viresh Kumar wrote:
>>>
>>> On 8 April 2013 16:37, Vikas Sajjan wrote:
>>> > While migrating to common clock framework (CCF), I found that the
FIMD clocks
>>> >
2013/4/19 Vikas Sajjan
> Hi Inki Dae and Viresh,
>
> On 8 April 2013 16:41, Viresh Kumar wrote:
>
>> On 8 April 2013 16:37, Vikas Sajjan 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)
2013/4/19 Vikas Sajjan
> Hi Inki Dae and Viresh,
>
> On 8 April 2013 16:41, Viresh Kumar wrote:
>
>> On 8 April 2013 16:37, Vikas Sajjan 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)
Hi Inki Dae and Viresh,
On 8 April 2013 16:41, Viresh Kumar wrote:
> On 8 April 2013 16:37, Vikas Sajjan 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
Hi Inki Dae and Viresh,
On 8 April 2013 16:41, Viresh Kumar wrote:
> On 8 April 2013 16:37, Vikas Sajjan 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
On 8 April 2013 16:37, Vikas Sajjan 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.
>
> Calling clk_prepar
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 r
On 8 April 2013 16:37, Vikas Sajjan 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.
>
> Calling clk_prepar
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 r
56 matches
Mail list logo
