From: Nishanth Menon <menon.nishanth@gmail.com>
To: Nishanth Menon <nm@ti.com>, Tony Lindgren <tony@atomide.com>,
Kevin Hilman <khilman@deeprootsystems.com>,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
Woodruff, Richard
Subject: Re: [PATCH] save and restore etm state across core OFF modes
Date: Wed, 13 Jan 2010 06:58:28 -0600 [thread overview]
Message-ID: <4B4DC374.1010909@gmail.com> (raw)
In-Reply-To: <20100113113616.GI29059@shisha.kicks-ass.net>
Alexander Shishkin said the following on 01/13/2010 05:36 AM:
> On Tue, Jan 12, 2010 at 04:08:23 -0600, Nishanth Menon wrote:
>
>> Alexander Shishkin had written, on 01/12/2010 03:46 PM, the following:
>>
>>> On Tue, Jan 12, 2010 at 01:04:04 -0800, Tony Lindgren wrote:
>>>
>>>> * Nishanth Menon <nm@ti.com> [100112 09:31]:
>>>>
>>>>> Alexander Shishkin had written, on 01/12/2010 11:30 AM, the following:
>>>>>
>>>>>> On Tue, Jan 12, 2010 at 11:13:13 -0600, Nishanth Menon wrote:
>>>>>>
>>>>>>> Alexander Shishkin had written, on 01/12/2010 11:04 AM, the following:
>>>>>>>
>>>>>>>> diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
>>>>>>>> index 69521be..0a5ec86 100644
>>>>>>>> --- a/arch/arm/mach-omap2/sleep34xx.S
>>>>>>>> +++ b/arch/arm/mach-omap2/sleep34xx.S
>>>>>>>>
>>>>> [...]
>>>>>
>>>>>>>> /* Store current cpsr*/
>>>>>>>> mrs r2, cpsr
>>>>>>>> stmia r8!, {r2}
>>>>>>>> @@ -520,6 +616,7 @@ clean_caches:
>>>>>>>> cmp r9, #1 /* Check whether L2 inval is required or not*/
>>>>>>>> bne skip_l2_inval
>>>>>>>> clean_l2:
>>>>>>>> +#if 0
>>>>>>>>
>>>>>>> my aversion to #if 0 kicks in here :(.. do we have an alternative
>>>>>>> like using the CONFIG_ENABLE_OFF_MODE_JTAG_ETM_DEBUG or something
>>>>>>> else?
>>>>>>>
>>>>>> Fair enough. I could replace it with "#if !defined(...)" as the first
>>>>>> thing that comes to mind. This way it will only take disabling the
>>>>>> config option to catch any possible regressions in between. Does this
>>>>>> sound reasonable?
>>>>>>
>>>>> sounds ok to me.. unless folks have ideas coz of clean_l2 label..
>>>>> more comments might be useful before a rev2 of the patch..
>>>>>
>>>> The best solution would be to be able to toggle this via sysfs or
>>>> debugfs by swapping the sram code for idle loop when JTAG support
>>>> is needed.
>>>>
>>> Well, if you say, compile the ETM driver in, this will be needed most of
>>> the time.
>>>
>>>
>> I can think of reasons for an against a sysfs entry (as part of
>> discussion -warning lot of self contradictions below- but I think
>> might save a bit of back and froth ;)):
>>
>> for sysfs entry:
>> a) save and restore will have additional latency when you save a
>> chunk such as EMU domain regs - this will not be needed in
>> production phones, disabling it might pop up surprises
>> counter: having a disabled defconfig allows relevant folks to
>> enable on a need basis
>> counter to counter: what do you do when a user reports
>> an issue in a release and you'd want to debug it with
>> ETM on his platform other than doing a rebuild?
>>
>
> Well, my intention is to have it enabled for most of the cases only having
> it disabled for testing purposes.
>
with a sysfs you can go either way, with proper #ifdeferry, you can get
the best of all worlds I guess.. I know in one of the products, a
similar patch was not taken in due to introduction of additional
scratchpad space and latencies - so there are folks who would like this
and those who would like to see this not present in the binary they
flash to thier device.
>
>> b) mostly a debug support -> only for blokes using ETM/JTAG
>> interfaces - not everyone can afford these (no offense to openOCD
>> guys - but they are still a bit away from being able to debug kernel
>> yet on OMAP)..
>>
>
> Not really, you can still make use of ETM without any additional hardware
> attached.
For the unitiated (like me) link from Alex's offline email[1].
Regards,
Nishanth Menon
[1]
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c5d6c7708c3e58015b2e4e13e6cea02c8567a94e
next prev parent reply other threads:[~2010-01-13 12:58 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-12 17:04 [PATCH] save and restore etm state across core OFF modes Alexander Shishkin
2010-01-12 17:13 ` Nishanth Menon
2010-01-12 17:30 ` Alexander Shishkin
2010-01-12 17:33 ` Nishanth Menon
2010-01-12 21:04 ` Tony Lindgren
2010-01-12 21:46 ` Alexander Shishkin
2010-01-12 22:08 ` Nishanth Menon
2010-01-12 22:15 ` Tony Lindgren
2010-01-12 22:53 ` Nishanth Menon
2010-05-01 17:24 ` Alexander Shishkin
2010-01-13 11:36 ` Alexander Shishkin
2010-01-13 12:58 ` Nishanth Menon [this message]
2010-01-18 10:46 ` Alexander Shishkin
2010-01-18 13:47 ` Nishanth Menon
2010-01-12 22:02 ` Kevin Hilman
-- strict thread matches above, loose matches on Subject: below --
2010-07-25 18:34 [PATCH 6/7] " Hari Kanigeri
2010-07-25 21:15 ` [PATCH] " Alexander Shishkin
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=4B4DC374.1010909@gmail.com \
--to=menon.nishanth@gmail.com \
--cc=khilman@deeprootsystems.com \
--cc=linux-omap@vger.kernel.org \
--cc=nm@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox