Hi all,
This is now a conflict between the drm tree and Linus' tree.
On Fri, 22 Mar 2019 10:57:28 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the drm-intel tree got a conflict in:
>
> drivers/gpu/drm/i915/gvt/mmio_context.c
>
> between commit:
>
> 1e8b15a1988e ("drm/i91
Den 28.03.2019 10.31, skrev Daniel Vetter:
> On Tue, Mar 26, 2019 at 06:55:30PM +0100, Noralf Trønnes wrote:
>> This moves the modesetting code from drm_fb_helper to drm_client so it
>> can be shared by all internal clients.
>>
>> I have also added a client display abstraction and a bootsplash ex
Before trying to measure the busyness reporting for the idle state, make
sure the gpu is actually idle and not still running any backgound system
task.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
tests/perf_pmu.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tests/perf_pmu.c b/test
== Series Details ==
Series: series starting with [1/2] drm/i915/icl: Fix for setting HDMI 10/12 bit
Deep color correctly
URL : https://patchwork.freedesktop.org/series/58784/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5845_full -> Patchwork_12644_full
== Series Details ==
Series: drm/i915: Check domains for userptr on release
URL : https://patchwork.freedesktop.org/series/58783/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5845_full -> Patchwork_12643_full
Summary
-
On Sun, 31 Mar 2019 at 10:47, Chris Wilson wrote:
>
> When we return pages to the system, we release control over them and
> should defensively return them to the CPU write domain so that we catch
> any external writes on reacquiring them (e.g. to transparently
> swapout/swapin). While we did this
== Series Details ==
Series: series starting with [1/2] drm/i915/icl: Fix for setting HDMI 10/12 bit
Deep color correctly
URL : https://patchwork.freedesktop.org/series/58784/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5845 -> Patchwork_12644
==
On 2019-03-31 03:02:21, Chris Wilson wrote:
> Quoting Jordan Justen (2019-03-31 10:57:09)
> > On 2019-03-25 03:58:59, Chris Wilson wrote:
> > > iris currently uses two distinct GEM contexts to have distinct logical
> > > HW contexts for the compute and render pipelines. However, using two
> > > dis
== Series Details ==
Series: series starting with [1/2] drm/i915/icl: Fix for setting HDMI 10/12 bit
Deep color correctly
URL : https://patchwork.freedesktop.org/series/58784/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
8f7ec76513b3 drm/i915/icl: Fix for setting HDMI 10/12 b
== Series Details ==
Series: drm/i915: Check domains for userptr on release
URL : https://patchwork.freedesktop.org/series/58783/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5845 -> Patchwork_12643
Summary
---
**SU
Quoting Jordan Justen (2019-03-31 10:57:09)
> On 2019-03-25 03:58:59, Chris Wilson wrote:
> > iris currently uses two distinct GEM contexts to have distinct logical
> > HW contexts for the compute and render pipelines. However, using two
> > distinct GEM contexts implies that they are distinct time
On 2019-03-25 03:58:59, Chris Wilson wrote:
> iris currently uses two distinct GEM contexts to have distinct logical
> HW contexts for the compute and render pipelines. However, using two
> distinct GEM contexts implies that they are distinct timelines, yet as
> they are a single GL context that im
== Series Details ==
Series: drm/i915: Check domains for userptr on release
URL : https://patchwork.freedesktop.org/series/58783/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d4c23a28662b drm/i915: Check domains for userptr on release
-:14: ERROR:GIT_COMMIT_ID: Please use git
Quoting Jordan Justen (2019-03-31 10:53:06)
> Where are these changes from (repo/commit)? It could be good to
> reference in the commit message.
They don't exist in drm-next yet, so they don't have a reference.
-Chris
___
Intel-gfx mailing list
Intel-gfx
Where are these changes from (repo/commit)? It could be good to
reference in the commit message.
I suspect that the answer might mean that these patches should be
labeled RFC.
-Jordan
On 2019-03-25 03:58:58, Chris Wilson wrote:
> For use in GPU recovery and pipeline construction.
> ---
> includ
Adding N & CTS values for 10/12 bit deep color from Appendix C
table in HDMI 2.0 spec. The correct values for N is not chosen
automatically by hardware for deep color modes.
Signed-off-by: Aditya Swarup
Cc: Clint Taylor
Cc: Ville Syrjälä
Cc: Jani Nikula
Cc: Manasi Navare
---
drivers/gpu/drm/
From: Clinton Taylor
Changing settings from 8 bit to 10/12 bit deep color(& vice versa)
doesn't work correctly using xrandr max bpc property. Fix the
driver for applying correct settings.
Test:
xrandr --output HDMI-2 --mode 3840x2160 --rate 30 --set "max bpc" 10
and then
xrandr --output HDMI-2 -
When we return pages to the system, we release control over them and
should defensively return them to the CPU write domain so that we catch
any external writes on reacquiring them (e.g. to transparently
swapout/swapin). While we did this defensive clflushing for ordinary
shmem pages, it was forgot
Quoting Michal Wajdeczko (2019-03-31 10:12:52)
> On Sat, 30 Mar 2019 11:03:49 +0100, Chris Wilson
> wrote:
>
> > As we only set ctx->file_priv on registering the GEM context after
> > construction, it is invalid to try and use it in the middle for setting
>
> Other option would be to set ctx->
On 2019-03-31 00:32:52, Chris Wilson wrote:
> Quoting Jordan Justen (2019-03-31 04:03:44)
> > I think the change is focused mainly around setting the vm param, so
> > perhaps the subject should mention that. Maybe something like:
>
> It's not just about that, it's the design in how create_ext is r
On Sat, 30 Mar 2019 11:03:49 +0100, Chris Wilson
wrote:
As we only set ctx->file_priv on registering the GEM context after
construction, it is invalid to try and use it in the middle for setting
Other option would be to set ctx->file_priv ahead of gem_context_register
and use gem_context_re
Quoting Jordan Justen (2019-03-31 04:03:44)
> I think the change is focused mainly around setting the vm param, so
> perhaps the subject should mention that. Maybe something like:
It's not just about that, it's the design in how create_ext is run
before registration which caters for more than just
22 matches
Mail list logo
