[PATCH 1/2] drm: armada: Remove custom .dumb_destroy() handler

[Laurent Pinchart]

The custom implementation just calls drm_gem_handle_delete(), which is
identical to the default implementation used when the operation handler
isn't set. Remove it.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/armada/armada_drv.c | 1 -
 drivers/gpu/drm/armada/armada_gem.c | 6 --
 drivers/gpu/drm/armada/armada_gem.h | 2 --
 3 files changed, 9 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_drv.c 
b/drivers/gpu/drm/armada/armada_drv.c
index 0b3227c039d7..8a37b9a66dbc 100644
--- a/drivers/gpu/drm/armada/armada_drv.c
+++ b/drivers/gpu/drm/armada/armada_drv.c
@@ -71,7 +71,6 @@ static struct drm_driver armada_drm_driver = {
.gem_prime_import   = armada_gem_prime_import,
.dumb_create= armada_gem_dumb_create,
.dumb_map_offset= armada_gem_dumb_map_offset,
-   .dumb_destroy   = armada_gem_dumb_destroy,
.gem_vm_ops = _gem_vm_ops,
.major  = 1,
.minor  = 0,
diff --git a/drivers/gpu/drm/armada/armada_gem.c 
b/drivers/gpu/drm/armada/armada_gem.c
index a76ca21d063b..9d69132bbeda 100644
--- a/drivers/gpu/drm/armada/armada_gem.c
+++ b/drivers/gpu/drm/armada/armada_gem.c
@@ -300,12 +300,6 @@ int armada_gem_dumb_map_offset(struct drm_file *file, 
struct drm_device *dev,
return ret;
 }
 
-int armada_gem_dumb_destroy(struct drm_file *file, struct drm_device *dev,
-   uint32_t handle)
-{
-   return drm_gem_handle_delete(file, handle);
-}
-
 /* Private driver gem ioctls */
 int armada_gem_create_ioctl(struct drm_device *dev, void *data,
struct drm_file *file)
diff --git a/drivers/gpu/drm/armada/armada_gem.h 
b/drivers/gpu/drm/armada/armada_gem.h
index 6e524e0676bb..78d5690b699b 100644
--- a/drivers/gpu/drm/armada/armada_gem.h
+++ b/drivers/gpu/drm/armada/armada_gem.h
@@ -37,8 +37,6 @@ int armada_gem_dumb_create(struct drm_file *, struct 
drm_device *,
struct drm_mode_create_dumb *);
 int armada_gem_dumb_map_offset(struct drm_file *, struct drm_device *,
uint32_t, uint64_t *);
-int armada_gem_dumb_destroy(struct drm_file *, struct drm_device *,
-   uint32_t);
 struct dma_buf *armada_gem_prime_export(struct drm_device *dev,
struct drm_gem_object *obj, int flags);
 struct drm_gem_object *armada_gem_prime_import(struct drm_device *,
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] drm: Don't export the drm_gem_dumb_destroy() function

[Laurent Pinchart]

The drm_gem_dumb_destroy() isn't used in drivers, don't export it.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/drm_dumb_buffers.c | 7 ---
 drivers/gpu/drm/drm_gem.c  | 1 -
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_dumb_buffers.c 
b/drivers/gpu/drm/drm_dumb_buffers.c
index 39ac15ce4702..7abf6fd6b52f 100644
--- a/drivers/gpu/drm/drm_dumb_buffers.c
+++ b/drivers/gpu/drm/drm_dumb_buffers.c
@@ -44,9 +44,10 @@
  * KMS frame buffers.
  *
  * To support dumb objects drivers must implement the _driver.dumb_create
- * operation. _driver.dumb_destroy defaults to drm_gem_dumb_destroy() if
- * not set and _driver.dumb_map_offset defaults to
- * drm_gem_dumb_map_offset(). See the callbacks for further details.
+ * and _driver.dumb_map_offset operations (the latter defaults to
+ * drm_gem_dumb_map_offset() if not set). Drivers that don't use GEM handles
+ * additionally need to implement the _driver.dumb_destroy operation. See
+ * the callbacks for further details.
  *
  * Note that dumb objects may not be used for gpu acceleration, as has been
  * attempted on some ARM embedded platforms. Such drivers really must have
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index ad4e9cfe48a2..6b23b707b15f 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -360,7 +360,6 @@ int drm_gem_dumb_destroy(struct drm_file *file,
 {
return drm_gem_handle_delete(file, handle);
 }
-EXPORT_SYMBOL(drm_gem_dumb_destroy);
 
 /**
  * drm_gem_handle_create_tail - internal functions to create a handle
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm: Why shmem?

[Eric Anholt]

Noralf Trønnes  writes:

> Den 30.08.2017 09.40, skrev Daniel Vetter:
>> On Tue, Aug 29, 2017 at 10:40:04AM -0700, Eric Anholt wrote:
>>> Daniel Vetter  writes:
>>>
 On Mon, Aug 28, 2017 at 8:44 PM, Noralf Trønnes  wrote:
> Hi,
>
> Currently I'm using the cma library with tinydrm because it was so
> simple to use even though I have to work around the fact that reads are
> uncached. A bigger problem that I have become aware of, is that it
> restricts the dma buffers it can import since they have to be continous.
>
> So I looked to udl and it uses shmem. Fine, let's make a shmem gem
> library similar to the cma library.
>
> Now I have done so and have started to think about the DOC: section,
> explaining what the library does. And I'm stuck, what's the benefit of
> using shmem compared to just using alloc_page()?
 Gives you swapping (and eventually maybe even migration) since there's
 a real filesystem behind it. Atm this only works if you register a
 shrinker callback, which for display drivers is a bit overkill. See
 i915 or msm for examples (or ttm, if you want an entire fancy
 framework), and git grep shrinker -- drivers/gpu.
>>> The shrinker is only needed if you need some impetus to unbind objects
>>> from your page tables, right?  If you're just binding the pages for the
>>> moment that you're doing SPI transfers to the display, then in the
>>> remaining time it could be swapped out, right?
>> Yup, and for SPI the setup overhead shouldn't matter. But everyone else
>> probably wants to cache mappings and page lists, and that means some kind
>> of shrinker to drop them when needed.
>
> Let me see if I've understood this correctly:
>
> The first time I call drm_gem_get_pages() the buffer pages are
> allocated and pinned.
> When I then call drm_gem_put_pages() the pages are unpinned, but not freed.
> The kernel is now free to swap out the pages if necessary.
> Calling drm_gem_get_pages() a second time will swapin the pages if
> necessary and pin them.
>
> If this is correct, where are pages freed?

drm_gem_object_release() during freeing of the object.



signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm: Why shmem?

[Noralf Trønnes]

Den 30.08.2017 09.40, skrev Daniel Vetter:

On Tue, Aug 29, 2017 at 10:40:04AM -0700, Eric Anholt wrote:

Daniel Vetter  writes:


On Mon, Aug 28, 2017 at 8:44 PM, Noralf Trønnes  wrote:

Hi,

Currently I'm using the cma library with tinydrm because it was so
simple to use even though I have to work around the fact that reads are
uncached. A bigger problem that I have become aware of, is that it
restricts the dma buffers it can import since they have to be continous.

So I looked to udl and it uses shmem. Fine, let's make a shmem gem
library similar to the cma library.

Now I have done so and have started to think about the DOC: section,
explaining what the library does. And I'm stuck, what's the benefit of
using shmem compared to just using alloc_page()?

Gives you swapping (and eventually maybe even migration) since there's
a real filesystem behind it. Atm this only works if you register a
shrinker callback, which for display drivers is a bit overkill. See
i915 or msm for examples (or ttm, if you want an entire fancy
framework), and git grep shrinker -- drivers/gpu.

The shrinker is only needed if you need some impetus to unbind objects
from your page tables, right?  If you're just binding the pages for the
moment that you're doing SPI transfers to the display, then in the
remaining time it could be swapped out, right?

Yup, and for SPI the setup overhead shouldn't matter. But everyone else
probably wants to cache mappings and page lists, and that means some kind
of shrinker to drop them when needed.


Let me see if I've understood this correctly:

The first time I call drm_gem_get_pages() the buffer pages are
allocated and pinned.
When I then call drm_gem_put_pages() the pages are unpinned, but not freed.
The kernel is now free to swap out the pages if necessary.
Calling drm_gem_get_pages() a second time will swapin the pages if
necessary and pin them.

If this is correct, where are pages freed?

Noralf.


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] dma-buf: remove redundant initialization of sg_table

[Colin King]

From: Colin Ian King 

sg_table is being initialized and is never read before it is updated
again later on, hence making the initialization redundant. Remove
the initialization.

Detected by clang scan-build:
"warning: Value stored to 'sg_table' during its initialization is
never read"

Signed-off-by: Colin Ian King 
---
 drivers/dma-buf/dma-buf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 4a038dcf5361..bc1cb284111c 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -625,7 +625,7 @@ EXPORT_SYMBOL_GPL(dma_buf_detach);
 struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach,
enum dma_data_direction direction)
 {
-   struct sg_table *sg_table = ERR_PTR(-EINVAL);
+   struct sg_table *sg_table;
 
might_sleep();
 
-- 
2.14.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101872] [PIGLIT] Corrupted temporal json test file blocks execution resume

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101872

Elizabeth  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 100596] [BXT/GLK/KBL/BDW/IVB/HSW/BSW/BYT] gem_userptr_blits/map-fixed-invalidate* showing bad address

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100596

Elizabeth  changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED

--- Comment #19 from Elizabeth  ---
Verified with BXT, GLK, KBL, BDW, IVB, HSW, BSW, BYT.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 100305] [BAT][IGT]basic tests in gem_ctx_basic, gem_ctx_exec, gem_ctx_params fail

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100305

--- Comment #2 from Elizabeth  ---
Does this need to be verified or can we close it?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99130] [IVB] CONFIG_PROVE_LOCKING=y causes igt/gem_exec/basic-wait-all (and possibly others) to fail

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99130

Elizabeth  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #23 from Elizabeth  ---
Closing. Please reopen if needed. Thanks.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 98361] [BDW /BXT/SKL/SNB] [Regression] drv_hangman subtests parser fail

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=98361

Elizabeth  changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED

--- Comment #4 from Elizabeth  ---
Verified on SKL, BDW, BXT, SNB.

$ : sudo -E ./drv_hangman --r error-state-capture-blt
IGT-Version: 1.19-gc718ba8 (x86_64) (Linux: 4.13.0-drm-tip-ww37-commit-14ea1a9+
x86_64)
Subtest error-state-capture-blt: SUCCESS (17.077s)

$ : sudo -E ./drv_hangman --r error-state-capture-bsd
IGT-Version: 1.19-gc718ba8 (x86_64) (Linux: 4.13.0-drm-tip-ww37-commit-14ea1a9+
x86_64)
Subtest error-state-capture-bsd: SUCCESS (17.329s)

$ : sudo -E ./drv_hangman --r error-state-capture-render
IGT-Version: 1.19-gc718ba8 (x86_64) (Linux: 4.13.0-drm-tip-ww37-commit-14ea1a9+
x86_64)
Subtest error-state-capture-render: SUCCESS (17.589s)

$ : sudo -E ./drv_hangman --r error-state-capture-vebox
IGT-Version: 1.19-gc718ba8 (x86_64) (Linux: 4.13.0-drm-tip-ww37-commit-14ea1a9+
x86_64)
Subtest error-state-capture-vebox: SUCCESS (17.153s)

Note with SNB last one is skipped:
$ : sudo -E ./drv_hangman --r error-state-capture-vebox
IGT-Version: 1.19-gc718ba8 (x86_64) (Linux: 4.13.0-drm-tip-ww37-commit-36b5aec+
x86_64)
Test requirement not met in function test_error_state_capture, file
drv_hangman.c:186:
Test requirement: gem_has_ring(device, ring_id)
Subtest error-state-capture-vebox: SKIP (0.000s)


With configuration:

==
 Software
==
kernel version  : 4.13.0-drm-tip-ww37-commit-14ea1a9+
architecture: x86_64
os version  : Ubuntu 16.10
os codename : yakkety
kernel driver   : i915
hardware acceleration   : disabled
swap partition  : enabled on (/dev/sda3)

==
Graphic drivers
==
grep: /opt/X11R7/var/log/Xorg.0.log: No such file or directory
libdrm  : 2.4.83
cairo   : 1.15.9
intel-gpu-tools (tag)   : intel-gpu-tools-1.19-289-gc718ba8
intel-gpu-tools (commit): c718ba8

intel_iommu=igfx_off

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/8] drm/fb-helper: Use drm_file to get a dumb framebuffer

[Laurent Pinchart]

Hi Noralf,

On Wednesday, 13 September 2017 18:19:22 EEST Noralf Trønnes wrote:
> Den 13.09.2017 07.09, skrev Laurent Pinchart:
> > On Monday, 11 September 2017 17:31:54 EEST Noralf Trønnes wrote:
> >> Hi,
> >> 
> >> I want to start out by saying that this patchset is low priority for me
> >> and if no one has interest or time to review this, that is just fine. I
> >> was in the flow and just typed it out.
> >> 
> >> This patchset adds a way for fbdev emulation code to create a
> >> framebuffer that is backed by a dumb buffer. drm_fb_helper gets a
> >> drm_file to hang the objects on, drm_framebuffer_create_dumb() creates
> >> the framebuffer and drm_fb_helper_fini() destroys it.
> >> I have verified that all cma drivers supports dumb buffers, so
> >> converting the library should be fine for all.
> > 
> > Stupid question, what does this give us ? The series makes the call stack
> > more complex (up to a point where I'm getting trouble just following it),
> > what's the advantage that offsets that ?
> 
> The short answer is that it avoids the need for special fbdev
> _with_funcs() functions in libraries like cma for framebuffers with the
> dirty callback set.
> 
> I'm suprised that you think this more complex, I find it more coherent
> when fbdev userspace is doing things more like DRM userspace, like
> hanging the objects on a drm_file and cleaning up the objects when done.

Maybe moving to a new code base gave me the wrong feeling that the result is 
more complex. The current implementation is certainly not simple.

> The longer and more diffuse answer is that it's annoying me that many
> drivers carry the burden of fbdev emulation just to get a console!

I totally agree with that. Ideally I'd like to remove 100% of fbdev-related 
code from drivers. This includes

- initialization and cleanup of fbdev helpers
- fbdev restore in last_close()
- forwarding of hotplug events to fbdev compatibility layer

In practice we'll likely need to keep one initialization function (or a 
drm_driver flag) to let drivers opt-in to fbdev compatibility, but the rest 
should go away. Or maybe we could even enable fbdev compatibility in all 
drivers unconditionally.

> And an in-kernel drm console, as David Herrmann described it a year ago,
> would allocate a framebuffer using something like what I have done here.
> But maybe it's better to do this the other way around: first get the
> drm console and then let fbdev use the same mechanisms. Or maybe at that
> point, just forget about fbdev and not spend any more time on it :-)

When I mention I'd like fbdev to go away completely people complain that I 
like breaking things :-)

> Sidenote:
> Do you if any DRM drivers is capable of showing kernel oops'es on the
> console?

The last time my kernel oopses the i915 driver certainly didn't show me the 
oops.

> > With the exception of vmwgfx that does weird things I won't even try to
> > understand, all drivers seem to use the drm_file object passed to the
> > .dumb_create() operation just to register the GEM object handle. I wonder
> > whether a better solution to use .dumb_create() for framebuffer emulation
> > wouldn't be to move the GEM object handle registration from the
> > .dumb_create() implementation to its caller in the core.
> 
> Can you elaborate what you mean by this?

Again vmwgfx aside (and that's not a detail, we'd still have to handle that 
driver), the reason why the .dumb_create() operation needs a drm_file pointer 
is to register the GEM object handle for the dumb buffer. We could perform 
that registration in the caller of .dumb_create(), in which case we wouldn't 
need to pass the drm_file to the operation.

> >> A patch by David Herrmann from a year ago made this easy. It was the
> >> last piece in his work to make it possible to create a drm_file for
> >> in-kernel use, but it never got merged.
> >> 
> >> I've cc'ed intel-gfx since that will give CI runs of the core patches if
> >> I understood Daniel right.
> >> 
> >> Noralf.
> >> 
> >> David Herrmann (1):
> >>drm: provide management functions for drm_file
> >> 
> >> Noralf Trønnes (7):
> >>drm/framebuffer: Add drm_framebuffer_create_dumb()
> >>drm/auth: Export drm_dropmaster_ioctl()
> >>drm/fb-helper: Allocate a drm_file
> >>drm/fb-cma-helper: Use drm_framebuffer_create_dumb()
> >>drm/fb-cma-helper: Drop unnecessary fbdev buffer offset
> >>drm/tinydrm: Use drm_fbdev_cma_init()
> >>drm/fb-cma-helper: Remove drm_fbdev_cma_init_with_funcs()
> >>   
> >>   drivers/gpu/drm/drm_auth.c  |   1 +
> >>   drivers/gpu/drm/drm_fb_cma_helper.c | 111 ++
> >>   drivers/gpu/drm/drm_fb_helper.c |  22 +-
> >>   drivers/gpu/drm/drm_file.c  | 323 
> >>   drivers/gpu/drm/drm_framebuffer.c   |  61 ++
> >>   drivers/gpu/drm/drm_internal.h  |   2 -
> >>   drivers/gpu/drm/tinydrm/core/tinydrm-core.c |   5 +-
> >>   include/drm/drm_auth.h  

[Bug 101731] System freeze with AMDGPU when playing The Witcher 3 (GOG GOTY)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101731

--- Comment #44 from Shmerl  ---
(In reply to Lukas Jirkovsky from comment #43)
> Here are some additional information:

Yes, I observed that as well. You can access the box over ssh, but it doens't
react to any local input. Also attempts to reboot it remotely hang (systemctl
reboot). And lack of any sensible info in the logs is just strange.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 102009] Blender crashes when compiling OpenCL kernel

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=102009

--- Comment #3 from Jan Vesely  ---
the stacktrace does not say much, and it's not similar to segfault I see on my
machine. Can you repost the stacktrace with mesa debug information?

thanks

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 98352] [ctg bat] igt@kms_flip@basic-flip-vs-wf_vblank

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=98352

Elizabeth  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101731] System freeze with AMDGPU when playing The Witcher 3 (GOG GOTY)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101731

--- Comment #43 from Lukas Jirkovsky  ---
I'm having the same problem during the initial cutscene in Velen.

Here are some additional information:

* While the computer seems frozen, it's not frozen completely. I can still
connect over ssh and do stuff there as if nothing happened. Other services work
uninterrupted, too.

* Locally, only SysRq helps. Even after killing everything using Alt+SysRq+i
the computer doesn't react to anything apart from more SysRq shortcuts.

* dmesg doesn't contain anything useful

* Xorg.0.log doesn't contain anything useful either (on the wine bug there is a
mention about input devices being removed, but that doesn't appear here unless
forced using SysRq).

Happens with AMD RX 480 with mesa 17.2.0 and linux kernel 4.13.2

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/2] drm/gem-fb-helper: Cleanup docs

[Laurent Pinchart]

Hi Noralf,

On Wednesday, 13 September 2017 16:41:49 EEST Noralf Trønnes wrote:
> Den 13.09.2017 04.44, skrev Laurent Pinchart:
> > On Monday, 11 September 2017 19:37:44 EEST Noralf Trønnes wrote:
> >> Make the docs read a little better.
> >> 
> >> Cc: Laurent Pinchart 
> >> Signed-off-by: Noralf Trønnes 
> >> Reviewed-by: Daniel Vetter 
> >> ---
> >> 
> >> Changes:
> >> Addressed Daniel's comments.
> >> 
> >> drivers/gpu/drm/drm_gem_framebuffer_helper.c | 25 +--
> >> 
> >> 1 file changed, 14 insertions(+), 11 deletions(-)
> >> 
> >> diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> >> b/drivers/gpu/drm/drm_gem_framebuffer_helper.c index d54a083..e2ca002
> >> 100644
> >> --- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> >> +++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c

[snip]

> >>  /**
> >>   * drm_gem_fb_create_handle - Create handle for GEM backed framebuffer
> >> - * @fb: DRM framebuffer
> >> - * @file: drm file
> >> + * @fb: framebuffer
> >> + * @file: DRM file
> > 
> > I wonder why framebuffer doesn't need a DRM while file does :-)
> 
> Yes this is haphazard.
> I think my problem is that I haven't been able to pick up a consistent
> "signal" from the DRM subsystem when it comes to how documentation
> should be written. Code patterns are fairly consistent and looks much
> the same including variable names, but documentation is more or less
> all over the place.

That doesn't surprise me too much, as documentation in DRM is pretty recent, 
and we never agreed to a documentation style.

> So I guess I need to come to grips with this, since this isn't the last
> time I have to write documentation. I have to make myself some rules
> that I can look at next time when all of this is forgotten.

Or, as the first person to address this problem, you could set your own rules 
that everybody else should then follow :-)

> Should description entries be Capitalized?
> My gut feeling is that most DRM docs don't do that, but when humans
> write for humans we do capatalize the start of sentences. So I guess
> that's the natural thing to do.
> 
> Should DRM objects start with DRM in the argument doc entries?
> 'DRM device' is a given since the kernel has many types of devices, but
> should we write 'DRM framebuffer' or 'Framebuffer'?

I would only mention DRM when the description could otherwise be 
misinterpreted, as in DRM device.

> How descriptive should the descriptions be?
> Let's take this example:
> 
> /**
>   * drm_gem_fb_prepare_fb() - Prepare gem framebuffer
>   * @plane: Which plane
>   * @state: Plane state the fence will be attached to
>   *
>   * This can be used as the _plane_helper_funcs.prepare_fb hook.
>   *
>   * This function checks if the plane FB has an dma-buf attached, extracts
>   * the exclusive fence and attaches it to plane state for the atomic helper
>   * to wait on.
> 
> Both the @state description and the body says that the fence will be
> attached to the plane state. Would it be better to just say:
> 
>   * @state: Plane state
> 
> Another way to ask this is:
> Should the documentation be terse or should it be repeating itself?
> 
> Then we have (copied from the cma library):
> 
>   * @plane: Which plane
> 
> Which is probably short for: The plane which we are operating/acting on.
> 
> More possibilities:
> 
>   * @plane: DRM plane
>   * @plane: Plane
>   * @plane: The plane for which a framebuffer is prepared for scanout
> 
> The text for the last one is also available when clicking on the
> _plane_helper_funcs.prepare_fb link, so it's repeating something
> that is one click away.

Writing kerneldoc just for the sake of it is mostly pointless. We should write 
documentation to make it as useful and easy to consume as possible. Keeping 
that in mind,

 * @plane: Plane

isn't very useful. It's clear from the function argument name (and type) that 
it is a pointer to a plane. I would thus advocate for more detailed parameter 
descriptions.

> I always get comments on my documentation, so it's clearly something I
> need to find a way to improve.

I don't think it's specific to your documentation. You're doing a great job, 
for which I'm personally grateful. The fact that we haven't defined a 
documentation style in a similar way as we have defined a coding style is an 
issue of the DRM/KMS community.

> >>   * @handle: handle created
> >>   *
> >>   * Drivers can use this as their _framebuffer_funcs->create_handle

[snip]

-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 97259] Some gem_shrink subcases return fail instead of pass

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=97259

Elizabeth  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 100212] Implement vload_* and vstore_* to make Theano/libgpuarray working

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100212

--- Comment #4 from Jan Vesely  ---
(In reply to Vedran Miletić from comment #0)
> We miss at least vload_half and vstore_half_rtn.

vstore_half/vload_half is in libclc. I can't find vstore_half_rtn used in
either blender-2.78 or 2.79.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 102517] System hang/freeze Helium Rain

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=102517

--- Comment #2 from Samuel Pitoiset  ---
I can confirm the hang with the following environment.

OpenGL renderer string: AMD Radeon (TM) RX 480 Graphics (AMD POLARIS10 / DRM
3.19.0 / 4.13.0-rc5-ARCH+, LLVM 4.0.1)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.2.0

But can't be reproduced with:

OpenGL renderer string: AMD Radeon (TM) RX 480 Graphics (POLARIS10 / DRM 3.19.0
/ 4.13.0-rc5-ARCH+, LLVM 6.0.0)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.3.0-devel
(git-49c72d84c2)

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 102276] System randomly freezes, only fixed by power off and boot.

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=102276

--- Comment #9 from Mathieu Belanger  ---
I forgot to mention, while the crash occured, the mouse was working but
everything else was hang, including magic keys was doing nothing.

After X felt, I tried to login and I got an error about missing OpenGL 2 from
KDE so I did a full reboot, here the end of my message log.

[loop]
Sep 14 13:57:56 uk-dev kernel: [drm:amdgpu_gem_object_create [amdgpu]] *ERROR*
Failed to allocate GEM object (33554432, 6, 131072, -12)
Sep 14 13:57:56 uk-dev kernel: [TTM] Out of kernel memory
Sep 14 13:57:56 uk-dev kernel: [TTM] Out of kernel memory
[/loop]
Sep 14 13:57:56 uk-dev kernel: [drm:amdgpu_gem_object_create [amdgpu]] *ERROR*
Failed to allocate GEM object (33554432, 6, 131072, -12)
Sep 14 13:57:56 uk-dev kernel: [drm] Atomic commit: RESET. crtc id
0:[880405ebb800]
Sep 14 13:57:56 uk-dev kernel: [drm] dc_commit_state: 0 streams
Sep 14 13:57:56 uk-dev polkitd[3633]: Unregistered Authentication Agent for
unix-session:/org/freedesktop/ConsoleKit/Session1 (system bus name :1.18,
object path /org/kde/PolicyKit1/AuthenticationAgent, locale en_US.utf8)
(disconnected from bus)
Sep 14 13:57:56 uk-dev kernel: [drm] Atomic commit: SET crtc id 0:
[880405ebb800]
Sep 14 13:57:56 uk-dev kernel: [drm] dc_commit_state: 1 streams
Sep 14 13:57:56 uk-dev kernel: [drm] core_stream 0x4b321c00: src: 0, 0, 3840,
2160; dst: 0, 0, 3840, 2160, colorSpace:1
Sep 14 13:57:56 uk-dev kernel: [drm] \x09pix_clk_khz: 533250, h_total: 4000,
v_total: , pixelencoder:1, displaycolorDepth:2
Sep 14 13:57:56 uk-dev kernel: [drm] \x09sink name: U28E590, serial: 810373197
Sep 14 13:57:56 uk-dev kernel: [drm] \x09link: 0
Sep 14 13:57:56 uk-dev kernel: [drm] dce_get_required_clocks_state: clocks
unsupported
Sep 14 13:57:56 uk-dev kernel: [drm] Link: 0 eDP panel mode supported: 0 eDP
panel mode enabled: 0 
Sep 14 13:57:56 uk-dev kernel: [drm] [LKTN]\x09[DP][ConnIdx:0] HBR2x4 pass
VS=2, PE=0^
Sep 14 13:57:56 uk-dev kernel: [drm] [Mode]\x09[DP][ConnIdx:0] {3840x2160,
4000x@533250Khz}^
Sep 14 13:58:57 uk-dev slim[21180]: pam_unix(slim:session): session opened for
user destroyfx by destroyfx(uid=0)
[loop]
Sep 14 13:58:57 uk-dev kernel: [TTM] Out of kernel memory
Sep 14 13:58:57 uk-dev kernel: [TTM] Out of kernel memory
Sep 14 13:58:57 uk-dev kernel: [drm:amdgpu_gem_object_create [amdgpu]] *ERROR*
Failed to allocate GEM object (131072, 6, 131072, -12)
[/loop]

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 102276] System randomly freezes, only fixed by power off and boot.

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=102276

--- Comment #8 from Mathieu Belanger  ---
(In reply to Michel Dänzer from comment #7)
> (In reply to Mathieu Belanger from comment #6)
> > I might have the same bug
> > 
> > I does not append with Mesa git from mid august but a version from beginning
> > of September do it.
> 
> [...]
> 
> > Kernel 4.12
> 
> If that means amd-staging-4.12, you're probably running into bug 102500.

Yes, I did fix the one I wrote by switching the 4.13-rc5 (amd-staging-next, I
think)

Now I might have got similar to OP, "randomly" crash and the mouse was still
alive. After about 5 minutes X suicided and I was able to get the message log
and I saw a ton of:

[drm:amdgpu_gem_object_create [amdgpu]] *ERROR* Failed to allocate GEM object
(131072, 6, 131072, -12)

That bug was also not present with 4.12/mid august mesa.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915: remove redundant variable hw_check

[Chris Wilson]

Quoting Colin King (2017-09-14 17:21:54)
> From: Colin Ian King 
> 
> hw_check is being assigned and updated but is no longer being read,
> hence it is redundant and can be removed.
> 
> Detected by clang scan-build:
> "warning: Value stored to 'hw_check' during its initialization
> is never read"
> 
> Fixes: f6d1973db2d2 ("drm/i915: Move modeset state verifier calls")
> Signed-off-by: Colin Ian King 
Reviewed-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index f17275519484..ac261eaa5ba5 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -12359,7 +12359,6 @@ static void intel_atomic_commit_tail(struct 
> drm_atomic_state *state)
> struct drm_crtc_state *old_crtc_state, *new_crtc_state;
> struct drm_crtc *crtc;
> struct intel_crtc_state *intel_cstate;
> -   bool hw_check = intel_state->modeset;
> u64 put_domains[I915_MAX_PIPES] = {};
> unsigned crtc_vblank_mask = 0;
> int i;
> @@ -12376,7 +12375,6 @@ static void intel_atomic_commit_tail(struct 
> drm_atomic_state *state)
>  
> if (needs_modeset(new_crtc_state) ||
> to_intel_crtc_state(new_crtc_state)->update_pipe) {
> -   hw_check = true;
>  
> put_domains[to_intel_crtc(crtc)->pipe] =
> modeset_get_crtc_power_domains(crtc,
> -- 
> 2.14.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101731] System freeze with AMDGPU when playing The Witcher 3 (GOG GOTY)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101731

Samuel Pitoiset  changed:

   What|Removed |Added

Summary|System freeze with AMDGPU   |System freeze with AMDGPU
   |when playing The Witcher 3  |when playing The Witcher 3
   ||(GOG GOTY)

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 102646] Screen flickering under amdgpu-experimental (buffer corruptions?)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=102646

--- Comment #9 from Justin Mitzel  ---
I went looking for them and noticed that these are all made for ubuntu. Will
they still work with Manjaro?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/6 v4] Add ASoC support for AMD Stoney APUs

[Mark Brown]

On Wed, Sep 13, 2017 at 02:49:08PM -0400, Alex Deucher wrote:
> On Wed, Sep 13, 2017 at 2:12 PM, Mark Brown  wrote:

> > No, send me a pull request for the dependencies so we can do a cross
> > merge.  I want to make sure that when this gets reviewed it actually
> > gets merged.

> I'm not quite sure what you mean by the cross merge.  There are no
> dependencies outside this patch set.  The only patches that touch drm
> are patches 1 and 2.  Patch 1 touches both audio and drm, patch 2 just
> touches drm.  Do you want me to send you a pull request for patches 1

I can't see any reason for patch 1 to be a single patch, just have a DRM
patch that adds the property and then a separate audio patch that uses
it.  Send me a pull request for that and patch 2 then I can handle the
audio stuff.

> and 2 and then would you'd send Dave a pull request for the audio side
> (patches 3-6)?

I guess, but I thought you were a maintainer for this stuff and could
merge things yourself?


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 196777] Virtual guest using video device QXL does not reach GDM

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=196777

Justin M. Forbes (jmfor...@linuxtx.org) changed:

   What|Removed |Added

 CC||jmfor...@linuxtx.org

--- Comment #7 from Justin M. Forbes (jmfor...@linuxtx.org) ---
(In reply to Gerd Hoffmann from comment #4)
> Retested 4.13 + comment #2 patch.
> 
> plymouth (aka graphical boot) hangs the machine indeed.
> 
> when disabling rhgb gdm comes up just fine though, in both wayland and xorg
> mode.
> so apparently we have two issues here, and the patch fixes only one of them.
> 
> The plymouth hang appears to be pretty serious, the whole machine appears to
> be toast.  I can't login over network to see what is going on, so it's not
> only the display which is f*cked up.  Nothing written to the logs either. 
> When enabling the serial console to see the logs plymouth skips the splash
> screen though, so the issue doesn't trigger any more.  Hmm, I'm running out
> of ideas ...

I dropped the patch into the 4.12.12 update for Fedora kernels. The complaints
I am seeing are screen strobing with this patch, it has been backed out for
now.  The plymouth issue is also a big one.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/amdgpu: revert tile table update for oland

[Alex Deucher]

On Thu, Sep 14, 2017 at 12:21 PM, Marek Olšák  wrote:
> Reviewed-by: Marek Olšák 

Applied.  thanks.

Alex

>
> Marek
>
> On Mon, Sep 11, 2017 at 5:43 PM, Jean Delvare  wrote:
>> Several users have complained that the tile table update broke Oland
>> support. Despite several attempts to fix it, the root cause is still
>> unknown at this point and no solution is available. As it is not
>> acceptable to leave a known regression breaking a major functionality
>> in the kernel for several releases, let's just reverse this
>> optimization for now. It can be implemented again later if and only
>> if the breakage is understood and fixed.
>>
>> As there were no complaints for Hainan so far, only the Oland part of
>> the offending commit is reverted. Optimization is preserved on
>> Hainan, so this commit isn't an actual revert of the original.
>>
>> This fixes bug #194761:
>> https://bugzilla.kernel.org/show_bug.cgi?id=194761
>>
>> Signed-off-by: Jean Delvare 
>> Fixes: f8d9422ef80c ("drm/amdgpu: update tile table for oland/hainan")
>> Cc: Flora Cui 
>> Cc: Junwei Zhang 
>> Cc: Alex Deucher 
>> Cc: Marek Olšák 
>> ---
>> This version of the fix is suitable for kernels v4.13 and up.
>> I'm running it for some time now it works perfectly on my
>> Radeon R5 240 (Dell OEM):
>> 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. 
>> [AMD/ATI] Oland [Radeon HD 8570 / R7 240/340 OEM] [1002:6611]
>>
>>  drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c |  189 
>> +-
>>  1 file changed, 188 insertions(+), 1 deletion(-)
>>
>> --- linux-4.13.orig/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c   2017-09-11 
>> 17:33:30.103176910 +0200
>> +++ linux-4.13/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c2017-09-11 
>> 17:40:12.711316976 +0200
>> @@ -636,7 +636,194 @@ static void gfx_v6_0_tiling_mode_table_i
>> NUM_BANKS(ADDR_SURF_2_BANK);
>> for (reg_offset = 0; reg_offset < num_tile_mode_states; 
>> reg_offset++)
>> WREG32(mmGB_TILE_MODE0 + reg_offset, 
>> tilemode[reg_offset]);
>> -   } else if (adev->asic_type == CHIP_OLAND || adev->asic_type == 
>> CHIP_HAINAN) {
>> +   } else if (adev->asic_type == CHIP_OLAND) {
>> +   tilemode[0] =   
>> MICRO_TILE_MODE(ADDR_SURF_DEPTH_MICRO_TILING) |
>> +   ARRAY_MODE(ARRAY_2D_TILED_THIN1) |
>> +   PIPE_CONFIG(ADDR_SURF_P4_8x16) |
>> +   TILE_SPLIT(ADDR_SURF_TILE_SPLIT_64B) |
>> +   NUM_BANKS(ADDR_SURF_16_BANK) |
>> +   BANK_WIDTH(ADDR_SURF_BANK_WIDTH_1) |
>> +   BANK_HEIGHT(ADDR_SURF_BANK_HEIGHT_4) |
>> +   MACRO_TILE_ASPECT(ADDR_SURF_MACRO_ASPECT_4);
>> +   tilemode[1] =   
>> MICRO_TILE_MODE(ADDR_SURF_DEPTH_MICRO_TILING) |
>> +   ARRAY_MODE(ARRAY_2D_TILED_THIN1) |
>> +   PIPE_CONFIG(ADDR_SURF_P4_8x16) |
>> +   TILE_SPLIT(ADDR_SURF_TILE_SPLIT_128B) |
>> +   NUM_BANKS(ADDR_SURF_16_BANK) |
>> +   BANK_WIDTH(ADDR_SURF_BANK_WIDTH_1) |
>> +   BANK_HEIGHT(ADDR_SURF_BANK_HEIGHT_4) |
>> +   MACRO_TILE_ASPECT(ADDR_SURF_MACRO_ASPECT_4);
>> +   tilemode[2] =   
>> MICRO_TILE_MODE(ADDR_SURF_DEPTH_MICRO_TILING) |
>> +   ARRAY_MODE(ARRAY_2D_TILED_THIN1) |
>> +   PIPE_CONFIG(ADDR_SURF_P4_8x16) |
>> +   TILE_SPLIT(ADDR_SURF_TILE_SPLIT_256B) |
>> +   NUM_BANKS(ADDR_SURF_16_BANK) |
>> +   BANK_WIDTH(ADDR_SURF_BANK_WIDTH_1) |
>> +   BANK_HEIGHT(ADDR_SURF_BANK_HEIGHT_4) |
>> +   MACRO_TILE_ASPECT(ADDR_SURF_MACRO_ASPECT_4);
>> +   tilemode[3] =   
>> MICRO_TILE_MODE(ADDR_SURF_DEPTH_MICRO_TILING) |
>> +   ARRAY_MODE(ARRAY_2D_TILED_THIN1) |
>> +   PIPE_CONFIG(ADDR_SURF_P4_8x16) |
>> +   TILE_SPLIT(ADDR_SURF_TILE_SPLIT_128B) |
>> +   NUM_BANKS(ADDR_SURF_16_BANK) |
>> +   BANK_WIDTH(ADDR_SURF_BANK_WIDTH_1) |
>> +   BANK_HEIGHT(ADDR_SURF_BANK_HEIGHT_4) |
>> +   MACRO_TILE_ASPECT(ADDR_SURF_MACRO_ASPECT_4);
>> +   tilemode[4] =   
>> MICRO_TILE_MODE(ADDR_SURF_DEPTH_MICRO_TILING) |
>> +   ARRAY_MODE(ARRAY_1D_TILED_THIN1) |
>> +   PIPE_CONFIG(ADDR_SURF_P4_8x16) |
>> +  

Re: [PATCH] drm/amdgpu: revert tile table update for oland

[Marek Olšák]

Reviewed-by: Marek Olšák 

Marek

On Mon, Sep 11, 2017 at 5:43 PM, Jean Delvare  wrote:
> Several users have complained that the tile table update broke Oland
> support. Despite several attempts to fix it, the root cause is still
> unknown at this point and no solution is available. As it is not
> acceptable to leave a known regression breaking a major functionality
> in the kernel for several releases, let's just reverse this
> optimization for now. It can be implemented again later if and only
> if the breakage is understood and fixed.
>
> As there were no complaints for Hainan so far, only the Oland part of
> the offending commit is reverted. Optimization is preserved on
> Hainan, so this commit isn't an actual revert of the original.
>
> This fixes bug #194761:
> https://bugzilla.kernel.org/show_bug.cgi?id=194761
>
> Signed-off-by: Jean Delvare 
> Fixes: f8d9422ef80c ("drm/amdgpu: update tile table for oland/hainan")
> Cc: Flora Cui 
> Cc: Junwei Zhang 
> Cc: Alex Deucher 
> Cc: Marek Olšák 
> ---
> This version of the fix is suitable for kernels v4.13 and up.
> I'm running it for some time now it works perfectly on my
> Radeon R5 240 (Dell OEM):
> 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. 
> [AMD/ATI] Oland [Radeon HD 8570 / R7 240/340 OEM] [1002:6611]
>
>  drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c |  189 
> +-
>  1 file changed, 188 insertions(+), 1 deletion(-)
>
> --- linux-4.13.orig/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c   2017-09-11 
> 17:33:30.103176910 +0200
> +++ linux-4.13/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c2017-09-11 
> 17:40:12.711316976 +0200
> @@ -636,7 +636,194 @@ static void gfx_v6_0_tiling_mode_table_i
> NUM_BANKS(ADDR_SURF_2_BANK);
> for (reg_offset = 0; reg_offset < num_tile_mode_states; 
> reg_offset++)
> WREG32(mmGB_TILE_MODE0 + reg_offset, 
> tilemode[reg_offset]);
> -   } else if (adev->asic_type == CHIP_OLAND || adev->asic_type == 
> CHIP_HAINAN) {
> +   } else if (adev->asic_type == CHIP_OLAND) {
> +   tilemode[0] =   MICRO_TILE_MODE(ADDR_SURF_DEPTH_MICRO_TILING) 
> |
> +   ARRAY_MODE(ARRAY_2D_TILED_THIN1) |
> +   PIPE_CONFIG(ADDR_SURF_P4_8x16) |
> +   TILE_SPLIT(ADDR_SURF_TILE_SPLIT_64B) |
> +   NUM_BANKS(ADDR_SURF_16_BANK) |
> +   BANK_WIDTH(ADDR_SURF_BANK_WIDTH_1) |
> +   BANK_HEIGHT(ADDR_SURF_BANK_HEIGHT_4) |
> +   MACRO_TILE_ASPECT(ADDR_SURF_MACRO_ASPECT_4);
> +   tilemode[1] =   MICRO_TILE_MODE(ADDR_SURF_DEPTH_MICRO_TILING) 
> |
> +   ARRAY_MODE(ARRAY_2D_TILED_THIN1) |
> +   PIPE_CONFIG(ADDR_SURF_P4_8x16) |
> +   TILE_SPLIT(ADDR_SURF_TILE_SPLIT_128B) |
> +   NUM_BANKS(ADDR_SURF_16_BANK) |
> +   BANK_WIDTH(ADDR_SURF_BANK_WIDTH_1) |
> +   BANK_HEIGHT(ADDR_SURF_BANK_HEIGHT_4) |
> +   MACRO_TILE_ASPECT(ADDR_SURF_MACRO_ASPECT_4);
> +   tilemode[2] =   MICRO_TILE_MODE(ADDR_SURF_DEPTH_MICRO_TILING) 
> |
> +   ARRAY_MODE(ARRAY_2D_TILED_THIN1) |
> +   PIPE_CONFIG(ADDR_SURF_P4_8x16) |
> +   TILE_SPLIT(ADDR_SURF_TILE_SPLIT_256B) |
> +   NUM_BANKS(ADDR_SURF_16_BANK) |
> +   BANK_WIDTH(ADDR_SURF_BANK_WIDTH_1) |
> +   BANK_HEIGHT(ADDR_SURF_BANK_HEIGHT_4) |
> +   MACRO_TILE_ASPECT(ADDR_SURF_MACRO_ASPECT_4);
> +   tilemode[3] =   MICRO_TILE_MODE(ADDR_SURF_DEPTH_MICRO_TILING) 
> |
> +   ARRAY_MODE(ARRAY_2D_TILED_THIN1) |
> +   PIPE_CONFIG(ADDR_SURF_P4_8x16) |
> +   TILE_SPLIT(ADDR_SURF_TILE_SPLIT_128B) |
> +   NUM_BANKS(ADDR_SURF_16_BANK) |
> +   BANK_WIDTH(ADDR_SURF_BANK_WIDTH_1) |
> +   BANK_HEIGHT(ADDR_SURF_BANK_HEIGHT_4) |
> +   MACRO_TILE_ASPECT(ADDR_SURF_MACRO_ASPECT_4);
> +   tilemode[4] =   MICRO_TILE_MODE(ADDR_SURF_DEPTH_MICRO_TILING) 
> |
> +   ARRAY_MODE(ARRAY_1D_TILED_THIN1) |
> +   PIPE_CONFIG(ADDR_SURF_P4_8x16) |
> +   TILE_SPLIT(ADDR_SURF_TILE_SPLIT_64B) |
> +   NUM_BANKS(ADDR_SURF_16_BANK) |
> +   

[PATCH] drm/i915: remove redundant variable hw_check

[Colin King]

From: Colin Ian King 

hw_check is being assigned and updated but is no longer being read,
hence it is redundant and can be removed.

Detected by clang scan-build:
"warning: Value stored to 'hw_check' during its initialization
is never read"

Fixes: f6d1973db2d2 ("drm/i915: Move modeset state verifier calls")
Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/i915/intel_display.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index f17275519484..ac261eaa5ba5 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12359,7 +12359,6 @@ static void intel_atomic_commit_tail(struct 
drm_atomic_state *state)
struct drm_crtc_state *old_crtc_state, *new_crtc_state;
struct drm_crtc *crtc;
struct intel_crtc_state *intel_cstate;
-   bool hw_check = intel_state->modeset;
u64 put_domains[I915_MAX_PIPES] = {};
unsigned crtc_vblank_mask = 0;
int i;
@@ -12376,7 +12375,6 @@ static void intel_atomic_commit_tail(struct 
drm_atomic_state *state)
 
if (needs_modeset(new_crtc_state) ||
to_intel_crtc_state(new_crtc_state)->update_pipe) {
-   hw_check = true;
 
put_domains[to_intel_crtc(crtc)->pipe] =
modeset_get_crtc_power_domains(crtc,
-- 
2.14.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 102709] War Thunder crashes after logging in to the game. (GL_INVALID_ENUM)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=102709

--- Comment #1 from Samuel Pitoiset  ---
Well, War Thunder doesn't check that GL_EXT_texture_compression_s3tc is exposed
before using those compressed formats.

Though, if you have libtxc_dxtn installed on your system the extension should
be enabled, can you check?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 98324] [DC] amd-staging-4.7: problems with unblanking displays when monitors are switched off

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=98324

--- Comment #7 from Darren Salt  ---
Seems to be working properly with current amd-staging-drm-next (43dd6fde5df4).

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101731] System freeze with AMDGPU when playing The Witcher 3

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101731

--- Comment #42 from Samuel Pitoiset  ---
What's your Steam AppID?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #176 from Jon Doane  ---
(In reply to Thomas DEBESSE from comment #175)
> (In reply to Alex Deucher from comment #174)
> > (In reply to Thomas DEBESSE from comment #173)
> > > 
> > > Their AMDGPU-PRO driver looks to not be affected by the bug, so they have 
> > > a
> > > fix somewhere. Why this fix can't make it's way to the open driver?
> > 
> > The pro stack and the open stack share the same amdgpu kernel driver.
> 
> Yes I know, so what?
> 
> Is this a packaging issue like the firmware delivered not being the good one
> or things like that?

I've experienced this issue with both AMDGPU-Pro and AMDGPU with the same
visual artifacts out of the box. The radeon driver seems to not have the same
kind of visual artifacts that AMDGPU(-Pro) has but, it's just as unstable
without intervention, at least for me. Changing the firmware didn't make enough
of an impact to make my machine even close to stable by itself.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #175 from Thomas DEBESSE  ---
(In reply to Alex Deucher from comment #174)
> (In reply to Thomas DEBESSE from comment #173)
> > 
> > Their AMDGPU-PRO driver looks to not be affected by the bug, so they have a
> > fix somewhere. Why this fix can't make it's way to the open driver?
> 
> The pro stack and the open stack share the same amdgpu kernel driver.

Yes I know, so what?

Is this a packaging issue like the firmware delivered not being the good one or
things like that?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101731] System freeze with AMDGPU when playing The Witcher 3

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101731

--- Comment #41 from Shmerl  ---
(In reply to Samuel Pitoiset from comment #40)
> How to load a save game file? Where are they stored?

They should be in:

"${WINEPREFIX}/drive_c/users/$USER/My Documents/The Witcher 3/gamesaves"

I.e. it depends on what prefix you used.

Note that GOTY save file won't work with other versions, because of some minor
incompatibilities. Even Steam version with all expansions isn't the same as GOG
GOTY one. If you need the later, let me know. Linux GOG developers said they
can provide a key.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101731] System freeze with AMDGPU when playing The Witcher 3

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101731

--- Comment #40 from Samuel Pitoiset  ---
How to load a save game file? Where are they stored?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 102694] Astrokill Beta: LLVM triggered Diagnostic Handler: Illegal instruction detected: VOP* instruction uses the constant bus more than once

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=102694

--- Comment #4 from MIka R  ---
This also seems to affect kwin_x11. Memory leaking and some plasma 5 objects
flicker mildly.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #174 from Alex Deucher  ---
(In reply to Thomas DEBESSE from comment #173)
> 
> Their AMDGPU-PRO driver looks to not be affected by the bug, so they have a
> fix somewhere. Why this fix can't make it's way to the open driver?

The pro stack and the open stack share the same amdgpu kernel driver.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] drm/exynos: Fix suspend/resume support

[Marek Szyprowski]

Commit 7d902c05b480 ("drm: Nuke drm_atomic_helper_connector_dpms")
removed drm_atomic_helper_connector_dpms() helper saying that it was a dead
code. It was however indirectly used by Exynos DRM driver for implementing
suspend/resume support. To fix this regression (after that patch Exynos DRM
suspend/resume functions became no-ops and hardware fails to suspend),
this patch rewrites them with drm_atomic_helper_suspend/resume() helpers.

Fixes: 7d902c05b480 ("drm: Nuke drm_atomic_helper_connector_dpms")
Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c   | 40 ++-
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |  1 +
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 20 
 drivers/gpu/drm/exynos/exynos_drm_fbdev.h | 10 
 4 files changed, 43 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 7f3cfc5dd320..e651a58c18cf 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -168,25 +168,19 @@ static void exynos_drm_lastclose(struct drm_device *dev)
 static int exynos_drm_suspend(struct device *dev)
 {
struct drm_device *drm_dev = dev_get_drvdata(dev);
-   struct drm_connector *connector;
-   struct drm_connector_list_iter conn_iter;
+   struct exynos_drm_private *private = drm_dev->dev_private;
 
if (pm_runtime_suspended(dev) || !drm_dev)
return 0;
 
-   drm_modeset_lock_all(drm_dev);
-   drm_connector_list_iter_begin(drm_dev, _iter);
-   drm_for_each_connector_iter(connector, _iter) {
-   int old_dpms = connector->dpms;
-
-   if (connector->funcs->dpms)
-   connector->funcs->dpms(connector, DRM_MODE_DPMS_OFF);
-
-   /* Set the old mode back to the connector for resume */
-   connector->dpms = old_dpms;
+   drm_kms_helper_poll_disable(drm_dev);
+   exynos_drm_fbdev_suspend(drm_dev);
+   private->suspend_state = drm_atomic_helper_suspend(drm_dev);
+   if (IS_ERR(private->suspend_state)) {
+   exynos_drm_fbdev_resume(drm_dev);
+   drm_kms_helper_poll_enable(drm_dev);
+   return PTR_ERR(private->suspend_state);
}
-   drm_connector_list_iter_end(_iter);
-   drm_modeset_unlock_all(drm_dev);
 
return 0;
 }
@@ -194,24 +188,14 @@ static int exynos_drm_suspend(struct device *dev)
 static int exynos_drm_resume(struct device *dev)
 {
struct drm_device *drm_dev = dev_get_drvdata(dev);
-   struct drm_connector *connector;
-   struct drm_connector_list_iter conn_iter;
+   struct exynos_drm_private *private = drm_dev->dev_private;
 
if (pm_runtime_suspended(dev) || !drm_dev)
return 0;
 
-   drm_modeset_lock_all(drm_dev);
-   drm_connector_list_iter_begin(drm_dev, _iter);
-   drm_for_each_connector_iter(connector, _iter) {
-   if (connector->funcs->dpms) {
-   int dpms = connector->dpms;
-
-   connector->dpms = DRM_MODE_DPMS_OFF;
-   connector->funcs->dpms(connector, dpms);
-   }
-   }
-   drm_connector_list_iter_end(_iter);
-   drm_modeset_unlock_all(drm_dev);
+   drm_atomic_helper_resume(drm_dev, private->suspend_state);
+   exynos_drm_fbdev_resume(drm_dev);
+   drm_kms_helper_poll_enable(drm_dev);
 
return 0;
 }
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index cf131c2aa23e..f8bae4cb4823 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -202,6 +202,7 @@ struct drm_exynos_file_private {
  */
 struct exynos_drm_private {
struct drm_fb_helper *fb_helper;
+   struct drm_atomic_state *suspend_state;
 
struct device *dma_dev;
void *mapping;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index c3a068409b48..dfb66ecf417b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -18,6 +18,8 @@
 #include 
 #include 
 
+#include 
+
 #include "exynos_drm_drv.h"
 #include "exynos_drm_fb.h"
 #include "exynos_drm_fbdev.h"
@@ -285,3 +287,21 @@ void exynos_drm_output_poll_changed(struct drm_device *dev)
 
drm_fb_helper_hotplug_event(fb_helper);
 }
+
+void exynos_drm_fbdev_suspend(struct drm_device *dev)
+{
+   struct exynos_drm_private *private = dev->dev_private;
+
+   console_lock();
+   drm_fb_helper_set_suspend(private->fb_helper, 1);
+   console_unlock();
+}
+
+void exynos_drm_fbdev_resume(struct drm_device *dev)
+{
+   struct exynos_drm_private *private = dev->dev_private;
+
+   console_lock();
+   drm_fb_helper_set_suspend(private->fb_helper, 0);
+   console_unlock();
+}
diff 

[PATCH 1/2] drm/exynos: Fix locking in the suspend/resume paths

[Marek Szyprowski]

Commit 48a92916729b ("drm/exynos: use drm_for_each_connector_iter()")
replaced unsafe drm_for_each_connector() with drm_for_each_connector_iter()
and removed surrounding drm_modeset_lock calls. However, that lock was
there not only to protect unsafe drm_for_each_connector(), but it was also
required to be held by the dpms code which was called from the loop body.
This patch restores those drm_modeset_lock calls to fix broken suspend
and resume of Exynos DRM subsystem in v4.13 kernel.

Fixes: 48a92916729b ("drm/exynos: use drm_for_each_connector_iter()")
CC: sta...@vger.kernel.org # v4.13
Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index b1f7299600f0..7f3cfc5dd320 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -174,6 +174,7 @@ static int exynos_drm_suspend(struct device *dev)
if (pm_runtime_suspended(dev) || !drm_dev)
return 0;
 
+   drm_modeset_lock_all(drm_dev);
drm_connector_list_iter_begin(drm_dev, _iter);
drm_for_each_connector_iter(connector, _iter) {
int old_dpms = connector->dpms;
@@ -185,6 +186,7 @@ static int exynos_drm_suspend(struct device *dev)
connector->dpms = old_dpms;
}
drm_connector_list_iter_end(_iter);
+   drm_modeset_unlock_all(drm_dev);
 
return 0;
 }
@@ -198,6 +200,7 @@ static int exynos_drm_resume(struct device *dev)
if (pm_runtime_suspended(dev) || !drm_dev)
return 0;
 
+   drm_modeset_lock_all(drm_dev);
drm_connector_list_iter_begin(drm_dev, _iter);
drm_for_each_connector_iter(connector, _iter) {
if (connector->funcs->dpms) {
@@ -208,6 +211,7 @@ static int exynos_drm_resume(struct device *dev)
}
}
drm_connector_list_iter_end(_iter);
+   drm_modeset_unlock_all(drm_dev);
 
return 0;
 }
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/2] Exynos DRM: fix suspend/resume support

