[PULL] drm-misc-fixes

[Maarten Lankhorst]

Hi Dave/Daniel,

drm-misc-fixes-2019-01-10:
Pull request for drm-misc-fixes for v5.0-rc2:
- Fixes for the tc358767 bridge to work correctly with
  tc358867 using a DP connector.
- Make resume work on amdgpu when a DP-MST display is unplugged.
The following changes since commit bfeffd155283772bbe78c6a05dec7c0128ee500c:

  Linux 5.0-rc1 (2019-01-06 17:08:20 -0800)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2019-01-10

for you to fetch changes up to f8c15790e4d8bdf2d21a5e9d43b5f97983af1222:

  drm/bridge: tc358767: use DP connector if no panel set (2019-01-09 10:49:31 
+0100)


Pull request for drm-misc-fixes for v5.0-rc2:
- Fixes for the tc358767 bridge to work correctly with
  tc358867 using a DP connector.
- Make resume work on amdgpu when a DP-MST display is unplugged.


Lyude Paul (3):
  drm/amdgpu: Don't ignore rc from drm_dp_mst_topology_mgr_resume()
  drm/amdgpu: Don't fail resume process if resuming atomic state fails
  drm/dp_mst: Add __must_check to drm_dp_mst_topology_mgr_resume()

Tomi Valkeinen (7):
  drm/bridge: tc358767: add bus flags
  drm/bridge: tc358767: add defines for DP1_SRCCTRL & PHY_2LANE
  drm/bridge: tc358767: fix single lane configuration
  drm/bridge: tc358767: fix initial DP0/1_SRCCTRL value
  drm/bridge: tc358767: reject modes which require too much BW
  drm/bridge: tc358767: fix output H/V syncs
  drm/bridge: tc358767: use DP connector if no panel set

 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 37 +++--
 drivers/gpu/drm/bridge/tc358767.c | 48 ++-
 include/drm/drm_dp_mst_helper.h   |  3 +-
 3 files changed, 65 insertions(+), 23 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 109265] [regression, bisected] arb_texture_multisample texelfetch piglit test failing on NIR backend

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109265

Bug ID: 109265
   Summary: [regression, bisected] arb_texture_multisample
texelfetch piglit test failing on NIR backend
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: t_arc...@yahoo.com.au
QA Contact: dri-devel@lists.freedesktop.org

For example:

R600_DEBUG=nir ./bin/texelFetch fs sampler2DMS 4 1x71-501x71 -auto -fbo

Bisected to (on VEGA 64):

commit f7ffa504a065dc2631fd38cc5fe885b277f4e7e7 (refs/bisect/bad)
Author: Marek Olšák 
Date:   Sat Jul 29 01:40:48 2017 +0200

ac/surface: compute tile swizzle for GFX9

Tested-by: Dieter Nützel 

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/9] drm/mediatek: recalculate hdmi phy clock of MT2701 by querying hardware

[CK Hu]

Hi, Chunhui:


On Fri, 2019-01-04 at 15:03 +0800, chunhui dai wrote:
> Recalculate the rate of this clock, by querying hardware.
> 
> Signed-off-by: chunhui dai 
> ---
>  drivers/gpu/drm/mediatek/mtk_hdmi_phy.c|  7 ++--
>  drivers/gpu/drm/mediatek/mtk_hdmi_phy.h|  3 +-
>  drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 49 
> ++
>  drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c |  8 +
>  4 files changed, 61 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c 
> b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
> index 4ef9c57..79e737d 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
> @@ -29,12 +29,11 @@ long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned 
> long rate,
>   return rate;
>  }
>  
> -unsigned long mtk_hdmi_pll_recalc_rate(struct clk_hw *hw,
> -unsigned long parent_rate)
> +u32 mtk_hdmi_phy_read(struct mtk_hdmi_phy *hdmi_phy, u32 offset)
>  {
> - struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
> + void __iomem *reg = hdmi_phy->regs + offset;
>  
> - return hdmi_phy->pll_rate;
> + return readl(reg);

reg is used only once, so

return readl(hdmi_phy->regs + offset);

>  }
>  
>  void mtk_hdmi_phy_clear_bits(struct mtk_hdmi_phy *hdmi_phy, u32 offset,
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h 
> b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
> index f39b1fc..fdad8b1 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
> @@ -41,6 +41,7 @@ struct mtk_hdmi_phy {
>   unsigned int ibias_up;
>  };
>  
> +u32 mtk_hdmi_phy_read(struct mtk_hdmi_phy *hdmi_phy, u32 offset);
>  void mtk_hdmi_phy_clear_bits(struct mtk_hdmi_phy *hdmi_phy, u32 offset,
>u32 bits);
>  void mtk_hdmi_phy_set_bits(struct mtk_hdmi_phy *hdmi_phy, u32 offset,
> @@ -50,8 +51,6 @@ void mtk_hdmi_phy_mask(struct mtk_hdmi_phy *hdmi_phy, u32 
> offset,
>  struct mtk_hdmi_phy *to_mtk_hdmi_phy(struct clk_hw *hw);
>  long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long rate,
>unsigned long *parent_rate);
> -unsigned long mtk_hdmi_pll_recalc_rate(struct clk_hw *hw,
> -unsigned long parent_rate);
>  
>  extern struct platform_driver mtk_hdmi_phy_driver;
>  extern struct mtk_hdmi_phy_conf mtk_hdmi_phy_8173_conf;
> diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c 
> b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> index fcc42dc..b5ed6b7 100644
> --- a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> +++ b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> @@ -153,6 +153,55 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw, 
> unsigned long rate,
> RG_HDMITX_DRV_IBIAS_MASK);
>   return 0;
>  }
> +static unsigned long mtk_hdmi_pll_recalc_rate(struct clk_hw *hw,
> +unsigned long parent_rate)
> +{
> + struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
> + unsigned long out_rate, val;
> +
> + val = (mtk_hdmi_phy_read(hdmi_phy, HDMI_CON6)
> + & RG_HTPLL_PREDIV_MASK) >> RG_HTPLL_PREDIV;
> + switch (val) {
> + case 0x00:
> + out_rate = parent_rate;
> + break;
> + case 0x01:
> + out_rate = parent_rate / 2;
> + break;
> + default:
> + out_rate = parent_rate / 4;
> + break;

If the val would not be 3, maybe out_rate could be calculate as

out_rate >>= val;

> + }
> +
> + val = (mtk_hdmi_phy_read(hdmi_phy, HDMI_CON6)
> + & RG_HTPLL_FBKDIV_MASK) >> RG_HTPLL_FBKDIV;
> + out_rate = out_rate * (val + 1) * 2;

out_rate *= (val + 1) * 2;

> + val = (mtk_hdmi_phy_read(hdmi_phy, HDMI_CON2)
> + & RG_HDMITX_TX_POSDIV_MASK) >> RG_HDMITX_TX_POSDIV;
> + switch (val) {
> + case 0x00:
> + out_rate = out_rate;
> + break;
> + case 0x01:
> + out_rate = out_rate / 2;
> + break;
> + case 0x02:
> + out_rate = out_rate / 4;
> + break;
> + case 0x03:
> + out_rate = out_rate / 8;
> + break;
> + default:
> + break;
> + }

out_rate >>= val;

Regards,
CK

> +
> + if (mtk_hdmi_phy_read(hdmi_phy, HDMI_CON2) & RG_HDMITX_EN_TX_POSDIV)
> + out_rate = out_rate / 5;
> +
> + hdmi_phy->pll_rate = out_rate;
> +
> + return hdmi_phy->pll_rate;
> +}
>  
>  static const struct clk_ops mtk_hdmi_phy_pll_ops = {
>   .prepare = mtk_hdmi_pll_prepare,
> diff --git a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c 
> b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> index ed5916b..cb23c1e 100644
> --- a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> +++ b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> @@ -285,6 +285,14 @@ static int 

[radeon-alex:amd-staging-drm-next 262/270] drivers/gpu/drm/amd/amdgpu/si.c:1341:35: error: 'PCIE_PERF_CNTL_TXCLK__EVENT0_SEL_MASK' undeclared; did you mean 'PCI_PM_CTRL_DATA_SEL_MASK'?

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head:   d2d07f246b126b23d02af0603b83866a3c3e2483
commit: fdc916c8be24375d63c36ae363f71e59becfb8f2 [262/270] drm/amdgpu: Add 
sysfs file for PCIe usage v4
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 8.1.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout fdc916c8be24375d63c36ae363f71e59becfb8f2
# save the attached .config to linux build tree
GCC_VERSION=8.1.0 make.cross ARCH=ia64 

Note: the radeon-alex/amd-staging-drm-next HEAD 
d2d07f246b126b23d02af0603b83866a3c3e2483 builds fine.
  It only hurts bisectibility.

All errors (new ones prefixed by >>):

   In file included from drivers/gpu/drm/amd/amdgpu/si.c:28:
   drivers/gpu/drm/amd/amdgpu/si.c: In function 'si_get_pcie_usage':
>> drivers/gpu/drm/amd/amdgpu/si.c:1341:35: error: 
>> 'PCIE_PERF_CNTL_TXCLK__EVENT0_SEL_MASK' undeclared (first use in this 
>> function); did you mean 'PCI_PM_CTRL_DATA_SEL_MASK'?
 perfctr = REG_SET_FIELD(perfctr, PCIE_PERF_CNTL_TXCLK, EVENT0_SEL, 40);
  ^~~~
   drivers/gpu/drm/amd/amdgpu/amdgpu.h:1010:36: note: in definition of macro 
'REG_FIELD_MASK'
#define REG_FIELD_MASK(reg, field) reg##__##field##_MASK
   ^~~
   drivers/gpu/drm/amd/amdgpu/si.c:1341:12: note: in expansion of macro 
'REG_SET_FIELD'
 perfctr = REG_SET_FIELD(perfctr, PCIE_PERF_CNTL_TXCLK, EVENT0_SEL, 40);
   ^
   drivers/gpu/drm/amd/amdgpu/si.c:1341:35: note: each undeclared identifier is 
reported only once for each function it appears in
 perfctr = REG_SET_FIELD(perfctr, PCIE_PERF_CNTL_TXCLK, EVENT0_SEL, 40);
  ^~~~
   drivers/gpu/drm/amd/amdgpu/amdgpu.h:1010:36: note: in definition of macro 
'REG_FIELD_MASK'
#define REG_FIELD_MASK(reg, field) reg##__##field##_MASK
   ^~~
   drivers/gpu/drm/amd/amdgpu/si.c:1341:12: note: in expansion of macro 
'REG_SET_FIELD'
 perfctr = REG_SET_FIELD(perfctr, PCIE_PERF_CNTL_TXCLK, EVENT0_SEL, 40);
   ^
>> drivers/gpu/drm/amd/amdgpu/si.c:1341:35: error: 
>> 'PCIE_PERF_CNTL_TXCLK__EVENT0_SEL__SHIFT' undeclared (first use in this 
>> function); did you mean 'ixPCIE_PERF_CNTL_EVENT0_PORT_SEL'?
 perfctr = REG_SET_FIELD(perfctr, PCIE_PERF_CNTL_TXCLK, EVENT0_SEL, 40);
  ^~~~
   drivers/gpu/drm/amd/amdgpu/amdgpu.h:1009:37: note: in definition of macro 
'REG_FIELD_SHIFT'
#define REG_FIELD_SHIFT(reg, field) reg##__##field##__SHIFT
^~~
   drivers/gpu/drm/amd/amdgpu/si.c:1341:12: note: in expansion of macro 
'REG_SET_FIELD'
 perfctr = REG_SET_FIELD(perfctr, PCIE_PERF_CNTL_TXCLK, EVENT0_SEL, 40);
   ^
>> drivers/gpu/drm/amd/amdgpu/si.c:1342:35: error: 
>> 'PCIE_PERF_CNTL_TXCLK__EVENT1_SEL_MASK' undeclared (first use in this 
>> function); did you mean 'PCI_PM_CTRL_DATA_SEL_MASK'?
 perfctr = REG_SET_FIELD(perfctr, PCIE_PERF_CNTL_TXCLK, EVENT1_SEL, 104);
  ^~~~
   drivers/gpu/drm/amd/amdgpu/amdgpu.h:1010:36: note: in definition of macro 
'REG_FIELD_MASK'
#define REG_FIELD_MASK(reg, field) reg##__##field##_MASK
   ^~~
   drivers/gpu/drm/amd/amdgpu/si.c:1342:12: note: in expansion of macro 
'REG_SET_FIELD'
 perfctr = REG_SET_FIELD(perfctr, PCIE_PERF_CNTL_TXCLK, EVENT1_SEL, 104);
   ^
>> drivers/gpu/drm/amd/amdgpu/si.c:1342:35: error: 
>> 'PCIE_PERF_CNTL_TXCLK__EVENT1_SEL__SHIFT' undeclared (first use in this 
>> function); did you mean 'ixPCIE_PERF_CNTL_EVENT1_PORT_SEL'?
 perfctr = REG_SET_FIELD(perfctr, PCIE_PERF_CNTL_TXCLK, EVENT1_SEL, 104);
  ^~~~
   drivers/gpu/drm/amd/amdgpu/amdgpu.h:1009:37: note: in definition of macro 
'REG_FIELD_SHIFT'
#define REG_FIELD_SHIFT(reg, field) reg##__##field##__SHIFT
^~~
   drivers/gpu/drm/amd/amdgpu/si.c:1342:12: note: in expansion of macro 
'REG_SET_FIELD'
 perfctr = REG_SET_FIELD(perfctr, PCIE_PERF_CNTL_TXCLK, EVENT1_SEL, 104);
   ^
   drivers/gpu/drm/amd/amdgpu/si.c:1364:31: error: 
'PCIE_PERF_CNTL_TXCLK__COUNTER0_UPPER_MASK' undeclared (first use in this 
function)
 cnt0_of = REG_GET_FIELD(tmp, PCIE_PERF_CNTL_TXCLK, COUNTER0_UPPER);
  ^~~~
   drivers/gpu/drm/amd/amdgpu/amdgpu.h:1010:36: note: in definition of macro 
'REG_FIELD_MASK'
#define REG_FIELD_MASK(reg, field) reg##__##field##_MASK
   ^~~
   drivers/gpu/drm/amd/amdgpu/si.c:1364:12: note: 

Re: [PATCH v3 12/12] drm: remove drmP.h from drm_gem_cma_helper.h

[Sam Ravnborg]

On Wed, Jan 09, 2019 at 11:24:05PM +0100, Daniel Vetter wrote:
> On Tue, Jan 08, 2019 at 08:29:39PM +0100, Sam Ravnborg wrote:
> > With all dependencies fixed we can now remove
> > drmP.h from drm_gem_cma_helper.h.
> > It is replaced by the include files required,
> > or forward declarations as appropritate.
> > 
> > Signed-off-by: Sam Ravnborg 
> > Acked-by: Noralf Trønnes 
> > Cc: Maarten Lankhorst 
> > Cc: Maxime Ripard 
> > Cc: Sean Paul 
> > Cc: David Airlie 
> > Cc: Daniel Vetter 
> 
> Except for the ones I commented on, all patches applied. I also fixed the
> one typo in the summary.

Thanks, I will rebase, address comments, do a new set of build tests etc. and 
repost.

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

[Bug 108521] RX 580 as eGPU amdgpu: gpu post error!

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=108521

--- Comment #38 from Alex Deucher  ---
(In reply to Robert Strube from comment #34)
> Created attachment 143044 [details]
> dmesg log amdgpu.dpm=0 with 580 as eGPU
> 
> Another user is reporting a similar problem with a different Dell laptop
> (the XPS 9370).  He provided two dmesg log files.  This one has amdgpu=0.

It would appear that this user is not experiencing the same issue as you.  In
your case the driver fails to even post the GPU.  That happens long before dpm
is initialized.  The other user can try adding amdgpu.ppfeaturemask=0xfffd3ffb
to disable pcie power management to see if his issue is related to comment 29.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[radeon-alex:amd-staging-drm-next 262/270] drivers/gpu//drm/amd/amdgpu/si.c:1341:12: note: in expansion of macro 'REG_SET_FIELD'

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head:   d2d07f246b126b23d02af0603b83866a3c3e2483
commit: fdc916c8be24375d63c36ae363f71e59becfb8f2 [262/270] drm/amdgpu: Add 
sysfs file for PCIe usage v4
config: i386-randconfig-s3-201901 (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
git checkout fdc916c8be24375d63c36ae363f71e59becfb8f2
# save the attached .config to linux build tree
make ARCH=i386 

Note: the radeon-alex/amd-staging-drm-next HEAD 
d2d07f246b126b23d02af0603b83866a3c3e2483 builds fine.
  It only hurts bisectibility.

All error/warnings (new ones prefixed by >>):

   In file included from drivers/gpu//drm/amd/amdgpu/si.c:28:0:
   drivers/gpu//drm/amd/amdgpu/si.c: In function 'si_get_pcie_usage':
>> drivers/gpu//drm/amd/amdgpu/si.c:1341:35: error: 
>> 'PCIE_PERF_CNTL_TXCLK__EVENT0_SEL_MASK' undeclared (first use in this 
>> function)
 perfctr = REG_SET_FIELD(perfctr, PCIE_PERF_CNTL_TXCLK, EVENT0_SEL, 40);
  ^
   drivers/gpu//drm/amd/amdgpu/amdgpu.h:1010:36: note: in definition of macro 
'REG_FIELD_MASK'
#define REG_FIELD_MASK(reg, field) reg##__##field##_MASK
   ^~~
>> drivers/gpu//drm/amd/amdgpu/si.c:1341:12: note: in expansion of macro 
>> 'REG_SET_FIELD'
 perfctr = REG_SET_FIELD(perfctr, PCIE_PERF_CNTL_TXCLK, EVENT0_SEL, 40);
   ^
   drivers/gpu//drm/amd/amdgpu/si.c:1341:35: note: each undeclared identifier 
is reported only once for each function it appears in
 perfctr = REG_SET_FIELD(perfctr, PCIE_PERF_CNTL_TXCLK, EVENT0_SEL, 40);
  ^
   drivers/gpu//drm/amd/amdgpu/amdgpu.h:1010:36: note: in definition of macro 
'REG_FIELD_MASK'
#define REG_FIELD_MASK(reg, field) reg##__##field##_MASK
   ^~~
>> drivers/gpu//drm/amd/amdgpu/si.c:1341:12: note: in expansion of macro 
>> 'REG_SET_FIELD'
 perfctr = REG_SET_FIELD(perfctr, PCIE_PERF_CNTL_TXCLK, EVENT0_SEL, 40);
   ^
>> drivers/gpu//drm/amd/amdgpu/si.c:1341:35: error: 
>> 'PCIE_PERF_CNTL_TXCLK__EVENT0_SEL__SHIFT' undeclared (first use in this 
>> function)
 perfctr = REG_SET_FIELD(perfctr, PCIE_PERF_CNTL_TXCLK, EVENT0_SEL, 40);
  ^
   drivers/gpu//drm/amd/amdgpu/amdgpu.h:1009:37: note: in definition of macro 
'REG_FIELD_SHIFT'
#define REG_FIELD_SHIFT(reg, field) reg##__##field##__SHIFT
^~~
>> drivers/gpu//drm/amd/amdgpu/si.c:1341:12: note: in expansion of macro 
>> 'REG_SET_FIELD'
 perfctr = REG_SET_FIELD(perfctr, PCIE_PERF_CNTL_TXCLK, EVENT0_SEL, 40);
   ^
>> drivers/gpu//drm/amd/amdgpu/si.c:1342:35: error: 
>> 'PCIE_PERF_CNTL_TXCLK__EVENT1_SEL_MASK' undeclared (first use in this 
>> function)
 perfctr = REG_SET_FIELD(perfctr, PCIE_PERF_CNTL_TXCLK, EVENT1_SEL, 104);
  ^
   drivers/gpu//drm/amd/amdgpu/amdgpu.h:1010:36: note: in definition of macro 
'REG_FIELD_MASK'
#define REG_FIELD_MASK(reg, field) reg##__##field##_MASK
   ^~~
   drivers/gpu//drm/amd/amdgpu/si.c:1342:12: note: in expansion of macro 
'REG_SET_FIELD'
 perfctr = REG_SET_FIELD(perfctr, PCIE_PERF_CNTL_TXCLK, EVENT1_SEL, 104);
   ^
>> drivers/gpu//drm/amd/amdgpu/si.c:1342:35: error: 
>> 'PCIE_PERF_CNTL_TXCLK__EVENT1_SEL__SHIFT' undeclared (first use in this 
>> function)
 perfctr = REG_SET_FIELD(perfctr, PCIE_PERF_CNTL_TXCLK, EVENT1_SEL, 104);
  ^
   drivers/gpu//drm/amd/amdgpu/amdgpu.h:1009:37: note: in definition of macro 
'REG_FIELD_SHIFT'
#define REG_FIELD_SHIFT(reg, field) reg##__##field##__SHIFT
^~~
   drivers/gpu//drm/amd/amdgpu/si.c:1342:12: note: in expansion of macro 
'REG_SET_FIELD'
 perfctr = REG_SET_FIELD(perfctr, PCIE_PERF_CNTL_TXCLK, EVENT1_SEL, 104);
   ^
>> drivers/gpu//drm/amd/amdgpu/si.c:1364:31: error: 
>> 'PCIE_PERF_CNTL_TXCLK__COUNTER0_UPPER_MASK' undeclared (first use in this 
>> function)
 cnt0_of = REG_GET_FIELD(tmp, PCIE_PERF_CNTL_TXCLK, COUNTER0_UPPER);
  ^
   drivers/gpu//drm/amd/amdgpu/amdgpu.h:1010:36: note: in definition of macro 
'REG_FIELD_MASK'
#define REG_FIELD_MASK(reg, field) reg##__##field##_MASK
   ^~~
>> drivers/gpu//drm/amd/amdgpu/si.c:1364:12: note: in expansion of macro 
>> 'REG_GET_FIELD'
 cnt0_of = REG_GET_FIELD(tmp, PCIE_PERF_CNTL_TXCLK, COUNTER0_UPPER);
   ^
>> drivers/gpu//drm/amd/amdgpu/si.c:1364:31: error: 
>> 'PCIE_PERF_CNTL_TXCLK__COUNTER0_UPPER__SHIFT' undeclared (first use in this 
>> function)
 cnt0_of = REG_GET_FIELD(tmp, PCIE_PERF_CNTL_TXCLK, COUNTER0_UPPER);
  ^
   

Re: [PATCH v3 12/12] drm: remove drmP.h from drm_gem_cma_helper.h

[Daniel Vetter]

On Tue, Jan 08, 2019 at 08:29:39PM +0100, Sam Ravnborg wrote:
> With all dependencies fixed we can now remove
> drmP.h from drm_gem_cma_helper.h.
> It is replaced by the include files required,
> or forward declarations as appropritate.
> 
> Signed-off-by: Sam Ravnborg 
> Acked-by: Noralf Trønnes 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: Sean Paul 
> Cc: David Airlie 
> Cc: Daniel Vetter 

Except for the ones I commented on, all patches applied. I also fixed the
one typo in the summary.

Thanks, Daniel
> ---
>  include/drm/drm_gem_cma_helper.h | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/include/drm/drm_gem_cma_helper.h 
> b/include/drm/drm_gem_cma_helper.h
> index 07c504940ba1..947ac95eb24a 100644
> --- a/include/drm/drm_gem_cma_helper.h
> +++ b/include/drm/drm_gem_cma_helper.h
> @@ -2,9 +2,12 @@
>  #ifndef __DRM_GEM_CMA_HELPER_H__
>  #define __DRM_GEM_CMA_HELPER_H__
>  
> -#include 
> +#include 
> +#include 
>  #include 
>  
> +struct drm_mode_create_dumb;
> +
>  /**
>   * struct drm_gem_cma_object - GEM object backed by CMA memory allocations
>   * @base: base GEM object
> -- 
> 2.12.0
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 05/12] drm: move EXPORT_SYMBOL_FOR_TESTS_ONLY to drm_util.h

[Daniel Vetter]

On Tue, Jan 08, 2019 at 08:29:32PM +0100, Sam Ravnborg wrote:
> In the quest to get rid of drmP.h move the newly
> added EXPORT_SYMBOL_FOR_TESTS_ONLY to drm_util.h.
> Fix the single user.
> 
> Add a note to drmP.h to avoid further use of it.
> 
> Signed-off-by: Sam Ravnborg 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: Sean Paul 
> Cc: David Airlie 
> Cc: Daniel Vetter 

Skipping this one for now, since it doesn't apply cleanly without patch 4.
Seems like none of the later patches requires it.
-Daniel

> ---
>  drivers/gpu/drm/drm_framebuffer.c |  1 +
>  include/drm/drmP.h| 11 ++-
>  include/drm/drm_util.h| 10 ++
>  3 files changed, 17 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_framebuffer.c 
> b/drivers/gpu/drm/drm_framebuffer.c
> index fcaea8f50513..7abcb265a108 100644
> --- a/drivers/gpu/drm/drm_framebuffer.c
> +++ b/drivers/gpu/drm/drm_framebuffer.c
> @@ -27,6 +27,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "drm_internal.h"
>  #include "drm_crtc_internal.h"
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index bc4cb3732407..3f5c577c9dbd 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -94,10 +94,11 @@ struct dma_buf_attachment;
>  struct pci_dev;
>  struct pci_controller;
>  
> -#if defined(CONFIG_DRM_DEBUG_SELFTEST_MODULE)
> -#define EXPORT_SYMBOL_FOR_TESTS_ONLY(x) EXPORT_SYMBOL(x)
> -#else
> -#define EXPORT_SYMBOL_FOR_TESTS_ONLY(x)
> -#endif
> +/*
> + * NOTE: drmP.h is obsolete - do NOT add anything to this file
> + *
> + * Do not include drmP.h in new files.
> + * Work is ongoing to remove drmP.h includes from existing files
> + */
>  
>  #endif
> diff --git a/include/drm/drm_util.h b/include/drm/drm_util.h
> index 8fda5777471c..cd1e4be1dfb3 100644
> --- a/include/drm/drm_util.h
> +++ b/include/drm/drm_util.h
> @@ -37,6 +37,16 @@
>  #include 
>  #include 
>  
> +/*
> + * Use EXPORT_SYMBOL_FOR_TESTS_ONLY() for functions that shall
> + * only be visible for drmselftests.
> + */
> +#if defined(CONFIG_DRM_DEBUG_SELFTEST_MODULE)
> +#define EXPORT_SYMBOL_FOR_TESTS_ONLY(x) EXPORT_SYMBOL(x)
> +#else
> +#define EXPORT_SYMBOL_FOR_TESTS_ONLY(x)
> +#endif
> +
>  /**
>   * for_each_if - helper for handling conditionals in various for_each macros
>   * @condition The condition to check
> -- 
> 2.12.0
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 08/12] drm: remove include of drmP.h from drm_modeset_helper.h

[Daniel Vetter]

On Tue, Jan 08, 2019 at 08:29:35PM +0100, Sam Ravnborg wrote:
> drmP.h is an relic from the days when there was a single header file.
> To enable the removal of drmP.h from all users drop include
> of drmP.h from drm_modeset_helper.h.
> 
> A few files relied on the file included in drmP.h - add explicit
> include statements to these files.
> Build tested with arm and x86.
> 
> v2:
> - Add forward declarations to drm_modeset_helper.h (Laurent Pinchart)
> 
> Signed-off-by: Sam Ravnborg 
> Reviewed-by: Laurent Pinchart 
> Cc: Alexey Brodkin 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Archit Taneja 
> Cc: Andrzej Hajda 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: Sean Paul 
> Cc: Kieran Bingham 

This one here breaks tinydrm without the tinydrm patch first. I reorderd
while applying. It also breaks kirin (and maybe more, I didn't check), so
I've left this one out for now.
-Daniel

> ---
>  drivers/gpu/drm/arc/arcpgu_sim.c | 1 +
>  drivers/gpu/drm/bridge/cdns-dsi.c| 2 ++
>  drivers/gpu/drm/drm_modeset_helper.c | 2 ++
>  drivers/gpu/drm/rcar-du/rcar_lvds.c  | 1 +
>  include/drm/drm_modeset_helper.h | 6 +-
>  5 files changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/arc/arcpgu_sim.c 
> b/drivers/gpu/drm/arc/arcpgu_sim.c
> index 68629e614990..3b7556f62230 100644
> --- a/drivers/gpu/drm/arc/arcpgu_sim.c
> +++ b/drivers/gpu/drm/arc/arcpgu_sim.c
> @@ -14,6 +14,7 @@
>   *
>   */
>  
> +#include 
>  #include 
>  #include 
>  
> diff --git a/drivers/gpu/drm/bridge/cdns-dsi.c 
> b/drivers/gpu/drm/bridge/cdns-dsi.c
> index ce9496d13986..4b73d0969468 100644
> --- a/drivers/gpu/drm/bridge/cdns-dsi.c
> +++ b/drivers/gpu/drm/bridge/cdns-dsi.c
> @@ -8,11 +8,13 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/gpu/drm/drm_modeset_helper.c 
> b/drivers/gpu/drm/drm_modeset_helper.c
> index 9150fa385bba..9bc1ef788c77 100644
> --- a/drivers/gpu/drm/drm_modeset_helper.c
> +++ b/drivers/gpu/drm/drm_modeset_helper.c
> @@ -23,8 +23,10 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
> +#include 
>  
>  /**
>   * DOC: aux kms helpers
> diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c 
> b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> index 534a128a869d..8010ed702509 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> @@ -10,6 +10,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/include/drm/drm_modeset_helper.h 
> b/include/drm/drm_modeset_helper.h
> index efa337f03129..995fd981cab0 100644
> --- a/include/drm/drm_modeset_helper.h
> +++ b/include/drm/drm_modeset_helper.h
> @@ -23,7 +23,11 @@
>  #ifndef __DRM_KMS_HELPER_H__
>  #define __DRM_KMS_HELPER_H__
>  
> -#include 
> +struct drm_crtc;
> +struct drm_crtc_funcs;
> +struct drm_device;
> +struct drm_framebuffer;
> +struct drm_mode_fb_cmd2;
>  
>  void drm_helper_move_panel_connectors_to_head(struct drm_device *);
>  
> -- 
> 2.12.0
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 15/15] drm/bochs: reserve bo for pin/unpin

[Daniel Vetter]

On Wed, Jan 9, 2019 at 9:52 PM Gerd Hoffmann  wrote:
>
>   Hi,
>
> > > If I understand things correctly it is valid to set all import/export
> > > callbacks (prime_handle_to_fd, prime_fd_to_handle,
> > > gem_prime_get_sg_table, gem_prime_import_sg_table) to NULL when not
> > > supporting dma-buf import/export and still advertise DRIVER_PRIME to
> > > indicate the other prime callbacks are supported (so generic fbdev
> > > emulation can use gem_prime_vmap etc).  Is that correct?
> >
> > I'm not sure how much that's a good idea ... Never thought about it
> > tbh. All the fbdev/dma-buf stuff has plenty of hacks and
> > inconsistencies still, so I guess we can't make it much worse really.
>
> Setting prime_handle_to_fd + prime_fd_to_handle to NULL has the effect
> that drm stops advertising DRM_PRIME_CAP_{IMPORT,EXPORT} to userspace.
>
> Which looks better to me than telling userspace we support it then throw
> errors unconditionally when userspace tries to use that.
>
> > > Is it possible to export TTM_PL_VRAM objects (with backing storage being
> > > a pci memory bar)?  If so, how?
> >
> > Not really in general. amdgpu upcasts to amdgpu_bo (if it's amgpu BO)
> > and then knows the internals so it can do a proper pci peer2peer
> > mapping. Or at least there's been lots of patches floating around to
> > make that happen.
>
> That is limited to bo sharing between two amdgpu devices, correct?
>
> > I think other drivers migrate the bo out of VRAM.
>
> Well, that doesn't look too useful.  bochs and qxl virtual hardware
> can't access buffers outside VRAM.  So, while I could migrate the
> buffers to RAM (via memcpy) when exporting they would at the same time
> become unusable for the GPU ...
>
> > > On importing:
> > >
> > > Importing into TTM_PL_TT object looks easy again, at least when the
> > > object is actually stored in RAM.  What if not?
> >
> > They are all supposed to be stored in RAM. Note that all current ttm
> > importers totally break the abstraction, by taking the sg list,
> > throwing the dma mapping away and assuming there's a struct page
> > backing it. Would be good if we could stop spreading that abuse - the
> > dma-buf interfaces have been modelled after the ttm bo interfaces, so
> > shouldn't be too hard to wire this up correctly.
>
> Ok.  With virtio-gpu (where objects are backed by RAM pages anyway)
> wiring this up should be easy.
>
> But given there is no correct sample code I can look at it would be cool
> if you could give some more hints how this is supposed to work.  The
> gem_prime_import_sg_table() callback gets a sg list passed in after all,
> so I probably would have tried to take the sg list too ...

I'm not a fan of that helper either, that's really the broken part
imo. i915 doesn't use it. It's a midlayer so that the nvidia blob can
avoid directly touching the EXPORT_SYMBOL_GPL dma-buf symbols, afaiui
there's really no other solid reason for it. What the new gem cma
helpers does is imo much better (it still uses the import_sg_table
midlayer, but oh well).

For ttm you'd need to make sure that all the various ttm cpu side
access functions also all go through the relevant dma-buf interfaces,
and not through the struct page list fished out of the sgt. That was
at least the idea, long ago.

> > > Importing into TTM_PL_VRAM:  Impossible I think, without copying over
> > > the data.  Should that be done?  If so, how?  Or is it better to just
> > > not support import then?
> >
> > Hm, since you ask about TTM concepts and not what this means in terms
> > of dma-buf:
>
> Ok, more details on the quesion:
>
> dma-buf: whatever the driver gets passed into the
> gem_prime_import_sg_table() callback.
>
> import into TTM_PL_VRAM: qemu driver which supports VRAM storage only
> (bochs, qxl), so the buffer has to be stored there if we want do
> something with it (like scanning out to a crtc).
>
> > As long as you upcast to the ttm_bo you can do whatever
> > you want to really.
>
> Well, if the dma-buf comes from another device (say export vgem bo, then
> try import into bochs/qxl/virtio) I can't upcast.

In that case you'll in practice only get system RAM, and you're not
allowed to move it (dma-buf is meant to be zero-copy after all). If
your hw can't scan these out directly, then userspace needs to arrange
for a buffer copy into a native buffer somehow (that's how Xorg prime
works at least I think). No idea whether your virtual gpus can make
use of that directly. You might also get some pci peer2peer range in
the future, but it's strictly opt-in (because there's too many dma-buf
importers that just blindly assume there's a struct page behind the
sgt).

> When the dma-buf comes from the same device drm_gem_prime_import_dev()
> will notice and take a shortcut (skip import, just increase refcount
> instead), so I don't have to worry about that case in the
> gem_prime_import_sg_table() callback.

You can also upcast if it's from the same driver, not just same device.
-Daniel

> > But with plain 

Re: [RESEND PATCH v2] drm/gem: Mark pinned pages as unevictable

[Chris Wilson]

Quoting Kuo-Hsin Yang (2019-01-08 07:45:17)
> The gem drivers use shmemfs to allocate backing storage for gem objects.
> On Samsung Chromebook Plus, the drm/rockchip driver may call
> rockchip_gem_get_pages -> drm_gem_get_pages -> shmem_read_mapping_page
> to pin a lot of pages, breaking the page reclaim mechanism and causing
> oom-killer invocation.
> 
> E.g. when the size of a zone is 3.9 GiB, the inactive_ratio is 5. If
> active_anon / inactive_anon < 5 and all pages in the inactive_anon lru
> are pinned, page reclaim would keep scanning inactive_anon lru without
> reclaiming memory. It breaks page reclaim when the rockchip driver only
> pins about 1/6 of the anon lru pages.
> 
> Mark these pinned pages as unevictable to avoid the premature oom-killer
> invocation. See also similar patch on i915 driver [1].
> 
> [1]: 
> https://patchwork.freedesktop.org/patch/msgid/20181106132324.17390-1-ch...@chris-wilson.co.uk
> 
> Signed-off-by: Kuo-Hsin Yang 
> Cc: Daniel Vetter 
> Cc: Chris Wilson 
> Reviewed-by: Chris Wilson 

No objections, so pushed to drm-misc-next. Let the screaming begin.
Thanks for the patch!
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 04/12] drm: move drm_can_sleep() to drm_util.h

[Daniel Vetter]

On Tue, Jan 08, 2019 at 08:29:31PM +0100, Sam Ravnborg wrote:
> Move drm_can_sleep() out of drmP.h to allow users
> to get rid of the drmP.h include.
> 
> There was no header file that was a good match for this helper function.
> So add this to drm_util with the relevant includes.
> 
> Update comments to use kernel-doc style.
> Add FIXME to drm_can_sleep and add note
> that this function should not be used in new code
> 
> Add include of drm_util.h to all users.
> 
> Signed-off-by: Sam Ravnborg 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: Sean Paul 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Alex Deucher 
> Cc: "Christian König" 
> Cc: "David (ChunMing) Zhou" 
> Cc: Gerd Hoffmann 
> Cc: Rob Clark 
> Cc: Tomi Valkeinen 
> Cc: Eric Anholt 
> ---
>  drivers/gpu/drm/amd/amdgpu/atom.c   |  2 ++
>  drivers/gpu/drm/ast/ast_fb.c|  2 ++
>  drivers/gpu/drm/cirrus/cirrus_fbdev.c   |  1 +
>  drivers/gpu/drm/drm_flip_work.c |  1 +
>  drivers/gpu/drm/mgag200/mgag200_fb.c|  1 +
>  drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c|  1 +
>  drivers/gpu/drm/omapdrm/omap_fbdev.c|  1 +
>  drivers/gpu/drm/qxl/qxl_cmd.c   |  2 ++
>  drivers/gpu/drm/radeon/atom.c   |  2 ++
>  drivers/gpu/drm/radeon/radeon_legacy_encoders.c |  1 +
>  drivers/gpu/drm/vc4/vc4_drv.h   |  1 +
>  include/drm/drmP.h  |  8 -
>  include/drm/drm_util.h  | 42 
> -
>  13 files changed, 56 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/atom.c 
> b/drivers/gpu/drm/amd/amdgpu/atom.c
> index e9934de1b9cf..dd30f4e61a8c 100644
> --- a/drivers/gpu/drm/amd/amdgpu/atom.c
> +++ b/drivers/gpu/drm/amd/amdgpu/atom.c
> @@ -27,6 +27,8 @@
>  #include 
>  #include 
>  
> +#include 
> +
>  #define ATOM_DEBUG
>  
>  #include "atom.h"
> diff --git a/drivers/gpu/drm/ast/ast_fb.c b/drivers/gpu/drm/ast/ast_fb.c
> index a80bca1a857f..eb66bf7d3e63 100644
> --- a/drivers/gpu/drm/ast/ast_fb.c
> +++ b/drivers/gpu/drm/ast/ast_fb.c
> @@ -39,7 +39,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
> +
>  #include "ast_drv.h"
>  
>  static void ast_dirty_update(struct ast_fbdev *afbdev,
> diff --git a/drivers/gpu/drm/cirrus/cirrus_fbdev.c 
> b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
> index 4dd499c7d1ba..79fea1b8bc14 100644
> --- a/drivers/gpu/drm/cirrus/cirrus_fbdev.c
> +++ b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
> @@ -10,6 +10,7 @@
>   */
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> diff --git a/drivers/gpu/drm/drm_flip_work.c b/drivers/gpu/drm/drm_flip_work.c
> index 12dea16f22a8..3da3bf5af405 100644
> --- a/drivers/gpu/drm/drm_flip_work.c
> +++ b/drivers/gpu/drm/drm_flip_work.c
> @@ -22,6 +22,7 @@
>   */
>  
>  #include 
> +#include 
>  #include 
>  
>  /**
> diff --git a/drivers/gpu/drm/mgag200/mgag200_fb.c 
> b/drivers/gpu/drm/mgag200/mgag200_fb.c
> index 30726c9fe28c..6893934b26c0 100644
> --- a/drivers/gpu/drm/mgag200/mgag200_fb.c
> +++ b/drivers/gpu/drm/mgag200/mgag200_fb.c
> @@ -12,6 +12,7 @@
>   */
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c 
> b/drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c
> index 96c2b828dba4..fa2d1d8995ee 100644
> --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c
> +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c
> @@ -16,6 +16,7 @@
>   * this program.  If not, see .
>   */
>  
> +#include 
>  
>  #include "mdp5_kms.h"
>  #include "mdp5_smp.h"
> diff --git a/drivers/gpu/drm/omapdrm/omap_fbdev.c 
> b/drivers/gpu/drm/omapdrm/omap_fbdev.c
> index aee99194499f..851c59f07eb1 100644
> --- a/drivers/gpu/drm/omapdrm/omap_fbdev.c
> +++ b/drivers/gpu/drm/omapdrm/omap_fbdev.c
> @@ -16,6 +16,7 @@
>   */
>  
>  #include 
> +#include 
>  #include 
>  
>  #include "omap_drv.h"
> diff --git a/drivers/gpu/drm/qxl/qxl_cmd.c b/drivers/gpu/drm/qxl/qxl_cmd.c
> index dffc5093ff16..2e100f644236 100644
> --- a/drivers/gpu/drm/qxl/qxl_cmd.c
> +++ b/drivers/gpu/drm/qxl/qxl_cmd.c
> @@ -25,6 +25,8 @@
>  
>  /* QXL cmd/ring handling */
>  
> +#include 
> +
>  #include "qxl_drv.h"
>  #include "qxl_object.h"
>  
> diff --git a/drivers/gpu/drm/radeon/atom.c b/drivers/gpu/drm/radeon/atom.c
> index e55cbeee7a53..ac98ad561870 100644
> --- a/drivers/gpu/drm/radeon/atom.c
> +++ b/drivers/gpu/drm/radeon/atom.c
> @@ -27,6 +27,8 @@
>  #include 
>  #include 
>  
> +#include 
> +
>  #define ATOM_DEBUG
>  
>  #include "atom.h"
> diff --git a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c 
> b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
> index 222a1fa41d7c..7e3257e8fd56 100644
> --- a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
> +++ b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
> @@ -24,6 +24,7 @@
>   *  Alex Deucher
>   */
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 

[Bug 108521] RX 580 as eGPU amdgpu: gpu post error!

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=108521

--- Comment #37 from Robert Strube  ---
One additional comment, the user with the XPS 9370 was able to get the RX 580
working as an eGPU flawlessly in Windows 10.  This lends some credibility to
the theory that it might not actually be a BIOS issue - unless the BIOS bug is
worked around in Windows 10 drivers.  Please see here for additional
information:

https://forum.manjaro.org/t/rx-580-in-a-thunderbolt-egpu-dock/58210/30

I'm planning on purchasing an Vega 56 or 64 in the near future so I can
continue to attempt to troubleshoot the issue.

Rob

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 0/7] drm: Remove drm_mode_object dependency from drm_display_mode

[Daniel Vetter]

On Thu, Dec 20, 2018 at 10:24:27AM -0200, Shayenne Moura wrote:
> This patch serie removes drm_mode_object dependency from
> drm_display_mode struct. This is part of KMS cleanup.
> 
> Shayenne Moura (7):
>   drm: msm: Cleanup drm_display_mode print str
>   drm: omapdrm: Cleanup drm_display_mode print str
>   drm: meson: Cleanup on drm_display_mode print str
>   drm: sti: Cleanup drm_display_mode print str
>   drm: i915: Cleanup drm_display_mode print str
>   drm: Remove use of drm_mode_object
>   drm: Complete remove drm_mode_object dependency

Ok, merged patches 2-5 to drm-misc-next. Sorry for the delay, caught a
cold and was out of service past few days :-/

Can you pls fix the compile issue in the msm patch? Looks like that wasn't
properly compile-tested. For a howto, see:

https://blog.ffwll.ch/2016/02/arm-kernel-cross-compiling.html

and make sure MSM is enabled in the .config. You can configure the
cross-compiled kernel with e.g.

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- menuconfig

Thanks, Daniel
> 
>  drivers/gpu/drm/drm_crtc_helper.c |  5 ++---
>  drivers/gpu/drm/drm_modes.c   |  9 
>  drivers/gpu/drm/i915/i915_debugfs.c   |  9 +---
>  drivers/gpu/drm/meson/meson_dw_hdmi.c | 12 +++
>  drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c | 10 ++---
>  .../gpu/drm/msm/disp/mdp4/mdp4_dsi_encoder.c  |  9 +---
>  .../gpu/drm/msm/disp/mdp4/mdp4_dtv_encoder.c  |  9 +---
>  .../gpu/drm/msm/disp/mdp4/mdp4_lcdc_encoder.c |  9 +---
>  .../gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c  |  9 +---
>  drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c |  9 +---
>  drivers/gpu/drm/msm/disp/mdp5/mdp5_encoder.c  |  9 +---
>  drivers/gpu/drm/msm/dsi/dsi_manager.c |  9 +---
>  drivers/gpu/drm/msm/edp/edp_bridge.c  |  9 +---
>  drivers/gpu/drm/omapdrm/omap_connector.c  |  9 ++--
>  drivers/gpu/drm/omapdrm/omap_crtc.c   |  8 ++-
>  drivers/gpu/drm/sti/sti_crtc.c| 16 --
>  include/drm/drm_modes.h   | 21 +++
>  17 files changed, 27 insertions(+), 144 deletions(-)
> 
> -- 
> 2.17.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 108521] RX 580 as eGPU amdgpu: gpu post error!

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=108521

--- Comment #36 from Robert Strube  ---
(In reply to Robert Strube from comment #34)
> Created attachment 143044 [details]
> dmesg log amdgpu.dpm=0 with 580 as eGPU
> 
> Another user is reporting a similar problem with a different Dell laptop
> (the XPS 9370).  He provided two dmesg log files.  This one has amdgpu=0.

Meant to say amdgpu.dpm=0 as a boot paramater.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 108521] RX 580 as eGPU amdgpu: gpu post error!

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=108521

Robert Strube  changed:

   What|Removed |Added

 Attachment #143044|dmesg log amdgpu=0 with 580 |dmesg log amdgpu.dpm=0 with
description|as eGPU |580 as eGPU

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 108521] RX 580 as eGPU amdgpu: gpu post error!

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=108521

--- Comment #35 from Robert Strube  ---
Created attachment 143045
  --> https://bugs.freedesktop.org/attachment.cgi?id=143045=edit
dmesg log pci=noacpi with 580 as eGPU

Another user has reported a similar problem with a different laptop (XPS 9370).
 He provided to dmesg log files.  This one has pci=noacpi set as a kernel boot
parameter.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 108521] RX 580 as eGPU amdgpu: gpu post error!

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=108521

--- Comment #34 from Robert Strube  ---
Created attachment 143044
  --> https://bugs.freedesktop.org/attachment.cgi?id=143044=edit
dmesg log amdgpu=0 with 580 as eGPU

Another user is reporting a similar problem with a different Dell laptop (the
XPS 9370).  He provided two dmesg log files.  This one has amdgpu=0.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 15/15] drm/bochs: reserve bo for pin/unpin

[Gerd Hoffmann]

  Hi,

> > If I understand things correctly it is valid to set all import/export
> > callbacks (prime_handle_to_fd, prime_fd_to_handle,
> > gem_prime_get_sg_table, gem_prime_import_sg_table) to NULL when not
> > supporting dma-buf import/export and still advertise DRIVER_PRIME to
> > indicate the other prime callbacks are supported (so generic fbdev
> > emulation can use gem_prime_vmap etc).  Is that correct?
> 
> I'm not sure how much that's a good idea ... Never thought about it
> tbh. All the fbdev/dma-buf stuff has plenty of hacks and
> inconsistencies still, so I guess we can't make it much worse really.

Setting prime_handle_to_fd + prime_fd_to_handle to NULL has the effect
that drm stops advertising DRM_PRIME_CAP_{IMPORT,EXPORT} to userspace.

Which looks better to me than telling userspace we support it then throw
errors unconditionally when userspace tries to use that.

> > Is it possible to export TTM_PL_VRAM objects (with backing storage being
> > a pci memory bar)?  If so, how?
> 
> Not really in general. amdgpu upcasts to amdgpu_bo (if it's amgpu BO)
> and then knows the internals so it can do a proper pci peer2peer
> mapping. Or at least there's been lots of patches floating around to
> make that happen.

That is limited to bo sharing between two amdgpu devices, correct?

> I think other drivers migrate the bo out of VRAM.

Well, that doesn't look too useful.  bochs and qxl virtual hardware
can't access buffers outside VRAM.  So, while I could migrate the
buffers to RAM (via memcpy) when exporting they would at the same time
become unusable for the GPU ...

> > On importing:
> >
> > Importing into TTM_PL_TT object looks easy again, at least when the
> > object is actually stored in RAM.  What if not?
> 
> They are all supposed to be stored in RAM. Note that all current ttm
> importers totally break the abstraction, by taking the sg list,
> throwing the dma mapping away and assuming there's a struct page
> backing it. Would be good if we could stop spreading that abuse - the
> dma-buf interfaces have been modelled after the ttm bo interfaces, so
> shouldn't be too hard to wire this up correctly.

Ok.  With virtio-gpu (where objects are backed by RAM pages anyway)
wiring this up should be easy.

But given there is no correct sample code I can look at it would be cool
if you could give some more hints how this is supposed to work.  The
gem_prime_import_sg_table() callback gets a sg list passed in after all,
so I probably would have tried to take the sg list too ...

> > Importing into TTM_PL_VRAM:  Impossible I think, without copying over
> > the data.  Should that be done?  If so, how?  Or is it better to just
> > not support import then?
> 
> Hm, since you ask about TTM concepts and not what this means in terms
> of dma-buf:

Ok, more details on the quesion:

dma-buf: whatever the driver gets passed into the
gem_prime_import_sg_table() callback.

import into TTM_PL_VRAM: qemu driver which supports VRAM storage only
(bochs, qxl), so the buffer has to be stored there if we want do
something with it (like scanning out to a crtc).

> As long as you upcast to the ttm_bo you can do whatever
> you want to really.

Well, if the dma-buf comes from another device (say export vgem bo, then
try import into bochs/qxl/virtio) I can't upcast.

When the dma-buf comes from the same device drm_gem_prime_import_dev()
will notice and take a shortcut (skip import, just increase refcount
instead), so I don't have to worry about that case in the
gem_prime_import_sg_table() callback.

> But with plain dma-buf this doesn't work right now
> (least because ttm assumes it gets system RAM on import, in theory you
> could put the peer2peer dma mapping into the sg list and it should
> work).

Well, qemu display devices don't have peer2peer dma support.
So I guess the answer is "doesn't work".

cheers,
  Gerd

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

Re: [RFC] Getting OpenChrome DRM mainlined into Linux kernel tree

[Sean Paul]

On Wed, Jan 09, 2019 at 09:39:45PM +0100, Daniel Vetter wrote:
> Hi Kevin,
> 
> On Wed, Jan 09, 2019 at 06:09:00PM +0100, Kevin Brace wrote:
> > Hi Sean,
> > 
> > I do recall seeing you at XDC2017, I do not believe I spoke with you at
> > the event.  I will not name the name, but I had one developer who
> > strongly asked me to convert to atomic mode setting, but I refused due
> > to the state of the code at the time.
> 
> That was at least me and Ben Skeggs. No point playing games, we're doing
> open discussions here in the gpu subsystem.
> 
> > Now, the KMS device support is mostly comparable to the existing UMS
> > code path, so I can soon consider implementing universal plane and
> > atomic mode setting.  I am okay with the OpenChrome DRM not being
> > activated initially (i.e.,
> > Displaying "(Experimental)" status when running menuconfig), but I do
> > want it directly inserted into the DRM tree from day one after the code
> > is pulled in. (i.e., not getting inserted into the "staging" tree) I
> > believe the current code quality is good enough for this arrangement.
> 
> Given how much cleaner the atomic helpers are, and how much simpler the
> resulting drivers tend to be, I still think that's a bad idea. We do have
> vboxvideo merged into staging, which still a non-atomic driver, but I
> don't think that's helping anyone. It's definitely hurting refactoring to
> have a driver outside of drm. And within drm imo a new non-atomic driver
> doesn't make sense.

Yeah, given the pain experienced with vboxvideo in the past half-year, I'd
like to reverse my statement from June and vote against putting this in
staging.

We've waited this long for the openchrome stuff, we can probably wait a bit
longer until it's at least basically atomic.

Sean

> 
> I've also never seen the code yet on dri-devel, so can't really give more
> specific advise.
> 
> Cheers, Daniel
> 
> > 
> > Regards,
> > 
> > Kevin Brace
> > Brace Computer Laboratory blog
> > https://bracecomputerlab.com
> > 
> > 
> > > Sent: Wednesday, June 13, 2018 at 1:07 PM
> > > From: "Sean Paul" 
> > > To: kevinbr...@gmx.com
> > > Cc: "Dave Airlie" , dri-devel 
> > > , openchrome-de...@lists.freedesktop.org
> > > Subject: Re: [RFC] Getting OpenChrome DRM mainlined into Linux kernel tree
> > >
> > > I think I was one of those developers asking you to switch to atomic
> > > (iirc, i encouraged you to start working on kms instead of ums). I
> > > know this is a personal project that you've been working on in your
> > > spare time (which is awesome!), so while I still encourage you to
> > > convert the driver, I don't have a problem with you doing the
> > > conversion in mainline. I think hiding under staging until the
> > > conversion is complete is a pretty reasonable compromise.
> > > 
> > > Sean
> > > 
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/4] drm/tinydrm: Use damage helper for dirtyfb

[Daniel Vetter]

On Wed, Jan 9, 2019 at 6:50 PM Noralf Trønnes  wrote:
>
> Hi,
>
> I was really pleased to see that the damage helper had landed. Now I can
> do framebuffer flushing solely through the display pipe functions. This
> prepares the ground for the removal of struct tinydrm_device in my next
> series.

Awesome stuff!

> Note:
> The damage helper isn't in drm-misc-next yet, it will show up when -rc1
> arrives there.

Maxime, can you pls do the backmerge for Noralf, with the above reason?

$ dim backmerge drm-misc-next drm/drm-next

should get the job  done.

Cheers, Daniel
>
> Noralf.
>
> Noralf Trønnes (4):
>   drm/gem-fb-helper: Add drm_gem_fb_create_with_dirty()
>   drm/damage-helper: Add drm_atomic_helper_damage_merged()
>   drm/tinydrm: Use struct drm_rect
>   drm/tinydrm: Use damage helper for dirtyfb
>
>  drivers/gpu/drm/drm_damage_helper.c   |  43 ++
>  drivers/gpu/drm/drm_gem_framebuffer_helper.c  |  47 +-
>  drivers/gpu/drm/tinydrm/core/tinydrm-core.c   |  21 +--
>  .../gpu/drm/tinydrm/core/tinydrm-helpers.c| 100 +
>  drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c   |  30 
>  drivers/gpu/drm/tinydrm/hx8357d.c |   2 +-
>  drivers/gpu/drm/tinydrm/ili9225.c | 138 +++---
>  drivers/gpu/drm/tinydrm/ili9341.c |   2 +-
>  drivers/gpu/drm/tinydrm/mi0283qt.c|   2 +-
>  drivers/gpu/drm/tinydrm/mipi-dbi.c|  87 +++
>  drivers/gpu/drm/tinydrm/repaper.c |  42 +++---
>  drivers/gpu/drm/tinydrm/st7586.c  |  73 -
>  drivers/gpu/drm/tinydrm/st7735r.c |   2 +-
>  include/drm/drm_damage_helper.h   |   3 +
>  include/drm/drm_gem_framebuffer_helper.h  |   3 +
>  include/drm/tinydrm/mipi-dbi.h|   5 +-
>  include/drm/tinydrm/tinydrm-helpers.h |  20 +--
>  include/drm/tinydrm/tinydrm.h |  26 
>  18 files changed, 281 insertions(+), 365 deletions(-)
>
> --
> 2.20.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/4] drm/gem-fb-helper: Add drm_gem_fb_create_with_dirty()

[Daniel Vetter]

On Wed, Jan 09, 2019 at 06:49:53PM +0100, Noralf Trønnes wrote:
> This adds a .fb_create helper that sets the .dirty callback to
> drm_atomic_helper_dirtyfb().
> 
> Signed-off-by: Noralf Trønnes 
> ---
>  drivers/gpu/drm/drm_gem_framebuffer_helper.c | 47 +---
>  include/drm/drm_gem_framebuffer_helper.h |  3 ++
>  2 files changed, 44 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c 
> b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> index acb466d25afc..4edd0261e507 100644
> --- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> +++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> @@ -17,6 +17,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -136,10 +137,9 @@ EXPORT_SYMBOL(drm_gem_fb_create_handle);
>   * @mode_cmd: Metadata from the userspace framebuffer creation request
>   * @funcs: vtable to be used for the new framebuffer object
>   *
> - * This can be used to set _framebuffer_funcs for drivers that need the
> - * _framebuffer_funcs.dirty callback. Use drm_gem_fb_create() if you 
> don't
> - * need to change _framebuffer_funcs.
> - * The function does buffer size validation.
> + * This function can be used to set _framebuffer_funcs for drivers that 
> need
> + * custom framebuffer callbacks. Use drm_gem_fb_create() if you don't need to
> + * change _framebuffer_funcs. The function does buffer size validation.
>   *
>   * Returns:
>   * Pointer to a _framebuffer on success or an error pointer on failure.
> @@ -215,8 +215,8 @@ static const struct drm_framebuffer_funcs 
> drm_gem_fb_funcs = {
>   *
>   * If your hardware has special alignment or pitch requirements these should 
> be
>   * checked before calling this function. The function does buffer size
> - * validation. Use drm_gem_fb_create_with_funcs() if you need to set
> - * _framebuffer_funcs.dirty.
> + * validation. Use drm_gem_fb_create_with_dirty() if you need framebuffer
> + * flushing.
>   *
>   * Drivers can use this as their _mode_config_funcs.fb_create callback.
>   * The ADDFB2 IOCTL calls into this callback.
> @@ -233,6 +233,41 @@ drm_gem_fb_create(struct drm_device *dev, struct 
> drm_file *file,
>  }
>  EXPORT_SYMBOL_GPL(drm_gem_fb_create);
>  
> +static const struct drm_framebuffer_funcs drm_gem_fb_funcs_dirtyfb = {
> + .destroy= drm_gem_fb_destroy,
> + .create_handle  = drm_gem_fb_create_handle,
> + .dirty  = drm_atomic_helper_dirtyfb,
> +};
> +
> +/**
> + * drm_gem_fb_create_with_dirty() - Helper function for the
> + *   _mode_config_funcs.fb_create callback
> + * @dev: DRM device
> + * @file: DRM file that holds the GEM handle(s) backing the framebuffer
> + * @mode_cmd: Metadata from the userspace framebuffer creation request
> + *
> + * This function creates a new framebuffer object described by
> + * _mode_fb_cmd2. This description includes handles for the buffer(s)
> + * backing the framebuffer. drm_atomic_helper_dirtyfb() is used for the dirty
> + * callback giving framebuffer flushing through the atomic machinery. Use
> + * drm_gem_fb_create() if you don't need the dirty callback.
> + * The function does buffer size validation.
> + *
> + * Drivers can use this as their _mode_config_funcs.fb_create callback.
> + * The ADDFB2 IOCTL calls into this callback.

I think would be good to add:

"Drivers should also call drm_plane_enable_fb_damage_clips() on all planes
to enable userspace to use damage clips also with the ATOMIC IOCTL."

It's a bit annoying that drivers have to make that separate call too (so
some risk for accidents), but I didn't see a good way to avoid that.

With the documentation nit, on the entire series:

Acked-by: Daniel Vetter 
> + *
> + * Returns:
> + * Pointer to a _framebuffer on success or an error pointer on failure.
> + */
> +struct drm_framebuffer *
> +drm_gem_fb_create_with_dirty(struct drm_device *dev, struct drm_file *file,
> +  const struct drm_mode_fb_cmd2 *mode_cmd)
> +{
> + return drm_gem_fb_create_with_funcs(dev, file, mode_cmd,
> + _gem_fb_funcs_dirtyfb);
> +}
> +EXPORT_SYMBOL_GPL(drm_gem_fb_create_with_dirty);
> +
>  /**
>   * drm_gem_fb_prepare_fb() - Prepare a GEM backed framebuffer
>   * @plane: Plane
> diff --git a/include/drm/drm_gem_framebuffer_helper.h 
> b/include/drm/drm_gem_framebuffer_helper.h
> index a38de7eb55b4..7f307e834eef 100644
> --- a/include/drm/drm_gem_framebuffer_helper.h
> +++ b/include/drm/drm_gem_framebuffer_helper.h
> @@ -25,6 +25,9 @@ drm_gem_fb_create_with_funcs(struct drm_device *dev, struct 
> drm_file *file,
>  struct drm_framebuffer *
>  drm_gem_fb_create(struct drm_device *dev, struct drm_file *file,
> const struct drm_mode_fb_cmd2 *mode_cmd);
> +struct drm_framebuffer *
> +drm_gem_fb_create_with_dirty(struct drm_device *dev, struct drm_file *file,
> +  const struct drm_mode_fb_cmd2 *mode_cmd);
>  

[pull] amdgpu drm-fixes-5.0

[Alex Deucher]

Hi Dave, Daniel,

Fixes for 5.0.  Highlights:
- Powerplay fixes
- Virtual display pinning fixes
- Golden register updates for vega
- Pitch and gem size validation fixes
- Fix for error case in sr-iov init
- Disable page tables in system memory on RV due to issues with IOMMU
  reported on some platforms

The following changes since commit 74136a3d47f51ae72ee8b9ebc1ec2a29bcf30676:

  Merge branch 'drm-next-4.21' of git://people.freedesktop.org/~agd5f/linux 
into drm-next (2018-12-31 08:29:54 +1000)

are available in the Git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-fixes-5.0

for you to fetch changes up to 1c1eba86339c8517814863bc7dd21e2661a84e77:

  drm/amdgpu: disable system memory page tables for now (2019-01-09 15:01:18 
-0500)


Christian König (1):
  drm/amdgpu: disable system memory page tables for now

Emily Deng (3):
  drm/amdgpu/virtual_dce: No need to pin the fb's bo
  drm/amdgpu/virtual_dce: No need to pin the cursor bo
  drm/amdgpu/sriov:Correct pfvf exchange logic

Evan Quan (5):
  drm/amd/powerplay: support BOOTUP_DEFAULT power profile mode
  drm/amd/powerplay: update OD support flag for SKU with no OD capabilities
  drm/amd/powerplay: create pp_od_clk_voltage device file under OD support
  drm/amd/powerplay: avoid possible buffer overflow
  drm/amd/powerplay: drop the unnecessary uclk hard min setting

Jim Qu (1):
  drm/amdgpu: set WRITE_BURST_LENGTH to 64B to workaround SDMA1 hang

Kent Russell (1):
  drm/amdgpu: Cleanup 2 compiler warnings

Likun Gao (1):
  drm/amdgpu: make gfx9 enter into rlc safe mode when set MGCG

Tao Zhou (1):
  drm/amdgpu: fix CPDMA hang in PRT mode for VEGA20

Tiecheng Zhou (1):
  drm/amdgpu/gfx_v8_0: Reorder the gfx, kiq and kcq rings test sequence

Yu Zhao (2):
  drm/amdgpu: validate user pitch alignment
  drm/amdgpu: validate user GEM object size

 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 12 +++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c| 38 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 22 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c |  3 --
 drivers/gpu/drm/amd/amdgpu/dce_virtual.c   | 17 ++--
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c  | 48 +++---
 drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c  | 14 ---
 drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c  |  2 +-
 drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c |  3 +-
 drivers/gpu/drm/amd/include/kgd_pp_interface.h | 13 +++---
 drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c| 24 ++-
 drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c   |  8 ++--
 drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 12 +++---
 drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c | 34 ++-
 drivers/gpu/drm/amd/powerplay/inc/hwmgr.h  |  2 +-
 15 files changed, 156 insertions(+), 96 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] Getting OpenChrome DRM mainlined into Linux kernel tree

[Daniel Vetter]

Hi Kevin,

On Wed, Jan 09, 2019 at 06:09:00PM +0100, Kevin Brace wrote:
> Hi Sean,
> 
> I do recall seeing you at XDC2017, I do not believe I spoke with you at
> the event.  I will not name the name, but I had one developer who
> strongly asked me to convert to atomic mode setting, but I refused due
> to the state of the code at the time.

That was at least me and Ben Skeggs. No point playing games, we're doing
open discussions here in the gpu subsystem.

> Now, the KMS device support is mostly comparable to the existing UMS
> code path, so I can soon consider implementing universal plane and
> atomic mode setting.  I am okay with the OpenChrome DRM not being
> activated initially (i.e.,
> Displaying "(Experimental)" status when running menuconfig), but I do
> want it directly inserted into the DRM tree from day one after the code
> is pulled in. (i.e., not getting inserted into the "staging" tree) I
> believe the current code quality is good enough for this arrangement.

Given how much cleaner the atomic helpers are, and how much simpler the
resulting drivers tend to be, I still think that's a bad idea. We do have
vboxvideo merged into staging, which still a non-atomic driver, but I
don't think that's helping anyone. It's definitely hurting refactoring to
have a driver outside of drm. And within drm imo a new non-atomic driver
doesn't make sense.

I've also never seen the code yet on dri-devel, so can't really give more
specific advise.

Cheers, Daniel

> 
> Regards,
> 
> Kevin Brace
> Brace Computer Laboratory blog
> https://bracecomputerlab.com
> 
> 
> > Sent: Wednesday, June 13, 2018 at 1:07 PM
> > From: "Sean Paul" 
> > To: kevinbr...@gmx.com
> > Cc: "Dave Airlie" , dri-devel 
> > , openchrome-de...@lists.freedesktop.org
> > Subject: Re: [RFC] Getting OpenChrome DRM mainlined into Linux kernel tree
> >
> > I think I was one of those developers asking you to switch to atomic
> > (iirc, i encouraged you to start working on kms instead of ums). I
> > know this is a personal project that you've been working on in your
> > spare time (which is awesome!), so while I still encourage you to
> > convert the driver, I don't have a problem with you doing the
> > conversion in mainline. I think hiding under staging until the
> > conversion is complete is a pretty reasonable compromise.
> > 
> > Sean
> > 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 1/4] drm/vc4: Wait for display list synchronization when completing commit

[Daniel Vetter]

On Wed, Jan 09, 2019 at 05:52:20PM +0100, Paul Kocialkowski wrote:
> Hi Daniel,
> 
> On Tue, 2019-01-08 at 19:21 +0100, Daniel Vetter wrote:
> > On Tue, Jan 8, 2019 at 3:51 PM Paul Kocialkowski
> >  wrote:
> > > During an atomic commit, the HVS is configured with a display list
> > > for the channel matching the associated CRTC. The Pixel Valve (CRTC)
> > > and encoder are also configured for the new setup at that time.
> > > While the Pixel Valve and encoder are reconfigured synchronously, the
> > > HVS is only reconfigured after the display list address (DISPLIST) has
> > > been updated to the current display list address (DISPLACTX), which is
> > > the responsibility of the hardware.
> > > 
> > > The time frame during which the HVS is still running on its previous
> > > configuration but the CRTC and encoder have been reconfigured already
> > > can lead to a number of synchronization issues. They will eventually
> > > cause errors reported on the FIFOs, such as underruns.
> > > 
> > > With underrun detection enabled (from Boris Brezillon's series), this
> > > leads to unreliable underrun detection with random false positives.
> > > 
> > > To ensure a coherent state, wait for each enabled channel of the HVS
> > > to synchronize its current display list address. This fixes the issue
> > > of random underrun reporting on commits.
> > > 
> > > Signed-off-by: Paul Kocialkowski 
> > > ---
> > >  drivers/gpu/drm/vc4/vc4_drv.h  |  1 +
> > >  drivers/gpu/drm/vc4/vc4_hvs.c  | 17 +
> > >  drivers/gpu/drm/vc4/vc4_kms.c  |  2 ++
> > >  drivers/gpu/drm/vc4/vc4_regs.h |  2 ++
> > >  4 files changed, 22 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
> > > index c24b078f0593..955f157f5ad0 100644
> > > --- a/drivers/gpu/drm/vc4/vc4_drv.h
> > > +++ b/drivers/gpu/drm/vc4/vc4_drv.h
> > > @@ -772,6 +772,7 @@ void vc4_irq_reset(struct drm_device *dev);
> > >  extern struct platform_driver vc4_hvs_driver;
> > >  void vc4_hvs_dump_state(struct drm_device *dev);
> > >  int vc4_hvs_debugfs_regs(struct seq_file *m, void *unused);
> > > +void vc4_hvs_sync_dlist(struct drm_device *dev);
> > > 
> > >  /* vc4_kms.c */
> > >  int vc4_kms_load(struct drm_device *dev);
> > > diff --git a/drivers/gpu/drm/vc4/vc4_hvs.c b/drivers/gpu/drm/vc4/vc4_hvs.c
> > > index 5d8c749c9749..1ba60b8e0c2d 100644
> > > --- a/drivers/gpu/drm/vc4/vc4_hvs.c
> > > +++ b/drivers/gpu/drm/vc4/vc4_hvs.c
> > > @@ -166,6 +166,23 @@ static int vc4_hvs_upload_linear_kernel(struct 
> > > vc4_hvs *hvs,
> > > return 0;
> > >  }
> > > 
> > > +void vc4_hvs_sync_dlist(struct drm_device *dev)
> > > +{
> > > +   struct vc4_dev *vc4 = to_vc4_dev(dev);
> > > +   unsigned int i;
> > > +   int ret;
> > > +
> > > +   for (i = 0; i < SCALER_CHANNELS_COUNT; i++) {
> > > +   if (!(HVS_READ(SCALER_DISPCTRLX(i)) & 
> > > SCALER_DISPCTRLX_ENABLE))
> > > +   continue;
> > > +
> > > +   ret = wait_for(HVS_READ(SCALER_DISPLACTX(i)) ==
> > > +  HVS_READ(SCALER_DISPLISTX(i)), 1000);
> > > +   WARN(ret, "Timeout waiting for channel %d display list 
> > > sync\n",
> > > +i);
> > > +   }
> > > +}
> > > +
> > >  static int vc4_hvs_bind(struct device *dev, struct device *master, void 
> > > *data)
> > >  {
> > > struct platform_device *pdev = to_platform_device(dev);
> > > diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
> > > index 0490edb192a1..2d66a2b57a91 100644
> > > --- a/drivers/gpu/drm/vc4/vc4_kms.c
> > > +++ b/drivers/gpu/drm/vc4/vc4_kms.c
> > > @@ -155,6 +155,8 @@ vc4_atomic_complete_commit(struct drm_atomic_state 
> > > *state)
> > > 
> > > drm_atomic_helper_commit_hw_done(state);
> > > 
> > > +   vc4_hvs_sync_dlist(dev);
> > 
> > From your description I'd have guessed you want this between when you
> > update the planes and the crtc, so somewhere between commit_planes()
> > and commit_modeset_enables(). At least I have no idea how waiting here
> > can prevent underruns, by this point there's no further hw programming
> > happening.
> 
> One thing that I did not mention is that the display list (that
> configures the planes) is only set at crtc_enable time (and taken into
> account by the hardware later).
> 
> However, even calling vc4_hvs_sync_dlist right at the end of
> crtc_enable doesn't do either (the old display list just sticks). It
> only seems to work after the HDMI encoder enable step and I don't know
> any good reason why.
> 
> I didn't find any description of when that dlist sync mechanism is
> supposed to take place and what particular event triggers it. Perhaps
> it is triggered by a signal originating from the encoder? If anyone has
> insight on the hardware, feel free to shed some light here :)

Maybe my concern wasn't clear: I have no idea why you need this exactly
and how your hw works. Only thing I meant to highlight is 

Re: [PATCH v7 0/6] arm64: dts: Add sdm845 GPU/GMU and SMMU

[Rob Clark]

On Wed, Jan 9, 2019 at 1:20 PM Doug Anderson  wrote:
>
> Hi Rob,
>
> On Tue, Dec 18, 2018 at 10:32 AM Jordan Crouse  wrote:
> >
> > Now that more of the sdm845 bindings are headed upstream this a refresh of
> > of https://patchwork.freedesktop.org/series/39308/ to add bindings and nodes
> > for the GPU/GMU and GPU SMMU for sdm845. v7 of this patchset also removes
> > interrupt-names from the driver and the existing DT changes per feedback 
> > from
> > Rob Herring.
> >
> > This is based on :
> > git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git for-next
> >
> > with:
> > https://lore.kernel.org/patchwork/patch/1018365/
> >
> > This change requires the following dependencies:
> >
> > include/dt-bindings/power/qcom-rpmpd.h:
> > https://patchwork.kernel.org/patch/1079/
> >
> > qcom,smmu-v2 binding:
> > https://patchwork.kernel.org/patch/10581911/
> >
> > v7: Add patches to remove interrupt-names, add version specific compatible
> > string for gmu
> > v6: Update GPU bindings for a6xx and make the examples match the nodes and 
> > vice
> >  versa.  Clean up types and rebase on
> >  https://lore.kernel.org/patchwork/patch/1018365/ to help facilitate 
> > merging.
> > v5: Use symbolic names for the RPMH power levels defined in OPP table,
> >  move the opp tables as children of their respective nodes and rename
> >  the iommu device.
> > v4: Rebase
> > v3: Split GMU PDC region into two GPU specific sections, fix indentation,
> >   really use qcom,gmu for the phandle name
> > v2: changed qcom,arc-level to qcom,level following discussion with Viresh;
> >   change gmu phandle to qcom,gmu per Rob
> >
> > Jordan Crouse (6):
> >   drm/msm/gpu: Remove hardcoded interrupt name
> >   drm/msm: drop interrupt-names
> >   ARM: dts: qcom: Removed unused interrupt-names from GPU node
> >   arm64: dts: qcom: msm8916: Remove unused interrupt-names from GPU
> >   dt-bindings: drm/msm/a6xx: Document GMU and update GPU bindings
> >   arm64: dts: sdm845: Add gpu and gmu device nodes
>
> I know it's been holidays and everyone (including me) has been on
> vacation, but just wanted to make sure the current status of this
> series was explicitly called out.  :-)
>
>
> I believe patches #1 and #2 are ready to land and will go through your tree.
>
> Patches #3 and #4 should probably go through Andy's tree and are not
> urgent (they are just cleanup).  They can sit on the back burner until
> patches #1 and #2 have hit mainline.  That's a good reason to land #1
> and #2 sooner.  ;-)
>
> I think patch #5 is also ready to land.  There's been some
> bikeshedding about the exact format for the opp table, but none of
> that bikeshedding affects the bindings that Jordan wrote.  If you
> agree that this is OK to land, it would also be nice to get in.
>
> ...then Jordan can spin patch #6 (once Rob H Acks Rajendra's opp
> bindings) alone at a future date.
>

