Hi Kevin,
On Mon, May 7, 2012 at 7:31 PM, Kevin Hilman khil...@ti.com wrote:
Jean Pihet jean.pi...@newoldbits.com writes:
On Tue, May 1, 2012 at 7:27 PM, Kevin Hilman khil...@ti.com wrote:
Jean Pihet jean.pi...@newoldbits.com writes:
HI Kevin, Grazvydas,
On Tue, Apr 24, 2012 at 4:29 PM,
Jean Pihet jean.pi...@newoldbits.com writes:
On Tue, May 1, 2012 at 7:27 PM, Kevin Hilman khil...@ti.com wrote:
Jean Pihet jean.pi...@newoldbits.com writes:
HI Kevin, Grazvydas,
On Tue, Apr 24, 2012 at 4:29 PM, Kevin Hilman khil...@ti.com wrote:
Jean Pihet jean.pi...@newoldbits.com writes:
On Tue, May 1, 2012 at 7:27 PM, Kevin Hilman khil...@ti.com wrote:
Jean Pihet jean.pi...@newoldbits.com writes:
HI Kevin, Grazvydas,
On Tue, Apr 24, 2012 at 4:29 PM, Kevin Hilman khil...@ti.com wrote:
Jean Pihet jean.pi...@newoldbits.com writes:
Hi Grazvydas, Kevin,
I did some gather
HI Kevin, Grazvydas,
On Tue, Apr 24, 2012 at 4:29 PM, Kevin Hilman khil...@ti.com wrote:
Jean Pihet jean.pi...@newoldbits.com writes:
Hi Grazvydas, Kevin,
I did some gather some performance measurements and statistics using
custom tracepoints in __omap3_enter_idle.
I posted the patches for
Jean Pihet jean.pi...@newoldbits.com writes:
HI Kevin, Grazvydas,
On Tue, Apr 24, 2012 at 4:29 PM, Kevin Hilman khil...@ti.com wrote:
Jean Pihet jean.pi...@newoldbits.com writes:
Hi Grazvydas, Kevin,
I did some gather some performance measurements and statistics using
custom tracepoints
On Tue, 1 May 2012, Kevin Hilman wrote:
PER is the one that seems to be causing the most latency.
Can you try do your measurements using hack below which makes sure that
PER isn't any deeper than CORE?
It might be the relock time for DPLL4, the PER DPLL. You might also
try disabling
Hi Grazvydas, Kevin,
I did some gather some performance measurements and statistics using
custom tracepoints in __omap3_enter_idle.
All the details are at
http://www.omappedia.org/wiki/Power_Management_Device_Latencies_Measurement#C1_performance_problem:_analysis
.
The setup is:
- Beagleboard
+ Tero
On Tuesday 24 April 2012 03:20 PM, Jean Pihet wrote:
Hi Grazvydas, Kevin,
I did some gather some performance measurements and statistics using
custom tracepoints in __omap3_enter_idle.
All the details are at
On Tue, 2012-04-24 at 16:08 +0530, Santosh Shilimkar wrote:
+ Tero
On Tuesday 24 April 2012 03:20 PM, Jean Pihet wrote:
Hi Grazvydas, Kevin,
I did some gather some performance measurements and statistics using
custom tracepoints in __omap3_enter_idle.
All the details are at
Hi Tero,
On Tue, Apr 24, 2012 at 2:21 PM, Tero Kristo t-kri...@ti.com wrote:
On Tue, 2012-04-24 at 16:08 +0530, Santosh Shilimkar wrote:
+ Tero
On Tuesday 24 April 2012 03:20 PM, Jean Pihet wrote:
Hi Grazvydas, Kevin,
I did some gather some performance measurements and statistics using
On Tue, 2012-04-24 at 14:50 +0200, Jean Pihet wrote:
Hi Tero,
On Tue, Apr 24, 2012 at 2:21 PM, Tero Kristo t-kri...@ti.com wrote:
On Tue, 2012-04-24 at 16:08 +0530, Santosh Shilimkar wrote:
+ Tero
On Tuesday 24 April 2012 03:20 PM, Jean Pihet wrote:
Hi Grazvydas, Kevin,
I did
Jean Pihet jean.pi...@newoldbits.com writes:
Hi Grazvydas, Kevin,
I did some gather some performance measurements and statistics using
custom tracepoints in __omap3_enter_idle.
All the details are at
Grazvydas Ignotas nota...@gmail.com writes:
On Thu, Apr 12, 2012 at 3:19 AM, Kevin Hilman khil...@ti.com wrote:
It would be helpful now to narrow down what are the big contributors to
the overhead in omap_sram_idle(). Most of the code there is skipped for
C1 because the next states for MPU
On Tue, Apr 17, 2012 at 5:30 PM, Kevin Hilman khil...@ti.com wrote:
Grazvydas Ignotas nota...@gmail.com writes:
Ok I did some tests, all in mostly idle system with just init, busybox
shell and dd doing a NAND read to /dev/null .
Hmm, I seem to get a hang using dd to read from NAND /dev/mtdX
Hi,
On Thu, Apr 12, 2012 at 09:57:32AM -0700, Kevin Hilman wrote:
+Felipe for EHCI question
Gary Thomas g...@mlbassoc.com writes:
[...]
This worked a treat, thanks. My network performance is better
now, but still not what it was. The same TFTP transfer now takes
71 seconds, so
On Thu, Apr 12, 2012 at 3:19 AM, Kevin Hilman khil...@ti.com wrote:
Grazvydas Ignotas nota...@gmail.com writes:
On Mon, Apr 9, 2012 at 10:03 PM, Kevin Hilman khil...@ti.com wrote:
Grazvydas Ignotas nota...@gmail.com writes:
While SD card performance loss is not that bad (~7%), NAND one is
On Thu, Apr 12, 2012 at 3:19 AM, Kevin Hilman khil...@ti.com wrote:
It would be helpful now to narrow down what are the big contributors to
the overhead in omap_sram_idle(). Most of the code there is skipped for
C1 because the next states for MPU and CORE are both ON.
Ok I did some tests, all
On 2012-04-11 13:17, Kevin Hilman wrote:
Gary Thomasg...@mlbassoc.com writes:
[...]
I fear I'm seeing similar problems with 3.3. I have my board (similar
to the BeagleBoard) ported to 3.0 and 3.3. I'm seeing terrible network
performance on 3.3. For example, if I use TFTP to download a
Gary Thomas g...@mlbassoc.com writes:
On 2012-04-11 13:17, Kevin Hilman wrote:
Gary Thomasg...@mlbassoc.com writes:
[...]
I fear I'm seeing similar problems with 3.3. I have my board (similar
to the BeagleBoard) ported to 3.0 and 3.3. I'm seeing terrible network
performance on 3.3.
On 2012-04-12 08:14, Kevin Hilman wrote:
Gary Thomasg...@mlbassoc.com writes:
On 2012-04-11 13:17, Kevin Hilman wrote:
Gary Thomasg...@mlbassoc.com writes:
[...]
I fear I'm seeing similar problems with 3.3. I have my board (similar
to the BeagleBoard) ported to 3.0 and 3.3. I'm seeing
+Felipe for EHCI question
Gary Thomas g...@mlbassoc.com writes:
[...]
This worked a treat, thanks. My network performance is better
now, but still not what it was. The same TFTP transfer now takes
71 seconds, so about 50% slower than on the 3.0 kernel. Applying the
second [unnamed] patch
On 2012-04-12 10:57, Kevin Hilman wrote:
+Felipe for EHCI question
Gary Thomasg...@mlbassoc.com writes:
[...]
This worked a treat, thanks. My network performance is better
now, but still not what it was. The same TFTP transfer now takes
71 seconds, so about 50% slower than on the 3.0
Gary Thomas g...@mlbassoc.com writes:
On 2012-04-12 10:57, Kevin Hilman wrote:
+Felipe for EHCI question
Gary Thomasg...@mlbassoc.com writes:
[...]
This worked a treat, thanks. My network performance is better
now, but still not what it was. The same TFTP transfer now takes
71
On 2012-04-12 12:08, Kevin Hilman wrote:
Gary Thomasg...@mlbassoc.com writes:
On 2012-04-12 10:57, Kevin Hilman wrote:
+Felipe for EHCI question
Gary Thomasg...@mlbassoc.com writes:
[...]
This worked a treat, thanks. My network performance is better
now, but still not what it was.
Gary Thomas g...@mlbassoc.com writes:
On 2012-04-12 12:08, Kevin Hilman wrote:
Gary Thomasg...@mlbassoc.com writes:
On 2012-04-12 10:57, Kevin Hilman wrote:
+Felipe for EHCI question
Gary Thomasg...@mlbassoc.com writes:
[...]
This worked a treat, thanks. My network performance is
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Grazvydas Ignotas
Sent: Tuesday, April 10, 2012 7:30 PM
What I think is going on here is that omap_sram_idle() is taking too
much time because it's overhead is too large. I've added a counter
On 2012-04-12 16:03, Kevin Hilman wrote:
Gary Thomasg...@mlbassoc.com writes:
On 2012-04-12 12:08, Kevin Hilman wrote:
Gary Thomasg...@mlbassoc.com writes:
On 2012-04-12 10:57, Kevin Hilman wrote:
+Felipe for EHCI question
Gary Thomasg...@mlbassoc.comwrites:
[...]
This worked a
On 2012-04-06 16:50, Grazvydas Ignotas wrote:
Hello,
I'm DMA seeing performance loss related to CONFIG_PM on OMAP3.
# CONFIG_PM is set:
echo 3 /proc/sys/vm/drop_caches
# file copy from NAND (using NAND driver in DMA mode)
dd if=/mnt/tmp/a of=/dev/null bs=1M count=32
33554432 bytes (32.0MB)
On Wed, Apr 11, 2012 at 5:59 PM, Gary Thomas g...@mlbassoc.com wrote:
I'd like to try building without CONFIG_PM, but when I disabled this, my
kernel fails to come up. Can someone point me to the magic to build without
CONFIG_PM, or possibly send me a working config file?
You probably need
On 2012-04-11 11:23, Grazvydas Ignotas wrote:
On Wed, Apr 11, 2012 at 5:59 PM, Gary Thomasg...@mlbassoc.com wrote:
I'd like to try building without CONFIG_PM, but when I disabled this, my
kernel fails to come up. Can someone point me to the magic to build without
CONFIG_PM, or possibly send
Gary Thomas g...@mlbassoc.com writes:
[...]
I fear I'm seeing similar problems with 3.3. I have my board (similar
to the BeagleBoard) ported to 3.0 and 3.3. I'm seeing terrible network
performance on 3.3. For example, if I use TFTP to download a large file
(~35MB), I get this:
3.0:
Grazvydas Ignotas nota...@gmail.com writes:
On Mon, Apr 9, 2012 at 10:03 PM, Kevin Hilman khil...@ti.com wrote:
Grazvydas Ignotas nota...@gmail.com writes:
While SD card performance loss is not that bad (~7%), NAND one is
worrying (~39%). I've tried disabling/enabling CONFIG_CPU_IDLE, also
On Mon, Apr 9, 2012 at 10:03 PM, Kevin Hilman khil...@ti.com wrote:
Grazvydas Ignotas nota...@gmail.com writes:
While SD card performance loss is not that bad (~7%), NAND one is
worrying (~39%). I've tried disabling/enabling CONFIG_CPU_IDLE, also
cpuidle states over sysfs, it did not have any
Grazvydas Ignotas nota...@gmail.com writes:
Hello,
I'm DMA seeing performance loss related to CONFIG_PM on OMAP3.
# CONFIG_PM is set:
echo 3 /proc/sys/vm/drop_caches
# file copy from NAND (using NAND driver in DMA mode)
dd if=/mnt/tmp/a of=/dev/null bs=1M count=32
33554432 bytes
34 matches
Mail list logo
