This is ideal and had been discussed in the beginning of upstream.
Mostly people didn't like this approach because it needs to modify i915
ppgtt code a lot and have to introduce a lot gvt-only code in i915 ppgtt.
The idea of the series of Joonas patch is to make PPGTT selection
per-platform. I
== Series Details ==
Series: drm/i915: Check ppgtt validity for GVT GEM context
URL : https://patchwork.freedesktop.org/series/50724/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4951 -> Patchwork_10396 =
== Summary - SUCCESS ==
No regressions found.
External URL:
h
The guest couldn't boot up under GVT-g environment as the following call
trace exists:
[ 272.504762] BUG: unable to handle kernel NULL pointer dereference at
0100
[ 272.504834] Call Trace:
[ 272.504852] execlists_context_pin+0x2b2/0x520 [i915]
[ 272.504869] intel_gvt_scan_and_sha
== Series Details ==
Series: drm/dp: Add definitions for eDP Rev 1.4a and 1.4b
URL : https://patchwork.freedesktop.org/series/50720/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4951_full -> Patchwork_10395_full =
== Summary - SUCCESS ==
No regressions found.
== Kn
On 2018.09.27 12:37:47 -0400, Xiaolin Zhang wrote:
> To enable pvmmio feature, we need to prepare one 4K shared page
> which will be accessed by both guest and backend i915 driver.
>
> guest i915 allocate one page memory and then the guest physical address is
> passed to backend i915 driver throug
On 2018.09.28 14:09:45 +0800, Zhang, Xiaolin wrote:
> On 09/27/2018 07:03 PM, Joonas Lahtinen wrote:
> > Quoting Xiaolin Zhang (2018-09-27 19:37:46)
> >> This int type module parameter is used to control the different
> >> level pvmmio feature for MMIO emulation in GVT.
> >>
> >> This parameter is
On 2018.10.08 13:58:25 +, Wang, Zhi A wrote:
> Thanks for pointing this. My bad.
>
> I take a look on the code and it looks like the GVT-g context is now quite
> similar with the kernel context except the force single submission and ring
> buffer size. (When we upstream the code, there was n
On Mon, 2018-10-08 at 17:49 -0700, Dhinakaran Pandiyan wrote:
> On Mon, 2018-10-08 at 17:30 -0700, Souza, Jose wrote:
> > On Mon, 2018-10-08 at 17:14 -0700, Dhinakaran Pandiyan wrote:
> > > On Fri, 2018-10-05 at 16:35 -0700, José Roberto de Souza wrote:
> > > > While PSR is active hardware will do
On Mon, 2018-10-08 at 17:35 -0700, Souza, Jose wrote:
> On Mon, 2018-10-08 at 17:19 -0700, Dhinakaran Pandiyan wrote:
> > On Fri, 2018-10-05 at 16:35 -0700, José Roberto de Souza wrote:
> > > For eDP panels all the DPCD and EDID data is cached when
> > > initializing
> > > the eDP connector so in f
On Mon, 2018-10-08 at 17:30 -0700, Souza, Jose wrote:
> On Mon, 2018-10-08 at 17:14 -0700, Dhinakaran Pandiyan wrote:
> > On Fri, 2018-10-05 at 16:35 -0700, José Roberto de Souza wrote:
> > > While PSR is active hardware will do aux transactions by it self
> > > to
> > > wakeup sink to receive a ne
== Series Details ==
Series: drm/dp: Add definitions for eDP Rev 1.4a and 1.4b
URL : https://patchwork.freedesktop.org/series/50720/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4951 -> Patchwork_10395 =
== Summary - SUCCESS ==
No regressions found.
External URL:
ht
On Mon, 2018-10-08 at 17:19 -0700, Dhinakaran Pandiyan wrote:
> On Fri, 2018-10-05 at 16:35 -0700, José Roberto de Souza wrote:
> > For eDP panels all the DPCD and EDID data is cached when
> > initializing
> > the eDP connector so in futher detection it do not call
> > intel_dp_detect_dpcd() for eD
== Series Details ==
Series: Fix legacy DPMS changes with MST (rev7)
URL : https://patchwork.freedesktop.org/series/49878/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4951 -> Patchwork_10394 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patc
On Mon, 2018-10-08 at 17:14 -0700, Dhinakaran Pandiyan wrote:
> On Fri, 2018-10-05 at 16:35 -0700, José Roberto de Souza wrote:
> > While PSR is active hardware will do aux transactions by it self to
> > wakeup sink to receive a new frame when necessary. If that
> > transaction is not acked by sink
VESA eDP 1.4 specification has separate fields defined in
EDP_DPCD_REV for eDP 1.4a and 1.4b eDP revisions.
This patch defines those. Found this when one of my eDP panels
advertises eDP 1.4a (04h) in the EDP_DPCD_REV DPCD field.
Cc: Jani Nikula
Cc: Ville Syrjala
Signed-off-by: Manasi Navare
---
On Fri, 2018-10-05 at 16:35 -0700, José Roberto de Souza wrote:
> For eDP panels all the DPCD and EDID data is cached when initializing
> the eDP connector so in futher detection it do not call
> intel_dp_detect_dpcd() for eDP.
> The problem is on the first short pulse interruption it calls
> intel
On Fri, 2018-10-05 at 16:35 -0700, José Roberto de Souza wrote:
> While PSR is active hardware will do aux transactions by it self to
> wakeup sink to receive a new frame when necessary. If that
> transaction is not acked by sink, hardware will trigger this
> interruption.
>
> So let's disable PSR
== Series Details ==
Series: Fix legacy DPMS changes with MST (rev6)
URL : https://patchwork.freedesktop.org/series/49878/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4950 -> Patchwork_10393 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patc
Currently, i915 appears to rely on blocking modesets on
no-longer-present MSTB ports by simply returning NULL for
->best_encoder(), which in turn causes any new atomic commits that don't
disable the CRTC to fail. This is wrong however, since we still want to
allow userspace to disable CRTCs on no-l
Since we need to be able to allow DPMS on->off prop changes after an MST
port has disappeared from the system, we need to be able to make sure we
can compute a config for the resulting atomic commit. Currently this is
impossible when the port has disappeared, since the VCPI slot searching
we try to
With the exception of modesets which would switch the DPMS state of a
connector from on to off, we want to make sure that we disallow all
modesets which would result in enabling a new monitor or a new mode
configuration on a monitor if the connector for the display in question
is no longer register
Currently we set intel_connector->mst_port to NULL to signify that the
MST port has been removed from the system so that we can prevent further
action on the port such as connector probes, mode probing, etc.
However, we're going to need access to intel_connector->mst_port in
order to fixup ->best_e
As mentioned in the previous commit, we currently prevent new modesets
on recently-removed MST connectors by returning no encoder from our
->best_encoder() callback once the MST port has disappeared. This is
wrong however, because it prevents legacy modesetting users from being
able to disable CRTC
Next version of https://patchwork.freedesktop.org/series/49878/
Still no functional changes, just removing a duplicate s-b to make CI
happy.
Lyude Paul (5):
drm/atomic_helper: Disallow new modesets on unregistered connectors
drm/nouveau: Fix nv50_mstc->best_encoder()
drm/i915: Don't unset i
== Series Details ==
Series: Fix legacy DPMS changes with MST (rev6)
URL : https://patchwork.freedesktop.org/series/49878/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
c7fbf3e3184e drm/atomic_helper: Disallow new modesets on unregistered connectors
de38c26c2d84 drm/nouveau: Fi
== Series Details ==
Series: Fix legacy DPMS changes with MST (rev5)
URL : https://patchwork.freedesktop.org/series/49878/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4950 -> Patchwork_10392 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patc
== Series Details ==
Series: Fix legacy DPMS changes with MST (rev5)
URL : https://patchwork.freedesktop.org/series/49878/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e2f961e30125 drm/atomic_helper: Disallow new modesets on unregistered connectors
492652e4f510 drm/nouveau: Fi
Currently, i915 appears to rely on blocking modesets on
no-longer-present MSTB ports by simply returning NULL for
->best_encoder(), which in turn causes any new atomic commits that don't
disable the CRTC to fail. This is wrong however, since we still want to
allow userspace to disable CRTCs on no-l
With the exception of modesets which would switch the DPMS state of a
connector from on to off, we want to make sure that we disallow all
modesets which would result in enabling a new monitor or a new mode
configuration on a monitor if the connector for the display in question
is no longer register
Currently we set intel_connector->mst_port to NULL to signify that the
MST port has been removed from the system so that we can prevent further
action on the port such as connector probes, mode probing, etc.
However, we're going to need access to intel_connector->mst_port in
order to fixup ->best_e
Since we need to be able to allow DPMS on->off prop changes after an MST
port has disappeared from the system, we need to be able to make sure we
can compute a config for the resulting atomic commit. Currently this is
impossible when the port has disappeared, since the VCPI slot searching
we try to
As mentioned in the previous commit, we currently prevent new modesets
on recently-removed MST connectors by returning no encoder from our
->best_encoder() callback once the MST port has disappeared. This is
wrong however, because it prevents legacy modesetting users from being
able to disable CRTC
Next version of https://patchwork.freedesktop.org/series/49878/
No functional changes, just a typo fix
Lyude Paul (5):
drm/atomic_helper: Disallow new modesets on unregistered connectors
drm/nouveau: Fix nv50_mstc->best_encoder()
drm/i915: Don't unset intel_connector->mst_port
drm/i915: S
On Fri, 2018-10-05 at 16:35 -0700, José Roberto de Souza wrote:
> It should always wait for idle state when disabling PSR because PSR
> could be inactive due a call to intel_psr_exit() and while PSR is
> still being disabled asynchronously userspace could change the
> modeset causing a call to psr_
Currently, i915 appears to rely on blocking modesets on
no-longer-present MSTB ports by simply returning NULL for
->best_encoder(), which in turn causes any new atomic commits that don't
disable the CRTC to fail. This is wrong however, since we still want to
allow userspace to disable CRTCs on no-l
Currently we set intel_connector->mst_port to NULL to signify that the
MST port has been removed from the system so that we can prevent further
action on the port such as connector probes, mode probing, etc.
However, we're going to need access to intel_connector->mst_port in
order to fixup ->best_e
Since we need to be able to allow DPMS on->off prop changes after an MST
port has disappeared from the system, we need to be able to make sure we
can compute a config for the resulting atomic commit. Currently this is
impossible when the port has disappeared, since the VCPI slot searching
we try to
With the exception of modesets which would switch the DPMS state of a
connector from on to off, we want to make sure that we disallow all
modesets which would result in enabling a new monitor or a new mode
configuration on a monitor if the connector for the display in question
is no longer register
As mentioned in the previous commit, we currently prevent new modesets
on recently-removed MST connectors by returning no encoder from our
->best_encoder() callback once the MST port has disappeared. This is
wrong however, because it prevents legacy modesetting users from being
able to disable CRTC
Latest version of https://patchwork.freedesktop.org/series/49878/
Lyude Paul (5):
drm/atomic_helper: Disallow new modesets on unregistered connectors
drm/nouveau: Fix nv50_mstc->best_encoder()
drm/i915: Don't unset intel_connector->mst_port
drm/i915: Skip vcpi allocation for MSTB ports tha
== Series Details ==
Series: drm/i915: Rename full ppgtt configuration to be more generic (rev6)
URL : https://patchwork.freedesktop.org/series/49021/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4950_full -> Patchwork_10391_full =
== Summary - WARNING ==
Minor unknown
On Mon, Oct 01, 2018 at 07:03:52PM +0300, Ville Syrjälä wrote:
> On Wed, Sep 12, 2018 at 03:57:16PM -0700, Manasi Navare wrote:
> > This patch fixes the original commit c0cfb10d9e1de49 ("drm/i915/edp:
> > Do not do link training fallback or prune modes on EDP") that causes
> > a blank screen in cas
== Series Details ==
Series: drm/i915: Rename full ppgtt configuration to be more generic (rev6)
URL : https://patchwork.freedesktop.org/series/49021/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4950 -> Patchwork_10391 =
== Summary - WARNING ==
Minor unknown changes co
== Series Details ==
Series: drm/i915: Rename full ppgtt configuration to be more generic (rev6)
URL : https://patchwork.freedesktop.org/series/49021/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Make 48bit full ppgtt configuration generic
== Series Details ==
Series: drm/i915: Rename full ppgtt configuration to be more generic (rev6)
URL : https://patchwork.freedesktop.org/series/49021/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
bcd9b888d547 drm/i915: Make 48bit full ppgtt configuration generic (v7)
-:286: ER
48 bit ppgtt device configuration is really just extended address
range full ppgtt and may actually be something other than 48 bits.
Change HAS_FULL_48BIT_PPGTT() to HAS_4LVL_PPGTT() to better
describe that a 4 level walk table extended range PPGTT is being
used. Add a new device info field that s
== Series Details ==
Series: drm/i915: serialized performance queries
URL : https://patchwork.freedesktop.org/series/50698/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4950_full -> Patchwork_10390_full =
== Summary - FAILURE ==
Serious unknown changes coming with Patch
Hi Bjorn,
On Thu, Oct 4, 2018 at 4:12 AM Bjorn Helgaas wrote:
>
> On Thu, Sep 27, 2018 at 10:10:07AM +0800, Bin Meng wrote:
> > On Thu, Sep 27, 2018 at 12:57 AM Bjorn Helgaas wrote:
> > > On Wed, Sep 26, 2018 at 08:14:01AM -0700, Bin Meng wrote:
> > > > Add more PCI IDs to the Intel GPU "spuriou
Hi David,
On Mon, Oct 8, 2018 at 6:06 PM David Laight wrote:
>
> From: Bin Meng
> > Sent: 08 October 2018 10:44
> ...
> > Correct, disable the shared interrupt line keeps all devices using
> > that line from working, which is current kernel's behavior w/o this
> > quirk handling: it disables the
On Mon, 8 Oct 2018 22:35:34 +0800
Chris Chiu wrote:
> Thanks! I have no problem with this patch.
There are Fi.CI.BAT failures with the v2 (only with formatting fix
added) while the previous patch had passing results.
Now trying to identify why the failures happened with trybot
Thanks,
Guang
>
== Series Details ==
Series: drm/i915: serialized performance queries
URL : https://patchwork.freedesktop.org/series/50698/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4950 -> Patchwork_10390 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://pat
On 08/10/2018 16:35, Chris Wilson wrote:
Quoting Lionel Landwerlin (2018-10-08 16:18:20)
We would like to make use of perf in Vulkan. The Vulkan API is much
lower level than OpenGL, with applications directly exposed to the
concept of command buffers (pretty much equivalent to our batch
buffers)
Quoting Lionel Landwerlin (2018-10-08 16:18:22)
> We want the ability to dispatch a set of command buffer to the
> hardware, each with a different OA configuration. To achieve this, we
> reuse a couple of fields from the execbuf2 struct (I CAN HAZ
> execbuf3?) to notify what OA configuration should
On 08/10/2018 16:34, Chris Wilson wrote:
Quoting Lionel Landwerlin (2018-10-08 16:18:21)
Here we introduce a mechanism by which the execbuf part of the i915
driver will be able to request that a batch buffer containing the
programming for a particular OA config be created.
We'll execute these O
Quoting Lionel Landwerlin (2018-10-08 16:18:20)
> We would like to make use of perf in Vulkan. The Vulkan API is much
> lower level than OpenGL, with applications directly exposed to the
> concept of command buffers (pretty much equivalent to our batch
> buffers). In Vulkan, queries are always limi
== Series Details ==
Series: series starting with [1/2] drm/i915: Do intel_panel_destroy_backlight()
later
URL : https://patchwork.freedesktop.org/series/50691/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4950_full -> Patchwork_10389_full =
== Summary - WARNING ==
Min
Quoting Lionel Landwerlin (2018-10-08 16:18:21)
> Here we introduce a mechanism by which the execbuf part of the i915
> driver will be able to request that a batch buffer containing the
> programming for a particular OA config be created.
>
> We'll execute these OA configuration buffers right befo
== Series Details ==
Series: drm/i915: serialized performance queries
URL : https://patchwork.freedesktop.org/series/50698/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915/perf: allow holding preemption on filtered ctx
Okay!
Commit: drm/i915/p
== Series Details ==
Series: drm/i915: serialized performance queries
URL : https://patchwork.freedesktop.org/series/50698/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
40102d5976dd drm/i915/perf: allow holding preemption on filtered ctx
ccae77ecfc25 drm/i915/perf: allow for C
We want the ability to dispatch a set of command buffer to the
hardware, each with a different OA configuration. To achieve this, we
reuse a couple of fields from the execbuf2 struct (I CAN HAZ
execbuf3?) to notify what OA configuration should be used for a batch
buffer. This requires the process m
We would like to make use of perf in Vulkan. The Vulkan API is much
lower level than OpenGL, with applications directly exposed to the
concept of command buffers (pretty much equivalent to our batch
buffers). In Vulkan, queries are always limited in scope to a command
buffer. In OpenGL, the lack of
Here we introduce a mechanism by which the execbuf part of the i915
driver will be able to request that a batch buffer containing the
programming for a particular OA config be created.
We'll execute these OA configuration buffers right before executing a
set of userspace commands so that a particu
Hi all,
This is a early stage series on which I'm looking for feedback.
Some background :
Performance queries (sampling performance counters through
MI_REPORT_PERF_COUNT instruction) commands requires the hardware to be
programmed with the desired configuration to allow particular
performance da
Quoting Ville Syrjala (2018-10-08 14:46:40)
> From: Ville Syrjälä
>
> Currently we destroy the backlight during connector unregistration.
> That means the final modeset performed by drm_atomic_helper_shutdown()
> will leave the backlight on. We don't want that so let's just move
> intel_panel_des
Thanks! I have no problem with this patch.
On Thu, Oct 4, 2018 at 2:08 AM Guang Bai wrote:
> On some platforms, slowly unplugging (wiggling) the HDMI cable makes
> the kernel to believe the HDMI display still connected. This is because
> the HDMI DDC lines are disconnected sometimes later after
Quoting Ville Syrjala (2018-10-08 14:46:40)
> From: Ville Syrjälä
>
> Currently we destroy the backlight during connector unregistration.
> That means the final modeset performed by drm_atomic_helper_shutdown()
> will leave the backlight on. We don't want that so let's just move
> intel_panel_des
Quoting Ville Syrjala (2018-10-08 14:46:41)
> From: Ville Syrjälä
>
> As long as the connector was zeroed during allocation calling
> intel_panel_fini() is safe even if we haven't initialized
> the panel struct explicitly. So let's drop the useless eDP
> check from dp connector destruction.
>
>
== Series Details ==
Series: series starting with [1/2] drm/i915: Do intel_panel_destroy_backlight()
later
URL : https://patchwork.freedesktop.org/series/50691/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4950 -> Patchwork_10389 =
== Summary - SUCCESS ==
No regression
On Mon, Oct 08, 2018 at 09:44:08AM +0300, Jani Nikula wrote:
> On Fri, 05 Oct 2018, Chris Wilson wrote:
> > If we reduce the suspend function for intel_opregion to do the minimum
> > required, the resume function can also do the simple task of notifier
> > the ACPI bios that we are back. This avoi
Radhakrishna Sripada writes:
> From: Anuj Phogat
>
> Incorrect TDL's SSP address shift in SARB for 16:6 & 18:8 modes.
> Disable the Sampler state prefetch functionality in the SARB by
> programming 0xB000[30] to '1'. This is to be done at boot time
> and the feature must remain disabled permanen
Thanks for pointing this. My bad.
I take a look on the code and it looks like the GVT-g context is now quite
similar with the kernel context except the force single submission and ring
buffer size. (When we upstream the code, there was no kernel context at that
time. :/) Now there is already on
Radhakrishna Sripada writes:
> Shader feature to prefetch binding tables does not support 16:6 18:8 BTP
> formats. Enabling fault handling could result in hangs with faults.
> Disabling demand prefetch would disable binding table prefetch.
>
> V2: Fix the stepping rivision to B0(Mika)
>
> Referen
From: Ville Syrjälä
Currently we destroy the backlight during connector unregistration.
That means the final modeset performed by drm_atomic_helper_shutdown()
will leave the backlight on. We don't want that so let's just move
intel_panel_destroy_backlight() into intel_panel_fini() which gets
call
From: Ville Syrjälä
As long as the connector was zeroed during allocation calling
intel_panel_fini() is safe even if we haven't initialized
the panel struct explicitly. So let's drop the useless eDP
check from dp connector destruction.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/inte
From: Bin Meng
> Sent: 08 October 2018 13:34
> Hi David,
>
> On Mon, Oct 8, 2018 at 6:06 PM David Laight wrote:
> >
> > From: Bin Meng
> > > Sent: 08 October 2018 10:44
> > ...
> > > Correct, disable the shared interrupt line keeps all devices using
> > > that line from working, which is current
== Series Details ==
Series: drm/i915: Fixup kernel doc for param name changes
URL : https://patchwork.freedesktop.org/series/50679/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4948_full -> Patchwork_10388_full =
== Summary - SUCCESS ==
No regressions found.
== Kn
== Series Details ==
Series: drm/i915: Fixup kernel doc for param name changes
URL : https://patchwork.freedesktop.org/series/50679/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4948 -> Patchwork_10388 =
== Summary - SUCCESS ==
No regressions found.
External URL:
ht
Acked-by: Maarten Lankhorst
On 08.10.2018 14:13, Ville Syrjälä wrote:
On Mon, Oct 08, 2018 at 11:48:08AM +0100, Chris Wilson wrote:
s/crtc/crtc_state/ for the kernel doc as well as the params.
Fixes: 65c307fd08dd ("drm/i915: Make shared dpll functions take crtc_state,
v3.")
Signed-off-by: C
On Mon, Oct 08, 2018 at 11:48:08AM +0100, Chris Wilson wrote:
> s/crtc/crtc_state/ for the kernel doc as well as the params.
>
> Fixes: 65c307fd08dd ("drm/i915: Make shared dpll functions take crtc_state,
> v3.")
> Signed-off-by: Chris Wilson
> Cc: Maarten Lankhorst
> Cc: Ville Syrjälä
Review
s/crtc/crtc_state/ for the kernel doc as well as the params.
Fixes: 65c307fd08dd ("drm/i915: Make shared dpll functions take crtc_state,
v3.")
Signed-off-by: Chris Wilson
Cc: Maarten Lankhorst
Cc: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dpll_mgr.c | 6 +++---
1 file changed, 3 insertions
On Fri, Oct 05, 2018 at 03:18:44PM -0700, clinton.a.tay...@intel.com wrote:
> From: Clint Taylor
>
> Setting the SCDC scrambling CTS mode causes HDMI Link Layer protocol tests
> HF1-12 and HF1-13 to fail. Added "Source Shall" entries from SCDC
> section before enabling scrambling.
>
> Bugzilla:
From: Bin Meng
> Sent: 08 October 2018 10:44
...
> Correct, disable the shared interrupt line keeps all devices using
> that line from working, which is current kernel's behavior w/o this
> quirk handling: it disables the (shared) interrupt line after 100.000+
> generated interrupts. But the side e
On 2018.09.26 11:02:15 +0300, Joonas Lahtinen wrote:
> Quoting He, Min (2018-09-26 04:06:25)
> > No. We changed to full 48bit ppgtt long time ago. :)
>
> So would that mean the change is OK to do?
Looks that one unfortunately caused gvt regression, gvt context has
no i915 managed i915_hw_ppgtt bu
83 matches
Mail list logo
