> -----Original Message-----
> From: [email protected] [mailto:linux-omap-
> [email protected]] On Behalf Of Hiremath, Vaibhav
> Sent: Friday, March 11, 2011 6:53 PM
> To: Valkeinen, Tomi; K, Mythri P
> Cc: Stephan Raue; [email protected]
> Subject: RE: [PATCH v5 00/10] OMAP4 : DSS2 : HDMI support on OMAP4
>
> > -----Original Message-----
> > From: [email protected] [mailto:linux-omap-
> > [email protected]] On Behalf Of Valkeinen, Tomi
> > Sent: Friday, March 11, 2011 12:55 PM
> > To: K, Mythri P
> > Cc: Stephan Raue; [email protected]
> > Subject: Re: [PATCH v5 00/10] OMAP4 : DSS2 : HDMI support on OMAP4
> >
> > On Fri, 2011-03-11 at 00:16 -0600, K, Mythri P wrote:
> > > Hi Stephan,
> > >
> > > On Fri, Mar 11, 2011 at 5:37 AM, Stephan Raue
> <[email protected]>
> > wrote:
> >
> > > > thanks, this helps to boot the kernel. but now i get:
> > > >
> > >
> > > <snip>
> > >
> > > > see also: http://paste.pocoo.org/show/351648/
> > > >
> > >
> > > I see that you kernel is not booting because of dss clk
> > > [ 3.335601] PC is at dss_clk_disable_no_ctx+0x0/0xa4
> > > [ 3.335632] LR is at omap_dispc_register_isr+0xa4/0xcc
> > > Tomi is this related to the clock issue you were mentioning , which
> > > gets solved by adding a delay ?
> >
> > Well, I have a hack patch in my tree which adds a delay of 10us. That
> > fixed the problem for me, but the 10us is just a random guess. It could
> > be that it needs to be longer wait. But this could be something else
> > also.
> >
> > Tomi
> >
> [Hiremath, Vaibhav] Tomi, just thought of updating you,
>
> The linux-omap/dss2 OMAP3EVM seems to be broken, I am trying to debug this
> at the moment and will update about my findings.
>
> Since linux-omap/master is booting up fine, it looks like one of new DSS
> patch leading to this.
>
[Hiremath, Vaibhav] I think I found the where and why the kernel is crashing
but not sure about root-cause -
The root-cause turned out to be -
void dss_clk_enable(enum dss_clock clks)
{
...
if (check_ctx && cpu_is_omap34xx() && dss_need_ctx_restore())
restore_all_ctx();
...
}
In this case, restore never happens, if I understand correctly, I am expecting,
the context must be restored when all clock (especially interface clock) is
disabled.
In order to do this, dss_need_ctx_restore must be implemented here, which I
think should be ORed with other conditions.
if (cpu_is_omap34xx() && (check_ctx || dss_need_ctx_restore()))
(This results in kernel crash at my end)
Personally I don't know any platform is implementing this function OR how one
should make use of it. I remember last time we had similar discussion and the
comment came was, restore only required in case of off mode. I feel, this is
not applicable here, since irrespective of retention/inactive/off mode if
driver is disabling clock for the peripheral we must restore the context.
Thanks,
Vaibhav
> Thanks,
> Vaibhav
>
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> > the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
