Hi Abhinav,
Thank you for the patch.
On Fri, Apr 22, 2022 at 04:06:36PM -0700, Abhinav Kumar wrote:
> Clients of drm_writeback_connector_init() initialize the
> possible_crtcs and then invoke the call to this API.
>
> To simplify things, allow passing possible_crtcs as a parameter
> to drm_write
Hi Abhinav,
Thank you for the patch.
On Fri, Apr 22, 2022 at 04:06:37PM -0700, Abhinav Kumar wrote:
> For vendors drivers which pass an already allocated and
> initialized encoder especially for cases where the encoder
> hardware is shared OR the writeback encoder shares the resources
> with the
Hi Abhinav,
Thank you for the patch.
On Fri, Apr 22, 2022 at 04:06:38PM -0700, Abhinav Kumar wrote:
> For some vendor driver implementations, display hardware can
> be shared between the encoder used for writeback and the physical
> display.
>
> In addition resources such as clocks and interrupt
Hi Laurent
On 4/24/2022 7:50 AM, Laurent Pinchart wrote:
Hi Abhinav,
Thank you for the patch.
On Fri, Apr 22, 2022 at 04:06:38PM -0700, Abhinav Kumar wrote:
For some vendor driver implementations, display hardware can
be shared between the encoder used for writeback and the physical
display.
On 4/24/2022 11:12 AM, Abhinav Kumar wrote:
Hi Laurent
On 4/24/2022 7:50 AM, Laurent Pinchart wrote:
Hi Abhinav,
Thank you for the patch.
On Fri, Apr 22, 2022 at 04:06:38PM -0700, Abhinav Kumar wrote:
For some vendor driver implementations, display hardware can
be shared between the encod
Hi Abhinav,
On Sun, Apr 24, 2022 at 11:23:20AM -0700, Abhinav Kumar wrote:
> On 4/24/2022 11:12 AM, Abhinav Kumar wrote:
> > On 4/24/2022 7:50 AM, Laurent Pinchart wrote:
> >> On Fri, Apr 22, 2022 at 04:06:38PM -0700, Abhinav Kumar wrote:
> >>> For some vendor driver implementations, display hardw
Hi Laurent
On 4/24/2022 12:59 PM, Laurent Pinchart wrote:
Hi Abhinav,
On Sun, Apr 24, 2022 at 11:23:20AM -0700, Abhinav Kumar wrote:
On 4/24/2022 11:12 AM, Abhinav Kumar wrote:
On 4/24/2022 7:50 AM, Laurent Pinchart wrote:
On Fri, Apr 22, 2022 at 04:06:38PM -0700, Abhinav Kumar wrote:
For s
Hi Laurent
On 4/24/2022 2:12 PM, Abhinav Kumar wrote:
Hi Laurent
On 4/24/2022 12:59 PM, Laurent Pinchart wrote:
Hi Abhinav,
On Sun, Apr 24, 2022 at 11:23:20AM -0700, Abhinav Kumar wrote:
On 4/24/2022 11:12 AM, Abhinav Kumar wrote:
On 4/24/2022 7:50 AM, Laurent Pinchart wrote:
On Fri, Apr 2
This series adds support for writeback block on DPU. Writeback
block is extremely useful to validate boards having no physical displays
in addition to many other use-cases where we want to get the output
of the display pipeline to examine whether issue is with the display
pipeline or with the panel
Clients of drm_writeback_connector_init() initialize the
possible_crtcs and then invoke the call to this API.
To simplify things, allow passing possible_crtcs as a parameter
to drm_writeback_connector_init() and make changes to the
other drm drivers to make them compatible with this change.
chang
For vendors drivers which pass an already allocated and
initialized encoder especially for cases where the encoder
hardware is shared OR the writeback encoder shares the resources
with the rest of the display pipeline introduce a new API,
drm_writeback_connector_init_with_encoder() which expects
an
Add writeback blocks to the sm8250 DPU hardware catalog. Other
chipsets support writeback too but add it to sm8250 to prototype
the feature so that it can be easily extended to other chipsets.
changes in v4:
- fix the copyright year order
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry
Add a reset_intf_cfg operation for dpu_hw_ctl to reset the
entire CTL path by disabling each component namely layer mixer,
3d-merge and interface blocks.
changes in v3:
- none
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 32
Rename dpu_hw_pipe_cdp_cfg to dpu_hw_cdp_cfg and move it
to dpu_hw_utils file so that other modules in addition to
SSPP such as writeback can use it as all the fields can
be used by writeback as well.
Suggested-by: Dmitry Baryshkov
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
---
Add changes to support writeback module in the dpu_hw_ctl
interface.
changes in v4:
- fix the copyright year order
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 52 --
drivers/gpu/drm/msm/disp/dpu
Make changes to dpu_encoder to support virtual encoder needed
to support writeback for dpu.
changes in v4:
- squash dpu_encoder pieces from [1]
[1] https://patchwork.freedesktop.org/patch/483099/?series=102964&rev=2
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_enc
Add the dpu_hw_wb abstraction to program registers related to the
writeback block. These will be invoked once all the configuration
is set and ready to be programmed to the registers.
changes in v3:
- start using the common struct dpu_hw_cdp_cfg
- leave a comment about DPU non-DPU_
Add writeback blocks to DPU resource manager so that
the encoders can directly request them through RM.
changes in v4:
- absorb dpu_rm.h header change from [1]
- since its a trivial change absorbed from an approved
patch, preserving the previous ack on this
[1] https://p
add dpu encoder APIs to prepare and cleanup writeback job
for the writeback encoder. These shall be invoked from the
prepare_wb_job/cleanup_wb_job hooks of the drm_writeback
framework.
changes in v3:
- none
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/
_dpu_plane_get_qos_lut() is not specific to just dpu_plane.
It can take any fill level and return the LUT matching it.
This can be used even for other modules like dpu_writeback.
Move _dpu_plane_get_qos_lut() to the common dpu_hw_util file
and rename it to _dpu_hw_get_qos_lut().
Signed-off-by: Ab
Introduce the dpu_encoder_phys_* for the writeback interface
to handle writeback specific hardware programming.
changes in v4:
- squash the encoder_phys_wb bits from [1]
- since its a trivial change of a previously acked change
preserving the ack
[1] https://patchwork.fr
Add an API to reset the encoder related hw blocks to ensure
a proper teardown of the pipeline. At the moment this is being
used only for the writeback encoder but eventually we can start
using this for all interfaces.
changes in v4:
- none
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry
kms_writeback test cases also verify with a null fb for the
writeback connector job. In addition there are also other
commit paths which can result in kickoffs without a valid
framebuffer like while closing the fb which results in the
callback to drm_atomic_helper_dirtyfb() which internally
trigger
Initialize dpu encoder and connector for writeback if the
target supports it in the catalog.
changes in v2:
- start initialing the encoder for writeback since we
have migrated to using drm_writeback_connector_init_with_encoder()
- instead of checking for WB_2 inside _dpu_km
Add writeback block information while capturing the display
snapshot.
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/di
Introduce the dpu_writeback module which serves as the
interface between dpu operations and the drm_writeback.
This module manages the connector related operations for
dpu writeback.
changes in v2:
- start using drm_writeback_connector_init_with_encoder()
- drop unnecessary argume
Change the DRM traces to include both the intf_mode
and wb_idx similar to the DRM prints in the previous change.
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 13 -
drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h | 26 ++
Add wb_idx to existing DRM prints in dpu_encoder and also
print the intf_mode so that its clear that for any INTF_CMD/VID
there will be a valid intf_idx and any INTF_WB_* there will be a
valid wb_idx.
Update the debugfs to add the same information. Here is a sample
output with this change:
root:/
Hi Stephen,
>Quoting Sankeerth Billakanti (2022-04-22 02:11:04)
>> The panel-edp enables the eDP panel power during probe, get_modes and
>> pre-enable. The eDP connect and disconnect interrupts for the eDP/DP
>> controller are directly dependent on panel power. As eDP display can
>> be assumed as
BUG: Unable to handle kernel paging request at virtual address 006b6b6b6b6b6be3
Call trace:
dpu_vbif_init_memtypes+0x40/0xb8
dpu_runtime_resume+0xcc/0x1c0
pm_generic_runtime_resume+0x30/0x44
__genpd_runtime_resume+0x68/0x7c
genpd_runtime_resume+0x134/0x258
__rpm_callback+0x98/0x138
r
30 matches
Mail list logo
