On pe, 2017-02-24 at 06:01 -0800, Oscar Mateo wrote:
> This vma contains much more than just the additional data struct (ads)
> and since we were already using the word "addon" as an object in
> guc_addon_create, make it the preffered one. No need for the vma suffix
> either, as that dependency is
HDMI 2.0 spec defines a method to reduce the RF footprint while
operating at higher pixel clocks, which is called Scrambling.
Scrambling can be controlled over a new set of I2C registers
which are accessible over existing DDC I2C lines, called SCDC
register set.
This patch series contains 6 patche
From: Thierry Reding
SCDC is a mechanism defined in the HDMI 2.0 specification that allows
the source and sink devices to communicate.
This commit introduces helpers to access the SCDC and provides the
symbolic names for the various registers defined in the specification.
V2: Rebase.
V3: Added
From: Thierry Reding
This patch implements a small function that finds if a
given CEA db is hdmi-forum vendor specific data block
or not.
V2: Rebase.
V3: Added R-B from Jose.
V4: Rebase
V5: Rebase
Signed-off-by: Thierry Reding
Signed-off-by: Shashank Sharma
Reviewed-by: Jose Abreu
---
drive
This patch does following:
- Adds a new structure (drm_hdmi_info) in drm_display_info.
This structure will be used to save and indicate if sink
supports advanced HDMI 2.0 features
- Adds another structure drm_scdc within drm_hdmi_info, to
reflect scdc support and capabilities in connected HDM
Geminilake has a native HDMI 2.0 controller, which is capable of
driving clocks upto 594Mhz. This patch updates the max tmds clock
limit for the same.
V2: rebase
V3: rebase
V4: added r-b from Ander
V5: rebase
Cc: Ander Conselvan De Oliveira
Signed-off-by: Shashank Sharma
Reviewed-by: Ander Cons
This patch does following:
- Adds a new structure (drm_hdmi_info) in drm_display_info.
This structure will be used to save and indicate if sink
supports advanced HDMI 2.0 features
- Adds another structure drm_scdc within drm_hdmi_info, to
reflect scdc support and capabilities in connected HDM
Geminilake platform sports a native HDMI 2.0 controller, and is
capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec
mendates scrambling for these higher clocks, for reduced RF footprint.
This patch checks if the monitor supports scrambling, and if required,
enables it during the modeset.
V
On Tue, Feb 28, 2017 at 07:42:50AM +, Tvrtko Ursulin wrote:
>
> On 27/02/2017 23:41, Chris Wilson wrote:
> >Move the setting of gpu_error->missed_irq_ring bit to a common function
> >so that we can get the debug logging for either path.
> >
> >Signed-off-by: Chris Wilson
> >Cc: Tvrtko Ursulin
On 28/02/2017 08:35, Chris Wilson wrote:
On Tue, Feb 28, 2017 at 07:42:50AM +, Tvrtko Ursulin wrote:
On 27/02/2017 23:41, Chris Wilson wrote:
Move the setting of gpu_error->missed_irq_ring bit to a common function
so that we can get the debug logging for either path.
Signed-off-by: Chris
Following the use of dma_fence_signal() from within our interrupt
handler, we need to make guc->wq_lock also irq-safe. This was done
previously as part of the guc scheduler patch (which also started
mixing our fences with the interrupt handler), but is now required to
fix the current guc submission
Move the setting of gpu_error->missed_irq_ring bit to a common function
so that we can get the debug logging for either path.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_breadcrumbs.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff
Move the setting of gpu_error->missed_irq_ring bit to a common function
so that we can get the debug logging for either path.
v2: Add %pF caller
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_breadcrumbs.c | 15 ---
1 file
== Series Details ==
Series: HDMI 2.0: Scrambling in DRM layer (rev5)
URL : https://patchwork.freedesktop.org/series/19161/
State : success
== Summary ==
Series 19161v5 HDMI 2.0: Scrambling in DRM layer
https://patchwork.freedesktop.org/api/1.0/series/19161/revisions/5/mbox/
fi-bdw-5557u
On 28/02/2017 08:47, Chris Wilson wrote:
Following the use of dma_fence_signal() from within our interrupt
handler, we need to make guc->wq_lock also irq-safe. This was done
previously as part of the guc scheduler patch (which also started
mixing our fences with the interrupt handler), but is no
Hi,
On 27-02-17 18:16, Bob Paauwe wrote:
On Sat, 25 Feb 2017 11:42:09 +0100
Hans de Goede wrote:
Hi,
On 24-02-17 18:02, Bob Paauwe wrote:
On Mon, 20 Feb 2017 15:08:42 +0100
Hans de Goede wrote:
According to the spec for v2 VBTs we should call MIPI_SEQ_DISPLAY_OFF
before sending SHUTDOWN,
On Tue, Feb 28, 2017 at 08:47:17AM +, Chris Wilson wrote:
> Move the setting of gpu_error->missed_irq_ring bit to a common function
> so that we can get the debug logging for either path.
Ignore me, bad git send-email before coffee.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Mon, Feb 27, 2017 at 05:31:04PM -0800, Joe Perches wrote:
> Use a more common logging style.
>
> Miscellanea:
>
> o Coalesce formats and realign arguments
> o Neaten a few macros now using pr_
>
> Signed-off-by: Joe Perches
I know this is pain, but can you pls split this into:
- amd/radeon
On Mon, Feb 27, 2017 at 05:18:08PM -0800, Ben Widawsky wrote:
> On 17-02-27 17:12:07, Rodrigo Vivi wrote:
> >Many screen corruptions and hangs in the past were somehow
> >related to the caches. In many situations forcing the uncached
> >was useful at least to narrow down the issue by confirming it
Following the use of dma_fence_signal() from within our interrupt
handler, we need to make guc->wq_lock also irq-safe. This was done
previously as part of the guc scheduler patch (which also started
mixing our fences with the interrupt handler), but is now required to
fix the current guc submission
On Tue, Feb 28, 2017 at 09:09:04AM +, Chris Wilson wrote:
> Following the use of dma_fence_signal() from within our interrupt
> handler, we need to make guc->wq_lock also irq-safe. This was done
> previously as part of the guc scheduler patch (which also started
> mixing our fences with the int
On Tue, Feb 28, 2017 at 08:58:18AM +, Tvrtko Ursulin wrote:
>
> On 28/02/2017 08:47, Chris Wilson wrote:
> >Following the use of dma_fence_signal() from within our interrupt
> >handler, we need to make guc->wq_lock also irq-safe. This was done
> >previously as part of the guc scheduler patch (
== Series Details ==
Series: drm/i915/guc: Make wq_lock irq-safe
URL : https://patchwork.freedesktop.org/series/20355/
State : success
== Summary ==
Series 20355v1 drm/i915/guc: Make wq_lock irq-safe
https://patchwork.freedesktop.org/api/1.0/series/20355/revisions/1/mbox/
fi-bdw-5557u tot
From: Hans de Goede
intel_dsi_disable/enable only have one caller, merge them into their
respective callers.
Change msleep(2) into usleep_range(2000, 5000) to make checkpatch happy,
otherwise no functional changes.
The main advantage of this change is that it makes it easier to
follow all the s
From: Hans de Goede
The enable path has an intel_dsi_prepare() helper which prepares various
registers for the mode-set. Move the code undoing this to a new
intel_dsi_unprepare() helper function for better symmetry between the
enable and disable paths. No functional changes.
Signed-off-by: Hans
From: Hans de Goede
Move the intel_dsi_clear_device_ready() function to higher up in
intel_dsi.c this pairs it with intel_dsi_device_ready(); and pairs
intel_dsi_*enable* with intel_dsi_*disable without
intel_dsi_clear_device_ready() sitting in the middle of them.
This commit purely moves code a
From: Hans de Goede
On some devices only MIPI PORT C is used, in this case checking the
MIPI PORT A CTRL AFE_LATCHOUT bit (there is no such bit for PORT C
on VLV/CHT) will result in false positive "DSI LP not going Low" errors
as this checks the PORT A clk status.
In case both ports are used we
From: Hans de Goede
The drm_panel_enable/disable and drm_panel_prepare/unprepare calls are
not fine grained enough to abstract all the different steps we need to
take (and VBT sequences we need to exec) properly. So simply remove the
panel _enable/disable and prepare/unprepare callbacks and inste
Hans, I don't know what's going on, but patchwork didn't get your series
[1] or patch [2] although they hit the list, and they didn't go through
CI because of that. I recall this happening before with your patches.
I picked up the patches from the front of the series and the separate
single patch
From: Hans de Goede
Instead of calling wait_for_dsi_fifo_empty on all dsi ports after calling
a drm_panel_foo helper which calls VBT sequences, move it to the VBT
mipi_exec_send_packet helper, which is the one VBT instruction which
actually puts data in the fifo.
This results in a nice cleanup m
Following the use of dma_fence_signal() from within our interrupt
handler, we need to make guc->wq_lock also irq-safe. This was done
previously as part of the guc scheduler patch (which also started
mixing our fences with the interrupt handler), but is now required to
fix the current guc submission
Hi,
On 25-02-17 11:31, Hans de Goede wrote:
Hi Bob,
Thank you for the review of this patch-set.
On 24-02-17 18:00, Bob Paauwe wrote:
On Mon, 20 Feb 2017 15:08:35 +0100
Hans de Goede wrote:
Document the DSI panel enable / disable sequences from the spec,
for easy comparison between the code
Hi,
On 28-02-17 10:26, Jani Nikula wrote:
Hans, I don't know what's going on, but patchwork didn't get your series
[1] or patch [2] although they hit the list, and they didn't go through
CI because of that. I recall this happening before with your patches.
I picked up the patches from the front
On Tue, 28 Feb 2017, Hans de Goede wrote:
> Hi,
>
> On 28-02-17 10:26, Jani Nikula wrote:
>> Hans, I don't know what's going on, but patchwork didn't get your series
>> [1] or patch [2] although they hit the list, and they didn't go through
>> CI because of that. I recall this happening before wit
== Series Details ==
Series: drm/i915: Consolidate reporting of "missed breadcrumbs" (rev3)
URL : https://patchwork.freedesktop.org/series/20330/
State : warning
== Summary ==
Series 20330v3 drm/i915: Consolidate reporting of "missed breadcrumbs"
https://patchwork.freedesktop.org/api/1.0/serie
Hi,
On 28-02-17 10:50, Jani Nikula wrote:
On Tue, 28 Feb 2017, Hans de Goede wrote:
Hi,
On 28-02-17 10:26, Jani Nikula wrote:
Hans, I don't know what's going on, but patchwork didn't get your series
[1] or patch [2] although they hit the list, and they didn't go through
CI because of that. I
On Fri, 17 Feb 2017, Madhav Chauhan wrote:
> The patches in this list enable MIPI DSI video mode
> support for GLK platform. Tesed locally.
> v2: Renamed bitfields macros as per review comments(Jani)
> v3: Code alignment/abstraction as per arch (Jani review comments)
> v4: Fix MIPI DSI disable seq
On Tue, Feb 28, 2017 at 09:28:10AM +, Chris Wilson wrote:
> Following the use of dma_fence_signal() from within our interrupt
> handler, we need to make guc->wq_lock also irq-safe. This was done
> previously as part of the guc scheduler patch (which also started
> mixing our fences with the int
We've switched to refcounting for the event completion, which means
there's no risk for use-after free anymore after:
commit 24835e442f289813aa568d142a755672a740503c
Author: Daniel Vetter
Date: Wed Dec 21 11:23:30 2016 +0100
drm: reference count event->completion
This should make the comm
On Tue, Feb 28, 2017 at 11:07:58AM +0100, Michal Wajdeczko wrote:
> On Tue, Feb 28, 2017 at 09:28:10AM +, Chris Wilson wrote:
> > @@ -951,10 +958,12 @@ int i915_guc_submission_enable(struct
> > drm_i915_private *dev_priv)
> > engine->schedule = NULL;
> >
> > /* Replay
== Series Details ==
Series: drm/i915/dsi: subset of the cleanups from Hans
URL : https://patchwork.freedesktop.org/series/20361/
State : failure
== Summary ==
Series 20361v1 drm/i915/dsi: subset of the cleanups from Hans
https://patchwork.freedesktop.org/api/1.0/series/20361/revisions/1/mbox/
On Tue, 28 Feb 2017, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/dsi: subset of the cleanups from Hans
> URL : https://patchwork.freedesktop.org/series/20361/
> State : failure
>
> == Summary ==
>
> Series 20361v1 drm/i915/dsi: subset of the cleanups from Hans
> https://patchwor
== Series Details ==
Series: drm/i915/guc: Make wq_lock irq-safe (rev3)
URL : https://patchwork.freedesktop.org/series/20355/
State : success
== Summary ==
Series 20355v3 drm/i915/guc: Make wq_lock irq-safe
https://patchwork.freedesktop.org/api/1.0/series/20355/revisions/3/mbox/
fi-bdw-5557u
Leave the runtime check in place in case the platform variable itself
comes from bogus sources.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_device_info.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915
On Tue, Feb 28, 2017 at 01:11:43PM +0200, Jani Nikula wrote:
> Leave the runtime check in place in case the platform variable itself
> comes from bogus sources.
>
> Signed-off-by: Jani Nikula
Neat.
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_
Following the use of dma_fence_signal() from within our interrupt
handler, we need to make guc->wq_lock also irq-safe. This was done
previously as part of the guc scheduler patch (which also started
mixing our fences with the interrupt handler), but is now required to
fix the current guc submission
A couple of operations, the flushes and the tracepoint, do not require
serialisation by client->wq_lock, so move them before we take it.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_guc_submission.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions
---
drivers/gpu/drm/i915/i915_params.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index 2e9645e6555a..8fa96edddf9f 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_p
This patch make changes to use linetime latency if allocated
DDB size during plane watermark calculation in switch case not available,
This is required to implement new DDB allocation algorithm.
In New Algorithm DDB is allocated based on WM values, because of which
number of DDB blocks will not be
This series implements new DDB allocation algorithm to solve the cases,
where we have sufficient DDB available to enable multiple planes, But
due to the current algorithm not dividing it properly among planes, we
end-up failing the flip.
It also takes care of enabling same watermark level for each
We are already doing memset of ddb structure at the begining of
skl_allocatE_pipe_ddb
function, No need to again do a memset.
Signed-off-by: Mahesh Kumar
---
drivers/gpu/drm/i915/intel_pm.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/
Fail the flip if no FB is present but plane_state is set as visible,
that is not a valid combination so instead of continue fail the flip.
Signed-off-by: Mahesh Kumar
---
drivers/gpu/drm/i915/intel_pm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/in
This patch make changes to calculate adjusted plane pixel rate &
plane downscale amount using fixed_point functions available. This also
adds few fixed point function to facilitate calculation.
Signed-off-by: Mahesh Kumar
---
drivers/gpu/drm/i915/i915_drv.h | 34 +
This patch cleans the watermark calculation functions. This patch make
use of already available macro to walk through plane_state list instead
of calculating plane_state in function itself.
Now we iterate over WM levels in skl_compute_wm_level function.
Signed-off-by: Mahesh Kumar
---
drivers/gp
DDB minimum requirement may also exceed the allocated DDB for CRTC.
Instead of directly deducting from alloc_size, check against
total_min_ddb requirement. if exceeding fail the flip.
Signed-off-by: Mahesh Kumar
---
drivers/gpu/drm/i915/intel_pm.c | 13 +++--
1 file changed, 11 insertion
A display resolution is only supported if it meets all the restrictions
below for Maximum Pipe Pixel Rate.
The display resolution must fit within the maximum pixel rate output
from the pipe. Make sure that the display pipe is able to feed pixels at
a rate required to support the desired resolution
This patch implements new DDB allocation algorithm as per HW team
recommendation. This algo takecare of scenario where we allocate less DDB
for the planes with lower relative pixel rate, but they require more DDB
to work.
It also takes care of enabling same watermark level for each
plane, for effic
The new version patchwork is filtering out my patches for some reason.
Test if it's because it now insists on a capital [PATCH] in the subject.
Patchwork should be more version control agnostic than that.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/dr
On 28/02/2017 11:28, Chris Wilson wrote:
Following the use of dma_fence_signal() from within our interrupt
handler, we need to make guc->wq_lock also irq-safe. This was done
previously as part of the guc scheduler patch (which also started
mixing our fences with the interrupt handler), but is no
i915_gem_object_is_dead() was a temporary lockdep aide whilst
transitioning to a new locking structure for obj->mm. Since commit
1233e2db199d ("drm/i915: Move object backing storage manipulation to its
own locking") it is now unused and should be removed.
Signed-off-by: Chris Wilson
Cc: Joonas L
On 28/02/2017 11:28, Chris Wilson wrote:
A couple of operations, the flushes and the tracepoint, do not require
serialisation by client->wq_lock, so move them before we take it.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_guc_submission.c | 13 +++--
The new version of patchwork is filtering out my patches which apply
fine with git am and have worked for everyone else's patchwork. Perhaps
it's insisting on a --- break?
Signed-off-by: Dan Carpenter
---
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index d1670
This is the control where I resend the original patch to make verify
that it really doesn't work as-is.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index d1670b8afbf5..9173548ba601 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/
On Tue, Feb 28, 2017 at 09:52:30AM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Consolidate reporting of "missed breadcrumbs" (rev3)
> URL : https://patchwork.freedesktop.org/series/20330/
> State : warning
>
> == Summary ==
>
> Series 20330v3 drm/i915: Consolidate repo
On 28.02.2017 11:11, Daniel Vetter wrote:
> We've switched to refcounting for the event completion, which means
> there's no risk for use-after free anymore after:
>
> commit 24835e442f289813aa568d142a755672a740503c
> Author: Daniel Vetter
> Date: Wed Dec 21 11:23:30 2016 +0100
>
> drm: refe
On Thu, Feb 23, 2017 at 10:09:27AM -0500, Sean Paul wrote:
> On Tue, Feb 21, 2017 at 02:51:41PM +0100, Maarten Lankhorst wrote:
> > Instead of trying to do everything in 1 go, just do a basic safe
> > conversion first. We've been bitten by too many regressions in the
> > past.
> >
> > This patch o
On Tue, Feb 28, 2017 at 02:46:18PM +0300, Dan Carpenter wrote:
> The new version of patchwork is filtering out my patches which apply
> fine with git am and have worked for everyone else's patchwork. Perhaps
> it's insisting on a --- break?
>
> Signed-off-by: Dan Carpenter
> ---
iirc, pw does i
On Tue, Feb 28, 2017 at 12:10:19PM +, Chris Wilson wrote:
> On Tue, Feb 28, 2017 at 02:46:18PM +0300, Dan Carpenter wrote:
> > The new version of patchwork is filtering out my patches which apply
> > fine with git am and have worked for everyone else's patchwork. Perhaps
> > it's insisting on
== Series Details ==
Series: drm/atomic-helpers: Make nonblocking more resilient
URL : https://patchwork.freedesktop.org/series/20369/
State : warning
== Summary ==
Series 20369v1 drm/atomic-helpers: Make nonblocking more resilient
https://patchwork.freedesktop.org/api/1.0/series/20369/revisio
On ti, 2017-02-28 at 13:11 +0200, Jani Nikula wrote:
> Leave the runtime check in place in case the platform variable itself
> comes from bogus sources.
>
> Signed-off-by: Jani Nikula
> @@ -890,6 +890,7 @@ enum intel_platform {
> INTEL_BROXTON,
> INTEL_KABYLAKE,
> INTEL_GEMIN
Broken up for Daniel Vetter
Joe Perches (3):
gpu: drm: amd/radeon: Convert printk(KERN_ to pr_
gpu: drm: core: Convert printk(KERN_ to pr_
gpu: drm: drivers: Convert printk(KERN_ to pr_
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 3 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_afmt.c
Use a more common logging style.
Miscellanea:
o Coalesce formats and realign arguments
o Neaten a few macros now using pr_
Signed-off-by: Joe Perches
---
drivers/gpu/drm/gma500/cdv_intel_lvds.c | 9 -
drivers/gpu/drm/gma500/oaktrail_lvds.c| 18 +-
drivers
Now that we are no longer bound to the drm_panel_ callbacks, call
MIPI_SEQ_POWER_ON/OFF at the proper place.
Signed-off-by: Hans de Goede
Reviewed-by: Bob Paauwe
---
drivers/gpu/drm/i915/intel_dsi.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i
intel_dsi_post_disable(), which does the MIPI_SEQ_ASSERT_RESET,
will always be called at some point before intel_dsi_pre_enable()
making the MIPI_SEQ_ASSERT_RESET in intel_dsi_pre_enable() redundant.
In addition, calling MIPI_SEQ_ASSERT_RESET in the enable path goes
against the VBT spec.
Signed-o
Document the DSI panel enable / disable sequences from the spec,
for easy comparison between the code and the spec.
Signed-off-by: Hans de Goede
Acked-by: Jani Nikula
---
Changes in v2:
-Make the comment a table with 3 columns for easier comparison of the
3 sequences
---
drivers/gpu/drm/i915/i
Move the DPOunit clock gate workaround to directly after the PLL enable.
The exact location of the workaround does not matter and there are 2
reasons to group it with the PLL enable:
1) This moves it out of the middle of the init sequence from the spec,
making it easier to follow the init sequ
For v3 VBTs in vid-mode the delays are part of the VBT sequences, so
we should not also delay ourselves otherwise we get double delays.
Signed-off-by: Hans de Goede
Reviewed-by: Bob Paauwe
---
drivers/gpu/drm/i915/intel_dsi.c | 19 +++
1 file changed, 15 insertions(+), 4 deletio
Execute MIPI_SEQ_DEASSERT_RESET before putting the device in ready
state (LP-11), this is the sequence in which things should be done
according to the spec.
Signed-off-by: Hans de Goede
Reviewed-by: Bob Paauwe
---
drivers/gpu/drm/i915/intel_dsi.c | 9 +++--
1 file changed, 7 insertions(+),
According to the spec we should call MIPI_SEQ_TEAR_ON and DISPLAY_ON
on enable for cmd-mode, just like we already call their counterparts
on disable. Note: untested, my panel is a vid-mode panel.
Signed-off-by: Hans de Goede
Reviewed-by: Bob Paauwe
---
drivers/gpu/drm/i915/intel_dsi.c | 2 ++
1
Execute the MIPI_SEQ_BACKLIGHT_ON/OFF VBT sequences at the same time as
we call intel_panel_enable_backlight() / intel_panel_disable_backlight().
Signed-off-by: Hans de Goede
Reviewed-by: Bob Paauwe
---
Changes in v2:
-Drop meaningless code-comments
---
drivers/gpu/drm/i915/intel_dsi.c | 4 ++--
According to the spec for v2 VBTs we should call MIPI_SEQ_DISPLAY_OFF
before sending SHUTDOWN, where as for v3 VBTs we should send SHUTDOWN
first.
Since the v2 order has known issues, we use the v3 order everywhere,
add a comment documenting this.
Signed-off-by: Hans de Goede
---
Changes in v2:
For v3+ VBTs we should call MIPI_SEQ_TEAR_OFF before MIPI_SEQ_DISPLAY_OFF,
v2 VBTs do not have MIPI_SEQ_TEAR_OFF so there this is a nop.
Signed-off-by: Hans de Goede
---
Changes in v2:
-Only call MIPI_SEQ_TEAR_OFF in cmd mode
---
drivers/gpu/drm/i915/intel_dsi.c | 2 ++
1 file changed, 2 inserti
On ti, 2017-02-28 at 11:13 +, Chris Wilson wrote:
> i915_gem_object_is_dead() was a temporary lockdep aide whilst
> transitioning to a new locking structure for obj->mm. Since commit
> 1233e2db199d ("drm/i915: Move object backing storage manipulation to its
> own locking") it is now unused and
On 22 February 2017 at 15:25, Robert Bragg wrote:
> This updates the tail pointer race workaround handling to updating the
> 'aged' pointer before looking to start aging a new one. There's the
> possibility that there is already new data available and so we can
> immediately start aging a new poin
On 22 February 2017 at 15:25, Robert Bragg wrote:
> This change is pre-emptively aiming to avoid a potential cause of kernel
> logging noise in case some condition were to result in us seeing invalid
> OA reports.
>
> The workaround for the OA unit's tail pointer race condition is what
> avoids th
On Tue, Feb 28, 2017 at 09:21:12AM +0200, Ander Conselvan de Oliveira wrote:
> Commit 62b695662a24 ("drm/i915: Only enable DDI IO power domains after
> enabling DPLL") changed how the DDI IO power domains get enabled, but
> neglected the need to enable those domains when enabling a DP connector
> w
On Tue, Feb 28, 2017 at 01:28:13PM +, Matthew Auld wrote:
> On 22 February 2017 at 15:25, Robert Bragg wrote:
> > This change is pre-emptively aiming to avoid a potential cause of kernel
> > logging noise in case some condition were to result in us seeing invalid
> > OA reports.
> >
> > The wo
On Tue, Feb 28, 2017 at 04:55:51AM -0800, Joe Perches wrote:
> Broken up for Daniel Vetter
Thanks, I applied the core patch (needed a minor resolution in
drm_edid.c). I'll wait with the driver patch for a few more acks maybe,
and leave the 2 other patches to Alex for picking up directly.
Thanks,
== Series Details ==
Series: drm/i915: use BUILD_BUG_ON to ensure platform name has been set up
URL : https://patchwork.freedesktop.org/series/20373/
State : failure
== Summary ==
Series 20373v1 drm/i915: use BUILD_BUG_ON to ensure platform name has been set
up
https://patchwork.freedesktop.o
Nothing special, just rote conversion.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_hotplug.c | 28 ++--
1 file changed, 18 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hotplug.c
b/drivers/gpu/drm/i915/intel_hotplug.c
index 0756b
While at it also try to reduce the locking a bit to what's really just
needed instead of everything that we could possibly lock.
Added a new for_each_intel_connector_iter which includes the cast to
intel_connector.
Otherwise just plain transformation with nothing special going on.
v2: Review fro
This gets rid of the last users of for_each_intel_connector(), remove
that too.
At first I wasn't sure whether the 2 loops in the modeset state
checker should instead only loop over the connectors in the atomic
commit. But we never add connectors to an atomic update if they don't
(or won't have) a
One case where I nuked a now unecessary locking, otherwise all just
boring stuff.
Cc: Jani Nikula
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_opregion.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_opregion.c
b/
The trouble here is that looking at all connector->state in the
verifier isn't good, because that's run from the commit work, which
doesn't hold the connection_mutex. Which means we're only allowed to
look at states in our atomic update.
The simple fix for future proofing would be to switch over t
Drive-by fixup while looking at all the connector_list walkers -
holding connection_mutex does actually _not_ give you locking to look
at the legacy drm_connector->encoder->crtc pointer chain. That one is
solely owned by the atomic commit workers. Instead we must inspect the
atomic state.
Signed-o
On Tue, Feb 28, 2017 at 09:21:13AM +0200, Ander Conselvan de Oliveira wrote:
> The logic to enable a DDI in intel_mst_pre_enable_dp() is essentially
> the same as in intel_ddi_pre_enable_dp(). So reuse the latter function
> by calling the post_disable hook on the intel_dig_port instead of
Additionally use runtime check to catch invalid engine indices.
Signed-off-by: Michal Wajdeczko
Cc: Jani Nikula
---
drivers/gpu/drm/i915/intel_engine_cs.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index
On Tue, 2017-02-28 at 07:53 +, Patchwork wrote:
> == Series Details ==
>
> Series: Try to fix MST regression with DDI IO power domains
> URL : https://patchwork.freedesktop.org/series/20345/
> State : failure
>
> == Summary ==
>
> Series 20345v1 Try to fix MST regression with DDI IO power
On ti, 2017-02-28 at 14:00 +, Michal Wajdeczko wrote:
> Additionally use runtime check to catch invalid engine indices.
>
> Signed-off-by: Michal Wajdeczko
> Cc: Jani Nikula
Reviewed-by: Joonas Lahtinen
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
__
On Tue, 28 Feb 2017, Joonas Lahtinen wrote:
> On ti, 2017-02-28 at 13:11 +0200, Jani Nikula wrote:
>> Leave the runtime check in place in case the platform variable itself
>> comes from bogus sources.
>>
>> Signed-off-by: Jani Nikula
>
>
>
>> @@ -890,6 +890,7 @@ enum intel_platform {
>> IN
1 - 100 of 179 matches
Mail list logo
