All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heiko Stuebner <heiko@sntech.de>
To: Brian Norris <briannorris@chromium.org>
Cc: devicetree@vger.kernel.org, hl <hl@rock-chips.com>,
	"open list:ARM/Rockchip SoC..."
	<linux-rockchip@lists.infradead.org>,
	David Airlie <airlied@linux.ie>,
	Doug Anderson <dianders@chromium.org>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	dri-devel@lists.freedesktop.org, Chris Zhong <zyw@rock-chips.com>,
	Daniel Vetter <daniel.vetter@intel.com>,
	Kishon Vijay Abraham I <kishon@ti.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v5 4/4] drm/rockchip: support dp training outside dp firmware
Date: Fri, 18 May 2018 10:52:17 +0200	[thread overview]
Message-ID: <11928313.3EhRqhFFHB@phil> (raw)
In-Reply-To: <CA+ASDXN2LT6FcX_2-MM=Qu7cZOHwVK3+2rGDLGcC1SnY3BJaSw@mail.gmail.com>

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.


Heiko


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: multiple messages have this Message-ID (diff)
From: heiko@sntech.de (Heiko Stuebner)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v5 4/4] drm/rockchip: support dp training outside dp firmware
Date: Fri, 18 May 2018 10:52:17 +0200	[thread overview]
Message-ID: <11928313.3EhRqhFFHB@phil> (raw)
In-Reply-To: <CA+ASDXN2LT6FcX_2-MM=Qu7cZOHwVK3+2rGDLGcC1SnY3BJaSw@mail.gmail.com>

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.


Heiko

WARNING: multiple messages have this Message-ID (diff)
From: Heiko Stuebner <heiko@sntech.de>
To: Brian Norris <briannorris@chromium.org>
Cc: hl <hl@rock-chips.com>, Sean Paul <seanpaul@chromium.org>,
	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 10:52:17 +0200	[thread overview]
Message-ID: <11928313.3EhRqhFFHB@phil> (raw)
In-Reply-To: <CA+ASDXN2LT6FcX_2-MM=Qu7cZOHwVK3+2rGDLGcC1SnY3BJaSw@mail.gmail.com>

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.


Heiko

  reply	other threads:[~2018-05-18  8:52 UTC|newest]

Thread overview: 34+ 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 ` 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-17  9:17   ` Lin Huang
2018-05-18 16:24   ` Heiko Stuebner
2018-05-18 16:24     ` Heiko Stuebner
2018-05-18 16:24     ` Heiko Stuebner
2018-05-18 16:41   ` Rob Herring
2018-05-18 16:41     ` Rob Herring
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-17  9:17   ` Lin Huang
2018-05-18 16:33   ` Heiko Stuebner
2018-05-18 16:33     ` Heiko Stuebner
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  9:18   ` Lin Huang
2018-05-17 13:51   ` Sean Paul
2018-05-17 13:51     ` Sean Paul
2018-05-17 13:51     ` Sean Paul
2018-05-18  1:41     ` hl
2018-05-18  1:41       ` hl
2018-05-18  1:45       ` Brian Norris
2018-05-18  1:45         ` Brian Norris
2018-05-18  1:45         ` Brian Norris
2018-05-18  8:52         ` Heiko Stuebner [this message]
2018-05-18  8:52           ` Heiko Stuebner
2018-05-18  8:52           ` Heiko Stuebner
2018-05-18 15:36           ` Sean Paul
2018-05-18 15:36             ` Sean Paul
2018-05-18 15:36             ` Sean Paul
2018-05-18 16:35             ` Heiko Stuebner
2018-05-18 16:35               ` Heiko Stuebner
2018-05-18 16:35               ` Heiko Stuebner

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=11928313.3EhRqhFFHB@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=hl@rock-chips.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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.