From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DB48FC433F5 for ; Thu, 4 Nov 2021 15:41:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C0B23610FD for ; Thu, 4 Nov 2021 15:41:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231189AbhKDPoC (ORCPT ); Thu, 4 Nov 2021 11:44:02 -0400 Received: from mga11.intel.com ([192.55.52.93]:45277 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229770AbhKDPoB (ORCPT ); Thu, 4 Nov 2021 11:44:01 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10157"; a="229189340" X-IronPort-AV: E=Sophos;i="5.87,209,1631602800"; d="scan'208";a="229189340" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Nov 2021 08:41:23 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.87,209,1631602800"; d="scan'208";a="450250513" Received: from stinkbox.fi.intel.com (HELO stinkbox) ([10.237.72.171]) by orsmga006.jf.intel.com with SMTP; 04 Nov 2021 08:41:14 -0700 Received: by stinkbox (sSMTP sendmail emulation); Thu, 04 Nov 2021 17:41:13 +0200 Date: Thu, 4 Nov 2021 17:41:13 +0200 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Maxime Ripard Cc: Emma Anholt , Neil Armstrong , David Airlie , dri-devel@lists.freedesktop.org, Andrzej Hajda , Thierry Reding , amd-gfx@lists.freedesktop.org, Benjamin Gaignard , Daniel Vetter , Phil Elwell , Jerome Brunet , Tim Gover , Dave Stevenson , Kevin Hilman , Jernej Skrabec , Jonathan Hunter , Jonas Karlman , Martin Blumenstingl , intel-gfx@lists.freedesktop.org, Rodrigo Vivi , linux-tegra@vger.kernel.org, linux-amlogic@lists.infradead.org, linux-arm-kernel@lists.infradead.org, Dom Cobley , "Pan, Xinhui" , Robert Foss , Thomas Zimmermann , Alex Deucher , Christian =?iso-8859-1?Q?K=F6nig?= , Laurent Pinchart Subject: Re: [PATCH 01/13] drm/connector: Add define for HDMI 1.4 Maximum Pixel Rate Message-ID: References: <20211102145944.259181-1-maxime@cerno.tech> <20211102145944.259181-2-maxime@cerno.tech> <20211104084841.mjnennxgelacleaj@gilmour> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20211104084841.mjnennxgelacleaj@gilmour> X-Patchwork-Hint: comment Precedence: bulk List-ID: X-Mailing-List: linux-tegra@vger.kernel.org On Thu, Nov 04, 2021 at 09:48:41AM +0100, Maxime Ripard wrote: > Hi Ville, > > On Wed, Nov 03, 2021 at 08:05:16PM +0200, Ville Syrjälä wrote: > > On Wed, Nov 03, 2021 at 01:02:11PM +0200, Ville Syrjälä wrote: > > > On Tue, Nov 02, 2021 at 03:59:32PM +0100, Maxime Ripard wrote: > > > > --- a/drivers/gpu/drm/drm_edid.c > > > > +++ b/drivers/gpu/drm/drm_edid.c > > > > @@ -4966,7 +4966,7 @@ static void drm_parse_hdmi_forum_vsdb(struct drm_connector *connector, > > > > u32 max_tmds_clock = hf_vsdb[5] * 5000; > > > > struct drm_scdc *scdc = &hdmi->scdc; > > > > > > > > - if (max_tmds_clock > 340000) { > > > > + if (max_tmds_clock > DRM_HDMI_14_MAX_TMDS_CLK_KHZ) { > > > > display->max_tmds_clock = max_tmds_clock; > > > > DRM_DEBUG_KMS("HF-VSDB: max TMDS clock %d kHz\n", > > > > display->max_tmds_clock); > > > > diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c b/drivers/gpu/drm/i915/display/intel_hdmi.c > > > > index d2e61f6c6e08..0666203d52b7 100644 > > > > --- a/drivers/gpu/drm/i915/display/intel_hdmi.c > > > > +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c > > > > @@ -2226,7 +2226,7 @@ int intel_hdmi_compute_config(struct intel_encoder *encoder, > > > > if (scdc->scrambling.low_rates) > > > > pipe_config->hdmi_scrambling = true; > > > > > > > > - if (pipe_config->port_clock > 340000) { > > > > + if (pipe_config->port_clock > DRM_HDMI_14_MAX_TMDS_CLK_KHZ) { > > > > pipe_config->hdmi_scrambling = true; > > > > pipe_config->hdmi_high_tmds_clock_ratio = true; > > > > } > > > > > > All of that is HDMI 2.0 stuff. So this just makes it all super > > > confusing IMO. Nak. > > > > So reading throgh HDMI 1.4 again it does specify 340 MHz as some kind > > of upper limit for the physical cable. But nowhere else is that number > > really mentioned AFAICS. HDMI 2.0 does talk quite a bit about the 340 > > Mcsc limit in various places. > > > > I wonder what people would think of a couple of helpers like: > > - drm_hdmi_{can,must}_use_scrambling() > > - drm_hdmi_is_high_tmds_clock_ratio() > > or something along those lines? At least with those the code would > > read decently and I wouldn't have to wonder what this HDMI 1.4 TMDS > > clock limit really is. > > Patch 2 introduces something along those lines. > > It doesn't cover everything though, we're using this define in vc4 to > limit the available modes in mode_valid on HDMI controllers not > 4k-capable I wouldn't want to use this kind of define for those kinds of checks anyway. If the hardware has specific limits in what kind of clocks it can generate (or what it was validated for) IMO you should spell those out explicitly instead of assuming they happen to match some standard defined max value. -- Ville Syrjälä Intel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8EBF2C433EF for ; Thu, 4 Nov 2021 15:41:28 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 528C9610FD for ; Thu, 4 Nov 2021 15:41:28 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 528C9610FD Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 22EC46EE4A; Thu, 4 Nov 2021 15:41:25 +0000 (UTC) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by gabe.freedesktop.org (Postfix) with ESMTPS id A56FB6EDFA; Thu, 4 Nov 2021 15:41:23 +0000 (UTC) X-IronPort-AV: E=McAfee;i="6200,9189,10157"; a="295175449" X-IronPort-AV: E=Sophos;i="5.87,209,1631602800"; d="scan'208";a="295175449" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Nov 2021 08:41:23 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.87,209,1631602800"; d="scan'208";a="450250513" Received: from stinkbox.fi.intel.com (HELO stinkbox) ([10.237.72.171]) by orsmga006.jf.intel.com with SMTP; 04 Nov 2021 08:41:14 -0700 Received: by stinkbox (sSMTP sendmail emulation); Thu, 04 Nov 2021 17:41:13 +0200 Date: Thu, 4 Nov 2021 17:41:13 +0200 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Maxime Ripard Subject: Re: [PATCH 01/13] drm/connector: Add define for HDMI 1.4 Maximum Pixel Rate Message-ID: References: <20211102145944.259181-1-maxime@cerno.tech> <20211102145944.259181-2-maxime@cerno.tech> <20211104084841.mjnennxgelacleaj@gilmour> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20211104084841.mjnennxgelacleaj@gilmour> X-Patchwork-Hint: comment X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Tim Gover , Neil Armstrong , David Airlie , dri-devel@lists.freedesktop.org, Andrzej Hajda , Thierry Reding , amd-gfx@lists.freedesktop.org, Benjamin Gaignard , Daniel Vetter , Phil Elwell , Jerome Brunet , Emma Anholt , Dave Stevenson , Kevin Hilman , Jernej Skrabec , Jonathan Hunter , Jonas Karlman , Martin Blumenstingl , intel-gfx@lists.freedesktop.org, Rodrigo Vivi , linux-tegra@vger.kernel.org, linux-amlogic@lists.infradead.org, linux-arm-kernel@lists.infradead.org, Dom Cobley , "Pan, Xinhui" , Robert Foss , Thomas Zimmermann , Alex Deucher , Christian =?iso-8859-1?Q?K=F6nig?= , Laurent Pinchart Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Thu, Nov 04, 2021 at 09:48:41AM +0100, Maxime Ripard wrote: > Hi Ville, > > On Wed, Nov 03, 2021 at 08:05:16PM +0200, Ville Syrjälä wrote: > > On Wed, Nov 03, 2021 at 01:02:11PM +0200, Ville Syrjälä wrote: > > > On Tue, Nov 02, 2021 at 03:59:32PM +0100, Maxime Ripard wrote: > > > > --- a/drivers/gpu/drm/drm_edid.c > > > > +++ b/drivers/gpu/drm/drm_edid.c > > > > @@ -4966,7 +4966,7 @@ static void drm_parse_hdmi_forum_vsdb(struct drm_connector *connector, > > > > u32 max_tmds_clock = hf_vsdb[5] * 5000; > > > > struct drm_scdc *scdc = &hdmi->scdc; > > > > > > > > - if (max_tmds_clock > 340000) { > > > > + if (max_tmds_clock > DRM_HDMI_14_MAX_TMDS_CLK_KHZ) { > > > > display->max_tmds_clock = max_tmds_clock; > > > > DRM_DEBUG_KMS("HF-VSDB: max TMDS clock %d kHz\n", > > > > display->max_tmds_clock); > > > > diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c b/drivers/gpu/drm/i915/display/intel_hdmi.c > > > > index d2e61f6c6e08..0666203d52b7 100644 > > > > --- a/drivers/gpu/drm/i915/display/intel_hdmi.c > > > > +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c > > > > @@ -2226,7 +2226,7 @@ int intel_hdmi_compute_config(struct intel_encoder *encoder, > > > > if (scdc->scrambling.low_rates) > > > > pipe_config->hdmi_scrambling = true; > > > > > > > > - if (pipe_config->port_clock > 340000) { > > > > + if (pipe_config->port_clock > DRM_HDMI_14_MAX_TMDS_CLK_KHZ) { > > > > pipe_config->hdmi_scrambling = true; > > > > pipe_config->hdmi_high_tmds_clock_ratio = true; > > > > } > > > > > > All of that is HDMI 2.0 stuff. So this just makes it all super > > > confusing IMO. Nak. > > > > So reading throgh HDMI 1.4 again it does specify 340 MHz as some kind > > of upper limit for the physical cable. But nowhere else is that number > > really mentioned AFAICS. HDMI 2.0 does talk quite a bit about the 340 > > Mcsc limit in various places. > > > > I wonder what people would think of a couple of helpers like: > > - drm_hdmi_{can,must}_use_scrambling() > > - drm_hdmi_is_high_tmds_clock_ratio() > > or something along those lines? At least with those the code would > > read decently and I wouldn't have to wonder what this HDMI 1.4 TMDS > > clock limit really is. > > Patch 2 introduces something along those lines. > > It doesn't cover everything though, we're using this define in vc4 to > limit the available modes in mode_valid on HDMI controllers not > 4k-capable I wouldn't want to use this kind of define for those kinds of checks anyway. If the hardware has specific limits in what kind of clocks it can generate (or what it was validated for) IMO you should spell those out explicitly instead of assuming they happen to match some standard defined max value. -- Ville Syrjälä Intel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 97262C4332F for ; Thu, 4 Nov 2021 15:41:26 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 5E98061212 for ; Thu, 4 Nov 2021 15:41:26 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 5E98061212 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id F207D6EE0C; Thu, 4 Nov 2021 15:41:24 +0000 (UTC) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by gabe.freedesktop.org (Postfix) with ESMTPS id A56FB6EDFA; Thu, 4 Nov 2021 15:41:23 +0000 (UTC) X-IronPort-AV: E=McAfee;i="6200,9189,10157"; a="295175449" X-IronPort-AV: E=Sophos;i="5.87,209,1631602800"; d="scan'208";a="295175449" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Nov 2021 08:41:23 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.87,209,1631602800"; d="scan'208";a="450250513" Received: from stinkbox.fi.intel.com (HELO stinkbox) ([10.237.72.171]) by orsmga006.jf.intel.com with SMTP; 04 Nov 2021 08:41:14 -0700 Received: by stinkbox (sSMTP sendmail emulation); Thu, 04 Nov 2021 17:41:13 +0200 Date: Thu, 4 Nov 2021 17:41:13 +0200 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Maxime Ripard Message-ID: References: <20211102145944.259181-1-maxime@cerno.tech> <20211102145944.259181-2-maxime@cerno.tech> <20211104084841.mjnennxgelacleaj@gilmour> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20211104084841.mjnennxgelacleaj@gilmour> X-Patchwork-Hint: comment Subject: Re: [Intel-gfx] [PATCH 01/13] drm/connector: Add define for HDMI 1.4 Maximum Pixel Rate X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Tim Gover , Neil Armstrong , David Airlie , dri-devel@lists.freedesktop.org, Andrzej Hajda , amd-gfx@lists.freedesktop.org, Benjamin Gaignard , Daniel Vetter , Phil Elwell , Jerome Brunet , Emma Anholt , Dave Stevenson , Kevin Hilman , Jernej Skrabec , Jonathan Hunter , Jonas Karlman , Martin Blumenstingl , intel-gfx@lists.freedesktop.org, linux-tegra@vger.kernel.org, linux-amlogic@lists.infradead.org, linux-arm-kernel@lists.infradead.org, Dom Cobley , "Pan, Xinhui" , Robert Foss , Thomas Zimmermann , Alex Deucher , Christian =?iso-8859-1?Q?K=F6nig?= , Laurent Pinchart Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Thu, Nov 04, 2021 at 09:48:41AM +0100, Maxime Ripard wrote: > Hi Ville, > > On Wed, Nov 03, 2021 at 08:05:16PM +0200, Ville Syrjälä wrote: > > On Wed, Nov 03, 2021 at 01:02:11PM +0200, Ville Syrjälä wrote: > > > On Tue, Nov 02, 2021 at 03:59:32PM +0100, Maxime Ripard wrote: > > > > --- a/drivers/gpu/drm/drm_edid.c > > > > +++ b/drivers/gpu/drm/drm_edid.c > > > > @@ -4966,7 +4966,7 @@ static void drm_parse_hdmi_forum_vsdb(struct drm_connector *connector, > > > > u32 max_tmds_clock = hf_vsdb[5] * 5000; > > > > struct drm_scdc *scdc = &hdmi->scdc; > > > > > > > > - if (max_tmds_clock > 340000) { > > > > + if (max_tmds_clock > DRM_HDMI_14_MAX_TMDS_CLK_KHZ) { > > > > display->max_tmds_clock = max_tmds_clock; > > > > DRM_DEBUG_KMS("HF-VSDB: max TMDS clock %d kHz\n", > > > > display->max_tmds_clock); > > > > diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c b/drivers/gpu/drm/i915/display/intel_hdmi.c > > > > index d2e61f6c6e08..0666203d52b7 100644 > > > > --- a/drivers/gpu/drm/i915/display/intel_hdmi.c > > > > +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c > > > > @@ -2226,7 +2226,7 @@ int intel_hdmi_compute_config(struct intel_encoder *encoder, > > > > if (scdc->scrambling.low_rates) > > > > pipe_config->hdmi_scrambling = true; > > > > > > > > - if (pipe_config->port_clock > 340000) { > > > > + if (pipe_config->port_clock > DRM_HDMI_14_MAX_TMDS_CLK_KHZ) { > > > > pipe_config->hdmi_scrambling = true; > > > > pipe_config->hdmi_high_tmds_clock_ratio = true; > > > > } > > > > > > All of that is HDMI 2.0 stuff. So this just makes it all super > > > confusing IMO. Nak. > > > > So reading throgh HDMI 1.4 again it does specify 340 MHz as some kind > > of upper limit for the physical cable. But nowhere else is that number > > really mentioned AFAICS. HDMI 2.0 does talk quite a bit about the 340 > > Mcsc limit in various places. > > > > I wonder what people would think of a couple of helpers like: > > - drm_hdmi_{can,must}_use_scrambling() > > - drm_hdmi_is_high_tmds_clock_ratio() > > or something along those lines? At least with those the code would > > read decently and I wouldn't have to wonder what this HDMI 1.4 TMDS > > clock limit really is. > > Patch 2 introduces something along those lines. > > It doesn't cover everything though, we're using this define in vc4 to > limit the available modes in mode_valid on HDMI controllers not > 4k-capable I wouldn't want to use this kind of define for those kinds of checks anyway. If the hardware has specific limits in what kind of clocks it can generate (or what it was validated for) IMO you should spell those out explicitly instead of assuming they happen to match some standard defined max value. -- Ville Syrjälä Intel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 55919C433EF for ; Thu, 4 Nov 2021 15:41:57 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id EA300610FD for ; Thu, 4 Nov 2021 15:41:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org EA300610FD Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=batikRMZzNBhdsTomYpDy9LSNSp+P4lshBCgfILAlP0=; b=gSCm0ztp6/ST+/ SssvTVQLEtVr3Ml4T4yZnw9xz/3sHo5LCLP4uysCg2gTdEG8r64Kg+udJpOKoNOnLSQKDwBjyiM8B fO1Frq3O7mejSyi52w5MOb3K57bBMCOTd1NV6IX0Ed3NuqORW2hbfDZ9cZg/dVdH7DzSlexLLq9yZ uzNiKojxej9hbuQeElV9+SHZIYf90Fh5CjD+qxCDKxSsQfeM9QZG6V9eo14n2tB9FexIvBVwU4yut V3oscWfdCz6HC6rH1Q+Hn+CtpLWD1NSBqCj01RxColq0rkiFOrE/Orjb5CPrM29FRnbKZgy+ssK9T vMa6aI2U4U1bK7RrTuaA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1miesB-009Hze-9C; Thu, 04 Nov 2021 15:41:51 +0000 Received: from mga18.intel.com ([134.134.136.126]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1miern-009HtA-H6; Thu, 04 Nov 2021 15:41:28 +0000 X-IronPort-AV: E=McAfee;i="6200,9189,10157"; a="218631536" X-IronPort-AV: E=Sophos;i="5.87,209,1631602800"; d="scan'208";a="218631536" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Nov 2021 08:41:23 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.87,209,1631602800"; d="scan'208";a="450250513" Received: from stinkbox.fi.intel.com (HELO stinkbox) ([10.237.72.171]) by orsmga006.jf.intel.com with SMTP; 04 Nov 2021 08:41:14 -0700 Received: by stinkbox (sSMTP sendmail emulation); Thu, 04 Nov 2021 17:41:13 +0200 Date: Thu, 4 Nov 2021 17:41:13 +0200 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Maxime Ripard Cc: Emma Anholt , Neil Armstrong , David Airlie , dri-devel@lists.freedesktop.org, Andrzej Hajda , Thierry Reding , amd-gfx@lists.freedesktop.org, Benjamin Gaignard , Daniel Vetter , Phil Elwell , Jerome Brunet , Tim Gover , Dave Stevenson , Kevin Hilman , Jernej Skrabec , Jonathan Hunter , Jonas Karlman , Martin Blumenstingl , intel-gfx@lists.freedesktop.org, Rodrigo Vivi , linux-tegra@vger.kernel.org, linux-amlogic@lists.infradead.org, linux-arm-kernel@lists.infradead.org, Dom Cobley , "Pan, Xinhui" , Robert Foss , Thomas Zimmermann , Alex Deucher , Christian =?iso-8859-1?Q?K=F6nig?= , Laurent Pinchart Subject: Re: [PATCH 01/13] drm/connector: Add define for HDMI 1.4 Maximum Pixel Rate Message-ID: References: <20211102145944.259181-1-maxime@cerno.tech> <20211102145944.259181-2-maxime@cerno.tech> <20211104084841.mjnennxgelacleaj@gilmour> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20211104084841.mjnennxgelacleaj@gilmour> X-Patchwork-Hint: comment X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211104_084127_641493_201809D1 X-CRM114-Status: GOOD ( 24.95 ) X-BeenThere: linux-amlogic@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-amlogic" Errors-To: linux-amlogic-bounces+linux-amlogic=archiver.kernel.org@lists.infradead.org On Thu, Nov 04, 2021 at 09:48:41AM +0100, Maxime Ripard wrote: > Hi Ville, > = > On Wed, Nov 03, 2021 at 08:05:16PM +0200, Ville Syrj=E4l=E4 wrote: > > On Wed, Nov 03, 2021 at 01:02:11PM +0200, Ville Syrj=E4l=E4 wrote: > > > On Tue, Nov 02, 2021 at 03:59:32PM +0100, Maxime Ripard wrote: > > > > --- a/drivers/gpu/drm/drm_edid.c > > > > +++ b/drivers/gpu/drm/drm_edid.c > > > > @@ -4966,7 +4966,7 @@ static void drm_parse_hdmi_forum_vsdb(struct = drm_connector *connector, > > > > u32 max_tmds_clock =3D hf_vsdb[5] * 5000; > > > > struct drm_scdc *scdc =3D &hdmi->scdc; > > > > = > > > > - if (max_tmds_clock > 340000) { > > > > + if (max_tmds_clock > DRM_HDMI_14_MAX_TMDS_CLK_KHZ) { > > > > display->max_tmds_clock =3D max_tmds_clock; > > > > DRM_DEBUG_KMS("HF-VSDB: max TMDS clock %d kHz\n", > > > > display->max_tmds_clock); > > > > diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c b/drivers/gp= u/drm/i915/display/intel_hdmi.c > > > > index d2e61f6c6e08..0666203d52b7 100644 > > > > --- a/drivers/gpu/drm/i915/display/intel_hdmi.c > > > > +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c > > > > @@ -2226,7 +2226,7 @@ int intel_hdmi_compute_config(struct intel_en= coder *encoder, > > > > if (scdc->scrambling.low_rates) > > > > pipe_config->hdmi_scrambling =3D true; > > > > = > > > > - if (pipe_config->port_clock > 340000) { > > > > + if (pipe_config->port_clock > DRM_HDMI_14_MAX_TMDS_CLK_KHZ) { > > > > pipe_config->hdmi_scrambling =3D true; > > > > pipe_config->hdmi_high_tmds_clock_ratio =3D true; > > > > } > > > = > > > All of that is HDMI 2.0 stuff. So this just makes it all super > > > confusing IMO. Nak. > > = > > So reading throgh HDMI 1.4 again it does specify 340 MHz as some kind > > of upper limit for the physical cable. But nowhere else is that number > > really mentioned AFAICS. HDMI 2.0 does talk quite a bit about the 340 > > Mcsc limit in various places. > > = > > I wonder what people would think of a couple of helpers like: > > - drm_hdmi_{can,must}_use_scrambling() > > - drm_hdmi_is_high_tmds_clock_ratio() > > or something along those lines? At least with those the code would > > read decently and I wouldn't have to wonder what this HDMI 1.4 TMDS > > clock limit really is. > = > Patch 2 introduces something along those lines. > = > It doesn't cover everything though, we're using this define in vc4 to > limit the available modes in mode_valid on HDMI controllers not > 4k-capable I wouldn't want to use this kind of define for those kinds of checks anyway. If the hardware has specific limits in what kind of clocks it can generate (or what it was validated for) IMO you should spell those out explicitly instead of assuming they happen to match some standard defined max value. -- = Ville Syrj=E4l=E4 Intel _______________________________________________ linux-amlogic mailing list linux-amlogic@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-amlogic From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4CBAEC433F5 for ; Thu, 4 Nov 2021 15:43:03 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 13833610D0 for ; Thu, 4 Nov 2021 15:43:03 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 13833610D0 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=p3M/PWKzJ3l8TAuBPRYSATZYZQOA/QFRK1XsgYt8brI=; b=is2lCY7prMicy5 8o416SPqRr/hJ9eINo142fIRjOyebGByX4cn9qaWcjzaR7CL2sWhFoQfmIF+yw8Ltf8lg4KP2ppde IYgQZ1GKYLNvu58o6Q7wEqrFW4OIxOkOZRkbzpEIrV9Rn1HriFSaETJ9ECESMRUqGt73BtgohNk7B K2MkhM7WS2dMwuOgvfPqLGT+CebTyHtOeO5iVw2D4C4Bj82Wf7wv0kQh92kh+U0RdpwEwwe3KaOPg +WCdB0a5l9Cye50PuHfBcx4vFHRpUhGUIpgDqN6COTA+HVPuLyYgdcAs6AoD/tQOeF7z/D6GFQwNZ nz9HmUNJ9h0sfE49/vOg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mies1-009HwV-U9; Thu, 04 Nov 2021 15:41:42 +0000 Received: from mga18.intel.com ([134.134.136.126]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1miern-009HtA-H6; Thu, 04 Nov 2021 15:41:28 +0000 X-IronPort-AV: E=McAfee;i="6200,9189,10157"; a="218631536" X-IronPort-AV: E=Sophos;i="5.87,209,1631602800"; d="scan'208";a="218631536" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Nov 2021 08:41:23 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.87,209,1631602800"; d="scan'208";a="450250513" Received: from stinkbox.fi.intel.com (HELO stinkbox) ([10.237.72.171]) by orsmga006.jf.intel.com with SMTP; 04 Nov 2021 08:41:14 -0700 Received: by stinkbox (sSMTP sendmail emulation); Thu, 04 Nov 2021 17:41:13 +0200 Date: Thu, 4 Nov 2021 17:41:13 +0200 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Maxime Ripard Cc: Emma Anholt , Neil Armstrong , David Airlie , dri-devel@lists.freedesktop.org, Andrzej Hajda , Thierry Reding , amd-gfx@lists.freedesktop.org, Benjamin Gaignard , Daniel Vetter , Phil Elwell , Jerome Brunet , Tim Gover , Dave Stevenson , Kevin Hilman , Jernej Skrabec , Jonathan Hunter , Jonas Karlman , Martin Blumenstingl , intel-gfx@lists.freedesktop.org, Rodrigo Vivi , linux-tegra@vger.kernel.org, linux-amlogic@lists.infradead.org, linux-arm-kernel@lists.infradead.org, Dom Cobley , "Pan, Xinhui" , Robert Foss , Thomas Zimmermann , Alex Deucher , Christian =?iso-8859-1?Q?K=F6nig?= , Laurent Pinchart Subject: Re: [PATCH 01/13] drm/connector: Add define for HDMI 1.4 Maximum Pixel Rate Message-ID: References: <20211102145944.259181-1-maxime@cerno.tech> <20211102145944.259181-2-maxime@cerno.tech> <20211104084841.mjnennxgelacleaj@gilmour> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20211104084841.mjnennxgelacleaj@gilmour> X-Patchwork-Hint: comment X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211104_084127_641493_201809D1 X-CRM114-Status: GOOD ( 24.95 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Nov 04, 2021 at 09:48:41AM +0100, Maxime Ripard wrote: > Hi Ville, > = > On Wed, Nov 03, 2021 at 08:05:16PM +0200, Ville Syrj=E4l=E4 wrote: > > On Wed, Nov 03, 2021 at 01:02:11PM +0200, Ville Syrj=E4l=E4 wrote: > > > On Tue, Nov 02, 2021 at 03:59:32PM +0100, Maxime Ripard wrote: > > > > --- a/drivers/gpu/drm/drm_edid.c > > > > +++ b/drivers/gpu/drm/drm_edid.c > > > > @@ -4966,7 +4966,7 @@ static void drm_parse_hdmi_forum_vsdb(struct = drm_connector *connector, > > > > u32 max_tmds_clock =3D hf_vsdb[5] * 5000; > > > > struct drm_scdc *scdc =3D &hdmi->scdc; > > > > = > > > > - if (max_tmds_clock > 340000) { > > > > + if (max_tmds_clock > DRM_HDMI_14_MAX_TMDS_CLK_KHZ) { > > > > display->max_tmds_clock =3D max_tmds_clock; > > > > DRM_DEBUG_KMS("HF-VSDB: max TMDS clock %d kHz\n", > > > > display->max_tmds_clock); > > > > diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c b/drivers/gp= u/drm/i915/display/intel_hdmi.c > > > > index d2e61f6c6e08..0666203d52b7 100644 > > > > --- a/drivers/gpu/drm/i915/display/intel_hdmi.c > > > > +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c > > > > @@ -2226,7 +2226,7 @@ int intel_hdmi_compute_config(struct intel_en= coder *encoder, > > > > if (scdc->scrambling.low_rates) > > > > pipe_config->hdmi_scrambling =3D true; > > > > = > > > > - if (pipe_config->port_clock > 340000) { > > > > + if (pipe_config->port_clock > DRM_HDMI_14_MAX_TMDS_CLK_KHZ) { > > > > pipe_config->hdmi_scrambling =3D true; > > > > pipe_config->hdmi_high_tmds_clock_ratio =3D true; > > > > } > > > = > > > All of that is HDMI 2.0 stuff. So this just makes it all super > > > confusing IMO. Nak. > > = > > So reading throgh HDMI 1.4 again it does specify 340 MHz as some kind > > of upper limit for the physical cable. But nowhere else is that number > > really mentioned AFAICS. HDMI 2.0 does talk quite a bit about the 340 > > Mcsc limit in various places. > > = > > I wonder what people would think of a couple of helpers like: > > - drm_hdmi_{can,must}_use_scrambling() > > - drm_hdmi_is_high_tmds_clock_ratio() > > or something along those lines? At least with those the code would > > read decently and I wouldn't have to wonder what this HDMI 1.4 TMDS > > clock limit really is. > = > Patch 2 introduces something along those lines. > = > It doesn't cover everything though, we're using this define in vc4 to > limit the available modes in mode_valid on HDMI controllers not > 4k-capable I wouldn't want to use this kind of define for those kinds of checks anyway. If the hardware has specific limits in what kind of clocks it can generate (or what it was validated for) IMO you should spell those out explicitly instead of assuming they happen to match some standard defined max value. -- = Ville Syrj=E4l=E4 Intel _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel