Dear,
I use NVidia Geforce 7300GT graphics card in my PC, and Linux 3.1rc4 kernel
code, git drm 2.4.36.
When I run the vbltest program, it prints "60HZ" which indicated the
implementation of drmWaitVBlank() and drm_vblank_wait() is correct.
But when I run modetest with option " -v -s 12:
Can anyone give a suggestion, is wait-vblank fully implemented in page_flip()
for nouveau drm driver?
At 2011-10-24 14:30:55,chris wrote:
Dear,
I use NVidia Geforce 7300GT graphics card in my PC, and Linux 3.1rc4 kernel
code, git drm 2.4.36.
When I run the vbltest program, it prints
hange the frontbuffer
context when it is rendering, am I right?
At 2011-10-25 13:45:29,"Maarten Maathuis" wrote:
>2011/10/25 chris :
>> Can anyone give a suggestion, is wait-vblank fully implemented in
>> page_flip() for nouveau drm driver?
>>
>>
>>
I think page_flip ioctl need to realize a synchronous mechanism to control
fresh rate...!!!
At 2011-10-25 20:30:39,"Ben Skeggs" wrote:
>On Tue, 2011-10-25 at 14:15 +0200, Francisco Jerez wrote:
>> Maarten Maathuis writes:
>>
>> > 2011/10/25 chris :
>>
Dear,
I use NVidia Geforce 7300GT graphics card in my PC, and Linux 3.1rc4 kernel
code, git drm 2.4.36.
When I run the vbltest program, it prints "60HZ" which indicated the
implementation of drmWaitVBlank() and drm_vblank_wait() is correct.
But when I run modetest with option " -v -s 12:
Can anyone give a suggestion, is wait-vblank fully implemented in page_flip()
for nouveau drm driver?
At 2011-10-24 14:30:55,chris wrote:
Dear,
I use NVidia Geforce 7300GT graphics card in my PC, and Linux 3.1rc4 kernel
code, git drm 2.4.36.
When I run the vbltest program, it prints
hange the frontbuffer
context when it is rendering, am I right?
At 2011-10-25 13:45:29,"Maarten Maathuis" wrote:
>2011/10/25 chris :
>> Can anyone give a suggestion, is wait-vblank fully implemented in
>> page_flip() for nouveau drm driver?
>>
>>
>>
I think page_flip ioctl need to realize a synchronous mechanism to control
fresh rate...!!!
At 2011-10-25 20:30:39,"Ben Skeggs" wrote:
>On Tue, 2011-10-25 at 14:15 +0200, Francisco Jerez wrote:
>> Maarten Maathuis writes:
>>
>> > 2011/10/25 chris :
>>
From: Chris Morgan
Set a condition for the message of "Couldn't set OPP regulators" to not
display if the error code is EPROBE_DEFER. Note that I used an if
statement to capture the condition instead of the dev_err_probe
function because I didn't want to change the DRM_DEV_
t.
I filed a bug on
https://gitlab.freedesktop.org/drm/intel/-/issues/3407 and also
uploaded the journal log with kernel boot parameter
"drm.debug=0x10e".
Can anyone suggest what happens at the replug? What can we do to
identify the cause? Thanks
Chris
__
Update the panel to allow setting the rotation value in device tree.
Tested on an Odroid Go Advance, where the panel is by default rotated 270
degrees.
Signed-off-by: Chris Morgan
---
drivers/gpu/drm/panel/panel-elida-kd35t133.c | 8
1 file changed, 8 insertions(+)
diff --git a
Update the comments to state this is a 3.5" display and not a 5.5" display.
Signed-off-by: Chris Morgan
---
drivers/gpu/drm/panel/panel-elida-kd35t133.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-elida-kd35t133.c
b/drivers/gpu
Quoting Daniel Vetter (2021-01-14 09:02:57)
> On Wed, Jan 13, 2021 at 10:08 PM Chris Wilson
> wrote:
> > Quoting Daniel Vetter (2021-01-13 20:50:11)
> > > On Wed, Jan 13, 2021 at 4:43 PM Chris Wilson
> > > wrote:
> > > >
> > > > Quoting Dan
Quoting Daniel Vetter (2021-01-14 09:30:32)
> On Thu, Jan 14, 2021 at 10:23 AM Chris Wilson
> wrote:
> > The only other problem I see with the implementation is that there's
> > nothing that says that each dmabuf->ops->map_dma_buf() returns a new
> > sg_tabl
Quoting Steven Rostedt (2021-01-14 21:32:06)
> On reboot, one of my test boxes now triggers the following warning:
057fe3535eb3 ("drm/i915: Disable RPM wakeref assertions during driver shutdown")
is included with the drm-intel-fixes PR.
-Chris
__
Quoting Daniel Vetter (2021-01-14 09:47:40)
> On Thu, Jan 14, 2021 at 09:45:37AM +0000, Chris Wilson wrote:
> > Quoting Daniel Vetter (2021-01-14 09:30:32)
> > > On Thu, Jan 14, 2021 at 10:23 AM Chris Wilson
> > > wrote:
> > > > The only other proble
_ERR_OR_NULL(sg_table))
> + return;
Although NULL is not meant to be returned.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
_user_pages() in the process.
> On failure, return -EFAULT so that userspace can fallback to software
> blitting.
See https://patchwork.freedesktop.org/series/33449/ for adding PROBE |
POPULATE flags.
But we can just use set-domain.
-Chris
___
dri-de
Quoting Chris Wilson (2021-01-15 16:56:42)
> Quoting Jinoh Kang (2021-01-15 16:23:31)
> > If GUP-ineligible pages are passed to a GEM userptr object, -EFAULT is
> > returned only when the object is actually bound.
> >
> > The xf86-video-intel userspace drive
ssignment moved to the end as a separate patch.
That makes more sense.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Quoting Pan Bian (2021-01-22 01:56:40)
> Object out is not released on path that no VMA instance found. The root
> cause is jumping to an unexpected label on the error path.
Wouldn't the root cause be whatever caused the allocation to fail?
Language notwithstanding,
Reviewed-by: C
quot;ret" if i915_gem_object_pin_map()
> fails.
True.
> Let's fix the bug and silence the false positive.
>
> Fixes: 493f30cd086e ("drm/i915/gvt: parse init context to update cmd
> accessible reg whitelist")
> Signed-off-by: Dan Carpenter
Review
[=y] && DRM_I915 [=m] && EXPERT [=y] &&
> !COMPILE_TEST [=y]
> Selected by [m]:
> - DRM_I915_DEBUG [=y] && HAS_IOMEM [=y] && EXPERT [=y] && DRM_I915 [=m]
DRM_I915_DEBUG now depends on !COMPILE_TEST and EXPERT.
-Chris
plicit declaration of
> function 'wbinvd_on_all_cpus' [-Werror,-Wimplicit-function-declaration]
I thought the code was already in i915_gem_pm.c (which included smp.h);
it is now.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop
next
Ta. Saves me having to do the fixup.
Reviewed-by: Chris Wilson
Will be applied to drm-intel-gt-next which is scheduled for inclusion in
5.13. It should apply against the 5.12 merge window if there's a tree
through which you want to migrate the tasklet API faster.
-Chris
___
> ppgtt->vm.i915 = i915;
> ppgtt->vm.total = round_down(U64_MAX, PAGE_SIZE);
> ppgtt->vm.file = ERR_PTR(-ENODEV);
> - ppgtt->vm.dma = &i915->drm.pdev->dev;
> + ppgtt->vm.dma = i915->drm.dev;
We can remove thi
start as a copy of module parameters. */
Stick the mock
- i915->drm.pdev = pdev;
in this patch, and I'm happy.
With that, the series is
Reviewed-by: Chris Wilson
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
that.
>
>
> and now I see that it also happens in today's linux-next.
The fix is in the tree that should be feeding into linux-next, so I
trust it will resolve itself shortly. Along with the WERROR depends
snafu.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
level for ivb, should we not
enable the optimisation for ivb unaffected by the w/a? Just no one has
taken the time to see if it causes a regression.
For error state, the question remains whether we should revert to
uncompressed data if the compressed stream is larger than the origina
Quoting Vinicius Tinti (2021-01-30 12:34:11)
> On Fri, Jan 29, 2021 at 08:55:54PM +0000, Chris Wilson wrote:
> > Quoting Vinicius Tinti (2021-01-29 18:15:19)
> > > By enabling -Wunreachable-code-aggressive on Clang the following code
> > > paths are unreachable.
&
verflow potential for
print_text()")
Reported-by: Sven Schnelle
Signed-off-by: John Ogness
Signed-off-by: Petr Mladek
Link:
https://lore.kernel.org/r/20210124202728.4718-1-john.ogn...@linutronix.de
din should be rolled forward, but there's yet another regression in r
that would show the GPU% on/next the CPU overview.
Then we could have a futher expansion of a GPU% into per-channel
utilisation. That would be useful to check to see what is saturating a
particular channel, e.g. find the video decoder bottleneck.
Signed-off-by: Chris Wilson
---
fs/proc/Makefile
Use the pid to find associated clients, and report their runtime. This
will be used to provide the information via procfs.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drm_client.c | 70 +++---
drivers/gpu/drm/i915/i915_drm_client.h | 12 +++--
2 files changed
Register with /proc/gpu to provide the client runtimes for generic
top-like overview, e.g. gnome-system-monitor can use this information to
show the per-process multi-GPU usage.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Makefile| 1 +
drivers/gpu/drm/i915/gt/intel_gt.c
/intel/-/issues/3046
Signed-off-by: Chris Wilson
Cc: Jani Nikula
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 1e1cb245fca7..470a5214bd33 100644
--- a/drivers/gpu/drm/i915
, lift SYS_kcmp out of the non-default
CONFIG_CHECKPOINT_RESTORE into the selectable syscall category.
Signed-off-by: Chris Wilson
Cc: Kees Cook
Cc: Andy Lutomirski
Cc: Will Drewry
Cc: Andrew Morton
Cc: Dave Airlie
Cc: Daniel Vetter
Cc: Lucas Stach
---
init/Kconfig
/3046
Signed-off-by: Chris Wilson
Cc: Kees Cook
Cc: Andy Lutomirski
Cc: Will Drewry
Cc: Andrew Morton
Cc: Dave Airlie
Cc: Daniel Vetter
Cc: Lucas Stach
Acked-by: Daniel Vetter # DRM depends on SYS_kcmp
---
v2:
- Default n.
- Borrrow help message from man kcmp.
- Export
The subject should of course be changed, as it is no longer being
enabled by default.
Something like
kcmp: Support selection of SYS_kcmp without CHECKPOINT_RESTORE
Quoting Chris Wilson (2021-02-05 21:06:10)
> Userspace has discovered the functionality offered by SYS_kcmp and has
> star
Quoting Kees Cook (2021-02-05 21:20:33)
> On Fri, Feb 05, 2021 at 09:16:01PM +0000, Chris Wilson wrote:
> > The subject should of course be changed, as it is no longer being
> > enabled by default.
>
> "default n" is redundant.
I thought being explicit would be p
CHECKPOINT_RESTORE in their configs and so, by extension, SYS_kcmp.
References: https://gitlab.freedesktop.org/drm/intel/-/issues/3046
Signed-off-by: Chris Wilson
Cc: Kees Cook
Cc: Andy Lutomirski
Cc: Will Drewry
Cc: Andrew Morton
Cc: Dave Airlie
Cc: Daniel Vetter
Cc: Lucas Stach
Cc: Rasmus Villemoes
Cc
int pagenum", and then we can remove
the GEM_WARN_ON((sz) >> PAGE_SHIFT > INT_MAX). These are not emitted for
users, only for us to motivate us into finally fixing the code.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http
Quoting Emil Velikov (2021-02-12 14:57:56)
> Hi Chris,
>
> On Thu, 4 Feb 2021 at 12:11, Chris Wilson wrote:
> >
> > Register with /proc/gpu to provide the client runtimes for generic
> > top-like overview, e.g. gnome-system-monitor can use this information to
> &g
Update the panel to allow setting the rotation value in device tree.
Signed-off-by: Chris Morgan
---
drivers/gpu/drm/panel/panel-elida-kd35t133.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-elida-kd35t133.c
b/drivers/gpu/drm/panel/panel-elida
Update the comments to state this is a 3.5" display and not a 5.5" display
Signed-off-by: Chris Morgan
---
drivers/gpu/drm/panel/panel-elida-kd35t133.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-elida-kd35t133.c
b/drivers/gpu/drm/p
Quoting Emil Velikov (2021-02-12 15:45:04)
> On Fri, 12 Feb 2021 at 15:16, Chris Wilson wrote:
> >
> > Quoting Emil Velikov (2021-02-12 14:57:56)
> > > Hi Chris,
> > >
> > > On Thu, 4 Feb 2021 at 12:11, Chris Wilson
> > > wrote:
> >
Quoting Ram Moon, AnandX (2021-02-15 12:29:17)
> Hi Chris,
>
> -Original Message-
> From: dri-devel On Behalf Of Chris
> Wilson
> Sent: Wednesday, February 10, 2021 4:15 PM
> To: Ram Moon, AnandX ; Jani Nikula
> ; Auld, Matthew ;
> Surendrakumar Upadhya
Quoting Ram Moon, AnandX (2021-02-16 12:05:23)
> Hi Chris,
>
> -Original Message-
> From: dri-devel On Behalf Of Chris
> Wilson
> Sent: Monday, February 15, 2021 6:10 PM
> To: Auld, Matthew ; Ram Moon, AnandX
> ; Surendrakumar Upadhyay, TejaskumarX
> ; Ursul
This fixes an issue with the panel not working after
commit c6d94e37bdbb ("drm/bridge/synopsys: dsi: add support for non-continuous
HS clock").
With this change the panel inits successfully and displays an image.
Signed-off-by: Chris Morgan
---
drivers/gpu/drm/panel/panel-elida-kd35
he attachment if the attachment rather than the dmabuf is to be
dynamic.
Fixes: bb42df4662a4 ("dma-buf: add dynamic DMA-buf handling v15")
Fixes: c545781e1c55 ("dma-buf: doc polish for pin/unpin")
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: Christian König
Cc: #
which causes the whole desktop to lock up.
The fence error handling is required to prevent user's circumventing
incomplete work, such as security validation or escaping isolation.
-Chris
___
dri-devel mailing list
dri-devel@lists
pposed to an internal allocation failure from
the driver.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
t
in this case the idea was to return 0 as no testing was done and the
ENOMEM was raised before testing began i.e. not an internal and
unexpected driver allocation failure.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freede
wn by igt it's a critical issue that we have to judicially
chose which errors to ignore. And it's not just the ability to subvert
gen7 and gen9, it's the error tracking employed for preempting contexts
among others. Hence go with the original patch to undo the propagation
along dma-resv.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
gt; We have an access to exec2_list there, we know the gen so we're able to say
> relocations are not supported immediate, without entering
> i915_gem_do_execbuffer().
There's a NORELOC flag you can enforce as mandatory. That's trivial for
userspace to set, really makes sure the
le s2idle
enter/exit with IPCS timeout.
Any suggestion would be appreciated. Thanks.
Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Thu, May 6, 2021 at 5:46 PM Rafael J. Wysocki wrote:
>
> On Tue, May 4, 2021 at 10:08 AM Chris Chiu wrote:
> >
> > Hi,
> > We have some Intel laptops (11th generation CPU) with NVIDIA GPU
> > suffering the same GPU falling off the bus problem while exiting
&g
Quoting Luo Meng (2020-11-25 01:29:38)
> Fix to return a negative error code from the error handling case
> instead of 0 in function check_partial_mapping(), as done elsewhere
> in this function.
It's not an error, just the end of t
Quoting Ville Syrjälä (2020-10-30 14:43:46)
> On Fri, Oct 30, 2020 at 02:19:45PM +0000, Chris Wilson wrote:
> > Quoting Ville Syrjala (2020-10-22 20:42:56)
> > > From: Ville Syrjälä
> > >
> > > The new >8k CEA modes have dotclocks reaching 5.94 GHz, wh
hich
> is
> +* annoying. In the pipeline is support for async get_pages()
> +* which should fit nicely for this. Also note that the actual
> +* clear should be done async(we currently do an object_wait
> +* which is pure garbage), we just need to take care if
> +* userspace opts of implicit sync for the execbuf, to avoid
> any
> +* potential info leak.
> +*/
Not just XXX, but the design should be completed first.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Quoting Matthew Auld (2020-11-27 12:06:09)
> From: Michel Thierry
>
> Signed-off-by: Michel Thierry
> Signed-off-by: Matthew Auld
> Cc: Joonas Lahtinen
> Cc: Abdiel Janulgue
> ---
> drivers/gpu/drm/i915/gt/intel_ring.c | 15 +++
> 1 file changed, 11 insertions(+), 4 deletions(-)
mem->instance = instance;
> mem->gt = &i915->gt;
>
> + if (HAS_LMEM(mem->i915) && type != INTEL_MEMORY_SYSTEM)
> + intel_memory_region_set_name(mem, "%s%u",
> +
xts. Here we replace the kmap with the object
> maping code that for simple single page shmemfs object will return a
> plain kmap, that is then kept for the lifetime of the page directory.
>
> Signed-off-by: Matthew Auld
> Signed-off-by: Chris Wilson
We are going to really struggle
*i915 = ppgtt->vm.i915;
> @@ -365,7 +381,7 @@ gen8_ppgtt_insert_pte(struct i915_ppgtt *ppgtt,
> u32 flags)
> {
> struct i915_page_directory *pd;
> - const gen8_pte_t pte_encode = gen8_pte_encode(0, cache_level, fl
em_object_pin_map(ctx_obj, I915_MAP_WC);
> + if (IS_ERR(vaddr))
> + return PTR_ERR(vaddr);
> +
> + memset64(vaddr, 0, ctx_obj->base.size / sizeof(u64));
> +
> + i915_gem_object_unpin_map(ctx_obj);
What? We copy over the entire object with the de
x%llx-0x%llx]\n",
> +reserve_start, reserve_end);
> + ret = i915_buddy_alloc_range(&mem->mm, &mem->reserved,
> + reserve_start,
> +reserve_end - reserve_start);
Isn't this now relative
Quoting Matthew Auld (2020-11-27 12:06:40)
> From: Michel Thierry
Rationale goes here.
Is this wise? HWSP is very frequently read by the CPU, and expected to
be cached on the CPU.
What do the performance profiles indicate?
-Chris
___
dri-de
can ask sg what the backend maximum is, and use that as our max
order.
The only question is whether this merits a flag, or we just assume that
the buddy allocator is only used for objects and so always presented via
sg?
-Chris
___
dri-devel mailing
Quoting Matthew Auld (2020-11-27 12:06:42)
> From: Bommu Krishnaiah
>
> Update shmem available memory in “intel_memory_region”
Was avail ever set?
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.or
addition to evict purgeable objects only.
We really do not want to conflate the system shrinker with eviction.
Reservation based eviction looks nothing like the shrinker.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freed
Enough said. Don't mindlessly add fields.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
> - if (!err)
> + if (!err) {
> + diff = jiffies - start;
> + msec = diff * 1000 / HZ;
> + atomic_long_add(msec, &i915->time_swap_out_ms);
> atomic_long_add(sizes, &i915->num_bytes_swapped_out);
>
quest_put(rq);
> + flush_work(&i915->gt.engine[BCS0]->retire_work);
Papering (doubtful the paper is successful) over bugs by introducing a
whole load more.
This fails the basic premise that eviction must be pipelined. The PTE
are transient and can be written prior to the copy and kept within the
non-preemptible window of the blt. Thus allowing many evictions to
scheduled in parallel (by either allocating separate contexts, or more
preferably picking a user context).
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Quoting Matthew Auld (2020-11-27 12:06:56)
> From: Ramalingam C
>
> window_blt_copy feature is used for swapin and swapout based on the i915
> module parameter called enable_eviction.
A module parameter?
-Chris
___
dri-devel mailing li
tomic_long_t time_swap_out_ms_memcpy;
> + atomic_long_t time_swap_in_ms_memcpy;
See earlier comments about why this will be rejected.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
int id, ret = 0;
> +
> + /*
> +* FIXME: Presently using memcpy,
> +* will replace with blitter once
> +* fix the issues.
> +*/
Why hasn't it been fixed then?
-Chris
___
dri-devel mailing l
intel_engine_pm.c
> @@ -66,6 +66,11 @@ static int __engine_unpark(struct intel_wakeref *wf)
> ce->ops->reset(ce);
> }
Add a list of pinned volatile contexts to the engine that must be
restored across resume.
-Chris
__
;do_swapping = false;
> if (ret) {
> @@ -1176,6 +1177,43 @@ static int intel_dmem_evict_buffers(struct drm_device
> *dev, bool in_suspend)
> return ret;
> }
>
> +static int i915_gem_suspend_ppgtt_mappings(struct drm_i915_private *i915)
> +{
> + struct i915_gem_context *ctx, *cn;
> + int ret;
> +
> + spin_lock(&i915->gem.contexts.lock);
> + list_for_each_entry_safe(ctx, cn, &i915->gem.contexts.list, link) {
Wrong list. Bad starting point from GEM.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
default object, to restore the ctx with default HW values, will leads to
> the dead lock situation. To avoid this, safe to keep these
> objects in SMEM.
Dead patch. Default object state should be recorded as shmemfs.
-Chris
___
dri-deve
Quoting Matthew Auld (2020-11-27 12:07:04)
> From: Venkata Ramana Nayana
>
> In suspend mode use blitter eviction before disable the runtime
> interrupts and in resume use blitter after the gem resume happens.
Consider add it to the suspend prepare func
as_snoop=1. Otherwise, we set obj->cache_choerent=0 and
> have performance impact.
>
> Cc: Chris P Wilson
> Cc: Ramalingam C
> Cc: Sudeep Dutt
> Cc: Matthew Auld
> Signed-off-by: CQ Tang
> ---
> drivers/gpu/drm/i915/gem/i915_gem_object.c | 16 +
of effort to fix up patches after the fact, might as well make it
a real PMU interface.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
wappable copy of the
> default context state")
A bug fix, send it. But please write a concise changelog first.
I missed setting the dirty bit, and so the contents were not being saved
on swap out as expected. Impact is severe; any context created after
resume may be gibberish.
-Chris
__
gt; + ext_data.n_placements,
> + &args->size, &args->handle);
> + if (!ret)
> + return 0;
Applying the extensions has to happen after creating the vanilla object.
It literally is the equivalent of
esno(info->name));
> +#define PRINT_FLAG(name) drm_printf(p, "%s: %s\n", #name, yesno(info->name))
> DEV_INFO_FOR_EACH_FLAG(PRINT_FLAG);
I thought that this was a macro that avoided adding the ';' to each
invocation. Perhaps another time.
Reviewed-by: C
Quoting Matthew Auld (2020-11-27 12:04:37)
> In igt_ppgtt_sanity_check we should also exercise the non-contiguous
> option for LMEM, since this will give us slightly different sg layouts
> and alignment.
>
> Signed-off-by: Matthew Auld
Reviewed-by: Chris
Quoting Matthew Auld (2020-11-27 12:04:40)
> From: Chris Wilson
>
> Cleanup intel_lrc.h by moving some of the residual common register
> definitions into intel_lrc_reg.h, prior to rebranding and splitting off
> the submission backends.
>
> v2: keep the SCHEDULE enum in the
Quoting Matthew Auld (2020-11-27 12:04:41)
> From: Chris Wilson
>
> We want to separate the utility functions for controlling the logical
> ring context from the execlists submission mechanism (which is an
> overgrown scheduler).
>
> This is similar to Daniele's work
Quoting Matthew Auld (2020-11-27 12:04:42)
> From: Daniele Ceraolo Spurio
>
> These functions are independent from the backend used and can therefore
> be split out of the exelists submission file, so they can be re-used by
> the upcoming GuC submission backend.
>
> Base
x27;t report the power consumption.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Quoting Matthew Auld (2020-11-27 12:06:23)
> From: CQ Tang
>
> The lmem region needs to remove the stolen part.
>
> Cc: Joonas Lahtinen
> Cc: Matthew Auld
> Cc: Abdiel Janulgue
> Cc: Chris P Wilson
> Cc: Balestrieri, Francesco
> Cc: Niranjana Vishwanathapur
Quoting Matthew Auld (2020-11-30 11:09:57)
> On 27/11/2020 13:52, Chris Wilson wrote:
> > Quoting Matthew Auld (2020-11-27 12:06:34)
> >> From: Imre Deak
> >>
> >> On DG1 A0/B0 steppings the first 1MB of local memory must be reserved.
> >> One reason
Quoting Matthew Auld (2020-11-30 17:17:16)
> On 27/11/2020 13:55, Chris Wilson wrote:
> > Quoting Matthew Auld (2020-11-27 12:06:40)
> >> From: Michel Thierry
> >
> > Rationale goes here.
> >
> > Is this wise? HWSP is very frequently read by the CPU
ing gem_create, there is no detection of an
unsupported extension. That is there is no rejection of new userspace
asking for placement on an old kernel. (As erroneous as that would be
for many other reasons.)
Unless I've missed something, we need a new ioctl number for CREATEv2.
-Chris
__
_internal(i915, PAGE_SIZE);
> - if (IS_ERR(obj)) {
> - err = PTR_ERR(obj);
> + if (IS_ERR(obj2)) {
> + err = PTR_ERR(obj2);
Reviewed-by: Chris Wilson
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > return PTR_ERR(obj);
> >
> > obj2 = i915_gem_object_create_internal(i915, PAGE_SIZE);
> > - if (IS_ERR(obj)) {
> > - err = PTR_ERR(obj);
> > + if (IS_ERR(obj2)) {
> > + err = PTR_ERR(obj2);
>
> Rev
t;[3.755211] Modules linked in: i915 mei_hdcp x86_pkg_temp_thermal
coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_intel
snd_intel_dspcfg snd_hda_codec r8169 snd_hwdep snd_hda_core realtek mei_me
snd_pcm mei lpc_ich prime_numbers
<4>[3.755224] CR2: 0000
&l
code_context_alloc to make it
> not assert but just return NULL (which seems an already possible return
> value).
>
> Signed-off-by: Tvrtko Ursulin
Good riddance,
Reviewed-by: Chris Wilson
-Chris
___
dri-devel mailing list
dri-
Quoting Tvrtko Ursulin (2020-11-19 13:42:07)
>
> On 18/11/2020 17:04, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2020-11-18 16:36:01)
> >> From: Tvrtko Ursulin
> >>
> >> There is this long standing nit of igt/tools/intel_error_decode asserting
> >
From: Chris Morgan
This series adds the ability to set the byteswap order in the chrontel
ch7033 driver via an optional devicetree node. This is necessary
because the HDMI DIP of the NTC CHIP requires a byteswap order that
differs from the default value of the driver.
Signed-off-by: Chris
From: Chris Morgan
Update dt-binding documentation to add support for setting byteswap of
chrontel ch7033.
New property name of chrontel,byteswap added to set the byteswap order.
This property is optional.
Signed-off-by: Chris Morgan
---
.../bindings/display/bridge/chrontel,ch7033.yaml
1 - 100 of 4529 matches
Mail list logo
