On 22 May 2014 13:33, Thierry Reding wrote:
> On Thu, May 22, 2014 at 12:06:16PM +0530, Rahul Sharma wrote:
>> On 22 May 2014 11:51, Sachin Kamat wrote:
>> > Hi Rahul,
>> [snip]
>> >>
>> >> + clk_prepare_enable(ctx->bus_clk);
>> >
>> > Probably a check for its success?
>> >
>> >> + cl
On 22 May 2014 12:06, Rahul Sharma wrote:
> On 22 May 2014 11:51, Sachin Kamat wrote:
>> Hi Rahul,
> [snip]
>>>
>>> + clk_prepare_enable(ctx->bus_clk);
>>
>> Probably a check for its success?
>>
>>> + clk_prepare_enable(ctx->lcd_clk);
>>
>
> Generally we don't check this in any of the
On 22 May 2014 11:51, Sachin Kamat wrote:
> Hi Rahul,
[snip]
>>
>> + clk_prepare_enable(ctx->bus_clk);
>
> Probably a check for its success?
>
>> + clk_prepare_enable(ctx->lcd_clk);
>
Generally we don't check this in any of the driver. It will be
quite unnecessary.
Regards,
Rahul Sha
Hi Rahul,
On 22 May 2014 10:46, Rahul Sharma wrote:
> From: Rahul Sharma
>
> Fimd probe is accessing fimd Registers without enabling the fimd
> gate clocks. If FIMD clocks are kept disabled in Uboot or disbaled
> during kernel boottime, the system hangs during boottime.
>
> This issue got surfac
From: Rahul Sharma
Fimd probe is accessing fimd Registers without enabling the fimd
gate clocks. If FIMD clocks are kept disabled in Uboot or disbaled
during kernel boottime, the system hangs during boottime.
This issue got surfaced when verifying with sysmmu enabled. Probe of
fimd Sysmmu enable
On Thu, May 22, 2014 at 12:06:16PM +0530, Rahul Sharma wrote:
> On 22 May 2014 11:51, Sachin Kamat wrote:
> > Hi Rahul,
> [snip]
> >>
> >> + clk_prepare_enable(ctx->bus_clk);
> >
> > Probably a check for its success?
> >
> >> + clk_prepare_enable(ctx->lcd_clk);
> >
>
> Generally we do
2013/3/20 Vikas Sajjan :
> 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.
>
> By calling clk_prepare_enable() for FIM
Hi,
On 27 March 2013 15:53, Inki Dae wrote:
> 2013/3/20 Vikas Sajjan :
>> 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
Hi,
On 27 March 2013 15:53, Inki Dae wrote:
> 2013/3/20 Vikas Sajjan :
>> 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
2013/3/20 Vikas Sajjan :
> 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.
>
> By calling clk_prepare_enable() for FIM
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.
By calling clk_prepare_enable() for FIMD clocks fixes the issue.
this patc
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.
By calling clk_prepare_enable() for FIMD clocks fixes the issue.
this patc
12 matches
Mail list logo
