[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #142 from Jan Ziak <0xe2.0x9a.0x9b at gmail.com> ---
(In reply to Chris Waters from comment #141)
> At what point did we go from talking about radeon, the driver this bug
> report is about, to amdgpu?
This freedesktop.org bug is a Mesa bug. The bug title is "Radeonsi ...".
If the visual artifacting issue is solved in radeon.ko, the patch will probably
be in short time applied to amdgpu.ko, and vice versa.
> Isn't support and performance for GCN 1.1 cards rather bad on amdgpu
> compared to radeon?
Support for R9 390/390X (Grenada) in amdgpu.ko is basically equivalent to
radeon.ko (at least on my machine). Performance is very similar too.
amdgpu.ko and radeon.ko are loading the same firmware files for R9 390/390X
(/lib/firmware/radeon/{hawaii,HAWAII}*.bin).
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161211/c8f90008/attachment.html>
[RFC] Using DC in amdgpu for upcoming GPU
On Wed, Dec 07, 2016 at 09:02:13PM -0500, Harry Wentland wrote: > We propose to use the Display Core (DC) driver for display support on > AMD's upcoming GPU (referred to by uGPU in the rest of the doc). In order to > avoid a flag day the plan is to only support uGPU initially and transition > to older ASICs gradually. Bridgeman brought it up a few times that this here was the question - it's kinda missing a question mark, hard to figure this out ;-). I'd say for upstream it doesn't really matter, but imo having both atomic and non-atomic paths in one driver is one world of hurt and I strongly recommend against it, at least if feasible. All drivers that switched switched in one go, the only exception was i915 (it took much longer than we ever feared, causing lots of pain) and nouveau (which only converted nv50+, but pre/post-nv50 have always been two almost completely separate worlds anyway). > The DC component has received extensive testing within AMD for DCE8, 10, and > 11 GPUs and is being prepared for uGPU. Support should be better than > amdgpu's current display support. > > * All of our QA effort is focused on DC > * All of our CQE effort is focused on DC > * All of our OEM preloads and custom engagements use DC > * DC behavior mirrors what we do for other OSes > > The new asic utilizes a completely re-designed atom interface, so we cannot > easily leverage much of the existing atom-based code. > > We've introduced DC to the community earlier in 2016 and received a fair > amount of feedback. Some of what we've addressed so far are: > > * Self-contain ASIC specific code. We did a bunch of work to pull >common sequences into dc/dce and leave ASIC specific code in >separate folders. > * Started to expose AUX and I2C through generic kernel/drm >functionality and are mostly using that. Some of that code is still >needlessly convoluted. This cleanup is in progress. > * Integrated Dave and Jeromeâs work on removing abstraction in bios >parser. > * Retire adapter service and asic capability > * Remove some abstraction in GPIO > > Since a lot of our code is shared with pre- and post-silicon validation > suites changes need to be done gradually to prevent breakages due to a major > flag day. This, coupled with adding support for new asics and lots of new > feature introductions means progress has not been as quick as we would have > liked. We have made a lot of progress none the less. > > The remaining concerns that were brought up during the last review that we > are working on addressing: > > * Continue to cleanup and reduce the abstractions in DC where it >makes sense. > * Removing duplicate code in I2C and AUX as we transition to using the >DRM core interfaces. We can't fully transition until we've helped >fill in the gaps in the drm core that we need for certain features. > * Making sure Atomic API support is correct. Some of the semantics of >the Atomic API were not particularly clear when we started this, >however, that is improving a lot as the core drm documentation >improves. Getting this code upstream and in the hands of more >atomic users will further help us identify and rectify any gaps we >have. Ok so I guess Dave is typing some more general comments about demidlayering, let me type some guidelines about atomic. Hopefully this all materializes itself a bit better into improved upstream docs, but meh. Step 0: Prep So atomic is transactional, but it's not validate + rollback or commit, but duplicate state, validate and then either throw away or commit. There's a few big reasons for this: a) partial atomic updates - if you duplicate it's much easier to check that you have all the right locks b) kfree() is much easier to check for correctness than a rollback code and c) atomic_check functions are much easier to audit for invalid changes to persistent state. Trouble is that this seems a bit unusual compared to all other approaches, and ime (from the drawn-out i915 conversion) you really don't want to mix things up. Ofc for private state you can roll back (e.g. vc4 does that for the drm_mm allocator thing for scanout slots or whatever it is), but it's trivial easy to accidentally check the wrong state or mix them up or something else bad. Long story short, I think step 0 for DC is to split state from objects, i.e. for each dc_surface/foo/bar you need a dc_surface/foo/bar_state. And all the back-end functions need to take both the object and the state explicitly. This is a bit a pain to do, but should be pretty much just mechanical. And imo not all of it needs to happen before DC lands in upstream, but see above imo that half-converted state is postively horrible. This should also not harm cross-os reuse at all, you can still store things together on os where that makes sense. Guidelines for amdgpu atomic structures drm atomic stores everything in state structs on plane/connector/crtc. This includes any property
[Bug 98984] Hexagonal shapes around lights in Cities: Skylines
https://bugs.freedesktop.org/show_bug.cgi?id=98984 --- Comment #1 from kuehner.moritz at gmail.com --- I'm affected by the same bug. I managed to create a apitrace. https://drive.google.com/open?id=0B-LPqSh05jsNdWJWbFprcDR4MTQ <- 959,8 MB compressed >From glxinfo: Extended renderer info (GLX_MESA_query_renderer): Vendor: X.Org (0x1002) Device: AMD POLARIS10 (DRM 3.3.0 / 4.8.12-3-ARCH, LLVM 3.9.0) (0x67df) Version: 13.0.2 Accelerated: yes Video memory: 4059MB Unified memory: no Preferred profile: core (0x1) Max core profile version: 4.3 Max compat profile version: 3.0 Max GLES1 profile version: 1.1 Max GLES[23] profile version: 3.1 OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD POLARIS10 (DRM 3.3.0 / 4.8.12-3-ARCH, LLVM 3.9.0) OpenGL core profile version string: 4.3 (Core Profile) Mesa 13.0.2 OpenGL core profile shading language version string: 4.30 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161211/334e63a1/attachment.html>
[Bug 98238] witcher 2: objects are black when changing lod
https://bugs.freedesktop.org/show_bug.cgi?id=98238 --- Comment #11 from Shmerl --- I have the same problem with Mesa 13.0.2 / radeonsi on RX 480 (reported it here: https://github.com/virtual-programming/witcher2-linux/issues/175 ). See attached video there for example of this behavior. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161211/a1b3e725/attachment.html>
[PATCH] drm: Simplify GETRESOURCES ioctl
Looping twice when we can do it once is silly. Also use a consistent
style. Note that there's a good race with the connector list walking,
since that is no longer protected by mode_config.mutex. But that's for
a later patch to fix.
v2: Actually try to not blow up, somehow I lost the hunk that checks
we don't copy too much. Noticed by Chris.
v3:
- squash all drm_mode_getresources cleanups into one
- use consistent style for walking objects (Chris)
v4:
- Use u64_to_user_ptr (Chris)
- Don't forget to copy the last connector (Chris)
v5: Chris was right ...
Cc: Chris Wilson
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_mode_config.c | 111 ++
1 file changed, 39 insertions(+), 72 deletions(-)
diff --git a/drivers/gpu/drm/drm_mode_config.c
b/drivers/gpu/drm/drm_mode_config.c
index 2735a5847ffa..b1e8bbceaf39 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -84,17 +84,11 @@ int drm_mode_getresources(struct drm_device *dev, void
*data,
struct drm_file *file_priv)
{
struct drm_mode_card_res *card_res = data;
- struct list_head *lh;
struct drm_framebuffer *fb;
struct drm_connector *connector;
struct drm_crtc *crtc;
struct drm_encoder *encoder;
- int ret = 0;
- int connector_count = 0;
- int crtc_count = 0;
- int fb_count = 0;
- int encoder_count = 0;
- int copied = 0;
+ int count, ret = 0;
uint32_t __user *fb_id;
uint32_t __user *crtc_id;
uint32_t __user *connector_id;
@@ -105,89 +99,62 @@ int drm_mode_getresources(struct drm_device *dev, void
*data,
mutex_lock(_priv->fbs_lock);
- /*
-* For the non-control nodes we need to limit the list of resources
-* by IDs in the group list for this node
-*/
- list_for_each(lh, _priv->fbs)
- fb_count++;
-
- /* handle this in 4 parts */
- /* FBs */
- if (card_res->count_fbs >= fb_count) {
- copied = 0;
- fb_id = (uint32_t __user *)(unsigned long)card_res->fb_id_ptr;
- list_for_each_entry(fb, _priv->fbs, filp_head) {
- if (put_user(fb->base.id, fb_id + copied)) {
- mutex_unlock(_priv->fbs_lock);
- return -EFAULT;
- }
- copied++;
+ count = 0;
+ fb_id = u64_to_user_ptr(card_res->fb_id_ptr);
+ list_for_each_entry(fb, _priv->fbs, filp_head) {
+ if (count < card_res->count_fbs &&
+ put_user(fb->base.id, fb_id + count)) {
+ mutex_unlock(_priv->fbs_lock);
+ return -EFAULT;
}
+ count++;
}
- card_res->count_fbs = fb_count;
+ card_res->count_fbs = count;
mutex_unlock(_priv->fbs_lock);
/* mode_config.mutex protects the connector list against e.g. DP MST
* connector hot-adding. CRTC/Plane lists are invariant. */
mutex_lock(>mode_config.mutex);
- drm_for_each_crtc(crtc, dev)
- crtc_count++;
-
- drm_for_each_connector(connector, dev)
- connector_count++;
-
- drm_for_each_encoder(encoder, dev)
- encoder_count++;
-
card_res->max_height = dev->mode_config.max_height;
card_res->min_height = dev->mode_config.min_height;
card_res->max_width = dev->mode_config.max_width;
card_res->min_width = dev->mode_config.min_width;
- /* CRTCs */
- if (card_res->count_crtcs >= crtc_count) {
- copied = 0;
- crtc_id = (uint32_t __user *)(unsigned
long)card_res->crtc_id_ptr;
- drm_for_each_crtc(crtc, dev) {
- if (put_user(crtc->base.id, crtc_id + copied)) {
- ret = -EFAULT;
- goto out;
- }
- copied++;
+ count = 0;
+ crtc_id = u64_to_user_ptr(card_res->crtc_id_ptr);
+ drm_for_each_crtc(crtc, dev) {
+ if (count < card_res->count_crtcs &&
+ put_user(crtc->base.id, crtc_id + count)) {
+ ret = -EFAULT;
+ goto out;
}
+ count++;
}
- card_res->count_crtcs = crtc_count;
-
- /* Encoders */
- if (card_res->count_encoders >= encoder_count) {
- copied = 0;
- encoder_id = (uint32_t __user *)(unsigned
long)card_res->encoder_id_ptr;
- drm_for_each_encoder(encoder, dev) {
- if (put_user(encoder->base.id, encoder_id +
-copied)) {
- ret = -EFAULT;
- goto out;
- }
-
[PATCH libdrm] xf86drm: fix aliasing violation
Just tell the compiler that drm_event will alias the char buffer,
so that it has no excuse to warn or generate bad code.
Signed-off-by: Grazvydas Ignotas
---
Android.mk | 1 +
configure.ac| 9 +
libdrm_macros.h | 6 ++
xf86drmMode.c | 11 +++
4 files changed, 23 insertions(+), 4 deletions(-)
diff --git a/Android.mk b/Android.mk
index 2aa2bc9..ae7c3fe 100644
--- a/Android.mk
+++ b/Android.mk
@@ -42,6 +42,7 @@ LOCAL_C_INCLUDES := \
LOCAL_CFLAGS := \
-DHAVE_VISIBILITY=1 \
+ -DHAVE_MAY_ALIAS=1 \
-DHAVE_LIBDRM_ATOMIC_PRIMITIVES=1
include $(BUILD_STATIC_LIBRARY)
diff --git a/configure.ac b/configure.ac
index e0597c3..2868036 100644
--- a/configure.ac
+++ b/configure.ac
@@ -507,6 +507,15 @@ if test "x$HAVE_ATTRIBUTE_VISIBILITY" = xyes; then
AC_DEFINE(HAVE_VISIBILITY, 1, [Compiler supports
__attribute__(("hidden"))])
fi
+AC_MSG_CHECKING([whether $CC supports __attribute__((__may_alias__))])
+AC_LINK_IFELSE([AC_LANG_PROGRAM([
+struct foo_may_alias { int i; } __attribute__((__may_alias__)) foo;
+])], HAVE_ATTRIBUTE_MAY_ALIAS="yes"; AC_MSG_RESULT([yes]),
AC_MSG_RESULT([no]));
+
+if test "x$HAVE_ATTRIBUTE_MAY_ALIAS" = xyes; then
+AC_DEFINE(HAVE_MAY_ALIAS, 1, [Compiler supports
__attribute__((__may_alias__))])
+fi
+
AC_SUBST(WARN_CFLAGS)
AC_CONFIG_FILES([
Makefile
diff --git a/libdrm_macros.h b/libdrm_macros.h
index 639d090..eea47ee 100644
--- a/libdrm_macros.h
+++ b/libdrm_macros.h
@@ -29,6 +29,12 @@
# define drm_private
#endif
+#if defined(HAVE_MAY_ALIAS)
+# define drm_may_alias __attribute__((__may_alias__))
+#else
+# define drm_may_alias
+#endif
+
/**
* Static (compile-time) assertion.
diff --git a/xf86drmMode.c b/xf86drmMode.c
index fb22f68..a6bf5f7 100644
--- a/xf86drmMode.c
+++ b/xf86drmMode.c
@@ -52,6 +52,7 @@
#include
#include
+#include "libdrm_macros.h"
#include "xf86drmMode.h"
#include "xf86drm.h"
#include
@@ -885,9 +886,11 @@ int drmModeCrtcSetGamma(int fd, uint32_t crtc_id, uint32_t
size,
int drmHandleEvent(int fd, drmEventContextPtr evctx)
{
+ struct drm_event_aliased {
+ struct drm_event e;
+ } drm_may_alias *e;
char buffer[1024];
int len, i;
- struct drm_event *e;
struct drm_event_vblank *vblank;
/* The DRM read semantics guarantees that we always get only
@@ -901,8 +904,8 @@ int drmHandleEvent(int fd, drmEventContextPtr evctx)
i = 0;
while (i < len) {
- e = (struct drm_event *) [i];
- switch (e->type) {
+ e = (struct drm_event_aliased *) [i];
+ switch (e->e.type) {
case DRM_EVENT_VBLANK:
if (evctx->version < 1 ||
evctx->vblank_handler == NULL)
@@ -928,7 +931,7 @@ int drmHandleEvent(int fd, drmEventContextPtr evctx)
default:
break;
}
- i += e->length;
+ i += e->e.length;
}
return 0;
--
2.7.4
[PATCH libdrm] xf86drm: fix sign-compare warning
xf86drm.c:3601:21: warning: comparison between signed and unsigned integer
expressions [-Wsign-compare]
while (expected < sizeof(match)) {
^
Signed-off-by: Grazvydas Ignotas
---
xf86drm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xf86drm.c b/xf86drm.c
index 2e8c956..b5eeeb0 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -3582,7 +3582,7 @@ char *drmGetDeviceNameFromFd2(int fd)
FILE *f;
char buf[512];
static const char match[9] = "\nDEVNAME=";
-int expected = 1;
+size_t expected = 1;
if (fstat(fd, ))
--
2.7.4
[PATCH] drm: Simplify GETRESOURCES ioctl
On Sun, Dec 11, 2016 at 08:20:19PM +0100, Daniel Vetter wrote:
> Looping twice when we can do it once is silly. Also use a consistent
> style. Note that there's a good race with the connector list walking,
> since that is no longer protected by mode_config.mutex. But that's for
> a later patch to fix.
>
> v2: Actually try to not blow up, somehow I lost the hunk that checks
> we don't copy too much. Noticed by Chris.
>
> v3:
> - squash all drm_mode_getresources cleanups into one
> - use consistent style for walking objects (Chris)
>
> v4:
> - Use u64_to_user_ptr (Chris)
> - Don't forget to copy the last connector (Chris)
>
> v5: Chris was right ...
>
> Cc: Chris Wilson
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_mode_config.c | 111
> ++
> 1 file changed, 39 insertions(+), 72 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_mode_config.c
> b/drivers/gpu/drm/drm_mode_config.c
> index 2735a5847ffa..b1e8bbceaf39 100644
> --- a/drivers/gpu/drm/drm_mode_config.c
> +++ b/drivers/gpu/drm/drm_mode_config.c
> @@ -84,17 +84,11 @@ int drm_mode_getresources(struct drm_device *dev, void
> *data,
> struct drm_file *file_priv)
> {
> struct drm_mode_card_res *card_res = data;
> - struct list_head *lh;
> struct drm_framebuffer *fb;
> struct drm_connector *connector;
> struct drm_crtc *crtc;
> struct drm_encoder *encoder;
> - int ret = 0;
> - int connector_count = 0;
> - int crtc_count = 0;
> - int fb_count = 0;
> - int encoder_count = 0;
> - int copied = 0;
> + int count, ret = 0;
I'm down to a minor int but uABI uses u32. This being C, it all comes
out in the wash. One day we may have -Wsign-compare, but not today!
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing
https://bugs.freedesktop.org/show_bug.cgi?id=91880 --- Comment #141 from Chris Waters --- At what point did we go from talking about radeon, the driver this bug report is about, to amdgpu? Isn't support and performance for GCN 1.1 cards rather bad on amdgpu compared to radeon? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161211/c67253f1/attachment.html>
[PATCH 0/5] sphinxification for dma-buf docs
On Sun, Dec 11, 2016 at 4:11 PM, Jonathan Corbet wrote: > On Sun, 11 Dec 2016 13:35:49 +0100 > Daniel Vetter wrote: > >> > It seems like just the sort of thing we want to be doing to pull the docs >> > together in a more rational way. >> >> Ok if we pull this in through gfx trees? Will miss 4.10 though, that's >> already finished and in bugfix-only mode. > > I've pretty much closed up 4.10 as well. > > Here's a thought, though: how about if we slip in a little version of > dma-buf.rst now with a "coming soon, don't miss it!!" message? Then the > rest of the set could go through your tree without touching > driver-api/index.rst and, thus, avoiding the otherwise inevitable > conflicts? So just patch 1 still for 4.10 through your tree? Sounds good to me. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH] staging/android: remove Sync Framework tasks from TODO
Hi Gustavo, On 6 December 2016 at 23:55, Gustavo Padovan wrote: > From: Gustavo Padovan > > The destaging work is now fully complete. > Thanks for the patch, and your awesome work here :). > Cc: Arve Hjønnevåg > Cc: Riley Andrews > Signed-off-by: Gustavo Padovan FWIW, please feel free to add my Acked-by: Sumit Semwal to it. > --- > drivers/staging/android/TODO | 8 > 1 file changed, 8 deletions(-) > > diff --git a/drivers/staging/android/TODO b/drivers/staging/android/TODO > index 64d8c87..8f3ac37 100644 > --- a/drivers/staging/android/TODO > +++ b/drivers/staging/android/TODO > @@ -25,13 +25,5 @@ ion/ > exposes existing cma regions and doesn't reserve unecessarily memory when > booting a system which doesn't use ion. > > -sync framework: > - - remove CONFIG_SW_SYNC_USER, it is used only for testing/debugging and > - should not be upstreamed. > - - port CONFIG_SW_SYNC_USER tests interfaces to use debugfs somehow > - - port libsync tests to kselftest > - - clean up and ABI check for security issues > - - move it to drivers/base/dma-buf > - > Please send patches to Greg Kroah-Hartman and Cc: > Arve Hjønnevåg and Riley Andrews android.com> > -- > 2.5.5 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/5] sphinxification for dma-buf docs
Hi Daniel, On 10 December 2016 at 02:45, Jonathan Corbet wrote: > On Fri, 9 Dec 2016 19:53:04 +0100 > Daniel Vetter wrote: > >> Not yet everything in this area, I still want to sprinkle nice docs around >> all >> the fence code. Especially some text to explain implicit vs. explicit fencing >> and how it's all supposed to work. >> Thanks for the patch series; I had something in the works too, but you beat me to it! :) Looks good to me, so please feel free to add my Acked-by: Sumit Semwal to the series. >> But just cleanup in the dma-buf part was quite a bit of work, and I'd like to >> get feedback on that before moving on. > > No complaints here - except that I had to go looking around to find this > 0/5 posting explaining what the overall goal was...:) > > It seems like just the sort of thing we want to be doing to pull the docs > together in a more rational way. > > jon Best regards, Sumit.
[imx-drm] YUV on the first primary plane is misinterpreted as RGB
Hello, if the fb on the first primary plane has pixel format YUV, the planes was misinterpreted as RGB. The y-plane is red, the u-plane is green and the v-plane is blue. On the overlay plane it works right. But I need the overlay plane for OSD. I tested with linux-4.9-rc7 and pza/linux imx-drm/next on Matrix TBS2910. How can I change to crtc 29? There are also a primary and a overlay plane. Is anywhere a howto? Best regards Jens.
[PATCH] dma-buf: Provide wrappers for reservation's lock
On Tue, Nov 15, 2016 at 10:43:34PM +0100, Daniel Vetter wrote:
> On Tue, Nov 15, 2016 at 03:46:42PM +, Chris Wilson wrote:
> > Joonas complained that writing ww_mutex_lock(>lock, ctx) was too
> > intrusive compared to reservation_object_lock(resv, ctx);
> >
> > Signed-off-by: Chris Wilson
> > Cc: Sumit Semwal
> > Cc: Joonas Lahtinen
> > ---
> > include/linux/reservation.h | 34 ++
> > 1 file changed, 34 insertions(+)
> >
> > diff --git a/include/linux/reservation.h b/include/linux/reservation.h
> > index ed238961e1bf..9cfc0d857862 100644
> > --- a/include/linux/reservation.h
> > +++ b/include/linux/reservation.h
> > @@ -129,6 +129,40 @@ reservation_object_fini(struct reservation_object *obj)
> > }
> >
> > /**
> > + * reservation_object_lock - lock the reservation object
> > + * @obj: the reservation object
> > + * @ctx: the locking context
> > + *
> > + * Locks the reservation object for exclusive access and modification.
> > Note,
> > + * that the lock is only against other writers, readers will run
> > concurrently
> > + * with a writer under RCU. The seqlock is used to notify readers if they
> > + * overlap with a writer.
> > + *
> > + * As the reservation object may be locked by multiple parties in an
> > + * undefined order, a #ww_acquire_ctx is passed to unwind if a cycle
>
> s/#/&/ for struct references. Otherwise the magic hotlink won't appear
> (once we get around to pulling all the core docs into the overall sphinx
> build). I can fix this while applying if everyone else is ok with the
> patch - imo it makes sense.
Anyone want to second these ww_mutex wrappers for reservation objects?
> > + * is detected. See ww_mutex_lock() and ww_acquire_init(). A reservation
> > + * object may be locked by itself by passing NULL as @ctx.
> > + */
> > +static inline int
> > +reservation_object_lock(struct reservation_object *obj,
> > + struct ww_acquire_ctx *ctx)
> > +{
> > + return ww_mutex_lock(>lock, ctx);
> > +}
> > +
> > +/**
> > + * reservation_object_unlock - unlock the reservation object
> > + * @obj: the reservation object
> > + *
> > + * Unlocks the reservation object following exclusive access.
> > + */
> > +static inline void
> > +reservation_object_unlock(struct reservation_object *obj)
> > +{
> > + ww_mutex_unlock(>lock);
> > +}
> > +
> > +/**
> > * reservation_object_get_excl - get the reservation object's
> > * exclusive fence, with update-side lock held
> > * @obj: the reservation object
--
Chris Wilson, Intel Open Source Technology Centre
[Bug 51381] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting, when disabled via vgaswitcheroo
https://bugzilla.kernel.org/show_bug.cgi?id=51381 luminoso changed: What|Removed |Added CC||luminoso at gmail.com --- Comment #51 from luminoso --- System is kernel 4.9.0-RC8, Fedora 25, "[AMD/ATI] Venus PRO [Radeon HD 8850M / R9 M265X]" Some other bug pushed me to boot kernel with radeon.rumpm=0 at boot. I noticied that I had this ATOM bios stuck when trying to turn ON the graphic card due to laptop power usage being to high. turn off is "echo OFF | sudo tee /sys/kernel/debug/vgaswitcheroo/switch turn on is "echo OFF | sudo tee /sys/kernel/debug/vgaswitcheroo/switch" my switch looks like this: 0:IGD:+:Pwr::00:02.0 1:DIS: :Off::01:00.0 Power usage is reported by powertop. Low means ~12w and high means ~17w So, the test cases are: 1) Boot, turn off AMD. Power usage is LOW Suspend and resume. Power usage is now high. Switch reports OFF. 2) Boot, turn off AMD. Power usage is LOW Suspend and resume. Power usage is now high. Switch reports OFF. Turn on the GPU takes a long time and throws atom bios stuck error. Turning it off again reduces usage almost to low but my laptop fans are a bit crazy. 3) Boot, turn off AMD. Power usage is LOW Before suspending turn ON via systemd hook. Suspend and resume. After suspend turn OFF via systemd hook. No errors in dmesg. Power usage is low. No delays. So 3) is the perfect solution where everything works as expected with just and quick workaround. Probably my GPU doesn't support turn ON after suspending and my laptop should suspend with GPU turned on. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 98298] System freezes 380X
https://bugs.freedesktop.org/show_bug.cgi?id=98298 kuehner.moritz at gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161211/013a80bb/attachment.html>
[Bug 98298] System freezes 380X
https://bugs.freedesktop.org/show_bug.cgi?id=98298 --- Comment #2 from kuehner.moritz at gmail.com --- I got my money back from the retailer. Therefor I think I can assume a hardware defect was the case. So this bug can be closed. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161211/d008f5ee/attachment.html>
[PATCH] dma-buf: Provide wrappers for reservation's lock
On Sun, Dec 11, 2016 at 12:12 PM, Chris Wilson
wrote:
> On Tue, Nov 15, 2016 at 10:43:34PM +0100, Daniel Vetter wrote:
>> On Tue, Nov 15, 2016 at 03:46:42PM +, Chris Wilson wrote:
>> > Joonas complained that writing ww_mutex_lock(>lock, ctx) was too
>> > intrusive compared to reservation_object_lock(resv, ctx);
>> >
>> > Signed-off-by: Chris Wilson
>> > Cc: Sumit Semwal
>> > Cc: Joonas Lahtinen
>> > ---
>> > include/linux/reservation.h | 34 ++
>> > 1 file changed, 34 insertions(+)
>> >
>> > diff --git a/include/linux/reservation.h b/include/linux/reservation.h
>> > index ed238961e1bf..9cfc0d857862 100644
>> > --- a/include/linux/reservation.h
>> > +++ b/include/linux/reservation.h
>> > @@ -129,6 +129,40 @@ reservation_object_fini(struct reservation_object
>> > *obj)
>> > }
>> >
>> > /**
>> > + * reservation_object_lock - lock the reservation object
>> > + * @obj: the reservation object
>> > + * @ctx: the locking context
>> > + *
>> > + * Locks the reservation object for exclusive access and modification.
>> > Note,
>> > + * that the lock is only against other writers, readers will run
>> > concurrently
>> > + * with a writer under RCU. The seqlock is used to notify readers if they
>> > + * overlap with a writer.
>> > + *
>> > + * As the reservation object may be locked by multiple parties in an
>> > + * undefined order, a #ww_acquire_ctx is passed to unwind if a cycle
>>
>> s/#/&/ for struct references. Otherwise the magic hotlink won't appear
>> (once we get around to pulling all the core docs into the overall sphinx
>> build). I can fix this while applying if everyone else is ok with the
>> patch - imo it makes sense.
>
> Anyone want to second these ww_mutex wrappers for reservation objects?
Looks good to me.
Reviewed-by: Alex Deucher
>
>> > + * is detected. See ww_mutex_lock() and ww_acquire_init(). A reservation
>> > + * object may be locked by itself by passing NULL as @ctx.
>> > + */
>> > +static inline int
>> > +reservation_object_lock(struct reservation_object *obj,
>> > + struct ww_acquire_ctx *ctx)
>> > +{
>> > + return ww_mutex_lock(>lock, ctx);
>> > +}
>> > +
>> > +/**
>> > + * reservation_object_unlock - unlock the reservation object
>> > + * @obj: the reservation object
>> > + *
>> > + * Unlocks the reservation object following exclusive access.
>> > + */
>> > +static inline void
>> > +reservation_object_unlock(struct reservation_object *obj)
>> > +{
>> > + ww_mutex_unlock(>lock);
>> > +}
>> > +
>> > +/**
>> > * reservation_object_get_excl - get the reservation object's
>> > * exclusive fence, with update-side lock held
>> > * @obj: the reservation object
>
> --
> Chris Wilson, Intel Open Source Technology Centre
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] ASoC: hdmi-codec: add channel mapping control
On Dec 9 2016 01:37, Arnaud Pouliquen wrote:
> Add user interface to provide channel mapping.
> In a first step this control is read only.
>
> As TLV type, the control provides all configurations available for
> HDMI sink(ELD), and provides current channel mapping selected by codec
> based on ELD and number of channels specified by user on open.
> When control is called before the number of the channel is specified
> (i.e. hw_params is set), it returns all channels set to UNKNOWN.
>
> Notice that SNDRV_CTL_TLVT_CHMAP_FIXED is used for all mappings,
> as no information is available from HDMI driver to allow channel swapping.
>
> Signed-off-by: Arnaud Pouliquen
> ---
> sound/soc/codecs/hdmi-codec.c | 346
> +-
> 1 file changed, 345 insertions(+), 1 deletion(-)
>
> diff --git a/sound/soc/codecs/hdmi-codec.c b/sound/soc/codecs/hdmi-codec.c
> index f27d115..0cb83a3 100644
> --- a/sound/soc/codecs/hdmi-codec.c
> +++ b/sound/soc/codecs/hdmi-codec.c
> @@ -18,12 +18,137 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
>
> #include /* This is only to get MAX_ELD_BYTES */
>
> +#define HDMI_MAX_SPEAKERS 8
> +
> +/*
> + * CEA speaker placement for HDMI 1.4:
> + *
> + * FL FLC FC FRC FR FRW
> + *
> + * LFE
> + *
> + * RL RLC RC RRC RR
> + *
> + * Speaker placement has to be extended to support HDMI 2.0
> + */
> +enum hdmi_codec_cea_spk_placement {
> + FL = (1 << 0),/* Front Left */
> + FC = (1 << 1),/* Front Center */
> + FR = (1 << 2),/* Front Right */
> + FLC = (1 << 3),/* Front Left Center*/
> + FRC = (1 << 4),/* Front Right Center */
> + RL = (1 << 5),/* Rear Left*/
> + RC = (1 << 6),/* Rear Center */
> + RR = (1 << 7),/* Rear Right */
> + RLC = (1 << 8),/* Rear Left Center */
> + RRC = (1 << 9),/* Rear Right Center*/
> + LFE = (1 << 10),/* Low Frequency Effect */
> +};
BIT() macro in "linux/bitops.h" is available.
> +
> +/*
> + * ELD Speaker allocation bits in the CEA Speaker Allocation data block
> + */
> +static int hdmi_codec_eld_spk_alloc_bits[] = {
> + [0] = FL | FR,
> + [1] = LFE,
> + [2] = FC,
> + [3] = RL | RR,
> + [4] = RC,
> + [5] = FLC | FRC,
> + [6] = RLC | RRC,
> +};
Please put this kind of invariant table into .rodata section with
'const' modifier.
> +
> +struct hdmi_codec_channel_map_table {
> + unsigned char map; /* ALSA API channel map position */
> + int spk_mask; /* speaker position bit mask */
> +};
> +
> +static struct hdmi_codec_channel_map_table hdmi_codec_map_table[] = {
> + { SNDRV_CHMAP_FL, FL },
> + { SNDRV_CHMAP_FR, FR },
> + { SNDRV_CHMAP_RL, RL },
> + { SNDRV_CHMAP_RR, RR },
> + { SNDRV_CHMAP_LFE, LFE },
> + { SNDRV_CHMAP_FC, FC },
> + { SNDRV_CHMAP_RLC, RLC },
> + { SNDRV_CHMAP_RRC, RRC },
> + { SNDRV_CHMAP_RC, RC },
> + { SNDRV_CHMAP_FLC, FLC },
> + { SNDRV_CHMAP_FRC, FRC },
> + {} /* terminator */
> +};
In this case, the table can be put into snd_hdac_spk_to_chmap().
> +
> +/*
> + * cea Speaker allocation structure
> + */
> +struct hdmi_codec_cea_spk_alloc {
> + int ca_index;
> + int speakers[HDMI_MAX_SPEAKERS];
> +
> + /* Derived values, computed during init */
> + int channels;
> + int spk_mask;
> + int spk_na_mask;
> +};
> +
> +/*
> + * This is an ordered list!
> + *
> + * The preceding ones have better chances to be selected by
> + * hdmi_channel_allocation().
The function is not defined and implemented. It takes developers to be
puzzled.
> + */
> +static struct hdmi_codec_cea_spk_alloc hdmi_codec_channel_alloc[] = {
> +/* channel: 7 6543 210 */
> +{ .ca_index = 0x00, .speakers = { 0,0, 0, 0, 0,0, FR, FL
> } },
> + /* 2.1 */
> +{ .ca_index = 0x01, .speakers = { 0,0, 0, 0, 0, LFE, FR, FL
> } },
> + /* Dolby Surround */
> +{ .ca_index = 0x02, .speakers = { 0,0, 0, 0, FC,0, FR, FL
> } },
> + /* surround51 */
> +{ .ca_index = 0x0b, .speakers = { 0,0, RR, RL, FC, LFE, FR, FL
> } },
> + /* surround40 */
> +{ .ca_index = 0x08, .speakers = { 0,0, RR, RL, 0,0, FR, FL
> } },
> + /* surround41 */
> +{ .ca_index = 0x09, .speakers = { 0,0, RR, RL, 0, LFE, FR, FL
> } },
> + /* surround50 */
> +{ .ca_index = 0x0a, .speakers = { 0,0, RR, RL, FC,0, FR, FL
> } },
> + /* 6.1 */
> +{
[PATCH] drm: Simplify GETRESOURCES ioctl
On Sun, Dec 11, 2016 at 01:39:15PM +0100, Daniel Vetter wrote:
> + count = 0;
> + fb_id = u64_to_user_ptr(card_res->fb_id_ptr);
> + list_for_each_entry(fb, _priv->fbs, filp_head) {
> + count++;
> + if (count > card_res->count_fbs)
> + continue;
> +
> + if (put_user(fb->base.id, fb_id + count)) {
On the first iteration what is the value of count here?
What should it be?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
[PATCH 1/5] dma-buf: Extract dma-buf.rst
On Fri, 9 Dec 2016 19:53:05 +0100
Daniel Vetter wrote:
> Just prep work to polish and consolidate all the dma-buf related
> documenation.
>
> Unfortunately I didn't discover a way to both integrate this new file
> into the overall toc while keeping it at the current place. Work
> around that by moving it into the overall driver-api/index.rst.
OK, I've applied this, with one change:
> diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
> index d51a7d23c358..c683c4e908d2 100644
> --- a/include/linux/dma-fence.h
> +++ b/include/linux/dma-fence.h
> @@ -163,7 +163,6 @@ struct dma_fence_cb {
> * destruction of the fence. Can be called from irq context.
> * If pointer is set to NULL, kfree will get called instead.
> */
> -
> struct dma_fence_ops {
> const char * (*get_driver_name)(struct dma_fence *fence);
> const char * (*get_timeline_name)(struct dma_fence *fence);
This hunk didn't apply to my tree, but I figured that, under duress, we
could probably manage to do without it for now...:)
jon
[PATCH] drm: Simplify GETRESOURCES ioctl
Looping twice when we can do it once is silly. Also use a consistent
style. Note that there's a good race with the connector list walking,
since that is no longer protected by mode_config.mutex. But that's for
a later patch to fix.
v2: Actually try to not blow up, somehow I lost the hunk that checks
we don't copy too much. Noticed by Chris.
v3:
- squash all drm_mode_getresources cleanups into one
- use consistent style for walking objects (Chris)
v4:
- Use u64_to_user_ptr (Chris)
- Don't forget to copy the last connector (Chris)
Cc: Chris Wilson
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_mode_config.c | 119 +++---
1 file changed, 47 insertions(+), 72 deletions(-)
diff --git a/drivers/gpu/drm/drm_mode_config.c
b/drivers/gpu/drm/drm_mode_config.c
index 2735a5847ffa..3e6952142974 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -84,17 +84,11 @@ int drm_mode_getresources(struct drm_device *dev, void
*data,
struct drm_file *file_priv)
{
struct drm_mode_card_res *card_res = data;
- struct list_head *lh;
struct drm_framebuffer *fb;
struct drm_connector *connector;
struct drm_crtc *crtc;
struct drm_encoder *encoder;
- int ret = 0;
- int connector_count = 0;
- int crtc_count = 0;
- int fb_count = 0;
- int encoder_count = 0;
- int copied = 0;
+ int count, ret = 0;
uint32_t __user *fb_id;
uint32_t __user *crtc_id;
uint32_t __user *connector_id;
@@ -105,89 +99,70 @@ int drm_mode_getresources(struct drm_device *dev, void
*data,
mutex_lock(_priv->fbs_lock);
- /*
-* For the non-control nodes we need to limit the list of resources
-* by IDs in the group list for this node
-*/
- list_for_each(lh, _priv->fbs)
- fb_count++;
-
- /* handle this in 4 parts */
- /* FBs */
- if (card_res->count_fbs >= fb_count) {
- copied = 0;
- fb_id = (uint32_t __user *)(unsigned long)card_res->fb_id_ptr;
- list_for_each_entry(fb, _priv->fbs, filp_head) {
- if (put_user(fb->base.id, fb_id + copied)) {
- mutex_unlock(_priv->fbs_lock);
- return -EFAULT;
- }
- copied++;
+ count = 0;
+ fb_id = u64_to_user_ptr(card_res->fb_id_ptr);
+ list_for_each_entry(fb, _priv->fbs, filp_head) {
+ count++;
+ if (count > card_res->count_fbs)
+ continue;
+
+ if (put_user(fb->base.id, fb_id + count)) {
+ mutex_unlock(_priv->fbs_lock);
+ return -EFAULT;
}
}
- card_res->count_fbs = fb_count;
+ card_res->count_fbs = count;
mutex_unlock(_priv->fbs_lock);
/* mode_config.mutex protects the connector list against e.g. DP MST
* connector hot-adding. CRTC/Plane lists are invariant. */
mutex_lock(>mode_config.mutex);
- drm_for_each_crtc(crtc, dev)
- crtc_count++;
-
- drm_for_each_connector(connector, dev)
- connector_count++;
-
- drm_for_each_encoder(encoder, dev)
- encoder_count++;
-
card_res->max_height = dev->mode_config.max_height;
card_res->min_height = dev->mode_config.min_height;
card_res->max_width = dev->mode_config.max_width;
card_res->min_width = dev->mode_config.min_width;
- /* CRTCs */
- if (card_res->count_crtcs >= crtc_count) {
- copied = 0;
- crtc_id = (uint32_t __user *)(unsigned
long)card_res->crtc_id_ptr;
- drm_for_each_crtc(crtc, dev) {
- if (put_user(crtc->base.id, crtc_id + copied)) {
- ret = -EFAULT;
- goto out;
- }
- copied++;
+ count = 0;
+ crtc_id = u64_to_user_ptr(card_res->crtc_id_ptr);
+ drm_for_each_crtc(crtc, dev) {
+ count++;
+ if (count > card_res->count_crtcs)
+ continue;
+
+ if (put_user(crtc->base.id, crtc_id + count)) {
+ ret = -EFAULT;
+ goto out;
}
}
- card_res->count_crtcs = crtc_count;
-
- /* Encoders */
- if (card_res->count_encoders >= encoder_count) {
- copied = 0;
- encoder_id = (uint32_t __user *)(unsigned
long)card_res->encoder_id_ptr;
- drm_for_each_encoder(encoder, dev) {
- if (put_user(encoder->base.id, encoder_id +
-copied)) {
- ret = -EFAULT;
- goto out;
-
[PATCH 0/5] sphinxification for dma-buf docs
On Fri, Dec 9, 2016 at 10:15 PM, Jonathan Corbet wrote: > On Fri, 9 Dec 2016 19:53:04 +0100 > Daniel Vetter wrote: > >> Not yet everything in this area, I still want to sprinkle nice docs around >> all >> the fence code. Especially some text to explain implicit vs. explicit fencing >> and how it's all supposed to work. >> >> But just cleanup in the dma-buf part was quite a bit of work, and I'd like to >> get feedback on that before moving on. > > No complaints here - except that I had to go looking around to find this > 0/5 posting explaining what the overall goal was...:) > > It seems like just the sort of thing we want to be doing to pull the docs > together in a more rational way. Ok if we pull this in through gfx trees? Will miss 4.10 though, that's already finished and in bugfix-only mode. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[RFC] Using DC in amdgpu for upcoming GPU
On Fri, Dec 9, 2016 at 9:34 PM, Dave Airlie airlied at gmail.com> wrote: > On 10 December 2016 at 05:59, Daniel Vetter wrote: >> I guess things went a bit sideways by me and Dave only talking about >> the midlayer, so let me first state that the DC stuff has massively >> improved through replacing all the backend services that reimplemented >> Linux helper libraries with their native equivalent. That's some >> serious work, and it shows that AMD is committed to doing the right >> thing. >> >> I absolutely didn't want to belittle all that effort by only raising >> what I see is the one holdover left. > > I see myself and Daniel have kinda fallen into good-cop, bad-cop mode. > > I agree with everything Daniel had said in here, and come next week I might > try and write something more constructive up, but believe me Daniel is totally > right! It's Saturday morning, I've got a weekend to deal with and I'm going to > try and avoid thinking too much about this. Yeah I'm pondering what a reasonable action plan for dc from an atomic pov is too. One issue we have is that right now the atomic docs are a bit lacking for large-scale/design issues. But I'm working on this (hopefully happens soonish, we need it for intel projects too), both pulling the original atomic design stuff from my blog into docs and beat into shape. And also how to handle state and atomic_check/commit for when you want a state model that goes massively beyond what's there with just drm_plane/crtc/connector_state (like e.g. i915 has). But instead of me typing this up in this thread here and then getting lost again (hopefully amdgpu/dc is not the last full-featured driver we'll get ...) I think it's better if I type this up for the drm docs and ask Harry/Tony for review feedback. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH] treewide: Make remaining source files non-executable
.c and .h source files should not be executable, change the permissions to 0644. Signed-off-by: Joe Perches --- drivers/gpu/drm/amd/include/asic_reg/dce/dce_11_2_d.h | 0 drivers/gpu/drm/amd/include/asic_reg/dce/dce_11_2_sh_mask.h | 0 drivers/gpu/drm/amd/include/cgs_common.h| 0 drivers/gpu/drm/amd/powerplay/smumgr/fiji_smumgr.c | 0 scripts/sign-file.c | 0 5 files changed, 0 insertions(+), 0 deletions(-) mode change 100755 => 100644 drivers/gpu/drm/amd/include/asic_reg/dce/dce_11_2_d.h mode change 100755 => 100644 drivers/gpu/drm/amd/include/asic_reg/dce/dce_11_2_sh_mask.h mode change 100755 => 100644 drivers/gpu/drm/amd/include/cgs_common.h mode change 100755 => 100644 drivers/gpu/drm/amd/powerplay/smumgr/fiji_smumgr.c mode change 100755 => 100644 scripts/sign-file.c diff --git a/drivers/gpu/drm/amd/include/asic_reg/dce/dce_11_2_d.h b/drivers/gpu/drm/amd/include/asic_reg/dce/dce_11_2_d.h old mode 100755 new mode 100644 diff --git a/drivers/gpu/drm/amd/include/asic_reg/dce/dce_11_2_sh_mask.h b/drivers/gpu/drm/amd/include/asic_reg/dce/dce_11_2_sh_mask.h old mode 100755 new mode 100644 diff --git a/drivers/gpu/drm/amd/include/cgs_common.h b/drivers/gpu/drm/amd/include/cgs_common.h old mode 100755 new mode 100644 diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smumgr.c b/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smumgr.c old mode 100755 new mode 100644 diff --git a/scripts/sign-file.c b/scripts/sign-file.c old mode 100755 new mode 100644 -- 2.10.0.rc2.1.g053435c
[PATCH 0/5] sphinxification for dma-buf docs
On Sun, 11 Dec 2016 18:35:42 +0100 Daniel Vetter wrote: > > Here's a thought, though: how about if we slip in a little version of > > dma-buf.rst now with a "coming soon, don't miss it!!" message? Then the > > rest of the set could go through your tree without touching > > driver-api/index.rst and, thus, avoiding the otherwise inevitable > > conflicts? > > So just patch 1 still for 4.10 through your tree? Sounds good to me. Yeah, that will work just fine, I'll slip it in. Thanks, jon
[PATCH 4/4] drm: Simplify GETRESOURCES ioctl
On Sat, Dec 10, 2016 at 11:04 PM, Chris Wilson
wrote:
>> + list_for_each_entry(fb, _priv->fbs, filp_head) {
>> + count++;
>> + if (count > card_res->count_fbs)
>> + continue;
>> +
>> + if (put_user(fb->base.id, fb_id + count)) {
>
> In this style increment of count has to happen after the copy.
>
> i.e.
> if (count < card_res->count_fbs &&
> put_user(fb->base.id, fb_id + count) {
> mutex_unlock()
> return -EFAULT;
> }
> count++;
Note I also have > instead of <, so I think it should be equivalent.
Oops except for the connector lop, silly me that lost one.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing
https://bugs.freedesktop.org/show_bug.cgi?id=91880 --- Comment #140 from Jan Ziak <0xe2.0x9a.0x9b at gmail.com> --- (In reply to Chris Waters from comment #139) > Tried Manjaro and an install of Ubuntu MATE with a ppa for mesa-git drivers. > No pp_dpm_sclk in either. > > Am I missing something? Manjaro (both stable and development) is running on Linux kernel 4.4. Ubuntu MATE 16.10 is running on Linux kernel 4.8.0, but it has CONFIG_DRM_AMDGPU_CIK disabled in kernel configuration and is loading radeon.ko instead of amdgpu.ko. The following 3 commands can be used to check whether amdgpu+CIK are enabled: $ uname -r 4.8.0 (or later version) $ lsmod | grep amdgpu amdgpu $ zgrep CIK /proc/config.gz CONFIG_DRM_AMDGPU_CIK=y An alternative form of the last command: $ grep CIK /boot/config-$(uname -r) CONFIG_DRM_AMDGPU_CIK=y -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161211/0e00b570/attachment-0001.html>
[PATCH 0/2] Generic HDMI codec: Add channel mapping control
On Dec 9 2016 23:06, Arnaud Pouliquen wrote: >> Anyway, we're mostly on the end of development for 4.10 cycle, and the >> review process for new feature might be delay till 4.10-rc1 release, two >> weeks later. During the weeks. bug fixes are preferable to be applied. > > Thank you for warning me. No problem for the delay, i fully understand > that focus is on bug fixes. > Notice that it is quite difficult for developers to find the best timing > to address this kind of patch, as integration process is not always > simple to follow... this probably come with experience. ALSA is a development project for sound subsystem of Linux operating system, and our work is a part of Linux kernel. Therefore, it's better to follow generic behavior in Linux kernel development. > So if i well understand your remark the best windows to integrate a > feature for the version N+1, is to propose patch from N-rc1 tag. > (expecting that patch-set is enough mature to be integrated in N+1...) It's a better way if you're aware of maintainers' work and your task allows you to do things steadily. Regards Takashi Sakamoto
[Bug 60879] [radeonsi] Tahiti LE: GFX block is not functional, CP is okay
https://bugs.freedesktop.org/show_bug.cgi?id=60879 --- Comment #162 from John Steele Scott --- I just bit the bullet and swapped out my Radeon HD 7870 XT for an RX 480 due to this issue. I'll happily donate the 7870 to any developer who would like to put it to use fixing this bug. Get in touch in the next week or so if interested. Otherwise I'll try and sell it before Christmas, it's still a good card for Windows gaming. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161211/8e55ea95/attachment.html>
[Bug 99051] Pillars of Eternity won't start on AMD Radeon mesa
https://bugs.freedesktop.org/show_bug.cgi?id=99051 Bug ID: 99051 Summary: Pillars of Eternity won't start on AMD Radeon mesa Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: darekdeoniziak at gmail.com QA Contact: dri-devel at lists.freedesktop.org Created attachment 128409 --> https://bugs.freedesktop.org/attachment.cgi?id=128409=edit game log and system specs in zip file Issue happens on Ubuntu 16.04 using oibaf PPA (https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers) game doesn't start on AMD gpu. Before last updates (at least a month ago) it worked without issues. Here are my system specs and logs from game, although I think there are no error logs until game is loaded which doesn't happen (tested by removing log file and running game, no new log was generated). https://dl.dropboxusercontent.com/u/88194181/poe_radeon_linux_issue_files.zip Related thread on Pillars of Eternity forums with more info: http://forums.obsidian.net/topic/90525-linux-radensi-wont-start/ -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161211/81e00e07/attachment.html>
[PATCH 0/5] sphinxification for dma-buf docs
On Sun, 11 Dec 2016 13:35:49 +0100 Daniel Vetter wrote: > > It seems like just the sort of thing we want to be doing to pull the docs > > together in a more rational way. > > Ok if we pull this in through gfx trees? Will miss 4.10 though, that's > already finished and in bugfix-only mode. I've pretty much closed up 4.10 as well. Here's a thought, though: how about if we slip in a little version of dma-buf.rst now with a "coming soon, don't miss it!!" message? Then the rest of the set could go through your tree without touching driver-api/index.rst and, thus, avoiding the otherwise inevitable conflicts? jon
[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing
https://bugs.freedesktop.org/show_bug.cgi?id=91880 --- Comment #139 from Chris Waters --- Tried Manjaro and an install of Ubuntu MATE with a ppa for mesa-git drivers. No pp_dpm_sclk in either. Am I missing something? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161211/440b1e6f/attachment.html>
[Bug 93649] [radeonsi] Graphics lockup while playing tf2
https://bugs.freedesktop.org/show_bug.cgi?id=93649 --- Comment #76 from Amarildo --- (In reply to null32 from comment #75) > (In reply to hofmann.zachary from comment #73) > > One hour is not enough testing. I applied this patch to mesa 13.0.2 and the > > game still locks up. > > Make sure you're using a patched version of the 32 bit libraries too. I > managed to play almost 3 hours in a row in a full server and in different > maps without issues at all. > > These are the packages that I'm using: > > * linux 4.8.12-2 > * linux-firmware 20161005.9c71af9-1 > > * mesa-git 13.1.0_devel.87233.bd56de8-1 > * lib32-mesa-git 13.1.0_devel.87233.bd56de8-1 > > * llvm-svn 4.0.0svn_r289147-1 > * lib32-llvm-svn 4.0.0svn_r289117-1 He confirmed it working :D https://github.com/ValveSoftware/Source-1-Games/issues/1943#issuecomment-266251699 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161211/18ac074f/attachment.html>
[Intel-gfx] [PATCH] drm: Make each driver's struct_mutex its own subclass
'desc' include/drm/drm_drv.h:415: warning: No description found for parameter 'date' include/drm/drm_drv.h:415: warning: No description found for parameter 'driver_features' include/drm/drm_drv.h:415: warning: No description found for parameter 'dev_priv_size' include/drm/drm_drv.h:415: warning: No description found for parameter 'ioctls' include/drm/drm_drv.h:415: warning: No description found for parameter 'num_ioctls' include/drm/drm_drv.h:415: warning: No description found for parameter 'fops' include/drm/drm_drv.h:415: warning: No description found for parameter 'legacy_dev_list' include/media/media-entity.h:1054: warning: No description found for parameter '...' include/net/mac80211.h:3207: ERROR: Unexpected indentation. include/net/mac80211.h:3210: WARNING: Block quote ends without a blank line; unexpected unindent. include/net/mac80211.h:3212: ERROR: Unexpected indentation. include/net/mac80211.h:3213: WARNING: Block quote ends without a blank line; unexpected unindent. include/net/mac80211.h:1772: ERROR: Unexpected indentation. include/net/mac80211.h:1776: WARNING: Block quote ends without a blank line; unexpected unindent. kernel/sched/fair.c:7259: WARNING: Inline emphasis start-string without end-string. kernel/time/timer.c:1240: ERROR: Unexpected indentation. kernel/time/timer.c:1242: ERROR: Unexpected indentation. kernel/time/timer.c:1243: WARNING: Block quote ends without a blank line; unexpected unindent. include/linux/wait.h:121: WARNING: Block quote ends without a blank line; unexpected unindent. include/linux/wait.h:124: ERROR: Unexpected indentation. include/linux/wait.h:126: WARNING: Block quote ends without a blank line; unexpected unindent. kernel/time/hrtimer.c:1021: WARNING: Block quote ends without a blank line; unexpected unindent. kernel/signal.c:317: WARNING: Inline literal start-string without end-string. drivers/base/firmware_class.c:1348: WARNING: Bullet list ends without a blank line; unexpected unindent. drivers/message/fusion/mptbase.c:5054: WARNING: Definition list ends without a blank line; unexpected unindent. drivers/tty/serial/serial_core.c:1893: WARNING: Definition list ends without a blank line; unexpected unindent. include/linux/spi/spi.h:369: ERROR: Unexpected indentation. WARNING: dvipng command 'dvipng' cannot be run (needed for math display), check the imgmath_dvipng setting vim +/class +415 include/drm/drm_drv.h 85e634bc Daniel Vetter 2016-11-14 399 int major; 85e634bc Daniel Vetter 2016-11-14 400 int minor; 85e634bc Daniel Vetter 2016-11-14 401 int patchlevel; 85e634bc Daniel Vetter 2016-11-14 402 char *name; 85e634bc Daniel Vetter 2016-11-14 403 char *desc; 85e634bc Daniel Vetter 2016-11-14 404 char *date; 85e634bc Daniel Vetter 2016-11-14 405 85e634bc Daniel Vetter 2016-11-14 406 u32 driver_features; 85e634bc Daniel Vetter 2016-11-14 407 int dev_priv_size; 85e634bc Daniel Vetter 2016-11-14 408 const struct drm_ioctl_desc *ioctls; 85e634bc Daniel Vetter 2016-11-14 409 int num_ioctls; 85e634bc Daniel Vetter 2016-11-14 410 const struct file_operations *fops; 85e634bc Daniel Vetter 2016-11-14 411 85e634bc Daniel Vetter 2016-11-14 412 /* List of devices hanging off this driver with stealth attach. */ 85e634bc Daniel Vetter 2016-11-14 413 struct list_head legacy_dev_list; 85e634bc Daniel Vetter 2016-11-14 414 }; 85e634bc Daniel Vetter 2016-11-14 @415 85e634bc Daniel Vetter 2016-11-14 416 extern __printf(6, 7) 85e634bc Daniel Vetter 2016-11-14 417 void drm_dev_printk(const struct device *dev, const char *level, 85e634bc Daniel Vetter 2016-11-14 418 unsigned int category, const char *function_name, 85e634bc Daniel Vetter 2016-11-14 419 const char *prefix, const char *format, ...); 85e634bc Daniel Vetter 2016-11-14 420 extern __printf(3, 4) 85e634bc Daniel Vetter 2016-11-14 421 void drm_printk(const char *level, unsigned int category, 85e634bc Daniel Vetter 2016-11-14 422 const char *format, ...); 85e634bc Daniel Vetter 2016-11-14 423 extern unsigned int drm_debug; :: The code at line 415 was first introduced by commit :: 85e634bce01af582a0fa549c904154b0e3c56db5 drm: Extract drm_drv.h :: TO: Daniel Vetter :: CC: Daniel Vetter --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation -- next part -- A non-text attachment was scrubbed... Name: .config.gz Type: application/gzip Size: 6425 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161211/45eba6ba/attachment.gz>
