Re: [v3 7/7] drm: mediatek: adjust dsi and mipi_tx probe sequence

[CK Hu]

Hi, Jitao:

On Sun, 2019-05-19 at 17:25 +0800, Jitao Shi wrote:
> mtk_mipi_tx is the phy of mtk_dsi.
> mtk_dsi get the phy(mtk_mipi_tx) in probe().
> 
> So,  mtk_mipi_tx init should be ahead of mtk_dsi. Or mtk_dsi will
> defer to wait mtk_mipi_tx probe done.

Reviewed-by: CK Hu 

> 
> Signed-off-by: Jitao Shi 
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index cf59ea9bccfd..583d533d9574 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -633,8 +633,8 @@ static struct platform_driver * const mtk_drm_drivers[] = 
> {
>   _disp_rdma_driver,
>   _dpi_driver,
>   _drm_platform_driver,
> - _dsi_driver,
>   _mipi_tx_driver,
> + _dsi_driver,
>  };
>  
>  static int __init mtk_drm_init(void)


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

Re: [v3 3/7] drm/mediatek: add dsi reg commit disable control

[CK Hu]

Hi, Jitao:

On Sun, 2019-05-19 at 17:25 +0800, Jitao Shi wrote:
> New DSI IP has shadow register and working reg. The register
> values are writen to shadow register. And then trigger with
> commit reg, the register values will be moved working register.
> 
> This fucntion is defualt on. But this driver doesn't use this
> function. So add the disable control.
> 
> Signed-off-by: Jitao Shi 
> ---
>  drivers/gpu/drm/mediatek/mtk_dsi.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index a48db056df6c..fd367985c7fd 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -131,6 +131,10 @@
>  #define VM_CMD_ENBIT(0)
>  #define TS_VFP_ENBIT(5)
>  
> +#define DSI_SHADOW_DEBUG 0x190U
> +#define FORCE_COMMIT BIT(0)
> +#define BYPASS_SHADOWBIT(1)

One more 'tab' for bitwise definition.

Regards,
CK

> +
>  #define CONFIG   (0xff << 0)
>  #define SHORT_PACKET 0
>  #define LONG_PACKET  2
> @@ -157,6 +161,7 @@ struct phy;
>  
>  struct mtk_dsi_driver_data {
>   const u32 reg_cmdq_off;
> + bool has_shadow_ctl;
>  };
>  
>  struct mtk_dsi {
> @@ -594,6 +599,11 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
>   }
>  
>   mtk_dsi_enable(dsi);
> +
> + if (dsi->driver_data->has_shadow_ctl)
> + writel(FORCE_COMMIT | BYPASS_SHADOW,
> +dsi->regs + DSI_SHADOW_DEBUG);
> +
>   mtk_dsi_reset_engine(dsi);
>   mtk_dsi_phy_timconfig(dsi);
>  


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

Re: [PATCH] dt-bindings: display: Convert Allwinner DSI to a schema

[Chen-Yu Tsai]

On Fri, May 31, 2019 at 2:54 AM Maxime Ripard  wrote:
>
> Hi,
>
> On Thu, May 30, 2019 at 09:48:02PM +0800, Chen-Yu Tsai wrote:
> > On Mon, May 27, 2019 at 8:09 PM Maxime Ripard  
> > wrote:
> > >
> > > The Allwinner SoCs have a MIPI-DSI and MIPI-D-PHY controllers supported in
> > > Linux, with a matching Device Tree binding.
> > >
> > > Now that we have the DT validation in place, let's convert the device tree
> > > bindings for that controller over to a YAML schemas.
> > >
> > > Signed-off-by: Maxime Ripard 
> >
> > Looks good to me. However not sure why you replaced the clock index macros
> > with raw numbers.
>
> The examples are compiled now, and unfortunately we can't use the
> defines at this point.

That was what I suspected. Thanks.
My Reviewed-by still stands.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/mediatek: add dsi module reset driver

[CK Hu]

Hi, Jitao:

On Sun, 2019-05-19 at 19:15 +0800, Jitao Shi wrote:
> Reset dsi HW to default when power on. Prevent the setting differet
> between bootloader and kernel.
> 
> Signed-off-by: Jitao Shi 
> ---
>  drivers/gpu/drm/mediatek/mtk_dsi.c | 35 ++
>  1 file changed, 35 insertions(+)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index b00eb2d2e086..39ccb34a7c7f 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -21,10 +21,12 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -146,6 +148,8 @@
>  #define T_HS_EXIT7
>  #define T_HS_ZERO10
>  
> +#define MMSYS_SW_RST_DSI_B BIT(25)
> +
>  #define NS_TO_CYCLE(n, c)((n) / (c) + (((n) % (c)) ? 1 : 0))
>  
>  #define MTK_DSI_HOST_IS_READ(type) \
> @@ -165,6 +169,8 @@ struct mtk_dsi {
>   struct drm_panel *panel;
>   struct drm_bridge *bridge;
>   struct phy *phy;
> + struct regmap *mmsys_sw_rst_b;
> + u32 sw_rst_b;
>  
>   void __iomem *regs;
>  
> @@ -238,6 +244,16 @@ static void mtk_dsi_disable(struct mtk_dsi *dsi)
>   mtk_dsi_mask(dsi, DSI_CON_CTRL, DSI_EN, 0);
>  }
>  
> +static void mtk_dsi_reset_all(struct mtk_dsi *dsi)
> +{
> + regmap_update_bits(dsi->mmsys_sw_rst_b, dsi->sw_rst_b,
> +MMSYS_SW_RST_DSI_B, ~MMSYS_SW_RST_DSI_B);
> + usleep_range(1000, 1100);
> +
> + regmap_update_bits(dsi->mmsys_sw_rst_b, dsi->sw_rst_b,
> +MMSYS_SW_RST_DSI_B, MMSYS_SW_RST_DSI_B);
> +}
> +
>  static void mtk_dsi_reset_engine(struct mtk_dsi *dsi)
>  {
>   mtk_dsi_mask(dsi, DSI_CON_CTRL, DSI_RESET, DSI_RESET);
> @@ -831,6 +847,8 @@ static int mtk_dsi_create_conn_enc(struct drm_device 
> *drm, struct mtk_dsi *dsi)
>   goto err_encoder_cleanup;
>   }
>  
> + mtk_dsi_reset_all(dsi);
> +
>   return 0;
>  
>  err_encoder_cleanup:
> @@ -1087,6 +1105,7 @@ static int mtk_dsi_probe(struct platform_device *pdev)
>   struct mtk_dsi *dsi;
>   struct device *dev = >dev;
>   struct resource *regs;
> + struct regmap *regmap;
>   int irq_num;
>   int comp_id;
>   int ret;
> @@ -1139,6 +1158,22 @@ static int mtk_dsi_probe(struct platform_device *pdev)
>   return ret;
>   }
>  
> + regmap = syscon_regmap_lookup_by_phandle(dev->of_node,
> +  "mediatek,syscon-dsi");

Where is the binding document for "mediatek,syscon-dsi"?

Regards,
CK

> + ret = of_property_read_u32_index(dev->of_node, "mediatek,syscon-dsi", 1,
> +  >sw_rst_b);
> +
> + if (IS_ERR(regmap))
> + ret = PTR_ERR(regmap);
> +
> + if (ret) {
> + ret = PTR_ERR(regmap);
> + dev_err(dev, "Failed to get mmsys registers: %d\n", ret);
> + return ret;
> + }
> +
> + dsi->mmsys_sw_rst_b = regmap;
> +
>   comp_id = mtk_ddp_comp_get_id(dev->of_node, MTK_DSI);
>   if (comp_id < 0) {
>   dev_err(dev, "Failed to identify by alias: %d\n", comp_id);


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

[git pull] drm fixes for 5.2-rc3

[Dave Airlie]

Hi Linus,

Nothing too crazy, pretty quiet, maybe too quiet.

amdgpu:
- a fixed version of the raven firmware fix we previously reverted,
- stolen memory fix

imx:
- regression fix

qxl:
- remove a bad warning.

etnaviv:
- VM locking fix.

Dave.

drm-fixes-2019-05-31:
drm etnaviv, imx, amdgpu fixes
The following changes since commit cd6c84d8f0cdc911df435bb075ba22ce3c605b07:

  Linux 5.2-rc2 (2019-05-26 16:49:19 -0700)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-05-31

for you to fetch changes up to 2a3e0b716296a504d9e65fea7acb379c86fe4283:

  Merge tag 'imx-drm-fixes-2019-05-29' of
git://git.pengutronix.de/git/pza/linux into drm-fixes (2019-05-31
09:15:25 +1000)


drm etnaviv, imx, amdgpu fixes


Dave Airlie (4):
  Merge branch 'etnaviv/fixes' of
https://git.pengutronix.de/git/lst/linux into drm-fixes
  Merge tag 'drm-misc-fixes-2019-05-29' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
  Merge branch 'drm-fixes-5.2' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes
  Merge tag 'imx-drm-fixes-2019-05-29' of
git://git.pengutronix.de/git/pza/linux into drm-fixes

Flora Cui (1):
  drm/amdgpu: reserve stollen vram for raven series

Gerd Hoffmann (1):
  drm/qxl: drop WARN_ONCE()

Harry Wentland (1):
  drm/amd/display: Don't load DMCU for Raven 1 (v2)

Lucas Stach (1):
  drm/etnaviv: lock MMU while dumping core

Philipp Zabel (1):
  drm/imx: ipuv3-plane: fix atomic update status query for non-plus i.MX6Q

 drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c |  3 +--
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 12 ++--
 drivers/gpu/drm/etnaviv/etnaviv_dump.c|  5 +
 drivers/gpu/drm/imx/ipuv3-plane.c | 13 -
 drivers/gpu/drm/imx/ipuv3-plane.h |  1 -
 drivers/gpu/drm/qxl/qxl_prime.c   |  1 -
 6 files changed, 24 insertions(+), 11 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 4/4] drm/panfrost: Expose performance counters through unstable ioctls

[kbuild test robot]

Hi Boris,

I love your patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on v5.2-rc2 next-20190530]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Boris-Brezillon/drm-panfrost-Expose-perf-counters-to-userspace/20190531-020136
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 7.4.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=arm 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot 

All warnings (new ones prefixed by >>):

   drivers/gpu//drm/panfrost/panfrost_perfcnt.c: In function 
'panfrost_ioctl_perfcnt_dump':
>> drivers/gpu//drm/panfrost/panfrost_perfcnt.c:224:26: warning: cast to 
>> pointer from integer of different size [-Wint-to-pointer-cast]
 void __user *user_ptr = (void __user *)req->buf_ptr;
 ^

vim +224 drivers/gpu//drm/panfrost/panfrost_perfcnt.c

   217  
   218  int panfrost_ioctl_perfcnt_dump(struct drm_device *dev, void *data,
   219  struct drm_file *file_priv)
   220  {
   221  struct panfrost_device *pfdev = dev->dev_private;
   222  struct panfrost_perfcnt *perfcnt = pfdev->perfcnt;
   223  struct drm_panfrost_perfcnt_dump *req = data;
 > 224  void __user *user_ptr = (void __user *)req->buf_ptr;
   225  int ret;
   226  
   227  ret = panfrost_unstable_ioctl_check();
   228  if (ret)
   229  return ret;
   230  
   231  mutex_lock(>lock);
   232  if (perfcnt->user != file_priv->driver_priv) {
   233  ret = -EINVAL;
   234  goto out;
   235  }
   236  
   237  ret = panfrost_perfcnt_dump_locked(pfdev);
   238  if (ret)
   239  goto out;
   240  
   241  if (copy_to_user(user_ptr, perfcnt->buf, perfcnt->bosize))
   242  ret = -EFAULT;
   243  
   244  out:
   245  mutex_unlock(>lock);
   246  
   247  return ret;
   248  }
   249  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 110117] Waking from Suspend causes screen to appear with grey static (like a TV with no signal)

[bugzilla-daemon]

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

--- Comment #12 from Craig  ---
yes i should mention most of my static is grey but there are colours in there
as well

-- 
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 110117] Waking from Suspend causes screen to appear with grey static (like a TV with no signal)

[bugzilla-daemon]

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

--- Comment #11 from leo60228  ---
I can reproduce on the same machine, but I get rainbow static, not grey.

-- 
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: [v3 6/7] drm/mediatek: change the dsi phytiming calculate method

[Ryan Case]

Hi Jitao,