[Marek Szyprowski]

Hi!

Recently I noticed that suspend/resume support in Exynos DRM driver is
broken since v4.13-rc1. After some investigation I found that there are 2
patches causing this problem. First one is specific to v4.13
kernel release (first patch fixes it). The second one is caused by a
patch queued to linux-next for v4.14-rc1 merge window (second patch fixes
it). Please queue both patches to v4.14-rcX fixes merge.

Best regards
Marek Szyprowski
Samsung R Institute Poland

Marek Szyprowski (2):
  drm/exynos: Fix locking in the suspend/resume paths
  drm/exynos: Fix suspend/resume support

 drivers/gpu/drm/exynos/exynos_drm_drv.c   | 36 +++
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |  1 +
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 20 +
 drivers/gpu/drm/exynos/exynos_drm_fbdev.h | 10 +
 4 files changed, 43 insertions(+), 24 deletions(-)

-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[GIT PULL] fbdev changes for v4.14

[Bartlomiej Zolnierkiewicz]

Hi Linus,

Please pull fbdev changes for v4.14. There is slightly more changes than
usual this time (especially fbcon changes stand out from the rest), please
see the signed tag description for details.

Test merge revealed a small merge conflict, the resolution is trivial:

diff --cc drivers/video/fbdev/core/fbmem.c
index 25e862c,a35f788b..f741ba8
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@@ -32,7 -32,7 +32,8 @@@
  #include 
  #include 
  #include 
