or higher without impacting the
rest of the system at all when oprofile is not active (and having very low
overhead when oprofile is used), this would solve all the problems.
Best regards,
Siarhei Siamashka
> Thanks
> Hemanth
>
> http://oprofile.sourceforge.net/doc/detailed-paramet
iliar with linux patch submission policy, so might have violated something
unintentionally.
The code is very simple for now. But tweaking it to work better with power
management and frequency scaling may be desired.
Best regards,
Siarhei Siamashka
--
To unsubscribe from this list: send the
Signed-off-by: Siarhei Siamashka
---
arch/arm/Kconfig |6 ++
arch/arm/oprofile/Makefile|1 +
arch/arm/oprofile/common.c|5 ++
arch/arm/oprofile/op_arm_model.h |2 +
arch/arm/oprofile/op_model_omap_gptimer.c | 76
CNT myself, the other counters seemed to be
fine in my tests. But the preliminary report from ARM that I got earlier was
not so optimistic. Maybe I need to get and check an updated official errata
list now.
--
Best regards,
Siarhei Siamashka
--
To unsubscribe from this list: send the line "un
for the
> system timer. I believe 24xx only has GPTIMER1 in the WKUP domain,
> so you might want to use omap_dm_timer_request() if cpu_is_omap24xx().
> Don't know if 2430 has more thant GPTIMER1 in WKUP domain.
IMHO there is little need to use this oprofile driver on OMAP2 chips at a
Signed-off-by: Siarhei Siamashka
---
A second revision of gptimer oprofile patch
http://marc.info/?l=linux-omap&m=123143937515088&w=2
with the fixes suggested by Tony Lindgren
Timers from the CORE domain seem to work best on OMAP3.
Also tested the patch on Nokia 770 (OMAP1710).
Pleas
23 and sound related stuff has problems, but
can be disabled). Maybe some of the more recent kernels are fine too, but I
did not find the exact point where it got broken yet.
Are there any ideas how to bring dspgateway branch into a better shape?
--
Best regards,
Siarhei Siamashka
--
To unsubscribe f
On Thursday 29 January 2009 22:10:06 ext Kevin Hilman wrote:
> Siarhei Siamashka writes:
> > Signed-off-by: Siarhei Siamashka
> > ---
> >
> > A second revision of gptimer oprofile patch
> > http://marc.info/?l=linux-omap&m=123143937515088&w=2
>
causes sound stuttering on video playback.
--
Best regards,
Siarhei Siamashka
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
ase reading from this buffer
will in fact be perfectly cached in L1 cache and memcpy would look fast.
If it is not the case, investigating how to boost memory performance in the
latest kernels is very interesting for sure.
--
Best regards,
Siarhei Siamashka
--
To unsubscribe from this list:
se. That is assuming that the userspace stuff was identical in both
tests.
--
Best regards,
Siarhei Siamashka
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
clean way) something similar to
http://marc.info/?l=oprofile-list&m=123688347009580&w=2
Or is it going to be a different workaround?
--
Best regards,
Siarhei Siamashka
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to
On Monday 29 June 2009 19:58:41 ext Jean Pihet wrote:
> Hi Siarhei Siamashka,
>
> On Monday 29 June 2009 18:36:57 Siarhei Siamashka wrote:
> > On Monday 29 June 2009 17:31:18 ext Jean Pihet wrote:
> > > Hi,
> > >
> > > I am trying to get the latest IRQ re
On Monday 29 June 2009 20:37:57 ext Russell King - ARM Linux wrote:
> On Mon, Jun 29, 2009 at 07:36:57PM +0300, Siarhei Siamashka wrote:
> > On Monday 29 June 2009 17:31:18 ext Jean Pihet wrote:
> > > I am trying to get the latest IRQ registers from a timer or a work
> >
-specific GPTIMER. Is there something more
> > portable in the kernel to provide similar functionality? Or are there any
> > Cortex-A8 r1 cores other than OMAP3 in the wild?
>
> You can use a 'struct timer_list' and the setup_timer, mod_timer,
> del_timer_sync.
And AFAIK beagleboard revision C has ES3.0 silicon. So no luck here. Or can
something still be done?
The whole beagleboard EHCI story starts here:
http://groups.google.com/group/beagleboard/browse_thread/thread/5b8385f0bb1f63da/d46625fe49783a8a
--
Best regards,
Siarhei Siamashka
--
To unsubscribe
CONFIG_WATCHDOG, CONFIG_CBUS and probably some other
stuff.
This all also means that CBUS is critical for correct N8x0 operation and these
devices simply can't work without it at all.
Hope this information helps.
--
Best regards,
Siarhei Siamashka
signature.asc
Description: This is a digitally signed message part.
assembly of section .text:
:
0: ec510b30 vmov r0, r1, d16
4: ec510b30vmovr0, r1, d16
The comment in the existing code is a bit misleading though.
--
Best regards,
Siarhei Siamashka
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
5010&w=2
Samples collection frequency can be adjusted by another patch (the default
128Hz used on most ARM boards/devices is way too low).
oprofile kernel module can be loaded with 'timer=1' parameter to override
the use of buggy Cortex-A8 PMU.
--
Best regards,
Siarhei Siamashka
--
To
luck. But OMAP3 based hardware can have a nice
graphics performance boost. And OMAP3 actually needs it a lot more.
PS. The xf86-video-omapfb-0.1.1 driver does not even use shadow
framebuffer (ouch!). So its users, if any, should see an immediate
speedup.
Siarhei Siamashka (2):
ARM
Needed for remapping pages with write-through cacheable
attribute. May be useful for framebuffers.
Signed-off-by: Siarhei Siamashka
---
arch/arm/include/asm/pgtable.h |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/pgtable.h b/arch/arm/include/asm
rep @ 3.1565 msec ( 317.0/sec): Copy 500x500 from pixmap to window
8000 trep @ 3.1373 msec ( 319.0/sec): Copy 500x500 from window to pixmap
8000 trep @ 3.4631 msec ( 289.0/sec): Copy 500x500 from pixmap to pixmap
Signed-off-by: Siarhei Siamashka
---
Documentation/arm/OMAP/DSS |
On Tue, May 22, 2012 at 10:54 PM, Siarhei Siamashka
wrote:
> And at least for ARM11 and Cortex-A8 processors, the performance of
> write-through cache is really good. Cortex-A9 is another story, because
> all pages marked as Write-Through are supposedly treated as Non-Cacheable:
On Thu, May 24, 2012 at 10:43 AM, Tomi Valkeinen wrote:
> On Tue, 2012-05-22 at 22:54 +0300, Siarhei Siamashka wrote:
> I ran my own fb perf test on omap3 overo board ("perf" test in
> https://gitorious.org/linux-omap-dss2/omapfb-tests) :
>
> vram_cache=n:
>
> se
mode before passing control to the
bootloader and there is simply no way to workaround bugs like this.
The users are screwed.
Having some way to pass a small signed chunk of code through SMC API
could be a life saver if the erratum is particularly nasty. The vendor
could just contribute the signed piece of code with a few instructions
to set the needed bits in the needed registers in the case of
emergency.
--
Best regards,
Siarhei Siamashka
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
25 matches
Mail list logo