From: Dave Airlie
sync_file uses the reference count of the file, the internal
kref was never getting moved past 1.
We can reintroduce this if we decide we need it later.
Signed-off-by: Dave Airlie
---
drivers/dma-buf/sync_file.c | 13 ++---
include/linux/sync_file.h | 1 -
2 files
On Wed, Apr 12, 2017 at 09:37:02AM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> sync_file uses the reference count of the file, the internal
> kref was never getting moved past 1.
>
> We can reintroduce this if we decide we need it later.
>
> Signed-off-by: Dave Airlie
Reviewed-by: Chris
commit e7e11f995642 ("drm/vmwgfx: fix integer overflow in
vmw_surface_define_ioctl()")
ensures that each req->mip_levels[i] <= DRM_VMW_MAX_MIP_LEVELS, It would be
easy to
conclude that the sum of req->mip_levels[i] (i = 0, ...,
DRM_VMW_MAX_SURFACE_FACES - 1)
is less than or equal to (DRM_VMW_MAX
Now that we have the InfoFrame data being provided, for the most
part, program the hardware to use it.
While we're here, and since the functionality will come in handy
for supporting 3D stereoscopy, implement setting the Vendor
("generic") InfoFrame.
Also don't enable any AVI or Vendor InfoFrame
Hi,
This is a follow up of my questions around exynos-rng [1].
Changes since v4:
=
1. Patch 2/2: Use "stdrng" name, as suggested by Herbert.
2. Patch 2/2: Add Bartlomiej's reviewed-by.
Changes since v3:
=
1. New patch: 1/2 for ALIGN_DOWN macro. The change in metag
Now that we have mechanism by which to pass mode-dependent HDMI
InfoFrames to the low-level hardware driver, it is incumbent upon
us to do so.
Signed-off-by: Alastair Bridgewater
---
drivers/gpu/drm/nouveau/nv50_display.c | 30 +-
1 file changed, 29 insertions(+), 1 d
Now that we have the InfoFrame data being provided, for the most
part, program the hardware to use it.
While we're here, and since the functionality will come in handy
for supporting 3D stereoscopy, implement setting the Vendor
("generic"?) InfoFrame.
Also don't enable any AVI or Vendor InfoFrame
Few parts of kernel define their own macro for aligning down so provide
a common define for this, with the same usage and assumptions as existing
ALIGN.
Convert also three existing implementations to this one.
Signed-off-by: Krzysztof Kozlowski
---
The metag change was not even compiled due to
Replace existing hw_ranndom/exynos-rng driver with a new, reworked one.
This is a driver for pseudo random number generator block which on
Exynos4 chipsets must be seeded with some value. On newer Exynos5420
chipsets it might seed itself from true random number generator block
but this is not impl
thanks for the work, but could you please split that patch?
It looks like you are doing several things at once and it isn't really
easy to review like this. And it isn't bisectable.
If there are clean ups here, please do it in a seperate patch. I
highly doubt that it all has to be done within one
Sent from my iPhone
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Mon, Apr 10, 2017 at 12:55 PM, Herbert Xu
wrote:
> On Sat, Apr 08, 2017 at 03:32:45PM +0200, Krzysztof Kozlowski wrote:
>>
>> +static struct rng_alg exynos_rng_alg = {
>> + .generate = exynos_rng_generate,
>> + .seed = exynos_rng_seed,
>> + .seedsize
HDMI InfoFrames are passed to NVKM as bags of bytes, but the
hardware needs them to be packed into words. Rather than having
four (or more) copies of the packing logic introduce a single copy
now, in a central place.
We currently need these for AVI and Vendor InfoFrames, but we may
also expect to
Hi Sean,
On 04/11/2017 04:31 AM, Sean Paul wrote:
On Mon, Apr 10, 2017 at 06:00:45PM +0800, Jeffy Chen wrote:
After unbinding drm, the user space may still owns the drm dev fd,
and may trigger fb release after cleanup mode config.
Add a sanity check to prevent that.
Signed-off-by: Jeffy Chen
While highly unlikely, this makes sure that the string built from
engine names won't be processed as a format string.
Signed-off-by: Kees Cook
---
drivers/gpu/drm/i915/intel_hangcheck.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_hangcheck.c
b/
Hi,
this patch replaces the old hwmon_device_register with the new
hwmon_device_register_with_info.
I've tested it on my laptop with a GeForceGT 425M and it doesn't break anything.
--- linux/drivers/gpu/drm/nouveau/nouveau_hwmon.c.orig 2017-04-11
18:27:15.477623009 +0200
+++ linux/drivers/gpu/
HDMI 3D mode support, round three. Rebased to drm-next as it was on
Sunday morning. Overall structure is the same as v2.
Substantially rewrote the first patch (nv50_head_atomic_check_mode())
since a recent change to the calculation of m->v.blankus caused a
merge conflict and problems with frame-
Now that we have the InfoFrame data being provided, for the most
part, program the hardware to use it.
While we're here, and since the functionality will come in handy
for supporting 3D stereoscopy, implement setting the Vendor
("generic"?) InfoFrame.
Also don't enable any InfoFrame that is not p
Frame-packing modes add an extra vtotal raster lines to each frame
above and beyond what the basic mode description calls for.
Account for this during scaler configuration (possibly a bit of a
hack), during CRTC configuration (clearly not a hack), and when
checking that a mode is valid for a given
On 10.04.2017 23:29, Christophe JAILLET wrote:
If 'devm_reset_control_get' returns an error, then we erroneously return
success because error code is taken from 'host->clk' instead of
'host->rst'.
Fixes: b386c6b73ac6 ("gpu: host1x: Support module reset")
Signed-off-by: Christophe JAILLET
---
On Mon, Apr 10, 2017 at 06:18:01PM -0700, Eric Anholt wrote:
> v5: Move register definitions inside the driver directory, fix build
> in COMPILE_TEST and !AMBA mode.
Why is it necessary to move the register definitions there, when
they're already available in linux/amba/clcd.h and are required
Enable stereoscopic output for HDMI and DisplayPort connectors on
NV50+ (G80+) hardware. We do not enable stereoscopy on older
hardware in case there is some older board that still has HDMI
output but for which we have no logic for setting the Vendor
InfoFrame.
With this, I get an obvious 3D outp
The nouveau driver, in the Linux 3.7 days, used to try and set the
AVI InfoFrame based on the selected display mode. These days, it
uses a fixed set of InfoFrames. Start to correct that, by
providing a mechanism whereby InfoFrame data may be passed to the
NVKM functions that do the actual configu
Hi Sean,
On 04/11/2017 03:26 AM, Sean Paul wrote:
On Mon, Apr 10, 2017 at 06:00:43PM +0800, Jeffy Chen wrote:
Hi Jeffy,
Thanks for sending this up again.
Verified on rk3399 chromebook kevin, no more crashes during unbind/bind drm.
I'm assuming this is on the chromeos-4.4 kernel? If so, you
Verified on rk3399 chromebook kevin(with cros 4.4 kernel), no more crashes
during unbind/bind drm.
Changes in v7:
Address Sean Paul 's comments.
Update commit message.
Changes in v6:
Address Daniel Vetter 's comments.
Changes in v5:
Fix wrong git account.
Changes in v2:
Fix some commit messag
We are freeing all framebuffers in drm_mode_config_cleanup without
sync the drm_file's fbs list.
So if someone try to unbind drm before release drm dev fd, the fbs
list would remain some invalid fb references. And that would cause
crash later in drm_fb_release.
Add a sanity check to prevent that.
drm_mode_set_crtcinfo() does compensation for interlace and
doublescan timing effects already, so do it first and use the
compensated figures instead of the constant "vscan / ilace" terms
that we had before.
And then it turns out that the hardware model for how the timing
parameters are configured
On Tue, Apr 11, 2017 at 09:30:53AM -0400, Sean Paul wrote:
> On Fri, Apr 07, 2017 at 10:02:29PM +0200, Jonathan Neuschäfer wrote:
> > On SPARC, the udl driver filled my kernel log with these messages:
> >
> > [186668.910612] Kernel unaligned access at TPC[76609c]
> > udl_render_hline+0x13c/0x3a0
From: Wei Yongjun
Add the missing unlock before return from function etnaviv_gpu_submit()
in the error handling case.
Fixes: f3cd1b064f11 ("drm/etnaviv: (re-)protect fence allocation with
GPU mutex")
Signed-off-by: Wei Yongjun
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 3 ++-
1 file changed,
After unbinding drm, the user space may still owns the drm dev fd,
and may still be able to call drm ioctl.
We're using an unplugged state to prevent something like that, so
let's reuse it here.
Signed-off-by: Jeffy Chen
Reviewed-by: Sean Paul
---
Changes in v7:
Address Sean Paul 's comments.
Now that we have the InfoFrame data being provided, for the most
part, program the hardware to use it.
While we're here, and since the functionality will come in handy
for supporting 3D stereoscopy, implement setting the Vendor
("generic"?) InfoFrame.
Also don't enable any InfoFrame that is not p
On Tue, Apr 11, 2017 at 09:06:31AM -0700, Eric Anholt wrote:
> Russell King - ARM Linux writes:
>
> > On Mon, Apr 10, 2017 at 06:18:01PM -0700, Eric Anholt wrote:
> >> v5: Move register definitions inside the driver directory, fix build
> >> in COMPILE_TEST and !AMBA mode.
> >
> > Why is it n
My previous patch (c5d8fac2bf drm: Unplug drm device when unregistering
it) calls drm_unplug_dev when unregistering drm dev. But if open_count
is 0, the unplug will try to unregister the drm dev again and cause
deadlock.
Fix it by dropping drm_unplug_dev and use drm_device_set_plug_state
directly
drm-tip/drm-tip build: 207 builds: 1 failed, 206 passed, 45 warnings
(v4.11-rc6-1901-gf27f076a9b50)
Full Build Summary:
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1901-gf27f076a9b50/
Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc6-1901-gf27f076a9b50
Git Commit: f27
https://bugzilla.kernel.org/show_bug.cgi?id=195295
--- Comment #4 from Michel Dänzer (mic...@daenzer.net) ---
It could be Mesa, there was an intermittent regression there which caused it to
unnecessarily power up GPUs.
--
You are receiving this mail because:
You are watching the assignee of the
https://bugs.freedesktop.org/show_bug.cgi?id=98996
--- Comment #3 from Michel Dänzer ---
Might be worth investigating the buffer waits, e.g. 80 ms corresponds to almost
5 display refresh cycles.
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=100618
--- Comment #9 from Michel Dänzer ---
Something like
valgrind %command%
in the game's Properties -> Launch Options should work.
--
You are receiving this mail because:
You are the assignee for the bug.___
2017년 04월 11일 17:01에 Tobias Jakobi 이(가) 쓴 글:
> Inki Dae wrote:
>>
>>
>> 2017년 04월 10일 19:27에 Tobias Jakobi 이(가) 쓴 글:
>>> Inki Dae wrote:
2017-03-29 20:56 GMT+09:00 Tobias Jakobi :
> Hello Daniel,
>
> same question here. Patch doesn't introduce any functional changes (just
> a
2017년 04월 11일 17:17에 Tobias Jakobi 이(가) 쓴 글:
> Another thing that I noticed. Why wasn't the v2 that ended up in your
> git ever submitted to the mailing list? Because it should have, in
> particular to spot these obvious errors.
Only comment about this.
This patch cleans up description of struc
On 11 April 2017 at 22:42, Chris Wilson wrote:
> On Tue, Apr 11, 2017 at 01:22:20PM +1000, Dave Airlie wrote:
>> +static int amdgpu_sem_lookup_and_sync(struct amdgpu_cs_parser *p,
>> + uint32_t handle)
>> +{
>> + int r;
>> + struct dma_fence *old_fence;
>>
https://bugs.freedesktop.org/show_bug.cgi?id=97861
--- Comment #10 from James Wagner ---
Same purple line on my R9 280X
Debian 9.0 (Testing)
Linux 4.10.6 with amdgpu for SI and CIK enabled (From kernel.org)
X.Org 1.19.2, from Debian.
`xrandr --output HDMI-A-0 --auto --set audio off` is a valid
Hello Tobias,
2017년 04월 11일 19:52에 Tobias Jakobi 이(가) 쓴 글:
> Hello Inki,
>
> please don't forget to review this series.
Thanks for your contribution, and don't worry about that. Will review this
series.
Just sharing a plan for -next,
I plan to have pull-request after reviewing a patch set[1]
On 11 April 2017 at 17:50, Chris Wilson wrote:
> On Tue, Apr 11, 2017 at 01:22:17PM +1000, Dave Airlie wrote:
>> From: Dave Airlie
>>
>> This object can be used to implement the Vulkan semaphores.
>>
>> The object behaviour differs from fence, in that you can
>> replace the underlying fence, and
On 12 April 2017 at 12:36, Mao, David wrote:
> Does it means we have to submit command to trigger the semaphore wait/signal?
Yes, but I think that should be fine, we need to submit a job to the
scheduler to
get the waits to happen or to have a fence to fill into the signals.
Dave.
__
On 12 April 2017 at 12:49, Mao, David wrote:
> But how to handle the semaphore wait in the vkQueuePresentkHR?
The problem here is that really we'd want the presenting process to
do the signal once it submits the work for actual presentations (be
that the X server DDX or whatever).
However that i
But how to handle the semaphore wait in the vkQueuePresentkHR?
Thanks.
Best Regards,
David
-Original Message-
From: Dave Airlie [mailto:airl...@gmail.com]
Sent: Wednesday, April 12, 2017 10:44 AM
To: Mao, David
Cc: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
Subject:
My point is it is reasonable to split the semaphore signal/wait with the
command submission.
For the signal ioctl, we could just pick the last fence in the same schedule
context, and we don't need to ask for a explicit flush or a dummy submission
trick.
The spec guarantee the signal always come
On 12 April 2017 at 13:34, Mao, David wrote:
> My point is it is reasonable to split the semaphore signal/wait with the
> command submission.
> For the signal ioctl, we could just pick the last fence in the same schedule
> context, and we don't need to ask for a explicit flush or a dummy submiss
=> we'd really want to pass a semaphore between the X server and client to do
this perfectly.
Do you means that you want X to signal the semaphore that waited by client,
through special version of xsync?
We use pretty complex tricks to build synchronization logic upon the event and
shm fence.
B
Hi Dave,
[auto build test WARNING on linus/master]
[also build test WARNING on v4.11-rc6 next-20170411]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Dave-Airlie/sync_file-get-rid-of-internal
Hi Emil,
Really sorry for late. Forgot this for a long time.
2016년 05월 12일 06:39에 Emil Velikov 이(가) 쓴 글:
> Hi Inki, all,
>
> On 10 May 2016 at 08:18, Inki Dae wrote:
>> This patch changes GPL license to X11/MIT.
>>
> As mentioned by Tobias, the commit messages should elaborate on the
> summary
drm-tip/drm-tip boot: 119 boots: 5 failed, 113 passed with 1 offline
(v4.11-rc6-1901-gf27f076a9b50)
Full Boot Summary:
https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1901-gf27f076a9b50/
Full Build Summary:
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11
From: Dave Airlie
These are just alloc and fdget interfaces needed by the drm sync
objects code.
Reviewed-by: Christian König
Reviewed-by: Daniel Vetter
Signed-off-by: Dave Airlie
---
drivers/dma-buf/sync_file.c | 21 +++--
include/linux/sync_file.h | 3 ++-
2 files change
From: Dave Airlie
This allows us to create sync files with different semantics,
and clearly define the interoperation between them it also
provides flags to allow for tweaks on those semantics.
This provides a validation interface for drivers that accept
types from userspace so they can return E
From: Dave Airlie
This patch allows the underlying fence in a sync_file to be changed
or set to NULL. This isn't currently required but for Vulkan
semaphores we need to be able to swap and reset the fence.
In order to faciliate this, it uses rcu to protect the fence,
along with a new mutex. The
Okay another day, another sync object patchset.
In my drm-syncobj branch.
This round should:
a) address the amdgpu CS ERESTARTSYS failure case, I've reworked
the sync_file/syncobj/amdgpu bits to have a lookup and just replace
in separate phases and just do the wait lookup and sync, then later
rep
From: Dave Airlie
This just adds two helper interfaces to bridge the gap from
drivers to sync_file for the semaphore objects.
These will be used by the amdgpu driver.
v2: drop one of the APIs and replace with a fence
lookup to make the amdgpu api more robust.
Signed-off-by: Dave Airlie
---
d
From: Dave Airlie
This creates a new command submission chunk for amdgpu
to add wait and signal sync objects around the submission.
Sync objects are managed via the drm syncobj ioctls.
The command submission interface is enhanced with two new
chunks, one for semaphore waiting, one for semaphore
From: Dave Airlie
This just splits out the fence depenency checking into it's
own function to make it easier to add semaphore dependencies.
Reviewed-by: Christian König
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 85 +++---
1 file change
From: Dave Airlie
This object can be used to implement the Vulkan semaphores.
The object behaviour differs from fence, in that you can
replace the underlying fence, and you cannot merge semaphores.
v2: change replace fence API to have a return value,
don't allow polling on semaphore objects,
do
From: Dave Airlie
Sync objects are new toplevel drm object, that have the same
semantics as sync_file objects, but without requiring an fd
to be consumed to support them.
This patch just enables the DRM interface to create these
objects, it doesn't actually provide any semaphore objects
or new f
Does it means we have to submit command to trigger the semaphore wait/signal?
Best Regards,
David
-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Dave
Airlie
Sent: Tuesday, April 11, 2017 11:22 AM
To: amd-...@lists.freedesktop.org; dri-devel@l
tree: git://people.freedesktop.org/~airlied/linux.git drm-syncobj
head: 58ec426a9ee099705987657cfad202b5bd96e363
commit: 58ec426a9ee099705987657cfad202b5bd96e363 [8/8] amdgpu: use sync file
for shared semaphores (v3)
config: i386-randconfig-x075-201715 (attached as .config)
compiler: gcc-6 (De
tree: git://people.freedesktop.org/~airlied/linux.git drm-syncobj
head: 58ec426a9ee099705987657cfad202b5bd96e363
commit: 0b73d1e7e4168f9c80d3c867d8366057290d82fb [3/8] drm: introduce sync
objects as sync file objects with no fd (v2.1)
config: i386-randconfig-x070-201715 (attached as .config)
c
On Tue, Apr 11, 2017 at 11:31:41AM +0800, Jeffy Chen wrote:
> After unbinding drm, the user space may still owns the drm dev fd,
> and may still be able to call drm ioctl.
>
> We're using an unplugged state to prevent something like that, so
> let's reuse it here.
>
> Signed-off-by: Jeffy Chen
>
On Tue, Apr 11, 2017 at 11:31:42AM +0800, Jeffy Chen wrote:
> We are freeing all framebuffers in drm_mode_config_cleanup without
> sync the drm_file's fbs list.
>
> So if someone try to unbind drm before release drm dev fd, the fbs
> list would remain some invalid fb references. And that would cau
101 - 166 of 166 matches
Mail list logo