+ #include 
 +#include 
  
  #include 
  

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics


The following changes since commit dd0c41f8a7e0babdadc61d5201ac8505a79dec05:

  efifb: allow user to disable write combined mapping. (2017-07-31 18:45:41 
+0200)

are available in the git repository at:

  https://github.com/bzolnier/linux.git tags/fbdev-v4.14

for you to fetch changes up to 23e9f4ef99dd313fc8d19c326f6518459a402d71:

  video/console: Update BIOS dates list for GPD win console rotation DMI quirk 
(2017-09-07 13:18:33 +0200)


fbdev changes for v4.14:

- make fbcon a built-time depency for fbdev (fbcon was tristate option
  before, now it is a bool) - this is a first step in preparations for
  making console_lock usage saner (currently it acts like the BKL for
  all things fbdev/fbcon) (Daniel Vetter)

- add fbcon=margin: command line option to select the fbcon margin
  color (David Lechner)

- add DMI quirk table for x86 systems which need fbcon rotation (devices
  like Asus T100HA, GPD Pocket, the GPD win and the I.T.Works TW891)
  (Hans de Goede)

- fix 1bpp logo support for unusual width (needed by LEGO MINDSTORMS EV3)
  (David Lechner)

- enable Xilinx FB driver for ARM ZynqMP platform (Michal Simek)

