From: Jani Nikula <jani.nikula@linux.intel.com>
To: Yaroslav Bolyukin <iam@lach.pw>,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org
Cc: David Airlie <airlied@linux.ie>, Yaroslav Bolyukin <iam@lach.pw>,
Thomas Zimmermann <tzimmermann@suse.de>
Subject: Re: [PATCH] drm/edid: Support type 7 timings
Date: Wed, 19 Jan 2022 11:35:06 +0200 [thread overview]
Message-ID: <874k60cblh.fsf@intel.com> (raw)
In-Reply-To: <20220118215956.17229-1-iam@lach.pw>
On Wed, 19 Jan 2022, Yaroslav Bolyukin <iam@lach.pw> wrote:
> Per VESA DisplayID Standard v2.0: Type VII Timing – Detailed Timing Data
>
> Definitions were already provided as type I, but not used
Thanks for the patch. Functionally I think it looks correct, and
something we'll want. I do have some nitpicks though, comments inline.
For the next version, please consider Cc'ing the intel-gfx list as well
to get our CI results on it too.
BR,
Jani.
>
> Signed-off-by: Yaroslav Bolyukin <iam@lach.pw>
> ---
> drivers/gpu/drm/drm_edid.c | 26 +++++++++++++++++---------
> include/drm/drm_displayid.h | 6 +++---
> 2 files changed, 20 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 12893e7be..5fcefd9b5 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -5404,13 +5404,17 @@ u32 drm_add_display_info(struct drm_connector *connector, const struct edid *edi
> return quirks;
> }
>
> -static struct drm_display_mode *drm_mode_displayid_detailed(struct drm_device *dev,
> - struct displayid_detailed_timings_1 *timings)
> +static struct drm_display_mode *drm_mode_displayid_detailed_1_7(struct drm_device *dev,
> + struct displayid_detailed_timings_1_7 *timings,
> + bool type_7)
I think the function rename here is unnecessary.
> {
> struct drm_display_mode *mode;
> unsigned pixel_clock = (timings->pixel_clock[0] |
> (timings->pixel_clock[1] << 8) |
> (timings->pixel_clock[2] << 16)) + 1;
> + // type 7 allows higher precision pixel clock
Please don't use // style comments.
For the comment contents, I think you should just state the units for
each; 10 kHz for type I, kHz for type VII.
> + if (!type_7)
> + pixel_clock *= 10;
Please don't mix declarations and code.
> unsigned hactive = (timings->hactive[0] | timings->hactive[1] << 8) + 1;
> unsigned hblank = (timings->hblank[0] | timings->hblank[1] << 8) + 1;
> unsigned hsync = (timings->hsync[0] | (timings->hsync[1] & 0x7f) << 8) + 1;
> @@ -5426,7 +5430,7 @@ static struct drm_display_mode *drm_mode_displayid_detailed(struct drm_device *d
> if (!mode)
> return NULL;
>
> - mode->clock = pixel_clock * 10;
> + mode->clock = pixel_clock;
Since we used to have the multiplication here (and we don't mix
declarations and code anyway) I'd keep it here.
Maybe:
mode->clock = type_7 ? pixel_clock : pixel_clock * 10;
> mode->hdisplay = hactive;
> mode->hsync_start = mode->hdisplay + hsync;
> mode->hsync_end = mode->hsync_start + hsync_width;
> @@ -5449,10 +5453,12 @@ static struct drm_display_mode *drm_mode_displayid_detailed(struct drm_device *d
> return mode;
> }
>
> -static int add_displayid_detailed_1_modes(struct drm_connector *connector,
> - const struct displayid_block *block)
> +static int add_displayid_detailed_1_7_modes(struct drm_connector *connector,
> + const struct displayid_block *block,
> + bool type_7)
> {
> - struct displayid_detailed_timing_block *det = (struct displayid_detailed_timing_block *)block;
> + struct displayid_detailed_timing_1_7_block *det =
> + (struct displayid_detailed_timing_1_7_block *)block;
I think the displayid_detailed_timing_block ->
displayid_detailed_timing_1_7_block rename is unnecessary.
> int i;
> int num_timings;
> struct drm_display_mode *newmode;
> @@ -5463,9 +5469,9 @@ static int add_displayid_detailed_1_modes(struct drm_connector *connector,
>
> num_timings = block->num_bytes / 20;
> for (i = 0; i < num_timings; i++) {
> - struct displayid_detailed_timings_1 *timings = &det->timings[i];
> + struct displayid_detailed_timings_1_7 *timings = &det->timings[i];
>
> - newmode = drm_mode_displayid_detailed(connector->dev, timings);
> + newmode = drm_mode_displayid_detailed_1_7(connector->dev, timings, type_7);
> if (!newmode)
> continue;
>
> @@ -5485,7 +5491,9 @@ static int add_displayid_detailed_modes(struct drm_connector *connector,
> displayid_iter_edid_begin(edid, &iter);
> displayid_iter_for_each(block, &iter) {
> if (block->tag == DATA_BLOCK_TYPE_1_DETAILED_TIMING)
> - num_modes += add_displayid_detailed_1_modes(connector, block);
> + num_modes += add_displayid_detailed_1_7_modes(connector, block, false);
> + else if (block->tag == DATA_BLOCK_2_TYPE_7_DETAILED_TIMING)
> + num_modes += add_displayid_detailed_1_7_modes(connector, block, true);
I'd probably not add a true/false parameter here, since we pass in block
anyway, and the function can have and initialize the bool local variable
internally based on block->tag.
> }
> displayid_iter_end(&iter);
>
> diff --git a/include/drm/drm_displayid.h b/include/drm/drm_displayid.h
> index 7ffbd9f7b..268ff5e1f 100644
> --- a/include/drm/drm_displayid.h
> +++ b/include/drm/drm_displayid.h
> @@ -111,7 +111,7 @@ struct displayid_tiled_block {
> u8 topology_id[8];
> } __packed;
>
> -struct displayid_detailed_timings_1 {
> +struct displayid_detailed_timings_1_7 {
> u8 pixel_clock[3];
> u8 flags;
> u8 hactive[2];
> @@ -124,9 +124,9 @@ struct displayid_detailed_timings_1 {
> u8 vsw[2];
> } __packed;
>
> -struct displayid_detailed_timing_block {
> +struct displayid_detailed_timing_1_7_block {
Like I said, I wouldn't rename this.
> struct displayid_block base;
> - struct displayid_detailed_timings_1 timings[];
> + struct displayid_detailed_timings_1_7 timings[];
> };
>
> #define DISPLAYID_VESA_MSO_OVERLAP GENMASK(3, 0)
>
> base-commit: 99613159ad749543621da8238acf1a122880144e
--
Jani Nikula, Intel Open Source Graphics Center
next prev parent reply other threads:[~2022-01-19 9:35 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-18 21:59 [PATCH] drm/edid: Support type 7 timings Yaroslav Bolyukin
2022-01-19 9:35 ` Jani Nikula [this message]
2022-01-23 19:19 ` [Intel-gfx] [PATCH v2] " Yaroslav Bolyukin
2022-01-23 19:19 ` Yaroslav Bolyukin
2022-01-25 7:02 ` [Intel-gfx] " Jani Nikula
2022-01-25 7:02 ` Jani Nikula
2022-01-25 12:35 ` [Intel-gfx] " Jani Nikula
2022-01-25 12:35 ` Jani Nikula
2022-01-24 21:06 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
2022-01-24 21:38 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-01-25 3:01 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874k60cblh.fsf@intel.com \
--to=jani.nikula@linux.intel.com \
--cc=airlied@linux.ie \
--cc=dri-devel@lists.freedesktop.org \
--cc=iam@lach.pw \
--cc=linux-kernel@vger.kernel.org \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.