I've picked up 1+2 and 5..  I assume it makes more sense for agross to
pick up the rest?

BR,
-R
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/4] drm/tinydrm: Use damage helper for dirtyfb

[Noralf Trønnes]

Den 09.01.2019 19.26, skrev Sam Ravnborg:
> Hi Noralf.
> 
>>
>> I was really pleased to see that the damage helper had landed. Now I can
>> do framebuffer flushing solely through the display pipe functions. This
>> prepares the ground for the removal of struct tinydrm_device in my next
>> series.
> 
> I browsed through the code - and the code paths I could follow looked
> good to me.
> I missed an update of Documentation/gpu/todo.rst as I think we can
> close a few items with this patch-set.
> 

Yeah, you're right, I forgot about that one. I'll add a patch in the
next version.

> You can add my:
> Acked-by: Sam Ravnborg 
> to the full series.
> 

Thanks,
Noralf.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6] drm/panel: Add a driver for the TPO TPG110

[Sam Ravnborg]

Hi Linus.

On Wed, Jan 09, 2019 at 02:53:31PM +0100, Linus Walleij wrote:
> The TPO (Toppoly) TPG110 is a pretty generic display driver
> similar in vein to the Ilitek 93xx devices. It is not a panel
> per se but a driver used with several low-cost noname panels.
> 
> This is used on the Nomadik NHK15 combined with a OSD
> OSD057VA01CT display for WVGA 800x480.
> 
> The driver is pretty minimalistic right now but can be
> extended to handle non-default polarities, gamma correction
> etc.
> 
> The driver is based on the baked-in code in
> drivers/video/fbdev/amba-clcd-nomadik.c which will be
> decomissioned once this us upstream.
> 
> Acked-by: Sam Ravnborg 
> Signed-off-by: Linus Walleij 

While browsing this code again a few things jumped at me.
- we try to kill use of drmP.h
- DRM_DEV_XXX rather than dev_xxx (not all like these, but they are used in 
other panels)
- drop videomode - not used anymore.

I went ahead and made a patch. Build tested on top of drm-misc-next
(had to define SPI_3WIRE_HIZ, because we miss a backmerge of -rc1)

Apply what you think is relevant, and sorry for the late feedback.

Sam

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index e3821180b6cd..a71f44191273 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -208,7 +208,6 @@ config DRM_PANEL_TPO_TPG110
tristate "TPO TPG 800x400 panel"
depends on OF && SPI && GPIOLIB
depends on BACKLIGHT_CLASS_DEVICE
-   select VIDEOMODE_HELPERS
help
  Say Y here if you want to enable support for TPO TPG110
  400CH LTPS TFT LCD Single Chip Digital Driver for up to
diff --git a/drivers/gpu/drm/panel/panel-tpo-tpg110.c 
b/drivers/gpu/drm/panel/panel-tpo-tpg110.c
index d7c3541fdf28..67c7be8eb166 100644
--- a/drivers/gpu/drm/panel/panel-tpo-tpg110.c
+++ b/drivers/gpu/drm/panel/panel-tpo-tpg110.c
@@ -10,11 +10,14 @@
  * Author:
  * Linus Walleij 
  */
-#include 
+
+#include 
 #include 
+#include 
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -22,9 +25,6 @@
 #include 
 #include 
 
-#include 
-#include 
-
 #define TPG110_TEST0x00
 #define TPG110_CHIPID  0x01
 #define TPG110_CTRL1   0x02
