[Freedreno] [PATCH AUTOSEL 4.19 079/209] msm/gpu/a6xx: Force of_dma_configure to setup DMA for GMU

2019-11-12 Thread Sasha Levin
From: Jordan Crouse 

[ Upstream commit 32aa27e15c28d3898ed6f9b3c98f95f34a81eab2 ]

The point of the 'force_dma' parameter for of_dma_configure
is to force the device to be set up even if DMA capability is
not described by the firmware which is exactly the use case
 we have for GMU - we need SMMU to get set up but we have no
other dma capabilities since memory is managed by the GPU
driver. Currently we pass false so of_dma_configure() fails
and subsequently GMU and GPU probe does as well.

Fixes: 4b565ca5a2c ("drm/msm: Add A6XX device support")
Signed-off-by: Jordan Crouse 
Tested-by: Sibi Sankar 
Signed-off-by: Rob Clark 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 9acb9dfaf57e6..9cde79a7335c8 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -1140,7 +1140,7 @@ int a6xx_gmu_probe(struct a6xx_gpu *a6xx_gpu, struct 
device_node *node)
 
gmu->dev = >dev;
 
-   of_dma_configure(gmu->dev, node, false);
+   of_dma_configure(gmu->dev, node, true);
 
/* Fow now, don't do anything fancy until we get our feet under us */
gmu->idle_level = GMU_IDLE_STATE_ACTIVE;
-- 
2.20.1

___
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno

Re: [Freedreno] [PATCH 1/4] drm/msm: fix memleak on release

2019-11-12 Thread Sean Paul
On Tue, Nov 12, 2019 at 08:32:07AM -0800, Rob Clark wrote:
> On Tue, Nov 12, 2019 at 6:01 AM Daniel Vetter  wrote:
> >
> > On Tue, Nov 12, 2019 at 11:40:01AM +0100, Johan Hovold wrote:
> > > On Wed, Oct 30, 2019 at 11:01:46AM +0100, Johan Hovold wrote:
> > > > On Thu, Oct 10, 2019 at 03:13:30PM +0200, Johan Hovold wrote:
> > > > > If a process is interrupted while accessing the "gpu" debugfs file and
> > > > > the drm device struct_mutex is contended, release() could return early
> > > > > and fail to free related resources.
> > > > >
> > > > > Note that the return value from release() is ignored.
> > > > >
> > > > > Fixes: 4f776f4511c7 ("drm/msm/gpu: Convert the GPU show function to 
> > > > > use the GPU state")
> > > > > Cc: stable  # 4.18
> > > > > Cc: Jordan Crouse 
> > > > > Cc: Rob Clark 
> > > > > Signed-off-by: Johan Hovold 
> > > > > ---
> > > >
> > > > Rob, Sean,
> > > >
> > > > Sending a reminder about this one, which is not yet in linux-next.
> > > >
> > > > Perhaps Daniel can pick it up otherwise?
> > >
> > > Another two weeks, another reminder. This one is still not in -next.
> >
> > Well msm is maintained in a separate tree, so the usual group maintainer
> > fallback for when patches are stuck doesn't apply.
> 
> oh, sorry, this wasn't showing up in patchwork.. or rather it did but
> the non-msm related series subject made me overlook it.
> 
> I've already sent a PR, but this shouldn't conflict with anything and
> I think it can go in via drm-misc/fixes
> 
> Reviewed-by: Rob Clark 

Thanks for the patch, pushed to drm-misc-next-fixes

Sean

> 
> > Rob, Sean, time to reconsider drm-misc for msm? I think there's some more
> > oddball patches that occasionally get stuck for msm ...
> >
> > Also +Dave.
> > -Daniel
> >
> > >
> > > Johan
> > >
> > > > >  drivers/gpu/drm/msm/msm_debugfs.c | 6 +-
> > > > >  1 file changed, 1 insertion(+), 5 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/msm/msm_debugfs.c 
> > > > > b/drivers/gpu/drm/msm/msm_debugfs.c
> > > > > index 6be879578140..1c74381a4fc9 100644
> > > > > --- a/drivers/gpu/drm/msm/msm_debugfs.c
> > > > > +++ b/drivers/gpu/drm/msm/msm_debugfs.c
> > > > > @@ -47,12 +47,8 @@ static int msm_gpu_release(struct inode *inode, 
> > > > > struct file *file)
> > > > >   struct msm_gpu_show_priv *show_priv = m->private;
> > > > >   struct msm_drm_private *priv = show_priv->dev->dev_private;
> > > > >   struct msm_gpu *gpu = priv->gpu;
> > > > > - int ret;
> > > > > -
> > > > > - ret = mutex_lock_interruptible(_priv->dev->struct_mutex);
> > > > > - if (ret)
> > > > > - return ret;
> > > > >
> > > > > + mutex_lock(_priv->dev->struct_mutex);
> > > > >   gpu->funcs->gpu_state_put(show_priv->state);
> > > > >   mutex_unlock(_priv->dev->struct_mutex);
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch

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

Re: [Freedreno] [PATCH 14/16] drm/msm: avoid using 'timespec'

2019-11-12 Thread Jordan Crouse
On Fri, Nov 08, 2019 at 10:32:52PM +0100, Arnd Bergmann wrote:
> The timespec structure and associated interfaces are deprecated and will
> be removed in the future because of the y2038 overflow.
> 
> The use of ktime_to_timespec() in timeout_to_jiffies() does not
> suffer from that overflow, but is easy to avoid by just converting
> the ktime_t into jiffies directly.

This seems good to me. y2038 changes are the best changes.

Reviewed-by: Jordan Crouse 

> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/gpu/drm/msm/msm_drv.h | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
> index 71547e756e29..740bf7c70d8f 100644
> --- a/drivers/gpu/drm/msm/msm_drv.h
> +++ b/drivers/gpu/drm/msm/msm_drv.h
> @@ -454,8 +454,7 @@ static inline unsigned long timeout_to_jiffies(const 
> ktime_t *timeout)
>   remaining_jiffies = 0;
>   } else {
>   ktime_t rem = ktime_sub(*timeout, now);
> - struct timespec ts = ktime_to_timespec(rem);
> - remaining_jiffies = timespec_to_jiffies();
> + remaining_jiffies = ktime_divns(rem, NSEC_PER_SEC / HZ);
>   }
>  
>   return remaining_jiffies;
> -- 
> 2.20.0
> 

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno

