Re: [PATCH 3/4] drm/imx: fix -Wformat-truncation warning in imx_ldb_probe()
On Thu, May 23, 2024 at 06:51:08PM +0300, Jani Nikula wrote:
> Enabling -Wformat-truncation yields the following warning:
>
> ../drivers/gpu/drm/imx/ipuv3/imx-ldb.c: In function ‘imx_ldb_probe’:
> ../drivers/gpu/drm/imx/ipuv3/imx-ldb.c:658:57: error: ‘_sel’ directive output
> may be truncated writing 4 bytes into a region of size between 3 and 13
> [-Werror=format-truncation=]
> 658 | snprintf(clkname, sizeof(clkname), "di%d_sel", i);
> | ^~~~
> ../drivers/gpu/drm/imx/ipuv3/imx-ldb.c:658:17: note: ‘snprintf’ output
> between 8 and 18 bytes into a destination of size 16
> 658 | snprintf(clkname, sizeof(clkname), "di%d_sel", i);
> | ^
If only the compiler could count to three...
>
> Silence the warning by checking the snprintf() return value.
>
> Signed-off-by: Jani Nikula
>
> ---
>
> Cc: Philipp Zabel
> Cc: Shawn Guo
> Cc: Sascha Hauer
> Cc: Pengutronix Kernel Team
> Cc: Fabio Estevam
> Cc: dri-de...@lists.freedesktop.org
> Cc: i...@lists.linux.dev
> ---
> drivers/gpu/drm/imx/ipuv3/imx-ldb.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/imx/ipuv3/imx-ldb.c
> b/drivers/gpu/drm/imx/ipuv3/imx-ldb.c
> index 71d70194fcbd..46f779fe60ee 100644
> --- a/drivers/gpu/drm/imx/ipuv3/imx-ldb.c
> +++ b/drivers/gpu/drm/imx/ipuv3/imx-ldb.c
> @@ -654,8 +654,12 @@ static int imx_ldb_probe(struct platform_device *pdev)
>*/
> for (i = 0; i < 4; i++) {
> char clkname[16];
> + int len;
> +
> + len = snprintf(clkname, sizeof(clkname), "di%d_sel", i);
> + if (len >= sizeof(clkname))
> + dev_err(dev, "clkname truncated\n");
>
> - snprintf(clkname, sizeof(clkname), "di%d_sel", i);
> imx_ldb->clk_sel[i] = devm_clk_get(imx_ldb->dev, clkname);
> if (IS_ERR(imx_ldb->clk_sel[i])) {
> ret = PTR_ERR(imx_ldb->clk_sel[i]);
> --
> 2.39.2
--
Ville Syrjälä
Intel
Re: [PATCH v0 02/14] drm/amdgpu,drm/radeon: Make I2C terminology more inclusive
On Fri, Mar 29, 2024 at 06:38:10PM +0100, Andi Shyti wrote: > Hi, > > On Fri, Mar 29, 2024 at 10:28:14AM -0700, Easwar Hariharan wrote: > > On 3/29/2024 10:16 AM, Andi Shyti wrote: > > > Hi Easwar, > > > > > > On Fri, Mar 29, 2024 at 05:00:26PM +, Easwar Hariharan wrote: > > >> I2C v7, SMBus 3.2, and I3C specifications have replaced "master/slave" > > > > > > I don't understand why we forget that i3c is 1.1.1 :-) > > > > That's because it's a copy-paste error from Wolfram's cover letter. :) I'll > > update > > next go-around. > > not a binding comment, though. Just for completeness, because we > are giving the version to the i2c and smbus, but not i3c. > > > >> with more appropriate terms. Inspired by and following on to Wolfram's > > >> series to fix drivers/i2c/[1], fix the terminology for users of > > >> I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists > > >> in the specification. > > > > > > The specification talks about: > > > > > > - master -> controller > > > - slave -> target (and not client) > > > > > > But both you and Wolfram have used client. I'd like to reach > > > some more consistency here. > > > > I had the impression that remote targets (i.e external to the device) were > > to be called clients, > > e.g. the QSFP FRUs in drivers/infiniband, and internal ones targets. > > I chose the terminology according to that understanding, but now I can't > > find where I got that > > information. > > The word "client" does not even appear in the documentation (only > one instance in the i3c document), so that the change is not > related to the document as stated in the commit log. Unless, of > course, I am missing something. > > I'm OK with choosing a "customized" naming, but we need to reach > an agreement. > > I raised the same question to Wolfram. I don't know where that discussion happened, but my opinion is NAK to "client". Life is already confusing enough with these renames, so let's not make it even more confusing by inventing new names nowhere to be found in the spec. And let's especially not invent names that don't even fit the purpose. "Client" makes me think of "client/server" or some real world analogy. Neither of which seem to have any resemblence to how the term would be used for i2c. -- Ville Syrjälä Intel
Re: [PATCH v6 3/5] drm: Add support to get EDID from ACPI
On Thu, Feb 15, 2024 at 12:20:56PM -0600, Mario Limonciello wrote:
> On 2/14/2024 17:13, Ville Syrjälä wrote:
> > On Wed, Feb 14, 2024 at 03:57:54PM -0600, Mario Limonciello wrote:
> >> Some manufacturers have intentionally put an EDID that differs from
> >> the EDID on the internal panel on laptops. Drivers that prefer to
> >> fetch this EDID can set a bit on the drm_connector to indicate that
> >> the DRM EDID helpers should try to fetch it and it is preferred if
> >> it's present.
> >>
> >> Signed-off-by: Mario Limonciello
> >> ---
> >> drivers/gpu/drm/Kconfig | 1 +
> >> drivers/gpu/drm/drm_edid.c | 109 +---
> >> include/drm/drm_connector.h | 6 ++
> >> include/drm/drm_edid.h | 1 +
> >> 4 files changed, 109 insertions(+), 8 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> >> index 872edb47bb53..3db89e6af01d 100644
> >> --- a/drivers/gpu/drm/Kconfig
> >> +++ b/drivers/gpu/drm/Kconfig
> >> @@ -8,6 +8,7 @@
> >> menuconfig DRM
> >>tristate "Direct Rendering Manager (XFree86 4.1.0 and higher DRI
> >> support)"
> >>depends on (AGP || AGP=n) && !EMULATED_CMPXCHG && HAS_DMA
> >> + depends on (ACPI_VIDEO || ACPI_VIDEO=n)
> >>select DRM_PANEL_ORIENTATION_QUIRKS
> >>select DRM_KMS_HELPER if DRM_FBDEV_EMULATION
> >>select FB_CORE if DRM_FBDEV_EMULATION
> >> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> >> index 923c4423151c..cdc30c6d05d5 100644
> >> --- a/drivers/gpu/drm/drm_edid.c
> >> +++ b/drivers/gpu/drm/drm_edid.c
> >> @@ -28,6 +28,7 @@
> >>* DEALINGS IN THE SOFTWARE.
> >>*/
> >>
> >> +#include
> >> #include
> >> #include
> >> #include
> >> @@ -2188,6 +2189,58 @@ drm_do_probe_ddc_edid(void *data, u8 *buf, unsigned
> >> int block, size_t len)
> >>return ret == xfers ? 0 : -1;
> >> }
> >>
> >> +/**
> >> + * drm_do_probe_acpi_edid() - get EDID information via ACPI _DDC
> >> + * @data: struct drm_connector
> >> + * @buf: EDID data buffer to be filled
> >> + * @block: 128 byte EDID block to start fetching from
> >> + * @len: EDID data buffer length to fetch
> >> + *
> >> + * Try to fetch EDID information by calling acpi_video_get_edid()
> >> function.
> >> + *
> >> + * Return: 0 on success or error code on failure.
> >> + */
> >> +static int
> >> +drm_do_probe_acpi_edid(void *data, u8 *buf, unsigned int block, size_t
> >> len)
> >> +{
> >> + struct drm_connector *connector = data;
> >> + struct drm_device *ddev = connector->dev;
> >> + struct acpi_device *acpidev = ACPI_COMPANION(ddev->dev);
> >> + unsigned char start = block * EDID_LENGTH;
> >> + void *edid;
> >> + int r;
> >> +
> >> + if (!acpidev)
> >> + return -ENODEV;
> >> +
> >> + switch (connector->connector_type) {
> >> + case DRM_MODE_CONNECTOR_LVDS:
> >> + case DRM_MODE_CONNECTOR_eDP:
> >> + break;
> >> + default:
> >> + return -EINVAL;
> >> + }
> >
> > We could have other types of connectors that want this too.
> > I don't see any real benefit in having this check tbh. Drivers
> > should simply notset the flag on connectors where it won't work,
> > and only the driver can really know that.
>
> Ack.
>
> >
> >> + /* fetch the entire edid from BIOS */
> >> + r = acpi_video_get_edid(acpidev, ACPI_VIDEO_DISPLAY_LCD, -1, );
> >> + if (r < 0) {
> >> + DRM_DEBUG_KMS("Failed to get EDID from ACPI: %d\n", r);
> >> + return r;
> >> + }
> >> + if (len > r || start > r || start + len > r) {
> >> + r = -EINVAL;
> >> + goto cleanup;
> >> + }
> >> +
> >> + memcpy(buf, edid + start, len);
> >> + r = 0;
> >> +
> >> +cleanup:
> >> + kfree(edid);
> >> +
> >> + return r;
> >> +}
> >> +
> >> static void connector_bad_edid(struct drm_connector *connector,
> >> const struct edid *edid, int num_blocks)
> >> {
> >> @@ -2621,7 +2674,8 @@ EXPORT_SYMBOL(drm_probe_ddc);
&
Re: [PATCH v6 3/5] drm: Add support to get EDID from ACPI
(connector, drm_do_probe_acpi_edid,
> connector, NULL);
> +
> + if (!edid) {
> + if (connector->force == DRM_FORCE_UNSPECIFIED &&
> !drm_probe_ddc(adapter))
> + return NULL;
> + edid = _drm_do_get_edid(connector, drm_do_probe_ddc_edid,
> adapter, NULL);
> + }
>
> - edid = _drm_do_get_edid(connector, drm_do_probe_ddc_edid, adapter,
> NULL);
> drm_connector_update_edid_property(connector, edid);
> return edid;
> }
> EXPORT_SYMBOL(drm_get_edid);
>
> +/**
> + * drm_edid_read_acpi - get EDID data, if available
> + * @connector: connector we're probing
> + *
> + * Use the BIOS to attempt to grab EDID data if possible.
> + *
> + * The returned pointer must be freed using drm_edid_free().
> + *
> + * Return: Pointer to valid EDID or NULL if we couldn't find any.
> + */
> +const struct drm_edid *drm_edid_read_acpi(struct drm_connector *connector)
> +{
> + const struct drm_edid *drm_edid;
> +
> + if (connector->force == DRM_FORCE_OFF)
> + return NULL;
> +
> + drm_edid = drm_edid_read_custom(connector, drm_do_probe_acpi_edid,
> connector);
> +
> + /* Note: Do *not* call connector updates here. */
> +
> + return drm_edid;
> +}
> +EXPORT_SYMBOL(drm_edid_read_acpi);
> +
> /**
> * drm_edid_read_custom - Read EDID data using given EDID block read function
> * @connector: Connector to use
> @@ -2727,10 +2811,11 @@ const struct drm_edid *drm_edid_read_ddc(struct
> drm_connector *connector,
> EXPORT_SYMBOL(drm_edid_read_ddc);
>
> /**
> - * drm_edid_read - Read EDID data using connector's I2C adapter
> + * drm_edid_read - Read EDID data using BIOS or connector's I2C adapter
> * @connector: Connector to use
> *
> - * Read EDID using the connector's I2C adapter.
> + * Read EDID from BIOS if allowed by connector or by using the connector's
> + * I2C adapter.
> *
> * The EDID may be overridden using debugfs override_edid or firmware EDID
> * (drm_edid_load_firmware() and drm.edid_firmware parameter), in this
> priority
> @@ -2742,10 +2827,18 @@ EXPORT_SYMBOL(drm_edid_read_ddc);
> */
> const struct drm_edid *drm_edid_read(struct drm_connector *connector)
> {
> + const struct drm_edid *drm_edid = NULL;
> +
> if (drm_WARN_ON(connector->dev, !connector->ddc))
> return NULL;
>
> - return drm_edid_read_ddc(connector, connector->ddc);
> + if (connector->acpi_edid_allowed)
That should probably be called 'prefer_acpi_edid' or something
since it's the first choice when the flag is set.
But I'm not so sure there's any real benefit in having this
flag at all. You anyway have to modify the driver to use this,
so why not just have the driver do the call directly instead of
adding this extra detour via the flag?
> + drm_edid = drm_edid_read_acpi(connector);
> +
> + if (!drm_edid)
> + drm_edid = drm_edid_read_ddc(connector, connector->ddc);
> +
> + return drm_edid;
> }
> EXPORT_SYMBOL(drm_edid_read);
>
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index fe88d7fc6b8f..74ed47f37a69 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -1886,6 +1886,12 @@ struct drm_connector {
>
> /** @hdr_sink_metadata: HDR Metadata Information read from sink */
> struct hdr_sink_metadata hdr_sink_metadata;
> +
> + /**
> + * @acpi_edid_allowed: Get the EDID from the BIOS, if available.
> + * This is only applicable to eDP and LVDS displays.
> + */
> + bool acpi_edid_allowed;
Aren't there other bools/small stuff in there for tighter packing?
> };
>
> #define obj_to_connector(x) container_of(x, struct drm_connector, base)
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index 7923bc00dc7a..1c1ee927de9c 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -459,5 +459,6 @@ bool drm_edid_is_digital(const struct drm_edid *drm_edid);
>
> const u8 *drm_find_edid_extension(const struct drm_edid *drm_edid,
> int ext_id, int *ext_index);
> +const struct drm_edid *drm_edid_read_acpi(struct drm_connector *connector);
>
> #endif /* __DRM_EDID_H__ */
> --
> 2.34.1
--
Ville Syrjälä
Intel
Re: [Nouveau] [PATCH V2] drm/modes: Fix divide error in drm_mode_debug_printmodeline
On Mon, Nov 20, 2023 at 10:41:18PM +0800, Edward Adam Davis wrote:
> [Syz Log]
> divide error: [#1] PREEMPT SMP KASAN
> CPU: 0 PID: 5068 Comm: syz-executor357 Not tainted
> 6.6.0-syzkaller-16039-gac347a0655db #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 10/09/2023
> RIP: 0010:drm_mode_vrefresh drivers/gpu/drm/drm_modes.c:1303 [inline]
> RIP: 0010:drm_mode_debug_printmodeline+0x118/0x4e0
> drivers/gpu/drm/drm_modes.c:60
> Code: 00 41 0f b7 07 66 83 f8 02 b9 01 00 00 00 0f 43 c8 0f b7 c1 0f af e8 44
> 89 f0 48 69 c8 e8 03 00 00 89 e8 d1 e8 48 01 c8 31 d2 <48> f7 f5 49 89 c6 eb
> 0c e8 fb 07 66 fc eb 05 e8 f4 07 66 fc 48 89
> RSP: 0018:c9000391f8d0 EFLAGS: 00010246
> RAX: 0001f400 RBX: 888025045000 RCX: 0001f400
> RDX: RSI: 8000 RDI: 888025045018
> RBP: R08: 8528b9af R09:
> R10: c9000391f8a0 R11: f52000723f17 R12: 0080
> R13: dc00 R14: 0080 R15: 888025045016
> FS: 56932380() GS:8880b980() knlGS:
> CS: 0010 DS: ES: CR0: 80050033
> CR2: 005fdeb8 CR3: 7fcff000 CR4: 003506f0
> DR0: DR1: DR2:
> DR3: DR6: fffe0ff0 DR7: 0400
> Call Trace:
>
> drm_mode_setcrtc+0x83b/0x1880 drivers/gpu/drm/drm_crtc.c:794
> drm_ioctl_kernel+0x362/0x500 drivers/gpu/drm/drm_ioctl.c:792
> drm_ioctl+0x636/0xb00 drivers/gpu/drm/drm_ioctl.c:895
> vfs_ioctl fs/ioctl.c:51 [inline]
> __do_sys_ioctl fs/ioctl.c:871 [inline]
> __se_sys_ioctl+0xf8/0x170 fs/ioctl.c:857
> do_syscall_x64 arch/x86/entry/common.c:51 [inline]
> do_syscall_64+0x44/0x110 arch/x86/entry/common.c:82
> entry_SYSCALL_64_after_hwframe+0x63/0x6b
>
> [Analysis]
> When calculating den in drm_mode_vrefresh(), if the vscan value is too large,
> there is a probability of unsigned integer overflow.
>
> [Fix]
> Before multiplying by vscan, first check if their product will overflow.
> If overflow occurs, return 0 and exit the subsequent process.
>
> Reported-and-tested-by: syzbot+2e93e6fb36e6fdc56...@syzkaller.appspotmail.com
> Fixes: ea40d7857d52 ("drm/vkms: fbdev emulation support")
> Signed-off-by: Edward Adam Davis
> ---
> drivers/gpu/drm/drm_modes.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index ac9a406250c5..60739d861da2 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -36,6 +36,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -1297,8 +1298,10 @@ int drm_mode_vrefresh(const struct drm_display_mode
> *mode)
> num *= 2;
> if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
> den *= 2;
> - if (mode->vscan > 1)
> - den *= mode->vscan;
> + if (mode->vscan > 1) {
> + if (unlikely(check_mul_overflow(den, mode->vscan, )))
> + return 0;
> + }
I can't see any driver that actually supports vscan>1. Only
nouveau has some code for it, but doesn't look like it does
anything sensible. All other drivers for sure should be
rejecting vscan>1 outright. Which driver is this?
Is there an actual usecase where nouveau needs this (and does
it even work?) or could we just rip out the whole thing and
reject vscan>1 globally?
>
> return DIV_ROUND_CLOSEST_ULL(mul_u32_u32(num, 1000), den);
> }
> --
> 2.25.1
--
Ville Syrjälä
Intel
Re: [Nouveau] [PATCH v4 1/5] drm/i915: Add support for panels with VESA backlights with PWM enable/disable
On Tue, Oct 26, 2021 at 06:08:44PM -0400, Lyude Paul wrote:
> This simply adds proper support for panel backlights that can be controlled
> via VESA's backlight control protocol, but which also require that we
> enable and disable the backlight via PWM instead of via the DPCD interface.
> We also enable this by default, in order to fix some people's backlights
> that were broken by not having this enabled.
>
> For reference, backlights that require this and use VESA's backlight
> interface tend to be laptops with hybrid GPUs, but this very well may
> change in the future.
>
> v4:
> * Make sure that we call intel_backlight_level_to_pwm() in
> intel_dp_aux_vesa_enable_backlight() - vsyrjala
>
> Signed-off-by: Lyude Paul
> Link: https://gitlab.freedesktop.org/drm/intel/-/issues/3680
> Fixes: fe7d52bccab6 ("drm/i915/dp: Don't use DPCD backlights that need PWM
> enable/disable")
> Cc: # v5.12+
Seems consistent enough.
Reviewed-by: Ville Syrjälä
> ---
> .../drm/i915/display/intel_dp_aux_backlight.c | 27 ++-
> 1 file changed, 21 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> index 569d17b4d00f..f05b71c01b8e 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> @@ -293,6 +293,13 @@ intel_dp_aux_vesa_enable_backlight(const struct
> intel_crtc_state *crtc_state,
> struct intel_panel *panel = >panel;
> struct intel_dp *intel_dp = enc_to_intel_dp(connector->encoder);
>
> + if (!panel->backlight.edp.vesa.info.aux_enable) {
> + u32 pwm_level = intel_backlight_invert_pwm_level(connector,
> +
> panel->backlight.pwm_level_max);
> +
> + panel->backlight.pwm_funcs->enable(crtc_state, conn_state,
> pwm_level);
> + }
> +
> drm_edp_backlight_enable(_dp->aux,
> >backlight.edp.vesa.info, level);
> }
>
> @@ -304,6 +311,10 @@ static void intel_dp_aux_vesa_disable_backlight(const
> struct drm_connector_state
> struct intel_dp *intel_dp = enc_to_intel_dp(connector->encoder);
>
> drm_edp_backlight_disable(_dp->aux,
> >backlight.edp.vesa.info);
> +
> + if (!panel->backlight.edp.vesa.info.aux_enable)
> + panel->backlight.pwm_funcs->disable(old_conn_state,
> +
> intel_backlight_invert_pwm_level(connector, 0));
> }
>
> static int intel_dp_aux_vesa_setup_backlight(struct intel_connector
> *connector, enum pipe pipe)
> @@ -321,6 +332,15 @@ static int intel_dp_aux_vesa_setup_backlight(struct
> intel_connector *connector,
> if (ret < 0)
> return ret;
>
> + if (!panel->backlight.edp.vesa.info.aux_enable) {
> + ret = panel->backlight.pwm_funcs->setup(connector, pipe);
> + if (ret < 0) {
> + drm_err(>drm,
> + "Failed to setup PWM backlight controls for eDP
> backlight: %d\n",
> + ret);
> + return ret;
> + }
> + }
> panel->backlight.max = panel->backlight.edp.vesa.info.max;
> panel->backlight.min = 0;
> if (current_mode == DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD) {
> @@ -340,12 +360,7 @@ intel_dp_aux_supports_vesa_backlight(struct
> intel_connector *connector)
> struct intel_dp *intel_dp = intel_attached_dp(connector);
> struct drm_i915_private *i915 = dp_to_i915(intel_dp);
>
> - /* TODO: We currently only support AUX only backlight configurations,
> not backlights which
> - * require a mix of PWM and AUX controls to work. In the mean time,
> these machines typically
> - * work just fine using normal PWM controls anyway.
> - */
> - if ((intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP) &&
> - drm_edp_backlight_supported(intel_dp->edp_dpcd)) {
> + if (drm_edp_backlight_supported(intel_dp->edp_dpcd)) {
> drm_dbg_kms(>drm, "AUX Backlight Control Supported!\n");
> return true;
> }
> --
> 2.31.1
--
Ville Syrjälä
Intel
Re: [Nouveau] [Intel-gfx] [PATCH v3 13/13] drm/i915: replace drm_detect_hdmi_monitor() with drm_display_info.is_hdmi
On Fri, Oct 22, 2021 at 03:01:52PM +0300, Ville Syrjälä wrote:
> On Fri, Oct 22, 2021 at 12:25:33PM +0200, Claudio Suarez wrote:
> > On Thu, Oct 21, 2021 at 04:49:59PM +0300, Ville Syrjälä wrote:
> > > On Wed, Oct 20, 2021 at 12:51:21AM +0200, Claudio Suarez wrote:
> > > > drm_get_edid() internally calls to drm_connector_update_edid_property()
> > > > and then drm_add_display_info(), which parses the EDID.
> > > > This happens in the function intel_hdmi_set_edid() and
> > > > intel_sdvo_tmds_sink_detect() (via intel_sdvo_get_edid()).
> > > >
> > > > Once EDID is parsed, the monitor HDMI support information is available
> > > > through drm_display_info.is_hdmi. Retriving the same information with
> > > > drm_detect_hdmi_monitor() is less efficient. Change to
> > > > drm_display_info.is_hdmi
> > >
> > > I meant we need to examine all call chains that can lead to
> > > .detect() to make sure all of them do in fact update the
> > > display_info beforehand.
> >
> > Well, I studied it carefully and, yes, all call chains that can lead to
> > drm_display_info.is_hdmi / drm_detect_hdmi_monitor() update display_info
> > beforehand. In the case that this doesn't happen, the code is unchanged.
> >
> > Do you want I explain the changes in the code here again ? Or do you want
> > to me change the commit message to be more clear ? In the first case, I can
> > write here a detailed explanation. In the second case I can make a longer
> > commit
> > message.
> >
> > Or both?
>
> I want all those call chains explained in the commit message,
> otherwise I have no easy way to confirm whether the change
> is correct or not.
Hmm. OK, so I had a bit of a dig around and seems that what we do now
.detect()->drm_get_edid()->drm_connector_update_edid_property()->drm_add_display_info()
Now the question is when did that start happening? Looks like it was
commit 4b4df570b41d ("drm: Update edid-derived drm_display_info fields
at edid property set [v2]") that started to call drm_add_display_info()
from drm_connector_update_edid_property(), and then commit 5186421cbfe2
("drm: Introduce epoch counter to drm_connector") started to call
drm_connector_update_edid_property() from drm_get_edid(). Before both
of those commits were in place display_info would still contain
some stale garbage during .detect().
That is the story I think we want in these commit messages since it
a) explains why the old code was directly parsing the edid instead
b) why it's now safe to change this
PS. connector->force handling in drm_get_edid() looks a bit busted
since it doesn't call drm_connector_update_edid_property() at all
in some cases. I think there might be some path that leads there
anywya if/when we change connector->force, but we should fix
drm_get_edid() to do the right thing regarless.
--
Ville Syrjälä
Intel
Re: [Nouveau] [PATCH v3 13/13] drm/i915: replace drm_detect_hdmi_monitor() with drm_display_info.is_hdmi
On Fri, Oct 22, 2021 at 12:25:33PM +0200, Claudio Suarez wrote: > On Thu, Oct 21, 2021 at 04:49:59PM +0300, Ville Syrjälä wrote: > > On Wed, Oct 20, 2021 at 12:51:21AM +0200, Claudio Suarez wrote: > > > drm_get_edid() internally calls to drm_connector_update_edid_property() > > > and then drm_add_display_info(), which parses the EDID. > > > This happens in the function intel_hdmi_set_edid() and > > > intel_sdvo_tmds_sink_detect() (via intel_sdvo_get_edid()). > > > > > > Once EDID is parsed, the monitor HDMI support information is available > > > through drm_display_info.is_hdmi. Retriving the same information with > > > drm_detect_hdmi_monitor() is less efficient. Change to > > > drm_display_info.is_hdmi > > > > I meant we need to examine all call chains that can lead to > > .detect() to make sure all of them do in fact update the > > display_info beforehand. > > Well, I studied it carefully and, yes, all call chains that can lead to > drm_display_info.is_hdmi / drm_detect_hdmi_monitor() update display_info > beforehand. In the case that this doesn't happen, the code is unchanged. > > Do you want I explain the changes in the code here again ? Or do you want > to me change the commit message to be more clear ? In the first case, I can > write here a detailed explanation. In the second case I can make a longer > commit > message. > > Or both? I want all those call chains explained in the commit message, otherwise I have no easy way to confirm whether the change is correct or not. -- Ville Syrjälä Intel
Re: [Nouveau] [PATCH v3 13/13] drm/i915: replace drm_detect_hdmi_monitor() with drm_display_info.is_hdmi
On Wed, Oct 20, 2021 at 12:51:21AM +0200, Claudio Suarez wrote:
> drm_get_edid() internally calls to drm_connector_update_edid_property()
> and then drm_add_display_info(), which parses the EDID.
> This happens in the function intel_hdmi_set_edid() and
> intel_sdvo_tmds_sink_detect() (via intel_sdvo_get_edid()).
>
> Once EDID is parsed, the monitor HDMI support information is available
> through drm_display_info.is_hdmi. Retriving the same information with
> drm_detect_hdmi_monitor() is less efficient. Change to
> drm_display_info.is_hdmi
I meant we need to examine all call chains that can lead to
.detect() to make sure all of them do in fact update the
display_info beforehand.
>
> This is a TODO task in Documentation/gpu/todo.rst
>
> Signed-off-by: Claudio Suarez
> ---
> drivers/gpu/drm/i915/display/intel_hdmi.c | 2 +-
> drivers/gpu/drm/i915/display/intel_sdvo.c | 3 ++-
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
> b/drivers/gpu/drm/i915/display/intel_hdmi.c
> index b04685bb6439..008e5b0ba408 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> @@ -2355,7 +2355,7 @@ intel_hdmi_set_edid(struct drm_connector *connector)
> to_intel_connector(connector)->detect_edid = edid;
> if (edid && edid->input & DRM_EDID_INPUT_DIGITAL) {
> intel_hdmi->has_audio = drm_detect_monitor_audio(edid);
> - intel_hdmi->has_hdmi_sink = drm_detect_hdmi_monitor(edid);
> + intel_hdmi->has_hdmi_sink = connector->display_info.is_hdmi;
>
> connected = true;
> }
> diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c
> b/drivers/gpu/drm/i915/display/intel_sdvo.c
> index 6cb27599ea03..b4065e4df644 100644
> --- a/drivers/gpu/drm/i915/display/intel_sdvo.c
> +++ b/drivers/gpu/drm/i915/display/intel_sdvo.c
> @@ -2060,8 +2060,9 @@ intel_sdvo_tmds_sink_detect(struct drm_connector
> *connector)
> if (edid->input & DRM_EDID_INPUT_DIGITAL) {
> status = connector_status_connected;
> if (intel_sdvo_connector->is_hdmi) {
> - intel_sdvo->has_hdmi_monitor =
> drm_detect_hdmi_monitor(edid);
> intel_sdvo->has_hdmi_audio =
> drm_detect_monitor_audio(edid);
> + intel_sdvo->has_hdmi_monitor =
> +
> connector->display_info.is_hdmi;
> }
> } else
> status = connector_status_disconnected;
> --
> 2.33.0
>
>
--
Ville Syrjälä
Intel
Re: [Nouveau] [PATCH v2 13/13] drm/i915: replace drm_detect_hdmi_monitor() with drm_display_info.is_hdmi
On Sat, Oct 16, 2021 at 08:42:26PM +0200, Claudio Suarez wrote:
> Once EDID is parsed, the monitor HDMI support information is available
> through drm_display_info.is_hdmi. Retriving the same information with
> drm_detect_hdmi_monitor() is less efficient. Change to
> drm_display_info.is_hdmi where possible.
We still need proof in the commit message that display_info
is actually populated by the time this gets called.
>
> This is a TODO task in Documentation/gpu/todo.rst
>
> Signed-off-by: Claudio Suarez
> ---
> drivers/gpu/drm/i915/display/intel_hdmi.c | 2 +-
> drivers/gpu/drm/i915/display/intel_sdvo.c | 3 ++-
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
> b/drivers/gpu/drm/i915/display/intel_hdmi.c
> index b04685bb6439..008e5b0ba408 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> @@ -2355,7 +2355,7 @@ intel_hdmi_set_edid(struct drm_connector *connector)
> to_intel_connector(connector)->detect_edid = edid;
> if (edid && edid->input & DRM_EDID_INPUT_DIGITAL) {
> intel_hdmi->has_audio = drm_detect_monitor_audio(edid);
> - intel_hdmi->has_hdmi_sink = drm_detect_hdmi_monitor(edid);
> + intel_hdmi->has_hdmi_sink = connector->display_info.is_hdmi;
>
> connected = true;
> }
> diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c
> b/drivers/gpu/drm/i915/display/intel_sdvo.c
> index 6cb27599ea03..b4065e4df644 100644
> --- a/drivers/gpu/drm/i915/display/intel_sdvo.c
> +++ b/drivers/gpu/drm/i915/display/intel_sdvo.c
> @@ -2060,8 +2060,9 @@ intel_sdvo_tmds_sink_detect(struct drm_connector
> *connector)
> if (edid->input & DRM_EDID_INPUT_DIGITAL) {
> status = connector_status_connected;
> if (intel_sdvo_connector->is_hdmi) {
> - intel_sdvo->has_hdmi_monitor =
> drm_detect_hdmi_monitor(edid);
> intel_sdvo->has_hdmi_audio =
> drm_detect_monitor_audio(edid);
> + intel_sdvo->has_hdmi_monitor =
> +
> connector->display_info.is_hdmi;
> }
> } else
> status = connector_status_disconnected;
> --
> 2.33.0
>
--
Ville Syrjälä
Intel
Re: [Nouveau] [PATCH v2 01/13] gpu/drm: make drm_add_edid_modes() consistent when updating connector->display_info
On Sat, Oct 16, 2021 at 08:42:14PM +0200, Claudio Suarez wrote:
> According to the documentation, drm_add_edid_modes
> "... Also fills out the _display_info structure and ELD in @connector
> with any information which can be derived from the edid."
>
> drm_add_edid_modes accepts a struct edid *edid parameter which may have a
> value or may be null. When it is not null, connector->display_info and
> connector->eld are updated according to the edid. When edid=NULL, only
> connector->eld is reset. Reset connector->display_info to be consistent
> and accurate.
>
> Signed-off-by: Claudio Suarez
> ---
> drivers/gpu/drm/drm_edid.c | 11 +--
> 1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 6325877c5fd6..c643db17782c 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -5356,14 +5356,13 @@ int drm_add_edid_modes(struct drm_connector
> *connector, struct edid *edid)
> int num_modes = 0;
> u32 quirks;
>
> - if (edid == NULL) {
> - clear_eld(connector);
> - return 0;
> - }
> if (!drm_edid_is_valid(edid)) {
OK, so drm_edid_is_valid() will happily accept NULL and considers
it invalid. You may want to mention that explicitly in the commit
message.
> + /* edid == NULL or invalid here */
> clear_eld(connector);
> - drm_warn(connector->dev, "%s: EDID invalid.\n",
> - connector->name);
> + drm_reset_display_info(connector);
> + if (edid)
> + drm_warn(connector->dev, "%s: EDID invalid.\n",
> + connector->name);
Could you respin this to use the standard [CONNECTOR:%d:%s] form
while at it? Or I guess a patch to mass convert the whole drm_edid.c
might be another option.
Patch looks good.
Reviewed-by: Ville Syrjälä
> return 0;
> }
>
> --
> 2.33.0
>
>
--
Ville Syrjälä
Intel
Re: [Nouveau] [PATCH v3 5/5] drm/i915: Clarify probing order in intel_dp_aux_init_backlight_funcs()
On Tue, Oct 05, 2021 at 10:40:18PM -0400, Lyude Paul wrote:
> Hooray! We've managed to hit enough bugs upstream that I've been able to
> come up with a pretty solid explanation for how backlight controls are
> actually supposed to be detected and used these days. As well, having the
> rest of the PWM bits in VESA's backlight interface implemented seems to
> have fixed all of the problematic brightness controls laptop panels that
> we've hit so far.
>
> So, let's actually document this instead of just calling the laptop panels
> liars. As well, I would like to formally apologize to all of the laptop
> panels I called liars. I'm sorry laptop panels, hopefully you can all
> forgive me and we can move past this~
>
> Signed-off-by: Lyude Paul
> ---
> .../drm/i915/display/intel_dp_aux_backlight.c| 16 +++-
> 1 file changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> index 91daf9ab50e8..04a52d6a74ed 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> @@ -455,11 +455,17 @@ int intel_dp_aux_init_backlight_funcs(struct
> intel_connector *connector)
> }
>
> /*
> - * A lot of eDP panels in the wild will report supporting both the
> - * Intel proprietary backlight control interface, and the VESA
> - * backlight control interface. Many of these panels are liars though,
> - * and will only work with the Intel interface. So, always probe for
> - * that first.
> + * Since Intel has their own backlight control interface, the majority
> of machines out there
> + * using DPCD backlight controls with Intel GPUs will be using this
> interface as opposed to
> + * the VESA interface. However, other GPUs (such as Nvidia's) will
> always use the VESA
> + * interface. This means that there's quite a number of panels out
> there that will advertise
> + * support for both interfaces, primarily systems with Intel/Nvidia
> hybrid GPU setups.
> + *
> + * There's a catch to this though: on many panels that advertise
> support for both
> + * interfaces, the VESA backlight interface will stop working once
> we've programmed the
> + * panel with Intel's OUI - which is also required for us to be able to
> detect Intel's
> + * backlight interface at all. This means that the only sensible way
> for us to detect both
> + * interfaces is to probe for Intel's first, and VESA's second.
>*/
You know a lot more about this than I do.
Acked-by: Ville Syrjälä
> if (try_intel_interface &&
> intel_dp_aux_supports_hdr_backlight(connector)) {
> drm_dbg_kms(dev, "Using Intel proprietary eDP backlight
> controls\n");
> --
> 2.31.1
--
Ville Syrjälä
Intel
Re: [Nouveau] [PATCH v3 1/5] drm/i915: Add support for panels with VESA backlights with PWM enable/disable
On Tue, Oct 05, 2021 at 10:40:14PM -0400, Lyude Paul wrote:
> This simply adds proper support for panel backlights that can be controlled
> via VESA's backlight control protocol, but which also require that we
> enable and disable the backlight via PWM instead of via the DPCD interface.
> We also enable this by default, in order to fix some people's backlights
> that were broken by not having this enabled.
>
> For reference, backlights that require this and use VESA's backlight
> interface tend to be laptops with hybrid GPUs, but this very well may
> change in the future.
>
> Signed-off-by: Lyude Paul
> Link: https://gitlab.freedesktop.org/drm/intel/-/issues/3680
> Fixes: fe7d52bccab6 ("drm/i915/dp: Don't use DPCD backlights that need PWM
> enable/disable")
> Cc: # v5.12+
> ---
> .../drm/i915/display/intel_dp_aux_backlight.c | 24 ++-
> 1 file changed, 18 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> index 569d17b4d00f..594fdc7453ca 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> @@ -293,6 +293,10 @@ intel_dp_aux_vesa_enable_backlight(const struct
> intel_crtc_state *crtc_state,
> struct intel_panel *panel = >panel;
> struct intel_dp *intel_dp = enc_to_intel_dp(connector->encoder);
>
> + if (!panel->backlight.edp.vesa.info.aux_enable)
> + panel->backlight.pwm_funcs->enable(crtc_state, conn_state,
> +
> panel->backlight.pwm_level_max);
What't the story here with the non-inverted max vs. pontetially inverted
0 in the counterpart?
> +
> drm_edp_backlight_enable(_dp->aux,
> >backlight.edp.vesa.info, level);
> }
>
> @@ -304,6 +308,10 @@ static void intel_dp_aux_vesa_disable_backlight(const
> struct drm_connector_state
> struct intel_dp *intel_dp = enc_to_intel_dp(connector->encoder);
>
> drm_edp_backlight_disable(_dp->aux,
> >backlight.edp.vesa.info);
> +
> + if (!panel->backlight.edp.vesa.info.aux_enable)
> + panel->backlight.pwm_funcs->disable(old_conn_state,
> +
> intel_backlight_invert_pwm_level(connector, 0));
> }
>
> static int intel_dp_aux_vesa_setup_backlight(struct intel_connector
> *connector, enum pipe pipe)
> @@ -321,6 +329,15 @@ static int intel_dp_aux_vesa_setup_backlight(struct
> intel_connector *connector,
> if (ret < 0)
> return ret;
>
> + if (!panel->backlight.edp.vesa.info.aux_enable) {
> + ret = panel->backlight.pwm_funcs->setup(connector, pipe);
> + if (ret < 0) {
> + drm_err(>drm,
> + "Failed to setup PWM backlight controls for eDP
> backlight: %d\n",
> + ret);
> + return ret;
> + }
> + }
> panel->backlight.max = panel->backlight.edp.vesa.info.max;
> panel->backlight.min = 0;
> if (current_mode == DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD) {
> @@ -340,12 +357,7 @@ intel_dp_aux_supports_vesa_backlight(struct
> intel_connector *connector)
> struct intel_dp *intel_dp = intel_attached_dp(connector);
> struct drm_i915_private *i915 = dp_to_i915(intel_dp);
>
> - /* TODO: We currently only support AUX only backlight configurations,
> not backlights which
> - * require a mix of PWM and AUX controls to work. In the mean time,
> these machines typically
> - * work just fine using normal PWM controls anyway.
> - */
> - if ((intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP) &&
> - drm_edp_backlight_supported(intel_dp->edp_dpcd)) {
> + if (drm_edp_backlight_supported(intel_dp->edp_dpcd)) {
> drm_dbg_kms(>drm, "AUX Backlight Control Supported!\n");
> return true;
> }
> --
> 2.31.1
--
Ville Syrjälä
Intel
Re: [Nouveau] [Intel-gfx] [PATCH 01/15] gpu/drm: make drm_add_edid_modes() consistent when updating connector->display_info
On Fri, Oct 15, 2021 at 10:33:29PM +0300, Ville Syrjälä wrote:
> On Fri, Oct 15, 2021 at 09:24:06PM +0200, Claudio Suarez wrote:
> > On Fri, Oct 15, 2021 at 03:03:13PM +0300, Ville Syrjälä wrote:
> > > On Fri, Oct 15, 2021 at 01:36:59PM +0200, Claudio Suarez wrote:
> > > > According to the documentation, drm_add_edid_modes
> > > > "... Also fills out the _display_info structure and ELD in
> > > > @connector
> > > > with any information which can be derived from the edid."
> > > >
> > > > drm_add_edid_modes accepts a struct edid *edid parameter which may have
> > > > a
> > > > value or may be null. When it is not null, connector->display_info and
> > > > connector->eld are updated according to the edid. When edid=NULL, only
> > > > connector->eld is reset. Reset connector->display_info to be consistent
> > > > and accurate.
> > > >
> > > > Signed-off-by: Claudio Suarez
> > > > ---
> > > > drivers/gpu/drm/drm_edid.c | 2 ++
> > > > 1 file changed, 2 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > > > index 6325877c5fd6..6cbe09b2357c 100644
> > > > --- a/drivers/gpu/drm/drm_edid.c
> > > > +++ b/drivers/gpu/drm/drm_edid.c
> > > > @@ -5358,10 +5358,12 @@ int drm_add_edid_modes(struct drm_connector
> > > > *connector, struct edid *edid)
> > > >
> > > > if (edid == NULL) {
> > > > clear_eld(connector);
> > > > + drm_reset_display_info(connector);
> > > > return 0;
> > > > }
> > > > if (!drm_edid_is_valid(edid)) {
> > > > clear_eld(connector);
> > > > + drm_reset_display_info(connector);
> > >
> > > Looks easier if you pull both of those out from these branches and
> > > just call them unconditionally at the start.
> >
> > After looking at the full code, I am not sure. This is the code:
> > ==
> > int drm_add_edid_modes(struct drm_connector *connector, struct edid *edid)
> > {
> > int num_modes = 0;
> > u32 quirks;
> >
> > if (edid == NULL) {
> > clear_eld(connector);
> > drm_reset_display_info(connector); <--- added by me
> > return 0;
> > }
> > if (!drm_edid_is_valid(edid)) {
> > clear_eld(connector);
> > drm_reset_display_info(connector); <--- added by me
> > drm_warn(connector->dev, "%s: EDID invalid.\n",
> > connector->name);
> > return 0;
> > }
> >
> > drm_edid_to_eld(connector, edid);
> >
> > quirks = drm_add_display_info(connector, edid);
> > etc...
> > =
> >
> > If we move those out of these branches and edid != NULL, we are executing an
> > unnecessary clear_eld(connector) and an unnecessary
> > drm_reset_display_info(connector)
> > because the fields will be set in the next drm_edid_to_eld(connector, edid)
> > and
> > drm_add_display_info(connector, edid)
> >
> > Do we want this ?
>
> Seems fine by me. And maybe we could nuke the second
> drm_reset_display_info() from deeper inside drm_add_display_info()?
> Not sure if drm_add_display_info() still has to be able to operate
> standalone or not.
>
> Hmm. Another option is to just move all these NULL/invalid edid
> checks into drm_edid_to_eld() and drm_add_display_info().
But maybe that's not so easy. Would still need to bail out
from drm_add_edid_modes() I guess.
--
Ville Syrjälä
Intel
Re: [Nouveau] [PATCH 01/15] gpu/drm: make drm_add_edid_modes() consistent when updating connector->display_info
On Fri, Oct 15, 2021 at 09:24:06PM +0200, Claudio Suarez wrote:
> On Fri, Oct 15, 2021 at 03:03:13PM +0300, Ville Syrjälä wrote:
> > On Fri, Oct 15, 2021 at 01:36:59PM +0200, Claudio Suarez wrote:
> > > According to the documentation, drm_add_edid_modes
> > > "... Also fills out the _display_info structure and ELD in @connector
> > > with any information which can be derived from the edid."
> > >
> > > drm_add_edid_modes accepts a struct edid *edid parameter which may have a
> > > value or may be null. When it is not null, connector->display_info and
> > > connector->eld are updated according to the edid. When edid=NULL, only
> > > connector->eld is reset. Reset connector->display_info to be consistent
> > > and accurate.
> > >
> > > Signed-off-by: Claudio Suarez
> > > ---
> > > drivers/gpu/drm/drm_edid.c | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > > index 6325877c5fd6..6cbe09b2357c 100644
> > > --- a/drivers/gpu/drm/drm_edid.c
> > > +++ b/drivers/gpu/drm/drm_edid.c
> > > @@ -5358,10 +5358,12 @@ int drm_add_edid_modes(struct drm_connector
> > > *connector, struct edid *edid)
> > >
> > > if (edid == NULL) {
> > > clear_eld(connector);
> > > + drm_reset_display_info(connector);
> > > return 0;
> > > }
> > > if (!drm_edid_is_valid(edid)) {
> > > clear_eld(connector);
> > > + drm_reset_display_info(connector);
> >
> > Looks easier if you pull both of those out from these branches and
> > just call them unconditionally at the start.
>
> After looking at the full code, I am not sure. This is the code:
> ==
> int drm_add_edid_modes(struct drm_connector *connector, struct edid *edid)
> {
> int num_modes = 0;
> u32 quirks;
>
> if (edid == NULL) {
> clear_eld(connector);
> drm_reset_display_info(connector); <--- added by me
> return 0;
> }
> if (!drm_edid_is_valid(edid)) {
> clear_eld(connector);
> drm_reset_display_info(connector); <--- added by me
> drm_warn(connector->dev, "%s: EDID invalid.\n",
> connector->name);
> return 0;
> }
>
> drm_edid_to_eld(connector, edid);
>
> quirks = drm_add_display_info(connector, edid);
> etc...
> =
>
> If we move those out of these branches and edid != NULL, we are executing an
> unnecessary clear_eld(connector) and an unnecessary
> drm_reset_display_info(connector)
> because the fields will be set in the next drm_edid_to_eld(connector, edid)
> and
> drm_add_display_info(connector, edid)
>
> Do we want this ?
Seems fine by me. And maybe we could nuke the second
drm_reset_display_info() from deeper inside drm_add_display_info()?
Not sure if drm_add_display_info() still has to be able to operate
standalone or not.
Hmm. Another option is to just move all these NULL/invalid edid
checks into drm_edid_to_eld() and drm_add_display_info().
--
Ville Syrjälä
Intel
Re: [Nouveau] [Intel-gfx] [PATCH 15/15] drm/i915: replace drm_detect_hdmi_monitor() with drm_display_info.is_hdmi
On Fri, Oct 15, 2021 at 03:44:48PM +0300, Jani Nikula wrote:
> On Fri, 15 Oct 2021, Claudio Suarez wrote:
> > Once EDID is parsed, the monitor HDMI support information is available
> > through drm_display_info.is_hdmi. Retriving the same information with
> > drm_detect_hdmi_monitor() is less efficient. Change to
> > drm_display_info.is_hdmi where possible.
> >
> > This is a TODO task in Documentation/gpu/todo.rst
> >
> > Signed-off-by: Claudio Suarez
> > ---
> > drivers/gpu/drm/i915/display/intel_connector.c | 5 +
> > drivers/gpu/drm/i915/display/intel_connector.h | 1 +
> > drivers/gpu/drm/i915/display/intel_hdmi.c | 2 +-
> > drivers/gpu/drm/i915/display/intel_sdvo.c | 3 ++-
> > 4 files changed, 9 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_connector.c
> > b/drivers/gpu/drm/i915/display/intel_connector.c
> > index 9bed1ccecea0..3346b55df6e1 100644
> > --- a/drivers/gpu/drm/i915/display/intel_connector.c
> > +++ b/drivers/gpu/drm/i915/display/intel_connector.c
> > @@ -213,6 +213,11 @@ int intel_ddc_get_modes(struct drm_connector
> > *connector,
> > return ret;
> > }
> >
> > +bool intel_connector_is_hdmi_monitor(struct drm_connector *connector)
> > +{
> > + return connector->display_info.is_hdmi;
> > +}
> > +
>
> A helper like this belongs in drm, not i915. Seems useful in other
> drivers too.
Not sure it's actually helpful for i915. We end up having to root around
in the display_info in a lot of places anyway. So a helper for single
boolean seems a bit out of place perhaps.
--
Ville Syrjälä
Intel
Re: [Nouveau] [Intel-gfx] [PATCH 15/15] drm/i915: replace drm_detect_hdmi_monitor() with drm_display_info.is_hdmi
On Fri, Oct 15, 2021 at 01:37:13PM +0200, Claudio Suarez wrote:
> Once EDID is parsed, the monitor HDMI support information is available
> through drm_display_info.is_hdmi. Retriving the same information with
> drm_detect_hdmi_monitor() is less efficient. Change to
> drm_display_info.is_hdmi where possible.
>
> This is a TODO task in Documentation/gpu/todo.rst
>
> Signed-off-by: Claudio Suarez
> ---
> drivers/gpu/drm/i915/display/intel_connector.c | 5 +
> drivers/gpu/drm/i915/display/intel_connector.h | 1 +
> drivers/gpu/drm/i915/display/intel_hdmi.c | 2 +-
> drivers/gpu/drm/i915/display/intel_sdvo.c | 3 ++-
> 4 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_connector.c
> b/drivers/gpu/drm/i915/display/intel_connector.c
> index 9bed1ccecea0..3346b55df6e1 100644
> --- a/drivers/gpu/drm/i915/display/intel_connector.c
> +++ b/drivers/gpu/drm/i915/display/intel_connector.c
> @@ -213,6 +213,11 @@ int intel_ddc_get_modes(struct drm_connector *connector,
> return ret;
> }
>
> +bool intel_connector_is_hdmi_monitor(struct drm_connector *connector)
> +{
> + return connector->display_info.is_hdmi;
> +}
> +
> static const struct drm_prop_enum_list force_audio_names[] = {
> { HDMI_AUDIO_OFF_DVI, "force-dvi" },
> { HDMI_AUDIO_OFF, "off" },
> diff --git a/drivers/gpu/drm/i915/display/intel_connector.h
> b/drivers/gpu/drm/i915/display/intel_connector.h
> index 661a37a3c6d8..ceda6e72ece6 100644
> --- a/drivers/gpu/drm/i915/display/intel_connector.h
> +++ b/drivers/gpu/drm/i915/display/intel_connector.h
> @@ -27,6 +27,7 @@ enum pipe intel_connector_get_pipe(struct intel_connector
> *connector);
> int intel_connector_update_modes(struct drm_connector *connector,
>struct edid *edid);
> int intel_ddc_get_modes(struct drm_connector *c, struct i2c_adapter
> *adapter);
> +bool intel_connector_is_hdmi_monitor(struct drm_connector *connector);
> void intel_attach_force_audio_property(struct drm_connector *connector);
> void intel_attach_broadcast_rgb_property(struct drm_connector *connector);
> void intel_attach_aspect_ratio_property(struct drm_connector *connector);
> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
> b/drivers/gpu/drm/i915/display/intel_hdmi.c
> index b04685bb6439..2b1d7c5bebdd 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> @@ -2355,7 +2355,7 @@ intel_hdmi_set_edid(struct drm_connector *connector)
> to_intel_connector(connector)->detect_edid = edid;
> if (edid && edid->input & DRM_EDID_INPUT_DIGITAL) {
> intel_hdmi->has_audio = drm_detect_monitor_audio(edid);
> - intel_hdmi->has_hdmi_sink = drm_detect_hdmi_monitor(edid);
> + intel_hdmi->has_hdmi_sink =
> intel_connector_is_hdmi_monitor(connector);
Hmm. Have we parse the EDID by this point actually? I don't think that
was the case in the past but maybe it changed at some point.
>
> connected = true;
> }
> diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c
> b/drivers/gpu/drm/i915/display/intel_sdvo.c
> index 6cb27599ea03..a32279e4fee8 100644
> --- a/drivers/gpu/drm/i915/display/intel_sdvo.c
> +++ b/drivers/gpu/drm/i915/display/intel_sdvo.c
> @@ -2060,8 +2060,9 @@ intel_sdvo_tmds_sink_detect(struct drm_connector
> *connector)
> if (edid->input & DRM_EDID_INPUT_DIGITAL) {
> status = connector_status_connected;
> if (intel_sdvo_connector->is_hdmi) {
> - intel_sdvo->has_hdmi_monitor =
> drm_detect_hdmi_monitor(edid);
> intel_sdvo->has_hdmi_audio =
> drm_detect_monitor_audio(edid);
> + intel_sdvo->has_hdmi_monitor =
> +
> intel_connector_is_hdmi_monitor(connector);
FYI there's a third copy of this in intel_dp.c
> }
> } else
> status = connector_status_disconnected;
> --
> 2.33.0
>
--
Ville Syrjälä
Intel
Re: [Nouveau] [PATCH 01/15] gpu/drm: make drm_add_edid_modes() consistent when updating connector->display_info
On Fri, Oct 15, 2021 at 01:36:59PM +0200, Claudio Suarez wrote:
> According to the documentation, drm_add_edid_modes
> "... Also fills out the _display_info structure and ELD in @connector
> with any information which can be derived from the edid."
>
> drm_add_edid_modes accepts a struct edid *edid parameter which may have a
> value or may be null. When it is not null, connector->display_info and
> connector->eld are updated according to the edid. When edid=NULL, only
> connector->eld is reset. Reset connector->display_info to be consistent
> and accurate.
>
> Signed-off-by: Claudio Suarez
> ---
> drivers/gpu/drm/drm_edid.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 6325877c5fd6..6cbe09b2357c 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -5358,10 +5358,12 @@ int drm_add_edid_modes(struct drm_connector
> *connector, struct edid *edid)
>
> if (edid == NULL) {
> clear_eld(connector);
> + drm_reset_display_info(connector);
> return 0;
> }
> if (!drm_edid_is_valid(edid)) {
> clear_eld(connector);
> + drm_reset_display_info(connector);
Looks easier if you pull both of those out from these branches and
just call them unconditionally at the start.
> drm_warn(connector->dev, "%s: EDID invalid.\n",
>connector->name);
> return 0;
> --
> 2.33.0
>
>
--
Ville Syrjälä
Intel
Re: [Nouveau] [PATCH] Revert "drm/fb-helper: improve DRM fbdev emulation device names"
On Fri, Oct 08, 2021 at 09:17:08AM +0200, Javier Martinez Canillas wrote:
> This reverts commit b3484d2b03e4c940a9598aa841a52d69729c582a.
>
> That change attempted to improve the DRM drivers fbdev emulation device
> names to avoid having confusing names like "simpledrmdrmfb" in /proc/fb.
>
> But unfortunately there are user-space programs, such as pm-utils that
> query that information and so broke after the mentioned commit. Since
> the names in /proc/fb are used programs that consider it an ABI, let's
> restore the old names even when this lead to silly naming like the one
> mentioned above as an example.
The usage Johannes listed was this specificially:
using_kms() { grep -q -E '(nouveau|drm)fb' /proc/fb; }
So it actually looks like Daniel's
commit f243dd06180a ("drm/nouveau: Use drm_fb_helper_fill_info")
also broke the abi. But for the pm-utils use case at least
just having the "drmfb" in there should cover even nouveau.
Cc: sta...@vger.kernel.org
Reviewed-by: Ville Syrjälä
>
> Reported-by: Johannes Stezenbach
> Signed-off-by: Javier Martinez Canillas
> ---
>
> 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 3ab07832104..8993b02e783 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -1737,7 +1737,7 @@ void drm_fb_helper_fill_info(struct fb_info *info,
> sizes->fb_width, sizes->fb_height);
>
> info->par = fb_helper;
> - snprintf(info->fix.id, sizeof(info->fix.id), "%s",
> + snprintf(info->fix.id, sizeof(info->fix.id), "%sdrmfb",
>fb_helper->dev->driver->name);
>
> }
> --
> 2.31.1
--
Ville Syrjälä
Intel
Re: [Nouveau] [Intel-gfx] [PATCH v2 00/17] drm: cleanup: Use DRM_MODESET_LOCK_ALL_* helpers where possible
On Sun, Oct 03, 2021 at 12:32:14AM +0200, Fernando Ramos wrote: > On 21/10/02 09:13AM, Fernando Ramos wrote: > > > > Sean, could you revert the whole patch series? I'll have a deeper look into > > the > > patch set and come up with a v3 where all these issues will be addressed. > > > > Hi Sean, > > I now understand the nature of the issue that caused the problem with i915 and > have proceed to remove the global context structure (which revealed a similar > issue in the amdgpu driver). > > I have prepared a V3 version of the patch set where these issues should > hopefully be fixed for both the i915 and amdgpu drivers. > > In order to prevent causing more disruption, could you tell me what the proper > way to proceed would be? In particular: > > 1. Is there any place where I can push my changes so that they are tested > on a i915 machine? (Some type of automated pool) cc:intel-gfx, which it looks like you did, _but_ your patches did did not even apply against drm-tip so our CI rejected it. There was a reply to the patches from CI indicating that. And that is one reason I probably just ignored the whole thing. If it doesn't even apply/build it's not worth my time to read. > > 2. I can test the amdgpu driver on my machine but, what about all the other > architectures? What is the standard procedure? Should I simply publish V3 > and wait for feedback from the different vendors? (I would hate to cause > a > simular situation again) > > 3. Should I post V3 on top of drm-next or drm-misc-next? The normal rule is: always work on drm-tip. That is what gets tested by our CI as well. Yes, it does mean a bit of extra hurdles during development since drm-tip is a rebasing tree, but there are tools like dim retip to help out here. As for where to merge them. I would generally recommed against merging i915 patches through drm-misc unless there is a very compelling reason to do so. i915 is a fast moving target and if there are significant changes coming in via drm-misc they usually will cause conflicts for people during drm-tip rebuild. Also I would expect to see an ack requested from i915 maintainers for merging anything significant via drm-misc, which I don't think happened in this case. -- Ville Syrjälä Intel
Re: [Nouveau] [Intel-gfx] [PATCH v2 00/17] drm: cleanup: Use DRM_MODESET_LOCK_ALL_* helpers where possible
On Sat, Oct 02, 2021 at 07:28:02PM +0200, Fernando Ramos wrote:
> On 21/10/02 09:13AM, Fernando Ramos wrote:
> > On 21/10/02 05:30AM, Ville Syrjälä wrote:
> > > On Sat, Oct 02, 2021 at 01:05:47AM +0300, Ville Syrjälä wrote:
> > > > On Fri, Oct 01, 2021 at 04:48:15PM -0400, Sean Paul wrote:
> > > > > On Fri, Oct 01, 2021 at 10:00:50PM +0300, Ville Syrjälä wrote:
> > > > > > On Fri, Oct 01, 2021 at 02:36:55PM -0400, Sean Paul wrote:
> > > > > > >
> > > > > > > Thank you for revising, Fernando! I've pushed the set to
> > > > > > > drm-misc-next (along
> > > > > > > with the necessary drm-tip conflict resolutions).
> > > > > >
> > > > > > Ugh. Did anyone actually review the locking changes this does?
> > > > > > I shot the previous i915 stuff down because the commit messages
> > > > > > did not address any of it.
> > > > >
> > > > > I reviewed the set on 9/17, I didn't see your feedback on that thread.
> > > >
> > > > It was much earlir than that.
> > > > https://lists.freedesktop.org/archives/dri-devel/2021-June/313193.html
>
> Sorry, I'm new to this and it did not occur to me to search for similar
> patches
> in the mailing list archives in case there were additional comments that
> applied
> to my change set.
>
> In case I had done that I would have found that, as you mentioned, you had
> already raised two issues back in June:
>
> On Tue, Jun 29, 2021, Ville Syrjälä wrote:
> >
> > That looks wrong. You're using a private ctx here, but still
> > passing dev->mode_config.acquire_ctx to the lower level stuff.
> >
> > Also DRM_MODESET_LOCK_ALL_{BEGIN,END}() do not seem to be
> > equivalent to drm_modeset_{lock,unlock}_all() when it comes to
> > mode_config.mutex. So would need a proper review whether we
> > actually need that lock or not.
>
> The first one was pointing out the same error I would later repeat in my patch
> series (ups).
>
> After further inspection of the code it looks to me that changing this:
>
> intel_modeset_setup_hw_state(dev, dev->mode_config.acquire_ctx);
>
> ...into this:
>
> intel_modeset_setup_hw_state(dev, );
>
> ...would be enough.
Yes.
>
> Why? The only difference between the old drm_modeset_{lock,unlock}_all()
> functions and the new DRM_MODESET_LOCK_ALL_{BEGIN,END}() macros is that the
> former use a global context stored in dev->mode_config.acquire_ctx while the
> latter depend on a user provided one (typically in the stack).
>
> In the old (working) code the global context structure is freed in
> drm_modeset_unlock_all() thus we are sure no one is holding a reference to it
> at
> that point. This means that as long as no one accesses the global
> dev->mode_config.acquire_ctx context in the block that runs between lock/BEGIN
> and unlock/END, the code should be equivalent before and after my changes.
>
> In fact, now that my patch series removes the drm_modeset_{lock,unlock}_all()
> functions, the acquire_ctx field of the drm_mode_config structure should be
> deleted:
>
> /**
> * @acquire_ctx:
> *
> * Global implicit acquire context used by atomic drivers for legacy
> * IOCTLs. Deprecated, since implicit locking contexts make it
> * impossible to use driver-private drm_modeset_lock. Users of
> * this must hold @mutex.
> */
> struct drm_modeset_acquire_ctx *acquire_ctx;
>
> If I had done that (ie. removing this field) I would have detected the problem
> when compiling.
>
> There is another place (in the amdgpu driver) where this field is still being
> referenced, but before I investigate that I would like to know if you agree
> that
> this is a good path to follow.
Yeah, removing the mode_config.acquire_ctx is a good idea if it's
no longer needed.
>
> Regarding the second issue you raised...
>
> > Also DRM_MODESET_LOCK_ALL_{BEGIN,END}() do not seem to be
> > equivalent to drm_modeset_{lock,unlock}_all() when it comes to
> > mode_config.mutex. So would need a proper review whether we
> > actually need that lock or not.
>
> ...the only difference regarding mode_config.mutex I see is that in the new
> macros the mutex is locked only under this condition:
>
> if (!drm_drv_uses_atomic_modeset(dev))
>
> ...which seems reasonable, right? Is this what you were referring to or is it
> something else?
In order to eliminate the lock one first has to determine what that lock
might be protecting here, and then prove that such protection is not
actually needed.
--
Ville Syrjälä
Intel
Re: [Nouveau] [Intel-gfx] [PATCH v2 00/17] drm: cleanup: Use DRM_MODESET_LOCK_ALL_* helpers where possible
On Sat, Oct 02, 2021 at 01:05:47AM +0300, Ville Syrjälä wrote:
> On Fri, Oct 01, 2021 at 04:48:15PM -0400, Sean Paul wrote:
> > On Fri, Oct 01, 2021 at 10:00:50PM +0300, Ville Syrjälä wrote:
> > > On Fri, Oct 01, 2021 at 02:36:55PM -0400, Sean Paul wrote:
> > > > On Fri, Sep 24, 2021 at 08:43:07AM +0200, Fernando Ramos wrote:
> > > > > Hi all,
> > > > >
> > > > > One of the things in the DRM TODO list ("Documentation/gpu/todo.rst")
> > > > > was to
> > > > > "use DRM_MODESET_LOCAL_ALL_* helpers instead of boilerplate". That's
> > > > > what this
> > > > > patch series is about.
> > > > >
> > > > > You will find two types of changes here:
> > > > >
> > > > > - Replacing "drm_modeset_lock_all_ctx()" (and surrounding
> > > > > boilerplate) with
> > > > > "DRM_MODESET_LOCK_ALL_BEGIN()/END()" in the remaining places (as
> > > > > it has
> > > > > already been done in previous commits such as b7ea04d2)
> > > > >
> > > > > - Replacing "drm_modeset_lock_all()" with
> > > > > "DRM_MODESET_LOCK_ALL_BEGIN()/END()"
> > > > > in the remaining places (as it has already been done in previous
> > > > > commits
> > > > > such as 57037094)
> > > > >
> > > > > Most of the changes are straight forward, except for a few cases in
> > > > > the "amd"
> > > > > and "i915" drivers where some extra dancing was needed to overcome the
> > > > > limitation that the DRM_MODESET_LOCK_ALL_BEGIN()/END() macros can
> > > > > only be used
> > > > > once inside the same function (the reason being that the macro
> > > > > expansion
> > > > > includes *labels*, and you can not have two labels named the same
> > > > > inside one
> > > > > function)
> > > > >
> > > > > Notice that, even after this patch series, some places remain where
> > > > > "drm_modeset_lock_all()" and "drm_modeset_lock_all_ctx()" are still
> > > > > present,
> > > > > all inside drm core (which makes sense), except for two (in "amd" and
> > > > > "i915")
> > > > > which cannot be replaced due to the way they are being used.
> > > > >
> > > > > Changes in v2:
> > > > >
> > > > > - Fix commit message typo
> > > > > - Use the value returned by DRM_MODESET_LOCK_ALL_END when possible
> > > > > - Split drm/i915 patch into two simpler ones
> > > > > - Remove drm_modeset_(un)lock_all()
> > > > > - Fix build problems in non-x86 platforms
> > > > >
> > > > > Fernando Ramos (17):
> > > > > drm: cleanup: drm_modeset_lock_all_ctx() -->
> > > > > DRM_MODESET_LOCK_ALL_BEGIN()
> > > > > drm/i915: cleanup: drm_modeset_lock_all_ctx() -->
> > > > > DRM_MODESET_LOCK_ALL_BEGIN()
> > > > > drm/msm: cleanup: drm_modeset_lock_all_ctx() -->
> > > > > DRM_MODESET_LOCK_ALL_BEGIN()
> > > > > drm: cleanup: drm_modeset_lock_all() -->
> > > > > DRM_MODESET_LOCK_ALL_BEGIN() drm/vmwgfx: cleanup:
> > > > > drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
> > > > > drm/tegra: cleanup: drm_modeset_lock_all() -->
> > > > > DRM_MODESET_LOCK_ALL_BEGIN()
> > > > > drm/shmobile: cleanup: drm_modeset_lock_all() -->
> > > > > DRM_MODESET_LOCK_ALL_BEGIN()
> > > > > drm/radeon: cleanup: drm_modeset_lock_all() -->
> > > > > DRM_MODESET_LOCK_ALL_BEGIN()
> > > > > drm/omapdrm: cleanup: drm_modeset_lock_all() -->
> > > > > DRM_MODESET_LOCK_ALL_BEGIN()
> > > > > drm/nouveau: cleanup: drm_modeset_lock_all() -->
> > > > > DRM_MODESET_LOCK_ALL_BEGIN()
> > > > > drm/msm: cleanup: drm_modeset_lock_all() -->
> > > > > DRM_MODESET_LOCK_ALL_BEGIN()
> > > > > drm/i915: cleanup: drm_modeset_lock_all() -->
> > > > > DRM_MODESET_LOCK_ALL_BEGIN()
> > > > > drm/i915: cleanup: drm_modeset_lock_all() -->
> > > > > DRM_MODESET_LOCK_ALL_BEGIN() part 2
> &
Re: [Nouveau] [PATCH v2 00/17] drm: cleanup: Use DRM_MODESET_LOCK_ALL_* helpers where possible
On Fri, Oct 01, 2021 at 04:48:15PM -0400, Sean Paul wrote:
> On Fri, Oct 01, 2021 at 10:00:50PM +0300, Ville Syrjälä wrote:
> > On Fri, Oct 01, 2021 at 02:36:55PM -0400, Sean Paul wrote:
> > > On Fri, Sep 24, 2021 at 08:43:07AM +0200, Fernando Ramos wrote:
> > > > Hi all,
> > > >
> > > > One of the things in the DRM TODO list ("Documentation/gpu/todo.rst")
> > > > was to
> > > > "use DRM_MODESET_LOCAL_ALL_* helpers instead of boilerplate". That's
> > > > what this
> > > > patch series is about.
> > > >
> > > > You will find two types of changes here:
> > > >
> > > > - Replacing "drm_modeset_lock_all_ctx()" (and surrounding
> > > > boilerplate) with
> > > > "DRM_MODESET_LOCK_ALL_BEGIN()/END()" in the remaining places (as it
> > > > has
> > > > already been done in previous commits such as b7ea04d2)
> > > >
> > > > - Replacing "drm_modeset_lock_all()" with
> > > > "DRM_MODESET_LOCK_ALL_BEGIN()/END()"
> > > > in the remaining places (as it has already been done in previous
> > > > commits
> > > > such as 57037094)
> > > >
> > > > Most of the changes are straight forward, except for a few cases in the
> > > > "amd"
> > > > and "i915" drivers where some extra dancing was needed to overcome the
> > > > limitation that the DRM_MODESET_LOCK_ALL_BEGIN()/END() macros can only
> > > > be used
> > > > once inside the same function (the reason being that the macro expansion
> > > > includes *labels*, and you can not have two labels named the same
> > > > inside one
> > > > function)
> > > >
> > > > Notice that, even after this patch series, some places remain where
> > > > "drm_modeset_lock_all()" and "drm_modeset_lock_all_ctx()" are still
> > > > present,
> > > > all inside drm core (which makes sense), except for two (in "amd" and
> > > > "i915")
> > > > which cannot be replaced due to the way they are being used.
> > > >
> > > > Changes in v2:
> > > >
> > > > - Fix commit message typo
> > > > - Use the value returned by DRM_MODESET_LOCK_ALL_END when possible
> > > > - Split drm/i915 patch into two simpler ones
> > > > - Remove drm_modeset_(un)lock_all()
> > > > - Fix build problems in non-x86 platforms
> > > >
> > > > Fernando Ramos (17):
> > > > drm: cleanup: drm_modeset_lock_all_ctx() -->
> > > > DRM_MODESET_LOCK_ALL_BEGIN()
> > > > drm/i915: cleanup: drm_modeset_lock_all_ctx() -->
> > > > DRM_MODESET_LOCK_ALL_BEGIN()
> > > > drm/msm: cleanup: drm_modeset_lock_all_ctx() -->
> > > > DRM_MODESET_LOCK_ALL_BEGIN()
> > > > drm: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
> > > > drm/vmwgfx: cleanup: drm_modeset_lock_all() -->
> > > > DRM_MODESET_LOCK_ALL_BEGIN()
> > > > drm/tegra: cleanup: drm_modeset_lock_all() -->
> > > > DRM_MODESET_LOCK_ALL_BEGIN()
> > > > drm/shmobile: cleanup: drm_modeset_lock_all() -->
> > > > DRM_MODESET_LOCK_ALL_BEGIN()
> > > > drm/radeon: cleanup: drm_modeset_lock_all() -->
> > > > DRM_MODESET_LOCK_ALL_BEGIN()
> > > > drm/omapdrm: cleanup: drm_modeset_lock_all() -->
> > > > DRM_MODESET_LOCK_ALL_BEGIN()
> > > > drm/nouveau: cleanup: drm_modeset_lock_all() -->
> > > > DRM_MODESET_LOCK_ALL_BEGIN()
> > > > drm/msm: cleanup: drm_modeset_lock_all() -->
> > > > DRM_MODESET_LOCK_ALL_BEGIN()
> > > > drm/i915: cleanup: drm_modeset_lock_all() -->
> > > > DRM_MODESET_LOCK_ALL_BEGIN()
> > > > drm/i915: cleanup: drm_modeset_lock_all() -->
> > > > DRM_MODESET_LOCK_ALL_BEGIN() part 2
> > > > drm/gma500: cleanup: drm_modeset_lock_all() -->
> > > > DRM_MODESET_LOCK_ALL_BEGIN()
> > > > drm/amd: cleanup: drm_modeset_lock_all() -->
> > > > DRM_MODESET_LOCK_ALL_BEGIN()
> > > > drm: cleanup: remove drm_modeset_(un)lock_all()
> > > > doc: drm: remove TODO entry regarding DRM_MODSET_LOCK_ALL cleanup
> > > >
> > >
> > > Thank you for revising, Fernando! I've pushed the set to drm-misc-next
> > > (along
> > > with the necessary drm-tip conflict resolutions).
> >
> > Ugh. Did anyone actually review the locking changes this does?
> > I shot the previous i915 stuff down because the commit messages
> > did not address any of it.
>
> I reviewed the set on 9/17, I didn't see your feedback on that thread.
It was much earlir than that.
https://lists.freedesktop.org/archives/dri-devel/2021-June/313193.html
And I think I might have also shot down a similar thing earlier.
I was actually half considering sending a patch to nuke that
misleading TODO item. I don't think anything which changes
which locks are taken should be considred a starter level task.
And the commit messages here don't seem to address any of it.
--
Ville Syrjälä
Intel
Re: [Nouveau] [PATCH v2 00/17] drm: cleanup: Use DRM_MODESET_LOCK_ALL_* helpers where possible
On Fri, Oct 01, 2021 at 02:36:55PM -0400, Sean Paul wrote:
> On Fri, Sep 24, 2021 at 08:43:07AM +0200, Fernando Ramos wrote:
> > Hi all,
> >
> > One of the things in the DRM TODO list ("Documentation/gpu/todo.rst") was to
> > "use DRM_MODESET_LOCAL_ALL_* helpers instead of boilerplate". That's what
> > this
> > patch series is about.
> >
> > You will find two types of changes here:
> >
> > - Replacing "drm_modeset_lock_all_ctx()" (and surrounding boilerplate)
> > with
> > "DRM_MODESET_LOCK_ALL_BEGIN()/END()" in the remaining places (as it has
> > already been done in previous commits such as b7ea04d2)
> >
> > - Replacing "drm_modeset_lock_all()" with
> > "DRM_MODESET_LOCK_ALL_BEGIN()/END()"
> > in the remaining places (as it has already been done in previous commits
> > such as 57037094)
> >
> > Most of the changes are straight forward, except for a few cases in the
> > "amd"
> > and "i915" drivers where some extra dancing was needed to overcome the
> > limitation that the DRM_MODESET_LOCK_ALL_BEGIN()/END() macros can only be
> > used
> > once inside the same function (the reason being that the macro expansion
> > includes *labels*, and you can not have two labels named the same inside one
> > function)
> >
> > Notice that, even after this patch series, some places remain where
> > "drm_modeset_lock_all()" and "drm_modeset_lock_all_ctx()" are still present,
> > all inside drm core (which makes sense), except for two (in "amd" and
> > "i915")
> > which cannot be replaced due to the way they are being used.
> >
> > Changes in v2:
> >
> > - Fix commit message typo
> > - Use the value returned by DRM_MODESET_LOCK_ALL_END when possible
> > - Split drm/i915 patch into two simpler ones
> > - Remove drm_modeset_(un)lock_all()
> > - Fix build problems in non-x86 platforms
> >
> > Fernando Ramos (17):
> > drm: cleanup: drm_modeset_lock_all_ctx() --> DRM_MODESET_LOCK_ALL_BEGIN()
> > drm/i915: cleanup: drm_modeset_lock_all_ctx() -->
> > DRM_MODESET_LOCK_ALL_BEGIN()
> > drm/msm: cleanup: drm_modeset_lock_all_ctx() -->
> > DRM_MODESET_LOCK_ALL_BEGIN()
> > drm: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
> > drm/vmwgfx: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
> > drm/tegra: cleanup: drm_modeset_lock_all() -->
> > DRM_MODESET_LOCK_ALL_BEGIN()
> > drm/shmobile: cleanup: drm_modeset_lock_all() -->
> > DRM_MODESET_LOCK_ALL_BEGIN()
> > drm/radeon: cleanup: drm_modeset_lock_all() -->
> > DRM_MODESET_LOCK_ALL_BEGIN()
> > drm/omapdrm: cleanup: drm_modeset_lock_all() -->
> > DRM_MODESET_LOCK_ALL_BEGIN()
> > drm/nouveau: cleanup: drm_modeset_lock_all() -->
> > DRM_MODESET_LOCK_ALL_BEGIN()
> > drm/msm: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
> > drm/i915: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
> > drm/i915: cleanup: drm_modeset_lock_all() -->
> > DRM_MODESET_LOCK_ALL_BEGIN() part 2
> > drm/gma500: cleanup: drm_modeset_lock_all() -->
> > DRM_MODESET_LOCK_ALL_BEGIN()
> > drm/amd: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
> > drm: cleanup: remove drm_modeset_(un)lock_all()
> > doc: drm: remove TODO entry regarding DRM_MODSET_LOCK_ALL cleanup
> >
>
> Thank you for revising, Fernando! I've pushed the set to drm-misc-next (along
> with the necessary drm-tip conflict resolutions).
Ugh. Did anyone actually review the locking changes this does?
I shot the previous i915 stuff down because the commit messages
did not address any of it.
--
Ville Syrjälä
Intel
Re: [Nouveau] [PATCH v3 03/20] drm/dp: Move i2c init to drm_dp_aux_init, add __must_check and fini
On Mon, Apr 19, 2021 at 06:55:05PM -0400, Lyude Paul wrote: > When moving around drm_dp_aux_register() calls, it turned out we > accidentally managed to cause issues with the Tegra driver due to the fact > the Tegra driver would attempt to retrieve a reference to the AUX channel's > i2c adapter - which wouldn't be initialized until drm_dp_aux_register() is > called. > > This doesn't actually make a whole ton of sense, as it's not unexpected for > a driver to need to be able to use an AUX adapter before it's been > registered. Likewise-it's not unexpected for a driver to try using the i2c > adapter for said AUX channel before it's been registered as well. In fact, > the current documentation for drm_dp_aux_init() even seems to imply that > drm_dp_aux_init() is supposed to be handling i2c adapter creation for this > precise reason - not drm_dp_aux_register(). > > Since the i2c adapter doesn't need to be linked to the DRM device in any > way, we can just fix this problem by moving i2c adapter creation out of > drm_dp_aux_register() and into drm_dp_aux_init(). Additionally, since this > means that drm_dp_aux_init() can fail we go ahead and add a __must_check > attribute to it so that drivers don't ignore its return status on failures. > And finally, we add a drm_dp_aux_fini() and hook it up in all DRM drivers > across the kernel to take care of cleaning up the i2c adapter once it's no > longer needed. > > This should also fix the regressions noted in the Tegra driver. The init vs. register split is intentional. Registering the thing and allowing userspace access to it before the rest of the driver is ready isn't particularly great. For a while now we've tried to move towards an architecture where the driver is fully initialzied before anything gets exposed to userspace. -- Ville Syrjälä Intel ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [igt-dev] [PATCH i-g-t v2] lib: Introduce the igt_nouveau library
igt_nouveau_munmap_bo(fb);
> + else
> + gem_munmap(ptr, fb->size);
>
> if (fb->is_dumb)
> igt_dirty_fb(fb->fd, fb);
> @@ -2553,6 +2622,8 @@ static void *map_bo(int fd, struct igt_fb *fb)
> else if (is_amdgpu_device(fd))
> ptr = igt_amd_mmap_bo(fd, fb->gem_handle, fb->size,
> PROT_READ | PROT_WRITE);
> + else if (is_nouveau_device(fd))
> + ptr = igt_nouveau_mmap_bo(fb, PROT_READ | PROT_WRITE);
> else
> igt_assert(false);
>
> @@ -3569,13 +3640,13 @@ static void create_cairo_surface__convert(int fd,
> struct igt_fb *fb)
>>shadow_fb);
> igt_assert(blit->shadow_ptr);
>
> - if (use_enginecopy(fb) || use_blitter(fb) ||
> - igt_vc4_is_tiled(fb->modifier)) {
> + /* Note for nouveau, it's currently faster to copy fbs to/from vram
> (even linear ones) */
> + if (use_enginecopy(fb) || use_blitter(fb) ||
> igt_vc4_is_tiled(fb->modifier) ||
> + is_nouveau_device(fd)) {
> setup_linear_mapping(>base);
>
> /* speed things up by working from a copy in system memory */
> - cvt.src.slow_reads =
> - is_i915_device(fd) && !gem_has_mappable_ggtt(fd);
> + cvt.src.slow_reads = is_i915_device(fd) &&
> !gem_has_mappable_ggtt(fd);
> } else {
> blit->base.linear.fb = *fb;
> blit->base.linear.fb.gem_handle = 0;
> @@ -3659,7 +3730,8 @@ cairo_surface_t *igt_get_cairo_surface(int fd, struct
> igt_fb *fb)
> create_cairo_surface__convert(fd, fb);
> else if (use_blitter(fb) || use_enginecopy(fb) ||
>igt_vc4_is_tiled(fb->modifier) ||
> - igt_amd_is_tiled(fb->modifier))
> + igt_amd_is_tiled(fb->modifier) ||
> + is_nouveau_device(fb->fd))
> create_cairo_surface__gpu(fd, fb);
> else
> create_cairo_surface__gtt(fd, fb);
> @@ -3733,6 +3805,8 @@ void igt_remove_fb(int fd, struct igt_fb *fb)
> do_or_die(drmModeRmFB(fd, fb->fb_id));
> if (fb->is_dumb)
> kmstest_dumb_destroy(fd, fb->gem_handle);
> + else if (is_nouveau_device(fd))
> + igt_nouveau_delete_bo(fb);
> else
> gem_close(fd, fb->gem_handle);
> fb->fb_id = 0;
> diff --git a/lib/igt_fb.h b/lib/igt_fb.h
> index 0d64898a..2c2b8265 100644
> --- a/lib/igt_fb.h
> +++ b/lib/igt_fb.h
> @@ -71,6 +71,7 @@ struct buf_ops;
> * @plane_bpp: The bpp for each plane.
> * @plane_width: The width for each plane.
> * @plane_height: The height for each plane.
> + * @driver_priv: Private driver-specific data, if any
> *
> * Tracking structure for KMS framebuffer objects.
> */
> @@ -94,6 +95,7 @@ typedef struct igt_fb {
> unsigned int plane_bpp[4];
> unsigned int plane_width[4];
> unsigned int plane_height[4];
> + void *driver_priv;
As mentioned on irc this looks a bit redundant and could just do
the gem_handle->bo lookup as needed.
No idea about the nouveau specifics, but the igt_fb.c stuff looks
as good as what else we have there, so for that reason
Reviewed-by: Ville Syrjälä
In general the amount of driver if-else ladders is starting to
get a bit out of hand. We may want to begin thinking about some
refactoring to clean it up. But I guess step one there might be
just to suck out all the i915 specific stuff into its own file...
> } igt_fb_t;
>
> /**
> diff --git a/lib/igt_nouveau.c b/lib/igt_nouveau.c
> new file mode 100644
> index ..ae6104e3
> --- /dev/null
> +++ b/lib/igt_nouveau.c
> @@ -0,0 +1,281 @@
> +/*
> + * Copyright 2021 Red Hat Inc.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES O
Re: [Nouveau] [igt-dev] [PATCH i-g-t v3] tests/kms_cursor_crc: Probe kernel for cursor size support
On Tue, Mar 23, 2021 at 01:25:13PM -0400, Lyude wrote: > From: Lyude Paul > > Currently we just assume that every cursor size up to data->cursor_max_w/h > will > be supported by the driver, and check for support of nonsquare cursors by > checking if we're running on u815 and if so, which variant of intel hardware > we're running on. This isn't really ideal as we're about to enable 32x32 > cursor > size tests for nouveau, and Intel hardware doesn't support cursor sizes that > small. > > So, fix this by removing has_nonsquare_cursors() and replacing it with a more > generic require_cursor_size() function which checks whether or not the driver > we're using supports a given cursor size by attempting a test-only atomic > commit. > > v3: > * Also probe for cursor support on systems without atomic support Gave this a go on my i865, and after removing a bogus max_w==max_h assert it all passed, and your non-square probing worked fine. I'll need to send a patch to nuke that bogus assert, and I also had an idea to test the max sized cursor as well (in case it's not square and thus not being tested already)... with the s/u815/i915/ Petri pointed out Reviewed-by: Ville Syrjälä -- Ville Syrjälä Intel ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [igt-dev] [PATCH i-g-t v2 1/2] tests/kms_cursor_crc: Probe kernel for cursor size support
On Fri, Mar 19, 2021 at 02:43:56PM -0400, Lyude Paul wrote:
> On Fri, 2021-03-19 at 20:00 +0200, Ville Syrjälä wrote:
> > On Fri, Mar 19, 2021 at 01:40:52PM -0400, Lyude Paul wrote:
> > > On Fri, 2021-03-19 at 17:01 +0200, Ville Syrjälä wrote:
> > > > On Thu, Mar 18, 2021 at 06:21:23PM -0400, Lyude wrote:
> > > > > From: Lyude Paul
> > > > >
> > > > > Currently we just assume that every cursor size up to data-
> > > > > >cursor_max_w/h
> > > > > will
> > > > > be supported by the driver, and check for support of nonsquare cursors
> > > > > by
> > > > > checking if we're running on u815 and if so, which variant of intel
> > > > > hardware
> > > > > we're running on. This isn't really ideal as we're about to enable
> > > > > 32x32
> > > > > cursor
> > > > > size tests for nouveau, and Intel hardware doesn't support cursor
> > > > > sizes
> > > > > that
> > > > > small.
> > > > >
> > > > > So, fix this by removing has_nonsquare_cursors() and replacing it
> > > > > with a
> > > > > more
> > > > > generic require_cursor_size() function which checks whether or not the
> > > > > driver
> > > > > we're using supports a given cursor size by attempting a test-only
> > > > > atomic
> > > > > commit.
> > > > >
> > > > > Signed-off-by: Lyude Paul
> > > > > Cc: Martin Peres
> > > > > Cc: Ben Skeggs
> > > > > Cc: Jeremy Cline
> > > > > ---
> > > > > tests/kms_cursor_crc.c | 131
> > > > > -
> > > > > 1 file changed, 76 insertions(+), 55 deletions(-)
> > > > >
> > > > > diff --git a/tests/kms_cursor_crc.c b/tests/kms_cursor_crc.c
> > > > > index 3541ea06..b9c05472 100644
> > > > > --- a/tests/kms_cursor_crc.c
> > > > > +++ b/tests/kms_cursor_crc.c
> > > > > @@ -523,26 +523,43 @@ static void create_cursor_fb(data_t *data, int
> > > > > cur_w,
> > > > > int cur_h)
> > > > > igt_put_cairo_ctx(cr);
> > > > > }
> > > > >
> > > > > -static bool has_nonsquare_cursors(data_t *data)
> > > > > +static void require_cursor_size(data_t *data, int w, int h)
> > > > > {
> > > > > - uint32_t devid;
> > > > > + igt_fb_t primary_fb;
> > > > > + drmModeModeInfo *mode;
> > > > > + igt_display_t *display = >display;
> > > > > + igt_output_t *output = data->output;
> > > > > + igt_plane_t *primary, *cursor;
> > > > > + int ret;
> > > > >
> > > > > - if (!is_i915_device(data->drm_fd))
> > > > > - return false;
> > > > > + igt_output_set_pipe(output, data->pipe);
> > > > >
> > > > > - devid = intel_get_drm_devid(data->drm_fd);
> > > > > + mode = igt_output_get_mode(output);
> > > > > + primary = igt_output_get_plane_type(output,
> > > > > DRM_PLANE_TYPE_PRIMARY);
> > > > > + cursor = igt_output_get_plane_type(output,
> > > > > DRM_PLANE_TYPE_CURSOR);
> > > > >
> > > > > - /*
> > > > > - * Test non-square cursors a bit on the platforms
> > > > > - * that support such things.
> > > > > - */
> > > > > - if (devid == PCI_CHIP_845_G || devid == PCI_CHIP_I865_G)
> > > > > - return true;
> > > > > + /* Create temporary primary fb for testing */
> > > > > + igt_assert(igt_create_fb(data->drm_fd, mode->hdisplay, mode-
> > > > > > vdisplay, DRM_FORMAT_XRGB,
> > > > > + LOCAL_DRM_FORMAT_MOD_NONE,
> > > > > _fb));
> > > > >
> > > > > - if (IS_VALLEYVIEW(devid) || IS_CHERRYVIEW(devid))
> > > > > - return false;
> > > > > + igt_plane_set_fb(primary, _fb);
> > > > > + igt_plane_set_fb(cursor, >fb);
> > > > > + igt_plane_set_size(cursor, w, h);
> > > > > + igt_fb_set_size(>fb, cursor, w, h);
> > > > > +
> > > > > + /* Test if the kernel supports the given cursor size or not */
> > > > > + ret = igt_display_try_commit_atomic(display,
> > > > > + DRM_MODE_ATOMIC_TEST_ONLY
> > > > > |
> > > > > +
> > > > > DRM_MODE_ATOMIC_ALLOW_MODESET,
> > > > > + NULL);
> > > >
> > > > Would be better to not depend on atomic. We have platforms
> > > > that don't expose it yet.
> > >
> > > Do you have any other ideas how we could probe for this then? it seems
> > > like
> > > the
> > > only alternative would be to add intel-specific checks to fix that, or add
> > > some
> > > ioctl for querying the minimum cursor size (which sounds preferable imo).
> > > would
> > > the latter work for you, or do you have another idea?
> >
> > Just do it for real instead of TEST_ONLY.
>
> ah-and it'll still fail in that case I assume?
Yeah, should fail just the same if the driver doesn't like it.
--
Ville Syrjälä
Intel
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [igt-dev] [PATCH i-g-t v2 1/2] tests/kms_cursor_crc: Probe kernel for cursor size support
On Fri, Mar 19, 2021 at 01:40:52PM -0400, Lyude Paul wrote:
> On Fri, 2021-03-19 at 17:01 +0200, Ville Syrjälä wrote:
> > On Thu, Mar 18, 2021 at 06:21:23PM -0400, Lyude wrote:
> > > From: Lyude Paul
> > >
> > > Currently we just assume that every cursor size up to data->cursor_max_w/h
> > > will
> > > be supported by the driver, and check for support of nonsquare cursors by
> > > checking if we're running on u815 and if so, which variant of intel
> > > hardware
> > > we're running on. This isn't really ideal as we're about to enable 32x32
> > > cursor
> > > size tests for nouveau, and Intel hardware doesn't support cursor sizes
> > > that
> > > small.
> > >
> > > So, fix this by removing has_nonsquare_cursors() and replacing it with a
> > > more
> > > generic require_cursor_size() function which checks whether or not the
> > > driver
> > > we're using supports a given cursor size by attempting a test-only atomic
> > > commit.
> > >
> > > Signed-off-by: Lyude Paul
> > > Cc: Martin Peres
> > > Cc: Ben Skeggs
> > > Cc: Jeremy Cline
> > > ---
> > > tests/kms_cursor_crc.c | 131 -
> > > 1 file changed, 76 insertions(+), 55 deletions(-)
> > >
> > > diff --git a/tests/kms_cursor_crc.c b/tests/kms_cursor_crc.c
> > > index 3541ea06..b9c05472 100644
> > > --- a/tests/kms_cursor_crc.c
> > > +++ b/tests/kms_cursor_crc.c
> > > @@ -523,26 +523,43 @@ static void create_cursor_fb(data_t *data, int
> > > cur_w,
> > > int cur_h)
> > > igt_put_cairo_ctx(cr);
> > > }
> > >
> > > -static bool has_nonsquare_cursors(data_t *data)
> > > +static void require_cursor_size(data_t *data, int w, int h)
> > > {
> > > - uint32_t devid;
> > > + igt_fb_t primary_fb;
> > > + drmModeModeInfo *mode;
> > > + igt_display_t *display = >display;
> > > + igt_output_t *output = data->output;
> > > + igt_plane_t *primary, *cursor;
> > > + int ret;
> > >
> > > - if (!is_i915_device(data->drm_fd))
> > > - return false;
> > > + igt_output_set_pipe(output, data->pipe);
> > >
> > > - devid = intel_get_drm_devid(data->drm_fd);
> > > + mode = igt_output_get_mode(output);
> > > + primary = igt_output_get_plane_type(output,
> > > DRM_PLANE_TYPE_PRIMARY);
> > > + cursor = igt_output_get_plane_type(output, DRM_PLANE_TYPE_CURSOR);
> > >
> > > - /*
> > > - * Test non-square cursors a bit on the platforms
> > > - * that support such things.
> > > - */
> > > - if (devid == PCI_CHIP_845_G || devid == PCI_CHIP_I865_G)
> > > - return true;
> > > + /* Create temporary primary fb for testing */
> > > + igt_assert(igt_create_fb(data->drm_fd, mode->hdisplay, mode-
> > > >vdisplay, DRM_FORMAT_XRGB,
> > > + LOCAL_DRM_FORMAT_MOD_NONE, _fb));
> > >
> > > - if (IS_VALLEYVIEW(devid) || IS_CHERRYVIEW(devid))
> > > - return false;
> > > + igt_plane_set_fb(primary, _fb);
> > > + igt_plane_set_fb(cursor, >fb);
> > > + igt_plane_set_size(cursor, w, h);
> > > + igt_fb_set_size(>fb, cursor, w, h);
> > > +
> > > + /* Test if the kernel supports the given cursor size or not */
> > > + ret = igt_display_try_commit_atomic(display,
> > > + DRM_MODE_ATOMIC_TEST_ONLY |
> > > + DRM_MODE_ATOMIC_ALLOW_MODESET,
> > > + NULL);
> >
> > Would be better to not depend on atomic. We have platforms
> > that don't expose it yet.
>
> Do you have any other ideas how we could probe for this then? it seems like
> the
> only alternative would be to add intel-specific checks to fix that, or add
> some
> ioctl for querying the minimum cursor size (which sounds preferable imo).
> would
> the latter work for you, or do you have another idea?
Just do it for real instead of TEST_ONLY.
> >
> > > +
> > > + igt_plane_set_fb(primary, NULL);
> > > + igt_plane_set_fb(cursor, NULL);
> > > +
> > >
Re: [Nouveau] [igt-dev] [PATCH i-g-t v2 1/2] tests/kms_cursor_crc: Probe kernel for cursor size support
, w, h);
> -
> - igt_describe("Check random placement of a cursor with given
> size.");
> - igt_subtest_f("pipe-%s-cursor-%dx%d-random",
> kmstest_pipe_name(pipe), w, h)
> - run_test(data, test_crc_random, w, h);
> -
> - igt_describe("Check the rapid update of given-size cursor
> movements.");
> - igt_subtest_f("pipe-%s-cursor-%dx%d-rapid-movement",
> kmstest_pipe_name(pipe), w, h) {
> - run_test(data, test_rapid_movement, w, h);
> + igt_subtest_group {
> + igt_fixture
> + require_cursor_size(data, w, h);
> +
> + /* Using created cursor FBs to test cursor support */
> + igt_describe("Check if a given-size cursor is
> well-positioned inside the "
> + "screen.");
> + igt_subtest_f("pipe-%s-cursor-%dx%d-onscreen",
> kmstest_pipe_name(pipe), w, h)
> + run_test(data, test_crc_onscreen, w, h);
> +
> + igt_describe("Check if a given-size cursor is
> well-positioned outside the "
> + "screen.");
> + igt_subtest_f("pipe-%s-cursor-%dx%d-offscreen",
> kmstest_pipe_name(pipe), w, h)
> + run_test(data, test_crc_offscreen, w, h);
> +
> + igt_describe("Check the smooth and pixel-by-pixel
> given-size cursor "
> + "movements on horizontal, vertical and
> diagonal.");
> + igt_subtest_f("pipe-%s-cursor-%dx%d-sliding",
> kmstest_pipe_name(pipe), w, h)
> + run_test(data, test_crc_sliding, w, h);
> +
> + igt_describe("Check random placement of a cursor with
> given size.");
> + igt_subtest_f("pipe-%s-cursor-%dx%d-random",
> kmstest_pipe_name(pipe), w, h)
> + run_test(data, test_crc_random, w, h);
> +
> + igt_describe("Check the rapid update of given-size
> cursor movements.");
> + igt_subtest_f("pipe-%s-cursor-%dx%d-rapid-movement",
> kmstest_pipe_name(pipe), w, h)
> + run_test(data, test_rapid_movement, w, h);
> }
>
> igt_fixture
> @@ -730,27 +753,25 @@ static void run_tests_on_pipe(data_t *data, enum pipe
> pipe)
>*/
> h /= 3;
>
> - igt_fixture {
> - if (has_nonsquare_cursors(data))
> - create_cursor_fb(data, w, h);
> - }
> + igt_fixture
> + create_cursor_fb(data, w, h);
>
> - /* Using created cursor FBs to test cursor support */
> - igt_subtest_f("pipe-%s-cursor-%dx%d-onscreen",
> kmstest_pipe_name(pipe), w, h) {
> - igt_require(has_nonsquare_cursors(data));
> - run_test(data, test_crc_onscreen, w, h);
> - }
> - igt_subtest_f("pipe-%s-cursor-%dx%d-offscreen",
> kmstest_pipe_name(pipe), w, h) {
> - igt_require(has_nonsquare_cursors(data));
> - run_test(data, test_crc_offscreen, w, h);
> - }
> - igt_subtest_f("pipe-%s-cursor-%dx%d-sliding",
> kmstest_pipe_name(pipe), w, h) {
> - igt_require(has_nonsquare_cursors(data));
> - run_test(data, test_crc_sliding, w, h);
> - }
> - igt_subtest_f("pipe-%s-cursor-%dx%d-random",
> kmstest_pipe_name(pipe), w, h) {
> - igt_require(has_nonsquare_cursors(data));
> - run_test(data, test_crc_random, w, h);
> + igt_subtest_group {
> + igt_fixture
> + require_cursor_size(data, w, h);
> +
> + /* Using created cursor FBs to test cursor support */
> + igt_subtest_f("pipe-%s-cursor-%dx%d-onscreen",
> kmstest_pipe_name(pipe), w, h)
> + run_test(data, test_crc_onscreen, w, h);
> +
> + igt_subtest_f("pipe-%s-cursor-%dx%d-offscreen",
> kmstest_pipe_name(pipe), w, h)
> + run_test(data, test_crc_offscreen, w, h);
> +
> + igt_subtest_f("pipe-%s-cursor-%dx%d-sliding",
> kmstest_pipe_name(pipe), w, h)
> + run_test(data, test_crc_sliding, w, h);
> +
> + igt_subtest_f("pipe-%s-cursor-%dx%d-random",
> kmstest_pipe_name(pipe), w, h)
> + run_test(data, test_crc_random, w, h);
> }
>
> igt_fixture
> --
> 2.29.2
>
> ___
> igt-dev mailing list
> igt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/igt-dev
--
Ville Syrjälä
Intel
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [igt-dev] [PATCH i-g-t 4/7] lib/igt_fb: Remove domain from igt_fb
On Wed, Mar 17, 2021 at 06:49:46PM -0400, Lyude wrote:
> From: Lyude Paul
>
> It doesn't look like that this is used by i915 for anything these days, so
> let's just remove this while we're at it.
I wa scurious why this is here so dug around a bit.
It was added in
commit 18d0b1efb875 ("lib/igt_fb: Fix domain tracking for GTT cairo surfaces")
then got broken again by
commit 89b3ffe02c2a ("lib: Map dumb buffers")
and later fixed again with
commit 3bd68529c464 ("lib/igt_fb: Add missing set_domain calls")
So yeah, not needed anymore.
Reviewed-by: Ville Syrjälä
>
> Signed-off-by: Lyude Paul
> Cc: Martin Peres
> Cc: Jeremy Cline
> ---
> lib/igt_fb.c | 3 ---
> lib/igt_fb.h | 2 --
> 2 files changed, 5 deletions(-)
>
> diff --git a/lib/igt_fb.c b/lib/igt_fb.c
> index f0fcd1a7..2b478887 100644
> --- a/lib/igt_fb.c
> +++ b/lib/igt_fb.c
> @@ -2491,7 +2491,6 @@ static void create_cairo_surface__gpu(int fd, struct
> igt_fb *fb)
> cairo_format,
> fb->width, fb->height,
> blit->linear.fb.strides[0]);
> - fb->domain = I915_GEM_DOMAIN_GTT;
>
> cairo_surface_set_user_data(fb->cairo_surface,
> (cairo_user_data_key_t
> *)create_cairo_surface__gpu,
> @@ -2571,8 +2570,6 @@ static void create_cairo_surface__gtt(int fd, struct
> igt_fb *fb)
> "Unable to create a cairo surface: %s\n",
>
> cairo_status_to_string(cairo_surface_status(fb->cairo_surface)));
>
> - fb->domain = I915_GEM_DOMAIN_GTT;
> -
> cairo_surface_set_user_data(fb->cairo_surface,
> (cairo_user_data_key_t
> *)create_cairo_surface__gtt,
> fb, destroy_cairo_surface__gtt);
> diff --git a/lib/igt_fb.h b/lib/igt_fb.h
> index 0d64898a..e4f8b2b1 100644
> --- a/lib/igt_fb.h
> +++ b/lib/igt_fb.h
> @@ -64,7 +64,6 @@ struct buf_ops;
> * @modifier: tiling mode as a DRM framebuffer modifier
> * @size: size in bytes of the underlying backing storage
> * @cairo_surface: optionally attached cairo drawing surface
> - * @domain: current domain for cache flushing tracking on i915.ko
> * @num_planes: Amount of planes on this fb. >1 for planar formats.
> * @strides: line stride for each plane in bytes
> * @offsets: Offset for each plane in bytes.
> @@ -87,7 +86,6 @@ typedef struct igt_fb {
> uint64_t modifier;
> uint64_t size;
> cairo_surface_t *cairo_surface;
> - unsigned int domain;
> unsigned int num_planes;
> uint32_t strides[4];
> uint32_t offsets[4];
> --
> 2.29.2
>
> ___
> igt-dev mailing list
> igt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/igt-dev
--
Ville Syrjälä
Intel
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [igt-dev] [PATCH i-g-t] tests/kms_cursor_crc: Test 32x32 cursors
On Thu, Mar 18, 2021 at 08:39:01AM +0200, Martin Peres wrote: > On 18/03/2021 00:45, Lyude wrote: > > From: Lyude Paul > > > > Since pre-nve4 only has two cursor sizes (32x32 and 64x64), we should at > > least test both of them. > > This adds 36 subtests, which take about 1s in average. So the runtime is > not significantly increased on the Intel side. > > It also seems that Intel should add skips or fix the kernel to support > these 32xXX format. Intel hw at least does not support 32x32 cursors. We should probably just just probe the kernel to see if it accepts the requested cursor size, and skip the subtest if not. That would also let us remove the i915 platform specific information from has_nonsquare_cursors(). -- Ville Syrjälä Intel ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [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
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [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
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [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
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [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 ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v2 00/18] drm/i915: Pimp DP DFP handling
On Tue, Sep 08, 2020 at 02:34:24PM -0400, Lyude Paul wrote: > With the nitpicks addressed (note there were a couple of other spots where we > wanted to use Return: in the kdocs, but I didn't bother pointing all of them > out), all but patch 07 is: > > Reviewed-by: Lyude Paul Thanks for the review. I fixed up the missing/bad docs and pushed the lot to drm-intel-next-queued (with Daniel's irc ack). PS. Had to s/drm_dp_downstream_max_clock/drm_dp_downstream_max_dotclock/ in nouveau_dp.c to keep it in a buildable shape. I hope I didn't step on too many toes with this... -- Ville Syrjälä Intel ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 2/3] drm/dp_mst: Don't show connectors as connected before probing available PBN
On Thu, Mar 05, 2020 at 01:13:36PM -0500, Lyude Paul wrote:
> On Thu, 2020-03-05 at 15:11 +0200, Ville Syrjälä wrote:
> > On Wed, Mar 04, 2020 at 05:36:12PM -0500, Lyude Paul wrote:
> > > It's next to impossible for us to do connector probing on topologies
> > > without occasionally racing with userspace, since creating a connector
> > > itself causes a hotplug event which we have to send before probing the
> > > available PBN of a connector. Even if we didn't have this hotplug event
> > > sent, there's still always a chance that userspace started probing
> > > connectors before we finished probing the topology.
> > >
> > > This can be a problem when validating a new MST state since the
> > > connector will be shown as connected briefly, but without any available
> > > PBN - causing any atomic state which would enable said connector to fail
> > > with -ENOSPC. So, let's simply workaround this by telling userspace new
> > > MST connectors are disconnected until we've finished probing their PBN.
> > > Since we always send a hotplug event at the end of the link address
> > > probing process, userspace will still know to reprobe the connector when
> > > we're ready.
> > >
> > > Signed-off-by: Lyude Paul
> > > Fixes: cd82d82cbc04 ("drm/dp_mst: Add branch bandwidth validation to MST
> > > atomic check")
> > > Cc: Mikita Lipski
> > > Cc: Alex Deucher
> > > Cc: Sean Paul
> > > Cc: Hans de Goede
> > > ---
> > > drivers/gpu/drm/drm_dp_mst_topology.c | 13 +
> > > 1 file changed, 13 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > index 207eef08d12c..7b0ff0cff954 100644
> > > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > @@ -4033,6 +4033,19 @@ drm_dp_mst_detect_port(struct drm_connector
> > > *connector,
> > > ret = connector_status_connected;
> > > break;
> > > }
> > > +
> > > + /* We don't want to tell userspace the port is actually plugged into
> > > + * anything until we've finished probing it's available_pbn, otherwise
> >
> > "its"
> >
> > Why is the connector even registered before we've finished the probe?
> >
> Oops, I'm not sure how I did this by accident but the explanation I gave in
> the commit message was uh, completely wrong. I must have forgotten that I made
> sure we didn't expose connectors before probing their PBN back when I started
> my MST cleanup
>
> So: despite what I said before it's not actually when new connectors are
> created, it's when downstream hotplugs happen which means that the conenctor's
> always going to be there before we probe the available_pbn.
Not sure I understand. You're saying this is going to change for already
existing connectors when something else gets plugged in, and either we
zero it out during the probe or it always was zero to begin with for
whatever reason?
> I did just notice
> though that we send a hotplug on connection status notifications even before
> we've finished the PBN probe, so I might be able to improve on that as well.
> We still definitely want to report the connector as disconnected before we
> have the available PBN though, in case another probe was already going before
> we got the connection status notification.
>
> I'll make sure to fixup the explanation in the commit message on the next
> respin
>
> > > + * userspace will see racy atomic check failures
> > > + *
> > > + * Since we always send a hotplug at the end of probing topology
> > > + * state, we can just let userspace reprobe this connector later.
> > > + */
> > > + if (ret == connector_status_connected && !port->available_pbn) {
> > > + DRM_DEBUG_KMS("[CONNECTOR:%d:%s] not ready yet (PBN not
> > > probed)\n",
> > > + connector->base.id, connector->name);
> > > + ret = connector_status_disconnected;
> > > + }
> > > out:
> > > drm_dp_mst_topology_put_port(port);
> > > return ret;
> > > --
> > > 2.24.1
> > >
> > > ___
> > > dri-devel mailing list
> > > dri-de...@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> --
> Cheers,
> Lyude Paul (she/her)
> Associate Software Engineer at Red Hat
--
Ville Syrjälä
Intel
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 2/3] drm/dp_mst: Don't show connectors as connected before probing available PBN
On Wed, Mar 04, 2020 at 05:36:12PM -0500, Lyude Paul wrote:
> It's next to impossible for us to do connector probing on topologies
> without occasionally racing with userspace, since creating a connector
> itself causes a hotplug event which we have to send before probing the
> available PBN of a connector. Even if we didn't have this hotplug event
> sent, there's still always a chance that userspace started probing
> connectors before we finished probing the topology.
>
> This can be a problem when validating a new MST state since the
> connector will be shown as connected briefly, but without any available
> PBN - causing any atomic state which would enable said connector to fail
> with -ENOSPC. So, let's simply workaround this by telling userspace new
> MST connectors are disconnected until we've finished probing their PBN.
> Since we always send a hotplug event at the end of the link address
> probing process, userspace will still know to reprobe the connector when
> we're ready.
>
> Signed-off-by: Lyude Paul
> Fixes: cd82d82cbc04 ("drm/dp_mst: Add branch bandwidth validation to MST
> atomic check")
> Cc: Mikita Lipski
> Cc: Alex Deucher
> Cc: Sean Paul
> Cc: Hans de Goede
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 207eef08d12c..7b0ff0cff954 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -4033,6 +4033,19 @@ drm_dp_mst_detect_port(struct drm_connector *connector,
> ret = connector_status_connected;
> break;
> }
> +
> + /* We don't want to tell userspace the port is actually plugged into
> + * anything until we've finished probing it's available_pbn, otherwise
"its"
Why is the connector even registered before we've finished the probe?
> + * userspace will see racy atomic check failures
> + *
> + * Since we always send a hotplug at the end of probing topology
> + * state, we can just let userspace reprobe this connector later.
> + */
> + if (ret == connector_status_connected && !port->available_pbn) {
> + DRM_DEBUG_KMS("[CONNECTOR:%d:%s] not ready yet (PBN not
> probed)\n",
> + connector->base.id, connector->name);
> + ret = connector_status_disconnected;
> + }
> out:
> drm_dp_mst_topology_put_port(port);
> return ret;
> --
> 2.24.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] (no subject)
Subject: Re: [PATCH 04/12] drm: Nuke mode->vrefresh Message-ID: <20200226115708.gh13...@intel.com> References: <20200219203544.31013-1-ville.syrj...@linux.intel.com> <20200219203544.31013-5-ville.syrj...@linux.intel.com> <0f278771-79ce-fe23-e72c-3935dbe82...@samsung.com> <20200225112114.ga13...@intel.com> <3ca785f2-9032-aaf9-0965-8657d3111...@samsung.com> <20200225154506.gf13...@intel.com> <20200225192720.gg13...@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Patchwork-Hint: comment User-Agent: Mutt/1.10.1 (2018-07-13) On Tue, Feb 25, 2020 at 10:52:25PM +0100, Linus Walleij wrote: > On Tue, Feb 25, 2020 at 8:27 PM Ville Syrjälä > wrote: > > > OK, so I went ahead a wrote a bit of cocci [1] to find the bad apples. > > That's impressive :D > > > Unfortunately it found a lot of strange stuff: > > I will answer for the weirdness I caused. > > I have long suspected that a whole bunch of the "simple" displays > are not simple but contains a display controller and memory. > That means that the speed over the link to the display and > actual refresh rate on the actual display is asymmetric because > well we are just updating a RAM, the resolution just limits how > much data we are sending, the clock limits the speed on the > bus over to the RAM on the other side. IMO even in command mode mode->clock should probably be the actual dotclock used by the display. If there's another clock for the bus speed/etc. it should be stored somewhere else. -- Ville Syrjälä Intel ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] (no subject)
On Wed, Feb 26, 2020 at 01:08:06PM +0100, Linus Walleij wrote: > On Wed, Feb 26, 2020 at 12:57 PM Ville Syrjälä > wrote: > > On Tue, Feb 25, 2020 at 10:52:25PM +0100, Linus Walleij wrote: > > > > I have long suspected that a whole bunch of the "simple" displays > > > are not simple but contains a display controller and memory. > > > That means that the speed over the link to the display and > > > actual refresh rate on the actual display is asymmetric because > > > well we are just updating a RAM, the resolution just limits how > > > much data we are sending, the clock limits the speed on the > > > bus over to the RAM on the other side. > > > > IMO even in command mode mode->clock should probably be the actual > > dotclock used by the display. If there's another clock for the bus > > speed/etc. it should be stored somewhere else. > > Good point. For the DSI panels we have the field hs_rate > for the HS clock in struct mipi_dsi_device which is based > on exactly this reasoning. And that is what I actually use for > setting the HS clock. > > The problem is however that we in many cases have so > substandard documentation of these panels that we have > absolutely no idea about the dotclock. Maybe we should > just set it to 0 in these cases? Don't you always have a TE interrupt or something like that available? Could just measure it from that if no better information is available? -- Ville Syrjälä Intel ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] (no subject)
On Wed, Feb 26, 2020 at 03:56:36PM +0100, Linus Walleij wrote:
> On Wed, Feb 26, 2020 at 3:34 PM Ville Syrjälä
> wrote:
> > On Wed, Feb 26, 2020 at 01:08:06PM +0100, Linus Walleij wrote:
> > > On Wed, Feb 26, 2020 at 12:57 PM Ville Syrjälä
> > > wrote:
> > > > On Tue, Feb 25, 2020 at 10:52:25PM +0100, Linus Walleij wrote:
> > >
> > > > > I have long suspected that a whole bunch of the "simple" displays
> > > > > are not simple but contains a display controller and memory.
> > > > > That means that the speed over the link to the display and
> > > > > actual refresh rate on the actual display is asymmetric because
> > > > > well we are just updating a RAM, the resolution just limits how
> > > > > much data we are sending, the clock limits the speed on the
> > > > > bus over to the RAM on the other side.
> > > >
> > > > IMO even in command mode mode->clock should probably be the actual
> > > > dotclock used by the display. If there's another clock for the bus
> > > > speed/etc. it should be stored somewhere else.
> > >
> > > Good point. For the DSI panels we have the field hs_rate
> > > for the HS clock in struct mipi_dsi_device which is based
> > > on exactly this reasoning. And that is what I actually use for
> > > setting the HS clock.
> > >
> > > The problem is however that we in many cases have so
> > > substandard documentation of these panels that we have
> > > absolutely no idea about the dotclock. Maybe we should
> > > just set it to 0 in these cases?
> >
> > Don't you always have a TE interrupt or something like that
> > available? Could just measure it from that if no better
> > information is available?
>
> Yes and I did exactly that, so that is why this comment is in
> the driver:
>
> static const struct drm_display_mode sony_acx424akp_cmd_mode = {
> (...)
> /*
> * Some desired refresh rate, experiments at the maximum "pixel"
> * clock speed (HS clock 420 MHz) yields around 117Hz.
> */
> .vrefresh = 60,
>
> I got a review comment at the time saying 117 Hz was weird.
> We didn't reach a proper conclusion on this:
> https://lore.kernel.org/dri-devel/CACRpkdYW3YNPSNMY3A44GQn8DqK-n9TLvr7uipF7LM_DHZ5=l...@mail.gmail.com/
>
> Thierry wasn't sure if 60Hz was good or not, so I just had to
> go with something.
>
> We could calculate the resulting pixel clock for ~117 Hz with
> this resolution and put that in the clock field but ... don't know
> what is the best?
I would vote for that approach.
--
Ville Syrjälä
Intel
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 04/12] drm: Nuke mode->vrefresh
On Tue, Feb 25, 2020 at 04:19:27PM +0100, Andrzej Hajda wrote:
> On 25.02.2020 12:21, Ville Syrjälä wrote:
> > On Mon, Feb 24, 2020 at 03:14:54PM +0100, Andrzej Hajda wrote:
> >> On 19.02.2020 21:35, Ville Syrjala wrote:
> >>> From: Ville Syrjälä
> >>>
> >>> Get rid of mode->vrefresh and just calculate it on demand. Saves
> >>> a bit of space and avoids the cached value getting out of sync
> >>> with reality.
> >>>
> >>> Mostly done with cocci, with the following manual fixups:
> >>> - Remove the now empty loop in drm_helper_probe_single_connector_modes()
> >>> - Fix __MODE() macro in ch7006_mode.c
> >>> - Fix DRM_MODE_ARG() macro in drm_modes.h
> >>> - Remove leftover comment from samsung_s6d16d0_mode
> >> ...
> >>> diff --git a/drivers/gpu/drm/panel/panel-arm-versatile.c
> >>> b/drivers/gpu/drm/panel/panel-arm-versatile.c
> >>> index 41444a73c980..47b37fef7ee8 100644
> >>> --- a/drivers/gpu/drm/panel/panel-arm-versatile.c
> >>> +++ b/drivers/gpu/drm/panel/panel-arm-versatile.c
> >>> @@ -143,7 +143,6 @@ static const struct versatile_panel_type
> >>> versatile_panels[] = {
> >>> .vsync_start = 240 + 5,
> >>> .vsync_end = 240 + 5 + 6,
> >>> .vtotal = 240 + 5 + 6 + 5,
> >>> - .vrefresh = 116,
> >>
> >> Are you sure vrefresh calculated (from totals and clock) is different
> >> than this field? If not, we risk regressions.
> >>
> >> This case is OK, but there is plenty other cases.
> > IIRC I did spot check a few of them. But which code exactly do you think
> > is abusing vrefresh and thus could break?
>
>
> I guess suspect/potential victim is every code which uses
> drm_mode_vrefresh - after this patch the function can return different
> value(if there are differences between provided and calculated vrefresh).
>
> Quick examples where output of this function matters:
>
> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c#L387
Already looks quite sketchy due to rounding.
>
> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c#L42
msleep() is in no way accurate so looks rather sketchy as well.
> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/tilcdc/tilcdc_crtc.c#L810
Another thing that suffers from rounding issues.
So to me these all look like code that someone should fix regardless.
--
Ville Syrjälä
Intel
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 04/12] drm: Nuke mode->vrefresh
On Tue, Feb 25, 2020 at 05:45:06PM +0200, Ville Syrjälä wrote:
> On Tue, Feb 25, 2020 at 04:19:27PM +0100, Andrzej Hajda wrote:
> > On 25.02.2020 12:21, Ville Syrjälä wrote:
> > > On Mon, Feb 24, 2020 at 03:14:54PM +0100, Andrzej Hajda wrote:
> > >> On 19.02.2020 21:35, Ville Syrjala wrote:
> > >>> From: Ville Syrjälä
> > >>>
> > >>> Get rid of mode->vrefresh and just calculate it on demand. Saves
> > >>> a bit of space and avoids the cached value getting out of sync
> > >>> with reality.
> > >>>
> > >>> Mostly done with cocci, with the following manual fixups:
> > >>> - Remove the now empty loop in drm_helper_probe_single_connector_modes()
> > >>> - Fix __MODE() macro in ch7006_mode.c
> > >>> - Fix DRM_MODE_ARG() macro in drm_modes.h
> > >>> - Remove leftover comment from samsung_s6d16d0_mode
> > >> ...
> > >>> diff --git a/drivers/gpu/drm/panel/panel-arm-versatile.c
> > >>> b/drivers/gpu/drm/panel/panel-arm-versatile.c
> > >>> index 41444a73c980..47b37fef7ee8 100644
> > >>> --- a/drivers/gpu/drm/panel/panel-arm-versatile.c
> > >>> +++ b/drivers/gpu/drm/panel/panel-arm-versatile.c
> > >>> @@ -143,7 +143,6 @@ static const struct versatile_panel_type
> > >>> versatile_panels[] = {
> > >>> .vsync_start = 240 + 5,
> > >>> .vsync_end = 240 + 5 + 6,
> > >>> .vtotal = 240 + 5 + 6 + 5,
> > >>> - .vrefresh = 116,
> > >>
> > >> Are you sure vrefresh calculated (from totals and clock) is different
> > >> than this field? If not, we risk regressions.
> > >>
> > >> This case is OK, but there is plenty other cases.
> > > IIRC I did spot check a few of them. But which code exactly do you think
> > > is abusing vrefresh and thus could break?
> >
> >
> > I guess suspect/potential victim is every code which uses
> > drm_mode_vrefresh - after this patch the function can return different
> > value(if there are differences between provided and calculated vrefresh).
> >
> > Quick examples where output of this function matters:
> >
> > https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c#L387
>
> Already looks quite sketchy due to rounding.
>
> >
> > https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c#L42
>
> msleep() is in no way accurate so looks rather sketchy as well.
>
> > https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/tilcdc/tilcdc_crtc.c#L810
>
> Another thing that suffers from rounding issues.
>
> So to me these all look like code that someone should fix regardless.
OK, so I went ahead a wrote a bit of cocci [1] to find the bad apples.
Unfortunately it found a lot of strange stuff:
panel-sony-acx424akp.c:51/sony_acx424akp_vid_mode: 60 vs. 727 (.clock=33
.htotal=480 + 15 + 0 + 15 .vtotal=864 + 14 + 1 + 11)
panel-sony-acx424akp.c:71/sony_acx424akp_cmd_mode: 60 vs. 711 (.clock=420160
.htotal=480 + 154 + 16 + 32 .vtotal=864 + 1 + 1 + 1)
panel-ilitek-ili9322.c:543/srgb_320x240_mode: 60 vs. 10168 (.clock=2453500
.htotal=320 + 359 + 1 + 241 .vtotal=262)
panel-ilitek-ili9322.c:587/yuv_640x320_mode: 60 vs. 7768 (.clock=2454000
.htotal=640 + 252 + 1 + 28 .vtotal=320 + 4 + 1 + 18)
panel-ilitek-ili9322.c:616/itu_r_bt_656_640_mode: 60 vs. 5358 (.clock=2454000
.htotal=640 + 3 + 1 + 272 .vtotal=500)
panel-ilitek-ili9322.c:557/srgb_360x240_mode: 60 vs. 16178 (.clock=270
.htotal=360 + 35 + 1 + 241 .vtotal=262)
panel-ilitek-ili9322.c:601/yuv_720x360_mode: 60 vs. 7071 (.clock=270
.htotal=720 + 252 + 1 + 24 .vtotal=360 + 4 + 1 + 18)
panel-ilitek-ili9322.c:631/itu_r_bt_656_720_mode: 60 vs. 5422 (.clock=270
.htotal=720 + 3 + 1 + 272 .vtotal=500)
panel-ilitek-ili9322.c:572/prgb_320x240_mode: 60 vs. 59725 (.clock=640
.htotal=320 + 38 + 1 + 50 .vtotal=262)
panel-lg-lg4573.c:200/default_mode: 60 vs. 57 (.clock=27000 .htotal=480 + 10 +
59 + 10 .vtotal=800 + 15 + 15 + 15)
panel-sitronix-st7789v.c:159/default_mode: 60 vs. 70 (.clock=7000 .htotal=240 +
38 + 10 + 10 .vtotal=320 + 8 + 4 + 4)
panel-arm-versatile.c:161/versatile_panels[]: 60 vs. 61 (.clock=25000
.htotal=640 + 24 + 96 + 24 .vtotal=480 + 11 + 2 + 32)
panel-arm-versatile.c:208/versatile_panels[]: 116 vs. 59 (.clock=5400
.htotal=240 + 10 + 10 + 20 .vtotal=320 + 2 + 2 + 2)
panel-arm-versatile.c:184/versatile_panels[]: 390 vs. 1523 (.clock=62500
.htotal=176 + 2 + 3 + 3 .vtotal=220 + 0 + 2 + 1)
pan
Re: [Nouveau] [PATCH 04/12] drm: Nuke mode->vrefresh
On Mon, Feb 24, 2020 at 03:14:54PM +0100, Andrzej Hajda wrote:
> On 19.02.2020 21:35, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Get rid of mode->vrefresh and just calculate it on demand. Saves
> > a bit of space and avoids the cached value getting out of sync
> > with reality.
> >
> > Mostly done with cocci, with the following manual fixups:
> > - Remove the now empty loop in drm_helper_probe_single_connector_modes()
> > - Fix __MODE() macro in ch7006_mode.c
> > - Fix DRM_MODE_ARG() macro in drm_modes.h
> > - Remove leftover comment from samsung_s6d16d0_mode
> ...
> > diff --git a/drivers/gpu/drm/panel/panel-arm-versatile.c
> > b/drivers/gpu/drm/panel/panel-arm-versatile.c
> > index 41444a73c980..47b37fef7ee8 100644
> > --- a/drivers/gpu/drm/panel/panel-arm-versatile.c
> > +++ b/drivers/gpu/drm/panel/panel-arm-versatile.c
> > @@ -143,7 +143,6 @@ static const struct versatile_panel_type
> > versatile_panels[] = {
> > .vsync_start = 240 + 5,
> > .vsync_end = 240 + 5 + 6,
> > .vtotal = 240 + 5 + 6 + 5,
> > - .vrefresh = 116,
>
>
> Are you sure vrefresh calculated (from totals and clock) is different
> than this field? If not, we risk regressions.
>
> This case is OK, but there is plenty other cases.
IIRC I did spot check a few of them. But which code exactly do you think
is abusing vrefresh and thus could break?
>
>
> Regards
>
> Andrzej
>
>
> > .flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC,
> > },
> > },
> > @@ -167,7 +166,6 @@ static const struct versatile_panel_type
> > versatile_panels[] = {
> > .vsync_start = 480 + 11,
> > .vsync_end = 480 + 11 + 2,
> > .vtotal = 480 + 11 + 2 + 32,
> > - .vrefresh = 60,
> > .flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC,
> > },
> > },
> > @@ -190,7 +188,6 @@ static const struct versatile_panel_type
> > versatile_panels[] = {
> > .vsync_start = 220 + 0,
> > .vsync_end = 220 + 0 + 2,
> > .vtotal = 220 + 0 + 2 + 1,
> > - .vrefresh = 390,
> > .flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC,
> > },
> > .bus_flags = DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE,
> > @@ -214,7 +211,6 @@ static const struct versatile_panel_type
> > versatile_panels[] = {
> > .vsync_start = 320 + 2,
> > .vsync_end = 320 + 2 + 2,
> > .vtotal = 320 + 2 + 2 + 2,
> > - .vrefresh = 116,
> > .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
> > },
> > .bus_flags = DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE,
> > diff --git a/drivers/gpu/drm/panel/panel-boe-himax8279d.c
> > b/drivers/gpu/drm/panel/panel-boe-himax8279d.c
> > index 74d58ee7d04c..7c27bd5e3486 100644
> > --- a/drivers/gpu/drm/panel/panel-boe-himax8279d.c
> > +++ b/drivers/gpu/drm/panel/panel-boe-himax8279d.c
> > @@ -229,7 +229,7 @@ static int boe_panel_get_modes(struct drm_panel *panel,
> > mode = drm_mode_duplicate(connector->dev, m);
> > if (!mode) {
> > DRM_DEV_ERROR(pinfo->base.dev, "failed to add mode %ux%u@%u\n",
> > - m->hdisplay, m->vdisplay, m->vrefresh);
> > + m->hdisplay, m->vdisplay, drm_mode_vrefresh(m));
> > return -ENOMEM;
> > }
> >
> > @@ -262,7 +262,6 @@ static const struct drm_display_mode
> > default_display_mode = {
> > .vsync_start = 1920 + 10,
> > .vsync_end = 1920 + 10 + 14,
> > .vtotal = 1920 + 10 + 14 + 4,
> > - .vrefresh = 60,
> > };
> >
> > /* 8 inch */
> > diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
> > b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
> > index 48a164257d18..c580bd1e121c 100644
> > --- a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
> > +++ b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
> > @@ -594,7 +594,6 @@ static const struct drm_display_mode
> > boe_tv101wum_nl6_default_mode = {
> > .vsync_start = 1920 + 10,
> > .vsync_end = 1920 + 10 + 14,
> > .vtotal = 1920 + 10 + 14 + 4,
> > - .vrefresh = 60,
> > };
> >
> > static const struct pa
Re: [Nouveau] [PATCH 04/12] drm: Nuke mode->vrefresh
On Sat, Feb 22, 2020 at 01:32:40PM +0100, Sam Ravnborg wrote: > Hi Ville. > > Nice patch - and diffstat looks good: > > 63 files changed, 217 insertions(+), 392 deletions(-) > > There is an item in the Documentation/gpu/todo.rst that > describes this. > Could you drop this from todo.rst in this patch too. Yeah, missed the TODO. Looks like there's one for hsync removal as well. > > > diff --git a/drivers/gpu/drm/mcde/mcde_dsi.c > > b/drivers/gpu/drm/mcde/mcde_dsi.c > > index bb6528b01cd0..6dca5344c0b3 100644 > > --- a/drivers/gpu/drm/mcde/mcde_dsi.c > > +++ b/drivers/gpu/drm/mcde/mcde_dsi.c > > @@ -538,7 +538,7 @@ static void mcde_dsi_setup_video_mode(struct mcde_dsi > > *d, > > */ > > /* (ps/s) / (pixels/s) = ps/pixels */ > > pclk = DIV_ROUND_UP_ULL(1, > > - (mode->vrefresh * mode->htotal * mode->vtotal)); > > + (drm_mode_vrefresh(mode) * mode->htotal * > > mode->vtotal)); > > dev_dbg(d->dev, "picoseconds between two pixels: %llu\n", > > pclk); > > > > This just caught my eye while browsing the patch. > It looks like a backward way to get the clock. Yep. I'll cook up a patch to switch this to ->clock. > > But patch is fine, it was just a drive-by comment. > > Whole patch is: > Reviewed-by: Sam Ravnborg > (with or without removal of todo item added) > > Sam -- Ville Syrjälä Intel ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v3 22/22] drm: Remove legacy version of get_scanout_position()
On Mon, Jan 20, 2020 at 09:23:14AM +0100, Thomas Zimmermann wrote:
> The legacy version of get_scanout_position() was only useful while
> drivers still used drm_driver.get_scanout_position(). With no such
> drivers left, the related typedef and code can be removed
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_vblank.c| 27 +++
> drivers/gpu/drm/i915/i915_irq.c | 2 +-
> include/drm/drm_vblank.h| 10 +-
> 3 files changed, 9 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> index 34428ce3c676..0bda7d7a0af2 100644
> --- a/drivers/gpu/drm/drm_vblank.c
> +++ b/drivers/gpu/drm/drm_vblank.c
> @@ -576,9 +576,6 @@ EXPORT_SYMBOL(drm_calc_timestamping_constants);
> * @get_scanout_position:
> * Callback function to retrieve the scanout position. See
> * @struct drm_crtc_helper_funcs.get_scanout_position.
> - * @get_scanout_position_legacy:
> - * Callback function to retrieve the scanout position. See
> - * @struct drm_driver.get_scanout_position.
> *
> * Implements calculation of exact vblank timestamps from given
> drm_display_mode
> * timings and current video scanout position of a CRTC.
> @@ -601,8 +598,7 @@ bool
> drm_crtc_vblank_helper_get_vblank_timestamp_internal(
> struct drm_crtc *crtc, int *max_error, ktime_t *vblank_time,
> bool in_vblank_irq,
> - drm_vblank_get_scanout_position_func get_scanout_position,
> - drm_vblank_get_scanout_position_legacy_func get_scanout_position_legacy)
> + drm_vblank_get_scanout_position_func get_scanout_position)
> {
> struct drm_device *dev = crtc->dev;
> unsigned int pipe = crtc->index;
> @@ -620,7 +616,7 @@ drm_crtc_vblank_helper_get_vblank_timestamp_internal(
> }
>
> /* Scanout position query not supported? Should not happen. */
> - if (!get_scanout_position && !get_scanout_position_legacy) {
> + if (!get_scanout_position) {
> DRM_ERROR("Called from CRTC w/o get_scanout_position()!?\n");
> return false;
> }
> @@ -651,19 +647,10 @@ drm_crtc_vblank_helper_get_vblank_timestamp_internal(
>* Get vertical and horizontal scanout position vpos, hpos,
>* and bounding timestamps stime, etime, pre/post query.
>*/
> - if (get_scanout_position) {
> - vbl_status = get_scanout_position(crtc,
> - in_vblank_irq,
> - , ,
> - , ,
> - mode);
> - } else {
> - vbl_status = get_scanout_position_legacy(dev, pipe,
> - in_vblank_irq,
> - , ,
> - , ,
> - mode);
> - }
> + vbl_status = get_scanout_position(crtc, in_vblank_irq,
> + , ,
> + , ,
> + mode);
>
> /* Return as no-op if scanout query unsupported or failed. */
> if (!vbl_status) {
> @@ -755,7 +742,7 @@ bool drm_crtc_vblank_helper_get_vblank_timestamp(struct
> drm_crtc *crtc,
> {
> return drm_crtc_vblank_helper_get_vblank_timestamp_internal(
> crtc, max_error, vblank_time, in_vblank_irq,
> - crtc->helper_private->get_scanout_position, NULL);
> + crtc->helper_private->get_scanout_position);
> }
> EXPORT_SYMBOL(drm_crtc_vblank_helper_get_vblank_timestamp);
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 29bf847999f5..3245f7c5c84f 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -886,7 +886,7 @@ bool intel_crtc_get_vblank_timestamp(struct drm_crtc
> *crtc, int *max_error,
> {
> return drm_crtc_vblank_helper_get_vblank_timestamp_internal(
> crtc, max_error, vblank_time, in_vblank_irq,
> - i915_get_crtc_scanoutpos, NULL);
> + i915_get_crtc_scanoutpos);
> }
>
> int intel_get_crtc_scanline(struct intel_crtc *crtc)
> diff --git a/include/drm/drm_vblank.h b/include/drm/drm_vblank.h
> index a6ca8be93dd8..0f474e855e7f 100644
&
Re: [Nouveau] [Intel-gfx] [PATCH v3 03/22] drm: Add get_vblank_timestamp() to struct drm_crtc_funcs
atomic modeset drivers) to
> + * match the scanout position reported.
> + *
> + * Note that atomic drivers must call drm_calc_timestamping_constants()
> before
> + * enabling a CRTC. The atomic helpers already take care of that in
> + * drm_atomic_helper_update_legacy_modeset_state().
> + *
> + * Returns:
> + *
> + * Returns true on success, and false on failure, i.e. when no accurate
> + * timestamp could be acquired.
> + */
> +bool drm_crtc_vblank_helper_get_vblank_timestamp(struct drm_crtc *crtc,
> + int *max_error,
> + ktime_t *vblank_time,
> + bool in_vblank_irq)
> +{
> + return drm_crtc_vblank_helper_get_vblank_timestamp_internal(
> + crtc, max_error, vblank_time, in_vblank_irq,
> + crtc->helper_private->get_scanout_position, NULL);
> +}
> +EXPORT_SYMBOL(drm_crtc_vblank_helper_get_vblank_timestamp);
> +
> /**
> * drm_get_last_vbltimestamp - retrieve raw timestamp for the most recent
> * vblank interval
> @@ -799,15 +844,22 @@ static bool
> drm_get_last_vbltimestamp(struct drm_device *dev, unsigned int pipe,
> ktime_t *tvblank, bool in_vblank_irq)
> {
> + struct drm_crtc *crtc = drm_crtc_from_index(dev, pipe);
> bool ret = false;
>
> /* Define requested maximum error on timestamps (nanoseconds). */
> int max_error = (int) drm_timestamp_precision * 1000;
>
> /* Query driver if possible and precision timestamping enabled. */
> - if (dev->driver->get_vblank_timestamp && (max_error > 0))
> + if (crtc && crtc->funcs->get_vblank_timestamp && max_error > 0) {
> + struct drm_crtc *crtc = drm_crtc_from_index(dev, pipe);
> +
> + ret = crtc->funcs->get_vblank_timestamp(crtc, _error,
> + tvblank, in_vblank_irq);
> + } else if (dev->driver->get_vblank_timestamp && max_error > 0) {
> ret = dev->driver->get_vblank_timestamp(dev, pipe, _error,
> tvblank, in_vblank_irq);
> + }
>
> /* GPU high precision timestamp query unsupported or failed.
>* Return current monotonic/gettimeofday timestamp as best estimate.
> @@ -1790,9 +1842,11 @@ int drm_wait_vblank_ioctl(struct drm_device *dev, void
> *data,
>
> static void drm_handle_vblank_events(struct drm_device *dev, unsigned int
> pipe)
> {
> + struct drm_crtc *crtc = drm_crtc_from_index(dev, pipe);
> struct drm_pending_vblank_event *e, *t;
> ktime_t now;
> u64 seq;
> + bool high_prec;
>
> assert_spin_locked(>event_lock);
>
> @@ -1812,8 +1866,10 @@ static void drm_handle_vblank_events(struct drm_device
> *dev, unsigned int pipe)
> send_vblank_event(dev, e, seq, now);
> }
>
> - trace_drm_vblank_event(pipe, seq, now,
> - dev->driver->get_vblank_timestamp != NULL);
> + high_prec = crtc && crtc->funcs->get_vblank_timestamp ||
> + dev->driver->get_vblank_timestamp;
I'm sure gcc will complain about the && vs. || here. Hmm, yeah looks
like quite a few gcc/sparse/checkpatch warnings in this series.
With some of the more important warns fixed patches 1-3 are
Reviewed-by: Ville Syrjälä
> +
> + trace_drm_vblank_event(pipe, seq, now, high_prec);
> }
>
> /**
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 5e9b15a0e8c5..db46abbbf4e7 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -867,6 +867,47 @@ struct drm_crtc_funcs {
>* new drivers as the replacement of _driver.disable_vblank hook.
>*/
> void (*disable_vblank)(struct drm_crtc *crtc);
> +
> + /**
> + * @get_vblank_timestamp:
> + *
> + * Called by drm_get_last_vbltimestamp(). Should return a precise
> + * timestamp when the most recent vblank interval ended or will end.
> + *
> + * Specifically, the timestamp in @vblank_time should correspond as
> + * closely as possible to the time when the first video scanline of
> + * the video frame after the end of vblank will start scanning out,
> + * the time immediately after end of the vblank interval. If the
> + * @crtc is currently inside vblank, this will be a time in the future.
> + * If the @crtc is currently scanning out a frame, this will be the
> + * past start time of the current scanout. This
Re: [Nouveau] [Intel-gfx] [PATCH v2 03/21] drm: Add get_vblank_timestamp() to struct drm_crtc_funcs
* measured. Note that this is a helper callback which is only used
> - * if a driver uses drm_calc_vbltimestamp_from_scanoutpos() for the
> - * @drm_driver.get_vblank_timestamp callback.
> + * if a driver uses drm_crtc_vblank_helper_get_vblank_timestamp()
> + * for the @drm_crtc_funcs.get_vblank_timestamp callback.
>*
>* Parameters:
>*
> diff --git a/include/drm/drm_vblank.h b/include/drm/drm_vblank.h
> index c16c44052b3d..248fbd5de177 100644
> --- a/include/drm/drm_vblank.h
> +++ b/include/drm/drm_vblank.h
> @@ -174,13 +174,13 @@ struct drm_vblank_crtc {
> unsigned int pipe;
> /**
>* @framedur_ns: Frame/Field duration in ns, used by
> - * drm_calc_vbltimestamp_from_scanoutpos() and computed by
> + * drm_crtc_vblank_helper_get_vblank_timestamp() and computed by
>* drm_calc_timestamping_constants().
>*/
> int framedur_ns;
> /**
>* @linedur_ns: Line duration in ns, used by
> - * drm_calc_vbltimestamp_from_scanoutpos() and computed by
> + * drm_crtc_vblank_helper_get_vblank_timestamp() and computed by
>* drm_calc_timestamping_constants().
>*/
> int linedur_ns;
> @@ -190,8 +190,8 @@ struct drm_vblank_crtc {
>*
>* Cache of the current hardware display mode. Only valid when @enabled
>* is set. This is used by helpers like
> - * drm_calc_vbltimestamp_from_scanoutpos(). We can't just access the
> - * hardware mode by e.g. looking at _crtc_state.adjusted_mode,
> + * drm_crtc_vblank_helper_get_vblank_timestamp(). We can't just access
> + * the hardware mode by e.g. looking at _crtc_state.adjusted_mode,
>* because that one is really hard to get from interrupt context.
>*/
> struct drm_display_mode hwmode;
> @@ -238,4 +238,22 @@ void drm_calc_timestamping_constants(struct drm_crtc
> *crtc,
> wait_queue_head_t *drm_crtc_vblank_waitqueue(struct drm_crtc *crtc);
> void drm_crtc_set_max_vblank_count(struct drm_crtc *crtc,
> u32 max_vblank_count);
> +
> +/*
> + * Helpers for struct drm_crtc_funcs
> + */
> +
> +bool
> +drm_crtc_vblank_helper_get_vblank_timestamp_internal(
> + struct drm_crtc *crtc, int *max_error, ktime_t *vblank_time,
> + bool in_vblank_irq,
> + bool (*get_scanout_position)(struct drm_crtc *crtc,
> + bool in_vblank_irq, int *vpos, int
> *hpos,
> + ktime_t *stime, ktime_t *etime,
> + const struct drm_display_mode *mode));
Ugly alignment. Could maybe add a typedef for the function pointer if it
otherwise gets super horrible with proper alignment.
> +bool drm_crtc_vblank_helper_get_vblank_timestamp(struct drm_crtc *crtc,
> + int *max_error,
> + ktime_t *vblank_time,
> + bool in_vblank_irq);
> +
> #endif
> --
> 2.24.1
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [Intel-gfx] [PATCH v2 03/21] drm: Add get_vblank_timestamp() to struct drm_crtc_funcs
On Thu, Jan 16, 2020 at 09:44:55AM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 15.01.20 um 15:49 schrieb Ville Syrjälä:
> > On Wed, Jan 15, 2020 at 01:16:34PM +0100, Thomas Zimmermann wrote:
> >> @@ -2020,3 +2042,193 @@ int drm_crtc_queue_sequence_ioctl(struct
> >> drm_device *dev, void *data,
> >>kfree(e);
> >>return ret;
> >> }
> >> +
> >> +/*
> >> + * Helpers for struct drm_crtc_funcs
> >> + */
> >> +
> >> +/**
> >> + * drm_crtc_vblank_helper_get_vblank_timestamp_internal - precise vblank
> >> + *timestamp helper
> >> + * @dev: DRM device
> >> + * @pipe: index of CRTC whose vblank timestamp to retrieve
> >> + * @max_error: Desired maximum allowable error in timestamps (nanosecs)
> >> + * On return contains true maximum error of timestamp
> >> + * @vblank_time: Pointer to time which should receive the timestamp
> >> + * @in_vblank_irq:
> >> + * True when called from drm_crtc_handle_vblank(). Some drivers
> >> + * need to apply some workarounds for gpu-specific vblank irq quirks
> >> + * if flag is set.
> >> + * @get_scanout_position:
> >> + * Callback function to retrieve the scanout position. See
> >> + * @struct drm_crtc_helper_funcs.get_scanout_position.
> >> + *
> >> + * Implements calculation of exact vblank timestamps from given
> >> drm_display_mode
> >> + * timings and current video scanout position of a CRTC.
> >> + *
> >> + * The current implementation only handles standard video modes. For
> >> double scan
> >> + * and interlaced modes the driver is supposed to adjust the hardware mode
> >> + * (taken from _crtc_state.adjusted mode for atomic modeset drivers)
> >> to
> >> + * match the scanout position reported.
> >> + *
> >> + * Note that atomic drivers must call drm_calc_timestamping_constants()
> >> before
> >> + * enabling a CRTC. The atomic helpers already take care of that in
> >> + * drm_atomic_helper_update_legacy_modeset_state().
> >> + *
> >> + * Returns:
> >> + *
> >> + * Returns true on success, and false on failure, i.e. when no accurate
> >> + * timestamp could be acquired.
> >> + */
> >> +bool
> >> +drm_crtc_vblank_helper_get_vblank_timestamp_internal(
> >> + struct drm_crtc *crtc, int *max_error, ktime_t *vblank_time,
> >> + bool in_vblank_irq,
> >> + bool (*get_scanout_position)(struct drm_crtc *crtc,
> >> + bool in_vblank_irq, int *vpos, int
> >> *hpos,
> >> + ktime_t *stime, ktime_t *etime,
> >> + const struct drm_display_mode *mode))
> >> +{
> >> + struct drm_device *dev = crtc->dev;
> >> + unsigned int pipe = crtc->index;
> >> + struct drm_vblank_crtc *vblank = >vblank[pipe];
> >> + struct timespec64 ts_etime, ts_vblank_time;
> >> + ktime_t stime, etime;
> >> + bool vbl_status;
> >> + const struct drm_display_mode *mode;
> >> + int vpos, hpos, i;
> >> + int delta_ns, duration_ns;
> >> +
> >> + if (pipe >= dev->num_crtcs) {
> >> + DRM_ERROR("Invalid crtc %u\n", pipe);
> >> + return false;
> >> + }
> >> +
> >> + /* Scanout position query not supported? Should not happen. */
> >> + if (!get_scanout_position) {
> >> + DRM_ERROR("Called from CRTC w/o get_scanout_position()!?\n");
> >> + return false;
> >> + }
> >> +
> >> + if (drm_drv_uses_atomic_modeset(dev))
> >> + mode = >hwmode;
> >> + else
> >> + mode = >hwmode;
> >> +
> >> + /* If mode timing undefined, just return as no-op:
> >> + * Happens during initial modesetting of a crtc.
> >> + */
> >> + if (mode->crtc_clock == 0) {
> >> + DRM_DEBUG("crtc %u: Noop due to uninitialized mode.\n", pipe);
> >> + WARN_ON_ONCE(drm_drv_uses_atomic_modeset(dev));
> >> + return false;
> >> + }
> >> +
> >> + /* Get current scanout position with system timestamp.
> >> + * Repeat query up to DRM_TIMESTAMP_MAXRETRIES times
> >> + * if single query takes longer than max_error nanoseconds.
> >> + *
> &g
Re: [Nouveau] [Intel-gfx] [PATCH v2 02/21] drm: Evaluate struct drm_device.vblank_disable_immediate on each use
On Wed, Jan 15, 2020 at 01:16:33PM +0100, Thomas Zimmermann wrote:
> VBLANK interrupts can be disabled immediately or with a delay, where the
> latter is the default. The former option can be selected by setting
> get_vblank_timestamp, and enabling vblank_disable_immediate in struct
> drm_device.
>
> The setup is only evaluated once when DRM initializes VBLANKs. Evaluating
> the settings on each use of vblank_disable_immediate will allow for easy
> integration of CRTC VBLANK functions.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/drm_vblank.c | 31 ++-
> 1 file changed, 14 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> index 3f1dd54cc8bb..abb085c67d82 100644
> --- a/drivers/gpu/drm/drm_vblank.c
> +++ b/drivers/gpu/drm/drm_vblank.c
> @@ -481,19 +481,6 @@ int drm_vblank_init(struct drm_device *dev, unsigned int
> num_crtcs)
>
> DRM_INFO("Supports vblank timestamp caching Rev 2 (21.10.2013).\n");
>
> - /* Driver specific high-precision vblank timestamping supported? */
> - if (dev->driver->get_vblank_timestamp)
> - DRM_INFO("Driver supports precise vblank timestamp query.\n");
> - else
> - DRM_INFO("No driver support for vblank timestamp query.\n");
> -
> - /* Must have precise timestamping for reliable vblank instant disable */
> - if (dev->vblank_disable_immediate &&
> !dev->driver->get_vblank_timestamp) {
> - dev->vblank_disable_immediate = false;
> - DRM_INFO("Setting vblank_disable_immediate to false because "
> - "get_vblank_timestamp == NULL\n");
> - }
Which drivers are so broken they set vblank_disable_immediate to true
without having the vfunc specified? IMO this code should just go away
(or converted to a WARN).
> -
> return 0;
>
> err:
> @@ -1070,6 +1057,15 @@ int drm_crtc_vblank_get(struct drm_crtc *crtc)
> }
> EXPORT_SYMBOL(drm_crtc_vblank_get);
>
> +static bool __vblank_disable_immediate(struct drm_device *dev, unsigned int
> pipe)
> +{
> + if (!dev->vblank_disable_immediate)
> + return false;
> + if (!dev->driver->get_vblank_timestamp)
> + return false;
> + return true;
> +}
> +
> static void drm_vblank_put(struct drm_device *dev, unsigned int pipe)
> {
> struct drm_vblank_crtc *vblank = >vblank[pipe];
> @@ -1086,7 +1082,7 @@ static void drm_vblank_put(struct drm_device *dev,
> unsigned int pipe)
> return;
> else if (drm_vblank_offdelay < 0)
> vblank_disable_fn(>disable_timer);
> - else if (!dev->vblank_disable_immediate)
> + else if (__vblank_disable_immediate(dev, pipe))
> mod_timer(>disable_timer,
> jiffies + ((drm_vblank_offdelay * HZ)/1000));
> }
> @@ -1663,7 +1659,7 @@ int drm_wait_vblank_ioctl(struct drm_device *dev, void
> *data,
> /* If the counter is currently enabled and accurate, short-circuit
>* queries to return the cached timestamp of the last vblank.
>*/
> - if (dev->vblank_disable_immediate &&
> + if (__vblank_disable_immediate(dev, pipe) &&
> drm_wait_vblank_is_query(vblwait) &&
> READ_ONCE(vblank->enabled)) {
> drm_wait_vblank_reply(dev, pipe, >reply);
> @@ -1820,7 +1816,7 @@ bool drm_handle_vblank(struct drm_device *dev, unsigned
> int pipe)
>* been signaled. The disable has to be last (after
>* drm_handle_vblank_events) so that the timestamp is always accurate.
>*/
> - disable_irq = (dev->vblank_disable_immediate &&
> + disable_irq = (__vblank_disable_immediate(dev, pipe) &&
> drm_vblank_offdelay > 0 &&
> !atomic_read(>refcount));
>
> @@ -1893,7 +1889,8 @@ int drm_crtc_get_sequence_ioctl(struct drm_device *dev,
> void *data,
> pipe = drm_crtc_index(crtc);
>
> vblank = >vblank[pipe];
> - vblank_enabled = dev->vblank_disable_immediate &&
> READ_ONCE(vblank->enabled);
> + vblank_enabled = __vblank_disable_immediate(dev, pipe) &&
> + READ_ONCE(vblank->enabled);
>
> if (!vblank_enabled) {
> ret = drm_crtc_vblank_get(crtc);
> --
> 2.24.1
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v2 07/21] drm/i915: Convert to CRTC VBLANK callbacks
et) % vtotal;
> }
>
> -bool i915_get_crtc_scanoutpos(struct drm_device *dev, unsigned int index,
> - bool in_vblank_irq, int *vpos, int *hpos,
> - ktime_t *stime, ktime_t *etime,
> - const struct drm_display_mode *mode)
> +static bool i915_get_crtc_scanoutpos(struct drm_crtc *dcrtc,
'struct drm_crtc *_crtc'
is the style we're going with these days.
> + bool in_vblank_irq,
> + int *vpos, int *hpos,
> + ktime_t *stime, ktime_t *etime,
> + const struct drm_display_mode *mode)
> {
> + struct drm_device *dev = dcrtc->dev;
> struct drm_i915_private *dev_priv = to_i915(dev);
> - struct intel_crtc *crtc = to_intel_crtc(drm_crtc_from_index(dev,
> index));
> + struct intel_crtc *crtc = to_intel_crtc(dcrtc);
> enum pipe pipe = crtc->pipe;
> int position;
> int vbl_start, vbl_end, hsync_start, htotal, vtotal;
> @@ -879,6 +881,14 @@ bool i915_get_crtc_scanoutpos(struct drm_device *dev,
> unsigned int index,
> return true;
> }
>
> +bool i915_crtc_get_vblank_timestamp(struct drm_crtc *crtc, int *max_error,
> + ktime_t *vblank_time, bool in_vblank_irq)
'intel_crtc_get_vblank_timestamp' pls.
Otherwise lgtm
Reviewed-by: Ville Syrjälä
> +{
> + return drm_crtc_vblank_helper_get_vblank_timestamp_internal(
> + crtc, max_error, vblank_time, in_vblank_irq,
> + i915_get_crtc_scanoutpos);
> +}
> +
> int intel_get_crtc_scanline(struct intel_crtc *crtc)
> {
> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> diff --git a/drivers/gpu/drm/i915/i915_irq.h b/drivers/gpu/drm/i915/i915_irq.h
> index 812c47a9c2d6..53ec921c1c67 100644
> --- a/drivers/gpu/drm/i915/i915_irq.h
> +++ b/drivers/gpu/drm/i915/i915_irq.h
> @@ -101,10 +101,8 @@ void gen8_irq_power_well_post_enable(struct
> drm_i915_private *dev_priv,
> void gen8_irq_power_well_pre_disable(struct drm_i915_private *dev_priv,
>u8 pipe_mask);
>
> -bool i915_get_crtc_scanoutpos(struct drm_device *dev, unsigned int pipe,
> - bool in_vblank_irq, int *vpos, int *hpos,
> - ktime_t *stime, ktime_t *etime,
> - const struct drm_display_mode *mode);
> +bool i915_crtc_get_vblank_timestamp(struct drm_crtc *crtc, int *max_error,
> + ktime_t *vblank_time, bool in_vblank_irq);
>
> u32 i915_get_vblank_counter(struct drm_crtc *crtc);
> u32 g4x_get_vblank_counter(struct drm_crtc *crtc);
> --
> 2.24.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 03/23] drm/i915: Don't use struct drm_driver.get_scanout_position()
On Fri, Jan 10, 2020 at 03:56:06PM +0200, Jani Nikula wrote: > On Fri, 10 Jan 2020, Thomas Zimmermann wrote: > > Hi > > > > Am 10.01.20 um 12:59 schrieb Jani Nikula: > >> On Fri, 10 Jan 2020, Thomas Zimmermann wrote: > >>> The callback struct drm_driver.get_scanout_position() is deprecated in > >>> favor of struct drm_crtc_helper_funcs.get_scanout_position(). > >>> > >>> i915 doesn't use CRTC helpers. The patch duplicates the caller > >>> drm_calc_vbltimestamp_from_scanoutpos() for i915, such that the callback > >>> function is not needed. > >>> > >>> Signed-off-by: Thomas Zimmermann > >>> --- > >>> drivers/gpu/drm/i915/i915_drv.c | 3 +- > >>> drivers/gpu/drm/i915/i915_irq.c | 117 ++-- > >>> drivers/gpu/drm/i915/i915_irq.h | 9 +-- > >>> 3 files changed, 119 insertions(+), 10 deletions(-) > >> > >> Not really enthusiastic about the diffstat in a "cleanup" series. > > > > Well, the cleanup is about the content of drm_driver :) > > > >> > >> I wonder if you could add a generic helper version of > >> drm_calc_vbltimestamp_from_scanoutpos where you pass the > >> get_scanout_position function as a parameter. Both > >> drm_calc_vbltimestamp_from_scanoutpos and the new > >> i915_calc_vbltimestamp_from_scanoutpos would then be fairly thin > >> wrappers passing in the relevant get_scanout_position function. > > > > Of course. Will be in v2 of the series. > > Please give Ville (Cc'd) a moment before sending v2 in case he wants to > chime in on this. Passing the function pointer was one option I considered for this a while back. Can't remeber what other solutions I condsidered. But I guess I didn't like any of them enough to make an actual patch. -- Ville Syrjälä Intel ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v2] drm/connector: Allow max possible encoders to attach to a connector
On Thu, Sep 05, 2019 at 02:09:27PM -0700, José Roberto de Souza wrote:
> From: Dhinakaran Pandiyan
>
> Currently we restrict the number of encoders that can be linked to
> a connector to 3, increase it to match the maximum number of encoders
> that can be initialized(32).
>
> To more effiently do that lets switch from an array of encoder ids to
> bitmask.
>
> Also removing the best_encoder hook from the drivers that only have
> one encoder per connector(this ones have one encoder in the whole
> driver), pick_single_encoder_for_connector() will do the same job
> with no functional change.
I don't think non-atomic drivers have that fallback in place.
They probable should...
Apart from that lgtm
Reviewed-by: Ville Syrjälä
>
> v2: Fixing missed return on amdgpu_dm_connector_to_encoder()
>
> Suggested-by: Ville Syrjälä
> Cc: Ville Syrjälä
> Cc: Alex Deucher
> Cc: dri-de...@lists.freedesktop.org
> Cc: intel-...@lists.freedesktop.org
> Cc: nouveau@lists.freedesktop.org
> Cc: amd-...@lists.freedesktop.org
> Signed-off-by: Dhinakaran Pandiyan
> Signed-off-by: José Roberto de Souza
> ---
> .../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 23 +-
> drivers/gpu/drm/amd/amdgpu/dce_virtual.c | 5 ++-
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 6 +++-
> drivers/gpu/drm/ast/ast_mode.c| 12 ---
> drivers/gpu/drm/drm_atomic_helper.c | 9 --
> drivers/gpu/drm/drm_client_modeset.c | 3 +-
> drivers/gpu/drm/drm_connector.c | 31 +--
> drivers/gpu/drm/drm_probe_helper.c| 3 +-
> drivers/gpu/drm/mgag200/mgag200_mode.c| 11 ---
> drivers/gpu/drm/nouveau/dispnv04/disp.c | 2 +-
> drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +-
> drivers/gpu/drm/nouveau/nouveau_connector.c | 7 ++---
> drivers/gpu/drm/radeon/radeon_connectors.c| 27 ++--
> drivers/gpu/drm/udl/udl_connector.c | 8 -
> include/drm/drm_connector.h | 18 +--
> 15 files changed, 53 insertions(+), 114 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> index ece55c8fa673..d8729285f731 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> @@ -217,11 +217,10 @@ amdgpu_connector_update_scratch_regs(struct
> drm_connector *connector,
> struct drm_encoder *encoder;
> const struct drm_connector_helper_funcs *connector_funcs =
> connector->helper_private;
> bool connected;
> - int i;
>
> best_encoder = connector_funcs->best_encoder(connector);
>
> - drm_connector_for_each_possible_encoder(connector, encoder, i) {
> + drm_connector_for_each_possible_encoder(connector, encoder) {
> if ((encoder == best_encoder) && (status ==
> connector_status_connected))
> connected = true;
> else
> @@ -236,9 +235,8 @@ amdgpu_connector_find_encoder(struct drm_connector
> *connector,
> int encoder_type)
> {
> struct drm_encoder *encoder;
> - int i;
>
> - drm_connector_for_each_possible_encoder(connector, encoder, i) {
> + drm_connector_for_each_possible_encoder(connector, encoder) {
> if (encoder->encoder_type == encoder_type)
> return encoder;
> }
> @@ -347,10 +345,9 @@ static struct drm_encoder *
> amdgpu_connector_best_single_encoder(struct drm_connector *connector)
> {
> struct drm_encoder *encoder;
> - int i;
>
> /* pick the first one */
> - drm_connector_for_each_possible_encoder(connector, encoder, i)
> + drm_connector_for_each_possible_encoder(connector, encoder)
> return encoder;
>
> return NULL;
> @@ -1065,9 +1062,8 @@ amdgpu_connector_dvi_detect(struct drm_connector
> *connector, bool force)
> /* find analog encoder */
> if (amdgpu_connector->dac_load_detect) {
> struct drm_encoder *encoder;
> - int i;
>
> - drm_connector_for_each_possible_encoder(connector, encoder, i) {
> + drm_connector_for_each_possible_encoder(connector, encoder) {
> if (encoder->encoder_type != DRM_MODE_ENCODER_DAC &&
> encoder->encoder_type != DRM_MODE_ENCODER_TVDAC)
> continue;
> @@ -1117,9 +1113,8 @@ amdgpu_connector_dvi_encoder(struct drm_connector
> *connector)
> {
> struct amdgpu_connector *amdgpu_connector =
> to_amdgpu_connect
Re: [Nouveau] [PATCH v7 1/9] drm_dp_cec: add connector info support.
nnector_register(struct drm_connector *connector)
> {
> struct intel_dp *intel_dp = intel_attached_dp(connector);
> - struct drm_device *dev = connector->dev;
> int ret;
>
> ret = intel_connector_register(connector);
> @@ -5512,8 +5511,7 @@ intel_dp_connector_register(struct drm_connector
> *connector)
> intel_dp->aux.dev = connector->kdev;
> ret = drm_dp_aux_register(_dp->aux);
> if (!ret)
> - drm_dp_cec_register_connector(_dp->aux,
> - connector->name, dev->dev);
> + drm_dp_cec_register_connector(_dp->aux, connector);
> return ret;
> }
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
> b/drivers/gpu/drm/nouveau/nouveau_connector.c
> index 330d7d29a6e34..8aa703347eb54 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_connector.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
> @@ -1416,8 +1416,7 @@ nouveau_connector_create(struct drm_device *dev,
> switch (type) {
> case DRM_MODE_CONNECTOR_DisplayPort:
> case DRM_MODE_CONNECTOR_eDP:
> - drm_dp_cec_register_connector(_connector->aux,
> - connector->name, dev->dev);
> + drm_dp_cec_register_connector(_connector->aux, connector);
> break;
> }
>
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 8364502f92cfe..7972b925a952b 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -1230,20 +1230,19 @@ struct drm_dp_aux_msg {
>
> struct cec_adapter;
> struct edid;
> +struct drm_connector;
>
> /**
> * struct drm_dp_aux_cec - DisplayPort CEC-Tunneling-over-AUX
> * @lock: mutex protecting this struct
> * @adap: the CEC adapter for CEC-Tunneling-over-AUX support.
> - * @name: name of the CEC adapter
> - * @parent: parent device of the CEC adapter
> + * @connector: the connector this CEC adapter is associated with
> * @unregister_work: unregister the CEC adapter
> */
> struct drm_dp_aux_cec {
> struct mutex lock;
> struct cec_adapter *adap;
> - const char *name;
> - struct device *parent;
> + struct drm_connector *connector;
I think all current users could just pass the connector to
cec_set_edid(). So could save a pointer here.
Anyways
Reviewed-by: Ville Syrjälä
> struct delayed_work unregister_work;
> };
>
> @@ -1451,8 +1450,8 @@ drm_dp_has_quirk(const struct drm_dp_desc *desc, enum
> drm_dp_quirk quirk)
>
> #ifdef CONFIG_DRM_DP_CEC
> void drm_dp_cec_irq(struct drm_dp_aux *aux);
> -void drm_dp_cec_register_connector(struct drm_dp_aux *aux, const char *name,
> -struct device *parent);
> +void drm_dp_cec_register_connector(struct drm_dp_aux *aux,
> +struct drm_connector *connector);
> void drm_dp_cec_unregister_connector(struct drm_dp_aux *aux);
> void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const struct edid *edid);
> void drm_dp_cec_unset_edid(struct drm_dp_aux *aux);
> @@ -1461,9 +1460,9 @@ static inline void drm_dp_cec_irq(struct drm_dp_aux
> *aux)
> {
> }
>
> -static inline void drm_dp_cec_register_connector(struct drm_dp_aux *aux,
> - const char *name,
> - struct device *parent)
> +static inline void
> +drm_dp_cec_register_connector(struct drm_dp_aux *aux,
> + struct drm_connector *connector)
> {
> }
>
> --
> 2.23.0.rc1.153.gdeed80330f-goog
--
Ville Syrjälä
Intel
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v3 5/7] drm/nouveau: utilize subconnector property for DP
On Wed, Aug 28, 2019 at 11:11:41AM -0400, Ilia Mirkin wrote: > On Wed, Aug 28, 2019 at 10:54 AM Ville Syrjälä > wrote: > > > > On Wed, Aug 28, 2019 at 10:47:08AM -0400, Ilia Mirkin wrote: > > > On Wed, Aug 28, 2019 at 10:38 AM Ville Syrjälä > > > wrote: > > > > > > > > On Mon, Aug 26, 2019 at 09:36:50AM -0400, Ilia Mirkin wrote: > > > > > This should probably be fixed to account for the scenario where an > > > > > HDMI connector is plugged directly into the DP++ port. I don't think > > > > > the dp.subconnector property will be valid in that case. > > > > > (Unfortunately I don't remember how one detects that particular > > > > > situation.) > > > > > > > > One may or may not be able to detect it very well. I've seen dongles > > > > that automagically change the DFP type from DP++ to DP/HDMI depending > > > > on what's plugged in, and I've also seen dongles that leave the DFP > > > > type to DP++. > > > > > > Well, our internal logic certainly knows if it's driving DP or TMDS. I > > > just don't remember how it knows this. > > > > You'll be driving DP in this case. The DFP will be the one driving > > DP or TMDS depending on what's plugged in. > > OK. That's not the case I was worried about though :) > > I'm worried about the case where you plug a true HDMI thing into the > DP port, which will then be driven by HDMI and none of the dp.* things > will be set (I don't remember, but they might even be in a union). I > think Intel multiplies connectors for this, but nouveau/amd just have > a single connector that handles both. Ah. Yeah, that's a bit more confusing since you kinda now have two levels of subconnectors. Not sure how to deal with that tbh. -- Ville Syrjälä Intel ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v3 5/7] drm/nouveau: utilize subconnector property for DP
On Wed, Aug 28, 2019 at 10:47:08AM -0400, Ilia Mirkin wrote: > On Wed, Aug 28, 2019 at 10:38 AM Ville Syrjälä > wrote: > > > > On Mon, Aug 26, 2019 at 09:36:50AM -0400, Ilia Mirkin wrote: > > > This should probably be fixed to account for the scenario where an > > > HDMI connector is plugged directly into the DP++ port. I don't think > > > the dp.subconnector property will be valid in that case. > > > (Unfortunately I don't remember how one detects that particular > > > situation.) > > > > One may or may not be able to detect it very well. I've seen dongles > > that automagically change the DFP type from DP++ to DP/HDMI depending > > on what's plugged in, and I've also seen dongles that leave the DFP > > type to DP++. > > Well, our internal logic certainly knows if it's driving DP or TMDS. I > just don't remember how it knows this. You'll be driving DP in this case. The DFP will be the one driving DP or TMDS depending on what's plugged in. -- Ville Syrjälä Intel ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v3 5/7] drm/nouveau: utilize subconnector property for DP
> + }
> > + nv_encoder->dp.subconnector = drm_dp_subconnector_type(dpcd,
> > port_cap);
> > +
> > nv_encoder->dp.link_bw = 27000 * dpcd[1];
> > nv_encoder->dp.link_nr = dpcd[2] & DP_MAX_LANE_COUNT_MASK;
> >
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_encoder.h
> > b/drivers/gpu/drm/nouveau/nouveau_encoder.h
> > index 3517f920bf89..e17971a30221 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_encoder.h
> > +++ b/drivers/gpu/drm/nouveau/nouveau_encoder.h
> > @@ -63,6 +63,7 @@ struct nouveau_encoder {
> > struct nv50_mstm *mstm;
> > int link_nr;
> > int link_bw;
> > + enum drm_mode_subconnector subconnector;
> > } dp;
> > };
> >
> > --
> > 2.23.0
> >
> > ___
> > Nouveau mailing list
> > Nouveau@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/nouveau
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [PATCH v2] drm: Bump encoder limit from 32 to 64
>base, DRM_MODE_OBJECT_ENCODER);
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 7d14c11bdc0a..fd0b2438c3d5 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -210,7 +210,7 @@ struct drm_crtc_state {
>* @encoder_mask: Bitmask of drm_encoder_mask(encoder) of encoders
>* attached to this CRTC.
>*/
> - u32 encoder_mask;
> + u64 encoder_mask;
>
> /**
>* @adjusted_mode:
> diff --git a/include/drm/drm_encoder.h b/include/drm/drm_encoder.h
> index 70cfca03d812..3f9cb65694e1 100644
> --- a/include/drm/drm_encoder.h
> +++ b/include/drm/drm_encoder.h
> @@ -159,7 +159,15 @@ struct drm_encoder {
>* encoders can be used in a cloned configuration, they both should have
>* each another bits set.
>*
> - * In reality almost every driver gets this wrong.
> + * In reality almost every driver gets this wrong, and most modern
> + * display hardware does not have support for cloning. As well, while we
> + * expose this mask to userspace as 32bits long, we do sure purely to
> + * avoid breaking pre-existing UAPI since the limitation on the number
> + * of encoders has been increased from 32 bits to 64 bits. In order to
> + * maintain functionality for drivers which do actually support cloning,
> + * we only allow cloning with encoders that have an index <32. Encoders
> + * with indexes higher than 32 are not allowed to specify a non-zero
> + * value here.
>*
>* Note that since encoder objects can't be hotplugged the assigned
> indices
>* are stable and hence known before registering all objects.
> @@ -198,13 +206,15 @@ static inline unsigned int drm_encoder_index(const
> struct drm_encoder *encoder)
> }
>
> /**
> - * drm_encoder_mask - find the mask of a registered ENCODER
> + * drm_encoder_mask - find the mask of a registered encoder
> * @encoder: encoder to find mask for
> *
> - * Given a registered encoder, return the mask bit of that encoder for an
> - * encoder's possible_clones field.
> + * Returns:
> + * A bit mask with the nth bit set, where n is the index of the encoder. Take
> + * care when using this, as the DRM UAPI only allows for 32 bit encoder masks
> + * while internally encoder masks are 64 bits.
> */
> -static inline u32 drm_encoder_mask(const struct drm_encoder *encoder)
> +static inline u64 drm_encoder_mask(const struct drm_encoder *encoder)
> {
> return 1 << drm_encoder_index(encoder);
> }
> --
> 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: [Nouveau] [PATCH v3 04/10] drm: Convert connector_helper_funcs->atomic_check to accept drm_atomic_state
On Thu, May 16, 2019 at 02:07:34PM +0200, Daniel Vetter wrote: > On Thu, May 16, 2019 at 2:02 PM Laurent Pinchart > wrote: > > > > Hi Daniel, > > > > On Mon, May 13, 2019 at 04:47:47PM +0200, Daniel Vetter wrote: > > > On Sat, May 11, 2019 at 10:12:02PM +0300, Laurent Pinchart wrote: > > > > On Thu, May 02, 2019 at 03:49:46PM -0400, Sean Paul wrote: > > > >> From: Sean Paul > > > >> > > > >> Everyone who implements connector_helper_funcs->atomic_check reaches > > > >> into the connector state to get the atomic state. Instead of continuing > > > >> this pattern, change the callback signature to just give atomic state > > > >> and let the driver determine what it does and does not need from it. > > > >> > > > >> Eventually all atomic functions should do this, but that's just too > > > >> much > > > >> busy work for me. > > > > > > > > Given that drivers also access the connector state, isn't this slightly > > > > more inefficient ? > > > > > > It's atomic code, we're trying to optimize for clean code at the expense > > > of a bit of runtime overhead due to more pointer chasing. And I agree with > > > the general push, the pile of old/new_state pointers of various objects > > > we're passing around is confusing. Passing the overall drm_atomic_state > > > seems much more reasonable, and with that we can get everything else. Plus > > > it's much more obvious whether you have the old/new state (since that's > > > explicit when you look it up from the drm_atomic_state). > > > > Yes, I agree it's cleaner. I just hope the atomic state tracking cost > > can be kept under control :-) > > > > By the way, this is likely not going to happen as it would be way too > > intrusive, but it would be nice to rename drm_atomic_state to > > drm_atomic_transaction (or something similar). It doesn't model a state, > > but a change between an old state to a new state. This confused me in > > the past, and I'm sure it can still be confusing to newcomers. > > Why are you the first to suggest this, this is awesome! Can't quite tell if that's irony or not. Anyways, this has been suggested before but no volunteers stepped forward. > drm_atomic_state is indeed not a state, but a transaction representing > how we go from the old to the new state. On a semi-related topic, I've occasionally pondered about moving mode_changed & co. from the obj states to the top level state/transaction (maybe stored as a bitmask). But that would definitely not be a trivial sed job. -- Ville Syrjälä Intel ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 1/4] drm/edid: Pass connector to AVI inforframe functions
On Tue, Dec 04, 2018 at 08:46:53AM +0100, Andrzej Hajda wrote: > On 03.12.2018 22:38, Ville Syrjälä wrote: > > On Thu, Nov 29, 2018 at 10:08:07AM +0100, Andrzej Hajda wrote: > >> On 21.11.2018 19:19, Laurent Pinchart wrote: > >>> Hi Ville, > >>> > >>> Thank you for the patch. > >>> > >>> On Tuesday, 20 November 2018 18:13:42 EET Ville Syrjala wrote: > >>>> From: Ville Syrjälä > >>>> > >>>> Make life easier for drivers by simply passing the connector > >>>> to drm_hdmi_avi_infoframe_from_display_mode() and > >>>> drm_hdmi_avi_infoframe_quant_range(). That way drivers don't > >>>> need to worry about is_hdmi2_sink mess. > >>> While this is good for display controller drivers, the change isn't great > >>> for > >>> bridge drivers. Down the road we're looking at moving connector support > >>> out of > >>> the bridge drivers. Adding an additional dependency to connectors in the > >>> bridges will make that more difficult. Ideally bridges should retrieve > >>> the > >>> information from their sink, regardless of whether it is a connector or > >>> another bridge. > >> > >> I agree with it, and case of sii8620 shows that there are cases where > >> bridge has no direct access to the connector. > > It's just a matter of plumbing it through. > > > What do you mean exactly? void bridge_foo(... + ,struct drm_connector *connector); > > > > > >> On the other side, since you are passing connector to > >> drm_hdmi_avi_infoframe_from_display_mode(), you could drop mode > >> parameter and rename the function to > >> drm_hdmi_avi_infoframe_from_connector() then, unless mode passed and > >> mode set on the connector differs? > > Connectors don't have a mode. > > > As they are passing video stream they should have it, even if not > directly, for example: > > connector->state->crtc->mode That's not really how atomic works. One shouldn't go digging through the obj->state pointers when we're not holding the relevant locks anymore. The atomic way would be to pass either both crtc state and connector state, or drm_atomic_state + crtc/connector. > > In moment of creating infoframe it should be set properly. > > > Regards > > Andrzej > > > > > >> > >> Regards > >> > >> Andrzej > >> > >> > >>> Please see below for an additional comment. > >>> > >>>> Cc: Alex Deucher > >>>> Cc: "Christian König" > >>>> Cc: "David (ChunMing) Zhou" > >>>> Cc: Archit Taneja > >>>> Cc: Andrzej Hajda > >>>> Cc: Laurent Pinchart > >>>> Cc: Inki Dae > >>>> Cc: Joonyoung Shim > >>>> Cc: Seung-Woo Kim > >>>> Cc: Kyungmin Park > >>>> Cc: Russell King > >>>> Cc: CK Hu > >>>> Cc: Philipp Zabel > >>>> Cc: Rob Clark > >>>> Cc: Ben Skeggs > >>>> Cc: Tomi Valkeinen > >>>> Cc: Sandy Huang > >>>> Cc: "Heiko Stübner" > >>>> Cc: Benjamin Gaignard > >>>> Cc: Vincent Abriou > >>>> Cc: Thierry Reding > >>>> Cc: Eric Anholt > >>>> Cc: Shawn Guo > >>>> Cc: Ilia Mirkin > >>>> Cc: amd-...@lists.freedesktop.org > >>>> Cc: linux-arm-...@vger.kernel.org > >>>> Cc: freedr...@lists.freedesktop.org > >>>> Cc: nouveau@lists.freedesktop.org > >>>> Cc: linux-te...@vger.kernel.org > >>>> Signed-off-by: Ville Syrjälä > >>>> --- > >>>> drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 2 +- > >>>> drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 2 +- > >>>> drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 3 ++- > >>>> drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 2 +- > >>>> drivers/gpu/drm/bridge/analogix-anx78xx.c | 5 ++-- > >>>> drivers/gpu/drm/bridge/sii902x.c | 3 ++- > >>>> drivers/gpu/drm/bridge/sil-sii8620.c | 3 +-- > >>>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 3 ++- > >>>> drivers/gpu/drm/drm_edid.c| 33 ++- > >>>> drivers/gpu/drm/exynos/exynos_hdmi.c | 3 ++- > >>>> driver
Re: [Nouveau] [PATCH 1/4] drm/edid: Pass connector to AVI inforframe functions
On Wed, Dec 05, 2018 at 09:46:40AM +0100, Andrzej Hajda wrote: > On 05.12.2018 07:32, Laurent Pinchart wrote: > > Hi Ville, > > > > On Tuesday, 4 December 2018 21:13:20 EET Ville Syrjälä wrote: > >> On Tue, Dec 04, 2018 at 08:46:53AM +0100, Andrzej Hajda wrote: > >>> On 03.12.2018 22:38, Ville Syrjälä wrote: > >>>> On Thu, Nov 29, 2018 at 10:08:07AM +0100, Andrzej Hajda wrote: > >>>>> On 21.11.2018 19:19, Laurent Pinchart wrote: > >>>>>> On Tuesday, 20 November 2018 18:13:42 EET Ville Syrjala wrote: > >>>>>>> From: Ville Syrjälä > >>>>>>> > >>>>>>> Make life easier for drivers by simply passing the connector > >>>>>>> to drm_hdmi_avi_infoframe_from_display_mode() and > >>>>>>> drm_hdmi_avi_infoframe_quant_range(). That way drivers don't > >>>>>>> need to worry about is_hdmi2_sink mess. > >>>>>> While this is good for display controller drivers, the change isn't > >>>>>> great for bridge drivers. Down the road we're looking at moving > >>>>>> connector support out of the bridge drivers. Adding an additional > >>>>>> dependency to connectors in the bridges will make that more > >>>>>> difficult. Ideally bridges should retrieve the information from their > >>>>>> sink, regardless of whether it is a connector or another bridge. > >>>>> I agree with it, and case of sii8620 shows that there are cases where > >>>>> bridge has no direct access to the connector. > >>>> It's just a matter of plumbing it through. > >>> What do you mean exactly? > >> void bridge_foo(... > >> + ,struct drm_connector *connector); > >> > >>>>> On the other side, since you are passing connector to > >>>>> drm_hdmi_avi_infoframe_from_display_mode(), you could drop mode > >>>>> parameter and rename the function to > >>>>> drm_hdmi_avi_infoframe_from_connector() then, unless mode passed and > >>>>> mode set on the connector differs? > >>>> Connectors don't have a mode. > >>> As they are passing video stream they should have it, even if not > >>> directly, for example: > >>> > >>> connector->state->crtc->mode > >> That's not really how atomic works. One shouldn't go digging > >> through the obj->state pointers when we're not holding the > >> relevant locks anymore. The atomic way would be to pass either > >> both crtc state and connector state, or drm_atomic_state + > >> crtc/connector. > > > Usually infoframe contents is generated in modesetting/enable callbacks > so the locks should be in place. Not when doing a nonblocking modeset. > > And the locks should be hold for > drm_hdmi_avi_infoframe_from_display_mode as well - it wouldn't be correct if > > generated infoframe is not relevant to actual video mode. I guess that > if connector->state->crtc->mode > > differs from mode passed to drm_hdmi_avi_infoframe_from_display_mode it > is a sign of possible problem. > > And if they do not differ passing mode as an extra argument is redundant. > > > > Or a bridge state ? With chained bridges the mode can vary along the > > pipeline, > > the CRTC adjusted mode will only cover the link between the CRTC and the > > first > > bridge. It's only a matter of time until we need to store other > > intermediate > > modes in states. I'd rather prepare for that instead of passing the CRTC > > state > > to bridges. > > > Yes, optional bridge states seems reasonable, volunteers needed :) > > > Regards > > Andrzej > > > > > >>> In moment of creating infoframe it should be set properly. > >>> > >>>>>> Please see below for an additional comment. > >>>>>> > >>>>>>> Cc: Alex Deucher > >>>>>>> Cc: "Christian König" > >>>>>>> Cc: "David (ChunMing) Zhou" > >>>>>>> Cc: Archit Taneja > >>>>>>> Cc: Andrzej Hajda > >>>>>>> Cc: Laurent Pinchart > >>>>>>> Cc: Inki Dae > >>>>>>> Cc: Joonyoung Shim > >>>>>> Cc: Seung-Woo Kim > >>>>>>> Cc: Kyungmin Park > >>>>>>> Cc: Russell King &g
Re: [Nouveau] [PATCH 1/4] drm/edid: Pass connector to AVI inforframe functions
On Tue, Dec 04, 2018 at 08:03:53AM +0100, Andrzej Hajda wrote:
> On 03.12.2018 22:48, Ville Syrjälä wrote:
> > On Thu, Nov 29, 2018 at 09:46:16AM +0100, Andrzej Hajda wrote:
> >> Quite late, hopefully not too late.
> >>
> >>
> >> On 21.11.2018 12:51, Ville Syrjälä wrote:
> >>> On Wed, Nov 21, 2018 at 01:40:43PM +0200, Jani Nikula wrote:
> >>>>> return;
> >>>>> diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c
> >>>>> b/drivers/gpu/drm/bridge/sil-sii8620.c
> >>>>> index a6e8f4591e63..0cc293a6ac24 100644
> >>>>> --- a/drivers/gpu/drm/bridge/sil-sii8620.c
> >>>>> +++ b/drivers/gpu/drm/bridge/sil-sii8620.c
> >>>>> @@ -1104,8 +1104,7 @@ static void sii8620_set_infoframes(struct sii8620
> >>>>> *ctx,
> >>>>> int ret;
> >>>>>
> >>>>> ret = drm_hdmi_avi_infoframe_from_display_mode(,
> >>>>> - mode,
> >>>>> - true);
> >>>>> + NULL, mode);
> >>>>> if (ctx->use_packed_pixel)
> >>>>> frm.avi.colorspace = HDMI_COLORSPACE_YUV422;
> >>>>>
> >>>>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> >>>>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> >>>>> index 64c3cf027518..88b720b63126 100644
> >>>>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> >>>>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> >>>>> @@ -1344,7 +1344,8 @@ static void hdmi_config_AVI(struct dw_hdmi *hdmi,
> >>>>> struct drm_display_mode *mode)
> >>>>> u8 val;
> >>>>>
> >>>>> /* Initialise info frame from DRM mode */
> >>>>> - drm_hdmi_avi_infoframe_from_display_mode(, mode, false);
> >>>>> + drm_hdmi_avi_infoframe_from_display_mode(,
> >>>>> +>connector,
> >>>>> mode);
> >>>>>
> >>>>> if (hdmi_bus_fmt_is_yuv444(hdmi->hdmi_data.enc_out_bus_format))
> >>>>> frame.colorspace = HDMI_COLORSPACE_YUV444;
> >>>>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> >>>>> index b506e3622b08..501ac05ba7da 100644
> >>>>> --- a/drivers/gpu/drm/drm_edid.c
> >>>>> +++ b/drivers/gpu/drm/drm_edid.c
> >>>>> @@ -4830,19 +4830,32 @@ void drm_set_preferred_mode(struct
> >>>>> drm_connector *connector,
> >>>>> }
> >>>>> EXPORT_SYMBOL(drm_set_preferred_mode);
> >>>>>
> >>>>> +static bool is_hdmi2_sink(struct drm_connector *connector)
> >>>> You're usually known for adding const all around, why not const pointer
> >>>> here and in all the other drm_* functions that call this?
> >>> My current approach is to constify states/fbs/etc. but not so much
> >>> crtcs/connectors/etc. Too much const can sometimes get in the way
> >>> of things requiring that you remove the const later. But I guess
> >>> in this case the const shouldn't really get in the way of anything
> >>> because these are pretty much supposed to be pure functions.
> >>>
> >>>>> +{
> >>>>> + /*
> >>>>> +* FIXME: sil-sii8620 doesn't have a connector around when
> >>>>> +* we need one, so we have to be prepared for a NULL connector.
> >>>>> +*/
> >>>>> + if (!connector)
> >>>>> + return false;
> >>>> This actually changes the is_hdmi2_sink value for sil-sii8620.
> >>> Hmm. No idea why they would have set that to true when everyone else is
> >>> passing false.
> >>
> >> Because false does not work :) More precisely MHLv3 (used in Sii8620)
> >> uses CTA-861-F standard for infoframes, which is specific to HDMI2.0.
> >>
> >> Unfortunately I have no access to MHL specs, but my experiments and
> >> vendor drivers strongly suggests it is done this way.
> >>
> >> This is important in case of 4K modes which are handled differently by
> &g
Re: [Nouveau] [PATCH 1/4] drm/edid: Pass connector to AVI inforframe functions
On Wed, Dec 05, 2018 at 08:40:34AM +0100, Andrzej Hajda wrote:
> On 04.12.2018 20:02, Ville Syrjälä wrote:
> > On Tue, Dec 04, 2018 at 08:03:53AM +0100, Andrzej Hajda wrote:
> >> On 03.12.2018 22:48, Ville Syrjälä wrote:
> >>> On Thu, Nov 29, 2018 at 09:46:16AM +0100, Andrzej Hajda wrote:
> >>>> Quite late, hopefully not too late.
> >>>>
> >>>>
> >>>> On 21.11.2018 12:51, Ville Syrjälä wrote:
> >>>>> On Wed, Nov 21, 2018 at 01:40:43PM +0200, Jani Nikula wrote:
> >>>>>>> return;
> >>>>>>> diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c
> >>>>>>> b/drivers/gpu/drm/bridge/sil-sii8620.c
> >>>>>>> index a6e8f4591e63..0cc293a6ac24 100644
> >>>>>>> --- a/drivers/gpu/drm/bridge/sil-sii8620.c
> >>>>>>> +++ b/drivers/gpu/drm/bridge/sil-sii8620.c
> >>>>>>> @@ -1104,8 +1104,7 @@ static void sii8620_set_infoframes(struct
> >>>>>>> sii8620 *ctx,
> >>>>>>> int ret;
> >>>>>>>
> >>>>>>> ret = drm_hdmi_avi_infoframe_from_display_mode(,
> >>>>>>> -mode,
> >>>>>>> -true);
> >>>>>>> +NULL, mode);
> >>>>>>> if (ctx->use_packed_pixel)
> >>>>>>> frm.avi.colorspace = HDMI_COLORSPACE_YUV422;
> >>>>>>>
> >>>>>>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> >>>>>>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> >>>>>>> index 64c3cf027518..88b720b63126 100644
> >>>>>>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> >>>>>>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> >>>>>>> @@ -1344,7 +1344,8 @@ static void hdmi_config_AVI(struct dw_hdmi
> >>>>>>> *hdmi, struct drm_display_mode *mode)
> >>>>>>> u8 val;
> >>>>>>>
> >>>>>>> /* Initialise info frame from DRM mode */
> >>>>>>> - drm_hdmi_avi_infoframe_from_display_mode(, mode, false);
> >>>>>>> + drm_hdmi_avi_infoframe_from_display_mode(,
> >>>>>>> + >connector,
> >>>>>>> mode);
> >>>>>>>
> >>>>>>> if (hdmi_bus_fmt_is_yuv444(hdmi->hdmi_data.enc_out_bus_format))
> >>>>>>> frame.colorspace = HDMI_COLORSPACE_YUV444;
> >>>>>>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> >>>>>>> index b506e3622b08..501ac05ba7da 100644
> >>>>>>> --- a/drivers/gpu/drm/drm_edid.c
> >>>>>>> +++ b/drivers/gpu/drm/drm_edid.c
> >>>>>>> @@ -4830,19 +4830,32 @@ void drm_set_preferred_mode(struct
> >>>>>>> drm_connector *connector,
> >>>>>>> }
> >>>>>>> EXPORT_SYMBOL(drm_set_preferred_mode);
> >>>>>>>
> >>>>>>> +static bool is_hdmi2_sink(struct drm_connector *connector)
> >>>>>> You're usually known for adding const all around, why not const pointer
> >>>>>> here and in all the other drm_* functions that call this?
> >>>>> My current approach is to constify states/fbs/etc. but not so much
> >>>>> crtcs/connectors/etc. Too much const can sometimes get in the way
> >>>>> of things requiring that you remove the const later. But I guess
> >>>>> in this case the const shouldn't really get in the way of anything
> >>>>> because these are pretty much supposed to be pure functions.
> >>>>>
> >>>>>>> +{
> >>>>>>> + /*
> >>>>>>> + * FIXME: sil-sii8620 doesn't have a connector around when
> >>>>>>> + * we need one, so we have to be prepared for a NULL connector.
> >>>>>>> + */
> >>>>>>> + if (!connector)
> >>>>>>> + return false;
> >>>>>> This actually changes the i
Re: [Nouveau] [PATCH 1/4] drm/edid: Pass connector to AVI inforframe functions
On Thu, Nov 29, 2018 at 09:46:16AM +0100, Andrzej Hajda wrote:
> Quite late, hopefully not too late.
>
>
> On 21.11.2018 12:51, Ville Syrjälä wrote:
> > On Wed, Nov 21, 2018 at 01:40:43PM +0200, Jani Nikula wrote:
> >>
> >>> return;
> >>> diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c
> >>> b/drivers/gpu/drm/bridge/sil-sii8620.c
> >>> index a6e8f4591e63..0cc293a6ac24 100644
> >>> --- a/drivers/gpu/drm/bridge/sil-sii8620.c
> >>> +++ b/drivers/gpu/drm/bridge/sil-sii8620.c
> >>> @@ -1104,8 +1104,7 @@ static void sii8620_set_infoframes(struct sii8620
> >>> *ctx,
> >>> int ret;
> >>>
> >>> ret = drm_hdmi_avi_infoframe_from_display_mode(,
> >>> -mode,
> >>> -true);
> >>> +NULL, mode);
> >>> if (ctx->use_packed_pixel)
> >>> frm.avi.colorspace = HDMI_COLORSPACE_YUV422;
> >>>
> >>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> >>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> >>> index 64c3cf027518..88b720b63126 100644
> >>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> >>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> >>> @@ -1344,7 +1344,8 @@ static void hdmi_config_AVI(struct dw_hdmi *hdmi,
> >>> struct drm_display_mode *mode)
> >>> u8 val;
> >>>
> >>> /* Initialise info frame from DRM mode */
> >>> - drm_hdmi_avi_infoframe_from_display_mode(, mode, false);
> >>> + drm_hdmi_avi_infoframe_from_display_mode(,
> >>> + >connector, mode);
> >>>
> >>> if (hdmi_bus_fmt_is_yuv444(hdmi->hdmi_data.enc_out_bus_format))
> >>> frame.colorspace = HDMI_COLORSPACE_YUV444;
> >>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> >>> index b506e3622b08..501ac05ba7da 100644
> >>> --- a/drivers/gpu/drm/drm_edid.c
> >>> +++ b/drivers/gpu/drm/drm_edid.c
> >>> @@ -4830,19 +4830,32 @@ void drm_set_preferred_mode(struct drm_connector
> >>> *connector,
> >>> }
> >>> EXPORT_SYMBOL(drm_set_preferred_mode);
> >>>
> >>> +static bool is_hdmi2_sink(struct drm_connector *connector)
> >> You're usually known for adding const all around, why not const pointer
> >> here and in all the other drm_* functions that call this?
> > My current approach is to constify states/fbs/etc. but not so much
> > crtcs/connectors/etc. Too much const can sometimes get in the way
> > of things requiring that you remove the const later. But I guess
> > in this case the const shouldn't really get in the way of anything
> > because these are pretty much supposed to be pure functions.
> >
> >>> +{
> >>> + /*
> >>> + * FIXME: sil-sii8620 doesn't have a connector around when
> >>> + * we need one, so we have to be prepared for a NULL connector.
> >>> + */
> >>> + if (!connector)
> >>> + return false;
> >> This actually changes the is_hdmi2_sink value for sil-sii8620.
> > Hmm. No idea why they would have set that to true when everyone else is
> > passing false.
>
>
> Because false does not work :) More precisely MHLv3 (used in Sii8620)
> uses CTA-861-F standard for infoframes, which is specific to HDMI2.0.
>
> Unfortunately I have no access to MHL specs, but my experiments and
> vendor drivers strongly suggests it is done this way.
>
> This is important in case of 4K modes which are handled differently by
> HDMI 1.4 and HDMI2.0.
HDMI 2.0 handles 4k just like 1.4 handled it when you use one of
the 4k modes defined in 1.4. Only if you use features beyond 1.4 do we
switch over to the HDMI 2.0 specific signalling.
>
> The pipeline looks like (in parenthesis HDMI version on the stream):
>
> exynos_hdmi --(1.4)--> SII8620 --(2.0)--> MHL_dongle --(1.4)--> TV
>
>
> > I guess I can change this to true to not change it. IIRC
> > that was the only driver that didn't have a connector around.
> >
> > That said, I was actually thinking of removing this hdmi2 vs. not
> > stuff from drm_hdmi_avi_infoframe_from_display_mode(). We added it
> > "just in case", but we already have a similar issue with earlier
> > cea-861 revisions and haven't seen any bugs where an older monitor
> > would get confused by a VIC not yet defined when the monitor was
> > produced.
> >
> Are you sure this is a good idea? As I said earlier 4K modes are present
> in HDMI 1.4 and 2.0 but they are handled differently, so this is not
> only matter of unknown VIC in AVIF.
>
>
> Regards
>
> Andrzej
--
Ville Syrjälä
Intel
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 1/4] drm/edid: Pass connector to AVI inforframe functions
On Thu, Nov 29, 2018 at 10:08:07AM +0100, Andrzej Hajda wrote: > On 21.11.2018 19:19, Laurent Pinchart wrote: > > Hi Ville, > > > > Thank you for the patch. > > > > On Tuesday, 20 November 2018 18:13:42 EET Ville Syrjala wrote: > >> From: Ville Syrjälä > >> > >> Make life easier for drivers by simply passing the connector > >> to drm_hdmi_avi_infoframe_from_display_mode() and > >> drm_hdmi_avi_infoframe_quant_range(). That way drivers don't > >> need to worry about is_hdmi2_sink mess. > > While this is good for display controller drivers, the change isn't great > > for > > bridge drivers. Down the road we're looking at moving connector support out > > of > > the bridge drivers. Adding an additional dependency to connectors in the > > bridges will make that more difficult. Ideally bridges should retrieve the > > information from their sink, regardless of whether it is a connector or > > another bridge. > > > I agree with it, and case of sii8620 shows that there are cases where > bridge has no direct access to the connector. It's just a matter of plumbing it through. > > On the other side, since you are passing connector to > drm_hdmi_avi_infoframe_from_display_mode(), you could drop mode > parameter and rename the function to > drm_hdmi_avi_infoframe_from_connector() then, unless mode passed and > mode set on the connector differs? Connectors don't have a mode. > > > Regards > > Andrzej > > > > > > Please see below for an additional comment. > > > >> Cc: Alex Deucher > >> Cc: "Christian König" > >> Cc: "David (ChunMing) Zhou" > >> Cc: Archit Taneja > >> Cc: Andrzej Hajda > >> Cc: Laurent Pinchart > >> Cc: Inki Dae > >> Cc: Joonyoung Shim > >> Cc: Seung-Woo Kim > >> Cc: Kyungmin Park > >> Cc: Russell King > >> Cc: CK Hu > >> Cc: Philipp Zabel > >> Cc: Rob Clark > >> Cc: Ben Skeggs > >> Cc: Tomi Valkeinen > >> Cc: Sandy Huang > >> Cc: "Heiko Stübner" > >> Cc: Benjamin Gaignard > >> Cc: Vincent Abriou > >> Cc: Thierry Reding > >> Cc: Eric Anholt > >> Cc: Shawn Guo > >> Cc: Ilia Mirkin > >> Cc: amd-...@lists.freedesktop.org > >> Cc: linux-arm-...@vger.kernel.org > >> Cc: freedr...@lists.freedesktop.org > >> Cc: nouveau@lists.freedesktop.org > >> Cc: linux-te...@vger.kernel.org > >> Signed-off-by: Ville Syrjälä > >> --- > >> drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 2 +- > >> drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 2 +- > >> drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 3 ++- > >> drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 2 +- > >> drivers/gpu/drm/bridge/analogix-anx78xx.c | 5 ++-- > >> drivers/gpu/drm/bridge/sii902x.c | 3 ++- > >> drivers/gpu/drm/bridge/sil-sii8620.c | 3 +-- > >> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 3 ++- > >> drivers/gpu/drm/drm_edid.c| 33 ++- > >> drivers/gpu/drm/exynos/exynos_hdmi.c | 3 ++- > >> drivers/gpu/drm/i2c/tda998x_drv.c | 3 ++- > >> drivers/gpu/drm/i915/intel_hdmi.c | 14 +- > >> drivers/gpu/drm/i915/intel_lspcon.c | 15 ++- > >> drivers/gpu/drm/i915/intel_sdvo.c | 10 --- > >> drivers/gpu/drm/mediatek/mtk_hdmi.c | 3 ++- > >> drivers/gpu/drm/msm/hdmi/hdmi_bridge.c| 3 ++- > >> drivers/gpu/drm/nouveau/dispnv50/disp.c | 7 +++-- > >> drivers/gpu/drm/omapdrm/omap_encoder.c| 5 ++-- > >> drivers/gpu/drm/radeon/radeon_audio.c | 2 +- > >> drivers/gpu/drm/rockchip/inno_hdmi.c | 4 ++- > >> drivers/gpu/drm/sti/sti_hdmi.c| 3 ++- > >> drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c| 3 ++- > >> drivers/gpu/drm/tegra/hdmi.c | 3 ++- > >> drivers/gpu/drm/tegra/sor.c | 3 ++- > >> drivers/gpu/drm/vc4/vc4_hdmi.c| 11 +--- > >> drivers/gpu/drm/zte/zx_hdmi.c | 4 ++- > >> include/drm/drm_edid.h| 8 +++--- > >> 27 files changed, 94 insertions(+), 66 deletions(-) > > For dw-hdmi and omapdrm, > > > > Reviewed-by: Laurent Pinchart > > -- Ville Syrjälä Intel ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v3 1/3] drm/connector: Add generic underscan properties
On Thu, Nov 22, 2018 at 12:23:29PM +0100, Boris Brezillon wrote:
> @@ -924,6 +978,29 @@ struct drm_connector {
>*/
> struct drm_property_blob *path_blob_ptr;
>
> + /**
> + * @underscan_mode_property: Optional connector underscan mode. Used by
> + * the driver to scale the output image and compensate an overscan done
> + * on the display side.
> + */
> + struct drm_property *underscan_mode_property;
> +
> + /**
> + * @underscan_hborder_property: Optional connector underscan horizontal
> + * border (expressed in pixels). Used by the driver to adjust the
> + * output image position and compensate an overscan done on the display
> + * side.
> + */
> + struct drm_property *underscan_hborder_property;
> +
> + /**
> + * @underscan_hborder_property: Optional connector underscan vertical
> + * border (expressed in pixels). Used by the driver to adjust the
> + * output image position and compensate an overscan done on the display
> + * side.
> + */
> + struct drm_property *underscan_vborder_property;
I'm wondering why we're adding these new props when we already have the
(slightly more flexible) margin properties for TV out. We could just
reuse those AFAICS.
> +
> #define DRM_CONNECTOR_POLL_HPD (1 << 0)
> #define DRM_CONNECTOR_POLL_CONNECT (1 << 1)
> #define DRM_CONNECTOR_POLL_DISCONNECT (1 << 2)
> @@ -1180,6 +1257,9 @@ int drm_mode_create_dvi_i_properties(struct drm_device
> *dev);
> int drm_mode_create_tv_properties(struct drm_device *dev,
> unsigned int num_modes,
> const char * const modes[]);
> +int drm_connector_attach_underscan_properties(struct drm_connector
> *connector,
> + u32 mode_mask, u64 max_hborder,
> + u64 max_vborder);
> int drm_mode_create_scaling_mode_property(struct drm_device *dev);
> int drm_connector_attach_content_type_property(struct drm_connector *dev);
> int drm_connector_attach_scaling_mode_property(struct drm_connector
> *connector,
> --
> 2.17.1
--
Ville Syrjälä
Intel
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 1/4] drm/edid: Pass connector to AVI inforframe functions
On Wed, Nov 21, 2018 at 01:40:43PM +0200, Jani Nikula wrote:
> On Tue, 20 Nov 2018, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Make life easier for drivers by simply passing the connector
> > to drm_hdmi_avi_infoframe_from_display_mode() and
> > drm_hdmi_avi_infoframe_quant_range(). That way drivers don't
> > need to worry about is_hdmi2_sink mess.
>
> Overall looks about right and nice,
>
> Reviewed-by: Jani Nikula
>
> But please do take that with a grain of salt for everything outside of
> i915 and drm core.
>
> Please also find a few comments inline below.
>
> > Cc: Alex Deucher
> > Cc: "Christian König"
> > Cc: "David (ChunMing) Zhou"
> > Cc: Archit Taneja
> > Cc: Andrzej Hajda
> > Cc: Laurent Pinchart
> > Cc: Inki Dae
> > Cc: Joonyoung Shim
> > Cc: Seung-Woo Kim
> > Cc: Kyungmin Park
> > Cc: Russell King
> > Cc: CK Hu
> > Cc: Philipp Zabel
> > Cc: Rob Clark
> > Cc: Ben Skeggs
> > Cc: Tomi Valkeinen
> > Cc: Sandy Huang
> > Cc: "Heiko Stübner"
> > Cc: Benjamin Gaignard
> > Cc: Vincent Abriou
> > Cc: Thierry Reding
> > Cc: Eric Anholt
> > Cc: Shawn Guo
> > Cc: Ilia Mirkin
> > Cc: amd-...@lists.freedesktop.org
> > Cc: linux-arm-...@vger.kernel.org
> > Cc: freedr...@lists.freedesktop.org
> > Cc: nouveau@lists.freedesktop.org
> > Cc: linux-te...@vger.kernel.org
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 2 +-
> > drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 2 +-
> > drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 3 ++-
> > drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 2 +-
> > drivers/gpu/drm/bridge/analogix-anx78xx.c | 5 ++--
> > drivers/gpu/drm/bridge/sii902x.c | 3 ++-
> > drivers/gpu/drm/bridge/sil-sii8620.c | 3 +--
> > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 3 ++-
> > drivers/gpu/drm/drm_edid.c| 33 ++-
> > drivers/gpu/drm/exynos/exynos_hdmi.c | 3 ++-
> > drivers/gpu/drm/i2c/tda998x_drv.c | 3 ++-
> > drivers/gpu/drm/i915/intel_hdmi.c | 14 +-
> > drivers/gpu/drm/i915/intel_lspcon.c | 15 ++-
> > drivers/gpu/drm/i915/intel_sdvo.c | 10 ---
> > drivers/gpu/drm/mediatek/mtk_hdmi.c | 3 ++-
> > drivers/gpu/drm/msm/hdmi/hdmi_bridge.c| 3 ++-
> > drivers/gpu/drm/nouveau/dispnv50/disp.c | 7 +++--
> > drivers/gpu/drm/omapdrm/omap_encoder.c| 5 ++--
> > drivers/gpu/drm/radeon/radeon_audio.c | 2 +-
> > drivers/gpu/drm/rockchip/inno_hdmi.c | 4 ++-
> > drivers/gpu/drm/sti/sti_hdmi.c| 3 ++-
> > drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c| 3 ++-
> > drivers/gpu/drm/tegra/hdmi.c | 3 ++-
> > drivers/gpu/drm/tegra/sor.c | 3 ++-
> > drivers/gpu/drm/vc4/vc4_hdmi.c| 11 +---
> > drivers/gpu/drm/zte/zx_hdmi.c | 4 ++-
> > include/drm/drm_edid.h| 8 +++---
> > 27 files changed, 94 insertions(+), 66 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> > b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> > index 4cfecdce29a3..1f0426d2fc2a 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> > @@ -1682,7 +1682,7 @@ static void dce_v10_0_afmt_setmode(struct drm_encoder
> > *encoder,
> > dce_v10_0_audio_write_sad_regs(encoder);
> > dce_v10_0_audio_write_latency_fields(encoder, mode);
> >
> > - err = drm_hdmi_avi_infoframe_from_display_mode(, mode, false);
> > + err = drm_hdmi_avi_infoframe_from_display_mode(, connector, mode);
> > if (err < 0) {
> > DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
> > return;
> > diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> > b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> > index 7c868916d90f..2280b971d758 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> > @@ -1724,7 +1724,7 @@ static void dce_v11_0_afmt_setmode(struct drm_encoder
> > *encoder,
> > dce_v11_0_audio_write_sad_regs(encoder);
> > dce_v11_0_audio_write_latency_fields(encoder, mode);
> >
> > - err = drm_hdmi_avi_infoframe_from_display_mode(, mode, false);
> > + err = drm_hdmi_avi_infoframe_from_display_mode(, connector, mode);
> > if (err < 0) {
> >
Re: [Nouveau] [Intel-gfx] [PATCH 2/2] drm/atomic: Create and use __drm_atomic_helper_crtc_reset() everywhere
struct drm_crtc_state *crtc_state = > + kzalloc(sizeof(*crtc->state), GFP_KERNEL); > + > if (crtc->state) > __drm_atomic_helper_crtc_destroy_state(crtc->state); > > kfree(crtc->state); > - crtc->state = kzalloc(sizeof(*crtc->state), GFP_KERNEL); > - > - if (crtc->state) > - crtc->state->crtc = crtc; > + __drm_atomic_helper_crtc_reset(crtc, crtc_state); > } > EXPORT_SYMBOL(drm_atomic_helper_crtc_reset); > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index f383417571ec..907ffeb64781 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -15457,7 +15457,7 @@ static void intel_modeset_readout_hw_state(struct > drm_device *dev) > > __drm_atomic_helper_crtc_destroy_state(_state->base); > memset(crtc_state, 0, sizeof(*crtc_state)); > - crtc_state->base.crtc = >base; > + __drm_atomic_helper_crtc_reset(>base, _state->base); intel_crtc_init() could use the same treatment. And intel_create_plane_state() could use the plane reset. In fact it looks like we aren't intializing plane constant alpha at all. So it'll start out as zero which probably isn't what most people would expect. I also wonder if this patch shouldn't be split up more. Just in case there's some unforseen regression somewhere I'd hate to see the entire thing get reverted. -- Ville Syrjälä Intel ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] drm/nouveau: tegra: Initialize mode configuration
b
> 00546958 bea73b0c
> [ 19.120708] ffe0: bea73af8 bea73ae8 b6c44c14 b6b4b710 600d0010
> 000f
> [ 19.128884] [] (drm_plane_register_all) from []
> (drm_modeset_register_all+0xc/0x70)
> [ 19.138273] [] (drm_modeset_register_all) from
> [] (drm_dev_register+0x168/0x1c4)
> [ 19.147581] [] (drm_dev_register) from []
> (nouveau_platform_probe+0x6c/0x88 [nouveau])
> [ 19.157434] [] (nouveau_platform_probe [nouveau]) from
> [] (platform_drv_probe+0x48/0x98)
> [ 19.167256] [] (platform_drv_probe) from []
> (really_probe+0x1e0/0x2cc)
> [ 19.175516] [] (really_probe) from []
> (driver_probe_device+0x60/0x16c)
> [ 19.183777] [] (driver_probe_device) from []
> (__driver_attach+0xdc/0xe0)
> [ 19.192210] [] (__driver_attach) from []
> (bus_for_each_dev+0x74/0xb4)
> [ 19.200383] [] (bus_for_each_dev) from []
> (bus_add_driver+0x1c0/0x204)
> [ 19.208644] [] (bus_add_driver) from []
> (driver_register+0x74/0x108)
> [ 19.216928] [] (driver_register) from []
> (nouveau_drm_init+0x170/0x1000 [nouveau])
> [ 19.226429] [] (nouveau_drm_init [nouveau]) from
> [] (do_one_initcall+0x54/0x284)
> [ 19.235557] [] (do_one_initcall) from []
> (do_init_module+0x64/0x214)
> [ 19.243643] [] (do_init_module) from []
> (load_module+0x1e30/0x24a8)
> [ 19.251643] [] (load_module) from []
> (sys_finit_module+0xc4/0xdc)
> [ 19.259470] [] (sys_finit_module) from []
> (__sys_trace_return+0x0/0x2c)
> [ 19.267807] Exception stack(0xed5dffa8 to 0xed5dfff0)
> [ 19.272853] ffa0: b6c51c58 000f
> b6c51c58 00559220
> [ 19.281018] ffc0: b6c51c58 000f 017b
> 00546958 bea73b0c
> [ 19.289182] ffe0: bea73af8 bea73ae8 b6c44c14 b6b4b710
> [ 19.294224] Code: e5b54250 e1550004 0a0c e2444004 (e5943070)
> [ 19.300863] ---[ end trace 7cb25d313b9a3b9d ]---
>
> Fix this by initializing the mode configuration structure in the Tegra
> case as well. No other modeset helper setup is required.
>
> Signed-off-by: Thierry Reding
> ---
> drivers/gpu/drm/nouveau/nouveau_platform.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_platform.c
> b/drivers/gpu/drm/nouveau/nouveau_platform.c
> index 039e23548e08..1d4c895b379d 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_platform.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_platform.c
> @@ -34,6 +34,8 @@ static int nouveau_platform_probe(struct platform_device
> *pdev)
> if (IS_ERR(drm))
> return PTR_ERR(drm);
>
> + drm_mode_config_init(drm);
> +
> ret = drm_dev_register(drm, 0);
> if (ret < 0) {
> drm_dev_put(drm);
> @@ -46,7 +48,10 @@ static int nouveau_platform_probe(struct platform_device
> *pdev)
> static int nouveau_platform_remove(struct platform_device *pdev)
> {
> struct drm_device *dev = platform_get_drvdata(pdev);
> +
> + drm_mode_config_cleanup(dev);
> nouveau_drm_device_remove(dev);
> +
> return 0;
> }
>
> --
> 2.19.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v7 1/5] drm/atomic_helper: Disallow new modesets on unregistered connectors
On Mon, Oct 08, 2018 at 07:24:30PM -0400, Lyude Paul wrote:
> With the exception of modesets which would switch the DPMS state of a
> connector from on to off, we want to make sure that we disallow all
> modesets which would result in enabling a new monitor or a new mode
> configuration on a monitor if the connector for the display in question
> is no longer registered. This allows us to stop userspace from trying to
> enable new displays on connectors for an MST topology that were just
> removed from the system, without preventing userspace from disabling
> DPMS on those connectors.
>
> Changes since v5:
> - Fix typo in comment, nothing else
>
> Signed-off-by: Lyude Paul
> Reviewed-by: Daniel Vetter
> Cc: sta...@vger.kernel.org
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 21 -
> 1 file changed, 20 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 6f66777dca4b..e6a2cf72de5e 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -319,6 +319,26 @@ update_connector_routing(struct drm_atomic_state *state,
> return 0;
> }
>
> + crtc_state = drm_atomic_get_new_crtc_state(state,
> +new_connector_state->crtc);
> + /*
> + * For compatibility with legacy users, we want to make sure that
> + * we allow DPMS On->Off modesets on unregistered connectors. Modesets
> + * which would result in anything else must be considered invalid, to
> + * avoid turning on new displays on dead connectors.
> + *
> + * Since the connector can be unregistered at any point during an
> + * atomic check or commit, this is racy. But that's OK: all we care
> + * about is ensuring that userspace can't do anything but shut off the
> + * display on a connector that was destroyed after its been notified,
> + * not before.
> + */
> + if (!READ_ONCE(connector->registered) && crtc_state->active) {
> + DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] is not registered\n",
> + connector->base.id, connector->name);
> + return -EINVAL;
> + }
This broke my ilk (and presumably snb-bdw as well).
[ 25.593121] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] Updating
routing for [CONNECTOR:55:eDP-1]
[ 25.593131] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]]
[CONNECTOR:55:eDP-1] is not registered
[ 25.593133] [ cut here ]
[ 25.593134] Could not determine valid watermarks for inherited state
[ 25.593212] WARNING: CPU: 0 PID: 3060 at
../drivers/gpu/drm/i915/intel_display.c:14983 intel_modeset_init+0x12cf/0x1980
[i915]
Also I can't see that any of the repostings of this has undergone the
full CI run (just BAT results are visible). Not sure why that is.
Not that the full run would have caught this because we unwisely
load the module before the tests start. Which means any failures
during initial readout/takeover will not be flagged :(
> +
> funcs = connector->helper_private;
>
> if (funcs->atomic_best_encoder)
> @@ -363,7 +383,6 @@ update_connector_routing(struct drm_atomic_state *state,
>
> set_best_encoder(state, new_connector_state, new_encoder);
>
> - crtc_state = drm_atomic_get_new_crtc_state(state,
> new_connector_state->crtc);
> crtc_state->connectors_changed = true;
>
> DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] using [ENCODER:%d:%s] on
> [CRTC:%d:%s]\n",
> --
> 2.17.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 1/2] drm/nouveau: Disable atomic support on a per-device basis
On Thu, Sep 13, 2018 at 05:02:05PM -0400, Lyude Paul wrote: > Hm, one nitpick here. Since /sys/kernel/debug/dri/*/state creation depends on > the driver supporting atomic, maybe it would be good to make it so that we set > DRIVER_ATOMIC in the driver_stub structure, then disable it per-device > depending > on the nouveau_atomic setting + hw support. That way we can always have the > state debugfs file while maintaining nouveau's current behavior with exposing > atomic ioctls. Assuming that wouldn't have any unintended side-effects of > course I'm not sure why there are three driver structs in nouveau. Maybe someone can just nuke two of them? > > On Thu, 2018-09-13 at 19:31 +0300, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > We now have per-device driver_features, so let's use that > > to disable atomic only for pre-nv50. > > > > Cc: Ben Skeggs > > Cc: Lyude Paul > > Cc: nouveau@lists.freedesktop.org > > Cc: Daniel Vetter > > Reviewed-by: Daniel Vetter > > Suggested-by: Daniel Vetter > > Signed-off-by: Ville Syrjälä > > --- > > drivers/gpu/drm/nouveau/dispnv04/disp.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.c > > b/drivers/gpu/drm/nouveau/dispnv04/disp.c > > index 70dce544984e..670535a68d3b 100644 > > --- a/drivers/gpu/drm/nouveau/dispnv04/disp.c > > +++ b/drivers/gpu/drm/nouveau/dispnv04/disp.c > > @@ -56,7 +56,7 @@ nv04_display_create(struct drm_device *dev) > > nouveau_display(dev)->fini = nv04_display_fini; > > > > /* Pre-nv50 doesn't support atomic, so don't expose the ioctls */ > > - dev->driver->driver_features &= ~DRIVER_ATOMIC; > > + dev->driver_features &= ~DRIVER_ATOMIC; > > > > nouveau_hw_save_vga_fonts(dev, 1); > > -- Ville Syrjälä Intel ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v2] drm/nouveau: Fix nouveau_connector_ddc_detect()
On Thu, Aug 30, 2018 at 01:16:28PM -0400, Lyude Paul wrote:
> It looks like that when we moved over to using
> drm_connector_for_each_possible_encoder() in nouveau, that one rather
> important part of this function got dropped by accident:
>
> /* Right v here */
> for (i = 0; nv_encoder = NULL, i < DRM_CONNECTOR_MAX_ENCODER; i++) {
> int id = connector->encoder_ids[i];
> if (id == 0)
> break;
>
> Since it's rather difficult to notice: the conditional in this loop is
> actually:
>
> nv_encoder = NULL, i < DRM_CONNECTOR_MAX_ENCODER
>
> Meaning that all early breaks result in nv_encoder keeping it's value,
> otherwise nv_encoder = NULL. Ugh.
>
> Since this got dropped, nouveau_connector_ddc_detect() now returns an
> encoder for every single connector, regardless of whether or not it's
> detected:
>
> [ 1780.056185] nouveau :01:00.0: DRM: DDC responded, but no EDID for
> DP-2
>
> So: fix this to ensure we only return an encoder if we actually found
> one, and clean up the rest of the function while we're at it since it's
> nearly impossible to read properly.
>
> Changes since v1:
> - Don't skip ddc probing for LVDS if we can't switch DDC through
> vga-switcheroo, just do the DDC probing without calling
> vga_switcheroo_lock_ddc() - skeggsb
>
> Signed-off-by: Lyude Paul
> Cc: Ville Syrjälä
> Fixes: ddba766dd07e ("drm/nouveau: Use
> drm_connector_for_each_possible_encoder()")
> ---
> drivers/gpu/drm/nouveau/nouveau_connector.c | 49 -
> 1 file changed, 28 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
> b/drivers/gpu/drm/nouveau/nouveau_connector.c
> index 71c3bd8ff9f8..46aaedc4 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_connector.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
> @@ -414,9 +414,10 @@ nouveau_connector_ddc_detect(struct drm_connector
> *connector)
> struct nouveau_connector *nv_connector = nouveau_connector(connector);
> struct nouveau_drm *drm = nouveau_drm(dev);
> struct nvkm_gpio *gpio = nvxx_gpio(>client.device);
> - struct nouveau_encoder *nv_encoder = NULL;
> + struct nouveau_encoder *nv_encoder = NULL, *found = NULL;
> struct drm_encoder *encoder;
> - int i, panel = -ENODEV;
> + int i, ret, panel = -ENODEV;
> + bool switcheroo_ddc = false;
>
> /* eDP panels need powering on by us (if the VBIOS doesn't default it
>* to on) before doing any AUX channel transactions. LVDS panel power
> @@ -433,37 +434,43 @@ nouveau_connector_ddc_detect(struct drm_connector
> *connector)
> drm_connector_for_each_possible_encoder(connector, encoder, i) {
> nv_encoder = nouveau_encoder(encoder);
>
> - if (nv_encoder->dcb->type == DCB_OUTPUT_DP) {
> - int ret = nouveau_dp_detect(nv_encoder);
> + switch (nv_encoder->dcb->type) {
> + case DCB_OUTPUT_DP:
> + ret = nouveau_dp_detect(nv_encoder);
> if (ret == NOUVEAU_DP_MST)
> return NULL;
> - if (ret == NOUVEAU_DP_SST)
> - break;
> - } else
> - if ((vga_switcheroo_handler_flags() &
> - VGA_SWITCHEROO_CAN_SWITCH_DDC) &&
> - nv_encoder->dcb->type == DCB_OUTPUT_LVDS &&
> - nv_encoder->i2c) {
> - int ret;
> - vga_switcheroo_lock_ddc(dev->pdev);
> - ret = nvkm_probe_i2c(nv_encoder->i2c, 0x50);
> - vga_switcheroo_unlock_ddc(dev->pdev);
> - if (ret)
> + else if (ret == NOUVEAU_DP_SST)
> + found = nv_encoder;
> +
> + break;
> + case DCB_OUTPUT_LVDS:
> + switcheroo_ddc = !!(vga_switcheroo_handler_flags() &
> + VGA_SWITCHEROO_CAN_SWITCH_DDC);
> + /* fall-through */
> + default:
> + if (!nv_encoder->i2c)
> break;
> - } else
> - if (nv_encoder->i2c) {
> +
> + if (switcheroo_ddc)
> + vga_switcheroo_lock_ddc(dev->pdev);
> if (nvkm_probe_i2c(nv_encoder->i2c, 0x50))
> - break;
> + found = nv_encode
Re: [Nouveau] [PATCH v2 2/3] drm/nouveau: Fix runtime PM leak in nv50_disp_atomic_commit()
On Tue, Jul 17, 2018 at 09:33:52AM +0200, Lukas Wunner wrote:
> On Thu, Jul 12, 2018 at 01:02:53PM -0400, Lyude Paul wrote:
> > --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > @@ -1878,7 +1878,7 @@ nv50_disp_atomic_commit(struct drm_device *dev,
> > nv50_disp_atomic_commit_tail(state);
> >
> > drm_for_each_crtc(crtc, dev) {
> > - if (crtc->state->enable) {
> > + if (crtc->state->active) {
> > if (!drm->have_disp_power_ref) {
> > drm->have_disp_power_ref = true;
> > return 0;
>
> Somewhat tangential comment on this older patch, since you
> continue to dig around in the runtime PM area:
>
> Whenever a crtc is activated or deactivated in nouveau, we iterate
> over all crtcs and acquire a runtime PM if a crtc is active and
> previously there was no active one, or we drop a ref if none is
> active and previously there was an active one.
>
> For a while now I've been thinking that it would be more straightforward
> to acquire a ref whenever a crtc is activated and drop one when a crtc
> is deactivated, i.e. hold one ref for every active crtc. That way the
> have_disp_power_ref variable as well as the iteration logic could be
> removed, leading to a simplification. Just a suggestion anyway.
The current code looks somewhat busted anyway. First problem is that
it's accessing crtc->state without the appropriate locks held (unless
something always pulls in all crtcs to every commit?). Second issue
is that the rpm_put() is called without waiting for nonblocking commits
to have finished so it looks like you can currentlly remove the power
before the hardware has been properly shut down.
--
Ville Syrjälä
Intel
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v2 5/9] drm/nouveau: Use drm_connector_for_each_possible_encoder()
On Mon, Jul 02, 2018 at 04:04:45PM +0300, Ville Syrjälä wrote:
> On Sat, Jun 30, 2018 at 10:12:21PM +0300, Dan Carpenter wrote:
> > Hi Ville,
> >
> > Thank you for the patch! Perhaps something to improve:
> >
> > url:
> > https://github.com/0day-ci/linux/commits/Ville-Syrjala/drm-Third-attempt-at-fixing-the-fb-helper-best_encoder-mess/20180629-014202
> > base: git://people.freedesktop.org/~airlied/linux.git drm-next
> >
> > smatch warnings:
> > drivers/gpu/drm/nouveau/nouveau_connector.c:461
> > nouveau_connector_ddc_detect() error: uninitialized symbol 'nv_encoder'.
> >
> > #
> > https://github.com/0day-ci/linux/commit/7ec8bb65386edfb0b2bdc8e8391eb5e6eac44c06
> > git remote add linux-review https://github.com/0day-ci/linux
> > git remote update linux-review
> > git checkout 7ec8bb65386edfb0b2bdc8e8391eb5e6eac44c06
> > vim +/nv_encoder +461 drivers/gpu/drm/nouveau/nouveau_connector.c
> >
> > 6ee738610 Ben Skeggs 2009-12-11 407
> > 8777c5c11 Ben Skeggs 2014-06-06 408 static struct nouveau_encoder *
> > 8777c5c11 Ben Skeggs 2014-06-06 409
> > nouveau_connector_ddc_detect(struct drm_connector *connector)
> > 6ee738610 Ben Skeggs 2009-12-11 410 {
> > 6ee738610 Ben Skeggs 2009-12-11 411 struct drm_device *dev =
> > connector->dev;
> > 1a1841d30 Ben Skeggs 2012-12-10 412 struct nouveau_connector
> > *nv_connector = nouveau_connector(connector);
> > 77145f1cb Ben Skeggs 2012-07-31 413 struct nouveau_drm *drm =
> > nouveau_drm(dev);
> > 1167c6bc5 Ben Skeggs 2016-05-18 414 struct nvkm_gpio *gpio =
> > nvxx_gpio(>client.device);
> > 8777c5c11 Ben Skeggs 2014-06-06 415 struct nouveau_encoder
> > *nv_encoder;
> > 6d385c0aa Rob Clark 2014-07-17 416 struct drm_encoder *encoder;
> > 1a1841d30 Ben Skeggs 2012-12-10 417 int i, panel = -ENODEV;
> > 1a1841d30 Ben Skeggs 2012-12-10 418
> > 1a1841d30 Ben Skeggs 2012-12-10 419 /* eDP panels need powering on
> > by us (if the VBIOS doesn't default it
> > 1a1841d30 Ben Skeggs 2012-12-10 420* to on) before doing any AUX
> > channel transactions. LVDS panel power
> > 1a1841d30 Ben Skeggs 2012-12-10 421* is handled by the SOR
> > itself, and not required for LVDS DDC.
> > 1a1841d30 Ben Skeggs 2012-12-10 422*/
> > 1a1841d30 Ben Skeggs 2012-12-10 423 if (nv_connector->type ==
> > DCB_CONNECTOR_eDP) {
> > 2ea7249fe Ben Skeggs 2015-08-20 424 panel =
> > nvkm_gpio_get(gpio, 0, DCB_GPIO_PANEL_POWER, 0xff);
> > 1a1841d30 Ben Skeggs 2012-12-10 425 if (panel == 0) {
> > 2ea7249fe Ben Skeggs 2015-08-20 426
> > nvkm_gpio_set(gpio, 0, DCB_GPIO_PANEL_POWER, 0xff, 1);
> > 1a1841d30 Ben Skeggs 2012-12-10 427 msleep(300);
> > 1a1841d30 Ben Skeggs 2012-12-10 428 }
> > 1a1841d30 Ben Skeggs 2012-12-10 429 }
> > 6ee738610 Ben Skeggs 2009-12-11 430
> > 7ec8bb653 Ville Syrjälä 2018-06-28 431
> > drm_connector_for_each_possible_encoder(connector, encoder, i) {
> > 6d385c0aa Rob Clark 2014-07-17 432 nv_encoder =
> > nouveau_encoder(encoder);
> >
> > ^
> > If we enter the loop that means nv_encoder is non-NULL. Smatch can't
> > prove that we always enter the loop in this case for whatever reason but
> > my guess is that we always do.
> >
> > 4ca2b7120 Francisco Jerez 2010-08-08 433
> > 8777c5c11 Ben Skeggs 2014-06-06 434 if
> > (nv_encoder->dcb->type == DCB_OUTPUT_DP) {
> > 8777c5c11 Ben Skeggs 2014-06-06 435 int ret =
> > nouveau_dp_detect(nv_encoder);
> > 52aa30f25 Ben Skeggs 2016-11-04 436 if (ret ==
> > NOUVEAU_DP_MST)
> > 52aa30f25 Ben Skeggs 2016-11-04 437 return
> > NULL;
> > 52aa30f25 Ben Skeggs 2016-11-04 438 if (ret ==
> > NOUVEAU_DP_SST)
> > 8777c5c11 Ben Skeggs 2014-06-06 439 break;
> > 8777c5c11 Ben Skeggs 2014-06-06 440 } else
> > 39c1c9011 Lukas Wunner2016-01-11 441 if
> > ((vga_switcheroo_handler_flags() &
> > 39c1c9011 Lukas Wunner2016-01-11 442
> > VGA_SWITCHEROO_CAN_SWITCH_DDC) &&
> > 39c1c9011 Lukas Wunner2016-01-11 443
> > nv_encoder->
Re: [Nouveau] [PATCH v2 5/9] drm/nouveau: Use drm_connector_for_each_possible_encoder()
On Sat, Jun 30, 2018 at 10:12:21PM +0300, Dan Carpenter wrote:
> Hi Ville,
>
> Thank you for the patch! Perhaps something to improve:
>
> url:
> https://github.com/0day-ci/linux/commits/Ville-Syrjala/drm-Third-attempt-at-fixing-the-fb-helper-best_encoder-mess/20180629-014202
> base: git://people.freedesktop.org/~airlied/linux.git drm-next
>
> smatch warnings:
> drivers/gpu/drm/nouveau/nouveau_connector.c:461
> nouveau_connector_ddc_detect() error: uninitialized symbol 'nv_encoder'.
>
> #
> https://github.com/0day-ci/linux/commit/7ec8bb65386edfb0b2bdc8e8391eb5e6eac44c06
> git remote add linux-review https://github.com/0day-ci/linux
> git remote update linux-review
> git checkout 7ec8bb65386edfb0b2bdc8e8391eb5e6eac44c06
> vim +/nv_encoder +461 drivers/gpu/drm/nouveau/nouveau_connector.c
>
> 6ee738610 Ben Skeggs 2009-12-11 407
> 8777c5c11 Ben Skeggs 2014-06-06 408 static struct nouveau_encoder *
> 8777c5c11 Ben Skeggs 2014-06-06 409
> nouveau_connector_ddc_detect(struct drm_connector *connector)
> 6ee738610 Ben Skeggs 2009-12-11 410 {
> 6ee738610 Ben Skeggs 2009-12-11 411 struct drm_device *dev =
> connector->dev;
> 1a1841d30 Ben Skeggs 2012-12-10 412 struct nouveau_connector
> *nv_connector = nouveau_connector(connector);
> 77145f1cb Ben Skeggs 2012-07-31 413 struct nouveau_drm *drm =
> nouveau_drm(dev);
> 1167c6bc5 Ben Skeggs 2016-05-18 414 struct nvkm_gpio *gpio =
> nvxx_gpio(>client.device);
> 8777c5c11 Ben Skeggs 2014-06-06 415 struct nouveau_encoder
> *nv_encoder;
> 6d385c0aa Rob Clark 2014-07-17 416 struct drm_encoder *encoder;
> 1a1841d30 Ben Skeggs 2012-12-10 417 int i, panel = -ENODEV;
> 1a1841d30 Ben Skeggs 2012-12-10 418
> 1a1841d30 Ben Skeggs 2012-12-10 419 /* eDP panels need powering on
> by us (if the VBIOS doesn't default it
> 1a1841d30 Ben Skeggs 2012-12-10 420 * to on) before doing any AUX
> channel transactions. LVDS panel power
> 1a1841d30 Ben Skeggs 2012-12-10 421 * is handled by the SOR
> itself, and not required for LVDS DDC.
> 1a1841d30 Ben Skeggs 2012-12-10 422 */
> 1a1841d30 Ben Skeggs 2012-12-10 423 if (nv_connector->type ==
> DCB_CONNECTOR_eDP) {
> 2ea7249fe Ben Skeggs 2015-08-20 424 panel =
> nvkm_gpio_get(gpio, 0, DCB_GPIO_PANEL_POWER, 0xff);
> 1a1841d30 Ben Skeggs 2012-12-10 425 if (panel == 0) {
> 2ea7249fe Ben Skeggs 2015-08-20 426
> nvkm_gpio_set(gpio, 0, DCB_GPIO_PANEL_POWER, 0xff, 1);
> 1a1841d30 Ben Skeggs 2012-12-10 427 msleep(300);
> 1a1841d30 Ben Skeggs 2012-12-10 428 }
> 1a1841d30 Ben Skeggs 2012-12-10 429 }
> 6ee738610 Ben Skeggs 2009-12-11 430
> 7ec8bb653 Ville Syrjälä 2018-06-28 431
> drm_connector_for_each_possible_encoder(connector, encoder, i) {
> 6d385c0aa Rob Clark 2014-07-17 432 nv_encoder =
> nouveau_encoder(encoder);
>
> ^
> If we enter the loop that means nv_encoder is non-NULL. Smatch can't
> prove that we always enter the loop in this case for whatever reason but
> my guess is that we always do.
>
> 4ca2b7120 Francisco Jerez 2010-08-08 433
> 8777c5c11 Ben Skeggs 2014-06-06 434 if
> (nv_encoder->dcb->type == DCB_OUTPUT_DP) {
> 8777c5c11 Ben Skeggs 2014-06-06 435 int ret =
> nouveau_dp_detect(nv_encoder);
> 52aa30f25 Ben Skeggs 2016-11-04 436 if (ret ==
> NOUVEAU_DP_MST)
> 52aa30f25 Ben Skeggs 2016-11-04 437 return
> NULL;
> 52aa30f25 Ben Skeggs 2016-11-04 438 if (ret ==
> NOUVEAU_DP_SST)
> 8777c5c11 Ben Skeggs 2014-06-06 439 break;
> 8777c5c11 Ben Skeggs 2014-06-06 440 } else
> 39c1c9011 Lukas Wunner2016-01-11 441 if
> ((vga_switcheroo_handler_flags() &
> 39c1c9011 Lukas Wunner2016-01-11 442
> VGA_SWITCHEROO_CAN_SWITCH_DDC) &&
> 39c1c9011 Lukas Wunner2016-01-11 443
> nv_encoder->dcb->type == DCB_OUTPUT_LVDS &&
> 39c1c9011 Lukas Wunner2016-01-11 444 nv_encoder->i2c) {
> 39c1c9011 Lukas Wunner2016-01-11 445 int ret;
> 39c1c9011 Lukas Wunner2016-01-11 446
> vga_switcheroo_lock_ddc(dev->pdev);
> 39c1c9011 Lukas Wunner2016-01-11 447 ret =
> nvkm_probe_i2c(nv_enco
Re: [Nouveau] [PATCH v2 0/9] drm: Third attempt at fixing the fb-helper .best_encoder() mess
On Thu, Jun 28, 2018 at 04:13:06PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > Changes from the previous version mainly involve Danoie's suggestion Can't type today either: "Daniel's" > of hiding the drm_encoder_find() in the iterator macro. I also polished > the msm and tilcdc cases a bit more with another small helper. > > Cc: Alex Deucher > Cc: amd-...@lists.freedesktop.org > Cc: Ben Skeggs > Cc: "Christian König" > Cc: Daniel Vetter > Cc: "David (ChunMing) Zhou" > Cc: Dhinakaran Pandiyan > Cc: freedr...@lists.freedesktop.org > Cc: Harry Wentland > Cc: Jyri Sarha > Cc: linux-arm-...@vger.kernel.org > Cc: nouveau@lists.freedesktop.org > Cc: Rob Clark > Cc: Tomi Valkeinen > > Ville Syrjälä (9): > drm/fb-helper: Eliminate the .best_encoder() usage > drm/i915: Nuke intel_mst_best_encoder() > drm: Add drm_connector_for_each_possible_encoder() > drm/amdgpu: Use drm_connector_for_each_possible_encoder() > drm/nouveau: Use drm_connector_for_each_possible_encoder() > drm/radeon: Use drm_connector_for_each_possible_encoder() > drm: Add drm_connector_has_possible_encoder() > drm/msm: Use drm_connector_has_possible_encoder() > drm/tilcdc: Use drm_connector_has_possible_encoder() > > drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 81 ++- > drivers/gpu/drm/amd/amdgpu/dce_virtual.c | 15 ++--- > drivers/gpu/drm/drm_connector.c| 44 + > drivers/gpu/drm/drm_fb_helper.c| 34 +- > drivers/gpu/drm/drm_probe_helper.c | 10 +-- > drivers/gpu/drm/i915/intel_dp_mst.c| 10 --- > drivers/gpu/drm/msm/dsi/dsi_manager.c | 8 +-- > drivers/gpu/drm/nouveau/nouveau_connector.c| 21 +- > drivers/gpu/drm/radeon/radeon_connectors.c | 90 > -- > drivers/gpu/drm/tilcdc/tilcdc_external.c | 9 ++- > include/drm/drm_connector.h| 16 + > 11 files changed, 128 insertions(+), 210 deletions(-) > > -- > 2.16.4 -- Ville Syrjälä Intel ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v2 2/4] drm/vc4: Take underscan setup into account when updating planes
On Fri, May 11, 2018 at 09:47:49PM +0200, Boris Brezillon wrote:
> On Fri, 11 May 2018 20:29:48 +0300
> Ville Syrjälä <ville.syrj...@linux.intel.com> wrote:
>
> > On Fri, May 11, 2018 at 07:12:21PM +0200, Boris Brezillon wrote:
> > > On Fri, 11 May 2018 19:54:02 +0300
> > > Ville Syrjälä <ville.syrj...@linux.intel.com> wrote:
> > >
> > > > On Fri, May 11, 2018 at 05:52:56PM +0200, Boris Brezillon wrote:
> > > > > On Fri, 11 May 2018 18:34:50 +0300
> > > > > Ville Syrjälä <ville.syrj...@linux.intel.com> wrote:
> > > > >
> > > > > > On Fri, May 11, 2018 at 04:59:17PM +0200, Boris Brezillon wrote:
> > > > > > > Applying an underscan setup is just a matter of scaling all planes
> > > > > > > appropriately and adjusting the CRTC X/Y offset to account for the
> > > > > > > horizontal and vertical border.
> > > > > > >
> > > > > > > Create an vc4_plane_underscan_adj() function doing that and call
> > > > > > > it from
> > > > > > > vc4_plane_setup_clipping_and_scaling() so that we are ready to
> > > > > > > attach
> > > > > > > underscan properties to the HDMI connector.
> > > > > > >
> > > > > > > Signed-off-by: Boris Brezillon <boris.brezil...@bootlin.com>
> > > > > > > ---
> > > > > > > Changes in v2:
> > > > > > > - Take changes on hborder/vborder meaning into account
> > > > > > > ---
> > > > > > > drivers/gpu/drm/vc4/vc4_plane.c | 49
> > > > > > > -
> > > > > > > 1 file changed, 48 insertions(+), 1 deletion(-)
> > > > > > >
> > > > > > > diff --git a/drivers/gpu/drm/vc4/vc4_plane.c
> > > > > > > b/drivers/gpu/drm/vc4/vc4_plane.c
> > > > > > > index 71d44c357d35..61ed60841cd6 100644
> > > > > > > --- a/drivers/gpu/drm/vc4/vc4_plane.c
> > > > > > > +++ b/drivers/gpu/drm/vc4/vc4_plane.c
> > > > > > > @@ -258,6 +258,49 @@ static u32 vc4_get_scl_field(struct
> > > > > > > drm_plane_state *state, int plane)
> > > > > > > }
> > > > > > > }
> > > > > > >
> > > > > > > +static int vc4_plane_underscan_adj(struct drm_plane_state
> > > > > > > *pstate)
> > > > > > > +{
> > > > > > > + struct vc4_plane_state *vc4_pstate = to_vc4_plane_state(pstate);
> > > > > > > + struct drm_connector_state *conn_state = NULL;
> > > > > > > + struct drm_connector *conn;
> > > > > > > + struct drm_crtc_state *crtc_state;
> > > > > > > + int i;
> > > > > > > +
> > > > > > > + for_each_new_connector_in_state(pstate->state, conn,
> > > > > > > conn_state, i) {
> > > > > > > + if (conn_state->crtc == pstate->crtc)
> > > > > > > + break;
> > > > > > > + }
> > > > > > > +
> > > > > > > + if (i == pstate->state->num_connector)
> > > > > > > + return 0;
> > > > > > > +
> > > > > > > + if (conn_state->underscan.mode != DRM_UNDERSCAN_ON)
> > > > > > > + return 0;
> > > > > > > +
> > > > > > > + crtc_state = drm_atomic_get_new_crtc_state(pstate->state,
> > > > > > > +pstate->crtc);
> > > > > > > +
> > > > > > > + if (conn_state->underscan.hborder >= crtc_state->mode.hdisplay
> > > > > > > ||
> > > > > > > + conn_state->underscan.vborder >= crtc_state->mode.vdisplay)
> > > > > > > + return -EINVAL;
> > > > > >
> > > > > > border * 2 ?
> > > > >
> > > > > Oops, indeed. I'll fix that.
> > > > >
> > > > > >
> > > > > > > +
> > > > > > > + vc4_pstate->crtc_x += conn_state->underscan.hborder;
> > > > > > > + vc4_pstate->crtc_y += con
Re: [Nouveau] [PATCH v2 2/4] drm/vc4: Take underscan setup into account when updating planes
On Fri, May 11, 2018 at 07:12:21PM +0200, Boris Brezillon wrote:
> On Fri, 11 May 2018 19:54:02 +0300
> Ville Syrjälä <ville.syrj...@linux.intel.com> wrote:
>
> > On Fri, May 11, 2018 at 05:52:56PM +0200, Boris Brezillon wrote:
> > > On Fri, 11 May 2018 18:34:50 +0300
> > > Ville Syrjälä <ville.syrj...@linux.intel.com> wrote:
> > >
> > > > On Fri, May 11, 2018 at 04:59:17PM +0200, Boris Brezillon wrote:
> > > > > Applying an underscan setup is just a matter of scaling all planes
> > > > > appropriately and adjusting the CRTC X/Y offset to account for the
> > > > > horizontal and vertical border.
> > > > >
> > > > > Create an vc4_plane_underscan_adj() function doing that and call it
> > > > > from
> > > > > vc4_plane_setup_clipping_and_scaling() so that we are ready to attach
> > > > > underscan properties to the HDMI connector.
> > > > >
> > > > > Signed-off-by: Boris Brezillon <boris.brezil...@bootlin.com>
> > > > > ---
> > > > > Changes in v2:
> > > > > - Take changes on hborder/vborder meaning into account
> > > > > ---
> > > > > drivers/gpu/drm/vc4/vc4_plane.c | 49
> > > > > -
> > > > > 1 file changed, 48 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/vc4/vc4_plane.c
> > > > > b/drivers/gpu/drm/vc4/vc4_plane.c
> > > > > index 71d44c357d35..61ed60841cd6 100644
> > > > > --- a/drivers/gpu/drm/vc4/vc4_plane.c
> > > > > +++ b/drivers/gpu/drm/vc4/vc4_plane.c
> > > > > @@ -258,6 +258,49 @@ static u32 vc4_get_scl_field(struct
> > > > > drm_plane_state *state, int plane)
> > > > > }
> > > > > }
> > > > >
> > > > > +static int vc4_plane_underscan_adj(struct drm_plane_state *pstate)
> > > > > +{
> > > > > + struct vc4_plane_state *vc4_pstate = to_vc4_plane_state(pstate);
> > > > > + struct drm_connector_state *conn_state = NULL;
> > > > > + struct drm_connector *conn;
> > > > > + struct drm_crtc_state *crtc_state;
> > > > > + int i;
> > > > > +
> > > > > + for_each_new_connector_in_state(pstate->state, conn,
> > > > > conn_state, i) {
> > > > > + if (conn_state->crtc == pstate->crtc)
> > > > > + break;
> > > > > + }
> > > > > +
> > > > > + if (i == pstate->state->num_connector)
> > > > > + return 0;
> > > > > +
> > > > > + if (conn_state->underscan.mode != DRM_UNDERSCAN_ON)
> > > > > + return 0;
> > > > > +
> > > > > + crtc_state = drm_atomic_get_new_crtc_state(pstate->state,
> > > > > +pstate->crtc);
> > > > > +
> > > > > + if (conn_state->underscan.hborder >= crtc_state->mode.hdisplay
> > > > > ||
> > > > > + conn_state->underscan.vborder >= crtc_state->mode.vdisplay)
> > > > > + return -EINVAL;
> > > >
> > > > border * 2 ?
> > >
> > > Oops, indeed. I'll fix that.
> > >
> > > >
> > > > > +
> > > > > + vc4_pstate->crtc_x += conn_state->underscan.hborder;
> > > > > + vc4_pstate->crtc_y += conn_state->underscan.vborder;
> > > > > + vc4_pstate->crtc_w = (vc4_pstate->crtc_w *
> > > > > + (crtc_state->mode.hdisplay -
> > > > > +(conn_state->underscan.hborder * 2))) /
> > > > > + crtc_state->mode.hdisplay;
> > > > > + vc4_pstate->crtc_h = (vc4_pstate->crtc_h *
> > > > > + (crtc_state->mode.vdisplay -
> > > > > +(conn_state->underscan.vborder * 2))) /
> > > > > + crtc_state->mode.vdisplay;
> > > >
> > > > So you're now scaling all planes? The code seems to reject scaling for
> > > > the cursor plane, how are you dealing with that? Or just
Re: [Nouveau] [PATCH v2 2/4] drm/vc4: Take underscan setup into account when updating planes
On Fri, May 11, 2018 at 05:52:56PM +0200, Boris Brezillon wrote:
> On Fri, 11 May 2018 18:34:50 +0300
> Ville Syrjälä <ville.syrj...@linux.intel.com> wrote:
>
> > On Fri, May 11, 2018 at 04:59:17PM +0200, Boris Brezillon wrote:
> > > Applying an underscan setup is just a matter of scaling all planes
> > > appropriately and adjusting the CRTC X/Y offset to account for the
> > > horizontal and vertical border.
> > >
> > > Create an vc4_plane_underscan_adj() function doing that and call it from
> > > vc4_plane_setup_clipping_and_scaling() so that we are ready to attach
> > > underscan properties to the HDMI connector.
> > >
> > > Signed-off-by: Boris Brezillon <boris.brezil...@bootlin.com>
> > > ---
> > > Changes in v2:
> > > - Take changes on hborder/vborder meaning into account
> > > ---
> > > drivers/gpu/drm/vc4/vc4_plane.c | 49
> > > -
> > > 1 file changed, 48 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/vc4/vc4_plane.c
> > > b/drivers/gpu/drm/vc4/vc4_plane.c
> > > index 71d44c357d35..61ed60841cd6 100644
> > > --- a/drivers/gpu/drm/vc4/vc4_plane.c
> > > +++ b/drivers/gpu/drm/vc4/vc4_plane.c
> > > @@ -258,6 +258,49 @@ static u32 vc4_get_scl_field(struct drm_plane_state
> > > *state, int plane)
> > > }
> > > }
> > >
> > > +static int vc4_plane_underscan_adj(struct drm_plane_state *pstate)
> > > +{
> > > + struct vc4_plane_state *vc4_pstate = to_vc4_plane_state(pstate);
> > > + struct drm_connector_state *conn_state = NULL;
> > > + struct drm_connector *conn;
> > > + struct drm_crtc_state *crtc_state;
> > > + int i;
> > > +
> > > + for_each_new_connector_in_state(pstate->state, conn, conn_state, i) {
> > > + if (conn_state->crtc == pstate->crtc)
> > > + break;
> > > + }
> > > +
> > > + if (i == pstate->state->num_connector)
> > > + return 0;
> > > +
> > > + if (conn_state->underscan.mode != DRM_UNDERSCAN_ON)
> > > + return 0;
> > > +
> > > + crtc_state = drm_atomic_get_new_crtc_state(pstate->state,
> > > +pstate->crtc);
> > > +
> > > + if (conn_state->underscan.hborder >= crtc_state->mode.hdisplay ||
> > > + conn_state->underscan.vborder >= crtc_state->mode.vdisplay)
> > > + return -EINVAL;
> >
> > border * 2 ?
>
> Oops, indeed. I'll fix that.
>
> >
> > > +
> > > + vc4_pstate->crtc_x += conn_state->underscan.hborder;
> > > + vc4_pstate->crtc_y += conn_state->underscan.vborder;
> > > + vc4_pstate->crtc_w = (vc4_pstate->crtc_w *
> > > + (crtc_state->mode.hdisplay -
> > > +(conn_state->underscan.hborder * 2))) /
> > > + crtc_state->mode.hdisplay;
> > > + vc4_pstate->crtc_h = (vc4_pstate->crtc_h *
> > > + (crtc_state->mode.vdisplay -
> > > +(conn_state->underscan.vborder * 2))) /
> > > + crtc_state->mode.vdisplay;
> >
> > So you're now scaling all planes? The code seems to reject scaling for
> > the cursor plane, how are you dealing with that? Or just no cursor
> > allowed when underscanning?
>
> No, I just didn't test with a cursor plane. We should probably avoid
> scaling the cursor plane and just adjust its position. Eric any opinion
> on that?
I don't think you can just not scale it. The user asked for the cursor
to be at a specific place with a specific size. Can't just ignore
that and do something else. Also eg. i915 would definitely scale the
cursor since we'd just scale the entire crtc instead of scaling
individual planes. Different drivers doing different things wouldn't
be good.
>
> >
> > I'm also wondering if there's any way we can reconcile these border
> > props with the scaling mode prop, should we ever wish to expose
> > these props on connectors that already have the scaling mode prop.
>
> Nouveau seems to expose both, and I don't see why we couldn't.
First of all the interaction of these borders with panels that have
a fixed mode would need to be properly specified. Do we apply the
borders against the user mode or the panel's native mode? I guess
the latter would be a bit easier (would also match how
Re: [Nouveau] [PATCH v2 2/4] drm/vc4: Take underscan setup into account when updating planes
On Fri, May 11, 2018 at 04:59:17PM +0200, Boris Brezillon wrote:
> Applying an underscan setup is just a matter of scaling all planes
> appropriately and adjusting the CRTC X/Y offset to account for the
> horizontal and vertical border.
>
> Create an vc4_plane_underscan_adj() function doing that and call it from
> vc4_plane_setup_clipping_and_scaling() so that we are ready to attach
> underscan properties to the HDMI connector.
>
> Signed-off-by: Boris Brezillon <boris.brezil...@bootlin.com>
> ---
> Changes in v2:
> - Take changes on hborder/vborder meaning into account
> ---
> drivers/gpu/drm/vc4/vc4_plane.c | 49
> -
> 1 file changed, 48 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
> index 71d44c357d35..61ed60841cd6 100644
> --- a/drivers/gpu/drm/vc4/vc4_plane.c
> +++ b/drivers/gpu/drm/vc4/vc4_plane.c
> @@ -258,6 +258,49 @@ static u32 vc4_get_scl_field(struct drm_plane_state
> *state, int plane)
> }
> }
>
> +static int vc4_plane_underscan_adj(struct drm_plane_state *pstate)
> +{
> + struct vc4_plane_state *vc4_pstate = to_vc4_plane_state(pstate);
> + struct drm_connector_state *conn_state = NULL;
> + struct drm_connector *conn;
> + struct drm_crtc_state *crtc_state;
> + int i;
> +
> + for_each_new_connector_in_state(pstate->state, conn, conn_state, i) {
> + if (conn_state->crtc == pstate->crtc)
> + break;
> + }
> +
> + if (i == pstate->state->num_connector)
> + return 0;
> +
> + if (conn_state->underscan.mode != DRM_UNDERSCAN_ON)
> + return 0;
> +
> + crtc_state = drm_atomic_get_new_crtc_state(pstate->state,
> +pstate->crtc);
> +
> + if (conn_state->underscan.hborder >= crtc_state->mode.hdisplay ||
> + conn_state->underscan.vborder >= crtc_state->mode.vdisplay)
> + return -EINVAL;
border * 2 ?
> +
> + vc4_pstate->crtc_x += conn_state->underscan.hborder;
> + vc4_pstate->crtc_y += conn_state->underscan.vborder;
> + vc4_pstate->crtc_w = (vc4_pstate->crtc_w *
> + (crtc_state->mode.hdisplay -
> +(conn_state->underscan.hborder * 2))) /
> + crtc_state->mode.hdisplay;
> + vc4_pstate->crtc_h = (vc4_pstate->crtc_h *
> + (crtc_state->mode.vdisplay -
> +(conn_state->underscan.vborder * 2))) /
> + crtc_state->mode.vdisplay;
So you're now scaling all planes? The code seems to reject scaling for
the cursor plane, how are you dealing with that? Or just no cursor
allowed when underscanning?
I'm also wondering if there's any way we can reconcile these border
props with the scaling mode prop, should we ever wish to expose
these props on connectors that already have the scaling mode prop.
Maybe we just have to require the scaling mode to be set to fullscreen
to allow borders to be specified explictly?
> +
> + if (!vc4_pstate->crtc_w || !vc4_pstate->crtc_h)
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> static int vc4_plane_setup_clipping_and_scaling(struct drm_plane_state
> *state)
> {
> struct drm_plane *plane = state->plane;
> @@ -269,7 +312,7 @@ static int vc4_plane_setup_clipping_and_scaling(struct
> drm_plane_state *state)
> int num_planes = fb->format->num_planes;
> u32 h_subsample = 1;
> u32 v_subsample = 1;
> - int i;
> + int i, ret;
>
> for (i = 0; i < num_planes; i++)
> vc4_state->offsets[i] = bo->paddr + fb->offsets[i];
> @@ -292,6 +335,10 @@ static int vc4_plane_setup_clipping_and_scaling(struct
> drm_plane_state *state)
> vc4_state->crtc_w = state->crtc_w;
> vc4_state->crtc_h = state->crtc_h;
>
> + ret = vc4_plane_underscan_adj(state);
> + if (ret)
> + return ret;
> +
> vc4_state->x_scaling[0] = vc4_get_scaling_mode(vc4_state->src_w[0],
> vc4_state->crtc_w);
> vc4_state->y_scaling[0] = vc4_get_scaling_mode(vc4_state->src_h[0],
> --
> 2.14.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 1/3] drm/connector: Add generic underscan properties
+ * @DRM_UNDERSCAN_ON: Underscan is enabled, and horizontal/vertical border
> size
> + * are specified through the _drm_underscan->hborder
> + * and _drm_underscan->vborder fields.
> + * @DRM_UNDERSCAN_AUTO: Underscan is enabled and
> _drm_underscan->hborder
> + * and _drm_underscan->vborder are guessed by the
> + * driver.
> + */
> +enum drm_underscan_mode {
> + DRM_UNDERSCAN_OFF,
> + DRM_UNDERSCAN_ON,
> + DRM_UNDERSCAN_AUTO,
> +};
> +
> +/**
> + * struct drm_underscan - Underscan properties attached to a connector state
> + *
> + * This can be used to tell the CRTC how the image should be scaled/placed in
> + * order to cover fit in the display connected through this connector. Most
> of
> + * the time used to address situations where the display borders are hidden.
> + * Can also be used to compensate overscan done on the display side.
> + */
> +struct drm_underscan {
> + /**
> + * @mode: Underscan mode.
> + */
> + enum drm_underscan_mode mode;
> +
> + /**
> + * @hborder: Horizontal border. This values encodes both the left and
> + * right borders: left_border = right_border = hborder / 2.
> + */
> + unsigned int hborder;
> +
> + /**
> + * @vborder: Vertical border. This values encodes both the top and
> + * bottom borders: top_border = bottom_border = vborder / 2.
> + */
> + unsigned int vborder;
> +};
> +
> /**
> * struct drm_connector_state - mutable connector state
> * @connector: backpointer to the connector
> @@ -429,6 +475,12 @@ struct drm_connector_state {
>* protection. This is most commonly used for HDCP.
>*/
> unsigned int content_protection;
> +
> + /**
> + * @underscan: Underscan information. Most commonly used to adjust
> + * image when the display is doing overscan.
> + */
> + struct drm_underscan underscan;
> };
>
> /**
> @@ -892,6 +944,29 @@ struct drm_connector {
>*/
> struct drm_property_blob *tile_blob_ptr;
>
> + /**
> + * @underscan_mode_property: Optional connector underscan mode. Used by
> + * the driver to scale the output image and compensate an overscan done
> + * on the display side.
> + */
> + struct drm_property *underscan_mode_property;
> +
> + /**
> + * @underscan_hborder_property: Optional connector underscan horizontal
> + * border (expressed in pixels). Used by the driver to adjust the
> + * output image position and compensate an overscan done on the display
> + * side.
> + */
> + struct drm_property *underscan_hborder_property;
> +
> + /**
> + * @underscan_hborder_property: Optional connector underscan vertical
> + * border (expressed in pixels). Used by the driver to adjust the
> + * output image position and compensate an overscan done on the display
> + * side.
> + */
> + struct drm_property *underscan_vborder_property;
> +
> /* should we poll this connector for connects and disconnects */
> /* hot plug detectable */
> #define DRM_CONNECTOR_POLL_HPD (1 << 0)
> @@ -1088,6 +1163,9 @@ int drm_mode_create_dvi_i_properties(struct drm_device
> *dev);
> int drm_mode_create_tv_properties(struct drm_device *dev,
> unsigned int num_modes,
> const char * const modes[]);
> +int drm_connector_attach_underscan_properties(struct drm_connector
> *connector,
> + u32 mode_mask, u64 max_hborder,
> + u64 max_vborder);
> int drm_mode_create_scaling_mode_property(struct drm_device *dev);
> int drm_connector_attach_scaling_mode_property(struct drm_connector
> *connector,
> u32 scaling_mode_mask);
> --
> 2.14.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] drm: Don't pass the index to drm_property_add_enum()
On Thu, Apr 26, 2018 at 12:45:13PM +, Lisovskiy, Stanislav wrote:
> Reviewed-by: Stanislav Lisovskiy <stanislav.lisovs...@intel.com>
Thanks. Pushed to drm-misc-next.
>
> Best Regards,
>
> Lisovskiy Stanislav
>
> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
>
>
> From: Intel-gfx [intel-gfx-boun...@lists.freedesktop.org] on behalf of
> Lisovskiy, Stanislav [stanislav.lisovs...@intel.com]
> Sent: Monday, April 23, 2018 4:59 PM
> To: Ville Syrjala; dri-de...@lists.freedesktop.org
> Cc: nouveau@lists.freedesktop.org; intel-...@lists.freedesktop.org; Ben Skeggs
> Subject: Re: [Intel-gfx] [PATCH] drm: Don't pass the index to
> drm_property_add_enum()
>
> Acked-by: Stanislav Lisovskiy <stanislav.lisovs...@intel.com>
>
> Best Regards,
>
> Lisovskiy Stanislav
>
> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo>
>
>
> From: Ville Syrjala [ville.syrj...@linux.intel.com]
> Sent: Friday, March 16, 2018 9:04 PM
> To: dri-de...@lists.freedesktop.org
> Cc: intel-...@lists.freedesktop.org; Patrik Jakobsson; Ben Skeggs;
> nouveau@lists.freedesktop.org
> Subject: [PATCH] drm: Don't pass the index to drm_property_add_enum()
>
> From: Ville Syrjälä <ville.syrj...@linux.intel.com>
>
> drm_property_add_enum() can calculate the index itself just fine,
> so no point in having the caller pass it in.
>
> Cc: Patrik Jakobsson <patrik.r.jakobs...@gmail.com>
> Cc: Ben Skeggs <bske...@redhat.com>
> Cc: nouveau@lists.freedesktop.org
> Signed-off-by: Ville Syrjälä <ville.syrj...@linux.intel.com>
> ---
> drivers/gpu/drm/drm_connector.c | 6 +++---
> drivers/gpu/drm/drm_property.c| 27 +--
> drivers/gpu/drm/gma500/cdv_device.c | 4 ++--
> drivers/gpu/drm/gma500/psb_intel_sdvo.c | 2 +-
> drivers/gpu/drm/i915/intel_sdvo.c | 5 ++---
> drivers/gpu/drm/nouveau/nouveau_display.c | 4 +---
> include/drm/drm_property.h| 2 +-
> 7 files changed, 23 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index b3cde897cd80..dfc8ca1e9413 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1069,7 +1069,7 @@ int drm_mode_create_tv_properties(struct drm_device
> *dev,
> goto nomem;
>
> for (i = 0; i < num_modes; i++)
> - drm_property_add_enum(dev->mode_config.tv_mode_property, i,
> + drm_property_add_enum(dev->mode_config.tv_mode_property,
> i, modes[i]);
>
> dev->mode_config.tv_brightness_property =
> @@ -1156,7 +1156,7 @@ int drm_connector_attach_scaling_mode_property(struct
> drm_connector *connector,
> {
> struct drm_device *dev = connector->dev;
> struct drm_property *scaling_mode_property;
> - int i, j = 0;
> + int i;
> const unsigned valid_scaling_mode_mask =
> (1U << ARRAY_SIZE(drm_scaling_mode_enum_list)) - 1;
>
> @@ -1177,7 +1177,7 @@ int drm_connector_attach_scaling_mode_property(struct
> drm_connector *connector,
> if (!(BIT(i) & scaling_mode_mask))
> continue;
>
> - ret = drm_property_add_enum(scaling_mode_property, j++,
> + ret = drm_property_add_enum(scaling_mode_property,
>
> drm_scaling_mode_enum_list[i].type,
>
> drm_scaling_mode_enum_list[i].name);
>
> diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c
> index 8f4672daac7f..1f8031e30f53 100644
> --- a/drivers/gpu/drm/drm_property.c
> +++ b/drivers/gpu/drm/drm_property.c
> @@ -169,9 +169,9 @@ struct drm_property *drm_property_create_enum(struct
> drm_device *dev,
> return NULL;
>
> for (i = 0; i < num_values; i++) {
> - ret = drm_property_add_enum(property, i,
> - props[i].type,
> - props[i].name);
> + ret = drm_property_add_enum(property,
> + props[i].type,
> + props[i].name);
> if (ret) {
> drm_property_destroy(dev, property);
> return NULL;
> @@ -209,7 +209,7 @@ struct drm_property *drm_property_create_bitmask(struct
>
Re: [Nouveau] [PATCH] drm/nouveau: Replace the iturbt_709 prop with the standarad COLOR_ENCODNIG prop
On Tue, Feb 27, 2018 at 10:49:39AM +0200, Ville Syrjälä wrote: > On Tue, Feb 27, 2018 at 12:54:47AM -0500, Ilia Mirkin wrote: > > On Tue, Feb 20, 2018 at 9:25 AM, Ilia Mirkin <imir...@alum.mit.edu> wrote: > > > On Tue, Feb 20, 2018 at 8:48 AM, Ville Syrjala > > > <ville.syrj...@linux.intel.com> wrote: > > >> From: Ville Syrjälä <ville.syrj...@linux.intel.com> > > >> > > >> Replace the ad-hoc iturbt_709 property with the new standard > > >> COLOR_ENCODING property. Compiles, but not tested. > > >> > > >> Cc: Daniel Vetter <dan...@ffwll.ch> > > >> Cc: nouveau@lists.freedesktop.org > > >> Cc: Ben Skeggs <bske...@redhat.com> > > >> Cc: Ilia Mirkin <imir...@alum.mit.edu> > > >> Signed-off-by: Ville Syrjälä <ville.syrj...@linux.intel.com> > > > > > > s/standarad/standard/ in subject > > > > > > I'd like the opportunity to test this out on real hardware, but I > > > don't have any pre-NV41 boards plugged in right now. I should be able > > > to attend to it within 7 days. If you don't hear back from me by then, > > > I'd appreciate a ping, as I do let things (hopefully occasionally) > > > slip through. > > > > Tested this out on a NV34. Seems to work - at least the green SMPTE > > bar looks different in the two different modes (had to hack modetest > > to use the SMPTE pattern on planes). > > > > I do wonder about the new color range property... that's more of a > > connector thing than a plane thing no? Presumably over S-Video it's a > > partial range, and over VGA it's full? I'd flip it to always full here > > tbh. (Or just not provide it at all.) > > No, this property is just about the range of the input data. Full range > YCbCr isn't exaclty common so you'd rarely need this. JPEG uses full > range I believe. > > > > > Anyways, with the subject typo(s! noticed ENCODNIG -> ENCODING just > > now) fixed, this is > > > > Reviewed-by: Ilia Mirkin <imir...@alum.mit.edu> > > Cool. Thanks. Pushed to drm-misc-next with Ben's ack. 17:27 friendly reminder about https://patchwork.freedesktop.org/patch/205620/ -- ville was wondering whether you'd take it, or if he should push via drm-misc. 17:27 ack, i'd say ville should take it in drm-misc for now -- Ville Syrjälä Intel OTC ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] drm/nouveau: Replace the iturbt_709 prop with the standarad COLOR_ENCODNIG prop
On Tue, Feb 27, 2018 at 12:54:47AM -0500, Ilia Mirkin wrote: > On Tue, Feb 20, 2018 at 9:25 AM, Ilia Mirkin <imir...@alum.mit.edu> wrote: > > On Tue, Feb 20, 2018 at 8:48 AM, Ville Syrjala > > <ville.syrj...@linux.intel.com> wrote: > >> From: Ville Syrjälä <ville.syrj...@linux.intel.com> > >> > >> Replace the ad-hoc iturbt_709 property with the new standard > >> COLOR_ENCODING property. Compiles, but not tested. > >> > >> Cc: Daniel Vetter <dan...@ffwll.ch> > >> Cc: nouveau@lists.freedesktop.org > >> Cc: Ben Skeggs <bske...@redhat.com> > >> Cc: Ilia Mirkin <imir...@alum.mit.edu> > >> Signed-off-by: Ville Syrjälä <ville.syrj...@linux.intel.com> > > > > s/standarad/standard/ in subject > > > > I'd like the opportunity to test this out on real hardware, but I > > don't have any pre-NV41 boards plugged in right now. I should be able > > to attend to it within 7 days. If you don't hear back from me by then, > > I'd appreciate a ping, as I do let things (hopefully occasionally) > > slip through. > > Tested this out on a NV34. Seems to work - at least the green SMPTE > bar looks different in the two different modes (had to hack modetest > to use the SMPTE pattern on planes). > > I do wonder about the new color range property... that's more of a > connector thing than a plane thing no? Presumably over S-Video it's a > partial range, and over VGA it's full? I'd flip it to always full here > tbh. (Or just not provide it at all.) No, this property is just about the range of the input data. Full range YCbCr isn't exaclty common so you'd rarely need this. JPEG uses full range I believe. > > Anyways, with the subject typo(s! noticed ENCODNIG -> ENCODING just > now) fixed, this is > > Reviewed-by: Ilia Mirkin <imir...@alum.mit.edu> Cool. Thanks. -- Ville Syrjälä Intel OTC ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] nouveau 30bpp / deep color status
On Thu, Feb 08, 2018 at 07:34:11PM -0500, Ilia Mirkin wrote: > On Wed, Feb 7, 2018 at 12:01 PM, Ville Syrjälä > <ville.syrj...@linux.intel.com> wrote: > > On Wed, Feb 07, 2018 at 06:28:42PM +0200, Ville Syrjälä wrote: > >> On Sun, Feb 04, 2018 at 06:50:45PM -0500, Ilia Mirkin wrote: > >> > In case anyone's curious about 30bpp framebuffer support, here's the > >> > current status: > >> > > >> > Kernel: > >> > > >> > Ben and I have switched the code to using a 256-based LUT for Kepler+, > >> > and I've also written a patch to cause the addfb ioctl to use the > >> > proper format. You can pick this up at: > >> > > >> > https://github.com/skeggsb/linux/commits/linux-4.16 (note the branch!) > >> > https://patchwork.freedesktop.org/patch/202322/ > >> > > >> > With these two, you should be able to use "X -depth 30" again on any > >> > G80+ GPU to bring up a screen (as you could in kernel 4.9 and > >> > earlier). However this still has some deficiencies, some of which I've > >> > addressed: > >> > > >> > xf86-video-nouveau: > >> > > >> > DRI3 was broken, and Xv was broken. Patches available at: > >> > > >> > https://github.com/imirkin/xf86-video-nouveau/commits/master > >> > > >> > mesa: > >> > > >> > The NVIDIA hardware (pre-Kepler) can only do XBGR scanout. Further the > >> > nouveau KMS doesn't add XRGB scanout for Kepler+ (although it could). > >> > Mesa was only enabled for XRGB, so I've piped XBGR through all the > >> > same places: > >> > > >> > https://github.com/imirkin/mesa/commits/30bpp > >> > > >> > libdrm: > >> > > >> > For testing, I added a modetest gradient pattern split horizontally. > >> > Top half is 10bpc, bottom half is 8bpc. This is useful for seeing > >> > whether you're really getting 10bpc, or if things are getting > >> > truncated along the way. Definitely hacky, but ... wasn't intending on > >> > upstreaming it anyways: > >> > > >> > https://github.com/imirkin/drm/commit/9b8776f58448b5745675c3a7f5eb2735e3989441 > >> > > >> > - > >> > > >> > Results with the patches (tested on a GK208B and a "deep color" TV over > >> > HDMI): > >> > - modetest with a 10bpc gradient shows up smoother than an 8bpc > >> > gradient. However it's still dithered to 8bpc, not "real" 10bpc. > >> > - things generally work in X -- dri2 and dri3, xv, and obviously > >> > regular X rendering / acceleration > >> > - lots of X software can't handle 30bpp modes (mplayer hates it for > >> > xv and x11 rendering, aterm bails on shading the root pixmap, probably > >> > others) > >> > > >> > I'm also told that with DP, it should actually send the higher-bpc > >> > data over the wire. With HDMI, we're still stuck at 24bpp for now > >> > (although the hardware can do 36bpp as well). This is why my gradient > >> > result above was still dithered. > >> > > >> > Things to do - mostly nouveau specific, but probably some general > >> > infra needed too: > >> > - Figure out how to properly expose the 1024-sized LUT > >> > >> We have the properties in the kernel. Not sure if x11 could expose it > >> to clients somehow, or would we just have to interpolate the missing > >> bits in the ddx? > > > > Oh, and I think we're going to have to come up with a fancier uapi for > > this stuff because in the future the input points may not be evenly > > spaced (for HDR stuff). Also the hardware may provide various different > > modes for the gamma LUTs with different tradeoffs. So we may even want > > to somehow try to enumerate the different modes and let userspace pick > > the mode that best suits its needs. > > That's already the case -- NVIDIA actually has like 5 different LUT > modes on recent chips. > > https://github.com/envytools/envytools/blob/master/rnndb/display/nv_evo.xml#L25 > > > > > > Yeah, we also have several LUT modes on intel hw. IIRC ~4 on current hw. The main questions are whether all of them are actually useful for userspace, and how we can expose the relevant details to userspace in a succinct and hw independent way. -- Ville Syrjälä Intel OTC ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] nouveau 30bpp / deep color status
On Wed, Feb 07, 2018 at 06:28:42PM +0200, Ville Syrjälä wrote: > On Sun, Feb 04, 2018 at 06:50:45PM -0500, Ilia Mirkin wrote: > > In case anyone's curious about 30bpp framebuffer support, here's the > > current status: > > > > Kernel: > > > > Ben and I have switched the code to using a 256-based LUT for Kepler+, > > and I've also written a patch to cause the addfb ioctl to use the > > proper format. You can pick this up at: > > > > https://github.com/skeggsb/linux/commits/linux-4.16 (note the branch!) > > https://patchwork.freedesktop.org/patch/202322/ > > > > With these two, you should be able to use "X -depth 30" again on any > > G80+ GPU to bring up a screen (as you could in kernel 4.9 and > > earlier). However this still has some deficiencies, some of which I've > > addressed: > > > > xf86-video-nouveau: > > > > DRI3 was broken, and Xv was broken. Patches available at: > > > > https://github.com/imirkin/xf86-video-nouveau/commits/master > > > > mesa: > > > > The NVIDIA hardware (pre-Kepler) can only do XBGR scanout. Further the > > nouveau KMS doesn't add XRGB scanout for Kepler+ (although it could). > > Mesa was only enabled for XRGB, so I've piped XBGR through all the > > same places: > > > > https://github.com/imirkin/mesa/commits/30bpp > > > > libdrm: > > > > For testing, I added a modetest gradient pattern split horizontally. > > Top half is 10bpc, bottom half is 8bpc. This is useful for seeing > > whether you're really getting 10bpc, or if things are getting > > truncated along the way. Definitely hacky, but ... wasn't intending on > > upstreaming it anyways: > > > > https://github.com/imirkin/drm/commit/9b8776f58448b5745675c3a7f5eb2735e3989441 > > > > - > > > > Results with the patches (tested on a GK208B and a "deep color" TV over > > HDMI): > > - modetest with a 10bpc gradient shows up smoother than an 8bpc > > gradient. However it's still dithered to 8bpc, not "real" 10bpc. > > - things generally work in X -- dri2 and dri3, xv, and obviously > > regular X rendering / acceleration > > - lots of X software can't handle 30bpp modes (mplayer hates it for > > xv and x11 rendering, aterm bails on shading the root pixmap, probably > > others) > > > > I'm also told that with DP, it should actually send the higher-bpc > > data over the wire. With HDMI, we're still stuck at 24bpp for now > > (although the hardware can do 36bpp as well). This is why my gradient > > result above was still dithered. > > > > Things to do - mostly nouveau specific, but probably some general > > infra needed too: > > - Figure out how to properly expose the 1024-sized LUT > > We have the properties in the kernel. Not sure if x11 could expose it > to clients somehow, or would we just have to interpolate the missing > bits in the ddx? Oh, and I think we're going to have to come up with a fancier uapi for this stuff because in the future the input points may not be evenly spaced (for HDR stuff). Also the hardware may provide various different modes for the gamma LUTs with different tradeoffs. So we may even want to somehow try to enumerate the different modes and let userspace pick the mode that best suits its needs. -- Ville Syrjälä Intel OTC ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] nouveau 30bpp / deep color status
't necessarily plan on working further on this, so if there are > interested parties, they should definitely try to pick it up. I'll try > to upstream all my changes though. > > Cheers, > > -ilia > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Ville Syrjälä Intel OTC ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 00/15] drm: More plane clipping polish
On Thu, Nov 23, 2017 at 09:04:47PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä <ville.syrj...@linux.intel.com> > > This series first unifies all users of drm_atomic_helper_check_plane_state() > to populate the clip rectangle with drm_mode_get_hv_timing(), and once > everything is unified the clip rectangle handling is sucked into > drm_atomic_helper_check_plane_state() away from driver code. > > Entire series available here: > git://github.com/vsyrjala/linux.git atomic_plane_helper_clip > > Cc: Archit Taneja <arch...@codeaurora.org> > Cc: Ben Skeggs <bske...@redhat.com> > Cc: Brian Starkey <brian.star...@arm.com> > Cc: CK Hu <ck...@mediatek.com> > Cc: Daniel Vetter <dan...@ffwll.ch> > Cc: freedr...@lists.freedesktop.org > Cc: Laurent Pinchart <laurent.pinch...@ideasonboard.com> > Cc: linux-amlo...@lists.infradead.org > Cc: linux-arm-...@vger.kernel.org > Cc: linux-te...@vger.kernel.org > Cc: Liviu Dudau <liviu.du...@arm.com> > Cc: Mali DP Maintainers <mal...@foss.arm.com> > Cc: Mark Yao <mark@rock-chips.com> > Cc: Neil Armstrong <narmstr...@baylibre.com> > Cc: Noralf Trønnes <nor...@tronnes.org> > Cc: nouveau@lists.freedesktop.org > Cc: Philipp Zabel <p.za...@pengutronix.de> > Cc: Rob Clark <robdcl...@gmail.com> > Cc: Shawn Guo <shawn...@kernel.org> > Cc: Sinclair Yeh <s...@vmware.com> > Cc: Thierry Reding <thierry.red...@gmail.com> > Cc: Thomas Hellstrom <thellst...@vmware.com> > Cc: VMware Graphics <linux-graphics-maintai...@vmware.com> > > Ville Syrjälä (15): > drm/i915: Reject odd pipe source width with double wide/dual link > drm/i915: Use drm_mode_get_hv_timing() to populate plane clip > rectangle > drm/arm/hdlcd: Use drm_mode_get_hv_timing() to populate plane clip > rectangle > drm/arm/mali-dp: Use drm_mode_get_hv_timing() to populate plane clip > rectangle > drm/simple_kms_helper: Use drm_mode_get_hv_timing() to populate plane > clip rectangle > drm/imx: Use drm_mode_get_hv_timing() to populate plane clip rectangle > drm/mediatek: Use drm_mode_get_hv_timing() to populate plane clip > rectangle > drm/meson: Use drm_mode_get_hv_timing() to populate plane clip > rectangle > drm/msm/mdp5: Use drm_mode_get_hv_timing() to populate plane clip > rectangle > drm/nouveau/kms/nv50: Use drm_mode_get_hv_timing() to populate plane > clip rectangle > drm/rockchip: Use drm_mode_get_hv_timing() to populate plane clip > rectangle > drm/tegra/dc: Use drm_mode_get_hv_timing() to populate plane clip > rectangle > drm/vmwgfx: Use drm_mode_get_hv_timing() to populate plane clip > rectangle > drm/zte: Use drm_mode_get_hv_timing() to populate plane clip rectangle Everything up to here pushed to drm-misc-next. Thanks for the reviews. There have been a few new users of the clip helper so I'll have to take care of those and respin the final patch. Also armada looks broken to me since it has started to use the atomic version of the helper without actually being an atomic driver. So I'll have to figure out what's going on there as well. > drm: Don't pass clip to drm_atomic_helper_check_plane_state() > > drivers/gpu/drm/arm/hdlcd_crtc.c| 6 +- > drivers/gpu/drm/arm/malidp_planes.c | 5 + > drivers/gpu/drm/armada/armada_overlay.c | 2 +- > drivers/gpu/drm/drm_atomic_helper.c | 12 +++- > drivers/gpu/drm/drm_plane_helper.c | 11 +++ > drivers/gpu/drm/drm_simple_kms_helper.c | 5 - > drivers/gpu/drm/i915/intel_atomic_plane.c | 8 > drivers/gpu/drm/i915/intel_display.c| 12 +++- > drivers/gpu/drm/i915/intel_drv.h| 1 - > drivers/gpu/drm/i915/intel_sprite.c | 8 ++-- > drivers/gpu/drm/imx/ipuv3-plane.c | 7 +-- > drivers/gpu/drm/mediatek/mtk_drm_plane.c| 6 +- > drivers/gpu/drm/meson/meson_plane.c | 6 +- > drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 14 ++ > drivers/gpu/drm/nouveau/nv50_display.c | 8 > drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 8 +--- > drivers/gpu/drm/tegra/dc.c | 8 +--- > drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 8 +--- > drivers/gpu/drm/zte/zx_plane.c | 15 +-- > include/drm/drm_atomic_helper.h | 1 - > include/drm/drm_plane_helper.h | 1 - > 21 files changed, 35 insertions(+), 117 deletions(-) > > -- > 2.13.6 -- Ville Syrjälä Intel OTC ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v3] drm: Add DRM_MODE_ROTATE_ and DRM_MODE_REFLECT_ to UAPI
On Wed, May 17, 2017 at 09:39:11PM -0400, Robert Foss wrote:
> +/*
> + * DRM_MODE_REFLECT_
> + *
> + * Signals that the contents of a drm plane has been reflected in
> + * the axis.
Still vague.
Also you didn't respond to my comment about the use of past tense.
> + *
> + * This define is provided as a convenience, looking up the property id
> + * using the name->prop id lookup is the preferred method.
> + */
> +#define DRM_MODE_REFLECT_X (1<<4)
> +#define DRM_MODE_REFLECT_Y (1<<5)
> +
> +/*
> + * DRM_MODE_REFLECT_MASK
> + *
> + * Bitmask used to look for drm plane reflections.
> + */
> +#define DRM_MODE_REFLECT_MASK (\
> + DRM_MODE_REFLECT_X | \
> + DRM_MODE_REFLECT_Y)
> +
> +
> struct drm_mode_modeinfo {
> __u32 clock;
> __u16 hdisplay;
> --
> 2.11.0.453.g787f75f05
--
Ville Syrjälä
Intel OTC
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v4 2/2] drm: Add DRM_MODE_ROTATE_ and DRM_MODE_REFLECT_ to UAPI
drm_object_attach_property(obj, priv->zorder_prop, 0); > @@ -273,7 +273,7 @@ static void omap_plane_reset(struct drm_plane *plane) >*/ > omap_state->zorder = plane->type == DRM_PLANE_TYPE_PRIMARY > ? 0 : omap_plane->id; > - omap_state->base.rotation = DRM_ROTATE_0; > + omap_state->base.rotation = DRM_MODE_ROTATE_0; > > plane->state = _state->base; > plane->state->plane = plane; > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c > b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
Re: [Nouveau] [PATCH v2 00/10] Enable HDMI Stereoscopy
On Wed, Mar 29, 2017 at 10:24:05AM -0400, Alastair Bridgewater wrote: > On Wed, Mar 29, 2017 at 8:02 AM, Ville Syrjälä < > ville.syrj...@linux.intel.com> wrote: > > > > On Mon, Mar 27, 2017 at 05:57:57PM -0400, Alastair Bridgewater wrote: > > > And the tenth patch enables stereo mode support... on HDMI and DPort > > > connectors on nv50+ hardware. HDMI connectors because obvious. DPort > > > connectors because of DPort to HDMI adaptors. > > > > Do you mean DP++ or actual protocol converters? DP++ is just HDMI with > > a some electrical tweaks, but IIRC proper DP defines 3D stereo quite > > differently than HDMI. I'm not sure if we should be able to push HDMI > > style 3D through DP->HDMI/DP++ adaptors. The specs are unfortunately > > very vague when it comes to such devices. > > DP++. Good point about the protocol converters, though I don't recall > seeing any way to distinguish between a DP and a DP++ connector in > nouveau, nor do I know if nVidia actually made any boards with DP that > isn't DP++. I guess I have some digging to do in that direction. Thank > you. In i915 we register both a HDMI and a DP connector for the same physical DP connector, and a sink attached via a DP++ dongle/cable will appear on the HDMI connector instead of the DP connector. But I don't know if nouveau follows this same pattern or not. -- Ville Syrjälä Intel OTC ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v2 00/10] Enable HDMI Stereoscopy
On Mon, Mar 27, 2017 at 05:57:57PM -0400, Alastair Bridgewater wrote: > HDMI 3D mode support, round two. Revisions include no longer dealing > with audio InfoFrames, passing infoframe data to NVKM as bags of bytes > rather than as data pre-packed for the hardware, more-normal return > value checking for drm_hdmi_*_infoframe_from_display_mode() results, > Frame-Packing mode support, more-principled logic for enabling stereo > mode support on a connector, and support for all four nv50+ DISPs. > Additionally, this patch set is being sent to the dri-devel list as > well as the nouveau list. Dropped in this version is the removal of > the "mandatory" 3D mode logic. After discussion, I'm still convinced > that it's wrong, but now I'm convinced that it's too conservative > rather than my original belief which was that it was too liberal. > > Thanks to Ilia Mirkin, Damien Lespiau, and Ben Skeggs for feedback on > the original patch set. If I have neglected to mention anyone, mea > culpa. > > The first patch perhaps isn't technically necessary, but simplifies > the later logic for fixing frame-packing mode timing. There may be > some effect from applying this, as drm_mode_set_crtcinfo() does > something with vscan which can affect the given CRTC timing. I'm > not sure what's going on there, if there's any behavioral change or > not, and if there is what to do about it (other than using > drm_mode_set_crtcinfo() twice, once with CRTC_NO_VSCAN and once > without). > > The second through eighth patches are all the InfoFrame logic again, > this time with support for all four DISP types. This does not appear > to cause regressions in HDMI audio on GT215, GF119, or GK104. I hope > that it doesn't cause a regression on G84, but haven't yet managed to > set up a test case for G84 and HDMI audio. > > The ninth patch is to fix up frame-packing mode timings and geometry. > As the patch comment says, there are clearly-correct parts, and there > are possibly-hacky parts. But it gets frame-packing modes working, > and we can revise from there if necessary. > > And the tenth patch enables stereo mode support... on HDMI and DPort > connectors on nv50+ hardware. HDMI connectors because obvious. DPort > connectors because of DPort to HDMI adaptors. Do you mean DP++ or actual protocol converters? DP++ is just HDMI with a some electrical tweaks, but IIRC proper DP defines 3D stereo quite differently than HDMI. I'm not sure if we should be able to push HDMI style 3D through DP->HDMI/DP++ adaptors. The specs are unfortunately very vague when it comes to such devices. > eDP connectors because > it shouldn't do any harm, and someone might have been maniac enough to > set up an eDP port to point to something with an HDMI 3D setup. And > nv50+ hardware only because while I'm not aware of any pre-nv50 cards > that have HDMI outputs, there could be a setup out there like the PS3 > that uses an external HDMI encoder on pre-nv50 hardware, at which > point none of the mode timing or InfoFrame support is in place for it. > > Alastair Bridgewater (10): > drm/nouveau: Use drm_mode_set_crtcinfo() to compensate for vscan / > ilace > drm/nouveau: Extend NVKM HDMI power control method to set InfoFrames > drm/nouveau: Pass mode-dependent AVI and Vendor HDMI InfoFrames to > NVKM > drm/nouveau: Add mechanism to convert HDMI InfoFrames to hardware > format > drm/nouveau: Use supplied HDMI InfoFrames on G84 hardware > drm/nouveau: Use supplied HDMI InfoFrames on GT215 hardware > drm/nouveau: Use supplied HDMI InfoFrames on GF119 hardware > drm/nouveau: Use supplied HDMI InfoFrames on GK104 hardware > drm/nouveau: Handle frame-packing mode geometry and timing effects > drm/nouveau: Enable stereoscopic 3D output over HDMI > > drivers/gpu/drm/nouveau/include/nvif/cl5070.h | 4 +- > drivers/gpu/drm/nouveau/nouveau_connector.c| 10 +++ > drivers/gpu/drm/nouveau/nv50_display.c | 80 > -- > drivers/gpu/drm/nouveau/nvkm/engine/disp/Kbuild| 1 + > .../drm/nouveau/nvkm/engine/disp/hdmi_infoframe.c | 66 ++ > drivers/gpu/drm/nouveau/nvkm/engine/disp/hdmig84.c | 46 +++-- > .../gpu/drm/nouveau/nvkm/engine/disp/hdmigf119.c | 49 +++-- > .../gpu/drm/nouveau/nvkm/engine/disp/hdmigk104.c | 45 ++-- > .../gpu/drm/nouveau/nvkm/engine/disp/hdmigt215.c | 46 +++-- > drivers/gpu/drm/nouveau/nvkm/engine/disp/nv50.h| 11 +++ > 10 files changed, 307 insertions(+), 51 deletions(-) > create mode 100644 drivers/gpu/drm/nouveau/nvkm/engine/disp/hdmi_infoframe.c > > -- > 2.10.2 > > ___ > dri-devel mailing list > dri-de
Re: [Nouveau] [PATCH v4 1/3] drm/atomic: Save flip flags in drm_crtct_state
On Wed, Feb 01, 2017 at 12:03:34PM -0500, Andrey Grodzovsky wrote:
> Allows using atomic flip helpers for drivers
> using ASYNC flip.
> Remove ASYNC_FLIP restriction in helpers and
> caches the page flip flags in drm_crtc_state
> to be used in the low level drivers.
>
> v2:
> Resending the patch since the original was broken.
>
> v3:
> Save flag in crtc_state instead of plane_state
>
> v4:
> Reset the flag before using again.
>
> Change-Id: I0219c3ec3ecceb82143ee176d30cb50d9aa76bf0
> Signed-off-by: Andrey Grodzovsky <andrey.grodzov...@amd.com>
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 20 ++--
> include/drm/drm_crtc.h | 9 -
> include/drm/drm_plane.h | 1 +
> 3 files changed, 15 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index a4e5477..f84b5aa 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -2737,7 +2737,8 @@ static int page_flip_common(
> struct drm_atomic_state *state,
> struct drm_crtc *crtc,
> struct drm_framebuffer *fb,
> - struct drm_pending_vblank_event *event)
> + struct drm_pending_vblank_event *event,
> + uint32_t flags)
> {
> struct drm_plane *plane = crtc->primary;
> struct drm_plane_state *plane_state;
> @@ -2749,12 +2750,12 @@ static int page_flip_common(
> return PTR_ERR(crtc_state);
>
> crtc_state->event = event;
> + crtc_state->pflip_flags = flags;
Still wondering why we can't afford to spell out "page_flip" completely?
>
> plane_state = drm_atomic_get_plane_state(state, plane);
> if (IS_ERR(plane_state))
> return PTR_ERR(plane_state);
>
> -
> ret = drm_atomic_set_crtc_for_plane(plane_state, crtc);
> if (ret != 0)
> return ret;
--
Ville Syrjälä
Intel OTC
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 1/4] drm/atomic: Save flip flags in drm_plane_state
On Mon, Jan 16, 2017 at 10:44:55AM -0500, Andrey Grodzovsky wrote:
> Allows using atomic flip helpers for drivers
> using ASYNC flip.
> Remove ASYNC_FLIP restriction in helpers and
> caches the page flip flags in drm_plane_state
> to be used in the low level drivers.
>
> Signed-off-by: Andrey Grodzovsky <andrey.grodzov...@amd.com>
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 10 +++---
> include/drm/drm_plane.h | 8
> 2 files changed, 11 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index a4e5477..f83dc43 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -2737,7 +2737,8 @@ static int page_flip_common(
> struct drm_atomic_state *state,
> struct drm_crtc *crtc,
> struct drm_framebuffer *fb,
> - struct drm_pending_vblank_event *event)
> + struct drm_pending_vblank_event *event,
> + uint32_t flags)
> {
> struct drm_plane *plane = crtc->primary;
> struct drm_plane_state *plane_state;
> @@ -2754,6 +2755,7 @@ static int page_flip_common(
> if (IS_ERR(plane_state))
> return PTR_ERR(plane_state);
>
> + plane_state->pflip_flags = flags;
"pflip" looks off. Better just spell it out.
These flags need to be reset in duplicate_state otherwise they leak into
subsequent operations. This is why I don't really like the concept of
"state" containing flags and stuff that are not really part of the
state but rather part of the operation of moving from the old state to
the new state. But maybe we don't have a better place for this sort of
stuff? I have suggested at some point that we might rename drm_atomic_state
to drm_atomic_transaction or something. Stuffing the flags (or just a bool
perhaps?) in there might be less confusing.
>
> ret = drm_atomic_set_crtc_for_plane(plane_state, crtc);
> if (ret != 0)
> @@ -2800,9 +2802,6 @@ int drm_atomic_helper_page_flip(struct drm_crtc *crtc,
> struct drm_atomic_state *state;
> int ret = 0;
>
> - if (flags & DRM_MODE_PAGE_FLIP_ASYNC)
> - return -EINVAL;
> -
> state = drm_atomic_state_alloc(plane->dev);
> if (!state)
> return -ENOMEM;
> @@ -2865,9 +2864,6 @@ int drm_atomic_helper_page_flip_target(
> struct drm_crtc_state *crtc_state;
> int ret = 0;
>
> - if (flags & DRM_MODE_PAGE_FLIP_ASYNC)
> - return -EINVAL;
> -
> state = drm_atomic_state_alloc(plane->dev);
> if (!state)
> return -ENOMEM;
> diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
> index db3bbde..86d8ffc 100644
> --- a/include/drm/drm_plane.h
> +++ b/include/drm/drm_plane.h
> @@ -122,6 +122,14 @@ struct drm_plane_state {
>*/
> bool visible;
>
> +
> + /**
> + * @pflip_flags:
> + *
> + * Flip related config options
> + */
> + u32 pflip_flags;
> +
> struct drm_atomic_state *state;
> };
>
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel OTC
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [Intel-gfx] [PATCH 10/37] drm: add per-crtc locks
props, but if they don't end up changing anything in the modeset state, I can continue with the non-blocking operation. But you can argue that userspace is being silly if it sends such things, and we can just refuse it early on. -- Ville Syrjälä Intel OTC ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [Intel-gfx] [PATCH 10/37] drm: add per-crtc locks
On Thu, Dec 13, 2012 at 12:54:44PM +0100, Daniel Vetter wrote: On Thu, Dec 13, 2012 at 12:38 PM, Ville Syrjälä ville.syrj...@linux.intel.com wrote: And if we _really_ want such semantics, we can always get them by introducing another pageflip mutex between the mode_config.mutex and the individual crtc locks. Pageflips crossing more than one crtc would then need to take that lock first, to lock out concurrent multi-crtc pageflips. I'm actually concerned with multi CRTC page flips, not for moving planes between CRTCs, but mainly for updating content on genlocked displays atomically. We need to avoid deadlocks between multiple CRTC locks. Trying to take the CRTC locks in the same order would be a solution, but since user space can send the props in any order, it's going to require extra of work. Ordering CRTC locks should also work - modeset_lock_all takes them always in the same order, and as long as you only take a single crtc nested within the modeset lock that's still ok (e.g. the load-detect code). We don't have many CRTCs, so even the dumbest sort will be fast enough. A bit of work will be required to make lockdep happy. But we can achieve this by nesting CRTCs within a fake lock encapsulated by the lock/unlock helper functions. Yeah it would mean pre-processing the object ID list in the atomic ioctl. Currently there is at most num_crtc+num_plane object IDs in the list, assuming userspace didn't send any duplicates. For each of those we'd need to take the CRTC lock. So a bit of a change to my code, but not too bad I suppose. But this also has to handle planes that can move between CRTCs, so it's not quite as simple as that. Maybe grab the lock for plane-crtc, and once you have the lock re-check that plane-crtc didn't change before we got the lock. We also need to change things so that plane-crtc can never be NULL. Currently when a plane is disabled, we set plane-crtc to NULL, but since we need that information for taking the lock, and to prevent two guys from accessing the same disabled plane, we can no longer allow that. -- Ville Syrjälä Intel OTC ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
