On 04/05/2022 02:21, Douglas Anderson wrote:
When doing DP AUX transfers there are two actors that need to be
powered in order for the DP AUX transfer to work: the DP source and
the DP sync.
Nit: sink
Commit bacbab58f09d ("drm: Mention the power state
requirement on side-channel operations")
On 2/9/2022 9:25 AM, Dmitry Baryshkov wrote:
Instead of querying the CTL for the flush mask (for SSPP, LM or DSPP),
storing the mask in the mixer configuration and then pushing the mask to
the CTL, tell CTL to cache the flush in place.
This follows the pattern of other update_pending_flush_
When doing DP AUX transfers there are two actors that need to be
powered in order for the DP AUX transfer to work: the DP source and
the DP sync. Commit bacbab58f09d ("drm: Mention the power state
requirement on side-channel operations") added some documentation
saying that the DP source is require
On 2/9/2022 9:25 AM, Dmitry Baryshkov wrote:
There no more need for the dpu_plane_pipe() function, crtc code can
access pstate->pipe_hw.idx directly.
Signed-off-by: Dmitry Baryshkov
Perhaps this can be squashed with the previous change.
Otherwise,
Reviewed-by: Abhinav Kumar
---
drive
On 2/9/2022 9:25 AM, Dmitry Baryshkov wrote:
There is no need to keep a separate function for calling into the ctl if
we already know all the details. Inline this function in the dpu_crtc.c
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_
While it works, for the most part, to assume that the panel has
finished probing when devm_of_dp_aux_populate_ep_devices() returns,
it's a bit fragile. This is talked about at length in commit
a1e3667a9835 ("drm/bridge: ti-sn65dsi86: Promote the AUX channel to
its own sub-dev").
When reviewing the
As talked about in this patch in the kerneldoc of
of_dp_aux_populate_ep_device() and also in the past in commit
a1e3667a9835 ("drm/bridge: ti-sn65dsi86: Promote the AUX channel to
its own sub-dev"), it can be difficult for eDP controller drivers to
know when the panel has finished probing when they
This patch is v2 of the first 2 patches from my RFC series ("drm/dp:
Improvements
for DP AUX channel") [1]. I've broken the series in two so we can make
progress on the two halves separately.
v2 of this series tries to incorporate all the feedback from v1. Hopefully
things are less confusing and
On 5/3/2022 3:11 PM, Dmitry Baryshkov wrote:
On 04/05/2022 00:34, Abhinav Kumar wrote:
On 2/9/2022 9:24 AM, Dmitry Baryshkov wrote:
As SSPP blocks are now visible through dpu_kms->rm.sspp_blocks, move
SSPP debugfs creation from dpu_plane to dpu_kms.
Change is fine by itself, but is it r
On 2/9/2022 9:25 AM, Dmitry Baryshkov wrote:
In preparation to adding fully virtualized planes, move struct
dpu_hw_pipe instance from struct dpu_plane to struct dpu_plane_state, as
it will become a part of state (allocated during atomic check) rather
than part of a plane (allocated during boot
On 04/05/2022 00:34, Abhinav Kumar wrote:
On 2/9/2022 9:24 AM, Dmitry Baryshkov wrote:
As SSPP blocks are now visible through dpu_kms->rm.sspp_blocks, move
SSPP debugfs creation from dpu_plane to dpu_kms.
Change is fine by itself, but is it really needed?
Wouldnt it be better to keep dpu_de
On 2/9/2022 9:24 AM, Dmitry Baryshkov wrote:
As SSPP blocks are now visible through dpu_kms->rm.sspp_blocks, move
SSPP debugfs creation from dpu_plane to dpu_kms.
Change is fine by itself, but is it really needed?
Wouldnt it be better to keep dpu_debugfs_sspp_init in dpu_plane.c?
Signed-o
On 5/3/2022 1:43 PM, Dmitry Baryshkov wrote:
Correct a typo in the address of the second DSI PHY in the SDM660 device
config.
Fixes: 694dd304cc29 ("drm/msm/dsi: Add phy configuration for SDM630/636/660")
Cc: Konrad Dybcio
Signed-off-by: Dmitry Baryshkov
Typo indeed. 0xc996400 is the corre
Correct a typo in the address of the second DSI PHY in the SDM660 device
config.
Fixes: 694dd304cc29 ("drm/msm/dsi: Add phy configuration for SDM630/636/660")
Cc: Konrad Dybcio
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c | 2 +-
1 file changed, 1 insertion(+),
Event thread supposed to exit from its while loop after kthread_stop().
However there may has possibility that event thread is pending in the
middle of wait_event due to condition checking never become true.
To make sure event thread exit its loop after kthread_stop(), this
patch OR kthread_should_
On 5/2/2022 6:13 PM, Stephen Boyd wrote:
Quoting Kuogee Hsieh (2022-05-02 16:04:28)
Event thread supposed to exit from its while loop after kthread_stop().
However there may has possibility that event thread is pending in the
middle of wait_event due to condition checking never become true.
To
On 2022-05-03 14:30, Dmitry Baryshkov wrote:
On Tue, 3 May 2022 at 13:57, Robin Murphy wrote:
On 2022-05-01 11:10, Dmitry Baryshkov wrote:
Move iommu_domain_alloc() in front of adress space/IOMMU initialization.
This allows us to drop final bits of struct mdp5_cfg_platform which
remained from
On Tue, May 3, 2022 at 5:12 AM Lucas Stach wrote:
>
> Am Montag, dem 02.05.2022 um 10:29 -0700 schrieb Rob Clark:
> > From: Rob Clark
> >
> > Running the GPU without an IOMMU is not really a supported (or sane)
> > configuration. Yet it can be useful during SoC bringup (ie. if the
> > iommu driv
On Tue, 3 May 2022 at 13:57, Robin Murphy wrote:
>
> On 2022-05-01 11:10, Dmitry Baryshkov wrote:
> > Move iommu_domain_alloc() in front of adress space/IOMMU initialization.
> > This allows us to drop final bits of struct mdp5_cfg_platform which
> > remained from the pre-DT days.
> >
> > Signed-o
Am Montag, dem 02.05.2022 um 10:29 -0700 schrieb Rob Clark:
> From: Rob Clark
>
> Running the GPU without an IOMMU is not really a supported (or sane)
> configuration. Yet it can be useful during SoC bringup (ie. if the
> iommu driver doesn't work yet).
>
> Lets limit it to users who already ha
On 2022-05-01 11:10, Dmitry Baryshkov wrote:
Move iommu_domain_alloc() in front of adress space/IOMMU initialization.
This allows us to drop final bits of struct mdp5_cfg_platform which
remained from the pre-DT days.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
21 matches
Mail list logo