Re: [Freedreno] [PATCH RESEND] drm/msm/adreno: Do not print error on "qcom, gpu-pwrlevels" absence

2019-11-12 Thread Jordan Crouse
On Tue, Nov 12, 2019 at 01:40:22PM -0300, Fabio Estevam wrote:
> Hi Jordan,
> 
> On Fri, Nov 1, 2019 at 11:52 AM Jordan Crouse  wrote:
> 
> > I'm good with this. This really should only be around for
> > compatibility with downstream device tree files which should mean nothing 
> > for
> > I.MX5.
> 
> May I resend it with your Reviewed-by tag?

Of course.

Jordan
-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno

Re: [Freedreno] [PATCH RESEND] drm/msm/adreno: Do not print error on "qcom, gpu-pwrlevels" absence

2019-11-12 Thread Fabio Estevam
Hi Jordan,

On Fri, Nov 1, 2019 at 11:52 AM Jordan Crouse  wrote:

> I'm good with this. This really should only be around for
> compatibility with downstream device tree files which should mean nothing for
> I.MX5.

May I resend it with your Reviewed-by tag?

Thanks
___
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno

[Freedreno] Add support for DisplayPort driver on SnapDragon 845 - 5.2.0 kernel from Linaro.

2019-11-12 Thread vadiraj kaveri
Hi Chandan,

I am trying to enable DP on 5.2.0 based kernel from Linaro, using Inforce
Computing SnapDragon 845 based board. I have integrated your DP patches
done on 4.9 kernel.
I am getting some compile errors as listed below. Please let me know if you
have some pointers for that, also do you have plans to integrate on 5.2
kernel? Please let me know.

