Re: [RFC v3 3/3] drm/ttm/tests: Add tests for ttm_pool

Am 04.07.23 um 08:50 schrieb Mauro Carvalho Chehab: On Mon, 3 Jul 2023 13:21:43 +0200 Christian König wrote: + /* We don't need this BO later, release it */ + ttm_bo_put(bo); That won't work. A BO must always outlive the TT object allocated for it. Otherwise you can get crashes d

Re: [PATCH] drm/amdgpu: avoid integer overflow warning in amdgpu_device_resize_fb_bar()

Am 03.07.23 um 14:35 schrieb Arnd Bergmann: From: Arnd Bergmann On 32-bit architectures comparing a resource against a value larger than U32_MAX can cause a warning: drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1344:18: error: result of comparison of constant 4294967296 with expression of type

Re: [PATCH 2/3] drm/mediatek: Use dev_err_probe() in probe functions

Re: [RFC v3 3/3] drm/ttm/tests: Add tests for ttm_pool

On Mon, 3 Jul 2023 13:21:43 +0200 Christian König wrote: > > + /* We don't need this BO later, release it */ > > + ttm_bo_put(bo); > > That won't work. A BO must always outlive the TT object allocated for it. > > Otherwise you can get crashes during TT release. Just my two cents: shouldn

Re: [RFC v3 3/3] drm/ttm/tests: Add tests for ttm_pool

On 3.07.2023 13:21, Christian König wrote: Am 03.07.23 um 09:58 schrieb Karolina Stolarek: Add KUnit tests that exercise page allocation using page pools and freeing pages, either by returning them to the pool or freeing them. Add a basic test for ttm_pool cleanup. Introduce helpers to create

Re: [PATCH 1/5] accel/qaic: tighten bounds checking in encode_message()

