Re: [Intel-gfx] [PATCH v5 4/8] drm/cma-helper: Use the generic fbdev emulation
On Tue, Aug 21, 2018 at 8:43 PM, John Stultz wrote: > On Tue, Aug 21, 2018 at 7:59 AM, Noralf Trønnes wrote: >> Den 21.08.2018 10.44, skrev Daniel Vetter: >>> On Mon, Aug 20, 2018 at 11:44:56PM -0700, John Stultz wrote: Since we don't have a drm_gem_cma_object reference in drm_fb_helper_generic_probe(), I instead added: fbi->fix.smem_start = page_to_phys(virt_to_page(fbi->screen_buffer)); And that got things working! So yea, I wanted to figure out if we are just missing the line above in drm_fb_helper_generic_probe()? Or if the kirin driver should be setting the fix.smem_start in some other fashion? >>> >>> With the generic helpers we can't use the generic fb_mmap() implementation >>> in fbdev/core/fbmem.c anymore. Instead Noralf added a generic fb_mmap >>> fb_ops callback in drm_fbdev_fb_mmap, which you're supposed to use. Can >>> you pls double-check that this is wired up correctly for kirin? >>> >>> At least I don't see any other place where we use smem_start in the fbdev >>> code. It does get copied to userspace, but userspace should never use >>> that. >> >> >> I googled 'FBIOGET_FSCREENINFO smem_start' and came across info[1] >> about the Mali blob using it and HiKey seems to have a Mali GPU: >> >> 00:17 BorgCuba: >> the mali blob is supposed to open the framebuffer device, >> get "smem_start" and try to map this memory via MALI_IOC_MEM_MAP_EXT ioctl >> >> Could this be the problem here? > > It does look like that's the case. Looking for smem_start usage, for > Android its the gralloc code that fetches it: > > https://android.googlesource.com/device/linaro/hikey/+/master/gralloc/framebuffer_device.cpp#353 > and then puts it into the private_handle_t: > > https://android.googlesource.com/device/linaro/hikey/+/master/gralloc/framebuffer_device.cpp#384 > > Which I assume then gets used later in the opaque mali blob (which > then results in a similarly opaque hang). > > While I'm perfectly understanding that folks are not interested as its > related to mali (which is fine, I can carry a patch - working to move > away from fbdev emulation anyway), I am wondering if it might cause > trouble for other users, as smem_start was previously set and now its > not, so it seems likely to break userspace examples like: >https://www.linuxtv.org/downloads/v4l-dvb-apis-old/osd.html > > Or are those such old legacy they don't really count? We've been pretty strict in drm about never ever exposing any physical offsets to userspace. I'm mildly tempted to plug this even more if possible, to stop more abuse. If you want mmap, fbdev has that. If you want buffer sharing, use drm. Don't do buffer sharing by passing physical addresses around in userspace, that idea is dead since about 8 years (back when we've done the initial dma-buf discussions). So yeah, not going to care one bit here :-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 1/2] Increase the string size for a module name
On Tue, Aug 21, 2018 at 10:57:47AM -0300, Rodrigo Siqueira wrote:
> On 08/21, Petri Latvala wrote:
> > On Sat, Jul 07, 2018 at 08:24:39PM -0300, Rodrigo Siqueira wrote:
> > > Some modules name are larger than 5 characters, this can be a problem to
> > > add support for other modules. This patch, increase the maximum size in
> > > order to enable other modules to use IGT.
> > >
> > > Signed-off-by: Rodrigo Siqueira
> > > ---
> > > lib/drmtest.c | 6 --
> > > 1 file changed, 4 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/lib/drmtest.c b/lib/drmtest.c
> > > index fae6f86f..eee733eb 100644
> > > --- a/lib/drmtest.c
> > > +++ b/lib/drmtest.c
> > > @@ -60,6 +60,8 @@
> > > #include "ioctl_wrappers.h"
> > > #include "igt_dummyload.h"
> > >
> > > +#define NAME_LEN 32
> > > +
> > > /**
> > > * SECTION:drmtest
> > > * @short_description: Base library for drm tests and tools
> > > @@ -82,7 +84,7 @@ static int __get_drm_device_name(int fd, char *name)
> > > drm_version_t version;
> > >
> > > memset(&version, 0, sizeof(version));
> > > - version.name_len = 4;
> > > + version.name_len = NAME_LEN;
> > > version.name = name;
> > >
> > > if (!drmIoctl(fd, DRM_IOCTL_VERSION, &version)){
> > > @@ -94,7 +96,7 @@ static int __get_drm_device_name(int fd, char *name)
> > >
> > > static bool __is_device(int fd, const char *expect)
> > > {
> > > - char name[5] = "";
> > > + char name[NAME_LEN] = "";
> >
> > This would need to be NAME_LEN + 1 to have room for the
> > null-termination.
> >
> > But, is this patch really necessary? Are there false matches from
> > using a substring of 4 to match driver names?
>
> Hi,
>
> To test the force option, I used two drivers: Bochs and VKMS. I noticed
> that Bochs failed to load because the module name is "bochs-drm".
Driver name is still not the same as the kernel module name necessarily.
> Additionally, if we want to add a force option, I assume that someone
> can have a module name larger than four characters. Make sense? Or Did I
> missed something?
Sure, names can and are already larger than four characters
(e.g. "amdgpu"). But the driver matching uses the first four
characters of the name. The length of matching the driver name doesn't
need to be lengthened as of yet.
Kernel module name, again, is another thing entirely.
--
Petri Latvala
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 2/2] Add support for forcing specific module
On Tue, Aug 21, 2018 at 11:22:45AM -0300, Rodrigo Siqueira wrote:
> On 08/21, Petri Latvala wrote:
> > On Sat, Jul 07, 2018 at 08:25:07PM -0300, Rodrigo Siqueira wrote:
> > > This commit adds a new option for forcing the use of a specific module
> > > indicated via command line. The force command expects a module name
> > > which will be used on the target test (changing the standard behavior).
> > >
> > > Signed-off-by: Rodrigo Siqueira
> > > ---
> > > lib/drmtest.c| 33 +++--
> > > lib/igt_core.c | 23 +++
> > > lib/igt_core.h | 4
> > > scripts/run-tests.sh | 4 +++-
> > > 4 files changed, 57 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/lib/drmtest.c b/lib/drmtest.c
> > > index eee733eb..a77e2231 100644
> > > --- a/lib/drmtest.c
> > > +++ b/lib/drmtest.c
> > > @@ -247,6 +247,20 @@ static int __open_device(const char *base, int
> > > offset, unsigned int chipset)
> > > if (chipset & DRIVER_AMDGPU && is_amd_device(fd))
> > > return fd;
> > >
> > > + // Force options
> > > + if (get_target_module() && chipset == DRIVER_ANY) {
> > > + if (__is_device(fd, get_target_module())) {
> > > + return fd;
> > > + }
> > > + else {
> > > + memset(name, 0, sizeof(name));
> > > + __get_drm_device_name(fd, name);
> > > + close(fd);
> > > + igt_kmod_unload(name, 0);
> > > + return -1;
> > > + }
> > > + }
> > > +
> >
> >
> > You're unloading modules (which you shouldn't need to do here anyway),
> > and even worse, unloading them if the first loop iteration doesn't
> > land on the forced name.
> >
> > This chunk needs to be before the matches for the known bits for
> > DRIVER_ANY or you'll just get one of them when forcing a custom name.
> Hi,
>
> I think I did not fully understand your point; I'm a little bit confused
> with this part:
>
> "[..] or you'll just get one of them when forcing a custom name."
>
> Do we want more than one?
I mean that when a test calls drm_open_driver(DRIVER_ANY), it will
happily open /dev/dri/card0 and use that if it's, say, an i915
device. Even though you enabled the force option to "vkms".
>
> >
> > > /* Only VGEM-specific tests should be run on VGEM */
> > > if (chipset == DRIVER_ANY && !is_vgem_device(fd))
> > > return fd;
> > > @@ -260,6 +274,7 @@ static int __open_device(const char *base, int
> > > offset, unsigned int chipset)
> > > static int __open_driver(const char *base, int offset, unsigned int
> > > chipset)
> > > {
> > > static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
> > > + const char* target;
> > > static const struct module {
> > > unsigned int bit;
> > > const char *module;
> > > @@ -278,13 +293,19 @@ static int __open_driver(const char *base, int
> > > offset, unsigned int chipset)
> > > if (fd != -1)
> > > return fd;
> > >
> > > + target = get_target_module();
> > > +
> > > pthread_mutex_lock(&mutex);
> > > - for (const struct module *m = modules; m->module; m++) {
> > > - if (chipset & m->bit) {
> > > - if (m->modprobe)
> > > - m->modprobe(m->module);
> > > - else
> > > - modprobe(m->module);
> > > + if (target) {
> > > + modprobe(target);
> > > + } else {
> >
> >
> > The name of the driver (as returned by DRM_IOCTL_VERSION) doesn't have
> > to match the kernel module filename. Case in point: virtio-gpu.ko is
> > "virtio_gpu".
> >
> > I would suggest leaving the kernel module loading plans later for now
> > and get the DRIVER_ANY match forcing in place. Or even forget kernel
> > module loading entirely. If the user is able to set a parameter to a
> > module name, the user can load the module themselves before running
> > tests. It won't get unloaded if IGT doesn't have a test that does it,
> > and it won't have such a test unless it knows about the
> > driver/module. And at that point, IGT will know how to load that
> > module.
>
> Basically, leave the modprobe part for the user, Right?
Exactly.
>
> >
> >
> > > + for (const struct module *m = modules; m->module; m++) {
> > > + if (chipset & m->bit) {
> > > + if (m->modprobe)
> > > + m->modprobe(m->module);
> > > + else
> > > + modprobe(m->module);
> > > + }
> > > }
> > > }
> > > pthread_mutex_unlock(&mutex);
> > > diff --git a/lib/igt_core.c b/lib/igt_core.c
> > > index 5092a3f0..ee085e2a 100644
> > > --- a/lib/igt_core.c
> > > +++ b/lib/igt_core.c
> > > @@ -286,6 +286,7 @@ enum {
> > > OPT_DESCRIPTI
Re: [Intel-gfx] [RFC v4 3/8] drm: Add Plane CTM property
fre 2018-08-17 klockan 19:48 +0530 skrev Uma Shankar:
> Add a blob property for plane CSC usage.
>
> v2: Rebase
>
> v3: Fixed Sean, Paul's review comments. Moved the property from
> mode_config to drm_plane. Created a helper function to instantiate
> these properties and removed from drm_mode_create_standard_properties
> Added property documentation as suggested by Daniel, Vetter.
>
> v4: Rebase
>
> Signed-off-by: Uma Shankar
> ---
> Documentation/gpu/drm-kms.rst | 3 +++
> drivers/gpu/drm/drm_atomic.c| 10 ++
> drivers/gpu/drm/drm_atomic_helper.c | 4
> drivers/gpu/drm/drm_plane.c | 12
> include/drm/drm_plane.h | 15 +++
> 5 files changed, 44 insertions(+)
>
> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-
> kms.rst
> index 8b10b12..16d6d8d 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -560,6 +560,9 @@ Plane Color Management Properties
> .. kernel-doc:: drivers/gpu/drm/drm_plane.c
> :doc: degamma_lut_size_property
>
> +.. kernel-doc:: drivers/gpu/drm/drm_plane.c
> + :doc: ctm_property
> +
> Tile Group Property
> ---
>
> diff --git a/drivers/gpu/drm/drm_atomic.c
> b/drivers/gpu/drm/drm_atomic.c
> index f8cad9b..ddda935 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -917,6 +917,14 @@ static int drm_atomic_plane_set_property(struct
> drm_plane *plane,
> &replaced);
> state->color_mgmt_changed |= replaced;
> return ret;
> + } else if (property == plane->ctm_property) {
> + ret = drm_atomic_replace_property_blob_from_id(dev,
> + &state->ctm,
> + val,
> + sizeof(struct
> drm_color_ctm), -1,
> + &replaced);
> + state->color_mgmt_changed |= replaced;
> + return ret;
> } else if (plane->funcs->atomic_set_property) {
> return plane->funcs->atomic_set_property(plane,
> state,
> property, val);
> @@ -988,6 +996,8 @@ static int drm_atomic_plane_set_property(struct
> drm_plane *plane,
> } else if (property == plane->degamma_lut_property) {
> *val = (state->degamma_lut) ?
> state->degamma_lut->base.id : 0;
> + } else if (property == plane->ctm_property) {
> + *val = (state->ctm) ? state->ctm->base.id : 0;
> } else if (plane->funcs->atomic_get_property) {
> return plane->funcs->atomic_get_property(plane,
> state, property, val);
> } else {
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 67c5b51..866181f 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -3616,6 +3616,9 @@ void
> __drm_atomic_helper_plane_duplicate_state(struct drm_plane *plane,
>
> if (state->degamma_lut)
> drm_property_blob_get(state->degamma_lut);
> + if (state->ctm)
> + drm_property_blob_get(state->ctm);
> +
> state->color_mgmt_changed = false;
> }
> EXPORT_SYMBOL(__drm_atomic_helper_plane_duplicate_state);
> @@ -3663,6 +3666,7 @@ void
> __drm_atomic_helper_plane_destroy_state(struct drm_plane_state
> *state)
> drm_crtc_commit_put(state->commit);
>
> drm_property_blob_put(state->degamma_lut);
> + drm_property_blob_put(state->ctm);
> }
> EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
>
> diff --git a/drivers/gpu/drm/drm_plane.c
> b/drivers/gpu/drm/drm_plane.c
> index 03e0560..97520b1 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -489,6 +489,11 @@ int drm_mode_plane_set_obj_prop(struct drm_plane
> *plane,
> *
> * degamma_lut_size_property:
> * Range Property to indicate size of the plane degamma LUT.
> + *
> + * ctm_property:
> + * Blob property which allows a userspace to provide CTM
> coefficients
> + * to do color space conversion or any other enhancement by
> doing a
> + * matrix multiplication using the h/w CTM processing engine
> */
> int drm_plane_color_create_prop(struct drm_device *dev,
> struct drm_plane *plane)
> @@ -509,6 +514,13 @@ int drm_plane_color_create_prop(struct
> drm_device *dev,
> return -ENOMEM;
> plane->degamma_lut_size_property = prop;
>
> + prop = drm_property_create(dev,
> + DRM_MODE_PROP_BLOB,
> + "PLANE_CTM", 0);
> + if (!prop)
> + return -ENOMEM;
> + plane->ctm_property = prop;
> +
> return 0;
> }
> EXPORT_SYMBOL(drm_plane_color_create_prop);
> diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
> index 28357ac..5143277 100644
> --- a/include/drm/drm_plane.h
> +++ b/inc
[Intel-gfx] [PATCH 4/4] drm/fb: Stop leaking physical address
For buffer sharing, use dma-buf instead. We can't set smem_start to 0 unconditionally since that's used by the fbdev mmap default implementation. And we have plenty of userspace which would like to keep that working. This might break legit userspace - if it does we need to look at a case-by-cases basis how to handle that. Worst case I expect overrides for only specific drivers, since anything remotely modern should be using dma-buf/prime now (which is about 7 years old now for DRM drivers). This issue was uncovered because Noralf's rework to implement a generic fb_probe also implements it's own fb_mmap callback. Which means smem_start didn't have to be set anymore, which blew up some blob in userspace rather badly. Cc: Gustavo Padovan Cc: Maarten Lankhorst Cc: Sean Paul Cc: David Airlie Cc: John Stultz Cc: Noralf Trønnes Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_fb_helper.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index 4b0dd20bccb8..bcb78693c4f7 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -2673,6 +2673,8 @@ __drm_fb_helper_initial_config_and_unlock(struct drm_fb_helper *fb_helper, info = fb_helper->fbdev; info->var.pixclock = 0; + /* don't leak any physical addresses to userspace */ + info->flags |= FBINFO_HIDE_SMEM_START; /* Need to drop locks to avoid recursive deadlock in * register_framebuffer. This is ok because the only thing left to do is -- 2.18.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/4] fbdev: Drop FBINFO_CAN_FORCE_OUTPUT flag
This was only added for the drm's fbdev emulation support, so that it
would try harder to show the Oops.
Unfortunately this never really worked reliably, and in practice ended
up pushing the real Oops off the screen due to plentyfull locking,
sleep-while-atomic and other issues. So we removed all that support
from the fbdev emulation a while back. Aside: We've also removed the
kgdb support, for similar reasons.
Since it's such a small patch I figured I don't split this up into the
usual 3-phase removal.
Cc: Ben Skeggs
Cc: Bartlomiej Zolnierkiewicz
Cc: Greg Kroah-Hartman
Cc: Hans de Goede
Cc: Daniel Vetter
Cc: Alexander Kapshuk
Cc: Kees Cook
Cc: Thierry Reding
Cc: David Lechner
Cc: nouv...@lists.freedesktop.org
Cc: linux-fb...@vger.kernel.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 1 -
drivers/staging/vboxvideo/vbox_fb.c | 3 +--
drivers/video/fbdev/core/fbcon.c| 1 -
include/linux/fb.h | 4
4 files changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
index 844498c4267c..20a260887be3 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
@@ -379,7 +379,6 @@ nouveau_fbcon_create(struct drm_fb_helper *helper,
info->flags = FBINFO_DEFAULT | FBINFO_HWACCEL_COPYAREA |
FBINFO_HWACCEL_FILLRECT |
FBINFO_HWACCEL_IMAGEBLIT;
- info->flags |= FBINFO_CAN_FORCE_OUTPUT;
info->fbops = &nouveau_fbcon_sw_ops;
info->fix.smem_start = fb->nvbo->bo.mem.bus.base +
fb->nvbo->bo.mem.bus.offset;
diff --git a/drivers/staging/vboxvideo/vbox_fb.c
b/drivers/staging/vboxvideo/vbox_fb.c
index 43c39eca4ae1..034f8ffa8f20 100644
--- a/drivers/staging/vboxvideo/vbox_fb.c
+++ b/drivers/staging/vboxvideo/vbox_fb.c
@@ -155,8 +155,7 @@ static int vboxfb_create(struct drm_fb_helper *helper,
* The last flag forces a mode set on VT switches even if the kernel
* does not think it is needed.
*/
- info->flags = FBINFO_DEFAULT | FBINFO_CAN_FORCE_OUTPUT |
- FBINFO_MISC_ALWAYS_SETPAR;
+ info->flags = FBINFO_DEFAULT | FBINFO_MISC_ALWAYS_SETPAR;
info->fbops = &vboxfb_ops;
/*
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 5fb156bdcf4e..2b5bb52b1798 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -1104,7 +1104,6 @@ static void fbcon_init(struct vc_data *vc, int init)
if (p->userfont)
charcnt = FNTCHARCNT(p->fontdata);
- vc->vc_panic_force_write = !!(info->flags & FBINFO_CAN_FORCE_OUTPUT);
vc->vc_can_do_color = (fb_get_color_depth(&info->var, &info->fix)!=1);
vc->vc_complement_mask = vc->vc_can_do_color ? 0x7700 : 0x0800;
if (charcnt == 256) {
diff --git a/include/linux/fb.h b/include/linux/fb.h
index aa74a228bb92..fa8c6f9c9c3a 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -457,10 +457,6 @@ struct fb_tile_ops {
*/
#define FBINFO_BE_MATH 0x10
-/* report to the VT layer that this fb driver can accept forced console
- output like oopses */
-#define FBINFO_CAN_FORCE_OUTPUT 0x20
-
struct fb_info {
atomic_t count;
int node;
--
2.18.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] vt: Remove vc_panic_force_write
It was only used by the panic support in fbcon, which is now gone.
Remove this now dead code too.
Cc: Greg Kroah-Hartman
Cc: Kees Cook
Cc: Joe Perches
Cc: Daniel Vetter
Cc: Meng Xu
Cc: Nicolas Pitre
Cc: Thomas Meyer
Cc: Mike Frysinger
Cc: Bartlomiej Zolnierkiewicz
Cc: Hans de Goede
Cc: Thierry Reding
Cc: David Lechner
Cc: Philippe Ombredanne
Cc: Thomas Gleixner
Cc: Kate Stewart
Signed-off-by: Daniel Vetter
---
drivers/tty/vt/vt.c | 12
drivers/video/fbdev/core/fbcon.c | 3 +--
include/linux/console_struct.h | 1 -
include/linux/vt_kern.h | 7 ---
4 files changed, 5 insertions(+), 18 deletions(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 15eb6c829d39..6d41b14e4fc7 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -700,9 +700,7 @@ void redraw_screen(struct vc_data *vc, int is_switch)
clear_buffer_attributes(vc);
}
- /* Forcibly update if we're panicing */
- if ((update && vc->vc_mode != KD_GRAPHICS) ||
- vt_force_oops_output(vc))
+ if (update && vc->vc_mode != KD_GRAPHICS)
do_update_region(vc, vc->vc_origin,
vc->vc_screenbuf_size / 2);
}
set_cursor(vc);
@@ -742,7 +740,6 @@ static void visual_init(struct vc_data *vc, int num, int
init)
vc->vc_hi_font_mask = 0;
vc->vc_complement_mask = 0;
vc->vc_can_do_color = 0;
- vc->vc_panic_force_write = false;
vc->vc_cur_blink_ms = DEFAULT_CURSOR_BLINK_MS;
vc->vc_sw->con_init(vc, init);
if (!vc->vc_complement_mask)
@@ -2576,7 +2573,7 @@ static void vt_console_print(struct console *co, const
char *b, unsigned count)
goto quit;
}
- if (vc->vc_mode != KD_TEXT && !vt_force_oops_output(vc))
+ if (vc->vc_mode != KD_TEXT)
goto quit;
/* undraw cursor first */
@@ -3894,8 +3891,7 @@ void do_unblank_screen(int leaving_gfx)
return;
}
vc = vc_cons[fg_console].d;
- /* Try to unblank in oops case too */
- if (vc->vc_mode != KD_TEXT && !vt_force_oops_output(vc))
+ if (vc->vc_mode != KD_TEXT)
return; /* but leave console_blanked != 0 */
if (blankinterval) {
@@ -3904,7 +3900,7 @@ void do_unblank_screen(int leaving_gfx)
}
console_blanked = 0;
- if (vc->vc_sw->con_blank(vc, 0, leaving_gfx) ||
vt_force_oops_output(vc))
+ if (vc->vc_sw->con_blank(vc, 0, leaving_gfx))
/* Low-level driver cannot restore -> do it ourselves */
update_screen(vc);
if (console_blank_hook)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 2b5bb52b1798..4541bc17573e 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -284,8 +284,7 @@ static inline int fbcon_is_inactive(struct vc_data *vc,
struct fb_info *info)
struct fbcon_ops *ops = info->fbcon_par;
return (info->state != FBINFO_STATE_RUNNING ||
- vc->vc_mode != KD_TEXT || ops->graphics) &&
- !vt_force_oops_output(vc);
+ vc->vc_mode != KD_TEXT || ops->graphics);
}
static int get_color(struct vc_data *vc, struct fb_info *info,
diff --git a/include/linux/console_struct.h b/include/linux/console_struct.h
index c0ec478ea5bf..c96e7f5f7c77 100644
--- a/include/linux/console_struct.h
+++ b/include/linux/console_struct.h
@@ -140,7 +140,6 @@ struct vc_data {
struct vc_data **vc_display_fg; /* [!] Ptr to var holding fg
console for this display */
struct uni_pagedir *vc_uni_pagedir;
struct uni_pagedir **vc_uni_pagedir_loc; /* [!] Location of uni_pagedir
variable for this console */
- bool vc_panic_force_write; /* when oops/panic this VC can accept forced
output/blanking */
/* additional information is in vt_kern.h */
};
diff --git a/include/linux/vt_kern.h b/include/linux/vt_kern.h
index 3fd07912909c..8dc77e40bc03 100644
--- a/include/linux/vt_kern.h
+++ b/include/linux/vt_kern.h
@@ -135,13 +135,6 @@ extern int do_unbind_con_driver(const struct consw *csw,
int first, int last,
int deflt);
int vty_init(const struct file_operations *console_fops);
-static inline bool vt_force_oops_output(struct vc_data *vc)
-{
- if (oops_in_progress && vc->vc_panic_force_write && panic_timeout >= 0)
- return true;
- return false;
-}
-
extern char vt_dont_switch;
extern int default_utf8;
extern int global_cursor_default;
--
2.18.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] fbdev: Add FBINFO_HIDE_SMEM_START flag
DRM drivers really, really, really don't want random userspace to
share buffer behind it's back, bypassing the dma-buf buffer sharing
machanism. For that reason we've ruthlessly rejected any IOCTL
exposing the physical address of any graphics buffer.
Unfortunately fbdev comes with that built-in. We could just set
smem_start to 0, but that means we'd have to hand-roll our own fb_mmap
implementation. For good reasons many drivers do that, but
smem_start/length is still super convenient.
Hence instead just stop the leak in the ioctl, to keep fb mmap working
as-is. A second patch will set this flag for all drm drivers.
Cc: Bartlomiej Zolnierkiewicz
Cc: Kees Cook
Cc: Daniel Vetter
Cc: linux-fb...@vger.kernel.org
Signed-off-by: Daniel Vetter
---
drivers/video/fbdev/core/fbmem.c | 4
include/linux/fb.h | 7 +++
2 files changed, 11 insertions(+)
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 609438d2465b..549d0f86fcf3 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1116,6 +1116,8 @@ static long do_fb_ioctl(struct fb_info *info, unsigned
int cmd,
if (!lock_fb_info(info))
return -ENODEV;
fix = info->fix;
+ if (info->flags & FBINFO_HIDE_SMEM_START)
+ fix.smem_start = 0;
unlock_fb_info(info);
ret = copy_to_user(argp, &fix, sizeof(fix)) ? -EFAULT : 0;
@@ -1326,6 +1328,8 @@ static int fb_get_fscreeninfo(struct fb_info *info,
unsigned int cmd,
if (!lock_fb_info(info))
return -ENODEV;
fix = info->fix;
+ if (info->flags & FBINFO_HIDE_SMEM_START)
+ fix.smem_start = 0;
unlock_fb_info(info);
return do_fscreeninfo_to_user(&fix, compat_ptr(arg));
}
diff --git a/include/linux/fb.h b/include/linux/fb.h
index fa8c6f9c9c3a..f42b09ca71f8 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -456,6 +456,13 @@ struct fb_tile_ops {
* and host endianness. Drivers should not use this flag.
*/
#define FBINFO_BE_MATH 0x10
+/*
+ * Hide smem_start in the FBIOGET_FSCREENINFO IOCTL. This is used by modern DRM
+ * drivers to stop userspace from trying to share buffers behind the kernel's
+ * back. Instead dma-buf based buffer sharing should be used.
+ */
+#define FBINFO_HIDE_SMEM_START 0x20
+
struct fb_info {
atomic_t count;
--
2.18.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] vt: Remove vc_panic_force_write
On Wed, Aug 22, 2018 at 10:54:03AM +0200, Daniel Vetter wrote: > It was only used by the panic support in fbcon, which is now gone. > Remove this now dead code too. > > Cc: Greg Kroah-Hartman > Cc: Kees Cook > Cc: Joe Perches > Cc: Daniel Vetter > Cc: Meng Xu > Cc: Nicolas Pitre > Cc: Thomas Meyer > Cc: Mike Frysinger > Cc: Bartlomiej Zolnierkiewicz > Cc: Hans de Goede > Cc: Thierry Reding > Cc: David Lechner > Cc: Philippe Ombredanne > Cc: Thomas Gleixner > Cc: Kate Stewart > Signed-off-by: Daniel Vetter > --- Acked-by: Greg Kroah-Hartman ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/4] fbdev: Drop FBINFO_CAN_FORCE_OUTPUT flag
== Series Details ==
Series: series starting with [1/4] fbdev: Drop FBINFO_CAN_FORCE_OUTPUT flag
URL : https://patchwork.freedesktop.org/series/48541/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4695 -> Patchwork_9987 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/48541/revisions/1/mbox/
== Possible new issues ==
Here are the unknown changes that may have been introduced in Patchwork_9987:
=== IGT changes ===
Possible regressions
{igt@pm_rpm@module-reload}:
fi-byt-j1900: NOTRUN -> DMESG-WARN
Warnings
{igt@kms_psr@primary_page_flip}:
fi-cnl-psr: DMESG-WARN -> DMESG-FAIL
{igt@pm_rpm@module-reload}:
fi-bsw-n3050: DMESG-WARN -> DMESG-FAIL
== Known issues ==
Here are the changes found in Patchwork_9987 that come from known issues:
=== IGT changes ===
Issues hit
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
fi-snb-2520m: PASS -> INCOMPLETE (fdo#103713)
{igt@pm_rpm@module-reload}:
fi-cnl-psr: PASS -> WARN (fdo#107602)
igt@prime_vgem@basic-fence-flip:
fi-ilk-650: PASS -> FAIL (fdo#104008)
Possible fixes
igt@drv_selftest@live_hangcheck:
{fi-cfl-8109u}: DMESG-FAIL (fdo#106560) -> PASS
igt@kms_frontbuffer_tracking@basic:
{fi-byt-clapper}: FAIL (fdo#103167) -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008
fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560
fdo#107602 https://bugs.freedesktop.org/show_bug.cgi?id=107602
== Participating hosts (52 -> 45) ==
Additional (1): fi-byt-j1900
Missing(8): fi-ilk-m540 fi-hsw-4200u fi-skl-guc fi-byt-squawks
fi-bsw-cyan fi-ctg-p8600 fi-glk-j4005 fi-bdw-samus
== Build changes ==
* Linux: CI_DRM_4695 -> Patchwork_9987
CI_DRM_4695: f352837700ec39dbaf00cdf727650851993d754b @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4608: 94ebd21177feedf03e8f6dd1e73dca1a6ec7a0ac @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9987: d9f67334c780e3eaedae58d8a87aaa8d3e3574b3 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
d9f67334c780 drm/fb: Stop leaking physical address
f9169b2a9d69 fbdev: Add FBINFO_HIDE_SMEM_START flag
795187808141 vt: Remove vc_panic_force_write
61a7e4303234 fbdev: Drop FBINFO_CAN_FORCE_OUTPUT flag
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9987/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/syncobj: Drop add/remove_callback from driver interface
This is used for handling future fences. Currently no driver use
these, and I think given the new timeline fence proposed by KHR it
would be better to have a more abstract interface for future fences.
Could be something simple like a struct dma_future_fence plus a
function to add a callback or wait for the fence to materialize.
Then syncobj (and anything else really) could grow new functions to
expose these two drivers. Normal dma_fence would then keep the nice
guarantee that they will always signal (and through ordering, be
deadlock free). dma_future_fence would then be the tricky one.
This also fixes sphinx complaining about the kerneldoc.
Cc: Jason Ekstrand
Cc: Dave Airlie
Cc: Chris Wilson
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_syncobj.c | 15 ---
include/drm/drm_syncobj.h | 5 -
2 files changed, 20 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index adb3cb27d31e..3a8837c49639 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -120,14 +120,6 @@ static int drm_syncobj_fence_get_or_add_callback(struct
drm_syncobj *syncobj,
return ret;
}
-/**
- * drm_syncobj_add_callback - adds a callback to syncobj::cb_list
- * @syncobj: Sync object to which to add the callback
- * @cb: Callback to add
- * @func: Func to use when initializing the drm_syncobj_cb struct
- *
- * This adds a callback to be called next time the fence is replaced
- */
void drm_syncobj_add_callback(struct drm_syncobj *syncobj,
struct drm_syncobj_cb *cb,
drm_syncobj_func_t func)
@@ -136,13 +128,7 @@ void drm_syncobj_add_callback(struct drm_syncobj *syncobj,
drm_syncobj_add_callback_locked(syncobj, cb, func);
spin_unlock(&syncobj->lock);
}
-EXPORT_SYMBOL(drm_syncobj_add_callback);
-/**
- * drm_syncobj_add_callback - removes a callback to syncobj::cb_list
- * @syncobj: Sync object from which to remove the callback
- * @cb: Callback to remove
- */
void drm_syncobj_remove_callback(struct drm_syncobj *syncobj,
struct drm_syncobj_cb *cb)
{
@@ -150,7 +136,6 @@ void drm_syncobj_remove_callback(struct drm_syncobj
*syncobj,
list_del_init(&cb->node);
spin_unlock(&syncobj->lock);
}
-EXPORT_SYMBOL(drm_syncobj_remove_callback);
/**
* drm_syncobj_replace_fence - replace fence in a sync object.
diff --git a/include/drm/drm_syncobj.h b/include/drm/drm_syncobj.h
index 3980602472c0..e419c79ba94d 100644
--- a/include/drm/drm_syncobj.h
+++ b/include/drm/drm_syncobj.h
@@ -131,11 +131,6 @@ drm_syncobj_fence_get(struct drm_syncobj *syncobj)
struct drm_syncobj *drm_syncobj_find(struct drm_file *file_private,
u32 handle);
-void drm_syncobj_add_callback(struct drm_syncobj *syncobj,
- struct drm_syncobj_cb *cb,
- drm_syncobj_func_t func);
-void drm_syncobj_remove_callback(struct drm_syncobj *syncobj,
-struct drm_syncobj_cb *cb);
void drm_syncobj_replace_fence(struct drm_syncobj *syncobj,
struct dma_fence *fence);
int drm_syncobj_find_fence(struct drm_file *file_private,
--
2.18.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/syncobj: Drop add/remove_callback from driver interface
== Series Details == Series: drm/syncobj: Drop add/remove_callback from driver interface URL : https://patchwork.freedesktop.org/series/48542/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/syncobj: Drop add/remove_callback from driver interface +drivers/gpu/drm/drm_syncobj.c:123:6: warning: symbol 'drm_syncobj_add_callback' was not declared. Should it be static? +drivers/gpu/drm/drm_syncobj.c:132:6: warning: symbol 'drm_syncobj_remove_callback' was not declared. Should it be static? ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Rename PLANE_CTL_DECOMPRESSION_ENABLE
On Tue, Aug 21, 2018 at 06:50:53PM -0700, Dhinakaran Pandiyan wrote:
> Rename PLANE_CTL_DECOMPRESSION_ENABLE to resemble the bpsec name -
> PLANE_CTL_RENDER_DECOMPRESSION_ENABLE
>
> Suggested-by: Rodrigo Vivi
> Cc: Daniel Vetter
> Signed-off-by: Dhinakaran Pandiyan
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_reg.h | 2 +-
> drivers/gpu/drm/i915/intel_display.c | 8
> 2 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 59d06d0055bb..a338aaa2b313 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6515,7 +6515,7 @@ enum {
> #define PLANE_CTL_YUV422_UYVY (1 << 16)
> #define PLANE_CTL_YUV422_YVYU (2 << 16)
> #define PLANE_CTL_YUV422_VYUY (3 << 16)
> -#define PLANE_CTL_DECOMPRESSION_ENABLE (1 << 15)
> +#define PLANE_CTL_RENDER_DECOMPRESSION_ENABLE (1 << 15)
> #define PLANE_CTL_TRICKLE_FEED_DISABLE (1 << 14)
> #define PLANE_CTL_PLANE_GAMMA_DISABLE (1 << 13) /* Pre-GLK */
> #define PLANE_CTL_TILED_MASK (0x7 << 10)
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index b98eab113330..ea2bf9c22ade 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3554,11 +3554,11 @@ static u32 skl_plane_ctl_tiling(uint64_t fb_modifier)
> case I915_FORMAT_MOD_Y_TILED:
> return PLANE_CTL_TILED_Y;
> case I915_FORMAT_MOD_Y_TILED_CCS:
> - return PLANE_CTL_TILED_Y | PLANE_CTL_DECOMPRESSION_ENABLE;
> + return PLANE_CTL_TILED_Y |
> PLANE_CTL_RENDER_DECOMPRESSION_ENABLE;
> case I915_FORMAT_MOD_Yf_TILED:
> return PLANE_CTL_TILED_YF;
> case I915_FORMAT_MOD_Yf_TILED_CCS:
> - return PLANE_CTL_TILED_YF | PLANE_CTL_DECOMPRESSION_ENABLE;
> + return PLANE_CTL_TILED_YF |
> PLANE_CTL_RENDER_DECOMPRESSION_ENABLE;
> default:
> MISSING_CASE(fb_modifier);
> }
> @@ -8801,13 +8801,13 @@ skylake_get_initial_plane_config(struct intel_crtc
> *crtc,
> fb->modifier = I915_FORMAT_MOD_X_TILED;
> break;
> case PLANE_CTL_TILED_Y:
> - if (val & PLANE_CTL_DECOMPRESSION_ENABLE)
> + if (val & PLANE_CTL_RENDER_DECOMPRESSION_ENABLE)
> fb->modifier = I915_FORMAT_MOD_Y_TILED_CCS;
> else
> fb->modifier = I915_FORMAT_MOD_Y_TILED;
> break;
> case PLANE_CTL_TILED_YF:
> - if (val & PLANE_CTL_DECOMPRESSION_ENABLE)
> + if (val & PLANE_CTL_RENDER_DECOMPRESSION_ENABLE)
> fb->modifier = I915_FORMAT_MOD_Yf_TILED_CCS;
> else
> fb->modifier = I915_FORMAT_MOD_Yf_TILED;
> --
> 2.17.1
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Add a small wrapper to check for CCS modifiers.
On Tue, Aug 21, 2018 at 06:50:52PM -0700, Dhinakaran Pandiyan wrote:
> Code looks cleaner with modifiers hidden inside this wrapper.
>
> Signed-off-by: Dhinakaran Pandiyan
> ---
> drivers/gpu/drm/i915/intel_display.c | 21 +++--
> drivers/gpu/drm/i915/intel_display.h | 1 +
> drivers/gpu/drm/i915/intel_sprite.c | 3 +--
> 3 files changed, 13 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index ad0f0e5389d9..b98eab113330 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2474,6 +2474,12 @@ intel_get_format_info(const struct drm_mode_fb_cmd2
> *cmd)
> }
> }
>
> +bool is_ccs_modifier(const u64 modifier)
const is rather pointless here IMO.
> +{
> + return modifier == I915_FORMAT_MOD_Y_TILED_CCS ||
> +modifier == I915_FORMAT_MOD_Yf_TILED_CCS;
> +}
IIRC I had a similar thing in my gtt remapping series, though I didn't
plug it into all the places that could have used it.
Reviewed-by: Ville Syrjälä
> +
> static int
> intel_fill_fb_info(struct drm_i915_private *dev_priv,
> struct drm_framebuffer *fb)
> @@ -2504,8 +2510,7 @@ intel_fill_fb_info(struct drm_i915_private *dev_priv,
> return ret;
> }
>
> - if ((fb->modifier == I915_FORMAT_MOD_Y_TILED_CCS ||
> - fb->modifier == I915_FORMAT_MOD_Yf_TILED_CCS) && i == 1) {
> + if (is_ccs_modifier(fb->modifier) && i == 1) {
> int hsub = fb->format->hsub;
> int vsub = fb->format->vsub;
> int tile_width, tile_height;
> @@ -3054,8 +3059,7 @@ static int skl_check_main_surface(const struct
> intel_crtc_state *crtc_state,
>* CCS AUX surface doesn't have its own x/y offsets, we must make sure
>* they match with the main surface x/y offsets.
>*/
> - if (fb->modifier == I915_FORMAT_MOD_Y_TILED_CCS ||
> - fb->modifier == I915_FORMAT_MOD_Yf_TILED_CCS) {
> + if (is_ccs_modifier(fb->modifier)) {
> while (!skl_check_main_ccs_coordinates(plane_state, x, y,
> offset)) {
> if (offset == 0)
> break;
> @@ -3189,8 +3193,7 @@ int skl_check_plane_surface(const struct
> intel_crtc_state *crtc_state,
> ret = skl_check_nv12_aux_surface(plane_state);
> if (ret)
> return ret;
> - } else if (fb->modifier == I915_FORMAT_MOD_Y_TILED_CCS ||
> -fb->modifier == I915_FORMAT_MOD_Yf_TILED_CCS) {
> + } else if (is_ccs_modifier(fb->modifier)) {
> ret = skl_check_ccs_aux_surface(plane_state);
> if (ret)
> return ret;
> @@ -13399,8 +13402,7 @@ static bool skl_plane_format_mod_supported(struct
> drm_plane *_plane,
> case DRM_FORMAT_XBGR:
> case DRM_FORMAT_ARGB:
> case DRM_FORMAT_ABGR:
> - if (modifier == I915_FORMAT_MOD_Yf_TILED_CCS ||
> - modifier == I915_FORMAT_MOD_Y_TILED_CCS)
> + if (is_ccs_modifier(modifier))
> return true;
> /* fall through */
> case DRM_FORMAT_RGB565:
> @@ -14596,8 +14598,7 @@ static int intel_framebuffer_init(struct
> intel_framebuffer *intel_fb,
>* potential runtime errors at plane configuration time.
>*/
> if (IS_GEN9(dev_priv) && i == 0 && fb->width > 3840 &&
> - (fb->modifier == I915_FORMAT_MOD_Y_TILED_CCS ||
> - fb->modifier == I915_FORMAT_MOD_Yf_TILED_CCS))
> + is_ccs_modifier(fb->modifier))
> stride_alignment *= 4;
>
> if (fb->pitches[i] & (stride_alignment - 1)) {
> diff --git a/drivers/gpu/drm/i915/intel_display.h
> b/drivers/gpu/drm/i915/intel_display.h
> index a04c5a495a2b..dbd8b1acf9d6 100644
> --- a/drivers/gpu/drm/i915/intel_display.h
> +++ b/drivers/gpu/drm/i915/intel_display.h
> @@ -381,4 +381,5 @@ void intel_link_compute_m_n(int bpp, int nlanes,
> struct intel_link_m_n *m_n,
> bool reduce_m_n);
>
> +bool is_ccs_modifier(const u64 modifier);
> #endif
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> b/drivers/gpu/drm/i915/intel_sprite.c
> index f7026e887fa9..b49adcd93892 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -1407,8 +1407,7 @@ static bool skl_plane_format_mod_supported(struct
> drm_plane *_plane,
> case DRM_FORMAT_XBGR:
> case DRM_FORMAT_ARGB:
> case DRM_FORMAT_ABGR:
> - if (modifier == I915_FORMAT_MOD_Yf_TILED_CCS ||
> - modifier == I915_FORMAT_MOD_Y_TILED_CCS)
> + if (is_ccs_modifier(modifier))
> return true;
> /* fall through */
>
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/syncobj: Drop add/remove_callback from driver interface
== Series Details ==
Series: drm/syncobj: Drop add/remove_callback from driver interface
URL : https://patchwork.freedesktop.org/series/48542/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4695 -> Patchwork_9988 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/48542/revisions/1/mbox/
== Possible new issues ==
Here are the unknown changes that may have been introduced in Patchwork_9988:
=== IGT changes ===
Possible regressions
{igt@pm_rpm@module-reload}:
fi-byt-j1900: NOTRUN -> DMESG-WARN
== Known issues ==
Here are the changes found in Patchwork_9988 that come from known issues:
=== IGT changes ===
Issues hit
{igt@amdgpu/amd_basic@userptr}:
{fi-kbl-8809g}: PASS -> INCOMPLETE (fdo#107402)
{igt@pm_rpm@module-reload}:
fi-cnl-psr: PASS -> WARN (fdo#107602)
Possible fixes
igt@drv_selftest@live_hangcheck:
{fi-cfl-8109u}: DMESG-FAIL (fdo#106560) -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560
fdo#107402 https://bugs.freedesktop.org/show_bug.cgi?id=107402
fdo#107602 https://bugs.freedesktop.org/show_bug.cgi?id=107602
== Participating hosts (52 -> 47) ==
Additional (1): fi-byt-j1900
Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-bdw-samus
== Build changes ==
* Linux: CI_DRM_4695 -> Patchwork_9988
CI_DRM_4695: f352837700ec39dbaf00cdf727650851993d754b @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4608: 94ebd21177feedf03e8f6dd1e73dca1a6ec7a0ac @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9988: 573052f7cbf140741e3689c403484e3182fe9f94 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
573052f7cbf1 drm/syncobj: Drop add/remove_callback from driver interface
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9988/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC v4 3/8] drm: Add Plane CTM property
On Wed, Aug 22, 2018 at 08:40:19AM +, Lankhorst, Maarten wrote:
> fre 2018-08-17 klockan 19:48 +0530 skrev Uma Shankar:
> > Add a blob property for plane CSC usage.
> >
> > v2: Rebase
> >
> > v3: Fixed Sean, Paul's review comments. Moved the property from
> > mode_config to drm_plane. Created a helper function to instantiate
> > these properties and removed from drm_mode_create_standard_properties
> > Added property documentation as suggested by Daniel, Vetter.
> >
> > v4: Rebase
> >
> > Signed-off-by: Uma Shankar
> > ---
> > Documentation/gpu/drm-kms.rst | 3 +++
> > drivers/gpu/drm/drm_atomic.c| 10 ++
> > drivers/gpu/drm/drm_atomic_helper.c | 4
> > drivers/gpu/drm/drm_plane.c | 12
> > include/drm/drm_plane.h | 15 +++
> > 5 files changed, 44 insertions(+)
> >
> > diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-
> > kms.rst
> > index 8b10b12..16d6d8d 100644
> > --- a/Documentation/gpu/drm-kms.rst
> > +++ b/Documentation/gpu/drm-kms.rst
> > @@ -560,6 +560,9 @@ Plane Color Management Properties
> > .. kernel-doc:: drivers/gpu/drm/drm_plane.c
> > :doc: degamma_lut_size_property
> >
> > +.. kernel-doc:: drivers/gpu/drm/drm_plane.c
> > + :doc: ctm_property
> > +
> > Tile Group Property
> > ---
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c
> > b/drivers/gpu/drm/drm_atomic.c
> > index f8cad9b..ddda935 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -917,6 +917,14 @@ static int drm_atomic_plane_set_property(struct
> > drm_plane *plane,
> > &replaced);
> > state->color_mgmt_changed |= replaced;
> > return ret;
> > + } else if (property == plane->ctm_property) {
> > + ret = drm_atomic_replace_property_blob_from_id(dev,
> > + &state->ctm,
> > + val,
> > + sizeof(struct
> > drm_color_ctm), -1,
> > + &replaced);
> > + state->color_mgmt_changed |= replaced;
> > + return ret;
> > } else if (plane->funcs->atomic_set_property) {
> > return plane->funcs->atomic_set_property(plane,
> > state,
> > property, val);
> > @@ -988,6 +996,8 @@ static int drm_atomic_plane_set_property(struct
> > drm_plane *plane,
> > } else if (property == plane->degamma_lut_property) {
> > *val = (state->degamma_lut) ?
> > state->degamma_lut->base.id : 0;
> > + } else if (property == plane->ctm_property) {
> > + *val = (state->ctm) ? state->ctm->base.id : 0;
> > } else if (plane->funcs->atomic_get_property) {
> > return plane->funcs->atomic_get_property(plane,
> > state, property, val);
> > } else {
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index 67c5b51..866181f 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -3616,6 +3616,9 @@ void
> > __drm_atomic_helper_plane_duplicate_state(struct drm_plane *plane,
> >
> > if (state->degamma_lut)
> > drm_property_blob_get(state->degamma_lut);
> > + if (state->ctm)
> > + drm_property_blob_get(state->ctm);
> > +
> > state->color_mgmt_changed = false;
> > }
> > EXPORT_SYMBOL(__drm_atomic_helper_plane_duplicate_state);
> > @@ -3663,6 +3666,7 @@ void
> > __drm_atomic_helper_plane_destroy_state(struct drm_plane_state
> > *state)
> > drm_crtc_commit_put(state->commit);
> >
> > drm_property_blob_put(state->degamma_lut);
> > + drm_property_blob_put(state->ctm);
> > }
> > EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
> >
> > diff --git a/drivers/gpu/drm/drm_plane.c
> > b/drivers/gpu/drm/drm_plane.c
> > index 03e0560..97520b1 100644
> > --- a/drivers/gpu/drm/drm_plane.c
> > +++ b/drivers/gpu/drm/drm_plane.c
> > @@ -489,6 +489,11 @@ int drm_mode_plane_set_obj_prop(struct drm_plane
> > *plane,
> > *
> > * degamma_lut_size_property:
> > * Range Property to indicate size of the plane degamma LUT.
> > + *
> > + * ctm_property:
> > + * Blob property which allows a userspace to provide CTM
> > coefficients
> > + * to do color space conversion or any other enhancement by
> > doing a
> > + * matrix multiplication using the h/w CTM processing engine
> > */
> > int drm_plane_color_create_prop(struct drm_device *dev,
> > struct drm_plane *plane)
> > @@ -509,6 +514,13 @@ int drm_plane_color_create_prop(struct
> > drm_device *dev,
> > return -ENOMEM;
> > plane->degamma_lut_size_property = prop;
> >
> > + prop = drm_property_create(dev,
> > + DRM_MODE_PROP_BLOB,
> > + "PLANE_CTM", 0);
> > + if (!prop)
> > + return -ENOMEM;
> > + plane-
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/4] fbdev: Drop FBINFO_CAN_FORCE_OUTPUT flag
== Series Details == Series: series starting with [1/4] fbdev: Drop FBINFO_CAN_FORCE_OUTPUT flag URL : https://patchwork.freedesktop.org/series/48541/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4695_full -> Patchwork_9987_full = == Summary - SUCCESS == No regressions found. == Known issues == Here are the changes found in Patchwork_9987_full that come from known issues: === IGT changes === Issues hit igt@gem_ctx_isolation@vcs1-s3: shard-kbl: PASS -> INCOMPLETE (fdo#103665) igt@kms_available_modes_crc@available_mode_test_crc: shard-kbl: NOTRUN -> FAIL (fdo#106641) igt@kms_setmode@basic: shard-apl: PASS -> FAIL (fdo#99912) Possible fixes igt@gem_ppgtt@blt-vs-render-ctxn: shard-kbl: INCOMPLETE (fdo#106023, fdo#103665) -> PASS +1 igt@kms_flip@flip-vs-expired-vblank: shard-glk: FAIL (fdo#105363) -> PASS igt@kms_setmode@basic: shard-kbl: FAIL (fdo#99912) -> PASS fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023 fdo#106641 https://bugs.freedesktop.org/show_bug.cgi?id=106641 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4695 -> Patchwork_9987 CI_DRM_4695: f352837700ec39dbaf00cdf727650851993d754b @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4608: 94ebd21177feedf03e8f6dd1e73dca1a6ec7a0ac @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9987: d9f67334c780e3eaedae58d8a87aaa8d3e3574b3 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9987/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v2] Add support for forcing a specific driver
This commit adds a new option for forcing the use of a specific driver
indicated via an environment variable.
v2 (Petri):
- Use an environment variable instead of command line
- Refactor the loop in __open_device
- Don't try to load kernel modules
Signed-off-by: Rodrigo Siqueira
Signed-off-by: Petri Latvala
Cc: Arkadiusz Hiler
Cc: gust...@padovan.org
---
Did the changes I suggested myself to see what else is lurking
there. I'm still unsure whether using IGT_FORCE_DRIVER=something
should still accept opening e.g. an i915 device with DRIVER_INTEL,
currently this does. Both ways have their merits.
I was able to test vkms with this patch, revealing some amount of
intelisms still lurking.
lib/drmtest.c | 35 +++
lib/drmtest.h | 2 ++
lib/igt_core.c | 5 +
3 files changed, 42 insertions(+)
diff --git a/lib/drmtest.c b/lib/drmtest.c
index fae6f86f..e8308b0d 100644
--- a/lib/drmtest.c
+++ b/lib/drmtest.c
@@ -146,6 +146,31 @@ static bool has_known_intel_chipset(int fd)
return true;
}
+static char _forced_driver[5] = "";
+
+/**
+ * __set_forced_driver:
+ * @name: name of driver to forcibly use
+ *
+ * Set the name of a driver to use when calling #drm_open_driver with
+ * the #DRIVER_ANY flag.
+ */
+void __set_forced_driver(const char *name)
+{
+ if (!name)
+ igt_warn("No driver specified, keep default behaviour");
+
+ strncpy(_forced_driver, name, 4);
+}
+
+static const char *forced_driver(void)
+{
+ if (_forced_driver[0])
+ return _forced_driver;
+
+ return NULL;
+}
+
#define LOCAL_I915_EXEC_VEBOX (4 << 0)
/**
* gem_quiescent_gpu:
@@ -229,6 +254,16 @@ static int __open_device(const char *base, int offset,
unsigned int chipset)
if (fd == -1)
continue;
+ // Force options
+ if (chipset == DRIVER_ANY && forced_driver()) {
+ if (__is_device(fd, forced_driver())) {
+ igt_debug("Force option used: Using driver
%s\n", forced_driver());
+ return fd;
+ }
+
+ continue;
+ }
+
if (chipset & DRIVER_INTEL && is_i915_device(fd) &&
has_known_intel_chipset(fd))
return fd;
diff --git a/lib/drmtest.h b/lib/drmtest.h
index 949865ee..62f53ec3 100644
--- a/lib/drmtest.h
+++ b/lib/drmtest.h
@@ -51,6 +51,8 @@
*/
#define DRIVER_ANY ~(DRIVER_VGEM)
+void __set_forced_driver(const char *name);
+
/**
* ARRAY_SIZE:
* @arr: static array
diff --git a/lib/igt_core.c b/lib/igt_core.c
index c52c0818..c17e53c5 100644
--- a/lib/igt_core.c
+++ b/lib/igt_core.c
@@ -646,6 +646,11 @@ static void common_init_env(void)
igt_frame_dump_path = getenv("IGT_FRAME_DUMP_PATH");
stderr_needs_sentinel = getenv("IGT_SENTINEL_ON_STDERR") != NULL;
+
+ env = getenv("IGT_FORCE_DRIVER");
+ if (env) {
+ __set_forced_driver(env);
+ }
}
static int common_init(int *argc, char **argv,
--
2.14.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/i915: kill intel_display_power_well_is_enabled()
On Tue, Aug 21, 2018 at 12:54:12PM -0700, Paulo Zanoni wrote:
> Em Ter, 2018-08-21 às 14:12 +0300, Imre Deak escreveu:
> > On Mon, Aug 20, 2018 at 04:11:27PM -0700, Paulo Zanoni wrote:
> > > Em Sex, 2018-08-17 às 16:41 -0700, Paulo Zanoni escreveu:
> > > > Em Qua, 2018-08-15 às 23:27 +0300, Imre Deak escreveu:
> > > > > On Wed, Aug 08, 2018 at 03:16:11PM -0700, Paulo Zanoni wrote:
> > > > > > [...]
> > > > > > -bool intel_display_power_well_is_enabled(struct drm_i915_private
> > > > > > *dev_priv,
> > > > > > -enum i915_power_well_id
> > > > > > power_well_id)
> > > > > > -{
> > > > > > - struct i915_power_well *power_well;
> > > > > > - bool ret;
> > > > > > -
> > > > > > - power_well = lookup_power_well(dev_priv, power_well_id);
> > > > > > - ret = power_well->desc->ops->is_enabled(dev_priv, power_well);
> > > > > > -
> > > > > > - return ret;
> > > > > > -}
> > > > > > -
> > > > >
> > > > > Or rather export a locked version of it and use that in intel_hdcp.c
> > > > > to better hide the internals?
> > > >
> > > > That should probably be combined with José's idea of using
> > > > ->enabled so we trust the hardware sync.
> > > >
> > > > Thanks for the suggestions.
> > >
> > > After further analysis, I wonder if intel_hdcp.c should really be
> > > checking for enabled power wells or if it should be doing
> > > something else, such as actually grabbing power domain references
> > > to make sure we're able to enable/disable HDCP whenever we need.
> > > Most of our code should not be checking for power wells/domains
> > > being enabled/disabled (except for HW readout), it should actually
> > > be requesting those resources to make sure we have them when we
> > > need them.
> > >
> > > CCing Ramaligam for that.
> >
> > There is no separate power resource for HDCP, it just uses the power
> > wells the encoder already uses. Those are guaranteed to be on, since
> > intel_hdcp_enable/disable are called from the encoder enable/disable
> > hooks. As such hdcp_key_loadable() is just an assert.
>
> But then in this case, an assertion wouldn't make sense at all, since
> if the condition for the assert was not valid, everything before that
> call would have been broken too. If this were the only problem I would
> just vote to remove the assertion.
It is an assertion, hdcp_key_loadable() always returns true, unless
there is a bug somewhere. I think it also makes sense to have an
assertion past the point where the condition should be true, close to a
place where you logically depend on this condition. For instance for
documentation or to make sure some bug in between didn't cause the
condition to become false. In this case it looks like it was added to
match the conditions listed by BSpec.
> The problem here is that we have a work function that also runs the
> assert, and since it's a work function we really have no guarantees
> about the power wells being held when it runs.
>
> intel_hdcp_check_work() -> intel_hdcp_check_link() ->
> _intel_hdcp_enable() -> hdcp_key_loadable().
>
> I'm not sure what's the best thing to do here, but perhaps preventing
> the hardware from going away when this work is scheduled would help.
The work is cancelled in intel_hdcp_disable(), so it's guarateed to run
only while the encoder is active (and hence that the required power
wells are enabled).
> > Defining a new power domain for this would be a bit overkill imo
> > and as PW#1 is handled automatically by HW (and so not the usual
> > driver get/put ops via power domain handles) we would have to
> > special case it.
>
> It only gets automatically handled by the HW once we drop a well
> defined set of power domains. If we grab those power domains we
> prevent automatic hardware handling.
Sure, but the assert is specifically about PW#1, not about some other
indirect dependency that should cause PW#1 to be enabled. (That is
should unless there is a bug somewhere.)
--Imre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH V2 4/4] drm/crc: add pre_crc_read function
Op 21-08-18 om 10:38 schreef Mahesh Kumar:
> This patch implements a callback function which will be called before
> crc read. In this function driver can implement any preparation work
> required for successfully reading CRC data.
>
> Changes Since V1:
> - rebase
>
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Mahesh Kumar
After some discussion with David on whether this can be upstreamed, he NACK'd
it.
Because there are no upstream users for this callback, it cannot be included
upstream.
It would be removed by the first person to notice there are no in-kernel users
using it.
For the first 3 patches:
Reviewed-by: Maarten Lankhorst
> drivers/gpu/drm/drm_debugfs_crc.c | 8
> include/drm/drm_crtc.h| 14 ++
> 2 files changed, 22 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_debugfs_crc.c
> b/drivers/gpu/drm/drm_debugfs_crc.c
> index 00e743153e94..e303c194c080 100644
> --- a/drivers/gpu/drm/drm_debugfs_crc.c
> +++ b/drivers/gpu/drm/drm_debugfs_crc.c
> @@ -274,6 +274,14 @@ static ssize_t crtc_crc_read(struct file *filep, char
> __user *user_buf,
> return 0;
> }
>
> + if (crtc->funcs->pre_crc_read) {
> + ret = crtc->funcs->pre_crc_read(crtc);
> + if (ret) {
> + spin_unlock_irq(&crc->lock);
> + return ret;
> + }
> + }
> +
> /* Nothing to read? */
> while (crtc_crc_data_count(crc) == 0) {
> if (filep->f_flags & O_NONBLOCK) {
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index b21437bc95bf..19c2bf63935e 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -761,6 +761,20 @@ struct drm_crtc_funcs {
>*/
> int (*verify_crc_source)(struct drm_crtc *crtc, const char *source,
>size_t *values_cnt);
> + /**
> + * @pre_crc_read:
> + *
> + * Driver callback for performing any preparation work required by
> + * driver before reading CRC
> + *
> + * This callback is optional if the driver does not support CRC
> + * generation or no prework is required before reading the crc
> + *
> + * RETURNS:
> + *
> + * 0 on success or a negative error code on failure.
> + */
> + int (*pre_crc_read)(struct drm_crtc *crtc);
> /**
>* @get_crc_sources:
>*
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC v4 3/8] drm: Add Plane CTM property
Hi,
On Wed, Aug 22, 2018 at 12:53:58PM +0300, Ville Syrjälä wrote:
On Wed, Aug 22, 2018 at 08:40:19AM +, Lankhorst, Maarten wrote:
fre 2018-08-17 klockan 19:48 +0530 skrev Uma Shankar:
> Add a blob property for plane CSC usage.
>
> v2: Rebase
>
> v3: Fixed Sean, Paul's review comments. Moved the property from
> mode_config to drm_plane. Created a helper function to instantiate
> these properties and removed from drm_mode_create_standard_properties
> Added property documentation as suggested by Daniel, Vetter.
>
> v4: Rebase
>
> Signed-off-by: Uma Shankar
> ---
> Documentation/gpu/drm-kms.rst | 3 +++
> drivers/gpu/drm/drm_atomic.c| 10 ++
> drivers/gpu/drm/drm_atomic_helper.c | 4
> drivers/gpu/drm/drm_plane.c | 12
> include/drm/drm_plane.h | 15 +++
> 5 files changed, 44 insertions(+)
>
> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-
> kms.rst
> index 8b10b12..16d6d8d 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -560,6 +560,9 @@ Plane Color Management Properties
> .. kernel-doc:: drivers/gpu/drm/drm_plane.c
> :doc: degamma_lut_size_property
>
> +.. kernel-doc:: drivers/gpu/drm/drm_plane.c
> + :doc: ctm_property
> +
> Tile Group Property
> ---
>
> diff --git a/drivers/gpu/drm/drm_atomic.c
> b/drivers/gpu/drm/drm_atomic.c
> index f8cad9b..ddda935 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -917,6 +917,14 @@ static int drm_atomic_plane_set_property(struct
> drm_plane *plane,
>&replaced);
>state->color_mgmt_changed |= replaced;
>return ret;
> + } else if (property == plane->ctm_property) {
> + ret = drm_atomic_replace_property_blob_from_id(dev,
> + &state->ctm,
> + val,
> + sizeof(struct
> drm_color_ctm), -1,
> + &replaced);
> + state->color_mgmt_changed |= replaced;
> + return ret;
>} else if (plane->funcs->atomic_set_property) {
>return plane->funcs->atomic_set_property(plane,
> state,
>property, val);
> @@ -988,6 +996,8 @@ static int drm_atomic_plane_set_property(struct
> drm_plane *plane,
>} else if (property == plane->degamma_lut_property) {
>*val = (state->degamma_lut) ?
>state->degamma_lut->base.id : 0;
> + } else if (property == plane->ctm_property) {
> + *val = (state->ctm) ? state->ctm->base.id : 0;
>} else if (plane->funcs->atomic_get_property) {
>return plane->funcs->atomic_get_property(plane,
> state, property, val);
>} else {
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 67c5b51..866181f 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -3616,6 +3616,9 @@ void
> __drm_atomic_helper_plane_duplicate_state(struct drm_plane *plane,
>
>if (state->degamma_lut)
>drm_property_blob_get(state->degamma_lut);
> + if (state->ctm)
> + drm_property_blob_get(state->ctm);
> +
>state->color_mgmt_changed = false;
> }
> EXPORT_SYMBOL(__drm_atomic_helper_plane_duplicate_state);
> @@ -3663,6 +3666,7 @@ void
> __drm_atomic_helper_plane_destroy_state(struct drm_plane_state
> *state)
>drm_crtc_commit_put(state->commit);
>
>drm_property_blob_put(state->degamma_lut);
> + drm_property_blob_put(state->ctm);
> }
> EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
>
> diff --git a/drivers/gpu/drm/drm_plane.c
> b/drivers/gpu/drm/drm_plane.c
> index 03e0560..97520b1 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -489,6 +489,11 @@ int drm_mode_plane_set_obj_prop(struct drm_plane
> *plane,
> *
> * degamma_lut_size_property:
> *Range Property to indicate size of the plane degamma LUT.
> + *
> + * ctm_property:
> + *Blob property which allows a userspace to provide CTM
> coefficients
> + *to do color space conversion or any other enhancement by
> doing a
> + *matrix multiplication using the h/w CTM processing engine
> */
> int drm_plane_color_create_prop(struct drm_device *dev,
>struct drm_plane *plane)
> @@ -509,6 +514,13 @@ int drm_plane_color_create_prop(struct
> drm_device *dev,
>return -ENOMEM;
>plane->degamma_lut_size_property = prop;
>
> + prop = drm_property_create(dev,
> + DRM_MODE_PROP_BLOB,
> + "PLANE_CTM", 0);
> + if (!prop)
> + return -ENOMEM;
> + plane->ctm_property = prop;
> +
>return 0;
> }
> EXPORT_SYMBOL(drm_plane_color_create_prop);
> diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
> index 28357ac..5143277 100644
> --- a/include/drm/d
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/syncobj: Drop add/remove_callback from driver interface
== Series Details ==
Series: drm/syncobj: Drop add/remove_callback from driver interface
URL : https://patchwork.freedesktop.org/series/48542/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4695_full -> Patchwork_9988_full =
== Summary - WARNING ==
Minor unknown changes coming with Patchwork_9988_full need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_9988_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
== Possible new issues ==
Here are the unknown changes that may have been introduced in
Patchwork_9988_full:
=== IGT changes ===
Warnings
igt@gem_ctx_param@root-set-no-zeromap-disabled:
shard-kbl: PASS -> ( 2 PASS ) +541
igt@gem_exec_big:
shard-apl: SKIP -> ( 2 SKIP ) +197
igt@gem_mocs_settings@mocs-reset-bsd2:
shard-snb: SKIP -> ( 2 SKIP ) +343
igt@gem_pread@stolen-uncached:
shard-kbl: SKIP -> ( 2 SKIP ) +207
igt@gem_pwrite@small-cpu-random:
shard-hsw: PASS -> ( 2 PASS ) +452
igt@kms_concurrent@pipe-d:
shard-hsw: SKIP -> ( 2 SKIP ) +239
igt@kms_frontbuffer_tracking@psr-rgb101010-draw-pwrite:
shard-glk: SKIP -> ( 2 SKIP ) +173
igt@kms_plane@plane-panning-bottom-right-pipe-a-planes:
shard-glk: PASS -> ( 2 PASS ) +440
igt@kms_rotation_crc@sprite-rotation-90-pos-100-0:
shard-apl: PASS -> ( 2 PASS ) +416
igt@syncobj_wait@invalid-wait-bad-flags:
shard-snb: PASS -> ( 2 PASS ) +348
== Known issues ==
Here are the changes found in Patchwork_9988_full that come from known issues:
=== IGT changes ===
Issues hit
igt@gem_ctx_isolation@vcs1-s3:
shard-kbl: PASS -> ( 2 INCOMPLETE ) (fdo#103665)
igt@kms_setmode@basic:
shard-apl: PASS -> FAIL (fdo#99912)
Possible fixes
igt@gem_ppgtt@blt-vs-render-ctx0:
shard-kbl: INCOMPLETE (fdo#103665, fdo#106023) -> PASS
Warnings
igt@gem_exec_schedule@pi-ringfull-bsd1:
shard-kbl: FAIL (fdo#103158) -> ( 2 FAIL ) (fdo#103158) +1
igt@gem_exec_schedule@pi-ringfull-render:
shard-apl: FAIL (fdo#103158) -> ( 2 FAIL ) (fdo#103158)
igt@kms_ccs@pipe-b-crc-sprite-planes-basic:
shard-apl: FAIL (fdo#105458, fdo#106510) -> ( 2 FAIL )
(fdo#105458, fdo#106510)
igt@kms_flip@flip-vs-expired-vblank:
shard-glk: FAIL (fdo#105363) -> ( 1 FAIL, 1 PASS ) (fdo#102887,
fdo#105363)
igt@kms_rotation_crc@primary-rotation-180:
shard-snb: FAIL (fdo#103925) -> ( 2 FAIL ) (fdo#103925)
igt@kms_setmode@basic:
shard-kbl: FAIL (fdo#99912) -> ( 2 FAIL ) (fdo#99912)
igt@kms_sysfs_edid_timing:
shard-hsw: WARN (fdo#100047) -> ( 2 WARN ) (fdo#100047)
shard-glk: WARN (fdo#100047) -> ( 2 WARN ) (fdo#100047)
shard-kbl: FAIL (fdo#100047) -> ( 2 FAIL ) (fdo#100047)
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
fdo#103158 https://bugs.freedesktop.org/show_bug.cgi?id=103158
fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
fdo#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925
fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363
fdo#105458 https://bugs.freedesktop.org/show_bug.cgi?id=105458
fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023
fdo#106510 https://bugs.freedesktop.org/show_bug.cgi?id=106510
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
== Participating hosts (5 -> 5) ==
No changes in participating hosts
== Build changes ==
* Linux: CI_DRM_4695 -> Patchwork_9988
CI_DRM_4695: f352837700ec39dbaf00cdf727650851993d754b @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4608: 94ebd21177feedf03e8f6dd1e73dca1a6ec7a0ac @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9988: 573052f7cbf140741e3689c403484e3182fe9f94 @
git://anongit.freedesktop.org/gfx-ci/linux
piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @
git://anongit.freedesktop.org/piglit
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9988/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Simplify condition to keep DMC active during S0ix
For S0ix we want to deinit power domains (and so deactivate the DMC
firmware) exactly when the platform supports the DC9 state. To reach
S0ix we need DC9 on these platforms (for which the DMC FW needs to be
deactivated) while to reach S0ix on the rest of the DMC platforms we
need DC6 (which needs the DMC FW to stay active).
Simplify the condition accordingly so it will be automatically
correct for upcoming DC9 platforms like ICL.
Cc: Lucas De Marchi
Cc: Michel Thierry
Cc: Ville Syrjälä
Cc: Rodrigo Vivi
Cc: Paulo Zanoni
Cc: Chris Wilson
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_runtime_pm.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index ff3fd8dbd2b4..1b10b7041513 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -3848,13 +3848,14 @@ void intel_power_domains_suspend(struct
drm_i915_private *dev_priv,
intel_display_power_put(dev_priv, POWER_DOMAIN_INIT);
/*
-* In case of firmware assisted context save/restore don't manually
-* deinit the power domains. This also means the CSR/DMC firmware will
-* stay active, it will power down any HW resources as required and
-* also enable deeper system power states that would be blocked if the
-* firmware was inactive.
+* In case of suspend-to-idle (aka S0ix) on a DMC platform without DC9
+* support don't manually deinit the power domains. This also means the
+* CSR/DMC firmware will stay active, it will power down any HW
+* resources as required and also enable deeper system power states
+* that would be blocked if the firmware was inactive.
*/
- if (!IS_GEN9_LP(dev_priv) && suspend_mode == I915_DRM_SUSPEND_IDLE &&
+ if (!(dev_priv->csr.allowed_dc_mask & DC_STATE_EN_DC9) &&
+ suspend_mode == I915_DRM_SUSPEND_IDLE &&
dev_priv->csr.dmc_payload != NULL) {
intel_power_domains_verify_state(dev_priv);
return;
--
2.13.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] RFC: Migration to Gitlab
Hi all, I think it's time to brainstorm a bit about the gitlab migration. Basic reasons: - fd.o admins want to deprecate shell accounts and hand-rolled infrastructure, because it's a pain to keep secure&updated. - gitlab will allow us to add committers on our own, greatly simplifying that process (and offloading that task from fd.o admins). There's also some more benefits we might want to reap, like better CI integration for basic build testing - no more "oops didn't build drm-misc defconfigs" or "sry, forgot make check in maintainer-tools". But that's all fully optional. For the full in-depth writeup of everything, see https://www.fooishbar.org/blog/gitlab-fdo-introduction/ I think now is also a good time, with mesa, xorg, wayland/weston and others moved, to start thinking about how we'll move drm. There's a few things to figure out though: - We probably want to split out maintainer-tools. That would address the concern that there's 50+ committers to an auto-updating shell script ... - We need to figure out how to handle the ACL trickery around drm-tip in gitlab. - Probably good to stage the migration, with maintainer-tools, igt leading. That will also make fd.o admins happy, who want to rework their cloud infrastructure a bit before migrating the big kernel repos over. - Figuring out the actual migration - we've been adding a pile of committers since fd.o LDAP was converted to gitlab once back in spring. We need to at least figure out how to move the new accounts/committers. - Similar, maintainer-tools needs to move. We probably want to move all the dim maintained kernel repos in one go, to avoid headaches with double-accounts needed for committers. - CI, linux-next and everyone else should be fine, since the cgit/non-ssh paths will keep working (they'll be read-only mirrors). Need to double-check that with everyone. - Some organization structure would be good. https://cgit.freedesktop.org/drm libdrm won't be part of the gitlab drm group because that's already moved under mesa (and you can't symlink/mulit-home anymore on gitlab): https://gitlab.freedesktop.org/mesa/drm But there's also drm_hwcomposer, which we might want to migrate into drm too - gitlab requires a containing group, and drm_hwcomposer/drm_hwcomposer is a bit silly. Note: Access rights can be done at any level in the hierarchy, the organization is orthogonal to commit rights. - Anything else I've forgotten. A lot of this still needs to be figured out first. As a first step I'm looking for volunteers who want to join the fun, besides comments and thoughts on the overall topic of course. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Simplify condition to keep DMC active during S0ix
== Series Details ==
Series: drm/i915: Simplify condition to keep DMC active during S0ix
URL : https://patchwork.freedesktop.org/series/48556/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4695 -> Patchwork_9989 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/48556/revisions/1/mbox/
== Possible new issues ==
Here are the unknown changes that may have been introduced in Patchwork_9989:
=== IGT changes ===
Possible regressions
{igt@pm_rpm@module-reload}:
fi-byt-j1900: NOTRUN -> DMESG-WARN
Warnings
igt@drv_selftest@live_guc:
{fi-bdw-samus}: SKIP -> PASS +1
{igt@pm_rpm@module-reload}:
fi-hsw-4770r: PASS -> SKIP
== Known issues ==
Here are the changes found in Patchwork_9989 that come from known issues:
=== IGT changes ===
Issues hit
igt@drv_module_reload@basic-reload-inject:
fi-hsw-4770r: PASS -> DMESG-WARN (fdo#107425)
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
{fi-byt-clapper}: PASS -> FAIL (fdo#103191, fdo#107362)
{igt@kms_psr@primary_page_flip}:
{fi-icl-u}: NOTRUN -> FAIL (fdo#107383) +3
Possible fixes
igt@drv_selftest@live_hangcheck:
{fi-bdw-samus}: DMESG-FAIL (fdo#106560) -> PASS
{fi-cfl-8109u}: DMESG-FAIL (fdo#106560) -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560
fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362
fdo#107383 https://bugs.freedesktop.org/show_bug.cgi?id=107383
fdo#107425 https://bugs.freedesktop.org/show_bug.cgi?id=107425
== Participating hosts (52 -> 49) ==
Additional (2): fi-byt-j1900 fi-icl-u
Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-hsw-4200u
== Build changes ==
* Linux: CI_DRM_4695 -> Patchwork_9989
CI_DRM_4695: f352837700ec39dbaf00cdf727650851993d754b @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4608: 94ebd21177feedf03e8f6dd1e73dca1a6ec7a0ac @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9989: 2c35976d2b8127d127729694fe0295a61ee2d685 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
2c35976d2b81 drm/i915: Simplify condition to keep DMC active during S0ix
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9989/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Simplify condition to keep DMC active during S0ix
On Wed, Aug 22, 2018 at 02:26:02PM +0300, Imre Deak wrote:
> For S0ix we want to deinit power domains (and so deactivate the DMC
> firmware) exactly when the platform supports the DC9 state. To reach
> S0ix we need DC9 on these platforms (for which the DMC FW needs to be
> deactivated) while to reach S0ix on the rest of the DMC platforms we
> need DC6 (which needs the DMC FW to stay active).
>
> Simplify the condition accordingly so it will be automatically
> correct for upcoming DC9 platforms like ICL.
>
> Cc: Lucas De Marchi
> Cc: Michel Thierry
> Cc: Ville Syrjälä
> Cc: Rodrigo Vivi
> Cc: Paulo Zanoni
> Cc: Chris Wilson
> Signed-off-by: Imre Deak
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_runtime_pm.c | 13 +++--
> 1 file changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index ff3fd8dbd2b4..1b10b7041513 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -3848,13 +3848,14 @@ void intel_power_domains_suspend(struct
> drm_i915_private *dev_priv,
> intel_display_power_put(dev_priv, POWER_DOMAIN_INIT);
>
> /*
> - * In case of firmware assisted context save/restore don't manually
> - * deinit the power domains. This also means the CSR/DMC firmware will
> - * stay active, it will power down any HW resources as required and
> - * also enable deeper system power states that would be blocked if the
> - * firmware was inactive.
> + * In case of suspend-to-idle (aka S0ix) on a DMC platform without DC9
> + * support don't manually deinit the power domains. This also means the
> + * CSR/DMC firmware will stay active, it will power down any HW
> + * resources as required and also enable deeper system power states
> + * that would be blocked if the firmware was inactive.
>*/
> - if (!IS_GEN9_LP(dev_priv) && suspend_mode == I915_DRM_SUSPEND_IDLE &&
> + if (!(dev_priv->csr.allowed_dc_mask & DC_STATE_EN_DC9) &&
> + suspend_mode == I915_DRM_SUSPEND_IDLE &&
> dev_priv->csr.dmc_payload != NULL) {
> intel_power_domains_verify_state(dev_priv);
> return;
> --
> 2.13.2
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Keep physical cursors pinned while in use
On Fri, Aug 17, 2018 at 09:24:05AM +0100, Chris Wilson wrote:
> The optimisation inherent in commit 6a2c4232ece1 ("drm/i915: Make the
> physical object coherent with GTT") relies on that once we allocated a
> cursor we would have coherent, zero overhead access to the scanout plane
> holding the cursor. That is we could then do the very frequent cursor
> updates X enjoys with no indirection or kernel involvement. However,
> that all hinges on the GGTT mmap of the cursor being pinned and not
> require refaulting on each access -- handling such a page fault likely
> requires the busy GGTT to be rearranged causing a stall. A very simple
> fix is then to handle the physical cursor exactly like other cursors and
> keep its vma pinned while active.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107600
I guess this wasn't the thing we wanted. But seems quite harmless to
me anyway, so
Reviewed-by: Ville Syrjälä
in case you still want to land it.
> References: 6a2c4232ece1 ("drm/i915: Make the physical object coherent with
> GTT")
> Signed-off-by: Chris Wilson
> Cc: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_display.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 592b847db88e..d47ec9fd4af4 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -12966,8 +12966,11 @@ static int intel_plane_pin_fb(struct
> intel_plane_state *plane_state)
> INTEL_INFO(dev_priv)->cursor_needs_physical) {
> struct drm_i915_gem_object *obj = intel_fb_obj(fb);
> const int align = intel_cursor_alignment(dev_priv);
> + int err;
>
> - return i915_gem_object_attach_phys(obj, align);
> + err = i915_gem_object_attach_phys(obj, align);
> + if (err)
> + return err;
> }
>
> vma = intel_pin_and_fence_fb_obj(fb,
> --
> 2.18.0
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Simplify condition to keep DMC active during S0ix
== Series Details == Series: drm/i915: Simplify condition to keep DMC active during S0ix URL : https://patchwork.freedesktop.org/series/48556/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4695_full -> Patchwork_9989_full = == Summary - SUCCESS == No regressions found. == Known issues == Here are the changes found in Patchwork_9989_full that come from known issues: === IGT changes === Issues hit igt@gem_ctx_isolation@vcs1-s3: shard-kbl: PASS -> INCOMPLETE (fdo#103665) Possible fixes igt@kms_flip@flip-vs-expired-vblank: shard-glk: FAIL (fdo#105363) -> PASS fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4695 -> Patchwork_9989 CI_DRM_4695: f352837700ec39dbaf00cdf727650851993d754b @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4608: 94ebd21177feedf03e8f6dd1e73dca1a6ec7a0ac @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9989: 2c35976d2b8127d127729694fe0295a61ee2d685 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9989/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/tracepoints: Remove DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig option
On 21/08/2018 13:06, Joonas Lahtinen wrote: Quoting Kukanova, Svetlana (2018-08-13 16:44:49) Joonas, sorry for interfering; could you please explain more regarding the options for tracing scheduling events better than tracepoints? After scheduling moves to GuC tools will have to switch to something like GuC-logging; but while kmd does scheduling isn't kernel-tracing the best solution? I know gpuvis is not the only attempt to use tracepoints for the same purpose. (there're trace.pl and S.E.A. and of course VTune though it probably is not considered to be existing as it's not open source). And assuming this movement towards GuC is it not too late to invent a completely new way to provide tools with scheduling info from kmd? Could we just improve the existing way and let it live its last years\months? Hi, You actually mentioned the prime reason why we should not go and hastily make tracepoints a stable uAPI with regards to scheduling information. The scheduler's nature will be evolving when some of the scheduling decisions are moved to GuC and the way how we get the information will be changing at that point, so tracepoints will indeed be a very bad mechanism for providing the information. The kernel scheduler is definitely not going anywhere with the introduction of more hardware scheduling capabilities, so it is a misconception to think that the interface would need to be completely different for when GuC is enabled. On the last paragraph - even with the today's GuC i915 already loses visibility of CSB interrupts. So there is already a big difference in semantics of what request_in and request_out tracepoints mean. Put preemption into the picture and we just don't know any more when something started executing on the GPU, when it got preempted, re-submitted etc. So I think it is fair to say that moving more of scheduling into the GuC creates a problem for tools which want to represent request execution timelines. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC v4 3/8] drm: Add Plane CTM property
ons 2018-08-22 klockan 12:11 +0100 skrev Brian Starkey:
> Hi,
>
> On Wed, Aug 22, 2018 at 12:53:58PM +0300, Ville Syrjälä wrote:
> > On Wed, Aug 22, 2018 at 08:40:19AM +, Lankhorst, Maarten wrote:
> > > fre 2018-08-17 klockan 19:48 +0530 skrev Uma Shankar:
> > > > Add a blob property for plane CSC usage.
> > > >
> > > > v2: Rebase
> > > >
> > > > v3: Fixed Sean, Paul's review comments. Moved the property from
> > > > mode_config to drm_plane. Created a helper function to
> > > > instantiate
> > > > these properties and removed from
> > > > drm_mode_create_standard_properties
> > > > Added property documentation as suggested by Daniel, Vetter.
> > > >
> > > > v4: Rebase
> > > >
> > > > Signed-off-by: Uma Shankar
> > > > ---
> > > > Documentation/gpu/drm-kms.rst | 3 +++
> > > > drivers/gpu/drm/drm_atomic.c| 10 ++
> > > > drivers/gpu/drm/drm_atomic_helper.c | 4
> > > > drivers/gpu/drm/drm_plane.c | 12
> > > > include/drm/drm_plane.h | 15 +++
> > > > 5 files changed, 44 insertions(+)
> > > >
> > > > diff --git a/Documentation/gpu/drm-kms.rst
> > > > b/Documentation/gpu/drm-
> > > > kms.rst
> > > > index 8b10b12..16d6d8d 100644
> > > > --- a/Documentation/gpu/drm-kms.rst
> > > > +++ b/Documentation/gpu/drm-kms.rst
> > > > @@ -560,6 +560,9 @@ Plane Color Management Properties
> > > > .. kernel-doc:: drivers/gpu/drm/drm_plane.c
> > > > :doc: degamma_lut_size_property
> > > >
> > > > +.. kernel-doc:: drivers/gpu/drm/drm_plane.c
> > > > + :doc: ctm_property
> > > > +
> > > > Tile Group Property
> > > > ---
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_atomic.c
> > > > b/drivers/gpu/drm/drm_atomic.c
> > > > index f8cad9b..ddda935 100644
> > > > --- a/drivers/gpu/drm/drm_atomic.c
> > > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > > @@ -917,6 +917,14 @@ static int
> > > > drm_atomic_plane_set_property(struct
> > > > drm_plane *plane,
> > > > &replaced);
> > > > state->color_mgmt_changed |= replaced;
> > > > return ret;
> > > > + } else if (property == plane->ctm_property) {
> > > > + ret =
> > > > drm_atomic_replace_property_blob_from_id(dev,
> > > > + &state->ctm,
> > > > + val,
> > > > + sizeof(struct
> > > > drm_color_ctm), -1,
> > > > + &replaced);
> > > > + state->color_mgmt_changed |= replaced;
> > > > + return ret;
> > > > } else if (plane->funcs->atomic_set_property) {
> > > > return plane->funcs-
> > > > >atomic_set_property(plane,
> > > > state,
> > > > property, val);
> > > > @@ -988,6 +996,8 @@ static int
> > > > drm_atomic_plane_set_property(struct
> > > > drm_plane *plane,
> > > > } else if (property == plane->degamma_lut_property) {
> > > > *val = (state->degamma_lut) ?
> > > > state->degamma_lut->base.id : 0;
> > > > + } else if (property == plane->ctm_property) {
> > > > + *val = (state->ctm) ? state->ctm->base.id : 0;
> > > > } else if (plane->funcs->atomic_get_property) {
> > > > return plane->funcs-
> > > > >atomic_get_property(plane,
> > > > state, property, val);
> > > > } else {
> > > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > > > b/drivers/gpu/drm/drm_atomic_helper.c
> > > > index 67c5b51..866181f 100644
> > > > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > > @@ -3616,6 +3616,9 @@ void
> > > > __drm_atomic_helper_plane_duplicate_state(struct drm_plane
> > > > *plane,
> > > >
> > > > if (state->degamma_lut)
> > > > drm_property_blob_get(state->degamma_lut);
> > > > + if (state->ctm)
> > > > + drm_property_blob_get(state->ctm);
> > > > +
> > > > state->color_mgmt_changed = false;
> > > > }
> > > > EXPORT_SYMBOL(__drm_atomic_helper_plane_duplicate_state);
> > > > @@ -3663,6 +3666,7 @@ void
> > > > __drm_atomic_helper_plane_destroy_state(struct drm_plane_state
> > > > *state)
> > > > drm_crtc_commit_put(state->commit);
> > > >
> > > > drm_property_blob_put(state->degamma_lut);
> > > > + drm_property_blob_put(state->ctm);
> > > > }
> > > > EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_plane.c
> > > > b/drivers/gpu/drm/drm_plane.c
> > > > index 03e0560..97520b1 100644
> > > > --- a/drivers/gpu/drm/drm_plane.c
> > > > +++ b/drivers/gpu/drm/drm_plane.c
> > > > @@ -489,6 +489,11 @@ int drm_mode_plane_set_obj_prop(struct
> > > > drm_plane
> > > > *plane,
> > > > *
> > > > * degamma_lut_size_property:
> > > > * Range Property to indicate size of the p
Re: [Intel-gfx] [PATCH 4/4] drm/fb: Stop leaking physical address
On Wed, Aug 22, 2018 at 10:54:05AM +0200, Daniel Vetter wrote: > For buffer sharing, use dma-buf instead. We can't set smem_start to 0 > unconditionally since that's used by the fbdev mmap default > implementation. And we have plenty of userspace which would like to > keep that working. > > This might break legit userspace - if it does we need to look at a > case-by-cases basis how to handle that. Worst case I expect overrides > for only specific drivers, since anything remotely modern should be > using dma-buf/prime now (which is about 7 years old now for DRM > drivers). > > This issue was uncovered because Noralf's rework to implement a > generic fb_probe also implements it's own fb_mmap callback. Which > means smem_start didn't have to be set anymore, which blew up some > blob in userspace rather badly. > > Cc: Gustavo Padovan > Cc: Maarten Lankhorst > Cc: Sean Paul > Cc: David Airlie > Cc: John Stultz > Cc: Noralf Trønnes > Signed-off-by: Daniel Vetter After clarifying on IRC, I think this makes sense. The chance to break userspace requires a very specific configuration that I don't expect will be common. Acked-by: Sean Paul > --- > drivers/gpu/drm/drm_fb_helper.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c > index 4b0dd20bccb8..bcb78693c4f7 100644 > --- a/drivers/gpu/drm/drm_fb_helper.c > +++ b/drivers/gpu/drm/drm_fb_helper.c > @@ -2673,6 +2673,8 @@ __drm_fb_helper_initial_config_and_unlock(struct > drm_fb_helper *fb_helper, > > info = fb_helper->fbdev; > info->var.pixclock = 0; > + /* don't leak any physical addresses to userspace */ > + info->flags |= FBINFO_HIDE_SMEM_START; > > /* Need to drop locks to avoid recursive deadlock in >* register_framebuffer. This is ok because the only thing left to do is > -- > 2.18.0 > -- Sean Paul, Software Engineer, Google / Chromium OS ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/5] drm/i915/kbl+: Enable IPC only for symmetric memory configurations
Hi,
On 8/22/2018 12:26 AM, Rodrigo Vivi wrote:
On Tue, Aug 21, 2018 at 09:30:21PM +0530, Kumar, Mahesh wrote:
Hi,
On 8/21/2018 8:27 PM, Kumar, Mahesh wrote:
Hi,
On 8/17/2018 11:50 PM, Rodrigo Vivi wrote:
On Thu, Jul 26, 2018 at 07:44:09PM +0530, Mahesh Kumar wrote:
IPC may cause underflows if not used with dual channel symmetric
memory configuration. Disable IPC for non symmetric configurations in
affected platforms.
Display WA #1141
Signed-off-by: Mahesh Kumar
---
drivers/gpu/drm/i915/i915_drv.c | 43
-
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 2 +-
3 files changed, 40 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c
b/drivers/gpu/drm/i915/i915_drv.c
index 86bc2e685522..2273664166bc 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1141,21 +1141,47 @@ skl_dram_get_channel_info(struct
dram_channel_info *ch, u32 val)
return 0;
}
+static bool
+intel_is_dram_ipc_capable(struct drm_i915_private *dev_priv,
+ u32 val_ch0, u32 val_ch1,
+ struct dram_channel_info *ch0)
what about
intel_is_dram_symmetric() ?
sounds good.
+{
+ /* Display WA #1141: SKL:all KBL:all CNL:A CNL:B */
move this to the wa call, not the the function check...
+ if (INTEL_GEN(dev_priv) > 9 &&
+ !IS_CNL_REVID(dev_priv, CNL_REVID_A0, CNL_REVID_B0))
please don't add CNL pre-prod wa
ok sure
+ return true;
+
+ if (!IS_KABYLAKE(dev_priv) && !IS_SKYLAKE(dev_priv))
+ return true;
actually remove all platforms checks here...
Agree will remove these checks, function will just return if memory is
symmetric.
+
+ if (val_ch0 != val_ch1)
+ return false;
+
+ if (ch0->s_info.size == 0)
+ return true;
+ if (ch0->l_info.size == ch0->s_info.size &&
+ ch0->l_info.width == ch0->s_info.width &&
+ ch0->l_info.rank == ch0->s_info.rank)
+ return true;
+
+ return false;
return (val_ch0 == val_ch1 && (ch0->s_info.size == 0 ||
(ch0->l_info.size == ch0->s_info.size &&
ch0->l_info.width == ch0->s_info.width &&
ch0->l_info.rank == ch0->s_info.rank)))
+}
+
static int
skl_dram_get_channels_info(struct drm_i915_private *dev_priv)
{
struct dram_info *dram_info = &dev_priv->dram_info;
struct dram_channel_info ch0, ch1;
- u32 val;
+ u32 val_ch0, val_ch1;
int ret;
- val = I915_READ(SKL_MAD_DIMM_CH0_0_0_0_MCHBAR_MCMAIN);
- ret = skl_dram_get_channel_info(&ch0, val);
+ val_ch0 = I915_READ(SKL_MAD_DIMM_CH0_0_0_0_MCHBAR_MCMAIN);
+ ret = skl_dram_get_channel_info(&ch0, val_ch0);
if (ret == 0)
dram_info->num_channels++;
- val = I915_READ(SKL_MAD_DIMM_CH1_0_0_0_MCHBAR_MCMAIN);
- ret = skl_dram_get_channel_info(&ch1, val);
+ val_ch1 = I915_READ(SKL_MAD_DIMM_CH1_0_0_0_MCHBAR_MCMAIN);
+ ret = skl_dram_get_channel_info(&ch1, val_ch1);
if (ret == 0)
dram_info->num_channels++;
@@ -1185,6 +1211,13 @@ skl_dram_get_channels_info(struct
drm_i915_private *dev_priv)
if (ch0.is_16gb_dimm || ch1.is_16gb_dimm)
dram_info->is_16gb_dimm = true;
+ if (intel_is_dram_ipc_capable(dev_priv, val_ch0, val_ch1, &ch0))
+ dev_priv->ipc_capable_mem = true;
+ else
+ dev_priv->ipc_capable_mem = false;
+
+ DRM_DEBUG_KMS("memory configuration is %sIPC capable\n",
+ dev_priv->ipc_capable_mem ? "" : "not ");
return 0;
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 854f3c828e01..036d6554c017 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2112,6 +2112,7 @@ struct drm_i915_private {
bool chv_phy_assert[2];
bool ipc_enabled;
+ bool ipc_capable_mem;
I don't think we need to stage this...
With above changes storing this info is not needed, But we need to keep
a flag in dram_info to check if "memory is symmetric", Otherwise we need
to compute all the memory related info again.
-Mahesh
/* Used to save the pipe-to-encoder mapping for audio */
struct intel_encoder *av_enc_map[I915_MAX_PIPES];
diff --git a/drivers/gpu/drm/i915/intel_pm.c
b/drivers/gpu/drm/i915/intel_pm.c
index 2446f53adf21..39e400d5f555 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6097,7 +6097,7 @@ void intel_enable_ipc(struct
drm_i915_private *dev_priv)
u32 val;
/* Display WA #0477 WaDisableIPC: skl */
- if (IS_SKYLAKE(dev_priv)) {
+ if (IS_SKYLAKE(dev_priv) || !dev_priv->ipc_capable_mem) {
dev_priv->ipc_enabled = false;
This is not the WA 1141 for other platforms than SKL. Please only
keep skl here.
For the other WA add 4us across all watermark levels
/* Display WA #1141: skl,kbl,cfl */
if ((IS_KABYLAKE(dev_priv) || IS_COFFEELAKE(dev_priv)) &&
intel_is_dram_symmetric())
levels += 4;
Addi
Re: [Intel-gfx] [PATCH 2/2] drm/i915/tracepoints: Remove DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig option
On 22/08/2018 13:49, Tvrtko Ursulin wrote: On 21/08/2018 13:06, Joonas Lahtinen wrote: Quoting Kukanova, Svetlana (2018-08-13 16:44:49) Joonas, sorry for interfering; could you please explain more regarding the options for tracing scheduling events better than tracepoints? After scheduling moves to GuC tools will have to switch to something like GuC-logging; but while kmd does scheduling isn't kernel-tracing the best solution? I know gpuvis is not the only attempt to use tracepoints for the same purpose. (there're trace.pl and S.E.A. and of course VTune though it probably is not considered to be existing as it's not open source). And assuming this movement towards GuC is it not too late to invent a completely new way to provide tools with scheduling info from kmd? Could we just improve the existing way and let it live its last years\months? Hi, You actually mentioned the prime reason why we should not go and hastily make tracepoints a stable uAPI with regards to scheduling information. The scheduler's nature will be evolving when some of the scheduling decisions are moved to GuC and the way how we get the information will be changing at that point, so tracepoints will indeed be a very bad mechanism for providing the information. The kernel scheduler is definitely not going anywhere with the introduction of more hardware scheduling capabilities, so it is a misconception to think that the interface would need to be completely different for when GuC is enabled. On the last paragraph - even with the today's GuC i915 already loses visibility of CSB interrupts. So there is already a big difference in semantics of what request_in and request_out tracepoints mean. Put preemption into the picture and we just don't know any more when something started executing on the GPU, when it got preempted, re-submitted etc. So I think it is fair to say that moving more of scheduling into the GuC creates a problem for tools which want to represent request execution timelines. P.S. To clarify - which is exactly why we marked those tracpoints as low level and why it is problematic to rely on them. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] RFC: Migration to Gitlab
On Wed, Aug 22, 2018 at 01:44:56PM +0200, Daniel Vetter wrote: > Hi all, > > I think it's time to brainstorm a bit about the gitlab migration. Basic > reasons: > > - fd.o admins want to deprecate shell accounts and hand-rolled > infrastructure, because it's a pain to keep secure&updated. > > - gitlab will allow us to add committers on our own, greatly > simplifying that process (and offloading that task from fd.o admins). > > There's also some more benefits we might want to reap, like better CI > integration for basic build testing - no more "oops didn't build > drm-misc defconfigs" or "sry, forgot make check in maintainer-tools". > But that's all fully optional. > > For the full in-depth writeup of everything, see > > https://www.fooishbar.org/blog/gitlab-fdo-introduction/ > > I think now is also a good time, with mesa, xorg, wayland/weston and > others moved, to start thinking about how we'll move drm. There's a > few things to figure out though: > > - We probably want to split out maintainer-tools. That would address > the concern that there's 50+ committers to an auto-updating shell > script ... > /me laughs nervously > - We need to figure out how to handle the ACL trickery around drm-tip in > gitlab. > > - Probably good to stage the migration, with maintainer-tools, igt > leading. That will also make fd.o admins happy, who want to rework > their cloud infrastructure a bit before migrating the big kernel repos > over. > > - Figuring out the actual migration - we've been adding a pile of > committers since fd.o LDAP was converted to gitlab once back in > spring. We need to at least figure out how to move the new > accounts/committers. > > - Similar, maintainer-tools needs to move. We probably want to move > all the dim maintained kernel repos in one go, to avoid headaches with > double-accounts needed for committers. > > - CI, linux-next and everyone else should be fine, since the > cgit/non-ssh paths will keep working (they'll be read-only mirrors). > Need to double-check that with everyone. They can also pull the trees from git://gitlab.fd.o/blah as normal, just need to give them new pointers once we're stable. > > - Some organization structure would be good. > > https://cgit.freedesktop.org/drm > > libdrm won't be part of the gitlab drm group because that's already > moved under mesa (and you can't symlink/mulit-home anymore on gitlab): > > https://gitlab.freedesktop.org/mesa/drm > > But there's also drm_hwcomposer, which we might want to migrate into > drm too - gitlab requires a containing group, and > drm_hwcomposer/drm_hwcomposer is a bit silly. This seems fine to me. Our expansion plans likely aren't big enough to warrant a separate group. > > Note: Access rights can be done at any level in the hierarchy, the > organization is orthogonal to commit rights. > > - Anything else I've forgotten. > > A lot of this still needs to be figured out first. As a first step I'm > looking for volunteers who want to join the fun, besides comments and > thoughts on the overall topic of course. I'm pretty keen on getting this done, so I'll volunteer some cycles if there's something that needs doing. Sean > > Cheers, Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Sean Paul, Software Engineer, Google / Chromium OS ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/tracepoints: Remove DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig option
Quoting Tvrtko Ursulin (2018-08-22 15:49:52) > > On 21/08/2018 13:06, Joonas Lahtinen wrote: > > Quoting Kukanova, Svetlana (2018-08-13 16:44:49) > >> Joonas, sorry for interfering; could you please explain more regarding the > >> options for tracing scheduling events better than tracepoints? > >> After scheduling moves to GuC tools will have to switch to something like > >> GuC-logging; but while kmd does scheduling isn't kernel-tracing the best > >> solution? > >> I know gpuvis is not the only attempt to use tracepoints for the same > >> purpose. > >> (there're trace.pl and S.E.A. and of course VTune though it probably is not > >> considered to be existing as it's not open source). > >> And assuming this movement towards GuC is it not too late to invent a > >> completely new way to provide tools with scheduling info from kmd? > >> Could we just improve the existing way and let it live its last > >> years\months? > > > > Hi, > > > > You actually mentioned the prime reason why we should not go and > > hastily make tracepoints a stable uAPI with regards to scheduling > > information. > > > > The scheduler's nature will be evolving when some of the scheduling > > decisions are moved to GuC and the way how we get the information > > will be changing at that point, so tracepoints will indeed be a > > very bad mechanism for providing the information. > > > > The kernel scheduler is definitely not going anywhere with the > > introduction of more hardware scheduling capabilities, so it is a > > misconception to think that the interface would need to be completely > > different for when GuC is enabled. To clarify, I meant to underline that there is not going to be a steep switching point where a transition from interface A to B, which Svetlana referred to, would happen naturally. The introduced interface will have to provide the information for years and kernel versions to come, and we already have a some data that tracepoints may not be the format of choice due to GuC. > On the last paragraph - even with the today's GuC i915 already loses > visibility of CSB interrupts. So there is already a big difference in > semantics of what request_in and request_out tracepoints mean. Put > preemption into the picture and we just don't know any more when > something started executing on the GPU, when it got preempted, > re-submitted etc. So I think it is fair to say that moving more of > scheduling into the GuC creates a problem for tools which want to > represent request execution timelines. Yes, for tools that depend on the tracepoints. That's why it is most likely best to introduce the information in some other form, but I am starting to sound like a broken record already :) Regards, Joonas > > Regards, > > Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC v4 3/8] drm: Add Plane CTM property
On Wed, Aug 22, 2018 at 12:11:42PM +0100, Brian Starkey wrote:
> Hi,
>
> On Wed, Aug 22, 2018 at 12:53:58PM +0300, Ville Syrjälä wrote:
> >On Wed, Aug 22, 2018 at 08:40:19AM +, Lankhorst, Maarten wrote:
> >> fre 2018-08-17 klockan 19:48 +0530 skrev Uma Shankar:
> >> > Add a blob property for plane CSC usage.
> >> >
> >> > v2: Rebase
> >> >
> >> > v3: Fixed Sean, Paul's review comments. Moved the property from
> >> > mode_config to drm_plane. Created a helper function to instantiate
> >> > these properties and removed from drm_mode_create_standard_properties
> >> > Added property documentation as suggested by Daniel, Vetter.
> >> >
> >> > v4: Rebase
> >> >
> >> > Signed-off-by: Uma Shankar
> >> > ---
> >> > Documentation/gpu/drm-kms.rst | 3 +++
> >> > drivers/gpu/drm/drm_atomic.c| 10 ++
> >> > drivers/gpu/drm/drm_atomic_helper.c | 4
> >> > drivers/gpu/drm/drm_plane.c | 12
> >> > include/drm/drm_plane.h | 15 +++
> >> > 5 files changed, 44 insertions(+)
> >> >
> >> > diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-
> >> > kms.rst
> >> > index 8b10b12..16d6d8d 100644
> >> > --- a/Documentation/gpu/drm-kms.rst
> >> > +++ b/Documentation/gpu/drm-kms.rst
> >> > @@ -560,6 +560,9 @@ Plane Color Management Properties
> >> > .. kernel-doc:: drivers/gpu/drm/drm_plane.c
> >> > :doc: degamma_lut_size_property
> >> >
> >> > +.. kernel-doc:: drivers/gpu/drm/drm_plane.c
> >> > + :doc: ctm_property
> >> > +
> >> > Tile Group Property
> >> > ---
> >> >
> >> > diff --git a/drivers/gpu/drm/drm_atomic.c
> >> > b/drivers/gpu/drm/drm_atomic.c
> >> > index f8cad9b..ddda935 100644
> >> > --- a/drivers/gpu/drm/drm_atomic.c
> >> > +++ b/drivers/gpu/drm/drm_atomic.c
> >> > @@ -917,6 +917,14 @@ static int drm_atomic_plane_set_property(struct
> >> > drm_plane *plane,
> >> > &replaced);
> >> > state->color_mgmt_changed |= replaced;
> >> > return ret;
> >> > +} else if (property == plane->ctm_property) {
> >> > +ret = drm_atomic_replace_property_blob_from_id(dev,
> >> > +&state->ctm,
> >> > +val,
> >> > +sizeof(struct
> >> > drm_color_ctm), -1,
> >> > +&replaced);
> >> > +state->color_mgmt_changed |= replaced;
> >> > +return ret;
> >> > } else if (plane->funcs->atomic_set_property) {
> >> > return plane->funcs->atomic_set_property(plane,
> >> > state,
> >> > property, val);
> >> > @@ -988,6 +996,8 @@ static int drm_atomic_plane_set_property(struct
> >> > drm_plane *plane,
> >> > } else if (property == plane->degamma_lut_property) {
> >> > *val = (state->degamma_lut) ?
> >> > state->degamma_lut->base.id : 0;
> >> > +} else if (property == plane->ctm_property) {
> >> > +*val = (state->ctm) ? state->ctm->base.id : 0;
> >> > } else if (plane->funcs->atomic_get_property) {
> >> > return plane->funcs->atomic_get_property(plane,
> >> > state, property, val);
> >> > } else {
> >> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> >> > b/drivers/gpu/drm/drm_atomic_helper.c
> >> > index 67c5b51..866181f 100644
> >> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> >> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> >> > @@ -3616,6 +3616,9 @@ void
> >> > __drm_atomic_helper_plane_duplicate_state(struct drm_plane *plane,
> >> >
> >> > if (state->degamma_lut)
> >> > drm_property_blob_get(state->degamma_lut);
> >> > +if (state->ctm)
> >> > +drm_property_blob_get(state->ctm);
> >> > +
> >> > state->color_mgmt_changed = false;
> >> > }
> >> > EXPORT_SYMBOL(__drm_atomic_helper_plane_duplicate_state);
> >> > @@ -3663,6 +3666,7 @@ void
> >> > __drm_atomic_helper_plane_destroy_state(struct drm_plane_state
> >> > *state)
> >> > drm_crtc_commit_put(state->commit);
> >> >
> >> > drm_property_blob_put(state->degamma_lut);
> >> > +drm_property_blob_put(state->ctm);
> >> > }
> >> > EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
> >> >
> >> > diff --git a/drivers/gpu/drm/drm_plane.c
> >> > b/drivers/gpu/drm/drm_plane.c
> >> > index 03e0560..97520b1 100644
> >> > --- a/drivers/gpu/drm/drm_plane.c
> >> > +++ b/drivers/gpu/drm/drm_plane.c
> >> > @@ -489,6 +489,11 @@ int drm_mode_plane_set_obj_prop(struct drm_plane
> >> > *plane,
> >> > *
> >> > * degamma_lut_size_property:
> >> > * Range Property to indicate size of the plane degamma LUT.
> >> > + *
> >> > + * ctm_property:
> >> > + * Blob property which allows a userspace to provide CTM
> >> > coefficients
> >> > + * t
Re: [Intel-gfx] [igt-dev] RFC: Migration to Gitlab
On Wed, 22 Aug 2018, Daniel Vetter wrote: > Hi all, > > I think it's time to brainstorm a bit about the gitlab migration. Basic > reasons: > > - fd.o admins want to deprecate shell accounts and hand-rolled > infrastructure, because it's a pain to keep secure&updated. > > - gitlab will allow us to add committers on our own, greatly > simplifying that process (and offloading that task from fd.o admins). > > There's also some more benefits we might want to reap, like better CI > integration for basic build testing - no more "oops didn't build > drm-misc defconfigs" or "sry, forgot make check in maintainer-tools". > But that's all fully optional. > > For the full in-depth writeup of everything, see > > https://www.fooishbar.org/blog/gitlab-fdo-introduction/ > > I think now is also a good time, with mesa, xorg, wayland/weston and > others moved, to start thinking about how we'll move drm. There's a > few things to figure out though: > > - We probably want to split out maintainer-tools. That would address > the concern that there's 50+ committers to an auto-updating shell > script ... > > - We need to figure out how to handle the ACL trickery around drm-tip in > gitlab. > > - Probably good to stage the migration, with maintainer-tools, igt > leading. That will also make fd.o admins happy, who want to rework > their cloud infrastructure a bit before migrating the big kernel repos > over. > > - Figuring out the actual migration - we've been adding a pile of > committers since fd.o LDAP was converted to gitlab once back in > spring. We need to at least figure out how to move the new > accounts/committers. > > - Similar, maintainer-tools needs to move. We probably want to move > all the dim maintained kernel repos in one go, to avoid headaches with > double-accounts needed for committers. > > - CI, linux-next and everyone else should be fine, since the > cgit/non-ssh paths will keep working (they'll be read-only mirrors). > Need to double-check that with everyone. > > - Some organization structure would be good. > > https://cgit.freedesktop.org/drm > > libdrm won't be part of the gitlab drm group because that's already > moved under mesa (and you can't symlink/mulit-home anymore on gitlab): > > https://gitlab.freedesktop.org/mesa/drm > > But there's also drm_hwcomposer, which we might want to migrate into > drm too - gitlab requires a containing group, and > drm_hwcomposer/drm_hwcomposer is a bit silly. > > Note: Access rights can be done at any level in the hierarchy, the > organization is orthogonal to commit rights. > > - Anything else I've forgotten. > > A lot of this still needs to be figured out first. As a first step I'm > looking for volunteers who want to join the fun, besides comments and > thoughts on the overall topic of course. Just a couple of concerns from drm/i915 perspective for starters: - Patchwork integration. I think we'll want to keep patchwork for at least intel-gfx etc. for the time being. IIUC the one thing we need is some server side hook to update patchwork on git push. - Sticking to fdo bugzilla and disabling gitlab issues for at least drm-intel for the time being. Doing that migration in the same go is a bit much I think. Reassignment across bugzilla and gitlab will be an issue. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Correct CSB probing for engine state dumper
Chris Wilson writes:
> Quoting Mika Kuoppala (2018-08-21 08:58:26)
>> Chris Wilson writes:
>>
>> > Since we no longer maintain our read position in the CSB pointers
>> > register, it always returns 0 and not where we last read up to. As a
>> > result the CSB probing in the state dumper starts from 0, either missing
>> > entries or showing stale one.
>> >
>> > Signed-off-by: Chris Wilson
>> > Cc: Mika Kuoppala
>> > ---
>> > drivers/gpu/drm/i915/intel_engine_cs.c | 24
>> > 1 file changed, 12 insertions(+), 12 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
>> > b/drivers/gpu/drm/i915/intel_engine_cs.c
>> > index 8628567d8f6e..49b580c188eb 100644
>> > --- a/drivers/gpu/drm/i915/intel_engine_cs.c
>> > +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
>> > @@ -1345,20 +1345,20 @@ static void intel_engine_print_registers(const
>> > struct intel_engine_cs *engine,
>> >
>> > if (HAS_EXECLISTS(dev_priv)) {
>> > const u32 *hws =
>> > &engine->status_page.page_addr[I915_HWS_CSB_BUF0_INDEX];
>> > - u32 ptr, read, write;
>> > unsigned int idx;
>> > + u8 read, write;
>> >
>> > drm_printf(m, "\tExeclist status: 0x%08x %08x\n",
>> > I915_READ(RING_EXECLIST_STATUS_LO(engine)),
>> > I915_READ(RING_EXECLIST_STATUS_HI(engine)));
>> >
>> > - ptr = I915_READ(RING_CONTEXT_STATUS_PTR(engine));
>> > - read = GEN8_CSB_READ_PTR(ptr);
>> > - write = GEN8_CSB_WRITE_PTR(ptr);
>> > - drm_printf(m, "\tExeclist CSB read %d [%d cached], write %d
>> > [%d from hws], tasklet queued? %s (%s)\n",
>> > -read, execlists->csb_head,
>> > -write,
>> > -intel_read_status_page(engine,
>> > intel_hws_csb_write_index(engine->i915)),
>> > + read = execlists->csb_head;
>> > + write = intel_read_status_page(engine,
>> > +
>> > intel_hws_csb_write_index(dev_priv));
>> > +
>> > + drm_printf(m, "\tExeclist CSB read %d, write %d [mmio:%d],
>> > tasklet queued? %s (%s)\n",
>> > +read, write,
>>
>> In here I was thinking that we want to keep the write as 32bit so it
>> would show weirdness in here with %d. But the odds of that to happen
>> with only in this status page entry...
>
> Hmm, it was u8 for automatically truncating execlists->csb_write...
> Oh, this should have been write = READ_ONCE(*execlists->csb_write);
>
> Mind if I make that change?
Please do.
-Mika
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gtt: Setup guards in scratch page
There have been cases where GPU engine has managed to run past
execbuffer ending due to reasons unknown at that time:
coherency problems, page table setup errors, hw glitches.
Let's try to contain a wild engine head by putting batch
buffer end commands into start and end of scratch page.
Leave two nops at start of page so it would catch the
eye on error dumps.
Cc: Chris Wilson
Cc: Matthew Auld
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 4137af4bd8f5..56399dbf4558 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -617,6 +617,21 @@ static void fill_page_dma_32(struct i915_address_space *vm,
fill_page_dma(vm, p, (u64)v << 32 | v);
}
+static void setup_scratch_page_guards(struct i915_address_space *vm)
+{
+ struct i915_page_dma const *p = &vm->scratch_page;
+ u32 *scratch;
+ const unsigned int size = BIT(p->order) << PAGE_SHIFT;
+ const unsigned int last_idx = size / sizeof(*scratch) - 1;
+
+ scratch = kmap_atomic(p->page);
+
+ scratch[2] = MI_BATCH_BUFFER_END;
+ scratch[last_idx] = MI_BATCH_BUFFER_END;
+
+ kunmap_atomic(scratch);
+}
+
static int
setup_scratch_page(struct i915_address_space *vm, gfp_t gfp)
{
@@ -665,6 +680,9 @@ setup_scratch_page(struct i915_address_space *vm, gfp_t gfp)
vm->scratch_page.page = page;
vm->scratch_page.daddr = addr;
vm->scratch_page.order = order;
+
+ setup_scratch_page_guards(vm);
+
return 0;
unmap_page:
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gtt: Setup guards in scratch page
There have been cases where GPU engine has managed to run past
execbuffer ending due to reasons unknown at that time:
coherency problems, page table setup errors, hw glitches.
Let's try to contain a wild engine head by putting batch
buffer end commands into start and end of scratch page.
v2: add more signature
Cc: Chris Wilson
Cc: Matthew Auld
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 4137af4bd8f5..3c617874ee7c 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -617,6 +617,24 @@ static void fill_page_dma_32(struct i915_address_space *vm,
fill_page_dma(vm, p, (u64)v << 32 | v);
}
+static void setup_scratch_page_guards(struct i915_address_space *vm)
+{
+ struct i915_page_dma const *p = &vm->scratch_page;
+ u32 *scratch;
+ const unsigned int size = BIT(p->order) << PAGE_SHIFT;
+ const unsigned int last_idx = size / sizeof(*scratch) - 1;
+
+ scratch = kmap_atomic(p->page);
+
+ scratch[0] = MI_BATCH_BUFFER_END;
+ scratch[1] = MI_BATCH_BUFFER_END;
+
+ scratch[last_idx - 1] = MI_BATCH_BUFFER_END;
+ scratch[last_idx] = MI_BATCH_BUFFER_END;
+
+ kunmap_atomic(scratch);
+}
+
static int
setup_scratch_page(struct i915_address_space *vm, gfp_t gfp)
{
@@ -665,6 +683,9 @@ setup_scratch_page(struct i915_address_space *vm, gfp_t gfp)
vm->scratch_page.page = page;
vm->scratch_page.daddr = addr;
vm->scratch_page.order = order;
+
+ setup_scratch_page_guards(vm);
+
return 0;
unmap_page:
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/gtt: Setup guards in scratch page (rev2)
== Series Details == Series: drm/i915/gtt: Setup guards in scratch page (rev2) URL : https://patchwork.freedesktop.org/series/48565/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915/gtt: Setup guards in scratch page +drivers/gpu/drm/i915/i915_gem_gtt.c:1017:9: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem_gtt.c:1017:9: warning: expression using sizeof(void) -drivers/gpu/drm/i915/i915_gem_gtt.c:1017:9: warning: expression using sizeof(void) -drivers/gpu/drm/i915/i915_gem_gtt.c:1017:9: warning: expression using sizeof(void) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gtt: Setup guards in scratch page
Quoting Mika Kuoppala (2018-08-22 14:27:14) > There have been cases where GPU engine has managed to run past > execbuffer ending due to reasons unknown at that time: > coherency problems, page table setup errors, hw glitches. You are trading an obvious error for a subtle one; if userspace got its batch wrong and doesn't die, the output will likely be wrong instead. mesa/src/intel/tools/intel_sanitize_gpu for how userspace could do this detection itself. You can intercept the execbuf, place a canary after the batch and report if the canary gets written. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gtt: Setup guards in scratch page (rev2)
== Series Details ==
Series: drm/i915/gtt: Setup guards in scratch page (rev2)
URL : https://patchwork.freedesktop.org/series/48565/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4695 -> Patchwork_9990 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/48565/revisions/2/mbox/
== Possible new issues ==
Here are the unknown changes that may have been introduced in Patchwork_9990:
=== IGT changes ===
Possible regressions
{igt@pm_rpm@module-reload}:
fi-byt-j1900: NOTRUN -> DMESG-WARN
== Known issues ==
Here are the changes found in Patchwork_9990 that come from known issues:
=== IGT changes ===
Issues hit
igt@drv_selftest@live_coherency:
fi-gdg-551: PASS -> DMESG-FAIL (fdo#107164)
igt@drv_selftest@live_hangcheck:
fi-kbl-7560u: PASS -> DMESG-FAIL (fdo#106947, fdo#106560)
fi-skl-guc: PASS -> DMESG-FAIL (fdo#107174)
{igt@kms_psr@primary_page_flip}:
{fi-icl-u}: NOTRUN -> FAIL (fdo#107383) +3
{igt@pm_rpm@module-reload}:
fi-cnl-psr: PASS -> WARN (fdo#107602)
Possible fixes
igt@drv_selftest@live_hangcheck:
{fi-cfl-8109u}: DMESG-FAIL (fdo#106560) -> PASS
igt@kms_frontbuffer_tracking@basic:
{fi-byt-clapper}: FAIL (fdo#103167) -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560
fdo#106947 https://bugs.freedesktop.org/show_bug.cgi?id=106947
fdo#107164 https://bugs.freedesktop.org/show_bug.cgi?id=107164
fdo#107174 https://bugs.freedesktop.org/show_bug.cgi?id=107174
fdo#107383 https://bugs.freedesktop.org/show_bug.cgi?id=107383
fdo#107602 https://bugs.freedesktop.org/show_bug.cgi?id=107602
== Participating hosts (52 -> 48) ==
Additional (2): fi-byt-j1900 fi-icl-u
Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-bdw-samus
== Build changes ==
* Linux: CI_DRM_4695 -> Patchwork_9990
CI_DRM_4695: f352837700ec39dbaf00cdf727650851993d754b @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4608: 94ebd21177feedf03e8f6dd1e73dca1a6ec7a0ac @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9990: 39443beee0c02518071ab487cb3aa557dd9d5ce1 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
39443beee0c0 drm/i915/gtt: Setup guards in scratch page
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9990/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] RFC: Migration to Gitlab
On Wed, 2018-08-22 at 16:13 +0300, Jani Nikula wrote: > - Sticking to fdo bugzilla and disabling gitlab issues for at least > drm-intel for the time being. Doing that migration in the same go is a > bit much I think. Reassignment across bugzilla and gitlab will be an > issue. Can you elaborate a bit on the issues here? The actual move-the-bugs process has been pretty painless for the parts of xorg we've done so far. - ajax ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Fix subslice configuration on Gen9LP
From: Tvrtko Ursulin
According to the documentation, when programming the subslice count power-
gating configuration register, the value to be written into it on Gen9LP
should actually in the format of:
1 slice = 0x001
2 slices = 0x010
3 slices = 0x100
And not the popcount of the enabled subslice mask as on other platforms.
So on Gen9LP platforms we have been programming 0x11 into those bits, but
the documentation does not explain what would that achieve. Could it be
that we enable only two subslice on three sub-slice parts? Or hardware
simply ignores it and sticks with the maximum configuration?
Signed-off-by: Tvrtko Ursulin
Cc: Lionel Landwerlin
Bspec: 12247
---
Could this actually be true or I am severely misreading the docs? It does
not sound plausible to me this would have been missed all this time..
How to test in what configuration do these parts run before and after this
patch?
---
drivers/gpu/drm/i915/intel_lrc.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 36050f085071..cdfa962a1975 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2508,9 +2508,15 @@ make_rpcs(struct drm_i915_private *dev_priv)
}
if (INTEL_INFO(dev_priv)->sseu.has_subslice_pg) {
+ u8 val;
+
+ val = hweight8(INTEL_INFO(dev_priv)->sseu.subslice_mask[0]);
+
+ if (IS_GEN9_LP(dev_priv))
+ val = BIT(val - 1);
+
rpcs |= GEN8_RPCS_SS_CNT_ENABLE;
- rpcs |= hweight8(INTEL_INFO(dev_priv)->sseu.subslice_mask[0]) <<
- GEN8_RPCS_SS_CNT_SHIFT;
+ rpcs |= val << GEN8_RPCS_SS_CNT_SHIFT;
rpcs |= GEN8_RPCS_ENABLE;
}
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix subslice configuration on Gen9LP
On 22/08/18 15:29, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
According to the documentation, when programming the subslice count power-
gating configuration register, the value to be written into it on Gen9LP
should actually in the format of:
1 slice = 0x001
2 slices = 0x010
3 slices = 0x100
And not the popcount of the enabled subslice mask as on other platforms.
So on Gen9LP platforms we have been programming 0x11 into those bits, but
the documentation does not explain what would that achieve. Could it be
that we enable only two subslice on three sub-slice parts? Or hardware
simply ignores it and sticks with the maximum configuration?
Signed-off-by: Tvrtko Ursulin
Cc: Lionel Landwerlin
Bspec: 12247
If it does turn out to be broken and this the correct fix then:
Fixes: 0cea6502bf9c ("drm/i915: Request full SSEU enablement on Gen9")
?
At that time code looked like:
+ if (INTEL_INFO(dev)->has_subslice_pg) {
+ rpcs |= GEN8_RPCS_SS_CNT_ENABLE;
+ rpcs |= INTEL_INFO(dev)->subslice_per_slice <<
+ GEN8_RPCS_SS_CNT_SHIFT;
+ rpcs |= GEN8_RPCS_ENABLE;
+ }
So would had already most likely been broken.
Tvrtko
---
Could this actually be true or I am severely misreading the docs? It does
not sound plausible to me this would have been missed all this time..
How to test in what configuration do these parts run before and after this
patch?
---
drivers/gpu/drm/i915/intel_lrc.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 36050f085071..cdfa962a1975 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2508,9 +2508,15 @@ make_rpcs(struct drm_i915_private *dev_priv)
}
if (INTEL_INFO(dev_priv)->sseu.has_subslice_pg) {
+ u8 val;
+
+ val = hweight8(INTEL_INFO(dev_priv)->sseu.subslice_mask[0]);
+
+ if (IS_GEN9_LP(dev_priv))
+ val = BIT(val - 1);
+
rpcs |= GEN8_RPCS_SS_CNT_ENABLE;
- rpcs |= hweight8(INTEL_INFO(dev_priv)->sseu.subslice_mask[0]) <<
- GEN8_RPCS_SS_CNT_SHIFT;
+ rpcs |= val << GEN8_RPCS_SS_CNT_SHIFT;
rpcs |= GEN8_RPCS_ENABLE;
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] RFC: Migration to Gitlab
On Wed, Aug 22, 2018 at 3:13 PM, Jani Nikula wrote: > On Wed, 22 Aug 2018, Daniel Vetter wrote: >> Hi all, >> >> I think it's time to brainstorm a bit about the gitlab migration. Basic >> reasons: >> >> - fd.o admins want to deprecate shell accounts and hand-rolled >> infrastructure, because it's a pain to keep secure&updated. >> >> - gitlab will allow us to add committers on our own, greatly >> simplifying that process (and offloading that task from fd.o admins). >> >> There's also some more benefits we might want to reap, like better CI >> integration for basic build testing - no more "oops didn't build >> drm-misc defconfigs" or "sry, forgot make check in maintainer-tools". >> But that's all fully optional. >> >> For the full in-depth writeup of everything, see >> >> https://www.fooishbar.org/blog/gitlab-fdo-introduction/ >> >> I think now is also a good time, with mesa, xorg, wayland/weston and >> others moved, to start thinking about how we'll move drm. There's a >> few things to figure out though: >> >> - We probably want to split out maintainer-tools. That would address >> the concern that there's 50+ committers to an auto-updating shell >> script ... >> >> - We need to figure out how to handle the ACL trickery around drm-tip in >> gitlab. >> >> - Probably good to stage the migration, with maintainer-tools, igt >> leading. That will also make fd.o admins happy, who want to rework >> their cloud infrastructure a bit before migrating the big kernel repos >> over. >> >> - Figuring out the actual migration - we've been adding a pile of >> committers since fd.o LDAP was converted to gitlab once back in >> spring. We need to at least figure out how to move the new >> accounts/committers. >> >> - Similar, maintainer-tools needs to move. We probably want to move >> all the dim maintained kernel repos in one go, to avoid headaches with >> double-accounts needed for committers. >> >> - CI, linux-next and everyone else should be fine, since the >> cgit/non-ssh paths will keep working (they'll be read-only mirrors). >> Need to double-check that with everyone. >> >> - Some organization structure would be good. >> >> https://cgit.freedesktop.org/drm >> >> libdrm won't be part of the gitlab drm group because that's already >> moved under mesa (and you can't symlink/mulit-home anymore on gitlab): >> >> https://gitlab.freedesktop.org/mesa/drm >> >> But there's also drm_hwcomposer, which we might want to migrate into >> drm too - gitlab requires a containing group, and >> drm_hwcomposer/drm_hwcomposer is a bit silly. >> >> Note: Access rights can be done at any level in the hierarchy, the >> organization is orthogonal to commit rights. >> >> - Anything else I've forgotten. >> >> A lot of this still needs to be figured out first. As a first step I'm >> looking for volunteers who want to join the fun, besides comments and >> thoughts on the overall topic of course. > > Just a couple of concerns from drm/i915 perspective for starters: > > - Patchwork integration. I think we'll want to keep patchwork for at > least intel-gfx etc. for the time being. IIUC the one thing we need is > some server side hook to update patchwork on git push. > > - Sticking to fdo bugzilla and disabling gitlab issues for at least > drm-intel for the time being. Doing that migration in the same go is a > bit much I think. Reassignment across bugzilla and gitlab will be an > issue. Good points, forgot about both. Patchwork reading the mailing list should keep working as-is, but the update hook needs looking into. Disabling gitlab issues is a non-brainer, same with merge requests. Mesa is already doing that. For bugs I think it's best to entirely leave them out for now, and maybe reconsider when/if mesa has moved. Before that I don't think gitlab issues make any sense at all. For merge requests I think best approach is to enable them very selectively at first for testing out, and then making a per-subproject decision whether they make sense. E.g. I think for maintainer-tools integrating make check and the doc building into gitlab CI would be sweet, and worth looking into gitlab merge requests just to automate that. Again best left out of scope for the initial migration. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gtt: Setup guards in scratch page (rev2)
== Series Details == Series: drm/i915/gtt: Setup guards in scratch page (rev2) URL : https://patchwork.freedesktop.org/series/48565/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4695_full -> Patchwork_9990_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9990_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9990_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9990_full: === IGT changes === Warnings igt@kms_chv_cursor_fail@pipe-a-128x128-right-edge: shard-snb: PASS -> SKIP +2 == Known issues == Here are the changes found in Patchwork_9990_full that come from known issues: === IGT changes === Issues hit igt@kms_setmode@basic: shard-apl: PASS -> FAIL (fdo#99912) Possible fixes igt@kms_flip@flip-vs-expired-vblank: shard-glk: FAIL (fdo#105363) -> PASS fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4695 -> Patchwork_9990 CI_DRM_4695: f352837700ec39dbaf00cdf727650851993d754b @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4608: 94ebd21177feedf03e8f6dd1e73dca1a6ec7a0ac @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9990: 39443beee0c02518071ab487cb3aa557dd9d5ce1 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9990/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix subslice configuration on Gen9LP
== Series Details ==
Series: drm/i915: Fix subslice configuration on Gen9LP
URL : https://patchwork.freedesktop.org/series/48566/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4696 -> Patchwork_9991 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/48566/revisions/1/mbox/
== Possible new issues ==
Here are the unknown changes that may have been introduced in Patchwork_9991:
=== IGT changes ===
Warnings
{igt@kms_psr@primary_page_flip}:
fi-cnl-psr: DMESG-FAIL -> DMESG-WARN
== Known issues ==
Here are the changes found in Patchwork_9991 that come from known issues:
=== IGT changes ===
Issues hit
igt@drv_selftest@live_hangcheck:
fi-skl-guc: PASS -> DMESG-FAIL (fdo#107174)
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
fi-snb-2520m: PASS -> INCOMPLETE (fdo#103713)
fi-cnl-psr: PASS -> DMESG-WARN (fdo#104951)
Possible fixes
igt@drv_selftest@live_hangcheck:
{fi-skl-iommu}: DMESG-FAIL (fdo#107174, fdo#106560) -> PASS
fi-kbl-7567u: DMESG-FAIL (fdo#106947, fdo#106560) -> PASS
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
{fi-byt-clapper}: FAIL (fdo#107362, fdo#103191) -> PASS
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
{fi-cfl-8109u}: INCOMPLETE (fdo#106070) -> PASS
Warnings
{igt@pm_rpm@module-reload}:
fi-cnl-psr: FAIL -> WARN (fdo#107602)
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#104951 https://bugs.freedesktop.org/show_bug.cgi?id=104951
fdo#106070 https://bugs.freedesktop.org/show_bug.cgi?id=106070
fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560
fdo#106947 https://bugs.freedesktop.org/show_bug.cgi?id=106947
fdo#107174 https://bugs.freedesktop.org/show_bug.cgi?id=107174
fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362
fdo#107602 https://bugs.freedesktop.org/show_bug.cgi?id=107602
== Participating hosts (54 -> 48) ==
Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-glk-j4005
== Build changes ==
* Linux: CI_DRM_4696 -> Patchwork_9991
CI_DRM_4696: ced152c46fc90f7c1ac8963850d64c9f1ce652d6 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4608: 94ebd21177feedf03e8f6dd1e73dca1a6ec7a0ac @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9991: 75e3f1910f813b2dff2ae2794d9e84e9f832188c @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
75e3f1910f81 drm/i915: Fix subslice configuration on Gen9LP
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9991/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] RFC: Migration to Gitlab
Hi Dan, On 22 August 2018 at 12:44, Daniel Vetter wrote: > Hi all, > > I think it's time to brainstorm a bit about the gitlab migration. Basic > reasons: > > - fd.o admins want to deprecate shell accounts and hand-rolled > infrastructure, because it's a pain to keep secure&updated. > > - gitlab will allow us to add committers on our own, greatly > simplifying that process (and offloading that task from fd.o admins). > Random thought - I really wish the admins spoke early and louder about issues. From infra to manpower and adhoc tool maintenance. > There's also some more benefits we might want to reap, like better CI > integration for basic build testing - no more "oops didn't build > drm-misc defconfigs" or "sry, forgot make check in maintainer-tools". > But that's all fully optional. > > For the full in-depth writeup of everything, see > > https://www.fooishbar.org/blog/gitlab-fdo-introduction/ > > I think now is also a good time, with mesa, xorg, wayland/weston and > others moved, to start thinking about how we'll move drm. There's a > few things to figure out though: > > - We probably want to split out maintainer-tools. That would address > the concern that there's 50+ committers to an auto-updating shell > script ... > > - We need to figure out how to handle the ACL trickery around drm-tip in > gitlab. > > - Probably good to stage the migration, with maintainer-tools, igt > leading. That will also make fd.o admins happy, who want to rework > their cloud infrastructure a bit before migrating the big kernel repos > over. > > - Figuring out the actual migration - we've been adding a pile of > committers since fd.o LDAP was converted to gitlab once back in > spring. We need to at least figure out how to move the new > accounts/committers. > As a observer, allow me to put some ideas. You've mostly covered them all, my emphasis is to seriously stick with _one_ thing at a time. Attempting to do multiple things in parallel will end up with sub-optimal results. - (at random point) cleanup the committers list - people who have not contributed in the last 1 year? - setup drm group, copy/migrate accounts - one could even reuse the existing credentials - move git repos to gitlab, the push URL change, cgit mirror preserves the normal fetch ones as well as PW hooks - work out how new accounts are handled - still in bugzilla, otherwise At this stage only workflow change is a) once-off account setup and b) pushURL update As a follow-up one can setup anything fancy. - migrate PW/other hooks - migrate bugs - if applicable - add new hooks - DRM docs, other - etc > - Similar, maintainer-tools needs to move. We probably want to move > all the dim maintained kernel repos in one go, to avoid headaches with > double-accounts needed for committers. > One should be able to create a separate repo for these. And then either: - one by one add the required features into the gitlab MR machinery, - or, wire the execution in pre/post merge stage. IIRC there are some upstream requests about the former. > - CI, linux-next and everyone else should be fine, since the > cgit/non-ssh paths will keep working (they'll be read-only mirrors). > Need to double-check that with everyone. > > - Some organization structure would be good. > > https://cgit.freedesktop.org/drm > > libdrm won't be part of the gitlab drm group because that's already > moved under mesa (and you can't symlink/mulit-home anymore on gitlab): > > https://gitlab.freedesktop.org/mesa/drm > > But there's also drm_hwcomposer, which we might want to migrate into > drm too - gitlab requires a containing group, and > drm_hwcomposer/drm_hwcomposer is a bit silly. > It did strike me a lot when drm_hwcomposer/drm_hwcomposer was introduced. Fortunately moving repos in gitlab is reasonably pain-free HTH Emil ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix subslice configuration on Gen9LP
On 22/08/2018 15:29, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
According to the documentation, when programming the subslice count power-
gating configuration register, the value to be written into it on Gen9LP
should actually in the format of:
1 slice = 0x001
2 slices = 0x010
3 slices = 0x100
s/slice/subslice/
Also 0b001 etc... Not hexadecimal.
And not the popcount of the enabled subslice mask as on other platforms.
So on Gen9LP platforms we have been programming 0x11 into those bits, but
the documentation does not explain what would that achieve. Could it be
that we enable only two subslice on three sub-slice parts? Or hardware
simply ignores it and sticks with the maximum configuration?
Signed-off-by: Tvrtko Ursulin
Cc: Lionel Landwerlin
Bspec: 12247
---
Could this actually be true or I am severely misreading the docs? It does
not sound plausible to me this would have been missed all this time..
How to test in what configuration do these parts run before and after this
patch?
---
drivers/gpu/drm/i915/intel_lrc.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 36050f085071..cdfa962a1975 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2508,9 +2508,15 @@ make_rpcs(struct drm_i915_private *dev_priv)
}
if (INTEL_INFO(dev_priv)->sseu.has_subslice_pg) {
+ u8 val;
+
+ val = hweight8(INTEL_INFO(dev_priv)->sseu.subslice_mask[0]);
+
+ if (IS_GEN9_LP(dev_priv))
+ val = BIT(val - 1);
Hmm... Are you breaking the 2 subslices setting here then?
(2 subslices = 0b10 which should be equal to hweight8(subslice_mask) if
I'm thinking right)
+
rpcs |= GEN8_RPCS_SS_CNT_ENABLE;
- rpcs |= hweight8(INTEL_INFO(dev_priv)->sseu.subslice_mask[0]) <<
- GEN8_RPCS_SS_CNT_SHIFT;
+ rpcs |= val << GEN8_RPCS_SS_CNT_SHIFT;
rpcs |= GEN8_RPCS_ENABLE;
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix subslice configuration on Gen9LP
On 22/08/2018 16:08, Lionel Landwerlin wrote:
On 22/08/2018 15:29, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
According to the documentation, when programming the subslice count
power-
gating configuration register, the value to be written into it on Gen9LP
should actually in the format of:
1 slice = 0x001
2 slices = 0x010
3 slices = 0x100
s/slice/subslice/
Also 0b001 etc... Not hexadecimal.
Oops, you're right.
And not the popcount of the enabled subslice mask as on other platforms.
So on Gen9LP platforms we have been programming 0x11 into those bits, but
the documentation does not explain what would that achieve. Could it be
that we enable only two subslice on three sub-slice parts? Or hardware
simply ignores it and sticks with the maximum configuration?
Signed-off-by: Tvrtko Ursulin
Cc: Lionel Landwerlin
Bspec: 12247
---
Could this actually be true or I am severely misreading the docs? It does
not sound plausible to me this would have been missed all this time..
How to test in what configuration do these parts run before and after
this
patch?
---
drivers/gpu/drm/i915/intel_lrc.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c
b/drivers/gpu/drm/i915/intel_lrc.c
index 36050f085071..cdfa962a1975 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2508,9 +2508,15 @@ make_rpcs(struct drm_i915_private *dev_priv)
}
if (INTEL_INFO(dev_priv)->sseu.has_subslice_pg) {
+ u8 val;
+
+ val = hweight8(INTEL_INFO(dev_priv)->sseu.subslice_mask[0]);
+
+ if (IS_GEN9_LP(dev_priv))
+ val = BIT(val - 1);
Hmm... Are you breaking the 2 subslices setting here then?
(2 subslices = 0b10 which should be equal to hweight8(subslice_mask) if
I'm thinking right)
No and yes, I think.
subslice_mask = 0b011 => hweight = 2 => BIT(2 - 1) = BIT(1) = 0b010 into
the register
In the same way, all together:
subslice_mask = 0b001 => hweight = 1 => BIT(0) = 0b001
subslice_mask = 0b011 => hweight = 2 => BIT(1) = 0b010
subslice_mask = 0b111 => hweight = 3 => BIT(2) = 0b100
Have I made a mistake somewhere?
Regards,
Tvrtko
+
rpcs |= GEN8_RPCS_SS_CNT_ENABLE;
- rpcs |= hweight8(INTEL_INFO(dev_priv)->sseu.subslice_mask[0]) <<
- GEN8_RPCS_SS_CNT_SHIFT;
+ rpcs |= val << GEN8_RPCS_SS_CNT_SHIFT;
rpcs |= GEN8_RPCS_ENABLE;
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix subslice configuration on Gen9LP
On 22/08/2018 16:17, Tvrtko Ursulin wrote:
On 22/08/2018 16:08, Lionel Landwerlin wrote:
On 22/08/2018 15:29, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
According to the documentation, when programming the subslice count
power-
gating configuration register, the value to be written into it on
Gen9LP
should actually in the format of:
1 slice = 0x001
2 slices = 0x010
3 slices = 0x100
s/slice/subslice/
Also 0b001 etc... Not hexadecimal.
Oops, you're right.
And not the popcount of the enabled subslice mask as on other
platforms.
So on Gen9LP platforms we have been programming 0x11 into those
bits, but
the documentation does not explain what would that achieve. Could it be
that we enable only two subslice on three sub-slice parts? Or hardware
simply ignores it and sticks with the maximum configuration?
Signed-off-by: Tvrtko Ursulin
Cc: Lionel Landwerlin
Bspec: 12247
---
Could this actually be true or I am severely misreading the docs? It
does
not sound plausible to me this would have been missed all this time..
How to test in what configuration do these parts run before and
after this
patch?
---
drivers/gpu/drm/i915/intel_lrc.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c
b/drivers/gpu/drm/i915/intel_lrc.c
index 36050f085071..cdfa962a1975 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2508,9 +2508,15 @@ make_rpcs(struct drm_i915_private *dev_priv)
}
if (INTEL_INFO(dev_priv)->sseu.has_subslice_pg) {
+ u8 val;
+
+ val = hweight8(INTEL_INFO(dev_priv)->sseu.subslice_mask[0]);
+
+ if (IS_GEN9_LP(dev_priv))
+ val = BIT(val - 1);
Hmm... Are you breaking the 2 subslices setting here then?
(2 subslices = 0b10 which should be equal to hweight8(subslice_mask)
if I'm thinking right)
No and yes, I think.
subslice_mask = 0b011 => hweight = 2 => BIT(2 - 1) = BIT(1) = 0b010
into the register
In the same way, all together:
subslice_mask = 0b001 => hweight = 1 => BIT(0) = 0b001
subslice_mask = 0b011 => hweight = 2 => BIT(1) = 0b010
subslice_mask = 0b111 => hweight = 3 => BIT(2) = 0b100
Have I made a mistake somewhere?
Ah, yes! You're right :)
My eyes got tricked, thanks for finding this out.
With the comment fixed :
Reviewed-by: Lionel Landwerlin
Regards,
Tvrtko
+
rpcs |= GEN8_RPCS_SS_CNT_ENABLE;
- rpcs |=
hweight8(INTEL_INFO(dev_priv)->sseu.subslice_mask[0]) <<
- GEN8_RPCS_SS_CNT_SHIFT;
+ rpcs |= val << GEN8_RPCS_SS_CNT_SHIFT;
rpcs |= GEN8_RPCS_ENABLE;
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix subslice configuration on Gen9LP
On 22/08/2018 16:22, Lionel Landwerlin wrote:
On 22/08/2018 16:17, Tvrtko Ursulin wrote:
On 22/08/2018 16:08, Lionel Landwerlin wrote:
On 22/08/2018 15:29, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
According to the documentation, when programming the subslice count
power-
gating configuration register, the value to be written into it on
Gen9LP
should actually in the format of:
1 slice = 0x001
2 slices = 0x010
3 slices = 0x100
s/slice/subslice/
Also 0b001 etc... Not hexadecimal.
Oops, you're right.
And not the popcount of the enabled subslice mask as on other
platforms.
So on Gen9LP platforms we have been programming 0x11 into those
bits, but
the documentation does not explain what would that achieve. Could it be
that we enable only two subslice on three sub-slice parts? Or hardware
simply ignores it and sticks with the maximum configuration?
Signed-off-by: Tvrtko Ursulin
Cc: Lionel Landwerlin
Bspec: 12247
---
Could this actually be true or I am severely misreading the docs? It
does
not sound plausible to me this would have been missed all this time..
How to test in what configuration do these parts run before and
after this
patch?
---
drivers/gpu/drm/i915/intel_lrc.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c
b/drivers/gpu/drm/i915/intel_lrc.c
index 36050f085071..cdfa962a1975 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2508,9 +2508,15 @@ make_rpcs(struct drm_i915_private *dev_priv)
}
if (INTEL_INFO(dev_priv)->sseu.has_subslice_pg) {
+ u8 val;
+
+ val = hweight8(INTEL_INFO(dev_priv)->sseu.subslice_mask[0]);
+
+ if (IS_GEN9_LP(dev_priv))
+ val = BIT(val - 1);
Hmm... Are you breaking the 2 subslices setting here then?
(2 subslices = 0b10 which should be equal to hweight8(subslice_mask)
if I'm thinking right)
No and yes, I think.
subslice_mask = 0b011 => hweight = 2 => BIT(2 - 1) = BIT(1) = 0b010
into the register
In the same way, all together:
subslice_mask = 0b001 => hweight = 1 => BIT(0) = 0b001
subslice_mask = 0b011 => hweight = 2 => BIT(1) = 0b010
subslice_mask = 0b111 => hweight = 3 => BIT(2) = 0b100
Have I made a mistake somewhere?
Ah, yes! You're right :)
My eyes got tricked, thanks for finding this out.
At least half of the credit goes to you for linking to 12247 in scope of
one different thread!
With the comment fixed :
Reviewed-by: Lionel Landwerlin
Thanks!
Any ideas on how to test this? I'd like to commit message to be more
precise - have we been running with one slice too few? Or hardware
ignores the undocumented bit combination? Or even, is the documentation
perhaps incorrect?!
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/5] drm/i915/kbl+: Enable IPC only for symmetric memory configurations
On Wed, Aug 22, 2018 at 06:32:33PM +0530, Kumar, Mahesh wrote:
> Hi,
>
>
> On 8/22/2018 12:26 AM, Rodrigo Vivi wrote:
> > On Tue, Aug 21, 2018 at 09:30:21PM +0530, Kumar, Mahesh wrote:
> > > Hi,
> > >
> > >
> > > On 8/21/2018 8:27 PM, Kumar, Mahesh wrote:
> > > > Hi,
> > > >
> > > >
> > > > On 8/17/2018 11:50 PM, Rodrigo Vivi wrote:
> > > > > On Thu, Jul 26, 2018 at 07:44:09PM +0530, Mahesh Kumar wrote:
> > > > > > IPC may cause underflows if not used with dual channel symmetric
> > > > > > memory configuration. Disable IPC for non symmetric configurations
> > > > > > in
> > > > > > affected platforms.
> > > > > > Display WA #1141
> > > > > >
> > > > > > Signed-off-by: Mahesh Kumar
> > > > > > ---
> > > > > > drivers/gpu/drm/i915/i915_drv.c | 43
> > > > > > -
> > > > > > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > > > > > drivers/gpu/drm/i915/intel_pm.c | 2 +-
> > > > > > 3 files changed, 40 insertions(+), 6 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > > > > > b/drivers/gpu/drm/i915/i915_drv.c
> > > > > > index 86bc2e685522..2273664166bc 100644
> > > > > > --- a/drivers/gpu/drm/i915/i915_drv.c
> > > > > > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > > > > > @@ -1141,21 +1141,47 @@ skl_dram_get_channel_info(struct
> > > > > > dram_channel_info *ch, u32 val)
> > > > > > return 0;
> > > > > > }
> > > > > >
> > > > > > +static bool
> > > > > > +intel_is_dram_ipc_capable(struct drm_i915_private *dev_priv,
> > > > > > + u32 val_ch0, u32 val_ch1,
> > > > > > + struct dram_channel_info *ch0)
> > > > > what about
> > > > > intel_is_dram_symmetric() ?
> > > > sounds good.
> > > > > > +{
> > > > > > + /* Display WA #1141: SKL:all KBL:all CNL:A CNL:B */
> > > > > move this to the wa call, not the the function check...
> > > > >
> > > > > > + if (INTEL_GEN(dev_priv) > 9 &&
> > > > > > + !IS_CNL_REVID(dev_priv, CNL_REVID_A0, CNL_REVID_B0))
> > > > > please don't add CNL pre-prod wa
> > > > ok sure
> > > > > > + return true;
> > > > > > +
> > > > > > + if (!IS_KABYLAKE(dev_priv) && !IS_SKYLAKE(dev_priv))
> > > > > > + return true;
> > > > > actually remove all platforms checks here...
> > > > Agree will remove these checks, function will just return if memory is
> > > > symmetric.
> > > > > > +
> > > > > > + if (val_ch0 != val_ch1)
> > > > > > + return false;
> > > > > > +
> > > > > > + if (ch0->s_info.size == 0)
> > > > > > + return true;
> > > > > > + if (ch0->l_info.size == ch0->s_info.size &&
> > > > > > + ch0->l_info.width == ch0->s_info.width &&
> > > > > > + ch0->l_info.rank == ch0->s_info.rank)
> > > > > > + return true;
> > > > > > +
> > > > > > + return false;
> > > > > return (val_ch0 == val_ch1 && (ch0->s_info.size == 0 ||
> > > > > (ch0->l_info.size == ch0->s_info.size &&
> > > > > ch0->l_info.width == ch0->s_info.width &&
> > > > > ch0->l_info.rank == ch0->s_info.rank)))
> > > > >
> > > > > > +}
> > > > > > +
> > > > > > static int
> > > > > > skl_dram_get_channels_info(struct drm_i915_private *dev_priv)
> > > > > > {
> > > > > > struct dram_info *dram_info = &dev_priv->dram_info;
> > > > > > struct dram_channel_info ch0, ch1;
> > > > > > - u32 val;
> > > > > > + u32 val_ch0, val_ch1;
> > > > > > int ret;
> > > > > >
> > > > > > - val = I915_READ(SKL_MAD_DIMM_CH0_0_0_0_MCHBAR_MCMAIN);
> > > > > > - ret = skl_dram_get_channel_info(&ch0, val);
> > > > > > + val_ch0 = I915_READ(SKL_MAD_DIMM_CH0_0_0_0_MCHBAR_MCMAIN);
> > > > > > + ret = skl_dram_get_channel_info(&ch0, val_ch0);
> > > > > > if (ret == 0)
> > > > > > dram_info->num_channels++;
> > > > > >
> > > > > > - val = I915_READ(SKL_MAD_DIMM_CH1_0_0_0_MCHBAR_MCMAIN);
> > > > > > - ret = skl_dram_get_channel_info(&ch1, val);
> > > > > > + val_ch1 = I915_READ(SKL_MAD_DIMM_CH1_0_0_0_MCHBAR_MCMAIN);
> > > > > > + ret = skl_dram_get_channel_info(&ch1, val_ch1);
> > > > > > if (ret == 0)
> > > > > > dram_info->num_channels++;
> > > > > >
> > > > > > @@ -1185,6 +1211,13 @@ skl_dram_get_channels_info(struct
> > > > > > drm_i915_private *dev_priv)
> > > > > > if (ch0.is_16gb_dimm || ch1.is_16gb_dimm)
> > > > > > dram_info->is_16gb_dimm = true;
> > > > > >
> > > > > > + if (intel_is_dram_ipc_capable(dev_priv, val_ch0, val_ch1,
> > > > > > &ch0))
> > > > > > + dev_priv->ipc_capable_mem = true;
> > > > > > + else
> > > > > > + dev_priv->ipc_capable_mem = false;
> > > > > > +
> > > > > > + DRM_DEBUG_KMS("memory configuration is %sIPC capable\n",
> > > > > > + dev_priv->ipc_capable_mem ? "" : "not ");
> > > > > > return 0;
> > > > > > }
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > > > inde
Re: [Intel-gfx] [PATCH] drm/i915: Fix subslice configuration on Gen9LP
On 22/08/2018 16:27, Tvrtko Ursulin wrote:
On 22/08/2018 16:22, Lionel Landwerlin wrote:
On 22/08/2018 16:17, Tvrtko Ursulin wrote:
On 22/08/2018 16:08, Lionel Landwerlin wrote:
On 22/08/2018 15:29, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
According to the documentation, when programming the subslice
count power-
gating configuration register, the value to be written into it on
Gen9LP
should actually in the format of:
1 slice = 0x001
2 slices = 0x010
3 slices = 0x100
s/slice/subslice/
Also 0b001 etc... Not hexadecimal.
Oops, you're right.
And not the popcount of the enabled subslice mask as on other
platforms.
So on Gen9LP platforms we have been programming 0x11 into those
bits, but
the documentation does not explain what would that achieve. Could
it be
that we enable only two subslice on three sub-slice parts? Or
hardware
simply ignores it and sticks with the maximum configuration?
Signed-off-by: Tvrtko Ursulin
Cc: Lionel Landwerlin
Bspec: 12247
---
Could this actually be true or I am severely misreading the docs?
It does
not sound plausible to me this would have been missed all this time..
How to test in what configuration do these parts run before and
after this
patch?
---
drivers/gpu/drm/i915/intel_lrc.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c
b/drivers/gpu/drm/i915/intel_lrc.c
index 36050f085071..cdfa962a1975 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2508,9 +2508,15 @@ make_rpcs(struct drm_i915_private *dev_priv)
}
if (INTEL_INFO(dev_priv)->sseu.has_subslice_pg) {
+ u8 val;
+
+ val = hweight8(INTEL_INFO(dev_priv)->sseu.subslice_mask[0]);
+
+ if (IS_GEN9_LP(dev_priv))
+ val = BIT(val - 1);
Hmm... Are you breaking the 2 subslices setting here then?
(2 subslices = 0b10 which should be equal to
hweight8(subslice_mask) if I'm thinking right)
No and yes, I think.
subslice_mask = 0b011 => hweight = 2 => BIT(2 - 1) = BIT(1) = 0b010
into the register
In the same way, all together:
subslice_mask = 0b001 => hweight = 1 => BIT(0) = 0b001
subslice_mask = 0b011 => hweight = 2 => BIT(1) = 0b010
subslice_mask = 0b111 => hweight = 3 => BIT(2) = 0b100
Have I made a mistake somewhere?
Ah, yes! You're right :)
My eyes got tricked, thanks for finding this out.
At least half of the credit goes to you for linking to 12247 in scope
of one different thread!
With the comment fixed :
Reviewed-by: Lionel Landwerlin
Thanks!
Any ideas on how to test this? I'd like to commit message to be more
precise - have we been running with one slice too few? Or hardware
ignores the undocumented bit combination? Or even, is the
documentation perhaps incorrect?!
Yeah the tests that I wrote to test the API you're picking up use a
MI_PREDICATE where you can make a command (let's say
MI_STORE_REGISTER_MEM) conditional on the number of slice.
You can use that in a user batch an verify that memory has or hasn't
been written to.
That's only before Gen10 though.
I'm looking at whether something that is passed onto the EUs could map
back to the physical location.
Not sure if there is something...
-
Lionel
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] RFC: Migration to Gitlab
On Wed, Aug 22, 2018 at 10:19:19AM -0400, Adam Jackson wrote: > On Wed, 2018-08-22 at 16:13 +0300, Jani Nikula wrote: > > > - Sticking to fdo bugzilla and disabling gitlab issues for at least > > drm-intel for the time being. Doing that migration in the same go is a > > bit much I think. Reassignment across bugzilla and gitlab will be an > > issue. > > Can you elaborate a bit on the issues here? The actual move-the-bugs > process has been pretty painless for the parts of xorg we've done so > far. I guess there is nothing against moving the bugs there. The concern is only on doing everything at once. I'm in favor of moving gits for now and after we are confident that everything is there and working we move the bugs. One question about the bugzilla: Will all the referrences on all commit messages get outdated after bugzilla is dead? Or bugzilla will stay up for referrence but closed for interaction? or all old closed stuff are always moved and bugzilla.fd.o as well and bugzilla.fd.o will be mirroring gitlab? Thanks, Rodrigo. > > - ajax > ___ > dim-tools mailing list > dim-to...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dim-tools ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/syncobj: Drop add/remove_callback from driver interface
Fine with me.
Reviewed-by: Jason Ekstrand
On Wed, Aug 22, 2018 at 4:29 AM Daniel Vetter
wrote:
> This is used for handling future fences. Currently no driver use
> these, and I think given the new timeline fence proposed by KHR it
> would be better to have a more abstract interface for future fences.
> Could be something simple like a struct dma_future_fence plus a
> function to add a callback or wait for the fence to materialize.
>
> Then syncobj (and anything else really) could grow new functions to
> expose these two drivers. Normal dma_fence would then keep the nice
> guarantee that they will always signal (and through ordering, be
> deadlock free). dma_future_fence would then be the tricky one.
>
> This also fixes sphinx complaining about the kerneldoc.
>
> Cc: Jason Ekstrand
> Cc: Dave Airlie
> Cc: Chris Wilson
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_syncobj.c | 15 ---
> include/drm/drm_syncobj.h | 5 -
> 2 files changed, 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
> index adb3cb27d31e..3a8837c49639 100644
> --- a/drivers/gpu/drm/drm_syncobj.c
> +++ b/drivers/gpu/drm/drm_syncobj.c
> @@ -120,14 +120,6 @@ static int
> drm_syncobj_fence_get_or_add_callback(struct drm_syncobj *syncobj,
> return ret;
> }
>
> -/**
> - * drm_syncobj_add_callback - adds a callback to syncobj::cb_list
> - * @syncobj: Sync object to which to add the callback
> - * @cb: Callback to add
> - * @func: Func to use when initializing the drm_syncobj_cb struct
> - *
> - * This adds a callback to be called next time the fence is replaced
> - */
> void drm_syncobj_add_callback(struct drm_syncobj *syncobj,
> struct drm_syncobj_cb *cb,
> drm_syncobj_func_t func)
> @@ -136,13 +128,7 @@ void drm_syncobj_add_callback(struct drm_syncobj
> *syncobj,
> drm_syncobj_add_callback_locked(syncobj, cb, func);
> spin_unlock(&syncobj->lock);
> }
> -EXPORT_SYMBOL(drm_syncobj_add_callback);
>
> -/**
> - * drm_syncobj_add_callback - removes a callback to syncobj::cb_list
> - * @syncobj: Sync object from which to remove the callback
> - * @cb: Callback to remove
> - */
> void drm_syncobj_remove_callback(struct drm_syncobj *syncobj,
> struct drm_syncobj_cb *cb)
> {
> @@ -150,7 +136,6 @@ void drm_syncobj_remove_callback(struct drm_syncobj
> *syncobj,
> list_del_init(&cb->node);
> spin_unlock(&syncobj->lock);
> }
> -EXPORT_SYMBOL(drm_syncobj_remove_callback);
>
> /**
> * drm_syncobj_replace_fence - replace fence in a sync object.
> diff --git a/include/drm/drm_syncobj.h b/include/drm/drm_syncobj.h
> index 3980602472c0..e419c79ba94d 100644
> --- a/include/drm/drm_syncobj.h
> +++ b/include/drm/drm_syncobj.h
> @@ -131,11 +131,6 @@ drm_syncobj_fence_get(struct drm_syncobj *syncobj)
>
> struct drm_syncobj *drm_syncobj_find(struct drm_file *file_private,
> u32 handle);
> -void drm_syncobj_add_callback(struct drm_syncobj *syncobj,
> - struct drm_syncobj_cb *cb,
> - drm_syncobj_func_t func);
> -void drm_syncobj_remove_callback(struct drm_syncobj *syncobj,
> -struct drm_syncobj_cb *cb);
> void drm_syncobj_replace_fence(struct drm_syncobj *syncobj,
>struct dma_fence *fence);
> int drm_syncobj_find_fence(struct drm_file *file_private,
> --
> 2.18.0
>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Fix subslice configuration on Gen9LP
== Series Details == Series: drm/i915: Fix subslice configuration on Gen9LP URL : https://patchwork.freedesktop.org/series/48566/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4696_full -> Patchwork_9991_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9991_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9991_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9991_full: === IGT changes === Warnings igt@kms_cursor_legacy@cursorb-vs-flipa-toggle: shard-hsw: SKIP -> PASS == Known issues == Here are the changes found in Patchwork_9991_full that come from known issues: === IGT changes === Issues hit igt@gem_ctx_isolation@vcs1-s3: shard-kbl: PASS -> INCOMPLETE (fdo#103665) igt@gem_exec_await@wide-contexts: shard-glk: PASS -> FAIL (fdo#105900) shard-kbl: PASS -> FAIL (fdo#105900) igt@kms_available_modes_crc@available_mode_test_crc: shard-kbl: NOTRUN -> FAIL (fdo#106641) Possible fixes igt@drv_suspend@shrink: shard-glk: FAIL (fdo#106886) -> PASS igt@gem_ppgtt@blt-vs-render-ctxn: shard-kbl: INCOMPLETE (fdo#106023, fdo#103665) -> PASS +1 igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: shard-glk: FAIL (fdo#105363) -> PASS +1 igt@kms_flip@flip-vs-expired-vblank-interruptible: shard-glk: FAIL (fdo#102887, fdo#105363) -> PASS igt@perf@polling: shard-hsw: FAIL (fdo#102252) -> PASS fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#105900 https://bugs.freedesktop.org/show_bug.cgi?id=105900 fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023 fdo#106641 https://bugs.freedesktop.org/show_bug.cgi?id=106641 fdo#106886 https://bugs.freedesktop.org/show_bug.cgi?id=106886 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4696 -> Patchwork_9991 CI_DRM_4696: ced152c46fc90f7c1ac8963850d64c9f1ce652d6 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4608: 94ebd21177feedf03e8f6dd1e73dca1a6ec7a0ac @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9991: 75e3f1910f813b2dff2ae2794d9e84e9f832188c @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9991/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/icl: Fix context slice count configuration
From: Tvrtko Ursulin
Bitfield width for configuring the active slice count has grown in Gen11
so we need to program the GEN8_R_PWR_CLK_STATE accordingly.
Current code was always requesting eight times the number of slices (due
writting to a bitfield starting three bits higher than it should). These
requests were luckily a) capped by the hardware to the available number of
slices, and b) we haven't yet exported the code to ask for reduced slice
configurations.
Due both of the above there was no impact from this incorrect programming
but we should still fix it.
Signed-off-by: Tvrtko Ursulin
Bspec: 12247
Reported-by: tony...@intel.com
Suggested-by: Lionel Landwerlin
Cc: Lionel Landwerlin
Cc: tony...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 2 ++
drivers/gpu/drm/i915/intel_lrc.c | 12
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 59d06d0055bb..640f7b774a26 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -344,6 +344,8 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
#define GEN8_RPCS_S_CNT_ENABLE (1 << 18)
#define GEN8_RPCS_S_CNT_SHIFT15
#define GEN8_RPCS_S_CNT_MASK (0x7 << GEN8_RPCS_S_CNT_SHIFT)
+#define GEN11_RPCS_S_CNT_SHIFT 12
+#define GEN11_RPCS_S_CNT_MASK(0x3f << GEN11_RPCS_S_CNT_SHIFT)
#define GEN8_RPCS_SS_CNT_ENABLE (1 << 11)
#define GEN8_RPCS_SS_CNT_SHIFT 8
#define GEN8_RPCS_SS_CNT_MASK(0x7 << GEN8_RPCS_SS_CNT_SHIFT)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 36050f085071..43b8b0675ba0 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2501,10 +2501,14 @@ make_rpcs(struct drm_i915_private *dev_priv)
* enablement.
*/
if (INTEL_INFO(dev_priv)->sseu.has_slice_pg) {
- rpcs |= GEN8_RPCS_S_CNT_ENABLE;
- rpcs |= hweight8(INTEL_INFO(dev_priv)->sseu.slice_mask) <<
- GEN8_RPCS_S_CNT_SHIFT;
- rpcs |= GEN8_RPCS_ENABLE;
+ rpcs = hweight8(INTEL_INFO(dev_priv)->sseu.slice_mask);
+
+ if (INTEL_GEN(dev_priv) >= 11)
+ rpcs <<= GEN11_RPCS_S_CNT_SHIFT;
+ else
+ rpcs <<= GEN8_RPCS_S_CNT_SHIFT;
+
+ rpcs |= GEN8_RPCS_ENABLE | GEN8_RPCS_S_CNT_ENABLE;
}
if (INTEL_INFO(dev_priv)->sseu.has_subslice_pg) {
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] RFC: Migration to Gitlab
Hi, On Wed, 22 Aug 2018 at 16:02, Emil Velikov wrote: > On 22 August 2018 at 12:44, Daniel Vetter wrote: > > I think it's time to brainstorm a bit about the gitlab migration. Basic > > reasons: > > > > - fd.o admins want to deprecate shell accounts and hand-rolled > > infrastructure, because it's a pain to keep secure&updated. > > > > - gitlab will allow us to add committers on our own, greatly > > simplifying that process (and offloading that task from fd.o admins). > > Random thought - I really wish the admins spoke early and louder about issues. > From infra to manpower and adhoc tool maintenance. I thought I mostly had it covered, but fair enough. What knowledge are you missing and how should it best be delivered? One first-order issue is that as documented at https://www.freedesktop.org/wiki/AccountRequests/ creating accounts requires manual admin intervention. You can also search the 'freedesktop.org' product on Bugzilla to see the amount of time we spend shuffling around GPG & SSH keys, which is about the worst possible use of my time. Many other people have had access to drive the ancient shell-script frontend to LDAP before, but for some reason they mostly aren't very enthusiastic about doing it all the time. In the mesa-dev@ thread about Mesa's migration, which is linked from my blog post, I went into quite a lot of detail about why Jenkins was not suitable to roll out across fd.o globally. That knowledge was gained from trial & error, which was a lot of time burnt. The end result is that we don't have any CI, except if people hang Travis/AppVeyor off GitHub mirrors. You've personally seen what's involved in setting up Git repository hooks so we can build docs. We can't give access to let people work on those, without giving them direct access to the literal Git repository itself on disk. The hooks mostly involve bespoke sets of rsync jobs and hand-managed SSH credentials and external services to build docs and so on and so forth. None of this is accessible to a newcomer who wants to make a non-code contribution: you have to find someone with access to the repo to go bash some shell scripts directly and hope you didn't screw it up. None of this is auditable, so if the repo mysteriously gets wiped, then hopefully there are some backups somewhere. But there definitely aren't any logs. Luckily we prevent most people from having access to most repositories via a mandatory 'shell' which only allows people to push Git; this was written by hand by us 12 years ago. What else? Our fork of Patchwork was until recently based on an ancient fork of Django, in a bespoke unreproducible production environment. Bugzilla is patched for spam and templates (making upgrades complex), yet we still have a surprising amount of spam pass through. There's no way to delete spam, but you have to manually move every bug to the 'spam' group, then go through and delete the user which involves copying & pasting the email and a few clicks per user. Mailman is patched to support Recaptcha, bringing more upgrade fun. ikiwiki breaks all the time because it's designed to have the public-access web server on the same host as the writeable Git repositories. Our servers are several years old and approaching life expiry, and we have no more spare disk. You can see in #freedesktop IRC the constant network connectivity issues people have to PSU almost every day. Our attempts to root-cause and solve those have got nowhere. I could go on, but the 'moved elsewhere' list in https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/2 indicates that we do have problems to solve, and that changing peoples' SSH keys for them isn't the best way for us to be spending the extremely limited time that we do have. > > For the full in-depth writeup of everything, see > > > > https://www.fooishbar.org/blog/gitlab-fdo-introduction/ If you haven't seen this, or the post it was linked from, they would be a good start: https://lists.freedesktop.org/archives/freedesktop/2018-July/000370.html There's also the long thread on mesa-dev a long time back which covers a lot of this ground already. > > - Figuring out the actual migration - we've been adding a pile of > > committers since fd.o LDAP was converted to gitlab once back in > > spring. We need to at least figure out how to move the new > > accounts/committers. > > As a observer, allow me to put some ideas. You've mostly covered them > all, my emphasis is to seriously stick with _one_ thing at a time. > Attempting to do multiple things in parallel will end up with > sub-optimal results. > > - (at random point) cleanup the committers list - people who have not > contributed in the last 1 year? libdrm was previously covered under the Mesa ACL. Here are the other committer lists, which you can see via 'getent group' on annarchy or another machine: amdkfd:x:922:fxkuehl,agd5f,deathsimple,danvet,jazhou,jbridgman,hwentland,tstdenis,gitlab-mirror,rui drm-meson:x:936:narmstrong drm:x:940:airlie
Re: [Intel-gfx] [PATCH] drm/i915/icl: Fix context slice count configuration
On 22/08/2018 17:18, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Bitfield width for configuring the active slice count has grown in Gen11
so we need to program the GEN8_R_PWR_CLK_STATE accordingly.
Current code was always requesting eight times the number of slices (due
writting to a bitfield starting three bits higher than it should). These
requests were luckily a) capped by the hardware to the available number of
slices, and b) we haven't yet exported the code to ask for reduced slice
configurations.
Due both of the above there was no impact from this incorrect programming
but we should still fix it.
Signed-off-by: Tvrtko Ursulin
Bspec: 12247
Reported-by: tony...@intel.com
Suggested-by: Lionel Landwerlin
Cc: Lionel Landwerlin
Cc: tony...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 2 ++
drivers/gpu/drm/i915/intel_lrc.c | 12
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 59d06d0055bb..640f7b774a26 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -344,6 +344,8 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
#define GEN8_RPCS_S_CNT_ENABLE (1 << 18)
#define GEN8_RPCS_S_CNT_SHIFT 15
#define GEN8_RPCS_S_CNT_MASK(0x7 << GEN8_RPCS_S_CNT_SHIFT)
+#define GEN11_RPCS_S_CNT_SHIFT 12
+#define GEN11_RPCS_S_CNT_MASK(0x3f << GEN11_RPCS_S_CNT_SHIFT)
#define GEN8_RPCS_SS_CNT_ENABLE (1 << 11)
#define GEN8_RPCS_SS_CNT_SHIFT 8
#define GEN8_RPCS_SS_CNT_MASK (0x7 << GEN8_RPCS_SS_CNT_SHIFT)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 36050f085071..43b8b0675ba0 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2501,10 +2501,14 @@ make_rpcs(struct drm_i915_private *dev_priv)
* enablement.
*/
if (INTEL_INFO(dev_priv)->sseu.has_slice_pg) {
- rpcs |= GEN8_RPCS_S_CNT_ENABLE;
- rpcs |= hweight8(INTEL_INFO(dev_priv)->sseu.slice_mask) <<
- GEN8_RPCS_S_CNT_SHIFT;
- rpcs |= GEN8_RPCS_ENABLE;
+ rpcs = hweight8(INTEL_INFO(dev_priv)->sseu.slice_mask);
+
+ if (INTEL_GEN(dev_priv) >= 11)
+ rpcs <<= GEN11_RPCS_S_CNT_SHIFT;
+ else
+ rpcs <<= GEN8_RPCS_S_CNT_SHIFT;
+
+ rpcs |= GEN8_RPCS_ENABLE | GEN8_RPCS_S_CNT_ENABLE;
I don't know if you saw that wording in the documentation :
"
Note: In ICL, software programs this register as if GT consists of 2
slices with 4 subslices in each slice. Hardware maps this to the 1
slice/8-subslice physical layout.
"
My understanding is that it would make this function a bit more
complicated ;)
It also implies that on ICL you cannot select 3 subslices, which is
unfortunately what Tony was trying to do.
Maybe some opens need to be raised as to what's possible on ICL.
}
if (INTEL_INFO(dev_priv)->sseu.has_subslice_pg) {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] RFC: Migration to Gitlab
Hi, On Wed, 22 Aug 2018 at 15:44, Daniel Vetter wrote: > On Wed, Aug 22, 2018 at 3:13 PM, Jani Nikula > wrote: > > Just a couple of concerns from drm/i915 perspective for starters: > > > > - Patchwork integration. I think we'll want to keep patchwork for at > > least intel-gfx etc. for the time being. IIUC the one thing we need is > > some server side hook to update patchwork on git push. > > > > - Sticking to fdo bugzilla and disabling gitlab issues for at least > > drm-intel for the time being. Doing that migration in the same go is a > > bit much I think. Reassignment across bugzilla and gitlab will be an > > issue. > > Good points, forgot about both. Patchwork reading the mailing list > should keep working as-is, but the update hook needs looking into. All the hooks are retained. gitlab.fd.o pushes to git.fd.o, and git.fd.o still executes all the old hooks. This includes Patchwork, readthedocs, AppVeyor, and whatever else. > For merge requests I think best approach is to enable them very > selectively at first for testing out, and then making a per-subproject > decision whether they make sense. E.g. I think for maintainer-tools > integrating make check and the doc building into gitlab CI would be > sweet, and worth looking into gitlab merge requests just to automate > that. Again best left out of scope for the initial migration. You don't need MRs to do that. You can build a .gitlab-ci.yml file which will run make check or build the docs or whatever, and have that run on pushes. Anyone can then fork the repo, push their changes to that fork, and see the CI results from there. It's like Travis: the CI configuration is a (mutable) part of the codebase, not a separate 'thing' hanging off a specific repo. So if you write the CI pipeline first, you can have people running CI on push completely independently of switching the workflow to use MRs. Cheers, Daniel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] RFC: Migration to Gitlab
Hi Rodrigo, On Wed, 22 Aug 2018 at 17:06, Rodrigo Vivi wrote: > On Wed, Aug 22, 2018 at 10:19:19AM -0400, Adam Jackson wrote: > > On Wed, 2018-08-22 at 16:13 +0300, Jani Nikula wrote: > > > - Sticking to fdo bugzilla and disabling gitlab issues for at least > > > drm-intel for the time being. Doing that migration in the same go is a > > > bit much I think. Reassignment across bugzilla and gitlab will be an > > > issue. > > > > Can you elaborate a bit on the issues here? The actual move-the-bugs > > process has been pretty painless for the parts of xorg we've done so > > far. > > I guess there is nothing against moving the bugs there. The concern is only on > doing everything at once. > > I'm in favor of moving gits for now and after we are confident that > everything is there and working we move the bugs. As Daniel alluded to, the only issue I really have is moving _all_ the kernel repos at once. At the end of the year we'll have easy automatic scaling thanks to the independent services being separated. As it is, all the GitLab services (apart from CI runners) run on a single machine, so we have limited options if it becomes overwhelmed with load. Do you have a particular concern about the repos? e.g. what would you check for to make sure things are 'there and working'? > One question about the bugzilla: > > Will all the referrences on all commit messages get outdated after > bugzilla is dead? > Or bugzilla will stay up for referrence but closed for interaction? > or all old closed stuff are always moved and bugzilla.fd.o as well and > bugzilla.fd.o will be mirroring gitlab? When bugs are migrated from Bugzilla to GitLab, only open bugs are migrated. Closed ones are left in place, as is; open ones have a comment at the end saying that the bug has moved to GitLab, a URL linking to the new GitLab issue, and telling them to please chase it up there. Even when we move everyone completely off Bugzilla, we will keep it as a read-only mirror forever. Even with Phabricator, which very few people ever used, has had all its bugs and code review captured and archived, so we can continue to preserve all the old content and links, without having to run the actual service. Cheers, Daniel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/icl: Fix context slice count configuration
== Series Details == Series: drm/i915/icl: Fix context slice count configuration URL : https://patchwork.freedesktop.org/series/48570/ State : warning == Summary == $ dim checkpatch origin/drm-tip 5cf33a6a09d9 drm/i915/icl: Fix context slice count configuration -:10: WARNING:TYPO_SPELLING: 'writting' may be misspelled - perhaps 'writing'? #10: writting to a bitfield starting three bits higher than it should). These total: 0 errors, 1 warnings, 0 checks, 26 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Possible use_mm() mis-uses
Guys and gals, this is a *very* random list of people on the recipients list, but we had a subtle TLB shootdown issue in the VM, and that brought up some issues when people then went through the code more carefully. I think we have a handle on the TLB shootdown bug itself. But when people were discussing all the possible situations, one thing that came up was "use_mm()" that takes a mm, and makes it temporarily the mm for a kernel thread (until "unuse_mm()", duh). And it turns out that some of those uses are definitely wrong, some of them are right, and some of them are suspect or at least so overly complicated that it's hard for the VM people to know if they are ok. Basically, the rule for "use_mm()" is that the mm in question *has* to have a valid page table associated with it over the whole use_mm() -> unuse_mm() sequence. That may sound obvious, and I guess it actually is so obvious that there isn't even a comment about it, but the actual users are showing that it's sadly apparently not so obvious after all. There is one user that uses the "obviously correct" model: the vhost driver does a "mmget()" and "mmput()" pair around its use of it, thanks to vhost_dev_set_owner() doing a dev->mm = get_task_mm(current); to look up the mm, and then the teardown case does a if (dev->mm) mmput(dev->mm); dev->mm = NULL; This is the *right* sequence. A gold star to the vhost people. Sadly, the vhost people are the only ones who seem to get things unquestionably right. And some of those gold star people are also apparently involved in the cases that didn't get things right. An example of something that *isn't* right, is the i915 kvm interface, which does use_mm(kvm->mm); on an mm that was initialized in virt/kvm/kvm_main.c using mmgrab(current->mm); kvm->mm = current->mm; which is *not* right. Using "mmgrab()" does indeed guarantee the lifetime of the 'struct mm_struct' itself, but it does *not* guarantee the lifetime of the page tables. You need to use "mmget()" and "mmput()", which get the reference to the actual process address space! Now, it is *possible* that the kvm use is correct too, because kvm does register a mmu_notifier chain, and in theory you can avoid the proper refcounting by just making sure the mmu "release" notifier kills any existing uses, but I don't really see kvm doing that. Kvm does register a release notifier, but that just flushes the shadow page tables, it doesn't kill any use_mm() use by some i915 use case. So while the vhost use looks right, the kvm/i915 use looks definitely wrong. The other users of "use_mm()" and "unuse_mm()" are less black-and-white right vs wrong.. One of the complex ones is the amdgpu driver. It does a "use_mm(mmptr)" deep deep in the guts of a macro that ends up being used in fa few places, and it's very hard to tell if it's right. It looks almost certainly buggy (there is no mmget/mmput to get the refcount), but there _is_ a "release" mmu_notifier function and that one - unlike the kvm case - looks like it might actually be trying to flush the existing pending users of that mm. But on the whole, I'm suspicious of the amdgpu use. It smells. Jann Horn pointed out that even if it migth be ok due to the mmu_notifier, the comments are garbage: > Where "process" in the uniquely-named "struct queue" is a "struct > kfd_process"; that struct's definition has this comment in it: > >/* > * Opaque pointer to mm_struct. We don't hold a reference to > * it so it should never be dereferenced from here. This is > * only used for looking up processes by their mm. > */ >void *mm; > > So I think either that comment is wrong, or their code is wrong? so I'm chalking the amdgpu use up in the "broken" column. It's also actually quite hard to synchronze with some other kernel worker thread correctly, so just on general principles, if you use "use_mm()" it really really should be on something that you've properly gotten a mm refcount on with mmget(). Really. Even if you try to synchronize things. The two final cases are two uses in the USB gadget driver. Again, they don't have the proper mmget/mmput, but they may br ok simply because the uses are done for AIO, and the VM teardown is preceded by an AIO teardown, so the proper serialization may come in from that. Anyway, sorry for the long email, and the big list of participants and odd mailing lists, but I'd really like people to look at their "use_mm()" cases, and ask themselves if they have done enough to guarantee that the full mm exists. Again, "mmgrab()" is *not* enough on its own. You need either "mmget()" or some lifetime guarantee. And if you do have those lifetime guarantees, it would be really nice to get a good explanatory comment about said lifetime guarantees above the "use_mm()" call. Ok? Note that the lifetime rules are very important, because obviously use_mm() itself is never called i
Re: [Intel-gfx] [PATCH V2 4/4] drm/crc: add pre_crc_read function
On Wed, Aug 22, 2018 at 12:37:05PM +0200, Maarten Lankhorst wrote:
> Op 21-08-18 om 10:38 schreef Mahesh Kumar:
> > This patch implements a callback function which will be called before
> > crc read. In this function driver can implement any preparation work
> > required for successfully reading CRC data.
> >
> > Changes Since V1:
> > - rebase
> >
> > Cc: dri-de...@lists.freedesktop.org
> > Signed-off-by: Mahesh Kumar
> After some discussion with David on whether this can be upstreamed, he NACK'd
> it.
> Because there are no upstream users for this callback, it cannot be included
> upstream.
> It would be removed by the first person to notice there are no in-kernel
> users using it.
It makes sense After I posted the review yesterday I started thinking
exactly
about this case... if would get easily removed in a clean-up for obvious
reasons...
> For the first 3 patches:
> Reviewed-by: Maarten Lankhorst
thanks. pushed all 3 to drm-misc-next.
> > drivers/gpu/drm/drm_debugfs_crc.c | 8
> > include/drm/drm_crtc.h| 14 ++
> > 2 files changed, 22 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_debugfs_crc.c
> > b/drivers/gpu/drm/drm_debugfs_crc.c
> > index 00e743153e94..e303c194c080 100644
> > --- a/drivers/gpu/drm/drm_debugfs_crc.c
> > +++ b/drivers/gpu/drm/drm_debugfs_crc.c
> > @@ -274,6 +274,14 @@ static ssize_t crtc_crc_read(struct file *filep, char
> > __user *user_buf,
> > return 0;
> > }
> >
> > + if (crtc->funcs->pre_crc_read) {
> > + ret = crtc->funcs->pre_crc_read(crtc);
> > + if (ret) {
> > + spin_unlock_irq(&crc->lock);
> > + return ret;
> > + }
> > + }
> > +
> > /* Nothing to read? */
> > while (crtc_crc_data_count(crc) == 0) {
> > if (filep->f_flags & O_NONBLOCK) {
> > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> > index b21437bc95bf..19c2bf63935e 100644
> > --- a/include/drm/drm_crtc.h
> > +++ b/include/drm/drm_crtc.h
> > @@ -761,6 +761,20 @@ struct drm_crtc_funcs {
> > */
> > int (*verify_crc_source)(struct drm_crtc *crtc, const char *source,
> > size_t *values_cnt);
> > + /**
> > +* @pre_crc_read:
> > +*
> > +* Driver callback for performing any preparation work required by
> > +* driver before reading CRC
> > +*
> > +* This callback is optional if the driver does not support CRC
> > +* generation or no prework is required before reading the crc
> > +*
> > +* RETURNS:
> > +*
> > +* 0 on success or a negative error code on failure.
> > +*/
> > + int (*pre_crc_read)(struct drm_crtc *crtc);
> > /**
> > * @get_crc_sources:
> > *
>
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/icl: Fix context slice count configuration
== Series Details ==
Series: drm/i915/icl: Fix context slice count configuration
URL : https://patchwork.freedesktop.org/series/48570/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4696 -> Patchwork_9992 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/48570/revisions/1/mbox/
== Known issues ==
Here are the changes found in Patchwork_9992 that come from known issues:
=== IGT changes ===
Issues hit
igt@kms_pipe_crc_basic@hang-read-crc-pipe-b:
{fi-byt-clapper}: PASS -> FAIL (fdo#107362, fdo#103191)
Possible fixes
igt@drv_selftest@live_hangcheck:
{fi-skl-iommu}: DMESG-FAIL (fdo#106560, fdo#107174) -> PASS
fi-kbl-7567u: DMESG-FAIL (fdo#106560, fdo#106947) -> PASS
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
{fi-byt-clapper}: FAIL (fdo#107362, fdo#103191) -> PASS
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
{fi-cfl-8109u}: INCOMPLETE (fdo#106070) -> PASS
Warnings
{igt@pm_rpm@module-reload}:
fi-cnl-psr: FAIL -> WARN (fdo#107602)
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
fdo#106070 https://bugs.freedesktop.org/show_bug.cgi?id=106070
fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560
fdo#106947 https://bugs.freedesktop.org/show_bug.cgi?id=106947
fdo#107174 https://bugs.freedesktop.org/show_bug.cgi?id=107174
fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362
fdo#107602 https://bugs.freedesktop.org/show_bug.cgi?id=107602
== Participating hosts (54 -> 46) ==
Missing(8): fi-ilk-m540 fi-hsw-4200u fi-byt-j1900 fi-byt-squawks
fi-bsw-cyan fi-ctg-p8600 fi-glk-j4005 fi-gdg-551
== Build changes ==
* Linux: CI_DRM_4696 -> Patchwork_9992
CI_DRM_4696: ced152c46fc90f7c1ac8963850d64c9f1ce652d6 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4608: 94ebd21177feedf03e8f6dd1e73dca1a6ec7a0ac @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9992: 5cf33a6a09d933f2cc8def1e8f43aa1812615aab @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
5cf33a6a09d9 drm/i915/icl: Fix context slice count configuration
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9992/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] RFC: Migration to Gitlab
On Wed, Aug 22, 2018 at 05:37:22PM +0100, Daniel Stone wrote: > Hi Rodrigo, > > On Wed, 22 Aug 2018 at 17:06, Rodrigo Vivi wrote: > > On Wed, Aug 22, 2018 at 10:19:19AM -0400, Adam Jackson wrote: > > > On Wed, 2018-08-22 at 16:13 +0300, Jani Nikula wrote: > > > > - Sticking to fdo bugzilla and disabling gitlab issues for at least > > > > drm-intel for the time being. Doing that migration in the same go is a > > > > bit much I think. Reassignment across bugzilla and gitlab will be an > > > > issue. > > > > > > Can you elaborate a bit on the issues here? The actual move-the-bugs > > > process has been pretty painless for the parts of xorg we've done so > > > far. > > > > I guess there is nothing against moving the bugs there. The concern is only > > on > > doing everything at once. > > > > I'm in favor of moving gits for now and after we are confident that > > everything is there and working we move the bugs. > > As Daniel alluded to, the only issue I really have is moving _all_ the > kernel repos at once. At the end of the year we'll have easy automatic > scaling thanks to the independent services being separated. As it is, > all the GitLab services (apart from CI runners) run on a single > machine, so we have limited options if it becomes overwhelmed with > load. > > Do you have a particular concern about the repos? no concerns from my side about the repos itself. From my committer perspective on libdrm, mesa the migration was really smooth. > e.g. what would you > check for to make sure things are 'there and working'? more in terms of other committers getting used to it, dim working for most of committers, links in documentations and wikis updated... but no concerns with the infra itself. > > > One question about the bugzilla: > > > > Will all the referrences on all commit messages get outdated after > > bugzilla is dead? > > Or bugzilla will stay up for referrence but closed for interaction? > > or all old closed stuff are always moved and bugzilla.fd.o as well and > > bugzilla.fd.o will be mirroring gitlab? > > When bugs are migrated from Bugzilla to GitLab, only open bugs are > migrated. Closed ones are left in place, as is; open ones have a > comment at the end saying that the bug has moved to GitLab, a URL > linking to the new GitLab issue, and telling them to please chase it > up there. > > Even when we move everyone completely off Bugzilla, we will keep it as > a read-only mirror forever. Even with Phabricator, which very few > people ever used, has had all its bugs and code review captured and > archived, so we can continue to preserve all the old content and > links, without having to run the actual service. Great! Thanks for all clarification, Rodrigo. > > Cheers, > Daniel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/icl: Fix context slice count configuration
On 22/08/2018 17:33, Lionel Landwerlin wrote:
On 22/08/2018 17:18, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Bitfield width for configuring the active slice count has grown in Gen11
so we need to program the GEN8_R_PWR_CLK_STATE accordingly.
Current code was always requesting eight times the number of slices (due
writting to a bitfield starting three bits higher than it should). These
requests were luckily a) capped by the hardware to the available
number of
slices, and b) we haven't yet exported the code to ask for reduced slice
configurations.
Due both of the above there was no impact from this incorrect programming
but we should still fix it.
Signed-off-by: Tvrtko Ursulin
Bspec: 12247
Reported-by: tony...@intel.com
Suggested-by: Lionel Landwerlin
Cc: Lionel Landwerlin
Cc: tony...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 2 ++
drivers/gpu/drm/i915/intel_lrc.c | 12
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h
index 59d06d0055bb..640f7b774a26 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -344,6 +344,8 @@ static inline bool i915_mmio_reg_valid(i915_reg_t
reg)
#define GEN8_RPCS_S_CNT_ENABLE (1 << 18)
#define GEN8_RPCS_S_CNT_SHIFT 15
#define GEN8_RPCS_S_CNT_MASK (0x7 << GEN8_RPCS_S_CNT_SHIFT)
+#define GEN11_RPCS_S_CNT_SHIFT 12
+#define GEN11_RPCS_S_CNT_MASK (0x3f << GEN11_RPCS_S_CNT_SHIFT)
#define GEN8_RPCS_SS_CNT_ENABLE (1 << 11)
#define GEN8_RPCS_SS_CNT_SHIFT 8
#define GEN8_RPCS_SS_CNT_MASK (0x7 << GEN8_RPCS_SS_CNT_SHIFT)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c
b/drivers/gpu/drm/i915/intel_lrc.c
index 36050f085071..43b8b0675ba0 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2501,10 +2501,14 @@ make_rpcs(struct drm_i915_private *dev_priv)
* enablement.
*/
if (INTEL_INFO(dev_priv)->sseu.has_slice_pg) {
- rpcs |= GEN8_RPCS_S_CNT_ENABLE;
- rpcs |= hweight8(INTEL_INFO(dev_priv)->sseu.slice_mask) <<
- GEN8_RPCS_S_CNT_SHIFT;
- rpcs |= GEN8_RPCS_ENABLE;
+ rpcs = hweight8(INTEL_INFO(dev_priv)->sseu.slice_mask);
+
+ if (INTEL_GEN(dev_priv) >= 11)
+ rpcs <<= GEN11_RPCS_S_CNT_SHIFT;
+ else
+ rpcs <<= GEN8_RPCS_S_CNT_SHIFT;
+
+ rpcs |= GEN8_RPCS_ENABLE | GEN8_RPCS_S_CNT_ENABLE;
I don't know if you saw that wording in the documentation :
"
Note: In ICL, software programs this register as if GT consists of 2
slices with 4 subslices in each slice. Hardware maps this to the 1
slice/8-subslice physical layout.
"
My understanding is that it would make this function a bit more
complicated ;)
It also implies that on ICL you cannot select 3 subslices, which is
unfortunately what Tony was trying to do.
Maybe some opens need to be raised as to what's possible on ICL.
I interpreted the note in my head as "In ICL, _if_ _the_ software
programs.." so did not see a problem. Thought that would be just some
hidden/under the covers remapping hw would do. But I see now that was
wrong, and you are most likely right. I'll try to do some digging to
understand this better.
But for the second part of it, I don't see why 1x3 configuration would
be illegal. If software must assume hw is 2x4, even if in reality it is
1x8, then 1x3 would still be legal, no?
I thought the cause of the hang on ICL was that when Tony was asking for
1x3, the code was actually programming a request for 8x3 - which is
illegal (as in slice count must be 1 to enable subslice pg) and so would
fail to actually turn of the unwanted subslices.
But then I also though on ICL we deal with masks and not counts when
programming the hardware. Since apparently it is counts both for slices
and subslices, I am mightily confused as to how media-driver would even
theoretically be able to turn off a _specific_ (sub)slice?!
Regards,
Tvrtko
}
if (INTEL_INFO(dev_priv)->sseu.has_subslice_pg) {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/icl: Fix context slice count configuration
On 22/08/2018 18:07, Tvrtko Ursulin wrote:
On 22/08/2018 17:33, Lionel Landwerlin wrote:
On 22/08/2018 17:18, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Bitfield width for configuring the active slice count has grown in
Gen11
so we need to program the GEN8_R_PWR_CLK_STATE accordingly.
Current code was always requesting eight times the number of slices
(due
writting to a bitfield starting three bits higher than it should).
These
requests were luckily a) capped by the hardware to the available
number of
slices, and b) we haven't yet exported the code to ask for reduced
slice
configurations.
Due both of the above there was no impact from this incorrect
programming
but we should still fix it.
Signed-off-by: Tvrtko Ursulin
Bspec: 12247
Reported-by: tony...@intel.com
Suggested-by: Lionel Landwerlin
Cc: Lionel Landwerlin
Cc: tony...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 2 ++
drivers/gpu/drm/i915/intel_lrc.c | 12
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h
index 59d06d0055bb..640f7b774a26 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -344,6 +344,8 @@ static inline bool
i915_mmio_reg_valid(i915_reg_t reg)
#define GEN8_RPCS_S_CNT_ENABLE (1 << 18)
#define GEN8_RPCS_S_CNT_SHIFT 15
#define GEN8_RPCS_S_CNT_MASK (0x7 << GEN8_RPCS_S_CNT_SHIFT)
+#define GEN11_RPCS_S_CNT_SHIFT 12
+#define GEN11_RPCS_S_CNT_MASK (0x3f <<
GEN11_RPCS_S_CNT_SHIFT)
#define GEN8_RPCS_SS_CNT_ENABLE (1 << 11)
#define GEN8_RPCS_SS_CNT_SHIFT 8
#define GEN8_RPCS_SS_CNT_MASK (0x7 <<
GEN8_RPCS_SS_CNT_SHIFT)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c
b/drivers/gpu/drm/i915/intel_lrc.c
index 36050f085071..43b8b0675ba0 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2501,10 +2501,14 @@ make_rpcs(struct drm_i915_private *dev_priv)
* enablement.
*/
if (INTEL_INFO(dev_priv)->sseu.has_slice_pg) {
- rpcs |= GEN8_RPCS_S_CNT_ENABLE;
- rpcs |= hweight8(INTEL_INFO(dev_priv)->sseu.slice_mask) <<
- GEN8_RPCS_S_CNT_SHIFT;
- rpcs |= GEN8_RPCS_ENABLE;
+ rpcs = hweight8(INTEL_INFO(dev_priv)->sseu.slice_mask);
+
+ if (INTEL_GEN(dev_priv) >= 11)
+ rpcs <<= GEN11_RPCS_S_CNT_SHIFT;
+ else
+ rpcs <<= GEN8_RPCS_S_CNT_SHIFT;
+
+ rpcs |= GEN8_RPCS_ENABLE | GEN8_RPCS_S_CNT_ENABLE;
I don't know if you saw that wording in the documentation :
"
Note: In ICL, software programs this register as if GT consists of 2
slices with 4 subslices in each slice. Hardware maps this to the 1
slice/8-subslice physical layout.
"
My understanding is that it would make this function a bit more
complicated ;)
It also implies that on ICL you cannot select 3 subslices, which is
unfortunately what Tony was trying to do.
Maybe some opens need to be raised as to what's possible on ICL.
I interpreted the note in my head as "In ICL, _if_ _the_ software
programs.." so did not see a problem. Thought that would be just some
hidden/under the covers remapping hw would do. But I see now that was
wrong, and you are most likely right. I'll try to do some digging to
understand this better.
But for the second part of it, I don't see why 1x3 configuration would
be illegal. If software must assume hw is 2x4, even if in reality it
is 1x8, then 1x3 would still be legal, no?
We still seem to put a subslice number in the register for ICL (values
being 0b001, 0b010, 0b011 & 0b100).
My understanding is that the hardware will just multiply that value by 2
to map to the 1x8 underlying topology.
So if that's the case, you can't really do odd numbers... ¯\_(ツ)_/¯
I thought the cause of the hang on ICL was that when Tony was asking
for 1x3, the code was actually programming a request for 8x3 - which
is illegal (as in slice count must be 1 to enable subslice pg) and so
would fail to actually turn of the unwanted subslices.
But then I also though on ICL we deal with masks and not counts when
programming the hardware. Since apparently it is counts both for
slices and subslices, I am mightily confused as to how media-driver
would even theoretically be able to turn off a _specific_ (sub)slice?!
The fact that the feature needed isn't implemented at by the thread
dispatcher is really strange to me too.
It sounds like we're forced to use a bigger hammer than what we really need.
As to how that maps to the right subslices is also unknown to me.
The only explanation I have is that subslices with no VME samplers get
turn off first in the list of subslices to turn off.
Cheers,
-
Lionel
Regards,
Tvrtko
}
if (INTEL_INFO(dev_priv)->sseu.has_subslice_pg) {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://l
[Intel-gfx] [PATCH v4] drm/i915/psr: Add PSR mode/revision to debugfs
Log the PSR mode/revision (PSR1 or PSR2) in the debugfs file i915_edp_psr_status. Suggested-by: Dhinakaran Pandiyan Signed-off-by: Azhar Shaikh --- Changes in v4: - Fix the rebase error in v3 of adding typecast to bool - in i915_edp_psr_status(), which is not needed Changes in v3: - rebased Changes in v2: - Fix checkpatch warning. - Add Reviewed-by: from v1 drivers/gpu/drm/i915/i915_debugfs.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 26b7e5276b15..544ec5cdfe9f 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -2708,6 +2708,8 @@ static int i915_edp_psr_status(struct seq_file *m, void *data) intel_runtime_pm_get(dev_priv); mutex_lock(&dev_priv->psr.lock); + seq_printf(m, "PSR mode: %s\n", + dev_priv->psr.psr2_enabled ? "PSR2" : "PSR1"); seq_printf(m, "Enabled: %s\n", yesno(dev_priv->psr.enabled)); seq_printf(m, "Busy frontbuffer bits: 0x%03x\n", dev_priv->psr.busy_frontbuffer_bits); -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Add a small wrapper to check for CCS modifiers.
On Wed, 2018-08-22 at 12:48 +0300, Ville Syrjälä wrote:
> On Tue, Aug 21, 2018 at 06:50:52PM -0700, Dhinakaran Pandiyan wrote:
> > Code looks cleaner with modifiers hidden inside this wrapper.
> >
> > Signed-off-by: Dhinakaran Pandiyan
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 21 +++--
> > drivers/gpu/drm/i915/intel_display.h | 1 +
> > drivers/gpu/drm/i915/intel_sprite.c | 3 +--
> > 3 files changed, 13 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index ad0f0e5389d9..b98eab113330 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -2474,6 +2474,12 @@ intel_get_format_info(const struct
> > drm_mode_fb_cmd2 *cmd)
> > }
> > }
> >
> > +bool is_ccs_modifier(const u64 modifier)
>
> const is rather pointless here IMO.
I thought of it as harmless documentation, will remove and send a v2.
>
> > +{
> > + return modifier == I915_FORMAT_MOD_Y_TILED_CCS ||
> > + modifier == I915_FORMAT_MOD_Yf_TILED_CCS;
> > +}
>
> IIRC I had a similar thing in my gtt remapping series, though I
> didn't
> plug it into all the places that could have used it.
>
> Reviewed-by: Ville Syrjälä
>
Thanks for the reviews. We have to get your plane refactor series
merged soon, I'm hoping I can make some time to start reviewing it this
week.
-DK
> > +
> > static int
> > intel_fill_fb_info(struct drm_i915_private *dev_priv,
> >struct drm_framebuffer *fb)
> > @@ -2504,8 +2510,7 @@ intel_fill_fb_info(struct drm_i915_private
> > *dev_priv,
> > return ret;
> > }
> >
> > - if ((fb->modifier == I915_FORMAT_MOD_Y_TILED_CCS
> > ||
> > -fb->modifier == I915_FORMAT_MOD_Yf_TILED_CCS)
> > && i == 1) {
> > + if (is_ccs_modifier(fb->modifier) && i == 1) {
> > int hsub = fb->format->hsub;
> > int vsub = fb->format->vsub;
> > int tile_width, tile_height;
> > @@ -3054,8 +3059,7 @@ static int skl_check_main_surface(const
> > struct intel_crtc_state *crtc_state,
> > * CCS AUX surface doesn't have its own x/y offsets, we
> > must make sure
> > * they match with the main surface x/y offsets.
> > */
> > - if (fb->modifier == I915_FORMAT_MOD_Y_TILED_CCS ||
> > - fb->modifier == I915_FORMAT_MOD_Yf_TILED_CCS) {
> > + if (is_ccs_modifier(fb->modifier)) {
> > while
> > (!skl_check_main_ccs_coordinates(plane_state, x, y, offset)) {
> > if (offset == 0)
> > break;
> > @@ -3189,8 +3193,7 @@ int skl_check_plane_surface(const struct
> > intel_crtc_state *crtc_state,
> > ret = skl_check_nv12_aux_surface(plane_state);
> > if (ret)
> > return ret;
> > - } else if (fb->modifier == I915_FORMAT_MOD_Y_TILED_CCS ||
> > - fb->modifier == I915_FORMAT_MOD_Yf_TILED_CCS) {
> > + } else if (is_ccs_modifier(fb->modifier)) {
> > ret = skl_check_ccs_aux_surface(plane_state);
> > if (ret)
> > return ret;
> > @@ -13399,8 +13402,7 @@ static bool
> > skl_plane_format_mod_supported(struct drm_plane *_plane,
> > case DRM_FORMAT_XBGR:
> > case DRM_FORMAT_ARGB:
> > case DRM_FORMAT_ABGR:
> > - if (modifier == I915_FORMAT_MOD_Yf_TILED_CCS ||
> > - modifier == I915_FORMAT_MOD_Y_TILED_CCS)
> > + if (is_ccs_modifier(modifier))
> > return true;
> > /* fall through */
> > case DRM_FORMAT_RGB565:
> > @@ -14596,8 +14598,7 @@ static int intel_framebuffer_init(struct
> > intel_framebuffer *intel_fb,
> > * potential runtime errors at plane configuration
> > time.
> > */
> > if (IS_GEN9(dev_priv) && i == 0 && fb->width >
> > 3840 &&
> > - (fb->modifier == I915_FORMAT_MOD_Y_TILED_CCS
> > ||
> > -fb->modifier ==
> > I915_FORMAT_MOD_Yf_TILED_CCS))
> > + is_ccs_modifier(fb->modifier))
> > stride_alignment *= 4;
> >
> > if (fb->pitches[i] & (stride_alignment - 1)) {
> > diff --git a/drivers/gpu/drm/i915/intel_display.h
> > b/drivers/gpu/drm/i915/intel_display.h
> > index a04c5a495a2b..dbd8b1acf9d6 100644
> > --- a/drivers/gpu/drm/i915/intel_display.h
> > +++ b/drivers/gpu/drm/i915/intel_display.h
> > @@ -381,4 +381,5 @@ void intel_link_compute_m_n(int bpp, int
> > nlanes,
> > struct intel_link_m_n *m_n,
> > bool reduce_m_n);
> >
> > +bool is_ccs_modifier(const u64 modifier);
> > #endif
> > diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> > b/drivers/gpu/drm/i915/intel_sprite.c
> > index f7026e887fa9..b49adcd93892 100644
> > --- a/drivers/gpu/drm/i915/intel_sprite.c
> > +++ b/drivers/gpu/drm/i915/intel_sprite.c
> > @@ -1407,8 +
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/icl: Fix context slice count configuration
== Series Details == Series: drm/i915/icl: Fix context slice count configuration URL : https://patchwork.freedesktop.org/series/48570/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4696_full -> Patchwork_9992_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9992_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9992_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9992_full: === IGT changes === Warnings igt@kms_cursor_legacy@cursorb-vs-flipa-toggle: shard-hsw: SKIP -> PASS == Known issues == Here are the changes found in Patchwork_9992_full that come from known issues: === IGT changes === Issues hit igt@gem_ctx_isolation@vcs1-s3: shard-kbl: PASS -> INCOMPLETE (fdo#103665) igt@kms_flip@modeset-vs-vblank-race: shard-apl: PASS -> FAIL (fdo#103060) Possible fixes igt@drv_suspend@shrink: shard-glk: FAIL (fdo#106886) -> PASS igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: shard-glk: FAIL (fdo#105363) -> PASS +1 igt@kms_flip@flip-vs-expired-vblank-interruptible: shard-glk: FAIL (fdo#102887, fdo#105363) -> PASS igt@kms_setmode@basic: shard-apl: FAIL (fdo#99912) -> PASS shard-glk: FAIL (fdo#99912) -> PASS igt@perf@polling: shard-hsw: FAIL (fdo#102252) -> PASS igt@pm_rpm@system-suspend: shard-kbl: INCOMPLETE (fdo#107556, fdo#103665) -> PASS fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#106886 https://bugs.freedesktop.org/show_bug.cgi?id=106886 fdo#107556 https://bugs.freedesktop.org/show_bug.cgi?id=107556 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4696 -> Patchwork_9992 CI_DRM_4696: ced152c46fc90f7c1ac8963850d64c9f1ce652d6 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4608: 94ebd21177feedf03e8f6dd1e73dca1a6ec7a0ac @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9992: 5cf33a6a09d933f2cc8def1e8f43aa1812615aab @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9992/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Possible use_mm() mis-uses
Adding Felix because the KFD part of amdgpu is actually his responsibility. If I'm not completely mistaken the release callback of the mmu_notifier should take care of that for amdgpu. Regards, Christian. Am 22.08.2018 um 18:44 schrieb Linus Torvalds: Guys and gals, this is a *very* random list of people on the recipients list, but we had a subtle TLB shootdown issue in the VM, and that brought up some issues when people then went through the code more carefully. I think we have a handle on the TLB shootdown bug itself. But when people were discussing all the possible situations, one thing that came up was "use_mm()" that takes a mm, and makes it temporarily the mm for a kernel thread (until "unuse_mm()", duh). And it turns out that some of those uses are definitely wrong, some of them are right, and some of them are suspect or at least so overly complicated that it's hard for the VM people to know if they are ok. Basically, the rule for "use_mm()" is that the mm in question *has* to have a valid page table associated with it over the whole use_mm() -> unuse_mm() sequence. That may sound obvious, and I guess it actually is so obvious that there isn't even a comment about it, but the actual users are showing that it's sadly apparently not so obvious after all. There is one user that uses the "obviously correct" model: the vhost driver does a "mmget()" and "mmput()" pair around its use of it, thanks to vhost_dev_set_owner() doing a dev->mm = get_task_mm(current); to look up the mm, and then the teardown case does a if (dev->mm) mmput(dev->mm); dev->mm = NULL; This is the *right* sequence. A gold star to the vhost people. Sadly, the vhost people are the only ones who seem to get things unquestionably right. And some of those gold star people are also apparently involved in the cases that didn't get things right. An example of something that *isn't* right, is the i915 kvm interface, which does use_mm(kvm->mm); on an mm that was initialized in virt/kvm/kvm_main.c using mmgrab(current->mm); kvm->mm = current->mm; which is *not* right. Using "mmgrab()" does indeed guarantee the lifetime of the 'struct mm_struct' itself, but it does *not* guarantee the lifetime of the page tables. You need to use "mmget()" and "mmput()", which get the reference to the actual process address space! Now, it is *possible* that the kvm use is correct too, because kvm does register a mmu_notifier chain, and in theory you can avoid the proper refcounting by just making sure the mmu "release" notifier kills any existing uses, but I don't really see kvm doing that. Kvm does register a release notifier, but that just flushes the shadow page tables, it doesn't kill any use_mm() use by some i915 use case. So while the vhost use looks right, the kvm/i915 use looks definitely wrong. The other users of "use_mm()" and "unuse_mm()" are less black-and-white right vs wrong.. One of the complex ones is the amdgpu driver. It does a "use_mm(mmptr)" deep deep in the guts of a macro that ends up being used in fa few places, and it's very hard to tell if it's right. It looks almost certainly buggy (there is no mmget/mmput to get the refcount), but there _is_ a "release" mmu_notifier function and that one - unlike the kvm case - looks like it might actually be trying to flush the existing pending users of that mm. But on the whole, I'm suspicious of the amdgpu use. It smells. Jann Horn pointed out that even if it migth be ok due to the mmu_notifier, the comments are garbage: Where "process" in the uniquely-named "struct queue" is a "struct kfd_process"; that struct's definition has this comment in it: /* * Opaque pointer to mm_struct. We don't hold a reference to * it so it should never be dereferenced from here. This is * only used for looking up processes by their mm. */ void *mm; So I think either that comment is wrong, or their code is wrong? so I'm chalking the amdgpu use up in the "broken" column. It's also actually quite hard to synchronze with some other kernel worker thread correctly, so just on general principles, if you use "use_mm()" it really really should be on something that you've properly gotten a mm refcount on with mmget(). Really. Even if you try to synchronize things. The two final cases are two uses in the USB gadget driver. Again, they don't have the proper mmget/mmput, but they may br ok simply because the uses are done for AIO, and the VM teardown is preceded by an AIO teardown, so the proper serialization may come in from that. Anyway, sorry for the long email, and the big list of participants and odd mailing lists, but I'd really like people to look at their "use_mm()" cases, and ask themselves if they have done enough to guarantee that the full mm exists. Again, "mmgrab()" is *not* enough on its own. You need either "mmget()" or some lifetime guarantee. And if you
Re: [Intel-gfx] Possible use_mm() mis-uses
On 22/08/2018 18:44, Linus Torvalds wrote: > An example of something that *isn't* right, is the i915 kvm interface, > which does > > use_mm(kvm->mm); > > on an mm that was initialized in virt/kvm/kvm_main.c using > > mmgrab(current->mm); > kvm->mm = current->mm; > > which is *not* right. Using "mmgrab()" does indeed guarantee the > lifetime of the 'struct mm_struct' itself, but it does *not* guarantee > the lifetime of the page tables. You need to use "mmget()" and > "mmput()", which get the reference to the actual process address > space! > > Now, it is *possible* that the kvm use is correct too, because kvm > does register a mmu_notifier chain, and in theory you can avoid the > proper refcounting by just making sure the mmu "release" notifier > kills any existing uses, but I don't really see kvm doing that. Kvm > does register a release notifier, but that just flushes the shadow > page tables, it doesn't kill any use_mm() use by some i915 use case. Yes, KVM is correct but the i915 bits are at least fishy. It's probably as simple as adding a mmget/mmput pair respectively in kvmgt_guest_init and kvmgt_guest_exit, or maybe mmget_not_zero. Paolo ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4] drm/i915/psr: Add PSR mode/revision to debugfs
On Wed, 2018-08-22 at 10:23 -0700, Azhar Shaikh wrote: > Log the PSR mode/revision (PSR1 or PSR2) in the debugfs file > i915_edp_psr_status. > Reviewed-by: Dhinakaran Pandiyan > Suggested-by: Dhinakaran Pandiyan > Signed-off-by: Azhar Shaikh > --- > Changes in v4: > - Fix the rebase error in v3 of adding typecast to bool > - in i915_edp_psr_status(), which is not needed > > Changes in v3: > - rebased > > Changes in v2: > - Fix checkpatch warning. > - Add Reviewed-by: from v1 > > drivers/gpu/drm/i915/i915_debugfs.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c > b/drivers/gpu/drm/i915/i915_debugfs.c > index 26b7e5276b15..544ec5cdfe9f 100644 > --- a/drivers/gpu/drm/i915/i915_debugfs.c > +++ b/drivers/gpu/drm/i915/i915_debugfs.c > @@ -2708,6 +2708,8 @@ static int i915_edp_psr_status(struct seq_file > *m, void *data) > intel_runtime_pm_get(dev_priv); > > mutex_lock(&dev_priv->psr.lock); > + seq_printf(m, "PSR mode: %s\n", > +dev_priv->psr.psr2_enabled ? "PSR2" : "PSR1"); > seq_printf(m, "Enabled: %s\n", yesno(dev_priv- > >psr.enabled)); > seq_printf(m, "Busy frontbuffer bits: 0x%03x\n", > dev_priv->psr.busy_frontbuffer_bits); ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Possible use_mm() mis-uses
On Wed, Aug 22, 2018 at 11:21 AM Paolo Bonzini wrote: > > Yes, KVM is correct but the i915 bits are at least fishy. It's probably > as simple as adding a mmget/mmput pair respectively in kvmgt_guest_init > and kvmgt_guest_exit, or maybe mmget_not_zero. Definitely mmget_not_zero(). If it was just mmgrab()'ed earlier, the actual page tables might already be gone. Linus ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/syncobj: Drop add/remove_callback from driver interface
On Wed, Aug 22, 2018 at 11:09:21AM -0500, Jason Ekstrand wrote:
> Fine with me.
>
> Reviewed-by: Jason Ekstrand
Thanks for the review, applied to drm-misc-next.
-Daniel
>
> On Wed, Aug 22, 2018 at 4:29 AM Daniel Vetter
> wrote:
>
> > This is used for handling future fences. Currently no driver use
> > these, and I think given the new timeline fence proposed by KHR it
> > would be better to have a more abstract interface for future fences.
> > Could be something simple like a struct dma_future_fence plus a
> > function to add a callback or wait for the fence to materialize.
> >
> > Then syncobj (and anything else really) could grow new functions to
> > expose these two drivers. Normal dma_fence would then keep the nice
> > guarantee that they will always signal (and through ordering, be
> > deadlock free). dma_future_fence would then be the tricky one.
> >
> > This also fixes sphinx complaining about the kerneldoc.
> >
> > Cc: Jason Ekstrand
> > Cc: Dave Airlie
> > Cc: Chris Wilson
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_syncobj.c | 15 ---
> > include/drm/drm_syncobj.h | 5 -
> > 2 files changed, 20 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
> > index adb3cb27d31e..3a8837c49639 100644
> > --- a/drivers/gpu/drm/drm_syncobj.c
> > +++ b/drivers/gpu/drm/drm_syncobj.c
> > @@ -120,14 +120,6 @@ static int
> > drm_syncobj_fence_get_or_add_callback(struct drm_syncobj *syncobj,
> > return ret;
> > }
> >
> > -/**
> > - * drm_syncobj_add_callback - adds a callback to syncobj::cb_list
> > - * @syncobj: Sync object to which to add the callback
> > - * @cb: Callback to add
> > - * @func: Func to use when initializing the drm_syncobj_cb struct
> > - *
> > - * This adds a callback to be called next time the fence is replaced
> > - */
> > void drm_syncobj_add_callback(struct drm_syncobj *syncobj,
> > struct drm_syncobj_cb *cb,
> > drm_syncobj_func_t func)
> > @@ -136,13 +128,7 @@ void drm_syncobj_add_callback(struct drm_syncobj
> > *syncobj,
> > drm_syncobj_add_callback_locked(syncobj, cb, func);
> > spin_unlock(&syncobj->lock);
> > }
> > -EXPORT_SYMBOL(drm_syncobj_add_callback);
> >
> > -/**
> > - * drm_syncobj_add_callback - removes a callback to syncobj::cb_list
> > - * @syncobj: Sync object from which to remove the callback
> > - * @cb: Callback to remove
> > - */
> > void drm_syncobj_remove_callback(struct drm_syncobj *syncobj,
> > struct drm_syncobj_cb *cb)
> > {
> > @@ -150,7 +136,6 @@ void drm_syncobj_remove_callback(struct drm_syncobj
> > *syncobj,
> > list_del_init(&cb->node);
> > spin_unlock(&syncobj->lock);
> > }
> > -EXPORT_SYMBOL(drm_syncobj_remove_callback);
> >
> > /**
> > * drm_syncobj_replace_fence - replace fence in a sync object.
> > diff --git a/include/drm/drm_syncobj.h b/include/drm/drm_syncobj.h
> > index 3980602472c0..e419c79ba94d 100644
> > --- a/include/drm/drm_syncobj.h
> > +++ b/include/drm/drm_syncobj.h
> > @@ -131,11 +131,6 @@ drm_syncobj_fence_get(struct drm_syncobj *syncobj)
> >
> > struct drm_syncobj *drm_syncobj_find(struct drm_file *file_private,
> > u32 handle);
> > -void drm_syncobj_add_callback(struct drm_syncobj *syncobj,
> > - struct drm_syncobj_cb *cb,
> > - drm_syncobj_func_t func);
> > -void drm_syncobj_remove_callback(struct drm_syncobj *syncobj,
> > -struct drm_syncobj_cb *cb);
> > void drm_syncobj_replace_fence(struct drm_syncobj *syncobj,
> >struct dma_fence *fence);
> > int drm_syncobj_find_fence(struct drm_file *file_private,
> > --
> > 2.18.0
> >
> >
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Possible use_mm() mis-uses
On Wed, Aug 22, 2018 at 11:33 AM Linus Torvalds wrote: > > On Wed, Aug 22, 2018 at 11:21 AM Paolo Bonzini wrote: > > > > Yes, KVM is correct but the i915 bits are at least fishy. It's probably > > as simple as adding a mmget/mmput pair respectively in kvmgt_guest_init > > and kvmgt_guest_exit, or maybe mmget_not_zero. > > Definitely mmget_not_zero(). If it was just mmgrab()'ed earlier, the > actual page tables might already be gone. Side note: we _could_ do the mmget_not_zero() inside use_mm() itself, if we just knew that the mm was at least mmgrab()'ed correctly. But for some of the uses, even that isn't clear. It's not entirely obvious that the "struct mm_struct" exists _at_all_ at that point, and that a mmget_not_zero() wouldn't just have some use-after-free access. Again, independent lifetime rules could show that this isn't the case (ie "exit_aio() is always called before exit_mmap(), and kill_ioctx() takes care of it all"), but it would be good to have the users of "use_mm()" actually verify their lifetime rules are correct and enforced. Because quite often, the lifetime rule might nbot be a mmu notifier or aio_exit at all, but just be "oh, the user won't exit until this is all done". But do you *control* the user? What if the user is buggy? Linus ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Possible use_mm() mis-uses
Hi Linus: Thanks for letting us know that. We would fix this ASAP. The kvmgt.c module is a part of GVT-g code. It's our fault that we didn't find this mis-uses, not i915 or KVM guys. Wish they would feel better after seeing this message. Thanks, Zhi. On 08/23/18 00:44, Linus Torvalds wrote: Guys and gals, this is a *very* random list of people on the recipients list, but we had a subtle TLB shootdown issue in the VM, and that brought up some issues when people then went through the code more carefully. I think we have a handle on the TLB shootdown bug itself. But when people were discussing all the possible situations, one thing that came up was "use_mm()" that takes a mm, and makes it temporarily the mm for a kernel thread (until "unuse_mm()", duh). And it turns out that some of those uses are definitely wrong, some of them are right, and some of them are suspect or at least so overly complicated that it's hard for the VM people to know if they are ok. Basically, the rule for "use_mm()" is that the mm in question *has* to have a valid page table associated with it over the whole use_mm() -> unuse_mm() sequence. That may sound obvious, and I guess it actually is so obvious that there isn't even a comment about it, but the actual users are showing that it's sadly apparently not so obvious after all. There is one user that uses the "obviously correct" model: the vhost driver does a "mmget()" and "mmput()" pair around its use of it, thanks to vhost_dev_set_owner() doing a dev->mm = get_task_mm(current); to look up the mm, and then the teardown case does a if (dev->mm) mmput(dev->mm); dev->mm = NULL; This is the *right* sequence. A gold star to the vhost people. Sadly, the vhost people are the only ones who seem to get things unquestionably right. And some of those gold star people are also apparently involved in the cases that didn't get things right. An example of something that *isn't* right, is the i915 kvm interface, which does use_mm(kvm->mm); on an mm that was initialized in virt/kvm/kvm_main.c using mmgrab(current->mm); kvm->mm = current->mm; which is *not* right. Using "mmgrab()" does indeed guarantee the lifetime of the 'struct mm_struct' itself, but it does *not* guarantee the lifetime of the page tables. You need to use "mmget()" and "mmput()", which get the reference to the actual process address space! Now, it is *possible* that the kvm use is correct too, because kvm does register a mmu_notifier chain, and in theory you can avoid the proper refcounting by just making sure the mmu "release" notifier kills any existing uses, but I don't really see kvm doing that. Kvm does register a release notifier, but that just flushes the shadow page tables, it doesn't kill any use_mm() use by some i915 use case. So while the vhost use looks right, the kvm/i915 use looks definitely wrong. The other users of "use_mm()" and "unuse_mm()" are less black-and-white right vs wrong.. One of the complex ones is the amdgpu driver. It does a "use_mm(mmptr)" deep deep in the guts of a macro that ends up being used in fa few places, and it's very hard to tell if it's right. It looks almost certainly buggy (there is no mmget/mmput to get the refcount), but there _is_ a "release" mmu_notifier function and that one - unlike the kvm case - looks like it might actually be trying to flush the existing pending users of that mm. But on the whole, I'm suspicious of the amdgpu use. It smells. Jann Horn pointed out that even if it migth be ok due to the mmu_notifier, the comments are garbage: Where "process" in the uniquely-named "struct queue" is a "struct kfd_process"; that struct's definition has this comment in it: /* * Opaque pointer to mm_struct. We don't hold a reference to * it so it should never be dereferenced from here. This is * only used for looking up processes by their mm. */ void *mm; So I think either that comment is wrong, or their code is wrong? so I'm chalking the amdgpu use up in the "broken" column. It's also actually quite hard to synchronze with some other kernel worker thread correctly, so just on general principles, if you use "use_mm()" it really really should be on something that you've properly gotten a mm refcount on with mmget(). Really. Even if you try to synchronize things. The two final cases are two uses in the USB gadget driver. Again, they don't have the proper mmget/mmput, but they may br ok simply because the uses are done for AIO, and the VM teardown is preceded by an AIO teardown, so the proper serialization may come in from that. Anyway, sorry for the long email, and the big list of participants and odd mailing lists, but I'd really like people to look at their "use_mm()" cases, and ask themselves if they have done enough to guarantee that the full mm exists. Again, "mmgrab()" is *not* enough on its own. You need either "mmget
Re: [Intel-gfx] Possible use_mm() mis-uses
On Wed, Aug 22, 2018 at 7:44 PM Linus Torvalds wrote: > One of the complex ones is the amdgpu driver. It does a > "use_mm(mmptr)" deep deep in the guts of a macro that ends up being > used in fa few places, and it's very hard to tell if it's right. > > It looks almost certainly buggy (there is no mmget/mmput to get the > refcount), but there _is_ a "release" mmu_notifier function and that > one - unlike the kvm case - looks like it might actually be trying to > flush the existing pending users of that mm. > > But on the whole, I'm suspicious of the amdgpu use. It smells. Jann > Horn pointed out that even if it migth be ok due to the mmu_notifier, > the comments are garbage: > > > Where "process" in the uniquely-named "struct queue" is a "struct > > kfd_process"; that struct's definition has this comment in it: > > > >/* > > * Opaque pointer to mm_struct. We don't hold a reference to > > * it so it should never be dereferenced from here. This is > > * only used for looking up processes by their mm. > > */ > >void *mm; > > > > So I think either that comment is wrong, or their code is wrong? > > so I'm chalking the amdgpu use up in the "broken" column. > Hello Linus, I looked at the amdkfd code and indeed the comment does not match the actual code because the mm pointer is clearly dereferenced directly in the macro you mentioned (read_user_wptr). That macro is used in the code path of loading a descriptor to the H/W (load_hqd). That function is called in several cases, where in some of them we are in the context of the calling process, but in others we are in a kernel thread context (hence the use_mm). That's why we check these two situations inside that macro and only do use_mm if we are in kernel thread. We need to fix that behavior and obviously make sure that in future code we don't cast this pointer to mm_struct* and derereference it directly. Actually, the original code had "mm_struct *mm" instead of "void *mm" in the structure, and I think the reason we changed it to void* is to "make sure" that we won't dereference it directly, but clearly that failed :( Having said that, I think we *are* protected by the mmu_notifier release because if the process suddenly dies, we will gracefully clean the process's data in our driver and on the H/W before returning to the mm core code. And before we return to the mm core code, we set the mm pointer to NULL. And the graceful cleaning should be serialized with the load_hqd uses. Felix, do you have anything to add here that I might have missed ? Thanks, Oded ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: Add a small wrapper to check for CCS modifiers.
Code looks cleaner with modifiers hidden inside this wrapper.
v2: Remove const qualifier (Ville)
Signed-off-by: Dhinakaran Pandiyan
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 21 +++--
drivers/gpu/drm/i915/intel_display.h | 1 +
drivers/gpu/drm/i915/intel_sprite.c | 3 +--
3 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index ad0f0e5389d9..85062d07b201 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2474,6 +2474,12 @@ intel_get_format_info(const struct drm_mode_fb_cmd2 *cmd)
}
}
+bool is_ccs_modifier(u64 modifier)
+{
+ return modifier == I915_FORMAT_MOD_Y_TILED_CCS ||
+ modifier == I915_FORMAT_MOD_Yf_TILED_CCS;
+}
+
static int
intel_fill_fb_info(struct drm_i915_private *dev_priv,
struct drm_framebuffer *fb)
@@ -2504,8 +2510,7 @@ intel_fill_fb_info(struct drm_i915_private *dev_priv,
return ret;
}
- if ((fb->modifier == I915_FORMAT_MOD_Y_TILED_CCS ||
-fb->modifier == I915_FORMAT_MOD_Yf_TILED_CCS) && i == 1) {
+ if (is_ccs_modifier(fb->modifier) && i == 1) {
int hsub = fb->format->hsub;
int vsub = fb->format->vsub;
int tile_width, tile_height;
@@ -3054,8 +3059,7 @@ static int skl_check_main_surface(const struct
intel_crtc_state *crtc_state,
* CCS AUX surface doesn't have its own x/y offsets, we must make sure
* they match with the main surface x/y offsets.
*/
- if (fb->modifier == I915_FORMAT_MOD_Y_TILED_CCS ||
- fb->modifier == I915_FORMAT_MOD_Yf_TILED_CCS) {
+ if (is_ccs_modifier(fb->modifier)) {
while (!skl_check_main_ccs_coordinates(plane_state, x, y,
offset)) {
if (offset == 0)
break;
@@ -3189,8 +3193,7 @@ int skl_check_plane_surface(const struct intel_crtc_state
*crtc_state,
ret = skl_check_nv12_aux_surface(plane_state);
if (ret)
return ret;
- } else if (fb->modifier == I915_FORMAT_MOD_Y_TILED_CCS ||
- fb->modifier == I915_FORMAT_MOD_Yf_TILED_CCS) {
+ } else if (is_ccs_modifier(fb->modifier)) {
ret = skl_check_ccs_aux_surface(plane_state);
if (ret)
return ret;
@@ -13399,8 +13402,7 @@ static bool skl_plane_format_mod_supported(struct
drm_plane *_plane,
case DRM_FORMAT_XBGR:
case DRM_FORMAT_ARGB:
case DRM_FORMAT_ABGR:
- if (modifier == I915_FORMAT_MOD_Yf_TILED_CCS ||
- modifier == I915_FORMAT_MOD_Y_TILED_CCS)
+ if (is_ccs_modifier(modifier))
return true;
/* fall through */
case DRM_FORMAT_RGB565:
@@ -14596,8 +14598,7 @@ static int intel_framebuffer_init(struct
intel_framebuffer *intel_fb,
* potential runtime errors at plane configuration time.
*/
if (IS_GEN9(dev_priv) && i == 0 && fb->width > 3840 &&
- (fb->modifier == I915_FORMAT_MOD_Y_TILED_CCS ||
-fb->modifier == I915_FORMAT_MOD_Yf_TILED_CCS))
+ is_ccs_modifier(fb->modifier))
stride_alignment *= 4;
if (fb->pitches[i] & (stride_alignment - 1)) {
diff --git a/drivers/gpu/drm/i915/intel_display.h
b/drivers/gpu/drm/i915/intel_display.h
index a04c5a495a2b..43f080c6538d 100644
--- a/drivers/gpu/drm/i915/intel_display.h
+++ b/drivers/gpu/drm/i915/intel_display.h
@@ -381,4 +381,5 @@ void intel_link_compute_m_n(int bpp, int nlanes,
struct intel_link_m_n *m_n,
bool reduce_m_n);
+bool is_ccs_modifier(u64 modifier);
#endif
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 774bfb03c5d9..c286dda625e4 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1409,8 +1409,7 @@ static bool skl_plane_format_mod_supported(struct
drm_plane *_plane,
case DRM_FORMAT_XBGR:
case DRM_FORMAT_ARGB:
case DRM_FORMAT_ABGR:
- if (modifier == I915_FORMAT_MOD_Yf_TILED_CCS ||
- modifier == I915_FORMAT_MOD_Y_TILED_CCS)
+ if (is_ccs_modifier(modifier))
return true;
/* fall through */
case DRM_FORMAT_RGB565:
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-misc-next-fixes
Hi Dave, A couple fixes for you that didn't quite make your -rc1 pull last week. I'm sending this since Gustavo is busy organizing linuxdev-br. drm-misc-next-fixes-2018-08-22: - Add an unprepare delay to the tv123wam panel (Sean) - Update seanpaul's email in MAINTAINERS (Sean) Cc: seanp...@chromium.org Cc: s...@poorly.run Cheers, Sean The following changes since commit 2ead1be54b22ccdc93d3030172993e363128f1b4: drm/vkms: Fix connector leak at the module removal (2018-07-28 16:09:39 -0300) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-fixes-2018-08-22 for you to fetch changes up to 4acd8d01a2393f2145ad1db10b2d5c764582a98d: MAINTAINERS: drm-misc: Change seanpaul's email address (2018-08-16 11:48:24 -0400) - Add an unprepare delay to the tv123wam panel (Sean) - Update seanpaul's email in MAINTAINERS (Sean) Cc: seanp...@chromium.org Cc: s...@poorly.run Sean Paul (2): drm/panel: simple: tv123wam: Add unprepare delay MAINTAINERS: drm-misc: Change seanpaul's email address MAINTAINERS | 2 +- drivers/gpu/drm/panel/panel-simple.c | 3 +++ 2 files changed, 4 insertions(+), 1 deletion(-) -- Sean Paul, Software Engineer, Google / Chromium OS ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Possible use_mm() mis-uses
On 2018-08-22 02:13 PM, Christian König wrote: > Adding Felix because the KFD part of amdgpu is actually his > responsibility. > > If I'm not completely mistaken the release callback of the > mmu_notifier should take care of that for amdgpu. You're right, but that's a bit fragile and convoluted. I'll fix KFD to handle this more robustly. See the attached (untested) patch. And obviously that opaque pointer didn't work as intended. It just gets promoted to an mm_struct * without a warning from the compiler. Maybe I should change that to a long to make abuse easier to spot. Regards, Felix > > Regards, > Christian. > > Am 22.08.2018 um 18:44 schrieb Linus Torvalds: >> Guys and gals, >> this is a *very* random list of people on the recipients list, but we >> had a subtle TLB shootdown issue in the VM, and that brought up some >> issues when people then went through the code more carefully. >> >> I think we have a handle on the TLB shootdown bug itself. But when >> people were discussing all the possible situations, one thing that >> came up was "use_mm()" that takes a mm, and makes it temporarily the >> mm for a kernel thread (until "unuse_mm()", duh). >> >> And it turns out that some of those uses are definitely wrong, some of >> them are right, and some of them are suspect or at least so overly >> complicated that it's hard for the VM people to know if they are ok. >> >> Basically, the rule for "use_mm()" is that the mm in question *has* to >> have a valid page table associated with it over the whole use_mm() -> >> unuse_mm() sequence. That may sound obvious, and I guess it actually >> is so obvious that there isn't even a comment about it, but the actual >> users are showing that it's sadly apparently not so obvious after all. >> >> There is one user that uses the "obviously correct" model: the vhost >> driver does a "mmget()" and "mmput()" pair around its use of it, >> thanks to vhost_dev_set_owner() doing a >> >> dev->mm = get_task_mm(current); >> >> to look up the mm, and then the teardown case does a >> >> if (dev->mm) >> mmput(dev->mm); >> dev->mm = NULL; >> >> This is the *right* sequence. A gold star to the vhost people. >> >> Sadly, the vhost people are the only ones who seem to get things >> unquestionably right. And some of those gold star people are also >> apparently involved in the cases that didn't get things right. >> >> An example of something that *isn't* right, is the i915 kvm interface, >> which does >> >> use_mm(kvm->mm); >> >> on an mm that was initialized in virt/kvm/kvm_main.c using >> >> mmgrab(current->mm); >> kvm->mm = current->mm; >> >> which is *not* right. Using "mmgrab()" does indeed guarantee the >> lifetime of the 'struct mm_struct' itself, but it does *not* guarantee >> the lifetime of the page tables. You need to use "mmget()" and >> "mmput()", which get the reference to the actual process address >> space! >> >> Now, it is *possible* that the kvm use is correct too, because kvm >> does register a mmu_notifier chain, and in theory you can avoid the >> proper refcounting by just making sure the mmu "release" notifier >> kills any existing uses, but I don't really see kvm doing that. Kvm >> does register a release notifier, but that just flushes the shadow >> page tables, it doesn't kill any use_mm() use by some i915 use case. >> >> So while the vhost use looks right, the kvm/i915 use looks definitely >> wrong. >> >> The other users of "use_mm()" and "unuse_mm()" are less >> black-and-white right vs wrong.. >> >> One of the complex ones is the amdgpu driver. It does a >> "use_mm(mmptr)" deep deep in the guts of a macro that ends up being >> used in fa few places, and it's very hard to tell if it's right. >> >> It looks almost certainly buggy (there is no mmget/mmput to get the >> refcount), but there _is_ a "release" mmu_notifier function and that >> one - unlike the kvm case - looks like it might actually be trying to >> flush the existing pending users of that mm. >> >> But on the whole, I'm suspicious of the amdgpu use. It smells. Jann >> Horn pointed out that even if it migth be ok due to the mmu_notifier, >> the comments are garbage: >> >>> Where "process" in the uniquely-named "struct queue" is a "struct >>> kfd_process"; that struct's definition has this comment in it: >>> >>> /* >>> * Opaque pointer to mm_struct. We don't hold a reference to >>> * it so it should never be dereferenced from here. This is >>> * only used for looking up processes by their mm. >>> */ >>> void *mm; >>> >>> So I think either that comment is wrong, or their code is wrong? >> so I'm chalking the amdgpu use up in the "broken" column. >> >> It's also actually quite hard to synchronze with some other kernel >> worker thread correctly, so just on general principles, if you use >> "use_mm()" it really really should be on something that you've >> properly gotten a
Re: [Intel-gfx] Possible use_mm() mis-uses
On Wed, Aug 22, 2018 at 12:37 PM Oded Gabbay wrote:
>
> Having said that, I think we *are* protected by the mmu_notifier
> release because if the process suddenly dies, we will gracefully clean
> the process's data in our driver and on the H/W before returning to
> the mm core code. And before we return to the mm core code, we set the
> mm pointer to NULL. And the graceful cleaning should be serialized
> with the load_hqd uses.
So I'm a bit nervous about the mmu_notifier model (and the largely
equivalent exit_aio() model for the USB gardget AIO uses).
The reason I'm nervous about it is that the mmu_notifier() gets called
only after the mm_users count has already been decremented to zero
(and the exact same thing goes for exit_aio()).
Now that's fine if you actually get rid of all accesses in
mmu_notifier_release() or in exit_aio(), because the page tables still
exist at that point - they are in the process of being torn down, but
they haven't been torn down yet.
But for something like a kernel thread doing use_mm(), the thing that
worries me is a pattern something like this:
kwork thread exit thread
mmput() ->
mm_users goes to zero
use_mm(mmptr);
..
mmu_notifier_release();
exit_mm() ->
exit_aio()
and the pattern is basically the same regatdless of whether you use
mmu_notifier_release() or depend on some exit_aio() flushing your aio
work: the use_mm() can be called with a mm that has already had its
mm_users count decremented to zero, and that is now scheduled to be
free'd.
Does it "work"? Yes. Kind of. At least if the mmu notifier and/or
exit_aio() actually makes sure to wait for any kwork thread thing. But
it's a bit of a worrisome pattern.
Linus
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Possible use_mm() mis-uses
On Wed, Aug 22, 2018 at 10:58 PM Linus Torvalds wrote: > > On Wed, Aug 22, 2018 at 12:37 PM Oded Gabbay wrote: > > > > Having said that, I think we *are* protected by the mmu_notifier > > release because if the process suddenly dies, we will gracefully clean > > the process's data in our driver and on the H/W before returning to > > the mm core code. And before we return to the mm core code, we set the > > mm pointer to NULL. And the graceful cleaning should be serialized > > with the load_hqd uses. > > So I'm a bit nervous about the mmu_notifier model (and the largely > equivalent exit_aio() model for the USB gardget AIO uses). > > The reason I'm nervous about it is that the mmu_notifier() gets called > only after the mm_users count has already been decremented to zero > (and the exact same thing goes for exit_aio()). > > Now that's fine if you actually get rid of all accesses in > mmu_notifier_release() or in exit_aio(), because the page tables still > exist at that point - they are in the process of being torn down, but > they haven't been torn down yet. > > But for something like a kernel thread doing use_mm(), the thing that > worries me is a pattern something like this: > > kwork thread exit thread > > > mmput() -> > mm_users goes to zero > > use_mm(mmptr); > .. > > mmu_notifier_release(); > exit_mm() -> > exit_aio() > > and the pattern is basically the same regatdless of whether you use > mmu_notifier_release() or depend on some exit_aio() flushing your aio > work: the use_mm() can be called with a mm that has already had its > mm_users count decremented to zero, and that is now scheduled to be > free'd. > > Does it "work"? Yes. Kind of. At least if the mmu notifier and/or > exit_aio() actually makes sure to wait for any kwork thread thing. But > it's a bit of a worrisome pattern. > >Linus Yes, agreed, and that's why we will be on the safe side and eliminate this pattern from our code and make sure we won't add this pattern in the future. Oded ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2] drm/i915: Add a small wrapper to check for CCS modifiers. (rev2)
== Series Details ==
Series: series starting with [v2] drm/i915: Add a small wrapper to check for
CCS modifiers. (rev2)
URL : https://patchwork.freedesktop.org/series/48524/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4697 -> Patchwork_9994 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/48524/revisions/2/mbox/
== Known issues ==
Here are the changes found in Patchwork_9994 that come from known issues:
=== IGT changes ===
Issues hit
igt@drv_selftest@live_hangcheck:
{fi-kbl-8809g}: PASS -> DMESG-FAIL (fdo#106947, fdo#106560)
{igt@pm_rpm@module-reload}:
fi-cnl-psr: PASS -> WARN (fdo#107602)
Possible fixes
igt@debugfs_test@read_all_entries:
fi-snb-2520m: INCOMPLETE (fdo#103713) -> PASS
igt@drv_selftest@live_coherency:
fi-gdg-551: DMESG-FAIL (fdo#107164) -> PASS
igt@drv_selftest@live_hangcheck:
fi-bxt-j4205: DMESG-FAIL (fdo#106560) -> PASS
igt@kms_frontbuffer_tracking@basic:
{fi-byt-clapper}: FAIL (fdo#103167) -> PASS
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
fi-skl-guc: FAIL (fdo#103191) -> PASS
fi-bxt-dsi: INCOMPLETE (fdo#103927) -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560
fdo#106947 https://bugs.freedesktop.org/show_bug.cgi?id=106947
fdo#107164 https://bugs.freedesktop.org/show_bug.cgi?id=107164
fdo#107602 https://bugs.freedesktop.org/show_bug.cgi?id=107602
== Participating hosts (54 -> 48) ==
Missing(6): fi-ilk-m540 fi-hsw-4200u fi-hsw-peppy fi-byt-squawks
fi-bsw-cyan fi-ctg-p8600
== Build changes ==
* Linux: CI_DRM_4697 -> Patchwork_9994
CI_DRM_4697: b68c36de381756889dffa2c8de3206c8bf9a66d2 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4608: 94ebd21177feedf03e8f6dd1e73dca1a6ec7a0ac @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9994: 34f47ae1580b75ec1cdc1f5666caba114ca9743c @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
34f47ae1580b drm/i915: Rename PLANE_CTL_DECOMPRESSION_ENABLE
d077a8e50b7f drm/i915: Add a small wrapper to check for CCS modifiers.
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9994/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Possible use_mm() mis-uses
== Series Details ==
Series: Possible use_mm() mis-uses
URL : https://patchwork.freedesktop.org/series/48584/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
8fa6553a2650 Possible use_mm() mis-uses
-:114: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#114:
>>> * Opaque pointer to mm_struct. We don't hold a reference to
-:165: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit
<12+ chars of sha1> ("")' - ie: 'commit fatal: bad o
("3ac2307cf362c1aec")'
#165:
>From 05cdd85427c8ce6a05435df3ac2307cf362c1aec Mon Sep 17 00:00:00 2001
-:174: ERROR:GERRIT_CHANGE_ID: Remove Gerrit Change-Id's before submitting
upstream.
#174:
Change-Id: Id42976075adce45007c10481c6a8f29df67e54a9
total: 2 errors, 1 warnings, 0 checks, 80 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Possible use_mm() mis-uses
On Wed, Aug 22, 2018 at 12:44 PM Felix Kuehling wrote: > > You're right, but that's a bit fragile and convoluted. I'll fix KFD to > handle this more robustly. See the attached (untested) patch. Yes, this patch that makes the whole "has to use current mm" or uses "get_task_mm()" looks good from a VM< worry standpoint. Thanks. > And > obviously that opaque pointer didn't work as intended. It just gets > promoted to an mm_struct * without a warning from the compiler. Maybe I > should change that to a long to make abuse easier to spot. Using a "void *" is actually just about the worst possible type for something that should be a cookie, because it silently translates to any pointer. "long" is actually not much better, becuase it will silently convert to any integer type. A good fairly type-safe cookie type is actually this: typedef volatile const struct no_such_struct *cookie_ptr_t; and now something of type "cookie_ptr_t" is actually very hard to convert to other types by mistake. Note that the "volatile const" is not just random noise - it's so that it won't even convert without warnings to things that take a "const void *" as an argument (like, say, the source of 'memcpy()'). So you almost _have_ to explicitly cast it to use it. Linus ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Possible use_mm() mis-uses
== Series Details ==
Series: Possible use_mm() mis-uses
URL : https://patchwork.freedesktop.org/series/48584/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4697 -> Patchwork_9995 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/48584/revisions/1/mbox/
== Possible new issues ==
Here are the unknown changes that may have been introduced in Patchwork_9995:
=== IGT changes ===
Warnings
{igt@pm_rpm@module-reload}:
fi-cnl-psr: PASS -> SKIP
== Known issues ==
Here are the changes found in Patchwork_9995 that come from known issues:
=== IGT changes ===
Issues hit
igt@kms_pipe_crc_basic@read-crc-pipe-a:
{fi-byt-clapper}: PASS -> FAIL (fdo#107362)
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
{fi-byt-clapper}: PASS -> FAIL (fdo#107362, fdo#103191)
Possible fixes
igt@debugfs_test@read_all_entries:
fi-snb-2520m: INCOMPLETE (fdo#103713) -> PASS
igt@drv_selftest@live_coherency:
fi-gdg-551: DMESG-FAIL (fdo#107164) -> PASS
igt@drv_selftest@live_hangcheck:
fi-bxt-j4205: DMESG-FAIL (fdo#106560) -> PASS
igt@kms_frontbuffer_tracking@basic:
{fi-byt-clapper}: FAIL (fdo#103167) -> PASS
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
fi-skl-guc: FAIL (fdo#103191) -> PASS
fi-bxt-dsi: INCOMPLETE (fdo#103927) -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560
fdo#107164 https://bugs.freedesktop.org/show_bug.cgi?id=107164
fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362
== Participating hosts (54 -> 49) ==
Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-hsw-4200u
== Build changes ==
* Linux: CI_DRM_4697 -> Patchwork_9995
CI_DRM_4697: b68c36de381756889dffa2c8de3206c8bf9a66d2 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4608: 94ebd21177feedf03e8f6dd1e73dca1a6ec7a0ac @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9995: 8fa6553a26506a13ffcdcaf4cd6523f49fb4c9db @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
8fa6553a2650 Possible use_mm() mis-uses
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9995/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v2] drm/i915: Add a small wrapper to check for CCS modifiers. (rev2)
== Series Details == Series: series starting with [v2] drm/i915: Add a small wrapper to check for CCS modifiers. (rev2) URL : https://patchwork.freedesktop.org/series/48524/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4697_full -> Patchwork_9994_full = == Summary - FAILURE == Serious unknown changes coming with Patchwork_9994_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9994_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9994_full: === IGT changes === Possible regressions igt@gem_eio@reset-stress: shard-kbl: PASS -> FAIL == Known issues == Here are the changes found in Patchwork_9994_full that come from known issues: === IGT changes === Issues hit igt@gem_ctx_isolation@vcs1-s3: shard-kbl: PASS -> INCOMPLETE (fdo#103665) igt@gem_ppgtt@blt-vs-render-ctxn: shard-kbl: PASS -> INCOMPLETE (fdo#106023, fdo#103665) igt@kms_setmode@basic: shard-kbl: PASS -> FAIL (fdo#99912) fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4697 -> Patchwork_9994 CI_DRM_4697: b68c36de381756889dffa2c8de3206c8bf9a66d2 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4608: 94ebd21177feedf03e8f6dd1e73dca1a6ec7a0ac @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9994: 34f47ae1580b75ec1cdc1f5666caba114ca9743c @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9994/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for Possible use_mm() mis-uses
== Series Details == Series: Possible use_mm() mis-uses URL : https://patchwork.freedesktop.org/series/48584/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4697_full -> Patchwork_9995_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9995_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9995_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9995_full: === IGT changes === Warnings igt@kms_vblank@crtc-id: shard-snb: PASS -> SKIP == Known issues == Here are the changes found in Patchwork_9995_full that come from known issues: === IGT changes === Issues hit igt@gem_ctx_isolation@vcs1-s3: shard-kbl: PASS -> INCOMPLETE (fdo#103665) igt@gem_exec_await@wide-contexts: shard-kbl: PASS -> FAIL (fdo#105900) igt@kms_setmode@basic: shard-apl: PASS -> FAIL (fdo#99912) shard-kbl: PASS -> FAIL (fdo#99912) fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#105900 https://bugs.freedesktop.org/show_bug.cgi?id=105900 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4697 -> Patchwork_9995 CI_DRM_4697: b68c36de381756889dffa2c8de3206c8bf9a66d2 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4608: 94ebd21177feedf03e8f6dd1e73dca1a6ec7a0ac @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9995: 8fa6553a26506a13ffcdcaf4cd6523f49fb4c9db @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9995/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/18] drm/i915: s/tile_offset/aligned_offset/
On Thu, 2018-07-19 at 21:21 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Rename some of the tile_offset() functions to aligned_offset() since
> they operate on both linear and tiled functions. And we'll include
> _plane_ in the name of all the variants that take a plane state.
> Should make it more clear which function to use where.
>
Maybe rename the title as it is not doing only
s/tile_offset/aligned_offset/ as described in the commit message and in
code.
Reviewed-by: José Roberto de Souza
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_display.c | 123 ++---
> --
> drivers/gpu/drm/i915/intel_drv.h | 2 -
> 2 files changed, 63 insertions(+), 62 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 8efff0c56920..5f8304a11482 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2229,13 +2229,13 @@ void intel_add_fb_offsets(int *x, int *y,
> }
> }
>
> -static u32 __intel_adjust_tile_offset(int *x, int *y,
> - unsigned int tile_width,
> - unsigned int tile_height,
> - unsigned int tile_size,
> - unsigned int pitch_tiles,
> - u32 old_offset,
> - u32 new_offset)
> +static u32 intel_adjust_tile_offset(int *x, int *y,
> + unsigned int tile_width,
> + unsigned int tile_height,
> + unsigned int tile_size,
> + unsigned int pitch_tiles,
> + u32 old_offset,
> + u32 new_offset)
> {
> unsigned int pitch_pixels = pitch_tiles * tile_width;
> unsigned int tiles;
> @@ -2256,12 +2256,12 @@ static u32 __intel_adjust_tile_offset(int *x,
> int *y,
> return new_offset;
> }
>
> -static u32 _intel_adjust_tile_offset(int *x, int *y,
> - const struct drm_framebuffer *fb,
> int plane,
> - unsigned int rotation,
> - u32 old_offset, u32 new_offset)
> +static u32 intel_adjust_aligned_offset(int *x, int *y,
> +const struct drm_framebuffer
> *fb, int plane,
> +unsigned int rotation,
> +u32 old_offset, u32 new_offset)
> {
> - const struct drm_i915_private *dev_priv = to_i915(fb->dev);
> + struct drm_i915_private *dev_priv = to_i915(fb->dev);
> unsigned int cpp = fb->format->cpp[plane];
> unsigned int pitch = intel_fb_pitch(fb, plane, rotation);
>
> @@ -2281,9 +2281,9 @@ static u32 _intel_adjust_tile_offset(int *x,
> int *y,
> pitch_tiles = pitch / (tile_width * cpp);
> }
>
> - __intel_adjust_tile_offset(x, y, tile_width,
> tile_height,
> -tile_size, pitch_tiles,
> -old_offset, new_offset);
> + intel_adjust_tile_offset(x, y, tile_width, tile_height,
> + tile_size, pitch_tiles,
> + old_offset, new_offset);
> } else {
> old_offset += *y * pitch + *x * cpp;
>
> @@ -2298,17 +2298,18 @@ static u32 _intel_adjust_tile_offset(int *x,
> int *y,
> * Adjust the tile offset by moving the difference into
> * the x/y offsets.
> */
> -static u32 intel_adjust_tile_offset(int *x, int *y,
> - const struct intel_plane_state
> *state, int plane,
> - u32 old_offset, u32 new_offset)
> +static u32 intel_plane_adjust_aligned_offset(int *x, int *y,
> + const struct
> intel_plane_state *state,
> + int plane,
> + u32 old_offset, u32
> new_offset)
> {
> - return _intel_adjust_tile_offset(x, y, state->base.fb, plane,
> - state->base.rotation,
> - old_offset, new_offset);
> + return intel_adjust_aligned_offset(x, y, state->base.fb, plane,
> +state->base.rotation,
> +old_offset, new_offset);
> }
>
> /*
> - * Computes the linear offset to the base tile and adjusts
> + * Computes the aligned offset to the base tile and adjusts
> * x, y. bytes per pixel is assumed to be a power-of-two.
> *
> * In the 90/270 rotated case, x and y are assumed
> @@ -2321,12 +2322,12 @@ static u32 intel_adjust_tile_offset(int *x,
> int *y,
> * used. This is why the user has
Re: [Intel-gfx] [PATCH 03/18] drm/i915: Add .max_stride() plane hook
On Thu, 2018-07-19 at 21:21 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Each plane may have different stride limitations. Let's add a new
> plane function to retutn the maximum stride for each plane. There's
> going to be some use for this outside the .atomic_check() stuff hence
> the separate hook.
I just not checked the the spec for the VLV and CHV other than that
LGTM but just take a look to the nitpick bellow:
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_display.c | 46
>
> drivers/gpu/drm/i915/intel_drv.h | 10
> drivers/gpu/drm/i915/intel_sprite.c | 34 --
> 3 files changed, 88 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 5f8304a11482..a09e11e0596f 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3210,6 +3210,31 @@ int skl_check_plane_surface(const struct
> intel_crtc_state *crtc_state,
> return 0;
> }
>
> +unsigned int
> +i9xx_plane_max_stride(struct intel_plane *plane,
> + u32 pixel_format, u64 modifier,
> + unsigned int rotation)
> +{
> + struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
> +
> + if (INTEL_GEN(dev_priv) >= 4) {
> + if (modifier == I915_FORMAT_MOD_X_TILED)
> + return 16*1024;
> + else
> + return 32*1024;
> + } else if (INTEL_GEN(dev_priv) >= 3) {
> + if (modifier == I915_FORMAT_MOD_X_TILED)
> + return 8*1024;
> + else
> + return 16*1024;
> + } else {
> + if (plane->i9xx_plane == PLANE_C)
> + return 4*1024;
> + else
> + return 8*1024;
> + }
> +}
> +
> static u32 i9xx_plane_ctl(const struct intel_crtc_state *crtc_state,
> const struct intel_plane_state *plane_state)
> {
> @@ -9672,6 +9697,14 @@ static int intel_check_cursor(struct
> intel_crtc_state *crtc_state,
> return 0;
> }
>
> +static unsigned int
> +i845_cursor_max_stride(struct intel_plane *plane,
> +u32 pixel_format, u64 modifier,
> +unsigned int rotation)
> +{
> + return 2048;
> +}
> +
> static u32 i845_cursor_ctl(const struct intel_crtc_state
> *crtc_state,
> const struct intel_plane_state *plane_state)
> {
> @@ -9805,6 +9838,14 @@ static bool i845_cursor_get_hw_state(struct
> intel_plane *plane,
> return ret;
> }
>
> +static unsigned int
> +i9xx_cursor_max_stride(struct intel_plane *plane,
> +u32 pixel_format, u64 modifier,
> +unsigned int rotation)
> +{
> + return plane->base.dev->mode_config.cursor_width * 4;
> +}
> +
> static u32 i9xx_cursor_ctl(const struct intel_crtc_state
> *crtc_state,
> const struct intel_plane_state *plane_state)
> {
> @@ -13699,6 +13740,7 @@ intel_primary_plane_create(struct
> drm_i915_private *dev_priv, enum pipe pipe)
> else
> modifiers = skl_format_modifiers_noccs;
>
> + primary->max_stride = skl_plane_max_stride;
> primary->update_plane = skl_update_plane;
> primary->disable_plane = skl_disable_plane;
> primary->get_hw_state = skl_plane_get_hw_state;
> @@ -13709,6 +13751,7 @@ intel_primary_plane_create(struct
> drm_i915_private *dev_priv, enum pipe pipe)
> num_formats = ARRAY_SIZE(i965_primary_formats);
> modifiers = i9xx_format_modifiers;
>
> + primary->max_stride = i9xx_plane_max_stride;
> primary->update_plane = i9xx_update_plane;
> primary->disable_plane = i9xx_disable_plane;
> primary->get_hw_state = i9xx_plane_get_hw_state;
> @@ -13719,6 +13762,7 @@ intel_primary_plane_create(struct
> drm_i915_private *dev_priv, enum pipe pipe)
> num_formats = ARRAY_SIZE(i8xx_primary_formats);
> modifiers = i9xx_format_modifiers;
>
> + primary->max_stride = i9xx_plane_max_stride;
> primary->update_plane = i9xx_update_plane;
> primary->disable_plane = i9xx_disable_plane;
> primary->get_hw_state = i9xx_plane_get_hw_state;
> @@ -13826,11 +13870,13 @@ intel_cursor_plane_create(struct
> drm_i915_private *dev_priv,
> cursor->frontbuffer_bit = INTEL_FRONTBUFFER(pipe, cursor->id);
>
> if (IS_I845G(dev_priv) || IS_I865G(dev_priv)) {
> + cursor->max_stride = i845_cursor_max_stride;
> cursor->update_plane = i845_update_cursor;
> cursor->disable_plane = i845_disable_cursor;
> cursor->get_hw_state = i845_cursor_get_hw_state;
> cursor->check_plane
Re: [Intel-gfx] [PATCH 03/18] drm/i915: Add .max_stride() plane hook
On Wed, 2018-08-22 at 22:03 +, Souza, Jose wrote:
> On Thu, 2018-07-19 at 21:21 +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Each plane may have different stride limitations. Let's add a new
> > plane function to retutn the maximum stride for each plane. There's
> > going to be some use for this outside the .atomic_check() stuff
> > hence
> > the separate hook.
>
> I just not checked the the spec for the VLV and CHV other than that
> LGTM but just take a look to the nitpick bellow:
>
> Reviewed-by: José Roberto de Souza
>
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 46
> >
> > drivers/gpu/drm/i915/intel_drv.h | 10
> > drivers/gpu/drm/i915/intel_sprite.c | 34
> > --
> > 3 files changed, 88 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 5f8304a11482..a09e11e0596f 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -3210,6 +3210,31 @@ int skl_check_plane_surface(const struct
> > intel_crtc_state *crtc_state,
> > return 0;
> > }
> >
> > +unsigned int
> > +i9xx_plane_max_stride(struct intel_plane *plane,
> > + u32 pixel_format, u64 modifier,
> > + unsigned int rotation)
> > +{
> > + struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
> > +
Reviwing 'drm/i915: Use pipe A primary plane .max_stride() as the
global stride limit' I notice that this case was not moved here:
} else if (gen >= 5 && !HAS_GMCH_DISPLAY(dev_priv)) {
return 32*1024;
}
Not relevant anymore?
> > + if (INTEL_GEN(dev_priv) >= 4) {
> > + if (modifier == I915_FORMAT_MOD_X_TILED)
> > + return 16*1024;
> > + else
> > + return 32*1024;
> > + } else if (INTEL_GEN(dev_priv) >= 3) {
> > + if (modifier == I915_FORMAT_MOD_X_TILED)
> > + return 8*1024;
> > + else
> > + return 16*1024;
> > + } else {
> > + if (plane->i9xx_plane == PLANE_C)
> > + return 4*1024;
> > + else
> > + return 8*1024;
> > + }
> > +}
> > +
> > static u32 i9xx_plane_ctl(const struct intel_crtc_state
> > *crtc_state,
> > const struct intel_plane_state *plane_state)
> > {
> > @@ -9672,6 +9697,14 @@ static int intel_check_cursor(struct
> > intel_crtc_state *crtc_state,
> > return 0;
> > }
> >
> > +static unsigned int
> > +i845_cursor_max_stride(struct intel_plane *plane,
> > + u32 pixel_format, u64 modifier,
> > + unsigned int rotation)
> > +{
> > + return 2048;
> > +}
> > +
> > static u32 i845_cursor_ctl(const struct intel_crtc_state
> > *crtc_state,
> >const struct intel_plane_state *plane_state)
> > {
> > @@ -9805,6 +9838,14 @@ static bool i845_cursor_get_hw_state(struct
> > intel_plane *plane,
> > return ret;
> > }
> >
> > +static unsigned int
> > +i9xx_cursor_max_stride(struct intel_plane *plane,
> > + u32 pixel_format, u64 modifier,
> > + unsigned int rotation)
> > +{
> > + return plane->base.dev->mode_config.cursor_width * 4;
> > +}
> > +
> > static u32 i9xx_cursor_ctl(const struct intel_crtc_state
> > *crtc_state,
> >const struct intel_plane_state *plane_state)
> > {
> > @@ -13699,6 +13740,7 @@ intel_primary_plane_create(struct
> > drm_i915_private *dev_priv, enum pipe pipe)
> > else
> > modifiers = skl_format_modifiers_noccs;
> >
> > + primary->max_stride = skl_plane_max_stride;
> > primary->update_plane = skl_update_plane;
> > primary->disable_plane = skl_disable_plane;
> > primary->get_hw_state = skl_plane_get_hw_state;
> > @@ -13709,6 +13751,7 @@ intel_primary_plane_create(struct
> > drm_i915_private *dev_priv, enum pipe pipe)
> > num_formats = ARRAY_SIZE(i965_primary_formats);
> > modifiers = i9xx_format_modifiers;
> >
> > + primary->max_stride = i9xx_plane_max_stride;
> > primary->update_plane = i9xx_update_plane;
> > primary->disable_plane = i9xx_disable_plane;
> > primary->get_hw_state = i9xx_plane_get_hw_state;
> > @@ -13719,6 +13762,7 @@ intel_primary_plane_create(struct
> > drm_i915_private *dev_priv, enum pipe pipe)
> > num_formats = ARRAY_SIZE(i8xx_primary_formats);
> > modifiers = i9xx_format_modifiers;
> >
> > + primary->max_stride = i9xx_plane_max_stride;
> > primary->update_plane = i9xx_update_plane;
> > primary->disable_plane = i9xx_disable_plane;
> > primary->get_hw_state = i9xx_plane_get_hw_state;
> > @@ -13826,11 +13870,13 @@ intel_cursor_plane
Re: [Intel-gfx] [PATCH 04/18] drm/i915: Use pipe A primary plane .max_stride() as the global stride limit
On Thu, 2018-07-19 at 21:22 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Let's assume that the primary plane for pipe A has the highest max
> stride of all planes, and we'll use that as the global limit when
> creating a new framebuffer.
Well it was already assuming that but using the new max_stride hook is
way better.
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_display.c | 33 ++--
> -
> 1 file changed, 10 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index a09e11e0596f..994685230b97 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14399,31 +14399,18 @@ static
> u32 intel_fb_pitch_limit(struct drm_i915_private *dev_priv,
>uint64_t fb_modifier, uint32_t pixel_format)
> {
> - u32 gen = INTEL_GEN(dev_priv);
> + struct intel_crtc *crtc;
> + struct intel_plane *plane;
>
> - if (gen >= 9) {
> - int cpp = drm_format_plane_cpp(pixel_format, 0);
> + /*
> + * We assume the primary plane for pipe A has
> + * the highest stride limits of them all.
> + */
> + crtc = intel_get_crtc_for_pipe(dev_priv, PIPE_A);
> + plane = to_intel_plane(crtc->base.primary);
>
> - /* "The stride in bytes must not exceed the of the size
> of 8K
> - * pixels and 32K bytes."
> - */
> - return min(8192 * cpp, 32768);
> - } else if (gen >= 5 && !HAS_GMCH_DISPLAY(dev_priv)) {
> - return 32*1024;
> - } else if (gen >= 4) {
> - if (fb_modifier == I915_FORMAT_MOD_X_TILED)
> - return 16*1024;
> - else
> - return 32*1024;
> - } else if (gen >= 3) {
> - if (fb_modifier == I915_FORMAT_MOD_X_TILED)
> - return 8*1024;
> - else
> - return 16*1024;
> - } else {
> - /* XXX DSPC is limited to 4k tiled */
> - return 8*1024;
> - }
> + return plane->max_stride(plane, pixel_format, fb_modifier,
> + DRM_MODE_ROTATE_0);
> }
>
> static int intel_framebuffer_init(struct intel_framebuffer
> *intel_fb,
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/psr: Add PSR mode/revision to debugfs (rev4)
== Series Details ==
Series: drm/i915/psr: Add PSR mode/revision to debugfs (rev4)
URL : https://patchwork.freedesktop.org/series/47902/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4697 -> Patchwork_9996 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/47902/revisions/4/mbox/
== Known issues ==
Here are the changes found in Patchwork_9996 that come from known issues:
=== IGT changes ===
Issues hit
igt@gem_exec_suspend@basic-s3:
{fi-byt-clapper}: PASS -> INCOMPLETE (fdo#102657)
igt@kms_frontbuffer_tracking@basic:
fi-hsw-peppy: PASS -> DMESG-FAIL (fdo#102614)
{igt@pm_rpm@module-reload}:
fi-cnl-psr: PASS -> WARN (fdo#107602)
Possible fixes
igt@debugfs_test@read_all_entries:
fi-snb-2520m: INCOMPLETE (fdo#103713) -> PASS
igt@drv_selftest@live_coherency:
fi-gdg-551: DMESG-FAIL (fdo#107164) -> PASS
igt@drv_selftest@live_hangcheck:
fi-bxt-j4205: DMESG-FAIL (fdo#106560) -> PASS
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
fi-skl-guc: FAIL (fdo#103191) -> PASS
fi-bxt-dsi: INCOMPLETE (fdo#103927) -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614
fdo#102657 https://bugs.freedesktop.org/show_bug.cgi?id=102657
fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560
fdo#107164 https://bugs.freedesktop.org/show_bug.cgi?id=107164
fdo#107602 https://bugs.freedesktop.org/show_bug.cgi?id=107602
== Participating hosts (54 -> 47) ==
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-j1900 fi-byt-squawks
fi-bsw-cyan fi-ctg-p8600 fi-icl-u
== Build changes ==
* Linux: CI_DRM_4697 -> Patchwork_9996
CI_DRM_4697: b68c36de381756889dffa2c8de3206c8bf9a66d2 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4608: 94ebd21177feedf03e8f6dd1e73dca1a6ec7a0ac @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9996: ad40f970820c5021aaf10dab23fd53301a42c49c @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
ad40f970820c drm/i915/psr: Add PSR mode/revision to debugfs
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9996/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Add plane alpha blending support, v2.
On Wed, Aug 15, 2018 at 12:34:05PM +0200, Maarten Lankhorst wrote:
> Add plane alpha blending support with the different blend modes.
> This has been tested on a icl to show the correct results,
> on earlier platforms small rounding errors cause issues. But this
> already happens case with fully transparant or fully opaque RGB
> fb's.
>
> The recommended HW workaround is to disable alpha blending when the
> plane alpha is 0 (transparant, hide plane) or 0xff (opaque, disable blending).
> This is easy to implement on any platform, so just do that.
>
> The tests for userspace are also available, and pass on gen11.
>
> Changes since v1:
> - Change mistaken < 0xff0 to 0xff00.
> - Only set PLANE_KEYMSK_ALPHA_ENABLE when plane alpha < 0xff00, ignore blend
> mode.
> - Rework disabling FBC when per pixel alpha is used.
>
> Signed-off-by: Maarten Lankhorst
One question and one minor suggestion inline below, but otherwise,
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 +
> drivers/gpu/drm/i915/i915_reg.h | 2 +
> drivers/gpu/drm/i915/intel_display.c | 58 +++-
> drivers/gpu/drm/i915/intel_fbc.c | 8
> drivers/gpu/drm/i915/intel_sprite.c | 23 ++-
> 5 files changed, 73 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 3fa56b960ef2..29f75da5fa8c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -545,6 +545,8 @@ struct intel_fbc {
> int adjusted_y;
>
> int y;
> +
> + uint16_t pixel_blend_mode;
> } plane;
>
> struct {
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 0c9f03dda569..93a1d87cdeb2 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6561,8 +6561,10 @@ enum {
> #define _PLANE_KEYVAL_2_A0x70294
> #define _PLANE_KEYMSK_1_A0x70198
> #define _PLANE_KEYMSK_2_A0x70298
> +#define PLANE_KEYMSK_ALPHA_ENABLE (1 << 31)
> #define _PLANE_KEYMAX_1_A0x701a0
> #define _PLANE_KEYMAX_2_A0x702a0
> +#define PLANE_KEYMAX_ALPHA_SHIFT24
> #define _PLANE_AUX_DIST_1_A 0x701c0
> #define _PLANE_AUX_DIST_2_A 0x702c0
> #define _PLANE_AUX_OFFSET_1_A0x701c4
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index a0345e7d3c2b..aedad3674b0d 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3167,6 +3167,12 @@ int skl_check_plane_surface(const struct
> intel_crtc_state *crtc_state,
> return -EINVAL;
> }
>
> + /* HW only has 8 bits pixel precision, disable plane if invisible */
> + if (!(plane_state->base.alpha >> 8)) {
> + plane_state->base.visible = false;
> + return 0;
> + }
> +
> if (!plane_state->base.visible)
> return 0;
>
> @@ -3512,30 +3518,39 @@ static u32 skl_plane_ctl_format(uint32_t pixel_format)
> return 0;
> }
>
> -/*
> - * XXX: For ARBG/ABGR formats we default to expecting scanout buffers
> - * to be already pre-multiplied. We need to add a knob (or a different
> - * DRM_FORMAT) for user-space to configure that.
> - */
> -static u32 skl_plane_ctl_alpha(uint32_t pixel_format)
> +static u32 skl_plane_ctl_alpha(const struct intel_plane_state *plane_state)
> {
> - switch (pixel_format) {
> - case DRM_FORMAT_ABGR:
> - case DRM_FORMAT_ARGB:
> + if (!plane_state->base.fb->format->has_alpha)
> + return PLANE_CTL_ALPHA_DISABLE;
> +
> + switch (plane_state->base.pixel_blend_mode) {
> + case DRM_MODE_BLEND_PIXEL_NONE:
> + return PLANE_CTL_ALPHA_DISABLE;
> + case DRM_MODE_BLEND_PREMULTI:
> return PLANE_CTL_ALPHA_SW_PREMULTIPLY;
> + case DRM_MODE_BLEND_COVERAGE:
> + return PLANE_CTL_ALPHA_HW_PREMULTIPLY;
> default:
> - return PLANE_CTL_ALPHA_DISABLE;
> + MISSING_CASE(plane_state->base.pixel_blend_mode);
> + return 0;
Maybe just add the MISSING_CASE line before the current return? The
macro still expands to 0, so leaving that makes it slightly more clear
what the default fallback is. Same for the glk_ function below.
> }
> }
>
> -static u32 glk_plane_color_ctl_alpha(uint32_t pixel_format)
> +static u32 glk_plane_color_ctl_alpha(const struct intel_plane_state
> *plane_state)
> {
> - switch (pixel_format) {
> - case DRM_FORMAT_ABGR:
> - case DRM_FORMAT_ARGB:
> + if (!plane_state->base.fb->format->has_alpha)
> + return PLANE_COLOR_ALPHA_DISABLE;
> +
> + switch (plane_state->base.pixel_blend_mode) {
> + case DRM_
Re: [Intel-gfx] [PATCH 05/18] drm/i915: Rename the plane_state->main/aux to plane_state->color_plane[]
On Thu, 2018-07-19 at 21:22 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Make the main/aux surface stuff a bit more generic by using an array
> of structures. This will allow us to deal with both the main and aux
> surfaces with common code.
Nitpick: consider having a enum { SURFACE_MAIN = 0, SURFACE_AUX } and
use it instead of the magic numbers 0 and 1.
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_display.c | 56 ++--
>
> drivers/gpu/drm/i915/intel_drv.h | 6 +---
> drivers/gpu/drm/i915/intel_fbc.c | 4 +--
> drivers/gpu/drm/i915/intel_sprite.c | 29 ++-
> 4 files changed, 46 insertions(+), 49 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 994685230b97..3aec789657b1 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2946,9 +2946,9 @@ static bool
> skl_check_main_ccs_coordinates(struct intel_plane_state *plane_state
> const struct drm_framebuffer *fb = plane_state->base.fb;
> int hsub = fb->format->hsub;
> int vsub = fb->format->vsub;
> - int aux_x = plane_state->aux.x;
> - int aux_y = plane_state->aux.y;
> - u32 aux_offset = plane_state->aux.offset;
> + int aux_x = plane_state->color_plane[1].x;
> + int aux_y = plane_state->color_plane[1].y;
> + u32 aux_offset = plane_state->color_plane[1].offset;
> u32 alignment = intel_surf_alignment(fb, 1);
>
> while (aux_offset >= main_offset && aux_y <= main_y) {
> @@ -2971,9 +2971,9 @@ static bool
> skl_check_main_ccs_coordinates(struct intel_plane_state *plane_state
> if (aux_x != main_x || aux_y != main_y)
> return false;
>
> - plane_state->aux.offset = aux_offset;
> - plane_state->aux.x = aux_x;
> - plane_state->aux.y = aux_y;
> + plane_state->color_plane[1].offset = aux_offset;
> + plane_state->color_plane[1].x = aux_x;
> + plane_state->color_plane[1].y = aux_y;
>
> return true;
> }
> @@ -2994,7 +2994,7 @@ static int skl_check_main_surface(const struct
> intel_crtc_state *crtc_state,
> int pipe_src_w = crtc_state->pipe_src_w;
> int max_width = skl_max_plane_width(fb, 0, rotation);
> int max_height = 4096;
> - u32 alignment, offset, aux_offset = plane_state->aux.offset;
> + u32 alignment, offset, aux_offset = plane_state-
> >color_plane[1].offset;
>
> if (w > max_width || h > max_height) {
> DRM_DEBUG_KMS("requested Y/RGB source size %dx%d too
> big (limit %dx%d)\n",
> @@ -3067,15 +3067,15 @@ static int skl_check_main_surface(const
> struct intel_crtc_state *crtc_state,
> offs
> et, offset - alignment);
> }
>
> - if (x != plane_state->aux.x || y != plane_state->aux.y)
> {
> + if (x != plane_state->color_plane[1].x || y !=
> plane_state->color_plane[1].y) {
> DRM_DEBUG_KMS("Unable to find suitable display
> surface offset due to CCS\n");
> return -EINVAL;
> }
> }
>
> - plane_state->main.offset = offset;
> - plane_state->main.x = x;
> - plane_state->main.y = y;
> + plane_state->color_plane[0].offset = offset;
> + plane_state->color_plane[0].x = x;
> + plane_state->color_plane[0].y = y;
>
> return 0;
> }
> @@ -3125,9 +3125,9 @@ static int skl_check_nv12_aux_surface(struct
> intel_plane_state *plane_state)
> return -EINVAL;
> }
>
> - plane_state->aux.offset = offset;
> - plane_state->aux.x = x;
> - plane_state->aux.y = y;
> + plane_state->color_plane[1].offset = offset;
> + plane_state->color_plane[1].x = x;
> + plane_state->color_plane[1].y = y;
>
> return 0;
> }
> @@ -3152,9 +3152,9 @@ static int skl_check_ccs_aux_surface(struct
> intel_plane_state *plane_state)
> intel_add_fb_offsets(&x, &y, plane_state, 1);
> offset = intel_plane_compute_aligned_offset(&x, &y,
> plane_state, 1);
>
> - plane_state->aux.offset = offset;
> - plane_state->aux.x = x * hsub + src_x % hsub;
> - plane_state->aux.y = y * vsub + src_y % vsub;
> + plane_state->color_plane[1].offset = offset;
> + plane_state->color_plane[1].x = x * hsub + src_x % hsub;
> + plane_state->color_plane[1].y = y * vsub + src_y % vsub;
>
> return 0;
> }
> @@ -3198,9 +3198,9 @@ int skl_check_plane_surface(const struct
> intel_crtc_state *crtc_state,
> if (ret)
> return ret;
> } else {
> - plane_state->aux.offset = ~0xfff;
> - plane_state->aux.x = 0;
> - plane_state->aux.y = 0;
> + plane_state->color_plane[1].offset = ~0xfff;
> + plane_state->color_plane[1].x = 0;
> + plane_state->color_plane[1]