*** Default configuration is based on 'defconfig'
arch/arm64/configs/defconfig:346:warning: override: reassigning to symbol
SERIAL_QCOM_GENI
arch/arm64/configs/defconfig:347:warning: override: reassigning to symbol
SERIAL_QCOM_GENI_CONSOLE
arch/arm64/configs/defconfig:406:warning: override: reassigning to symbol
PINCTRL_SDM845
arch/arm64/configs/defconfig:859:warning: override: reassigning to symbol
DMA_CMA
arch/arm64/configs/defconfig:870:warning: override: reassigning to symbol
SECURITY
arch/arm64/configs/defconfig:871:warning: override: reassigning to symbol
CRYPTO_ECHAINIV
arch/arm64/configs/defconfig:872:warning: override: reassigning to symbol
CRYPTO_ANSI_CPRNG
arch/arm64/configs/defconfig:874:warning: override: reassigning to symbol
ARM64_CRYPTO
arch/arm64/configs/defconfig:875:warning: override: reassigning to symbol
CRYPTO_SHA1_ARM64_CE
arch/arm64/configs/defconfig:876:warning: override: reassigning to symbol
CRYPTO_SHA2_ARM64_CE
arch/arm64/configs/defconfig:877:warning: override: reassigning to symbol
CRYPTO_SHA512_ARM64_CE
arch/arm64/configs/defconfig:878:warning: override: reassigning to symbol
CRYPTO_SHA3_ARM64
arch/arm64/configs/defconfig:879:warning: override: reassigning to symbol
CRYPTO_SM3_ARM64_CE
arch/arm64/configs/defconfig:880:warning: override: reassigning to symbol
CRYPTO_GHASH_ARM64_CE
arch/arm64/configs/defconfig:881:warning: override: reassigning to symbol
CRYPTO_CRCT10DIF_ARM64_CE
arch/arm64/configs/defconfig:882:warning: override: reassigning to symbol
CRYPTO_AES_ARM64_CE_CCM
arch/arm64/configs/defconfig:883:warning: override: reassigning to symbol
CRYPTO_AES_ARM64_CE_BLK
arch/arm64/configs/defconfig:884:warning: override: reassigning to symbol
CRYPTO_CHACHA20_NEON
arch/arm64/configs/defconfig:885:warning: override: reassigning to symbol
CRYPTO_AES_ARM64_BS
arch/arm64/configs/defconfig:895:warning: symbol value 'm' invalid for
BT_HCIUART_QCA
#
# No change to .config
#
  CALLscripts/atomic/check-atomics.sh
  CALLscripts/checksyscalls.sh
  CHK include/generated/compile.h
  CC  drivers/gpu/drm/msm/dp/dp_power.o
  CC  drivers/gpu/drm/msm/msm_fbdev.o
  CC  drivers/gpu/drm/msm/disp/mdp4/mdp4_lvds_pll.o
  CC  drivers/gpu/drm/msm/hdmi/hdmi_pll_8960.o
