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
> > I don't know why it was done that way, but I wrote the TTM DMA code
> > to be optimized for that (and it has the code to reverse direction - b/c
> > the testcases I used initially had the a,b,c,d,e,f order when doing
> > get_pages
> > and put_pages) - but I can alter the code to do it in the f
On Wed, Nov 02, 2011 at 07:37:51PM -0400, j.glisse at gmail.com wrote:
> From: Jerome Glisse
>
> On failure we need to make sure the page we free has wb cache
> attribute. Do this pas call the proper ttm page helper function.
>
> Signed-off-by: Jerome Glisse
Reviewed-by...
> ---
> drivers/gpu
On Wed, Nov 02, 2011 at 07:37:52PM -0400, j.glisse at gmail.com wrote:
> From: Jerome Glisse
>
> Use the ttm_tt page ptr array for page allocation, move the list to
> array unwinding into the page allocation functions.
>
> V2 split the fix to use ttm put page as a separate fix
> properly fill pa
On Wed, Nov 02, 2011 at 07:37:53PM -0400, j.glisse at gmail.com wrote:
> From: Jerome Glisse
>
> Signed-off-by: Jerome Glisse
Reviewed-by-me.
> ---
> drivers/gpu/drm/ttm/ttm_tt.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/driv
On Sun, Nov 06, 2011 at 04:03:21PM +0100, Tormod Volden wrote:
> From: Tormod Volden
>
> Some cards report that they support only 4x, in which case they
> should support 2x and 1x as well, according to the AGP spec.
Have you tested it on other hardware besides your KN133?
>
> Otherwise a reque
them.
Reviewed-by: Konrad Rzeszutek Wilk
>
> Signed-off-by: Jerome Glisse
> ---
> drivers/gpu/drm/nouveau/nouveau_bo.c| 14 ++-
> drivers/gpu/drm/nouveau/nouveau_drv.h |5 +-
> drivers/gpu/drm/nouveau/nouveau_sgdma.c | 188 --
> driver
pulate an object this simplify some of code designed around
> the page fault design.
Reviewed-by: Konrad Rzeszutek Wilk
>
> Signed-off-by: Jerome Glisse
> ---
> drivers/gpu/drm/nouveau/nouveau_bo.c |3 +
> drivers/gpu/drm/radeon/radeon_ttm.c|2 +
> dri
On Thu, Nov 03, 2011 at 07:39:04PM -0400, j.glisse at gmail.com wrote:
> Hi,
>
> So updated patchset, only patch 5 seen change since last set.
> Last 3 patch are from your patchset, modified on top of mine.
Yup, and I've tested it on my radeon box. Going to test it
on the nvidia and some of the 3
; >ttm page allocation helper to actualy take an array instead
> >of relying on list this could drasticly reduce the number of
> >function call in the common case of allocation whole buffer.
> >
> >Signed-off-by: Jerome Glisse
> >Reviewed-by: Konrad Rzeszutek Wilk
>
On Mon, Nov 07, 2011 at 06:40:20PM -0500, j.glisse at gmail.com wrote:
> Ok so here is full patchset, including nouveau support, Ben if you
> could review (if change to nouveau in patch 7 are correct then others
> change to nouveau are more than likely 100% correct :)).
You are missing one patch (
On Fri, Nov 11, 2011 at 05:47:48PM -0500, j.glisse at gmail.com wrote:
> From: Jerome Glisse
>
> Move dma data to a superset ttm_dma_tt structure which herit
inherit
> from ttm_tt. This allow driver that don't use dma functionalities
> to not have to waste memory for it.
>
> V2 Rebase on top o
On Mon, Nov 14, 2011 at 01:54:27PM -0500, Jerome Glisse wrote:
> On Mon, Nov 14, 2011 at 05:06:42PM +0100, Thomas Hellstrom wrote:
> > On 11/14/2011 05:02 PM, Jerome Glisse wrote:
> > >On Mon, Nov 14, 2011 at 9:49 AM, Thomas Hellstrom > >vmware.com> wrote:
> > >>On 11/11/2011 11:47 PM, j.glisse at
> +#ifdef CONFIG_SWIOTLB
> + if (swiotlb_nr_tbl()) {
> + return ttm_dma_populate(ttm, rdev->dev);
> + }
> +#endif
..
> +#ifdef CONFIG_SWIOTLB
> + if (swiotlb_nr_tbl()) {
> + ttm_dma_unpopulate(ttm, rdev->dev);
> + return;
> + }
> +#endif
> +#ifde
> +int ttm_dma_populate(struct ttm_tt *ttm, struct device *dev)
> +{
.. snip..
> + for (i = 0; i < ttm->num_pages; ++i) {
> + ret = ttm_dma_pool_get_pages(pool, ttm, i);
> + if (ret != 0) {
> + ttm_dma_unpopulate(ttm, dev);
> + re
> > which I think was your V4 posting (or earlier) (the last patch is something
> > I added
> > to toggle it off/on to test).
>
> You have to allocate like a million of gem object to trigger it.
>
Which I certainly did not, but I did find an accounting error in the
rebased v5 version of the TTM
> >> -int ttm_dma_populate(struct ttm_tt *ttm, struct device *dev);
> >> -extern void ttm_dma_unpopulate(struct ttm_tt *ttm, struct device *dev);
> >> +int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct device *dev);
> >> +extern void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma, struct devic
gt; V2 Rebase on top of no memory account changes (where/when is my
>delorean when i need it ?)
> V3 Make sure page list is initialized empty
> V4 typo/syntax fixes
>
> Signed-off-by: Jerome Glisse
> Reviewed-by: Thomas Hellstrom
Reviewed-by: Konrad Rzeszutek Wilk
> ---
>
On Wed, Nov 16, 2011 at 11:57:31AM -0500, j.glisse at gmail.com wrote:
> From: Jerome Glisse
>
> Use the ttm_tt pages array for pages allocations, move the list
> unwinding into the page allocation functions.
>
> Signed-off-by: Jerome Glisse
Reviewed-by: Kon
On Wed, Nov 16, 2011 at 11:57:24AM -0500, j.glisse at gmail.com wrote:
> Respin some of the patch with syntax/typo fix + patch 10 with proper
> memory accounting of page being free.
Ran it yesterday all day and as well today using the TTM DMA (so SWIOTLB is on)
and had no trouble. This is with a R
> Subject: Regression in 3.1 causes Xen to use wrong idle routine
> Submitter : Stefan Bader
> Date : 2011-10-26 10:24
> Message-ID : 4EA7DFD1.9060608 at canonical.com
> References : http://marc.info/?l=linux-acpi&m=131962467924564&w=2
The patch mentioned in http://mid.gmane.org/20
On Sun, Jun 27, 2010 at 12:58:07AM -0400, Matt Turner wrote:
> On Sun, Jun 27, 2010 at 12:20 AM, FUJITA Tomonori
> wrote:
> > On Thu, 24 Jun 2010 10:53:52 -0400
> > Matt Turner wrote:
> >
> >> > Seems that the IOMMU can't find 128 pages. It's likely due to:
> >> >
> >> > - out of the IOMMU space
onfig
(ecb4aed78dcf09e48c8c34c8c2fa7f5c69344be6) but this one is lacking.
Acked-by: Konrad Rzeszutek Wilk
- Forwarded message from Bruce Edge -
Date: Sun, 7 Nov 2010 17:56:38 -0800
From: Bruce Edge
To: xen-devel at lists.xensource.com,
Konrad Rzeszutek Wilk
Subject: PATCH: pvops 2.6.36 patc
On Mon, Nov 08, 2010 at 10:51:10AM -0500, Konrad Rzeszutek Wilk wrote:
> Hey guys,
>
> This failure also occurs on v2.6.37-rc1 (the branch Bruce is
> referring has been merged in Linus's tree). This compile
> failure can be demonstrated if one does not
> select VIDEO_OUT
> Code looks good but GART stuff can be picky, i will try to do a full
> scale testing in next couple week.
ping?
x27;t see this anymore.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/radeon/radeon_gart.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
b/drivers/gpu/drm/radeon/radeon_gart.c
index 6501611..dc04c7b 100644
--- a/driver
I found this when I was doing a bit of testing of my TTM patches. The issue is
that during unload/unbind:
echo :01:05.0 > /sys/bus/pci/drivers/radeon/unbind
the radeon driver would unload, but if compiled with the CONFIG_DMA_API_DEBUG=y
it would throw out this warning:
[ 22.113420] drm: un
On Thu, Feb 24, 2011 at 03:25:43AM -0500, Alex Deucher wrote:
> On Wed, Feb 23, 2011 at 3:48 PM, Konrad Rzeszutek Wilk
> wrote:
> > git commit 82568565683b4991964a5fc89a9ca0c7122818e8 adds a dummy page
> > so that if something goes wrong it will at least fetch/write data
> > The errors
> >
> > [3.778476] [drm:r100_ring_test] *ERROR* radeon: ring test failed
> > (sracth(0x15E4)=0xCAFEDEAD)
> > [3.781010] [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22).
> > [3.782542] radeon :00:04.0: failled initializing CP (-22).
> > [3.784006] radeon
We only use the "if (pool == NULL)" path for right now.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 26 +++---
1 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c
b/drivers/g
This is right now limited to only non-pool constructs.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/ttm_page_alloc.c |9 ++---
drivers/gpu/drm/ttm/ttm_tt.c | 10 --
include/drm/ttm/ttm_bo_driver.h |2 ++
include/drm/ttm/ttm_page_alloc.h
_page (and pci_unmap_page) if
there is a DMA addresses passed in for that page. If the dma_address
is zero (or DMA_ERROR_CODE), then we continue on with our old
behaviour.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/radeon/radeon.h |4 ++-
drivers/gpu/drm/radeon/radeon_gar
hys do not give use the DMA (bus) address).
Since we are using the DMA API on those pages, we should pass in the
DMA address to this function so it can save it in its proper fields
(later patches use it).
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/nouveau/nouveau_sgdma.c |3 ++
vice' or 'struct pci_device'
but figured it would make first sense to get your guys input before heading
that route.
This patch-set is also available at:
git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
devel/ttm.pci-api.v3
Konrad Rzeszutek Wilk (5):
ttm: Introduce
_page (and pci_unmap_page) if
there is a DMA addresses passed in for that page. If the dma_address
is zero (or DMA_ERROR_CODE), then we continue on with our old
behaviour.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/nouveau/nouveau_sgdma.c | 28 +---
1 files c
On Fri, Jan 07, 2011 at 05:47:59PM +, Prasad Joshi wrote:
> 2011/1/7 Konrad Rzeszutek Wilk :
> >> > The errors
> >> >
> >> > [ ? ?3.778476] [drm:r100_ring_test] *ERROR* radeon: ring test failed
> >> > (sracth(0x15E4)=0xCAFEDEAD)
> >>
On Mon, Jan 10, 2011 at 03:25:55PM +0100, Thomas Hellstrom wrote:
> Konrad,
>
> Before looking further into the patch series, I need to make sure
> I've completely understood the problem and why you've chosen this
> solution: Please see inline.
Of course.
.. snip ..
> >The problem above can be e
. snip ..
> >>2) What about accounting? In a *non-Xen* environment, will the
> >>number of coherent pages be less than the number of DMA32 pages, or
> >>will dma_alloc_coherent just translate into a alloc_page(GFP_DMA32)?
> >The code in the IOMMUs end up calling __get_free_pages, which ends up
> >i
> Tried your patches on Guest machine, it did not help. I am attaching
> the messages from guest machine.
Ok, then the issue is not with the guest but the IOMMU.
>
> > well, what is the DMA code that gets turned on when you run your guest?
>
> Looking into the qemu-kvm code to find more informat
> AMD chipset.
They don't seem to have have any errata's for this GFX business.
But they do have a passthrough mode - hopefull that is not what you have
passed in?
> > Since you mentioned that you were able to passthrough other PCI devices
> > that means the IOMMU is working. This narrows it down
. snip ..
> >>>I think the error path would be the same in both cases?
> >>Not really. The really dangerous situation is if TTM is allowed to
> >>exhaust all GFP_KERNEL memory. Then any application or kernel task
> >Ok, since GFP_KERNEL does not contain the GFP_DMA32 flag then
> >this should be OK?
> >> Another thing that I was thinking of is what happens if you have a
> >> huge gart and allocate a lot of coherent memory. Could that
> >> potentially exhaust IOMMU resources?
> >
> >
> >
> > So the GART is in the PCI space in one of the BARs of the device right?
> > (We are talking about the d
> > What motherboard is this?
>
> ASUS M4A89TD Pro/USB3, it is mentioned on the link
> http://wiki.xensource.com/xenwiki/VTdHowTo
I am not sure how the implementation of the IOMMU
in the Xen hypervisor is different from the Linux implementation.
Usually it is lock-step, but it might be different.
On Tue, Jan 11, 2011 at 01:12:57PM -0500, Alex Deucher wrote:
> On Tue, Jan 11, 2011 at 11:59 AM, Konrad Rzeszutek Wilk
> wrote:
> >> >> Another thing that I was thinking of is what happens if you have a
> >> >> huge gart and allocate a lot of coherent me
On Wed, Jan 12, 2011 at 10:12:14AM +0100, Thomas Hellstrom wrote:
> Hi, Konrad.
>
> This discussion has become a bit lenghty. I'll filter out the
> sorted-out stuff, which leaves me with two remaining issues:
>
>
> On 01/11/2011 04:55 PM, Konrad Rzeszutek Wilk wrot
On Wed, Jan 12, 2011 at 10:19:39AM -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Jan 12, 2011 at 10:12:14AM +0100, Thomas Hellstrom wrote:
> > Hi, Konrad.
> >
> > This discussion has become a bit lenghty. I'll filter out the
> > sorted-out stuff, which lea
On Thu, Jan 27, 2011 at 10:19:55AM +0100, Thomas Hellstrom wrote:
> On 01/07/2011 06:11 PM, Konrad Rzeszutek Wilk wrote:
>
> Apart from previously mentioned indentation issues,
> Reviewed-by: Thomas Hellstrom
Thank you..
>
.. snip..
> > nouveau_sgdma_populate(struct ttm_
On Fri, Jan 07, 2011 at 12:11:43PM -0500, Konrad Rzeszutek Wilk wrote:
> If the TTM layer has used the DMA API to setup pages that are
> TTM_PAGE_FLAG_DMA32 (look at patch titled: "ttm: Utilize the dma_addr_t
> array for pages that are to in DMA32 pool."), lets use it
> whe
On Fri, Jan 07, 2011 at 12:11:44PM -0500, Konrad Rzeszutek Wilk wrote:
> If the TTM layer has used the DMA API to setup pages that are
> TTM_PAGE_FLAG_DMA32 (look at patch titled: "ttm: Utilize the dma_addr_t
> array for pages that are to in DMA32 pool."), lets use it
> whe
On Thu, Jan 27, 2011 at 10:28:45AM +0100, Thomas Hellstrom wrote:
> Konrad, Dave
>
> Given our previous discussion on the list, I believe these patches
> shouldn't introduce any regressions in the non-Xen case, however we
> should probably be prepared to back them out quickly if that turns
> out t
On Fri, Jan 28, 2011 at 09:42:48AM -0500, Jerome Glisse wrote:
> On Thu, Jan 27, 2011 at 4:20 PM, Konrad Rzeszutek Wilk
> wrote:
> > On Fri, Jan 07, 2011 at 12:11:43PM -0500, Konrad Rzeszutek Wilk wrote:
> >> If the TTM layer has used the DMA API to setup pages that are
>
. and some comments to make it easier to understand.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 14 +++---
include/drm/ttm/ttm_bo_api.h |3 ---
include/drm/ttm/ttm_bo_driver.h |6 +++---
include/drm/ttm/ttm_memory.h
While working on the DMA pool concept in the TTM code I re-read
everything once more to make sure I was not missing anything. Whilst doing
that I found some spelling mistakes and some wording that could be improved
a bit. So fixed it up and please consider this patch for 3.1.
.instead increment it by the count of pages that we want to
splice into the pool list.
In other words we were incrementing the pool->npages by the wrong
amount. This bug was observed from code inspection.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/ttm_page_alloc.c |
The bug-fix "ttm: Do not increment the amount of pages in a pool by the current
amount"
I never observed, but found while looking at the code. The cleanup patch:
"ttm: Fix spelling mistakes and remove unused #ifdef", I had posted earlier and
Randy
Dunlap graciously added some extra cleanups - whi
. and some comments to make it easier to understand.
Ackedby: Randy Dunlap
[v2: Added some more updates from Randy Dunlap]
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 16
include/drm/ttm/ttm_bo_api.h |3 ---
include/drm/ttm
> > > The bug-fix "ttm: Do not increment the amount of pages in a pool by the
> > > current amount"
> > > I never observed, but found while looking at the code. The cleanup patch:
> > > "ttm: Fix spelling mistakes and remove unused #ifdef", I had posted
> > > earlier and Randy
> > > Dunlap gracio
using the DMA
API."
and moves the mechanism of passing in 'struct device' to the TTM API.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/nouveau/nouveau_mem.c |4 ++--
drivers/gpu/drm/radeon/radeon_ttm.c |4 ++--
drivers/gpu/drm/ttm/ttm_bo.c |4 +
e struct ttm_bo_device and use that. However,
when 'ttm_tt_destroy' is called it sets ttm->be (which contains
the 'struct ttm_bo_device') to NULL so we cannot use it. Hence
we copy the 'struct device' pointer to the 'struct ttm_tm' and keep
it there.
[v2: A
would fallback to that?). Ended up calling 'unbind' on the
/sys/pci/.../$BDF/driver/[radeon,nouveau] to trigger the de-allocation path.
Thomas,
What is the best way to test vmw-gfx*? Does the Workstation (5?) support
this particular frontend?
Konrad Rzeszutek Wilk (2):
ttm: Incl
ages and copy all
> the data.
Makes sense.
>
> /Thomas
>
>
> On 03/08/2011 04:39 PM, Konrad Rzeszutek Wilk wrote:
> >These two patches are not strictly required but they do a bit of
> >cleanup and also fix a false reporting issue when the kernel is compiled
&g
On Fri, Aug 24, 2012 at 10:35:00AM +0800, Aaron.Chen ??? wrote:
> Hi,
>
> >What's with the #ifdef 0 or #ifdef 1?
>
> >Why is there a bunch of ddkxxx something? Can those header files be squashed
> >together?
>
> We have deleted all the "#ifdef 0 or #ifdef 1" and cut our codes into smaller
> p
Hey Alex,
Your recent patch "31f731a drm/radeon/dpm: fix calculations in
si_calculate_leakage_for_v_and_t_formula" causes a build regression:
drivers/built-in.o: In function `si_calculate_leakage_for_v_and_t_formula':
/home/build/linux-linus/drivers/gpu/drm/radeon/si_dpm.c:1770: undefined
referen
On Wed, Aug 07, 2013 at 12:09:32PM +0200, Daniel Vetter wrote:
> This fixes a WARN in i915_gem_free_object when the
> obj->pages_pin_count isn't 0.
>
> v2: Add locking to unmap, noticed by Chris Wilson. Note that even
> though we call unmap with our own dev->struct_mutex held that won't
> result i
with an illegal size. This is also fixed with this commit.
>
> v2: Fixed an error path and removed an unused variable.
>
> Signed-off-by: Thomas Hellstrom
> Cc: Jerome Glisse
> Cc: stable at vger.kernel.org
Reviewed-by: Konrad Rzeszutek Wilk
> ---
> drivers/gpu/drm/tt
On Wed, Jun 13, 2012 at 09:44:19AM +0800, llittle?? wrote:
>
> HI,all
> Now, my lab is using radeon_ati card?And, I need ati_card dma
> function?But, I do not clear that how the ati card know the dma address which
> alloced by kernel??
By using the PCI API.
>
> Can any kernel dri
On Tue, Mar 20, 2012 at 10:15:02AM +0800, Scott Fang wrote:
> Can I do the optimization like:
>
> if (ttm->caching_state == tt_cached)
> -drm_clflush_pages(ttm->pages, ttm->num_pages);
> +for (i = 0; i < ttm->num_pages; ++i)
> + if (PageHighMem(ttm->pages[i]))
> +
On August 9, 2014 1:39:39 AM EDT, Thomas Hellstrom
wrote:
>Hi.
>
Hey Thomas!
>IIRC I don't think the TTM DMA pool allocates coherent pages more than
>one page at a time, and _if that's true_ it's pretty unnecessary for
>the
>dma subsystem to route those allocations to CMA. Maybe Konrad could
>sh
ellstrom wrote:
> >>>>On 08/10/2014 05:11 AM, Mario Kleiner wrote:
> >>>>>Resent this time without HTML formatting which lkml doesn't like.
> >>>>>Sorry.
> >>>>>
> >>>>>On 08/09/2014 03:58 PM, Thomas Hells
On Wed, Nov 12, 2014 at 06:03:49PM +0100, Arnd Bergmann wrote:
> On Wednesday 12 November 2014 09:18:59 Konrad Rzeszutek Wilk wrote:
> > On Wed, Nov 12, 2014 at 01:39:05PM +0100, Thierry Reding wrote:
> > > From: Thierry Reding
> > >
> > > dma_alloc_coheren
Hey,
I should know this but I am bit behind on the latest of the drm-debug
tools. Is there a way to figure out which applications are using
GEM/TTM buffers? Or just even a simpler - which application is using
which DRM pages?
Michael (CC-ed here) is finding that TTM is hitting the memory ceiling
Yijing Wang wrote:
>Fix acpi_evaluate_object() return value check,
>shoud acpi_status not int.
Should be?
Your mailer also ate the word 'to' .
>
>Signed-off-by: Yijing Wang
>---
>
>v1->v2: Add CC to the related subsystem MAINTAINERS.
>
>---
> drivers/gpu/drm/i915/intel_acpi.c | 13
On Wed, Jul 02, 2014 at 05:08:43PM +0300, Michael S. Tsirkin wrote:
> On Wed, Jul 02, 2014 at 10:00:33AM -0400, Konrad Rzeszutek Wilk wrote:
> > On Wed, Jul 02, 2014 at 01:33:09PM +0200, Paolo Bonzini wrote:
> > > Il 01/07/2014 19:39, Ross Philipson ha scritto:
> > &
On Wed, Jul 02, 2014 at 06:29:23PM +0200, Paolo Bonzini wrote:
> Il 02/07/2014 17:27, Michael S. Tsirkin ha scritto:
> > At some level, maybe Paolo is right. Ignore existing drivers and ask
> > intel developers to update their drivers to do something sane on
> > hypervisors, even if they do ugly t
On Fri, May 04, 2012 at 02:46:54PM +0100, Dave Airlie wrote:
> From: Dave Airlie
>
> This adds the ability for ttm common code to take an SG table
> and use it as the backing for a slave TTM object.
I took a look at both patches from the perspective of the TTM DMA pool
code and it looks fine (th
On Tue, May 28, 2013 at 08:55:29PM +0200, Sven Joachim wrote:
> On 2013-05-26 23:09 +0200, Maarten Maathuis wrote:
>
> > My NV96 does not resume from suspend to ram (the screen stays black, magic
> > sysrq keys do work) with the current linus git kernel, i bisected it to the
> > following commit.
On Mon, Nov 04, 2013 at 05:57:38AM -0800, Thomas Hellstrom wrote:
> Used by the vmwgfx driver
That looks OK to me. And baremetal should not be
affected as the Intel VT-d driver turns of the SWIOTLB
driver - so it will still use the classic ttm pool code.
Reviewed-by: Konrad Rzeszutek W
On Mon, Nov 04, 2013 at 05:57:39AM -0800, Thomas Hellstrom wrote:
> The code handles three different cases:
> 1) physical page addresses. The ttm page array is used.
> 2) DMA subsystem addresses. A scatter-gather list is used.
> 3) Coherent pages. The ttm dma pool is used, together with the dma_ttm
On Mon, Nov 04, 2013 at 05:57:37AM -0800, Thomas Hellstrom wrote:
> These patches makes the vmwgfx driver use the DMA API to obtain valid
> device addresses rather than blindly using physical addresses.
>
> The main motivation is to be able to use a virtual IOMMU in the future.
Ooooh. Neat! Are t
nd deallocation.
>
> Signed-off-by: Jérôme Glisse
> Reviewed-by: Mario Kleiner
> Tested-by: Michel Dänzer
> Cc: Thomas Hellstrom
> Cc: Konrad Rzeszutek Wilk
Reviewed-by: Konrad Rzeszutek Wilk
> ---
> drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 9 ++---
> 1
On Tue, May 19, 2015 at 08:33:59PM +0900, Alexandre Courbot wrote:
> On 05/16/2015 04:55 AM, Konrad Rzeszutek Wilk wrote:
> >On Fri, May 15, 2015 at 04:09:54PM +0900, Alexandre Courbot wrote:
> >>dma_alloc_coherent() can return memory in the vmalloc range.
> >>virt_t
me Glisse
> Reviewed-by: Mario Kleiner
> Cc: Michel Dänzer
> Cc: Thomas Hellstrom
> Cc: Konrad Rzeszutek Wilk
Reviewed-by: Konrad Rzeszutek Wilk
> ---
> drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletio
gned-off-by: Jérôme Glisse
> Reviewed-by: Mario Kleiner
> Tested-by: Michel Dänzer
> Cc: Thomas Hellstrom
> Cc: Konrad Rzeszutek Wilk
Reviewed-by: Konrad Rzeszutek Wilk
> ---
> drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 8 +---
> 1 file changed, 1 insertion(+), 7
> So after a bit of irc chatting with Maarten this seems to be more
> involved. The above check is to cache the dma mapping, but the
> implementation is bogus in tons of ways:
> - If direction changes we don't bother with unmaping and freeing the
> mapping, but simply leak it.
> - This will break i
the backport, including the original git commit
> id to .
>
> thanks,
>
> greg k-h
>
> -- original commit in Linus's tree --
>
> >From 1625e7e549c50fb57a1e1ab1cb0f5735c84c9029 Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk
On Fri, Jul 26, 2013 at 04:37:32PM -0400, Ilia Mirkin wrote:
> On Fri, Jul 26, 2013 at 2:28 PM, konrad wilk
> wrote:
> > I just saw this on a box of mine (rc1 worked) I hadn't done yet a bisection.
> > Any suggestions?
> >
> > ring 0 polarity 1
> > [6.023776] Already setup the GSI :22
> > ^G^
On Mon, Jun 03, 2013 at 03:50:50PM +1000, Ben Skeggs wrote:
> On Fri, May 31, 2013 at 11:05 PM, Konrad Rzeszutek Wilk <
> konrad.wilk at oracle.com> wrote:
>
> > On Tue, May 28, 2013 at 08:55:29PM +0200, Sven Joachim wrote:
> > > On 2013-05-26 23:09 +0200, Maarten Ma
tutorial on how
to use different mailers. The "Setup your tools" has a nice
tutorial on .gitconfig setup. If you would like to use
me as test subject and send emails to me before the mailing list
please do.
I usually have this in my .gitconfig file:
[konrad at build-external ~]$ more .gitconfig
On Sun, Jun 16, 2013 at 04:57:17PM +0200, Daniel Vetter wrote:
> Hi all,
>
> So I've taken a look again at the locking mess in our fbdev support and cried.
> Fixing up the console_lock mess around the fbdev notifier will be real work,
> semanatically the fbdev layer does lots of stupid things (lik
I am wondering is if there are some fallbacks when the
underlaying IOMMU can't deal with a request for contingous regions
that are more than 2MB?
Thanks.
>From a681a4adb4738c32cb1acdf6f5161bf877816b01 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk
Date: Fri, 21 Jun 2013 11:17:55 -
On Fri, Jun 21, 2013 at 03:28:28PM -0400, Konrad Rzeszutek Wilk wrote:
> Hey,
CC-ing Imre,
Imre, your patch 90797e6d1ec0dfde6ba62a48b9ee3803887d6ed4
("drm/i915: create compact dma scatter lists for gem objects") is the cause
of the regression.
If I revert your patch it boots fin
On Sat, Jun 22, 2013 at 03:22:59PM +0100, Chris Wilson wrote:
> On Fri, Jun 21, 2013 at 10:03:43PM -0400, Konrad Rzeszutek Wilk wrote:
> > On Fri, Jun 21, 2013 at 03:28:28PM -0400, Konrad Rzeszutek Wilk wrote:
> > > Hey,
> >
> > CC-ing I
.get_pages' and the
i915_gem_gtt_prepare_object to retry with smaller max gap of the
amount of PFNs that can be combined together - but with this issue
discovered during rc7 that might be too risky.
Reported-and-Tested-by: Konrad Rzeszutek Wilk
CC: Chris Wilson
CC: Imre Deak
CC: Daniel Vett
Hey Dave, Chris, Imre,
Attached is a fix that makes v3.10-rc6 boot on Intel HD 4000 when SWIOTLB
bounce buffer is in usage. The SWIOTLB can only handle up to 512KB swath
of memory to create bounce buffers for and Imre's patch made it possible
to provide more than to the DMA API which caused it to
On Mon, Jun 24, 2013 at 07:09:12PM +0200, Daniel Vetter wrote:
> On Mon, Jun 24, 2013 at 11:47:48AM -0400, Konrad Rzeszutek Wilk wrote:
> > Git commit 90797e6d1ec0dfde6ba62a48b9ee3803887d6ed4
> > ("drm/i915: create compact dma scatter lists for gem objects") makes
> >
On Mon, Jun 24, 2013 at 08:26:18PM +0200, Daniel Vetter wrote:
> On Mon, Jun 24, 2013 at 7:32 PM, Konrad Rzeszutek Wilk
> wrote:
> > On Mon, Jun 24, 2013 at 07:09:12PM +0200, Daniel Vetter wrote:
> >> On Mon, Jun 24, 2013 at 11:47:48AM -0400, Konrad Rzeszutek Wilk wro
Dave Airlie wrote:
>On Tue, Jun 25, 2013 at 4:34 AM, Konrad Rzeszutek Wilk
> wrote:
>> On Mon, Jun 24, 2013 at 08:26:18PM +0200, Daniel Vetter wrote:
>>> On Mon, Jun 24, 2013 at 7:32 PM, Konrad Rzeszutek Wilk
>>> wrote:
>>> > On Mon, Jun 24, 201
On Tue, Jun 25, 2013 at 11:03:01AM -0400, Jerome Glisse wrote:
> On Fri, Jun 21, 2013 at 3:28 PM, Konrad Rzeszutek Wilk
> wrote:
> > Hey,
> >
> > I am using an ThinkPad X230 with an Intel HD 4000. With a stock Fedora 18
> > (3.9.6) I can get it to boot and work just
> >>Dave.
> >
> > Hey Dave
> > Of course I will investigate.
> >
> > The SWIOTLB is unfortunately used because it is a fallback (and I am the
> > maintainer of it) and if a real IOMMU is activated it can be mitigated
> > differently. When you say 'passed through' you mean in terms of an IOMMU
>
James Simmons wrote:
>
>> Am Freitag, 28. Juni 2013, 13:31:50 schrieb Dave Airlie:
>> > Okay drm-next is pretty big, possibly the biggest ever.
>> >
>> > Outstanding things I know about, and will merge, if they arrive
>soon:
>> > exynos -next
>> > nouveau -next
>> >
>> > Big things I've merged:
401 - 500 of 505 matches
Mail list logo
