one>
On 2021-08-17 20:30, abhin...@codeaurora.org wrote:
On 2021-06-17 15:20, Dmitry Baryshkov wrote:
DPU interrupts code allows multiple callbacks per interrut. In reality
/interrupt
none of the interrupts is shared between blocks (and will probably
never
be). Drop support for registering
On 2021-10-18 11:36, Bjorn Andersson wrote:
On Mon 18 Oct 11:07 PDT 2021, abhin...@codeaurora.org wrote:
Hi Bjorn
On 2021-10-17 09:42, Bjorn Andersson wrote:
> On Fri 15 Oct 16:53 PDT 2021, abhin...@codeaurora.org wrote:
>
> > On 2021-10-15 16:17, Bjorn Andersson wrote:
> > > In the cleanup
On 2021-07-04 18:21, Dmitry Baryshkov wrote:
If SmartDMA is supported by the hardware, SSPPs allow using two RGB
layers per the hardware pipe (with some additional restrictions, like
no
support for scaling, etc). Register additional planes (two per the
SSPP)
and check if we can use multirect
On 2021-07-04 18:21, Dmitry Baryshkov wrote:
Client driven prefetch (CDP) is properly setup only for SSPP REC0
currently. Enable client driven prefetch also for SSPP REC1.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 12
On 2021-07-04 18:21, Dmitry Baryshkov wrote:
Downstream driver uses dpu->caps->smart_dma_rev to update
sspp->cap->features with the bit corresponding to the supported
SmartDMA
version. Upstream driver does not do this, resulting in SSPP subdriver
not enbaling setup_multirect callback. Make
On 2021-11-09 12:21, Dmitry Baryshkov wrote:
On Tue, 9 Nov 2021 at 23:15, wrote:
On 2021-07-04 18:21, Dmitry Baryshkov wrote:
> Stop limiting zpos property values, we use normalized_zpos anyway. And
> nothing stops userspace from assigning several planes to a single zpos
> (it is a userspace
On 2021-07-04 18:21, Dmitry Baryshkov wrote:
Add support for handling and allocting SSPP blocks through the resource
manager. Handling code is not converted to use it though.
Signed-off-by: Dmitry Baryshkov
Conceptually this is identical to the previous attempt from QC on this:
On 2021-07-04 18:21, Dmitry Baryshkov wrote:
Stop limiting zpos property values, we use normalized_zpos anyway. And
nothing stops userspace from assigning several planes to a single zpos
(it is a userspace bug, but the kernel is forgiving about it).
Userspace assigning several planes to a
On 2021-07-04 18:21, Dmitry Baryshkov wrote:
Add DPU_SSPP_CSC_ANY denoting any CSC block. As we are at it, rewrite
DPU_SSPP_SCALER (any scaler) to use BIT(x) instead of hand-coded
bitshifts.
This can go independent of the multi-rect series, so can you please take
this with the
first half of
On 2021-07-04 18:21, Dmitry Baryshkov wrote:
As we are going to add virtual planes, add the list of supported
formats
to the hw catalog entry. It will be used to setup universal planes,
with
later selecting a pipe depending on whether the YUV format is used for
the framebuffer.
Signed-off-by:
On 2021-10-01 08:11, Sean Paul wrote:
From: Sean Paul
This patch expands upon the HDCP helper library to manage HDCP
enable, disable, and check.
Previous to this patch, the majority of the state management and sink
interaction is tucked inside the Intel driver with the understanding
that once
On 2021-10-01 08:11, Sean Paul wrote:
From: Sean Paul
A couple more useless checks to remove in dpu_encoder.
Reviewed-by: Stephen Boyd
Signed-off-by: Sean Paul
Reviewed-by: Abhinav Kumar
Link:
https://patchwork.freedesktop.org/patch/msgid/20210913175747.47456-10-s...@poorly.run
#v1
Link:
On 2021-10-01 08:11, Sean Paul wrote:
From: Sean Paul
This patch updates the connector's property value in 2 cases which were
previously missed:
1- Content type changes. The value should revert back to DESIRED from
ENABLED in case the driver must re-authenticate the link due to the
new
On 2021-10-01 08:11, Sean Paul wrote:
From: Sean Paul
This patch moves the hdcp atomic check from i915 to drm_hdcp so other
drivers can use it. No functional changes, just cleaned up some of the
code when moving it over.
Acked-by: Jani Nikula
Signed-off-by: Sean Paul
For the drm/hdcp
On 2021-10-01 08:11, Sean Paul wrote:
From: Sean Paul
encoder->commit() was being misused because there were some global
resources which needed to be tweaked in encoder->enable() which were
not
accessible in dpu_encoder.c. That is no longer true and the redirect
serves no purpose any longer.
On 2021-09-30 07:00, Dmitry Baryshkov wrote:
In preparations of virtualizing the dpu_plane rip out debugfs support
from dpu_plane (as it is mostly used to expose plane's pipe registers).
Also move disable_danger file to danger/ debugfs subdir where it
belongs.
Signed-off-by: Dmitry Baryshkov
On 2021-09-30 07:00, Dmitry Baryshkov wrote:
Do not cache hw_pipe's sblk in dpu_plane. Use
pdpu->pipe_hw->cap->sblk directly.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 25 ---
1 file changed, 8
On 2021-09-30 07:00, Dmitry Baryshkov wrote:
Do not cache hw_pipe's features in dpu_plane. Use
pdpu->pipe_hw->cap->features directly.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 12 +---
1 file changed, 5 insertions(+),
On 2021-09-30 06:59, Dmitry Baryshkov wrote:
Remove struct dpu_hw_pipe_cdp_cfg instance from dpu_plane, it is an
interim configuration structure. Allocate it on stack instead.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 14
On 2021-09-30 06:59, Dmitry Baryshkov wrote:
Simplify code surrounding CSC table setup by removing struct
dpu_csc_cfg
pointer from dpu_plane and getting it directly at the CSC setup time.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
On 2021-09-30 06:59, Dmitry Baryshkov wrote:
Scaler and pixel_ext configuration does not contain a long living
state,
it is used only during plane update, so remove these two fiels from
fiels ---> fields
dpu_plane_state and allocate them on stack.
Signed-off-by: Dmitry Baryshkov
While
On 2021-09-30 06:59, Dmitry Baryshkov wrote:
struct dpu_hw_pipe_cfg represents an interim state during atomic
update/color fill, so move it out of struct dpu_plane.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 104
On 2021-09-30 06:59, Dmitry Baryshkov wrote:
The stage_cfg is not used outside of _dpu_crtc_blend_setup(), so remove
the temporary config from global struct.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 11 ++-
On 2021-09-30 06:59, Dmitry Baryshkov wrote:
LUT levels are setup outside of setup_qos_ctrl, so remove them from the
struct dpu_hw_pipe_qos_cfg.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 15 ---
On 2021-10-01 18:27, Dmitry Baryshkov wrote:
Use clk_bulk_* API instead of hand-coding them. Note, this drops
support
for legacy clk naming (e.g. "iface_clk" instead of just "iface"),
however all in-kernel device trees were converted long long ago. The
warning is present there since 2017.
On 2021-10-06 13:48, Dmitry Baryshkov wrote:
There is no reason to set clock parents manually, use device tree to
assign DSI/display clock parents to DSI PHY clocks. Dropping this
manual
setup allows us to drop repeating code and to move registration of hw
clock providers to generic place.
On 2021-10-06 13:48, Dmitry Baryshkov wrote:
Move DPHY/CPHY setting from msm_dsi_host_set_src_pll() to new function
msm_dsi_host_set_phy_mode().
Signed-off-by: Dmitry Baryshkov
Just a minor comment, can you also include the part which removes
msm_host->cphy_mode = src_phy->cphy_mode; from
On 2021-10-16 07:21, Dmitry Baryshkov wrote:
On Sat, 16 Oct 2021 at 01:25, wrote:
Hi Dmitry
On 2021-10-14 17:11, Dmitry Baryshkov wrote:
> Merge old hdmi_bridge and hdmi_connector implementations. Use
> drm_bridge_connector instead.
>
Can you please comment on the validation done on this
On 2021-10-16 15:18, Bjorn Andersson wrote:
The sc8180x has 2 DP and 1 eDP controllers, add support for these to
the
DP driver.
Link:
https://lore.kernel.org/linux-arm-msm/20210725042436.3967173-7-bjorn.anders...@linaro.org/
Signed-off-by: Bjorn Andersson
Reviewed-by: Abhinav Kumar
---
On 2021-10-16 15:18, Bjorn Andersson wrote:
Based on the removal of the g_dp_display and the movement of the
priv->dp lookup into the DP code it's now possible to have multiple
DP instances.
In line with the other controllers in the MSM driver, introduce a
per-compatible list of base addresses
On 2021-10-16 15:18, Bjorn Andersson wrote:
eDP panels might need some power sequencing and backlight management,
so make it possible to associate a drm_panel with an eDP instance and
prepare and enable the panel accordingly.
Now that we know which hardware instance is DP and which is eDP,
Hi Bjorn
On 2021-10-17 09:42, Bjorn Andersson wrote:
On Fri 15 Oct 16:53 PDT 2021, abhin...@codeaurora.org wrote:
On 2021-10-15 16:17, Bjorn Andersson wrote:
> In the cleanup path of the MSM DP driver the DP driver's debugfs files
> are destroyed by invoking debugfs_remove_recursive() on
On 2021-10-15 16:17, Bjorn Andersson wrote:
In the cleanup path of the MSM DP driver the DP driver's debugfs files
are destroyed by invoking debugfs_remove_recursive() on debug->root,
which during initialization has been set to minor->debugfs_root.
To allow cleaning up the DP driver's debugfs
On 2021-10-15 16:13, Bjorn Andersson wrote:
dpu_kms_debugfs_init() and hence dp_debug_get() gets invoked for each
minor being registered. But dp_debug_get() will allocate a new struct
dp_debug for each call and this will be associated as dp->debug.
As such dp_debug will create debugfs files in
Hi Dmitry
On 2021-10-14 17:11, Dmitry Baryshkov wrote:
Merge old hdmi_bridge and hdmi_connector implementations. Use
drm_bridge_connector instead.
Can you please comment on the validation done on this change?
Has basic bootup been verified on db820c as thats the only platform
which shall use
On 2021-10-14 17:10, Dmitry Baryshkov wrote:
Switch to using bulk regulator API instead of hand coding loops.
Nice cleanup!
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/hdmi/hdmi.c | 34 +++
Hi Dmitry
No concerns from our side to drop this.
Reviewed-by: Abhinav Kumar for the series.
Thanks
Abhinav
On 2021-10-01 09:50, Dmitry Baryshkov wrote:
MSM DRM driver has support for eDP block present on MSM 8x74/8x84 SoC
families. However since addition back in 2015 this driver received
On 2021-10-12 16:38, Bjorn Andersson wrote:
On Tue 12 Oct 16:03 PDT 2021, abhin...@codeaurora.org wrote:
On 2021-10-09 20:04, Bjorn Andersson wrote:
> The debugfs code is provided an array of a single drm_connector. Then to
> access the connector, the list of all connectors of the DRM device
On 2021-10-09 20:04, Bjorn Andersson wrote:
The debugfs code is provided an array of a single drm_connector. Then
to
access the connector, the list of all connectors of the DRM device is
traversed and all non-DisplayPort connectors are skipped, to find the
one and only DisplayPort connector.
On 2021-10-11 13:16, Marijn Suijten wrote:
div_u64_rem provides the result of the division and additionally the
remainder; don't use this function to solely calculate the remainder
while calculating the division again with div_u64.
A similar improvement was applied earlier to the 10nm pll in
Hi Bjorn and Stephen
On 2021-10-06 13:39, Bjorn Andersson wrote:
On Wed 06 Oct 11:59 PDT 2021, Stephen Boyd wrote:
Quoting Bjorn Andersson (2021-10-06 11:05:09)
> On Wed 06 Oct 10:19 PDT 2021, Stephen Boyd wrote:
>
> > Quoting Bjorn Andersson (2021-10-06 10:07:17)
> > > On Tue 05 Oct 21:26
On 2021-10-05 19:09, Bjorn Andersson wrote:
On Tue 05 Oct 17:35 PDT 2021, abhin...@codeaurora.org wrote:
Hi Bjorn
On 2021-10-05 16:13, Bjorn Andersson wrote:
> eDP panels might need some power sequencing and backlight management,
> so make it possible to associate a drm_panel with an eDP
Hi Bjorn
On 2021-10-05 16:13, Bjorn Andersson wrote:
eDP panels might need some power sequencing and backlight management,
so make it possible to associate a drm_panel with an eDP instance and
prepare and enable the panel accordingly.
Now that we know which hardware instance is DP and which is
On 2021-10-01 10:43, Bjorn Andersson wrote:
Not all platforms has DP_P0 at offset 0x1000 from the beginning of the
DP block. So split the dss_io_data memory region into a set of
sub-regions, to make it possible in the next patch to specify each of
the sub-regions individually.
Reviewed-by:
On 2021-10-01 10:43, Bjorn Andersson wrote:
In order to deal with multiple memory ranges in the following commit
change the ioremap wrapper to not poke directly into the dss_io_data
struct.
While at it, devm_ioremap_resource() already prints useful error
messages on failure, so omit the
On 2021-10-01 10:43, Bjorn Andersson wrote:
reg was defined as one region covering the entire DP block, but the
memory map is actually split in 4 regions and obviously the size of
these regions differs between platforms.
Switch the reg to require that all four regions are specified instead.
It
On 2021-10-01 11:00, Bjorn Andersson wrote:
The sc8180x has 2 DP and 1 eDP controllers, add support for these to
the
DP driver.
Reviewed-by: Stephen Boyd
Signed-off-by: Bjorn Andersson
Reviewed-by: Abhinav Kumar
---
Changes since v2:
- None
drivers/gpu/drm/msm/dp/dp_display.c | 7
On 2021-10-01 11:00, Bjorn Andersson wrote:
The Qualcomm SC8180x has 2 DP controllers and 1 eDP controller, add
compatibles for these to the msm/dp binding.
Reviewed-by: Stephen Boyd
Signed-off-by: Bjorn Andersson
Reviewed-by: Abhinav Kumar
---
Changes since v2:
- None
On 2021-10-05 13:16, abhin...@codeaurora.org wrote:
On 2021-10-01 11:00, Bjorn Andersson wrote:
Based on the removal of the g_dp_display and the movement of the
priv->dp lookup into the DP code it's now possible to have multiple
DP instances.
In line with the other controllers in the MSM
On 2021-10-01 11:00, Bjorn Andersson wrote:
Based on the removal of the g_dp_display and the movement of the
priv->dp lookup into the DP code it's now possible to have multiple
DP instances.
In line with the other controllers in the MSM driver, introduce a
per-compatible list of base addresses
On 2021-10-01 11:00, Bjorn Andersson wrote:
Functions in the DisplayPort code that relates to individual instances
(encoders) are passed both the struct msm_dp and the struct
drm_encoder. But
in a situation where multiple DP instances would exist this means that
the caller need to resolve
On 2021-10-01 11:00, Bjorn Andersson wrote:
As the Qualcomm DisplayPort driver only supports a single instance of
the driver the commonly used struct dp_display is kept in a global
variable. As we introduce additional instances this obviously doesn't
work.
Replace this with a combination of
On 2021-10-01 08:11, Sean Paul wrote:
From: Sean Paul
This patch updates the connector's property value in 2 cases which were
previously missed:
1- Content type changes. The value should revert back to DESIRED from
ENABLED in case the driver must re-authenticate the link due to the
new
On 2021-10-04 03:38, Dan Carpenter wrote:
The msm_iommu_new() returns error pointers on failure so check for that
to avoid an Oops.
Fixes: ccac7ce373c1 ("drm/msm: Refactor address space initialization")
Signed-off-by: Dan Carpenter
Reviewed-by: Abhinav Kumar
---
On 2021-10-04 06:47, Dan Carpenter wrote:
The "vbif->features" is type unsigned long but the debugfs file
is treating it as a u32 type. This will work in little endian
systems, but the correct thing is to change the debugfs to use
an unsigned long.
Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU
On 2021-10-01 18:08, Dmitry Baryshkov wrote:
The DSI host might be left in some state by the bootloader. If this
state generates an IRQ, it might hang the system by holding the
interrupt line before the driver sets up the DSI host to the known
state.
Move the request_irq into msm_dsi_host_init
Hi Dmitry
On 2021-07-04 18:20, Dmitry Baryshkov wrote:
As discussed on IRC, change dpu_plane implementation to be virtual:
register unified planes and select backing SSPP block at runtime.
Use msm.dpu_use_virtual_planes=1 to enable usage of virtual planes
rather than statically allocated SSPPs
On 2021-09-28 11:02, Sean Paul wrote:
On Tue, Sep 21, 2021 at 07:25:41PM -0700, abhin...@codeaurora.org
wrote:
On 2021-09-15 13:38, Sean Paul wrote:
> From: Sean Paul
>
> This patch adds HDCP 1.x support to msm DP connectors using the new HDCP
> helpers.
>
> Cc: Stephen Boyd
> Signed-off-by:
Hi Sean
On 2021-09-28 10:33, Sean Paul wrote:
On Tue, Sep 21, 2021 at 04:34:59PM -0700, abhin...@codeaurora.org
wrote:
On 2021-09-15 13:38, Sean Paul wrote:
> From: Sean Paul
>
> This patch expands upon the HDCP helper library to manage HDCP
> enable, disable, and check.
>
> Previous to this
On 2021-09-28 11:06, Sean Paul wrote:
On Tue, Sep 21, 2021 at 07:30:29PM -0700, abhin...@codeaurora.org
wrote:
Hi Sean
On 2021-09-15 13:38, Sean Paul wrote:
> From: Sean Paul
>
> Hello again,
> This is the second version of the HDCP helper patchset. See version 1
> here:
On 2021-09-27 18:29, Dmitry Baryshkov wrote:
On 28/09/2021 04:19, abhin...@codeaurora.org wrote:
On 2021-09-27 18:06, Dmitry Baryshkov wrote:
On Tue, 28 Sept 2021 at 03:22, wrote:
On 2021-09-25 12:43, Dmitry Baryshkov wrote:
> On 21/09/2021 23:52, abhin...@codeaurora.org wrote:
>> On
On 2021-09-27 18:06, Dmitry Baryshkov wrote:
On Tue, 28 Sept 2021 at 03:22, wrote:
On 2021-09-25 12:43, Dmitry Baryshkov wrote:
> On 21/09/2021 23:52, abhin...@codeaurora.org wrote:
>> On 2021-09-21 10:47, Dmitry Baryshkov wrote:
>>> Hi,
>>>
>>> On Tue, 21 Sept 2021 at 20:01, wrote:
On 2021-09-25 12:43, Dmitry Baryshkov wrote:
On 21/09/2021 23:52, abhin...@codeaurora.org wrote:
On 2021-09-21 10:47, Dmitry Baryshkov wrote:
Hi,
On Tue, 21 Sept 2021 at 20:01, wrote:
On 2021-09-21 09:22, Dmitry Baryshkov wrote:
> The DSI host might be left in some state by the bootloader.
Hi Sean
On 2021-09-15 13:38, Sean Paul wrote:
From: Sean Paul
Hello again,
This is the second version of the HDCP helper patchset. See version 1
here: https://patchwork.freedesktop.org/series/94623/
In this second version, I've fixed up the oopsies exposed by 0-day and
yamllint and
On 2021-09-15 13:38, Sean Paul wrote:
From: Sean Paul
Make includes alphabetical in dpu_kms.c
Signed-off-by: Sean Paul
Reviewed-by: Abhinav Kumar
Link:
https://patchwork.freedesktop.org/patch/msgid/20210913175747.47456-9-s...@poorly.run
#v1
Changes in v2:
-None
---
On 2021-09-15 13:38, Sean Paul wrote:
From: Sean Paul
This patch adds HDCP 1.x support to msm DP connectors using the new
HDCP
helpers.
Cc: Stephen Boyd
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20210913175747.47456-15-s...@poorly.run
#v1
Changes in v2:
On 2021-09-15 13:38, Sean Paul wrote:
From: Sean Paul
This patch expands upon the HDCP helper library to manage HDCP
enable, disable, and check.
Previous to this patch, the majority of the state management and sink
interaction is tucked inside the Intel driver with the understanding
that once
On 2021-09-21 10:47, Dmitry Baryshkov wrote:
Hi,
On Tue, 21 Sept 2021 at 20:01, wrote:
On 2021-09-21 09:22, Dmitry Baryshkov wrote:
> The DSI host might be left in some state by the bootloader. If this
> state generates an IRQ, it might hang the system by holding the
> interrupt line before
On 2021-09-21 09:22, Dmitry Baryshkov wrote:
The DSI host might be left in some state by the bootloader. If this
state generates an IRQ, it might hang the system by holding the
interrupt line before the driver sets up the DSI host to the known
state.
Move the request/free_irq calls into
On 2021-09-21 09:22, Dmitry Baryshkov wrote:
The commit 9f91f22aafcd ("drm/msm/dsi: remove duplicate fields from
dsi_pll_Nnm instances") mistakenly changed registered clock names.
While
the platform is in progress of migration to using clock properties in
the dts rather than the global clock
On 2021-07-21 10:55, Sean Paul wrote:
From: Sean Paul
The debug messages shouldn't be logged as errors when debug categories
are enabled. Use the drm logging helpers to do the right thing
Signed-off-by: Sean Paul
Reviewed-by: Abhinav Kumar
Link:
Hi Fabio
Ah, I did not realize that amd compatible is present in the list and its
quite a surprise.
/*
* We don't know what's the best binding to link the gpu with the drm
device.
* Fow now, we just hunt for all the possible gpus that we support, and
add them
* as components.
*/
static
Hi Fabio
Thanks for confirming.
Although I have no issues with your change, I am curious why even msm is
probing and/or binding.
Your device tree should not be having any mdp/dpu nodes then.
Thanks
Abhinav
On 2021-09-16 04:42, Fabio Estevam wrote:
Hi Abhinav,
On Wed, Sep 15, 2021 at 11:22
On 2021-09-06 13:25, Marijn Suijten wrote:
div_u64_rem provides the result of the divison and additonally the
remainder; don't use this function to solely calculate the remainder
while calculating the division again with div_u64.
A similar improvement was applied earlier to the 10nm pll in
On 2021-08-30 11:13, Mark Yacoub wrote:
From: Mark Yacoub
[why]
vsync_cnt atomic counter increments for every hw vsync. On the other
hand, frame count is a register that increments when the frame gets
actually pushed out. We cannnot read this register whenever the timing
engine is off, but
On 2021-06-17 15:20, Dmitry Baryshkov wrote:
Drop the wrapping structures and the enum used to index those
structures
in dpu_kms. Instead of them use IRQ indices and callback functions
directly.
Signed-off-by: Dmitry Baryshkov
Is this change really needed because I think the enum based
On 2021-06-17 15:20, Dmitry Baryshkov wrote:
Get rid of dpu_encoder_helper_register_irq/unregister_irq helpers, call
dpu_core_register/unregister_callback directly, without surrounding
them
with helpers.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
On 2021-06-17 15:20, Dmitry Baryshkov wrote:
Remove extra dpu_irq_* wrappers from dpu_kms.c, merge them directly
into
dpu_core_irq_* functions.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.h | 12 -
On 2021-06-17 15:20, Dmitry Baryshkov wrote:
DPU interrupts code allows multiple callbacks per interrut. In reality
/interrupt
none of the interrupts is shared between blocks (and will probably
never
be). Drop support for registering multiple callbacks per interrupt to
simplify interrupt
On 2021-06-17 15:20, Dmitry Baryshkov wrote:
As dpu_core_irq was merged into dpu_hw_intr, merge data structures too,
removing the need for a separate data structure.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 51
On 2021-06-17 15:20, Dmitry Baryshkov wrote:
We already clear the IRQ status register before processing IRQs, so do
not clear the register again. Especially do not clear the IRQ status
_after_ processing the IRQ as this way we can loose the event.
Signed-off-by: Dmitry Baryshkov
Reviewed-by:
On 2021-06-17 15:20, Dmitry Baryshkov wrote:
With dpu_core_irq being the wrapper around dpu_hw_interrupts, there is
little sense in having them separate. Squash them together to remove
another layer of abstraction (hw_intr ops).
Signed-off-by: Dmitry Baryshkov
Overall, I think this is a
On 2021-06-28 12:19, Dmitry Baryshkov wrote:
Add support for alpha blending properties. Setup the plane blend state
according to those properties.
Signed-off-by: Dmitry Baryshkov
I think this has already been picked up by Rob but just had a couple of
comments
below.
Also, how has this
On 2021-08-11 16:28, Rob Clark wrote:
On Wed, Aug 11, 2021 at 4:11 PM wrote:
On 2021-08-11 11:43, Rob Clark wrote:
> On Wed, Aug 11, 2021 at 11:12 AM Mark Yacoub
> wrote:
>>
>> From: Mark Yacoub
>>
>> [why]
>> Reading frame count register used to get the vblank counter, which
>> calls
>>
On 2021-08-11 11:43, Rob Clark wrote:
On Wed, Aug 11, 2021 at 11:12 AM Mark Yacoub
wrote:
From: Mark Yacoub
[why]
Reading frame count register used to get the vblank counter, which
calls
dpu_encoder_phys to get the frame count. Even when it's disabled, the
vblank counter (through frame
On 2021-08-05 10:08, Dmitry Baryshkov wrote:
Unlike previous generations, 7nm PHYs are required to collaborate with
the host for conitnuos clock mode. Add changes neccessary to enable
/continuous
/necessary
continuous clock mode in the 7nm DSI PHYs.
Signed-off-by: Dmitry Baryshkov
---
Hi Marijn
Thanks for reviewing and testing the latest patchset.
On 2021-08-10 15:59, Marijn Suijten wrote:
Hi Abhinav,
On 7/16/21 2:01 AM, abhin...@codeaurora.org wrote:
Hi Marijn
Sorry for the late response.
Apologies from my side as well.
[...]
+static void
On 2021-08-03 02:06, Thomas Zimmermann wrote:
Drop the DRM IRQ midlayer in favor of Linux IRQ interfaces. DRM's
IRQ helpers are mostly useful for UMS drivers. Modern KMS drivers
don't benefit from using it.
DRM IRQ callbacks are now being called directly or inlined.
Signed-off-by: Thomas
On 2021-07-14 23:52, Vinod Koul wrote:
When DSC is enabled, we need to pass the DSC parameters to panel driver
as well, so add a dsc parameter in panel and set it when DSC is enabled
Signed-off-by: Vinod Koul
based on the comments on prev patches in the series, this will need to
be reworked
On 2021-07-14 23:52, Vinod Koul wrote:
When DSC is enabled, we need to configure DSI registers accordingly and
configure the respective stream compression registers.
Add support to calculate the register setting based on DSC params and
timing information and configure these registers.
On 2021-07-14 23:52, Vinod Koul wrote:
For DSC to work we typically need a 2,2,1 configuration. This should
suffice for resolutions upto 4k. For more resolutions like 8k this
won't
work.
The topology information is provided by DTS so we try to deduce the
topology required for DSC.
On 2021-07-14 23:52, Vinod Koul wrote:
When DSC is enabled in DT, we need to configure the encoder for DSC
configuration, calculate DSC parameters for the given timing.
This patch adds that support by adding dpu_encoder_prep_dsc() which is
invoked when DSC is enabled in DT
correct me if wrong
On 2021-07-14 23:51, Vinod Koul wrote:
We cannot enable mode_3d when we are using the DSC. So pass
configuration to detect DSC is enabled and not enable mode_3d
when we are using DSC
We add a helper dpu_encoder_helper_get_dsc_mode() to detect dsc
enabled and pass this to .setup_intf_cfg()
This
On 2021-07-14 23:51, Vinod Koul wrote:
Later gens of hardware have DSC bits moved to hw_ctl, so configure
these
bits so that DSC would work there as well
Signed-off-by: Vinod Koul
Please correct me if wrong but here you seem to be flushing all the DSC
bits
even the unused ones. This will
On 2021-07-14 23:51, Vinod Koul wrote:
This add SDM845 DSC blocks into hw_catalog
/add --> adds
Signed-off-by: Vinod Koul
---
Changes since RFC:
- use BIT values from MASK
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 22 +++
1 file changed, 22 insertions(+)
diff --git
On 2021-07-14 23:51, Vinod Koul wrote:
This add the bits in RM to enable the DSC blocks
Signed-off-by: Vinod Koul
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 1 +
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 32 +
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 1 +
3 files
On 2021-07-14 23:51, Vinod Koul wrote:
In SDM845, DSC can be enabled by writing to pingpong block registers,
so
add support for DSC in hw_pp
Signed-off-by: Vinod Koul
Reviewed-by: Abhinav Kumar
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c | 32 +++
On 2021-07-14 23:51, Vinod Koul wrote:
Display Stream Compression (DSC) is one of the hw blocks in dpu, so add
support by adding hw blocks for DSC
Signed-off-by: Vinod Koul
---
Changes since RFC:
- Drop unused enums
drivers/gpu/drm/msm/Makefile | 1 +
On 2021-07-14 23:51, Vinod Koul wrote:
Display Stream Compression (DSC) parameters need to be calculated. Add
helpers and struct msm_display_dsc_config in msm_drv for this
msm_display_dsc_config uses drm_dsc_config for DSC parameters.
Signed-off-by: Vinod Koul
---
Changes since RFC:
- Drop
Hi Bjorn
On 2021-07-24 21:24, Bjorn Andersson wrote:
The current implementation supports a single DP instance and the DPU
code will
only match it against INTF_DP instance 0. These patches extends this to
allow
multiple DP instances and support for matching against DP instances
beyond 0.
1 - 100 of 295 matches
Mail list logo
