> -----Original Message----- > From: Valkeinen, Tomi > Sent: Monday, March 14, 2011 2:55 PM > To: Hiremath, Vaibhav > Cc: K, Mythri P; Stephan Raue; linux-omap@xxxxxxxxxxxxxxx > Subject: RE: [PATCH v5 00/10] OMAP4 : DSS2 : HDMI support on OMAP4 > > On Mon, 2011-03-14 at 03:35 -0500, Hiremath, Vaibhav wrote: > > > -----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. > > I don't know about OMAP4, but on OMAP3 the register contents are only > lost when DSS goes to OFF mode. If you just turn off the clocks and OFF > mode is not enabled in the PM, context restore is not needed. I am not > sure of the current status of OFF mode in the mainline kernel. > > However, for some reason DSS works fine on my Overo board. I would > imagine that it would break also if OFF is enabled for all omap > boards... > > As for get_last_off_on_transaction_id(), it seems to be called > get_context_loss_count() in the mainline kernel and returns u32, not > int. I haven't tested it, but get_last_off_on_transaction_id pointer in > the dss platform data should be set to get_context_loss_count in the > board file (or in arch/arm/plat-omap/display.c if using the dss2 tree). > [Hiremath, Vaibhav] Let me try this out. Thanks, Vaibhav > Tomi > -- 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
