From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3558B1CF2A3; Mon, 28 Oct 2024 18:19:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.70.183.197 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730139595; cv=none; b=lxIewszRX7VaBdQixqD5sXlzJWR8rHy7xawnmJBG9J2Es9UkzqvhEcHB3B3za+bhGQxzyxymv6gtunleX6b5TCiaUPLHfXHu6G6wHme+aWrAXbAKZb57ag5uLkWx2tRbHygdmaGAZ6lfBqPNVdIaeyk8XlQsbj2X62fVGmegsTM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730139595; c=relaxed/simple; bh=qqgKXSXOsxtg94W88L+CbsZDdVta0JNoA9jWPD/KOSE=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=t1A37F+qcUowaDhnZpDdQTgx9y65Ny/VPXSZLEhtvdOtPp7su241Ypa2eVIOkOSLWokEnH6KltAARMDifDmn7XfDWrAYuphvaSmmY6LSwEhPuRcwkR8hFEodtPf6cfss9jqBRuy3wAVhlmCz8NSlqc4JNZPJ1kJ/+bLGnWtO1zE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com; spf=pass smtp.mailfrom=bootlin.com; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b=nDF74+/0; arc=none smtp.client-ip=217.70.183.197 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bootlin.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b="nDF74+/0" Received: by mail.gandi.net (Postfix) with ESMTPSA id E565B1C0004; Mon, 28 Oct 2024 18:19:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1730139591; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=b/kO4kEXCHHF3kJ5Bu3ijehycRJX0SWC+3a8OLL3WQ8=; b=nDF74+/0gi1F49A5sbYDgWy8Q/KuHjQwDnQsNkE7mBITemNslObdEXWgXlD603+Umh48Hs glP6DmvnjHLdFFfyPigYgyFHxGMgE9kLTFW2i8oqrqEXae+CE6kLfsNOXECLKzWnHJwfrM 92hl2sMAfXuzi8qH9foB+qhB1RGT8MDTu0WdjcErJKWbFwz6zDqLTpIpZxfvUyNsn/2BlG qJNBBqbNfr1DqiYuu+biLD218A4EsBrOmJEVl5nhFhPLRKZgwlu9dhXVUeQ3y3iqSHW7IU 6W1OSHfOi836/w0GQ2M2RUKLCWk5K2slZqPiV7aJ9e+WV6AD92Mby8dq4TvL3g== Date: Mon, 28 Oct 2024 19:19:48 +0100 From: Herve Codina To: Marek Vasut Cc: Andrzej Hajda , Neil Armstrong , Robert Foss , Laurent Pinchart , Jonas Karlman , Jernej Skrabec , David Airlie , Simona Vetter , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Michael Walle , dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Luca Ceresoli , Thomas Petazzoni Subject: Re: [PATCH 2/2] drm: bridge: ti-sn65dsi83: Add error recovery mechanism Message-ID: <20241028191948.5fd1bd6d@bootlin.com> In-Reply-To: References: <20241024095539.1637280-1-herve.codina@bootlin.com> <20241024095539.1637280-3-herve.codina@bootlin.com> <78a09625-6bad-4fda-8ee5-92b8dd0de381@denx.de> <20241028090220.1fd803ff@bootlin.com> <16edb769-a608-4b6a-9391-a63a69df8c8d@denx.de> <20241028145259.5d520445@bootlin.com> Organization: Bootlin X-Mailer: Claws Mail 4.3.0 (GTK 3.24.43; x86_64-redhat-linux-gnu) Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-GND-Sasl: herve.codina@bootlin.com On Mon, 28 Oct 2024 15:47:25 +0100 Marek Vasut wrote: > On 10/28/24 2:52 PM, Herve Codina wrote: > > Hi Marek, > > Hi, > > >>> On Sat, 26 Oct 2024 00:53:51 +0200 > >>> Marek Vasut wrote: > >>> > >>>> On 10/24/24 11:55 AM, Herve Codina wrote: > >>>>> In some cases observed during ESD tests, the TI SN65DSI83 cannot recover > >>>>> from errors by itself. A full restart of the bridge is needed in those > >>>>> cases to have the bridge output LVDS signals again. > >>>> > >>>> I have seen the bridge being flaky sometimes, do you have any more > >>>> details of what is going on when this irrecoverable error occurs ? > >>> > >>> The panel attached to the bridge goes and stays black. That's the behavior. > >>> A full reset brings the panel back displaying frames. > >> Is there some noticeable change in 0xe0/0xe1/0xe5 registers, esp. 0xe5, > >> do they indicate the error occurred somehow ? > > > > 0xe5 register can signal any DSI errors (depending on when the ESD affects > > the DSI bus) even PLL unlock bit was observed set but we didn't see any > > relationship between the bits set in 0xe5 register and the recoverable or > > unrecoverable behavior. > > > > Also, in some cases, reading the register was not even possible (i2c > > transaction nacked). > Oh, wow, I haven't seen that one before. But this is really useful > information, can you please add it into the commit message for V2 ? Yes, I will add this information in v2. Best regards, Hervé -- Hervé Codina, Bootlin Embedded Linux and Kernel engineering https://bootlin.com