All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Marek <jonathan@marek.ca>
To: Rob Clark <robdclark@gmail.com>,
	Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
	<devicetree@vger.kernel.org>, David Airlie <airlied@linux.ie>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	Abhinav Kumar <abhinavk@codeaurora.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Stephen Boyd <swboyd@chromium.org>,
	khsieh@codeaurora.org, Sean Paul <seanpaul@chromium.org>,
	Tanmay Shah <tanmay@codeaurora.org>,
	Daniel Vetter <daniel@ffwll.ch>,
	Vara Reddy <varar@codeaurora.org>,
	aravindh@codeaurora.org,
	freedreno <freedreno@lists.freedesktop.org>,
	Chandan Uddaraju <chandanu@codeaurora.org>
Subject: Re: [Freedreno] [PATCH v10 3/5] drm/msm/dp: add support for DP PLL driver
Date: Sat, 15 Aug 2020 17:21:49 -0400	[thread overview]
Message-ID: <1ea81fa2-1dc8-a0b9-aa32-3127e9354be2@marek.ca> (raw)
In-Reply-To: <CAF6AEGtcfXodN1_HSdTcH402FdwTk15Nt6p3F=QYeSRhTc+hqw@mail.gmail.com>

On 8/15/20 4:20 PM, Rob Clark wrote:
> On Fri, Aug 14, 2020 at 10:05 AM Dmitry Baryshkov
> <dmitry.baryshkov@linaro.org> wrote:
>>
>>
>> On 12/08/2020 07:42, Tanmay Shah wrote:
>>   > From: Chandan Uddaraju <chandanu@codeaurora.org>
>>   >
>>   > Add the needed DP PLL specific files to support
>>   > display port interface on msm targets.
>>
>> [skipped]
>>
>>   > diff --git a/drivers/gpu/drm/msm/dp/dp_pll_private.h
>> b/drivers/gpu/drm/msm/dp/dp_pll_private.h
>>   > new file mode 100644
>>   > index 000000000000..475ba6ed59ab
>>   > --- /dev/null
>>   > +++ b/drivers/gpu/drm/msm/dp/dp_pll_private.h
>>   > @@ -0,0 +1,98 @@
>>   > +/* SPDX-License-Identifier: GPL-2.0-only */
>>   > +/*
>>   > + * Copyright (c) 2016-2020, The Linux Foundation. All rights reserved.
>>   > + */
>>   > +
>>   > +#ifndef __DP_PLL_10NM_H
>>   > +#define __DP_PLL_10NM_H
>>   > +
>>   > +#include "dp_pll.h"
>>   > +#include "dp_reg.h"
>>   > +
>>   > +#define DP_VCO_HSCLK_RATE_1620MHZDIV1000    1620000UL
>>   > +#define DP_VCO_HSCLK_RATE_2700MHZDIV1000    2700000UL
>>   > +#define DP_VCO_HSCLK_RATE_5400MHZDIV1000    5400000UL
>>   > +#define DP_VCO_HSCLK_RATE_8100MHZDIV1000    8100000UL
>>   > +
>>   > +#define NUM_DP_CLOCKS_MAX            6
>>   > +
>>   > +#define DP_PHY_PLL_POLL_SLEEP_US        500
>>   > +#define DP_PHY_PLL_POLL_TIMEOUT_US        10000
>>   > +
>>   > +#define DP_VCO_RATE_8100MHZDIV1000        8100000UL
>>   > +#define DP_VCO_RATE_9720MHZDIV1000        9720000UL
>>   > +#define DP_VCO_RATE_10800MHZDIV1000        10800000UL
>>   > +
>>   > +struct dp_pll_vco_clk {
>>   > +    struct clk_hw hw;
>>   > +    unsigned long    rate;        /* current vco rate */
>>   > +    u64        min_rate;    /* min vco rate */
>>   > +    u64        max_rate;    /* max vco rate */
>>   > +    void        *priv;
>>   > +};
>>   > +
>>   > +struct dp_pll_db {
>>
>> This struct should probably go into dp_pll_10nm.c. dp_pll_7nm.c, for
>> example, will use slightly different structure.
> 
> Note that sboyd has a WIP series to move all of the pll code out to a
> phy driver.  If there is work already happening on 7nm support, it
> might be better to go with the separate phy driver approach?  I'm
> still a bit undecided about whether to land the dp code initially with
> the pll stuff in drm, and then continue refactoring to move to
> separate phy driver upstream, or to strip out the pll code from the
> beginning.  If you/someone is working on 7nm support, then feedback
> about which approach is easier is welcome.
> 
> https://lore.kernel.org/dri-devel/20200611091919.108018-1-swboyd@chromium.org/
> 

I have a sm8150/sm8250 (7nm) upstream kernel stack with DP enabled, and 
I have done something similar, with the PLL driver in the QMP phy, 
although not based on sboyd's series (along with some typec changes to 
negotiate the DP alt mode and get HPD events, etc.). I don't think 
having PLL in drm/msm makes sense, the drm/msm DP driver shouldn't need 
to be aware of the DP PLL/PHY driver, it only needs to set the 
link/pixel clock rates which are in dispcc (and those then have the PLL 
clocks as a parent).

