Re: [Freedreno] [PATCH v10 3/5] drm/msm/dp: add support for DP PLL driver
On Mon, Aug 17, 2020 at 1:32 PM Dmitry Baryshkov wrote: > > On 16/08/2020 01:45, Rob Clark wrote: > > On Sat, Aug 15, 2020 at 2:21 PM Jonathan Marek wrote: > >> > >> On 8/15/20 4:20 PM, Rob Clark wrote: > >>> On Fri, Aug 14, 2020 at 10:05 AM Dmitry Baryshkov > >>> wrote: > > > On 12/08/2020 07:42, Tanmay Shah wrote: > > From: Chandan Uddaraju > > > > 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 ..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_1620MHZDIV1000162UL > > +#define DP_VCO_HSCLK_RATE_2700MHZDIV1000270UL > > +#define DP_VCO_HSCLK_RATE_5400MHZDIV1000540UL > > +#define DP_VCO_HSCLK_RATE_8100MHZDIV1000810UL > > + > > +#define NUM_DP_CLOCKS_MAX6 > > + > > +#define DP_PHY_PLL_POLL_SLEEP_US500 > > +#define DP_PHY_PLL_POLL_TIMEOUT_US1 > > + > > +#define DP_VCO_RATE_8100MHZDIV1000810UL > > +#define DP_VCO_RATE_9720MHZDIV1000972UL > > +#define DP_VCO_RATE_10800MHZDIV10001080UL > > + > > +struct dp_pll_vco_clk { > > +struct clk_hw hw; > > +unsigned longrate;/* current vco rate */ > > +u64min_rate;/* min vco rate */ > > +u64max_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-swb...@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). > > > > yeah, in the dp case, having phy split out makes a ton of sense.. it > > would maybe be a nice cleanup in other cases (dsi, hdmi) but the > > combination of usb+dp makes burying this in drm not so great.. > > > > It would be good if you could work w/ sboyd on this.. based on what > > I've seen on previous gens, it is probably a different phy driver for > > 7nm vs 10nm, but I think where we want to end up upstream is with phy > > split out of drm. > > 7nm differs in registers programming, so it would end up with a separate > set of tables in qmp phy driver. There is also a 14nm version of dp phy, > but I don't know if it usable in any actual hardware design. > I'll defer to Stephen about phy stuff, but was kinda just expecting to have different phy drivers for different process sizes, rather than trying to bundle it all in one phy driver. At least what I've seen before for dsi/hdmi/etc phy's is that the register programming is different enough to not really share much. BR, -R
Re: [Freedreno] [PATCH v10 3/5] drm/msm/dp: add support for DP PLL driver
On 16/08/2020 01:45, Rob Clark wrote: On Sat, Aug 15, 2020 at 2:21 PM Jonathan Marek wrote: On 8/15/20 4:20 PM, Rob Clark wrote: On Fri, Aug 14, 2020 at 10:05 AM Dmitry Baryshkov wrote: On 12/08/2020 07:42, Tanmay Shah wrote: > From: Chandan Uddaraju > > 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 ..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_1620MHZDIV1000162UL > +#define DP_VCO_HSCLK_RATE_2700MHZDIV1000270UL > +#define DP_VCO_HSCLK_RATE_5400MHZDIV1000540UL > +#define DP_VCO_HSCLK_RATE_8100MHZDIV1000810UL > + > +#define NUM_DP_CLOCKS_MAX6 > + > +#define DP_PHY_PLL_POLL_SLEEP_US500 > +#define DP_PHY_PLL_POLL_TIMEOUT_US1 > + > +#define DP_VCO_RATE_8100MHZDIV1000810UL > +#define DP_VCO_RATE_9720MHZDIV1000972UL > +#define DP_VCO_RATE_10800MHZDIV10001080UL > + > +struct dp_pll_vco_clk { > +struct clk_hw hw; > +unsigned longrate;/* current vco rate */ > +u64min_rate;/* min vco rate */ > +u64max_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-swb...@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). yeah, in the dp case, having phy split out makes a ton of sense.. it would maybe be a nice cleanup in other cases (dsi, hdmi) but the combination of usb+dp makes burying this in drm not so great.. It would be good if you could work w/ sboyd on this.. based on what I've seen on previous gens, it is probably a different phy driver for 7nm vs 10nm, but I think where we want to end up upstream is with phy split out of drm. 7nm differs in registers programming, so it would end up with a separate set of tables in qmp phy driver. There is also a 14nm version of dp phy, but I don't know if it usable in any actual hardware design. -- With best wishes Dmitry
Re: [Freedreno] [PATCH v10 3/5] drm/msm/dp: add support for DP PLL driver
On 2020-08-15 15:45, Rob Clark wrote: On Sat, Aug 15, 2020 at 2:21 PM Jonathan Marek wrote: On 8/15/20 4:20 PM, Rob Clark wrote: > On Fri, Aug 14, 2020 at 10:05 AM Dmitry Baryshkov > wrote: >> >> >> On 12/08/2020 07:42, Tanmay Shah wrote: >> > From: Chandan Uddaraju >> > >> > 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 ..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_1620MHZDIV1000162UL >> > +#define DP_VCO_HSCLK_RATE_2700MHZDIV1000270UL >> > +#define DP_VCO_HSCLK_RATE_5400MHZDIV1000540UL >> > +#define DP_VCO_HSCLK_RATE_8100MHZDIV1000810UL >> > + >> > +#define NUM_DP_CLOCKS_MAX6 >> > + >> > +#define DP_PHY_PLL_POLL_SLEEP_US500 >> > +#define DP_PHY_PLL_POLL_TIMEOUT_US1 >> > + >> > +#define DP_VCO_RATE_8100MHZDIV1000810UL >> > +#define DP_VCO_RATE_9720MHZDIV1000972UL >> > +#define DP_VCO_RATE_10800MHZDIV10001080UL >> > + >> > +struct dp_pll_vco_clk { >> > +struct clk_hw hw; >> > +unsigned longrate;/* current vco rate */ >> > +u64min_rate;/* min vco rate */ >> > +u64max_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). yeah, in the dp case, having phy split out makes a ton of sense.. it would maybe be a nice cleanup in other cases (dsi, hdmi) but the combination of usb+dp makes burying this in drm not so great.. It would be good if you could work w/ sboyd on this.. based on what I've seen on previous gens, it is probably a different phy driver for 7nm vs 10nm, but I think where we want to end up upstream is with phy split out of drm. 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. Yeah, the idea to land dp isn't that it is perfect (or even not broken), so much as having something upstream gives a common base for others to work against.. maybe we should make the dp parts 'depends on STAGING'? I could keep a separate msm-next-dp branch that I rebase, to give a common point for folks working dp support for various different gens to coordinate work on.. that kinda sounds like a bunch of extra work for me, so might as well land what we have somehow and work together from there ;-) But it does sound like you are making the case for including the patch to drop the pll stuff and use phy framework as part of what initially goes upstream. I agree with Rob on landing what we have in DP driver. Of course, by addressing any outstanding comments. That would help in setting base functional code for DisplayPort Bring-up. Other features
Re: [Freedreno] [PATCH v10 3/5] drm/msm/dp: add support for DP PLL driver
On Sat, Aug 15, 2020 at 2:21 PM Jonathan Marek wrote: > > On 8/15/20 4:20 PM, Rob Clark wrote: > > On Fri, Aug 14, 2020 at 10:05 AM Dmitry Baryshkov > > wrote: > >> > >> > >> On 12/08/2020 07:42, Tanmay Shah wrote: > >> > From: Chandan Uddaraju > >> > > >> > 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 ..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_1620MHZDIV1000162UL > >> > +#define DP_VCO_HSCLK_RATE_2700MHZDIV1000270UL > >> > +#define DP_VCO_HSCLK_RATE_5400MHZDIV1000540UL > >> > +#define DP_VCO_HSCLK_RATE_8100MHZDIV1000810UL > >> > + > >> > +#define NUM_DP_CLOCKS_MAX6 > >> > + > >> > +#define DP_PHY_PLL_POLL_SLEEP_US500 > >> > +#define DP_PHY_PLL_POLL_TIMEOUT_US1 > >> > + > >> > +#define DP_VCO_RATE_8100MHZDIV1000810UL > >> > +#define DP_VCO_RATE_9720MHZDIV1000972UL > >> > +#define DP_VCO_RATE_10800MHZDIV10001080UL > >> > + > >> > +struct dp_pll_vco_clk { > >> > +struct clk_hw hw; > >> > +unsigned longrate;/* current vco rate */ > >> > +u64min_rate;/* min vco rate */ > >> > +u64max_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-swb...@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). yeah, in the dp case, having phy split out makes a ton of sense.. it would maybe be a nice cleanup in other cases (dsi, hdmi) but the combination of usb+dp makes burying this in drm not so great.. It would be good if you could work w/ sboyd on this.. based on what I've seen on previous gens, it is probably a different phy driver for 7nm vs 10nm, but I think where we want to end up upstream is with phy split out of drm. > 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. Yeah, the idea to land dp isn't that it is perfect (or even not broken), so much as having something upstream gives a common base for others to work against.. maybe we should make the dp parts 'depends on STAGING'? I could keep a separate msm-next-dp branch that I rebase, to give a common point for folks working dp support for various different gens to coordinate work on.. that kinda sounds like a bunch of extra work for me, so might as well land what we have somehow and work together from there ;-) But it does sound like you are making the case for including the patch to drop the pll stuff and use phy framework as part of what initially goes upstream. BR, -R > > -Jonathan > > > BR, > > -R > >
Re: [Freedreno] [PATCH v10 3/5] drm/msm/dp: add support for DP PLL driver
On 8/15/20 4:20 PM, Rob Clark wrote: On Fri, Aug 14, 2020 at 10:05 AM Dmitry Baryshkov wrote: On 12/08/2020 07:42, Tanmay Shah wrote: > From: Chandan Uddaraju > > 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 ..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_1620MHZDIV1000162UL > +#define DP_VCO_HSCLK_RATE_2700MHZDIV1000270UL > +#define DP_VCO_HSCLK_RATE_5400MHZDIV1000540UL > +#define DP_VCO_HSCLK_RATE_8100MHZDIV1000810UL > + > +#define NUM_DP_CLOCKS_MAX6 > + > +#define DP_PHY_PLL_POLL_SLEEP_US500 > +#define DP_PHY_PLL_POLL_TIMEOUT_US1 > + > +#define DP_VCO_RATE_8100MHZDIV1000810UL > +#define DP_VCO_RATE_9720MHZDIV1000972UL > +#define DP_VCO_RATE_10800MHZDIV10001080UL > + > +struct dp_pll_vco_clk { > +struct clk_hw hw; > +unsigned longrate;/* current vco rate */ > +u64min_rate;/* min vco rate */ > +u64max_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-swb...@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 freedr...@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/freedreno