@@ -248,7 +248,7 @@ static u8 tpg110_readwrite_reg(struct tpg110 *tpg, bool 
write,
spi_message_add_tail([1], );
ret = spi_sync(tpg->spi, );
if (ret) {
-   dev_err(tpg->dev, "SPI message error %d\n", ret);
+   DRM_DEV_ERROR(tpg->dev, "SPI message error %d\n", ret);
return ret;
}
if (write)
@@ -275,46 +275,46 @@ static int tpg110_startup(struct tpg110 *tpg)
/* De-assert the reset signal */
gpiod_set_value_cansleep(tpg->grestb, 0);
mdelay(1);
-   dev_info(tpg->dev, "de-asserted GRESTB\n");
+   DRM_DEV_INFO(tpg->dev, "de-asserted GRESTB\n");
 
/* Test display communication */
tpg110_write_reg(tpg, TPG110_TEST, 0x55);
val = tpg110_read_reg(tpg, TPG110_TEST);
if (val != 0x55) {
-   dev_err(tpg->dev, "failed communication test\n");
+   DRM_DEV_ERROR(tpg->dev, "failed communication test\n");
return -ENODEV;
}
 
val = tpg110_read_reg(tpg, TPG110_CHIPID);
-   dev_info(tpg->dev, "TPG110 chip ID: %d version: %d\n",
-val >> 4, val & 0x0f);
+   DRM_DEV_INFO(tpg->dev, "TPG110 chip ID: %d version: %d\n",
+val >> 4, val & 0x0f);
 
/* Show display resolution */
val = tpg110_read_reg(tpg, TPG110_CTRL1);
val &= TPG110_RES_MASK;
switch (val) {
case TPG110_RES_400X240_D:
-   dev_info(tpg->dev,
-"IN 400x240 RGB -> OUT 800x480 RGB (dual scan)");
+   DRM_DEV_INFO(tpg->dev,
+"IN 400x240 RGB -> OUT 800x480 RGB (dual scan)");
break;
case TPG110_RES_480X272_D:
-   dev_info(tpg->dev,
-"IN 480x272 RGB -> OUT 800x480 RGB (dual scan)");
+   DRM_DEV_INFO(tpg->dev,
+"IN 480x272 RGB -> OUT 800x480 RGB (dual scan)");
break;
case TPG110_RES_480X640:
-   dev_info(tpg->dev, "480x640 RGB");
+   DRM_DEV_INFO(tpg->dev, "480x640 RGB");
break;
case TPG110_RES_480X272:
-   dev_info(tpg->dev, "480x272 RGB");
+   DRM_DEV_INFO(tpg->dev, "480x272 RGB");
break;
case TPG110_RES_640X480:
-   dev_info(tpg->dev, "640x480 RGB");
+   DRM_DEV_INFO(tpg->dev, "640x480 RGB");
break;
case TPG110_RES_800X480:
-   dev_info(tpg->dev, "800x480 RGB");
+   DRM_DEV_INFO(tpg->dev, "800x480 RGB");
break;
default:
-   dev_info(tpg->dev, "ILLEGAL RESOLUTION");
+

[PATCH 0/3] Support reflect-x/y on RK3328, RK3368, and RK3399

[Ezequiel Garcia]

Here's a small series supporting plane reflection (aka. mirroring)
properties on RK3328, RK3368, and RK3399 SoCs.

Note that RK3288 specification doesn't seem to document registers
for plane mirroring, but instead it only seems to support mirroring
at the display (CRTC) level.

A small typo cleanup patch is included, in patch 1. Not related
to the rotation stuff.

In order to support this feature, patch 2 separates the register
set for win0 and win1.

Once that's done, patch 3 creates the properties, if supported
by each plane/SoC.

The following modetest commands would test this feature,
where 30 is the plane ID, and 49 = rotate_0 + relect_y + reflect_x.

X mirror:
modetest -s 43@33:1920x1080@XR24 -w 30:rotation:17

Y mirror:
modetest -s 43@33:1920x1080@XR24 -w 30:rotation:33

XY mirror:
modetest -s 43@33:1920x1080@XR24 -w 30:rotation:49

This work has been originally by Daniele. I just cleaned
up the implementation a it, and ported the code to upstream.

This series is based on drm-misc-next plus 
https://patchwork.kernel.org/patch/10752893/.

Daniele Castagna (1):
  drm/rockchip: Add reflection properties

Ezequiel Garcia (2):
  drm/rockchip: Fix typo in VOP macros argument
  drm/rockchip: Separate RK3288 from RK3368 win01 registers

 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 47 ++---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h |  2 +
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 34 ---
 3 files changed, 70 insertions(+), 13 deletions(-)

-- 
2.20.1

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

[PATCH 1/3] drm/rockchip: Fix typo in VOP macros argument

[Ezequiel Garcia]

Fix a small typo in the macros VOP argument. The macro argument
is currently wrongly named "x", and then never used. The code
built fine almost by accident, as the macros are always used
in a context where a proper "vop" symbol exists.

This fix is almost cosmetic, as the resulting code shouldn't change.

Signed-off-by: Ezequiel Garcia 
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 7ad9067b3110..fe800f784c18 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -45,21 +45,21 @@
 #include "rockchip_drm_vop.h"
 #include "rockchip_rgb.h"
 
-#define VOP_WIN_SET(x, win, name, v) \
+#define VOP_WIN_SET(vop, win, name, v) \
vop_reg_set(vop, >phy->name, win->base, ~0, v, #name)
-#define VOP_SCL_SET(x, win, name, v) \
+#define VOP_SCL_SET(vop, win, name, v) \
vop_reg_set(vop, >phy->scl->name, win->base, ~0, v, #name)
-#define VOP_SCL_SET_EXT(x, win, name, v) \
+#define VOP_SCL_SET_EXT(vop, win, name, v) \
vop_reg_set(vop, >phy->scl->ext->name, \
win->base, ~0, v, #name)
 
-#define VOP_WIN_YUV2YUV_SET(x, win_yuv2yuv, name, v) \
+#define VOP_WIN_YUV2YUV_SET(vop, win_yuv2yuv, name, v) \
do { \
if (win_yuv2yuv && win_yuv2yuv->name.mask) \
vop_reg_set(vop, _yuv2yuv->name, 0, ~0, v, #name); \
} while (0)
 
-#define VOP_WIN_YUV2YUV_COEFFICIENT_SET(x, win_yuv2yuv, name, v) \
+#define VOP_WIN_YUV2YUV_COEFFICIENT_SET(vop, win_yuv2yuv, name, v) \
do { \
if (win_yuv2yuv && win_yuv2yuv->phy->name.mask) \
vop_reg_set(vop, _yuv2yuv->phy->name, 
win_yuv2yuv->base, ~0, v, #name); \
@@ -85,8 +85,8 @@
 #define VOP_INTR_GET_TYPE(vop, name, type) \
vop_get_intr_type(vop, >data->intr->name, type)
 
-#define VOP_WIN_GET(x, win, name) \
-   vop_read_reg(x, win->offset, win->phy->name)
+#define VOP_WIN_GET(vop, win, name) \
+   vop_read_reg(vop, win->offset, win->phy->name)
 
 #define VOP_WIN_GET_YRGBADDR(vop, win) \
vop_readl(vop, win->base + win->phy->yrgb_mst.offset)
-- 
2.20.1

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

[PATCH 2/3] drm/rockchip: Separate RK3288 from RK3368 win01 registers

[Ezequiel Garcia]

This commit splits the registers for RK3288 from those
for RK3328, RK3368 and RK3399. It seems RK3288 does not
support plane x-y-mirroring, and so in order to support this
for the other SoCs, we need to have separate set of registers
for win0 and win1.

Signed-off-by: Ezequiel Garcia 
---
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 31 +
 1 file changed, 25 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c 
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index fe752df4e038..4f7000b5f9ed 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -550,6 +550,25 @@ static const struct vop_intr rk3368_vop_intr = {
.clear = VOP_REG_MASK_SYNC(RK3368_INTR_CLEAR, 0x3fff, 0),
 };
 
+static const struct vop_win_phy rk3368_win01_data = {
+   .scl = _win_full_scl,
+   .data_formats = formats_win_full,
+   .nformats = ARRAY_SIZE(formats_win_full),
+   .enable = VOP_REG(RK3368_WIN0_CTRL0, 0x1, 0),
+   .format = VOP_REG(RK3368_WIN0_CTRL0, 0x7, 1),
+   .rb_swap = VOP_REG(RK3368_WIN0_CTRL0, 0x1, 12),
+   .act_info = VOP_REG(RK3368_WIN0_ACT_INFO, 0x1fff1fff, 0),
+   .dsp_info = VOP_REG(RK3368_WIN0_DSP_INFO, 0x0fff0fff, 0),
+   .dsp_st = VOP_REG(RK3368_WIN0_DSP_ST, 0x1fff1fff, 0),
+   .yrgb_mst = VOP_REG(RK3368_WIN0_YRGB_MST, 0x, 0),
+   .uv_mst = VOP_REG(RK3368_WIN0_CBR_MST, 0x, 0),
+   .yrgb_vir = VOP_REG(RK3368_WIN0_VIR, 0x3fff, 0),
+   .uv_vir = VOP_REG(RK3368_WIN0_VIR, 0x3fff, 16),
+   .src_alpha_ctl = VOP_REG(RK3368_WIN0_SRC_ALPHA_CTRL, 0xff, 0),
+   .dst_alpha_ctl = VOP_REG(RK3368_WIN0_DST_ALPHA_CTRL, 0xff, 0),
+   .channel = VOP_REG(RK3368_WIN0_CTRL2, 0xff, 0),
+};
+
 static const struct vop_win_phy rk3368_win23_data = {
.data_formats = formats_win_lite,
.nformats = ARRAY_SIZE(formats_win_lite),
@@ -566,9 +585,9 @@ static const struct vop_win_phy rk3368_win23_data = {
 };
 
 static const struct vop_win_data rk3368_vop_win_data[] = {
-   { .base = 0x00, .phy = _win01_data,
+   { .base = 0x00, .phy = _win01_data,
  .type = DRM_PLANE_TYPE_PRIMARY },
-   { .base = 0x40, .phy = _win01_data,
+   { .base = 0x40, .phy = _win01_data,
  .type = DRM_PLANE_TYPE_OVERLAY },
{ .base = 0x00, .phy = _win23_data,
  .type = DRM_PLANE_TYPE_OVERLAY },
@@ -679,7 +698,7 @@ static const struct vop_data rk3399_vop_big = {
 };
 
 static const struct vop_win_data rk3399_vop_lit_win_data[] = {
-   { .base = 0x00, .phy = _win01_data,
+   { .base = 0x00, .phy = _win01_data,
  .type = DRM_PLANE_TYPE_PRIMARY },
{ .base = 0x00, .phy = _win23_data,
  .type = DRM_PLANE_TYPE_CURSOR},
@@ -766,11 +785,11 @@ static const struct vop_intr rk3328_vop_intr = {
 };
 
 static const struct vop_win_data rk3328_vop_win_data[] = {
-   { .base = 0xd0, .phy = _win01_data,
+   { .base = 0xd0, .phy = _win01_data,
  .type = DRM_PLANE_TYPE_PRIMARY },
-   { .base = 0x1d0, .phy = _win01_data,
+   { .base = 0x1d0, .phy = _win01_data,
  .type = DRM_PLANE_TYPE_OVERLAY },
-   { .base = 0x2d0, .phy = _win01_data,
+   { .base = 0x2d0, .phy = _win01_data,
  .type = DRM_PLANE_TYPE_CURSOR },
 };
 
-- 
2.20.1

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

[PATCH 3/3] drm/rockchip: Add reflection properties

[Ezequiel Garcia]

From: Daniele Castagna 

Add the KMS plane rotation property to the DRM rockchip driver,
for SoCs RK3328, RK3368 and RK3399.

RK3288 only supports rotation at the display level (i.e. CRTC),
but for now we are only interested in plane rotation.

This commit only adds support for the value of reflect-y
and reflect-x (i.e. mirroring).

Note that y-mirroring is not compatible with YUV.

The following modetest commands would test this feature,
where 30 is the plane ID, and 49 = rotate_0 + relect_y + reflect_x.

X mirror:
modetest -s 43@33:1920x1080@XR24 -w 30:rotation:17

Y mirror:
modetest -s 43@33:1920x1080@XR24 -w 30:rotation:33

XY mirror:
modetest -s 43@33:1920x1080@XR24 -w 30:rotation:49

Signed-off-by: Daniele Castagna 
Signed-off-by: Ezequiel Garcia 
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 33 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h |  2 ++
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c |  3 ++
 3 files changed, 38 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index fe800f784c18..5185a31318f5 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -88,6 +88,9 @@
 #define VOP_WIN_GET(vop, win, name) \
vop_read_reg(vop, win->offset, win->phy->name)
 
+#define VOP_WIN_HAS_REG(win, name) \
+   !!(win->phy->name.mask)
+
 #define VOP_WIN_GET_YRGBADDR(vop, win) \
vop_readl(vop, win->base + win->phy->yrgb_mst.offset)
 
@@ -711,6 +714,11 @@ static int vop_plane_atomic_check(struct drm_plane *plane,
return -EINVAL;
}
 
+   if (fb->format->is_yuv && state->rotation & DRM_MODE_REFLECT_Y) {
+   DRM_ERROR("Invalid Source: Yuv format does not support this 
rotation\n");
+   return -EINVAL;
+   }
+
return 0;
 }
 
@@ -789,6 +797,13 @@ static void vop_plane_atomic_update(struct drm_plane 
*plane,
offset += (src->y1 >> 16) * fb->pitches[0];
dma_addr = rk_obj->dma_addr + offset + fb->offsets[0];
 
+   /*
+* For y-mirroring we need to move address
+* to the beginning of the last line.
+*/
+   if (state->rotation & DRM_MODE_REFLECT_Y)
+   dma_addr += (actual_h - 1) * fb->pitches[0];
+
format = vop_convert_format(fb->format->format);
 
spin_lock(>reg_lock);
@@ -797,6 +812,10 @@ static void vop_plane_atomic_update(struct drm_plane 
*plane,
VOP_WIN_SET(vop, win, yrgb_vir, DIV_ROUND_UP(fb->pitches[0], 4));
VOP_WIN_SET(vop, win, yrgb_mst, dma_addr);
VOP_WIN_YUV2YUV_SET(vop, win_yuv2yuv, y2r_en, is_yuv);
+   VOP_WIN_SET(vop, win, y_mir_en,
+   (state->rotation & DRM_MODE_REFLECT_Y) ? 1 : 0);
+   VOP_WIN_SET(vop, win, x_mir_en,
+   (state->rotation & DRM_MODE_REFLECT_X) ? 1 : 0);
 
if (is_yuv) {
int hsub = 
drm_format_horz_chroma_subsampling(fb->format->format);
@@ -1311,6 +1330,18 @@ static irqreturn_t vop_isr(int irq, void *data)
return ret;
 }
 
+static void vop_plane_add_properties(struct drm_plane *plane,
+const struct vop_win_data *win_data)
+{
+   unsigned int flags = 0;
+
+   flags |= VOP_WIN_HAS_REG(win_data, x_mir_en) ? DRM_MODE_REFLECT_X : 0;
+   flags |= VOP_WIN_HAS_REG(win_data, y_mir_en) ? DRM_MODE_REFLECT_Y : 0;
+   if (flags)
+   drm_plane_create_rotation_property(plane, DRM_MODE_ROTATE_0,
+  DRM_MODE_ROTATE_0 | flags);
+}
+
 static int vop_create_crtc(struct vop *vop)
 {
const struct vop_data *vop_data = vop->data;
@@ -1348,6 +1379,7 @@ static int vop_create_crtc(struct vop *vop)
 
plane = _win->base;
drm_plane_helper_add(plane, _helper_funcs);
+   vop_plane_add_properties(plane, win_data);
if (plane->type == DRM_PLANE_TYPE_PRIMARY)
primary = plane;
else if (plane->type == DRM_PLANE_TYPE_CURSOR)
@@ -1385,6 +1417,7 @@ static int vop_create_crtc(struct vop *vop)
goto err_cleanup_crtc;
}
drm_plane_helper_add(_win->base, _helper_funcs);
+   vop_plane_add_properties(_win->base, win_data);
}
 
port = of_get_child_by_name(dev->of_node, "port");
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
index aed467cd81b9..04ed401d2325 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
@@ -146,6 +146,8 @@ struct vop_win_phy {
struct vop_reg uv_mst;
struct vop_reg yrgb_vir;
struct vop_reg uv_vir;
+   struct vop_reg y_mir_en;
+   struct vop_reg x_mir_en;
 
struct vop_reg dst_alpha_ctl;
struct vop_reg src_alpha_ctl;
diff --git 

Re: [PATCH v2 15/15] drm/bochs: reserve bo for pin/unpin

[Alex Deucher]

On Wed, Jan 9, 2019 at 12:36 PM Daniel Vetter  wrote:
>
> On Wed, Jan 9, 2019 at 3:54 PM Gerd Hoffmann  wrote:
> >
> > On Wed, Jan 09, 2019 at 11:10:44AM +0100, Daniel Vetter wrote:
> > > On Tue, Jan 08, 2019 at 12:25:19PM +0100, Gerd Hoffmann wrote:
> > > > The buffer object must be reserved before calling
> > > > ttm_bo_validate for pinning/unpinning.
> > > >
> > > > Signed-off-by: Gerd Hoffmann 
> > >
> > > Seems a bit a bisect fumble in your series here: legacy kms code reserved
> > > the ttm bo before calling boch_bo_pin/unpin, your atomic code doesn't. I
> > > think pushing this into bochs_bo_pin/unpin makes sense for atomic, but to
> > > avoid bisect fail I think you need to have these temporarily in your
> > > cleanup/prepare_plane functions too.
> >
> > I think I've sorted that.  Have some other changes too, will probably
> > send v3 tomorrow.
> >
> > > Looked through the entire series, this here is the only issue I think
> > > should be fixed before merging (making atomic_enable optional can be done
> > > as a follow-up if you feel like it). With that addressed on the series:
> > >
> > > Acked-by: Daniel Vetter 
> >
> > Thanks.
> >
> > While being at it:  I'm also looking at dma-buf export and import
> > support for the qemu drivers.
> >
> > Right now both qxl and virtio have gem_prime_get_sg_table and
> > gem_prime_import_sg_table handlers which throw a WARN_ONCE() and return
> > an error.
> >
> > If I understand things correctly it is valid to set all import/export
> > callbacks (prime_handle_to_fd, prime_fd_to_handle,
> > gem_prime_get_sg_table, gem_prime_import_sg_table) to NULL when not
> > supporting dma-buf import/export and still advertise DRIVER_PRIME to
> > indicate the other prime callbacks are supported (so generic fbdev
> > emulation can use gem_prime_vmap etc).  Is that correct?
>
> I'm not sure how much that's a good idea ... Never thought about it
> tbh. All the fbdev/dma-buf stuff has plenty of hacks and
> inconsistencies still, so I guess we can't make it much worse really.
>
> > On exporting:
> >
> > TTM_PL_TT should be easy, just pin the buffer, grab the pages list and
> > feed that into drm_prime_pages_to_sg.  Didn't try yet though.  Is that
> > approach correct?
> >
> > Is it possible to export TTM_PL_VRAM objects (with backing storage being
> > a pci memory bar)?  If so, how?
>
> Not really in general. amdgpu upcasts to amdgpu_bo (if it's amgpu BO)
> and then knows the internals so it can do a proper pci peer2peer
> mapping. Or at least there's been lots of patches floating around to
> make that happen.

Here's Christian's WIP stuff for adding device memory support to dma-buf:
https://cgit.freedesktop.org/~deathsimple/linux/log/?h=p2p

Alex

>
> I think other drivers migrate the bo out of VRAM.
>
> > On importing:
> >
> > Importing into TTM_PL_TT object looks easy again, at least when the
> > object is actually stored in RAM.  What if not?
>
> They are all supposed to be stored in RAM. Note that all current ttm
> importers totally break the abstraction, by taking the sg list,
> throwing the dma mapping away and assuming there's a struct page
> backing it. Would be good if we could stop spreading that abuse - the
> dma-buf interfaces have been modelled after the ttm bo interfaces, so
> shouldn't be too hard to wire this up correctly.
>
> > Importing into TTM_PL_VRAM:  Impossible I think, without copying over
> > the data.  Should that be done?  If so, how?  Or is it better to just
> > not support import then?
>
> Hm, since you ask about TTM concepts and not what this means in terms
> of dma-buf: As long as you upcast to the ttm_bo you can do whatever
> you want to really. But with plain dma-buf this doesn't work right now
> (least because ttm assumes it gets system RAM on import, in theory you
> could put the peer2peer dma mapping into the sg list and it should
> work).
> -Daniel
>
> >
> > thanks,
> >   Gerd
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/4] drm/tinydrm: Use damage helper for dirtyfb

[Sam Ravnborg]

Hi Noralf.

> 
> I was really pleased to see that the damage helper had landed. Now I can
> do framebuffer flushing solely through the display pipe functions. This
> prepares the ground for the removal of struct tinydrm_device in my next
> series.

I browsed through the code - and the code paths I could follow looked
good to me.
I missed an update of Documentation/gpu/todo.rst as I think we can
close a few items with this patch-set.

You can add my:
Acked-by: Sam Ravnborg 
to the full series.

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

Re: [PATCH v7 0/6] arm64: dts: Add sdm845 GPU/GMU and SMMU

[Doug Anderson]

Hi Rob,

On Tue, Dec 18, 2018 at 10:32 AM Jordan Crouse  wrote:
>
> Now that more of the sdm845 bindings are headed upstream this a refresh of
> of https://patchwork.freedesktop.org/series/39308/ to add bindings and nodes
> for the GPU/GMU and GPU SMMU for sdm845. v7 of this patchset also removes
> interrupt-names from the driver and the existing DT changes per feedback from
> Rob Herring.
>
> This is based on :
> git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git for-next
>
> with:
> https://lore.kernel.org/patchwork/patch/1018365/
>
> This change requires the following dependencies:
>
> include/dt-bindings/power/qcom-rpmpd.h:
> https://patchwork.kernel.org/patch/1079/
>
> qcom,smmu-v2 binding:
> https://patchwork.kernel.org/patch/10581911/
>
> v7: Add patches to remove interrupt-names, add version specific compatible
> string for gmu
> v6: Update GPU bindings for a6xx and make the examples match the nodes and 
> vice
>  versa.  Clean up types and rebase on
>  https://lore.kernel.org/patchwork/patch/1018365/ to help facilitate merging.
> v5: Use symbolic names for the RPMH power levels defined in OPP table,
>  move the opp tables as children of their respective nodes and rename
>  the iommu device.
> v4: Rebase
> v3: Split GMU PDC region into two GPU specific sections, fix indentation,
>   really use qcom,gmu for the phandle name
> v2: changed qcom,arc-level to qcom,level following discussion with Viresh;
>   change gmu phandle to qcom,gmu per Rob
>
> Jordan Crouse (6):
>   drm/msm/gpu: Remove hardcoded interrupt name
>   drm/msm: drop interrupt-names
>   ARM: dts: qcom: Removed unused interrupt-names from GPU node
>   arm64: dts: qcom: msm8916: Remove unused interrupt-names from GPU
>   dt-bindings: drm/msm/a6xx: Document GMU and update GPU bindings
>   arm64: dts: sdm845: Add gpu and gmu device nodes

I know it's been holidays and everyone (including me) has been on
vacation, but just wanted to make sure the current status of this
series was explicitly called out.  :-)


I believe patches #1 and #2 are ready to land and will go through your tree.

Patches #3 and #4 should probably go through Andy's tree and are not
urgent (they are just cleanup).  They can sit on the back burner until
patches #1 and #2 have hit mainline.  That's a good reason to land #1
and #2 sooner.  ;-)

I think patch #5 is also ready to land.  There's been some
bikeshedding about the exact format for the opp table, but none of
that bikeshedding affects the bindings that Jordan wrote.  If you
agree that this is OK to land, it would also be nice to get in.

...then Jordan can spin patch #6 (once Rob H Acks Rajendra's opp
bindings) alone at a future date.


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

[v5 3/3] dt-bindings: msm/disp: Introduce interconnect bindings for MDSS on SDM845

[Jayant Shekhar]

From: Sravanthi Kollukuduru 

Add interconnect properties such as interconnect provider specifier
, the edge source and destination ports which are required by the
interconnect API to configure interconnect path for MDSS.

Changes in v2:
- none

Changes in v3:
- Remove common property definitions (Rob Herring)

Changes in v4:
- Use port macros and change port string names (Georgi Djakov)

Changes in v5:
- None

Signed-off-by: Sravanthi Kollukuduru 
Signed-off-by: Jayant Shekhar 
---
 Documentation/devicetree/bindings/display/msm/dpu.txt | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/msm/dpu.txt 
b/Documentation/devicetree/bindings/display/msm/dpu.txt
index ad2e883..a61dd40 100644
--- a/Documentation/devicetree/bindings/display/msm/dpu.txt
+++ b/Documentation/devicetree/bindings/display/msm/dpu.txt
@@ -28,6 +28,11 @@ Required properties:
 - #address-cells: number of address cells for the MDSS children. Should be 1.
 - #size-cells: Should be 1.
 - ranges: parent bus address space is the same as the child bus address space.
+- interconnects : interconnect path specifier for MDSS according to
+  Documentation/devicetree/bindings/interconnect/interconnect.txt. Should be
+  2 paths corresponding to 2 AXI ports.
+- interconnect-names : MDSS will have 2 port names to differentiate between the
+  2 interconnect paths defined with interconnect specifier.
 
 Optional properties:
 - assigned-clocks: list of clock specifiers for clocks needing rate assignment
@@ -86,6 +91,11 @@ Example:
interrupt-controller;
#interrupt-cells = <1>;
 
+   interconnects = <_hlos MASTER_MDP0 _hlos SLAVE_EBI1>,
+   <_hlos MASTER_MDP1 _hlos SLAVE_EBI1>;
+
+   interconnect-names = "mdp0-mem", "mdp1-mem";
+
iommus = <_iommu 0>;
 
#address-cells = <2>;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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

[v5 2/3] drm/msm/dpu: Integrate interconnect API in MDSS

[Jayant Shekhar]

From: Sravanthi Kollukuduru 

The interconnect framework is designed to provide a
standard kernel interface to control the settings of
the interconnects on a SoC.

The interconnect API uses a consumer/provider-based model,
where the providers are the interconnect buses and the
consumers could be various drivers.

MDSS is one of the interconnect consumers which uses the
interconnect APIs to get the path between endpoints and
set its bandwidth requirement for the given interconnected
path.

Changes in v2:
- Remove error log and unnecessary check (Jordan Crouse)

Changes in v3:
- Code clean involving variable name change, removal
  of extra paranthesis and variables (Matthias Kaehlcke)

Changes in v4:
- Add comments, spacings, tabs, proper port name
  and icc macro (Georgi Djakov)

Changes in v5:
- Commit text and parenthesis alignment (Georgi Djakov)

Signed-off-by: Sravanthi Kollukuduru 
Signed-off-by: Jayant Shekhar 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c | 49 +---
 1 file changed, 45 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
index 38576f8..b8fb197 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
@@ -4,11 +4,15 @@
  */
 
 #include "dpu_kms.h"
+#include 
 
 #define to_dpu_mdss(x) container_of(x, struct dpu_mdss, base)
 
 #define HW_INTR_STATUS 0x0010
 
+/* Max BW defined in KBps */
+#define MAX_BW 680
+
 struct dpu_mdss {
struct msm_mdss base;
void __iomem *mmio;
@@ -16,8 +20,30 @@ struct dpu_mdss {
u32 hwversion;
struct dss_module_power mp;
struct dpu_irq_controller irq_controller;
+   struct icc_path *path[2];
+   u32 num_paths;
 };
 
+static int dpu_mdss_parse_data_bus_icc_path(struct drm_device *dev,
+   struct dpu_mdss *dpu_mdss)
+{
+   struct icc_path *path0 = of_icc_get(dev->dev, "mdp0-mem");
+   struct icc_path *path1 = of_icc_get(dev->dev, "mdp1-mem");
+
+   if (IS_ERR(path0))
+   return PTR_ERR(path0);
+
+   dpu_mdss->path[0] = path0;
+   dpu_mdss->num_paths = 1;
+
+   if (!IS_ERR(path1)) {
+   dpu_mdss->path[1] = path1;
+   dpu_mdss->num_paths++;
+   }
+
+   return 0;
+}
+
 static irqreturn_t dpu_mdss_irq(int irq, void *arg)
 {
struct dpu_mdss *dpu_mdss = arg;
@@ -127,7 +153,11 @@ static int dpu_mdss_enable(struct msm_mdss *mdss)
 {
struct dpu_mdss *dpu_mdss = to_dpu_mdss(mdss);
struct dss_module_power *mp = _mdss->mp;
-   int ret;
+   int ret, i;
+   u64 avg_bw = dpu_mdss->num_paths ? MAX_BW / dpu_mdss->num_paths : 0;
+
+   for (i = 0; i < dpu_mdss->num_paths; i++)
+   icc_set(dpu_mdss->path[i], avg_bw, kBps_to_icc(MAX_BW));
 
ret = msm_dss_enable_clk(mp->clk_config, mp->num_clk, true);
if (ret)
@@ -140,12 +170,15 @@ static int dpu_mdss_disable(struct msm_mdss *mdss)
 {
struct dpu_mdss *dpu_mdss = to_dpu_mdss(mdss);
struct dss_module_power *mp = _mdss->mp;
-   int ret;
+   int ret, i;
 
ret = msm_dss_enable_clk(mp->clk_config, mp->num_clk, false);
if (ret)
DPU_ERROR("clock disable failed, ret:%d\n", ret);
 
+   for (i = 0; i < dpu_mdss->num_paths; i++)
+   icc_set(dpu_mdss->path[i], 0, 0);
+
return ret;
 }
 
@@ -155,6 +188,7 @@ static void dpu_mdss_destroy(struct drm_device *dev)
struct msm_drm_private *priv = dev->dev_private;
struct dpu_mdss *dpu_mdss = to_dpu_mdss(priv->mdss);
struct dss_module_power *mp = _mdss->mp;
+   int i;
 
pm_runtime_disable(dev->dev);
_dpu_mdss_irq_domain_fini(dpu_mdss);
@@ -162,6 +196,9 @@ static void dpu_mdss_destroy(struct drm_device *dev)
msm_dss_put_clk(mp->clk_config, mp->num_clk);
devm_kfree(>dev, mp->clk_config);
 
+   for (i = 0; i < dpu_mdss->num_paths; i++)
+   icc_put(dpu_mdss->path[i]);
+
if (dpu_mdss->mmio)
devm_iounmap(>dev, dpu_mdss->mmio);
dpu_mdss->mmio = NULL;
@@ -200,6 +237,10 @@ int dpu_mdss_init(struct drm_device *dev)
}
dpu_mdss->mmio_len = resource_size(res);
 
+   ret = dpu_mdss_parse_data_bus_icc_path(dev, dpu_mdss);
+   if (ret)
+   return ret;
+
mp = _mdss->mp;
ret = msm_dss_parse_clock(pdev, mp);
if (ret) {
@@ -221,14 +262,14 @@ int dpu_mdss_init(struct drm_device *dev)
goto irq_error;
}
 
+   priv->mdss = _mdss->base;
+
pm_runtime_enable(dev->dev);
 
pm_runtime_get_sync(dev->dev);
dpu_mdss->hwversion = readl_relaxed(dpu_mdss->mmio);
pm_runtime_put_sync(dev->dev);
 
-   priv->mdss = _mdss->base;
-
return ret;
 
 irq_error:
-- 
The Qualcomm 

[v5 1/3] drm/msm/dpu: clean up references of DPU custom bus scaling

[Jayant Shekhar]

From: Sravanthi Kollukuduru 

Since the upstream interconnect bus framework has landed
upstream, the existing references of custom bus scaling
needs to be cleaned up.

Changes in v2:
- Fixed build error due to partial clean up

Changes in v3:
- Condense multiple lines into a single line (Sean Paul)

Changes in v4:
- None

Changes in v5:
- None

Signed-off-by: Sravanthi Kollukuduru 
Signed-off-by: Jayant Shekhar 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c| 174 +--
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h|   4 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c |  13 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c |  47 ++
 drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h |  68 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h|  22 +--
 6 files changed, 89 insertions(+), 239 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
index 22e84b3..c75536e 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -84,7 +84,6 @@ static void _dpu_core_perf_calc_crtc(struct dpu_kms *kms,
struct dpu_core_perf_params *perf)
 {
struct dpu_crtc_state *dpu_cstate;
-   int i;
 
if (!kms || !kms->catalog || !crtc || !state || !perf) {
DPU_ERROR("invalid parameters\n");
@@ -95,35 +94,24 @@ static void _dpu_core_perf_calc_crtc(struct dpu_kms *kms,
memset(perf, 0, sizeof(struct dpu_core_perf_params));
 
if (!dpu_cstate->bw_control) {
-   for (i = 0; i < DPU_POWER_HANDLE_DBUS_ID_MAX; i++) {
-   perf->bw_ctl[i] = kms->catalog->perf.max_bw_high *
+   perf->bw_ctl = kms->catalog->perf.max_bw_high *
1000ULL;
-   perf->max_per_pipe_ib[i] = perf->bw_ctl[i];
-   }
+   perf->max_per_pipe_ib = perf->bw_ctl;
perf->core_clk_rate = kms->perf.max_core_clk_rate;
} else if (kms->perf.perf_tune.mode == DPU_PERF_MODE_MINIMUM) {
-   for (i = 0; i < DPU_POWER_HANDLE_DBUS_ID_MAX; i++) {
-   perf->bw_ctl[i] = 0;
-   perf->max_per_pipe_ib[i] = 0;
-   }
+   perf->bw_ctl = 0;
+   perf->max_per_pipe_ib = 0;
perf->core_clk_rate = 0;
} else if (kms->perf.perf_tune.mode == DPU_PERF_MODE_FIXED) {
-   for (i = 0; i < DPU_POWER_HANDLE_DBUS_ID_MAX; i++) {
-   perf->bw_ctl[i] = kms->perf.fix_core_ab_vote;
-   perf->max_per_pipe_ib[i] = kms->perf.fix_core_ib_vote;
-   }
+   perf->bw_ctl = kms->perf.fix_core_ab_vote;
+   perf->max_per_pipe_ib = kms->perf.fix_core_ib_vote;
perf->core_clk_rate = kms->perf.fix_core_clk_rate;
}
 
DPU_DEBUG(
-   "crtc=%d clk_rate=%llu core_ib=%llu core_ab=%llu llcc_ib=%llu 
llcc_ab=%llu mem_ib=%llu mem_ab=%llu\n",
+   "crtc=%d clk_rate=%llu core_ib=%llu core_ab=%llu\n",
crtc->base.id, perf->core_clk_rate,
-   perf->max_per_pipe_ib[DPU_POWER_HANDLE_DBUS_ID_MNOC],
-   perf->bw_ctl[DPU_POWER_HANDLE_DBUS_ID_MNOC],
-   perf->max_per_pipe_ib[DPU_POWER_HANDLE_DBUS_ID_LLCC],
-   perf->bw_ctl[DPU_POWER_HANDLE_DBUS_ID_LLCC],
-   perf->max_per_pipe_ib[DPU_POWER_HANDLE_DBUS_ID_EBI],
-   perf->bw_ctl[DPU_POWER_HANDLE_DBUS_ID_EBI]);
+   perf->max_per_pipe_ib, perf->bw_ctl);
 }
 
 int dpu_core_perf_crtc_check(struct drm_crtc *crtc,
@@ -136,7 +124,6 @@ int dpu_core_perf_crtc_check(struct drm_crtc *crtc,
struct dpu_crtc_state *dpu_cstate;
struct drm_crtc *tmp_crtc;
struct dpu_kms *kms;
-   int i;
 
if (!crtc || !state) {
DPU_ERROR("invalid crtc\n");
@@ -158,31 +145,25 @@ int dpu_core_perf_crtc_check(struct drm_crtc *crtc,
/* obtain new values */
_dpu_core_perf_calc_crtc(kms, crtc, state, _cstate->new_perf);
 
-   for (i = DPU_POWER_HANDLE_DBUS_ID_MNOC;
-   i < DPU_POWER_HANDLE_DBUS_ID_MAX; i++) {
-   bw_sum_of_intfs = dpu_cstate->new_perf.bw_ctl[i];
-   curr_client_type = dpu_crtc_get_client_type(crtc);
+   bw_sum_of_intfs = dpu_cstate->new_perf.bw_ctl;
+   curr_client_type = dpu_crtc_get_client_type(crtc);
 
-   drm_for_each_crtc(tmp_crtc, crtc->dev) {
-   if (_dpu_core_perf_crtc_is_power_on(tmp_crtc) &&
-   (dpu_crtc_get_client_type(tmp_crtc) ==
-   curr_client_type) &&
-   (tmp_crtc != crtc)) {
-   struct dpu_crtc_state *tmp_cstate =
-   

[v5 0/3] Use interconnect API in MDSS on SDM845

[Jayant Shekhar]

The interconnect API provides an interface for consumer drivers to express
their bandwidth needs in the SoC. This data is aggregated and the on-chip
interconnect hardware is configured to the appropriate power/performance
profile.

MDSS is one of the interconnect consumers which uses the interconnect APIs
to get the path between endpoints and set its bandwidth requirements
for the given interconnected path.

Subsequently, there is a clean up patch to remove all the references
of the DPU custom bus scaling.

There is corresponding DT patch with the source and destination ports
defined for display driver which will be sent separately.

Changes in v2:
- Remove error log and unnecessary check (Jordan Crouse)
- Fixed build error due to partial clean up

Changes in v3:
- Remove common property definitions (Rob Herring)
- Code clean up involving variable name change, removal
  of extra paranthesis and variables (Matthias Kaehlcke)
- Condense multiple lines into a single line (Sean Paul)

Changes in v4:
- Add comments, spacings, tabs, proper port name and icc macro
- Use port macros and change port string names (Georgi Djakov)

Changes in v5:
- Updated commit text and parenthesis alignment (Georgi Djakov)

Sravanthi Kollukuduru (3):
  drm/msm/dpu: clean up references of DPU custom bus scaling
  drm/msm/dpu: Integrate interconnect API in MDSS
  dt-bindings: msm/disp: Introduce interconnect bindings for MDSS on
SDM845

 .../devicetree/bindings/display/msm/dpu.txt|  10 ++
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c  | 174 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h  |   4 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c   |  13 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c   |  49 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c   |  47 ++
 drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h   |  68 
 drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h  |  22 +--
 8 files changed, 144 insertions(+), 243 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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

[PATCH 1/4] drm/gem-fb-helper: Add drm_gem_fb_create_with_dirty()

[Noralf Trønnes]

This adds a .fb_create helper that sets the .dirty callback to
drm_atomic_helper_dirtyfb().

Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/drm_gem_framebuffer_helper.c | 47 +---
 include/drm/drm_gem_framebuffer_helper.h |  3 ++
 2 files changed, 44 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c 
b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
index acb466d25afc..4edd0261e507 100644
--- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
+++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -136,10 +137,9 @@ EXPORT_SYMBOL(drm_gem_fb_create_handle);
  * @mode_cmd: Metadata from the userspace framebuffer creation request
  * @funcs: vtable to be used for the new framebuffer object
  *
- * This can be used to set _framebuffer_funcs for drivers that need the
- * _framebuffer_funcs.dirty callback. Use drm_gem_fb_create() if you don't
- * need to change _framebuffer_funcs.
- * The function does buffer size validation.
+ * This function can be used to set _framebuffer_funcs for drivers that 
need
+ * custom framebuffer callbacks. Use drm_gem_fb_create() if you don't need to
+ * change _framebuffer_funcs. The function does buffer size validation.
  *
  * Returns:
  * Pointer to a _framebuffer on success or an error pointer on failure.
@@ -215,8 +215,8 @@ static const struct drm_framebuffer_funcs drm_gem_fb_funcs 
= {
  *
  * If your hardware has special alignment or pitch requirements these should be
  * checked before calling this function. The function does buffer size
- * validation. Use drm_gem_fb_create_with_funcs() if you need to set
- * _framebuffer_funcs.dirty.
+ * validation. Use drm_gem_fb_create_with_dirty() if you need framebuffer
+ * flushing.
  *
  * Drivers can use this as their _mode_config_funcs.fb_create callback.
  * The ADDFB2 IOCTL calls into this callback.
@@ -233,6 +233,41 @@ drm_gem_fb_create(struct drm_device *dev, struct drm_file 
*file,
 }
 EXPORT_SYMBOL_GPL(drm_gem_fb_create);
 
+static const struct drm_framebuffer_funcs drm_gem_fb_funcs_dirtyfb = {
+   .destroy= drm_gem_fb_destroy,
+   .create_handle  = drm_gem_fb_create_handle,
+   .dirty  = drm_atomic_helper_dirtyfb,
+};
+
+/**
+ * drm_gem_fb_create_with_dirty() - Helper function for the
+ *   _mode_config_funcs.fb_create callback
+ * @dev: DRM device
+ * @file: DRM file that holds the GEM handle(s) backing the framebuffer
+ * @mode_cmd: Metadata from the userspace framebuffer creation request
+ *
+ * This function creates a new framebuffer object described by
+ * _mode_fb_cmd2. This description includes handles for the buffer(s)
+ * backing the framebuffer. drm_atomic_helper_dirtyfb() is used for the dirty
+ * callback giving framebuffer flushing through the atomic machinery. Use
+ * drm_gem_fb_create() if you don't need the dirty callback.
+ * The function does buffer size validation.
+ *
+ * Drivers can use this as their _mode_config_funcs.fb_create callback.
+ * The ADDFB2 IOCTL calls into this callback.
+ *
+ * Returns:
+ * Pointer to a _framebuffer on success or an error pointer on failure.
+ */
+struct drm_framebuffer *
+drm_gem_fb_create_with_dirty(struct drm_device *dev, struct drm_file *file,
+const struct drm_mode_fb_cmd2 *mode_cmd)
+{
+   return drm_gem_fb_create_with_funcs(dev, file, mode_cmd,
+   _gem_fb_funcs_dirtyfb);
+}
+EXPORT_SYMBOL_GPL(drm_gem_fb_create_with_dirty);
+
 /**
  * drm_gem_fb_prepare_fb() - Prepare a GEM backed framebuffer
  * @plane: Plane
diff --git a/include/drm/drm_gem_framebuffer_helper.h 
b/include/drm/drm_gem_framebuffer_helper.h
index a38de7eb55b4..7f307e834eef 100644
--- a/include/drm/drm_gem_framebuffer_helper.h
+++ b/include/drm/drm_gem_framebuffer_helper.h
@@ -25,6 +25,9 @@ drm_gem_fb_create_with_funcs(struct drm_device *dev, struct 
drm_file *file,
 struct drm_framebuffer *
 drm_gem_fb_create(struct drm_device *dev, struct drm_file *file,
  const struct drm_mode_fb_cmd2 *mode_cmd);
+struct drm_framebuffer *
+drm_gem_fb_create_with_dirty(struct drm_device *dev, struct drm_file *file,
+const struct drm_mode_fb_cmd2 *mode_cmd);
 
 int drm_gem_fb_prepare_fb(struct drm_plane *plane,
  struct drm_plane_state *state);
-- 
2.20.1

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

[PATCH 2/4] drm/damage-helper: Add drm_atomic_helper_damage_merged()

[Noralf Trønnes]

Useful for drivers that only care about the combined damage.

Cc: Deepak Rawat 
Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/drm_damage_helper.c | 43 +
 include/drm/drm_damage_helper.h |  3 ++
 2 files changed, 46 insertions(+)

diff --git a/drivers/gpu/drm/drm_damage_helper.c 
b/drivers/gpu/drm/drm_damage_helper.c
index d2a1c7372f36..4ddf1b41a852 100644
--- a/drivers/gpu/drm/drm_damage_helper.c
+++ b/drivers/gpu/drm/drm_damage_helper.c
@@ -332,3 +332,46 @@ drm_atomic_helper_damage_iter_next(struct 
drm_atomic_helper_damage_iter *iter,
return ret;
 }
 EXPORT_SYMBOL(drm_atomic_helper_damage_iter_next);
+
+/**
+ * drm_atomic_helper_damage_merged - Merged plane damage
+ * @old_state: Old plane state for validation.
+ * @state: Plane state from which to iterate the damage clips.
+ * @rect: Returns the merged damage rectangle
+ *
+ * This function merges any valid plane damage clips into one rectangle and
+ * returns it in @rect. It also clears the plane damage.
+ *
+ * For details see: drm_atomic_helper_damage_iter_init() and
+ * drm_atomic_helper_damage_iter_next().
+ *
+ * Returns:
+ * True if there is valid plane damage otherwise false.
+ */
+bool drm_atomic_helper_damage_merged(const struct drm_plane_state *old_state,
+struct drm_plane_state *state,
+struct drm_rect *rect)
+{
+   struct drm_atomic_helper_damage_iter iter;
+   struct drm_rect clip;
+   bool valid = false;
+
+   rect->x1 = INT_MAX;
+   rect->y1 = INT_MAX;
+   rect->x2 = 0;
+   rect->y2 = 0;
+
+   drm_atomic_helper_damage_iter_init(, old_state, state);
+   drm_atomic_for_each_plane_damage(, ) {
+   rect->x1 = min(rect->x1, clip.x1);
+   rect->y1 = min(rect->y1, clip.y1);
+   rect->x2 = max(rect->x2, clip.x2);
+   rect->y2 = max(rect->y2, clip.y2);
+   valid = true;
+   }
+
+   drm_property_replace_blob(>fb_damage_clips, NULL);
+
+   return valid;
+}
+EXPORT_SYMBOL(drm_atomic_helper_damage_merged);
diff --git a/include/drm/drm_damage_helper.h b/include/drm/drm_damage_helper.h
index 4487660b26b8..40c34a5bf149 100644
--- a/include/drm/drm_damage_helper.h
+++ b/include/drm/drm_damage_helper.h
@@ -78,6 +78,9 @@ drm_atomic_helper_damage_iter_init(struct 
drm_atomic_helper_damage_iter *iter,
 bool
 drm_atomic_helper_damage_iter_next(struct drm_atomic_helper_damage_iter *iter,
   struct drm_rect *rect);
+bool drm_atomic_helper_damage_merged(const struct drm_plane_state *old_state,
+struct drm_plane_state *state,
+struct drm_rect *rect);
 
 /**
  * drm_helper_get_plane_damage_clips - Returns damage clips in _rect.
-- 
2.20.1

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

[PATCH 3/4] drm/tinydrm: Use struct drm_rect

[Noralf Trønnes]

This prepares for the switch to drm_atomic_helper_dirtyfb() in the next
patch. The damage helper returns a drm_rect so switch to that everywhere
including using a pointer in the dirty functions.

This is a non-functional change except for the debug print which looks a
bit different.

Signed-off-by: Noralf Trønnes 
---
 .../gpu/drm/tinydrm/core/tinydrm-helpers.c| 19 
 drivers/gpu/drm/tinydrm/ili9225.c | 43 ++-
 drivers/gpu/drm/tinydrm/mipi-dbi.c| 21 -
 drivers/gpu/drm/tinydrm/repaper.c |  3 +-
 drivers/gpu/drm/tinydrm/st7586.c  | 27 ++--
 include/drm/tinydrm/mipi-dbi.h|  3 +-
 include/drm/tinydrm/tinydrm-helpers.h | 11 ++---
 7 files changed, 67 insertions(+), 60 deletions(-)

diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c 
b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
index bf6bfbc5d412..d0ece6ad4a1c 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -41,7 +42,7 @@ MODULE_PARM_DESC(spi_max, "Set a lower SPI max transfer 
size");
  * Returns:
  * true if it's a full clip, false otherwise
  */
-bool tinydrm_merge_clips(struct drm_clip_rect *dst,
+bool tinydrm_merge_clips(struct drm_rect *dst,
 struct drm_clip_rect *src, unsigned int num_clips,
 unsigned int flags, u32 max_width, u32 max_height)
 {
@@ -63,10 +64,10 @@ bool tinydrm_merge_clips(struct drm_clip_rect *dst,
for (i = 0; i < num_clips; i++) {
if (flags & DRM_MODE_FB_DIRTY_ANNOTATE_COPY)
i++;
-   dst->x1 = min(dst->x1, src[i].x1);
-   dst->x2 = max(dst->x2, src[i].x2);
-   dst->y1 = min(dst->y1, src[i].y1);
-   dst->y2 = max(dst->y2, src[i].y2);
+   dst->x1 = min_t(int, dst->x1, src[i].x1);
+   dst->x2 = max_t(int, dst->x2, src[i].x2);
+   dst->y1 = min_t(int, dst->y1, src[i].y1);
+   dst->y2 = max_t(int, dst->y2, src[i].y2);
}
 
if (dst->x2 > max_width || dst->y2 > max_height ||
@@ -122,7 +123,7 @@ EXPORT_SYMBOL(tinydrm_fb_dirty);
  * @clip: Clip rectangle area to copy
  */
 void tinydrm_memcpy(void *dst, void *vaddr, struct drm_framebuffer *fb,
-   struct drm_clip_rect *clip)
+   struct drm_rect *clip)
 {
unsigned int cpp = drm_format_plane_cpp(fb->format->format, 0);
unsigned int pitch = fb->pitches[0];
@@ -146,7 +147,7 @@ EXPORT_SYMBOL(tinydrm_memcpy);
  * @clip: Clip rectangle area to copy
  */
 void tinydrm_swab16(u16 *dst, void *vaddr, struct drm_framebuffer *fb,
-   struct drm_clip_rect *clip)
+   struct drm_rect *clip)
 {
size_t len = (clip->x2 - clip->x1) * sizeof(u16);
unsigned int x, y;
@@ -186,7 +187,7 @@ EXPORT_SYMBOL(tinydrm_swab16);
  */
 void tinydrm_xrgb_to_rgb565(u16 *dst, void *vaddr,
struct drm_framebuffer *fb,
-   struct drm_clip_rect *clip, bool swap)
+   struct drm_rect *clip, bool swap)
 {
size_t len = (clip->x2 - clip->x1) * sizeof(u32);
unsigned int x, y;
@@ -235,7 +236,7 @@ EXPORT_SYMBOL(tinydrm_xrgb_to_rgb565);
  * ITU BT.601 is used for the RGB -> luma (brightness) conversion.
  */
 void tinydrm_xrgb_to_gray8(u8 *dst, void *vaddr, struct drm_framebuffer 
*fb,
-  struct drm_clip_rect *clip)
+  struct drm_rect *clip)
 {
unsigned int len = (clip->x2 - clip->x1) * sizeof(u32);
unsigned int x, y;
diff --git a/drivers/gpu/drm/tinydrm/ili9225.c 
b/drivers/gpu/drm/tinydrm/ili9225.c
index 78f7c2d1b449..cea70f9addcf 100644
--- a/drivers/gpu/drm/tinydrm/ili9225.c
+++ b/drivers/gpu/drm/tinydrm/ili9225.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -82,7 +83,8 @@ static int ili9225_fb_dirty(struct drm_framebuffer *fb,
struct tinydrm_device *tdev = fb->dev->dev_private;
struct mipi_dbi *mipi = mipi_dbi_from_tinydrm(tdev);
bool swap = mipi->swap_bytes;
-   struct drm_clip_rect clip;
+   struct drm_rect clip;
+   struct drm_rect *rect = 
u16 x_start, y_start;
u16 x1, x2, y1, y2;
int ret = 0;
@@ -95,13 +97,12 @@ static int ili9225_fb_dirty(struct drm_framebuffer *fb,
full = tinydrm_merge_clips(, clips, num_clips, flags,
   fb->width, fb->height);
 
-   DRM_DEBUG("Flushing [FB:%d] x1=%u, x2=%u, y1=%u, y2=%u\n", fb->base.id,
- clip.x1, clip.x2, clip.y1, clip.y2);
+   DRM_DEBUG_KMS("Flushing [FB:%d] " DRM_RECT_FMT "\n", fb->base.id, 
DRM_RECT_ARG(rect));
 
if (!mipi->dc || !full || swap ||
 

[PATCH 4/4] drm/tinydrm: Use damage helper for dirtyfb

[Noralf Trønnes]

This switches to drm_atomic_helper_dirtyfb() as the framebuffer dirty
handler. All flushing will now happen in the pipe functions.

Also enable the damage plane property for all except repaper which can
only do full updates.

ili9225:
This change made ili9225_init() equal to mipi_dbi_init() so use it.

Cc: David Lechner 
Cc: Eric Anholt 
Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/tinydrm/core/tinydrm-core.c   |  21 +---
 .../gpu/drm/tinydrm/core/tinydrm-helpers.c|  91 +---
 drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c   |  30 --
 drivers/gpu/drm/tinydrm/hx8357d.c |   2 +-
 drivers/gpu/drm/tinydrm/ili9225.c | 101 ++
 drivers/gpu/drm/tinydrm/ili9341.c |   2 +-
 drivers/gpu/drm/tinydrm/mi0283qt.c|   2 +-
 drivers/gpu/drm/tinydrm/mipi-dbi.c|  72 -
 drivers/gpu/drm/tinydrm/repaper.c |  39 ---
 drivers/gpu/drm/tinydrm/st7586.c  |  50 +
 drivers/gpu/drm/tinydrm/st7735r.c |   2 +-
 include/drm/tinydrm/mipi-dbi.h|   2 +
 include/drm/tinydrm/tinydrm-helpers.h |  11 +-
 include/drm/tinydrm/tinydrm.h |  26 -
 14 files changed, 138 insertions(+), 313 deletions(-)

diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c 
b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
index 01a6f2d42440..dca0f642fee6 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
@@ -36,31 +36,17 @@
  * and registers the DRM device using devm_tinydrm_register().
  */
 
-static struct drm_framebuffer *
-tinydrm_fb_create(struct drm_device *drm, struct drm_file *file_priv,
- const struct drm_mode_fb_cmd2 *mode_cmd)
-{
-   struct tinydrm_device *tdev = drm->dev_private;
-
-   return drm_gem_fb_create_with_funcs(drm, file_priv, mode_cmd,
-   tdev->fb_funcs);
-}
-
 static const struct drm_mode_config_funcs tinydrm_mode_config_funcs = {
-   .fb_create = tinydrm_fb_create,
+   .fb_create = drm_gem_fb_create_with_dirty,
.atomic_check = drm_atomic_helper_check,
.atomic_commit = drm_atomic_helper_commit,
 };
 
 static int tinydrm_init(struct device *parent, struct tinydrm_device *tdev,
-   const struct drm_framebuffer_funcs *fb_funcs,
struct drm_driver *driver)
 {
struct drm_device *drm;
 
-   mutex_init(>dirty_lock);
-   tdev->fb_funcs = fb_funcs;
-
/*
 * We don't embed drm_device, because that prevent us from using
 * devm_kzalloc() to allocate tinydrm_device in the driver since
@@ -83,7 +69,6 @@ static int tinydrm_init(struct device *parent, struct 
tinydrm_device *tdev,
 static void tinydrm_fini(struct tinydrm_device *tdev)
 {
drm_mode_config_cleanup(tdev->drm);
-   mutex_destroy(>dirty_lock);
tdev->drm->dev_private = NULL;
drm_dev_put(tdev->drm);
 }
@@ -97,7 +82,6 @@ static void devm_tinydrm_release(void *data)
  * devm_tinydrm_init - Initialize tinydrm device
  * @parent: Parent device object
  * @tdev: tinydrm device
- * @fb_funcs: Framebuffer functions
  * @driver: DRM driver
  *
  * This function initializes @tdev, the underlying DRM device and it's
@@ -108,12 +92,11 @@ static void devm_tinydrm_release(void *data)
  * Zero on success, negative error code on failure.
  */
 int devm_tinydrm_init(struct device *parent, struct tinydrm_device *tdev,
- const struct drm_framebuffer_funcs *fb_funcs,
  struct drm_driver *driver)
 {
int ret;
 
-   ret = tinydrm_init(parent, tdev, fb_funcs, driver);
+   ret = tinydrm_init(parent, tdev, driver);
if (ret)
return ret;
 
diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c 
b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
index d0ece6ad4a1c..2737b6fdadc8 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
@@ -17,104 +17,15 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
-#include 
 #include 
-#include 
 
 static unsigned int spi_max;
 module_param(spi_max, uint, 0400);
 MODULE_PARM_DESC(spi_max, "Set a lower SPI max transfer size");
 
-/**
- * tinydrm_merge_clips - Merge clip rectangles
- * @dst: Destination clip rectangle
- * @src: Source clip rectangle(s)
- * @num_clips: Number of @src clip rectangles
- * @flags: Dirty fb ioctl flags
- * @max_width: Maximum width of @dst
- * @max_height: Maximum height of @dst
- *
- * This function merges @src clip rectangle(s) into @dst. If @src is NULL,
- * @max_width and @min_width is used to set a full @dst clip rectangle.
- *
- * Returns:
- * true if it's a full clip, false otherwise
- */
-bool tinydrm_merge_clips(struct drm_rect *dst,
-struct drm_clip_rect *src, unsigned int num_clips,
-unsigned int flags, 

[PATCH 0/4] drm/tinydrm: Use damage helper for dirtyfb

[Noralf Trønnes]

Hi,

I was really pleased to see that the damage helper had landed. Now I can
do framebuffer flushing solely through the display pipe functions. This
prepares the ground for the removal of struct tinydrm_device in my next
series.

Note:
The damage helper isn't in drm-misc-next yet, it will show up when -rc1
arrives there.

Noralf.

Noralf Trønnes (4):
  drm/gem-fb-helper: Add drm_gem_fb_create_with_dirty()
  drm/damage-helper: Add drm_atomic_helper_damage_merged()
  drm/tinydrm: Use struct drm_rect
  drm/tinydrm: Use damage helper for dirtyfb

 drivers/gpu/drm/drm_damage_helper.c   |  43 ++
 drivers/gpu/drm/drm_gem_framebuffer_helper.c  |  47 +-
 drivers/gpu/drm/tinydrm/core/tinydrm-core.c   |  21 +--
 .../gpu/drm/tinydrm/core/tinydrm-helpers.c| 100 +
 drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c   |  30 
 drivers/gpu/drm/tinydrm/hx8357d.c |   2 +-
 drivers/gpu/drm/tinydrm/ili9225.c | 138 +++---
 drivers/gpu/drm/tinydrm/ili9341.c |   2 +-
 drivers/gpu/drm/tinydrm/mi0283qt.c|   2 +-
 drivers/gpu/drm/tinydrm/mipi-dbi.c|  87 +++
 drivers/gpu/drm/tinydrm/repaper.c |  42 +++---
 drivers/gpu/drm/tinydrm/st7586.c  |  73 -
 drivers/gpu/drm/tinydrm/st7735r.c |   2 +-
 include/drm/drm_damage_helper.h   |   3 +
 include/drm/drm_gem_framebuffer_helper.h  |   3 +
 include/drm/tinydrm/mipi-dbi.h|   5 +-
 include/drm/tinydrm/tinydrm-helpers.h |  20 +--
 include/drm/tinydrm/tinydrm.h |  26 
 18 files changed, 281 insertions(+), 365 deletions(-)

-- 
2.20.1

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

[Bug 107652] amdgpu couldn't resume after suspend

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=107652

Mart Raudsepp  changed:

   What|Removed |Added

 CC||l...@gentoo.org

--- Comment #17 from Mart Raudsepp  ---
Created attachment 143042
  --> https://bugs.freedesktop.org/attachment.cgi?id=143042=edit
kernel log pre and post suspend

I still hit something like this with a 4.20 kernel. Perhaps it gives additional
data points to figure it out.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 15/15] drm/bochs: reserve bo for pin/unpin

[Daniel Vetter]

On Wed, Jan 9, 2019 at 3:54 PM Gerd Hoffmann  wrote:
>
> On Wed, Jan 09, 2019 at 11:10:44AM +0100, Daniel Vetter wrote:
> > On Tue, Jan 08, 2019 at 12:25:19PM +0100, Gerd Hoffmann wrote:
> > > The buffer object must be reserved before calling
> > > ttm_bo_validate for pinning/unpinning.
> > >
> > > Signed-off-by: Gerd Hoffmann 
> >
> > Seems a bit a bisect fumble in your series here: legacy kms code reserved
> > the ttm bo before calling boch_bo_pin/unpin, your atomic code doesn't. I
> > think pushing this into bochs_bo_pin/unpin makes sense for atomic, but to
> > avoid bisect fail I think you need to have these temporarily in your
> > cleanup/prepare_plane functions too.
>
> I think I've sorted that.  Have some other changes too, will probably
> send v3 tomorrow.
>
> > Looked through the entire series, this here is the only issue I think
> > should be fixed before merging (making atomic_enable optional can be done
> > as a follow-up if you feel like it). With that addressed on the series:
> >
> > Acked-by: Daniel Vetter 
>
> Thanks.
>
> While being at it:  I'm also looking at dma-buf export and import
> support for the qemu drivers.
>
> Right now both qxl and virtio have gem_prime_get_sg_table and
> gem_prime_import_sg_table handlers which throw a WARN_ONCE() and return
> an error.
>
> If I understand things correctly it is valid to set all import/export
> callbacks (prime_handle_to_fd, prime_fd_to_handle,
> gem_prime_get_sg_table, gem_prime_import_sg_table) to NULL when not
> supporting dma-buf import/export and still advertise DRIVER_PRIME to
> indicate the other prime callbacks are supported (so generic fbdev
> emulation can use gem_prime_vmap etc).  Is that correct?

I'm not sure how much that's a good idea ... Never thought about it
tbh. All the fbdev/dma-buf stuff has plenty of hacks and
inconsistencies still, so I guess we can't make it much worse really.

> On exporting:
>
> TTM_PL_TT should be easy, just pin the buffer, grab the pages list and
> feed that into drm_prime_pages_to_sg.  Didn't try yet though.  Is that
> approach correct?
>
> Is it possible to export TTM_PL_VRAM objects (with backing storage being
> a pci memory bar)?  If so, how?

Not really in general. amdgpu upcasts to amdgpu_bo (if it's amgpu BO)
and then knows the internals so it can do a proper pci peer2peer
mapping. Or at least there's been lots of patches floating around to
make that happen.

I think other drivers migrate the bo out of VRAM.

> On importing:
>
> Importing into TTM_PL_TT object looks easy again, at least when the
> object is actually stored in RAM.  What if not?

They are all supposed to be stored in RAM. Note that all current ttm
importers totally break the abstraction, by taking the sg list,
throwing the dma mapping away and assuming there's a struct page
backing it. Would be good if we could stop spreading that abuse - the
dma-buf interfaces have been modelled after the ttm bo interfaces, so
shouldn't be too hard to wire this up correctly.

> Importing into TTM_PL_VRAM:  Impossible I think, without copying over
> the data.  Should that be done?  If so, how?  Or is it better to just
> not support import then?

Hm, since you ask about TTM concepts and not what this means in terms
of dma-buf: As long as you upcast to the ttm_bo you can do whatever
you want to really. But with plain dma-buf this doesn't work right now
(least because ttm assumes it gets system RAM on import, in theory you
could put the peer2peer dma mapping into the sg list and it should
work).
-Daniel

>
> thanks,
>   Gerd
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 108098] Ryzen 7 2700U, amdgpu, graphics freezes on 4.19.0-041900-generic

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=108098

--- Comment #9 from Daniel Stone  ---
(In reply to Michel Dänzer from comment #7)
> FWIW, I advise against paying too much attention to fin4478. They are not
> involved in driver development and known for making rather questionable
> suggestions which are definitely not suitable for everyone.

@finn4478: Please stop posting in these bugs asserting which
distributions/environments/etc do and don't work. Most of what you say is not
factual, and though I'm sure you have good intentions, you are misleading users
and frustrating both users and developers. If you do not stop with these
interjections, we may have to remove your ability to comment.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 09/10] drm/mxsfb: Improve the axi clock usage

[Stefan Agner]

On 09.01.2019 15:13, Robert Chiras wrote:
> Currently, the enable of the axi clock return status is ignored, causing
> issues when the enable fails then we try to disable it. Therefore, it is
> better to check the return status and disable it only when enable
> succeeded.
> Also, remove the helper functions around clk_axi, since we can directly
> use the clk API function for enable/disable the clock. Those functions
> are already checking for NULL clk and returning 0 if that's the case.

Can we maybe even use the runtime PM system for that (adding two
callbacks for SET_RUNTIME_PM_OPS)?

I suggested it a while ago, but did not looked deeper into it:
https://lkml.org/lkml/2018/8/1/300

Since we basically enable on mxsfb_crtc_enable and disable on
mxsfb_crtc_disable, I think it would be pretty much the same thing.

--
Stefan


> 
> Signed-off-by: Robert Chiras 
> Acked-by: Leonard Crestez 
> ---
>  drivers/gpu/drm/mxsfb/mxsfb_crtc.c |  8 
>  drivers/gpu/drm/mxsfb/mxsfb_drv.c  | 32 +---
>  drivers/gpu/drm/mxsfb/mxsfb_drv.h  |  3 ---
>  3 files changed, 17 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
> b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
> index 8d1b6a6..b9437c7 100644
> --- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
> +++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
> @@ -411,7 +411,7 @@ void mxsfb_crtc_enable(struct mxsfb_drm_private *mxsfb)
>  {
>   dma_addr_t paddr;
>  
> - mxsfb_enable_axi_clk(mxsfb);
> + clk_prepare_enable(mxsfb->clk_axi);
>   writel(0, mxsfb->base + LCDC_CTRL);
>   mxsfb_crtc_mode_set_nofb(mxsfb);
>  
> @@ -428,7 +428,7 @@ void mxsfb_crtc_enable(struct mxsfb_drm_private *mxsfb)
>  void mxsfb_crtc_disable(struct mxsfb_drm_private *mxsfb)
>  {
>   mxsfb_disable_controller(mxsfb);
> - mxsfb_disable_axi_clk(mxsfb);
> + clk_disable_unprepare(mxsfb->clk_axi);
>  }
>  
>  void mxsfb_plane_atomic_update(struct mxsfb_drm_private *mxsfb,
> @@ -456,9 +456,9 @@ void mxsfb_plane_atomic_update(struct
> mxsfb_drm_private *mxsfb,
>  
>   paddr = mxsfb_get_fb_paddr(mxsfb);
>   if (paddr) {
> - mxsfb_enable_axi_clk(mxsfb);
> + clk_prepare_enable(mxsfb->clk_axi);
>   writel(paddr, mxsfb->base + mxsfb->devdata->next_buf);
> - mxsfb_disable_axi_clk(mxsfb);
> + clk_disable_unprepare(mxsfb->clk_axi);
>   }
>  
>   if (!fb || !old_fb)
> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> index 135b8e1..5e18353 100644
> --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> @@ -103,18 +103,6 @@ drm_pipe_to_mxsfb_drm_private(struct
> drm_simple_display_pipe *pipe)
>   return container_of(pipe, struct mxsfb_drm_private, pipe);
>  }
>  
> -void mxsfb_enable_axi_clk(struct mxsfb_drm_private *mxsfb)
> -{
> - if (mxsfb->clk_axi)
> - clk_prepare_enable(mxsfb->clk_axi);
> -}
> -
> -void mxsfb_disable_axi_clk(struct mxsfb_drm_private *mxsfb)
> -{
> - if (mxsfb->clk_axi)
> - clk_disable_unprepare(mxsfb->clk_axi);
> -}
> -
>  /**
>   * mxsfb_atomic_helper_check - validate state object
>   * @dev: DRM device
> @@ -237,25 +225,31 @@ static void mxsfb_pipe_update(struct
> drm_simple_display_pipe *pipe,
>  static int mxsfb_pipe_enable_vblank(struct drm_simple_display_pipe *pipe)
>  {
>   struct mxsfb_drm_private *mxsfb = drm_pipe_to_mxsfb_drm_private(pipe);
> + int ret = 0;
> +
> + ret = clk_prepare_enable(mxsfb->clk_axi);
> + if (ret)
> + return ret;
>  
>   /* Clear and enable VBLANK IRQ */
> - mxsfb_enable_axi_clk(mxsfb);
>   writel(CTRL1_CUR_FRAME_DONE_IRQ, mxsfb->base + LCDC_CTRL1 + REG_CLR);
>   writel(CTRL1_CUR_FRAME_DONE_IRQ_EN, mxsfb->base + LCDC_CTRL1 + REG_SET);
> - mxsfb_disable_axi_clk(mxsfb);
> + clk_disable_unprepare(mxsfb->clk_axi);
>  
> - return 0;
> + return ret;
>  }
>  
>  static void mxsfb_pipe_disable_vblank(struct drm_simple_display_pipe *pipe)
>  {
>   struct mxsfb_drm_private *mxsfb = drm_pipe_to_mxsfb_drm_private(pipe);
>  
> + if (clk_prepare_enable(mxsfb->clk_axi))
> + return;
> +
>   /* Disable and clear VBLANK IRQ */
> - mxsfb_enable_axi_clk(mxsfb);
>   writel(CTRL1_CUR_FRAME_DONE_IRQ_EN, mxsfb->base + LCDC_CTRL1 + REG_CLR);
>   writel(CTRL1_CUR_FRAME_DONE_IRQ, mxsfb->base + LCDC_CTRL1 + REG_CLR);
> - mxsfb_disable_axi_clk(mxsfb);
> + clk_disable_unprepare(mxsfb->clk_axi);
>  }
>  
>  static struct drm_simple_display_pipe_funcs mxsfb_funcs = {
> @@ -440,7 +434,7 @@ static irqreturn_t mxsfb_irq_handler(int irq, void *data)
>   struct mxsfb_drm_private *mxsfb = drm->dev_private;
>   u32 reg;
>  
> - mxsfb_enable_axi_clk(mxsfb);
> + clk_prepare_enable(mxsfb->clk_axi);
>  
>   reg = readl(mxsfb->base + LCDC_CTRL1);
>  
> @@ -449,7 +443,7 @@ static irqreturn_t mxsfb_irq_handler(int irq, void *data)
>  
>   

Re: [RFC] Getting OpenChrome DRM mainlined into Linux kernel tree

[Kevin Brace]

Hi Sean,

I do recall seeing you at XDC2017, I do not believe I spoke with you at the 
event.
I will not name the name, but I had one developer who strongly asked me to 
convert to atomic mode setting, but I refused due to the state of the code at 
the time.
Now, the KMS device support is mostly comparable to the existing UMS code path, 
so I can soon consider implementing universal plane and atomic mode setting.
I am okay with the OpenChrome DRM not being activated initially (i.e., 
Displaying "(Experimental)" status when running menuconfig), but I do want it 
directly inserted into the DRM tree from day one after the code is pulled in. 
(i.e., not getting inserted into the "staging" tree)
I believe the current code quality is good enough for this arrangement.

Regards,

Kevin Brace
Brace Computer Laboratory blog
https://bracecomputerlab.com


> Sent: Wednesday, June 13, 2018 at 1:07 PM
> From: "Sean Paul" 
> To: kevinbr...@gmx.com
> Cc: "Dave Airlie" , dri-devel 
> , openchrome-de...@lists.freedesktop.org
> Subject: Re: [RFC] Getting OpenChrome DRM mainlined into Linux kernel tree
>
> I think I was one of those developers asking you to switch to atomic
> (iirc, i encouraged you to start working on kms instead of ums). I
> know this is a personal project that you've been working on in your
> spare time (which is awesome!), so while I still encourage you to
> convert the driver, I don't have a problem with you doing the
> conversion in mainline. I think hiding under staging until the
> conversion is complete is a pretty reasonable compromise.
> 
> Sean
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 109235] Using named pixmap of window right after resizing results in garbage content

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109235

Michel Dänzer  changed:

   What|Removed |Added

 QA Contact|dri-devel@lists.freedesktop |xorg-t...@lists.x.org
   |.org|
   Assignee|dri-devel@lists.freedesktop |xorg-driver-...@lists.x.org
   |.org|
Product|Mesa|xorg
Version|unspecified |git
  Component|Drivers/Gallium/radeonsi|Driver/AMDgpu

--- Comment #2 from Michel Dänzer  ---
Does
https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/merge_requests/21
fix it?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 1/4] drm/vc4: Wait for display list synchronization when completing commit

[Paul Kocialkowski]

Hi Daniel,

On Tue, 2019-01-08 at 19:21 +0100, Daniel Vetter wrote:
> On Tue, Jan 8, 2019 at 3:51 PM Paul Kocialkowski
>  wrote:
> > During an atomic commit, the HVS is configured with a display list
> > for the channel matching the associated CRTC. The Pixel Valve (CRTC)
> > and encoder are also configured for the new setup at that time.
> > While the Pixel Valve and encoder are reconfigured synchronously, the
> > HVS is only reconfigured after the display list address (DISPLIST) has
> > been updated to the current display list address (DISPLACTX), which is
> > the responsibility of the hardware.
> > 
> > The time frame during which the HVS is still running on its previous
> > configuration but the CRTC and encoder have been reconfigured already
> > can lead to a number of synchronization issues. They will eventually
> > cause errors reported on the FIFOs, such as underruns.
> > 
> > With underrun detection enabled (from Boris Brezillon's series), this
> > leads to unreliable underrun detection with random false positives.
> > 
> > To ensure a coherent state, wait for each enabled channel of the HVS
> > to synchronize its current display list address. This fixes the issue
> > of random underrun reporting on commits.
> > 
> > Signed-off-by: Paul Kocialkowski 
> > ---
> >  drivers/gpu/drm/vc4/vc4_drv.h  |  1 +
> >  drivers/gpu/drm/vc4/vc4_hvs.c  | 17 +
> >  drivers/gpu/drm/vc4/vc4_kms.c  |  2 ++
> >  drivers/gpu/drm/vc4/vc4_regs.h |  2 ++
> >  4 files changed, 22 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
> > index c24b078f0593..955f157f5ad0 100644
> > --- a/drivers/gpu/drm/vc4/vc4_drv.h
> > +++ b/drivers/gpu/drm/vc4/vc4_drv.h
> > @@ -772,6 +772,7 @@ void vc4_irq_reset(struct drm_device *dev);
> >  extern struct platform_driver vc4_hvs_driver;
> >  void vc4_hvs_dump_state(struct drm_device *dev);
> >  int vc4_hvs_debugfs_regs(struct seq_file *m, void *unused);
> > +void vc4_hvs_sync_dlist(struct drm_device *dev);
> > 
> >  /* vc4_kms.c */
> >  int vc4_kms_load(struct drm_device *dev);
> > diff --git a/drivers/gpu/drm/vc4/vc4_hvs.c b/drivers/gpu/drm/vc4/vc4_hvs.c
> > index 5d8c749c9749..1ba60b8e0c2d 100644
> > --- a/drivers/gpu/drm/vc4/vc4_hvs.c
> > +++ b/drivers/gpu/drm/vc4/vc4_hvs.c
> > @@ -166,6 +166,23 @@ static int vc4_hvs_upload_linear_kernel(struct vc4_hvs 
> > *hvs,
> > return 0;
> >  }
> > 
> > +void vc4_hvs_sync_dlist(struct drm_device *dev)
> > +{
> > +   struct vc4_dev *vc4 = to_vc4_dev(dev);
> > +   unsigned int i;
> > +   int ret;
> > +
> > +   for (i = 0; i < SCALER_CHANNELS_COUNT; i++) {
> > +   if (!(HVS_READ(SCALER_DISPCTRLX(i)) & 
> > SCALER_DISPCTRLX_ENABLE))
> > +   continue;
> > +
> > +   ret = wait_for(HVS_READ(SCALER_DISPLACTX(i)) ==
> > +  HVS_READ(SCALER_DISPLISTX(i)), 1000);
> > +   WARN(ret, "Timeout waiting for channel %d display list 
> > sync\n",
> > +i);
> > +   }
> > +}
> > +
> >  static int vc4_hvs_bind(struct device *dev, struct device *master, void 
> > *data)
> >  {
> > struct platform_device *pdev = to_platform_device(dev);
> > diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
> > index 0490edb192a1..2d66a2b57a91 100644
> > --- a/drivers/gpu/drm/vc4/vc4_kms.c
> > +++ b/drivers/gpu/drm/vc4/vc4_kms.c
> > @@ -155,6 +155,8 @@ vc4_atomic_complete_commit(struct drm_atomic_state 
> > *state)
> > 
> > drm_atomic_helper_commit_hw_done(state);
> > 
> > +   vc4_hvs_sync_dlist(dev);
> 
> From your description I'd have guessed you want this between when you
> update the planes and the crtc, so somewhere between commit_planes()
> and commit_modeset_enables(). At least I have no idea how waiting here
> can prevent underruns, by this point there's no further hw programming
> happening.

One thing that I did not mention is that the display list (that
configures the planes) is only set at crtc_enable time (and taken into
account by the hardware later).

However, even calling vc4_hvs_sync_dlist right at the end of
crtc_enable doesn't do either (the old display list just sticks). It
only seems to work after the HDMI encoder enable step and I don't know
any good reason why.

I didn't find any description of when that dlist sync mechanism is
supposed to take place and what particular event triggers it. Perhaps
it is triggered by a signal originating from the encoder? If anyone has
insight on the hardware, feel free to shed some light here :)

Cheers and thanks for the review,

Paul

> Only exception is if you have an IOMMU which can fault, in
> which case the cleanup_planes might remove the buffers prematurely.
> But if that's the problem, then your semantics of the flip_done event
> are wrong - when flip_done is signalled, the hw must have stopped
> scanning out the old planes, since userspace expects to be able to
> start overwriting/reusing 

Re: [PATCH v4 2/3] drm/msm/dpu: Integrate interconnect API in MDSS

[Doug Anderson]

Hi,

On Wed, Jan 9, 2019 at 6:38 AM Georgi Djakov  wrote:
>
> Hi Jayant,
>
> On 12/21/18 08:20, Jayant Shekhar wrote:
> > From: Sravanthi Kollukuduru 
> >
> > The interconnect framework is designed to provide a
> > standard kernel interface to control the settings of
> > the interconnects on a SoC.
> >
> > The interconnect API uses a consumer/provider-based model,
> > where the providers are the interconnect buses and the
> > consumers could be various drivers.
> >
> > MDSS is one of the interconnect consumers which uses the
> > interconnect APIs to get the path between endpoints and
> > set its bandwidth/latency/QoS requirements for the given
>
> Currently we set only bandwidth.
>
> > interconnected path.
> >
> > Changes in v2:
> >   - Remove error log and unnecessary check (Jordan Crouse)
> >
> > Changes in v3:
> >   - Code clean involving variable name change, removal
> > of extra paranthesis and variables (Matthias Kaehlcke)
> >
> > Changes in v4:
> >   - Add comments, spacings, tabs, proper port name
> > and icc macro (Georgi Djakov)
>
> The changes should not be part of the commit text, but should move below
> the "---" line.

Drive-by comment that (I believe) they actually should be part of the
commit text.  Convention for changes in the "drm" subsystem appears to
be to include the revision log in the commit text.  This is unlike the
rest of the kernel, but *shrug*.

Try, for instance:

git log --no-merges v4.19..v5.0-rc1 drivers/gpu/drm/msm | grep 'v[0-9]'

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

Re: [PATCH v2 2/2] drm/fb-helper: Ignore the value of fb_var_screeninfo.pixclock

[Sasha Levin]

Hi,

[This is an automated email]

This commit has been processed because it contains a "Fixes:" tag,
fixing commit: 79e539453b34 DRM: i915: add mode setting support.

The bot has tested the following trees: v4.20.0, v4.19.13, v4.14.91, v4.9.148, 
v4.4.169, v3.18.131.

v4.20.0: Failed to apply! Possible dependencies:
042bf753842d ("drm/fourcc: Add char_per_block, block_w and block_h in 
drm_format_info")
9c71a6686bfa ("drm: fourcc: Convert drm_format_info kerneldoc to in-line 
member documentation")

v4.19.13: Failed to apply! Possible dependencies:
042bf753842d ("drm/fourcc: Add char_per_block, block_w and block_h in 
drm_format_info")
9c71a6686bfa ("drm: fourcc: Convert drm_format_info kerneldoc to in-line 
member documentation")
c76abab59b3c ("drm: Use horizontal and vertical chroma subsampling factor 
while calculating offsets in the physical address of framebuffer")

v4.14.91: Failed to apply! Possible dependencies:
042bf753842d ("drm/fourcc: Add char_per_block, block_w and block_h in 
drm_format_info")
4cc4e1b40f3f ("drm/fourcc: Add a alpha field to drm_format_info")
9c71a6686bfa ("drm: fourcc: Convert drm_format_info kerneldoc to in-line 
member documentation")
c76abab59b3c ("drm: Use horizontal and vertical chroma subsampling factor 
while calculating offsets in the physical address of framebuffer")
ce2d54619a10 ("drm/fourcc: Add is_yuv field to drm_format_info to denote if 
the format is yuv")

v4.9.148: Failed to apply! Possible dependencies:
042bf753842d ("drm/fourcc: Add char_per_block, block_w and block_h in 
drm_format_info")
05fc03217e08 ("drm/mm: Some doc polish")
06df8ac682e6 ("drm: kselftest for drm_mm_debug()")
14d7f96f90fb ("drm/fb_cma_helper: Add drm_fb_cma_prepare_fb() helper")
2bd966d106e3 ("drm: kselftest for drm_mm_replace_node()")
2fba0de0a9ec ("drm: kselftest for drm_mm_insert_node_in_range()")
393b50f30566 ("drm: kselftest for drm_mm_init()")
4636ce93d5b2 ("drm/fb-cma-helper: Add drm_fb_cma_get_gem_addr()")
50f0033d1a0f ("drm: Add some kselftests for the DRM range manager (struct 
drm_mm)")
5628648df755 ("drm/fb-cma-helper: Use drm_gem_framebuffer_helper")
5705670d0463 ("drm: Track drm_mm allocators and show leaks on shutdown")
6259a56ba0e1 ("drm: Add asserts to catch overflow in drm_mm_init() and 
drm_mm_init_scan()")
62a0d98a188c ("drm: allow to use mmuless SoC")
72a93e8dd52c ("drm: Take ownership of the dmabuf->obj when exporting")
7886692a5804 ("drm: kselftest for drm_mm_insert_node()")
900537dc3889 ("drm: kselftest for drm_mm_reserve_node()")
940eba2d58a7 ("drm/gem|prime|mm: Use recommened kerneldoc for struct member 
refs")
9a71e277888b ("drm: Extract struct drm_mm_scan from struct drm_mm")
9b26f2ed29f8 ("drm: kselftest for drm_mm and alignment")
b112481bb327 ("drm/cma-helper: simplify setup for drivers with ->dirty 
callbacks")
b3ee963fe41d ("drm: Compile time enabling for asserts in drm_mm")
ba004e39b199 ("drm: Fix kerneldoc for drm_mm_scan_remove_block()")
c76abab59b3c ("drm: Use horizontal and vertical chroma subsampling factor 
while calculating offsets in the physical address of framebuffer")
e6b62714e87c ("drm: Introduce drm_gem_object_{get,put}()")

v4.4.169: Failed to apply! Possible dependencies:
042bf753842d ("drm/fourcc: Add char_per_block, block_w and block_h in 
drm_format_info")
14d7f96f90fb ("drm/fb_cma_helper: Add drm_fb_cma_prepare_fb() helper")
199c77179c87 ("drm/fb-cma-helper: Add fb_deferred_io support")
1eb83451ba55 ("drm: Pass the user drm_mode_fb_cmd2 as const to 
.fb_create()")
4636ce93d5b2 ("drm/fb-cma-helper: Add drm_fb_cma_get_gem_addr()")
5628648df755 ("drm/fb-cma-helper: Use drm_gem_framebuffer_helper")
70c0616d5a84 ("drm/fb_cma_helper: remove duplicate const from 
drm_fb_cma_alloc")
b112481bb327 ("drm/cma-helper: simplify setup for drivers with ->dirty 
callbacks")
c76abab59b3c ("drm: Use horizontal and vertical chroma subsampling factor 
while calculating offsets in the physical address of framebuffer")
ce0c57576810 ("drm/fb_cma_helper: Implement fb_mmap callback")
fdce184609ee ("drm/fb-cma-helper: Use const for drm_framebuffer_funcs 
argument")

v3.18.131: Failed to apply! Possible dependencies:
042bf753842d ("drm/fourcc: Add char_per_block, block_w and block_h in 
drm_format_info")
14d7f96f90fb ("drm/fb_cma_helper: Add drm_fb_cma_prepare_fb() helper")
199c77179c87 ("drm/fb-cma-helper: Add fb_deferred_io support")
1a396789f65a ("drm: add Atmel HLCDC Display Controller support")
1eb83451ba55 ("drm: Pass the user drm_mode_fb_cmd2 as const to 
.fb_create()")
2a8cb4894540 ("drm/exynos: merge exynos_drm_buf.c to exynos_drm_gem.c")
2b8376c803c4 ("drm/exynos: remove struct exynos_drm_encoder layer")
39a839f2e651 ("drm/exynos: s/exynos_gem_obj/obj in exynos_drm_fbdev.c")
421ee18d4e04 ("drm/exynos: fix null pointer dereference issue")
  

Re: [PATCH v2 2/2] drm/fb-helper: Ignore the value of fb_var_screeninfo.pixclock

[Sasha Levin]

Hi,

[This is an automated email]

This commit has been processed because it contains a "Fixes:" tag,
fixing commit: 79e539453b34 DRM: i915: add mode setting support.

The bot has tested the following trees: v4.20.0, v4.19.13, v4.14.91, v4.9.148, 
v4.4.169, v3.18.131.

v4.20.0: Failed to apply! Possible dependencies:
042bf753842d ("drm/fourcc: Add char_per_block, block_w and block_h in 
drm_format_info")
9c71a6686bfa ("drm: fourcc: Convert drm_format_info kerneldoc to in-line 
member documentation")

v4.19.13: Failed to apply! Possible dependencies:
042bf753842d ("drm/fourcc: Add char_per_block, block_w and block_h in 
drm_format_info")
9c71a6686bfa ("drm: fourcc: Convert drm_format_info kerneldoc to in-line 
member documentation")
c76abab59b3c ("drm: Use horizontal and vertical chroma subsampling factor 
while calculating offsets in the physical address of framebuffer")

v4.14.91: Failed to apply! Possible dependencies:
042bf753842d ("drm/fourcc: Add char_per_block, block_w and block_h in 
drm_format_info")
4cc4e1b40f3f ("drm/fourcc: Add a alpha field to drm_format_info")
9c71a6686bfa ("drm: fourcc: Convert drm_format_info kerneldoc to in-line 
member documentation")
c76abab59b3c ("drm: Use horizontal and vertical chroma subsampling factor 
while calculating offsets in the physical address of framebuffer")
ce2d54619a10 ("drm/fourcc: Add is_yuv field to drm_format_info to denote if 
the format is yuv")

v4.9.148: Failed to apply! Possible dependencies:
042bf753842d ("drm/fourcc: Add char_per_block, block_w and block_h in 
drm_format_info")
05fc03217e08 ("drm/mm: Some doc polish")
06df8ac682e6 ("drm: kselftest for drm_mm_debug()")
14d7f96f90fb ("drm/fb_cma_helper: Add drm_fb_cma_prepare_fb() helper")
2bd966d106e3 ("drm: kselftest for drm_mm_replace_node()")
2fba0de0a9ec ("drm: kselftest for drm_mm_insert_node_in_range()")
393b50f30566 ("drm: kselftest for drm_mm_init()")
4636ce93d5b2 ("drm/fb-cma-helper: Add drm_fb_cma_get_gem_addr()")
50f0033d1a0f ("drm: Add some kselftests for the DRM range manager (struct 
drm_mm)")
5628648df755 ("drm/fb-cma-helper: Use drm_gem_framebuffer_helper")
5705670d0463 ("drm: Track drm_mm allocators and show leaks on shutdown")
6259a56ba0e1 ("drm: Add asserts to catch overflow in drm_mm_init() and 
drm_mm_init_scan()")
62a0d98a188c ("drm: allow to use mmuless SoC")
72a93e8dd52c ("drm: Take ownership of the dmabuf->obj when exporting")
7886692a5804 ("drm: kselftest for drm_mm_insert_node()")
900537dc3889 ("drm: kselftest for drm_mm_reserve_node()")
940eba2d58a7 ("drm/gem|prime|mm: Use recommened kerneldoc for struct member 
refs")
9a71e277888b ("drm: Extract struct drm_mm_scan from struct drm_mm")
9b26f2ed29f8 ("drm: kselftest for drm_mm and alignment")
b112481bb327 ("drm/cma-helper: simplify setup for drivers with ->dirty 
callbacks")
b3ee963fe41d ("drm: Compile time enabling for asserts in drm_mm")
ba004e39b199 ("drm: Fix kerneldoc for drm_mm_scan_remove_block()")
c76abab59b3c ("drm: Use horizontal and vertical chroma subsampling factor 
while calculating offsets in the physical address of framebuffer")
e6b62714e87c ("drm: Introduce drm_gem_object_{get,put}()")

v4.4.169: Failed to apply! Possible dependencies:
042bf753842d ("drm/fourcc: Add char_per_block, block_w and block_h in 
drm_format_info")
14d7f96f90fb ("drm/fb_cma_helper: Add drm_fb_cma_prepare_fb() helper")
199c77179c87 ("drm/fb-cma-helper: Add fb_deferred_io support")
1eb83451ba55 ("drm: Pass the user drm_mode_fb_cmd2 as const to 
.fb_create()")
4636ce93d5b2 ("drm/fb-cma-helper: Add drm_fb_cma_get_gem_addr()")
5628648df755 ("drm/fb-cma-helper: Use drm_gem_framebuffer_helper")
70c0616d5a84 ("drm/fb_cma_helper: remove duplicate const from 
drm_fb_cma_alloc")
b112481bb327 ("drm/cma-helper: simplify setup for drivers with ->dirty 
callbacks")
c76abab59b3c ("drm: Use horizontal and vertical chroma subsampling factor 
while calculating offsets in the physical address of framebuffer")
ce0c57576810 ("drm/fb_cma_helper: Implement fb_mmap callback")
fdce184609ee ("drm/fb-cma-helper: Use const for drm_framebuffer_funcs 
argument")

v3.18.131: Failed to apply! Possible dependencies:
042bf753842d ("drm/fourcc: Add char_per_block, block_w and block_h in 
drm_format_info")
14d7f96f90fb ("drm/fb_cma_helper: Add drm_fb_cma_prepare_fb() helper")
199c77179c87 ("drm/fb-cma-helper: Add fb_deferred_io support")
1a396789f65a ("drm: add Atmel HLCDC Display Controller support")
1eb83451ba55 ("drm: Pass the user drm_mode_fb_cmd2 as const to 
.fb_create()")
2a8cb4894540 ("drm/exynos: merge exynos_drm_buf.c to exynos_drm_gem.c")
2b8376c803c4 ("drm/exynos: remove struct exynos_drm_encoder layer")
39a839f2e651 ("drm/exynos: s/exynos_gem_obj/obj in exynos_drm_fbdev.c")
421ee18d4e04 ("drm/exynos: fix null pointer dereference issue")
  

[Bug 109234] amdgpu random hangs with 4.21+

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109234

--- Comment #12 from Michel Dänzer  ---
Looks like this should be reported to Christoph Hellwig and other kernel DMA
mapping helper developers then. Please Cc the dri-devel mailing list when doing
so.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 109234] amdgpu random hangs with 4.21+

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109234

--- Comment #10 from Sibren Vasse  ---
Created attachment 143038
  --> https://bugs.freedesktop.org/attachment.cgi?id=143038=edit
Bisect result

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 109234] amdgpu random hangs with 4.21+

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109234

--- Comment #11 from Sibren Vasse  ---
I've been running into this issue multiple times a day. I noticed I hit the
OOPS a lot more frequent when my system was under load (e.g. compiling a
kernel) and then opening a new tab in Firefox. 

Don't ask me how, but eventually I figured out I could reproduce the problem
reliably on my system by starting many instances of my terminal emulator until
I hit the OOM killer.

v4.20 (good): OOM Killer kills processes and/or my user session and I can login
again.
v5.0-rc1 (bad): System hangs with OOPS in dmesg.

So I started bisecting, result attached.

I have not been able to reproduce after reverting parent merge commit
[af7ddd8a627c62a835524b3f5b471edbbbcce025]
and these related commits:
06f55fd2d22742ed7e725124dfea68936d12ce40
2e05ea5cdc1ac55d9ef678ed5ea6c38acf7fd2a3
d7076f07840851bbe57cb21ba052d6a4a9b1efa9
4788ba5792cc1368ba4867e1488dc168b4fe97b7
ed6ccf10f24bdfc1955bc8b976ddedc370fc3869

See the full tree here: https://github.com/SibrenVasse/linux/tree/revert

Hope this helps!

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 1/2] drm/sched: Refactor ring mirror list handling.

[Grodzovsky, Andrey]

On 01/09/2019 05:22 AM, Christian König wrote:
> Am 07.01.19 um 20:47 schrieb Grodzovsky, Andrey:
>>
>> On 01/07/2019 09:13 AM, Christian König wrote:
>>> Am 03.01.19 um 18:42 schrieb Grodzovsky, Andrey:
 On 01/03/2019 11:20 AM, Grodzovsky, Andrey wrote:
> On 01/03/2019 03:54 AM, Koenig, Christian wrote:
>> Am 21.12.18 um 21:36 schrieb Grodzovsky, Andrey:
>>> On 12/21/2018 01:37 PM, Christian König wrote:
 Am 20.12.18 um 20:23 schrieb Andrey Grodzovsky:
> Decauple sched threads stop and start and ring mirror
> list handling from the policy of what to do about the
> guilty jobs.
> When stoppping the sched thread and detaching sched fences
> from non signaled HW fenes wait for all signaled HW fences
> to complete before rerunning the jobs.
>
> v2: Fix resubmission of guilty job into HW after refactoring.
>
> v4:
> Full restart for all the jobs, not only from guilty ring.
> Extract karma increase into standalone function.
>
> v5:
> Rework waiting for signaled jobs without relying on the job
> struct itself as those might already be freed for non 'guilty'
> job's schedulers.
> Expose karma increase to drivers.
>
> Suggested-by: Christian Koenig 
> Signed-off-by: Andrey Grodzovsky 
> ---
>    drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  18 +--
>    drivers/gpu/drm/etnaviv/etnaviv_sched.c |  11 +-
>    drivers/gpu/drm/scheduler/sched_main.c | 188
> +++--
>    drivers/gpu/drm/v3d/v3d_sched.c |  12 +-
>    include/drm/gpu_scheduler.h |  10 +-
>    5 files changed, 151 insertions(+), 88 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index 8a078f4..a4bd2d3 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -3298,12 +3298,10 @@ static int
> amdgpu_device_pre_asic_reset(struct amdgpu_device *adev,
>    if (!ring || !ring->sched.thread)
>    continue;
>    - kthread_park(ring->sched.thread);
> +    drm_sched_stop(>sched, job ? >base : NULL);
>    -    if (job && job->base.sched != >sched)
> -    continue;
> -
> - drm_sched_hw_job_reset(>sched, job ? >base :
> NULL);
> +    if(job)
> + drm_sched_increase_karma(>base);
 Since we dropped the "job && job->base.sched != >sched" 
 check
 above this will now increase the jobs karma multiple times.

 Maybe just move that outside of the loop.

>      /* after all hw jobs are reset, hw fence is
> meaningless,
> so force_completion */
> amdgpu_fence_driver_force_completion(ring);
> @@ -3454,14 +3452,10 @@ static void
> amdgpu_device_post_asic_reset(struct amdgpu_device *adev,
>    if (!ring || !ring->sched.thread)
>    continue;
>    -    /* only need recovery sched of the given job's 
> ring
> - * or all rings (in the case @job is NULL)
> - * after above amdgpu_reset accomplished
> - */
> -    if ((!job || job->base.sched == >sched) &&
> !adev->asic_reset_res)
> - drm_sched_job_recovery(>sched);
> +    if (!adev->asic_reset_res)
> + drm_sched_resubmit_jobs(>sched);
>    - kthread_unpark(ring->sched.thread);
> +    drm_sched_start(>sched, !adev->asic_reset_res);
>    }
>      if (!amdgpu_device_has_dc_support(adev)) {
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
> b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
> index 49a6763..6f1268f 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
> @@ -109,16 +109,19 @@ static void 
> etnaviv_sched_timedout_job(struct
> drm_sched_job *sched_job)
>    }
>      /* block scheduler */
> -    kthread_park(gpu->sched.thread);
> -    drm_sched_hw_job_reset(>sched, sched_job);
> +    drm_sched_stop(>sched, sched_job);
> +
> +    if(sched_job)
> +    drm_sched_increase_karma(sched_job);
>      /* get the GPU back into the init state */
>    etnaviv_core_dump(gpu);
>    etnaviv_gpu_recover_hang(gpu);
>    + drm_sched_resubmit_jobs(>sched);
> +
>    /* restart scheduler after GPU is usable again */

Re: [PATCHv2 0/7] drm/bridge: tc358767: small fixes

[Lucas Stach]

Hi Tomi,

Am Mittwoch, den 09.01.2019, 16:55 +0200 schrieb Tomi Valkeinen:
> On 09/01/19 11:51, Lucas Stach wrote:
> 
> > For the series:
> > 
> > > > Tested-by: Lucas Stach 
> > 
> > on a device with TC358767 and a 4.20 based kernel.
> 
> Thanks Lucas.
> 
> Does the device use TC358767 as eDP+panel, or as full DP with an
> external connector? We have the latter, and I think there are some
> missing pieces in the driver which I'll be working on some time in the
> near future.

It's eDP + panel.

Regards,
Lucas
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104362] GPU fault detected on wine-nine Path of Exile

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=104362

--- Comment #11 from nmr  ---
Created attachment 143037
  --> https://bugs.freedesktop.org/attachment.cgi?id=143037=edit
dmesg dump for hang

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCHv2 0/7] drm/bridge: tc358767: small fixes

[Tomi Valkeinen]

On 09/01/19 11:51, Lucas Stach wrote:

> For the series:
> 
> Tested-by: Lucas Stach 
> 
> on a device with TC358767 and a 4.20 based kernel.

Thanks Lucas.

Does the device use TC358767 as eDP+panel, or as full DP with an
external connector? We have the latter, and I think there are some
missing pieces in the driver which I'll be working on some time in the
near future.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104362] GPU fault detected on wine-nine Path of Exile

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=104362

nmr  changed:

   What|Removed |Added

 CC||nnmmrr88...@gmail.com

--- Comment #10 from nmr  ---
Created attachment 143036
  --> https://bugs.freedesktop.org/attachment.cgi?id=143036=edit
UMR dump for PoE/gallium-nine induced AMDGPU hang

I am experiencing the same bug, here is the UMR dump.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 15/15] drm/bochs: reserve bo for pin/unpin

[Gerd Hoffmann]

On Wed, Jan 09, 2019 at 11:10:44AM +0100, Daniel Vetter wrote:
> On Tue, Jan 08, 2019 at 12:25:19PM +0100, Gerd Hoffmann wrote:
> > The buffer object must be reserved before calling
> > ttm_bo_validate for pinning/unpinning.
> > 
> > Signed-off-by: Gerd Hoffmann 
> 
> Seems a bit a bisect fumble in your series here: legacy kms code reserved
> the ttm bo before calling boch_bo_pin/unpin, your atomic code doesn't. I
> think pushing this into bochs_bo_pin/unpin makes sense for atomic, but to
> avoid bisect fail I think you need to have these temporarily in your
> cleanup/prepare_plane functions too.

I think I've sorted that.  Have some other changes too, will probably
send v3 tomorrow.

> Looked through the entire series, this here is the only issue I think
> should be fixed before merging (making atomic_enable optional can be done
> as a follow-up if you feel like it). With that addressed on the series:
> 
> Acked-by: Daniel Vetter 

Thanks.

While being at it:  I'm also looking at dma-buf export and import
support for the qemu drivers.

Right now both qxl and virtio have gem_prime_get_sg_table and
gem_prime_import_sg_table handlers which throw a WARN_ONCE() and return
an error.

If I understand things correctly it is valid to set all import/export
callbacks (prime_handle_to_fd, prime_fd_to_handle,
gem_prime_get_sg_table, gem_prime_import_sg_table) to NULL when not
supporting dma-buf import/export and still advertise DRIVER_PRIME to
indicate the other prime callbacks are supported (so generic fbdev
emulation can use gem_prime_vmap etc).  Is that correct?

On exporting:

TTM_PL_TT should be easy, just pin the buffer, grab the pages list and
feed that into drm_prime_pages_to_sg.  Didn't try yet though.  Is that
approach correct?

Is it possible to export TTM_PL_VRAM objects (with backing storage being
a pci memory bar)?  If so, how?

On importing:

Importing into TTM_PL_TT object looks easy again, at least when the
object is actually stored in RAM.  What if not?

Importing into TTM_PL_VRAM:  Impossible I think, without copying over
the data.  Should that be done?  If so, how?  Or is it better to just
not support import then?

thanks,
  Gerd

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

[Bug 109246] HDMI connected monitors fail to sleep and instead turn back on when amdgpu.dc=1

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109246

--- Comment #13 from Nicholas Kazlauskas  ---
(In reply to Michel Dänzer from comment #12)
> (In reply to tme from comment #9)
> > Setting amdgpu.dc=1 on 4.15.18 and 4.16.18 does not reproduce the problem.
> > It does, however, reproduce on 4.17.19.
> 
> Can you bisect between 4.16.18 and 4.17.19?
> 
> (I see some HPD filtering related changes between them, Nicholas / Harry
> maybe you can take a look if anything jumps out?)

I haven't had a chance to look into the HPD changes yet, but we haven't seen
this bug occur with our DPMS tests so I'm guessing that it's monitor specific.
A system environment with Ubuntu/Plasma/xf86-video-amdgpu seems pretty standard
at least.

A bisection point on amd-staging-drm-next would certainly help narrow this
down.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v6] drm/panel: Add a driver for the TPO TPG110

[Linus Walleij]

The TPO (Toppoly) TPG110 is a pretty generic display driver
similar in vein to the Ilitek 93xx devices. It is not a panel
per se but a driver used with several low-cost noname panels.

This is used on the Nomadik NHK15 combined with a OSD
OSD057VA01CT display for WVGA 800x480.

The driver is pretty minimalistic right now but can be
extended to handle non-default polarities, gamma correction
etc.

The driver is based on the baked-in code in
drivers/video/fbdev/amba-clcd-nomadik.c which will be
decomissioned once this us upstream.

Acked-by: Sam Ravnborg 
Signed-off-by: Linus Walleij 
---
ChangeLog v5->v6:
- Collected Sam's ACK.
ChangeLog v4->v5:
- Assign proper bus_flags.
- This is now the only remaining patch.
ChangeLog v3->v4:
- Tag on the SPI_3WIRE_HIZ flag to the SPI slave mode.
ChangeLog v2->v3:
- Rewrite as an SPI child device.
---
 MAINTAINERS  |   7 +
 drivers/gpu/drm/panel/Kconfig|  10 +
 drivers/gpu/drm/panel/Makefile   |   1 +
 drivers/gpu/drm/panel/panel-tpo-tpg110.c | 511 +++
 4 files changed, 529 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-tpo-tpg110.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 32d76a90..e177473d5417 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4909,6 +4909,13 @@ DRM DRIVER FOR TDFX VIDEO CARDS
 S: Orphan / Obsolete
 F: drivers/gpu/drm/tdfx/
 
+DRM DRIVER FOR TPO TPG110 PANELS
+M: Linus Walleij 
+T: git git://anongit.freedesktop.org/drm/drm-misc
+S: Maintained
+F: drivers/gpu/drm/panel/panel-tpo-tpg110.c
+F: Documentation/devicetree/bindings/display/panel/tpo,tpg110.txt
+
 DRM DRIVER FOR USB DISPLAYLINK VIDEO ADAPTERS
 M: Dave Airlie 
 R: Sean Paul 
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 3f3537719beb..e3821180b6cd 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -204,6 +204,16 @@ config DRM_PANEL_SITRONIX_ST7789V
  Say Y here if you want to enable support for the Sitronix
  ST7789V controller for 240x320 LCD panels
 
+config DRM_PANEL_TPO_TPG110
+   tristate "TPO TPG 800x400 panel"
+   depends on OF && SPI && GPIOLIB
+   depends on BACKLIGHT_CLASS_DEVICE
+   select VIDEOMODE_HELPERS
+   help
+ Say Y here if you want to enable support for TPO TPG110
+ 400CH LTPS TFT LCD Single Chip Digital Driver for up to
+ 800x400 LCD panels.
+
 config DRM_PANEL_TRULY_NT35597_WQXGA
tristate "Truly WQXGA"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 4396658a7996..cd14ca39c6e0 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -21,4 +21,5 @@ obj-$(CONFIG_DRM_PANEL_SEIKO_43WVF1G) += panel-seiko-43wvf1g.o
 obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
 obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
 obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
+obj-$(CONFIG_DRM_PANEL_TPO_TPG110) += panel-tpo-tpg110.o
 obj-$(CONFIG_DRM_PANEL_TRULY_NT35597_WQXGA) += panel-truly-nt35597.o
diff --git a/drivers/gpu/drm/panel/panel-tpo-tpg110.c 
b/drivers/gpu/drm/panel/panel-tpo-tpg110.c
new file mode 100644
index ..d7c3541fdf28
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-tpo-tpg110.c
@@ -0,0 +1,511 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Panel driver for the TPO TPG110 400CH LTPS TFT LCD Single Chip
+ * Digital Driver.
+ *
+ * This chip drives a TFT LCD, so it does not know what kind of
+ * display is actually connected to it, so the width and height of that
+ * display needs to be supplied from the machine configuration.
+ *
+ * Author:
+ * Linus Walleij 
+ */
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#define TPG110_TEST0x00
+#define TPG110_CHIPID  0x01
+#define TPG110_CTRL1   0x02
+#define TPG110_RES_MASKGENMASK(2, 0)
+#define TPG110_RES_800X480 0x07
+#define TPG110_RES_640X480 0x06
+#define TPG110_RES_480X272 0x05
+#define TPG110_RES_480X640 0x04
+#define TPG110_RES_480X272_D   0x01 /* Dual scan: outputs 800x480 */
+#define TPG110_RES_400X240_D   0x00 /* Dual scan: outputs 800x480 */
+#define TPG110_CTRL2   0x03
+#define TPG110_CTRL2_PMBIT(0)
+#define TPG110_CTRL2_RES_PM_CTRL   BIT(7)
+
+/**
+ * struct tpg110_panel_mode - lookup struct for the supported modes
+ */
+struct tpg110_panel_mode {
+   /**
+* @name: the name of this panel
+*/
+   const char *name;
+   /**
+* @magic: the magic value from the detection register
+*/
+   u32 magic;
+   /**
+* @mode: the DRM display mode for this panel
+*/
+   struct 

[PATCH] drm/meson: Fix atomic mode switching regression

[Neil Armstrong]

Since commit 2bcd3ecab773 when switching mode from X11 (ubuntu mate for
example) the display gets blurry, looking like an invalid framebuffer width.

This commit fixed atomic crtc modesetting but didn't update the display
parameters when changing mode, but only when starting a mode setting after
a crtc disable.

This commit setups the crctc parameter in _begin() and _enable() to
take in account the current ctrc parameters.

Reported-by: Tony McKahan 
Fixes: 2bcd3ecab773 ("drm/meson: Fixes for drm_crtc_vblank_on/off support")
Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/meson/meson_crtc.c | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/meson/meson_crtc.c 
b/drivers/gpu/drm/meson/meson_crtc.c
index 75d97f1b2e8f..5bb432021caf 100644
--- a/drivers/gpu/drm/meson/meson_crtc.c
+++ b/drivers/gpu/drm/meson/meson_crtc.c
@@ -82,14 +82,12 @@ static const struct drm_crtc_funcs meson_crtc_funcs = {
 
 };
 
-static void meson_crtc_enable(struct drm_crtc *crtc)
+static void meson_crtc_setup(struct drm_crtc *crtc)
 {
struct meson_crtc *meson_crtc = to_meson_crtc(crtc);
struct drm_crtc_state *crtc_state = crtc->state;
struct meson_drm *priv = meson_crtc->priv;
 
-   DRM_DEBUG_DRIVER("\n");
-
if (!crtc_state) {
DRM_ERROR("Invalid crtc_state\n");
return;
@@ -98,6 +96,16 @@ static void meson_crtc_enable(struct drm_crtc *crtc)
/* Enable VPP Postblend */
writel(crtc_state->mode.hdisplay,
   priv->io_base + _REG(VPP_POSTBLEND_H_SIZE));
+}
+
+static void meson_crtc_enable(struct drm_crtc *crtc)
+{
+   struct meson_crtc *meson_crtc = to_meson_crtc(crtc);
+   struct meson_drm *priv = meson_crtc->priv;
+
+   DRM_DEBUG_DRIVER("\n");
+
+   meson_crtc_setup(crtc);
 
/* VD1 Preblend vertical start/end */
writel(FIELD_PREP(GENMASK(11, 0), 2303),
@@ -121,6 +129,8 @@ static void meson_crtc_atomic_enable(struct drm_crtc *crtc,
 
if (!meson_crtc->enabled)
meson_crtc_enable(crtc);
+   else
+   meson_crtc_setup(crtc);
 
priv->viu.osd1_enabled = true;
 }
-- 
2.19.2

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

Re: [PATCH v4 8/9] phy: Add Cadence D-PHY support

[Sakari Ailus]

On Wed, Jan 09, 2019 at 10:33:25AM +0100, Maxime Ripard wrote:
> Cadence has designed a D-PHY that can be used by the, currently in tree,
> DSI bridge (DRM), CSI Transceiver and CSI Receiver (v4l2) drivers.
> 
> Only the DSI driver has an ad-hoc driver for that phy at the moment, while
> the v4l2 drivers are completely missing any phy support. In order to make
> that phy support available to all these drivers, without having to
> duplicate that code three times, let's create a generic phy framework
> driver.
> 
> Signed-off-by: Maxime Ripard 

Reviewed-by: Sakari Ailus 

-- 
Sakari Ailus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 7/9] dt-bindings: phy: Move the Cadence D-PHY bindings

[Sakari Ailus]

Hi Maxime,

On Wed, Jan 09, 2019 at 10:33:24AM +0100, Maxime Ripard wrote:
> The Cadence D-PHY bindings was defined as part of the DSI block so far.
> However, since it's now going to be a separate driver, we need to move the
> binding to a file of its own.
> 
> Signed-off-by: Maxime Ripard 

Reviewed-by: Sakari Ailus 

Could you also send this to the devicetree list, please?

> ---
>  Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt | 21 +---
>  Documentation/devicetree/bindings/phy/cdns,dphy.txt   | 20 +++-
>  2 files changed, 20 insertions(+), 21 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/phy/cdns,dphy.txt
> 
> diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt 
> b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt
> index f5725bb6c61c..525a4bfd8634 100644
> --- a/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt
> +++ b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt
> @@ -31,28 +31,7 @@ Required subnodes:
>  - one subnode per DSI device connected on the DSI bus. Each DSI device should
>contain a reg property encoding its virtual channel.
>  
> -Cadence DPHY
> -
> -
> -Cadence DPHY block.
> -
> -Required properties:
> -- compatible: should be set to "cdns,dphy".
> -- reg: physical base address and length of the DPHY registers.
> -- clocks: DPHY reference clocks.
> -- clock-names: must contain "psm" and "pll_ref".
> -- #phy-cells: must be set to 0.
> -
> -
>  Example:
> - dphy0: dphy@fd0e{
> - compatible = "cdns,dphy";
> - reg = <0x0 0xfd0e 0x0 0x1000>;
> - clocks = <_clk>, <_ref_clk>;
> - clock-names = "psm", "pll_ref";
> - #phy-cells = <0>;
> - };
> -
>   dsi0: dsi@fd0c {
>   compatible = "cdns,dsi";
>   reg = <0x0 0xfd0c 0x0 0x1000>;
> diff --git a/Documentation/devicetree/bindings/phy/cdns,dphy.txt 
> b/Documentation/devicetree/bindings/phy/cdns,dphy.txt
> new file mode 100644
> index ..1095bc4e72d9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/cdns,dphy.txt
> @@ -0,0 +1,20 @@
> +Cadence DPHY
> +
> +
> +Cadence DPHY block.
> +
> +Required properties:
> +- compatible: should be set to "cdns,dphy".
> +- reg: physical base address and length of the DPHY registers.
> +- clocks: DPHY reference clocks.
> +- clock-names: must contain "psm" and "pll_ref".
> +- #phy-cells: must be set to 0.
> +
> +Example:
> + dphy0: dphy@fd0e{
> + compatible = "cdns,dphy";
> + reg = <0x0 0xfd0e 0x0 0x1000>;
> + clocks = <_clk>, <_ref_clk>;
> + clock-names = "psm", "pll_ref";
> + #phy-cells = <0>;
> + };
> -- 
> git-series 0.9.1

-- 
Sakari Ailus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 0/9] phy: Add configuration interface for MIPI D-PHY devices

[Sakari Ailus]

On Wed, Jan 09, 2019 at 10:33:17AM +0100, Maxime Ripard wrote:
> Hi,
> 
> Here is a set of patches to allow the phy framework consumers to test and
> apply runtime configurations.
> 
> This is needed to support more phy classes that require tuning based on
> parameters depending on the current use case of the device, in addition to
> the power state management already provided by the current functions.
> 
> A first test bed for that API are the MIPI D-PHY devices. There's a number
> of solutions that have been used so far to support these phy, most of the
> time being an ad-hoc driver in the consumer.
> 
> That approach has a big shortcoming though, which is that this is quite
> difficult to deal with consumers integrated with multiple variants of phy,
> of multiple consumers integrated with the same phy.
> 
> The latter case can be found in the Cadence DSI bridge, and the CSI
> transceiver and receivers. All of them are integrated with the same phy, or
> can be integrated with different phy, depending on the implementation.
> 
> I've looked at all the MIPI DSI drivers I could find, and gathered all the
> parameters I could find. The interface should be complete, and most of the
> drivers can be converted in the future. The current set converts two of
> them: the above mentionned Cadence DSI driver so that the v4l2 drivers can
> use them, and the Allwinner MIPI-DSI driver.
> 
> Let me know what you think,
> Maxime
> 
> Changes from v3
>   - Rebased on 5.0-rc1
>   - Added the fixes suggested by Sakari

Thanks!

For patches 1--3:

Acked-by: Sakari Ailus 

-- 
Sakari Ailus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [v6 1/2] drm: Add colorspace connector property

[Shankar, Uma]

>-Original Message-
>From: Brian Starkey [mailto:brian.star...@arm.com]
>Sent: Tuesday, January 8, 2019 7:43 PM
>To: Shankar, Uma 
>Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; 
>Lankhorst,
>Maarten ; Syrjala, Ville 
>;
>Sharma, Shashank ; nd 
>Subject: Re: [v6 1/2] drm: Add colorspace connector property
>
>Hi Uma,
>
>On Thu, Dec 27, 2018 at 11:22:37PM +0530, Uma Shankar wrote:
>> This patch adds a colorspace connector property, enabling userspace to
>> switch to various supported colorspaces.
>> This will help enable BT2020 along with other colorspaces.
>>
>> v2: Addressed Maarten and Ville's review comments. Enhanced the
>> colorspace enum to incorporate both HDMI and DP supported colorspaces.
>> Also, added a default option for colorspace.
>>
>> v3: Removed Adobe references from enum definitions as per Ville, Hans
>> Verkuil and Jonas Karlman suggestions. Changed Default to an unset
>> state where driver will assign the colorspace is not chosen by user,
>> suggested by Ville and Maarten. Addressed other misc review comments
>> from Maarten. Split the changes to have separate colorspace property
>> for DP and HDMI.
>>
>> v4: Addressed Chris and Ville's review comments, and created a common
>> colorspace property for DP and HDMI, filtered the list based on the
>> colorspaces supported by the respective protocol standard.
>>
>> v5: Made the property creation helper accept enum list based on
>> platform capabilties as suggested by Shashank. Consolidated HDMI and
>> DP property creation in the common helper.
>>
>> v6: Addressed Shashank's review comments.
>>
>> Signed-off-by: Uma Shankar 
>> Reviewed-by: Shashank Sharma 
>> ---
>>  drivers/gpu/drm/drm_atomic_uapi.c |  4 ++
>>  drivers/gpu/drm/drm_connector.c   | 79
>+++
>>  include/drm/drm_connector.h   | 17 +
>>  include/uapi/drm/drm_mode.h   | 33 
>>  4 files changed, 133 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
>> b/drivers/gpu/drm/drm_atomic_uapi.c
>> index c408898..5e03292 100644
>> --- a/drivers/gpu/drm/drm_atomic_uapi.c
>> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
>> @@ -746,6 +746,8 @@ static int drm_atomic_connector_set_property(struct
>drm_connector *connector,
>>  return -EINVAL;
>>  }
>>  state->content_protection = val;
>> +} else if (property == connector->colorspace_property) {
>> +state->colorspace = val;
>>  } else if (property == config->writeback_fb_id_property) {
>>  struct drm_framebuffer *fb = drm_framebuffer_lookup(dev,
>NULL, val);
>>  int ret = drm_atomic_set_writeback_fb_for_connector(state,
>fb); @@
>> -814,6 +816,8 @@ static int drm_atomic_connector_set_property(struct
>drm_connector *connector,
>>  *val = state->picture_aspect_ratio;
>>  } else if (property == config->content_type_property) {
>>  *val = state->content_type;
>> +} else if (property == connector->colorspace_property) {
>> +*val = state->colorspace;
>>  } else if (property == connector->scaling_mode_property) {
>>  *val = state->scaling_mode;
>>  } else if (property == connector->content_protection_property) {
>> diff --git a/drivers/gpu/drm/drm_connector.c
>> b/drivers/gpu/drm/drm_connector.c index 8475396..ad1b862 100644
>> --- a/drivers/gpu/drm/drm_connector.c
>> +++ b/drivers/gpu/drm/drm_connector.c
>> @@ -826,6 +826,54 @@ int drm_display_info_set_bus_formats(struct
>> drm_display_info *info,  };
>> DRM_ENUM_NAME_FN(drm_get_content_protection_name,
>drm_cp_enum_list)
>>
>> +/* List of HDMI Colorspaces supported */ static const struct
>> +drm_prop_enum_list hdmi_colorspaces[] = {
>> +/* For Default case, driver will set the colorspace */
>> +{ COLORIMETRY_DEFAULT, "Default" },
>> +/* Standard Definition Colorimetry based on CEA 861 */
>> +{ COLORIMETRY_ITU_601, "ITU_601" },
>> +{ COLORIMETRY_ITU_709, "ITU_709" },
>> +/* Standard Definition Colorimetry based on IEC 61966-2-4 */
>> +{ COLORIMETRY_XV_YCC_601, "XV_YCC_601" },
>> +/* High Definition Colorimetry based on IEC 61966-2-4 */
>> +{ COLORIMETRY_XV_YCC_709, "XV_YCC_709" },
>> +/* Colorimetry based on IEC 61966-2-1/Amendment 1 */
>> +{ COLORIMETRY_S_YCC_601, "S_YCC_601" },
>> +/* Colorimetry based on IEC 61966-2-5 [33] */
>> +{ COLORIMETRY_OPYCC_601, "opYCC_601" },
>> +/* Colorimetry based on IEC 61966-2-5 */
>> +{ COLORIMETRY_OPRGB, "opRGB" },
>> +/* Colorimetry based on ITU-R BT.2020 */
>> +{ COLORIMETRY_BT2020_RGB, "BT2020_RGB" },
>> +/* Colorimetry based on ITU-R BT.2020 */
>> +{ COLORIMETRY_BT2020_YCC, "BT2020_YCC" },
>> +/* Colorimetry based on ITU-R BT.2020 */
>> +{ COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" }, };
>> +
>> +/* List of DP Colorspaces supported */ static const struct
>> +drm_prop_enum_list dp_colorspaces[] = {
>> +/* For Default 

RE: [v6 0/2] Add Colorspace connector property interface

[Shankar, Uma]

>-Original Message-
>From: Brian Starkey [mailto:brian.star...@arm.com]
>Sent: Tuesday, January 8, 2019 7:37 PM
>To: Shankar, Uma 
>Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; 
>Lankhorst,
>Maarten ; Syrjala, Ville 
>;
>Sharma, Shashank ; nd 
>Subject: Re: [v6 0/2] Add Colorspace connector property interface
>
>Hi Uma,
>
>On Thu, Dec 27, 2018 at 11:22:36PM +0530, Uma Shankar wrote:
>> This patch series creates a new connector property to program
>> colorspace to sink devices. Modern sink devices support more than 1
>> type of colorspace like 601, 709, BT2020 etc. This helps to switch
>> based on content type which is to be displayed. The decision lies with
>> compositors as to in which scenarios, a particular colorspace will be
>> picked.
>>
>> This will be helpful mostly to switch to higher gamut colorspaces like
>> BT2020 when the media content is encoded as BT2020. Thereby giving a
>> good visual experience to users.
>>
>> The expectation from userspace is that it should parse the EDID and
>> get supported colorspaces. Use this property and switch to the one
>> supported. Kernel will not give the supported colorspaces since this
>> is panel dependent and our current property infrastructure is not
>> supporting it.
>>
>> Basically the expectation from userspace is:
>>  - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink
>>colorspace
>>  - Set this new property to let the sink know what it
>>converted the CRTC output to.
>>  - This property is just to inform sink what colorspace
>>source is trying to drive.
>
>All the above info is really important/useful stuff, but it's going to get lost
>because it's only in the cover letter. This should either find its way into the
>commit message of patch 1 or even better, into the kerneldoc for the property.

Sure Brian, Will add it to kernel doc as well to commit message so that it's 
not lost.

Regards,
Uma Shankar

>Cheers,
>-Brian
>
>>
>> Have tested this using xrandr by using below command:
>> xrandr --output HDMI2 --set "Colorspace" "BT2020_rgb"
>>
>> v2: Addressed Ville and Maarten's review comments. Merged the 2nd and
>> 3rd patch into one common logical patch.
>>
>> v3: Removed Adobe references from enum definitions as per Ville, Hans
>> Verkuil and Jonas Karlman suggestions. Changed default to an unset
>> state where driver will assign the colorspace when not chosen by user,
>> suggested by Ville and Maarten. Addressed other misc review comments
>> from Maarten. Split the changes to have separate colorspace property
>> for DP and HDMI.
>>
>> v4: Addressed Chris and Ville's review comments, and created a common
>> colorspace property for DP and HDMI, filtered the list based on the
>> colorspaces supported by the respective protocol standard. Handled the
>> default case more efficiently.
>>
>> v5: Modified the colorspace property creation helper to take platform
>> specific enum list based on the capabilities of the platform as
>> suggested by Shashank. With this there is no need for segregation
>> between DP and HDMI.
>>
>> v6: Addressed Shashank's review comments.
>>
>> Uma Shankar (2):
>>   drm: Add colorspace connector property
>>   drm/i915: Attach colorspace property and enable modeset
>>
>>  drivers/gpu/drm/drm_atomic_uapi.c  |  4 ++
>>  drivers/gpu/drm/drm_connector.c| 82
>++
>>  drivers/gpu/drm/i915/intel_atomic.c|  1 +
>>  drivers/gpu/drm/i915/intel_connector.c | 63 ++
>>  drivers/gpu/drm/i915/intel_drv.h   |  1 +
>>  drivers/gpu/drm/i915/intel_hdmi.c  | 18 
>>  include/drm/drm_connector.h| 17 +++
>>  include/uapi/drm/drm_mode.h| 33 ++
>>  8 files changed, 219 insertions(+)
>>
>> --
>> 1.9.1
>>
>> Uma Shankar (2):
>>   drm: Add colorspace connector property
>>   drm/i915: Attach colorspace property and enable modeset
>>
>>  drivers/gpu/drm/drm_atomic_uapi.c  |  4 ++
>>  drivers/gpu/drm/drm_connector.c| 79
>++
>>  drivers/gpu/drm/i915/intel_atomic.c|  1 +
>>  drivers/gpu/drm/i915/intel_connector.c | 63 +++
>>  drivers/gpu/drm/i915/intel_drv.h   |  1 +
>>  drivers/gpu/drm/i915/intel_hdmi.c  | 19 
>>  include/drm/drm_connector.h| 17 
>>  include/uapi/drm/drm_mode.h| 33 ++
>>  8 files changed, 217 insertions(+)
>>
>> --
>> 1.9.1
>>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [v4 10/12] drm/i915: Add HLG EOTF

[Shankar, Uma]

>-Original Message-
>From: Roper, Matthew D
>Sent: Wednesday, January 9, 2019 1:15 AM
>To: Shankar, Uma 
>Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Syrjala, 
>Ville
>; emil.l.veli...@gmail.com; Lankhorst, Maarten
>
>Subject: Re: [v4 10/12] drm/i915: Add HLG EOTF
>
>On Tue, Jan 08, 2019 at 02:41:25PM +0530, Uma Shankar wrote:
>> From: Ville Syrjälä 
>>
>> ADD HLG EOTF to the list of EOTF transfer functions supported.
>> Hybrid Log-Gamma (HLG) is a high dynamic range (HDR) standard.
>> HLG defines a nonlinear transfer function in which the lower half of
>> the signal values use a gamma curve and the upper half of the signal
>> values use a logarithmic curve.
>>
>> v2: Rebase
>>
>> v3: Fixed a warning message
>>
>> v4: Addressed Shashank's review comments
>>
>> Signed-off-by: Ville Syrjälä 
>> Signed-off-by: Uma Shankar 
>> ---
>>  drivers/gpu/drm/drm_edid.c | 4 ++--
>>  include/linux/hdmi.h   | 1 +
>>  2 files changed, 3 insertions(+), 2 deletions(-)
>
>I haven't really looked at this series in depth, but just a quick drive-by 
>comment:
>it doesn't look like this patch touches i915, so the "drm/i915:" headline 
>prefix
>should probably just be "drm:" and you might want to move it earlier in the 
>series
>so that all the core patches come before all the i915 patches.

Sure Matt, will update this as part of next version.

Regards,
Uma Shankar

>
>Matt
>
>>
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> index df27012..5592c9b 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -3850,8 +3850,8 @@ static uint8_t eotf_supported(const u8 *edid_ext)
>>  return edid_ext[2] &
>>  (BIT(HDMI_EOTF_TRADITIONAL_GAMMA_SDR) |
>>   BIT(HDMI_EOTF_TRADITIONAL_GAMMA_HDR) |
>> - BIT(HDMI_EOTF_SMPTE_ST2084));
>> -
>> + BIT(HDMI_EOTF_SMPTE_ST2084) |
>> + BIT(HDMI_EOTF_BT_2100_HLG));
>>  }
>>
>>  static uint8_t hdr_metadata_type(const u8 *edid_ext) diff --git
>> a/include/linux/hdmi.h b/include/linux/hdmi.h index ce00e1e..b5346c3
>> 100644
>> --- a/include/linux/hdmi.h
>> +++ b/include/linux/hdmi.h
>> @@ -146,6 +146,7 @@ enum hdmi_eotf {
>>  HDMI_EOTF_TRADITIONAL_GAMMA_SDR,
>>  HDMI_EOTF_TRADITIONAL_GAMMA_HDR,
>>  HDMI_EOTF_SMPTE_ST2084,
>> +HDMI_EOTF_BT_2100_HLG,
>>  };
>>
>>  struct hdmi_avi_infoframe {
>> --
>> 1.9.1
>>
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>--
>Matt Roper
>Graphics Software Engineer
>IoTG Platform Enabling & Development
>Intel Corporation
>(916) 356-2795
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/atmel-hlcdc: prevent divide by zero

[Boris Brezillon]

On Wed, 9 Jan 2019 11:37:19 +
Peter Rosin  wrote:

> On 2019-01-09 11:12, Daniel Vetter wrote:
> > On Tue, Jan 08, 2019 at 12:31:36PM +, Peter Rosin wrote:  
> >> While trying to temporarily hide a plane, one thing that was attempted
> >> was to call (from libdrm)
> >>
> >>drmModeSetPlane(fd, plane_id, crtc_id, fb_id, 0,
> >>0, 0, 0, 0, 0, 0, 0, 0);
> >>
> >> This call causes a pair of "Division by zero in kernel." messages. Kill
> >> those messages, but preserve the current behaviour that also happen to
> >> make the plane disappear with the above call.
> >>
> >> Signed-off-by: Peter Rosin 
> >> ---
> >>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 14 ++
> >>  1 file changed, 10 insertions(+), 4 deletions(-)
> >>
> >> Side note, when comparing with drm_atomic_helper_check_plane_state(), I get
> >> the feeling that the src rect should be clipped together with the crtc rect
> >> if/when clipping is needed. That function calls drm_rect_clip_scaled(), and
> >> the equivalent does not seem to happen here. Should clipping be performed
> >> on the src rect?  
> > 
> > Any reasons atmel can't switch over to that helper? Would compute a nice  
> > ->visible state variable for you ...  
> > -Daniel  
> 
> I have not researched that, and as stated above, I was not sure if that was 
> the
> correct approach to begin with. Boris, any insights?

You can look at vc4_plane.c if you want an example of how this helper
can be used to get clipped dimensions of the plane.

> Does this code predate the
> helper or something?

Yes, and I must admit I'm not actively maintaining the driver, so there
are probably a few other things we could simplify by using generic
helpers.

> 
> Maybe there's some register bit that hides a plane explicitly, matching the
> ->visible state variable? I haven't looked at that either...

I don't think so, but you can simply disable the plane when ->visible
is false.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/atmel-hlcdc: prevent divide by zero

[Boris Brezillon]

On Wed, 9 Jan 2019 11:12:24 +0100
Daniel Vetter  wrote:

> On Tue, Jan 08, 2019 at 12:31:36PM +, Peter Rosin wrote:
> > While trying to temporarily hide a plane, one thing that was attempted
> > was to call (from libdrm)
> > 
> > drmModeSetPlane(fd, plane_id, crtc_id, fb_id, 0,
> > 0, 0, 0, 0, 0, 0, 0, 0);
> > 
> > This call causes a pair of "Division by zero in kernel." messages. Kill
> > those messages, but preserve the current behaviour that also happen to
> > make the plane disappear with the above call.
> > 
> > Signed-off-by: Peter Rosin 
> > ---
> >  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 14 ++
> >  1 file changed, 10 insertions(+), 4 deletions(-)
> > 
> > Side note, when comparing with drm_atomic_helper_check_plane_state(), I get
> > the feeling that the src rect should be clipped together with the crtc rect
> > if/when clipping is needed. That function calls drm_rect_clip_scaled(), and
> > the equivalent does not seem to happen here. Should clipping be performed
> > on the src rect?  
> 
> Any reasons atmel can't switch over to that helper? Would compute a nice
> ->visible state variable for you ...  

We should definitely use drm_atomic_helper_check_plane_state().
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6 02/12] gpu: ipu-csi: Swap fields according to input/output field types

[Philipp Zabel]

On Tue, 2019-01-08 at 16:15 -0800, Steve Longerbeam wrote:
> The function ipu_csi_init_interface() was inverting the F-bit for
> NTSC case, in the CCIR_CODE_1/2 registers. The result being that
> for NTSC bottom-top field order, the CSI would swap fields and
> capture in top-bottom order.
> 
> Instead, base field swap on the field order of the input to the CSI,
> and the field order of the requested output. If the input/output
> fields are sequential but different, swap fields, otherwise do
> not swap. This requires passing both the input and output mbus
> frame formats to ipu_csi_init_interface().
> 
> Move this code to a new private function ipu_csi_set_bt_interlaced_codes()
> that programs the CCIR_CODE_1/2 registers for interlaced BT.656 (and
> possibly interlaced BT.1120 in the future).
> 
> When detecting input video standard from the input frame width/height,
> make sure to double height if input field type is alternate, since
> in that case input height only includes lines for one field.
> 
> Signed-off-by: Steve Longerbeam 
> Reviewed-by: Philipp Zabel 

Also
Acked-by: Philipp Zabel 
to be merged via the media tree

regards
Philipp
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 1/2] drm/sched: Refactor ring mirror list handling.

[Christian König]

Am 07.01.19 um 20:47 schrieb Grodzovsky, Andrey:


On 01/07/2019 09:13 AM, Christian König wrote:

Am 03.01.19 um 18:42 schrieb Grodzovsky, Andrey:

On 01/03/2019 11:20 AM, Grodzovsky, Andrey wrote:

On 01/03/2019 03:54 AM, Koenig, Christian wrote:

Am 21.12.18 um 21:36 schrieb Grodzovsky, Andrey:

On 12/21/2018 01:37 PM, Christian König wrote:

Am 20.12.18 um 20:23 schrieb Andrey Grodzovsky:

Decauple sched threads stop and start and ring mirror
list handling from the policy of what to do about the
guilty jobs.
When stoppping the sched thread and detaching sched fences
from non signaled HW fenes wait for all signaled HW fences
to complete before rerunning the jobs.

v2: Fix resubmission of guilty job into HW after refactoring.

v4:
Full restart for all the jobs, not only from guilty ring.
Extract karma increase into standalone function.

v5:
Rework waiting for signaled jobs without relying on the job
struct itself as those might already be freed for non 'guilty'
job's schedulers.
Expose karma increase to drivers.

Suggested-by: Christian Koenig 
Signed-off-by: Andrey Grodzovsky 
---
       drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  18 +--
       drivers/gpu/drm/etnaviv/etnaviv_sched.c    |  11 +-
       drivers/gpu/drm/scheduler/sched_main.c | 188
+++--
       drivers/gpu/drm/v3d/v3d_sched.c    |  12 +-
       include/drm/gpu_scheduler.h    |  10 +-
       5 files changed, 151 insertions(+), 88 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 8a078f4..a4bd2d3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3298,12 +3298,10 @@ static int
amdgpu_device_pre_asic_reset(struct amdgpu_device *adev,
       if (!ring || !ring->sched.thread)
       continue;
       -    kthread_park(ring->sched.thread);
+    drm_sched_stop(>sched, job ? >base : NULL);
       -    if (job && job->base.sched != >sched)
-    continue;
-
-    drm_sched_hw_job_reset(>sched, job ? >base :
NULL);
+    if(job)
+ drm_sched_increase_karma(>base);

Since we dropped the "job && job->base.sched != >sched" check
above this will now increase the jobs karma multiple times.

Maybe just move that outside of the loop.


         /* after all hw jobs are reset, hw fence is
meaningless,
so force_completion */
amdgpu_fence_driver_force_completion(ring);
@@ -3454,14 +3452,10 @@ static void
amdgpu_device_post_asic_reset(struct amdgpu_device *adev,
       if (!ring || !ring->sched.thread)
       continue;
       -    /* only need recovery sched of the given job's ring
- * or all rings (in the case @job is NULL)
- * after above amdgpu_reset accomplished
- */
-    if ((!job || job->base.sched == >sched) &&
!adev->asic_reset_res)
- drm_sched_job_recovery(>sched);
+    if (!adev->asic_reset_res)
+ drm_sched_resubmit_jobs(>sched);
       -    kthread_unpark(ring->sched.thread);
+    drm_sched_start(>sched, !adev->asic_reset_res);
       }
         if (!amdgpu_device_has_dc_support(adev)) {
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
index 49a6763..6f1268f 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
@@ -109,16 +109,19 @@ static void etnaviv_sched_timedout_job(struct
drm_sched_job *sched_job)
       }
         /* block scheduler */
-    kthread_park(gpu->sched.thread);
-    drm_sched_hw_job_reset(>sched, sched_job);
+    drm_sched_stop(>sched, sched_job);
+
+    if(sched_job)
+    drm_sched_increase_karma(sched_job);
         /* get the GPU back into the init state */
       etnaviv_core_dump(gpu);
       etnaviv_gpu_recover_hang(gpu);
       + drm_sched_resubmit_jobs(>sched);
+
       /* restart scheduler after GPU is usable again */
-    drm_sched_job_recovery(>sched);
-    kthread_unpark(gpu->sched.thread);
+    drm_sched_start(>sched, true);
       }
         static void etnaviv_sched_free_job(struct drm_sched_job
*sched_job)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index dbb6906..b5c5bee 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -60,8 +60,6 @@
         static void drm_sched_process_job(struct dma_fence *f,
struct
dma_fence_cb *cb);
       -static void drm_sched_expel_job_unlocked(struct
drm_sched_job
*s_job);
-
       /**
        * drm_sched_rq_init - initialize a given run queue struct
        *
@@ -335,6 +333,42 @@ static void drm_sched_job_timedout(struct
work_struct *work)
spin_unlock_irqrestore(>job_list_lock, flags);
       }

Kernel doc here would be nice to have.


+void drm_sched_increase_karma(struct drm_sched_job *bad)
+{
+    int i;
+    struct drm_sched_entity *tmp;
+    struct drm_sched_entity 

Re: [PATCH] drm/atmel-hlcdc: prevent divide by zero

[Daniel Vetter]

On Tue, Jan 08, 2019 at 12:31:36PM +, Peter Rosin wrote:
> While trying to temporarily hide a plane, one thing that was attempted
> was to call (from libdrm)
> 
>   drmModeSetPlane(fd, plane_id, crtc_id, fb_id, 0,
>   0, 0, 0, 0, 0, 0, 0, 0);
> 
> This call causes a pair of "Division by zero in kernel." messages. Kill
> those messages, but preserve the current behaviour that also happen to
> make the plane disappear with the above call.
> 
> Signed-off-by: Peter Rosin 
> ---
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 14 ++
>  1 file changed, 10 insertions(+), 4 deletions(-)
> 
> Side note, when comparing with drm_atomic_helper_check_plane_state(), I get
> the feeling that the src rect should be clipped together with the crtc rect
> if/when clipping is needed. That function calls drm_rect_clip_scaled(), and
> the equivalent does not seem to happen here. Should clipping be performed
> on the src rect?

Any reasons atmel can't switch over to that helper? Would compute a nice
->visible state variable for you ...
-Daniel

> 
> Cheers,
> Peter
> 
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c 
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> index 3cc489b870fe..1bdb30dc218c 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> @@ -675,10 +675,16 @@ static int atmel_hlcdc_plane_atomic_check(struct 
> drm_plane *p,
>   state->crtc_y = 0;
>   }
>  
> - patched_src_w = DIV_ROUND_CLOSEST(patched_crtc_w * state->src_w,
> -   state->crtc_w);
> - patched_src_h = DIV_ROUND_CLOSEST(patched_crtc_h * state->src_h,
> -   state->crtc_h);
> + if (state->crtc_w)
> + patched_src_w = DIV_ROUND_CLOSEST(patched_crtc_w * state->src_w,
> +   state->crtc_w);
> + else
> + patched_src_w = 0;
> + if (state->crtc_h)
> + patched_src_h = DIV_ROUND_CLOSEST(patched_crtc_h * state->src_h,
> +   state->crtc_h);
> + else
> + patched_src_h = 0;
>  
>   hsub = drm_format_horz_chroma_subsampling(fb->format->format);
>   vsub = drm_format_vert_chroma_subsampling(fb->format->format);
> -- 
> 2.11.0
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCHv2 0/7] drm/bridge: tc358767: small fixes

[Andrzej Hajda]

On 09.01.2019 10:51, Lucas Stach wrote:
> Am Mittwoch, den 09.01.2019, 11:12 +0200 schrieb Tomi Valkeinen:
>> Hi Andrzej,
>>
>> On 09/01/19 10:22, Andrzej Hajda wrote:
>>> Hi Tomi,
>>>
>>> On 03.01.2019 12:59, Tomi Valkeinen wrote:
 Hi,

 We have TC358867 on our board, which I believe is almost identical to
 TC358767. We're using it with a DP connector instead of eDP with a fixed
 panel.

 I have tested these patches only on TI's 4.14 based kernel, as
 unfortunately we don't have all the necessary support in mainline yet.
 These patches fix various bugs, but I'm still seeing at least two
 issues:

 * Sync with some videomodes is not correct, resulting in a jumping and
   skewed display
 * Link training fails sometimes

 I would appreciate if someone is able to verify these patches with
 TC358767.
>>>
>>> Do you want to wait for testers or shall I queue this patchset?
>> I haven't heard from anyone, so I'm ok with pushing these.
> For the series:
>
> Tested-by: Lucas Stach 
>
> on a device with TC358767 and a 4.20 based kernel.


Already queued :)


Regards

Andrzej


>
> Regards,
> Lucas
>
>
>
>

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

Re: [PATCH v2 15/15] drm/bochs: reserve bo for pin/unpin

[Daniel Vetter]

On Tue, Jan 08, 2019 at 12:25:19PM +0100, Gerd Hoffmann wrote:
> The buffer object must be reserved before calling
> ttm_bo_validate for pinning/unpinning.
> 
> Signed-off-by: Gerd Hoffmann 

Seems a bit a bisect fumble in your series here: legacy kms code reserved
the ttm bo before calling boch_bo_pin/unpin, your atomic code doesn't. I
think pushing this into bochs_bo_pin/unpin makes sense for atomic, but to
avoid bisect fail I think you need to have these temporarily in your
cleanup/prepare_plane functions too.

Looked through the entire series, this here is the only issue I think
should be fixed before merging (making atomic_enable optional can be done
as a follow-up if you feel like it). With that addressed on the series:

Acked-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/bochs/bochs_mm.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/bochs/bochs_mm.c 
> b/drivers/gpu/drm/bochs/bochs_mm.c
> index cfe061c25f..970a591908 100644
> --- a/drivers/gpu/drm/bochs/bochs_mm.c
> +++ b/drivers/gpu/drm/bochs/bochs_mm.c
> @@ -223,7 +223,11 @@ int bochs_bo_pin(struct bochs_bo *bo, u32 pl_flag)
>   bochs_ttm_placement(bo, pl_flag);
>   for (i = 0; i < bo->placement.num_placement; i++)
>   bo->placements[i].flags |= TTM_PL_FLAG_NO_EVICT;
> + ret = ttm_bo_reserve(>bo, true, false, NULL);
> + if (ret)
> + return ret;
>   ret = ttm_bo_validate(>bo, >placement, );
> + ttm_bo_unreserve(>bo);
>   if (ret)
>   return ret;
>  
> @@ -247,7 +251,11 @@ int bochs_bo_unpin(struct bochs_bo *bo)
>  
>   for (i = 0; i < bo->placement.num_placement; i++)
>   bo->placements[i].flags &= ~TTM_PL_FLAG_NO_EVICT;
> + ret = ttm_bo_reserve(>bo, true, false, NULL);
> + if (ret)
> + return ret;
>   ret = ttm_bo_validate(>bo, >placement, );
> + ttm_bo_unreserve(>bo);
>   if (ret)
>   return ret;
>  
> -- 
> 2.9.3
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 03/15] drm/bochs: atomic: add atomic_flush+atomic_enable callbacks.

[Daniel Vetter]

On Tue, Jan 08, 2019 at 12:25:07PM +0100, Gerd Hoffmann wrote:
> Conversion to atomic modesetting, step one.
> Add atomic crtc helper callbacks.
> 
> Signed-off-by: Gerd Hoffmann 
> ---
>  drivers/gpu/drm/bochs/bochs_kms.c | 25 +
>  1 file changed, 25 insertions(+)
> 
> diff --git a/drivers/gpu/drm/bochs/bochs_kms.c 
> b/drivers/gpu/drm/bochs/bochs_kms.c
> index f7e6d1a9b3..2cbd406b1f 100644
> --- a/drivers/gpu/drm/bochs/bochs_kms.c
> +++ b/drivers/gpu/drm/bochs/bochs_kms.c
> @@ -115,6 +115,29 @@ static int bochs_crtc_page_flip(struct drm_crtc *crtc,
>   return 0;
>  }
>  
> +static void bochs_crtc_atomic_enable(struct drm_crtc *crtc,
> +  struct drm_crtc_state *old_crtc_state)
> +{
> +}

A patch to make this optional in the helpers would be neat.
-Daniel

> +
> +static void bochs_crtc_atomic_flush(struct drm_crtc *crtc,
> + struct drm_crtc_state *old_crtc_state)
> +{
> + struct drm_device *dev = crtc->dev;
> + struct drm_pending_vblank_event *event;
> +
> + if (crtc->state && crtc->state->event) {
> + unsigned long irqflags;
> +
> + spin_lock_irqsave(>event_lock, irqflags);
> + event = crtc->state->event;
> + crtc->state->event = NULL;
> + drm_crtc_send_vblank_event(crtc, event);
> + spin_unlock_irqrestore(>event_lock, irqflags);
> + }
> +}
> +
> +
>  /* These provide the minimum set of functions required to handle a CRTC */
>  static const struct drm_crtc_funcs bochs_crtc_funcs = {
>   .set_config = drm_crtc_helper_set_config,
> @@ -128,6 +151,8 @@ static const struct drm_crtc_helper_funcs 
> bochs_helper_funcs = {
>   .mode_set_base = bochs_crtc_mode_set_base,
>   .prepare = bochs_crtc_prepare,
>   .commit = bochs_crtc_commit,
> + .atomic_enable = bochs_crtc_atomic_enable,
> + .atomic_flush = bochs_crtc_atomic_flush,
>  };
>  
>  static const uint32_t bochs_formats[] = {
> -- 
> 2.9.3
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCHv2 0/7] drm/bridge: tc358767: small fixes

[Lucas Stach]

Am Mittwoch, den 09.01.2019, 11:12 +0200 schrieb Tomi Valkeinen:
> Hi Andrzej,
> 
> On 09/01/19 10:22, Andrzej Hajda wrote:
> > Hi Tomi,
> > 
> > On 03.01.2019 12:59, Tomi Valkeinen wrote:
> > > Hi,
> > > 
> > > We have TC358867 on our board, which I believe is almost identical to
> > > TC358767. We're using it with a DP connector instead of eDP with a fixed
> > > panel.
> > > 
> > > I have tested these patches only on TI's 4.14 based kernel, as
> > > unfortunately we don't have all the necessary support in mainline yet.
> > > These patches fix various bugs, but I'm still seeing at least two
> > > issues:
> > > 
> > > * Sync with some videomodes is not correct, resulting in a jumping and
> > >   skewed display
> > > * Link training fails sometimes
> > > 
> > > I would appreciate if someone is able to verify these patches with
> > > TC358767.
> > 
> > 
> > Do you want to wait for testers or shall I queue this patchset?
> 
> I haven't heard from anyone, so I'm ok with pushing these.

For the series:

Tested-by: Lucas Stach 

on a device with TC358767 and a 4.20 based kernel.

Regards,
Lucas


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

Re: [PATCH v3 10/12] drm/stm: do not reply on drmP.h from drm_gem_cma_helper.h

[Sam Ravnborg]

Hi Benjamin.

On Wed, Jan 09, 2019 at 09:21:39AM +0100, Benjamin Gaignard wrote:
> Le mar. 8 janv. 2019 à 20:30, Sam Ravnborg  a écrit :
> I just notice the a typo in the title of the commit message reply ->rely ?
Randy already told me this, but I missed that in the update.

Will fix in v4 if this set do not get applied.

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

Re: [PATCH] Build etnaviv on non-ARM architectures

[Lucas Stach]

Am Dienstag, den 08.01.2019, 12:43 -0800 schrieb Matthew Wilcox:
> I wanted to test-compile etnaviv on x86 after making a tree-wide change
> to it.  Unfortunately, Kconfig has a bad dependency, so I couldn't.
> 
> Signed-off-by: Matthew Wilcox 

I think we even want to relax this some more in the future, as Vivante
GPUs are also found on non ARM SoCs, but that needs some more testing
so I applied this patch to etnaviv/next as it's certainly the right
thing to do.

Regards,
Lucas

> 
> diff --git a/drivers/gpu/drm/etnaviv/Kconfig b/drivers/gpu/drm/etnaviv/Kconfig
> index 041a77e400d4..342591a1084e 100644
> --- a/drivers/gpu/drm/etnaviv/Kconfig
> +++ b/drivers/gpu/drm/etnaviv/Kconfig
> @@ -2,7 +2,7 @@
>  config DRM_ETNAVIV
> >     tristate "ETNAVIV (DRM support for Vivante GPU IP cores)"
> >     depends on DRM
> > -   depends on ARCH_MXC || ARCH_DOVE || (ARM && COMPILE_TEST)
> > +   depends on ARCH_MXC || ARCH_DOVE || ARM || COMPILE_TEST
> >     depends on MMU
> >     select SHMEM
> >     select SYNC_FILE
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] etnaviv mailing list is moderated

[Lucas Stach]

Am Dienstag, den 08.01.2019, 12:50 -0800 schrieb Matthew Wilcox:
> > Signed-off-by: Matthew Wilcox 

Thanks, applied to etnaviv/next.

Regards,
Lucas

> diff --git a/MAINTAINERS b/MAINTAINERS
> index 32d76a90..44888eb121d8 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5141,7 +5141,7 @@ DRM DRIVERS FOR VIVANTE GPU IP
> > >  M:   Lucas Stach 
> > >  R:   Russell King 
> > >  R:   Christian Gmeiner 
> -L:   etna...@lists.freedesktop.org
> > +L: etna...@lists.freedesktop.org (moderated for non-subscribers)
>  L:   dri-devel@lists.freedesktop.org
> >  S: Maintained
> >  F: drivers/gpu/drm/etnaviv/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 5/9] phy: Move Allwinner A31 D-PHY driver to drivers/phy/

[Maxime Ripard]

Now that our MIPI D-PHY driver has been converted to the phy framework,
let's move it into the drivers/phy directory.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/sun4i/Kconfig   |  10 +-
 drivers/gpu/drm/sun4i/Makefile  |   1 +-
 drivers/gpu/drm/sun4i/sun6i_mipi_dphy.c | 318 +-
 drivers/phy/allwinner/Kconfig   |  12 +-
 drivers/phy/allwinner/Makefile  |   1 +-
 drivers/phy/allwinner/phy-sun6i-mipi-dphy.c | 318 +-
 6 files changed, 332 insertions(+), 328 deletions(-)
 delete mode 100644 drivers/gpu/drm/sun4i/sun6i_mipi_dphy.c
 create mode 100644 drivers/phy/allwinner/phy-sun6i-mipi-dphy.c

diff --git a/drivers/gpu/drm/sun4i/Kconfig b/drivers/gpu/drm/sun4i/Kconfig
index 2b8db82c4bab..1dbbc3a1b763 100644
--- a/drivers/gpu/drm/sun4i/Kconfig
+++ b/drivers/gpu/drm/sun4i/Kconfig
@@ -45,20 +45,12 @@ config DRM_SUN6I_DSI
default MACH_SUN8I
select CRC_CCITT
select DRM_MIPI_DSI
-   select DRM_SUN6I_DPHY
+   select PHY_SUN6I_MIPI_DPHY
help
  Choose this option if you want have an Allwinner SoC with
  MIPI-DSI support. If M is selected the module will be called
  sun6i_mipi_dsi.
 
-config DRM_SUN6I_DPHY
-   tristate "Allwinner A31 MIPI D-PHY Support"
-   select GENERIC_PHY_MIPI_DPHY
-   help
- Choose this option if you have an Allwinner SoC with
- MIPI-DSI support. If M is selected, the module will be
- called sun6i_mipi_dphy.
-
 config DRM_SUN8I_DW_HDMI
tristate "Support for Allwinner version of DesignWare HDMI"
depends on DRM_SUN4I
diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
index 1e2320d824b5..0d04f2447b01 100644
--- a/drivers/gpu/drm/sun4i/Makefile
+++ b/drivers/gpu/drm/sun4i/Makefile
@@ -34,7 +34,6 @@ ifdef CONFIG_DRM_SUN4I_BACKEND
 obj-$(CONFIG_DRM_SUN4I)+= sun4i-frontend.o
 endif
 obj-$(CONFIG_DRM_SUN4I_HDMI)   += sun4i-drm-hdmi.o
-obj-$(CONFIG_DRM_SUN6I_DPHY)   += sun6i_mipi_dphy.o
 obj-$(CONFIG_DRM_SUN6I_DSI)+= sun6i_mipi_dsi.o
 obj-$(CONFIG_DRM_SUN8I_DW_HDMI)+= sun8i-drm-hdmi.o
 obj-$(CONFIG_DRM_SUN8I_MIXER)  += sun8i-mixer.o
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dphy.c 
b/drivers/gpu/drm/sun4i/sun6i_mipi_dphy.c
deleted file mode 100644
index 79c8af5c7c1d..
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dphy.c
+++ /dev/null
@@ -1,318 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Copyright (c) 2016 Allwinnertech Co., Ltd.
- * Copyright (C) 2017-2018 Bootlin
- *
- * Maxime Ripard 
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include 
-#include 
-
-#define SUN6I_DPHY_GCTL_REG0x00
-#define SUN6I_DPHY_GCTL_LANE_NUM(n)n) - 1) & 3) << 4)
-#define SUN6I_DPHY_GCTL_EN BIT(0)
-
-#define SUN6I_DPHY_TX_CTL_REG  0x04
-#define SUN6I_DPHY_TX_CTL_HS_TX_CLK_CONT   BIT(28)
-
-#define SUN6I_DPHY_TX_TIME0_REG0x10
-#define SUN6I_DPHY_TX_TIME0_HS_TRAIL(n)(((n) & 0xff) << 24)
-#define SUN6I_DPHY_TX_TIME0_HS_PREPARE(n)  (((n) & 0xff) << 16)
-#define SUN6I_DPHY_TX_TIME0_LP_CLK_DIV(n)  ((n) & 0xff)
-
-#define SUN6I_DPHY_TX_TIME1_REG0x14
-#define SUN6I_DPHY_TX_TIME1_CLK_POST(n)(((n) & 0xff) << 24)
-#define SUN6I_DPHY_TX_TIME1_CLK_PRE(n) (((n) & 0xff) << 16)
-#define SUN6I_DPHY_TX_TIME1_CLK_ZERO(n)(((n) & 0xff) << 8)
-#define SUN6I_DPHY_TX_TIME1_CLK_PREPARE(n) ((n) & 0xff)
-
-#define SUN6I_DPHY_TX_TIME2_REG0x18
-#define SUN6I_DPHY_TX_TIME2_CLK_TRAIL(n)   ((n) & 0xff)
-
-#define SUN6I_DPHY_TX_TIME3_REG0x1c
-
-#define SUN6I_DPHY_TX_TIME4_REG0x20
-#define SUN6I_DPHY_TX_TIME4_HS_TX_ANA1(n)  (((n) & 0xff) << 8)
-#define SUN6I_DPHY_TX_TIME4_HS_TX_ANA0(n)  ((n) & 0xff)
-
-#define SUN6I_DPHY_ANA0_REG0x4c
-#define SUN6I_DPHY_ANA0_REG_PWSBIT(31)
-#define SUN6I_DPHY_ANA0_REG_DMPC   BIT(28)
-#define SUN6I_DPHY_ANA0_REG_DMPD(n)(((n) & 0xf) << 24)
-#define SUN6I_DPHY_ANA0_REG_SLV(n) (((n) & 7) << 12)
-#define SUN6I_DPHY_ANA0_REG_DEN(n) (((n) & 0xf) << 8)
-
-#define SUN6I_DPHY_ANA1_REG0x50
-#define SUN6I_DPHY_ANA1_REG_VTTMODEBIT(31)
-#define SUN6I_DPHY_ANA1_REG_CSMPS(n)   (((n) & 3) << 28)
-#define SUN6I_DPHY_ANA1_REG_SVTT(n)(((n) & 0xf) << 24)
-
-#define SUN6I_DPHY_ANA2_REG0x54
-#define SUN6I_DPHY_ANA2_EN_P2S_CPU(n)  (((n) & 0xf) << 24)
-#define SUN6I_DPHY_ANA2_EN_P2S_CPU_MASKGENMASK(27, 24)
-#define SUN6I_DPHY_ANA2_EN_CK_CPU  BIT(4)
-#define SUN6I_DPHY_ANA2_REG_ENIB   BIT(1)
-
-#define SUN6I_DPHY_ANA3_REG0x58
-#define SUN6I_DPHY_ANA3_EN_VTTD(n) (((n) & 0xf) << 28)
-#define 

[PATCH v4 4/9] sun6i: dsi: Convert to generic phy handling

[Maxime Ripard]

Now that we have everything in place in the PHY framework to deal in a
generic way with MIPI D-PHY phys, let's convert our PHY driver and its
associated DSI driver to that new API.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/sun4i/Kconfig   |  11 +-
 drivers/gpu/drm/sun4i/Makefile  |   6 +-
 drivers/gpu/drm/sun4i/sun6i_mipi_dphy.c | 164 ++---
 drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c  |  31 ++---
 drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h  |  17 +---
 5 files changed, 126 insertions(+), 103 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/Kconfig b/drivers/gpu/drm/sun4i/Kconfig
index c2c042287c19..2b8db82c4bab 100644
--- a/drivers/gpu/drm/sun4i/Kconfig
+++ b/drivers/gpu/drm/sun4i/Kconfig
@@ -45,10 +45,19 @@ config DRM_SUN6I_DSI
default MACH_SUN8I
select CRC_CCITT
select DRM_MIPI_DSI
+   select DRM_SUN6I_DPHY
help
  Choose this option if you want have an Allwinner SoC with
  MIPI-DSI support. If M is selected the module will be called
- sun6i-dsi
+ sun6i_mipi_dsi.
+
+config DRM_SUN6I_DPHY
+   tristate "Allwinner A31 MIPI D-PHY Support"
+   select GENERIC_PHY_MIPI_DPHY
+   help
+ Choose this option if you have an Allwinner SoC with
+ MIPI-DSI support. If M is selected, the module will be
+ called sun6i_mipi_dphy.
 
 config DRM_SUN8I_DW_HDMI
tristate "Support for Allwinner version of DesignWare HDMI"
diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
index 0eb38ac8e86e..1e2320d824b5 100644
--- a/drivers/gpu/drm/sun4i/Makefile
+++ b/drivers/gpu/drm/sun4i/Makefile
@@ -24,9 +24,6 @@ sun4i-tcon-y  += sun4i_lvds.o
 sun4i-tcon-y   += sun4i_tcon.o
 sun4i-tcon-y   += sun4i_rgb.o
 
-sun6i-dsi-y+= sun6i_mipi_dphy.o
-sun6i-dsi-y+= sun6i_mipi_dsi.o
-
 obj-$(CONFIG_DRM_SUN4I)+= sun4i-drm.o
 obj-$(CONFIG_DRM_SUN4I)+= sun4i-tcon.o
 obj-$(CONFIG_DRM_SUN4I)+= sun4i_tv.o
@@ -37,7 +34,8 @@ ifdef CONFIG_DRM_SUN4I_BACKEND
 obj-$(CONFIG_DRM_SUN4I)+= sun4i-frontend.o
 endif
 obj-$(CONFIG_DRM_SUN4I_HDMI)   += sun4i-drm-hdmi.o
-obj-$(CONFIG_DRM_SUN6I_DSI)+= sun6i-dsi.o
+obj-$(CONFIG_DRM_SUN6I_DPHY)   += sun6i_mipi_dphy.o
+obj-$(CONFIG_DRM_SUN6I_DSI)+= sun6i_mipi_dsi.o
 obj-$(CONFIG_DRM_SUN8I_DW_HDMI)+= sun8i-drm-hdmi.o
 obj-$(CONFIG_DRM_SUN8I_MIXER)  += sun8i-mixer.o
 obj-$(CONFIG_DRM_SUN8I_TCON_TOP) += sun8i_tcon_top.o
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dphy.c 
b/drivers/gpu/drm/sun4i/sun6i_mipi_dphy.c
index e4d19431fa0e..79c8af5c7c1d 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dphy.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dphy.c
@@ -8,11 +8,14 @@
 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include 
 #include 
 
-#include "sun6i_mipi_dsi.h"
+#include 
+#include 
 
 #define SUN6I_DPHY_GCTL_REG0x00
 #define SUN6I_DPHY_GCTL_LANE_NUM(n)n) - 1) & 3) << 4)
@@ -81,12 +84,46 @@
 
 #define SUN6I_DPHY_DBG5_REG0xf4
 
-int sun6i_dphy_init(struct sun6i_dphy *dphy, unsigned int lanes)
+struct sun6i_dphy {
+   struct clk  *bus_clk;
+   struct clk  *mod_clk;
+   struct regmap   *regs;
+   struct reset_control*reset;
+
+   struct phy  *phy;
+   struct phy_configure_opts_mipi_dphy config;
+};
+
+static int sun6i_dphy_init(struct phy *phy)
 {
+   struct sun6i_dphy *dphy = phy_get_drvdata(phy);
+
reset_control_deassert(dphy->reset);
clk_prepare_enable(dphy->mod_clk);
clk_set_rate_exclusive(dphy->mod_clk, 15000);
 
+   return 0;
+}
+
+static int sun6i_dphy_configure(struct phy *phy, union phy_configure_opts 
*opts)
+{
+   struct sun6i_dphy *dphy = phy_get_drvdata(phy);
+   int ret;
+
+   ret = phy_mipi_dphy_config_validate(>mipi_dphy);
+   if (ret)
+   return ret;
+
+   memcpy(>config, opts, sizeof(dphy->config));
+
+   return 0;
+}
+
+static int sun6i_dphy_power_on(struct phy *phy)
+{
+   struct sun6i_dphy *dphy = phy_get_drvdata(phy);
+   u8 lanes_mask = GENMASK(dphy->config.lanes - 1, 0);
+
regmap_write(dphy->regs, SUN6I_DPHY_TX_CTL_REG,
 SUN6I_DPHY_TX_CTL_HS_TX_CLK_CONT);
 
@@ -111,16 +148,9 @@ int sun6i_dphy_init(struct sun6i_dphy *dphy, unsigned int 
lanes)
 SUN6I_DPHY_TX_TIME4_HS_TX_ANA1(3));
 
regmap_write(dphy->regs, SUN6I_DPHY_GCTL_REG,
-SUN6I_DPHY_GCTL_LANE_NUM(lanes) |
+SUN6I_DPHY_GCTL_LANE_NUM(dphy->config.lanes) |
 SUN6I_DPHY_GCTL_EN);
 
-   return 0;
-}
-
-int sun6i_dphy_power_on(struct sun6i_dphy *dphy, unsigned int lanes)
-{
-   u8 lanes_mask = GENMASK(lanes - 1, 0);
-

[PATCH v4 2/9] phy: dphy: Change units of wakeup and init parameters

[Maxime Ripard]

The Init and wakeup D-PHY parameters are in the micro/milliseconds range,
putting the values real close to the types limits if they were in
picoseconds.

Move them to microseconds which should be better fit.

Suggested-by: Sakari Ailus 
Signed-off-by: Maxime Ripard 
---
 drivers/phy/phy-core-mipi-dphy.c  | 8 
 include/linux/phy/phy-mipi-dphy.h | 8 
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/phy/phy-core-mipi-dphy.c b/drivers/phy/phy-core-mipi-dphy.c
index 465fa1b91a5f..14e0551cd319 100644
--- a/drivers/phy/phy-core-mipi-dphy.c
+++ b/drivers/phy/phy-core-mipi-dphy.c
@@ -65,12 +65,12 @@ int phy_mipi_dphy_get_default_config(unsigned long 
pixel_clock,
 */
cfg->hs_trail = max(4 * 8 * ui, 6 + 4 * 4 * ui);
 
-   cfg->init = 1;
+   cfg->init = 100;
cfg->lpx = 6;
cfg->ta_get = 5 * cfg->lpx;
cfg->ta_go = 4 * cfg->lpx;
cfg->ta_sure = 2 * cfg->lpx;
-   cfg->wakeup = 10;
+   cfg->wakeup = 1000;
 
cfg->hs_clk_rate = hs_clk_rate;
cfg->lanes = lanes;
@@ -143,7 +143,7 @@ int phy_mipi_dphy_config_validate(struct 
phy_configure_opts_mipi_dphy *cfg)
if (cfg->hs_trail < max(8 * ui, 6 + 4 * ui))
return -EINVAL;
 
-   if (cfg->init < 1)
+   if (cfg->init < 100)
return -EINVAL;
 
if (cfg->lpx < 5)
@@ -158,7 +158,7 @@ int phy_mipi_dphy_config_validate(struct 
phy_configure_opts_mipi_dphy *cfg)
if (cfg->ta_sure < cfg->lpx || cfg->ta_sure > (2 * cfg->lpx))
return -EINVAL;
 
-   if (cfg->wakeup < 10)
+   if (cfg->wakeup < 1000)
return -EINVAL;
 
return 0;
diff --git a/include/linux/phy/phy-mipi-dphy.h 
b/include/linux/phy/phy-mipi-dphy.h
index 9cf97cd1d303..627d28080d3a 100644
--- a/include/linux/phy/phy-mipi-dphy.h
+++ b/include/linux/phy/phy-mipi-dphy.h
@@ -190,10 +190,10 @@ struct phy_configure_opts_mipi_dphy {
/**
 * @init:
 *
-* Time, in picoseconds for the initialization period to
+* Time, in microseconds for the initialization period to
 * complete.
 *
-* Minimum value: 1 ps
+* Minimum value: 100 us
 */
unsigned intinit;
 
@@ -244,11 +244,11 @@ struct phy_configure_opts_mipi_dphy {
/**
 * @wakeup:
 *
-* Time, in picoseconds, that a transmitter drives a Mark-1
+* Time, in microseconds, that a transmitter drives a Mark-1
 * state prior to a Stop state in order to initiate an exit
 * from ULPS.
 *
-* Minimum value: 10 ps
+* Minimum value: 1000 us
 */
unsigned intwakeup;
 
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 7/9] dt-bindings: phy: Move the Cadence D-PHY bindings

[Maxime Ripard]

The Cadence D-PHY bindings was defined as part of the DSI block so far.
However, since it's now going to be a separate driver, we need to move the
binding to a file of its own.

Signed-off-by: Maxime Ripard 
---
 Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt | 21 +---
 Documentation/devicetree/bindings/phy/cdns,dphy.txt   | 20 +++-
 2 files changed, 20 insertions(+), 21 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/phy/cdns,dphy.txt

diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt 
b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt
index f5725bb6c61c..525a4bfd8634 100644
--- a/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt
+++ b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt
@@ -31,28 +31,7 @@ Required subnodes:
 - one subnode per DSI device connected on the DSI bus. Each DSI device should
   contain a reg property encoding its virtual channel.
 
-Cadence DPHY
-
-
-Cadence DPHY block.
-
-Required properties:
-- compatible: should be set to "cdns,dphy".
-- reg: physical base address and length of the DPHY registers.
-- clocks: DPHY reference clocks.
-- clock-names: must contain "psm" and "pll_ref".
-- #phy-cells: must be set to 0.
-
-
 Example:
-   dphy0: dphy@fd0e{
-   compatible = "cdns,dphy";
-   reg = <0x0 0xfd0e 0x0 0x1000>;
-   clocks = <_clk>, <_ref_clk>;
-   clock-names = "psm", "pll_ref";
-   #phy-cells = <0>;
-   };
-
dsi0: dsi@fd0c {
compatible = "cdns,dsi";
reg = <0x0 0xfd0c 0x0 0x1000>;
diff --git a/Documentation/devicetree/bindings/phy/cdns,dphy.txt 
b/Documentation/devicetree/bindings/phy/cdns,dphy.txt
new file mode 100644
index ..1095bc4e72d9
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/cdns,dphy.txt
@@ -0,0 +1,20 @@
+Cadence DPHY
+
+
+Cadence DPHY block.
+
+Required properties:
+- compatible: should be set to "cdns,dphy".
+- reg: physical base address and length of the DPHY registers.
+- clocks: DPHY reference clocks.
+- clock-names: must contain "psm" and "pll_ref".
+- #phy-cells: must be set to 0.
+
+Example:
+   dphy0: dphy@fd0e{
+   compatible = "cdns,dphy";
+   reg = <0x0 0xfd0e 0x0 0x1000>;
+   clocks = <_clk>, <_ref_clk>;
+   clock-names = "psm", "pll_ref";
+   #phy-cells = <0>;
+   };
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 0/9] phy: Add configuration interface for MIPI D-PHY devices

[Maxime Ripard]

Hi,

Here is a set of patches to allow the phy framework consumers to test and
apply runtime configurations.

This is needed to support more phy classes that require tuning based on
parameters depending on the current use case of the device, in addition to
the power state management already provided by the current functions.

A first test bed for that API are the MIPI D-PHY devices. There's a number
of solutions that have been used so far to support these phy, most of the
time being an ad-hoc driver in the consumer.

That approach has a big shortcoming though, which is that this is quite
difficult to deal with consumers integrated with multiple variants of phy,
of multiple consumers integrated with the same phy.

The latter case can be found in the Cadence DSI bridge, and the CSI
transceiver and receivers. All of them are integrated with the same phy, or
can be integrated with different phy, depending on the implementation.

I've looked at all the MIPI DSI drivers I could find, and gathered all the
parameters I could find. The interface should be complete, and most of the
drivers can be converted in the future. The current set converts two of
them: the above mentionned Cadence DSI driver so that the v4l2 drivers can
use them, and the Allwinner MIPI-DSI driver.

Let me know what you think,
Maxime

Changes from v3
  - Rebased on 5.0-rc1
  - Added the fixes suggested by Sakari

Changes from v2:
  - Rebased on next
  - Changed the interface to accomodate for the new submodes
  - Changed the timings units from nanoseconds to picoseconds
  - Added minimum and maximum boundaries to the documentation
  - Moved the clock enabling to phy_power_on in the Cadence DPHY driver
  - Exported the phy_configure and phy_validate symbols
  - Rework the phy pll divider computation in the cadence dphy driver

Changes from v1:
  - Rebased on top of 4.20-rc1
  - Removed the bus mode and timings parameters from the MIPI D-PHY
parameters, since that shouldn't have any impact on the PHY itself.
  - Reworked the Cadence DSI and D-PHY drivers to take this into account.
  - Remove the mode parameter from phy_configure
  - Added phy_configure and phy_validate stubs
  - Return -EOPNOTSUPP in phy_configure and phy_validate when the operation
is not implemented

Maxime Ripard (9):
  phy: dphy: Remove unused header
  phy: dphy: Change units of wakeup and init parameters
  phy: dphy: Clarify lanes parameter documentation
  sun6i: dsi: Convert to generic phy handling
  phy: Move Allwinner A31 D-PHY driver to drivers/phy/
  drm/bridge: cdns: Separate DSI and D-PHY configuration
  dt-bindings: phy: Move the Cadence D-PHY bindings
  phy: Add Cadence D-PHY support
  drm/bridge: cdns: Convert to phy framework

 Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt |  21 +-
 Documentation/devicetree/bindings/phy/cdns,dphy.txt   |  20 +-
 drivers/gpu/drm/bridge/Kconfig|   1 +-
 drivers/gpu/drm/bridge/cdns-dsi.c | 535 +--
 drivers/gpu/drm/sun4i/Kconfig |   3 +-
 drivers/gpu/drm/sun4i/Makefile|   5 +-
 drivers/gpu/drm/sun4i/sun6i_mipi_dphy.c   | 292 +
 drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c|  31 +-
 drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h|  17 +-
 drivers/phy/allwinner/Kconfig |  12 +-
 drivers/phy/allwinner/Makefile|   1 +-
 drivers/phy/allwinner/phy-sun6i-mipi-dphy.c   | 318 -
 drivers/phy/cadence/Kconfig   |  13 +-
 drivers/phy/cadence/Makefile  |   1 +-
 drivers/phy/cadence/cdns-dphy.c   | 389 +-
 drivers/phy/phy-core-mipi-dphy.c  |   8 +-
 include/linux/phy/phy-mipi-dphy.h |  13 +-
 17 files changed, 890 insertions(+), 790 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/phy/cdns,dphy.txt
 delete mode 100644 drivers/gpu/drm/sun4i/sun6i_mipi_dphy.c
 create mode 100644 drivers/phy/allwinner/phy-sun6i-mipi-dphy.c
 create mode 100644 drivers/phy/cadence/cdns-dphy.c

base-commit: bfeffd155283772bbe78c6a05dec7c0128ee500c
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 6/9] drm/bridge: cdns: Separate DSI and D-PHY configuration

[Maxime Ripard]

The current configuration of the DSI bridge and its associated D-PHY is
intertwined. In order to ease the future conversion to the phy framework
for the D-PHY part, let's split the configuration in two.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/bridge/cdns-dsi.c | 96 ++--
 1 file changed, 68 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/bridge/cdns-dsi.c 
b/drivers/gpu/drm/bridge/cdns-dsi.c
index ce9496d13986..3ac6dd524b6d 100644
--- a/drivers/gpu/drm/bridge/cdns-dsi.c
+++ b/drivers/gpu/drm/bridge/cdns-dsi.c
@@ -545,6 +545,11 @@ bridge_to_cdns_dsi_input(struct drm_bridge *bridge)
return container_of(bridge, struct cdns_dsi_input, bridge);
 }
 
+static unsigned int mode_to_dpi_hfp(const struct drm_display_mode *mode)
+{
+   return mode->crtc_hsync_start - mode->crtc_hdisplay;
+}
+
 static int cdns_dsi_get_dphy_pll_cfg(struct cdns_dphy *dphy,
 struct cdns_dphy_cfg *cfg,
 unsigned int dpi_htotal,
@@ -731,14 +736,12 @@ static unsigned int dpi_to_dsi_timing(unsigned int 
dpi_timing,
 static int cdns_dsi_mode2cfg(struct cdns_dsi *dsi,
 const struct drm_display_mode *mode,
 struct cdns_dsi_cfg *dsi_cfg,
-struct cdns_dphy_cfg *dphy_cfg,
 bool mode_valid_check)
 {
-   unsigned long dsi_htotal = 0, dsi_hss_hsa_hse_hbp = 0;
struct cdns_dsi_output *output = >output;
-   unsigned int dsi_hfp_ext = 0, dpi_hfp, tmp;
+   unsigned int tmp;
bool sync_pulse = false;
-   int bpp, nlanes, ret;
+   int bpp, nlanes;
 
memset(dsi_cfg, 0, sizeof(*dsi_cfg));
 
@@ -757,8 +760,6 @@ static int cdns_dsi_mode2cfg(struct cdns_dsi *dsi,
   mode->crtc_hsync_end : mode->crtc_hsync_start);
 
dsi_cfg->hbp = dpi_to_dsi_timing(tmp, bpp, DSI_HBP_FRAME_OVERHEAD);
-   dsi_htotal += dsi_cfg->hbp + DSI_HBP_FRAME_OVERHEAD;
-   dsi_hss_hsa_hse_hbp += dsi_cfg->hbp + DSI_HBP_FRAME_OVERHEAD;
 
if (sync_pulse) {
if (mode_valid_check)
@@ -768,49 +769,90 @@ static int cdns_dsi_mode2cfg(struct cdns_dsi *dsi,
 
dsi_cfg->hsa = dpi_to_dsi_timing(tmp, bpp,
 DSI_HSA_FRAME_OVERHEAD);
-   dsi_htotal += dsi_cfg->hsa + DSI_HSA_FRAME_OVERHEAD;
-   dsi_hss_hsa_hse_hbp += dsi_cfg->hsa + DSI_HSA_FRAME_OVERHEAD;
}
 
dsi_cfg->hact = dpi_to_dsi_timing(mode_valid_check ?
  mode->hdisplay : mode->crtc_hdisplay,
  bpp, 0);
-   dsi_htotal += dsi_cfg->hact;
+   dsi_cfg->hfp = dpi_to_dsi_timing(mode_to_dpi_hfp(mode), bpp,
+DSI_HFP_FRAME_OVERHEAD);
 
-   if (mode_valid_check)
-   dpi_hfp = mode->hsync_start - mode->hdisplay;
-   else
-   dpi_hfp = mode->crtc_hsync_start - mode->crtc_hdisplay;
+   return 0;
+}
+
+static int cdns_dphy_validate(struct cdns_dsi *dsi,
+ struct cdns_dsi_cfg *dsi_cfg,
+ struct cdns_dphy_cfg *dphy_cfg,
+ const struct drm_display_mode *mode,
+ bool mode_valid_check)
+{
+   struct cdns_dsi_output *output = >output;
+   unsigned long dsi_htotal;
+   unsigned int dsi_hfp_ext = 0;
+
+   int ret;
 
-   dsi_cfg->hfp = dpi_to_dsi_timing(dpi_hfp, bpp, DSI_HFP_FRAME_OVERHEAD);
+   dsi_htotal = dsi_cfg->hbp + DSI_HBP_FRAME_OVERHEAD;
+   if (output->dev->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)
+   dsi_htotal += dsi_cfg->hsa + DSI_HSA_FRAME_OVERHEAD;
+
+   dsi_htotal += dsi_cfg->hact;
dsi_htotal += dsi_cfg->hfp + DSI_HFP_FRAME_OVERHEAD;
 
if (mode_valid_check)
ret = cdns_dsi_get_dphy_pll_cfg(dsi->dphy, dphy_cfg,
-   mode->htotal, bpp,
+   mode->htotal,
mode->clock * 1000,
-   dsi_htotal, nlanes,
+   
mipi_dsi_pixel_format_to_bpp(output->dev->format),
+   dsi_htotal,
+   output->dev->lanes,
_hfp_ext);
else
ret = cdns_dsi_get_dphy_pll_cfg(dsi->dphy, dphy_cfg,
-   mode->crtc_htotal, bpp,
+   mode->crtc_htotal,
+   
mipi_dsi_pixel_format_to_bpp(output->dev->format),
mode->crtc_clock * 1000,
- 

[PATCH v4 8/9] phy: Add Cadence D-PHY support

[Maxime Ripard]

Cadence has designed a D-PHY that can be used by the, currently in tree,
DSI bridge (DRM), CSI Transceiver and CSI Receiver (v4l2) drivers.

Only the DSI driver has an ad-hoc driver for that phy at the moment, while
the v4l2 drivers are completely missing any phy support. In order to make
that phy support available to all these drivers, without having to
duplicate that code three times, let's create a generic phy framework
driver.

Signed-off-by: Maxime Ripard 
---
 drivers/phy/cadence/Kconfig |  13 +-
 drivers/phy/cadence/Makefile|   1 +-
 drivers/phy/cadence/cdns-dphy.c | 389 +-
 3 files changed, 402 insertions(+), 1 deletion(-)
 create mode 100644 drivers/phy/cadence/cdns-dphy.c

diff --git a/drivers/phy/cadence/Kconfig b/drivers/phy/cadence/Kconfig
index 2b8c0851ff33..31f18b67dd7c 100644
--- a/drivers/phy/cadence/Kconfig
+++ b/drivers/phy/cadence/Kconfig
@@ -1,6 +1,7 @@
 #
 # Phy drivers for Cadence PHYs
 #
+
 config PHY_CADENCE_DP
tristate "Cadence MHDP DisplayPort PHY driver"
depends on OF
@@ -9,9 +10,19 @@ config PHY_CADENCE_DP
help
  Support for Cadence MHDP DisplayPort PHY.
 
+config PHY_CADENCE_DPHY
+   tristate "Cadence D-PHY Support"
+   depends on HAS_IOMEM && OF
+   select GENERIC_PHY
+   select GENERIC_PHY_MIPI_DPHY
+   help
+ Choose this option if you have a Cadence D-PHY in your
+ system. If M is selected, the module will be called
+ cdns-dphy.
+
 config PHY_CADENCE_SIERRA
tristate "Cadence Sierra PHY Driver"
depends on OF && HAS_IOMEM && RESET_CONTROLLER
select GENERIC_PHY
help
- Enable this to support the Cadence Sierra PHY driver
\ No newline at end of file
+ Enable this to support the Cadence Sierra PHY driver
diff --git a/drivers/phy/cadence/Makefile b/drivers/phy/cadence/Makefile
index 412349af0492..2f9e3457b954 100644
--- a/drivers/phy/cadence/Makefile
+++ b/drivers/phy/cadence/Makefile
@@ -1,2 +1,3 @@
 obj-$(CONFIG_PHY_CADENCE_DP)   += phy-cadence-dp.o
+obj-$(CONFIG_PHY_CADENCE_DPHY) += cdns-dphy.o
 obj-$(CONFIG_PHY_CADENCE_SIERRA)   += phy-cadence-sierra.o
diff --git a/drivers/phy/cadence/cdns-dphy.c b/drivers/phy/cadence/cdns-dphy.c
new file mode 100644
index ..1d0abba03f37
--- /dev/null
+++ b/drivers/phy/cadence/cdns-dphy.c
@@ -0,0 +1,389 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright: 2017-2018 Cadence Design Systems, Inc.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#define REG_WAKEUP_TIME_NS 800
+#define DPHY_PLL_RATE_HZ   10800
+
+/* DPHY registers */
+#define DPHY_PMA_CMN(reg)  (reg)
+#define DPHY_PMA_LCLK(reg) (0x100 + (reg))
+#define DPHY_PMA_LDATA(lane, reg)  (0x200 + ((lane) * 0x100) + (reg))
+#define DPHY_PMA_RCLK(reg) (0x600 + (reg))
+#define DPHY_PMA_RDATA(lane, reg)  (0x700 + ((lane) * 0x100) + (reg))
+#define DPHY_PCS(reg)  (0xb00 + (reg))
+
+#define DPHY_CMN_SSM   DPHY_PMA_CMN(0x20)
+#define DPHY_CMN_SSM_ENBIT(0)
+#define DPHY_CMN_TX_MODE_ENBIT(9)
+
+#define DPHY_CMN_PWM   DPHY_PMA_CMN(0x40)
+#define DPHY_CMN_PWM_DIV(x)((x) << 20)
+#define DPHY_CMN_PWM_LOW(x)((x) << 10)
+#define DPHY_CMN_PWM_HIGH(x)   (x)
+
+#define DPHY_CMN_FBDIV DPHY_PMA_CMN(0x4c)
+#define DPHY_CMN_FBDIV_VAL(low, high)  (((high) << 11) | ((low) << 22))
+#define DPHY_CMN_FBDIV_FROM_REG(BIT(10) | BIT(21))
+
+#define DPHY_CMN_OPIPDIV   DPHY_PMA_CMN(0x50)
+#define DPHY_CMN_IPDIV_FROM_REGBIT(0)
+#define DPHY_CMN_IPDIV(x)  ((x) << 1)
+#define DPHY_CMN_OPDIV_FROM_REGBIT(6)
+#define DPHY_CMN_OPDIV(x)  ((x) << 7)
+
+#define DPHY_PSM_CFG   DPHY_PCS(0x4)
+#define DPHY_PSM_CFG_FROM_REG  BIT(0)
+#define DPHY_PSM_CLK_DIV(x)((x) << 1)
+
+#define DSI_HBP_FRAME_OVERHEAD 12
+#define DSI_HSA_FRAME_OVERHEAD 14
+#define DSI_HFP_FRAME_OVERHEAD 6
+#define DSI_HSS_VSS_VSE_FRAME_OVERHEAD 4
+#define DSI_BLANKING_FRAME_OVERHEAD6
+#define DSI_NULL_FRAME_OVERHEAD6
+#define DSI_EOT_PKT_SIZE   4
+
+struct cdns_dphy_cfg {
+   u8 pll_ipdiv;
+   u8 pll_opdiv;
+   u16 pll_fbdiv;
+   unsigned int nlanes;
+};
+
+enum cdns_dphy_clk_lane_cfg {
+   DPHY_CLK_CFG_LEFT_DRIVES_ALL = 0,
+   DPHY_CLK_CFG_LEFT_DRIVES_RIGHT = 1,
+   DPHY_CLK_CFG_LEFT_DRIVES_LEFT = 2,
+   DPHY_CLK_CFG_RIGHT_DRIVES_ALL = 3,
+};
+
+struct cdns_dphy;
+struct cdns_dphy_ops {
+   int (*probe)(struct cdns_dphy *dphy);
+   void (*remove)(struct cdns_dphy *dphy);
+   void (*set_psm_div)(struct cdns_dphy *dphy, u8 div);
+   void (*set_clk_lane_cfg)(struct cdns_dphy *dphy,
+

[PATCH v4 9/9] drm/bridge: cdns: Convert to phy framework

[Maxime Ripard]

Now that we have everything we need in the phy framework to allow to tune
the phy parameters, let's convert the Cadence DSI bridge to that API
instead of creating a ad-hoc driver for its phy.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/bridge/Kconfig|   1 +-
 drivers/gpu/drm/bridge/cdns-dsi.c | 485 +++
 drivers/phy/cadence/cdns-dphy.c   |   2 +-
 3 files changed, 61 insertions(+), 427 deletions(-)

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 2fee47b0d50b..8840f396a7b6 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -30,6 +30,7 @@ config DRM_CDNS_DSI
select DRM_KMS_HELPER
select DRM_MIPI_DSI
select DRM_PANEL_BRIDGE
+   select GENERIC_PHY_MIPI_DPHY
depends on OF
help
  Support Cadence DPI to DSI bridge. This is an internal
diff --git a/drivers/gpu/drm/bridge/cdns-dsi.c 
b/drivers/gpu/drm/bridge/cdns-dsi.c
index 3ac6dd524b6d..7b432257ffbe 100644
--- a/drivers/gpu/drm/bridge/cdns-dsi.c
+++ b/drivers/gpu/drm/bridge/cdns-dsi.c
@@ -21,6 +21,9 @@
 #include 
 #include 
 
+#include 
+#include 
+
 #define IP_CONF0x0
 #define SP_HS_FIFO_DEPTH(x)(((x) & GENMASK(30, 26)) >> 26)
 #define SP_LP_FIFO_DEPTH(x)(((x) & GENMASK(25, 21)) >> 21)
@@ -419,44 +422,11 @@
 #define DSI_NULL_FRAME_OVERHEAD6
 #define DSI_EOT_PKT_SIZE   4
 
-#define REG_WAKEUP_TIME_NS 800
-#define DPHY_PLL_RATE_HZ   10800
-
-/* DPHY registers */
-#define DPHY_PMA_CMN(reg)  (reg)
-#define DPHY_PMA_LCLK(reg) (0x100 + (reg))
-#define DPHY_PMA_LDATA(lane, reg)  (0x200 + ((lane) * 0x100) + (reg))
-#define DPHY_PMA_RCLK(reg) (0x600 + (reg))
-#define DPHY_PMA_RDATA(lane, reg)  (0x700 + ((lane) * 0x100) + (reg))
-#define DPHY_PCS(reg)  (0xb00 + (reg))
-
-#define DPHY_CMN_SSM   DPHY_PMA_CMN(0x20)
-#define DPHY_CMN_SSM_ENBIT(0)
-#define DPHY_CMN_TX_MODE_ENBIT(9)
-
-#define DPHY_CMN_PWM   DPHY_PMA_CMN(0x40)
-#define DPHY_CMN_PWM_DIV(x)((x) << 20)
-#define DPHY_CMN_PWM_LOW(x)((x) << 10)
-#define DPHY_CMN_PWM_HIGH(x)   (x)
-
-#define DPHY_CMN_FBDIV DPHY_PMA_CMN(0x4c)
-#define DPHY_CMN_FBDIV_VAL(low, high)  (((high) << 11) | ((low) << 22))
-#define DPHY_CMN_FBDIV_FROM_REG(BIT(10) | BIT(21))
-
-#define DPHY_CMN_OPIPDIV   DPHY_PMA_CMN(0x50)
-#define DPHY_CMN_IPDIV_FROM_REGBIT(0)
-#define DPHY_CMN_IPDIV(x)  ((x) << 1)
-#define DPHY_CMN_OPDIV_FROM_REGBIT(6)
-#define DPHY_CMN_OPDIV(x)  ((x) << 7)
-
-#define DPHY_PSM_CFG   DPHY_PCS(0x4)
-#define DPHY_PSM_CFG_FROM_REG  BIT(0)
-#define DPHY_PSM_CLK_DIV(x)((x) << 1)
-
 struct cdns_dsi_output {
struct mipi_dsi_device *dev;
struct drm_panel *panel;
struct drm_bridge *bridge;
+   union phy_configure_opts phy_opts;
 };
 
 enum cdns_dsi_input_id {
@@ -465,14 +435,6 @@ enum cdns_dsi_input_id {
CDNS_DSC_INPUT,
 };
 
-struct cdns_dphy_cfg {
-   u8 pll_ipdiv;
-   u8 pll_opdiv;
-   u16 pll_fbdiv;
-   unsigned long lane_bps;
-   unsigned int nlanes;
-};
-
 struct cdns_dsi_cfg {
unsigned int hfp;
unsigned int hsa;
@@ -481,34 +443,6 @@ struct cdns_dsi_cfg {
unsigned int htotal;
 };
 
-struct cdns_dphy;
-
-enum cdns_dphy_clk_lane_cfg {
-   DPHY_CLK_CFG_LEFT_DRIVES_ALL = 0,
-   DPHY_CLK_CFG_LEFT_DRIVES_RIGHT = 1,
-   DPHY_CLK_CFG_LEFT_DRIVES_LEFT = 2,
-   DPHY_CLK_CFG_RIGHT_DRIVES_ALL = 3,
-};
-
-struct cdns_dphy_ops {
-   int (*probe)(struct cdns_dphy *dphy);
-   void (*remove)(struct cdns_dphy *dphy);
-   void (*set_psm_div)(struct cdns_dphy *dphy, u8 div);
-   void (*set_clk_lane_cfg)(struct cdns_dphy *dphy,
-enum cdns_dphy_clk_lane_cfg cfg);
-   void (*set_pll_cfg)(struct cdns_dphy *dphy,
-   const struct cdns_dphy_cfg *cfg);
-   unsigned long (*get_wakeup_time_ns)(struct cdns_dphy *dphy);
-};
-
-struct cdns_dphy {
-   struct cdns_dphy_cfg cfg;
-   void __iomem *regs;
-   struct clk *psm_clk;
-   struct clk *pll_ref_clk;
-   const struct cdns_dphy_ops *ops;
-};
-
 struct cdns_dsi_input {
enum cdns_dsi_input_id id;
struct drm_bridge bridge;
@@ -526,7 +460,7 @@ struct cdns_dsi {
struct reset_control *dsi_p_rst;
struct clk *dsi_sys_clk;
bool link_initialized;
-   struct cdns_dphy *dphy;
+   struct phy *dphy;
 };
 
 static inline struct cdns_dsi *input_to_dsi(struct cdns_dsi_input *input)
@@ -550,175 +484,6 @@ static unsigned int mode_to_dpi_hfp(const struct 
drm_display_mode *mode)
return mode->crtc_hsync_start - 

[PATCH v4 3/9] phy: dphy: Clarify lanes parameter documentation

[Maxime Ripard]

The lanes parameter is not solely about the number of lanes, but it also
carries the fact that those are the first lanes in use during the
transmission.

It was implicit so far, so make sure it's explicit now.

Suggested-by: Sakari Ailus 
Signed-off-by: Maxime Ripard 
---
 include/linux/phy/phy-mipi-dphy.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/include/linux/phy/phy-mipi-dphy.h 
b/include/linux/phy/phy-mipi-dphy.h
index 627d28080d3a..a877ffee845d 100644
--- a/include/linux/phy/phy-mipi-dphy.h
+++ b/include/linux/phy/phy-mipi-dphy.h
@@ -269,7 +269,8 @@ struct phy_configure_opts_mipi_dphy {
/**
 * @lanes:
 *
-* Number of active data lanes used for the transmissions.
+* Number of active, consecutive, data lanes, starting from
+* lane 0, used for the transmissions.
 */
unsigned char   lanes;
 };
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 1/9] phy: dphy: Remove unused header

[Maxime Ripard]

The videomode.h header inclusion is an artifact from the patches
development, remove it.

Suggested-by: Sakari Ailus 
Signed-off-by: Maxime Ripard 
---
 include/linux/phy/phy-mipi-dphy.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/include/linux/phy/phy-mipi-dphy.h 
b/include/linux/phy/phy-mipi-dphy.h
index c08aacc0ac35..9cf97cd1d303 100644
--- a/include/linux/phy/phy-mipi-dphy.h
+++ b/include/linux/phy/phy-mipi-dphy.h
@@ -6,8 +6,6 @@
 #ifndef __PHY_MIPI_DPHY_H_
 #define __PHY_MIPI_DPHY_H_
 
-#include 
-
 /**
  * struct phy_configure_opts_mipi_dphy - MIPI D-PHY configuration set
  *
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 109246] HDMI connected monitors fail to sleep and instead turn back on when amdgpu.dc=1

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109246

--- Comment #12 from Michel Dänzer  ---
(In reply to tme from comment #9)
> Setting amdgpu.dc=1 on 4.15.18 and 4.16.18 does not reproduce the problem.
> It does, however, reproduce on 4.17.19.

Can you bisect between 4.16.18 and 4.17.19?

(I see some HPD filtering related changes between them, Nicholas / Harry maybe
you can take a look if anything jumps out?)

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v7 6/6] arm64: dts: sdm845: Add gpu and gmu device nodes

[Rajendra Nayak]

On 1/9/2019 10:50 AM, Doug Anderson wrote:

...but in the meantime Rajendra has had to change his bindings, so you
still need to spin this to account for Rajendra's v9 bindings [2].
Specifically you need to make changes like:

-   compatible = "operating-points-v2-qcom-level";
+   compatible = "operating-points-v2-level";


so there's now a v10 [1] and the new compatible is completely dropped and 
opp-level
is now an optional property using the default "operating-points-v2"

so the change should be
-   compatible = "operating-points-v2-qcom-level";
+   compatible = "operating-points-v2";

[1] https://lkml.org/lkml/2019/1/9/152

--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Armada DRM: bridge with componentized devices

[Russell King - ARM Linux]

On Wed, Jan 09, 2019 at 10:24:01AM +0100, Rafael J. Wysocki wrote:
> On Wed, Jan 9, 2019 at 10:13 AM Andrzej Hajda  wrote:
> >
> > +CC: Rafael J. Wysocki 
> >
> > On 08.01.2019 16:07, Russell King - ARM Linux wrote:
> > > On Tue, Jan 08, 2019 at 03:33:54PM +0100, Andrzej Hajda wrote:
> > >> On 08.01.2019 14:21, Russell King - ARM Linux wrote:
> > >>> On Tue, Jan 08, 2019 at 01:27:56PM +0100, Andrzej Hajda wrote:
> >  On 08.01.2019 12:38, Russell King - ARM Linux wrote:
> > > On Tue, Jan 08, 2019 at 12:25:34PM +0100, Andrzej Hajda wrote:
> > >> Issues with device links have nothing to do with hotplugging, they 
> > >> are
> > >> generic - lifetime of the objects (drm_bridge, drm_panel) is just
> > >> slightly different of lifetime of device links, and this is racy 
> > >> even if
> > >> you do not want hotplugging. Moreover since drm_dev is not device 
> > >> (has
> > >> no associated struct device) assuming we can reuse its parent to 
> > >> create
> > >> device link results in circular dependencies.
> > > How about having the device links created depending on whether the
> > > main drm driver wants them or not - that would mean that Exynos
> > > could continue avoiding them, but others that want them can have
> > > the links?
> >  That should be OK for Exynos. But regardless of Exynos device_links at
> >  the current state will not work correctly with bridges/panels as I
> >  described earlier.
> > >>> However, I'm not sure you're correct with your interpretation of the
> > >>> documentation.  Firstly, the documentation says:
> > >>>
> > >>>Another example for an inconsistent state would be a device link that
> > >>>represents a driver presence dependency, yet is added from the 
> > >>> consumer's
> > >>>->probe callback while the supplier hasn't probed yet: Had the 
> > >>> driver core
> > >>>known about the device link earlier, it wouldn't have probed the 
> > >>> consumer
> > >>>in the first place. The onus is thus on the consumer to check 
> > >>> presence of
> > >>>the supplier after adding the link, and defer probing on 
> > >>> non-presence.
> > >>>
> > >>> This is fine - if we add the device link from of_drm_find_bridge(), we
> > >>> will be in the consumer's ->probe function, and the supplier must have
> > >>> been probed for us to find the struct drm_bridge.
> > >>
> > >> Supplier usually is registered in it's probe time, so there is short
> > >> period of time when supplier is available, but the probe is not yet
> > >> finished - quite unsafe, but not impossible, especially if there exists
> > >> some kind of notifications about resource appearance (MIPI-DSI case).
> > > At some point during the supplier probe, the resource becomes available
> > > to consumers.  At that point, device links can be setup before the
> > > supplier has finished probing.  So any driver that provides resources
> > > to another driver will, at some point during the provider's probe,
> > > make resources available, and therefore be a candidate for device links
> > > to be created _before_ the probe function has returned.
> > >
> > > What is a problem is if the provider publishes resources, and then fails
> > > its probe function, causing the resource to disappear.
> >
> >
> > But creating link to not-probed provider is still incorrect usage from
> > device_links framework PoV, and my tests showed indeed that device link
> > created before end of provider's probe does not work at all - and since
> > it is stated in the documentation I guess it is by design.
> 
> Yes, it is.

So is the regulator support and the use of it being proposed for the CCF
all going against the design of device links?  In both those cases,
device links _can_ be created while the supplier is still in the probe
function by a consumer finding the resource.

This seems fragile by design.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Armada DRM: bridge with componentized devices

[Rafael J. Wysocki]

On Wed, Jan 9, 2019 at 10:13 AM Andrzej Hajda  wrote:
>
> +CC: Rafael J. Wysocki 
>
> On 08.01.2019 16:07, Russell King - ARM Linux wrote:
> > On Tue, Jan 08, 2019 at 03:33:54PM +0100, Andrzej Hajda wrote:
> >> On 08.01.2019 14:21, Russell King - ARM Linux wrote:
> >>> On Tue, Jan 08, 2019 at 01:27:56PM +0100, Andrzej Hajda wrote:
>  On 08.01.2019 12:38, Russell King - ARM Linux wrote:
> > On Tue, Jan 08, 2019 at 12:25:34PM +0100, Andrzej Hajda wrote:
> >> Issues with device links have nothing to do with hotplugging, they are
> >> generic - lifetime of the objects (drm_bridge, drm_panel) is just
> >> slightly different of lifetime of device links, and this is racy even 
> >> if
> >> you do not want hotplugging. Moreover since drm_dev is not device (has
> >> no associated struct device) assuming we can reuse its parent to create
> >> device link results in circular dependencies.
> > How about having the device links created depending on whether the
> > main drm driver wants them or not - that would mean that Exynos
> > could continue avoiding them, but others that want them can have
> > the links?
>  That should be OK for Exynos. But regardless of Exynos device_links at
>  the current state will not work correctly with bridges/panels as I
>  described earlier.
> >>> However, I'm not sure you're correct with your interpretation of the
> >>> documentation.  Firstly, the documentation says:
> >>>
> >>>Another example for an inconsistent state would be a device link that
> >>>represents a driver presence dependency, yet is added from the 
> >>> consumer's
> >>>->probe callback while the supplier hasn't probed yet: Had the driver 
> >>> core
> >>>known about the device link earlier, it wouldn't have probed the 
> >>> consumer
> >>>in the first place. The onus is thus on the consumer to check presence 
> >>> of
> >>>the supplier after adding the link, and defer probing on non-presence.
> >>>
> >>> This is fine - if we add the device link from of_drm_find_bridge(), we
> >>> will be in the consumer's ->probe function, and the supplier must have
> >>> been probed for us to find the struct drm_bridge.
> >>
> >> Supplier usually is registered in it's probe time, so there is short
> >> period of time when supplier is available, but the probe is not yet
> >> finished - quite unsafe, but not impossible, especially if there exists
> >> some kind of notifications about resource appearance (MIPI-DSI case).
> > At some point during the supplier probe, the resource becomes available
> > to consumers.  At that point, device links can be setup before the
> > supplier has finished probing.  So any driver that provides resources
> > to another driver will, at some point during the provider's probe,
> > make resources available, and therefore be a candidate for device links
> > to be created _before_ the probe function has returned.
> >
> > What is a problem is if the provider publishes resources, and then fails
> > its probe function, causing the resource to disappear.
>
>
> But creating link to not-probed provider is still incorrect usage from
> device_links framework PoV, and my tests showed indeed that device link
> created before end of provider's probe does not work at all - and since
> it is stated in the documentation I guess it is by design.

Yes, it is.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH AUTOSEL 4.20 034/117] drm/amdgpu: Correct get_crtc_scanoutpos behavior when vpos >= vtotal

[Michel Dänzer]

On 2019-01-08 8:25 p.m., Sasha Levin wrote:
> From: Nicholas Kazlauskas 
> 
> [ Upstream commit 520f08df45fbe300ed650da786a74093d658b7e1 ]
> 
> When variable refresh rate is active [...]

Variable refresh rate (FreeSync) support is only landing in 5.0,
therefore this fix isn't needed in older kernels.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel