On 06/27/2017 11:16 PM, Laurent Pinchart wrote:
> The CRTC .disable() helper operation is deprecated for atomic drivers,
> the new .atomic_disable() helper operation being preferred. Convert all
> atomic drivers to .atomic_disable() to avoid cargo-cult use of
> .disable() in new drivers.
>
> Sig
On 06/27/2017 11:16 PM, Laurent Pinchart wrote:
> The old state is useful for drivers that need to perform operations at
> enable time that depend on the transition between the old and new
> states.
>
> While at it, rename the operation to .atomic_enable() to be consistent
> with .atomic_disable
On 06/27/2017 11:16 PM, Laurent Pinchart wrote:
> The old state is useful for drivers that need to perform operations at
> enable time that depend on the transition between the old and new
> states.
>
> While at it, rename the operation to .atomic_enable() to be consistent
> with .atomic_disable
On 06/27/2017 11:16 PM, Laurent Pinchart wrote:
> The CRTC .disable() helper operation is deprecated for atomic drivers,
> the new .atomic_disable() helper operation being preferred. Convert all
> atomic drivers to .atomic_disable() to avoid cargo-cult use of
> .disable() in new drivers.
>
> Sig
Am 29.06.2017 um 00:59 schrieb John Brooks:
On Wed, Jun 28, 2017 at 03:06:47PM +0200, Christian König wrote:
Am 28.06.2017 um 04:33 schrieb John Brooks:
Signed-off-by: John Brooks
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 3 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 5 +
Am 29.06.2017 um 04:35 schrieb Michel Dänzer:
On 29/06/17 08:26 AM, John Brooks wrote:
On Wed, Jun 28, 2017 at 03:05:32PM +0200, Christian König wrote:
Am 28.06.2017 um 04:33 schrieb John Brooks:
When the AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED flag is given by userspace,
it should only be treat
On 27.06.2017 21:58, Eric Anholt wrote:
> The DPHY spec requires a much larger T_INIT than I was specifying
> before. In the absence of clear specs from the slave of what their
> timing is, just use the value that the firmware was using.
>
> Signed-off-by: Eric Anholt
Reviewed-by: Andrzej Hajda
On 27.06.2017 21:58, Eric Anholt wrote:
> The logic was all right in the end, the name was just backwards.
>
> Signed-off-by: Eric Anholt
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://
Op 27-06-17 om 16:59 schreef Daniel Vetter:
> From: Thierry Reding
>
> Move the modeset locking from drivers into FB helpers.
>
> v2: Also handle intel_connector_add_to_fbdev.
>
> Tested-by: John Stultz
> Signed-off-by: Thierry Reding (v1)
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm
On Thu, Jun 29, 2017 at 11:10 AM, Maarten Lankhorst
wrote:
> Op 27-06-17 om 16:59 schreef Daniel Vetter:
>> From: Thierry Reding
>>
>> Move the modeset locking from drivers into FB helpers.
>>
>> v2: Also handle intel_connector_add_to_fbdev.
>>
>> Tested-by: John Stultz
>> Signed-off-by: Thierry
On 27.06.2017 21:58, Eric Anholt wrote:
> I'm not sure what changed where I started getting vrefresh=0 from the
> mode to be fixed up.
It can be a case of low pixel_clock value, maybe it should be
investigated further, unless there is execution path with forgotten
mode->vrefresh =
drm_mode_vrefre
https://bugzilla.kernel.org/show_bug.cgi?id=196197
--- Comment #4 from Andreas Brogle (an...@ok.de) ---
Hello Michel,
needed a little bit help for the last step.
I am glad to give you now the precise information you need.
Last bisect good:
7089db84e356562f8ba737c29e472cc42d530dbc
First bisect ba
On 27.06.2017 21:58, Eric Anholt wrote:
> This will let drivers reduce the error cleanup they need, in
> particular the "is_panel_bridge" flag.
>
> Signed-off-by: Eric Anholt
> ---
> drivers/gpu/drm/bridge/panel.c | 30 ++
> include/drm/drm_bridge.h | 3 +++
> 2
Op 29-06-17 om 11:23 schreef Daniel Vetter:
> On Thu, Jun 29, 2017 at 11:10 AM, Maarten Lankhorst
> wrote:
>> Op 27-06-17 om 16:59 schreef Daniel Vetter:
>>> From: Thierry Reding
>>>
>>> Move the modeset locking from drivers into FB helpers.
>>>
>>> v2: Also handle intel_connector_add_to_fbdev.
>
On 27.06.2017 21:58, Eric Anholt wrote:
> The vc4 driver was unusual in that it was delaying the panel lookup
> until the attach step, while most DSI hosts will -EPROBE_DEFER until
> they get a panel.
>
> Signed-off-by: Eric Anholt
> ---
> drivers/gpu/drm/vc4/vc4_dsi.c | 40 --
On Thu, Jun 29, 2017 at 11:33 AM, Maarten Lankhorst
wrote:
> Op 29-06-17 om 11:23 schreef Daniel Vetter:
>> On Thu, Jun 29, 2017 at 11:10 AM, Maarten Lankhorst
>> wrote:
>>> Op 27-06-17 om 16:59 schreef Daniel Vetter:
From: Thierry Reding
Move the modeset locking from drivers into
https://bugzilla.kernel.org/show_bug.cgi?id=196197
--- Comment #5 from Andreas Brogle (an...@ok.de) ---
(In reply to Andreas Brogle from comment #4)
> Hello Michel,
> needed a little bit help for the last step.
> I am glad to give you now the precise information you need.
>
> Last bisect good:
>
On 29/06/17 05:23 PM, Christian König wrote:
> Am 29.06.2017 um 04:35 schrieb Michel Dänzer:
>> On 29/06/17 08:26 AM, John Brooks wrote:
>>> On Wed, Jun 28, 2017 at 03:05:32PM +0200, Christian König wrote:
>
> Instead of the flag being set in stone at BO creation, set the flag
> when a
On Thu, Jun 29, 2017 at 06:58:05PM +0900, Michel Dänzer wrote:
> On 29/06/17 05:23 PM, Christian König wrote:
> > Am 29.06.2017 um 04:35 schrieb Michel Dänzer:
> >> On 29/06/17 08:26 AM, John Brooks wrote:
> >>> On Wed, Jun 28, 2017 at 03:05:32PM +0200, Christian König wrote:
> >
> > Instea
Op 27-06-17 om 16:59 schreef Daniel Vetter:
> Like with panning and modesetting, and like with those, stick with
> simple drm_modeset_locking_all for the legacy path, and the full
> atomic dance for atomic drivers.
>
> This means a bit more boilerplate since setting up the atomic state
> machinery
On Thu, Jun 29, 2017 at 12:22 PM, Maarten Lankhorst
wrote:
>> +static void dpms_atomic(struct drm_fb_helper *fb_helper, int dpms_mode)
>> +{
>> + struct drm_device *dev = fb_helper->dev;
>> + struct drm_atomic_state *state;
>> + int i, ret;
>> +
>> + struct drm_modeset_acquire_ctx
On 29.06.2017 07:03, Archit Taneja wrote:
>
> On 06/28/2017 01:28 AM, Eric Anholt wrote:
>> When a mipi_dsi_host is registered, the DT is walked to find any child
>> nodes with compatible strings. Those get registered as DSI devices,
>> and most DSI panel drivers are mipi_dsi_drivers that attach t
Hi Morimoto-san,
Thank you for the patch.
On Wednesday 28 Jun 2017 00:32:17 Kuninori Morimoto wrote:
> From: Kuninori Morimoto
>
> Now, we can use of_graph_get_remote_endpoint(). Let's use it.
>
> Signed-off-by: Kuninori Morimoto
Reviewed-by: Laurent Pinchart
> ---
> based on 4c9c3d595f1ba
Op 29-06-17 om 12:31 schreef Daniel Vetter:
> On Thu, Jun 29, 2017 at 12:22 PM, Maarten Lankhorst
> wrote:
>>> +static void dpms_atomic(struct drm_fb_helper *fb_helper, int dpms_mode)
>>> +{
>>> + struct drm_device *dev = fb_helper->dev;
>>> + struct drm_atomic_state *state;
>>> + int
Op 28-06-17 om 13:32 schreef Daniel Vetter:
> FB helper code falls back to a 1024x768 mode if no outputs are connected
> or don't report back any modes upon initialization. This can be annoying
> because outputs that are added to FB helper later on can't be used with
> FB helper if they don't suppo
On Thu, Jun 29, 2017 at 12:58 PM, Maarten Lankhorst
wrote:
> Op 29-06-17 om 12:31 schreef Daniel Vetter:
>> On Thu, Jun 29, 2017 at 12:22 PM, Maarten Lankhorst
>> wrote:
+static void dpms_atomic(struct drm_fb_helper *fb_helper, int dpms_mode)
+{
+ struct drm_device *dev = fb_he
https://bugs.freedesktop.org/show_bug.cgi?id=101644
Bug ID: 101644
Summary: Applying for drm-misc commit rights
Product: DRI
Version: unspecified
Hardware: Other
OS: All
Status: NEW
Severity: normal
https://bugs.freedesktop.org/show_bug.cgi?id=101644
--- Comment #1 from Noralf Trønnes ---
Created attachment 132339
--> https://bugs.freedesktop.org/attachment.cgi?id=132339&action=edit
ssh key
--
You are receiving this mail because:
You are the assignee for the bug._
Op 29-06-17 om 11:44 schreef Daniel Vetter:
> On Thu, Jun 29, 2017 at 11:33 AM, Maarten Lankhorst
> wrote:
>> Op 29-06-17 om 11:23 schreef Daniel Vetter:
>>> On Thu, Jun 29, 2017 at 11:10 AM, Maarten Lankhorst
>>> wrote:
Op 27-06-17 om 16:59 schreef Daniel Vetter:
> From: Thierry Reding
Hi Laurent,
On Thu, Jun 29, 2017 at 12:44 PM, Laurent Pinchart
wrote:
> On Wednesday 28 Jun 2017 00:32:17 Kuninori Morimoto wrote:
>> From: Kuninori Morimoto
>>
>> Now, we can use of_graph_get_remote_endpoint(). Let's use it.
>>
>> Signed-off-by: Kuninori Morimoto
>
> Reviewed-by: Laurent Pinch
Op 29-06-17 om 13:00 schreef Daniel Vetter:
> On Thu, Jun 29, 2017 at 12:58 PM, Maarten Lankhorst
> wrote:
>> Op 29-06-17 om 12:31 schreef Daniel Vetter:
>>> On Thu, Jun 29, 2017 at 12:22 PM, Maarten Lankhorst
>>> wrote:
> +static void dpms_atomic(struct drm_fb_helper *fb_helper, int dpms_mod
Hi Geert,
On Thursday 29 Jun 2017 13:22:14 Geert Uytterhoeven wrote:
> On Thu, Jun 29, 2017 at 12:44 PM, Laurent Pinchart wrote:
> > On Wednesday 28 Jun 2017 00:32:17 Kuninori Morimoto wrote:
> >> From: Kuninori Morimoto
> >>
> >> Now, we can use of_graph_get_remote_endpoint(). Let's use it.
> >
Hi Laurent,
On Thu, Jun 29, 2017 at 1:26 PM, Laurent Pinchart
wrote:
> On Thursday 29 Jun 2017 13:22:14 Geert Uytterhoeven wrote:
>> On Thu, Jun 29, 2017 at 12:44 PM, Laurent Pinchart wrote:
>> > On Wednesday 28 Jun 2017 00:32:17 Kuninori Morimoto wrote:
>> >> From: Kuninori Morimoto
>> >>
>> >>
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_framebuffer.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/drm_framebuffer.c
b/drivers/gpu/drm/drm_framebuffer.c
index fc8ef42203ec..b3ef4f1c2630 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/d
On Wed, 2017-06-21 at 16:04 +0530, Shashank Sharma wrote:
> To support ycbcr HDMI output, we need a pipe CSC block to
> do the RGB->YCBCR conversion, as the blender output is in RGB.
>
> Current Intel platforms have only one pipe CSC unit, so
> we can either do color correction using it, or we can
On Wed, Jun 28, 2017 at 7:08 PM, Gustavo A. R. Silva
wrote:
> Hi Alex,
>
> Quoting "Deucher, Alexander" :
>
>>> -Original Message-
>>> From: Gustavo A. R. Silva [mailto:garsi...@embeddedor.com]
>>> Sent: Wednesday, June 28, 2017 10:22 AM
>>> To: Deucher, Alexander; Koenig, Christian; David
On Thu, Jun 29, 2017 at 12:59 PM, Maarten Lankhorst
wrote:
>> @@ -2538,6 +2563,12 @@ int drm_fb_helper_hotplug_event(struct drm_fb_helper
>> *fb_helper)
>> return 0;
>>
>> mutex_lock(&fb_helper->lock);
>> + if (fb_helper->deferred_setup) {
>> + err = __drm_fb_h
Commit 3fcdcb270936 ("drm/vblank: Switch to bool in_vblank_irq in
get_vblank_timestamp") inverted a condition by mistake that resulted in
vblank timestamps always being 0 on hardware without a vblank counter.
Fix it.
Fixes: 3fcdcb270936 ("drm/vblank: Switch to bool in_vblank_irq in
get_vblank_tim
On Thu, Jun 29, 2017 at 1:13 PM, Maarten Lankhorst
wrote:
> Oh ok. But there will always be a race. If DP-MST fails immediately after
> drm_dp_get_validated_port_ref,
> you'd still not be able to do anything about it. :)
This is just about not oopsing, any transactions to the sink will
still go
On 28 June 2017 at 14:10, Laurent Pinchart
wrote:
> Hi Emil,
>
> On Wednesday 28 Jun 2017 12:27:06 Emil Velikov wrote:
>> On 27 June 2017 at 21:38, Laurent Pinchart wrote:
>> > Hello,
>> >
>> > The atomic helpers favour the .enable() and .atomic_disable() CRTC helper
>> > operations, but still sup
On Thu, Jun 29, 2017 at 03:37:20PM +0300, Laurent Pinchart wrote:
> Commit 3fcdcb270936 ("drm/vblank: Switch to bool in_vblank_irq in
> get_vblank_timestamp") inverted a condition by mistake that resulted in
> vblank timestamps always being 0 on hardware without a vblank counter.
> Fix it.
>
> Fix
If we know the context under which we are called, then we can use the
simpler form of spin_lock_irq (saving the save/restore).
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Sean Paul
Cc: Gustavo Padovan
---
drivers/dma-buf/sw_sync.c| 15 +--
drivers/dma-buf/sync_debug.c | 1
Use the canonical __dma_fence_is_later() to compare the fence seqno
against the timeline seqno to check if the fence is signaled.
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Sean Paul
Cc: Gustavo Padovan
---
drivers/dma-buf/sw_sync.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
The sync_pt were not adding themselves atomically to the timeline lists,
corruption imminent. Only a single list is required to track the
unsignaled sync_pt, so reduce it and rename the lock more appropriately
along with using idiomatic names to distinguish a list from links along
it.
Signed-off-
The timeline is u32, which limits any single advance to INT_MAX so that
we can detect all fences that need signaling.
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Sean Paul
Cc: Gustavo Padovan
---
drivers/dma-buf/sw_sync.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/d
Since sync_pt is only allocated from a single location and is no longer
the base class for fences (that is struct dma_fence) it no longer needs
a generic unsized allocator.
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Sean Paul
Cc: Gustavo Padovan
---
drivers/dma-buf/sw_sync.c | 12 --
Reduce the list iteration when incrementing the timeline by storing the
fences in increasing order.
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Sean Paul
Cc: Gustavo Padovan
---
drivers/dma-buf/sw_sync.c| 49 ++--
drivers/dma-buf/sync_debug.h |
Often we have the task of comparing two seqno known to be on the same
context, so provide a common __dma_fence_is_later().
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Sean Paul
Cc: Gustavo Padovan
---
include/linux/dma-fence.h | 15 ++-
1 file changed, 14 insertions(+), 1 del
Reviewed-by: Thomas Hellstrom
On 06/27/2017 11:16 PM, Laurent Pinchart wrote:
The CRTC .prepare() helper operation is part of the legacy helpers and
is deprecated in favour of the .disable() helper operation. As the
vmwgfx driver provides a .disable() helper operation, and as the
.prepare() hel
Reviewed-by: Thomas Hellstrom
On 06/27/2017 11:16 PM, Laurent Pinchart wrote:
The CRTC helper .commit() operation is legacy code, the atomic helpers
prefer the .enable() operation. Replace the .commit() helper operation
with .enable() in the driver.
Signed-off-by: Laurent Pinchart
---
driv
For the vmwgfx part:
Reviewed-by: Thomas Hellstrom
On 06/27/2017 11:16 PM, Laurent Pinchart wrote:
The CRTC .disable() helper operation is deprecated for atomic drivers,
the new .atomic_disable() helper operation being preferred. Convert all
atomic drivers to .atomic_disable() to avoid cargo
For the vmwgfx part:
Reviewed-by: Thomas Hellstrom
On 06/27/2017 11:16 PM, Laurent Pinchart wrote:
The old state is useful for drivers that need to perform operations at
enable time that depend on the transition between the old and new
states.
While at it, rename the operation to .atomic_en
-Original Message-
From: Mark Brown [mailto:broo...@kernel.org]
Sent: Wednesday, June 28, 2017 11:36 PM
To: Alex Deucher
Cc: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org;
alsa-de...@alsa-project.org; airl...@gmail.com; Mukunda, Vijendar;
rajeevkumar.li...@gmail.com; lg
From: Ville Syrjälä
Split intel_atomic_commit_tail() into a lower level function that does
the actual commit, and a higher level one that waits for the
dependencies and signals the commit as done. We'll reuse the lower
level function to perform commits during GPU resets.
Signed-off-by: Ville Syr
From: Ville Syrjälä
I set out to fix the pre-g4x GPU reset by protecting display commits with
an rw_semaphore. I originally went all out and added infrastructure to track
the committed state (as opposed the latest swapped state), but Daniel suggested
that we want to backport the thing so I simpl
From: Ville Syrjälä
Pull the code to reallocate the state->connectors[] array into a
helper function. We'll have another use for this later.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_atomic.c | 43 +--
include/drm/drm_atomic.h | 5 +
From: Ville Syrjälä
For i915 GPU reset handling we'll want to be able to duplicate the state
that was last committed to the hardware. For that purpose let's provide
a helper function that is supposed to duplicate the state last committed
to the hardware. For now we'll actually just duplicate the
From: Ville Syrjälä
To avoid having to deference plane_state->vma during the commit phase of
plane updates, let's store the vma gtt offset (or the bus address when
we need it) in the plane state. This is crucial for doing the modeset
operations during GPU reset as as plane_state->vma gets cleared
From: Ville Syrjälä
Introduce an rw_semaphore to protect the display commits. All normal
commits use down_read() and hence can proceed in parallel, but GPU reset
will use down_write() making sure no other commits are in progress when
we have to pull the plug on the display engine on pre-g4x platf
Quoting ville.syrj...@linux.intel.com (2017-06-29 14:49:48)
> @@ -2640,15 +2600,13 @@ static void i915_reset_device(struct drm_i915_private
> *dev_priv)
> char *error_event[] = { I915_ERROR_UEVENT "=1", NULL };
> char *reset_event[] = { I915_RESET_UEVENT "=1", NULL };
> cha
On Thu, Jun 29, 2017 at 01:59:54PM +0200, Maarten Lankhorst wrote:
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/drm_framebuffer.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/drm_framebuffer.c
> b/drivers/gpu/drm/drm_framebuffer.c
> index fc8ef42203ec..
On Thu, Jun 29, 2017 at 04:57:25PM +0300, Ville Syrjälä wrote:
> On Thu, Jun 29, 2017 at 01:59:54PM +0200, Maarten Lankhorst wrote:
> > Signed-off-by: Maarten Lankhorst
> > ---
> > drivers/gpu/drm/drm_framebuffer.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/dr
From: Ville Syrjälä
Introduce an rw_semaphore to protect the display commits. All normal
commits use down_read() and hence can proceed in parallel, but GPU reset
will use down_write() making sure no other commits are in progress when
we have to pull the plug on the display engine on pre-g4x platf
On 06/28/2017 08:44 AM, Archit Taneja wrote:
>
>
> On 06/19/2017 09:58 PM, Philippe CORNU wrote:
>> Add a Synopsys Designware MIPI DSI host DRM bridge driver, based on the
>> Rockchip version from rockchip/dw-mipi-dsi.c with phy & bridge APIs.
>>
>> Signed-off-by: Philippe CORNU
>> ---
>> dr
Andrzej Hajda writes:
> On 29.06.2017 07:03, Archit Taneja wrote:
>>
>> On 06/28/2017 01:28 AM, Eric Anholt wrote:
>>> When a mipi_dsi_host is registered, the DT is walked to find any child
>>> nodes with compatible strings. Those get registered as DSI devices,
>>> and most DSI panel drivers are
On Wed, Jun 28, 2017 at 08:39:33PM +1000, Jonathan Liu wrote:
> >> + u32 int_status;
> >> + u32 fifo_status;
> >> + /* Read needs empty flag unset, write needs full flag unset */
> >> + u32 flag = read ? SUN4I_HDMI_DDC_FIFO_STATUS_EMPTY :
> >> + SUN4I_HDMI_DDC_
Hi,
On Wed, Jun 28, 2017 at 08:52:24PM +1000, Jonathan Liu wrote:
> The documentation for drm_do_get_edid in drivers/gpu/drm/drm_edid.c states:
> "As in the general case the DDC bus is accessible by the kernel at the I2C
> level, drivers must make all reasonable efforts to expose it as an I2C
> ad
https://bugs.freedesktop.org/show_bug.cgi?id=95269
--- Comment #4 from Ricardo Madrigal ---
Hello,
I just tried to reproduce the problem with following configuration:
BDW NUC, using an MST dongle emulating docking station and two external
monitors, one connected via DVI and the other one via DP
https://bugs.freedesktop.org/show_bug.cgi?id=95269
Ricardo Madrigal changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|NEEDINF
On Thu, Jun 29, 2017 at 01:59:29PM +0100, Chris Wilson wrote:
> The sync_pt were not adding themselves atomically to the timeline lists,
> corruption imminent. Only a single list is required to track the
> unsignaled sync_pt, so reduce it and rename the lock more appropriately
> along with using i
Quoting Sean Paul (2017-06-29 18:22:10)
> On Thu, Jun 29, 2017 at 01:59:29PM +0100, Chris Wilson wrote:
> > The sync_pt were not adding themselves atomically to the timeline lists,
> > corruption imminent. Only a single list is required to track the
> > unsignaled sync_pt, so reduce it and rename
https://bugs.freedesktop.org/show_bug.cgi?id=101528
--- Comment #1 from Alexander Tsoy ---
Same problem with TONGA. When GPU is idle, mclk goes to its maximum. This is
easily reproducible: just turn off the monitor. I noticed this issue after
upgrade from 4.9.x kernels to 4.11.7. Maybe I'll check
series merged to libdrm. thanks for patches and review.
On Wed, Jun 28, 2017 at 2:09 PM, Clint Taylor
wrote:
>
>
> On 06/21/2017 09:39 AM, Anusha Srivatsa wrote:
>>
>> Add the PCI IDs for U SKU IN CFL by following the spec.
>>
>> v2: Update IDs
>>
>> Cc: Rodrigo Vivi
>> Signed-off-by: Anusha Sri
https://bugs.freedesktop.org/show_bug.cgi?id=101651
Bug ID: 101651
Summary: [radeonsi][hawaii] Borderlands 2 rendering issues with
recent mesa/llvm
Product: Mesa
Version: git
Hardware: Other
OS: All
Quoting ville.syrj...@linux.intel.com (2017-06-29 15:36:42)
> From: Ville Syrjälä
>
> Introduce an rw_semaphore to protect the display commits. All normal
> commits use down_read() and hence can proceed in parallel, but GPU reset
> will use down_write() making sure no other commits are in progres
https://bugs.freedesktop.org/show_bug.cgi?id=101651
--- Comment #1 from Vadim Girlin ---
Created attachment 132355
--> https://bugs.freedesktop.org/attachment.cgi?id=132355&action=edit
screenshot (correct rendering)
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=101651
--- Comment #2 from Vadim Girlin ---
Created attachment 132356
--> https://bugs.freedesktop.org/attachment.cgi?id=132356&action=edit
llvm patch
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=101651
--- Comment #3 from Vadim Girlin ---
Created attachment 132357
--> https://bugs.freedesktop.org/attachment.cgi?id=132357&action=edit
reduced test
--
You are receiving this mail because:
You are the assignee for the bug.__
On Thu, Jun 29, 2017 at 01:59:30PM +0100, Chris Wilson wrote:
> Reduce the list iteration when incrementing the timeline by storing the
> fences in increasing order.
>
> Signed-off-by: Chris Wilson
> Cc: Sumit Semwal
> Cc: Sean Paul
> Cc: Gustavo Padovan
> ---
> drivers/dma-buf/sw_sync.c|
https://bugs.freedesktop.org/show_bug.cgi?id=95269
Ricardo Madrigal changed:
What|Removed |Added
Status|RESOLVED|CLOSED
Resolution|WORKSFORME
https://bugs.freedesktop.org/show_bug.cgi?id=95269
Ricardo Madrigal changed:
What|Removed |Added
Summary|monitors connected to |[DP] monitors connected to
Quoting Sean Paul (2017-06-29 19:10:11)
> On Thu, Jun 29, 2017 at 01:59:30PM +0100, Chris Wilson wrote:
> > Reduce the list iteration when incrementing the timeline by storing the
> > fences in increasing order.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Sumit Semwal
> > Cc: Sean Paul
> > Cc:
On Thu, Jun 29, 2017 at 1:38 PM, Gustavo A. R. Silva
wrote:
> Add function header comment to make it clear that local variable sw_cg
> is used for debugging and it should not be removed.
>
> Addresses-Coverity-ID: 1198635
> Cc: Alex Deucher
> Signed-off-by: Gustavo A. R. Silva
Applied. thanks!
On Thu, Jun 29, 2017 at 06:57:30PM +0100, Chris Wilson wrote:
> Quoting ville.syrj...@linux.intel.com (2017-06-29 15:36:42)
> > From: Ville Syrjälä
> >
> > Introduce an rw_semaphore to protect the display commits. All normal
> > commits use down_read() and hence can proceed in parallel, but GPU r
https://bugs.freedesktop.org/show_bug.cgi?id=101528
--- Comment #2 from Alexander Tsoy ---
I've added printing of some debug info into smu7_hwmgr.c and here what I get
before GPU enters that state:
[ 778.701843] AMDGPU: vblank_time_us: 630, switch_limit_us: 450
[ 778.707608] AMDGPU:
On Fri, Jun 23, 2017 at 09:45:42AM -0700, Ben Widawsky wrote:
> Updated blob layout (Rob, Daniel, Kristian, xerpi)
>
> v2:
> * Removed __packed, and alignment (.+)
> * Fix indent in drm_format_modifier fields (Liviu)
> * Remove duplicated modifier > 64 check (Liviu)
> * Change comment about modifi
Rob,
On Wed, Jun 14, 2017 at 2:49 PM, Thierry Reding
wrote:
>> +Required properties:
>> +- compatible: should be "sii,43wvf1g".
>> +- "DVDD-supply": 3v3 digital regulator.
>> +- "AVDD-supply": 5v analog regulator.
>
> I don't think we should be using all-uppercase for supply names. So the
> abov
On Fri, Jun 23, 2017 at 09:45:43AM -0700, Ben Widawsky wrote:
> This was based on a patch originally by Kristian. It has been modified
> pretty heavily to use the new callbacks from the previous patch.
>
> v2:
> - Add LINEAR and Yf modifiers to list (Ville)
> - Combine i8xx and i965 into one l
On Fri, Jun 23, 2017 at 09:45:44AM -0700, Ben Widawsky wrote:
> v2:
> Support sprite plane.
> Support pipe C/D limitation on GEN9.
>
> This requires rebase on the correct Ville patches
>
> Cc: Daniel Stone
> Cc: Kristian Høgsberg
> Signed-off-by: Ben Widawsky
> ---
> drivers/gpu/drm/i915/inte
On Thu, Jun 29, 2017 at 01:59:24PM +0100, Chris Wilson wrote:
> Often we have the task of comparing two seqno known to be on the same
> context, so provide a common __dma_fence_is_later().
>
> Signed-off-by: Chris Wilson
> Cc: Sumit Semwal
> Cc: Sean Paul
Hi Chris,
Thanks for writing the code
https://bugs.freedesktop.org/show_bug.cgi?id=101528
--- Comment #3 from Alex Deucher ---
Created attachment 132358
--> https://bugs.freedesktop.org/attachment.cgi?id=132358&action=edit
possible fix
--
You are receiving this mail because:
You are the assignee for the bug.__
The sync_pt were not adding themselves atomically to the timeline lists,
corruption imminent. Only a single list is required to track the
unsignaled sync_pt, so reduce it and rename the lock more appropriately
along with using idiomatic names to distinguish a list from links along
it.
v2: Prevent
Reduce the list iteration when incrementing the timeline by storing the
fences in increasing order.
v2: Prevent spinlock recursion on free during create
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Sean Paul
Cc: Gustavo Padovan
---
drivers/dma-buf/sw_sync.c| 49 ++
On Thu, Jun 29, 2017 at 1:54 PM, Peter Griffin wrote:
> This patch fixes the following soft lockup:
> BUG: soft lockup - CPU#0 stuck for 23s! [weston:307]
>
> On weston idle-timeout the IP is powered down and reset
> asserted. On weston resume we get a massive vblank
> IRQ storm due to the LDI r
Reduce the list iteration when incrementing the timeline by storing the
fences in increasing order.
v2: Prevent spinlock recursion on free during create
v3: Fixup rebase conflict inside comments that escaped the compiler.
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Sean Paul
Cc: Gustavo P
By the Spec all CNL Y skus are 2+2, i.e. GT2.
This is a copy of merged i915's
commit 95578277cbdb ("drm/i915/cnl: Add Cannonlake PCI IDs for Y-skus.")
v2: Add kernel commit id for reference.
Cc: Anusha Srivatsa
Cc: Clinton Taylor
Signed-off-by: Rodrigo Vivi
---
intel/intel_chipset.h | 16 +++
From: Paulo Zanoni
As far as I understand, IS_9XX should return true for it.
Signed-off-by: Paulo Zanoni
---
intel/intel_chipset.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
index 37579c6..770d21f 100644
--- a/intel/intel
Platform enabling and its power-on are organized in different
skus (U x Y x S x H, etc). So instead of organizing it in
GT1 x GT2 x GT3 let's also use the platform sku.
This is a copy of merged i915's
commit e918d79a5d0a ("drm/i915/cnl: Add Cannonlake PCI IDs for U-skus.")
v2: Remove PCI IDs for
From: Ben Widawsky
This got lost on rebase, I believe
Signed-off-by: Ben Widawsky
---
intel/intel_bufmgr_gem.c | 2 ++
intel/intel_decode.c | 4 +++-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 45a26da..71f140f 100
https://bugs.freedesktop.org/show_bug.cgi?id=101528
--- Comment #4 from Alexander Tsoy ---
(In reply to Alex Deucher from comment #3)
> Created attachment 132358 [details] [review]
> possible fix
This patch fixes this bug for me. Thank you!
[ 359.229187] AMDGPU: vblank_time_us: 630, switch_lim
1 - 100 of 140 matches
Mail list logo
