On Thu, 17 Aug 2017, Rodrigo Vivi wrote:
> So far we could use *dim* to apply a whole series
> in a mbox, but only the very last patch was receiving
> all the checks and patchwork link.
>
> So this patch remove this limitation by using git mailsplit
> to split the mbox and than use git am and chec
There are some potential integer overflows here on 64 bit systems.
The condition "if (nfences > SIZE_MAX / sizeof(*fences))" can only be
true on 32 bit systems, it's a no-op on 64 bit, so let's ignore the
check for now and look a couple lines after:
if (!access_ok(VERIFY_READ, user, nfenc
On Thu, 17 Aug 2017, Rodrigo Vivi wrote:
> On Thu, Aug 17, 2017 at 10:33 AM, Jani Nikula wrote:
>> On Thu, 17 Aug 2017, Rodrigo Vivi wrote:
>>> On my own workflow I was missing a way to download mboxes
>>> directly from patchwork with the patchwork id. So my first
>>> reflex was to modify dim to
Waitboost and reset test cases were failing because maximum
frequency is not always boost frequency (sometimes overcloking
occurs).
Moreover more time is needed for boost to be finished.
Changed boost_freq function so boost occurred on the same engine
as low load.
Added function waiting for boost t
== Series Details ==
Series: drm/i915: Fix integer overflow tests (rev4)
URL : https://patchwork.freedesktop.org/series/28898/
State : success
== Summary ==
Series 28898v4 drm/i915: Fix integer overflow tests
https://patchwork.freedesktop.org/api/1.0/series/28898/revisions/4/mbox/
fi-bdw-5557
Quoting Dan Carpenter (2017-08-18 08:07:00)
> There are some potential integer overflows here on 64 bit systems.
>
> The condition "if (nfences > SIZE_MAX / sizeof(*fences))" can only be
> true on 32 bit systems, it's a no-op on 64 bit, so let's ignore the
> check for now and look a couple lines a
On Thu, Aug 17, 2017 at 07:53:45AM -0700, Kelvin Gardiner wrote:
> On 17/08/17 00:50, Daniel Vetter wrote:
> > On Wed, Aug 16, 2017 at 05:30:08PM -0700, Kelvin Gardiner wrote:
> > >
> > >
> > > On 16/08/17 07:04, Daniel Vetter wrote:
> > > > On Wed, Aug 16, 2017 at 11:33 AM, Petri Latvala
> > >
Quoting Chris Wilson (2017-08-17 13:37:06)
> If we miss the current vblank because the gpu was busy, that may cause a
> jitter as the frame rate temporarily drops. We try to limit the impact
> of this by then boosting the GPU clock to deliver the frame as quickly
> as possible. Originally done in c
== Series Details ==
Series: pm_rps: Changes in waitboost scenario
URL : https://patchwork.freedesktop.org/series/28966/
State : success
== Summary ==
IGT patchset tested on top of latest successful build
5a17ee2c8f9013f5db852d27564b837f9f2c5a9f tools/intel_vbt_decode: Fix decoding
of child d
On Tue, Aug 15, 2017 at 11:04:21AM -0700, Clint Taylor wrote:
>
>
> On 08/15/2017 12:58 AM, Daniel Vetter wrote:
> > On Mon, Aug 14, 2017 at 10:21:51AM -0700, Clint Taylor wrote:
> > >
> > > On 08/14/2017 07:40 AM, Daniel Vetter wrote:
> > > > On Thu, Aug 10, 2017 at 10:50:19AM -0700, clinton.a.
On Thu, 17 Aug 2017, Mika Kahola wrote:
> Tested with GLK + MIPI/DSI panel (AU Optronics B101UAN01)
>
> Tested-by: Mika Kahola
Do we have a bxt system available for testing this? With that,
Acked-by: Jani Nikula
BR,
Jani.
>
> On Thu, 2017-08-17 at 13:55 +0300, Andy Shevchenko wrote:
>> The
On Fri, Aug 18, 2017 at 08:46:25AM +0100, Chris Wilson wrote:
> Quoting Dan Carpenter (2017-08-18 08:07:00)
> > There are some potential integer overflows here on 64 bit systems.
> >
> > The condition "if (nfences > SIZE_MAX / sizeof(*fences))" can only be
> > true on 32 bit systems, it's a no-op
On Wed, Aug 16, 2017 at 03:26:43AM +, Zhang, Tina wrote:
>
>
> > -Original Message-
> > From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On
> > Behalf Of Chris Wilson
> > Sent: Tuesday, August 15, 2017 11:02 PM
> > To: Daniel Vetter
> > Cc: intel-gfx ; intel-g
On Thu, Aug 17, 2017 at 12:46:53PM -0700, Manasi Navare wrote:
> On Thu, Aug 17, 2017 at 07:01:05AM +, Rodrigo Vivi wrote:
> >On Wed, Aug 16, 2017 at 11:51 PM Manasi Navare
> ><[1]manasi.d.nav...@intel.com> wrote:
> >
> > In case of eDP because the panel has a fixed mode we cannot
Quoting Michel Thierry (2017-08-17 18:41:16)
> On 17/08/17 10:32, Chris Wilson wrote:
> > Forcewake is not affected by the engine reset on gen6+. Indeed the
> > reason why we added intel_uncore_forcewake_reset() to
> > gen6_reset_engines() was to keep the bookkeeping intact because the
> > reset di
On Thu, Aug 17, 2017 at 06:32:29PM +0100, Chris Wilson wrote:
> Forcewake is not affected by the engine reset on gen6+. Indeed the
> reason why we added intel_uncore_forcewake_reset() to
> gen6_reset_engines() was to keep the bookkeeping intact because the
> reset did not touch the forcewake bit (y
More visibility
Signed-off-by: Daniel Vetter
---
TODO => TODO.rst | 11 +--
index.rst| 1 +
2 files changed, 10 insertions(+), 2 deletions(-)
rename TODO => TODO.rst (97%)
diff --git a/TODO b/TODO.rst
similarity index 97%
rename from TODO
rename to TODO.rst
index 4a56e0eb414f.
Quoting Daniel Vetter (2017-08-18 09:12:12)
> On Thu, Aug 17, 2017 at 06:32:29PM +0100, Chris Wilson wrote:
> > Forcewake is not affected by the engine reset on gen6+. Indeed the
> > reason why we added intel_uncore_forcewake_reset() to
> > gen6_reset_engines() was to keep the bookkeeping intact be
Quoting Daniel Vetter (2017-08-18 09:12:12)
> On Thu, Aug 17, 2017 at 06:32:29PM +0100, Chris Wilson wrote:
> > Forcewake is not affected by the engine reset on gen6+. Indeed the
> > reason why we added intel_uncore_forcewake_reset() to
> > gen6_reset_engines() was to keep the bookkeeping intact be
On Fri, 2017-08-18 at 10:03 +0200, Daniel Vetter wrote:
> On Wed, Aug 16, 2017 at 03:26:43AM +, Zhang, Tina wrote:
> > > Quoting Daniel Vetter (2017-08-15 15:48:03)
> > > > On Tue, Aug 15, 2017 at 4:35 PM, Chris Wilson
> > > > - If we need that special errno, can we take something else?
On Fri, 2017-08-18 at 08:54 +0100, Chris Wilson wrote:
> Quoting Chris Wilson (2017-08-17 13:37:06)
> > If we miss the current vblank because the gpu was busy, that may cause a
> > jitter as the frame rate temporarily drops. We try to limit the impact
> > of this by then boosting the GPU clock to d
Michel Thierry writes:
> On 17/08/17 10:32, Chris Wilson wrote:
>> Forcewake is not affected by the engine reset on gen6+. Indeed the
>> reason why we added intel_uncore_forcewake_reset() to
>> gen6_reset_engines() was to keep the bookkeeping intact because the
>> reset did not touch the forcewak
On Thu, 17 Aug 2017, Stéphane Marchesin wrote:
> On Mon, Jun 19, 2017 at 11:45 AM, Jani Nikula
> wrote:
>>
>> On Thu, 15 Jun 2017, Imre Deak wrote:
>> > On Thu, Jun 15, 2017 at 10:20:57AM -0700, Rodrigo Vivi wrote:
>> >> I believe it is worth allowing RPM to work without requiring DMC, no?!
>> >
During a global reset, we disable the irq. As we disable the irq, the
hardware may be raising a GT interrupt that we then ignore, leaving it
pending in the GTIIR. After the reset, we then re-enable the irq,
triggering the pending interrupt. However, that interrupt was for the
stale state from befor
On Thu, 2017-08-17 at 15:47 +0100, Chris Wilson wrote:
> In a synchronous setup, we may retire the last request before we
> complete allocating the next request. As the last request is retired, we
> queue a timer to mark the device as idle, and promptly have to execute
> ad cancel that timer once w
Quoting Mika Kuoppala (2017-08-18 09:56:23)
> Michel Thierry writes:
>
> > On 17/08/17 10:32, Chris Wilson wrote:
> >> Forcewake is not affected by the engine reset on gen6+. Indeed the
> >> reason why we added intel_uncore_forcewake_reset() to
> >> gen6_reset_engines() was to keep the bookkeepin
We're not super-consistent about these, but I think it's worth to
document at least the commmon patterns.
Cc: Joonas Lahtinen
Cc: Chris Wilson
Cc: "Zhang, Tina"
Signed-off-by: Daniel Vetter
---
Documentation/gpu/drm-uapi.rst | 53 ++
1 file changed, 53
Emphasize that this is based on the port, not intel_dp. This is also in
line with the underlying intel_bios_is_port_edp() function. No
functional changes.
Cc: Manasi Navare
Cc: Jim Bride
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_display.c | 6 +++---
drivers/gpu/drm/i915/intel_
Expose across driver for future work. No functional changes.
Cc: Manasi Navare
Cc: Jim Bride
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 77 +---
drivers/gpu/drm/i915/intel_drv.h | 1 +
2 files changed, 41 insertions(+), 37 deletions(-
On Fri, 18 Aug 2017, Daniel Vetter wrote:
> More visibility
>
> Signed-off-by: Daniel Vetter
Ack.
I guess qf man page should be extracted from the script, and put here
too.
BR,
Jani.
> ---
> TODO => TODO.rst | 11 +--
> index.rst| 1 +
> 2 files changed, 10 insertions(+), 2
Quoting Chris Wilson (2017-08-17 13:37:06)
> If we miss the current vblank because the gpu was busy, that may cause a
> jitter as the frame rate temporarily drops. We try to limit the impact
> of this by then boosting the GPU clock to deliver the frame as quickly
> as possible. Originally done in c
On Tue, Aug 15, 2017 at 11:57:40PM +0100, Chris Wilson wrote:
> For the set of execbuf flags who by definition are based on whether or
> not the kernel supports that feature, the ultimate arbiter of whether or
> not the kernel accepts the flag is the kernel. The negative tests were
> second guessin
On Thu, Aug 17, 2017 at 07:05:56PM +0300, Paul Kocialkowski wrote:
> This introduces an ALSA library, with dedicated helpers for handling
> playback and capture. It handles ALSA device identification and
> configuration as well as a run loop with callback mechanisms for feeding
> output data and ha
Note: Alsa libraries are not installed in CI atm so this series wasn't
quite tested.
--
Petri Latvala
On Thu, Aug 17, 2017 at 04:24:21PM +, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [1/3] lib: Add audio library with dedicated
> helpers
> URL : https://pat
The RGB 64-bit 16:16:16:16 float pixel format is needed by some Apps in
windows. The float format in each component is 1:5:10 MSb-sign:exponent:
fraction.
This patch is to introduce the format to drm, so that the windows guest's
framebuffer in this kind of format can be recognized and used by linu
v13->v14:
1) add PROBE, DMABUF and REGION flags. (Alex)
2) return -ENXIO when gem proxy object is banned by ioctl.
(Chris) (Daniel)
3) add some details about the float pixel format. (Daniel)
4) add F suffix to the defined name. (Daniel)
5) refine pixel format table. (Zhenyu)
v12->v13:
1) add co
This patch is to introduce the framebuffer decoder which can decode guest
OS's framebuffer information, including primary, cursor and sprite plane.
v14:
- refine pixel format table. (Zhenyu)
v9:
- move drm format change to a separate patch. (Xiaoguang)
v8:
- fix a bug in decoding primary plane.
Windows guest driver needs vbt in opregion, to configure the setting
for display. Without opregion support, the display registers won't
be set and this blocks display model to get the correct information
of the guest display plane.
This patch is to provide a virtual opregion for guest. Current
imp
GEM proxy is a kind of GEM, whose backing physical memory is pinned
and produced by guest VM and is used by host as read only. With GEM
proxy, host is able to access guest physical memory through GEM object
interface. As GEM proxy is such a special kind of GEM, a new flag
I915_GEM_OBJECT_IS_PROXY i
This patch introduces a guest's framebuffer sharing mechanism based on
dma-buf subsystem. With this sharing mechanism, guest's framebuffer can
be shared between guest VM and host.
v14:
- add PROBE, DMABUF and REGION flags. (Alex)
v12:
- refine the lifecycle of dmabuf.
v9:
- remove dma-buf manage
The RGB 64-bit 16:16:16:16 float pixel format is needed by windows 10
guest VM. This patch is to add this pixel format support to gvt device
model. Without this patch, some Apps, e.g. "DXGIGammaVM.exe", will crash
and make guest screen black.
Signed-off-by: Tina Zhang
diff --git a/drivers/gpu/dr
Add VFIO_DEVICE_QUERY_GFX_PLANE ioctl command to let user mode query and
get the plan and its related information. This ioctl can be invoked with:
1) either flag DMABUF or REGION is set. Vendor driver returns success and
the plane_info only when the specific kind of buffer is supported.
2) flag PRO
On Mon, Aug 14, 2017 at 09:18:45PM +0100, Chris Wilson wrote:
> Pass the fd along to igt_enable_connectors() so that it actually dtrt
> when there are multiple drm devices in the system.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Arkadiusz Hiler
--
Cheers,
Arek
__
On Mon, Aug 14, 2017 at 09:18:25PM +0100, Chris Wilson wrote:
> is_mountpoint() asserts rather than report the error. Normally this
> isn't a problem, except for atypical selftests.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Arkadiusz Hiler
___
Intel
igt_require_gem() checks whether we can use the i915 fd for submitting
requests by detecting a wedged driver. It was intended to be used just
after opening DRIVER_INTEL for a gem test to provide an early skip if
the device was unusable. However, it is also used at the start of
library functions lik
Quoting Chris Wilson (2017-08-18 11:46:19)
> igt_require_gem() checks whether we can use the i915 fd for submitting
> requests by detecting a wedged driver. It was intended to be used just
> after opening DRIVER_INTEL for a gem test to provide an early skip if
> the device was unusable. However, it
Quoting Chris Wilson (2017-08-18 11:46:19)
> igt_require_gem() checks whether we can use the i915 fd for submitting
> requests by detecting a wedged driver. It was intended to be used just
> after opening DRIVER_INTEL for a gem test to provide an early skip if
> the device was unusable. However, it
CI is observing sporadical failures in pm_rps subtests.
There are a couple of reasons. One of them is the fact that
on gen6, gen7 and gen7.5, max frequency (as in the HW limit)
is not set to RP0, but the value obtaind from PCODE (which
may be different from RP0). Thus the test is operating under
wr
Chris Wilson writes:
> MI_STORE_DWORD_IMM just doesn't work on the video decode engine under
> Sandybridge, so refrain from using it. Then switch the selftests over to
> using the now common test prior to using MI_STORE_DWORD_IMM.
>
> Fixes: 7dd4f6729f92 ("drm/i915: Async GPU relocation processin
Quoting Mika Kuoppala (2017-08-18 12:07:20)
> Chris Wilson writes:
> > if (!eb->reloc_cache.vaddr &&
> > (DBG_FORCE_RELOC == FORCE_GPU_RELOC ||
> > - !reservation_object_test_signaled_rcu(vma->resv, true))) {
> > + !reservation_object_test_signaled_rcu(vma->resv,
Chris Wilson writes:
> Quoting Mika Kuoppala (2017-08-18 12:07:20)
>> Chris Wilson writes:
>> > if (!eb->reloc_cache.vaddr &&
>> > (DBG_FORCE_RELOC == FORCE_GPU_RELOC ||
>> > - !reservation_object_test_signaled_rcu(vma->resv, true))) {
>> > + !reservation_object
== Series Details ==
Series: drm/i915: Clear lost context-switch interrupts across reset (rev2)
URL : https://patchwork.freedesktop.org/series/28450/
State : success
== Summary ==
Series 28450v2 drm/i915: Clear lost context-switch interrupts across reset
https://patchwork.freedesktop.org/api/1
On Fri, 2017-08-18 at 18:21 +0800, Tina Zhang wrote:
> GEM proxy is a kind of GEM, whose backing physical memory is pinned
> and produced by guest VM and is used by host as read only. With GEM
> proxy, host is able to access guest physical memory through GEM object
> interface. As GEM proxy is such
Quoting Patchwork (2017-08-17 16:36:15)
> == Series Details ==
>
> Series: series starting with [1/7] drm/i915: Don't use MI_STORE_DWORD_IMM on
> Sandybridge/vcs (rev2)
> URL : https://patchwork.freedesktop.org/series/28859/
> State : success
>
> == Summary ==
>
> Series 28859v2 Series withou
On Thu, 2017-08-17 at 14:06 +0300, Mika Kahola wrote:
> Tested with GLK + MIPI/DSI panel (AU Optronics B101UAN01)
Tested also with APL + MIPI/DSI setup.
>
> Tested-by: Mika Kahola
>
> On Thu, 2017-08-17 at 13:55 +0300, Andy Shevchenko wrote:
> >
> > The commit 213e08ad60ba
> > ("drm/i915/b
On Fri, Aug 18, 2017 at 11:53:22AM +0100, Chris Wilson wrote:
> Quoting Chris Wilson (2017-08-18 11:46:19)
> > igt_require_gem() checks whether we can use the i915 fd for submitting
> > requests by detecting a wedged driver. It was intended to be used just
> > after opening DRIVER_INTEL for a gem t
== Series Details ==
Series: drm/doc: Document ioctl errno value patterns
URL : https://patchwork.freedesktop.org/series/28974/
State : success
== Summary ==
Series 28974v1 drm/doc: Document ioctl errno value patterns
https://patchwork.freedesktop.org/api/1.0/series/28974/revisions/1/mbox/
fi
Quoting Daniel Vetter (2017-08-18 10:21:24)
> We're not super-consistent about these, but I think it's worth to
> document at least the commmon patterns.
>
> Cc: Joonas Lahtinen
> Cc: Chris Wilson
> Cc: "Zhang, Tina"
> Signed-off-by: Daniel Vetter
One extra used outside of i915 is ENOSYS. Per
== Series Details ==
Series: series starting with [1/2] drm/i915/dp: rename intel_dp_is_edp to
intel_dp_is_port_edp
URL : https://patchwork.freedesktop.org/series/28976/
State : success
== Summary ==
Series 28976v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/2
== Series Details ==
Series: drm/i915/gvt: Dma-buf support for GVT-g
URL : https://patchwork.freedesktop.org/series/28980/
State : success
== Summary ==
Series 28980v1 drm/i915/gvt: Dma-buf support for GVT-g
https://patchwork.freedesktop.org/api/1.0/series/28980/revisions/1/mbox/
Test gem_exe
On Thu, Aug 17, 2017 at 03:58:19PM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Beef up the IPS vs. CRC workaround (rev3)
> URL : https://patchwork.freedesktop.org/series/17084/
> State : warning
>
> == Summary ==
>
> Series 17084v3 drm/i915: Beef up the IPS vs. CRC wor
On Fri, Aug 18, 2017 at 11:53:22AM +0100, Chris Wilson wrote:
> Quoting Chris Wilson (2017-08-18 11:46:19)
> > igt_require_gem() checks whether we can use the i915 fd for submitting
> > requests by detecting a wedged driver. It was intended to be used just
> > after opening DRIVER_INTEL for a gem t
Quoting Chris Wilson (2017-08-16 15:23:06)
> Prefer to defer activating our GEM shrinker until we have a few
> megabytes to free; or we have accumulated sufficient mempressure by
> deferring the reclaim to force a shrink. The intent is that because our
> objects may typically be large, we are too e
== Series Details ==
Series: lib: Avoid actually throttling from igt_require_gem()
URL : https://patchwork.freedesktop.org/series/28983/
State : failure
== Summary ==
IGT patchset build failed on latest successful build
5a17ee2c8f9013f5db852d27564b837f9f2c5a9f tools/intel_vbt_decode: Fix decod
On Fri, Aug 18, 2017 at 01:46:12PM +0200, Michal Wajdeczko wrote:
> On Fri, Aug 18, 2017 at 11:53:22AM +0100, Chris Wilson wrote:
> > Quoting Chris Wilson (2017-08-18 11:46:19)
> > > igt_require_gem() checks whether we can use the i915 fd for submitting
> > > requests by detecting a wedged driver.
On Fri, 18 Aug 2017, Mika Kahola wrote:
> On Thu, 2017-08-17 at 14:06 +0300, Mika Kahola wrote:
>> Tested with GLK + MIPI/DSI panel (AU Optronics B101UAN01)
> Tested also with APL + MIPI/DSI setup.
Pushed to drm-intel-next-queued, thanks for the patch and testing.
BR,
Jani.
>
>>
>> Tested-by:
== Series Details ==
Series: pm_rps: Changes in waitboost scenario (rev2)
URL : https://patchwork.freedesktop.org/series/28966/
State : success
== Summary ==
IGT patchset tested on top of latest successful build
5a17ee2c8f9013f5db852d27564b837f9f2c5a9f tools/intel_vbt_decode: Fix decoding
of
Quoting Katarzyna Dec (2017-08-18 08:33:11)
> Waitboost and reset test cases were failing because maximum
> frequency is not always boost frequency (sometimes overcloking
> occurs).
> Moreover more time is needed for boost to be finished.
> Changed boost_freq function so boost occurred on the same
Quoting Katarzyna Dec (2017-08-18 12:08:44)
> While I'm here let's also make sure that we're running as DRM
> master to catch the common case, where the test is being ran
> along with Xorg.
Semantic changes to the test though, that implies its needs to be master
to run.
If you want to impose the
Quoting Katarzyna Dec (2017-08-18 12:08:44)
> CI is observing sporadical failures in pm_rps subtests.
For reference a real bug report looks like:
https://bugs.freedesktop.org/show_bug.cgi?id=102199
which is very much a functional regression that we don't cover.
-Chris
_
From: Ville Syrjälä
Add defines for the secondary data packet (SDP) types from the spec.
These are the DP specific ones, and in addition HDMI infoframe types
(see enum hdmi_infoframe_type) are also valid SDP types.
v2: Add more SDP types
v3: Note the DP version that added each SDP type (Rodrigo)
From: Ville Syrjälä
A rebased reposting of the dig_port infoframe series.
Notable changes since last time:
* Dealt with the new intel_sdvo_connector_state
* Annotated the SDP types with the DP spec version information
* Fixed the kernel docs for the PSR enable/disable funcs
Ville Syrjälä (8):
From: Ville Syrjälä
Now that the infoframe hooks are part of the intel_dig_port, we can use
the normal .write_infoframe() hook to update the VSC SDP. We do need to
deal with the size difference between the VSC DIP and the others though.
Another minor snag is that the compiler will complain to us
From: Ville Syrjälä
DP ports will also want to utilize the video DIP for SDP transmission.
So let's move the vfuncs into the dig_port.
v2: Rebase due to DDI changes
Signed-off-by: Ville Syrjälä
Reviewed-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_ddi.c | 22 ++---
drivers/gpu
From: Ville Syrjälä
The enable/disable/etc. encoder hooks aren't supposed to alter the
state(s), so pass them as const. Unfortunately C lacks any kind of deep
const thingy, so this can't catch all abuses. But at least it acts as a
hint to the reader telling them not to mess about with the state(s
From: Ville Syrjälä
DP ports may want to use the video DIP for SDP transmission, so let's
initialize the vfuncs for DP encoders as well. The only exception is
port A eDP prior to HSW as that one doesn't have a video DIP instance.
Signed-off-by: Ville Syrjälä
Reviewed-by: Shashank Sharma
---
d
From: Ville Syrjälä
has_infoframe is what tells us whether infoframes should be enabled, so
let's pass that instead of has_hdmi_sink to .set_infoframes().
Reviewed-by: Rodrigo Vivi
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_ddi.c | 6 +++---
drivers/gpu/drm/i915/intel_hdmi.c
From: Ville Syrjälä
Disabling the video DIP when shutting the port down seems like a good
idea.
Bspec says:
"When disabling both the DIP port and DIP transmission,
first disable the port and then disable DIP."
and
"Restriction : GCP is only supported with HDMI when the bits per color is
not eq
From: Ville Syrjälä
The PSR enable/disable need to know things about the crtc state, so
plumb it through. This will become even more important when we start
to reuse the generic infoframe code for the VSC DIP programming as the
infoframe code wants the crtc state as well.
v2: Fix kernel docs
Re
Quoting Chris Wilson (2017-08-18 10:30:47)
> Quoting Chris Wilson (2017-08-17 13:37:06)
> > If we miss the current vblank because the gpu was busy, that may cause a
> > jitter as the frame rate temporarily drops. We try to limit the impact
> > of this by then boosting the GPU clock to deliver the f
During suspend we want to flush out all active contexts and their
rendering. To do so we queue a request from the kernel's context, once
we know that request is done, we know the GPU is completely idle. To
speed up that switch bump the GPU clocks.
Switching to the kernel context prior to idling is
== Series Details ==
Series: drm/i915: Make infoframe code available to (e)DP ports (rev3)
URL : https://patchwork.freedesktop.org/series/8183/
State : failure
== Summary ==
Series 8183v3 drm/i915: Make infoframe code available to (e)DP ports
https://patchwork.freedesktop.org/api/1.0/series/81
Hi,
On 18 August 2017 at 10:21, Daniel Vetter wrote:
> +Recommended IOCTL Return Values
> +===
> +
> +In theory a driver's IOCTL callback is only allowed to return very few error
> +codes. In practice it's good to abuse a few more. This section documents
> common
> +p
" Do we have a bug about this at bugs.freedesktop.org?" I did quick query on
fdo.bugzilla and did not find any matching item (afaik) from there (with
i915_feature = GPU *hang*|*DMC*) so I would claim that bug is not filed.
Stephane can correct my wrong sayings here.
BR, Jari
-Original Mes
== Series Details ==
Series: drm/i915: "Race-to-idle" on switching to the kernel context
URL : https://patchwork.freedesktop.org/series/28998/
State : success
== Summary ==
Series 28998v1 drm/i915: "Race-to-idle" on switching to the kernel context
https://patchwork.freedesktop.org/api/1.0/seri
Quoting Tahvanainen, Jari (2017-08-18 15:26:03)
> " Do we have a bug about this at bugs.freedesktop.org?" I did quick query on
> fdo.bugzilla and did not find any matching item (afaik) from there (with
> i915_feature = GPU *hang*|*DMC*) so I would claim that bug is not filed.
> Stephane can corr
Hi Dave,
Here's the latest and greatest from drm-misc-fixes. We have a couple nice
cleanups from Maarten centered around properly handling errors (and specifically
EDEADLK) in atomic_check.
I probably would have liked Mark's DRM_ERROR patch to go through -misc-next, but
hopefully it's harmless eno
Nice job! Only one small formatting change
On Thu, 2017-08-17 at 19:05 +0300, Paul Kocialkowski wrote:
> This introduces a new test for audio going through display
> connectors.
> It currently contains a single subtest for HDMI signal integrity, but
> other test cases will be added later on.
>
>
One more small formatting change
On Thu, 2017-08-17 at 19:05 +0300, Paul Kocialkowski wrote:
> This introduces an audio library, with dedicated helpers for both
> generating signals and detecting peak frequencies in a signal.
>
> This library paves the way for testing audio going through display
And two more small changes
On Thu, 2017-08-17 at 19:05 +0300, Paul Kocialkowski wrote:
> This introduces an ALSA library, with dedicated helpers for handling
> playback and capture. It handles ALSA device identification and
> configuration as well as a run loop with callback mechanisms for
> feedi
On 18/08/17 02:05, Chris Wilson wrote:
During a global reset, we disable the irq. As we disable the irq, the
hardware may be raising a GT interrupt that we then ignore, leaving it
pending in the GTIIR. After the reset, we then re-enable the irq,
triggering the pending interrupt. However, that int
On Fri, Aug 18, 2017 at 12:30:19PM +0300, Jani Nikula wrote:
> Emphasize that this is based on the port, not intel_dp. This is also in
> line with the underlying intel_bios_is_port_edp() function. No
> functional changes.
Reviewed-by: Jim Bride
> Cc: Manasi Navare
> Cc: Jim Bride
> Signed-off-
On Thu, Aug 17, 2017 at 08:03:04PM -0700, Manasi Navare wrote:
> In the channel EQ retry loop, we break from the loop in case
> of failure to get link status or failure in clock recovery or
> failure to update link training. In these cases channel_eq_status
> is still false even though the retry lo
On Fri, Aug 18, 2017 at 12:30:20PM +0300, Jani Nikula wrote:
> Expose across driver for future work. No functional changes.
Reviewed-by: Jim Bride
> Cc: Manasi Navare
> Cc: Jim Bride
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_dp.c | 77
> +--
2017-08-14 Maarten Lankhorst :
> complete_crtc_signaling is freeing fence_state, but when retrying
> num_fences and fence_state are not zero'd. This caused duplicate
> fd's in the fence_state array, followed by a BUG_ON in fs/file.c
> because we reallocate freed memory, and installing over an exis
Hi Dave,
Here's the last of -misc-next for 4.14, we'll switch over to drm-misc-next-fixes
now and drm-misc-next will target 4.15. I'll send a PSA to misc committers once
the branches are set up.
Since we just send a pull a few days ago, there's not much here, and the tl;dr
is Noralf. We have the e
The corruption in CSB mmio reads we were seeing has been tracked down to
incorrectly touching forcewake of all domains, following an engine reset.
It is still a mistery why we only catched this in Broxton, since it
could happen in any platform.
With that fix already merged, commit 4055dc75d6b5 ("d
== Series Details ==
Series: drm/i915: Make infoframe code available to (e)DP ports (rev3)
URL : https://patchwork.freedesktop.org/series/8183/
State : failure
== Summary ==
Series 8183v3 drm/i915: Make infoframe code available to (e)DP ports
https://patchwork.freedesktop.org/api/1.0/series/81
We're not super-consistent about these, but I think it's worth to
document at least the commmon patterns.
v2:
- Add a not about ENOTTY (it's just a confusing name, but used
exactly what it's meant for in DRM) (Chris).
- Unconfuse the text for ENODEV (Daniel)
- Move text undert the IOCTL heading (C
== Series Details ==
Series: drm/i915: Re-enable per-engine reset for Broxton
URL : https://patchwork.freedesktop.org/series/29011/
State : success
== Summary ==
Series 29011v1 drm/i915: Re-enable per-engine reset for Broxton
https://patchwork.freedesktop.org/api/1.0/series/29011/revisions/1/m
1 - 100 of 146 matches
Mail list logo
