On Thu, May 23, 2019 at 11:10:39AM -0500, Rob Herring wrote:
> On Thu, May 23, 2019 at 6:54 AM Maxime Ripard
> wrote:
> >
> > On Tue, May 21, 2019 at 10:51:51AM +1000, Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > Today's linux-next merge of the drm-misc tree got a conflict in:
> > >
> > >
On Thu, 23 May 2019, Jonathan Corbet wrote:
> With Sphinx 2.0 (or prior versions with the deprecation warnings fixed) the
> docs build fails with:
>
> Documentation/gpu/i915.rst:403: WARNING: Title level inconsistent:
>
> Global GTT Fence Handling
> ~
>
> reST marku
Apparently VLA structs (e.g. struct { int array[count] }) is a gcc
extension that clang refuses to support as handling memory layout is too
difficult for it.
Move the on-stack VLA to the heap.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
benchmarks/gem_wsim.c | 146 ++
On Fri, 2019-05-24 at 08:25 +0100, Chris Wilson wrote:
> Apparently VLA structs (e.g. struct { int array[count] }) is a gcc
> extension that clang refuses to support as handling memory layout is too
> difficult for it.
>
> Move the on-stack VLA to the heap.
IMHO using an upper bound would be much
Chris Wilson writes:
> From: Dongwon Kim
>
> Setting bit5 (headerless msg for preemptable GPGPU context) of SAMPLER_MODE
> register to enable support for the headless msgs on gen11. None of existing
> use cases will be affected by this as this change makes both types of message
> - headerless an
On 24/05/2019 07:45, Chris Wilson wrote:
Having deferred the vma destruction to a worker where we can acquire the
struct_mutex, we have to avoid chasing back into the now destroyed
ppgtt. The pd_vma is special in having a custom unbind function to scan
for unused pages despite the VMA itself bei
Quoting Tvrtko Ursulin (2019-05-24 09:13:14)
>
> On 24/05/2019 07:45, Chris Wilson wrote:
> > Having deferred the vma destruction to a worker where we can acquire the
> > struct_mutex, we have to avoid chasing back into the now destroyed
> > ppgtt. The pd_vma is special in having a custom unbind f
On 24/05/2019 08:25, Chris Wilson wrote:
Apparently VLA structs (e.g. struct { int array[count] }) is a gcc
extension that clang refuses to support as handling memory layout is too
difficult for it.
Move the on-stack VLA to the heap.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
bench
On 24/05/2019 09:17, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-05-24 09:13:14)
On 24/05/2019 07:45, Chris Wilson wrote:
Having deferred the vma destruction to a worker where we can acquire the
struct_mutex, we have to avoid chasing back into the now destroyed
ppgtt. The pd_vma is speci
On Fri, 2019-05-24 at 09:20 +0100, Tvrtko Ursulin wrote:
> On 24/05/2019 08:25, Chris Wilson wrote:
> > Apparently VLA structs (e.g. struct { int array[count] }) is a gcc
> > extension that clang refuses to support as handling memory layout is too
> > difficult for it.
> >
> > Move the on-stack VL
Quoting Tvrtko Ursulin (2019-05-24 09:23:40)
>
> On 24/05/2019 09:17, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-05-24 09:13:14)
> >>
> >> On 24/05/2019 07:45, Chris Wilson wrote:
> >>> Having deferred the vma destruction to a worker where we can acquire the
> >>> struct_mutex, we have t
== Series Details ==
Series: drm/i915/gtt: Neuter the deferred unbind callback from
gen6_ppgtt_cleanup
URL : https://patchwork.freedesktop.org/series/61084/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6138 -> Patchwork_13087
=
On 24/05/2019 09:29, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-05-24 09:23:40)
On 24/05/2019 09:17, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-05-24 09:13:14)
On 24/05/2019 07:45, Chris Wilson wrote:
Having deferred the vma destruction to a worker where we can acquire the
stru
Quoting Tvrtko Ursulin (2019-05-24 09:20:47)
>
> On 24/05/2019 08:25, Chris Wilson wrote:
> > Apparently VLA structs (e.g. struct { int array[count] }) is a gcc
> > extension that clang refuses to support as handling memory layout is too
> > difficult for it.
> >
> > Move the on-stack VLA to the
Quoting Tvrtko Ursulin (2019-05-24 09:31:45)
>
> On 24/05/2019 09:29, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-05-24 09:23:40)
> >>
> >> On 24/05/2019 09:17, Chris Wilson wrote:
> >>> Quoting Tvrtko Ursulin (2019-05-24 09:13:14)
>
> On 24/05/2019 07:45, Chris Wilson wrote:
>
On Fri, 2019-05-24 at 09:33 +0100, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2019-05-24 09:20:47)
> > On 24/05/2019 08:25, Chris Wilson wrote:
> > > Apparently VLA structs (e.g. struct { int array[count] }) is a gcc
> > > extension that clang refuses to support as handling memory layout is too
On 24/05/2019 09:33, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-05-24 09:20:47)
On 24/05/2019 08:25, Chris Wilson wrote:
Apparently VLA structs (e.g. struct { int array[count] }) is a gcc
extension that clang refuses to support as handling memory layout is too
difficult for it.
Move th
Apparently VLA structs (e.g. struct { int array[count] }) is a gcc
extension that clang refuses to support as handling memory layout is too
difficult for it. So calculate the size by hand!
v2: Use alloca().
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
benchmarks/gem_wsim.c | 115
On 24/05/2019 09:36, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-05-24 09:31:45)
On 24/05/2019 09:29, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-05-24 09:23:40)
On 24/05/2019 09:17, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-05-24 09:13:14)
On 24/05/2019 07:45, Chris Wil
Hi all,
I fixed the fbcon_exited mess that CI spotted (hopefully it works now, the
code is still rather brittle imo). Plus all the little nits 0day and
people found.
Maarten slapped an rb onto the entire pile, but I feel like enough has
changed that a 2nd look from him is warranted.
I also added
As part of trying to understand the locking (or lack thereof) in the
fbcon/vt/fbdev maze, annotate everything.
Signed-off-by: Daniel Vetter
Cc: Bartlomiej Zolnierkiewicz
Cc: Hans de Goede
Cc: Daniel Vetter
Cc: Greg Kroah-Hartman
Cc: Kees Cook
Cc: Nicolas Pitre
---
drivers/video/console/dum
Just drive-by, nothing systematic yet.
Signed-off-by: Daniel Vetter
Cc: Bartlomiej Zolnierkiewicz
Cc: Daniel Vetter
Cc: "Michał Mirosław"
Cc: Peter Rosin
Cc: Hans de Goede
Cc: Thomas Zimmermann
Cc: Manfred Schlaegl
Cc: Mikulas Patocka
Cc: Kees Cook
---
drivers/video/fbdev/core/fbmem.c |
I honestly have no idea what the subtle differences between
con_is_visible, con_is_fg (internal to vt.c) and con_is_bound are. But
it looks like both vc->vc_display_fg and con_driver_map are protected
by the console_lock, so probably better if we hold that when checking
this.
To do that I had to d
With
commit 6104c37094e729f3d4ce65797002112735d49cd1
Author: Daniel Vetter
Date: Tue Aug 1 17:32:07 2017 +0200
fbcon: Make fbcon a built-time depency for fbdev
we have a static dependency between fbcon and fbdev, and we can
replace the indirection through the notifier chain with a functio
Motivated because it contains a struct display, which is a fbcon
internal data structure that I want to rename. It seems to have been
formerly used in drivers, but that's very long time ago.
Signed-off-by: Daniel Vetter
Cc: Paul Mackerras
Cc: linux-fb...@vger.kernel.org
---
drivers/video/fbdev/
Entirely unused.
Signed-off-by: Daniel Vetter
Cc: Russell King
Cc: linux-arm-ker...@lists.infradead.org
---
drivers/video/fbdev/cyber2000fb.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/fbdev/cyber2000fb.c
b/drivers/video/fbdev/cyber2000fb.c
index 9a5751cb4e16..452ef07b3a0
For symmetry reasons with do_unblank_screen, except without the
oops_in_progress special case.
Just a drive-by annotation while I'm trying to untangle the fbcon vs.
fbdev screen blank/unblank maze.
Signed-off-by: Daniel Vetter
Cc: Greg Kroah-Hartman
Cc: Nicolas Pitre
Cc: Adam Borowski
Cc: Mar
It's properly protected by reboot_lock.
Signed-off-by: Daniel Vetter
Cc: Mikulas Patocka
Cc: "David S. Miller"
Cc: "Ville Syrjälä"
Cc: Bartlomiej Zolnierkiewicz
Cc: Daniel Vetter
---
drivers/video/fbdev/aty/atyfb_base.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/d
Which means lock_fb_info can never fail. Remove the error handling.
Signed-off-by: Daniel Vetter
Cc: Daniel Vetter
Cc: Bartlomiej Zolnierkiewicz
Cc: Rob Clark
---
drivers/video/fbdev/core/fbsysfs.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/video/fb
Motivated because it contains a struct display, which is a fbcon
internal data structure that I want to rename. It seems to have been
formerly used in drivers, but that's very long time ago.
Signed-off-by: Daniel Vetter
Cc: Daniel Vetter
---
drivers/video/fbdev/sa1100fb.c | 25 -
This was formerly used in fbdev drivers (not sure why, predates most
git history), but now it's entirely an fbcon internal thing. Give it a
more specific name.
Signed-off-by: Daniel Vetter
Cc: Bartlomiej Zolnierkiewicz
Cc: Daniel Vetter
Cc: Hans de Goede
Cc: Greg Kroah-Hartman
Cc: Kees Cook
This is unused code since
commit 6104c37094e729f3d4ce65797002112735d49cd1
Author: Daniel Vetter
Date: Tue Aug 1 17:32:07 2017 +0200
fbcon: Make fbcon a built-time depency for fbdev
when fbcon was made a compile-time static dependency of fbdev. We
can't exit fbcon anymore without exiting f
Which means lock_fb_info can never fail. Remove the error handling.
Signed-off-by: Daniel Vetter
Cc: Daniel Vetter
---
.../video/fbdev/omap2/omapfb/omapfb-sysfs.c | 21 +++
1 file changed, 7 insertions(+), 14 deletions(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/omapfb-s
With all the work I've done on replacing fb notifier calls with direct
calls into fbcon the backlight/lcd notifier is the only user left.
It will only receive events now that it cares about, hence we can
remove this check.
Signed-off-by: Daniel Vetter
Cc: Lee Jones
Cc: Daniel Thompson
Cc: Jing
Quoting Tvrtko Ursulin (2019-05-24 09:51:46)
>
> On 24/05/2019 09:36, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-05-24 09:31:45)
> >>
> >> On 24/05/2019 09:29, Chris Wilson wrote:
> >>> Quoting Tvrtko Ursulin (2019-05-24 09:23:40)
>
> On 24/05/2019 09:17, Chris Wilson wrote:
>
It's not pretty.
Signed-off-by: Daniel Vetter
Cc: Daniel Vetter
Cc: Bartlomiej Zolnierkiewicz
Cc: Hans de Goede
Cc: Yisheng Xie
---
drivers/video/fbdev/core/fbcon.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev
Pretty simple case really.
v2: Forgot to remove a break;
v3: Add static inline to the dummy versions.
Signed-off-by: Daniel Vetter
Cc: Bartlomiej Zolnierkiewicz
Cc: Daniel Vetter
Cc: Hans de Goede
Cc: "Steven Rostedt (VMware)"
Cc: Prarit Bhargava
Cc: Kees Cook
Cc: Yisheng Xie
Cc: "Michał
For some reasons the pm_vt_switch_unregister call was missing from the
direct unregister_framebuffer path. Fix this.
v2: fbinfo->dev is used to decided whether unlink_framebuffer has been
called already. I botched that in v1. Make this all clearer by
inlining __unlink_framebuffer.
v3: Fix typoe i
this driver is pretty horrible from a design pov, and needs a complete
overhaul. Concrete thing that annoys me is that it looks at
registered_fb, which is an internal thing to fbmem.c and fbcon.c. And
ofc it gets the lifetime rules all wrong (it should at least use
get/put_fb_info).
Looking at the
Instead of wiring almost everything down to the very last line using
goto soup (but not consistently, where would the fun be otherwise)
drop out early when checks fail. This allows us to flatten the huge
indent levels to just 1.
Aside: If a driver doesn't set ->fb_check_var, then FB_ACTIVATE_NOW
d
There's a callchain of:
fbcon_fb_blaned -> do_(un)blank_screen -> consw->con_blank
-> fbcon_blank -> fb_blank
Things don't go horribly wrong because the BKL console_lock safes the
day, but that's about it. And the seeming recursion is broken in 2
ways:
- Starting from the fbdev ioctl we s
With the recursion broken in the previous patch we can drop the
FBINFO_MISC_USEREVENT flag around calls to fb_blank - recursion
prevention was it's only job.
Signed-off-by: Daniel Vetter
Cc: Daniel Vetter
Cc: Bartlomiej Zolnierkiewicz
Cc: Hans de Goede
Cc: Yisheng Xie
Cc: "Michał Mirosław"
C
While at it, clean up the interface a bit and push the console locking
into fbcon.c.
v2: Remove now outdated comment (Lukas).
v3: Forgot to add static inline to the dummy function.
Acked-by: Lukas Wunner
Signed-off-by: Daniel Vetter
Cc: Lukas Wunner
Cc: David Airlie
Cc: Daniel Vetter
Cc: Ma
drm-misc-next-2019-05-24:
drm-misc-next for v5.3, try #2:
Cross-subsystem Changes:
- Fix device tree bindings in drm-misc-next after a botched merge.
Core Changes:
- Docbook fix for drm_hdmi_infoframe_set_hdr_metadata.
Driver Changes:
- mediatek: Fix compiler warning after merging the HDR series
With the sh_mobile notifier removed we can just directly call the
fbcon code here.
v2: Remove now unused local variable.
v3: fixup !CONFIG_FRAMEBUFFER_CONSOLE, noticed by kbuild
Signed-off-by: Daniel Vetter
Cc: Bartlomiej Zolnierkiewicz
Cc: Daniel Vetter
Cc: Hans de Goede
Cc: Greg Kroah-Hart
Create a new wrapper function for this, feels like there's some
refactoring room here between the two modes.
v2: backlight notifier is also interested in the mode change event,
it calls lcd->set_mode, of which there are 3 implementations. Thanks
to Maarten for spotting this. So we keep that. We ca
This reverts commit 994efacdf9a087b52f71e620b58dfa526b0cf928.
The justification is that if hw blanking fails (i.e. fbops->fb_blank)
fails, then we still want to shut down the backlight. Which is exactly
_not_ what fb_blank() does and so rather inconsistent if we end up
with different behaviour bet
It's dead code, and removing it avoids me having to understand
what it's doing with lock_fb_info.
Signed-off-by: Daniel Vetter
Reviewed-by: Geert Uytterhoeven
Cc: Geert Uytterhoeven
Cc: Daniel Vetter
---
drivers/video/fbdev/sh_mobile_lcdcfb.c | 63 --
drivers/video/fbd
Simply because olpc never unregisters the damn thing. It also
registers the framebuffer directly by poking around in fbdev
core internals, so it's all around rather broken.
Signed-off-by: Daniel Vetter
Cc: Jens Frederich
Cc: Daniel Drake
Cc: Jon Nettleton
---
drivers/staging/olpc_dcon/olpc_dc
This seems to be entirely defunct:
- The FB_EVEN_SUSPEND/RESUME events are only sent out by
fb_set_suspend. Which is supposed to be called by drivers in their
suspend/resume hooks, and not itself call into drivers. Luckily
sh_mob doesn't call fb_set_suspend, so this seems to do nothing
use
Also remove the error return value. That's all errors for either
driver bugs (trying to unbind something that isn't bound), or errors
of the new driver that will take over.
There's nothing the outgoing driver can do about this anyway, so
switch over to void.
Signed-off-by: Daniel Vetter
Cc: Bart
These are actually fbcon ioctls which just happen to be exposed
through /dev/fb*. They completely ignore which fb_info they're called
on, and I think the userspace tool even hardcodes to /dev/fb0.
Hence just forward the entire thing to fbcon.c wholesale.
Note that this patch drops the fb_lock/unl
Ever since
commit c47747fde931c02455683bd00ea43eaa62f35b0e
Author: Linus Torvalds
Date: Wed May 11 14:58:34 2011 -0700
fbmem: make read/write/ioctl use the frame buffer at open time
fbdev has gained proper refcounting for the fbinfo attached to any
open files, which means that the backing
I'm not entirely clear on what new_modelist actually does, it seems
exclusively for a sysfs interface. Which in the end does amount to a
normal fb_set_par to check the mode, but then takes a different path
in both fbmem.c and fbcon.c.
I have no idea why these 2 paths are different, but then I also
Except for driver bugs (which we'll catch with a WARN_ON) this is only
to report failures of the new driver taking over the console. There's
nothing the outgoing driver can do about that, and no one ever
bothered to actually look at these return values. So remove them all.
v2: fixup unregister_fra
On 24/05/2019 09:51, Tvrtko Ursulin wrote:
On 24/05/2019 09:36, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-05-24 09:31:45)
On 24/05/2019 09:29, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-05-24 09:23:40)
On 24/05/2019 09:17, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-05-
Quoting Tvrtko Ursulin (2019-05-24 09:57:42)
>
> On 24/05/2019 09:51, Tvrtko Ursulin wrote:
> >
> > On 24/05/2019 09:36, Chris Wilson wrote:
> >> Quoting Tvrtko Ursulin (2019-05-24 09:31:45)
> >>>
> >>> On 24/05/2019 09:29, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2019-05-24 09:23:40)
>
Quoting Mika Kuoppala (2019-05-24 09:03:00)
> Chris Wilson writes:
>
> > From: Dongwon Kim
> >
> > Setting bit5 (headerless msg for preemptable GPGPU context) of SAMPLER_MODE
> > register to enable support for the headless msgs on gen11. None of existing
> > use cases will be affected by this as
On 24/05/2019 10:01, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-05-24 09:57:42)
On 24/05/2019 09:51, Tvrtko Ursulin wrote:
On 24/05/2019 09:36, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-05-24 09:31:45)
On 24/05/2019 09:29, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-05-
On 21/05/2019 17:36, Chris Wilson wrote:
Quoting Lionel Landwerlin (2019-05-21 15:08:52)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index f263a8374273..2ad95977f7a8 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_l
On 24/05/2019 09:45, Chris Wilson wrote:
Apparently VLA structs (e.g. struct { int array[count] }) is a gcc
extension that clang refuses to support as handling memory layout is too
difficult for it. So calculate the size by hand!
v2: Use alloca().
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursuli
Quoting Lionel Landwerlin (2019-05-24 10:28:16)
> On 21/05/2019 17:36, Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2019-05-21 15:08:52)
> >> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> >> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> >> index f263a8374273..2ad95977f7a8 100644
> >> --- a/dr
On 24/05/2019 10:42, Chris Wilson wrote:
Quoting Lionel Landwerlin (2019-05-24 10:28:16)
On 21/05/2019 17:36, Chris Wilson wrote:
Quoting Lionel Landwerlin (2019-05-21 15:08:52)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index f263a8374273..2ad95977
Quoting Lionel Landwerlin (2019-05-24 10:51:49)
> On 24/05/2019 10:42, Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2019-05-24 10:28:16)
> >> On 21/05/2019 17:36, Chris Wilson wrote:
> >>> Quoting Lionel Landwerlin (2019-05-21 15:08:52)
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
== Series Details ==
Series: fbcon notifier begone! (rev3)
URL : https://patchwork.freedesktop.org/series/60843/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
9f0a699de21c dummycon: Sprinkle locking checks
-:45: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal
== Series Details ==
Series: fbcon notifier begone! (rev3)
URL : https://patchwork.freedesktop.org/series/60843/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: dummycon: Sprinkle locking checks
Okay!
Commit: fbdev: locking check for fb_set_suspend
Oka
== Series Details ==
Series: fbcon notifier begone! (rev3)
URL : https://patchwork.freedesktop.org/series/60843/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6140 -> Patchwork_13088
Summary
---
**SUCCESS**
No reg
On Thu, May 23, 2019 at 06:53:20PM +0200, Sam Ravnborg wrote:
> Hi Linus, Gerd.
>
> > This moves the modesetting code from drm_fb_helper to drm_client so it
> > can be shared by all internal clients.
>
> Could one of you take a look at this series.
> Daniel already ack'ed the series on irc, but a
Prior to this commit we fail to init the DSI panel on the GPD MicroPC:
https://www.indiegogo.com/projects/gpd-micropc-6-inch-handheld-industry-laptop#/
The problem is intel_dsi_vbt_init() failing with the following error:
*ERROR* Burst mode freq is less than computed
The pclk in the VBT panel mod
Quoting Ye, Tony (2019-05-22 14:32:41)
> From UMD perspective, when HuC is not working as expected, usually we
> look into the kernel log and i915_huc_load_status debugfs to find out
> why it's not working. It will be helpful to know the reason of the
> failure from the error code. The typicall
On Fri, May 24, 2019 at 10:53:45AM +0200, Daniel Vetter wrote:
> This reverts commit 994efacdf9a087b52f71e620b58dfa526b0cf928.
>
> The justification is that if hw blanking fails (i.e. fbops->fb_blank)
> fails, then we still want to shut down the backlight. Which is exactly
> _not_ what fb_blank()
== Series Details ==
Series: drm/i915/dsi: Use a fuzzy check for burst mode clock check
URL : https://patchwork.freedesktop.org/series/61105/
State : failure
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
DESCEND objtool
CHK include/generated/
On Fri, 24 May 2019 15:10:58 +0200, Joonas Lahtinen
wrote:
Quoting Ye, Tony (2019-05-22 14:32:41)
From UMD perspective, when HuC is not working as expected, usually we
look into the kernel log and i915_huc_load_status debugfs to find out
why it's not working. It will be helpful to know the
Check the right engine to see if it is the one that explodes!
Fixes: 88318b0771f9 ("test/i915: gem_busy: use the gem_engine_topology library")
Signed-off-by: Chris Wilson
Cc: Andi Shyti
Cc: Tvrtko Ursulin
---
tests/i915/gem_busy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --g
> - if (!gem_class_can_store_dword(fd, e->class))
> + if (!gem_class_can_store_dword(fd, e2->class))
> continue;
ops!
Reviewed-by: Andi Shyti
Thanks,
Andi
> igt_debug("Testing %s in parallel\n", e2->nam
Hi,
On 5/24/19 3:06 PM, Hans de Goede wrote:
Prior to this commit we fail to init the DSI panel on the GPD MicroPC:
https://www.indiegogo.com/projects/gpd-micropc-6-inch-handheld-industry-laptop#/
The problem is intel_dsi_vbt_init() failing with the following error:
*ERROR* Burst mode freq is l
Do not allow runtime pm autosuspend to remove userspace GGTT mmaps too
quickly. For example, igt sets the autosuspend delay to 0, and so we
immediately attempt to perform runtime suspend upon releasing the
wakeref. Unfortunately, that involves tearing down GGTT mmaps as they
require an active devic
On Thu, May 23, 2019 at 6:53 PM Sam Ravnborg wrote:
> Could one of you take a look at this series.
> Daniel already ack'ed the series on irc, but an extra pair of eyes
> is never bad.
I would if I had a chance of understanding them. I am still pretty
novice with DRM so what I do is trace down to
On Tue, May 21, 2019 at 07:12:28PM +0530, Sharma, Swati2 wrote:
> On 14-May-19 9:40 PM, Ville Syrjälä wrote:
>
> > On Tue, May 14, 2019 at 03:13:21PM +0530, Swati Sharma wrote:
> >> v3: -Rebase
> >> v4: -Renamed intel_compare_color_lut() to intel_color_lut_equal() [Jani]
> >> -Added the defau
Hi Linus.
Thanks for the response.
> > Could one of you take a look at this series.
> > Daniel already ack'ed the series on irc, but an extra pair of eyes
> > is never bad.
>
> I would if I had a chance of understanding them. I am still pretty
> novice with DRM so what I do is trace down to the
Hi Daniel,
On Fri, May 24, 2019 at 3:14 PM Daniel Thompson
wrote:
>
> On Fri, May 24, 2019 at 10:53:45AM +0200, Daniel Vetter wrote:
> > This reverts commit 994efacdf9a087b52f71e620b58dfa526b0cf928.
> >
> > The justification is that if hw blanking fails (i.e. fbops->fb_blank)
> > fails, then we s
Do not allow runtime pm autosuspend to remove userspace GGTT mmaps too
quickly. For example, igt sets the autosuspend delay to 0, and so we
immediately attempt to perform runtime suspend upon releasing the
wakeref. Unfortunately, that involves tearing down GGTT mmaps as they
require an active devic
From: Ville Syrjälä
ICL has so many planes that it can easily exceed the maximum
effective memory bandwidth of the system. We must therefore check
that we don't exceed that limit.
The algorithm is very magic number heavy and lacks sufficient
explanation for now. We also have no sane way to query
This patch series contains a few code clean-up patches, followed
by a patch which changes the storage of the subslice mask to better
match the userspace access through the I915_QUERY_TOPOLOGY_INFO
ioctl. The index into the subslice_mask array is then calculated:
slice * subslice stride + subslice
Add a new function to return the number of subslices per slice to
consolidate code usage.
v2: rebase on changes to move sseu struct to intel_sseu.h
v3: add intel_* prefix to sseu_subslices_per_slice
Cc: Daniele Ceraolo Spurio
Reviewed-by: Daniele Ceraolo Spurio
Signed-off-by: Stuart Summers
--
Subslice stride and EU stride are calculated multiple times in
i915_query. Move this calculation to a macro to reduce code duplication.
v2: update headers in intel_sseu.h
v3: use GEN_SSEU_STRIDE for stride calculations in intel_sseu.h
apply s/bits/max_entries/ to GEN_SSEU_STRIDE parameter
Cc:
In the GETPARAM ioctl handler, use a local variable to consolidate
usage of SSEU runtime info.
v2: add const to sseu_dev_info variable
Cc: Daniele Ceraolo Spurio
Reviewed-by: Daniele Ceraolo Spurio
Signed-off-by: Stuart Summers
---
drivers/gpu/drm/i915/i915_drv.c | 11 ++-
1 file chan
Currently, the subslice_mask runtime parameter is stored as an
array of subslices per slice. Expand the subslice mask array to
better match what is presented to userspace through the
I915_QUERY_TOPOLOGY_INFO ioctl. The index into this array is
then calculated:
slice * subslice stride + subslice i
Move functions to intel_sseu.h and remove inline qualifier.
Additionally, ensure these are all prefixed with intel_sseu_*
to match the convention of other functions in i915.
v2: fix spacing from checkpatch warning
v3: squash helper function changes into a single patch
break 80 character line t
Chris Wilson writes:
> Do not allow runtime pm autosuspend to remove userspace GGTT mmaps too
> quickly. For example, igt sets the autosuspend delay to 0, and so we
> immediately attempt to perform runtime suspend upon releasing the
> wakeref. Unfortunately, that involves tearing down GGTT mmaps
On 23/05/2019 16:08, Imre Deak wrote:
> An IO failure happens if the sink is unplugged. This scenario shouldn't
> be logged with error level, since it is not a user visible problem.
> Converting the corresponding error messages to be debug messages also
> ensures that we don't fail some CI test inc
Hi All,
This is a resend of my 3th attempt to fix the pclk we calculate for
DSI panels and the pclk which the GOP has configured, causing fastboot
to not work.
As requested in the review of earlier versions, this version moves the
overriding of the pclk out of intel_dsi_vbt.c and into vlv_dsi.c.
The GOP sometimes initializes the pclk at a (slightly) different frequency
then the pclk which we've calculated.
This commit makes the DSI code read-back the pclk set by the GOP and
if that is within a reasonable margin of the calculated pclk, uses
that instead.
This fixes the first modeset being
The next patch in this series uses intel_fuzzy_clock_check from the
vlv_dsi.c code.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
drivers/gpu/drm/i915/intel_drv.h | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_d
The vlv/icl_dphy_param_init calls do various calculations to set dphy
parameters based on the pclk.
Move the calling of vlv/icl_dphy_param_init to vlv_dsi_init to give
vlv_dsi_init a chance to tweak the pclk before these calculations are done.
This also removes the single "if (IS_ICELAKE(dev_priv
This is a preparation patch for moving the calling of *_dphy_param_init()
out of intel_dsi_vbt_init.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/intel_dsi_vbt.c | 77 +++-
1 file changed, 42 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel
If we exit vlv_dsi_init() because we failed to find a fixed_mode, then
we've already called drm_connector_init() and we should call
drm_connector_cleanup() to unregister the connector object.
Reviewed-by: Ville Syrjälä
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/vlv_dsi.c | 4 +++-
1
On Fri, May 24, 2019 at 07:27:54PM +0300, Martin Peres wrote:
> On 23/05/2019 16:08, Imre Deak wrote:
> > An IO failure happens if the sink is unplugged. This scenario shouldn't
> > be logged with error level, since it is not a user visible problem.
> > Converting the corresponding error messages t
Atm AUX-B transfers can fail with the following error if AUX-A is not
enabled:
[ 594.594108] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status
0x7c2003ff
[ 594.615854] [drm:intel_dp_aux_xfer [i915]] *ERROR* dp aux hw did not signal
timeout!
[ 594.632851] [drm:intel_dp_aux_xfer [i915]] *
>-Original Message-
>From: Wajdeczko, Michal
>Sent: Thursday, May 23, 2019 4:31 PM
>To: intel-gfx@lists.freedesktop.org
>Cc: Wajdeczko, Michal ; Ceraolo Spurio, Daniele
>; Srivatsa, Anusha
>
>Subject: [PATCH v4 11/22] drm/i915/guc: Define GuC firmware version for
>Geminilake
>
>Define GuC
1 - 100 of 124 matches
Mail list logo