On 7/4/2023 11:57 AM, Pranjal Ramajor Asha Kanojiya wrote: On 6/21/2023 12:51 PM, Dan Carpenter wrote: There are several issues in this code.  The check at the start of the loop: if (user_len >= user_msg->len) { This check does not ensure that we have enough space for the trans_hdr (8

Re: [PATCH 2/5] accel/qaic: tighten bounds checking in decode_message()

On 6/21/2023 12:51 PM, Dan Carpenter wrote: Copy the bounds checking from encode_message() to decode_message(). This patch addresses the following concerns. Ensure that there is enough space for at least one header so that we don't have a negative size later. if (msg_hdr_len < sizeo

Re: [PATCH 1/3] drm/mediatek: Use devm_platform_get_and_ioremap_resource()

Re: [PATCH 1/5] accel/qaic: tighten bounds checking in encode_message()

On 6/21/2023 12:51 PM, Dan Carpenter wrote: There are several issues in this code. The check at the start of the loop: if (user_len >= user_msg->len) { This check does not ensure that we have enough space for the trans_hdr (8 bytes). Instead the check needs to be: if (user

Re: [PATCH 3/9] drm/verisilicon: Add basic drm driver

On 2023/7/4 2:42, Shengyu Qu wrote: > Hello Keith, > > While compiling this driver as a module, a error happens: > > drivers/gpu/drm/verisilicon/vs_drm: struct of_device_id is 200 bytes.  The > last of 1 is: > 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > 0x00

Re: [PATCH v4 1/2] drm/mediatek: Add ability to support dynamic connector selection

[PATCH] drm/panel: Add avdd/avee delay for Starry-himax83102-j02 and Starry-ili9882t panel

>From power on/off sequence for panel data sheet[1], T2 timing VSP to VSN needs 1ms delay when power on, and VSN to VSP also needs 1ms delay when power off. Some pmic may not be able to adjust the delay internally, so let's add a delay between avdd/avee regulator gpio to meet the timing of panel.

Re: [PATCH 24/29] mm: vmscan: make global slab shrink lockless

Hi Dave, On 2023/6/24 19:08, Qi Zheng wrote: Hi Dave, On 2023/6/24 06:19, Dave Chinner wrote: On Fri, Jun 23, 2023 at 09:10:57PM +0800, Qi Zheng wrote: On 2023/6/23 14:29, Dave Chinner wrote: On Thu, Jun 22, 2023 at 05:12:02PM +0200, Vlastimil Babka wrote: On 6/22/23 10:53, Qi Zheng wrote:

Re: [PATCH v4 04/19] drm/msm/dpu: drop dpu_mdss_cfg::mdp_count field

On 7/3/2023 7:20 PM, Dmitry Baryshkov wrote: On 03/07/2023 05:01, Abhinav Kumar wrote: On 6/19/2023 2:25 PM, Dmitry Baryshkov wrote: There is always a single MDP TOP block. Drop the mdp_count field and stop declaring dpu_mdp_cfg instances as arrays. Tested-by: Marijn Suijten Signed-off-b

Re: [PATCH V5 1/9] drivers core: Add support for Wifi band RF mitigations

On 7/3/23 22:40, Quan, Evan wrote: [AMD Official Use Only - General] -Original Message- From: Limonciello, Mario Sent: Saturday, July 1, 2023 12:41 AM To: Quan, Evan ; raf...@kernel.org; l...@kernel.org; Deucher, Alexander ; Koenig, Christian ; Pan, Xinhui ; airl...@gmail.com; dan...@f

Re: [PATCH 24/29] mm: vmscan: make global slab shrink lockless

On 2023/7/4 00:39, Paul E. McKenney wrote: On Fri, Jun 23, 2023 at 04:29:39PM +1000, Dave Chinner wrote: On Thu, Jun 22, 2023 at 05:12:02PM +0200, Vlastimil Babka wrote: On 6/22/23 10:53, Qi Zheng wrote: @@ -1067,33 +1068,27 @@ static unsigned long shrink_slab(gfp_t gfp_mask, int nid,

RE: [PATCH V5 1/9] drivers core: Add support for Wifi band RF mitigations

[AMD Official Use Only - General] > -Original Message- > From: Simon Horman > Sent: Friday, June 30, 2023 9:39 PM > To: Quan, Evan > Cc: raf...@kernel.org; l...@kernel.org; Deucher, Alexander > ; Koenig, Christian > ; Pan, Xinhui ; > airl...@gmail.com; dan...@ffwll.ch; johan...@sipsoluti

RE: [PATCH V5 1/9] drivers core: Add support for Wifi band RF mitigations

[AMD Official Use Only - General] > -Original Message- > From: Limonciello, Mario > Sent: Saturday, July 1, 2023 12:41 AM > To: Quan, Evan ; raf...@kernel.org; l...@kernel.org; > Deucher, Alexander ; Koenig, Christian > ; Pan, Xinhui ; > airl...@gmail.com; dan...@ffwll.ch; johan...@sipsol

RE: [PATCH V5 1/9] drivers core: Add support for Wifi band RF mitigations

[AMD Official Use Only - General] > -Original Message- > From: Andrew Lunn > Sent: Saturday, July 1, 2023 8:20 AM > To: Quan, Evan > Cc: raf...@kernel.org; l...@kernel.org; Deucher, Alexander > ; Koenig, Christian > ; Pan, Xinhui ; > airl...@gmail.com; dan...@ffwll.ch; johan...@sipsoluti

RE: [PATCH V5 1/9] drivers core: Add support for Wifi band RF mitigations

[AMD Official Use Only - General] > -Original Message- > From: Andrew Lunn > Sent: Saturday, July 1, 2023 8:25 AM > To: Limonciello, Mario > Cc: Quan, Evan ; raf...@kernel.org; l...@kernel.org; > Deucher, Alexander ; Koenig, Christian > ; Pan, Xinhui ; > airl...@gmail.com; dan...@ffwll.c

RE: [PATCH V5 2/9] driver core: add ACPI based WBRF mechanism introduced by AMD

[AMD Official Use Only - General] > -Original Message- > From: Andrew Lunn > Sent: Saturday, July 1, 2023 8:51 AM > To: Quan, Evan > Cc: raf...@kernel.org; l...@kernel.org; Deucher, Alexander > ; Koenig, Christian > ; Pan, Xinhui ; > airl...@gmail.com; dan...@ffwll.ch; johan...@sipsoluti

RE: [PATCH V5 4/9] wifi: mac80211: Add support for ACPI WBRF

[AMD Official Use Only - General] Hi Andrew, > -Original Message- > From: Andrew Lunn > Sent: Saturday, July 1, 2023 9:02 AM > To: Quan, Evan > Cc: raf...@kernel.org; l...@kernel.org; Deucher, Alexander > ; Koenig, Christian > ; Pan, Xinhui ; > airl...@gmail.com; dan...@ffwll.ch; johan.

[PATCH 1/2] docs: module: start adding some docs for MODULE_ macros.

From: Dave Airlie In order to add a new macro, Luis suggested converting some docs for the new ones. This tries to keep exisiting module_init, module_exit where they are, and adds the new docs to the module section. Cc: linux-...@vger.kernel.org Cc: Jonathan Corbet Cc: Luis Chamberlain Cc: li

[PATCH 2/2] modules/firmware: add a new option to denote a firmware group to choose one.

From: Dave Airlie This adds two tags that will go into the module info. The first denotes a group of firmwares, when that tag is present all MODULE_FIRMWARE lines between the tags will be ignored by new versions of dracut. The second makes an explicitly ordered group of firmwares to search for

modules: firmware groups attempt two

This is a second attempt at firmware grouping so we can have dracut only pull one firmware into the initramfs instead of a bunch of legacy ones. v1 got derailed when it was pointed out that ordering isn't consistent in modinfo with C to sections, so that plan no longer was feasible. This was the

Re: [PATCH v5 1/1] drm/doc: Document DRM device reset expectations

On 7/3/23 19:44, Marek Olšák wrote: > > > On Mon, Jul 3, 2023, 22:38 Randy Dunlap > wrote: > > > > On 7/3/23 19:34, Marek Olšák wrote: > > > > > > On Mon, Jul 3, 2023, 03:12 Michel Dänzer

Re: [PATCH v5 1/1] drm/doc: Document DRM device reset expectations

On Mon, Jul 3, 2023, 22:38 Randy Dunlap wrote: > > > On 7/3/23 19:34, Marek Olšák wrote: > > > > > > On Mon, Jul 3, 2023, 03:12 Michel Dänzer > wrote: > > > > Marek, > Please stop sending html emails to the mailing lists. > The mailing list software drops them.

Re: [PATCH v5 1/1] drm/doc: Document DRM device reset expectations

On 7/3/23 19:34, Marek Olšák wrote: > > > On Mon, Jul 3, 2023, 03:12 Michel Dänzer > wrote: > Marek, Please stop sending html emails to the mailing lists. The mailing list software drops them. Please set your email interface to use plain text mode instead

Re: [PATCH v5 1/1] drm/doc: Document DRM device reset expectations

On Mon, Jul 3, 2023, 03:12 Michel Dänzer wrote: > On 6/30/23 22:32, Marek Olšák wrote: > > On Fri, Jun 30, 2023 at 11:11 AM Michel Dänzer < > michel.daen...@mailbox.org > wrote: > >> On 6/30/23 16:59, Alex Deucher wrote: > >>> On Fri, Jun 30, 2023 at 10:49 AM Se

[PATCH v5 16/19] drm/msm/dpu: inline WB_BLK macros

To simplify making changes to the hardware block definitions, expand corresponding macros. This way making all the changes are more obvious and visible in the source files. Tested-by: Marijn Suijten Reviewed-by: Marijn Suijten Reviewed-by: Abhinav Kumar Signed-off-by: Dmitry Baryshkov --- ...

[PATCH v5 09/19] drm/msm/dpu: correct indentation for CTL definitions

Shift dpu_ctl_cfg contents to correct the indentation of CTL blocks. This is done in preparation to expanding the rest of hardware block defines, so that all blocks have similar indentation. Reviewed-by: Marijn Suijten Tested-by: Marijn Suijten Reviewed-by: Abhinav Kumar Signed-off-by: Dmitry B

[PATCH v5 19/19] drm/msm/dpu: drop empty features mask INTF_SDM845_MASK

The INTF_SDM845_MASK features mask is zero. Drop it completely. Reviewed-by: Marijn Suijten Tested-by: Marijn Suijten Reviewed-by: Abhinav Kumar Signed-off-by: Dmitry Baryshkov --- drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 4 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_

[PATCH v5 18/19] drm/msm/dpu: drop empty features mask MERGE_3D_SM8150_MASK

The MERGE_3D_SM8150_MASK features mask is zero. Drop it completely. Reviewed-by: Marijn Suijten Tested-by: Marijn Suijten Reviewed-by: Abhinav Kumar Signed-off-by: Dmitry Baryshkov --- drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h | 3 --- drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_

[PATCH v5 17/19] drm/msm/dpu: inline INTF_BLK and INTF_BLK_DSI_TE macros

To simplify making changes to the hardware block definitions, expand corresponding macros. This way making all the changes are more obvious and visible in the source files. Tested-by: Marijn Suijten Reviewed-by: Marijn Suijten Reviewed-by: Abhinav Kumar Signed-off-by: Dmitry Baryshkov --- ...

[PATCH v5 12/19] drm/msm/dpu: inline LM_BLK macros

To simplify making changes to the hardware block definitions, expand corresponding macros. This way making all the changes are more obvious and visible in the source files. Tested-by: Marijn Suijten Reviewed-by: Marijn Suijten Reviewed-by: Abhinav Kumar Signed-off-by: Dmitry Baryshkov --- ...

[PATCH v5 04/19] drm/msm/dpu: drop dpu_mdss_cfg::mdp_count field

There is always a single MDP TOP block. Drop the mdp_count field and stop declaring dpu_mdp_cfg instances as arrays. Tested-by: Marijn Suijten Reviewed-by: Marijn Suijten Signed-off-by: Dmitry Baryshkov --- .../msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 7 ++-- .../msm/disp/dpu1/catalog/dpu_

[PATCH v5 15/19] drm/msm/dpu: inline various PP_BLK_* macros

To simplify making changes to the hardware block definitions, expand corresponding macros. This way making all the changes are more obvious and visible in the source files. Tested-by: Marijn Suijten Reviewed-by: Abhinav Kumar Reviewed-by: Marijn Suijten Signed-off-by: Dmitry Baryshkov --- ...

[PATCH v5 14/19] drm/msm/dpu: inline MERGE_3D_BLK macros

To simplify making changes to the hardware block definitions, expand corresponding macros. This way making all the changes are more obvious and visible in the source files. Tested-by: Marijn Suijten Reviewed-by: Marijn Suijten Reviewed-by: Abhinav Kumar Signed-off-by: Dmitry Baryshkov --- ...

[PATCH v5 06/19] drm/msm/dpu: expand .clk_ctrls definitions

Use more standard initialisation for .clk_ctrls definitions. Define a single .clk_ctrls field and use array init inside. Reviewed-by: Marijn Suijten Tested-by: Marijn Suijten Reviewed-by: Abhinav Kumar Signed-off-by: Dmitry Baryshkov --- .../msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 22

[PATCH v5 07/19] drm/msm/dpu: drop zero features from dpu_mdp_cfg data

Drop useless zero assignments to the dpu_mdp_cfg::features field. Reviewed-by: Marijn Suijten Tested-by: Marijn Suijten Reviewed-by: Abhinav Kumar Signed-off-by: Dmitry Baryshkov --- drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h | 1 - drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_2_s

[PATCH v5 13/19] drm/msm/dpu: inline DSC_BLK and DSC_BLK_1_2 macros

To simplify making changes to the hardware block definitions, expand corresponding macros. This way making all the changes are more obvious and visible in the source files. Tested-by: Marijn Suijten Signed-off-by: Dmitry Baryshkov --- .../msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 9 - ..

[PATCH v5 11/19] drm/msm/dpu: inline DSPP_BLK macros

To simplify making changes to the hardware block definitions, expand corresponding macros. This way making all the changes are more obvious and visible in the source files. Tested-by: Marijn Suijten Reviewed-by: Abhinav Kumar Reviewed-by: Marijn Suijten Signed-off-by: Dmitry Baryshkov --- ...

[PATCH v5 10/19] drm/msm/dpu: inline SSPP_BLK macros

To simplify making changes to the hardware block definitions, expand corresponding macros. This way making all the changes are more obvious and visible in the source files. Tested-by: Marijn Suijten Reviewed-by: Abhinav Kumar Reviewed-by: Marijn Suijten Signed-off-by: Dmitry Baryshkov --- ...

[PATCH v5 08/19] drm/msm/dpu: drop zero features from dpu_ctl_cfg data

Drop useless zero assignments to the dpu_ctl_cfg::features field. Reviewed-by: Marijn Suijten Tested-by: Marijn Suijten Reviewed-by: Abhinav Kumar Signed-off-by: Dmitry Baryshkov --- drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 3 --- drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0

[PATCH v5 05/19] drm/msm/dpu: drop enum dpu_mdp and MDP_TOP value

Since there is always just a single MDP_TOP instance, drop the enum dpu_mdp and corresponding index value. Reviewed-by: Marijn Suijten Tested-by: Marijn Suijten Reviewed-by: Abhinav Kumar Signed-off-by: Dmitry Baryshkov --- drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 2 +- driv

[PATCH v5 02/19] drm/msm/dpu: always use MSM_DP/DSI_CONTROLLER_n

In several catalog entries we did not use existing MSM_DP_CONTROLLER_n constants. Fill them in. Also use freshly defined MSM_DSI_CONTROLLER_n for DSI interfaces. Reviewed-by: Marijn Suijten Tested-by: Marijn Suijten Reviewed-by: Abhinav Kumar Signed-off-by: Dmitry Baryshkov --- drivers/gpu/dr

[PATCH v5 03/19] drm/msm/dpu: simplify peer LM handling

For each LM there is at max 1 peer LM. Thus there is no need to have a mask for the peer LM enumeration. Change that to have an ID of the peer LM. Reviewed-by: Marijn Suijten Tested-by: Marijn Suijten Signed-off-by: Dmitry Baryshkov --- .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 2 +- ..

[PATCH v5 01/19] drm/msm: enumerate DSI interfaces

Follow the DP example and define MSM_DSI_CONTROLLER_n enumeration. Reviewed-by: Abhinav Kumar Reviewed-by: Marijn Suijten Tested-by: Marijn Suijten Signed-off-by: Dmitry Baryshkov --- drivers/gpu/drm/msm/msm_drv.h | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/driv

[PATCH v5 00/19] drm/msm/dpu: another catalog rework

Having a macro with 10 arguments doesn't seem like a good idea. It makes it inherently harder to compare the actual structure values. Also this leads to adding macros covering varieties of the block. As it was previously discussed, inline all foo_BLK macros in order to ease performing changes to t

Re: [PATCH v4 04/19] drm/msm/dpu: drop dpu_mdss_cfg::mdp_count field

On 03/07/2023 05:01, Abhinav Kumar wrote: On 6/19/2023 2:25 PM, Dmitry Baryshkov wrote: There is always a single MDP TOP block. Drop the mdp_count field and stop declaring dpu_mdp_cfg instances as arrays. Tested-by: Marijn Suijten Signed-off-by: Dmitry Baryshkov --- The change drops mdp_c

[v2] media: mediatek: vcodec: fix AV1 decode fail for 36bit iova

Fix av1 decode fail when iova is 36bit. Decoder hardware will access incorrect iova address when tile buffer is 36bit, it will lead to iommu fault when hardware access dram data. Fixes: 2f5d0aef37c6 ("media: mediatek: vcodec: support stateless AV1 decoder") Signed-off-by: Xiaoyong Lu --- Changes

Re: [PATCH 6/8] drm/msm/dpu: use dpu_perf_cfg in DPU core_perf code

On 6/20/2023 4:31 AM, Konrad Dybcio wrote: On 20.06.2023 13:18, Dmitry Baryshkov wrote: On 20/06/2023 13:55, Konrad Dybcio wrote: On 20.06.2023 02:08, Dmitry Baryshkov wrote: Simplify dpu_core_perf code by using only dpu_perf_cfg instead of using full-featured catalog data. Signed-off-by:

Re: [PATCH 5/8] drm/msm/dpu: drop the dpu_core_perf_crtc_update()'s stop_req param

On 7/3/2023 5:28 PM, Dmitry Baryshkov wrote: On Tue, 4 Jul 2023 at 02:16, Abhinav Kumar wrote: On 7/3/2023 4:01 PM, Dmitry Baryshkov wrote: On Tue, 4 Jul 2023 at 01:55, Abhinav Kumar wrote: On 7/3/2023 3:53 PM, Dmitry Baryshkov wrote: On Tue, 4 Jul 2023 at 01:37, Abhinav Kumar wro

Re: [PATCH 5/8] drm/msm/dpu: drop the dpu_core_perf_crtc_update()'s stop_req param

On Tue, 4 Jul 2023 at 02:16, Abhinav Kumar wrote: > > > > On 7/3/2023 4:01 PM, Dmitry Baryshkov wrote: > > On Tue, 4 Jul 2023 at 01:55, Abhinav Kumar > > wrote: > >> > >> > >> > >> On 7/3/2023 3:53 PM, Dmitry Baryshkov wrote: > >>> On Tue, 4 Jul 2023 at 01:37, Abhinav Kumar > >>> wrote: >

Re: [PATCH 8/8] drm/msm/dpu: remove unused fields from struct dpu_core_perf

On 6/19/2023 5:08 PM, Dmitry Baryshkov wrote: Remove dpu_core_perf::dev and dpu_core_perf::debugfs_root fields, they are not used by the code. Signed-off-by: Dmitry Baryshkov --- drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 2 -- drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h | 4

Re: [PATCH v3 0/4] Qualcomm REFGEN regulator

On Tue, 4 Jul 2023 at 01:59, Mark Brown wrote: > > On Mon, Jul 03, 2023 at 08:15:53PM +0200, Konrad Dybcio wrote: > > > Recent Qualcomm SoCs have a REFGEN (reference voltage generator) regulator > > responsible for providing a reference voltage to some on-SoC IPs (like DSI > > or PHYs). It can be

Re: [PATCH 7/8] drm/msm/dpu: drop dpu_core_perf_destroy()

On 7/3/2023 3:59 PM, Dmitry Baryshkov wrote: On Tue, 4 Jul 2023 at 01:57, Abhinav Kumar wrote: On 6/19/2023 5:08 PM, Dmitry Baryshkov wrote: This function does nothing, just clears several data pointers. Drop it now. This will undo what dpu_core_perf_init() did when an error happens.

RE: [PATCH 2/3] drm/panel: ld9040: Register a backlight device

Hi, > -Original Message- > From: dri-devel On Behalf Of > Paul Cercueil > Sent: Tuesday, July 4, 2023 6:47 AM > To: Krzysztof Kozlowski ; Rob Herring > ; Conor Dooley ; Alim Akhtar > ; Neil Armstrong ; Sam > Ravnborg > Cc: devicet...@vger.kernel.org; linux-samsung-...@vger.kernel.org; li

Re: [PATCH 5/8] drm/msm/dpu: drop the dpu_core_perf_crtc_update()'s stop_req param

On 7/3/2023 4:01 PM, Dmitry Baryshkov wrote: On Tue, 4 Jul 2023 at 01:55, Abhinav Kumar wrote: On 7/3/2023 3:53 PM, Dmitry Baryshkov wrote: On Tue, 4 Jul 2023 at 01:37, Abhinav Kumar wrote: On 6/19/2023 5:08 PM, Dmitry Baryshkov wrote: The stop_req is true only in the dpu_crtc_disa

[PATCH] drm/i915/pmu: Use local64_try_cmpxchg in i915_pmu_event_read

Use local64_try_cmpxchg instead of local64_cmpxchg (*ptr, old, new) == old in i915_pmu_event_read. x86 CMPXCHG instruction returns success in ZF flag, so this change saves a compare after cmpxchg (and related move instruction in front of cmpxchg). Also, try_cmpxchg implicitly assigns old *ptr val

[PATCH] drm/amdgpu: Use local64_try_cmpxchg in amdgpu_perf_read

Use local64_try_cmpxchg instead of local64_cmpxchg (*ptr, old, new) == old in amdgpu_perf_read. x86 CMPXCHG instruction returns success in ZF flag, so this change saves a compare after cmpxchg (and related move instruction in front of cmpxchg). Also, try_cmpxchg implicitly assigns old *ptr value

[PATCH v4 5/5] drm: Make FB_CORE to be selected if DRM fbdev emulation is enabled

Now that fbdev core has been split in FB_CORE and FB, make the DRM symbol to select the FB_CORE option if the DRM fbdev emulation layer is enabled. This allows to disable the CONFIG_FB option if is not needed, which will avoid the need to explicitly disable each of the legacy fbdev drivers. Signe

[PATCH v4 2/5] fbdev: Move core fbdev symbols to a separate Kconfig file

The drivers/video/fbdev/Kconfig defines both symbols for fbdev drivers and core fbdev symbols, that can be enabled independently of the fbdev drivers. Split the Kconfig in two, one that only has the symbols for fbdev drivers and another one that contains the fbdev core symbols. Suggested-by: Arnd

[PATCH v4 1/5] video: Add auxiliary display drivers to Graphics support menu

The drivers in this subsystem are for character-based LCD displays, which can fall into the same category of the DRM/KMS and fbdev drivers that are located under the "Graphics support" menu. Add auxdisplay there as well. Suggested-by: Thomas Zimmermann Signed-off-by: Javier Martinez Canillas ---

[PATCH v4 4/5] fbdev: Split frame buffer support in FB and FB_CORE symbols

Currently the CONFIG_FB option has to be enabled even if no legacy fbdev drivers are needed (e.g: only to have support for framebuffer consoles). The DRM subsystem has a fbdev emulation layer, but depends on CONFIG_FB and so it can only be enabled if that dependency is enabled as well. That means

[PATCH v4 3/5] drm/arm: Make ARM devices menu depend on DRM

Otherwise if CONFIG_DRM is disabled, menuconfig will show an empty menu. Signed-off-by: Javier Martinez Canillas --- (no changes since v1) drivers/gpu/drm/arm/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/arm/Kconfig b/drivers/gpu/drm/arm/Kconfig index c1b89274d2a

[PATCH v4 0/5] Allow disabling all native fbdev drivers and only keeping DRM emulation

This patch series splits the fbdev core support in two different Kconfig symbols: FB and FB_CORE. The motivation for this is to allow CONFIG_FB to be disabled, while still having the the core fbdev support needed for the CONFIG_DRM_FBDEV_EMULATION to be enabled. The motivation is automatically disa

Re: [PATCH v3 0/4] Qualcomm REFGEN regulator

On 4.07.2023 00:59, Mark Brown wrote: > On Mon, Jul 03, 2023 at 08:15:53PM +0200, Konrad Dybcio wrote: > >> Recent Qualcomm SoCs have a REFGEN (reference voltage generator) regulator >> responsible for providing a reference voltage to some on-SoC IPs (like DSI >> or PHYs). It can be turned off whe

Re: [PATCH 5/8] drm/msm/dpu: drop the dpu_core_perf_crtc_update()'s stop_req param

On Tue, 4 Jul 2023 at 01:55, Abhinav Kumar wrote: > > > > On 7/3/2023 3:53 PM, Dmitry Baryshkov wrote: > > On Tue, 4 Jul 2023 at 01:37, Abhinav Kumar > > wrote: > >> > >> > >> > >> On 6/19/2023 5:08 PM, Dmitry Baryshkov wrote: > >>> The stop_req is true only in the dpu_crtc_disable() case, when

Re: [PATCH v3 0/4] Qualcomm REFGEN regulator

On Mon, Jul 03, 2023 at 08:15:53PM +0200, Konrad Dybcio wrote: > Recent Qualcomm SoCs have a REFGEN (reference voltage generator) regulator > responsible for providing a reference voltage to some on-SoC IPs (like DSI > or PHYs). It can be turned off when unused to save power. > > This series intr

Re: [PATCH 7/8] drm/msm/dpu: drop dpu_core_perf_destroy()

On Tue, 4 Jul 2023 at 01:57, Abhinav Kumar wrote: > > > > On 6/19/2023 5:08 PM, Dmitry Baryshkov wrote: > > This function does nothing, just clears several data pointers. Drop it > > now. > > > > This will undo what dpu_core_perf_init() did when an error happens. > > Why can we drop that? Because

Re: [PATCH 7/8] drm/msm/dpu: drop dpu_core_perf_destroy()

On 6/19/2023 5:08 PM, Dmitry Baryshkov wrote: This function does nothing, just clears several data pointers. Drop it now. This will undo what dpu_core_perf_init() did when an error happens. Why can we drop that? Signed-off-by: Dmitry Baryshkov --- drivers/gpu/drm/msm/disp/dpu1/dpu_cor

Re: [PATCH 5/8] drm/msm/dpu: drop the dpu_core_perf_crtc_update()'s stop_req param

On 7/3/2023 3:53 PM, Dmitry Baryshkov wrote: On Tue, 4 Jul 2023 at 01:37, Abhinav Kumar wrote: On 6/19/2023 5:08 PM, Dmitry Baryshkov wrote: The stop_req is true only in the dpu_crtc_disable() case, when crtc->enable has already been set to false. This renders the stop_req argument usele

Re: [PATCH v3 4/4] drm/msm/dsi: Hook up refgen regulator

On Mon, 3 Jul 2023 at 21:16, Konrad Dybcio wrote: > > Consume the refgen supply on configurations that may use it. > > Signed-off-by: Konrad Dybcio Reviewed--by: Dmitry Baryshkov > --- > drivers/gpu/drm/msm/dsi/dsi_cfg.c | 2 ++ > 1 file changed, 2 insertions(+) -- With best wishes Dmitry

Re: [PATCH 5/8] drm/msm/dpu: drop the dpu_core_perf_crtc_update()'s stop_req param

On Tue, 4 Jul 2023 at 01:37, Abhinav Kumar wrote: > > > > On 6/19/2023 5:08 PM, Dmitry Baryshkov wrote: > > The stop_req is true only in the dpu_crtc_disable() case, when > > crtc->enable has already been set to false. This renders the stop_req > > argument useless. Remove it completely. > > > > W

Re: [PATCH 5/8] drm/msm/dpu: drop the dpu_core_perf_crtc_update()'s stop_req param

On 6/19/2023 5:08 PM, Dmitry Baryshkov wrote: The stop_req is true only in the dpu_crtc_disable() case, when crtc->enable has already been set to false. This renders the stop_req argument useless. Remove it completely. What about the enable case? That time dpu_crtc->enabled will be false

Re: [PATCH 2/8] drm/msm/dpu: drop performance tuning modes

On Tue, 4 Jul 2023 at 01:26, Abhinav Kumar wrote: > > > > On 7/3/2023 3:20 PM, Dmitry Baryshkov wrote: > > On Tue, 4 Jul 2023 at 00:40, Abhinav Kumar > > wrote: > >> > >> > >> > >> On 6/19/2023 5:08 PM, Dmitry Baryshkov wrote: > >>> DPU performance module contains code to change performance stat

Re: [PATCH 2/8] drm/msm/dpu: drop performance tuning modes

On 7/3/2023 3:20 PM, Dmitry Baryshkov wrote: On Tue, 4 Jul 2023 at 00:40, Abhinav Kumar wrote: On 6/19/2023 5:08 PM, Dmitry Baryshkov wrote: DPU performance module contains code to change performance state calculations. In addition to normal (sum plane and CRTC requirements), it can work

Re: [PATCH 2/8] drm/msm/dpu: drop performance tuning modes

On Tue, 4 Jul 2023 at 00:40, Abhinav Kumar wrote: > > > > On 6/19/2023 5:08 PM, Dmitry Baryshkov wrote: > > DPU performance module contains code to change performance state > > calculations. In addition to normal (sum plane and CRTC requirements), > > it can work in 'minimal' or 'fixed' modes. Bot

Re: [PATCH 4/8] drm/msm/dpu: rework indentation in dpu_core_perf

On 6/19/2023 5:08 PM, Dmitry Baryshkov wrote: dpu_core_perf.c contains several multi-line conditions which are hard to comprehent because of the indentation. Rework the identation of these conditions to make it easier to understand them. Signed-off-by: Dmitry Baryshkov --- I think some of

Re: [PATCH 3/8] drm/msm/dpu: drop dpu_core_perf_params::max_per_pipe_ib

On 6/19/2023 5:08 PM, Dmitry Baryshkov wrote: The max_per_pipe_ib is a constant across all CRTCs and is read from the catalog. Drop corresponding calculations and read the value directly at icc_set_bw() time. Suggested-by: Konrad Dybcio Signed-off-by: Dmitry Baryshkov --- This will need t

[PATCH 3/3] ARM: dts: exynos/i9100: Fix LCD screen's physical size

The previous values were completely bogus, and resulted in the computed DPI ratio being much lower than reality, causing applications and UIs to misbehave. Signed-off-by: Paul Cercueil Fixes: 8620cc2f99b7 ("ARM: dts: exynos: Add devicetree file for the Galaxy S2") Cc: # v5.8+ --- arch/arm/boot/

[PATCH 2/3] drm/panel: ld9040: Register a backlight device

Register a backlight device to be able to switch between all the gamma levels. Signed-off-by: Paul Cercueil --- drivers/gpu/drm/panel/panel-samsung-ld9040.c | 40 1 file changed, 40 insertions(+) diff --git a/drivers/gpu/drm/panel/panel-samsung-ld9040.c b/drivers/gpu/drm/p

[PATCH 0/3] Galaxy S2 (i9100) panel updates

Hi, Here's a small patchset that I created while playing with PostmarketOS on my Samsung Galaxy S2. The first two patches update the LD9040 panel driver so that it looks much better, and supports setting the backlight. The third patch fixes the size of the panel in the Device Tree. The previous

[PATCH 1/3] drm/panel: ld9040: Use better magic values

I have no idea what the prior magic values mean, and I have no idea what my replacement (extracted from [1]) magic values mean. What I do know, is that these new values result in a much better picture, where the blacks are really black (as you would expect on an AMOLED display) instead of grey-ish

Re: [PATCH 2/8] drm/msm/dpu: drop performance tuning modes

On 6/19/2023 5:08 PM, Dmitry Baryshkov wrote: DPU performance module contains code to change performance state calculations. In addition to normal (sum plane and CRTC requirements), it can work in 'minimal' or 'fixed' modes. Both modes are impractical, since they can easily end up with the dis

Re: [PATCH 1/8] drm/msm/dpu: drop enum dpu_core_perf_data_bus_id

On 6/19/2023 5:08 PM, Dmitry Baryshkov wrote: Drop the leftover of bus-client -> interconnect conversion, the enum dpu_core_perf_data_bus_id. Fixes: cb88482e2570 ("drm/msm/dpu: clean up references of DPU custom bus scaling") Signed-off-by: Dmitry Baryshkov --- It seems unused, hence Revi

Re: [PATCH v4 2/8] drm/atomic: Add support for mouse hotspots

On 6/29/23 01:16, Pekka Paalanen wrote: On Wed, 28 Jun 2023 16:26:37 + Zack Rusin wrote: An argument could be made that crtc x/y properties should be removed on the cursor plane in drivers for para-virtualized hardware and instead replaced with mouse_position x/y properties that do exa

Re: [PATCH v4 19/19] drm/msm/dpu: drop empty features mask INTF_SDM845_MASK

On 6/19/2023 2:25 PM, Dmitry Baryshkov wrote: The INTF_SDM845_MASK features mask is zero. Drop it completely. Reviewed-by: Marijn Suijten Tested-by: Marijn Suijten Signed-off-by: Dmitry Baryshkov --- drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 4 drivers/gpu/drm/msm/d

Re: [PATCH v4 18/19] drm/msm/dpu: drop empty features mask MERGE_3D_SM8150_MASK

On 6/19/2023 2:25 PM, Dmitry Baryshkov wrote: The MERGE_3D_SM8150_MASK features mask is zero. Drop it completely. Reviewed-by: Marijn Suijten Tested-by: Marijn Suijten Signed-off-by: Dmitry Baryshkov --- Reviewed-by: Abhinav Kumar

Re: [PATCH v4 2/8] drm/atomic: Add support for mouse hotspots

Hi, I can speak to the virtual mouse/console half of this from the VMware-side. I believe Zack's preparing a new set of comments here that can speak to most of your concerns, but I'll answer some of the other questions directly. On 6/29/23 01:03, Pekka Paalanen wrote: Is it really required

Re: [PATCH v4 17/19] drm/msm/dpu: inline INTF_BLK and INTF_BLK_DSI_TE macros

On 6/19/2023 2:25 PM, Dmitry Baryshkov wrote: To simplify making changes to the hardware block definitions, expand corresponding macros. This way making all the changes are more obvious and visible in the source files. Tested-by: Marijn Suijten Signed-off-by: Dmitry Baryshkov --- Reviewed

Re: [PATCH v4 16/19] drm/msm/dpu: inline WB_BLK macros

On 6/19/2023 2:25 PM, Dmitry Baryshkov wrote: To simplify making changes to the hardware block definitions, expand corresponding macros. This way making all the changes are more obvious and visible in the source files. Tested-by: Marijn Suijten Signed-off-by: Dmitry Baryshkov --- Reviewed

Re: [PATCH v4 15/19] drm/msm/dpu: inline various PP_BLK_* macros

On 6/19/2023 2:25 PM, Dmitry Baryshkov wrote: To simplify making changes to the hardware block definitions, expand corresponding macros. This way making all the changes are more obvious and visible in the source files. Tested-by: Marijn Suijten Signed-off-by: Dmitry Baryshkov --- Reviewed

Re: [PATCH v4 14/19] drm/msm/dpu: inline MERGE_3D_BLK macros

On 7/3/2023 1:58 PM, Dmitry Baryshkov wrote: On Mon, 3 Jul 2023 at 23:29, Abhinav Kumar wrote: On 6/19/2023 2:25 PM, Dmitry Baryshkov wrote: To simplify making changes to the hardware block definitions, expand corresponding macros. This way making all the changes are more obvious and vis

Re: [PATCH v4 14/19] drm/msm/dpu: inline MERGE_3D_BLK macros

On Mon, 3 Jul 2023 at 23:29, Abhinav Kumar wrote: > > > > On 6/19/2023 2:25 PM, Dmitry Baryshkov wrote: > > To simplify making changes to the hardware block definitions, expand > > corresponding macros. This way making all the changes are more obvious > > and visible in the source files. > > > > T

Re: [PATCH v4 14/19] drm/msm/dpu: inline MERGE_3D_BLK macros

On 6/19/2023 2:25 PM, Dmitry Baryshkov wrote: To simplify making changes to the hardware block definitions, expand corresponding macros. This way making all the changes are more obvious and visible in the source files. Tested-by: Marijn Suijten Signed-off-by: Dmitry Baryshkov --- the valu

Re: [PATCH v4] drm/vkms: Add support to 1D gamma LUT

On 02/07/23 18:37, Maira Canal wrote: > On 6/27/23 05:12, Pekka Paalanen wrote: >> On Mon, 26 Jun 2023 14:35:25 -0300 >> Maira Canal wrote: >> >>> Hi Pekka, >>> >>> On 6/26/23 05:17, Pekka Paalanen wrote: On Sat, 24 Jun 2023 18:48:08 -0300 Maira Canal wrote: > Hi Arthur,

Re: [PATCH v4 13/19] drm/msm/dpu: inline DSC_BLK and DSC_BLK_1_2 macros

On 6/27/2023 1:29 AM, Marijn Suijten wrote: On 2023-06-20 00:25:13, Dmitry Baryshkov wrote: To simplify making changes to the hardware block definitions, expand corresponding macros. This way making all the changes are more obvious and visible in the source files. Tested-by: Marijn Suijten

Re: [PATCH v4 12/19] drm/msm/dpu: inline LM_BLK macros

On 6/19/2023 2:25 PM, Dmitry Baryshkov wrote: To simplify making changes to the hardware block definitions, expand corresponding macros. This way making all the changes are more obvious and visible in the source files. Tested-by: Marijn Suijten Signed-off-by: Dmitry Baryshkov --- Same com

  1   2   >