From: Marek Vasut <marex@denx.de>
To: Alexander Stein <alexander.stein@ew.tq-group.com>
Cc: linux-arm-kernel@lists.infradead.org,
Conor Dooley <conor+dt@kernel.org>,
Fabio Estevam <festevam@gmail.com>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
NXP Linux Team <linux-imx@nxp.com>,
Pengutronix Kernel Team <kernel@pengutronix.de>,
Rob Herring <robh+dt@kernel.org>,
Sascha Hauer <s.hauer@pengutronix.de>,
Shawn Guo <shawnguo@kernel.org>,
devicetree@vger.kernel.org
Subject: Re: [PATCH] arm64: dts: imx8mp: Add TC9595 bridge on DH electronics i.MX8M Plus DHCOM
Date: Wed, 24 May 2023 12:37:50 +0200 [thread overview]
Message-ID: <75c45018-fae3-aa9d-db5d-7d378f69b53c@denx.de> (raw)
In-Reply-To: <1953702.usQuhbGJ8B@steina-w>
On 5/24/23 12:24, Alexander Stein wrote:
Hi,
>>> Looking at the AUX_CH+/- signals, I can see the native aux request and the
>>> (presumable) correct answer (DP_DPCD_REV register) from the display. But
>>> for some reason the bridge runs into a aux timeout.
>>> I can see in the DP0_AUXSTATUS register the bus gets busy (0x1) after
>>> starting transfer. But after the tc_aux_wait_busy() call DP0_AUXSTATUS
>>> his indicating a timeout and sync error (0x310002).
>>> When changing the "Aux Bit Period Calculator Threshold" to 5 (register
>>> AUXCFG1), the sync error is gone, but the timeout still happens.
>>>
>>> The frequency used from the display is ~1MHz, which should be okay. So on
>>> the electrical side all seems okay, but the native aux transfer don't
>>> work.
>> I recall DPCD read timeouts, but those were usually triggered by either
>> bad clock or wiring problems (the devkit wiring I used was horrible at
>> the beginning) from what I can recall.
>
> bad clock in the sense of badly configured or bad xtal hardware?
As in, the xtal clock drives the internal PLLs and if those are
misconfigured for whatever reason, the chip can misbehave. You might
want to double-check the clock routing chapter in the toshiba bridge
datasheet and matching registers.
Have you tried forcing the chip into 1.62G (instead of 2.7G) operation
and into 1-lane DP instead of 2-lane DP mode ? Does that make any
difference ?
> As the bridge
> and the xtal is on the same mainboard, for now, I ignore wirings.
OK
next prev parent reply other threads:[~2023-05-24 10:38 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-15 16:24 [PATCH] arm64: dts: imx8mp: Add TC9595 bridge on DH electronics i.MX8M Plus DHCOM Marek Vasut
2023-05-23 11:17 ` Alexander Stein
2023-05-23 13:10 ` Marek Vasut
2023-05-24 6:49 ` Alexander Stein
2023-05-24 9:28 ` Marek Vasut
2023-05-24 10:24 ` Alexander Stein
2023-05-24 10:37 ` Marek Vasut [this message]
2023-05-26 12:52 ` Alexander Stein
2023-05-27 8:35 ` Shawn Guo
2023-05-27 10:19 ` Marek Vasut
2023-05-27 10:47 ` Shawn Guo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=75c45018-fae3-aa9d-db5d-7d378f69b53c@denx.de \
--to=marex@denx.de \
--cc=alexander.stein@ew.tq-group.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=festevam@gmail.com \
--cc=kernel@pengutronix.de \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-imx@nxp.com \
--cc=robh+dt@kernel.org \
--cc=s.hauer@pengutronix.de \
--cc=shawnguo@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).