On 2019-01-28 12:42, Sean Paul wrote:
From: Sean Paul
Use the drm_mode_vrefresh helper where we need refresh rate in case
vrefresh is empty.
Signed-off-by: Sean Paul
Reviewed-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 6 +++---
drivers/gpu/drm/msm
;
/* All phys encs are ready to go, trigger the kickoff */
_dpu_encoder_kickoff_phys(dpu_enc, async);
Reviewed-by: Jeykumar Sankaran
--
Jeykumar S
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
ts being
wrong
didn't matter. I've also dropped the timeout from the previous 60
frames
to 5. That seems like more than enough time to give up on a frame, and
my guess is that no one intended for the timeout to _actually_ be 60
frames.
Signed-off-by: Sean Paul
Reviewed-by: Jeyku
y time the cursor moves without a synchronous frame following it up
before the timeout expires. Since we don't wait for frame_done, and
don't handle it, we shouldn't modify the watchdog.
Signed-off-by: Sean Paul
---
Reviewed-by: Jeykumar Sankaran
drivers/gpu/drm/msm/dis
Not holding any video encoder specific data. Get rid of it.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 11 ---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 18 --
2 files changed, 4 insertions(+), 25 deletions
Both video and command physical encoders will have
a hw interface assigned to it. So there is really no
need to track the hw block in specific encoder subclass.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 4 +-
.../gpu/drm/msm/disp/dpu1
Removing unwanted access of crtc_state for finding this information.
Use split role information to know whether we have slave ctl.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
diff
release resources allocated in mode_set if any of
the hw check fails. Most of these checks are not
necessary and they will be removed in the follow up
patches with state based resource allocations.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 7 +--
1
Both video and command physical encoders will have
a hw interface assigned to it. So there is really no
need to track the hw block in specific encoder subclass.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 4 +-
.../gpu/drm/msm/disp/dpu1
Iterate and assign HW intf block to physical encoders
in encoder modeset. Moving all the HW block assignments
to encoder modeset to allow easy switching to state
based resource management.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c| 22
After resource allocation, iterate and populate mixer/ctl
hw blocks in encoder modeset thereby centralizing all
the resource mapping to the CRTC. This change is made
for easy switching to state based allocation using
private objects later in this series.
Signed-off-by: Jeykumar Sankaran
Not holding any video encoder specific data. Get rid of it.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 11 ---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 18 --
2 files changed, 4 insertions(+), 25 deletions
Fixing some of the low hanging fruits by moving the hw resource
parsing and assignment to encoder modeset. This series
prepares DPU resource management to switch to state based
resource tracking which is implemented in the next incoming
changes.
Thanks.
Jeykumar Sankaran (7):
drm/msm/dpu
encoder->crtc is not really meaningful for atomic path. Use
crtc->encoder_mask to identify the crtc attached with
an encoder.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drive
On 2019-02-13 17:19, Jeykumar Sankaran wrote:
Fixing some of the low hanging fruits by moving the hw resource
parsing and assignment to encoder modeset. This series
prepares DPU resource management to switch to state based
resource tracking which is implemented in the next incoming
changes
maintained in dpu_crtc as
the resources are tracked per display
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 3 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 64 +++-
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 15
3
Now that we have dpu private state tracking the reserved
HW resources, we have access to them after atomic swap.
So avoid reserving the resources in mode_set.
changes in v2:
- removal applied on private object based reservation
Signed-off-by: Jeykumar Sankaran
Reviewed-by: Sean Paul
up RM iterator
API's.
Thanks and Regards,
Jeykumar S.
Jeykumar Sankaran (4):
drm/msm/dpu: add atomic private object to dpu crtc
drm/msm/dpu: track HW resources using private object state
drm/msm/dpu: remove reserve in encoder mode_set
drm/msm/dpu: remove mode_set_complete
drivers/gp
crtc
- No explicit count for hw_ctl as they match
with hw_intf count
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h| 7 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 157
drivers/gpu/drm/msm/disp/dpu1/dpu_
This flag was introduced as a fix to notify modeset complete
when hw reservations were happening in both atomic_check
and atomic_commit paths. Now that we are reserving only in
atomic_check, we can get rid of this flag.
changes in v2:
- none
Signed-off-by: Jeykumar Sankaran
Reviewed-by
On 2019-03-04 13:32, Sean Paul wrote:
On Wed, Feb 13, 2019 at 05:52:19PM -0800, Jeykumar Sankaran wrote:
Subclass drm private object state for DPU for handling driver
specific data. Adds atomic private object to dpu crtc to
track hw resources per display. Provide helper function to
retrieve DPU
On 2019-03-04 10:09, Sean Paul wrote:
On Wed, Feb 13, 2019 at 05:19:13PM -0800, Jeykumar Sankaran wrote:
encoder->crtc is not really meaningful for atomic path. Use
crtc->encoder_mask to identify the crtc attached with
an encoder.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/ms
On 2019-06-23 23:27, Shubhashree Dhar wrote:
dpu encoder spinlock should be initialized during dpu encoder
init instead of dpu encoder setup which is part of commit.
There are chances that vblank control uses the uninitialized
spinlock if not initialized during encoder init.
Not much can be done
On 2019-06-24 22:44, d...@codeaurora.org wrote:
On 2019-06-25 03:56, Jeykumar Sankaran wrote:
On 2019-06-23 23:27, Shubhashree Dhar wrote:
dpu encoder spinlock should be initialized during dpu encoder
init instead of dpu encoder setup which is part of commit.
There are chances that vblank
On 2019-07-01 03:29, d...@codeaurora.org wrote:
On 2019-06-26 03:10, Jeykumar Sankaran wrote:
On 2019-06-24 22:44, d...@codeaurora.org wrote:
On 2019-06-25 03:56, Jeykumar Sankaran wrote:
On 2019-06-23 23:27, Shubhashree Dhar wrote:
dpu encoder spinlock should be initialized during dpu
On 2019-07-02 11:21, Jeykumar Sankaran wrote:
On 2019-07-01 03:29, d...@codeaurora.org wrote:
On 2019-06-26 03:10, Jeykumar Sankaran wrote:
On 2019-06-24 22:44, d...@codeaurora.org wrote:
On 2019-06-25 03:56, Jeykumar Sankaran wrote:
On 2019-06-23 23:27, Shubhashree Dhar wrote:
dpu encoder
er vendors for their
growing need for drm_mode specific capabilities.
Please provide your inputs on the options or any upstream friendly
recommendation to handle such custom use cases.
Thanks and Regards,
Jeykumar S.
Jeykumar Sankaran (1):
drm: add mode flags in uapi for sea
Add drm mode flag values to expose mode capabilities to
perform dynamic seamless mode switch. This change also
exposes the backing panel type associated with a mode
for panels which can dynamically switch between video
and command display modes.
Signed-off-by: Jeykumar Sankaran
---
include/uapi
On 2019-07-16 02:07, Daniel Vetter wrote:
On Thu, Jul 11, 2019 at 11:46:44AM -0700, Jeykumar Sankaran wrote:
Hello All,
drm_mode_modeinfo::flags is a 32 bit field currently used to
describe the properties of a connector mode. I see the least order
22 bits
are already in
On 2019-07-19 07:29, Sean Paul wrote:
On Fri, Jul 19, 2019 at 05:15:28PM +0300, Ville Syrjälä wrote:
On Fri, Jul 19, 2019 at 09:55:58AM -0400, Sean Paul wrote:
> On Fri, Jul 19, 2019 at 11:05:53AM +0200, Daniel Vetter wrote:
> > On Thu, Jul 18, 2019 at 11:18:42AM -0700, Jeykumar Sanka
On 2019-07-24 07:48, Sean Paul wrote:
On Mon, Jul 22, 2019 at 04:50:43PM -0700, Jeykumar Sankaran wrote:
On 2019-07-19 07:29, Sean Paul wrote:
> On Fri, Jul 19, 2019 at 05:15:28PM +0300, Ville Syrjälä wrote:
> > On Fri, Jul 19, 2019 at 09:55:58AM -0400, Sean Paul wrote:
> > &
On 2019-10-09 03:47, Daniel Vetter wrote:
On Tue, Sep 24, 2019 at 10:28:48AM -0700, Jeykumar Sankaran wrote:
Reviving this thread from the context of the below conversion:
https://lore.kernel.org/linux-arm-msm/db26145b-3f64-a334-f698-76f972332881
@baylibre.com/T/#u
On 2018-10-05 01:19
Reviving this thread from the context of the below conversion:
https://lore.kernel.org/linux-arm-msm/db26145b-3f64-a334-f698-76f972332...@baylibre.com/T/#u
On 2018-10-05 01:19, Neil Armstrong wrote:
On 05/10/2018 09:58, Daniel Vetter wrote:
On Fri, Oct 5, 2018 at 9:39 AM Neil Armstrong
wrote:
Below two discussion threads will provide the context behind this patch.
https://www.spinics.net/lists/dri-devel/msg229070.html
https://lore.kernel.org/linux-arm-msm/db26145b-3f64-a334-f698-76f972332...@baylibre.com/T/
Seperating out the core framework patch from vendor implementation.
Jeykumar
Below two discussion threads will provide the context behind this patch.
https://www.spinics.net/lists/dri-devel/msg229070.html
https://lore.kernel.org/linux-arm-msm/db26145b-3f64-a334-f698-76f972332...@baylibre.com/T/
Seperating out the core framework patch from vendor implementation.
Jeykumar
ering and validating the modes against the appropriate max
fields in their mode_valid() implementations.
Signed-off-by: Neil Armstrong
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/drm_framebuffer.c | 15 +++
include/drm/drm_mode_config.h | 3 +++
2 files changed, 14 inser
Below two discussion threads will provide the context behind this patch.
https://www.spinics.net/lists/dri-devel/msg229070.html
https://lore.kernel.org/linux-arm-msm/db26145b-3f64-a334-f698-76f972332...@baylibre.com/T/
Seperating out the core framework patch from vendor implementation.
Jeykumar
ering and validating the modes against the appropriate max
fields in their mode_valid() implementations.
Signed-off-by: Neil Armstrong
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/drm_framebuffer.c | 15 +++
include/drm/drm_mode_config.h | 3 +++
2 files changed, 14 inser
Below two discussion threads will provide the context behind this patch.
https://www.spinics.net/lists/dri-devel/msg229070.html
https://lore.kernel.org/linux-arm-msm/db26145b-3f64-a334-f698-76f972332...@baylibre.com/T/
Seperating out the core framework patch from vendor implementation.
Jeykumar
On 2019-09-30 03:39, Ville Syrjälä wrote:
On Fri, Sep 27, 2019 at 06:28:51PM -0700, Jeykumar Sankaran wrote:
The mode_config max width/height values determine the maximum
resolution the pixel reader can handle.
Not according to the docs I "fixed" a while ago.
But the same values a
On 4/17/2023 8:30 AM, Konrad Dybcio wrote:
Apart from the already handled data bus (MAS_MDP_Pn<->DDR), there's
another path that needs to be handled to ensure MDSS functions properly,
namely the "reg bus", a.k.a the CPU-MDSS interconnect.
Gating that path may have a variety of effects.. from
On 4/19/2023 12:48 PM, Konrad Dybcio wrote:
On 19.04.2023 21:06, Jeykumar Sankaran wrote:
On 4/17/2023 8:30 AM, Konrad Dybcio wrote:
Apart from the already handled data bus (MAS_MDP_Pn<->DDR), there's
another path that needs to be handled to ensure MDSS functions properly,
Resending the question as the previous one was sent only to the
freedreno list. Apologies for spamming!
On 4/17/2023 8:30 AM, Konrad Dybcio wrote:
Apart from the already handled data bus (MAS_MDP_Pn<->DDR), there's
another path that needs to be handled to ensure MDSS functions properly,
namely
On 4/17/2023 8:30 AM, Konrad Dybcio wrote:
Apart from the already handled data bus (MAS_MDP_Pn<->DDR), there's
another path that needs to be handled to ensure MDSS functions properly,
namely the "reg bus", a.k.a the CPU-MDSS interconnect.
Gating that path may have a variety of effects.. from
On 4/19/2023 7:41 AM, Arnaud Vrac wrote:
Do not override the hsync/vsync polarity passed by the encoder when
setting up intf timings. The same logic was used in both the encoder and
intf code to set the DP and DSI polarities, so those interfaces are not
impacted. However for HDMI, the polariti
On 4/19/2023 3:23 PM, Dmitry Baryshkov wrote:
On 19/04/2023 17:41, Arnaud Vrac wrote:
This avoids using two LMs instead of one when the display width is lower
than the maximum supported value. For example on MSM8996/MSM8998, the
actual maxwidth is 2560, so we would use two LMs for 1280x720 or
On 4/21/2023 5:08 PM, Dmitry Baryshkov wrote:
The src_blk declares a lame copy of main SSPP register space. It's
offset is always 0. It's length has been fixed to 0x150, while SSPP's
length is now correct. Drop the src_blk and access SSPP registers
without additional subblock lookup.
Signed-o
ctx->hw, idx);
+ return dpu_hw_get_scaler3_ver(&ctx->hw,
+ ctx->cap->sblk->scaler_blk.base);
}
/*
Reviewed-by: Jeykumar Sankaran
, data, csc10);
}
static void dpu_hw_sspp_setup_solidfill(struct dpu_sw_pipe *pipe, u32 color)
Reviewed-by: Jeykumar Sankaran
On 4/30/2023 1:57 PM, Dmitry Baryshkov wrote:
The function dpu_plane_sspp_update_pipe() contains code to skip enabling
the QoS and OT limitis for CURSOR pipes. However all DPU since sdm845
repurpose DMA SSPP for the cursor planes because they lack the real
CURSOR SSPP. Fix the condition to act
On 4/30/2023 1:57 PM, Dmitry Baryshkov wrote:
Get rid of intermediatory configuration structure and defines. Pass the
format and the enablement bit directly to the new helper. The
WB_CDP_CNTL register ignores BIT(2), so we can write it for both SSPP
and WB CDP settings.
Signed-off-by: Dmitry
_dpu_plane_set_ot_limit(plane, pipe, pipe_cfg, frame_rate);
- }
if (pstate->needs_qos_remap)
_dpu_plane_set_qos_remap(plane, pipe);
Reviewed-by: Jeykumar Sankaran
pipe_qos_cfg.danger_safe_en,
- pipe_qos_cfg.vblank_en,
- pipe_qos_cfg.creq_vblank,
- pipe_qos_cfg.danger_vblank,
pdpu->is_rt_pipe);
pipe->sspp->ops.setup_qos_ctrl(pipe->sspp,
Reviewed-by: Jeykumar Sankaran
pstate->pipe, enable);
if (pstate->r_pipe.sspp)
- _dpu_plane_set_qos_ctrl(plane, &pstate->r_pipe, enable,
DPU_PLANE_QOS_PANIC_CTRL);
+ _dpu_plane_set_qos_ctrl(plane, &pstate->r_pipe, enable);
pm_runtime_put_sync(&dpu_kms->pdev->dev);
}
#endif
Reviewed-by: Jeykumar Sankaran
t drm_plane *plane,
struct dpu_sw_pipe *pipe,
@@ -1086,10 +1065,6 @@ static void dpu_plane_sspp_update_pipe(struct drm_plane
*plane,
}
_dpu_plane_set_qos_lut(plane, pipe, fmt, pipe_cfg);
- _dpu_plane_set_danger_lut(plane, pipe, fmt);
- _dpu_plane_set_qos_ctrl(plane, pipe,
- pipe->sspp->idx != SSPP_CURSOR0 &&
- pipe->sspp->idx != SSPP_CURSOR1);
if (pipe->sspp->idx != SSPP_CURSOR0 &&
pipe->sspp->idx != SSPP_CURSOR1)
Reviewed-by: Jeykumar Sankaran
On 5/2/2023 8:05 AM, Dmitry Baryshkov wrote:
Reorder SSPP register definitions to sort them in the ascending order.
Move register bitfields after the register definitions.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 66 +++--
1 file ch
NK_AMORTIZE) {
- /* this feature overrules previous VBLANK_CTRL */
pipe_qos_cfg.vblank_en = false;
pipe_qos_cfg.creq_vblank = 0; /* clear vblank bits */
}
Reviewed-by: Jeykumar Sankaran
quot;pnum:%d ds:%d is_rt:%d\n",
pdpu->pipe - SSPP_VIG0,
- pipe_qos_cfg.danger_safe_en,
+ enable,
pdpu->is_rt_pipe);
pipe->sspp->ops.setup_qos_ctrl(pipe->sspp,
- &pipe_qos_cfg);
+
lane_set_ot_limit(plane, pipe, pipe_cfg, frame_rate);
}
Reviewed-by: Jeykumar Sankaran
->sspp->ops.setup_cdp(pipe, &cdp_cfg);
+ pipe->sspp->ops.setup_cdp(pipe, fmt,
+
perf->cdp_cfg[DPU_PERF_CDP_USAGE_RT].rd_enable);
}
}
Reviewed-by: Jeykumar Sankaran
On 5/18/2023 3:22 PM, Dmitry Baryshkov wrote:
Reorder SSPP register definitions to sort them in the ascending order.
Move register bitfields after the register definitions.
Signed-off-by: Dmitry Baryshkov
---
Reviewed-by: Jeykumar Sankaran
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
On 5/22/2023 2:45 PM, Dmitry Baryshkov wrote:
There is no point in having a single enum (and a single array) for both
DPU < 7.0 and DPU >= 7.0 interrupt registers. Instead define a single
enum and two IRQ address arrays.
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_7_0
define MSM_DSI_6G_VER_MINOR_V1_0 0x1000
+#define MSM_DSI_6G_VER_MINOR_V1_0_20x1002
#define MSM_DSI_6G_VER_MINOR_V1_1 0x1001
#define MSM_DSI_6G_VER_MINOR_V1_1_1 0x10010001
#define MSM_DSI_6G_VER_MINOR_V1_2 0x1002
Reviewed-by: Jeykumar Sankaran
{ .revision = 3, .config = { .hw = &apq8084_config } },
{ .revision = 6, .config = { .hw = &msm8x16_config } },
Reviewed-by: Jeykumar Sankaran
On 6/1/2023 10:00 AM, Luca Weiss wrote:
MSM8226 uses a modified PLL lock sequence compared to MSM8974, which is
based on the function dsi_pll_enable_seq_m in the msm-3.10 kernel.
Worth noting that the msm-3.10 downstream kernel also will try other
sequences in case this one doesn't work, but
drm connector notifies userspace on hotplug event prematurely before
late_register and mode_object register completes. This leads to a race
between userspace and kernel on updating the IDR list. So, move the
notification to end of connector register.
Signed-off-by: Jeykumar Sankaran
Signed-off
While creating display and event threads per crtc, validate
them before setting their priorities.
Change-Id: I1dda805286df981c0f0e2b26507d089d3a21ff6c
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/msm_drv.c | 49 ++-
1 file changed, 16
While creating display and event threads per crtc, validate
them before setting their priorities.
changes in v2:
- use dev_warn (Abhinav Kumar)
Change-Id: I1dda805286df981c0f0e2b26507d089d3a21ff6c
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/msm_drv.c | 49
While creating display and event threads per crtc, validate
them before setting their priorities.
changes in v2:
- use dev_warn (Abhinav Kumar)
changes in v3:
- fix compilation error
Change-Id: I1dda805286df981c0f0e2b26507d089d3a21ff6c
Signed-off-by: Jeykumar Sankaran
Not actively used. Clean up the crtc mixer struct.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 2 --
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 2 --
2 files changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm
Not used. Remove from RM.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 3 +--
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 7 ++-
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 6 +-
3 files changed, 4 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu
Layer mixer/pingpong block counts and hw ctl block counts
will not be same for all the topologies (e.g. layer
mixer muxing to single interface)
Use the encoder's split_role info to retrieve the
respective control path for programming.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/dr
Definition was removed already. Clean up header declaration.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
index f41fd19
struct dpu_hw_blk has hw block type info. Remove duplicate
type tracking in struct dpu_rm_hw_blk.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 17 -
1 file changed, 4 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1
This flag was introduced as a fix to notify modeset complete
when hw reservations were happening in both atomic_check
and atomic_commit paths. Now that we are reserving only in
atomic_check, we can get rid of this flag.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1
Submitting series of patches to clean up DPU resource manager (RM)
of complicated hw iterations, redundant data maintenence and eventually
modifying the DPU to reserve display HW blocks only in atomic check
and caching the assigned HW blocks in atomic CRTC state.
Thanks,
Jeykumar S.
Jeykumar
Use the hw block pointers stored in crtc state to
release them back to RM resource pool. This change
is made to uncouple RM reservation from encoder_id.
Separate change is submitted to clean up RM of
encoder id tagging.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1
p
the support from RM. Replace rsvp with the corresponding
encoder id to tag the HW blocks reserved.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 284 +
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 4 -
2 files changed, 43 insertions(+)
pipeline. It helps the driver:
- to get rid of unwanted store and retrieval RM API's
- to preserve HW resources assigned in atomic_check
through atomic swap/duplicate.
Separate patch is submitted to remove resource
reservation in atomic_commit path.
Signed-off-by: Jeykumar Sankaran
---
dr
Now that we have crtc state tracking the reserved
HW resources, we have access to them after atomic swap.
So avoid reserving the resources in mode_set.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 17 ++---
1 file changed, 2 insertions(+), 15
HW blocks reserved for a display are stored in crtc state.
No one outside RM is interested in using these API's for
HW block list iterations.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 37 ++-
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
Instead of letting encoder make a centralized reservation for
all of its display DRM components, this path splits the
responsibility between CRTC and Encoder, each requesting
RM for the HW mapping of its own domain.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
We cleaned up RM reserve api's enough to get rid of
most of its unwanted checks and release handlers. To
improve further the readability of the function, merging
down the individual HW type allocators into one function.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu
Usage of hw block iterators are only RM internal. Instead
of using generic void pointers for HW blocks, use dpu
specific structure. It helps us to get rid of duplicate
hw block id's maintained in RM wrapper.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
hw_mdp block is common for displays. No need
to reserve per display.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 7 ++-
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 20
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 10 --
3 files
.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 13 +++--
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 4 +---
3 files changed, 5 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/msm
Replacing with simpler linked list helper iterators.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 120 +
1 file changed, 46 insertions(+), 74 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
b/drivers/gpu/drm/msm
RM was using encoder id's to tag HW block's to reserve
and retrieve later for display pipeline. Now
that all the reserved HW blocks for a display are
maintained in its crtc state, no retrieval is needed.
This patch cleans up RM of encoder id tagging.
Signed-off-by: Jeykumar Sankaran
--
Since HW reservations are happening through atomic_check
and all the display commits are catered by a single commit thread,
it is not necessary to protect the interfaces by a separate
mutex.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 24
Unused variable in the driver.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 12
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 2 --
2 files changed, 14 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
b/drivers/gpu/drm/msm/disp/dpu1
Get rid of hw block pointer in RM iter as we can
access the same through dpu_hw_blk.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
b/drivers/gpu
we don't have enough reasons why the HW block looping's
cannot happen in the same function. So merge them.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 63 ++
1 file changed, 26 insertions(+), 37 deletions(-)
diff --git
assigned HW blocks for providing the info,
we can conveniently get rid of this structure.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 29 --
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 82 -
drivers/gpu/drm/msm/disp/dpu1
Validate layer mixer pairs for compatibility before retrieving
the connected pingpong blocks.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 61 ++
1 file changed, 17 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/msm
Move and maintain RM initialization flag checks
from KMS to RM.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 6 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 12
drivers/gpu/drm/msm/disp/dpu1
On 2018-10-09 07:24, Sean Paul wrote:
On Mon, Oct 08, 2018 at 04:55:45PM -0700, Jeykumar Sankaran wrote:
While creating display and event threads per crtc, validate
them before setting their priorities.
changes in v2:
- use dev_warn (Abhinav Kumar)
changes in v3:
- fix
On 2018-10-09 09:50, Jordan Crouse wrote:
On Mon, Oct 08, 2018 at 09:27:35PM -0700, Jeykumar Sankaran wrote:
we don't have enough reasons why the HW block looping's
cannot happen in the same function. So merge them.
looping's -> looping. So there are reasons one might brea
On 2018-10-09 11:07, Sean Paul wrote:
On Mon, Oct 08, 2018 at 09:27:18PM -0700, Jeykumar Sankaran wrote:
Layer mixer/pingpong block counts and hw ctl block counts
will not be same for all the topologies (e.g. layer
mixer muxing to single interface)
Use the encoder's split_role info to ret
On 2018-10-09 12:57, Sean Paul wrote:
On Mon, Oct 08, 2018 at 09:27:41PM -0700, Jeykumar Sankaran wrote:
Since HW reservations are happening through atomic_check
and all the display commits are catered by a single commit thread,
it is not necessary to protect the interfaces by a separate
mutex
On 2018-10-09 13:41, Sean Paul wrote:
On Mon, Oct 08, 2018 at 09:27:39PM -0700, Jeykumar Sankaran wrote:
Instead of letting encoder make a centralized reservation for
all of its display DRM components, this path splits the
responsibility between CRTC and Encoder, each requesting
RM for the HW
1 - 100 of 383 matches
Mail list logo
