Hi Ville,
On 22 March 2018 at 15:22, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> I really just wanted to fix i915 to re-enable its planes afer load
> detection (a two line patch). This is what I actually ended up with
> after I ran into a framebuffer refcount leak with said two line patch.
>
On 20 February 2018 at 13:12, Peter Zijlstra wrote:
> On Tue, Feb 20, 2018 at 01:58:26PM +0100, Christian König wrote:
>> amdgpu needs to verify if userspace sends us valid addresses and the simplest
>> way of doing this is to check if the buffer object is locked with the ticket
>> of the current
drey Grodzovsky
Thanks for the quick fixup.
Reviewed-by: Emil Velikov
-Emil
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
On 10 November 2017 at 04:30, Andrey Grodzovsky
wrote:
> Switch from disabling tests during run to using the new disable
> API.
>
> Signed-off-by: Andrey Grodzovsky
> ---
> tests/amdgpu/amdgpu_test.c| 14 ++--
> tests/amdgpu/amdgpu_test.h| 15
> tests/amdgpu/deadlock_tests.c
On 30 November 2017 at 23:49, Sudip Mukherjee
wrote:
> Hi Daniel,
>
> On Wed, Nov 29, 2017 at 10:56:34AM +0100, Daniel Vetter wrote:
>> On Tue, Nov 28, 2017 at 12:30:30PM +, Sudip Mukherjee wrote:
>> > On Tue, Nov 28, 2017 at 12:32:38PM +0100, Greg KH wrote:
>> > > On Tue, Nov 28, 2017 at 11:2
On 27 October 2017 at 01:15, Andrey Grodzovsky
wrote:
> Change-Id: I7eafb85c1ca96d6d255f0183bed0ce4129746fe0
> Signed-off-by: Andrey Grodzovsky
> ---
> amdgpu/Makefile.sources | 1 +
> amdgpu/amdgpu.h | 20 +++
> amdgpu/amdgpu_vm.c | 52
> ++
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
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
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
On 30 August 2017 at 10:51, Michel Dänzer wrote:
> From: Michel Dänzer
>
> xserver 1.13.0 was released on September 6th, 2012, almost 5 years ago.
>
> This allows cleaning up a bunch of backwards compatibility code.
>
Hell yeah ;-) FWIW
Reviewed-by: Emil Velikov
Some n
On 30 August 2017 at 09:04, Michel Dänzer wrote:
> On 29/08/17 07:56 PM, Emil Velikov wrote:
>> On 28 August 2017 at 10:23, Michel Dänzer wrote:
>>> From: Michel Dänzer
>>>
>>> And destroy all other FBs. This is so that other DRM masters can only
>>>
Hi Michel,
On 28 August 2017 at 10:23, Michel Dänzer wrote:
> From: Michel Dänzer
>
> And destroy all other FBs. This is so that other DRM masters can only
> get access to this all-black FB, not to any other FB we created, while
> we're switched away and not DRM master.
>
Isn't the issue applica
Hi all,
Can anyone skim through this patch?
Thanks
Emil
On 22 January 2017 at 18:48, Emil Velikov wrote:
> All one needs is to establish if dev->fd is the flink (primary/card)
> node, rather than use DRM_IOCTL_GET_CLIENT to query the auth status.
>
> The latter is [somewhat]
On 10 August 2017 at 20:29, Joe Kniss wrote:
> On Wed, Aug 9, 2017 at 4:13 PM, Joe Kniss wrote:
>> On Wed, Aug 9, 2017 at 12:14 PM, Noralf Trønnes wrote:
>>>
>>> Den 09.08.2017 01.42, skrev Joe Kniss:
Because all drivers currently use gem objects for framebuffer planes,
the virtua
Hi Dave,
On 18 July 2017 at 04:52, Dave Airlie wrote:
> +int amdgpu_cs_submit_raw(amdgpu_device_handle dev,
> +amdgpu_context_handle context,
> +amdgpu_bo_list_handle bo_list_handle,
> +int num_chunks,
> +
Hi Alex,
On 20 July 2017 at 03:46, Alex Xie wrote:
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c
> @@ -198,12 +198,18 @@ amdgpu_bo_list_get(struct amdgpu_fpriv *fpriv, int id)
> result = idr_find(&fpriv->bo_list_handles, id);
>
>
On 19 July 2017 at 11:18, Chih-Wei Huang wrote:
> Define two macros to avoid building errors.
>
> Fixes: 7e6bf88cac (amdgpu: move asic id table to a separate file)
>
> Signed-off-by: Chih-Wei Huang
> ---
> amdgpu/Android.mk | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/amdgpu/An
On 11 July 2017 at 10:15, Christian König wrote:
> From: Christian König
>
> This reverts commit 6b79c66b841dded6ffa6b56f14e4eb10a90a7c07
> and commit 6afadeaf13279fcdbc48999f522e1dc90a9dfdaf.
>
If/when you're going ahead with this please squash a revert for
25712f1d35f6f64167ede45d3dc72a410f367c
On 6 July 2017 at 13:46, Deucher, Alexander wrote:
>> Attach it to analogous primitive?
>
> Radeon libdrm is much different than amdgpu. There is no analog.
>
Upon a closer look, indeed there isn't. Must have gotten confused earlier.
>>
>> > I think the current radeon API is simpler. Maybe a fo
On 5 July 2017 at 22:31, Li, Samuel wrote:
>> - above all, as-is make check will fail
> Right, I did not check that.
>
>> - keeping the radeon API symmetrical to the amdgpu one would a good idea
> The issue is Radeon does not have a struct similar to amdgpu_device_handle.
Attach it to analogous
On 5 July 2017 at 11:44, Chih-Wei Huang wrote:
> 2017-07-05 17:35 GMT+08:00 Emil Velikov :
>> On 4 July 2017 at 07:40, Chih-Wei Huang wrote:
>>>
>>> Unfortunately this patch breaks Android build
>>> since the two macros are not defined.
>>>
>>&g
Hi Samuel,
On 30 June 2017 at 20:25, Samuel Li wrote:
> Change-Id: I24b6624789d1a9dc0fd3a446b0e6f21ed5183ff2
> Signed-off-by: Samuel Li
> ---
> radeon/Makefile.am | 6 +++
> radeon/Makefile.sources | 6 ++-
> radeon/radeon_asic_id.c | 106
>
On 30 June 2017 at 20:24, Samuel Li wrote:
Commit message should explain why we want this - aka "Will be reused
in radeon with a later commit"
> Change-Id: Iac1c4870253e8b8860a61b7cf175e7a25cc95921
> Signed-off-by: Samuel Li
> ---
> Makefile.sources | 10 +-
> amdgpu/Makefile.am
Dänzer]
>> * Move amdgpu.ids to new data directory
>> * Remove placeholder entries from amdgpu.ids
>> * Set libdrmdatadir variable in configure.ac instead of Makefile.am
>> [Emil Velikov]
>> * Use isblank() instead of open-coding it [Emil Velikov]
>> * Don't leak asi
On 16 June 2017 at 09:08, zhoucm1 wrote:
>
> ping...?
>
Normally you want to send patches as plain text (ideally git
send-email), so that people can reply/comment inline.
But above all a summary of the "requirements" and "how it's achieved"
helps your colleagues, amongst others ;-)
-Emil
On 15 June 2017 at 04:16, Michel Dänzer wrote:
> On 14/06/17 08:34 PM, Emil Velikov wrote:
>> On 13 June 2017 at 10:45, Michel Dänzer wrote:
>>> From: Xiaojie Yuan
>>>
>>> v2: fix an off by one error and leading white spaces
>>> v3: use thread s
u.ids
> * Set libdrmdatadir variable in configure.ac instead of Makefile.am
> [Emil Velikov]
> * Use isblank() instead of open-coding it [Emil Velikov]
> * Don't leak asic_id_table memory if realloc fails [Emil Velikov]
> * Check and bump table_max_size at the begin
On 7 June 2017 at 09:40, Michel Dänzer wrote:
> On 06/06/17 10:43 PM, Emil Velikov wrote:
>> On 31 May 2017 at 21:22, Samuel Li wrote:
>>
>>> --- /dev/null
>>> +++ b/amdgpu/amdgpu_asic_id.c
>>
>>> +static int parse_one_line(const char *line, st
Hi Samuel,
With all the other discussion aside here is some code specific input
which I'd hope you agree with.
On 31 May 2017 at 21:22, Samuel Li wrote:
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -45,6 +45,9 @@ AM_DISTCHECK_CONFIGURE_FLAGS = \
>
> pkgconfigdir = @pkgconfigdir@
> pkgconfig_D
On 30 May 2017 at 22:59, Li, Samuel wrote:
>> - Marketing can make mistakes or have IT glitches The inconsistent use of
>> "(TM)" and using a 67C2:00 is something one wants to double-check with them.
> Marketing names are there for a lot of reasons. The code here is to pass the
> names only.
>
Hi all,
Pardon for dropping in uninvited. Just some food for thought.
On 29 May 2017 at 22:01, Li, Samuel wrote:
> Understood your point. However as discussed internally before, marketing
> names are there for a lot of reasons; my understanding of the policy is we do
> not need to touch them a
Hi Gerd,
I did not have the change to follow through the discussion.
Pardon if my suggestion have already been discussed.
On 2 May 2017 at 14:34, Gerd Hoffmann wrote:
> It's unused.
>
> Suggested-by: Daniel Vetter
> Signed-off-by: Gerd Hoffmann
> ---
> include/uapi/drm/drm_fourcc.h | 2 --
On 22 April 2017 at 07:47, Edward O'Callaghan
wrote:
> Suggested-by: Emil Velikov
> Signed-off-by: Edward O'Callaghan
Reviewed-by: Emil Velikov
Thanks
Emil
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedes
Hi Edward,
On 18 April 2017 at 17:20, Edward O'Callaghan
wrote:
[snip]
> if (NULL == sem->signal_fence.context)
> return -EINVAL;
I think this hunk can be fixed as well.
-Emi
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.or
Hi Dave,
On 12 April 2017 at 05:57, Dave Airlie wrote:
> +struct drm_syncobj_handle {
> + __u32 handle;
> + /** Flags.. only applicable for handle->fd */
> + __u32 flags;
> +
> + __s32 fd;
> +};
I think this struct need a __u32 pad as well.
Thanks
Emil
__
ess, the amdgpu and ati patches are
Reviewed-by: Emil Velikov
Thanks
Emil
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
On 7 April 2017 at 21:15, Felix Kuehling wrote:
> Advertise CIK PCI IDs only when they are not supported by amdgpu.
> Use the CONFIG_DRM_AMDGPU_CIK to check so that a single option in
> the kernel config keeps both drivers in sync.
>
> This is the simplest possible change. A more complete solution
when it's
> not in Linus's tree.
>
I'm not Dave, so pardon for dropping in.
AFAICT the idea is that once the feature is within a non-rebase branch
such as drm-next, it's part of the ABI. As such one can use it across
the board - be that in here, Mesa or elsewhere.
That said, the series looks great. Thanks for the updates gents.
Acked-by: Emil Velikov
Thanks
Emil
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
;
> return 0;
One can drop the intermediate "r" here
return vi_set_uvd_clock(adev, dclk, ixCG_DCLK_CNTL, ixCG_DCLK_STATUS);
Either way both patches are correct. so FWIW
Reviewed-by: Emil Velikov
-Emil
___
amd-gfx mailing list
Hi Dave,
Barring the other discussions, allow me to put a couple of trivial suggestions:
Please re-wrap the long lines to follow existing code style.
On 14 March 2017 at 00:50, Dave Airlie wrote:
> @@ -882,6 +894,12 @@ int amdgpu_cs_submit(amdgpu_context_handle context,
>
On 7 March 2017 at 00:45, Emil Velikov wrote:
> I have another ~20 patch series that builds on top ;-)
>
Correction - those are xf86-video-amdgpu ones independent of this series.
Pardon for the noise.
Emil
___
amd-gfx mailing list
a
On 22 January 2017 at 18:48, Emil Velikov wrote:
> All one needs is to establish if dev->fd is the flink (primary/card)
> node, rather than use DRM_IOCTL_GET_CLIENT to query the auth status.
>
> The latter is [somewhat] deprecated and incorrect. We need to know [and
> store] t
On 2 March 2017 at 03:52, Andres Rodriguez wrote:
>
>
> On 2017-02-28 08:13 PM, Emil Velikov wrote:
>>
>> Hi Andres,
>>
>> There's a couple of nitpicks below, but feel free to address those as
>> follow-up. Considering they're correct of course ;
Hi David,
On 1 March 2017 at 07:09, zhoucm1 wrote:
>>> +ctx->priority = priority;
>>
>> seems not used.
>
> I see ctx->priority is used in following patches, so pls remove it there.
>
Fwiw, I don't think that's a good idea.
Most places in the kernel are OK if you add plumbing with patch X a
Hi Harry,
On 1 March 2017 at 00:26, Harry Wentland wrote:
> Change-Id: I48d38e4d0224c9f0e52055b3c4ddef8e872b3dac
> Signed-off-by: Harry Wentland
> Acked-by: Harry Wentland
> Reviewed-by: Jordan Lazare
> Reviewed-by: Tony Cheng
> ---
> drivers/gpu/drm/amd/display/Makefile | 2 ++
> 1 file cha
rm_file *filp)
> {
> int r;
> - uint32_t id;
> + uint32_t id, priority;
>
> union drm_amdgpu_ctx *args = data;
> struct amdgpu_device *adev = dev->dev_private;
> struct amdgpu_fpriv *fpriv = filp->driver_priv;
>
> r = 0;
> id = args->in.ctx_id;
> + priority = args->in.priority;
>
Hmm we don't seem to be doing any in.flags validation - not cool.
Someone seriously wants to add that and check the remaining ioctls.
At the same time - I think you want to add a flag bit "HAS_PRIORITY"
[or similar] and honour in.priority only when that is set.
Even if the USM drivers are safe, this will break on a poor soul that
is learning how to program their GPU. "My program was running before -
I updated the kernel and it no longer does :-("
Either way, the patch is:
Reviewed-by: Emil Velikov
-Emil
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
On 23 February 2017 at 17:18, Joe Perches wrote:
> On Thu, 2017-02-23 at 09:28 -0600, Rob Herring wrote:
>> On Fri, Feb 17, 2017 at 1:11 AM, Joe Perches wrote:
>> > There are ~4300 uses of pr_warn and ~250 uses of the older
>> > pr_warning in the kernel source tree.
>> >
>> > Make the use of pr_w
On 20 February 2017 at 15:22, Mao, David wrote:
> Thanks for the Info, but it seems the PACKAGE_VERSION is not the version i am
> looking for.
> Is there any ways that libdrm.so/libdrm_amdgpu.so can provide in the runtime
> to indicate the ABI state besides the SO_VERSION?
> I may want to compil
On 20 February 2017 at 09:20, Mao, David wrote:
> Hi Jerry & Christian,
> Regarding to the version control, what is the rule of bumping the
> PACKAGE_VERSION of libdrm?
> We may need something, like the size of gpu_info structure or the something
> like PACKAGE VERSION of the running libdrm_amdg
On 15 February 2017 at 14:47, Harry Wentland wrote:
> On 2017-02-15 06:44 AM, Emil Velikov wrote:
>>
>> On 14 February 2017 at 20:36, Harry Wentland
>> wrote:
>>>
>>> Also make the code somewhat more readable.
>>>
>> I'd suggest reachi
On 14 February 2017 at 20:36, Harry Wentland wrote:
> Also make the code somewhat more readable.
>
I'd suggest reaching to the team to integrate scripts/checkpatch.pl in
the pre-commit hook.
It will help you improve the coding standard and, as you mentioned, it
"make[s] the code somewhat more rea
On 8 February 2017 at 12:34, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> This is a new kernel interface.
>
> Signed-off-by: Nicolai Hähnle
> ---
> include/drm/amdgpu_drm.h | 2 ++
Hi Nicolai,
Please see the "When and how to update these files" section in the README
-Emil
_
On 7 February 2017 at 11:30, Tom St Denis wrote:
> On 07/02/17 06:02 AM, Emil Velikov wrote:
>>
>> On 6 February 2017 at 22:39, StDenis, Tom wrote:
>>>
>>>
>>> Apparently I missed the bottom of your reply (all of the clients I have
>>> outlook
to read ;-)
* Dependency tracking (pkg-config + foo.pc), incremental builds - ($CC
... -MM -MP ...), tarballs.
> Tom
>
>
> From: amd-gfx on behalf of StDenis,
> Tom
> Sent: Monday, February 6, 2017 16:33
> To: Emil Velikov; Tom St Denis
> Cc:
Hi Tom,
On 5 February 2017 at 22:24, Tom St Denis wrote:
> (v2): Use findLibDRM script instead of directly finding path
>
Since the project already depends on libdrm you might want to use the
drmDevice2 API and drop the iteration over all PCI devices
(libpciaccess dependency).
If the former is l
u: Free/uninit vamgr_32 in theoretically correct order
> amdgpu: vamgr can be a struct instead of a pointer
> amdgpu: vamgr_32 can be a struct instead of a pointer
>
Nice cleanups/fixes indeed.
Fwiw
Reviewed-by: Emil Velikov
Unless someone beats me to it I'll collect all the
On 31 January 2017 at 15:43, Deucher, Alexander
wrote:
>> -Original Message-
>> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
>> Of Dieter Nützel
>> Sent: Tuesday, January 31, 2017 6:25 AM
>> To: Michel Dänzer
>> Cc: Alex Deucher; mesa-...@lists.freedesktop.org; am
Hi Andrey,
Unrelated suggestion:
A handy trick - to save yourself a bit of time (and "get it right")
you can use `git format-patch -vX ...' [it also works with send-email]
to have the version in the subject prefix.
Feel free to share it with the team - it seems that many people
manually edit the
s passed on render node.
>BO export/import test was skipped
>
> Signed-off-by: Alex Xie
I haven't done too in-depth review by the series looks a lot better.
Thanks again for addressing my suggestions !
Reviewed-by: Emil Velikov
-Emil
Hi Alex,
Things look a lot better imho. There's some ideas below, for the
future if you/others see value in them. Please do not worry about
those now.
On 24 January 2017 at 22:29, Alex Xie wrote:
> Verify the vender ID and driver name.
> Open all AMDGPU devices.
> Provide an option to open rende
On 24 January 2017 at 22:39, Xie, AlexBin wrote:
> Hi Emil,
>
> Point 1 will be left for future patch.
>
Definitely. I did not mean to ask/push you to address that here.
> Current error message is following.
> Error: Permission denied. Hint:Try to run this test program as root.
>
> I am thinking
On 23 January 2017 at 16:14, Nicolai Hähnle wrote:
> I don't think is correct. The incoming handle is in shared_handle, not in
> handle. Once the code block around line 310 has executed, shared_handle is
> the handle produced by drmPrimeFDToHandle, and closing it on error (as the
> code currently
On 20 January 2017 at 22:08, Xie, AlexBin wrote:
> HI Emil,
>
>
> See below.
>
>
> Thanks,
>
> Alex
>
>
>
> ________
> From: Emil Velikov
> Sent: Friday, January 20, 2017 8:24 AM
> To: Xie, AlexBin
> Cc: amd-gfx mailing l
Do not close the handle if someone else has created it. Afaict there's
no change of ownership implied if the function fails. Thus the caller is
responsible to doing the right thing - trying again, closing the handle
and/or other.
Cc: amd-gfx@lists.freedesktop.org
Signed-off-by: Emil Ve
r buffer import/export sharing.
Cc: amd-gfx@lists.freedesktop.org
Signed-off-by: Emil Velikov
---
Again not 100% sure but things look quite fishy as-is... The
conditionals might be off.
Note: original code [and this one] do not consider if flink_fd is
already set, thus as we dup we'll leak it
Cc: amd-gfx@lists.freedesktop.org
Signed-off-by: Emil Velikov
---
amdgpu/amdgpu_bo.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/amdgpu/amdgpu_bo.c b/amdgpu/amdgpu_bo.c
index d30fd1e7..c9f31587 100644
--- a/amdgpu/amdgpu_bo.c
+++ b/amdgpu/amdgpu_bo.c
@@ -302,6 +302,7 @@ int
On 20 January 2017 at 19:14, Xie, AlexBin wrote:
> Hi Emil,
>
>
> Thanks for the comments.
>
>
> Please see below.
>
>
> Regards,
>
> Alex Bin Xie
>
>
>
> ____
> From: Emil Velikov
> Sent: Friday, January 20, 2017
HI Alex,
A couple of small idea(s) for future work (?).
On 19 January 2017 at 22:53, Alex Xie wrote:
> Tested:
> 1. As root, tests passed on primary.
Add auth mechanism and request run outside of X environment (switching
to TTY should work).
Then adjust the suggestion s/run as root/run in TTY/ ?
On 19 January 2017 at 22:53, Alex Xie wrote:
> This can be used to test multiple GPUs
>
> Signed-off-by: Alex Xie
> ---
> tests/amdgpu/amdgpu_test.c | 25 -
> 1 file changed, 20 insertions(+), 5 deletions(-)
>
> diff --git a/tests/amdgpu/amdgpu_test.c b/tests/amdgpu/amdgp
Hi Alex,
Thanks for doing this. There's a few nitpicks on top of what David and
Christian has spotted.
On 19 January 2017 at 22:53, Alex Xie wrote:
> Verify the vender ID and driver name.
> Open all AMDGPU devices.
> Provide an option to open render node.
>
> Tested as root: PASS
> Tested as non
On 9 January 2017 at 18:34, Andres Rodriguez wrote:
> Generated using make headers_install from:
> airlied/drm-next 3806a27 Merge tag 'drm-misc-next-2016-12-30' ...
> +
> drm/radeon: define RADEON_TILING_R600_NO_SCANOUT
>
> By adding RADEON_TILING_R600_NO_SCANOUT to the kernel tree we no longer
>
gt;
> To solve the problem, add the define on the kernel side.
>
> RADEON_TILING_R600_NO_SCANOUT is consumed by the radeon Mesa/Gallium
> driver.
>
It may look a bit iffy to have it here, but it's a bit late to change it now.
Fwiw
Rev
On 12 January 2017 at 01:29, Edward O'Callaghan
wrote:
> Hi Xie,
>
> Perhaps you want to use `fprintf(stderr, "...")` over `printf("..")` and
> lose the space before the start parenthesis. Also, line wrap
> your commit message.
>
> Side note, use git send-email so that the patch is inline and not
On 9 January 2017 at 16:44, Christian König wrote:
> Am 09.01.2017 um 17:39 schrieb Emil Velikov:
>>
>> On 9 January 2017 at 11:18, Arindam Nath wrote:
>>
>>> v2:
>>> * Generated using make headers_install.
>>
On 9 January 2017 at 11:18, Arindam Nath wrote:
> v2:
> * Generated using make headers_install.
> * Generated from linux-stable/master commit
> a121103c922847ba5010819a3f250f1f7fc84ab8
>
The above is either wrong or you've done manual changes. Both of which
are _not_ cool.
Please be more caref
On 5 January 2017 at 00:29, Andres Rodriguez wrote:
> This patch is for reference only, as the corresponding kernel change is
> still under review.
>
Obviously one would sync this in a similar fashion to 1/3 but as-is
this is pretty good.
> Signed-off-by: Andres Rodriguez
> ---
> include/drm/am
Thank you Andres. There's a small nit below.
On 5 January 2017 at 00:29, Andres Rodriguez wrote:
> Generated using make headers_install from:
> airlied/drm-next 2cf026a Merge branch 'linux-4.10' ...
>
> Manually re-added missing RADEON_TILING_R600_NO_SCANOUT as documented on
> README
>
"Thou Shal
Hi Andres,
Pardon for jumping in uninvited, there's a few comments below that you
might find useful.
On 4 January 2017 at 01:56, Andres Rodriguez wrote:
> --- a/configure.ac
> +++ b/configure.ac
> @@ -20,7 +20,7 @@
>
> AC_PREREQ([2.63])
> AC_INIT([libdrm],
> -[2.4.74],
> +[2.4
On 21 December 2016 at 15:04, Sagalovitch, Serguei
wrote:
>> Intel has managed to get there
> I am not 100% sure.
> E.g.
> http://www.phoronix.com/scan.php?page=article&item=intel-win10-mesa121&num=1
>
> In general Intel driver under Linux is still behind MS Windows
> version.
>
The article is
On 19 December 2016 at 12:53, StDenis, Tom wrote:
>
> Hi Emil,
>
Hey there, Tom.
Seems my "ignoring the heat around DC/DAL ..." wasn't enough and
things have gone there :-(
Cutting down to the important piece...
>
> It's a bit of a catch. The public (re: Linux) wants open, stable, efficient,
Hi Harry,
On 14 December 2016 at 16:26, Harry Wentland wrote:
> They are still used all over the place (e.g.
> dc/dce110/dce110_resource.c:413).
>
> We should at least do an spatch to use kzalloc/krealloc/kfree across the
> board if the wrappers are an issue.
>
> NAKed
>
[Ignoring all the heat ar
On 15 December 2016 at 07:30, Nath, Arindam wrote:
>>-Original Message-
>>From: Emil Velikov [mailto:emil.l.veli...@gmail.com]
>>Sent: Wednesday, December 14, 2016 9:26 PM
>>To: Nath, Arindam
>>Cc: David Airlie; Deucher, Alexander; amd-gfx mailing list; ML
On 12 December 2016 at 18:51, wrote:
> From: Arindam Nath
>
> User might want to query the maximum number of UVD
> instances supported by firmware. In addition to that,
> if there are multiple applications using UVD handles
> at the same time, he might also want to query the
> currently used num
On 12 December 2016 at 18:49, wrote:
> From: Arindam Nath
>
> Change History
> --
>
> v3: changes suggested by Christian
> - Add a check for UVD IP block using AMDGPU_HW_IP_UVD
> query type.
> - Add a check for asic_type to be less than
> CHIP_POLARIS10 since starting Polaris, we
On 1 December 2016 at 06:11, zhoucm1 wrote:
> Hi Dave,
>
> As the attached, our Vulkan team is verifying it.
>
David, please read through the following documents when designing
ioctls [1] and [im]porting the UABI to libdrm [2].
Thanks
Emil
[1]
https://git.kernel.org/cgit/linux/kernel/git/torval
Hi Michel,
On 22 November 2016 at 07:58, Michel Dänzer wrote:
> From: Michel Dänzer
>
> (Ported from radeon commit 1106b2f773ad0611c729b27f4c192a26b43ef1e7)
>
> Signed-off-by: Michel Dänzer
> ---
> +static Bool drmmode_probe_page_flip_target(AMDGPUEntPtr pAMDGPUEnt)
> +{
> +#ifdef DRM_CAP_PAGE
On 8 November 2016 at 08:44, Michel Dänzer wrote:
> On 07/11/16 08:30 PM, Emil Velikov wrote:
>> On 7 November 2016 at 09:14, Michel Dänzer wrote:
>>> On 05/11/16 03:14 AM, Emil Velikov wrote:
>>>> On 2 November 2016 at 03:07, Michel Dänzer wrote:
>>>
On 7 November 2016 at 11:43, Emil Velikov wrote:
> On 7 November 2016 at 09:09, Michel Dänzer wrote:
>
>> +static struct amdgpu_asic_id_table_t {
>> + uint32_t did;
>> + uint32_t rid;
>> + char marketing_name[64];
> Using a char * here might b
On 7 November 2016 at 09:09, Michel Dänzer wrote:
> +static struct amdgpu_asic_id_table_t {
> + uint32_t did;
> + uint32_t rid;
> + char marketing_name[64];
Using a char * here might be a better. From a quick look [64] is quite wasteful.
-Emil
__
On 7 November 2016 at 09:14, Michel Dänzer wrote:
> On 05/11/16 03:14 AM, Emil Velikov wrote:
>> On 2 November 2016 at 03:07, Michel Dänzer wrote:
>>>
>>> The first attached patch will result in drmParsePciDeviceInfo always
>>> reporting revision 0 on kerne
HI all,
On 2 November 2016 at 03:07, Michel Dänzer wrote:
>
> The first attached patch will result in drmParsePciDeviceInfo always
> reporting revision 0 on kernels without the second attached patch. Will
> that be an issue for the amdgpu-pro stack?
>
> Please follow up directly to the patch e-ma
On 9 September 2016 at 12:24, Christian König wrote:
> Hi Hawking,
>
>> Removing the flag will make ttm_mem_type_from_place skip counting the
>> corresponding placement and thus have impact on mem region create and bo
>> movement.
>
> And that is exactly the reason why I want to remove the unused
On 9 September 2016 at 15:30, Christian König wrote:
> Am 09.09.2016 um 15:54 schrieb Emil Velikov:
>>
>> On 9 September 2016 at 12:24, Christian König
>> wrote:
>>>
>>> Hi Hawking,
>>>
>>>> Removing the flag will make ttm_mem_type_f
On 19 August 2016 at 03:09, Michel Dänzer wrote:
> On 19/08/16 11:02 AM, Yu, Qiang wrote:
>>
>> Each point of the patch set is not broken. Patches are arranged like
>> this to show how I do it:
>> 1. create a pageflip.c to host common page flip code
>> 2. copy amdgpu DDX DRI2 page flip code to mod
Hi Qiang,
On 17 August 2016 at 11:29, Qiang Yu wrote:
> Hi guys,
>
> This patch set is for adding DRI2 page flip support to modesetting
> driver. I mainly take reference of amdgpu DDX and reuse present
> page flip code in the modesetting driver.
>
> Regards,
> Qiang
>
> Qiang Yu (6):
> modesett
101 - 195 of 195 matches
Mail list logo
