Skip to content

L
linux
Switch branch/tag
  1. 23 Oct, 2017 18 commits
  3. 18 Oct, 2017 1 commit
  5. 03 Oct, 2017 5 commits
  7. 26 Sep, 2017 7 commits
    • Douglas Anderson's avatar
      phy: rockchip-typec: Don't set the aux voltage swing to 400 mV · 26e03d80
      Douglas Anderson authored 
      On rk3399-gru-kevin there are some cases where we're seeing AUX CH
failures when trying to do DisplayPort over type C.  Problems are
intermittent and don't reproduce all the time.  Problems are often
bursty and failures persist for several seconds before going away.
The failure case I focused on is:
* A particular type C to HDMI adapter.
* One orientation (flip mode) of that adapter.
* Easier to see failures when something is plugged into the _other
  type C port at the same time.
* Problems reproduce on both type C ports (left and right side).

Ironically problems also stop reproducing when I solder wires onto the
AUX CH signals on a port (even if no scope is connected to the
signals).  In this case, problems only stop reproducing on the port
with the wires connected.

From the above it appears that something about the signaling on the
aux channel is marginal and any slight differences can bring us over
the edge to failure.

It turns out that we can fix our problems by just increasing the
voltage swing of the AUX CH, giving us a bunch of extra margin.  In DP
up to version 1.2 the voltage swing on the aux channel was specced as
.29 V to 1.38 V.  In DP version 1.3 the aux channel voltage was
tightened to be between .29 V and .40 V, but it clarifies that it
really only needs the lower voltage when operating at the highest
speed (HBR3 mode).  So right now we are trying to use a voltage that
technically should be valid for all versions of the spec (including
version 1.3 when transmitting at HBR3).  That would be great to do if
it worked reliably.  ...but it doesn't seem to.

It turns out that if you continue to read through the DP part of the
rk3399 TRM and other parts of the type C PHY spec you'll find out that
while the rk3399 does support DP 1.3, it doesn't support HBR3.  The
docs specifically say "RBR, HBR and HBR2 data rates only".  Thus there
is actually no requirement to support an AUX CH swing of .4 V.

Even if there is no actual requirement to support the tighter voltage
swing, one could possibly argue that we should support it anyway.  The
DP spec clarifies that the lower voltage on the AUX CH will reduce
cross talk in some cases and that seems like it could be beneficial
even at the lower bit rates.  At the moment, though, we are seeing
problems with the AUX CH and not on the other lines.  Also, checking
another known working and similar laptop shows that the other laptop
runs the AUX channel at a higher voltage.

Other notes:
* Looking at measurements done on the AUX CH we weren't actually
  compliant with the DP 1.3 spec anyway.  AUX CH peek-to-peek voltage
  was measured on rk3399-gru-kevin as .466 V which is > .4 V.
* With this new patch the AUX channel isn't actually 1.0 V, but it has
  been confirmed that the signal is better and has more margin.  Eye
  diagram passes.
* If someone were truly an expert in the Type C PHY and in DisplayPort
  signaling they might be able to make things work and keep the
  voltage at < .4 V.  The Type C PHY seems to have a plethora of
  tuning knobs that could almost certainly improve the signal
  integrity.  Some of these things (like enabling tx_fcm_full_margin)
  even seem to fix my problems.  However, lacking expertise I can't
  say whether this is a better or worse solution.  Tightening signals
  to give cleaner waveforms can often have adverse affects, like
  increasing EMI or adding noise to other signals.  I'd rather not
  tune things like this without a healthy application of expertise
  that I don't have.
Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
Signed-off-by: default avatarKishon Vijay Abraham I <kishon@ti.com>
      26e03d80
    • Douglas Anderson's avatar
      phy: rockchip-typec: Set the AUX channel flip state earlier · f98b7438
      Douglas Anderson authored 
      On some DP monitors we found that setting the wrong flip state on the
AUX channel could cause the monitor to stop asserting HotPlug Detect
(HPD).  Setting the right flip state caused these monitors to start
asserting HotPlug Detect again.

