> -----Original Message----- > From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap- > owner@xxxxxxxxxxxxxxx] On Behalf Of Hiremath, Vaibhav > Sent: Friday, March 11, 2011 6:53 PM > To: Valkeinen, Tomi; K, Mythri P > Cc: Stephan Raue; linux-omap@xxxxxxxxxxxxxxx > Subject: RE: [PATCH v5 00/10] OMAP4 : DSS2 : HDMI support on OMAP4 > > > -----Original Message----- > > From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap- > > owner@xxxxxxxxxxxxxxx] On Behalf Of Valkeinen, Tomi > > Sent: Friday, March 11, 2011 12:55 PM > > To: K, Mythri P > > Cc: Stephan Raue; linux-omap@xxxxxxxxxxxxxxx > > 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 > <mailinglists@xxxxxxxxxxx> > > 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 majordomo@xxxxxxxxxxxxxxx > > 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 majordomo@xxxxxxxxxxxxxxx > 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
