>>
>>
>> Can the various in-kernel GPU drivers benefit from this? If so, wiring
>> up one or more of those would be helpful?
>
>
> I'm sure that other in-kernel GPU drivers can have benefit.
> It must be helpful.
>
> If I was familiar with other in-kernel GPU drivers code, I tried to patch
> them.
mp;Technology
Peking University
Beijing, 100871, PRC
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150709/c688e5f5/attachment.html>
lication/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150709/0bdff701/attachment.sig>
ES)
last_pte = GEN8_PTES;
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150709/f1b0ee5b/attachment.sig>
2015-07-09 ì¤ì 7:47ì Dave Airlie ì´(ê°) ì´ ê¸:
>>>
>>>
>>> Can the various in-kernel GPU drivers benefit from this? If so, wiring
>>> up one or more of those would be helpful?
>>
>>
>> I'm sure that other in-kernel GPU drivers can have benefit.
>> It must be helpful.
>>
>> If I was fami
Hi Mark,
Thank you very much for your review!
> -Original Message-
> From: Wang Jianwei-B52261
> Sent: Thursday, July 09, 2015 9:28 AM
> To: Wang Jianwei-B52261
> Subject: FW: [PATCH v5 1/3] drm/layerscape: Add Freescale DCU DRM driver
>
>
> From: Jianwei Wang
>
> This patch add suppo
https://bugzilla.kernel.org/show_bug.cgi?id=100541
--- Comment #6 from Michel Dänzer ---
The mouse cursor corruption should be fixed with the drm-fixes-4.2-wip branch
of http://cgit.freedesktop.org/~agd5f/linux/ .
--
You are receiving this mail because:
You are watching the assignee of the bug
Although I don't like the method of manually iterating sysfs, it seems the last
resort if we want to avoid introducing libudev dependency.
Besides, you mentioned that you would spend some time on the device enumeration
interface, do you have some chance to look at it?
Regards,
Jammy
-Origi
ogl???
It does.
However, your problem seems rather that gnome-shell/mutter doesn't
support R200 anymore.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
-- next part ------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 173 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150709/fd979396/attachment.sig>
Hi Mark,
Thank you very much for your review!
From: Mark yao [mailto:mark@rock-chips.com]
Sent: Wednesday, July 01, 2015 9:59 AM
To: Wang Jianwei-B52261
Cc: David Airlie; daniel.vetter at intel.com; stefan at agner.ch; dri-devel;
linux-kernel; linux-arm-kernel at lists.infradead.org; Wang J
On 09.07.2015 03:16, j.glisse at gmail.com wrote:
> From: Jérôme Glisse
>
> Current code never allowed the page pool to actualy fill in anyway.
> This fix it, so that we only start freeing page from the pool when
> we go over the pool size.
>
> Signed-off-by: Jérôme Glisse
[...]
> -
From: Dave Airlie
This really doesn't seem to have much chance of working anymore,
esp for irq context, qxl at least tries to talk to the hw,
and waits for irqs, and fails.
with runtime pm and other stuff I think we should just
bail on this for now.
Signed-off-by: Dave Airlie
---
drivers/gpu
Andrzej Hajda (6):
drm/exynos/hdmi: fix edid memory leak
drm/exynos/mixer: fix interrupt clearing
drm/exynos/mixer: correct vsync configuration sequence
drm/exynos/mixer: always update INT_EN cache
drm/exynos/mixer: simplify poweron flag
drm/exynos/mixer: replace MXR_INT_EN register c
edid returned by drm_get_edid should be freed.
The patch fixes it.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 99
The driver used incorrect flags to clear interrupt status.
The patch fixes it.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_mixer.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos
Specification advises to clear vsync indicator before configuring vsync.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_mixer.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.
INT_EN cache field was updated only by mixer_enable_vblank.
The patch adds update also by mixer_disable_vblank function.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_mixer.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/driver
The driver uses bool protected by mutex to track power state.
The patch replaces this combo with single bit and atomic bitops.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_mixer.c | 52 ++-
1 file changed, 14 insertions(+), 38 deletions(-)
diff
Driver uses only VSYNC interrupts, so we need to cache VSYNC bit state only.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_mixer.c | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/e
On Thu Jul 9 03:32:40 2015 GMT+0100, Michel Dänzer wrote:
> On 09.07.2015 06:01, Steven Newbury wrote:
> > On Wed, 2015-07-08 at 21:56 +0100, Steven Newbury wrote:
> >> On Tue, 2015-07-07 at 09:18 +0300, Pekka Paalanen wrote:
> >>> On Mon, 06 Jul 2015 22:50:30 +0100 Steven Newbury
> >>> wrote:
https://bugzilla.kernel.org/show_bug.cgi?id=100541
Christian Casteyde changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugzilla.kernel.org/show_bug.cgi?id=100541
Christian Casteyde changed:
What|Removed |Added
Status|RESOLVED|CLOSED
Resolution|CODE_FIX
On 07/09/2015 03:25 PM, Andrzej Hajda wrote:
> The driver used incorrect flags to clear interrupt status.
> The patch fixes it.
>
> Signed-off-by: Andrzej Hajda
> ---
> drivers/gpu/drm/exynos/exynos_mixer.c | 8 +++-
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers
Hi Andrzej,
On 07/09/2015 03:25 PM, Andrzej Hajda wrote:
>
>
> Andrzej Hajda (6):
> drm/exynos/hdmi: fix edid memory leak
> drm/exynos/mixer: fix interrupt clearing
> drm/exynos/mixer: correct vsync configuration sequence
> drm/exynos/mixer: always update INT_EN cache
> drm/exynos/mixe
https://bugzilla.kernel.org/show_bug.cgi?id=101261
Bug ID: 101261
Summary: Radeon - Kernel warning when driver is unbound to
secondary GPU
Product: Drivers
Version: 2.5
Kernel Version: 4.0.7
Hardware: All
https://bugzilla.kernel.org/show_bug.cgi?id=101261
--- Comment #1 from Beau V.C. Bellamy ---
Created attachment 182291
--> https://bugzilla.kernel.org/attachment.cgi?id=182291&action=edit
Script to unbind and start VM
--
You are receiving this mail because:
You are watching the assignee of th
The driver used incorrect flags to clear interrupt status.
The patch fixes it.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_mixer.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exyno
+Cc Andrzej,
On 07/07/2015 02:41 AM, Daniel Vetter wrote:
> On Mon, Jul 06, 2015 at 11:20:13AM -0300, Gustavo Padovan wrote:
>> From: Gustavo Padovan
>>
>> struct drm_crtc already stores the enabled state of the crtc
>> thus we don't need to replicate enabled in exynos_drm_crtc.
>>
I think exyno
https://bugzilla.kernel.org/show_bug.cgi?id=101261
--- Comment #2 from Beau V.C. Bellamy ---
When unbinding the radeon driver from a second GPU in order to bind to the
vfio-pci driver (so it can be used on a virtual machine), the linux kernel will
display several warnings. It looks like some res
https://bugzilla.kernel.org/show_bug.cgi?id=101261
Beau V.C. Bellamy changed:
What|Removed |Added
Summary|Radeon - Kernel warning |Radeon - Kernel warning
The Kodi/XBMC developers want to transcode NV12 to RGB with OpenGL
shaders, importing the two source planes through
EGL_EXT_image_dma_buf_import. That requires importing the Y plane as an
R8 EGLImage and the UV plane as either an RG88 or GR88 EGLImage.
CC: Peter Frühberger
Cc: Rainer Hochecker
On Mon, Jun 29, 2015 at 7:33 AM, Maninder Singh
wrote:
>
> pdd is already dereferenced before this check.
> So it is redundtant to validate pdd here.
>
> Signed-off-by: Maninder Singh
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_process.c |3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
On 07/09/2015 05:07 PM, Andrzej Hajda wrote:
> The driver used incorrect flags to clear interrupt status.
> The patch fixes it.
>
> Signed-off-by: Andrzej Hajda
> ---
> drivers/gpu/drm/exynos/exynos_mixer.c | 9 -
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/driver
Currently pdd is validate after dereferencing it, which is
not correct, Thus validate pdd before its first use.
Signed-off-by: Maninder Singh
---
v1: remove validation of pdd after its usage
v2: do validation at first place rather than removing
drivers/gpu/drm/amd/amdkfd/kfd_process.c |9 ++
On Tue, Jul 7, 2015 at 8:27 PM, Jerome Glisse wrote:
> On Tue, Jul 07, 2015 at 11:29:38AM -0400, Ilia Mirkin wrote:
>> On Mon, Jul 6, 2015 at 8:42 PM, Andrew Chew wrote:
>> > Hello,
>> >
>> > I am currently looking into ways to support fixed virtual address
>> > allocations
>> > and sparse mappi
On Thu, Jul 9, 2015 at 12:11 PM, Maninder Singh
wrote:
> Currently pdd is validate after dereferencing it, which is
> not correct, Thus validate pdd before its first use.
>
> Signed-off-by: Maninder Singh
> ---
> v1: remove validation of pdd after its usage
> v2: do validation at first place rat
BO_VA (-35)
around the lock/reset on previous tests.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150709/8b803072/attachment-0001.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150709/1e18a0ec/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150709/ad7992dd/attachment.html>
RL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150709/d82993e3/attachment.html>
Hi Dave,
A single fix so far for 4.2:
- checking a pointer is not null before using it
Thanks,
Oded
The following changes since commit d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754:
Linux 4.2-rc1 (2015-07-05 11:01:52 -0700)
are available in the git repository at:
git://people.freedesk
or the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150709/639037d8/attachment.html>
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150709/4807a91e/attachment.html>
|--- |FIXED
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150709/8fe2d75a/attachment.html>
generation in any way.
But yeah for newer hardware it's rather irrelevant.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachme
On Thu, Jul 09, 2015 at 08:55:25AM +0900, Gioh Kim wrote:
>
>
> 2015-07-09 ì¤ì 7:47ì Dave Airlie ì´(ê°) ì´ ê¸:
> >>>
> >>>
> >>>Can the various in-kernel GPU drivers benefit from this? If so, wiring
> >>>up one or more of those would be helpful?
> >>
> >>
> >>I'm sure that other in-kern
On Thu, 9 Jul 2015 01:38:42 -0700
Chad Versace wrote:
> The Kodi/XBMC developers want to transcode NV12 to RGB with OpenGL
> shaders, importing the two source planes through
> EGL_EXT_image_dma_buf_import. That requires importing the Y plane as an
> R8 EGLImage and the UV plane as either an RG88
On Thu, Jul 09, 2015 at 04:08:08PM +0300, Pekka Paalanen wrote:
> On Thu, 9 Jul 2015 01:38:42 -0700
> Chad Versace wrote:
>
> > The Kodi/XBMC developers want to transcode NV12 to RGB with OpenGL
> > shaders, importing the two source planes through
> > EGL_EXT_image_dma_buf_import. That requires
On Thu, Jul 09, 2015 at 03:08:48PM +0200, Daniel Vetter wrote:
> On Thu, Jul 09, 2015 at 08:55:25AM +0900, Gioh Kim wrote:
> >
> >
> > 2015-07-09 ì¤ì 7:47ì Dave Airlie ì´(ê°) ì´ ê¸:
> > >>>
> > >>>
> > >>>Can the various in-kernel GPU drivers benefit from this? If so, wiring
> > >>>up o
Hi Dave,
Pile of fixes for either 4.2 issues or cc: stable. This should fix the 2nd
kind of WARNING Linus's been seeing, please ask him to scream if that's
not the case.
Cheers, Daniel
The following changes since commit d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754:
Linux 4.2-rc1 (2015-07-05 11:0
Hi Dave,
Non-i915 fixes I picked up in your absence: kerneldoc + 2x cc: stable. The
rockchip fix is just in here to make sure it won't get lost, I kept it
since I didn't yet see a rockchip fixes pull nor confirmation from Mark
that he pulled it into his tree.
Cheers, Daniel
The following change
Hi Inki, Joonyoung,
These patches removes obsolete and old structures, to simplify further
development. They should not change behavior of the driver.
The patchset is based on exynos-drm-next plus my HDMI related fixes [1].
The patchset was tested on Universal and Odroid U3.
[1]: http://permali
s5p_hdmi_platform_data were used before device tree introduction.
As HDMI driver is DT only we can drop this struct completely.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 36 +---
1 file changed, 5 insertions(+), 31 deletions(-)
diff
GPIO is tested only in hdmi_detect, so there is no reason to set it in
other places and to preserve its value in context.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/exyno
The patch replaces duplicated driver data fields in private context with
pointer to driver data. It also simplifies driver data lookup code.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 49 +++-
1 file changed, 20 insertions(+), 29 delet
The patch removes intermediate struct for HDMIv13 register configuration,
instead registry values are calculated on the fly.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 280 +--
1 file changed, 101 insertions(+), 179 deletions(-)
diff
Most of the code is called by drm core framework, so it is already synchronized.
The only async function is irq routine which only calls drm framework so it
does not need to be synchronized.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 27 +++
1
The patch removes redundant fields from hdmi_conf_regs. Their values
can be calculated from current_mode. This patch is the first step to remove
whole hdmi_conf_regs structure.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 68 +---
1 file
The patch removes intermediate struct for HDMIv14 register configuration,
instead registry values are calculated on the fly.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 427 +--
1 file changed, 109 insertions(+), 318 deletions(-)
diff
Hi Rob,
DMA pipes can be configured to work in either line mode or block mode.
In line mode, it is the same as RGB/VIG pipes except no CSC/SCALE/PP/...
support. So it can be used by any CRTC.
In block mode, it is used as a rotator with writeback(0/1) interface which
is not covered by this change.
On Thu, Jul 9, 2015 at 2:58 AM, Steven Newbury wrote:
>
>
> On Thu Jul 9 03:32:40 2015 GMT+0100, Michel Dänzer wrote:
>> On 09.07.2015 06:01, Steven Newbury wrote:
>> > On Wed, 2015-07-08 at 21:56 +0100, Steven Newbury wrote:
>> >> On Tue, 2015-07-07 at 09:18 +0300, Pekka Paalanen wrote:
>> >>> O
Hi Dave,
radeon and amdgpu fixes for 4.2. All over the place:
- fix cursor corruption on resume and re-enable no VT switch on suspend
- vblank fixes
- fix gpuvm error messages
- misc other fixes
The following changes since commit d6ac4ffc61ace6ed6f183e9fd7f207c0ddafb897:
Merge branch 'for-lin
On Thu Jul 9 16:04:35 2015 GMT+0100, Alex Deucher wrote:
> On Thu, Jul 9, 2015 at 2:58 AM, Steven Newbury
> wrote:
> >
> >
> > On Thu Jul 9 03:32:40 2015 GMT+0100, Michel Dänzer wrote:
> >> On 09.07.2015 06:01, Steven Newbury wrote:
> >> > On Wed, 2015-07-08 at 21:56 +0100, Steven Newbury wrote:
From: Chunming Zhou
This is used by the incoming ACP driver. The DMA
engine for the i2s audio codec is part of the GPU.
This exposes an amd gnb bus for the i2s codec to
hang off of.
Reviewed-by: Jammy Zhou
Signed-off-by: Chunming Zhou
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/Kconfig
From: Chunming Zhou
CGS (Common Graphics Services) is an AMD cross component
abstraction layer to designed to better encapsulate
specific IP block drivers so different teams can effectively
work on differnet IP block drivers independently. It provides
a common interface for things like accessing
From: Chunming Zhou
This implements the MMIO register accessors.
Reviewed-by: Jammy Zhou
Signed-off-by: Chunming Zhou
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c | 45 -
1 file changed, 38 insertions(+), 7 deletions(-)
diff --git a
From: Chunming Zhou
This implements the irq src registrar.
Reviewed-by: Jammy Zhou
Signed-off-by: Chunming Zhou
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c | 81 ++---
drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c | 2 +
drivers/gpu/drm/amd/
From: Chunming Zhou
This implements the pciconfig register accessors.
Reviewed-by: Jammy Zhou
Signed-off-by: Chunming Zhou
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c | 40 +++--
1 file changed, 28 insertions(+), 12 deletions(-)
diff -
From: Chunming Zhou
This implements the interface for atombios command
and data table access.
Reviewed-by: Jammy Zhou
Signed-off-by: Chunming Zhou
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c | 28 ++--
1 file changed, 22 insertions(+), 6 de
From: Chunming Zhou
This implements the cgs interface for allocating
GPU memory.
Reviewed-by: Jammy Zhou
Signed-off-by: Chunming Zhou
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c | 238 ++--
1 file changed, 226 insertions(+), 12 deletion
From: Maruthi Bayyavarapu
This adds the ACP (Audio CoProcessor) IP driver and wires
it up to the amdgpu driver. The ACP block provides the DMA
engine and bus for the i2s codec which is supported by an
alsa driver. This is required for audio on APUs that
utilize an i2s codec.
v2: integrate i2s/
From: Maruthi Srinivas Bayyavarapu
The following are design changes for ACP DMA :
1. For capture usecase, DMA Interrupt on Complete is added for
ACP_TO_SYSRAM_CH_NUM DMA channel
2. For playback usecase, the destination for DMA descriptors is
reversed.
3. Finally, modified DMA buffer positio
From: Maruthi Srinivas Bayyavarapu
ACP IP can be powered on and off during system wide suspend/resume
transition. AMD ASoC PCM device will use this module during
system suspend/resume and PCM device's runtime pm.
Also, updated code comments.
Signed-off-by: Maruthi Bayyavarapu
Reviewed-by: Alex
From: Maruthi Srinivas Bayyavarapu
with the default gnb bus runtime pm ops, alsa pcm device attached to
it is unable to get runtime suspended/resumed.
Signed-off-by: Maruthi Bayyavarapu
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/amd/bus/amd_gnb_bus.c | 5 -
1 file changed, 5 deletions(
The GEM CMA helper allocates GEM objects with dma_alloc_writecombine(),
so the objects are cache coherent, and the exporter methods for these
objects can skip cache sync.
To accomplish this a dma atrribute is added to drm_gem_object,
and is used with dma_map_sg_attrs/dma_unmap_sg_attrs in
drm_gem_
From: Jérôme Glisse
Current code never allowed the page pool to actualy fill in anyway.
This fix it, so that we only start freeing page from the pool when
we go over the pool size.
Changed since v1:
- Move the page batching optimization to its separate patch.
Changed since v2:
- Do not re
From: Jérôme Glisse
Calls to set_memory_wb() incure heavy TLB flush and IPI cost. To
minimize those wait until pool grow beyond batch size before
draining the pool.
Signed-off-by: Jérôme Glisse
Reviewed-by: Mario Kleiner
Reviewed-and-Tested-by: Michel Dänzer
Reviewed-by: Konrad Rzeszutek
On Thu, Jul 9, 2015 at 2:19 PM, wrote:
> From: Jérôme Glisse
>
> Current code never allowed the page pool to actualy fill in anyway.
> This fix it, so that we only start freeing page from the pool when
> we go over the pool size.
>
> Changed since v1:
> - Move the page batching optimization
On Thu, Jul 9, 2015 at 2:19 PM, wrote:
> From: Jérôme Glisse
>
> Calls to set_memory_wb() incure heavy TLB flush and IPI cost. To
> minimize those wait until pool grow beyond batch size before
> draining the pool.
>
> Signed-off-by: Jérôme Glisse
> Reviewed-by: Mario Kleiner
> Reviewed-and
On Thu, Jul 09, 2015 at 01:15:34PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> This really doesn't seem to have much chance of working anymore,
>
> esp for irq context, qxl at least tries to talk to the hw,
> and waits for irqs, and fails.
>
> with runtime pm and other stuff I think we sh
Hi all,
I wanted to take another look at struct_mutex usage in modern (gem) drivers and
noticed that for a fair lot we're very to be completely struct_mutex free.
This pile here is the the simple part, which mostly just removes code and
mutex_lock/unlock calls. All the patches here are independen
Doesn't really add anything which can't be figured out through
proc files. And more clearly separates the new gem mmap handling
code from the old drm maps mmap handling code, which is surely a
good thing.
Cc: Martin Peres
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_gem.c | 11 +---
This function takes two locks, both of them the wrong ones. This
wasn't an oversight from my fb locking rework since both patches
landed in parallel. We really only need fb_lock when walking that
list, since everything we can reach from that is refcounted properly
already.
Cc: Rob Clark
Cc: Laure
BUG_ON kills the driver, WARN_ON is much friendly. And usually nothing
bad happens when the locking is lightly busted.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_ge
Since David Herrmann's mmap vma manager rework we don't need to grab
dev->struct_mutex any more to prevent races when looking up the mmap
offset. Drop it and instead don't forget to use the unref_unlocked
variant (since the drm core still cares).
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/
Since David Herrmann's mmap vma manager rework we don't need to grab
dev->struct_mutex any more to prevent races when looking up the mmap
offset. Drop it and instead don't forget to use the unref_unlocked
variant (since the drm core still cares).
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/
Since David Herrmann's mmap vma manager rework we don't need to grab
dev->struct_mutex any more to prevent races when looking up the mmap
offset. Drop it and instead don't forget to use the unref_unlocked
variant (since the drm core still cares).
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/
Looking up an obj, immediate dropping the acquired reference and then
continuing to use it isn't how this is supposed to work. Fix this by
holding a reference for the entire function.
While at it stop grabbing dev->struct_mutex, it doesn't protect
anything here.
Signed-off-by: Daniel Vetter
---
Since David Herrmann's mmap vma manager rework we don't need to grab
dev->struct_mutex any more to prevent races when looking up the mmap
offset. Drop it and instead don't forget to use the unref_unlocked
variant (since the drm core still cares).
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/
Since David Herrmann's mmap vma manager rework we don't need to grab
dev->struct_mutex any more to prevent races when looking up the mmap
offset. Drop it and instead don't forget to use the unref_unlocked
variant (since the drm core still cares).
Cc: Laurent Pinchart
Cc: Rob Clark
Signed-off-by:
Since David Herrmann's mmap vma manager rework we don't need to grab
dev->struct_mutex any more to prevent races when looking up the mmap
offset. Drop it and instead don't forget to use the unref_unlocked
variant (since the drm core still cares).
Aside: I stumbled over the mmap handler which direc
Since David Herrmann's mmap vma manager rework we don't need to grab
dev->struct_mutex any more to prevent races when looking up the mmap
offset. Drop it and instead don't forget to use the unref_unlocked
variant (since the drm core still cares).
While at it also fix a leak when this ioctl is call
It doesn't protect anything at all. fbdev helper state is all
protected by modeset locks, and nouveau bo state is taken care of by
ttm. There's also nothing else grabbing struct_mutex that might need
to coordinate with this code. Also this is driver load code, no one
can get at the device yet anywa
This is only called in driver load/unload paths, no need to grab any
locks at all. Also, ttm takes care of itself anyway.
Cc: Ben Skeggs
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/nouveau/nouveau_ttm.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_tt
It really doesn't protect anything which doesn't have other locks
already. It also doesn't seem to be wired up into the driver unload
code fwiw, but that's a different issue.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/qxl/qxl_object.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-
It really doesn't protect anything which doesn't have other locks
already. Also this is run from driver unload code so not much need for
locks anyway.
Cc: Alex Deucher
Cc: "Christian König"
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/radeon/radeon_object.c | 4 +---
1 file changed, 1 ins
We already grab 2 device-global locks (write-sema rdev->pm.mclk_lock
and rdev->ring_lock), adding another global mutex won't serialize this
code more. And since there's really nothing interesting that gets
protected in radeon by dev->struct mutex (we only have the global z
buffer owners and it's st
It really doesn't protect anything which doesn't have other locks
already. Also this is run from driver unload code so not much need for
locks anyway.
Same changes as for readone really.
Cc: Alex Deucher
Cc: "Christian König"
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/amd/amdgpu/amdgpu
Similar to radeon, except that amdgpu doesn't even use struct_mutex to
protect anything like the shared z buffer (sane gpu architecture,
yay!). And the code already grabs the globa adev->ring_lock, so this
code can't race with itself. Which makes struct_mutex completely
redundnant. Remove it.
Cc:
Hi all,
So this is the second iteration of my connector locking series. This tries to
clarify the cargo-culted locking rules around hotadd/removing drm_connector,
which was added to support DP MST. I want to get this in first for a release or
so just to document all the locking rules we have (and
1 - 100 of 122 matches
Mail list logo
