Re: [PATCH] drm/msm/mdp5: enable clocks in hw_init and set_irqmask

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 08/28/2015 11:48 PM, Rob Clark wrote:
On Fri, Aug 28, 2015 at 3:56 AM, Archit Taneja <architt@xxxxxxxxxxxxxx> wrote:


On 08/27/2015 10:36 AM, Archit Taneja wrote:



On 08/26/2015 08:42 PM, hali@xxxxxxxxxxxxxx wrote:

2015-08-26 9:55 GMT-04:00  <hali@xxxxxxxxxxxxxx>:

Hi Archit,

mdp5_hw_init and mdp5_set_irqmask configure registers but may not have
clocks enabled.

Add mdp5_enable/disable calls in these funcs to ensure clocks are
enabled. We need this until we get proper runtime pm support.

Signed-off-by: Archit Taneja <architt@xxxxxxxxxxxxxx>
---
   drivers/gpu/drm/msm/mdp/mdp5/mdp5_irq.c | 10 ++++++++--
   drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c |  2 ++
   2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_irq.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_irq.c
index b1f73be..9fabfca 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_irq.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_irq.c
@@ -24,9 +24,15 @@
   void mdp5_set_irqmask(struct mdp_kms *mdp_kms, uint32_t irqmask,
                uint32_t old_irqmask)
   {
-     mdp5_write(to_mdp5_kms(mdp_kms), REG_MDP5_MDP_INTR_CLEAR(0),
+     struct mdp5_kms *mdp5_kms = to_mdp5_kms(mdp_kms);
+
+     mdp5_enable(mdp5_kms);
+
+     mdp5_write(mdp5_kms, REG_MDP5_MDP_INTR_CLEAR(0),
                irqmask ^ (irqmask & old_irqmask));
-     mdp5_write(to_mdp5_kms(mdp_kms), REG_MDP5_MDP_INTR_EN(0),
irqmask);
+     mdp5_write(mdp5_kms, REG_MDP5_MDP_INTR_EN(0), irqmask);
+
+     mdp5_disable(mdp5_kms);
   }


mdp5_set_irqmask() can be invoked in atomic context, clk_prepare() is
not
allowed in this function because it may cause process to sleep. We can
enable the clocks in the caller at initialization.


Oh, oops. I missed that.


iirc, it will be called with at least one spinlock held..

We do already move the enable/disable_vblank() paths off to a worker
so that we can ensure things are enabled before we get into
update_irq()..  the only other path to update_irq() should be when
driver code does mdp_irq_register/unregister().. so maybe we should
just require that the mdp4/mdp5 kms code only calls those when clk's
are already enabled (which should be mostly true already, I think)

BR,
-R


Yes, the only case that not been covered is mdp5_irq_postinstall(). We
can
enable clocks in this function. Actually, this is what we are doing in
downstream test.


It works fine if I put it in postinstall. I'll update the patch and
resend.


So, I hit an issue in both the approaches.

When I try modeset, I get a watchdog reset once the app closes down.

I meant modetest here*


Looking at debug logs, it looks like the issue happens when the ioctl
RMFB and drm_release race with each other.

hmm, this seems a bit strange.. since to do the RMFB ioctl the device
must still be open.. do we end up w/ the RMFB being an async commit
somehow?  (Although in case of flip w/ gpu rendering still pending,
somewhere we probably want to block on previous async commit?)

It isn't a race condition as I thought before. The RMFB ioctl isn't
asynchronous either.

The problem has to do with how msm_atomic_commit behaves when the
state we want to commit involves disabling the crtc:

In this case, we grab clocks once (in mdp5_prepare_commit), but
disable them twice (first, via mdp5_crtc_disable() in disable_outputs(),
and then in mdp5_complete_commit())

Whatever comes next will crash if it requires clocks. In this case,
drm_release's call to mdp5_crtc_cancel_pending_flip() is the first
thing that needs clocks, and it crashes there.


Within the the msm driver, this maps to mdp5_complete_commit
(drm_mode_rmfb path) being called before mdp5_crtc_cancel_pending_flip
(drm_release path). mdp5_complete_commit disables clocks, and the other
patch calls complete_flip, which requires clocks.

If I wrap around complete_flip with mdp5_enable/disable calls, things
work fine. Although, that's not an ideal fix.

I guess it is a reasonable thing to do.. but on that topic, it would
be nice if someone had some time to look and the pending atomic
suspend/resume/runtime-pm stuff.  I haven't really had time to follow
that, but I guess it is a good time to revisit the mdpN_enable/disable
stuff?

Yeah, that'd be more ideal. We're looking at runtime pm adaptation now.

Thanks,
Archit


--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux