Re: [PATCH v2] drm/i915: Fix "mitigations" parsing if i915 is builtin
On Wed, Apr 14, 2021 at 02:06:43PM +0800, Jisheng Zhang wrote:
> I met below error during boot with i915 builtin if pass
> "i915.mitigations=off":
> [0.015589] Booting kernel: `off' invalid for parameter `i915.mitigations'
>
> The reason is slab subsystem isn't ready at that time, so kstrdup()
> returns NULL. Fix this issue by using stack var instead of kstrdup().
>
> Fixes: 984cadea032b ("drm/i915: Allow the sysadmin to override security
> mitigations")
> Signed-off-by: Jisheng Zhang
> ---
> Since v1:
> - Ensure "str" is properly terminated. Thanks Ville for pointing this out.
>
> drivers/gpu/drm/i915/i915_mitigations.c | 8 +++-
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_mitigations.c
> b/drivers/gpu/drm/i915/i915_mitigations.c
> index 84f12598d145..231aad5ff46c 100644
> --- a/drivers/gpu/drm/i915/i915_mitigations.c
> +++ b/drivers/gpu/drm/i915/i915_mitigations.c
> @@ -29,15 +29,14 @@ bool i915_mitigate_clear_residuals(void)
> static int mitigations_set(const char *val, const struct kernel_param *kp)
> {
> unsigned long new = ~0UL;
> - char *str, *sep, *tok;
> + char str[64], *sep, *tok;
> bool first = true;
> int err = 0;
>
> BUILD_BUG_ON(ARRAY_SIZE(names) >= BITS_PER_TYPE(mitigations));
>
> - str = kstrdup(val, GFP_KERNEL);
> - if (!str)
> - return -ENOMEM;
> + strncpy(str, val, sizeof(str) - 1);
> + str[sizeof(str) - 1] = '\0';
Looks correct, however strscpy() seems to be the thing we should
be using these days.
>
> for (sep = str; (tok = strsep(, ","));) {
> bool enable = true;
> @@ -86,7 +85,6 @@ static int mitigations_set(const char *val, const struct
> kernel_param *kp)
> break;
> }
> }
> - kfree(str);
> if (err)
> return err;
>
> --
> 2.31.0
--
Ville Syrjälä
Intel
Re: [PATCH] drm/i915: Fix "mitigations" parsing if i915 is builtin
On Tue, Apr 13, 2021 at 05:02:40PM +0800, Jisheng Zhang wrote:
> I met below error during boot with i915 builtin if pass
> "i915.mitigations=off":
> [0.015589] Booting kernel: `off' invalid for parameter `i915.mitigations'
>
> The reason is slab subsystem isn't ready at that time, so kstrdup()
> returns NULL. Fix this issue by using stack var instead of kstrdup().
>
> Fixes: 984cadea032b ("drm/i915: Allow the sysadmin to override security
> mitigations")
> Signed-off-by: Jisheng Zhang
> ---
> drivers/gpu/drm/i915/i915_mitigations.c | 7 ++-
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_mitigations.c
> b/drivers/gpu/drm/i915/i915_mitigations.c
> index 84f12598d145..7dadf41064e0 100644
> --- a/drivers/gpu/drm/i915/i915_mitigations.c
> +++ b/drivers/gpu/drm/i915/i915_mitigations.c
> @@ -29,15 +29,13 @@ bool i915_mitigate_clear_residuals(void)
> static int mitigations_set(const char *val, const struct kernel_param *kp)
> {
> unsigned long new = ~0UL;
> - char *str, *sep, *tok;
> + char str[64], *sep, *tok;
> bool first = true;
> int err = 0;
>
> BUILD_BUG_ON(ARRAY_SIZE(names) >= BITS_PER_TYPE(mitigations));
>
> - str = kstrdup(val, GFP_KERNEL);
> - if (!str)
> - return -ENOMEM;
> + strncpy(str, val, sizeof(str) - 1);
I don't think strncpy() guarantees that the string is properly
terminated.
Also commit b1b6bed3b503 ("usb: core: fix quirks_param_set() writing to
a const pointer") looks broken as well given your findings, and
arch/um/drivers/virtio_uml.c seems to suffer from this as well.
kernel/params.c itself seems to have some slab_is_available() magic
around kmalloc().
I used the following cocci snippet to find these:
@find@
identifier O, F;
position PS;
@@
struct kernel_param_ops O = {
...,
.set = F@PS
,...
};
@alloc@
identifier ALLOC =~ "^k.*(alloc|dup)";
identifier find.F;
position PA;
@@
F(...) {
<+...
ALLOC@PA(...)
...+>
}
@script:python depends on alloc@
ps << find.PS;
pa << alloc.PA;
@@
coccilib.report.print_report(ps[0], "struct")
coccilib.report.print_report(pa[0], "alloc")
That could of course miss a bunch more if they allocate
via some other function I didn't consider.
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH v2] drm/i915: Fix invalid access to ACPI _DSM objects
On Thu, Apr 08, 2021 at 06:34:06PM +0200, Takashi Iwai wrote: > On Thu, 08 Apr 2021 09:51:18 +0200, > Takashi Iwai wrote: > > > > On Wed, 07 Apr 2021 23:28:48 +0200, > > Ville Syrjälä wrote: > > > > > > Oh, could you ask the bug reporter to attach an acpidump to the > > > bug? Might be good to have that stuff on record somewhere if/when > > > someone wants to actually figure out what's going on here. > > > > OK, I'll ask. > > Available at > acpidump: https://susepaste.org/59777448 > hwinfo: https://susepaste.org/86284020 Those will apparently expire real soon. I took local copies out of morbid curiosity, but that's not going to help anyone else in the future. I rather wish bug reporting tools would flat out refuse to accept any pastebin links. -- Ville Syrjälä Intel
Re: [Intel-gfx] [PATCH v2] drm/i915: Fix invalid access to ACPI _DSM objects
On Wed, Apr 07, 2021 at 06:56:15PM +0200, Takashi Iwai wrote:
> On Wed, 07 Apr 2021 18:34:46 +0200,
> Ville Syrjälä wrote:
> >
> > On Fri, Apr 02, 2021 at 10:23:17AM +0200, Takashi Iwai wrote:
> > > intel_dsm_platform_mux_info() tries to parse the ACPI package data
> > > from _DSM for the debug information, but it assumes the fixed format
> > > without checking what values are stored in the elements actually.
> > > When an unexpected value is returned from BIOS, it may lead to GPF or
> > > NULL dereference, as reported recently.
> > >
> > > Add the checks of the contents in the returned values and skip the
> > > values for invalid cases.
> > >
> > > v1->v2: Check the info contents before dereferencing, too
> > >
> > > BugLink: http://bugzilla.opensuse.org/show_bug.cgi?id=1184074
> > > Cc:
> > > Signed-off-by: Takashi Iwai
> > > ---
> > > drivers/gpu/drm/i915/display/intel_acpi.c | 22 --
> > > 1 file changed, 20 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_acpi.c
> > > b/drivers/gpu/drm/i915/display/intel_acpi.c
> > > index e21fb14d5e07..833d0c1be4f1 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_acpi.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_acpi.c
> > > @@ -84,13 +84,31 @@ static void intel_dsm_platform_mux_info(acpi_handle
> > > dhandle)
> > > return;
> > > }
> > >
> > > + if (!pkg->package.count) {
> > > + DRM_DEBUG_DRIVER("no connection in _DSM\n");
> > > + return;
> > > + }
> > > +
> > > connector_count = >package.elements[0];
> > > DRM_DEBUG_DRIVER("MUX info connectors: %lld\n",
> > > (unsigned long long)connector_count->integer.value);
> > > for (i = 1; i < pkg->package.count; i++) {
> > > union acpi_object *obj = >package.elements[i];
> > > - union acpi_object *connector_id = >package.elements[0];
> > > - union acpi_object *info = >package.elements[1];
> > > + union acpi_object *connector_id;
> > > + union acpi_object *info;
> > > +
> > > + if (obj->type != ACPI_TYPE_PACKAGE || obj->package.count < 2) {
> > > + DRM_DEBUG_DRIVER("Invalid object for MUX #%d\n", i);
> > > + continue;
> > > + }
> > > +
> > > + connector_id = >package.elements[0];
> >
> > You don't want to check connector_id->type as well?
>
> I added only the minimal checks that may lead to Oops.
OK. I guess misinterpreting something else as an integer isn't
particular dangerous in this case.
Pushed to drm-intel-next. Thanks.
Oh, could you ask the bug reporter to attach an acpidump to the
bug? Might be good to have that stuff on record somewhere if/when
someone wants to actually figure out what's going on here.
That said, maybe we should just nuke this whole thing instead?
Unless I'm missing someting this code doesn't seem to actually
do anything...
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH v2] drm/i915: Fix invalid access to ACPI _DSM objects
On Fri, Apr 02, 2021 at 10:23:17AM +0200, Takashi Iwai wrote:
> intel_dsm_platform_mux_info() tries to parse the ACPI package data
> from _DSM for the debug information, but it assumes the fixed format
> without checking what values are stored in the elements actually.
> When an unexpected value is returned from BIOS, it may lead to GPF or
> NULL dereference, as reported recently.
>
> Add the checks of the contents in the returned values and skip the
> values for invalid cases.
>
> v1->v2: Check the info contents before dereferencing, too
>
> BugLink: http://bugzilla.opensuse.org/show_bug.cgi?id=1184074
> Cc:
> Signed-off-by: Takashi Iwai
> ---
> drivers/gpu/drm/i915/display/intel_acpi.c | 22 --
> 1 file changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_acpi.c
> b/drivers/gpu/drm/i915/display/intel_acpi.c
> index e21fb14d5e07..833d0c1be4f1 100644
> --- a/drivers/gpu/drm/i915/display/intel_acpi.c
> +++ b/drivers/gpu/drm/i915/display/intel_acpi.c
> @@ -84,13 +84,31 @@ static void intel_dsm_platform_mux_info(acpi_handle
> dhandle)
> return;
> }
>
> + if (!pkg->package.count) {
> + DRM_DEBUG_DRIVER("no connection in _DSM\n");
> + return;
> + }
> +
> connector_count = >package.elements[0];
> DRM_DEBUG_DRIVER("MUX info connectors: %lld\n",
> (unsigned long long)connector_count->integer.value);
> for (i = 1; i < pkg->package.count; i++) {
> union acpi_object *obj = >package.elements[i];
> - union acpi_object *connector_id = >package.elements[0];
> - union acpi_object *info = >package.elements[1];
> + union acpi_object *connector_id;
> + union acpi_object *info;
> +
> + if (obj->type != ACPI_TYPE_PACKAGE || obj->package.count < 2) {
> + DRM_DEBUG_DRIVER("Invalid object for MUX #%d\n", i);
> + continue;
> + }
> +
> + connector_id = >package.elements[0];
You don't want to check connector_id->type as well?
> + info = >package.elements[1];
> + if (info->type != ACPI_TYPE_BUFFER || info->buffer.length < 4) {
> + DRM_DEBUG_DRIVER("Invalid info for MUX obj #%d\n", i);
> + continue;
> + }
> +
> DRM_DEBUG_DRIVER("Connector id: 0x%016llx\n",
> (unsigned long long)connector_id->integer.value);
> DRM_DEBUG_DRIVER(" port id: %s\n",
> --
> 2.26.2
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
Re: [PATCH v2 09/14] drm/edid: Use the cached EDID in drm_get_edid() if eDP
On Mon, Mar 29, 2021 at 07:53:40PM -0700, Douglas Anderson wrote:
> Each time we call drm_get_edid() we:
> 1. Go out to the bus and ask for the EDID.
> 2. Cache the EDID.
>
> We can improve this to actually use the cached EDID so that if
> drm_get_edid() is called multiple times then we don't need to go out
> to the bus over and over again.
>
> In normal DP/HDMI cases reading the EDID over and over again isn't
> _that_ expensive so, presumably, this wasn't that critical in the
> past. However for eDP going out to the bus can be expensive. This is
> because eDP panels might be powered off before the EDID was requested
> so we need to do power sequencing in addition to the transfer.
>
> In theory we should be able to cache the EDID for all types of
> displays. There is already code throwing the cache away when we detect
> that a display was unplugged. However, it can be noted that it's
> _extra_ safe to cache the EDID for eDP since eDP isn't a hot-pluggable
> interface. If we get the EDID once then we've got the EDID and we
> should never need to read it again. For now we'll only use the cache
> for eDP both because it's more important and extra safe.
>
> Signed-off-by: Douglas Anderson
> ---
>
> (no changes since v1)
>
> drivers/gpu/drm/drm_edid.c | 32
> 1 file changed, 28 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index c2bbe7bee7b6..fcbf468d73c9 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -2049,15 +2049,39 @@ struct edid *drm_get_edid(struct drm_connector
> *connector,
> struct i2c_adapter *adapter)
> {
> struct edid *edid;
> + size_t old_edid_size;
> + const struct edid *old_edid;
>
> if (connector->force == DRM_FORCE_OFF)
> return NULL;
>
> - if (connector->force == DRM_FORCE_UNSPECIFIED &&
> !drm_probe_ddc(adapter))
> - return NULL;
> + if (connector->connector_type == DRM_MODE_CONNECTOR_eDP &&
> + connector->edid_blob_ptr) {
> + /*
> + * eDP devices are non-removable, or at least not something
> + * that's expected to be hot-pluggable. We can freely use
> + * the cached EDID.
> + *
> + * NOTE: technically we could probably even use the cached
> + * EDID even for non-eDP because the cached EDID should be
> + * cleared if we ever notice a display is not connected, but
> + * we'll use an abundance of caution and only do it for eDP.
> + * It's more important for eDP anyway because the EDID may not
> + * always be readable, like when the panel is powered down.
> + */
> + old_edid = (const struct edid *)connector->edid_blob_ptr->data;
> + old_edid_size = ksize(old_edid);
> + edid = kmalloc(old_edid_size, GFP_KERNEL);
> + if (edid)
> + memcpy(edid, old_edid, old_edid_size);
> + } else {
> + if (connector->force == DRM_FORCE_UNSPECIFIED &&
> !drm_probe_ddc(adapter))
> + return NULL;
> +
> + edid = drm_do_get_edid(connector, drm_do_probe_ddc_edid,
> adapter);
> + drm_connector_update_edid_property(connector, edid);
> + }
This is a pretty low level function. Too low level for this caching
IMO. So I think better just do it a bit higher up like other drivers.
>
> - edid = drm_do_get_edid(connector, drm_do_probe_ddc_edid, adapter);
> - drm_connector_update_edid_property(connector, edid);
> return edid;
> }
> EXPORT_SYMBOL(drm_get_edid);
> --
> 2.31.0.291.g576ba9dcdaf-goog
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
Re: [PATCH 10/11] drm/i915: avoid stringop-overread warning on pri_latency
On Wed, Mar 24, 2021 at 05:30:24PM +0200, Jani Nikula wrote:
> On Mon, 22 Mar 2021, Arnd Bergmann wrote:
> > From: Arnd Bergmann
> >
> > gcc-11 warns about what appears to be an out-of-range array access:
> >
> > In function ‘snb_wm_latency_quirk’,
> > inlined from ‘ilk_setup_wm_latency’ at
> > drivers/gpu/drm/i915/intel_pm.c:3108:3:
> > drivers/gpu/drm/i915/intel_pm.c:3057:9: error: ‘intel_print_wm_latency’
> > reading 16 bytes from a region of size 10 [-Werror=stringop-overread]
> > 3057 | intel_print_wm_latency(dev_priv, "Primary",
> > dev_priv->wm.pri_latency);
> > |
> > ^
> > drivers/gpu/drm/i915/intel_pm.c: In function ‘ilk_setup_wm_latency’:
> > drivers/gpu/drm/i915/intel_pm.c:3057:9: note: referencing argument 3 of
> > type ‘const u16 *’ {aka ‘const short unsigned int *’}
> > drivers/gpu/drm/i915/intel_pm.c:2994:13: note: in a call to function
> > ‘intel_print_wm_latency’
> > 2994 | static void intel_print_wm_latency(struct drm_i915_private
> > *dev_priv,
> > | ^~
> >
> > My guess is that this code is actually safe because the size of the
> > array depends on the hardware generation, and the function checks for
> > that, but at the same time I would not expect the compiler to work it
> > out correctly, and the code seems a little fragile with regards to
> > future changes. Simply increasing the size of the array should help.
>
> Agreed, I don't think there's an issue, but the code could use a bunch
> of improvements.
>
> Like, we have intel_print_wm_latency() for debug logging and
> wm_latency_show() for debugfs, and there's a bunch of duplication and
> ugh.
There is all this ancient stuff in review limbo...
https://patchwork.freedesktop.org/series/50802/
--
Ville Syrjälä
Intel
Re: [PATCH 04/19] include: drm: drm_atomic: Make use of 'new_plane_state'
On Fri, Mar 19, 2021 at 08:24:13AM +, Lee Jones wrote: > In the macro for_each_oldnew_plane_in_state() 'new_plane_state' is provided > as a container for state->planes[i].new_state, but is not utilised in > some use-cases, so we fake-use it instead. > > Fixes the following W=1 kernel build warning(s): > > drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c: In function > ‘amdgpu_dm_commit_cursors’: > drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:7649:44: > warning: variable ‘new_plane_state’ set but not used > [-Wunused-but-set-variable] > > Cc: Maarten Lankhorst > Cc: Maxime Ripard > Cc: Thomas Zimmermann > Cc: David Airlie > Cc: Daniel Vetter > Cc: Rob Clark > Cc: dri-de...@lists.freedesktop.org > Signed-off-by: Lee Jones > --- > include/drm/drm_atomic.h | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h > index ac5a28eff2c86..259e6970dc836 100644 > --- a/include/drm/drm_atomic.h > +++ b/include/drm/drm_atomic.h > @@ -871,7 +871,8 @@ void drm_state_dump(struct drm_device *dev, struct > drm_printer *p); >((plane) = (__state)->planes[__i].ptr, \ > (void)(plane) /* Only to avoid > unused-but-set-variable warning */, \ > (old_plane_state) = > (__state)->planes[__i].old_state,\ > - (new_plane_state) = > (__state)->planes[__i].new_state, 1)) > + (new_plane_state) = > (__state)->planes[__i].new_state, \ > + (void)(new_plane_state) /* Only to avoid > unused-but-set-variable warning */, 1)) In this case you can just switch the code to use for_each_old_plane_in_state() instead. > > /** > * for_each_oldnew_plane_in_state_reverse - iterate over all planes in an > atomic > -- > 2.27.0 > > _______ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Ville Syrjälä Intel
Re: [PATCH] rtc: cmos: Disable irq around direct invocation of cmos_interrupt()
<4>[ 254.193785] cmos_resume+0x2ac/0x2d0
> <4>[ 254.193813] ? acpi_pm_set_device_wakeup+0x1f/0x110
> <4>[ 254.193842] ? pnp_bus_suspend+0x10/0x10
> <4>[ 254.193864] pnp_bus_resume+0x5e/0x90
> <4>[ 254.193885] dpm_run_callback+0x5f/0x240
> <4>[ 254.193914] device_resume+0xb2/0x1e0
> <4>[ 254.193942] ? pm_dev_err+0x25/0x25
> <4>[ 254.193974] dpm_resume+0xea/0x3f0
> <4>[ 254.194005] dpm_resume_end+0x8/0x10
> <4>[ 254.194030] suspend_devices_and_enter+0x29b/0xaa0
> <4>[ 254.194066] pm_suspend.cold.8+0x301/0x34a
> <4>[ 254.194094] state_store+0x7b/0xe0
> <4>[ 254.194124] kernfs_fop_write_iter+0x11d/0x1c0
> <4>[ 254.194151] new_sync_write+0x11d/0x1b0
> <4>[ 254.194183] vfs_write+0x265/0x390
> <4>[ 254.194207] ksys_write+0x5a/0xd0
> <4>[ 254.194232] do_syscall_64+0x33/0x80
> <4>[ 254.194251] entry_SYSCALL_64_after_hwframe+0x44/0xae
> <4>[ 254.194274] RIP: 0033:0x7f07d79691e7
> <4>[ 254.194293] Code: 64 89 02 48 c7 c0 ff ff ff ff eb bb 0f 1f 80 00 00 00
> 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48>
> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24
> <4>[ 254.194312] RSP: 002b:7ffd9cc2c768 EFLAGS: 0246 ORIG_RAX:
> 0001
> <4>[ 254.194337] RAX: ffda RBX: 0004 RCX:
> 7f07d79691e7
> <4>[ 254.194352] RDX: 0004 RSI: 556ebfc63590 RDI:
> 000b
> <4>[ 254.194366] RBP: 556ebfc63590 R08: R09:
> 0004
> <4>[ 254.194379] R10: 556ebf0ec2a6 R11: 0246 R12:
> 0004
>
> which breaks S3-resume on fi-kbl-soraka presumably as that's slow enough
> to trigger the alarm during the suspend.
>
> Fixes: 6950d046eb6e ("rtc: cmos: Replace spin_lock_irqsave with spin_lock in
> hard IRQ")
Sigh. I wish people would at least try to check the code/history
before doing these blind "cleanups" :(
> References: 66e4f4a9cc38 ("rtc: cmos: Use spin_lock_irqsave() in
> cmos_interrupt()"):
> Signed-off-by: Chris Wilson
> Cc: Xiaofei Tan
> Cc: Alexandre Belloni
> Cc: Alessandro Zummo
> Cc: Ville Syrjälä
> ---
> drivers/rtc/rtc-cmos.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
> index 670fd8a2970e..6545afb2f20e 100644
> --- a/drivers/rtc/rtc-cmos.c
> +++ b/drivers/rtc/rtc-cmos.c
> @@ -1053,7 +1053,9 @@ static void cmos_check_wkalrm(struct device *dev)
>* ACK the rtc irq here
>*/
> if (t_now >= cmos->alarm_expires && cmos_use_acpi_alarm()) {
> + local_irq_disable();
> cmos_interrupt(0, (void *)cmos->rtc);
> + local_irq_enable();
Yeah, given what's already happened this seems more likely to
survive a bit longer.
Reviewed-by: Ville Syrjälä
> return;
> }
>
> --
> 2.20.1
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [WARNING] v5.12-rc1 in intel_pipe_disable tracepoint
On Mon, Mar 01, 2021 at 07:20:59PM +0200, Ville Syrjälä wrote: > On Mon, Mar 01, 2021 at 11:59:46AM -0500, Steven Rostedt wrote: > > > > On my test box with latest v5.12-rc1, running with all trace events > > enabled, I consistently trigger this warning. > > > > It appears to get triggered by the trace_intel_pipe_disable() code. > > > > -- Steve > > > > [ cut here ] > > i915 :00:02.0: drm_WARN_ON_ONCE(drm_drv_uses_atomic_modeset(dev)) > > WARNING: CPU: 7 PID: 1258 at drivers/gpu/drm/drm_vblank.c:728 > > drm_crtc_vblank_helper_get_vblank_timestamp_internal+0x319/0x330 [drm] > > Modules linked in: ebtable_filter ebtables bridge stp llc vsock vmw_vmci > > ipt_REJECT nf_reject_ipv4 iptable_filter ip6t_REJECT nf_reject_ipv6 > > xt_state xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 > > ip6table_filter ip6_tables snd_hda_codec_hdmi snd_h > > ek snd_hda_codec_generic ledtrig_audio snd_hda_intel snd_intel_dspcfg > > snd_hda_codec joydev snd_hwdep intel_rapl_msr snd_hda_core hp_wmi i915 > > iTCO_wdt snd_seq intel_rapl_common iTCO_vendor_support wmi_bmof > > sparse_keymap snd_seq_device rfkill snd_pcm x86_pkg_t > > d_timer i2c_algo_bit drm_kms_helper mei_me intel_powerclamp snd mei > > soundcore i2c_i801 drm coretemp lpc_ich e1000e kvm_intel i2c_smbus kvm > > irqbypass crct10dif_pclmul crc32_pclmul crc32c_intel serio_raw > > ghash_clmulni_intel video tpm_infineon wmi ip_tables > > CPU: 7 PID: 1258 Comm: Xorg Tainted: GW 5.12.0-rc1-test+ > > #12 > > Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 > > v03.03 07/14/2016 > > RIP: 0010:drm_crtc_vblank_helper_get_vblank_timestamp_internal+0x319/0x330 > > [drm] > > Code: 4c 8b 6f 50 4d 85 ed 75 03 4c 8b 2f e8 60 92 45 c2 48 c7 c1 28 a5 3c > > c0 4c 89 ea 48 c7 c7 15 5a 3c c0 48 89 c6 e8 1f e7 7b c2 <0f> 0b e9 e2 fe > > ff ff e8 fb 6c 81 c2 66 66 2e 0f 1f 84 00 00 00 00 > > RSP: 0018:b77580ea7920 EFLAGS: 00010082 > > RAX: RBX: 8afe500c RCX: > > RDX: 0004 RSI: 833c86b8 RDI: 0001 > > RBP: b77580ea7990 R08: 00700c782173 R09: > > R10: 0001 R11: 0001 R12: > > R13: 8afe41c7eff0 R14: c05e0410 R15: 8afe456a2bf8 > > FS: 7f8f91869f00() GS:8afe5aa0() > > knlGS: > > CS: 0010 DS: ES: CR0: 80050033 > > CR2: 7f9523a6cad0 CR3: 01b78002 CR4: 001706e0 > > Call Trace: > > drm_get_last_vbltimestamp+0xaa/0xc0 [drm] > > drm_update_vblank_count+0x90/0x2d0 [drm] > > drm_crtc_accurate_vblank_count+0x3e/0xc0 [drm] > > intel_crtc_get_vblank_counter+0x43/0x50 [i915] > > trace_event_raw_event_intel_pipe_disable+0x87/0x110 [i915] > > intel_disable_pipe+0x1a8/0x210 [i915] > > Hmm. Yeah we do vblank_off() before pipe_disable() which wants > to still grab the frame counter in the tracepoint. I think we > could reorder those two without causing any problems. Either > that or we put the tracepoint before vblank_off(). > > > ilk_crtc_disable+0x85/0x390 [i915] > > But this part is confusing me. intel_crtc_get_vblank_counter() is > only supposed to do drm_crtc_accurate_vblank_count() fallback when > the hardware lacks a working frame counter, and that should only > be the case for ancient gen2 or semi-ancient i965gm TV output, > ilk_crtc_disable() is not the function we should be calling in > either of those cases. OK, figured this out. It can happen on any platform due to never initializing .max_vblank_count for pipes that were disabled at boot. Also spotted some other issues in this code that needs fixing. I'll mail out some patches... -- Ville Syrjälä Intel
Re: [PATCH -next v2] fbdev: atyfb: use LCD management functions for PPC_PMAC also
On Fri, Feb 26, 2021 at 09:30:08AM -0800, Randy Dunlap wrote:
> Include PPC_PMAC in the configs that use aty_ld_lcd() and
> aty_st_lcd() implementations so that the PM code may work
> correctly for PPC_PMAC.
>
> Suggested-by: Ville Syrjälä
> Signed-off-by: Randy Dunlap
> Cc: Daniel Vetter
> Cc: Nick Desaulniers
> Cc: linux-fb...@vger.kernel.org
> Cc: dri-de...@lists.freedesktop.org
> Cc: Bartlomiej Zolnierkiewicz
> Cc: Sam Ravnborg
> Cc: David Airlie
> Cc: Jani Nikula
> ---
> Daniel- We also need this patch:
> https://lore.kernel.org/dri-devel/20210224215528.822-1-rdun...@infradead.org/
> to fix a kernel test robot build error.
>
> v2: send the correct version of this patch (thanks, Ville)
Both patches pushed to drm-misc-fixes. Thanks.
>
> drivers/video/fbdev/aty/atyfb_base.c |9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> --- linux-next-20210219.orig/drivers/video/fbdev/aty/atyfb_base.c
> +++ linux-next-20210219/drivers/video/fbdev/aty/atyfb_base.c
> @@ -133,7 +133,7 @@
> #define PRINTKE(fmt, args...)printk(KERN_ERR "atyfb: " fmt, ## args)
>
> #if defined(CONFIG_PMAC_BACKLIGHT) || defined(CONFIG_FB_ATY_GENERIC_LCD) || \
> -defined(CONFIG_FB_ATY_BACKLIGHT)
> +defined(CONFIG_FB_ATY_BACKLIGHT) || defined (CONFIG_PPC_PMAC)
> static const u32 lt_lcd_regs[] = {
> CNFG_PANEL_LG,
> LCD_GEN_CNTL_LG,
> @@ -175,8 +175,8 @@ u32 aty_ld_lcd(int index, const struct a
> return aty_ld_le32(LCD_DATA, par);
> }
> }
> -#else /* defined(CONFIG_PMAC_BACKLIGHT) || defined(CONFIG_FB_ATY_BACKLIGHT) \
> - defined(CONFIG_FB_ATY_GENERIC_LCD) */
> +#else /* defined(CONFIG_PMAC_BACKLIGHT) || defined(CONFIG_FB_ATY_BACKLIGHT)
> ||
> + defined(CONFIG_FB_ATY_GENERIC_LCD) || defined(CONFIG_PPC_PMAC) */
> void aty_st_lcd(int index, u32 val, const struct atyfb_par *par)
> { }
>
> @@ -184,7 +184,8 @@ u32 aty_ld_lcd(int index, const struct a
> {
> return 0;
> }
> -#endif /* defined(CONFIG_PMAC_BACKLIGHT) || defined
> (CONFIG_FB_ATY_GENERIC_LCD) */
> +#endif /* defined(CONFIG_PMAC_BACKLIGHT) || defined(CONFIG_FB_ATY_BACKLIGHT)
> ||
> + defined (CONFIG_FB_ATY_GENERIC_LCD) || defined(CONFIG_PPC_PMAC) */
>
> #ifdef CONFIG_FB_ATY_GENERIC_LCD
> /*
--
Ville Syrjälä
Intel
Re: [WARNING] v5.12-rc1 in intel_pipe_disable tracepoint
On Mon, Mar 01, 2021 at 11:59:46AM -0500, Steven Rostedt wrote: > > On my test box with latest v5.12-rc1, running with all trace events > enabled, I consistently trigger this warning. > > It appears to get triggered by the trace_intel_pipe_disable() code. > > -- Steve > > [ cut here ] > i915 :00:02.0: drm_WARN_ON_ONCE(drm_drv_uses_atomic_modeset(dev)) > WARNING: CPU: 7 PID: 1258 at drivers/gpu/drm/drm_vblank.c:728 > drm_crtc_vblank_helper_get_vblank_timestamp_internal+0x319/0x330 [drm] > Modules linked in: ebtable_filter ebtables bridge stp llc vsock vmw_vmci > ipt_REJECT nf_reject_ipv4 iptable_filter ip6t_REJECT nf_reject_ipv6 xt_state > xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip6table_filter > ip6_tables snd_hda_codec_hdmi snd_h > ek snd_hda_codec_generic ledtrig_audio snd_hda_intel snd_intel_dspcfg > snd_hda_codec joydev snd_hwdep intel_rapl_msr snd_hda_core hp_wmi i915 > iTCO_wdt snd_seq intel_rapl_common iTCO_vendor_support wmi_bmof sparse_keymap > snd_seq_device rfkill snd_pcm x86_pkg_t > d_timer i2c_algo_bit drm_kms_helper mei_me intel_powerclamp snd mei soundcore > i2c_i801 drm coretemp lpc_ich e1000e kvm_intel i2c_smbus kvm irqbypass > crct10dif_pclmul crc32_pclmul crc32c_intel serio_raw ghash_clmulni_intel > video tpm_infineon wmi ip_tables > CPU: 7 PID: 1258 Comm: Xorg Tainted: GW 5.12.0-rc1-test+ #12 > Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v03.03 > 07/14/2016 > RIP: 0010:drm_crtc_vblank_helper_get_vblank_timestamp_internal+0x319/0x330 > [drm] > Code: 4c 8b 6f 50 4d 85 ed 75 03 4c 8b 2f e8 60 92 45 c2 48 c7 c1 28 a5 3c > c0 4c 89 ea 48 c7 c7 15 5a 3c c0 48 89 c6 e8 1f e7 7b c2 <0f> 0b e9 e2 fe ff > ff e8 fb 6c 81 c2 66 66 2e 0f 1f 84 00 00 00 00 > RSP: 0018:b77580ea7920 EFLAGS: 00010082 > RAX: RBX: 8afe500c RCX: > RDX: 0004 RSI: 833c86b8 RDI: 0001 > RBP: b77580ea7990 R08: 00700c782173 R09: > R10: 0001 R11: 0001 R12: > R13: 8afe41c7eff0 R14: c05e0410 R15: 8afe456a2bf8 > FS: 7f8f91869f00() GS:8afe5aa0() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: 7f9523a6cad0 CR3: 01b78002 CR4: 001706e0 > Call Trace: > drm_get_last_vbltimestamp+0xaa/0xc0 [drm] > drm_update_vblank_count+0x90/0x2d0 [drm] > drm_crtc_accurate_vblank_count+0x3e/0xc0 [drm] > intel_crtc_get_vblank_counter+0x43/0x50 [i915] > trace_event_raw_event_intel_pipe_disable+0x87/0x110 [i915] > intel_disable_pipe+0x1a8/0x210 [i915] Hmm. Yeah we do vblank_off() before pipe_disable() which wants to still grab the frame counter in the tracepoint. I think we could reorder those two without causing any problems. Either that or we put the tracepoint before vblank_off(). > ilk_crtc_disable+0x85/0x390 [i915] But this part is confusing me. intel_crtc_get_vblank_counter() is only supposed to do drm_crtc_accurate_vblank_count() fallback when the hardware lacks a working frame counter, and that should only be the case for ancient gen2 or semi-ancient i965gm TV output, ilk_crtc_disable() is not the function we should be calling in either of those cases. What hardware do you have? > intel_old_crtc_state_disables.isra.0+0x5c/0x110 [i915] > intel_atomic_commit_tail+0xf5d/0x1460 [i915] > ? complete+0x18/0x40 > intel_atomic_commit+0x345/0x3c0 [i915] > drm_atomic_connector_commit_dpms+0xd7/0x100 [drm] > set_property_atomic+0xcc/0x160 [drm] > drm_mode_obj_set_property_ioctl+0xbd/0x100 [drm] > ? drm_connector_set_obj_prop+0x90/0x90 [drm] > drm_connector_property_set_ioctl+0x39/0x60 [drm] > drm_ioctl_kernel+0xad/0x100 [drm] > drm_ioctl+0x1ec/0x390 [drm] > ? drm_connector_set_obj_prop+0x90/0x90 [drm] > ? sched_clock_cpu+0x10/0xd0 > ? lock_release+0x155/0x410 > __x64_sys_ioctl+0x83/0xb0 > do_syscall_64+0x33/0x40 > entry_SYSCALL_64_after_hwframe+0x44/0xae > RIP: 0033:0x7f8f91ce535b > Code: 0f 1e fa 48 8b 05 2d 9b 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff > ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff > 73 01 c3 48 8b 0d fd 9a 0c 00 f7 d8 64 89 01 48 > RSP: 002b:7ffcb4603378 EFLAGS: 0246 ORIG_RAX: 0010 > RAX: ffda RBX: 7ffcb46033b0 RCX: 7f8f91ce535b > RDX: 7ffcb46033b0 RSI: c01064ab RDI: 000e > RBP: c01064ab R08: 55d68f44ba60 R09: > R10: 55d68f44ba60 R11: 0246 R12: 55d68f5e0010 > R13: 000e R14: 0000 R15: 55d68e2275c0 > ---[ end trace d18216ba28a2f0e8 ]--- > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Ville Syrjälä Intel
Re: [PATCH -next] fbdev: atyfb: use LCD management functions for PPC_PMAC also
On Thu, Feb 25, 2021 at 04:05:37PM -0800, Randy Dunlap wrote:
> Include PPC_PMAC in the configs that use aty_ld_lcd() and
> aty_st_lcd() implementations so that the PM code may work
> correctly for PPC_PMAC.
>
> Suggested-by: Ville Syrjälä
> Signed-off-by: Randy Dunlap
> Cc: Daniel Vetter
> Cc: Nick Desaulniers
> Cc: linux-fb...@vger.kernel.org
> Cc: dri-de...@lists.freedesktop.org
> Cc: Bartlomiej Zolnierkiewicz
> Cc: Sam Ravnborg
> Cc: David Airlie
> Cc: Jani Nikula
> ---
> Daniel- We also need this patch:
> https://lore.kernel.org/dri-devel/20210224215528.822-1-rdun...@infradead.org/
> to fix a kernel test robot build error.
>
> drivers/video/fbdev/aty/atyfb_base.c |8 +++-
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> --- linux-next-20210219.orig/drivers/video/fbdev/aty/atyfb_base.c
> +++ linux-next-20210219/drivers/video/fbdev/aty/atyfb_base.c
> @@ -132,8 +132,7 @@
> #define PRINTKI(fmt, args...)printk(KERN_INFO "atyfb: " fmt, ## args)
> #define PRINTKE(fmt, args...)printk(KERN_ERR "atyfb: " fmt, ## args)
>
> -#if defined(CONFIG_PMAC_BACKLIGHT) || defined(CONFIG_FB_ATY_GENERIC_LCD) || \
> -defined(CONFIG_FB_ATY_BACKLIGHT)
> +#if defined(CONFIG_PPC_PMAC)
Did you send an old version by accident? That's definitely
not what we want since it would break everything except PPC_PMAC.
> static const u32 lt_lcd_regs[] = {
> CNFG_PANEL_LG,
> LCD_GEN_CNTL_LG,
> @@ -175,8 +174,7 @@ u32 aty_ld_lcd(int index, const struct a
> return aty_ld_le32(LCD_DATA, par);
> }
> }
> -#else /* defined(CONFIG_PMAC_BACKLIGHT) || defined(CONFIG_FB_ATY_BACKLIGHT) \
> - defined(CONFIG_FB_ATY_GENERIC_LCD) */
> +#else /* defined(CONFIG_PPC_PMAC) */
> void aty_st_lcd(int index, u32 val, const struct atyfb_par *par)
> { }
>
> @@ -184,7 +182,7 @@ u32 aty_ld_lcd(int index, const struct a
> {
> return 0;
> }
> -#endif /* defined(CONFIG_PMAC_BACKLIGHT) || defined
> (CONFIG_FB_ATY_GENERIC_LCD) */
> +#endif /* defined(CONFIG_PPC_PMAC) */
>
> #ifdef CONFIG_FB_ATY_GENERIC_LCD
> /*
--
Ville Syrjälä
Intel
Re: [PATCH] fbdev: atyfb: add stubs for aty_{ld,st}_lcd()
On Wed, Feb 24, 2021 at 11:59:45AM -0800, Randy Dunlap wrote:
> On 2/22/21 9:44 AM, Ville Syrjälä wrote:
> > On Sun, Feb 21, 2021 at 07:28:53PM -0800, Randy Dunlap wrote:
> >> Fix build errors when these functions are not defined.
> >>
> >> ../drivers/video/fbdev/aty/atyfb_base.c: In function 'aty_power_mgmt':
> >> ../drivers/video/fbdev/aty/atyfb_base.c:2002:7: error: implicit
> >> declaration of function 'aty_ld_lcd'; did you mean 'aty_ld_8'?
> >> [-Werror=implicit-function-declaration]
> >> 2002 | pm = aty_ld_lcd(POWER_MANAGEMENT, par);
> >> ../drivers/video/fbdev/aty/atyfb_base.c:2004:2: error: implicit
> >> declaration of function 'aty_st_lcd'; did you mean 'aty_st_8'?
> >> [-Werror=implicit-function-declaration]
> >> 2004 | aty_st_lcd(POWER_MANAGEMENT, pm, par);
> >> Signed-off-by: Randy Dunlap
> >> Reported-by: kernel test robot
> >> Cc: linux-fb...@vger.kernel.org
> >> Cc: dri-de...@lists.freedesktop.org
> >> Cc: Bartlomiej Zolnierkiewicz
> >> Cc: Sam Ravnborg
> >> Cc: Daniel Vetter
> >> Cc: David Airlie
> >> Cc: Jani Nikula
> >> ---
> >> drivers/video/fbdev/aty/atyfb_base.c |9 +
> >> 1 file changed, 9 insertions(+)
> >>
> >> --- linux-next-20210219.orig/drivers/video/fbdev/aty/atyfb_base.c
> >> +++ linux-next-20210219/drivers/video/fbdev/aty/atyfb_base.c
> >> @@ -175,6 +175,15 @@ u32 aty_ld_lcd(int index, const struct a
> >>return aty_ld_le32(LCD_DATA, par);
> >>}
> >> }
> >> +#else /* defined(CONFIG_PMAC_BACKLIGHT) ||
> >> defined(CONFIG_FB_ATY_BACKLIGHT) \
> >> + defined(CONFIG_FB_ATY_GENERIC_LCD) */
> >
> > A better fix would seem to be to include these functions if
> > CONFIG_PPC_PMAC is enabled. Otherwise the PM code will surely
> > not work correctly. Though I'm not sure if that PPC PM
> > code makes any sense w/o LCD/backlight support anyway.
>
> Hi Ville,
>
> I tried this:
>
> -#if defined(CONFIG_PMAC_BACKLIGHT) || defined(CONFIG_FB_ATY_GENERIC_LCD) || \
> -defined(CONFIG_FB_ATY_BACKLIGHT)
> +#if defined(CONFIG_PPC_PMAC)
>
> in both atyfb_base.c and atyfb.h, but then there is a build error in
> mach64_ct.c when PPC_PMAC is not enabled but FB_ATY_GENERIC_LCD is enabled.
> [mach64_ct.c is the only other user of aty_{ld,st}_lcd()]
>
> or did you mean adding CONFIG_PPC_PMAC to that longish #if list?
> (that's not how I understood your comment.)
Yeah, I meant adding ||PPC_PMAC to the existing set of conditions.
You definitely need to have this stuff for the LCD/backlight
support on !PPC_PMAC as well.
>
>
> I'll gladly step away and let you submit patches for this. :)
I don't have any powerbook/etc. hw to test this so couldn't
really add any extra value. Just have vague memories of touching
this stuff long ago so figured I'd provide my "expertise" :)
>
> >> +void aty_st_lcd(int index, u32 val, const struct atyfb_par *par)
> >> +{ }
> >> +
> >> +u32 aty_ld_lcd(int index, const struct atyfb_par *par)
> >> +{
> >> + return 0;
> >> +}
> >> #endif /* defined(CONFIG_PMAC_BACKLIGHT) || defined
> >> (CONFIG_FB_ATY_GENERIC_LCD) */
> >>
> >> #ifdef CONFIG_FB_ATY_GENERIC_LCD
> >> ___
>
>
> thanks.
> --
> ~Randy
--
Ville Syrjälä
Intel
Re: [PATCH] fbdev: atyfb: add stubs for aty_{ld,st}_lcd()
On Sun, Feb 21, 2021 at 07:28:53PM -0800, Randy Dunlap wrote:
> Fix build errors when these functions are not defined.
>
> ../drivers/video/fbdev/aty/atyfb_base.c: In function 'aty_power_mgmt':
> ../drivers/video/fbdev/aty/atyfb_base.c:2002:7: error: implicit declaration
> of function 'aty_ld_lcd'; did you mean 'aty_ld_8'?
> [-Werror=implicit-function-declaration]
> 2002 | pm = aty_ld_lcd(POWER_MANAGEMENT, par);
> ../drivers/video/fbdev/aty/atyfb_base.c:2004:2: error: implicit declaration
> of function 'aty_st_lcd'; did you mean 'aty_st_8'?
> [-Werror=implicit-function-declaration]
> 2004 | aty_st_lcd(POWER_MANAGEMENT, pm, par);
> Signed-off-by: Randy Dunlap
> Reported-by: kernel test robot
> Cc: linux-fb...@vger.kernel.org
> Cc: dri-de...@lists.freedesktop.org
> Cc: Bartlomiej Zolnierkiewicz
> Cc: Sam Ravnborg
> Cc: Daniel Vetter
> Cc: David Airlie
> Cc: Jani Nikula
> ---
> drivers/video/fbdev/aty/atyfb_base.c |9 +
> 1 file changed, 9 insertions(+)
>
> --- linux-next-20210219.orig/drivers/video/fbdev/aty/atyfb_base.c
> +++ linux-next-20210219/drivers/video/fbdev/aty/atyfb_base.c
> @@ -175,6 +175,15 @@ u32 aty_ld_lcd(int index, const struct a
> return aty_ld_le32(LCD_DATA, par);
> }
> }
> +#else /* defined(CONFIG_PMAC_BACKLIGHT) || defined(CONFIG_FB_ATY_BACKLIGHT) \
> + defined(CONFIG_FB_ATY_GENERIC_LCD) */
A better fix would seem to be to include these functions if
CONFIG_PPC_PMAC is enabled. Otherwise the PM code will surely
not work correctly. Though I'm not sure if that PPC PM
code makes any sense w/o LCD/backlight support anyway.
> +void aty_st_lcd(int index, u32 val, const struct atyfb_par *par)
> +{ }
> +
> +u32 aty_ld_lcd(int index, const struct atyfb_par *par)
> +{
> + return 0;
> +}
> #endif /* defined(CONFIG_PMAC_BACKLIGHT) || defined
> (CONFIG_FB_ATY_GENERIC_LCD) */
>
> #ifdef CONFIG_FB_ATY_GENERIC_LCD
> _______
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [RFC v4 10/11] drm/dp: Extract i915's eDP backlight code into DRM helpers
On Thu, Feb 18, 2021 at 10:35:05AM +0200, Jani Nikula wrote: > On Fri, 12 Feb 2021, Lyude Paul wrote: > > I think it wouldn't be a bad idea to just address this with a followup > > series > > instead and use the old DRM_DEBUG_* macros in the mean time. > > aux->dev is there, could also use dev_dbg et al. in the mean time. They > handle NULL dev gracefully too if the driver didn't set that. Last I looked aux->dev was random. Some drivers point it at the connector vs. some at the the pci/platform device. -- Ville Syrjälä Intel
Re: [PATCH] drm/i915: Remove unused function pointer typedef long_pulse_detect_func
On Mon, Feb 15, 2021 at 07:30:19PM +0800, Chen Lin wrote: > From: Chen Lin > > Remove the 'long_pulse_detect_func' typedef as it is not used. > > Signed-off-by: Chen Lin > --- > drivers/gpu/drm/i915/i915_irq.c |1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c > index 6cdb052..c294ac6 100644 > --- a/drivers/gpu/drm/i915/i915_irq.c > +++ b/drivers/gpu/drm/i915/i915_irq.c > @@ -78,7 +78,6 @@ static inline void pmu_irq_stats(struct drm_i915_private > *i915, > WRITE_ONCE(i915->pmu.irq_count, i915->pmu.irq_count + 1); > } > > -typedef bool (*long_pulse_detect_func)(enum hpd_pin pin, u32 val); > typedef u32 (*hotplug_enables_func)(struct drm_i915_private *i915, > enum hpd_pin pin); I thought we used in when passing it as an argument to intel_get_hpd_pins(), but looks like that's not the case. I guess we should unify this stuff by either removing both these typedefs and adjusting intel_hpd_hotplug_enables() accordingly, or we should use the typedef in intel_get_hpd_pins() as well. -- Ville Syrjälä Intel
Re: [PATCH v3 2/4] drm_dp_mst_topology: use correct AUX channel
On Fri, Feb 05, 2021 at 04:17:51PM +1100, Sam McNally wrote:
> On Thu, 4 Feb 2021 at 21:19, Hans Verkuil wrote:
> >
> > On 01/02/2021 23:13, Ville Syrjälä wrote:
> > > On Wed, Sep 23, 2020 at 12:13:53PM +1000, Sam McNally wrote:
> > >> From: Hans Verkuil
> > >>
> > >> For adapters behind an MST hub use the correct AUX channel.
> > >>
> > >> Signed-off-by: Hans Verkuil
> > >> [sa...@chromium.org: rebased, removing redundant changes]
> > >> Signed-off-by: Sam McNally
> > >> ---
> > >>
> > >> (no changes since v1)
> > >>
> > >> drivers/gpu/drm/drm_dp_mst_topology.c | 36 +++
> > >> 1 file changed, 36 insertions(+)
> > >>
> > >> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > >> b/drivers/gpu/drm/drm_dp_mst_topology.c
> > >> index 15b6cc39a754..0d753201adbd 100644
> > >> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > >> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > >> @@ -2255,6 +2255,9 @@ drm_dp_mst_topology_unlink_port(struct
> > >> drm_dp_mst_topology_mgr *mgr,
> > >> drm_dp_mst_topology_put_port(port);
> > >> }
> > >>
> > >> +static ssize_t
> > >> +drm_dp_mst_aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg
> > >> *msg);
> > >> +
> > >> static struct drm_dp_mst_port *
> > >> drm_dp_mst_add_port(struct drm_device *dev,
> > >> struct drm_dp_mst_topology_mgr *mgr,
> > >> @@ -2271,9 +2274,13 @@ drm_dp_mst_add_port(struct drm_device *dev,
> > >> port->port_num = port_number;
> > >> port->mgr = mgr;
> > >> port->aux.name = "DPMST";
> > >> +mutex_init(>aux.hw_mutex);
> > >> +mutex_init(>aux.cec.lock);
> > >> port->aux.dev = dev->dev;
> > >> port->aux.is_remote = true;
> > >>
> > >> +port->aux.transfer = drm_dp_mst_aux_transfer;
> > >> +
> > >
> > > This was supposed to be handled via higher levels checking for
> > > is_remote==true.
> >
> > Ah, I suspect this patch can be dropped entirely: it predates commit
> > 2f221a5efed4
> > ("drm/dp_mst: Add MST support to DP DPCD R/W functions").
> >
> > It looks like that commit basically solved what this older patch attempts
> > to do
> > as well.
> >
> > Sam, can you test if it works without this patch?
>
> It almost just works; drm_dp_cec uses whether aux.transfer is non-null
> to filter out non-DP connectors. Using aux.is_remote as another signal
> indicating a DP connector seems plausible. We can drop this patch.
Why would anyone even call this stuff on a non-DP connector?
And where did they even get the struct drm_dp_aux to do so?
> Thanks all!
> >
> > Regards,
> >
> > Hans
> >
> > >
> > >> /* initialize the MST downstream port's AUX crc work queue */
> > >> drm_dp_remote_aux_init(>aux);
> > >>
> > >> @@ -3503,6 +3510,35 @@ static int drm_dp_send_up_ack_reply(struct
> > >> drm_dp_mst_topology_mgr *mgr,
> > >> return 0;
> > >> }
> > >>
> > >> +static ssize_t
> > >> +drm_dp_mst_aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg
> > >> *msg)
> > >> +{
> > >> +struct drm_dp_mst_port *port =
> > >> +container_of(aux, struct drm_dp_mst_port, aux);
> > >> +int ret;
> > >> +
> > >> +switch (msg->request & ~DP_AUX_I2C_MOT) {
> > >> +case DP_AUX_NATIVE_WRITE:
> > >> +case DP_AUX_I2C_WRITE:
> > >> +case DP_AUX_I2C_WRITE_STATUS_UPDATE:
> > >> +ret = drm_dp_send_dpcd_write(port->mgr, port, msg->address,
> > >> + msg->size, msg->buffer);
> > >
> > > That doesn't make sense to me. I2c writes and DPCD writes
> > > are definitely not the same thing.
> > >
> > > aux->transfer is a very low level thing. I don't think it's the
> > > correct level of abstraction for sideband.
> > >
> > >> +break;
> > >> +
> > >> +case DP_AUX_NATIVE_READ:
> > >> +case DP_AUX_I2C_READ:
> > >> +ret = drm_dp_send_dpcd_read(port->mgr, port, msg->address,
> > >> +msg->size, msg->buffer);
> > >> +break;
> > >> +
> > >> +default:
> > >> +ret = -EINVAL;
> > >> +break;
> > >> +}
> > >> +
> > >> +return ret;
> > >> +}
> > >> +
> > >> static int drm_dp_get_vc_payload_bw(u8 dp_link_bw, u8 dp_link_count)
> > >> {
> > >> if (dp_link_bw == 0 || dp_link_count == 0)
> > >> --
> > >> 2.28.0.681.g6f77f65b4e-goog
> > >>
> > >> ___
> > >> dri-devel mailing list
> > >> dri-de...@lists.freedesktop.org
> > >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > >
> >
--
Ville Syrjälä
Intel
Re: [PATCH v3 2/4] drm_dp_mst_topology: use correct AUX channel
On Fri, Feb 05, 2021 at 02:46:44PM +0100, Hans Verkuil wrote:
> On 05/02/2021 14:24, Ville Syrjälä wrote:
> > On Fri, Feb 05, 2021 at 04:17:51PM +1100, Sam McNally wrote:
> >> On Thu, 4 Feb 2021 at 21:19, Hans Verkuil wrote:
> >>>
> >>> On 01/02/2021 23:13, Ville Syrjälä wrote:
> >>>> On Wed, Sep 23, 2020 at 12:13:53PM +1000, Sam McNally wrote:
> >>>>> From: Hans Verkuil
> >>>>>
> >>>>> For adapters behind an MST hub use the correct AUX channel.
> >>>>>
> >>>>> Signed-off-by: Hans Verkuil
> >>>>> [sa...@chromium.org: rebased, removing redundant changes]
> >>>>> Signed-off-by: Sam McNally
> >>>>> ---
> >>>>>
> >>>>> (no changes since v1)
> >>>>>
> >>>>> drivers/gpu/drm/drm_dp_mst_topology.c | 36 +++
> >>>>> 1 file changed, 36 insertions(+)
> >>>>>
> >>>>> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> >>>>> b/drivers/gpu/drm/drm_dp_mst_topology.c
> >>>>> index 15b6cc39a754..0d753201adbd 100644
> >>>>> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> >>>>> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> >>>>> @@ -2255,6 +2255,9 @@ drm_dp_mst_topology_unlink_port(struct
> >>>>> drm_dp_mst_topology_mgr *mgr,
> >>>>> drm_dp_mst_topology_put_port(port);
> >>>>> }
> >>>>>
> >>>>> +static ssize_t
> >>>>> +drm_dp_mst_aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg
> >>>>> *msg);
> >>>>> +
> >>>>> static struct drm_dp_mst_port *
> >>>>> drm_dp_mst_add_port(struct drm_device *dev,
> >>>>> struct drm_dp_mst_topology_mgr *mgr,
> >>>>> @@ -2271,9 +2274,13 @@ drm_dp_mst_add_port(struct drm_device *dev,
> >>>>> port->port_num = port_number;
> >>>>> port->mgr = mgr;
> >>>>> port->aux.name = "DPMST";
> >>>>> +mutex_init(>aux.hw_mutex);
> >>>>> +mutex_init(>aux.cec.lock);
> >>>>> port->aux.dev = dev->dev;
> >>>>> port->aux.is_remote = true;
> >>>>>
> >>>>> +port->aux.transfer = drm_dp_mst_aux_transfer;
> >>>>> +
> >>>>
> >>>> This was supposed to be handled via higher levels checking for
> >>>> is_remote==true.
> >>>
> >>> Ah, I suspect this patch can be dropped entirely: it predates commit
> >>> 2f221a5efed4
> >>> ("drm/dp_mst: Add MST support to DP DPCD R/W functions").
> >>>
> >>> It looks like that commit basically solved what this older patch attempts
> >>> to do
> >>> as well.
> >>>
> >>> Sam, can you test if it works without this patch?
> >>
> >> It almost just works; drm_dp_cec uses whether aux.transfer is non-null
> >> to filter out non-DP connectors. Using aux.is_remote as another signal
> >> indicating a DP connector seems plausible. We can drop this patch.
> >
> > Why would anyone even call this stuff on a non-DP connector?
> > And where did they even get the struct drm_dp_aux to do so?
>
> This check came in with commit 5ce70c799ac2 ("drm_dp_cec: check that aux
> has a transfer function"). It seems nouveau and amdgpu specific.
I see.
>
> A better approach would be to fix those drivers to only call these cec
> functions for DP outputs. I think I moved the test to drm_dp_cec.c primarily
> for robustness (i.e. do nothing if called for a non-DP output). But that
> might not be the right approach after all.
Shrug. I guess just extending to check is_remote (or maybe there is
some other member that's always set?) is a good enough short term
solution. Someone may want to have a look at adjusting
amdgpu/nouveau to not need it, but who knows how much work that is.
--
Ville Syrjälä
Intel
Re: [PATCH] drm: Fix drm_atomic_get_new_crtc_state call error
On Mon, Feb 01, 2021 at 05:33:44PM +0800, Zhaoge Zhang wrote:
> This position is to clear the previous mask flags,
> so drm_atomic_get_crtc_state should be used.
>
> Signed-off-by: Zhaoge Zhang
> ---
> drivers/gpu/drm/drm_atomic_uapi.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index 268bb69..07fe01b 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -313,8 +313,8 @@ drm_atomic_set_crtc_for_connector(struct
> drm_connector_state *conn_state,
> return 0;
>
> if (conn_state->crtc) {
> - crtc_state = drm_atomic_get_new_crtc_state(conn_state->state,
> -conn_state->crtc);
> + crtc_state = drm_atomic_get_crtc_state(conn_state->state,
> + conn_state->crtc);
drm_atomic_get_new_crtc_state() should be fine here since
drm_atomic_get_connector_state() will have added the old
crtc to the state already.
>
> crtc_state->connector_mask &=
> ~drm_connector_mask(conn_state->connector);
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
Re: [PATCH v3 2/4] drm_dp_mst_topology: use correct AUX channel
On Wed, Sep 23, 2020 at 12:13:53PM +1000, Sam McNally wrote:
> From: Hans Verkuil
>
> For adapters behind an MST hub use the correct AUX channel.
>
> Signed-off-by: Hans Verkuil
> [sa...@chromium.org: rebased, removing redundant changes]
> Signed-off-by: Sam McNally
> ---
>
> (no changes since v1)
>
> drivers/gpu/drm/drm_dp_mst_topology.c | 36 +++
> 1 file changed, 36 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 15b6cc39a754..0d753201adbd 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -2255,6 +2255,9 @@ drm_dp_mst_topology_unlink_port(struct
> drm_dp_mst_topology_mgr *mgr,
> drm_dp_mst_topology_put_port(port);
> }
>
> +static ssize_t
> +drm_dp_mst_aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg);
> +
> static struct drm_dp_mst_port *
> drm_dp_mst_add_port(struct drm_device *dev,
> struct drm_dp_mst_topology_mgr *mgr,
> @@ -2271,9 +2274,13 @@ drm_dp_mst_add_port(struct drm_device *dev,
> port->port_num = port_number;
> port->mgr = mgr;
> port->aux.name = "DPMST";
> + mutex_init(>aux.hw_mutex);
> + mutex_init(>aux.cec.lock);
> port->aux.dev = dev->dev;
> port->aux.is_remote = true;
>
> + port->aux.transfer = drm_dp_mst_aux_transfer;
> +
This was supposed to be handled via higher levels checking for
is_remote==true.
> /* initialize the MST downstream port's AUX crc work queue */
> drm_dp_remote_aux_init(>aux);
>
> @@ -3503,6 +3510,35 @@ static int drm_dp_send_up_ack_reply(struct
> drm_dp_mst_topology_mgr *mgr,
> return 0;
> }
>
> +static ssize_t
> +drm_dp_mst_aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg)
> +{
> + struct drm_dp_mst_port *port =
> + container_of(aux, struct drm_dp_mst_port, aux);
> + int ret;
> +
> + switch (msg->request & ~DP_AUX_I2C_MOT) {
> + case DP_AUX_NATIVE_WRITE:
> + case DP_AUX_I2C_WRITE:
> + case DP_AUX_I2C_WRITE_STATUS_UPDATE:
> + ret = drm_dp_send_dpcd_write(port->mgr, port, msg->address,
> + msg->size, msg->buffer);
That doesn't make sense to me. I2c writes and DPCD writes
are definitely not the same thing.
aux->transfer is a very low level thing. I don't think it's the
correct level of abstraction for sideband.
> + break;
> +
> + case DP_AUX_NATIVE_READ:
> + case DP_AUX_I2C_READ:
> + ret = drm_dp_send_dpcd_read(port->mgr, port, msg->address,
> + msg->size, msg->buffer);
> + break;
> +
> + default:
> + ret = -EINVAL;
> + break;
> + }
> +
> + return ret;
> +}
> +
> static int drm_dp_get_vc_payload_bw(u8 dp_link_bw, u8 dp_link_count)
> {
> if (dp_link_bw == 0 || dp_link_count == 0)
> --
> 2.28.0.681.g6f77f65b4e-goog
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
Re: regression in drm_blank.c?
On Thu, Jan 28, 2021 at 11:12:50AM -0600, Steve French wrote:
> For the last month my logs have been flooded many times a second with:
>
> "nouveau :01:00.0: [drm] *ERROR* crtc 50: Can't calculate
> constants, dotclock = 0!"
Would indicate someone has a bogus adjusted_mode in their state struct.
Assuming this is one of those atomic nouveaus of course. No idea what
goes on with any of the older(?) stuff.
Sadly it's an error and not a WARN so we don't get a backtrace to
see who is calling it.
The only related changes around the atomic helpers I remember were
commit 441959ebc905 ("drm/atomic-helper: Remove the timestamping constant
update from drm_atomic_helper_update_legacy_modeset_state()")
commit 4b31a9c77bf8 ("drm/atomic-helper: Extract
drm_atomic_helper_calc_timestamping_constants()")
but those should be a nop for nouveau.
So no idea really. I'd suggest changing it to a WARN to see where it's
coming from and then adding more debugs to figure out why the mode
is garbage.
>
> (see line 641 of drm_vblank.c) which is distracting for debugging all
> other kernel problems (since dmesg entries on this system are 99+%
> this message).
>
> Am running current kernel ie 5.11-rc5 (although it also was very very
> noisty in 5.10), Ubuntu mainline kernel builds, Lenovo P52 Thinkpad
> laptop. Could it be due to one of the more recent changes to
> drivers/gpu/drm/drm_vblank.c?
>
> Ideas how to workaround this?
>
> --
> Thanks,
>
> Steve
--
Ville Syrjälä
Intel
Re: [PATCH v2 08/11] drm: Rename plane->state variables in atomic update and disable
On Mon, Jan 25, 2021 at 11:52:18AM +0100, Maxime Ripard wrote:
> Hi Ville,
>
> On Fri, Jan 22, 2021 at 02:15:07PM +0200, Ville Syrjälä wrote:
> > On Thu, Jan 21, 2021 at 05:35:33PM +0100, Maxime Ripard wrote:
> > > Some drivers are storing the plane->state pointer in atomic_update and
> > > atomic_disable in a variable simply called state, while the state passed
> > > as an argument is called old_state.
> > >
> > > In order to ease subsequent reworks and to avoid confusing or
> > > inconsistent names, let's rename those variables to new_state.
> > >
> > > This was done using the following coccinelle script, plus some manual
> > > changes for mtk and tegra.
> > >
> > > @ plane_atomic_func @
> > > identifier helpers;
> > > identifier func;
> > > @@
> > >
> > > (
> > > static const struct drm_plane_helper_funcs helpers = {
> > > ...,
> > > .atomic_disable = func,
> > > ...,
> > > };
> > > |
> > > static const struct drm_plane_helper_funcs helpers = {
> > > ...,
> > > .atomic_update = func,
> > > ...,
> > > };
> > > )
> > >
> > > @ moves_new_state_old_state @
> > > identifier plane_atomic_func.func;
> > > identifier plane;
> > > symbol old_state;
> > > symbol state;
> > > @@
> > >
> > > func(struct drm_plane *plane, struct drm_plane_state *old_state)
> > > {
> > > ...
> > > - struct drm_plane_state *state = plane->state;
> > > + struct drm_plane_state *new_state = plane->state;
> > > ...
> > > }
> > >
> > > @ depends on moves_new_state_old_state @
> > > identifier plane_atomic_func.func;
> > > identifier plane;
> > > identifier old_state;
> > > symbol state;
> > > @@
> > >
> > > func(struct drm_plane *plane, struct drm_plane_state *old_state)
> > > {
> > > <...
> > > - state
> > > + new_state
> > > ...>
> >
> > Was going to say that this migh eat something else, but I guess
> > the dependency prevents that?
>
> Yeah, the dependency takes care of this
>
> > Another way to avoid that I suppose would be to declare 'state'
> > as
> > symbol moves_new_state_old_state.state;
> >
> > That would probably make the intent a bit more obvious, even with
> > the dependency. Or does a dependency somehow automagically imply
> > that?
>
> I'm not sure if it does, but it's a symbol here not an identifier or an
> expression, so here moves_new_state_old_state.state would always resolve
> to state (and only state) anyway
Hm. Right. OK, cocci bits look good to me. Variable naming
bikeshed I'll leave to others :)
Reviewed-by: Ville Syrjälä
--
Ville Syrjälä
Intel
Re: [PATCH v2 10/11] drm: Use state helper instead of the plane state pointer
On Thu, Jan 21, 2021 at 05:35:35PM +0100, Maxime Ripard wrote:
> Many drivers reference the plane->state pointer in order to get the
> current plane state in their atomic_update or atomic_disable hooks,
> which would be the new plane state in the global atomic state since
> _swap_state happened when those hooks are run.
>
> Use the drm_atomic_get_new_plane_state helper to get that state to make it
> more obvious.
>
> This was made using the coccinelle script below:
>
> @ plane_atomic_func @
> identifier helpers;
> identifier func;
> @@
>
> (
> static const struct drm_plane_helper_funcs helpers = {
> ...,
> .atomic_disable = func,
> ...,
> };
> |
> static const struct drm_plane_helper_funcs helpers = {
> ...,
> .atomic_update = func,
> ...,
> };
> )
>
> @ adds_new_state @
> identifier plane_atomic_func.func;
> identifier plane, state;
> identifier new_state;
> @@
>
> func(struct drm_plane *plane, struct drm_atomic_state *state)
> {
> ...
> - struct drm_plane_state *new_state = plane->state;
> + struct drm_plane_state *new_state =
> drm_atomic_get_new_plane_state(state, plane);
> ...
> }
>
> @ include depends on adds_new_state @
> @@
>
> #include
>
> @ no_include depends on !include && adds_new_state @
> @@
>
> + #include
> #include
>
> Signed-off-by: Maxime Ripard
Looks great.
Reviewed-by: Ville Syrjälä
--
Ville Syrjälä
Intel
Re: [PATCH 2/2] drm/dp_mst: Align mst link rate with soure rate
On Wed, Jan 13, 2021 at 01:51:00PM +0200, Jani Nikula wrote:
> On Wed, 13 Jan 2021, Koba Ko wrote:
> > After read the link rate from MST hub, align with
> > maximum source rate.
> >
> > Signed-off-by: Koba Ko
> > ---
> > drivers/gpu/drm/drm_dp_mst_topology.c | 8
> > drivers/gpu/drm/i915/display/intel_dp.c | 7 +++
> > include/drm/drm_dp_helper.h | 8
> > include/drm/drm_dp_mst_helper.h | 4
> > 4 files changed, 27 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index 6982ecbf30b5..e7ceae97be85 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -3672,6 +3672,10 @@ int drm_dp_mst_topology_mgr_set_mst(struct
> > drm_dp_mst_topology_mgr *mgr, bool ms
> > {
> > int ret = 0;
> > struct drm_dp_mst_branch *mstb = NULL;
> > + unsigned int max_link_rate_tbl[MAX_DRM_DP_MAX_RATE + 1] = {
> > + DP_LINK_BW_1_62, DP_LINK_BW_2_7, DP_LINK_BW_5_4,
> > + DP_LINK_BW_8_1, DP_LINK_RATE_TABLE
> > + };
>
> Please no. Read on for why.
>
> >
> > mutex_lock(>payload_lock);
> > mutex_lock(>lock);
> > @@ -3693,6 +3697,9 @@ int drm_dp_mst_topology_mgr_set_mst(struct
> > drm_dp_mst_topology_mgr *mgr, bool ms
> > goto out_unlock;
> > }
> >
> > + if (mgr->max_source_rate < MAX_DRM_DP_MAX_RATE)
> > + mgr->dpcd[1] = max_link_rate_tbl[mgr->max_source_rate];
>
> Make ->max_source_rate the actual physical rate in kHz, and use
> drm_dp_link_rate_to_bw_code() here.
>
> > +
> > mgr->pbn_div = drm_dp_get_vc_payload_bw(mgr->dpcd[1],
> > mgr->dpcd[2] &
> > DP_MAX_LANE_COUNT_MASK);
> > if (mgr->pbn_div == 0) {
> > @@ -5422,6 +5429,7 @@ int drm_dp_mst_topology_mgr_init(struct
> > drm_dp_mst_topology_mgr *mgr,
> > mgr->aux = aux;
> > mgr->max_dpcd_transaction_bytes = max_dpcd_transaction_bytes;
> > mgr->max_payloads = max_payloads;
> > + mgr->max_source_rate = MAX_DRM_DP_MAX_RATE;
> > mgr->conn_base_id = conn_base_id;
> > if (max_payloads + 1 > sizeof(mgr->payload_mask) * 8 ||
> > max_payloads + 1 > sizeof(mgr->vcpi_mask) * 8)
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 469e765a1b7b..a89b4c823123 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -5392,6 +5392,13 @@ intel_dp_configure_mst(struct intel_dp *intel_dp)
> > intel_dp->is_mst = sink_can_mst &&
> > i915->params.enable_dp_mst;
> >
> > + if (intel_dp_source_supports_hbr3(intel_dp))
> > + intel_dp->mst_mgr.max_source_rate = DRM_DP_MAX_RATE_HBR3;
> > + else if (intel_dp_source_supports_hbr2(intel_dp))
> > + intel_dp->mst_mgr.max_source_rate = DRM_DP_MAX_RATE_HBR2;
> > + else
> > + intel_dp->mst_mgr.max_source_rate = DRM_DP_MAX_RATE_HBR;
>
> Whenever this file references a "rate", it's the rate in kHz. This is
> confusing. Use the rate in kHz.
>
> Also, please look at how intel_dp_source_supports_hbr* are implemented;
> we already have all the supported source rates cached in intel_dp.
>
> The max source rate is:
>
> intel_dp->source_rates[intel_dp->num_source_rates - 1].
>
> No need to do the if ladder here at all. If you like, you can add a
> helper:
>
> int intel_dp_max_source_rate(struct intel_dp *intel_dp)
> {
> return intel_dp->source_rates[intel_dp->num_source_rates - 1];
> }
Using the max source rate isn't super great either. A bit better
than the current mess though.
The correct fix would be to let the driver provide the actually
used link_rate+lane_count to the MST code during atomic_check(),
instead of trying to guess what the driver is going to use.
--
Ville Syrjälä
Intel
Re: [PATCH v2 06/11] drm: Use state helper instead of plane state pointer in atomic_check
On Thu, Jan 21, 2021 at 05:35:31PM +0100, Maxime Ripard wrote:
> Many drivers reference the plane->state pointer in order to get the
> current plane state in their atomic_check hook, which would be the old
> plane state in the global atomic state since _swap_state hasn't happened
> when atomic_check is run.
>
> Use the drm_atomic_get_old_plane_state helper to get that state to make
> it more obvious.
>
> This was made using the coccinelle script below:
>
> @ plane_atomic_func @
> identifier helpers;
> identifier func;
> @@
>
> static struct drm_plane_helper_funcs helpers = {
> ...,
> .atomic_check = func,
> ...,
> };
>
> @ replaces_old_state @
> identifier plane_atomic_func.func;
> identifier plane, state, plane_state;
> @@
>
> func(struct drm_plane *plane, struct drm_atomic_state *state) {
> ...
> - struct drm_plane_state *plane_state = plane->state;
> + struct drm_plane_state *plane_state =
> drm_atomic_get_old_plane_state(state, plane);
> ...
> }
>
> @@
> identifier plane_atomic_func.func;
> identifier plane, state, plane_state;
> @@
>
> func(struct drm_plane *plane, struct drm_atomic_state *state) {
> struct drm_plane_state *plane_state =
> drm_atomic_get_old_plane_state(state, plane);
> ...
> - plane->state
> + plane_state
> ...
We don't need the <... ...> style here? It's been a while since
I did any serious cocci so I'm getting a bit rusty on the details...
Otherwise looks great
Reviewed-by: Ville Syrjälä
> }
>
> @ adds_old_state @
> identifier plane_atomic_func.func;
> identifier plane, state;
> @@
>
> func(struct drm_plane *plane, struct drm_atomic_state *state) {
> + struct drm_plane_state *old_plane_state =
> drm_atomic_get_old_plane_state(state, plane);
> ...
> - plane->state
> + old_plane_state
> ...
> }
>
> @ include depends on adds_old_state || replaces_old_state @
> @@
>
> #include
>
> @ no_include depends on !include && (adds_old_state || replaces_old_state) @
> @@
>
> + #include
> #include
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/imx/ipuv3-plane.c | 3 ++-
> drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c | 4 +++-
> drivers/gpu/drm/tilcdc/tilcdc_plane.c | 3 ++-
> 3 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c
> b/drivers/gpu/drm/imx/ipuv3-plane.c
> index b5f6123850bb..6484592e3f86 100644
> --- a/drivers/gpu/drm/imx/ipuv3-plane.c
> +++ b/drivers/gpu/drm/imx/ipuv3-plane.c
> @@ -341,7 +341,8 @@ static int ipu_plane_atomic_check(struct drm_plane *plane,
> {
> struct drm_plane_state *new_state =
> drm_atomic_get_new_plane_state(state,
>
> plane);
> - struct drm_plane_state *old_state = plane->state;
> + struct drm_plane_state *old_state =
> drm_atomic_get_old_plane_state(state,
> +
> plane);
> struct drm_crtc_state *crtc_state;
> struct device *dev = plane->dev->dev;
> struct drm_framebuffer *fb = new_state->fb;
> diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
> b/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
> index 4aac6217a5ad..6ce6ce09fecc 100644
> --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
> +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
> @@ -406,12 +406,14 @@ static int mdp5_plane_atomic_check_with_state(struct
> drm_crtc_state *crtc_state,
> static int mdp5_plane_atomic_check(struct drm_plane *plane,
> struct drm_atomic_state *state)
> {
> + struct drm_plane_state *old_plane_state =
> drm_atomic_get_old_plane_state(state,
> +
> plane);
> struct drm_plane_state *new_plane_state =
> drm_atomic_get_new_plane_state(state,
>
> plane);
> struct drm_crtc *crtc;
> struct drm_crtc_state *crtc_state;
>
> - crtc = new_plane_state->crtc ? new_plane_state->crtc :
> plane->state->crtc;
> + crtc = new_plane_state->crtc ? new_plane_state->crtc :
> old_plane_state->crtc;
> if (!crtc)
> return 0;
>
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_plane.c
> b/drivers/gpu/drm/tilcdc/tilcdc_plane.c
> index ebdd42dcaf82..c86258132432 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_plane.c
> +++ b/drivers/gpu/drm/tilcdc/
Re: [PATCH 1/3] drivers/nouveau/kms/nv50-: Reject format modifiers for cursor planes
On Mon, Jan 18, 2021 at 08:54:12PM -0500, Lyude Paul wrote:
> Nvidia hardware doesn't actually support using tiling formats with the
> cursor plane, only linear is allowed. In the future, we should write a
> testcase for this.
There are a couple of old modifier/format sanity tests here:
https://patchwork.freedesktop.org/series/46876/
Couple of things missing that now came to my mind:
- test setplane/etc. rejects unsupported formats/modifiers even if
addfb allowed them, exactly for the case where only a subset of
planes support something
- validate the IN_FORMATS blob harder, eg. make sure each modifier
listed there supports at least one format. IIRC this was busted on
a few drivers last year, dunno if they got fixed or not. Hmm,
actually since this is now using the pre-parsed stuff I guess we
should just stick an assert into igt_fill_plane_format_mod() where
the blob gets parsed
>
> Fixes: c586f30bf74c ("drm/nouveau/kms: Add format mod prop to
> base/ovly/nvdisp")
> Cc: James Jones
> Cc: Martin Peres
> Cc: Jeremy Cline
> Cc: Simon Ser
> Cc: # v5.8+
> Signed-off-by: Lyude Paul
> ---
> drivers/gpu/drm/nouveau/dispnv50/wndw.c | 17 +
> 1 file changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/wndw.c
> b/drivers/gpu/drm/nouveau/dispnv50/wndw.c
> index ce451242f79e..271de3a63f21 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/wndw.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/wndw.c
> @@ -702,6 +702,11 @@ nv50_wndw_init(struct nv50_wndw *wndw)
> nvif_notify_get(>notify);
> }
>
> +static const u64 nv50_cursor_format_modifiers[] = {
> + DRM_FORMAT_MOD_LINEAR,
> + DRM_FORMAT_MOD_INVALID,
> +};
> +
> int
> nv50_wndw_new_(const struct nv50_wndw_func *func, struct drm_device *dev,
> enum drm_plane_type type, const char *name, int index,
> @@ -713,6 +718,7 @@ nv50_wndw_new_(const struct nv50_wndw_func *func, struct
> drm_device *dev,
> struct nvif_mmu *mmu = >client.mmu;
> struct nv50_disp *disp = nv50_disp(dev);
> struct nv50_wndw *wndw;
> + const u64 *format_modifiers;
> int nformat;
> int ret;
>
> @@ -728,10 +734,13 @@ nv50_wndw_new_(const struct nv50_wndw_func *func,
> struct drm_device *dev,
>
> for (nformat = 0; format[nformat]; nformat++);
>
> - ret = drm_universal_plane_init(dev, >plane, heads, _wndw,
> -format, nformat,
> -nouveau_display(dev)->format_modifiers,
> -type, "%s-%d", name, index);
> + if (type == DRM_PLANE_TYPE_CURSOR)
> + format_modifiers = nv50_cursor_format_modifiers;
> + else
> + format_modifiers = nouveau_display(dev)->format_modifiers;
> +
> + ret = drm_universal_plane_init(dev, >plane, heads, _wndw,
> format, nformat,
> +format_modifiers, type, "%s-%d", name,
> index);
> if (ret) {
> kfree(*pwndw);
> *pwndw = NULL;
> --
> 2.29.2
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
Re: [RFC PATCH 1/2] drm: RFC add choice to use dynamic debug in drm-debug
16,7 @@ void drm_dev_dbg(const struct device *dev, enum > drm_debug_category category, > */ > > __printf(2, 3) > -void __drm_dbg(enum drm_debug_category category, const char *format, ...); > +void ___drm_dbg(enum drm_debug_category category, const char *format, ...); > __printf(1, 2) > void __drm_err(const char *format, ...); > > @@ -500,29 +545,30 @@ void __drm_err(const char *format, ...); > #define DRM_ERROR_RATELIMITED(fmt, ...) > \ > DRM_DEV_ERROR_RATELIMITED(NULL, fmt, ##__VA_ARGS__) > > + > #define DRM_DEBUG(fmt, ...) \ > - __drm_dbg(DRM_UT_CORE, fmt, ##__VA_ARGS__) > + __drm_dbg(cDRM_UT_CORE, fmt, ##__VA_ARGS__) > > #define DRM_DEBUG_DRIVER(fmt, ...) \ > - __drm_dbg(DRM_UT_DRIVER, fmt, ##__VA_ARGS__) > + __drm_dbg(cDRM_UT_DRIVER, fmt, ##__VA_ARGS__) > > #define DRM_DEBUG_KMS(fmt, ...) > \ > - __drm_dbg(DRM_UT_KMS, fmt, ##__VA_ARGS__) > + __drm_dbg(cDRM_UT_KMS, fmt, ##__VA_ARGS__) > > #define DRM_DEBUG_PRIME(fmt, ...)\ > - __drm_dbg(DRM_UT_PRIME, fmt, ##__VA_ARGS__) > + __drm_dbg(cDRM_UT_PRIME, fmt, ##__VA_ARGS__) > > #define DRM_DEBUG_ATOMIC(fmt, ...) \ > - __drm_dbg(DRM_UT_ATOMIC, fmt, ##__VA_ARGS__) > + __drm_dbg(cDRM_UT_ATOMIC, fmt, ##__VA_ARGS__) > > #define DRM_DEBUG_VBL(fmt, ...) > \ > - __drm_dbg(DRM_UT_VBL, fmt, ##__VA_ARGS__) > + __drm_dbg(cDRM_UT_VBL, fmt, ##__VA_ARGS__) > > #define DRM_DEBUG_LEASE(fmt, ...)\ > - __drm_dbg(DRM_UT_LEASE, fmt, ##__VA_ARGS__) > + __drm_dbg(cDRM_UT_LEASE, fmt, ##__VA_ARGS__) > > #define DRM_DEBUG_DP(fmt, ...) > \ > - __drm_dbg(DRM_UT_DP, fmt, ## __VA_ARGS__) > + __drm_dbg(cDRM_UT_DP, fmt, ## __VA_ARGS__) > > > #define DRM_DEBUG_KMS_RATELIMITED(fmt, ...) \ > @@ -531,7 +577,7 @@ void __drm_err(const char *format, ...); > DEFAULT_RATELIMIT_INTERVAL, \ > DEFAULT_RATELIMIT_BURST); \ > if (__ratelimit(&_rs)) \ > - drm_dev_dbg(NULL, DRM_UT_KMS, fmt, ##__VA_ARGS__); \ > + drm_dev_dbg(NULL, cDRM_UT_KMS, fmt, ##__VA_ARGS__); \ > }) > > /* > -- > 2.28.0 > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Ville Syrjälä Intel
Re: [Intel-gfx] [patch 13/30] drm/i915/lpe_audio: Remove pointless irq_to_desc() usage
On Thu, Dec 10, 2020 at 08:25:49PM +0100, Thomas Gleixner wrote:
> Nothing uses the result and nothing should ever use it in driver code.
>
> Signed-off-by: Thomas Gleixner
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Pankaj Bharadiya
> Cc: Chris Wilson
> Cc: Wambui Karuga
> Cc: intel-...@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_lpe_audio.c |4
> 1 file changed, 4 deletions(-)
>
> --- a/drivers/gpu/drm/i915/display/intel_lpe_audio.c
> +++ b/drivers/gpu/drm/i915/display/intel_lpe_audio.c
> @@ -297,13 +297,9 @@ int intel_lpe_audio_init(struct drm_i915
> */
> void intel_lpe_audio_teardown(struct drm_i915_private *dev_priv)
> {
> - struct irq_desc *desc;
> -
> if (!HAS_LPE_AUDIO(dev_priv))
> return;
>
> - desc = irq_to_desc(dev_priv->lpe_audio.irq);
> -
> lpe_audio_platdev_destroy(dev_priv);
>
> irq_free_desc(dev_priv->lpe_audio.irq);
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
Re: [RFC PATCH 1/2] drm: RFC add choice to use dynamic debug in drm-debug
VA_ARGS__) > #define drm_dbg_lease(drm, fmt, ...) \ > - drm_dev_dbg((drm)->dev, DRM_UT_LEASE, fmt, ##__VA_ARGS__) > + drm_dev_dbg((drm)->dev, cDRM_UT_LEASE, fmt, ##__VA_ARGS__) > #define drm_dbg_dp(drm, fmt, ...)\ > - drm_dev_dbg((drm)->dev, DRM_UT_DP, fmt, ##__VA_ARGS__) > + drm_dev_dbg((drm)->dev, cDRM_UT_DP, fmt, ##__VA_ARGS__) > #define drm_dbg_drmres(drm, fmt, ...) > \ > - drm_dev_dbg((drm)->dev, DRM_UT_DRMRES, fmt, ##__VA_ARGS__) > + drm_dev_dbg((drm)->dev, cDRM_UT_DRMRES, fmt, ##__VA_ARGS__) > > > /* > @@ -471,7 +516,7 @@ void drm_dev_dbg(const struct device *dev, enum > drm_debug_category category, > */ > > __printf(2, 3) > -void __drm_dbg(enum drm_debug_category category, const char *format, ...); > +void ___drm_dbg(enum drm_debug_category category, const char *format, ...); > __printf(1, 2) > void __drm_err(const char *format, ...); > > @@ -500,29 +545,30 @@ void __drm_err(const char *format, ...); > #define DRM_ERROR_RATELIMITED(fmt, ...) > \ > DRM_DEV_ERROR_RATELIMITED(NULL, fmt, ##__VA_ARGS__) > > + > #define DRM_DEBUG(fmt, ...) \ > - __drm_dbg(DRM_UT_CORE, fmt, ##__VA_ARGS__) > + __drm_dbg(cDRM_UT_CORE, fmt, ##__VA_ARGS__) > > #define DRM_DEBUG_DRIVER(fmt, ...) \ > - __drm_dbg(DRM_UT_DRIVER, fmt, ##__VA_ARGS__) > + __drm_dbg(cDRM_UT_DRIVER, fmt, ##__VA_ARGS__) > > #define DRM_DEBUG_KMS(fmt, ...) > \ > - __drm_dbg(DRM_UT_KMS, fmt, ##__VA_ARGS__) > + __drm_dbg(cDRM_UT_KMS, fmt, ##__VA_ARGS__) > > #define DRM_DEBUG_PRIME(fmt, ...)\ > - __drm_dbg(DRM_UT_PRIME, fmt, ##__VA_ARGS__) > + __drm_dbg(cDRM_UT_PRIME, fmt, ##__VA_ARGS__) > > #define DRM_DEBUG_ATOMIC(fmt, ...) \ > - __drm_dbg(DRM_UT_ATOMIC, fmt, ##__VA_ARGS__) > + __drm_dbg(cDRM_UT_ATOMIC, fmt, ##__VA_ARGS__) > > #define DRM_DEBUG_VBL(fmt, ...) > \ > - __drm_dbg(DRM_UT_VBL, fmt, ##__VA_ARGS__) > + __drm_dbg(cDRM_UT_VBL, fmt, ##__VA_ARGS__) > > #define DRM_DEBUG_LEASE(fmt, ...)\ > - __drm_dbg(DRM_UT_LEASE, fmt, ##__VA_ARGS__) > + __drm_dbg(cDRM_UT_LEASE, fmt, ##__VA_ARGS__) > > #define DRM_DEBUG_DP(fmt, ...) > \ > - __drm_dbg(DRM_UT_DP, fmt, ## __VA_ARGS__) > + __drm_dbg(cDRM_UT_DP, fmt, ## __VA_ARGS__) > > > #define DRM_DEBUG_KMS_RATELIMITED(fmt, ...) \ > @@ -531,7 +577,7 @@ void __drm_err(const char *format, ...); > DEFAULT_RATELIMIT_INTERVAL, \ > DEFAULT_RATELIMIT_BURST); \ > if (__ratelimit(&_rs)) \ > - drm_dev_dbg(NULL, DRM_UT_KMS, fmt, ##__VA_ARGS__); \ > + drm_dev_dbg(NULL, cDRM_UT_KMS, fmt, ##__VA_ARGS__); \ > }) > > /* > -- > 2.28.0 > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Ville Syrjälä Intel
Re: [git pull] drm next pull for 5.10-rc1
On Mon, Nov 09, 2020 at 12:50:48PM -0500, Lyude Paul wrote: > Looking at the patches you sent is on my TODO list for this week at least as a > priority, although I really would have hoped that someone from Intel would > have looked by now since it's a regression on their end. What regression are you talking about? > > Gentle ping to Vsyrjala and Imre > > On Mon, 2020-11-09 at 14:52 +0300, Kirill A. Shutemov wrote: > > On Wed, Nov 04, 2020 at 04:58:14PM -0500, Lyude Paul wrote: > > > ACK, I will send out a patch for this asap > > > > Any update. AFAICS, v5.10-rc3 is still buggy. > > > > -- > Cheers, > Lyude Paul (she/her) > Software Engineer at Red Hat -- Ville Syrjälä Intel
Re: [PATCH 14/19] gpu: drm: selftests: test-drm_dp_mst_helper: Place 'struct drm_dp_sideband_msg_req_body' onto the heap
On Mon, Nov 09, 2020 at 04:40:04PM +, Lee Jones wrote:
> On Mon, 09 Nov 2020, Ville Syrjälä wrote:
>
> > On Mon, Nov 09, 2020 at 04:12:58PM +, Lee Jones wrote:
> > > On Mon, 09 Nov 2020, Ville Syrjälä wrote:
> > >
> > > > On Thu, Nov 05, 2020 at 02:45:12PM +, Lee Jones wrote:
> > > > > The stack is too full.
> > > > >
> > > > > Fixes the following W=1 kernel build warning(s):
> > > > >
> > > > > drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c: In function
> > > > > ‘sideband_msg_req_encode_decode’:
> > > > > drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c:161:1: warning:
> > > > > the frame size of 1176 bytes is larger than 1024 bytes
> > > > > [-Wframe-larger-than=]
> > > > >
> > > > > Cc: David Airlie
> > > > > Cc: Daniel Vetter
> > > > > Cc: Lyude Paul
> > > > > Cc: David Francis
> > > > > Cc: dri-de...@lists.freedesktop.org
> > > > > Signed-off-by: Lee Jones
> > > > > ---
> > > > > .../drm/selftests/test-drm_dp_mst_helper.c| 29
> > > > > ---
> > > > > 1 file changed, 18 insertions(+), 11 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c
> > > > > b/drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c
> > > > > index 1d696ec001cff..0a539456f6864 100644
> > > > > --- a/drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c
> > > > > +++ b/drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c
> > > > > @@ -120,44 +120,51 @@ sideband_msg_req_equal(const struct
> > > > > drm_dp_sideband_msg_req_body *in,
> > > > > static bool
> > > > > sideband_msg_req_encode_decode(struct drm_dp_sideband_msg_req_body
> > > > > *in)
> > > > > {
> > > > > - struct drm_dp_sideband_msg_req_body out = {0};
> > > > > + struct drm_dp_sideband_msg_req_body *out;
> > > >
> > > > How big is it? And why is it that big?
> > >
> > > It's a struct of a union of structs.
> > >
> > > And it's all allocated on the stack. Bad news!
> >
> > That doesn't answer my questions.
>
> It answers the second question.
Not really. A combination of structs and unions could be
pretty much any size.
>
> The answer to the first question you can `grep` for yourself. ;)
I would rather run pahole on it. But why would you require
reviewers to jump through such extra hoops when you could
just put that information into the commit message? With that
anyone could review this without having to do a lot of extra
work.
--
Ville Syrjälä
Intel
Re: [PATCH 14/19] gpu: drm: selftests: test-drm_dp_mst_helper: Place 'struct drm_dp_sideband_msg_req_body' onto the heap
On Mon, Nov 09, 2020 at 04:12:58PM +, Lee Jones wrote:
> On Mon, 09 Nov 2020, Ville Syrjälä wrote:
>
> > On Thu, Nov 05, 2020 at 02:45:12PM +, Lee Jones wrote:
> > > The stack is too full.
> > >
> > > Fixes the following W=1 kernel build warning(s):
> > >
> > > drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c: In function
> > > ‘sideband_msg_req_encode_decode’:
> > > drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c:161:1: warning: the
> > > frame size of 1176 bytes is larger than 1024 bytes [-Wframe-larger-than=]
> > >
> > > Cc: David Airlie
> > > Cc: Daniel Vetter
> > > Cc: Lyude Paul
> > > Cc: David Francis
> > > Cc: dri-de...@lists.freedesktop.org
> > > Signed-off-by: Lee Jones
> > > ---
> > > .../drm/selftests/test-drm_dp_mst_helper.c| 29 ---
> > > 1 file changed, 18 insertions(+), 11 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c
> > > b/drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c
> > > index 1d696ec001cff..0a539456f6864 100644
> > > --- a/drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c
> > > +++ b/drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c
> > > @@ -120,44 +120,51 @@ sideband_msg_req_equal(const struct
> > > drm_dp_sideband_msg_req_body *in,
> > > static bool
> > > sideband_msg_req_encode_decode(struct drm_dp_sideband_msg_req_body *in)
> > > {
> > > - struct drm_dp_sideband_msg_req_body out = {0};
> > > + struct drm_dp_sideband_msg_req_body *out;
> >
> > How big is it? And why is it that big?
>
> It's a struct of a union of structs.
>
> And it's all allocated on the stack. Bad news!
That doesn't answer my questions.
--
Ville Syrjälä
Intel
Re: [PATCH 14/19] gpu: drm: selftests: test-drm_dp_mst_helper: Place 'struct drm_dp_sideband_msg_req_body' onto the heap
On Thu, Nov 05, 2020 at 02:45:12PM +, Lee Jones wrote:
> The stack is too full.
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c: In function
> ‘sideband_msg_req_encode_decode’:
> drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c:161:1: warning: the frame
> size of 1176 bytes is larger than 1024 bytes [-Wframe-larger-than=]
>
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Lyude Paul
> Cc: David Francis
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Lee Jones
> ---
> .../drm/selftests/test-drm_dp_mst_helper.c| 29 ---
> 1 file changed, 18 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c
> b/drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c
> index 1d696ec001cff..0a539456f6864 100644
> --- a/drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c
> +++ b/drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c
> @@ -120,44 +120,51 @@ sideband_msg_req_equal(const struct
> drm_dp_sideband_msg_req_body *in,
> static bool
> sideband_msg_req_encode_decode(struct drm_dp_sideband_msg_req_body *in)
> {
> - struct drm_dp_sideband_msg_req_body out = {0};
> + struct drm_dp_sideband_msg_req_body *out;
How big is it? And why is it that big?
--
Ville Syrjälä
Intel
Re: [PATCH -next] drm/i915: Remove unused variable ret
On Thu, Oct 29, 2020 at 10:18:45AM +0800, Zou Wei wrote: > This patch fixes below warnings reported by coccicheck > > ./drivers/gpu/drm/i915/i915_debugfs.c:789:5-8: Unneeded variable: "ret". > Return "0" on line 1012 > > Reported-by: Hulk Robot > Signed-off-by: Zou Wei Thanks. Applied. > --- > drivers/gpu/drm/i915/i915_debugfs.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c > b/drivers/gpu/drm/i915/i915_debugfs.c > index ea46916..200f6b8 100644 > --- a/drivers/gpu/drm/i915/i915_debugfs.c > +++ b/drivers/gpu/drm/i915/i915_debugfs.c > @@ -786,7 +786,6 @@ static int i915_frequency_info(struct seq_file *m, void > *unused) > struct intel_uncore *uncore = _priv->uncore; > struct intel_rps *rps = _priv->gt.rps; > intel_wakeref_t wakeref; > - int ret = 0; > > wakeref = intel_runtime_pm_get(_priv->runtime_pm); > > @@ -1009,7 +1008,7 @@ static int i915_frequency_info(struct seq_file *m, void > *unused) > seq_printf(m, "Max pixel clock frequency: %d kHz\n", > dev_priv->max_dotclk_freq); > > intel_runtime_pm_put(_priv->runtime_pm, wakeref); > - return ret; > + return 0; > } > > static int i915_ring_freq_table(struct seq_file *m, void *unused) > -- > 2.6.2 > > _______ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Ville Syrjälä Intel
Re: [Intel-gfx] drm_modes: signed integer overflow
On Fri, Oct 23, 2020 at 03:14:20PM +, Simon Ser wrote:
> On Thursday, October 22, 2020 12:14 PM, Ville Syrjälä
> wrote:
>
> > On Wed, Oct 21, 2020 at 08:13:43PM -0700, Randy Dunlap wrote:
> >
> > > Hi,
> > > With linux-next 20201021, when booting up, I am seeing this:
> > > [ 0.560896] UBSAN: signed-integer-overflow in
> > > ../drivers/gpu/drm/drm_modes.c:765:20
> > > [ 0.560903] 2376000 * 1000 cannot be represented in type 'int'
> >
> > Dang. Didn't realize these new crazy >8k modes have dotclocks reaching
> > almost 6 GHz, which would overflow even u32. I guess we'll switch to
> > 64bit maths. Now I wonder how many other places can hit this overflow
> > in practice...
>
> Can you provide an example of a full crazy >8k mode?
These are two extreme cases:
/* 216 - 10240x4320@100Hz 64:27 */
{ DRM_MODE("10240x4320", DRM_MODE_TYPE_DRIVER, 594, 10240, 12432,
12608, 13200, 0, 4320, 4336, 4356, 4500, 0,
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
.picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
/* 217 - 10240x4320@120Hz 64:27 */
{ DRM_MODE("10240x4320", DRM_MODE_TYPE_DRIVER, 594, 10240, 10528,
10704, 11000, 0, 4320, 4336, 4356, 4500, 0,
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
.picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, }
> I'm trying to get
> a fix for my user-space [1], and I'm wondering if int32_t is enough
> after dividing by mode->htotal.
>
> CC Pekka, just FYI (I think Weston has similar code).
>
> [1]: https://github.com/swaywm/wlroots/pull/2450
What's with those 100LL constants? Are you storing
clock in Hz units?
--
Ville Syrjälä
Intel
Re: [Intel-gfx] drm_modes: signed integer overflow
On Wed, Oct 21, 2020 at 08:13:43PM -0700, Randy Dunlap wrote: > Hi, > > With linux-next 20201021, when booting up, I am seeing this: > > [0.560896] UBSAN: signed-integer-overflow in > ../drivers/gpu/drm/drm_modes.c:765:20 > [0.560903] 2376000 * 1000 cannot be represented in type 'int' Dang. Didn't realize these new crazy >8k modes have dotclocks reaching almost 6 GHz, which would overflow even u32. I guess we'll switch to 64bit maths. Now I wonder how many other places can hit this overflow in practice... > [0.560909] CPU: 3 PID: 7 Comm: kworker/u16:0 Not tainted > 5.9.0-next-20201021 #2 > [0.560914] Hardware name: TOSHIBA PORTEGE R835/Portable PC, BIOS Version > 4.10 01/08/2013 > [0.560924] Workqueue: events_unbound async_run_entry_fn > > [0.560930] Call Trace: > [0.560938] dump_stack+0x5e/0x74 > [0.560943] ubsan_epilogue+0x9/0x45 > [0.560948] handle_overflow+0x8b/0x98 > [0.560953] ? set_track+0x3f/0xad > [0.560958] __ubsan_handle_mul_overflow+0xe/0x10 > [0.560964] drm_mode_vrefresh+0x4a/0xbc > [0.560970] initcall i915_init+0x0/0x6a returned 0 after 116076 usecs > [0.560974] calling cn_proc_init+0x0/0x36 @ 1 > [0.560978] cea_mode_alternate_clock+0x11/0x62 > [0.560985] drm_match_cea_mode+0xc7/0x1e7 > [0.560987] initcall cn_proc_init+0x0/0x36 returned 0 after 3 usecs > [0.560990] calling topology_sysfs_init+0x0/0x2d @ 1 > [0.561000] drm_mode_validate_ycbcr420+0xd/0x48 > [0.561005] drm_helper_probe_single_connector_modes+0x6db/0x7da > [0.561012] drm_client_modeset_probe+0x225/0x143f > [0.561018] ? bitmap_fold+0x8a/0x8a > [0.561023] ? update_cfs_rq_load_avg+0x192/0x1a2 > [0.561029] __drm_fb_helper_initial_config_and_unlock+0x3f/0x5b7 > [0.561035] ? get_sd_balance_interval+0x1c/0x40 > [0.561040] drm_fb_helper_initial_config+0x48/0x4f > [0.561047] intel_fbdev_initial_config+0x13/0x23 > [0.561052] async_run_entry_fn+0x89/0x15c > [0.561058] process_one_work+0x15c/0x1f3 > [0.561064] worker_thread+0x1ac/0x25d > [0.561069] ? process_scheduled_works+0x2e/0x2e > [0.561074] kthread+0x10e/0x116 > [0.561078] ? kthread_parkme+0x1c/0x1c > [0.561083] ret_from_fork+0x22/0x30 > [0.561087] > > > -- > ~Randy > Reported-by: Randy Dunlap > _______ > Intel-gfx mailing list > intel-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ville Syrjälä Intel
Re: [PATCH v2 17/17] drm/i915: Properly request PCI BARs
On Fri, Oct 09, 2020 at 12:01:39PM +0200, Daniel Vetter wrote: > On Fri, Oct 9, 2020 at 11:47 AM Ville Syrjälä > wrote: > > > > On Fri, Oct 09, 2020 at 09:59:34AM +0200, Daniel Vetter wrote: > > > When trying to test my CONFIG_IO_STRICT_DEVMEM changes I realized they > > > do nothing for i915. Because i915 doesn't request any regions, like > > > pretty much all drm pci drivers. I guess this is some very old > > > remnants from the userspace modesetting days, when we wanted to > > > co-exist with the fbdev driver. Which usually requested these > > > resources. > > > > > > But makes me wonder why the pci subsystem doesn't just request > > > resource automatically when we map a bar and a pci driver is bound? > > > > > > Knowledge about which pci bars we need kludged together from > > > intel_uncore.c and intel_gtt.c from i915 and intel-gtt.c over in the > > > fake agp driver. > > > > > > Signed-off-by: Daniel Vetter > > > Cc: Jason Gunthorpe > > > Cc: Kees Cook > > > Cc: Dan Williams > > > Cc: Andrew Morton > > > Cc: John Hubbard > > > Cc: Jérôme Glisse > > > Cc: Jan Kara > > > Cc: Dan Williams > > > Cc: linux...@kvack.org > > > Cc: linux-arm-ker...@lists.infradead.org > > > Cc: linux-samsung-...@vger.kernel.org > > > Cc: linux-me...@vger.kernel.org > > > Cc: Bjorn Helgaas > > > Cc: linux-...@vger.kernel.org > > > --- > > > drivers/gpu/drm/i915/intel_uncore.c | 25 +++-- > > > 1 file changed, 23 insertions(+), 2 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/i915/intel_uncore.c > > > b/drivers/gpu/drm/i915/intel_uncore.c > > > index 54e201fdeba4..ce39049d8919 100644 > > > --- a/drivers/gpu/drm/i915/intel_uncore.c > > > +++ b/drivers/gpu/drm/i915/intel_uncore.c > > > @@ -1692,10 +1692,13 @@ static int uncore_mmio_setup(struct intel_uncore > > > *uncore) > > > struct pci_dev *pdev = i915->drm.pdev; > > > int mmio_bar; > > > int mmio_size; > > > + int bar_selection; > > > > Signed bitmasks always make me uneasy. But looks like > > that's what it is in the pci api. So meh. > > Yeah it's surprising. > > > > + int ret; > > > > > > mmio_bar = IS_GEN(i915, 2) ? 1 : 0; > > > + bar_selection = BIT (2) | BIT(mmio_bar); > >^ > > spurious space > > > > That's also not correct for gen2 I think. > > > > gen2: > > 0 = GMADR > > 1 = MMADR > > 2 = IOBAR > > > > gen3: > > 0 = MMADR > > 1 = IOBAR > > 2 = GMADR > > 3 = GTTADR > > > > gen4+: > > 0+1 = GTTMMADR > > 2+3 = GMADR > > 4 = IOBAR > > > > Maybe we should just have an explicit list of bars like that in a > > comment? > > > > I'd also suggest sucking this bitmask calculation into a small helper > > so you can reuse it for the release. > > tbh I just hacked this up for testing. Given how almost no other drm > driver does this, I'm wondering whether we should or not. > > Also the only reason why I didn't just use the pci_request_regions > helper is to avoid the vga ioport range, since that's managed by > vgaarbiter. VGA io range isn't part of any bar. Or do you mean just the io decode enable bit in the pci command register? That should be just a matter or pci_enable_device() vs. pci_enable_device_mem() I think. So nothing to do with which bars we've requested IIRC. > > So I think if we go for this for real we should: > - register the vga ioport range in the vgaarbiter > - have a pci_request_iomem_regions helper that grabs all mem bars > - roll that out to all drm pci drivers > > Or something like that. The other complication is when we resize the > iobar. So not really sure what to do here. We resize it? -- Ville Syrjälä Intel
Re: [PATCH v2 17/17] drm/i915: Properly request PCI BARs
On Fri, Oct 09, 2020 at 09:59:34AM +0200, Daniel Vetter wrote:
> When trying to test my CONFIG_IO_STRICT_DEVMEM changes I realized they
> do nothing for i915. Because i915 doesn't request any regions, like
> pretty much all drm pci drivers. I guess this is some very old
> remnants from the userspace modesetting days, when we wanted to
> co-exist with the fbdev driver. Which usually requested these
> resources.
>
> But makes me wonder why the pci subsystem doesn't just request
> resource automatically when we map a bar and a pci driver is bound?
>
> Knowledge about which pci bars we need kludged together from
> intel_uncore.c and intel_gtt.c from i915 and intel-gtt.c over in the
> fake agp driver.
>
> Signed-off-by: Daniel Vetter
> Cc: Jason Gunthorpe
> Cc: Kees Cook
> Cc: Dan Williams
> Cc: Andrew Morton
> Cc: John Hubbard
> Cc: Jérôme Glisse
> Cc: Jan Kara
> Cc: Dan Williams
> Cc: linux...@kvack.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-me...@vger.kernel.org
> Cc: Bjorn Helgaas
> Cc: linux-...@vger.kernel.org
> ---
> drivers/gpu/drm/i915/intel_uncore.c | 25 +++--
> 1 file changed, 23 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> b/drivers/gpu/drm/i915/intel_uncore.c
> index 54e201fdeba4..ce39049d8919 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -1692,10 +1692,13 @@ static int uncore_mmio_setup(struct intel_uncore
> *uncore)
> struct pci_dev *pdev = i915->drm.pdev;
> int mmio_bar;
> int mmio_size;
> + int bar_selection;
Signed bitmasks always make me uneasy. But looks like
that's what it is in the pci api. So meh.
> + int ret;
>
> mmio_bar = IS_GEN(i915, 2) ? 1 : 0;
> + bar_selection = BIT (2) | BIT(mmio_bar);
^
spurious space
That's also not correct for gen2 I think.
gen2:
0 = GMADR
1 = MMADR
2 = IOBAR
gen3:
0 = MMADR
1 = IOBAR
2 = GMADR
3 = GTTADR
gen4+:
0+1 = GTTMMADR
2+3 = GMADR
4 = IOBAR
Maybe we should just have an explicit list of bars like that in a
comment?
I'd also suggest sucking this bitmask calculation into a small helper
so you can reuse it for the release.
> /*
> - * Before gen4, the registers and the GTT are behind different BARs.
> + * On gen3 the registers and the GTT are behind different BARs.
>* However, from gen4 onwards, the registers and the GTT are shared
>* in the same BAR, so we want to restrict this ioremap from
>* clobbering the GTT which we want ioremap_wc instead. Fortunately,
> @@ -1703,6 +1706,8 @@ static int uncore_mmio_setup(struct intel_uncore
> *uncore)
>* generations up to Ironlake.
>* For dgfx chips register range is expanded to 4MB.
>*/
> + if (INTEL_GEN(i915) == 3)
> + bar_selection |= BIT(3);
> if (INTEL_GEN(i915) < 5)
> mmio_size = 512 * 1024;
> else if (IS_DGFX(i915))
> @@ -1710,8 +1715,15 @@ static int uncore_mmio_setup(struct intel_uncore
> *uncore)
> else
> mmio_size = 2 * 1024 * 1024;
>
> + ret = pci_request_selected_regions(pdev, bar_selection, "i915");
> + if (ret < 0) {
> + drm_err(>drm, "failed to request pci bars\n");
> + return ret;
> + }
> +
> uncore->regs = pci_iomap(pdev, mmio_bar, mmio_size);
> if (uncore->regs == NULL) {
> + pci_release_selected_regions(pdev, bar_selection);
> drm_err(>drm, "failed to map registers\n");
> return -EIO;
> }
> @@ -1721,9 +1733,18 @@ static int uncore_mmio_setup(struct intel_uncore
> *uncore)
>
> static void uncore_mmio_cleanup(struct intel_uncore *uncore)
> {
> - struct pci_dev *pdev = uncore->i915->drm.pdev;
> + struct drm_i915_private *i915 = uncore->i915;
> + struct pci_dev *pdev = i915->drm.pdev;
> + int mmio_bar;
> + int bar_selection;
> +
> + mmio_bar = IS_GEN(i915, 2) ? 1 : 0;
> + bar_selection = BIT (2) | BIT(mmio_bar);
> + if (INTEL_GEN(i915) == 3)
> + bar_selection |= BIT(3);
>
> pci_iounmap(pdev, uncore->regs);
> + pci_release_selected_regions(pdev, bar_selection);
> }
>
> void intel_uncore_init_early(struct intel_uncore *uncore,
> --
> 2.28.0
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
Re: [PATCH v2 0/3] drm: commit_work scheduling
On Wed, Oct 07, 2020 at 09:44:09AM -0700, Rob Clark wrote: > On Mon, Oct 5, 2020 at 5:15 AM Ville Syrjälä > wrote: > > > > On Fri, Oct 02, 2020 at 10:55:52AM -0700, Rob Clark wrote: > > > On Fri, Oct 2, 2020 at 4:05 AM Ville Syrjälä > > > wrote: > > > > > > > > On Fri, Oct 02, 2020 at 01:52:56PM +0300, Ville Syrjälä wrote: > > > > > On Thu, Oct 01, 2020 at 05:25:55PM +0200, Daniel Vetter wrote: > > > > > > On Thu, Oct 1, 2020 at 5:15 PM Rob Clark > > > > > > wrote: > > > > > > > > > > > > > > I'm leaning towards converting the other drivers over to use the > > > > > > > per-crtc kwork, and then dropping the 'commit_work` from atomic > > > > > > > state. > > > > > > > I can add a patch to that, but figured I could postpone that churn > > > > > > > until there is some by-in on this whole idea. > > > > > > > > > > > > i915 has its own commit code, it's not even using the current commit > > > > > > helpers (nor the commit_work). Not sure how much other fun there is. > > > > > > > > > > I don't think we want per-crtc threads for this in i915. Seems > > > > > to me easier to guarantee atomicity across multiple crtcs if > > > > > we just commit them from the same thread. > > > > > > > > Oh, and we may have to commit things in a very specific order > > > > to guarantee the hw doesn't fall over, so yeah definitely per-crtc > > > > thread is a no go. > > > > > > If I'm understanding the i915 code, this is only the case for modeset > > > commits? I suppose we could achieve the same result by just deciding > > > to pick the kthread of the first CRTC for modeset commits. I'm not > > > really so much concerned about parallelism for modeset. > > > > I'm not entirely happy about the random differences between modesets > > and other commits. Ideally we wouldn't need any. > > > > Anyways, even if we ignore modesets we still have the issue with > > atomicity guarantees across multiple crtcs. So I think we still > > don't want per-crtc threads, rather it should be thread for each > > commit. > > I don't really see any other way to solve the priority inversion other > than per-CRTC kthreads. What's the problem with just something like a dedicated commit thread pool? > I've been thinking about it a bit more, and > my conclusion is: > > (1) There isn't really any use for the N+1'th commit to start running > before the kthread_work for the N'th commit completes, so I don't mind > losing the unbound aspect of the workqueue approach > (2) For cases where there does need to be serialization between > commits on different CRTCs, since there is a per-CRTC kthread, you > could achieve this with locking > > Since i915 isn't using the atomic helpers here, I suppose it is an > option for i915 to just continue doing what it is doing. > > And I could ofc just stop using the atomic commit helper and do the > kthreads thing in msm. But my first preference would be that the > commit helper does generally the right thing. > > BR, > -R -- Ville Syrjälä Intel
Re: [PATCH] drm/fourcc: Add AXBXGXRX106106106106 format
On Wed, Oct 07, 2020 at 10:27:25AM +0100, Matteo Franchin wrote:
> Add ABGR format with 10-bit components packed in 64-bit per pixel.
> This format can be used to handle
> VK_FORMAT_R10X6G10X6B10X6A10X6_UNORM_4PACK16 on little-endian
> architectures.
>
> Signed-off-by: Matteo Franchin
> ---
> drivers/gpu/drm/drm_fourcc.c | 1 +
> include/uapi/drm/drm_fourcc.h | 7 +++
> 2 files changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index 722c7ebe4e88..bba03fcb016d 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -202,6 +202,7 @@ const struct drm_format_info *__drm_format_info(u32
> format)
> { .format = DRM_FORMAT_XBGR16161616F, .depth = 0,
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1 },
> { .format = DRM_FORMAT_ARGB16161616F, .depth = 0,
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true
> },
> { .format = DRM_FORMAT_ABGR16161616F, .depth = 0,
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true
> },
> + { .format = DRM_FORMAT_AXBXGXRX106106106106,.depth = 0,
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true
> },
> { .format = DRM_FORMAT_RGB888_A8, .depth = 32,
> .num_planes = 2, .cpp = { 3, 1, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true
> },
> { .format = DRM_FORMAT_BGR888_A8, .depth = 32,
> .num_planes = 2, .cpp = { 3, 1, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true
> },
> { .format = DRM_FORMAT_XRGB_A8, .depth = 32,
> .num_planes = 2, .cpp = { 4, 1, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true
> },
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 82f327801267..76eedba52b77 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -155,6 +155,13 @@ extern "C" {
> #define DRM_FORMAT_ARGB16161616F fourcc_code('A', 'R', '4', 'H') /* [63:0]
> A:R:G:B 16:16:16:16 little endian */
> #define DRM_FORMAT_ABGR16161616F fourcc_code('A', 'B', '4', 'H') /* [63:0]
> A:B:G:R 16:16:16:16 little endian */
>
> +/*
> + * RGBA format with 10-bit components packed in 64-bit per pixel, with 6 bits
> + * of unused padding per component:
> + * [63:0] A:x:B:x:G:x:R:x 10:6:10:6:10:6:10:6 little endian
I think we usually put that last bit at the end of the fourcc define.
In theory it makes grepping a bit nicer. The exceptions are all planar
formats where each plane can have different component packing.
> + */
> +#define DRM_FORMAT_AXBXGXRX106106106106 fourcc_code('A', 'B', '1', '0')
> +
> /* packed YCbCr */
> #define DRM_FORMAT_YUYV fourcc_code('Y', 'U', 'Y', 'V') /*
> [31:0] Cr0:Y1:Cb0:Y0 8:8:8:8 little endian */
> #define DRM_FORMAT_YVYU fourcc_code('Y', 'V', 'Y', 'U') /*
> [31:0] Cb0:Y1:Cr0:Y0 8:8:8:8 little endian */
> --
> 2.17.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
Re: [PATCH v2 0/3] drm: commit_work scheduling
On Fri, Oct 02, 2020 at 10:55:52AM -0700, Rob Clark wrote: > On Fri, Oct 2, 2020 at 4:05 AM Ville Syrjälä > wrote: > > > > On Fri, Oct 02, 2020 at 01:52:56PM +0300, Ville Syrjälä wrote: > > > On Thu, Oct 01, 2020 at 05:25:55PM +0200, Daniel Vetter wrote: > > > > On Thu, Oct 1, 2020 at 5:15 PM Rob Clark wrote: > > > > > > > > > > On Thu, Oct 1, 2020 at 12:25 AM Daniel Vetter wrote: > > > > > > > > > > > > On Wed, Sep 30, 2020 at 11:16 PM Rob Clark > > > > > > wrote: > > > > > > > > > > > > > > From: Rob Clark > > > > > > > > > > > > > > The android userspace treats the display pipeline as a realtime > > > > > > > problem. > > > > > > > And arguably, if your goal is to not miss frame deadlines (ie. > > > > > > > vblank), > > > > > > > it is. (See https://lwn.net/Articles/809545/ for the best > > > > > > > explaination > > > > > > > that I found.) > > > > > > > > > > > > > > But this presents a problem with using workqueues for non-blocking > > > > > > > atomic commit_work(), because the SCHED_FIFO userspace thread(s) > > > > > > > can > > > > > > > preempt the worker. Which is not really the outcome you want.. > > > > > > > once > > > > > > > the required fences are scheduled, you want to push the atomic > > > > > > > commit > > > > > > > down to hw ASAP. > > > > > > > > > > > > > > But the decision of whether commit_work should be RT or not really > > > > > > > depends on what userspace is doing. For a pure CFS userspace > > > > > > > display > > > > > > > pipeline, commit_work() should remain SCHED_NORMAL. > > > > > > > > > > > > > > To handle this, convert non-blocking commit_work() to use per-CRTC > > > > > > > kthread workers, instead of system_unbound_wq. Per-CRTC workers > > > > > > > are > > > > > > > used to avoid serializing commits when userspace is using a > > > > > > > per-CRTC > > > > > > > update loop. And the last patch exposes the task id to userspace > > > > > > > as > > > > > > > a CRTC property, so that userspace can adjust the priority and > > > > > > > sched > > > > > > > policy to fit it's needs. > > > > > > > > > > > > > > > > > > > > > v2: Drop client cap and in-kernel setting of priority/policy in > > > > > > > favor of exposing the kworker tid to userspace so that user- > > > > > > > space can set priority/policy. > > > > > > > > > > > > Yeah I think this looks more reasonable. Still a bit irky interface, > > > > > > so I'd like to get some kworker/rt ack on this. Other opens: > > > > > > - needs userspace, the usual drill > > > > > > > > > > fwiw, right now the userspace is "modetest + chrt".. *probably* the > > > > > userspace will become a standalone helper or daemon, mostly because > > > > > the chrome gpu-process sandbox does not allow setting SCHED_FIFO. I'm > > > > > still entertaining the possibility of switching between rt and cfs > > > > > depending on what is in the foreground (ie. only do rt for android > > > > > apps). > > > > > > > > > > > - we need this also for vblank workers, otherwise this wont work for > > > > > > drivers needing those because of another priority inversion. > > > > > > > > > > I have a thought on that, see below.. > > > > > > > > Hm, not seeing anything about vblank worker below? > > > > > > > > > > - we probably want some indication of whether this actually does > > > > > > something useful, not all drivers use atomic commit helpers. Not > > > > > > sure > > > > > > how to do that. > > > > > > > > > > I'm leaning towards converting the other drivers over to use the > > > > > per-crtc kwork, and then dropping the 'commit_work` from atomic state. > > &
Re: [LKP] Re: [drm/dp] 6509ca051a: PANIC:double_fault
On Tue, Sep 29, 2020 at 01:26:09PM +0800, Rong Chen wrote:
>
>
> On 9/25/20 12:42 AM, Ville Syrjälä wrote:
> > On Thu, Sep 24, 2020 at 10:30:49PM +0800, kernel test robot wrote:
> >> Greeting,
> >>
> >> FYI, we noticed the following commit (built with gcc-9):
> >>
> >> commit: 6509ca051abf4ff60d63732badcb2173a715f741 ("drm/dp: Add
> >> drm_dp_downstream_{min,max}_tmds_clock()")
> > That doesn't really do anything on its own. So can't see how it would
> > make anything blow up.
>
> Hi Ville,
>
> The issue is 100% reproducible, could you try the reproduce steps:
>
> To reproduce:
>
> # build kernel
> cd linux
> cp config-5.9.0-rc4-00881-g6509ca051abf4 .config
> make HOSTCC=gcc-9 CC=gcc-9 ARCH=i386 olddefconfig prepare
> modules_prepare bzImage
>
> git clone https://github.com/intel/lkp-tests.git
> cd lkp-tests
> bin/lkp qemu -k job-script # job-script is attached in
> this email
Managed to find some Ubuntu machine where that would run.
$ time ./bin/lkp qemu -k ~/bzImage ~/job-script
...
[0.00] Linux version 5.9.0-rc4-00027-g6509ca051abf (...) (gcc (Gentoo
9.3.0-r1 p3) 9.3.0, GNU ld (Gentoo 2.33.1 p2) 2.33.1) #2 SMP PREEMPT Fri Oct 2
19:24:28 EEST 2020
...
[ 12.717392] Applicom driver: $Id: ac.c,v 1.30 2000/03/22 16:03:57 dwmw2 Exp $
[ 12.718889] ac.o: No PCI boards found.
[ 12.719696] ac.o: For an ISA board you must supply memory and irq parameters.
[ 12.721269] toshiba: not a supported Toshiba laptop
[ 12.722779] random: get_random_u32 called from arch_rnd+0x1c/0x40 with
crng_init=0
[ 12.722784] random: get_random_u32 called from randomize_stack_top+0x35/0x50
with crng_init=0
[ 12.722787] random: get_random_u32 called from arch_align_stack+0x35/0x50
with crng_init=0
...
real11m35,352s
user13m40,549s
sys 0m13,071s
$ echo $?
0
--
Ville Syrjälä
Intel
Re: [PATCH v2 0/3] drm: commit_work scheduling
On Fri, Oct 02, 2020 at 01:52:56PM +0300, Ville Syrjälä wrote: > On Thu, Oct 01, 2020 at 05:25:55PM +0200, Daniel Vetter wrote: > > On Thu, Oct 1, 2020 at 5:15 PM Rob Clark wrote: > > > > > > On Thu, Oct 1, 2020 at 12:25 AM Daniel Vetter wrote: > > > > > > > > On Wed, Sep 30, 2020 at 11:16 PM Rob Clark wrote: > > > > > > > > > > From: Rob Clark > > > > > > > > > > The android userspace treats the display pipeline as a realtime > > > > > problem. > > > > > And arguably, if your goal is to not miss frame deadlines (ie. > > > > > vblank), > > > > > it is. (See https://lwn.net/Articles/809545/ for the best > > > > > explaination > > > > > that I found.) > > > > > > > > > > But this presents a problem with using workqueues for non-blocking > > > > > atomic commit_work(), because the SCHED_FIFO userspace thread(s) can > > > > > preempt the worker. Which is not really the outcome you want.. once > > > > > the required fences are scheduled, you want to push the atomic commit > > > > > down to hw ASAP. > > > > > > > > > > But the decision of whether commit_work should be RT or not really > > > > > depends on what userspace is doing. For a pure CFS userspace display > > > > > pipeline, commit_work() should remain SCHED_NORMAL. > > > > > > > > > > To handle this, convert non-blocking commit_work() to use per-CRTC > > > > > kthread workers, instead of system_unbound_wq. Per-CRTC workers are > > > > > used to avoid serializing commits when userspace is using a per-CRTC > > > > > update loop. And the last patch exposes the task id to userspace as > > > > > a CRTC property, so that userspace can adjust the priority and sched > > > > > policy to fit it's needs. > > > > > > > > > > > > > > > v2: Drop client cap and in-kernel setting of priority/policy in > > > > > favor of exposing the kworker tid to userspace so that user- > > > > > space can set priority/policy. > > > > > > > > Yeah I think this looks more reasonable. Still a bit irky interface, > > > > so I'd like to get some kworker/rt ack on this. Other opens: > > > > - needs userspace, the usual drill > > > > > > fwiw, right now the userspace is "modetest + chrt".. *probably* the > > > userspace will become a standalone helper or daemon, mostly because > > > the chrome gpu-process sandbox does not allow setting SCHED_FIFO. I'm > > > still entertaining the possibility of switching between rt and cfs > > > depending on what is in the foreground (ie. only do rt for android > > > apps). > > > > > > > - we need this also for vblank workers, otherwise this wont work for > > > > drivers needing those because of another priority inversion. > > > > > > I have a thought on that, see below.. > > > > Hm, not seeing anything about vblank worker below? > > > > > > - we probably want some indication of whether this actually does > > > > something useful, not all drivers use atomic commit helpers. Not sure > > > > how to do that. > > > > > > I'm leaning towards converting the other drivers over to use the > > > per-crtc kwork, and then dropping the 'commit_work` from atomic state. > > > I can add a patch to that, but figured I could postpone that churn > > > until there is some by-in on this whole idea. > > > > i915 has its own commit code, it's not even using the current commit > > helpers (nor the commit_work). Not sure how much other fun there is. > > I don't think we want per-crtc threads for this in i915. Seems > to me easier to guarantee atomicity across multiple crtcs if > we just commit them from the same thread. Oh, and we may have to commit things in a very specific order to guarantee the hw doesn't fall over, so yeah definitely per-crtc thread is a no go. I don't even understand the serialization argument. If the commits are truly independent then why isn't the unbound wq enough to avoid the serialization? It should just spin up a new thread for each commit no? -- Ville Syrjälä Intel
Re: [PATCH v2 0/3] drm: commit_work scheduling
On Thu, Oct 01, 2020 at 05:25:55PM +0200, Daniel Vetter wrote: > On Thu, Oct 1, 2020 at 5:15 PM Rob Clark wrote: > > > > On Thu, Oct 1, 2020 at 12:25 AM Daniel Vetter wrote: > > > > > > On Wed, Sep 30, 2020 at 11:16 PM Rob Clark wrote: > > > > > > > > From: Rob Clark > > > > > > > > The android userspace treats the display pipeline as a realtime problem. > > > > And arguably, if your goal is to not miss frame deadlines (ie. vblank), > > > > it is. (See https://lwn.net/Articles/809545/ for the best explaination > > > > that I found.) > > > > > > > > But this presents a problem with using workqueues for non-blocking > > > > atomic commit_work(), because the SCHED_FIFO userspace thread(s) can > > > > preempt the worker. Which is not really the outcome you want.. once > > > > the required fences are scheduled, you want to push the atomic commit > > > > down to hw ASAP. > > > > > > > > But the decision of whether commit_work should be RT or not really > > > > depends on what userspace is doing. For a pure CFS userspace display > > > > pipeline, commit_work() should remain SCHED_NORMAL. > > > > > > > > To handle this, convert non-blocking commit_work() to use per-CRTC > > > > kthread workers, instead of system_unbound_wq. Per-CRTC workers are > > > > used to avoid serializing commits when userspace is using a per-CRTC > > > > update loop. And the last patch exposes the task id to userspace as > > > > a CRTC property, so that userspace can adjust the priority and sched > > > > policy to fit it's needs. > > > > > > > > > > > > v2: Drop client cap and in-kernel setting of priority/policy in > > > > favor of exposing the kworker tid to userspace so that user- > > > > space can set priority/policy. > > > > > > Yeah I think this looks more reasonable. Still a bit irky interface, > > > so I'd like to get some kworker/rt ack on this. Other opens: > > > - needs userspace, the usual drill > > > > fwiw, right now the userspace is "modetest + chrt".. *probably* the > > userspace will become a standalone helper or daemon, mostly because > > the chrome gpu-process sandbox does not allow setting SCHED_FIFO. I'm > > still entertaining the possibility of switching between rt and cfs > > depending on what is in the foreground (ie. only do rt for android > > apps). > > > > > - we need this also for vblank workers, otherwise this wont work for > > > drivers needing those because of another priority inversion. > > > > I have a thought on that, see below.. > > Hm, not seeing anything about vblank worker below? > > > > - we probably want some indication of whether this actually does > > > something useful, not all drivers use atomic commit helpers. Not sure > > > how to do that. > > > > I'm leaning towards converting the other drivers over to use the > > per-crtc kwork, and then dropping the 'commit_work` from atomic state. > > I can add a patch to that, but figured I could postpone that churn > > until there is some by-in on this whole idea. > > i915 has its own commit code, it's not even using the current commit > helpers (nor the commit_work). Not sure how much other fun there is. I don't think we want per-crtc threads for this in i915. Seems to me easier to guarantee atomicity across multiple crtcs if we just commit them from the same thread. -- Ville Syrjälä Intel
Re: [PATCH v6] drm/i915: Init lspcon after HPD in intel_dp_detect()
(lspcon_wait_mode(lspcon, expected_mode) == DRM_LSPCON_MODE_PCON)
> + return;
> +
> + if (lspcon_change_mode(lspcon, DRM_LSPCON_MODE_PCON))
> + DRM_ERROR("LSPCON resume failed\n");
> + else
> + DRM_DEBUG_KMS("LSPCON resume success\n");
> +}
> diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.h
> b/drivers/gpu/drm/i915/display/intel_lspcon.h
> index 37cfddf8a9c5..169db35db13e 100644
> --- a/drivers/gpu/drm/i915/display/intel_lspcon.h
> +++ b/drivers/gpu/drm/i915/display/intel_lspcon.h
> @@ -15,8 +15,7 @@ struct intel_digital_port;
> struct intel_encoder;
> struct intel_lspcon;
>
> -bool lspcon_init(struct intel_digital_port *intel_dig_port);
> -void lspcon_resume(struct intel_lspcon *lspcon);
> +void lspcon_resume(struct intel_digital_port *intel_dig_port);
> void lspcon_wait_pcon_mode(struct intel_lspcon *lspcon);
> void lspcon_write_infoframe(struct intel_encoder *encoder,
> const struct intel_crtc_state *crtc_state,
> --
> 2.17.1
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH] Revert "drm/i915: Force state->modeset=true when distrust_bios_wm==true"
On Wed, Sep 30, 2020 at 03:47:06PM +0200, Stefan Joosten wrote: > The fix of flagging state->modeset whenever distrust_bios_wm is set > causes a regression when initializing display(s) attached to a Lenovo > USB-C docking station. The display remains blank until the dock is > reattached. Revert to bring the behavior of the functional v5.6 stable. > > This reverts commit 0f8839f5f323da04a800e6ced1136e4b1e1689a9. > > BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1879442 > Signed-off-by: Stefan Joosten > --- > drivers/gpu/drm/i915/display/intel_display.c | 14 -- > 1 file changed, 14 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c > b/drivers/gpu/drm/i915/display/intel_display.c > index b18c5ac2934d..ece1c28278f7 100644 > --- a/drivers/gpu/drm/i915/display/intel_display.c > +++ b/drivers/gpu/drm/i915/display/intel_display.c > @@ -14942,20 +14942,6 @@ static int intel_atomic_check(struct drm_device *dev, > if (ret) > goto fail; > > - /* > - * distrust_bios_wm will force a full dbuf recomputation > - * but the hardware state will only get updated accordingly > - * if state->modeset==true. Hence distrust_bios_wm==true && > - * state->modeset==false is an invalid combination which > - * would cause the hardware and software dbuf state to get > - * out of sync. We must prevent that. > - * > - * FIXME clean up this mess and introduce better > - * state tracking for dbuf. > - */ > - if (dev_priv->wm.distrust_bios_wm) > - any_ms = true; > - Argh. If only I had managed to land the full dbuf rework and nuke this mess before it came back to bite us... This is definitely going to break something else, so not great. Can you file an upstream bug at https://gitlab.freedesktop.org/drm/intel/issues/new and attach dmesgs from booting both good and bad kernels with drm.debug=0x1e passed to the kernel cmdline? Bump log_buf_len= if necessary to capture the full log. > intel_fbc_choose_crtc(dev_priv, state); > ret = calc_watermark_data(state); > if (ret) > -- > 2.25.4 > > > ___________ > Intel-gfx mailing list > intel-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ville Syrjälä Intel
Re: [PATCH] drm/nouveau/kms/nv50-: Fix clock checking algorithm in nv50_dp_mode_valid()
On Tue, Sep 29, 2020 at 01:54:13PM -0400, Lyude Paul wrote:
> On Mon, 2020-09-28 at 16:01 +0300, Ville Syrjälä wrote:
> > On Tue, Sep 22, 2020 at 05:05:10PM -0400, Lyude Paul wrote:
> > > While I thought I had this correct (since it actually did reject modes
> > > like I expected during testing), Ville Syrjala from Intel pointed out
> > > that the logic here isn't correct. max_clock refers to the max symbol
> > > rate supported by the encoder, so limiting clock to ds_clock using max()
> > > doesn't make sense. Additionally, we want to check against 6bpc for the
> > > time being since that's the minimum possible bpc here, not the reported
> > > bpc from the connector. See:
> > >
> > > https://lists.freedesktop.org/archives/dri-devel/2020-September/280276.html
> > >
> > > For more info.
> > >
> > > So, let's rewrite this using Ville's advice.
> > >
> > > Signed-off-by: Lyude Paul
> > > Fixes: 409d38139b42 ("drm/nouveau/kms/nv50-: Use downstream DP clock
> > > limits for mode validation")
> > > Cc: Ville Syrjälä
> > > Cc: Lyude Paul
> > > Cc: Ben Skeggs
> > > ---
> > > drivers/gpu/drm/nouveau/nouveau_dp.c | 23 +--
> > > 1 file changed, 13 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
> > > b/drivers/gpu/drm/nouveau/nouveau_dp.c
> > > index 7b640e05bd4cd..24c81e423d349 100644
> > > --- a/drivers/gpu/drm/nouveau/nouveau_dp.c
> > > +++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
> > > @@ -231,23 +231,26 @@ nv50_dp_mode_valid(struct drm_connector *connector,
> > > const struct drm_display_mode *mode,
> > > unsigned *out_clock)
> > > {
> > > - const unsigned min_clock = 25000;
> > > - unsigned max_clock, ds_clock, clock;
> > > + const unsigned int min_clock = 25000;
> > > + unsigned int max_clock, ds_clock, clock;
> > > + const u8 bpp = 18; /* 6 bpc */
> >
> > AFAICS nv50_outp_atomic_check() and nv50_msto_atomic_check()
> > just blindly use connector->display_info.bpc without any fallback
> > logic to lower the bpc. So Ilia's concerns seem well founded.
> > Without that logic I guess you should just use
> > connector->display_info.bpc here as well.
> >
> > > enum drm_mode_status ret;
> > >
> > > if (mode->flags & DRM_MODE_FLAG_INTERLACE && !outp->caps.dp_interlace)
> > > return MODE_NO_INTERLACE;
> > >
> > > max_clock = outp->dp.link_nr * outp->dp.link_bw;
> > > - ds_clock = drm_dp_downstream_max_dotclock(outp->dp.dpcd,
> > > - outp->dp.downstream_ports);
> > > - if (ds_clock)
> > > - max_clock = min(max_clock, ds_clock);
> > > -
> > > - clock = mode->clock * (connector->display_info.bpc * 3) / 10;
> > > - ret = nouveau_conn_mode_clock_valid(mode, min_clock, max_clock,
> > > - );
> > > + clock = mode->clock * bpp / 8;
> > > + if (clock > max_clock)
> > > + return MODE_CLOCK_HIGH;
> >
> > This stuff vs. nouveau_conn_mode_clock_valid() still seems a bit messy.
> > The max_clock you pass to nouveau_conn_mode_clock_valid() is the max
> > symbol clock, but nouveau_conn_mode_clock_valid() checks it against the
> > dotclock. Also only nouveau_conn_mode_clock_valid() has any kind of
> > stereo 3D handling, but AFAICS stereo_allowed is also set for DP?
>
> ...not sure I'm following you here, it's set to true for DP so don't we want
> to check it and adjust the pixel clock we output accordingly?
Yes, but then you need to also double your your pixel clock
derived values in this function. Ie. all the mode->clock
needs to become mode->clock*2 when dealing with a 3D frame
packing mode.
>
> >
> > > +
> > > + ds_clock = drm_dp_downstream_max_dotclock(outp->dp.dpcd, outp-
> > > >dp.downstream_ports);
> > > + if (ds_clock && mode->clock > ds_clock)
> > > + return MODE_CLOCK_HIGH;
> > > +
> > > + ret = nouveau_conn_mode_clock_valid(mode, min_clock, max_clock,
> > > );
> > > if (out_clock)
> > > *out_clock = clock;
> > > +
> > > return ret;
> > > }
> > > --
> > > 2.26.2
> --
> Cheers,
> Lyude Paul (she/her)
> Software Engineer at Red Hat
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH 2/2] drm/i915/edp/jsl: Update vswing table for HBR and HBR2
On Mon, Sep 28, 2020 at 08:20:59PM +0300, Jani Nikula wrote: > On Mon, 28 Sep 2020, Ville Syrjälä wrote: > > On Mon, Sep 28, 2020 at 07:15:43AM -0700, James Ausmus wrote: > >> On Mon, Sep 28, 2020 at 04:43:11PM +0300, Jani Nikula wrote: > >> > On Mon, 28 Sep 2020, Tejas Upadhyay > >> > wrote: > >> > > JSL has update in vswing table for eDP > >> > > >> > I've thought the TLA for Jasper Lake is JSP, not JSL. At least we have > >> > PCH_JSP for Jasper Lake PCH. > >> > >> JSP == Point (the PCH), JSL == Lake > > > > .PT was " Point", ..P stands just for " PCH" IIRC. > > Yeah, nowadays it doesn't have "Point", however bspec agrees on the JSL > acronym for Jasper Lake. Bspec uses ..P for " PCH", when it acknowledges the existence of said PCH (see eg. CNP,ICP,TGP). JSP is not among that select crowd however, neither really is MCC (although it is mentioned by name in the JSL section). I kinda want to nuke the JSP and MCC types entirely. I believe we should be able to treat them as just ICP and TGP variants respectively. But theres's still a bit of work left to do before we can get there. -- Ville Syrjälä Intel
Re: [Intel-gfx] [PATCH 2/2] drm/i915/edp/jsl: Update vswing table for HBR and HBR2
On Mon, Sep 28, 2020 at 07:15:43AM -0700, James Ausmus wrote: > On Mon, Sep 28, 2020 at 04:43:11PM +0300, Jani Nikula wrote: > > On Mon, 28 Sep 2020, Tejas Upadhyay > > wrote: > > > JSL has update in vswing table for eDP > > > > I've thought the TLA for Jasper Lake is JSP, not JSL. At least we have > > PCH_JSP for Jasper Lake PCH. > > JSP == Point (the PCH), JSL == Lake .PT was " Point", ..P stands just for " PCH" IIRC. -- Ville Syrjälä Intel
Re: [PATCH] drm/nouveau/kms/nv50-: Fix clock checking algorithm in nv50_dp_mode_valid()
On Tue, Sep 22, 2020 at 05:05:10PM -0400, Lyude Paul wrote:
> While I thought I had this correct (since it actually did reject modes
> like I expected during testing), Ville Syrjala from Intel pointed out
> that the logic here isn't correct. max_clock refers to the max symbol
> rate supported by the encoder, so limiting clock to ds_clock using max()
> doesn't make sense. Additionally, we want to check against 6bpc for the
> time being since that's the minimum possible bpc here, not the reported
> bpc from the connector. See:
>
> https://lists.freedesktop.org/archives/dri-devel/2020-September/280276.html
>
> For more info.
>
> So, let's rewrite this using Ville's advice.
>
> Signed-off-by: Lyude Paul
> Fixes: 409d38139b42 ("drm/nouveau/kms/nv50-: Use downstream DP clock limits
> for mode validation")
> Cc: Ville Syrjälä
> Cc: Lyude Paul
> Cc: Ben Skeggs
> ---
> drivers/gpu/drm/nouveau/nouveau_dp.c | 23 +--
> 1 file changed, 13 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
> b/drivers/gpu/drm/nouveau/nouveau_dp.c
> index 7b640e05bd4cd..24c81e423d349 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_dp.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
> @@ -231,23 +231,26 @@ nv50_dp_mode_valid(struct drm_connector *connector,
> const struct drm_display_mode *mode,
> unsigned *out_clock)
> {
> - const unsigned min_clock = 25000;
> - unsigned max_clock, ds_clock, clock;
> + const unsigned int min_clock = 25000;
> + unsigned int max_clock, ds_clock, clock;
> + const u8 bpp = 18; /* 6 bpc */
AFAICS nv50_outp_atomic_check() and nv50_msto_atomic_check()
just blindly use connector->display_info.bpc without any fallback
logic to lower the bpc. So Ilia's concerns seem well founded.
Without that logic I guess you should just use
connector->display_info.bpc here as well.
> enum drm_mode_status ret;
>
> if (mode->flags & DRM_MODE_FLAG_INTERLACE && !outp->caps.dp_interlace)
> return MODE_NO_INTERLACE;
>
> max_clock = outp->dp.link_nr * outp->dp.link_bw;
> - ds_clock = drm_dp_downstream_max_dotclock(outp->dp.dpcd,
> - outp->dp.downstream_ports);
> - if (ds_clock)
> - max_clock = min(max_clock, ds_clock);
> -
> - clock = mode->clock * (connector->display_info.bpc * 3) / 10;
> - ret = nouveau_conn_mode_clock_valid(mode, min_clock, max_clock,
> - );
> + clock = mode->clock * bpp / 8;
> + if (clock > max_clock)
> + return MODE_CLOCK_HIGH;
This stuff vs. nouveau_conn_mode_clock_valid() still seems a bit messy.
The max_clock you pass to nouveau_conn_mode_clock_valid() is the max
symbol clock, but nouveau_conn_mode_clock_valid() checks it against the
dotclock. Also only nouveau_conn_mode_clock_valid() has any kind of
stereo 3D handling, but AFAICS stereo_allowed is also set for DP?
> +
> + ds_clock = drm_dp_downstream_max_dotclock(outp->dp.dpcd,
> outp->dp.downstream_ports);
> + if (ds_clock && mode->clock > ds_clock)
> + return MODE_CLOCK_HIGH;
> +
> + ret = nouveau_conn_mode_clock_valid(mode, min_clock, max_clock, );
> if (out_clock)
> *out_clock = clock;
> +
> return ret;
> }
> --
> 2.26.2
--
Ville Syrjälä
Intel
Re: [PATCH 0/3] Fix Kernel-doc warnings introduced on next-20200921
On Tue, Sep 22, 2020 at 01:39:41PM -0400, Lyude Paul wrote: > For patches 2 and 3: > > Reviewed-by: Lyude Paul > > I'll go ahead and push these to drm-intel-next-queued (since drm-misc-next > doesn't have these patches in yet, and the commits these fix were originally > merged through drm-intel-next-queued anyway). thanks! Mea culpa. My doc test build was foiled by the sphinx 2 vs. 3 regression and I was too lazy to start downgrading things. Any ETA for getting that fixed btw? > > On Tue, 2020-09-22 at 13:22 +0200, Mauro Carvalho Chehab wrote: > > A few new warnings were added at linux-next. Address them, in order for us > > to keep zero warnings at the docs. > > > > The entire patchset fixing all kernel-doc warnings is at: > > https://git.linuxtv.org/mchehab/experimental.git/log/?h=doc-fixes > > > > Mauro Carvalho Chehab (3): > > net: fix a new kernel-doc warning at dev.c > > drm/dp: fix kernel-doc warnings at drm_dp_helper.c > > drm/dp: fix a kernel-doc issue at drm_edid.c > > > > drivers/gpu/drm/drm_dp_helper.c | 5 + > > drivers/gpu/drm/drm_edid.c | 2 +- > > net/core/dev.c | 4 ++-- > > 3 files changed, 8 insertions(+), 3 deletions(-) > > > -- > Cheers, > Lyude Paul (she/her) > Software Engineer at Red Hat -- Ville Syrjälä Intel
Re: [Intel-gfx] [PATCH] i915: Introduce quirk for shifting eDP brightness.
On Thu, Sep 17, 2020 at 09:25:35PM +0300, Ville Syrjälä wrote: > On Thu, Sep 17, 2020 at 11:14:43AM -0700, Puthikorn Voravootivat wrote: > > The Lyude fde7266fb2f6 change is actually based on Chromium change > > (https://crrev.com/c/1650325) that fixes the brightness for Samsung > > Galaxy Chromebook. So currently we have 2 examples that use LSB > > interpretation and 1 that use MSB. > > "If field 4:0 of the EDP_PWMGEN_BIT_COUNT register represents a value > of greater than 8 and the BACKLIGHT_BRIGHTNESS_BYTE_COUNT bit > is cleared to 0, only the 8 MSB of the brightness control value can be > controlled. > (See Note below.) > Assigned bits are allocated to the MSB of the enabled register > combination." > > I think that's pretty clear the assigned bits are supposed to be > msb aligned. I guess there's some email issues happening, but just to clarify: When the spec says MSB in caps here it clearly means "most significant-bit(s)" since otherwise "8 MSB" would not make any sense in the context of a 2 byte value. Granted the spec is crap here since "Table 1-1: Acronyms and Initialism" does claim "MSB" should be byte(s) and "msb" bit(s). Also I can't imagine anyone would allocate the bits starting from the lsb when the whole thing is clearly supposed to be a 16bit big endian integer. So with >8 assigned bits you'd end up with crazy stuff like this: [ 7 ... 0 ][7 ... 0] [ 8 MSB ][][N LSB] so you couldn't even treat the value as a regular big endian thing. Instead, if you squint a bit, it now looks like a funky little endian value. So we're deep into some mixed endian land where nothing makes sense anymore. Anyways I think the code should simply do this to match the spec: u16 value = brightness << (16 - num_assigned_bits); val[0] = value >> 8; val[1] = value & 0xff; > > > > > > > On Thu, Sep 17, 2020 at 10:55 AM Kevin Chowski wrote: > > > > > > Apologies for being too vague. To be as precise I can be, here is the > > > specific code delta I tested: https://crrev.com/c/2406616 . To answer > > > your other question, the code I tested against is indeed including the > > > fde7266fb2f6 (despite ostensibly being called 5.4 in my commit > > > message): our current top-of-tree for our 5.4 branch includes the > > > intel_dp_aux_calc_max_backlight logic. Further, I'll note that change > > > is exactly the change which breaks my Pixelbook model: prior to the > > > change, the max_brightness was hard-coded to 0x and the math > > > worked out that it didn't matter that the hardware cared about the MSB > > > despite the driver code caring about the LSB. > > > > > > To answer Ville's question: the fde7266fb2f6 change which fixes one > > > laptop (I believe Thinkpad X1 extreme Gen 2, from some bug reports I > > > dug up) and breaks another (Pixelbook); so unfortunately I believe we > > > need a quirk at least for some laptop. Reading through the copy of the > > > datasheet I have, it wasn't clear to me which was the correct > > > interpretation. I'm cc'ing puthik@, who was leaning toward the current > > > kernel code (caring about LSB) being the correct interpretation. I > > > believe we have other chromebooks which do rely on LSB functionality, > > > so unless we can find more examples of laptops wanting MSB it > > > currently looks like Pixelbook is the outlier. > > > > > > On Thu, Sep 17, 2020 at 11:28 AM Jani Nikula > > > wrote: > > > > > > > > On Thu, 17 Sep 2020, Kevin Chowski wrote: > > > > > We have observed that Google Pixelbook's backlight hardware is > > > > > interpretting these backlight bits from the most-significant side of > > > > > the > > > > > 16 bit word (if DP_EDP_PWMGEN_BIT_COUNT < 16), whereas the driver code > > > > > assumes the peripheral cares about the least-significant bits. > > > > > > > > > > Testing was done from within Chrome OS's build environment when the > > > > > patch is backported to 5.4 (the version we are newly targeting for the > > > > > Pixelbook); for the record: > > > > >$ emerge-eve-kernelnext sys-kernel/chromeos-kernel-5_4 && \ > > > > > ./update_kernel.sh --remote=$IP > > > > > > > > > > I used `/sys/kernel/debug/dri/0/eDP-1/i915_dpcd` on my laptop to > > > > > verify > > > > > that the registers were being set according to what the actual > > > &
Re: [PATCH] i915: Introduce quirk for shifting eDP brightness.
FO("Applying shift eDP backlight brightness quirk\n");
> +}
> +
> struct intel_quirk {
> int device;
> int subsystem_vendor;
> @@ -156,6 +166,9 @@ static struct intel_quirk intel_quirks[] = {
> /* ASRock ITX*/
> { 0x3185, 0x1849, 0x2212, quirk_increase_ddi_disabled_time },
> { 0x3184, 0x1849, 0x2212, quirk_increase_ddi_disabled_time },
> +
> + /* Google Pixelbook */
> + { 0x591E, 0x8086, 0x2212, quirk_shift_edp_backlight_brightness },
> };
>
> void intel_init_quirks(struct drm_i915_private *i915)
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index e4f7f6518945b..cc93bede4fab8 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -525,6 +525,7 @@ struct i915_psr {
> #define QUIRK_PIN_SWIZZLED_PAGES (1<<5)
> #define QUIRK_INCREASE_T12_DELAY (1<<6)
> #define QUIRK_INCREASE_DDI_DISABLED_TIME (1<<7)
> +#define QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS (1<<8)
>
> struct intel_fbdev;
> struct intel_fbc_work;
> --
> 2.28.0.618.gf4bc123cb7-goog
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH v5 14/20] drm/nouveau/kms/nv50-: Use downstream DP clock limits for mode validation
st use 6 for bpc if (clock > max_clock) reurn CLOCK_HIGH; ds_clock = drm_dp_downstream_max_dotclock(); if (ds_clock && mode->clock > ds_clock) return CLOCK_HIGH; + a bit more if you want to also deal with the TMDS clock limits sensibly. That also requires some though as to which bpc to use. In i915 we assume 8bpc when calculating the TMDS clock since that's the minimum DVI/HDMI supports. -- Ville Syrjälä Intel
Re: [PATCH -next 0/8] drm/amd/amdgpu: fix comparison pointer to bool warning
On Tue, Sep 15, 2020 at 03:16:32PM -0400, Alex Deucher wrote: > I question the value of these warnings. Why even have a boolean type > if you are going to get warnings when you use them... > That said, applied to avoid getting these patches again and again > every time someone sees this. if (this_is_sparta) if (this_is_sparta == true) if (this_is_sparta != false) I think the first one reads the best, and avoids having to decide between truth and falsehood :) > > Alex > > On Wed, Sep 9, 2020 at 9:21 AM Christian König > wrote: > > > > Acked-by: Christian König for the series. > > > > Am 09.09.20 um 15:07 schrieb Zheng Bin: > > > Zheng Bin (8): > > >drm/amd/amdgpu: fix comparison pointer to bool warning in gfx_v9_0.c > > >drm/amd/amdgpu: fix comparison pointer to bool warning in gfx_v10_0.c > > >drm/amd/amdgpu: fix comparison pointer to bool warning in sdma_v5_0.c > > >drm/amd/amdgpu: fix comparison pointer to bool warning in sdma_v5_2.c > > >drm/amd/amdgpu: fix comparison pointer to bool warning in si.c > > >drm/amd/amdgpu: fix comparison pointer to bool warning in uvd_v6_0.c > > >drm/amd/amdgpu: fix comparison pointer to bool warning in > > > amdgpu_atpx_handler.c > > >drm/amd/amdgpu: fix comparison pointer to bool warning in sdma_v4_0.c > > > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | 4 ++-- > > > drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 2 +- > > > drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c| 2 +- > > > drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 4 ++-- > > > drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c | 2 +- > > > drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c | 2 +- > > > drivers/gpu/drm/amd/amdgpu/si.c | 2 +- > > > drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c| 4 ++-- > > > 8 files changed, 11 insertions(+), 11 deletions(-) > > > > > > -- > > > 2.26.0.106.g9fadedd > > > > > > > ___ > > amd-gfx mailing list > > amd-...@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/amd-gfx > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Ville Syrjälä Intel
Re: [PATCH] drm/imx/dcss: fix 64-bit divisions
On Fri, Sep 11, 2020 at 04:48:27PM +0300, Laurentiu Palcu wrote: > Use div_s64() for the 64-bit divisions. This would allow the driver to compile > on 32-bit architectures, if needed. > > Signed-off-by: Laurentiu Palcu > --- > drivers/gpu/drm/imx/dcss/dcss-scaler.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/imx/dcss/dcss-scaler.c > b/drivers/gpu/drm/imx/dcss/dcss-scaler.c > index cd21905de580..7c1e0e461244 100644 > --- a/drivers/gpu/drm/imx/dcss/dcss-scaler.c > +++ b/drivers/gpu/drm/imx/dcss/dcss-scaler.c > @@ -134,7 +134,7 @@ static int div_q(int A, int B) > else > temp -= B / 2; > > - result = (int)(temp / B); > + result = (int)(div_s64(temp, B)); > return result; > } > > @@ -237,7 +237,7 @@ static void dcss_scaler_gaussian_filter(int fc_q, bool > use_5_taps, > ll_temp = coef[phase][i]; > ll_temp <<= PSC_COEFF_PRECISION; > ll_temp += sum >> 1; > - ll_temp /= sum; That looks like hand rolled DIV_ROUND_CLOSEST_ULL() > + ll_temp = div_s64(ll_temp, sum); > coef[phase][i] = (int)ll_temp; > } > } > -- > 2.17.1 > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Ville Syrjälä Intel
Re: [PATCH] drm/dp: For MST hub, Get max_link_rate_lane from extended rx capability field if EXTENDED_RECEIVER_CAPABILITY_FILED_PRESENT is set.
On Wed, Sep 09, 2020 at 02:26:11PM -0400, Lyude Paul wrote:
> On Wed, 2020-09-09 at 21:20 +0300, Ville Syrjälä wrote:
> > On Wed, Sep 09, 2020 at 12:33:09PM -0400, Lyude Paul wrote:
> > > We just added a new helper for DPCD retrieval to drm_dp_helper.c (which
> > > also
> > > handles grabbing the extended receiver caps), we should probably make use
> > > of
> > > it here
> >
> > Someone should really rework this whole thing so that the driver can
> > pass in the link rate+lane count when setting up the link. There's no
> > reason to assume that the source device capabilities match or exceed
> > the MST device caps. It would also allow the driver the dynamically
> > adjust these in response to link failures.
>
> I'm a bit confused, I also think we should pass the link rate+lane count in
> (especially since it'll be very helpful for when we start optimizing PBN
> handling in regards to bw constraints), but I'm not sure what you mean by
> "There's no reason to assume that the source device capabilities match or
> exceed the MST device caps", aren't we doing the opposite here by checking the
> MST device caps?
We assume only the MST device caps matter. Which is fine if the source
device caps are equal or higher. But if the source device isn't as
capable then we're going to calculate the MST things based on link bw
we can not actually achieve. End result is that we potentially try to
push too much data over the link.
I'm not really sure what actually happens if we just miscompute these
things but don't actually oversubscribe the link. Maybe the remote
end gets confused when we tell it some bogus VC parameters? Maybe it
doesn't care? Dunno.
> >
> > > On Wed, 2020-09-09 at 14:31 +0800, Koba Ko wrote:
> > > > On Thu, Aug 27, 2020 at 1:30 PM Koba Ko wrote:
> > > > > Currently, DRM get the capability of the mst hub only from DP_DPCD_REV
> > > > > and
> > > > > get the slower speed even the mst hub can run in the faster speed.
> > > > >
> > > > > As per DP-1.3, First check DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT.
> > > > > If DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT is 1, read the
> > > > > DP_DP13_DPCD_REV
> > > > > to
> > > > > get the faster capability.
> > > > > If DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT is 0, read DP_DPCD_REV.
> > > > >
> > > > > Signed-off-by: Koba Ko
> > > > > ---
> > > > > drivers/gpu/drm/drm_dp_mst_topology.c | 10 +-
> > > > > 1 file changed, 9 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > > index 67dd72ea200e..3b84c6801281 100644
> > > > > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > > @@ -3497,6 +3497,8 @@ static int drm_dp_get_vc_payload_bw(u8
> > > > > dp_link_bw,
> > > > > u8 dp_link_count)
> > > > > int drm_dp_mst_topology_mgr_set_mst(struct drm_dp_mst_topology_mgr
> > > > > *mgr,
> > > > > bool mst_state)
> > > > > {
> > > > > int ret = 0;
> > > > > + u8 dpcd_ext = 0;
> > > > > + unsigned int dpcd_offset = 0;
> > > > > struct drm_dp_mst_branch *mstb = NULL;
> > > > >
> > > > > mutex_lock(>payload_lock);
> > > > > @@ -3510,9 +3512,15 @@ int drm_dp_mst_topology_mgr_set_mst(struct
> > > > > drm_dp_mst_topology_mgr *mgr, bool ms
> > > > > struct drm_dp_payload reset_pay;
> > > > >
> > > > > WARN_ON(mgr->mst_primary);
> > > > > + drm_dp_dpcd_read(mgr->aux,
> > > > > +DP_TRAINING_AUX_RD_INTERVAL,
> > > > > +_ext, sizeof(dpcd_ext));
> > > > > +
> > > > > + dpcd_offset =
> > > > > + ((dpcd_ext &
> > > > > DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT) ? DP_DP13_DPCD_REV :
> > > > > DP_DPCD_REV);
> > > > >
> > > > > /* get dpcd info */
> > > > > - ret = drm_dp_dpcd_read(mgr->aux, DP_DPCD_REV, mgr-
> > > > > >dpcd,
> > > > > DP_RECEIVER_CAP_SIZE);
> > > > > + ret = drm_dp_dpcd_read(mgr->aux, dpcd_offset, mgr-
> > > > > >dpcd,
> > > > > DP_RECEIVER_CAP_SIZE);
> > > > > if (ret != DP_RECEIVER_CAP_SIZE) {
> > > > > DRM_DEBUG_KMS("failed to read DPCD\n");
> > > > > goto out_unlock;
> > > > > --
> > > > > 2.25.1
> > > > >
> > > > Add Lyude Paul
> > > >
> > > --
> > > Cheers,
> > > Lyude Paul (she/her)
> > > Software Engineer at Red Hat
> > >
> > > ___
> > > dri-devel mailing list
> > > dri-de...@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> --
> Cheers,
> Lyude Paul (she/her)
> Software Engineer at Red Hat
--
Ville Syrjälä
Intel
Re: [PATCH] drm/dp: For MST hub, Get max_link_rate_lane from extended rx capability field if EXTENDED_RECEIVER_CAPABILITY_FILED_PRESENT is set.
On Wed, Sep 09, 2020 at 12:33:09PM -0400, Lyude Paul wrote:
> We just added a new helper for DPCD retrieval to drm_dp_helper.c (which also
> handles grabbing the extended receiver caps), we should probably make use of
> it here
Someone should really rework this whole thing so that the driver can
pass in the link rate+lane count when setting up the link. There's no
reason to assume that the source device capabilities match or exceed
the MST device caps. It would also allow the driver the dynamically
adjust these in response to link failures.
> On Wed, 2020-09-09 at 14:31 +0800, Koba Ko wrote:
> > On Thu, Aug 27, 2020 at 1:30 PM Koba Ko wrote:
> > > Currently, DRM get the capability of the mst hub only from DP_DPCD_REV and
> > > get the slower speed even the mst hub can run in the faster speed.
> > >
> > > As per DP-1.3, First check DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT.
> > > If DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT is 1, read the DP_DP13_DPCD_REV
> > > to
> > > get the faster capability.
> > > If DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT is 0, read DP_DPCD_REV.
> > >
> > > Signed-off-by: Koba Ko
> > > ---
> > > drivers/gpu/drm/drm_dp_mst_topology.c | 10 +-
> > > 1 file changed, 9 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > index 67dd72ea200e..3b84c6801281 100644
> > > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > @@ -3497,6 +3497,8 @@ static int drm_dp_get_vc_payload_bw(u8 dp_link_bw,
> > > u8 dp_link_count)
> > > int drm_dp_mst_topology_mgr_set_mst(struct drm_dp_mst_topology_mgr *mgr,
> > > bool mst_state)
> > > {
> > > int ret = 0;
> > > + u8 dpcd_ext = 0;
> > > + unsigned int dpcd_offset = 0;
> > > struct drm_dp_mst_branch *mstb = NULL;
> > >
> > > mutex_lock(>payload_lock);
> > > @@ -3510,9 +3512,15 @@ int drm_dp_mst_topology_mgr_set_mst(struct
> > > drm_dp_mst_topology_mgr *mgr, bool ms
> > > struct drm_dp_payload reset_pay;
> > >
> > > WARN_ON(mgr->mst_primary);
> > > + drm_dp_dpcd_read(mgr->aux,
> > > +DP_TRAINING_AUX_RD_INTERVAL,
> > > +_ext, sizeof(dpcd_ext));
> > > +
> > > + dpcd_offset =
> > > + ((dpcd_ext &
> > > DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT) ? DP_DP13_DPCD_REV :
> > > DP_DPCD_REV);
> > >
> > > /* get dpcd info */
> > > - ret = drm_dp_dpcd_read(mgr->aux, DP_DPCD_REV, mgr->dpcd,
> > > DP_RECEIVER_CAP_SIZE);
> > > + ret = drm_dp_dpcd_read(mgr->aux, dpcd_offset, mgr->dpcd,
> > > DP_RECEIVER_CAP_SIZE);
> > > if (ret != DP_RECEIVER_CAP_SIZE) {
> > > DRM_DEBUG_KMS("failed to read DPCD\n");
> > > goto out_unlock;
> > > --
> > > 2.25.1
> > >
> > Add Lyude Paul
> >
> --
> Cheers,
> Lyude Paul (she/her)
> Software Engineer at Red Hat
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
Re: [PATCH]] drm/dp check aux_dev before use in drm_dp_aux_dev_get_by_minor()
gt;: mov%eax,%edx
>0x00017b78 <+104>: jmp0x17b43
>
>0x00017b7a <+106>: xor%r12d,%r12d
>0x00017b7d <+109>: jmp0x17b5a
>
> End of assembler dump.
>
> (gdb) list *drm_dp_aux_dev_get_by_minor+0x29
> 0x17b39 is in drm_dp_aux_dev_get_by_minor
> (drivers/gpu/drm/drm_dp_aux_dev.c:65).
> 60 static struct drm_dp_aux_dev *drm_dp_aux_dev_get_by_minor(unsigned
> index)
> 61 {
> 62 struct drm_dp_aux_dev *aux_dev = NULL;
> 63
> 64 mutex_lock(_idr_mutex);
> 65 aux_dev = idr_find(_idr, index);
> 66 if (!kref_get_unless_zero(_dev->refcount))
> 67 aux_dev = NULL;
> 68 mutex_unlock(_idr_mutex);
> 69
> (gdb) p/x &((struct drm_dp_aux_dev *)(0x0))->refcount
> $8 = 0x18
>
> Looking at the caller, checks on the minor are pushed down to
> drm_dp_aux_dev_get_by_minor()
>
> static int auxdev_open(struct inode *inode, struct file *file)
> {
> unsigned int minor = iminor(inode);
> struct drm_dp_aux_dev *aux_dev;
>
> aux_dev = drm_dp_aux_dev_get_by_minor(minor); <
> if (!aux_dev)
> return -ENODEV;
>
> file->private_data = aux_dev;
> return 0;
> }
>
>
> Fixes: e94cb37b34eb8 ("Add a drm_aux-dev module for reading/writing dpcd
> registers")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Zwane Mwaikambo
> ---
>
> diff --git a/drivers/gpu/drm/drm_dp_aux_dev.c
> b/drivers/gpu/drm/drm_dp_aux_dev.c
> index 2510717d5a08..e25181bf2c48 100644
> --- a/drivers/gpu/drm/drm_dp_aux_dev.c
> +++ b/drivers/gpu/drm/drm_dp_aux_dev.c
> @@ -63,7 +63,7 @@ static struct drm_dp_aux_dev
> *drm_dp_aux_dev_get_by_minor(unsigned index)
>
> mutex_lock(_idr_mutex);
> aux_dev = idr_find(_idr, index);
> - if (!kref_get_unless_zero(_dev->refcount))
> + if (aux_dev && !kref_get_unless_zero(_dev->refcount))
Dejavu
https://lists.freedesktop.org/archives/dri-devel/2019-May/218855.html
https://lists.freedesktop.org/archives/dri-devel/2019-July/226168.html
I guess we just got stuck waiting for confirmation that it reproduces
with the bogus device node trick.
> aux_dev = NULL;
> mutex_unlock(_idr_mutex);
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
Re: [PATCH] drm/vkms: add support for gamma_set interface
On Wed, Sep 02, 2020 at 09:09:11AM +, Simon Ser wrote: > On Tuesday, September 1, 2020 3:26 PM, Daniel Vetter wrote: > > > On Tue, Sep 01, 2020 at 08:57:37AM +, Simon Ser wrote: > > > > > On Monday, August 31, 2020 3:48 PM, Ville Syrjälä > > > ville.syrj...@linux.intel.com wrote: > > > > > > > > > It doesn't seem like this IGT test's goal is to exercise support for > > > > > > gamma LUTs. Does the test just tries to reset the gamma LUT to > > > > > > linear? > > > > > > If so, I think the IGT test should be fixed to ignore "I don't > > > > > > support > > > > > > gamma" errors. > > > > > > > > > > It seems like that IGT test pixel-format is to make gamma lut like > > > > > below. > > > > > for (i = 0; i < lut_size; i++) > > > > > lut[i] = (i * 0x / (lut_size - 1)) & mask; > > > > > And set this table to drm driver. and test begins. It's the test > > > > > about pixel > > > > > format. I think you're right. It's not about gamma lut. > > > > > > > > The point of the gamma LUT stuff in the pixel format test is to throw > > > > away a bunch of the lsbs so that the test passes when the result is > > > > "close enough" to the 8bpc RGB reference image. Without it we would > > > > never get a crc match when testing non-8bpc or YCbCr formats. > > > > > > OK, that makes sense. Would it be sensible to: > > > > > > - Don't set gamma if the pixel format being tested is 8bpc > > > > Hm not sure what 8bpc format you mean here, because we have C8 (needs > > gamma table or doesn't work) and the 8b greyscale one with the R8 one. If > > you ask for legacy 8bpc you get C8. > > Why do we need a gamma LUT for C8 and R8? There shouldn't be any > precision loss, right? C8 always needs a LUT. Somewhat annoying legacy uapi thing that the crtc's gamma LUT is also the LUT for C8 scanout, but at least it does match how eg. Intel hw works. I think ideally there should a separate per-plane LUT for this (with i915 then having to check that the same LUT is used for all C8 planes on the crtc). As for why we might need the LUT even for 8bpc formats. The test does the following: capture a reference CRC using XRGB for_each_format capture CRC using the format compare CRC to the reference CRC So all formats need to use the LUT to preserve the same number of msbs and throw away the unwanted lsbs. I guess we could add a special case for the "plane only supports 8bpc formats" situation and omit the LUT in that case... > > > > - Make the test skip if the pixel format is >8bpc and gamma isn't > > > supported > > > > > > > Yeah the test should skip if gamma isn't there. > > -Daniel > > > > > dri-devel mailing list > > > dri-de...@lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > -- > > > > Daniel Vetter > > Software Engineer, Intel Corporation > > http://blog.ffwll.ch > -- Ville Syrjälä Intel
Re: [PATCH] drm/dp_mst: Support remote i2c writes
eof(msg));
> + msg.req_type = DP_REMOTE_I2C_WRITE;
> + msg.u.i2c_write.port_number = port->port_num;
> + msg.u.i2c_write.write_i2c_device_id = msgs[i].addr;
> + msg.u.i2c_write.num_bytes = msgs[i].len;
> + msg.u.i2c_write.bytes = msgs[i].buf;
> +
> + memset(txmsg, 0, sizeof(*txmsg));
> + txmsg->dst = mstb;
> +
> + drm_dp_encode_sideband_req(, txmsg);
> + drm_dp_queue_down_tx(mgr, txmsg);
> +
> + ret = drm_dp_mst_wait_tx_reply(mstb, txmsg);
> + if (ret > 0) {
> + if (txmsg->reply.reply_type == DP_SIDEBAND_REPLY_NAK) {
> + ret = -EREMOTEIO;
> + goto out;
> + }
> + } else {
> + goto out;
> + }
> + }
> + ret = num;
> +out:
> + kfree(txmsg);
> + return ret;
> +}
> +
> +/* I2C device */
> +static int drm_dp_mst_i2c_xfer(struct i2c_adapter *adapter,
> +struct i2c_msg *msgs, int num)
> +{
> + struct drm_dp_aux *aux = adapter->algo_data;
> + struct drm_dp_mst_port *port =
> + container_of(aux, struct drm_dp_mst_port, aux);
> + struct drm_dp_mst_branch *mstb;
> + struct drm_dp_mst_topology_mgr *mgr = port->mgr;
> + int ret;
> +
> + mstb = drm_dp_mst_topology_get_mstb_validated(mgr, port->parent);
> + if (!mstb)
> + return -EREMOTEIO;
> +
> + if (remote_i2c_read_ok(msgs, num)) {
> + ret = drm_dp_mst_i2c_read(mstb, port, msgs, num);
> + } else if (remote_i2c_write_ok(msgs, num)) {
> + ret = drm_dp_mst_i2c_write(mstb, port, msgs, num);
> + } else {
> + DRM_DEBUG_KMS("Unsupported I2C transaction for MST device\n");
> + ret = -EIO;
> + }
> +
> drm_dp_mst_topology_put_mstb(mstb);
> return ret;
> }
> --
> 2.28.0.rc0.142.g3c755180ce-goog
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
Re: [PATCH] drm: Parse Colorimetry data block from EDID
On Fri, Aug 28, 2020 at 09:07:13AM +0800, crj wrote:
> Hi Ville Syrjälä,
>
> 在 2020/8/27 18:57, Ville Syrjälä 写道:
> > On Wed, Aug 26, 2020 at 10:23:28PM +0800, Algea Cao wrote:
> >> CEA 861.3 spec adds colorimetry data block for HDMI.
> >> Parsing the block to get the colorimetry data from
> >> panel.
> > And what exactly do you want to do with that data?
>
>
> We can get colorimetry data block from edid then support
>
> HDMI colorimetry such as BT2020.
But what do you want to do with it? The patch does nothing
functional.
>
> >> Signed-off-by: Algea Cao
> >> ---
> >>
> >> drivers/gpu/drm/drm_edid.c | 45 +
> >> include/drm/drm_connector.h | 3 +++
> >> include/drm/drm_edid.h | 14
> >> 3 files changed, 62 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> >> index 31496b6cfc56..67e607c04492 100644
> >> --- a/drivers/gpu/drm/drm_edid.c
> >> +++ b/drivers/gpu/drm/drm_edid.c
> >> @@ -3223,6 +3223,7 @@ add_detailed_modes(struct drm_connector *connector,
> >> struct edid *edid,
> >> #define VIDEO_BLOCK 0x02
> >> #define VENDOR_BLOCK0x03
> >> #define SPEAKER_BLOCK0x04
> >> +#define COLORIMETRY_DATA_BLOCK0x5
> >> #define HDR_STATIC_METADATA_BLOCK0x6
> >> #define USE_EXTENDED_TAG 0x07
> >> #define EXT_VIDEO_CAPABILITY_BLOCK 0x00
> >> @@ -4309,6 +4310,48 @@ static void fixup_detailed_cea_mode_clock(struct
> >> drm_display_mode *mode)
> >>mode->clock = clock;
> >> }
> >>
> >> +static bool cea_db_is_hdmi_colorimetry_data_block(const u8 *db)
> >> +{
> >> + if (cea_db_tag(db) != USE_EXTENDED_TAG)
> >> + return false;
> >> +
> >> + if (db[1] != COLORIMETRY_DATA_BLOCK)
> >> + return false;
> >> +
> >> + if (cea_db_payload_len(db) < 2)
> >> + return false;
> >> +
> >> + return true;
> >> +}
> >> +
> >> +static void
> >> +drm_parse_colorimetry_data_block(struct drm_connector *connector, const
> >> u8 *db)
> >> +{
> >> + struct drm_hdmi_info *info = >display_info.hdmi;
> >> +
> >> + if (db[2] & DRM_EDID_CLRMETRY_xvYCC_601)
> >> + info->colorimetry |= DRM_EDID_CLRMETRY_xvYCC_601;
> >> + if (db[2] & DRM_EDID_CLRMETRY_xvYCC_709)
> >> + info->colorimetry |= DRM_EDID_CLRMETRY_xvYCC_709;
> >> + if (db[2] & DRM_EDID_CLRMETRY_sYCC_601)
> >> + info->colorimetry |= DRM_EDID_CLRMETRY_sYCC_601;
> >> + if (db[2] & DRM_EDID_CLRMETRY_ADBYCC_601)
> >> + info->colorimetry |= DRM_EDID_CLRMETRY_ADBYCC_601;
> >> + if (db[2] & DRM_EDID_CLRMETRY_ADB_RGB)
> >> + info->colorimetry |= DRM_EDID_CLRMETRY_ADB_RGB;
> >> + if (db[2] & DRM_EDID_CLRMETRY_BT2020_CYCC)
> >> + info->colorimetry |= DRM_EDID_CLRMETRY_BT2020_CYCC;
> >> + if (db[2] & DRM_EDID_CLRMETRY_BT2020_YCC)
> >> + info->colorimetry |= DRM_EDID_CLRMETRY_BT2020_YCC;
> >> + if (db[2] & DRM_EDID_CLRMETRY_BT2020_RGB)
> >> + info->colorimetry |= DRM_EDID_CLRMETRY_BT2020_RGB;
> >> + /* Byte 4 Bit 7: DCI-P3 */
> >> + if (db[3] & BIT(7))
> >> + info->colorimetry |= DRM_EDID_CLRMETRY_DCI_P3;
> >> +
> >> + DRM_DEBUG_KMS("Supported Colorimetry 0x%x\n", info->colorimetry);
> >> +}
> >> +
> >> static bool cea_db_is_hdmi_hdr_metadata_block(const u8 *db)
> >> {
> >>if (cea_db_tag(db) != USE_EXTENDED_TAG)
> >> @@ -4994,6 +5037,8 @@ static void drm_parse_cea_ext(struct drm_connector
> >> *connector,
> >>drm_parse_vcdb(connector, db);
> >>if (cea_db_is_hdmi_hdr_metadata_block(db))
> >>drm_parse_hdr_metadata_block(connector, db);
> >> + if (cea_db_is_hdmi_colorimetry_data_block(db))
> >> + drm_parse_colorimetry_data_block(connector, db);
> >>}
> >> }
> >>
> >> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> >> index af145608b5ed..d599c3b9e881 100644
> >> --- a/include/drm/drm_connector.h
> >> +++ b/include/drm/drm_connector.h
> >> @@ -207,6 +207,9 @@ struct drm_hd
Re: [PATCH] drm/i915/lspcon: Limits to 8 bpc for RGB/YCbCr444
On Thu, Aug 27, 2020 at 01:04:54PM +0800, Kai Heng Feng wrote:
> Hi Ville,
>
> > On Aug 27, 2020, at 12:24 AM, Ville Syrjälä
> > wrote:
> >
> > On Wed, Aug 26, 2020 at 01:21:15PM +0800, Kai-Heng Feng wrote:
> >> LSPCON only supports 8 bpc for RGB/YCbCr444.
> >>
> >> Set the correct bpp otherwise it renders blank screen.
> >
> > Hmm. Does
> > git://github.com/vsyrjala/linux.git dp_downstream_ports_5
> > work?
> >
> > Actually better make that dp_downstream_ports_5^^^ aka.
> > 54d846ce62a2 ("drm/i915: Do YCbCr 444->420 conversion via DP protocol
> > converters") to avoid the experiments and hacks I have sitting on top.
>
> Can you please rebase it to mainline master or drm-tip?
git://github.com/vsyrjala/linux.git dp_downstream_ports_6
I threw out the hacks/experimental stuff.
>
> I am getting errors on the branch:
>
> DESCEND objtool
> CALLscripts/atomic/check-atomics.sh
> CALLscripts/checksyscalls.sh
> CHK include/generated/compile.h
> Building modules, stage 2.
> MODPOST 166 modules
> LD arch/x86/boot/compressed/vmlinux
> ld: arch/x86/boot/compressed/pgtable_64.o:(.bss+0x0): multiple definition of
> `__force_order'; arch/x86/boot/compressed/kaslr_64.o:(.bss+0x0): first
> defined here
> ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only
> section `.head.text'
> ld: warning: creating DT_TEXTREL in a PIE
> make[2]: *** [arch/x86/boot/compressed/Makefile:119:
> arch/x86/boot/compressed/vmlinux] Error 1
> make[1]: *** [arch/x86/boot/Makefile:113: arch/x86/boot/compressed/vmlinux]
> Error 2
> make: *** [arch/x86/Makefile:284: bzImage] Error 2
> make: *** Waiting for unfinished jobs
>
> Kai-Heng
>
> >
> >>
> >> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2195
> >> Signed-off-by: Kai-Heng Feng
> >> ---
> >> drivers/gpu/drm/i915/display/intel_lspcon.c | 3 ++-
> >> 1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c
> >> b/drivers/gpu/drm/i915/display/intel_lspcon.c
> >> index b781bf469644..c7a44fcaade8 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_lspcon.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
> >> @@ -196,7 +196,8 @@ void lspcon_ycbcr420_config(struct drm_connector
> >> *connector,
> >> crtc_state->port_clock /= 2;
> >>crtc_state->output_format = INTEL_OUTPUT_FORMAT_YCBCR444;
> >>crtc_state->lspcon_downsampling = true;
> >> - }
> >> + } else
> >> + crtc_state->pipe_bpp = 24;
> >> }
> >>
> >> static bool lspcon_probe(struct intel_lspcon *lspcon)
> >> --
> >> 2.17.1
> >
> > --
> > Ville Syrjälä
> > Intel
--
Ville Syrjälä
Intel
Re: [PATCH] drm/vkms: add support for gamma_set interface
On Mon, Aug 31, 2020 at 01:38:58PM +, Sidong Yang wrote:
> On Mon, Aug 31, 2020 at 11:39:10AM +, Simon Ser wrote:
> > On Saturday, August 29, 2020 4:06 PM, Sidong Yang
> > wrote:
> >
> > > Currently vkms module doesn't support gamma function for userspace. so igt
> > > subtests in kms_plane(pixel-format-pipe-A-plan) failed for calling
> > > drmModeCrtcSetGamma().
> >
>
> Hi, Simon.
> Thanks for review.
>
> > It doesn't seem like this IGT test's goal is to exercise support for
> > gamma LUTs. Does the test just tries to reset the gamma LUT to linear?
> > If so, I think the IGT test should be fixed to ignore "I don't support
> > gamma" errors.
>
> It seems like that IGT test pixel-format is to make gamma lut like below.
>
> for (i = 0; i < lut_size; i++)
> lut[i] = (i * 0x / (lut_size - 1)) & mask;
>
> And set this table to drm driver. and test begins. It's the test about pixel
> format. I think you're right. It's not about gamma lut.
The point of the gamma LUT stuff in the pixel format test is to throw
away a bunch of the lsbs so that the test passes when the result is
"close enough" to the 8bpc RGB reference image. Without it we would
never get a crc match when testing non-8bpc or YCbCr formats.
> >
> > > This patch set gamma_set interface in vkms_crtc_funcs for
> > > support gamma function. With initializing crtc, added calls for setting
> > > gamma
> > > size. it pass the test after this patch.
> > >
> > > Cc: Daniel Vetter
> > > Cc: Rodrigo Siqueira
> > > Cc: Haneen Mohammed
> > >
> > > Signed-off-by: Sidong Yang
> > > ---
> > > drivers/gpu/drm/vkms/vkms_crtc.c | 8
> > > 1 file changed, 8 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c
> > > b/drivers/gpu/drm/vkms/vkms_crtc.c
> > > index ac85e17428f8..643435fb2ee6 100644
> > > --- a/drivers/gpu/drm/vkms/vkms_crtc.c
> > > +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> > > @@ -160,6 +160,7 @@ static const struct drm_crtc_funcs vkms_crtc_funcs = {
> > > .get_crc_sources= vkms_get_crc_sources,
> > > .set_crc_source = vkms_set_crc_source,
> > > .verify_crc_source = vkms_verify_crc_source,
> > > + .gamma_set = drm_atomic_helper_legacy_gamma_set,
> >
> > Why does VKMS need to use a legacy helper?
>
> drm_crtc_enable_color_mgmt() enables properties about gamma/degamma lut. And
> legacy helper just saves lut data from userspace to drm property blob. It
> seems
> that it's convenient way to implement .gamma_set.
>
> > It seems like this patch just advertises support for gamma LUTs, but
> > ignores any value set by user-space. If VKMS advertises support for
> > gamma LUTs, it needs to take the LUT into account when blending planes.
>
> Yes, This patch doesn't use gamma lut passed by user. lut should be used for
> calculating pixel value. For vkms, Maybe lut will be used in making crc value?
> If so, I'll try to write next patch for it.
>
> Thanks,
> -Sidong
>
> >
> > > };
> > >
> > > static int vkms_crtc_atomic_check(struct drm_crtc *crtc,
> > > @@ -275,6 +276,13 @@ int vkms_crtc_init(struct drm_device *dev, struct
> > > drm_crtc *crtc,
> > > return ret;
> > > }
> > >
> > > + ret = drm_mode_crtc_set_gamma_size(crtc, 256);
> > > + if (ret) {
> > > + DRM_ERROR("Failed to set gamma size\n");
> > > + return ret;
> > > + }
> > > + drm_crtc_enable_color_mgmt(crtc, 0, false, 256);
> > > +
> > > drm_crtc_helper_add(crtc, _crtc_helper_funcs);
> > >
> > > spin_lock_init(_out->lock);
> > > --
> > > 2.17.1
> >
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH] drm/i915/vlv_dsi_pll: fix spelling mistake "Cant" -> "Can't"
On Mon, Aug 10, 2020 at 10:59:52AM +0100, Colin King wrote:
> From: Colin Ian King
>
> There is a spelling mistake in a drm_err message. Fix it.
Thanks. Applied to dinq.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/i915/display/vlv_dsi_pll.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/vlv_dsi_pll.c
> b/drivers/gpu/drm/i915/display/vlv_dsi_pll.c
> index d0a514301575..4070b00c3690 100644
> --- a/drivers/gpu/drm/i915/display/vlv_dsi_pll.c
> +++ b/drivers/gpu/drm/i915/display/vlv_dsi_pll.c
> @@ -483,7 +483,7 @@ int bxt_dsi_pll_compute(struct intel_encoder *encoder,
>
> if (dsi_ratio < dsi_ratio_min || dsi_ratio > dsi_ratio_max) {
> drm_err(_priv->drm,
> - "Cant get a suitable ratio from DSI PLL ratios\n");
> + "Can't get a suitable ratio from DSI PLL ratios\n");
> return -ECHRNG;
> } else
> drm_dbg_kms(_priv->drm, "DSI PLL calculation is Done!!\n");
> --
> 2.27.0
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
Re: [PATCH] drm: Parse Colorimetry data block from EDID
On Wed, Aug 26, 2020 at 10:23:28PM +0800, Algea Cao wrote:
> CEA 861.3 spec adds colorimetry data block for HDMI.
> Parsing the block to get the colorimetry data from
> panel.
And what exactly do you want to do with that data?
>
> Signed-off-by: Algea Cao
> ---
>
> drivers/gpu/drm/drm_edid.c | 45 +
> include/drm/drm_connector.h | 3 +++
> include/drm/drm_edid.h | 14
> 3 files changed, 62 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 31496b6cfc56..67e607c04492 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -3223,6 +3223,7 @@ add_detailed_modes(struct drm_connector *connector,
> struct edid *edid,
> #define VIDEO_BLOCK 0x02
> #define VENDOR_BLOCK0x03
> #define SPEAKER_BLOCK0x04
> +#define COLORIMETRY_DATA_BLOCK 0x5
> #define HDR_STATIC_METADATA_BLOCK0x6
> #define USE_EXTENDED_TAG 0x07
> #define EXT_VIDEO_CAPABILITY_BLOCK 0x00
> @@ -4309,6 +4310,48 @@ static void fixup_detailed_cea_mode_clock(struct
> drm_display_mode *mode)
> mode->clock = clock;
> }
>
> +static bool cea_db_is_hdmi_colorimetry_data_block(const u8 *db)
> +{
> + if (cea_db_tag(db) != USE_EXTENDED_TAG)
> + return false;
> +
> + if (db[1] != COLORIMETRY_DATA_BLOCK)
> + return false;
> +
> + if (cea_db_payload_len(db) < 2)
> + return false;
> +
> + return true;
> +}
> +
> +static void
> +drm_parse_colorimetry_data_block(struct drm_connector *connector, const u8
> *db)
> +{
> + struct drm_hdmi_info *info = >display_info.hdmi;
> +
> + if (db[2] & DRM_EDID_CLRMETRY_xvYCC_601)
> + info->colorimetry |= DRM_EDID_CLRMETRY_xvYCC_601;
> + if (db[2] & DRM_EDID_CLRMETRY_xvYCC_709)
> + info->colorimetry |= DRM_EDID_CLRMETRY_xvYCC_709;
> + if (db[2] & DRM_EDID_CLRMETRY_sYCC_601)
> + info->colorimetry |= DRM_EDID_CLRMETRY_sYCC_601;
> + if (db[2] & DRM_EDID_CLRMETRY_ADBYCC_601)
> + info->colorimetry |= DRM_EDID_CLRMETRY_ADBYCC_601;
> + if (db[2] & DRM_EDID_CLRMETRY_ADB_RGB)
> + info->colorimetry |= DRM_EDID_CLRMETRY_ADB_RGB;
> + if (db[2] & DRM_EDID_CLRMETRY_BT2020_CYCC)
> + info->colorimetry |= DRM_EDID_CLRMETRY_BT2020_CYCC;
> + if (db[2] & DRM_EDID_CLRMETRY_BT2020_YCC)
> + info->colorimetry |= DRM_EDID_CLRMETRY_BT2020_YCC;
> + if (db[2] & DRM_EDID_CLRMETRY_BT2020_RGB)
> + info->colorimetry |= DRM_EDID_CLRMETRY_BT2020_RGB;
> + /* Byte 4 Bit 7: DCI-P3 */
> + if (db[3] & BIT(7))
> + info->colorimetry |= DRM_EDID_CLRMETRY_DCI_P3;
> +
> + DRM_DEBUG_KMS("Supported Colorimetry 0x%x\n", info->colorimetry);
> +}
> +
> static bool cea_db_is_hdmi_hdr_metadata_block(const u8 *db)
> {
> if (cea_db_tag(db) != USE_EXTENDED_TAG)
> @@ -4994,6 +5037,8 @@ static void drm_parse_cea_ext(struct drm_connector
> *connector,
> drm_parse_vcdb(connector, db);
> if (cea_db_is_hdmi_hdr_metadata_block(db))
> drm_parse_hdr_metadata_block(connector, db);
> + if (cea_db_is_hdmi_colorimetry_data_block(db))
> + drm_parse_colorimetry_data_block(connector, db);
> }
> }
>
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index af145608b5ed..d599c3b9e881 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -207,6 +207,9 @@ struct drm_hdmi_info {
>
> /** @y420_dc_modes: bitmap of deep color support index */
> u8 y420_dc_modes;
> +
> + /* @colorimetry: bitmap of supported colorimetry modes */
> + u16 colorimetry;
> };
>
> /**
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index cfa4f5af49af..98fa78c2f82d 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -229,6 +229,20 @@ struct detailed_timing {
> DRM_EDID_YCBCR420_DC_36 | \
> DRM_EDID_YCBCR420_DC_30)
>
> +/*
> + * Supported Colorimetry from colorimetry data block
> + * as per CEA 861-G spec
> + */
> +#define DRM_EDID_CLRMETRY_xvYCC_601 (1 << 0)
> +#define DRM_EDID_CLRMETRY_xvYCC_709 (1 << 1)
> +#define DRM_EDID_CLRMETRY_sYCC_601(1 << 2)
> +#define DRM_EDID_CLRMETRY_ADBYCC_601 (1 << 3)
> +#define DRM_EDID_CLRMETRY_ADB_RGB (1 << 4)
> +#define DRM_EDID_CLRMETRY_BT2020_CYCC (1 << 5)
> +#define DRM_EDID_CLRMETRY_BT2020_YCC (1 << 6)
> +#define DRM_EDID_CLRMETRY_BT2020_RGB (1 << 7)
> +#define DRM_EDID_CLRMETRY_DCI_P3 (1 << 15)
> +
> /* ELD Header Block */
> #define DRM_ELD_HEADER_BLOCK_SIZE4
>
> --
> 2.25.1
>
>
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
Re: [PATCH] drm/i915/lspcon: Limits to 8 bpc for RGB/YCbCr444
On Wed, Aug 26, 2020 at 01:21:15PM +0800, Kai-Heng Feng wrote:
> LSPCON only supports 8 bpc for RGB/YCbCr444.
>
> Set the correct bpp otherwise it renders blank screen.
Hmm. Does
git://github.com/vsyrjala/linux.git dp_downstream_ports_5
work?
Actually better make that dp_downstream_ports_5^^^ aka.
54d846ce62a2 ("drm/i915: Do YCbCr 444->420 conversion via DP protocol
converters") to avoid the experiments and hacks I have sitting on top.
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2195
> Signed-off-by: Kai-Heng Feng
> ---
> drivers/gpu/drm/i915/display/intel_lspcon.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c
> b/drivers/gpu/drm/i915/display/intel_lspcon.c
> index b781bf469644..c7a44fcaade8 100644
> --- a/drivers/gpu/drm/i915/display/intel_lspcon.c
> +++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
> @@ -196,7 +196,8 @@ void lspcon_ycbcr420_config(struct drm_connector
> *connector,
> crtc_state->port_clock /= 2;
> crtc_state->output_format = INTEL_OUTPUT_FORMAT_YCBCR444;
> crtc_state->lspcon_downsampling = true;
> - }
> + } else
> + crtc_state->pipe_bpp = 24;
> }
>
> static bool lspcon_probe(struct intel_lspcon *lspcon)
> --
> 2.17.1
--
Ville Syrjälä
Intel
Re: [PATCH -next] gpu: drm: Fix spinlock vblank_time_lock use error.
On Wed, Jul 22, 2020 at 01:05:27AM +, Xu Qiang wrote:
> The drm_handle_vblank function is in the interrupt context.
> Therefore, the spin lock vblank_time_lock is obtained
> from the interrupt context.
>
> Cc:
> Signed-off-by: Xu Qiang
> ---
> drivers/gpu/drm/drm_vblank.c | 17 ++---
> 1 file changed, 10 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> index f402c75b9d34..4ca63ff33a43 100644
> --- a/drivers/gpu/drm/drm_vblank.c
> +++ b/drivers/gpu/drm/drm_vblank.c
> @@ -229,10 +229,11 @@ static void drm_reset_vblank_timestamp(struct
> drm_device *dev, unsigned int pipe
> {
> u32 cur_vblank;
> bool rc;
> + unsigned long irqflags;
> ktime_t t_vblank;
> int count = DRM_TIMESTAMP_MAXRETRIES;
>
> - spin_lock(>vblank_time_lock);
> + spin_lock_irqsave(>vblank_time_lock, irqflags);
Nak. This is always called with interrupts off, so no point on wasting
time saving/restoring the flags. And it's the same situation for all the
other cases you have below.
>
> /*
>* sample the current counter to avoid random jumps
> @@ -257,7 +258,7 @@ static void drm_reset_vblank_timestamp(struct drm_device
> *dev, unsigned int pipe
>*/
> store_vblank(dev, pipe, 1, t_vblank, cur_vblank);
>
> - spin_unlock(>vblank_time_lock);
> + spin_unlock_irqrestore(>vblank_time_lock, irqflags);
> }
>
> /*
> @@ -1106,11 +1107,12 @@ static int __enable_vblank(struct drm_device *dev,
> unsigned int pipe)
> static int drm_vblank_enable(struct drm_device *dev, unsigned int pipe)
> {
> struct drm_vblank_crtc *vblank = >vblank[pipe];
> + unsigned long irqflags;
> int ret = 0;
>
> assert_spin_locked(>vbl_lock);
>
> - spin_lock(>vblank_time_lock);
> + spin_lock_irqsave(>vblank_time_lock, irqflags);
>
> if (!vblank->enabled) {
> /*
> @@ -1136,7 +1138,7 @@ static int drm_vblank_enable(struct drm_device *dev,
> unsigned int pipe)
> }
> }
>
> - spin_unlock(>vblank_time_lock);
> + spin_unlock_irqrestore(>vblank_time_lock, irqflags);
>
> return ret;
> }
> @@ -1917,6 +1919,7 @@ bool drm_handle_vblank(struct drm_device *dev, unsigned
> int pipe)
> {
> struct drm_vblank_crtc *vblank = >vblank[pipe];
> unsigned long irqflags;
> + unsigned long irqflags_vblank;
> bool disable_irq;
>
> if (drm_WARN_ON_ONCE(dev, !drm_dev_has_vblank(dev)))
> @@ -1931,18 +1934,18 @@ bool drm_handle_vblank(struct drm_device *dev,
> unsigned int pipe)
>* vblank enable/disable, as this would cause inconsistent
>* or corrupted timestamps and vblank counts.
>*/
> - spin_lock(>vblank_time_lock);
> + spin_lock_irqsave(>vblank_time_lock, irqflags_vblank);
>
> /* Vblank irq handling disabled. Nothing to do. */
> if (!vblank->enabled) {
> - spin_unlock(>vblank_time_lock);
> + spin_unlock_irqrestore(>vblank_time_lock, irqflags_vblank);
> spin_unlock_irqrestore(>event_lock, irqflags);
> return false;
> }
>
> drm_update_vblank_count(dev, pipe, true);
>
> - spin_unlock(>vblank_time_lock);
> + spin_unlock_irqrestore(>vblank_time_lock, irqflags_vblank);
>
> wake_up(>queue);
>
> --
> 2.25.0
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
Re: Warning triggered in drm_dp_delayed_destroy_work workqueue
On Fri, Jun 26, 2020 at 03:40:20PM +0200, Daniel Vetter wrote:
> Adding Lyude, she's been revamping all the lifetime refcouting in the
> dp code last few kernel releases. At a glance I don't even have an
> idea what's going wrong here ...
Already fixed by Imre I believe.
7d11507605a7 ("drm/dp_mst: Fix the DDC I2C device unregistration of an MST
port")
> -Daniel
>
> On Thu, Jun 25, 2020 at 12:22 PM Luis Henriques wrote:
> >
> > Hi!
> >
> > I've been seeing this warning occasionally, not sure if it has been
> > reported yet. It's not a regression as I remember seeing it in, at least,
> > 5.7.
> >
> > Anyway, here it is:
> >
> > [ cut here ]
> > sysfs group 'power' not found for kobject 'i2c-7'
> > WARNING: CPU: 1 PID: 17996 at fs/sysfs/group.c:279
> > sysfs_remove_group+0x74/0x80
> > Modules linked in: ccm(E) dell_rbtn(E) iwlmvm(E) mei_wdt(E) mac80211(E)
> > libarc4(E) uvcvideo(E) dell_laptop(E) videobuf2_vmalloc(E) intel_rapl_>
> > soundcore(E) intel_soc_dts_iosf(E) rng_core(E) battery(E) acpi_pad(E)
> > sparse_keymap(E) acpi_thermal_rel(E) intel_pch_thermal(E) int3402_therm>
> > sysfillrect(E) intel_lpss(E) sysimgblt(E) fb_sys_fops(E) idma64(E)
> > scsi_mod(E) virt_dma(E) mfd_core(E) drm(E) fan(E) thermal(E) i2c_hid(E) hi>
> > CPU: 1 PID: 17996 Comm: kworker/1:1 Tainted: GE 5.8.0-rc2+
> > #36
> > Hardware name: Dell Inc. Precision 5510/0N8J4R, BIOS 1.14.2 05/25/2020
> > Workqueue: events drm_dp_delayed_destroy_work [drm_kms_helper]
> > RIP: 0010:sysfs_remove_group+0x74/0x80
> > Code: ff 5b 48 89 ef 5d 41 5c e9 79 bc ff ff 48 89 ef e8 01 b8 ff ff eb cc
> > 49 8b 14 24 48 8b 33 48 c7 c7 90 ac 8b 93 e8 de b1 d4 ff <0f> 0b 5b>
> > RSP: :b12d40c13c38 EFLAGS: 00010282
> > RAX: RBX: 936e6a60 RCX: 0027
> > RDX: 0027 RSI: 0086 RDI: 8e37de097b68
> > RBP: R08: 8e37de097b60 R09: 93fb4624
> > R10: 0904 R11: 0001002c R12: 8e37d3081c18
> > R13: 8e375f1450a8 R14: R15: 8e375f145410
> > FS: () GS:8e37de08() knlGS:
> > CS: 0010 DS: ES: CR0: 80050033
> > CR2: CR3: 0004ab20a001 CR4: 003606e0
> > DR0: DR1: DR2:
> > DR3: DR6: fffe0ff0 DR7: 0400
> > Call Trace:
> > device_del+0x97/0x3f0
> > cdev_device_del+0x15/0x30
> > put_i2c_dev+0x7b/0x90 [i2c_dev]
> > i2cdev_detach_adapter+0x33/0x60 [i2c_dev]
> > notifier_call_chain+0x47/0x70
> > blocking_notifier_call_chain+0x3d/0x60
> > device_del+0x8f/0x3f0
> > device_unregister+0x16/0x60
> > i2c_del_adapter+0x247/0x300
> > drm_dp_port_set_pdt+0x90/0x2c0 [drm_kms_helper]
> > drm_dp_delayed_destroy_work+0x2be/0x340 [drm_kms_helper]
> > process_one_work+0x1ae/0x370
> > worker_thread+0x50/0x3a0
> > ? process_one_work+0x370/0x370
> > kthread+0x11b/0x140
> > ? kthread_associate_blkcg+0x90/0x90
> > ret_from_fork+0x22/0x30
> > ---[ end trace 16486ad3c2627482 ]---
> > [ cut here ]
> >
> > Cheers,
> > --
> > Luis
>
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
Re: [PATCH] drm/edid: add support for min horizontal rate equal to max horizontal rate
On Thu, Jun 18, 2020 at 12:58:33AM +0800, Cyrus Lien wrote: > On Tue, Jun 9, 2020 at 10:58 PM Ville Syrjälä > wrote: > > > On Tue, Jun 09, 2020 at 03:57:04AM +0800, Cyrus Lien wrote: > > > According to EDID spec, table 3.26, byte #6 and #8, which said "Minimum > > > rate value shall be less than or equal to maximum rate value". The > > minimum > > > horizontal/vertical rate value is able to be equal to maximum horizontal/ > > > veritcal rate value. > > > > How does that justifiy ignoring the min value? > > > > Indeed, this patch does not make sense. > Setting minimum horizontal rate equal to maximum horizontal rate is a > request come from AMD Windows graphic driver for support freesync (I'm not > sure if linux AMD driver also require it). AFAICS the DP spec itself doesn't say anything about the horizontal min/max rates. However DP-EDID-CTS 1.2 / 4.8 seems to say that hmin==hmax==hsync should hold. Not sure if that should be the hsync rate of the min/max/nominal refresh rate. I would have maybe expected the max since that's the actual rate it's going operate at. Alhtough I even less of an idea what it should be if the monitor supports multiple resolutions. In this case it doesn't seem to be any of those exactly. Pretty close to the min refresh rate though. hmin=hmax=110 kHz vs. actual hsync rate for 50Hz would be 111.1 kHz (if it was actually running at 50Hz with the declared vblank length which it won't be of course). If we calculate in the opposite direction we get a vrefresh of ~49.5 Hz based on the 110 kHz hsync rate. So if we round to nearest integer it does match the declared vmin of 50Hz. I suspect the right answer is to just ignore hmin/hmax when it comes to adaptive sync. > The problem is mode_in_hsync_range always return false except the mode's > hsync exactly equal to hmax and hmin. > > Add print in mode_in_hsync_range(): > [drm] mode_in_hsync_range 1920x1200: hsync: 94, hmax: 110, hmix:110 > [drm] mode_in_hsync_range 1920x1200: hsync: 107, hmax: 110, hmix:110 > [drm] mode_in_hsync_range 1920x1200: hsync: 152, hmax: 110, hmix:110 > [drm] mode_in_hsync_range 1920x1440: hsync: 90, hmax: 110, hmix:110 > [drm] mode_in_hsync_range 1920x1440: hsync: 113, hmax: 110, hmix:110 > [drm] mode_in_hsync_range 1920x1440: hsync: 183, hmax: 110, hmix:110 > > Is it available to get or calculate the hmax, hmix value from other fields > in EDID ? > Would you please provide some advice or directions to solve this problem ? > Thank you and appreciated the help. > > edid-decode (hex): > > 00 ff ff ff ff ff ff 00 06 af 9b 32 00 00 00 00 > 00 1e 01 04 b5 26 15 78 03 1f 95 a5 53 35 b5 26 > 0f 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 > 01 01 01 01 01 01 70 d0 00 a0 f0 70 3e 80 30 20 > 35 00 7d d6 10 00 00 1a 00 00 00 fd 00 32 5a 6e > 6e 17 01 11 01 e0 60 20 50 3c 00 00 00 fe 00 34 > 34 54 52 4e 15 42 31 37 33 5a 41 4e 00 00 00 00 > 00 05 81 01 28 00 12 00 00 0b 01 0a 20 20 01 af > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > > > EDID version: 1.4 > Manufacturer: AUO Model 12955 Serial Number 0 > Made in year 2020 > Digital display > 10 bits per primary color channel > DisplayPort interface > Maximum image size: 38 cm x 21 cm > Gamma: 2.20 > Supported color formats: RGB 4:4:4 > First detailed timing includes the native pixel format and preferred > refresh rate > Display is continuous frequency > Color Characteristics > Red: 0.6445, 0.3251 > Green: 0.2099, 0.7099 > Blue: 0.1503, 0.0595 > White: 0.3134, 0.3291 > Established Timings I & II: none > Standard Timings: none > Detailed mode: Clock 533.600 MHz, 381 mm x 214 mm >3840 3888 3920 4000 ( 48 32 80) >2160 2163 2168 ( 3 5 54) >+hsync -vsync >VertFreq: 60.036 Hz, HorFreq: 133.400 kHz > Display Range Limits > Monitor ranges (Bare Limits): 50-90 Hz V, 110-110 kHz H, max dotclock 230 > MHz > Alphanumeric Data String: 44TRN > Manufacturer-Specified Display Descriptor (0x00): 00 00 00 05 81 01 28 00 > 12 00 00 0b 01 0a 20 20 ..(... > Has 1 extension block > Checksum: 0xaf > > > > > > > > This change check if h/v-sync excess maximum horizontal/vertical rate if > > > hmin equal to hmax or vmin equal to vmax. > > >
Re: [PATCH v2 5/5] drm/tegra: plane: Support 180° rotation
On Sun, Jun 14, 2020 at 11:01:21PM +0300, Dmitry Osipenko wrote:
> Combining horizontal and vertical reflections gives us 180 degrees of
> rotation.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/gpu/drm/tegra/dc.c | 13 -
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
> index f31bca27cde4..ddd9b88f8fce 100644
> --- a/drivers/gpu/drm/tegra/dc.c
> +++ b/drivers/gpu/drm/tegra/dc.c
> @@ -608,6 +608,7 @@ static int tegra_plane_atomic_check(struct drm_plane
> *plane,
> {
> struct tegra_plane_state *plane_state = to_tegra_plane_state(state);
> unsigned int rotation = DRM_MODE_ROTATE_0 |
> + DRM_MODE_ROTATE_180 |
Leave this out ...
> DRM_MODE_REFLECT_X |
> DRM_MODE_REFLECT_Y;
> struct tegra_bo_tiling *tiling = _state->tiling;
> @@ -659,6 +660,14 @@ static int tegra_plane_atomic_check(struct drm_plane
> *plane,
> else
> plane_state->reflect_y = false;
>
> + if (tegra_fb_is_bottom_up(state->fb))
> + plane_state->reflect_y = true;
> +
> + if (rotation & DRM_MODE_ROTATE_180) {
> + plane_state->reflect_x = !plane_state->reflect_x;
> + plane_state->reflect_y = !plane_state->reflect_y;
> + }
... and drm_rotation_simplify() will do this for you.
Though the bottim_up() thing will need a slightly different tweak I
guess.
I'd write this as somehting like:
rotation = state->rotation;
if (bottom_up())
rotation ^= DRM_MODE_REFLECT_Y;
rotation = drm_rotation_simplify(rotation,
DRM_MODE_ROTATE_0 |
DRM_MODE_REFLECT_X |
DRM_MODE_REFLECT_Y;
Also note my use of XOR for the bottom_up() handling. I suspect
the current code is already broken if you combine bottom_up()
and REFLECT_Y since it just uses an OR instead of an XOR. That's
assuming my hucnh what bottom_up() is supposed to do is correct.
> +
> /*
>* Tegra doesn't support different strides for U and V planes so we
>* error out if the user tries to display a framebuffer with such a
> @@ -720,7 +729,7 @@ static void tegra_plane_atomic_update(struct drm_plane
> *plane,
> window.dst.h = drm_rect_height(>state->dst);
> window.bits_per_pixel = fb->format->cpp[0] * 8;
> window.reflect_x = state->reflect_x;
> - window.reflect_y = tegra_fb_is_bottom_up(fb) || state->reflect_y;
> + window.reflect_y = state->reflect_y;
>
> /* copy from state */
> window.zpos = plane->state->normalized_zpos;
> @@ -806,6 +815,7 @@ static struct drm_plane
> *tegra_primary_plane_create(struct drm_device *drm,
> err = drm_plane_create_rotation_property(>base,
>DRM_MODE_ROTATE_0,
>DRM_MODE_ROTATE_0 |
> + DRM_MODE_ROTATE_180 |
>DRM_MODE_REFLECT_X |
>DRM_MODE_REFLECT_Y);
> if (err < 0)
> @@ -1094,6 +1104,7 @@ static struct drm_plane
> *tegra_dc_overlay_plane_create(struct drm_device *drm,
> err = drm_plane_create_rotation_property(>base,
>DRM_MODE_ROTATE_0,
>DRM_MODE_ROTATE_0 |
> + DRM_MODE_ROTATE_180 |
>DRM_MODE_REFLECT_X |
> DRM_MODE_REFLECT_Y);
> if (err < 0)
> --
> 2.26.0
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
Re: [PATCH] drm/edid: add support for min horizontal rate equal to max horizontal rate
On Tue, Jun 09, 2020 at 03:57:04AM +0800, Cyrus Lien wrote: > According to EDID spec, table 3.26, byte #6 and #8, which said "Minimum > rate value shall be less than or equal to maximum rate value". The minimum > horizontal/vertical rate value is able to be equal to maximum horizontal/ > veritcal rate value. How does that justifiy ignoring the min value? > > This change check if h/v-sync excess maximum horizontal/vertical rate if > hmin equal to hmax or vmin equal to vmax. > > Signed-off-by: Cyrus Lien > --- > drivers/gpu/drm/drm_edid.c | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c > index fed653f13c26..23878320eabd 100644 > --- a/drivers/gpu/drm/drm_edid.c > +++ b/drivers/gpu/drm/drm_edid.c > @@ -2674,6 +2674,9 @@ mode_in_hsync_range(const struct drm_display_mode *mode, > hmax += ((t[4] & 0x08) ? 255 : 0); > hsync = drm_mode_hsync(mode); > > + if (hmax == hmin) > + return (hsync <= hmax); > + > return (hsync <= hmax && hsync >= hmin); > } > > @@ -2691,6 +2694,9 @@ mode_in_vsync_range(const struct drm_display_mode *mode, > vmax += ((t[4] & 0x02) ? 255 : 0); > vsync = drm_mode_vrefresh(mode); > > + if (vmax == vmin) > + return (vsync <= vmax); > + > return (vsync <= vmax && vsync >= vmin); > } > > -- > 2.25.1 > > _______ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Ville Syrjälä Intel
Re: Re:[PATCH] drm: fix setting of plane_mask in pan_display_atomic() function for linux-4.4
On Wed, May 27, 2020 at 09:33:27PM +0800, chenxb_99...@126.com wrote: > From: Xuebing Chen > > On Mon, May 25, 2020 at 04:34:28PM +0200, Daniel Vetter wrote: > > On Sat, May 23, 2020 at 11:49:07AM +0800, chenxb_99...@126.com wrote: > > > From: Xuebing Chen > > > > > > The provides drm_for_each_plane_mask macro and > > > plane_mask is defined as bitmask of plane indices, such as > > > 1< > > in pan_display_atomic() function. > > > > > > Signed-off-by: Xuebing Chen > > > > What kernel is this patch against? Latest upstream doesn't have any such > > code anymore ... I'm assuming that Ville fixed this in one of his patches, > > but I can't find the right one just now. > > This bug is still present in the longterm-supported versions of kernel 4.4.y, > including the latest kernel v4.4.224, > See > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/?h=v4.4.224 See Documentation/process/stable-kernel-rules.rst on how to request a stable backport. -- Ville Syrjälä Intel
Re: [PATCH] drm: fix setting of plane_mask in pan_display_atomic() function for linux-4.4
On Mon, May 25, 2020 at 04:34:28PM +0200, Daniel Vetter wrote:
> On Sat, May 23, 2020 at 11:49:07AM +0800, chenxb_99...@126.com wrote:
> > From: Xuebing Chen
> >
> > The provides drm_for_each_plane_mask macro and
> > plane_mask is defined as bitmask of plane indices, such as
> > 1< > in pan_display_atomic() function.
> >
> > Signed-off-by: Xuebing Chen
>
> What kernel is this patch against? Latest upstream doesn't have any such
> code anymore ... I'm assuming that Ville fixed this in one of his patches,
> but I can't find the right one just now.
Looks to be gone in
commit e00fb8564ee9 ("drm: Stop updating plane->crtc/fb/old_fb on
atomic drivers"), in 2018.
Also seems this 1<< bug was already fixed in
commit 7118fd9bd975 ("drm/fb-helper: Use proper plane mask for fb
cleanup") ... in 2015!
Might be a good idea to invest in an upgrade if you're still using
such old kernel releases.
> -Daniel
>
> > ---
> > drivers/gpu/drm/drm_fb_helper.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_fb_helper.c
> > b/drivers/gpu/drm/drm_fb_helper.c
> > index e449f22..6a9f7ee 100644
> > --- a/drivers/gpu/drm/drm_fb_helper.c
> > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > @@ -1256,7 +1256,7 @@ retry:
> > goto fail;
> >
> > plane = mode_set->crtc->primary;
> > - plane_mask |= drm_plane_index(plane);
> > + plane_mask |= 1 << drm_plane_index(plane);
> > plane->old_fb = plane->fb;
> > }
> >
> > --
> > 2.7.4
> >
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
Re: [PATCH] drm/i915: Don't enable WaIncreaseLatencyIPCEnabled when IPC is disabled
On Thu, Apr 30, 2020 at 02:46:54PM -0700, Sultan Alsawaf wrote:
> From: Sultan Alsawaf
>
> In commit 5a7d202b1574, a logical AND was erroneously changed to an OR,
> causing WaIncreaseLatencyIPCEnabled to be enabled unconditionally for
> kabylake and coffeelake, even when IPC is disabled. Fix the logic so
> that WaIncreaseLatencyIPCEnabled is only used when IPC is enabled.
>
> Fixes: 5a7d202b1574 ("drm/i915: Drop WaIncreaseLatencyIPCEnabled/1140 for
> cnl")
> Cc: sta...@vger.kernel.org # 5.3.x+
> Signed-off-by: Sultan Alsawaf
> ---
> drivers/gpu/drm/i915/intel_pm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 8375054ba27d..a52986a9e7a6 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -4992,7 +4992,7 @@ static void skl_compute_plane_wm(const struct
> intel_crtc_state *crtc_state,
>* WaIncreaseLatencyIPCEnabled: kbl,cfl
>* Display WA #1141: kbl,cfl
>*/
> - if ((IS_KABYLAKE(dev_priv) || IS_COFFEELAKE(dev_priv)) ||
> + if ((IS_KABYLAKE(dev_priv) || IS_COFFEELAKE(dev_priv)) &&
Whoops. Thanks for the fix. Pushed.
> dev_priv->ipc_enabled)
> latency += 4;
>
> --
> 2.26.2
--
Ville Syrjälä
Intel
Re: [PATCH] Remove drm_display_mode.hsync
On Tue, Apr 28, 2020 at 05:18:13PM +0200, Daniel Vetter wrote:
> On Mon, Apr 27, 2020 at 10:05:17AM +0200, Michal Orzel wrote:
> > As suggested by the TODO list of DRM subsystem:
> > -remove the member hsync of drm_display_mode
> > -convert code using hsync member to use drm_mode_hsync()
> >
> > Signed-off-by: Michal Orzel
>
> I think Ville has a bunch of patches doing this, we might have some
> overlap :-/ Adding Ville.
>
> Please sync with him and get either of these patches reviewed.
Yeah, I have the same thing (+ making the function static). I think
my series is sufficiently reviewed to get most of it pushed. Just need
to get it past the ci... which apparently means I get to do another
rebase.
>
> Thanks, Daniel
>
> > ---
> > drivers/gpu/drm/drm_modes.c | 6 +-
> > drivers/gpu/drm/i915/display/intel_display.c | 1 -
> > include/drm/drm_modes.h | 10 --
> > 3 files changed, 1 insertion(+), 16 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> > index d4d6451..0340079 100644
> > --- a/drivers/gpu/drm/drm_modes.c
> > +++ b/drivers/gpu/drm/drm_modes.c
> > @@ -752,16 +752,12 @@ EXPORT_SYMBOL(drm_mode_set_name);
> > * @mode: mode
> > *
> > * Returns:
> > - * @modes's hsync rate in kHz, rounded to the nearest integer. Calculates
> > the
> > - * value first if it is not yet set.
> > + * @modes's hsync rate in kHz, rounded to the nearest integer.
> > */
> > int drm_mode_hsync(const struct drm_display_mode *mode)
> > {
> > unsigned int calc_val;
> >
> > - if (mode->hsync)
> > - return mode->hsync;
> > -
> > if (mode->htotal <= 0)
> > return 0;
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 3468466..ec7e943 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -8891,7 +8891,6 @@ void intel_mode_from_pipe_config(struct
> > drm_display_mode *mode,
> >
> > mode->clock = pipe_config->hw.adjusted_mode.crtc_clock;
> >
> > - mode->hsync = drm_mode_hsync(mode);
> > mode->vrefresh = drm_mode_vrefresh(mode);
> > drm_mode_set_name(mode);
> > }
> > diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
> > index 99134d4..7dab7f1 100644
> > --- a/include/drm/drm_modes.h
> > +++ b/include/drm/drm_modes.h
> > @@ -391,16 +391,6 @@ struct drm_display_mode {
> > int vrefresh;
> >
> > /**
> > -* @hsync:
> > -*
> > -* Horizontal refresh rate, for debug output in human readable form. Not
> > -* used in a functional way.
> > -*
> > -* This value is in kHz.
> > -*/
> > - int hsync;
> > -
> > - /**
> > * @picture_aspect_ratio:
> > *
> > * Field for setting the HDMI picture aspect ratio of a mode.
> > --
> > 2.7.4
> >
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Ville Syrjälä
Intel
Re: [PATCH v2 1/3] drm: Add some new format DRM_FORMAT_NVXX_10
On Tue, Oct 08, 2019 at 10:40:20AM +0800, sandy.huang wrote:
> Hi ville syrjala,
>
> 在 2019/9/30 下午6:48, Ville Syrjälä 写道:
> > On Thu, Sep 26, 2019 at 04:24:47PM +0800, Sandy Huang wrote:
> >> These new format is supported by some rockchip socs:
> >>
> >> DRM_FORMAT_NV12_10/DRM_FORMAT_NV21_10
> >> DRM_FORMAT_NV16_10/DRM_FORMAT_NV61_10
> >> DRM_FORMAT_NV24_10/DRM_FORMAT_NV42_10
> >>
> >> Signed-off-by: Sandy Huang
> >> ---
> >> drivers/gpu/drm/drm_fourcc.c | 18 ++
> >> include/uapi/drm/drm_fourcc.h | 14 ++
> >> 2 files changed, 32 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> >> index c630064..ccd78a3 100644
> >> --- a/drivers/gpu/drm/drm_fourcc.c
> >> +++ b/drivers/gpu/drm/drm_fourcc.c
> >> @@ -261,6 +261,24 @@ const struct drm_format_info *__drm_format_info(u32
> >> format)
> >>{ .format = DRM_FORMAT_P016,.depth = 0,
> >> .num_planes = 2,
> >> .char_per_block = { 2, 4, 0 }, .block_w = { 1, 0, 0 },
> >> .block_h = { 1, 0, 0 },
> >> .hsub = 2, .vsub = 2, .is_yuv = true},
> >> + { .format = DRM_FORMAT_NV12_10, .depth = 0,
> >> .num_planes = 2,
> >> +.char_per_block = { 5, 10, 0 }, .block_w = { 4, 4, 0 },
> >> .block_h = { 4, 4, 0 },
> >> +.hsub = 2, .vsub = 2, .is_yuv = true},
> >> + { .format = DRM_FORMAT_NV21_10, .depth = 0,
> >> .num_planes = 2,
> >> +.char_per_block = { 5, 10, 0 }, .block_w = { 4, 4, 0 },
> >> .block_h = { 4, 4, 0 },
> >> +.hsub = 2, .vsub = 2, .is_yuv = true},
> >> + { .format = DRM_FORMAT_NV16_10, .depth = 0,
> >> .num_planes = 2,
> >> +.char_per_block = { 5, 10, 0 }, .block_w = { 4, 4, 0 },
> >> .block_h = { 4, 4, 0 },
> >> +.hsub = 2, .vsub = 1, .is_yuv = true},
> >> + { .format = DRM_FORMAT_NV61_10, .depth = 0,
> >> .num_planes = 2,
> >> +.char_per_block = { 5, 10, 0 }, .block_w = { 4, 4, 0 },
> >> .block_h = { 4, 4, 0 },
> >> +.hsub = 2, .vsub = 1, .is_yuv = true},
> >> + { .format = DRM_FORMAT_NV24_10, .depth = 0,
> >> .num_planes = 2,
> >> +.char_per_block = { 5, 10, 0 }, .block_w = { 4, 4, 0 },
> >> .block_h = { 4, 4, 0 },
> >> +.hsub = 1, .vsub = 1, .is_yuv = true},
> >> + { .format = DRM_FORMAT_NV42_10, .depth = 0,
> >> .num_planes = 2,
> >> +.char_per_block = { 5, 10, 0 }, .block_w = { 4, 4, 0 },
> >> .block_h = { 4, 4, 0 },
> >> +.hsub = 1, .vsub = 1, .is_yuv = true},
> >>{ .format = DRM_FORMAT_P210,.depth = 0,
> >> .num_planes = 2, .char_per_block = { 2, 4, 0 },
> >> .block_w = { 1, 0, 0 }, .block_h = { 1, 0, 0 }, .hsub = 2,
> >> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> >> index 3feeaa3..08e2221 100644
> >> --- a/include/uapi/drm/drm_fourcc.h
> >> +++ b/include/uapi/drm/drm_fourcc.h
> >> @@ -238,6 +238,20 @@ extern "C" {
> >> #define DRM_FORMAT_NV42 fourcc_code('N', 'V', '4', '2') /*
> >> non-subsampled Cb:Cr plane */
> >>
> >> /*
> >> + * 2 plane YCbCr
> >> + * index 0 = Y plane, Y3:Y2:Y1:Y0 10:10:10:10
> >> + * index 1 = Cb:Cr plane, Cb3:Cr3:Cb2:Cr2:Cb1:Cr1:Cb0:Cr0
> >> 10:10:10:10:10:10:10:10
> >> + * or
> >> + * index 1 = Cr:Cb plane, Cr3:Cb3:Cr2:Cb2:Cr1:Cb1:Cr0:Cb0
> >> 10:10:10:10:10:10:10:10
> > So now you're defining it as some kind of byte aligned block.
> > With that specifying endianness would now make sense since
> > otherwise this tells us absolutely nothing about the memory
> > layout.
> >
> > So I'd either do that, or go back to not specifying anything and
> > use some weasel words like "mamory layout is implementation defined"
> > which of course means no one can use it for anything that involves
> > any kind of cross vendor stuff.
> /*
> * 2 plane YCbCr
> * index 0 = Y plane, [39: 0] Y3:Y2:Y1:Y0 10:10:10:10 little endian
> * index 1 = Cb:Cr plane, [79: 0] Cb3:Cr3:Cb2:Cr2:Cb1:Cr1:Cb0:Cr0
> 10:10:10:10:10:10:10:10 little endian
> * or
> * index 1 = Cr:Cb plane, [79: 0] Cr3:Cb3:Cr2:Cb2:C
Re: [PATCH] cpufreq: Fix RCU reboot regression on x86 PIC machines
On Thu, Oct 03, 2019 at 05:05:28PM +0200, Rafael J. Wysocki wrote:
> On Thursday, October 3, 2019 4:08:28 PM CEST Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Since 4.20-rc1 my PIC machines no longer reboot/shutdown.
> > I bisected this down to commit 45975c7d21a1 ("rcu: Define RCU-sched
> > API in terms of RCU for Tree RCU PREEMPT builds").
> >
> > I traced the hang into
> > -> cpufreq_suspend()
> > -> cpufreq_stop_governor()
> > -> cpufreq_dbs_governor_stop()
> >-> gov_clear_update_util()
> > -> synchronize_sched()
> > -> synchronize_rcu()
> >
> > Only PREEMPT=y is affected for obvious reasons. The problem
> > is limited to PIC machines since they mask off interrupts
> > in i8259A_shutdown() (syscore_ops.shutdown() registered
> > from device_initcall()).
>
> Let me treat this as a fresh bug report. :-)
>
> > I reported this long ago but no better fix has surfaced,
>
> So I don't recall seeing the original report or if I did, I had not understood
> the problem then.
>
> > hence sending out my initial workaround which I've been
> > carrying around ever since. I just move cpufreq_core_init()
> > to late_initcall() so the syscore_ops get registered in the
> > oppsite order and thus the .shutdown() hooks get executed
> > in the opposite order as well. Not 100% convinced this is
> > safe (especially moving the cpufreq_global_kobject creation
> > to late_initcall()) but I've not had any problems with it
> > at least.
>
> The problem is a bug in cpufreq that shouldn't point its syscore shutdown
> callback pointer to cpufreq_suspend(), because the syscore stage is generally
> too lat to call that function and I'm not sure why this has not been causing
> any other issues to trigger (or maybe it did, but they were not reported).
>
> Does the patch below work for you?
It does. Thanks.
Feel free to slap on
Tested-by: Ville Syrjälä
if you want to go with that.
>
> ---
> drivers/base/core.c |3 +++
> drivers/cpufreq/cpufreq.c | 10 --
> 2 files changed, 3 insertions(+), 10 deletions(-)
>
> Index: linux-pm/drivers/cpufreq/cpufreq.c
> ===
> --- linux-pm.orig/drivers/cpufreq/cpufreq.c
> +++ linux-pm/drivers/cpufreq/cpufreq.c
> @@ -2737,14 +2737,6 @@ int cpufreq_unregister_driver(struct cpu
> }
> EXPORT_SYMBOL_GPL(cpufreq_unregister_driver);
>
> -/*
> - * Stop cpufreq at shutdown to make sure it isn't holding any locks
> - * or mutexes when secondary CPUs are halted.
> - */
> -static struct syscore_ops cpufreq_syscore_ops = {
> - .shutdown = cpufreq_suspend,
> -};
> -
> struct kobject *cpufreq_global_kobject;
> EXPORT_SYMBOL(cpufreq_global_kobject);
>
> @@ -2756,8 +2748,6 @@ static int __init cpufreq_core_init(void
> cpufreq_global_kobject = kobject_create_and_add("cpufreq",
> _subsys.dev_root->kobj);
> BUG_ON(!cpufreq_global_kobject);
>
> - register_syscore_ops(_syscore_ops);
> -
> return 0;
> }
> module_param(off, int, 0444);
> Index: linux-pm/drivers/base/core.c
> ===
> --- linux-pm.orig/drivers/base/core.c
> +++ linux-pm/drivers/base/core.c
> @@ -9,6 +9,7 @@
> */
>
> #include
> +#include
> #include
> #include
> #include
> @@ -3179,6 +3180,8 @@ void device_shutdown(void)
> wait_for_device_probe();
> device_block_probing();
>
> + cpufreq_suspend();
> +
> spin_lock(_kset->list_lock);
> /*
>* Walk the devices list backward, shutting down each in turn.
>
>
--
Ville Syrjälä
Intel
Re: [PATCH v3 5/5] RFC: drm/atomic-helper: Reapply color transformation after resume
On Mon, Sep 30, 2019 at 07:28:02PM -0300, Ezequiel Garcia wrote:
> Some platforms are not able to maintain the color transformation
> state after a system suspend/resume cycle.
>
> Set the colog_mgmt_changed flag so that CMM on the CRTCs in
> the suspend state are reapplied after system resume.
>
> Signed-off-by: Ezequiel Garcia
> ---
> This is an RFC, and it's mostly based on Jacopo Mondi's work
> https://lkml.org/lkml/2019/9/6/498.
>
> Changes from v2:
> * New patch.
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index e41db0f202ca..518488125575 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -3234,8 +3234,20 @@ int drm_atomic_helper_resume(struct drm_device *dev,
>struct drm_atomic_state *state)
> {
> struct drm_modeset_acquire_ctx ctx;
> + struct drm_crtc_state *crtc_state;
> + struct drm_crtc *crtc;
> + unsigned int i;
> int err;
>
> + for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
> + /*
> + * Force re-enablement of CMM after system resume if any
> + * of the DRM color transformation properties was set in
> + * the state saved at system suspend time.
> + */
> + if (crtc_state->gamma_lut)
You say "any" but you check the one?
> + crtc_state->color_mgmt_changed = true;
But I'm not convinced this is the best way to go about it.
I would generally expect that you repgrogram everything
when doing a full modeset since the state was possibly
lost while the crtc was disabled.
> + }
> drm_mode_config_reset(dev);
>
> DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 0, err);
> --
> 2.22.0
>
> _______
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
Re: Follow up on hid2hci: Fix udev rules for linux-4.14+
On Wed, Aug 28, 2019 at 08:50:51PM +0300, Ville Syrjälä wrote: > On Wed, Aug 28, 2019 at 01:34:07PM -0400, Dan Streetman wrote: > > It looks like this patch got lost at some point: > > https://lore.kernel.org/patchwork/patch/902126/#1138115 > > > > but it seems to still be a problem and I'd like to pull it into Ubuntu: > > https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1759836 > > > > Ville, did you ever follow up with a v2 for that patch and/or do you > > know if it will be accepted soon? > > There's a more recent version of that somewhere on the mailing list. > The problem is getting someone to actually apply it. Seems much harder > than it should be... https://lore.kernel.org/patchwork/patch/1021109/ > > And IIRC I also posted a few other fixes for hid2hci tool which didn't > get any response from the crowd. https://www.spinics.net/lists/linux-bluetooth/msg79803.html -- Ville Syrjälä Intel
Re: Follow up on hid2hci: Fix udev rules for linux-4.14+
On Wed, Aug 28, 2019 at 01:34:07PM -0400, Dan Streetman wrote: > It looks like this patch got lost at some point: > https://lore.kernel.org/patchwork/patch/902126/#1138115 > > but it seems to still be a problem and I'd like to pull it into Ubuntu: > https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1759836 > > Ville, did you ever follow up with a v2 for that patch and/or do you > know if it will be accepted soon? There's a more recent version of that somewhere on the mailing list. The problem is getting someone to actually apply it. Seems much harder than it should be... And IIRC I also posted a few other fixes for hid2hci tool which didn't get any response from the crowd. -- Ville Syrjälä Intel
Re: [PATCH] drm/msm/dpu: add rotation property
On Wed, Aug 21, 2019 at 06:57:24PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> index 45bfac9e3af7..c5653771e8fa 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> @@ -1040,8 +1040,21 @@ static void dpu_plane_sspp_atomic_update(struct
> drm_plane *plane)
> pstate->multirect_mode);
>
> if (pdpu->pipe_hw->ops.setup_format) {
> + unsigned int rotation;
> +
> src_flags = 0x0;
>
> + rotation = drm_rotation_simplify(state->rotation,
> + DRM_MODE_ROTATE_0 |
> + DRM_MODE_REFLECT_X |
> + DRM_MODE_REFLECT_Y);
> +
> + if (rotation & DRM_MODE_REFLECT_X)
> + src_flags |= DPU_SSPP_FLIP_UD;
> +
> + if (rotation & DRM_MODE_REFLECT_Y)
> + src_flags |= DPU_SSPP_FLIP_LR;
> +
UD vs. LR (assuming those mean what I think they mean) seem the wrong
way around here.
>
> /* update format */
> pdpu->pipe_hw->ops.setup_format(pdpu->pipe_hw, fmt, src_flags,
> pstate->multirect_index);
> @@ -1522,6 +1535,13 @@ struct drm_plane *dpu_plane_init(struct drm_device
> *dev,
> if (ret)
> DPU_ERROR("failed to install zpos property, rc = %d\n", ret);
>
> + drm_plane_create_rotation_property(plane,
> + DRM_MODE_ROTATE_0,
> + DRM_MODE_ROTATE_0 |
> + DRM_MODE_ROTATE_180 |
> + DRM_MODE_REFLECT_X |
> + DRM_MODE_REFLECT_Y);
> +
> drm_plane_enable_fb_damage_clips(plane);
>
> /* success! finalize initialization */
> --
> 2.21.0
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
Re: [PATCH -next] drm/i915: Remove set but not used variable 'encoder'
On Fri, Jul 05, 2019 at 11:31:12AM +, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/i915/display/intel_dp.c: In function
> 'intel_dp_set_drrs_state':
> drivers/gpu/drm/i915/display/intel_dp.c:6623:24: warning:
> variable 'encoder' set but not used [-Wunused-but-set-variable]
>
> It's never used, so can be removed.Also remove related
> variable 'dig_port'
>
> Signed-off-by: YueHaibing
Applied to drm-intel-next-queued. Thanks for the patch.
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 5 -
> 1 file changed, 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 8f7188d71d08..0bdb7ecc5a81 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -6620,8 +6620,6 @@ static void intel_dp_set_drrs_state(struct
> drm_i915_private *dev_priv,
> const struct intel_crtc_state *crtc_state,
> int refresh_rate)
> {
> - struct intel_encoder *encoder;
> - struct intel_digital_port *dig_port = NULL;
> struct intel_dp *intel_dp = dev_priv->drrs.dp;
> struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state->base.crtc);
> enum drrs_refresh_rate_type index = DRRS_HIGH_RR;
> @@ -6636,9 +6634,6 @@ static void intel_dp_set_drrs_state(struct
> drm_i915_private *dev_priv,
> return;
> }
>
> - dig_port = dp_to_dig_port(intel_dp);
> - encoder = _port->base;
> -
> if (!intel_crtc) {
> DRM_DEBUG_KMS("DRRS: intel_crtc not initialized\n");
> return;
>
>
--
Ville Syrjälä
Intel
Re: [PATCH -next] drm/i915: Remove set but not used variable 'intel_dig_port'
On Fri, Jul 05, 2019 at 11:31:38AM +, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/i915/display/intel_ddi.c: In function 'intel_ddi_get_config':
> drivers/gpu/drm/i915/display/intel_ddi.c:3774:29: warning:
> variable 'intel_dig_port' set but not used [-Wunused-but-set-variable]
> struct intel_digital_port *intel_dig_port;
>
> It is never used, so can be removed.
>
> Signed-off-by: YueHaibing
Applied to drm-intel-next-queued. Thanks for the patch.
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index a4172595c8d8..30e48609db1d 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -3771,7 +3771,6 @@ void intel_ddi_get_config(struct intel_encoder *encoder,
> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> struct intel_crtc *intel_crtc = to_intel_crtc(pipe_config->base.crtc);
> enum transcoder cpu_transcoder = pipe_config->cpu_transcoder;
> - struct intel_digital_port *intel_dig_port;
> u32 temp, flags = 0;
>
> /* XXX: DSI transcoder paranoia */
> @@ -3810,7 +3809,6 @@ void intel_ddi_get_config(struct intel_encoder *encoder,
> switch (temp & TRANS_DDI_MODE_SELECT_MASK) {
> case TRANS_DDI_MODE_SELECT_HDMI:
> pipe_config->has_hdmi_sink = true;
> - intel_dig_port = enc_to_dig_port(>base);
>
> pipe_config->infoframes.enable |=
> intel_hdmi_infoframes_enabled(encoder, pipe_config);
>
>
--
Ville Syrjälä
Intel
Re: [PATCH] drm/komeda: Added AFBC support for komeda driver
On Fri, May 24, 2019 at 11:10:09AM +, Brian Starkey wrote:
> Hi,
>
> On Tue, May 21, 2019 at 09:45:58AM +0100, james qian wang (Arm Technology
> China) wrote:
> > On Thu, May 16, 2019 at 09:57:49PM +0800, Ayan Halder wrote:
> > > On Thu, Apr 04, 2019 at 12:06:14PM +0100, james qian wang (Arm Technology
> > > China) wrote:
> > > >
> > > > +static int
> > > > +komeda_fb_afbc_size_check(struct komeda_fb *kfb, struct drm_file *file,
> > > > + const struct drm_mode_fb_cmd2 *mode_cmd)
> > > > +{
> > > > + struct drm_framebuffer *fb = >base;
> > > > + const struct drm_format_info *info = fb->format;
> > > > + struct drm_gem_object *obj;
> > > > + u32 alignment_w = 0, alignment_h = 0, alignment_header;
> > > > + u32 n_blocks = 0, min_size = 0;
> > > > +
> > > > + obj = drm_gem_object_lookup(file, mode_cmd->handles[0]);
> > > > + if (!obj) {
> > > > + DRM_DEBUG_KMS("Failed to lookup GEM object\n");
> > > > + return -ENOENT;
> > > > + }
> > > > +
> > > > + switch (fb->modifier & AFBC_FORMAT_MOD_BLOCK_SIZE_MASK) {
> > > > + case AFBC_FORMAT_MOD_BLOCK_SIZE_32x8:
> > > > + alignment_w = 32;
> > > > + alignment_h = 8;
> > > > + break;
> > > > + case AFBC_FORMAT_MOD_BLOCK_SIZE_16x16:
> > > > + alignment_w = 16;
> > > > + alignment_h = 16;
> > > > + break;
> > > > + default:
> > > Can we have something like a warn here ?
> >
> > will add a WARN here.
> >
>
> I think it's better not to. fb->modifier comes from
> userspace, so a malicious app could spam us with WARNs, effectively
> dos-ing the system. -EINVAL should be sufficient.
Should probably check that the entire modifier+format is
actually valid. Otherwise you risk passing on a bogus
modifier deeper into the driver which may trigger
interesting bugs.
Also theoretically (however unlikely) some broken userspace
might start to depend on the ability to create framebuffers
with crap modifiers, which could later break if you change
the way you handle the modifiers. Then you're stuck between
the rock and hard place because you can't break existing
userspace but you still want to change the way modifiers
are handled in the kernel.
Best not give userspace too much rope IMO. Two ways to go about
that:
1) drm_any_plane_has_format() (assumes your .format_mod_supported()
does its job properly)
2) roll your own
--
Ville Syrjälä
Intel
Re: [REGRESSION 4.20-rc1] 45975c7d21a1 ("rcu: Define RCU-sched API in terms of RCU for Tree RCU PREEMPT builds")
On Mon, Nov 26, 2018 at 02:01:22PM -0800, Paul E. McKenney wrote:
> On Wed, Nov 14, 2018 at 12:20:13PM -0800, Paul E. McKenney wrote:
> > On Tue, Nov 13, 2018 at 07:10:37AM -0800, Paul E. McKenney wrote:
> > > On Tue, Nov 13, 2018 at 03:54:53PM +0200, Ville Syrjälä wrote:
> > > > Hi Paul,
> > > >
> > > > After 4.20-rc1 some of my 32bit UP machines no longer reboot/shutdown.
> > > > I bisected this down to commit 45975c7d21a1 ("rcu: Define RCU-sched
> > > > API in terms of RCU for Tree RCU PREEMPT builds").
> > > >
> > > > I traced the hang into
> > > > -> cpufreq_suspend()
> > > > -> cpufreq_stop_governor()
> > > > -> cpufreq_dbs_governor_stop()
> > > >-> gov_clear_update_util()
> > > > -> synchronize_sched()
> > > > -> synchronize_rcu()
> > > >
> > > > Only PREEMPT=y is affected for obvious reasons, but that couldn't
> > > > explain why the same UP kernel booted on an SMP machine worked fine.
> > > > Eventually I realized that the difference between working and
> > > > non-working machine was IOAPIC vs. PIC. With initcall_debug I saw
> > > > that we mask everything in the PIC before cpufreq is shut down,
> > > > and came up with the following fix:
> > > >
> > > > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> > > > index 7aa3dcad2175..f88bf3c77fc0 100644
> > > > --- a/drivers/cpufreq/cpufreq.c
> > > > +++ b/drivers/cpufreq/cpufreq.c
> > > > @@ -2605,4 +2605,4 @@ static int __init cpufreq_core_init(void)
> > > > return 0;
> > > > }
> > > > module_param(off, int, 0444);
> > > > -core_initcall(cpufreq_core_init);
> > > > +late_initcall(cpufreq_core_init);
> > >
> > > Thank you for testing this and tracking it down!
> > >
> > > I am glad that you have a fix, but I hope that we can arrive at a less
> > > constraining one.
> > >
> > > > Here's the resulting change in inutcall_debug:
> > > > pci :00:00.1: shutdown
> > > > hub 4-0:1.0: hub_ext_port_status failed (err = -110)
> > > > agpgart-intel :00:00.0: shutdown
> > > > + PM: Calling cpufreq_suspend+0x0/0x100
> > > > PM: Calling mce_syscore_shutdown+0x0/0x10
> > > > PM: Calling i8259A_shutdown+0x0/0x10
> > > > - PM: Calling cpufreq_suspend+0x0/0x100
> > > > + reboot: Restarting system
> > > > + reboot: machine restart
> > > >
> > > > I didn't really look into what other ramifications the cpufreq
> > > > initcall change might have. cpufreq_global_kobject worries
> > > > me a bit. Maybe that one has to remain in core_initcall() and
> > > > we could just move the suspend to late_initcall()? Anyways,
> > > > I figured I'd leave this for someone more familiar with the
> > > > code to figure out ;)
> > >
> > > Let me guess...
> > >
> > > When the system suspends or shuts down, there comes a point after which
> > > there is only a single CPU that is running with preemption and interrupts
> > > are disabled. At this point, RCU must change the way that it works, and
> > > the commit you bisected to would make the change more necessary. But if
> > > I am guessing correctly, we have just been getting lucky in the past.
> > >
> > > It looks like RCU needs to create a struct syscore_ops with a shutdown
> > > function and pass this to register_syscore_ops(). Maybe a suspend
> > > function as well. And RCU needs to invoke register_syscore_ops() at
> > > a time that causes RCU's shutdown function to be invoked in the right
> > > order with respect to the other work in flight. The hope would be that
> > > RCU's suspend function gets called just as the system transitions into
> > > a mode where the scheduler is no longer active, give or take.
> > >
> > > Does this make sense, or am I confused?
> >
> > Well, it certainly does not make sense in that blocking is still legal
> > at .shutdown() invocation time, which means that RCU cannot revert to
> > its boot-time approach at that point. Looks like I need hooks in a
> > bunch of arch-dependent functions. Which is certainly doable, but will
> > take a bit more digging.
>
> A bit more detail, after some additional discussion at Linux Plumbers
> conference...
>
> T
Re: [PATCH] drm/vkms: Solve bug on kms_crc_cursor tests
On Fri, Mar 01, 2019 at 03:35:35PM -0300, Shayenne Moura wrote:
> Em sex, 1 de mar de 2019 às 12:26, Ville Syrjälä
> escreveu:
> >
> > On Fri, Mar 01, 2019 at 11:55:11AM -0300, Shayenne Moura wrote:
> > > Em qui, 28 de fev de 2019 às 11:03, Ville Syrjälä
> > > escreveu:
> > > >
> > > > On Thu, Feb 28, 2019 at 11:11:07AM +0100, Daniel Vetter wrote:
> > > > > On Mon, Feb 25, 2019 at 11:26:06AM -0300, Shayenne Moura wrote:
> > > > > > vkms_crc_work_handle needs the value of the actual frame to
> > > > > > schedule the workqueue that calls periodically the vblank
> > > > > > handler and the destroy state functions. However, the frame
> > > > > > value returned from vkms_vblank_simulate is updated and
> > > > > > diminished in vblank_get_timestamp because it is not in a
> > > > > > vblank interrupt, and return an inaccurate value.
> > > > > >
> > > > > > Solve this getting the actual vblank frame directly from the
> > > > > > vblank->count inside the `struct drm_crtc`, instead of using
> > > > > > the `drm_accurate_vblank_count` function.
> > > > > >
> > > > > > Signed-off-by: Shayenne Moura
> > > > >
> > > > > Sorry for the delay, I'm a bit swamped right now :-/
> > > > >
> > > > > Debug work you're doing here is really impressive! But I have no idea
> > > > > what's going on. It doesn't look like it's just papering over a bug
> > > > > (like
> > > > > the in_vblank_irq check we've discussed on irc), but I also have no
> > > > > idea
> > > > > why it works.
> > > > >
> > > > > I'll pull in Ville, he understands this better than me.
> > > >
> > > > It's not entirely clear what we're trying to fix. From what I can see
> > > > the crc work seems to be in no way synchronized with page flips, so
> > > > I'm not sure how all this is really supposed to work.
> > > >
> > >
> > > Hi, Ville!
> > >
> > > Thank you for the review! :)
> > >
> > > I do not understand well what crc code is doing, but the issue that I
> > > found
> > > is related to the vblank timestamp and frame count.
> > >
> > > When vkms handles the crc_cursor it uses the start frame and end frame
> > > values to verify if it needs to call the function
> > > 'drm_crtc_add_crc_entry()'
> > > for each frame.
> > >
> > > However, when getting the frame count, the code is calling the function
> > > drm_update_vblank_count(dev, pipe, false) and, because of the 'false',
> > > subtracting the actual vblank timestamp (consequently, the frame count
> > > value), causing conflicts.
> >
> > The in_vblank_irq behavour looks sane to me. What are these conflicts?
> >
>
> The entire history was:
> - I sent the patch with bugfix for vblank extra frame. The patch changed
>our function vkms_get_vblank_timestamp() to look like this:
>
> bool vkms_get_vblank_timestamp(struct drm_device *dev, unsigned int pipe,
>int *max_error, ktime_t *vblank_time,
>bool in_vblank_irq)
> {
> struct vkms_device *vkmsdev = drm_device_to_vkms_device(dev);
> struct vkms_output *output = >output;
>
> *vblank_time = output->vblank_hrtimer.node.expires;
>
> + if (!in_vblank_irq)
> +*vblank_time -= output->period_ns;
>
> return true;
> }
>
> - This patch solve the issue that I was looking for (extra vblank
> frames on kms_flip).
>
> - However, kms_cursor_crc tests, which passed before my patch, started to
> fail.
>
> - Debugging them, I found that the problem was inside of function
> `vkms_vblank_simulate()`
> when it was handling the crc_enabled (inside if (state &&
> output->crc_enabled))
> and inside the function vkms_crc_work_handle() too.
>
> - Following the steps:
> 1. Inside vkms_vblank_simulate() we call drm_crtc_accurate_vblank_count()
> 2. In its turn, drm_crtc_accurate_vblank_count() calls the function
>drm_update_vblank_count(dev, pipe, false). /* This false is default */
> 3. Finally, the “false” used in drm_update_vblank_count(), will be
> passed to vkms_get_vblank_timestamp() and the condition “if
> (!in_vblank_irq)” will be executed multiple times (we don’t want it).
>
> - Inside vkms_crc, the issue is that the returned frame value change fo
Re: [PATCH] drm/vkms: Solve bug on kms_crc_cursor tests
On Fri, Mar 01, 2019 at 11:55:11AM -0300, Shayenne Moura wrote: > Em qui, 28 de fev de 2019 às 11:03, Ville Syrjälä > escreveu: > > > > On Thu, Feb 28, 2019 at 11:11:07AM +0100, Daniel Vetter wrote: > > > On Mon, Feb 25, 2019 at 11:26:06AM -0300, Shayenne Moura wrote: > > > > vkms_crc_work_handle needs the value of the actual frame to > > > > schedule the workqueue that calls periodically the vblank > > > > handler and the destroy state functions. However, the frame > > > > value returned from vkms_vblank_simulate is updated and > > > > diminished in vblank_get_timestamp because it is not in a > > > > vblank interrupt, and return an inaccurate value. > > > > > > > > Solve this getting the actual vblank frame directly from the > > > > vblank->count inside the `struct drm_crtc`, instead of using > > > > the `drm_accurate_vblank_count` function. > > > > > > > > Signed-off-by: Shayenne Moura > > > > > > Sorry for the delay, I'm a bit swamped right now :-/ > > > > > > Debug work you're doing here is really impressive! But I have no idea > > > what's going on. It doesn't look like it's just papering over a bug (like > > > the in_vblank_irq check we've discussed on irc), but I also have no idea > > > why it works. > > > > > > I'll pull in Ville, he understands this better than me. > > > > It's not entirely clear what we're trying to fix. From what I can see > > the crc work seems to be in no way synchronized with page flips, so > > I'm not sure how all this is really supposed to work. > > > > Hi, Ville! > > Thank you for the review! :) > > I do not understand well what crc code is doing, but the issue that I found > is related to the vblank timestamp and frame count. > > When vkms handles the crc_cursor it uses the start frame and end frame > values to verify if it needs to call the function 'drm_crtc_add_crc_entry()' > for each frame. > > However, when getting the frame count, the code is calling the function > drm_update_vblank_count(dev, pipe, false) and, because of the 'false', > subtracting the actual vblank timestamp (consequently, the frame count > value), causing conflicts. The in_vblank_irq behavour looks sane to me. What are these conflicts? > > Does it make sense? I am not sure about this crc code behavior. > > Shayenne > > > > -Daniel > > > > > > > --- > > > > drivers/gpu/drm/vkms/vkms_crc.c | 4 +++- > > > > drivers/gpu/drm/vkms/vkms_crtc.c | 4 +++- > > > > 2 files changed, 6 insertions(+), 2 deletions(-) > > > > > > > > diff --git a/drivers/gpu/drm/vkms/vkms_crc.c > > > > b/drivers/gpu/drm/vkms/vkms_crc.c > > > > index d7b409a3c0f8..09a8b00ef1f1 100644 > > > > --- a/drivers/gpu/drm/vkms/vkms_crc.c > > > > +++ b/drivers/gpu/drm/vkms/vkms_crc.c > > > > @@ -161,6 +161,8 @@ void vkms_crc_work_handle(struct work_struct *work) > > > > struct vkms_output *out = drm_crtc_to_vkms_output(crtc); > > > > struct vkms_device *vdev = container_of(out, struct vkms_device, > > > > output); > > > > + unsigned int pipe = drm_crtc_index(crtc); > > > > + struct drm_vblank_crtc *vblank = >dev->vblank[pipe]; > > > > struct vkms_crc_data *primary_crc = NULL; > > > > struct vkms_crc_data *cursor_crc = NULL; > > > > struct drm_plane *plane; > > > > @@ -196,7 +198,7 @@ void vkms_crc_work_handle(struct work_struct *work) > > > > if (primary_crc) > > > > crc32 = _vkms_get_crc(primary_crc, cursor_crc); > > > > > > > > - frame_end = drm_crtc_accurate_vblank_count(crtc); > > > > + frame_end = vblank->count; > > > > > > > > /* queue_work can fail to schedule crc_work; add crc for > > > > * missing frames > > > > diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c > > > > b/drivers/gpu/drm/vkms/vkms_crtc.c > > > > index 8a9aeb0a9ea8..9bf3268e2e92 100644 > > > > --- a/drivers/gpu/drm/vkms/vkms_crtc.c > > > > +++ b/drivers/gpu/drm/vkms/vkms_crtc.c > > > > @@ -10,6 +10,8 @@ static enum hrtimer_restart > > > > vkms_vblank_simulate(struct hrtimer *timer) > > > > vblank_hrtimer); > > > > struct drm_crtc *crtc = >crtc; > > > > struct vkms_crtc_state *state = t
Re: [PATCH] drm/vkms: Solve bug on kms_crc_cursor tests
On Thu, Feb 28, 2019 at 11:11:07AM +0100, Daniel Vetter wrote:
> On Mon, Feb 25, 2019 at 11:26:06AM -0300, Shayenne Moura wrote:
> > vkms_crc_work_handle needs the value of the actual frame to
> > schedule the workqueue that calls periodically the vblank
> > handler and the destroy state functions. However, the frame
> > value returned from vkms_vblank_simulate is updated and
> > diminished in vblank_get_timestamp because it is not in a
> > vblank interrupt, and return an inaccurate value.
> >
> > Solve this getting the actual vblank frame directly from the
> > vblank->count inside the `struct drm_crtc`, instead of using
> > the `drm_accurate_vblank_count` function.
> >
> > Signed-off-by: Shayenne Moura
>
> Sorry for the delay, I'm a bit swamped right now :-/
>
> Debug work you're doing here is really impressive! But I have no idea
> what's going on. It doesn't look like it's just papering over a bug (like
> the in_vblank_irq check we've discussed on irc), but I also have no idea
> why it works.
>
> I'll pull in Ville, he understands this better than me.
It's not entirely clear what we're trying to fix. From what I can see
the crc work seems to be in no way synchronized with page flips, so
I'm not sure how all this is really supposed to work.
> -Daniel
>
> > ---
> > drivers/gpu/drm/vkms/vkms_crc.c | 4 +++-
> > drivers/gpu/drm/vkms/vkms_crtc.c | 4 +++-
> > 2 files changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/vkms/vkms_crc.c
> > b/drivers/gpu/drm/vkms/vkms_crc.c
> > index d7b409a3c0f8..09a8b00ef1f1 100644
> > --- a/drivers/gpu/drm/vkms/vkms_crc.c
> > +++ b/drivers/gpu/drm/vkms/vkms_crc.c
> > @@ -161,6 +161,8 @@ void vkms_crc_work_handle(struct work_struct *work)
> > struct vkms_output *out = drm_crtc_to_vkms_output(crtc);
> > struct vkms_device *vdev = container_of(out, struct vkms_device,
> > output);
> > + unsigned int pipe = drm_crtc_index(crtc);
> > + struct drm_vblank_crtc *vblank = >dev->vblank[pipe];
> > struct vkms_crc_data *primary_crc = NULL;
> > struct vkms_crc_data *cursor_crc = NULL;
> > struct drm_plane *plane;
> > @@ -196,7 +198,7 @@ void vkms_crc_work_handle(struct work_struct *work)
> > if (primary_crc)
> > crc32 = _vkms_get_crc(primary_crc, cursor_crc);
> >
> > - frame_end = drm_crtc_accurate_vblank_count(crtc);
> > + frame_end = vblank->count;
> >
> > /* queue_work can fail to schedule crc_work; add crc for
> > * missing frames
> > diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c
> > b/drivers/gpu/drm/vkms/vkms_crtc.c
> > index 8a9aeb0a9ea8..9bf3268e2e92 100644
> > --- a/drivers/gpu/drm/vkms/vkms_crtc.c
> > +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> > @@ -10,6 +10,8 @@ static enum hrtimer_restart vkms_vblank_simulate(struct
> > hrtimer *timer)
> > vblank_hrtimer);
> > struct drm_crtc *crtc = >crtc;
> > struct vkms_crtc_state *state = to_vkms_crtc_state(crtc->state);
> > + unsigned int pipe = drm_crtc_index(crtc);
> > + struct drm_vblank_crtc *vblank = >dev->vblank[pipe];
> > u64 ret_overrun;
> > bool ret;
> >
> > @@ -20,7 +22,7 @@ static enum hrtimer_restart vkms_vblank_simulate(struct
> > hrtimer *timer)
> > DRM_ERROR("vkms failure on handling vblank");
> >
> > if (state && output->crc_enabled) {
> > - u64 frame = drm_crtc_accurate_vblank_count(crtc);
> > + u64 frame = vblank->count;
> >
> > /* update frame_start only if a queued vkms_crc_work_handle()
> > * has read the data
> > --
> > 2.17.1
> >
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH v3 3/3] drm/i915: Don't send hotplug in intel_dp_check_mst_status()
On Tue, Jan 29, 2019 at 02:10:01PM -0500, Lyude Paul wrote:
> This hotplug also isn't needed: drm_dp_mst_topology_mgr_set_mst()
> already sends a hotplug on its own from drm_dp_destroy_connector_work()
> after destroying connectors in the MST topology.
>
> Signed-off-by: Lyude Paul
> Cc: Imre Deak
> Cc: Daniel Vetter
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_dp.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index c2399acf177b..f9113c0cdfcd 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4608,12 +4608,10 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
>
> return ret;
> } else {
> - struct intel_digital_port *intel_dig_port =
> dp_to_dig_port(intel_dp);
> DRM_DEBUG_KMS("failed to get ESI - device may have
> failed\n");
> intel_dp->is_mst = false;
> - drm_dp_mst_topology_mgr_set_mst(_dp->mst_mgr,
> intel_dp->is_mst);
> - /* send a hotplug event */
> -
> drm_kms_helper_hotplug_event(intel_dig_port->base.base.dev);
> + drm_dp_mst_topology_mgr_set_mst(_dp->mst_mgr,
> + intel_dp->is_mst);
> }
> }
> return -EINVAL;
> --
> 2.20.1
>
> _______
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
Re: [PATCH v3 2/3] drm/i915: Don't send MST hotplugs during resume
On Tue, Jan 29, 2019 at 02:10:00PM -0500, Lyude Paul wrote:
> We have a bad habit of calling drm_fb_helper_hotplug_event() far more
> then we actually need to. MST appears to be one of these cases, where we
> call drm_fb_helper_hotplug_event() if we fail to resume a connected MST
> topology in intel_dp_mst_resume(). We don't actually need to do this at
> all though since hotplug events are already sent from
> drm_dp_connector_destroy_work() every time connectors are unregistered
> from userspace's PoV. Additionally, extra calls to
> drm_fb_helper_hotplug_event() also just mean more of a chance of doing a
> connector probe somewhere we shouldn't.
>
> So, don't send any hotplug events during resume if the MST topology
> fails to come up. Just rely on the DP MST helpers to send them for us.
>
> Signed-off-by: Lyude Paul
> Cc: Imre Deak
> Cc: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_dp.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 681e88405ada..c2399acf177b 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -7096,7 +7096,10 @@ void intel_dp_mst_resume(struct drm_i915_private
> *dev_priv)
> continue;
>
> ret = drm_dp_mst_topology_mgr_resume(_dp->mst_mgr);
> - if (ret)
> - intel_dp_check_mst_status(intel_dp);
> + if (ret) {
> + intel_dp->is_mst = false;
> + drm_dp_mst_topology_mgr_set_mst(_dp->mst_mgr,
> + false);
drm_dp_mst_topology_mgr_set_mst()
-> drm_dp_mst_topology_put_mstb()
-> drm_dp_destroy_mst_branch_device()
-> drm_dp_mst_topology_put_port()
-> drm_dp_destroy_port()
-> drm_dp_destroy_connector_work()
-> drm_kms_helper_hotplug_event()
That of course requires that no one is hanging on to the
kref(s). The lifetime of the references isn't really clear
to me, but I'll take your word that it works.
Reviewed-by: Ville Syrjälä
> + }
> }
> }
> --
> 2.20.1
>
> _______
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
Re: [PATCH v3 23/23] drm/qxl: add overflow checks to qxl_mode_dumb_create()
On Fri, Jan 18, 2019 at 04:49:44PM +0100, Daniel Vetter wrote:
> On Fri, Jan 18, 2019 at 01:20:20PM +0100, Gerd Hoffmann wrote:
> > Signed-off-by: Gerd Hoffmann
>
> We already do all reasonable overflow checks in drm_mode_create_dumb(). If
> you don't trust them I think would be better time spent typing an igt to
> test this than adding redundant check in all drivers.
>
> You're also missing one check for bpp underflows :-)
BTW I just noticed that we don't seem to validating
create_dumb->flags at all. Someone should probably add some
checks for that, or mark it as deprecated in case we already
lost the battle with userspace stack garbage.
> -Daniel
>
> > ---
> > drivers/gpu/drm/qxl/qxl_dumb.c | 10 ++
> > 1 file changed, 6 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/qxl/qxl_dumb.c b/drivers/gpu/drm/qxl/qxl_dumb.c
> > index 272d19b677..bed6d06ee4 100644
> > --- a/drivers/gpu/drm/qxl/qxl_dumb.c
> > +++ b/drivers/gpu/drm/qxl/qxl_dumb.c
> > @@ -37,11 +37,13 @@ int qxl_mode_dumb_create(struct drm_file *file_priv,
> > uint32_t handle;
> > int r;
> > struct qxl_surface surf;
> > - uint32_t pitch, format;
> > + uint32_t pitch, size, format;
> >
> > - pitch = args->width * ((args->bpp + 1) / 8);
> > - args->size = pitch * args->height;
> > - args->size = ALIGN(args->size, PAGE_SIZE);
> > + if (check_mul_overflow(args->width, ((args->bpp + 1) / 8), ))
> > + return -EINVAL;
> > + if (check_mul_overflow(pitch, args->height, ))
> > + return -EINVAL;
> > + args->size = ALIGN(size, PAGE_SIZE);
> >
> > switch (args->bpp) {
> > case 16:
> > --
> > 2.9.3
> >
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
Re: [PATCH 1/6] include/drm: color_mgmt: Add enum labels
On Fri, Jan 18, 2019 at 03:34:18PM +0100, Andrzej Hajda wrote:
> +CC: Hans
>
> On 17.01.2019 20:47, Ville Syrjälä wrote:
> > On Fri, Dec 14, 2018 at 01:10:16PM +0100, Christoph Manszewski wrote:
> >> Range setting makes sense for YCbCr and RGB buffers. Current
> >> drm_color_range enum labels suggest use with YCbCr buffers.
> >> Create enum labels without colorspace specification.
> >>
> >> Signed-off-by: Christoph Manszewski
> >> ---
> >> include/drm/drm_color_mgmt.h | 2 ++
> >> 1 file changed, 2 insertions(+)
> >>
> >> diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
> >> index 90ef9996d9a4..52f6d5221a0d 100644
> >> --- a/include/drm/drm_color_mgmt.h
> >> +++ b/include/drm/drm_color_mgmt.h
> >> @@ -62,6 +62,8 @@ enum drm_color_range {
> >>DRM_COLOR_YCBCR_LIMITED_RANGE,
> >>DRM_COLOR_YCBCR_FULL_RANGE,
> >>DRM_COLOR_RANGE_MAX,
> >> + DRM_COLOR_LIMITED_RANGE = DRM_COLOR_YCBCR_LIMITED_RANGE,
> >> + DRM_COLOR_FULL_RANGE = DRM_COLOR_YCBCR_FULL_RANGE,
> > These enum values don't mean anything really. The strings are what
> > matter for the uapi.
> >
> > The default for YCbCr needs to be limited range, the default for RGB
> > needs to be full range. So I think this would really require a separate
> > prop for each.
> >
> > But is there an actual usecase for this stuff?
>
>
> Yes, for example HDMI path (Display Controller and HDMI encoder) in
> Exynos5433 works on RGB buffers and do not perform any conversion if the
> output is also RGB, on the other side CEA861 specs says that in case of
> CEA modes output RGB should be in limited range, in case of non CEA
> modes it should be full range.
>
> The idea was to allow userspace to check (atomic_check) which ranges are
> acceptable in given mode and to set desired one if possible.
>
> Any better solution is welcome?
i915 has the "Broadcast RGB" property for the CEA-861 stuff.
You don't have a way to implement that?
--
Ville Syrjälä
Intel
Re: [PATCH 1/6] include/drm: color_mgmt: Add enum labels
On Fri, Dec 14, 2018 at 01:10:16PM +0100, Christoph Manszewski wrote:
> Range setting makes sense for YCbCr and RGB buffers. Current
> drm_color_range enum labels suggest use with YCbCr buffers.
> Create enum labels without colorspace specification.
>
> Signed-off-by: Christoph Manszewski
> ---
> include/drm/drm_color_mgmt.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
> index 90ef9996d9a4..52f6d5221a0d 100644
> --- a/include/drm/drm_color_mgmt.h
> +++ b/include/drm/drm_color_mgmt.h
> @@ -62,6 +62,8 @@ enum drm_color_range {
> DRM_COLOR_YCBCR_LIMITED_RANGE,
> DRM_COLOR_YCBCR_FULL_RANGE,
> DRM_COLOR_RANGE_MAX,
> + DRM_COLOR_LIMITED_RANGE = DRM_COLOR_YCBCR_LIMITED_RANGE,
> + DRM_COLOR_FULL_RANGE = DRM_COLOR_YCBCR_FULL_RANGE,
These enum values don't mean anything really. The strings are what
matter for the uapi.
The default for YCbCr needs to be limited range, the default for RGB
needs to be full range. So I think this would really require a separate
prop for each.
But is there an actual usecase for this stuff?
> };
>
> int drm_plane_create_color_properties(struct drm_plane *plane,
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
Re: [PATCH v2] drm/i915: Pass down rc in intel_encoder->compute_config()
On Tue, Jan 15, 2019 at 03:08:00PM -0500, Lyude Paul wrote:
> Something that I completely missed when implementing the new MST VCPI
> atomic helpers is that with those helpers, there's technically a chance
> of us having to grab additional modeset locks in ->compute_config() and
> furthermore, that means we have the potential to hit a normal modeset
> deadlock. However, because ->compute_config() only returns a bool this
> means we can't return -EDEADLK when we need to drop locks and try again
> which means we end up just failing the atomic check permanently. Whoops.
>
> So, fix this by modifying ->compute_config() to pass down an actual
> error code instead of a bool so that the atomic check can be restarted
> on modeset deadlocks.
>
> Thanks to Ville Syrjälä for pointing this out!
>
> Changes since v1:
> * Add some newlines
> * Return only -EINVAL from hsw_crt_compute_config()
> * Propogate return code from intel_dp_compute_dsc_params()
> * Change all of the intel_dp_compute_link_config*() variants
> * Don't miss if (hdmi_port_clock_valid()) branch in
> intel_hdmi_compute_config()
>
> Signed-off-by: Lyude Paul
> Cc: Ville Syrjälä
> Fixes: eceae1472467 ("drm/dp_mst: Start tracking per-port VCPI allocations")
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109320
Patch looks great. Hopefully we got them all.
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/icl_dsi.c | 8 ++--
> drivers/gpu/drm/i915/intel_crt.c | 35 +++---
> drivers/gpu/drm/i915/intel_ddi.c | 6 +--
> drivers/gpu/drm/i915/intel_display.c | 11 +++--
> drivers/gpu/drm/i915/intel_dp.c | 71 +++-
> drivers/gpu/drm/i915/intel_dp_mst.c | 12 ++---
> drivers/gpu/drm/i915/intel_drv.h | 18 +++
> drivers/gpu/drm/i915/intel_dvo.c | 11 +++--
> drivers/gpu/drm/i915/intel_hdmi.c| 14 +++---
> drivers/gpu/drm/i915/intel_lvds.c| 12 ++---
> drivers/gpu/drm/i915/intel_sdvo.c| 14 +++---
> drivers/gpu/drm/i915/intel_tv.c | 8 ++--
> drivers/gpu/drm/i915/vlv_dsi.c | 14 +++---
> 13 files changed, 122 insertions(+), 112 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/icl_dsi.c b/drivers/gpu/drm/i915/icl_dsi.c
> index f3a5f03646ce..355b48d1c937 100644
> --- a/drivers/gpu/drm/i915/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/icl_dsi.c
> @@ -1188,9 +1188,9 @@ static void gen11_dsi_get_config(struct intel_encoder
> *encoder,
> pipe_config->output_types |= BIT(INTEL_OUTPUT_DSI);
> }
>
> -static bool gen11_dsi_compute_config(struct intel_encoder *encoder,
> - struct intel_crtc_state *pipe_config,
> - struct drm_connector_state *conn_state)
> +static int gen11_dsi_compute_config(struct intel_encoder *encoder,
> + struct intel_crtc_state *pipe_config,
> + struct drm_connector_state *conn_state)
> {
> struct intel_dsi *intel_dsi = container_of(encoder, struct intel_dsi,
> base);
> @@ -1215,7 +1215,7 @@ static bool gen11_dsi_compute_config(struct
> intel_encoder *encoder,
> pipe_config->clock_set = true;
> pipe_config->port_clock = intel_dsi_bitrate(intel_dsi) / 5;
>
> - return true;
> + return 0;
> }
>
> static u64 gen11_dsi_get_power_domains(struct intel_encoder *encoder,
> diff --git a/drivers/gpu/drm/i915/intel_crt.c
> b/drivers/gpu/drm/i915/intel_crt.c
> index 33bd2addcbdd..081c333f30d2 100644
> --- a/drivers/gpu/drm/i915/intel_crt.c
> +++ b/drivers/gpu/drm/i915/intel_crt.c
> @@ -345,51 +345,52 @@ intel_crt_mode_valid(struct drm_connector *connector,
> return MODE_OK;
> }
>
> -static bool intel_crt_compute_config(struct intel_encoder *encoder,
> - struct intel_crtc_state *pipe_config,
> - struct drm_connector_state *conn_state)
> +static int intel_crt_compute_config(struct intel_encoder *encoder,
> + struct intel_crtc_state *pipe_config,
> + struct drm_connector_state *conn_state)
> {
> struct drm_display_mode *adjusted_mode =
> _config->base.adjusted_mode;
>
> if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)
> - return false;
> + return -EINVAL;
>
> pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
> - return true;
> +
> + return 0;
> }
>
> -static bool pch_crt_compute_config(struct intel_encoder *encoder,
> -struct intel_crtc_state *pipe_conf
Re: [PATCH] drm/i915: Pass down rc in intel_encoder->compute_config()
On Mon, Jan 14, 2019 at 05:29:31PM -0500, Lyude Paul wrote:
> Something that I completely missed when implementing the new MST VCPI
> atomic helpers is that with those helpers, there's technically a chance
> of us having to grab additional modeset locks in ->compute_config() and
> furthermore, that means we have the potential to hit a normal modeset
> deadlock. However, because ->compute_config() only returns a bool this
> means we can't return -EDEADLK when we need to drop locks and try again
> which means we end up just failing the atomic check permanently. Whoops.
>
> So, fix this by modifying ->compute_config() to pass down an actual
> error code instead of a bool so that the atomic check can be restarted
> on modeset deadlocks.
>
> Thanks to Ville Syrjälä for pointing this out!
>
> Signed-off-by: Lyude Paul
> Cc: Ville Syrjälä
> Fixes: eceae1472467 ("drm/dp_mst: Start tracking per-port VCPI allocations")
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109320
> ---
> drivers/gpu/drm/i915/icl_dsi.c | 8 +++
> drivers/gpu/drm/i915/intel_crt.c | 34 ++--
> drivers/gpu/drm/i915/intel_ddi.c | 6 ++---
> drivers/gpu/drm/i915/intel_display.c | 11 +
> drivers/gpu/drm/i915/intel_dp.c | 32 +-
> drivers/gpu/drm/i915/intel_dp_mst.c | 12 +-
> drivers/gpu/drm/i915/intel_drv.h | 18 +++
> drivers/gpu/drm/i915/intel_dvo.c | 10
> drivers/gpu/drm/i915/intel_hdmi.c| 12 +-
> drivers/gpu/drm/i915/intel_lvds.c| 12 +-
> drivers/gpu/drm/i915/intel_sdvo.c| 14 ++--
> drivers/gpu/drm/i915/intel_tv.c | 8 +++
> drivers/gpu/drm/i915/vlv_dsi.c | 14 ++--
> 13 files changed, 97 insertions(+), 94 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/icl_dsi.c b/drivers/gpu/drm/i915/icl_dsi.c
> index f3a5f03646ce..355b48d1c937 100644
> --- a/drivers/gpu/drm/i915/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/icl_dsi.c
> @@ -1188,9 +1188,9 @@ static void gen11_dsi_get_config(struct intel_encoder
> *encoder,
> pipe_config->output_types |= BIT(INTEL_OUTPUT_DSI);
> }
>
> -static bool gen11_dsi_compute_config(struct intel_encoder *encoder,
> - struct intel_crtc_state *pipe_config,
> - struct drm_connector_state *conn_state)
> +static int gen11_dsi_compute_config(struct intel_encoder *encoder,
> + struct intel_crtc_state *pipe_config,
> + struct drm_connector_state *conn_state)
> {
> struct intel_dsi *intel_dsi = container_of(encoder, struct intel_dsi,
> base);
> @@ -1215,7 +1215,7 @@ static bool gen11_dsi_compute_config(struct
> intel_encoder *encoder,
> pipe_config->clock_set = true;
> pipe_config->port_clock = intel_dsi_bitrate(intel_dsi) / 5;
>
> - return true;
> + return 0;
> }
>
> static u64 gen11_dsi_get_power_domains(struct intel_encoder *encoder,
> diff --git a/drivers/gpu/drm/i915/intel_crt.c
> b/drivers/gpu/drm/i915/intel_crt.c
> index 33bd2addcbdd..625794883433 100644
> --- a/drivers/gpu/drm/i915/intel_crt.c
> +++ b/drivers/gpu/drm/i915/intel_crt.c
> @@ -345,51 +345,51 @@ intel_crt_mode_valid(struct drm_connector *connector,
> return MODE_OK;
> }
>
> -static bool intel_crt_compute_config(struct intel_encoder *encoder,
> - struct intel_crtc_state *pipe_config,
> - struct drm_connector_state *conn_state)
> +static int intel_crt_compute_config(struct intel_encoder *encoder,
> + struct intel_crtc_state *pipe_config,
> + struct drm_connector_state *conn_state)
> {
> struct drm_display_mode *adjusted_mode =
> _config->base.adjusted_mode;
>
> if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)
> - return false;
> + return -EINVAL;
>
> pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
Please add a newline here while at it.
> - return true;
> + return 0;
> }
>
> -static bool pch_crt_compute_config(struct intel_encoder *encoder,
> -struct intel_crtc_state *pipe_config,
> -struct drm_connector_state *conn_state)
> +static int pch_crt_compute_config(struct intel_encoder *encoder,
> + struct intel_crtc_state *pipe_config,
> + struct drm_connector_state *conn_state)
>
Re: "flip_done timed out" messages causing huge increase in boot time
On Sat, Jan 05, 2019 at 12:47:12AM +0100, Daniel Kamil Kozar wrote:
> Hello.
> After upgrading the kernel to 4.20, I noticed that the boot time
> increased from about 5 seconds to 25 seconds. My machine is an Asus
> K53SV with an Intel i7-2630QM, i.e. Sandy Bridge. I have an external
> display connected to it via HDMI. If the display is unplugged when
> booting the machine, the boot time stays at its old value.
> The kernel log shows two messages like this :
>
> [ 15.747206] [drm:drm_atomic_helper_wait_for_flip_done
> [drm_kms_helper]] *ERROR* [CRTC:39:pipe A] flip_done timed out
> [ 26.198968] [drm:drm_atomic_helper_wait_for_dependencies
> [drm_kms_helper]] *ERROR* [CRTC:39:pipe A] flip_done timed out
Hrm. With SNB I would be tempted to blame the LP3 watermarks, but
4.20 already has commit 21556350ade3 ("drm/i915: Disable LP3 watermarks
on all SNB machines").
Can you file a bug at
https://bugs.freedesktop.org/enter_bug.cgi?product=DRI=DRM/Intel
and attach the full dmesg from the boot with drm.debug=0xe passed to the
kernel cmdline?
--
Ville Syrjälä
Intel
Re: [PATCH 4.19 044/110] drm/i915: Disable LP3 watermarks on all SNB machines
On Thu, Dec 06, 2018 at 08:28:07AM +0100, Greg Kroah-Hartman wrote:
> On Wed, Dec 05, 2018 at 11:39:05PM +0200, Ville Syrjälä wrote:
> > On Thu, Nov 29, 2018 at 03:12:15PM +0100, Greg Kroah-Hartman wrote:
> > > 4.19-stable review patch. If anyone has any objections, please let me
> > > know.
> >
> > This one apparently introduces some annoying dmesg errors:
> > [3.487895] [drm:intel_print_wm_latency [i915]] *ERROR* Primary WM3
> > latency not provided
> > [3.487926] [drm:intel_print_wm_latency [i915]] *ERROR* Sprite WM3
> > latency not provided
> > [3.487955] [drm:intel_print_wm_latency [i915]] *ERROR* Cursor WM3
> > latency not provided
> >
> > To silence those please also backport
> > commit 274dba1ae8ff ("drm/i915: Downgrade Gen9 Plane WM latency error")
>
> That commit id is not in Linus's tree, are you sure it is correct?
Sorry. Picked the wrong sha by accident.
86c1c87d0e62 ("drm/i915: Downgrade Gen9 Plane WM latency error")
--
Ville Syrjälä
Intel
Re: [PATCH 4.19 044/110] drm/i915: Disable LP3 watermarks on all SNB machines
On Thu, Dec 06, 2018 at 08:28:07AM +0100, Greg Kroah-Hartman wrote:
> On Wed, Dec 05, 2018 at 11:39:05PM +0200, Ville Syrjälä wrote:
> > On Thu, Nov 29, 2018 at 03:12:15PM +0100, Greg Kroah-Hartman wrote:
> > > 4.19-stable review patch. If anyone has any objections, please let me
> > > know.
> >
> > This one apparently introduces some annoying dmesg errors:
> > [3.487895] [drm:intel_print_wm_latency [i915]] *ERROR* Primary WM3
> > latency not provided
> > [3.487926] [drm:intel_print_wm_latency [i915]] *ERROR* Sprite WM3
> > latency not provided
> > [3.487955] [drm:intel_print_wm_latency [i915]] *ERROR* Cursor WM3
> > latency not provided
> >
> > To silence those please also backport
> > commit 274dba1ae8ff ("drm/i915: Downgrade Gen9 Plane WM latency error")
>
> That commit id is not in Linus's tree, are you sure it is correct?
Sorry. Picked the wrong sha by accident.
86c1c87d0e62 ("drm/i915: Downgrade Gen9 Plane WM latency error")
--
Ville Syrjälä
Intel
