Subject: Multiple issues with omap4 panda es in linux next

From: [email-masked] (Kevin Hilman)
Date: Thu, 25 Apr 2013 06:58:19 -0700

Tony Lindgren <[email-masked]> writes:

> * Santosh Shilimkar <[email-masked]> [130419 10:56]:
>> On Friday 19 April 2013 11:14 PM, Tony Lindgren wrote:
>> > * Santosh Shilimkar <[email-masked]> [130419 10:43]:
>> >> On Friday 19 April 2013 10:43 PM, Tony Lindgren wrote:
>> >>> Hi all,
>> >>>
>> >>> Here's a list of breakage I've noticed so far while trying to
>> >>> use linux next on my pandaboard es. Probably similar issues exist
>> >>> on other boards as well.
>> >>>
>> >>> Ideally we would not have any breakage by the merge window, so
>> >>> let's try to get these fixed ASAP:
>> >>>
>> >>> 1. Serial console broken on panda es booting with DT
>> >>>
>> >>> The symptoms are dmesg output stopping after few lines
>> >>> and only continuing after pressing a key. Does not seem to
>> >>> happen on blaze with DT for some reason. And does not happen
>> >>> on panda es with legacy booting.
>> >>>
>> >> This one is known and reported on list along with fix patches and
>> >> later pull request [1].
>> >>
>> >> Unfortunately with all the testing and everything and patches have
>> >> been on the list for quite some time, feedback on one of the patch
>> >> received was after pull request and then there was no further
>> >> clarification. That series address the same exact issue you have
>> >> mentioned above.
>> > 
>> > OK thanks. I think Paul picked some of those and the plan was
>> > to update the branch? Which one(s) should go into v3.10 as fixes?
>> > 
>> Main in that series was to handle driver sysc handling withing hwmod
>> layer and that is where the series got stuck [2]. Without that support
>> other patches won't fix the issue.
>
> OK it seems that that is still ongoing discussion. For v3.10 we should
> probably just disable PM for omap4 for DT booting so people can use
> it for DT related development.

Disabling PM (and even avoiding WFI using 'nohlt') will not fix this
problem, since it's related to the idle-mode of the IP block itself.

What fixes the problem is the series from Santosh for the SYSC removal.

Santosh, it seems that series combined a fix for this problem with some
cleanup of the hwmod code that Paul had some concerns with.  Is there
any chance you can split up that series into a fix targetted at the
DT-boot UART problem and a feature cleanup for hwmod?

Then we hopefully get this fix into v3.10-rc and work on the hwmod
changes/cleanup for the following merge window.

Kevin