From: Suman Anna <s-anna@ti.com>
To: Tony Lindgren <tony@atomide.com>
Cc: <linux-omap@vger.kernel.org>, <devicetree@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
Tero Kristo <t-kristo@ti.com>
Subject: Re: [PATCH 00/13] Add IPU & DSP remoteprocs on OMAP4 and OMAP5
Date: Fri, 10 Jul 2020 13:24:17 -0500 [thread overview]
Message-ID: <d9f5dab4-a588-2dda-6d95-7e0c9c5f6b14@ti.com> (raw)
In-Reply-To: <20200710174051.GG5849@atomide.com>
On 7/10/20 12:40 PM, Tony Lindgren wrote:
> * Suman Anna <s-anna@ti.com> [200710 17:18]:
>> On 7/10/20 11:58 AM, Tony Lindgren wrote:
>>> I wonder the following commit in v5.8-rc3 might help with this though:
>>>
>>> 5ce8aee81be6 ("bus: ti-sysc: Flush posted write on enable and disable")
>>>
>>
>> I had already tested on v5.8-rc4 when I posted the patches, so this patch
>> doesn't help. OMAP5 DSP is fine, because Think it has to do with this
>> automated
>
> OK
>
>> So, I am looking at the TRM, and the three VDD_{IVA,MPU,CORE}_I2C_DISABLE
>> bits in VOLTCTRL are marked debug-purpose only, so I don't think we should
>> be setting those to begin with. Any reason why you want to set those?
>> Anyway, these bits were not an issue, I have specifically tried that
>> already.
>
> I'm pretty sure that's how the old TI PM branch was initializing them to
> disable voltctrl I2C use on init. But if these are not the issue I guess
> no need to mess with them.
OK.
>
> Could it be that we have wrong voltage tables for 4460 in the mainline
> kernel? See earlier commit 32236a84906f ("ARM: OMAP2+: Update 4430
> voltage controller operating points").
I am running on Pandaboard, so it's a OMAP4430 ES2.2. Tried with the
older values reverting the above commit, didn't make any difference. So,
the only trigger point so far seems to be the automatic IVA voltage
domain transition. Looks to be a timing related issue given that a debug
trace also helped, wondering if it goes through a quick RET->ON->RET
sequence from the time I disable the MMUs (child device) to the actual
module disabling in sysc_module_disable() on the parent target-module
device.
regards
Suman
WARNING: multiple messages have this Message-ID (diff)
From: Suman Anna <s-anna@ti.com>
To: Tony Lindgren <tony@atomide.com>
Cc: Tero Kristo <t-kristo@ti.com>,
devicetree@vger.kernel.org, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 00/13] Add IPU & DSP remoteprocs on OMAP4 and OMAP5
Date: Fri, 10 Jul 2020 13:24:17 -0500 [thread overview]
Message-ID: <d9f5dab4-a588-2dda-6d95-7e0c9c5f6b14@ti.com> (raw)
In-Reply-To: <20200710174051.GG5849@atomide.com>
On 7/10/20 12:40 PM, Tony Lindgren wrote:
> * Suman Anna <s-anna@ti.com> [200710 17:18]:
>> On 7/10/20 11:58 AM, Tony Lindgren wrote:
>>> I wonder the following commit in v5.8-rc3 might help with this though:
>>>
>>> 5ce8aee81be6 ("bus: ti-sysc: Flush posted write on enable and disable")
>>>
>>
>> I had already tested on v5.8-rc4 when I posted the patches, so this patch
>> doesn't help. OMAP5 DSP is fine, because Think it has to do with this
>> automated
>
> OK
>
>> So, I am looking at the TRM, and the three VDD_{IVA,MPU,CORE}_I2C_DISABLE
>> bits in VOLTCTRL are marked debug-purpose only, so I don't think we should
>> be setting those to begin with. Any reason why you want to set those?
>> Anyway, these bits were not an issue, I have specifically tried that
>> already.
>
> I'm pretty sure that's how the old TI PM branch was initializing them to
> disable voltctrl I2C use on init. But if these are not the issue I guess
> no need to mess with them.
OK.
>
> Could it be that we have wrong voltage tables for 4460 in the mainline
> kernel? See earlier commit 32236a84906f ("ARM: OMAP2+: Update 4430
> voltage controller operating points").
I am running on Pandaboard, so it's a OMAP4430 ES2.2. Tried with the
older values reverting the above commit, didn't make any difference. So,
the only trigger point so far seems to be the automatic IVA voltage
domain transition. Looks to be a timing related issue given that a debug
trace also helped, wondering if it goes through a quick RET->ON->RET
sequence from the time I disable the MMUs (child device) to the actual
module disabling in sysc_module_disable() on the parent target-module
device.
regards
Suman
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-07-10 18:24 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-09 23:19 [PATCH 00/13] Add IPU & DSP remoteprocs on OMAP4 and OMAP5 Suman Anna
2020-07-09 23:19 ` Suman Anna
2020-07-09 23:19 ` [PATCH 01/13] ARM: dts: omap4: Add timer_sys_ck clocks for timers Suman Anna
2020-07-09 23:19 ` Suman Anna
2020-07-09 23:19 ` [PATCH 02/13] ARM: dts: omap5: " Suman Anna
2020-07-09 23:19 ` Suman Anna
2020-07-09 23:19 ` [PATCH 03/13] ARM: dts: omap4: Update the DSP node Suman Anna
2020-07-09 23:19 ` Suman Anna
2020-07-09 23:19 ` [PATCH 04/13] ARM: dts: omap4: Add IPU DT node Suman Anna
2020-07-09 23:19 ` Suman Anna
2020-07-09 23:19 ` [PATCH 05/13] ARM: dts: omap4: Add aliases for rproc nodes Suman Anna
2020-07-09 23:19 ` Suman Anna
2020-07-09 23:19 ` [PATCH 06/13] ARM: dts: omap4-panda-common: Add CMA pools and enable IPU & DSP Suman Anna
2020-07-09 23:19 ` Suman Anna
2020-08-12 5:31 ` Guillaume Tucker
2020-08-12 5:31 ` Guillaume Tucker
2020-08-14 14:32 ` Guillaume Tucker
2020-08-14 14:32 ` Guillaume Tucker
2020-08-14 15:26 ` Suman Anna
2020-08-14 15:26 ` Suman Anna
2020-08-14 16:33 ` Guillaume Tucker
2020-08-14 16:33 ` Guillaume Tucker
2020-08-14 19:33 ` Suman Anna
2020-08-14 19:33 ` Suman Anna
2020-08-20 9:17 ` Guillaume Tucker
2020-08-20 9:17 ` Guillaume Tucker
2020-07-09 23:19 ` [PATCH 07/13] ARM: dts: omap4-panda-common:: Add system timers to DSP and IPU Suman Anna
2020-07-09 23:19 ` Suman Anna
2020-07-09 23:19 ` [PATCH 08/13] ARM: dts: omap5: Add DSP and IPU nodes Suman Anna
2020-07-09 23:19 ` Suman Anna
2020-07-09 23:19 ` [PATCH 09/13] ARM: dts: omap5: Add aliases for rproc nodes Suman Anna
2020-07-09 23:19 ` Suman Anna
2020-07-09 23:19 ` [PATCH 10/13] ARM: dts: omap5-uevm: Add CMA pools and enable IPU & DSP Suman Anna
2020-07-09 23:19 ` Suman Anna
2020-07-09 23:19 ` [PATCH 11/13] ARM: dts: omap5-uevm: Add system timers to DSP and IPU Suman Anna
2020-07-09 23:19 ` Suman Anna
2020-07-09 23:19 ` [PATCH 12/13] ARM: dts: omap4-panda-common: Add watchdog timers for IPU and DSP Suman Anna
2020-07-09 23:19 ` Suman Anna
2020-07-09 23:19 ` [PATCH 13/13] ARM: dts: omap5-uevm: " Suman Anna
2020-07-09 23:19 ` Suman Anna
2020-07-10 16:58 ` [PATCH 00/13] Add IPU & DSP remoteprocs on OMAP4 and OMAP5 Tony Lindgren
2020-07-10 16:58 ` Tony Lindgren
2020-07-10 17:17 ` Suman Anna
2020-07-10 17:17 ` Suman Anna
2020-07-10 17:28 ` Suman Anna
2020-07-10 17:28 ` Suman Anna
2020-07-10 17:59 ` Tony Lindgren
2020-07-10 17:59 ` Tony Lindgren
2020-07-10 18:29 ` Suman Anna
2020-07-10 18:29 ` Suman Anna
2020-07-10 20:45 ` Suman Anna
2020-07-10 20:45 ` Suman Anna
2020-07-10 22:08 ` Tony Lindgren
2020-07-10 22:08 ` Tony Lindgren
2020-07-10 17:40 ` Tony Lindgren
2020-07-10 17:40 ` Tony Lindgren
2020-07-10 18:24 ` Suman Anna [this message]
2020-07-10 18:24 ` Suman Anna
2020-07-13 18:24 ` Tony Lindgren
2020-07-13 18:24 ` Tony Lindgren
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=d9f5dab4-a588-2dda-6d95-7e0c9c5f6b14@ti.com \
--to=s-anna@ti.com \
--cc=devicetree@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=t-kristo@ti.com \
--cc=tony@atomide.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.