On 2023-06-23 08:54:39, Marijn Suijten wrote:
> On 2023-06-22 22:47:04, Abhinav Kumar wrote:
> > On 6/22/2023 6:37 PM, Dmitry Baryshkov wrote:
> > > All DSC_BLK_1_2 declarations incorrectly pass 0x29c as the block length.
> > > This includes the common block itself, enc subblocks and some empty
> >
On 2023-06-22 22:47:04, Abhinav Kumar wrote:
> On 6/22/2023 6:37 PM, Dmitry Baryshkov wrote:
> > All DSC_BLK_1_2 declarations incorrectly pass 0x29c as the block length.
> > This includes the common block itself, enc subblocks and some empty
> > space around. Change that to pass 0x4 instead, the le
On 6/22/2023 6:37 PM, Dmitry Baryshkov wrote:
All DSC_BLK_1_2 declarations incorrectly pass 0x29c as the block length.
This includes the common block itself, enc subblocks and some empty
space around. Change that to pass 0x4 instead, the length of common
register block itself.
Fixes: 0d1b10c6
Both struct dpu_dsc_sub_blks instances declare enc subblock length to be
0x100, while the actual length is 0x9c (last register having offset 0x98).
Reduce subblock length to remove the empty register space from being
dumped.
Fixes: 0d1b10c63346 ("drm/msm/dpu: add DSC 1.2 hw blocks for relevant chi
All DSC_BLK_1_2 declarations incorrectly pass 0x29c as the block length.
This includes the common block itself, enc subblocks and some empty
space around. Change that to pass 0x4 instead, the length of common
register block itself.
Fixes: 0d1b10c63346 ("drm/msm/dpu: add DSC 1.2 hw blocks for relev
On 23/06/2023 03:01, Abhinav Kumar wrote:
On 6/14/2023 2:56 AM, Marijn Suijten wrote:
On 2023-06-13 18:57:13, Jessica Zhang wrote:
DSI 6G v2.5.x+ supports a data-bus widen mode that allows DSI to send
48 bits of compressed data per pclk instead of 24.
For all chipsets that support this mode,
On 23/06/2023 03:32, Abhinav Kumar wrote:
On 6/22/2023 5:17 PM, Dmitry Baryshkov wrote:
On 23/06/2023 03:14, Abhinav Kumar wrote:
On 6/19/2023 2:06 PM, Dmitry Baryshkov wrote:
Provide actual documentation for the pclk and hdisplay calculations in
the case of DSC compression being used.
Si
On 6/22/2023 5:17 PM, Dmitry Baryshkov wrote:
On 23/06/2023 03:14, Abhinav Kumar wrote:
On 6/19/2023 2:06 PM, Dmitry Baryshkov wrote:
Provide actual documentation for the pclk and hdisplay calculations in
the case of DSC compression being used.
Signed-off-by: Dmitry Baryshkov
---
Change
On 23/06/2023 03:14, Abhinav Kumar wrote:
On 6/19/2023 2:06 PM, Dmitry Baryshkov wrote:
Provide actual documentation for the pclk and hdisplay calculations in
the case of DSC compression being used.
Signed-off-by: Dmitry Baryshkov
---
Changes since v1:
- Converted dsi_adjust_pclk_for_compre
On 23/06/2023 02:57, Dmitry Baryshkov wrote:
On 23/06/2023 02:48, Ryan McCann wrote:
Drop unused parameter "num" from VIG_SBLK_NOSCALE and DMA sub block
macros. Update calls to relevant macros to reflect change.
This is not relevant for this patchset.
Ok, after reviewing the rest of the patc
On 6/19/2023 2:06 PM, Dmitry Baryshkov wrote:
Provide actual documentation for the pclk and hdisplay calculations in
the case of DSC compression being used.
Signed-off-by: Dmitry Baryshkov
---
Changes since v1:
- Converted dsi_adjust_pclk_for_compression() into kerneldoc (Marijn)
- Added a
On 23/06/2023 02:48, Ryan McCann wrote:
Currently, the device core dump mechanism does not dump registers of sub
blocks within the DSPP, SSPP, DSC, and PINGPONG blocks. Add wrapper
function to dump hardware blocks that contain sub blocks.
Signed-off-by: Ryan McCann
---
drivers/gpu/drm/msm/dis
On 6/14/2023 2:56 AM, Marijn Suijten wrote:
On 2023-06-13 18:57:13, Jessica Zhang wrote:
DSI 6G v2.5.x+ supports a data-bus widen mode that allows DSI to send
48 bits of compressed data per pclk instead of 24.
For all chipsets that support this mode, enable it whenever DSC is
enabled as reco
On 23/06/2023 02:48, Ryan McCann wrote:
Device core dump add block method adds hardware blocks to dumping queue
with stack behavior which causes the hardware blocks to be printed in
reverse order. Change the addition to dumping queue data structure
from "list_add" to "list_add_tail" for FIFO queu
On 23/06/2023 02:48, Ryan McCann wrote:
Drop unused parameter "num" from VIG_SBLK_NOSCALE and DMA sub block
macros. Update calls to relevant macros to reflect change.
This is not relevant for this patchset.
With https://patchwork.freedesktop.org/patch/534745/?series=116851&rev=2
in place, VIG
For a device core dump, the registers of sub blocks are printed under the
title . For example, the csc sub block for an SSPP
block "sspp_0" would be printed "sspp_0_csc0". There is a redundant 0 in
the title due to a concatention done in the definition of the VIG_SBLK
macro, the macro used to defin
Currently, the device core dump mechanism does not dump registers of sub
blocks within the DSPP, SSPP, DSC, and PINGPONG blocks. Add wrapper
function to dump hardware blocks that contain sub blocks.
Signed-off-by: Ryan McCann
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 194
Some sub blocks in the hw catalog have not been given a name, so when the
registers from that block are dumped, there is no name to reference.
Define names for relevant sub blocks to fix this.
Signed-off-by: Ryan McCann
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 20 ++--
Device core dump add block method adds hardware blocks to dumping queue
with stack behavior which causes the hardware blocks to be printed in
reverse order. Change the addition to dumping queue data structure
from "list_add" to "list_add_tail" for FIFO queue behavior.
Fixes: 98659487b845 ("drm/msm
When the registers of the csc and scaler sub blocks are printed during a
device core dump, the sub block title is printed: .
Currently this appears as "sspp_0_sspp_csc" for a csc sub block to an
SSPP main block named "sspp_0". Because the name of the sub block defined
in the VIG_SBLK macro is "sspp
Drop unused parameter "num" from VIG_SBLK_NOSCALE and DMA sub block
macros. Update calls to relevant macros to reflect change.
Signed-off-by: Ryan McCann
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git
deletions(-)
---
base-commit: 710025fdedb3767655823c3a12d27d404d209f75
change-id: 20230622-devcoredump_patch-df7e8f6fd632
Best regards,
--
Ryan McCann
On 6/22/2023 4:14 PM, Dmitry Baryshkov wrote:
On 23/06/2023 01:37, Abhinav Kumar wrote:
On 6/21/2023 4:46 PM, Dmitry Baryshkov wrote:
On 22/06/2023 02:01, Abhinav Kumar wrote:
On 6/21/2023 9:36 AM, Dmitry Baryshkov wrote:
On 21/06/2023 18:17, Marijn Suijten wrote:
On 2023-06-20 14:38:
On 23/06/2023 01:37, Abhinav Kumar wrote:
On 6/21/2023 4:46 PM, Dmitry Baryshkov wrote:
On 22/06/2023 02:01, Abhinav Kumar wrote:
On 6/21/2023 9:36 AM, Dmitry Baryshkov wrote:
On 21/06/2023 18:17, Marijn Suijten wrote:
On 2023-06-20 14:38:34, Jessica Zhang wrote:
+ if (phys_enc->hw_i
On 6/14/2023 3:03 AM, Marijn Suijten wrote:
On 2023-06-14 10:49:31, Dmitry Baryshkov wrote:
On 14/06/2023 04:57, Jessica Zhang wrote:
DSI 6G v2.5.x+ supports a data-bus widen mode that allows DSI to send
48 bits of compressed data per pclk instead of 24.
For all chipsets that support this m
On 6/21/2023 4:46 PM, Dmitry Baryshkov wrote:
On 22/06/2023 02:01, Abhinav Kumar wrote:
On 6/21/2023 9:36 AM, Dmitry Baryshkov wrote:
On 21/06/2023 18:17, Marijn Suijten wrote:
On 2023-06-20 14:38:34, Jessica Zhang wrote:
+ if (phys_enc->hw_intf->ops.enable_widebus)
+
phys_en
On 20/06/2023 08:40, Juerg Haefliger wrote:
The driver references some firmware files that don't have corresponding
MODULE_FIRMWARE macros and thus won't be listed via modinfo. Fix that.
Signed-off-by: Juerg Haefliger
---
v2:
- Drop addition and removal of zap files (needs more discussion)
On 20/06/2023 14:43, Konrad Dybcio wrote:
This helper has been introduced to avoid programmer errors (missing
_put calls leading to dangling refcnt) when using pm_runtime_get, use it.
While at it, start checking the return value.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/dsi/phy/d
On 20/06/2023 14:43, Konrad Dybcio wrote:
Some devices power the DSI PHY/PLL through a power rail that we model
as a GENPD. Enable runtime PM to make it suspendable.
Signed-off-by: Konrad Dybcio
So, we were calling pm_runtime_get/put, but we didn't have runtime PM
enabled for this device? It
On 21/06/2023 02:23, Fabio Estevam wrote:
From: Fabio Estevam
The adreno_is_a20x() and adreno_is_a225() functions rely on the
GPU revision, but such information is retrieved inside adreno_gpu_init(),
which is called afterwards.
Fix this problem by caling adreno_gpu_init() earlier, so that
the
On Thu, 22 Jun 2023 at 20:25, Kuogee Hsieh wrote:
>
> Currently struct drm_dsc_config for DSI is populated at display
> setup during system boot up. This mechanism works fine with
> embedded display but not for pluggable displays as the
> struct drm_dsc_config will become stale once external displ
On 6/22/2023 7:00 AM, Dmitry Baryshkov wrote:
On 21/06/2023 19:18, Kuogee Hsieh wrote:
Currently DSI DSC struct is populated at display setup during
system bootup. This mechanism works fine with embedded display
but not for pluggable displays as the DSC struct will become
stale once external
Currently struct drm_dsc_config for DSI is populated at display
setup during system boot up. This mechanism works fine with
embedded display but not for pluggable displays as the
struct drm_dsc_config will become stale once external display
is unplugged.
Move storing of DSI DSC struct to atomic_en
Since struct drm_dsc_config is stored at atomic_enable() instead
of display setup time during boot up, saving struct drm_dsc_config
at struct msm_display_info is not necessary. Lets drop the dsc member
from struct msm_display_info.
Changes in v4:
-- fix "Since" at commit text
Signed-off-by: Kuoge
moving retrieving struct drm_dsc_cofnig from setup_display to
atomic_enable() and delete struct drm_dsc_config from
struct msm_display_info.
Kuogee Hsieh (2):
drm/msm/dpu: retrieve DSI DSC struct through priv->dsi[0]
drm/msm/dpu: remove struct drm_dsc_config from struct msm_display_info
driv
From: Qi Zheng
Hi all,
1. Background
=
We used to implement the lockless slab shrink with SRCU [1], but then kernel
test robot reported -88.8% regression in stress-ng.ramfs.ops_per_sec test
case [2], so we reverted it [3].
This patch series aims to re-implement the lockless slab sh
From: Qi Zheng
In preparation for implementing lockless slab shrink,
we need to dynamically allocate the vmw-balloon shrinker,
so that it can be freed asynchronously using kfree_rcu().
Then it doesn't need to wait for RCU read-side critical
section when releasing the struct vmballoon.
Signed-off
From: Qi Zheng
In preparation for implementing lockless slab shrink,
we need to dynamically allocate the ext4-es shrinker,
so that it can be freed asynchronously using kfree_rcu().
Then it doesn't need to wait for RCU read-side critical
section when releasing the struct ext4_sb_info.
Signed-off-
From: Qi Zheng
Introduce some helpers for dynamically allocating shrinker instance,
and their uses are as follows:
1. shrinker_alloc_and_init()
Used to allocate and initialize a shrinker instance, the priv_data
parameter is used to pass the pointer of the previously embedded
structure of the sh
From: Qi Zheng
In preparation for implementing lockless slab shrink,
we need to dynamically allocate the i915_gem_mm shrinker,
so that it can be freed asynchronously by using kfree_rcu().
Then it doesn't need to wait for RCU read-side critical
section when releasing the struct drm_i915_private.
From: Qi Zheng
In preparation for implementing lockless slab shrink,
we need to dynamically allocate the md-raid5 shrinker,
so that it can be freed asynchronously using kfree_rcu().
Then it doesn't need to wait for RCU read-side critical
section when releasing the struct r5conf.
Signed-off-by: Q
This patch set failed to send due to the following reasons, please ignore.
4.7.1 Error: too many recipients from 49.7.199.65
From: Qi Zheng
Hi all,
1. Background
=
We used to implement the lockless slab shrink with SRCU [1], but then kernel
test robot reported -88.8% regression in stress-ng.ramfs.ops_per_sec test
case [2], so we reverted it [3].
This patch series aims to re-implement the lockless slab sh
From: Qi Zheng
In preparation for implementing lockless slab shrink,
we need to dynamically allocate the drm-msm_gem shrinker,
so that it can be freed asynchronously using kfree_rcu().
Then it doesn't need to wait for RCU read-side critical
section when releasing the struct msm_drm_private.
Sign
From: Qi Zheng
In preparation for implementing lockless slab shrink,
we need to dynamically allocate the mbcache shrinker,
so that it can be freed asynchronously using kfree_rcu().
Then it doesn't need to wait for RCU read-side critical
section when releasing the struct mb_cache.
Signed-off-by:
From: Qi Zheng
In preparation for implementing lockless slab shrink,
we need to dynamically allocate the md-bcache shrinker,
so that it can be freed asynchronously using kfree_rcu().
Then it doesn't need to wait for RCU read-side critical
section when releasing the struct cache_set.
Signed-off-b
From: Qi Zheng
Introduce some helpers for dynamically allocating shrinker instance,
and their uses are as follows:
1. shrinker_alloc_and_init()
Used to allocate and initialize a shrinker instance, the priv_data
parameter is used to pass the pointer of the previously embedded
structure of the sh
From: Qi Zheng
In preparation for implementing lockless slab shrink,
we need to dynamically allocate the virtio-balloon shrinker,
so that it can be freed asynchronously using kfree_rcu().
Then it doesn't need to wait for RCU read-side critical
section when releasing the struct virtio_balloon.
Si
From: Qi Zheng
In preparation for implementing lockless slab shrink,
we need to dynamically allocate the dm-bufio shrinker,
so that it can be freed asynchronously using kfree_rcu().
Then it doesn't need to wait for RCU read-side critical
section when releasing the struct dm_bufio_client.
Signed-
From: Qi Zheng
To prepare for the dynamic allocation of shrinker instances
embedded in other structures, add a private_data field to
struct shrinker, so that we can use shrinker::private_data
to record and get the original embedded structure.
Signed-off-by: Qi Zheng
---
include/linux/shrinker.
From: Qi Zheng
In preparation for implementing lockless slab shrink,
we need to dynamically allocate the drm-panfrost shrinker,
so that it can be freed asynchronously using kfree_rcu().
Then it doesn't need to wait for RCU read-side critical
section when releasing the struct panfrost_device.
Sig
From: Qi Zheng
In preparation for implementing lockless slab shrink,
we need to dynamically allocate the dm-zoned-meta shrinker,
so that it can be freed asynchronously using kfree_rcu().
Then it doesn't need to wait for RCU read-side critical
section when releasing the struct dmz_metadata.
Signe
From: Qi Zheng
To prepare for the dynamic allocation of shrinker instances
embedded in other structures, add a private_data field to
struct shrinker, so that we can use shrinker::private_data
to record and get the original embedded structure.
Signed-off-by: Qi Zheng
---
include/linux/shrinker.
From: Qi Zheng
In preparation for implementing lockless slab shrink,
we need to dynamically allocate the jbd2-journal shrinker,
so that it can be freed asynchronously using kfree_rcu().
Then it doesn't need to wait for RCU read-side critical
section when releasing the struct journal_s.
Signed-of
On 21/06/2023 19:18, Kuogee Hsieh wrote:
Currently DSI DSC struct is populated at display setup during
system bootup. This mechanism works fine with embedded display
but not for pluggable displays as the DSC struct will become
stale once external display unplugged.
Move storing of DSI DSC struct
> > https://patchwork.freedesktop.org/patch/538601/?series=118148&rev=3
> > Apologies if you were not CCed on this, if a next version is CCed,
> >
> > will ask kuogee to cc you.
> >
> > Meanwhile, will be great if you can verify if it works for you and
> >
> > provide Tested-by tags.
> >
>
56 matches
Mail list logo
