https://bugs.freedesktop.org/show_bug.cgi?id=103370
--- Comment #24 from Shih-Yuan Lee ---
If I used radeon.dpm=0, there is no such issue.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@li
On Wed, Oct 25, 2017 at 12:01 AM, Rob Herring wrote:
> On Tue, Oct 17, 2017 at 08:17:59PM +0800, Chen-Yu Tsai wrote:
>> From: Jonathan Liu
>>
>> The A10 has two TCONs that are similar to the ones found on other SoCs.
>> Like the A31, TCON0 has a register used to mux the TCON outputs to the
>> dow
https://bugs.freedesktop.org/show_bug.cgi?id=103544
Roland Scheidegger changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Hi Dave,
2017년 11월 14일 13:22에 Dave Airlie 이(가) 쓴 글:
> On 26 October 2017 at 11:37, Inki Dae wrote:
>> Hi Dave,
>>
>>Improving Exynos DRM HDMI and Mixer drivers and also adding
>>HDMI audio support.
>>
>>Please kindly let me know if there is any problem.
>>
>>Ps. we are reviewing I
On 11/14, Matthias Brugger wrote:
> As the new mfd device is in place, switch probing
> for the MMSYS to support invocation from the mfd device.
>
> Signed-off-by: Matthias Brugger
> ---
Acked-by: Stephen Boyd
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Found
On 11/14, Matthias Brugger wrote:
> As the new mfd device is in place, switch probing
> for the MMSYS to support invocation from the mfd device.
>
> Signed-off-by: Matthias Brugger
> ---
Acked-by: Stephen Boyd
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Found
https://bugs.freedesktop.org/show_bug.cgi?id=102009
--- Comment #8 from Jan Vesely ---
(In reply to Markus from comment #7)
> I tried to obtain debug information from Mesa but was unable to do so (i.e.
> starting Blender with `MESA_DEBUG=context CYCLES_OPENCL_SPLIT_KERNEL_TEST=1
> ./blender` did
On Tue, Nov 14, 2017 at 8:44 PM, Eric Anholt wrote:
> Stefan Schake writes:
>
>> On Tue, Nov 14, 2017 at 1:18 AM, Eric Anholt wrote:
>>> Stefan Schake writes:
>>>
The overflow mem work callback vc4_overflow_mem_work reenables its
associated interrupt upon completion. To ensure all int
This patchset adds some simple modeset suspend/resume helpers which
probably most atomic drivers can use.
I have converted the cma helper drivers as part of my ongoing cma helper
refactoring.
Noralf.
Changes since version 2:
- drm_mode_config_helper_suspend(): Check suspend_state as we do on
r
Add entry for conversion of drivers to new helpers.
Signed-off-by: Noralf Trønnes
Reviewed-by: Daniel Vetter
---
Documentation/gpu/todo.rst | 9 +
1 file changed, 9 insertions(+)
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index a44f379d2b25..6bce1beafabe 10064
Add drm_mode_config_helper_suspend/resume() which takes care of
atomic modeset suspend/resume for simple use cases.
The suspend state is stored in struct drm_mode_config.
Signed-off-by: Noralf Trønnes
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_modeset_helper.c | 79 +
Replace driver's code with the generic helpers that do the same thing.
Cc: Liviu Dudau
Cc: Brian Starkey
Signed-off-by: Noralf Trønnes
Reviewed-by: Liviu Dudau
---
drivers/gpu/drm/arm/malidp_drv.c | 24 +++-
drivers/gpu/drm/arm/malidp_drv.h | 1 -
2 files changed, 3 inser
Fix docs to reflect code and drm_kms_helper_poll_disable() docs by saying
that calling drm_kms_helper_poll_enable() is fine even if output polling
is not enabled.
Signed-off-by: Noralf Trønnes
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_probe_helper.c | 3 +--
1 file changed, 1 insertion
Replace driver's code with the generic helpers that do the same thing.
Remove todo entry.
Signed-off-by: Noralf Trønnes
Reviewed-by: Stefan Agner
---
Documentation/gpu/todo.rst | 5 ---
drivers/gpu/drm/tinydrm/core/tinydrm-core.c | 67 -
drivers/gpu
Replace driver's code with the generic helpers that do the same thing.
Cc: Stefan Agner
Cc: Alison Wang
Signed-off-by: Noralf Trønnes
Acked-by: Stefan Agner
---
Stefan, I didn't retain your tested-by tag now that I have rebased.
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 25 ++
On Tue, Nov 14, 2017 at 02:31:11PM -0500, Alex Deucher wrote:
> On Tue, Nov 14, 2017 at 2:10 PM, Ville Syrjala
> wrote:
> > From: Ville Syrjälä
> >
> > Add the missing kerneldoc for modifiers and modifier_count.
> >
> > Cc: Ben Widawsky
> > Cc: Daniel Vetter
> > Suggested-by: Daniel Vetter
> >
On Tue, 2017-11-14 at 20:32 +0200, Ville Syrjala wrote:
> @@ -253,8 +251,11 @@ struct drm_display_mode {
>* - DRM_MODE_TYPE_USERDEF: Mode defined via kernel command line
>*
>* Plus a big list of flags which shouldn't be used at all, but are
> - * still around since th
Den 14.11.2017 20.10, skrev Ville Syrjala:
From: Ville Syrjälä
Use the correct name for the function argument in the docs.
Cc: Noralf Trønnes
Cc: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_gem_cma_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
di
On 14/11/17 18:05, Johan Hovold wrote:
On Mon, Nov 13, 2017 at 02:16:09PM +, Daniel Thompson wrote:
On 13/11/17 10:20, Johan Hovold wrote:
Fix child-node lookup during probe, which ended up searching the whole
device tree depth-first starting at the parent rather than just matching
on its c
Stefan Schake writes:
> On Tue, Nov 14, 2017 at 1:18 AM, Eric Anholt wrote:
>> Stefan Schake writes:
>>
>>> The overflow mem work callback vc4_overflow_mem_work reenables its
>>> associated interrupt upon completion. To ensure all interrupts are disabled
>>> when we return from vc4_irq_uninstal
On Tue, Nov 14, 2017 at 1:32 PM, Ville Syrjala
wrote:
> From: Ville Syrjälä
>
> These days DRM_MODE_TYPE_USERDEF is used to flag modes defined via the
> kernel command line. Update the docs to reflect that fact.
>
> Signed-off-by: Ville Syrjälä
Acked-by: Alex Deucher
> ---
> include/drm/drm_
On Tue, Nov 14, 2017 at 2:10 PM, Ville Syrjala
wrote:
> From: Ville Syrjälä
>
> Add the missing kerneldoc for modifiers and modifier_count.
>
> Cc: Ben Widawsky
> Cc: Daniel Vetter
> Suggested-by: Daniel Vetter
> Signed-off-by: Ville Syrjälä
Series is:
Reviewed-by: Alex Deucher
> ---
> in
On Tue, Nov 14, 2017 at 8:10 PM, Ville Syrjala
wrote:
> From: Ville Syrjälä
>
> Document the drm_syncobj_get_handle() function parameters.
>
> Cc: Marek Olšák
> Cc: Dave Airlie
> Cc: Alex Deucher
> Cc: Daniel Vetter
> Suggested-by: Daniel Vetter
> Signed-off-by: Ville Syrjälä
> ---
> drive
On Tue, Nov 14, 2017 at 1:32 PM, Ville Syrjala
wrote:
> From: Ville Syrjälä
>
> Currently we don't sanity check the 3D stereo flags for modes filled out
> by the kernel. Move the check from drm_mode_convert_umode() into
> drm_mode_validate_basic() so that we get the same check going both ways.
>
On Tue, Nov 14, 2017 at 1:32 PM, Ville Syrjala
wrote:
> From: Ville Syrjälä
>
> BUILTIN, CRTC_C, CLOCK_C, and DEFULT mode types are unused. Let's
> refuse to generate them or accept them from userspace either. A
> cursory check didn't reveal any userspace code that would depend
> on these.
>
> Cc
On Tue, Nov 14, 2017 at 1:32 PM, Ville Syrjala
wrote:
> From: Ville Syrjälä
>
> No idea what the DRM_MODE_TYPE_CLOCK_CRTC_C define is supposed to
> achieve. Totally unused so kill if off.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Alex Deucher
> ---
> include/drm/drm_modes.h | 3 ---
> 1
On Tue, Nov 14, 2017 at 1:43 PM, Chris Wilson wrote:
> Quoting Ville Syrjala (2017-11-14 18:32:54)
>> From: Ville Syrjälä
>>
>> For some reason drm_mode_set_crtcinfo() does nothing of the mode has
> s/of/if/
With the typo fixed:
Reviewed-by: Alex Deucher
>
>> the DRM_MODE_TYPE_BUILTIN flag set
The panel_bridge bridge attaches to the panel's OF node, not the
lvds-encoder's node. Put in a little no-op bridge of our own so that
our consumers can still find a bridge where they expect.
This also fixes an unintended unregistration and leak of the
panel-bridge on module remove.
Signed-off-by
On Tue, Nov 14, 2017 at 1:32 PM, Ville Syrjala
wrote:
> From: Ville Syrjälä
>
> Reject any mode with DRM_MODE_FLAG_BCAST. We have no code that even
> checks for this flag hence it can't possibly do any good.
>
> I think this maybe originated from fbdev where it was supposed to
> indicate PAL/NTSC
On Tue, Nov 14, 2017 at 1:32 PM, Ville Syrjala
wrote:
> From: Ville Syrjälä
>
> Reject any mode with DRM_MODE_FLAG_PIXMUX. We have no code that even
> checks for this flag hence it can't possibly do any good.
>
> Looks like this flag had something to do the the controller<->ramdac
> interface wit
From: Ville Syrjälä
Use the correct name for the function argument in the docs.
Cc: Noralf Trønnes
Cc: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_gem_cma_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
From: Ville Syrjälä
Document the drm_syncobj_get_handle() function parameters.
Cc: Marek Olšák
Cc: Dave Airlie
Cc: Alex Deucher
Cc: Daniel Vetter
Suggested-by: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_syncobj.c | 3 +++
1 file changed, 3 insertions(+)
diff --git
From: Ville Syrjälä
Add the missing kerneldoc for modifiers and modifier_count.
Cc: Ben Widawsky
Cc: Daniel Vetter
Suggested-by: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
include/drm/drm_plane.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/drm/drm_plane.h b/include/drm
On Tue, Nov 14, 2017 at 06:42:06PM +, Chris Wilson wrote:
> Quoting Ville Syrjala (2017-11-14 18:32:50)
> > From: Ville Syrjälä
> >
> > Currently userspace is allowed to feed in any king of garbage in the
> > high bits of the mode flags/type, as are drivers when probing modes.
> > Reject any
Quoting Ville Syrjala (2017-11-14 18:32:54)
> From: Ville Syrjälä
>
> For some reason drm_mode_set_crtcinfo() does nothing of the mode has
s/of/if/
> the DRM_MODE_TYPE_BUILTIN flag set without the other bit from
> DRM_MODE_TYPE_CRTC_C also set. I have zero idea what that is supposed
> to achieve
Quoting Ville Syrjala (2017-11-14 18:32:50)
> From: Ville Syrjälä
>
> Currently userspace is allowed to feed in any king of garbage in the
> high bits of the mode flags/type, as are drivers when probing modes.
> Reject any mode with bogus flags/type.
>
> Hopefully this won't break any current us
https://bugs.freedesktop.org/show_bug.cgi?id=103736
--- Comment #2 from Andres Rodriguez ---
> FWIW, Andres Rodriguez reported similar symptoms with a Ryzen system on IRC,
> and raising voltages / disabling Cool'n'Quiet / disabling C6 states fixed
> them for him.
I raised the memory and the cor
From: Ville Syrjälä
We never support certain mode flags etc. Reject those early on in the
mode_config.mode_valid() hook. That allows us to remove some duplicated
checks from the connector .mode_valid() hooks, and it guarantees that
we never see those flags even from user mode as the
mode_config.m
From: Ville Syrjälä
Allow drivers to provide a device wide .mode_valid() hook in addition to
the already existing crtc/encoder/bridge/connector hooks. This can be
used to validate device/driver wide constraings without having to add
those to the other hooks. And since we call this hook also for u
From: Ville Syrjälä
No idea what the DRM_MODE_TYPE_CLOCK_CRTC_C define is supposed to
achieve. Totally unused so kill if off.
Signed-off-by: Ville Syrjälä
---
include/drm/drm_modes.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index 8
From: Ville Syrjälä
BUILTIN, CRTC_C, CLOCK_C, and DEFULT mode types are unused. Let's
refuse to generate them or accept them from userspace either. A
cursory check didn't reveal any userspace code that would depend
on these.
Cc: Jose Abreu
Cc: Adam Jackson
Cc: Keith Packard
Signed-off-by: Vil
From: Ville Syrjälä
Currently we don't sanity check the 3D stereo flags for modes filled out
by the kernel. Move the check from drm_mode_convert_umode() into
drm_mode_validate_basic() so that we get the same check going both ways.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_modes.c |
From: Ville Syrjälä
For some reason drm_mode_set_crtcinfo() does nothing of the mode has
the DRM_MODE_TYPE_BUILTIN flag set without the other bit from
DRM_MODE_TYPE_CRTC_C also set. I have zero idea what that is supposed
to achieve, but since we have no users for neither flag bit let's kill
this
From: Ville Syrjälä
Reject any mode with DRM_MODE_FLAG_BCAST. We have no code that even
checks for this flag hence it can't possibly do any good.
I think this maybe originated from fbdev where it was supposed to
indicate PAL/NTSC broadcast timings. I have no idea why those would
have to be ident
From: Ville Syrjälä
These days DRM_MODE_TYPE_USERDEF is used to flag modes defined via the
kernel command line. Update the docs to reflect that fact.
Signed-off-by: Ville Syrjälä
---
include/drm/drm_modes.h | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/include/drm/drm_
From: Ville Syrjälä
Currently userspace is allowed to feed in any king of garbage in the
high bits of the mode flags/type, as are drivers when probing modes.
Reject any mode with bogus flags/type.
Hopefully this won't break any current userspace...
Cc: Jose Abreu
Cc: Adam Jackson
Cc: Keith Pa
From: Ville Syrjälä
I recently realized that we're not validating the mode flags/type
passed in from userspace. Let's try to fix that.
I'd also like to entirely eliminate some of the more crazy mode flags.
PIXMUX and BCAST look pretty easy, so I've targetted them first.
Ideally I'd like to kill
From: Ville Syrjälä
Reject any mode with DRM_MODE_FLAG_PIXMUX. We have no code that even
checks for this flag hence it can't possibly do any good.
Looks like this flag had something to do the the controller<->ramdac
interface with some ancient S3 graphics adapters. Why someone though
it would be
https://bugs.freedesktop.org/show_bug.cgi?id=103743
--- Comment #3 from Philip Rebohle ---
PS: While bug 102218 is not directly related to this one, that's another case
where two shaders that *should* be functionally equivalent yield different
results. In the second screenshot, workarounds for bo
https://bugs.freedesktop.org/show_bug.cgi?id=103743
--- Comment #2 from Philip Rebohle ---
Created attachment 135459
--> https://bugs.freedesktop.org/attachment.cgi?id=135459&action=edit
Frame 2400 without artifacts
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=103743
--- Comment #1 from Philip Rebohle ---
Created attachment 135458
--> https://bugs.freedesktop.org/attachment.cgi?id=135458&action=edit
Frame 2400 with artifacts
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=103743
Bug ID: 103743
Summary: Nier:Automata - "if" in fragment shader incorrectly
evaluated, causes artifacts
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
Am 14.11.2017 um 17:27 schrieb Chris Wilson:
Ages ago Rob Clark noted,
"Currently with fence-array, we have a potential deadlock situation. If
we fence_add_callback() on an array-fence, the array-fence's lock is
acquired first, and in it's ->enable_signaling() callback, it will install
cbs on i
The resume helpers wait for a vblank to occurre hence IRQ need
to be enabled. This avoids a warning as follows during resume:
WARNING: CPU: 0 PID: 314 at drivers/gpu/drm/drm_atomic_helper.c:1249
drm_atomic_helper_wait_for_vblanks.part.1+0x284/0x288
[CRTC:28:crtc-0] vblank wait timed out
Signe
With commit 0a70c998d0c5 ("drm/fsl-dcu: enable pixel clock when
enabling CRTC") the pixel clock is controlled by the CRTC code.
Disabling the pixel clock in suspend leads to a warning due to
the second clk_disable_unprepare call:
WARNING: CPU: 0 PID: 359 at drivers/clk/clk.c:594 clk_core_disable+
Ages ago Rob Clark noted,
"Currently with fence-array, we have a potential deadlock situation. If
we fence_add_callback() on an array-fence, the array-fence's lock is
acquired first, and in it's ->enable_signaling() callback, it will install
cbs on it's array-member fences, so the array-member's
Den 14.11.2017 16.56, skrev Stefan Agner:
On 2017-11-14 16:40, Noralf Trønnes wrote:
Den 14.11.2017 16.23, skrev Stefan Agner:
On 2017-11-10 19:06, Noralf Trønnes wrote:
Den 10.11.2017 17.39, skrev Stefan Agner:
On 2017-11-09 17:49, Noralf Trønnes wrote:
Den 09.11.2017 15.34, skrev Stefan
Den 14.11.2017 16.40, skrev Stefan Agner:
On 2017-11-06 20:18, Noralf Trønnes wrote:
Replace driver's code with the generic helpers that do the same thing.
Remove todo entry.
This patch looks good to me:
Reviewed-by: Stefan Agner
Thanks!
One question below though:
Signed-off-by: Noralf
On 2017-11-14 16:40, Noralf Trønnes wrote:
> Den 14.11.2017 16.23, skrev Stefan Agner:
>> On 2017-11-10 19:06, Noralf Trønnes wrote:
>>> Den 10.11.2017 17.39, skrev Stefan Agner:
On 2017-11-09 17:49, Noralf Trønnes wrote:
> Den 09.11.2017 15.34, skrev Stefan Agner:
>> On 2017-11-06 20:
https://bugs.freedesktop.org/show_bug.cgi?id=103736
Michel Dänzer changed:
What|Removed |Added
CC||andre...@gmail.com
--- Comment #1 from
On Tue, Nov 14, 2017 at 7:13 AM, Christian König
wrote:
> Otherwise we can't correctly CPU map TTM buffers.
>
> Signed-off-by: Christian König
Acked-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a
On 2017-11-06 20:18, Noralf Trønnes wrote:
> Replace driver's code with the generic helpers that do the same thing.
> Remove todo entry.
This patch looks good to me:
Reviewed-by: Stefan Agner
One question below though:
>
> Signed-off-by: Noralf Trønnes
> ---
> Documentation/gpu/todo.rst
https://bugs.freedesktop.org/show_bug.cgi?id=103519
--- Comment #10 from Derek Foreman ---
Thanks Emil! sorry for the noise on list. :(
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@list
https://bugs.freedesktop.org/show_bug.cgi?id=103519
Emil Velikov changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Den 14.11.2017 16.23, skrev Stefan Agner:
On 2017-11-10 19:06, Noralf Trønnes wrote:
Den 10.11.2017 17.39, skrev Stefan Agner:
On 2017-11-09 17:49, Noralf Trønnes wrote:
Den 09.11.2017 15.34, skrev Stefan Agner:
On 2017-11-06 20:18, Noralf Trønnes wrote:
Replace driver's code with the gener
https://bugs.freedesktop.org/show_bug.cgi?id=103519
--- Comment #8 from Derek Foreman ---
Oops, I've dropped the ball on this.
I need to send it to the list for further review (and potentially revision in
response to that) - will do that today.
--
You are receiving this mail because:
You are t
On 14/11/17 01:18 PM, Christian König wrote:
> Am 14.11.2017 um 11:02 schrieb Michel Dänzer:
>> On 13/11/17 10:54 AM, Christian König wrote:
>>>
>>> + } else {
>>> + locked = reservation_object_trylock(bo->resv);
>>> + if (!locked)
>>> + c
https://bugs.freedesktop.org/show_bug.cgi?id=103700
--- Comment #3 from Harry Wentland ---
dwagner, these are different issue. This one was reported on a kernel without
DC, the other with DC.
--
You are receiving this mail because:
You are the assignee for the bug.__
On 2017-11-10 19:06, Noralf Trønnes wrote:
> Den 10.11.2017 17.39, skrev Stefan Agner:
>> On 2017-11-09 17:49, Noralf Trønnes wrote:
>>> Den 09.11.2017 15.34, skrev Stefan Agner:
On 2017-11-06 20:18, Noralf Trønnes wrote:
> Replace driver's code with the generic helpers that do the same th
https://bugs.freedesktop.org/show_bug.cgi?id=103736
Bug ID: 103736
Summary: Sudden system freezes, dmesg errors
Product: DRI
Version: XOrg git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity:
https://bugs.freedesktop.org/show_bug.cgi?id=102358
--- Comment #39 from har...@gmx.de ---
Thank you, problem fully solved for me.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freed
https://bugs.freedesktop.org/show_bug.cgi?id=103519
--- Comment #7 from Apostolos B. ---
@Emil Velikov
It will be in for 17.3 right?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.f
Quoting Chris Wilson (2017-11-14 14:39:29)
> Quoting Christian König (2017-11-14 14:24:35)
> > The amdgpu issue to also need signaled fences in the reservation objects
> > should be fixed by now.
> >
> > Optimize the list by keeping only the not signaled yet fences around.
> >
> > v2: temporary p
Quoting Christian König (2017-11-14 14:24:36)
> The amdgpu issue to also need signaled fences in the reservation objects
> should
> be fixed by now.
>
> Optimize the handling by replacing a signaled fence when adding a new
> shared one.
>
> Signed-off-by: Christian König
Reviewed-by: Chris Wil
Quoting Christian König (2017-11-14 14:24:35)
> The amdgpu issue to also need signaled fences in the reservation objects
> should be fixed by now.
>
> Optimize the list by keeping only the not signaled yet fences around.
>
> v2: temporary put the signaled fences at the end of the new container
>
On 05.04.2017 14:04, Thierry Reding wrote:
> On Wed, Apr 05, 2017 at 10:52:32AM +0200, Lucas Stach wrote:
>> Hi Rob,
>>
>> Am Mittwoch, den 29.03.2017, 08:56 -0500 schrieb Rob Herring:
>>> On Mon, Jan 23, 2017 at 10:33 AM, Thierry Reding
>>> wrote:
On Fri, Jan 13, 2017 at 06:36:30PM +0100, Lu
Quoting Christian König (2017-11-14 14:24:44)
> Am 06.11.2017 um 17:22 schrieb Chris Wilson:
> > Quoting Christian König (2017-10-30 14:59:04)
> >> From: Christian König
> >>
> >> The amdgpu issue to also need signaled fences in the reservation objects
> >> should
> >> be fixed by now.
> >>
> >>
The amdgpu issue to also need signaled fences in the reservation objects should
be fixed by now.
Optimize the handling by replacing a signaled fence when adding a new
shared one.
Signed-off-by: Christian König
---
drivers/dma-buf/reservation.c | 18 +++---
1 file changed, 15 inserti
The amdgpu issue to also need signaled fences in the reservation objects
should be fixed by now.
Optimize the list by keeping only the not signaled yet fences around.
v2: temporary put the signaled fences at the end of the new container
v3: put the old fence at the end of the new container as wel
Am 06.11.2017 um 17:22 schrieb Chris Wilson:
Quoting Christian König (2017-10-30 14:59:04)
From: Christian König
The amdgpu issue to also need signaled fences in the reservation objects should
be fixed by now.
Optimize the handling by replacing a signaled fence when adding a new
shared one.
The suite stalls the CP, until RCA is done the suite is
disabled to not disrupt regression testing.
Signed-off-by: Andrey Grodzovsky
---
tests/amdgpu/amdgpu_test.c| 2 +-
tests/amdgpu/amdgpu_test.h| 5 +
tests/amdgpu/deadlock_tests.c | 19 +++
3 files changed, 25 in
https://bugs.freedesktop.org/show_bug.cgi?id=101483
--- Comment #27 from FFAB ---
Created attachment 135448
--> https://bugs.freedesktop.org/attachment.cgi?id=135448&action=edit
dmesg_20171114_4_14_iommu_soft.txt, kernel boot-parameter iommu=soft
--
You are receiving this mail because:
You ar
https://bugs.freedesktop.org/show_bug.cgi?id=101483
FFAB changed:
What|Removed |Added
Attachment #135255|0 |1
is obsolete|
Do you have a standard such reference for uniformity, else chrome keyword will
do.
(typed on mobile, kindly ignore typos)
Regards,
Shirish S
From: Fengguang Wu
Sent: Tuesday, November 14, 2017 6:41:41 PM
To: S, Shirish
Cc: StDenis, Tom; kbuild-...@01.org; dri-d
https://bugs.freedesktop.org/show_bug.cgi?id=101483
--- Comment #25 from FFAB ---
Upstream kernel test - kernel 4.14
Installation, on which upstream kernel was installed:
ubuntu 16.04.3, kernel4.10.0-38, updated 2017-11-14
1. booting without any workaround parameters
2. booting with kernel par
Thanks.
(typed on mobile, kindly ignore typos)
Regards,
Shirish S
From: Fengguang Wu
Sent: Tuesday, November 14, 2017 6:52:03 PM
To: S, Shirish
Cc: StDenis, Tom; kbuild-...@01.org; dri-devel@lists.freedesktop.org; Koenig,
Christian; Deucher, Alexander
Subject:
Am 14.11.2017 um 13:53 schrieb Andrey Grodzovsky:
On 11/14/2017 03:44 AM, Christian König wrote:
Am 13.11.2017 um 18:01 schrieb Andrey Grodzovsky:
Allocates 1 TB of memory. Test is disabled by default
since it's triggers OOM killer.
v2:
FIx the test to only alloc the BO and assert if return
OK I'll blacklist all branches containing the "chrome" string.
It's "grep -E" patterns. Here are some examples:
wfg /c/lkp-tests% grep -hr blacklist repo
blacklist_branch: master|revert-
blacklist_branch: .*
blacklist_branch: .*
blacklist_branch: .*
blacklist_branch: for-epmt
blacklist_branch: m
Hi Shirish,
Sorry for the noise! Do you have any branch pattern that I can add to
blacklist? The regex could be 'chrome$' to match it in the end or just
'chrome' to match it anywhere in the branch name.
Thanks,
Fengguang
On Tue, Nov 14, 2017 at 01:07:07PM +, S, Shirish wrote:
Please ignore
On 11/14/2017 03:44 AM, Christian König wrote:
Am 13.11.2017 um 18:01 schrieb Andrey Grodzovsky:
Allocates 1 TB of memory. Test is disabled by default
since it's triggers OOM killer.
v2:
FIx the test to only alloc the BO and assert if return value
not equal to -ENOMEM and remove test disable
Please ignore all the kbuild bot related mails on this branch.
As the purpose of this branch is chrome specific and in a very specific build
environment.
Regards,
Shirish S
From: StDenis, Tom
Sent: Tuesday, November 14, 2017 4:58:48 PM
To: kbuild test robot
Cc:
Hi,
Changes since v1:
- Use the crtc->mode_valid and not connector->mode_valid as the limit is really
posed by the 'crtc' (DISPC)
- Bandwidth calculation changed: do the calculation in place + extended comment
- looked for better place to document the max-memory-bandwidth, but
can not find an
If we have memory bandwidth limit configured, reject the modes which would
require more bandwidth than the limit if it is used with one full
resolution plane (most common use case).
This filtering is not providing full protection as it is possible that
application would pick smaller crtc resolutio
The get_memory_bandwidth_limit() in dispc_ops can be used to query the
memory bandwidth limit of dispc by upper layers.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/dss/dispc.c | 13 +
drivers/gpu/drm/omapdrm/dss/omapdss.h | 2 ++
2 files changed, 15 insertions(+)
di
max-memory-bandwidth can be used to specify the maximum bandwidth dispc
can use when reading display data from main memory.
In some SoC (am437x for example) we have memory bandwidth limitation
which causes underflow in the display subsystem.
Signed-off-by: Peter Ujfalusi
---
Documentation/devic
Am 14.11.2017 um 11:02 schrieb Michel Dänzer:
On 13/11/17 10:54 AM, Christian König wrote:
Deleted BOs with the same reservation object can be reaped even if they
can't be reserved.
v2: rebase and we still need to remove/add the BO from/to the LRU.
v3: fix remove/add one more time, cleanup the
Otherwise we can't correctly CPU map TTM buffers.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
index 90a
Is this:
commit 7a9667ae197460e6c9c3bb432fe68c708fce6259
Refs: v4.13-rc5-1195-g7a9667ae1974
Author: Tom St Denis
AuthorDate: Tue Sep 5 07:30:59 2017 -0400
Commit: Alex Deucher
CommitDate: Tue Sep 12 14:22:55 2017 -0400
drm/ttm: Fix configuration error around populate_and_map() func
On Tue, Nov 14, 2017 at 1:18 AM, Eric Anholt wrote:
> Stefan Schake writes:
>
>> The overflow mem work callback vc4_overflow_mem_work reenables its
>> associated interrupt upon completion. To ensure all interrupts are disabled
>> when we return from vc4_irq_uninstall, we need to disable it again
RK3126 vop register layout is similar with rk3036, so some feature
can reuse with rk3036.
RK3126 support two overlay plane and one hwc plane, max output
resolution is 1080p. it support IOMMU, and its IOMMU same as
rk3288's
Signed-off-by: Sandy Huang
---
drivers/gpu/drm/rockchip/rockchip_vop_reg
1 - 100 of 117 matches
Mail list logo
