On 2018-12-04 21:21, Rob Clark wrote:
On Tue, Dec 4, 2018 at 11:56 AM Robert Foss wrote:
If dma_fence_wait fails to wait for a supplied in-fence in
msm_ioctl_gem_submit, make sure we release that in-fence.
Also remove this dma_fence_put() from the 'out' label.
Signed-off-by: Robert Foss
Hi Andrzej,
On Wednesday, 5 December 2018 10:46:40 EET Andrzej Hajda wrote:
> On 05.12.2018 07:32, Laurent Pinchart wrote:
> > On Tuesday, 4 December 2018 21:13:20 EET Ville Syrjälä wrote:
> >> On Tue, Dec 04, 2018 at 08:46:53AM +0100, Andrzej Hajda wrote:
> >>> On 03.12.2018 22:38, Ville Syrjälä
On Tue, Nov 20, 2018 at 06:13:42PM +0200, Ville Syrjala wrote:
> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
> b/drivers/gpu/drm/i2c/tda998x_drv.c
> index a7c39f39793f..38c66fbc8276 100644
> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> @@ -849,7 +849,8 @@
On Wed, Dec 05, 2018 at 08:40:34AM +0100, Andrzej Hajda wrote:
> On 04.12.2018 20:02, Ville Syrjälä wrote:
> > On Tue, Dec 04, 2018 at 08:03:53AM +0100, Andrzej Hajda wrote:
> >> On 03.12.2018 22:48, Ville Syrjälä wrote:
> >>> On Thu, Nov 29, 2018 at 09:46:16AM +0100, Andrzej Hajda 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 pending work if not
scheduled.
Signed-off-by:
From: Sean Paul
drm core already tracks this, so we can just lean on that instead of
tracking ourselves.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/dsi/dsi.c | 1 -
drivers/gpu/drm/msm/edp/edp.c | 1 -
drivers/gpu/drm/msm/hdmi/hdmi.c | 1 -
drivers/gpu/drm/msm/msm_drv.h | 3 ---
4
From: Sean Paul
It's always 0, and not exposed via property, so remove it and all
affected code.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 13 +
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.h | 1 -
drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c | 2 --
From: Sean Paul
drm core already tracks this, so we can just lean on that instead of
tracking ourselves.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 16
drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 5 -
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c |
From: Sean Paul
drm core already tracks this, so we can just lean on that instead of
tracking ourselves.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 7 +++
drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 2 --
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 2 --
From: Sean Paul
Just call drm_plane_create_rotation_property() directly
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c | 18 ++
1 file changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
From: Sean Paul
drm core already tracks this, so we can just lean on that instead of
tracking ourselves.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 9 ++-
drivers/gpu/drm/msm/disp/mdp4/mdp4_irq.c | 10 +--
drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 4 +-
From: Sean Paul
mdp5 only exposes one custom property, and it's zpos.
Fortunately, we have a standard zpos property now, we can remove
the hand-rolled property code entirely from mdp5 and rely on core.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 2 +-
From: Sean Paul
It's always 0xFF, so remove it and any code that relies on it being
!= 0xFF.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 27 ++
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.h | 1 -
drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c | 4
From: Sean Paul
drm core already tracks this, so we can just lean on that instead of
tracking ourselves.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 10 ++
drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 3 ---
drivers/gpu/drm/msm/dsi/dsi.c| 2 --
Hi Jordan,
Thanks for the patch!
On 11/29/18 19:26, Jordan Crouse wrote:
> Try to get the interconnect path for the GPU and vote for the maximum
> bandwidth to support all frequencies. This is needed for performance.
> Later we will want to scale the bandwidth based on the frequency to
> also
_dpu_crtc_vblank_enable_no_lock releases crtc_lock as
its needed for power handle operations. This opens up a
window where in a thread running dpu_crtc_disable and a thread
running dpu_crtc_vblank can race in using dpu_crtc->enabled.
dpu_crtc_disable will change the state, where as
Hi Dave,
I'm guest-robclarking for msm for this PR. I've been tracking a bunch of display
stuff for dpu and it am able to take a bit off Rob's plate by collecting the
fixes that have trickled in over the past while.
We've got a bunch of dpu-specific fixes since rc1, but I've deferred most of
them
17 matches
Mail list logo