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 make sure event thread exit its loop
On Mon 02 May 15:49 PDT 2022, Kuogee Hsieh wrote:
>
> On 5/2/2022 3:29 PM, Bjorn Andersson wrote:
> > On Mon 02 May 13:59 PDT 2022, Kuogee Hsieh wrote:
> >
> > > On 5/2/2022 9:53 AM, Bjorn Andersson wrote:
> > > > The Qualcomm DisplayPort driver contains traces of the necessary
> > > > plumbing
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 Mon 02 May 15:29 PDT 2022, Bjorn Andersson wrote:
> On Mon 02 May 13:59 PDT 2022, Kuogee Hsieh wrote:
>
> >
> > On 5/2/2022 9:53 AM, Bjorn Andersson wrote:
> > > The Qualcomm DisplayPort driver contains traces of the necessary
> > > plumbing to hook up USB HPD, in the form of the dp_hpd modul
On 5/2/2022 3:29 PM, Bjorn Andersson wrote:
On Mon 02 May 13:59 PDT 2022, Kuogee Hsieh wrote:
On 5/2/2022 9:53 AM, Bjorn Andersson wrote:
The Qualcomm DisplayPort driver contains traces of the necessary
plumbing to hook up USB HPD, in the form of the dp_hpd module and the
dp_usbpd_cb struct.
On Mon 02 May 13:59 PDT 2022, Kuogee Hsieh wrote:
>
> On 5/2/2022 9:53 AM, Bjorn Andersson wrote:
> > The Qualcomm DisplayPort driver contains traces of the necessary
> > plumbing to hook up USB HPD, in the form of the dp_hpd module and the
> > dp_usbpd_cb struct. Use this as basis for implementi
On 03/05/2022 00:42, Marijn Suijten wrote:
On 2022-05-02 13:47:51, Stephen Boyd wrote:
Quoting Dmitry Baryshkov (2022-05-01 12:56:20)
Remove dividers that are not recommended for DSI DPHY mode when setting
Is "DPHY" intentional or just "PHY" should be here?
up the clock tree for the DSI pix
On 2022-05-02 13:02:09, Dmitry Baryshkov wrote:
> [snip]
> > How would you represent this in XML? I was hoping for a method that
> > allows to construct the value in a generic way, without register names,
> > and then simply have a "register macro" that moves (and perhaps masks)
> > the preconstru
On 2022-05-02 12:41:37, Dmitry Baryshkov wrote:
> On 02/05/2022 11:43, Marijn Suijten wrote:
> > On 2022-05-02 01:44:20, Dmitry Baryshkov wrote:
> >> [sni[
> >>> In any case, given that you've already sent this patch and another three
> >>> patches [2] fixing/cleaning up the series tells me it's fa
On 5/2/2022 2:50 PM, Kuogee Hsieh wrote:
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
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 2022-05-02 13:47:51, Stephen Boyd wrote:
> Quoting Dmitry Baryshkov (2022-05-01 12:56:20)
> > Remove dividers that are not recommended for DSI DPHY mode when setting
>
> Is "DPHY" intentional or just "PHY" should be here?
>
> > up the clock tree for the DSI pixel clock.
> >
> > Signed-off-by:
On 5/2/2022 9:53 AM, Bjorn Andersson wrote:
The Qualcomm DisplayPort driver contains traces of the necessary
plumbing to hook up USB HPD, in the form of the dp_hpd module and the
dp_usbpd_cb struct. Use this as basis for implementing the
hpd_notify() callback, by amending the dp_hpd module with
On 5/2/2022 1:45 PM, Stephen Boyd wrote:
Quoting Abhinav Kumar (2022-05-01 22:39:41)
Add missing break statement for dpu_hw_ctl_update_pending_flush_wb().
Otherwise this leads to below build warning.
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c:273:2:
warning: unannotated fall-through between
Quoting Dmitry Baryshkov (2022-05-01 12:56:20)
> Remove dividers that are not recommended for DSI DPHY mode when setting
Is "DPHY" intentional or just "PHY" should be here?
> up the clock tree for the DSI pixel clock.
>
> Signed-off-by: Dmitry Baryshkov
> ---
Reviewed-by: Stephen Boyd
> driv
Quoting Abhinav Kumar (2022-05-01 22:39:41)
> Add missing break statement for dpu_hw_ctl_update_pending_flush_wb().
> Otherwise this leads to below build warning.
>
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c:273:2:
> warning: unannotated fall-through between switch labels
>default:
>
Quoting Vinod Polimera (2022-05-02 09:44:06)
> If edp modeset init is failed due to panel being not ready and
> probe defers during drm bind, avoid clearing irqs and derefernce
s/derefernce/dereference/
> hw_intr when hw_intr is null.
>
> BUG: Unable to handle kernel NULL pointer dereference at v
Quoting Jessica Zhang (2022-04-29 17:52:10)
> Currently, dpu_hw_lm_collect_misr returns EINVAL if CRC is disabled.
> This causes a lot of spam in the DRM debug logs as it's called for every
> vblank.
>
> Instead of returning EINVAL when CRC is disabled in
> dpu_hw_lm_collect_misr, let's return ENOD
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 have /dev/mem access, to avoid the
chance that a user accidentially configur
On 02/05/2022 19:44, Vinod Polimera wrote:
If edp modeset init is failed due to panel being not ready and
probe defers during drm bind, avoid clearing irqs and derefernce
hw_intr when hw_intr is null.
BUG: Unable to handle kernel NULL pointer dereference at virtual address
Cal
The Qualcomm DisplayPort driver contains traces of the necessary
plumbing to hook up USB HPD, in the form of the dp_hpd module and the
dp_usbpd_cb struct. Use this as basis for implementing the
hpd_notify() callback, by amending the dp_hpd module with the
missing logic.
Overall the solution is sim
From: Dmitry Baryshkov
Remove most of remains of downstream usbpd code. Mainline kernel uses
different approach for managing Type-C / USB-PD, so this remains unused.
Do not touch usbpd callbacks for now, since they look useful enough as
an example of how to handle connect/disconnect (to be rewrit
From: Dmitry Baryshkov
Implement the oob_hotplug_event() callback. Translate it to the HPD
notification sent to the HPD bridge in the chain.
Signed-off-by: Dmitry Baryshkov
Signed-off-by: Bjorn Andersson
---
Changes since v3:
- New patch
drivers/gpu/drm/drm_bridge_connector.c | 12 +
In some implementations, such as the Qualcomm platforms, the display
driver has no way to query the current HPD state and as such it's
impossible to distinguish between disconnect and attention events.
Add a parameter to drm_connector_oob_hotplug_event() to pass the HPD
state.
Also push the test
USB altmodes code would send OOB notifications to the drm_connector
specified in the device tree. However as the MSM DP driver uses
drm_bridge_connector, there is no way to receive these event directly.
Implement a bridge between oob_hotplug_event and drm_bridge's hpd_notify
and use it to deliver a
From: Dmitry Baryshkov
In some cases the bridge drivers would like to receive hotplug events
even in the case new status is equal to the old status. In the DP case
this is used to deliver "attention" messages to the DP host. Stop
filtering the events in the drm_bridge_connector_hpd_cb() and let
d
If edp modeset init is failed due to panel being not ready and
probe defers during drm bind, avoid clearing irqs and derefernce
hw_intr when hw_intr is null.
BUG: Unable to handle kernel NULL pointer dereference at virtual address
Call trace:
dpu_core_irq_uninstall+0x50/0xb0
d
On 5/2/2022 1:24 AM, Dmitry Baryshkov wrote:
Move the initializer for the mode variable to the declaration point to
remove unitialized variable access from the DEBUG_DPU macro. This fixes
the following warning:
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c:250:37: note: initialize
the
On 5/2/2022 1:05 AM, Dmitry Baryshkov wrote:
On Mon, 2 May 2022 at 04:38, Abhinav Kumar wrote:
Looks like our new CI has given all the answers we need :) which is a
great win for the CI in my opinion.
Take a look at this report :
https://gitlab.freedesktop.org/drm/msm/-/jobs/22015361
This
On Tue, Apr 26, 2022 at 4:45 PM Dmitry Baryshkov
wrote:
>
> Hi linux-firmware maintainers,
>
> Please pull the firmware for several generation of Adreno GPU (A220, A330,
> A405/A420/A430).
>
> The firmware files come from Dragonboard 820c BSP available at [1] or directly
> from Qualcomm at [2] (re
On 02/05/2022 11:34, Marijn Suijten wrote:
On 2022-05-01 16:56:45, Abhinav Kumar wrote:
[snip]
Wouln't this macro already make sure that 'reg' doesnt have anything in
the top 16 bits? Its doing a & with 0x3f00
Like I said, it is unlikely that this happens, only if someone starts
changing t
On 02/05/2022 11:43, Marijn Suijten wrote:
On 2022-05-02 01:44:20, Dmitry Baryshkov wrote:
[sni[
In any case, given that you've already sent this patch and another three
patches [2] fixing/cleaning up the series tells me it's far from ready.
Most of this should just be handled - or have been ha
On 2022-05-02 01:44:20, Dmitry Baryshkov wrote:
> [sni[
> > In any case, given that you've already sent this patch and another three
> > patches [2] fixing/cleaning up the series tells me it's far from ready.
> > Most of this should just be handled - or have been handled - in review
> > and amended
On 2022-05-01 16:56:45, Abhinav Kumar wrote:
> [snip]
> Wouln't this macro already make sure that 'reg' doesnt have anything in
> the top 16 bits? Its doing a & with 0x3f00
Like I said, it is unlikely that this happens, only if someone starts
changing the code that assigns to `reg` which is u
Move the initializer for the mode variable to the declaration point to
remove unitialized variable access from the DEBUG_DPU macro. This fixes
the following warning:
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c:250:37: note: initialize
the variable 'mode' to silence this warning
Fixes: d7
On Mon, 2 May 2022 at 08:39, Abhinav Kumar wrote:
>
> Add missing break statement for dpu_hw_ctl_update_pending_flush_wb().
> Otherwise this leads to below build warning.
>
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c:273:2:
> warning: unannotated fall-through between switch labels
>de
On Mon, 2 May 2022 at 04:38, Abhinav Kumar wrote:
>
> Looks like our new CI has given all the answers we need :) which is a
> great win for the CI in my opinion.
>
> Take a look at this report :
> https://gitlab.freedesktop.org/drm/msm/-/jobs/22015361
>
> This issue seems to be because this change
On Mon, 2 May 2022 at 02:56, Abhinav Kumar wrote:
>
>
>
> On 5/1/2022 1:06 PM, Marijn Suijten wrote:
> > On 2022-04-30 12:25:57, Abhinav Kumar wrote:
> >>
> >>
> >> On 4/30/2022 11:58 AM, Marijn Suijten wrote:
> >>> On 2022-04-30 20:55:33, Dmitry Baryshkov wrote:
> The downstream uses read-mo
38 matches
Mail list logo
