On Fri 22 Apr 16:07 PDT 2022, Dmitry Baryshkov wrote:
> On 23/04/2022 01:32, Bjorn Andersson wrote:
[..]
> > diff --git a/drivers/gpu/drm/msm/dp/dp_drm.c
> > b/drivers/gpu/drm/msm/dp/dp_drm.c
> > index 80f59cf99089..76904b1601b1 100644
> > --- a/drivers/gpu/drm/msm/dp/dp_drm.c
> > +++
Quoting Maxime Ripard (2022-04-22 02:48:17)
> Hi,
>
> On Thu, Apr 21, 2022 at 07:49:12PM -0700, Stephen Boyd wrote:
> > +Maxime
> >
> > Quoting Dmitry Baryshkov (2022-04-19 16:54:47)
> > > Since the commit 948fb0969eae ("clk: Always clamp the rounded rate"),
> > > the
Quoting Sankeerth Billakanti (2022-04-22 02:11:06)
> The eDP controller does not have a reliable way keep panel
> powered on to read the sink capabilities. So, the controller
> driver cannot validate if a mode can be supported by the
> source. We will rely on the panel driver to populate only
>
Quoting Sankeerth Billakanti (2022-04-22 02:11:05)
> The source device should ensure the sink is ready before proceeding to
> read the sink capability or perform any aux transactions. The sink
> will indicate its readiness by asserting the HPD line. The controller
> driver needs to wait for the
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 always connected,
Quoting Sankeerth Billakanti (2022-04-22 02:11:03)
> diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
> b/drivers/gpu/drm/msm/dp/dp_display.c
> index d7a19d6..055681a 100644
> --- a/drivers/gpu/drm/msm/dp/dp_display.c
> +++ b/drivers/gpu/drm/msm/dp/dp_display.c
Some nitpicks
Reviewed-by:
On 4/22/2022 5:07 PM, Dmitry Baryshkov wrote:
On 23/04/2022 02:45, Kuogee Hsieh wrote:
Current DP driver implementation has adding safe mode done at
dp_hpd_plug_handle() which is expected to be executed under event
thread context.
However there is possible circular locking happen (see blow
On 23/04/2022 02:45, Kuogee Hsieh wrote:
Current DP driver implementation has adding safe mode done at
dp_hpd_plug_handle() which is expected to be executed under event
thread context.
However there is possible circular locking happen (see blow stack trace)
after edp driver call
Quoting Kuogee Hsieh (2022-04-22 16:45:23)
> Current DP driver implementation has adding safe mode done at
> dp_hpd_plug_handle() which is expected to be executed under event
> thread context.
>
> However there is possible circular locking happen (see blow stack trace)
> after edp driver call
Current DP driver implementation has adding safe mode done at
dp_hpd_plug_handle() which is expected to be executed under event
thread context.
However there is possible circular locking happen (see blow stack trace)
after edp driver call dp_hpd_plug_handle() from dp_bridge_enable() which
is
Hi Liviu
Thank you for the feedback.
I have fixed the order of copyright years in all the changes in the next
version.
Thanks
Abhinav
On 4/21/2022 5:16 AM, Liviu Dudau wrote:
On Tue, Apr 19, 2022 at 06:45:56PM -0700, Abhinav Kumar wrote:
Add writeback blocks to the sm8250 DPU hardware
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 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
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:
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
_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:
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
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
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
---
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]
On 23/04/2022 01:32, Bjorn Andersson wrote:
The Qualcomm DisplayPort driver contains traces of the necessary
plumbing to hook up USB HPD, in the form of the dp_hpd module and the
dp_usbpd_cb struct. Use this as basis for implementing the
oob_hotplug_event() callback, by amending the dp_hpd
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
---
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=2
Signed-off-by: Abhinav Kumar
---
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:
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 --
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]
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
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 |
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
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 interrupts can
also be shared between writeback and the real encoder.
To accommodate such vendor drivers and hardware,
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
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
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.
On 22/04/2022 13:42, Dmitry Baryshkov wrote:
On Fri, 22 Apr 2022 at 11:52, wrote:
From: Lv Ruyi
The irq_of_parse_and_map() function returns 0 on failure, and does not
return an negative value.
Reported-by: Zeal Robot
Signed-off-by: Lv Ruyi
Reviewed-by: Dmitry Baryshkov
---
On 22/04/2022 21:39, Stephen Boyd wrote:
Quoting cgel@gmail.com (2022-04-22 01:49:51)
From: Lv Ruyi
The irq_of_parse_and_map() function returns 0 on failure, and does not
return an negative value.
Fixes: 8ede2ecc3e5e ("drm/msm/dp: Add DP compliance tests on Snapdragon
Chipsets")
The Qualcomm DisplayPort driver contains traces of the necessary
plumbing to hook up USB HPD, in the form of the dp_hpd module and the
dp_usbpd_cb struct. Use this as basis for implementing the
oob_hotplug_event() callback, by amending the dp_hpd module with the
missing logic.
Overall the
In some implementations, such as the Qualcomm platforms, the display
driver has no way to query the current HPD state and as such it's
impossible to distinguish between disconnect and attention events.
Add a parameter to drm_connector_oob_hotplug_event() to pass the HPD
state.
Also push the test
On 22/04/2022 22:45, Abhinav Kumar wrote:
Using intf_idx even for writeback interfaces is confusing
because intf_idx is of type enum dpu_intf but the index used
for writeback is of type enum dpu_wb.
In addition, this makes it easier to separately check the
availability of the two as its
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:
Using intf_idx even for writeback interfaces is confusing
because intf_idx is of type enum dpu_intf but the index used
for writeback is of type enum dpu_wb.
In addition, this makes it easier to separately check the
availability of the two as its possible that there are boards
which don't have any
As promised here [1], this is a follow up change to separate out
wb_idx and intf_idx for better clarity in dpu_encoder.
This also helps to easily handle boards which do not have a physical
display but can still be validated using writeback interface.
In addition, this also takes care of adding
On Fri, 22 Apr 2022 at 21:18, Abhinav Kumar wrote:
>
> Hi Dmitry
>
> On 4/22/2022 3:37 AM, Dmitry Baryshkov wrote:
> > On Fri, 22 Apr 2022 at 04:59, Abhinav Kumar
> > wrote:
> >>
> >>
> >>
> >> On 4/21/2022 5:22 PM, Dmitry Baryshkov wrote:
> >>> On Fri, 22 Apr 2022 at 02:07, Abhinav Kumar
>
Quoting cgel@gmail.com (2022-04-22 01:49:51)
> From: Lv Ruyi
>
> The irq_of_parse_and_map() function returns 0 on failure, and does not
> return an negative value.
>
> Fixes: 8ede2ecc3e5e ("drm/msm/dp: Add DP compliance tests on Snapdragon
> Chipsets")
> Reported-by: Zeal Robot
>
Hi Dmitry
On 4/22/2022 3:37 AM, Dmitry Baryshkov wrote:
On Fri, 22 Apr 2022 at 04:59, Abhinav Kumar wrote:
On 4/21/2022 5:22 PM, Dmitry Baryshkov wrote:
On Fri, 22 Apr 2022 at 02:07, Abhinav Kumar wrote:
Hi Dmitry
Thanks for the review.
One question below.
On 4/21/2022 3:40 PM,
Hi,
On Fri, Apr 22, 2022 at 9:05 AM Abhinav Kumar wrote:
>
> Hi Doug
>
> For the lockdep error, the splat looks similar to what kuogee fixed
> recently.
>
> Can you please check if below patch is present in your tree?
>
> https://patchwork.freedesktop.org/patch/481396/
Indeed I did have that in
Hi Doug
For the lockdep error, the splat looks similar to what kuogee fixed
recently.
Can you please check if below patch is present in your tree?
https://patchwork.freedesktop.org/patch/481396/
Thanks
Abhinav
On 4/22/2022 8:55 AM, Doug Anderson wrote:
Hi,
On Fri, Apr 22, 2022 at 2:11 AM
Hi,
On Fri, Apr 22, 2022 at 2:11 AM Sankeerth Billakanti
wrote:
>
> 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
Hi,
On Mon, Mar 21, 2022 at 8:27 PM Vinod Polimera
wrote:
>
> Set mdp clock to max clock rate during probe/bind sequence from the
> opp table so that rails are not at undetermined state. Since we do not
> know what will be the rate set in boot loader, it would be ideal to
> vote at max
Hi,
On Fri, Apr 22, 2022 at 2:11 AM Sankeerth Billakanti
wrote:
>
> 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
Hi,
On Fri, Apr 22, 2022 at 2:11 AM Sankeerth Billakanti
wrote:
>
> This patch adds support for generic eDP sink through aux_bus. The eDP/DP
> controller driver should support aux transactions originating from the
> panel-edp driver and hence should be initialized and ready.
>
> The panel bridge
Il 22/04/22 10:52, cgel@gmail.com ha scritto:
From: Lv Ruyi
The irq_of_parse_and_map() function returns 0 on failure, and does not
return an negative value.
Reported-by: Zeal Robot
Signed-off-by: Lv Ruyi
Reviewed-by: AngeloGioacchino Del Regno
On Fri, 22 Apr 2022 at 11:52, wrote:
>
> From: Lv Ruyi
>
> The irq_of_parse_and_map() function returns 0 on failure, and does not
> return an negative value.
>
> Reported-by: Zeal Robot
> Signed-off-by: Lv Ruyi
Reviewed-by: Dmitry Baryshkov
> ---
> drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
On Fri, 22 Apr 2022 at 11:50, wrote:
>
> From: Lv Ruyi
>
> The irq_of_parse_and_map() function returns 0 on failure, and does not
> return an negative value.
>
> Fixes: 8ede2ecc3e5e ("drm/msm/dp: Add DP compliance tests on Snapdragon
> Chipsets")
> Reported-by: Zeal Robot
> Signed-off-by: Lv
On Fri, 22 Apr 2022 at 06:10, Yang Yingliang wrote:
>
> It will cause null-ptr-deref if platform_get_resource_byname() returns NULL,
> we need check the return value.
>
> Fixes: c6a57a50ad56 ("drm/msm/hdmi: add hdmi hdcp support (V3)")
> Signed-off-by: Yang Yingliang
Reviewed-by: Dmitry
On Fri, 22 Apr 2022 at 04:59, Abhinav Kumar wrote:
>
>
>
> On 4/21/2022 5:22 PM, Dmitry Baryshkov wrote:
> > On Fri, 22 Apr 2022 at 02:07, Abhinav Kumar
> > wrote:
> >>
> >> Hi Dmitry
> >>
> >> Thanks for the review.
> >>
> >> One question below.
> >>
> >> On 4/21/2022 3:40 PM, Dmitry Baryshkov
Hi,
On Thu, Apr 21, 2022 at 07:49:12PM -0700, Stephen Boyd wrote:
> +Maxime
>
> Quoting Dmitry Baryshkov (2022-04-19 16:54:47)
> > Since the commit 948fb0969eae ("clk: Always clamp the rounded rate"),
> > the clk_core_determine_round_nolock() would clamp the requested rate
> > between min and
The eDP controller does not have a reliable way keep panel
powered on to read the sink capabilities. So, the controller
driver cannot validate if a mode can be supported by the
source. We will rely on the panel driver to populate only
the supported modes for now.
Signed-off-by: Sankeerth
The source device should ensure the sink is ready before proceeding to
read the sink capability or perform any aux transactions. The sink
will indicate its readiness by asserting the HPD line. The controller
driver needs to wait for the hpd line to be asserted by the sink before
it performs any
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 always connected, the controller driver can skip the eDP
connect and
This patch adds support for generic eDP sink through aux_bus. The eDP/DP
controller driver should support aux transactions originating from the
panel-edp driver and hence should be initialized and ready.
The panel bridge supporting the panel should be ready before the bridge
connector is
This series adds support for generic eDP panel over aux_bus.
These changes are dependent on the following patches:
https://patchwork.kernel.org/project/linux-arm-msm/patch/20220211224006.1797846-5-dmitry.barysh...@linaro.org/
From: Lv Ruyi
The irq_of_parse_and_map() function returns 0 on failure, and does not
return an negative value.
Reported-by: Zeal Robot
Signed-off-by: Lv Ruyi
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
From: Lv Ruyi
The irq_of_parse_and_map() function returns 0 on failure, and does not
return an negative value.
Fixes: 8ede2ecc3e5e ("drm/msm/dp: Add DP compliance tests on Snapdragon
Chipsets")
Reported-by: Zeal Robot
Signed-off-by: Lv Ruyi
---
drivers/gpu/drm/msm/dp/dp_display.c | 2 +-
1
64 matches
Mail list logo
