Instead of allocating snapshotting structure at the driver probe time
and later handling concurrent access, actual state, etc, make
msm_disp_state transient struct. Allocate one when snapshotting happens
and free it after coredump data is read by userspace.
Signed-off-by: Dmitry Baryshkov
---
Instead of looping throught the resources each time to get the DSI CTRL
area size, get it at the ioremap time.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/dsi_host.c | 5 +++--
drivers/gpu/drm/msm/msm_drv.c | 27 +--
drivers/gpu/drm/msm/msm_drv.h
Add DSI PHY registers to the msm state snapshots to be able to check
their contents.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/dsi.c | 1 +
drivers/gpu/drm/msm/dsi/dsi.h | 1 +
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 31 +++
Instead of always getting the disp_state from drm device, pass it as an
argument.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 5 +
drivers/gpu/drm/msm/disp/msm_disp_snapshot.h| 8
Rework MSM coredump support: add DSI PHY registers, simplify
snapshotting code.
Changes since v1:
- Readd mutex serializing register snapshot calls
- Add DSI PHY register dumping support
Dmitry Baryshkov (4):
drm/msm: pass
From: Rob Clark
Our initial logic for excluding dma-bufs was not quite right. In
particular we want msm_gem_get/put_pages() path used for exported
dma-bufs to increment/decrement the pin-count.
Also, in case the importer is vmap'ing the dma-buf, we need to be
sure to update the object's
On 2021-04-26 15:14, Dmitry Baryshkov wrote:
On Tue, 27 Apr 2021 at 01:03, wrote:
On 2021-04-26 14:23, Dmitry Baryshkov wrote:
> On 26/04/2021 23:50, abhin...@codeaurora.org wrote:
>> On 2021-04-25 09:08, Dmitry Baryshkov wrote:
>>> Instead of allocating snapshotting structure at the driver
On Tue, 27 Apr 2021 at 01:03, wrote:
>
> On 2021-04-26 14:23, Dmitry Baryshkov wrote:
> > On 26/04/2021 23:50, abhin...@codeaurora.org wrote:
> >> On 2021-04-25 09:08, Dmitry Baryshkov wrote:
> >>> Instead of allocating snapshotting structure at the driver probe time
> >>> and later handling
On 2021-04-26 14:23, Dmitry Baryshkov wrote:
On 26/04/2021 23:50, abhin...@codeaurora.org wrote:
On 2021-04-25 09:08, Dmitry Baryshkov wrote:
Instead of allocating snapshotting structure at the driver probe time
and later handling concurrent access, actual state, etc, make
msm_disp_state
On 26/04/2021 23:50, abhin...@codeaurora.org wrote:
On 2021-04-25 09:08, Dmitry Baryshkov wrote:
Instead of allocating snapshotting structure at the driver probe time
and later handling concurrent access, actual state, etc, make
msm_disp_state transient struct. Allocate one when snapshotting
On Mon, 26 Apr 2021 11:29:15 +0530, Rajeev Nandan wrote:
> Add bindings for DisplayPort aux backlight driver.
>
> Changes in v2:
> - New
>
> Signed-off-by: Rajeev Nandan
> ---
> .../bindings/leds/backlight/dp-aux-backlight.yaml | 49
> ++
> 1 file changed, 49
On 2021-04-25 09:08, Dmitry Baryshkov wrote:
Instead of allocating snapshotting structure at the driver probe time
and later handling concurrent access, actual state, etc, make
msm_disp_state transient struct. Allocate one when snapshotting happens
and free it after coredump data is read by
On 2021-04-25 09:07, Dmitry Baryshkov wrote:
Instead of always getting the disp_state from drm device, pass it as an
argument.
Signed-off-by: Dmitry Baryshkov
This certainly reduces some amount of code, I am onboard with this,
hence:
Reviewed-by: Abhinav Kumar
---
On 26-04-2021 15:19, Jani Nikula wrote:
On Mon, 26 Apr 2021, Rajeev Nandan wrote:
Add backlight driver for the panels supporting backlight control
using DPCD registers on the DisplayPort aux channel.
No, please don't do this.
I wrote you last week in reply to v1 why I thought merging this
On Sat, Apr 24, 2021 at 03:25:04AM +0530, Rajeev Nandan wrote:
> Add backlight driver for the panels supporting backlight control
> using DPCD registers on the DisplayPort aux channel.
>
> Changes in v2:
> - New (most of the code reused from drm_dp_aux_backlight.c of v1)
Did you respond to
On Mon, 26 Apr 2021, Rajeev Nandan wrote:
> Add backlight driver for the panels supporting backlight control
> using DPCD registers on the DisplayPort aux channel.
No, please don't do this.
I wrote you last week in reply to v1 why I thought merging this would
not be a good idea [1]. Why have
Add backlight driver for the panels supporting backlight control
using DPCD registers on the DisplayPort aux channel.
Changes in v2:
- New (most of the code reused from drm_dp_aux_backlight.c of v1)
Changes in v3:
- Add missing ';' to fix module compilation (kernel test bot)
Signed-off-by:
Add bindings for DisplayPort aux backlight driver.
Changes in v2:
- New
Signed-off-by: Rajeev Nandan
---
.../bindings/leds/backlight/dp-aux-backlight.yaml | 49 ++
1 file changed, 49 insertions(+)
create mode 100644
The backlight level of an eDP panel can be controlled through the AUX
channel using DPCD registers of the panel.
The capability for the Source device to adjust backlight characteristics
within the panel, using the Sink device DPCD registers is indicated by
the TCON_BACKLIGHT_ADJUSTMENT_CAPABLE
19 matches
Mail list logo