Here's what we believe was happening:
* We'd plug in the monitor and we'd see HPD assert
* We'd quickly see HPD deassert
* The kernel would try to init the type C PHY but would init it in USB
  mode (because there was a peripheral there but no HPD)
* Because the kernel never set the flip mode properly we'd never see
  the HPD come back.

With this change, we'll still see HPD disappear (we don't think
there's anything we can do about that), but then it will come back.

Overall we can say that it's sane to set the AUX channel flip state
even when HPD is not asserted.

NOTE: to make this change possible, I needed to do a bit of cleanup to
the tcphy_dp_aux_calibration() function so that it doesn't ever
clobber the FLIP state.  This made it very obvious that a line of code
documented as "setting bit 12" also did a bunch of other magic,
undocumented stuff.  For now I'll just break out the bits and add a
comment that this is black magic and we'll try to document
tcphy_dp_aux_calibration() better in a future CL.

ALSO NOTE: the old function used to write a bunch of hardcoded
values in _some_ cases instead of doing a read-modify-write.  One
could possibly assert that these could have had (beneficial) side
effects and thus with this new code (which always does
read-modify-write) we could have a bug.  We shouldn't need to worry,
though, since in the old code tcphy_dp_aux_calibration() was always
called following the de-assertion of "reset" the the type C PHY.
...so the type C PHY was always in default state.  TX_ANA_CTRL_REG_1
is documented to be 0x0 after reset.  This was also confirmed by
printk.
Suggested-by: default avatarShawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: default avatarChris Zhong <zyw@rock-chips.com>
Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
Signed-off-by: default avatarKishon Vijay Abraham I <kishon@ti.com>
      f98b7438
    • Dan Carpenter's avatar
      phy: mvebu-cp110: checking for NULL instead of IS_ERR() · c1c7acac
      Dan Carpenter authored 
      devm_ioremap_resource() never returns NULL, it only returns error
pointers so this test needs to be changed.

Fixes: d0438bd6 ("phy: add the mvebu cp110 comphy driver")
Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: default avatarKishon Vijay Abraham I <kishon@ti.com>
      c1c7acac
    • Antoine Tenart's avatar
      phy: mvebu-cp110-comphy: explicitly set the pipe selector · 17fb745d
      Antoine Tenart authored 
      The pipe selector is used to select some modes (such as USB or PCIe).
Otherwise it must be set to 0 (or "unconnected"). This patch does this
to ensure it is not set to an incompatible value when using the
supported modes (SGMII, 10GKR).
Signed-off-by: default avatarAntoine Tenart <antoine.tenart@free-electrons.com>
Signed-off-by: default avatarKishon Vijay Abraham I <kishon@ti.com>
      17fb745d
    • Antoine Tenart's avatar
      phy: mvebu-cp110-comphy: fix mux error check · caef3e0b
      Antoine Tenart authored 
      The mux value is retrieved from the mvebu_comphy_get_mux() function
which returns an int. In mvebu_comphy_power_on() this int is stored to a
u32 and a check is made to ensure it's not negative. Which is wrong.
This fixes it.

Fixes: d0438bd6 ("phy: add the mvebu cp110 comphy driver")
Signed-off-by: default avatarAntoine Tenart <antoine.tenart@free-electrons.com>
Signed-off-by: default avatarKishon Vijay Abraham I <kishon@ti.com>
      caef3e0b
    • Chunfeng Yun's avatar
      phy: phy-mtk-tphy: fix NULL point of chip bank · 554a56fc
      Chunfeng Yun authored 
      Chip bank of version-1 is initialized as NULL, but it's used
by pcie_phy_instance_power_on/off(), so assign it a right
address.
Signed-off-by: default avatarChunfeng Yun <chunfeng.yun@mediatek.com>
Signed-off-by: default avatarKishon Vijay Abraham I <kishon@ti.com>
      554a56fc
    • Arvind Yadav's avatar
      phy: tegra: Handle return value of kasprintf · 1df79cb3
      Arvind Yadav authored 
      kasprintf() can fail and it's return value must be checked.
Signed-off-by: default avatarArvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: default avatarKishon Vijay Abraham I <kishon@ti.com>
      1df79cb3
  9. 16 Sep, 2017 9 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7