FYI, since it sounds you are considering landing this: it is completely 
broken, for example:
- ioremap()'s to #define'd addresses in the PLL driver
- main DP driver reading/writing to registers in the PHY region, but 
getting the base address from devicetree was removed since earlier 
revisions, so it just fails completely. Look at usb3_dp_com (for 
example), which in dp_catalog_ctrl_usb_reset() would be used to 
overwrite registers already being driven by the qmp phy driver - but now 
the usb3_dp_com.base is never initialized.

-Jonathan

> BR,
> -R
> _______________________________________________
> Freedreno mailing list
> Freedreno@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/freedreno
> 

WARNING: multiple messages have this Message-ID (diff)
From: Jonathan Marek <jonathan@marek.ca>
To: Rob Clark <robdclark@gmail.com>,
	Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
	<devicetree@vger.kernel.org>, Tanmay Shah <tanmay@codeaurora.org>,
	David Airlie <airlied@linux.ie>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Stephen Boyd <swboyd@chromium.org>,
	khsieh@codeaurora.org, Sean Paul <seanpaul@chromium.org>,
	Abhinav Kumar <abhinavk@codeaurora.org>,
	Vara Reddy <varar@codeaurora.org>,
	aravindh@codeaurora.org,
	freedreno <freedreno@lists.freedesktop.org>,
	Chandan Uddaraju <chandanu@codeaurora.org>
Subject: Re: [Freedreno] [PATCH v10 3/5] drm/msm/dp: add support for DP PLL driver
Date: Sat, 15 Aug 2020 17:21:49 -0400	[thread overview]
Message-ID: <1ea81fa2-1dc8-a0b9-aa32-3127e9354be2@marek.ca> (raw)
In-Reply-To: <CAF6AEGtcfXodN1_HSdTcH402FdwTk15Nt6p3F=QYeSRhTc+hqw@mail.gmail.com>

On 8/15/20 4:20 PM, Rob Clark wrote:
> On Fri, Aug 14, 2020 at 10:05 AM Dmitry Baryshkov
> <dmitry.baryshkov@linaro.org> wrote:
>>
>>
>> On 12/08/2020 07:42, Tanmay Shah wrote:
>>   > From: Chandan Uddaraju <chandanu@codeaurora.org>
>>   >
>>   > Add the needed DP PLL specific files to support
>>   > display port interface on msm targets.
>>
>> [skipped]
>>
>>   > diff --git a/drivers/gpu/drm/msm/dp/dp_pll_private.h
>> b/drivers/gpu/drm/msm/dp/dp_pll_private.h
>>   > new file mode 100644
>>   > index 000000000000..475ba6ed59ab
>>   > --- /dev/null
>>   > +++ b/drivers/gpu/drm/msm/dp/dp_pll_private.h
>>   > @@ -0,0 +1,98 @@
>>   > +/* SPDX-License-Identifier: GPL-2.0-only */
>>   > +/*
>>   > + * Copyright (c) 2016-2020, The Linux Foundation. All rights reserved.
>>   > + */
>>   > +
>>   > +#ifndef __DP_PLL_10NM_H
>>   > +#define __DP_PLL_10NM_H
>>   > +
>>   > +#include "dp_pll.h"
>>   > +#include "dp_reg.h"
>>   > +
>>   > +#define DP_VCO_HSCLK_RATE_1620MHZDIV1000    1620000UL
>>   > +#define DP_VCO_HSCLK_RATE_2700MHZDIV1000    2700000UL
>>   > +#define DP_VCO_HSCLK_RATE_5400MHZDIV1000    5400000UL
>>   > +#define DP_VCO_HSCLK_RATE_8100MHZDIV1000    8100000UL
>>   > +
>>   > +#define NUM_DP_CLOCKS_MAX            6
>>   > +
>>   > +#define DP_PHY_PLL_POLL_SLEEP_US        500
>>   > +#define DP_PHY_PLL_POLL_TIMEOUT_US        10000
>>   > +
>>   > +#define DP_VCO_RATE_8100MHZDIV1000        8100000UL
>>   > +#define DP_VCO_RATE_9720MHZDIV1000        9720000UL
>>   > +#define DP_VCO_RATE_10800MHZDIV1000        10800000UL
>>   > +
>>   > +struct dp_pll_vco_clk {
>>   > +    struct clk_hw hw;
>>   > +    unsigned long    rate;        /* current vco rate */
>>   > +    u64        min_rate;    /* min vco rate */
>>   > +    u64        max_rate;    /* max vco rate */
>>   > +    void        *priv;
>>   > +};
>>   > +
>>   > +struct dp_pll_db {
>>
>> This struct should probably go into dp_pll_10nm.c. dp_pll_7nm.c, for
>> example, will use slightly different structure.
> 
> Note that sboyd has a WIP series to move all of the pll code out to a
> phy driver.  If there is work already happening on 7nm support, it
> might be better to go with the separate phy driver approach?  I'm
> still a bit undecided about whether to land the dp code initially with
> the pll stuff in drm, and then continue refactoring to move to
> separate phy driver upstream, or to strip out the pll code from the
> beginning.  If you/someone is working on 7nm support, then feedback
> about which approach is easier is welcome.
> 
> https://lore.kernel.org/dri-devel/20200611091919.108018-1-swboyd@chromium.org/
> 

I have a sm8150/sm8250 (7nm) upstream kernel stack with DP enabled, and 
I have done something similar, with the PLL driver in the QMP phy, 
although not based on sboyd's series (along with some typec changes to 
negotiate the DP alt mode and get HPD events, etc.). I don't think 
having PLL in drm/msm makes sense, the drm/msm DP driver shouldn't need 
to be aware of the DP PLL/PHY driver, it only needs to set the 
link/pixel clock rates which are in dispcc (and those then have the PLL 
clocks as a parent).

