On 2023-01-05 15:49:58, Daniel Vetter wrote:
> On Thu, Dec 22, 2022 at 12:19:35AM +0100, Marijn Suijten wrote:
> > [..]
>
> Please note that Electric Boogaloo/Boogaloo Boys has been appropriated by
> US alt-right groups, and so is really not a great thing to put into the
> cover letter for your
On 2023-01-09 07:01:49, Dmitry Baryshkov wrote:
> Convert the mdp5.txt into the yaml format. Changes to the existing (txt)
> schema:
> - MSM8996 has additional "iommu" clock, define it separately
> - Add new properties used on some of platforms:
>- interconnects, interconnect-names
>-
Hi Sam,
On Sun, 8 Jan 2023 21:29:43 +0100, Sam Ravnborg wrote:
> On Sun, Jan 08, 2023 at 08:28:17PM +0100, Stephen Kitt wrote:
> > On Sat, 07 Jan 2023 19:26:23 +0100, Sam Ravnborg via B4 Submission
> > Endpoint wrote:
> >
> > > From: Sam Ravnborg
> > >
> > > Avoiding direct access to
Describe the RBCPR clock used on msm8996 (A530), MSM8998 (A540) and
SDM630/660 (A508/A512).
Signed-off-by: Dmitry Baryshkov
---
Documentation/devicetree/bindings/display/msm/gpu.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/msm/gpu.yaml
Follow the schema change and rename mdss node to generic name
'display-subsystem'.
Signed-off-by: Dmitry Baryshkov
---
arch/arm/boot/dts/qcom-msm8974.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
Follow the schema change and rename mdp nodes to generic name
'display-controller'.
Signed-off-by: Dmitry Baryshkov
---
arch/arm/boot/dts/qcom-apq8064.dtsi | 2 +-
arch/arm/boot/dts/qcom-msm8974.dtsi | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git
Follow the 'generic names' rule and rename mdp nodes to
display-controller.
Signed-off-by: Dmitry Baryshkov
---
.../devicetree/bindings/display/msm/dpu-common.yaml | 8
.../devicetree/bindings/display/msm/qcom,mdp5.yaml| 3 +++
Follow the 'generic names' rule and rename mdss nodes to
display-subsystem.
Signed-off-by: Dmitry Baryshkov
---
.../devicetree/bindings/display/msm/mdss-common.yaml | 8
.../devicetree/bindings/display/msm/qcom,mdss.yaml| 5 -
2 files changed, 12 insertions(+), 1
Follow the schema change and rename mdp nodes to generic name
'display-controller'.
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/msm8916.dtsi | 2 +-
arch/arm64/boot/dts/qcom/msm8953.dtsi | 2 +-
arch/arm64/boot/dts/qcom/msm8996.dtsi | 2 +-
arch/arm64/boot/dts/qcom/sdm630.dtsi
Follow the schema change and rename mdss nodes to generic name
'display-subsystem'.
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/msm8916.dtsi | 2 +-
arch/arm64/boot/dts/qcom/msm8953.dtsi | 2 +-
arch/arm64/boot/dts/qcom/msm8996.dtsi | 2 +-
arch/arm64/boot/dts/qcom/sc7180.dtsi
Finish the process of renaming display-related nodes on Qualcomm
systems. Fix it in the schema that MDSS (Mobile Display SubSystem)
devices are named `display-subsystem' and both MDP (Mobile Display
Processor) and DPU (Display Processor Unit) nodes are named
`display-controller'.
Dmitry Baryshkov
Add SoC-specific compat string to the MDP5 device node to ease
distinguishing between various platforms.
Signed-off-by: Dmitry Baryshkov
---
arch/arm/boot/dts/qcom-msm8974.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
Add platform-specific compatible entries to the qcom,mdp5.yaml to allow
distinguishing between various platforms. For msm8998 list
qcom,msm8998-dpu rather than -mdp5 to allow this binding to be handled
by either of the drivers.
Signed-off-by: Dmitry Baryshkov
---
Add SoC-specific compat string to the MDP5 device nodes to ease
distinguishing between various platforms.
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/msm8916.dtsi | 2 +-
arch/arm64/boot/dts/qcom/msm8996.dtsi | 2 +-
arch/arm64/boot/dts/qcom/sdm630.dtsi | 2 +-
This patch concludes the conversion of display/msm schema from txt files
to YAML format.
The per-SoC compat (new addition) is required to ease migrating platform
support between mdp5 and dpu drivers.
Changes since v4:
- Adjust qcom,mdss.yaml to follow the addition of per-SoC compatibles
Changes
Convert the mdp5.txt into the yaml format. Changes to the existing (txt) schema:
- MSM8996 has additional "iommu" clock, define it separately
- Add new properties used on some of platforms:
- interconnects, interconnect-names
- iommus
- power-domains
- operating-points-v2, opp-table
Document the DP controller added to the sdm845 display subsystem.
Signed-off-by: Dmitry Baryshkov
---
.../devicetree/bindings/display/msm/qcom,sdm845-mdss.yaml | 6 ++
1 file changed, 6 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/msm/qcom,sdm845-mdss.yaml
On Qualcomm devices HDMI PHY node names were changed from hdmi-phy to
phy. Follow this change.
Signed-off-by: Dmitry Baryshkov
---
.../devicetree/bindings/display/msm/qcom,mdss.yaml | 6 --
1 file changed, 6 deletions(-)
diff --git
Yes. How to place Dept in here looks so ugly. But it's inevitable as
long as relying on Lockdep. The way should be enhanced gradually.
1. Basically relies on Lockdep to track typical locks and IRQ things.
2. Dept fails to recognize IRQ situation so it generates false alarms
when
Makes Dept able to track dependencies by PG_{locked,writeback} waits.
Signed-off-by: Byungchul Park
---
mm/filemap.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/mm/filemap.c b/mm/filemap.c
index c4d4ace..b013a5b 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -42,6 +42,7 @@
Now that CONFIG_DEPT_AGGRESSIVE_TIMEOUT_WAIT was introduced, apply the
consideration to waitqueue wait, assuming an input 'ret' in
___wait_event() macro is used as a timeout value.
Signed-off-by: Byungchul Park
---
include/linux/wait.h | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
Makes Dept able to track dma fence waits.
Signed-off-by: Byungchul Park
---
drivers/dma-buf/dma-fence.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 406b4e2..dd190cf 100644
--- a/drivers/dma-buf/dma-fence.c
+++
Now that CONFIG_DEPT_AGGRESSIVE_TIMEOUT_WAIT was introduced, apply the
consideration to wait_for_completion()/complete().
Signed-off-by: Byungchul Park
---
include/linux/completion.h | 21 +
1 file changed, 17 insertions(+), 4 deletions(-)
diff --git
Waits with valid timeouts don't actually cause deadlocks. However, Dept
has been reporting the cases as well because it's worth informing the
circular dependency for some cases where, for example, timeout is used
to avoid a deadlock but not meant to be expired.
However, yes, there are also a lot
Makes Dept able to track dependencies by
wait_for_completion()/complete().
In order to obtain the meaningful caller points, replace all the
wait_for_completion*() declarations with macros in the header.
Signed-off-by: Byungchul Park
---
include/linux/completion.h | 89
Workqueue already provides concurrency control. By that, any wait in a
work doesn't prevents events in other works with the control enabled.
Thus, each work would better be considered a different context.
So let Dept assign a different context id to each work.
Signed-off-by: Byungchul Park
---
Makes Dept able to track dependencies by hashed-waitqueue waits, but
weakly.
Signed-off-by: Byungchul Park
---
include/linux/wait_bit.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/linux/wait_bit.h b/include/linux/wait_bit.h
index 7725b75..bad30ba 100644
---
Makes Dept able to track dependencies by swaits, but weakly.
Signed-off-by: Byungchul Park
---
include/linux/swait.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/linux/swait.h b/include/linux/swait.h
index 6a8c22b..1304209 100644
--- a/include/linux/swait.h
+++
Wrapped the base APIs for easier annotation on typical lock.
Signed-off-by: Byungchul Park
---
include/linux/dept_ldt.h | 77
1 file changed, 77 insertions(+)
create mode 100644 include/linux/dept_ldt.h
diff --git a/include/linux/dept_ldt.h
Now that CONFIG_DEPT_AGGRESSIVE_TIMEOUT_WAIT was introduced, apply the
consideration to hashed-waitqueue wait, assuming an input 'ret' in
___wait_var_event() macro is used as a timeout value.
Signed-off-by: Byungchul Park
---
include/linux/wait_bit.h | 5 -
1 file changed, 4 insertions(+),
Wrapped the base APIs for easier annotation on wait and event. Start
with supporting waiters on each single event. More general support for
multiple events is a future work. Do more when the need arises.
How to annotate (the simplest way):
1. Initaialize a map for the interesting wait.
/*
cb92173d1f0 ("locking/lockdep, cpu/hotplug: Annotate AP thread") was
introduced to make lockdep_assert_cpus_held() work in AP thread.
However, the annotation is too strong for that purpose. We don't have to
use more than try lock annotation for that.
Furthermore, now that Dept was introduced,
Dept engine works in a constrained environment. For example, Dept cannot
make use of dynamic allocation e.g. kmalloc(). So Dept has been using
static pools to keep memory chunks Dept uses.
However, Dept would barely work once any of the pools gets run out. So
implemented a mechanism for the
Now that CONFIG_DEPT_AGGRESSIVE_TIMEOUT_WAIT was introduced, apply the
consideration to swait, assuming an input 'ret' in ___swait_event()
macro is used as a timeout value.
Signed-off-by: Byungchul Park
---
include/linux/swait.h | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff
Now that CONFIG_DEPT_AGGRESSIVE_TIMEOUT_WAIT was introduced, apply the
consideration to dma fence wait.
Signed-off-by: Byungchul Park
---
drivers/dma-buf/dma-fence.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/dma-buf/dma-fence.c
The current code records all the waits for later use to track relation
between waits and events in each context. However, since the same class
is handled the same way, it'd be okay to record only one on behalf of
the others if they all have the same class.
Even though it's the ideal to search the
It enters kernel mode on each syscall and each syscall handling should
be considered independently from the point of view of Dept. Otherwise,
Dept may wrongly track dependencies across different syscalls.
That might be a real dependency from user mode. However, now that Dept
just started to work,
CURRENT STATUS
--
Lockdep tracks acquisition order of locks in order to detect deadlock,
and IRQ and IRQ enable/disable state as well to take accident
acquisitions into account.
Lockdep should be turned off once it detects and reports a deadlock
since the data structure and algorithm
Makes Dept able to track dependencies by waitqueue waits, but weakly.
Signed-off-by: Byungchul Park
---
include/linux/wait.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/linux/wait.h b/include/linux/wait.h
index a0307b5..ede466c 100644
--- a/include/linux/wait.h
+++
It'd be useful to show Dept internal stats and dependency graph on
runtime via proc for better information. Introduced the knobs.
Signed-off-by: Byungchul Park
---
kernel/dependency/Makefile| 1 +
kernel/dependency/dept.c | 24 --
kernel/dependency/dept_internal.h | 26
Just for those who want to try the latest version of DEPT.
---
Hi Linus and folks,
I've been developing a tool for detecting deadlock possibilities by
tracking wait/event rather than lock(?) acquisition order to try to
cover all synchonization machanisms. It's done on v6.2-rc2.
llist_head and llist_node can be used by very primitives. For example,
Dept for tracking dependency uses llist things in its header. To avoid
header dependency, move those to types.h.
Signed-off-by: Byungchul Park
---
include/linux/llist.h | 8
include/linux/types.h | 8
2
Add check for the return value of alloc_ordered_workqueue as it may return
NULL pointer and cause NULL pointer dereference.
Moreover, change the "goto fail" into "return ret" and drop the "fail"
label since they are the same.
Signed-off-by: Jiasheng Jiang
---
Changelog:
v1 -> v2:
1. Change the
Add check for the return value of alloc_ordered_workqueue as it may return
NULL pointer.
Moreover, use the destroy_workqueue in the later fails in order to avoid
memory leak.
Signed-off-by: Jiasheng Jiang
---
Changelog:
v1 -> v2:
1. Convert "goto err_destroy_workqueue" into "goto err_msm_unit"
Add SoC-specific compat string to the MDP5 device node to ease
distinguishing between various platforms.
Signed-off-by: Dmitry Baryshkov
---
arch/arm/boot/dts/qcom-msm8974.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
Add platform-specific compatible entries to the qcom,mdp5.yaml to allow
distinguishing between various platforms. For msm8998 list
qcom,msm8998-dpu rather than -mdp5 to allow this binding to be handled
by either of the drivers.
Signed-off-by: Dmitry Baryshkov
---
Add SoC-specific compat string to the MDP5 device nodes to ease
distinguishing between various platforms.
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/msm8916.dtsi | 2 +-
arch/arm64/boot/dts/qcom/msm8996.dtsi | 2 +-
arch/arm64/boot/dts/qcom/sdm630.dtsi | 2 +-
This patch concludes the conversion of display/msm schema from txt files
to YAML format.
The per-SoC compat (new addition) is required to ease migrating platform
support between mdp5 and dpu drivers.
Changes since v2:
- Fix MSM8998 compatible list: "qcom,msm8998-dpu", "msm,mdp5" to allow
Convert the mdp5.txt into the yaml format. Changes to the existing (txt) schema:
- MSM8996 has additional "iommu" clock, define it separately
- Add new properties used on some of platforms:
- interconnects, interconnect-names
- iommus
- power-domains
- operating-points-v2, opp-table
On 22/12/2022 01:19, Marijn Suijten wrote:
Downstream calls this num_enc yet the DSC patches introduced a new
num_dsc struct member, leaving num_enc effectively unused.
Fixes: 7e9cc175b159 ("drm/msm/disp/dpu1: Add support for DSC in topology")
Signed-off-by: Marijn Suijten
---
On 09/01/2023 01:28, Dmitry Baryshkov wrote:
On 22/12/2022 01:19, Marijn Suijten wrote:
In the event that the topology requests resources that have not been
created by the system (because they are typically not represented in
dpu_mdss_cfg ^1), the resource(s) in global_state (in this case DSC
On 22/12/2022 01:19, Marijn Suijten wrote:
Resource allocation of DSC blocks should behave more like LMs and CTLs
where NULL resources (based on initial hw_blk creation via definitions
in the catalog) are skipped ^1. The current hardcoded mapping of DSC
blocks however means that resource
On 22/12/2022 01:19, Marijn Suijten wrote:
In the event that the topology requests resources that have not been
created by the system (because they are typically not represented in
dpu_mdss_cfg ^1), the resource(s) in global_state (in this case DSC
blocks) remain NULL but will still be returned
On 22/12/2022 01:19, Marijn Suijten wrote:
Active CTLs have to configure what DSC block(s) have to be enabled, and
what DSC block(s) have to be flushed; this value was initialized to zero
resulting in the necessary register writes to never happen (or would
write zero otherwise). This seems to
On 04/01/2023 11:08, Neil Armstrong wrote:
Add definitions for the display hardware used on Qualcomm SM8550
platform.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 197 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 1 +
On 04/01/2023 11:08, Neil Armstrong wrote:
Document the MDSS and DPU blocks found on the Qualcomm SM8550
platform.
Signed-off-by: Neil Armstrong
Please split this into two patches: one for mdss, one for dpu.
---
.../bindings/display/msm/qcom,sm8550-dpu.yaml | 134 +
On 04/01/2023 11:08, Neil Armstrong wrote:
This adds support for the MDSS/DPU/DSI on the Qualcomm SM8550 platform.
Nit: please change the subject for v2. It's 8550, not 8450.
This patchset is based on the SM8450 display support serie at [1].
In order to work, the following patchsets are
On 06/01/2023 17:41, Krzysztof Kozlowski wrote:
On 04/01/2023 10:08, Neil Armstrong wrote:
Document the SM8550 DSI PHY which is very close from the 7nm
and 5nm DSI PHYs found in earlier platforms.
Signed-off-by: Neil Armstrong
---
On 06/01/2023 10:47, Jiasheng Jiang wrote:
Add check for the return value of alloc_ordered_workqueue as it may return
NULL pointer.
Moreover, use the destroy_workqueue in the later fails in order to avoid
memory leak.
Fixes: c8afe684c95c ("drm/msm: basic KMS driver for snapdragon")
On 06/01/2023 04:56, Jiasheng Jiang wrote:
Add check for the return value of alloc_ordered_workqueue as it may return
NULL pointer and cause NULL pointer dereference.
Moreover, change the "return ret" into "goto fail" in order to be
consistent with the others.
Fixes: a689554ba6ed ("drm/msm:
On 06/01/2023 04:30, Jiasheng Jiang wrote:
Add check for the return value of alloc_ordered_workqueue as it may return
NULL pointer and cause NULL pointer dereference in `hdmi_hdcp.c` and
`hdmi_hpd.c`.
Fixes: c6a57a50ad56 ("drm/msm/hdmi: add hdmi hdcp support (V3)")
Signed-off-by: Jiasheng Jiang
On 08/01/2023 23:56, Dmitry Baryshkov wrote:
On 06/12/2022 10:05, Jiasheng Jiang wrote:
As kzalloc may fail and return NULL pointer,
it should be better to check cstate
in order to avoid the NULL pointer dereference
in __drm_atomic_helper_crtc_reset.
Fixes: 1cff7440a86e ("drm/msm: Convert to
On 06/12/2022 10:05, Jiasheng Jiang wrote:
As kzalloc may fail and return NULL pointer,
it should be better to check cstate
in order to avoid the NULL pointer dereference
in __drm_atomic_helper_crtc_reset.
Fixes: 1cff7440a86e ("drm/msm: Convert to using __drm_atomic_helper_crtc_reset() for
On 09/12/2022 01:31, Kuogee Hsieh wrote:
On 12/7/2022 2:00 PM, Bjorn Andersson wrote:
From: Bjorn Andersson
The Qualcomm SC8280XP platform contains DPU version 8.0.0, has 9
interfaces, 2 DSI controllers and 4 DisplayPort controllers. Extend the
necessary definitions and describe the DPU in
drm_gem_shmem_mmap() doesn't own reference in error code path, resulting
in the dma-buf shmem GEM object getting prematurely freed leading to a
later use-after-free.
Fixes: f49a51bfdc8e ("drm/shme-helpers: Fix dma_buf_mmap forwarding bug")
Cc: sta...@vger.kernel.org
Signed-off-by: Dmitry Osipenko
Different entries into the catalog were added quite randomly. Enforce
the sorting order of some kind. It is not alphabetic to prevent the
patch from growing uncontrollably. Thus SDM comes before SC and SM
platforms and QCM is kept as the last one. There are no functional
changes in this patch.
Replace Panfrost's custom memory shrinker with a common drm-shmem
memory shrinker.
Tested-by: Steven Price # Firefly-RK3288
Reviewed-by: Steven Price
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem_shmem_helper.c| 2 -
drivers/gpu/drm/panfrost/Makefile | 1 -
Support generic drm-shmem memory shrinker and add new madvise IOCTL to
the VirtIO-GPU driver. BO cache manager of Mesa driver will mark BOs as
"don't need" using the new IOCTL to let shrinker purge the marked BOs on
OOM, the shrinker will also evict unpurgeable shmem BOs from memory if
guest
Add unlocked variants of drm_gem_un/pin() functions. These new helpers
will take care of GEM dma-reservation locking for DRM drivers.
VirtIO-GPU driver will use these helpers to pin shmem framebuffers,
preventing them from eviction during scanout.
Signed-off-by: Dmitry Osipenko
---
Introduce common drm-shmem shrinker for DRM drivers.
To start using drm-shmem shrinker drivers should do the following:
1. Implement evict() callback of GEM object where driver should check
whether object is purgeable or evictable using drm-shmem helpers and
perform the shrinking action
Replace all drm-shmem locks with a GEM reservation lock. This makes locks
consistent with dma-buf locking convention where importers are responsible
for holding reservation lock for all operations performed over dma-bufs,
preventing deadlock between dma-buf importers and exporters.
Suggested-by:
DMA-buf core has its own refcounting of vmaps, use it instead of drm-shmem
counting. This change prepares drm-shmem for addition of memory shrinker
support where drm-shmem will use a single dma-buf reservation lock for
all operations performed over dma-bufs.
Signed-off-by: Dmitry Osipenko
---
Ease debugging of a multi-GPU system by using drm_WARN_*() and
drm_dbg_kms() helpers that print out DRM device name corresponding
to shmem GEM.
Suggested-by: Thomas Zimmermann
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 38 +++---
1 file
Group all 1-bit boolean members of struct drm_gem_shmem_object in the end
of the structure, allowing compiler to pack data better and making code to
look more consistent.
Suggested-by: Thomas Zimmermann
Signed-off-by: Dmitry Osipenko
---
include/drm/drm_gem_shmem_helper.h | 30
Add new common evict() callback to drm_gem_object_funcs and corresponding
drm_gem_object_evict() helper. This is a first step on a way to providing
common GEM-shrinker API for DRM drivers.
Suggested-by: Thomas Zimmermann
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem.c | 16
Lockdep warns about potential circular locking dependency of devfreq
with the fs_reclaim caused by immediate device suspension when mapping is
released by shrinker. Fix it by doing the suspension asynchronously.
Reviewed-by: Steven Price
Fixes: ec7eba47da86 ("drm/panfrost: Rework page table
Consider this scenario:
1. APP1 continuously creates lots of small GEMs
2. APP2 triggers `drop_caches`
3. Shrinker starts to evict APP1 GEMs, while APP1 produces new purgeable
GEMs
4. msm_gem_shrinker_scan() returns non-zero number of freed pages
and causes shrinker to try shrink more
5.
This series:
1. Makes minor fixes for drm_gem_lru and Panfrost
2. Brings refactoring for older code
3. Adds common drm-shmem memory shrinker
4. Enables shrinker for VirtIO-GPU driver
5. Switches Panfrost driver to the common shrinker
Changelog:
v10:- Rebased on a recent linux-next.
On Sat, 07 Jan 2023 19:26:29 +0100, Sam Ravnborg via B4 Submission Endpoint
wrote:
> From: Sam Ravnborg
>
> With all users gone remove the deprecated fb_blank member in
> backlight_properties.
>
> Signed-off-by: Sam Ravnborg
> Cc: Lee Jones
> Cc: Daniel Thompson
> Cc: Jingoo Han
> ---
>
On 30/12/2022 17:35, Robert Foss wrote:
Add compatibles string, "qcom,sm8350-dpu", for the display processing unit
used on Qualcomm SM8350 platform.
Signed-off-by: Robert Foss
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 1 +
1 file changed, 1 insertion(+)
Reviewed-by: Dmitry Baryshkov
Hi Stephen,
On Sun, Jan 08, 2023 at 08:28:17PM +0100, Stephen Kitt wrote:
> On Sat, 07 Jan 2023 19:26:23 +0100, Sam Ravnborg via B4 Submission Endpoint
> wrote:
>
> > From: Sam Ravnborg
> >
> > Avoiding direct access to backlight_properties.props.
> >
> > Access to the deprecated
Hi Helge,
> >
> > Helge - could you pick the reviewed patches from:
> > https://lore.kernel.org/all/20220607192335.1137249-1-st...@sk2.org/
> > [This is the same mail as Stephen refer to above - looked up via lore].
>
> I just pulled those 7 patches into fbdev/for-next.
> If you need more,
Hi Stephen.
> Here are my pending patches from last June on lore:
>
All patches are handled I think except this:
> * https://lore.kernel.org/lkml/20220608205623.2106113-1-st...@sk2.org/
Can I ask you to drop the assignment that is not needed, and resend with
the collected acks/r-b.
With
On Sat, 07 Jan 2023 19:26:25 +0100, Sam Ravnborg via B4 Submission Endpoint
wrote:
> From: Sam Ravnborg
>
> Introduce backlight_get_brightness() to simplify logic
> and avoid direct access to backlight properties.
>
> Signed-off-by: Sam Ravnborg
> Cc: Benjamin Herrenschmidt
> Cc: Sam
On Sat, 07 Jan 2023 19:26:24 +0100, Sam Ravnborg via B4 Submission Endpoint
wrote:
> From: Sam Ravnborg
>
> Avoiding direct access to backlight_properties.props.
>
> Access to the deprecated props.fb_blank replaced by backlight_is_blank().
> Access to props.power is dropped - it was only used
On Sat, 07 Jan 2023 19:26:27 +0100, Sam Ravnborg via B4 Submission Endpoint
wrote:
> From: Sam Ravnborg
>
> Rework backlight handling to avoid access to the deprecated
> backlight_properties.fb_blank member.
>
> The rework includes removal of get_brightness() operation,
> because there was no
On Sat, 07 Jan 2023 19:26:23 +0100, Sam Ravnborg via B4 Submission Endpoint
wrote:
> From: Sam Ravnborg
>
> Avoiding direct access to backlight_properties.props.
>
> Access to the deprecated props.fb_blank replaced by backlight_is_blank().
> Access to props.power is dropped - it was only used
On Thu, 29 Dec 2022 12:44:38 +, Bryan O'Donoghue wrote:
> Add in missing qcom,dsi-phy-regulator-ldo-mode to the 28nm DSI PHY.
> When converting from .txt to .yaml we missed this one.
>
> Fixes: 4dbe55c97741 ("dt-bindings: msm: dsi: add yaml schemas for DSI
> bindings")
> Reviewed-by:
On Sun, 25 Dec 2022 12:59:25 +0100, Krzysztof Kozlowski wrote:
> With only one compatible, there is no need to define it as list (items).
>
> Signed-off-by: Krzysztof Kozlowski
> ---
> .../devicetree/bindings/display/msm/qcom,msm8998-dpu.yaml | 3 +--
>
On Sun, 25 Dec 2022 12:59:24 +0100, Krzysztof Kozlowski wrote:
> The Devicetree bindings document does not have to say in the title that
> contains "DT properties", but instead just describe the hardware.
>
> Signed-off-by: Krzysztof Kozlowski
> ---
>
On Tue, 03 Jan 2023 13:07:05 -0600, Chris Morgan wrote:
> From: Chris Morgan
>
> Add documentation for Samsung AMS495QA01 panel (with Magnachip
> D53E6EA8966 controller IC).
>
> Signed-off-by: Chris Morgan
> Signed-off-by: Maya Matuszczyk
> ---
> .../display/panel/samsung,ams495qa01.yaml
On 1/7/23 21:53, Sam Ravnborg wrote:
Hi Stephen.
On Sat, Jan 07, 2023 at 09:36:47PM +0100, Stephen Kitt wrote:
On 7 January 2023 19:26:15 CET, Sam Ravnborg via B4 Submission Endpoint
wrote:
From: Sam Ravnborg
The atmel_lcdfb had code to save/restore power state.
This is not needed so drop
Fix programming of hsync and vsync polarities
Fixes: 23278bf54afe ("drm/bridge: Introduce LT9611 DSI to HDMI bridge")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/bridge/lontium-lt9611.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git
The lt9611 bridge can support different modes, it makes no sense to list
them in the table. Drop the table and check the number of interfaces
using the fixed value.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/bridge/lontium-lt9611.c | 41 +++--
1 file changed, 4
Attaching DVI sink to the lt9611 requires different setup. Fix the
register write to make the DVI displays sync onto the correct sync
pulse.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/bridge/lontium-lt9611.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git
Rework handling infoframes:
- Write full HDMI AVI infoframe instead of just fixing the VIC value
- Also send the HDMI Vendor Specific infoframe, as recommended by the
HDMI spec.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/bridge/lontium-lt9611.c | 57 +++--
1 file
If the bridge is connected using both DSI ports, the driver should use
both of them all the time. Correct programming sequence to always use
dual-port mode if both dsi0 and dsi1 are connected.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/bridge/lontium-lt9611.c | 28
The bindings require that there is a next bridge after the lt9611. If
nothing else it can be the hdmi-connector (as used on the RB3 platform,
see sdm845-db845c.dts).
Bring in the next bridge into the drm bridges chain and attach to it.
Since lt9611 is not anymore the last bridge in the chain,
The driver will reset the bridge in the atomic_pre_enable(). However
this will also drop the HPD interrupt state. Instead of resetting the
bridge, properly wake it up. This fixes the HPD interrupt delivery after
the disable/enable cycle.
Fixes: 23278bf54afe ("drm/bridge: Introduce LT9611 DSI to
Inline calculated values to simplify the calculation in
lt9611_mipi_video_setup().
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/bridge/lontium-lt9611.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/lontium-lt9611.c
1 - 100 of 112 matches
Mail list logo
