On 11/20/2018 5:17 AM, Jordan Crouse wrote:
In very extreme cases an individual gdsc may wish to override the
power domain enable or disable callback functions for their own
purposes. Only set the generic gdsc callback if the function pointers
are not already set.
Signed-off-by: Jordan Crouse
Most of the time the CPU should not be touching the GX
domain on the GPU except for a very special use case when
the CPU needs to force the GX headswitch off. Add a
dummy enable function for the GX gdsc to simulate success
so that the pm_runtime reference counting is correct.
Signed-off-by: Jordan
In very extreme cases an individual gdsc may wish to override the
power domain enable or disable callback functions for their own
purposes. Only set the generic gdsc callback if the function pointers
are not already set.
Signed-off-by: Jordan Crouse
---
drivers/clk/qcom/gdsc.c | 6 --
1 file
The GMU code currently has some misguided code to try to work around
a hardware quirk that requires the power domains on the GPU be
collapsed in a certain order. Upcoming patches will do this the
right way so get rid of the unused and unwanted regulator
code.
Signed-off-by: Jordan Crouse
---
dri
99.999% of the time during normal operation the GMU is responsible
for power and clock control on the GX domain and the CPU remains
blissfully unaware. However, there is one situation where the CPU
needs to get involved:
The power sequencing rules dictate that the GX needs to be turned
off before
The GPU GX domain on SDM845 is nominally managed by the GMU microcontroller
but there are certain circumstances when the CPU needs to be sure that the
GX headswitch is off.
This RFC series adds a special modification for the GX power domain
that always returns success for domain power on and uses
On 2018-11-16 10:42, Sean Paul wrote:
From: Sean Paul
Each time it's called we're holding the crtc modeset lock, so it's
redundant.
Changes in v2:
- None
Signed-off-by: Sean Paul
Reviewed-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 11 ---
drivers/gpu/d
On 2018-11-16 10:42, Sean Paul wrote:
From: Sean Paul
It's just for debugfs output, we don't need it
Changes in v2:
- None
Cc: Jeykumar Sankaran
Signed-off-by: Sean Paul
Reviewed-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 6 --
drivers/gpu/drm/msm/disp/
On 2018-11-16 10:42, Sean Paul wrote:
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.
Changes in v2:
- None
Signed-off-by: Sean Paul
Reviewed-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/
On 2018-11-16 10:42, 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 dr
On 2018-11-16 10:42, Sean Paul wrote:
From: Sean Paul
Matches dpu_crtc_enable and we'll need the old state in a future patch
Changes in v2:
- None
Signed-off-by: Sean Paul
Reviewed-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 5 +++--
1 file changed, 3 insertion
On 2018-11-16 10:42, Sean Paul wrote:
From: Sean Paul
The indirection of registering a callback and opaque pointer isn't
reall
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 la
On 2018-11-16 10:42, Sean Paul wrote:
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
On 2018-11-16 10:42, Sean Paul wrote:
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 respecti
On 2018-11-16 13:14, Sean Paul wrote:
On Fri, Nov 16, 2018 at 12:05:09PM -0800, Jeykumar Sankaran wrote:
On 2018-11-16 10:42, Sean Paul wrote:
> From: Sean Paul
>
> It's for legacy drivers, for atomic drivers crtc->state->encoder_mask
> should be used to map encoder to crtc.
>
> Changes in v2:
On 2018-11-16 10:42, Sean Paul wrote:
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:
- None
Signed-off-by: Sean Pau
On 2018-11-16 10: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.
Changes in v2:
- None
Signed-off-by: Sean Paul
Reviewed-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/d
On 2018-11-16 13:37, Sean Paul wrote:
On Fri, Nov 16, 2018 at 04:35:26PM -0500, Sean Paul wrote:
On Fri, Nov 16, 2018 at 11:22:21AM -0800, Jeykumar Sankaran wrote:
> Add encoder interface to release dpu encoder
> on mode_init failures in kms.
>
> Signed-off-by: Jeykumar Sankaran
> ---
> driver
On 2018-11-16 13:35, Sean Paul wrote:
On Fri, Nov 16, 2018 at 11:22:21AM -0800, Jeykumar Sankaran wrote:
Add encoder interface to release dpu encoder
on mode_init failures in kms.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 12 ++--
drivers/gpu/d
On 2018-11-16 12:02, Sean Paul wrote:
On Thu, Nov 08, 2018 at 02:00:51PM -0800, Jeykumar Sankaran wrote:
On 2018-10-30 09:00, Sean Paul wrote:
> From: Sean Paul
>
> This patch sprinkles a few async/legacy_cursor_update checks
> through commit to ensure that cursor updates aren't blocked on vsyn
On 11/12, Maarten Lankhorst wrote:
> We already have __drm_atomic_helper_connector_reset() and
> __drm_atomic_helper_plane_reset(), extend this to crtc as well.
>
> Most drivers already have a gpu reset hook, correct it.
> Nouveau already implemented its own __drm_atomic_helper_crtc_reset(),
> con
On 11/19/2018 11:55 AM, Jayant Shekhar wrote:
In case of msm drm bind failure, pm runtime put sync
is called from dsi driver which issues an asynchronous
put on mdss device. Subsequently when dpu_mdss_destroy
is triggered the change will make sure to put the mdss
device in suspend and clearing p
22 matches
Mail list logo
