On 8 January 2023 08:45:46 CET, Stephen Kitt wrote:
>On 7 January 2023 21:53:46 CET, 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 Ravnbor
Hi Robin.
On Sat, Jan 07, 2023 at 10:02:38PM +0100, Miguel Ojeda wrote:
> On Sat, Jan 7, 2023 at 7:26 PM Sam Ravnborg via B4 Submission Endpoint
> wrote:
> >
> > Introduce backlight_get_brightness() to simplify logic
> > and avoid direct access to backlight properties.
>
> Note: Stephen sent thi
https://bugzilla.kernel.org/show_bug.cgi?id=216899
Artem S. Tashkinov (a...@gmx.com) changed:
What|Removed |Added
Status|NEW |RESOLVED
Reso
On Sat, Jan 7, 2023 at 8:48 PM Tom Rix wrote:
>
> From reviewing the code, the line
> memset(kdata, 0, usize);
> is not needed because kdata is either zeroed by
> kdata = kzalloc(asize, GFP_KERNEL);
> when allocated at runtime or by
> char stack_kdata[128] = {0};
> at compile time.
>
> Signe
On 07/01/2023 11:22, Pin-yen Lin wrote:
> Analogix 7625 can be used in systems to switch the DP traffic between
> two downstreams, which can be USB Type-C DisplayPort alternate mode
> lane or regular DisplayPort output ports.
>
> Update the binding to accommodate this usage by introducing a
> data
On 07/01/2023 11:22, Pin-yen Lin wrote:
> ITE IT6505 can be used in systems to switch the DP traffic between
> two downstreams, which can be USB Type-C DisplayPort alternate mode
> lane or regular DisplayPort output ports.
>
> Update the binding to accommodate this usage by introducing a
> data-la
On atomic_post_disable the bridge goes to the low power state. However
the code disables too much of the chip, so the HPD event is not being
detected and delivered to the host. Reduce the power saving in order to
get the HPD event.
Fixes: 23278bf54afe ("drm/bridge: Introduce LT9611 DSI to HDMI bri
A series of patches to fix mode programming for the Lontium lt9611
DSI-to-HDMI bridge (found e.g. on the Thundercomm RB3/Dragonboard845c
platform).
Changes since v1:
- Fixed the double-DSI check to look for the lt9611->dsi1_node rather
than lt9611->dsi1, modesetting happens before lt9611->dsi1
Program the upper part of the hfront_porch into the proper register.
Fixes: 23278bf54afe ("drm/bridge: Introduce LT9611 DSI to HDMI bridge")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/bridge/lontium-lt9611.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/g
Pass a pointer to the OF node while registering lt9611 MIPI device.
Fixes: 23278bf54afe ("drm/bridge: Introduce LT9611 DSI to HDMI bridge")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/bridge/lontium-lt9611.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/
The mode_set callback is deprectated for drm_bridges in favour of using
atomic_enable callback. Move corresponding code into the function
lt9611_bridge_atomic_enable() and turn lt9611_bridge_pre_enable() into
the proper atomic_pre_enable callback.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/
Instead of having several fixed values for the pcr register, calculate
it before programming. This allows the bridge to support most of the
display modes.
Fixes: 23278bf54afe ("drm/bridge: Introduce LT9611 DSI to HDMI bridge")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/bridge/lontium-lt
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
b/drivers/gpu/drm/bridge
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 HD
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, thi
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 --
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 c
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 a/dr
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 inser
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 a/drivers/gpu/drm
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
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 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
> ---
> .../devicetree/bindings/display/msm/dsi-ph
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 +--
> .../devicetree/bindings/display/msm
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: Dmitry
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 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: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: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 Ravnbor
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 this
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, pleas
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 props.fb_bla
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
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
> ---
> d
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. msm
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.
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 flush
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
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 +++--
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 chang
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
---
dr
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: D
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
2.
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
---
drivers/gpu/
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 suppor
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 -
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.
Sig
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
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 th
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
rese
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 us
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 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: Init
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")
Signed-off-by
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
---
Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yam
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 req
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 +
.../bind
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 +
dri
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 ha
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 o
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 allocat
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
bl
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
---
drivers/gpu/drm
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
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
handli
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 +-
arch/arm64/boot/
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
---
.../bindings/display/msm/qcom,md
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
b/arch/arm/boo
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 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
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 file
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.
https://github.c
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
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
+++ b/include/l
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 a
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
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 b/drivers/dma-buf/dma-f
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 --g
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 refill
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, fal
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.
/*
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(+), 1
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 b/in
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
+++ b/include/linux/
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
--- a/include/linux/wai
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
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 ++
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 o
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 a/include/linux/completi
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(-)
d
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
+++ b/drivers
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 raw_l
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 @@
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 a/Documentation/devicetree/bindings/display/msm/qc
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
b/Docu
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
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
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 +-
arch/arm64/boot/
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
---
.../bindings/display/msm/qcom,md
1 - 100 of 112 matches
Mail list logo
