On 2018-11-13 12:52, Sean Paul wrote:
From: Sean Paul
Instead of assigning/clearing the crtc on vblank enable/disable, we can
just assign and clear the crtc on modeset. That allows us to just
toggle
the encoder's vblank interrupts on vblank_enable.
So why is this important? Previously the
On 2018-11-13 12:52, Sean Paul wrote:
From: Sean Paul
It's just for debug output, we don't need it
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 6 --
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 2 --
drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h | 14
On 2018-11-13 12:52, Sean Paul wrote:
From: Sean Paul
The indirection of registering a callback and opaque pointer isn't real
useful when there's only one callsite. So instead of having the
vblank_cb registration, just give encoder a crtc and let it directly
call the vblank handler.
In a
On Tue, Nov 13, 2018 at 03:52:44PM -0500, Sean Paul wrote:
> From: Sean Paul
I neglected to add --cover-letter to send-email, so pasting my cover here
instead:
Hi all,
So I kept digging into the locking and dependencies around encoder/crtc and this
is the latest series to pop out. I think
From: Sean Paul
It's just for debug output, we don't need it
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 6 --
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 2 --
drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h | 14 --
3 files changed, 4 insertions(+),
From: Sean Paul
Each time it's called we're holding the crtc modeset lock, so it's
redundant.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 11 ---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 3 ---
2 files changed, 14 deletions(-)
diff --git
From: Sean Paul
Matches dpu_crtc_enable and we'll need the old state in a future patch
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
From: Sean Paul
Instead of assigning/clearing the crtc on vblank enable/disable, we can
just assign and clear the crtc on modeset. That allows us to just toggle
the encoder's vblank interrupts on vblank_enable.
So why is this important? Previously the driver was using the legacy
pointers to
From: Sean Paul
The drm_crtc_vblank_on/off calls in enable/disable guarantee that we
won't call this function when crtc is not enabled.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git
From: Sean Paul
I think the intention here was to protect the enc->crtc access, but
that's insufficient to avoid enc->crtc changing. Fortunately we're
already holding the modeset lock when this is called (from
atomic_check), so remove the crtc_lock and add a modeset lock check.
While we're at
From: Sean Paul
There are 4 times that _dpu_crtc_vblank_enable_no_lock() is called:
1- crtc enable
2- crtc disable
3- crtc vblank enable
4- crtc vblank disable
When we enable or disable the crtc, we call drm_crtc_vblank_on and
drm_crtc_vblank_off respectively. That will gate vblank enables and
From: Sean Paul
The indirection of registering a callback and opaque pointer isn't real
useful when there's only one callsite. So instead of having the
vblank_cb registration, just give encoder a crtc and let it directly
call the vblank handler.
In a later patch, we'll make use of this further.
From: Sean Paul
Now that runtime resume is handled in encoder, we don't need to worry
about crtc_lock recursion when calling pm_runtime_(get|put). So drop the
lock drops in _dpu_crtc_vblank_enable_no_lock().
Changes in v2:
- Added to patch series
Signed-off-by: Sean Paul
---
On Fri, Nov 09, 2018 at 11:37:17AM +0530, Rajendra Nayak wrote:
>
> On 11/2/2018 6:19 PM, Jayant Shekhar wrote:
> > In case of msm drm bind failure, dpu_mdss_destroy is triggered.
> > In this function, resources are freed and pm runtime disable is
> > called, which triggers dpu_mdss_disable. Now
From: Sean Paul
power_events are only used for pm_runtime, and that's all handled in
dpu_kms. So just call vbif_init_memtypes at the correct times.
Changes in v2:
- Removed obsolete comment (Jeykumar)
Cc: Jeykumar Sankaran
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
On Mon, Nov 12, 2018 at 05:47:58PM -0800, Jeykumar Sankaran wrote:
> On 2018-11-12 11:42, Sean Paul wrote:
> > From: Sean Paul
> >
> > The crtc runtime resume doesn't actually operate on the crtc, but rather
> > its encoders. The problem with this is that we need to inspect the crtc
> > state to
On Mon, Nov 12, 2018 at 05:43:17PM -0800, Jeykumar Sankaran wrote:
> On 2018-11-12 11:42, Sean Paul wrote:
> > From: Sean Paul
> >
> > Add a bool to dpu_encoder_virt to track whether the encoder is enabled
> > or not. Repurpose the enc_lock mutex to ensure that it is consistent
> > with the hw
On Mon, Nov 12, 2018 at 05:20:28PM -0800, Jeykumar Sankaran wrote:
> On 2018-11-12 11:42, Sean Paul wrote:
> > From: Sean Paul
> >
> > Instead of registering through dpu_power_handle just to get a call on
> > runtime_resume, call the crtc function directly.
> >
> > Signed-off-by: Sean Paul
> >
On Tue, Nov 13, 2018 at 1:32 AM Will Deacon wrote:
>
> On Fri, Nov 09, 2018 at 01:01:55PM -0500, Rob Clark wrote:
> > On Mon, Oct 29, 2018 at 3:09 PM Will Deacon wrote:
> > > On Thu, Sep 27, 2018 at 06:46:07PM -0400, Rob Clark wrote:
> > > > We seem to need to set either this or CFCFG (stall),
19 matches
Mail list logo
