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
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
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)
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
27 matches
Mail list logo
