On Thu, Feb 04, 2021 at 11:49:23AM +, Robin Murphy wrote:
> On 2021-02-04 07:29, Christoph Hellwig wrote:
> > On Wed, Feb 03, 2021 at 03:37:05PM -0800, Dongli Zhang wrote:
> > > This patch converts several swiotlb related variables to arrays, in
> > > order to maintain stat/status for different
On Sun, Feb 07, 2021 at 04:56:01PM +0100, Christoph Hellwig wrote:
> On Thu, Feb 04, 2021 at 09:40:23AM +0100, Christoph Hellwig wrote:
> > So one thing that has been on my mind for a while: I'd really like
> > to kill the separate dma ops in Xen swiotlb. If we compare xen-swiotlb
> > to swiotlb
On Mon, May 10, 2021 at 05:25:25PM +0200, Christoph Hellwig wrote:
> Hi all,
>
> swiotlb_max_segment is a rather strange "API" export by swiotlb.c,
> and i915 is the only (remaining) user.
>
> swiotlb_max_segment returns 0 if swiotlb is not in use, 1 if
> SWIOTLB_FORCE is set or swiotlb-zen is se
On Tue, Jul 06, 2021 at 04:05:13PM +0200, Christoph Hellwig wrote:
> On Tue, Jul 06, 2021 at 03:01:04PM +0100, Robin Murphy wrote:
> > FWIW I was pondering the question of whether to do something along those
> > lines or just scrap the default assignment entirely, so since I hadn't got
> > round
On Tue, Jul 06, 2021 at 05:57:21PM +0100, Will Deacon wrote:
> On Tue, Jul 06, 2021 at 10:46:07AM -0400, Konrad Rzeszutek Wilk wrote:
> > On Tue, Jul 06, 2021 at 04:05:13PM +0200, Christoph Hellwig wrote:
> > > On Tue, Jul 06, 2021 at 03:01:04PM +0100, Robin Murphy wrote:
..snip..
> > > I think the main question I have is how would you like to see patches for
> > > 5.15? i.e. as patches on top of devel/for-linus-5.14 or something else?
> >
> > Yes that would be perfect. If there are any dependencies on the rc1, I
> > can rebase it on top of that.
>
> Yes, please,
On Thu, Jan 10, 2019 at 04:26:43PM +0100, Sibren Vasse wrote:
> On Thu, 10 Jan 2019 at 14:57, Christoph Hellwig wrote:
> >
> > On Thu, Jan 10, 2019 at 10:59:02AM +0100, Michel Dänzer wrote:
> > >
> > > Hi Christoph,
> > >
> > >
> > > https://bugs.freedesktop.org/109234 (please ignore comments #6-#
.snip..
> > -u64 drm_get_max_iomem(void)
> > +bool drm_need_swiotlb(int dma_bits)
> > {
> > struct resource *tmp;
> > resource_size_t max_iomem = 0;
> >
> > + /*
> > +* Xen paravirtual hosts require swiotlb regardless of requested dma
> > +* transfer size.
> > +*
> > +*
On Tue, May 18, 2021 at 02:48:35PM +0800, Claire Chang wrote:
> I didn't move this to a separate file because I feel it might be
> confusing for swiotlb_alloc/free (and need more functions to be
> non-static).
> Maybe instead of moving to a separate file, we can try to come up with
> a better namin
On Tue, May 18, 2021 at 02:51:52PM +0800, Claire Chang wrote:
> Still keep this function because directly using dev->dma_io_tlb_mem
> will cause issues for memory allocation for existing devices. The pool
> can't support atomic coherent allocation so we need to distinguish the
> per device pool and
> > do the set_memory_decrypted()+memset(). Is this okay or should
> > swiotlb_init_io_tlb_mem() add an additional argument to do this
> > conditionally?
>
> I'm actually not sure if this it okay. If not, will add an additional
> argument for it.
Any observations discovered? (Want to make sure my
On Tue, Jun 15, 2021 at 09:27:02PM +0800, Claire Chang wrote:
> Always have the pointer to the swiotlb pool used in struct device. This
> could help simplify the code for other pools.
Applying: swiotlb: Set dev->dma_io_tlb_mem to the swiotlb pool used
error: patch failed: kernel/dma/swiotlb.c:339
On Sat, Jun 19, 2021 at 11:40:31AM +0800, Claire Chang wrote:
> This series implements mitigations for lack of DMA access control on
> systems without an IOMMU, which could result in the DMA accessing the
> system memory at unexpected times and/or unexpected addresses, possibly
> leading to data le
On Thu, Jun 24, 2021 at 10:10:51AM -0400, Qian Cai wrote:
>
>
> On 6/24/2021 7:48 AM, Will Deacon wrote:
> > Ok, diff below which attempts to tackle the offset issue I mentioned as
> > well. Qian Cai -- please can you try with these changes?
>
> This works fine.
Cool. Let me squash this patch i
On Thu, Jun 24, 2021 at 11:55:14PM +0800, Claire Chang wrote:
> This series implements mitigations for lack of DMA access control on
> systems without an IOMMU, which could result in the DMA accessing the
> system memory at unexpected times and/or unexpected addresses, possibly
> leading to data le
On Thu, Jun 24, 2021 at 11:58:57PM +0800, Claire Chang wrote:
> On Thu, Jun 24, 2021 at 11:56 PM Konrad Rzeszutek Wilk
> wrote:
> >
> > On Thu, Jun 24, 2021 at 10:10:51AM -0400, Qian Cai wrote:
> > >
> > >
> > > On 6/24/2021 7:48 AM, Will Deacon wr
On Tue, Apr 18, 2017 at 02:13:59PM +, David Laight wrote:
> From: Logan Gunthorpe
> > Sent: 13 April 2017 23:05
> > Straightforward conversion to the new helper, except due to
> > the lack of error path, we have to warn if unmapable memory
> > is ever present in the sgl.
Interesting that you d
On Tue, Apr 18, 2017 at 09:42:20AM -0600, Logan Gunthorpe wrote:
>
>
> On 18/04/17 08:27 AM, Konrad Rzeszutek Wilk wrote:
> > Interesting that you didn't CC any of the maintainers. Could you
> > do that in the future please?
>
> Please read the cover lette
On Mon, May 30, 2016 at 01:54:06PM +0200, Krzysztof Kozlowski wrote:
> The dma-mapping core and the implementations do not change the
> DMA attributes passed by pointer. Thus the pointer can point to const
> data. However the attributes do not have to be a bitfield. Instead
> unsigned long will d
---
> drivers/xen/swiotlb-xen.c | 93
> ++
> include/xen/swiotlb-xen.h | 62 +---
> 4 files changed, 49 insertions(+), 137 deletions(-)
Yeeey!
Reviewed-by: Konrad Rzeszutek Wilk
__
On Thu, Jun 08, 2017 at 03:25:33PM +0200, Christoph Hellwig wrote:
> DMA_ERROR_CODE is going to go away, so don't rely on it.
Reviewed-by: Konrad Rzeszutek Wilk
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedes
On Thu, Aug 06, 2020 at 03:46:23AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:47ec5303 Merge git://git.kernel.org/pub/scm/linux/kernel/g..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=16fe1dea90
> kernel
On Fri, May 15, 2015 at 04:09:54PM +0900, Alexandre Courbot wrote:
> dma_alloc_coherent() can return memory in the vmalloc range.
> virt_to_page() cannot handle such addresses and crashes. This
> patch detects such cases and obtains the struct page * using
> vmalloc_to_page() instead.
>
> Signed-o
On Fri, Jul 11, 2014 at 08:29:56AM +0200, Daniel Vetter wrote:
> On Thu, Jul 10, 2014 at 09:08:24PM +, Tian, Kevin wrote:
> > actually I'm curious whether it's still necessary to __detect__ PCH. Could
> > we assume a 1:1 mapping between GPU and PCH, e.g. BDW already hard
> > code the knowledge:
On Sat, May 31, 2014 at 12:00:45PM +0900, Tetsuo Handa wrote:
> >From 4e8d1a83629c5966bfd401c5f2187355624194f2 Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa
> Date: Sat, 31 May 2014 09:59:44 +0900
> Subject: [PATCH 3/5] gpu/drm/ttm: Use mutex_trylock() to avoid deadlock
> inside shrinker function
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^G^G
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
On Tue, Aug 13, 2013 at 06:19:35PM +0900, Inki Dae wrote:
> This patch adds a buffer synchronization framework based on DMA BUF[1]
> and and based on ww-mutexes[2] for lock mechanism.
>
> The purpose of this framework is to provide not only buffer access control
> to CPU and DMA but also easy-to-u
> > > +EXPORT_SYMBOL(is_dmabuf_sync_supported);
> >
> > _GPL ?
> >
> > I would also prefix it with 'dmabuf_is_sync_supported' just to make
> > all of the libraries call start with 'dmabuf'
> >
>
> Seems better. Will change it to dmabuf_is_sync_supported, and use
> EXPORT_SYMBOL_GPL.
One thing
On Wed, Aug 28, 2013 at 09:28:57AM +0200, Lucas Stach wrote:
> Am Mittwoch, den 28.08.2013, 17:09 +1000 schrieb Ben Skeggs:
> > On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach wrote:
> > > MSIs were only problematic on some old, broken chipsets. But now that we
> > > already see systems where PCI le
On Wed, Aug 28, 2013 at 02:00:47AM +0200, Lucas Stach wrote:
> Signed-off-by: Lucas Stach
> ---
> drivers/gpu/drm/nouveau/nouveau_bo.c | 4
> drivers/gpu/drm/nouveau/nouveau_gem.c | 5 +
> 2 files changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
> b/drive
On Wed, Aug 28, 2013 at 06:58:37PM +0200, Lucas Stach wrote:
> Am Mittwoch, den 28.08.2013, 12:43 -0400 schrieb Konrad Rzeszutek Wilk:
> > On Wed, Aug 28, 2013 at 02:00:47AM +0200, Lucas Stach wrote:
> > > Signed-off-by: Lucas Stach
> > > ---
> > > drive
an R
> Signed-off-by: Manjunath Goudar
> Cc: David Airlie
> Cc: "Paul E. McKenney"
> Cc: David Howells
> Cc: Thomas Gleixner
> Cc: Dave Jones
> Cc: Dave Airlie
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-ker...@vger.kernel.org
Reviewed-by: Konrad Rzesz
On Sun, Sep 08, 2013 at 02:10:58PM +0200, Markus Trippelsdorf wrote:
> Currently radeon devices are not properbly shutdown during kexec. This
properly
> cases a varity of issues, e.g. dpm initialization failures.
> Fix this by implementing a radeon_pci_shutdown function, that unloads
> the driver
On Tue, Sep 10, 2013 at 01:20:57PM +0400, Alex Ivanov wrote:
> Alex,
>
> 09.09.2013, в 21:43, Alex Deucher написал(а):
>
> > On Mon, Sep 9, 2013 at 12:44 PM, Alex Ivanov wrote:
> >> Folks,
> >>
> >> We (people at linux-parisc @ vger.kernel.org mail list) are trying to make
> >> native video op
On Sat, Sep 21, 2013 at 07:39:10AM +0400, Alex Ivanov wrote:
> 21.09.2013, в 1:27, Alex Deucher написал(а):
>
> > On Tue, Sep 17, 2013 at 3:33 PM, Alex Ivanov wrote:
> >> 17.09.2013, в 18:24, Alex Deucher написал(а):
> >>
> >>> On Tue, Sep 17, 2013 at 5:23 AM, Alex Ivanov wrote:
> Alex,
On Wed, Sep 25, 2013 at 08:29:07PM +0400, Alex Ivanov wrote:
> 24.09.2013, 00:11, "Konrad Rzeszutek Wilk" :
> > On Sat, Sep 21, 2013 at 07:39:10AM +0400, Alex Ivanov wrote:
> >
> >> 21.09.2013, в 1:27, Alex Deucher написал(а):
> >>> The register
On Tue, Oct 01, 2013 at 12:16:16PM +0200, Thomas Hellstrom wrote:
> Jerome, Konrad
>
> Forgive an ignorant question, but it appears like both Nouveau and
> Radeon may use pci_map_page() when populating TTMs on
> pages obtained using the ordinary (not DMA pool). These pages will,
> if I understand
On Tue, May 20, 2014 at 01:40:40AM +0100, Dave Airlie wrote:
>
> cc'ing dri-devel.
It looks pretty simple and correct . I can test it tomorrow and make sure it
works
right.
>
> > >From d0d57745ba23faf605b0f249b57d283fe1a8ee60 Mon Sep 17 00:00:00 2001
> > From: Tetsuo Handa
> > Date: Mon, 19 Ma
On Sat, May 24, 2014 at 11:22:09PM +0900, Tetsuo Handa wrote:
> Hello.
>
> I tried to test whether it is OK (from point of view of reentrant) to use
> mutex_lock() or mutex_lock_killable() inside shrinker functions when shrinker
> functions do memory allocation, for drivers/gpu/drm/ttm/ttm_page_al
On Thu, May 29, 2014 at 06:47:49AM +0900, Tetsuo Handa wrote:
> Konrad Rzeszutek Wilk wrote:
> > On Sat, May 24, 2014 at 11:22:09PM +0900, Tetsuo Handa wrote:
> > > Hello.
> > >
> > > I tried to test whether it is OK (from point of view of ree
On Thu, May 29, 2014 at 11:34:59PM +0900, Tetsuo Handa wrote:
> Tetsuo Handa wrote:
> > Konrad Rzeszutek Wilk wrote:
> > > On Sat, May 24, 2014 at 11:22:09PM +0900, Tetsuo Handa wrote:
> > > > Hello.
> > > >
> > > > I tried to test
On Wed, Nov 12, 2014 at 01:39:05PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> dma_alloc_coherent() returns a kernel virtual address that is part of
> the linear range. Passing such an address to virt_to_page() is illegal
> on non-coherent architectures. This causes the kernel to oops
mple helpers to check if any of
Why is it unreliable?
> the dma_ops associated with a device points to the swiotlb functions,
> making swiotlb check reliable for a device.
>
> Signed-off-by: Jérôme Glisse
> Cc: Konrad Rzeszutek Wilk
> Cc: Alex Deucher
> Cc: Ben Skeg
On Wed, Aug 26, 2015 at 03:26:42PM -0400, Jerome Glisse wrote:
> On Wed, Aug 26, 2015 at 03:02:31PM -0400, Konrad Rzeszutek Wilk wrote:
> > On Wed, Aug 26, 2015 at 02:52:02PM -0400, jglisse at redhat.com wrote:
> > > From: Jérôme Glisse
> > >
> > > Some devi
On Wed, Aug 26, 2015 at 04:31:50PM -0400, Jerome Glisse wrote:
> On Wed, Aug 26, 2015 at 03:44:52PM -0400, Konrad Rzeszutek Wilk wrote:
> > On Wed, Aug 26, 2015 at 03:26:42PM -0400, Jerome Glisse wrote:
> > > On Wed, Aug 26, 2015 at 03:02:31PM -0400, Konrad Rzeszutek Wilk wro
On Mon, Dec 19, 2016 at 03:16:44PM +0100, Juergen Gross wrote:
> On 19/12/16 13:29, Chris Wilson wrote:
> > On Mon, Dec 19, 2016 at 12:39:16PM +0100, Juergen Gross wrote:
> >> With recent 4.10 kernel the graphics isn't coming up under Xen. First
> >> failure message is:
> >>
> >> [ 46.656649] i91
On Tue, Dec 20, 2016 at 09:42:46AM -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Dec 19, 2016 at 03:16:44PM +0100, Juergen Gross wrote:
> > On 19/12/16 13:29, Chris Wilson wrote:
> > > On Mon, Dec 19, 2016 at 12:39:16PM +0100, Juergen Gross wrote:
> > >> With recent
On Tue, Aug 13, 2013 at 06:19:35PM +0900, Inki Dae wrote:
> This patch adds a buffer synchronization framework based on DMA BUF[1]
> and and based on ww-mutexes[2] for lock mechanism.
>
> The purpose of this framework is to provide not only buffer access control
> to CPU and DMA but also easy-to-u
> > > +EXPORT_SYMBOL(is_dmabuf_sync_supported);
> >
> > _GPL ?
> >
> > I would also prefix it with 'dmabuf_is_sync_supported' just to make
> > all of the libraries call start with 'dmabuf'
> >
>
> Seems better. Will change it to dmabuf_is_sync_supported, and use
> EXPORT_SYMBOL_GPL.
One thing
On Wed, Aug 28, 2013 at 09:28:57AM +0200, Lucas Stach wrote:
> Am Mittwoch, den 28.08.2013, 17:09 +1000 schrieb Ben Skeggs:
> > On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach wrote:
> > > MSIs were only problematic on some old, broken chipsets. But now that we
> > > already see systems where PCI le
On Wed, Aug 28, 2013 at 02:00:47AM +0200, Lucas Stach wrote:
> Signed-off-by: Lucas Stach
> ---
> drivers/gpu/drm/nouveau/nouveau_bo.c | 4
> drivers/gpu/drm/nouveau/nouveau_gem.c | 5 +
> 2 files changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
> b/drive
On Wed, Aug 28, 2013 at 06:58:37PM +0200, Lucas Stach wrote:
> Am Mittwoch, den 28.08.2013, 12:43 -0400 schrieb Konrad Rzeszutek Wilk:
> > On Wed, Aug 28, 2013 at 02:00:47AM +0200, Lucas Stach wrote:
> > > Signed-off-by: Lucas Stach
> > > ---
> > > drive
I keep on getting this:
Any thoughts? I hadn't tried to do a bisection or such.
[ 1784.126124] Console: switching to colour VGA+ 80x25
[ 1784.128286] drm_kms_helper: drm: unregistered panic notifier
[ 1784.133601] [drm] radeon: finishing device.
[ 1784.135934] BUG: unable to handle kernel NULL po
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@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
> >> + 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
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
ends on DRM_SAMSUNG
> + help
> + Choose this option if you want to use Samsung FIMD for DRM.
> + If M is selected, the module will be called samsung_drm_fimd
.. which is just nitpicking and optional so. I took a look at the code and
you can stick 'Reviewed-by: Konrad
On Mon, Oct 03, 2011 at 06:35:42PM +0200, Thomas Hellstrom wrote:
> On 09/30/2011 04:09 PM, Konrad Rzeszutek Wilk wrote:
> >On Fri, Sep 30, 2011 at 08:59:52AM +0200, Thomas Hellstrom wrote:
> >>Konrad,
> >>
> >>I'm really sorry for taking so long to re
On Fri, Sep 30, 2011 at 06:43:16PM +0900, Inki Dae wrote:
> I am sorry for missed title.
Hey Dave,
I took a look at the driver with memory/DMA in mind and it looks
good to me.
>
>
>
> From: Inki Dae [mailto:inki@samsung.com]
> Sent: Friday, September 30, 2011 6:39 PM
> To: 'airl...@linux
On Mon, Oct 03, 2011 at 03:12:17AM +0200, Jakob Bornecrantz wrote:
> On Thu, Sep 29, 2011 at 11:50 PM, Konrad Rzeszutek Wilk
> wrote:
> > On Wed, Sep 28, 2011 at 04:10:06PM +0200, Thomas Hellstrom wrote:
> >> From: Jakob Bornecrantz
> >>
> >> Mor
On Mon, Oct 03, 2011 at 03:18:32AM +0200, Jakob Bornecrantz wrote:
> On Thu, Sep 29, 2011 at 11:42 PM, Konrad Rzeszutek Wilk
> wrote:
> > On Wed, Sep 28, 2011 at 04:10:01PM +0200, Thomas Hellstrom wrote:
> >> From: Jakob Bornecrantz
> >>
> >> Signed-off-
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/nouveau/nouveau_debugfs.c |1 +
drivers/gpu/drm/nouveau/nouveau_sgdma.c |5 +
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_debugfs.c
b/drivers/gpu/drm/nouveau/nouveau_debug
__ttm_put_pages,
which later on we will remove (by moving the __ttm_put_pages).
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 29 +++--
drivers/gpu/drm/ttm/ttm_tt.c |6 ++
include/drm/ttm/ttm_page_alloc.h | 16 +
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_memory.c |7
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
troying them).
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/ttm_tt.c | 15 +++
1 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 76c982f..31ae359 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b
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
The two overrides will be choosen by the backends whether they
want to use a different TTM page pool than the default.
If the backend does not choose a new override, the default one
will be used.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 10
ey work.
Michel (thanks!) took a spin of the patches on his PowerPC and they did not
cause any regressions (wheew).
The patches are also located in a git tree:
git://oss.oracle.com/git/kwilk/xen.git devel/ttm.dma_pool.v2.1
Konrad Rzeszutek Wilk (11):
swiotlb: Expose swiotlb_nr_tlb function
which was used in the "ttm: Wrap ttm_[put|get]_pages and
extract GFP_* and caching states from 'struct ttm_tt" patch.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 83 -
1 files changed, 40 insertions(+), 43 del
: Alex Deucher
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/radeon/radeon_ttm.c | 19 +++
1 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 60125dd..2e7419f 100644
--- a/drivers
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, Oct 19, 2011 at 06:19:21PM -0400, Konrad Rzeszutek Wilk wrote:
Hmm, seems a part of this got eaten by the Internet monsters.
Since v2.0: [not posted]
- Redid the registration/override to be tightly integrated with the
'struct ttm_backend_func' per Thomas's suggest
On Sat, Oct 22, 2011 at 11:40:54AM +0200, Thomas Hellstrom wrote:
> Konrad,
>
> I was hoping that we could get rid of the dma_address shuffling into
> core TTM,
> like I mentioned in the review. From what I can tell it's now only
> used in the backend and
> core ttm doesn't care about it.
>
> Is
> >For that there are couple of architectural issues I am not sure how to solve.
> >
> >There has to be some form of TTM<->[Radeon|Nouveau] lookup mechanism
> >to say: "here is a 'struct page *', give me the bus address". Currently
> >this is solved by keeping an array of DMA addresses along with t
On Sat, Oct 22, 2011 at 10:29:33AM +0200, Thomas Hellstrom wrote:
> From: Jakob Bornecrantz
>
> Signed-off-by: Jakob Bornecrantz
> Signed-off-by: Thomas Hellstrom
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 10 +-
> 1 files changed, 9 insertions(+), 1 deletions(-)
>
> diff --git a
On Mon, Oct 24, 2011 at 03:01:23PM -0700, Jakob Bornecrantz wrote:
>
> - Original Message -
> > On Sat, Oct 22, 2011 at 10:29:33AM +0200, Thomas Hellstrom wrote:
> > > From: Jakob Bornecrantz
> > >
> > > Signed-off-by: Jakob Bornecrantz
> > > Signed-off-by: Thomas Hellstrom
> > > ---
>
> > +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
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.gli...@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/dr
1 - 100 of 505 matches
Mail list logo