- fix use after free in the error path of udlfb driver (Anton Vasilyev)

- fix error return code handling in pxa3xx_gcu driver (Gustavo A. R. Silva)

- fix bootparams.screeninfo arguments checking in vgacon (Jan H. Schönherr)

- do not leak uninitialized padding in clk to userspace in the debug code of
  atyfb driver (Vladis Dronov)

- fix compiler warnings in fbcon code and matroxfb driver (Arnd Bergmann)

- convert fbdev susbsytem to using %pOF instead of full_name (Rob Herring)

- structures constifications (Arvind Yadav, Bhumika Goyal, Gustavo A. R.
  Silva, Julia Lawall)

- misc cleanups (Gustavo A. R. Silva, Hyun Kwon, Julia Lawall, Kuninori
  Morimoto, Lynn Lei)


Anton Vasilyev (1):
  video: fbdev: udlfb: Fix use after free on dlfb_usb_probe error path

Arnd Bergmann (2):
  fbcon: mark dummy functions 'inline'
  fbdev: matrox: hide unused 'hotplug' variable

Arvind Yadav (35):
  video: fbdev: uvesafb: constify attribute_group structures.
  omapfb: panel-tpo-td043mtea1: constify attribute_group structures.
  omapfb: panel-sony-acx565akm: constify attribute_group structures.
  video: fbdev: radeon: constify pci_device_id.
  video: fbdev: atyfb: constify pci_device_id.
  video: fbdev: aty128fb: constify pci_device_id.
  video: fbdev: sunxvr2500: constify pci_device_id.
  video: fbdev: asiliantfb: constify pci_device_id.
  video: fbdev: intelfb: constify pci_device_id.
  video: fbdev: pvr2fb: constify pci_device_id.
  video: fbdev: tridentfb: constify pci_device_id.
  video: fbdev: skeletonfb: constify pci_device_id.
  video: fbdev: via: constify pci_device_id.
  video: fbdev: savage: constify pci_device_id.
  video: fbdev: riva: constify pci_device_id.
  video: fbdev: i810: constify pci_device_id.
  video: fbdev: arkfb: constify pci_device_id.
  video: fbdev: kyro: constify pci_device_id.
  video: fbdev: vermilion: constify pci_device_id.
  video: fbdev: nvidia: constify pci_device_id.
  video: fbdev: mb862xx: constify pci_device_id.
  video: fbdev: tdfx: constify pci_device_id.
  video: fbdev: sunxvr500: constify pci_device_id.
  video: fbdev: imsttfb: constify pci_device_id.
  video: fbdev: pm2fb: constify pci_device_id.
  video: fbdev: gxfb: constify pci_device_id.
  video: fbdev: neofb: constify pci_device_id.
  video: fbdev: s3fb: constify pci_device_id.
  video: fbdev: pm3fb: constify pci_device_id.
  video: fbdev: matroxfb: constify pci_device_id.
  video: fbdev: vt8623fb: constify pci_device_id.
  video: fbdev: smscufx: constify usb_device_id.
  video: fbdev: udlfb: constify usb_device_id.
  video: fm2fb: constify zorro_device_id
  video: ARM CLCD: constify amba_id

