From: Ilya Yanok <yanok@emcraft.com>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Archit Taneja <archit@ti.com>, Paul Walmsley <paul@pwsan.com>
Subject: Re: [PATCH] OMAP3: hwmod_data: add HWMOD_INIT_NO_RESET flag for dss_dispc
Date: Thu, 22 Dec 2011 16:42:32 +0400 [thread overview]
Message-ID: <4EF325B8.2090206@emcraft.com> (raw)
In-Reply-To: <1324548785.13282.10.camel@deskari>
Hi Tomi,
On 22.12.2011 14:13, Tomi Valkeinen wrote:
> On Thu, 2011-12-22 at 02:00 +0100, Ilya Yanok wrote:
>> Resetting DISPC when a DISPC output is enabled causes the DSS to go into
>> an inconsistent state.
>>
>> commit b923d40dd4211c4ef7d4efa2bd81b7ca1d8744c1
>> Author: Archit Taneja <archit@ti.com>
>> Date: Thu Oct 6 18:04:08 2011 -0600
>>
>> ARM: OMAP2PLUS: DSS: Ensure DSS works correctly if display is
>> enabled in bootloader
>>
>> tries to deal with this problem by checking if display is enabled and
>> disabling it before doing reset.
>>
>> But in my setup dss_dispc is resetted from omap_hwmod_setup_all function
>> _before_ calling omap_dss_reset. So when dispc_disable_outputs is
>> executed dispc is already reset and nothing happens.
>
> Hmm, why is that? You don't have the dss hwmod before dispc in the list
> of hwmods? The code presumes that dss hwmod is handled first.
Looking at the arch/arm/mach-omap2/omap_hwmod_3xxx_data.c I can see that
dss_dispc is in the list of generic hwmods which is registered first
while dss_core hwmod is in revision-specific lists which are registered
later. I think this is the real root of the problem, thanks for pointing
this out!
>
>> This patch and HWMOD_INIT_NO_RESET flags to dss_dispc hwmod thus leaving
>> DISPC untouched so that omap_dss_reset can take care of it.
>
> omap_dss_reset() doesn't reset dispc, so this will leave dispc
> un-reseted.
>
> The idea of the current code is to do the reset similarly on all OMAPs.
> The sequence should be:
>
> - omap_dss_reset(), which disables dispc outputs and manually resets dss
> registers.
> - then the rest of the dss modules reset themselves normally, using the
> softreset bit.
But currently omap_dss_reset() is called the last.
Regards, Ilya.
WARNING: multiple messages have this Message-ID (diff)
From: yanok@emcraft.com (Ilya Yanok)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] OMAP3: hwmod_data: add HWMOD_INIT_NO_RESET flag for dss_dispc
Date: Thu, 22 Dec 2011 16:42:32 +0400 [thread overview]
Message-ID: <4EF325B8.2090206@emcraft.com> (raw)
In-Reply-To: <1324548785.13282.10.camel@deskari>
Hi Tomi,
On 22.12.2011 14:13, Tomi Valkeinen wrote:
> On Thu, 2011-12-22 at 02:00 +0100, Ilya Yanok wrote:
>> Resetting DISPC when a DISPC output is enabled causes the DSS to go into
>> an inconsistent state.
>>
>> commit b923d40dd4211c4ef7d4efa2bd81b7ca1d8744c1
>> Author: Archit Taneja <archit@ti.com>
>> Date: Thu Oct 6 18:04:08 2011 -0600
>>
>> ARM: OMAP2PLUS: DSS: Ensure DSS works correctly if display is
>> enabled in bootloader
>>
>> tries to deal with this problem by checking if display is enabled and
>> disabling it before doing reset.
>>
>> But in my setup dss_dispc is resetted from omap_hwmod_setup_all function
>> _before_ calling omap_dss_reset. So when dispc_disable_outputs is
>> executed dispc is already reset and nothing happens.
>
> Hmm, why is that? You don't have the dss hwmod before dispc in the list
> of hwmods? The code presumes that dss hwmod is handled first.
Looking at the arch/arm/mach-omap2/omap_hwmod_3xxx_data.c I can see that
dss_dispc is in the list of generic hwmods which is registered first
while dss_core hwmod is in revision-specific lists which are registered
later. I think this is the real root of the problem, thanks for pointing
this out!
>
>> This patch and HWMOD_INIT_NO_RESET flags to dss_dispc hwmod thus leaving
>> DISPC untouched so that omap_dss_reset can take care of it.
>
> omap_dss_reset() doesn't reset dispc, so this will leave dispc
> un-reseted.
>
> The idea of the current code is to do the reset similarly on all OMAPs.
> The sequence should be:
>
> - omap_dss_reset(), which disables dispc outputs and manually resets dss
> registers.
> - then the rest of the dss modules reset themselves normally, using the
> softreset bit.
But currently omap_dss_reset() is called the last.
Regards, Ilya.
next prev parent reply other threads:[~2011-12-22 12:42 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-22 1:00 [PATCH] OMAP3: hwmod_data: add HWMOD_INIT_NO_RESET flag for dss_dispc Ilya Yanok
2011-12-22 1:00 ` Ilya Yanok
2011-12-22 10:13 ` Tomi Valkeinen
2011-12-22 10:13 ` Tomi Valkeinen
2011-12-22 12:42 ` Ilya Yanok [this message]
2011-12-22 12:42 ` Ilya Yanok
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4EF325B8.2090206@emcraft.com \
--to=yanok@emcraft.com \
--cc=archit@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=paul@pwsan.com \
--cc=tomi.valkeinen@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.