Re: oprofile and ARM A9 hardware counter

Re: oprofile and ARM A9 hardware counter

[Will Deacon]

On Mon, Jan 09, 2012 at 04:39:09PM +0000, Maynard Johnson wrote:
> On 01/08/2012 8:58 PM, Lik Lik wrote:
> > Hi all,

Hi guys [adding a bunch of people to CC because this issue is really
annoying me now],

> > I am an oprofile user and I need to profile one of my applications on a TI OMAP4
> > platform (pandaboard, to be specific). I have ubuntu 11.10 installed. My problem
> > is that oprofile always use the timer interrupt mode but doesn't recognize the
> > hardware counters, which I am sure my platform has.

First and foremost, we can't currently generate PMU interrupts on OMAP4 in
mainline. There are some additional patches required for these to work:

http://marc.info/?l=linux-arm-kernel&m=131946761428296&w=2

However, as Stephane has pointed out here:

http://marc.info/?l=linux-omap&m=132585784125352&w=2

the interrupts still don't seem to work, even with the patches above
applied.

Ming Lei doesn't seem to be replying to email anymore, so maybe somebody
else on linux-omap could please help us? I'm hoping that we're just missing
some patches from somewhere, but it would be great if somebody could verify
this (and indeed, verify that the interrupts we're registering in the thread
above look sane).

> OProfile userspace support for ARM Cortex-A9 was added by Will Deacon in June 
> 2010.  This support is available in OProfile 0.9.7.  According to Will's 
> posting, the kernel support was due to be added to Ubuntu Maverick, so I would 
> expect your version should support CA9 out of the box.  If not already using 
> oprofile 0.9.7, please upgrade to that version and retry.  If it still doesn't 
> work, please re-post with complete information (kernel version, oprofile command 
> output, and contents of /dev/oprofile/cpu_type).

If with the latest OProfile, `timer mode' is still reported then you should
check that you have CONFIG_HW_PERF_EVENTS enabled in your kernel. It still
won't work though, because of the problems I mentioned above.

Cheers,

Will

oprofile and ARM A9 hardware counter

[Will Deacon]

On Mon, Jan 09, 2012 at 04:39:09PM +0000, Maynard Johnson wrote:
> On 01/08/2012 8:58 PM, Lik Lik wrote:
> > Hi all,

Hi guys [adding a bunch of people to CC because this issue is really
annoying me now],

> > I am an oprofile user and I need to profile one of my applications on a TI OMAP4
> > platform (pandaboard, to be specific). I have ubuntu 11.10 installed. My problem
> > is that oprofile always use the timer interrupt mode but doesn't recognize the
> > hardware counters, which I am sure my platform has.

First and foremost, we can't currently generate PMU interrupts on OMAP4 in
mainline. There are some additional patches required for these to work:

http://marc.info/?l=linux-arm-kernel&m=131946761428296&w=2

However, as Stephane has pointed out here:

http://marc.info/?l=linux-omap&m=132585784125352&w=2

the interrupts still don't seem to work, even with the patches above
applied.

Ming Lei doesn't seem to be replying to email anymore, so maybe somebody
else on linux-omap could please help us? I'm hoping that we're just missing
some patches from somewhere, but it would be great if somebody could verify
this (and indeed, verify that the interrupts we're registering in the thread
above look sane).

> OProfile userspace support for ARM Cortex-A9 was added by Will Deacon in June 
> 2010.  This support is available in OProfile 0.9.7.  According to Will's 
> posting, the kernel support was due to be added to Ubuntu Maverick, so I would 
> expect your version should support CA9 out of the box.  If not already using 
> oprofile 0.9.7, please upgrade to that version and retry.  If it still doesn't 
> work, please re-post with complete information (kernel version, oprofile command 
> output, and contents of /dev/oprofile/cpu_type).

If with the latest OProfile, `timer mode' is still reported then you should
check that you have CONFIG_HW_PERF_EVENTS enabled in your kernel. It still
won't work though, because of the problems I mentioned above.

Cheers,

Will

Re: oprofile and ARM A9 hardware counter

[Ming Lei]

Hi,

On Tue, Jan 10, 2012 at 6:49 AM, Will Deacon <will.deacon@arm.com> wrote:
> On Mon, Jan 09, 2012 at 04:39:09PM +0000, Maynard Johnson wrote:
>> On 01/08/2012 8:58 PM, Lik Lik wrote:
>> > Hi all,
>
> Hi guys [adding a bunch of people to CC because this issue is really
> annoying me now],
>
>> > I am an oprofile user and I need to profile one of my applications on a TI OMAP4
>> > platform (pandaboard, to be specific). I have ubuntu 11.10 installed. My problem
>> > is that oprofile always use the timer interrupt mode but doesn't recognize the
>> > hardware counters, which I am sure my platform has.
>
> First and foremost, we can't currently generate PMU interrupts on OMAP4 in
> mainline. There are some additional patches required for these to work:
>
> http://marc.info/?l=linux-arm-kernel&m=131946761428296&w=2
>
> However, as Stephane has pointed out here:
>
> http://marc.info/?l=linux-omap&m=132585784125352&w=2
>
> the interrupts still don't seem to work, even with the patches above
> applied.
>
> Ming Lei doesn't seem to be replying to email anymore, so maybe somebody

Sorry, I am on a trip now and no pandboard at my hand, so I may have
time to verify
the latest mainline next week after I return home.

I remembered that last time I verified these patches on 3.2-rc2 and
3.2-rc2 next tree,
and perf did work well on my pandaboard.

Also seems there were reports that omap4 perf may not work on some specific
uboot version even with these patches.

> else on linux-omap could please help us? I'm hoping that we're just missing
> some patches from somewhere, but it would be great if somebody could verify
> this (and indeed, verify that the interrupts we're registering in the thread
> above look sane).
>
>> OProfile userspace support for ARM Cortex-A9 was added by Will Deacon in June
>> 2010.  This support is available in OProfile 0.9.7.  According to Will's
>> posting, the kernel support was due to be added to Ubuntu Maverick, so I would
>> expect your version should support CA9 out of the box.  If not already using
>> oprofile 0.9.7, please upgrade to that version and retry.  If it still doesn't
>> work, please re-post with complete information (kernel version, oprofile command
>> output, and contents of /dev/oprofile/cpu_type).
>
> If with the latest OProfile, `timer mode' is still reported then you should
> check that you have CONFIG_HW_PERF_EVENTS enabled in your kernel. It still
> won't work though, because of the problems I mentioned above.

If debug message from 'dmesg' can be provided, maybe we can find clue
about the problem.

thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

oprofile and ARM A9 hardware counter

[Ming Lei]

Hi,

On Tue, Jan 10, 2012 at 6:49 AM, Will Deacon <will.deacon@arm.com> wrote:
> On Mon, Jan 09, 2012 at 04:39:09PM +0000, Maynard Johnson wrote:
>> On 01/08/2012 8:58 PM, Lik Lik wrote:
>> > Hi all,
>
> Hi guys [adding a bunch of people to CC because this issue is really
> annoying me now],
>
>> > I am an oprofile user and I need to profile one of my applications on a TI OMAP4
>> > platform (pandaboard, to be specific). I have ubuntu 11.10 installed. My problem
>> > is that oprofile always use the timer interrupt mode but doesn't recognize the
>> > hardware counters, which I am sure my platform has.
>
> First and foremost, we can't currently generate PMU interrupts on OMAP4 in
> mainline. There are some additional patches required for these to work:
>
> http://marc.info/?l=linux-arm-kernel&m=131946761428296&w=2
>
> However, as Stephane has pointed out here:
>
> http://marc.info/?l=linux-omap&m=132585784125352&w=2
>
> the interrupts still don't seem to work, even with the patches above
> applied.
>
> Ming Lei doesn't seem to be replying to email anymore, so maybe somebody

Sorry, I am on a trip now and no pandboard at my hand, so I may have
time to verify
the latest mainline next week after I return home.

I remembered that last time I verified these patches on 3.2-rc2 and
3.2-rc2 next tree,
and perf did work well on my pandaboard.

Also seems there were reports that omap4 perf may not work on some specific
uboot version even with these patches.

> else on linux-omap could please help us? I'm hoping that we're just missing
> some patches from somewhere, but it would be great if somebody could verify
> this (and indeed, verify that the interrupts we're registering in the thread
> above look sane).
>
>> OProfile userspace support for ARM Cortex-A9 was added by Will Deacon in June
>> 2010. ?This support is available in OProfile 0.9.7. ?According to Will's
>> posting, the kernel support was due to be added to Ubuntu Maverick, so I would
>> expect your version should support CA9 out of the box. ?If not already using
>> oprofile 0.9.7, please upgrade to that version and retry. ?If it still doesn't
>> work, please re-post with complete information (kernel version, oprofile command
>> output, and contents of /dev/oprofile/cpu_type).
>
> If with the latest OProfile, `timer mode' is still reported then you should
> check that you have CONFIG_HW_PERF_EVENTS enabled in your kernel. It still
> won't work though, because of the problems I mentioned above.

If debug message from 'dmesg' can be provided, maybe we can find clue
about the problem.

thanks,
--
Ming Lei

Re: oprofile and ARM A9 hardware counter

[stephane eranian]

See the dmesg from my 3.2 kernel:


[    0.000000] Booting Linux on physical CPU 0[    0.000000]
Initializing cgroup subsys cpuset[    0.000000] Initializing cgroup
subsys cpu[    0.000000] Linux version 3.2.0-omap4 (eranian@panda)
(gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3) ) #9 SMP PR[
0.000000] CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7),
cr=10c5387d[    0.000000] CPU: PIPT / VIPT nonaliasing data cache,
VIPT aliasing instruction cache[    0.000000] Machine: OMAP4 Panda
board[    0.000000] Reserving 33554432 bytes SDRAM for VRAM[
0.000000] Memory policy: ECC disabled, Data cache writealloc[
0.000000] On node 0 totalpages: 239616[    0.000000]
free_area_init_node: node 0, pgdat c077c180, node_mem_map c07f4000[
0.000000]   Normal zone: 1536 pages used for memmap[    0.000000]
Normal zone: 0 pages reserved[    0.000000]   Normal zone: 180736
pages, LIFO batch:31[    0.000000]   HighMem zone: 512 pages used for
memmap[    0.000000]   HighMem zone: 56832 pages, LIFO batch:15[
0.000000] OMAP4430 ES2.2[    0.000000] PERCPU: Embedded 8 pages/cpu
@c0ffc000 s10240 r8192 d14336 u32768[    0.000000] pcpu-alloc: s10240
r8192 d14336 u32768 alloc=8*4096[    0.000000] pcpu-alloc: [0] 0 [0]
1[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.
 Total pages: 237568[    0.000000] Kernel command line: ro
elevator=noop vram=32M mem=456M@0x80000000 mem=512M@0xA0000000
root=UUID=ec3f7a[    0.000000] PID hash table entries: 4096 (order: 2,
16384 bytes)[    0.000000] Dentry cache hash table entries: 131072
(order: 7, 524288 bytes)[    0.000000] Inode-cache hash table entries:
65536 (order: 6, 262144 bytes)[    0.000000] allocated 4194304 bytes
of page_cgroup[    0.000000] please try 'cgroup_disable=memory' option
if you don't want memory cgroups[    0.000000] Memory: 456MB 480MB =
936MB total[    0.000000] Memory: 934980k/934980k available, 56252k
reserved, 229376K highmem[    0.000000] Virtual kernel memory layout:[
   0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)[
0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)[
0.000000]     vmalloc : 0xf0800000 - 0xf8000000   ( 120 MB)[
0.000000]     lowmem  : 0xc0000000 - 0xf0000000   ( 768 MB)[
0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)[
0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)[
0.000000]       .text : 0xc0008000 - 0xc06e1134   (7013 kB)[
0.000000]       .init : 0xc06e2000 - 0xc071e800   ( 242 kB)[
0.000000]       .data : 0xc0720000 - 0xc077ecf0   ( 380 kB)[
0.000000]        .bss : 0xc077ed14 - 0xc07f32ec   ( 466 kB)[
0.000000] SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0,
CPUs=2, Nodes=1[    0.000000] Preemptible hierarchical RCU
implementation.[    0.000000] NR_IRQS:410[    0.000000] omap_hwmod:
dpll_mpu_m2_ck: missing clockdomain for dpll_mpu_m2_ck.[    0.000000]
OMAP clockevent source: GPTIMER1 at 32768 Hz[    0.000000]
sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every
131071999ms[    0.000000] Console: colour dummy device 80x30[
0.000000] console [tty0] enabled[    0.000213] Calibrating delay
loop... 1576.53 BogoMIPS (lpj=6156288)[    0.070373] pid_max: default:
32768 minimum: 301[    0.070617] Security Framework initialized[
0.070678] Smack:  Initializing.[    0.070770] Mount-cache hash table
entries: 512[    0.071807] Initializing cgroup subsys cpuacct[
0.071868] Initializing cgroup subsys memory[    0.071929] Initializing
cgroup subsys devices[    0.071929] Initializing cgroup subsys
freezer[    0.071960] Initializing cgroup subsys blkio[    0.071990]
Initializing cgroup subsys perf_event[    0.072143] CPU: Testing write
buffer coherency: ok[    0.072448] CPU0: thread -1, cpu 0, socket 0,
mpidr 80000000[    0.072509] Calibrating local timer... 386.32MHz.[
0.117462] hw perfevents: enabled with ARMv7 Cortex-A9 PMU driver, 7
counters available[    0.117523] L310 cache controller enabled[
0.117523] l2x0: 16 ways, CACHE_ID 0x410000c4, AUX_CTRL 0x7e470000,
Cache size: 1048576 B[    0.194000] CPU1: Booted secondary processor[
  0.224121] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001[
0.224151] CPU1: Unknown IPI message 0x1[    0.224182] Brought up 2
CPUs[    0.224212] SMP: Total of 2 processors activated (3115.31
BogoMIPS).[    0.225097] devtmpfs: initialized[    0.228820]
omap_hwmod: l3_div_ck: missing clockdomain for l3_div_ck.[
0.231903] omap_hwmod: dmm: _wait_target_disable failed[    0.234497]
omap_hwmod: emif_fw: _wait_target_disable failed[    0.237091]
omap_hwmod: l3_main_1: _wait_target_disable failed[    0.239715]
omap_hwmod: l3_main_2: _wait_target_disable failed[    0.242309]
omap_hwmod: l4_abe: _wait_target_disable failed[    0.244903]
omap_hwmod: l4_cfg: _wait_target_disable failed[    0.247528]
omap_hwmod: l4_per: _wait_target_disable failed[    0.250610]
omap_hwmod: l4_wkup: _wait_target_disable failed[    0.253234]
omap_hwmod: dma_system: _wait_target_disable failed[    0.255889]
omap_hwmod: dss_core: _wait_target_disable failed[    0.258514]
omap_hwmod: dss_dispc: _wait_target_disable failed[    0.261108]
omap_hwmod: dss_dsi1: _wait_target_disable failed[    0.263732]
omap_hwmod: dss_dsi2: _wait_target_disable failed[    0.266326]
omap_hwmod: dss_hdmi: _wait_target_disable failed[    0.268920]
omap_hwmod: dss_rfbi: _wait_target_disable failed[    0.271545]
omap_hwmod: dss_venc: _wait_target_disable failed[    0.275054]
omap_hwmod: mailbox: _wait_target_disable failed[    0.277709]
omap_hwmod: mcpdm: cannot be enabled (3)[    0.280487] omap_hwmod:
spinlock: _wait_target_disable failed[    0.282348] print_constraints:
dummy:[    0.282592] NET: Registered protocol family 16[    0.282775]
GPMC revision 6.0[    0.284332] OMAP GPIO hardware version 0.1
[    0.285552] omap_mux_init: Add partition: #1: core, flags: 2
[    0.286468] omap_mux_init: Add partition: #2: wkup, flags: 2
[    0.291015] hw-breakpoint: found 5 (+1 reserved) breakpoint and 1
watchpoint registers.
[    0.291015] hw-breakpoint: maximum watchpoint size is 4 bytes.
[    0.291595] RES:0 IRQ:33
[    0.291595] RES:1 IRQ:34
[    0.294219] OMAP DMA hardware revision 0.0
[    0.299591] bio: create slab <bio-0> at 0
[    0.300109] print_constraints: vwl1271: 1800 mV
[    0.300994] SCSI subsystem initialized
[    0.301239] usbcore: registered new interface driver usbfs
[    0.301300] usbcore: registered new interface driver hub
[    0.301391] usbcore: registered new device driver usb
[    0.315643] omap_i2c omap_i2c.1: bus 1 rev2.4.0 at 400 kHz
[    0.316131] Skipping twl internal clock init and using bootloader
value (unknown osc rate)
[    0.316619] twl6030: PIH (irq 39) chaining IRQs 368..387
[    0.316986] print_constraints: VUSB: 3300 mV normal standby
[    0.514312] twl6030_usb twl6030_usb: Initialized TWL6030 USB module
[    0.514648] print_constraints: VMMC: 1200 <--> 3000 mV at 3000 mV
normal standby
[    0.515075] print_constraints: VPP: 1800 <--> 2500 mV at 1900 mV
normal standby
[    0.515563] print_constraints: VCXIO: 1800 mV normal standby
[    0.515808] print_constraints: VDAC: 1800 mV normal standby
[    0.516174] print_constraints: VAUX2_6030: 1200 <--> 2800 mV at
1800 mV normal standby
[    0.516601] print_constraints: VAUX3_6030: 1000 <--> 3000 mV at
1200 mV normal standby
[    0.516845] print_constraints: CLK32KG:
[    0.517059] print_constraints: VANA: 2100 mV normal standby
[    0.529052] omap_i2c omap_i2c.2: bus 2 rev2.4.0 at 400 kHz
[    0.544281] omap_i2c omap_i2c.3: bus 3 rev2.4.0 at 100 kHz
[    0.559539] omap_i2c omap_i2c.4: bus 4 rev2.4.0 at 400 kHz
[    0.559997] Advanced Linux Sound Architecture Driver Version 1.0.24.
[    0.560516] Bluetooth: Core ver 2.16
[    0.560577] NET: Registered protocol family 31
[    0.560577] Bluetooth: HCI device and connection manager initialized
[    0.560607] Bluetooth: HCI socket layer initialized
[    0.560821] cfg80211: Calling CRDA to update world regulatory domain
[    0.561523] NetLabel: Initializing
[    0.561523] NetLabel:  domain hash size = 128
[    0.561553] NetLabel:  protocols = UNLABELED CIPSOv4
[    0.561584] NetLabel:  unlabeled traffic allowed by default
[    0.561614] Switching to clocksource 32k_counter
[    0.592681] musb-hdrc: version 6.0, ?dma?, otg (peripheral+host)
[    0.592864] musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk
combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn
[    0.592926] musb-hdrc: MHDRC RTL version 2.0
[    0.592926] musb-hdrc: setup fifo_mode 4
[    0.592956] musb-hdrc: 28/31 max ep, 16384/16384 memory
[    0.593231] musb-hdrc musb-hdrc: USB OTG mode controller at
fc0ab000 using DMA, IRQ 124
[    0.593627] NET: Registered protocol family 2
[    0.593933] IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
[    0.595001] TCP established hash table entries: 131072 (order: 8,
1048576 bytes)
[    0.596923] TCP bind hash table entries: 65536 (order: 7, 786432 bytes)
[    0.598022] TCP: Hash tables configured (established 131072 bind 65536)
[    0.598022] TCP reno registered
[    0.598052] UDP hash table entries: 512 (order: 2, 16384 bytes)
[    0.598083] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
[    0.598449] NET: Registered protocol family 1
[    0.598846] RPC: Registered named UNIX socket transport module.
[    0.598846] RPC: Registered udp transport module.
[    0.598846] RPC: Registered tcp transport module.
[    0.598876] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    0.599121] Trying to unpack rootfs image as initramfs...
[    0.793060] Freeing initrd memory: 2612K
[    0.914703] audit: initializing netlink socket (disabled)
[    0.914764] type=2000 audit(0.921:1): initialized
[    1.053497] highmem bounce pool size: 64 pages
[    1.060485] VFS: Disk quotas dquot_6.5.2
[    1.060913] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[    1.063934] msgmni has been set to 1383
[    1.065399] Block layer SCSI generic (bsg) driver version 0.4
loaded (major 252)
[    1.065429] io scheduler noop registered (default)
[    1.065429] io scheduler deadline registered
[    1.065460] io scheduler cfq registered
[    1.066253] OMAP DSS rev 4.0
[    1.068847] omap_hwmod: dss_core: _wait_target_disable failed
[    1.071716] omap_hwmod: dss_core: _wait_target_disable failed
[    1.074340] omap_hwmod: dss_dispc: _wait_target_disable failed
[    1.077209] omap_hwmod: dss_dispc: _wait_target_disable failed
[    1.079864] omap_hwmod: dss_core: _wait_target_disable failed
[    1.082489] omap_hwmod: dss_dsi1: _wait_target_disable failed
[    1.085266] omap_hwmod: dss_dispc: _wait_target_disable failed
[    1.087890] omap_hwmod: dss_dsi2: _wait_target_disable failed
[    1.091247] omap_hwmod: dss_dispc: _wait_target_disable failed
[    1.093841] omap_hwmod: dss_core: _wait_target_disable failed
[    1.098175] omap_uart.0: ttyO0 at MMIO 0x4806a000 (irq = 104) is a OMAP UART0
[    1.116394] omap_uart.1: ttyO1 at MMIO 0x4806c000 (irq = 105) is a OMAP UART1
[    1.139831] omap_uart.2: ttyO2 at MMIO 0x48020000 (irq = 106) is a OMAP UART2
[    1.257019] omap_uart.3: ttyO3 at MMIO 0x4806e000 (irq = 102) is a OMAP UART3
[    1.382202] [drm] Initialized drm 1.1.0 20060810
[    1.382781] brd: module loaded
[    1.386749] loop: module loaded
[    1.386932] (stk) :sysfs entries created
[    1.386962] (stk) : debugfs entries created
[    1.387573] usbcore: registered new interface driver smsc95xx
[    1.387603] cdc_ncm: 04-Aug-2011
[    1.387695] usbcore: registered new interface driver cdc_ncm
[    1.387786] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    1.387817] ehci_hcd: block sizes: qh 64 qtd 96 itd 160 sitd 96
[    1.387908] _regulator_get: ehci-omap.0 supply hsusb0 not found,
using dummy regulator
[    1.388031] ehci-omap ehci-omap.0: reset hcs_params 0x1313 dbg=0
cc=1 pcc=3 ordered ports=3
[    1.388061] ehci-omap ehci-omap.0: reset hcc_params 20016 thresh 1
uframes 256/512/1024 park LPM
[    1.388061] ehci-omap ehci-omap.0: reset hcc_params 20016 thresh 1
uframes 256/512/1024 park LPM
[    1.388061] ehci-omap ehci-omap.0: OMAP-EHCI Host Controller
[    1.388092] ehci-omap ehci-omap.0: new USB bus registered, assigned
bus number 1
[    1.388214] ehci-omap ehci-omap.0: park 0
[    1.388214] ehci-omap ehci-omap.0: support lpm
[    1.388244] ehci-omap ehci-omap.0: irq 109, io mem 0x4a064c00
[    1.388275] ehci-omap ehci-omap.0: reset command 0080b02  park=3
ithresh=8 period=1024 Reset HALT
[    1.388305] ehci-omap ehci-omap.0: init command 0010005 (park)=0
ithresh=1 period=512 RUN
[    1.397613] ehci-omap ehci-omap.0: USB 2.0 started, EHCI 1.00
[    1.397735] usb usb1: default language 0x0409
[    1.397766] usb usb1: udev 1, busnum 1, minor = 0
[    1.397796] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[    1.397796] usb usb1: New USB device strings: Mfr=3, Product=2,
SerialNumber=1
[    1.397796] usb usb1: Product: OMAP-EHCI Host Controller
[    1.397827] usb usb1: Manufacturer: Linux 3.2.0-omap4 ehci_hcd
[    1.397827] usb usb1: SerialNumber: ehci-omap.0
[    1.398223] usb usb1: usb_probe_device
[    1.398254] usb usb1: configuration #1 chosen from 1 choice
[    1.398284] usb usb1: adding 1-0:1.0 (config #1, interface 0)
[    1.398406] hub 1-0:1.0: usb_probe_interface
[    1.398406] hub 1-0:1.0: usb_probe_interface - got id
[    1.398437] hub 1-0:1.0: USB hub found
[    1.398437] hub 1-0:1.0: 3 ports detected
[    1.398468] hub 1-0:1.0: standalone hub
[    1.398468] hub 1-0:1.0: individual port power switching
[    1.398468] hub 1-0:1.0: individual port over-current protection
[    1.398498] hub 1-0:1.0: power on to power good time: 20ms
[    1.398498] hub 1-0:1.0: local power source is good
[    1.398529] hub 1-0:1.0: enabling power on all ports
[    1.398712] ehci-omap ehci-omap.0: ...powerup ports...
[    1.428924] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    1.428924] ohci_hcd: block sizes: ed 64 td 64
[    1.429046] ohci-omap3 ohci-omap3.0: OMAP3 OHCI Host Controller
[    1.429077] ohci-omap3 ohci-omap3.0: new USB bus registered,
assigned bus number 2
[    1.429077] ohci-omap3 ohci-omap3.0: starting OHCI controller
[    1.429168] ohci-omap3 ohci-omap3.0: created debug files
[    1.429199] ohci-omap3 ohci-omap3.0: irq 108, io mem 0x4a064800
[    1.499206] ehci-omap ehci-omap.0: GetStatus port:1 status 001803 0
 ACK POWER sig=j CSC CONNECT
[    1.499237] hub 1-0:1.0: port 1: status 0501 change 0001
[    1.510986] ohci-omap3 ohci-omap3.0: OHCI controller state
[    1.510986] ohci-omap3 ohci-omap3.0: OHCI 1.0, NO legacy support registers
[    1.511016] ohci-omap3 ohci-omap3.0: control 0x283 RWC
HCFS=operational CBSR=3
[    1.511016] ohci-omap3 ohci-omap3.0: cmdstatus 0x00000 SOC=0
[    1.511047] ohci-omap3 ohci-omap3.0: intrstatus 0x00000004 SF
[    1.511047] ohci-omap3 ohci-omap3.0: intrenable 0x8000005a MIE RHSC UE RD WDH
[    1.511077] ohci-omap3 ohci-omap3.0: hcca frame #0014
[    1.511077] ohci-omap3 ohci-omap3.0: roothub.a 0a000203 POTPGT=10
NPS NDP=3(3)
[    1.511108] ohci-omap3 ohci-omap3.0: roothub.b 00000000 PPCM=0000 DR=0000
[    1.511108] ohci-omap3 ohci-omap3.0: roothub.status 00008000 DRWE
[    1.511108] ohci-omap3 ohci-omap3.0: roothub.portstatus [0] 0x00000100 PPS
[    1.511138] ohci-omap3 ohci-omap3.0: roothub.portstatus [1] 0x00000100 PPS
[    1.511138] ohci-omap3 ohci-omap3.0: roothub.portstatus [2] 0x00000100 PPS
[    1.511199] usb usb2: default language 0x0409
[    1.511230] usb usb2: udev 1, busnum 2, minor = 128
[    1.511230] usb usb2: New USB device found, idVendor=1d6b, idProduct=0001
[    1.511260] usb usb2: New USB device strings: Mfr=3, Product=2,
SerialNumber=1
[    1.511260] usb usb2: Product: OMAP3 OHCI Host Controller
[    1.511291] usb usb2: Manufacturer: Linux 3.2.0-omap4 ohci_hcd
[    1.511291] usb usb2: SerialNumber: ohci-omap3.0
[    1.511627] usb usb2: usb_probe_device
[    1.511627] usb usb2: configuration #1 chosen from 1 choice
[    1.511657] usb usb2: adding 2-0:1.0 (config #1, interface 0)
[    1.511779] hub 2-0:1.0: usb_probe_interface
[    1.511779] hub 2-0:1.0: usb_probe_interface - got id
[    1.511779] hub 2-0:1.0: USB hub found
[    1.511810] hub 2-0:1.0: 3 ports detected
[    1.511810] hub 2-0:1.0: standalone hub
[    1.511840] hub 2-0:1.0: no power switching (usb 1.0)
[    1.511840] hub 2-0:1.0: global over-current protection
[    1.511871] hub 2-0:1.0: power on to power good time: 20ms
[    1.511871] hub 2-0:1.0: local power source is good
[    1.511901] hub 2-0:1.0: no over-current condition exists
[    1.511901] hub 2-0:1.0: trying to enable port power on non-switchable hub
[    1.512176] Initializing USB Mass Storage driver...
[    1.512329] usbcore: registered new interface driver usb-storage
[    1.512359] USB Mass Storage support registered.
[    1.512664] mousedev: PS/2 mouse device common for all mice
[    1.515930] twl_rtc twl_rtc: rtc core: registered twl_rtc as rtc0
[    1.516174] i2c /dev entries driver
[    1.516815] Linux video capture interface: v2.00
[    1.516845] Driver for 1-wire Dallas network protocol.
[    1.516967] 1-Wire driver for the DS2760 battery monitor  chip  -
(c) 2004-2005, Szabolcs Gyurko
[    1.517669] OMAP Watchdog Timer Rev 0x00: initial timeout 60 sec
[    1.517822] Bluetooth: Bluetooth Driver for TI WiLink - Version 1.0
[    1.517913] cpuidle: using governor ladder
[    1.517944] cpuidle: using governor menu
[    1.519592] _regulator_get: omap_hsmmc.0 supply vmmc_aux not found,
using dummy regulator
[    1.522094] _regulator_get: omap_hsmmc.4 supply vmmc_aux not found,
using dummy regulator
[    1.592010] Registered led device: pandaboard::status1
[    1.592102] Registered led device: pandaboard::status2
[    1.592712] omap-iommu omap-iommu.0: ducati registered
[    1.593780] ALSA device list:
[    1.593780]   No soundcards found.
[    1.594940] TCP cubic registered
[    1.595581] NET: Registered protocol family 10
[    1.598114] NET: Registered protocol family 17
[    1.598266] lib80211: common routines for IEEE802.11 drivers
[    1.598297] lib80211_crypt: registered algorithm 'NULL'
[    1.598297] Registering the dns_resolver key type
[    1.598327] VFP support v0.3: implementor 41 architecture 3 part 30
variant 9 rev 1
[    1.598358] ThumbEE CPU extension supported.
[    1.598388] Registering SWP/SWPB emulation handler
[    1.600585] omap_vc_i2c_init: I2C config for all channels must match.
[    1.600616] omap_vc_i2c_init: I2C config for all channels must match.
[    1.600799] hub 1-0:1.0: state 7 ports 3 chg 0002 evt 0000
[    1.600830] hub 1-0:1.0: port 1, status 0501, change 0000, 480 Mb/s
[    1.602111] Power Management for TI OMAP4.
[    1.602142] sr_init: No PMIC hook to init smartreflex
[    1.602294] smartreflex smartreflex.0: omap_sr_probe: SmartReflex
driver initialized
[    1.602416] smartreflex smartreflex.1: omap_sr_probe: SmartReflex
driver initialized
[    1.602539] smartreflex smartreflex.2: omap_sr_probe: SmartReflex
driver initialized
[    1.602691] SmartReflex Class3 initialized
[    1.610168] registered taskstats version 1
[    1.610321] omapfb omapfb: no driver for display: dvi
[    1.623474] omapdss error: timeout reading edid
[    1.629852] omap_hwmod: dss_hdmi: _wait_target_disable failed
[    1.632507] omap_hwmod: dss_dispc: _wait_target_disable failed
[    1.635131] omap_hwmod: dss_core: _wait_target_disable failed
[    1.653015] Console: switching to colour frame buffer device 80x30
[    1.658050] omap_hwmod: dss_dispc: _wait_target_disable failed
[    1.660644] omap_hwmod: dss_core: _wait_target_disable failed
[    1.663421] ehci-omap ehci-omap.0: port 1 high speed
[    1.663452] ehci-omap ehci-omap.0: GetStatus port:1 status 001005 0
 ACK POWER sig=se0 PE CONNECT
[    1.665924] omap_hwmod: dss_dispc: _wait_target_disable failed
[    1.668548] omap_hwmod: dss_core: _wait_target_disable failed
[    1.686309] regulator_init_complete: VANA: incomplete constraints, leaving on
[    1.687469] regulator_init_complete: VDAC: incomplete constraints, leaving on
[    1.688049] regulator_init_complete: VUSB: incomplete constraints, leaving on
[    1.688873] twl_rtc twl_rtc: setting system clock to 2012-01-06
11:35:33 UTC (1325849733)
[    1.689300] Freeing init memory: 240K
[    1.725799] usb 1-1: new high-speed USB device number 2 using ehci-omap
[    1.771179] udevd[68]: starting version 173
[    1.788543] ehci-omap ehci-omap.0: port 1 high speed
[    1.788574] ehci-omap ehci-omap.0: GetStatus port:1 status 001005 0
 ACK POWER sig=se0 PE CONNECT
[    1.882476] usb 1-1: udev 2, busnum 1, minor = 1
[    1.882507] usb 1-1: New USB device found, idVendor=0424, idProduct=9514
[    1.882507] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    1.882934] usb 1-1: usb_probe_device
[    1.882934] usb 1-1: configuration #1 chosen from 1 choice
[    1.883117] usb 1-1: adding 1-1:1.0 (config #1, interface 0)
[    1.883239] hub 1-1:1.0: usb_probe_interface
[    1.883270] hub 1-1:1.0: usb_probe_interface - got id
[    1.883270] hub 1-1:1.0: USB hub found
[    1.883453] hub 1-1:1.0: 5 ports detected
[    1.883453] hub 1-1:1.0: compound device; port removable status: FRRRR
[    1.883483] hub 1-1:1.0: individual port power switching
[    1.883483] hub 1-1:1.0: individual port over-current protection
[    1.883636] hub 1-1:1.0: TT per port
[    1.883666] hub 1-1:1.0: TT requires at most 8 FS bit times (666 ns)
[    1.883666] hub 1-1:1.0: power on to power good time: 100ms
[    1.883941] hub 1-1:1.0: local power source is good
[    1.883972] hub 1-1:1.0: enabling power on all ports
[    1.884674] hub 2-0:1.0: state 7 ports 3 chg 0000 evt 0000
[    1.984588] hub 1-1:1.0: port 1: status 0101 change 0001
[    2.085235] usb 1-1: link qh256-0001/ef2b23c0 start 1 [1/0 us]
[    2.085296] hub 1-1:1.0: state 7 ports 5 chg 0002 evt 0000
[    2.085449] hub 1-1:1.0: port 1, status 0101, change 0000, 12 Mb/s
[    2.104522] mmc0: host does not support reading read-only switch.
assuming write-enable.
[    2.106475] mmc0: new high speed SDHC card at address 0007
[    2.107696] mmcblk0: mmc0:0007 SD08G 7.42 GiB
[    2.111999]  mmcblk0: p1 p2
[    2.171325] usb 1-1.1: new high-speed USB device number 3 using ehci-omap
[    2.291595] usb 1-1.1: udev 3, busnum 1, minor = 2
[    2.291595] usb 1-1.1: New USB device found, idVendor=0424, idProduct=ec00
[    2.291625] usb 1-1.1: New USB device strings: Mfr=0, Product=0,
SerialNumber=0
[    2.291961] usb 1-1.1: usb_probe_device
[    2.291992] usb 1-1.1: configuration #1 chosen from 1 choice
[    2.294281] usb 1-1.1: adding 1-1.1:1.0 (config #1, interface 0)
[    2.294433] smsc95xx 1-1.1:1.0: usb_probe_interface
[    2.294464] smsc95xx 1-1.1:1.0: usb_probe_interface - got id
[    2.294525] smsc95xx v1.0.4
[    2.422302] smsc95xx 1-1.1:1.0: eth0: register 'smsc95xx' at
usb-ehci-omap.0-1.1, smsc95xx USB 2.0 Ethernet, 1a:8b:
[    2.422424] hub 1-1:1.0: state 7 ports 5 chg 0000 evt 0002
[    2.823638] EXT4-fs (mmcblk0p2): mounted filesystem with ordered
data mode. Opts: (null)
[    5.319183] udevd[223]: starting version 173
[    6.641143] usb 1-1.1: link qh8-0001/eecde0c0 start 2 [1/0 us]
[    8.164916] smsc95xx 1-1.1:1.0: eth0: link up, 100Mbps,
full-duplex, lpa 0x45E1
[    8.581451] EXT4-fs (mmcblk0p2): re-mounted. Opts: errors=remount-ro
[    9.204528] init: failsafe main process (513) killed by TERM signal
[   10.159149] init: apport pre-start process (590) terminated with status 1
[   10.171966] init: alsa-restore main process (601) terminated with status 19
[   10.310028] init: apport post-stop process (630) terminated with status 1
[   16.678833] eth0: no IPv6 routers present
[   18.239624] Adding 524240k swap on /SWAP.swap.  Priority:-1
extents:11 across:571384k SS
[  616.003448] omap_hwmod: dss_hdmi: _wait_target_disable failed
[  616.006103] omap_hwmod: dss_dispc: _wait_target_disable failed
[  616.008728] omap_hwmod: dss_core: _wait_target_disable failed

On Tue, Jan 10, 2012 at 12:30 AM, Ming Lei <ming.lei@canonical.com> wrote:
> Hi,
>
> On Tue, Jan 10, 2012 at 6:49 AM, Will Deacon <will.deacon@arm.com> wrote:
>> On Mon, Jan 09, 2012 at 04:39:09PM +0000, Maynard Johnson wrote:
>>> On 01/08/2012 8:58 PM, Lik Lik wrote:
>>> > Hi all,
>>
>> Hi guys [adding a bunch of people to CC because this issue is really
>> annoying me now],
>>
>>> > I am an oprofile user and I need to profile one of my applications on a TI OMAP4
>>> > platform (pandaboard, to be specific). I have ubuntu 11.10 installed. My problem
>>> > is that oprofile always use the timer interrupt mode but doesn't recognize the
>>> > hardware counters, which I am sure my platform has.
>>
>> First and foremost, we can't currently generate PMU interrupts on OMAP4 in
>> mainline. There are some additional patches required for these to work:
>>
>> http://marc.info/?l=linux-arm-kernel&m=131946761428296&w=2
>>
>> However, as Stephane has pointed out here:
>>
>> http://marc.info/?l=linux-omap&m=132585784125352&w=2
>>
>> the interrupts still don't seem to work, even with the patches above
>> applied.
>>
>> Ming Lei doesn't seem to be replying to email anymore, so maybe somebody
>
> Sorry, I am on a trip now and no pandboard at my hand, so I may have
> time to verify
> the latest mainline next week after I return home.
>
> I remembered that last time I verified these patches on 3.2-rc2 and
> 3.2-rc2 next tree,
> and perf did work well on my pandaboard.
>
> Also seems there were reports that omap4 perf may not work on some specific
> uboot version even with these patches.
>
>> else on linux-omap could please help us? I'm hoping that we're just missing
>> some patches from somewhere, but it would be great if somebody could verify
>> this (and indeed, verify that the interrupts we're registering in the thread
>> above look sane).
>>
>>> OProfile userspace support for ARM Cortex-A9 was added by Will Deacon in June
>>> 2010.  This support is available in OProfile 0.9.7.  According to Will's
>>> posting, the kernel support was due to be added to Ubuntu Maverick, so I would
>>> expect your version should support CA9 out of the box.  If not already using
>>> oprofile 0.9.7, please upgrade to that version and retry.  If it still doesn't
>>> work, please re-post with complete information (kernel version, oprofile command
>>> output, and contents of /dev/oprofile/cpu_type).
>>
>> If with the latest OProfile, `timer mode' is still reported then you should
>> check that you have CONFIG_HW_PERF_EVENTS enabled in your kernel. It still
>> won't work though, because of the problems I mentioned above.
>
> If debug message from 'dmesg' can be provided, maybe we can find clue
> about the problem.
>
> thanks,
> --
> Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

oprofile and ARM A9 hardware counter

[stephane eranian]

See the dmesg from my 3.2 kernel:


[ ? ?0.000000] Booting Linux on physical CPU 0[ ? ?0.000000]
Initializing cgroup subsys cpuset[ ? ?0.000000] Initializing cgroup
subsys cpu[ ? ?0.000000] Linux version 3.2.0-omap4 (eranian at panda)
(gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3) ) #9 SMP PR[
0.000000] CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7),
cr=10c5387d[ ? ?0.000000] CPU: PIPT / VIPT nonaliasing data cache,
VIPT aliasing instruction cache[ ? ?0.000000] Machine: OMAP4 Panda
board[ ? ?0.000000] Reserving 33554432 bytes SDRAM for VRAM[
0.000000] Memory policy: ECC disabled, Data cache writealloc[
0.000000] On node 0 totalpages: 239616[ ? ?0.000000]
free_area_init_node: node 0, pgdat c077c180, node_mem_map c07f4000[
0.000000] ? Normal zone: 1536 pages used for memmap[ ? ?0.000000]
Normal zone: 0 pages reserved[ ? ?0.000000] ? Normal zone: 180736
pages, LIFO batch:31[ ? ?0.000000] ? HighMem zone: 512 pages used for
memmap[ ? ?0.000000] ? HighMem zone: 56832 pages, LIFO batch:15[
0.000000] OMAP4430 ES2.2[ ? ?0.000000] PERCPU: Embedded 8 pages/cpu
@c0ffc000 s10240 r8192 d14336 u32768[ ? ?0.000000] pcpu-alloc: s10240
r8192 d14336 u32768 alloc=8*4096[ ? ?0.000000] pcpu-alloc: [0] 0 [0]
1[ ? ?0.000000] Built 1 zonelists in Zone order, mobility grouping on.
?Total pages: 237568[ ? ?0.000000] Kernel command line: ro
elevator=noop vram=32M mem=456M at 0x80000000 mem=512M at 0xA0000000
root=UUID=ec3f7a[ ? ?0.000000] PID hash table entries: 4096 (order: 2,
16384 bytes)[ ? ?0.000000] Dentry cache hash table entries: 131072
(order: 7, 524288 bytes)[ ? ?0.000000] Inode-cache hash table entries:
65536 (order: 6, 262144 bytes)[ ? ?0.000000] allocated 4194304 bytes
of page_cgroup[ ? ?0.000000] please try 'cgroup_disable=memory' option
if you don't want memory cgroups[ ? ?0.000000] Memory: 456MB 480MB =
936MB total[ ? ?0.000000] Memory: 934980k/934980k available, 56252k
reserved, 229376K highmem[ ? ?0.000000] Virtual kernel memory layout:[
? ?0.000000] ? ? vector ?: 0xffff0000 - 0xffff1000 ? ( ? 4 kB)[
0.000000] ? ? fixmap ?: 0xfff00000 - 0xfffe0000 ? ( 896 kB)[
0.000000] ? ? vmalloc : 0xf0800000 - 0xf8000000 ? ( 120 MB)[
0.000000] ? ? lowmem ?: 0xc0000000 - 0xf0000000 ? ( 768 MB)[
0.000000] ? ? pkmap ? : 0xbfe00000 - 0xc0000000 ? ( ? 2 MB)[
0.000000] ? ? modules : 0xbf000000 - 0xbfe00000 ? ( ?14 MB)[
0.000000] ? ? ? .text : 0xc0008000 - 0xc06e1134 ? (7013 kB)[
0.000000] ? ? ? .init : 0xc06e2000 - 0xc071e800 ? ( 242 kB)[
0.000000] ? ? ? .data : 0xc0720000 - 0xc077ecf0 ? ( 380 kB)[
0.000000] ? ? ? ?.bss : 0xc077ed14 - 0xc07f32ec ? ( 466 kB)[
0.000000] SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0,
CPUs=2, Nodes=1[ ? ?0.000000] Preemptible hierarchical RCU
implementation.[ ? ?0.000000] NR_IRQS:410[ ? ?0.000000] omap_hwmod:
dpll_mpu_m2_ck: missing clockdomain for dpll_mpu_m2_ck.[ ? ?0.000000]
OMAP clockevent source: GPTIMER1 at 32768 Hz[ ? ?0.000000]
sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every
131071999ms[ ? ?0.000000] Console: colour dummy device 80x30[
0.000000] console [tty0] enabled[ ? ?0.000213] Calibrating delay
loop... 1576.53 BogoMIPS (lpj=6156288)[ ? ?0.070373] pid_max: default:
32768 minimum: 301[ ? ?0.070617] Security Framework initialized[
0.070678] Smack: ?Initializing.[ ? ?0.070770] Mount-cache hash table
entries: 512[ ? ?0.071807] Initializing cgroup subsys cpuacct[
0.071868] Initializing cgroup subsys memory[ ? ?0.071929] Initializing
cgroup subsys devices[ ? ?0.071929] Initializing cgroup subsys
freezer[ ? ?0.071960] Initializing cgroup subsys blkio[ ? ?0.071990]
Initializing cgroup subsys perf_event[ ? ?0.072143] CPU: Testing write
buffer coherency: ok[ ? ?0.072448] CPU0: thread -1, cpu 0, socket 0,
mpidr 80000000[ ? ?0.072509] Calibrating local timer... 386.32MHz.[
0.117462] hw perfevents: enabled with ARMv7 Cortex-A9 PMU driver, 7
counters available[ ? ?0.117523] L310 cache controller enabled[
0.117523] l2x0: 16 ways, CACHE_ID 0x410000c4, AUX_CTRL 0x7e470000,
Cache size: 1048576 B[ ? ?0.194000] CPU1: Booted secondary processor[
 ?0.224121] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001[
0.224151] CPU1: Unknown IPI message 0x1[ ? ?0.224182] Brought up 2
CPUs[ ? ?0.224212] SMP: Total of 2 processors activated (3115.31
BogoMIPS).[ ? ?0.225097] devtmpfs: initialized[ ? ?0.228820]
omap_hwmod: l3_div_ck: missing clockdomain for l3_div_ck.[
0.231903] omap_hwmod: dmm: _wait_target_disable failed[ ? ?0.234497]
omap_hwmod: emif_fw: _wait_target_disable failed[ ? ?0.237091]
omap_hwmod: l3_main_1: _wait_target_disable failed[ ? ?0.239715]
omap_hwmod: l3_main_2: _wait_target_disable failed[ ? ?0.242309]
omap_hwmod: l4_abe: _wait_target_disable failed[ ? ?0.244903]
omap_hwmod: l4_cfg: _wait_target_disable failed[ ? ?0.247528]
omap_hwmod: l4_per: _wait_target_disable failed[ ? ?0.250610]
omap_hwmod: l4_wkup: _wait_target_disable failed[ ? ?0.253234]
omap_hwmod: dma_system: _wait_target_disable failed[ ? ?0.255889]
omap_hwmod: dss_core: _wait_target_disable failed[ ? ?0.258514]
omap_hwmod: dss_dispc: _wait_target_disable failed[ ? ?0.261108]
omap_hwmod: dss_dsi1: _wait_target_disable failed[ ? ?0.263732]
omap_hwmod: dss_dsi2: _wait_target_disable failed[ ? ?0.266326]
omap_hwmod: dss_hdmi: _wait_target_disable failed[ ? ?0.268920]
omap_hwmod: dss_rfbi: _wait_target_disable failed[ ? ?0.271545]
omap_hwmod: dss_venc: _wait_target_disable failed[ ? ?0.275054]
omap_hwmod: mailbox: _wait_target_disable failed[ ? ?0.277709]
omap_hwmod: mcpdm: cannot be enabled (3)[ ? ?0.280487] omap_hwmod:
spinlock: _wait_target_disable failed[ ? ?0.282348] print_constraints:
dummy:[ ? ?0.282592] NET: Registered protocol family 16[ ? ?0.282775]
GPMC revision 6.0[    0.284332] OMAP GPIO hardware version 0.1
[    0.285552] omap_mux_init: Add partition: #1: core, flags: 2
[    0.286468] omap_mux_init: Add partition: #2: wkup, flags: 2
[    0.291015] hw-breakpoint: found 5 (+1 reserved) breakpoint and 1
watchpoint registers.
[    0.291015] hw-breakpoint: maximum watchpoint size is 4 bytes.
[    0.291595] RES:0 IRQ:33
[    0.291595] RES:1 IRQ:34
[    0.294219] OMAP DMA hardware revision 0.0
[    0.299591] bio: create slab <bio-0> at 0
[    0.300109] print_constraints: vwl1271: 1800 mV
[    0.300994] SCSI subsystem initialized
[    0.301239] usbcore: registered new interface driver usbfs
[    0.301300] usbcore: registered new interface driver hub
[    0.301391] usbcore: registered new device driver usb
[    0.315643] omap_i2c omap_i2c.1: bus 1 rev2.4.0 at 400 kHz
[    0.316131] Skipping twl internal clock init and using bootloader
value (unknown osc rate)
[    0.316619] twl6030: PIH (irq 39) chaining IRQs 368..387
[    0.316986] print_constraints: VUSB: 3300 mV normal standby
[    0.514312] twl6030_usb twl6030_usb: Initialized TWL6030 USB module
[    0.514648] print_constraints: VMMC: 1200 <--> 3000 mV at 3000 mV
normal standby
[    0.515075] print_constraints: VPP: 1800 <--> 2500 mV at 1900 mV
normal standby
[    0.515563] print_constraints: VCXIO: 1800 mV normal standby
[    0.515808] print_constraints: VDAC: 1800 mV normal standby
[    0.516174] print_constraints: VAUX2_6030: 1200 <--> 2800 mV at
1800 mV normal standby
[    0.516601] print_constraints: VAUX3_6030: 1000 <--> 3000 mV at
1200 mV normal standby
[    0.516845] print_constraints: CLK32KG:
[    0.517059] print_constraints: VANA: 2100 mV normal standby
[    0.529052] omap_i2c omap_i2c.2: bus 2 rev2.4.0 at 400 kHz
[    0.544281] omap_i2c omap_i2c.3: bus 3 rev2.4.0 at 100 kHz
[    0.559539] omap_i2c omap_i2c.4: bus 4 rev2.4.0 at 400 kHz
[    0.559997] Advanced Linux Sound Architecture Driver Version 1.0.24.
[    0.560516] Bluetooth: Core ver 2.16
[    0.560577] NET: Registered protocol family 31
[    0.560577] Bluetooth: HCI device and connection manager initialized
[    0.560607] Bluetooth: HCI socket layer initialized
[    0.560821] cfg80211: Calling CRDA to update world regulatory domain
[    0.561523] NetLabel: Initializing
[    0.561523] NetLabel:  domain hash size = 128
[    0.561553] NetLabel:  protocols = UNLABELED CIPSOv4
[    0.561584] NetLabel:  unlabeled traffic allowed by default
[    0.561614] Switching to clocksource 32k_counter
[    0.592681] musb-hdrc: version 6.0, ?dma?, otg (peripheral+host)
[    0.592864] musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk
combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn
[    0.592926] musb-hdrc: MHDRC RTL version 2.0
[    0.592926] musb-hdrc: setup fifo_mode 4
[    0.592956] musb-hdrc: 28/31 max ep, 16384/16384 memory
[    0.593231] musb-hdrc musb-hdrc: USB OTG mode controller at
fc0ab000 using DMA, IRQ 124
[    0.593627] NET: Registered protocol family 2
[    0.593933] IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
[    0.595001] TCP established hash table entries: 131072 (order: 8,
1048576 bytes)
[    0.596923] TCP bind hash table entries: 65536 (order: 7, 786432 bytes)
[    0.598022] TCP: Hash tables configured (established 131072 bind 65536)
[    0.598022] TCP reno registered
[    0.598052] UDP hash table entries: 512 (order: 2, 16384 bytes)
[    0.598083] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
[    0.598449] NET: Registered protocol family 1
[    0.598846] RPC: Registered named UNIX socket transport module.
[    0.598846] RPC: Registered udp transport module.
[    0.598846] RPC: Registered tcp transport module.
[    0.598876] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    0.599121] Trying to unpack rootfs image as initramfs...
[    0.793060] Freeing initrd memory: 2612K
[    0.914703] audit: initializing netlink socket (disabled)
[    0.914764] type=2000 audit(0.921:1): initialized
[    1.053497] highmem bounce pool size: 64 pages
[    1.060485] VFS: Disk quotas dquot_6.5.2
[    1.060913] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[    1.063934] msgmni has been set to 1383
[    1.065399] Block layer SCSI generic (bsg) driver version 0.4
loaded (major 252)
[    1.065429] io scheduler noop registered (default)
[    1.065429] io scheduler deadline registered
[    1.065460] io scheduler cfq registered
[    1.066253] OMAP DSS rev 4.0
[    1.068847] omap_hwmod: dss_core: _wait_target_disable failed
[    1.071716] omap_hwmod: dss_core: _wait_target_disable failed
[    1.074340] omap_hwmod: dss_dispc: _wait_target_disable failed
[    1.077209] omap_hwmod: dss_dispc: _wait_target_disable failed
[    1.079864] omap_hwmod: dss_core: _wait_target_disable failed
[    1.082489] omap_hwmod: dss_dsi1: _wait_target_disable failed
[    1.085266] omap_hwmod: dss_dispc: _wait_target_disable failed
[    1.087890] omap_hwmod: dss_dsi2: _wait_target_disable failed
[    1.091247] omap_hwmod: dss_dispc: _wait_target_disable failed
[    1.093841] omap_hwmod: dss_core: _wait_target_disable failed
[    1.098175] omap_uart.0: ttyO0 at MMIO 0x4806a000 (irq = 104) is a OMAP UART0
[    1.116394] omap_uart.1: ttyO1 at MMIO 0x4806c000 (irq = 105) is a OMAP UART1
[    1.139831] omap_uart.2: ttyO2 at MMIO 0x48020000 (irq = 106) is a OMAP UART2
[    1.257019] omap_uart.3: ttyO3 at MMIO 0x4806e000 (irq = 102) is a OMAP UART3
[    1.382202] [drm] Initialized drm 1.1.0 20060810
[    1.382781] brd: module loaded
[    1.386749] loop: module loaded
[    1.386932] (stk) :sysfs entries created
[    1.386962] (stk) : debugfs entries created
[    1.387573] usbcore: registered new interface driver smsc95xx
[    1.387603] cdc_ncm: 04-Aug-2011
[    1.387695] usbcore: registered new interface driver cdc_ncm
[    1.387786] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    1.387817] ehci_hcd: block sizes: qh 64 qtd 96 itd 160 sitd 96
[    1.387908] _regulator_get: ehci-omap.0 supply hsusb0 not found,
using dummy regulator
[    1.388031] ehci-omap ehci-omap.0: reset hcs_params 0x1313 dbg=0
cc=1 pcc=3 ordered ports=3
[    1.388061] ehci-omap ehci-omap.0: reset hcc_params 20016 thresh 1
uframes 256/512/1024 park LPM
[    1.388061] ehci-omap ehci-omap.0: reset hcc_params 20016 thresh 1
uframes 256/512/1024 park LPM
[    1.388061] ehci-omap ehci-omap.0: OMAP-EHCI Host Controller
[    1.388092] ehci-omap ehci-omap.0: new USB bus registered, assigned
bus number 1
[    1.388214] ehci-omap ehci-omap.0: park 0
[    1.388214] ehci-omap ehci-omap.0: support lpm
[    1.388244] ehci-omap ehci-omap.0: irq 109, io mem 0x4a064c00
[    1.388275] ehci-omap ehci-omap.0: reset command 0080b02  park=3
ithresh=8 period=1024 Reset HALT
[    1.388305] ehci-omap ehci-omap.0: init command 0010005 (park)=0
ithresh=1 period=512 RUN
[    1.397613] ehci-omap ehci-omap.0: USB 2.0 started, EHCI 1.00
[    1.397735] usb usb1: default language 0x0409
[    1.397766] usb usb1: udev 1, busnum 1, minor = 0
[    1.397796] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[    1.397796] usb usb1: New USB device strings: Mfr=3, Product=2,
SerialNumber=1
[    1.397796] usb usb1: Product: OMAP-EHCI Host Controller
[    1.397827] usb usb1: Manufacturer: Linux 3.2.0-omap4 ehci_hcd
[    1.397827] usb usb1: SerialNumber: ehci-omap.0
[    1.398223] usb usb1: usb_probe_device
[    1.398254] usb usb1: configuration #1 chosen from 1 choice
[    1.398284] usb usb1: adding 1-0:1.0 (config #1, interface 0)
[    1.398406] hub 1-0:1.0: usb_probe_interface
[    1.398406] hub 1-0:1.0: usb_probe_interface - got id
[    1.398437] hub 1-0:1.0: USB hub found
[    1.398437] hub 1-0:1.0: 3 ports detected
[    1.398468] hub 1-0:1.0: standalone hub
[    1.398468] hub 1-0:1.0: individual port power switching
[    1.398468] hub 1-0:1.0: individual port over-current protection
[    1.398498] hub 1-0:1.0: power on to power good time: 20ms
[    1.398498] hub 1-0:1.0: local power source is good
[    1.398529] hub 1-0:1.0: enabling power on all ports
[    1.398712] ehci-omap ehci-omap.0: ...powerup ports...
[    1.428924] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    1.428924] ohci_hcd: block sizes: ed 64 td 64
[    1.429046] ohci-omap3 ohci-omap3.0: OMAP3 OHCI Host Controller
[    1.429077] ohci-omap3 ohci-omap3.0: new USB bus registered,
assigned bus number 2
[    1.429077] ohci-omap3 ohci-omap3.0: starting OHCI controller
[    1.429168] ohci-omap3 ohci-omap3.0: created debug files
[    1.429199] ohci-omap3 ohci-omap3.0: irq 108, io mem 0x4a064800
[    1.499206] ehci-omap ehci-omap.0: GetStatus port:1 status 001803 0
 ACK POWER sig=j CSC CONNECT
[    1.499237] hub 1-0:1.0: port 1: status 0501 change 0001
[    1.510986] ohci-omap3 ohci-omap3.0: OHCI controller state
[    1.510986] ohci-omap3 ohci-omap3.0: OHCI 1.0, NO legacy support registers
[    1.511016] ohci-omap3 ohci-omap3.0: control 0x283 RWC
HCFS=operational CBSR=3
[    1.511016] ohci-omap3 ohci-omap3.0: cmdstatus 0x00000 SOC=0
[    1.511047] ohci-omap3 ohci-omap3.0: intrstatus 0x00000004 SF
[    1.511047] ohci-omap3 ohci-omap3.0: intrenable 0x8000005a MIE RHSC UE RD WDH
[    1.511077] ohci-omap3 ohci-omap3.0: hcca frame #0014
[    1.511077] ohci-omap3 ohci-omap3.0: roothub.a 0a000203 POTPGT=10
NPS NDP=3(3)
[    1.511108] ohci-omap3 ohci-omap3.0: roothub.b 00000000 PPCM=0000 DR=0000
[    1.511108] ohci-omap3 ohci-omap3.0: roothub.status 00008000 DRWE
[    1.511108] ohci-omap3 ohci-omap3.0: roothub.portstatus [0] 0x00000100 PPS
[    1.511138] ohci-omap3 ohci-omap3.0: roothub.portstatus [1] 0x00000100 PPS
[    1.511138] ohci-omap3 ohci-omap3.0: roothub.portstatus [2] 0x00000100 PPS
[    1.511199] usb usb2: default language 0x0409
[    1.511230] usb usb2: udev 1, busnum 2, minor = 128
[    1.511230] usb usb2: New USB device found, idVendor=1d6b, idProduct=0001
[    1.511260] usb usb2: New USB device strings: Mfr=3, Product=2,
SerialNumber=1
[    1.511260] usb usb2: Product: OMAP3 OHCI Host Controller
[    1.511291] usb usb2: Manufacturer: Linux 3.2.0-omap4 ohci_hcd
[    1.511291] usb usb2: SerialNumber: ohci-omap3.0
[    1.511627] usb usb2: usb_probe_device
[    1.511627] usb usb2: configuration #1 chosen from 1 choice
[    1.511657] usb usb2: adding 2-0:1.0 (config #1, interface 0)
[    1.511779] hub 2-0:1.0: usb_probe_interface
[    1.511779] hub 2-0:1.0: usb_probe_interface - got id
[    1.511779] hub 2-0:1.0: USB hub found
[    1.511810] hub 2-0:1.0: 3 ports detected
[    1.511810] hub 2-0:1.0: standalone hub
[    1.511840] hub 2-0:1.0: no power switching (usb 1.0)
[    1.511840] hub 2-0:1.0: global over-current protection
[    1.511871] hub 2-0:1.0: power on to power good time: 20ms
[    1.511871] hub 2-0:1.0: local power source is good
[    1.511901] hub 2-0:1.0: no over-current condition exists
[    1.511901] hub 2-0:1.0: trying to enable port power on non-switchable hub
[    1.512176] Initializing USB Mass Storage driver...
[    1.512329] usbcore: registered new interface driver usb-storage
[    1.512359] USB Mass Storage support registered.
[    1.512664] mousedev: PS/2 mouse device common for all mice
[    1.515930] twl_rtc twl_rtc: rtc core: registered twl_rtc as rtc0
[    1.516174] i2c /dev entries driver
[    1.516815] Linux video capture interface: v2.00
[    1.516845] Driver for 1-wire Dallas network protocol.
[    1.516967] 1-Wire driver for the DS2760 battery monitor  chip  -
(c) 2004-2005, Szabolcs Gyurko
[    1.517669] OMAP Watchdog Timer Rev 0x00: initial timeout 60 sec
[    1.517822] Bluetooth: Bluetooth Driver for TI WiLink - Version 1.0
[    1.517913] cpuidle: using governor ladder
[    1.517944] cpuidle: using governor menu
[    1.519592] _regulator_get: omap_hsmmc.0 supply vmmc_aux not found,
using dummy regulator
[    1.522094] _regulator_get: omap_hsmmc.4 supply vmmc_aux not found,
using dummy regulator
[    1.592010] Registered led device: pandaboard::status1
[    1.592102] Registered led device: pandaboard::status2
[    1.592712] omap-iommu omap-iommu.0: ducati registered
[    1.593780] ALSA device list:
[    1.593780]   No soundcards found.
[    1.594940] TCP cubic registered
[    1.595581] NET: Registered protocol family 10
[    1.598114] NET: Registered protocol family 17
[    1.598266] lib80211: common routines for IEEE802.11 drivers
[    1.598297] lib80211_crypt: registered algorithm 'NULL'
[    1.598297] Registering the dns_resolver key type
[    1.598327] VFP support v0.3: implementor 41 architecture 3 part 30
variant 9 rev 1
[    1.598358] ThumbEE CPU extension supported.
[    1.598388] Registering SWP/SWPB emulation handler
[    1.600585] omap_vc_i2c_init: I2C config for all channels must match.
[    1.600616] omap_vc_i2c_init: I2C config for all channels must match.
[    1.600799] hub 1-0:1.0: state 7 ports 3 chg 0002 evt 0000
[    1.600830] hub 1-0:1.0: port 1, status 0501, change 0000, 480 Mb/s
[    1.602111] Power Management for TI OMAP4.
[    1.602142] sr_init: No PMIC hook to init smartreflex
[    1.602294] smartreflex smartreflex.0: omap_sr_probe: SmartReflex
driver initialized
[    1.602416] smartreflex smartreflex.1: omap_sr_probe: SmartReflex
driver initialized
[    1.602539] smartreflex smartreflex.2: omap_sr_probe: SmartReflex
driver initialized
[    1.602691] SmartReflex Class3 initialized
[    1.610168] registered taskstats version 1
[    1.610321] omapfb omapfb: no driver for display: dvi
[    1.623474] omapdss error: timeout reading edid
[    1.629852] omap_hwmod: dss_hdmi: _wait_target_disable failed
[    1.632507] omap_hwmod: dss_dispc: _wait_target_disable failed
[    1.635131] omap_hwmod: dss_core: _wait_target_disable failed
[    1.653015] Console: switching to colour frame buffer device 80x30
[    1.658050] omap_hwmod: dss_dispc: _wait_target_disable failed
[    1.660644] omap_hwmod: dss_core: _wait_target_disable failed
[    1.663421] ehci-omap ehci-omap.0: port 1 high speed
[    1.663452] ehci-omap ehci-omap.0: GetStatus port:1 status 001005 0
 ACK POWER sig=se0 PE CONNECT
[    1.665924] omap_hwmod: dss_dispc: _wait_target_disable failed
[    1.668548] omap_hwmod: dss_core: _wait_target_disable failed
[    1.686309] regulator_init_complete: VANA: incomplete constraints, leaving on
[    1.687469] regulator_init_complete: VDAC: incomplete constraints, leaving on
[    1.688049] regulator_init_complete: VUSB: incomplete constraints, leaving on
[    1.688873] twl_rtc twl_rtc: setting system clock to 2012-01-06
11:35:33 UTC (1325849733)
[    1.689300] Freeing init memory: 240K
[    1.725799] usb 1-1: new high-speed USB device number 2 using ehci-omap
[    1.771179] udevd[68]: starting version 173
[    1.788543] ehci-omap ehci-omap.0: port 1 high speed
[    1.788574] ehci-omap ehci-omap.0: GetStatus port:1 status 001005 0
 ACK POWER sig=se0 PE CONNECT
[    1.882476] usb 1-1: udev 2, busnum 1, minor = 1
[    1.882507] usb 1-1: New USB device found, idVendor=0424, idProduct=9514
[    1.882507] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    1.882934] usb 1-1: usb_probe_device
[    1.882934] usb 1-1: configuration #1 chosen from 1 choice
[    1.883117] usb 1-1: adding 1-1:1.0 (config #1, interface 0)
[    1.883239] hub 1-1:1.0: usb_probe_interface
[    1.883270] hub 1-1:1.0: usb_probe_interface - got id
[    1.883270] hub 1-1:1.0: USB hub found
[    1.883453] hub 1-1:1.0: 5 ports detected
[    1.883453] hub 1-1:1.0: compound device; port removable status: FRRRR
[    1.883483] hub 1-1:1.0: individual port power switching
[    1.883483] hub 1-1:1.0: individual port over-current protection
[    1.883636] hub 1-1:1.0: TT per port
[    1.883666] hub 1-1:1.0: TT requires at most 8 FS bit times (666 ns)
[    1.883666] hub 1-1:1.0: power on to power good time: 100ms
[    1.883941] hub 1-1:1.0: local power source is good
[    1.883972] hub 1-1:1.0: enabling power on all ports
[    1.884674] hub 2-0:1.0: state 7 ports 3 chg 0000 evt 0000
[    1.984588] hub 1-1:1.0: port 1: status 0101 change 0001
[    2.085235] usb 1-1: link qh256-0001/ef2b23c0 start 1 [1/0 us]
[    2.085296] hub 1-1:1.0: state 7 ports 5 chg 0002 evt 0000
[    2.085449] hub 1-1:1.0: port 1, status 0101, change 0000, 12 Mb/s
[    2.104522] mmc0: host does not support reading read-only switch.
assuming write-enable.
[    2.106475] mmc0: new high speed SDHC card at address 0007
[    2.107696] mmcblk0: mmc0:0007 SD08G 7.42 GiB
[    2.111999]  mmcblk0: p1 p2
[    2.171325] usb 1-1.1: new high-speed USB device number 3 using ehci-omap
[    2.291595] usb 1-1.1: udev 3, busnum 1, minor = 2
[    2.291595] usb 1-1.1: New USB device found, idVendor=0424, idProduct=ec00
[    2.291625] usb 1-1.1: New USB device strings: Mfr=0, Product=0,
SerialNumber=0
[    2.291961] usb 1-1.1: usb_probe_device
[    2.291992] usb 1-1.1: configuration #1 chosen from 1 choice
[    2.294281] usb 1-1.1: adding 1-1.1:1.0 (config #1, interface 0)
[    2.294433] smsc95xx 1-1.1:1.0: usb_probe_interface
[    2.294464] smsc95xx 1-1.1:1.0: usb_probe_interface - got id
[    2.294525] smsc95xx v1.0.4
[    2.422302] smsc95xx 1-1.1:1.0: eth0: register 'smsc95xx' at
usb-ehci-omap.0-1.1, smsc95xx USB 2.0 Ethernet, 1a:8b:
[    2.422424] hub 1-1:1.0: state 7 ports 5 chg 0000 evt 0002
[    2.823638] EXT4-fs (mmcblk0p2): mounted filesystem with ordered
data mode. Opts: (null)
[    5.319183] udevd[223]: starting version 173
[    6.641143] usb 1-1.1: link qh8-0001/eecde0c0 start 2 [1/0 us]
[    8.164916] smsc95xx 1-1.1:1.0: eth0: link up, 100Mbps,
full-duplex, lpa 0x45E1
[    8.581451] EXT4-fs (mmcblk0p2): re-mounted. Opts: errors=remount-ro
[    9.204528] init: failsafe main process (513) killed by TERM signal
[   10.159149] init: apport pre-start process (590) terminated with status 1
[   10.171966] init: alsa-restore main process (601) terminated with status 19
[   10.310028] init: apport post-stop process (630) terminated with status 1
[   16.678833] eth0: no IPv6 routers present
[   18.239624] Adding 524240k swap on /SWAP.swap.  Priority:-1
extents:11 across:571384k SS
[  616.003448] omap_hwmod: dss_hdmi: _wait_target_disable failed
[  616.006103] omap_hwmod: dss_dispc: _wait_target_disable failed
[  616.008728] omap_hwmod: dss_core: _wait_target_disable failed

On Tue, Jan 10, 2012 at 12:30 AM, Ming Lei <ming.lei@canonical.com> wrote:
> Hi,
>
> On Tue, Jan 10, 2012 at 6:49 AM, Will Deacon <will.deacon@arm.com> wrote:
>> On Mon, Jan 09, 2012 at 04:39:09PM +0000, Maynard Johnson wrote:
>>> On 01/08/2012 8:58 PM, Lik Lik wrote:
>>> > Hi all,
>>
>> Hi guys [adding a bunch of people to CC because this issue is really
>> annoying me now],
>>
>>> > I am an oprofile user and I need to profile one of my applications on a TI OMAP4
>>> > platform (pandaboard, to be specific). I have ubuntu 11.10 installed. My problem
>>> > is that oprofile always use the timer interrupt mode but doesn't recognize the
>>> > hardware counters, which I am sure my platform has.
>>
>> First and foremost, we can't currently generate PMU interrupts on OMAP4 in
>> mainline. There are some additional patches required for these to work:
>>
>> http://marc.info/?l=linux-arm-kernel&m=131946761428296&w=2
>>
>> However, as Stephane has pointed out here:
>>
>> http://marc.info/?l=linux-omap&m=132585784125352&w=2
>>
>> the interrupts still don't seem to work, even with the patches above
>> applied.
>>
>> Ming Lei doesn't seem to be replying to email anymore, so maybe somebody
>
> Sorry, I am on a trip now and no pandboard at my hand, so I may have
> time to verify
> the latest mainline next week after I return home.
>
> I remembered that last time I verified these patches on 3.2-rc2 and
> 3.2-rc2 next tree,
> and perf did work well on my pandaboard.
>
> Also seems there were reports that omap4 perf may not work on some specific
> uboot version even with these patches.
>
>> else on linux-omap could please help us? I'm hoping that we're just missing
>> some patches from somewhere, but it would be great if somebody could verify
>> this (and indeed, verify that the interrupts we're registering in the thread
>> above look sane).
>>
>>> OProfile userspace support for ARM Cortex-A9 was added by Will Deacon in June
>>> 2010. ?This support is available in OProfile 0.9.7. ?According to Will's
>>> posting, the kernel support was due to be added to Ubuntu Maverick, so I would
>>> expect your version should support CA9 out of the box. ?If not already using
>>> oprofile 0.9.7, please upgrade to that version and retry. ?If it still doesn't
>>> work, please re-post with complete information (kernel version, oprofile command
>>> output, and contents of /dev/oprofile/cpu_type).
>>
>> If with the latest OProfile, `timer mode' is still reported then you should
>> check that you have CONFIG_HW_PERF_EVENTS enabled in your kernel. It still
>> won't work though, because of the problems I mentioned above.
>
> If debug message from 'dmesg' can be provided, maybe we can find clue
> about the problem.
>
> thanks,
> --
> Ming Lei

Re: oprofile and ARM A9 hardware counter

[Ming Lei]

Hi stephane & Will,

On Tue, Jan 10, 2012 at 8:46 AM, stephane eranian
<eranian@googlemail.com> wrote:
> See the dmesg from my 3.2 kernel:
>
>
> [    0.000000] Booting Linux on physical CPU 0[    0.000000]

Looks no obvious failure can be found from your 'dmesg'.

I have run upstream 3.2 kernel plus 6 omap4 pmu patches below and
found perf can work well on my panda board.

	0001-arm-introduce-cross-trigger-interface-helpers.patch
	0002-arm-pmu-allow-platform-specific-irq-enable-disable-h.patch
	0003-arm-omap4-hwmod-introduce-emu-hwmod.patch or Benoit's debugss patch[2]
	0004-arm-omap4-create-pmu-device-via-hwmod.patch[3]
	0005-arm-omap4-support-pmu.patch[4]
	0006-arm-omap4-pmu-support-runtime-pm.patch[5]

Could you verify the above patches on 3.2 to see if perf can work well?
If it doesn't, I may share my u-boot and mlo for your test if you'd like to do.

BTW: #1 and #2 have been in Will's -next tree.

thanks,
--
Ming Lei

[1], uname -a & cat /proc/interrupts
[root@root]#uname -a
Linux beagleboard 3.2.0+ #480 SMP PREEMPT Wed Jan 18 11:38:33 CST 2012
armv7l GNU/Linux
[root@root]#cat /proc/interrupts
           CPU0       CPU1
 29:      29014      17353       GIC  twd
 33:      56231          0       GIC  arm-pmu
 34:          0      25778       GIC  arm-pmu

[2], http://marc.info/?l=linux-omap&m=132162118104901&w=2
[3],http://marc.info/?t=132227621500002&r=1&w=2
[4],http://marc.info/?t=132227621700002&r=1&w=2
[5],http://marc.info/?t=132227621700003&r=1&w=2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

oprofile and ARM A9 hardware counter

[Ming Lei]

Hi stephane & Will,

On Tue, Jan 10, 2012 at 8:46 AM, stephane eranian
<eranian@googlemail.com> wrote:
> See the dmesg from my 3.2 kernel:
>
>
> [ ? ?0.000000] Booting Linux on physical CPU 0[ ? ?0.000000]

Looks no obvious failure can be found from your 'dmesg'.

I have run upstream 3.2 kernel plus 6 omap4 pmu patches below and
found perf can work well on my panda board.

	0001-arm-introduce-cross-trigger-interface-helpers.patch
	0002-arm-pmu-allow-platform-specific-irq-enable-disable-h.patch
	0003-arm-omap4-hwmod-introduce-emu-hwmod.patch or Benoit's debugss patch[2]
	0004-arm-omap4-create-pmu-device-via-hwmod.patch[3]
	0005-arm-omap4-support-pmu.patch[4]
	0006-arm-omap4-pmu-support-runtime-pm.patch[5]

Could you verify the above patches on 3.2 to see if perf can work well?
If it doesn't, I may share my u-boot and mlo for your test if you'd like to do.

BTW: #1 and #2 have been in Will's -next tree.

thanks,
--
Ming Lei

[1], uname -a & cat /proc/interrupts
[root at root]#uname -a
Linux beagleboard 3.2.0+ #480 SMP PREEMPT Wed Jan 18 11:38:33 CST 2012
armv7l GNU/Linux
[root at root]#cat /proc/interrupts
           CPU0       CPU1
 29:      29014      17353       GIC  twd
 33:      56231          0       GIC  arm-pmu
 34:          0      25778       GIC  arm-pmu

[2], http://marc.info/?l=linux-omap&m=132162118104901&w=2
[3],http://marc.info/?t=132227621500002&r=1&w=2
[4],http://marc.info/?t=132227621700002&r=1&w=2
[5],http://marc.info/?t=132227621700003&r=1&w=2

Re: oprofile and ARM A9 hardware counter

[Ming Lei]

Hi Will and stephane,

On Wed, Jan 18, 2012 at 12:18 PM, Ming Lei <ming.lei@canonical.com> wrote:
> Hi stephane & Will,
>
> On Tue, Jan 10, 2012 at 8:46 AM, stephane eranian
> <eranian@googlemail.com> 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@ti.com>
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,
 };

 static struct clockdomain l3_dma_44xx_clkdm = {
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

oprofile and ARM A9 hardware counter

[Ming Lei]

Hi Will and stephane,

On Wed, Jan 18, 2012 at 12:18 PM, Ming Lei <ming.lei@canonical.com> wrote:
> Hi stephane & Will,
>
> On Tue, Jan 10, 2012 at 8:46 AM, stephane eranian
> <eranian@googlemail.com> 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@ti.com>
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,
 };

 static struct clockdomain l3_dma_44xx_clkdm = {

Re: oprofile and ARM A9 hardware counter

[Shilimkar, Santosh]

On Wed, Jan 18, 2012 at 10:33 AM, Ming Lei <ming.lei@canonical.com> wrote:
> Hi Will and stephane,
>
> On Wed, Jan 18, 2012 at 12:18 PM, Ming Lei <ming.lei@canonical.com> wrote:
>> Hi stephane & Will,
>>
>> On Tue, Jan 10, 2012 at 8:46 AM, stephane eranian
>> <eranian@googlemail.com> 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@ti.com>
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

oprofile and ARM A9 hardware counter

[Shilimkar, Santosh]

On Wed, Jan 18, 2012 at 10:33 AM, Ming Lei <ming.lei@canonical.com> wrote:
> Hi Will and stephane,
>
> On Wed, Jan 18, 2012 at 12:18 PM, Ming Lei <ming.lei@canonical.com> wrote:
>> Hi stephane & Will,
>>
>> On Tue, Jan 10, 2012 at 8:46 AM, stephane eranian
>> <eranian@googlemail.com> 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@ti.com>
> 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

Re: oprofile and ARM A9 hardware counter

[Ming Lei]

On Wed, Jan 18, 2012 at 7:39 PM, Shilimkar, Santosh
<santosh.shilimkar@ti.com> wrote:
> On Wed, Jan 18, 2012 at 10:33 AM, Ming Lei <ming.lei@canonical.com> wrote:
>> Hi Will and stephane,
>>
>> On Wed, Jan 18, 2012 at 12:18 PM, Ming Lei <ming.lei@canonical.com> wrote:
>>> Hi stephane & Will,
>>>
>>> On Tue, Jan 10, 2012 at 8:46 AM, stephane eranian
>>> <eranian@googlemail.com> 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@ti.com>
>> 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.

But why can this patch make omap4 pmu work?  Without the patch,
there are no CTI interrupts generated for pmu irq.

thanks
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

oprofile and ARM A9 hardware counter

[Ming Lei]

On Wed, Jan 18, 2012 at 7:39 PM, Shilimkar, Santosh
<santosh.shilimkar@ti.com> wrote:
> On Wed, Jan 18, 2012 at 10:33 AM, Ming Lei <ming.lei@canonical.com> wrote:
>> Hi Will and stephane,
>>
>> On Wed, Jan 18, 2012 at 12:18 PM, Ming Lei <ming.lei@canonical.com> wrote:
>>> Hi stephane & Will,
>>>
>>> On Tue, Jan 10, 2012 at 8:46 AM, stephane eranian
>>> <eranian@googlemail.com> 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@ti.com>
>> 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.

But why can this patch make omap4 pmu work?  Without the patch,
there are no CTI interrupts generated for pmu irq.

thanks
--
Ming Lei

Re: oprofile and ARM A9 hardware counter

[Shilimkar, Santosh]

On Wed, Jan 18, 2012 at 1:24 PM, Ming Lei <ming.lei@canonical.com> wrote:
> On Wed, Jan 18, 2012 at 7:39 PM, Shilimkar, Santosh
> <santosh.shilimkar@ti.com> wrote:
>> On Wed, Jan 18, 2012 at 10:33 AM, Ming Lei <ming.lei@canonical.com> wrote:
>>> Hi Will and stephane,
>>>
>>> On Wed, Jan 18, 2012 at 12:18 PM, Ming Lei <ming.lei@canonical.com> wrote:
>>>> Hi stephane & Will,
>>>>
>>>> On Tue, Jan 10, 2012 at 8:46 AM, stephane eranian
>>>> <eranian@googlemail.com> 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@ti.com>
>>> 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.
>
> But why can this patch make omap4 pmu work?  Without the patch,
> there are no CTI interrupts generated for pmu irq.
>
Interesting. For me debugger works which also relies on Emulation domain.

Need to see why CTI is behaving like this.

Regards
Santosh
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

oprofile and ARM A9 hardware counter

[Shilimkar, Santosh]

On Wed, Jan 18, 2012 at 1:24 PM, Ming Lei <ming.lei@canonical.com> wrote:
> On Wed, Jan 18, 2012 at 7:39 PM, Shilimkar, Santosh
> <santosh.shilimkar@ti.com> wrote:
>> On Wed, Jan 18, 2012 at 10:33 AM, Ming Lei <ming.lei@canonical.com> wrote:
>>> Hi Will and stephane,
>>>
>>> On Wed, Jan 18, 2012 at 12:18 PM, Ming Lei <ming.lei@canonical.com> wrote:
>>>> Hi stephane & Will,
>>>>
>>>> On Tue, Jan 10, 2012 at 8:46 AM, stephane eranian
>>>> <eranian@googlemail.com> 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@ti.com>
>>> 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.
>
> But why can this patch make omap4 pmu work? ?Without the patch,
> there are no CTI interrupts generated for pmu irq.
>
Interesting. For me debugger works which also relies on Emulation domain.

Need to see why CTI is behaving like this.

Regards
Santosh

Re: oprofile and ARM A9 hardware counter

[Will Deacon]

Santosh,

On Wed, Jan 18, 2012 at 12:33:23PM +0000, Shilimkar, Santosh wrote:
> On Wed, Jan 18, 2012 at 1:24 PM, Ming Lei <ming.lei@canonical.com> wrote:
> >>> 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.
> >
> > But why can this patch make omap4 pmu work?  Without the patch,
> > there are no CTI interrupts generated for pmu irq.
> >
> Interesting. For me debugger works which also relies on Emulation domain.
> 
> Need to see why CTI is behaving like this.

Did you ever get to the bottom of this? This change really is required in
order to generate PMU interrupts with the CTI and I don't know of any
alternative to the above.

Any suggestions?

Will
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

oprofile and ARM A9 hardware counter

[Will Deacon]

Santosh,

On Wed, Jan 18, 2012 at 12:33:23PM +0000, Shilimkar, Santosh wrote:
> On Wed, Jan 18, 2012 at 1:24 PM, Ming Lei <ming.lei@canonical.com> wrote:
> >>> 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.
> >
> > But why can this patch make omap4 pmu work? ?Without the patch,
> > there are no CTI interrupts generated for pmu irq.
> >
> Interesting. For me debugger works which also relies on Emulation domain.
> 
> Need to see why CTI is behaving like this.

Did you ever get to the bottom of this? This change really is required in
order to generate PMU interrupts with the CTI and I don't know of any
alternative to the above.

Any suggestions?

Will

Re: oprofile and ARM A9 hardware counter

[Shilimkar, Santosh]

On Tue, Apr 3, 2012 at 2:55 PM, Will Deacon <will.deacon@arm.com> wrote:
> Santosh,
>
> On Wed, Jan 18, 2012 at 12:33:23PM +0000, Shilimkar, Santosh wrote:
>> On Wed, Jan 18, 2012 at 1:24 PM, Ming Lei <ming.lei@canonical.com> wrote:
>> >>> 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.
>> >
>> > But why can this patch make omap4 pmu work?  Without the patch,
>> > there are no CTI interrupts generated for pmu irq.
>> >
>> Interesting. For me debugger works which also relies on Emulation domain.
>>
>> Need to see why CTI is behaving like this.
>
> Did you ever get to the bottom of this? This change really is required in
> order to generate PMU interrupts with the CTI and I don't know of any
> alternative to the above.
>
> Any suggestions?
>
Sorry I lost track of this one. There is one relevant patch in Kevin's queue
for 3.4/fixes. [1] which I generated for perf time stamp issue.

Can you try that patch and see if it helps the CTI issue as well ? There
is an outside chance that it might help. If it doesn't, we should commit
Ming Lei  patch.

Regards
Santosh

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2012-March/089679.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

oprofile and ARM A9 hardware counter

[Shilimkar, Santosh]

On Tue, Apr 3, 2012 at 2:55 PM, Will Deacon <will.deacon@arm.com> wrote:
> Santosh,
>
> On Wed, Jan 18, 2012 at 12:33:23PM +0000, Shilimkar, Santosh wrote:
>> On Wed, Jan 18, 2012 at 1:24 PM, Ming Lei <ming.lei@canonical.com> wrote:
>> >>> 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.
>> >
>> > But why can this patch make omap4 pmu work? ?Without the patch,
>> > there are no CTI interrupts generated for pmu irq.
>> >
>> Interesting. For me debugger works which also relies on Emulation domain.
>>
>> Need to see why CTI is behaving like this.
>
> Did you ever get to the bottom of this? This change really is required in
> order to generate PMU interrupts with the CTI and I don't know of any
> alternative to the above.
>
> Any suggestions?
>
Sorry I lost track of this one. There is one relevant patch in Kevin's queue
for 3.4/fixes. [1] which I generated for perf time stamp issue.

Can you try that patch and see if it helps the CTI issue as well ? There
is an outside chance that it might help. If it doesn't, we should commit
Ming Lei  patch.

Regards
Santosh

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2012-March/089679.html

Re: oprofile and ARM A9 hardware counter

[Will Deacon]

On Tue, Apr 03, 2012 at 10:42:30AM +0100, Shilimkar, Santosh wrote:
> On Tue, Apr 3, 2012 at 2:55 PM, Will Deacon <will.deacon@arm.com> wrote:
> > Did you ever get to the bottom of this? This change really is required in
> > order to generate PMU interrupts with the CTI and I don't know of any
> > alternative to the above.
> >
> > Any suggestions?
> >
> Sorry I lost track of this one. There is one relevant patch in Kevin's queue
> for 3.4/fixes. [1] which I generated for perf time stamp issue.

Thanks, I'll take a look.

> Can you try that patch and see if it helps the CTI issue as well ? There
> is an outside chance that it might help. If it doesn't, we should commit
> Ming Lei  patch.

It seems that they're both needed to get reliable PMU operation. Without the
CLKDM_CAN_SWSUP fix, no interrupts are generated at all. Without the patch
below ([1]), it seems that we don't generate enough. So it looks like we
need them both.

> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2012-March/089679.html

Cheers,

Will

oprofile and ARM A9 hardware counter

[Will Deacon]

On Tue, Apr 03, 2012 at 10:42:30AM +0100, Shilimkar, Santosh wrote:
> On Tue, Apr 3, 2012 at 2:55 PM, Will Deacon <will.deacon@arm.com> wrote:
> > Did you ever get to the bottom of this? This change really is required in
> > order to generate PMU interrupts with the CTI and I don't know of any
> > alternative to the above.
> >
> > Any suggestions?
> >
> Sorry I lost track of this one. There is one relevant patch in Kevin's queue
> for 3.4/fixes. [1] which I generated for perf time stamp issue.

Thanks, I'll take a look.

> Can you try that patch and see if it helps the CTI issue as well ? There
> is an outside chance that it might help. If it doesn't, we should commit
> Ming Lei  patch.

It seems that they're both needed to get reliable PMU operation. Without the
CLKDM_CAN_SWSUP fix, no interrupts are generated at all. Without the patch
below ([1]), it seems that we don't generate enough. So it looks like we
need them both.

> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2012-March/089679.html

Cheers,

Will

Re: oprofile and ARM A9 hardware counter

[Shilimkar, Santosh]

On Tue, Apr 3, 2012 at 3:17 PM, Will Deacon <will.deacon@arm.com> wrote:
> On Tue, Apr 03, 2012 at 10:42:30AM +0100, Shilimkar, Santosh wrote:
>> On Tue, Apr 3, 2012 at 2:55 PM, Will Deacon <will.deacon@arm.com> wrote:
>> > Did you ever get to the bottom of this? This change really is required in
>> > order to generate PMU interrupts with the CTI and I don't know of any
>> > alternative to the above.
>> >
>> > Any suggestions?
>> >
>> Sorry I lost track of this one. There is one relevant patch in Kevin's queue
>> for 3.4/fixes. [1] which I generated for perf time stamp issue.
>
> Thanks, I'll take a look.
>
>> Can you try that patch and see if it helps the CTI issue as well ? There
>> is an outside chance that it might help. If it doesn't, we should commit
>> Ming Lei  patch.
>
> It seems that they're both needed to get reliable PMU operation. Without the
> CLKDM_CAN_SWSUP fix, no interrupts are generated at all. Without the patch
> below ([1]), it seems that we don't generate enough. So it looks like we
> need them both.
>
I see. Can you please confirm if it is still the case with [1].

If yes then am nou sure how to proceed. because permanently setting
EMU CD to CLKDM_CAN_SWSUP will break PM.

>> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2012-March/089679.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

oprofile and ARM A9 hardware counter

[Shilimkar, Santosh]

On Tue, Apr 3, 2012 at 3:17 PM, Will Deacon <will.deacon@arm.com> wrote:
> On Tue, Apr 03, 2012 at 10:42:30AM +0100, Shilimkar, Santosh wrote:
>> On Tue, Apr 3, 2012 at 2:55 PM, Will Deacon <will.deacon@arm.com> wrote:
>> > Did you ever get to the bottom of this? This change really is required in
>> > order to generate PMU interrupts with the CTI and I don't know of any
>> > alternative to the above.
>> >
>> > Any suggestions?
>> >
>> Sorry I lost track of this one. There is one relevant patch in Kevin's queue
>> for 3.4/fixes. [1] which I generated for perf time stamp issue.
>
> Thanks, I'll take a look.
>
>> Can you try that patch and see if it helps the CTI issue as well ? There
>> is an outside chance that it might help. If it doesn't, we should commit
>> Ming Lei ?patch.
>
> It seems that they're both needed to get reliable PMU operation. Without the
> CLKDM_CAN_SWSUP fix, no interrupts are generated at all. Without the patch
> below ([1]), it seems that we don't generate enough. So it looks like we
> need them both.
>
I see. Can you please confirm if it is still the case with [1].

If yes then am nou sure how to proceed. because permanently setting
EMU CD to CLKDM_CAN_SWSUP will break PM.

>> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2012-March/089679.html
>

Re: oprofile and ARM A9 hardware counter

[Will Deacon]

On Tue, Apr 03, 2012 at 11:01:53AM +0100, Shilimkar, Santosh wrote:
> On Tue, Apr 3, 2012 at 3:17 PM, Will Deacon <will.deacon@arm.com> wrote:
> > It seems that they're both needed to get reliable PMU operation. Without the
> > CLKDM_CAN_SWSUP fix, no interrupts are generated at all. Without the patch
> > below ([1]), it seems that we don't generate enough. So it looks like we
> > need them both.
> >
> I see. Can you please confirm if it is still the case with [1].

Right, ignore my previous comment, I was using a vanilla 3.3 kernel without
realising and therefore what I thought were PMU/CTI interrupts were actually
just from a timer. Sorry for the confusion.

So I've gone back to basics. Here is a branch containing what I believe
should be all the patches required for the OMAP4 PMU:

git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git perf/omap4

I've omitted the SWSUSP patch since you say it breaks pm, which is clearly not
acceptable.

The problem is, trying to boot this on my pandaboard results in a hang (see
dmesg below). Even worse, the problem isn't easily bisectable since rebuilding
a working image can give you something that no longer boots and I haven't found
a reliable way to cause the lockup.

I'll take JTAG for a whirl to see where we are. If anything looks wrong in
my dmesg, please shout (there are plenty of things in there that look like
they've gone awry).

Will

Uncompressing Linux... done, booting the kernel.
[    0.000000] Booting Linux on physical CPU 0
[    0.000000] Linux version 3.3.0-00005-gcd122ab (will@mudshark) (gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu3) ) #1 SMP Tue Apr 3 13:19:29 BST 2012
[    0.000000] CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7), cr=10c53c7d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] Machine: OMAP4 Panda board
[    0.000000] bootconsole [earlycon0] enabled
[    0.000000] Memory policy: ECC disabled, Data cache writealloc
[    0.000000] OMAP4430 ES2.1
[    0.000000] PERCPU: Embedded 8 pages/cpu @c1025000 s11072 r8192 d13504 u32768
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 129792
[    0.000000] Kernel command line: console=ttyO2,115200 root=/dev/nfs nfsroot=10.1.79.58:/exports/linaro-11.11,tcp rw earlyprintk ip=dhcp
[    0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes)
[    0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
[    0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
[    0.000000] Memory: 511MB = 511MB total
[    0.000000] Memory: 506272k/506272k available, 18016k reserved, 0K highmem
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
[    0.000000]     vmalloc : 0xe0800000 - 0xff000000   ( 488 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xe0000000   ( 512 MB)
[    0.000000]     modules : 0xbf000000 - 0xc0000000   (  16 MB)
[    0.000000]       .text : 0xc0008000 - 0xc05ebf68   (6032 kB)
[    0.000000]       .init : 0xc05ec000 - 0xc0639b40   ( 311 kB)
[    0.000000]       .data : 0xc063a000 - 0xc06c6d50   ( 564 kB)
[    0.000000]        .bss : 0xc06c6d74 - 0xc0c1cb5c   (5464 kB)
[    0.000000] Hierarchical RCU implementation.
[    0.000000] NR_IRQS:474
[    0.000000] omap_hwmod: dpll_mpu_m2_ck: missing clockdomain for dpll_mpu_m2_ck.
[    0.000000] OMAP clockevent source: GPTIMER1 at 32768 Hz
[    0.000000] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms
[    0.000000] Console: colour dummy device 80x30
[    0.000000] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
[    0.000000] ... MAX_LOCKDEP_SUBCLASSES:  8
[    0.000000] ... MAX_LOCK_DEPTH:          48
[    0.000000] ... MAX_LOCKDEP_KEYS:        8191
[    0.000000] ... CLASSHASH_SIZE:          4096
[    0.000000] ... MAX_LOCKDEP_ENTRIES:     16384
[    0.000000] ... MAX_LOCKDEP_CHAINS:      32768
[    0.000000] ... CHAINHASH_SIZE:          16384
[    0.000000]  memory used by lock dependency info: 3695 kB
[    0.000000]  per task-struct memory footprint: 1152 bytes
[    0.056579] Calibrating delay loop... 2007.19 BogoMIPS (lpj=7839744)
[    0.129791] pid_max: default: 32768 minimum: 301
[    0.135192] Security Framework initialized
[    0.139678] Mount-cache hash table entries: 512
[    0.147979] CPU: Testing write buffer coherency: ok
[    0.153961] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[    0.160278] hw perfevents: enabled with ARMv7 Cortex-A9 PMU driver, 7 counters available
[    0.168853] Setting up static identity map for 0x8043ce60 - 0x8043ced0
[    0.175689] L310 cache controller enabled
[    0.179931] l2x0: 16 ways, CACHE_ID 0x410000c4, AUX_CTRL 0x7e470000, Cache size: 1048576 B
[    0.190856] CPU1: Booted secondary processor
[    0.254028] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[    0.254058] CPU1: Unknown IPI message 0x1
[    0.254180] Brought up 2 CPUs
[    0.254180] SMP: Total of 2 processors activated (4022.78 BogoMIPS).
[    0.286102] omap_hwmod: trace_clk_div_ck: missing clockdomain for trace_clk_div_ck.
[    0.294067] omap_hwmod: l3_div_ck: missing clockdomain for l3_div_ck.
[    0.303955] omap_hwmod: l3_instr: _wait_target_disable failed
[    0.322052] omap_hwmod: debugss: softreset failed (waited 10000 usec)
[    0.332824] omap_hwmod: mcpdm: cannot be enabled (3)
[    0.342315] print_constraints: dummy: 
[    0.347137] NET: Registered protocol family 16
[    0.352264] GPMC revision 6.0
[    0.360229] gpiochip_add: registered GPIOs 0 to 31 on device: gpio
[    0.366912] OMAP GPIO hardware version 0.1
[    0.371612] gpiochip_add: registered GPIOs 32 to 63 on device: gpio
[    0.378662] gpiochip_add: registered GPIOs 64 to 95 on device: gpio
[    0.385772] gpiochip_add: registered GPIOs 96 to 127 on device: gpio
[    0.392913] gpiochip_add: registered GPIOs 128 to 159 on device: gpio
[    0.400177] gpiochip_add: registered GPIOs 160 to 191 on device: gpio
[    0.410064] omap_mux_init: Add partition: #1: core, flags: 2
[    0.417327] omap_mux_init: Add partition: #2: wkup, flags: 2
[    0.423339] error setting wl12xx data: -38
[    0.430267] _omap_mux_get_by_name: Could not find signal uart1_cts.uart1_cts
[    0.437622] _omap_mux_get_by_name: Could not find signal uart1_cts.uart1_cts
[    0.444946] omap_hwmod_mux_init: Could not allocate device mux entry
[    0.455047]  usbhs_omap: alias fck already exists
[    0.463409] hw-breakpoint: found 5 (+1 reserved) breakpoint and 1 watchpoint registers.
[    0.471710] hw-breakpoint: maximum watchpoint size is 4 bytes.

<hangs here. Would usually print something about "OMAP DMA" next>

oprofile and ARM A9 hardware counter

[Will Deacon]

On Tue, Apr 03, 2012 at 11:01:53AM +0100, Shilimkar, Santosh wrote:
> On Tue, Apr 3, 2012 at 3:17 PM, Will Deacon <will.deacon@arm.com> wrote:
> > It seems that they're both needed to get reliable PMU operation. Without the
> > CLKDM_CAN_SWSUP fix, no interrupts are generated at all. Without the patch
> > below ([1]), it seems that we don't generate enough. So it looks like we
> > need them both.
> >
> I see. Can you please confirm if it is still the case with [1].

Right, ignore my previous comment, I was using a vanilla 3.3 kernel without
realising and therefore what I thought were PMU/CTI interrupts were actually
just from a timer. Sorry for the confusion.

So I've gone back to basics. Here is a branch containing what I believe
should be all the patches required for the OMAP4 PMU:

git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git perf/omap4

I've omitted the SWSUSP patch since you say it breaks pm, which is clearly not
acceptable.

The problem is, trying to boot this on my pandaboard results in a hang (see
dmesg below). Even worse, the problem isn't easily bisectable since rebuilding
a working image can give you something that no longer boots and I haven't found
a reliable way to cause the lockup.

I'll take JTAG for a whirl to see where we are. If anything looks wrong in
my dmesg, please shout (there are plenty of things in there that look like
they've gone awry).

Will

Uncompressing Linux... done, booting the kernel.
[    0.000000] Booting Linux on physical CPU 0
[    0.000000] Linux version 3.3.0-00005-gcd122ab (will at mudshark) (gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu3) ) #1 SMP Tue Apr 3 13:19:29 BST 2012
[    0.000000] CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7), cr=10c53c7d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] Machine: OMAP4 Panda board
[    0.000000] bootconsole [earlycon0] enabled
[    0.000000] Memory policy: ECC disabled, Data cache writealloc
[    0.000000] OMAP4430 ES2.1
[    0.000000] PERCPU: Embedded 8 pages/cpu @c1025000 s11072 r8192 d13504 u32768
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 129792
[    0.000000] Kernel command line: console=ttyO2,115200 root=/dev/nfs nfsroot=10.1.79.58:/exports/linaro-11.11,tcp rw earlyprintk ip=dhcp
[    0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes)
[    0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
[    0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
[    0.000000] Memory: 511MB = 511MB total
[    0.000000] Memory: 506272k/506272k available, 18016k reserved, 0K highmem
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
[    0.000000]     vmalloc : 0xe0800000 - 0xff000000   ( 488 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xe0000000   ( 512 MB)
[    0.000000]     modules : 0xbf000000 - 0xc0000000   (  16 MB)
[    0.000000]       .text : 0xc0008000 - 0xc05ebf68   (6032 kB)
[    0.000000]       .init : 0xc05ec000 - 0xc0639b40   ( 311 kB)
[    0.000000]       .data : 0xc063a000 - 0xc06c6d50   ( 564 kB)
[    0.000000]        .bss : 0xc06c6d74 - 0xc0c1cb5c   (5464 kB)
[    0.000000] Hierarchical RCU implementation.
[    0.000000] NR_IRQS:474
[    0.000000] omap_hwmod: dpll_mpu_m2_ck: missing clockdomain for dpll_mpu_m2_ck.
[    0.000000] OMAP clockevent source: GPTIMER1 at 32768 Hz
[    0.000000] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms
[    0.000000] Console: colour dummy device 80x30
[    0.000000] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
[    0.000000] ... MAX_LOCKDEP_SUBCLASSES:  8
[    0.000000] ... MAX_LOCK_DEPTH:          48
[    0.000000] ... MAX_LOCKDEP_KEYS:        8191
[    0.000000] ... CLASSHASH_SIZE:          4096
[    0.000000] ... MAX_LOCKDEP_ENTRIES:     16384
[    0.000000] ... MAX_LOCKDEP_CHAINS:      32768
[    0.000000] ... CHAINHASH_SIZE:          16384
[    0.000000]  memory used by lock dependency info: 3695 kB
[    0.000000]  per task-struct memory footprint: 1152 bytes
[    0.056579] Calibrating delay loop... 2007.19 BogoMIPS (lpj=7839744)
[    0.129791] pid_max: default: 32768 minimum: 301
[    0.135192] Security Framework initialized
[    0.139678] Mount-cache hash table entries: 512
[    0.147979] CPU: Testing write buffer coherency: ok
[    0.153961] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[    0.160278] hw perfevents: enabled with ARMv7 Cortex-A9 PMU driver, 7 counters available
[    0.168853] Setting up static identity map for 0x8043ce60 - 0x8043ced0
[    0.175689] L310 cache controller enabled
[    0.179931] l2x0: 16 ways, CACHE_ID 0x410000c4, AUX_CTRL 0x7e470000, Cache size: 1048576 B
[    0.190856] CPU1: Booted secondary processor
[    0.254028] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[    0.254058] CPU1: Unknown IPI message 0x1
[    0.254180] Brought up 2 CPUs
[    0.254180] SMP: Total of 2 processors activated (4022.78 BogoMIPS).
[    0.286102] omap_hwmod: trace_clk_div_ck: missing clockdomain for trace_clk_div_ck.
[    0.294067] omap_hwmod: l3_div_ck: missing clockdomain for l3_div_ck.
[    0.303955] omap_hwmod: l3_instr: _wait_target_disable failed
[    0.322052] omap_hwmod: debugss: softreset failed (waited 10000 usec)
[    0.332824] omap_hwmod: mcpdm: cannot be enabled (3)
[    0.342315] print_constraints: dummy: 
[    0.347137] NET: Registered protocol family 16
[    0.352264] GPMC revision 6.0
[    0.360229] gpiochip_add: registered GPIOs 0 to 31 on device: gpio
[    0.366912] OMAP GPIO hardware version 0.1
[    0.371612] gpiochip_add: registered GPIOs 32 to 63 on device: gpio
[    0.378662] gpiochip_add: registered GPIOs 64 to 95 on device: gpio
[    0.385772] gpiochip_add: registered GPIOs 96 to 127 on device: gpio
[    0.392913] gpiochip_add: registered GPIOs 128 to 159 on device: gpio
[    0.400177] gpiochip_add: registered GPIOs 160 to 191 on device: gpio
[    0.410064] omap_mux_init: Add partition: #1: core, flags: 2
[    0.417327] omap_mux_init: Add partition: #2: wkup, flags: 2
[    0.423339] error setting wl12xx data: -38
[    0.430267] _omap_mux_get_by_name: Could not find signal uart1_cts.uart1_cts
[    0.437622] _omap_mux_get_by_name: Could not find signal uart1_cts.uart1_cts
[    0.444946] omap_hwmod_mux_init: Could not allocate device mux entry
[    0.455047]  usbhs_omap: alias fck already exists
[    0.463409] hw-breakpoint: found 5 (+1 reserved) breakpoint and 1 watchpoint registers.
[    0.471710] hw-breakpoint: maximum watchpoint size is 4 bytes.

<hangs here. Would usually print something about "OMAP DMA" next>

Re: oprofile and ARM A9 hardware counter

[Shilimkar, Santosh]

On Tue, Apr 3, 2012 at 6:04 PM, Will Deacon <will.deacon@arm.com> wrote:
> On Tue, Apr 03, 2012 at 11:01:53AM +0100, Shilimkar, Santosh wrote:
>> On Tue, Apr 3, 2012 at 3:17 PM, Will Deacon <will.deacon@arm.com> wrote:
>> > It seems that they're both needed to get reliable PMU operation. Without the
>> > CLKDM_CAN_SWSUP fix, no interrupts are generated at all. Without the patch
>> > below ([1]), it seems that we don't generate enough. So it looks like we
>> > need them both.
>> >
>> I see. Can you please confirm if it is still the case with [1].
>
> Right, ignore my previous comment, I was using a vanilla 3.3 kernel without
> realising and therefore what I thought were PMU/CTI interrupts were actually
> just from a timer. Sorry for the confusion.
>
> So I've gone back to basics. Here is a branch containing what I believe
> should be all the patches required for the OMAP4 PMU:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git perf/omap4
>
> I've omitted the SWSUSP patch since you say it breaks pm, which is clearly not
> acceptable.
>
> The problem is, trying to boot this on my pandaboard results in a hang (see
> dmesg below). Even worse, the problem isn't easily bisectable since rebuilding
> a working image can give you something that no longer boots and I haven't found
> a reliable way to cause the lockup.
>
> I'll take JTAG for a whirl to see where we are. If anything looks wrong in
> my dmesg, please shout (there are plenty of things in there that look like
> they've gone awry).
>
I don't see anything abnormal in below boot log. Not sure why it
hands around there.

Regards
Santosh

oprofile and ARM A9 hardware counter

[Shilimkar, Santosh]

On Tue, Apr 3, 2012 at 6:04 PM, Will Deacon <will.deacon@arm.com> wrote:
> On Tue, Apr 03, 2012 at 11:01:53AM +0100, Shilimkar, Santosh wrote:
>> On Tue, Apr 3, 2012 at 3:17 PM, Will Deacon <will.deacon@arm.com> wrote:
>> > It seems that they're both needed to get reliable PMU operation. Without the
>> > CLKDM_CAN_SWSUP fix, no interrupts are generated at all. Without the patch
>> > below ([1]), it seems that we don't generate enough. So it looks like we
>> > need them both.
>> >
>> I see. Can you please confirm if it is still the case with [1].
>
> Right, ignore my previous comment, I was using a vanilla 3.3 kernel without
> realising and therefore what I thought were PMU/CTI interrupts were actually
> just from a timer. Sorry for the confusion.
>
> So I've gone back to basics. Here is a branch containing what I believe
> should be all the patches required for the OMAP4 PMU:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git perf/omap4
>
> I've omitted the SWSUSP patch since you say it breaks pm, which is clearly not
> acceptable.
>
> The problem is, trying to boot this on my pandaboard results in a hang (see
> dmesg below). Even worse, the problem isn't easily bisectable since rebuilding
> a working image can give you something that no longer boots and I haven't found
> a reliable way to cause the lockup.
>
> I'll take JTAG for a whirl to see where we are. If anything looks wrong in
> my dmesg, please shout (there are plenty of things in there that look like
> they've gone awry).
>
I don't see anything abnormal in below boot log. Not sure why it
hands around there.

Regards
Santosh

Re: oprofile and ARM A9 hardware counter

[Kevin Hilman]

Hi Will,

Will Deacon <will.deacon@arm.com> writes:

> On Tue, Apr 03, 2012 at 11:01:53AM +0100, Shilimkar, Santosh wrote:
>> On Tue, Apr 3, 2012 at 3:17 PM, Will Deacon <will.deacon@arm.com> wrote:
>> > It seems that they're both needed to get reliable PMU operation. Without the
>> > CLKDM_CAN_SWSUP fix, no interrupts are generated at all. Without the patch
>> > below ([1]), it seems that we don't generate enough. So it looks like we
>> > need them both.
>> >
>> I see. Can you please confirm if it is still the case with [1].
>
> Right, ignore my previous comment, I was using a vanilla 3.3 kernel without
> realising and therefore what I thought were PMU/CTI interrupts were actually
> just from a timer. Sorry for the confusion.
>
> So I've gone back to basics. Here is a branch containing what I believe
> should be all the patches required for the OMAP4 PMU:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git perf/omap4
>
> I've omitted the SWSUSP patch since you say it breaks pm, which is clearly not
> acceptable.
>
> The problem is, trying to boot this on my pandaboard results in a hang (see
> dmesg below). Even worse, the problem isn't easily bisectable since rebuilding
> a working image can give you something that no longer boots and I haven't found
> a reliable way to cause the lockup.
>
> I'll take JTAG for a whirl to see where we are. If anything looks wrong in
> my dmesg, please shout (there are plenty of things in there that look like
> they've gone awry).

Not sure why it hangs for you, but it worked for me both with your
branch on v3.3 and merging with v3.4-rc1[1]

Below is a Kconfig snippet[2] which I append to my .config after
building omap2plus_defconfig in order to build a perf/trace/PMU enabled
kernel for my Panda.

Kevin

[1]
# perf stat sleep 1

 Performance counter stats for 'sleep 1':

          9.582520 task-clock                #    0.009 CPUs utilized          
                 1 context-switches          #    0.104 K/sec                  
                 0 CPU-migrations            #    0.000 K/sec                  
               147 page-faults               #    0.015 M/sec                  
           5096283 cycles                    #    0.532 GHz                    
            607876 stalled-cycles-frontend   #   11.93% frontend cycles idle   
           3285045 stalled-cycles-backend    #   64.46% backend  cycles idle   
           2722485 instructions              #    0.53  insns per cycle        
                                             #    1.21  stalled cycles per insn
            259247 branches                  #   27.054 M/sec                  
             84274 branch-misses             #   32.51% of all branches        

       1.015919088 seconds time elapsed


[2]
CONFIG_ARCH_OMAP2=n
CONFIG_ARCH_OMAP3=n       # need to disable OMAP3 for CPU_HAS_PMU support, needed for perf on OMAP4
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_NET_SMSC95XX=y

CONFIG_PROFILING=y
CONFIG_HW_PERF_EVENTS=y
CONFIG_PERF_EVENTS=y
CONFIG_PERF_COUNTERS=y
CONFIG_TRACEPOINTS=y
CONFIG_TRACING=y
CONFIG_GENERIC_TRACER=y
CONFIG_FTRACE=y
CONFIG_FUNCTION_TRACER=y
CONFIG_ENABLE_DEFAULT_TRACERS=y
CONFIG_STACK_TRACER=y
CONFIG_SCHED_TRACER=y
CONFIG_EVENT_POWER_TRACING_DEPRECATED=n

oprofile and ARM A9 hardware counter

[Kevin Hilman]

Hi Will,

Will Deacon <will.deacon@arm.com> writes:

> On Tue, Apr 03, 2012 at 11:01:53AM +0100, Shilimkar, Santosh wrote:
>> On Tue, Apr 3, 2012 at 3:17 PM, Will Deacon <will.deacon@arm.com> wrote:
>> > It seems that they're both needed to get reliable PMU operation. Without the
>> > CLKDM_CAN_SWSUP fix, no interrupts are generated at all. Without the patch
>> > below ([1]), it seems that we don't generate enough. So it looks like we
>> > need them both.
>> >
>> I see. Can you please confirm if it is still the case with [1].
>
> Right, ignore my previous comment, I was using a vanilla 3.3 kernel without
> realising and therefore what I thought were PMU/CTI interrupts were actually
> just from a timer. Sorry for the confusion.
>
> So I've gone back to basics. Here is a branch containing what I believe
> should be all the patches required for the OMAP4 PMU:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git perf/omap4
>
> I've omitted the SWSUSP patch since you say it breaks pm, which is clearly not
> acceptable.
>
> The problem is, trying to boot this on my pandaboard results in a hang (see
> dmesg below). Even worse, the problem isn't easily bisectable since rebuilding
> a working image can give you something that no longer boots and I haven't found
> a reliable way to cause the lockup.
>
> I'll take JTAG for a whirl to see where we are. If anything looks wrong in
> my dmesg, please shout (there are plenty of things in there that look like
> they've gone awry).

Not sure why it hangs for you, but it worked for me both with your
branch on v3.3 and merging with v3.4-rc1[1]

Below is a Kconfig snippet[2] which I append to my .config after
building omap2plus_defconfig in order to build a perf/trace/PMU enabled
kernel for my Panda.

Kevin

[1]
# perf stat sleep 1

 Performance counter stats for 'sleep 1':

          9.582520 task-clock                #    0.009 CPUs utilized          
                 1 context-switches          #    0.104 K/sec                  
                 0 CPU-migrations            #    0.000 K/sec                  
               147 page-faults               #    0.015 M/sec                  
           5096283 cycles                    #    0.532 GHz                    
            607876 stalled-cycles-frontend   #   11.93% frontend cycles idle   
           3285045 stalled-cycles-backend    #   64.46% backend  cycles idle   
           2722485 instructions              #    0.53  insns per cycle        
                                             #    1.21  stalled cycles per insn
            259247 branches                  #   27.054 M/sec                  
             84274 branch-misses             #   32.51% of all branches        

       1.015919088 seconds time elapsed


[2]
CONFIG_ARCH_OMAP2=n
CONFIG_ARCH_OMAP3=n       # need to disable OMAP3 for CPU_HAS_PMU support, needed for perf on OMAP4
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_NET_SMSC95XX=y

CONFIG_PROFILING=y
CONFIG_HW_PERF_EVENTS=y
CONFIG_PERF_EVENTS=y
CONFIG_PERF_COUNTERS=y
CONFIG_TRACEPOINTS=y
CONFIG_TRACING=y
CONFIG_GENERIC_TRACER=y
CONFIG_FTRACE=y
CONFIG_FUNCTION_TRACER=y
CONFIG_ENABLE_DEFAULT_TRACERS=y
CONFIG_STACK_TRACER=y
CONFIG_SCHED_TRACER=y
CONFIG_EVENT_POWER_TRACING_DEPRECATED=n

Re: oprofile and ARM A9 hardware counter

[Will Deacon]

On Tue, Apr 03, 2012 at 03:27:52PM +0100, Kevin Hilman wrote:
> Hi Will,

Hi Kevin,

> Will Deacon <will.deacon@arm.com> writes:
> > The problem is, trying to boot this on my pandaboard results in a hang (see
> > dmesg below). Even worse, the problem isn't easily bisectable since rebuilding
> > a working image can give you something that no longer boots and I haven't found
> > a reliable way to cause the lockup.
> >
> > I'll take JTAG for a whirl to see where we are. If anything looks wrong in
> > my dmesg, please shout (there are plenty of things in there that look like
> > they've gone awry).
> 
> Not sure why it hangs for you, but it worked for me both with your
> branch on v3.3 and merging with v3.4-rc1[1]

Thanks for testing that. It turns out that updating my x-loader (it was
pretty ancient) fixed the boot hang, though I'm not sure I want to know why!

> # perf stat sleep 1
> 
>  Performance counter stats for 'sleep 1':
> 
>           9.582520 task-clock                #    0.009 CPUs utilized          
>                  1 context-switches          #    0.104 K/sec                  
>                  0 CPU-migrations            #    0.000 K/sec                  
>                147 page-faults               #    0.015 M/sec                  
>            5096283 cycles                    #    0.532 GHz                    
>             607876 stalled-cycles-frontend   #   11.93% frontend cycles idle   
>            3285045 stalled-cycles-backend    #   64.46% backend  cycles idle   
>            2722485 instructions              #    0.53  insns per cycle        
>                                              #    1.21  stalled cycles per insn
>             259247 branches                  #   27.054 M/sec                  
>              84274 branch-misses             #   32.51% of all branches        

Right. Can you confirm whether the PMU/CTI interrupts fire for you please?
Just run perf top and look at /proc/interrupts while it's running. You
should see a couple of arm-pmu entries in there and hopefully numbers > 0.

For me, my earlier mis-diagnosis has turned out to be true and I can only
see PMU interrupts if I apply the SWSUSP patch, which Santosh says will
break pm.

Cheers,

Will

oprofile and ARM A9 hardware counter

[Will Deacon]

On Tue, Apr 03, 2012 at 03:27:52PM +0100, Kevin Hilman wrote:
> Hi Will,

Hi Kevin,

> Will Deacon <will.deacon@arm.com> writes:
> > The problem is, trying to boot this on my pandaboard results in a hang (see
> > dmesg below). Even worse, the problem isn't easily bisectable since rebuilding
> > a working image can give you something that no longer boots and I haven't found
> > a reliable way to cause the lockup.
> >
> > I'll take JTAG for a whirl to see where we are. If anything looks wrong in
> > my dmesg, please shout (there are plenty of things in there that look like
> > they've gone awry).
> 
> Not sure why it hangs for you, but it worked for me both with your
> branch on v3.3 and merging with v3.4-rc1[1]

Thanks for testing that. It turns out that updating my x-loader (it was
pretty ancient) fixed the boot hang, though I'm not sure I want to know why!

> # perf stat sleep 1
> 
>  Performance counter stats for 'sleep 1':
> 
>           9.582520 task-clock                #    0.009 CPUs utilized          
>                  1 context-switches          #    0.104 K/sec                  
>                  0 CPU-migrations            #    0.000 K/sec                  
>                147 page-faults               #    0.015 M/sec                  
>            5096283 cycles                    #    0.532 GHz                    
>             607876 stalled-cycles-frontend   #   11.93% frontend cycles idle   
>            3285045 stalled-cycles-backend    #   64.46% backend  cycles idle   
>            2722485 instructions              #    0.53  insns per cycle        
>                                              #    1.21  stalled cycles per insn
>             259247 branches                  #   27.054 M/sec                  
>              84274 branch-misses             #   32.51% of all branches        

Right. Can you confirm whether the PMU/CTI interrupts fire for you please?
Just run perf top and look at /proc/interrupts while it's running. You
should see a couple of arm-pmu entries in there and hopefully numbers > 0.

For me, my earlier mis-diagnosis has turned out to be true and I can only
see PMU interrupts if I apply the SWSUSP patch, which Santosh says will
break pm.

Cheers,

Will

Re: oprofile and ARM A9 hardware counter

[Kevin Hilman]

Will Deacon <will.deacon@arm.com> writes:

[...]

> Right. Can you confirm whether the PMU/CTI interrupts fire for you please?
> Just run perf top and look at /proc/interrupts while it's running. You
> should see a couple of arm-pmu entries in there and hopefully numbers > 0.

Ah, I see now (I'm a perf newbie.)

Indeed, like you, I have to change the EMU clock domain to SWSUP[1] in
order to see any interrupts and see anything in perf top.  This isn't
really a mergeable workaround, so I'll look into this a little closer
with Santosh to see what we can do once we fully understand the HW
problem.

Kevin

[1]
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,
 };

oprofile and ARM A9 hardware counter

[Kevin Hilman]

Will Deacon <will.deacon@arm.com> writes:

[...]

> Right. Can you confirm whether the PMU/CTI interrupts fire for you please?
> Just run perf top and look at /proc/interrupts while it's running. You
> should see a couple of arm-pmu entries in there and hopefully numbers > 0.

Ah, I see now (I'm a perf newbie.)

Indeed, like you, I have to change the EMU clock domain to SWSUP[1] in
order to see any interrupts and see anything in perf top.  This isn't
really a mergeable workaround, so I'll look into this a little closer
with Santosh to see what we can do once we fully understand the HW
problem.

Kevin

[1]
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,
 };

Re: oprofile and ARM A9 hardware counter

[Paul Walmsley]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1887 bytes --]

Hi

On Tue, 3 Apr 2012, Kevin Hilman wrote:

> Indeed, like you, I have to change the EMU clock domain to SWSUP[1] in
> order to see any interrupts and see anything in perf top.  This isn't
> really a mergeable workaround, so I'll look into this a little closer
> with Santosh to see what we can do once we fully understand the HW
> problem.

Part of the problem is that the clockdomain data for the emu_sys 
clockdomain is wrong.  Here's something to try to fix it.  It might just 
be enough to get it to work.

- Paul

From: Paul Walmsley <paul@pwsan.com>
Date: Tue, 3 Apr 2012 17:13:48 -0600
Subject: [PATCH] ARM: OMAP44xx: clockdomain data: correct the emu_sys_clkdm
 CLKTRCTRL data

According to the 4430 ES2.0 TRM vX Table 3-744 "CM_EMU_CLKSTCTRL",
the emu_sys clockdomain data in mainline is incorrect.

The emu_sys clockdomain does not support the DISABLE_AUTO state, and
instead it supports the FORCE_WAKEUP state.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Ming Lei <ming.lei@canonical.com>
---
 arch/arm/mach-omap2/clockdomains44xx_data.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/clockdomains44xx_data.c b/arch/arm/mach-omap2/clockdomains44xx_data.c
index 9299ac2..bd7ed13 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_ENABLE_AUTO | CLKDM_CAN_FORCE_WAKEUP,
 };
 
 static struct clockdomain l3_dma_44xx_clkdm = {
-- 
1.7.9.5

oprofile and ARM A9 hardware counter

[Paul Walmsley]

Hi

On Tue, 3 Apr 2012, Kevin Hilman wrote:

> Indeed, like you, I have to change the EMU clock domain to SWSUP[1] in
> order to see any interrupts and see anything in perf top.  This isn't
> really a mergeable workaround, so I'll look into this a little closer
> with Santosh to see what we can do once we fully understand the HW
> problem.

Part of the problem is that the clockdomain data for the emu_sys 
clockdomain is wrong.  Here's something to try to fix it.  It might just 
be enough to get it to work.

- Paul

From: Paul Walmsley <paul@pwsan.com>
Date: Tue, 3 Apr 2012 17:13:48 -0600
Subject: [PATCH] ARM: OMAP44xx: clockdomain data: correct the emu_sys_clkdm
 CLKTRCTRL data

According to the 4430 ES2.0 TRM vX Table 3-744 "CM_EMU_CLKSTCTRL",
the emu_sys clockdomain data in mainline is incorrect.

The emu_sys clockdomain does not support the DISABLE_AUTO state, and
instead it supports the FORCE_WAKEUP state.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Beno?t Cousson <b-cousson@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Ming Lei <ming.lei@canonical.com>
---
 arch/arm/mach-omap2/clockdomains44xx_data.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/clockdomains44xx_data.c b/arch/arm/mach-omap2/clockdomains44xx_data.c
index 9299ac2..bd7ed13 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_ENABLE_AUTO | CLKDM_CAN_FORCE_WAKEUP,
 };
 
 static struct clockdomain l3_dma_44xx_clkdm = {
-- 
1.7.9.5

Re: oprofile and ARM A9 hardware counter

[Ming Lei]

On Wed, Apr 4, 2012 at 7:29 AM, Paul Walmsley <paul@pwsan.com> wrote:
> Hi
>
> On Tue, 3 Apr 2012, Kevin Hilman wrote:
>
>> Indeed, like you, I have to change the EMU clock domain to SWSUP[1] in
>> order to see any interrupts and see anything in perf top.  This isn't
>> really a mergeable workaround, so I'll look into this a little closer
>> with Santosh to see what we can do once we fully understand the HW
>> problem.
>
> Part of the problem is that the clockdomain data for the emu_sys
> clockdomain is wrong.  Here's something to try to fix it.  It might just
> be enough to get it to work.
>
> - Paul
>
> From: Paul Walmsley <paul@pwsan.com>
> Date: Tue, 3 Apr 2012 17:13:48 -0600
> Subject: [PATCH] ARM: OMAP44xx: clockdomain data: correct the emu_sys_clkdm
>  CLKTRCTRL data
>
> According to the 4430 ES2.0 TRM vX Table 3-744 "CM_EMU_CLKSTCTRL",
> the emu_sys clockdomain data in mainline is incorrect.
>
> The emu_sys clockdomain does not support the DISABLE_AUTO state, and
> instead it supports the FORCE_WAKEUP state.
>
> Signed-off-by: Paul Walmsley <paul@pwsan.com>
> Cc: Benoît Cousson <b-cousson@ti.com>
> Cc: Kevin Hilman <khilman@ti.com>
> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Ming Lei <ming.lei@canonical.com>
> ---
>  arch/arm/mach-omap2/clockdomains44xx_data.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-omap2/clockdomains44xx_data.c b/arch/arm/mach-omap2/clockdomains44xx_data.c
> index 9299ac2..bd7ed13 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_ENABLE_AUTO | CLKDM_CAN_FORCE_WAKEUP,

I tested the patch just now, but unfortunately, the change still doesn't make
PMU to generate IRQs.

Mark the flags as CLKDM_CAN_SWSUP may work, but PMU will stop producing
IRQs after resuming from suspend.


Thanks
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

oprofile and ARM A9 hardware counter

[Ming Lei]

On Wed, Apr 4, 2012 at 7:29 AM, Paul Walmsley <paul@pwsan.com> wrote:
> Hi
>
> On Tue, 3 Apr 2012, Kevin Hilman wrote:
>
>> Indeed, like you, I have to change the EMU clock domain to SWSUP[1] in
>> order to see any interrupts and see anything in perf top. ?This isn't
>> really a mergeable workaround, so I'll look into this a little closer
>> with Santosh to see what we can do once we fully understand the HW
>> problem.
>
> Part of the problem is that the clockdomain data for the emu_sys
> clockdomain is wrong. ?Here's something to try to fix it. ?It might just
> be enough to get it to work.
>
> - Paul
>
> From: Paul Walmsley <paul@pwsan.com>
> Date: Tue, 3 Apr 2012 17:13:48 -0600
> Subject: [PATCH] ARM: OMAP44xx: clockdomain data: correct the emu_sys_clkdm
> ?CLKTRCTRL data
>
> According to the 4430 ES2.0 TRM vX Table 3-744 "CM_EMU_CLKSTCTRL",
> the emu_sys clockdomain data in mainline is incorrect.
>
> The emu_sys clockdomain does not support the DISABLE_AUTO state, and
> instead it supports the FORCE_WAKEUP state.
>
> Signed-off-by: Paul Walmsley <paul@pwsan.com>
> Cc: Beno?t Cousson <b-cousson@ti.com>
> Cc: Kevin Hilman <khilman@ti.com>
> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Ming Lei <ming.lei@canonical.com>
> ---
> ?arch/arm/mach-omap2/clockdomains44xx_data.c | ? ?2 +-
> ?1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-omap2/clockdomains44xx_data.c b/arch/arm/mach-omap2/clockdomains44xx_data.c
> index 9299ac2..bd7ed13 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_ENABLE_AUTO | CLKDM_CAN_FORCE_WAKEUP,

I tested the patch just now, but unfortunately, the change still doesn't make
PMU to generate IRQs.

Mark the flags as CLKDM_CAN_SWSUP may work, but PMU will stop producing
IRQs after resuming from suspend.


Thanks
--
Ming Lei

Re: oprofile and ARM A9 hardware counter

[Will Deacon]

On Wed, Apr 04, 2012 at 12:29:49AM +0100, Paul Walmsley wrote:
> 
> Part of the problem is that the clockdomain data for the emu_sys 
> clockdomain is wrong.  Here's something to try to fix it.  It might just 
> be enough to get it to work.

Hmm, doesn't seem to work but I do see the following in dmesg when I try to
use perf:

 powerdomain: waited too long for powerdomain emu_pwrdm to complete transition

which is new with your patch.

Cheers,

Will

oprofile and ARM A9 hardware counter

[Will Deacon]

On Wed, Apr 04, 2012 at 12:29:49AM +0100, Paul Walmsley wrote:
> 
> Part of the problem is that the clockdomain data for the emu_sys 
> clockdomain is wrong.  Here's something to try to fix it.  It might just 
> be enough to get it to work.

Hmm, doesn't seem to work but I do see the following in dmesg when I try to
use perf:

 powerdomain: waited too long for powerdomain emu_pwrdm to complete transition

which is new with your patch.

Cheers,

Will

Re: oprofile and ARM A9 hardware counter

[Will Deacon]

On Wed, Apr 04, 2012 at 12:15:24PM +0100, Will Deacon wrote:
> On Wed, Apr 04, 2012 at 12:29:49AM +0100, Paul Walmsley wrote:
> > 
> > Part of the problem is that the clockdomain data for the emu_sys 
> > clockdomain is wrong.  Here's something to try to fix it.  It might just 
> > be enough to get it to work.
> 
> Hmm, doesn't seem to work but I do see the following in dmesg when I try to
> use perf:
> 
>  powerdomain: waited too long for powerdomain emu_pwrdm to complete transition
> 
> which is new with your patch.

Sorry to nag, but does anybody have a clue where to go from here? I can
start digging in the OMAP PM code, but it's all new territory for me.

Cheers,

Will

oprofile and ARM A9 hardware counter

[Will Deacon]

On Wed, Apr 04, 2012 at 12:15:24PM +0100, Will Deacon wrote:
> On Wed, Apr 04, 2012 at 12:29:49AM +0100, Paul Walmsley wrote:
> > 
> > Part of the problem is that the clockdomain data for the emu_sys 
> > clockdomain is wrong.  Here's something to try to fix it.  It might just 
> > be enough to get it to work.
> 
> Hmm, doesn't seem to work but I do see the following in dmesg when I try to
> use perf:
> 
>  powerdomain: waited too long for powerdomain emu_pwrdm to complete transition
> 
> which is new with your patch.

Sorry to nag, but does anybody have a clue where to go from here? I can
start digging in the OMAP PM code, but it's all new territory for me.

Cheers,

Will

Re: oprofile and ARM A9 hardware counter

[Kevin Hilman]

Hi Will,

Will Deacon <will.deacon@arm.com> writes:

> On Wed, Apr 04, 2012 at 12:15:24PM +0100, Will Deacon wrote:
>> On Wed, Apr 04, 2012 at 12:29:49AM +0100, Paul Walmsley wrote:
>> > 
>> > Part of the problem is that the clockdomain data for the emu_sys 
>> > clockdomain is wrong.  Here's something to try to fix it.  It might just 
>> > be enough to get it to work.
>> 
>> Hmm, doesn't seem to work but I do see the following in dmesg when I try to
>> use perf:
>> 
>>  powerdomain: waited too long for powerdomain emu_pwrdm to complete transition
>> 
>> which is new with your patch.
>
> Sorry to nag, but does anybody have a clue where to go from here? I can
> start digging in the OMAP PM code, but it's all new territory for me.

Unfortunately, digging in the code isn't going to help much.  

We've been trying to get our heads around some undocumented reset
behavior for the various debug IPs in OMAP.

After a little digging and clarification from HW designers, it appears
that if we allow the EMU clockdomain to idle, a full reset of the debug
IPs is done.  That means there are two solutions to this problem:

1) don't ever alow EMU clockdomain to idle.
2) modify CTI driver to re-init for every use.

Obviously (1) is the easiet, and hacks for that have already been
posted, but that has pretty significant impacts on power savings.  (2)
is the right solution to merge upstream, but needs writing. 

For (2), using runtime PM methods in the driver would be the simplest
here since the ->runtime_resume method will be called every time the
device is about to be used.

Kevin

oprofile and ARM A9 hardware counter

[Kevin Hilman]

Hi Will,

Will Deacon <will.deacon@arm.com> writes:

> On Wed, Apr 04, 2012 at 12:15:24PM +0100, Will Deacon wrote:
>> On Wed, Apr 04, 2012 at 12:29:49AM +0100, Paul Walmsley wrote:
>> > 
>> > Part of the problem is that the clockdomain data for the emu_sys 
>> > clockdomain is wrong.  Here's something to try to fix it.  It might just 
>> > be enough to get it to work.
>> 
>> Hmm, doesn't seem to work but I do see the following in dmesg when I try to
>> use perf:
>> 
>>  powerdomain: waited too long for powerdomain emu_pwrdm to complete transition
>> 
>> which is new with your patch.
>
> Sorry to nag, but does anybody have a clue where to go from here? I can
> start digging in the OMAP PM code, but it's all new territory for me.

Unfortunately, digging in the code isn't going to help much.  

We've been trying to get our heads around some undocumented reset
behavior for the various debug IPs in OMAP.

After a little digging and clarification from HW designers, it appears
that if we allow the EMU clockdomain to idle, a full reset of the debug
IPs is done.  That means there are two solutions to this problem:

1) don't ever alow EMU clockdomain to idle.
2) modify CTI driver to re-init for every use.

Obviously (1) is the easiet, and hacks for that have already been
posted, but that has pretty significant impacts on power savings.  (2)
is the right solution to merge upstream, but needs writing. 

For (2), using runtime PM methods in the driver would be the simplest
here since the ->runtime_resume method will be called every time the
device is about to be used.

Kevin

Re: oprofile and ARM A9 hardware counter

[Ming Lei]

On Tue, May 1, 2012 at 6:25 AM, Kevin Hilman <khilman@ti.com> wrote:

> Unfortunately, digging in the code isn't going to help much.
>
> We've been trying to get our heads around some undocumented reset
> behavior for the various debug IPs in OMAP.
>
> After a little digging and clarification from HW designers, it appears
> that if we allow the EMU clockdomain to idle, a full reset of the debug
> IPs is done.  That means there are two solutions to this problem:
>
> 1) don't ever alow EMU clockdomain to idle.
> 2) modify CTI driver to re-init for every use.
>
> Obviously (1) is the easiet, and hacks for that have already been
> posted, but that has pretty significant impacts on power savings.  (2)
> is the right solution to merge upstream, but needs writing.
>
> For (2), using runtime PM methods in the driver would be the simplest
> here since the ->runtime_resume method will be called every time the
> device is about to be used.

The previous patch has supported runtime pm on omap4 pmu[1], but still
didn't fix the problem. Could you comment on the patch and point out
the proper way to support pmu runtime for fixing the problem?


[1], http://marc.info/?l=linux-arm-kernel&m=131946777028358&w=2

Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

oprofile and ARM A9 hardware counter

[Ming Lei]

On Tue, May 1, 2012 at 6:25 AM, Kevin Hilman <khilman@ti.com> wrote:

> Unfortunately, digging in the code isn't going to help much.
>
> We've been trying to get our heads around some undocumented reset
> behavior for the various debug IPs in OMAP.
>
> After a little digging and clarification from HW designers, it appears
> that if we allow the EMU clockdomain to idle, a full reset of the debug
> IPs is done. ?That means there are two solutions to this problem:
>
> 1) don't ever alow EMU clockdomain to idle.
> 2) modify CTI driver to re-init for every use.
>
> Obviously (1) is the easiet, and hacks for that have already been
> posted, but that has pretty significant impacts on power savings. ?(2)
> is the right solution to merge upstream, but needs writing.
>
> For (2), using runtime PM methods in the driver would be the simplest
> here since the ->runtime_resume method will be called every time the
> device is about to be used.

The previous patch has supported runtime pm on omap4 pmu[1], but still
didn't fix the problem. Could you comment on the patch and point out
the proper way to support pmu runtime for fixing the problem?


[1], http://marc.info/?l=linux-arm-kernel&m=131946777028358&w=2

Thanks,
--
Ming Lei

Re: oprofile and ARM A9 hardware counter

[Jon Hunter]

Hi Will,

On 04/26/2012 01:07 PM, Will Deacon wrote:
> On Wed, Apr 04, 2012 at 12:15:24PM +0100, Will Deacon wrote:
>> On Wed, Apr 04, 2012 at 12:29:49AM +0100, Paul Walmsley wrote:
>>>
>>> Part of the problem is that the clockdomain data for the emu_sys 
>>> clockdomain is wrong.  Here's something to try to fix it.  It might just 
>>> be enough to get it to work.
>>
>> Hmm, doesn't seem to work but I do see the following in dmesg when I try to
>> use perf:
>>
>>  powerdomain: waited too long for powerdomain emu_pwrdm to complete transition
>>
>> which is new with your patch.
> 
> Sorry to nag, but does anybody have a clue where to go from here? I can
> start digging in the OMAP PM code, but it's all new territory for me.

I did a little playing around with this today and I think that I have figured out why this was not working (see below). Please can you try the following patch? I tried this on top of your series for perf/omap4. 

Paul, FYI. If this works for Will then I can re-base on top of the latest linux-omap and submit to the mailing list.

Also, the above error about the emu_pwrdm is odd too. I noticed that the emu_pwrdm is always in the transitioning state. And when I say always, I mean that even if I check the power domain state while u-boot is running it is in the transitioning state. So even before the kernel starts. 

Cheers
Jon 

>From 9137ff9c1b382232de7443db0b51b7555846fb62 Mon Sep 17 00:00:00 2001
From: Jon Hunter <jon-hunter@ti.com>
Date: Fri, 4 May 2012 16:48:45 -0500
Subject: [PATCH] ARM: OMAP4: Disable auto enable for EMU CLKDM

The flag CLKDM_CAN_HWSUP allows the clock-domain to automatically transition
to the enabled and disabled state. This means that as soon as we force a
software wake-up on the clock domain, the clock domain will be allowed to idle
and put back into the hardware auto state. For the EMU clock domain this is not
what we want. We want to keep the clock domain in the software wakeup state
while the clock domain is being used and put it back in to the hardware auto
state when we have finished using the clock domain.

Signed-off-by: Jon Hunter <jon-hunter@ti.com>
---
 arch/arm/mach-omap2/clockdomains44xx_data.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/clockdomains44xx_data.c b/arch/arm/mach-omap2/clockdomains44xx_data.c
index 9299ac2..dd2cd96 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_FORCE_WAKEUP | CLKDM_CAN_DISABLE_AUTO,
 };
 
 static struct clockdomain l3_dma_44xx_clkdm = {
-- 
1.7.5.4

oprofile and ARM A9 hardware counter

[Jon Hunter]

Hi Will,

On 04/26/2012 01:07 PM, Will Deacon wrote:
> On Wed, Apr 04, 2012 at 12:15:24PM +0100, Will Deacon wrote:
>> On Wed, Apr 04, 2012 at 12:29:49AM +0100, Paul Walmsley wrote:
>>>
>>> Part of the problem is that the clockdomain data for the emu_sys 
>>> clockdomain is wrong.  Here's something to try to fix it.  It might just 
>>> be enough to get it to work.
>>
>> Hmm, doesn't seem to work but I do see the following in dmesg when I try to
>> use perf:
>>
>>  powerdomain: waited too long for powerdomain emu_pwrdm to complete transition
>>
>> which is new with your patch.
> 
> Sorry to nag, but does anybody have a clue where to go from here? I can
> start digging in the OMAP PM code, but it's all new territory for me.

I did a little playing around with this today and I think that I have figured out why this was not working (see below). Please can you try the following patch? I tried this on top of your series for perf/omap4. 

Paul, FYI. If this works for Will then I can re-base on top of the latest linux-omap and submit to the mailing list.

Also, the above error about the emu_pwrdm is odd too. I noticed that the emu_pwrdm is always in the transitioning state. And when I say always, I mean that even if I check the power domain state while u-boot is running it is in the transitioning state. So even before the kernel starts. 

Cheers
Jon 

>From 9137ff9c1b382232de7443db0b51b7555846fb62 Mon Sep 17 00:00:00 2001
From: Jon Hunter <jon-hunter@ti.com>
Date: Fri, 4 May 2012 16:48:45 -0500
Subject: [PATCH] ARM: OMAP4: Disable auto enable for EMU CLKDM

The flag CLKDM_CAN_HWSUP allows the clock-domain to automatically transition
to the enabled and disabled state. This means that as soon as we force a
software wake-up on the clock domain, the clock domain will be allowed to idle
and put back into the hardware auto state. For the EMU clock domain this is not
what we want. We want to keep the clock domain in the software wakeup state
while the clock domain is being used and put it back in to the hardware auto
state when we have finished using the clock domain.

Signed-off-by: Jon Hunter <jon-hunter@ti.com>
---
 arch/arm/mach-omap2/clockdomains44xx_data.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/clockdomains44xx_data.c b/arch/arm/mach-omap2/clockdomains44xx_data.c
index 9299ac2..dd2cd96 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_FORCE_WAKEUP | CLKDM_CAN_DISABLE_AUTO,
 };
 
 static struct clockdomain l3_dma_44xx_clkdm = {
-- 
1.7.5.4

Re: oprofile and ARM A9 hardware counter

[Kevin Hilman]

Jon Hunter <jon-hunter@ti.com> writes:

> Hi Will,
>
> On 04/26/2012 01:07 PM, Will Deacon wrote:
>> On Wed, Apr 04, 2012 at 12:15:24PM +0100, Will Deacon wrote:
>>> On Wed, Apr 04, 2012 at 12:29:49AM +0100, Paul Walmsley wrote:
>>>>
>>>> Part of the problem is that the clockdomain data for the emu_sys 
>>>> clockdomain is wrong.  Here's something to try to fix it.  It might just 
>>>> be enough to get it to work.
>>>
>>> Hmm, doesn't seem to work but I do see the following in dmesg when I try to
>>> use perf:
>>>
>>>  powerdomain: waited too long for powerdomain emu_pwrdm to complete transition
>>>
>>> which is new with your patch.
>> 
>> Sorry to nag, but does anybody have a clue where to go from here? I can
>> start digging in the OMAP PM code, but it's all new territory for me.
>
> I did a little playing around with this today and I think that I have figured out why this was not working (see below). Please can you try the following patch? I tried this on top of your series for perf/omap4. 
>
> Paul, FYI. If this works for Will then I can re-base on top of the latest linux-omap and submit to the mailing list.
>
> Also, the above error about the emu_pwrdm is odd too. I noticed that the emu_pwrdm is always in the transitioning state. And when I say always, I mean that even if I check the power domain state while u-boot is running it is in the transitioning state. So even before the kernel starts. 
>
> Cheers
> Jon 
>
> From 9137ff9c1b382232de7443db0b51b7555846fb62 Mon Sep 17 00:00:00 2001
> From: Jon Hunter <jon-hunter@ti.com>
> Date: Fri, 4 May 2012 16:48:45 -0500
> Subject: [PATCH] ARM: OMAP4: Disable auto enable for EMU CLKDM
>
> The flag CLKDM_CAN_HWSUP allows the clock-domain to automatically transition
> to the enabled and disabled state. This means that as soon as we force a
> software wake-up on the clock domain, the clock domain will be allowed to idle
> and put back into the hardware auto state. For the EMU clock domain this is not
> what we want. We want to keep the clock domain in the software wakeup state
> while the clock domain is being used and put it back in to the hardware auto
> state when we have finished using the clock domain.
>
> Signed-off-by: Jon Hunter <jon-hunter@ti.com>

With this patch, how is the clkdm ever idled?

IIUC, your patch will get PMU interrupts working, but similarily to
previous patches in this thread, it works because it *never* allows the
EMU clkdm to idle.  This is not a mergeable solution because it will not
allow CORE retention (and thus full-chip retention.)

What we need is a solution that allows the clkdm to idle, and then to be
reinitialzed when it wakes up.  Due to the way (I understand) resets in
the debugss, allowing the clkdm to idle will cause a reset, so the
PMU/CTI interrupts need to be reinitialzied after wakeup.

Kevin

P.S. Please note there is also already a different fix in mainline for
the EMU clkdm data from Paul which adds the force wakeup flag and
removes the DISABLE_AUTO flag[1] (but leaves the ENABLE_AUTO flag,
because the hardware is capable.)


[1]
Author: Paul Walmsley <paul@pwsan.com>  2012-04-04 07:25:25
Committer: Paul Walmsley <paul@pwsan.com>  2012-04-04 07:25:25
Parent: c16fa4f2ad19908a47c63d8fa436a1178438c7e7 (Linux 3.3)
Branches: many (164)
Follows: v3.4-rc1
Precedes: omap-fixes-a-for-3.4rc, omap-fixes-a2-for-3.4rc

    ARM: OMAP44xx: clockdomain data: correct the emu_sys_clkdm CLKTRCTRL data
    
    According to the 4430 ES2.0 TRM vX Table 3-744 "CM_EMU_CLKSTCTRL",
    the emu_sys clockdomain data in mainline is incorrect.
    
    The emu_sys clockdomain does not support the DISABLE_AUTO state, and
    instead it supports the FORCE_WAKEUP state.
    
    Signed-off-by: Paul Walmsley <paul@pwsan.com>
    Cc: Benoît Cousson <b-cousson@ti.com>
    Cc: Kevin Hilman <khilman@ti.com>
    Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
    Cc: Ming Lei <ming.lei@canonical.com>
    Cc: Will Deacon <will.deacon@arm.com>

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

oprofile and ARM A9 hardware counter

[Kevin Hilman]

Jon Hunter <jon-hunter@ti.com> writes:

> Hi Will,
>
> On 04/26/2012 01:07 PM, Will Deacon wrote:
>> On Wed, Apr 04, 2012 at 12:15:24PM +0100, Will Deacon wrote:
>>> On Wed, Apr 04, 2012 at 12:29:49AM +0100, Paul Walmsley wrote:
>>>>
>>>> Part of the problem is that the clockdomain data for the emu_sys 
>>>> clockdomain is wrong.  Here's something to try to fix it.  It might just 
>>>> be enough to get it to work.
>>>
>>> Hmm, doesn't seem to work but I do see the following in dmesg when I try to
>>> use perf:
>>>
>>>  powerdomain: waited too long for powerdomain emu_pwrdm to complete transition
>>>
>>> which is new with your patch.
>> 
>> Sorry to nag, but does anybody have a clue where to go from here? I can
>> start digging in the OMAP PM code, but it's all new territory for me.
>
> I did a little playing around with this today and I think that I have figured out why this was not working (see below). Please can you try the following patch? I tried this on top of your series for perf/omap4. 
>
> Paul, FYI. If this works for Will then I can re-base on top of the latest linux-omap and submit to the mailing list.
>
> Also, the above error about the emu_pwrdm is odd too. I noticed that the emu_pwrdm is always in the transitioning state. And when I say always, I mean that even if I check the power domain state while u-boot is running it is in the transitioning state. So even before the kernel starts. 
>
> Cheers
> Jon 
>
> From 9137ff9c1b382232de7443db0b51b7555846fb62 Mon Sep 17 00:00:00 2001
> From: Jon Hunter <jon-hunter@ti.com>
> Date: Fri, 4 May 2012 16:48:45 -0500
> Subject: [PATCH] ARM: OMAP4: Disable auto enable for EMU CLKDM
>
> The flag CLKDM_CAN_HWSUP allows the clock-domain to automatically transition
> to the enabled and disabled state. This means that as soon as we force a
> software wake-up on the clock domain, the clock domain will be allowed to idle
> and put back into the hardware auto state. For the EMU clock domain this is not
> what we want. We want to keep the clock domain in the software wakeup state
> while the clock domain is being used and put it back in to the hardware auto
> state when we have finished using the clock domain.
>
> Signed-off-by: Jon Hunter <jon-hunter@ti.com>

With this patch, how is the clkdm ever idled?

IIUC, your patch will get PMU interrupts working, but similarily to
previous patches in this thread, it works because it *never* allows the
EMU clkdm to idle.  This is not a mergeable solution because it will not
allow CORE retention (and thus full-chip retention.)

What we need is a solution that allows the clkdm to idle, and then to be
reinitialzed when it wakes up.  Due to the way (I understand) resets in
the debugss, allowing the clkdm to idle will cause a reset, so the
PMU/CTI interrupts need to be reinitialzied after wakeup.

Kevin

P.S. Please note there is also already a different fix in mainline for
the EMU clkdm data from Paul which adds the force wakeup flag and
removes the DISABLE_AUTO flag[1] (but leaves the ENABLE_AUTO flag,
because the hardware is capable.)


[1]
Author: Paul Walmsley <paul@pwsan.com>  2012-04-04 07:25:25
Committer: Paul Walmsley <paul@pwsan.com>  2012-04-04 07:25:25
Parent: c16fa4f2ad19908a47c63d8fa436a1178438c7e7 (Linux 3.3)
Branches: many (164)
Follows: v3.4-rc1
Precedes: omap-fixes-a-for-3.4rc, omap-fixes-a2-for-3.4rc

    ARM: OMAP44xx: clockdomain data: correct the emu_sys_clkdm CLKTRCTRL data
    
    According to the 4430 ES2.0 TRM vX Table 3-744 "CM_EMU_CLKSTCTRL",
    the emu_sys clockdomain data in mainline is incorrect.
    
    The emu_sys clockdomain does not support the DISABLE_AUTO state, and
    instead it supports the FORCE_WAKEUP state.
    
    Signed-off-by: Paul Walmsley <paul@pwsan.com>
    Cc: Beno?t Cousson <b-cousson@ti.com>
    Cc: Kevin Hilman <khilman@ti.com>
    Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
    Cc: Ming Lei <ming.lei@canonical.com>
    Cc: Will Deacon <will.deacon@arm.com>

Re: oprofile and ARM A9 hardware counter

[Jon Hunter]

Hi Kevin,

On 05/07/2012 12:15 PM, Kevin Hilman wrote:
> Jon Hunter <jon-hunter@ti.com> writes:
> 
>> Hi Will,
>>
>> On 04/26/2012 01:07 PM, Will Deacon wrote:
>>> On Wed, Apr 04, 2012 at 12:15:24PM +0100, Will Deacon wrote:
>>>> On Wed, Apr 04, 2012 at 12:29:49AM +0100, Paul Walmsley wrote:
>>>>>
>>>>> Part of the problem is that the clockdomain data for the emu_sys 
>>>>> clockdomain is wrong.  Here's something to try to fix it.  It might just 
>>>>> be enough to get it to work.
>>>>
>>>> Hmm, doesn't seem to work but I do see the following in dmesg when I try to
>>>> use perf:
>>>>
>>>>  powerdomain: waited too long for powerdomain emu_pwrdm to complete transition
>>>>
>>>> which is new with your patch.
>>>
>>> Sorry to nag, but does anybody have a clue where to go from here? I can
>>> start digging in the OMAP PM code, but it's all new territory for me.
>>
>> I did a little playing around with this today and I think that I have figured out why this was not working (see below). Please can you try the following patch? I tried this on top of your series for perf/omap4. 
>>
>> Paul, FYI. If this works for Will then I can re-base on top of the latest linux-omap and submit to the mailing list.
>>
>> Also, the above error about the emu_pwrdm is odd too. I noticed that the emu_pwrdm is always in the transitioning state. And when I say always, I mean that even if I check the power domain state while u-boot is running it is in the transitioning state. So even before the kernel starts. 
>>
>> Cheers
>> Jon 
>>
>> From 9137ff9c1b382232de7443db0b51b7555846fb62 Mon Sep 17 00:00:00 2001
>> From: Jon Hunter <jon-hunter@ti.com>
>> Date: Fri, 4 May 2012 16:48:45 -0500
>> Subject: [PATCH] ARM: OMAP4: Disable auto enable for EMU CLKDM
>>
>> The flag CLKDM_CAN_HWSUP allows the clock-domain to automatically transition
>> to the enabled and disabled state. This means that as soon as we force a
>> software wake-up on the clock domain, the clock domain will be allowed to idle
>> and put back into the hardware auto state. For the EMU clock domain this is not
>> what we want. We want to keep the clock domain in the software wakeup state
>> while the clock domain is being used and put it back in to the hardware auto
>> state when we have finished using the clock domain.
>>
>> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
> 
> With this patch, how is the clkdm ever idled?

It does not! Sorry, I was so engrossed with figuring out why the EMU
clkdm was being idled as soon as it was enabled, I forgot to check if is
ever disabled once we terminated perf :-(

> IIUC, your patch will get PMU interrupts working, but similarily to
> previous patches in this thread, it works because it *never* allows the
> EMU clkdm to idle.  This is not a mergeable solution because it will not
> allow CORE retention (and thus full-chip retention.)

Right!

> What we need is a solution that allows the clkdm to idle, and then to be
> reinitialzed when it wakes up.  Due to the way (I understand) resets in
> the debugss, allowing the clkdm to idle will cause a reset, so the
> PMU/CTI interrupts need to be reinitialzied after wakeup.

Yes exactly I see that now. I have prototyped the 3 patches and this is
working AND the EMU clkdm does go back to idle. I can send out to the
list for review.

> Kevin
> 
> P.S. Please note there is also already a different fix in mainline for
> the EMU clkdm data from Paul which adds the force wakeup flag and
> removes the DISABLE_AUTO flag[1] (but leaves the ENABLE_AUTO flag,
> because the hardware is capable.)

Hmmm ... yes saw this, and you will have to excuse me as I don't fully
follow the logic here. In fact, I am thinking we want the opposite ;-)

>From looking, into this it seems to me that when PMU is running we want
the EMU clock domain in software-wakeup state and when PMU is not
running we want in the hardware auto state. By keeping the ENABLE_AUTO
flag set, as soon as we enable the clock domain it is put right back
into the HW_AUTO state and hence PMU is not working (see _enable()
function in arch/arm/mach-omap2/omap_hwmod.c)

So really what I think we want is to remove the ENABLE_AUTO flag to keep
the clock domain in software wake-up and use the DISABLE_AUTO flag to
put the clock domain back in HW_AUTO (note this requires a patch to
perform this 2nd part).

Cheers
Jon

oprofile and ARM A9 hardware counter

[Jon Hunter]

Hi Kevin,

On 05/07/2012 12:15 PM, Kevin Hilman wrote:
> Jon Hunter <jon-hunter@ti.com> writes:
> 
>> Hi Will,
>>
>> On 04/26/2012 01:07 PM, Will Deacon wrote:
>>> On Wed, Apr 04, 2012 at 12:15:24PM +0100, Will Deacon wrote:
>>>> On Wed, Apr 04, 2012 at 12:29:49AM +0100, Paul Walmsley wrote:
>>>>>
>>>>> Part of the problem is that the clockdomain data for the emu_sys 
>>>>> clockdomain is wrong.  Here's something to try to fix it.  It might just 
>>>>> be enough to get it to work.
>>>>
>>>> Hmm, doesn't seem to work but I do see the following in dmesg when I try to
>>>> use perf:
>>>>
>>>>  powerdomain: waited too long for powerdomain emu_pwrdm to complete transition
>>>>
>>>> which is new with your patch.
>>>
>>> Sorry to nag, but does anybody have a clue where to go from here? I can
>>> start digging in the OMAP PM code, but it's all new territory for me.
>>
>> I did a little playing around with this today and I think that I have figured out why this was not working (see below). Please can you try the following patch? I tried this on top of your series for perf/omap4. 
>>
>> Paul, FYI. If this works for Will then I can re-base on top of the latest linux-omap and submit to the mailing list.
>>
>> Also, the above error about the emu_pwrdm is odd too. I noticed that the emu_pwrdm is always in the transitioning state. And when I say always, I mean that even if I check the power domain state while u-boot is running it is in the transitioning state. So even before the kernel starts. 
>>
>> Cheers
>> Jon 
>>
>> From 9137ff9c1b382232de7443db0b51b7555846fb62 Mon Sep 17 00:00:00 2001
>> From: Jon Hunter <jon-hunter@ti.com>
>> Date: Fri, 4 May 2012 16:48:45 -0500
>> Subject: [PATCH] ARM: OMAP4: Disable auto enable for EMU CLKDM
>>
>> The flag CLKDM_CAN_HWSUP allows the clock-domain to automatically transition
>> to the enabled and disabled state. This means that as soon as we force a
>> software wake-up on the clock domain, the clock domain will be allowed to idle
>> and put back into the hardware auto state. For the EMU clock domain this is not
>> what we want. We want to keep the clock domain in the software wakeup state
>> while the clock domain is being used and put it back in to the hardware auto
>> state when we have finished using the clock domain.
>>
>> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
> 
> With this patch, how is the clkdm ever idled?

It does not! Sorry, I was so engrossed with figuring out why the EMU
clkdm was being idled as soon as it was enabled, I forgot to check if is
ever disabled once we terminated perf :-(

> IIUC, your patch will get PMU interrupts working, but similarily to
> previous patches in this thread, it works because it *never* allows the
> EMU clkdm to idle.  This is not a mergeable solution because it will not
> allow CORE retention (and thus full-chip retention.)

Right!

> What we need is a solution that allows the clkdm to idle, and then to be
> reinitialzed when it wakes up.  Due to the way (I understand) resets in
> the debugss, allowing the clkdm to idle will cause a reset, so the
> PMU/CTI interrupts need to be reinitialzied after wakeup.

Yes exactly I see that now. I have prototyped the 3 patches and this is
working AND the EMU clkdm does go back to idle. I can send out to the
list for review.

> Kevin
> 
> P.S. Please note there is also already a different fix in mainline for
> the EMU clkdm data from Paul which adds the force wakeup flag and
> removes the DISABLE_AUTO flag[1] (but leaves the ENABLE_AUTO flag,
> because the hardware is capable.)

Hmmm ... yes saw this, and you will have to excuse me as I don't fully
follow the logic here. In fact, I am thinking we want the opposite ;-)

>From looking, into this it seems to me that when PMU is running we want
the EMU clock domain in software-wakeup state and when PMU is not
running we want in the hardware auto state. By keeping the ENABLE_AUTO
flag set, as soon as we enable the clock domain it is put right back
into the HW_AUTO state and hence PMU is not working (see _enable()
function in arch/arm/mach-omap2/omap_hwmod.c)

So really what I think we want is to remove the ENABLE_AUTO flag to keep
the clock domain in software wake-up and use the DISABLE_AUTO flag to
put the clock domain back in HW_AUTO (note this requires a patch to
perform this 2nd part).

Cheers
Jon

Re: oprofile and ARM A9 hardware counter

[Kevin Hilman]

Jon Hunter <jon-hunter@ti.com> writes:

> Hi Kevin,
>
> On 05/07/2012 12:15 PM, Kevin Hilman wrote:
>> Jon Hunter <jon-hunter@ti.com> writes:
>> 
>>> Hi Will,
>>>
>>> On 04/26/2012 01:07 PM, Will Deacon wrote:
>>>> On Wed, Apr 04, 2012 at 12:15:24PM +0100, Will Deacon wrote:
>>>>> On Wed, Apr 04, 2012 at 12:29:49AM +0100, Paul Walmsley wrote:
>>>>>>
>>>>>> Part of the problem is that the clockdomain data for the emu_sys 
>>>>>> clockdomain is wrong.  Here's something to try to fix it.  It might just 
>>>>>> be enough to get it to work.
>>>>>
>>>>> Hmm, doesn't seem to work but I do see the following in dmesg when I try to
>>>>> use perf:
>>>>>
>>>>>  powerdomain: waited too long for powerdomain emu_pwrdm to complete transition
>>>>>
>>>>> which is new with your patch.
>>>>
>>>> Sorry to nag, but does anybody have a clue where to go from here? I can
>>>> start digging in the OMAP PM code, but it's all new territory for me.
>>>
>>> I did a little playing around with this today and I think that I have figured out why this was not working (see below). Please can you try the following patch? I tried this on top of your series for perf/omap4. 
>>>
>>> Paul, FYI. If this works for Will then I can re-base on top of the latest linux-omap and submit to the mailing list.
>>>
>>> Also, the above error about the emu_pwrdm is odd too. I noticed that the emu_pwrdm is always in the transitioning state. And when I say always, I mean that even if I check the power domain state while u-boot is running it is in the transitioning state. So even before the kernel starts. 
>>>
>>> Cheers
>>> Jon 
>>>
>>> From 9137ff9c1b382232de7443db0b51b7555846fb62 Mon Sep 17 00:00:00 2001
>>> From: Jon Hunter <jon-hunter@ti.com>
>>> Date: Fri, 4 May 2012 16:48:45 -0500
>>> Subject: [PATCH] ARM: OMAP4: Disable auto enable for EMU CLKDM
>>>
>>> The flag CLKDM_CAN_HWSUP allows the clock-domain to automatically transition
>>> to the enabled and disabled state. This means that as soon as we force a
>>> software wake-up on the clock domain, the clock domain will be allowed to idle
>>> and put back into the hardware auto state. For the EMU clock domain this is not
>>> what we want. We want to keep the clock domain in the software wakeup state
>>> while the clock domain is being used and put it back in to the hardware auto
>>> state when we have finished using the clock domain.
>>>
>>> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
>> 
>> With this patch, how is the clkdm ever idled?
>
> It does not! Sorry, I was so engrossed with figuring out why the EMU
> clkdm was being idled as soon as it was enabled, I forgot to check if is
> ever disabled once we terminated perf :-(
>
>> IIUC, your patch will get PMU interrupts working, but similarily to
>> previous patches in this thread, it works because it *never* allows the
>> EMU clkdm to idle.  This is not a mergeable solution because it will not
>> allow CORE retention (and thus full-chip retention.)
>
> Right!
>
>> What we need is a solution that allows the clkdm to idle, and then to be
>> reinitialzed when it wakes up.  Due to the way (I understand) resets in
>> the debugss, allowing the clkdm to idle will cause a reset, so the
>> PMU/CTI interrupts need to be reinitialzied after wakeup.
>
> Yes exactly I see that now. I have prototyped the 3 patches and this is
> working AND the EMU clkdm does go back to idle. I can send out to the
> list for review.

Perfect, thanks.

>> Kevin
>> 
>> P.S. Please note there is also already a different fix in mainline for
>> the EMU clkdm data from Paul which adds the force wakeup flag and
>> removes the DISABLE_AUTO flag[1] (but leaves the ENABLE_AUTO flag,
>> because the hardware is capable.)
>
> Hmmm ... yes saw this, and you will have to excuse me as I don't fully
> follow the logic here. In fact, I am thinking we want the opposite ;-)
>
> From looking, into this it seems to me that when PMU is running we want
> the EMU clock domain in software-wakeup state and when PMU is not
> running we want in the hardware auto state. 

So far, I'm with you.

> By keeping the ENABLE_AUTO flag set, as soon as we enable the clock
> domain it is put right back into the HW_AUTO state 

This is only because it was in the HWSUP state when _enable was called.
If clkdm_deny_idle() is used, that behavior will change.

> and hence PMU is
> not working (see _enable() function in
> arch/arm/mach-omap2/omap_hwmod.c)
>
> So really what I think we want is to remove the ENABLE_AUTO flag to keep
> the clock domain in software wake-up and use the DISABLE_AUTO flag to
> put the clock domain back in HW_AUTO (note this requires a patch to
> perform this 2nd part).

Well, Paul will have to comment here for the final word, but IIUC, the
hwmod flags are supposed to indicate only what the HW is capable of.  If
we want to change the runtime behavior, we nee to use (or add) APIs to
change the beahvior.  In this case, clkdm_allow_idle(),
clkdm_deny_idle() are probably what is needed here.

Kevin

oprofile and ARM A9 hardware counter

[Kevin Hilman]

Jon Hunter <jon-hunter@ti.com> writes:

> Hi Kevin,
>
> On 05/07/2012 12:15 PM, Kevin Hilman wrote:
>> Jon Hunter <jon-hunter@ti.com> writes:
>> 
>>> Hi Will,
>>>
>>> On 04/26/2012 01:07 PM, Will Deacon wrote:
>>>> On Wed, Apr 04, 2012 at 12:15:24PM +0100, Will Deacon wrote:
>>>>> On Wed, Apr 04, 2012 at 12:29:49AM +0100, Paul Walmsley wrote:
>>>>>>
>>>>>> Part of the problem is that the clockdomain data for the emu_sys 
>>>>>> clockdomain is wrong.  Here's something to try to fix it.  It might just 
>>>>>> be enough to get it to work.
>>>>>
>>>>> Hmm, doesn't seem to work but I do see the following in dmesg when I try to
>>>>> use perf:
>>>>>
>>>>>  powerdomain: waited too long for powerdomain emu_pwrdm to complete transition
>>>>>
>>>>> which is new with your patch.
>>>>
>>>> Sorry to nag, but does anybody have a clue where to go from here? I can
>>>> start digging in the OMAP PM code, but it's all new territory for me.
>>>
>>> I did a little playing around with this today and I think that I have figured out why this was not working (see below). Please can you try the following patch? I tried this on top of your series for perf/omap4. 
>>>
>>> Paul, FYI. If this works for Will then I can re-base on top of the latest linux-omap and submit to the mailing list.
>>>
>>> Also, the above error about the emu_pwrdm is odd too. I noticed that the emu_pwrdm is always in the transitioning state. And when I say always, I mean that even if I check the power domain state while u-boot is running it is in the transitioning state. So even before the kernel starts. 
>>>
>>> Cheers
>>> Jon 
>>>
>>> From 9137ff9c1b382232de7443db0b51b7555846fb62 Mon Sep 17 00:00:00 2001
>>> From: Jon Hunter <jon-hunter@ti.com>
>>> Date: Fri, 4 May 2012 16:48:45 -0500
>>> Subject: [PATCH] ARM: OMAP4: Disable auto enable for EMU CLKDM
>>>
>>> The flag CLKDM_CAN_HWSUP allows the clock-domain to automatically transition
>>> to the enabled and disabled state. This means that as soon as we force a
>>> software wake-up on the clock domain, the clock domain will be allowed to idle
>>> and put back into the hardware auto state. For the EMU clock domain this is not
>>> what we want. We want to keep the clock domain in the software wakeup state
>>> while the clock domain is being used and put it back in to the hardware auto
>>> state when we have finished using the clock domain.
>>>
>>> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
>> 
>> With this patch, how is the clkdm ever idled?
>
> It does not! Sorry, I was so engrossed with figuring out why the EMU
> clkdm was being idled as soon as it was enabled, I forgot to check if is
> ever disabled once we terminated perf :-(
>
>> IIUC, your patch will get PMU interrupts working, but similarily to
>> previous patches in this thread, it works because it *never* allows the
>> EMU clkdm to idle.  This is not a mergeable solution because it will not
>> allow CORE retention (and thus full-chip retention.)
>
> Right!
>
>> What we need is a solution that allows the clkdm to idle, and then to be
>> reinitialzed when it wakes up.  Due to the way (I understand) resets in
>> the debugss, allowing the clkdm to idle will cause a reset, so the
>> PMU/CTI interrupts need to be reinitialzied after wakeup.
>
> Yes exactly I see that now. I have prototyped the 3 patches and this is
> working AND the EMU clkdm does go back to idle. I can send out to the
> list for review.

Perfect, thanks.

>> Kevin
>> 
>> P.S. Please note there is also already a different fix in mainline for
>> the EMU clkdm data from Paul which adds the force wakeup flag and
>> removes the DISABLE_AUTO flag[1] (but leaves the ENABLE_AUTO flag,
>> because the hardware is capable.)
>
> Hmmm ... yes saw this, and you will have to excuse me as I don't fully
> follow the logic here. In fact, I am thinking we want the opposite ;-)
>
> From looking, into this it seems to me that when PMU is running we want
> the EMU clock domain in software-wakeup state and when PMU is not
> running we want in the hardware auto state. 

So far, I'm with you.

> By keeping the ENABLE_AUTO flag set, as soon as we enable the clock
> domain it is put right back into the HW_AUTO state 

This is only because it was in the HWSUP state when _enable was called.
If clkdm_deny_idle() is used, that behavior will change.

> and hence PMU is
> not working (see _enable() function in
> arch/arm/mach-omap2/omap_hwmod.c)
>
> So really what I think we want is to remove the ENABLE_AUTO flag to keep
> the clock domain in software wake-up and use the DISABLE_AUTO flag to
> put the clock domain back in HW_AUTO (note this requires a patch to
> perform this 2nd part).

Well, Paul will have to comment here for the final word, but IIUC, the
hwmod flags are supposed to indicate only what the HW is capable of.  If
we want to change the runtime behavior, we nee to use (or add) APIs to
change the beahvior.  In this case, clkdm_allow_idle(),
clkdm_deny_idle() are probably what is needed here.

Kevin

Re: oprofile and ARM A9 hardware counter

[Cousson, Benoit]

Hi Kevin & Jon,

On 5/8/2012 1:28 AM, Kevin Hilman wrote:
> Jon Hunter<jon-hunter@ti.com>  writes:
>
>> Hi Kevin,
>>
>> On 05/07/2012 12:15 PM, Kevin Hilman wrote:
>>> Jon Hunter<jon-hunter@ti.com>  writes:
>>>
>>>> Hi Will,
>>>>
>>>> On 04/26/2012 01:07 PM, Will Deacon wrote:
>>>>> On Wed, Apr 04, 2012 at 12:15:24PM +0100, Will Deacon wrote:
>>>>>> On Wed, Apr 04, 2012 at 12:29:49AM +0100, Paul Walmsley wrote:
>>>>>>>
>>>>>>> Part of the problem is that the clockdomain data for the emu_sys
>>>>>>> clockdomain is wrong.  Here's something to try to fix it.  It might just
>>>>>>> be enough to get it to work.
>>>>>>
>>>>>> Hmm, doesn't seem to work but I do see the following in dmesg when I try to
>>>>>> use perf:
>>>>>>
>>>>>>   powerdomain: waited too long for powerdomain emu_pwrdm to complete transition
>>>>>>
>>>>>> which is new with your patch.
>>>>>
>>>>> Sorry to nag, but does anybody have a clue where to go from here? I can
>>>>> start digging in the OMAP PM code, but it's all new territory for me.
>>>>
>>>> I did a little playing around with this today and I think that I have figured out why this was not working (see below). Please can you try the following patch? I tried this on top of your series for perf/omap4.
>>>>
>>>> Paul, FYI. If this works for Will then I can re-base on top of the latest linux-omap and submit to the mailing list.
>>>>
>>>> Also, the above error about the emu_pwrdm is odd too. I noticed that the emu_pwrdm is always in the transitioning state. And when I say always, I mean that even if I check the power domain state while u-boot is running it is in the transitioning state. So even before the kernel starts.
>>>>
>>>> Cheers
>>>> Jon
>>>>
>>>>  From 9137ff9c1b382232de7443db0b51b7555846fb62 Mon Sep 17 00:00:00 2001
>>>> From: Jon Hunter<jon-hunter@ti.com>
>>>> Date: Fri, 4 May 2012 16:48:45 -0500
>>>> Subject: [PATCH] ARM: OMAP4: Disable auto enable for EMU CLKDM
>>>>
>>>> The flag CLKDM_CAN_HWSUP allows the clock-domain to automatically transition
>>>> to the enabled and disabled state. This means that as soon as we force a
>>>> software wake-up on the clock domain, the clock domain will be allowed to idle
>>>> and put back into the hardware auto state. For the EMU clock domain this is not
>>>> what we want. We want to keep the clock domain in the software wakeup state
>>>> while the clock domain is being used and put it back in to the hardware auto
>>>> state when we have finished using the clock domain.
>>>>
>>>> Signed-off-by: Jon Hunter<jon-hunter@ti.com>
>>>
>>> With this patch, how is the clkdm ever idled?
>>
>> It does not! Sorry, I was so engrossed with figuring out why the EMU
>> clkdm was being idled as soon as it was enabled, I forgot to check if is
>> ever disabled once we terminated perf :-(
>>
>>> IIUC, your patch will get PMU interrupts working, but similarily to
>>> previous patches in this thread, it works because it *never* allows the
>>> EMU clkdm to idle.  This is not a mergeable solution because it will not
>>> allow CORE retention (and thus full-chip retention.)
>>
>> Right!
>>
>>> What we need is a solution that allows the clkdm to idle, and then to be
>>> reinitialzed when it wakes up.  Due to the way (I understand) resets in
>>> the debugss, allowing the clkdm to idle will cause a reset, so the
>>> PMU/CTI interrupts need to be reinitialzied after wakeup.
>>
>> Yes exactly I see that now. I have prototyped the 3 patches and this is
>> working AND the EMU clkdm does go back to idle. I can send out to the
>> list for review.
>
> Perfect, thanks.
>
>>> Kevin
>>>
>>> P.S. Please note there is also already a different fix in mainline for
>>> the EMU clkdm data from Paul which adds the force wakeup flag and
>>> removes the DISABLE_AUTO flag[1] (but leaves the ENABLE_AUTO flag,
>>> because the hardware is capable.)
>>
>> Hmmm ... yes saw this, and you will have to excuse me as I don't fully
>> follow the logic here. In fact, I am thinking we want the opposite ;-)
>>
>>  From looking, into this it seems to me that when PMU is running we want
>> the EMU clock domain in software-wakeup state and when PMU is not
>> running we want in the hardware auto state.
>
> So far, I'm with you.
>
>> By keeping the ENABLE_AUTO flag set, as soon as we enable the clock
>> domain it is put right back into the HW_AUTO state
>
> This is only because it was in the HWSUP state when _enable was called.
> If clkdm_deny_idle() is used, that behavior will change.
>
>> and hence PMU is
>> not working (see _enable() function in
>> arch/arm/mach-omap2/omap_hwmod.c)
>>
>> So really what I think we want is to remove the ENABLE_AUTO flag to keep
>> the clock domain in software wake-up and use the DISABLE_AUTO flag to
>> put the clock domain back in HW_AUTO (note this requires a patch to
>> perform this 2nd part).
>
> Well, Paul will have to comment here for the final word, but IIUC, the
> hwmod flags are supposed to indicate only what the HW is capable of.  If
> we want to change the runtime behavior, we nee to use (or add) APIs to
> change the beahvior.  In this case, clkdm_allow_idle(),
> clkdm_deny_idle() are probably what is needed here.

Yes, indeed, we should not hack the flags to fix that kind of issue. The 
flags describe what the HW is capable of, and the EMU CD can support 
HW_AUTO and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the 
only valid next power state is OFF, meaning that no retention mode is 
supported. So any transition to idle will go to OFF and lead to a reset 
upon wakeup.

That being said, being able to transition to OFF during idle is a 
perfectly valid state for most powerdomain in OMAP anyway, so we should 
be able to restore from OFF mode smoothly.

It looks to me that what is missing here is *just* a restore path in the 
PMU/CTI code. But I'm probably missing some nasty details in this issue :-)

Regards,
Benoit

oprofile and ARM A9 hardware counter

[Cousson, Benoit]

Hi Kevin & Jon,

On 5/8/2012 1:28 AM, Kevin Hilman wrote:
> Jon Hunter<jon-hunter@ti.com>  writes:
>
>> Hi Kevin,
>>
>> On 05/07/2012 12:15 PM, Kevin Hilman wrote:
>>> Jon Hunter<jon-hunter@ti.com>  writes:
>>>
>>>> Hi Will,
>>>>
>>>> On 04/26/2012 01:07 PM, Will Deacon wrote:
>>>>> On Wed, Apr 04, 2012 at 12:15:24PM +0100, Will Deacon wrote:
>>>>>> On Wed, Apr 04, 2012 at 12:29:49AM +0100, Paul Walmsley wrote:
>>>>>>>
>>>>>>> Part of the problem is that the clockdomain data for the emu_sys
>>>>>>> clockdomain is wrong.  Here's something to try to fix it.  It might just
>>>>>>> be enough to get it to work.
>>>>>>
>>>>>> Hmm, doesn't seem to work but I do see the following in dmesg when I try to
>>>>>> use perf:
>>>>>>
>>>>>>   powerdomain: waited too long for powerdomain emu_pwrdm to complete transition
>>>>>>
>>>>>> which is new with your patch.
>>>>>
>>>>> Sorry to nag, but does anybody have a clue where to go from here? I can
>>>>> start digging in the OMAP PM code, but it's all new territory for me.
>>>>
>>>> I did a little playing around with this today and I think that I have figured out why this was not working (see below). Please can you try the following patch? I tried this on top of your series for perf/omap4.
>>>>
>>>> Paul, FYI. If this works for Will then I can re-base on top of the latest linux-omap and submit to the mailing list.
>>>>
>>>> Also, the above error about the emu_pwrdm is odd too. I noticed that the emu_pwrdm is always in the transitioning state. And when I say always, I mean that even if I check the power domain state while u-boot is running it is in the transitioning state. So even before the kernel starts.
>>>>
>>>> Cheers
>>>> Jon
>>>>
>>>>  From 9137ff9c1b382232de7443db0b51b7555846fb62 Mon Sep 17 00:00:00 2001
>>>> From: Jon Hunter<jon-hunter@ti.com>
>>>> Date: Fri, 4 May 2012 16:48:45 -0500
>>>> Subject: [PATCH] ARM: OMAP4: Disable auto enable for EMU CLKDM
>>>>
>>>> The flag CLKDM_CAN_HWSUP allows the clock-domain to automatically transition
>>>> to the enabled and disabled state. This means that as soon as we force a
>>>> software wake-up on the clock domain, the clock domain will be allowed to idle
>>>> and put back into the hardware auto state. For the EMU clock domain this is not
>>>> what we want. We want to keep the clock domain in the software wakeup state
>>>> while the clock domain is being used and put it back in to the hardware auto
>>>> state when we have finished using the clock domain.
>>>>
>>>> Signed-off-by: Jon Hunter<jon-hunter@ti.com>
>>>
>>> With this patch, how is the clkdm ever idled?
>>
>> It does not! Sorry, I was so engrossed with figuring out why the EMU
>> clkdm was being idled as soon as it was enabled, I forgot to check if is
>> ever disabled once we terminated perf :-(
>>
>>> IIUC, your patch will get PMU interrupts working, but similarily to
>>> previous patches in this thread, it works because it *never* allows the
>>> EMU clkdm to idle.  This is not a mergeable solution because it will not
>>> allow CORE retention (and thus full-chip retention.)
>>
>> Right!
>>
>>> What we need is a solution that allows the clkdm to idle, and then to be
>>> reinitialzed when it wakes up.  Due to the way (I understand) resets in
>>> the debugss, allowing the clkdm to idle will cause a reset, so the
>>> PMU/CTI interrupts need to be reinitialzied after wakeup.
>>
>> Yes exactly I see that now. I have prototyped the 3 patches and this is
>> working AND the EMU clkdm does go back to idle. I can send out to the
>> list for review.
>
> Perfect, thanks.
>
>>> Kevin
>>>
>>> P.S. Please note there is also already a different fix in mainline for
>>> the EMU clkdm data from Paul which adds the force wakeup flag and
>>> removes the DISABLE_AUTO flag[1] (but leaves the ENABLE_AUTO flag,
>>> because the hardware is capable.)
>>
>> Hmmm ... yes saw this, and you will have to excuse me as I don't fully
>> follow the logic here. In fact, I am thinking we want the opposite ;-)
>>
>>  From looking, into this it seems to me that when PMU is running we want
>> the EMU clock domain in software-wakeup state and when PMU is not
>> running we want in the hardware auto state.
>
> So far, I'm with you.
>
>> By keeping the ENABLE_AUTO flag set, as soon as we enable the clock
>> domain it is put right back into the HW_AUTO state
>
> This is only because it was in the HWSUP state when _enable was called.
> If clkdm_deny_idle() is used, that behavior will change.
>
>> and hence PMU is
>> not working (see _enable() function in
>> arch/arm/mach-omap2/omap_hwmod.c)
>>
>> So really what I think we want is to remove the ENABLE_AUTO flag to keep
>> the clock domain in software wake-up and use the DISABLE_AUTO flag to
>> put the clock domain back in HW_AUTO (note this requires a patch to
>> perform this 2nd part).
>
> Well, Paul will have to comment here for the final word, but IIUC, the
> hwmod flags are supposed to indicate only what the HW is capable of.  If
> we want to change the runtime behavior, we nee to use (or add) APIs to
> change the beahvior.  In this case, clkdm_allow_idle(),
> clkdm_deny_idle() are probably what is needed here.

Yes, indeed, we should not hack the flags to fix that kind of issue. The 
flags describe what the HW is capable of, and the EMU CD can support 
HW_AUTO and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the 
only valid next power state is OFF, meaning that no retention mode is 
supported. So any transition to idle will go to OFF and lead to a reset 
upon wakeup.

That being said, being able to transition to OFF during idle is a 
perfectly valid state for most powerdomain in OMAP anyway, so we should 
be able to restore from OFF mode smoothly.

It looks to me that what is missing here is *just* a restore path in the 
PMU/CTI code. But I'm probably missing some nasty details in this issue :-)

Regards,
Benoit

Re: oprofile and ARM A9 hardware counter

[Jean Pihet]

Hi Benoit,

On Tue, May 8, 2012 at 1:01 PM, Cousson, Benoit <b-cousson@ti.com> wrote:
> Hi Kevin & Jon,
>
>
> On 5/8/2012 1:28 AM, Kevin Hilman wrote:
>>
>> Jon Hunter<jon-hunter@ti.com>  writes:
>>
>>> Hi Kevin,
>>>
>>> On 05/07/2012 12:15 PM, Kevin Hilman wrote:
>>>>
>>>> Jon Hunter<jon-hunter@ti.com>  writes:
>>>>
>>>>> Hi Will,
>>>>>
>>>>> On 04/26/2012 01:07 PM, Will Deacon wrote:
>>>>>>
>>>>>> On Wed, Apr 04, 2012 at 12:15:24PM +0100, Will Deacon wrote:
>>>>>>>
>>>>>>> On Wed, Apr 04, 2012 at 12:29:49AM +0100, Paul Walmsley wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> Part of the problem is that the clockdomain data for the emu_sys
>>>>>>>> clockdomain is wrong.  Here's something to try to fix it.  It might
>>>>>>>> just
>>>>>>>> be enough to get it to work.
>>>>>>>
>>>>>>>
>>>>>>> Hmm, doesn't seem to work but I do see the following in dmesg when I
>>>>>>> try to
>>>>>>> use perf:
>>>>>>>
>>>>>>>  powerdomain: waited too long for powerdomain emu_pwrdm to complete
>>>>>>> transition
>>>>>>>
>>>>>>> which is new with your patch.
>>>>>>
>>>>>>
>>>>>> Sorry to nag, but does anybody have a clue where to go from here? I
>>>>>> can
>>>>>> start digging in the OMAP PM code, but it's all new territory for me.
>>>>>
>>>>>
>>>>> I did a little playing around with this today and I think that I have
>>>>> figured out why this was not working (see below). Please can you try the
>>>>> following patch? I tried this on top of your series for perf/omap4.
>>>>>
>>>>> Paul, FYI. If this works for Will then I can re-base on top of the
>>>>> latest linux-omap and submit to the mailing list.
>>>>>
>>>>> Also, the above error about the emu_pwrdm is odd too. I noticed that
>>>>> the emu_pwrdm is always in the transitioning state. And when I say always, I
>>>>> mean that even if I check the power domain state while u-boot is running it
>>>>> is in the transitioning state. So even before the kernel starts.
>>>>>
>>>>> Cheers
>>>>> Jon
>>>>>
>>>>>  From 9137ff9c1b382232de7443db0b51b7555846fb62 Mon Sep 17 00:00:00 2001
>>>>> From: Jon Hunter<jon-hunter@ti.com>
>>>>> Date: Fri, 4 May 2012 16:48:45 -0500
>>>>> Subject: [PATCH] ARM: OMAP4: Disable auto enable for EMU CLKDM
>>>>>
>>>>> The flag CLKDM_CAN_HWSUP allows the clock-domain to automatically
>>>>> transition
>>>>> to the enabled and disabled state. This means that as soon as we force
>>>>> a
>>>>> software wake-up on the clock domain, the clock domain will be allowed
>>>>> to idle
>>>>> and put back into the hardware auto state. For the EMU clock domain
>>>>> this is not
>>>>> what we want. We want to keep the clock domain in the software wakeup
>>>>> state
>>>>> while the clock domain is being used and put it back in to the hardware
>>>>> auto
>>>>> state when we have finished using the clock domain.
>>>>>
>>>>> Signed-off-by: Jon Hunter<jon-hunter@ti.com>
>>>>
>>>>
>>>> With this patch, how is the clkdm ever idled?
>>>
>>>
>>> It does not! Sorry, I was so engrossed with figuring out why the EMU
>>> clkdm was being idled as soon as it was enabled, I forgot to check if is
>>> ever disabled once we terminated perf :-(
>>>
>>>> IIUC, your patch will get PMU interrupts working, but similarily to
>>>> previous patches in this thread, it works because it *never* allows the
>>>> EMU clkdm to idle.  This is not a mergeable solution because it will not
>>>> allow CORE retention (and thus full-chip retention.)
>>>
>>>
>>> Right!
>>>
>>>> What we need is a solution that allows the clkdm to idle, and then to be
>>>> reinitialzed when it wakes up.  Due to the way (I understand) resets in
>>>> the debugss, allowing the clkdm to idle will cause a reset, so the
>>>> PMU/CTI interrupts need to be reinitialzied after wakeup.
>>>
>>>
>>> Yes exactly I see that now. I have prototyped the 3 patches and this is
>>> working AND the EMU clkdm does go back to idle. I can send out to the
>>> list for review.
>>
>>
>> Perfect, thanks.
>>
>>>> Kevin
>>>>
>>>> P.S. Please note there is also already a different fix in mainline for
>>>> the EMU clkdm data from Paul which adds the force wakeup flag and
>>>> removes the DISABLE_AUTO flag[1] (but leaves the ENABLE_AUTO flag,
>>>> because the hardware is capable.)
>>>
>>>
>>> Hmmm ... yes saw this, and you will have to excuse me as I don't fully
>>> follow the logic here. In fact, I am thinking we want the opposite ;-)
>>>
>>>  From looking, into this it seems to me that when PMU is running we want
>>> the EMU clock domain in software-wakeup state and when PMU is not
>>> running we want in the hardware auto state.
>>
>>
>> So far, I'm with you.
>>
>>> By keeping the ENABLE_AUTO flag set, as soon as we enable the clock
>>> domain it is put right back into the HW_AUTO state
>>
>>
>> This is only because it was in the HWSUP state when _enable was called.
>> If clkdm_deny_idle() is used, that behavior will change.
>>
>>> and hence PMU is
>>> not working (see _enable() function in
>>> arch/arm/mach-omap2/omap_hwmod.c)
>>>
>>> So really what I think we want is to remove the ENABLE_AUTO flag to keep
>>> the clock domain in software wake-up and use the DISABLE_AUTO flag to
>>> put the clock domain back in HW_AUTO (note this requires a patch to
>>> perform this 2nd part).
>>
>>
>> Well, Paul will have to comment here for the final word, but IIUC, the
>> hwmod flags are supposed to indicate only what the HW is capable of.  If
>> we want to change the runtime behavior, we nee to use (or add) APIs to
>> change the beahvior.  In this case, clkdm_allow_idle(),
>> clkdm_deny_idle() are probably what is needed here.
>
>
> Yes, indeed, we should not hack the flags to fix that kind of issue. The
> flags describe what the HW is capable of, and the EMU CD can support HW_AUTO
> and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the only valid next
> power state is OFF, meaning that no retention mode is supported. So any
> transition to idle will go to OFF and lead to a reset upon wakeup.
>
> That being said, being able to transition to OFF during idle is a perfectly
> valid state for most powerdomain in OMAP anyway, so we should be able to
> restore from OFF mode smoothly.
>
> It looks to me that what is missing here is *just* a restore path in the
> PMU/CTI code. But I'm probably missing some nasty details in this issue :-)
Although it is perfectly feasible to have a seamless transition of the
EMU power domain, I think the PMU counters will not be accurate
anymore since they stop counting events when going to OFF and re-start
after the state restore.

>
> Regards,
> Benoit

Regards,
Jean

>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

oprofile and ARM A9 hardware counter

[Jean Pihet]

Hi Benoit,

On Tue, May 8, 2012 at 1:01 PM, Cousson, Benoit <b-cousson@ti.com> wrote:
> Hi Kevin & Jon,
>
>
> On 5/8/2012 1:28 AM, Kevin Hilman wrote:
>>
>> Jon Hunter<jon-hunter@ti.com> ?writes:
>>
>>> Hi Kevin,
>>>
>>> On 05/07/2012 12:15 PM, Kevin Hilman wrote:
>>>>
>>>> Jon Hunter<jon-hunter@ti.com> ?writes:
>>>>
>>>>> Hi Will,
>>>>>
>>>>> On 04/26/2012 01:07 PM, Will Deacon wrote:
>>>>>>
>>>>>> On Wed, Apr 04, 2012 at 12:15:24PM +0100, Will Deacon wrote:
>>>>>>>
>>>>>>> On Wed, Apr 04, 2012 at 12:29:49AM +0100, Paul Walmsley wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> Part of the problem is that the clockdomain data for the emu_sys
>>>>>>>> clockdomain is wrong. ?Here's something to try to fix it. ?It might
>>>>>>>> just
>>>>>>>> be enough to get it to work.
>>>>>>>
>>>>>>>
>>>>>>> Hmm, doesn't seem to work but I do see the following in dmesg when I
>>>>>>> try to
>>>>>>> use perf:
>>>>>>>
>>>>>>> ?powerdomain: waited too long for powerdomain emu_pwrdm to complete
>>>>>>> transition
>>>>>>>
>>>>>>> which is new with your patch.
>>>>>>
>>>>>>
>>>>>> Sorry to nag, but does anybody have a clue where to go from here? I
>>>>>> can
>>>>>> start digging in the OMAP PM code, but it's all new territory for me.
>>>>>
>>>>>
>>>>> I did a little playing around with this today and I think that I have
>>>>> figured out why this was not working (see below). Please can you try the
>>>>> following patch? I tried this on top of your series for perf/omap4.
>>>>>
>>>>> Paul, FYI. If this works for Will then I can re-base on top of the
>>>>> latest linux-omap and submit to the mailing list.
>>>>>
>>>>> Also, the above error about the emu_pwrdm is odd too. I noticed that
>>>>> the emu_pwrdm is always in the transitioning state. And when I say always, I
>>>>> mean that even if I check the power domain state while u-boot is running it
>>>>> is in the transitioning state. So even before the kernel starts.
>>>>>
>>>>> Cheers
>>>>> Jon
>>>>>
>>>>> ?From 9137ff9c1b382232de7443db0b51b7555846fb62 Mon Sep 17 00:00:00 2001
>>>>> From: Jon Hunter<jon-hunter@ti.com>
>>>>> Date: Fri, 4 May 2012 16:48:45 -0500
>>>>> Subject: [PATCH] ARM: OMAP4: Disable auto enable for EMU CLKDM
>>>>>
>>>>> The flag CLKDM_CAN_HWSUP allows the clock-domain to automatically
>>>>> transition
>>>>> to the enabled and disabled state. This means that as soon as we force
>>>>> a
>>>>> software wake-up on the clock domain, the clock domain will be allowed
>>>>> to idle
>>>>> and put back into the hardware auto state. For the EMU clock domain
>>>>> this is not
>>>>> what we want. We want to keep the clock domain in the software wakeup
>>>>> state
>>>>> while the clock domain is being used and put it back in to the hardware
>>>>> auto
>>>>> state when we have finished using the clock domain.
>>>>>
>>>>> Signed-off-by: Jon Hunter<jon-hunter@ti.com>
>>>>
>>>>
>>>> With this patch, how is the clkdm ever idled?
>>>
>>>
>>> It does not! Sorry, I was so engrossed with figuring out why the EMU
>>> clkdm was being idled as soon as it was enabled, I forgot to check if is
>>> ever disabled once we terminated perf :-(
>>>
>>>> IIUC, your patch will get PMU interrupts working, but similarily to
>>>> previous patches in this thread, it works because it *never* allows the
>>>> EMU clkdm to idle. ?This is not a mergeable solution because it will not
>>>> allow CORE retention (and thus full-chip retention.)
>>>
>>>
>>> Right!
>>>
>>>> What we need is a solution that allows the clkdm to idle, and then to be
>>>> reinitialzed when it wakes up. ?Due to the way (I understand) resets in
>>>> the debugss, allowing the clkdm to idle will cause a reset, so the
>>>> PMU/CTI interrupts need to be reinitialzied after wakeup.
>>>
>>>
>>> Yes exactly I see that now. I have prototyped the 3 patches and this is
>>> working AND the EMU clkdm does go back to idle. I can send out to the
>>> list for review.
>>
>>
>> Perfect, thanks.
>>
>>>> Kevin
>>>>
>>>> P.S. Please note there is also already a different fix in mainline for
>>>> the EMU clkdm data from Paul which adds the force wakeup flag and
>>>> removes the DISABLE_AUTO flag[1] (but leaves the ENABLE_AUTO flag,
>>>> because the hardware is capable.)
>>>
>>>
>>> Hmmm ... yes saw this, and you will have to excuse me as I don't fully
>>> follow the logic here. In fact, I am thinking we want the opposite ;-)
>>>
>>> ?From looking, into this it seems to me that when PMU is running we want
>>> the EMU clock domain in software-wakeup state and when PMU is not
>>> running we want in the hardware auto state.
>>
>>
>> So far, I'm with you.
>>
>>> By keeping the ENABLE_AUTO flag set, as soon as we enable the clock
>>> domain it is put right back into the HW_AUTO state
>>
>>
>> This is only because it was in the HWSUP state when _enable was called.
>> If clkdm_deny_idle() is used, that behavior will change.
>>
>>> and hence PMU is
>>> not working (see _enable() function in
>>> arch/arm/mach-omap2/omap_hwmod.c)
>>>
>>> So really what I think we want is to remove the ENABLE_AUTO flag to keep
>>> the clock domain in software wake-up and use the DISABLE_AUTO flag to
>>> put the clock domain back in HW_AUTO (note this requires a patch to
>>> perform this 2nd part).
>>
>>
>> Well, Paul will have to comment here for the final word, but IIUC, the
>> hwmod flags are supposed to indicate only what the HW is capable of. ?If
>> we want to change the runtime behavior, we nee to use (or add) APIs to
>> change the beahvior. ?In this case, clkdm_allow_idle(),
>> clkdm_deny_idle() are probably what is needed here.
>
>
> Yes, indeed, we should not hack the flags to fix that kind of issue. The
> flags describe what the HW is capable of, and the EMU CD can support HW_AUTO
> and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the only valid next
> power state is OFF, meaning that no retention mode is supported. So any
> transition to idle will go to OFF and lead to a reset upon wakeup.
>
> That being said, being able to transition to OFF during idle is a perfectly
> valid state for most powerdomain in OMAP anyway, so we should be able to
> restore from OFF mode smoothly.
>
> It looks to me that what is missing here is *just* a restore path in the
> PMU/CTI code. But I'm probably missing some nasty details in this issue :-)
Although it is perfectly feasible to have a seamless transition of the
EMU power domain, I think the PMU counters will not be accurate
anymore since they stop counting events when going to OFF and re-start
after the state restore.

>
> Regards,
> Benoit

Regards,
Jean

>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html

Re: oprofile and ARM A9 hardware counter

[Cousson, Benoit]

Salut Jean,

On 5/8/2012 1:23 PM, Jean Pihet wrote:
> Hi Benoit,
>
> On Tue, May 8, 2012 at 1:01 PM, Cousson, Benoit<b-cousson@ti.com>  wrote:
>> Hi Kevin&  Jon,
>>
>>
>> On 5/8/2012 1:28 AM, Kevin Hilman wrote:
>>>
>>> Jon Hunter<jon-hunter@ti.com>    writes:
>>>
>>>> Hi Kevin,
>>>>
>>>> On 05/07/2012 12:15 PM, Kevin Hilman wrote:
>>>>>
>>>>> Jon Hunter<jon-hunter@ti.com>    writes:
>>>>>
>>>>>> Hi Will,
>>>>>>
>>>>>> On 04/26/2012 01:07 PM, Will Deacon wrote:
>>>>>>>
>>>>>>> On Wed, Apr 04, 2012 at 12:15:24PM +0100, Will Deacon wrote:
>>>>>>>>
>>>>>>>> On Wed, Apr 04, 2012 at 12:29:49AM +0100, Paul Walmsley wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Part of the problem is that the clockdomain data for the emu_sys
>>>>>>>>> clockdomain is wrong.  Here's something to try to fix it.  It might
>>>>>>>>> just
>>>>>>>>> be enough to get it to work.
>>>>>>>>
>>>>>>>>
>>>>>>>> Hmm, doesn't seem to work but I do see the following in dmesg when I
>>>>>>>> try to
>>>>>>>> use perf:
>>>>>>>>
>>>>>>>>   powerdomain: waited too long for powerdomain emu_pwrdm to complete
>>>>>>>> transition
>>>>>>>>
>>>>>>>> which is new with your patch.
>>>>>>>
>>>>>>>
>>>>>>> Sorry to nag, but does anybody have a clue where to go from here? I
>>>>>>> can
>>>>>>> start digging in the OMAP PM code, but it's all new territory for me.
>>>>>>
>>>>>>
>>>>>> I did a little playing around with this today and I think that I have
>>>>>> figured out why this was not working (see below). Please can you try the
>>>>>> following patch? I tried this on top of your series for perf/omap4.
>>>>>>
>>>>>> Paul, FYI. If this works for Will then I can re-base on top of the
>>>>>> latest linux-omap and submit to the mailing list.
>>>>>>
>>>>>> Also, the above error about the emu_pwrdm is odd too. I noticed that
>>>>>> the emu_pwrdm is always in the transitioning state. And when I say always, I
>>>>>> mean that even if I check the power domain state while u-boot is running it
>>>>>> is in the transitioning state. So even before the kernel starts.
>>>>>>
>>>>>> Cheers
>>>>>> Jon
>>>>>>
>>>>>>   From 9137ff9c1b382232de7443db0b51b7555846fb62 Mon Sep 17 00:00:00 2001
>>>>>> From: Jon Hunter<jon-hunter@ti.com>
>>>>>> Date: Fri, 4 May 2012 16:48:45 -0500
>>>>>> Subject: [PATCH] ARM: OMAP4: Disable auto enable for EMU CLKDM
>>>>>>
>>>>>> The flag CLKDM_CAN_HWSUP allows the clock-domain to automatically
>>>>>> transition
>>>>>> to the enabled and disabled state. This means that as soon as we force
>>>>>> a
>>>>>> software wake-up on the clock domain, the clock domain will be allowed
>>>>>> to idle
>>>>>> and put back into the hardware auto state. For the EMU clock domain
>>>>>> this is not
>>>>>> what we want. We want to keep the clock domain in the software wakeup
>>>>>> state
>>>>>> while the clock domain is being used and put it back in to the hardware
>>>>>> auto
>>>>>> state when we have finished using the clock domain.
>>>>>>
>>>>>> Signed-off-by: Jon Hunter<jon-hunter@ti.com>
>>>>>
>>>>>
>>>>> With this patch, how is the clkdm ever idled?
>>>>
>>>>
>>>> It does not! Sorry, I was so engrossed with figuring out why the EMU
>>>> clkdm was being idled as soon as it was enabled, I forgot to check if is
>>>> ever disabled once we terminated perf :-(
>>>>
>>>>> IIUC, your patch will get PMU interrupts working, but similarily to
>>>>> previous patches in this thread, it works because it *never* allows the
>>>>> EMU clkdm to idle.  This is not a mergeable solution because it will not
>>>>> allow CORE retention (and thus full-chip retention.)
>>>>
>>>>
>>>> Right!
>>>>
>>>>> What we need is a solution that allows the clkdm to idle, and then to be
>>>>> reinitialzed when it wakes up.  Due to the way (I understand) resets in
>>>>> the debugss, allowing the clkdm to idle will cause a reset, so the
>>>>> PMU/CTI interrupts need to be reinitialzied after wakeup.
>>>>
>>>>
>>>> Yes exactly I see that now. I have prototyped the 3 patches and this is
>>>> working AND the EMU clkdm does go back to idle. I can send out to the
>>>> list for review.
>>>
>>>
>>> Perfect, thanks.
>>>
>>>>> Kevin
>>>>>
>>>>> P.S. Please note there is also already a different fix in mainline for
>>>>> the EMU clkdm data from Paul which adds the force wakeup flag and
>>>>> removes the DISABLE_AUTO flag[1] (but leaves the ENABLE_AUTO flag,
>>>>> because the hardware is capable.)
>>>>
>>>>
>>>> Hmmm ... yes saw this, and you will have to excuse me as I don't fully
>>>> follow the logic here. In fact, I am thinking we want the opposite ;-)
>>>>
>>>>   From looking, into this it seems to me that when PMU is running we want
>>>> the EMU clock domain in software-wakeup state and when PMU is not
>>>> running we want in the hardware auto state.
>>>
>>>
>>> So far, I'm with you.
>>>
>>>> By keeping the ENABLE_AUTO flag set, as soon as we enable the clock
>>>> domain it is put right back into the HW_AUTO state
>>>
>>>
>>> This is only because it was in the HWSUP state when _enable was called.
>>> If clkdm_deny_idle() is used, that behavior will change.
>>>
>>>> and hence PMU is
>>>> not working (see _enable() function in
>>>> arch/arm/mach-omap2/omap_hwmod.c)
>>>>
>>>> So really what I think we want is to remove the ENABLE_AUTO flag to keep
>>>> the clock domain in software wake-up and use the DISABLE_AUTO flag to
>>>> put the clock domain back in HW_AUTO (note this requires a patch to
>>>> perform this 2nd part).
>>>
>>>
>>> Well, Paul will have to comment here for the final word, but IIUC, the
>>> hwmod flags are supposed to indicate only what the HW is capable of.  If
>>> we want to change the runtime behavior, we nee to use (or add) APIs to
>>> change the beahvior.  In this case, clkdm_allow_idle(),
>>> clkdm_deny_idle() are probably what is needed here.
>>
>>
>> Yes, indeed, we should not hack the flags to fix that kind of issue. The
>> flags describe what the HW is capable of, and the EMU CD can support HW_AUTO
>> and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the only valid next
>> power state is OFF, meaning that no retention mode is supported. So any
>> transition to idle will go to OFF and lead to a reset upon wakeup.
>>
>> That being said, being able to transition to OFF during idle is a perfectly
>> valid state for most powerdomain in OMAP anyway, so we should be able to
>> restore from OFF mode smoothly.
>>
>> It looks to me that what is missing here is *just* a restore path in the
>> PMU/CTI code. But I'm probably missing some nasty details in this issue :-)
> Although it is perfectly feasible to have a seamless transition of the
> EMU power domain, I think the PMU counters will not be accurate
> anymore since they stop counting events when going to OFF and re-start
> after the state restore.

Good point, but I think the PMU might still works fine because located 
inside the MPU domain. AFAIR, only the path to access the PMU and the 
CTI is going to OFF and thus will be reset.
But that whole DEBUGSS is such a nightmare, that I'm not 100% sure about 
that :-)

Regards,
Benoit

oprofile and ARM A9 hardware counter

[Cousson, Benoit]

Salut Jean,

On 5/8/2012 1:23 PM, Jean Pihet wrote:
> Hi Benoit,
>
> On Tue, May 8, 2012 at 1:01 PM, Cousson, Benoit<b-cousson@ti.com>  wrote:
>> Hi Kevin&  Jon,
>>
>>
>> On 5/8/2012 1:28 AM, Kevin Hilman wrote:
>>>
>>> Jon Hunter<jon-hunter@ti.com>    writes:
>>>
>>>> Hi Kevin,
>>>>
>>>> On 05/07/2012 12:15 PM, Kevin Hilman wrote:
>>>>>
>>>>> Jon Hunter<jon-hunter@ti.com>    writes:
>>>>>
>>>>>> Hi Will,
>>>>>>
>>>>>> On 04/26/2012 01:07 PM, Will Deacon wrote:
>>>>>>>
>>>>>>> On Wed, Apr 04, 2012 at 12:15:24PM +0100, Will Deacon wrote:
>>>>>>>>
>>>>>>>> On Wed, Apr 04, 2012 at 12:29:49AM +0100, Paul Walmsley wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Part of the problem is that the clockdomain data for the emu_sys
>>>>>>>>> clockdomain is wrong.  Here's something to try to fix it.  It might
>>>>>>>>> just
>>>>>>>>> be enough to get it to work.
>>>>>>>>
>>>>>>>>
>>>>>>>> Hmm, doesn't seem to work but I do see the following in dmesg when I
>>>>>>>> try to
>>>>>>>> use perf:
>>>>>>>>
>>>>>>>>   powerdomain: waited too long for powerdomain emu_pwrdm to complete
>>>>>>>> transition
>>>>>>>>
>>>>>>>> which is new with your patch.
>>>>>>>
>>>>>>>
>>>>>>> Sorry to nag, but does anybody have a clue where to go from here? I
>>>>>>> can
>>>>>>> start digging in the OMAP PM code, but it's all new territory for me.
>>>>>>
>>>>>>
>>>>>> I did a little playing around with this today and I think that I have
>>>>>> figured out why this was not working (see below). Please can you try the
>>>>>> following patch? I tried this on top of your series for perf/omap4.
>>>>>>
>>>>>> Paul, FYI. If this works for Will then I can re-base on top of the
>>>>>> latest linux-omap and submit to the mailing list.
>>>>>>
>>>>>> Also, the above error about the emu_pwrdm is odd too. I noticed that
>>>>>> the emu_pwrdm is always in the transitioning state. And when I say always, I
>>>>>> mean that even if I check the power domain state while u-boot is running it
>>>>>> is in the transitioning state. So even before the kernel starts.
>>>>>>
>>>>>> Cheers
>>>>>> Jon
>>>>>>
>>>>>>   From 9137ff9c1b382232de7443db0b51b7555846fb62 Mon Sep 17 00:00:00 2001
>>>>>> From: Jon Hunter<jon-hunter@ti.com>
>>>>>> Date: Fri, 4 May 2012 16:48:45 -0500
>>>>>> Subject: [PATCH] ARM: OMAP4: Disable auto enable for EMU CLKDM
>>>>>>
>>>>>> The flag CLKDM_CAN_HWSUP allows the clock-domain to automatically
>>>>>> transition
>>>>>> to the enabled and disabled state. This means that as soon as we force
>>>>>> a
>>>>>> software wake-up on the clock domain, the clock domain will be allowed
>>>>>> to idle
>>>>>> and put back into the hardware auto state. For the EMU clock domain
>>>>>> this is not
>>>>>> what we want. We want to keep the clock domain in the software wakeup
>>>>>> state
>>>>>> while the clock domain is being used and put it back in to the hardware
>>>>>> auto
>>>>>> state when we have finished using the clock domain.
>>>>>>
>>>>>> Signed-off-by: Jon Hunter<jon-hunter@ti.com>
>>>>>
>>>>>
>>>>> With this patch, how is the clkdm ever idled?
>>>>
>>>>
>>>> It does not! Sorry, I was so engrossed with figuring out why the EMU
>>>> clkdm was being idled as soon as it was enabled, I forgot to check if is
>>>> ever disabled once we terminated perf :-(
>>>>
>>>>> IIUC, your patch will get PMU interrupts working, but similarily to
>>>>> previous patches in this thread, it works because it *never* allows the
>>>>> EMU clkdm to idle.  This is not a mergeable solution because it will not
>>>>> allow CORE retention (and thus full-chip retention.)
>>>>
>>>>
>>>> Right!
>>>>
>>>>> What we need is a solution that allows the clkdm to idle, and then to be
>>>>> reinitialzed when it wakes up.  Due to the way (I understand) resets in
>>>>> the debugss, allowing the clkdm to idle will cause a reset, so the
>>>>> PMU/CTI interrupts need to be reinitialzied after wakeup.
>>>>
>>>>
>>>> Yes exactly I see that now. I have prototyped the 3 patches and this is
>>>> working AND the EMU clkdm does go back to idle. I can send out to the
>>>> list for review.
>>>
>>>
>>> Perfect, thanks.
>>>
>>>>> Kevin
>>>>>
>>>>> P.S. Please note there is also already a different fix in mainline for
>>>>> the EMU clkdm data from Paul which adds the force wakeup flag and
>>>>> removes the DISABLE_AUTO flag[1] (but leaves the ENABLE_AUTO flag,
>>>>> because the hardware is capable.)
>>>>
>>>>
>>>> Hmmm ... yes saw this, and you will have to excuse me as I don't fully
>>>> follow the logic here. In fact, I am thinking we want the opposite ;-)
>>>>
>>>>   From looking, into this it seems to me that when PMU is running we want
>>>> the EMU clock domain in software-wakeup state and when PMU is not
>>>> running we want in the hardware auto state.
>>>
>>>
>>> So far, I'm with you.
>>>
>>>> By keeping the ENABLE_AUTO flag set, as soon as we enable the clock
>>>> domain it is put right back into the HW_AUTO state
>>>
>>>
>>> This is only because it was in the HWSUP state when _enable was called.
>>> If clkdm_deny_idle() is used, that behavior will change.
>>>
>>>> and hence PMU is
>>>> not working (see _enable() function in
>>>> arch/arm/mach-omap2/omap_hwmod.c)
>>>>
>>>> So really what I think we want is to remove the ENABLE_AUTO flag to keep
>>>> the clock domain in software wake-up and use the DISABLE_AUTO flag to
>>>> put the clock domain back in HW_AUTO (note this requires a patch to
>>>> perform this 2nd part).
>>>
>>>
>>> Well, Paul will have to comment here for the final word, but IIUC, the
>>> hwmod flags are supposed to indicate only what the HW is capable of.  If
>>> we want to change the runtime behavior, we nee to use (or add) APIs to
>>> change the beahvior.  In this case, clkdm_allow_idle(),
>>> clkdm_deny_idle() are probably what is needed here.
>>
>>
>> Yes, indeed, we should not hack the flags to fix that kind of issue. The
>> flags describe what the HW is capable of, and the EMU CD can support HW_AUTO
>> and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the only valid next
>> power state is OFF, meaning that no retention mode is supported. So any
>> transition to idle will go to OFF and lead to a reset upon wakeup.
>>
>> That being said, being able to transition to OFF during idle is a perfectly
>> valid state for most powerdomain in OMAP anyway, so we should be able to
>> restore from OFF mode smoothly.
>>
>> It looks to me that what is missing here is *just* a restore path in the
>> PMU/CTI code. But I'm probably missing some nasty details in this issue :-)
> Although it is perfectly feasible to have a seamless transition of the
> EMU power domain, I think the PMU counters will not be accurate
> anymore since they stop counting events when going to OFF and re-start
> after the state restore.

Good point, but I think the PMU might still works fine because located 
inside the MPU domain. AFAIR, only the path to access the PMU and the 
CTI is going to OFF and thus will be reset.
But that whole DEBUGSS is such a nightmare, that I'm not 100% sure about 
that :-)

Regards,
Benoit

Re: oprofile and ARM A9 hardware counter

[Jean Pihet]

On Tue, May 8, 2012 at 2:37 PM, Cousson, Benoit <b-cousson@ti.com> wrote:
> Salut Jean,
>
>
> On 5/8/2012 1:23 PM, Jean Pihet wrote:
>>
>> Hi Benoit,
>>
>> On Tue, May 8, 2012 at 1:01 PM, Cousson, Benoit<b-cousson@ti.com>  wrote:
>>>
>>> Hi Kevin&  Jon,
>>>
>>>
>>>
>>> On 5/8/2012 1:28 AM, Kevin Hilman wrote:
>>>>
>>>>
>>>> Jon Hunter<jon-hunter@ti.com>    writes:
>>>>
>>>>> Hi Kevin,
>>>>>
>>>>> On 05/07/2012 12:15 PM, Kevin Hilman wrote:
>>>>>>
>>>>>>
>>>>>> Jon Hunter<jon-hunter@ti.com>    writes:
>>>>>>
>>>>>>> Hi Will,
>>>>>>>
>>>>>>> On 04/26/2012 01:07 PM, Will Deacon wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Apr 04, 2012 at 12:15:24PM +0100, Will Deacon wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, Apr 04, 2012 at 12:29:49AM +0100, Paul Walmsley wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Part of the problem is that the clockdomain data for the emu_sys
>>>>>>>>>> clockdomain is wrong.  Here's something to try to fix it.  It
>>>>>>>>>> might
>>>>>>>>>> just
>>>>>>>>>> be enough to get it to work.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hmm, doesn't seem to work but I do see the following in dmesg when
>>>>>>>>> I
>>>>>>>>> try to
>>>>>>>>> use perf:
>>>>>>>>>
>>>>>>>>>  powerdomain: waited too long for powerdomain emu_pwrdm to complete
>>>>>>>>> transition
>>>>>>>>>
>>>>>>>>> which is new with your patch.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Sorry to nag, but does anybody have a clue where to go from here? I
>>>>>>>> can
>>>>>>>> start digging in the OMAP PM code, but it's all new territory for
>>>>>>>> me.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I did a little playing around with this today and I think that I have
>>>>>>> figured out why this was not working (see below). Please can you try
>>>>>>> the
>>>>>>> following patch? I tried this on top of your series for perf/omap4.
>>>>>>>
>>>>>>> Paul, FYI. If this works for Will then I can re-base on top of the
>>>>>>> latest linux-omap and submit to the mailing list.
>>>>>>>
>>>>>>> Also, the above error about the emu_pwrdm is odd too. I noticed that
>>>>>>> the emu_pwrdm is always in the transitioning state. And when I say
>>>>>>> always, I
>>>>>>> mean that even if I check the power domain state while u-boot is
>>>>>>> running it
>>>>>>> is in the transitioning state. So even before the kernel starts.
>>>>>>>
>>>>>>> Cheers
>>>>>>> Jon
>>>>>>>
>>>>>>>  From 9137ff9c1b382232de7443db0b51b7555846fb62 Mon Sep 17 00:00:00
>>>>>>> 2001
>>>>>>> From: Jon Hunter<jon-hunter@ti.com>
>>>>>>> Date: Fri, 4 May 2012 16:48:45 -0500
>>>>>>> Subject: [PATCH] ARM: OMAP4: Disable auto enable for EMU CLKDM
>>>>>>>
>>>>>>> The flag CLKDM_CAN_HWSUP allows the clock-domain to automatically
>>>>>>> transition
>>>>>>> to the enabled and disabled state. This means that as soon as we
>>>>>>> force
>>>>>>> a
>>>>>>> software wake-up on the clock domain, the clock domain will be
>>>>>>> allowed
>>>>>>> to idle
>>>>>>> and put back into the hardware auto state. For the EMU clock domain
>>>>>>> this is not
>>>>>>> what we want. We want to keep the clock domain in the software wakeup
>>>>>>> state
>>>>>>> while the clock domain is being used and put it back in to the
>>>>>>> hardware
>>>>>>> auto
>>>>>>> state when we have finished using the clock domain.
>>>>>>>
>>>>>>> Signed-off-by: Jon Hunter<jon-hunter@ti.com>
>>>>>>
>>>>>>
>>>>>>
>>>>>> With this patch, how is the clkdm ever idled?
>>>>>
>>>>>
>>>>>
>>>>> It does not! Sorry, I was so engrossed with figuring out why the EMU
>>>>> clkdm was being idled as soon as it was enabled, I forgot to check if
>>>>> is
>>>>> ever disabled once we terminated perf :-(
>>>>>
>>>>>> IIUC, your patch will get PMU interrupts working, but similarily to
>>>>>> previous patches in this thread, it works because it *never* allows
>>>>>> the
>>>>>> EMU clkdm to idle.  This is not a mergeable solution because it will
>>>>>> not
>>>>>> allow CORE retention (and thus full-chip retention.)
>>>>>
>>>>>
>>>>>
>>>>> Right!
>>>>>
>>>>>> What we need is a solution that allows the clkdm to idle, and then to
>>>>>> be
>>>>>> reinitialzed when it wakes up.  Due to the way (I understand) resets
>>>>>> in
>>>>>> the debugss, allowing the clkdm to idle will cause a reset, so the
>>>>>> PMU/CTI interrupts need to be reinitialzied after wakeup.
>>>>>
>>>>>
>>>>>
>>>>> Yes exactly I see that now. I have prototyped the 3 patches and this is
>>>>> working AND the EMU clkdm does go back to idle. I can send out to the
>>>>> list for review.
>>>>
>>>>
>>>>
>>>> Perfect, thanks.
>>>>
>>>>>> Kevin
>>>>>>
>>>>>> P.S. Please note there is also already a different fix in mainline for
>>>>>> the EMU clkdm data from Paul which adds the force wakeup flag and
>>>>>> removes the DISABLE_AUTO flag[1] (but leaves the ENABLE_AUTO flag,
>>>>>> because the hardware is capable.)
>>>>>
>>>>>
>>>>>
>>>>> Hmmm ... yes saw this, and you will have to excuse me as I don't fully
>>>>> follow the logic here. In fact, I am thinking we want the opposite ;-)
>>>>>
>>>>>  From looking, into this it seems to me that when PMU is running we
>>>>> want
>>>>> the EMU clock domain in software-wakeup state and when PMU is not
>>>>> running we want in the hardware auto state.
>>>>
>>>>
>>>>
>>>> So far, I'm with you.
>>>>
>>>>> By keeping the ENABLE_AUTO flag set, as soon as we enable the clock
>>>>> domain it is put right back into the HW_AUTO state
>>>>
>>>>
>>>>
>>>> This is only because it was in the HWSUP state when _enable was called.
>>>> If clkdm_deny_idle() is used, that behavior will change.
>>>>
>>>>> and hence PMU is
>>>>> not working (see _enable() function in
>>>>> arch/arm/mach-omap2/omap_hwmod.c)
>>>>>
>>>>> So really what I think we want is to remove the ENABLE_AUTO flag to
>>>>> keep
>>>>> the clock domain in software wake-up and use the DISABLE_AUTO flag to
>>>>> put the clock domain back in HW_AUTO (note this requires a patch to
>>>>> perform this 2nd part).
>>>>
>>>>
>>>>
>>>> Well, Paul will have to comment here for the final word, but IIUC, the
>>>> hwmod flags are supposed to indicate only what the HW is capable of.  If
>>>> we want to change the runtime behavior, we nee to use (or add) APIs to
>>>> change the beahvior.  In this case, clkdm_allow_idle(),
>>>> clkdm_deny_idle() are probably what is needed here.
>>>
>>>
>>>
>>> Yes, indeed, we should not hack the flags to fix that kind of issue. The
>>> flags describe what the HW is capable of, and the EMU CD can support
>>> HW_AUTO
>>> and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the only valid
>>> next
>>> power state is OFF, meaning that no retention mode is supported. So any
>>> transition to idle will go to OFF and lead to a reset upon wakeup.
>>>
>>> That being said, being able to transition to OFF during idle is a
>>> perfectly
>>> valid state for most powerdomain in OMAP anyway, so we should be able to
>>> restore from OFF mode smoothly.
>>>
>>> It looks to me that what is missing here is *just* a restore path in the
>>> PMU/CTI code. But I'm probably missing some nasty details in this issue
>>> :-)
>>
>> Although it is perfectly feasible to have a seamless transition of the
>> EMU power domain, I think the PMU counters will not be accurate
>> anymore since they stop counting events when going to OFF and re-start
>> after the state restore.
>
>
> Good point, but I think the PMU might still works fine because located
> inside the MPU domain. AFAIR, only the path to access the PMU and the CTI is
> going to OFF and thus will be reset.
Ever better point ;p Thanks for the precision.
In any case my point was: can we allow the EMU CD to go OFF or prevent
it from doing so? We need to answer that question first.

> But that whole DEBUGSS is such a nightmare, that I'm not 100% sure about
> that :-)


>
> Regards,
> Benoit
>

Jean
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

oprofile and ARM A9 hardware counter

[Jean Pihet]

On Tue, May 8, 2012 at 2:37 PM, Cousson, Benoit <b-cousson@ti.com> wrote:
> Salut Jean,
>
>
> On 5/8/2012 1:23 PM, Jean Pihet wrote:
>>
>> Hi Benoit,
>>
>> On Tue, May 8, 2012 at 1:01 PM, Cousson, Benoit<b-cousson@ti.com> ?wrote:
>>>
>>> Hi Kevin& ?Jon,
>>>
>>>
>>>
>>> On 5/8/2012 1:28 AM, Kevin Hilman wrote:
>>>>
>>>>
>>>> Jon Hunter<jon-hunter@ti.com> ? ?writes:
>>>>
>>>>> Hi Kevin,
>>>>>
>>>>> On 05/07/2012 12:15 PM, Kevin Hilman wrote:
>>>>>>
>>>>>>
>>>>>> Jon Hunter<jon-hunter@ti.com> ? ?writes:
>>>>>>
>>>>>>> Hi Will,
>>>>>>>
>>>>>>> On 04/26/2012 01:07 PM, Will Deacon wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Apr 04, 2012 at 12:15:24PM +0100, Will Deacon wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, Apr 04, 2012 at 12:29:49AM +0100, Paul Walmsley wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Part of the problem is that the clockdomain data for the emu_sys
>>>>>>>>>> clockdomain is wrong. ?Here's something to try to fix it. ?It
>>>>>>>>>> might
>>>>>>>>>> just
>>>>>>>>>> be enough to get it to work.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hmm, doesn't seem to work but I do see the following in dmesg when
>>>>>>>>> I
>>>>>>>>> try to
>>>>>>>>> use perf:
>>>>>>>>>
>>>>>>>>> ?powerdomain: waited too long for powerdomain emu_pwrdm to complete
>>>>>>>>> transition
>>>>>>>>>
>>>>>>>>> which is new with your patch.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Sorry to nag, but does anybody have a clue where to go from here? I
>>>>>>>> can
>>>>>>>> start digging in the OMAP PM code, but it's all new territory for
>>>>>>>> me.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I did a little playing around with this today and I think that I have
>>>>>>> figured out why this was not working (see below). Please can you try
>>>>>>> the
>>>>>>> following patch? I tried this on top of your series for perf/omap4.
>>>>>>>
>>>>>>> Paul, FYI. If this works for Will then I can re-base on top of the
>>>>>>> latest linux-omap and submit to the mailing list.
>>>>>>>
>>>>>>> Also, the above error about the emu_pwrdm is odd too. I noticed that
>>>>>>> the emu_pwrdm is always in the transitioning state. And when I say
>>>>>>> always, I
>>>>>>> mean that even if I check the power domain state while u-boot is
>>>>>>> running it
>>>>>>> is in the transitioning state. So even before the kernel starts.
>>>>>>>
>>>>>>> Cheers
>>>>>>> Jon
>>>>>>>
>>>>>>> ?From 9137ff9c1b382232de7443db0b51b7555846fb62 Mon Sep 17 00:00:00
>>>>>>> 2001
>>>>>>> From: Jon Hunter<jon-hunter@ti.com>
>>>>>>> Date: Fri, 4 May 2012 16:48:45 -0500
>>>>>>> Subject: [PATCH] ARM: OMAP4: Disable auto enable for EMU CLKDM
>>>>>>>
>>>>>>> The flag CLKDM_CAN_HWSUP allows the clock-domain to automatically
>>>>>>> transition
>>>>>>> to the enabled and disabled state. This means that as soon as we
>>>>>>> force
>>>>>>> a
>>>>>>> software wake-up on the clock domain, the clock domain will be
>>>>>>> allowed
>>>>>>> to idle
>>>>>>> and put back into the hardware auto state. For the EMU clock domain
>>>>>>> this is not
>>>>>>> what we want. We want to keep the clock domain in the software wakeup
>>>>>>> state
>>>>>>> while the clock domain is being used and put it back in to the
>>>>>>> hardware
>>>>>>> auto
>>>>>>> state when we have finished using the clock domain.
>>>>>>>
>>>>>>> Signed-off-by: Jon Hunter<jon-hunter@ti.com>
>>>>>>
>>>>>>
>>>>>>
>>>>>> With this patch, how is the clkdm ever idled?
>>>>>
>>>>>
>>>>>
>>>>> It does not! Sorry, I was so engrossed with figuring out why the EMU
>>>>> clkdm was being idled as soon as it was enabled, I forgot to check if
>>>>> is
>>>>> ever disabled once we terminated perf :-(
>>>>>
>>>>>> IIUC, your patch will get PMU interrupts working, but similarily to
>>>>>> previous patches in this thread, it works because it *never* allows
>>>>>> the
>>>>>> EMU clkdm to idle. ?This is not a mergeable solution because it will
>>>>>> not
>>>>>> allow CORE retention (and thus full-chip retention.)
>>>>>
>>>>>
>>>>>
>>>>> Right!
>>>>>
>>>>>> What we need is a solution that allows the clkdm to idle, and then to
>>>>>> be
>>>>>> reinitialzed when it wakes up. ?Due to the way (I understand) resets
>>>>>> in
>>>>>> the debugss, allowing the clkdm to idle will cause a reset, so the
>>>>>> PMU/CTI interrupts need to be reinitialzied after wakeup.
>>>>>
>>>>>
>>>>>
>>>>> Yes exactly I see that now. I have prototyped the 3 patches and this is
>>>>> working AND the EMU clkdm does go back to idle. I can send out to the
>>>>> list for review.
>>>>
>>>>
>>>>
>>>> Perfect, thanks.
>>>>
>>>>>> Kevin
>>>>>>
>>>>>> P.S. Please note there is also already a different fix in mainline for
>>>>>> the EMU clkdm data from Paul which adds the force wakeup flag and
>>>>>> removes the DISABLE_AUTO flag[1] (but leaves the ENABLE_AUTO flag,
>>>>>> because the hardware is capable.)
>>>>>
>>>>>
>>>>>
>>>>> Hmmm ... yes saw this, and you will have to excuse me as I don't fully
>>>>> follow the logic here. In fact, I am thinking we want the opposite ;-)
>>>>>
>>>>> ?From looking, into this it seems to me that when PMU is running we
>>>>> want
>>>>> the EMU clock domain in software-wakeup state and when PMU is not
>>>>> running we want in the hardware auto state.
>>>>
>>>>
>>>>
>>>> So far, I'm with you.
>>>>
>>>>> By keeping the ENABLE_AUTO flag set, as soon as we enable the clock
>>>>> domain it is put right back into the HW_AUTO state
>>>>
>>>>
>>>>
>>>> This is only because it was in the HWSUP state when _enable was called.
>>>> If clkdm_deny_idle() is used, that behavior will change.
>>>>
>>>>> and hence PMU is
>>>>> not working (see _enable() function in
>>>>> arch/arm/mach-omap2/omap_hwmod.c)
>>>>>
>>>>> So really what I think we want is to remove the ENABLE_AUTO flag to
>>>>> keep
>>>>> the clock domain in software wake-up and use the DISABLE_AUTO flag to
>>>>> put the clock domain back in HW_AUTO (note this requires a patch to
>>>>> perform this 2nd part).
>>>>
>>>>
>>>>
>>>> Well, Paul will have to comment here for the final word, but IIUC, the
>>>> hwmod flags are supposed to indicate only what the HW is capable of. ?If
>>>> we want to change the runtime behavior, we nee to use (or add) APIs to
>>>> change the beahvior. ?In this case, clkdm_allow_idle(),
>>>> clkdm_deny_idle() are probably what is needed here.
>>>
>>>
>>>
>>> Yes, indeed, we should not hack the flags to fix that kind of issue. The
>>> flags describe what the HW is capable of, and the EMU CD can support
>>> HW_AUTO
>>> and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the only valid
>>> next
>>> power state is OFF, meaning that no retention mode is supported. So any
>>> transition to idle will go to OFF and lead to a reset upon wakeup.
>>>
>>> That being said, being able to transition to OFF during idle is a
>>> perfectly
>>> valid state for most powerdomain in OMAP anyway, so we should be able to
>>> restore from OFF mode smoothly.
>>>
>>> It looks to me that what is missing here is *just* a restore path in the
>>> PMU/CTI code. But I'm probably missing some nasty details in this issue
>>> :-)
>>
>> Although it is perfectly feasible to have a seamless transition of the
>> EMU power domain, I think the PMU counters will not be accurate
>> anymore since they stop counting events when going to OFF and re-start
>> after the state restore.
>
>
> Good point, but I think the PMU might still works fine because located
> inside the MPU domain. AFAIR, only the path to access the PMU and the CTI is
> going to OFF and thus will be reset.
Ever better point ;p Thanks for the precision.
In any case my point was: can we allow the EMU CD to go OFF or prevent
it from doing so? We need to answer that question first.

> But that whole DEBUGSS is such a nightmare, that I'm not 100% sure about
> that :-)


>
> Regards,
> Benoit
>

Jean

Re: oprofile and ARM A9 hardware counter

[Kevin Hilman]

Jean Pihet <jean.pihet@newoldbits.com> writes:

[...]

>>>> Yes, indeed, we should not hack the flags to fix that kind of issue. The
>>>> flags describe what the HW is capable of, and the EMU CD can support
>>>> HW_AUTO
>>>> and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the only valid
>>>> next
>>>> power state is OFF, meaning that no retention mode is supported. So any
>>>> transition to idle will go to OFF and lead to a reset upon wakeup.
>>>>
>>>> That being said, being able to transition to OFF during idle is a
>>>> perfectly
>>>> valid state for most powerdomain in OMAP anyway, so we should be able to
>>>> restore from OFF mode smoothly.
>>>>
>>>> It looks to me that what is missing here is *just* a restore path in the
>>>> PMU/CTI code. But I'm probably missing some nasty details in this issue
>>>> :-)
>>>
>>> Although it is perfectly feasible to have a seamless transition of the
>>> EMU power domain, I think the PMU counters will not be accurate
>>> anymore since they stop counting events when going to OFF and re-start
>>> after the state restore.
>>
>>
>> Good point, but I think the PMU might still works fine because located
>> inside the MPU domain. AFAIR, only the path to access the PMU and the CTI is
>> going to OFF and thus will be reset.
>
> Ever better point ;p Thanks for the precision.
> In any case my point was: can we allow the EMU CD to go OFF or prevent
> it from doing so? We need to answer that question first.
>

The idea I've suggested is to use runtime PM for this.  As long as the
PMU is in use, it will be runtime PM enabled (and not allowed to go into
HWSUP idle.)  When it is not used, it will be allowed to HWSUP idle, and
then be reset.  The next time it is needed, the runtime resume will need
to do a full re-init.

Kevin

oprofile and ARM A9 hardware counter

[Kevin Hilman]

Jean Pihet <jean.pihet@newoldbits.com> writes:

[...]

>>>> Yes, indeed, we should not hack the flags to fix that kind of issue. The
>>>> flags describe what the HW is capable of, and the EMU CD can support
>>>> HW_AUTO
>>>> and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the only valid
>>>> next
>>>> power state is OFF, meaning that no retention mode is supported. So any
>>>> transition to idle will go to OFF and lead to a reset upon wakeup.
>>>>
>>>> That being said, being able to transition to OFF during idle is a
>>>> perfectly
>>>> valid state for most powerdomain in OMAP anyway, so we should be able to
>>>> restore from OFF mode smoothly.
>>>>
>>>> It looks to me that what is missing here is *just* a restore path in the
>>>> PMU/CTI code. But I'm probably missing some nasty details in this issue
>>>> :-)
>>>
>>> Although it is perfectly feasible to have a seamless transition of the
>>> EMU power domain, I think the PMU counters will not be accurate
>>> anymore since they stop counting events when going to OFF and re-start
>>> after the state restore.
>>
>>
>> Good point, but I think the PMU might still works fine because located
>> inside the MPU domain. AFAIR, only the path to access the PMU and the CTI is
>> going to OFF and thus will be reset.
>
> Ever better point ;p Thanks for the precision.
> In any case my point was: can we allow the EMU CD to go OFF or prevent
> it from doing so? We need to answer that question first.
>

The idea I've suggested is to use runtime PM for this.  As long as the
PMU is in use, it will be runtime PM enabled (and not allowed to go into
HWSUP idle.)  When it is not used, it will be allowed to HWSUP idle, and
then be reset.  The next time it is needed, the runtime resume will need
to do a full re-init.

Kevin

Re: oprofile and ARM A9 hardware counter

[Cousson, Benoit]

On 5/8/2012 4:00 PM, Kevin Hilman wrote:
> Jean Pihet<jean.pihet@newoldbits.com>  writes:
>
> [...]
>
>>>>> Yes, indeed, we should not hack the flags to fix that kind of issue. The
>>>>> flags describe what the HW is capable of, and the EMU CD can support
>>>>> HW_AUTO
>>>>> and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the only valid
>>>>> next
>>>>> power state is OFF, meaning that no retention mode is supported. So any
>>>>> transition to idle will go to OFF and lead to a reset upon wakeup.
>>>>>
>>>>> That being said, being able to transition to OFF during idle is a
>>>>> perfectly
>>>>> valid state for most powerdomain in OMAP anyway, so we should be able to
>>>>> restore from OFF mode smoothly.
>>>>>
>>>>> It looks to me that what is missing here is *just* a restore path in the
>>>>> PMU/CTI code. But I'm probably missing some nasty details in this issue
>>>>> :-)
>>>>
>>>> Although it is perfectly feasible to have a seamless transition of the
>>>> EMU power domain, I think the PMU counters will not be accurate
>>>> anymore since they stop counting events when going to OFF and re-start
>>>> after the state restore.
>>>
>>>
>>> Good point, but I think the PMU might still works fine because located
>>> inside the MPU domain. AFAIR, only the path to access the PMU and the CTI is
>>> going to OFF and thus will be reset.
>>
>> Ever better point ;p Thanks for the precision.
>> In any case my point was: can we allow the EMU CD to go OFF or prevent
>> it from doing so? We need to answer that question first.
>>
>
> The idea I've suggested is to use runtime PM for this.  As long as the
> PMU is in use, it will be runtime PM enabled (and not allowed to go into
> HWSUP idle.)  When it is not used, it will be allowed to HWSUP idle, and
> then be reset.  The next time it is needed, the runtime resume will need
> to do a full re-init.

Oh, but does that mean that this driver is not pm_runtime adapted yet?

Benoit

oprofile and ARM A9 hardware counter

[Cousson, Benoit]

On 5/8/2012 4:00 PM, Kevin Hilman wrote:
> Jean Pihet<jean.pihet@newoldbits.com>  writes:
>
> [...]
>
>>>>> Yes, indeed, we should not hack the flags to fix that kind of issue. The
>>>>> flags describe what the HW is capable of, and the EMU CD can support
>>>>> HW_AUTO
>>>>> and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the only valid
>>>>> next
>>>>> power state is OFF, meaning that no retention mode is supported. So any
>>>>> transition to idle will go to OFF and lead to a reset upon wakeup.
>>>>>
>>>>> That being said, being able to transition to OFF during idle is a
>>>>> perfectly
>>>>> valid state for most powerdomain in OMAP anyway, so we should be able to
>>>>> restore from OFF mode smoothly.
>>>>>
>>>>> It looks to me that what is missing here is *just* a restore path in the
>>>>> PMU/CTI code. But I'm probably missing some nasty details in this issue
>>>>> :-)
>>>>
>>>> Although it is perfectly feasible to have a seamless transition of the
>>>> EMU power domain, I think the PMU counters will not be accurate
>>>> anymore since they stop counting events when going to OFF and re-start
>>>> after the state restore.
>>>
>>>
>>> Good point, but I think the PMU might still works fine because located
>>> inside the MPU domain. AFAIR, only the path to access the PMU and the CTI is
>>> going to OFF and thus will be reset.
>>
>> Ever better point ;p Thanks for the precision.
>> In any case my point was: can we allow the EMU CD to go OFF or prevent
>> it from doing so? We need to answer that question first.
>>
>
> The idea I've suggested is to use runtime PM for this.  As long as the
> PMU is in use, it will be runtime PM enabled (and not allowed to go into
> HWSUP idle.)  When it is not used, it will be allowed to HWSUP idle, and
> then be reset.  The next time it is needed, the runtime resume will need
> to do a full re-init.

Oh, but does that mean that this driver is not pm_runtime adapted yet?

Benoit

Re: oprofile and ARM A9 hardware counter

[Kevin Hilman]

"Cousson, Benoit" <b-cousson@ti.com> writes:

> On 5/8/2012 4:00 PM, Kevin Hilman wrote:
>> Jean Pihet<jean.pihet@newoldbits.com>  writes:
>>
>> [...]
>>
>>>>>> Yes, indeed, we should not hack the flags to fix that kind of issue. The
>>>>>> flags describe what the HW is capable of, and the EMU CD can support
>>>>>> HW_AUTO
>>>>>> and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the only valid
>>>>>> next
>>>>>> power state is OFF, meaning that no retention mode is supported. So any
>>>>>> transition to idle will go to OFF and lead to a reset upon wakeup.
>>>>>>
>>>>>> That being said, being able to transition to OFF during idle is a
>>>>>> perfectly
>>>>>> valid state for most powerdomain in OMAP anyway, so we should be able to
>>>>>> restore from OFF mode smoothly.
>>>>>>
>>>>>> It looks to me that what is missing here is *just* a restore path in the
>>>>>> PMU/CTI code. But I'm probably missing some nasty details in this issue
>>>>>> :-)
>>>>>
>>>>> Although it is perfectly feasible to have a seamless transition of the
>>>>> EMU power domain, I think the PMU counters will not be accurate
>>>>> anymore since they stop counting events when going to OFF and re-start
>>>>> after the state restore.
>>>>
>>>>
>>>> Good point, but I think the PMU might still works fine because located
>>>> inside the MPU domain. AFAIR, only the path to access the PMU and the CTI is
>>>> going to OFF and thus will be reset.
>>>
>>> Ever better point ;p Thanks for the precision.
>>> In any case my point was: can we allow the EMU CD to go OFF or prevent
>>> it from doing so? We need to answer that question first.
>>>
>>
>> The idea I've suggested is to use runtime PM for this.  As long as the
>> PMU is in use, it will be runtime PM enabled (and not allowed to go into
>> HWSUP idle.)  When it is not used, it will be allowed to HWSUP idle, and
>> then be reset.  The next time it is needed, the runtime resume will need
>> to do a full re-init.
>
> Oh, but does that mean that this driver is not pm_runtime adapted yet?
>

Actually, it is.  Ming Lei has done it.

Currently, Will has collected this[1] and is waiting (patiently) for us
to produce a real fix that doesn't kill PM in the process.

Kevin

[1] git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git perf/omap4

oprofile and ARM A9 hardware counter

[Kevin Hilman]

"Cousson, Benoit" <b-cousson@ti.com> writes:

> On 5/8/2012 4:00 PM, Kevin Hilman wrote:
>> Jean Pihet<jean.pihet@newoldbits.com>  writes:
>>
>> [...]
>>
>>>>>> Yes, indeed, we should not hack the flags to fix that kind of issue. The
>>>>>> flags describe what the HW is capable of, and the EMU CD can support
>>>>>> HW_AUTO
>>>>>> and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the only valid
>>>>>> next
>>>>>> power state is OFF, meaning that no retention mode is supported. So any
>>>>>> transition to idle will go to OFF and lead to a reset upon wakeup.
>>>>>>
>>>>>> That being said, being able to transition to OFF during idle is a
>>>>>> perfectly
>>>>>> valid state for most powerdomain in OMAP anyway, so we should be able to
>>>>>> restore from OFF mode smoothly.
>>>>>>
>>>>>> It looks to me that what is missing here is *just* a restore path in the
>>>>>> PMU/CTI code. But I'm probably missing some nasty details in this issue
>>>>>> :-)
>>>>>
>>>>> Although it is perfectly feasible to have a seamless transition of the
>>>>> EMU power domain, I think the PMU counters will not be accurate
>>>>> anymore since they stop counting events when going to OFF and re-start
>>>>> after the state restore.
>>>>
>>>>
>>>> Good point, but I think the PMU might still works fine because located
>>>> inside the MPU domain. AFAIR, only the path to access the PMU and the CTI is
>>>> going to OFF and thus will be reset.
>>>
>>> Ever better point ;p Thanks for the precision.
>>> In any case my point was: can we allow the EMU CD to go OFF or prevent
>>> it from doing so? We need to answer that question first.
>>>
>>
>> The idea I've suggested is to use runtime PM for this.  As long as the
>> PMU is in use, it will be runtime PM enabled (and not allowed to go into
>> HWSUP idle.)  When it is not used, it will be allowed to HWSUP idle, and
>> then be reset.  The next time it is needed, the runtime resume will need
>> to do a full re-init.
>
> Oh, but does that mean that this driver is not pm_runtime adapted yet?
>

Actually, it is.  Ming Lei has done it.

Currently, Will has collected this[1] and is waiting (patiently) for us
to produce a real fix that doesn't kill PM in the process.

Kevin

[1] git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git perf/omap4

Re: oprofile and ARM A9 hardware counter

[Jon Hunter]

On 05/08/2012 11:18 AM, Kevin Hilman wrote:
> "Cousson, Benoit" <b-cousson@ti.com> writes:
> 
>> On 5/8/2012 4:00 PM, Kevin Hilman wrote:
>>> Jean Pihet<jean.pihet@newoldbits.com>  writes:
>>>
>>> [...]
>>>
>>>>>>> Yes, indeed, we should not hack the flags to fix that kind of issue. The
>>>>>>> flags describe what the HW is capable of, and the EMU CD can support
>>>>>>> HW_AUTO
>>>>>>> and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the only valid
>>>>>>> next
>>>>>>> power state is OFF, meaning that no retention mode is supported. So any
>>>>>>> transition to idle will go to OFF and lead to a reset upon wakeup.
>>>>>>>
>>>>>>> That being said, being able to transition to OFF during idle is a
>>>>>>> perfectly
>>>>>>> valid state for most powerdomain in OMAP anyway, so we should be able to
>>>>>>> restore from OFF mode smoothly.
>>>>>>>
>>>>>>> It looks to me that what is missing here is *just* a restore path in the
>>>>>>> PMU/CTI code. But I'm probably missing some nasty details in this issue
>>>>>>> :-)
>>>>>>
>>>>>> Although it is perfectly feasible to have a seamless transition of the
>>>>>> EMU power domain, I think the PMU counters will not be accurate
>>>>>> anymore since they stop counting events when going to OFF and re-start
>>>>>> after the state restore.
>>>>>
>>>>>
>>>>> Good point, but I think the PMU might still works fine because located
>>>>> inside the MPU domain. AFAIR, only the path to access the PMU and the CTI is
>>>>> going to OFF and thus will be reset.
>>>>
>>>> Ever better point ;p Thanks for the precision.
>>>> In any case my point was: can we allow the EMU CD to go OFF or prevent
>>>> it from doing so? We need to answer that question first.
>>>>
>>>
>>> The idea I've suggested is to use runtime PM for this.  As long as the
>>> PMU is in use, it will be runtime PM enabled (and not allowed to go into
>>> HWSUP idle.)  When it is not used, it will be allowed to HWSUP idle, and
>>> then be reset.  The next time it is needed, the runtime resume will need
>>> to do a full re-init.
>>
>> Oh, but does that mean that this driver is not pm_runtime adapted yet?
>>
> 
> Actually, it is.  Ming Lei has done it.
> 
> Currently, Will has collected this[1] and is waiting (patiently) for us
> to produce a real fix that doesn't kill PM in the process.

I had to make a couple mods to Ming's patches but I do have something
working now that _should_ not break PM. However, per my previous email
(in response to Benoit's) I am struggling with the definition of the
CLKDM_CAN_XXXXXX_AUTO flags to know the correct way to fix this.

I was going to send out my patches, but I wanted to get some more
feedback on this first.

Cheers
Jon

oprofile and ARM A9 hardware counter

[Jon Hunter]

On 05/08/2012 11:18 AM, Kevin Hilman wrote:
> "Cousson, Benoit" <b-cousson@ti.com> writes:
> 
>> On 5/8/2012 4:00 PM, Kevin Hilman wrote:
>>> Jean Pihet<jean.pihet@newoldbits.com>  writes:
>>>
>>> [...]
>>>
>>>>>>> Yes, indeed, we should not hack the flags to fix that kind of issue. The
>>>>>>> flags describe what the HW is capable of, and the EMU CD can support
>>>>>>> HW_AUTO
>>>>>>> and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the only valid
>>>>>>> next
>>>>>>> power state is OFF, meaning that no retention mode is supported. So any
>>>>>>> transition to idle will go to OFF and lead to a reset upon wakeup.
>>>>>>>
>>>>>>> That being said, being able to transition to OFF during idle is a
>>>>>>> perfectly
>>>>>>> valid state for most powerdomain in OMAP anyway, so we should be able to
>>>>>>> restore from OFF mode smoothly.
>>>>>>>
>>>>>>> It looks to me that what is missing here is *just* a restore path in the
>>>>>>> PMU/CTI code. But I'm probably missing some nasty details in this issue
>>>>>>> :-)
>>>>>>
>>>>>> Although it is perfectly feasible to have a seamless transition of the
>>>>>> EMU power domain, I think the PMU counters will not be accurate
>>>>>> anymore since they stop counting events when going to OFF and re-start
>>>>>> after the state restore.
>>>>>
>>>>>
>>>>> Good point, but I think the PMU might still works fine because located
>>>>> inside the MPU domain. AFAIR, only the path to access the PMU and the CTI is
>>>>> going to OFF and thus will be reset.
>>>>
>>>> Ever better point ;p Thanks for the precision.
>>>> In any case my point was: can we allow the EMU CD to go OFF or prevent
>>>> it from doing so? We need to answer that question first.
>>>>
>>>
>>> The idea I've suggested is to use runtime PM for this.  As long as the
>>> PMU is in use, it will be runtime PM enabled (and not allowed to go into
>>> HWSUP idle.)  When it is not used, it will be allowed to HWSUP idle, and
>>> then be reset.  The next time it is needed, the runtime resume will need
>>> to do a full re-init.
>>
>> Oh, but does that mean that this driver is not pm_runtime adapted yet?
>>
> 
> Actually, it is.  Ming Lei has done it.
> 
> Currently, Will has collected this[1] and is waiting (patiently) for us
> to produce a real fix that doesn't kill PM in the process.

I had to make a couple mods to Ming's patches but I do have something
working now that _should_ not break PM. However, per my previous email
(in response to Benoit's) I am struggling with the definition of the
CLKDM_CAN_XXXXXX_AUTO flags to know the correct way to fix this.

I was going to send out my patches, but I wanted to get some more
feedback on this first.

Cheers
Jon

Re: oprofile and ARM A9 hardware counter

[Kevin Hilman]

Jon Hunter <jon-hunter@ti.com> writes:

> On 05/08/2012 11:18 AM, Kevin Hilman wrote:
>> "Cousson, Benoit" <b-cousson@ti.com> writes:
>> 
>>> On 5/8/2012 4:00 PM, Kevin Hilman wrote:
>>>> Jean Pihet<jean.pihet@newoldbits.com>  writes:
>>>>
>>>> [...]
>>>>
>>>>>>>> Yes, indeed, we should not hack the flags to fix that kind of issue. The
>>>>>>>> flags describe what the HW is capable of, and the EMU CD can support
>>>>>>>> HW_AUTO
>>>>>>>> and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the only valid
>>>>>>>> next
>>>>>>>> power state is OFF, meaning that no retention mode is supported. So any
>>>>>>>> transition to idle will go to OFF and lead to a reset upon wakeup.
>>>>>>>>
>>>>>>>> That being said, being able to transition to OFF during idle is a
>>>>>>>> perfectly
>>>>>>>> valid state for most powerdomain in OMAP anyway, so we should be able to
>>>>>>>> restore from OFF mode smoothly.
>>>>>>>>
>>>>>>>> It looks to me that what is missing here is *just* a restore path in the
>>>>>>>> PMU/CTI code. But I'm probably missing some nasty details in this issue
>>>>>>>> :-)
>>>>>>>
>>>>>>> Although it is perfectly feasible to have a seamless transition of the
>>>>>>> EMU power domain, I think the PMU counters will not be accurate
>>>>>>> anymore since they stop counting events when going to OFF and re-start
>>>>>>> after the state restore.
>>>>>>
>>>>>>
>>>>>> Good point, but I think the PMU might still works fine because located
>>>>>> inside the MPU domain. AFAIR, only the path to access the PMU and the CTI is
>>>>>> going to OFF and thus will be reset.
>>>>>
>>>>> Ever better point ;p Thanks for the precision.
>>>>> In any case my point was: can we allow the EMU CD to go OFF or prevent
>>>>> it from doing so? We need to answer that question first.
>>>>>
>>>>
>>>> The idea I've suggested is to use runtime PM for this.  As long as the
>>>> PMU is in use, it will be runtime PM enabled (and not allowed to go into
>>>> HWSUP idle.)  When it is not used, it will be allowed to HWSUP idle, and
>>>> then be reset.  The next time it is needed, the runtime resume will need
>>>> to do a full re-init.
>>>
>>> Oh, but does that mean that this driver is not pm_runtime adapted yet?
>>>
>> 
>> Actually, it is.  Ming Lei has done it.
>> 
>> Currently, Will has collected this[1] and is waiting (patiently) for us
>> to produce a real fix that doesn't kill PM in the process.
>
> I had to make a couple mods to Ming's patches but I do have something
> working now that _should_ not break PM. However, per my previous email
> (in response to Benoit's) I am struggling with the definition of the
> CLKDM_CAN_XXXXXX_AUTO flags to know the correct way to fix this.
>
> I was going to send out my patches, but I wanted to get some more
> feedback on this first.

While waiting for feeback, if you set the flags to CAN_FORCE_WAKEUP and
CAN_HWSUP, can you get the PMU interrupts working after an EMU CD idle
transition (and reset.)

Kevin

oprofile and ARM A9 hardware counter

[Kevin Hilman]

Jon Hunter <jon-hunter@ti.com> writes:

> On 05/08/2012 11:18 AM, Kevin Hilman wrote:
>> "Cousson, Benoit" <b-cousson@ti.com> writes:
>> 
>>> On 5/8/2012 4:00 PM, Kevin Hilman wrote:
>>>> Jean Pihet<jean.pihet@newoldbits.com>  writes:
>>>>
>>>> [...]
>>>>
>>>>>>>> Yes, indeed, we should not hack the flags to fix that kind of issue. The
>>>>>>>> flags describe what the HW is capable of, and the EMU CD can support
>>>>>>>> HW_AUTO
>>>>>>>> and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the only valid
>>>>>>>> next
>>>>>>>> power state is OFF, meaning that no retention mode is supported. So any
>>>>>>>> transition to idle will go to OFF and lead to a reset upon wakeup.
>>>>>>>>
>>>>>>>> That being said, being able to transition to OFF during idle is a
>>>>>>>> perfectly
>>>>>>>> valid state for most powerdomain in OMAP anyway, so we should be able to
>>>>>>>> restore from OFF mode smoothly.
>>>>>>>>
>>>>>>>> It looks to me that what is missing here is *just* a restore path in the
>>>>>>>> PMU/CTI code. But I'm probably missing some nasty details in this issue
>>>>>>>> :-)
>>>>>>>
>>>>>>> Although it is perfectly feasible to have a seamless transition of the
>>>>>>> EMU power domain, I think the PMU counters will not be accurate
>>>>>>> anymore since they stop counting events when going to OFF and re-start
>>>>>>> after the state restore.
>>>>>>
>>>>>>
>>>>>> Good point, but I think the PMU might still works fine because located
>>>>>> inside the MPU domain. AFAIR, only the path to access the PMU and the CTI is
>>>>>> going to OFF and thus will be reset.
>>>>>
>>>>> Ever better point ;p Thanks for the precision.
>>>>> In any case my point was: can we allow the EMU CD to go OFF or prevent
>>>>> it from doing so? We need to answer that question first.
>>>>>
>>>>
>>>> The idea I've suggested is to use runtime PM for this.  As long as the
>>>> PMU is in use, it will be runtime PM enabled (and not allowed to go into
>>>> HWSUP idle.)  When it is not used, it will be allowed to HWSUP idle, and
>>>> then be reset.  The next time it is needed, the runtime resume will need
>>>> to do a full re-init.
>>>
>>> Oh, but does that mean that this driver is not pm_runtime adapted yet?
>>>
>> 
>> Actually, it is.  Ming Lei has done it.
>> 
>> Currently, Will has collected this[1] and is waiting (patiently) for us
>> to produce a real fix that doesn't kill PM in the process.
>
> I had to make a couple mods to Ming's patches but I do have something
> working now that _should_ not break PM. However, per my previous email
> (in response to Benoit's) I am struggling with the definition of the
> CLKDM_CAN_XXXXXX_AUTO flags to know the correct way to fix this.
>
> I was going to send out my patches, but I wanted to get some more
> feedback on this first.

While waiting for feeback, if you set the flags to CAN_FORCE_WAKEUP and
CAN_HWSUP, can you get the PMU interrupts working after an EMU CD idle
transition (and reset.)

Kevin

Re: oprofile and ARM A9 hardware counter

[Jon Hunter]

Hi Kevin,

On 05/08/2012 04:28 PM, Kevin Hilman wrote:
> Jon Hunter <jon-hunter@ti.com> writes:
> 
>> On 05/08/2012 11:18 AM, Kevin Hilman wrote:
>>> "Cousson, Benoit" <b-cousson@ti.com> writes:
>>>
>>>> On 5/8/2012 4:00 PM, Kevin Hilman wrote:
>>>>> Jean Pihet<jean.pihet@newoldbits.com>  writes:
>>>>>
>>>>> [...]
>>>>>
>>>>>>>>> Yes, indeed, we should not hack the flags to fix that kind of issue. The
>>>>>>>>> flags describe what the HW is capable of, and the EMU CD can support
>>>>>>>>> HW_AUTO
>>>>>>>>> and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the only valid
>>>>>>>>> next
>>>>>>>>> power state is OFF, meaning that no retention mode is supported. So any
>>>>>>>>> transition to idle will go to OFF and lead to a reset upon wakeup.
>>>>>>>>>
>>>>>>>>> That being said, being able to transition to OFF during idle is a
>>>>>>>>> perfectly
>>>>>>>>> valid state for most powerdomain in OMAP anyway, so we should be able to
>>>>>>>>> restore from OFF mode smoothly.
>>>>>>>>>
>>>>>>>>> It looks to me that what is missing here is *just* a restore path in the
>>>>>>>>> PMU/CTI code. But I'm probably missing some nasty details in this issue
>>>>>>>>> :-)
>>>>>>>>
>>>>>>>> Although it is perfectly feasible to have a seamless transition of the
>>>>>>>> EMU power domain, I think the PMU counters will not be accurate
>>>>>>>> anymore since they stop counting events when going to OFF and re-start
>>>>>>>> after the state restore.
>>>>>>>
>>>>>>>
>>>>>>> Good point, but I think the PMU might still works fine because located
>>>>>>> inside the MPU domain. AFAIR, only the path to access the PMU and the CTI is
>>>>>>> going to OFF and thus will be reset.
>>>>>>
>>>>>> Ever better point ;p Thanks for the precision.
>>>>>> In any case my point was: can we allow the EMU CD to go OFF or prevent
>>>>>> it from doing so? We need to answer that question first.
>>>>>>
>>>>>
>>>>> The idea I've suggested is to use runtime PM for this.  As long as the
>>>>> PMU is in use, it will be runtime PM enabled (and not allowed to go into
>>>>> HWSUP idle.)  When it is not used, it will be allowed to HWSUP idle, and
>>>>> then be reset.  The next time it is needed, the runtime resume will need
>>>>> to do a full re-init.
>>>>
>>>> Oh, but does that mean that this driver is not pm_runtime adapted yet?
>>>>
>>>
>>> Actually, it is.  Ming Lei has done it.
>>>
>>> Currently, Will has collected this[1] and is waiting (patiently) for us
>>> to produce a real fix that doesn't kill PM in the process.
>>
>> I had to make a couple mods to Ming's patches but I do have something
>> working now that _should_ not break PM. However, per my previous email
>> (in response to Benoit's) I am struggling with the definition of the
>> CLKDM_CAN_XXXXXX_AUTO flags to know the correct way to fix this.
>>
>> I was going to send out my patches, but I wanted to get some more
>> feedback on this first.
> 
> While waiting for feeback, if you set the flags to CAN_FORCE_WAKEUP and
> CAN_HWSUP, can you get the PMU interrupts working after an EMU CD idle
> transition (and reset.)

Unfortunately, not. By setting CAN_HWSUP, the EMU CD will be put back
into HW_AUTO state when it is enabled. The hwmod _enable() function will
first put the CD into SW_WKUP (because CAN_FORCE_WAKEUP is set), but
because it was previously in HW_AUTO state AND CAN_ENABLE_AUTO is set it
will be be put back into HW_AUTO again. Hence, we are back where we begun!

CAN_ENABLE_AUTO is causing me a headache, because whenever you call
clkdm_allow_idle, it will allow it to idle and this happens during the
_enable() sequence :-(

Does this make sense?

Cheers
Jon

oprofile and ARM A9 hardware counter

[Jon Hunter]

Hi Kevin,

On 05/08/2012 04:28 PM, Kevin Hilman wrote:
> Jon Hunter <jon-hunter@ti.com> writes:
> 
>> On 05/08/2012 11:18 AM, Kevin Hilman wrote:
>>> "Cousson, Benoit" <b-cousson@ti.com> writes:
>>>
>>>> On 5/8/2012 4:00 PM, Kevin Hilman wrote:
>>>>> Jean Pihet<jean.pihet@newoldbits.com>  writes:
>>>>>
>>>>> [...]
>>>>>
>>>>>>>>> Yes, indeed, we should not hack the flags to fix that kind of issue. The
>>>>>>>>> flags describe what the HW is capable of, and the EMU CD can support
>>>>>>>>> HW_AUTO
>>>>>>>>> and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the only valid
>>>>>>>>> next
>>>>>>>>> power state is OFF, meaning that no retention mode is supported. So any
>>>>>>>>> transition to idle will go to OFF and lead to a reset upon wakeup.
>>>>>>>>>
>>>>>>>>> That being said, being able to transition to OFF during idle is a
>>>>>>>>> perfectly
>>>>>>>>> valid state for most powerdomain in OMAP anyway, so we should be able to
>>>>>>>>> restore from OFF mode smoothly.
>>>>>>>>>
>>>>>>>>> It looks to me that what is missing here is *just* a restore path in the
>>>>>>>>> PMU/CTI code. But I'm probably missing some nasty details in this issue
>>>>>>>>> :-)
>>>>>>>>
>>>>>>>> Although it is perfectly feasible to have a seamless transition of the
>>>>>>>> EMU power domain, I think the PMU counters will not be accurate
>>>>>>>> anymore since they stop counting events when going to OFF and re-start
>>>>>>>> after the state restore.
>>>>>>>
>>>>>>>
>>>>>>> Good point, but I think the PMU might still works fine because located
>>>>>>> inside the MPU domain. AFAIR, only the path to access the PMU and the CTI is
>>>>>>> going to OFF and thus will be reset.
>>>>>>
>>>>>> Ever better point ;p Thanks for the precision.
>>>>>> In any case my point was: can we allow the EMU CD to go OFF or prevent
>>>>>> it from doing so? We need to answer that question first.
>>>>>>
>>>>>
>>>>> The idea I've suggested is to use runtime PM for this.  As long as the
>>>>> PMU is in use, it will be runtime PM enabled (and not allowed to go into
>>>>> HWSUP idle.)  When it is not used, it will be allowed to HWSUP idle, and
>>>>> then be reset.  The next time it is needed, the runtime resume will need
>>>>> to do a full re-init.
>>>>
>>>> Oh, but does that mean that this driver is not pm_runtime adapted yet?
>>>>
>>>
>>> Actually, it is.  Ming Lei has done it.
>>>
>>> Currently, Will has collected this[1] and is waiting (patiently) for us
>>> to produce a real fix that doesn't kill PM in the process.
>>
>> I had to make a couple mods to Ming's patches but I do have something
>> working now that _should_ not break PM. However, per my previous email
>> (in response to Benoit's) I am struggling with the definition of the
>> CLKDM_CAN_XXXXXX_AUTO flags to know the correct way to fix this.
>>
>> I was going to send out my patches, but I wanted to get some more
>> feedback on this first.
> 
> While waiting for feeback, if you set the flags to CAN_FORCE_WAKEUP and
> CAN_HWSUP, can you get the PMU interrupts working after an EMU CD idle
> transition (and reset.)

Unfortunately, not. By setting CAN_HWSUP, the EMU CD will be put back
into HW_AUTO state when it is enabled. The hwmod _enable() function will
first put the CD into SW_WKUP (because CAN_FORCE_WAKEUP is set), but
because it was previously in HW_AUTO state AND CAN_ENABLE_AUTO is set it
will be be put back into HW_AUTO again. Hence, we are back where we begun!

CAN_ENABLE_AUTO is causing me a headache, because whenever you call
clkdm_allow_idle, it will allow it to idle and this happens during the
_enable() sequence :-(

Does this make sense?

Cheers
Jon

Re: oprofile and ARM A9 hardware counter

[Ming Lei]

On Wed, May 9, 2012 at 3:51 AM, Jon Hunter <jon-hunter@ti.com> wrote:
>
>
> I had to make a couple mods to Ming's patches but I do have something
> working now that _should_ not break PM. However, per my previous email
> (in response to Benoit's) I am struggling with the definition of the
> CLKDM_CAN_XXXXXX_AUTO flags to know the correct way to fix this.
>
> I was going to send out my patches, but I wanted to get some more
> feedback on this first.

I can test your patch once I return home from business trip next week.


Thanks,
--
Ming Lei

oprofile and ARM A9 hardware counter

[Ming Lei]

On Wed, May 9, 2012 at 3:51 AM, Jon Hunter <jon-hunter@ti.com> wrote:
>
>
> I had to make a couple mods to Ming's patches but I do have something
> working now that _should_ not break PM. However, per my previous email
> (in response to Benoit's) I am struggling with the definition of the
> CLKDM_CAN_XXXXXX_AUTO flags to know the correct way to fix this.
>
> I was going to send out my patches, but I wanted to get some more
> feedback on this first.

I can test your patch once I return home from business trip next week.


Thanks,
--
Ming Lei

Re: oprofile and ARM A9 hardware counter

[Jon Hunter]

Hi Benoit,

On 05/08/2012 06:01 AM, Cousson, Benoit wrote:

[...]

>>>> P.S. Please note there is also already a different fix in mainline for
>>>> the EMU clkdm data from Paul which adds the force wakeup flag and
>>>> removes the DISABLE_AUTO flag[1] (but leaves the ENABLE_AUTO flag,
>>>> because the hardware is capable.)
>>>
>>> Hmmm ... yes saw this, and you will have to excuse me as I don't fully
>>> follow the logic here. In fact, I am thinking we want the opposite ;-)
>>>
>>>  From looking, into this it seems to me that when PMU is running we want
>>> the EMU clock domain in software-wakeup state and when PMU is not
>>> running we want in the hardware auto state.
>>
>> So far, I'm with you.
>>
>>> By keeping the ENABLE_AUTO flag set, as soon as we enable the clock
>>> domain it is put right back into the HW_AUTO state
>>
>> This is only because it was in the HWSUP state when _enable was called.
>> If clkdm_deny_idle() is used, that behavior will change.
>>
>>> and hence PMU is
>>> not working (see _enable() function in
>>> arch/arm/mach-omap2/omap_hwmod.c)
>>>
>>> So really what I think we want is to remove the ENABLE_AUTO flag to keep
>>> the clock domain in software wake-up and use the DISABLE_AUTO flag to
>>> put the clock domain back in HW_AUTO (note this requires a patch to
>>> perform this 2nd part).
>>
>> Well, Paul will have to comment here for the final word, but IIUC, the
>> hwmod flags are supposed to indicate only what the HW is capable of.  If
>> we want to change the runtime behavior, we nee to use (or add) APIs to
>> change the beahvior.  In this case, clkdm_allow_idle(),
>> clkdm_deny_idle() are probably what is needed here.
> 
> Yes, indeed, we should not hack the flags to fix that kind of issue. The
> flags describe what the HW is capable of, and the EMU CD can support
> HW_AUTO and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the
> only valid next power state is OFF, meaning that no retention mode is
> supported. So any transition to idle will go to OFF and lead to a reset
> upon wakeup.

No hacking intended here, just getting the flags correct ;-)

So let me start from the beginning ...

1. I agree that for the EMU CD that the valid HW states are HW_AUTO and
SW_WKUP.

2. When the EMU CD is active (due to something like PMU), we want to
keep the CD in the SW_WKUP state, otherwise we can automatically
transition to idle and reset the IP (at least for omap4430).

3. When the EMU CD is inactive, we want to keep the CD in the HW_AUTO
state because SW_SLEEP is NOT supported.

In the current code, we have the CLKDM_CAN_DISABLE_AUTO flag disabled
and the CLKDM_CAN_ENABLE_AUTO flag enabled. If CLKDM_CAN_ENABLE_AUTO is
set then the omap_pm_clkdms_setup() function will place the CD into
HW_AUTO regardless of CLKDM_CAN_DISABLE_AUTO, and the next time the
hwmod _enable() is called it is in the HW_AUTO state and so it is
allowed to idle. This is not what we want. Do you agree?

If I set CLKDM_CAN_DISABLE_AUTO flag and disable CLKDM_CAN_ENABLE_AUTO,
then I do not have the above problem.

To be honest, with you the more I look and test the code, the more
confused I am by the definition of the CLKDM_CAN_HWSUP ...

#define CLKDM_CAN_HWSUP	(CLKDM_CAN_ENABLE_AUTO | CLKDM_CAN_DISABLE_AUTO)

When I look at where these flags are used, I see that
CLKDM_CAN_ENABLE_AUTO is used in clkdm_allow_idle and
CLKDM_CAN_DISABLE_AUTO is used in clkdm_deny_idle. So this implies that ...

CLKDM_CAN_ENABLE_AUTO = Supports HW_AUTO state when CD is active
CLKDM_CAN_DISABLE_AUTO = Does NOT supports HW_AUTO state when CD is active

Are the above the correct definitions? If so why is CLKDM_CAN_HWSUP
defined as above?

So may be I just needed to understand how these flags are intended to be
used.

> That being said, being able to transition to OFF during idle is a
> perfectly valid state for most powerdomain in OMAP anyway, so we should
> be able to restore from OFF mode smoothly.
> 
> It looks to me that what is missing here is *just* a restore path in the
> PMU/CTI code. But I'm probably missing some nasty details in this issue :-)

Yes agree with this too.

Cheers
Jon

oprofile and ARM A9 hardware counter

[Jon Hunter]

Hi Benoit,

On 05/08/2012 06:01 AM, Cousson, Benoit wrote:

[...]

>>>> P.S. Please note there is also already a different fix in mainline for
>>>> the EMU clkdm data from Paul which adds the force wakeup flag and
>>>> removes the DISABLE_AUTO flag[1] (but leaves the ENABLE_AUTO flag,
>>>> because the hardware is capable.)
>>>
>>> Hmmm ... yes saw this, and you will have to excuse me as I don't fully
>>> follow the logic here. In fact, I am thinking we want the opposite ;-)
>>>
>>>  From looking, into this it seems to me that when PMU is running we want
>>> the EMU clock domain in software-wakeup state and when PMU is not
>>> running we want in the hardware auto state.
>>
>> So far, I'm with you.
>>
>>> By keeping the ENABLE_AUTO flag set, as soon as we enable the clock
>>> domain it is put right back into the HW_AUTO state
>>
>> This is only because it was in the HWSUP state when _enable was called.
>> If clkdm_deny_idle() is used, that behavior will change.
>>
>>> and hence PMU is
>>> not working (see _enable() function in
>>> arch/arm/mach-omap2/omap_hwmod.c)
>>>
>>> So really what I think we want is to remove the ENABLE_AUTO flag to keep
>>> the clock domain in software wake-up and use the DISABLE_AUTO flag to
>>> put the clock domain back in HW_AUTO (note this requires a patch to
>>> perform this 2nd part).
>>
>> Well, Paul will have to comment here for the final word, but IIUC, the
>> hwmod flags are supposed to indicate only what the HW is capable of.  If
>> we want to change the runtime behavior, we nee to use (or add) APIs to
>> change the beahvior.  In this case, clkdm_allow_idle(),
>> clkdm_deny_idle() are probably what is needed here.
> 
> Yes, indeed, we should not hack the flags to fix that kind of issue. The
> flags describe what the HW is capable of, and the EMU CD can support
> HW_AUTO and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the
> only valid next power state is OFF, meaning that no retention mode is
> supported. So any transition to idle will go to OFF and lead to a reset
> upon wakeup.

No hacking intended here, just getting the flags correct ;-)

So let me start from the beginning ...

1. I agree that for the EMU CD that the valid HW states are HW_AUTO and
SW_WKUP.

2. When the EMU CD is active (due to something like PMU), we want to
keep the CD in the SW_WKUP state, otherwise we can automatically
transition to idle and reset the IP (at least for omap4430).

3. When the EMU CD is inactive, we want to keep the CD in the HW_AUTO
state because SW_SLEEP is NOT supported.

In the current code, we have the CLKDM_CAN_DISABLE_AUTO flag disabled
and the CLKDM_CAN_ENABLE_AUTO flag enabled. If CLKDM_CAN_ENABLE_AUTO is
set then the omap_pm_clkdms_setup() function will place the CD into
HW_AUTO regardless of CLKDM_CAN_DISABLE_AUTO, and the next time the
hwmod _enable() is called it is in the HW_AUTO state and so it is
allowed to idle. This is not what we want. Do you agree?

If I set CLKDM_CAN_DISABLE_AUTO flag and disable CLKDM_CAN_ENABLE_AUTO,
then I do not have the above problem.

To be honest, with you the more I look and test the code, the more
confused I am by the definition of the CLKDM_CAN_HWSUP ...

#define CLKDM_CAN_HWSUP	(CLKDM_CAN_ENABLE_AUTO | CLKDM_CAN_DISABLE_AUTO)

When I look at where these flags are used, I see that
CLKDM_CAN_ENABLE_AUTO is used in clkdm_allow_idle and
CLKDM_CAN_DISABLE_AUTO is used in clkdm_deny_idle. So this implies that ...

CLKDM_CAN_ENABLE_AUTO = Supports HW_AUTO state when CD is active
CLKDM_CAN_DISABLE_AUTO = Does NOT supports HW_AUTO state when CD is active

Are the above the correct definitions? If so why is CLKDM_CAN_HWSUP
defined as above?

So may be I just needed to understand how these flags are intended to be
used.

> That being said, being able to transition to OFF during idle is a
> perfectly valid state for most powerdomain in OMAP anyway, so we should
> be able to restore from OFF mode smoothly.
> 
> It looks to me that what is missing here is *just* a restore path in the
> PMU/CTI code. But I'm probably missing some nasty details in this issue :-)

Yes agree with this too.

Cheers
Jon

Re: oprofile and ARM A9 hardware counter

[Kevin Hilman]

Jon Hunter <jon-hunter@ti.com> writes:

> Hi Benoit,
>
> On 05/08/2012 06:01 AM, Cousson, Benoit wrote:
>
> [...]
>
>>>>> P.S. Please note there is also already a different fix in mainline for
>>>>> the EMU clkdm data from Paul which adds the force wakeup flag and
>>>>> removes the DISABLE_AUTO flag[1] (but leaves the ENABLE_AUTO flag,
>>>>> because the hardware is capable.)
>>>>
>>>> Hmmm ... yes saw this, and you will have to excuse me as I don't fully
>>>> follow the logic here. In fact, I am thinking we want the opposite ;-)
>>>>
>>>>  From looking, into this it seems to me that when PMU is running we want
>>>> the EMU clock domain in software-wakeup state and when PMU is not
>>>> running we want in the hardware auto state.
>>>
>>> So far, I'm with you.
>>>
>>>> By keeping the ENABLE_AUTO flag set, as soon as we enable the clock
>>>> domain it is put right back into the HW_AUTO state
>>>
>>> This is only because it was in the HWSUP state when _enable was called.
>>> If clkdm_deny_idle() is used, that behavior will change.
>>>
>>>> and hence PMU is
>>>> not working (see _enable() function in
>>>> arch/arm/mach-omap2/omap_hwmod.c)
>>>>
>>>> So really what I think we want is to remove the ENABLE_AUTO flag to keep
>>>> the clock domain in software wake-up and use the DISABLE_AUTO flag to
>>>> put the clock domain back in HW_AUTO (note this requires a patch to
>>>> perform this 2nd part).
>>>
>>> Well, Paul will have to comment here for the final word, but IIUC, the
>>> hwmod flags are supposed to indicate only what the HW is capable of.  If
>>> we want to change the runtime behavior, we nee to use (or add) APIs to
>>> change the beahvior.  In this case, clkdm_allow_idle(),
>>> clkdm_deny_idle() are probably what is needed here.
>> 
>> Yes, indeed, we should not hack the flags to fix that kind of issue. The
>> flags describe what the HW is capable of, and the EMU CD can support
>> HW_AUTO and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the
>> only valid next power state is OFF, meaning that no retention mode is
>> supported. So any transition to idle will go to OFF and lead to a reset
>> upon wakeup.
>
> No hacking intended here, just getting the flags correct ;-)
>
> So let me start from the beginning ...
>
> 1. I agree that for the EMU CD that the valid HW states are HW_AUTO and
> SW_WKUP.
>
> 2. When the EMU CD is active (due to something like PMU), we want to
> keep the CD in the SW_WKUP state, otherwise we can automatically
> transition to idle and reset the IP (at least for omap4430).

> 3. When the EMU CD is inactive, we want to keep the CD in the HW_AUTO
> state because SW_SLEEP is NOT supported.
>
> In the current code, we have the CLKDM_CAN_DISABLE_AUTO flag disabled
> and the CLKDM_CAN_ENABLE_AUTO flag enabled. If CLKDM_CAN_ENABLE_AUTO is
> set then the omap_pm_clkdms_setup() function will place the CD into
> HW_AUTO regardless of CLKDM_CAN_DISABLE_AUTO, and the next time the
> hwmod _enable() is called it is in the HW_AUTO state and so it is
> allowed to idle. This is not what we want. Do you agree?
>
> If I set CLKDM_CAN_DISABLE_AUTO flag and disable CLKDM_CAN_ENABLE_AUTO,
> then I do not have the above problem.
>
> To be honest, with you the more I look and test the code, the more
> confused I am by the definition of the CLKDM_CAN_HWSUP ...
>
> #define CLKDM_CAN_HWSUP	(CLKDM_CAN_ENABLE_AUTO | CLKDM_CAN_DISABLE_AUTO)
>
> When I look at where these flags are used, I see that
> CLKDM_CAN_ENABLE_AUTO is used in clkdm_allow_idle and
> CLKDM_CAN_DISABLE_AUTO is used in clkdm_deny_idle. So this implies that ...
>
> CLKDM_CAN_ENABLE_AUTO = Supports HW_AUTO state when CD is active
> CLKDM_CAN_DISABLE_AUTO = Does NOT supports HW_AUTO state when CD is active
>
> Are the above the correct definitions? 

Not quite. 

These flags describe the capabilities as defined in CLKTRCTRL field of
the CLKSTCTRL register (e.g. CM_EMU_CLKSTCTRL)

CLKDM_CAN_ENABLE_AUTO: IP supports HW_AUTO state (and it can be enabled)
CLKDM_CAN_DISABLE_AUTO: HW_AUTO feature can be disabled (a.k.a. NO_SLEEP)

Note that in OMAP4, the latter called NO_SLEEP in the TRM, but in OMAP3
it's described as "The automatic hardware-supervised mode is disabled"

What is confusing to me is that the OMAP4 TRM doesn't list the NO_SLEEP
mode as supported by the EMU.   It seems to me that if the IP supports
HW_AUTO, it should be able to be enabled *and* disabled. 

Maybe Paul/Benoit can clarify.

Kevin

oprofile and ARM A9 hardware counter

[Kevin Hilman]

Jon Hunter <jon-hunter@ti.com> writes:

> Hi Benoit,
>
> On 05/08/2012 06:01 AM, Cousson, Benoit wrote:
>
> [...]
>
>>>>> P.S. Please note there is also already a different fix in mainline for
>>>>> the EMU clkdm data from Paul which adds the force wakeup flag and
>>>>> removes the DISABLE_AUTO flag[1] (but leaves the ENABLE_AUTO flag,
>>>>> because the hardware is capable.)
>>>>
>>>> Hmmm ... yes saw this, and you will have to excuse me as I don't fully
>>>> follow the logic here. In fact, I am thinking we want the opposite ;-)
>>>>
>>>>  From looking, into this it seems to me that when PMU is running we want
>>>> the EMU clock domain in software-wakeup state and when PMU is not
>>>> running we want in the hardware auto state.
>>>
>>> So far, I'm with you.
>>>
>>>> By keeping the ENABLE_AUTO flag set, as soon as we enable the clock
>>>> domain it is put right back into the HW_AUTO state
>>>
>>> This is only because it was in the HWSUP state when _enable was called.
>>> If clkdm_deny_idle() is used, that behavior will change.
>>>
>>>> and hence PMU is
>>>> not working (see _enable() function in
>>>> arch/arm/mach-omap2/omap_hwmod.c)
>>>>
>>>> So really what I think we want is to remove the ENABLE_AUTO flag to keep
>>>> the clock domain in software wake-up and use the DISABLE_AUTO flag to
>>>> put the clock domain back in HW_AUTO (note this requires a patch to
>>>> perform this 2nd part).
>>>
>>> Well, Paul will have to comment here for the final word, but IIUC, the
>>> hwmod flags are supposed to indicate only what the HW is capable of.  If
>>> we want to change the runtime behavior, we nee to use (or add) APIs to
>>> change the beahvior.  In this case, clkdm_allow_idle(),
>>> clkdm_deny_idle() are probably what is needed here.
>> 
>> Yes, indeed, we should not hack the flags to fix that kind of issue. The
>> flags describe what the HW is capable of, and the EMU CD can support
>> HW_AUTO and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the
>> only valid next power state is OFF, meaning that no retention mode is
>> supported. So any transition to idle will go to OFF and lead to a reset
>> upon wakeup.
>
> No hacking intended here, just getting the flags correct ;-)
>
> So let me start from the beginning ...
>
> 1. I agree that for the EMU CD that the valid HW states are HW_AUTO and
> SW_WKUP.
>
> 2. When the EMU CD is active (due to something like PMU), we want to
> keep the CD in the SW_WKUP state, otherwise we can automatically
> transition to idle and reset the IP (at least for omap4430).

> 3. When the EMU CD is inactive, we want to keep the CD in the HW_AUTO
> state because SW_SLEEP is NOT supported.
>
> In the current code, we have the CLKDM_CAN_DISABLE_AUTO flag disabled
> and the CLKDM_CAN_ENABLE_AUTO flag enabled. If CLKDM_CAN_ENABLE_AUTO is
> set then the omap_pm_clkdms_setup() function will place the CD into
> HW_AUTO regardless of CLKDM_CAN_DISABLE_AUTO, and the next time the
> hwmod _enable() is called it is in the HW_AUTO state and so it is
> allowed to idle. This is not what we want. Do you agree?
>
> If I set CLKDM_CAN_DISABLE_AUTO flag and disable CLKDM_CAN_ENABLE_AUTO,
> then I do not have the above problem.
>
> To be honest, with you the more I look and test the code, the more
> confused I am by the definition of the CLKDM_CAN_HWSUP ...
>
> #define CLKDM_CAN_HWSUP	(CLKDM_CAN_ENABLE_AUTO | CLKDM_CAN_DISABLE_AUTO)
>
> When I look at where these flags are used, I see that
> CLKDM_CAN_ENABLE_AUTO is used in clkdm_allow_idle and
> CLKDM_CAN_DISABLE_AUTO is used in clkdm_deny_idle. So this implies that ...
>
> CLKDM_CAN_ENABLE_AUTO = Supports HW_AUTO state when CD is active
> CLKDM_CAN_DISABLE_AUTO = Does NOT supports HW_AUTO state when CD is active
>
> Are the above the correct definitions? 

Not quite. 

These flags describe the capabilities as defined in CLKTRCTRL field of
the CLKSTCTRL register (e.g. CM_EMU_CLKSTCTRL)

CLKDM_CAN_ENABLE_AUTO: IP supports HW_AUTO state (and it can be enabled)
CLKDM_CAN_DISABLE_AUTO: HW_AUTO feature can be disabled (a.k.a. NO_SLEEP)

Note that in OMAP4, the latter called NO_SLEEP in the TRM, but in OMAP3
it's described as "The automatic hardware-supervised mode is disabled"

What is confusing to me is that the OMAP4 TRM doesn't list the NO_SLEEP
mode as supported by the EMU.   It seems to me that if the IP supports
HW_AUTO, it should be able to be enabled *and* disabled. 

Maybe Paul/Benoit can clarify.

Kevin

Re: oprofile and ARM A9 hardware counter

[Jon Hunter]

Hi Kevin,

On 05/08/2012 04:22 PM, Kevin Hilman wrote:
> Jon Hunter <jon-hunter@ti.com> writes:
> 
>> Hi Benoit,
>>
>> On 05/08/2012 06:01 AM, Cousson, Benoit wrote:
>>
>> [...]
>>
>>>>>> P.S. Please note there is also already a different fix in mainline for
>>>>>> the EMU clkdm data from Paul which adds the force wakeup flag and
>>>>>> removes the DISABLE_AUTO flag[1] (but leaves the ENABLE_AUTO flag,
>>>>>> because the hardware is capable.)
>>>>>
>>>>> Hmmm ... yes saw this, and you will have to excuse me as I don't fully
>>>>> follow the logic here. In fact, I am thinking we want the opposite ;-)
>>>>>
>>>>>  From looking, into this it seems to me that when PMU is running we want
>>>>> the EMU clock domain in software-wakeup state and when PMU is not
>>>>> running we want in the hardware auto state.
>>>>
>>>> So far, I'm with you.
>>>>
>>>>> By keeping the ENABLE_AUTO flag set, as soon as we enable the clock
>>>>> domain it is put right back into the HW_AUTO state
>>>>
>>>> This is only because it was in the HWSUP state when _enable was called.
>>>> If clkdm_deny_idle() is used, that behavior will change.
>>>>
>>>>> and hence PMU is
>>>>> not working (see _enable() function in
>>>>> arch/arm/mach-omap2/omap_hwmod.c)
>>>>>
>>>>> So really what I think we want is to remove the ENABLE_AUTO flag to keep
>>>>> the clock domain in software wake-up and use the DISABLE_AUTO flag to
>>>>> put the clock domain back in HW_AUTO (note this requires a patch to
>>>>> perform this 2nd part).
>>>>
>>>> Well, Paul will have to comment here for the final word, but IIUC, the
>>>> hwmod flags are supposed to indicate only what the HW is capable of.  If
>>>> we want to change the runtime behavior, we nee to use (or add) APIs to
>>>> change the beahvior.  In this case, clkdm_allow_idle(),
>>>> clkdm_deny_idle() are probably what is needed here.
>>>
>>> Yes, indeed, we should not hack the flags to fix that kind of issue. The
>>> flags describe what the HW is capable of, and the EMU CD can support
>>> HW_AUTO and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the
>>> only valid next power state is OFF, meaning that no retention mode is
>>> supported. So any transition to idle will go to OFF and lead to a reset
>>> upon wakeup.
>>
>> No hacking intended here, just getting the flags correct ;-)
>>
>> So let me start from the beginning ...
>>
>> 1. I agree that for the EMU CD that the valid HW states are HW_AUTO and
>> SW_WKUP.
>>
>> 2. When the EMU CD is active (due to something like PMU), we want to
>> keep the CD in the SW_WKUP state, otherwise we can automatically
>> transition to idle and reset the IP (at least for omap4430).
> 
>> 3. When the EMU CD is inactive, we want to keep the CD in the HW_AUTO
>> state because SW_SLEEP is NOT supported.
>>
>> In the current code, we have the CLKDM_CAN_DISABLE_AUTO flag disabled
>> and the CLKDM_CAN_ENABLE_AUTO flag enabled. If CLKDM_CAN_ENABLE_AUTO is
>> set then the omap_pm_clkdms_setup() function will place the CD into
>> HW_AUTO regardless of CLKDM_CAN_DISABLE_AUTO, and the next time the
>> hwmod _enable() is called it is in the HW_AUTO state and so it is
>> allowed to idle. This is not what we want. Do you agree?
>>
>> If I set CLKDM_CAN_DISABLE_AUTO flag and disable CLKDM_CAN_ENABLE_AUTO,
>> then I do not have the above problem.
>>
>> To be honest, with you the more I look and test the code, the more
>> confused I am by the definition of the CLKDM_CAN_HWSUP ...
>>
>> #define CLKDM_CAN_HWSUP	(CLKDM_CAN_ENABLE_AUTO | CLKDM_CAN_DISABLE_AUTO)
>>
>> When I look at where these flags are used, I see that
>> CLKDM_CAN_ENABLE_AUTO is used in clkdm_allow_idle and
>> CLKDM_CAN_DISABLE_AUTO is used in clkdm_deny_idle. So this implies that ...
>>
>> CLKDM_CAN_ENABLE_AUTO = Supports HW_AUTO state when CD is active
>> CLKDM_CAN_DISABLE_AUTO = Does NOT supports HW_AUTO state when CD is active
>>
>> Are the above the correct definitions? 
> 
> Not quite. 
> 
> These flags describe the capabilities as defined in CLKTRCTRL field of
> the CLKSTCTRL register (e.g. CM_EMU_CLKSTCTRL)
> 
> CLKDM_CAN_ENABLE_AUTO: IP supports HW_AUTO state (and it can be enabled)
> CLKDM_CAN_DISABLE_AUTO: HW_AUTO feature can be disabled (a.k.a. NO_SLEEP)

Ok, so it that case it is wrong to set CAN_DISABLE_AUTO for the EMU CD.

> Note that in OMAP4, the latter called NO_SLEEP in the TRM, but in OMAP3
> it's described as "The automatic hardware-supervised mode is disabled"

Ah-ha. So this explains the naming! Thanks!

> What is confusing to me is that the OMAP4 TRM doesn't list the NO_SLEEP
> mode as supported by the EMU.   It seems to me that if the IP supports
> HW_AUTO, it should be able to be enabled *and* disabled. 
> 
> Maybe Paul/Benoit can clarify.

Yes, it definitely appears that EMU does not support NO_SLEEP according
to the TRM. However, even if it did, this would not help in this case as
we need to keep the CD in the SW_WKUP state while active. However, the
problem with this is it breaks the current software model that is used
to manage the CDs.

It is not a good solution, but for this domain it would appear that we
would need to have another flag, such as, "CAN_ENABLE_AUTO_ON_INACTIVE" :-(

Let me know what you think.

Cheers
Jon

oprofile and ARM A9 hardware counter

[Jon Hunter]

Hi Kevin,

On 05/08/2012 04:22 PM, Kevin Hilman wrote:
> Jon Hunter <jon-hunter@ti.com> writes:
> 
>> Hi Benoit,
>>
>> On 05/08/2012 06:01 AM, Cousson, Benoit wrote:
>>
>> [...]
>>
>>>>>> P.S. Please note there is also already a different fix in mainline for
>>>>>> the EMU clkdm data from Paul which adds the force wakeup flag and
>>>>>> removes the DISABLE_AUTO flag[1] (but leaves the ENABLE_AUTO flag,
>>>>>> because the hardware is capable.)
>>>>>
>>>>> Hmmm ... yes saw this, and you will have to excuse me as I don't fully
>>>>> follow the logic here. In fact, I am thinking we want the opposite ;-)
>>>>>
>>>>>  From looking, into this it seems to me that when PMU is running we want
>>>>> the EMU clock domain in software-wakeup state and when PMU is not
>>>>> running we want in the hardware auto state.
>>>>
>>>> So far, I'm with you.
>>>>
>>>>> By keeping the ENABLE_AUTO flag set, as soon as we enable the clock
>>>>> domain it is put right back into the HW_AUTO state
>>>>
>>>> This is only because it was in the HWSUP state when _enable was called.
>>>> If clkdm_deny_idle() is used, that behavior will change.
>>>>
>>>>> and hence PMU is
>>>>> not working (see _enable() function in
>>>>> arch/arm/mach-omap2/omap_hwmod.c)
>>>>>
>>>>> So really what I think we want is to remove the ENABLE_AUTO flag to keep
>>>>> the clock domain in software wake-up and use the DISABLE_AUTO flag to
>>>>> put the clock domain back in HW_AUTO (note this requires a patch to
>>>>> perform this 2nd part).
>>>>
>>>> Well, Paul will have to comment here for the final word, but IIUC, the
>>>> hwmod flags are supposed to indicate only what the HW is capable of.  If
>>>> we want to change the runtime behavior, we nee to use (or add) APIs to
>>>> change the beahvior.  In this case, clkdm_allow_idle(),
>>>> clkdm_deny_idle() are probably what is needed here.
>>>
>>> Yes, indeed, we should not hack the flags to fix that kind of issue. The
>>> flags describe what the HW is capable of, and the EMU CD can support
>>> HW_AUTO and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the
>>> only valid next power state is OFF, meaning that no retention mode is
>>> supported. So any transition to idle will go to OFF and lead to a reset
>>> upon wakeup.
>>
>> No hacking intended here, just getting the flags correct ;-)
>>
>> So let me start from the beginning ...
>>
>> 1. I agree that for the EMU CD that the valid HW states are HW_AUTO and
>> SW_WKUP.
>>
>> 2. When the EMU CD is active (due to something like PMU), we want to
>> keep the CD in the SW_WKUP state, otherwise we can automatically
>> transition to idle and reset the IP (at least for omap4430).
> 
>> 3. When the EMU CD is inactive, we want to keep the CD in the HW_AUTO
>> state because SW_SLEEP is NOT supported.
>>
>> In the current code, we have the CLKDM_CAN_DISABLE_AUTO flag disabled
>> and the CLKDM_CAN_ENABLE_AUTO flag enabled. If CLKDM_CAN_ENABLE_AUTO is
>> set then the omap_pm_clkdms_setup() function will place the CD into
>> HW_AUTO regardless of CLKDM_CAN_DISABLE_AUTO, and the next time the
>> hwmod _enable() is called it is in the HW_AUTO state and so it is
>> allowed to idle. This is not what we want. Do you agree?
>>
>> If I set CLKDM_CAN_DISABLE_AUTO flag and disable CLKDM_CAN_ENABLE_AUTO,
>> then I do not have the above problem.
>>
>> To be honest, with you the more I look and test the code, the more
>> confused I am by the definition of the CLKDM_CAN_HWSUP ...
>>
>> #define CLKDM_CAN_HWSUP	(CLKDM_CAN_ENABLE_AUTO | CLKDM_CAN_DISABLE_AUTO)
>>
>> When I look at where these flags are used, I see that
>> CLKDM_CAN_ENABLE_AUTO is used in clkdm_allow_idle and
>> CLKDM_CAN_DISABLE_AUTO is used in clkdm_deny_idle. So this implies that ...
>>
>> CLKDM_CAN_ENABLE_AUTO = Supports HW_AUTO state when CD is active
>> CLKDM_CAN_DISABLE_AUTO = Does NOT supports HW_AUTO state when CD is active
>>
>> Are the above the correct definitions? 
> 
> Not quite. 
> 
> These flags describe the capabilities as defined in CLKTRCTRL field of
> the CLKSTCTRL register (e.g. CM_EMU_CLKSTCTRL)
> 
> CLKDM_CAN_ENABLE_AUTO: IP supports HW_AUTO state (and it can be enabled)
> CLKDM_CAN_DISABLE_AUTO: HW_AUTO feature can be disabled (a.k.a. NO_SLEEP)

Ok, so it that case it is wrong to set CAN_DISABLE_AUTO for the EMU CD.

> Note that in OMAP4, the latter called NO_SLEEP in the TRM, but in OMAP3
> it's described as "The automatic hardware-supervised mode is disabled"

Ah-ha. So this explains the naming! Thanks!

> What is confusing to me is that the OMAP4 TRM doesn't list the NO_SLEEP
> mode as supported by the EMU.   It seems to me that if the IP supports
> HW_AUTO, it should be able to be enabled *and* disabled. 
> 
> Maybe Paul/Benoit can clarify.

Yes, it definitely appears that EMU does not support NO_SLEEP according
to the TRM. However, even if it did, this would not help in this case as
we need to keep the CD in the SW_WKUP state while active. However, the
problem with this is it breaks the current software model that is used
to manage the CDs.

It is not a good solution, but for this domain it would appear that we
would need to have another flag, such as, "CAN_ENABLE_AUTO_ON_INACTIVE" :-(

Let me know what you think.

Cheers
Jon

Re: oprofile and ARM A9 hardware counter

[Cousson, Benoit]

Hi Kevin and Jon,

On 5/8/2012 11:22 PM, Kevin Hilman wrote:
> Jon Hunter<jon-hunter@ti.com>  writes:
> 
>> Hi Benoit,
>>
>> On 05/08/2012 06:01 AM, Cousson, Benoit wrote:
>>
>> [...]
>>
>>>>>> P.S. Please note there is also already a different fix in mainline for
>>>>>> the EMU clkdm data from Paul which adds the force wakeup flag and
>>>>>> removes the DISABLE_AUTO flag[1] (but leaves the ENABLE_AUTO flag,
>>>>>> because the hardware is capable.)
>>>>>
>>>>> Hmmm ... yes saw this, and you will have to excuse me as I don't fully
>>>>> follow the logic here. In fact, I am thinking we want the opposite ;-)
>>>>>
>>>>>   From looking, into this it seems to me that when PMU is running we want
>>>>> the EMU clock domain in software-wakeup state and when PMU is not
>>>>> running we want in the hardware auto state.
>>>>
>>>> So far, I'm with you.
>>>>
>>>>> By keeping the ENABLE_AUTO flag set, as soon as we enable the clock
>>>>> domain it is put right back into the HW_AUTO state
>>>>
>>>> This is only because it was in the HWSUP state when _enable was called.
>>>> If clkdm_deny_idle() is used, that behavior will change.
>>>>
>>>>> and hence PMU is
>>>>> not working (see _enable() function in
>>>>> arch/arm/mach-omap2/omap_hwmod.c)
>>>>>
>>>>> So really what I think we want is to remove the ENABLE_AUTO flag to keep
>>>>> the clock domain in software wake-up and use the DISABLE_AUTO flag to
>>>>> put the clock domain back in HW_AUTO (note this requires a patch to
>>>>> perform this 2nd part).
>>>>
>>>> Well, Paul will have to comment here for the final word, but IIUC, the
>>>> hwmod flags are supposed to indicate only what the HW is capable of.  If
>>>> we want to change the runtime behavior, we nee to use (or add) APIs to
>>>> change the beahvior.  In this case, clkdm_allow_idle(),
>>>> clkdm_deny_idle() are probably what is needed here.
>>>
>>> Yes, indeed, we should not hack the flags to fix that kind of issue. The
>>> flags describe what the HW is capable of, and the EMU CD can support
>>> HW_AUTO and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the
>>> only valid next power state is OFF, meaning that no retention mode is
>>> supported. So any transition to idle will go to OFF and lead to a reset
>>> upon wakeup.
>>
>> No hacking intended here, just getting the flags correct ;-)
>>
>> So let me start from the beginning ...
>>
>> 1. I agree that for the EMU CD that the valid HW states are HW_AUTO and
>> SW_WKUP.
>>
>> 2. When the EMU CD is active (due to something like PMU), we want to
>> keep the CD in the SW_WKUP state, otherwise we can automatically
>> transition to idle and reset the IP (at least for omap4430).
> 
>> 3. When the EMU CD is inactive, we want to keep the CD in the HW_AUTO
>> state because SW_SLEEP is NOT supported.
>>
>> In the current code, we have the CLKDM_CAN_DISABLE_AUTO flag disabled
>> and the CLKDM_CAN_ENABLE_AUTO flag enabled. If CLKDM_CAN_ENABLE_AUTO is
>> set then the omap_pm_clkdms_setup() function will place the CD into
>> HW_AUTO regardless of CLKDM_CAN_DISABLE_AUTO, and the next time the
>> hwmod _enable() is called it is in the HW_AUTO state and so it is
>> allowed to idle. This is not what we want. Do you agree?
>>
>> If I set CLKDM_CAN_DISABLE_AUTO flag and disable CLKDM_CAN_ENABLE_AUTO,
>> then I do not have the above problem.
>>
>> To be honest, with you the more I look and test the code, the more
>> confused I am by the definition of the CLKDM_CAN_HWSUP ...
>>
>> #define CLKDM_CAN_HWSUP	(CLKDM_CAN_ENABLE_AUTO | CLKDM_CAN_DISABLE_AUTO)
>>
>> When I look at where these flags are used, I see that
>> CLKDM_CAN_ENABLE_AUTO is used in clkdm_allow_idle and
>> CLKDM_CAN_DISABLE_AUTO is used in clkdm_deny_idle. So this implies that ...
>>
>> CLKDM_CAN_ENABLE_AUTO = Supports HW_AUTO state when CD is active
>> CLKDM_CAN_DISABLE_AUTO = Does NOT supports HW_AUTO state when CD is active
>>
>> Are the above the correct definitions?
> 
> Not quite.
> 
> These flags describe the capabilities as defined in CLKTRCTRL field of
> the CLKSTCTRL register (e.g. CM_EMU_CLKSTCTRL)
> 
> CLKDM_CAN_ENABLE_AUTO: IP supports HW_AUTO state (and it can be enabled)
> CLKDM_CAN_DISABLE_AUTO: HW_AUTO feature can be disabled (a.k.a. NO_SLEEP)
> 
> Note that in OMAP4, the latter called NO_SLEEP in the TRM, but in OMAP3
> it's described as "The automatic hardware-supervised mode is disabled"

Yeah, in fact this is the source of the current confusion for my point of view.

We chat about that with Paul some time back.
 
EMU CD does support HW_AUTO and SW_WKUP, so it means that if you want to disable the AUTO mode you can use the SW_WKUP.
Assuming that CLKDM_CAN_DISABLE_AUTO is equivalent to NO_SLEEP is thus not correct. In fact any state != HW_AUTO should be considered a non-automatic mode.
So EMU does support CLKDM_CAN_ENABLE_AUTO, CLKDM_CAN_DISABLE_AUTO and CLKDM_CAN_FORCE_WAKEUP.

But the way it is implemented does not really allow that, because disable hwsup imply setting state to OMAP34XX_CLKSTCTRL_DISABLE_AUTO.

void omap4_cminst_clkdm_disable_hwsup(u8 part, s16 inst, u16 cdoffs)
{
        _clktrctrl_write(OMAP34XX_CLKSTCTRL_DISABLE_AUTO, part, inst, cdoffs);
}

So if we want to allow that, some code change are needed in order to set the clkdm mode to OMAP34XX_CLKSTCTRL_FORCE_WAKEUP if OMAP34XX_CLKSTCTRL_DISABLE_AUTO is not supported.

> What is confusing to me is that the OMAP4 TRM doesn't list the NO_SLEEP
> mode as supported by the EMU.   It seems to me that if the IP supports
> HW_AUTO, it should be able to be enabled *and* disabled.

No, not really, this is mostly OMAP3 legacy, and we do have plan to remove these useless modes going forward. We can effectively disable AUTO mode by going to FORCE_WAKEUP.

- 0x0 NO_SLEEP A clock domain sleep transition is never initiated, irrespective of the hardware conditions.
- 0x1 SW_SLEEP A software-forced sleep transition. The transition is initiated when the associated hardware conditions are satisfied
- 0x2 SW_WKUP A software-forced clock domain wake-up transition is initiated, irrespective of the hardware conditions.
- 0x3 HW_AUTO Hardware-controlled automatic sleep and wake-up transition is initiated by the PRCM module when the associated hardware conditions are satisfied


On OMAP4, SW_SLEEP is equivalent to ENABLE_AUTO and 
NO_SLEEP is equivalent to SW_WKUP. There are some slight differences inside the HW, but in term of functionality this is mostly equivalent.


Bottom-line, if we fix the omap4_cminst_clkdm_disable_hwsup, we can consider that the EMU CD does support CLKDM_CAN_ENABLE_AUTO, CLKDM_CAN_DISABLE_AUTO and CLKDM_CAN_FORCE_WAKEUP, which is equivalent to CLKDM_CAN_HWSUP | CLKDM_CAN_FORCE_WAKEUP.


Regards,
Benoit

oprofile and ARM A9 hardware counter

[Cousson, Benoit]

Hi Kevin and Jon,

On 5/8/2012 11:22 PM, Kevin Hilman wrote:
> Jon Hunter<jon-hunter@ti.com>  writes:
> 
>> Hi Benoit,
>>
>> On 05/08/2012 06:01 AM, Cousson, Benoit wrote:
>>
>> [...]
>>
>>>>>> P.S. Please note there is also already a different fix in mainline for
>>>>>> the EMU clkdm data from Paul which adds the force wakeup flag and
>>>>>> removes the DISABLE_AUTO flag[1] (but leaves the ENABLE_AUTO flag,
>>>>>> because the hardware is capable.)
>>>>>
>>>>> Hmmm ... yes saw this, and you will have to excuse me as I don't fully
>>>>> follow the logic here. In fact, I am thinking we want the opposite ;-)
>>>>>
>>>>>   From looking, into this it seems to me that when PMU is running we want
>>>>> the EMU clock domain in software-wakeup state and when PMU is not
>>>>> running we want in the hardware auto state.
>>>>
>>>> So far, I'm with you.
>>>>
>>>>> By keeping the ENABLE_AUTO flag set, as soon as we enable the clock
>>>>> domain it is put right back into the HW_AUTO state
>>>>
>>>> This is only because it was in the HWSUP state when _enable was called.
>>>> If clkdm_deny_idle() is used, that behavior will change.
>>>>
>>>>> and hence PMU is
>>>>> not working (see _enable() function in
>>>>> arch/arm/mach-omap2/omap_hwmod.c)
>>>>>
>>>>> So really what I think we want is to remove the ENABLE_AUTO flag to keep
>>>>> the clock domain in software wake-up and use the DISABLE_AUTO flag to
>>>>> put the clock domain back in HW_AUTO (note this requires a patch to
>>>>> perform this 2nd part).
>>>>
>>>> Well, Paul will have to comment here for the final word, but IIUC, the
>>>> hwmod flags are supposed to indicate only what the HW is capable of.  If
>>>> we want to change the runtime behavior, we nee to use (or add) APIs to
>>>> change the beahvior.  In this case, clkdm_allow_idle(),
>>>> clkdm_deny_idle() are probably what is needed here.
>>>
>>> Yes, indeed, we should not hack the flags to fix that kind of issue. The
>>> flags describe what the HW is capable of, and the EMU CD can support
>>> HW_AUTO and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the
>>> only valid next power state is OFF, meaning that no retention mode is
>>> supported. So any transition to idle will go to OFF and lead to a reset
>>> upon wakeup.
>>
>> No hacking intended here, just getting the flags correct ;-)
>>
>> So let me start from the beginning ...
>>
>> 1. I agree that for the EMU CD that the valid HW states are HW_AUTO and
>> SW_WKUP.
>>
>> 2. When the EMU CD is active (due to something like PMU), we want to
>> keep the CD in the SW_WKUP state, otherwise we can automatically
>> transition to idle and reset the IP (at least for omap4430).
> 
>> 3. When the EMU CD is inactive, we want to keep the CD in the HW_AUTO
>> state because SW_SLEEP is NOT supported.
>>
>> In the current code, we have the CLKDM_CAN_DISABLE_AUTO flag disabled
>> and the CLKDM_CAN_ENABLE_AUTO flag enabled. If CLKDM_CAN_ENABLE_AUTO is
>> set then the omap_pm_clkdms_setup() function will place the CD into
>> HW_AUTO regardless of CLKDM_CAN_DISABLE_AUTO, and the next time the
>> hwmod _enable() is called it is in the HW_AUTO state and so it is
>> allowed to idle. This is not what we want. Do you agree?
>>
>> If I set CLKDM_CAN_DISABLE_AUTO flag and disable CLKDM_CAN_ENABLE_AUTO,
>> then I do not have the above problem.
>>
>> To be honest, with you the more I look and test the code, the more
>> confused I am by the definition of the CLKDM_CAN_HWSUP ...
>>
>> #define CLKDM_CAN_HWSUP	(CLKDM_CAN_ENABLE_AUTO | CLKDM_CAN_DISABLE_AUTO)
>>
>> When I look at where these flags are used, I see that
>> CLKDM_CAN_ENABLE_AUTO is used in clkdm_allow_idle and
>> CLKDM_CAN_DISABLE_AUTO is used in clkdm_deny_idle. So this implies that ...
>>
>> CLKDM_CAN_ENABLE_AUTO = Supports HW_AUTO state when CD is active
>> CLKDM_CAN_DISABLE_AUTO = Does NOT supports HW_AUTO state when CD is active
>>
>> Are the above the correct definitions?
> 
> Not quite.
> 
> These flags describe the capabilities as defined in CLKTRCTRL field of
> the CLKSTCTRL register (e.g. CM_EMU_CLKSTCTRL)
> 
> CLKDM_CAN_ENABLE_AUTO: IP supports HW_AUTO state (and it can be enabled)
> CLKDM_CAN_DISABLE_AUTO: HW_AUTO feature can be disabled (a.k.a. NO_SLEEP)
> 
> Note that in OMAP4, the latter called NO_SLEEP in the TRM, but in OMAP3
> it's described as "The automatic hardware-supervised mode is disabled"

Yeah, in fact this is the source of the current confusion for my point of view.

We chat about that with Paul some time back.
 
EMU CD does support HW_AUTO and SW_WKUP, so it means that if you want to disable the AUTO mode you can use the SW_WKUP.
Assuming that CLKDM_CAN_DISABLE_AUTO is equivalent to NO_SLEEP is thus not correct. In fact any state != HW_AUTO should be considered a non-automatic mode.
So EMU does support CLKDM_CAN_ENABLE_AUTO, CLKDM_CAN_DISABLE_AUTO and CLKDM_CAN_FORCE_WAKEUP.

But the way it is implemented does not really allow that, because disable hwsup imply setting state to OMAP34XX_CLKSTCTRL_DISABLE_AUTO.

void omap4_cminst_clkdm_disable_hwsup(u8 part, s16 inst, u16 cdoffs)
{
        _clktrctrl_write(OMAP34XX_CLKSTCTRL_DISABLE_AUTO, part, inst, cdoffs);
}

So if we want to allow that, some code change are needed in order to set the clkdm mode to OMAP34XX_CLKSTCTRL_FORCE_WAKEUP if OMAP34XX_CLKSTCTRL_DISABLE_AUTO is not supported.

> What is confusing to me is that the OMAP4 TRM doesn't list the NO_SLEEP
> mode as supported by the EMU.   It seems to me that if the IP supports
> HW_AUTO, it should be able to be enabled *and* disabled.

No, not really, this is mostly OMAP3 legacy, and we do have plan to remove these useless modes going forward. We can effectively disable AUTO mode by going to FORCE_WAKEUP.

- 0x0 NO_SLEEP A clock domain sleep transition is never initiated, irrespective of the hardware conditions.
- 0x1 SW_SLEEP A software-forced sleep transition. The transition is initiated when the associated hardware conditions are satisfied
- 0x2 SW_WKUP A software-forced clock domain wake-up transition is initiated, irrespective of the hardware conditions.
- 0x3 HW_AUTO Hardware-controlled automatic sleep and wake-up transition is initiated by the PRCM module when the associated hardware conditions are satisfied


On OMAP4, SW_SLEEP is equivalent to ENABLE_AUTO and 
NO_SLEEP is equivalent to SW_WKUP. There are some slight differences inside the HW, but in term of functionality this is mostly equivalent.


Bottom-line, if we fix the omap4_cminst_clkdm_disable_hwsup, we can consider that the EMU CD does support CLKDM_CAN_ENABLE_AUTO, CLKDM_CAN_DISABLE_AUTO and CLKDM_CAN_FORCE_WAKEUP, which is equivalent to CLKDM_CAN_HWSUP | CLKDM_CAN_FORCE_WAKEUP.


Regards,
Benoit

Re: oprofile and ARM A9 hardware counter

[Jon Hunter]

Hi Benoit,

On 05/09/2012 05:58 AM, Cousson, Benoit wrote:
> Hi Kevin and Jon,
> 
> On 5/8/2012 11:22 PM, Kevin Hilman wrote:
>> Jon Hunter<jon-hunter@ti.com>  writes:
>>
>>> Hi Benoit,
>>>
>>> On 05/08/2012 06:01 AM, Cousson, Benoit wrote:
>>>
>>> [...]
>>>
>>>>>>> P.S. Please note there is also already a different fix in mainline for
>>>>>>> the EMU clkdm data from Paul which adds the force wakeup flag and
>>>>>>> removes the DISABLE_AUTO flag[1] (but leaves the ENABLE_AUTO flag,
>>>>>>> because the hardware is capable.)
>>>>>>
>>>>>> Hmmm ... yes saw this, and you will have to excuse me as I don't fully
>>>>>> follow the logic here. In fact, I am thinking we want the opposite ;-)
>>>>>>
>>>>>>   From looking, into this it seems to me that when PMU is running we want
>>>>>> the EMU clock domain in software-wakeup state and when PMU is not
>>>>>> running we want in the hardware auto state.
>>>>>
>>>>> So far, I'm with you.
>>>>>
>>>>>> By keeping the ENABLE_AUTO flag set, as soon as we enable the clock
>>>>>> domain it is put right back into the HW_AUTO state
>>>>>
>>>>> This is only because it was in the HWSUP state when _enable was called.
>>>>> If clkdm_deny_idle() is used, that behavior will change.
>>>>>
>>>>>> and hence PMU is
>>>>>> not working (see _enable() function in
>>>>>> arch/arm/mach-omap2/omap_hwmod.c)
>>>>>>
>>>>>> So really what I think we want is to remove the ENABLE_AUTO flag to keep
>>>>>> the clock domain in software wake-up and use the DISABLE_AUTO flag to
>>>>>> put the clock domain back in HW_AUTO (note this requires a patch to
>>>>>> perform this 2nd part).
>>>>>
>>>>> Well, Paul will have to comment here for the final word, but IIUC, the
>>>>> hwmod flags are supposed to indicate only what the HW is capable of.  If
>>>>> we want to change the runtime behavior, we nee to use (or add) APIs to
>>>>> change the beahvior.  In this case, clkdm_allow_idle(),
>>>>> clkdm_deny_idle() are probably what is needed here.
>>>>
>>>> Yes, indeed, we should not hack the flags to fix that kind of issue. The
>>>> flags describe what the HW is capable of, and the EMU CD can support
>>>> HW_AUTO and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the
>>>> only valid next power state is OFF, meaning that no retention mode is
>>>> supported. So any transition to idle will go to OFF and lead to a reset
>>>> upon wakeup.
>>>
>>> No hacking intended here, just getting the flags correct ;-)
>>>
>>> So let me start from the beginning ...
>>>
>>> 1. I agree that for the EMU CD that the valid HW states are HW_AUTO and
>>> SW_WKUP.
>>>
>>> 2. When the EMU CD is active (due to something like PMU), we want to
>>> keep the CD in the SW_WKUP state, otherwise we can automatically
>>> transition to idle and reset the IP (at least for omap4430).
>>
>>> 3. When the EMU CD is inactive, we want to keep the CD in the HW_AUTO
>>> state because SW_SLEEP is NOT supported.
>>>
>>> In the current code, we have the CLKDM_CAN_DISABLE_AUTO flag disabled
>>> and the CLKDM_CAN_ENABLE_AUTO flag enabled. If CLKDM_CAN_ENABLE_AUTO is
>>> set then the omap_pm_clkdms_setup() function will place the CD into
>>> HW_AUTO regardless of CLKDM_CAN_DISABLE_AUTO, and the next time the
>>> hwmod _enable() is called it is in the HW_AUTO state and so it is
>>> allowed to idle. This is not what we want. Do you agree?
>>>
>>> If I set CLKDM_CAN_DISABLE_AUTO flag and disable CLKDM_CAN_ENABLE_AUTO,
>>> then I do not have the above problem.
>>>
>>> To be honest, with you the more I look and test the code, the more
>>> confused I am by the definition of the CLKDM_CAN_HWSUP ...
>>>
>>> #define CLKDM_CAN_HWSUP	(CLKDM_CAN_ENABLE_AUTO | CLKDM_CAN_DISABLE_AUTO)
>>>
>>> When I look at where these flags are used, I see that
>>> CLKDM_CAN_ENABLE_AUTO is used in clkdm_allow_idle and
>>> CLKDM_CAN_DISABLE_AUTO is used in clkdm_deny_idle. So this implies that ...
>>>
>>> CLKDM_CAN_ENABLE_AUTO = Supports HW_AUTO state when CD is active
>>> CLKDM_CAN_DISABLE_AUTO = Does NOT supports HW_AUTO state when CD is active
>>>
>>> Are the above the correct definitions?
>>
>> Not quite.
>>
>> These flags describe the capabilities as defined in CLKTRCTRL field of
>> the CLKSTCTRL register (e.g. CM_EMU_CLKSTCTRL)
>>
>> CLKDM_CAN_ENABLE_AUTO: IP supports HW_AUTO state (and it can be enabled)
>> CLKDM_CAN_DISABLE_AUTO: HW_AUTO feature can be disabled (a.k.a. NO_SLEEP)
>>
>> Note that in OMAP4, the latter called NO_SLEEP in the TRM, but in OMAP3
>> it's described as "The automatic hardware-supervised mode is disabled"
> 
> Yeah, in fact this is the source of the current confusion for my point of view.
> 
> We chat about that with Paul some time back.
>  
> EMU CD does support HW_AUTO and SW_WKUP, so it means that if you want to disable the AUTO mode you can use the SW_WKUP.
> Assuming that CLKDM_CAN_DISABLE_AUTO is equivalent to NO_SLEEP is thus not correct. In fact any state != HW_AUTO should be considered a non-automatic mode.
> So EMU does support CLKDM_CAN_ENABLE_AUTO, CLKDM_CAN_DISABLE_AUTO and CLKDM_CAN_FORCE_WAKEUP.
> 
> But the way it is implemented does not really allow that, because disable hwsup imply setting state to OMAP34XX_CLKSTCTRL_DISABLE_AUTO.
> 
> void omap4_cminst_clkdm_disable_hwsup(u8 part, s16 inst, u16 cdoffs)
> {
>         _clktrctrl_write(OMAP34XX_CLKSTCTRL_DISABLE_AUTO, part, inst, cdoffs);
> }
> 
> So if we want to allow that, some code change are needed in order to set the clkdm mode to OMAP34XX_CLKSTCTRL_FORCE_WAKEUP if OMAP34XX_CLKSTCTRL_DISABLE_AUTO is not supported.
> 
>> What is confusing to me is that the OMAP4 TRM doesn't list the NO_SLEEP
>> mode as supported by the EMU.   It seems to me that if the IP supports
>> HW_AUTO, it should be able to be enabled *and* disabled.
> 
> No, not really, this is mostly OMAP3 legacy, and we do have plan to remove these useless modes going forward. We can effectively disable AUTO mode by going to FORCE_WAKEUP.
> 
> - 0x0 NO_SLEEP A clock domain sleep transition is never initiated, irrespective of the hardware conditions.
> - 0x1 SW_SLEEP A software-forced sleep transition. The transition is initiated when the associated hardware conditions are satisfied
> - 0x2 SW_WKUP A software-forced clock domain wake-up transition is initiated, irrespective of the hardware conditions.
> - 0x3 HW_AUTO Hardware-controlled automatic sleep and wake-up transition is initiated by the PRCM module when the associated hardware conditions are satisfied
> 
> 
> On OMAP4, SW_SLEEP is equivalent to ENABLE_AUTO and 
> NO_SLEEP is equivalent to SW_WKUP. There are some slight differences inside the HW, but in term of functionality this is mostly equivalent.
> 
> 
> Bottom-line, if we fix the omap4_cminst_clkdm_disable_hwsup, we can consider that the EMU CD does support CLKDM_CAN_ENABLE_AUTO, CLKDM_CAN_DISABLE_AUTO and CLKDM_CAN_FORCE_WAKEUP, which is equivalent to CLKDM_CAN_HWSUP | CLKDM_CAN_FORCE_WAKEUP.

Per our discussion and just to re-iterate here for OMAP4+ devices, we
should have ...

CAN_DISABLE_AUTO 	--> SW_WKUP
CAN_ENABLE_AUTO		--> HW_AUTO
CAN_FORCE_WAKEUP	--> SW_WKUP
CAN_FORCE_SLEEP		--> HW_AUTO

Hence, the NO_SLEEP and SW_SLEEP should not be used for OMAP4+ (per the
equivalents highlighted above). At least that is the current theory :-)

Please note that for the EMU power domain, although HW_AUTO and SW_WKUP
are the supported modes, even with the above definitions we still do not
want to enable CAN_ENABLE_AUTO for this CD as the _enable() will place
the CD in HW_AUTO after it has been woken up. So for the EMU CD we would
just want CAN_SWSUP (based on the above). This works so far.

By the way, given this new proposed mapping of flags to modes, I am
still wondering if we should take this a step further and change the
flag names completely :-o

For example, for CDs I see there being (at least) 3 states that we care
about and these are ...

1. The wake-up mode - CDs should be placed in SW_WKUP mode for all
   OMAP devices.
2. The on mode - CDs could be placed in NO_SLEEP (OMAP2/3 only)
   SW_WKUP (eg. OMAP4 EMU CD) or HW_AUTO mode
3. The off mode - CDs could be place in the HW_AUTO or SW_SLEEP
   (OMAP2/3 only) mode.

Note that it is possible for on and off modes to be the same (ie.
HW_AUTO). Given the above states, we should only care about how the CD
is programmed for each state versus what modes the CD actually supports.
Therefore, we could create the following flags ...

CLKDM_WAKEUP_MODE
CLKDM_ON_MODE_NO_SLEEP
CLKDM_ON_MODE_SW_WAKEUP
CLKDM_ON_MODE_HW_AUTO
CLKDM_OFF_MODE_SW_SLEEP
CLKDM_OFF_MODE_HW_AUTO

This would obviously be a bigger change, but I am wondering if this
could simplify the logic and be less confusing? Just a thought ...

Cheers
Jon

oprofile and ARM A9 hardware counter

[Jon Hunter]

Hi Benoit,

On 05/09/2012 05:58 AM, Cousson, Benoit wrote:
> Hi Kevin and Jon,
> 
> On 5/8/2012 11:22 PM, Kevin Hilman wrote:
>> Jon Hunter<jon-hunter@ti.com>  writes:
>>
>>> Hi Benoit,
>>>
>>> On 05/08/2012 06:01 AM, Cousson, Benoit wrote:
>>>
>>> [...]
>>>
>>>>>>> P.S. Please note there is also already a different fix in mainline for
>>>>>>> the EMU clkdm data from Paul which adds the force wakeup flag and
>>>>>>> removes the DISABLE_AUTO flag[1] (but leaves the ENABLE_AUTO flag,
>>>>>>> because the hardware is capable.)
>>>>>>
>>>>>> Hmmm ... yes saw this, and you will have to excuse me as I don't fully
>>>>>> follow the logic here. In fact, I am thinking we want the opposite ;-)
>>>>>>
>>>>>>   From looking, into this it seems to me that when PMU is running we want
>>>>>> the EMU clock domain in software-wakeup state and when PMU is not
>>>>>> running we want in the hardware auto state.
>>>>>
>>>>> So far, I'm with you.
>>>>>
>>>>>> By keeping the ENABLE_AUTO flag set, as soon as we enable the clock
>>>>>> domain it is put right back into the HW_AUTO state
>>>>>
>>>>> This is only because it was in the HWSUP state when _enable was called.
>>>>> If clkdm_deny_idle() is used, that behavior will change.
>>>>>
>>>>>> and hence PMU is
>>>>>> not working (see _enable() function in
>>>>>> arch/arm/mach-omap2/omap_hwmod.c)
>>>>>>
>>>>>> So really what I think we want is to remove the ENABLE_AUTO flag to keep
>>>>>> the clock domain in software wake-up and use the DISABLE_AUTO flag to
>>>>>> put the clock domain back in HW_AUTO (note this requires a patch to
>>>>>> perform this 2nd part).
>>>>>
>>>>> Well, Paul will have to comment here for the final word, but IIUC, the
>>>>> hwmod flags are supposed to indicate only what the HW is capable of.  If
>>>>> we want to change the runtime behavior, we nee to use (or add) APIs to
>>>>> change the beahvior.  In this case, clkdm_allow_idle(),
>>>>> clkdm_deny_idle() are probably what is needed here.
>>>>
>>>> Yes, indeed, we should not hack the flags to fix that kind of issue. The
>>>> flags describe what the HW is capable of, and the EMU CD can support
>>>> HW_AUTO and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the
>>>> only valid next power state is OFF, meaning that no retention mode is
>>>> supported. So any transition to idle will go to OFF and lead to a reset
>>>> upon wakeup.
>>>
>>> No hacking intended here, just getting the flags correct ;-)
>>>
>>> So let me start from the beginning ...
>>>
>>> 1. I agree that for the EMU CD that the valid HW states are HW_AUTO and
>>> SW_WKUP.
>>>
>>> 2. When the EMU CD is active (due to something like PMU), we want to
>>> keep the CD in the SW_WKUP state, otherwise we can automatically
>>> transition to idle and reset the IP (at least for omap4430).
>>
>>> 3. When the EMU CD is inactive, we want to keep the CD in the HW_AUTO
>>> state because SW_SLEEP is NOT supported.
>>>
>>> In the current code, we have the CLKDM_CAN_DISABLE_AUTO flag disabled
>>> and the CLKDM_CAN_ENABLE_AUTO flag enabled. If CLKDM_CAN_ENABLE_AUTO is
>>> set then the omap_pm_clkdms_setup() function will place the CD into
>>> HW_AUTO regardless of CLKDM_CAN_DISABLE_AUTO, and the next time the
>>> hwmod _enable() is called it is in the HW_AUTO state and so it is
>>> allowed to idle. This is not what we want. Do you agree?
>>>
>>> If I set CLKDM_CAN_DISABLE_AUTO flag and disable CLKDM_CAN_ENABLE_AUTO,
>>> then I do not have the above problem.
>>>
>>> To be honest, with you the more I look and test the code, the more
>>> confused I am by the definition of the CLKDM_CAN_HWSUP ...
>>>
>>> #define CLKDM_CAN_HWSUP	(CLKDM_CAN_ENABLE_AUTO | CLKDM_CAN_DISABLE_AUTO)
>>>
>>> When I look at where these flags are used, I see that
>>> CLKDM_CAN_ENABLE_AUTO is used in clkdm_allow_idle and
>>> CLKDM_CAN_DISABLE_AUTO is used in clkdm_deny_idle. So this implies that ...
>>>
>>> CLKDM_CAN_ENABLE_AUTO = Supports HW_AUTO state when CD is active
>>> CLKDM_CAN_DISABLE_AUTO = Does NOT supports HW_AUTO state when CD is active
>>>
>>> Are the above the correct definitions?
>>
>> Not quite.
>>
>> These flags describe the capabilities as defined in CLKTRCTRL field of
>> the CLKSTCTRL register (e.g. CM_EMU_CLKSTCTRL)
>>
>> CLKDM_CAN_ENABLE_AUTO: IP supports HW_AUTO state (and it can be enabled)
>> CLKDM_CAN_DISABLE_AUTO: HW_AUTO feature can be disabled (a.k.a. NO_SLEEP)
>>
>> Note that in OMAP4, the latter called NO_SLEEP in the TRM, but in OMAP3
>> it's described as "The automatic hardware-supervised mode is disabled"
> 
> Yeah, in fact this is the source of the current confusion for my point of view.
> 
> We chat about that with Paul some time back.
>  
> EMU CD does support HW_AUTO and SW_WKUP, so it means that if you want to disable the AUTO mode you can use the SW_WKUP.
> Assuming that CLKDM_CAN_DISABLE_AUTO is equivalent to NO_SLEEP is thus not correct. In fact any state != HW_AUTO should be considered a non-automatic mode.
> So EMU does support CLKDM_CAN_ENABLE_AUTO, CLKDM_CAN_DISABLE_AUTO and CLKDM_CAN_FORCE_WAKEUP.
> 
> But the way it is implemented does not really allow that, because disable hwsup imply setting state to OMAP34XX_CLKSTCTRL_DISABLE_AUTO.
> 
> void omap4_cminst_clkdm_disable_hwsup(u8 part, s16 inst, u16 cdoffs)
> {
>         _clktrctrl_write(OMAP34XX_CLKSTCTRL_DISABLE_AUTO, part, inst, cdoffs);
> }
> 
> So if we want to allow that, some code change are needed in order to set the clkdm mode to OMAP34XX_CLKSTCTRL_FORCE_WAKEUP if OMAP34XX_CLKSTCTRL_DISABLE_AUTO is not supported.
> 
>> What is confusing to me is that the OMAP4 TRM doesn't list the NO_SLEEP
>> mode as supported by the EMU.   It seems to me that if the IP supports
>> HW_AUTO, it should be able to be enabled *and* disabled.
> 
> No, not really, this is mostly OMAP3 legacy, and we do have plan to remove these useless modes going forward. We can effectively disable AUTO mode by going to FORCE_WAKEUP.
> 
> - 0x0 NO_SLEEP A clock domain sleep transition is never initiated, irrespective of the hardware conditions.
> - 0x1 SW_SLEEP A software-forced sleep transition. The transition is initiated when the associated hardware conditions are satisfied
> - 0x2 SW_WKUP A software-forced clock domain wake-up transition is initiated, irrespective of the hardware conditions.
> - 0x3 HW_AUTO Hardware-controlled automatic sleep and wake-up transition is initiated by the PRCM module when the associated hardware conditions are satisfied
> 
> 
> On OMAP4, SW_SLEEP is equivalent to ENABLE_AUTO and 
> NO_SLEEP is equivalent to SW_WKUP. There are some slight differences inside the HW, but in term of functionality this is mostly equivalent.
> 
> 
> Bottom-line, if we fix the omap4_cminst_clkdm_disable_hwsup, we can consider that the EMU CD does support CLKDM_CAN_ENABLE_AUTO, CLKDM_CAN_DISABLE_AUTO and CLKDM_CAN_FORCE_WAKEUP, which is equivalent to CLKDM_CAN_HWSUP | CLKDM_CAN_FORCE_WAKEUP.

Per our discussion and just to re-iterate here for OMAP4+ devices, we
should have ...

CAN_DISABLE_AUTO 	--> SW_WKUP
CAN_ENABLE_AUTO		--> HW_AUTO
CAN_FORCE_WAKEUP	--> SW_WKUP
CAN_FORCE_SLEEP		--> HW_AUTO

Hence, the NO_SLEEP and SW_SLEEP should not be used for OMAP4+ (per the
equivalents highlighted above). At least that is the current theory :-)

Please note that for the EMU power domain, although HW_AUTO and SW_WKUP
are the supported modes, even with the above definitions we still do not
want to enable CAN_ENABLE_AUTO for this CD as the _enable() will place
the CD in HW_AUTO after it has been woken up. So for the EMU CD we would
just want CAN_SWSUP (based on the above). This works so far.

By the way, given this new proposed mapping of flags to modes, I am
still wondering if we should take this a step further and change the
flag names completely :-o

For example, for CDs I see there being (at least) 3 states that we care
about and these are ...

1. The wake-up mode - CDs should be placed in SW_WKUP mode for all
   OMAP devices.
2. The on mode - CDs could be placed in NO_SLEEP (OMAP2/3 only)
   SW_WKUP (eg. OMAP4 EMU CD) or HW_AUTO mode
3. The off mode - CDs could be place in the HW_AUTO or SW_SLEEP
   (OMAP2/3 only) mode.

Note that it is possible for on and off modes to be the same (ie.
HW_AUTO). Given the above states, we should only care about how the CD
is programmed for each state versus what modes the CD actually supports.
Therefore, we could create the following flags ...

CLKDM_WAKEUP_MODE
CLKDM_ON_MODE_NO_SLEEP
CLKDM_ON_MODE_SW_WAKEUP
CLKDM_ON_MODE_HW_AUTO
CLKDM_OFF_MODE_SW_SLEEP
CLKDM_OFF_MODE_HW_AUTO

This would obviously be a bigger change, but I am wondering if this
could simplify the logic and be less confusing? Just a thought ...

Cheers
Jon

Re: oprofile and ARM A9 hardware counter

[Jon Hunter]

On 05/09/2012 01:04 PM, Jon Hunter wrote:
> Hi Benoit,
> 
> On 05/09/2012 05:58 AM, Cousson, Benoit wrote:
>> Hi Kevin and Jon,
>>
>> On 5/8/2012 11:22 PM, Kevin Hilman wrote:
>>> Jon Hunter<jon-hunter@ti.com>  writes:
>>>
>>>> Hi Benoit,
>>>>
>>>> On 05/08/2012 06:01 AM, Cousson, Benoit wrote:
>>>>
>>>> [...]
>>>>
>>>>>>>> P.S. Please note there is also already a different fix in mainline for
>>>>>>>> the EMU clkdm data from Paul which adds the force wakeup flag and
>>>>>>>> removes the DISABLE_AUTO flag[1] (but leaves the ENABLE_AUTO flag,
>>>>>>>> because the hardware is capable.)
>>>>>>>
>>>>>>> Hmmm ... yes saw this, and you will have to excuse me as I don't fully
>>>>>>> follow the logic here. In fact, I am thinking we want the opposite ;-)
>>>>>>>
>>>>>>>   From looking, into this it seems to me that when PMU is running we want
>>>>>>> the EMU clock domain in software-wakeup state and when PMU is not
>>>>>>> running we want in the hardware auto state.
>>>>>>
>>>>>> So far, I'm with you.
>>>>>>
>>>>>>> By keeping the ENABLE_AUTO flag set, as soon as we enable the clock
>>>>>>> domain it is put right back into the HW_AUTO state
>>>>>>
>>>>>> This is only because it was in the HWSUP state when _enable was called.
>>>>>> If clkdm_deny_idle() is used, that behavior will change.
>>>>>>
>>>>>>> and hence PMU is
>>>>>>> not working (see _enable() function in
>>>>>>> arch/arm/mach-omap2/omap_hwmod.c)
>>>>>>>
>>>>>>> So really what I think we want is to remove the ENABLE_AUTO flag to keep
>>>>>>> the clock domain in software wake-up and use the DISABLE_AUTO flag to
>>>>>>> put the clock domain back in HW_AUTO (note this requires a patch to
>>>>>>> perform this 2nd part).
>>>>>>
>>>>>> Well, Paul will have to comment here for the final word, but IIUC, the
>>>>>> hwmod flags are supposed to indicate only what the HW is capable of.  If
>>>>>> we want to change the runtime behavior, we nee to use (or add) APIs to
>>>>>> change the beahvior.  In this case, clkdm_allow_idle(),
>>>>>> clkdm_deny_idle() are probably what is needed here.
>>>>>
>>>>> Yes, indeed, we should not hack the flags to fix that kind of issue. The
>>>>> flags describe what the HW is capable of, and the EMU CD can support
>>>>> HW_AUTO and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the
>>>>> only valid next power state is OFF, meaning that no retention mode is
>>>>> supported. So any transition to idle will go to OFF and lead to a reset
>>>>> upon wakeup.
>>>>
>>>> No hacking intended here, just getting the flags correct ;-)
>>>>
>>>> So let me start from the beginning ...
>>>>
>>>> 1. I agree that for the EMU CD that the valid HW states are HW_AUTO and
>>>> SW_WKUP.
>>>>
>>>> 2. When the EMU CD is active (due to something like PMU), we want to
>>>> keep the CD in the SW_WKUP state, otherwise we can automatically
>>>> transition to idle and reset the IP (at least for omap4430).
>>>
>>>> 3. When the EMU CD is inactive, we want to keep the CD in the HW_AUTO
>>>> state because SW_SLEEP is NOT supported.
>>>>
>>>> In the current code, we have the CLKDM_CAN_DISABLE_AUTO flag disabled
>>>> and the CLKDM_CAN_ENABLE_AUTO flag enabled. If CLKDM_CAN_ENABLE_AUTO is
>>>> set then the omap_pm_clkdms_setup() function will place the CD into
>>>> HW_AUTO regardless of CLKDM_CAN_DISABLE_AUTO, and the next time the
>>>> hwmod _enable() is called it is in the HW_AUTO state and so it is
>>>> allowed to idle. This is not what we want. Do you agree?
>>>>
>>>> If I set CLKDM_CAN_DISABLE_AUTO flag and disable CLKDM_CAN_ENABLE_AUTO,
>>>> then I do not have the above problem.
>>>>
>>>> To be honest, with you the more I look and test the code, the more
>>>> confused I am by the definition of the CLKDM_CAN_HWSUP ...
>>>>
>>>> #define CLKDM_CAN_HWSUP	(CLKDM_CAN_ENABLE_AUTO | CLKDM_CAN_DISABLE_AUTO)
>>>>
>>>> When I look at where these flags are used, I see that
>>>> CLKDM_CAN_ENABLE_AUTO is used in clkdm_allow_idle and
>>>> CLKDM_CAN_DISABLE_AUTO is used in clkdm_deny_idle. So this implies that ...
>>>>
>>>> CLKDM_CAN_ENABLE_AUTO = Supports HW_AUTO state when CD is active
>>>> CLKDM_CAN_DISABLE_AUTO = Does NOT supports HW_AUTO state when CD is active
>>>>
>>>> Are the above the correct definitions?
>>>
>>> Not quite.
>>>
>>> These flags describe the capabilities as defined in CLKTRCTRL field of
>>> the CLKSTCTRL register (e.g. CM_EMU_CLKSTCTRL)
>>>
>>> CLKDM_CAN_ENABLE_AUTO: IP supports HW_AUTO state (and it can be enabled)
>>> CLKDM_CAN_DISABLE_AUTO: HW_AUTO feature can be disabled (a.k.a. NO_SLEEP)
>>>
>>> Note that in OMAP4, the latter called NO_SLEEP in the TRM, but in OMAP3
>>> it's described as "The automatic hardware-supervised mode is disabled"
>>
>> Yeah, in fact this is the source of the current confusion for my point of view.
>>
>> We chat about that with Paul some time back.
>>  
>> EMU CD does support HW_AUTO and SW_WKUP, so it means that if you want to disable the AUTO mode you can use the SW_WKUP.
>> Assuming that CLKDM_CAN_DISABLE_AUTO is equivalent to NO_SLEEP is thus not correct. In fact any state != HW_AUTO should be considered a non-automatic mode.
>> So EMU does support CLKDM_CAN_ENABLE_AUTO, CLKDM_CAN_DISABLE_AUTO and CLKDM_CAN_FORCE_WAKEUP.
>>
>> But the way it is implemented does not really allow that, because disable hwsup imply setting state to OMAP34XX_CLKSTCTRL_DISABLE_AUTO.
>>
>> void omap4_cminst_clkdm_disable_hwsup(u8 part, s16 inst, u16 cdoffs)
>> {
>>         _clktrctrl_write(OMAP34XX_CLKSTCTRL_DISABLE_AUTO, part, inst, cdoffs);
>> }
>>
>> So if we want to allow that, some code change are needed in order to set the clkdm mode to OMAP34XX_CLKSTCTRL_FORCE_WAKEUP if OMAP34XX_CLKSTCTRL_DISABLE_AUTO is not supported.
>>
>>> What is confusing to me is that the OMAP4 TRM doesn't list the NO_SLEEP
>>> mode as supported by the EMU.   It seems to me that if the IP supports
>>> HW_AUTO, it should be able to be enabled *and* disabled.
>>
>> No, not really, this is mostly OMAP3 legacy, and we do have plan to remove these useless modes going forward. We can effectively disable AUTO mode by going to FORCE_WAKEUP.
>>
>> - 0x0 NO_SLEEP A clock domain sleep transition is never initiated, irrespective of the hardware conditions.
>> - 0x1 SW_SLEEP A software-forced sleep transition. The transition is initiated when the associated hardware conditions are satisfied
>> - 0x2 SW_WKUP A software-forced clock domain wake-up transition is initiated, irrespective of the hardware conditions.
>> - 0x3 HW_AUTO Hardware-controlled automatic sleep and wake-up transition is initiated by the PRCM module when the associated hardware conditions are satisfied
>>
>>
>> On OMAP4, SW_SLEEP is equivalent to ENABLE_AUTO and 
>> NO_SLEEP is equivalent to SW_WKUP. There are some slight differences inside the HW, but in term of functionality this is mostly equivalent.
>>
>>
>> Bottom-line, if we fix the omap4_cminst_clkdm_disable_hwsup, we can consider that the EMU CD does support CLKDM_CAN_ENABLE_AUTO, CLKDM_CAN_DISABLE_AUTO and CLKDM_CAN_FORCE_WAKEUP, which is equivalent to CLKDM_CAN_HWSUP | CLKDM_CAN_FORCE_WAKEUP.
> 
> Per our discussion and just to re-iterate here for OMAP4+ devices, we
> should have ...
> 
> CAN_DISABLE_AUTO 	--> SW_WKUP
> CAN_ENABLE_AUTO		--> HW_AUTO
> CAN_FORCE_WAKEUP	--> SW_WKUP
> CAN_FORCE_SLEEP		--> HW_AUTO
> 
> Hence, the NO_SLEEP and SW_SLEEP should not be used for OMAP4+ (per the
> equivalents highlighted above). At least that is the current theory :-)

I realise now the the l4cfg CD does not support SW_WKUP and so I guess
we still need NO_SLEEP in that case. So that would break the above
mapping and we would have to handle it in software.

Jon

oprofile and ARM A9 hardware counter

[Jon Hunter]

On 05/09/2012 01:04 PM, Jon Hunter wrote:
> Hi Benoit,
> 
> On 05/09/2012 05:58 AM, Cousson, Benoit wrote:
>> Hi Kevin and Jon,
>>
>> On 5/8/2012 11:22 PM, Kevin Hilman wrote:
>>> Jon Hunter<jon-hunter@ti.com>  writes:
>>>
>>>> Hi Benoit,
>>>>
>>>> On 05/08/2012 06:01 AM, Cousson, Benoit wrote:
>>>>
>>>> [...]
>>>>
>>>>>>>> P.S. Please note there is also already a different fix in mainline for
>>>>>>>> the EMU clkdm data from Paul which adds the force wakeup flag and
>>>>>>>> removes the DISABLE_AUTO flag[1] (but leaves the ENABLE_AUTO flag,
>>>>>>>> because the hardware is capable.)
>>>>>>>
>>>>>>> Hmmm ... yes saw this, and you will have to excuse me as I don't fully
>>>>>>> follow the logic here. In fact, I am thinking we want the opposite ;-)
>>>>>>>
>>>>>>>   From looking, into this it seems to me that when PMU is running we want
>>>>>>> the EMU clock domain in software-wakeup state and when PMU is not
>>>>>>> running we want in the hardware auto state.
>>>>>>
>>>>>> So far, I'm with you.
>>>>>>
>>>>>>> By keeping the ENABLE_AUTO flag set, as soon as we enable the clock
>>>>>>> domain it is put right back into the HW_AUTO state
>>>>>>
>>>>>> This is only because it was in the HWSUP state when _enable was called.
>>>>>> If clkdm_deny_idle() is used, that behavior will change.
>>>>>>
>>>>>>> and hence PMU is
>>>>>>> not working (see _enable() function in
>>>>>>> arch/arm/mach-omap2/omap_hwmod.c)
>>>>>>>
>>>>>>> So really what I think we want is to remove the ENABLE_AUTO flag to keep
>>>>>>> the clock domain in software wake-up and use the DISABLE_AUTO flag to
>>>>>>> put the clock domain back in HW_AUTO (note this requires a patch to
>>>>>>> perform this 2nd part).
>>>>>>
>>>>>> Well, Paul will have to comment here for the final word, but IIUC, the
>>>>>> hwmod flags are supposed to indicate only what the HW is capable of.  If
>>>>>> we want to change the runtime behavior, we nee to use (or add) APIs to
>>>>>> change the beahvior.  In this case, clkdm_allow_idle(),
>>>>>> clkdm_deny_idle() are probably what is needed here.
>>>>>
>>>>> Yes, indeed, we should not hack the flags to fix that kind of issue. The
>>>>> flags describe what the HW is capable of, and the EMU CD can support
>>>>> HW_AUTO and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the
>>>>> only valid next power state is OFF, meaning that no retention mode is
>>>>> supported. So any transition to idle will go to OFF and lead to a reset
>>>>> upon wakeup.
>>>>
>>>> No hacking intended here, just getting the flags correct ;-)
>>>>
>>>> So let me start from the beginning ...
>>>>
>>>> 1. I agree that for the EMU CD that the valid HW states are HW_AUTO and
>>>> SW_WKUP.
>>>>
>>>> 2. When the EMU CD is active (due to something like PMU), we want to
>>>> keep the CD in the SW_WKUP state, otherwise we can automatically
>>>> transition to idle and reset the IP (at least for omap4430).
>>>
>>>> 3. When the EMU CD is inactive, we want to keep the CD in the HW_AUTO
>>>> state because SW_SLEEP is NOT supported.
>>>>
>>>> In the current code, we have the CLKDM_CAN_DISABLE_AUTO flag disabled
>>>> and the CLKDM_CAN_ENABLE_AUTO flag enabled. If CLKDM_CAN_ENABLE_AUTO is
>>>> set then the omap_pm_clkdms_setup() function will place the CD into
>>>> HW_AUTO regardless of CLKDM_CAN_DISABLE_AUTO, and the next time the
>>>> hwmod _enable() is called it is in the HW_AUTO state and so it is
>>>> allowed to idle. This is not what we want. Do you agree?
>>>>
>>>> If I set CLKDM_CAN_DISABLE_AUTO flag and disable CLKDM_CAN_ENABLE_AUTO,
>>>> then I do not have the above problem.
>>>>
>>>> To be honest, with you the more I look and test the code, the more
>>>> confused I am by the definition of the CLKDM_CAN_HWSUP ...
>>>>
>>>> #define CLKDM_CAN_HWSUP	(CLKDM_CAN_ENABLE_AUTO | CLKDM_CAN_DISABLE_AUTO)
>>>>
>>>> When I look at where these flags are used, I see that
>>>> CLKDM_CAN_ENABLE_AUTO is used in clkdm_allow_idle and
>>>> CLKDM_CAN_DISABLE_AUTO is used in clkdm_deny_idle. So this implies that ...
>>>>
>>>> CLKDM_CAN_ENABLE_AUTO = Supports HW_AUTO state when CD is active
>>>> CLKDM_CAN_DISABLE_AUTO = Does NOT supports HW_AUTO state when CD is active
>>>>
>>>> Are the above the correct definitions?
>>>
>>> Not quite.
>>>
>>> These flags describe the capabilities as defined in CLKTRCTRL field of
>>> the CLKSTCTRL register (e.g. CM_EMU_CLKSTCTRL)
>>>
>>> CLKDM_CAN_ENABLE_AUTO: IP supports HW_AUTO state (and it can be enabled)
>>> CLKDM_CAN_DISABLE_AUTO: HW_AUTO feature can be disabled (a.k.a. NO_SLEEP)
>>>
>>> Note that in OMAP4, the latter called NO_SLEEP in the TRM, but in OMAP3
>>> it's described as "The automatic hardware-supervised mode is disabled"
>>
>> Yeah, in fact this is the source of the current confusion for my point of view.
>>
>> We chat about that with Paul some time back.
>>  
>> EMU CD does support HW_AUTO and SW_WKUP, so it means that if you want to disable the AUTO mode you can use the SW_WKUP.
>> Assuming that CLKDM_CAN_DISABLE_AUTO is equivalent to NO_SLEEP is thus not correct. In fact any state != HW_AUTO should be considered a non-automatic mode.
>> So EMU does support CLKDM_CAN_ENABLE_AUTO, CLKDM_CAN_DISABLE_AUTO and CLKDM_CAN_FORCE_WAKEUP.
>>
>> But the way it is implemented does not really allow that, because disable hwsup imply setting state to OMAP34XX_CLKSTCTRL_DISABLE_AUTO.
>>
>> void omap4_cminst_clkdm_disable_hwsup(u8 part, s16 inst, u16 cdoffs)
>> {
>>         _clktrctrl_write(OMAP34XX_CLKSTCTRL_DISABLE_AUTO, part, inst, cdoffs);
>> }
>>
>> So if we want to allow that, some code change are needed in order to set the clkdm mode to OMAP34XX_CLKSTCTRL_FORCE_WAKEUP if OMAP34XX_CLKSTCTRL_DISABLE_AUTO is not supported.
>>
>>> What is confusing to me is that the OMAP4 TRM doesn't list the NO_SLEEP
>>> mode as supported by the EMU.   It seems to me that if the IP supports
>>> HW_AUTO, it should be able to be enabled *and* disabled.
>>
>> No, not really, this is mostly OMAP3 legacy, and we do have plan to remove these useless modes going forward. We can effectively disable AUTO mode by going to FORCE_WAKEUP.
>>
>> - 0x0 NO_SLEEP A clock domain sleep transition is never initiated, irrespective of the hardware conditions.
>> - 0x1 SW_SLEEP A software-forced sleep transition. The transition is initiated when the associated hardware conditions are satisfied
>> - 0x2 SW_WKUP A software-forced clock domain wake-up transition is initiated, irrespective of the hardware conditions.
>> - 0x3 HW_AUTO Hardware-controlled automatic sleep and wake-up transition is initiated by the PRCM module when the associated hardware conditions are satisfied
>>
>>
>> On OMAP4, SW_SLEEP is equivalent to ENABLE_AUTO and 
>> NO_SLEEP is equivalent to SW_WKUP. There are some slight differences inside the HW, but in term of functionality this is mostly equivalent.
>>
>>
>> Bottom-line, if we fix the omap4_cminst_clkdm_disable_hwsup, we can consider that the EMU CD does support CLKDM_CAN_ENABLE_AUTO, CLKDM_CAN_DISABLE_AUTO and CLKDM_CAN_FORCE_WAKEUP, which is equivalent to CLKDM_CAN_HWSUP | CLKDM_CAN_FORCE_WAKEUP.
> 
> Per our discussion and just to re-iterate here for OMAP4+ devices, we
> should have ...
> 
> CAN_DISABLE_AUTO 	--> SW_WKUP
> CAN_ENABLE_AUTO		--> HW_AUTO
> CAN_FORCE_WAKEUP	--> SW_WKUP
> CAN_FORCE_SLEEP		--> HW_AUTO
> 
> Hence, the NO_SLEEP and SW_SLEEP should not be used for OMAP4+ (per the
> equivalents highlighted above). At least that is the current theory :-)

I realise now the the l4cfg CD does not support SW_WKUP and so I guess
we still need NO_SLEEP in that case. So that would break the above
mapping and we would have to handle it in software.

Jon

Re: oprofile and ARM A9 hardware counter

[Jon Hunter]

Hi All,

On 05/09/2012 02:28 PM, Jon Hunter wrote:

[...]

>>>>> No hacking intended here, just getting the flags correct ;-)
>>>>>
>>>>> So let me start from the beginning ...
>>>>>
>>>>> 1. I agree that for the EMU CD that the valid HW states are HW_AUTO and
>>>>> SW_WKUP.
>>>>>
>>>>> 2. When the EMU CD is active (due to something like PMU), we want to
>>>>> keep the CD in the SW_WKUP state, otherwise we can automatically
>>>>> transition to idle and reset the IP (at least for omap4430).
>>>>
>>>>> 3. When the EMU CD is inactive, we want to keep the CD in the HW_AUTO
>>>>> state because SW_SLEEP is NOT supported.
>>>>>
>>>>> In the current code, we have the CLKDM_CAN_DISABLE_AUTO flag disabled
>>>>> and the CLKDM_CAN_ENABLE_AUTO flag enabled. If CLKDM_CAN_ENABLE_AUTO is
>>>>> set then the omap_pm_clkdms_setup() function will place the CD into
>>>>> HW_AUTO regardless of CLKDM_CAN_DISABLE_AUTO, and the next time the
>>>>> hwmod _enable() is called it is in the HW_AUTO state and so it is
>>>>> allowed to idle. This is not what we want. Do you agree?
>>>>>
>>>>> If I set CLKDM_CAN_DISABLE_AUTO flag and disable CLKDM_CAN_ENABLE_AUTO,
>>>>> then I do not have the above problem.
>>>>>
>>>>> To be honest, with you the more I look and test the code, the more
>>>>> confused I am by the definition of the CLKDM_CAN_HWSUP ...
>>>>>
>>>>> #define CLKDM_CAN_HWSUP	(CLKDM_CAN_ENABLE_AUTO | CLKDM_CAN_DISABLE_AUTO)
>>>>>
>>>>> When I look at where these flags are used, I see that
>>>>> CLKDM_CAN_ENABLE_AUTO is used in clkdm_allow_idle and
>>>>> CLKDM_CAN_DISABLE_AUTO is used in clkdm_deny_idle. So this implies that ...
>>>>>
>>>>> CLKDM_CAN_ENABLE_AUTO = Supports HW_AUTO state when CD is active
>>>>> CLKDM_CAN_DISABLE_AUTO = Does NOT supports HW_AUTO state when CD is active
>>>>>
>>>>> Are the above the correct definitions?
>>>>
>>>> Not quite.
>>>>
>>>> These flags describe the capabilities as defined in CLKTRCTRL field of
>>>> the CLKSTCTRL register (e.g. CM_EMU_CLKSTCTRL)
>>>>
>>>> CLKDM_CAN_ENABLE_AUTO: IP supports HW_AUTO state (and it can be enabled)
>>>> CLKDM_CAN_DISABLE_AUTO: HW_AUTO feature can be disabled (a.k.a. NO_SLEEP)
>>>>
>>>> Note that in OMAP4, the latter called NO_SLEEP in the TRM, but in OMAP3
>>>> it's described as "The automatic hardware-supervised mode is disabled"
>>>
>>> Yeah, in fact this is the source of the current confusion for my point of view.
>>>
>>> We chat about that with Paul some time back.
>>>  
>>> EMU CD does support HW_AUTO and SW_WKUP, so it means that if you want to disable the AUTO mode you can use the SW_WKUP.
>>> Assuming that CLKDM_CAN_DISABLE_AUTO is equivalent to NO_SLEEP is thus not correct. In fact any state != HW_AUTO should be considered a non-automatic mode.
>>> So EMU does support CLKDM_CAN_ENABLE_AUTO, CLKDM_CAN_DISABLE_AUTO and CLKDM_CAN_FORCE_WAKEUP.
>>>
>>> But the way it is implemented does not really allow that, because disable hwsup imply setting state to OMAP34XX_CLKSTCTRL_DISABLE_AUTO.
>>>
>>> void omap4_cminst_clkdm_disable_hwsup(u8 part, s16 inst, u16 cdoffs)
>>> {
>>>         _clktrctrl_write(OMAP34XX_CLKSTCTRL_DISABLE_AUTO, part, inst, cdoffs);
>>> }
>>>
>>> So if we want to allow that, some code change are needed in order to set the clkdm mode to OMAP34XX_CLKSTCTRL_FORCE_WAKEUP if OMAP34XX_CLKSTCTRL_DISABLE_AUTO is not supported.
>>>
>>>> What is confusing to me is that the OMAP4 TRM doesn't list the NO_SLEEP
>>>> mode as supported by the EMU.   It seems to me that if the IP supports
>>>> HW_AUTO, it should be able to be enabled *and* disabled.
>>>
>>> No, not really, this is mostly OMAP3 legacy, and we do have plan to remove these useless modes going forward. We can effectively disable AUTO mode by going to FORCE_WAKEUP.
>>>
>>> - 0x0 NO_SLEEP A clock domain sleep transition is never initiated, irrespective of the hardware conditions.
>>> - 0x1 SW_SLEEP A software-forced sleep transition. The transition is initiated when the associated hardware conditions are satisfied
>>> - 0x2 SW_WKUP A software-forced clock domain wake-up transition is initiated, irrespective of the hardware conditions.
>>> - 0x3 HW_AUTO Hardware-controlled automatic sleep and wake-up transition is initiated by the PRCM module when the associated hardware conditions are satisfied
>>>
>>>
>>> On OMAP4, SW_SLEEP is equivalent to ENABLE_AUTO and 
>>> NO_SLEEP is equivalent to SW_WKUP. There are some slight differences inside the HW, but in term of functionality this is mostly equivalent.
>>>
>>>
>>> Bottom-line, if we fix the omap4_cminst_clkdm_disable_hwsup, we can consider that the EMU CD does support CLKDM_CAN_ENABLE_AUTO, CLKDM_CAN_DISABLE_AUTO and CLKDM_CAN_FORCE_WAKEUP, which is equivalent to CLKDM_CAN_HWSUP | CLKDM_CAN_FORCE_WAKEUP.
>>
>> Per our discussion and just to re-iterate here for OMAP4+ devices, we
>> should have ...
>>
>> CAN_DISABLE_AUTO 	--> SW_WKUP
>> CAN_ENABLE_AUTO		--> HW_AUTO
>> CAN_FORCE_WAKEUP	--> SW_WKUP
>> CAN_FORCE_SLEEP		--> HW_AUTO
>>
>> Hence, the NO_SLEEP and SW_SLEEP should not be used for OMAP4+ (per the
>> equivalents highlighted above). At least that is the current theory :-)
> 
> I realise now the the l4cfg CD does not support SW_WKUP and so I guess
> we still need NO_SLEEP in that case. So that would break the above
> mapping and we would have to handle it in software.

I have posted my latest series here [1] based upon that from Will [2]
which attempts to fix the EMU CD based upon the inputs from this thread.
It is working on my omap4460 panda. Hopefully Ming and/or Will can also
test. I know that Ming is out this week but said he can test next week.

Cheers
Jon

[1] http://marc.info/?l=linux-omap&m=133659938028348&w=2
[2] git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git perf/omap4

oprofile and ARM A9 hardware counter

[Jon Hunter]

Hi All,

On 05/09/2012 02:28 PM, Jon Hunter wrote:

[...]

>>>>> No hacking intended here, just getting the flags correct ;-)
>>>>>
>>>>> So let me start from the beginning ...
>>>>>
>>>>> 1. I agree that for the EMU CD that the valid HW states are HW_AUTO and
>>>>> SW_WKUP.
>>>>>
>>>>> 2. When the EMU CD is active (due to something like PMU), we want to
>>>>> keep the CD in the SW_WKUP state, otherwise we can automatically
>>>>> transition to idle and reset the IP (at least for omap4430).
>>>>
>>>>> 3. When the EMU CD is inactive, we want to keep the CD in the HW_AUTO
>>>>> state because SW_SLEEP is NOT supported.
>>>>>
>>>>> In the current code, we have the CLKDM_CAN_DISABLE_AUTO flag disabled
>>>>> and the CLKDM_CAN_ENABLE_AUTO flag enabled. If CLKDM_CAN_ENABLE_AUTO is
>>>>> set then the omap_pm_clkdms_setup() function will place the CD into
>>>>> HW_AUTO regardless of CLKDM_CAN_DISABLE_AUTO, and the next time the
>>>>> hwmod _enable() is called it is in the HW_AUTO state and so it is
>>>>> allowed to idle. This is not what we want. Do you agree?
>>>>>
>>>>> If I set CLKDM_CAN_DISABLE_AUTO flag and disable CLKDM_CAN_ENABLE_AUTO,
>>>>> then I do not have the above problem.
>>>>>
>>>>> To be honest, with you the more I look and test the code, the more
>>>>> confused I am by the definition of the CLKDM_CAN_HWSUP ...
>>>>>
>>>>> #define CLKDM_CAN_HWSUP	(CLKDM_CAN_ENABLE_AUTO | CLKDM_CAN_DISABLE_AUTO)
>>>>>
>>>>> When I look at where these flags are used, I see that
>>>>> CLKDM_CAN_ENABLE_AUTO is used in clkdm_allow_idle and
>>>>> CLKDM_CAN_DISABLE_AUTO is used in clkdm_deny_idle. So this implies that ...
>>>>>
>>>>> CLKDM_CAN_ENABLE_AUTO = Supports HW_AUTO state when CD is active
>>>>> CLKDM_CAN_DISABLE_AUTO = Does NOT supports HW_AUTO state when CD is active
>>>>>
>>>>> Are the above the correct definitions?
>>>>
>>>> Not quite.
>>>>
>>>> These flags describe the capabilities as defined in CLKTRCTRL field of
>>>> the CLKSTCTRL register (e.g. CM_EMU_CLKSTCTRL)
>>>>
>>>> CLKDM_CAN_ENABLE_AUTO: IP supports HW_AUTO state (and it can be enabled)
>>>> CLKDM_CAN_DISABLE_AUTO: HW_AUTO feature can be disabled (a.k.a. NO_SLEEP)
>>>>
>>>> Note that in OMAP4, the latter called NO_SLEEP in the TRM, but in OMAP3
>>>> it's described as "The automatic hardware-supervised mode is disabled"
>>>
>>> Yeah, in fact this is the source of the current confusion for my point of view.
>>>
>>> We chat about that with Paul some time back.
>>>  
>>> EMU CD does support HW_AUTO and SW_WKUP, so it means that if you want to disable the AUTO mode you can use the SW_WKUP.
>>> Assuming that CLKDM_CAN_DISABLE_AUTO is equivalent to NO_SLEEP is thus not correct. In fact any state != HW_AUTO should be considered a non-automatic mode.
>>> So EMU does support CLKDM_CAN_ENABLE_AUTO, CLKDM_CAN_DISABLE_AUTO and CLKDM_CAN_FORCE_WAKEUP.
>>>
>>> But the way it is implemented does not really allow that, because disable hwsup imply setting state to OMAP34XX_CLKSTCTRL_DISABLE_AUTO.
>>>
>>> void omap4_cminst_clkdm_disable_hwsup(u8 part, s16 inst, u16 cdoffs)
>>> {
>>>         _clktrctrl_write(OMAP34XX_CLKSTCTRL_DISABLE_AUTO, part, inst, cdoffs);
>>> }
>>>
>>> So if we want to allow that, some code change are needed in order to set the clkdm mode to OMAP34XX_CLKSTCTRL_FORCE_WAKEUP if OMAP34XX_CLKSTCTRL_DISABLE_AUTO is not supported.
>>>
>>>> What is confusing to me is that the OMAP4 TRM doesn't list the NO_SLEEP
>>>> mode as supported by the EMU.   It seems to me that if the IP supports
>>>> HW_AUTO, it should be able to be enabled *and* disabled.
>>>
>>> No, not really, this is mostly OMAP3 legacy, and we do have plan to remove these useless modes going forward. We can effectively disable AUTO mode by going to FORCE_WAKEUP.
>>>
>>> - 0x0 NO_SLEEP A clock domain sleep transition is never initiated, irrespective of the hardware conditions.
>>> - 0x1 SW_SLEEP A software-forced sleep transition. The transition is initiated when the associated hardware conditions are satisfied
>>> - 0x2 SW_WKUP A software-forced clock domain wake-up transition is initiated, irrespective of the hardware conditions.
>>> - 0x3 HW_AUTO Hardware-controlled automatic sleep and wake-up transition is initiated by the PRCM module when the associated hardware conditions are satisfied
>>>
>>>
>>> On OMAP4, SW_SLEEP is equivalent to ENABLE_AUTO and 
>>> NO_SLEEP is equivalent to SW_WKUP. There are some slight differences inside the HW, but in term of functionality this is mostly equivalent.
>>>
>>>
>>> Bottom-line, if we fix the omap4_cminst_clkdm_disable_hwsup, we can consider that the EMU CD does support CLKDM_CAN_ENABLE_AUTO, CLKDM_CAN_DISABLE_AUTO and CLKDM_CAN_FORCE_WAKEUP, which is equivalent to CLKDM_CAN_HWSUP | CLKDM_CAN_FORCE_WAKEUP.
>>
>> Per our discussion and just to re-iterate here for OMAP4+ devices, we
>> should have ...
>>
>> CAN_DISABLE_AUTO 	--> SW_WKUP
>> CAN_ENABLE_AUTO		--> HW_AUTO
>> CAN_FORCE_WAKEUP	--> SW_WKUP
>> CAN_FORCE_SLEEP		--> HW_AUTO
>>
>> Hence, the NO_SLEEP and SW_SLEEP should not be used for OMAP4+ (per the
>> equivalents highlighted above). At least that is the current theory :-)
> 
> I realise now the the l4cfg CD does not support SW_WKUP and so I guess
> we still need NO_SLEEP in that case. So that would break the above
> mapping and we would have to handle it in software.

I have posted my latest series here [1] based upon that from Will [2]
which attempts to fix the EMU CD based upon the inputs from this thread.
It is working on my omap4460 panda. Hopefully Ming and/or Will can also
test. I know that Ming is out this week but said he can test next week.

Cheers
Jon

[1] http://marc.info/?l=linux-omap&m=133659938028348&w=2
[2] git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git perf/omap4

Re: oprofile and ARM A9 hardware counter

[Will Deacon]

On Wed, May 09, 2012 at 10:45:08PM +0100, Jon Hunter wrote:
> Hi All,

Hi Jon,

> I have posted my latest series here [1] based upon that from Will [2]
> which attempts to fix the EMU CD based upon the inputs from this thread.
> It is working on my omap4460 panda. Hopefully Ming and/or Will can also
> test. I know that Ming is out this week but said he can test next week.

Many thanks to you (+Kevin, Benoit, Paul and co) for persevering with this.
If I can get my hands on a Panda, I'll see if I can test something this
week. Any particular tests you want me to run to exercise the interaction
with PM?

Cheers,

Will

oprofile and ARM A9 hardware counter

[Will Deacon]

On Wed, May 09, 2012 at 10:45:08PM +0100, Jon Hunter wrote:
> Hi All,

Hi Jon,

> I have posted my latest series here [1] based upon that from Will [2]
> which attempts to fix the EMU CD based upon the inputs from this thread.
> It is working on my omap4460 panda. Hopefully Ming and/or Will can also
> test. I know that Ming is out this week but said he can test next week.

Many thanks to you (+Kevin, Benoit, Paul and co) for persevering with this.
If I can get my hands on a Panda, I'll see if I can test something this
week. Any particular tests you want me to run to exercise the interaction
with PM?

Cheers,

Will

Re: oprofile and ARM A9 hardware counter

[stephane eranian]

On Thu, May 10, 2012 at 10:44 AM, Will Deacon <will.deacon@arm.com> wrote:
> On Wed, May 09, 2012 at 10:45:08PM +0100, Jon Hunter wrote:
>> Hi All,
>
> Hi Jon,
>
>> I have posted my latest series here [1] based upon that from Will [2]
>> which attempts to fix the EMU CD based upon the inputs from this thread.
>> It is working on my omap4460 panda. Hopefully Ming and/or Will can also
>> test. I know that Ming is out this week but said he can test next week.
>
> Many thanks to you (+Kevin, Benoit, Paul and co) for persevering with this.
> If I can get my hands on a Panda, I'll see if I can test something this
> week. Any particular tests you want me to run to exercise the interaction
> with PM?
>
> Cheers,
>
I would like to get the final patch (on top of Ming's) so I can test this on
my Panda board too. Thanks.

> Will

oprofile and ARM A9 hardware counter

[stephane eranian]

On Thu, May 10, 2012 at 10:44 AM, Will Deacon <will.deacon@arm.com> wrote:
> On Wed, May 09, 2012 at 10:45:08PM +0100, Jon Hunter wrote:
>> Hi All,
>
> Hi Jon,
>
>> I have posted my latest series here [1] based upon that from Will [2]
>> which attempts to fix the EMU CD based upon the inputs from this thread.
>> It is working on my omap4460 panda. Hopefully Ming and/or Will can also
>> test. I know that Ming is out this week but said he can test next week.
>
> Many thanks to you (+Kevin, Benoit, Paul and co) for persevering with this.
> If I can get my hands on a Panda, I'll see if I can test something this
> week. Any particular tests you want me to run to exercise the interaction
> with PM?
>
> Cheers,
>
I would like to get the final patch (on top of Ming's) so I can test this on
my Panda board too. Thanks.

> Will

Re: oprofile and ARM A9 hardware counter

[Jon Hunter]

Hi Will,

On 05/10/2012 03:44 AM, Will Deacon wrote:
> On Wed, May 09, 2012 at 10:45:08PM +0100, Jon Hunter wrote:
>> Hi All,
> 
> Hi Jon,
> 
>> I have posted my latest series here [1] based upon that from Will [2]
>> which attempts to fix the EMU CD based upon the inputs from this thread.
>> It is working on my omap4460 panda. Hopefully Ming and/or Will can also
>> test. I know that Ming is out this week but said he can test next week.
> 
> Many thanks to you (+Kevin, Benoit, Paul and co) for persevering with this.
> If I can get my hands on a Panda, I'll see if I can test something this
> week. Any particular tests you want me to run to exercise the interaction
> with PM?

May be Kevin and Paul have some suggestions, but I am not sure what PM modes are currently supported for OMAP4 in the linux-omap master branch.

For my testing I have just been reading the PM_EMU_PWRSTST register which shows the power state of the EMU power domain. It should read 3 when the power domain is ON and 0 when it is off. I did something like the following (dumping all EMU clock and power domain registers).

Cheers
Jon

diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index b02aa81..41cb2fa 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -437,8 +437,25 @@ static struct omap_device_pm_latency omap_pmu_latency[] = {
 static struct cti omap4_cti[2];
 static struct platform_device *pmu_dev;
 
+static inline void dump_emu(char *s, int d)
+{
+       pr_info("%s-%d: CM_EMU_CLKSTCTRL = 0x%x\n", s, d,
+               __raw_readl(OMAP2_L4_IO_ADDRESS(0x4A307A00)));
+       pr_info("%s-%d: CM_EMU_DYNAMICDEP = 0x%x\n", s, d,
+               __raw_readl(OMAP2_L4_IO_ADDRESS(0x4A307A08)));
+       pr_info("%s-%d: CM_EMU_DEBUGSS_CLKCTRL = 0x%x\n", s, d,
+               __raw_readl(OMAP2_L4_IO_ADDRESS(0x4A307A20)));
+       pr_info("%s-%d: PM_EMU_PWRSTCTRL = 0x%x\n", s, d,
+               __raw_readl(OMAP2_L4_IO_ADDRESS(0x4A307900)));
+       pr_info("%s-%d: PM_EMU_PWRSTST = 0x%x\n", s, d,
+               __raw_readl(OMAP2_L4_IO_ADDRESS(0x4A307904)));
+       pr_info("%s-%d: RM_EMU_DEBUGSS_CONTEXT = 0x%x\n", s, d,
+               __raw_readl(OMAP2_L4_IO_ADDRESS(0x4A307924)));
+
+}
 static void omap4_enable_cti(int irq)
 {
+       dump_emu((char *)__func__, __LINE__);
        pm_runtime_get_sync(&pmu_dev->dev);
        if (irq == OMAP44XX_IRQ_CTI0) {
                /* configure CTI0 for pmu irq routing */
@@ -451,15 +468,18 @@ static void omap4_enable_cti(int irq)
                cti_map_trigger(&omap4_cti[1], 1, 6, 2);
                cti_enable(&omap4_cti[1]);
        }
+       dump_emu((char *)__func__, __LINE__);
 }
 
 static void omap4_disable_cti(int irq)
 {
+       dump_emu((char *)__func__, __LINE__);
        if (irq == OMAP44XX_IRQ_CTI0)
                cti_disable(&omap4_cti[0]);
        else if (irq == OMAP44XX_IRQ_CTI1)
                cti_disable(&omap4_cti[1]);
        pm_runtime_put(&pmu_dev->dev);
+       dump_emu((char *)__func__, __LINE__);
 }

oprofile and ARM A9 hardware counter

[Jon Hunter]

Hi Will,

On 05/10/2012 03:44 AM, Will Deacon wrote:
> On Wed, May 09, 2012 at 10:45:08PM +0100, Jon Hunter wrote:
>> Hi All,
> 
> Hi Jon,
> 
>> I have posted my latest series here [1] based upon that from Will [2]
>> which attempts to fix the EMU CD based upon the inputs from this thread.
>> It is working on my omap4460 panda. Hopefully Ming and/or Will can also
>> test. I know that Ming is out this week but said he can test next week.
> 
> Many thanks to you (+Kevin, Benoit, Paul and co) for persevering with this.
> If I can get my hands on a Panda, I'll see if I can test something this
> week. Any particular tests you want me to run to exercise the interaction
> with PM?

May be Kevin and Paul have some suggestions, but I am not sure what PM modes are currently supported for OMAP4 in the linux-omap master branch.

For my testing I have just been reading the PM_EMU_PWRSTST register which shows the power state of the EMU power domain. It should read 3 when the power domain is ON and 0 when it is off. I did something like the following (dumping all EMU clock and power domain registers).

Cheers
Jon

diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index b02aa81..41cb2fa 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -437,8 +437,25 @@ static struct omap_device_pm_latency omap_pmu_latency[] = {
 static struct cti omap4_cti[2];
 static struct platform_device *pmu_dev;
 
+static inline void dump_emu(char *s, int d)
+{
+       pr_info("%s-%d: CM_EMU_CLKSTCTRL = 0x%x\n", s, d,
+               __raw_readl(OMAP2_L4_IO_ADDRESS(0x4A307A00)));
+       pr_info("%s-%d: CM_EMU_DYNAMICDEP = 0x%x\n", s, d,
+               __raw_readl(OMAP2_L4_IO_ADDRESS(0x4A307A08)));
+       pr_info("%s-%d: CM_EMU_DEBUGSS_CLKCTRL = 0x%x\n", s, d,
+               __raw_readl(OMAP2_L4_IO_ADDRESS(0x4A307A20)));
+       pr_info("%s-%d: PM_EMU_PWRSTCTRL = 0x%x\n", s, d,
+               __raw_readl(OMAP2_L4_IO_ADDRESS(0x4A307900)));
+       pr_info("%s-%d: PM_EMU_PWRSTST = 0x%x\n", s, d,
+               __raw_readl(OMAP2_L4_IO_ADDRESS(0x4A307904)));
+       pr_info("%s-%d: RM_EMU_DEBUGSS_CONTEXT = 0x%x\n", s, d,
+               __raw_readl(OMAP2_L4_IO_ADDRESS(0x4A307924)));
+
+}
 static void omap4_enable_cti(int irq)
 {
+       dump_emu((char *)__func__, __LINE__);
        pm_runtime_get_sync(&pmu_dev->dev);
        if (irq == OMAP44XX_IRQ_CTI0) {
                /* configure CTI0 for pmu irq routing */
@@ -451,15 +468,18 @@ static void omap4_enable_cti(int irq)
                cti_map_trigger(&omap4_cti[1], 1, 6, 2);
                cti_enable(&omap4_cti[1]);
        }
+       dump_emu((char *)__func__, __LINE__);
 }
 
 static void omap4_disable_cti(int irq)
 {
+       dump_emu((char *)__func__, __LINE__);
        if (irq == OMAP44XX_IRQ_CTI0)
                cti_disable(&omap4_cti[0]);
        else if (irq == OMAP44XX_IRQ_CTI1)
                cti_disable(&omap4_cti[1]);
        pm_runtime_put(&pmu_dev->dev);
+       dump_emu((char *)__func__, __LINE__);
 }

Re: oprofile and ARM A9 hardware counter

[Will Deacon]

On Thu, May 10, 2012 at 07:55:01PM +0100, Jon Hunter wrote:
> Hi Will,

Hi Jon,

> For my testing I have just been reading the PM_EMU_PWRSTST register which shows the power state of the EMU power domain. It should read 3 when the power domain is ON and 0 when it is off. I did something like the following (dumping all EMU clock and power domain registers).

I figured I may as well take perf for a spin and see how I got on. The good
news is that the hwmod bits all seem to work as before and the correct IRQs
are requested:

root@florentine-pogen:~# cat /proc/interrupts
           CPU0       CPU1
 29:      44527      17916       GIC  twd
 33:          0          0       GIC  arm-pmu
 34:          0          0       GIC  arm-pmu

But, unfortunately, as you can see from the above, I just can't persuade them
to fire. The PMU counters do tick, but they happily increment through zero
without us realising. I retested with my perf/omap4 branch to make sure my
board is ok, and the irqs do fire there.

Any ideas?

Cheers,

Will

oprofile and ARM A9 hardware counter

[Will Deacon]

On Thu, May 10, 2012 at 07:55:01PM +0100, Jon Hunter wrote:
> Hi Will,

Hi Jon,

> For my testing I have just been reading the PM_EMU_PWRSTST register which shows the power state of the EMU power domain. It should read 3 when the power domain is ON and 0 when it is off. I did something like the following (dumping all EMU clock and power domain registers).

I figured I may as well take perf for a spin and see how I got on. The good
news is that the hwmod bits all seem to work as before and the correct IRQs
are requested:

root at florentine-pogen:~# cat /proc/interrupts
           CPU0       CPU1
 29:      44527      17916       GIC  twd
 33:          0          0       GIC  arm-pmu
 34:          0          0       GIC  arm-pmu

But, unfortunately, as you can see from the above, I just can't persuade them
to fire. The PMU counters do tick, but they happily increment through zero
without us realising. I retested with my perf/omap4 branch to make sure my
board is ok, and the irqs do fire there.

Any ideas?

Cheers,

Will

Re: oprofile and ARM A9 hardware counter

[Jon Hunter]

Hi Will

On 05/11/2012 07:25 AM, Will Deacon wrote:
> On Thu, May 10, 2012 at 07:55:01PM +0100, Jon Hunter wrote:
>> Hi Will,
> 
> Hi Jon,
> 
>> For my testing I have just been reading the PM_EMU_PWRSTST register which shows the power state of the EMU power domain. It should read 3 when the power domain is ON and 0 when it is off. I did something like the following (dumping all EMU clock and power domain registers).
> 
> I figured I may as well take perf for a spin and see how I got on. The good
> news is that the hwmod bits all seem to work as before and the correct IRQs
> are requested:
> 
> root@florentine-pogen:~# cat /proc/interrupts
>            CPU0       CPU1
>  29:      44527      17916       GIC  twd
>  33:          0          0       GIC  arm-pmu
>  34:          0          0       GIC  arm-pmu
> 
> But, unfortunately, as you can see from the above, I just can't persuade them
> to fire. The PMU counters do tick, but they happily increment through zero
> without us realising. I retested with my perf/omap4 branch to make sure my
> board is ok, and the irqs do fire there.
> 
> Any ideas?

Do you disable OMAP2/3 support in the kernel config, so that CPU_HAS_PMU
is enabled?

Cheers
Jon

oprofile and ARM A9 hardware counter

[Jon Hunter]

Hi Will

On 05/11/2012 07:25 AM, Will Deacon wrote:
> On Thu, May 10, 2012 at 07:55:01PM +0100, Jon Hunter wrote:
>> Hi Will,
> 
> Hi Jon,
> 
>> For my testing I have just been reading the PM_EMU_PWRSTST register which shows the power state of the EMU power domain. It should read 3 when the power domain is ON and 0 when it is off. I did something like the following (dumping all EMU clock and power domain registers).
> 
> I figured I may as well take perf for a spin and see how I got on. The good
> news is that the hwmod bits all seem to work as before and the correct IRQs
> are requested:
> 
> root at florentine-pogen:~# cat /proc/interrupts
>            CPU0       CPU1
>  29:      44527      17916       GIC  twd
>  33:          0          0       GIC  arm-pmu
>  34:          0          0       GIC  arm-pmu
> 
> But, unfortunately, as you can see from the above, I just can't persuade them
> to fire. The PMU counters do tick, but they happily increment through zero
> without us realising. I retested with my perf/omap4 branch to make sure my
> board is ok, and the irqs do fire there.
> 
> Any ideas?

Do you disable OMAP2/3 support in the kernel config, so that CPU_HAS_PMU
is enabled?

Cheers
Jon

Re: oprofile and ARM A9 hardware counter

[Will Deacon]

On Fri, May 11, 2012 at 02:47:17PM +0100, Jon Hunter wrote:
> On 05/11/2012 07:25 AM, Will Deacon wrote:
> > I figured I may as well take perf for a spin and see how I got on. The good
> > news is that the hwmod bits all seem to work as before and the correct IRQs
> > are requested:
> > 
> > root@florentine-pogen:~# cat /proc/interrupts
> >            CPU0       CPU1
> >  29:      44527      17916       GIC  twd
> >  33:          0          0       GIC  arm-pmu
> >  34:          0          0       GIC  arm-pmu
> > 
> > But, unfortunately, as you can see from the above, I just can't persuade them
> > to fire. The PMU counters do tick, but they happily increment through zero
> > without us realising. I retested with my perf/omap4 branch to make sure my
> > board is ok, and the irqs do fire there.
> > 
> > Any ideas?
> 
> Do you disable OMAP2/3 support in the kernel config, so that CPU_HAS_PMU
> is enabled?

I enabled OMAP3 debug peripherals, so I selected CPU_HAS_PMU that way.

Will

oprofile and ARM A9 hardware counter

[Will Deacon]

On Fri, May 11, 2012 at 02:47:17PM +0100, Jon Hunter wrote:
> On 05/11/2012 07:25 AM, Will Deacon wrote:
> > I figured I may as well take perf for a spin and see how I got on. The good
> > news is that the hwmod bits all seem to work as before and the correct IRQs
> > are requested:
> > 
> > root at florentine-pogen:~# cat /proc/interrupts
> >            CPU0       CPU1
> >  29:      44527      17916       GIC  twd
> >  33:          0          0       GIC  arm-pmu
> >  34:          0          0       GIC  arm-pmu
> > 
> > But, unfortunately, as you can see from the above, I just can't persuade them
> > to fire. The PMU counters do tick, but they happily increment through zero
> > without us realising. I retested with my perf/omap4 branch to make sure my
> > board is ok, and the irqs do fire there.
> > 
> > Any ideas?
> 
> Do you disable OMAP2/3 support in the kernel config, so that CPU_HAS_PMU
> is enabled?

I enabled OMAP3 debug peripherals, so I selected CPU_HAS_PMU that way.

Will

Re: oprofile and ARM A9 hardware counter

[Jon Hunter]

Hi Will,

On 05/11/2012 08:49 AM, Will Deacon wrote:
> On Fri, May 11, 2012 at 02:47:17PM +0100, Jon Hunter wrote:
>> On 05/11/2012 07:25 AM, Will Deacon wrote:
>>> I figured I may as well take perf for a spin and see how I got on. The good
>>> news is that the hwmod bits all seem to work as before and the correct IRQs
>>> are requested:
>>>
>>> root@florentine-pogen:~# cat /proc/interrupts
>>>            CPU0       CPU1
>>>  29:      44527      17916       GIC  twd
>>>  33:          0          0       GIC  arm-pmu
>>>  34:          0          0       GIC  arm-pmu
>>>
>>> But, unfortunately, as you can see from the above, I just can't persuade them
>>> to fire. The PMU counters do tick, but they happily increment through zero
>>> without us realising. I retested with my perf/omap4 branch to make sure my
>>> board is ok, and the irqs do fire there.
>>>
>>> Any ideas?
>>
>> Do you disable OMAP2/3 support in the kernel config, so that CPU_HAS_PMU
>> is enabled?
> 
> I enabled OMAP3 debug peripherals, so I selected CPU_HAS_PMU that way.

I tried the same (make omap2plus_defconfig and enabled the above
option), and I do see the interrupts firing on both 4430 and 4460...

/ # cat /proc/interrupts
           CPU0       CPU1
 29:       1023        404       GIC  twd
 33:        401          0       GIC  arm-pmu
 34:          0        441       GIC  arm-pmu


What is your kernel commit ID that you applied the patches on top of?

What board are you using? Blaze, panda, etc, and is it 4430 or 4460?

Cheers
Jon

oprofile and ARM A9 hardware counter

[Jon Hunter]

Hi Will,

On 05/11/2012 08:49 AM, Will Deacon wrote:
> On Fri, May 11, 2012 at 02:47:17PM +0100, Jon Hunter wrote:
>> On 05/11/2012 07:25 AM, Will Deacon wrote:
>>> I figured I may as well take perf for a spin and see how I got on. The good
>>> news is that the hwmod bits all seem to work as before and the correct IRQs
>>> are requested:
>>>
>>> root at florentine-pogen:~# cat /proc/interrupts
>>>            CPU0       CPU1
>>>  29:      44527      17916       GIC  twd
>>>  33:          0          0       GIC  arm-pmu
>>>  34:          0          0       GIC  arm-pmu
>>>
>>> But, unfortunately, as you can see from the above, I just can't persuade them
>>> to fire. The PMU counters do tick, but they happily increment through zero
>>> without us realising. I retested with my perf/omap4 branch to make sure my
>>> board is ok, and the irqs do fire there.
>>>
>>> Any ideas?
>>
>> Do you disable OMAP2/3 support in the kernel config, so that CPU_HAS_PMU
>> is enabled?
> 
> I enabled OMAP3 debug peripherals, so I selected CPU_HAS_PMU that way.

I tried the same (make omap2plus_defconfig and enabled the above
option), and I do see the interrupts firing on both 4430 and 4460...

/ # cat /proc/interrupts
           CPU0       CPU1
 29:       1023        404       GIC  twd
 33:        401          0       GIC  arm-pmu
 34:          0        441       GIC  arm-pmu


What is your kernel commit ID that you applied the patches on top of?

What board are you using? Blaze, panda, etc, and is it 4430 or 4460?

Cheers
Jon

Re: oprofile and ARM A9 hardware counter

[Will Deacon]

On Fri, May 11, 2012 at 03:52:59PM +0100, Jon Hunter wrote:
> Hi Will,

Hello,

> On 05/11/2012 08:49 AM, Will Deacon wrote:
> > I enabled OMAP3 debug peripherals, so I selected CPU_HAS_PMU that way.
> 
> I tried the same (make omap2plus_defconfig and enabled the above
> option), and I do see the interrupts firing on both 4430 and 4460...
> 
> / # cat /proc/interrupts
>            CPU0       CPU1
>  29:       1023        404       GIC  twd
>  33:        401          0       GIC  arm-pmu
>  34:          0        441       GIC  arm-pmu

Well, at least it's working for somebody!

> What is your kernel commit ID that you applied the patches on top of?

7cf543bc ("Linux-omap rebuilt: Updated to -rc6, merged in pending branches,
please test"). Is there something else I need too?

> What board are you using? Blaze, panda, etc, and is it 4430 or 4460?

Ye olde Panda 4430. It does work with my perf/omap4 branch though using the
same .config (I can mail it to you separately if you want).

Cheers,

Will

oprofile and ARM A9 hardware counter

[Will Deacon]

On Fri, May 11, 2012 at 03:52:59PM +0100, Jon Hunter wrote:
> Hi Will,

Hello,

> On 05/11/2012 08:49 AM, Will Deacon wrote:
> > I enabled OMAP3 debug peripherals, so I selected CPU_HAS_PMU that way.
> 
> I tried the same (make omap2plus_defconfig and enabled the above
> option), and I do see the interrupts firing on both 4430 and 4460...
> 
> / # cat /proc/interrupts
>            CPU0       CPU1
>  29:       1023        404       GIC  twd
>  33:        401          0       GIC  arm-pmu
>  34:          0        441       GIC  arm-pmu

Well, at least it's working for somebody!

> What is your kernel commit ID that you applied the patches on top of?

7cf543bc ("Linux-omap rebuilt: Updated to -rc6, merged in pending branches,
please test"). Is there something else I need too?

> What board are you using? Blaze, panda, etc, and is it 4430 or 4460?

Ye olde Panda 4430. It does work with my perf/omap4 branch though using the
same .config (I can mail it to you separately if you want).

Cheers,

Will

Re: oprofile and ARM A9 hardware counter

[Jon Hunter]

Hi Will,

On 05/11/2012 10:02 AM, Will Deacon wrote:
> On Fri, May 11, 2012 at 03:52:59PM +0100, Jon Hunter wrote:
>> Hi Will,
> 
> Hello,
> 
>> On 05/11/2012 08:49 AM, Will Deacon wrote:
>>> I enabled OMAP3 debug peripherals, so I selected CPU_HAS_PMU that way.
>>
>> I tried the same (make omap2plus_defconfig and enabled the above
>> option), and I do see the interrupts firing on both 4430 and 4460...
>>
>> / # cat /proc/interrupts
>>            CPU0       CPU1
>>  29:       1023        404       GIC  twd
>>  33:        401          0       GIC  arm-pmu
>>  34:          0        441       GIC  arm-pmu
> 
> Well, at least it's working for somebody!
> 
>> What is your kernel commit ID that you applied the patches on top of?
> 
> 7cf543bc ("Linux-omap rebuilt: Updated to -rc6, merged in pending branches,
> please test"). Is there something else I need too?

Ok, thanks. I was based upon Tony's -rc5. However, I rebased to the same
as you and it is still working for me

Can you send me your .config?

At the same time, maybe just try "make omap2plus_defconfig" and enable
the OMAP3 debug devices config. That's all I am doing.

>> What board are you using? Blaze, panda, etc, and is it 4430 or 4460?
> 
> Ye olde Panda 4430. It does work with my perf/omap4 branch though using the
> same .config (I can mail it to you separately if you want).

Ok, should be fine. The kernel should print the ES version on start-up ...

[    0.000000] OMAP4430 ES2.2

What does yours show?

Cheers
Jon

oprofile and ARM A9 hardware counter

[Jon Hunter]

Hi Will,

On 05/11/2012 10:02 AM, Will Deacon wrote:
> On Fri, May 11, 2012 at 03:52:59PM +0100, Jon Hunter wrote:
>> Hi Will,
> 
> Hello,
> 
>> On 05/11/2012 08:49 AM, Will Deacon wrote:
>>> I enabled OMAP3 debug peripherals, so I selected CPU_HAS_PMU that way.
>>
>> I tried the same (make omap2plus_defconfig and enabled the above
>> option), and I do see the interrupts firing on both 4430 and 4460...
>>
>> / # cat /proc/interrupts
>>            CPU0       CPU1
>>  29:       1023        404       GIC  twd
>>  33:        401          0       GIC  arm-pmu
>>  34:          0        441       GIC  arm-pmu
> 
> Well, at least it's working for somebody!
> 
>> What is your kernel commit ID that you applied the patches on top of?
> 
> 7cf543bc ("Linux-omap rebuilt: Updated to -rc6, merged in pending branches,
> please test"). Is there something else I need too?

Ok, thanks. I was based upon Tony's -rc5. However, I rebased to the same
as you and it is still working for me

Can you send me your .config?

At the same time, maybe just try "make omap2plus_defconfig" and enable
the OMAP3 debug devices config. That's all I am doing.

>> What board are you using? Blaze, panda, etc, and is it 4430 or 4460?
> 
> Ye olde Panda 4430. It does work with my perf/omap4 branch though using the
> same .config (I can mail it to you separately if you want).

Ok, should be fine. The kernel should print the ES version on start-up ...

[    0.000000] OMAP4430 ES2.2

What does yours show?

Cheers
Jon

Re: oprofile and ARM A9 hardware counter

[Will Deacon]

On Fri, May 11, 2012 at 05:31:47PM +0100, Jon Hunter wrote:
> Can you send me your .config?

Sent off-list.

> At the same time, maybe just try "make omap2plus_defconfig" and enable
> the OMAP3 debug devices config. That's all I am doing.

Excellent, that works for me. Once we've worked out the problem with my
.config you can have my tested-by.

Cheers,

Will

oprofile and ARM A9 hardware counter

[Will Deacon]

On Fri, May 11, 2012 at 05:31:47PM +0100, Jon Hunter wrote:
> Can you send me your .config?

Sent off-list.

> At the same time, maybe just try "make omap2plus_defconfig" and enable
> the OMAP3 debug devices config. That's all I am doing.

Excellent, that works for me. Once we've worked out the problem with my
.config you can have my tested-by.

Cheers,

Will

Re: oprofile and ARM A9 hardware counter

[Jon Hunter]

Hi Will,

On 05/11/2012 11:38 AM, Will Deacon wrote:
> On Fri, May 11, 2012 at 05:31:47PM +0100, Jon Hunter wrote:
>> Can you send me your .config?
> 
> Sent off-list.
> 
>> At the same time, maybe just try "make omap2plus_defconfig" and enable
>> the OMAP3 debug devices config. That's all I am doing.
> 
> Excellent, that works for me. Once we've worked out the problem with my
> .config you can have my tested-by.

Great! I have been looking at your .config, but I have not been able to
figure out the problem so far. Do you recall what your config is based
upon? I seems quite different to mine and the omap2plus_defconfig has
not changed much in the last few kernel releases.

Cheers
Jon

oprofile and ARM A9 hardware counter

[Jon Hunter]

Hi Will,

On 05/11/2012 11:38 AM, Will Deacon wrote:
> On Fri, May 11, 2012 at 05:31:47PM +0100, Jon Hunter wrote:
>> Can you send me your .config?
> 
> Sent off-list.
> 
>> At the same time, maybe just try "make omap2plus_defconfig" and enable
>> the OMAP3 debug devices config. That's all I am doing.
> 
> Excellent, that works for me. Once we've worked out the problem with my
> .config you can have my tested-by.

Great! I have been looking at your .config, but I have not been able to
figure out the problem so far. Do you recall what your config is based
upon? I seems quite different to mine and the omap2plus_defconfig has
not changed much in the last few kernel releases.

Cheers
Jon

Re: oprofile and ARM A9 hardware counter

[Will Deacon]

On Sat, May 12, 2012 at 12:51:00AM +0100, Jon Hunter wrote:
> On 05/11/2012 11:38 AM, Will Deacon wrote:
> > Excellent, that works for me. Once we've worked out the problem with my
> > .config you can have my tested-by.
> 
> Great! I have been looking at your .config, but I have not been able to
> figure out the problem so far. Do you recall what your config is based
> upon? I seems quite different to mine and the omap2plus_defconfig has
> not changed much in the last few kernel releases.

Hmm, I'm honestly not sure -- it was just lying around in my home directory.
Given that I know very little about OMAP, I would suspect that it's either
based on the defconfig or I inherited a working kernel image from somebody
else and used /proc/config.gz to build my own.

Will

oprofile and ARM A9 hardware counter

[Will Deacon]

On Sat, May 12, 2012 at 12:51:00AM +0100, Jon Hunter wrote:
> On 05/11/2012 11:38 AM, Will Deacon wrote:
> > Excellent, that works for me. Once we've worked out the problem with my
> > .config you can have my tested-by.
> 
> Great! I have been looking at your .config, but I have not been able to
> figure out the problem so far. Do you recall what your config is based
> upon? I seems quite different to mine and the omap2plus_defconfig has
> not changed much in the last few kernel releases.

Hmm, I'm honestly not sure -- it was just lying around in my home directory.
Given that I know very little about OMAP, I would suspect that it's either
based on the defconfig or I inherited a working kernel image from somebody
else and used /proc/config.gz to build my own.

Will

Re: oprofile and ARM A9 hardware counter

[Kevin Hilman]

Jon Hunter <jon-hunter@ti.com> writes:

[...]

> I have posted my latest series here [1] based upon that from Will [2]
> which attempts to fix the EMU CD based upon the inputs from this thread.
> It is working on my omap4460 panda. 

There are some differences between 4430 and 4460 here.  Can you test on
4430 as well?

Kevin

oprofile and ARM A9 hardware counter

[Kevin Hilman]

Jon Hunter <jon-hunter@ti.com> writes:

[...]

> I have posted my latest series here [1] based upon that from Will [2]
> which attempts to fix the EMU CD based upon the inputs from this thread.
> It is working on my omap4460 panda. 

There are some differences between 4430 and 4460 here.  Can you test on
4430 as well?

Kevin

Re: oprofile and ARM A9 hardware counter

[Jon Hunter]

Hi Kevin,

On 05/10/2012 09:12 AM, Kevin Hilman wrote:
> Jon Hunter <jon-hunter@ti.com> writes:
> 
> [...]
> 
>> I have posted my latest series here [1] based upon that from Will [2]
>> which attempts to fix the EMU CD based upon the inputs from this thread.
>> It is working on my omap4460 panda. 
> 
> There are some differences between 4430 and 4460 here.  Can you test on
> 4430 as well?

No problem. I tested on an OMAP4430 ES2.2 EMU blaze this morning and it
is also working.

By the way, from an EMU power domain perspective the omap4430 and
omap4460 behave the same, that is the PD is always set to OFF state and
so will transition to OFF when ever the EMU CD idles. So same problem
exists when using PMU and CTI.

Cheers
Jon

oprofile and ARM A9 hardware counter

[Jon Hunter]

Hi Kevin,

On 05/10/2012 09:12 AM, Kevin Hilman wrote:
> Jon Hunter <jon-hunter@ti.com> writes:
> 
> [...]
> 
>> I have posted my latest series here [1] based upon that from Will [2]
>> which attempts to fix the EMU CD based upon the inputs from this thread.
>> It is working on my omap4460 panda. 
> 
> There are some differences between 4430 and 4460 here.  Can you test on
> 4430 as well?

No problem. I tested on an OMAP4430 ES2.2 EMU blaze this morning and it
is also working.

By the way, from an EMU power domain perspective the omap4430 and
omap4460 behave the same, that is the PD is always set to OFF state and
so will transition to OFF when ever the EMU CD idles. So same problem
exists when using PMU and CTI.

Cheers
Jon

Re: oprofile and ARM A9 hardware counter

[Santosh Shilimkar]

Benoit,

On Wednesday 09 May 2012 04:28 PM, Cousson, Benoit wrote:
> Hi Kevin and Jon,
> 
> On 5/8/2012 11:22 PM, Kevin Hilman wrote:
>> Jon Hunter<jon-hunter@ti.com>  writes:
>>
>>> Hi Benoit,
>>>
>>> On 05/08/2012 06:01 AM, Cousson, Benoit wrote:
>>>
>>> [...]
>>>
>>>>>>> P.S. Please note there is also already a different fix in mainline for
>>>>>>> the EMU clkdm data from Paul which adds the force wakeup flag and
>>>>>>> removes the DISABLE_AUTO flag[1] (but leaves the ENABLE_AUTO flag,
>>>>>>> because the hardware is capable.)
>>>>>>
>>>>>> Hmmm ... yes saw this, and you will have to excuse me as I don't fully
>>>>>> follow the logic here. In fact, I am thinking we want the opposite ;-)
>>>>>>
>>>>>>   From looking, into this it seems to me that when PMU is running we want
>>>>>> the EMU clock domain in software-wakeup state and when PMU is not
>>>>>> running we want in the hardware auto state.
>>>>>
>>>>> So far, I'm with you.
>>>>>
>>>>>> By keeping the ENABLE_AUTO flag set, as soon as we enable the clock
>>>>>> domain it is put right back into the HW_AUTO state
>>>>>
>>>>> This is only because it was in the HWSUP state when _enable was called.
>>>>> If clkdm_deny_idle() is used, that behavior will change.
>>>>>
>>>>>> and hence PMU is
>>>>>> not working (see _enable() function in
>>>>>> arch/arm/mach-omap2/omap_hwmod.c)
>>>>>>
>>>>>> So really what I think we want is to remove the ENABLE_AUTO flag to keep
>>>>>> the clock domain in software wake-up and use the DISABLE_AUTO flag to
>>>>>> put the clock domain back in HW_AUTO (note this requires a patch to
>>>>>> perform this 2nd part).
>>>>>
>>>>> Well, Paul will have to comment here for the final word, but IIUC, the
>>>>> hwmod flags are supposed to indicate only what the HW is capable of.  If
>>>>> we want to change the runtime behavior, we nee to use (or add) APIs to
>>>>> change the beahvior.  In this case, clkdm_allow_idle(),
>>>>> clkdm_deny_idle() are probably what is needed here.
>>>>
>>>> Yes, indeed, we should not hack the flags to fix that kind of issue. The
>>>> flags describe what the HW is capable of, and the EMU CD can support
>>>> HW_AUTO and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the
>>>> only valid next power state is OFF, meaning that no retention mode is
>>>> supported. So any transition to idle will go to OFF and lead to a reset
>>>> upon wakeup.
>>>
>>> No hacking intended here, just getting the flags correct ;-)
>>>
>>> So let me start from the beginning ...
>>>
>>> 1. I agree that for the EMU CD that the valid HW states are HW_AUTO and
>>> SW_WKUP.
>>>
>>> 2. When the EMU CD is active (due to something like PMU), we want to
>>> keep the CD in the SW_WKUP state, otherwise we can automatically
>>> transition to idle and reset the IP (at least for omap4430).
>>
>>> 3. When the EMU CD is inactive, we want to keep the CD in the HW_AUTO
>>> state because SW_SLEEP is NOT supported.
>>>
>>> In the current code, we have the CLKDM_CAN_DISABLE_AUTO flag disabled
>>> and the CLKDM_CAN_ENABLE_AUTO flag enabled. If CLKDM_CAN_ENABLE_AUTO is
>>> set then the omap_pm_clkdms_setup() function will place the CD into
>>> HW_AUTO regardless of CLKDM_CAN_DISABLE_AUTO, and the next time the
>>> hwmod _enable() is called it is in the HW_AUTO state and so it is
>>> allowed to idle. This is not what we want. Do you agree?
>>>
>>> If I set CLKDM_CAN_DISABLE_AUTO flag and disable CLKDM_CAN_ENABLE_AUTO,
>>> then I do not have the above problem.
>>>
>>> To be honest, with you the more I look and test the code, the more
>>> confused I am by the definition of the CLKDM_CAN_HWSUP ...
>>>
>>> #define CLKDM_CAN_HWSUP	(CLKDM_CAN_ENABLE_AUTO | CLKDM_CAN_DISABLE_AUTO)
>>>
>>> When I look at where these flags are used, I see that
>>> CLKDM_CAN_ENABLE_AUTO is used in clkdm_allow_idle and
>>> CLKDM_CAN_DISABLE_AUTO is used in clkdm_deny_idle. So this implies that ...
>>>
>>> CLKDM_CAN_ENABLE_AUTO = Supports HW_AUTO state when CD is active
>>> CLKDM_CAN_DISABLE_AUTO = Does NOT supports HW_AUTO state when CD is active
>>>
>>> Are the above the correct definitions?
>>
>> Not quite.
>>
>> These flags describe the capabilities as defined in CLKTRCTRL field of
>> the CLKSTCTRL register (e.g. CM_EMU_CLKSTCTRL)
>>
>> CLKDM_CAN_ENABLE_AUTO: IP supports HW_AUTO state (and it can be enabled)
>> CLKDM_CAN_DISABLE_AUTO: HW_AUTO feature can be disabled (a.k.a. NO_SLEEP)
>>
>> Note that in OMAP4, the latter called NO_SLEEP in the TRM, but in OMAP3
>> it's described as "The automatic hardware-supervised mode is disabled"
> 
> Yeah, in fact this is the source of the current confusion for my point of view.
> 
> We chat about that with Paul some time back.
>  
> EMU CD does support HW_AUTO and SW_WKUP, so it means that if you want to disable the AUTO mode you can use the SW_WKUP.
> Assuming that CLKDM_CAN_DISABLE_AUTO is equivalent to NO_SLEEP is thus not correct. In fact any state != HW_AUTO should be considered a non-automatic mode.
> So EMU does support CLKDM_CAN_ENABLE_AUTO, CLKDM_CAN_DISABLE_AUTO and CLKDM_CAN_FORCE_WAKEUP.
> 
> But the way it is implemented does not really allow that, because disable hwsup imply setting state to OMAP34XX_CLKSTCTRL_DISABLE_AUTO.
> 
> void omap4_cminst_clkdm_disable_hwsup(u8 part, s16 inst, u16 cdoffs)
> {
>         _clktrctrl_write(OMAP34XX_CLKSTCTRL_DISABLE_AUTO, part, inst, cdoffs);
> }
> 
> So if we want to allow that, some code change are needed in order to set the clkdm mode to OMAP34XX_CLKSTCTRL_FORCE_WAKEUP if OMAP34XX_CLKSTCTRL_DISABLE_AUTO is not supported.
> 
>> What is confusing to me is that the OMAP4 TRM doesn't list the NO_SLEEP
>> mode as supported by the EMU.   It seems to me that if the IP supports
>> HW_AUTO, it should be able to be enabled *and* disabled.
> 
> No, not really, this is mostly OMAP3 legacy, and we do have plan to remove these useless modes going forward. We can effectively disable AUTO mode by going to FORCE_WAKEUP.
> 
> - 0x0 NO_SLEEP A clock domain sleep transition is never initiated, irrespective of the hardware conditions.
> - 0x1 SW_SLEEP A software-forced sleep transition. The transition is initiated when the associated hardware conditions are satisfied
Is the second statement correct ?
How about static/dynamic deps. Does SW_SLEEP honour that like HW_AUTO ?

Regards
Santosh

oprofile and ARM A9 hardware counter

[Santosh Shilimkar]

Benoit,

On Wednesday 09 May 2012 04:28 PM, Cousson, Benoit wrote:
> Hi Kevin and Jon,
> 
> On 5/8/2012 11:22 PM, Kevin Hilman wrote:
>> Jon Hunter<jon-hunter@ti.com>  writes:
>>
>>> Hi Benoit,
>>>
>>> On 05/08/2012 06:01 AM, Cousson, Benoit wrote:
>>>
>>> [...]
>>>
>>>>>>> P.S. Please note there is also already a different fix in mainline for
>>>>>>> the EMU clkdm data from Paul which adds the force wakeup flag and
>>>>>>> removes the DISABLE_AUTO flag[1] (but leaves the ENABLE_AUTO flag,
>>>>>>> because the hardware is capable.)
>>>>>>
>>>>>> Hmmm ... yes saw this, and you will have to excuse me as I don't fully
>>>>>> follow the logic here. In fact, I am thinking we want the opposite ;-)
>>>>>>
>>>>>>   From looking, into this it seems to me that when PMU is running we want
>>>>>> the EMU clock domain in software-wakeup state and when PMU is not
>>>>>> running we want in the hardware auto state.
>>>>>
>>>>> So far, I'm with you.
>>>>>
>>>>>> By keeping the ENABLE_AUTO flag set, as soon as we enable the clock
>>>>>> domain it is put right back into the HW_AUTO state
>>>>>
>>>>> This is only because it was in the HWSUP state when _enable was called.
>>>>> If clkdm_deny_idle() is used, that behavior will change.
>>>>>
>>>>>> and hence PMU is
>>>>>> not working (see _enable() function in
>>>>>> arch/arm/mach-omap2/omap_hwmod.c)
>>>>>>
>>>>>> So really what I think we want is to remove the ENABLE_AUTO flag to keep
>>>>>> the clock domain in software wake-up and use the DISABLE_AUTO flag to
>>>>>> put the clock domain back in HW_AUTO (note this requires a patch to
>>>>>> perform this 2nd part).
>>>>>
>>>>> Well, Paul will have to comment here for the final word, but IIUC, the
>>>>> hwmod flags are supposed to indicate only what the HW is capable of.  If
>>>>> we want to change the runtime behavior, we nee to use (or add) APIs to
>>>>> change the beahvior.  In this case, clkdm_allow_idle(),
>>>>> clkdm_deny_idle() are probably what is needed here.
>>>>
>>>> Yes, indeed, we should not hack the flags to fix that kind of issue. The
>>>> flags describe what the HW is capable of, and the EMU CD can support
>>>> HW_AUTO and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the
>>>> only valid next power state is OFF, meaning that no retention mode is
>>>> supported. So any transition to idle will go to OFF and lead to a reset
>>>> upon wakeup.
>>>
>>> No hacking intended here, just getting the flags correct ;-)
>>>
>>> So let me start from the beginning ...
>>>
>>> 1. I agree that for the EMU CD that the valid HW states are HW_AUTO and
>>> SW_WKUP.
>>>
>>> 2. When the EMU CD is active (due to something like PMU), we want to
>>> keep the CD in the SW_WKUP state, otherwise we can automatically
>>> transition to idle and reset the IP (at least for omap4430).
>>
>>> 3. When the EMU CD is inactive, we want to keep the CD in the HW_AUTO
>>> state because SW_SLEEP is NOT supported.
>>>
>>> In the current code, we have the CLKDM_CAN_DISABLE_AUTO flag disabled
>>> and the CLKDM_CAN_ENABLE_AUTO flag enabled. If CLKDM_CAN_ENABLE_AUTO is
>>> set then the omap_pm_clkdms_setup() function will place the CD into
>>> HW_AUTO regardless of CLKDM_CAN_DISABLE_AUTO, and the next time the
>>> hwmod _enable() is called it is in the HW_AUTO state and so it is
>>> allowed to idle. This is not what we want. Do you agree?
>>>
>>> If I set CLKDM_CAN_DISABLE_AUTO flag and disable CLKDM_CAN_ENABLE_AUTO,
>>> then I do not have the above problem.
>>>
>>> To be honest, with you the more I look and test the code, the more
>>> confused I am by the definition of the CLKDM_CAN_HWSUP ...
>>>
>>> #define CLKDM_CAN_HWSUP	(CLKDM_CAN_ENABLE_AUTO | CLKDM_CAN_DISABLE_AUTO)
>>>
>>> When I look at where these flags are used, I see that
>>> CLKDM_CAN_ENABLE_AUTO is used in clkdm_allow_idle and
>>> CLKDM_CAN_DISABLE_AUTO is used in clkdm_deny_idle. So this implies that ...
>>>
>>> CLKDM_CAN_ENABLE_AUTO = Supports HW_AUTO state when CD is active
>>> CLKDM_CAN_DISABLE_AUTO = Does NOT supports HW_AUTO state when CD is active
>>>
>>> Are the above the correct definitions?
>>
>> Not quite.
>>
>> These flags describe the capabilities as defined in CLKTRCTRL field of
>> the CLKSTCTRL register (e.g. CM_EMU_CLKSTCTRL)
>>
>> CLKDM_CAN_ENABLE_AUTO: IP supports HW_AUTO state (and it can be enabled)
>> CLKDM_CAN_DISABLE_AUTO: HW_AUTO feature can be disabled (a.k.a. NO_SLEEP)
>>
>> Note that in OMAP4, the latter called NO_SLEEP in the TRM, but in OMAP3
>> it's described as "The automatic hardware-supervised mode is disabled"
> 
> Yeah, in fact this is the source of the current confusion for my point of view.
> 
> We chat about that with Paul some time back.
>  
> EMU CD does support HW_AUTO and SW_WKUP, so it means that if you want to disable the AUTO mode you can use the SW_WKUP.
> Assuming that CLKDM_CAN_DISABLE_AUTO is equivalent to NO_SLEEP is thus not correct. In fact any state != HW_AUTO should be considered a non-automatic mode.
> So EMU does support CLKDM_CAN_ENABLE_AUTO, CLKDM_CAN_DISABLE_AUTO and CLKDM_CAN_FORCE_WAKEUP.
> 
> But the way it is implemented does not really allow that, because disable hwsup imply setting state to OMAP34XX_CLKSTCTRL_DISABLE_AUTO.
> 
> void omap4_cminst_clkdm_disable_hwsup(u8 part, s16 inst, u16 cdoffs)
> {
>         _clktrctrl_write(OMAP34XX_CLKSTCTRL_DISABLE_AUTO, part, inst, cdoffs);
> }
> 
> So if we want to allow that, some code change are needed in order to set the clkdm mode to OMAP34XX_CLKSTCTRL_FORCE_WAKEUP if OMAP34XX_CLKSTCTRL_DISABLE_AUTO is not supported.
> 
>> What is confusing to me is that the OMAP4 TRM doesn't list the NO_SLEEP
>> mode as supported by the EMU.   It seems to me that if the IP supports
>> HW_AUTO, it should be able to be enabled *and* disabled.
> 
> No, not really, this is mostly OMAP3 legacy, and we do have plan to remove these useless modes going forward. We can effectively disable AUTO mode by going to FORCE_WAKEUP.
> 
> - 0x0 NO_SLEEP A clock domain sleep transition is never initiated, irrespective of the hardware conditions.
> - 0x1 SW_SLEEP A software-forced sleep transition. The transition is initiated when the associated hardware conditions are satisfied
Is the second statement correct ?
How about static/dynamic deps. Does SW_SLEEP honour that like HW_AUTO ?

Regards
Santosh

Re: oprofile and ARM A9 hardware counter

[Paul Walmsley]

On Mon, 7 May 2012, Kevin Hilman wrote:

> Well, Paul will have to comment here for the final word, but IIUC, the
> hwmod flags are supposed to indicate only what the HW is capable of.

s/hwmod/clockdomain/ in this case, but that's exactly right.  The 
motivation is to allow this data to be autogenerated and to allow it to 
be verified against the TRM (assuming that the TRM is not wrong).
If there's some weird hardware bug, the intention is to either add a 
special workaround flag so the bug doesn't get hidden, or to deal with it 
in the code in some way.


- Paul

oprofile and ARM A9 hardware counter

[Paul Walmsley]

On Mon, 7 May 2012, Kevin Hilman wrote:

> Well, Paul will have to comment here for the final word, but IIUC, the
> hwmod flags are supposed to indicate only what the HW is capable of.

s/hwmod/clockdomain/ in this case, but that's exactly right.  The 
motivation is to allow this data to be autogenerated and to allow it to 
be verified against the TRM (assuming that the TRM is not wrong).
If there's some weird hardware bug, the intention is to either add a 
special workaround flag so the bug doesn't get hidden, or to deal with it 
in the code in some way.


- Paul

Re: oprofile and ARM A9 hardware counter

[Paul Walmsley]

On Tue, 3 Apr 2012, Will Deacon wrote:

> I'll take JTAG for a whirl to see where we are. If anything looks wrong in
> my dmesg, please shout (there are plenty of things in there that look like
> they've gone awry).

Might be worth booting with initcall_debug on the kernel command line.  
That will probably be easier than dealing with JTAG.

- Paul

oprofile and ARM A9 hardware counter

[Paul Walmsley]

On Tue, 3 Apr 2012, Will Deacon wrote:

> I'll take JTAG for a whirl to see where we are. If anything looks wrong in
> my dmesg, please shout (there are plenty of things in there that look like
> they've gone awry).

Might be worth booting with initcall_debug on the kernel command line.  
That will probably be easier than dealing with JTAG.

- Paul

Re: oprofile and ARM A9 hardware counter

[Will Deacon]

Hi Paul,

On Wed, Apr 04, 2012 at 01:00:53AM +0100, Paul Walmsley wrote:
> On Tue, 3 Apr 2012, Will Deacon wrote:
> 
> > I'll take JTAG for a whirl to see where we are. If anything looks wrong in
> > my dmesg, please shout (there are plenty of things in there that look like
> > they've gone awry).
> 
> Might be worth booting with initcall_debug on the kernel command line.  
> That will probably be easier than dealing with JTAG.

JTAG is unusable anyway because it requires a new MLO, which makes the
problem disappear.

Using initcall_debug I tracked the hang down to cti_unlock:

	val = __raw_readl(base + LOCKSTATUS);

causes the board to die, presumably because CoreSight isn't in a fit state
to be poked.

Will

oprofile and ARM A9 hardware counter

[Will Deacon]

Hi Paul,

On Wed, Apr 04, 2012 at 01:00:53AM +0100, Paul Walmsley wrote:
> On Tue, 3 Apr 2012, Will Deacon wrote:
> 
> > I'll take JTAG for a whirl to see where we are. If anything looks wrong in
> > my dmesg, please shout (there are plenty of things in there that look like
> > they've gone awry).
> 
> Might be worth booting with initcall_debug on the kernel command line.  
> That will probably be easier than dealing with JTAG.

JTAG is unusable anyway because it requires a new MLO, which makes the
problem disappear.

Using initcall_debug I tracked the hang down to cti_unlock:

	val = __raw_readl(base + LOCKSTATUS);

causes the board to die, presumably because CoreSight isn't in a fit state
to be poked.

Will

Re: oprofile and ARM A9 hardware counter

[stephane eranian]

On Wed, Jan 18, 2012 at 5:18 AM, Ming Lei <ming.lei@canonical.com> wrote:
> Hi stephane & Will,
>
> On Tue, Jan 10, 2012 at 8:46 AM, stephane eranian
> <eranian@googlemail.com> wrote:
>> See the dmesg from my 3.2 kernel:
>>
>>
>> [    0.000000] Booting Linux on physical CPU 0[    0.000000]
>
> Looks no obvious failure can be found from your 'dmesg'.
>
> I have run upstream 3.2 kernel plus 6 omap4 pmu patches below and
> found perf can work well on my panda board.
>
>        0001-arm-introduce-cross-trigger-interface-helpers.patch
>        0002-arm-pmu-allow-platform-specific-irq-enable-disable-h.patch
>        0003-arm-omap4-hwmod-introduce-emu-hwmod.patch or Benoit's debugss patch[2]
>        0004-arm-omap4-create-pmu-device-via-hwmod.patch[3]
>        0005-arm-omap4-support-pmu.patch[4]
>        0006-arm-omap4-pmu-support-runtime-pm.patch[5]
>
> Could you verify the above patches on 3.2 to see if perf can work well?
> If it doesn't, I may share my u-boot and mlo for your test if you'd like to do.
>
> BTW: #1 and #2 have been in Will's -next tree.
>
Should I use Will's -next tree as the base instead of Linus'?
Given that MARC is shutdown today, would you mind packing those patches
into a tarball and sending them to me directly?

When you mention Will's -next tree, are you talking about:
git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git for-next/perf

Thanks.

> thanks,
> --
> Ming Lei
>
> [1], uname -a & cat /proc/interrupts
> [root@root]#uname -a
> Linux beagleboard 3.2.0+ #480 SMP PREEMPT Wed Jan 18 11:38:33 CST 2012
> armv7l GNU/Linux
> [root@root]#cat /proc/interrupts
>           CPU0       CPU1
>  29:      29014      17353       GIC  twd
>  33:      56231          0       GIC  arm-pmu
>  34:          0      25778       GIC  arm-pmu
>
> [2], http://marc.info/?l=linux-omap&m=132162118104901&w=2
> [3],http://marc.info/?t=132227621500002&r=1&w=2
> [4],http://marc.info/?t=132227621700002&r=1&w=2
> [5],http://marc.info/?t=132227621700003&r=1&w=2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

oprofile and ARM A9 hardware counter

[stephane eranian]

On Wed, Jan 18, 2012 at 5:18 AM, Ming Lei <ming.lei@canonical.com> wrote:
> Hi stephane & Will,
>
> On Tue, Jan 10, 2012 at 8:46 AM, stephane eranian
> <eranian@googlemail.com> wrote:
>> See the dmesg from my 3.2 kernel:
>>
>>
>> [ ? ?0.000000] Booting Linux on physical CPU 0[ ? ?0.000000]
>
> Looks no obvious failure can be found from your 'dmesg'.
>
> I have run upstream 3.2 kernel plus 6 omap4 pmu patches below and
> found perf can work well on my panda board.
>
> ? ? ? ?0001-arm-introduce-cross-trigger-interface-helpers.patch
> ? ? ? ?0002-arm-pmu-allow-platform-specific-irq-enable-disable-h.patch
> ? ? ? ?0003-arm-omap4-hwmod-introduce-emu-hwmod.patch or Benoit's debugss patch[2]
> ? ? ? ?0004-arm-omap4-create-pmu-device-via-hwmod.patch[3]
> ? ? ? ?0005-arm-omap4-support-pmu.patch[4]
> ? ? ? ?0006-arm-omap4-pmu-support-runtime-pm.patch[5]
>
> Could you verify the above patches on 3.2 to see if perf can work well?
> If it doesn't, I may share my u-boot and mlo for your test if you'd like to do.
>
> BTW: #1 and #2 have been in Will's -next tree.
>
Should I use Will's -next tree as the base instead of Linus'?
Given that MARC is shutdown today, would you mind packing those patches
into a tarball and sending them to me directly?

When you mention Will's -next tree, are you talking about:
git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git for-next/perf

Thanks.

> thanks,
> --
> Ming Lei
>
> [1], uname -a & cat /proc/interrupts
> [root at root]#uname -a
> Linux beagleboard 3.2.0+ #480 SMP PREEMPT Wed Jan 18 11:38:33 CST 2012
> armv7l GNU/Linux
> [root at root]#cat /proc/interrupts
> ? ? ? ? ? CPU0 ? ? ? CPU1
> ?29: ? ? ?29014 ? ? ?17353 ? ? ? GIC ?twd
> ?33: ? ? ?56231 ? ? ? ? ?0 ? ? ? GIC ?arm-pmu
> ?34: ? ? ? ? ?0 ? ? ?25778 ? ? ? GIC ?arm-pmu
>
> [2], http://marc.info/?l=linux-omap&m=132162118104901&w=2
> [3],http://marc.info/?t=132227621500002&r=1&w=2
> [4],http://marc.info/?t=132227621700002&r=1&w=2
> [5],http://marc.info/?t=132227621700003&r=1&w=2

Re: oprofile and ARM A9 hardware counter

[Ming Lei]

[-- Attachment #1: Type: text/plain, Size: 908 bytes --]

Hi,

On Wed, Jan 18, 2012 at 5:54 PM, stephane eranian <eranian@googlemail.com>
> Should I use Will's -next tree as the base instead of Linus'?

Either one is OK. If you use linus tree as base, you need to apply the #1 and
#2 patch manually.

> Given that MARC is shutdown today, would you mind packing those patches
> into a tarball and sending them to me directly?

See attachment, which includes the patches from #3 to #6.

>
> When you mention Will's -next tree, are you talking about:
> git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git for-next/perf

It is perf/omap4 brach, you can pick up the two patches[1][2] directly from
the branch.


thanks,
--
Ming Lei

[1], http://git.kernel.org/?p=linux/kernel/git/will/linux.git;a=commit;h=7924a3eba0766348d6d6a56cbb9873cdbcab0d8c

[2], http://git.kernel.org/?p=linux/kernel/git/will/linux.git;a=commit;h=bde071f005e2dc71378aff69e86b961d8cd7922f

[-- Attachment #2: omap4_pmu.tar.gz --]
[-- Type: application/x-gzip, Size: 7423 bytes --]

oprofile and ARM A9 hardware counter

[Ming Lei]

Hi,

On Wed, Jan 18, 2012 at 5:54 PM, stephane eranian <eranian@googlemail.com>
> Should I use Will's -next tree as the base instead of Linus'?

Either one is OK. If you use linus tree as base, you need to apply the #1 and
#2 patch manually.

> Given that MARC is shutdown today, would you mind packing those patches
> into a tarball and sending them to me directly?

See attachment, which includes the patches from #3 to #6.

>
> When you mention Will's -next tree, are you talking about:
> git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git for-next/perf

It is perf/omap4 brach, you can pick up the two patches[1][2] directly from
the branch.


thanks,
--
Ming Lei

[1], http://git.kernel.org/?p=linux/kernel/git/will/linux.git;a=commit;h=7924a3eba0766348d6d6a56cbb9873cdbcab0d8c

[2], http://git.kernel.org/?p=linux/kernel/git/will/linux.git;a=commit;h=bde071f005e2dc71378aff69e86b961d8cd7922f
-------------- next part --------------
A non-text attachment was scrubbed...
Name: omap4_pmu.tar.gz
Type: application/x-gzip
Size: 7423 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120118/650d6340/attachment-0001.gz>

Re: oprofile and ARM A9 hardware counter

[stephane eranian]

Ming,

Ok, so I used Linus' tree @

It already includes patches #1 and #2. I applied 4-6.
Recompiled but my kernel does not boot, I don't see
anything on the serial console. Could be a broken
.config file. Could you send me your .config for Panda?

Thanks.

On Wed, Jan 18, 2012 at 11:07 AM, Ming Lei <ming.lei@canonical.com> wrote:
> Hi,
>
> On Wed, Jan 18, 2012 at 5:54 PM, stephane eranian <eranian@googlemail.com>
>> Should I use Will's -next tree as the base instead of Linus'?
>
> Either one is OK. If you use linus tree as base, you need to apply the #1 and
> #2 patch manually.
>
>> Given that MARC is shutdown today, would you mind packing those patches
>> into a tarball and sending them to me directly?
>
> See attachment, which includes the patches from #3 to #6.
>
>>
>> When you mention Will's -next tree, are you talking about:
>> git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git for-next/perf
>
> It is perf/omap4 brach, you can pick up the two patches[1][2] directly from
> the branch.
>
>
> thanks,
> --
> Ming Lei
>
> [1], http://git.kernel.org/?p=linux/kernel/git/will/linux.git;a=commit;h=7924a3eba0766348d6d6a56cbb9873cdbcab0d8c
>
> [2], http://git.kernel.org/?p=linux/kernel/git/will/linux.git;a=commit;h=bde071f005e2dc71378aff69e86b961d8cd7922f

oprofile and ARM A9 hardware counter

[stephane eranian]

Ming,

Ok, so I used Linus' tree @

It already includes patches #1 and #2. I applied 4-6.
Recompiled but my kernel does not boot, I don't see
anything on the serial console. Could be a broken
.config file. Could you send me your .config for Panda?

Thanks.

On Wed, Jan 18, 2012 at 11:07 AM, Ming Lei <ming.lei@canonical.com> wrote:
> Hi,
>
> On Wed, Jan 18, 2012 at 5:54 PM, stephane eranian <eranian@googlemail.com>
>> Should I use Will's -next tree as the base instead of Linus'?
>
> Either one is OK. If you use linus tree as base, you need to apply the #1 and
> #2 patch manually.
>
>> Given that MARC is shutdown today, would you mind packing those patches
>> into a tarball and sending them to me directly?
>
> See attachment, which includes the patches from #3 to #6.
>
>>
>> When you mention Will's -next tree, are you talking about:
>> git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git for-next/perf
>
> It is perf/omap4 brach, you can pick up the two patches[1][2] directly from
> the branch.
>
>
> thanks,
> --
> Ming Lei
>
> [1], http://git.kernel.org/?p=linux/kernel/git/will/linux.git;a=commit;h=7924a3eba0766348d6d6a56cbb9873cdbcab0d8c
>
> [2], http://git.kernel.org/?p=linux/kernel/git/will/linux.git;a=commit;h=bde071f005e2dc71378aff69e86b961d8cd7922f

Re: oprofile and ARM A9 hardware counter

[Ming Lei]

[-- Attachment #1: Type: text/plain, Size: 1845 bytes --]

Hi,

On Thu, Jan 19, 2012 at 5:58 AM, stephane eranian
<eranian@googlemail.com> wrote:
> Ming,
>
> Ok, so I used Linus' tree @
>
> It already includes patches #1 and #2. I applied 4-6.

The patch #3 is missed?

> Recompiled but my kernel does not boot, I don't see
> anything on the serial console. Could be a broken

I don't think that the patches can cause your non boot, you
can try the linus tree kernel first, then try the patches.

> .config file. Could you send me your .config for Panda?

See the attachment.

>
> Thanks.
>
> On Wed, Jan 18, 2012 at 11:07 AM, Ming Lei <ming.lei@canonical.com> wrote:
>> Hi,
>>
>> On Wed, Jan 18, 2012 at 5:54 PM, stephane eranian <eranian@googlemail.com>
>>> Should I use Will's -next tree as the base instead of Linus'?
>>
>> Either one is OK. If you use linus tree as base, you need to apply the #1 and
>> #2 patch manually.
>>
>>> Given that MARC is shutdown today, would you mind packing those patches
>>> into a tarball and sending them to me directly?
>>
>> See attachment, which includes the patches from #3 to #6.
>>
>>>
>>> When you mention Will's -next tree, are you talking about:
>>> git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git for-next/perf
>>
>> It is perf/omap4 brach, you can pick up the two patches[1][2] directly from
>> the branch.
>>
>>
>> thanks,
>> --
>> Ming Lei
>>
>> [1], http://git.kernel.org/?p=linux/kernel/git/will/linux.git;a=commit;h=7924a3eba0766348d6d6a56cbb9873cdbcab0d8c
>>
>> [2], http://git.kernel.org/?p=linux/kernel/git/will/linux.git;a=commit;h=bde071f005e2dc71378aff69e86b961d8cd7922f
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[-- Attachment #2: conf.tar.gz --]
[-- Type: application/x-gzip, Size: 16252 bytes --]

oprofile and ARM A9 hardware counter

[Ming Lei]

Hi,

On Thu, Jan 19, 2012 at 5:58 AM, stephane eranian
<eranian@googlemail.com> wrote:
> Ming,
>
> Ok, so I used Linus' tree @
>
> It already includes patches #1 and #2. I applied 4-6.

The patch #3 is missed?

> Recompiled but my kernel does not boot, I don't see
> anything on the serial console. Could be a broken

I don't think that the patches can cause your non boot, you
can try the linus tree kernel first, then try the patches.

> .config file. Could you send me your .config for Panda?

See the attachment.

>
> Thanks.
>
> On Wed, Jan 18, 2012 at 11:07 AM, Ming Lei <ming.lei@canonical.com> wrote:
>> Hi,
>>
>> On Wed, Jan 18, 2012 at 5:54 PM, stephane eranian <eranian@googlemail.com>
>>> Should I use Will's -next tree as the base instead of Linus'?
>>
>> Either one is OK. If you use linus tree as base, you need to apply the #1 and
>> #2 patch manually.
>>
>>> Given that MARC is shutdown today, would you mind packing those patches
>>> into a tarball and sending them to me directly?
>>
>> See attachment, which includes the patches from #3 to #6.
>>
>>>
>>> When you mention Will's -next tree, are you talking about:
>>> git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git for-next/perf
>>
>> It is perf/omap4 brach, you can pick up the two patches[1][2] directly from
>> the branch.
>>
>>
>> thanks,
>> --
>> Ming Lei
>>
>> [1], http://git.kernel.org/?p=linux/kernel/git/will/linux.git;a=commit;h=7924a3eba0766348d6d6a56cbb9873cdbcab0d8c
>>
>> [2], http://git.kernel.org/?p=linux/kernel/git/will/linux.git;a=commit;h=bde071f005e2dc71378aff69e86b961d8cd7922f
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: conf.tar.gz
Type: application/x-gzip
Size: 16252 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120119/2a4482db/attachment-0001.gz>

Re: oprofile and ARM A9 hardware counter

[stephane eranian]

Hi,

Ok some update on this.
With your .config file + 3.2.0 (Linus) + patch 3, 4, 5, 6, I get a kernel that
boots. It does recognize the PMU. However, it still does not count correctly
and I believe for the same reason.: no interrupts are delivered.

I run a cycle burner program on CPU0, I watch /proc/interrupts.
and then I run  libpfm4 program that does per-cpu monitoring on CPU0 and
print the counts every second:

$ sudo ./syst_count -d 10 -p -c 0 -e cpu_cycles
<press CTRL-C to quit before 10s time limit>
# 1s -----
CPU0   G0  1008129147           cpu_cycles (scaling 0.00%,
ena=1000152588, run=1000152588)
# 2s -----
CPU0   G0  2016240766           cpu_cycles (scaling 0.00%,
ena=2000335693, run=2000335693)
# 3s -----
CPU0   G0  3024249265           cpu_cycles (scaling 0.00%,
ena=3000427245, run=3000427245)
# 4s -----
CPU0   G0  4072779364           cpu_cycles (scaling 0.00%,
ena=4040710449, run=4040710449)
# 5s -----
CPU0   G0  785954705            cpu_cycles (scaling 0.00%,
ena=5040954589, run=5040954589)
# 6s -----
CPU0   G0  1803397848           cpu_cycles (scaling 0.00%,
ena=6050384520, run=6050384520)
# 7s -----

You clearly see that after 4s you've reached the 32-bit limit of the
counter and then you wrap around.
It should show 5 billions or so cycles. Over the entire run, no
arm-pmu interrupt was delivered according
to /proc/interrupts.

I guess you can test the same condition using perf directly, use a
program that burns cycles
for a know duration. Try < 4s and then > 4s. I use 1s vs. 10s and I
expect the count to be
10x larger in the latter test case. If it's not then, interrupts are
not coming in,


On Thu, Jan 19, 2012 at 2:21 AM, Ming Lei <ming.lei@canonical.com> wrote:
> Hi,
>
> On Thu, Jan 19, 2012 at 5:58 AM, stephane eranian
> <eranian@googlemail.com> wrote:
>> Ming,
>>
>> Ok, so I used Linus' tree @
>>
>> It already includes patches #1 and #2. I applied 4-6.
>
> The patch #3 is missed?
>
>> Recompiled but my kernel does not boot, I don't see
>> anything on the serial console. Could be a broken
>
> I don't think that the patches can cause your non boot, you
> can try the linus tree kernel first, then try the patches.
>
>> .config file. Could you send me your .config for Panda?
>
> See the attachment.
>
>>
>> Thanks.
>>
>> On Wed, Jan 18, 2012 at 11:07 AM, Ming Lei <ming.lei@canonical.com> wrote:
>>> Hi,
>>>
>>> On Wed, Jan 18, 2012 at 5:54 PM, stephane eranian <eranian@googlemail.com>
>>>> Should I use Will's -next tree as the base instead of Linus'?
>>>
>>> Either one is OK. If you use linus tree as base, you need to apply the #1 and
>>> #2 patch manually.
>>>
>>>> Given that MARC is shutdown today, would you mind packing those patches
>>>> into a tarball and sending them to me directly?
>>>
>>> See attachment, which includes the patches from #3 to #6.
>>>
>>>>
>>>> When you mention Will's -next tree, are you talking about:
>>>> git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git for-next/perf
>>>
>>> It is perf/omap4 brach, you can pick up the two patches[1][2] directly from
>>> the branch.
>>>
>>>
>>> thanks,
>>> --
>>> Ming Lei
>>>
>>> [1], http://git.kernel.org/?p=linux/kernel/git/will/linux.git;a=commit;h=7924a3eba0766348d6d6a56cbb9873cdbcab0d8c
>>>
>>> [2], http://git.kernel.org/?p=linux/kernel/git/will/linux.git;a=commit;h=bde071f005e2dc71378aff69e86b961d8cd7922f
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

oprofile and ARM A9 hardware counter

[stephane eranian]

Hi,

Ok some update on this.
With your .config file + 3.2.0 (Linus) + patch 3, 4, 5, 6, I get a kernel that
boots. It does recognize the PMU. However, it still does not count correctly
and I believe for the same reason.: no interrupts are delivered.

I run a cycle burner program on CPU0, I watch /proc/interrupts.
and then I run  libpfm4 program that does per-cpu monitoring on CPU0 and
print the counts every second:

$ sudo ./syst_count -d 10 -p -c 0 -e cpu_cycles
<press CTRL-C to quit before 10s time limit>
# 1s -----
CPU0   G0  1008129147           cpu_cycles (scaling 0.00%,
ena=1000152588, run=1000152588)
# 2s -----
CPU0   G0  2016240766           cpu_cycles (scaling 0.00%,
ena=2000335693, run=2000335693)
# 3s -----
CPU0   G0  3024249265           cpu_cycles (scaling 0.00%,
ena=3000427245, run=3000427245)
# 4s -----
CPU0   G0  4072779364           cpu_cycles (scaling 0.00%,
ena=4040710449, run=4040710449)
# 5s -----
CPU0   G0  785954705            cpu_cycles (scaling 0.00%,
ena=5040954589, run=5040954589)
# 6s -----
CPU0   G0  1803397848           cpu_cycles (scaling 0.00%,
ena=6050384520, run=6050384520)
# 7s -----

You clearly see that after 4s you've reached the 32-bit limit of the
counter and then you wrap around.
It should show 5 billions or so cycles. Over the entire run, no
arm-pmu interrupt was delivered according
to /proc/interrupts.

I guess you can test the same condition using perf directly, use a
program that burns cycles
for a know duration. Try < 4s and then > 4s. I use 1s vs. 10s and I
expect the count to be
10x larger in the latter test case. If it's not then, interrupts are
not coming in,


On Thu, Jan 19, 2012 at 2:21 AM, Ming Lei <ming.lei@canonical.com> wrote:
> Hi,
>
> On Thu, Jan 19, 2012 at 5:58 AM, stephane eranian
> <eranian@googlemail.com> wrote:
>> Ming,
>>
>> Ok, so I used Linus' tree @
>>
>> It already includes patches #1 and #2. I applied 4-6.
>
> The patch #3 is missed?
>
>> Recompiled but my kernel does not boot, I don't see
>> anything on the serial console. Could be a broken
>
> I don't think that the patches can cause your non boot, you
> can try the linus tree kernel first, then try the patches.
>
>> .config file. Could you send me your .config for Panda?
>
> See the attachment.
>
>>
>> Thanks.
>>
>> On Wed, Jan 18, 2012 at 11:07 AM, Ming Lei <ming.lei@canonical.com> wrote:
>>> Hi,
>>>
>>> On Wed, Jan 18, 2012 at 5:54 PM, stephane eranian <eranian@googlemail.com>
>>>> Should I use Will's -next tree as the base instead of Linus'?
>>>
>>> Either one is OK. If you use linus tree as base, you need to apply the #1 and
>>> #2 patch manually.
>>>
>>>> Given that MARC is shutdown today, would you mind packing those patches
>>>> into a tarball and sending them to me directly?
>>>
>>> See attachment, which includes the patches from #3 to #6.
>>>
>>>>
>>>> When you mention Will's -next tree, are you talking about:
>>>> git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git for-next/perf
>>>
>>> It is perf/omap4 brach, you can pick up the two patches[1][2] directly from
>>> the branch.
>>>
>>>
>>> thanks,
>>> --
>>> Ming Lei
>>>
>>> [1], http://git.kernel.org/?p=linux/kernel/git/will/linux.git;a=commit;h=7924a3eba0766348d6d6a56cbb9873cdbcab0d8c
>>>
>>> [2], http://git.kernel.org/?p=linux/kernel/git/will/linux.git;a=commit;h=bde071f005e2dc71378aff69e86b961d8cd7922f
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at ?http://vger.kernel.org/majordomo-info.html

Re: oprofile and ARM A9 hardware counter

[Ming Lei]

Hi,

On Thu, Jan 19, 2012 at 7:34 PM, stephane eranian
<eranian@googlemail.com> wrote:
> Hi,
>
> Ok some update on this.
> With your .config file + 3.2.0 (Linus) + patch 3, 4, 5, 6, I get a kernel that

You forget patch 1 and patch 2?

> boots. It does recognize the PMU. However, it still does not count correctly
> and I believe for the same reason.: no interrupts are delivered.
>
> I run a cycle burner program on CPU0, I watch /proc/interrupts.
> and then I run  libpfm4 program that does per-cpu monitoring on CPU0 and
> print the counts every second:

I just run 'perf top', then watch output of '/proc/interrupts' in
another terminal. I am sure I can see perf is OK and interrupts are
generated on my pandaboard.

>
> $ sudo ./syst_count -d 10 -p -c 0 -e cpu_cycles
> <press CTRL-C to quit before 10s time limit>
> # 1s -----
> CPU0   G0  1008129147           cpu_cycles (scaling 0.00%,
> ena=1000152588, run=1000152588)
> # 2s -----
> CPU0   G0  2016240766           cpu_cycles (scaling 0.00%,
> ena=2000335693, run=2000335693)
> # 3s -----
> CPU0   G0  3024249265           cpu_cycles (scaling 0.00%,
> ena=3000427245, run=3000427245)
> # 4s -----
> CPU0   G0  4072779364           cpu_cycles (scaling 0.00%,
> ena=4040710449, run=4040710449)
> # 5s -----
> CPU0   G0  785954705            cpu_cycles (scaling 0.00%,
> ena=5040954589, run=5040954589)
> # 6s -----
> CPU0   G0  1803397848           cpu_cycles (scaling 0.00%,
> ena=6050384520, run=6050384520)
> # 7s -----
>
> You clearly see that after 4s you've reached the 32-bit limit of the
> counter and then you wrap around.
> It should show 5 billions or so cycles. Over the entire run, no
> arm-pmu interrupt was delivered according
> to /proc/interrupts.
>
> I guess you can test the same condition using perf directly, use a
> program that burns cycles
> for a know duration. Try < 4s and then > 4s. I use 1s vs. 10s and I
> expect the count to be
> 10x larger in the latter test case. If it's not then, interrupts are
> not coming in,
>
>
> On Thu, Jan 19, 2012 at 2:21 AM, Ming Lei <ming.lei@canonical.com> wrote:
>> Hi,
>>
>> On Thu, Jan 19, 2012 at 5:58 AM, stephane eranian
>> <eranian@googlemail.com> wrote:
>>> Ming,
>>>
>>> Ok, so I used Linus' tree @
>>>
>>> It already includes patches #1 and #2. I applied 4-6.
>>
>> The patch #3 is missed?
>>
>>> Recompiled but my kernel does not boot, I don't see
>>> anything on the serial console. Could be a broken
>>
>> I don't think that the patches can cause your non boot, you
>> can try the linus tree kernel first, then try the patches.
>>
>>> .config file. Could you send me your .config for Panda?
>>
>> See the attachment.
>>
>>>
>>> Thanks.
>>>
>>> On Wed, Jan 18, 2012 at 11:07 AM, Ming Lei <ming.lei@canonical.com> wrote:
>>>> Hi,
>>>>
>>>> On Wed, Jan 18, 2012 at 5:54 PM, stephane eranian <eranian@googlemail.com>
>>>>> Should I use Will's -next tree as the base instead of Linus'?
>>>>
>>>> Either one is OK. If you use linus tree as base, you need to apply the #1 and
>>>> #2 patch manually.
>>>>
>>>>> Given that MARC is shutdown today, would you mind packing those patches
>>>>> into a tarball and sending them to me directly?
>>>>
>>>> See attachment, which includes the patches from #3 to #6.
>>>>
>>>>>
>>>>> When you mention Will's -next tree, are you talking about:
>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git for-next/perf
>>>>
>>>> It is perf/omap4 brach, you can pick up the two patches[1][2] directly from
>>>> the branch.
>>>>
>>>>
>>>> thanks,
>>>> --
>>>> Ming Lei
>>>>
>>>> [1], http://git.kernel.org/?p=linux/kernel/git/will/linux.git;a=commit;h=7924a3eba0766348d6d6a56cbb9873cdbcab0d8c
>>>>
>>>> [2], http://git.kernel.org/?p=linux/kernel/git/will/linux.git;a=commit;h=bde071f005e2dc71378aff69e86b961d8cd7922f
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

oprofile and ARM A9 hardware counter

[Ming Lei]

Hi,

On Thu, Jan 19, 2012 at 7:34 PM, stephane eranian
<eranian@googlemail.com> wrote:
> Hi,
>
> Ok some update on this.
> With your .config file + 3.2.0 (Linus) + patch 3, 4, 5, 6, I get a kernel that

You forget patch 1 and patch 2?

> boots. It does recognize the PMU. However, it still does not count correctly
> and I believe for the same reason.: no interrupts are delivered.
>
> I run a cycle burner program on CPU0, I watch /proc/interrupts.
> and then I run ?libpfm4 program that does per-cpu monitoring on CPU0 and
> print the counts every second:

I just run 'perf top', then watch output of '/proc/interrupts' in
another terminal. I am sure I can see perf is OK and interrupts are
generated on my pandaboard.

>
> $ sudo ./syst_count -d 10 -p -c 0 -e cpu_cycles
> <press CTRL-C to quit before 10s time limit>
> # 1s -----
> CPU0 ? G0 ?1008129147 ? ? ? ? ? cpu_cycles (scaling 0.00%,
> ena=1000152588, run=1000152588)
> # 2s -----
> CPU0 ? G0 ?2016240766 ? ? ? ? ? cpu_cycles (scaling 0.00%,
> ena=2000335693, run=2000335693)
> # 3s -----
> CPU0 ? G0 ?3024249265 ? ? ? ? ? cpu_cycles (scaling 0.00%,
> ena=3000427245, run=3000427245)
> # 4s -----
> CPU0 ? G0 ?4072779364 ? ? ? ? ? cpu_cycles (scaling 0.00%,
> ena=4040710449, run=4040710449)
> # 5s -----
> CPU0 ? G0 ?785954705 ? ? ? ? ? ?cpu_cycles (scaling 0.00%,
> ena=5040954589, run=5040954589)
> # 6s -----
> CPU0 ? G0 ?1803397848 ? ? ? ? ? cpu_cycles (scaling 0.00%,
> ena=6050384520, run=6050384520)
> # 7s -----
>
> You clearly see that after 4s you've reached the 32-bit limit of the
> counter and then you wrap around.
> It should show 5 billions or so cycles. Over the entire run, no
> arm-pmu interrupt was delivered according
> to /proc/interrupts.
>
> I guess you can test the same condition using perf directly, use a
> program that burns cycles
> for a know duration. Try < 4s and then > 4s. I use 1s vs. 10s and I
> expect the count to be
> 10x larger in the latter test case. If it's not then, interrupts are
> not coming in,
>
>
> On Thu, Jan 19, 2012 at 2:21 AM, Ming Lei <ming.lei@canonical.com> wrote:
>> Hi,
>>
>> On Thu, Jan 19, 2012 at 5:58 AM, stephane eranian
>> <eranian@googlemail.com> wrote:
>>> Ming,
>>>
>>> Ok, so I used Linus' tree @
>>>
>>> It already includes patches #1 and #2. I applied 4-6.
>>
>> The patch #3 is missed?
>>
>>> Recompiled but my kernel does not boot, I don't see
>>> anything on the serial console. Could be a broken
>>
>> I don't think that the patches can cause your non boot, you
>> can try the linus tree kernel first, then try the patches.
>>
>>> .config file. Could you send me your .config for Panda?
>>
>> See the attachment.
>>
>>>
>>> Thanks.
>>>
>>> On Wed, Jan 18, 2012 at 11:07 AM, Ming Lei <ming.lei@canonical.com> wrote:
>>>> Hi,
>>>>
>>>> On Wed, Jan 18, 2012 at 5:54 PM, stephane eranian <eranian@googlemail.com>
>>>>> Should I use Will's -next tree as the base instead of Linus'?
>>>>
>>>> Either one is OK. If you use linus tree as base, you need to apply the #1 and
>>>> #2 patch manually.
>>>>
>>>>> Given that MARC is shutdown today, would you mind packing those patches
>>>>> into a tarball and sending them to me directly?
>>>>
>>>> See attachment, which includes the patches from #3 to #6.
>>>>
>>>>>
>>>>> When you mention Will's -next tree, are you talking about:
>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git for-next/perf
>>>>
>>>> It is perf/omap4 brach, you can pick up the two patches[1][2] directly from
>>>> the branch.
>>>>
>>>>
>>>> thanks,
>>>> --
>>>> Ming Lei
>>>>
>>>> [1], http://git.kernel.org/?p=linux/kernel/git/will/linux.git;a=commit;h=7924a3eba0766348d6d6a56cbb9873cdbcab0d8c
>>>>
>>>> [2], http://git.kernel.org/?p=linux/kernel/git/will/linux.git;a=commit;h=bde071f005e2dc71378aff69e86b961d8cd7922f
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>>> the body of a message to majordomo at vger.kernel.org
>>> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html

Re: oprofile and ARM A9 hardware counter

[stephane eranian]

On Thu, Jan 19, 2012 at 1:45 PM, Ming Lei <ming.lei@canonical.com> wrote:
> Hi,
>
> On Thu, Jan 19, 2012 at 7:34 PM, stephane eranian
> <eranian@googlemail.com> wrote:
>> Hi,
>>
>> Ok some update on this.
>> With your .config file + 3.2.0 (Linus) + patch 3, 4, 5, 6, I get a kernel that
>
> You forget patch 1 and patch 2?
>
They are already in 3.2.0. Unless I am mistaken.

are you sure you don't have anything else applied?

>> boots. It does recognize the PMU. However, it still does not count correctly
>> and I believe for the same reason.: no interrupts are delivered.
>>
>> I run a cycle burner program on CPU0, I watch /proc/interrupts.
>> and then I run  libpfm4 program that does per-cpu monitoring on CPU0 and
>> print the counts every second:
>
> I just run 'perf top', then watch output of '/proc/interrupts' in
> another terminal. I am sure I can see perf is OK and interrupts are
> generated on my pandaboard.
>
>>
>> $ sudo ./syst_count -d 10 -p -c 0 -e cpu_cycles
>> <press CTRL-C to quit before 10s time limit>
>> # 1s -----
>> CPU0   G0  1008129147           cpu_cycles (scaling 0.00%,
>> ena=1000152588, run=1000152588)
>> # 2s -----
>> CPU0   G0  2016240766           cpu_cycles (scaling 0.00%,
>> ena=2000335693, run=2000335693)
>> # 3s -----
>> CPU0   G0  3024249265           cpu_cycles (scaling 0.00%,
>> ena=3000427245, run=3000427245)
>> # 4s -----
>> CPU0   G0  4072779364           cpu_cycles (scaling 0.00%,
>> ena=4040710449, run=4040710449)
>> # 5s -----
>> CPU0   G0  785954705            cpu_cycles (scaling 0.00%,
>> ena=5040954589, run=5040954589)
>> # 6s -----
>> CPU0   G0  1803397848           cpu_cycles (scaling 0.00%,
>> ena=6050384520, run=6050384520)
>> # 7s -----
>>
>> You clearly see that after 4s you've reached the 32-bit limit of the
>> counter and then you wrap around.
>> It should show 5 billions or so cycles. Over the entire run, no
>> arm-pmu interrupt was delivered according
>> to /proc/interrupts.
>>
>> I guess you can test the same condition using perf directly, use a
>> program that burns cycles
>> for a know duration. Try < 4s and then > 4s. I use 1s vs. 10s and I
>> expect the count to be
>> 10x larger in the latter test case. If it's not then, interrupts are
>> not coming in,
>>
>>
>> On Thu, Jan 19, 2012 at 2:21 AM, Ming Lei <ming.lei@canonical.com> wrote:
>>> Hi,
>>>
>>> On Thu, Jan 19, 2012 at 5:58 AM, stephane eranian
>>> <eranian@googlemail.com> wrote:
>>>> Ming,
>>>>
>>>> Ok, so I used Linus' tree @
>>>>
>>>> It already includes patches #1 and #2. I applied 4-6.
>>>
>>> The patch #3 is missed?
>>>
>>>> Recompiled but my kernel does not boot, I don't see
>>>> anything on the serial console. Could be a broken
>>>
>>> I don't think that the patches can cause your non boot, you
>>> can try the linus tree kernel first, then try the patches.
>>>
>>>> .config file. Could you send me your .config for Panda?
>>>
>>> See the attachment.
>>>
>>>>
>>>> Thanks.
>>>>
>>>> On Wed, Jan 18, 2012 at 11:07 AM, Ming Lei <ming.lei@canonical.com> wrote:
>>>>> Hi,
>>>>>
>>>>> On Wed, Jan 18, 2012 at 5:54 PM, stephane eranian <eranian@googlemail.com>
>>>>>> Should I use Will's -next tree as the base instead of Linus'?
>>>>>
>>>>> Either one is OK. If you use linus tree as base, you need to apply the #1 and
>>>>> #2 patch manually.
>>>>>
>>>>>> Given that MARC is shutdown today, would you mind packing those patches
>>>>>> into a tarball and sending them to me directly?
>>>>>
>>>>> See attachment, which includes the patches from #3 to #6.
>>>>>
>>>>>>
>>>>>> When you mention Will's -next tree, are you talking about:
>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git for-next/perf
>>>>>
>>>>> It is perf/omap4 brach, you can pick up the two patches[1][2] directly from
>>>>> the branch.
>>>>>
>>>>>
>>>>> thanks,
>>>>> --
>>>>> Ming Lei
>>>>>
>>>>> [1], http://git.kernel.org/?p=linux/kernel/git/will/linux.git;a=commit;h=7924a3eba0766348d6d6a56cbb9873cdbcab0d8c
>>>>>
>>>>> [2], http://git.kernel.org/?p=linux/kernel/git/will/linux.git;a=commit;h=bde071f005e2dc71378aff69e86b961d8cd7922f
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

oprofile and ARM A9 hardware counter

[stephane eranian]

On Thu, Jan 19, 2012 at 1:45 PM, Ming Lei <ming.lei@canonical.com> wrote:
> Hi,
>
> On Thu, Jan 19, 2012 at 7:34 PM, stephane eranian
> <eranian@googlemail.com> wrote:
>> Hi,
>>
>> Ok some update on this.
>> With your .config file + 3.2.0 (Linus) + patch 3, 4, 5, 6, I get a kernel that
>
> You forget patch 1 and patch 2?
>
They are already in 3.2.0. Unless I am mistaken.

are you sure you don't have anything else applied?

>> boots. It does recognize the PMU. However, it still does not count correctly
>> and I believe for the same reason.: no interrupts are delivered.
>>
>> I run a cycle burner program on CPU0, I watch /proc/interrupts.
>> and then I run ?libpfm4 program that does per-cpu monitoring on CPU0 and
>> print the counts every second:
>
> I just run 'perf top', then watch output of '/proc/interrupts' in
> another terminal. I am sure I can see perf is OK and interrupts are
> generated on my pandaboard.
>
>>
>> $ sudo ./syst_count -d 10 -p -c 0 -e cpu_cycles
>> <press CTRL-C to quit before 10s time limit>
>> # 1s -----
>> CPU0 ? G0 ?1008129147 ? ? ? ? ? cpu_cycles (scaling 0.00%,
>> ena=1000152588, run=1000152588)
>> # 2s -----
>> CPU0 ? G0 ?2016240766 ? ? ? ? ? cpu_cycles (scaling 0.00%,
>> ena=2000335693, run=2000335693)
>> # 3s -----
>> CPU0 ? G0 ?3024249265 ? ? ? ? ? cpu_cycles (scaling 0.00%,
>> ena=3000427245, run=3000427245)
>> # 4s -----
>> CPU0 ? G0 ?4072779364 ? ? ? ? ? cpu_cycles (scaling 0.00%,
>> ena=4040710449, run=4040710449)
>> # 5s -----
>> CPU0 ? G0 ?785954705 ? ? ? ? ? ?cpu_cycles (scaling 0.00%,
>> ena=5040954589, run=5040954589)
>> # 6s -----
>> CPU0 ? G0 ?1803397848 ? ? ? ? ? cpu_cycles (scaling 0.00%,
>> ena=6050384520, run=6050384520)
>> # 7s -----
>>
>> You clearly see that after 4s you've reached the 32-bit limit of the
>> counter and then you wrap around.
>> It should show 5 billions or so cycles. Over the entire run, no
>> arm-pmu interrupt was delivered according
>> to /proc/interrupts.
>>
>> I guess you can test the same condition using perf directly, use a
>> program that burns cycles
>> for a know duration. Try < 4s and then > 4s. I use 1s vs. 10s and I
>> expect the count to be
>> 10x larger in the latter test case. If it's not then, interrupts are
>> not coming in,
>>
>>
>> On Thu, Jan 19, 2012 at 2:21 AM, Ming Lei <ming.lei@canonical.com> wrote:
>>> Hi,
>>>
>>> On Thu, Jan 19, 2012 at 5:58 AM, stephane eranian
>>> <eranian@googlemail.com> wrote:
>>>> Ming,
>>>>
>>>> Ok, so I used Linus' tree @
>>>>
>>>> It already includes patches #1 and #2. I applied 4-6.
>>>
>>> The patch #3 is missed?
>>>
>>>> Recompiled but my kernel does not boot, I don't see
>>>> anything on the serial console. Could be a broken
>>>
>>> I don't think that the patches can cause your non boot, you
>>> can try the linus tree kernel first, then try the patches.
>>>
>>>> .config file. Could you send me your .config for Panda?
>>>
>>> See the attachment.
>>>
>>>>
>>>> Thanks.
>>>>
>>>> On Wed, Jan 18, 2012 at 11:07 AM, Ming Lei <ming.lei@canonical.com> wrote:
>>>>> Hi,
>>>>>
>>>>> On Wed, Jan 18, 2012 at 5:54 PM, stephane eranian <eranian@googlemail.com>
>>>>>> Should I use Will's -next tree as the base instead of Linus'?
>>>>>
>>>>> Either one is OK. If you use linus tree as base, you need to apply the #1 and
>>>>> #2 patch manually.
>>>>>
>>>>>> Given that MARC is shutdown today, would you mind packing those patches
>>>>>> into a tarball and sending them to me directly?
>>>>>
>>>>> See attachment, which includes the patches from #3 to #6.
>>>>>
>>>>>>
>>>>>> When you mention Will's -next tree, are you talking about:
>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git for-next/perf
>>>>>
>>>>> It is perf/omap4 brach, you can pick up the two patches[1][2] directly from
>>>>> the branch.
>>>>>
>>>>>
>>>>> thanks,
>>>>> --
>>>>> Ming Lei
>>>>>
>>>>> [1], http://git.kernel.org/?p=linux/kernel/git/will/linux.git;a=commit;h=7924a3eba0766348d6d6a56cbb9873cdbcab0d8c
>>>>>
>>>>> [2], http://git.kernel.org/?p=linux/kernel/git/will/linux.git;a=commit;h=bde071f005e2dc71378aff69e86b961d8cd7922f
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>>>> the body of a message to majordomo at vger.kernel.org
>>>> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at ?http://vger.kernel.org/majordomo-info.html

Re: oprofile and ARM A9 hardware counter

[stephane eranian]

On Thu, Jan 19, 2012 at 1:51 PM, stephane eranian
<eranian@googlemail.com> wrote:
> On Thu, Jan 19, 2012 at 1:45 PM, Ming Lei <ming.lei@canonical.com> wrote:
>> Hi,
>>
>> On Thu, Jan 19, 2012 at 7:34 PM, stephane eranian
>> <eranian@googlemail.com> wrote:
>>> Hi,
>>>
>>> Ok some update on this.
>>> With your .config file + 3.2.0 (Linus) + patch 3, 4, 5, 6, I get a kernel that
>>
>> You forget patch 1 and patch 2?
>>
> They are already in 3.2.0. Unless I am mistaken.
>
e0516a6 arm: pmu: allow platform specific irq enable/disable handling
14eec97 arm: introduce cross trigger interface helpers

> are you sure you don't have anything else applied?
>
>>> boots. It does recognize the PMU. However, it still does not count correctly
>>> and I believe for the same reason.: no interrupts are delivered.
>>>
>>> I run a cycle burner program on CPU0, I watch /proc/interrupts.
>>> and then I run  libpfm4 program that does per-cpu monitoring on CPU0 and
>>> print the counts every second:
>>
>> I just run 'perf top', then watch output of '/proc/interrupts' in
>> another terminal. I am sure I can see perf is OK and interrupts are
>> generated on my pandaboard.
>>
>>>
>>> $ sudo ./syst_count -d 10 -p -c 0 -e cpu_cycles
>>> <press CTRL-C to quit before 10s time limit>
>>> # 1s -----
>>> CPU0   G0  1008129147           cpu_cycles (scaling 0.00%,
>>> ena=1000152588, run=1000152588)
>>> # 2s -----
>>> CPU0   G0  2016240766           cpu_cycles (scaling 0.00%,
>>> ena=2000335693, run=2000335693)
>>> # 3s -----
>>> CPU0   G0  3024249265           cpu_cycles (scaling 0.00%,
>>> ena=3000427245, run=3000427245)
>>> # 4s -----
>>> CPU0   G0  4072779364           cpu_cycles (scaling 0.00%,
>>> ena=4040710449, run=4040710449)
>>> # 5s -----
>>> CPU0   G0  785954705            cpu_cycles (scaling 0.00%,
>>> ena=5040954589, run=5040954589)
>>> # 6s -----
>>> CPU0   G0  1803397848           cpu_cycles (scaling 0.00%,
>>> ena=6050384520, run=6050384520)
>>> # 7s -----
>>>
>>> You clearly see that after 4s you've reached the 32-bit limit of the
>>> counter and then you wrap around.
>>> It should show 5 billions or so cycles. Over the entire run, no
>>> arm-pmu interrupt was delivered according
>>> to /proc/interrupts.
>>>
>>> I guess you can test the same condition using perf directly, use a
>>> program that burns cycles
>>> for a know duration. Try < 4s and then > 4s. I use 1s vs. 10s and I
>>> expect the count to be
>>> 10x larger in the latter test case. If it's not then, interrupts are
>>> not coming in,
>>>
>>>
>>> On Thu, Jan 19, 2012 at 2:21 AM, Ming Lei <ming.lei@canonical.com> wrote:
>>>> Hi,
>>>>
>>>> On Thu, Jan 19, 2012 at 5:58 AM, stephane eranian
>>>> <eranian@googlemail.com> wrote:
>>>>> Ming,
>>>>>
>>>>> Ok, so I used Linus' tree @
>>>>>
>>>>> It already includes patches #1 and #2. I applied 4-6.
>>>>
>>>> The patch #3 is missed?
>>>>
>>>>> Recompiled but my kernel does not boot, I don't see
>>>>> anything on the serial console. Could be a broken
>>>>
>>>> I don't think that the patches can cause your non boot, you
>>>> can try the linus tree kernel first, then try the patches.
>>>>
>>>>> .config file. Could you send me your .config for Panda?
>>>>
>>>> See the attachment.
>>>>
>>>>>
>>>>> Thanks.
>>>>>
>>>>> On Wed, Jan 18, 2012 at 11:07 AM, Ming Lei <ming.lei@canonical.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On Wed, Jan 18, 2012 at 5:54 PM, stephane eranian <eranian@googlemail.com>
>>>>>>> Should I use Will's -next tree as the base instead of Linus'?
>>>>>>
>>>>>> Either one is OK. If you use linus tree as base, you need to apply the #1 and
>>>>>> #2 patch manually.
>>>>>>
>>>>>>> Given that MARC is shutdown today, would you mind packing those patches
>>>>>>> into a tarball and sending them to me directly?
>>>>>>
>>>>>> See attachment, which includes the patches from #3 to #6.
>>>>>>
>>>>>>>
>>>>>>> When you mention Will's -next tree, are you talking about:
>>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git for-next/perf
>>>>>>
>>>>>> It is perf/omap4 brach, you can pick up the two patches[1][2] directly from
>>>>>> the branch.
>>>>>>
>>>>>>
>>>>>> thanks,
>>>>>> --
>>>>>> Ming Lei
>>>>>>
>>>>>> [1], http://git.kernel.org/?p=linux/kernel/git/will/linux.git;a=commit;h=7924a3eba0766348d6d6a56cbb9873cdbcab0d8c
>>>>>>
>>>>>> [2], http://git.kernel.org/?p=linux/kernel/git/will/linux.git;a=commit;h=bde071f005e2dc71378aff69e86b961d8cd7922f
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>>>>> the body of a message to majordomo@vger.kernel.org
>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

oprofile and ARM A9 hardware counter

[stephane eranian]

On Thu, Jan 19, 2012 at 1:51 PM, stephane eranian
<eranian@googlemail.com> wrote:
> On Thu, Jan 19, 2012 at 1:45 PM, Ming Lei <ming.lei@canonical.com> wrote:
>> Hi,
>>
>> On Thu, Jan 19, 2012 at 7:34 PM, stephane eranian
>> <eranian@googlemail.com> wrote:
>>> Hi,
>>>
>>> Ok some update on this.
>>> With your .config file + 3.2.0 (Linus) + patch 3, 4, 5, 6, I get a kernel that
>>
>> You forget patch 1 and patch 2?
>>
> They are already in 3.2.0. Unless I am mistaken.
>
e0516a6 arm: pmu: allow platform specific irq enable/disable handling
14eec97 arm: introduce cross trigger interface helpers

> are you sure you don't have anything else applied?
>
>>> boots. It does recognize the PMU. However, it still does not count correctly
>>> and I believe for the same reason.: no interrupts are delivered.
>>>
>>> I run a cycle burner program on CPU0, I watch /proc/interrupts.
>>> and then I run ?libpfm4 program that does per-cpu monitoring on CPU0 and
>>> print the counts every second:
>>
>> I just run 'perf top', then watch output of '/proc/interrupts' in
>> another terminal. I am sure I can see perf is OK and interrupts are
>> generated on my pandaboard.
>>
>>>
>>> $ sudo ./syst_count -d 10 -p -c 0 -e cpu_cycles
>>> <press CTRL-C to quit before 10s time limit>
>>> # 1s -----
>>> CPU0 ? G0 ?1008129147 ? ? ? ? ? cpu_cycles (scaling 0.00%,
>>> ena=1000152588, run=1000152588)
>>> # 2s -----
>>> CPU0 ? G0 ?2016240766 ? ? ? ? ? cpu_cycles (scaling 0.00%,
>>> ena=2000335693, run=2000335693)
>>> # 3s -----
>>> CPU0 ? G0 ?3024249265 ? ? ? ? ? cpu_cycles (scaling 0.00%,
>>> ena=3000427245, run=3000427245)
>>> # 4s -----
>>> CPU0 ? G0 ?4072779364 ? ? ? ? ? cpu_cycles (scaling 0.00%,
>>> ena=4040710449, run=4040710449)
>>> # 5s -----
>>> CPU0 ? G0 ?785954705 ? ? ? ? ? ?cpu_cycles (scaling 0.00%,
>>> ena=5040954589, run=5040954589)
>>> # 6s -----
>>> CPU0 ? G0 ?1803397848 ? ? ? ? ? cpu_cycles (scaling 0.00%,
>>> ena=6050384520, run=6050384520)
>>> # 7s -----
>>>
>>> You clearly see that after 4s you've reached the 32-bit limit of the
>>> counter and then you wrap around.
>>> It should show 5 billions or so cycles. Over the entire run, no
>>> arm-pmu interrupt was delivered according
>>> to /proc/interrupts.
>>>
>>> I guess you can test the same condition using perf directly, use a
>>> program that burns cycles
>>> for a know duration. Try < 4s and then > 4s. I use 1s vs. 10s and I
>>> expect the count to be
>>> 10x larger in the latter test case. If it's not then, interrupts are
>>> not coming in,
>>>
>>>
>>> On Thu, Jan 19, 2012 at 2:21 AM, Ming Lei <ming.lei@canonical.com> wrote:
>>>> Hi,
>>>>
>>>> On Thu, Jan 19, 2012 at 5:58 AM, stephane eranian
>>>> <eranian@googlemail.com> wrote:
>>>>> Ming,
>>>>>
>>>>> Ok, so I used Linus' tree @
>>>>>
>>>>> It already includes patches #1 and #2. I applied 4-6.
>>>>
>>>> The patch #3 is missed?
>>>>
>>>>> Recompiled but my kernel does not boot, I don't see
>>>>> anything on the serial console. Could be a broken
>>>>
>>>> I don't think that the patches can cause your non boot, you
>>>> can try the linus tree kernel first, then try the patches.
>>>>
>>>>> .config file. Could you send me your .config for Panda?
>>>>
>>>> See the attachment.
>>>>
>>>>>
>>>>> Thanks.
>>>>>
>>>>> On Wed, Jan 18, 2012 at 11:07 AM, Ming Lei <ming.lei@canonical.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On Wed, Jan 18, 2012 at 5:54 PM, stephane eranian <eranian@googlemail.com>
>>>>>>> Should I use Will's -next tree as the base instead of Linus'?
>>>>>>
>>>>>> Either one is OK. If you use linus tree as base, you need to apply the #1 and
>>>>>> #2 patch manually.
>>>>>>
>>>>>>> Given that MARC is shutdown today, would you mind packing those patches
>>>>>>> into a tarball and sending them to me directly?
>>>>>>
>>>>>> See attachment, which includes the patches from #3 to #6.
>>>>>>
>>>>>>>
>>>>>>> When you mention Will's -next tree, are you talking about:
>>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git for-next/perf
>>>>>>
>>>>>> It is perf/omap4 brach, you can pick up the two patches[1][2] directly from
>>>>>> the branch.
>>>>>>
>>>>>>
>>>>>> thanks,
>>>>>> --
>>>>>> Ming Lei
>>>>>>
>>>>>> [1], http://git.kernel.org/?p=linux/kernel/git/will/linux.git;a=commit;h=7924a3eba0766348d6d6a56cbb9873cdbcab0d8c
>>>>>>
>>>>>> [2], http://git.kernel.org/?p=linux/kernel/git/will/linux.git;a=commit;h=bde071f005e2dc71378aff69e86b961d8cd7922f
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>>>>> the body of a message to majordomo at vger.kernel.org
>>>>> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>>> the body of a message to majordomo at vger.kernel.org
>>> More majordomo info at ?http://vger.kernel.org/majordomo-info.html

Re: oprofile and ARM A9 hardware counter

[Ming Lei]

On Thu, Jan 19, 2012 at 8:51 PM, stephane eranian
<eranian@googlemail.com> wrote:
> On Thu, Jan 19, 2012 at 1:45 PM, Ming Lei <ming.lei@canonical.com> wrote:
>> Hi,
>>
>> On Thu, Jan 19, 2012 at 7:34 PM, stephane eranian
>> <eranian@googlemail.com> wrote:
>>> Hi,
>>>
>>> Ok some update on this.
>>> With your .config file + 3.2.0 (Linus) + patch 3, 4, 5, 6, I get a kernel that
>>
>> You forget patch 1 and patch 2?
>>
> They are already in 3.2.0. Unless I am mistaken.

Sorry, I just found that they have been merged to 3.2.

>
> are you sure you don't have anything else applied?

Yes, I am sure, maybe it is caused by uboot and mlo, I will email them
to you in private mail.

thanks,
--
Ming Lei

oprofile and ARM A9 hardware counter

[Ming Lei]

On Thu, Jan 19, 2012 at 8:51 PM, stephane eranian
<eranian@googlemail.com> wrote:
> On Thu, Jan 19, 2012 at 1:45 PM, Ming Lei <ming.lei@canonical.com> wrote:
>> Hi,
>>
>> On Thu, Jan 19, 2012 at 7:34 PM, stephane eranian
>> <eranian@googlemail.com> wrote:
>>> Hi,
>>>
>>> Ok some update on this.
>>> With your .config file + 3.2.0 (Linus) + patch 3, 4, 5, 6, I get a kernel that
>>
>> You forget patch 1 and patch 2?
>>
> They are already in 3.2.0. Unless I am mistaken.

Sorry, I just found that they have been merged to 3.2.

>
> are you sure you don't have anything else applied?

Yes, I am sure, maybe it is caused by uboot and mlo, I will email them
to you in private mail.

thanks,
--
Ming Lei

Re: oprofile and ARM A9 hardware counter

[Ming Lei]

Hi,

On Thu, Jan 19, 2012 at 9:14 PM, Ming Lei <ming.lei@canonical.com> wrote:
> On Thu, Jan 19, 2012 at 8:51 PM, stephane eranian
> <eranian@googlemail.com> wrote:
>> On Thu, Jan 19, 2012 at 1:45 PM, Ming Lei <ming.lei@canonical.com> wrote:
>>> Hi,
>>>
>>> On Thu, Jan 19, 2012 at 7:34 PM, stephane eranian
>>> <eranian@googlemail.com> wrote:
>>>> Hi,
>>>>
>>>> Ok some update on this.
>>>> With your .config file + 3.2.0 (Linus) + patch 3, 4, 5, 6, I get a kernel that
>>>
>>> You forget patch 1 and patch 2?
>>>
>> They are already in 3.2.0. Unless I am mistaken.
>
> Sorry, I just found that they have been merged to 3.2.

After a double check, the two patches are not merged to 3.2, but have
been merged to the latest linus tree and can be seen in 3.3-rc1.

Also the commit 3c50729b(ARM: OMAP4: PM: Initialise all the clockdomains
to supported states) has been merged to linus tree too.

So if you just tested the latest linus tree simply, you need to apply
the patch[1]
(I have mentioned the problem in the thread.)

thanks,
--
Ming Lei

[1],
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,
 };

 static struct clockdomain l3_dma_44xx_clkdm = {

oprofile and ARM A9 hardware counter

[Ming Lei]

Hi,

On Thu, Jan 19, 2012 at 9:14 PM, Ming Lei <ming.lei@canonical.com> wrote:
> On Thu, Jan 19, 2012 at 8:51 PM, stephane eranian
> <eranian@googlemail.com> wrote:
>> On Thu, Jan 19, 2012 at 1:45 PM, Ming Lei <ming.lei@canonical.com> wrote:
>>> Hi,
>>>
>>> On Thu, Jan 19, 2012 at 7:34 PM, stephane eranian
>>> <eranian@googlemail.com> wrote:
>>>> Hi,
>>>>
>>>> Ok some update on this.
>>>> With your .config file + 3.2.0 (Linus) + patch 3, 4, 5, 6, I get a kernel that
>>>
>>> You forget patch 1 and patch 2?
>>>
>> They are already in 3.2.0. Unless I am mistaken.
>
> Sorry, I just found that they have been merged to 3.2.

After a double check, the two patches are not merged to 3.2, but have
been merged to the latest linus tree and can be seen in 3.3-rc1.

Also the commit 3c50729b(ARM: OMAP4: PM: Initialise all the clockdomains
to supported states) has been merged to linus tree too.

So if you just tested the latest linus tree simply, you need to apply
the patch[1]
(I have mentioned the problem in the thread.)

thanks,
--
Ming Lei

[1],
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,
 };

 static struct clockdomain l3_dma_44xx_clkdm = {

Re: oprofile and ARM A9 hardware counter

[stephane eranian]

On Thu, Jan 19, 2012 at 2:26 PM, Ming Lei <ming.lei@canonical.com> wrote:
> Hi,
>
> On Thu, Jan 19, 2012 at 9:14 PM, Ming Lei <ming.lei@canonical.com> wrote:
>> On Thu, Jan 19, 2012 at 8:51 PM, stephane eranian
>> <eranian@googlemail.com> wrote:
>>> On Thu, Jan 19, 2012 at 1:45 PM, Ming Lei <ming.lei@canonical.com> wrote:
>>>> Hi,
>>>>
>>>> On Thu, Jan 19, 2012 at 7:34 PM, stephane eranian
>>>> <eranian@googlemail.com> wrote:
>>>>> Hi,
>>>>>
>>>>> Ok some update on this.
>>>>> With your .config file + 3.2.0 (Linus) + patch 3, 4, 5, 6, I get a kernel that
>>>>
>>>> You forget patch 1 and patch 2?
>>>>
>>> They are already in 3.2.0. Unless I am mistaken.
>>
>> Sorry, I just found that they have been merged to 3.2.
>
> After a double check, the two patches are not merged to 3.2, but have
> been merged to the latest linus tree and can be seen in 3.3-rc1.
>
> Also the commit 3c50729b(ARM: OMAP4: PM: Initialise all the clockdomains
> to supported states) has been merged to linus tree too.
>
> So if you just tested the latest linus tree simply, you need to apply
> the patch[1]
> (I have mentioned the problem in the thread.)
>

Changing LMO, u-boot.bin did not help. Even with perf top I get no
interrupts.

My Linus tree is at commit fa1952b:

[6] 11891e1 arm: omap4: pmu: support runtime pm
[5] 25fab8a arm: omap4: support pmu
[4] fddef77 arm: omap4: create pmu device via hwmod

fa1952b ARM: OMAP4: hwmod data: Add support for the debug modules
ccb19d2 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
c3b5003 tg3: Fix single-vector MSI-X code

I think [1] had conflicts when applying it to the tree.

> thanks,
> --
> Ming Lei
>
> [1],
> 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,
>  };
>
>  static struct clockdomain l3_dma_44xx_clkdm = {
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

oprofile and ARM A9 hardware counter

[stephane eranian]

On Thu, Jan 19, 2012 at 2:26 PM, Ming Lei <ming.lei@canonical.com> wrote:
> Hi,
>
> On Thu, Jan 19, 2012 at 9:14 PM, Ming Lei <ming.lei@canonical.com> wrote:
>> On Thu, Jan 19, 2012 at 8:51 PM, stephane eranian
>> <eranian@googlemail.com> wrote:
>>> On Thu, Jan 19, 2012 at 1:45 PM, Ming Lei <ming.lei@canonical.com> wrote:
>>>> Hi,
>>>>
>>>> On Thu, Jan 19, 2012 at 7:34 PM, stephane eranian
>>>> <eranian@googlemail.com> wrote:
>>>>> Hi,
>>>>>
>>>>> Ok some update on this.
>>>>> With your .config file + 3.2.0 (Linus) + patch 3, 4, 5, 6, I get a kernel that
>>>>
>>>> You forget patch 1 and patch 2?
>>>>
>>> They are already in 3.2.0. Unless I am mistaken.
>>
>> Sorry, I just found that they have been merged to 3.2.
>
> After a double check, the two patches are not merged to 3.2, but have
> been merged to the latest linus tree and can be seen in 3.3-rc1.
>
> Also the commit 3c50729b(ARM: OMAP4: PM: Initialise all the clockdomains
> to supported states) has been merged to linus tree too.
>
> So if you just tested the latest linus tree simply, you need to apply
> the patch[1]
> (I have mentioned the problem in the thread.)
>

Changing LMO, u-boot.bin did not help. Even with perf top I get no
interrupts.

My Linus tree is at commit fa1952b:

[6] 11891e1 arm: omap4: pmu: support runtime pm
[5] 25fab8a arm: omap4: support pmu
[4] fddef77 arm: omap4: create pmu device via hwmod

fa1952b ARM: OMAP4: hwmod data: Add support for the debug modules
ccb19d2 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
c3b5003 tg3: Fix single-vector MSI-X code

I think [1] had conflicts when applying it to the tree.

> thanks,
> --
> Ming Lei
>
> [1],
> 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,
> ?};
>
> ?static struct clockdomain l3_dma_44xx_clkdm = {

Re: oprofile and ARM A9 hardware counter

[Ming Lei]

Hi,

On Thu, Jan 19, 2012 at 9:32 PM, stephane eranian
<eranian@googlemail.com> wrote:
> On Thu, Jan 19, 2012 at 2:26 PM, Ming Lei <ming.lei@canonical.com> wrote:
>> Hi,
>>
>> On Thu, Jan 19, 2012 at 9:14 PM, Ming Lei <ming.lei@canonical.com> wrote:
>>> On Thu, Jan 19, 2012 at 8:51 PM, stephane eranian
>>> <eranian@googlemail.com> wrote:
>>>> On Thu, Jan 19, 2012 at 1:45 PM, Ming Lei <ming.lei@canonical.com> wrote:
>>>>> Hi,
>>>>>
>>>>> On Thu, Jan 19, 2012 at 7:34 PM, stephane eranian
>>>>> <eranian@googlemail.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Ok some update on this.
>>>>>> With your .config file + 3.2.0 (Linus) + patch 3, 4, 5, 6, I get a kernel that
>>>>>
>>>>> You forget patch 1 and patch 2?
>>>>>
>>>> They are already in 3.2.0. Unless I am mistaken.
>>>
>>> Sorry, I just found that they have been merged to 3.2.
>>
>> After a double check, the two patches are not merged to 3.2, but have
>> been merged to the latest linus tree and can be seen in 3.3-rc1.
>>
>> Also the commit 3c50729b(ARM: OMAP4: PM: Initialise all the clockdomains
>> to supported states) has been merged to linus tree too.
>>
>> So if you just tested the latest linus tree simply, you need to apply
>> the patch[1]
>> (I have mentioned the problem in the thread.)
>>
>
> Changing LMO, u-boot.bin did not help. Even with perf top I get no
> interrupts.
>
> My Linus tree is at commit fa1952b:
>
> [6] 11891e1 arm: omap4: pmu: support runtime pm
> [5] 25fab8a arm: omap4: support pmu
> [4] fddef77 arm: omap4: create pmu device via hwmod
>
> fa1952b ARM: OMAP4: hwmod data: Add support for the debug modules

Sorry, there is no commit fa1952b in linus[1] tree at all, so you are
not testing
linus tree...

If you'd like to follow my instructions, I can help you further.

> ccb19d2 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
> c3b5003 tg3: Fix single-vector MSI-X code
>
> I think [1] had conflicts when applying it to the tree.

It is only one line(one character) change, you can do it manually.

>
>> thanks,
>> --
>> Ming Lei
>>
>> [1],
>> 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,
>>  };
>>

[1], http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=summary

thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

oprofile and ARM A9 hardware counter

[Ming Lei]

Hi,

On Thu, Jan 19, 2012 at 9:32 PM, stephane eranian
<eranian@googlemail.com> wrote:
> On Thu, Jan 19, 2012 at 2:26 PM, Ming Lei <ming.lei@canonical.com> wrote:
>> Hi,
>>
>> On Thu, Jan 19, 2012 at 9:14 PM, Ming Lei <ming.lei@canonical.com> wrote:
>>> On Thu, Jan 19, 2012 at 8:51 PM, stephane eranian
>>> <eranian@googlemail.com> wrote:
>>>> On Thu, Jan 19, 2012 at 1:45 PM, Ming Lei <ming.lei@canonical.com> wrote:
>>>>> Hi,
>>>>>
>>>>> On Thu, Jan 19, 2012 at 7:34 PM, stephane eranian
>>>>> <eranian@googlemail.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Ok some update on this.
>>>>>> With your .config file + 3.2.0 (Linus) + patch 3, 4, 5, 6, I get a kernel that
>>>>>
>>>>> You forget patch 1 and patch 2?
>>>>>
>>>> They are already in 3.2.0. Unless I am mistaken.
>>>
>>> Sorry, I just found that they have been merged to 3.2.
>>
>> After a double check, the two patches are not merged to 3.2, but have
>> been merged to the latest linus tree and can be seen in 3.3-rc1.
>>
>> Also the commit 3c50729b(ARM: OMAP4: PM: Initialise all the clockdomains
>> to supported states) has been merged to linus tree too.
>>
>> So if you just tested the latest linus tree simply, you need to apply
>> the patch[1]
>> (I have mentioned the problem in the thread.)
>>
>
> Changing LMO, u-boot.bin did not help. Even with perf top I get no
> interrupts.
>
> My Linus tree is at commit fa1952b:
>
> [6] 11891e1 arm: omap4: pmu: support runtime pm
> [5] 25fab8a arm: omap4: support pmu
> [4] fddef77 arm: omap4: create pmu device via hwmod
>
> fa1952b ARM: OMAP4: hwmod data: Add support for the debug modules

Sorry, there is no commit fa1952b in linus[1] tree at all, so you are
not testing
linus tree...

If you'd like to follow my instructions, I can help you further.

> ccb19d2 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
> c3b5003 tg3: Fix single-vector MSI-X code
>
> I think [1] had conflicts when applying it to the tree.

It is only one line(one character) change, you can do it manually.

>
>> thanks,
>> --
>> Ming Lei
>>
>> [1],
>> 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,
>> ?};
>>

[1], http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=summary

thanks,
--
Ming Lei

Re: oprofile and ARM A9 hardware counter

[stephane eranian]

Just did a fresh clone of Linus' tree:

$ git log --oneline | fgrep 'allow platform specific'
e0516a6 arm: pmu: allow platform specific irq enable/disable handling

$ git log --oneline | fgrep 'cross trigger'
14eec97 arm: introduce cross trigger interface helpers

Unless you were referring to a different pair of patches.


On Thu, Jan 19, 2012 at 2:51 PM, Ming Lei <ming.lei@canonical.com> wrote:
> Hi,
>
> On Thu, Jan 19, 2012 at 9:32 PM, stephane eranian
> <eranian@googlemail.com> wrote:
>> On Thu, Jan 19, 2012 at 2:26 PM, Ming Lei <ming.lei@canonical.com> wrote:
>>> Hi,
>>>
>>> On Thu, Jan 19, 2012 at 9:14 PM, Ming Lei <ming.lei@canonical.com> wrote:
>>>> On Thu, Jan 19, 2012 at 8:51 PM, stephane eranian
>>>> <eranian@googlemail.com> wrote:
>>>>> On Thu, Jan 19, 2012 at 1:45 PM, Ming Lei <ming.lei@canonical.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On Thu, Jan 19, 2012 at 7:34 PM, stephane eranian
>>>>>> <eranian@googlemail.com> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Ok some update on this.
>>>>>>> With your .config file + 3.2.0 (Linus) + patch 3, 4, 5, 6, I get a kernel that
>>>>>>
>>>>>> You forget patch 1 and patch 2?
>>>>>>
>>>>> They are already in 3.2.0. Unless I am mistaken.
>>>>
>>>> Sorry, I just found that they have been merged to 3.2.
>>>
>>> After a double check, the two patches are not merged to 3.2, but have
>>> been merged to the latest linus tree and can be seen in 3.3-rc1.
>>>
>>> Also the commit 3c50729b(ARM: OMAP4: PM: Initialise all the clockdomains
>>> to supported states) has been merged to linus tree too.
>>>
>>> So if you just tested the latest linus tree simply, you need to apply
>>> the patch[1]
>>> (I have mentioned the problem in the thread.)
>>>
>>
>> Changing LMO, u-boot.bin did not help. Even with perf top I get no
>> interrupts.
>>
>> My Linus tree is at commit fa1952b:
>>
>> [6] 11891e1 arm: omap4: pmu: support runtime pm
>> [5] 25fab8a arm: omap4: support pmu
>> [4] fddef77 arm: omap4: create pmu device via hwmod
>>
>> fa1952b ARM: OMAP4: hwmod data: Add support for the debug modules
>
> Sorry, there is no commit fa1952b in linus[1] tree at all, so you are
> not testing
> linus tree...
>
> If you'd like to follow my instructions, I can help you further.
>
>> ccb19d2 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
>> c3b5003 tg3: Fix single-vector MSI-X code
>>
>> I think [1] had conflicts when applying it to the tree.
>
> It is only one line(one character) change, you can do it manually.
>
>>
>>> thanks,
>>> --
>>> Ming Lei
>>>
>>> [1],
>>> 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,
>>>  };
>>>
>
> [1], http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=summary
>
> thanks,
> --
> Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

oprofile and ARM A9 hardware counter

[stephane eranian]

Just did a fresh clone of Linus' tree:

$ git log --oneline | fgrep 'allow platform specific'
e0516a6 arm: pmu: allow platform specific irq enable/disable handling

$ git log --oneline | fgrep 'cross trigger'
14eec97 arm: introduce cross trigger interface helpers

Unless you were referring to a different pair of patches.


On Thu, Jan 19, 2012 at 2:51 PM, Ming Lei <ming.lei@canonical.com> wrote:
> Hi,
>
> On Thu, Jan 19, 2012 at 9:32 PM, stephane eranian
> <eranian@googlemail.com> wrote:
>> On Thu, Jan 19, 2012 at 2:26 PM, Ming Lei <ming.lei@canonical.com> wrote:
>>> Hi,
>>>
>>> On Thu, Jan 19, 2012 at 9:14 PM, Ming Lei <ming.lei@canonical.com> wrote:
>>>> On Thu, Jan 19, 2012 at 8:51 PM, stephane eranian
>>>> <eranian@googlemail.com> wrote:
>>>>> On Thu, Jan 19, 2012 at 1:45 PM, Ming Lei <ming.lei@canonical.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On Thu, Jan 19, 2012 at 7:34 PM, stephane eranian
>>>>>> <eranian@googlemail.com> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Ok some update on this.
>>>>>>> With your .config file + 3.2.0 (Linus) + patch 3, 4, 5, 6, I get a kernel that
>>>>>>
>>>>>> You forget patch 1 and patch 2?
>>>>>>
>>>>> They are already in 3.2.0. Unless I am mistaken.
>>>>
>>>> Sorry, I just found that they have been merged to 3.2.
>>>
>>> After a double check, the two patches are not merged to 3.2, but have
>>> been merged to the latest linus tree and can be seen in 3.3-rc1.
>>>
>>> Also the commit 3c50729b(ARM: OMAP4: PM: Initialise all the clockdomains
>>> to supported states) has been merged to linus tree too.
>>>
>>> So if you just tested the latest linus tree simply, you need to apply
>>> the patch[1]
>>> (I have mentioned the problem in the thread.)
>>>
>>
>> Changing LMO, u-boot.bin did not help. Even with perf top I get no
>> interrupts.
>>
>> My Linus tree is at commit fa1952b:
>>
>> [6] 11891e1 arm: omap4: pmu: support runtime pm
>> [5] 25fab8a arm: omap4: support pmu
>> [4] fddef77 arm: omap4: create pmu device via hwmod
>>
>> fa1952b ARM: OMAP4: hwmod data: Add support for the debug modules
>
> Sorry, there is no commit fa1952b in linus[1] tree at all, so you are
> not testing
> linus tree...
>
> If you'd like to follow my instructions, I can help you further.
>
>> ccb19d2 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
>> c3b5003 tg3: Fix single-vector MSI-X code
>>
>> I think [1] had conflicts when applying it to the tree.
>
> It is only one line(one character) change, you can do it manually.
>
>>
>>> thanks,
>>> --
>>> Ming Lei
>>>
>>> [1],
>>> 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,
>>> ?};
>>>
>
> [1], http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=summary
>
> thanks,
> --
> Ming Lei

Re: oprofile and ARM A9 hardware counter

[stephane eranian]

Started afresh from:

90a4c0f uml: fix compile for x86-64

And added 3, 4, 5, 6:
603c316 arm: omap4: pmu: support runtime pm
4899fbd arm: omap4: support pmu
d737bb1 arm: omap4: create pmu device via hwmod
4e0259e arm: omap4: hwmod: introduce emu hwmod

Still no interrupts firing. I am using your .config file.

My HW:
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x1
CPU part	: 0xc09
CPU revision	: 2

Hardware	: OMAP4 Panda board
Revision	: 0020

There must be something I am missing here.



On Thu, Jan 19, 2012 at 6:07 PM, stephane eranian
<eranian@googlemail.com> wrote:
> Just did a fresh clone of Linus' tree:
>
> $ git log --oneline | fgrep 'allow platform specific'
> e0516a6 arm: pmu: allow platform specific irq enable/disable handling
>
> $ git log --oneline | fgrep 'cross trigger'
> 14eec97 arm: introduce cross trigger interface helpers
>
> Unless you were referring to a different pair of patches.
>
>
> On Thu, Jan 19, 2012 at 2:51 PM, Ming Lei <ming.lei@canonical.com> wrote:
>> Hi,
>>
>> On Thu, Jan 19, 2012 at 9:32 PM, stephane eranian
>> <eranian@googlemail.com> wrote:
>>> On Thu, Jan 19, 2012 at 2:26 PM, Ming Lei <ming.lei@canonical.com> wrote:
>>>> Hi,
>>>>
>>>> On Thu, Jan 19, 2012 at 9:14 PM, Ming Lei <ming.lei@canonical.com> wrote:
>>>>> On Thu, Jan 19, 2012 at 8:51 PM, stephane eranian
>>>>> <eranian@googlemail.com> wrote:
>>>>>> On Thu, Jan 19, 2012 at 1:45 PM, Ming Lei <ming.lei@canonical.com> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On Thu, Jan 19, 2012 at 7:34 PM, stephane eranian
>>>>>>> <eranian@googlemail.com> wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Ok some update on this.
>>>>>>>> With your .config file + 3.2.0 (Linus) + patch 3, 4, 5, 6, I get a kernel that
>>>>>>>
>>>>>>> You forget patch 1 and patch 2?
>>>>>>>
>>>>>> They are already in 3.2.0. Unless I am mistaken.
>>>>>
>>>>> Sorry, I just found that they have been merged to 3.2.
>>>>
>>>> After a double check, the two patches are not merged to 3.2, but have
>>>> been merged to the latest linus tree and can be seen in 3.3-rc1.
>>>>
>>>> Also the commit 3c50729b(ARM: OMAP4: PM: Initialise all the clockdomains
>>>> to supported states) has been merged to linus tree too.
>>>>
>>>> So if you just tested the latest linus tree simply, you need to apply
>>>> the patch[1]
>>>> (I have mentioned the problem in the thread.)
>>>>
>>>
>>> Changing LMO, u-boot.bin did not help. Even with perf top I get no
>>> interrupts.
>>>
>>> My Linus tree is at commit fa1952b:
>>>
>>> [6] 11891e1 arm: omap4: pmu: support runtime pm
>>> [5] 25fab8a arm: omap4: support pmu
>>> [4] fddef77 arm: omap4: create pmu device via hwmod
>>>
>>> fa1952b ARM: OMAP4: hwmod data: Add support for the debug modules
>>
>> Sorry, there is no commit fa1952b in linus[1] tree at all, so you are
>> not testing
>> linus tree...
>>
>> If you'd like to follow my instructions, I can help you further.
>>
>>> ccb19d2 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
>>> c3b5003 tg3: Fix single-vector MSI-X code
>>>
>>> I think [1] had conflicts when applying it to the tree.
>>
>> It is only one line(one character) change, you can do it manually.
>>
>>>
>>>> thanks,
>>>> --
>>>> Ming Lei
>>>>
>>>> [1],
>>>> 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,
>>>>  };
>>>>
>>
>> [1], http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=summary
>>
>> thanks,
>> --
>> Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

oprofile and ARM A9 hardware counter

[stephane eranian]

Started afresh from:

90a4c0f uml: fix compile for x86-64

And added 3, 4, 5, 6:
603c316 arm: omap4: pmu: support runtime pm
4899fbd arm: omap4: support pmu
d737bb1 arm: omap4: create pmu device via hwmod
4e0259e arm: omap4: hwmod: introduce emu hwmod

Still no interrupts firing. I am using your .config file.

My HW:
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x1
CPU part	: 0xc09
CPU revision	: 2

Hardware	: OMAP4 Panda board
Revision	: 0020

There must be something I am missing here.



On Thu, Jan 19, 2012 at 6:07 PM, stephane eranian
<eranian@googlemail.com> wrote:
> Just did a fresh clone of Linus' tree:
>
> $ git log --oneline | fgrep 'allow platform specific'
> e0516a6 arm: pmu: allow platform specific irq enable/disable handling
>
> $ git log --oneline | fgrep 'cross trigger'
> 14eec97 arm: introduce cross trigger interface helpers
>
> Unless you were referring to a different pair of patches.
>
>
> On Thu, Jan 19, 2012 at 2:51 PM, Ming Lei <ming.lei@canonical.com> wrote:
>> Hi,
>>
>> On Thu, Jan 19, 2012 at 9:32 PM, stephane eranian
>> <eranian@googlemail.com> wrote:
>>> On Thu, Jan 19, 2012 at 2:26 PM, Ming Lei <ming.lei@canonical.com> wrote:
>>>> Hi,
>>>>
>>>> On Thu, Jan 19, 2012 at 9:14 PM, Ming Lei <ming.lei@canonical.com> wrote:
>>>>> On Thu, Jan 19, 2012 at 8:51 PM, stephane eranian
>>>>> <eranian@googlemail.com> wrote:
>>>>>> On Thu, Jan 19, 2012 at 1:45 PM, Ming Lei <ming.lei@canonical.com> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On Thu, Jan 19, 2012 at 7:34 PM, stephane eranian
>>>>>>> <eranian@googlemail.com> wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Ok some update on this.
>>>>>>>> With your .config file + 3.2.0 (Linus) + patch 3, 4, 5, 6, I get a kernel that
>>>>>>>
>>>>>>> You forget patch 1 and patch 2?
>>>>>>>
>>>>>> They are already in 3.2.0. Unless I am mistaken.
>>>>>
>>>>> Sorry, I just found that they have been merged to 3.2.
>>>>
>>>> After a double check, the two patches are not merged to 3.2, but have
>>>> been merged to the latest linus tree and can be seen in 3.3-rc1.
>>>>
>>>> Also the commit 3c50729b(ARM: OMAP4: PM: Initialise all the clockdomains
>>>> to supported states) has been merged to linus tree too.
>>>>
>>>> So if you just tested the latest linus tree simply, you need to apply
>>>> the patch[1]
>>>> (I have mentioned the problem in the thread.)
>>>>
>>>
>>> Changing LMO, u-boot.bin did not help. Even with perf top I get no
>>> interrupts.
>>>
>>> My Linus tree is at commit fa1952b:
>>>
>>> [6] 11891e1 arm: omap4: pmu: support runtime pm
>>> [5] 25fab8a arm: omap4: support pmu
>>> [4] fddef77 arm: omap4: create pmu device via hwmod
>>>
>>> fa1952b ARM: OMAP4: hwmod data: Add support for the debug modules
>>
>> Sorry, there is no commit fa1952b in linus[1] tree at all, so you are
>> not testing
>> linus tree...
>>
>> If you'd like to follow my instructions, I can help you further.
>>
>>> ccb19d2 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
>>> c3b5003 tg3: Fix single-vector MSI-X code
>>>
>>> I think [1] had conflicts when applying it to the tree.
>>
>> It is only one line(one character) change, you can do it manually.
>>
>>>
>>>> thanks,
>>>> --
>>>> Ming Lei
>>>>
>>>> [1],
>>>> 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,
>>>> ?};
>>>>
>>
>> [1], http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=summary
>>
>> thanks,
>> --
>> Ming Lei

Re: oprofile and ARM A9 hardware counter

[Ming Lei]

On Fri, Jan 20, 2012 at 9:47 PM, stephane eranian
<eranian@googlemail.com> wrote:
> Started afresh from:
>
> 90a4c0f uml: fix compile for x86-64
>
> And added 3, 4, 5, 6:
> 603c316 arm: omap4: pmu: support runtime pm
> 4899fbd arm: omap4: support pmu
> d737bb1 arm: omap4: create pmu device via hwmod
> 4e0259e arm: omap4: hwmod: introduce emu hwmod
>
> Still no interrupts firing. I am using your .config file.
>
> My HW:
> CPU implementer : 0x41
> CPU architecture: 7
> CPU variant     : 0x1
> CPU part        : 0xc09
> CPU revision    : 2
>
> Hardware        : OMAP4 Panda board
> Revision        : 0020
>
> There must be something I am missing here.

Have you applied the patch in link[1]?


thanks,
--
Ming Lei

[1], http://marc.info/?l=linux-arm-kernel&m=132697975416659&w=2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

oprofile and ARM A9 hardware counter

[Ming Lei]

On Fri, Jan 20, 2012 at 9:47 PM, stephane eranian
<eranian@googlemail.com> wrote:
> Started afresh from:
>
> 90a4c0f uml: fix compile for x86-64
>
> And added 3, 4, 5, 6:
> 603c316 arm: omap4: pmu: support runtime pm
> 4899fbd arm: omap4: support pmu
> d737bb1 arm: omap4: create pmu device via hwmod
> 4e0259e arm: omap4: hwmod: introduce emu hwmod
>
> Still no interrupts firing. I am using your .config file.
>
> My HW:
> CPU implementer : 0x41
> CPU architecture: 7
> CPU variant ? ? : 0x1
> CPU part ? ? ? ?: 0xc09
> CPU revision ? ?: 2
>
> Hardware ? ? ? ?: OMAP4 Panda board
> Revision ? ? ? ?: 0020
>
> There must be something I am missing here.

Have you applied the patch in link[1]?


thanks,
--
Ming Lei

[1], http://marc.info/?l=linux-arm-kernel&m=132697975416659&w=2

Re: oprofile and ARM A9 hardware counter

[stephane eranian]

On Sat, Jan 21, 2012 at 4:25 AM, Ming Lei <ming.lei@canonical.com> wrote:
> On Fri, Jan 20, 2012 at 9:47 PM, stephane eranian
> <eranian@googlemail.com> wrote:
>> Started afresh from:
>>
>> 90a4c0f uml: fix compile for x86-64
>>
>> And added 3, 4, 5, 6:
>> 603c316 arm: omap4: pmu: support runtime pm
>> 4899fbd arm: omap4: support pmu
>> d737bb1 arm: omap4: create pmu device via hwmod
>> 4e0259e arm: omap4: hwmod: introduce emu hwmod
>>
>> Still no interrupts firing. I am using your .config file.
>>
>> My HW:
>> CPU implementer : 0x41
>> CPU architecture: 7
>> CPU variant     : 0x1
>> CPU part        : 0xc09
>> CPU revision    : 2
>>
>> Hardware        : OMAP4 Panda board
>> Revision        : 0020
>>
>> There must be something I am missing here.
>
> Have you applied the patch in link[1]?
>
You mean this:
> [1], http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=summary

It does not point to a patch but to the entire tree.

>
> thanks,
> --
> Ming Lei
>
> [1], http://marc.info/?l=linux-arm-kernel&m=132697975416659&w=2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

oprofile and ARM A9 hardware counter

[stephane eranian]

On Sat, Jan 21, 2012 at 4:25 AM, Ming Lei <ming.lei@canonical.com> wrote:
> On Fri, Jan 20, 2012 at 9:47 PM, stephane eranian
> <eranian@googlemail.com> wrote:
>> Started afresh from:
>>
>> 90a4c0f uml: fix compile for x86-64
>>
>> And added 3, 4, 5, 6:
>> 603c316 arm: omap4: pmu: support runtime pm
>> 4899fbd arm: omap4: support pmu
>> d737bb1 arm: omap4: create pmu device via hwmod
>> 4e0259e arm: omap4: hwmod: introduce emu hwmod
>>
>> Still no interrupts firing. I am using your .config file.
>>
>> My HW:
>> CPU implementer : 0x41
>> CPU architecture: 7
>> CPU variant ? ? : 0x1
>> CPU part ? ? ? ?: 0xc09
>> CPU revision ? ?: 2
>>
>> Hardware ? ? ? ?: OMAP4 Panda board
>> Revision ? ? ? ?: 0020
>>
>> There must be something I am missing here.
>
> Have you applied the patch in link[1]?
>
You mean this:
> [1], http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=summary

It does not point to a patch but to the entire tree.

>
> thanks,
> --
> Ming Lei
>
> [1], http://marc.info/?l=linux-arm-kernel&m=132697975416659&w=2

Re: oprofile and ARM A9 hardware counter

[Will Deacon]

Hi guys,

On Sat, Jan 21, 2012 at 09:16:57AM +0000, stephane eranian wrote:
> On Sat, Jan 21, 2012 at 4:25 AM, Ming Lei <ming.lei@canonical.com> wrote:
> > On Fri, Jan 20, 2012 at 9:47 PM, stephane eranian
> > <eranian@googlemail.com> wrote:
> >> Started afresh from:
> >>
> >> 90a4c0f uml: fix compile for x86-64
> >>
> >> And added 3, 4, 5, 6:
> >> 603c316 arm: omap4: pmu: support runtime pm
> >> 4899fbd arm: omap4: support pmu
> >> d737bb1 arm: omap4: create pmu device via hwmod
> >> 4e0259e arm: omap4: hwmod: introduce emu hwmod
> >>
> >> Still no interrupts firing. I am using your .config file.
> >>
> >> My HW:
> >> CPU implementer : 0x41
> >> CPU architecture: 7
> >> CPU variant     : 0x1
> >> CPU part        : 0xc09
> >> CPU revision    : 2
> >>
> >> Hardware        : OMAP4 Panda board
> >> Revision        : 0020
> >>
> >> There must be something I am missing here.

Did this lead anywhere in the end? It seems as though Ming Lei has a working
setup but Stephane is unable to replicate it, despite applying the necessary
patches and trying an updated bootloader.

Drastic suggestion: Stephane, could you try a kernel *binary* from Ming Lei?
If that works then you're probably just missing a patch. If it doesn't, then
there must be something different between your boards.

Will

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2

oprofile and ARM A9 hardware counter

[Will Deacon]

Hi guys,

On Sat, Jan 21, 2012 at 09:16:57AM +0000, stephane eranian wrote:
> On Sat, Jan 21, 2012 at 4:25 AM, Ming Lei <ming.lei@canonical.com> wrote:
> > On Fri, Jan 20, 2012 at 9:47 PM, stephane eranian
> > <eranian@googlemail.com> wrote:
> >> Started afresh from:
> >>
> >> 90a4c0f uml: fix compile for x86-64
> >>
> >> And added 3, 4, 5, 6:
> >> 603c316 arm: omap4: pmu: support runtime pm
> >> 4899fbd arm: omap4: support pmu
> >> d737bb1 arm: omap4: create pmu device via hwmod
> >> 4e0259e arm: omap4: hwmod: introduce emu hwmod
> >>
> >> Still no interrupts firing. I am using your .config file.
> >>
> >> My HW:
> >> CPU implementer : 0x41
> >> CPU architecture: 7
> >> CPU variant ? ? : 0x1
> >> CPU part ? ? ? ?: 0xc09
> >> CPU revision ? ?: 2
> >>
> >> Hardware ? ? ? ?: OMAP4 Panda board
> >> Revision ? ? ? ?: 0020
> >>
> >> There must be something I am missing here.

Did this lead anywhere in the end? It seems as though Ming Lei has a working
setup but Stephane is unable to replicate it, despite applying the necessary
patches and trying an updated bootloader.

Drastic suggestion: Stephane, could you try a kernel *binary* from Ming Lei?
If that works then you're probably just missing a patch. If it doesn't, then
there must be something different between your boards.

Will

Re: oprofile and ARM A9 hardware counter

[stephane eranian]

On Fri, Jan 27, 2012 at 1:13 PM, Will Deacon <will.deacon@arm.com> wrote:
> Hi guys,
>
> On Sat, Jan 21, 2012 at 09:16:57AM +0000, stephane eranian wrote:
>> On Sat, Jan 21, 2012 at 4:25 AM, Ming Lei <ming.lei@canonical.com> wrote:
>> > On Fri, Jan 20, 2012 at 9:47 PM, stephane eranian
>> > <eranian@googlemail.com> wrote:
>> >> Started afresh from:
>> >>
>> >> 90a4c0f uml: fix compile for x86-64
>> >>
>> >> And added 3, 4, 5, 6:
>> >> 603c316 arm: omap4: pmu: support runtime pm
>> >> 4899fbd arm: omap4: support pmu
>> >> d737bb1 arm: omap4: create pmu device via hwmod
>> >> 4e0259e arm: omap4: hwmod: introduce emu hwmod
>> >>
>> >> Still no interrupts firing. I am using your .config file.
>> >>
>> >> My HW:
>> >> CPU implementer : 0x41
>> >> CPU architecture: 7
>> >> CPU variant     : 0x1
>> >> CPU part        : 0xc09
>> >> CPU revision    : 2
>> >>
>> >> Hardware        : OMAP4 Panda board
>> >> Revision        : 0020
>> >>
>> >> There must be something I am missing here.
>
> Did this lead anywhere in the end? It seems as though Ming Lei has a working
> setup but Stephane is unable to replicate it, despite applying the necessary
> patches and trying an updated bootloader.
>
> Drastic suggestion: Stephane, could you try a kernel *binary* from Ming Lei?
> If that works then you're probably just missing a patch. If it doesn't, then
> there must be something different between your boards.
>
Sure, send me the binary+initrd and I can try it out.

> Will

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
oprofile-list mailing list
oprofile-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oprofile-list

oprofile and ARM A9 hardware counter

[stephane eranian]

On Fri, Jan 27, 2012 at 1:13 PM, Will Deacon <will.deacon@arm.com> wrote:
> Hi guys,
>
> On Sat, Jan 21, 2012 at 09:16:57AM +0000, stephane eranian wrote:
>> On Sat, Jan 21, 2012 at 4:25 AM, Ming Lei <ming.lei@canonical.com> wrote:
>> > On Fri, Jan 20, 2012 at 9:47 PM, stephane eranian
>> > <eranian@googlemail.com> wrote:
>> >> Started afresh from:
>> >>
>> >> 90a4c0f uml: fix compile for x86-64
>> >>
>> >> And added 3, 4, 5, 6:
>> >> 603c316 arm: omap4: pmu: support runtime pm
>> >> 4899fbd arm: omap4: support pmu
>> >> d737bb1 arm: omap4: create pmu device via hwmod
>> >> 4e0259e arm: omap4: hwmod: introduce emu hwmod
>> >>
>> >> Still no interrupts firing. I am using your .config file.
>> >>
>> >> My HW:
>> >> CPU implementer : 0x41
>> >> CPU architecture: 7
>> >> CPU variant ? ? : 0x1
>> >> CPU part ? ? ? ?: 0xc09
>> >> CPU revision ? ?: 2
>> >>
>> >> Hardware ? ? ? ?: OMAP4 Panda board
>> >> Revision ? ? ? ?: 0020
>> >>
>> >> There must be something I am missing here.
>
> Did this lead anywhere in the end? It seems as though Ming Lei has a working
> setup but Stephane is unable to replicate it, despite applying the necessary
> patches and trying an updated bootloader.
>
> Drastic suggestion: Stephane, could you try a kernel *binary* from Ming Lei?
> If that works then you're probably just missing a patch. If it doesn't, then
> there must be something different between your boards.
>
Sure, send me the binary+initrd and I can try it out.

> Will

Re: oprofile and ARM A9 hardware counter

[Måns Rullgård]

Will Deacon <will.deacon@arm.com> writes:

> Hi guys,
>
> On Sat, Jan 21, 2012 at 09:16:57AM +0000, stephane eranian wrote:
>> On Sat, Jan 21, 2012 at 4:25 AM, Ming Lei <ming.lei@canonical.com> wrote:
>> > On Fri, Jan 20, 2012 at 9:47 PM, stephane eranian
>> > <eranian@googlemail.com> wrote:
>> >> Started afresh from:
>> >>
>> >> 90a4c0f uml: fix compile for x86-64
>> >>
>> >> And added 3, 4, 5, 6:
>> >> 603c316 arm: omap4: pmu: support runtime pm
>> >> 4899fbd arm: omap4: support pmu
>> >> d737bb1 arm: omap4: create pmu device via hwmod
>> >> 4e0259e arm: omap4: hwmod: introduce emu hwmod
>> >>
>> >> Still no interrupts firing. I am using your .config file.
>> >>
>> >> My HW:
>> >> CPU implementer : 0x41
>> >> CPU architecture: 7
>> >> CPU variant     : 0x1
>> >> CPU part        : 0xc09
>> >> CPU revision    : 2
>> >>
>> >> Hardware        : OMAP4 Panda board
>> >> Revision        : 0020
>> >>
>> >> There must be something I am missing here.
>
> Did this lead anywhere in the end? It seems as though Ming Lei has a working
> setup but Stephane is unable to replicate it, despite applying the necessary
> patches and trying an updated bootloader.

With the patches listed above plus the one in [1], I get PMU interrupts.
However, unless I restrict the profiled process to one CPU
(taskset 1 perf record ...), I get a panic in armpmu_event_update() with
the 'event' argument being null when called from armv7pmu_handle_irq().

[1] http://article.gmane.org/gmane.linux.ports.arm.omap/69696

-- 
Måns Rullgård
mans@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

oprofile and ARM A9 hardware counter

[Måns Rullgård]

Will Deacon <will.deacon@arm.com> writes:

> Hi guys,
>
> On Sat, Jan 21, 2012 at 09:16:57AM +0000, stephane eranian wrote:
>> On Sat, Jan 21, 2012 at 4:25 AM, Ming Lei <ming.lei@canonical.com> wrote:
>> > On Fri, Jan 20, 2012 at 9:47 PM, stephane eranian
>> > <eranian@googlemail.com> wrote:
>> >> Started afresh from:
>> >>
>> >> 90a4c0f uml: fix compile for x86-64
>> >>
>> >> And added 3, 4, 5, 6:
>> >> 603c316 arm: omap4: pmu: support runtime pm
>> >> 4899fbd arm: omap4: support pmu
>> >> d737bb1 arm: omap4: create pmu device via hwmod
>> >> 4e0259e arm: omap4: hwmod: introduce emu hwmod
>> >>
>> >> Still no interrupts firing. I am using your .config file.
>> >>
>> >> My HW:
>> >> CPU implementer : 0x41
>> >> CPU architecture: 7
>> >> CPU variant ? ? : 0x1
>> >> CPU part ? ? ? ?: 0xc09
>> >> CPU revision ? ?: 2
>> >>
>> >> Hardware ? ? ? ?: OMAP4 Panda board
>> >> Revision ? ? ? ?: 0020
>> >>
>> >> There must be something I am missing here.
>
> Did this lead anywhere in the end? It seems as though Ming Lei has a working
> setup but Stephane is unable to replicate it, despite applying the necessary
> patches and trying an updated bootloader.

With the patches listed above plus the one in [1], I get PMU interrupts.
However, unless I restrict the profiled process to one CPU
(taskset 1 perf record ...), I get a panic in armpmu_event_update() with
the 'event' argument being null when called from armv7pmu_handle_irq().

[1] http://article.gmane.org/gmane.linux.ports.arm.omap/69696

-- 
M?ns Rullg?rd
mans at mansr.com

Re: oprofile and ARM A9 hardware counter

[Will Deacon]

Mans,

On Fri, Jan 27, 2012 at 12:56:35PM +0000, Måns Rullgård wrote:
> Will Deacon <will.deacon@arm.com> writes:
> > Did this lead anywhere in the end? It seems as though Ming Lei has a working
> > setup but Stephane is unable to replicate it, despite applying the necessary
> > patches and trying an updated bootloader.
> 
> With the patches listed above plus the one in [1], I get PMU interrupts.
> However, unless I restrict the profiled process to one CPU
> (taskset 1 perf record ...), I get a panic in armpmu_event_update() with
> the 'event' argument being null when called from armv7pmu_handle_irq().
> 
> [1] http://article.gmane.org/gmane.linux.ports.arm.omap/69696

Great, thanks for trying this out. Which version of the kernel were you
using? I fixed a bunch of NULL pointer derefs. during the 3.2 window, but if
you were using an -rc kernel you have have hit one of them.

Will

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2

oprofile and ARM A9 hardware counter

[Will Deacon]

Mans,

On Fri, Jan 27, 2012 at 12:56:35PM +0000, M?ns Rullg?rd wrote:
> Will Deacon <will.deacon@arm.com> writes:
> > Did this lead anywhere in the end? It seems as though Ming Lei has a working
> > setup but Stephane is unable to replicate it, despite applying the necessary
> > patches and trying an updated bootloader.
> 
> With the patches listed above plus the one in [1], I get PMU interrupts.
> However, unless I restrict the profiled process to one CPU
> (taskset 1 perf record ...), I get a panic in armpmu_event_update() with
> the 'event' argument being null when called from armv7pmu_handle_irq().
> 
> [1] http://article.gmane.org/gmane.linux.ports.arm.omap/69696

Great, thanks for trying this out. Which version of the kernel were you
using? I fixed a bunch of NULL pointer derefs. during the 3.2 window, but if
you were using an -rc kernel you have have hit one of them.

Will

Re: oprofile and ARM A9 hardware counter

[stephane eranian]

2012/1/27 Will Deacon <will.deacon@arm.com>:
> Mans,
>
> On Fri, Jan 27, 2012 at 12:56:35PM +0000, Måns Rullgård wrote:
>> Will Deacon <will.deacon@arm.com> writes:
>> > Did this lead anywhere in the end? It seems as though Ming Lei has a working
>> > setup but Stephane is unable to replicate it, despite applying the necessary
>> > patches and trying an updated bootloader.
>>
>> With the patches listed above plus the one in [1], I get PMU interrupts.
>> However, unless I restrict the profiled process to one CPU
>> (taskset 1 perf record ...), I get a panic in armpmu_event_update() with
>> the 'event' argument being null when called from armv7pmu_handle_irq().
>>
>> [1] http://article.gmane.org/gmane.linux.ports.arm.omap/69696
>
Ok, I am recompiling the kernel for this one line fix:

--- 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,
 };
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

oprofile and ARM A9 hardware counter

[stephane eranian]

2012/1/27 Will Deacon <will.deacon@arm.com>:
> Mans,
>
> On Fri, Jan 27, 2012 at 12:56:35PM +0000, M?ns Rullg?rd wrote:
>> Will Deacon <will.deacon@arm.com> writes:
>> > Did this lead anywhere in the end? It seems as though Ming Lei has a working
>> > setup but Stephane is unable to replicate it, despite applying the necessary
>> > patches and trying an updated bootloader.
>>
>> With the patches listed above plus the one in [1], I get PMU interrupts.
>> However, unless I restrict the profiled process to one CPU
>> (taskset 1 perf record ...), I get a panic in armpmu_event_update() with
>> the 'event' argument being null when called from armv7pmu_handle_irq().
>>
>> [1] http://article.gmane.org/gmane.linux.ports.arm.omap/69696
>
Ok, I am recompiling the kernel for this one line fix:

--- 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,
 };

Re: oprofile and ARM A9 hardware counter

[Måns Rullgård]

Will Deacon <will.deacon@arm.com> writes:

> Mans,
>
> On Fri, Jan 27, 2012 at 12:56:35PM +0000, Måns Rullgård wrote:
>> Will Deacon <will.deacon@arm.com> writes:
>> > Did this lead anywhere in the end? It seems as though Ming Lei has a working
>> > setup but Stephane is unable to replicate it, despite applying the necessary
>> > patches and trying an updated bootloader.
>> 
>> With the patches listed above plus the one in [1], I get PMU interrupts.
>> However, unless I restrict the profiled process to one CPU
>> (taskset 1 perf record ...), I get a panic in armpmu_event_update() with
>> the 'event' argument being null when called from armv7pmu_handle_irq().
>> 
>> [1] http://article.gmane.org/gmane.linux.ports.arm.omap/69696
>
> Great, thanks for trying this out. Which version of the kernel were you
> using? I fixed a bunch of NULL pointer derefs. during the 3.2 window, but if
> you were using an -rc kernel you have have hit one of them.

This was with the Linaro tilt-3.2 kernel from
git://git.linaro.org/landing-teams/working/ti/kernel.git, commit
73e2c294444f209d281f7cd10b52b53b087e74f1.  Maybe one of the many patches
it has on top of 3.2 is to blame.

-- 
Måns Rullgård
mans@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

oprofile and ARM A9 hardware counter

[Måns Rullgård]

Will Deacon <will.deacon@arm.com> writes:

> Mans,
>
> On Fri, Jan 27, 2012 at 12:56:35PM +0000, M?ns Rullg?rd wrote:
>> Will Deacon <will.deacon@arm.com> writes:
>> > Did this lead anywhere in the end? It seems as though Ming Lei has a working
>> > setup but Stephane is unable to replicate it, despite applying the necessary
>> > patches and trying an updated bootloader.
>> 
>> With the patches listed above plus the one in [1], I get PMU interrupts.
>> However, unless I restrict the profiled process to one CPU
>> (taskset 1 perf record ...), I get a panic in armpmu_event_update() with
>> the 'event' argument being null when called from armv7pmu_handle_irq().
>> 
>> [1] http://article.gmane.org/gmane.linux.ports.arm.omap/69696
>
> Great, thanks for trying this out. Which version of the kernel were you
> using? I fixed a bunch of NULL pointer derefs. during the 3.2 window, but if
> you were using an -rc kernel you have have hit one of them.

This was with the Linaro tilt-3.2 kernel from
git://git.linaro.org/landing-teams/working/ti/kernel.git, commit
73e2c294444f209d281f7cd10b52b53b087e74f1.  Maybe one of the many patches
it has on top of 3.2 is to blame.

-- 
M?ns Rullg?rd
mans at mansr.com

Re: oprofile and ARM A9 hardware counter

[Will Deacon]

On Fri, Jan 27, 2012 at 01:47:01PM +0000, Måns Rullgård wrote:
> Will Deacon <will.deacon@arm.com> writes:
> 
> > Mans,
> >
> > On Fri, Jan 27, 2012 at 12:56:35PM +0000, Måns Rullgård wrote:
> >> Will Deacon <will.deacon@arm.com> writes:
> >> > Did this lead anywhere in the end? It seems as though Ming Lei has a working
> >> > setup but Stephane is unable to replicate it, despite applying the necessary
> >> > patches and trying an updated bootloader.
> >> 
> >> With the patches listed above plus the one in [1], I get PMU interrupts.
> >> However, unless I restrict the profiled process to one CPU
> >> (taskset 1 perf record ...), I get a panic in armpmu_event_update() with
> >> the 'event' argument being null when called from armv7pmu_handle_irq().
> >> 
> >> [1] http://article.gmane.org/gmane.linux.ports.arm.omap/69696
> >
> > Great, thanks for trying this out. Which version of the kernel were you
> > using? I fixed a bunch of NULL pointer derefs. during the 3.2 window, but if
> > you were using an -rc kernel you have have hit one of them.
> 
> This was with the Linaro tilt-3.2 kernel from
> git://git.linaro.org/landing-teams/working/ti/kernel.git, commit
> 73e2c294444f209d281f7cd10b52b53b087e74f1.  Maybe one of the many patches
> it has on top of 3.2 is to blame.

Perhaps, or (more likely) the interrupt affinity for the CTI isn't working
properly and the interrupt is always delivered to CPU0. I'll keep this in
mind in case we get any more reports like this.

Cheers,

Will

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2

oprofile and ARM A9 hardware counter

[Will Deacon]

On Fri, Jan 27, 2012 at 01:47:01PM +0000, M?ns Rullg?rd wrote:
> Will Deacon <will.deacon@arm.com> writes:
> 
> > Mans,
> >
> > On Fri, Jan 27, 2012 at 12:56:35PM +0000, M?ns Rullg?rd wrote:
> >> Will Deacon <will.deacon@arm.com> writes:
> >> > Did this lead anywhere in the end? It seems as though Ming Lei has a working
> >> > setup but Stephane is unable to replicate it, despite applying the necessary
> >> > patches and trying an updated bootloader.
> >> 
> >> With the patches listed above plus the one in [1], I get PMU interrupts.
> >> However, unless I restrict the profiled process to one CPU
> >> (taskset 1 perf record ...), I get a panic in armpmu_event_update() with
> >> the 'event' argument being null when called from armv7pmu_handle_irq().
> >> 
> >> [1] http://article.gmane.org/gmane.linux.ports.arm.omap/69696
> >
> > Great, thanks for trying this out. Which version of the kernel were you
> > using? I fixed a bunch of NULL pointer derefs. during the 3.2 window, but if
> > you were using an -rc kernel you have have hit one of them.
> 
> This was with the Linaro tilt-3.2 kernel from
> git://git.linaro.org/landing-teams/working/ti/kernel.git, commit
> 73e2c294444f209d281f7cd10b52b53b087e74f1.  Maybe one of the many patches
> it has on top of 3.2 is to blame.

Perhaps, or (more likely) the interrupt affinity for the CTI isn't working
properly and the interrupt is always delivered to CPU0. I'll keep this in
mind in case we get any more reports like this.

Cheers,

Will

Re: oprofile and ARM A9 hardware counter

[Måns Rullgård]

Will Deacon <will.deacon@arm.com> writes:

> On Fri, Jan 27, 2012 at 01:47:01PM +0000, Måns Rullgård wrote:
>> Will Deacon <will.deacon@arm.com> writes:
>> 
>> > Mans,
>> >
>> > On Fri, Jan 27, 2012 at 12:56:35PM +0000, Måns Rullgård wrote:
>> >> Will Deacon <will.deacon@arm.com> writes:
>> >> > Did this lead anywhere in the end? It seems as though Ming Lei has a working
>> >> > setup but Stephane is unable to replicate it, despite applying the necessary
>> >> > patches and trying an updated bootloader.
>> >> 
>> >> With the patches listed above plus the one in [1], I get PMU interrupts.
>> >> However, unless I restrict the profiled process to one CPU
>> >> (taskset 1 perf record ...), I get a panic in armpmu_event_update() with
>> >> the 'event' argument being null when called from armv7pmu_handle_irq().
>> >> 
>> >> [1] http://article.gmane.org/gmane.linux.ports.arm.omap/69696
>> >
>> > Great, thanks for trying this out. Which version of the kernel were you
>> > using? I fixed a bunch of NULL pointer derefs. during the 3.2 window, but if
>> > you were using an -rc kernel you have have hit one of them.
>> 
>> This was with the Linaro tilt-3.2 kernel from
>> git://git.linaro.org/landing-teams/working/ti/kernel.git, commit
>> 73e2c294444f209d281f7cd10b52b53b087e74f1.  Maybe one of the many patches
>> it has on top of 3.2 is to blame.
>
> Perhaps, or (more likely) the interrupt affinity for the CTI isn't working
> properly and the interrupt is always delivered to CPU0. I'll keep this in
> mind in case we get any more reports like this.

It works whichever CPU I pin it to (i.e. taskset 2 also works).

FWIW, my /proc/interrupts looks like this when perf is running:

           CPU0       CPU1
 29:   25238127    1409121       GIC  twd
 33:    4586197          0       GIC  arm-pmu
 34:          0    4744550       GIC  arm-pmu
 39:          0          0       GIC  TWL6030-PIH
 41:          0          0       GIC  l3-dbg-irq
 42:          0          0       GIC  l3-app-irq
 43:          0          0       GIC  prcm
 44:        141          0       GIC  DMA
[...]

-- 
Måns Rullgård
mans@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

oprofile and ARM A9 hardware counter

[Måns Rullgård]

Will Deacon <will.deacon@arm.com> writes:

> On Fri, Jan 27, 2012 at 01:47:01PM +0000, M?ns Rullg?rd wrote:
>> Will Deacon <will.deacon@arm.com> writes:
>> 
>> > Mans,
>> >
>> > On Fri, Jan 27, 2012 at 12:56:35PM +0000, M?ns Rullg?rd wrote:
>> >> Will Deacon <will.deacon@arm.com> writes:
>> >> > Did this lead anywhere in the end? It seems as though Ming Lei has a working
>> >> > setup but Stephane is unable to replicate it, despite applying the necessary
>> >> > patches and trying an updated bootloader.
>> >> 
>> >> With the patches listed above plus the one in [1], I get PMU interrupts.
>> >> However, unless I restrict the profiled process to one CPU
>> >> (taskset 1 perf record ...), I get a panic in armpmu_event_update() with
>> >> the 'event' argument being null when called from armv7pmu_handle_irq().
>> >> 
>> >> [1] http://article.gmane.org/gmane.linux.ports.arm.omap/69696
>> >
>> > Great, thanks for trying this out. Which version of the kernel were you
>> > using? I fixed a bunch of NULL pointer derefs. during the 3.2 window, but if
>> > you were using an -rc kernel you have have hit one of them.
>> 
>> This was with the Linaro tilt-3.2 kernel from
>> git://git.linaro.org/landing-teams/working/ti/kernel.git, commit
>> 73e2c294444f209d281f7cd10b52b53b087e74f1.  Maybe one of the many patches
>> it has on top of 3.2 is to blame.
>
> Perhaps, or (more likely) the interrupt affinity for the CTI isn't working
> properly and the interrupt is always delivered to CPU0. I'll keep this in
> mind in case we get any more reports like this.

It works whichever CPU I pin it to (i.e. taskset 2 also works).

FWIW, my /proc/interrupts looks like this when perf is running:

           CPU0       CPU1
 29:   25238127    1409121       GIC  twd
 33:    4586197          0       GIC  arm-pmu
 34:          0    4744550       GIC  arm-pmu
 39:          0          0       GIC  TWL6030-PIH
 41:          0          0       GIC  l3-dbg-irq
 42:          0          0       GIC  l3-app-irq
 43:          0          0       GIC  prcm
 44:        141          0       GIC  DMA
[...]

-- 
M?ns Rullg?rd
mans at mansr.com

Re: oprofile and ARM A9 hardware counter

[Ming Lei]

Hi,

2012/1/27 Will Deacon <will.deacon@arm.com>:
> Mans,
>
> On Fri, Jan 27, 2012 at 12:56:35PM +0000, Måns Rullgård wrote:
>> Will Deacon <will.deacon@arm.com> writes:
>> > Did this lead anywhere in the end? It seems as though Ming Lei has a working
>> > setup but Stephane is unable to replicate it, despite applying the necessary
>> > patches and trying an updated bootloader.
>>
>> With the patches listed above plus the one in [1], I get PMU interrupts.
>> However, unless I restrict the profiled process to one CPU
>> (taskset 1 perf record ...), I get a panic in armpmu_event_update() with
>> the 'event' argument being null when called from armv7pmu_handle_irq().
>>
>> [1] http://article.gmane.org/gmane.linux.ports.arm.omap/69696
>
> Great, thanks for trying this out. Which version of the kernel were you
> using?

The patch is required for 3.3-rc1 in case that omap4 pmu works well.

thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

oprofile and ARM A9 hardware counter

[Ming Lei]

Hi,

2012/1/27 Will Deacon <will.deacon@arm.com>:
> Mans,
>
> On Fri, Jan 27, 2012 at 12:56:35PM +0000, M?ns Rullg?rd wrote:
>> Will Deacon <will.deacon@arm.com> writes:
>> > Did this lead anywhere in the end? It seems as though Ming Lei has a working
>> > setup but Stephane is unable to replicate it, despite applying the necessary
>> > patches and trying an updated bootloader.
>>
>> With the patches listed above plus the one in [1], I get PMU interrupts.
>> However, unless I restrict the profiled process to one CPU
>> (taskset 1 perf record ...), I get a panic in armpmu_event_update() with
>> the 'event' argument being null when called from armv7pmu_handle_irq().
>>
>> [1] http://article.gmane.org/gmane.linux.ports.arm.omap/69696
>
> Great, thanks for trying this out. Which version of the kernel were you
> using?

The patch is required for 3.3-rc1 in case that omap4 pmu works well.

thanks,
--
Ming Lei

Re: oprofile and ARM A9 hardware counter

[stephane eranian]

Hi,

Ok, with the one-line patch [1], this works much better now.
No more wrap around a 4 billion cycles.

Sampling is okay, though I noticed it tends to not get the
correct number of samples for a controlled run:

$ perf record -e cycles -c 1009213 noploop 10
noploop for 10 seconds

$ perf report -D | tail -20
cycles stats:
           TOTAL events:       9938
            MMAP events:         13
            COMM events:          2
            EXIT events:          2
        THROTTLE events:         12
      UNTHROTTLE events:         12
          SAMPLE events:       9897

Should not get throttled samples. Should get abour 10k samples
but only seeing 9897. The max_rate limit is way higher
than what I set the period (1000 samples/sec). But then,
is 3.2.0 throttling is broken. I posted a patch to fix that
yesterday. I will try with my patch applied as well.


Will do some more testing and update to the latest 3.3.0-rc1.
For now this is with 3.2.0 Linus tree.

$ sudo  ./syst_count -c 1 -p -e cpu_cycles
<press CTRL-C to quit before 20s time limit>
# 1s -----
CPU1   G0  1008360963           cpu_cycles (scaling 0.00%,
ena=1000427246, run=1000427246)
# 2s -----
CPU1   G0  2016503406           cpu_cycles (scaling 0.00%,
ena=2000610351, run=2000610351)
# 3s -----
CPU1   G0  3024622201           cpu_cycles (scaling 0.00%,
ena=3000701904, run=3000701904)
# 4s -----
CPU1   G0  4032753756           cpu_cycles (scaling 0.00%,
ena=4000823974, run=4000823974)
# 5s -----
CPU1   G0  5041040463           cpu_cycles (scaling 0.00%,
ena=5001098633, run=5001098633)
# 6s -----
CPU1   G0  6049184665           cpu_cycles (scaling 0.00%,
ena=6001220703, run=6001220703)
# 7s -----
CPU1   G0  7057336298           cpu_cycles (scaling 0.00%,
ena=7001403808, run=7001403808)
# 8s -----
CPU1   G0  8065459152           cpu_cycles (scaling 0.00%,
ena=8001556395, run=8001556395)
# 9s -----
CPU1   G0  9074297578           cpu_cycles (scaling 0.00%,
ena=9002380370, run=9002380370)
# 10s -----
CPU1   G0  10082619086          cpu_cycles (scaling 0.00%,
ena=10003540038, run=10003540038)

On Fri, Jan 27, 2012 at 3:09 PM, Ming Lei <ming.lei@canonical.com> wrote:
> Hi,
>
> 2012/1/27 Will Deacon <will.deacon@arm.com>:
>> Mans,
>>
>> On Fri, Jan 27, 2012 at 12:56:35PM +0000, Måns Rullgård wrote:
>>> Will Deacon <will.deacon@arm.com> writes:
>>> > Did this lead anywhere in the end? It seems as though Ming Lei has a working
>>> > setup but Stephane is unable to replicate it, despite applying the necessary
>>> > patches and trying an updated bootloader.
>>>
>>> With the patches listed above plus the one in [1], I get PMU interrupts.
>>> However, unless I restrict the profiled process to one CPU
>>> (taskset 1 perf record ...), I get a panic in armpmu_event_update() with
>>> the 'event' argument being null when called from armv7pmu_handle_irq().
>>>
>>> [1] http://article.gmane.org/gmane.linux.ports.arm.omap/69696
>>
>> Great, thanks for trying this out. Which version of the kernel were you
>> using?
>
> The patch is required for 3.3-rc1 in case that omap4 pmu works well.
>
> thanks,
> --
> Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

oprofile and ARM A9 hardware counter

[stephane eranian]

Hi,

Ok, with the one-line patch [1], this works much better now.
No more wrap around a 4 billion cycles.

Sampling is okay, though I noticed it tends to not get the
correct number of samples for a controlled run:

$ perf record -e cycles -c 1009213 noploop 10
noploop for 10 seconds

$ perf report -D | tail -20
cycles stats:
           TOTAL events:       9938
            MMAP events:         13
            COMM events:          2
            EXIT events:          2
        THROTTLE events:         12
      UNTHROTTLE events:         12
          SAMPLE events:       9897

Should not get throttled samples. Should get abour 10k samples
but only seeing 9897. The max_rate limit is way higher
than what I set the period (1000 samples/sec). But then,
is 3.2.0 throttling is broken. I posted a patch to fix that
yesterday. I will try with my patch applied as well.


Will do some more testing and update to the latest 3.3.0-rc1.
For now this is with 3.2.0 Linus tree.

$ sudo  ./syst_count -c 1 -p -e cpu_cycles
<press CTRL-C to quit before 20s time limit>
# 1s -----
CPU1   G0  1008360963           cpu_cycles (scaling 0.00%,
ena=1000427246, run=1000427246)
# 2s -----
CPU1   G0  2016503406           cpu_cycles (scaling 0.00%,
ena=2000610351, run=2000610351)
# 3s -----
CPU1   G0  3024622201           cpu_cycles (scaling 0.00%,
ena=3000701904, run=3000701904)
# 4s -----
CPU1   G0  4032753756           cpu_cycles (scaling 0.00%,
ena=4000823974, run=4000823974)
# 5s -----
CPU1   G0  5041040463           cpu_cycles (scaling 0.00%,
ena=5001098633, run=5001098633)
# 6s -----
CPU1   G0  6049184665           cpu_cycles (scaling 0.00%,
ena=6001220703, run=6001220703)
# 7s -----
CPU1   G0  7057336298           cpu_cycles (scaling 0.00%,
ena=7001403808, run=7001403808)
# 8s -----
CPU1   G0  8065459152           cpu_cycles (scaling 0.00%,
ena=8001556395, run=8001556395)
# 9s -----
CPU1   G0  9074297578           cpu_cycles (scaling 0.00%,
ena=9002380370, run=9002380370)
# 10s -----
CPU1   G0  10082619086          cpu_cycles (scaling 0.00%,
ena=10003540038, run=10003540038)

On Fri, Jan 27, 2012 at 3:09 PM, Ming Lei <ming.lei@canonical.com> wrote:
> Hi,
>
> 2012/1/27 Will Deacon <will.deacon@arm.com>:
>> Mans,
>>
>> On Fri, Jan 27, 2012 at 12:56:35PM +0000, M?ns Rullg?rd wrote:
>>> Will Deacon <will.deacon@arm.com> writes:
>>> > Did this lead anywhere in the end? It seems as though Ming Lei has a working
>>> > setup but Stephane is unable to replicate it, despite applying the necessary
>>> > patches and trying an updated bootloader.
>>>
>>> With the patches listed above plus the one in [1], I get PMU interrupts.
>>> However, unless I restrict the profiled process to one CPU
>>> (taskset 1 perf record ...), I get a panic in armpmu_event_update() with
>>> the 'event' argument being null when called from armv7pmu_handle_irq().
>>>
>>> [1] http://article.gmane.org/gmane.linux.ports.arm.omap/69696
>>
>> Great, thanks for trying this out. Which version of the kernel were you
>> using?
>
> The patch is required for 3.3-rc1 in case that omap4 pmu works well.
>
> thanks,
> --
> Ming Lei

Re: oprofile and ARM A9 hardware counter

[Will Deacon]

On Fri, Jan 27, 2012 at 03:45:53PM +0000, stephane eranian wrote:
> Hi,

Hi Stephane,

> Ok, with the one-line patch [1], this works much better now.
> No more wrap around a 4 billion cycles.

Hurrah! Thanks Mans and Ming Lei for helping with this. Unfortunately, I
remember Santosh had objections to this patch so that needs to be resolved.

> Sampling is okay, though I noticed it tends to not get the
> correct number of samples for a controlled run:
> 
> $ perf record -e cycles -c 1009213 noploop 10
> noploop for 10 seconds
> 
> $ perf report -D | tail -20
> cycles stats:
>            TOTAL events:       9938
>             MMAP events:         13
>             COMM events:          2
>             EXIT events:          2
>         THROTTLE events:         12
>       UNTHROTTLE events:         12
>           SAMPLE events:       9897
> 
> Should not get throttled samples. Should get abour 10k samples
> but only seeing 9897. The max_rate limit is way higher
> than what I set the period (1000 samples/sec). But then,
> is 3.2.0 throttling is broken. I posted a patch to fix that
> yesterday. I will try with my patch applied as well.

Ok. Note that on ARM the PMU generates a standard IRQ (i.e. not an NMI) so
you may miss samples if they occur during critical kernel sections (and if
you look at a profile, spin_unlock_irqrestore will be quite high).

A7 and A15 have the ability to filter counters based on privilege level, so
you can get more accurate userspace counts there.

Will

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2

oprofile and ARM A9 hardware counter

[Will Deacon]

On Fri, Jan 27, 2012 at 03:45:53PM +0000, stephane eranian wrote:
> Hi,

Hi Stephane,

> Ok, with the one-line patch [1], this works much better now.
> No more wrap around a 4 billion cycles.

Hurrah! Thanks Mans and Ming Lei for helping with this. Unfortunately, I
remember Santosh had objections to this patch so that needs to be resolved.

> Sampling is okay, though I noticed it tends to not get the
> correct number of samples for a controlled run:
> 
> $ perf record -e cycles -c 1009213 noploop 10
> noploop for 10 seconds
> 
> $ perf report -D | tail -20
> cycles stats:
>            TOTAL events:       9938
>             MMAP events:         13
>             COMM events:          2
>             EXIT events:          2
>         THROTTLE events:         12
>       UNTHROTTLE events:         12
>           SAMPLE events:       9897
> 
> Should not get throttled samples. Should get abour 10k samples
> but only seeing 9897. The max_rate limit is way higher
> than what I set the period (1000 samples/sec). But then,
> is 3.2.0 throttling is broken. I posted a patch to fix that
> yesterday. I will try with my patch applied as well.

Ok. Note that on ARM the PMU generates a standard IRQ (i.e. not an NMI) so
you may miss samples if they occur during critical kernel sections (and if
you look at a profile, spin_unlock_irqrestore will be quite high).

A7 and A15 have the ability to filter counters based on privilege level, so
you can get more accurate userspace counts there.

Will

Re: oprofile and ARM A9 hardware counter

[stephane eranian]

On Fri, Jan 27, 2012 at 4:54 PM, Will Deacon <will.deacon@arm.com> wrote:
> On Fri, Jan 27, 2012 at 03:45:53PM +0000, stephane eranian wrote:
>> Hi,
>
> Hi Stephane,
>
>> Ok, with the one-line patch [1], this works much better now.
>> No more wrap around a 4 billion cycles.
>
> Hurrah! Thanks Mans and Ming Lei for helping with this. Unfortunately, I
> remember Santosh had objections to this patch so that needs to be resolved.
>
Yes, this needs to be resolved ASAP.

>> Sampling is okay, though I noticed it tends to not get the
>> correct number of samples for a controlled run:
>>
>> $ perf record -e cycles -c 1009213 noploop 10
>> noploop for 10 seconds
>>
>> $ perf report -D | tail -20
>> cycles stats:
>>            TOTAL events:       9938
>>             MMAP events:         13
>>             COMM events:          2
>>             EXIT events:          2
>>         THROTTLE events:         12
>>       UNTHROTTLE events:         12
>>           SAMPLE events:       9897
>>
>> Should not get throttled samples. Should get abour 10k samples
>> but only seeing 9897. The max_rate limit is way higher
>> than what I set the period (1000 samples/sec). But then,
>> is 3.2.0 throttling is broken. I posted a patch to fix that
>> yesterday. I will try with my patch applied as well.
>
> Ok. Note that on ARM the PMU generates a standard IRQ (i.e. not an NMI) so
> you may miss samples if they occur during critical kernel sections (and if
> you look at a profile, spin_unlock_irqrestore will be quite high).
>
But I am only running a user space noploop. So it spends 99% in user space, no
critical section.

> A7 and A15 have the ability to filter counters based on privilege level, so
> you can get more accurate userspace counts there.

Ok, that's better. Need to update libpfm4 for A15 with priv levels then!

>
> Will
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

oprofile and ARM A9 hardware counter

[stephane eranian]

On Fri, Jan 27, 2012 at 4:54 PM, Will Deacon <will.deacon@arm.com> wrote:
> On Fri, Jan 27, 2012 at 03:45:53PM +0000, stephane eranian wrote:
>> Hi,
>
> Hi Stephane,
>
>> Ok, with the one-line patch [1], this works much better now.
>> No more wrap around a 4 billion cycles.
>
> Hurrah! Thanks Mans and Ming Lei for helping with this. Unfortunately, I
> remember Santosh had objections to this patch so that needs to be resolved.
>
Yes, this needs to be resolved ASAP.

>> Sampling is okay, though I noticed it tends to not get the
>> correct number of samples for a controlled run:
>>
>> $ perf record -e cycles -c 1009213 noploop 10
>> noploop for 10 seconds
>>
>> $ perf report -D | tail -20
>> cycles stats:
>> ? ? ? ? ? ?TOTAL events: ? ? ? 9938
>> ? ? ? ? ? ? MMAP events: ? ? ? ? 13
>> ? ? ? ? ? ? COMM events: ? ? ? ? ?2
>> ? ? ? ? ? ? EXIT events: ? ? ? ? ?2
>> ? ? ? ? THROTTLE events: ? ? ? ? 12
>> ? ? ? UNTHROTTLE events: ? ? ? ? 12
>> ? ? ? ? ? SAMPLE events: ? ? ? 9897
>>
>> Should not get throttled samples. Should get abour 10k samples
>> but only seeing 9897. The max_rate limit is way higher
>> than what I set the period (1000 samples/sec). But then,
>> is 3.2.0 throttling is broken. I posted a patch to fix that
>> yesterday. I will try with my patch applied as well.
>
> Ok. Note that on ARM the PMU generates a standard IRQ (i.e. not an NMI) so
> you may miss samples if they occur during critical kernel sections (and if
> you look at a profile, spin_unlock_irqrestore will be quite high).
>
But I am only running a user space noploop. So it spends 99% in user space, no
critical section.

> A7 and A15 have the ability to filter counters based on privilege level, so
> you can get more accurate userspace counts there.

Ok, that's better. Need to update libpfm4 for A15 with priv levels then!

>
> Will

Re: oprofile and ARM A9 hardware counter

[Will Deacon]

On Fri, Jan 27, 2012 at 03:57:25PM +0000, stephane eranian wrote:
> On Fri, Jan 27, 2012 at 4:54 PM, Will Deacon <will.deacon@arm.com> wrote:
> >
> > Ok. Note that on ARM the PMU generates a standard IRQ (i.e. not an NMI) so
> > you may miss samples if they occur during critical kernel sections (and if
> > you look at a profile, spin_unlock_irqrestore will be quite high).
> >
> But I am only running a user space noploop. So it spends 99% in user space, no
> critical section.

and your result is almost 99% of the way there :)

There are also potential overheads from the PMU interrupts themselves, since
there is a latency between overflow and taking the interrupt and then
between there are actually reading the counter (they continue to count after
overflow).

That said, if you see any bugs in the code please do shout!

> > A7 and A15 have the ability to filter counters based on privilege level, so
> > you can get more accurate userspace counts there.
> 
> Ok, that's better. Need to update libpfm4 for A15 with priv levels then!

How do you handle that in libpfm4? On ARM, the event encodings remain the same,
you just need to set some extra bits to determine which levels are included or
excluded (you can do this with the perf tool by using the :{u,k,h} suffix on an
event description).

Will

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2

oprofile and ARM A9 hardware counter

[Will Deacon]

On Fri, Jan 27, 2012 at 03:57:25PM +0000, stephane eranian wrote:
> On Fri, Jan 27, 2012 at 4:54 PM, Will Deacon <will.deacon@arm.com> wrote:
> >
> > Ok. Note that on ARM the PMU generates a standard IRQ (i.e. not an NMI) so
> > you may miss samples if they occur during critical kernel sections (and if
> > you look at a profile, spin_unlock_irqrestore will be quite high).
> >
> But I am only running a user space noploop. So it spends 99% in user space, no
> critical section.

and your result is almost 99% of the way there :)

There are also potential overheads from the PMU interrupts themselves, since
there is a latency between overflow and taking the interrupt and then
between there are actually reading the counter (they continue to count after
overflow).

That said, if you see any bugs in the code please do shout!

> > A7 and A15 have the ability to filter counters based on privilege level, so
> > you can get more accurate userspace counts there.
> 
> Ok, that's better. Need to update libpfm4 for A15 with priv levels then!

How do you handle that in libpfm4? On ARM, the event encodings remain the same,
you just need to set some extra bits to determine which levels are included or
excluded (you can do this with the perf tool by using the :{u,k,h} suffix on an
event description).

Will

Re: oprofile and ARM A9 hardware counter

[stephane eranian]

On Fri, Jan 27, 2012 at 5:59 PM, Will Deacon <will.deacon@arm.com> wrote:
> On Fri, Jan 27, 2012 at 03:57:25PM +0000, stephane eranian wrote:
>> On Fri, Jan 27, 2012 at 4:54 PM, Will Deacon <will.deacon@arm.com> wrote:
>> >
>> > Ok. Note that on ARM the PMU generates a standard IRQ (i.e. not an NMI) so
>> > you may miss samples if they occur during critical kernel sections (and if
>> > you look at a profile, spin_unlock_irqrestore will be quite high).
>> >
>> But I am only running a user space noploop. So it spends 99% in user space, no
>> critical section.
>
> and your result is almost 99% of the way there :)
>
> There are also potential overheads from the PMU interrupts themselves, since
> there is a latency between overflow and taking the interrupt and then
> between there are actually reading the counter (they continue to count after
> overflow).
>
> That said, if you see any bugs in the code please do shout!
>
I suspect there is something wrong, we shouldn't hit the max_rate_limit.
You may have bursts of interrupts (samples). I'll check on that this week-end.

>> > A7 and A15 have the ability to filter counters based on privilege level, so
>> > you can get more accurate userspace counts there.
>>
>> Ok, that's better. Need to update libpfm4 for A15 with priv levels then!
>
> How do you handle that in libpfm4? On ARM, the event encodings remain the same,
> you just need to set some extra bits to determine which levels are included or
> excluded (you can do this with the perf tool by using the :{u,k,h} suffix on an
> event description).
>
It depends what you call the encoding? If the priv level can be encoded in the
attr->config field, then that's easy. If it needs to be set somewhere else, then
we need to figure out how you encode it in the attr struct. Either in some other
bits in attr->config or use attr->config1, for instance. You tell me.

> Will

oprofile and ARM A9 hardware counter

[stephane eranian]

On Fri, Jan 27, 2012 at 5:59 PM, Will Deacon <will.deacon@arm.com> wrote:
> On Fri, Jan 27, 2012 at 03:57:25PM +0000, stephane eranian wrote:
>> On Fri, Jan 27, 2012 at 4:54 PM, Will Deacon <will.deacon@arm.com> wrote:
>> >
>> > Ok. Note that on ARM the PMU generates a standard IRQ (i.e. not an NMI) so
>> > you may miss samples if they occur during critical kernel sections (and if
>> > you look at a profile, spin_unlock_irqrestore will be quite high).
>> >
>> But I am only running a user space noploop. So it spends 99% in user space, no
>> critical section.
>
> and your result is almost 99% of the way there :)
>
> There are also potential overheads from the PMU interrupts themselves, since
> there is a latency between overflow and taking the interrupt and then
> between there are actually reading the counter (they continue to count after
> overflow).
>
> That said, if you see any bugs in the code please do shout!
>
I suspect there is something wrong, we shouldn't hit the max_rate_limit.
You may have bursts of interrupts (samples). I'll check on that this week-end.

>> > A7 and A15 have the ability to filter counters based on privilege level, so
>> > you can get more accurate userspace counts there.
>>
>> Ok, that's better. Need to update libpfm4 for A15 with priv levels then!
>
> How do you handle that in libpfm4? On ARM, the event encodings remain the same,
> you just need to set some extra bits to determine which levels are included or
> excluded (you can do this with the perf tool by using the :{u,k,h} suffix on an
> event description).
>
It depends what you call the encoding? If the priv level can be encoded in the
attr->config field, then that's easy. If it needs to be set somewhere else, then
we need to figure out how you encode it in the attr struct. Either in some other
bits in attr->config or use attr->config1, for instance. You tell me.

> Will

Re: oprofile and ARM A9 hardware counter

[Will Deacon]

On Fri, Jan 27, 2012 at 05:03:28PM +0000, stephane eranian wrote:
> On Fri, Jan 27, 2012 at 5:59 PM, Will Deacon <will.deacon@arm.com> wrote:
> > That said, if you see any bugs in the code please do shout!
> >
> I suspect there is something wrong, we shouldn't hit the max_rate_limit.
> You may have bursts of interrupts (samples). I'll check on that this week-end.

Ok, thanks. Keep in mind that you probably have variable rate clocks, which
will affect the cycle counter frequency.

> >> > A7 and A15 have the ability to filter counters based on privilege level, so
> >> > you can get more accurate userspace counts there.
> >>
> >> Ok, that's better. Need to update libpfm4 for A15 with priv levels then!
> >
> > How do you handle that in libpfm4? On ARM, the event encodings remain the same,
> > you just need to set some extra bits to determine which levels are included or
> > excluded (you can do this with the perf tool by using the :{u,k,h} suffix on an
> > event description).
> >
> It depends what you call the encoding? If the priv level can be encoded in the
> attr->config field, then that's easy. If it needs to be set somewhere else, then
> we need to figure out how you encode it in the attr struct. Either in some other
> bits in attr->config or use attr->config1, for instance. You tell me.

The way it's done with perf is to set the exclude{user,kernel,hv} fields in
the attr. The ARM perf backend then translates these into the relevant bits
which get orred into the config_base before hitting the hardware.

Will

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2

oprofile and ARM A9 hardware counter

[Will Deacon]

On Fri, Jan 27, 2012 at 05:03:28PM +0000, stephane eranian wrote:
> On Fri, Jan 27, 2012 at 5:59 PM, Will Deacon <will.deacon@arm.com> wrote:
> > That said, if you see any bugs in the code please do shout!
> >
> I suspect there is something wrong, we shouldn't hit the max_rate_limit.
> You may have bursts of interrupts (samples). I'll check on that this week-end.

Ok, thanks. Keep in mind that you probably have variable rate clocks, which
will affect the cycle counter frequency.

> >> > A7 and A15 have the ability to filter counters based on privilege level, so
> >> > you can get more accurate userspace counts there.
> >>
> >> Ok, that's better. Need to update libpfm4 for A15 with priv levels then!
> >
> > How do you handle that in libpfm4? On ARM, the event encodings remain the same,
> > you just need to set some extra bits to determine which levels are included or
> > excluded (you can do this with the perf tool by using the :{u,k,h} suffix on an
> > event description).
> >
> It depends what you call the encoding? If the priv level can be encoded in the
> attr->config field, then that's easy. If it needs to be set somewhere else, then
> we need to figure out how you encode it in the attr struct. Either in some other
> bits in attr->config or use attr->config1, for instance. You tell me.

The way it's done with perf is to set the exclude{user,kernel,hv} fields in
the attr. The ARM perf backend then translates these into the relevant bits
which get orred into the config_base before hitting the hardware.

Will

Re: oprofile and ARM A9 hardware counter

[stephane eranian]

On Fri, Jan 27, 2012 at 6:10 PM, Will Deacon <will.deacon@arm.com> wrote:
> On Fri, Jan 27, 2012 at 05:03:28PM +0000, stephane eranian wrote:
>> On Fri, Jan 27, 2012 at 5:59 PM, Will Deacon <will.deacon@arm.com> wrote:
>> > That said, if you see any bugs in the code please do shout!
>> >
>> I suspect there is something wrong, we shouldn't hit the max_rate_limit.
>> You may have bursts of interrupts (samples). I'll check on that this week-end.
>
> Ok, thanks. Keep in mind that you probably have variable rate clocks, which
> will affect the cycle counter frequency.
>
I assume it does not vary the clock if the workload is steady and just burning
cycles, e.g.: for(;;);

>> >> > A7 and A15 have the ability to filter counters based on privilege level, so
>> >> > you can get more accurate userspace counts there.
>> >>
>> >> Ok, that's better. Need to update libpfm4 for A15 with priv levels then!
>> >
>> > How do you handle that in libpfm4? On ARM, the event encodings remain the same,
>> > you just need to set some extra bits to determine which levels are included or
>> > excluded (you can do this with the perf tool by using the :{u,k,h} suffix on an
>> > event description).
>> >
>> It depends what you call the encoding? If the priv level can be encoded in the
>> attr->config field, then that's easy. If it needs to be set somewhere else, then
>> we need to figure out how you encode it in the attr struct. Either in some other
>> bits in attr->config or use attr->config1, for instance. You tell me.
>
> The way it's done with perf is to set the exclude{user,kernel,hv} fields in
> the attr. The ARM perf backend then translates these into the relevant bits
> which get orred into the config_base before hitting the hardware.
>
Well, that's also how we do it with libpfm4 on X86. This is because
with perf_events,
the exclude_* fields have priority over what you set in the attr->config field.

> Will

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2

oprofile and ARM A9 hardware counter

[stephane eranian]

On Fri, Jan 27, 2012 at 6:10 PM, Will Deacon <will.deacon@arm.com> wrote:
> On Fri, Jan 27, 2012 at 05:03:28PM +0000, stephane eranian wrote:
>> On Fri, Jan 27, 2012 at 5:59 PM, Will Deacon <will.deacon@arm.com> wrote:
>> > That said, if you see any bugs in the code please do shout!
>> >
>> I suspect there is something wrong, we shouldn't hit the max_rate_limit.
>> You may have bursts of interrupts (samples). I'll check on that this week-end.
>
> Ok, thanks. Keep in mind that you probably have variable rate clocks, which
> will affect the cycle counter frequency.
>
I assume it does not vary the clock if the workload is steady and just burning
cycles, e.g.: for(;;);

>> >> > A7 and A15 have the ability to filter counters based on privilege level, so
>> >> > you can get more accurate userspace counts there.
>> >>
>> >> Ok, that's better. Need to update libpfm4 for A15 with priv levels then!
>> >
>> > How do you handle that in libpfm4? On ARM, the event encodings remain the same,
>> > you just need to set some extra bits to determine which levels are included or
>> > excluded (you can do this with the perf tool by using the :{u,k,h} suffix on an
>> > event description).
>> >
>> It depends what you call the encoding? If the priv level can be encoded in the
>> attr->config field, then that's easy. If it needs to be set somewhere else, then
>> we need to figure out how you encode it in the attr struct. Either in some other
>> bits in attr->config or use attr->config1, for instance. You tell me.
>
> The way it's done with perf is to set the exclude{user,kernel,hv} fields in
> the attr. The ARM perf backend then translates these into the relevant bits
> which get orred into the config_base before hitting the hardware.
>
Well, that's also how we do it with libpfm4 on X86. This is because
with perf_events,
the exclude_* fields have priority over what you set in the attr->config field.

> Will

Re: oprofile and ARM A9 hardware counter

[stephane eranian]

Hi,

Ok, so I did a few more tests and there is a serious issue when sampling
in frequency mode (the default). I noticed wrong number of samples, so
I investigated this some more and instrumented the perf_event kernel code.
I found some erratic timer ticks causing broken period adjustments.

In fact, the problem is visible using top.
I am running a noploop program on CPU0 and nothing else besides top.
The noploop program  does: for(;;);. That is 100% user. On a 2-way
system otherwise idle, I expect top to return 50% user 50% idle.

Top with the commit:

top - 16:19:21 up 5 min,  1 user,  load average: 0.23, 0.15, 0.07
Tasks:  70 total,   2 running,  68 sleeping,   0 stopped,   0 zombie
Cpu(s): 31.1%us,  2.0%sy,  0.0%ni, 66.2%id,  0.0%wa,  0.0%hi,  0.7%si,  0.0%st
            ^^^^^^^^ That's WRONG

Mem:    940292k total,    74984k used,   865308k free,     8020k buffers
Swap:   524240k total,        0k used,   524240k free,    37420k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 3770 eranian   20   0   644  160  128 R   99  0.0   0:14.21 noploop
 3771 eranian   20   0  2184 1052  804 R    2  0.1   0:00.32 top
    1 root      20   0  2564 1528  952 S    0  0.2   0:01.26 init


I removed that one liner patch from Ming. The one fiddling with the
clockdomains:

--- 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,


When I rerun, the test, it now work:

top - 16:02:51 up 15 min,  1 user,  load average: 1.02, 0.46, 0.21
Tasks:  70 total,   2 running,  68 sleeping,   0 stopped,   0 zombie
Cpu(s): 47.2%us,  1.0%sy,  0.0%ni, 50.8%id,  0.0%wa,  0.0%hi,  1.0%si,  0.0%st
           ^^^^^^^^ close enough (in it stabilize somehow around 49%
which is good)

Mem:    940292k total,    75288k used,   865004k free,     8004k buffers
Swap:   524240k total,        0k used,   524240k free,    37408k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 3771 eranian   20   0   644  160  128 R  100  0.0   0:34.44 noploop

Although the patch fixes PMU interrupts, it breaks the timer tick logic somehow.
The perf problem is related to timer tick.

I am hoping that the tradeoff is not:
     PMU interrupts but broken timer ticks
vs.
    No PMU interrupts but working timer ticks


On Fri, Jan 27, 2012 at 6:16 PM, stephane eranian
<eranian@googlemail.com> wrote:
> On Fri, Jan 27, 2012 at 6:10 PM, Will Deacon <will.deacon@arm.com> wrote:
>> On Fri, Jan 27, 2012 at 05:03:28PM +0000, stephane eranian wrote:
>>> On Fri, Jan 27, 2012 at 5:59 PM, Will Deacon <will.deacon@arm.com> wrote:
>>> > That said, if you see any bugs in the code please do shout!
>>> >
>>> I suspect there is something wrong, we shouldn't hit the max_rate_limit.
>>> You may have bursts of interrupts (samples). I'll check on that this week-end.
>>
>> Ok, thanks. Keep in mind that you probably have variable rate clocks, which
>> will affect the cycle counter frequency.
>>
> I assume it does not vary the clock if the workload is steady and just burning
> cycles, e.g.: for(;;);
>
>>> >> > A7 and A15 have the ability to filter counters based on privilege level, so
>>> >> > you can get more accurate userspace counts there.
>>> >>
>>> >> Ok, that's better. Need to update libpfm4 for A15 with priv levels then!
>>> >
>>> > How do you handle that in libpfm4? On ARM, the event encodings remain the same,
>>> > you just need to set some extra bits to determine which levels are included or
>>> > excluded (you can do this with the perf tool by using the :{u,k,h} suffix on an
>>> > event description).
>>> >
>>> It depends what you call the encoding? If the priv level can be encoded in the
>>> attr->config field, then that's easy. If it needs to be set somewhere else, then
>>> we need to figure out how you encode it in the attr struct. Either in some other
>>> bits in attr->config or use attr->config1, for instance. You tell me.
>>
>> The way it's done with perf is to set the exclude{user,kernel,hv} fields in
>> the attr. The ARM perf backend then translates these into the relevant bits
>> which get orred into the config_base before hitting the hardware.
>>
> Well, that's also how we do it with libpfm4 on X86. This is because
> with perf_events,
> the exclude_* fields have priority over what you set in the attr->config field.
>
>> Will

oprofile and ARM A9 hardware counter

[stephane eranian]

Hi,

Ok, so I did a few more tests and there is a serious issue when sampling
in frequency mode (the default). I noticed wrong number of samples, so
I investigated this some more and instrumented the perf_event kernel code.
I found some erratic timer ticks causing broken period adjustments.

In fact, the problem is visible using top.
I am running a noploop program on CPU0 and nothing else besides top.
The noploop program  does: for(;;);. That is 100% user. On a 2-way
system otherwise idle, I expect top to return 50% user 50% idle.

Top with the commit:

top - 16:19:21 up 5 min,  1 user,  load average: 0.23, 0.15, 0.07
Tasks:  70 total,   2 running,  68 sleeping,   0 stopped,   0 zombie
Cpu(s): 31.1%us,  2.0%sy,  0.0%ni, 66.2%id,  0.0%wa,  0.0%hi,  0.7%si,  0.0%st
            ^^^^^^^^ That's WRONG

Mem:    940292k total,    74984k used,   865308k free,     8020k buffers
Swap:   524240k total,        0k used,   524240k free,    37420k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 3770 eranian   20   0   644  160  128 R   99  0.0   0:14.21 noploop
 3771 eranian   20   0  2184 1052  804 R    2  0.1   0:00.32 top
    1 root      20   0  2564 1528  952 S    0  0.2   0:01.26 init


I removed that one liner patch from Ming. The one fiddling with the
clockdomains:

--- 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,


When I rerun, the test, it now work:

top - 16:02:51 up 15 min,  1 user,  load average: 1.02, 0.46, 0.21
Tasks:  70 total,   2 running,  68 sleeping,   0 stopped,   0 zombie
Cpu(s): 47.2%us,  1.0%sy,  0.0%ni, 50.8%id,  0.0%wa,  0.0%hi,  1.0%si,  0.0%st
           ^^^^^^^^ close enough (in it stabilize somehow around 49%
which is good)

Mem:    940292k total,    75288k used,   865004k free,     8004k buffers
Swap:   524240k total,        0k used,   524240k free,    37408k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 3771 eranian   20   0   644  160  128 R  100  0.0   0:34.44 noploop

Although the patch fixes PMU interrupts, it breaks the timer tick logic somehow.
The perf problem is related to timer tick.

I am hoping that the tradeoff is not:
     PMU interrupts but broken timer ticks
vs.
    No PMU interrupts but working timer ticks


On Fri, Jan 27, 2012 at 6:16 PM, stephane eranian
<eranian@googlemail.com> wrote:
> On Fri, Jan 27, 2012 at 6:10 PM, Will Deacon <will.deacon@arm.com> wrote:
>> On Fri, Jan 27, 2012 at 05:03:28PM +0000, stephane eranian wrote:
>>> On Fri, Jan 27, 2012 at 5:59 PM, Will Deacon <will.deacon@arm.com> wrote:
>>> > That said, if you see any bugs in the code please do shout!
>>> >
>>> I suspect there is something wrong, we shouldn't hit the max_rate_limit.
>>> You may have bursts of interrupts (samples). I'll check on that this week-end.
>>
>> Ok, thanks. Keep in mind that you probably have variable rate clocks, which
>> will affect the cycle counter frequency.
>>
> I assume it does not vary the clock if the workload is steady and just burning
> cycles, e.g.: for(;;);
>
>>> >> > A7 and A15 have the ability to filter counters based on privilege level, so
>>> >> > you can get more accurate userspace counts there.
>>> >>
>>> >> Ok, that's better. Need to update libpfm4 for A15 with priv levels then!
>>> >
>>> > How do you handle that in libpfm4? On ARM, the event encodings remain the same,
>>> > you just need to set some extra bits to determine which levels are included or
>>> > excluded (you can do this with the perf tool by using the :{u,k,h} suffix on an
>>> > event description).
>>> >
>>> It depends what you call the encoding? If the priv level can be encoded in the
>>> attr->config field, then that's easy. If it needs to be set somewhere else, then
>>> we need to figure out how you encode it in the attr struct. Either in some other
>>> bits in attr->config or use attr->config1, for instance. You tell me.
>>
>> The way it's done with perf is to set the exclude{user,kernel,hv} fields in
>> the attr. The ARM perf backend then translates these into the relevant bits
>> which get orred into the config_base before hitting the hardware.
>>
> Well, that's also how we do it with libpfm4 on X86. This is because
> with perf_events,
> the exclude_* fields have priority over what you set in the attr->config field.
>
>> Will

Re: oprofile and ARM A9 hardware counter

[Ming Lei]

Hi,

On Mon, Jan 30, 2012 at 1:36 AM, stephane eranian
<eranian@googlemail.com> wrote:
> Hi,
>
> Ok, so I did a few more tests and there is a serious issue when sampling
> in frequency mode (the default). I noticed wrong number of samples, so
> I investigated this some more and instrumented the perf_event kernel code.
> I found some erratic timer ticks causing broken period adjustments.
>
> In fact, the problem is visible using top.
> I am running a noploop program on CPU0 and nothing else besides top.
> The noploop program  does: for(;;);. That is 100% user. On a 2-way

Sometimes it is not 100% user, for example irq/exception handling...

> system otherwise idle, I expect top to return 50% user 50% idle.
>
> Top with the commit:
>
> top - 16:19:21 up 5 min,  1 user,  load average: 0.23, 0.15, 0.07
> Tasks:  70 total,   2 running,  68 sleeping,   0 stopped,   0 zombie
> Cpu(s): 31.1%us,  2.0%sy,  0.0%ni, 66.2%id,  0.0%wa,  0.0%hi,  0.7%si,  0.0%st
>            ^^^^^^^^ That's WRONG

Did you reproduce the issue each time or just occasionally?

Looks no such issue on my board with 3.3-rc1 plus the 5 extra pmu/emu patches.

top - 00:59:15 up 7 min,  1 user,  load average: 1.00, 0.73, 0.35
Tasks:  56 total,   2 running,  54 sleeping,   0 stopped,   0 zombie
Cpu(s): 42.6%us,  0.2%sy,  0.0%ni, 56.8%id,  0.0%wa,  0.0%hi,  0.4%si,  0.0%st
Mem:   1013560k total,    50960k used,   962600k free,     6272k buffers
Swap:        0k total,        0k used,        0k free,    29036k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 1355 root      20   0  1460  260  216 R   99  0.0   5:07.38 busy
  532 root      20   0     0    0    0 S    0  0.0   0:00.23 kworker/1:1
 1356 root      20   0  2552 1120  916 R    0  0.1   0:01.93 top

>
> Mem:    940292k total,    74984k used,   865308k free,     8020k buffers
> Swap:   524240k total,        0k used,   524240k free,    37420k cached
>
>  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>  3770 eranian   20   0 644 160 128 R   99  0.0   0:14.21 noploop
>  3771 eranian   20   0  2184 1052  804 R    2  0.1   0:00.32 top
>    1 root      20   0  2564 1528  952 S    0  0.2   0:01.26 init
>
>
> I removed that one liner patch from Ming. The one fiddling with the
> clockdomains:
>
> --- 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,

The patch should not affect timer tick logic, and what the patch does is
just to revert the commit [1]  wrt. emu clock domain.

>
> When I rerun, the test, it now work:
>
> top - 16:02:51 up 15 min,  1 user,  load average: 1.02, 0.46, 0.21
> Tasks:  70 total,   2 running,  68 sleeping,   0 stopped,   0 zombie
> Cpu(s): 47.2%us,  1.0%sy,  0.0%ni, 50.8%id,  0.0%wa,  0.0%hi,  1.0%si,  0.0%st
>           ^^^^^^^^ close enough (in it stabilize somehow around 49%
> which is good)
>
> Mem:    940292k total,    75288k used,   865004k free,     8004k buffers
> Swap:   524240k total,        0k used,   524240k free,    37408k cached
>
>  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>  3771 eranian   20   0 644 160 128 R  100  0.0   0:34.44 noploop
>
> Although the patch fixes PMU interrupts, it breaks the timer tick logic somehow.
> The perf problem is related to timer tick.
>
> I am hoping that the tradeoff is not:
>     PMU interrupts but broken timer ticks
> vs.
>    No PMU interrupts but working timer ticks



[1], 3c50729b3fa1cd8ca1f347e6caf1081204cf1a7c
ARM: OMAP4: PM: Initialise all the clockdomains to supported states

thanks
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

oprofile and ARM A9 hardware counter

[Ming Lei]

Hi,

On Mon, Jan 30, 2012 at 1:36 AM, stephane eranian
<eranian@googlemail.com> wrote:
> Hi,
>
> Ok, so I did a few more tests and there is a serious issue when sampling
> in frequency mode (the default). I noticed wrong number of samples, so
> I investigated this some more and instrumented the perf_event kernel code.
> I found some erratic timer ticks causing broken period adjustments.
>
> In fact, the problem is visible using top.
> I am running a noploop program on CPU0 and nothing else besides top.
> The noploop program ?does: for(;;);. That is 100% user. On a 2-way

Sometimes it is not 100% user, for example irq/exception handling...

> system otherwise idle, I expect top to return 50% user 50% idle.
>
> Top with the commit:
>
> top - 16:19:21 up 5 min, ?1 user, ?load average: 0.23, 0.15, 0.07
> Tasks: ?70 total, ? 2 running, ?68 sleeping, ? 0 stopped, ? 0 zombie
> Cpu(s): 31.1%us, ?2.0%sy, ?0.0%ni, 66.2%id, ?0.0%wa, ?0.0%hi, ?0.7%si, ?0.0%st
> ? ? ? ? ? ?^^^^^^^^ That's WRONG

Did you reproduce the issue each time or just occasionally?

Looks no such issue on my board with 3.3-rc1 plus the 5 extra pmu/emu patches.

top - 00:59:15 up 7 min,  1 user,  load average: 1.00, 0.73, 0.35
Tasks:  56 total,   2 running,  54 sleeping,   0 stopped,   0 zombie
Cpu(s): 42.6%us,  0.2%sy,  0.0%ni, 56.8%id,  0.0%wa,  0.0%hi,  0.4%si,  0.0%st
Mem:   1013560k total,    50960k used,   962600k free,     6272k buffers
Swap:        0k total,        0k used,        0k free,    29036k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 1355 root      20   0  1460  260  216 R   99  0.0   5:07.38 busy
  532 root      20   0     0    0    0 S    0  0.0   0:00.23 kworker/1:1
 1356 root      20   0  2552 1120  916 R    0  0.1   0:01.93 top

>
> Mem: ? ?940292k total, ? ?74984k used, ? 865308k free, ? ? 8020k buffers
> Swap: ? 524240k total, ? ? ? ?0k used, ? 524240k free, ? ?37420k cached
>
> ?PID USER ? ? ?PR ?NI ?VIRT ?RES ?SHR S %CPU %MEM ? ?TIME+ ?COMMAND
> ?3770 eranian ? 20 ? 0 644 160 128 R ? 99 ?0.0 ? 0:14.21 noploop
> ?3771 eranian ? 20 ? 0 ?2184 1052 ?804 R ? ?2 ?0.1 ? 0:00.32 top
> ? ?1 root ? ? ?20 ? 0 ?2564 1528 ?952 S ? ?0 ?0.2 ? 0:01.26 init
>
>
> I removed that one liner patch from Ming. The one fiddling with the
> clockdomains:
>
> --- 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,

The patch should not affect timer tick logic, and what the patch does is
just to revert the commit [1]  wrt. emu clock domain.

>
> When I rerun, the test, it now work:
>
> top - 16:02:51 up 15 min, ?1 user, ?load average: 1.02, 0.46, 0.21
> Tasks: ?70 total, ? 2 running, ?68 sleeping, ? 0 stopped, ? 0 zombie
> Cpu(s): 47.2%us, ?1.0%sy, ?0.0%ni, 50.8%id, ?0.0%wa, ?0.0%hi, ?1.0%si, ?0.0%st
> ? ? ? ? ? ^^^^^^^^ close enough (in it stabilize somehow around 49%
> which is good)
>
> Mem: ? ?940292k total, ? ?75288k used, ? 865004k free, ? ? 8004k buffers
> Swap: ? 524240k total, ? ? ? ?0k used, ? 524240k free, ? ?37408k cached
>
> ?PID USER ? ? ?PR ?NI ?VIRT ?RES ?SHR S %CPU %MEM ? ?TIME+ ?COMMAND
> ?3771 eranian ? 20 ? 0 644 160 128 R ?100 ?0.0 ? 0:34.44 noploop
>
> Although the patch fixes PMU interrupts, it breaks the timer tick logic somehow.
> The perf problem is related to timer tick.
>
> I am hoping that the tradeoff is not:
> ? ? PMU interrupts but broken timer ticks
> vs.
> ? ?No PMU interrupts but working timer ticks



[1], 3c50729b3fa1cd8ca1f347e6caf1081204cf1a7c
ARM: OMAP4: PM: Initialise all the clockdomains to supported states

thanks
--
Ming Lei

Re: oprofile and ARM A9 hardware counter

[stephane eranian]

Ok, let me try again with 3.3.0-rc1, that was with 3.2.0.
The only thing that changed was that one line and it made
a big difference.


On Mon, Jan 30, 2012 at 10:40 AM, Ming Lei <ming.lei@canonical.com> wrote:
> Hi,
>
> On Mon, Jan 30, 2012 at 1:36 AM, stephane eranian
> <eranian@googlemail.com> wrote:
>> Hi,
>>
>> Ok, so I did a few more tests and there is a serious issue when sampling
>> in frequency mode (the default). I noticed wrong number of samples, so
>> I investigated this some more and instrumented the perf_event kernel code.
>> I found some erratic timer ticks causing broken period adjustments.
>>
>> In fact, the problem is visible using top.
>> I am running a noploop program on CPU0 and nothing else besides top.
>> The noploop program  does: for(;;);. That is 100% user. On a 2-way
>
> Sometimes it is not 100% user, for example irq/exception handling...
>
>> system otherwise idle, I expect top to return 50% user 50% idle.
>>
>> Top with the commit:
>>
>> top - 16:19:21 up 5 min,  1 user,  load average: 0.23, 0.15, 0.07
>> Tasks:  70 total,   2 running,  68 sleeping,   0 stopped,   0 zombie
>> Cpu(s): 31.1%us,  2.0%sy,  0.0%ni, 66.2%id,  0.0%wa,  0.0%hi,  0.7%si,  0.0%st
>>            ^^^^^^^^ That's WRONG
>
> Did you reproduce the issue each time or just occasionally?
>
> Looks no such issue on my board with 3.3-rc1 plus the 5 extra pmu/emu patches.
>
> top - 00:59:15 up 7 min,  1 user,  load average: 1.00, 0.73, 0.35
> Tasks:  56 total,   2 running,  54 sleeping,   0 stopped,   0 zombie
> Cpu(s): 42.6%us,  0.2%sy,  0.0%ni, 56.8%id,  0.0%wa,  0.0%hi,  0.4%si,  0.0%st
> Mem:   1013560k total,    50960k used,   962600k free,     6272k buffers
> Swap:        0k total,        0k used,        0k free,    29036k cached
>
>  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>  1355 root      20   0  1460  260  216 R   99  0.0   5:07.38 busy
>  532 root      20   0     0    0    0 S    0  0.0   0:00.23 kworker/1:1
>  1356 root      20   0  2552 1120  916 R    0  0.1   0:01.93 top
>
>>
>> Mem:    940292k total,    74984k used,   865308k free,     8020k buffers
>> Swap:   524240k total,        0k used,   524240k free,    37420k cached
>>
>>  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>>  3770 eranian   20   0 644 160 128 R   99  0.0   0:14.21 noploop
>>  3771 eranian   20   0  2184 1052  804 R    2  0.1   0:00.32 top
>>    1 root      20   0  2564 1528  952 S    0  0.2   0:01.26 init
>>
>>
>> I removed that one liner patch from Ming. The one fiddling with the
>> clockdomains:
>>
>> --- 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,
>
> The patch should not affect timer tick logic, and what the patch does is
> just to revert the commit [1]  wrt. emu clock domain.
>
>>
>> When I rerun, the test, it now work:
>>
>> top - 16:02:51 up 15 min,  1 user,  load average: 1.02, 0.46, 0.21
>> Tasks:  70 total,   2 running,  68 sleeping,   0 stopped,   0 zombie
>> Cpu(s): 47.2%us,  1.0%sy,  0.0%ni, 50.8%id,  0.0%wa,  0.0%hi,  1.0%si,  0.0%st
>>           ^^^^^^^^ close enough (in it stabilize somehow around 49%
>> which is good)
>>
>> Mem:    940292k total,    75288k used,   865004k free,     8004k buffers
>> Swap:   524240k total,        0k used,   524240k free,    37408k cached
>>
>>  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>>  3771 eranian   20   0 644 160 128 R  100  0.0   0:34.44 noploop
>>
>> Although the patch fixes PMU interrupts, it breaks the timer tick logic somehow.
>> The perf problem is related to timer tick.
>>
>> I am hoping that the tradeoff is not:
>>     PMU interrupts but broken timer ticks
>> vs.
>>    No PMU interrupts but working timer ticks
>
>
>
> [1], 3c50729b3fa1cd8ca1f347e6caf1081204cf1a7c
> ARM: OMAP4: PM: Initialise all the clockdomains to supported states
>
> thanks
> --
> Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

oprofile and ARM A9 hardware counter

[stephane eranian]

Ok, let me try again with 3.3.0-rc1, that was with 3.2.0.
The only thing that changed was that one line and it made
a big difference.


On Mon, Jan 30, 2012 at 10:40 AM, Ming Lei <ming.lei@canonical.com> wrote:
> Hi,
>
> On Mon, Jan 30, 2012 at 1:36 AM, stephane eranian
> <eranian@googlemail.com> wrote:
>> Hi,
>>
>> Ok, so I did a few more tests and there is a serious issue when sampling
>> in frequency mode (the default). I noticed wrong number of samples, so
>> I investigated this some more and instrumented the perf_event kernel code.
>> I found some erratic timer ticks causing broken period adjustments.
>>
>> In fact, the problem is visible using top.
>> I am running a noploop program on CPU0 and nothing else besides top.
>> The noploop program ?does: for(;;);. That is 100% user. On a 2-way
>
> Sometimes it is not 100% user, for example irq/exception handling...
>
>> system otherwise idle, I expect top to return 50% user 50% idle.
>>
>> Top with the commit:
>>
>> top - 16:19:21 up 5 min, ?1 user, ?load average: 0.23, 0.15, 0.07
>> Tasks: ?70 total, ? 2 running, ?68 sleeping, ? 0 stopped, ? 0 zombie
>> Cpu(s): 31.1%us, ?2.0%sy, ?0.0%ni, 66.2%id, ?0.0%wa, ?0.0%hi, ?0.7%si, ?0.0%st
>> ? ? ? ? ? ?^^^^^^^^ That's WRONG
>
> Did you reproduce the issue each time or just occasionally?
>
> Looks no such issue on my board with 3.3-rc1 plus the 5 extra pmu/emu patches.
>
> top - 00:59:15 up 7 min, ?1 user, ?load average: 1.00, 0.73, 0.35
> Tasks: ?56 total, ? 2 running, ?54 sleeping, ? 0 stopped, ? 0 zombie
> Cpu(s): 42.6%us, ?0.2%sy, ?0.0%ni, 56.8%id, ?0.0%wa, ?0.0%hi, ?0.4%si, ?0.0%st
> Mem: ? 1013560k total, ? ?50960k used, ? 962600k free, ? ? 6272k buffers
> Swap: ? ? ? ?0k total, ? ? ? ?0k used, ? ? ? ?0k free, ? ?29036k cached
>
> ?PID USER ? ? ?PR ?NI ?VIRT ?RES ?SHR S %CPU %MEM ? ?TIME+ ?COMMAND
> ?1355 root ? ? ?20 ? 0 ?1460 ?260 ?216 R ? 99 ?0.0 ? 5:07.38 busy
> ?532 root ? ? ?20 ? 0 ? ? 0 ? ?0 ? ?0 S ? ?0 ?0.0 ? 0:00.23 kworker/1:1
> ?1356 root ? ? ?20 ? 0 ?2552 1120 ?916 R ? ?0 ?0.1 ? 0:01.93 top
>
>>
>> Mem: ? ?940292k total, ? ?74984k used, ? 865308k free, ? ? 8020k buffers
>> Swap: ? 524240k total, ? ? ? ?0k used, ? 524240k free, ? ?37420k cached
>>
>> ?PID USER ? ? ?PR ?NI ?VIRT ?RES ?SHR S %CPU %MEM ? ?TIME+ ?COMMAND
>> ?3770 eranian ? 20 ? 0 644 160 128 R ? 99 ?0.0 ? 0:14.21 noploop
>> ?3771 eranian ? 20 ? 0 ?2184 1052 ?804 R ? ?2 ?0.1 ? 0:00.32 top
>> ? ?1 root ? ? ?20 ? 0 ?2564 1528 ?952 S ? ?0 ?0.2 ? 0:01.26 init
>>
>>
>> I removed that one liner patch from Ming. The one fiddling with the
>> clockdomains:
>>
>> --- 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,
>
> The patch should not affect timer tick logic, and what the patch does is
> just to revert the commit [1] ?wrt. emu clock domain.
>
>>
>> When I rerun, the test, it now work:
>>
>> top - 16:02:51 up 15 min, ?1 user, ?load average: 1.02, 0.46, 0.21
>> Tasks: ?70 total, ? 2 running, ?68 sleeping, ? 0 stopped, ? 0 zombie
>> Cpu(s): 47.2%us, ?1.0%sy, ?0.0%ni, 50.8%id, ?0.0%wa, ?0.0%hi, ?1.0%si, ?0.0%st
>> ? ? ? ? ? ^^^^^^^^ close enough (in it stabilize somehow around 49%
>> which is good)
>>
>> Mem: ? ?940292k total, ? ?75288k used, ? 865004k free, ? ? 8004k buffers
>> Swap: ? 524240k total, ? ? ? ?0k used, ? 524240k free, ? ?37408k cached
>>
>> ?PID USER ? ? ?PR ?NI ?VIRT ?RES ?SHR S %CPU %MEM ? ?TIME+ ?COMMAND
>> ?3771 eranian ? 20 ? 0 644 160 128 R ?100 ?0.0 ? 0:34.44 noploop
>>
>> Although the patch fixes PMU interrupts, it breaks the timer tick logic somehow.
>> The perf problem is related to timer tick.
>>
>> I am hoping that the tradeoff is not:
>> ? ? PMU interrupts but broken timer ticks
>> vs.
>> ? ?No PMU interrupts but working timer ticks
>
>
>
> [1], 3c50729b3fa1cd8ca1f347e6caf1081204cf1a7c
> ARM: OMAP4: PM: Initialise all the clockdomains to supported states
>
> thanks
> --
> Ming Lei

Re: oprofile and ARM A9 hardware counter

[stephane eranian]

Same results for me with 3.3.0-rc1 + 5 patches.


top - 14:42:34 up 8 min,  1 user,  load average: 0.70, 0.29, 0.15
Tasks:  75 total,   2 running,  73 sleeping,   0 stopped,   0 zombie
Cpu(s): 32.9%us,  1.3%sy,  0.0%ni, 65.8%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:    940232k total,   118520k used,   821712k free,     8080k buffers
Swap:   524240k total,        0k used,   524240k free,    79432k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 3868 eranian   20   0   644  160  128 R   99  0.0   0:53.34 noploop
 3870 eranian   20   0  2284 1060  804 R    3  0.1   0:00.63 top
    1 root      20   0  2564 1532  952 S    0  0.2   0:01.26 init

I am connecting to the board via ssh.
But the results don't look correct to me.

On Mon, Jan 30, 2012 at 11:24 AM, stephane eranian
<eranian@googlemail.com> wrote:
> Ok, let me try again with 3.3.0-rc1, that was with 3.2.0.
> The only thing that changed was that one line and it made
> a big difference.
>
>
> On Mon, Jan 30, 2012 at 10:40 AM, Ming Lei <ming.lei@canonical.com> wrote:
>> Hi,
>>
>> On Mon, Jan 30, 2012 at 1:36 AM, stephane eranian
>> <eranian@googlemail.com> wrote:
>>> Hi,
>>>
>>> Ok, so I did a few more tests and there is a serious issue when sampling
>>> in frequency mode (the default). I noticed wrong number of samples, so
>>> I investigated this some more and instrumented the perf_event kernel code.
>>> I found some erratic timer ticks causing broken period adjustments.
>>>
>>> In fact, the problem is visible using top.
>>> I am running a noploop program on CPU0 and nothing else besides top.
>>> The noploop program  does: for(;;);. That is 100% user. On a 2-way
>>
>> Sometimes it is not 100% user, for example irq/exception handling...
>>
>>> system otherwise idle, I expect top to return 50% user 50% idle.
>>>
>>> Top with the commit:
>>>
>>> top - 16:19:21 up 5 min,  1 user,  load average: 0.23, 0.15, 0.07
>>> Tasks:  70 total,   2 running,  68 sleeping,   0 stopped,   0 zombie
>>> Cpu(s): 31.1%us,  2.0%sy,  0.0%ni, 66.2%id,  0.0%wa,  0.0%hi,  0.7%si,  0.0%st
>>>            ^^^^^^^^ That's WRONG
>>
>> Did you reproduce the issue each time or just occasionally?
>>
>> Looks no such issue on my board with 3.3-rc1 plus the 5 extra pmu/emu patches.
>>
>> top - 00:59:15 up 7 min,  1 user,  load average: 1.00, 0.73, 0.35
>> Tasks:  56 total,   2 running,  54 sleeping,   0 stopped,   0 zombie
>> Cpu(s): 42.6%us,  0.2%sy,  0.0%ni, 56.8%id,  0.0%wa,  0.0%hi,  0.4%si,  0.0%st
>> Mem:   1013560k total,    50960k used,   962600k free,     6272k buffers
>> Swap:        0k total,        0k used,        0k free,    29036k cached
>>
>>  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>>  1355 root      20   0  1460  260  216 R   99  0.0   5:07.38 busy
>>  532 root      20   0     0    0    0 S    0  0.0   0:00.23 kworker/1:1
>>  1356 root      20   0  2552 1120  916 R    0  0.1   0:01.93 top
>>
>>>
>>> Mem:    940292k total,    74984k used,   865308k free,     8020k buffers
>>> Swap:   524240k total,        0k used,   524240k free,    37420k cached
>>>
>>>  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>>>  3770 eranian   20   0 644 160 128 R   99  0.0   0:14.21 noploop
>>>  3771 eranian   20   0  2184 1052  804 R    2  0.1   0:00.32 top
>>>    1 root      20   0  2564 1528  952 S    0  0.2   0:01.26 init
>>>
>>>
>>> I removed that one liner patch from Ming. The one fiddling with the
>>> clockdomains:
>>>
>>> --- 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,
>>
>> The patch should not affect timer tick logic, and what the patch does is
>> just to revert the commit [1]  wrt. emu clock domain.
>>
>>>
>>> When I rerun, the test, it now work:
>>>
>>> top - 16:02:51 up 15 min,  1 user,  load average: 1.02, 0.46, 0.21
>>> Tasks:  70 total,   2 running,  68 sleeping,   0 stopped,   0 zombie
>>> Cpu(s): 47.2%us,  1.0%sy,  0.0%ni, 50.8%id,  0.0%wa,  0.0%hi,  1.0%si,  0.0%st
>>>           ^^^^^^^^ close enough (in it stabilize somehow around 49%
>>> which is good)
>>>
>>> Mem:    940292k total,    75288k used,   865004k free,     8004k buffers
>>> Swap:   524240k total,        0k used,   524240k free,    37408k cached
>>>
>>>  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>>>  3771 eranian   20   0 644 160 128 R  100  0.0   0:34.44 noploop
>>>
>>> Although the patch fixes PMU interrupts, it breaks the timer tick logic somehow.
>>> The perf problem is related to timer tick.
>>>
>>> I am hoping that the tradeoff is not:
>>>     PMU interrupts but broken timer ticks
>>> vs.
>>>    No PMU interrupts but working timer ticks
>>
>>
>>
>> [1], 3c50729b3fa1cd8ca1f347e6caf1081204cf1a7c
>> ARM: OMAP4: PM: Initialise all the clockdomains to supported states
>>
>> thanks
>> --
>> Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

oprofile and ARM A9 hardware counter

[stephane eranian]

Same results for me with 3.3.0-rc1 + 5 patches.


top - 14:42:34 up 8 min, ?1 user, ?load average: 0.70, 0.29, 0.15
Tasks: ?75 total, ? 2 running, ?73 sleeping, ? 0 stopped, ? 0 zombie
Cpu(s): 32.9%us, ?1.3%sy, ?0.0%ni, 65.8%id, ?0.0%wa, ?0.0%hi, ?0.0%si, ?0.0%st
Mem: ? ?940232k total, ? 118520k used, ? 821712k free, ? ? 8080k buffers
Swap: ? 524240k total, ? ? ? ?0k used, ? 524240k free, ? ?79432k cached

? PID USER ? ? ?PR ?NI ?VIRT ?RES ?SHR S %CPU %MEM ? ?TIME+ ?COMMAND
?3868 eranian ? 20 ? 0 ? 644 ?160 ?128 R ? 99 ?0.0 ? 0:53.34 noploop
?3870 eranian ? 20 ? 0 ?2284 1060 ?804 R ? ?3 ?0.1 ? 0:00.63 top
? ? 1 root ? ? ?20 ? 0 ?2564 1532 ?952 S ? ?0 ?0.2 ? 0:01.26 init

I am connecting to the board via ssh.
But the results don't look correct to me.

On Mon, Jan 30, 2012 at 11:24 AM, stephane eranian
<eranian@googlemail.com> wrote:
> Ok, let me try again with 3.3.0-rc1, that was with 3.2.0.
> The only thing that changed was that one line and it made
> a big difference.
>
>
> On Mon, Jan 30, 2012 at 10:40 AM, Ming Lei <ming.lei@canonical.com> wrote:
>> Hi,
>>
>> On Mon, Jan 30, 2012 at 1:36 AM, stephane eranian
>> <eranian@googlemail.com> wrote:
>>> Hi,
>>>
>>> Ok, so I did a few more tests and there is a serious issue when sampling
>>> in frequency mode (the default). I noticed wrong number of samples, so
>>> I investigated this some more and instrumented the perf_event kernel code.
>>> I found some erratic timer ticks causing broken period adjustments.
>>>
>>> In fact, the problem is visible using top.
>>> I am running a noploop program on CPU0 and nothing else besides top.
>>> The noploop program ?does: for(;;);. That is 100% user. On a 2-way
>>
>> Sometimes it is not 100% user, for example irq/exception handling...
>>
>>> system otherwise idle, I expect top to return 50% user 50% idle.
>>>
>>> Top with the commit:
>>>
>>> top - 16:19:21 up 5 min, ?1 user, ?load average: 0.23, 0.15, 0.07
>>> Tasks: ?70 total, ? 2 running, ?68 sleeping, ? 0 stopped, ? 0 zombie
>>> Cpu(s): 31.1%us, ?2.0%sy, ?0.0%ni, 66.2%id, ?0.0%wa, ?0.0%hi, ?0.7%si, ?0.0%st
>>> ? ? ? ? ? ?^^^^^^^^ That's WRONG
>>
>> Did you reproduce the issue each time or just occasionally?
>>
>> Looks no such issue on my board with 3.3-rc1 plus the 5 extra pmu/emu patches.
>>
>> top - 00:59:15 up 7 min, ?1 user, ?load average: 1.00, 0.73, 0.35
>> Tasks: ?56 total, ? 2 running, ?54 sleeping, ? 0 stopped, ? 0 zombie
>> Cpu(s): 42.6%us, ?0.2%sy, ?0.0%ni, 56.8%id, ?0.0%wa, ?0.0%hi, ?0.4%si, ?0.0%st
>> Mem: ? 1013560k total, ? ?50960k used, ? 962600k free, ? ? 6272k buffers
>> Swap: ? ? ? ?0k total, ? ? ? ?0k used, ? ? ? ?0k free, ? ?29036k cached
>>
>> ?PID USER ? ? ?PR ?NI ?VIRT ?RES ?SHR S %CPU %MEM ? ?TIME+ ?COMMAND
>> ?1355 root ? ? ?20 ? 0 ?1460 ?260 ?216 R ? 99 ?0.0 ? 5:07.38 busy
>> ?532 root ? ? ?20 ? 0 ? ? 0 ? ?0 ? ?0 S ? ?0 ?0.0 ? 0:00.23 kworker/1:1
>> ?1356 root ? ? ?20 ? 0 ?2552 1120 ?916 R ? ?0 ?0.1 ? 0:01.93 top
>>
>>>
>>> Mem: ? ?940292k total, ? ?74984k used, ? 865308k free, ? ? 8020k buffers
>>> Swap: ? 524240k total, ? ? ? ?0k used, ? 524240k free, ? ?37420k cached
>>>
>>> ?PID USER ? ? ?PR ?NI ?VIRT ?RES ?SHR S %CPU %MEM ? ?TIME+ ?COMMAND
>>> ?3770 eranian ? 20 ? 0 644 160 128 R ? 99 ?0.0 ? 0:14.21 noploop
>>> ?3771 eranian ? 20 ? 0 ?2184 1052 ?804 R ? ?2 ?0.1 ? 0:00.32 top
>>> ? ?1 root ? ? ?20 ? 0 ?2564 1528 ?952 S ? ?0 ?0.2 ? 0:01.26 init
>>>
>>>
>>> I removed that one liner patch from Ming. The one fiddling with the
>>> clockdomains:
>>>
>>> --- 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,
>>
>> The patch should not affect timer tick logic, and what the patch does is
>> just to revert the commit [1] ?wrt. emu clock domain.
>>
>>>
>>> When I rerun, the test, it now work:
>>>
>>> top - 16:02:51 up 15 min, ?1 user, ?load average: 1.02, 0.46, 0.21
>>> Tasks: ?70 total, ? 2 running, ?68 sleeping, ? 0 stopped, ? 0 zombie
>>> Cpu(s): 47.2%us, ?1.0%sy, ?0.0%ni, 50.8%id, ?0.0%wa, ?0.0%hi, ?1.0%si, ?0.0%st
>>> ? ? ? ? ? ^^^^^^^^ close enough (in it stabilize somehow around 49%
>>> which is good)
>>>
>>> Mem: ? ?940292k total, ? ?75288k used, ? 865004k free, ? ? 8004k buffers
>>> Swap: ? 524240k total, ? ? ? ?0k used, ? 524240k free, ? ?37408k cached
>>>
>>> ?PID USER ? ? ?PR ?NI ?VIRT ?RES ?SHR S %CPU %MEM ? ?TIME+ ?COMMAND
>>> ?3771 eranian ? 20 ? 0 644 160 128 R ?100 ?0.0 ? 0:34.44 noploop
>>>
>>> Although the patch fixes PMU interrupts, it breaks the timer tick logic somehow.
>>> The perf problem is related to timer tick.
>>>
>>> I am hoping that the tradeoff is not:
>>> ? ? PMU interrupts but broken timer ticks
>>> vs.
>>> ? ?No PMU interrupts but working timer ticks
>>
>>
>>
>> [1], 3c50729b3fa1cd8ca1f347e6caf1081204cf1a7c
>> ARM: OMAP4: PM: Initialise all the clockdomains to supported states
>>
>> thanks
>> --
>> Ming Lei

Re: oprofile and ARM A9 hardware counter

[Ming Lei]

On Mon, Jan 30, 2012 at 9:43 PM, stephane eranian
<eranian@googlemail.com> wrote:
> Same results for me with 3.3.0-rc1 + 5 patches.

In fact, I think the only effect of the patch is to enable pmu
interrupt handling,
which may cause so much difference?

Also maybe you should put 'noploop' to run on CPU1 and you may observe
a more accurate result of 'top'.

On ARM, almost handling of all IRQs from gic is run on CPU0 at default,
which may cause your issue.

>
>
> top - 14:42:34 up 8 min,  1 user,  load average: 0.70, 0.29, 0.15
> Tasks:  75 total,   2 running,  73 sleeping,   0 stopped,   0 zombie
> Cpu(s): 32.9%us,  1.3%sy,  0.0%ni, 65.8%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
> Mem:    940232k total,   118520k used,   821712k free,     8080k buffers
> Swap:   524240k total,        0k used,   524240k free,    79432k cached
>
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>  3868 eranian   20   0   644  160  128 R   99  0.0   0:53.34 noploop
>  3870 eranian   20   0  2284 1060  804 R    3  0.1   0:00.63 top
>     1 root      20   0  2564 1532  952 S    0  0.2   0:01.26 init
>
> I am connecting to the board via ssh.
> But the results don't look correct to me.

thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

oprofile and ARM A9 hardware counter

[Ming Lei]

On Mon, Jan 30, 2012 at 9:43 PM, stephane eranian
<eranian@googlemail.com> wrote:
> Same results for me with 3.3.0-rc1 + 5 patches.

In fact, I think the only effect of the patch is to enable pmu
interrupt handling,
which may cause so much difference?

Also maybe you should put 'noploop' to run on CPU1 and you may observe
a more accurate result of 'top'.

On ARM, almost handling of all IRQs from gic is run on CPU0 at default,
which may cause your issue.

>
>
> top - 14:42:34 up 8 min, ?1 user, ?load average: 0.70, 0.29, 0.15
> Tasks: ?75 total, ? 2 running, ?73 sleeping, ? 0 stopped, ? 0 zombie
> Cpu(s): 32.9%us, ?1.3%sy, ?0.0%ni, 65.8%id, ?0.0%wa, ?0.0%hi, ?0.0%si, ?0.0%st
> Mem: ? ?940232k total, ? 118520k used, ? 821712k free, ? ? 8080k buffers
> Swap: ? 524240k total, ? ? ? ?0k used, ? 524240k free, ? ?79432k cached
>
> ? PID USER ? ? ?PR ?NI ?VIRT ?RES ?SHR S %CPU %MEM ? ?TIME+ ?COMMAND
> ?3868 eranian ? 20 ? 0 ? 644 ?160 ?128 R ? 99 ?0.0 ? 0:53.34 noploop
> ?3870 eranian ? 20 ? 0 ?2284 1060 ?804 R ? ?3 ?0.1 ? 0:00.63 top
> ? ? 1 root ? ? ?20 ? 0 ?2564 1532 ?952 S ? ?0 ?0.2 ? 0:01.26 init
>
> I am connecting to the board via ssh.
> But the results don't look correct to me.

thanks,
--
Ming Lei

Re: oprofile and ARM A9 hardware counter

[stephane eranian]

Same result for me on CPU1:

top - 16:20:24 up  1:45,  1 user,  load average: 0.29, 0.08, 0.07
Tasks:  70 total,   2 running,  68 sleeping,   0 stopped,   0 zombie
Cpu(s): 30.7%us,  2.7%sy,  0.0%ni, 66.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:    940232k total,   228984k used,   711248k free,    82244k buffers
Swap:   524240k total,        0k used,   524240k free,    91400k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  P COMMAND
 3968 eranian   20   0   644  160  128 R  100  0.0   0:21.98 1 noploop
 3969 eranian   20   0  2184 1056  804 R    3  0.1   0:00.53 0 top
   82 root      20   0     0    0    0 S    1  0.0   0:01.35 0
kworker/0:1

With 3.3.0-rc1, if I revert the clockdomain patch, I get the same result.
So it must be coming from somewhere else, as you suggested.

If the processor was spending time processing interrupts, then this would be
accounted for in as sys time. But that's not what I observe here. It's either
idle or user. That line, leads me to believe that the processor can only run
my program for 30% of the time. The rest is spent idling even though my
program is non-blocking. How could that be possible? Power-saving?


On Mon, Jan 30, 2012 at 3:49 PM, Ming Lei <ming.lei@canonical.com> wrote:
> On Mon, Jan 30, 2012 at 9:43 PM, stephane eranian
> <eranian@googlemail.com> wrote:
>> Same results for me with 3.3.0-rc1 + 5 patches.
>
> In fact, I think the only effect of the patch is to enable pmu
> interrupt handling,
> which may cause so much difference?
>
> Also maybe you should put 'noploop' to run on CPU1 and you may observe
> a more accurate result of 'top'.
>
> On ARM, almost handling of all IRQs from gic is run on CPU0 at default,
> which may cause your issue.
>
>>
>>
>> top - 14:42:34 up 8 min,  1 user,  load average: 0.70, 0.29, 0.15
>> Tasks:  75 total,   2 running,  73 sleeping,   0 stopped,   0 zombie
>> Cpu(s): 32.9%us,  1.3%sy,  0.0%ni, 65.8%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
>> Mem:    940232k total,   118520k used,   821712k free,     8080k buffers
>> Swap:   524240k total,        0k used,   524240k free,    79432k cached
>>
>>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>>  3868 eranian   20   0   644  160  128 R   99  0.0   0:53.34 noploop
>>  3870 eranian   20   0  2284 1060  804 R    3  0.1   0:00.63 top
>>     1 root      20   0  2564 1532  952 S    0  0.2   0:01.26 init
>>
>> I am connecting to the board via ssh.
>> But the results don't look correct to me.
>
> thanks,
> --
> Ming Lei

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
oprofile-list mailing list
oprofile-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oprofile-list

oprofile and ARM A9 hardware counter

[stephane eranian]

Same result for me on CPU1:

top - 16:20:24 up  1:45,  1 user,  load average: 0.29, 0.08, 0.07
Tasks:  70 total,   2 running,  68 sleeping,   0 stopped,   0 zombie
Cpu(s): 30.7%us,  2.7%sy,  0.0%ni, 66.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:    940232k total,   228984k used,   711248k free,    82244k buffers
Swap:   524240k total,        0k used,   524240k free,    91400k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  P COMMAND
 3968 eranian   20   0   644  160  128 R  100  0.0   0:21.98 1 noploop
 3969 eranian   20   0  2184 1056  804 R    3  0.1   0:00.53 0 top
   82 root      20   0     0    0    0 S    1  0.0   0:01.35 0
kworker/0:1

With 3.3.0-rc1, if I revert the clockdomain patch, I get the same result.
So it must be coming from somewhere else, as you suggested.

If the processor was spending time processing interrupts, then this would be
accounted for in as sys time. But that's not what I observe here. It's either
idle or user. That line, leads me to believe that the processor can only run
my program for 30% of the time. The rest is spent idling even though my
program is non-blocking. How could that be possible? Power-saving?


On Mon, Jan 30, 2012 at 3:49 PM, Ming Lei <ming.lei@canonical.com> wrote:
> On Mon, Jan 30, 2012 at 9:43 PM, stephane eranian
> <eranian@googlemail.com> wrote:
>> Same results for me with 3.3.0-rc1 + 5 patches.
>
> In fact, I think the only effect of the patch is to enable pmu
> interrupt handling,
> which may cause so much difference?
>
> Also maybe you should put 'noploop' to run on CPU1 and you may observe
> a more accurate result of 'top'.
>
> On ARM, almost handling of all IRQs from gic is run on CPU0 at default,
> which may cause your issue.
>
>>
>>
>> top - 14:42:34 up 8 min, ?1 user, ?load average: 0.70, 0.29, 0.15
>> Tasks: ?75 total, ? 2 running, ?73 sleeping, ? 0 stopped, ? 0 zombie
>> Cpu(s): 32.9%us, ?1.3%sy, ?0.0%ni, 65.8%id, ?0.0%wa, ?0.0%hi, ?0.0%si, ?0.0%st
>> Mem: ? ?940232k total, ? 118520k used, ? 821712k free, ? ? 8080k buffers
>> Swap: ? 524240k total, ? ? ? ?0k used, ? 524240k free, ? ?79432k cached
>>
>> ? PID USER ? ? ?PR ?NI ?VIRT ?RES ?SHR S %CPU %MEM ? ?TIME+ ?COMMAND
>> ?3868 eranian ? 20 ? 0 ? 644 ?160 ?128 R ? 99 ?0.0 ? 0:53.34 noploop
>> ?3870 eranian ? 20 ? 0 ?2284 1060 ?804 R ? ?3 ?0.1 ? 0:00.63 top
>> ? ? 1 root ? ? ?20 ? 0 ?2564 1532 ?952 S ? ?0 ?0.2 ? 0:01.26 init
>>
>> I am connecting to the board via ssh.
>> But the results don't look correct to me.
>
> thanks,
> --
> Ming Lei

Re: oprofile and ARM A9 hardware counter

[Måns Rullgård]

stephane eranian <eranian@googlemail.com> writes:

> Same result for me on CPU1:
>
> top - 16:20:24 up  1:45,  1 user,  load average: 0.29, 0.08, 0.07
> Tasks:  70 total,   2 running,  68 sleeping,   0 stopped,   0 zombie
> Cpu(s): 30.7%us,  2.7%sy,  0.0%ni, 66.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
> Mem:    940232k total,   228984k used,   711248k free,    82244k buffers
> Swap:   524240k total,        0k used,   524240k free,    91400k cached
>
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  P COMMAND
>  3968 eranian   20   0   644  160  128 R  100  0.0   0:21.98 1 noploop
>  3969 eranian   20   0  2184 1056  804 R    3  0.1   0:00.53 0 top
>    82 root      20   0     0    0    0 S    1  0.0   0:01.35 0
> kworker/0:1
>
> With 3.3.0-rc1, if I revert the clockdomain patch, I get the same result.
> So it must be coming from somewhere else, as you suggested.
>
> If the processor was spending time processing interrupts, then this would be
> accounted for in as sys time. But that's not what I observe here. It's either
> idle or user. That line, leads me to believe that the processor can only run
> my program for 30% of the time. The rest is spent idling even though my
> program is non-blocking. How could that be possible? Power-saving?

In top, press 1 to see the statistics for the CPUs separately.

-- 
Måns Rullgård
mans@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

oprofile and ARM A9 hardware counter

[Måns Rullgård]

stephane eranian <eranian@googlemail.com> writes:

> Same result for me on CPU1:
>
> top - 16:20:24 up  1:45,  1 user,  load average: 0.29, 0.08, 0.07
> Tasks:  70 total,   2 running,  68 sleeping,   0 stopped,   0 zombie
> Cpu(s): 30.7%us,  2.7%sy,  0.0%ni, 66.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
> Mem:    940232k total,   228984k used,   711248k free,    82244k buffers
> Swap:   524240k total,        0k used,   524240k free,    91400k cached
>
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  P COMMAND
>  3968 eranian   20   0   644  160  128 R  100  0.0   0:21.98 1 noploop
>  3969 eranian   20   0  2184 1056  804 R    3  0.1   0:00.53 0 top
>    82 root      20   0     0    0    0 S    1  0.0   0:01.35 0
> kworker/0:1
>
> With 3.3.0-rc1, if I revert the clockdomain patch, I get the same result.
> So it must be coming from somewhere else, as you suggested.
>
> If the processor was spending time processing interrupts, then this would be
> accounted for in as sys time. But that's not what I observe here. It's either
> idle or user. That line, leads me to believe that the processor can only run
> my program for 30% of the time. The rest is spent idling even though my
> program is non-blocking. How could that be possible? Power-saving?

In top, press 1 to see the statistics for the CPUs separately.

-- 
M?ns Rullg?rd
mans at mansr.com

Re: oprofile and ARM A9 hardware counter

[stephane eranian]

On Mon, Jan 30, 2012 at 5:08 PM, Måns Rullgård <mans@mansr.com> wrote:
> stephane eranian <eranian@googlemail.com> writes:
>
>> Same result for me on CPU1:
>>
>> top - 16:20:24 up  1:45,  1 user,  load average: 0.29, 0.08, 0.07
>> Tasks:  70 total,   2 running,  68 sleeping,   0 stopped,   0 zombie
>> Cpu(s): 30.7%us,  2.7%sy,  0.0%ni, 66.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
>> Mem:    940232k total,   228984k used,   711248k free,    82244k buffers
>> Swap:   524240k total,        0k used,   524240k free,    91400k cached
>>
>>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  P COMMAND
>>  3968 eranian   20   0   644  160  128 R  100  0.0   0:21.98 1 noploop
>>  3969 eranian   20   0  2184 1056  804 R    3  0.1   0:00.53 0 top
>>    82 root      20   0     0    0    0 S    1  0.0   0:01.35 0
>> kworker/0:1
>>
>> With 3.3.0-rc1, if I revert the clockdomain patch, I get the same result.
>> So it must be coming from somewhere else, as you suggested.
>>
>> If the processor was spending time processing interrupts, then this would be
>> accounted for in as sys time. But that's not what I observe here. It's either
>> idle or user. That line, leads me to believe that the processor can only run
>> my program for 30% of the time. The rest is spent idling even though my
>> program is non-blocking. How could that be possible? Power-saving?
>
> In top, press 1 to see the statistics for the CPUs separately.
>
Ok, when I pin my program to CPU1, and press 1 in top I get:
asks:  69 total,   2 running,  67 sleeping,   0 stopped,   0 zombie
Cpu0  :  0.9%us,  3.8%sy,  0.0%ni, 94.3%id,  0.0%wa,  0.0%hi,  0.9%si,  0.0%st
Cpu1  :100.0%us,  0.0%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:    940232k total,    75480k used,   864752k free,     8148k buffers
Swap:   524240k total,        0k used,   524240k free,    37568k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 3788 eranian   20   0   644  160  128 R  100  0.0   0:47.93 noploop
 3758 eranian   20   0  9900 1512  712 S    2  0.2   0:01.17 sshd
 3789 eranian   20   0  2184 1056  804 R    2  0.1   0:01.22 top

Which gives me the right answer. But in 'collapsed mode', press 1 again,
the aggregate value is bogus. Could be wrong math in top. Ok, that was
a false alarm then. Thanks for the help.

Still need to investigate why the frequency mode does
not yield the correct number of samples even with low frequency.


$ taskset -c 1 perf record -e cycles -F 100 noploop 10
$ perf report -D | tail -20
Aggregated stats:
           TOTAL events:        475
            MMAP events:         11
            COMM events:          2
            EXIT events:          2
          SAMPLE events:        460
cycles stats:
           TOTAL events:        475
            MMAP events:         11
            COMM events:          2
            EXIT events:          2
          SAMPLE events:        460

460 samples is way too low. Should be 100x10 = 1000 samples or close to it.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

oprofile and ARM A9 hardware counter

[stephane eranian]

On Mon, Jan 30, 2012 at 5:08 PM, M?ns Rullg?rd <mans@mansr.com> wrote:
> stephane eranian <eranian@googlemail.com> writes:
>
>> Same result for me on CPU1:
>>
>> top - 16:20:24 up ?1:45, ?1 user, ?load average: 0.29, 0.08, 0.07
>> Tasks: ?70 total, ? 2 running, ?68 sleeping, ? 0 stopped, ? 0 zombie
>> Cpu(s): 30.7%us, ?2.7%sy, ?0.0%ni, 66.7%id, ?0.0%wa, ?0.0%hi, ?0.0%si, ?0.0%st
>> Mem: ? ?940232k total, ? 228984k used, ? 711248k free, ? ?82244k buffers
>> Swap: ? 524240k total, ? ? ? ?0k used, ? 524240k free, ? ?91400k cached
>>
>> ? PID USER ? ? ?PR ?NI ?VIRT ?RES ?SHR S %CPU %MEM ? ?TIME+ ?P COMMAND
>> ?3968 eranian ? 20 ? 0 ? 644 ?160 ?128 R ?100 ?0.0 ? 0:21.98 1 noploop
>> ?3969 eranian ? 20 ? 0 ?2184 1056 ?804 R ? ?3 ?0.1 ? 0:00.53 0 top
>> ? ?82 root ? ? ?20 ? 0 ? ? 0 ? ?0 ? ?0 S ? ?1 ?0.0 ? 0:01.35 0
>> kworker/0:1
>>
>> With 3.3.0-rc1, if I revert the clockdomain patch, I get the same result.
>> So it must be coming from somewhere else, as you suggested.
>>
>> If the processor was spending time processing interrupts, then this would be
>> accounted for in as sys time. But that's not what I observe here. It's either
>> idle or user. That line, leads me to believe that the processor can only run
>> my program for 30% of the time. The rest is spent idling even though my
>> program is non-blocking. How could that be possible? Power-saving?
>
> In top, press 1 to see the statistics for the CPUs separately.
>
Ok, when I pin my program to CPU1, and press 1 in top I get:
asks:  69 total,   2 running,  67 sleeping,   0 stopped,   0 zombie
Cpu0  :  0.9%us,  3.8%sy,  0.0%ni, 94.3%id,  0.0%wa,  0.0%hi,  0.9%si,  0.0%st
Cpu1  :100.0%us,  0.0%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:    940232k total,    75480k used,   864752k free,     8148k buffers
Swap:   524240k total,        0k used,   524240k free,    37568k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 3788 eranian   20   0   644  160  128 R  100  0.0   0:47.93 noploop
 3758 eranian   20   0  9900 1512  712 S    2  0.2   0:01.17 sshd
 3789 eranian   20   0  2184 1056  804 R    2  0.1   0:01.22 top

Which gives me the right answer. But in 'collapsed mode', press 1 again,
the aggregate value is bogus. Could be wrong math in top. Ok, that was
a false alarm then. Thanks for the help.

Still need to investigate why the frequency mode does
not yield the correct number of samples even with low frequency.


$ taskset -c 1 perf record -e cycles -F 100 noploop 10
$ perf report -D | tail -20
Aggregated stats:
           TOTAL events:        475
            MMAP events:         11
            COMM events:          2
            EXIT events:          2
          SAMPLE events:        460
cycles stats:
           TOTAL events:        475
            MMAP events:         11
            COMM events:          2
            EXIT events:          2
          SAMPLE events:        460

460 samples is way too low. Should be 100x10 = 1000 samples or close to it.

Re: oprofile and ARM A9 hardware counter

[Will Deacon]

On Mon, Jan 30, 2012 at 05:15:53PM +0000, stephane eranian wrote:
> Still need to investigate why the frequency mode does
> not yield the correct number of samples even with low frequency.
> 
> 
> $ taskset -c 1 perf record -e cycles -F 100 noploop 10
> $ perf report -D | tail -20
> Aggregated stats:
>            TOTAL events:        475
>             MMAP events:         11
>             COMM events:          2
>             EXIT events:          2
>           SAMPLE events:        460
> cycles stats:
>            TOTAL events:        475
>             MMAP events:         11
>             COMM events:          2
>             EXIT events:          2
>           SAMPLE events:        460
> 
> 460 samples is way too low. Should be 100x10 = 1000 samples or close to it.

Can you stick noploop.c somewhere (I'm lazy :) and I'll try it on one of my
A9 boards?

Thanks,

Will

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2

oprofile and ARM A9 hardware counter

[Will Deacon]

On Mon, Jan 30, 2012 at 05:15:53PM +0000, stephane eranian wrote:
> Still need to investigate why the frequency mode does
> not yield the correct number of samples even with low frequency.
> 
> 
> $ taskset -c 1 perf record -e cycles -F 100 noploop 10
> $ perf report -D | tail -20
> Aggregated stats:
>            TOTAL events:        475
>             MMAP events:         11
>             COMM events:          2
>             EXIT events:          2
>           SAMPLE events:        460
> cycles stats:
>            TOTAL events:        475
>             MMAP events:         11
>             COMM events:          2
>             EXIT events:          2
>           SAMPLE events:        460
> 
> 460 samples is way too low. Should be 100x10 = 1000 samples or close to it.

Can you stick noploop.c somewhere (I'm lazy :) and I'll try it on one of my
A9 boards?

Thanks,

Will

Re: oprofile and ARM A9 hardware counter

[stephane eranian]

Will,

There you go, no attachment, not sure the omap list
supports this.

There is something quite interesting to observe.

While I run perf record -e cycles -F 100 noploop 10, I watch
/proc/interrupts. The number of interrupts is way lower than
expected. Therefore the number of samples is way too low:

$ perf record -e cycles -F 100 noploop 10
$ perf report -D | tail -20
cycles stats:
           TOTAL events:        535
            MMAP events:         11
            COMM events:          2
            EXIT events:          2
          SAMPLE events:        520

The delta in /proc/interrupts on CPU1 is 520 interrupts.

So looks like the frequency adjustment which is hooked off of the
timer tick is either not called at each timer tick, the timer ticks are
not at regular interval, or the math is wrong.

If I go with the fixed period mode:
$ perf stat -e cycles noploop 10
noploop for 10 seconds
 Performance counter stats for 'noploop 10':
       10079156960 cycles                    #    0.000 GHz
      10.004547117 seconds time elapsed

That means, if I want 100 samples/sec: = 10079156960/(10*100)=10079157
$ perf record -e cycles -c 10079157 noploop 10
$ perf report -D | tail -20
cycles stats:
           TOTAL events:       1003
            MMAP events:         11
            COMM events:          2
            EXIT events:          2
        THROTTLE events:          1
      UNTHROTTLE events:          1
          SAMPLE events:        986

Now, we're getting the right answer!

So with the right sampling period, everything works fine.
We need to elucidate what's going on in perf_event_task_tick().
I have tried with my throttling fix and it did not help. We are
not subject to throttling with such a low rate.

noploop.c:

#include <sys/types.h>
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <inttypes.h>
#include <unistd.h>

void handler(int sig)
{
	exit(0);
}

void
noploop(void)
{
	for(;;);
}

int
main(int argc, char **argv)
{
	unsigned int delay;
	delay = argc > 1 ? atoi(argv[1]) : 1;
	signal(SIGALRM, handler);
	printf("noploop for %d seconds\n", delay);
	alarm(delay);
	noploop();
	return 0;
}

On Mon, Jan 30, 2012 at 6:24 PM, Will Deacon <will.deacon@arm.com> wrote:
> On Mon, Jan 30, 2012 at 05:15:53PM +0000, stephane eranian wrote:
>> Still need to investigate why the frequency mode does
>> not yield the correct number of samples even with low frequency.
>>
>>
>> $ taskset -c 1 perf record -e cycles -F 100 noploop 10
>> $ perf report -D | tail -20
>> Aggregated stats:
>>            TOTAL events:        475
>>             MMAP events:         11
>>             COMM events:          2
>>             EXIT events:          2
>>           SAMPLE events:        460
>> cycles stats:
>>            TOTAL events:        475
>>             MMAP events:         11
>>             COMM events:          2
>>             EXIT events:          2
>>           SAMPLE events:        460
>>
>> 460 samples is way too low. Should be 100x10 = 1000 samples or close to it.
>
> Can you stick noploop.c somewhere (I'm lazy :) and I'll try it on one of my
> A9 boards?
>
> Thanks,
>
> Will
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

oprofile and ARM A9 hardware counter

[stephane eranian]

Will,

There you go, no attachment, not sure the omap list
supports this.

There is something quite interesting to observe.

While I run perf record -e cycles -F 100 noploop 10, I watch
/proc/interrupts. The number of interrupts is way lower than
expected. Therefore the number of samples is way too low:

$ perf record -e cycles -F 100 noploop 10
$ perf report -D | tail -20
cycles stats:
           TOTAL events:        535
            MMAP events:         11
            COMM events:          2
            EXIT events:          2
          SAMPLE events:        520

The delta in /proc/interrupts on CPU1 is 520 interrupts.

So looks like the frequency adjustment which is hooked off of the
timer tick is either not called at each timer tick, the timer ticks are
not at regular interval, or the math is wrong.

If I go with the fixed period mode:
$ perf stat -e cycles noploop 10
noploop for 10 seconds
 Performance counter stats for 'noploop 10':
       10079156960 cycles                    #    0.000 GHz
      10.004547117 seconds time elapsed

That means, if I want 100 samples/sec: = 10079156960/(10*100)=10079157
$ perf record -e cycles -c 10079157 noploop 10
$ perf report -D | tail -20
cycles stats:
           TOTAL events:       1003
            MMAP events:         11
            COMM events:          2
            EXIT events:          2
        THROTTLE events:          1
      UNTHROTTLE events:          1
          SAMPLE events:        986

Now, we're getting the right answer!

So with the right sampling period, everything works fine.
We need to elucidate what's going on in perf_event_task_tick().
I have tried with my throttling fix and it did not help. We are
not subject to throttling with such a low rate.

noploop.c:

#include <sys/types.h>
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <inttypes.h>
#include <unistd.h>

void handler(int sig)
{
	exit(0);
}

void
noploop(void)
{
	for(;;);
}

int
main(int argc, char **argv)
{
	unsigned int delay;
	delay = argc > 1 ? atoi(argv[1]) : 1;
	signal(SIGALRM, handler);
	printf("noploop for %d seconds\n", delay);
	alarm(delay);
	noploop();
	return 0;
}

On Mon, Jan 30, 2012 at 6:24 PM, Will Deacon <will.deacon@arm.com> wrote:
> On Mon, Jan 30, 2012 at 05:15:53PM +0000, stephane eranian wrote:
>> Still need to investigate why the frequency mode does
>> not yield the correct number of samples even with low frequency.
>>
>>
>> $ taskset -c 1 perf record -e cycles -F 100 noploop 10
>> $ perf report -D | tail -20
>> Aggregated stats:
>> ? ? ? ? ? ?TOTAL events: ? ? ? ?475
>> ? ? ? ? ? ? MMAP events: ? ? ? ? 11
>> ? ? ? ? ? ? COMM events: ? ? ? ? ?2
>> ? ? ? ? ? ? EXIT events: ? ? ? ? ?2
>> ? ? ? ? ? SAMPLE events: ? ? ? ?460
>> cycles stats:
>> ? ? ? ? ? ?TOTAL events: ? ? ? ?475
>> ? ? ? ? ? ? MMAP events: ? ? ? ? 11
>> ? ? ? ? ? ? COMM events: ? ? ? ? ?2
>> ? ? ? ? ? ? EXIT events: ? ? ? ? ?2
>> ? ? ? ? ? SAMPLE events: ? ? ? ?460
>>
>> 460 samples is way too low. Should be 100x10 = 1000 samples or close to it.
>
> Can you stick noploop.c somewhere (I'm lazy :) and I'll try it on one of my
> A9 boards?
>
> Thanks,
>
> Will

Re: oprofile and ARM A9 hardware counter

[Will Deacon]

On Mon, Jan 30, 2012 at 05:45:19PM +0000, stephane eranian wrote:
> There you go, no attachment, not sure the omap list
> supports this.

Cheers Stephane.

> There is something quite interesting to observe.
> 
> While I run perf record -e cycles -F 100 noploop 10, I watch
> /proc/interrupts. The number of interrupts is way lower than
> expected. Therefore the number of samples is way too low:
> 
> $ perf record -e cycles -F 100 noploop 10
> $ perf report -D | tail -20
> cycles stats:
>            TOTAL events:        535
>             MMAP events:         11
>             COMM events:          2
>             EXIT events:          2
>           SAMPLE events:        520
>
> The delta in /proc/interrupts on CPU1 is 520 interrupts.

Yes, that is about half of what you'd expect. Running on my A9 platform
(vexpress) I get:

$ perf record -e cycles -F 100 noploop 10
$ perf report -D | tail -20
cycles stats:
           TOTAL events:       1007
            MMAP events:         18
            COMM events:          2
            EXIT events:          2
          SAMPLE events:        985

> So looks like the frequency adjustment which is hooked off of the
> timer tick is either not called at each timer tick, the timer ticks are
> not at regular interval, or the math is wrong.

My hunch is that that the interval is probably varying, but I don't know much
about OMAP4 and its clocks.

> If I go with the fixed period mode:
> $ perf stat -e cycles noploop 10
> noploop for 10 seconds
>  Performance counter stats for 'noploop 10':
>        10079156960 cycles                    #    0.000 GHz
>       10.004547117 seconds time elapsed
> 
> That means, if I want 100 samples/sec: = 10079156960/(10*100)=10079157
> $ perf record -e cycles -c 10079157 noploop 10
> $ perf report -D | tail -20
> cycles stats:
>            TOTAL events:       1003
>             MMAP events:         11
>             COMM events:          2
>             EXIT events:          2
>         THROTTLE events:          1
>       UNTHROTTLE events:          1
>           SAMPLE events:        986
> 
> Now, we're getting the right answer!

Just to confirm, for me:

$ perf stat -e cycles ./noploop 10
noploop for 10 seconds

 Performance counter stats for './noploop 10':

        4001163930 cycles                    #    0.000 GHz

      10.006534024 seconds time elapsed

$ perf record -e cycles -c 4001163 ./noploop 10
$ perf report -D | tail -20
  Aggregated stats:
           TOTAL events:       1020
            MMAP events:         18
            COMM events:          2
            EXIT events:          2
          SAMPLE events:        998
cycles stats:
           TOTAL events:       1020
            MMAP events:         18
            COMM events:          2
            EXIT events:          2
          SAMPLE events:        998

which is close enough :)

> We need to elucidate what's going on in perf_event_task_tick().
> I have tried with my throttling fix and it did not help. We are
> not subject to throttling with such a low rate.

Ok. I would start by looking at the clock ticks if I were you, since this
seems to be alright on my board.

Will

oprofile and ARM A9 hardware counter

[Will Deacon]

On Mon, Jan 30, 2012 at 05:45:19PM +0000, stephane eranian wrote:
> There you go, no attachment, not sure the omap list
> supports this.

Cheers Stephane.

> There is something quite interesting to observe.
> 
> While I run perf record -e cycles -F 100 noploop 10, I watch
> /proc/interrupts. The number of interrupts is way lower than
> expected. Therefore the number of samples is way too low:
> 
> $ perf record -e cycles -F 100 noploop 10
> $ perf report -D | tail -20
> cycles stats:
>            TOTAL events:        535
>             MMAP events:         11
>             COMM events:          2
>             EXIT events:          2
>           SAMPLE events:        520
>
> The delta in /proc/interrupts on CPU1 is 520 interrupts.

Yes, that is about half of what you'd expect. Running on my A9 platform
(vexpress) I get:

$ perf record -e cycles -F 100 noploop 10
$ perf report -D | tail -20
cycles stats:
           TOTAL events:       1007
            MMAP events:         18
            COMM events:          2
            EXIT events:          2
          SAMPLE events:        985

> So looks like the frequency adjustment which is hooked off of the
> timer tick is either not called at each timer tick, the timer ticks are
> not at regular interval, or the math is wrong.

My hunch is that that the interval is probably varying, but I don't know much
about OMAP4 and its clocks.

> If I go with the fixed period mode:
> $ perf stat -e cycles noploop 10
> noploop for 10 seconds
>  Performance counter stats for 'noploop 10':
>        10079156960 cycles                    #    0.000 GHz
>       10.004547117 seconds time elapsed
> 
> That means, if I want 100 samples/sec: = 10079156960/(10*100)=10079157
> $ perf record -e cycles -c 10079157 noploop 10
> $ perf report -D | tail -20
> cycles stats:
>            TOTAL events:       1003
>             MMAP events:         11
>             COMM events:          2
>             EXIT events:          2
>         THROTTLE events:          1
>       UNTHROTTLE events:          1
>           SAMPLE events:        986
> 
> Now, we're getting the right answer!

Just to confirm, for me:

$ perf stat -e cycles ./noploop 10
noploop for 10 seconds

 Performance counter stats for './noploop 10':

        4001163930 cycles                    #    0.000 GHz

      10.006534024 seconds time elapsed

$ perf record -e cycles -c 4001163 ./noploop 10
$ perf report -D | tail -20
  Aggregated stats:
           TOTAL events:       1020
            MMAP events:         18
            COMM events:          2
            EXIT events:          2
          SAMPLE events:        998
cycles stats:
           TOTAL events:       1020
            MMAP events:         18
            COMM events:          2
            EXIT events:          2
          SAMPLE events:        998

which is close enough :)

> We need to elucidate what's going on in perf_event_task_tick().
> I have tried with my throttling fix and it did not help. We are
> not subject to throttling with such a low rate.

Ok. I would start by looking at the clock ticks if I were you, since this
seems to be alright on my board.

Will

Re: oprofile and ARM A9 hardware counter

[stephane eranian]

On Mon, Jan 30, 2012 at 8:14 PM, Will Deacon <will.deacon@arm.com> wrote:
> On Mon, Jan 30, 2012 at 05:45:19PM +0000, stephane eranian wrote:
>> There you go, no attachment, not sure the omap list
>> supports this.
>
> Cheers Stephane.
>
>> There is something quite interesting to observe.
>>
>> While I run perf record -e cycles -F 100 noploop 10, I watch
>> /proc/interrupts. The number of interrupts is way lower than
>> expected. Therefore the number of samples is way too low:
>>
>> $ perf record -e cycles -F 100 noploop 10
>> $ perf report -D | tail -20
>> cycles stats:
>>            TOTAL events:        535
>>             MMAP events:         11
>>             COMM events:          2
>>             EXIT events:          2
>>           SAMPLE events:        520
>>
>> The delta in /proc/interrupts on CPU1 is 520 interrupts.
>
> Yes, that is about half of what you'd expect. Running on my A9 platform
> (vexpress) I get:
>
> $ perf record -e cycles -F 100 noploop 10
> $ perf report -D | tail -20
> cycles stats:
>           TOTAL events:       1007
>            MMAP events:         18
>            COMM events:          2
>            EXIT events:          2
>          SAMPLE events:        985
>
>> So looks like the frequency adjustment which is hooked off of the
>> timer tick is either not called at each timer tick, the timer ticks are
>> not at regular interval, or the math is wrong.
>
> My hunch is that that the interval is probably varying, but I don't know much
> about OMAP4 and its clocks.
>
Glad you tested this. At least, it seems the generic perf_event code
is allright.
I agree with you, something is fishy with the clocks. Just out of
curiosity, what is
the HZ value for your board? On my Panda it's 128Hz.

>> If I go with the fixed period mode:
>> $ perf stat -e cycles noploop 10
>> noploop for 10 seconds
>>  Performance counter stats for 'noploop 10':
>>        10079156960 cycles                    #    0.000 GHz
>>       10.004547117 seconds time elapsed
>>
>> That means, if I want 100 samples/sec: = 10079156960/(10*100)=10079157
>> $ perf record -e cycles -c 10079157 noploop 10
>> $ perf report -D | tail -20
>> cycles stats:
>>            TOTAL events:       1003
>>             MMAP events:         11
>>             COMM events:          2
>>             EXIT events:          2
>>         THROTTLE events:          1
>>       UNTHROTTLE events:          1
>>           SAMPLE events:        986
>>
>> Now, we're getting the right answer!
>
> Just to confirm, for me:
>
> $ perf stat -e cycles ./noploop 10
> noploop for 10 seconds
>
>  Performance counter stats for './noploop 10':
>
>        4001163930 cycles                    #    0.000 GHz
>
>      10.006534024 seconds time elapsed
>
> $ perf record -e cycles -c 4001163 ./noploop 10
> $ perf report -D | tail -20
>  Aggregated stats:
>           TOTAL events:       1020
>            MMAP events:         18
>            COMM events:          2
>            EXIT events:          2
>          SAMPLE events:        998
> cycles stats:
>           TOTAL events:       1020
>            MMAP events:         18
>            COMM events:          2
>            EXIT events:          2
>          SAMPLE events:        998
>
> which is close enough :)
>
>> We need to elucidate what's going on in perf_event_task_tick().
>> I have tried with my throttling fix and it did not help. We are
>> not subject to throttling with such a low rate.
>
> Ok. I would start by looking at the clock ticks if I were you, since this
> seems to be alright on my board.
>
> Will
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

oprofile and ARM A9 hardware counter

[stephane eranian]

On Mon, Jan 30, 2012 at 8:14 PM, Will Deacon <will.deacon@arm.com> wrote:
> On Mon, Jan 30, 2012 at 05:45:19PM +0000, stephane eranian wrote:
>> There you go, no attachment, not sure the omap list
>> supports this.
>
> Cheers Stephane.
>
>> There is something quite interesting to observe.
>>
>> While I run perf record -e cycles -F 100 noploop 10, I watch
>> /proc/interrupts. The number of interrupts is way lower than
>> expected. Therefore the number of samples is way too low:
>>
>> $ perf record -e cycles -F 100 noploop 10
>> $ perf report -D | tail -20
>> cycles stats:
>> ? ? ? ? ? ?TOTAL events: ? ? ? ?535
>> ? ? ? ? ? ? MMAP events: ? ? ? ? 11
>> ? ? ? ? ? ? COMM events: ? ? ? ? ?2
>> ? ? ? ? ? ? EXIT events: ? ? ? ? ?2
>> ? ? ? ? ? SAMPLE events: ? ? ? ?520
>>
>> The delta in /proc/interrupts on CPU1 is 520 interrupts.
>
> Yes, that is about half of what you'd expect. Running on my A9 platform
> (vexpress) I get:
>
> $ perf record -e cycles -F 100 noploop 10
> $ perf report -D | tail -20
> cycles stats:
> ? ? ? ? ? TOTAL events: ? ? ? 1007
> ? ? ? ? ? ?MMAP events: ? ? ? ? 18
> ? ? ? ? ? ?COMM events: ? ? ? ? ?2
> ? ? ? ? ? ?EXIT events: ? ? ? ? ?2
> ? ? ? ? ?SAMPLE events: ? ? ? ?985
>
>> So looks like the frequency adjustment which is hooked off of the
>> timer tick is either not called at each timer tick, the timer ticks are
>> not at regular interval, or the math is wrong.
>
> My hunch is that that the interval is probably varying, but I don't know much
> about OMAP4 and its clocks.
>
Glad you tested this. At least, it seems the generic perf_event code
is allright.
I agree with you, something is fishy with the clocks. Just out of
curiosity, what is
the HZ value for your board? On my Panda it's 128Hz.

>> If I go with the fixed period mode:
>> $ perf stat -e cycles noploop 10
>> noploop for 10 seconds
>> ?Performance counter stats for 'noploop 10':
>> ? ? ? ?10079156960 cycles ? ? ? ? ? ? ? ? ? ?# ? ?0.000 GHz
>> ? ? ? 10.004547117 seconds time elapsed
>>
>> That means, if I want 100 samples/sec: = 10079156960/(10*100)=10079157
>> $ perf record -e cycles -c 10079157 noploop 10
>> $ perf report -D | tail -20
>> cycles stats:
>> ? ? ? ? ? ?TOTAL events: ? ? ? 1003
>> ? ? ? ? ? ? MMAP events: ? ? ? ? 11
>> ? ? ? ? ? ? COMM events: ? ? ? ? ?2
>> ? ? ? ? ? ? EXIT events: ? ? ? ? ?2
>> ? ? ? ? THROTTLE events: ? ? ? ? ?1
>> ? ? ? UNTHROTTLE events: ? ? ? ? ?1
>> ? ? ? ? ? SAMPLE events: ? ? ? ?986
>>
>> Now, we're getting the right answer!
>
> Just to confirm, for me:
>
> $ perf stat -e cycles ./noploop 10
> noploop for 10 seconds
>
> ?Performance counter stats for './noploop 10':
>
> ? ? ? ?4001163930 cycles ? ? ? ? ? ? ? ? ? ?# ? ?0.000 GHz
>
> ? ? ?10.006534024 seconds time elapsed
>
> $ perf record -e cycles -c 4001163 ./noploop 10
> $ perf report -D | tail -20
> ?Aggregated stats:
> ? ? ? ? ? TOTAL events: ? ? ? 1020
> ? ? ? ? ? ?MMAP events: ? ? ? ? 18
> ? ? ? ? ? ?COMM events: ? ? ? ? ?2
> ? ? ? ? ? ?EXIT events: ? ? ? ? ?2
> ? ? ? ? ?SAMPLE events: ? ? ? ?998
> cycles stats:
> ? ? ? ? ? TOTAL events: ? ? ? 1020
> ? ? ? ? ? ?MMAP events: ? ? ? ? 18
> ? ? ? ? ? ?COMM events: ? ? ? ? ?2
> ? ? ? ? ? ?EXIT events: ? ? ? ? ?2
> ? ? ? ? ?SAMPLE events: ? ? ? ?998
>
> which is close enough :)
>
>> We need to elucidate what's going on in perf_event_task_tick().
>> I have tried with my throttling fix and it did not help. We are
>> not subject to throttling with such a low rate.
>
> Ok. I would start by looking at the clock ticks if I were you, since this
> seems to be alright on my board.
>
> Will

Re: oprofile and ARM A9 hardware counter

[Ming Lei]

Hi Will,

On Fri, Jan 27, 2012 at 11:54 PM, Will Deacon <will.deacon@arm.com> wrote:
> Ok. Note that on ARM the PMU generates a standard IRQ (i.e. not an NMI) so
> you may miss samples if they occur during critical kernel sections (and if
> you look at a profile, spin_unlock_irqrestore will be quite high).

Also looks no any irq handler functions can be observed at a profile even
though they may be run at a very high frequency.

So could we configure ARM PMU interrupt as FIQ to address the above issues?

thanks
--
Ming Lei

oprofile and ARM A9 hardware counter

[Ming Lei]

Hi Will,

On Fri, Jan 27, 2012 at 11:54 PM, Will Deacon <will.deacon@arm.com> wrote:
> Ok. Note that on ARM the PMU generates a standard IRQ (i.e. not an NMI) so
> you may miss samples if they occur during critical kernel sections (and if
> you look at a profile, spin_unlock_irqrestore will be quite high).

Also looks no any irq handler functions can be observed at a profile even
though they may be run at a very high frequency.

So could we configure ARM PMU interrupt as FIQ to address the above issues?

thanks
--
Ming Lei

Re: oprofile and ARM A9 hardware counter

[Will Deacon]

On Wed, Mar 07, 2012 at 02:49:46AM +0000, Ming Lei wrote:
> Hi Will,

Hello,

> On Fri, Jan 27, 2012 at 11:54 PM, Will Deacon <will.deacon@arm.com> wrote:
> > Ok. Note that on ARM the PMU generates a standard IRQ (i.e. not an NMI) so
> > you may miss samples if they occur during critical kernel sections (and if
> > you look at a profile, spin_unlock_irqrestore will be quite high).
> 
> Also looks no any irq handler functions can be observed at a profile even
> though they may be run at a very high frequency.
> 
> So could we configure ARM PMU interrupt as FIQ to address the above issues?

I thought about that in the past but the problem is finding hardware which
allows this. It probably means that you need a second GIC which can route
interrupts onto the FIQ line into the CPU. Given that FIQ is usually claimed
for secure interrupts, there could also still be latency issues here.

A better (read: highly invasive) way to fix this is using interrupt
priorities at the distributor. You then have to hack the interrupt disabling
code so that it disables interrupts below a certain priority if they occur
during an IRQ-off section. The re-enabling code would then have to undo
those decisions and allow the interrupts to be serviced. Pretty nasty stuff.

Will

oprofile and ARM A9 hardware counter

[Will Deacon]

On Wed, Mar 07, 2012 at 02:49:46AM +0000, Ming Lei wrote:
> Hi Will,

Hello,

> On Fri, Jan 27, 2012 at 11:54 PM, Will Deacon <will.deacon@arm.com> wrote:
> > Ok. Note that on ARM the PMU generates a standard IRQ (i.e. not an NMI) so
> > you may miss samples if they occur during critical kernel sections (and if
> > you look at a profile, spin_unlock_irqrestore will be quite high).
> 
> Also looks no any irq handler functions can be observed at a profile even
> though they may be run at a very high frequency.
> 
> So could we configure ARM PMU interrupt as FIQ to address the above issues?

I thought about that in the past but the problem is finding hardware which
allows this. It probably means that you need a second GIC which can route
interrupts onto the FIQ line into the CPU. Given that FIQ is usually claimed
for secure interrupts, there could also still be latency issues here.

A better (read: highly invasive) way to fix this is using interrupt
priorities at the distributor. You then have to hack the interrupt disabling
code so that it disables interrupts below a certain priority if they occur
during an IRQ-off section. The re-enabling code would then have to undo
those decisions and allow the interrupts to be serviced. Pretty nasty stuff.

Will

Re: oprofile and ARM A9 hardware counter

[Ming Lei]

Hi,

On Fri, Jan 27, 2012 at 8:13 PM, Will Deacon <will.deacon@arm.com> wrote:
>> >> There must be something I am missing here.
>
> Did this lead anywhere in the end? It seems as though Ming Lei has a working
> setup but Stephane is unable to replicate it, despite applying the necessary
> patches and trying an updated bootloader.

In fact, I don't think stephane has tried the patch in the link[1] and
reported the
test result, even though I have asked him to do it for several times.

> Drastic suggestion: Stephane, could you try a kernel *binary* from Ming Lei?
> If that works then you're probably just missing a patch. If it doesn't, then
> there must be something different between your boards.

[1], http://marc.info/?l=linux-arm-kernel&m=132697975416659&w=2

thanks,
--
Ming Lei

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2

oprofile and ARM A9 hardware counter

[Ming Lei]

Hi,

On Fri, Jan 27, 2012 at 8:13 PM, Will Deacon <will.deacon@arm.com> wrote:
>> >> There must be something I am missing here.
>
> Did this lead anywhere in the end? It seems as though Ming Lei has a working
> setup but Stephane is unable to replicate it, despite applying the necessary
> patches and trying an updated bootloader.

In fact, I don't think stephane has tried the patch in the link[1] and
reported the
test result, even though I have asked him to do it for several times.

> Drastic suggestion: Stephane, could you try a kernel *binary* from Ming Lei?
> If that works then you're probably just missing a patch. If it doesn't, then
> there must be something different between your boards.

[1], http://marc.info/?l=linux-arm-kernel&m=132697975416659&w=2

thanks,
--
Ming Lei

Re: oprofile and ARM A9 hardware counter

[Russell King - ARM Linux]

On Wed, Jan 18, 2012 at 10:54:46AM +0100, stephane eranian wrote:
> Should I use Will's -next tree as the base instead of Linus'?
> Given that MARC is shutdown today, would you mind packing those patches
> into a tarball and sending them to me directly?

Other archive sites are available.

There's my lurker-based archive on the old list server, and there's
pipermail on the current list server to name two.

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d

oprofile and ARM A9 hardware counter

[Russell King - ARM Linux]

On Wed, Jan 18, 2012 at 10:54:46AM +0100, stephane eranian wrote:
> Should I use Will's -next tree as the base instead of Linus'?
> Given that MARC is shutdown today, would you mind packing those patches
> into a tarball and sending them to me directly?

Other archive sites are available.

There's my lurker-based archive on the old list server, and there's
pipermail on the current list server to name two.

oprofile and ARM A9 hardware counter

[Shilimkar, Santosh]

( Removing dead "linux-arm-kernel at lists.arm.linux.org.uk" and adding
correct list

On Tue, Feb 7, 2012 at 4:07 PM, stephane eranian <eranian@googlemail.com> wrote:
> Hi,
>
> Ok, with Santosh's patch this is much better almost as expected, still
> 10-15% off.
>
> With Santosh's:
> $ perf record noploop 10
> $ perf report -D | fgrep SAMPLE
> 552272888183 0x19a80 [0x28]: PERF_RECORD_SAMPLE(IP, 2): 3864/3864:
> 0x87b4 period: 1005980 addr: 0
> 552273895263 0x19aa8 [0x28]: PERF_RECORD_SAMPLE(IP, 2): 3864/3864:
> 0x87b4 period: 1005097 addr: 0
> 552274902343 0x19ad0 [0x28]: PERF_RECORD_SAMPLE(IP, 2): 3864/3864:
> 0x87b4 period: 1008113 addr: 0
> 552275909423 0x19af8 [0x28]: PERF_RECORD_SAMPLE(IP, 2): 3864/3864:
> 0x87b4 period: 1007228 addr: 0
> 552276885986 0x19b20 [0x28]: PERF_RECORD_SAMPLE(IP, 2): 3864/3864:
> 0x87b4 period: 1006344 addr: 0
> 552277893066 0x19b48 [0x28]: PERF_RECORD_SAMPLE(IP, 2): 3864/3864:
> 0x87b4 period: 1005461 addr: 0
> 552278900146 0x19b70 [0x28]: PERF_RECORD_SAMPLE(IP, 2): 3864/3864:
> 0x87b4 period: 1008478 addr: 0
> 552279907226 0x19b98 [0x28]: PERF_RECORD_SAMPLE(IP, 2): 3864/3864:
> 0x87b4 period: 1007321 addr: 0
> 552280914306 0x19bc0 [0x28]: PERF_RECORD_SAMPLE(IP, 2): 3864/3864:
> 0x87b4 period: 1006437 addr: 0
> 552281890869 0x19be8 [0x28]: PERF_RECORD_SAMPLE(IP, 2): 3864/3864:
> 0x87b4 period: 1005554 addr: 0
> 552282897949 0x19c10 [0x28]: PERF_RECORD_SAMPLE(IP, 2): 3864/3864:
> 0x87b4 period: 1004672 addr: 0
> 552283905029 0x19c38 [0x28]: PERF_RECORD_SAMPLE(IP, 2): 3864/3864:
> 0x87b4 period: 1007686 addr: 0
> 552284912109 0x19c60 [0x28]: PERF_RECORD_SAMPLE(IP, 2): 3864/3864:
> 0x87b4 period: 1006802 addr: 0
> 552285919189 0x19c88 [0x28]: PERF_RECORD_SAMPLE(IP, 2): 3864/3864:
> 0x87b4 period: 1005918 addr: 0
> 552286895751 0x19cb0 [0x28]: PERF_RECORD_SAMPLE(IP, 2): 3864/3864:
> 0x87b4 period: 1005088 addr: 0
>
> What's important is here is the value of period. on a 1GHz CPU
> sampling @ 1000Hz, should
> be hovering around 1000000000/1000 = 1000000, which is what we're seeing above.
>
> Total samples:
> $ perf report -D | tail -20
> cycles stats:
> ? ? ? ? ? TOTAL events: ? ? ? 8959
> ? ? ? ? ? ?MMAP events: ? ? ? ? 13
> ? ? ? ? ? ?COMM events: ? ? ? ? ?2
> ? ? ? ? ? ?EXIT events: ? ? ? ? ?2
> ? ? ? ? ?SAMPLE events: ? ? ? 8942
>
> Should have 10k samples, we're close.
>
> Without Santosh's:
> 1305066131591 0x143f0 [0x28]: PERF_RECORD_SAMPLE(IP, 2): 3778/3778:
> 0x87b4 period: 6933517 addr: 0
> 1305071594238 0x14418 [0x28]: PERF_RECORD_SAMPLE(IP, 2): 3778/3778:
> 0x87b4 period: 5501604 addr: 0
> 1305075866699 0x14440 [0x28]: PERF_RECORD_SAMPLE(IP, 2): 3778/3778:
> 0x87b4 period: 4429665 addr: 0
> 1305079956054 0x14468 [0x28]: PERF_RECORD_SAMPLE(IP, 2): 3778/3778:
> 0x87b4 period: 3977321 addr: 0
> 1305080017089 0x14490 [0x28]: PERF_RECORD_SAMPLE(IP, 2): 3778/3778:
> 0x87b4 period: 3325451 addr: 0
> 1305085510253 0x144b8 [0x28]: PERF_RECORD_SAMPLE(IP, 2): 3778/3778:
> 0x87b4 period: 3011420 addr: 0
> 1305093994140 0x144e0 [0x28]: PERF_RECORD_SAMPLE(IP, 2): 3778/3778:
> 0x87b4 period: 7804304 addr: 0
> 1305100219726 0x14508 [0x28]: PERF_RECORD_SAMPLE(IP, 2): 3778/3778:
> 0x87b4 period: 6247468 addr: 0
> 1305100280761 0x14530 [0x28]: PERF_RECORD_SAMPLE(IP, 2): 3778/3778:
> 0x87b4 period: 4954601 addr: 0
> 1305106201171 0x14558 [0x28]: PERF_RECORD_SAMPLE(IP, 2): 3778/3778:
> 0x87b4 period: 4434758 addr: 0
> 1305120941162 0x14580 [0x28]: PERF_RECORD_SAMPLE(IP, 2): 3778/3778:
> 0x87b4 period: 11484036 addr: 0
> 1305121826171 0x145a8 [0x28]: PERF_RECORD_SAMPLE(IP, 2): 3778/3778:
> 0x87b4 period: 9130408 addr: 0
> 1305137145996 0x145d0 [0x28]: PERF_RECORD_SAMPLE(IP, 2): 3778/3778:
> 0x87b4 period: 7181085 addr: 0
>
> It's all over the map. And the number of samples is way off:
> $ perf report -D | tail -20
> cycles stats:
> ? ? ? ? ? TOTAL events: ? ? ? 2150
> ? ? ? ? ? ?MMAP events: ? ? ? ? 13
> ? ? ? ? ? ?COMM events: ? ? ? ? ?2
> ? ? ? ? ? ?EXIT events: ? ? ? ? ?2
> ? ? ? ? ?SAMPLE events: ? ? ? 2133
>
> So the fix does help. I am wondering why we're not getting closer to
> 10k samples. But that
> may be due to some overhead somewhere in there.
>

Glad to hear that patch helped you. I will check with OMAP design team
on the issue and post a post to mainline accordingly.

Am keeping below thread as is since this is first time it will apear
on active arm list :)
Regards
Santosh

>
>
> On Tue, Feb 7, 2012 at 10:08 AM, Shilimkar, Santosh
> <santosh.shilimkar@ti.com> wrote:
>> On Tue, Feb 7, 2012 at 2:24 PM, stephane eranian <eranian@googlemail.com> wrote:
>>> Hi,
>>>
>>> There is something I don't understand in this discussion about idle and clock
>>> domain. In my example, I never go idle, I am running a busy loop at
>>> the user level.
>>> Unless there is something I am missing about ARM and clocks, I don't see how
>>> your patches could be helpful. Please enlighten me.
>>>
>> On OMAP specifically there are many power-domains and clock-domains and
>> they sort of independent. ?The clockdomain may be few modules and if
>> all the modules in that clockdomain idle, the clockdomain can idle as
>> well. This all happens in hardware.
>>
>> Your busy loop might keep the CPU and may be interconnect active
>> but l4_wk clockdomain can sitill idle when all the modules in that
>> clock-domain idle.
>>
>> Now the issue seems to be the independent idling of l4wk and
>> MPU. generally whenever there is CPU access for 32k counter,
>> l4_wkup clockdomain and counter should come out of idle and the
>> read should work. This scheme is hardware controlled and we have
>> come across few issues in other modules. So in my patch
>> I am trying to setup a config, in which wherever CPU needs
>> to access ?l4_wkup modules, it will be already active because
>> of the dependency patch sets. This is far more complicated
>> at hardware level but those details are not that important since
>> they behavior is expected to the one mentioned above.
>>
>> Hope this clarifies.
>>
>>> Thanks.
>>>
>>> On Tue, Feb 7, 2012 at 8:31 AM, Shilimkar, Santosh
>>> <santosh.shilimkar@ti.com> wrote:
>>>> On Tue, Feb 7, 2012 at 6:57 AM, David Long <dave.long@linaro.org> wrote:
>>>>>> Ok, so I did a few more tests and there is a serious issue when sampling
>>>>>> in frequency mode (the default). I noticed wrong number of samples, so
>>>>>> I investigated this some more and instrumented the perf_event kernel code.
>>>>>> I found some erratic timer ticks causing broken period adjustments.
>>>>>
>>>>> I also had a report of what appeared to be timer variability using perf
>>>>> on a panda. ?After much experimentation (including disabling frequency
>>>>> scaling) I was forced to conclude that the hardware 32K timer being used
>>>>> for the system tick was occasionally reporting stale values on read.
>>>>> This would give the appearance of code suddenly running impossibly fast
>>>>> for one sample period. ?The time would soon catch up showing an apparent
>>>>> slowing down for one period. ?Eventually I tried changing the 32K clock
>>>>> idle modes and that made the problem disappear. ?I have no explanation
>>>>> for exactly what is going on. ?Here is the diff:
>>>>>
>>>>>
>>>>>
>>>>> For some reason we seem to get stale 32k timer values when we allow the module to
>>>>> auto idle. Prevent this by disabling auto idle for this module.
>>>>>
>>>>> Signed-off-by: David A. Long <dave.long@linaro.org>
>>>>> ---
>>>>> ?arch/arm/mach-omap2/omap_hwmod_44xx_data.c | ? ?2 +-
>>>>> ?1 files changed, 1 insertions(+), 1 deletions(-)
>>>>>
>>>>> diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
>>>>> index daaf165..de6fe96 100644
>>>>> --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
>>>>> +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
>>>>> @@ -896,7 +896,7 @@ static struct omap_hwmod omap44xx_counter_32k_hwmod = {
>>>>> ? ? ? ?.name ? ? ? ? ? = "counter_32k",
>>>>> ? ? ? ?.class ? ? ? ? ?= &omap44xx_counter_hwmod_class,
>>>>> ? ? ? ?.clkdm_name ? ? = "l4_wkup_clkdm",
>>>>> - ? ? ? .flags ? ? ? ? ?= HWMOD_SWSUP_SIDLE,
>>>>> + ? ? ? .flags ? ? ? ? ?= (HWMOD_SWSUP_SIDLE | HWMOD_INIT_NO_IDLE),
>>>>> ? ? ? ?.main_clk ? ? ? = "sys_32k_ck",
>>>>> ? ? ? ?.prcm = {
>>>>> ? ? ? ? ? ? ? ?.omap4 = {
>>>>
>>>> Not sure how the above change will help. 32K counter module mode
>>>> is read-only register, so above change shouldn't have any impact.
>>>>
>>>> ------------------------
>>>> 1:0 MODULEMODE Control the way mandatory clocks are managed.
>>>> R 0x1
>>>> Read 0x1: Module is managed automatically by hardware Rreturns
>>>> according to clock domain transition. A clock domain
>>>> sleep transition put module into idle. A wakeup domain
>>>> transition put it back into function. If CLKTRCTRL=3, any
>>>> INTRCONN access to module is always granted. Module
>>>> clocks may be gated according to the clock domain state.
>>>> --------------------------------------------
>>>>
>>>> But it might not allow the always on l4_wkup clock
>>>> domain to idle and that might be helping.
>>>>
>>>> can you try below change instead of above and it see if it
>>>> helps.
>>>> diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
>>>> index c264ef7..687fcf2 100644
>>>> --- a/arch/arm/mach-omap2/pm44xx.c
>>>> +++ b/arch/arm/mach-omap2/pm44xx.c
>>>> @@ -197,7 +197,7 @@ static int __init omap4_pm_init(void)
>>>> ?{
>>>> ? ? ? ?int ret;
>>>> ? ? ? ?struct clockdomain *emif_clkdm, *mpuss_clkdm, *l3_1_clkdm;
>>>> - ? ? ? struct clockdomain *ducati_clkdm, *l3_2_clkdm, *l4_per_clkdm;
>>>> + ? ? ? struct clockdomain *ducati_clkdm, *l3_2_clkdm, *l4_per_clkdm, *l4wkup;
>>>>
>>>> ? ? ? ?if (!cpu_is_omap44xx())
>>>> ? ? ? ? ? ? ? ?return -ENODEV;
>>>> @@ -227,14 +227,16 @@ static int __init omap4_pm_init(void)
>>>> ? ? ? ?l3_2_clkdm = clkdm_lookup("l3_2_clkdm");
>>>> ? ? ? ?l4_per_clkdm = clkdm_lookup("l4_per_clkdm");
>>>> ? ? ? ?ducati_clkdm = clkdm_lookup("ducati_clkdm");
>>>> + ? ? ? l4wkup = clkdm_lookup("l4_wkup_clkdm");
>>>> ? ? ? ?if ((!mpuss_clkdm) || (!emif_clkdm) || (!l3_1_clkdm) ||
>>>> - ? ? ? ? ? ? ? (!l3_2_clkdm) || (!ducati_clkdm) || (!l4_per_clkdm))
>>>> + ? ? ? (!l3_2_clkdm) || (!ducati_clkdm) || (!l4_per_clkdm) || (!l4wkup))
>>>> ? ? ? ? ? ? ? ?goto err2;
>>>>
>>>> ? ? ? ?ret = clkdm_add_wkdep(mpuss_clkdm, emif_clkdm);
>>>> ? ? ? ?ret |= clkdm_add_wkdep(mpuss_clkdm, l3_1_clkdm);
>>>> ? ? ? ?ret |= clkdm_add_wkdep(mpuss_clkdm, l3_2_clkdm);
>>>> ? ? ? ?ret |= clkdm_add_wkdep(mpuss_clkdm, l4_per_clkdm);
>>>> + ? ? ? ret |= clkdm_add_wkdep(mpuss_clkdm, l4wkup);
>>>> ? ? ? ?ret |= clkdm_add_wkdep(ducati_clkdm, l3_1_clkdm);
>>>> ? ? ? ?ret |= clkdm_add_wkdep(ducati_clkdm, l3_2_clkdm);
>>>> ? ? ? ?if (ret) {

oprofile and ARM A9 hardware counter

[Shilimkar, Santosh]

On Tue, Feb 7, 2012 at 4:23 PM, Shilimkar, Santosh
<santosh.shilimkar@ti.com> wrote:
> ( Removing dead "linux-arm-kernel at lists.arm.linux.org.uk" and adding
> correct list
>
> On Tue, Feb 7, 2012 at 4:07 PM, stephane eranian <eranian@googlemail.com> wrote:
>> Hi,
>>
>> Ok, with Santosh's patch this is much better almost as expected, still
>> 10-15% off.
>>
[....]

>> So the fix does help. I am wondering why we're not getting closer to
>> 10k samples. But that
>> may be due to some overhead somewhere in there.
>>

There might be still a small corner case where few reads
might return the stale value. Counter need at least 1 32K
clock cycle for the sync. udelay is not accurate but
it will at least give min. 1/32768, so it should be
fine.

May be you can try out below patch and see if it helps.

Regards
Santosh

diff --git a/arch/arm/plat-omap/counter_32k.c b/arch/arm/plat-omap/counter_32k.c
index 5f0f229..014d8bd 100644
--- a/arch/arm/plat-omap/counter_32k.c
+++ b/arch/arm/plat-omap/counter_32k.c
@@ -18,6 +18,7 @@
 #include <linux/err.h>
 #include <linux/io.h>
 #include <linux/clocksource.h>
+#include <linux/delay.h>

 #include <asm/sched_clock.h>

@@ -38,6 +39,8 @@ static void __iomem *timer_32k_base;

 static u32 notrace omap_32k_read_sched_clock(void)
 {
+       /* Counter might take 1 clock cycle for OCP sync */
+       udelay(31);
        return timer_32k_base ? __raw_readl(timer_32k_base) : 0;
 }

oprofile and ARM A9 hardware counter

[stephane eranian]

On Tue, Feb 7, 2012 at 12:09 PM, Shilimkar, Santosh
<santosh.shilimkar@ti.com> wrote:
> On Tue, Feb 7, 2012 at 4:23 PM, Shilimkar, Santosh
> <santosh.shilimkar@ti.com> wrote:
>> ( Removing dead "linux-arm-kernel at lists.arm.linux.org.uk" and adding
>> correct list
>>
>> On Tue, Feb 7, 2012 at 4:07 PM, stephane eranian <eranian@googlemail.com> wrote:
>>> Hi,
>>>
>>> Ok, with Santosh's patch this is much better almost as expected, still
>>> 10-15% off.
>>>
> [....]
>
>>> So the fix does help. I am wondering why we're not getting closer to
>>> 10k samples. But that
>>> may be due to some overhead somewhere in there.
>>>
>
> There might be still a small corner case where few reads
> might return the stale value. Counter need at least 1 32K
> clock cycle for the sync. udelay is not accurate but
> it will at least give min. 1/32768, so it should be
> fine.
>
> May be you can try out below patch and see if it helps.
>
> Regards
> Santosh
>
> diff --git a/arch/arm/plat-omap/counter_32k.c b/arch/arm/plat-omap/counter_32k.c
> index 5f0f229..014d8bd 100644
> --- a/arch/arm/plat-omap/counter_32k.c
> +++ b/arch/arm/plat-omap/counter_32k.c
> @@ -18,6 +18,7 @@
> ?#include <linux/err.h>
> ?#include <linux/io.h>
> ?#include <linux/clocksource.h>
> +#include <linux/delay.h>
>
> ?#include <asm/sched_clock.h>
>
> @@ -38,6 +39,8 @@ static void __iomem *timer_32k_base;
>
> ?static u32 notrace omap_32k_read_sched_clock(void)
> ?{
> + ? ? ? /* Counter might take 1 clock cycle for OCP sync */
> + ? ? ? udelay(31);
> ? ? ? ?return timer_32k_base ? __raw_readl(timer_32k_base) : 0;
> ?}
That's worse with this patch (on top of the previous one).

84087402343 0x4a400 [0x28]: PERF_RECORD_SAMPLE(IP, 2): 3774/3774:
0x87b4 period: 989489 addr: 0
84088409423 0x4a428 [0x28]: PERF_RECORD_SAMPLE(IP, 2): 3774/3774:
0x87b4 period: 991744 addr: 0
84089355468 0x4a450 [0x28]: PERF_RECORD_SAMPLE(IP, 2): 3774/3774:
0x87b4 period: 971936 addr: 0
84090332030 0x4a478 [0x28]: PERF_RECORD_SAMPLE(IP, 2): 3774/3774:
0x87b4 period: 971083 addr: 0
84091308593 0x4a4a0 [0x28]: PERF_RECORD_SAMPLE(IP, 2): 3774/3774:
0x87b4 period: 978006 addr: 0
84092254638 0x4a4c8 [0x28]: PERF_RECORD_SAMPLE(IP, 2): 3774/3774:
0x87b4 period: 980940 addr: 0
84093261718 0x4a4f0 [0x28]: PERF_RECORD_SAMPLE(IP, 2): 3774/3774:
0x87b4 period: 983883 addr: 0
84094451903 0x4a518 [0x28]: PERF_RECORD_SAMPLE(IP, 2): 3774/3774:
0x87b4 period: 990897 addr: 0

total samples:
          SAMPLE events:       7571

oprofile and ARM A9 hardware counter

[Shilimkar, Santosh]

On Tue, Feb 7, 2012 at 4:55 PM, stephane eranian <eranian@googlemail.com> wrote:
> On Tue, Feb 7, 2012 at 12:09 PM, Shilimkar, Santosh
> <santosh.shilimkar@ti.com> wrote:
>> On Tue, Feb 7, 2012 at 4:23 PM, Shilimkar, Santosh
>> <santosh.shilimkar@ti.com> wrote:
>>> ( Removing dead "linux-arm-kernel at lists.arm.linux.org.uk" and adding
>>> correct list
>>>
>>> On Tue, Feb 7, 2012 at 4:07 PM, stephane eranian <eranian@googlemail.com> wrote:
>>>> Hi,
>>>>
>>>> Ok, with Santosh's patch this is much better almost as expected, still
>>>> 10-15% off.
>>>>
>> [....]
>>
>>>> So the fix does help. I am wondering why we're not getting closer to
>>>> 10k samples. But that
>>>> may be due to some overhead somewhere in there.
>>>>
>>
>> There might be still a small corner case where few reads
>> might return the stale value. Counter need at least 1 32K
>> clock cycle for the sync. udelay is not accurate but
>> it will at least give min. 1/32768, so it should be
>> fine.
>>
>> May be you can try out below patch and see if it helps.
>>
>> Regards
>> Santosh
>>
>> diff --git a/arch/arm/plat-omap/counter_32k.c b/arch/arm/plat-omap/counter_32k.c
>> index 5f0f229..014d8bd 100644
>> --- a/arch/arm/plat-omap/counter_32k.c
>> +++ b/arch/arm/plat-omap/counter_32k.c
>> @@ -18,6 +18,7 @@
>> ?#include <linux/err.h>
>> ?#include <linux/io.h>
>> ?#include <linux/clocksource.h>
>> +#include <linux/delay.h>
>>
>> ?#include <asm/sched_clock.h>
>>
>> @@ -38,6 +39,8 @@ static void __iomem *timer_32k_base;
>>
>> ?static u32 notrace omap_32k_read_sched_clock(void)
>> ?{
>> + ? ? ? /* Counter might take 1 clock cycle for OCP sync */
>> + ? ? ? udelay(31);
>> ? ? ? ?return timer_32k_base ? __raw_readl(timer_32k_base) : 0;
>> ?}
> That's worse with this patch (on top of the previous one).
>
Thanks for the test. Forget about the last change

oprofile and ARM A9 hardware counter

[stephane eranian]

An easier way to verify we're getting the right number of samples is
to use perf top:

$ taskset -c 1 noploop 1000 &
$ sudo perf top

You'll see around 850 irqs/sec, should be closer to 1000.
But if I drop the rate to 100Hz, then it works:

$ sudo perf top -F 100

That leads me to believe there is too much overhead somewhere.
Could be in perf_event itself.

Will, do you get 1000 irsq/sec running the same test on your systems?


On Tue, Feb 7, 2012 at 12:39 PM, Shilimkar, Santosh
<santosh.shilimkar@ti.com> wrote:
> On Tue, Feb 7, 2012 at 4:55 PM, stephane eranian <eranian@googlemail.com> wrote:
>> On Tue, Feb 7, 2012 at 12:09 PM, Shilimkar, Santosh
>> <santosh.shilimkar@ti.com> wrote:
>>> On Tue, Feb 7, 2012 at 4:23 PM, Shilimkar, Santosh
>>> <santosh.shilimkar@ti.com> wrote:
>>>> ( Removing dead "linux-arm-kernel at lists.arm.linux.org.uk" and adding
>>>> correct list
>>>>
>>>> On Tue, Feb 7, 2012 at 4:07 PM, stephane eranian <eranian@googlemail.com> wrote:
>>>>> Hi,
>>>>>
>>>>> Ok, with Santosh's patch this is much better almost as expected, still
>>>>> 10-15% off.
>>>>>
>>> [....]
>>>
>>>>> So the fix does help. I am wondering why we're not getting closer to
>>>>> 10k samples. But that
>>>>> may be due to some overhead somewhere in there.
>>>>>
>>>
>>> There might be still a small corner case where few reads
>>> might return the stale value. Counter need at least 1 32K
>>> clock cycle for the sync. udelay is not accurate but
>>> it will at least give min. 1/32768, so it should be
>>> fine.
>>>
>>> May be you can try out below patch and see if it helps.
>>>
>>> Regards
>>> Santosh
>>>
>>> diff --git a/arch/arm/plat-omap/counter_32k.c b/arch/arm/plat-omap/counter_32k.c
>>> index 5f0f229..014d8bd 100644
>>> --- a/arch/arm/plat-omap/counter_32k.c
>>> +++ b/arch/arm/plat-omap/counter_32k.c
>>> @@ -18,6 +18,7 @@
>>> ?#include <linux/err.h>
>>> ?#include <linux/io.h>
>>> ?#include <linux/clocksource.h>
>>> +#include <linux/delay.h>
>>>
>>> ?#include <asm/sched_clock.h>
>>>
>>> @@ -38,6 +39,8 @@ static void __iomem *timer_32k_base;
>>>
>>> ?static u32 notrace omap_32k_read_sched_clock(void)
>>> ?{
>>> + ? ? ? /* Counter might take 1 clock cycle for OCP sync */
>>> + ? ? ? udelay(31);
>>> ? ? ? ?return timer_32k_base ? __raw_readl(timer_32k_base) : 0;
>>> ?}
>> That's worse with this patch (on top of the previous one).
>>
> Thanks for the test. Forget about the last change

oprofile and ARM A9 hardware counter

[Will Deacon]

Hi Stephane,

On Tue, Feb 07, 2012 at 11:59:21AM +0000, stephane eranian wrote:
> An easier way to verify we're getting the right number of samples is
> to use perf top:
> 
> $ taskset -c 1 noploop 1000 &
> $ sudo perf top
> 
> You'll see around 850 irqs/sec, should be closer to 1000.
> But if I drop the rate to 100Hz, then it works:
> 
> $ sudo perf top -F 100
> 
> That leads me to believe there is too much overhead somewhere.
> Could be in perf_event itself.
> 
> Will, do you get 1000 irsq/sec running the same test on your systems?

I'm away from my dev boards at the moment, but I'll give this a go next week
and get back to you.

Will

Re: oprofile and ARM A9 hardware counter

[Ming Lei]

Hi,

CC lkml and perf guys, since looks it is related with perf core.

On Tue, Feb 7, 2012 at 7:59 PM, stephane eranian <eranian@googlemail.com> wrote:
> An easier way to verify we're getting the right number of samples is
> to use perf top:
>
> $ taskset -c 1 noploop 1000 &
> $ sudo perf top
>
> You'll see around 850 irqs/sec, should be closer to 1000.
> But if I drop the rate to 100Hz, then it works:
>
> $ sudo perf top -F 100
>
> That leads me to believe there is too much overhead somewhere.
> Could be in perf_event itself.

Looks like the issue is caused by perf_event itself, but nothing to do
with much overhead
somewhere.

On OMAP4, HZ is 128, and perf_rotate_context may set a new sample period(~8ms),
which is much longer than 1ms in 1000HZ freq mode, so less sample events are
observed. X86 isn't affected since its HZ is 1000.

With patch[1], about 10000 sample events can be generated after running
'perf record -e cycles  ./noploop 10' and 'perf report -D | tail -20'
on panda board.

I am not sure if patch[1] is a right fix, but it can verify the problem.

thanks,
--
Ming Lei

[1], fix adjusting frequency in perf_rotate_context

diff --git a/kernel/events/core.c b/kernel/events/core.c
index 32b48c8..db4faf2 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -2300,14 +2300,12 @@ do {					\
 	return div64_u64(dividend, divisor);
 }

-static void perf_adjust_period(struct perf_event *event, u64 nsec, u64 count)
+static void perf_adjust_period(struct perf_event *event, u64 period, u64 count)
 {
 	struct hw_perf_event *hwc = &event->hw;
-	s64 period, sample_period;
+	s64 sample_period;
 	s64 delta;

-	period = perf_calculate_period(event, nsec, count);
-
 	delta = (s64)(period - hwc->sample_period);
 	delta = (delta + 7) / 8; /* low pass filter */

@@ -2363,8 +2361,13 @@ static void perf_ctx_adjust_freq(struct
perf_event_context *ctx, u64 period)
 		delta = now - hwc->freq_count_stamp;
 		hwc->freq_count_stamp = now;

-		if (delta > 0)
+		if (delta > 0) {
+			period = perf_calculate_period(event, period, delta);
+
+			if (period > 4*hwc->sample_period)
+				period = hwc->sample_period;
 			perf_adjust_period(event, period, delta);
+		}
 	}
 }

@@ -4533,8 +4536,10 @@ static int __perf_event_overflow(struct
perf_event *event,

 		hwc->freq_time_stamp = now;

-		if (delta > 0 && delta < 2*TICK_NSEC)
+		if (delta > 0 && delta < 2*TICK_NSEC) {
+			delta = perf_calculate_period(event, delta, hwc->last_period);
 			perf_adjust_period(event, delta, hwc->last_period);
+		}
 	}

 	/*

oprofile and ARM A9 hardware counter

[Ming Lei]

Hi,

CC lkml and perf guys, since looks it is related with perf core.

On Tue, Feb 7, 2012 at 7:59 PM, stephane eranian <eranian@googlemail.com> wrote:
> An easier way to verify we're getting the right number of samples is
> to use perf top:
>
> $ taskset -c 1 noploop 1000 &
> $ sudo perf top
>
> You'll see around 850 irqs/sec, should be closer to 1000.
> But if I drop the rate to 100Hz, then it works:
>
> $ sudo perf top -F 100
>
> That leads me to believe there is too much overhead somewhere.
> Could be in perf_event itself.

Looks like the issue is caused by perf_event itself, but nothing to do
with much overhead
somewhere.

On OMAP4, HZ is 128, and perf_rotate_context may set a new sample period(~8ms),
which is much longer than 1ms in 1000HZ freq mode, so less sample events are
observed. X86 isn't affected since its HZ is 1000.

With patch[1], about 10000 sample events can be generated after running
'perf record -e cycles  ./noploop 10' and 'perf report -D | tail -20'
on panda board.

I am not sure if patch[1] is a right fix, but it can verify the problem.

thanks,
--
Ming Lei

[1], fix adjusting frequency in perf_rotate_context

diff --git a/kernel/events/core.c b/kernel/events/core.c
index 32b48c8..db4faf2 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -2300,14 +2300,12 @@ do {					\
 	return div64_u64(dividend, divisor);
 }

-static void perf_adjust_period(struct perf_event *event, u64 nsec, u64 count)
+static void perf_adjust_period(struct perf_event *event, u64 period, u64 count)
 {
 	struct hw_perf_event *hwc = &event->hw;
-	s64 period, sample_period;
+	s64 sample_period;
 	s64 delta;

-	period = perf_calculate_period(event, nsec, count);
-
 	delta = (s64)(period - hwc->sample_period);
 	delta = (delta + 7) / 8; /* low pass filter */

@@ -2363,8 +2361,13 @@ static void perf_ctx_adjust_freq(struct
perf_event_context *ctx, u64 period)
 		delta = now - hwc->freq_count_stamp;
 		hwc->freq_count_stamp = now;

-		if (delta > 0)
+		if (delta > 0) {
+			period = perf_calculate_period(event, period, delta);
+
+			if (period > 4*hwc->sample_period)
+				period = hwc->sample_period;
 			perf_adjust_period(event, period, delta);
+		}
 	}
 }

@@ -4533,8 +4536,10 @@ static int __perf_event_overflow(struct
perf_event *event,

 		hwc->freq_time_stamp = now;

-		if (delta > 0 && delta < 2*TICK_NSEC)
+		if (delta > 0 && delta < 2*TICK_NSEC) {
+			delta = perf_calculate_period(event, delta, hwc->last_period);
 			perf_adjust_period(event, delta, hwc->last_period);
+		}
 	}

 	/*

Re: oprofile and ARM A9 hardware counter

[Peter Zijlstra]

On Wed, 2012-02-08 at 10:24 +0800, Ming Lei wrote:
> 
> On OMAP4, HZ is 128, and perf_rotate_context may set a new sample period(~8ms),
> which is much longer than 1ms in 1000HZ freq mode, so less sample events are
> observed. X86 isn't affected since its HZ is 1000.
> 
> With patch[1], about 10000 sample events can be generated after running
> 'perf record -e cycles  ./noploop 10' and 'perf report -D | tail -20'
> on panda board.


> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 32b48c8..db4faf2 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -2300,14 +2300,12 @@ do {                                    \
>         return div64_u64(dividend, divisor);
>  }
> 
> -static void perf_adjust_period(struct perf_event *event, u64 nsec, u64 count)
> +static void perf_adjust_period(struct perf_event *event, u64 period, u64 count)
>  {
>         struct hw_perf_event *hwc = &event->hw;
> -       s64 period, sample_period;
> +       s64 sample_period;
>         s64 delta;
> 
> -       period = perf_calculate_period(event, nsec, count);
> -
>         delta = (s64)(period - hwc->sample_period);
>         delta = (delta + 7) / 8; /* low pass filter */
> 
> @@ -2363,8 +2361,13 @@ static void perf_ctx_adjust_freq(struct
> perf_event_context *ctx, u64 period)
>                 delta = now - hwc->freq_count_stamp;
>                 hwc->freq_count_stamp = now;
> 
> -               if (delta > 0)
> +               if (delta > 0) {
> +                       period = perf_calculate_period(event, period, delta);
> +
> +                       if (period > 4*hwc->sample_period)
> +                               period = hwc->sample_period;
>                         perf_adjust_period(event, period, delta);
> +               }
>         }
>  }
> 
> @@ -4533,8 +4536,10 @@ static int __perf_event_overflow(struct
> perf_event *event,
> 
>                 hwc->freq_time_stamp = now;
> 
> -               if (delta > 0 && delta < 2*TICK_NSEC)
> +               if (delta > 0 && delta < 2*TICK_NSEC) {
> +                       delta = perf_calculate_period(event, delta, hwc->last_period);
>                         perf_adjust_period(event, delta, hwc->last_period);
> +               }
>         }
> 
>         /* 

So what this patch seems to do is put that filter on period in
perf_ctx_adjust_freq(). Not making sense.. nor can I see a HZ
dependency, perf_ctx_adjust_freq() uses TICK_NSEC as time base.

oprofile and ARM A9 hardware counter

[Peter Zijlstra]

On Wed, 2012-02-08 at 10:24 +0800, Ming Lei wrote:
> 
> On OMAP4, HZ is 128, and perf_rotate_context may set a new sample period(~8ms),
> which is much longer than 1ms in 1000HZ freq mode, so less sample events are
> observed. X86 isn't affected since its HZ is 1000.
> 
> With patch[1], about 10000 sample events can be generated after running
> 'perf record -e cycles  ./noploop 10' and 'perf report -D | tail -20'
> on panda board.


> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 32b48c8..db4faf2 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -2300,14 +2300,12 @@ do {                                    \
>         return div64_u64(dividend, divisor);
>  }
> 
> -static void perf_adjust_period(struct perf_event *event, u64 nsec, u64 count)
> +static void perf_adjust_period(struct perf_event *event, u64 period, u64 count)
>  {
>         struct hw_perf_event *hwc = &event->hw;
> -       s64 period, sample_period;
> +       s64 sample_period;
>         s64 delta;
> 
> -       period = perf_calculate_period(event, nsec, count);
> -
>         delta = (s64)(period - hwc->sample_period);
>         delta = (delta + 7) / 8; /* low pass filter */
> 
> @@ -2363,8 +2361,13 @@ static void perf_ctx_adjust_freq(struct
> perf_event_context *ctx, u64 period)
>                 delta = now - hwc->freq_count_stamp;
>                 hwc->freq_count_stamp = now;
> 
> -               if (delta > 0)
> +               if (delta > 0) {
> +                       period = perf_calculate_period(event, period, delta);
> +
> +                       if (period > 4*hwc->sample_period)
> +                               period = hwc->sample_period;
>                         perf_adjust_period(event, period, delta);
> +               }
>         }
>  }
> 
> @@ -4533,8 +4536,10 @@ static int __perf_event_overflow(struct
> perf_event *event,
> 
>                 hwc->freq_time_stamp = now;
> 
> -               if (delta > 0 && delta < 2*TICK_NSEC)
> +               if (delta > 0 && delta < 2*TICK_NSEC) {
> +                       delta = perf_calculate_period(event, delta, hwc->last_period);
>                         perf_adjust_period(event, delta, hwc->last_period);
> +               }
>         }
> 
>         /* 

So what this patch seems to do is put that filter on period in
perf_ctx_adjust_freq(). Not making sense.. nor can I see a HZ
dependency, perf_ctx_adjust_freq() uses TICK_NSEC as time base.

Re: oprofile and ARM A9 hardware counter

[Ming Lei]

Hi,

On Thu, Feb 16, 2012 at 12:38 AM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
>
> So what this patch seems to do is put that filter on period in
> perf_ctx_adjust_freq(). Not making sense.. nor can I see a HZ
> dependency, perf_ctx_adjust_freq() uses TICK_NSEC as time base.

Yes, you are right, I remembered it was observed it on -rc1, and
Stephane's unthrottling
patch was not merged at that time. Today I investigated the problem
further on -rc3 and found that seems the problem is caused by arm pmu code.

The patch below may fix the problem, now about 40000 sample events
can be generated on the command:

	'perf record -e cycles -F 4000  ./noploop 10&& perf report -D | tail -20'

armpmu_event_update may be called in tick path, so the running counter
will be overflowed and produce a great value of 'delta', then a mistaken
count is stored into event->count and event->hw.freq_count_stamp. Finally
the two variables are not synchronous, then a invalid and large period is
computed and written to pmu, and sample events are decreased much.

Will, this patch simplifies the 'delta' computation and doesn't use the
overflow flag, even though which can be read directly from PMOVSR, could you
comment on the patch?

diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
index 5bb91bf..789700a 100644
--- a/arch/arm/kernel/perf_event.c
+++ b/arch/arm/kernel/perf_event.c
@@ -193,13 +193,8 @@ again:
 			     new_raw_count) != prev_raw_count)
 		goto again;

-	new_raw_count &= armpmu->max_period;
-	prev_raw_count &= armpmu->max_period;
-
-	if (overflow)
-		delta = armpmu->max_period - prev_raw_count + new_raw_count + 1;
-	else
-		delta = new_raw_count - prev_raw_count;
+	delta = (armpmu->max_period - prev_raw_count + new_raw_count
+				+ 1) & armpmu->max_period;

 	local64_add(delta, &event->count);
 	local64_sub(delta, &hwc->period_left);


thanks,
--
Ming Lei

oprofile and ARM A9 hardware counter

[Ming Lei]

Hi,

On Thu, Feb 16, 2012 at 12:38 AM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
>
> So what this patch seems to do is put that filter on period in
> perf_ctx_adjust_freq(). Not making sense.. nor can I see a HZ
> dependency, perf_ctx_adjust_freq() uses TICK_NSEC as time base.

Yes, you are right, I remembered it was observed it on -rc1, and
Stephane's unthrottling
patch was not merged at that time. Today I investigated the problem
further on -rc3 and found that seems the problem is caused by arm pmu code.

The patch below may fix the problem, now about 40000 sample events
can be generated on the command:

	'perf record -e cycles -F 4000  ./noploop 10&& perf report -D | tail -20'

armpmu_event_update may be called in tick path, so the running counter
will be overflowed and produce a great value of 'delta', then a mistaken
count is stored into event->count and event->hw.freq_count_stamp. Finally
the two variables are not synchronous, then a invalid and large period is
computed and written to pmu, and sample events are decreased much.

Will, this patch simplifies the 'delta' computation and doesn't use the
overflow flag, even though which can be read directly from PMOVSR, could you
comment on the patch?

diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
index 5bb91bf..789700a 100644
--- a/arch/arm/kernel/perf_event.c
+++ b/arch/arm/kernel/perf_event.c
@@ -193,13 +193,8 @@ again:
 			     new_raw_count) != prev_raw_count)
 		goto again;

-	new_raw_count &= armpmu->max_period;
-	prev_raw_count &= armpmu->max_period;
-
-	if (overflow)
-		delta = armpmu->max_period - prev_raw_count + new_raw_count + 1;
-	else
-		delta = new_raw_count - prev_raw_count;
+	delta = (armpmu->max_period - prev_raw_count + new_raw_count
+				+ 1) & armpmu->max_period;

 	local64_add(delta, &event->count);
 	local64_sub(delta, &hwc->period_left);


thanks,
--
Ming Lei

Re: oprofile and ARM A9 hardware counter

[Will Deacon]

On Thu, Feb 16, 2012 at 10:25:05AM +0000, Ming Lei wrote:
> On Thu, Feb 16, 2012 at 12:38 AM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> >
> > So what this patch seems to do is put that filter on period in
> > perf_ctx_adjust_freq(). Not making sense.. nor can I see a HZ
> > dependency, perf_ctx_adjust_freq() uses TICK_NSEC as time base.
> 
> Yes, you are right, I remembered it was observed it on -rc1, and
> Stephane's unthrottling
> patch was not merged at that time. Today I investigated the problem
> further on -rc3 and found that seems the problem is caused by arm pmu code.

As I reported previously, Stephane's patch is causing warnings on -rc3:

http://lists.infradead.org/pipermail/linux-arm-kernel/2012-February/084391.html

so I'd like to get to the bottom of that before changing anything else.

I'd also like to know why this has only been reported on OMAP4 and I can't
reproduce it on my boards.

> The patch below may fix the problem, now about 40000 sample events
> can be generated on the command:
> 
> 	'perf record -e cycles -F 4000  ./noploop 10&& perf report -D | tail -20'
> 
> armpmu_event_update may be called in tick path, so the running counter
> will be overflowed and produce a great value of 'delta', then a mistaken
> count is stored into event->count and event->hw.freq_count_stamp. Finally
> the two variables are not synchronous, then a invalid and large period is
> computed and written to pmu, and sample events are decreased much.

Hmm, so are you observing an event overflow during the tick handler? This
should be fine unless the new value has wrapped past the previous one (i.e.
more than 2^32 events have occurred). I find this extremely unlikely for
sample-based profiling unless you have some major IRQ latency issues...

The only way I can think of improving this (bearing in mind that at some
point we're limited by 32 bits of counter) is to check for overflow in the
tick path and then invoke the PMU irq handler if there is an overflow, but
that's really not very nice.

> diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
> index 5bb91bf..789700a 100644
> --- a/arch/arm/kernel/perf_event.c
> +++ b/arch/arm/kernel/perf_event.c
> @@ -193,13 +193,8 @@ again:
>  			     new_raw_count) != prev_raw_count)
>  		goto again;
> 
> -	new_raw_count &= armpmu->max_period;
> -	prev_raw_count &= armpmu->max_period;
> -
> -	if (overflow)
> -		delta = armpmu->max_period - prev_raw_count + new_raw_count + 1;
> -	else
> -		delta = new_raw_count - prev_raw_count;
> +	delta = (armpmu->max_period - prev_raw_count + new_raw_count
> +				+ 1) & armpmu->max_period;

This breaks when more than max_period events have passed. See a737823d
("ARM: 6835/1: perf: ensure overflows aren't missed due to IRQ latency").

Will

oprofile and ARM A9 hardware counter

[Will Deacon]

On Thu, Feb 16, 2012 at 10:25:05AM +0000, Ming Lei wrote:
> On Thu, Feb 16, 2012 at 12:38 AM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> >
> > So what this patch seems to do is put that filter on period in
> > perf_ctx_adjust_freq(). Not making sense.. nor can I see a HZ
> > dependency, perf_ctx_adjust_freq() uses TICK_NSEC as time base.
> 
> Yes, you are right, I remembered it was observed it on -rc1, and
> Stephane's unthrottling
> patch was not merged at that time. Today I investigated the problem
> further on -rc3 and found that seems the problem is caused by arm pmu code.

As I reported previously, Stephane's patch is causing warnings on -rc3:

http://lists.infradead.org/pipermail/linux-arm-kernel/2012-February/084391.html

so I'd like to get to the bottom of that before changing anything else.

I'd also like to know why this has only been reported on OMAP4 and I can't
reproduce it on my boards.

> The patch below may fix the problem, now about 40000 sample events
> can be generated on the command:
> 
> 	'perf record -e cycles -F 4000  ./noploop 10&& perf report -D | tail -20'
> 
> armpmu_event_update may be called in tick path, so the running counter
> will be overflowed and produce a great value of 'delta', then a mistaken
> count is stored into event->count and event->hw.freq_count_stamp. Finally
> the two variables are not synchronous, then a invalid and large period is
> computed and written to pmu, and sample events are decreased much.

Hmm, so are you observing an event overflow during the tick handler? This
should be fine unless the new value has wrapped past the previous one (i.e.
more than 2^32 events have occurred). I find this extremely unlikely for
sample-based profiling unless you have some major IRQ latency issues...

The only way I can think of improving this (bearing in mind that at some
point we're limited by 32 bits of counter) is to check for overflow in the
tick path and then invoke the PMU irq handler if there is an overflow, but
that's really not very nice.

> diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
> index 5bb91bf..789700a 100644
> --- a/arch/arm/kernel/perf_event.c
> +++ b/arch/arm/kernel/perf_event.c
> @@ -193,13 +193,8 @@ again:
>  			     new_raw_count) != prev_raw_count)
>  		goto again;
> 
> -	new_raw_count &= armpmu->max_period;
> -	prev_raw_count &= armpmu->max_period;
> -
> -	if (overflow)
> -		delta = armpmu->max_period - prev_raw_count + new_raw_count + 1;
> -	else
> -		delta = new_raw_count - prev_raw_count;
> +	delta = (armpmu->max_period - prev_raw_count + new_raw_count
> +				+ 1) & armpmu->max_period;

This breaks when more than max_period events have passed. See a737823d
("ARM: 6835/1: perf: ensure overflows aren't missed due to IRQ latency").

Will

Re: oprofile and ARM A9 hardware counter

[Ming Lei]

On Thu, Feb 16, 2012 at 11:00 PM, Will Deacon <will.deacon@arm.com> wrote:
> On Thu, Feb 16, 2012 at 10:25:05AM +0000, Ming Lei wrote:
>> On Thu, Feb 16, 2012 at 12:38 AM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
>> >
>> > So what this patch seems to do is put that filter on period in
>> > perf_ctx_adjust_freq(). Not making sense.. nor can I see a HZ
>> > dependency, perf_ctx_adjust_freq() uses TICK_NSEC as time base.
>>
>> Yes, you are right, I remembered it was observed it on -rc1, and
>> Stephane's unthrottling
>> patch was not merged at that time. Today I investigated the problem
>> further on -rc3 and found that seems the problem is caused by arm pmu code.
>
> As I reported previously, Stephane's patch is causing warnings on -rc3:
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2012-February/084391.html
>
> so I'd like to get to the bottom of that before changing anything else.

Looks I am luck enough and not see the warning on OMAP4, either -rc3 or
-rc3--next-20120210, :-)

Maybe we have different config options.

>
> I'd also like to know why this has only been reported on OMAP4 and I can't
> reproduce it on my boards.
>
>> The patch below may fix the problem, now about 40000 sample events
>> can be generated on the command:
>>
>>       'perf record -e cycles -F 4000  ./noploop 10&& perf report -D | tail -20'
>>
>> armpmu_event_update may be called in tick path, so the running counter
>> will be overflowed and produce a great value of 'delta', then a mistaken
>> count is stored into event->count and event->hw.freq_count_stamp. Finally
>> the two variables are not synchronous, then a invalid and large period is
>> computed and written to pmu, and sample events are decreased much.
>
> Hmm, so are you observing an event overflow during the tick handler? This

Yes, I am sure I can observe it without much difficulty.

> should be fine unless the new value has wrapped past the previous one (i.e.
> more than 2^32 events have occurred). I find this extremely unlikely for
> sample-based profiling unless you have some major IRQ latency issues...

IMO, it is not so difficult to get it, suppose prev_raw_count is
1000000 and -prev_raw_count
was write to one pmu counter, then the counter will be expired and pmu
irq is not handled
quickly enough, so the pmu counter will warp and start counting from zero.

When the tick is scheduled just before handling pmu irq,
armpmu_event_update() is
called to read the pmu counter as 'new_raw_count', suppose it is 100,
then the issue
is triggered: u64 delta = 100 -  1000000 = 18446744073708551716.

Looks the higher the frequency is, the easier the problem is reproduced.

>
> The only way I can think of improving this (bearing in mind that at some
> point we're limited by 32 bits of counter) is to check for overflow in the
> tick path and then invoke the PMU irq handler if there is an overflow, but
> that's really not very nice.

Also we may remove the 'overflow' parameter from armpmu_event_update,
and introduce armpmu->is_overflow(idx) callback to check if the counter(event)
is overflow inside armpmu_event_update.

IMO, the pmu irq can't be lost, so the pmu irq handler is not needed to invoke
in tick path.

>
>> diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
>> index 5bb91bf..789700a 100644
>> --- a/arch/arm/kernel/perf_event.c
>> +++ b/arch/arm/kernel/perf_event.c
>> @@ -193,13 +193,8 @@ again:
>>                            new_raw_count) != prev_raw_count)
>>               goto again;
>>
>> -     new_raw_count &= armpmu->max_period;
>> -     prev_raw_count &= armpmu->max_period;
>> -
>> -     if (overflow)
>> -             delta = armpmu->max_period - prev_raw_count + new_raw_count + 1;
>> -     else
>> -             delta = new_raw_count - prev_raw_count;
>> +     delta = (armpmu->max_period - prev_raw_count + new_raw_count
>> +                             + 1) & armpmu->max_period;
>
> This breaks when more than max_period events have passed. See a737823d
> ("ARM: 6835/1: perf: ensure overflows aren't missed due to IRQ latency").

Sorry, I didn't notice the commit and the problem addressed, so looks
the 'overflow'
information is needed for armpmu_event_update.

thanks,
--
Ming Lei

oprofile and ARM A9 hardware counter

[Ming Lei]

On Thu, Feb 16, 2012 at 11:00 PM, Will Deacon <will.deacon@arm.com> wrote:
> On Thu, Feb 16, 2012 at 10:25:05AM +0000, Ming Lei wrote:
>> On Thu, Feb 16, 2012 at 12:38 AM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
>> >
>> > So what this patch seems to do is put that filter on period in
>> > perf_ctx_adjust_freq(). Not making sense.. nor can I see a HZ
>> > dependency, perf_ctx_adjust_freq() uses TICK_NSEC as time base.
>>
>> Yes, you are right, I remembered it was observed it on -rc1, and
>> Stephane's unthrottling
>> patch was not merged at that time. Today I investigated the problem
>> further on -rc3 and found that seems the problem is caused by arm pmu code.
>
> As I reported previously, Stephane's patch is causing warnings on -rc3:
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2012-February/084391.html
>
> so I'd like to get to the bottom of that before changing anything else.

Looks I am luck enough and not see the warning on OMAP4, either -rc3 or
-rc3--next-20120210, :-)

Maybe we have different config options.

>
> I'd also like to know why this has only been reported on OMAP4 and I can't
> reproduce it on my boards.
>
>> The patch below may fix the problem, now about 40000 sample events
>> can be generated on the command:
>>
>> ? ? ? 'perf record -e cycles -F 4000 ?./noploop 10&& perf report -D | tail -20'
>>
>> armpmu_event_update may be called in tick path, so the running counter
>> will be overflowed and produce a great value of 'delta', then a mistaken
>> count is stored into event->count and event->hw.freq_count_stamp. Finally
>> the two variables are not synchronous, then a invalid and large period is
>> computed and written to pmu, and sample events are decreased much.
>
> Hmm, so are you observing an event overflow during the tick handler? This

Yes, I am sure I can observe it without much difficulty.

> should be fine unless the new value has wrapped past the previous one (i.e.
> more than 2^32 events have occurred). I find this extremely unlikely for
> sample-based profiling unless you have some major IRQ latency issues...

IMO, it is not so difficult to get it, suppose prev_raw_count is
1000000 and -prev_raw_count
was write to one pmu counter, then the counter will be expired and pmu
irq is not handled
quickly enough, so the pmu counter will warp and start counting from zero.

When the tick is scheduled just before handling pmu irq,
armpmu_event_update() is
called to read the pmu counter as 'new_raw_count', suppose it is 100,
then the issue
is triggered: u64 delta = 100 -  1000000 = 18446744073708551716.

Looks the higher the frequency is, the easier the problem is reproduced.

>
> The only way I can think of improving this (bearing in mind that at some
> point we're limited by 32 bits of counter) is to check for overflow in the
> tick path and then invoke the PMU irq handler if there is an overflow, but
> that's really not very nice.

Also we may remove the 'overflow' parameter from armpmu_event_update,
and introduce armpmu->is_overflow(idx) callback to check if the counter(event)
is overflow inside armpmu_event_update.

IMO, the pmu irq can't be lost, so the pmu irq handler is not needed to invoke
in tick path.

>
>> diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
>> index 5bb91bf..789700a 100644
>> --- a/arch/arm/kernel/perf_event.c
>> +++ b/arch/arm/kernel/perf_event.c
>> @@ -193,13 +193,8 @@ again:
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ?new_raw_count) != prev_raw_count)
>> ? ? ? ? ? ? ? goto again;
>>
>> - ? ? new_raw_count &= armpmu->max_period;
>> - ? ? prev_raw_count &= armpmu->max_period;
>> -
>> - ? ? if (overflow)
>> - ? ? ? ? ? ? delta = armpmu->max_period - prev_raw_count + new_raw_count + 1;
>> - ? ? else
>> - ? ? ? ? ? ? delta = new_raw_count - prev_raw_count;
>> + ? ? delta = (armpmu->max_period - prev_raw_count + new_raw_count
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? + 1) & armpmu->max_period;
>
> This breaks when more than max_period events have passed. See a737823d
> ("ARM: 6835/1: perf: ensure overflows aren't missed due to IRQ latency").

Sorry, I didn't notice the commit and the problem addressed, so looks
the 'overflow'
information is needed for armpmu_event_update.

thanks,
--
Ming Lei

Re: oprofile and ARM A9 hardware counter

[Peter Zijlstra]

On Fri, 2012-02-17 at 00:12 +0800, Ming Lei wrote:
> is triggered: u64 delta = 100 -  1000000 = 18446744073708551716.

on x86 we do:

  int shift = 64 - x86_pmu.cntval_bits;
  s64 delta;

  delta = (new_raw_count << shift) - (prev_raw_count << shift);
  delta >>= shift;

This deals with short overflows (on x86 the registers are typically 40
or 48 bits wide). If the arm register is 32 you can of course also get
there with some u32 casts.

oprofile and ARM A9 hardware counter

[Peter Zijlstra]

On Fri, 2012-02-17 at 00:12 +0800, Ming Lei wrote:
> is triggered: u64 delta = 100 -  1000000 = 18446744073708551716.

on x86 we do:

  int shift = 64 - x86_pmu.cntval_bits;
  s64 delta;

  delta = (new_raw_count << shift) - (prev_raw_count << shift);
  delta >>= shift;

This deals with short overflows (on x86 the registers are typically 40
or 48 bits wide). If the arm register is 32 you can of course also get
there with some u32 casts.

Re: oprofile and ARM A9 hardware counter

[Ming Lei]

On Fri, Feb 17, 2012 at 12:19 AM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> On Fri, 2012-02-17 at 00:12 +0800, Ming Lei wrote:
>> is triggered: u64 delta = 100 -  1000000 = 18446744073708551716.
>
> on x86 we do:
>
>  int shift = 64 - x86_pmu.cntval_bits;
>  s64 delta;
>
>  delta = (new_raw_count << shift) - (prev_raw_count << shift);
>  delta >>= shift;
>
> This deals with short overflows (on x86 the registers are typically 40
> or 48 bits wide). If the arm register is 32 you can of course also get
> there with some u32 casts.

Good idea, but it may not work if new_raw_count is bigger than prev_raw_count.

thanks
--
Ming Lei

oprofile and ARM A9 hardware counter

[Ming Lei]

On Fri, Feb 17, 2012 at 12:19 AM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> On Fri, 2012-02-17 at 00:12 +0800, Ming Lei wrote:
>> is triggered: u64 delta = 100 - ?1000000 = 18446744073708551716.
>
> on x86 we do:
>
> ?int shift = 64 - x86_pmu.cntval_bits;
> ?s64 delta;
>
> ?delta = (new_raw_count << shift) - (prev_raw_count << shift);
> ?delta >>= shift;
>
> This deals with short overflows (on x86 the registers are typically 40
> or 48 bits wide). If the arm register is 32 you can of course also get
> there with some u32 casts.

Good idea, but it may not work if new_raw_count is bigger than prev_raw_count.

thanks
--
Ming Lei

Re: oprofile and ARM A9 hardware counter

[Will Deacon]

On Thu, Feb 16, 2012 at 04:37:35PM +0000, Ming Lei wrote:
> On Fri, Feb 17, 2012 at 12:19 AM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> > On Fri, 2012-02-17 at 00:12 +0800, Ming Lei wrote:
> >> is triggered: u64 delta = 100 -  1000000 = 18446744073708551716.
> >
> > on x86 we do:
> >
> >  int shift = 64 - x86_pmu.cntval_bits;
> >  s64 delta;
> >
> >  delta = (new_raw_count << shift) - (prev_raw_count << shift);
> >  delta >>= shift;
> >
> > This deals with short overflows (on x86 the registers are typically 40
> > or 48 bits wide). If the arm register is 32 you can of course also get
> > there with some u32 casts.
> 
> Good idea, but it may not work if new_raw_count is bigger than prev_raw_count.

The more I think about this, the more I think that the overflow parameter to
armpmu_event_update needs to go. It was introduced to prevent massive event
loss in non-sampling mode, but I think we can get around that by changing
the default sample_period to be half of the max_period, therefore giving
ourselves a much better chance of handling the interrupt before new wraps
around past prev.

Ming Lei - can you try the following please? If it works for you, then I'll
do it properly and kill the overflow parameter altogether.

Thanks,

Will

git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
index 5bb91bf..ef597a3 100644
--- a/arch/arm/kernel/perf_event.c
+++ b/arch/arm/kernel/perf_event.c
@@ -193,13 +193,7 @@ again:
                             new_raw_count) != prev_raw_count)
                goto again;
 
-       new_raw_count &= armpmu->max_period;
-       prev_raw_count &= armpmu->max_period;
-
-       if (overflow)
-               delta = armpmu->max_period - prev_raw_count + new_raw_count + 1;
-       else
-               delta = new_raw_count - prev_raw_count;
+       delta = (new_raw_count - prev_raw_count) & armpmu->max_period;
 
        local64_add(delta, &event->count);
        local64_sub(delta, &hwc->period_left);
@@ -518,7 +512,7 @@ __hw_perf_event_init(struct perf_event *event)
        hwc->config_base            |= (unsigned long)mapping;
 
        if (!hwc->sample_period) {
-               hwc->sample_period  = armpmu->max_period;
+               hwc->sample_period  = armpmu->max_period >> 1;
                hwc->last_period    = hwc->sample_period;
                local64_set(&hwc->period_left, hwc->sample_period);
        }

oprofile and ARM A9 hardware counter

[Will Deacon]

On Thu, Feb 16, 2012 at 04:37:35PM +0000, Ming Lei wrote:
> On Fri, Feb 17, 2012 at 12:19 AM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> > On Fri, 2012-02-17 at 00:12 +0800, Ming Lei wrote:
> >> is triggered: u64 delta = 100 - ?1000000 = 18446744073708551716.
> >
> > on x86 we do:
> >
> > ?int shift = 64 - x86_pmu.cntval_bits;
> > ?s64 delta;
> >
> > ?delta = (new_raw_count << shift) - (prev_raw_count << shift);
> > ?delta >>= shift;
> >
> > This deals with short overflows (on x86 the registers are typically 40
> > or 48 bits wide). If the arm register is 32 you can of course also get
> > there with some u32 casts.
> 
> Good idea, but it may not work if new_raw_count is bigger than prev_raw_count.

The more I think about this, the more I think that the overflow parameter to
armpmu_event_update needs to go. It was introduced to prevent massive event
loss in non-sampling mode, but I think we can get around that by changing
the default sample_period to be half of the max_period, therefore giving
ourselves a much better chance of handling the interrupt before new wraps
around past prev.

Ming Lei - can you try the following please? If it works for you, then I'll
do it properly and kill the overflow parameter altogether.

Thanks,

Will

git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
index 5bb91bf..ef597a3 100644
--- a/arch/arm/kernel/perf_event.c
+++ b/arch/arm/kernel/perf_event.c
@@ -193,13 +193,7 @@ again:
                             new_raw_count) != prev_raw_count)
                goto again;
 
-       new_raw_count &= armpmu->max_period;
-       prev_raw_count &= armpmu->max_period;
-
-       if (overflow)
-               delta = armpmu->max_period - prev_raw_count + new_raw_count + 1;
-       else
-               delta = new_raw_count - prev_raw_count;
+       delta = (new_raw_count - prev_raw_count) & armpmu->max_period;
 
        local64_add(delta, &event->count);
        local64_sub(delta, &hwc->period_left);
@@ -518,7 +512,7 @@ __hw_perf_event_init(struct perf_event *event)
        hwc->config_base            |= (unsigned long)mapping;
 
        if (!hwc->sample_period) {
-               hwc->sample_period  = armpmu->max_period;
+               hwc->sample_period  = armpmu->max_period >> 1;
                hwc->last_period    = hwc->sample_period;
                local64_set(&hwc->period_left, hwc->sample_period);
        }

Re: oprofile and ARM A9 hardware counter

[Ming Lei]

On Fri, Feb 17, 2012 at 2:08 AM, Will Deacon <will.deacon@arm.com> wrote:

>
> The more I think about this, the more I think that the overflow parameter to
> armpmu_event_update needs to go. It was introduced to prevent massive event
> loss in non-sampling mode, but I think we can get around that by changing
> the default sample_period to be half of the max_period, therefore giving
> ourselves a much better chance of handling the interrupt before new wraps
> around past prev.
>
> Ming Lei - can you try the following please? If it works for you, then I'll
> do it properly and kill the overflow parameter altogether.

Of course, it does work for the problem reported by Stephane since
it changes the delta computation basically as I did, but I am afraid that
it may be not good enough for the issue fixed in a737823d ("ARM: 6835/1:
perf: ensure overflows aren't missed due to IRQ latency").

>
> Thanks,
>
> Will
>
> git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
> index 5bb91bf..ef597a3 100644
> --- a/arch/arm/kernel/perf_event.c
> +++ b/arch/arm/kernel/perf_event.c
> @@ -193,13 +193,7 @@ again:
>                             new_raw_count) != prev_raw_count)
>                goto again;
>
> -       new_raw_count &= armpmu->max_period;
> -       prev_raw_count &= armpmu->max_period;
> -
> -       if (overflow)
> -               delta = armpmu->max_period - prev_raw_count + new_raw_count + 1;
> -       else
> -               delta = new_raw_count - prev_raw_count;
> +       delta = (new_raw_count - prev_raw_count) & armpmu->max_period;
>
>        local64_add(delta, &event->count);
>        local64_sub(delta, &hwc->period_left);
> @@ -518,7 +512,7 @@ __hw_perf_event_init(struct perf_event *event)
>        hwc->config_base            |= (unsigned long)mapping;
>
>        if (!hwc->sample_period) {
> -               hwc->sample_period  = armpmu->max_period;
> +               hwc->sample_period  = armpmu->max_period >> 1;

If you assume that the issue addressed by a737823d can only happen in
non-sample situation, Peter's idea of u32 cast is OK and maybe simpler.

But I am afraid that the issue still can be triggered in sample-based situation,
especially in very high frequency case: suppose the sample freq is 10000,
100us IRQ delay may trigger the issue.

So we may use the overflow information to make perf more robust, IMO.

thanks
--
Ming Lei

oprofile and ARM A9 hardware counter

[Ming Lei]

On Fri, Feb 17, 2012 at 2:08 AM, Will Deacon <will.deacon@arm.com> wrote:

>
> The more I think about this, the more I think that the overflow parameter to
> armpmu_event_update needs to go. It was introduced to prevent massive event
> loss in non-sampling mode, but I think we can get around that by changing
> the default sample_period to be half of the max_period, therefore giving
> ourselves a much better chance of handling the interrupt before new wraps
> around past prev.
>
> Ming Lei - can you try the following please? If it works for you, then I'll
> do it properly and kill the overflow parameter altogether.

Of course, it does work for the problem reported by Stephane since
it changes the delta computation basically as I did, but I am afraid that
it may be not good enough for the issue fixed in a737823d ("ARM: 6835/1:
perf: ensure overflows aren't missed due to IRQ latency").

>
> Thanks,
>
> Will
>
> git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
> index 5bb91bf..ef597a3 100644
> --- a/arch/arm/kernel/perf_event.c
> +++ b/arch/arm/kernel/perf_event.c
> @@ -193,13 +193,7 @@ again:
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? new_raw_count) != prev_raw_count)
> ? ? ? ? ? ? ? ?goto again;
>
> - ? ? ? new_raw_count &= armpmu->max_period;
> - ? ? ? prev_raw_count &= armpmu->max_period;
> -
> - ? ? ? if (overflow)
> - ? ? ? ? ? ? ? delta = armpmu->max_period - prev_raw_count + new_raw_count + 1;
> - ? ? ? else
> - ? ? ? ? ? ? ? delta = new_raw_count - prev_raw_count;
> + ? ? ? delta = (new_raw_count - prev_raw_count) & armpmu->max_period;
>
> ? ? ? ?local64_add(delta, &event->count);
> ? ? ? ?local64_sub(delta, &hwc->period_left);
> @@ -518,7 +512,7 @@ __hw_perf_event_init(struct perf_event *event)
> ? ? ? ?hwc->config_base ? ? ? ? ? ?|= (unsigned long)mapping;
>
> ? ? ? ?if (!hwc->sample_period) {
> - ? ? ? ? ? ? ? hwc->sample_period ?= armpmu->max_period;
> + ? ? ? ? ? ? ? hwc->sample_period ?= armpmu->max_period >> 1;

If you assume that the issue addressed by a737823d can only happen in
non-sample situation, Peter's idea of u32 cast is OK and maybe simpler.

But I am afraid that the issue still can be triggered in sample-based situation,
especially in very high frequency case: suppose the sample freq is 10000,
100us IRQ delay may trigger the issue.

So we may use the overflow information to make perf more robust, IMO.

thanks
--
Ming Lei

Re: oprofile and ARM A9 hardware counter

[Will Deacon]

On Fri, Feb 17, 2012 at 05:24:02AM +0000, Ming Lei wrote:
> On Fri, Feb 17, 2012 at 2:08 AM, Will Deacon <will.deacon@arm.com> wrote:
> 
> >
> > The more I think about this, the more I think that the overflow parameter to
> > armpmu_event_update needs to go. It was introduced to prevent massive event
> > loss in non-sampling mode, but I think we can get around that by changing
> > the default sample_period to be half of the max_period, therefore giving
> > ourselves a much better chance of handling the interrupt before new wraps
> > around past prev.
> >
> > Ming Lei - can you try the following please? If it works for you, then I'll
> > do it properly and kill the overflow parameter altogether.
> 
> Of course, it does work for the problem reported by Stephane since
> it changes the delta computation basically as I did, but I am afraid that
> it may be not good enough for the issue fixed in a737823d ("ARM: 6835/1:
> perf: ensure overflows aren't missed due to IRQ latency").

I think it does solve that problem.

> >
> >        if (!hwc->sample_period) {
> > -               hwc->sample_period  = armpmu->max_period;
> > +               hwc->sample_period  = armpmu->max_period >> 1;
> 
> If you assume that the issue addressed by a737823d can only happen in
> non-sample situation, Peter's idea of u32 cast is OK and maybe simpler.

I don't want to assume that the counters are 32-bit in this code as we may
want to plug in some other PMU with 16-bit counters, for example. That's why
we have max_period defined for each PMU. Furthermore, it still doesn't help us
in the stat case where prev will typically be quite small after we've had an
overflow and new may well overtake it.

> But I am afraid that the issue still can be triggered in sample-based situation,
> especially in very high frequency case: suppose the sample freq is 10000,
> 100us IRQ delay may trigger the issue.

Not sure I follow. If the frequency is 10000, then we write 0xffffd8f0 to
the counter. That means we have a 0xffffd8f0 event window to read the
counter after it overflows before new overtakes prev and we get confused.
If this passed in 100us then either your clock speed is 4.3*10^12Hz or you
have a seriously wide issue :)

> So we may use the overflow information to make perf more robust, IMO.

There's a trade off between allowing the counter to wrap back around past
its previous value or being able to handle overflow on a non-interrupt path.
Given that the former problem is only a real issue for non-sampling runs,
halving the period in that case should sort it (and it does stop my simple
test case from exploding).

Will

oprofile and ARM A9 hardware counter

[Will Deacon]

On Fri, Feb 17, 2012 at 05:24:02AM +0000, Ming Lei wrote:
> On Fri, Feb 17, 2012 at 2:08 AM, Will Deacon <will.deacon@arm.com> wrote:
> 
> >
> > The more I think about this, the more I think that the overflow parameter to
> > armpmu_event_update needs to go. It was introduced to prevent massive event
> > loss in non-sampling mode, but I think we can get around that by changing
> > the default sample_period to be half of the max_period, therefore giving
> > ourselves a much better chance of handling the interrupt before new wraps
> > around past prev.
> >
> > Ming Lei - can you try the following please? If it works for you, then I'll
> > do it properly and kill the overflow parameter altogether.
> 
> Of course, it does work for the problem reported by Stephane since
> it changes the delta computation basically as I did, but I am afraid that
> it may be not good enough for the issue fixed in a737823d ("ARM: 6835/1:
> perf: ensure overflows aren't missed due to IRQ latency").

I think it does solve that problem.

> >
> > ? ? ? ?if (!hwc->sample_period) {
> > - ? ? ? ? ? ? ? hwc->sample_period ?= armpmu->max_period;
> > + ? ? ? ? ? ? ? hwc->sample_period ?= armpmu->max_period >> 1;
> 
> If you assume that the issue addressed by a737823d can only happen in
> non-sample situation, Peter's idea of u32 cast is OK and maybe simpler.

I don't want to assume that the counters are 32-bit in this code as we may
want to plug in some other PMU with 16-bit counters, for example. That's why
we have max_period defined for each PMU. Furthermore, it still doesn't help us
in the stat case where prev will typically be quite small after we've had an
overflow and new may well overtake it.

> But I am afraid that the issue still can be triggered in sample-based situation,
> especially in very high frequency case: suppose the sample freq is 10000,
> 100us IRQ delay may trigger the issue.

Not sure I follow. If the frequency is 10000, then we write 0xffffd8f0 to
the counter. That means we have a 0xffffd8f0 event window to read the
counter after it overflows before new overtakes prev and we get confused.
If this passed in 100us then either your clock speed is 4.3*10^12Hz or you
have a seriously wide issue :)

> So we may use the overflow information to make perf more robust, IMO.

There's a trade off between allowing the counter to wrap back around past
its previous value or being able to handle overflow on a non-interrupt path.
Given that the former problem is only a real issue for non-sampling runs,
halving the period in that case should sort it (and it does stop my simple
test case from exploding).

Will

Re: oprofile and ARM A9 hardware counter

[Ming Lei]

Hi,

On Fri, Feb 17, 2012 at 6:26 PM, Will Deacon <will.deacon@arm.com> wrote:
> On Fri, Feb 17, 2012 at 05:24:02AM +0000, Ming Lei wrote:
>> On Fri, Feb 17, 2012 at 2:08 AM, Will Deacon <will.deacon@arm.com> wrote:
>>
>> >
>> > The more I think about this, the more I think that the overflow parameter to
>> > armpmu_event_update needs to go. It was introduced to prevent massive event
>> > loss in non-sampling mode, but I think we can get around that by changing
>> > the default sample_period to be half of the max_period, therefore giving
>> > ourselves a much better chance of handling the interrupt before new wraps
>> > around past prev.
>> >
>> > Ming Lei - can you try the following please? If it works for you, then I'll
>> > do it properly and kill the overflow parameter altogether.
>>
>> Of course, it does work for the problem reported by Stephane since
>> it changes the delta computation basically as I did, but I am afraid that
>> it may be not good enough for the issue fixed in a737823d ("ARM: 6835/1:
>> perf: ensure overflows aren't missed due to IRQ latency").
>
> I think it does solve that problem.
>
>> >
>> >        if (!hwc->sample_period) {
>> > -               hwc->sample_period  = armpmu->max_period;
>> > +               hwc->sample_period  = armpmu->max_period >> 1;
>>
>> If you assume that the issue addressed by a737823d can only happen in
>> non-sample situation, Peter's idea of u32 cast is OK and maybe simpler.
>
> I don't want to assume that the counters are 32-bit in this code as we may
> want to plug in some other PMU with 16-bit counters, for example. That's why
> we have max_period defined for each PMU. Furthermore, it still doesn't help us
> in the stat case where prev will typically be quite small after we've had an
> overflow and new may well overtake it.

In fact, I suggested to keep the overflow information to handle the
case by reading
hw counter overflow flag, but looks it is a bit frail to sync overflow
flag with the
counter value in non-interrupt situation, so I agree with you to
remove 'overflow'
parameter from armpmu_event_update.

>
>> But I am afraid that the issue still can be triggered in sample-based situation,
>> especially in very high frequency case: suppose the sample freq is 10000,
>> 100us IRQ delay may trigger the issue.
>
> Not sure I follow. If the frequency is 10000, then we write 0xffffd8f0 to
> the counter. That means we have a 0xffffd8f0 event window to read the

The frequency I described is the 'freq' from '-F freq'. On OMAP4, when
the 'freq'
is 10000 and the interval for one samle is 100us, the observed counter
('left' variable in armpmu_event_set_period) is about 90000, so the written
value to the hw counter is 0xFFFEA06F, looks the window is wide enough,
and we may not consider the issue in a737823d for sample-based profiling.

> counter after it overflows before new overtakes prev and we get confused.
> If this passed in 100us then either your clock speed is 4.3*10^12Hz or you
> have a seriously wide issue :)

On OMAP4, I can observe that about 19800 sample events can be generated
with the below command:

 'perf record -e cycles -F 10000  ./noploop 2&& perf report -D | tail -20'

So the above result looks not bad, :-)

>
>> So we may use the overflow information to make perf more robust, IMO.
>
> There's a trade off between allowing the counter to wrap back around past
> its previous value or being able to handle overflow on a non-interrupt path.

I agree, it is not easy to read overflow flag and counter accurately
from hardware
directly on a non-interrupt path.

So do you need me to prepare a new patch, or you will do it by yourself?


thanks,
--
Ming Lei

oprofile and ARM A9 hardware counter

[Ming Lei]

Hi,

On Fri, Feb 17, 2012 at 6:26 PM, Will Deacon <will.deacon@arm.com> wrote:
> On Fri, Feb 17, 2012 at 05:24:02AM +0000, Ming Lei wrote:
>> On Fri, Feb 17, 2012 at 2:08 AM, Will Deacon <will.deacon@arm.com> wrote:
>>
>> >
>> > The more I think about this, the more I think that the overflow parameter to
>> > armpmu_event_update needs to go. It was introduced to prevent massive event
>> > loss in non-sampling mode, but I think we can get around that by changing
>> > the default sample_period to be half of the max_period, therefore giving
>> > ourselves a much better chance of handling the interrupt before new wraps
>> > around past prev.
>> >
>> > Ming Lei - can you try the following please? If it works for you, then I'll
>> > do it properly and kill the overflow parameter altogether.
>>
>> Of course, it does work for the problem reported by Stephane since
>> it changes the delta computation basically as I did, but I am afraid that
>> it may be not good enough for the issue fixed in a737823d ("ARM: 6835/1:
>> perf: ensure overflows aren't missed due to IRQ latency").
>
> I think it does solve that problem.
>
>> >
>> > ? ? ? ?if (!hwc->sample_period) {
>> > - ? ? ? ? ? ? ? hwc->sample_period ?= armpmu->max_period;
>> > + ? ? ? ? ? ? ? hwc->sample_period ?= armpmu->max_period >> 1;
>>
>> If you assume that the issue addressed by a737823d can only happen in
>> non-sample situation, Peter's idea of u32 cast is OK and maybe simpler.
>
> I don't want to assume that the counters are 32-bit in this code as we may
> want to plug in some other PMU with 16-bit counters, for example. That's why
> we have max_period defined for each PMU. Furthermore, it still doesn't help us
> in the stat case where prev will typically be quite small after we've had an
> overflow and new may well overtake it.

In fact, I suggested to keep the overflow information to handle the
case by reading
hw counter overflow flag, but looks it is a bit frail to sync overflow
flag with the
counter value in non-interrupt situation, so I agree with you to
remove 'overflow'
parameter from armpmu_event_update.

>
>> But I am afraid that the issue still can be triggered in sample-based situation,
>> especially in very high frequency case: suppose the sample freq is 10000,
>> 100us IRQ delay may trigger the issue.
>
> Not sure I follow. If the frequency is 10000, then we write 0xffffd8f0 to
> the counter. That means we have a 0xffffd8f0 event window to read the

The frequency I described is the 'freq' from '-F freq'. On OMAP4, when
the 'freq'
is 10000 and the interval for one samle is 100us, the observed counter
('left' variable in armpmu_event_set_period) is about 90000, so the written
value to the hw counter is 0xFFFEA06F, looks the window is wide enough,
and we may not consider the issue in a737823d for sample-based profiling.

> counter after it overflows before new overtakes prev and we get confused.
> If this passed in 100us then either your clock speed is 4.3*10^12Hz or you
> have a seriously wide issue :)

On OMAP4, I can observe that about 19800 sample events can be generated
with the below command:

 'perf record -e cycles -F 10000  ./noploop 2&& perf report -D | tail -20'

So the above result looks not bad, :-)

>
>> So we may use the overflow information to make perf more robust, IMO.
>
> There's a trade off between allowing the counter to wrap back around past
> its previous value or being able to handle overflow on a non-interrupt path.

I agree, it is not easy to read overflow flag and counter accurately
from hardware
directly on a non-interrupt path.

So do you need me to prepare a new patch, or you will do it by yourself?


thanks,
--
Ming Lei

Re: oprofile and ARM A9 hardware counter

[Will Deacon]

On Mon, Feb 20, 2012 at 03:19:02AM +0000, Ming Lei wrote:
> On Fri, Feb 17, 2012 at 6:26 PM, Will Deacon <will.deacon@arm.com> wrote:
> > Not sure I follow. If the frequency is 10000, then we write 0xffffd8f0 to
> > the counter. That means we have a 0xffffd8f0 event window to read the
> 
> The frequency I described is the 'freq' from '-F freq'. On OMAP4, when
> the 'freq'
> is 10000 and the interval for one samle is 100us, the observed counter
> ('left' variable in armpmu_event_set_period) is about 90000, so the written
> value to the hw counter is 0xFFFEA06F, looks the window is wide enough,
> and we may not consider the issue in a737823d for sample-based profiling.

My mistake - I thought you were referring to a period of 10000, but similar
logic follows.

> > There's a trade off between allowing the counter to wrap back around past
> > its previous value or being able to handle overflow on a non-interrupt path.
> 
> I agree, it is not easy to read overflow flag and counter accurately
> from hardware
> directly on a non-interrupt path.
> 
> So do you need me to prepare a new patch, or you will do it by yourself?

If the last one I posted is alright to you (seems that it is), then I'll
update it with the removal of the overflow flag and post it to the list with
you on CC.

I also need to get to the bottom of those warnings.

Thanks,

Will

oprofile and ARM A9 hardware counter

[Will Deacon]

On Mon, Feb 20, 2012 at 03:19:02AM +0000, Ming Lei wrote:
> On Fri, Feb 17, 2012 at 6:26 PM, Will Deacon <will.deacon@arm.com> wrote:
> > Not sure I follow. If the frequency is 10000, then we write 0xffffd8f0 to
> > the counter. That means we have a 0xffffd8f0 event window to read the
> 
> The frequency I described is the 'freq' from '-F freq'. On OMAP4, when
> the 'freq'
> is 10000 and the interval for one samle is 100us, the observed counter
> ('left' variable in armpmu_event_set_period) is about 90000, so the written
> value to the hw counter is 0xFFFEA06F, looks the window is wide enough,
> and we may not consider the issue in a737823d for sample-based profiling.

My mistake - I thought you were referring to a period of 10000, but similar
logic follows.

> > There's a trade off between allowing the counter to wrap back around past
> > its previous value or being able to handle overflow on a non-interrupt path.
> 
> I agree, it is not easy to read overflow flag and counter accurately
> from hardware
> directly on a non-interrupt path.
> 
> So do you need me to prepare a new patch, or you will do it by yourself?

If the last one I posted is alright to you (seems that it is), then I'll
update it with the removal of the overflow flag and post it to the list with
you on CC.

I also need to get to the bottom of those warnings.

Thanks,

Will

oprofile and ARM A9 hardware counter

[Will Deacon]

Stephane,

On Tue, Feb 07, 2012 at 11:59:21AM +0000, stephane eranian wrote:
> An easier way to verify we're getting the right number of samples is
> to use perf top:
> 
> $ taskset -c 1 noploop 1000 &
> $ sudo perf top
> 
> You'll see around 850 irqs/sec, should be closer to 1000.
> But if I drop the rate to 100Hz, then it works:
> 
> $ sudo perf top -F 100
> 
> That leads me to believe there is too much overhead somewhere.
> Could be in perf_event itself.
> 
> Will, do you get 1000 irsq/sec running the same test on your systems?

I finally got around to testing this and yes, the perf top invocation above
yields ~1005 interrupts/second on my board.

However, with -rc3 I get a WARNING in dmesg due to PERF_EF_RELOAD being
set on an event that's not PERF_HES_UPTODATE:


[   52.907666] ------------[ cut here ]------------
[   52.921530] WARNING: at arch/arm/kernel/perf_event.c:251 armpmu_start+0x74/0x80()
[   52.943986] [<c00137e4>] (unwind_backtrace+0x0/0xf8) from [<c001ebd0>] (warn_slowpath_common+0x50/0x60)
[   52.972157] [<c001ebd0>] (warn_slowpath_common+0x50/0x60) from [<c001ec94>] (warn_slowpath_null+0x1c/0x24)
[   53.001105] [<c001ec94>] (warn_slowpath_null+0x1c/0x24) from [<c0015f44>] (armpmu_start+0x74/0x80)
[   53.027975] [<c0015f44>] (armpmu_start+0x74/0x80) from [<c007eb0c>] (perf_adjust_freq_unthr_context+0x140/0x194)
[   53.058487] [<c007eb0c>] (perf_adjust_freq_unthr_context+0x140/0x194) from [<c007ed20>] (perf_event_task_tick+0x1c0/0x290)
[   53.091609] [<c007ed20>] (perf_event_task_tick+0x1c0/0x290) from [<c00446bc>] (scheduler_tick+0xf0/0x12c)
[   53.120308] [<c00446bc>] (scheduler_tick+0xf0/0x12c) from [<c002b3c8>] (update_process_times+0x60/0x6c)
[   53.148475] [<c002b3c8>] (update_process_times+0x60/0x6c) from [<c00586f4>] (tick_sched_timer+0x94/0xd8)
[   53.176913] [<c00586f4>] (tick_sched_timer+0x94/0xd8) from [<c003d220>] (__run_hrtimer.clone.28+0x44/0xf8)
[   53.205869] [<c003d220>] (__run_hrtimer.clone.28+0x44/0xf8) from [<c003ded8>] (hrtimer_interrupt+0xf0/0x274)
[   53.235338] [<c003ded8>] (hrtimer_interrupt+0xf0/0x274) from [<c0012e8c>] (twd_handler+0x34/0x44)
[   53.261954] [<c0012e8c>] (twd_handler+0x34/0x44) from [<c006de54>] (handle_percpu_devid_irq+0x88/0xa0)
[   53.289861] [<c006de54>] (handle_percpu_devid_irq+0x88/0xa0) from [<c006aad8>] (generic_handle_irq+0x20/0x30)
[   53.319601] [<c006aad8>] (generic_handle_irq+0x20/0x30) from [<c000e864>] (handle_IRQ+0x58/0xac)
[   53.345943] [<c000e864>] (handle_IRQ+0x58/0xac) from [<c0008520>] (gic_handle_irq+0x2c/0xac)
[   53.371243] [<c0008520>] (gic_handle_irq+0x2c/0xac) from [<c000dbc0>] (__irq_svc+0x40/0x70)
[   53.396270] Exception stack(0xc04b1f68 to 0xc04b1fb0)
[   53.411405] 1f60:                   00000001 200f0093 c04b1fb0 00000000 c04b0000 c04d2348
[   53.435919] 1f80: c04b2454 c03a5ae8 c04b5db0 410fc091 00000000 00000000 0094e000 c04b1fb0
[   53.460427] 1fa0: c000eac8 c000eacc 600f0013 ffffffff
[   53.475571] [<c000dbc0>] (__irq_svc+0x40/0x70) from [<c000eacc>] (default_idle+0x24/0x28)
[   53.500090] [<c000eacc>] (default_idle+0x24/0x28) from [<c000ec94>] (cpu_idle+0xd4/0x108)
[   53.524611] [<c000ec94>] (cpu_idle+0xd4/0x108) from [<c0487790>] (start_kernel+0x2a4/0x2b0)
[   53.549638] ---[ end trace 1b75b31a2719ed1e ]---


Reverting your throttling fix - e050e3f0 ("perf: Fix broken interrupt rate
throttling") makes the problem disappear.

Will

oprofile and ARM A9 hardware counter

[Shilimkar, Santosh]

On Sat, Feb 18, 2012 at 1:25 AM, David Long <dave.long@linaro.org> wrote:
> Hi Santosh,
>
> Have you determined yet whether or not the l4_wkup change we tested for you
> (and found to improve the 32k timer reliability), is something that should
> be made permanent?
>
The issue is confirmed with synctime idle. I am just waiting on for the
right work around confirmation from hardware team. As soon as
I have that, will post a patch.

Regards
Santosh

oprofile and ARM A9 hardware counter

[Will Deacon]

Hi Santosh,

On Sat, Feb 18, 2012 at 04:31:45AM +0000, Shilimkar, Santosh wrote:
> On Sat, Feb 18, 2012 at 1:25 AM, David Long <dave.long@linaro.org> wrote:
> > Have you determined yet whether or not the l4_wkup change we tested for you
> > (and found to improve the 32k timer reliability), is something that should
> > be made permanent?
> >
> The issue is confirmed with synctime idle. I am just waiting on for the
> right work around confirmation from hardware team. As soon as
> I have that, will post a patch.

Any update on this? I'm keen to collect all the patches required for the
OMAP4 PMU to work as they're currently scattered all over the place. Can I
have your signed-off-by for the patch referred to above as well please?

Thanks,

Will

oprofile and ARM A9 hardware counter

[Shilimkar, Santosh]

On Tue, Apr 3, 2012 at 3:14 PM, Will Deacon <will.deacon@arm.com> wrote:
> Hi Santosh,
>
> On Sat, Feb 18, 2012 at 04:31:45AM +0000, Shilimkar, Santosh wrote:
>> On Sat, Feb 18, 2012 at 1:25 AM, David Long <dave.long@linaro.org> wrote:
>> > Have you determined yet whether or not the l4_wkup change we tested for you
>> > (and found to improve the 32k timer reliability), is something that should
>> > be made permanent?
>> >
>> The issue is confirmed with synctime idle. I am just waiting on for the
>> right work around confirmation from hardware team. As soon as
>> I have that, will post a patch.
>
> Any update on this? I'm keen to collect all the patches required for the
> OMAP4 PMU to work as they're currently scattered all over the place. Can I
> have your signed-off-by for the patch referred to above as well please?
>
This patch is already in Kevin's queue now. [1]

regards
Santosh
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-March/089679.html

oprofile and ARM A9 hardware counter

[David A. Long]

On Tue, 2012-02-07 at 20:30 -0500, David Long wrote:

> Investigating this again I can only see the clock jitter problem on 3.0.
> Even without the HWMOD_INIT_NO_IDLE flag on the 32k_counter entry I
> can't reproduce the problem on the later kernels, although I think our
> 3.3 may be showing a little more variability than the intervening
> versions.

Further testing reveals my observations above are specific to 4430.
4460 exhibits bad jitter on all versions I've tried.  Interestingly my
change to the 32k timer idle modes does not fix the problem on 4460.

I too found Santosh's change greatly improves the jitter problem, but it
still seems worse than 4430.

-dl