From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f45.google.com (mail-ej1-f45.google.com [209.85.218.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 69B6F2BD015 for ; Mon, 24 Nov 2025 16:44:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764002665; cv=none; b=Acun6WJNDlAn0R4u0MbgVGsHx8+nh+g/yWnnkDG01uHoMERWfgVP8zjWbS/jL3freV4zdajEKiiDNj0HNOja8ArmVRt4ZtgoZu0AUjIUwpqcaJYQuPLKNgfK3rgF1auTYIpoI+mehR8w8C+NalOHuFrKAjglufkBcIOoxVzvhZ0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764002665; c=relaxed/simple; bh=b+d1kJPKfIvOT871IRGDTMP/h66VstUuIxiBl6bMhxc=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=JiML9iL1UiGf3zPuJDEFXWIPq6OnqCX0H6kYc9zOZ3xD3Ga4UFwjSK7vIBD9B6oWWt1Mss8KA4I2lz3N8PV3P+PJjvQe0oI6ioKlWD6/cm1qMYVqO4OJDVkSmPK4LpulnAXU8GsvGmH29gNZHIvqNei3vdrsow7nglecZsAUyGI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=Yhiu0vq/; arc=none smtp.client-ip=209.85.218.45 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Yhiu0vq/" Received: by mail-ej1-f45.google.com with SMTP id a640c23a62f3a-b72cbc24637so756349066b.0 for ; Mon, 24 Nov 2025 08:44:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764002661; x=1764607461; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=Y1qbvHz+aNkaALCeB6YuPy34i5js9SQOa33eGsK28Bk=; b=Yhiu0vq/Ykv7Pf3iksGAjKD84aYI8uQXKNyeaAqdky4ckB0eI2j3hSGqXdje+uU8SJ ZhajckwswF9FAE7TylhDOLSvrB4QZjvHN36tqriZNOfudsI1MnhZaWHV3dC6usBW+xEd WXhZCg4zBnl6VZJV8vyaBuQDOUpyGEKCyCMl/zwR0ecH//FCSdAVsZucKMhHDPeCyENY 7yqcqJKM2t77jTIPlmArcIqasrmfFPkF5Wam1f6VgKhD1rIgkXflDgoMWUB+H4vhVcOA z9FpohtUzv1Cskkn0gpr75R89BtI/gmCqF7Tzywer2W8hwAb2cKlAlzYxzhBqg25r9q9 2DLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764002661; x=1764607461; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Y1qbvHz+aNkaALCeB6YuPy34i5js9SQOa33eGsK28Bk=; b=ZQ02XNL8Qyz4eOhs8+uocPB7Ca5wVXjJyFDVxxsirn209NS7fUtF3FLvArIpU2U2ax tQU32WKU4daXL7hA+QgPsCk5QLFmBKCrzd2xk54kzC/yonLpTK8btSxmuQmlK39GPZg2 ZOJnW3wdt5S6ArHFOzH4eLk0paoP/bHaX6s1ia7ZXZ8WGCLANNxIcx9VDuGqSIkmN1dS 1B5PQvzU2SU9nQfAyHXW6lmw1n4WUT6pCY7IJqYXs49hHpLfUsymFr2Q4GP7jeMz4HBH Y7x4skWqQKGYW4QZJZ1SqH36+mBlP8AHDfspgCqBbmjcrhB1YP1ieVx1aFfBDeV3LbrV H4vw== X-Forwarded-Encrypted: i=1; AJvYcCVYIzhodWBwVm+PhV1uP8sSLXrnvYjVcPsn7SL44c9AC7W3nfsrhXDxJAmxAmNolfEgKihi0zugU43jkwg=@vger.kernel.org X-Gm-Message-State: AOJu0YxZPrts04bSV621vLBg26QGxpPsP13S+O64yGYqHfI02xhP08Yd 4xzOhrhg2dOPTQfZFo5urpZLD7diKc8O+MQYpax+yqgaxFzgHc41ZSFr X-Gm-Gg: ASbGncsfRP+W/ytGnncHCWN7i3qKG3KXI+x/yTA8g+fExkGl7ETyq3B5NU0Drc4ikI4 Q04zQDWAXk7fC7thhGfZm2QSCiBSo1ZPeJPa9LZq+46krRzyTvPZwVLXeplz/Uk20XC2Zn/C81N TQOkqWCQzW0/plII/4oow2L64CG+yjS6L9biCeuLiESeIKRjZqyog1ZMTwkhB1W7wxTxuzyfm8y UjDy3YLxWJDTMnOfoqYck4TbDXlBpN7OhudsjKy6hL6kbvRt8L8xVhZOXgaFCgJEB9Mne5//Lwr 4xuRhNiivQ2PwV4fLus0Ty7uqW3gGqquHDFIH7nvRaJJTSTC/XC6sgeY5LKs4LRu/ywwVFc4IOL 0SrXcNUut1YKBPDgfLUPw2Al+Go4UHGUAlocF6BKC21UyqwlYAkGPv3OByLoVp6ZrD9ehI5Uevk CMU3CpJvz415/Lj1pLas/nAN/JA/uL+hq5Yh5avgJB464WwxZx6dt1al7o7di2hH4= X-Google-Smtp-Source: AGHT+IF85wAitfiRyvXPAO0XMhtM7CwIOTaHsc/rcaYl6Oe0F21NZ/v0xt1HI+HqOTipz1bfL2STQQ== X-Received: by 2002:a17:907:1b02:b0:b40:b54d:e687 with SMTP id a640c23a62f3a-b7671acc2d5mr1367662866b.47.1764002660407; Mon, 24 Nov 2025 08:44:20 -0800 (PST) Received: from ?IPV6:2001:b07:aac:705d:9f97:b617:31ec:75d6? ([2001:b07:aac:705d:9f97:b617:31ec:75d6]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b7654cdd5bfsm1357742666b.9.2025.11.24.08.44.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 24 Nov 2025 08:44:19 -0800 (PST) Message-ID: Date: Mon, 24 Nov 2025 17:44:18 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [REGRESSION] TI SN65DSI83 is being reset making display to blink On/Off To: Luca Ceresoli , Maxime Ripard Cc: Herve Codina , Francesco Dolcini , Tomi Valkeinen , =?UTF-8?Q?Jo=C3=A3o_Paulo_Gon=C3=A7alves?= , Andrzej Hajda , Neil Armstrong , Robert Foss , Laurent Pinchart , Jonas Karlman , Jernej Skrabec , Maarten Lankhorst , Thomas Zimmermann , David Airlie , Simona Vetter , =?UTF-8?Q?Jo=C3=A3o_Paulo_Gon=C3=A7alves?= , "linux-kernel@vger.kernel.org" , "regressions@lists.linux.dev" , "thomas.petazzoni@bootlin.com" , Philippe Schenker References: <20251119085127.6e3e429e@bootlin.com> <20251119111221.GA18602@francesco-nb> <593e90d9-cf04-45a2-8172-98c441ec79f5@ideasonboard.com> <20251119122443.GA29208@francesco-nb> <20251119194023.6239d397@bootlin.com> <4e25291266d46777e84f22295b8f1094d8f682cc.camel@impulsing.ch> From: Emanuele Ghidoli Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 24/11/2025 15:12, Luca Ceresoli wrote: > Hello, > > sorry, a typo below. > > On Mon Nov 24, 2025 at 1:12 PM CET, Luca Ceresoli wrote: >> Hello João, Francesco, Maxime, Hervé, >> >> On Fri Nov 21, 2025 at 10:58 AM CET, Maxime Ripard wrote: >>> On Thu, Nov 20, 2025 at 09:50:27AM +0000, Philippe Schenker wrote: >>>> >>>> >>>> On Wed, 2025-11-19 at 19:40 +0100, Herve Codina wrote: >>>>> Hi Luca, Francesco, others >>>>> >>>>> On Wed, 19 Nov 2025 18:27:38 +0100 >>>>> "Luca Ceresoli" wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>> On Wed Nov 19, 2025 at 1:24 PM CET, Francesco Dolcini wrote: >>>>>> ... >>>>>>>> I might be mistaken, but I don't think the PLL will work if >>>>>>>> unlocked... >>>>>>>> But maybe the case is that it unlocks and lock again right >>>>>>>> afterwards. >>>>>>>>>> João, Francesco, on what hardware do you observe the >>>>>>>>>> problem? Which SoC? >>>>>>>>>> Which encoder, any previous bridges? >>>>>>>>> >>>>>>>>> Verdin AM62, TI AM62 SOC, arch/arm64/boot/dts/ti/k3-am62- >>>>>>>>> verdin.dtsi >>>>>>>>> >>>>>>>>> There is a DPI to DSI bridge in the module, tc358778, it has >>>>>>>>> a 25MHz >>>>>>>>> reference clock. >>>>>>>>> >>>>>>>>> TI AM62 DPI -> Toshiba TC358768 DSI -> TI SN65DSI83 -> >>>>>>>>> Display >>>>>>>>> >>>>>>>>> From a preliminary investigation this is a HW limitation, we >>>>>>>>> are not >>>>>>>>> able to generate a "good enough" DSI clock, see >>>>>>>>> tc358768_calc_pll() for >>>>>> >>>>>> Thanks Francesco for the feedback! >>>>>> >>>>>> I'm not sure I completely understand the issue described, but if >>>>>> the TI >>>>>> bridge requires a clock that cannot be provided by the hardware, >>>>>> then this >>>>>> actually looks like "a HW limitation" as you wrote, due to a HW >>>>>> integration >>>>>> limitation/bug/issue/whatever. In case this is confirmed, I think >>>>>> quirks >>>>>> are an appropriate tool to handle HW integration issues. >>>>>> >>>>>>>> I haven't studied the docs or done any testing, but I would >>>>>>>> think that >>>>>>>> it doesn't matter for the PLL even if the incoming DSI clock is >>>>>>>> a bit >>>>>>>> off, as long as it's continuous and stable. >>>>>>>> >>>>>>>> My first thought was that the DSI is using non-continuous >>>>>>>> clock, but at >>>>>>>> least the driver has code to drop the >>>>>>>> MIPI_DSI_CLOCK_NON_CONTINUOUS flag. >>>>>>>> >>>>>>>>> the actual code implementation of it, I believe that the >>>>>>>>> datasheet is >>>>>>>>> not available without NDA. >>>>>>>>> >>>>>>>>> Maybe the ugly hack "works-without-pll" is the way to work? >>>>>>>>> It will >>>>>>>>> require a DT change, but this seems doable. >>>>>>>> >>>>>>>> Revert is easier than adding new hacky DT properties... At >>>>>>>> least until >>>>>>>> the problem is understood. >>>>>>>> >>>>>>>>> Please note that this is the outcome of a short investigation >>>>>>>>> done >>>>>>>>> yesterday afternoon, so maybe I am overlooking something, >>>>>>>>> unfortunately >>>>>>>>> I do not have the bandwidth to work on it more this week. >>>>>>>>> >>>>>>>>>> Which clock rates? >>>>>>>>> 71100000 >>>>>>>> It would be a good test to try out with a few different >>>>>>>> clocks. >>>>>>> >>>>>>> 50 MHz works, for example. >>>>>>> >>>>>>> It seems that the issue exists when the actual display clock is >>>>>>> different >>>>>>> from the dsi clock. And this can happen for the reason I >>>>>>> explained >>>>>>> before (the DSI clock is computed starting from this 25MHz >>>>>>> reference >>>>>>> clock). >>>>>> >>>>> >>>>> If there is no way to set a correct clock, I agree with Luca a quirk >>>>> should >>>>> be the best solution. >>>>> >>>>> For instance, in the dts: >>>>>   ti,pll_may_unlock_quirk; >>>> >>>> I followed the discussion only loosely. But I once worked on bringing >>>> up the SN65DSI83 and from what I can remember is that there was a >>>> frequency range of the input clock where the PLL of SN65DSI83 just did >>>> not lock at all. >>>> >>>> I couldn't explain what was happening since the clock I fed was within >>>> the limits of the documentation I had. >>>> >>>> What I ultimately did was to just choose a clock that works. Given that >>>> experience I'm not sure about adding quirks on TI side. >>>> >>>> But anyway I'm not very familiar with the topic and it's a long time >>>> since I worked on it. Just wanted to point out this experience I had, >>>> maybe it helps. >>> >>> If the frequency is predictable, can we disable the error recovery if we >>> know we programmed the bridge in (one of) the affected range? >> >> This looks like the best solution in principle. However I'm not sure the >> ti-sn65dsi83 driver knows the exact clock it will receive, I suspect it is >> only known to the DSI host and there is an API for the DSI device to obtain > ^^^^^^^^ > there isn't > >> it from the DSI host. >> >> I'd be happy to be proven wrong though, and that the above idea can work. >> >> In case it doesn't we should reconsider the quirk. But as Maxime pointed >> out in another reply the quirk property in DT is not doable for backwards >> compatibility. Other options that have come to mind to use the quirk: >> >> * quirk based on the machine: ti-sn65dsi83 driver enabled the quirk >> if (of_machine_is_compatible("toradex,...")) >> * opt-out quirk instead of opt-in: ti-sn65dsi83 driver enabled the quirk >> if a DT property is absent, e.g. 'ti,pll-locking-capable' or similar to >> say "this hardware is able to provide a correct clock" >> >> Luca >> >> -- >> Luca Ceresoli, Bootlin >> Embedded Linux and Kernel engineering >> https://bootlin.com > > > > > -- > Luca Ceresoli, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com Hi, I'm debugging the RGB -> tc358778 -> sn65dsi84 pipeline Some observations: - If I avoid resetting the pipeline and only clear the status bit, the PLL unlock flag immediately comes back. Despite this, the display keeps working fine and the sn65dsi84 appears functional even when the PLL is reported as unlocked. - There’s no clear frequency boundary: working: 50000000, 68750000, 72750000, 75000000 not working: 69750000, 71100000, 72500000 - The tc358778 is configured for continuous-clock DSI. - I cannot measure the DSI clock directly, but the parallel RGB clock is stable. So far I haven’t found a rule that clearly explain why certain frequency are without problems while some other generate this issue. I'm struggling around the input clock frequency and the one generated by tc358778 using its PLL, and trying to find out how it is possible that the side effect is a not locked PLL on the sn65dsi84. I could run additional tests or gather more data if useful. Thanks, Emanuele