All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
Date: Thu, 09 Jan 2014 08:21:46 +0000	[thread overview]
Message-ID: <52CE5C1A.3070603@ti.com> (raw)
In-Reply-To: <79CD15C6BA57404B839C016229A409A83EDB11F5@DBDE04.ent.ti.com>

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

On 2014-01-09 07:06, Hiremath, Vaibhav wrote:

> I am seeing underflow issue on AM43x device if I use omapfb_vram argument.
> Did you see this on OMAP?
> 
> I am using "omapfb_vram=10M@0xA0000000", and I believe it is correct way of usage.

Hmm ok... The AM4x seems to have issues anyway, as we're seeing
underflows easily in other situations also.

Well, there's a small difference in the allocation. The normal dma alloc
uses dma_alloc_attrs() and passes DMA_ATTR_WRITE_COMBINE as a flag,
whereas allocating from the absolute address just uses the piece of
memory. I couldn't find how to set write-combine for the abs memory area.

Then again, that's for CPU caching, so I don't see why it would affect
DSS as such (but that's still something we should measure, cpu
read/write perf for normal and abs allocation).

The only thought I have is that somehow the reserved memory area is
missing some configuration that is done for the rest of the memory. But
that's purely a guess, this is totally out of my area of expertise...

Vaibhav, just to be sure, can you run both with normal dma_alloc and
with the reserve, and verify that the dispc register dumps are the same?
I don't see how they could be different, but just to be sure.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: "Hiremath, Vaibhav" <hvaibhav@ti.com>,
	Ivaylo Dimitrov <freemangordon@abv.bg>
Cc: Tony Lindgren <tony@atomide.com>,
	"linux-fbdev@vger.kernel.org" <linux-fbdev@vger.kernel.org>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
Date: Thu, 9 Jan 2014 10:21:46 +0200	[thread overview]
Message-ID: <52CE5C1A.3070603@ti.com> (raw)
In-Reply-To: <79CD15C6BA57404B839C016229A409A83EDB11F5@DBDE04.ent.ti.com>


