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
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
>
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
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
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
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
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
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 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 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 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
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
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
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
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
=> 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
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
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
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:
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
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 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
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]
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
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;
>>
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
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
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.___
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://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
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
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_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,
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.
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
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
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-
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
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/
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
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
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
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
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
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
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
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
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
Hi Lucas,
[auto build test ERROR on drm/drm-next]
[also build test ERROR on next-20170411]
[cannot apply to v4.11-rc6]
[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/Lucas-Stach/drm-etnaviv
https://bugs.freedesktop.org/show_bug.cgi?id=93341
--- Comment #26 from Jean-François Fortin Tam ---
OK, I've got good news... Julien, thanks to the crazy furry donut "torture
test" you suggested, I was able to finally pinpoint the real trigger for this
bug.
My understanding is that on Radeons (
Linus Walleij writes:
> On Tue, Apr 11, 2017 at 3:18 AM, Eric Anholt wrote:
>
>> From: Tom Cooksey
>
> Well that can be debated at this point. I think it should have
> your Author: tag and just Tom in the Signed-off-by, then mention
> the history in the commit message.
>
>> This is a modesettin
On Wed, Apr 12, 2017 at 04:57:54AM +0800, Jeffy Chen wrote:
> 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
https://bugzilla.kernel.org/show_bug.cgi?id=195295
--- Comment #3 from Eugene Shalygin (eugene.shaly...@gmail.com) ---
Tried 4.10.6, which was free of this bug at the time I used it, but now it show
the same behaviour. Here is a part from dmesg:
[ 21.074717] usb 3-1: new high-speed USB device n
Russell King - ARM Linux writes:
> 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 COMPIL
On Tue, Apr 11, 2017 at 01:45:01PM -0700, Eric Anholt wrote:
> Yannick Fertre writes:
> > +static void ltdc_crtc_disable(struct drm_crtc *crtc)
> > +{
> > + struct ltdc_device *ldev = crtc_to_ltdc(crtc);
> > + struct drm_pending_vblank_event *event = crtc->state->event;
> > +
> > + DRM_DEBUG
Yannick Fertre writes:
> This controller provides output signals to interface directly a variety
> of LCD and TFT panels. These output signals are: RGB signals
> (up to 24bpp), vertical & horizontal synchronisations, data enable and
> the pixel clock.
>
> Signed-off-by: Yannick Fertre
> ---
> d
On Mon, Apr 10, 2017 at 01:06:46PM -0700, Eric Anholt wrote:
> Gustavo Padovan writes:
>
> > From: Gustavo Padovan
> >
> > Add support to async updates of cursors by using the new atomic
> > interface for that. Basically what this commit does is do what
> > vc4_update_plane() did but through ato
On Mon, Apr 10, 2017 at 12:55:33PM -0700, Eric Anholt wrote:
> Gustavo Padovan writes:
>
> > From: Gustavo Padovan
> >
> > In some cases, like cursor updates, it is interesting to update the
> > plane in an asynchronous fashion to avoid big delays.
> >
> > The current queued update could be stil
Hi Dave,
I have a lonely pull request for you. Just the patch you asked me to pick up
this morning.
drm-misc-fixes-2017-04-11:
Core changes:
- None
Driver changes
- udl: Fix unaligned memory access on SPARC (Jonathan)
Cheers, Sean
The following changes since commit a71c9a1c779f2499fb2afc0
drm-tip/drm-tip boot: 122 boots: 4 failed, 117 passed with 1 offline
(v4.11-rc6-1898-g1a8653e657e1)
Full Boot Summary:
https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1898-g1a8653e657e1/
Full Build Summary:
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11
On Mon, Apr 10, 2017 at 2:27 PM, Dave Airlie wrote:
> On 10 April 2017 at 19:03, Laurent Pinchart
> wrote:
>> Hi Thierry,
>>
>> On Monday 10 Apr 2017 09:17:59 Thierry Reding wrote:
>>> On Sun, Apr 09, 2017 at 01:31:40PM +0100, Emil Velikov wrote:
>>> > Hi Thierry,
>>> >
>>> > I don't mean to stir
https://bugs.freedesktop.org/show_bug.cgi?id=98996
--- Comment #2 from Christoph Haag ---
Created attachment 130804
--> https://bugs.freedesktop.org/attachment.cgi?id=130804&action=edit
performance with amd-staging-4.9 and mesa git
Screenshot with out of the box performance on latest amd-stagi
On 2017-04-11 12:37 PM, James Jones wrote:
On 04/11/2017 09:09 AM, Harry Wentland wrote:
On 2017-04-11 11:15 AM, James Jones wrote:
On 04/10/2017 11:20 PM, Daniel Vetter wrote:
On Tue, Apr 11, 2017 at 7:52 AM, Daniel Vetter wrote:
On Tue, Apr 11, 2017 at 6:14 AM, Nikhil Mahale
wrote:
My na
drm-tip/drm-tip boot: 120 boots: 3 failed, 117 passed
(v4.11-rc6-1889-g328f79e8c2dc)
Full Boot Summary:
https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1889-g328f79e8c2dc/
Full Build Summary:
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1889-g328f
Chris Wilson writes:
> On Mon, Apr 10, 2017 at 06:44:14PM -0700, Eric Anholt wrote:
>> This is needed for proper synchronization with display on another DRM
>> device (pl111 or tinydrm) with buffers produced by vc4 V3D. Fixes the
>> new igt vc4_dmabuf_poll testcase, and rendering of one of the g
On Tue, Apr 11, 2017 at 1:11 PM, Alastair Bridgewater
wrote:
> 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
2017-04-11 Daniel Vetter :
> freedesktop.org has adopted a formal&enforced code of conduct:
>
> https://www.fooishbar.org/blog/fdo-contributor-covenant/
> https://www.freedesktop.org/wiki/CodeOfConduct/
>
> Besides formalizing things a bit more I don't think this changes
> anything for us, we've
On Tue, Apr 11, 2017 at 12:09 PM, Daniel Vetter wrote:
> On Tue, Apr 11, 2017 at 5:50 PM, Alex Deucher wrote:
>> On Tue, Apr 11, 2017 at 2:48 AM, Daniel Vetter
>> wrote:
>>> freedesktop.org has adopted a formal&enforced code of conduct:
>>>
>>> https://www.fooishbar.org/blog/fdo-contributor-cov
On Fri, Apr 7, 2017 at 12:33 PM, Thierry Reding wrote:
> On Fri, Apr 07, 2017 at 05:44:15AM +1000, Dave Airlie wrote:
>> On 5 April 2017 at 16:51, Laurent Pinchart
>> wrote:
>> > As the DRM LVDS panel driver uses a different approach to DT bindings
>> > compared to what Thierry Reding advocates,
drm-tip/drm-tip boot: 128 boots: 5 failed, 121 passed with 2 offline
(v4.11-rc6-1886-g20c20ad1f78a)
Full Boot Summary:
https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1886-g20c20ad1f78a/
Full Build Summary:
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11
On 04/10/2017 11:47 PM, Laurent Pinchart wrote:
> Hi Laura,
>
> Thank you for the patch.
>
> On Monday 03 Apr 2017 11:57:55 Laura Abbott wrote:
>> When CMA was first introduced, its primary use was for DMA allocation
>> and the only way to get CMA memory was to call dma_alloc_coherent. This
>> pu
The HDMI driver is currently enabling all clks and probe time and keep
the power-domain connected to the HDMI encoder enabled.
Move all activation code to vc4_hdmi_encoder_enable() and make sure
the clks and power domain are released when the HDMI encoder is not used
by adding deactivation steps i
On 04/11/2017 09:09 AM, Harry Wentland wrote:
On 2017-04-11 11:15 AM, James Jones wrote:
On 04/10/2017 11:20 PM, Daniel Vetter wrote:
On Tue, Apr 11, 2017 at 7:52 AM, Daniel Vetter wrote:
On Tue, Apr 11, 2017 at 6:14 AM, Nikhil Mahale
wrote:
My name is Nikhil Mahale, and I work at NVIDIA in
On Sat, Apr 8, 2017 at 3:45 PM, Fabio Estevam wrote:
> Thierry/Rob,
>
> On Tue, Feb 7, 2017 at 10:48 PM, Fabio Estevam wrote:
>> On Tue, Feb 7, 2017 at 9:36 PM, Rob Herring wrote:
>>
>>> Except I have no way of knowing whether: a) you omitted a supply
>>> because you don't (yet) care, b) the pan
GPU cores with the DYNAMIC_FREQUENCY_SCALING feature bit set expect the
platform to provide the clock scaling and ignore any requests to use the
internal FSCALE divider. Writes to this register still work, but don't
have any effect on the GPU clock frequency.
Save the initial core and shader clock
Daniel Vetter writes:
> freedesktop.org has adopted a formal&enforced code of conduct:
>
> https://www.fooishbar.org/blog/fdo-contributor-covenant/
> https://www.freedesktop.org/wiki/CodeOfConduct/
>
> Besides formalizing things a bit more I don't think this changes
> anything for us, we've alrea
drm-tip/drm-tip boot: 135 boots: 5 failed, 129 passed with 1 offline
(v4.11-rc6-1880-g52e53d64fa4a)
Full Boot Summary:
https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1880-g52e53d64fa4a/
Full Build Summary:
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11
Linus Walleij writes:
> On Tue, Apr 11, 2017 at 3:18 AM, Eric Anholt wrote:
>
>> From: Tom Cooksey
>
> Well that can be debated at this point. I think it should have
> your Author: tag and just Tom in the Signed-off-by, then mention
> the history in the commit message.
I'm happy giving credit
On Tue, Apr 11, 2017 at 5:50 PM, Alex Deucher wrote:
> On Tue, Apr 11, 2017 at 2:48 AM, Daniel Vetter wrote:
>> freedesktop.org has adopted a formal&enforced code of conduct:
>>
>> https://www.fooishbar.org/blog/fdo-contributor-covenant/
>> https://www.freedesktop.org/wiki/CodeOfConduct/
>>
>> Be
On 2017-04-11 11:15 AM, James Jones wrote:
On 04/10/2017 11:20 PM, Daniel Vetter wrote:
On Tue, Apr 11, 2017 at 7:52 AM, Daniel Vetter wrote:
On Tue, Apr 11, 2017 at 6:14 AM, Nikhil Mahale
wrote:
My name is Nikhil Mahale, and I work at NVIDIA in the Linux drivers
team.
I have been working o
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 necessary to move the register definitions there, when
> they're already ava
drm-tip/drm-tip build: 207 builds: 1 failed, 206 passed, 45 warnings
(v4.11-rc6-1898-g1a8653e657e1)
Full Build Summary:
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1898-g1a8653e657e1/
Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc6-1898-g1a8653e657e1
Git Commit: 1a8
1 - 100 of 166 matches
Mail list logo