Bhumika Goyal (7):
  drivers/video/fbdev/omap/lcd_mipid.c: add const to lcd_panel structure
  video: fbdev: add const to bin_attribute structures
  fbdev: matrox: make fb_ops const
  fbdev: i810: make fb_ops const
  video: fbdev: annotate fb_fix_screeninfo with const and __initconst
  video: fbdev: 

Re: [Outreachy kernel] [PATCH v3 4/4] drm/agpsupport: Remove extra blank line

[Julia Lawall]

On Thu, 14 Sep 2017, Meghana Madhyastha wrote:

> Remove extra blank line to adhere to standard coding style.
> Found by checkpath.pl..
>
> Signed-off-by: Meghana Madhyastha 
> ---
> Changes in v3:
>  -This was part of another commit in v2 and v1.
>   Now made this a separate commit
>
>  drivers/gpu/drm/drm_agpsupport.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_agpsupport.c 
> b/drivers/gpu/drm/drm_agpsupport.c
> index a0510557..737f028 100644
> --- a/drivers/gpu/drm/drm_agpsupport.c
> +++ b/drivers/gpu/drm/drm_agpsupport.c
> @@ -373,7 +373,6 @@ int drm_agp_free(struct drm_device *dev, struct 
> drm_agp_buffer *request)
>  EXPORT_SYMBOL(drm_agp_free);
>
>
> -

This looks better.

But you got some Reviewed-by: annotations from Sean. You should preserve
them on the next version.

julia

>  int drm_agp_free_ioctl(struct drm_device *dev, void *data,
>  struct drm_file *file_priv)
>  {
> --
> 2.7.4
>
> --
> You received this message because you are subscribed to the Google Groups 
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/outreachy-kernel/9cfc7e7535908f3fe3b1df706f2999687c90d4e7.1505376068.git.meghana.madhyastha%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH libdrm] freedreno/kgsl: fix pointer-to-int cast

[Eric Engestrom]

Fixes this warning:

freedreno/kgsl/kgsl_ringbuffer.c: In function ‘kgsl_ringbuffer_flush’:
freedreno/kgsl/kgsl_ringbuffer.c:149:19: warning: cast from pointer to integer 
of different size [-Wpointer-to-int-cast]
   req.timestamp = (uint32_t)kgsl_ring->bo->hostptr;
   ^

Signed-off-by: Eric Engestrom 
---
 freedreno/kgsl/kgsl_ringbuffer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/freedreno/kgsl/kgsl_ringbuffer.c b/freedreno/kgsl/kgsl_ringbuffer.c
index e4696b1b..f09c433b 100644
--- a/freedreno/kgsl/kgsl_ringbuffer.c
+++ b/freedreno/kgsl/kgsl_ringbuffer.c
@@ -146,7 +146,7 @@ static int kgsl_ringbuffer_flush(struct fd_ringbuffer 
*ring, uint32_t *last_star
ibdesc.gpuaddr = kgsl_ring->bo->gpuaddr;
ibdesc.hostptr = kgsl_ring->bo->hostptr;
ibdesc.sizedwords = 0x145;
-   req.timestamp = (uint32_t)kgsl_ring->bo->hostptr;
+   req.timestamp = (uintptr_t)kgsl_ring->bo->hostptr;
}
 
do {
-- 
Cheers,
  Eric

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm v3] etnaviv: prevent deadlock in error path

[Eric Engestrom]

On Wednesday, 2017-09-13 16:08:19 +0200, Philipp Zabel wrote:
> If drmPrimeFDToHandle fails in etna_bo_from_dmabuf, the function must
> not return with the table_lock mutex held. Unlock the mutex in the error
> path.
> 
> Based on ceb70a6b1015 ("freedreno: prevent deadlock in error path").
> 
> Signed-off-by: Philipp Zabel 
> Reviewed-by: Eric Engestrom 
> ---
> v3: fix the commit message to correspond to the code in v2/v3

Thanks, pushed now :)

> ---
>  etnaviv/etnaviv_bo.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/etnaviv/etnaviv_bo.c b/etnaviv/etnaviv_bo.c
> index 4fe877f1..78b9cd27 100644
> --- a/etnaviv/etnaviv_bo.c
> +++ b/etnaviv/etnaviv_bo.c
> @@ -206,10 +206,15 @@ struct etna_bo *etna_bo_from_dmabuf(struct etna_device 
> *dev, int fd)
>   int ret, size;
>   uint32_t handle;
>  
> + /* take the lock before calling drmPrimeFDToHandle to avoid
> +  * racing against etna_bo_del, which might invalidate the
> +  * returned handle.
> +  */
>   pthread_mutex_lock(_lock);
>  
>   ret = drmPrimeFDToHandle(dev->fd, fd, );
>   if (ret) {
> + pthread_mutex_unlock(_lock);
>   return NULL;
>   }
>  
> -- 
> 2.11.0
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 4/4] drm/agpsupport: Remove extra blank line

[Meghana Madhyastha]

Remove extra blank line to adhere to standard coding style.
Found by checkpath.pl..

Signed-off-by: Meghana Madhyastha 
---
Changes in v3:
 -This was part of another commit in v2 and v1.
  Now made this a separate commit

 drivers/gpu/drm/drm_agpsupport.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_agpsupport.c b/drivers/gpu/drm/drm_agpsupport.c
index a0510557..737f028 100644
--- a/drivers/gpu/drm/drm_agpsupport.c
+++ b/drivers/gpu/drm/drm_agpsupport.c
@@ -373,7 +373,6 @@ int drm_agp_free(struct drm_device *dev, struct 
drm_agp_buffer *request)
 EXPORT_SYMBOL(drm_agp_free);
 
 
-
 int drm_agp_free_ioctl(struct drm_device *dev, void *data,
   struct drm_file *file_priv)
 {
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 0/4] drm/agpsupport: Code cleanup

[Meghana Madhyastha]

Removes checkpath.pl errors and warnings.

Changes in v3:
 -Change commit title prefix from drm to drm/agpsupport
 -Split the commit "Move EXPORT_SYMBOL so that it immediately follows its
 function" into two commits. Removing the extra blank line is 
 now a separate commit.
 -Included merging conditionals in "Remove assignment in if condition"
 in the commit message

Meghana Madhyastha (4):
  drm/agpsupport: Replace "foo * bar" with "foo *bar"
  drm/agpsupport: Remove assignment in if condition
  drm/agpsupport: Move EXPORT_SYMBOL so that it immediately follows its
function
  drm/agpsupport: Remove extra blank line

 drivers/gpu/drm/drm_agpsupport.c | 45 
 1 file changed, 23 insertions(+), 22 deletions(-)

-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 2/4] drm/agpsupport: Remove assignment in if condition

[Meghana Madhyastha]

Move the assignment so that it happens before the if condition.
Merged multiple similar conditionals to a single conditional statement.
This results in syntax which is easier to read.

Found by checkpath.pl

Signed-off-by: Meghana Madhyastha 
---
Changes in v3:
 -Added "Merged multiple similar conditionals" to the commit
 message.
 
 drivers/gpu/drm/drm_agpsupport.c | 31 ++-
 1 file changed, 18 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/drm_agpsupport.c b/drivers/gpu/drm/drm_agpsupport.c
index d9e8cdd..860d57a 100644
--- a/drivers/gpu/drm/drm_agpsupport.c
+++ b/drivers/gpu/drm/drm_agpsupport.c
@@ -101,7 +101,8 @@ int drm_agp_acquire(struct drm_device *dev)
return -ENODEV;
if (dev->agp->acquired)
return -EBUSY;
-   if (!(dev->agp->bridge = agp_backend_acquire(dev->pdev)))
+   dev->agp->bridge = agp_backend_acquire(dev->pdev);
+   if (!dev->agp->bridge)
return -ENODEV;
dev->agp->acquired = 1;
return 0;
@@ -203,12 +204,14 @@ int drm_agp_alloc(struct drm_device *dev, struct 
drm_agp_buffer *request)
 
if (!dev->agp || !dev->agp->acquired)
return -EINVAL;
-   if (!(entry = kzalloc(sizeof(*entry), GFP_KERNEL)))
+   entry = kzalloc(sizeof(*entry), GFP_KERNEL);
+   if (!entry)
return -ENOMEM;
 