[-- Attachment #1.1: Type: text/plain, Size: 1271 bytes --]

On 2014-01-09 07:06, Hiremath, Vaibhav wrote:

> I am seeing underflow issue on AM43x device if I use omapfb_vram argument.
> Did you see this on OMAP?
> 
> I am using "omapfb_vram=10M@0xA0000000", and I believe it is correct way of usage.

Hmm ok... The AM4x seems to have issues anyway, as we're seeing
underflows easily in other situations also.

Well, there's a small difference in the allocation. The normal dma alloc
uses dma_alloc_attrs() and passes DMA_ATTR_WRITE_COMBINE as a flag,
whereas allocating from the absolute address just uses the piece of
memory. I couldn't find how to set write-combine for the abs memory area.

Then again, that's for CPU caching, so I don't see why it would affect
DSS as such (but that's still something we should measure, cpu
read/write perf for normal and abs allocation).

The only thought I have is that somehow the reserved memory area is
missing some configuration that is done for the rest of the memory. But
that's purely a guess, this is totally out of my area of expertise...

Vaibhav, just to be sure, can you run both with normal dma_alloc and
with the reserve, and verify that the dispc register dumps are the same?
I don't see how they could be different, but just to be sure.

 Tomi



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: tomi.valkeinen@ti.com (Tomi Valkeinen)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
Date: Thu, 9 Jan 2014 10:21:46 +0200	[thread overview]
Message-ID: <52CE5C1A.3070603@ti.com> (raw)
In-Reply-To: <79CD15C6BA57404B839C016229A409A83EDB11F5@DBDE04.ent.ti.com>

On 2014-01-09 07:06, Hiremath, Vaibhav wrote:

> I am seeing underflow issue on AM43x device if I use omapfb_vram argument.
> Did you see this on OMAP?
> 
> I am using "omapfb_vram=10M at 0xA0000000", and I believe it is correct way of usage.

Hmm ok... The AM4x seems to have issues anyway, as we're seeing
underflows easily in other situations also.

Well, there's a small difference in the allocation. The normal dma alloc
uses dma_alloc_attrs() and passes DMA_ATTR_WRITE_COMBINE as a flag,
whereas allocating from the absolute address just uses the piece of
memory. I couldn't find how to set write-combine for the abs memory area.

Then again, that's for CPU caching, so I don't see why it would affect
DSS as such (but that's still something we should measure, cpu
read/write perf for normal and abs allocation).

The only thought I have is that somehow the reserved memory area is
missing some configuration that is done for the rest of the memory. But
that's purely a guess, this is totally out of my area of expertise...

Vaibhav, just to be sure, can you run both with normal dma_alloc and
with the reserve, and verify that the dispc register dumps are the same?
I don't see how they could be different, but just to be sure.

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140109/72c0c420/attachment.sig>

  parent reply	other threads:[~2014-01-09  8:21 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-30 13:19 [PATCH 0/2] omapfb: option to use coherent dma mem Tomi Valkeinen
2013-12-30 13:19 ` Tomi Valkeinen
2013-12-30 13:19 ` Tomi Valkeinen
2013-12-30 13:19 ` [PATCH 1/2] ARM: omapfb: add coherent dma memory support Tomi Valkeinen
2013-12-30 13:19   ` Tomi Valkeinen
2013-12-30 13:19   ` Tomi Valkeinen
2014-01-05 14:16   ` Ivaylo Dimitrov
2014-01-05 14:16     ` Ivaylo Dimitrov
2014-01-05 14:16     ` Ivaylo Dimitrov
2014-01-07 23:59   ` Tony Lindgren
2014-01-07 23:59     ` Tony Lindgren
2014-01-07 23:59     ` Tony Lindgren
2014-01-08 14:13     ` Tomi Valkeinen
2014-01-08 14:13       ` Tomi Valkeinen
2014-01-08 14:13       ` Tomi Valkeinen
2014-01-09  5:06       ` Hiremath, Vaibhav
2014-01-09  5:06         ` Hiremath, Vaibhav
2014-01-09  5:06         ` Hiremath, Vaibhav
2014-01-09  7:34         ` Ivaylo Dimitrov
2014-01-09  7:34           ` Ivaylo Dimitrov
2014-01-09  7:34           ` Ivaylo Dimitrov
2014-01-09  8:08           ` Hiremath, Vaibhav
2014-01-09  8:08             ` Hiremath, Vaibhav
2014-01-09  8:08             ` Hiremath, Vaibhav
2014-01-09  8:27             ` Tomi Valkeinen
2014-01-09  8:27               ` Tomi Valkeinen
2014-01-09  8:27               ` Tomi Valkeinen
2014-01-09  8:31               ` Hiremath, Vaibhav
2014-01-09  8:31                 ` Hiremath, Vaibhav
2014-01-09  8:31                 ` Hiremath, Vaibhav
2014-01-11 13:28             ` Ivaylo Dimitrov
2014-01-11 13:28               ` Ivaylo Dimitrov
2014-01-11 13:28               ` Ivaylo Dimitrov
2014-01-22 21:08               ` Ivaylo Dimitrov
2014-01-22 21:08                 ` Ivaylo Dimitrov
2014-01-22 21:08                 ` Ivaylo Dimitrov
2014-01-24  8:47                 ` Hiremath, Vaibhav
2014-01-24  8:47                   ` Hiremath, Vaibhav
2014-01-24  8:47                   ` Hiremath, Vaibhav
2014-01-24 10:35                 ` Tomi Valkeinen
2014-01-24 10:35                   ` Tomi Valkeinen
2014-01-24 10:35                   ` Tomi Valkeinen
2014-01-09  8:21         ` Tomi Valkeinen [this message]
2014-01-09  8:21           ` Tomi Valkeinen
2014-01-09  8:21           ` Tomi Valkeinen
2014-01-09  8:31           ` Hiremath, Vaibhav
2014-01-09  8:31             ` Hiremath, Vaibhav
2014-01-09  8:31             ` Hiremath, Vaibhav
2014-01-09 13:02           ` Hiremath, Vaibhav
2014-01-09 13:02             ` Hiremath, Vaibhav
2014-01-09 13:02             ` Hiremath, Vaibhav
2013-12-30 13:19 ` [PATCH 2/2] omapfb: add support to reserve fb at specified phys address Tomi Valkeinen
2013-12-30 13:19   ` Tomi Valkeinen
2013-12-30 13:19   ` Tomi Valkeinen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52CE5C1A.3070603@ti.com \
    --to=tomi.valkeinen@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.