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 DB408C25B4E for ; Fri, 20 Jan 2023 19:11:53 +0000 (UTC) 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=r9W8fbdNtffqzT9uc+hPimoY2QaT3JENjVbaq529jEQ=; b=sKaEHWz5f/ePp1 pi8HLHZ5wp6ohnrZw7OGCh8BF5or7emsIOSFR7dFvuY5IFOfw6LaQCdZHBF3PHZL1qOMcDHEg4gTi 3Y3vMn17sSY5JZ5IQP+xGp+dS7R73jq4sNECIRi4N7RqQYzeQKr8h0KENUyZcq2s/5w2k8g4D55qL K8rOhUAspEbDAdEazLF6RqVDwUzwZh2IRZjNiBtmuUt3p69VtPbz0oXv8HT1cKNxp3jw5CawZg6c9 ZTRCWms87KyG/q1iRyzpgcjnf+2RY3AFA9aaqBs8oQeSDIf1PSBjVZCm17BlWjlMr6UJhxCnkX+nT T9vMwHRIXPhy9vxHhftw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pIwmV-00C0TA-00; Fri, 20 Jan 2023 19:10:31 +0000 Received: from new1-smtp.messagingengine.com ([66.111.4.221]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pIwmN-00C0NM-5J for linux-arm-kernel@lists.infradead.org; Fri, 20 Jan 2023 19:10:26 +0000 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailnew.nyi.internal (Postfix) with ESMTP id 7A66F581F44; Fri, 20 Jan 2023 14:10:16 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Fri, 20 Jan 2023 14:10:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cerno.tech; h=cc :cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm1; t=1674241816; x= 1674249016; bh=cNlI+KksvzptdXxI5ZVjZOHaj/EyWoi9wHcmf+pWjtc=; b=a WDTKvVN630dAa5rdSPz5O7/evgDoc4cu+i+0fZWz7TqFRvrX0gS1JwcuMapyu5xi kqQeVsbyRfkALu5MP2CxOcUeoliT7QCBXG29GaH3ueeNkKXP1GbtP81tkrbLTTNf pbIjbDJzsi4R6GEgBqLZUInJrPiach47gvSglUOUQFn+ZaJYlLbcT88Ga2Y4fJWz pdtTOb4DuCW/Ww0o5MXncRJ6n+oQY/FpJO6yDzb4Yc2DWJNM0E8Vbm4YYL6pEI24 XFk+3xTXD7tA9V54wCqzsmCZcAurxfasFDMR02e6ZrcqyFEg6IiO/1CS250lRQBL 0zFxrbqa/ryssfTFDLbKA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1674241816; x= 1674249016; bh=cNlI+KksvzptdXxI5ZVjZOHaj/EyWoi9wHcmf+pWjtc=; b=N V06uTaOXRmY5n2IPNNBx60U9Q130vUJaVsiP5H4oXqDOaqh+PCBRVvh+ZsTkjCZq oFrcqqBWPxaUTAo9shy35U7wlaxY2VA4LWdUdSA6rvEjvh9pVfshPx3xWjKq3F+K fml9Uoa3+RfLwgKkQalgrYr9FYlMNoTmWDEVQeX5lJDYeGmAFuWoV+g5RbfdGi0c GklhRqYUU4PY64RELAhvo6AdvvPFNBgluRBQIUV7ABu4y6VauVvyQdHsjzKwTR4R vfhlKLSc0WGhVBQY53Ak7luvSOEMO7flWX0Pm7gKvmgsTQBPyrZXWFdI5rSEqip9 uIPQmLFehli+mLe0pFdMA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudduvddguddvgecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvvefukfhfgggtugfgjgesthhqredttddtvdenucfhrhhomhepofgr gihimhgvucftihhprghrugcuoehmrgigihhmvgestggvrhhnohdrthgvtghhqeenucggtf frrghtthgvrhhnpefhuddvjeelhfetteffvdfgueehvdeugefgteehiefhkeetffdttdei ffdvtdeuheenucffohhmrghinhepghhithhhuhgsrdgtohhmpdhfrhgvvgguvghskhhtoh hprdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhho mhepmhgrgihimhgvsegtvghrnhhordhtvggthh X-ME-Proxy: Feedback-ID: i8771445c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 20 Jan 2023 14:10:14 -0500 (EST) Date: Fri, 20 Jan 2023 20:10:11 +0100 From: Maxime Ripard To: Marek Vasut Cc: Alexander Stein , Adam Ford , Andrzej Hajda , Inki Dae , Marek Szyprowski , Joonyoung Shim , Seung-Woo Kim , Kyungmin Park , Frieder Schrempf , Fancy Fang , Tim Harvey , Michael Nazzareno Trimarchi , Neil Armstrong , Robert Foss , Laurent Pinchart , Tommaso Merciai , "dri-devel@lists.freedesktop.org" , "linux-samsung-soc@vger.kernel.org" , Matteo Lisi , NXP Linux Team , linux-amarula , "linux-arm-kernel@lists.infradead.org" , Jagan Teki Subject: Re: [PATCH v10 00/18] drm: Add Samsung MIPI DSIM bridge Message-ID: <20230120191011.4ehxgxbpyvliye63@houat> References: <449d03be-226f-9a90-aff3-8afee68c346d@denx.de> <4207863.mogB4TqSGs@steina-w> <8172fbfd-a1b9-bfca-983d-b97a1f9560da@denx.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <8172fbfd-a1b9-bfca-983d-b97a1f9560da@denx.de> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230120_111023_598287_D860CC79 X-CRM114-Status: GOOD ( 50.30 ) 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="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Jan 04, 2023 at 04:08:47PM +0100, Marek Vasut wrote: > On 1/3/23 11:59, Alexander Stein wrote: > > Hi, > > > > Am Sonntag, 18. Dezember 2022, 23:28:20 CET schrieb Marek Vasut: > > > On 12/18/22 23:24, Adam Ford wrote: > > > > On Sat, Dec 17, 2022 at 10:33 PM Marek Vasut wrote: > > > > > On 12/18/22 05:23, Adam Ford wrote: > > > > > > On Sat, Dec 17, 2022 at 5:56 PM Marek Vasut wrote: > > > > > > > On 12/16/22 14:25, Alexander Stein wrote: > > > > > > > Hi, > > > > > > > > > > > > > > [...] > > > > > > > > > > > > > > > Oh, nice, thanks for the pointer. When setting > > > > > > > > > > > > > > > > > samsung,burst-clock-frequency = <668250000>; > > > > > > > > > > > > > > > > in imx8mm.dtsi > > > > > > > > I get a non-flickering display using 4 lanes. Although admittedly this > > > > > > > > is just random guessing. I'm not sure which clock exactly has to be > > > > > > > > in the range CHA_DSI_CLK_RANGE is configured to. With 4 lanes > > > > > > > > SN65DSI84 is configured for>>>>> > > > > > > > > 205-210 MHz (0x29), while I get these PLL PMS settings on DSIM: > > > > > > > > > samsung-dsim 32e10000.dsi: PLL freq 668250000, (p 4, m 99, s 0) > > > > > > > > > samsung-dsim 32e10000.dsi: hs_clk = 668250000, byte_clk = 83531250, > > > > > > > > > esc_clk > > > > > > > > > > > > > > > > = 16706250 > > > > > > > > > > > > > > If I recall it right, minimum PLL frequency is: > > > > > > > > > > > > > > fPMS=1.2*width*height*bpp*fps=1.2*800*480*24*60=663.5 MHz > > > > > > > > > > > > > > the link frequency is then > > > > > > > > > > > > > > fHS=fPMS/lanes/2=82.9 MHz (on the DDR clock lane) > > > > > > > > > > > > > > So DSI83 should be in the range of 80..85 MHz input clock if I > > > > > > > calculate > > > > > > > this right. Can you check what is the value of mode->clock, the > > > > > > > mipi_dsi_panel_format_to_bpp() return value, ctx->dsi->lanes in dsi83 > > > > > > > sm65dsi83_get_dsi_range() ? > > > > > > > > > > > > > > > AFAICS DSIM bridge is configurung hs_clk, byte_clk and esc_clk just > > > > > > > > from DT > > > > > > > > properties, while SN65DSI84 is using display mode and number of lanes. > > > > > > > > > > > > > > > > Is it expected that the DSIM PLL frequencies are set in DT for a > > > > > > > > specific > > > > > > > > bridge/display setup? > > > > > > > > > > > > > > No, there should be negotiation between the host and bridge/panel, I > > > > > > > tried to propose two variants, but they were all rejected. > > > > > > > > > > > > For one of Jagan's previous revisions, I added some code to let the > > > > > > PHY auto adjust the frequencies instead of being fixed. NXP had this > > > > > > in their downstream kernel, but with this patch and another, I was > > > > > > able to set a variety of pixel clocks from my HDMI monitor and my > > > > > > DSI83. I haven't had time to re-base my work on Jagan's latest work, > > > > > > but you can link to the patch I did for the older stuff here: > > > > > > > > > > > > https://github.com/aford173/linux/commit/e845274b0f22ba3b24813ffd6bb3cb8 > > > > > > 8ab4b67e4 and > > > > > > https://github.com/aford173/linux/commit/3f90057eb608f96d106029ef6398134 > > > > > > 75241936f > > > > > > > > > > > > I've been traveling a lot lately, so I haven't had time to evaluate > > > > > > his series, but I hope to get something like those re-based once the > > > > > > DSI stuff has been accepted. > > > > > > > > > > I have these two attempts, both rejected: > > > > > > > > > > https://patchwork.freedesktop.org/patch/475207/ > > > > > https://patchwork.freedesktop.org/patch/496049/ > > > > > > > > I have some patches re-based to Jagan's latest branch. It doesn't > > > > impact any drivers other than the new samsung-dsim driver, and it > > > > doesn't touch any of the drm helper functions either. It adjusts hs > > > > clock based on the connected device. I am not sure what the impact > > > > will have on the attached Exynos devices, so I am expecting some > > > > iterations. Right now it's working with my DSI83 chip, but I need to > > > > get it working with my adv7535 part as well. On the older branch, I > > > > was able to sync the ad7535 with a variety of resolutions using > > > > different pixel clock rates. > > > > > > > > Once I get it working again with my adv7535 and cleaned up, I'll > > > > submit the patches to the drm group, and I'll CC you, Jagan and Marek > > > > Szyprowski with a reference to Jagan's series so people wanting to try > > > > it can apply it to his branch. > > > > > > The negotiation has to happen between the host and the bridge/panel, > > > otherwise you won't be able to support bridge/panel devices which > > > require specific clock rate on the DSI. Only the bridge/panel driver > > > knows about such requirement. > > > > AFAICS using Adam's patch the dynamic DPHY config is done in atomic_pre_enable > > callback. So at this point the negotiation has to be finished already. > > Wouldn't it be possible to setup 'dsi->format' within a atomic_check for > > samsung_dsim? But I don't know how you would get the expected clock frequency > > from the downward bridge. I have zero context there, so I'm not sure what proposals have been made already, but why isn't it possible to do it the other way around and make the bridge ask the upstream driver if it can provide the clock frequency the bridge require? It's pretty much how the common clock framework works too: you set the rate on the leaf clock, and it propagates upwards in your tree, adjusting for any constraint we have along the way. It does need to happen at atomic_check time though, otherwise it would be terrible for anyone attempting to use that driver. Maxime _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel