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 m
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 pa
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 d
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 SSPP
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 b
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:
https://patch
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 singl
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 th
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 c
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 pieces
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 insertions(+
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
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ss
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 addr
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 ++-
drivers/gpu
On 2021-09-30 06:59, Dmitry Baryshkov wrote:
Use plane->name instead of artificial pipe_name.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/
On 2021-09-30 06:59, Dmitry Baryshkov wrote:
The pipe_qos_cfg is used only in _dpu_plane_set_qos_ctrl(), so remove
it
from the dpu_plane struct and allocate it on stack when necessary.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
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 ---
drivers/gpu/drm/m
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.
Signe
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.
Sig
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 msm
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 chan
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
---
Cha
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 w
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,
parse
On 2021-10-16 15:18, Bjorn Andersson wrote:
As the following patches introduced support for multiple DP blocks in a
platform and some of those block might be eDP it becomes useful to be
able to specify the connector type per block.
Although there's only a single block at this point, the array of
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 debug
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 fi
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 b
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 +++
drivers/gpu/drm/msm/hdmi/hdm
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 o
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 is
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.
Bu
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
5c1
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 PDT
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 insta
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: Steph
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 unnecess
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 i
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
.../devicetree/bin
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 driver
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 w
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 which
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 exis
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 c
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
---
drivers/gpu/drm/msm/disp/dpu
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 a
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: S
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 p
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: https://patchwork.free
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 2021-09
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 incorporat
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
---
drivers/gpu/drm/msm/di
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 t
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 msm_dsi_
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 na
On 2021-07-21 10:55, Sean Paul wrote:
From: Sean Paul
The atomic state is printed if the DRM_UT_STATE is active, but it's
printed at INFO level. This patch converts it to use the debug
category printer so:
a- it's consistent with other DRM_UT_STATE logging
b- it's properly routed through drm_t
On 2021-07-21 10:55, Sean Paul wrote:
From: Sean Paul
This patch adds a new printer which will select the appropriate output
for a given debug category. Currently there is only one output target,
which is syslog. However in the future we'll have tracefs and it will
be
useful to print to syslog
On 2021-07-21 10:55, Sean Paul wrote:
From: Sean Paul
In preparation for tracefs support, rename drm_debug related functions
to reflect that it targets the syslog. This will allow us to
selectively
target syslog and/or tracefs.
No functional changes here.
Signed-off-by: Sean Paul
Reviewed
On 2021-07-21 10:55, Sean Paul wrote:
From: Sean Paul
In preparation for tracefs support, rename drm_debug related functions
to reflect that it targets the syslog. This will allow us to
selectively
target syslog and/or tracefs.
No functional changes here.
Signed-off-by: Sean Paul
Reviewed
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:
https://patchwork.freedesktop.org/patch/msgi
On 2021-07-21 10:55, Sean Paul wrote:
From: Sean Paul
This patch adds a new module parameter called drm.trace which accepts
the same mask as drm.debug. When a debug category is enabled, log
messages will be put in a new tracefs instance called drm for
consumption.
Using the new tracefs instanc
On 2021-07-21 10:55, Sean Paul wrote:
From: Sean Paul
Hi all,
I just had the pleasure of rebasing this set on our CrOS downstream
kernel and wanted to resend it for consideration once again. There
hasn't been any resistence to the set AFAIK, just perhaps not enough
motivation for anyone to hit
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
Hi Fabio
On 2021-09-14 10:48, Fabio Estevam wrote:
Since commit 98659487b845 ("drm/msm: add support to take dpu snapshot")
the following NULL pointer dereference is seen on i.MX53:
[ 3.275493] msm msm: bound 3000.gpu (ops a3xx_ops)
[ 3.287174] [drm] Initialized msm 1.8.0 20130625 for msm on
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
5c191
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 appro
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
---
drivers/gpu/drm/msm/di
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 -
.../gpu/drm/msm/disp/
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 handl
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: A
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 reason
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 been
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
---
Changes
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 msm_dsi_host_cmd_test_patt
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 Zimmer
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.
Signed-of
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.
Furthermore,
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 bu
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
1 - 100 of 315 matches
Mail list logo
