Am 08.04.2017 um 20:00 schrieb Chris Wilson:
On Sat, Apr 08, 2017 at 07:49:37PM +0200, Christian König wrote:
Am 08.04.2017 um 18:26 schrieb Chris Wilson:
Reserve 0 for general use a token meaning that the fence doesn't belong
to an ordered timeline (fence context).
NAK, we kept context alloca
On Mon 2017-03-06 12:23:41, Chris Wilson wrote:
> On Mon, Mar 06, 2017 at 01:10:48PM +0100, Pavel Machek wrote:
> > On Mon 2017-03-06 11:15:28, Chris Wilson wrote:
> > > On Mon, Mar 06, 2017 at 12:01:51AM +0100, Pavel Machek wrote:
> > > > Hi!
> > > >
> > > > > > mplayer stopped working after a wh
Hi Laurent,
Pardon for reviving this old thread. I've noticed a couple of things
which might want some attention.
On 19 November 2016 at 03:28, Laurent Pinchart
wrote:
> +
> +- panel-timing: Most display panels are restricted to a single resolution and
> + require specific display timings. The
Hi Thierry,
I don't mean to stir up anything, just voicing "my 2c" as they say.
On 7 April 2017 at 18:33, Thierry Reding wrote:
> Ever since the simple-panel binding was introduced, which is now about
> 3 1/2 years ago,
Do you have a link to these discussions? Your blog article does not
have a
Hi Dave,
Noteworthy changes this time:
1) 4k support for newer chips (ganging up hwpipes and mixers)
2) using OPP bindings for gpu
3) more prep work towards per-process pagetables
Note that this includes the patches that where in the fixes pull for
4.11. One of those patches moved around some co
Hi!
A fix for this regression has been put together and I think it's already
in drm-misc.
Thanks,
/Thomas
On 04/09/2017 01:25 PM, Tetsuo Handa wrote:
> Hello.
>
> I'm getting a boot failure (console stops) as of next-20170403~69.
> next-20170403~70 and next-20170331 boot normally.
> Would you c
On Sun, Apr 09, 2017 at 09:08:53AM +0200, Christian König wrote:
> Am 08.04.2017 um 20:00 schrieb Chris Wilson:
> >On Sat, Apr 08, 2017 at 07:49:37PM +0200, Christian König wrote:
> >>Am 08.04.2017 um 18:26 schrieb Chris Wilson:
> >>>Reserve 0 for general use a token meaning that the fence doesn't
Pekka Paalanen writes:
> we need some kind of a database to recognize HMDs in any case, right?
> It would be best if the database was shared, so that everyone could
> recognize all HMDs, at least as far as one can do that based on EDID.
Yeah, I think you've got some good ideas here. Here are som
Am 09.04.2017 um 18:02 schrieb Chris Wilson:
On Sun, Apr 09, 2017 at 09:08:53AM +0200, Christian König wrote:
Am 08.04.2017 um 20:00 schrieb Chris Wilson:
On Sat, Apr 08, 2017 at 07:49:37PM +0200, Christian König wrote:
Am 08.04.2017 um 18:26 schrieb Chris Wilson:
Reserve 0 for general use a
On Fri, Apr 07, 2017 at 04:30:11PM +0100, Chris Wilson wrote:
> Not getting hangs is a good sign, but lockdep doesn't like it:
>
> [ 460.684901] WARNING: CPU: 1 PID: 172 at kernel/workqueue.c:2418
> check_flush_dependency+0x92/0x130
> [ 460.684924] workqueue: PF_MEMALLOC task 172(kworker/1:1H)
Signed-off-by: Eric Engestrom
---
intel/intel_bufmgr_gem.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index e260f2dc..45a26da1 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -655,15 +655,14 @@ drm_intel_gem_bo_bu
From: Gustavo Padovan
virtio_gpu_cursor_plane_update() doesn't need to know the exact
value of virtio_gpu_object_reserve() return, just if it is zero or
not. Thus just use the function direct in the return.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/virtio/virtgpu_plane.c | 4 +---
1 f
From: Gustavo Padovan
Short circuit the update path for cursors and use the drm async update
infrastructure.
Signed-off-by: Gustavo Padovan
---
I wrote this mostly for testing purposes, not sure if its something that
we actually for virtio.
---
drivers/gpu/drm/virtio/virtgpu_plane.c | 42
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
mdp5_update_cursor_plane_legacy() did but through atomic.
Cc: Rob Clark
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_pla
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 atomic.
Cc: Eric Anholt
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/vc4/vc4_plane.c | 94 -
From: Gustavo Padovan
After converting legacy cursor updates to atomic async commits
mdp5_cursor_plane_funcs just duplicates mdp5_plane_funcs now.
Cc: Rob Clark
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 26 +++---
1 file changed, 3 inse
From: Gustavo Padovan
After converting legacy cursor updates to atomic async commits
intel_cursor_plane_funcs just duplicates intel_plane_funcs now.
Cc: Daniel Vetter
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/i915/intel_display.c | 13 +
1 file changed, 1 insertion(+), 12
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 still waiting for a fence to signal and
thus block and subsequent update until its scan out. In cases like this if
we
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
intel_legacy_cursor_update() did but through atomic.
Cc: Daniel Vetter
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/i915/intel_atomic_plan
From: Gustavo Padovan
Hi,
First version of Asynchronous Plane Update over Atomic. Here I looked
to msm, vc4 and i915 to identify a common pattern to create atomic helpers
for async updates. So in patch 1 drm_atomic_async_check() and
drm_atomic_helper_async_commit() are introduced along with driv
Hi,
On Thu, Mar 9, 2017 at 10:40 PM, Maxime Ripard
wrote:
> On Thu, Mar 09, 2017 at 07:20:30PM +0800, Chen-Yu Tsai wrote:
>> On Thu, Mar 9, 2017 at 6:36 PM, Maxime Ripard
>> wrote:
>> > Hi,
>> >
>> > On Thu, Mar 09, 2017 at 06:05:32PM +0800, Chen-Yu Tsai wrote:
>> >> Some Allwinner SoCs have two
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
Hello.
I'm getting a boot failure (console stops) as of next-20170403~69.
next-20170403~70 and next-20170331 boot normally.
Would you check commit 8a2398eb335c11b1b33b860ff472c53c6b1bcc43("Merge
remote-tracking branch 'drm-misc/for-linux-next'") ?
--
%G[1.584230] ioc0: LSI53C1030 B0
* Maarten Lankhorst [170408 01:55]:
> Hey,
>
> Op 07-04-17 om 17:56 schreef Tony Lindgren:
> > Hi,
> >
> > Looks like current next now oopses at least for omapdrm
> > when starting X. Reverting commit d20afeb3e2f9 ("Merge
> > remote-tracking branch 'drm-misc/for-linux-next'") makes
> > things wor
Hi,
This is a follow up of my questions around exynos-rng [1].
Changes since v3:
=
1. New patch: 1/2 for ALIGN_DOWN macro. The change in metag architecture
was not compiled. Please test it.
2. Dropped patches touching ARM defconfig as they are not changing and
they pollute t
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
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
Use put_unaligned_be16 to avoid them. On x86 this results in the same
code, but on SPARC the compiler emits two single-byte stores.
Signed-off-b
Dear Alex and other developers,
On Thu, Apr 6, 2017 at 1:03 AM, wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=195231
>
> --- Comment #9 from Rogério Brito (rbr...@ime.usp.br) ---
> (In reply to Alex Deucher from comment #2)
>> Please attach your xorg log and dmesg output. Does appending
Hi Daniel
Thanks for the time and patience for reviewing my changes. I would ensure that
subsequent patches will not have the same mail problems.
I have some question on the validation methods. Since my drivers are processing
the images with an FPGA would running the tests with
https://dri.fre
https://bugzilla.kernel.org/show_bug.cgi?id=195295
--- Comment #1 from Michel Dänzer (mic...@daenzer.net) ---
Can you bisect?
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.f
https://bugs.freedesktop.org/show_bug.cgi?id=100618
--- Comment #1 from Michel Dänzer ---
What are the symptoms of the crash? Can you get a backtrace?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
Daniel Vetter writes:
> I think it'd be good if we could consolidate all the lease checking into
> drm_mode_object_find (respectively __drm_mode_object_find). We'd need to
> wire up the fpriv to be able to do that, but we could upstream that patch
> right away before anything else. That should ta
On 03/04/17 01:31 AM, Keith Packard wrote:
> Daniel Vetter writes:
>
>> I'm also not sure whether we really want sub-leases in v1, that's easy
>> to add later on, but for now just complicates stuff. Main compositor
>> should be a full master, VR can be the first lease level, we don't
>> need more
Hi,
On 04/07/2017 07:49 PM, Romain Perier wrote:
This set of patches split the stream handling functions in two parts. It
introduces new callbacks that are specific to each variant, one for I2S
and one for AHB.
Then, as requested by the datasheet for the I2S variant, it adds support
for gating
On 05.04.2017 13:23, Archit Taneja wrote:
> Add Laurent and Andrzej as maintainers for DRM bridge chip drivers. They
> actively review and contribute to bridge drivers and the bridge API.
>
> Cc: Laurent Pinchart
> Cc: Andrzej Hajda
> Signed-off-by: Archit Taneja
Acked-by: Andrzej Hajda
--
Re
https://bugs.freedesktop.org/show_bug.cgi?id=100611
--- Comment #4 from Jani Saarinen ---
Fix works, closed
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lis
https://bugs.freedesktop.org/show_bug.cgi?id=100611
Jani Saarinen changed:
What|Removed |Added
Status|RESOLVED|VERIFIED
--
You are receiving this mai
https://bugs.freedesktop.org/show_bug.cgi?id=100611
Jani Saarinen changed:
What|Removed |Added
Status|VERIFIED|CLOSED
--
You are receiving this mail
Add Laurent as a reviewer and Andrzej as a maintainer for DRM bridge chip
drivers. They actively review and contribute to bridge drivers and the
bridge API.
Acked-by: Andrzej Hajda
Acked-by: Laurent Pinchart
Acked-by: Sean Paul
Signed-off-by: Archit Taneja
---
v2:
- Collected Acks. Changed Lau
https://bugs.freedesktop.org/show_bug.cgi?id=100618
--- Comment #2 from at...@t-online.de ---
Created attachment 130769
--> https://bugs.freedesktop.org/attachment.cgi?id=130769&action=edit
crash log of Dead Island
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=100618
--- Comment #3 from at...@t-online.de ---
I added the crash log of the game. There is no error at the end. The Game seems
to crash while compiling shaders. Let me know if I could do any more to help
with this bug or if you need more infos of my s
https://bugzilla.kernel.org/show_bug.cgi?id=195231
Christian König (deathsim...@vodafone.de) changed:
What|Removed |Added
CC||deathsim...@vo
https://bugs.freedesktop.org/show_bug.cgi?id=100618
--- Comment #4 from Michel Dänzer ---
Can you try attaching gdb to the game process and getting a backtrace of the
crash?
--
You are receiving this mail because:
You are the assignee for the bug.___
43 matches
Mail list logo
