[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ZxkgEjptmmHpQpfB@hovoldconsulting.com>
Date: Wed, 23 Oct 2024 18:10:58 +0200
From: Johan Hovold <johan@...nel.org>
To: Abel Vesa <abel.vesa@...aro.org>
Cc: Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>, linux-arm-msm@...r.kernel.org,
Bjorn Andersson <andersson@...nel.org>,
Konrad Dybcio <konradybcio@...nel.org>,
Rajendra Nayak <quic_rjendra@...cinc.com>,
Sibi Sankar <quic_sibis@...cinc.com>,
Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
Trilok Soni <quic_tsoni@...cinc.com>, linux-kernel@...r.kernel.org,
linux-usb@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH v2 2/2] usb: typec: Add support for Parade PS8830 Type-C
Retimer
On Wed, Oct 23, 2024 at 11:04:37AM +0300, Abel Vesa wrote:
> On 24-10-23 09:52:19, Johan Hovold wrote:
> > I'm talking about an I/O pin here, you must generally not drive those
> > high before powering on the IC.
> >
> > And AFAIU the same applies to clocks even though the risk of damage
> > there is lower.
>
> As I stated before, enabling (or rather preparing, from kernel's point
> of view) will definitely glitch due to PLL switcing (unless the mux is
> glitchless from design). And there is literally no risk of enabling or
> keeping a clock enabled even if the consumer is powered off.
That's a separate discussion from whether you should supply clocks to an
unpowered IC, and you can get around that by making sure the IC is held
in reset until the clock is stable.
What does the datasheet say about the XTALO_REFCLK_IN pin? What's the
max voltage specified as?
And since the machine we are currently working on do not using a crystal
oscillator here, do you need to configure the device to use a clock
instead somehow?
Is there any mention of the refclk in the power-on sequence?
Johan
Powered by blists - more mailing lists