drivers/gpu/drm/msm/dp/dp_power.c: In function ‘msm_dss_enable_vreg’:
drivers/gpu/drm/msm/dp/dp_power.c:128:5: error: implicit declaration of
function ‘usleep_range’ [-Werror=implicit-function-declaration]
 usleep_range(in_vreg[i].pre_on_sleep * 1000,
 ^~~~
drivers/gpu/drm/msm/dp/dp_power.c: In function ‘dp_power_clk_init’:
drivers/gpu/drm/msm/dp/dp_power.c:289:19: error: ‘struct dp_parser’ has no
member named ‘pll’
  if (power->parser->pll && power->parser->pll->get_provider) {
   ^~
drivers/gpu/drm/msm/dp/dp_power.c:289:41: error: ‘struct dp_parser’ has no
member named ‘pll’
  if (power->parser->pll && power->parser->pll->get_provider) {
 ^~
drivers/gpu/drm/msm/dp/dp_power.c:290:21: error: ‘struct dp_parser’ has no
member named ‘pll’
   rc = power->parser->pll->get_provider(power->parser->pll,
 ^~
drivers/gpu/drm/msm/dp/dp_power.c:290:54: error: ‘struct dp_parser’ has no
member named ‘pll’
   rc = power->parser->pll->get_provider(power->parser->pll,
  ^~
In file included from drivers/gpu/drm/msm/dp/dp_power.c:9:0:
drivers/gpu/drm/msm/dp/dp_power.c: In function
‘dp_power_set_link_clk_parent’:
drivers/gpu/drm/msm/dp/dp_power.c:597:7: error: implicit declaration of
function ‘__clk_get_name’ [-Werror=implicit-function-declaration]
   __clk_get_name(power->link_provider),
   ^
./include/drm/drm_print.h:387:29: note: in definition of macro
‘DRM_DEBUG_DP’
  drm_dbg(DRM_UT_DP, fmt, ## __VA_ARGS__)
 ^~~
drivers/gpu/drm/msm/dp/dp_power.c:596:18: warning: format ‘%s’ expects
argument of type ‘char *’, but argument 3 has type ‘int’ [-Wformat=]
 DRM_DEBUG_DP("%s: is the parent of clk=%s\n",
  ^
./include/drm/drm_print.h:387:21: note: in definition of macro
‘DRM_DEBUG_DP’
  drm_dbg(DRM_UT_DP, fmt, ## __VA_ARGS__)
 ^~~
drivers/gpu/drm/msm/dp/dp_power.c:596:18: warning: format ‘%s’ expects
argument of type ‘char *’, but argument 4 has type ‘int’ [-Wformat=]
 DRM_DEBUG_DP("%s: is the parent of clk=%s\n",
  ^
./include/drm/drm_print.h:387:21: note: in definition of macro
‘DRM_DEBUG_DP’
  drm_dbg(DRM_UT_DP, fmt, ## __VA_ARGS__)
 ^~~
drivers/gpu/drm/msm/dp/dp_power.c: In function
‘dp_power_set_pixel_clk_parent’:

Re: [Freedreno] [PATCH 1/4] drm/msm: fix memleak on release

2019-11-12 Thread Rob Clark
On Tue, Nov 12, 2019 at 6:01 AM Daniel Vetter  wrote:
>
> On Tue, Nov 12, 2019 at 11:40:01AM +0100, Johan Hovold wrote:
> > On Wed, Oct 30, 2019 at 11:01:46AM +0100, Johan Hovold wrote:
> > > On Thu, Oct 10, 2019 at 03:13:30PM +0200, Johan Hovold wrote:
> > > > If a process is interrupted while accessing the "gpu" debugfs file and
> > > > the drm device struct_mutex is contended, release() could return early
> > > > and fail to free related resources.
> > > >
> > > > Note that the return value from release() is ignored.
> > > >
> > > > Fixes: 4f776f4511c7 ("drm/msm/gpu: Convert the GPU show function to use 
> > > > the GPU state")
> > > > Cc: stable  # 4.18
> > > > Cc: Jordan Crouse 
> > > > Cc: Rob Clark 
> > > > Signed-off-by: Johan Hovold 
> > > > ---
> > >
> > > Rob, Sean,
> > >
> > > Sending a reminder about this one, which is not yet in linux-next.
> > >
> > > Perhaps Daniel can pick it up otherwise?
> >
> > Another two weeks, another reminder. This one is still not in -next.
>
> Well msm is maintained in a separate tree, so the usual group maintainer
> fallback for when patches are stuck doesn't apply.

oh, sorry, this wasn't showing up in patchwork.. or rather it did but
the non-msm related series subject made me overlook it.

I've already sent a PR, but this shouldn't conflict with anything and
I think it can go in via drm-misc/fixes

Reviewed-by: Rob Clark 

> Rob, Sean, time to reconsider drm-misc for msm? I think there's some more
> oddball patches that occasionally get stuck for msm ...
>
> Also +Dave.
> -Daniel
>
> >
> > Johan
> >
> > > >  drivers/gpu/drm/msm/msm_debugfs.c | 6 +-
> > > >  1 file changed, 1 insertion(+), 5 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/msm/msm_debugfs.c 
> > > > b/drivers/gpu/drm/msm/msm_debugfs.c
> > > > index 6be879578140..1c74381a4fc9 100644
> > > > --- a/drivers/gpu/drm/msm/msm_debugfs.c
> > > > +++ b/drivers/gpu/drm/msm/msm_debugfs.c
> > > > @@ -47,12 +47,8 @@ static int msm_gpu_release(struct inode *inode, 
> > > > struct file *file)
> > > >   struct msm_gpu_show_priv *show_priv = m->private;
> > > >   struct msm_drm_private *priv = show_priv->dev->dev_private;
> > > >   struct msm_gpu *gpu = priv->gpu;
> > > > - int ret;
> > > > -
> > > > - ret = mutex_lock_interruptible(_priv->dev->struct_mutex);
> > > > - if (ret)
> > > > - return ret;
> > > >
> > > > + mutex_lock(_priv->dev->struct_mutex);
> > > >   gpu->funcs->gpu_state_put(show_priv->state);
> > > >   mutex_unlock(_priv->dev->struct_mutex);
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
___
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno

Re: [Freedreno] [PATCH] drm/msm/mdp5: enable autocommit

2019-11-12 Thread Jeffrey Hugo
On Tue, Nov 12, 2019 at 3:49 AM Brian Masney  wrote:
>
> Since the introduction of commit 2d99ced787e3 ("drm/msm: async commit
> support"), command-mode panels began throwing the following errors:
>
> msm fd90.mdss: pp done time out, lm=0
>
> Let's fix this by enabling the autorefresh feature that's available in
> the MDP starting at version 1.0. This will cause the MDP to
> automatically send a frame to the panel every time the panel invokes
> the TE signal, which will trigger the PP_DONE IRQ. This requires not
> sending a START signal for command-mode panels.
>
> This fixes the error and gives us a counter for command-mode panels that
> we can use to implement async commit support for the MDP5 in a follow up
> patch.
>
> Signed-off-by: Brian Masney 
> Suggested-by: Jeffrey Hugo 
> ---
>  drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 15 ++-
>  drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c  |  9 +
>  2 files changed, 15 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c 
> b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
> index 05cc04f729d6..539348cb6331 100644
> --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
> +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
> @@ -456,6 +456,7 @@ static void mdp5_crtc_atomic_enable(struct drm_crtc *crtc,
>  {
> struct mdp5_crtc *mdp5_crtc = to_mdp5_crtc(crtc);
> struct mdp5_crtc_state *mdp5_cstate = to_mdp5_crtc_state(crtc->state);
> +   struct mdp5_pipeline *pipeline = _cstate->pipeline;
> struct mdp5_kms *mdp5_kms = get_kms(crtc);
> struct device *dev = _kms->pdev->dev;
>
> @@ -493,9 +494,21 @@ static void mdp5_crtc_atomic_enable(struct drm_crtc 
> *crtc,
>
> mdp_irq_register(_kms->base, _crtc->err);
>
> -   if (mdp5_cstate->cmd_mode)
> +   if (mdp5_cstate->cmd_mode) {
> mdp_irq_register(_kms->base, _crtc->pp_done);
>
> +   /*
> +* Enable autorefresh so we get regular ping/pong IRQs.
> +* - Bit 31 is the enable bit
> +* - Bits 0-15 represent the frame count, specifically how 
> many
> +*   TE events before the MDP sends a frame.
> +*/
> +   mdp5_write(mdp5_kms,
> +  
> REG_MDP5_PP_AUTOREFRESH_CONFIG(pipeline->mixer->pp),
> +  BIT(31) | BIT(0));
> +   crtc_flush_all(crtc);
> +   }
> +
> mdp5_crtc->enabled = true;
>  }
>
> diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c 
> b/drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c
> index 030279d7b64b..aee295abada3 100644
> --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c
> +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c
> @@ -187,14 +187,7 @@ static bool start_signal_needed(struct mdp5_ctl *ctl,
> if (!ctl->encoder_enabled)
> return false;
>
> -   switch (intf->type) {
> -   case INTF_WB:
> -   return true;
> -   case INTF_DSI:
> -   return intf->mode == MDP5_INTF_DSI_MODE_COMMAND;
> -   default:
> -   return false;
> -   }
> +   return intf->type == INTF_WB;
>  }

I don't think this fully works.

The whole "flush" thing exists because the configuration is double
buffered.  You write to the flush register to tell the hardware to
pickup the new configuration, but it doesn't do that automatically.
It only picks up the new config on the next "vsync".  When you have a
video mode panel, you have the timing engine running, which drives
that.  With a command mode panel, you have either the start signal, or
the auto refresh to do the same, but you have a bit of a chicken and
egg situation where if you are programming the hardware from scratch,
autorefresh isn't already enabled to then pickup the config to enable
autorefresh. In this case, you'll need a single start to kick
everything off.  However, if say the bootloader already configured
things and has autorefresh running, then you need to not do that start
because you'll overload the DSI like you saw.

Nothing is simple, is it?  :)
___
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno

Re: [Freedreno] [PATCH 1/4] drm/msm: fix memleak on release

2019-11-12 Thread Daniel Vetter
On Tue, Nov 12, 2019 at 11:40:01AM +0100, Johan Hovold wrote:
> On Wed, Oct 30, 2019 at 11:01:46AM +0100, Johan Hovold wrote:
> > On Thu, Oct 10, 2019 at 03:13:30PM +0200, Johan Hovold wrote:
> > > If a process is interrupted while accessing the "gpu" debugfs file and
> > > the drm device struct_mutex is contended, release() could return early
> > > and fail to free related resources.
> > > 
> > > Note that the return value from release() is ignored.
> > > 
> > > Fixes: 4f776f4511c7 ("drm/msm/gpu: Convert the GPU show function to use 
> > > the GPU state")
> > > Cc: stable  # 4.18
> > > Cc: Jordan Crouse 
> > > Cc: Rob Clark 
> > > Signed-off-by: Johan Hovold 
> > > ---
> > 
> > Rob, Sean,
> > 
> > Sending a reminder about this one, which is not yet in linux-next.
> > 
> > Perhaps Daniel can pick it up otherwise?
> 
> Another two weeks, another reminder. This one is still not in -next.

Well msm is maintained in a separate tree, so the usual group maintainer
fallback for when patches are stuck doesn't apply.

Rob, Sean, time to reconsider drm-misc for msm? I think there's some more
oddball patches that occasionally get stuck for msm ...

Also +Dave.
-Daniel

> 
> Johan
> 
> > >  drivers/gpu/drm/msm/msm_debugfs.c | 6 +-
> > >  1 file changed, 1 insertion(+), 5 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/msm/msm_debugfs.c 
> > > b/drivers/gpu/drm/msm/msm_debugfs.c
> > > index 6be879578140..1c74381a4fc9 100644
> > > --- a/drivers/gpu/drm/msm/msm_debugfs.c
> > > +++ b/drivers/gpu/drm/msm/msm_debugfs.c
> > > @@ -47,12 +47,8 @@ static int msm_gpu_release(struct inode *inode, struct 
> > > file *file)
> > >   struct msm_gpu_show_priv *show_priv = m->private;
> > >   struct msm_drm_private *priv = show_priv->dev->dev_private;
> > >   struct msm_gpu *gpu = priv->gpu;
> > > - int ret;
> > > -
> > > - ret = mutex_lock_interruptible(_priv->dev->struct_mutex);
> > > - if (ret)
> > > - return ret;
> > >  
> > > + mutex_lock(_priv->dev->struct_mutex);
> > >   gpu->funcs->gpu_state_put(show_priv->state);
> > >   mutex_unlock(_priv->dev->struct_mutex);

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

Re: [Freedreno] drm/msm: 'pp done time out' errors after async commit changes

2019-11-12 Thread Brian Masney
On Mon, Nov 11, 2019 at 07:51:22AM -0700, Jeffrey Hugo wrote:
> On Mon, Nov 11, 2019 at 4:38 AM Brian Masney  wrote:
> >
> > On Sun, Nov 10, 2019 at 10:37:33AM -0700, Jeffrey Hugo wrote:
> > > On Sun, Nov 10, 2019 at 6:53 AM Brian Masney  
> > > wrote:
> > > >
> > > > On Fri, Nov 08, 2019 at 07:56:25AM -0700, Jeffrey Hugo wrote:
> > > > There's a REG_MDP5_PP_AUTOREFRESH_CONFIG() macro upstream here:
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/msm/disp/mdp5/mdp5.xml.h#n1383
> > > >
> > > > I'm not sure what to put in that register but I tried configuring it
> > > > with a 1 this way and still have the same issue.
> > > >
> > > > diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c 
> > > > b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c
> > > > index eeef41fcd4e1..6b9acf68fd2c 100644
> > > > --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c
> > > > +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c
> > > > @@ -80,6 +80,7 @@ static int pingpong_tearcheck_setup(struct 
> > > > drm_encoder *encoder,
> > > > mdp5_write(mdp5_kms, REG_MDP5_PP_SYNC_THRESH(pp_id),
> > > > MDP5_PP_SYNC_THRESH_START(4) |
> > > > MDP5_PP_SYNC_THRESH_CONTINUE(4));
> > > > +   mdp5_write(mdp5_kms, REG_MDP5_PP_AUTOREFRESH_CONFIG(pp_id), 1);
> > > >
> > > > return 0;
> > > >  }
> > >
> > > bit 31 is the enable bit (set that to 1), bits 15:0 are the
> > > frame_count (how many te events before the MDP sends a frame, I'd
> > > recommend set to 1).  Then after its programmed, you'll have to flush
> > > the config, and probably use a _START to make sure the flush takes
> > > effect.
> >
> > I think that I initially get autorefresh enabled based on your
> > description above since the ping pong IRQs occur much more frequently.
> > However pretty quickly the error 'dsi_err_worker: status=c' is shown,
> > the contents on the screen shift to the right, and the screen no longer
> > updates after that. That error decodes to
> > DSI_ERR_STATE_DLN0_PHY | DSI_ERR_STATE_FIFO according to dsi_host.c.
> >
> > Here's the relevant code that I have so far:
> 
> So, Unless I missed it, you haven't disabled using _start when
> autorefresh is enabled.  If you are using both at the same time,
> you'll overload the DSI and get those kinds of errors.

That fixed the issue. Just to close out this thread, I submitted a
patch with what I have here:
https://lore.kernel.org/lkml/20191112104854.20850-1-masn...@onstation.org/T/#u

I'll work on async commit support for the MDP5.

Thanks Jeff and Rob!

Brian
___
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno

[Freedreno] [PATCH] drm/msm/mdp5: enable autocommit

2019-11-12 Thread Brian Masney
Since the introduction of commit 2d99ced787e3 ("drm/msm: async commit
support"), command-mode panels began throwing the following errors:

msm fd90.mdss: pp done time out, lm=0

Let's fix this by enabling the autorefresh feature that's available in
the MDP starting at version 1.0. This will cause the MDP to
automatically send a frame to the panel every time the panel invokes
the TE signal, which will trigger the PP_DONE IRQ. This requires not
sending a START signal for command-mode panels.

This fixes the error and gives us a counter for command-mode panels that
we can use to implement async commit support for the MDP5 in a follow up
patch.

Signed-off-by: Brian Masney 
Suggested-by: Jeffrey Hugo 
---
 drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 15 ++-
 drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c  |  9 +
 2 files changed, 15 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
index 05cc04f729d6..539348cb6331 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
@@ -456,6 +456,7 @@ static void mdp5_crtc_atomic_enable(struct drm_crtc *crtc,
 {
struct mdp5_crtc *mdp5_crtc = to_mdp5_crtc(crtc);
struct mdp5_crtc_state *mdp5_cstate = to_mdp5_crtc_state(crtc->state);
+   struct mdp5_pipeline *pipeline = _cstate->pipeline;
struct mdp5_kms *mdp5_kms = get_kms(crtc);
struct device *dev = _kms->pdev->dev;
 
@@ -493,9 +494,21 @@ static void mdp5_crtc_atomic_enable(struct drm_crtc *crtc,
 
mdp_irq_register(_kms->base, _crtc->err);
 
-   if (mdp5_cstate->cmd_mode)
+   if (mdp5_cstate->cmd_mode) {
mdp_irq_register(_kms->base, _crtc->pp_done);
 
+   /*
+* Enable autorefresh so we get regular ping/pong IRQs.
+* - Bit 31 is the enable bit
+* - Bits 0-15 represent the frame count, specifically how many
+*   TE events before the MDP sends a frame.
+*/
+   mdp5_write(mdp5_kms,
+  REG_MDP5_PP_AUTOREFRESH_CONFIG(pipeline->mixer->pp),
+  BIT(31) | BIT(0));
+   crtc_flush_all(crtc);
+   }
+
mdp5_crtc->enabled = true;
 }
 
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c
index 030279d7b64b..aee295abada3 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c
@@ -187,14 +187,7 @@ static bool start_signal_needed(struct mdp5_ctl *ctl,
if (!ctl->encoder_enabled)
return false;
 
-   switch (intf->type) {
-   case INTF_WB:
-   return true;
-   case INTF_DSI:
-   return intf->mode == MDP5_INTF_DSI_MODE_COMMAND;
-   default:
-   return false;
-   }
+   return intf->type == INTF_WB;
 }
 
 /*
-- 
2.21.0

___
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno

Re: [Freedreno] [PATCH 1/4] drm/msm: fix memleak on release

2019-11-12 Thread Johan Hovold
On Wed, Oct 30, 2019 at 11:01:46AM +0100, Johan Hovold wrote:
> On Thu, Oct 10, 2019 at 03:13:30PM +0200, Johan Hovold wrote:
> > If a process is interrupted while accessing the "gpu" debugfs file and
> > the drm device struct_mutex is contended, release() could return early
> > and fail to free related resources.
> > 
> > Note that the return value from release() is ignored.
> > 
> > Fixes: 4f776f4511c7 ("drm/msm/gpu: Convert the GPU show function to use the 
> > GPU state")
> > Cc: stable  # 4.18
> > Cc: Jordan Crouse 
> > Cc: Rob Clark 
> > Signed-off-by: Johan Hovold 
> > ---
> 
> Rob, Sean,
> 
> Sending a reminder about this one, which is not yet in linux-next.
> 
> Perhaps Daniel can pick it up otherwise?

Another two weeks, another reminder. This one is still not in -next.

Johan

> >  drivers/gpu/drm/msm/msm_debugfs.c | 6 +-
> >  1 file changed, 1 insertion(+), 5 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/msm/msm_debugfs.c 
> > b/drivers/gpu/drm/msm/msm_debugfs.c
> > index 6be879578140..1c74381a4fc9 100644
> > --- a/drivers/gpu/drm/msm/msm_debugfs.c
> > +++ b/drivers/gpu/drm/msm/msm_debugfs.c
> > @@ -47,12 +47,8 @@ static int msm_gpu_release(struct inode *inode, struct 
> > file *file)
> > struct msm_gpu_show_priv *show_priv = m->private;
> > struct msm_drm_private *priv = show_priv->dev->dev_private;
> > struct msm_gpu *gpu = priv->gpu;
> > -   int ret;
> > -
> > -   ret = mutex_lock_interruptible(_priv->dev->struct_mutex);
> > -   if (ret)
> > -   return ret;
> >  
> > +   mutex_lock(_priv->dev->struct_mutex);
> > gpu->funcs->gpu_state_put(show_priv->state);
> > mutex_unlock(_priv->dev->struct_mutex);
___
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno