Quoting Stephen Boyd (2023-11-07 14:50:18)
> Quoting Dmitry Baryshkov (2023-11-06 18:00:04)
> > On Tue, 7 Nov 2023 at 03:36, Stephen Boyd wrote:
> > >
> > > Quoting Stephen Boyd (2023-11-03 18:24:47)
> > >
> > > I looked at this more today. It seems that I need to both read the
> > > config regist
On 11/6/2023 9:35 AM, Jessica Zhang wrote:
On 11/4/2023 6:02 AM, Helen Koike wrote:
Hi Jessica,
On 10/10/2023 19:25, Jessica Zhang wrote:
Recently, we've registered a Gitlab runner for a Qualcomm RB5 device
that will be
hosted and maintained in Qualcomm labs.
This series will add a corr
Quoting Dmitry Baryshkov (2023-11-06 18:00:04)
> On Tue, 7 Nov 2023 at 03:36, Stephen Boyd wrote:
> >
> > Quoting Stephen Boyd (2023-11-03 18:24:47)
> >
> > I looked at this more today. It seems that I need to both read the
> > config register at init and also move over the rcg to the safe source
On 11/6/23 16:45, Neil Armstrong wrote:
Hi,
On 28/09/2023 13:35, Dmitry Baryshkov wrote:
From: Konrad Dybcio
Apart from the already handled data bus (MAS_MDP_Pn<->DDR), there are
other connection paths:
- a path that connects rotator block to the DDR.
- a path that needs to be handled to e
On Tue, 7 Nov 2023 at 23:01, Kuogee Hsieh wrote:
>
>
> On 11/6/2023 5:55 PM, Dmitry Baryshkov wrote:
> > On Sat, 7 Oct 2023 at 01:55, Kuogee Hsieh wrote:
> >> The purpose of this patch series is to incorporate pm runtime framework
> >> into MSM eDP/DP driver so that eDP panel can be detected by D
On 11/6/2023 5:55 PM, Dmitry Baryshkov wrote:
On Sat, 7 Oct 2023 at 01:55, Kuogee Hsieh wrote:
The purpose of this patch series is to incorporate pm runtime framework
into MSM eDP/DP driver so that eDP panel can be detected by DRM eDP panel
driver during system probe time. During incorporatin
On 11/7/2023 3:14 AM, Dmitry Baryshkov wrote:
It seems during rebases I have left a call to drm_kms_helper_poll_init()
which is not guarded by the (priv->kms_init) check. This leads to the
crash for the boards which don't have KMS output. Drop this call, as
there is a correctly guarded one nex
On Tue, Nov 07, 2023 at 01:18:14PM +0100, Maxime Ripard wrote:
> On Tue, Nov 07, 2023 at 12:22:21PM +0100, Greg Kroah-Hartman wrote:
> > On Tue, Nov 07, 2023 at 11:57:49AM +0100, Maxime Ripard wrote:
> > > +GKH
> >
> > Why? I don't see a question for me here, sorry.
>
> I guess the question is:
From: Jani Nikula
[ Upstream commit a251c9d8e30833b260101edb9383b176ee2b7cb1 ]
The DP CTS test for EDID last block checksum expects the checksum for
the last block, invalid or not. Skip the validity check.
For the most part (*), the EDIDs returned by drm_get_edid() will be
valid anyway, and the
From: Jani Nikula
[ Upstream commit a251c9d8e30833b260101edb9383b176ee2b7cb1 ]
The DP CTS test for EDID last block checksum expects the checksum for
the last block, invalid or not. Skip the validity check.
For the most part (*), the EDIDs returned by drm_get_edid() will be
valid anyway, and the
From: Jani Nikula
[ Upstream commit a251c9d8e30833b260101edb9383b176ee2b7cb1 ]
The DP CTS test for EDID last block checksum expects the checksum for
the last block, invalid or not. Skip the validity check.
For the most part (*), the EDIDs returned by drm_get_edid() will be
valid anyway, and the
From: Jani Nikula
[ Upstream commit a251c9d8e30833b260101edb9383b176ee2b7cb1 ]
The DP CTS test for EDID last block checksum expects the checksum for
the last block, invalid or not. Skip the validity check.
For the most part (*), the EDIDs returned by drm_get_edid() will be
valid anyway, and the
From: Jani Nikula
[ Upstream commit a251c9d8e30833b260101edb9383b176ee2b7cb1 ]
The DP CTS test for EDID last block checksum expects the checksum for
the last block, invalid or not. Skip the validity check.
For the most part (*), the EDIDs returned by drm_get_edid() will be
valid anyway, and the
On Tue, Nov 07, 2023 at 12:22:21PM +0100, Greg Kroah-Hartman wrote:
> On Tue, Nov 07, 2023 at 11:57:49AM +0100, Maxime Ripard wrote:
> > +GKH
>
> Why? I don't see a question for me here, sorry.
I guess the question is: we have a bus with various power states
(powered off, low power, high speed)
On Tue, Nov 07, 2023 at 11:57:49AM +0100, Maxime Ripard wrote:
> +GKH
Why? I don't see a question for me here, sorry.
greg k-h
It seems during rebases I have left a call to drm_kms_helper_poll_init()
which is not guarded by the (priv->kms_init) check. This leads to the
crash for the boards which don't have KMS output. Drop this call, as
there is a correctly guarded one next to the one being removed.
Fixes: 506efcba3129 ("
+GKH
On Thu, Oct 26, 2023 at 11:41:34AM +0300, Dmitry Baryshkov wrote:
> > > > Also, we would still need to update every single panel driver, which is
> > > > going to create a lot of boilerplate that people might get wrong.
> > >
> > > Yes, quite unfortunately. Another approach that I have in min
Document the DisplayPort controller node in MDSS binding, already used
in DTS:
sm8250-xiaomi-elish-boe.dtb: display-subsystem@ae0: Unevaluated
properties are not allowed ('displayport-controller@ae9' was unexpected)
Signed-off-by: Krzysztof Kozlowski
---
.../bindings/display/msm/qcom
Hello members,
I'm Forcha Pearl, a final-year Computer Science postgraduate.
I'm good at Python, C++,C and JavaScript languages and have completed a few
projects,
excited to explore open source by contributing and learning.
Could anyone kindly assist me in making my initial contribution to X.ORG
f
19 matches
Mail list logo