t use pci_dma_mapping_error as that is IOMMU
specific (some check for a specific physical address, some
for ranges, some just do a check against zero).
Also update the comments in the header about the true state
of that parameter.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/no
On Fri, Sep 09, 2011 at 08:38:53PM +0900, Inki Dae wrote:
> This patch is a DRM Driver for Samsung SoC Exynos4210 and now enables
> only FIMD yet but we will add HDMI support also in the future.
>
> from now on, I will remove RFC prefix because I think we have got comments
> enough.
>
> this patc
On Thu, Sep 15, 2011 at 06:37:39PM +0900, Inki Dae wrote:
> Hello, Konrad Rzeszutek Wilk.
>
> Your review and comments are so very detail. it was very helpful. thank you
> again.
.. snip ..
> > > + /* FIXME: error check */
> >
> > You might as well d
On Thu, Sep 15, 2011 at 08:21:00PM +0200, Michel D?nzer wrote:
> From: Michel D?nzer
>
> This was only the case if the GPU reset was triggered from the CS ioctl,
> otherwise other processes could happily enter the CS ioctl and wreak havoc
> during the GPU reset.
>
> This is a little complicated
On Fri, Sep 16, 2011 at 10:40:23AM +0200, Michel D?nzer wrote:
> On Fre, 2011-09-16 at 04:31 -0400, Konrad Rzeszutek Wilk wrote:
> > On Thu, Sep 15, 2011 at 08:21:00PM +0200, Michel D?nzer wrote:
> > > From: Michel D?nzer
> > >
> > > This was only the case
On Sat, Sep 17, 2011 at 04:05:58AM +0900, FUJITA Tomonori wrote:
> On Tue, 13 Sep 2011 10:12:47 -0400
> Konrad Rzeszutek Wilk wrote:
>
> > As a mechanism to detect whether SWIOTLB is enabled or not.
> > And as such, we might as well wrap it within an 'swiotlb_enabled
> > > > > + DRM_ERROR("desired size is bigger then real
> size.\n");
> > > >
> > > > So .. you can't continue by just using the real size instead?
> > > >
> > >
> > > I am afraid I don't understand what you mean but I think that condition
> > is
> > > fine. size is a vm area to user-des
So I did a cursory look and stopped at omap_drv.h
due to the lack of time.
Some comments below.
> +++ b/drivers/staging/omapdrm/Kconfig
> @@ -0,0 +1,24 @@
> +
> +config DRM_OMAP
> + tristate "OMAP DRM (EXPERIMENTAL)"
> + depends on DRM && !CONFIG_FB_OMAP2
Since it says EXPERIMENTAL shoul
> >> + ? ? commit(crtc);
> >
> > So no checking of its return value.. Should you at least wrap
> > it with WARN_ON(?)
>
> Is it safe to rely on the "payload" of the WARN_ON() always being
> evaluated, or is there any scenario that you could have something like
Hmm, good question. I assumed so, bu
On Mon, Sep 26, 2011 at 09:55:44AM -0400, Konrad Rzeszutek Wilk wrote:
> > >> + ? ? commit(crtc);
> > >
> > > So no checking of its return value.. Should you at least wrap
> > > it with WARN_ON(?)
> >
> > Is it safe to rely on the "payload&q
t use pci_dma_mapping_error as that is IOMMU
specific (some check for a specific physical address, some
for ranges, some just do a check against zero).
Also update the comments in the header about the true state
of that parameter.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/no
ode).
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/ttm_memory.c |3 ++
drivers/gpu/drm/ttm/ttm_page_alloc.c | 58
include/drm/ttm/ttm_page_alloc.h | 60 ++
3 files changed, 113 insertions(+), 8 deleti
We want to pass in the 'struct device' to the TTM layer so that
the TTM DMA pool code (if enabled) can use it. The DMA API code
needs the 'struct device' to do the DMA API operations.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/nouveau/nouveau_mem.c |3
All the storage devices that use the dmapool set the coherent DMA
mask so they can properly use the dmapool. Since the TTM DMA pool
code is based on that and dma_alloc_coherent checks the
'coherent_dma_mask' and not 'dma_mask' we want to set it.
Signed-off-by: Konrad Rzeszute
. which is pretty much like the other TTM pool except it
also handles moving the page to another pool list.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 96 ++
1 files changed, 96 insertions(+), 0 deletions(-)
diff --git a
. and provide in the function callback a method to register
with the backend a new (*set_caching).
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 46 ++
drivers/gpu/drm/ttm/ttm_tt.c | 46
[.. and this is what I said in v1 post]:
Way back in January this patchset:
http://lists.freedesktop.org/archives/dri-devel/2011-January/006905.html
was merged in, but pieces of it had to be reverted b/c they did not
work properly under PowerPC, ARM, and when swapping out pages to disk.
After a b
; then there are the DMA32 variants which are:
write-combined dma32, uncached dma32, and cached dma32.
Currently this code only gets activated when any variant of the SWIOTLB IOMMU
code is running (Intel without VT-d, AMD without GART, IBM Calgary and Xen PV
with PCI devices).
Tested-by: Michel
The TTM DMA only gets turned on when the SWIOTLB is enabled - but
we might also want to turn it off when SWIOTLB is on to
use the non-DMA TTM pool code.
In the future this parameter can be removed.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c |4
As a mechanism to detect whether SWIOTLB is enabled or not.
We also fix the spelling - it was swioltb instead of
swiotlb.
CC: FUJITA Tomonori
[v1: Ripped out swiotlb_enabled]
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/xen/swiotlb-xen.c |2 +-
include/linux/swiotlb.h |2 +-
lib
On Wed, Sep 28, 2011 at 04:10:02PM +0200, Thomas Hellstrom wrote:
> From: Jakob Bornecrantz
>
> Signed-off-by: Jakob Bornecrantz
> Reviewed-by: Thomas Hellstrom
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c |5 +
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/dr
On Wed, Sep 28, 2011 at 04:10:01PM +0200, Thomas Hellstrom wrote:
> From: Jakob Bornecrantz
>
> Signed-off-by: Jakob Bornecrantz
> Reviewed-by: Thomas Hellstrom
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |5 -
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/driver
On Wed, Sep 28, 2011 at 04:10:06PM +0200, Thomas Hellstrom wrote:
> From: Jakob Bornecrantz
>
> More preparation for Screen Object support.
>
> Signed-off-by: Jakob Bornecrantz
> Signed-off-by: Thomas Hellstrom
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 238 +++
On Wed, Sep 28, 2011 at 04:10:08PM +0200, Thomas Hellstrom wrote:
> From: Jakob Bornecrantz
>
> Signed-off-by: Jakob Bornecrantz
> Signed-off-by: Thomas Hellstrom
> ---
> drivers/gpu/drm/vmwgfx/Makefile |2 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 34 ++-
> drivers/gpu/drm/vmwgfx
On Fri, Sep 30, 2011 at 08:59:52AM +0200, Thomas Hellstrom wrote:
> Konrad,
>
> I'm really sorry for taking so long to review this.
That is OK. We all are busy - and it gave me some time to pretty
up the code even more.
>
> I'd like to go through a couple of high-level things first before
> rev
On Sun, Apr 22, 2012 at 08:05:54PM -0400, Nick Bowler wrote:
> On 2012-04-22 12:40 -0400, Nick Bowler wrote:
> > On 2012-04-21 21:51 -0700, Linus Torvalds wrote:
> > > Nick, I realize you had trouble with a bisection already, but it might
> > > really be worth trying again. Do a
> > >
> > > gi
On Mon, Apr 23, 2012 at 09:03:45PM -0400, Nick Bowler wrote:
> On 2012-04-22 22:45 -0400, Konrad Rzeszutek Wilk wrote:
> > On Sun, Apr 22, 2012 at 08:05:54PM -0400, Nick Bowler wrote:
> > > Following up on the above, the commit which introduces the panics during
>
from incompatible pointer type
> include/drm/ttm/ttm_page_alloc.h:82:13: note: expected 'struct device *' but
> argument is of type 'struct device *'
>
> Signed-off-by: Huacai Chen
> Signed-off-by: Hongliang Tao
> Signed-off-by: Hua Yan
> Cc: dri-devel at lists
On Mon, Aug 13, 2012 at 04:56:33PM +0800, Aaron.Chen ??? wrote:
>
> Since there is no response for the last mail. Maybe it didn't sent
> successfully. So I send it again. Here is the initial patch for siliconmotion
> kernel driver.
What's with the #ifdef 0 or #ifdef 1?
Why is there a bunch of
On Fri, Dec 23, 2011 at 03:22:35PM +0530, Semwal, Sumit wrote:
> Hi Konrad,
>
> On Tue, Dec 20, 2011 at 10:06 PM, Konrad Rzeszutek Wilk
> wrote:
> > On Mon, Dec 19, 2011 at 02:03:30PM +0530, Sumit Semwal wrote:
> >> This is the first step in defining a dma buffer sha
On Tue, Jan 03, 2012 at 05:43:40PM -0500, Jerome Glisse wrote:
> On Fri, Dec 23, 2011 at 01:19:43AM +, James Simmons wrote:
> >
> > > > Hi!
> > > >
> > > > ? ? ? ?I updated the openchrome tree and while testing on the AGP system
> > > > discovered some interesting problems with the new TTM cha
xc0 [nouveau]
RSP
CR2:
---[ end trace b57ad98adec9841d ]---
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/nouveau/nouveau_bo.c |4 ++--
drivers/gpu/drm/ttm/ttm_bo.c |9 +++--
2 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/driv
tm_page_alloc.c does it). This reintroduces
the code that was lost during rebasing.
Reviewed-by: Jerome Glisse
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 15 ++-
1 files changed, 10 insertions(+), 5 deletions(-)
diff --gi
system_call_fastpath
__GI___ioctl
and after this patch all of that disappears.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
b
When I was debugging some DMA API accounting error (which were found to be
with the DMA API debug code), I encountered a couple of issues:
1). Doing "unbind" on the PCI device would crash the kernel _only_ with the
nouveau driver. The readon worked fine. This was due to:
"drm/ttm: callb
On Thu, Jan 05, 2012 at 01:31:55PM -0500, j.glisse at gmail.com wrote:
> From: Jerome Glisse
>
> ttm might call the move notify with null new mem placement,
> properly handle this case inside nouveau move notify callback.
Let me give this a spin tonight on both PCIe and AGP hardware.
Um, were y
On Thu, Jan 05, 2012 at 10:48:10AM +, Dave Airlie wrote:
> Hi
>
> So Linus has released, so really whats in -next is really it
>
> I've two things outstanding,
> the TTM/AGP fixes, from Jerome/Konrad, guys please cross-review asap,
OK, so the two I posted:
drm/ttm/dma: Fix accounting error
On Tue, Jan 03, 2012 at 05:59:33PM -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Jan 03, 2012 at 05:43:40PM -0500, Jerome Glisse wrote:
> > On Fri, Dec 23, 2011 at 01:19:43AM +, James Simmons wrote:
> > >
> > > > > Hi!
> > > > >
> > > &
On Thu, Jan 05, 2012 at 09:14:10PM -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Jan 06, 2012 at 07:53:13AM +1000, Ben Skeggs wrote:
> > On Thu, 2012-01-05 at 13:31 -0500, j.glisse at gmail.com wrote:
> > > From: Jerome Glisse
> > >
> > > ttm might ca
On Fri, Jan 06, 2012 at 11:51:03AM -0500, Jerome Glisse wrote:
> On Fri, Jan 6, 2012 at 9:57 AM, Konrad Rzeszutek Wilk
> wrote:
> > On Thu, Jan 05, 2012 at 09:14:10PM -0500, Konrad Rzeszutek Wilk wrote:
> >> On Fri, Jan 06, 2012 at 07:53:13AM +1000, Ben Skeggs wrote:
> &g
> Still having difficulty to reproduce can you reproduce with the attached
> printk debuging patch and provide the log (only few printk preceding the
> oops or segfault are interesting).
http://darnok.org/vga/move_notify-v212.log
>
> Cheers,
> Jerome
> >From 862e2cc6d35d85404ed24d24c5a5c49c5ef4
On Mon, Jan 09, 2012 at 10:07:02AM +0100, Thomas Hellstrom wrote:
> On 01/06/2012 04:51 PM, James Simmons wrote:
> You can achieve what you want by either adding a new domain so you would
> have
> system, vram, agp, pcidma and object can be bound to one and only one. Or
> you
> >>
On Tue, Jan 10, 2012 at 01:46:05PM +1000, Ben Skeggs wrote:
> On Fri, 2012-01-06 at 16:00 -0500, Jerome Glisse wrote:
> > On Fri, Jan 06, 2012 at 02:52:49PM -0500, Konrad Rzeszutek Wilk wrote:
> > > > Still having difficulty to reproduce can you reproduce with the attached
&g
On Mon, Jan 09, 2012 at 10:37:28AM +0100, Thomas Hellstrom wrote:
> Hi!
>
> When TTM was originally written, it was assumed that GPU apertures
> could address pages directly, and that the CPU could access those
> pages without explicit synchronization. The process of binding a
> page to a GPU tran
00_ib_fini+0x19/0x20 [radeon]
[] evergreen_init+0x1ee/0x2d0 [radeon]
The big WARN() has nothing to do with the culprit - which is that
the firmware was not loaded. So lets remove the WARN() from the TTM DMA code.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/ttm_page_alloc_dm
Please put
[PATCH] ttm/dma: Remove the WARN() which is not useful.
in your 3.3-rc0 branch. It is a minor fix, but quite .. um annoying
and it masks the real issue.
Thanks!
On Fri, Jan 20, 2012 at 10:04:57AM -0800, Robert Morell wrote:
> On Wed, Jan 18, 2012 at 01:10:04AM -0800, Semwal, Sumit wrote:
> > On Wed, Jan 18, 2012 at 5:38 AM, Robert Morell
> > wrote:
> > > EXPORT_SYMBOL_GPL is intended to be used for "an internal implementation
> > > issue, and not really
On Tue, Jan 17, 2012 at 12:57:50AM +0100, Martin Nyhus wrote:
> On Monday 16. January 2012 21:30:59 Jerome Glisse wrote:
> > On Sun, Jan 15, 2012 at 10:31:08PM +0100, Martin Nyhus wrote:
> > > In some cases mem will be null in nouveau_vm_map_sg, resulting in a crash
> > > at drivers/gpu/drm/nouveau
On Tue, Jan 10, 2012 at 01:46:05PM +1000, Ben Skeggs wrote:
> On Fri, 2012-01-06 at 16:00 -0500, Jerome Glisse wrote:
> > On Fri, Jan 06, 2012 at 02:52:49PM -0500, Konrad Rzeszutek Wilk wrote:
> > > > Still having difficulty to reproduce can you reproduce with the attached
&g
On Wed, Apr 06, 2011 at 11:13:59AM +0200, Thomas Hellstrom wrote:
> Dave, Konrad
>
> I think we need to back out this change as soon as possible. I will
> follow up the discussion with Konrad on how we should attempt to
> handle vm passthrough as soon as things settle down a bit over here.
Ok. I
On Fri, Apr 08, 2011 at 04:57:14PM +0200, Thomas Hellstrom wrote:
> Konrad,
>
> Sorry for waiting so long to answer. Workload is quite heavy ATM.
> Please see inline.
OK. Thank you for taking a look... some questions before you
depart on vacation.
> > 1). Get in the patch that passed in 'struct
On Tue, Apr 12, 2011 at 12:02:28AM +0300, Sergey Senozhatsky wrote:
> Hello,
> Aborting (Ctrl-Brake) suspend to disk process (s2disk) brakes drm/radeon.
Can you try to revert 69a07f0b117a40fcc1a479358d8e1f41793617f2 just to see
if that is the culprit.
> Please see the logs below:
>
> [..]
> [ 1
the
> dummy page on their own. So to do Konrad's patch one
> better, just remove the allocation and freeing of the
> dummy page in the r6xx, 7xx, evergreen, and ni code and
> allocate and free in the gart_init/fini() functions for
> all asics.
>
> Cc: Konrad Rzeszutek
We want to pass in the 'struct device' to the TTM layer so that
the TTM DMA pool code (if enabled) can use it. The DMA API code
needs the 'struct device' to do the DMA API operations.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/nouveau/nouveau_mem.c |3
; then there are the DMA32 variants which are:
write-combined dma32, uncached dma32, and cached dma32.
Currently this code only gets activated when any variant of the SWIOTLB IOMMU
code is running (Intel without VT-d, AMD without GART, IBM Calgary and Xen PV
with PCI devices).
Signed-off-by: Ko
Way back in January this patchset:
http://lists.freedesktop.org/archives/dri-devel/2011-January/006905.html
was merged in, but pieces of it had to be reverted b/c they did not
work properly under PowerPC, ARM, and when swapping out pages to disk.
After a bit of discussion on the mailing list
http:
t use pci_dma_mapping_error as that is IOMMU
specific (some check for a specific physical address, some
for ranges, some just do a check against zero).
Also update the comments in the header about the true state
of that parameter.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/no
ode).
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/ttm_memory.c |3 ++
drivers/gpu/drm/ttm/ttm_page_alloc.c | 58
include/drm/ttm/ttm_page_alloc.h | 60 ++
3 files changed, 113 insertions(+), 8 deleti
The TTM DMA only gets turned on when the SWIOTLB is enabled - but
we might also want to turn it off when SWIOTLB is on to
use the non-DMA TTM pool code.
In the future this parameter can be removed.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c |4
As a mechanism to detect whether SWIOTLB is enabled or not.
And as such, we might as well wrap it within an 'swiotlb_enabled()'
function that will call the swiotlb_nr_tlb.
We also fix the spelling - it was swioltb instead of
swiotlb.
CC: FUJITA Tomonori
Signed-off-by: Konrad Rzes
On Thu, Aug 25, 2011 at 05:28:09PM +0200, Michel D?nzer wrote:
> On Mit, 2011-08-24 at 13:16 -0400, Konrad Rzeszutek Wilk wrote:
> >
> > My PowerPC has issues with booting a virgin 3.0 kernel (something about
> > "ELF image not correct") so I don't have
> > + ? ? ? entry->vaddr = dma_alloc_writecombine(dev->dev, entry->size,
> > + ? ? ? ? ? ? ? ? ? ? ? (dma_addr_t *)&entry->paddr, GFP_KERNEL);
> > + ? ? ? if (!entry->paddr) {
> > + ? ? ? ? ? ? ? DRM_ERROR("failed to allocate buffer.\n");
> > + ? ? ? ? ? ? ? return -ENOMEM;
> > + ? ? ? }
> > +
> >
t use pci_dma_mapping_error as that is IOMMU
specific (some check for a specific physical address, some
for ranges, some just do a check against zero).
Also update the comments in the header about the true state
of that parameter.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/no
Since v1: [http://lwn.net/Articles/456246/]
- Ran it through the gauntlet of SubmitChecklist and fixed issues
- Made radeon/nouveau driver set coherent_dma (which is required for dmapool)
[.. and this is what I said in v1 post]:
Way back in January this patchset:
http://lists.freedesktop.org/ar
ode).
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/ttm_memory.c |3 ++
drivers/gpu/drm/ttm/ttm_page_alloc.c | 58
include/drm/ttm/ttm_page_alloc.h | 60 ++
3 files changed, 113 insertions(+), 8 deleti
We want to pass in the 'struct device' to the TTM layer so that
the TTM DMA pool code (if enabled) can use it. The DMA API code
needs the 'struct device' to do the DMA API operations.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/nouveau/nouveau_mem.c |3
As a mechanism to detect whether SWIOTLB is enabled or not.
And as such, we might as well wrap it within an 'swiotlb_enabled()'
function that will call the swiotlb_nr_tlb.
We also fix the spelling - it was swioltb instead of
swiotlb.
CC: FUJITA Tomonori
Signed-off-by: Konrad Rzes
The TTM DMA only gets turned on when the SWIOTLB is enabled - but
we might also want to turn it off when SWIOTLB is on to
use the non-DMA TTM pool code.
In the future this parameter can be removed.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c |4
; then there are the DMA32 variants which are:
write-combined dma32, uncached dma32, and cached dma32.
Currently this code only gets activated when any variant of the SWIOTLB IOMMU
code is running (Intel without VT-d, AMD without GART, IBM Calgary and Xen PV
with PCI devices).
Signed-off-by:
All the storage devices that use the dmapool set the coherent DMA
mask so they can properly use the dmapool. Since the TTM DMA pool
code is based on that and dma_alloc_coherent checks the
'coherent_dma_mask' and not 'dma_mask' we want to set it.
Signed-off-by: Konrad Rzeszute
On Wed, Aug 31, 2011 at 09:33:29AM +0300, Pekka Paalanen wrote:
> On Tue, 30 Aug 2011 22:41:46 -0400
> Konrad Rzeszutek Wilk wrote:
>
> > . instead of checking against the DMA_ERROR_CODE value which is
> > per-platform specific. The zero value is a known invalid value
> &
igned-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/nouveau/nouveau_mem.c |5 +
drivers/gpu/drm/radeon/radeon_device.c |1 +
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_mem.c
b/drivers/gpu/drm/nouveau/nouveau_mem.c
index 36bec48..
On Fri, Nov 18, 2011 at 08:08:36PM -0500, Jerome Glisse wrote:
> On Fri, Nov 18, 2011 at 08:04:47PM -0500, j.glisse at gmail.com wrote:
> > Important fix to patch 14, fix accounting of ghost bo. When creating a
> > ghost bo we don't account it, so set its acc_size to 0 so that when
> > ghost is rel
On Fri, Dec 02, 2011 at 02:27:31PM +0530, Sumit Semwal wrote:
> This is the first step in defining a dma buffer sharing mechanism.
>
> A new buffer object dma_buf is added, with operations and API to allow easy
> sharing of this buffer object across devices.
>
> The framework allows:
> - differen
> >From what I can see, you get the following callchain:
>
> start_kernel
> |-> setup_arch
> |-> x86_init.oem.arch_setup = xen_arch_setup
>
> |-> check_bugs
> |-> identify_boot_cpu
> |-> identify_cpu
> |-> select_idle_routine
>
>
> so xen_arch_set
On Thu, Dec 08, 2011 at 10:34:00AM -0500, Jerome Glisse wrote:
> On Thu, Dec 08, 2011 at 09:50:54AM +0300, Dan Carpenter wrote:
> > The "if (!p && !p->dev)" condition isn't right because || was intended
> > instead of &&. But actually, "p" is the list cursor and so it's always
Duh!
> > non-NULL a
On Fri, Dec 09, 2011 at 09:25:43PM -0500, Jerome Glisse wrote:
> Hi Konrad i stumble on this after a long period of test :
>
> Dec 9 12:00:37 homer kernel: [ cut here ]
> Dec 9 12:00:37 homer kernel: WARNING: at lib/dma-debug.c:894
> check_unmap+0x262/0x7e0()
> Dec 9 12:
> > Any ideas ?
>
> The only way to do that would be to modify the 'struct dma_page' vaddr and dma
> variables from what they had in __ttm_dma_alloc_page. But I am not seeing any
> willfull modifications. We do pass in to dma_free_coherent the _same_ values!
>
>
> Hm, it might be worth adding in
Jerome pointed me to some accounting error in the DMA API debugging code and
while I can't figure it out yet, I did notice some extreme slowness - which
is due to the nouveau driver calling the unpopulate (now that unbind +
unpopulate are squashed) quite a lot (this is using Gnome Shell - I think G
sys_ioctl
system_call_fastpath
__GI___ioctl
and after this patch all of that disappears.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a
rebasing.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
index e57aa24..156ddcd 100644
--- a/drivers
using a different value for the amount of pages to shrink.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
b/drivers/gpu/drm/ttm/ttm
Hey,
When I use the drm-next tree without the patch it works fine.
(albeit slowly - but I posted the patches for that).
With the patch mentioned I get this:
00:0d.0 VGA compatible controller: nVidia Corporation C61 [GeForce 6150SE
nForce 430] (rev a2)
sh-4.1# cd :00:0d.0
sh-4.1# cd driver
On Mon, Dec 12, 2011 at 12:37:43PM -0500, Konrad Rzeszutek Wilk wrote:
> > > Any ideas ?
> >
> > The only way to do that would be to modify the 'struct dma_page' vaddr and
> > dma
> > variables from what they had in __ttm_dma_alloc_page. But I am not
On Tue, Dec 13, 2011 at 05:23:30PM +0100, Thomas Hellstrom wrote:
> On 12/13/2011 05:07 PM, Jerome Glisse wrote:
> >On Mon, Dec 12, 2011 at 03:09:26PM -0500, Konrad Rzeszutek Wilk wrote:
> >>Jerome pointed me to some accounting error in the DMA API debugging code and
> >
On Mon, Dec 19, 2011 at 02:03:30PM +0530, Sumit Semwal wrote:
> This is the first step in defining a dma buffer sharing mechanism.
>
> A new buffer object dma_buf is added, with operations and API to allow easy
> sharing of this buffer object across devices.
>
> The framework allows:
> - differen
On Mon, Dec 19, 2011 at 08:51:15PM +0100, Thomas Hellstrom wrote:
> On 12/13/2011 05:40 PM, Konrad Rzeszutek Wilk wrote:
> >On Tue, Dec 13, 2011 at 05:23:30PM +0100, Thomas Hellstrom wrote:
> >>On 12/13/2011 05:07 PM, Jerome Glisse wrote:
> >>>On Mon, Dec 12, 20
On Wed, Dec 21, 2011 at 10:17:36AM -0500, Jerome Glisse wrote:
> On Mon, Dec 12, 2011 at 3:09 PM, Konrad Rzeszutek Wilk
> wrote:
> > The code to figure out how many pages to shrink the pool
> > ends up capping the 'count' at _manager->options.max_size - which is OK.
On Mon, Mar 21, 2011 at 02:11:07PM +0100, Michel D?nzer wrote:
> On Fre, 2011-01-07 at 12:11 -0500, Konrad Rzeszutek Wilk wrote:
> >
> > 1) The 'NULL' when doing dma_alloc_coherent is unsightly. I was toying
> > with modifying the TTM API to pass in 'struct de
On Tue, Mar 08, 2011 at 09:52:54PM +0100, Thomas Hellstrom wrote:
> Hi, Konrad,
>
> Is passing a struct device to the DMA api really *strictly* necessary?
Soo.. it seems it is on PowerPC, which I sadly didn't check for, does require
this.
>
> I'd like to avoid that at all cost, since we don't wa
On Tue, Mar 22, 2011 at 02:13:19PM +0100, Michel D?nzer wrote:
> On Mon, 2011-03-21 at 19:18 -0400, Konrad Rzeszutek Wilk wrote:
> > On Mon, Mar 21, 2011 at 02:11:07PM +0100, Michel D?nzer wrote:
> > > On Fre, 2011-01-07 at 12:11 -0500, Konrad Rzeszutek Wilk wrote:
> > &
> >I was thinking about this a bit after I found that the PowerPC requires
> >the 'struct dev'. But I got a question first, what do you with pages
> >that were allocated to a device that can do 64-bit DMA and then
> >move it to a device than can 32-bit DMA? Obviously the 32-bit card would
> >set th
On Wed, Mar 23, 2011 at 02:17:18PM +0100, Thomas Hellstrom wrote:
> On 03/23/2011 01:51 PM, Konrad Rzeszutek Wilk wrote:
> >>>I was thinking about this a bit after I found that the PowerPC requires
> >>>the 'struct dev'. But I got a question first, what do yo
On Thu, Mar 24, 2011 at 08:52:20AM +0100, Thomas Hellstrom wrote:
> On 03/23/2011 03:52 PM, Konrad Rzeszutek Wilk wrote:
> >On Wed, Mar 23, 2011 at 02:17:18PM +0100, Thomas Hellstrom wrote:
> >>On 03/23/2011 01:51 PM, Konrad Rzeszutek Wilk wrote:
> >>>>>I w
> > When a page in the TTM pool is being moved back and forth and also changes
> > the caching model, what happens on the free part? Is the original caching
> > state put back on it? Say I allocated a DMA32 page (GFP_DMA32), and move it
> > to another pool for another radeon device. I also do some
> >I can start this next week if you guys are comfortable with this idea.
> >
> >
>
> Konrad,
>
> 1) A couple of questions first. Where are the memory pools going to
> end up in this design. Could you draft an API? How is page
> accounting going to be taken care of? How do we differentiate
> betw
ost of this anyways properly.
Yes, just need to find the time :-)
>
> Signed-off-by: Dave Airlie
> Cc: Konrad Rzeszutek Wilk
Acked-by: Konrad Rzeszutek Wilk
Thanks for sending this patch out!
> ---
> drivers/gpu/drm/nouveau/nouveau_sgdma.c |3 ++-
> drivers/gpu
> > +static struct dma_page *__ttm_dma_alloc_page(struct dma_pool *pool)
> > +{
> > + struct dma_page *d_page;
> > +
> > + d_page = kmalloc(sizeof(struct dma_page), GFP_KERNEL);
> > + if (!d_page)
> > + return NULL;
> > +
> > + d_page->vaddr = dma_alloc_coherent(pool->dev, pool->s
On Tue, Nov 01, 2011 at 09:11:37PM -0400, Jerome Glisse wrote:
> Hi,
>
> So attached is patch serie (sorry for that i am away of my normal mail
> config) which ultimately merge ttm_backend & ttm_tt it allows to get
> rid of data duplication btw the two, especialy btw ttm_tt and driver
> specific b
On Tue, Nov 01, 2011 at 11:05:49PM -0400, Jerome Glisse wrote:
> On Tue, Nov 1, 2011 at 9:29 PM, Konrad Rzeszutek Wilk
> wrote:
> > On Tue, Nov 01, 2011 at 09:11:37PM -0400, Jerome Glisse wrote:
> >> Hi,
> >>
> >> So attached is patch serie (sorry for that
301 - 400 of 505 matches
Mail list logo
