From: Heiko Stuebner <heiko@sntech.de>
To: Sean Paul <seanpaul@chromium.org>
Cc: Brian Norris <briannorris@chromium.org>, hl <hl@rock-chips.com>,
devicetree@vger.kernel.org, David Airlie <airlied@linux.ie>,
Enric Balletbo Serra <eballetbo@gmail.com>,
Doug Anderson <dianders@chromium.org>,
Jani Nikula <jani.nikula@linux.intel.com>,
Linux Kernel <linux-kernel@vger.kernel.org>,
"open list:ARM/Rockchip SoC..."
<linux-rockchip@lists.infradead.org>,
Rob Herring <robh+dt@kernel.org>,
dri-devel@lists.freedesktop.org, Chris Zhong <zyw@rock-chips.com>,
Daniel Vetter <daniel.vetter@intel.com>,
linux-arm-kernel@lists.infradead.org,
Kishon Vijay Abraham I <kishon@ti.com>
Subject: Re: [PATCH v5 4/4] drm/rockchip: support dp training outside dp firmware
Date: Fri, 18 May 2018 18:35:49 +0200 [thread overview]
Message-ID: <5918781.MvJIhHKAbg@phil> (raw)
In-Reply-To: <20180518153656.GK3373@art_vandelay>
Am Freitag, 18. Mai 2018, 17:36:56 CEST schrieb Sean Paul:
> On Fri, May 18, 2018 at 10:52:17AM +0200, Heiko Stuebner wrote:
> > Am Freitag, 18. Mai 2018, 03:45:46 CEST schrieb Brian Norris:
> > > On Thu, May 17, 2018 at 6:41 PM, hl <hl@rock-chips.com> wrote:
> > > > On Thursday, May 17, 2018 09:51 PM, Sean Paul wrote:
> > > >> On Thu, May 17, 2018 at 05:18:00PM +0800, Lin Huang wrote:
> > > >>> DP firmware uses fixed phy config values to do training, but some
> > > >>> boards need to adjust these values to fit for their unique hardware
> > > >>> design. So get phy config values from dts and use software link training
> > > >>> instead of relying on firmware, if software training fail, keep firmware
> > > >>> training as a fallback if sw training fails.
> > > >>>
> > > >>> Signed-off-by: Chris Zhong <zyw@rock-chips.com>
> > > >>> Signed-off-by: Lin Huang <hl@rock-chips.com>
> > > >>> ---
> > > >>> Changes in v2:
> > > >>> - update patch following Enric suggest
> > > >>> Changes in v3:
> > > >>> - use variable fw_training instead sw_training_success
> > > >>> - base on DP SPCE, if training fail use lower link rate to retry training
> > > >>> Changes in v4:
> > > >>> - improve cdn_dp_get_lower_link_rate() and cdn_dp_software_train_link() follow Sean suggest
> > > >>> Changes in v5:
> > > >>> - fix some whitespcae issue
> > > >>>
> > > >>> drivers/gpu/drm/rockchip/Makefile | 3 +-
> > > >>> drivers/gpu/drm/rockchip/cdn-dp-core.c | 24 +-
> > > >>> drivers/gpu/drm/rockchip/cdn-dp-core.h | 2 +
> > > >>> drivers/gpu/drm/rockchip/cdn-dp-link-training.c | 420 ++++++++++++++++++++++++
> > > >>> drivers/gpu/drm/rockchip/cdn-dp-reg.c | 31 +-
> > > >>> drivers/gpu/drm/rockchip/cdn-dp-reg.h | 38 ++-
> > > >>> 6 files changed, 505 insertions(+), 13 deletions(-)
> > > >>> create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-link-training.c
> > > >>>
> > > ...
> > > >>> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-link-training.c b/drivers/gpu/drm/rockchip/cdn-dp-link-training.c
> > > >>> new file mode 100644
> > > >>> index 0000000..73c3290
> > > >>> --- /dev/null
> > > >>> +++ b/drivers/gpu/drm/rockchip/cdn-dp-link-training.c
> > > >>> @@ -0,0 +1,420 @@
> > > >>> +// SPDX-License-Identifier: GPL-2.0
> > > >>> +/*
> > > >>> + * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
> > > >>> + * Author: Chris Zhong <zyw@rock-chips.com>
> > > >>> + */
> > > >>> +
> > > >>> +#include <linux/device.h>
> > > >>> +#include <linux/delay.h>
> > > >>> +#include <linux/phy/phy.h>
> > > >>> +#include <soc/rockchip/rockchip_phy_typec.h>
> > > >>> +
> > > >>> +#include "cdn-dp-core.h"
> > > >>> +#include "cdn-dp-reg.h"
> > > >>> +
> > > >>> +static void cdn_dp_set_signal_levels(struct cdn_dp_device *dp)
> > > >>> +{
> > > >>> + struct cdn_dp_port *port = dp->port[dp->active_port];
> > > >>> + struct rockchip_typec_phy *tcphy = phy_get_drvdata(port->phy);
> > > >>
> > > >> You ignored Brian's comment on the previous patch:
> > > >> This is still antithetical to the PHY framework; you're assuming that
> > > >> this is a particular type of PHY here.
> > > >>
> > > >> FWIW, the mediatek drm driver also assumes a certain PHY type. A quick grep of
> > > >> drivers/ shows that the only other non-phy/ driver using this function
> > > >> (pinctrl-tegra-xusb.c) also casts it.
> > > >>
> > > >> Sean
> > > >
> > > > Thanks Sean, except phy framework have new API to handle it, i have not
> > > > idea how to do it in a better way.
> > >
> > > Well, if Mediatek can do it for their MIPI and HDMI, then maybe we just do it...
> >
> > I'd think so too. This is in Rockchip-specific code so it will always be
> > possible to easily get the soc-type and thus phy-type, if that combination
> > really changes down the road.
> >
>
> So in the absence of a better solution, and with prior art,
>
> Reviewed-by: Sean Paul <seanpaul@chromium.org>
>
>
> We just need some eyes on the dt and phy changes in this set. Heiko, can you
> help out with that?
done, but both the binding + phy changes should also get Acks from
Rob (dt) and Kishon (phy). Especially as the binding change is a bit more
than a new simple property.
Heiko
prev parent reply other threads:[~2018-05-18 16:36 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-17 9:17 [PATCH v5 1/4] drm/rockchip: add transfer function for cdn-dp Lin Huang
2018-05-17 9:17 ` [PATCH v5 2/4] Documentation: bindings: add phy_config for Rockchip USB Type-C PHY Lin Huang
2018-05-18 16:24 ` Heiko Stuebner
2018-05-18 16:41 ` Rob Herring
2018-05-17 9:17 ` [PATCH v5 3/4] phy: rockchip-typec: support variable phy config value Lin Huang
2018-05-18 16:33 ` Heiko Stuebner
2018-05-17 9:18 ` [PATCH v5 4/4] drm/rockchip: support dp training outside dp firmware Lin Huang
2018-05-17 13:51 ` Sean Paul
2018-05-18 1:41 ` hl
2018-05-18 1:45 ` Brian Norris
2018-05-18 8:52 ` Heiko Stuebner
2018-05-18 15:36 ` Sean Paul
2018-05-18 16:35 ` Heiko Stuebner [this message]
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=5918781.MvJIhHKAbg@phil \
--to=heiko@sntech.de \
--cc=airlied@linux.ie \
--cc=briannorris@chromium.org \
--cc=daniel.vetter@intel.com \
--cc=devicetree@vger.kernel.org \
--cc=dianders@chromium.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=eballetbo@gmail.com \
--cc=hl@rock-chips.com \
--cc=jani.nikula@linux.intel.com \
--cc=kishon@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=robh+dt@kernel.org \
--cc=seanpaul@chromium.org \
--cc=zyw@rock-chips.com \
/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