On Wed, May 11, 2022 at 06:33:32AM -0700, Rob Clark wrote:
>
> And ofc we want the expectations to be in the kernel tree because
> there could be, for example, differences between -fixes and -next
> branches. (Or even stable kernel branches if/when we get to the point
> of running CI on those.)
Quoting Dmitry Baryshkov (2022-05-11 18:30:55)
> On 12/05/2022 04:29, Stephen Boyd wrote:
> > Quoting Dmitry Baryshkov (2022-05-11 18:01:31)
> >> On Thu, 12 May 2022 at 03:54, Stephen Boyd wrote:
> >>>
> >>> Quoting Dmitry Baryshkov (2022-05-06 18:00:20)
> >>>
> >>> Does this supersede commit 0101
On 12/05/2022 04:29, Stephen Boyd wrote:
Quoting Dmitry Baryshkov (2022-05-11 18:01:31)
On Thu, 12 May 2022 at 03:54, Stephen Boyd wrote:
Quoting Dmitry Baryshkov (2022-05-06 18:00:20)
Does this supersede commit 01013ba9bbdd ("drm/msm/disp/dpu1: avoid
clearing hw interrupts if hw_intr is nul
Quoting Dmitry Baryshkov (2022-05-11 18:01:31)
> On Thu, 12 May 2022 at 03:54, Stephen Boyd wrote:
> >
> > Quoting Dmitry Baryshkov (2022-05-06 18:00:20)
> >
> > Does this supersede commit 01013ba9bbdd ("drm/msm/disp/dpu1: avoid
> > clearing hw interrupts if hw_intr is null during drm uninit")? I
On Thu, 12 May 2022 at 04:01, Stephen Boyd wrote:
>
> Quoting Dmitry Baryshkov (2022-05-11 17:41:50)
> > On 12/05/2022 03:02, Kuogee Hsieh wrote:
> > > diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c
> > > b/drivers/gpu/drm/msm/dp/dp_ctrl.c
> > > index af7a80c..f3e333e 100644
> > > --- a/drivers/gp
On Thu, 12 May 2022 at 03:54, Stephen Boyd wrote:
>
> Quoting Dmitry Baryshkov (2022-05-06 18:00:20)
> > As msm_drm_uninit() is called from the msm_drm_init() error path,
> > additional care should be necessary as not to call the free_irq() for
> > the IRQ that was not requested before (because an
Quoting Dmitry Baryshkov (2022-05-11 17:41:50)
> On 12/05/2022 03:02, Kuogee Hsieh wrote:
> > diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c
> > b/drivers/gpu/drm/msm/dp/dp_ctrl.c
> > index af7a80c..f3e333e 100644
> > --- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
> > +++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
Quoting Dmitry Baryshkov (2022-05-06 18:00:20)
> As msm_drm_uninit() is called from the msm_drm_init() error path,
> additional care should be necessary as not to call the free_irq() for
> the IRQ that was not requested before (because an error occured earlier
> than the request_irq() call).
>
> Th
Quoting Dmitry Baryshkov (2022-05-07 04:40:09)
> There is no need to check that kfree() argument is not NULL. Remove
> extra check and call kfree() unconditionally.
>
> Reported-by: kernel test robot
> Signed-off-by: Dmitry Baryshkov
> ---
Reviewed-by: Stephen Boyd
On 12/05/2022 03:02, Kuogee Hsieh wrote:
dp_catalog_ctrl_reset() will software reset DP controller. But it will
not reset programmable registers to default value. DP driver still have
to clear mask bits to interrupt status registers to disable interrupts
after software reset of controller.
At cu
dp_catalog_ctrl_reset() will software reset DP controller. But it will
not reset programmable registers to default value. DP driver still have
to clear mask bits to interrupt status registers to disable interrupts
after software reset of controller.
At current implementation, dp_ctrl_reset_irq_ctr
Quoting Abhinav Kumar (2022-05-11 15:27:10)
> DRM_MODE_ROTATE_180 was previously marked as supported even
> for devices not supporting inline rotation.
>
> This is true because the SSPPs can always flip the image.
>
> After inline rotation support changes, this bit was removed
> and kms_rotation_cr
On 12/05/2022 01:27, Abhinav Kumar wrote:
DRM_MODE_ROTATE_180 was previously marked as supported even
for devices not supporting inline rotation.
This is true because the SSPPs can always flip the image.
After inline rotation support changes, this bit was removed
and kms_rotation_crc IGT test s
On 12/05/2022 01:07, Rob Clark wrote:
On Wed, May 11, 2022 at 2:49 PM Dmitry Baryshkov
wrote:
On 11/05/2022 23:06, Doug Anderson wrote:
Hi,
On Tue, Dec 7, 2021 at 2:29 PM Dmitry Baryshkov
wrote:
The DSI subsystem does not fully fall into the pre-enable/enable system
of callbacks, since ty
On 12/05/2022 02:15, Douglas Anderson wrote:
This reverts commit 7d8e9a90509f1bd1d193a0c93cb8d1dbad9049fb.
The patch causes sc7180 Chromebooks that use the parade-ps8640 bridge
chip to fail to turn the display back on after it turns off.
Let's revert to get these devices back to a working state
On 5/11/2022 2:47 PM, Dmitry Baryshkov wrote:
On 12/05/2022 00:40, Kuogee Hsieh wrote:
dp_catalog_ctrl_reset() will software reset DP controller. But it will
not reset programmable registers to default value. DP driver still have
to clear mask bits to interrupt status registers to disable inte
Hi,
On Wed, May 11, 2022 at 4:07 PM Douglas Anderson wrote:
>
> This reverts commit c7e4a2a72e696aa6aed2c8b651279f491bb096fe.
>
> The patch causes sc7180 Chromebooks that use the parade-ps8640 bridge
> chip to fail to turn the display back on after it turns off.
>
> Let's revert to get these devi
This reverts commit 7d8e9a90509f1bd1d193a0c93cb8d1dbad9049fb.
The patch causes sc7180 Chromebooks that use the parade-ps8640 bridge
chip to fail to turn the display back on after it turns off.
Let's revert to get these devices back to a working state. It seems
like the DSI powerup problem is some
This reverts commit c7e4a2a72e696aa6aed2c8b651279f491bb096fe.
The patch causes sc7180 Chromebooks that use the parade-ps8640 bridge
chip to fail to turn the display back on after it turns off.
Let's revert to get these devices back to a working state. It seems
like the DSI powerup problem is some
As per Displayport spec section 5.2.1.2 ("Video Timing Format") says
that all detachable sinks shall support 640x480 @60Hz as a fail safe
mode.
A DP compliance test expected us to utilize the above fact when all
modes it presented to the DP source were not achievable. It presented
only modes that
The drm_helper_probe_single_connector_modes() is a bit long. Let's
break a chunk off to update and validate modes. This helps avoid one
goto and also will allow us to more easily call the helper a second
time in a future patch without adding looping or another goto.
This change is intended to be a
On 5/11/2022 3:27 PM, Abhinav Kumar wrote:
DRM_MODE_ROTATE_180 was previously marked as supported even
for devices not supporting inline rotation.
This is true because the SSPPs can always flip the image.
After inline rotation support changes, this bit was removed
and kms_rotation_crc IGT te
DRM_MODE_ROTATE_180 was previously marked as supported even
for devices not supporting inline rotation.
This is true because the SSPPs can always flip the image.
After inline rotation support changes, this bit was removed
and kms_rotation_crc IGT test starts skipping now whereas
it was previously
On Wed, May 11, 2022 at 2:49 PM Dmitry Baryshkov
wrote:
>
> On 11/05/2022 23:06, Doug Anderson wrote:
> > Hi,
> >
> > On Tue, Dec 7, 2021 at 2:29 PM Dmitry Baryshkov
> > wrote:
> >>
> >> The DSI subsystem does not fully fall into the pre-enable/enable system
> >> of callbacks, since typically DSI
On 11/05/2022 23:06, Doug Anderson wrote:
Hi,
On Tue, Dec 7, 2021 at 2:29 PM Dmitry Baryshkov
wrote:
The DSI subsystem does not fully fall into the pre-enable/enable system
of callbacks, since typically DSI device bridge drivers expect to be
able to communicate with DSI devices at the pre-ena
On 12/05/2022 00:40, Kuogee Hsieh wrote:
dp_catalog_ctrl_reset() will software reset DP controller. But it will
not reset programmable registers to default value. DP driver still have
to clear mask bits to interrupt status registers to disable interrupts
after software reset of controller. This p
dp_catalog_ctrl_reset() will software reset DP controller. But it will
not reset programmable registers to default value. DP driver still have
to clear mask bits to interrupt status registers to disable interrupts
after software reset of controller. This patch removes the enable flag
condition chec
Hi,
On Wed, May 11, 2022 at 12:14 AM Thomas Zimmermann wrote:
>
> Hi
>
> Am 10.05.22 um 22:51 schrieb Douglas Anderson:
> > If we're unable to read the EDID for a display because it's corrupt /
> > bogus / invalid then we'll add a set of standard modes for the
> > display. When userspace looks at
On 11/05/2022 23:04, Kuogee Hsieh wrote:
dp_catalog_ctrl_reset() will software reset DP controller. But it will
not reset programmable registers to default value. DP driver still have
to clear mask bits to interrupt status registers to disable interrupts
after software reset of controller. This p
On Wed, 11 May 2022 at 22:32, Rob Clark wrote:
>
> On Wed, May 11, 2022 at 12:14 PM Daniel Vetter wrote:
> >
> > On Wed, 11 May 2022 at 19:46, Rob Clark wrote:
> > >
> > > On Wed, May 11, 2022 at 10:12 AM Daniel Vetter wrote:
> > > >
> > > > On Tue, 10 May 2022 at 22:26, Rob Clark wrote:
> > >
On Wed, May 11, 2022 at 12:14 PM Daniel Vetter wrote:
>
> On Wed, 11 May 2022 at 19:46, Rob Clark wrote:
> >
> > On Wed, May 11, 2022 at 10:12 AM Daniel Vetter wrote:
> > >
> > > On Tue, 10 May 2022 at 22:26, Rob Clark wrote:
> > > >
> > > > On Tue, May 10, 2022 at 12:39 PM Jessica Zhang
> > >
On Wed, May 11, 2022 at 12:12 PM Linus Torvalds
wrote:
>
> On Wed, May 11, 2022 at 12:08 PM Linus Torvalds
> wrote:
> >
> > The kernel tree might have just the expected *failures* listed, if
> > there are any. Presumably the ci tree has to have the expected results
> > anyway, so what's the advan
On Wed, May 11, 2022 at 12:08 PM Linus Torvalds
wrote:
>
> On Wed, May 11, 2022 at 11:40 AM Rob Clark wrote:
> >
> > It is missing in this revision of the RFC, but the intention is to
> > have the gitlab-ci.yml point to a specific commit SHA in the
> > gfx-ci/drm-ci[1] tree, to solve the problem
Hi,
On Tue, Dec 7, 2021 at 2:29 PM Dmitry Baryshkov
wrote:
>
> The DSI subsystem does not fully fall into the pre-enable/enable system
> of callbacks, since typically DSI device bridge drivers expect to be
> able to communicate with DSI devices at the pre-enable() callback. The
> reason is that f
dp_catalog_ctrl_reset() will software reset DP controller. But it will
not reset programmable registers to default value. DP driver still have
to clear mask bits to interrupt status registers to disable interrupts
after software reset of controller. This patch removes the enable flag
condition chec
On Wed, May 11, 2022 at 10:33:06AM -0700, Linus Torvalds wrote:
> On Tue, May 10, 2022 at 10:07 PM Dave Airlie wrote:
> >
> > > And use it to store expectations about what the drm/msm driver is
> > > supposed to pass in the IGT test suite.
> >
> > I wanted to loop in Linus/Greg to see if there are
On Wed, May 11, 2022 at 11:40 AM Rob Clark wrote:
>
> It is missing in this revision of the RFC, but the intention is to
> have the gitlab-ci.yml point to a specific commit SHA in the
> gfx-ci/drm-ci[1] tree, to solve the problem of keeping the results in
> sync with the expectations. Ie. a kerne
On Wed, 11 May 2022 at 19:46, Rob Clark wrote:
>
> On Wed, May 11, 2022 at 10:12 AM Daniel Vetter wrote:
> >
> > On Tue, 10 May 2022 at 22:26, Rob Clark wrote:
> > >
> > > On Tue, May 10, 2022 at 12:39 PM Jessica Zhang
> > > wrote:
> > > >
> > > >
> > > >
> > > > On 5/10/2022 7:13 AM, Tomeu Viz
On Wed, May 11, 2022 at 12:08 PM Linus Torvalds
wrote:
>
> The kernel tree might have just the expected *failures* listed, if
> there are any. Presumably the ci tree has to have the expected results
> anyway, so what's the advantage of listing non-failures?
.. put another way: I think a list of "
On 11/04/2022 23:47, Sean Paul wrote:
From: Sean Paul
This patch adds HDCP 1.x support to msm DP connectors using the new HDCP
helpers.
As a note, msm drm driver already supports HDCP on the HDMI interface.
Can it also be converted to use new helpers?
Cc: Stephen Boyd
Cc: Abhinav Kumar
On Wed, May 11, 2022 at 10:33 AM Linus Torvalds
wrote:
>
> On Tue, May 10, 2022 at 10:07 PM Dave Airlie wrote:
> >
> > > And use it to store expectations about what the drm/msm driver is
> > > supposed to pass in the IGT test suite.
> >
> > I wanted to loop in Linus/Greg to see if there are any i
Hi,
On Fri, May 6, 2022 at 6:36 AM Sankeerth Billakanti (QUIC)
wrote:
>
> >> >> Our internal power grid documents list the regulators as
> >> >> VDD_A_*_1P2 and VDD_A_*_0P9 for all the platforms.
> >> >
> >> >Do your internal power grid documents indicate what these supplies
> >> >are powering? T
On Tue, May 10, 2022 at 10:07 PM Dave Airlie wrote:
>
> > And use it to store expectations about what the drm/msm driver is
> > supposed to pass in the IGT test suite.
>
> I wanted to loop in Linus/Greg to see if there are any issues raised
> by adding CI results file to the tree in their minds, o
On Wed, May 11, 2022 at 10:12 AM Daniel Vetter wrote:
>
> On Tue, 10 May 2022 at 22:26, Rob Clark wrote:
> >
> > On Tue, May 10, 2022 at 12:39 PM Jessica Zhang
> > wrote:
> > >
> > >
> > >
> > > On 5/10/2022 7:13 AM, Tomeu Vizoso wrote:
> > > > And use it to store expectations about what the drm
On Wed, May 11, 2022 at 9:43 AM Daniel Vetter wrote:
>
> On Wed, 11 May 2022 at 15:33, Rob Clark wrote:
> > On Wed, May 11, 2022 at 4:50 AM Greg Kroah-Hartman
> > wrote:
> > >
> > > On Wed, May 11, 2022 at 12:26:05PM +0200, Michel Dänzer wrote:
> > > > On 2022-05-11 08:22, Greg Kroah-Hartman wro
On Tue, 10 May 2022 at 22:26, Rob Clark wrote:
>
> On Tue, May 10, 2022 at 12:39 PM Jessica Zhang
> wrote:
> >
> >
> >
> > On 5/10/2022 7:13 AM, Tomeu Vizoso wrote:
> > > And use it to store expectations about what the drm/msm driver is
> > > supposed to pass in the IGT test suite.
> > >
> > > Al
On Wed, 11 May 2022 at 15:33, Rob Clark wrote:
> On Wed, May 11, 2022 at 4:50 AM Greg Kroah-Hartman
> wrote:
> >
> > On Wed, May 11, 2022 at 12:26:05PM +0200, Michel Dänzer wrote:
> > > On 2022-05-11 08:22, Greg Kroah-Hartman wrote:
> > > > On Wed, May 11, 2022 at 03:06:47PM +1000, Dave Airlie wr
On Wed, May 11, 2022 at 7:26 AM Jani Nikula wrote:
>
> On Tue, 10 May 2022, Tomeu Vizoso wrote:
> > And use it to store expectations about what the drm/msm driver is
> > supposed to pass in the IGT test suite.
> >
> > Also include a configuration file that points to the out-of-tree CI
> > scripts
On Tue, 10 May 2022, Tomeu Vizoso wrote:
> And use it to store expectations about what the drm/msm driver is
> supposed to pass in the IGT test suite.
>
> Also include a configuration file that points to the out-of-tree CI
> scripts.
>
> By storing the test expectations along the code we can make
On 5/11/22 3:20 PM, Rob Clark wrote:
On Tue, May 10, 2022 at 11:15 PM Tomeu Vizoso
wrote:
And use it to store expectations about what the drm/msm driver is
supposed to pass in the IGT test suite.
Also include a configuration file that points to the out-of-tree CI
scripts.
By storing the test
On Wed, May 11, 2022 at 4:50 AM Greg Kroah-Hartman
wrote:
>
> On Wed, May 11, 2022 at 12:26:05PM +0200, Michel Dänzer wrote:
> > On 2022-05-11 08:22, Greg Kroah-Hartman wrote:
> > > On Wed, May 11, 2022 at 03:06:47PM +1000, Dave Airlie wrote:
> > >>> And use it to store expectations about what the
On Tue, May 10, 2022 at 11:15 PM Tomeu Vizoso
wrote:
>
> And use it to store expectations about what the drm/msm driver is
> supposed to pass in the IGT test suite.
>
> Also include a configuration file that points to the out-of-tree CI
> scripts.
>
> By storing the test expectations along the cod
On Wed, May 11, 2022 at 12:26:05PM +0200, Michel Dänzer wrote:
> On 2022-05-11 08:22, Greg Kroah-Hartman wrote:
> > On Wed, May 11, 2022 at 03:06:47PM +1000, Dave Airlie wrote:
> >>> And use it to store expectations about what the drm/msm driver is
> >>> supposed to pass in the IGT test suite.
> >>
Hi
Am 10.05.22 um 22:13 schrieb Douglas Anderson:
The drm_helper_probe_single_connector_modes() is a bit long. Let's
break a chunk off to update and validate modes. This helps avoid one
goto and also will allow us to more easily call the helper a second
time in a future patch without adding loop
Hi
Am 10.05.22 um 22:51 schrieb Douglas Anderson:
If we're unable to read the EDID for a display because it's corrupt /
bogus / invalid then we'll add a set of standard modes for the
display. When userspace looks at these modes it doesn't really have a
good concept for which mode to pick and it'
55 matches
Mail list logo
