On Mon, Dec 14, 2015 at 02:07:23PM +0530, Jindal, Sonika wrote:
> %s/cpy/cpu
>
> Reviewed-by: Sonika Jindal
Queued for -next, thanks for the review.
-Daniel
>
> On 12/12/2015 12:14 AM, Daniel Vetter wrote:
> >I missed this myself when reviewing
> >
> >commit 237ed86c693d8a8e4db476976aeb30df4de
On Fri, Dec 11, 2015 at 10:18:35PM +, Chris Wilson wrote:
> igt likes to inject GPU hangs into its command streams. However, as we
> expect these hangs, we don't actually want them recorded in the dmesg
> output or stored in the i915_error_state (usually). To accomodate this
> allow userspace t
On Mon, 14 Dec 2015, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> My 85x has VBT version 108 which has a child dev size of 27 bytes.
> Let's allow that without printing an error.
>
> We still want to reject the actual parsin since for that we need
> the child device size to be at
On Mon, 14 Dec 2015, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> My 830 has VBT version 105 with child device size of 22 bytes.
> Let's assume that's correct and adjust our expectations.
>
> Signed-off-by: Ville Syrjälä
Let's see what blows up...
Acked-by: Jani Nikula
> -
On Sat, Dec 12, 2015 at 08:02:49PM +, Chris Wilson wrote:
> Wean drv_hangman off the atrocious stop_rings and use a real GPU hang
> instead.
>
> Signed-off-by: Chris Wilson
Doesn't this kill pre-gen6? Or at least anything where we don't have
proper hang recovery ... Lack of that is why I've
On Sun, Dec 13, 2015 at 08:37:04PM +0530, Sagar Arun Kamble wrote:
> From: Sagar Kamble
>
> With BXT, now all platforms from GEN6 to GEN9 support Runtime PM except IVB.
>
> Cc: Paulo Zanoni
> Cc: Imre Deak
> Change-Id: I700bf5092d6462b64499d876efeaea9dfa540380
> Signed-off-by: A.Sunil Kamath
On Tue, 08 Dec 2015, Jani Nikula wrote:
> The wavedrom timeline will be missing from html pages served over https
> due to "mixed active content" blocking [1], because the wavedrom engine
> and skin are only available over http. Embed the engine and skin into
> the resulting html to avoid the prob
On Mon, Dec 14, 2015 at 09:59:17AM +, Derek Morton wrote:
> gem_flink_race and prime_self_import have subtests which read the
> number of open gem objects from debugfs to determine if objects have
> leaked during the test. However the test can fail sporadically if
> the number of gem objects ch
On Fri, Dec 11, 2015 at 11:33:00AM +, Chris Wilson wrote:
> This is principally a little bit of syntatic sugar to hide the
> atomic_read()s throughout the code to retrieve the current reset_counter.
> It also provides the other utility functions to check the reset state on the
> already read re
On Fri, Dec 11, 2015 at 11:33:01AM +, Chris Wilson wrote:
> If we, when we store the reset_counter for the operation, we ensure that
> it is not in a wedged or in the middle of a reset, we can then assert that
> if any reset occurs the reset_counter must change. Later we can just
> compare the
Hit send too early ;-)
On Fri, Dec 11, 2015 at 11:33:00AM +, Chris Wilson wrote:
> @@ -4133,7 +4133,7 @@ i915_gem_ring_throttle(struct drm_device *dev, struct
> drm_file *file)
>
> target = request;
> }
> - reset_counter = atomic_read(&dev_priv->gpu_error.reset_count
On Fri, Dec 11, 2015 at 11:33:02AM +, Chris Wilson wrote:
> In the reset_counter, we use two bits to track a GPU hang and reset. The
> low bit is a "reset-in-progress" flag that we set to signal when we need
> to break waiters in order for the recovery task to grab the mutex. As
> soon as the r
On Wed, Dec 16, 2015 at 10:33:32AM +0100, Daniel Vetter wrote:
> Hit send too early ;-)
>
> On Fri, Dec 11, 2015 at 11:33:00AM +, Chris Wilson wrote:
> > @@ -4133,7 +4133,7 @@ i915_gem_ring_throttle(struct drm_device *dev, struct
> > drm_file *file)
> >
> > target = request;
> >
On Tue, 15 Dec 2015, Ville Syrjälä wrote:
> On Mon, Dec 14, 2015 at 04:34:34PM +0200, Ville Syrjälä wrote:
>> On Mon, Dec 14, 2015 at 04:19:50PM +0200, Ville Syrjälä wrote:
>> > On Mon, Dec 14, 2015 at 12:50:55PM +0200, Jani Nikula wrote:
>> > Either I'm blind or you didn't actually add rvda/rvds
On Fri, Dec 11, 2015 at 11:33:03AM +, Chris Wilson wrote:
> As the request is only valid during the same global reset epoch, we can
> record the current reset_counter when constructing the request and reuse
> it when waiting upon that request in future. This removes a very hairy
> atomic check
On Fri, Dec 11, 2015 at 11:33:04AM +, Chris Wilson wrote:
> Now that the reset_counter is stored on the request, we can rearrange
> the code to handle reading the counter versus waiting during the atomic
> modesetting for readibility (by deleting the hairiest of codes).
>
> Signed-off-by: Chri
On Fri, Dec 11, 2015 at 11:33:05AM +, Chris Wilson wrote:
> Reporting -EIO from i915_wait_request() has proven very troublematic
> over the years, with numerous hard-to-reproduce bugs cropping up in the
> corner case of where a reset occurs and the code wasn't expecting such
> an error.
>
> If
On Fri, Dec 11, 2015 at 11:33:06AM +, Chris Wilson wrote:
> If we do not have lowlevel support for reseting the GPU, or if the user
> has explicitly disabled reseting the device, the failure is expected.
> Since it is an expected failure, we should be using a lower priority
> message than *ERRO
On Wed, Dec 16, 2015 at 09:54:47AM +0100, Daniel Vetter wrote:
> On Fri, Dec 11, 2015 at 10:18:35PM +, Chris Wilson wrote:
> > igt likes to inject GPU hangs into its command streams. However, as we
> > expect these hangs, we don't actually want them recorded in the dmesg
> > output or stored in
On Wed, Dec 16, 2015 at 10:53:16AM +0100, Daniel Vetter wrote:
> On Fri, Dec 11, 2015 at 11:33:06AM +, Chris Wilson wrote:
> > If we do not have lowlevel support for reseting the GPU, or if the user
> > has explicitly disabled reseting the device, the failure is expected.
> > Since it is an exp
On Wed, Dec 16, 2015 at 10:00:44AM +, Chris Wilson wrote:
> On Wed, Dec 16, 2015 at 09:54:47AM +0100, Daniel Vetter wrote:
> > On Fri, Dec 11, 2015 at 10:18:35PM +, Chris Wilson wrote:
> > > igt likes to inject GPU hangs into its command streams. However, as we
> > > expect these hangs, we
Op 15-12-15 om 11:22 schreef Mika Kahola:
> On Tue, 2015-11-24 at 11:29 +0100, Maarten Lankhorst wrote:
>> Parallel modesets are still not allowed, but this will allow updating
>> a different crtc during a modeset if the clock is not changed.
>>
>> Additionally when all pipes are DPMS off the cdclk
On Mon, Dec 14, 2015 at 02:03:33PM +, Chris Wilson wrote:
> Our driver compiles clean (nowadays thanks to 0day) but for me, at least,
> it would be beneficial if the compiler threw an error rather than a
> warning when it found a piece of suspect code. (I use this to
> compile-check patch serie
On Wed, Dec 16, 2015 at 10:44:19AM +0100, Daniel Vetter wrote:
> On Fri, Dec 11, 2015 at 11:33:03AM +, Chris Wilson wrote:
> > As the request is only valid during the same global reset epoch, we can
> > record the current reset_counter when constructing the request and reuse
> > it when waiting
On Mon, Dec 14, 2015 at 06:23:42PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> The crc code assumes that the printed frame counter value takes
> exactly 8 characters. The counter is a 32bit value, so to fit
> it into 8 characters we need to print it in hex, in decimal it
On Mon, Dec 14, 2015 at 06:23:43PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> We use the vblank timestamps to generate the vblank frame counter value
> on gen2. That means we need the pipe scanout position to be accurate
> when we call drm_crtc_vblank_on(), otherwise th
On Wed, Dec 16, 2015 at 10:33:32AM +0100, Daniel Vetter wrote:
> Hit send too early ;-)
>
> On Fri, Dec 11, 2015 at 11:33:00AM +, Chris Wilson wrote:
> > @@ -4133,7 +4133,7 @@ i915_gem_ring_throttle(struct drm_device *dev, struct
> > drm_file *file)
> >
> > target = request;
> >
On Mon, Dec 14, 2015 at 06:23:44PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Gen2 doesn't have a hardware frame counter, so let's use the sw
> counter value instead.
>
> Testcase: igt/kms_pipe_crc_basic/read-crc-pipe-?-frame-sequence
> Signed-off-by: Ville Syrjälä
I
On Mon, Dec 14, 2015 at 06:23:45PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Since
> commit 4dfd648 ("drm: Use vblank timestamps to guesstimate how many vblanks
> were missed")
> the vblank code can cook up a frame counter value based on
> the vblank timestamps (as lo
On Mon, Dec 14, 2015 at 06:23:48PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> We use MI_BATCH_BUFFER on 830/845, which means we need to know
> the batch length. If the user passes a bad batch length (< 8)
> the results is most likely a GPU hang. Rejct such batches.
>
>
On Wed, Dec 16, 2015 at 10:02:27AM +0100, Daniel Vetter wrote:
> On Sat, Dec 12, 2015 at 08:02:49PM +, Chris Wilson wrote:
> > Wean drv_hangman off the atrocious stop_rings and use a real GPU hang
> > instead.
> >
> > Signed-off-by: Chris Wilson
>
> Doesn't this kill pre-gen6? Or at least an
On Wed, Dec 16, 2015 at 11:31:31AM +0100, Daniel Vetter wrote:
> On Mon, Dec 14, 2015 at 06:23:45PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Since
> > commit 4dfd648 ("drm: Use vblank timestamps to guesstimate how many vblanks
> > were missed")
> > the vblank c
On 12/16/2015 03:46 AM, abhay.ku...@intel.com wrote:
From: Abhay Kumar
Make resume codepath not to wait for panel_power_cycle_delay(t11_t12)
if this time is already spent in suspend/poweron time.
Signed-off-by: Abhay Kumar
---
drivers/gpu/drm/i915/intel_ddi.c | 3 +++
drivers/gpu/drm/i915
On Tue, Dec 15, 2015 at 01:36:07PM +0200, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > On Mon, Dec 14, 2015 at 07:14:23PM +0200, Mika Kuoppala wrote:
> >> When we drop caches, this debugfs entry does hardware access later in
> >> the chain, when fences are updated, so it needs a runtime pm r
On Wed, Dec 16, 2015 at 11:36:31AM +0100, Daniel Vetter wrote:
> On Mon, Dec 14, 2015 at 06:23:48PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > We use MI_BATCH_BUFFER on 830/845, which means we need to know
> > the batch length. If the user passes a bad batch lengt
Hi,
On ti, 2015-12-15 at 20:10 +0200, Imre Deak wrote:
> Signed-off-by: Imre Deak
Reviewed-by: Joonas Lahtinen
> ---
> drivers/gpu/drm/i915/intel_runtime_pm.c | 15 +--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> b
On Tue, Dec 15, 2015 at 12:30:54PM +, Chris Wilson wrote:
> On Tue, Dec 15, 2015 at 02:01:24PM +0200, Ville Syrjälä wrote:
> > On Tue, Dec 15, 2015 at 01:29:59PM +0200, Ville Syrjälä wrote:
> > > On Tue, Dec 15, 2015 at 11:16:52AM +, Chris Wilson wrote:
> > > > On Tue, Dec 15, 2015 at 12:57
Use the for_each_intel_* macros for iterating intel_encoder,
intel_connector, and intel_crtc. No functional changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.c | 11 ---
drivers/gpu/drm/i915/intel_display.c | 10 +++---
drivers/gpu/drm/i915/intel_dp.c
On Mon, Dec 14, 2015 at 10:15:55PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> During suspend tests we can exceed the current 100 frame difference
> in sequence numbers. Bump the limit to 150 frames.
>
> Signed-off-by: Ville Syrjälä
I'd bump a lot more tbh, or maybe c
On Wed, Dec 16, 2015 at 10:43:54AM +, Chris Wilson wrote:
> On Wed, Dec 16, 2015 at 11:36:31AM +0100, Daniel Vetter wrote:
> > On Mon, Dec 14, 2015 at 06:23:48PM +0200, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > We use MI_BATCH_BUFFER on 830/845, which mea
On Sun, Dec 06, 2015 at 09:33:20PM +0100, Lukas Wunner wrote:
> Hi Chris,
>
> On Fri, Dec 04, 2015 at 04:05:26PM +, Chris Wilson wrote:
> > A long time ago (before 3.14) we relied on a permanent pinning of the
> > ifbdev to lock the fb in place inside the GGTT. However, the
> > introduction of
On ti, 2015-12-15 at 20:10 +0200, Imre Deak wrote:
> We can make the RPM dependency on RC6 explciit in the code by taking
> an
> actual RPM reference, instead of avoiding to drop the initial one.
> This
> will also enable us to remove the HAS_RUNTIME_PM special casing from
> more places in the next
On Tue, Dec 15, 2015 at 02:16:38PM -0800, abhay.ku...@intel.com wrote:
> From: Abhay Kumar
>
> Make resume codepath not to wait for panel_power_cycle_delay(t11_t12)
> if this time is already spent in suspend/poweron time.
>
> Signed-off-by: Abhay Kumar
> ---
> drivers/gpu/drm/i915/intel_ddi.c
On ti, 2015-12-15 at 20:10 +0200, Imre Deak wrote:
> We don't really need to check this flag in the get/put/assert
> helpers,
> as on platforms without RPM support we won't ever enable RPM. That
> means
> pm.suspend will be always false and the assert will be always true.
>
> Do this to simplify t
On Tue, Dec 15, 2015 at 05:33:33PM +0200, Jani Nikula wrote:
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/intel_bios.c | 38 ++
> drivers/gpu/drm/i915/intel_tv.c | 43
> +---
On ti, 2015-12-15 at 20:10 +0200, Imre Deak wrote:
> v2-v3:
> - unchanged
> v4:
> - keep the corresponding check in the get helper (Chris)
This is put helper you patched, so I think the above message is
incorrect.
Regards, Joonas
>
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel
Call the encoders, call the hot_plug if it is registered.
This is required for connected boot and resume cases to generate
fake hpd resulting in reading of edid.
Removing the initial sdvo hot_plug call too so that it will be called
just once from this loop.
v2: Schedule a work function to call hot
From: Shashank Sharma
This patch adds a separate probe function for HDMI
EDID read over DDC channel. This function has been
registered as a .hot_plug handler for HDMI encoder.
The current implementation of hdmi_detect()
function re-sets the cached HDMI edid (in connector->detect_edid) in
every d
On ke, 2015-12-16 at 12:54 +0200, Joonas Lahtinen wrote:
> On ti, 2015-12-15 at 20:10 +0200, Imre Deak wrote:
> > We can make the RPM dependency on RC6 explciit in the code by
Typo, s/explciit/explicit/
> > taking
> > an
> > actual RPM reference, instead of avoiding to drop the initial one.
> >
On Tue, Dec 15, 2015 at 05:33:38PM +0200, Jani Nikula wrote:
> We've been accumulating code across the driver that depends on the VBT
> specific structures and defines. The VBT is an uncontrollable
> beast. Encourage encapsulation of the VBT data by hiding the structures
> and defines in a private
On ke, 2015-12-16 at 11:42 +0100, Daniel Vetter wrote:
> On Tue, Dec 15, 2015 at 01:36:07PM +0200, Mika Kuoppala wrote:
> > Chris Wilson writes:
> >
> > > On Mon, Dec 14, 2015 at 07:14:23PM +0200, Mika Kuoppala wrote:
> > > > When we drop caches, this debugfs entry does hardware access
> > > > la
On Wed, Dec 16, 2015 at 10:52:06AM +0100, Daniel Vetter wrote:
> On Fri, Dec 11, 2015 at 11:33:05AM +, Chris Wilson wrote:
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index d7bbd015de35..875bdf814d73 100644
> > --- a/drivers/gpu/drm/i915
On ti, 2015-12-15 at 20:10 +0200, Imre Deak wrote:
> In some cases we want to check whether we hold an RPM wakelock
> reference
> for the whole duration of a sequence. To achieve this add a new RPM
> atomic sequence
> counter that we increment any time the wakelock refcount drops to
> zero.
> Check
On Wed, Dec 16, 2015 at 11:23:54AM +0100, Daniel Vetter wrote:
> On Mon, Dec 14, 2015 at 06:23:42PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > The crc code assumes that the printed frame counter value takes
> > exactly 8 characters. The counter is a 32bit value, s
On Wed, Dec 16, 2015 at 01:00:38PM +0200, Joonas Lahtinen wrote:
> On ti, 2015-12-15 at 20:10 +0200, Imre Deak wrote:
> > v2-v3:
> > - unchanged
> > v4:
> > - keep the corresponding check in the get helper (Chris)
>
> This is put helper you patched, so I think the above message is
> incorrect.
It
On Wed, Dec 16, 2015 at 12:58:33PM +0200, Ville Syrjälä wrote:
> On Wed, Dec 16, 2015 at 11:23:54AM +0100, Daniel Vetter wrote:
> > On Mon, Dec 14, 2015 at 06:23:42PM +0200, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > The crc code assumes that the printed frame
On Wed, Dec 16, 2015 at 11:46:50AM +0100, Daniel Vetter wrote:
> On Tue, Dec 15, 2015 at 12:30:54PM +, Chris Wilson wrote:
> > On Tue, Dec 15, 2015 at 02:01:24PM +0200, Ville Syrjälä wrote:
> > > On Tue, Dec 15, 2015 at 01:29:59PM +0200, Ville Syrjälä wrote:
> > > > On Tue, Dec 15, 2015 at 11:1
On Tue, Dec 15, 2015 at 10:57:31PM +0200, Ville Syrjälä wrote:
> On Tue, Dec 15, 2015 at 08:10:30PM +0200, Imre Deak wrote:
> > All platforms with power well support have runtime PM support, so
> > simplify things by explicitly disabling power well support on platforms
> > without runtime PM suppor
On Tue, Dec 15, 2015 at 08:10:37PM +0200, Imre Deak wrote:
> In some cases we want to check whether we hold an RPM wakelock reference
> for the whole duration of a sequence. To achieve this add a new RPM atomic
> sequence
> counter that we increment any time the wakelock refcount drops to zero.
>
On Wed, Dec 16, 2015 at 12:48:16PM +0200, Jani Nikula wrote:
> Use the for_each_intel_* macros for iterating intel_encoder,
> intel_connector, and intel_crtc. No functional changes.
>
> Signed-off-by: Jani Nikula
Trusting that gcc will scream at you if you fumbled types:
Reviewed-by: Daniel Vet
These patches add support for Backlight Control using DPCD registers
on eDP displays.
Yetunde Adebisi (2):
drm/dp: Add definition for Display Control DPCD Registers capability
size
drm/i915: Add Backlight Control using DPCD for eDP connectors (v4)
drivers/gpu/drm/i915/Makefile
This patch adds support for eDP backlight control using DPCD registers to
backlight hooks in intel_panel.
It checks for backlight control over AUX channel capability and sets up
function pointers to get and set the backlight brightness level if
supported.
v2: Moved backlight functions from intel_
This is used when reading Display Control capability Registers on the sink
device.
cc: Jani Nikula
Signed-off-by: Yetunde Adebisi
---
include/drm/drm_dp_helper.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 1252108..92d9a52
On Tue, Dec 15, 2015 at 08:10:33PM +0200, Imre Deak wrote:
> As a preparation for follow-up patches add a new helper that checks
> whether we hold an RPM reference, since this is what we want most of
> the cases. Atm this helper will only check for the HW suspended state, a
> follow-up patch will d
Disable DP fast link training if DP link configuration
changes. If one of the DP link parameters i.e. link
bandwidth, lane count, rate selection, port clock or bpp
changes the link training does no longer apply the
previously computed voltage swing and pre-emphasis values.
Instead, the link trainin
Our driver compiles clean (nowadays thanks to 0day) but for me, at least,
it would be beneficial if the compiler threw an error rather than a
warning when it found a piece of suspect code. (I use this to
compile-check patch series and want to break on the first compiler error
in order to fix the pa
On Tue, Dec 15, 2015 at 05:50:36PM +, Dave Gordon wrote:
> On 15/12/15 14:54, Chris Wilson wrote:
> >On Tue, Dec 15, 2015 at 02:41:47PM +, Dave Gordon wrote:
> >>On 14/12/15 05:46, ankitprasad.r.sha...@intel.com wrote:
> >>>From: Ankitprasad Sharma
> >>>
> >>>Using stolen backed objects as
On Wed, 16 Dec 2015, Daniel Vetter wrote:
> On Wed, Dec 16, 2015 at 12:48:16PM +0200, Jani Nikula wrote:
>> Use the for_each_intel_* macros for iterating intel_encoder,
>> intel_connector, and intel_crtc. No functional changes.
>>
>> Signed-off-by: Jani Nikula
>
> Trusting that gcc will scream a
On Wed, Dec 16, 2015 at 02:26:58PM +0200, Mika Kahola wrote:
> Disable DP fast link training if DP link configuration
> changes. If one of the DP link parameters i.e. link
> bandwidth, lane count, rate selection, port clock or bpp
> changes the link training does no longer apply the
> previously co
On Tue, 2015-12-15 at 10:26 +, Chris Wilson wrote:
> On Tue, Dec 15, 2015 at 12:22:40PM +0200, Mika Kahola wrote:
> > On Tue, 2015-11-24 at 11:29 +0100, Maarten Lankhorst wrote:
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index 3c4
On ke, 2015-12-16 at 11:07 +, Chris Wilson wrote:
> On Wed, Dec 16, 2015 at 01:00:38PM +0200, Joonas Lahtinen wrote:
> > On ti, 2015-12-15 at 20:10 +0200, Imre Deak wrote:
> > > v2-v3:
> > > - unchanged
> > > v4:
> > > - keep the corresponding check in the get helper (Chris)
> >
> > This is pu
On Wed, Dec 16, 2015 at 11:30:19AM +0100, Daniel Vetter wrote:
> On Mon, Dec 14, 2015 at 06:23:44PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Gen2 doesn't have a hardware frame counter, so let's use the sw
> > counter value instead.
> >
> > Testcase: igt/kms_pip
On Wed, Dec 16, 2015 at 11:06:20AM +, Chris Wilson wrote:
> On Wed, Dec 16, 2015 at 10:52:06AM +0100, Daniel Vetter wrote:
> > On Fri, Dec 11, 2015 at 11:33:05AM +, Chris Wilson wrote:
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > b/drivers/gpu/drm/i915/intel_display.c
> >
On ke, 2015-12-16 at 12:11 +, Chris Wilson wrote:
> On Tue, Dec 15, 2015 at 08:10:33PM +0200, Imre Deak wrote:
> > As a preparation for follow-up patches add a new helper that checks
> > whether we hold an RPM reference, since this is what we want most
> > of
> > the cases. Atm this helper will
On Wed, Dec 16, 2015 at 02:54:43PM +0200, Imre Deak wrote:
> On ke, 2015-12-16 at 12:11 +, Chris Wilson wrote:
> > On Tue, Dec 15, 2015 at 08:10:33PM +0200, Imre Deak wrote:
> > > +static inline void
> > > +assert_rpm_device_not_suspended(struct drm_i915_private *dev_priv)
> > > +{
> > > + WARN
On Wed, 2015-12-16 at 14:41 +0200, Ville Syrjälä wrote:
> On Wed, Dec 16, 2015 at 02:26:58PM +0200, Mika Kahola wrote:
> > Disable DP fast link training if DP link configuration
> > changes. If one of the DP link parameters i.e. link
> > bandwidth, lane count, rate selection, port clock or bpp
> >
Specify the maximum number of letters to print from the potentially
unterminated buffer, not the minimum. While at it, use sizeof instead of
a magic number.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_bios.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/dr
dev_priv is the new black. Or something.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_dma.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_bios.c | 22 +-
3 files changed, 11 insertions(+), 15 deletions(-)
diff --git a/drivers/gp
The intel_bios.h header doesn't even need it, but other headers included
from i915_drv.h do. Let's untangle the mess a bit.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_bios.h | 2 --
2 files changed, 1 insertion(+), 2 deletions(-)
diff --gi
Slightly cleaner with early exit.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_bios.c | 39 ---
1 file changed, 20 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 25edfc062f
On Wed, Dec 16, 2015 at 10:37:55AM +, Chris Wilson wrote:
> On Wed, Dec 16, 2015 at 10:02:27AM +0100, Daniel Vetter wrote:
> > On Sat, Dec 12, 2015 at 08:02:49PM +, Chris Wilson wrote:
> > > Wean drv_hangman off the atrocious stop_rings and use a real GPU hang
> > > instead.
> > >
> > > Si
On ke, 2015-12-16 at 12:12 +0100, Daniel Vetter wrote:
> On Tue, Dec 15, 2015 at 10:57:31PM +0200, Ville Syrjälä wrote:
> > On Tue, Dec 15, 2015 at 08:10:30PM +0200, Imre Deak wrote:
> > > All platforms with power well support have runtime PM support, so
> > > simplify things by explicitly disablin
On ke, 2015-12-16 at 13:02 +, Chris Wilson wrote:
> On Wed, Dec 16, 2015 at 02:54:43PM +0200, Imre Deak wrote:
> > On ke, 2015-12-16 at 12:11 +, Chris Wilson wrote:
> > > On Tue, Dec 15, 2015 at 08:10:33PM +0200, Imre Deak wrote:
> > > > +static inline void
> > > > +assert_rpm_device_not_su
On ke, 2015-12-16 at 15:39 +0200, Joonas Lahtinen wrote:
> On ke, 2015-12-16 at 13:02 +, Chris Wilson wrote:
> > On Wed, Dec 16, 2015 at 02:54:43PM +0200, Imre Deak wrote:
> > > On ke, 2015-12-16 at 12:11 +, Chris Wilson wrote:
> > > > On Tue, Dec 15, 2015 at 08:10:33PM +0200, Imre Deak wro
On Wed, Dec 16, 2015 at 04:18:05PM +0530, Sonika Jindal wrote:
> Call the encoders, call the hot_plug if it is registered.
> This is required for connected boot and resume cases to generate
> fake hpd resulting in reading of edid.
> Removing the initial sdvo hot_plug call too so that it will be cal
On Thu, Nov 26, 2015 at 12:34:34PM +0100, Daniel Vetter wrote:
> So there's 3 competing proposals for what wait_ioctl should do wrt
> -EIO:
>
> - return -EIO when the gpu is wedged. Not terribly useful for
> userspace since it might race with a hang and then there's no
> guarantee that a subse
Currently we get a permanent RPM reference if the platform doesn't
support RPM, but this is implicit via the dependency of the power well
functionality on RPM the RPM support, see
sanitize_disable_power_well_option(). Make things more explicit by
taking an RPM reference only for the purpose of keep
On Wed, Dec 16, 2015 at 03:04:47PM +0200, Mika Kahola wrote:
> On Wed, 2015-12-16 at 14:41 +0200, Ville Syrjälä wrote:
> > On Wed, Dec 16, 2015 at 02:26:58PM +0200, Mika Kahola wrote:
> > > Disable DP fast link training if DP link configuration
> > > changes. If one of the DP link parameters i.e. l
On Wed, Dec 16, 2015 at 03:12:57PM +0200, Ville Syrjälä wrote:
> On Wed, Dec 16, 2015 at 10:37:55AM +, Chris Wilson wrote:
> > On Wed, Dec 16, 2015 at 10:02:27AM +0100, Daniel Vetter wrote:
> > > On Sat, Dec 12, 2015 at 08:02:49PM +, Chris Wilson wrote:
> > > > Wean drv_hangman off the atro
Currently we get a permanent RPM reference if the platform doesn't
support RPM, but this is implicit via the dependency of the power well
functionality on RPM the RPM support, see
sanitize_disable_power_well_option(). Make things more explicit by
taking an RPM reference only for the purpose of keep
On Wed, Dec 16, 2015 at 02:49:51PM +0100, Daniel Vetter wrote:
> On Wed, Dec 16, 2015 at 03:04:47PM +0200, Mika Kahola wrote:
> > On Wed, 2015-12-16 at 14:41 +0200, Ville Syrjälä wrote:
> > > On Wed, Dec 16, 2015 at 02:26:58PM +0200, Mika Kahola wrote:
> > > > Disable DP fast link training if DP li
On Wed, Dec 16, 2015 at 01:51:46PM +, Chris Wilson wrote:
> On Wed, Dec 16, 2015 at 03:12:57PM +0200, Ville Syrjälä wrote:
> > On Wed, Dec 16, 2015 at 10:37:55AM +, Chris Wilson wrote:
> > > On Wed, Dec 16, 2015 at 10:02:27AM +0100, Daniel Vetter wrote:
> > > > On Sat, Dec 12, 2015 at 08:02
On Wed, Dec 16, 2015 at 03:04:18PM +0200, Jani Nikula wrote:
> The intel_bios.h header doesn't even need it, but other headers included
> from i915_drv.h do. Let's untangle the mess a bit.
>
> Signed-off-by: Jani Nikula
Since we dereference struct drm_device inside i915_drv.h, we need this,
and
On Wed, Dec 16, 2015 at 03:04:19PM +0200, Jani Nikula wrote:
> Specify the maximum number of letters to print from the potentially
> unterminated buffer, not the minimum. While at it, use sizeof instead of
> a magic number.
>
> Signed-off-by: Jani Nikula
Wow that's a widely underused feature, on
On Wed, Dec 16, 2015 at 03:04:20PM +0200, Jani Nikula wrote:
> dev_priv is the new black. Or something.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
In
On Wed, Dec 16, 2015 at 03:04:21PM +0200, Jani Nikula wrote:
> Slightly cleaner with early exit.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx
On Wed, Dec 16, 2015 at 02:51:20PM +0200, Ville Syrjälä wrote:
> On Wed, Dec 16, 2015 at 11:30:19AM +0100, Daniel Vetter wrote:
> > On Mon, Dec 14, 2015 at 06:23:44PM +0200, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > Gen2 doesn't have a hardware frame counter,
I gave a try to this patch on Braswell.
A couple of comments below.
On 03/12/15 11:36, Shashank Sharma wrote:
CHV/BSW supports Degamma color correction, which linearizes all
the non-linear color values. This will be applied before Color
Transformation.
This patch does the following:
1. Attach d
On Wed, 16 Dec 2015, Chris Wilson wrote:
> On Wed, Dec 16, 2015 at 03:04:19PM +0200, Jani Nikula wrote:
>> Specify the maximum number of letters to print from the potentially
>> unterminated buffer, not the minimum. While at it, use sizeof instead of
>> a magic number.
>>
>> Signed-off-by: Jani N
From: Ville Syrjälä
I broke AVI/HDMI/SPD infoframes on HSW+ with the register type
safety changes. We were supposed to check that the infoframe data
register is valid before writing the infoframe data, but the check
ended up inverted, and so in practice we never wrote or enabled
these infoframes.
1 - 100 of 145 matches
Mail list logo
