Two nice things here:
- drm_dev_register will truly register everything in the right order
if the driver doesn't have a ->load callback. Before this we had to
init the primary mode_group after the device nodes where already
registered.
- Less things to keep track of when reworking the connec
It's been dead code since forever since mode groups haven't ever been
implemented. On top of that it's also been non-functional since we
only ever filtered the getresources ioctl and not any of the others
nor the mode object lookup code.
Given overwhelming evidence it looks like this isn't a featu
Remaining manual work in the drm core&helpers. Nothing special here,
no surprises.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c | 26 ++
drivers/gpu/drm/drm_crtc_helper.c | 2 +-
drivers/gpu/drm/drm_fb_cma_helper.c | 2 +-
drivers/gpu/drm/drm_m
Now that we also grab the connection_mutex and so fixed the race with
atomic modeset we can use the iterator there too.
The other special case is drm_connector_unplug_all which would have a
locking inversion with the sysfs store/show functions if we'd grab the
mode_config.mutex around the unplug.
Now that dp mst hotplug takes all locks we can amend the locking rules
for the iterators. This is needed before we can roll these out in the
atomic code to avoid getting burried in WARNINGs.
v2: Rebase onto the extracted list locking assert and add a comment to
explain the rules.
v3: Fixup German
Similar with the i915 take all modeset locks for mst hotplug. This is
needed to make sure radeon holds both mode_config.mutex and
mode_config.connection_mutex when updating the connector_list, which
is the new (interim) locking regime we want for that.
Signed-off-by: Daniel Vetter
---
drivers/gp
While auditing various users of the connector/encoder lists I realized
that the atomic code is a very prolific user of them. And it only ever
grabs the mode_config->connection_mutex, but not the
mode_config->mutex like all the other code walking encoder/connector
lists.
The problem is that we can'
Ever since framebuffers are reference counted we have a special lock
for the global fb list. Make sure users of that list do hold that
lock when using the new iterators.
Signed-off-by: Daniel Vetter
---
include/drm/drm_crtc.h | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git
Just so I have a user for this macro.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 053adbb97037..60eebf5f6da8 100644
---
Because of DP MST connectors can now be hotplugged and we must hold
the right lock when walking the connector lists. Enforce this by
checking the locking in our shiny new list walking macros.
v2: Extract the locking check into a small static inline helper to
help readability. This will be more im
This is now truly only duct-tape to keep locking checks happy since
calling this function when hpd or polling are already enabled is a
bug. The fbdev helper can't cope with hotplug changes yet at this
point, only after that.
Otoh a bit more robustness in this function can't hurt, and with this
fbd
So on first looks this seems superflous since drivers should ensure
correct ordering to not make this a problem. Otoh ordering constraints
between hdp, fbdev load and enabling polling are already tricky on
some hardware and it helps to be more robust.
But the real goal is to just shut up a locking
And roll them out across drm_* files. The point here isn't code
prettification (it helps with that too) but that some of these lists
aren't static any more. And having macros will gives us a convenient
place to put locking checks into.
I didn't add an iterator for props since that's only used by a
No need to pass the planelist when everyone just uses
dev->mode_config.plane_list anyway.
I want to add a pile more of iterators with unified (obj, dev)
arguments. This is just prep.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_pm.c | 2 +-
drivers/gpu/drm/shmobile/shmo
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
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:
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
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.
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
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(-
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 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
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
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).
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).
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).
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/
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
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
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 +---
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
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
:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150709/6e12ffc7/attachment.html>
Hi Philipp
On Tue, May 19, 2015 at 04:28:12PM +0200, Philipp Zabel wrote:
> The parallel-display driver used an undocumented, non-standard property
> "fsl,panel" to optionally associate with a drm_panel device. This patch
> fixes the driver to use the same OF graph bindings as the LDB driver
> ins
2015-07-09 Joonyoung Shim :
> +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
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
On Fri, 26 Jun 2015 12:08:57 -0300
Danilo Cesar Lemes de Paula wrote:
> To ease the navigation in the documentation we should use inside
> those tags so readers can easily jump between methods directly.
>
> This was discussed in 2014[1] and is implemented by getting a list
> of from the DocBoo
> 2. Use the GPUVM inside the GPU to access system memory. The
> limitation here is that the GPUVM uses 40-bit addresses, so the
> virtual address range must be in the lower 40-bit address range of the
> CPU. Access speed is limited by PCI-e bandwidth. Another limitation is
> that the system memory
+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
On Thu, Jul 09, 2015 at 04:33:01PM +0300, Ville Syrjälä wrote:
> 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 ì´(ê°) ì´ ê¸:
> > > >>>
> > > >>>
> > > >>>Ca
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
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
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
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
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
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 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
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
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
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
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
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 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
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 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:
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 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
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.
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 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 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
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
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
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
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
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
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
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(
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
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 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: Chunming Zhou
These are register headers for the ACP (Audio CoProcessor)
block on the GPU.
Reviewed-by: Maruthi Bayyavarapu
Acked-by: Jammy Zhou
Signed-off-by: Chunming Zhou
Signed-off-by: Alex Deucher
---
.../gpu/drm/amd/include/asic_reg/acp/acp_2_1_d.h | 437
.../drm/amd/inc
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: 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 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 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
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 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
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
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 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 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
[...]
> -
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>
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
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>
lication/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150709/0bdff701/attachment.sig>
|--- |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>
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150709/4807a91e/attachment.html>
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_
or the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150709/639037d8/attachment.html>
RL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150709/d82993e3/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150709/ad7992dd/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150709/1e18a0ec/attachment.html>
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 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
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
1 - 100 of 122 matches
Mail list logo