On Sun, May 19, 2019 at 2:27 AM Jitao Shi  wrote:
>
> Change the method of frame rate calc which can get more accurate
> frame rate.
>
> data rate = pixel_clock * bit_per_pixel / lanes
> Adjust hfp_wc to adapt the additional phy_data
>
> if MIPI_DSI_MODE_VIDEO_BURST
> hfp_wc = hfp * bpp - data_phy_cycles * lanes - 12 - 6;
> else
> hfp_wc = hfp * bpp - data_phy_cycles * lanes - 12;
>
> Note:
> //(2: 1 for sync, 1 for phy idle)
> data_phy_cycles = T_hs_exit + T_lpx + T_hs_prepare + T_hs_zero + 2;
>
> bpp: bit per pixel
>
> Signed-off-by: Jitao Shi 
> ---
>  drivers/gpu/drm/mediatek/mtk_dsi.c | 119 +
>  1 file changed, 86 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 1165ff944889..3f51b2000c68 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -158,6 +158,25 @@
> (type == MIPI_DSI_GENERIC_READ_REQUEST_2_PARAM) || \
> (type == MIPI_DSI_DCS_READ))
>
> +struct mtk_phy_timing {
> +   u32 lpx;
> +   u32 da_hs_prepare;
> +   u32 da_hs_zero;
> +   u32 da_hs_trail;
> +
> +   u32 ta_go;
> +   u32 ta_sure;
> +   u32 ta_get;
> +   u32 da_hs_exit;
> +
> +   u32 clk_hs_zero;
> +   u32 clk_hs_trail;
> +
> +   u32 clk_hs_prepare;
> +   u32 clk_hs_post;
> +   u32 clk_hs_exit;
> +};
> +
>  struct phy;
>
>  struct mtk_dsi_driver_data {
> @@ -182,12 +201,13 @@ struct mtk_dsi {
> struct clk *digital_clk;
> struct clk *hs_clk;
>
> -   u32 data_rate;
> +   u64 data_rate;
>
> unsigned long mode_flags;
> enum mipi_dsi_pixel_format format;
> unsigned int lanes;
> struct videomode vm;
> +   struct mtk_phy_timing phy_timing;
> int refcount;
> bool enabled;
> u32 irq_data;
> @@ -221,17 +241,39 @@ static void mtk_dsi_phy_timconfig(struct mtk_dsi *dsi)
>  {
> u32 timcon0, timcon1, timcon2, timcon3;
> u32 ui, cycle_time;
> +   struct mtk_phy_timing *timing = >phy_timing;
> +
> +   ui = 10 / dsi->data_rate;
> +   cycle_time = 80 / dsi->data_rate;
> +
> +   timing->lpx = NS_TO_CYCLE(60, cycle_time);
> +   timing->da_hs_prepare = NS_TO_CYCLE((40 + 5 * ui), cycle_time);
> +   timing->da_hs_zero = NS_TO_CYCLE((110 + 6 * ui), cycle_time);
> +   timing->da_hs_trail = NS_TO_CYCLE(((0x4 * ui) + 80), cycle_time);
> +
> +   if (timing->da_hs_zero > timing->da_hs_prepare)
> +   timing->da_hs_zero -= timing->da_hs_prepare;

I don't follow why the above comparison and subtraction is necessary
when the values are being explicitly set immediately prior and it
seems to introduce a bug. Leftover from an early revision?

It looks like you've tuned the values such that hs_prepare+hs_zero are
just above the minimum requirements for that sum, however due to this
comparison and subtraction we wind up with a value of
hs_prepare+hs_zero-hs_prepare and fall below spec. Either boosting the
initial value set for hs_zero or removing the comparison makes display
happy again. Since I don't see any reason for the compare and subtract
I'd just drop that.

> +
> +   timing->ta_go = 4 * timing->lpx;
> +   timing->ta_sure = 3 * timing->lpx / 2;
> +   timing->ta_get = 5 * timing->lpx;
> +   timing->da_hs_exit = 2 * timing->lpx;
> +
> +   timing->clk_hs_zero = NS_TO_CYCLE(0x150, cycle_time);
> +   timing->clk_hs_trail = NS_TO_CYCLE(0x64, cycle_time) + 0xa;
>
> -   ui = 1000 / dsi->data_rate + 0x01;
> -   cycle_time = 8000 / dsi->data_rate + 0x01;
> +   timing->clk_hs_prepare = NS_TO_CYCLE(0x40, cycle_time);
> +   timing->clk_hs_post = NS_TO_CYCLE(80 + 52 * ui, cycle_time);
> +   timing->clk_hs_exit = 2 * timing->lpx;

There is a lot of alternating between hex and decimal values in this
function which makes it a little hard to follow. Would be nice to
stick to one or the other.

>
> -   timcon0 = T_LPX | T_HS_PREP << 8 | T_HS_ZERO << 16 | T_HS_TRAIL << 24;
> -   timcon1 = 4 * T_LPX | (3 * T_LPX / 2) << 8 | 5 * T_LPX << 16 |
> - T_HS_EXIT << 24;
> -   timcon2 = ((NS_TO_CYCLE(0x64, cycle_time) + 0xa) << 24) |
> - (NS_TO_CYCLE(0x150, cycle_time) << 16);
> -   timcon3 = NS_TO_CYCLE(0x40, cycle_time) | (2 * T_LPX) << 16 |
> - NS_TO_CYCLE(80 + 52 * ui, cycle_time) << 8;
> +   timcon0 = timing->lpx | timing->da_hs_prepare << 8 |
> + timing->da_hs_zero << 16 | timing->da_hs_trail << 24;
> +   timcon1 = timing->ta_go | timing->ta_sure << 8 |
> + timing->ta_get << 16 | timing->da_hs_exit << 24;
> +   timcon2 = 1 << 8 | timing->clk_hs_zero << 16 |
> + timing->clk_hs_trail << 24;
> +   timcon3 = timing->clk_hs_prepare | timing->clk_hs_post << 8 |
> + timing->clk_hs_exit << 16;
>
> 

Re: [PATCH] dt-bindings: display: Convert Allwinner DSI to a schema

[Maxime Ripard]

Hi,

On Thu, May 30, 2019 at 09:48:02PM +0800, Chen-Yu Tsai wrote:
> On Mon, May 27, 2019 at 8:09 PM Maxime Ripard  
> wrote:
> >
> > The Allwinner SoCs have a MIPI-DSI and MIPI-D-PHY controllers supported in
> > Linux, with a matching Device Tree binding.
> >
> > Now that we have the DT validation in place, let's convert the device tree
> > bindings for that controller over to a YAML schemas.
> >
> > Signed-off-by: Maxime Ripard 
>
> Looks good to me. However not sure why you replaced the clock index macros
> with raw numbers.

The examples are compiled now, and unfortunately we can't use the
defines at this point.

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


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

Re: [PATCH v10 02/11] drm/sun4i: dsi: Update start value in video start delay

[Maxime Ripard]

On Fri, May 24, 2019 at 03:55:42PM +0530, Jagan Teki wrote:
> On Fri, May 24, 2019 at 2:07 AM Maxime Ripard  
> wrote:
> >
> > On Mon, May 20, 2019 at 02:33:09PM +0530, Jagan Teki wrote:
> > > start value in video start delay computation done in below commit
> > > is as per the legacy bsp drivers/video/sunxi/legacy..
> > > "drm/sun4i: dsi: Change the start delay calculation"
> > > (sha1: da676c6aa6413d59ab0a80c97bbc273025e640b2)
> > >
> > > This existing start delay computation gives start value of 35,
> > > for "bananapi,s070wv20-ct16" panel timings which indeed trigger
> > > panel flip_done timed out as:
> > >
> > >  WARNING: CPU: 0 PID: 31 at drivers/gpu/drm/drm_atomic_helper.c:1429 
> > > drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0
> > >  [CRTC:46:crtc-0] vblank wait timed out
> > >  Modules linked in:
> > >  CPU: 0 PID: 31 Comm: kworker/0:1 Tainted: GW 
> > > 5.1.0-next-20190514-00025-gf928bc7cc146 #15
> > >  Hardware name: Allwinner sun8i Family
> > >  Workqueue: events deferred_probe_work_func
> > >  [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
> > >  [] (show_stack) from [] (dump_stack+0x84/0x98)
> > >  [] (dump_stack) from [] (__warn+0xfc/0x114)
> > >  [] (__warn) from [] (warn_slowpath_fmt+0x44/0x68)
> > >  [] (warn_slowpath_fmt) from [] 
> > > (drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0)
> > >  [] (drm_atomic_helper_wait_for_vblanks.part.1) from 
> > > [] (drm_atomic_helper_commit_tail_rpm+0x5c/0x6c)
> > >  [] (drm_atomic_helper_commit_tail_rpm) from [] 
> > > (commit_tail+0x40/0x6c)
> > >  [] (commit_tail) from [] 
> > > (drm_atomic_helper_commit+0xbc/0x128)
> > >  [] (drm_atomic_helper_commit) from [] 
> > > (restore_fbdev_mode_atomic+0x1cc/0x1dc)
> > >  [] (restore_fbdev_mode_atomic) from [] 
> > > (drm_fb_helper_pan_display+0xac/0x1d0)
> > >  [] (drm_fb_helper_pan_display) from [] 
> > > (fb_pan_display+0xcc/0x134)
> > >  [] (fb_pan_display) from [] 
> > > (bit_update_start+0x14/0x30)
> > >  [] (bit_update_start) from [] 
> > > (fbcon_switch+0x3d8/0x4e0)
> > >  [] (fbcon_switch) from [] (redraw_screen+0x174/0x238)
> > >  [] (redraw_screen) from [] 
> > > (fbcon_prepare_logo+0x3c4/0x400)
> > >  [] (fbcon_prepare_logo) from [] 
> > > (fbcon_init+0x3c8/0x5ac)
> > >  [] (fbcon_init) from [] (visual_init+0xbc/0x104)
> > >  [] (visual_init) from [] 
> > > (do_bind_con_driver+0x1b0/0x390)
> > >  [] (do_bind_con_driver) from [] 
> > > (do_take_over_console+0x13c/0x1c4)
> > >  [] (do_take_over_console) from [] 
> > > (do_fbcon_takeover+0x74/0xcc)
> > >  [] (do_fbcon_takeover) from [] 
> > > (notifier_call_chain+0x44/0x84)
> > >  [] (notifier_call_chain) from [] 
> > > (__blocking_notifier_call_chain+0x48/0x60)
> > >  [] (__blocking_notifier_call_chain) from [] 
> > > (blocking_notifier_call_chain+0x18/0x20)
> > >  [] (blocking_notifier_call_chain) from [] 
> > > (register_framebuffer+0x1e0/0x2f8)
> > >  [] (register_framebuffer) from [] 
> > > (__drm_fb_helper_initial_config_and_unlock+0x2fc/0x50c)
> > >  [] (__drm_fb_helper_initial_config_and_unlock) from 
> > > [] (drm_fbdev_client_hotplug+0xe8/0x1b8)
> > >  [] (drm_fbdev_client_hotplug) from [] 
> > > (drm_fbdev_generic_setup+0x88/0x118)
> > >  [] (drm_fbdev_generic_setup) from [] 
> > > (sun4i_drv_bind+0x128/0x160)
> > >  [] (sun4i_drv_bind) from [] 
> > > (try_to_bring_up_master+0x164/0x1a0)
> > >  [] (try_to_bring_up_master) from [] 
> > > (__component_add+0x94/0x140)
> > >  [] (__component_add) from [] 
> > > (sun6i_dsi_probe+0x144/0x234)
> > >  [] (sun6i_dsi_probe) from [] 
> > > (platform_drv_probe+0x48/0x9c)
> > >  [] (platform_drv_probe) from [] 
> > > (really_probe+0x1dc/0x2c8)
> > >  [] (really_probe) from [] 
> > > (driver_probe_device+0x60/0x160)
> > >  [] (driver_probe_device) from [] 
> > > (bus_for_each_drv+0x74/0xb8)
> > >  [] (bus_for_each_drv) from [] 
> > > (__device_attach+0xd0/0x13c)
> > >  [] (__device_attach) from [] 
> > > (bus_probe_device+0x84/0x8c)
> > >  [] (bus_probe_device) from [] 
> > > (deferred_probe_work_func+0x64/0x90)
> > >  [] (deferred_probe_work_func) from [] 
> > > (process_one_work+0x204/0x420)
> > >  [] (process_one_work) from [] 
> > > (worker_thread+0x274/0x5a0)
> > >  [] (worker_thread) from [] (kthread+0x11c/0x14c)
> > >  [] (kthread) from [] (ret_from_fork+0x14/0x2c)
> > >  Exception stack(0xde539fb0 to 0xde539ff8)
> > >  9fa0:    
> > > 
> > >  9fc0:        
> > > 
> > >  9fe0:     0013 
> > >  ---[ end trace 755e10f62b83f396 ]---
> > >  Console: switching to colour frame buffer device 100x30
> > >  [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC:46:crtc-0] 
> > > flip_done timed out
> > >  [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* 
> > > [CONNECTOR:48:DSI-1] flip_done timed out
> > >  [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [PLANE:30:plane-0] 

Re: [PATCH 2/7] drm/dp_mst: Register AUX devices for MST ports

[Li, Sun peng (Leo)]

Hey, sorry for my late response!

On 2019-05-16 5:40 p.m., Lyude Paul wrote:

>>if (old_pdt != port->pdt && !port->input) {
>> @@ -1220,6 +1268,8 @@ static void drm_dp_add_port(struct drm_dp_mst_branch
>> *mstb,
>>drm_connector_set_tile_property(port->connector);
>>}
>>(*mstb->mgr->cbs->register_connector)(port->connector);
> This is wrong: we always want to setup everything in the connector first
> before trying to register it, not after. Otherwise, things explode like so:

**snip**

> [  452.424461] [ cut here ]
> [  452.424464] sysfs group 'power' not found for kobject 'drm_dp_aux5'
> [  452.424471] WARNING: CPU: 3 PID: 1887 at fs/sysfs/group.c:256 
> sysfs_remove_group+0x76/0x80
> [  452.424473] Modules linked in: vfat fat elan_i2c i915(O) intel_rapl 
> x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel iTCO_wdt kvm mei_wdt 
> irqbypass iTCO_vendor_support crct10dif_pclmul wmi_bmof intel_wmi_thunderbolt 
> crc32_pclmul i2c_algo_bit ghash_clmulni_intel intel_cstate drm_kms_helper(O) 
> intel_uncore intel_rapl_perf btusb btrtl btbcm syscopyarea btintel 
> sysfillrect sysimgblt fb_sys_fops bluetooth drm(O) joydev mei_me idma64 
> ucsi_acpi thunderbolt ecdh_generic i2c_i801 intel_xhci_usb_role_switch 
> processor_thermal_device typec_ucsi intel_lpss_pci intel_soc_dts_iosf mei 
> roles intel_lpss typec intel_pch_thermal wmi thinkpad_acpi ledtrig_audio 
> rfkill int3403_thermal int340x_thermal_zone int3400_thermal acpi_thermal_rel 
> acpi_pad video pcc_cpufreq crc32c_intel nvme serio_raw uas e1000e nvme_core 
> usb_storage i2c_dev
> [  452.424492] CPU: 3 PID: 1887 Comm: unloadgpumod Tainted: G   O 
>  5.1.0Lyude-Test+ #1
> [  452.424494] Hardware name: LENOVO 20L8S2N800/20L8S2N800, BIOS N22ET35W 
> (1.12 ) 04/09/2018
> [  452.424496] RIP: 0010:sysfs_remove_group+0x76/0x80
> [  452.424498] Code: 48 89 df 5b 5d 41 5c e9 f8 bc ff ff 48 89 df e8 d0 bc ff 
> ff eb cb 49 8b 14 24 48 8b 75 00 48 c7 c7 08 a5 0c aa e8 44 00 d6 ff <0f> 0b 
> 5b 5d 41 5c c3 0f 1f 00 0f 1f 44 00 00 48 85 f6 74 31 41 54
> [  452.424500] RSP: 0018:a8bb81b5fb28 EFLAGS: 00010282
> [  452.424501] RAX:  RBX:  RCX: 
> 0006
> [  452.424502] RDX: 0007 RSI: 0086 RDI: 
> 981fde2d5a00
> [  452.424503] RBP: a9ea12e0 R08: 0792 R09: 
> 0046
> [  452.424504] R10: 0727 R11: a8bb81b5f9d0 R12: 
> 981fd5f77010
> [  452.424505] R13: 981fd6ebbedc R14: dead0200 R15: 
> dead0100
> [  452.424507] FS:  7f8cc1d8c740() GS:981fde2c() 
> knlGS:
> [  452.424508] CS:  0010 DS:  ES:  CR0: 80050033
> [  452.424509] CR2: 55b19d079a08 CR3: 00043b2a0002 CR4: 
> 003606e0
> [  452.424510] DR0:  DR1:  DR2: 
> 
> [  452.424511] DR3:  DR6: fffe0ff0 DR7: 
> 0400
> [  452.424512] Call Trace:
> [  452.424516]  device_del+0x75/0x360
> [  452.424518]  ? class_find_device+0x96/0xf0
> [  452.424520]  device_unregister+0x16/0x60
> [  452.424521]  device_destroy+0x3a/0x40
> [  452.424525]  drm_dp_aux_unregister_devnode+0xea/0x180 [drm_kms_helper]
> [  452.424534]  ? drm_dbg+0x87/0x90 [drm]
> [  452.424538]  drm_dp_mst_topology_put_port+0x5b/0x110 [drm_kms_helper]
> [  452.424543]  drm_dp_mst_topology_put_mstb+0xb6/0x180 [drm_kms_helper]
> [  452.424547]  drm_dp_mst_topology_mgr_set_mst+0x233/0x2b0 [drm_kms_helper]
> [  452.424551]  drm_dp_mst_topology_mgr_destroy+0x18/0xa0 [drm_kms_helper]
> [  452.424571]  intel_dp_encoder_flush_work+0x32/0xb0 [i915]
> [  452.424592]  intel_ddi_encoder_destroy+0x32/0x70 [i915]
> [  452.424600]  drm_mode_config_cleanup+0x51/0x2e0 [drm]
> [  452.424621]  intel_modeset_cleanup+0xc8/0x140 [i915]
> [  452.424633]  i915_driver_unload+0xa8/0x130 [i915]
> [  452.424645]  i915_pci_remove+0x1e/0x40 [i915]
> [  452.424647]  pci_device_remove+0x3b/0xc0
> [  452.424649]  device_release_driver_internal+0xe4/0x1d0
> [  452.424651]  pci_stop_bus_device+0x69/0x90
> [  452.424653]  pci_stop_and_remove_bus_device_locked+0x16/0x30
> [  452.424655]  remove_store+0x75/0x90
> [  452.424656]  kernfs_fop_write+0x116/0x190
> [  452.424658]  vfs_write+0xa5/0x1a0
> [  452.424660]  ksys_write+0x57/0xd0
> [  452.424663]  do_syscall_64+0x55/0x150
> [  452.424665]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> [  452.424667] RIP: 0033:0x7f8cc1e7d038
> [  452.424668] Code: 89 02 48 c7 c0 ff ff ff ff eb b3 0f 1f 80 00 00 00 00 f3 
> 0f 1e fa 48 8d 05 e5 76 0d 00 8b 00 85 c0 75 17 b8 01 00 00 00 0f 05 <48> 3d 
> 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 41 54 49 89 d4 55
> [  452.424670] RSP: 002b:7ffce4321218 EFLAGS: 0246 ORIG_RAX: 
> 0001
> [  452.424672] RAX: ffda RBX: 0002 RCX: 
> 7f8cc1e7d038
> [  452.424673] RDX: 0002 RSI: 

[Bug 110721] graphics corruption on steam client with mesa 19.1.0 rc3 on polaris

[bugzilla-daemon]

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

alvarex  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED
Version|19.0|19.1

--- Comment #20 from alvarex  ---
this is fixed on 19.1.0-rc4 closing, the bug is still pending an update to the
19.0 stable branch

-- 
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 110674] Crashes / Resets From AMDGPU / Radeon VII

[bugzilla-daemon]

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

--- Comment #32 from Tom B  ---
This is still an issue in 5.1.5. It seems slightly more stable but I'm still
getting the high power usage and no boost clocks. 

On a successful boot I see the following in dmesg:



[3.628369] [drm] amdgpu: 16368M of VRAM memory ready
[3.628371] [drm] amdgpu: 16368M of GTT memory ready.
[3.629241] amdgpu :44:00.0: Direct firmware load for
amdgpu/vega20_ta.bin failed with error -2
[3.629243] amdgpu :44:00.0: psp v11.0: Failed to load firmware
"amdgpu/vega20_ta.bin"
[4.260631] fbcon: amdgpudrmfb (fb0) is primary device
[4.376861] amdgpu :44:00.0: fb0: amdgpudrmfb frame buffer device
[4.410360] amdgpu :44:00.0: ring gfx uses VM inv eng 0 on hub 0
[4.410363] amdgpu :44:00.0: ring comp_1.0.0 uses VM inv eng 1 on hub 0
[4.410365] amdgpu :44:00.0: ring comp_1.1.0 uses VM inv eng 4 on hub 0
[4.410367] amdgpu :44:00.0: ring comp_1.2.0 uses VM inv eng 5 on hub 0
[4.410369] amdgpu :44:00.0: ring comp_1.3.0 uses VM inv eng 6 on hub 0
[4.410371] amdgpu :44:00.0: ring comp_1.0.1 uses VM inv eng 7 on hub 0
[4.410372] amdgpu :44:00.0: ring comp_1.1.1 uses VM inv eng 8 on hub 0
[4.410374] amdgpu :44:00.0: ring comp_1.2.1 uses VM inv eng 9 on hub 0
[4.410376] amdgpu :44:00.0: ring comp_1.3.1 uses VM inv eng 10 on hub 0
[4.410378] amdgpu :44:00.0: ring kiq_2.1.0 uses VM inv eng 11 on hub 0
[4.410380] amdgpu :44:00.0: ring sdma0 uses VM inv eng 0 on hub 1
[4.410382] amdgpu :44:00.0: ring page0 uses VM inv eng 1 on hub 1
[4.410383] amdgpu :44:00.0: ring sdma1 uses VM inv eng 4 on hub 1
[4.410385] amdgpu :44:00.0: ring page1 uses VM inv eng 5 on hub 1
[4.410386] amdgpu :44:00.0: ring uvd_0 uses VM inv eng 6 on hub 1
[4.410388] amdgpu :44:00.0: ring uvd_enc_0.0 uses VM inv eng 7 on hub 1
[4.410390] amdgpu :44:00.0: ring uvd_enc_0.1 uses VM inv eng 8 on hub 1
[4.410391] amdgpu :44:00.0: ring uvd_1 uses VM inv eng 9 on hub 1
[4.410392] amdgpu :44:00.0: ring uvd_enc_1.0 uses VM inv eng 10 on hub
1
[4.410393] amdgpu :44:00.0: ring uvd_enc_1.1 uses VM inv eng 11 on hub
1
[4.410394] amdgpu :44:00.0: ring vce0 uses VM inv eng 12 on hub 1
[4.410396] amdgpu :44:00.0: ring vce1 uses VM inv eng 13 on hub 1
[4.410397] amdgpu :44:00.0: ring vce2 uses VM inv eng 14 on hub 1
[5.088344] [drm] Initialized amdgpu 3.30.0 20150101 for :44:00.0 on
minor 0
[5.247245] amdgpu: [powerplay] Failed to send message 0x28, response 0x0
[5.247247] amdgpu: [powerplay] [SetUclkToHightestDpmLevel] Set hard min
uclk failed!
[6.092850] amdgpu: [powerplay] Failed to send message 0x28, response 0x0
[6.092851] amdgpu: [powerplay] Attempt to set Hard Min for DCEFCLK Failed!
[6.939351] amdgpu: [powerplay] Failed to send message 0x28, response 0x0
[6.939351] amdgpu: [powerplay] [SetHardMinFreq] Set hard min uclk failed!
[7.784543] amdgpu: [powerplay] Failed to send message 0x26, response 0x0
[7.784544] amdgpu: [powerplay] Failed to set soft min gfxclk !
[7.784545] amdgpu: [powerplay] Failed to upload DPM Bootup Levels!
[7.842345] amdgpu: [powerplay] Failed to send message 0x28, response 0xff
[8.143759] amdgpu: [powerplay] Failed to send message 0x28, response 0xff
[8.143761] amdgpu: [powerplay] Attempt to set Hard Min for DCEFCLK Failed!
[8.159090] amdgpu: [powerplay] Failed to send message 0x26, response 0xff
[8.159091] amdgpu: [powerplay] Failed to set soft min socclk!
[8.159092] amdgpu: [powerplay] Failed to upload DPM Bootup Levels!
[8.245063] amdgpu: [powerplay] Failed to send message 0x28, response 0xff
[8.825759] amdgpu: [powerplay] Failed to send message 0x28, response 0xff
[8.825760] amdgpu: [powerplay] Attempt to set Hard Min for DCEFCLK Failed!
[8.825919] amdgpu: [powerplay] Failed to send message 0x26, response 0xff
[8.825919] amdgpu: [powerplay] Failed to set soft min socclk!
[8.825920] amdgpu: [powerplay] Failed to upload DPM Bootup Levels!
[8.826116] amdgpu: [powerplay] Failed to send message 0x28, response 0xff
[8.842518] amdgpu: [powerplay] Failed to send message 0x28, response 0xff
[8.842519] amdgpu: [powerplay] Attempt to set Hard Min for DCEFCLK Failed!
[8.842691] amdgpu: [powerplay] Failed to send message 0x26, response 0xff
[8.842692] amdgpu: [powerplay] Failed to set soft min socclk!
[8.842692] amdgpu: [powerplay] Failed to upload DPM Bootup Levels!
[8.885751] amdgpu: [powerplay] Failed to send message 0x28, response 0xff
[8.892421] amdgpu: [powerplay] Failed to send message 0x28, response 0xff
[8.892422] amdgpu: [powerplay] Attempt to set Hard Min for DCEFCLK Failed!
[8.892614] amdgpu: [powerplay] Failed to send message 0x26, response 0xff
[8.892614] amdgpu: [powerplay] Failed to set soft min socclk!
[

[PATCH][next] drm/amd/display: remove redundant assignment to status

[Colin King]

From: Colin Ian King 

The variable status is initialized with a value that is never read
and status is reassigned several statements later. This initialization
is redundant and can be removed.

Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
index 65d6caedbd82..cf6166a1be53 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
@@ -2367,7 +2367,7 @@ static bool retrieve_link_cap(struct dc_link *link)
union down_stream_port_count down_strm_port_count;
union edp_configuration_cap edp_config_cap;
union dp_downstream_port_present ds_port = { 0 };
-   enum dc_status status = DC_ERROR_UNEXPECTED;
+   enum dc_status status;
uint32_t read_dpcd_retry_cnt = 3;
int i;
struct dp_sink_hw_fw_revision dp_hw_fw_revision;
-- 
2.20.1

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

[PATCH 4/4] drm/msm/dsi: Add support for MSM8998 DSI controller

[Jeffrey Hugo]

The DSI controller on the MSM8998 SoC is a 6G v2.0.0 controller which is
very similar to the v2.0.1 of SDM845.

Signed-off-by: Jeffrey Hugo 
---
 drivers/gpu/drm/msm/dsi/dsi_cfg.c | 21 +
 drivers/gpu/drm/msm/dsi/dsi_cfg.h |  1 +
 2 files changed, 22 insertions(+)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.c 
b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
index dcdfb1bb54f9..7dd17b59c69d 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
@@ -118,6 +118,25 @@ static const struct msm_dsi_config msm8996_dsi_cfg = {
.num_dsi = 2,
 };
 
+static const char * const dsi_msm8998_bus_clk_names[] = {
+   "iface", "bus", "core",
+};
+
+static const struct msm_dsi_config msm8998_dsi_cfg = {
+   .io_offset = DSI_6G_REG_SHIFT,
+   .reg_cfg = {
+   .num = 2,
+   .regs = {
+   {"vdd", 367000, 16 },   /* 0.9 V */
+   {"vdda", 62800, 2 },/* 1.2 V */
+   },
+   },
+   .bus_clk_names = dsi_msm8998_bus_clk_names,
+   .num_bus_clks = ARRAY_SIZE(dsi_msm8998_bus_clk_names),
+   .io_start = { 0xc994000, 0xc996000 },
+   .num_dsi = 2,
+};
+
 static const char * const dsi_sdm845_bus_clk_names[] = {
"iface", "bus",
 };
@@ -186,6 +205,8 @@ static const struct msm_dsi_cfg_handler dsi_cfg_handlers[] 
= {
_dsi_cfg, _dsi_6g_host_ops},
{MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_4_1,
_dsi_cfg, _dsi_6g_host_ops},
+   {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V2_2_0,
+   _dsi_cfg, _dsi_6g_v2_host_ops},
{MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V2_2_1,
_dsi_cfg, _dsi_6g_v2_host_ops},
 };
diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.h 
b/drivers/gpu/drm/msm/dsi/dsi_cfg.h
index 16c50790..4f63b57b19dc 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_cfg.h
+++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.h
@@ -25,6 +25,7 @@
 #define MSM_DSI_6G_VER_MINOR_V1_3  0x1003
 #define MSM_DSI_6G_VER_MINOR_V1_3_10x10030001
 #define MSM_DSI_6G_VER_MINOR_V1_4_10x10040001
+#define MSM_DSI_6G_VER_MINOR_V2_2_00x2000
 #define MSM_DSI_6G_VER_MINOR_V2_2_10x20020001
 
 #define MSM_DSI_V2_VER_MINOR_8064  0x0
-- 
2.17.1

[PATCH 3/4] drm/msm/dsi: Add old timings quirk for 10nm phy

[Jeffrey Hugo]

The v3.0.0 10nm phy has two different implementations between MSM8998 and
SDM845, which require different timings calculations.  Unfortunately, the
hardware designers did not choose to revise the version to account for this
delta so implement a quirk instead.

Signed-off-by: Jeffrey Hugo 
---
 drivers/gpu/drm/msm/dsi/phy/dsi_phy.h  |  4 
 drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c | 12 +---
 2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h 
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
index 7161beb23b03..3c51df1aa2ee 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
@@ -21,6 +21,9 @@
 #define dsi_phy_read(offset) msm_readl((offset))
 #define dsi_phy_write(offset, data) msm_writel((data), (offset))
 
+/* v3.0.0 10nm implementation that requires the old timings settings */
+#define V3_0_0_10NM_OLD_TIMINGS_QUIRK  BIT(0)
+
 struct msm_dsi_phy_ops {
int (*init) (struct msm_dsi_phy *phy);
int (*enable)(struct msm_dsi_phy *phy, int src_pll_id,
@@ -41,6 +44,7 @@ struct msm_dsi_phy_cfg {
bool src_pll_truthtable[DSI_MAX][DSI_MAX];
const resource_size_t io_start[DSI_MAX];
const int num_dsi_phy;
+   const int quirks;
 };
 
 extern const struct msm_dsi_phy_cfg dsi_phy_28nm_hpm_cfgs;
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c 
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
index b1e7dbc69fa6..eb28937f4b34 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
@@ -42,6 +42,9 @@ static void dsi_phy_hw_v3_0_lane_settings(struct msm_dsi_phy 
*phy)
u8 tx_dctrl[] = { 0x00, 0x00, 0x00, 0x04, 0x01 };
void __iomem *lane_base = phy->lane_base;
 
+   if (phy->cfg->quirks & V3_0_0_10NM_OLD_TIMINGS_QUIRK)
+   tx_dctrl[3] = 0x02;
+
/* Strength ctrl settings */
for (i = 0; i < 5; i++) {
dsi_phy_write(lane_base + REG_DSI_10nm_PHY_LN_LPTX_STR_CTRL(i),
@@ -74,9 +77,11 @@ static void dsi_phy_hw_v3_0_lane_settings(struct msm_dsi_phy 
*phy)
  tx_dctrl[i]);
}
 
-   /* Toggle BIT 0 to release freeze I/0 */
-   dsi_phy_write(lane_base + REG_DSI_10nm_PHY_LN_TX_DCTRL(3), 0x05);
-   dsi_phy_write(lane_base + REG_DSI_10nm_PHY_LN_TX_DCTRL(3), 0x04);
+   if (!phy->cfg->quirks & V3_0_0_10NM_OLD_TIMINGS_QUIRK) {
+   /* Toggle BIT 0 to release freeze I/0 */
+   dsi_phy_write(lane_base + REG_DSI_10nm_PHY_LN_TX_DCTRL(3), 
0x05);
+   dsi_phy_write(lane_base + REG_DSI_10nm_PHY_LN_TX_DCTRL(3), 
0x04);
+   }
 }
 
 static int dsi_10nm_phy_enable(struct msm_dsi_phy *phy, int src_pll_id,
@@ -238,4 +243,5 @@ const struct msm_dsi_phy_cfg dsi_phy_10nm_8998_cfgs = {
},
.io_start = { 0xc994400, 0xc996400 },
.num_dsi_phy = 2,
+   .quirks = V3_0_0_10NM_OLD_TIMINGS_QUIRK,
 };
-- 
2.17.1

[PATCH 2/4] drm/msm/dsi: Add support for MSM8998 10nm dsi phy

[Jeffrey Hugo]

The MSM8998 dsi phy is 10nm v3.0.0 like SDM845, however there appear to
be minor differences such as the address space location.

Signed-off-by: Jeffrey Hugo 
---
 drivers/gpu/drm/msm/dsi/phy/dsi_phy.c  |  2 ++
 drivers/gpu/drm/msm/dsi/phy/dsi_phy.h  |  1 +
 drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c | 18 ++
 3 files changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c 
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
index 1760483b247e..fda73749fcc0 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
@@ -507,6 +507,8 @@ static const struct of_device_id dsi_phy_dt_match[] = {
 #ifdef CONFIG_DRM_MSM_DSI_10NM_PHY
{ .compatible = "qcom,dsi-phy-10nm",
  .data = _phy_10nm_cfgs },
+   { .compatible = "qcom,dsi-phy-10nm-8998",
+ .data = _phy_10nm_8998_cfgs },
 #endif
{}
 };
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h 
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
index a24ab80994a3..7161beb23b03 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
@@ -49,6 +49,7 @@ extern const struct msm_dsi_phy_cfg dsi_phy_20nm_cfgs;
 extern const struct msm_dsi_phy_cfg dsi_phy_28nm_8960_cfgs;
 extern const struct msm_dsi_phy_cfg dsi_phy_14nm_cfgs;
 extern const struct msm_dsi_phy_cfg dsi_phy_10nm_cfgs;
+extern const struct msm_dsi_phy_cfg dsi_phy_10nm_8998_cfgs;
 
 struct msm_dsi_dphy_timing {
u32 clk_pre;
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c 
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
index 44959e79ce28..b1e7dbc69fa6 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
@@ -221,3 +221,21 @@ const struct msm_dsi_phy_cfg dsi_phy_10nm_cfgs = {
.io_start = { 0xae94400, 0xae96400 },
.num_dsi_phy = 2,
 };
+
+const struct msm_dsi_phy_cfg dsi_phy_10nm_8998_cfgs = {
+   .type = MSM_DSI_PHY_10NM,
+   .src_pll_truthtable = { {false, false}, {true, false} },
+   .reg_cfg = {
+   .num = 1,
+   .regs = {
+   {"vdds", 36000, 32},
+   },
+   },
+   .ops = {
+   .enable = dsi_10nm_phy_enable,
+   .disable = dsi_10nm_phy_disable,
+   .init = dsi_10nm_phy_init,
+   },
+   .io_start = { 0xc994400, 0xc996400 },
+   .num_dsi_phy = 2,
+};
-- 
2.17.1

[PATCH 1/4] dt-bindings: msm/dsi: Add 10nm phy for msm8998 compatible

[Jeffrey Hugo]

The DSI phy on MSM8998 is a 10nm design like SDM845, however it has some
slightly different quirks which need to be handled by drivers.  Provide
a separate compatible to assist in handling the specifics.

Signed-off-by: Jeffrey Hugo 
---
 Documentation/devicetree/bindings/display/msm/dsi.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt 
b/Documentation/devicetree/bindings/display/msm/dsi.txt
index 9ae946942720..af95586c898f 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi.txt
+++ b/Documentation/devicetree/bindings/display/msm/dsi.txt
@@ -88,6 +88,7 @@ Required properties:
   * "qcom,dsi-phy-28nm-8960"
   * "qcom,dsi-phy-14nm"
   * "qcom,dsi-phy-10nm"
+  * "qcom,dsi-phy-10nm-8998"
 - reg: Physical base address and length of the registers of PLL, PHY. Some
   revisions require the PHY regulator base address, whereas others require the
   PHY lane base address. See below for each PHY revision.
-- 
2.17.1

[PATCH 0/4] MSM8998 DSI support

[Jeffrey Hugo]

Enabling DSI support for the MSM8998 SoC is another step to getting end
to end display going.  This will allow the SoC to drive panels that are
integraded on the device (ie not a HDMI port), but won't do much until
we have the display processor feeding the DSI blocks with lines to
scanout.

Jeffrey Hugo (4):
  dt-bindings: msm/dsi: Add 10nm phy for msm8998 compatible
  drm/msm/dsi: Add support for MSM8998 10nm dsi phy
  drm/msm/dsi: Add old timings quirk for 10nm phy
  drm/msm/dsi: Add support for MSM8998 DSI controller

 .../devicetree/bindings/display/msm/dsi.txt   |  1 +
 drivers/gpu/drm/msm/dsi/dsi_cfg.c | 21 +
 drivers/gpu/drm/msm/dsi/dsi_cfg.h |  1 +
 drivers/gpu/drm/msm/dsi/phy/dsi_phy.c |  2 ++
 drivers/gpu/drm/msm/dsi/phy/dsi_phy.h |  5 
 drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c| 30 +--
 6 files changed, 57 insertions(+), 3 deletions(-)

-- 
2.17.1

Re: [PATCH] drm/nouveau: Fix DEVICE_PRIVATE dependencies

[Jason Gunthorpe]

On Thu, May 30, 2019 at 11:31:12PM +0800, Yuehaibing wrote:
> Hi all,
> 
> Friendly ping:
> 
> Who can take this?
> 
> On 2019/4/17 22:26, Yue Haibing wrote:
> > From: YueHaibing 
> > 
> > During randconfig builds, I occasionally run into an invalid configuration
> > 
> > WARNING: unmet direct dependencies detected for DEVICE_PRIVATE
> >   Depends on [n]: ARCH_HAS_HMM_DEVICE [=n] && ZONE_DEVICE [=n]
> >   Selected by [y]:
> >   - DRM_NOUVEAU_SVM [=y] && HAS_IOMEM [=y] && ARCH_HAS_HMM [=y] && 
> > DRM_NOUVEAU [=y] && STAGING [=y]
> > 
> > mm/memory.o: In function `do_swap_page':
> > memory.c:(.text+0x2754): undefined reference to `device_private_entry_fault'
> > 
> > commit 5da25090ab04 ("mm/hmm: kconfig split HMM address space mirroring 
> > from device memory")
> > split CONFIG_DEVICE_PRIVATE dependencies from
> > ARCH_HAS_HMM to ARCH_HAS_HMM_DEVICE and ZONE_DEVICE,
> > so enable DRM_NOUVEAU_SVM will trigger this warning,
> > cause building failed.
> > 
> > Reported-by: Hulk Robot 
> > Fixes: 5da25090ab04 ("mm/hmm: kconfig split HMM address space mirroring 
> > from device memory")
> > Signed-off-by: YueHaibing 
> >  drivers/gpu/drm/nouveau/Kconfig | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/nouveau/Kconfig 
> > b/drivers/gpu/drm/nouveau/Kconfig
> > index 00cd9ab..99e30c1 100644
> > +++ b/drivers/gpu/drm/nouveau/Kconfig
> > @@ -74,7 +74,8 @@ config DRM_NOUVEAU_BACKLIGHT
> >  
> >  config DRM_NOUVEAU_SVM
> > bool "(EXPERIMENTAL) Enable SVM (Shared Virtual Memory) support"
> > -   depends on ARCH_HAS_HMM
> > +   depends on ARCH_HAS_HMM_DEVICE
> > +   depends on ZONE_DEVICE
> > depends on DRM_NOUVEAU
> > depends on STAGING
> > select HMM_MIRROR
> > 

I'm expecting to take a patch like this into the new hmm git tree once
Jerome sends his Final Solution for the kconfig problems.

Maybe it is this patch, Jerome??

Regards,
Jason 

Re: [PATCH] drm/nouveau: Fix DEVICE_PRIVATE dependencies

[Yuehaibing]

Hi all,

Friendly ping:

Who can take this?

On 2019/4/17 22:26, Yue Haibing wrote:
> From: YueHaibing 
> 
> During randconfig builds, I occasionally run into an invalid configuration
> 
> WARNING: unmet direct dependencies detected for DEVICE_PRIVATE
>   Depends on [n]: ARCH_HAS_HMM_DEVICE [=n] && ZONE_DEVICE [=n]
>   Selected by [y]:
>   - DRM_NOUVEAU_SVM [=y] && HAS_IOMEM [=y] && ARCH_HAS_HMM [=y] && 
> DRM_NOUVEAU [=y] && STAGING [=y]
> 
> mm/memory.o: In function `do_swap_page':
> memory.c:(.text+0x2754): undefined reference to `device_private_entry_fault'
> 
> commit 5da25090ab04 ("mm/hmm: kconfig split HMM address space mirroring from 
> device memory")
> split CONFIG_DEVICE_PRIVATE dependencies from
> ARCH_HAS_HMM to ARCH_HAS_HMM_DEVICE and ZONE_DEVICE,
> so enable DRM_NOUVEAU_SVM will trigger this warning,
> cause building failed.
> 
> Reported-by: Hulk Robot 
> Fixes: 5da25090ab04 ("mm/hmm: kconfig split HMM address space mirroring from 
> device memory")
> Signed-off-by: YueHaibing 
> ---
>  drivers/gpu/drm/nouveau/Kconfig | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/Kconfig b/drivers/gpu/drm/nouveau/Kconfig
> index 00cd9ab..99e30c1 100644
> --- a/drivers/gpu/drm/nouveau/Kconfig
> +++ b/drivers/gpu/drm/nouveau/Kconfig
> @@ -74,7 +74,8 @@ config DRM_NOUVEAU_BACKLIGHT
>  
>  config DRM_NOUVEAU_SVM
>   bool "(EXPERIMENTAL) Enable SVM (Shared Virtual Memory) support"
> - depends on ARCH_HAS_HMM
> + depends on ARCH_HAS_HMM_DEVICE
> + depends on ZONE_DEVICE
>   depends on DRM_NOUVEAU
>   depends on STAGING
>   select HMM_MIRROR
> 

Re: [PATCH] drm/sched: Fix make htmldocs warnings.

[Christian König]

Am 29.05.19 um 21:36 schrieb Daniel Vetter:

On Wed, May 29, 2019 at 04:43:45PM +, Grodzovsky, Andrey wrote:

I don't, sorry.

Should we fix that? Seems like you do plenty of scheduler stuff, so would
make sense I guess ...


Reviewed-by: Christian König  for the patch.

And +1 for giving Andrey commit rights to drm-misc-next.

Christian.


-Daniel


Andrey

On 5/29/19 12:42 PM, Alex Deucher wrote:

On Wed, May 29, 2019 at 10:29 AM Andrey Grodzovsky
 wrote:

Signed-off-by: Andrey Grodzovsky 

Reviewed-by: Alex Deucher 

I'll push it to drm-misc in a minute unless you have commit rights.

Alex


---
   drivers/gpu/drm/scheduler/sched_main.c | 2 ++
   1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/scheduler/sched_main.c 
b/drivers/gpu/drm/scheduler/sched_main.c
index 49e7d07..c1058ee 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -353,6 +353,7 @@ EXPORT_SYMBOL(drm_sched_increase_karma);
* drm_sched_stop - stop the scheduler
*
* @sched: scheduler instance
+ * @bad: job which caused the time out
*
* Stop the scheduler and also removes and frees all completed jobs.
* Note: bad job will not be freed as it might be used later and so it's
@@ -422,6 +423,7 @@ EXPORT_SYMBOL(drm_sched_stop);
* drm_sched_job_recovery - recover jobs after a reset
*
* @sched: scheduler instance
+ * @full_recovery: proceed with complete sched restart
*
*/
   void drm_sched_start(struct drm_gpu_scheduler *sched, bool full_recovery)
--
2.7.4

___
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] dt-bindings: display: Convert Allwinner DSI to a schema

[Chen-Yu Tsai]

On Mon, May 27, 2019 at 8:09 PM Maxime Ripard  wrote:
>
> The Allwinner SoCs have a MIPI-DSI and MIPI-D-PHY controllers supported in
> Linux, with a matching Device Tree binding.
>
> Now that we have the DT validation in place, let's convert the device tree
> bindings for that controller over to a YAML schemas.
>
> Signed-off-by: Maxime Ripard 

Looks good to me. However not sure why you replaced the clock index macros
with raw numbers.

Reviewed-by: Chen-Yu Tsai 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2] drm/i915: Split off pci_driver.remove() tail to drm_driver.release()

[Janusz Krzysztofik]

In order to support driver hot unbind, some cleanup operations, now
performed on PCI driver remove, must be called later, after all device
file descriptors are closed.

Split out those operations from the tail of pci_driver.remove()
callback and put them into drm_driver.release() which is called as soon
as all references to the driver are put.  As a result, those cleanups
will be now run on last drm_dev_put(), either still called from
pci_driver.remove() if all device file descriptors are already closed,
or on last drm_release() file operation.

Signed-off-by: Janusz Krzysztofik 
Reviewed-by: Chris Wilson 
---
Changelog:
v1 -> v2:
- defer intel_engines_cleanup() as well. (Chris)

 drivers/gpu/drm/i915/i915_drv.c | 17 +
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/i915_gem.c | 10 +-
 3 files changed, 23 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 83d2eb9e74cb..8be69f84eb6d 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -738,6 +738,7 @@ static int i915_load_modeset_init(struct drm_device *dev)
 
 cleanup_gem:
i915_gem_suspend(dev_priv);
+   i915_gem_fini_hw(dev_priv);
i915_gem_fini(dev_priv);
 cleanup_modeset:
intel_modeset_cleanup(dev);
@@ -1685,7 +1686,6 @@ static void i915_driver_cleanup_hw(struct 
drm_i915_private *dev_priv)
pci_disable_msi(pdev);
 
pm_qos_remove_request(_priv->pm_qos);
-   i915_ggtt_cleanup_hw(dev_priv);
 }
 
 /**
@@ -1909,6 +1909,7 @@ int i915_driver_load(struct pci_dev *pdev, const struct 
pci_device_id *ent)
 
 out_cleanup_hw:
i915_driver_cleanup_hw(dev_priv);
+   i915_ggtt_cleanup_hw(dev_priv);
 out_cleanup_mmio:
i915_driver_cleanup_mmio(dev_priv);
 out_runtime_pm_put:
@@ -1960,21 +1961,29 @@ void i915_driver_unload(struct drm_device *dev)
cancel_delayed_work_sync(_priv->gpu_error.hangcheck_work);
i915_reset_error_state(dev_priv);
 
-   i915_gem_fini(dev_priv);
+   i915_gem_fini_hw(dev_priv);
 
intel_power_domains_fini_hw(dev_priv);
 
i915_driver_cleanup_hw(dev_priv);
-   i915_driver_cleanup_mmio(dev_priv);
 
enable_rpm_wakeref_asserts(dev_priv);
-   intel_runtime_pm_cleanup(dev_priv);
 }
 
 static void i915_driver_release(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = to_i915(dev);
 
+   disable_rpm_wakeref_asserts(dev_priv);
+
+   i915_gem_fini(dev_priv);
+
+   i915_ggtt_cleanup_hw(dev_priv);
+   i915_driver_cleanup_mmio(dev_priv);
+
+   enable_rpm_wakeref_asserts(dev_priv);
+   intel_runtime_pm_cleanup(dev_priv);
+
i915_driver_cleanup_early(dev_priv);
i915_driver_destroy(dev_priv);
 }
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a2664ea1395b..d08e7bd83544 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3047,6 +3047,7 @@ void i915_gem_init_mmio(struct drm_i915_private *i915);
 int __must_check i915_gem_init(struct drm_i915_private *dev_priv);
 int __must_check i915_gem_init_hw(struct drm_i915_private *dev_priv);
 void i915_gem_init_swizzling(struct drm_i915_private *dev_priv);
+void i915_gem_fini_hw(struct drm_i915_private *dev_priv);
 void i915_gem_fini(struct drm_i915_private *dev_priv);
 int i915_gem_wait_for_idle(struct drm_i915_private *dev_priv,
   unsigned int flags, long timeout);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 7cafd5612f71..20d3f7532cef 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4667,7 +4667,7 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
return ret;
 }
 
-void i915_gem_fini(struct drm_i915_private *dev_priv)
+void i915_gem_fini_hw(struct drm_i915_private *dev_priv)
 {
GEM_BUG_ON(dev_priv->gt.awake);
 
@@ -4680,6 +4680,14 @@ void i915_gem_fini(struct drm_i915_private *dev_priv)
mutex_lock(_priv->drm.struct_mutex);
intel_uc_fini_hw(dev_priv);
intel_uc_fini(dev_priv);
+   mutex_unlock(_priv->drm.struct_mutex);
+
+   i915_gem_drain_freed_objects(dev_priv);
+}
+
+void i915_gem_fini(struct drm_i915_private *dev_priv)
+{
+   mutex_lock(_priv->drm.struct_mutex);
intel_engines_cleanup(dev_priv);
i915_gem_contexts_fini(dev_priv);
i915_gem_fini_scratch(dev_priv);
-- 
2.21.0

[PATCH v3] video: fbdev: atmel_lcdfb: add COMPILE_TEST support

[Bartlomiej Zolnierkiewicz]

Add COMPILE_TEST support to atmel_lcdfb driver for better compile
testing coverage.

While at it fix improper use of UL (to silence build warnings on
x86_64).

Cc: Alexandre Belloni 
Cc: Ludovic Desroches 
Signed-off-by: Bartlomiej Zolnierkiewicz 
---
v3: fix build warnings on x86_64

v2: add missing HAVE_CLK && HAS IOMEM dependencies

 drivers/video/fbdev/Kconfig   |3 ++-
 drivers/video/fbdev/atmel_lcdfb.c |4 ++--
 2 files changed, 4 insertions(+), 3 deletions(-)

Index: b/drivers/video/fbdev/Kconfig
===
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -855,7 +855,8 @@ config FB_S1D13XXX
 
 config FB_ATMEL
tristate "AT91 LCD Controller support"
-   depends on FB && OF && HAVE_FB_ATMEL
+   depends on FB && OF && HAVE_CLK && HAS_IOMEM
+   depends on HAVE_FB_ATMEL || COMPILE_TEST
select FB_BACKLIGHT
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
Index: b/drivers/video/fbdev/atmel_lcdfb.c
===
--- a/drivers/video/fbdev/atmel_lcdfb.c
+++ b/drivers/video/fbdev/atmel_lcdfb.c
@@ -673,7 +673,7 @@ static int atmel_lcdfb_set_par(struct fb
lcdc_writel(sinfo, ATMEL_LCDC_MVAL, 0);
 
/* Disable all interrupts */
-   lcdc_writel(sinfo, ATMEL_LCDC_IDR, ~0UL);
+   lcdc_writel(sinfo, ATMEL_LCDC_IDR, ~0U);
/* Enable FIFO & DMA errors */
lcdc_writel(sinfo, ATMEL_LCDC_IER, ATMEL_LCDC_UFLWI | ATMEL_LCDC_OWRI | 
ATMEL_LCDC_MERI);
 
@@ -1291,7 +1291,7 @@ static int atmel_lcdfb_suspend(struct pl
 * We don't want to handle interrupts while the clock is
 * stopped. It may take forever.
 */
-   lcdc_writel(sinfo, ATMEL_LCDC_IDR, ~0UL);
+   lcdc_writel(sinfo, ATMEL_LCDC_IDR, ~0U);
 
sinfo->saved_lcdcon = lcdc_readl(sinfo, ATMEL_LCDC_CONTRAST_CTR);
lcdc_writel(sinfo, ATMEL_LCDC_CONTRAST_CTR, 0);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 110781] Radeon: heavy r300 performance drop regression between 11.x and 19.x

[bugzilla-daemon]

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

--- Comment #7 from Richard Thier  ---
Latest bisect result so far:

Fast mesa version: 17.2.8 (2017 december 22)
Slow mesa version: 18.0.0 (git: 44c7d1aa2ea)

The change that slows the system is between the two.

-- 
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 0/4] drm/panfrost: Expose perf counters to userspace

[Alyssa Rosenzweig]

Woohoo! Patches 1-3 are R-b; patch 4 is A-b. Exciting progress! Hoping
to hear what Rob and Steven think :)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Panfrost impossible to probe without opp table

[Clément Péron]

Hi,

I have rebase my kernel on latest 5.2-rc2, and my panfrost driver is
no more probing.

The issue is coming from f3617b449d0bcf3b5d80a97f51498dcf7463cf7e
drm/panfrost: Select devfreq

Currently, there is some logic for the driver to work without devfreq.
However, the driver actually fails to probe if !CONFIG_PM_DEVFREQ.

Fix this by selecting devfreq, and drop the additional checks
for devfreq.

It seems that with this commit the OPP table is now mandatory.
is it intentional?

Actually
[3.046237] panfrost 180.gpu: clock rate = 43200
[3.051593] panfrost 180.gpu: bus_clock rate = 1
[3.096012] panfrost 180.gpu: mali-t720 id 0x720 major 0x1
minor 0x1 status 0x0
[3.103682] panfrost 180.gpu: features: ,10309e40,
issues: ,21054400
[3.111789] panfrost 180.gpu: Features: L2:0x07110206
Shader:0x Tiler:0x0809 Mem:0x1 MMU:0x2821 AS:0xf
JS:0x7
[3.123435] panfrost 180.gpu: shader_present=0x3 l2_present=0x1
[3.130405] panfrost 180.gpu: Fatal error during devfreq init

With commit reverted
[3.038236] panfrost 180.gpu: clock rate = 43200
[3.043593] panfrost 180.gpu: bus_clock rate = 1
[3.087994] panfrost 180.gpu: mali-t720 id 0x720 major 0x1
minor 0x1 status 0x0
[3.095658] panfrost 180.gpu: features: ,10309e40,
issues: ,21054400
[3.103763] panfrost 180.gpu: Features: L2:0x07110206
Shader:0x Tiler:0x0809 Mem:0x1 MMU:0x2821 AS:0xf
JS:0x7
[3.115410] panfrost 180.gpu: shader_present=0x3 l2_present=0x1
[3.122798] [drm] Initialized panfrost 1.0.0 20180908 for
180.gpu on minor 0


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

Re: [PATCH 5/5] drm/msm/mdp5: Use the interconnect API

[Georgi Djakov]

On 5/8/19 23:42, Rob Clark wrote:
> From: Georgi Djakov 
> 

Let's put some text in the commit message:

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 most appropriate power/performance
profile.

Use the API to configure the interconnects and request bandwidth between DDR and
the display hardware (MDP port(s) and rotator downscaler).


> Signed-off-by: Georgi Djakov 
> Signed-off-by: Rob Clark 
> ---
>  drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c 
> b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> index 97179bec8902..54d2b4c2b09f 100644
> --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> @@ -16,6 +16,7 @@
>   * this program.  If not, see .
>   */
>  
> +#include 
>  #include 
>  
>  #include "msm_drv.h"
> @@ -1050,6 +1051,19 @@ static const struct component_ops mdp5_ops = {
>  
>  static int mdp5_dev_probe(struct platform_device *pdev)
>  {
> + struct icc_path *path0 = of_icc_get(>dev, "port0");
> + struct icc_path *path1 = of_icc_get(>dev, "port1");
> + struct icc_path *path_rot = of_icc_get(>dev, "rotator");

It would be better change just the names to "mdp0-mem', "mdp1-mem",
"rotator-mem" for consistency and denote that the path target is the DDR memory.

> +
> + if (IS_ERR(path0))
> + return PTR_ERR(path0);
> + icc_set_bw(path0, 0, MBps_to_icc(6400));
> +
> + if (!IS_ERR(path1))
> + icc_set_bw(path1, 0, MBps_to_icc(6400));
> + if (!IS_ERR(path_rot))
> + icc_set_bw(path_rot, 0, MBps_to_icc(6400));
> +
>   DBG("");
>   return component_add(>dev, _ops);
>  }
> 

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

Re: [PATCH] drm/msm/dsi: add protection against NULL dsi device

[Jeffrey Hugo]

On 3/7/2019 3:02 PM, Abhinav Kumar wrote:

On 2019-03-07 13:59, Sean Paul wrote:

On Wed, Mar 06, 2019 at 05:28:54PM -0800, Abhinav Kumar wrote:

When panel probe happens after DSI probe, the DSI probe
is deferred as per current design. In the probe defer path
dsi device is destroyed. This NULL dsi device could be
deferenced by the panel probe in the mipi_dsi_attach path.

Check for NULL dsi device before accessing it.


It would be really nice to sort all of this out in a manner that's not
sprinkling NULL checks around the driver. I spent 5 minutes looking 
around and
couldn't really make sense of how all of these pieces interact, but 
this seems
like it might be an architectural problem (perhaps since dpu was using 
its own

panel stuff instead of drm_panel?).

Anyways, it'd be nice to fix that.

In the meantime, could you please add a big comment like the !dev 
check in this
function explaining how this situation can come to pass? That way the 
knowledge
isn't lost and whoever comes along to clean up all of these probe 
checks will

have some clue as to what's going on.

Sean

[Abhinav] Sure Sean, will add a detailed comment to explain the scenario


Abhinav, it looks like this may have dropped off your radar.  Do you 
know when you'll come back to it?






Reported-by: Jeffrey Hugo 
Tested-by: Jeffrey Hugo 
Signed-off-by: Abhinav Kumar 
---
 drivers/gpu/drm/msm/dsi/dsi_manager.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c 
b/drivers/gpu/drm/msm/dsi/dsi_manager.c

index 80aa634..cc2569d 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_manager.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c
@@ -769,7 +769,7 @@ bool msm_dsi_manager_cmd_xfer_trigger(int id, u32 
dma_base, u32 len)

 void msm_dsi_manager_attach_dsi_device(int id, u32 device_flags)
 {
 struct msm_dsi *msm_dsi = dsi_mgr_get_dsi(id);
-    struct drm_device *dev = msm_dsi->dev;
+    struct drm_device *dev = msm_dsi ? msm_dsi->dev : NULL;
 struct msm_drm_private *priv;
 struct msm_kms *kms;
 struct drm_encoder *encoder;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum,

a Linux Foundation Collaborative Project




--
Jeffrey Hugo
Qualcomm Datacenter Technologies as an affiliate of Qualcomm 
Technologies, Inc.

Qualcomm Technologies, 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/2] drm/komeda: Add new component komeda_splitter

[james qian wang (Arm Technology China)]

Similar to Layer Split, but Splitter is used for writeback, which splits
the compiz result to two half parts and then feed them to two scalers.

Signed-off-by: James Qian Wang (Arm Technology China) 
---
 .../arm/display/komeda/d71/d71_component.c| 63 +++
 .../drm/arm/display/komeda/komeda_pipeline.c  |  3 +
 .../drm/arm/display/komeda/komeda_pipeline.h  | 19 +-
 .../arm/display/komeda/komeda_private_obj.c   | 50 +++
 4 files changed, 133 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c 
b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
index 240f82cb9fa0..769f5a2da030 100644
--- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
+++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
@@ -767,6 +767,68 @@ static int d71_scaler_init(struct d71_dev *d71,
return 0;
 }

+static void d71_splitter_update(struct komeda_component *c,
+   struct komeda_component_state *state)
+{
+   struct komeda_splitter_state *st = to_splitter_st(state);
+   u32 __iomem *reg = c->reg;
+
+   malidp_write32(reg, BLK_INPUT_ID0, to_d71_input_id(state, 0));
+   malidp_write32(reg, BLK_SIZE, HV_SIZE(st->hsize, st->vsize));
+   malidp_write32(reg, SP_OVERLAP_SIZE, st->overlap & 0x1FFF);
+   malidp_write32(reg, BLK_CONTROL, BLK_CTRL_EN);
+}
+
+static void d71_splitter_dump(struct komeda_component *c, struct seq_file *sf)
+{
+   u32 v[3];
+
+   dump_block_header(sf, c->reg);
+
+   get_values_from_reg(c->reg, BLK_INPUT_ID0, 1, v);
+   seq_printf(sf, "SP_INPUT_ID0:\t\t0x%X\n", v[0]);
+
+   get_values_from_reg(c->reg, BLK_CONTROL, 3, v);
+   seq_printf(sf, "SP_CONTROL:\t\t0x%X\n", v[0]);
+   seq_printf(sf, "SP_SIZE:\t\t0x%X\n", v[1]);
+   seq_printf(sf, "SP_OVERLAP_SIZE:\t0x%X\n", v[2]);
+}
+
+static const struct komeda_component_funcs d71_splitter_funcs = {
+   .update = d71_splitter_update,
+   .disable= d71_component_disable,
+   .dump_register  = d71_splitter_dump,
+};
+
+static int d71_splitter_init(struct d71_dev *d71,
+struct block_header *blk, u32 __iomem *reg)
+{
+   struct komeda_component *c;
+   struct komeda_splitter *splitter;
+   u32 pipe_id, comp_id;
+
+   get_resources_id(blk->block_info, _id, _id);
+
+   c = komeda_component_add(>pipes[pipe_id]->base, sizeof(*splitter),
+comp_id,
+BLOCK_INFO_INPUT_ID(blk->block_info),
+_splitter_funcs,
+1, get_valid_inputs(blk), 2, reg,
+"CU%d_SPLITTER", pipe_id);
+
+   if (IS_ERR(c)) {
+   DRM_ERROR("Failed to initialize splitter");
+   return -1;
+   }
+
+   splitter = to_splitter(c);
+
+   set_range(>hsize, 4, d71->max_line_size);
+   set_range(>vsize, 4, d71->max_vsize);
+
+   return 0;
+}
+
 static void d71_merger_update(struct komeda_component *c,
  struct komeda_component_state *state)
 {
@@ -1126,6 +1188,7 @@ int d71_probe_block(struct d71_dev *d71,
break;

case D71_BLK_TYPE_CU_SPLITTER:
+   err = d71_splitter_init(d71, blk, reg);
break;

case D71_BLK_TYPE_CU_MERGER:
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c
index c7c3caad13bd..0b76e2acd38c 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c
@@ -92,6 +92,9 @@ komeda_pipeline_get_component_pos(struct komeda_pipeline 
*pipe, int id)
case KOMEDA_COMPONENT_SCALER1:
pos = to_cpos(pipe->scalers[id - KOMEDA_COMPONENT_SCALER0]);
break;
+   case KOMEDA_COMPONENT_SPLITTER:
+   pos = to_cpos(pipe->splitter);
+   break;
case KOMEDA_COMPONENT_MERGER:
pos = to_cpos(pipe->merger);
break;
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h 
b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
index 989408b53091..4632fc5ec71f 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
@@ -302,6 +302,17 @@ struct komeda_merger_state {
u16 vsize_merged;
 };

+struct komeda_splitter {
+   struct komeda_component base;
+   struct malidp_range hsize, vsize;
+};
+
+struct komeda_splitter_state {
+   struct komeda_component_state base;
+   u16 hsize, vsize;
+   u16 overlap;
+};
+
 struct komeda_improc {
struct komeda_component base;
u32 supported_color_formats;  /* DRM_RGB/YUV444/YUV420*/
@@ -393,6 +404,8 @@ struct komeda_pipeline {
struct komeda_scaler *scalers[KOMEDA_PIPELINE_MAX_SCALERS];
/** @compiz: 

[PATCH 2/2] drm/komeda: Enable writeback split support

[james qian wang (Arm Technology China)]

Writeback split is also for workaround the size limitation of d71 scaler.
Like layer_split, writeback downscaling also can use two scalers to handle
the scaling half-by-half. The only differnence is writback needs a
standalone component (splitter)'s help to split the composition result.
The data pipeline of writeback split as below:

   /-> scaler-0 ->\
 compiz -> splittermerger -> wb_layer -> memory
   \-> scaler-1 ->/

Signed-off-by: James Qian Wang (Arm Technology China) 
---
 .../drm/arm/display/komeda/komeda_pipeline.h  |   4 +
 .../display/komeda/komeda_pipeline_state.c| 117 --
 .../arm/display/komeda/komeda_wb_connector.c  |  17 ++-
 3 files changed, 124 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h 
b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
index 4632fc5ec71f..9057dc512cf2 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
@@ -524,6 +524,10 @@ int komeda_build_layer_split_data_flow(struct komeda_layer 
*left,
   struct komeda_plane_state *kplane_st,
   struct komeda_crtc_state *kcrtc_st,
   struct komeda_data_flow_cfg *dflow);
+int komeda_build_wb_split_data_flow(struct komeda_layer *wb_layer,
+   struct drm_connector_state *conn_st,
+   struct komeda_crtc_state *kcrtc_st,
+   struct komeda_data_flow_cfg *dflow);

 int komeda_release_unclaimed_resources(struct komeda_pipeline *pipe,
   struct komeda_crtc_state *kcrtc_st);
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
index 82ea6cf9a989..afd857ef2239 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
@@ -284,30 +284,33 @@ komeda_layer_check_cfg(struct komeda_layer *layer,
   struct komeda_fb *kfb,
   struct komeda_data_flow_cfg *dflow)
 {
-   u32 hsize_in, vsize_in;
+   u32 src_x, src_y, src_w, src_h;

if (!komeda_fb_is_layer_supported(kfb, layer->layer_type, dflow->rot))
return -EINVAL;

-   if (komeda_fb_check_src_coords(kfb, dflow->in_x, dflow->in_y,
-  dflow->in_w, dflow->in_h))
-   return -EINVAL;
-
if (layer->base.id == KOMEDA_COMPONENT_WB_LAYER) {
-   hsize_in = dflow->out_w;
-   vsize_in = dflow->out_h;
+   src_x = dflow->out_x;
+   src_y = dflow->out_y;
+   src_w = dflow->out_w;
+   src_h = dflow->out_h;
} else {
-   hsize_in = dflow->in_w;
-   vsize_in = dflow->in_h;
+   src_x = dflow->in_x;
+   src_y = dflow->in_y;
+   src_w = dflow->in_w;
+   src_h = dflow->in_h;
}

-   if (!in_range(>hsize_in, hsize_in)) {
-   DRM_DEBUG_ATOMIC("invalidate src_w %d.\n", hsize_in);
+   if (komeda_fb_check_src_coords(kfb, src_x, src_y, src_w, src_h))
+   return -EINVAL;
+
+   if (!in_range(>hsize_in, src_w)) {
+   DRM_DEBUG_ATOMIC("invalidate src_w %d.\n", src_w);
return -EINVAL;
}

-   if (!in_range(>vsize_in, vsize_in)) {
-   DRM_DEBUG_ATOMIC("invalidate src_h %d.\n", vsize_in);
+   if (!in_range(>vsize_in, src_h)) {
+   DRM_DEBUG_ATOMIC("invalidate src_h %d.\n", src_h);
return -EINVAL;
}

@@ -534,6 +537,59 @@ komeda_scaler_validate(void *user,
return err;
 }

+static void komeda_split_data_flow(struct komeda_scaler *scaler,
+  struct komeda_data_flow_cfg *dflow,
+  struct komeda_data_flow_cfg *l_dflow,
+  struct komeda_data_flow_cfg *r_dflow);
+
+static int
+komeda_splitter_validate(struct komeda_splitter *splitter,
+struct drm_connector_state *conn_st,
+struct komeda_data_flow_cfg *dflow,
+struct komeda_data_flow_cfg *l_output,
+struct komeda_data_flow_cfg *r_output)
+{
+   struct komeda_component_state *c_st;
+   struct komeda_splitter_state *st;
+
+   if (!splitter) {
+   DRM_DEBUG_ATOMIC("Current HW doesn't support splitter.\n");
+   return -EINVAL;
+   }
+
+   if (!in_range(>hsize, dflow->in_w)) {
+   DRM_DEBUG_ATOMIC("split in_w:%d is out of the acceptable 
range.\n",
+dflow->in_w);
+   return -EINVAL;
+   }
+
+   if 

[PATCH 0/2] drm/komeda: Add writeback downscaling split support

[james qian wang (Arm Technology China)]

Writeback split is also for workaround the size limitation of d71 scaler.
Like layer_split, writeback downscaling also can use two scalers to handle
the scaling half-by-half. The only differnence is writback needs a
standalone component (splitter)'s help to split the composition result.
The data pipeline of writeback split as below:

   /-> scaler-0 ->\
 compiz -> splittermerger -> wb_layer -> memory
   \-> scaler-1 ->/

Depends on:
- https://patchwork.freedesktop.org/series/58710/
- https://patchwork.freedesktop.org/series/59000/
- https://patchwork.freedesktop.org/series/59002/
- https://patchwork.freedesktop.org/series/59747/
- https://patchwork.freedesktop.org/series/59915/
- https://patchwork.freedesktop.org/series/60083/
- https://patchwork.freedesktop.org/series/60698/
- https://patchwork.freedesktop.org/series/60856/
- https://patchwork.freedesktop.org/series/60893/
- https://patchwork.freedesktop.org/series/61370/

James Qian Wang (Arm Technology China) (2):
  drm/komeda: Add new component komeda_splitter
  drm/komeda: Enable writeback split support

 .../arm/display/komeda/d71/d71_component.c|  63 ++
 .../drm/arm/display/komeda/komeda_pipeline.c  |   3 +
 .../drm/arm/display/komeda/komeda_pipeline.h  |  23 +++-
 .../display/komeda/komeda_pipeline_state.c| 117 --
 .../arm/display/komeda/komeda_private_obj.c   |  50 
 .../arm/display/komeda/komeda_wb_connector.c  |  17 ++-
 6 files changed, 257 insertions(+), 16 deletions(-)

--
2.17.1

Re: [PATCH v4] gpu/drm: mediatek: call mtk_dsi_stop() after mtk_drm_crtc_atomic_disable()

[CK Hu]

Hi, Hsin-Yi:

On Thu, 2019-05-30 at 17:18 +0800, Hsin-Yi Wang wrote:
> mtk_dsi_stop() should be called after mtk_drm_crtc_atomic_disable(), which 
> needs
> ovl irq for drm_crtc_wait_one_vblank(), since after mtk_dsi_stop() is called,
> ovl irq will be disabled. If drm_crtc_wait_one_vblank() is called after last
> irq, it will timeout with this message: "vblank wait timed out on crtc 0". 
> This
> happens sometimes when turning off the screen.
> 
> In drm_atomic_helper.c#disable_outputs(),
> the calling sequence when turning off the screen is:
> 
> 1. mtk_dsi_encoder_disable()
>  --> mtk_output_dsi_disable()
>--> mtk_dsi_stop();  // sometimes make vblank timeout in atomic_disable
>--> mtk_dsi_poweroff();
> 2. mtk_drm_crtc_atomic_disable()
>  --> drm_crtc_wait_one_vblank();
>  ...
>--> mtk_dsi_ddp_stop()
>  --> mtk_dsi_poweroff();
> 
> mtk_dsi_poweroff() has reference count design, change to make mtk_dsi_stop()
> called in mtk_dsi_poweroff() when refcount is 0.

Reviewed-by: CK Hu 

> 
> Fixes: 0707632b5bac ("drm/mediatek: update DSI sub driver flow for sending 
> commands to panel")
> Signed-off-by: Hsin-Yi Wang 
> ---
> change log v3->v4:
> * add comment in code.
> ---
>  drivers/gpu/drm/mediatek/mtk_dsi.c | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index b00eb2d2e086..730594a91440 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -630,6 +630,15 @@ static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
>   if (--dsi->refcount != 0)
>   return;
>  
> + /* 
> +  * mtk_dsi_stop() and mtk_dsi_start() is asymmetric, since
> +  * mtk_dsi_stop() should be called after mtk_drm_crtc_atomic_disable(),
> +  * which needs irq for vblank, and mtk_dsi_stop() will disable irq.
> +  * mtk_dsi_start() needs to be called in mtk_output_dsi_enable(),
> +  * after dsi is fully set.
> +  */
> + mtk_dsi_stop(dsi);
> +
>   if (!mtk_dsi_switch_to_cmd_mode(dsi, VM_DONE_INT_FLAG, 500)) {
>   if (dsi->panel) {
>   if (drm_panel_unprepare(dsi->panel)) {
> @@ -696,7 +705,6 @@ static void mtk_output_dsi_disable(struct mtk_dsi *dsi)
>   }
>   }
>  
> - mtk_dsi_stop(dsi);
>   mtk_dsi_poweroff(dsi);
>  
>   dsi->enabled = false;

Re: [PATCH] drm/mst: Fix MST sideband up-reply failure handling

[Imre Deak]

On Thu, May 23, 2019 at 06:31:15PM -0400, Lyude Paul wrote:
> On Fri, 2019-05-24 at 01:28 +0300, Imre Deak wrote:
> > On Thu, May 23, 2019 at 06:09:56PM -0400, Lyude Paul wrote:
> > > Patch mostly looks good to me, one comment below
> > > 
> > > On Fri, 2019-05-24 at 00:24 +0300, Imre Deak wrote:
> > > > Fix the breakage resulting in the stacktrace below, due to tx queue
> > > > being full when trying to send an up-reply. txmsg->seqno is -1 in this
> > > > case leading to a corruption of the mstb object by
> > > > 
> > > > txmsg->dst->tx_slots[txmsg->seqno] = NULL;
> > > > 
> > > > in process_single_up_tx_qlock().
> > > > 
> > > > [  +0,005162] [drm:process_single_tx_qlock [drm_kms_helper]]
> > > > set_hdr_from_dst_qlock: failed to find slot
> > > > [  +0,15] [drm:drm_dp_send_up_ack_reply.constprop.19
> > > > [drm_kms_helper]]
> > > > failed to send msg in q -11
> > > > [  +0,000939] BUG: kernel NULL pointer dereference, address:
> > > > 05a0
> > > > [  +0,006982] #PF: supervisor write access in kernel mode
> > > > [  +0,005223] #PF: error_code(0x0002) - not-present page
> > > > [  +0,005135] PGD 0 P4D 0
> > > > [  +0,002581] Oops: 0002 [#1] PREEMPT SMP NOPTI
> > > > [  +0,004359] CPU: 1 PID: 1200 Comm: kworker/u16:3 Tainted:
> > > > G U5.2.0-rc1+ #410
> > > > [  +0,008433] Hardware name: Intel Corporation Ice Lake Client
> > > > Platform/IceLake U DDR4 SODIMM PD RVP, BIOS
> > > > ICLSFWR1.R00.3175.A00.1904261428
> > > > 04/26/2019
> > > > [  +0,013323] Workqueue: i915-dp i915_digport_work_func [i915]
> > > > [  +0,005676] RIP: 0010:queue_work_on+0x19/0x70
> > > > [  +0,004372] Code: ff ff ff 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00
> > > > 41 56
> > > > 49 89 f6 41 55 41 89 fd 41 54 55 53 48 89 d3 9c 5d fa e8 e7 81 0c 00
> > > >  48
> > > > 0f ba 2b 00 73 31 45 31 e4 f7 c5 00 02 00 00 74 13 e8 cf 7f
> > > > [  +0,018750] RSP: 0018:c97dfc50 EFLAGS: 00010006
> > > > [  +0,005222] RAX: 0046 RBX: 05a0 RCX:
> > > > 0001
> > > > [  +0,007133] RDX: 0001b608 RSI:  RDI:
> > > > 82121972
> > > > [  +0,007129] RBP: 0202 R08:  R09:
> > > > 0001
> > > > [  +0,007129] R10:  R11:  R12:
> > > > 88847bfa5096
> > > > [  +0,007131] R13: 0010 R14: 88849c08f3f8 R15:
> > > > 
> > > > [  +0,007128] FS:  () GS:88849dc8()
> > > > knlGS:
> > > > [  +0,008083] CS:  0010 DS:  ES:  CR0: 80050033
> > > > [  +0,005749] CR2: 05a0 CR3: 05210006 CR4:
> > > > 00760ee0
> > > > [  +0,007128] PKRU: 5554
> > > > [  +0,002722] Call Trace:
> > > > [  +0,002458]  drm_dp_mst_handle_up_req+0x517/0x540 [drm_kms_helper]
> > > > [  +0,006197]  ? drm_dp_mst_hpd_irq+0x5b/0x9c0 [drm_kms_helper]
> > > > [  +0,005764]  drm_dp_mst_hpd_irq+0x5b/0x9c0 [drm_kms_helper]
> > > > [  +0,005623]  ? intel_dp_hpd_pulse+0x205/0x370 [i915]
> > > > [  +0,005018]  intel_dp_hpd_pulse+0x205/0x370 [i915]
> > > > [  +0,004836]  i915_digport_work_func+0xbb/0x140 [i915]
> > > > [  +0,005108]  process_one_work+0x245/0x610
> > > > [  +0,004027]  worker_thread+0x37/0x380
> > > > [  +0,003684]  ? process_one_work+0x610/0x610
> > > > [  +0,004184]  kthread+0x119/0x130
> > > > [  +0,003240]  ? kthread_park+0x80/0x80
> > > > [  +0,003668]  ret_from_fork+0x24/0x50
> > > > 
> > > > Cc: Lyude Paul 
> > > > Cc: Dave Airlie 
> > > > Signed-off-by: Imre Deak 
> > > > ---
> > > >  drivers/gpu/drm/drm_dp_mst_topology.c | 6 +-
> > > >  1 file changed, 5 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > index da1abca1b9e9..24c325f4a616 100644
> > > > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > @@ -1996,7 +1996,11 @@ static void process_single_up_tx_qlock(struct
> > > > drm_dp_mst_topology_mgr *mgr,
> > > > if (ret != 1)
> > > > DRM_DEBUG_KMS("failed to send msg in q %d\n", ret);
> > > >  
> > > > -   txmsg->dst->tx_slots[txmsg->seqno] = NULL;
> > > > +   if (txmsg->seqno != -1) {
> > > > +   WARN_ON((unsigned)txmsg->seqno >
> > > > +   ARRAY_SIZE(txmsg->dst->tx_slots));
> > > 
> > > Not 100% sure on this nitpick myself but, if we know that txmsg->seqno is
> > > about to go out of bounds shouldn't we also try to take action to stop it?
> > > like
> > 
> > Imo, it's worth keeping thins simple. If the WARN triggers we need to
> > fix the original issue in any case (txmsg->seqno never should be set to
> > anything else than -1 or a valid idx) so making the assignment here
> > conditional wouldn't have a real purpose.
> 
> mm, fair enough. Then:
> 
> Reviewed-by: Lyude Paul 
> 
> Thanks for the fix!

Thanks for the review. Got now the permission and so 

Re: [RFC PATCH 1/1] drm/i915: Split off pci_driver.remove() tail to drm_driver.release()

[Chris Wilson]

Quoting Janusz Krzysztofik (2019-05-30 10:24:26)
> In order to support driver hot unbind, some cleanup operations, now
> performed on PCI driver remove, must be called later, after all device
> file descriptors are closed.
> 
> Split out those operations from the tail of pci_driver.remove()
> callback and put them into drm_driver.release() which is called as soon
> as all references to the driver are put.  As a result, those cleanups
> will be now run on last drm_dev_put(), either still called from
> pci_driver.remove() if all device file descriptors are already closed,
> or on last drm_release() file operation.
> 
> Signed-off-by: Janusz Krzysztofik 
> ---
>  drivers/gpu/drm/i915/i915_drv.c | 17 +
>  drivers/gpu/drm/i915/i915_drv.h |  1 +
>  drivers/gpu/drm/i915/i915_gem.c | 10 +-
>  3 files changed, 23 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 83d2eb9e74cb..8be69f84eb6d 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -738,6 +738,7 @@ static int i915_load_modeset_init(struct drm_device *dev)
>  
>  cleanup_gem:
> i915_gem_suspend(dev_priv);
> +   i915_gem_fini_hw(dev_priv);
> i915_gem_fini(dev_priv);
>  cleanup_modeset:
> intel_modeset_cleanup(dev);
> @@ -1685,7 +1686,6 @@ static void i915_driver_cleanup_hw(struct 
> drm_i915_private *dev_priv)
> pci_disable_msi(pdev);
>  
> pm_qos_remove_request(_priv->pm_qos);
> -   i915_ggtt_cleanup_hw(dev_priv);
>  }
>  
>  /**
> @@ -1909,6 +1909,7 @@ int i915_driver_load(struct pci_dev *pdev, const struct 
> pci_device_id *ent)

Would it make sense to rename load/unload from the legacy drm stubs over
to match the pci entry points?

>  out_cleanup_hw:
> i915_driver_cleanup_hw(dev_priv);
> +   i915_ggtt_cleanup_hw(dev_priv);
>  out_cleanup_mmio:
> i915_driver_cleanup_mmio(dev_priv);
>  out_runtime_pm_put:
> @@ -1960,21 +1961,29 @@ void i915_driver_unload(struct drm_device *dev)
> cancel_delayed_work_sync(_priv->gpu_error.hangcheck_work);
> i915_reset_error_state(dev_priv);
>  
> -   i915_gem_fini(dev_priv);
> +   i915_gem_fini_hw(dev_priv);
>  
> intel_power_domains_fini_hw(dev_priv);
>  
> i915_driver_cleanup_hw(dev_priv);
> -   i915_driver_cleanup_mmio(dev_priv);
>  
> enable_rpm_wakeref_asserts(dev_priv);
> -   intel_runtime_pm_cleanup(dev_priv);
>  }
>  
>  static void i915_driver_release(struct drm_device *dev)
>  {
> struct drm_i915_private *dev_priv = to_i915(dev);
>  
> +   disable_rpm_wakeref_asserts(dev_priv);
> +
> +   i915_gem_fini(dev_priv);
> +
> +   i915_ggtt_cleanup_hw(dev_priv);
> +   i915_driver_cleanup_mmio(dev_priv);
> +
> +   enable_rpm_wakeref_asserts(dev_priv);
> +   intel_runtime_pm_cleanup(dev_priv);

We should really propagate the release nomenclature down and replace our
mixed fini/cleanup. Consistency is helpful when trying to work out which
phase the code is in.

> i915_driver_cleanup_early(dev_priv);
> i915_driver_destroy(dev_priv);
>  }
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index a2664ea1395b..d08e7bd83544 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3047,6 +3047,7 @@ void i915_gem_init_mmio(struct drm_i915_private *i915);
>  int __must_check i915_gem_init(struct drm_i915_private *dev_priv);
>  int __must_check i915_gem_init_hw(struct drm_i915_private *dev_priv);
>  void i915_gem_init_swizzling(struct drm_i915_private *dev_priv);
> +void i915_gem_fini_hw(struct drm_i915_private *dev_priv);
>  void i915_gem_fini(struct drm_i915_private *dev_priv);
>  int i915_gem_wait_for_idle(struct drm_i915_private *dev_priv,
>unsigned int flags, long timeout);
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 7cafd5612f71..c6a8e665a6ba 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -4667,7 +4667,7 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
> return ret;
>  }
>  
> -void i915_gem_fini(struct drm_i915_private *dev_priv)
> +void i915_gem_fini_hw(struct drm_i915_private *dev_priv)
>  {
> GEM_BUG_ON(dev_priv->gt.awake);
>  
> @@ -4681,6 +4681,14 @@ void i915_gem_fini(struct drm_i915_private *dev_priv)
> intel_uc_fini_hw(dev_priv);
> intel_uc_fini(dev_priv);

> intel_engines_cleanup(dev_priv);

intel_engines_cleanup -> i915_gem_fini -- that is in principle just
freeing structs. One side effect it does have is to make all engines
unavailable (but it doesn't update the engine_mask so the inconsistency
might catch us out if it is not one of the last cleanup actions).

intel_uc_fini() is a bit of a mixed bag. It looks like it flushes
runtime state, so preferrably that flush should be 

[RFC PATCH 1/1] drm/i915: Split off pci_driver.remove() tail to drm_driver.release()

[Janusz Krzysztofik]

In order to support driver hot unbind, some cleanup operations, now
performed on PCI driver remove, must be called later, after all device
file descriptors are closed.

Split out those operations from the tail of pci_driver.remove()
callback and put them into drm_driver.release() which is called as soon
as all references to the driver are put.  As a result, those cleanups
will be now run on last drm_dev_put(), either still called from
pci_driver.remove() if all device file descriptors are already closed,
or on last drm_release() file operation.

Signed-off-by: Janusz Krzysztofik 
---
 drivers/gpu/drm/i915/i915_drv.c | 17 +
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/i915_gem.c | 10 +-
 3 files changed, 23 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 83d2eb9e74cb..8be69f84eb6d 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -738,6 +738,7 @@ static int i915_load_modeset_init(struct drm_device *dev)
 
 cleanup_gem:
i915_gem_suspend(dev_priv);
+   i915_gem_fini_hw(dev_priv);
i915_gem_fini(dev_priv);
 cleanup_modeset:
intel_modeset_cleanup(dev);
@@ -1685,7 +1686,6 @@ static void i915_driver_cleanup_hw(struct 
drm_i915_private *dev_priv)
pci_disable_msi(pdev);
 
pm_qos_remove_request(_priv->pm_qos);
-   i915_ggtt_cleanup_hw(dev_priv);
 }
 
 /**
@@ -1909,6 +1909,7 @@ int i915_driver_load(struct pci_dev *pdev, const struct 
pci_device_id *ent)
 
 out_cleanup_hw:
i915_driver_cleanup_hw(dev_priv);
+   i915_ggtt_cleanup_hw(dev_priv);
 out_cleanup_mmio:
i915_driver_cleanup_mmio(dev_priv);
 out_runtime_pm_put:
@@ -1960,21 +1961,29 @@ void i915_driver_unload(struct drm_device *dev)
cancel_delayed_work_sync(_priv->gpu_error.hangcheck_work);
i915_reset_error_state(dev_priv);
 
-   i915_gem_fini(dev_priv);
+   i915_gem_fini_hw(dev_priv);
 
intel_power_domains_fini_hw(dev_priv);
 
i915_driver_cleanup_hw(dev_priv);
-   i915_driver_cleanup_mmio(dev_priv);
 
enable_rpm_wakeref_asserts(dev_priv);
-   intel_runtime_pm_cleanup(dev_priv);
 }
 
 static void i915_driver_release(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = to_i915(dev);
 
+   disable_rpm_wakeref_asserts(dev_priv);
+
+   i915_gem_fini(dev_priv);
+
+   i915_ggtt_cleanup_hw(dev_priv);
+   i915_driver_cleanup_mmio(dev_priv);
+
+   enable_rpm_wakeref_asserts(dev_priv);
+   intel_runtime_pm_cleanup(dev_priv);
+
i915_driver_cleanup_early(dev_priv);
i915_driver_destroy(dev_priv);
 }
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a2664ea1395b..d08e7bd83544 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3047,6 +3047,7 @@ void i915_gem_init_mmio(struct drm_i915_private *i915);
 int __must_check i915_gem_init(struct drm_i915_private *dev_priv);
 int __must_check i915_gem_init_hw(struct drm_i915_private *dev_priv);
 void i915_gem_init_swizzling(struct drm_i915_private *dev_priv);
+void i915_gem_fini_hw(struct drm_i915_private *dev_priv);
 void i915_gem_fini(struct drm_i915_private *dev_priv);
 int i915_gem_wait_for_idle(struct drm_i915_private *dev_priv,
   unsigned int flags, long timeout);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 7cafd5612f71..c6a8e665a6ba 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4667,7 +4667,7 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
return ret;
 }
 
-void i915_gem_fini(struct drm_i915_private *dev_priv)
+void i915_gem_fini_hw(struct drm_i915_private *dev_priv)
 {
GEM_BUG_ON(dev_priv->gt.awake);
 
@@ -4681,6 +4681,14 @@ void i915_gem_fini(struct drm_i915_private *dev_priv)
intel_uc_fini_hw(dev_priv);
intel_uc_fini(dev_priv);
intel_engines_cleanup(dev_priv);
+   mutex_unlock(_priv->drm.struct_mutex);
+
+   i915_gem_drain_freed_objects(dev_priv);
+}
+
+void i915_gem_fini(struct drm_i915_private *dev_priv)
+{
+   mutex_lock(_priv->drm.struct_mutex);
i915_gem_contexts_fini(dev_priv);
i915_gem_fini_scratch(dev_priv);
mutex_unlock(_priv->drm.struct_mutex);
-- 
2.21.0

[RFC PATCH 0/1] drm/i915: Split off pci_driver.remove() tail to drm_driver.release()

[Janusz Krzysztofik]

Hi,

I do realize more work needs to be done to get a clean hotunplug
solution, however I need your comments to make sure that I'm going in
the right direction.

So far I have no good idea how to resolve pm_runtime_get_sync()
failures on outstanding device file close after successfull driver
unbind.

Thanks,
Janusz


Janusz Krzysztofik (1):
  drm/i915: Split off pci_driver.remove() tail to drm_driver.release()

 drivers/gpu/drm/i915/i915_drv.c | 17 +
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/i915_gem.c | 10 +-
 3 files changed, 23 insertions(+), 5 deletions(-)

-- 
2.21.0

[PATCH v4] gpu/drm: mediatek: call mtk_dsi_stop() after mtk_drm_crtc_atomic_disable()

[Hsin-Yi Wang]

mtk_dsi_stop() should be called after mtk_drm_crtc_atomic_disable(), which needs
ovl irq for drm_crtc_wait_one_vblank(), since after mtk_dsi_stop() is called,
ovl irq will be disabled. If drm_crtc_wait_one_vblank() is called after last
irq, it will timeout with this message: "vblank wait timed out on crtc 0". This
happens sometimes when turning off the screen.

In drm_atomic_helper.c#disable_outputs(),
the calling sequence when turning off the screen is:

1. mtk_dsi_encoder_disable()
 --> mtk_output_dsi_disable()
   --> mtk_dsi_stop();  // sometimes make vblank timeout in atomic_disable
   --> mtk_dsi_poweroff();
2. mtk_drm_crtc_atomic_disable()
 --> drm_crtc_wait_one_vblank();
 ...
   --> mtk_dsi_ddp_stop()
 --> mtk_dsi_poweroff();

mtk_dsi_poweroff() has reference count design, change to make mtk_dsi_stop()
called in mtk_dsi_poweroff() when refcount is 0.

Fixes: 0707632b5bac ("drm/mediatek: update DSI sub driver flow for sending 
commands to panel")
Signed-off-by: Hsin-Yi Wang 
---
change log v3->v4:
* add comment in code.
---
 drivers/gpu/drm/mediatek/mtk_dsi.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index b00eb2d2e086..730594a91440 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -630,6 +630,15 @@ static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
if (--dsi->refcount != 0)
return;
 
+   /* 
+* mtk_dsi_stop() and mtk_dsi_start() is asymmetric, since
+* mtk_dsi_stop() should be called after mtk_drm_crtc_atomic_disable(),
+* which needs irq for vblank, and mtk_dsi_stop() will disable irq.
+* mtk_dsi_start() needs to be called in mtk_output_dsi_enable(),
+* after dsi is fully set.
+*/
+   mtk_dsi_stop(dsi);
+
if (!mtk_dsi_switch_to_cmd_mode(dsi, VM_DONE_INT_FLAG, 500)) {
if (dsi->panel) {
if (drm_panel_unprepare(dsi->panel)) {
@@ -696,7 +705,6 @@ static void mtk_output_dsi_disable(struct mtk_dsi *dsi)
}
}
 
-   mtk_dsi_stop(dsi);
mtk_dsi_poweroff(dsi);
 
dsi->enabled = false;
-- 
2.20.1

Re: [PATCH 09/22] docs: mark orphan documents as such

[Paolo Bonzini]

On 30/05/19 01:23, Mauro Carvalho Chehab wrote:
> Sphinx doesn't like orphan documents:
> 
> Documentation/accelerators/ocxl.rst: WARNING: document isn't included in 
> any toctree
> Documentation/arm/stm32/overview.rst: WARNING: document isn't included in 
> any toctree
> Documentation/arm/stm32/stm32f429-overview.rst: WARNING: document isn't 
> included in any toctree
> Documentation/arm/stm32/stm32f746-overview.rst: WARNING: document isn't 
> included in any toctree
> Documentation/arm/stm32/stm32f769-overview.rst: WARNING: document isn't 
> included in any toctree
> Documentation/arm/stm32/stm32h743-overview.rst: WARNING: document isn't 
> included in any toctree
> Documentation/arm/stm32/stm32mp157-overview.rst: WARNING: document isn't 
> included in any toctree
> Documentation/gpu/msm-crash-dump.rst: WARNING: document isn't included in 
> any toctree
> Documentation/interconnect/interconnect.rst: WARNING: document isn't 
> included in any toctree
> Documentation/laptops/lg-laptop.rst: WARNING: document isn't included in 
> any toctree
> Documentation/powerpc/isa-versions.rst: WARNING: document isn't included 
> in any toctree
> Documentation/virtual/kvm/amd-memory-encryption.rst: WARNING: document 
> isn't included in any toctree
> Documentation/virtual/kvm/vcpu-requests.rst: WARNING: document isn't 
> included in any toctree
> 
> So, while they aren't on any toctree, add :orphan: to them, in order
> to silent this warning.
> 
> Signed-off-by: Mauro Carvalho Chehab 

Please leave out KVM, I'll fix that instead.  Thanks for the report!

Paolo

> ---
>  Documentation/accelerators/ocxl.rst | 2 ++
>  Documentation/arm/stm32/overview.rst| 2 ++
>  Documentation/arm/stm32/stm32f429-overview.rst  | 2 ++
>  Documentation/arm/stm32/stm32f746-overview.rst  | 2 ++
>  Documentation/arm/stm32/stm32f769-overview.rst  | 2 ++
>  Documentation/arm/stm32/stm32h743-overview.rst  | 2 ++
>  Documentation/arm/stm32/stm32mp157-overview.rst | 2 ++
>  Documentation/gpu/msm-crash-dump.rst| 2 ++
>  Documentation/interconnect/interconnect.rst | 2 ++
>  Documentation/laptops/lg-laptop.rst | 2 ++
>  Documentation/powerpc/isa-versions.rst  | 2 ++
>  Documentation/virtual/kvm/amd-memory-encryption.rst | 2 ++
>  Documentation/virtual/kvm/vcpu-requests.rst | 2 ++
>  13 files changed, 26 insertions(+)
> 
> diff --git a/Documentation/accelerators/ocxl.rst 
> b/Documentation/accelerators/ocxl.rst
> index 14cefc020e2d..b1cea19a90f5 100644
> --- a/Documentation/accelerators/ocxl.rst
> +++ b/Documentation/accelerators/ocxl.rst
> @@ -1,3 +1,5 @@
> +:orphan:
> +
>  
>  OpenCAPI (Open Coherent Accelerator Processor Interface)
>  
> diff --git a/Documentation/arm/stm32/overview.rst 
> b/Documentation/arm/stm32/overview.rst
> index 85cfc8410798..f7e734153860 100644
> --- a/Documentation/arm/stm32/overview.rst
> +++ b/Documentation/arm/stm32/overview.rst
> @@ -1,3 +1,5 @@
> +:orphan:
> +
>  
>  STM32 ARM Linux Overview
>  
> diff --git a/Documentation/arm/stm32/stm32f429-overview.rst 
> b/Documentation/arm/stm32/stm32f429-overview.rst
> index 18feda97f483..65bbb1c3b423 100644
> --- a/Documentation/arm/stm32/stm32f429-overview.rst
> +++ b/Documentation/arm/stm32/stm32f429-overview.rst
> @@ -1,3 +1,5 @@
> +:orphan:
> +
>  STM32F429 Overview
>  ==
>  
> diff --git a/Documentation/arm/stm32/stm32f746-overview.rst 
> b/Documentation/arm/stm32/stm32f746-overview.rst
> index b5f4b6ce7656..42d593085015 100644
> --- a/Documentation/arm/stm32/stm32f746-overview.rst
> +++ b/Documentation/arm/stm32/stm32f746-overview.rst
> @@ -1,3 +1,5 @@
> +:orphan:
> +
>  STM32F746 Overview
>  ==
>  
> diff --git a/Documentation/arm/stm32/stm32f769-overview.rst 
> b/Documentation/arm/stm32/stm32f769-overview.rst
> index 228656ced2fe..f6adac862b17 100644
> --- a/Documentation/arm/stm32/stm32f769-overview.rst
> +++ b/Documentation/arm/stm32/stm32f769-overview.rst
> @@ -1,3 +1,5 @@
> +:orphan:
> +
>  STM32F769 Overview
>  ==
>  
> diff --git a/Documentation/arm/stm32/stm32h743-overview.rst 
> b/Documentation/arm/stm32/stm32h743-overview.rst
> index 3458dc00095d..c525835e7473 100644
> --- a/Documentation/arm/stm32/stm32h743-overview.rst
> +++ b/Documentation/arm/stm32/stm32h743-overview.rst
> @@ -1,3 +1,5 @@
> +:orphan:
> +
>  STM32H743 Overview
>  ==
>  
> diff --git a/Documentation/arm/stm32/stm32mp157-overview.rst 
> b/Documentation/arm/stm32/stm32mp157-overview.rst
> index 62e176d47ca7..2c52cd020601 100644
> --- a/Documentation/arm/stm32/stm32mp157-overview.rst
> +++ b/Documentation/arm/stm32/stm32mp157-overview.rst
> @@ -1,3 +1,5 @@
> +:orphan:
> +
>  STM32MP157 Overview
>  

[PATCH] drm/komeda: Adds gamma and color-transform support for DOU-IPS

[Lowry Li (Arm Technology China)]

Adds gamma and color-transform support for DOU-IPS.
Adds two caps members fgamma_coeffs and ctm_coeffs to komeda_improc_state.
If color management changed, set gamma and color-transform accordingly.

This patch series depends on:
- https://patchwork.freedesktop.org/series/58710/
- https://patchwork.freedesktop.org/series/59000/
- https://patchwork.freedesktop.org/series/59002/
- https://patchwork.freedesktop.org/series/59747/
- https://patchwork.freedesktop.org/series/59915/
- https://patchwork.freedesktop.org/series/60083/
- https://patchwork.freedesktop.org/series/60698/
- https://patchwork.freedesktop.org/series/60856/
- https://patchwork.freedesktop.org/series/60893/

Signed-off-by: Lowry Li (Arm Technology China) 
---
 .../gpu/drm/arm/display/komeda/d71/d71_component.c | 24 ++
 drivers/gpu/drm/arm/display/komeda/komeda_crtc.c   |  2 ++
 .../gpu/drm/arm/display/komeda/komeda_pipeline.h   |  3 +++
 .../drm/arm/display/komeda/komeda_pipeline_state.c |  6 ++
 4 files changed, 35 insertions(+)

diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c 
b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
index 9668063..240f82c 100644
--- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
+++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
@@ -882,15 +882,39 @@ static int d71_downscaling_clk_check(struct 
komeda_pipeline *pipe,
 static void d71_improc_update(struct komeda_component *c,
  struct komeda_component_state *state)
 {
+   struct drm_crtc_state *crtc_st = state->crtc->state;
struct komeda_improc_state *st = to_improc_st(state);
+   struct d71_pipeline *pipe = to_d71_pipeline(c->pipeline);
u32 __iomem *reg = c->reg;
u32 index;
+   u32 mask = 0, ctrl = 0;
 
for_each_changed_input(state, index)
malidp_write32(reg, BLK_INPUT_ID0 + index * 4,
   to_d71_input_id(state, index));
 
malidp_write32(reg, BLK_SIZE, HV_SIZE(st->hsize, st->vsize));
+
+   if (crtc_st->color_mgmt_changed) {
+   mask |= IPS_CTRL_FT | IPS_CTRL_RGB;
+
+   if (crtc_st->gamma_lut) {
+   malidp_write_group(pipe->dou_ft_coeff_addr, FT_COEFF0,
+  KOMEDA_N_GAMMA_COEFFS,
+  st->fgamma_coeffs);
+   ctrl |= IPS_CTRL_FT; /* enable gamma */
+   }
+
+   if (crtc_st->ctm) {
+   malidp_write_group(reg, IPS_RGB_RGB_COEFF0,
+  KOMEDA_N_CTM_COEFFS,
+  st->ctm_coeffs);
+   ctrl |= IPS_CTRL_RGB; /* enable gamut */
+   }
+   }
+
+   if (mask)
+   malidp_write32_mask(reg, BLK_CONTROL, mask, ctrl);
 }
 
 static void d71_improc_dump(struct komeda_component *c, struct seq_file *sf)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
index 24a9613..18c23f8 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
@@ -573,6 +573,8 @@ static int komeda_crtc_add(struct komeda_kms_dev *kms,
if (err)
return err;
 
+   drm_crtc_enable_color_mgmt(crtc, 0, true, KOMEDA_COLOR_LUT_SIZE);
+
return 0;
 }
 
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h 
b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
index 49bb058..989408b 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include "malidp_utils.h"
+#include "komeda_color_mgmt.h"
 
 #define KOMEDA_MAX_PIPELINES   2
 #define KOMEDA_PIPELINE_MAX_LAYERS 4
@@ -313,6 +314,8 @@ struct komeda_improc {
 struct komeda_improc_state {
struct komeda_component_state base;
u16 hsize, vsize;
+   u32 fgamma_coeffs[KOMEDA_N_GAMMA_COEFFS];
+   u32 ctm_coeffs[KOMEDA_N_CTM_COEFFS];
 };
 
 /* display timing controller */
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
index afb2301..82ea6cf 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
@@ -700,6 +700,12 @@ void pipeline_composition_size(struct komeda_crtc_state 
*kcrtc_st,
st->hsize = dflow->in_w;
st->vsize = dflow->in_h;
 
+   if (kcrtc_st->base.color_mgmt_changed) {
+   drm_lut_to_fgamma_coeffs(kcrtc_st->base.gamma_lut,
+st->fgamma_coeffs);
+   drm_ctm_to_coeffs(kcrtc_st->base.ctm, st->ctm_coeffs);
+   }
+
komeda_component_add_input(>base, >input, 0);
komeda_component_set_output(>input, >base, 

[Bug 108940] QHD bug? drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:1613 core_link_enable_stream+0xc14/0x1040

[bugzilla-daemon]

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

--- Comment #21 from l...@greensphere.co.za ---
Exactly Same Issue:

Fatal1ty AB350 Gaming-ITX/ac
AMD Ryzen 5 2400G


Is there anything I can do to help get this bug resolved?

My system remains unstable, with hardware resets the only solution.

-- 
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] gpu/drm: mediatek: call mtk_dsi_stop() after mtk_drm_crtc_atomic_disable()

[CK Hu]

Hi, Hsin-Yi:

On Thu, 2019-05-30 at 10:55 +0800, Hsin-Yi Wang wrote:
> On Tue, May 28, 2019 at 4:53 PM CK Hu  wrote:
> 
> > I think we've already discussed in [1]. I need a reason to understand
> > this is hardware behavior or software bug. If this is a software bug, we
> > need to fix the bug and code could be symmetric.
> >
> > [1]
> > http://lists.infradead.org/pipermail/linux-mediatek/2019-March/018423.html
> >
> Hi CK,
> 
> Jitao has replied in v2[1]
> "
> mtk_dsi_start must after dsi full setting.
> If you put it in mtk_dsi_ddp_start, mtk_dsi_set_mode won't work. DSI
> will keep cmd mode. So you see no irq.
> ...
> "
> 
> [1] https://lore.kernel.org/patchwork/patch/1052505/#1276270
> 
> Thanks

OK, this looks the hardware behavior, so I would like you to add comment
in the code to describe why we need this asymmetric behavior. The
description should be clear so that we could know how to modify the code
flow in future.

Regards,
CK

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

Re: [PATCHv6 0/4] omapdrm: DSI command mode panel support

[Tony Lindgren]

* Tony Lindgren  [190530 05:47]:
> * Tony Lindgren  [190529 08:11]:
> > * Tomi Valkeinen  [190529 07:06]:
> > > On 28/05/2019 13:18, Tony Lindgren wrote:
> > > 
> > > > > My board is x15 rev A3, attached to AM5 EVM. I've also attached my 
> > > > > kernel
> > > > > config.
> > > > 
> > > > Strange that this is not affecting other x15? I think timer12 would
> > > > be blocked on HS devices though?
> > > 
> > > Seems that the kernel config affects. omap2plus_defconfig boots ok.
> > 
> > OK, this line in your oops:
> > 
> > Unable to handle kernel paging request at virtual address 5a5a5a5a
> > 
> > Probably means we hit some slab poison with DEBUG_SLAB set.
> > Looks like your config boots fine with DEBUG_SLAB disabled
> > for me.
> > 
> > As this only happens for timer12, I wonder if we're again
> > hitting some uncompress issue with corrupted dtb. Changing
> > u-boot ftdaddr higher up might possibly make it go away.
> > Or else there's a bug elsewhere :)
> 
> Oh but CM_WKUPAON_TIMER12_CLKCTRL has no CLKSEL option unlike
> CM_WKUPAON_TIMER1_CLKCTRL. Below is one part of the fix, but
> it seems like we're missing handling somewhere as trying to
> get a non-existing clock should just produce -ENODEV type error.
> 
> And the clksel should be just handled with assigned-clocks
> in general, but I think we still need it there until we
> have drivers/clocksource/ timer drivers updated to boot
> using early_platform_device.

OK found it, we have the clkctrl clock potentially return
uninitialized data. I posted two fixes for the issue:

[PATCH] clk: ti: clkctrl: Fix returning uninitialized data
[PATCH] ARM: dts: Drop bogus CLKSEL for timer12 on dra7

Regards,

Tony

drop drmP.h usage? [Was: [pull] amdgpu, amdkfd drm-next-5.3]

[Sam Ravnborg]

Hi Alex et all.

> - Various cleanups

Any chance to persuade one of you guys to sweep through the amd / raedeon
tree and drop use of the deprecated header drmP.h?

Status at the moment (drm-misc-next):
$git grep drmP | cut -d '/' -f 1  | uniq -c | sort -n | tail -n 10
 11 meson
 12 mediatek
 13 vmwgfx
 15 rockchip
 16 sti
 18 sun4i
 24 exynos
 27 nouveau
103 radeon
110 amd

nouveau is already taken care of, the cleanup is in their tree.
amd and radeon are the two "worst" drivers in this respect at the
moment.

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