FYI, since it sounds you are considering landing this: it is completely 
broken, for example:
- ioremap()'s to #define'd addresses in the PLL driver
- main DP driver reading/writing to registers in the PHY region, but 
getting the base address from devicetree was removed since earlier 
revisions, so it just fails completely. Look at usb3_dp_com (for 
example), which in dp_catalog_ctrl_usb_reset() would be used to 
overwrite registers already being driven by the qmp phy driver - but now 
the usb3_dp_com.base is never initialized.

-Jonathan

> BR,
> -R
> _______________________________________________
> Freedreno mailing list
> Freedreno@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/freedreno
> 
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2020-08-15 21:41 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-12  4:42 [PATCH v10 0/5] Add support for DisplayPort driver on SnapDragon Tanmay Shah
2020-08-12  4:42 ` Tanmay Shah
2020-08-12  4:42 ` [PATCH v10 1/5] drm: add constant N value in helper file Tanmay Shah
2020-08-12  4:42   ` Tanmay Shah
2020-08-12  4:42 ` [PATCH v10 2/5] drm/msm/dp: add displayPort driver support Tanmay Shah
2020-08-12  4:42   ` Tanmay Shah
2020-08-14 17:12   ` Dmitry Baryshkov
2020-08-14 17:12     ` Dmitry Baryshkov
2020-08-14 17:56     ` [Freedreno] " Tanmay Shah
2020-08-14 17:56       ` Tanmay Shah
2020-08-14 21:14       ` Tanmay Shah
2020-08-14 21:14         ` Tanmay Shah
2020-08-12  4:42 ` [PATCH v10 3/5] drm/msm/dp: add support for DP PLL driver Tanmay Shah
2020-08-12  4:42   ` Tanmay Shah
2020-08-14 17:05   ` Dmitry Baryshkov
2020-08-14 17:05     ` Dmitry Baryshkov
2020-08-14 23:22     ` Tanmay Shah
2020-08-14 23:22       ` Tanmay Shah
2020-08-15 11:45       ` Dmitry Baryshkov
2020-08-15 11:45         ` Dmitry Baryshkov
2020-08-17 18:06         ` Tanmay Shah
2020-08-17 18:06           ` Tanmay Shah
2020-08-15 20:20     ` Rob Clark
2020-08-15 20:20       ` Rob Clark
2020-08-15 21:21       ` Jonathan Marek [this message]
2020-08-15 21:21         ` [Freedreno] " Jonathan Marek
2020-08-15 22:45         ` Rob Clark
2020-08-15 22:45           ` Rob Clark
2020-08-17 20:00           ` Tanmay Shah
2020-08-17 20:00             ` Tanmay Shah
2020-08-17 20:32           ` Dmitry Baryshkov
2020-08-17 20:32             ` Dmitry Baryshkov
2020-08-17 20:37             ` Rob Clark
2020-08-17 20:37               ` Rob Clark
2020-08-12  4:42 ` [PATCH v10 4/5] drm/msm/dpu: add display port support in DPU Tanmay Shah
2020-08-12  4:42   ` Tanmay Shah
2020-08-12  4:42 ` [PATCH v10 5/5] drm/msm/dp: Add Display Port HPD feature Tanmay Shah
2020-08-12  4:42   ` Tanmay Shah

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=1ea81fa2-1dc8-a0b9-aa32-3127e9354be2@marek.ca \
    --to=jonathan@marek.ca \
    --cc=abhinavk@codeaurora.org \
    --cc=airlied@linux.ie \
    --cc=aravindh@codeaurora.org \
    --cc=chandanu@codeaurora.org \
    --cc=daniel@ffwll.ch \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.baryshkov@linaro.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=freedreno@lists.freedesktop.org \
    --cc=khsieh@codeaurora.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robdclark@gmail.com \
    --cc=seanpaul@chromium.org \
    --cc=swboyd@chromium.org \
    --cc=tanmay@codeaurora.org \
    --cc=varar@codeaurora.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 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.