pages = (request->size + PAGE_SIZE - 1) / PAGE_SIZE;
type = (u32) request->type;
-   if (!(memory = agp_allocate_memory(dev->agp->bridge, pages, type))) {
+   memory = agp_allocate_memory(dev->agp->bridge, pages, type);
+   if (!memory) {
kfree(entry);
return -ENOMEM;
}
@@ -275,9 +278,8 @@ int drm_agp_unbind(struct drm_device *dev, struct 
drm_agp_binding *request)
 
if (!dev->agp || !dev->agp->acquired)
return -EINVAL;
-   if (!(entry = drm_agp_lookup_entry(dev, request->handle)))
-   return -EINVAL;
-   if (!entry->bound)
+   entry = drm_agp_lookup_entry(dev, request->handle);
+   if (!entry || !entry->bound)
return -EINVAL;
ret = drm_unbind_agp(entry->memory);
if (ret == 0)
@@ -316,12 +318,12 @@ int drm_agp_bind(struct drm_device *dev, struct 
drm_agp_binding *request)
 
if (!dev->agp || !dev->agp->acquired)
return -EINVAL;
-   if (!(entry = drm_agp_lookup_entry(dev, request->handle)))
-   return -EINVAL;
-   if (entry->bound)
+   entry = drm_agp_lookup_entry(dev, request->handle);
+   if (!entry || entry->bound)
return -EINVAL;
page = (request->offset + PAGE_SIZE - 1) / PAGE_SIZE;
-   if ((retcode = drm_bind_agp(entry->memory, page)))
+   retcode = drm_bind_agp(entry->memory, page);
+   if (retcode)
return retcode;
entry->bound = dev->agp->base + (page << PAGE_SHIFT);
DRM_DEBUG("base = 0x%lx entry->bound = 0x%lx\n",
@@ -359,7 +361,8 @@ int drm_agp_free(struct drm_device *dev, struct 
drm_agp_buffer *request)
 
if (!dev->agp || !dev->agp->acquired)
return -EINVAL;
-   if (!(entry = drm_agp_lookup_entry(dev, request->handle)))
+   entry = drm_agp_lookup_entry(dev, request->handle);
+   if (!entry)
return -EINVAL;
if (entry->bound)
drm_unbind_agp(entry->memory);
@@ -398,11 +401,13 @@ struct drm_agp_head *drm_agp_init(struct drm_device *dev)
 {
struct drm_agp_head *head = NULL;
 
-   if (!(head = kzalloc(sizeof(*head), GFP_KERNEL)))
+   head = kzalloc(sizeof(*head), GFP_KERNEL);
+   if (!head)
return NULL;
head->bridge = agp_find_bridge(dev->pdev);
if (!head->bridge) {
-   if (!(head->bridge = agp_backend_acquire(dev->pdev))) {
+   head->bridge = agp_backend_acquire(dev->pdev);
+   if (!head->bridge) {
kfree(head);
return NULL;
}
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Resizeable PCI BAR support V8

[Bjorn Helgaas]

On Mon, Jul 10, 2017 at 04:59:48PM +0200, Christian König wrote:
> Hi everyone,
> 
> This is the eighth incarnation of this set of patches. It enables device
> drivers to resize and most likely also relocate the PCI BAR of devices 
> they manage to allow the CPU to access all of the device local memory at once.
> 
> This is very useful for GFX device drivers where the default PCI BAR is only
> about 256MB in size for compatibility reasons, but the device easily have
> multiple gigabyte of local memory.
> 
> Some changes since the last version:
> 1. Rebased on Linus current master tree, going to rebase on 4.13-rc1 as soon 
> as that is out.
> 2. Some more documentation on how to use the new functionality in drivers.
> 3. Only re-enable decoding when everything looks good.
> 4. Rename the new amdgpu function to better match what it is doing.
> 
> Bjorn what's you'r feeling on getting this into 4.14?

This seems 99.9% done, but there were some kbuild issues that need to be
resolved.  Or did I miss the resolution of those?

Bjorn
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 1/4] drm/agpsupport: Replace "foo * bar" with "foo *bar"

[Meghana Madhyastha]

This replaces all instances of foo * bar with foo *bar
in drm_agpsupport.c. This is so that it adheres to
standard C syntax for pointers.

Signed-off-by: Meghana Madhyastha 
---
Changes in v3:
 -None

 drivers/gpu/drm/drm_agpsupport.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_agpsupport.c b/drivers/gpu/drm/drm_agpsupport.c
index c899534..d9e8cdd 100644
--- a/drivers/gpu/drm/drm_agpsupport.c
+++ b/drivers/gpu/drm/drm_agpsupport.c
@@ -95,7 +95,7 @@ int drm_agp_info_ioctl(struct drm_device *dev, void *data,
  * Verifies the AGP device hasn't been acquired before and calls
  * \c agp_backend_acquire.
  */
-int drm_agp_acquire(struct drm_device * dev)
+int drm_agp_acquire(struct drm_device *dev)
 {
if (!dev->agp)
return -ENODEV;
@@ -135,7 +135,7 @@ int drm_agp_acquire_ioctl(struct drm_device *dev, void 
*data,
  *
  * Verifies the AGP device has been acquired and calls \c agp_backend_release.
  */
-int drm_agp_release(struct drm_device * dev)
+int drm_agp_release(struct drm_device *dev)
 {
if (!dev->agp || !dev->agp->acquired)
return -EINVAL;
@@ -161,7 +161,7 @@ int drm_agp_release_ioctl(struct drm_device *dev, void 
*data,
  * Verifies the AGP device has been acquired but not enabled, and calls
  * \c agp_enable.
  */
-int drm_agp_enable(struct drm_device * dev, struct drm_agp_mode mode)
+int drm_agp_enable(struct drm_device *dev, struct drm_agp_mode mode)
 {
if (!dev->agp || !dev->agp->acquired)
return -EINVAL;
@@ -244,8 +244,8 @@ int drm_agp_alloc_ioctl(struct drm_device *dev, void *data,
  *
  * Walks through drm_agp_head::memory until finding a matching handle.
  */
-static struct drm_agp_mem *drm_agp_lookup_entry(struct drm_device * dev,
-  unsigned long handle)
+static struct drm_agp_mem *drm_agp_lookup_entry(struct drm_device *dev,
+   unsigned long handle)
 {
struct drm_agp_mem *entry;
 
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm/fsl-dcu: Fix DCU pixel clock issue in suspend/resume functions

[Alison Wang]

As there is not corresponding clk_prepare_enable() for
fsl_dev->pix_clk in previous contexts, clk_disable_unprepare() for
fsl_dcu->pix_clk in suspend function will fail.

This patch will add clk_prepare_enable() for fsl_dev->pix_clk in
previous contexts and resume function to fix the issue.

This patch is verified on LS1021ATWR board.

Signed-off-by: Alison Wang 
---
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c 
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
index 58e9e0601a61..875b0fdc4274 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
@@ -230,6 +230,12 @@ static int fsl_dcu_drm_pm_resume(struct device *dev)
return ret;
}
 
+   ret = clk_prepare_enable(fsl_dev->pix_clk);
+   if (ret < 0) {
+   dev_err(dev, "failed to enable dcu pix clk\n");
+   return ret;
+   }
+
if (fsl_dev->tcon)
fsl_tcon_bypass_enable(fsl_dev->tcon);
fsl_dcu_drm_init_planes(fsl_dev->drm);
@@ -351,6 +357,12 @@ static int fsl_dcu_drm_probe(struct platform_device *pdev)
goto disable_clk;
}
 
+   ret = clk_prepare_enable(fsl_dev->pix_clk);
+   if (ret < 0) {
+   dev_err(dev, "failed to enable dcu pix clk\n");
+   return ret;
+   }
+
fsl_dev->tcon = fsl_tcon_init(dev);
 
drm = drm_dev_alloc(driver, dev);
-- 
2.14.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 3/4] drm/agpsupport: Move EXPORT_SYMBOL so that it immediately follows its function

[Meghana Madhyastha]

EXPORT_SYMBOL(foo) should immediately follow its function/variable.
This coding style is preferred.
Found by checkpath.pl.

Signed-off-by: Meghana Madhyastha 
---
Changes in v3:
 -Split this commit into two commits and made another commit for
  removing the extra blank line not part of the EXPORT_SYMBOL
  warning

 drivers/gpu/drm/drm_agpsupport.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_agpsupport.c b/drivers/gpu/drm/drm_agpsupport.c
index 860d57a..a0510557 100644
--- a/drivers/gpu/drm/drm_agpsupport.c
+++ b/drivers/gpu/drm/drm_agpsupport.c
@@ -70,7 +70,6 @@ int drm_agp_info(struct drm_device *dev, struct drm_agp_info 
*info)
 
return 0;
 }
-
 EXPORT_SYMBOL(drm_agp_info);
 
 int drm_agp_info_ioctl(struct drm_device *dev, void *data,
@@ -107,7 +106,6 @@ int drm_agp_acquire(struct drm_device *dev)
dev->agp->acquired = 1;
return 0;
 }
-
 EXPORT_SYMBOL(drm_agp_acquire);
 
 /**
@@ -172,7 +170,6 @@ int drm_agp_enable(struct drm_device *dev, struct 
drm_agp_mode mode)
dev->agp->enabled = 1;
return 0;
 }
-
 EXPORT_SYMBOL(drm_agp_enable);
 
 int drm_agp_enable_ioctl(struct drm_device *dev, void *data,
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] drm/fsl-dcu: Fix the interrupt issue in suspend/resume functions

[Alison Wang]

drm_atomic_helper_suspend()/drm_atomic_helper_resume() are used in
suspend/resume functions. Interrupt can not be disabled when calling
drm_atomic_helper_resume(). Or else vblank interrupt will not generate
and the error about vblank wait timed out will occur.

This patch will enable interrupt before calling
drm_atomic_helper_resume().

The patch is verified on LS1021ATWR board.

Signed-off-by: Alison Wang 
---
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c 
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
index 875b0fdc4274..aa0393d32661 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
@@ -192,7 +192,6 @@ static int fsl_dcu_drm_pm_suspend(struct device *dev)
if (!fsl_dev)
return 0;
 
-   disable_irq(fsl_dev->irq);
drm_kms_helper_poll_disable(fsl_dev->drm);
 
console_lock();
@@ -210,6 +209,8 @@ static int fsl_dcu_drm_pm_suspend(struct device *dev)
return PTR_ERR(fsl_dev->state);
}
 
+   disable_irq(fsl_dev->irq);
+
clk_disable_unprepare(fsl_dev->pix_clk);
clk_disable_unprepare(fsl_dev->clk);
 
@@ -236,6 +237,8 @@ static int fsl_dcu_drm_pm_resume(struct device *dev)
return ret;
}
 
+   enable_irq(fsl_dev->irq);
+
if (fsl_dev->tcon)
fsl_tcon_bypass_enable(fsl_dev->tcon);
fsl_dcu_drm_init_planes(fsl_dev->drm);
@@ -246,7 +249,6 @@ static int fsl_dcu_drm_pm_resume(struct device *dev)
console_unlock();
 
drm_kms_helper_poll_enable(fsl_dev->drm);
-   enable_irq(fsl_dev->irq);
 
return 0;
 }
-- 
2.14.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 102457] [IGT] igt@kms_frontbuffer_tracking@basic blows up

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=102457

--- Comment #7 from Chris Wilson  ---
(In reply to Martin Peres from comment #4)
> (In reply to Daniel Vetter from comment #3)
> > Also changing the summary, Martin is wrong here.
> 
> And this is why we always need to trust the actual developers ;)
> 
> Sorry that my guess was wrong!

No, you were spot on.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 102457] [IGT] igt@kms_frontbuffer_tracking@basic blows up

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=102457

Chris Wilson  changed:

   What|Removed |Added

   Assignee|intel-gfx-bugs@lists.freede |dri-devel@lists.freedesktop
   |sktop.org   |.org
 QA Contact|intel-gfx-bugs@lists.freede |
   |sktop.org   |
  Component|DRM/Intel   |IGT

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101747] Steam-Game Turmoil, Segfault on start

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101747

John  changed:

   What|Removed |Added

 OS|All |Linux (All)
   Hardware|Other   |x86-64 (AMD64)
   Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
   |.org|org

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101747] Steam-Game Turmoil, Segfault on start

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101747

--- Comment #2 from John  ---
Same issue here on mesa dev with a 280X using the amdgpu kernel module on
4.13.1.

In dmesg we can see this:

[18506.679448] si_shader:2[21842]: segfault at f133abd4 ip 0834e6fc sp
e8efcc60 error 7 in runner[8048000+423000]
[18527.013339] runner[21858]: segfault at 4d0 ip f7824c02 sp
ffd7e120 error 4 in libX11.so.6.3.0[f77fa000+148000]
[18527.706432] runner[21946]: segfault at f0f24b70 ip 0834e6fc sp
ffd74050 error 7 in runner[8048000+423000]
[18527.706438] si_shader:2[21951]: segfault at ee7b62a4 ip 0834e6fc sp
e8efcb10 error 7 in runner[8048000+423000]
[18613.585254] si_shader:2[22020]: segfault at 54657369 ip f04f9739 sp
ebbfa610 error 4 in libLLVM-6.0svn.so[efdb8000+3

I've never played it before so I don't know if it's a somewhat recent breakage
or something that never worked. It works fine with "LIBGL_ALWAYS_SOFTWARE=1"
though.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 04/10] drivers:mpt: return -ENOMEM on allocation failure.

[Allen Pais]

Signed-off-by: Allen Pais 
---
 drivers/message/fusion/mptbase.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/message/fusion/mptbase.c b/drivers/message/fusion/mptbase.c
index 84eab28..7920b2b 100644
--- a/drivers/message/fusion/mptbase.c
+++ b/drivers/message/fusion/mptbase.c
@@ -4328,15 +4328,15 @@ initChainBuffers(MPT_ADAPTER *ioc)
if (ioc->ReqToChain == NULL) {
sz = ioc->req_depth * sizeof(int);
mem = kmalloc(sz, GFP_ATOMIC);
-   if (mem == NULL)
-   return -1;
+   if (!mem)
+   return -ENOMEM;
 
ioc->ReqToChain = (int *) mem;
dinitprintk(ioc, printk(MYIOC_s_DEBUG_FMT "ReqToChain alloc  @ 
%p, sz=%d bytes\n",
ioc->name, mem, sz));
mem = kmalloc(sz, GFP_ATOMIC);
-   if (mem == NULL)
-   return -1;
+   if (!mem)
+   return -ENOMEM;
 
ioc->RequestNB = (int *) mem;
dinitprintk(ioc, printk(MYIOC_s_DEBUG_FMT "RequestNB alloc  @ 
%p, sz=%d bytes\n",
@@ -4402,8 +4402,8 @@ initChainBuffers(MPT_ADAPTER *ioc)
sz = num_chain * sizeof(int);
if (ioc->ChainToChain == NULL) {
mem = kmalloc(sz, GFP_ATOMIC);
-   if (mem == NULL)
-   return -1;
+   if (!mem)
+   return -ENOMEM;
 
ioc->ChainToChain = (int *) mem;
dinitprintk(ioc, printk(MYIOC_s_DEBUG_FMT "ChainToChain alloc @ 
%p, sz=%d bytes\n",
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 01/10] arch:powerpc: return -ENOMEM on failed allocation

[Allen Pais]

Signed-off-by: Allen Pais 
---
 arch/powerpc/platforms/cell/spider-pci.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/platforms/cell/spider-pci.c 
b/arch/powerpc/platforms/cell/spider-pci.c
index d1e61e2..82aa3f7 100644
--- a/arch/powerpc/platforms/cell/spider-pci.c
+++ b/arch/powerpc/platforms/cell/spider-pci.c
@@ -106,7 +106,7 @@ static int __init spiderpci_pci_setup_chip(struct 
pci_controller *phb,
dummy_page_va = kmalloc(PAGE_SIZE, GFP_KERNEL);
if (!dummy_page_va) {
pr_err("SPIDERPCI-IOWA:Alloc dummy_page_va failed.\n");
-   return -1;
+   return -ENOMEM;
}
 
dummy_page_da = dma_map_single(phb->parent, dummy_page_va,
@@ -137,7 +137,7 @@ int __init spiderpci_iowa_init(struct iowa_bus *bus, void 
*data)
if (!priv) {
pr_err("SPIDERPCI-IOWA:"
   "Can't allocate struct spiderpci_iowa_private");
-   return -1;
+   return -ENOMEM;
}
 
if (of_address_to_resource(np, 0, )) {
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 06/10] drivers:ethernet: return -ENOMEM on allocation failure.

[Allen Pais]

Signed-off-by: Allen Pais 
---
 drivers/net/ethernet/sun/cassini.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/sun/cassini.c 
b/drivers/net/ethernet/sun/cassini.c
index 382993c..fc0ea3a 100644
--- a/drivers/net/ethernet/sun/cassini.c
+++ b/drivers/net/ethernet/sun/cassini.c
@@ -3984,7 +3984,7 @@ static inline int cas_alloc_rx_desc(struct cas *cp, int 
ring)
size = RX_DESC_RINGN_SIZE(ring);
for (i = 0; i < size; i++) {
if ((page[i] = cas_page_alloc(cp, GFP_KERNEL)) == NULL)
-   return -1;
+   return -ENOMEM;
}
return 0;
 }
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drivers:gpu:Use ARRAY_SIZE() for the size calculation of the array.

[Allen Pais]

Signed-off-by: Allen Pais 
---
 drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c 
b/drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c
index 4395a4f..0487936 100644
--- a/drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c
@@ -274,7 +274,7 @@ static const struct pctl_data pctl0_data[] = {
{0x135, 0x12a810},
{0x149, 0x7a82c}
 };
-#define PCTL0_DATA_LEN (sizeof(pctl0_data)/sizeof(pctl0_data[0]))
+#define PCTL0_DATA_LEN (ARRAY_SIZE(pctl0_data))
 
 #define PCTL0_RENG_EXEC_END_PTR 0x151
 #define PCTL0_STCTRL_REG_SAVE_RANGE0_BASE  0xa640
@@ -310,7 +310,7 @@ static const struct pctl_data pctl1_data[] = {
{0x1f0, 0x5000a7f6},
{0x1f1, 0x5000a7e4}
 };
-#define PCTL1_DATA_LEN (sizeof(pctl1_data)/sizeof(pctl1_data[0]))
+#define PCTL1_DATA_LEN (ARRAY_SIZE(pctl1_data))
 
 #define PCTL1_RENG_EXEC_END_PTR 0x1f1
 #define PCTL1_STCTRL_REG_SAVE_RANGE0_BASE  0xa000
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 3/3] drm: Remove assignment in if condition

[Meghana Madhyastha]

Move the assignment so that it happens before the if
condition. This results in syntax which is easier to read.

Found by checkpath.pl

Signed-off-by: Meghana Madhyastha 
---
 drivers/gpu/drm/drm_agpsupport.c | 31 ++-
 1 file changed, 18 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/drm_agpsupport.c b/drivers/gpu/drm/drm_agpsupport.c
index 993e486..737f028 100644
--- a/drivers/gpu/drm/drm_agpsupport.c
+++ b/drivers/gpu/drm/drm_agpsupport.c
@@ -100,7 +100,8 @@ int drm_agp_acquire(struct drm_device *dev)
return -ENODEV;
if (dev->agp->acquired)
return -EBUSY;
-   if (!(dev->agp->bridge = agp_backend_acquire(dev->pdev)))
+   dev->agp->bridge = agp_backend_acquire(dev->pdev);
+   if (!dev->agp->bridge)
return -ENODEV;
dev->agp->acquired = 1;
return 0;
@@ -200,12 +201,14 @@ int drm_agp_alloc(struct drm_device *dev, struct 
drm_agp_buffer *request)
 
if (!dev->agp || !dev->agp->acquired)
return -EINVAL;
-   if (!(entry = kzalloc(sizeof(*entry), GFP_KERNEL)))
+   entry = kzalloc(sizeof(*entry), GFP_KERNEL);
+   if (!entry)
return -ENOMEM;
 
pages = (request->size + PAGE_SIZE - 1) / PAGE_SIZE;
type = (u32) request->type;
-   if (!(memory = agp_allocate_memory(dev->agp->bridge, pages, type))) {
+   memory = agp_allocate_memory(dev->agp->bridge, pages, type);
+   if (!memory) {
kfree(entry);
return -ENOMEM;
}
@@ -272,9 +275,8 @@ int drm_agp_unbind(struct drm_device *dev, struct 
drm_agp_binding *request)
 
if (!dev->agp || !dev->agp->acquired)
return -EINVAL;
-   if (!(entry = drm_agp_lookup_entry(dev, request->handle)))
-   return -EINVAL;
-   if (!entry->bound)
+   entry = drm_agp_lookup_entry(dev, request->handle);
+   if (!entry || !entry->bound)
return -EINVAL;
ret = drm_unbind_agp(entry->memory);
if (ret == 0)
@@ -313,12 +315,12 @@ int drm_agp_bind(struct drm_device *dev, struct 
drm_agp_binding *request)
 
if (!dev->agp || !dev->agp->acquired)
return -EINVAL;
-   if (!(entry = drm_agp_lookup_entry(dev, request->handle)))
-   return -EINVAL;
-   if (entry->bound)
+   entry = drm_agp_lookup_entry(dev, request->handle);
+   if (!entry || entry->bound)
return -EINVAL;
page = (request->offset + PAGE_SIZE - 1) / PAGE_SIZE;
-   if ((retcode = drm_bind_agp(entry->memory, page)))
+   retcode = drm_bind_agp(entry->memory, page);
+   if (retcode)
return retcode;
entry->bound = dev->agp->base + (page << PAGE_SHIFT);
DRM_DEBUG("base = 0x%lx entry->bound = 0x%lx\n",
@@ -356,7 +358,8 @@ int drm_agp_free(struct drm_device *dev, struct 
drm_agp_buffer *request)
 
if (!dev->agp || !dev->agp->acquired)
return -EINVAL;
-   if (!(entry = drm_agp_lookup_entry(dev, request->handle)))
+   entry = drm_agp_lookup_entry(dev, request->handle);
+   if (!entry)
return -EINVAL;
if (entry->bound)
drm_unbind_agp(entry->memory);
@@ -394,11 +397,13 @@ struct drm_agp_head *drm_agp_init(struct drm_device *dev)
 {
struct drm_agp_head *head = NULL;
 
-   if (!(head = kzalloc(sizeof(*head), GFP_KERNEL)))
+   head = kzalloc(sizeof(*head), GFP_KERNEL);
+   if (!head)
return NULL;
head->bridge = agp_find_bridge(dev->pdev);
if (!head->bridge) {
-   if (!(head->bridge = agp_backend_acquire(dev->pdev))) {
+   head->bridge = agp_backend_acquire(dev->pdev);
+   if (!head->bridge) {
kfree(head);
return NULL;
}
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 10/10] fs:btrfs: return -ENOMEM on allocation failure.

[David Sterba]

On Wed, Sep 13, 2017 at 01:02:19PM +0530, Allen Pais wrote:
> Signed-off-by: Allen Pais 
> ---
>  fs/btrfs/check-integrity.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/btrfs/check-integrity.c b/fs/btrfs/check-integrity.c
> index 7d5a9b5..efa4c23 100644
> --- a/fs/btrfs/check-integrity.c
> +++ b/fs/btrfs/check-integrity.c
> @@ -2913,7 +2913,7 @@ int btrfsic_mount(struct btrfs_fs_info *fs_info,
>   state = kvzalloc(sizeof(*state), GFP_KERNEL);
>   if (!state) {
>   pr_info("btrfs check-integrity: allocation failed!\n");
> - return -1;
> + return -ENOMEM;

Makes sense, also please fix the -1 a few lines below that also result
from failed memory allocation, indirectly from btrfsic_dev_state_alloc().

>   }
>  
>   if (!btrfsic_is_initialized) {
> -- 
> 2.7.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 02/10] drivers:crypto: return -ENOMEM on allocation failure.

[Allen Pais]

Signed-off-by: Allen Pais 
---
 drivers/crypto/omap-aes-gcm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/crypto/omap-aes-gcm.c b/drivers/crypto/omap-aes-gcm.c
index 7d4f8a4..2542224 100644
--- a/drivers/crypto/omap-aes-gcm.c
+++ b/drivers/crypto/omap-aes-gcm.c
@@ -186,7 +186,7 @@ static int do_encrypt_iv(struct aead_request *req, u32 
*tag, u32 *iv)
sk_req = skcipher_request_alloc(ctx->ctr, GFP_KERNEL);
if (!sk_req) {
pr_err("skcipher: Failed to allocate request\n");
-   return -1;
+   return -ENOMEM;
}
 
init_completion();
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 0/3] drm: Code cleanup

[Meghana Madhyastha]

These patches fix the checkpath warnings and errors
in drm_agpsupport.c 

changes in v2:
 -Changed the commit subject prefix to follow the style used in drm.
 -Combine multiple redundant if conditions to a single condition in 
  patch 3.

Meghana Madhyastha (3):
  drm: Move EXPORT_SYMBOL so that it immediately follows its function
  drm: Replace "foo * bar" with "foo *bar"
  drm: Remove assignment in if condition

 drivers/gpu/drm/drm_agpsupport.c | 45 
 1 file changed, 23 insertions(+), 22 deletions(-)

-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 09/10] driver:video: return -ENOMEM on allocation failure.

[Allen Pais]

Signed-off-by: Allen Pais 
---
 drivers/video/fbdev/matrox/matroxfb_base.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/matrox/matroxfb_base.c 
b/drivers/video/fbdev/matrox/matroxfb_base.c
index f6a0b9a..5cd238d 100644
--- a/drivers/video/fbdev/matrox/matroxfb_base.c
+++ b/drivers/video/fbdev/matrox/matroxfb_base.c
@@ -2058,7 +2058,7 @@ static int matroxfb_probe(struct pci_dev* pdev, const 
struct pci_device_id* dumm
 
minfo = kzalloc(sizeof(*minfo), GFP_KERNEL);
if (!minfo)
-   return -1;
+   return -ENOMEM;
 
minfo->pcidev = pdev;
minfo->dead = 0;
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 01/10] arch:powerpc: return -ENOMEM on failed allocation

[Allen]

> I think the changelog for this series of conversions
> should show that you've validated the change by
> inspecting the return call chain at each modified line.
>
> Also, it seems you've cc'd the same mailing lists for
> all of the patches modified by this series.
>
> It would be better to individually address each patch
> in the series only cc'ing the appropriate maintainers
> and mailing lists.
>
> A cover letter would be good too.

 Point noted. Thanks.

- Allen
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 05/10] drivers:net: return -ENOMEM on allocation failure.

[Allen Pais]

Signed-off-by: Allen Pais 
---
 drivers/net/bonding/bond_alb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/bonding/bond_alb.c b/drivers/net/bonding/bond_alb.c
index c02cc81..89df377 100644
--- a/drivers/net/bonding/bond_alb.c
+++ b/drivers/net/bonding/bond_alb.c
@@ -864,7 +864,7 @@ static int rlb_initialize(struct bonding *bond)
 
new_hashtbl = kmalloc(size, GFP_KERNEL);
if (!new_hashtbl)
-   return -1;
+   return -ENOMEM;
 
spin_lock_bh(>mode_lock);
 
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon: Fix guard on radeon trace header

[Chuck Ebbert]

It's been that way for years...

--- a/drivers/gpu/drm/radeon/radeon_trace.h
+++ b/drivers/gpu/drm/radeon/radeon_trace.h
@@ -1,5 +1,5 @@
 #if !defined(_RADEON_TRACE_H) || defined(TRACE_HEADER_MULTI_READ)
-#define _RADEON_TRACE_H_
+#define _RADEON_TRACE_H
 
 #include 
 #include 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 2/3] drm: Replace "foo * bar" with "foo *bar"

[Meghana Madhyastha]

This replaces all instances of foo * bar with foo *bar
in drm_agpsupport.c. This is so that it adheres to
standard C syntax for pointers.

Signed-off-by: Meghana Madhyastha 
---
 drivers/gpu/drm/drm_agpsupport.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_agpsupport.c b/drivers/gpu/drm/drm_agpsupport.c
index 928248e..993e486 100644
--- a/drivers/gpu/drm/drm_agpsupport.c
+++ b/drivers/gpu/drm/drm_agpsupport.c
@@ -94,7 +94,7 @@ int drm_agp_info_ioctl(struct drm_device *dev, void *data,
  * Verifies the AGP device hasn't been acquired before and calls
  * \c agp_backend_acquire.
  */
-int drm_agp_acquire(struct drm_device * dev)
+int drm_agp_acquire(struct drm_device *dev)
 {
if (!dev->agp)
return -ENODEV;
@@ -133,7 +133,7 @@ int drm_agp_acquire_ioctl(struct drm_device *dev, void 
*data,
  *
  * Verifies the AGP device has been acquired and calls \c agp_backend_release.
  */
-int drm_agp_release(struct drm_device * dev)
+int drm_agp_release(struct drm_device *dev)
 {
if (!dev->agp || !dev->agp->acquired)
return -EINVAL;
@@ -159,7 +159,7 @@ int drm_agp_release_ioctl(struct drm_device *dev, void 
*data,
  * Verifies the AGP device has been acquired but not enabled, and calls
  * \c agp_enable.
  */
-int drm_agp_enable(struct drm_device * dev, struct drm_agp_mode mode)
+int drm_agp_enable(struct drm_device *dev, struct drm_agp_mode mode)
 {
if (!dev->agp || !dev->agp->acquired)
return -EINVAL;
@@ -241,8 +241,8 @@ int drm_agp_alloc_ioctl(struct drm_device *dev, void *data,
  *
  * Walks through drm_agp_head::memory until finding a matching handle.
  */
-static struct drm_agp_mem *drm_agp_lookup_entry(struct drm_device * dev,
-  unsigned long handle)
+static struct drm_agp_mem *drm_agp_lookup_entry(struct drm_device *dev,
+   unsigned long handle)
 {
struct drm_agp_mem *entry;
 
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 05/10] drivers:net: return -ENOMEM on allocation failure.

[Allen]

> propagates the -1. That is only called by bond_open() with:
>
> if (bond_alb_initialize(bond, (BOND_MODE(bond) == BOND_MODE_ALB)))
> return -ENOMEM;
>
> So you might want to also modify this code, to return the return
> value, rather than use the hard coded ENOMEM.
>

 I'll modify the above and send it out a separate patch.

Thank you.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 06/10] drivers:ethernet: return -ENOMEM on allocation failure.

[Allen]

>
> static int cas_alloc_rxds(struct cas *cp)
> {
> int i;
>
> for (i = 0; i < N_RX_DESC_RINGS; i++) {
> if (cas_alloc_rx_desc(cp, i) < 0) {
> cas_free_rxds(cp);
> return -1;
> }
> }
> return 0;
> }
>
> Again, your change is correct, but in the end the value is not used.
> And if you fix it at the cas_alloc_rxds level, you also need a fix at
> the next level up:
>
> err = -ENOMEM;
> if (cas_tx_tiny_alloc(cp) < 0)
> goto err_unlock;
>
> /* alloc rx descriptors */
> if (cas_alloc_rxds(cp) < 0)
> goto err_tx_tiny;
>
> again, the return value is discarded.

 I agree. I could send out v2 with fixes at both level.

- Allen
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 1/3] drm: Move EXPORT_SYMBOL so that it immediately follows its function

[Meghana Madhyastha]

EXPORT_SYMBOL(foo) should immediately follow its function/variable.
This coding style is preferred.
Found by checkpath.pl.

Signed-off-by: Meghana Madhyastha 
---
 drivers/gpu/drm/drm_agpsupport.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_agpsupport.c b/drivers/gpu/drm/drm_agpsupport.c
index c899534..928248e 100644
--- a/drivers/gpu/drm/drm_agpsupport.c
+++ b/drivers/gpu/drm/drm_agpsupport.c
@@ -70,7 +70,6 @@ int drm_agp_info(struct drm_device *dev, struct drm_agp_info 
*info)
 
return 0;
 }
-
 EXPORT_SYMBOL(drm_agp_info);
 
 int drm_agp_info_ioctl(struct drm_device *dev, void *data,
@@ -106,7 +105,6 @@ int drm_agp_acquire(struct drm_device * dev)
dev->agp->acquired = 1;
return 0;
 }
-
 EXPORT_SYMBOL(drm_agp_acquire);
 
 /**
@@ -171,7 +169,6 @@ int drm_agp_enable(struct drm_device * dev, struct 
drm_agp_mode mode)
dev->agp->enabled = 1;
return 0;
 }
-
 EXPORT_SYMBOL(drm_agp_enable);
 
 int drm_agp_enable_ioctl(struct drm_device *dev, void *data,
@@ -373,7 +370,6 @@ int drm_agp_free(struct drm_device *dev, struct 
drm_agp_buffer *request)
 EXPORT_SYMBOL(drm_agp_free);
 
 
-
 int drm_agp_free_ioctl(struct drm_device *dev, void *data,
   struct drm_file *file_priv)
 {
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 10/10] fs:btrfs: return -ENOMEM on allocation failure.

[Allen Pais]

Signed-off-by: Allen Pais 
---
 fs/btrfs/check-integrity.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/btrfs/check-integrity.c b/fs/btrfs/check-integrity.c
index 7d5a9b5..efa4c23 100644
--- a/fs/btrfs/check-integrity.c
+++ b/fs/btrfs/check-integrity.c
@@ -2913,7 +2913,7 @@ int btrfsic_mount(struct btrfs_fs_info *fs_info,
state = kvzalloc(sizeof(*state), GFP_KERNEL);
if (!state) {
pr_info("btrfs check-integrity: allocation failed!\n");
-   return -1;
+   return -ENOMEM;
}
 
if (!btrfsic_is_initialized) {
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 07/10] driver:megaraid: return -ENOMEM on allocation failure.

[Allen Pais]

Signed-off-by: Allen Pais 
---
 drivers/scsi/megaraid/megaraid_mbox.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_mbox.c 
b/drivers/scsi/megaraid/megaraid_mbox.c
index ec3c438..b09a0a6 100644
--- a/drivers/scsi/megaraid/megaraid_mbox.c
+++ b/drivers/scsi/megaraid/megaraid_mbox.c
@@ -724,8 +724,8 @@ megaraid_init_mbox(adapter_t *adapter)
 * controllers
 */
raid_dev = kzalloc(sizeof(mraid_device_t), GFP_KERNEL);
-   if (raid_dev == NULL) return -1;
-
+   if (!raid_dev)
+   return -ENOMEM;
 
/*
 * Attach the adapter soft state to raid device soft state
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 03/10] driver:gpu: return -ENOMEM on allocation failure.

[Allen Pais]

Signed-off-by: Allen Pais 
---
 drivers/gpu/drm/gma500/mid_bios.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/gma500/mid_bios.c 
b/drivers/gpu/drm/gma500/mid_bios.c
index d75ecb3..1fa1633 100644
--- a/drivers/gpu/drm/gma500/mid_bios.c
+++ b/drivers/gpu/drm/gma500/mid_bios.c
@@ -237,7 +237,7 @@ static int mid_get_vbt_data_r10(struct drm_psb_private 
*dev_priv, u32 addr)
 
gct = kmalloc(sizeof(*gct) * vbt.panel_count, GFP_KERNEL);
if (!gct)
-   return -1;
+   return -ENOMEM;
 
gct_virtual = ioremap(addr + sizeof(vbt),
sizeof(*gct) * vbt.panel_count);
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 08/10] driver:cxgbit: return -NOMEM on allocation failure.

[Allen Pais]

Signed-off-by: Allen Pais 
---
 drivers/target/iscsi/cxgbit/cxgbit_target.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/target/iscsi/cxgbit/cxgbit_target.c 
b/drivers/target/iscsi/cxgbit/cxgbit_target.c
index 514986b..47127d6 100644
--- a/drivers/target/iscsi/cxgbit/cxgbit_target.c
+++ b/drivers/target/iscsi/cxgbit/cxgbit_target.c
@@ -399,7 +399,7 @@ cxgbit_map_skb(struct iscsi_cmd *cmd, struct sk_buff *skb, 
u32 data_offset,
if (padding) {
page = alloc_page(GFP_KERNEL | __GFP_ZERO);
if (!page)
-   return -1;
+   return -ENOMEM;
skb_fill_page_desc(skb, i, page, 0, padding);
skb->data_len += padding;
skb->len += padding;
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm 1/4] amdgpu: add sync_file import and export functions

[Emil Velikov]

On 12 September 2017 at 21:43, Marek Olšák  wrote:
> From: Marek Olšák 
>
> ---
>  amdgpu/amdgpu.h| 30 ++
>  amdgpu/amdgpu_cs.c | 20 
>  2 files changed, 50 insertions(+)
>
> diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
> index 238b1aa..b44b9b6 100644
> --- a/amdgpu/amdgpu.h
> +++ b/amdgpu/amdgpu.h
> @@ -1383,6 +1383,36 @@ int amdgpu_cs_import_syncobj(amdgpu_device_handle dev,
>  uint32_t *syncobj);
>
>  /**
> + *  Export kernel sync object to a sync_file.
> + *
> + * \param   dev   - \c [in] device handle
> + * \param   syncobj- \c [in] sync object handle
> + * \param   sync_file_fd - \c [out] sync_file file descriptor.
> + *
> + * \return   0 on success\n
> + *  <0 - Negative POSIX Error code
> + *
> + */
> +int amdgpu_cs_syncobj_export_sync_file(amdgpu_device_handle dev,
> +  uint32_t syncobj,
> +  int *sync_file_fd);
> +
> +/**
> + *  Import kernel sync object from a sync_file.
> + *
> + * \param   dev   - \c [in] device handle
> + * \param   syncobj- \c [in] sync object handle
> + * \param   sync_file_fd - \c [in] sync_file file descriptor.
> + *
> + * \return   0 on success\n
> + *  <0 - Negative POSIX Error code
> + *
> + */
> +int amdgpu_cs_syncobj_import_sync_file(amdgpu_device_handle dev,
> +  uint32_t syncobj,
> +  int sync_file_fd);
> +
Did you run make check? Seems like these (and other newly introduced
symbols) are missing from amdgpu-symbol-check.

Thanks
Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm/syncobj: extract two helpers from drm_syncobj_create

[Emil Velikov]

On 14 September 2017 at 08:56, Emil Velikov  wrote:
> Hi Marek,
>
> On 12 September 2017 at 21:42, Marek Olšák  wrote:
>
>>  include/drm/drm_syncobj.h |  4 
> Please sync the header as described in
> https://cgit.freedesktop.org/mesa/drm/tree/include/drm/README#n72
>
> Tl;DR: cd .../linux; make headers_install; cp ... .../drm/include/drm;
> cd .../drm; git commit -sm " $branch $sha1..."
>
Seems like I've replied to the wrong patch - silly me.
This was meant for the libdrm ones - suggestion still applies though.

-Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm/syncobj: extract two helpers from drm_syncobj_create

[Emil Velikov]

Hi Marek,

On 12 September 2017 at 21:42, Marek Olšák  wrote:

>  include/drm/drm_syncobj.h |  4 
Please sync the header as described in
https://cgit.freedesktop.org/mesa/drm/tree/include/drm/README#n72

Tl;DR: cd .../linux; make headers_install; cp ... .../drm/include/drm;
cd .../drm; git commit -sm " $branch $sha1..."

Thank you
Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2] drm/dp: DPCD register defines for link status within ESI field

[Dhinakaran Pandiyan]

Link status is available in the ESI field on devices with DPCD r1.2 or
higher. DP spec also says "An MST upstream device shall use this field
instead of the Link/Sink Device Status field registers, starting from DPCD
Address 00200h."

v2: Prefixed DP_ (Jani)
Rewrote commment to stay within 80 cols.
Cc: Jani Nikula 
Reviewed-by: Jani Nikula 
Signed-off-by: Dhinakaran Pandiyan 
---
 include/drm/drm_dp_helper.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 2c412a15cfa1..11c39f15f1b3 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -738,6 +738,11 @@
 #define DP_RECEIVER_ALPM_STATUS0x200b  /* eDP 1.4 */
 # define DP_ALPM_LOCK_TIMEOUT_ERROR(1 << 0)
 
+#define DP_LANE0_1_STATUS_ESI  0x200c /* status same as 0x202 
*/
+#define DP_LANE2_3_STATUS_ESI  0x200d /* status same as 0x203 
*/
+#define DP_LANE_ALIGN_STATUS_UPDATED_ESI   0x200e /* status same as 0x204 
*/
+#define DP_SINK_STATUS_ESI 0x200f /* status same as 0x205 
*/
+
 #define DP_DPRX_FEATURE_ENUMERATION_LIST0x2210  /* DP 1.3 */
 # define DP_GTC_CAP(1 << 0)  /* DP 1.3 */
 # define DP_SST_SPLIT_SDP_CAP  (1 << 1)  /* DP 1.4 */
-- 
2.11.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] drm/dp: DPCD register defines for link

[Pandiyan, Dhinakaran]

On Thu, 2017-09-14 at 09:00 +0300, Jani Nikula wrote:
> On Wed, 13 Sep 2017, Dhinakaran Pandiyan  
> wrote:
> > Link status is available in the ESI field on devices with DPCD r1.2 or
> > higher. DP spec also says "An MST upstream device shall use this field
> > instead of the Link/Sink Device Status field registers, starting from DPCD
> > Address 00200h."
> >
> > Cc: Jani Nikula 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  include/drm/drm_dp_helper.h | 5 +
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> > index 2c412a15cfa1..0bf15525cdd0 100644
> > --- a/include/drm/drm_dp_helper.h
> > +++ b/include/drm/drm_dp_helper.h
> > @@ -738,6 +738,11 @@
> >  #define DP_RECEIVER_ALPM_STATUS0x200b  /* eDP 1.4 */
> >  # define DP_ALPM_LOCK_TIMEOUT_ERROR(1 << 0)
> >  
> > +#define LANE0_1_STATUS_ESI  0x200c /* Same as status in 
> > 0x202 */
> > +#define LANE2_3_STATUS_ESI  0x200d /* Same as status in 
> > 0x203 */
> > +#define LANE_ALIGN_STATUS_UPDATED_ESI   0x200e /* Same as status in 
> > 0x204 */
> > +#define SINK_STATUS_ESI 0x200f /* Same as status in 
> > 0x205 */
> 
> With the macro names prefixed with DP_,
> 

I must be blind to have not seen that. Thanks!

> Reviewed-by: Jani Nikula 
> 
> 
> > +
> >  #define DP_DPRX_FEATURE_ENUMERATION_LIST0x2210  /* DP 1.3 */
> >  # define DP_GTC_CAP(1 << 0)  /* DP 
> > 1.3 */
> >  # define DP_SST_SPLIT_SDP_CAP  (1 << 1)  /* DP 
> > 1.4 */
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Outreachy kernel] [PATCH v2 3/3] drm: Remove assignment in if condition

[Jani Nikula]

On Wed, 13 Sep 2017, Julia Lawall  wrote:
> On Wed, 13 Sep 2017, Meghana Madhyastha wrote:
>
>> Move the assignment so that it happens before the if
>> condition. This results in syntax which is easier to read.
>
> It would be nice to mention the merged conditionals in the log message.

Either way,

Reviewed-by: Jani Nikula 

>
> julia
>
>> Found by checkpath.pl
>>
>> Signed-off-by: Meghana Madhyastha 
>> ---
>>  drivers/gpu/drm/drm_agpsupport.c | 31 ++-
>>  1 file changed, 18 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_agpsupport.c 
>> b/drivers/gpu/drm/drm_agpsupport.c
>> index 993e486..737f028 100644
>> --- a/drivers/gpu/drm/drm_agpsupport.c
>> +++ b/drivers/gpu/drm/drm_agpsupport.c
>> @@ -100,7 +100,8 @@ int drm_agp_acquire(struct drm_device *dev)
>>  return -ENODEV;
>>  if (dev->agp->acquired)
>>  return -EBUSY;
>> -if (!(dev->agp->bridge = agp_backend_acquire(dev->pdev)))
>> +dev->agp->bridge = agp_backend_acquire(dev->pdev);
>> +if (!dev->agp->bridge)
>>  return -ENODEV;
>>  dev->agp->acquired = 1;
>>  return 0;
>> @@ -200,12 +201,14 @@ int drm_agp_alloc(struct drm_device *dev, struct 
>> drm_agp_buffer *request)
>>
>>  if (!dev->agp || !dev->agp->acquired)
>>  return -EINVAL;
>> -if (!(entry = kzalloc(sizeof(*entry), GFP_KERNEL)))
>> +entry = kzalloc(sizeof(*entry), GFP_KERNEL);
>> +if (!entry)
>>  return -ENOMEM;
>>
>>  pages = (request->size + PAGE_SIZE - 1) / PAGE_SIZE;
>>  type = (u32) request->type;
>> -if (!(memory = agp_allocate_memory(dev->agp->bridge, pages, type))) {
>> +memory = agp_allocate_memory(dev->agp->bridge, pages, type);
>> +if (!memory) {
>>  kfree(entry);
>>  return -ENOMEM;
>>  }
>> @@ -272,9 +275,8 @@ int drm_agp_unbind(struct drm_device *dev, struct 
>> drm_agp_binding *request)
>>
>>  if (!dev->agp || !dev->agp->acquired)
>>  return -EINVAL;
>> -if (!(entry = drm_agp_lookup_entry(dev, request->handle)))
>> -return -EINVAL;
>> -if (!entry->bound)
>> +entry = drm_agp_lookup_entry(dev, request->handle);
>> +if (!entry || !entry->bound)
>>  return -EINVAL;
>>  ret = drm_unbind_agp(entry->memory);
>>  if (ret == 0)
>> @@ -313,12 +315,12 @@ int drm_agp_bind(struct drm_device *dev, struct 
>> drm_agp_binding *request)
>>
>>  if (!dev->agp || !dev->agp->acquired)
>>  return -EINVAL;
>> -if (!(entry = drm_agp_lookup_entry(dev, request->handle)))
>> -return -EINVAL;
>> -if (entry->bound)
>> +entry = drm_agp_lookup_entry(dev, request->handle);
>> +if (!entry || entry->bound)
>>  return -EINVAL;
>>  page = (request->offset + PAGE_SIZE - 1) / PAGE_SIZE;
>> -if ((retcode = drm_bind_agp(entry->memory, page)))
>> +retcode = drm_bind_agp(entry->memory, page);
>> +if (retcode)
>>  return retcode;
>>  entry->bound = dev->agp->base + (page << PAGE_SHIFT);
>>  DRM_DEBUG("base = 0x%lx entry->bound = 0x%lx\n",
>> @@ -356,7 +358,8 @@ int drm_agp_free(struct drm_device *dev, struct 
>> drm_agp_buffer *request)
>>
>>  if (!dev->agp || !dev->agp->acquired)
>>  return -EINVAL;
>> -if (!(entry = drm_agp_lookup_entry(dev, request->handle)))
>> +entry = drm_agp_lookup_entry(dev, request->handle);
>> +if (!entry)
>>  return -EINVAL;
>>  if (entry->bound)
>>  drm_unbind_agp(entry->memory);
>> @@ -394,11 +397,13 @@ struct drm_agp_head *drm_agp_init(struct drm_device 
>> *dev)
>>  {
>>  struct drm_agp_head *head = NULL;
>>
>> -if (!(head = kzalloc(sizeof(*head), GFP_KERNEL)))
>> +head = kzalloc(sizeof(*head), GFP_KERNEL);
>> +if (!head)
>>  return NULL;
>>  head->bridge = agp_find_bridge(dev->pdev);
>>  if (!head->bridge) {
>> -if (!(head->bridge = agp_backend_acquire(dev->pdev))) {
>> +head->bridge = agp_backend_acquire(dev->pdev);
>> +if (!head->bridge) {
>>  kfree(head);
>>  return NULL;
>>  }
>> --
>> 2.7.4
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "outreachy-kernel" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to outreachy-kernel+unsubscr...@googlegroups.com.
>> To post to this group, send email to outreachy-ker...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/outreachy-kernel/20170913161531.GA3239%40meghana-HP-Pavilion-Notebook.
>> For more options, visit https://groups.google.com/d/optout.
>>

-- 
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org

Re: [PATCH] drm/dp: DPCD register defines for link status within ESI field

[Jani Nikula]

On Wed, 13 Sep 2017, Dhinakaran Pandiyan  wrote:
> Link status is available in the ESI field on devices with DPCD r1.2 or
> higher. DP spec also says "An MST upstream device shall use this field
> instead of the Link/Sink Device Status field registers, starting from DPCD
> Address 00200h."
>
> Cc: Jani Nikula 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  include/drm/drm_dp_helper.h | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 2c412a15cfa1..0bf15525cdd0 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -738,6 +738,11 @@
>  #define DP_RECEIVER_ALPM_STATUS  0x200b  /* eDP 1.4 */
>  # define DP_ALPM_LOCK_TIMEOUT_ERROR  (1 << 0)
>  
> +#define LANE0_1_STATUS_ESI  0x200c /* Same as status in 
> 0x202 */
> +#define LANE2_3_STATUS_ESI  0x200d /* Same as status in 
> 0x203 */
> +#define LANE_ALIGN_STATUS_UPDATED_ESI   0x200e /* Same as status in 
> 0x204 */
> +#define SINK_STATUS_ESI 0x200f /* Same as status in 
> 0x205 */

With the macro names prefixed with DP_,

Reviewed-by: Jani Nikula 


> +
>  #define DP_DPRX_FEATURE_ENUMERATION_LIST0x2210  /* DP 1.3 */
>  # define DP_GTC_CAP  (1 << 0)  /* DP 1.3 */
>  # define DP_SST_SPLIT_SDP_CAP(1 << 1)  /* DP 
> 1.4 */

-- 
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel