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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 95ABDC2BA15 for ; Mon, 17 Jun 2024 23:46:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:References: List-Owner; bh=WEcb4ceq4vj6F4Lm3zQBzfoD3bnUJEBNMCgzOVt1Zv0=; b=mDibil3Iv8lTrr 24K9Pu2be6/+6+OicX1KPasddbxlP9TdJJ6DN++7RCCMRL3Ae8qfB8xByzfI+chxKLsWct4qQnPKw /TUe8kSZn7R+xi+dpNmAbj7kdSi7iMZ030yorJiyGdRY5X8hcNMhTCU4Kq/9xWmUw2peCWAKvwSKo 6XLAMp63NmDVweUYvOxfWbVjlLfnRUXeFWRWnfI4BW7WjugM94WcpnH9m0F7t5vhqDmmu1T5Ojw80 NigzgcKdrvdiEwykkW1TeDFXZ44ZujPw8HqEFte050Vumf0/ZgMcHaSE4HjMmz1c6bxke5xzWsLbF Oza4rAegk3fs4NT6uCXQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sJM30-0000000CxRR-0J3q; Mon, 17 Jun 2024 23:46:02 +0000 Received: from gw2.atmark-techno.com ([35.74.137.57]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sJM2w-0000000CxQJ-41Ee for linux-arm-kernel@lists.infradead.org; Mon, 17 Jun 2024 23:46:00 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=atmark-techno.com; s=gw2_bookworm; t=1718667956; bh=u4SQ7Kn/9QOe7Lbom+t4xd7zdIO/xFKu407b+d9kyI8=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=LV7+focIijh6TZ3/phSj+mf8wNhszgO1C8IRU048WA4S8kJzUL75TZ37mFJv3qBnH VNsIpVHPZhaQeyB13y1sgYvKKHWfL+kfSuivo4UmlFrAtnq1KApqlxVBsGm48qB6FO G930rlGiZdxY/gGsjbBGOqnKXAx6NS0PZYOSrkORPjgvXqqTTzDckoTqNfX0/+HOUT fiAOe/d5a0KcDgN9sKdzacFaYkvrYeLjfMlc5DXBy0+xlBwW8tNj+tmbBQGBWLVO2V Hx3Vh7r7/jLGPUI1IqI3a9TN5GLIEGR3L7KILjTNBvH29UHqdvPWV1nCfgon/RUVIo 5Ltit7+NmvIJQ== Received: from gw2.atmark-techno.com (localhost [127.0.0.1]) by gw2.atmark-techno.com (Postfix) with ESMTP id 01AA9A74 for ; Tue, 18 Jun 2024 08:45:56 +0900 (JST) Authentication-Results: gw2.atmark-techno.com; dkim=pass (2048-bit key; unprotected) header.d=atmark-techno.com header.i=@atmark-techno.com header.a=rsa-sha256 header.s=google header.b=LsO1BIu7; dkim-atps=neutral Received: from mail-ot1-f72.google.com (mail-ot1-f72.google.com [209.85.210.72]) by gw2.atmark-techno.com (Postfix) with ESMTPS id 62293A87 for ; Tue, 18 Jun 2024 08:45:53 +0900 (JST) Received: by mail-ot1-f72.google.com with SMTP id 46e09a7af769-6f96e58ad4aso6132453a34.0 for ; Mon, 17 Jun 2024 16:45:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=atmark-techno.com; s=google; t=1718667952; x=1719272752; darn=lists.infradead.org; h=in-reply-to:content-disposition:mime-version:message-id:subject:cc :to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=WEcb4ceq4vj6F4Lm3zQBzfoD3bnUJEBNMCgzOVt1Zv0=; b=LsO1BIu75NemsB/Gb0LOwjjLquxnuYJ9kkHUakOyi+CLgNO0D2YWGgVh8+vIl5rtv/ A/nqCBbqyxJrhChzMXfLqLCtWuQWJWuQReuoBfAyYt7eVFipYQyFKXiYBixdKLzKG57x n5X/B/9mXEzdteD+GjebpWrsujHBMLewXTFv/gsBgp1YngH0tugpIm44i8WC77tmfxpH qmvAQoBKX3DsGqXhZqiIxgrf/fU3amOCw66FCanNLQM75g+y/+eQ5fLaXD09pF4vN+0N REBfADKXT9H63+m/AP8dhmD9hrIrgbWXfIx8ZwTSWxWWQ/emGNNwiX5/+WwP1+4/2U7L bGYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718667952; x=1719272752; h=in-reply-to:content-disposition:mime-version:message-id:subject:cc :to:from:date:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=WEcb4ceq4vj6F4Lm3zQBzfoD3bnUJEBNMCgzOVt1Zv0=; b=c2ZuS9y+DIYsdVC7diYjUTWbjucdHHLc+6Ra19n/IQFod17Bfrr46qKe3g0fwd/U4O JNSuWnWZeLoX9CeYkjWZRhym/IfOcfAVAwKSWOHul+PXl7O9r69/Jl95Jb/FirCwc8kD b94YzVmP6Q6UNo34JQ6HT25OeeqlK7MMAYMYmDrK13aXnitw/0grE0OWeOngE+x3qmka p6P/BZ666SbE7cDD/Uc0d23Ee5YloxSuqef7BQYkT2OkRhM8JzHM1QNYcVsexTfbnP+e egawkdd3y1Gu98le0ne0r6Py2BCV8WKE8gRIqu50adrQXMFxucaAH/6z5yTRFWzt/+63 sLYA== X-Gm-Message-State: AOJu0YxiB3zO7aeJGuTAcV/zfGL+TI8ZjEOqWOMzzM8eGl39ukPdtFzz WYpOhYMT+D4eS8c44FNWpjrP28nyeFwlwTNVOP/de5SaXBEutcDjxGdICsaJNxJmLcva3KqLcla R+acakQSyLJ5ZMYYFnDWJmFNdsTcqFgz0WbmHCkjg6YpstDQ8/fDCzzYq1zQ+goe58yJypieFkw == X-Received: by 2002:a05:6870:1c6:b0:24c:a547:7b5a with SMTP id 586e51a60fabf-258428b6ce7mr13781162fac.14.1718667951756; Mon, 17 Jun 2024 16:45:51 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHRFeiOGQPSIT5KptgcYboMcw31OfX8XCos9btgN4pxjCsjHfG6eKkB1gU/XzVNeRv8POSMRg== X-Received: by 2002:a05:6870:1c6:b0:24c:a547:7b5a with SMTP id 586e51a60fabf-258428b6ce7mr13781138fac.14.1718667951311; Mon, 17 Jun 2024 16:45:51 -0700 (PDT) Received: from pc-0182.atmarktech (103.131.189.35.bc.googleusercontent.com. [35.189.131.103]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-705cc91dc67sm7938979b3a.2.2024.06.17.16.45.50 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Jun 2024 16:45:50 -0700 (PDT) Received: from martinet by pc-0182.atmarktech with local (Exim 4.96) (envelope-from ) id 1sJM2m-00ABEf-2m; Tue, 18 Jun 2024 08:45:48 +0900 Date: Tue, 18 Jun 2024 08:45:38 +0900 From: Dominique MARTINET To: Adam Ford , Lucas Stach Cc: linux-arm-kernel@lists.infradead.org, marex@denx.de, Laurent Pinchart , Andrzej Hajda , Neil Armstrong , Robert Foss , Jonas Karlman , Jernej Skrabec , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Daniel Vetter , Shawn Guo , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , NXP Linux Team , Vinod Koul , Kishon Vijay Abraham I , Liu Ying , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-phy@lists.infradead.org, Makoto Sato Subject: Re: drm/bridge/imx8mp-hdmi-tx: Allow inexact pixel clock frequencies (Was: [PATCH V8 10/12] drm/bridge: imx: add bridge wrapper driver for i.MX8MP DWC HDMI) Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <22a3f5266260dd3915269ae3eec7724f7537eb55.camel@pengutronix.de> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240617_164559_162668_9736AD6C X-CRM114-Status: GOOD ( 45.53 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Thanks for the replies, replying to both mails at once. Adam Ford wrote on Mon, Jun 17, 2024 at 08:28:58AM -0500: > > Commit 6ad082bee902 ("phy: freescale: add Samsung HDMI PHY") already > > "fixed" the samsung hdmi phy driver to return the next frequency if an > > exact match hasn't been found (NXP tree's match frequencies exactly, but > > this gets the first clock with pixclk <= rate), so if this check is also > > relaxed our displays would work out of the box. > > Are you proposing to replace 'return MODE_CLOCK_RANGE' with a printed warning? Yes, something like that. The imx93-mipi-dsi.c code has a check that's a bit more complex that might be closer to what we want if you think the check is useful: if ((bridge->ops & DRM_BRIDGE_OP_DETECT) && (bridge->ops & DRM_BRIDGE_OP_EDID)) { unsigned long pixel_clock_rate = mode->clock * 1000; unsigned long rounded_rate; /* Allow +/-0.5% pixel clock rate deviation */ rounded_rate = clk_round_rate(dsi->clk_pixel, pixel_clock_rate); if (rounded_rate < pixel_clock_rate * 995 / 1000 || rounded_rate > pixel_clock_rate * 1005 / 1000) { dev_dbg(dsi->dev, "failed to round clock for mode " DRM_MODE_FMT "\n", DRM_MODE_ARG(mode)); return MODE_NOCLOCK; } } However, for my particular case 0.5% wouldn't be enough to get something to display unfortunately :/ > > In practice the screen I'm looking at has an EDID which only supports > > 51.2MHz and the closest frequency supported by the Samsung HDMI phy is > > 50.4MHz, so that's a ~1.5% difference and it'd be great if it could work > > out of the box. > > I wonder if the HDMI PHY could be improved to better dynamically > calculate values instead of the look tables. That would probably be ideal, right... If we could do that we could likely compute something within 0.5% of the required freq. The original code from NXP was full of what seemed at the time magic values, but with the new code it seems quite a bit clearer... At least the values that are left seem to somewhat make sense: https://gaia.codewreck.org/local/linux/hdmi/plot-combined.svg https://gaia.codewreck.org/local/linux/hdmi/plot-1.svg -> dented linear values, per the intervals defined in fsl_samsung_hdmi_phy_configure_pixclk() https://gaia.codewreck.org/local/linux/hdmi/plot-2.svg -> constant for each intervals? https://gaia.codewreck.org/local/linux/hdmi/plot-3.svg https://gaia.codewreck.org/local/linux/hdmi/plot-4.svg these don't really make sense to me... https://gaia.codewreck.org/local/linux/hdmi/plot-5.svg that one 0 value at 154000000 looks odd, but that aside we could probably get away with constant 0x80 if the value matters at all... https://gaia.codewreck.org/local/linux/hdmi/plot-6.svg weird as well I'm thinking the last few values just affect a very small % of the values, but would need to check with a proper scope if I can get a hold of the clock line... Does any of you happen to have any datasheet for these registers, or should we consider them to be magic values? Lucas Stach wrote on Mon, Jun 17, 2024 at 06:32:45PM +0200: > > Do you know why such a check is here? > > Sending a HDMI signal with a different rate than what the display > expects rarely ends well, so this check avoids that. > > However, this check is a bit overcautious in that it only allows exact > rate matches. IIRC HDMI allows a rate mismatch of +- 0.5%, so this > check could be relaxed quite a bit to allow for that. I'd expect displays to be tolerant to quite a few percents, but I didn't know the spec defined something like that... iirc the HDMI spec isn't public? > > In practice the screen I'm looking at has an EDID which only supports > > 51.2MHz and the closest frequency supported by the Samsung HDMI phy is > > 50.4MHz, so that's a ~1.5% difference and it'd be great if it could work > > out of the box. > > For rate mismatches larger than the 0.5% allowed by the HDMI spec it > would be better to actually add PHY PLL parameters matching those > rates. > > We could potentially add some more leeway for displays like yours that > aren't actually HDMI (as it doesn't seem to have a standard HDMI > resolution). But that's more of a last resort option, as it may > introduce other problems for displays that aren't as tolerant with > their input rates. Remember the mode_valid call is used to filter modes > that aren't compatible with the source, so for a display with multiple > modes allowing too much leeway may lead to incompatible modes not > getting tossed, in turn allowing userspace to set a mode that the > display may not like due to too much rate deviation, instead of only > presenting a list of valid modes. This again would present the user > with a black-screen without warning situation. Ah, that's a very good point, if other modes are valid then we don't want to present modes that are less likely to work, we should only allow bigger variations if no other mode worked... I don't think we have this info at validation time though? I think that Adam's suggestion of making this more dynamic would be great, if we can just generate finer frequencies for a reasonable range then it wouldn't be a problem to limit the check to 0.5%. Short of something really dynamic I can add a value for our particular display based on what I've seen above (just pick a couple of points along the lines for the two values I understood and whatever value neighbors have for the rest & check with a scope it's somewhat close), but I honestly would rather not get too far down this hole, we can't cover all the quirky hardwares that exist manually... Cheers, -- Dominique