Re: oprofile and ARM A9 hardware counter |
|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- Subject: Re: oprofile and ARM A9 hardware counter
- From: "Shilimkar, Santosh" <santosh.shilimkar@xxxxxx>
- Date: Wed, 18 Jan 2012 12:39:40 +0100
- Cc: eranian@xxxxxxxxx, Will Deacon <will.deacon@xxxxxxx>, Maynard Johnson <maynardj@xxxxxxxxxx>, Lik Lik <lik88888@xxxxxxxxx>, "oprofile-list@xxxxxxxxxxxxxxxxxxxxx" <oprofile-list@xxxxxxxxxxxxxxxxxxxxx>, linux-omap@xxxxxxxxxxxxxxx, linux-arm-kernel@xxxxxxxxxxxxxxxxxxx, "Cousson, Benoit" <b-cousson@xxxxxx>, Paul Walmsley <paul@xxxxxxxxx>
- In-reply-to: <CACVXFVMH9WZDqs-mVjxL=1FY12uHyQAJMTCQuU5ru1wQT+YnZg@mail.gmail.com>
On Wed, Jan 18, 2012 at 10:33 AM, Ming Lei <ming.lei@xxxxxxxxxxxxx> wrote:
> Hi Will and stephane,
>
> On Wed, Jan 18, 2012 at 12:18 PM, Ming Lei <ming.lei@xxxxxxxxxxxxx> wrote:
>> Hi stephane & Will,
>>
>> On Tue, Jan 10, 2012 at 8:46 AM, stephane eranian
>> <eranian@xxxxxxxxxxxxxx> wrote:
>>> See the dmesg from my 3.2 kernel:
>>>
>>>
>>> [ 0.000000] Booting Linux on physical CPU 0[ 0.000000]
>
> But if you test omap4 perf against -next kernel, pmu won't work because
> the commit[1] may put 'emu_sys_clkdm' clock domain into HW_AUTO mode,
> so writing pmu register may not take effect.
>
> I have found the similar problem on cam clock domain before[2].
> CD_EMU is very simliar with CD_CAM in the point below:
>
> CD_EMU has no static or module wake-up dependency with any other clock
> domain of the device.[3]
>
> So the patch[4] can make omap4 pmu work on -next tree.
>
> Shilimkar, care to comment on the patch[4]?
>
> thanks,
> --
> Ming Lei
>
> [1], commit 3c50729b3fa1cd8ca1f347e6caf1081204cf1a7c
> Author: Santosh Shilimkar <santosh.shilimkar@xxxxxx>
> Date: Wed Jan 5 22:03:17 2011 +0530
>
> ARM: OMAP4: PM: Initialise all the clockdomains to supported states
>
> Initialise hardware supervised mode for all clockdomains if it's
> supported. Initiate sleep transition for other clockdomains,
> if they are not being used.
>
> [2], http://www.spinics.net/lists/linux-omap/msg61911.html
>
> [3], 3.6.12.3 of OMAP4 TRM
>
> [4],
> diff --git a/arch/arm/mach-omap2/clockdomains44xx_data.c
> b/arch/arm/mach-omap2/clockdomains44xx_data.c
> index 9299ac2..41d2260 100644
> --- a/arch/arm/mach-omap2/clockdomains44xx_data.c
> +++ b/arch/arm/mach-omap2/clockdomains44xx_data.c
> @@ -390,7 +390,7 @@ static struct clockdomain emu_sys_44xx_clkdm = {
> .prcm_partition = OMAP4430_PRM_PARTITION,
> .cm_inst = OMAP4430_PRM_EMU_CM_INST,
> .clkdm_offs = OMAP4430_PRM_EMU_CM_EMU_CDOFFS,
> - .flags = CLKDM_CAN_HWSUP,
> + .flags = CLKDM_CAN_SWSUP,
> };
NAK.
You don't need this patch. What you saw on CAMERA was indeed
a known bug but emulation domain has no such issues.
So the accesses to emulation register should continue to work
with the clock-domain being kept under hardware supervision.
Regards
Santosh
--
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
[Linux Arm (vger)]
[ARM Kernel]
[ARM MSM]
[Linux Tegra]
[Maemo Users]
[Linux USB Devel]
[Video for Linux]
[Linux Audio Users]
[Photo]
[Yosemite News]
[Yosemite Photos]
[Free Online Dating]
[Linux Kernel]
[Linux SCSI]
[XFree86]