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:
Hi Su,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on linus/master v6.4-rc7 next-20230622]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use
On (23/06/22 16:53), Qi Zheng wrote:
> +/*
> + * Remove one
> + */
> +void unregister_shrinker(struct shrinker *shrinker)
> +{
> + struct dentry *debugfs_entry;
> + int debugfs_id;
> +
> + if (!(shrinker->flags & SHRINKER_REGISTERED))
> + return;
> +
> +
Commit d4313a68ec91 ("fbdev/media: Use GPIO descriptors for VIA GPIO")
moves via-gpio.h from include/linux to drivers/video/fbdev/via, but misses
to adjust the file entry for the VIA UNICHROME(PRO)/CHROME9 FRAMEBUFFER
DRIVER section.
Hence, ./scripts/get_maintainer.pl --self-test=patterns
Hi Keith,
There is a problem with stopping when changing modes.
Below test log
root:~> modetest -Mstarfive -c
Connectors:
id encoder status namesize (mm) modes
encoders
116 115 connected HDMI-A-1320x180 51 115
modes:
On Thu, Jun 22, 2023 at 05:07:11PM +0200, Danilo Krummrich wrote:
> On 6/22/23 17:04, Danilo Krummrich wrote:
> > On 6/22/23 16:42, Christian König wrote:
> > > Am 22.06.23 um 16:22 schrieb Danilo Krummrich:
> > > > On 6/22/23 15:54, Christian König wrote:
> > > > > Am 20.06.23 um 14:23 schrieb
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
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
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
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.
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
---
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
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
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
---
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
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
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=2
in place,
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
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
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
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
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
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
deletions(-)
---
base-commit: 710025fdedb3767655823c3a12d27d404d209f75
change-id: 20230622-devcoredump_patch-df7e8f6fd632
Best regards,
--
Ryan McCann
On Thursday, June 22, 2023 11:27:29 AM PDT Lucas De Marchi wrote:
> Move helper function to get all the forcewakes required by the wa list
> to the top, so it can be re-used by other functions.
>
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 32
On Thursday, June 22, 2023 11:27:30 AM PDT Lucas De Marchi wrote:
> Most of the context workarounds tweak masked registers, but not all. For
> masked registers, when writing the value it's sufficient to just write
> the wa->set_bits since that will take care of both the clr and set bits
> as well
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
tree: git://anongit.freedesktop.org/drm/drm-misc for-linux-next-fixes
head: 4481913607e58196c48a4fef5e6f45350684ec3c
commit: 4481913607e58196c48a4fef5e6f45350684ec3c [1/1] drm/ttm: fix bulk_move
corruption when adding a entry
config: x86_64-defconfig
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
^
cc1: all warnings being treated as errors
Caused by commit
4481913607e5 ("drm/ttm: fix bulk_move corruption when adding a entry")
I have used the drm-misc-fixes tree from next-20230622 for today.
--
Cheers,
Stephen Rothwell
pgpacjLilcN_V.pgp
Description: OpenPGP digital signature
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
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)
+
> The previouse i915_gem_object_create_internal already set it with proper
> value before function return. This hard coded setting is incorrect for
> platforms like MTL, thus need to be removed.
>
> Signed-off-by: Zhanjun Dong
> ---
> drivers/gpu/drm/i915/gt/intel_timeline.c | 2 --
> 1 file
Hi Vivek,
kernel test robot noticed the following build warnings:
[auto build test WARNING on akpm-mm/mm-everything]
[also build test WARNING on linus/master next-20230622]
[cannot apply to drm-misc/drm-misc-next drm-tip/drm-tip v6.4-rc7]
[If your patch is applied to the wrong git tree, kindly
There is apparently no reasons to open-code of_device_uevent() besides:
- The helper receives a struct device while we want to use the of_node
member of the struct device *parent*.
- of_device_uevent() could not be called by modules because of a missing
EXPORT_SYMBOL*().
In practice, the
My previous attempt to slightly clean the OF core wrt device structures
was rather unsuccessful as the idea behind the discussed cleanup was
more impacting than what I thought, leading to most of the previous
series to be dropped. However, aside, two patches seemed actually
relevant, so here they
The content of of_device_uevent() is currently hardcoded in a driver
that can be compiled as a module. Nothing prevents of_device_uevent() to
be exported to modules, most of the other helpers in of/device.c
actually are. The reason why this helper was not exported is because it
has been so far
Hi Rob,
r...@kernel.org wrote on Thu, 22 Jun 2023 08:31:40 -0600:
> On Fri, Jun 09, 2023 at 05:56:34PM +0200, Miquel Raynal wrote:
> > There is apparently no reasons to open-code of_device_uevent() besides:
> > - The helper receives a struct device while we want to use the of_node
> > member
On Wed, Jun 21, 2023 at 01:50:34PM -0500, Limonciello, Mario wrote:
> So if we go down this path of CONFIG_WBRF and CONFIG_WBRF_ACPI, another
> question would be where should the new "wbrf.c" be stored? The ACPI only
> version most certainly made sense in drivers/acpi/wbrf.c, but a generic
>
On 4/25/23 21:29, Dave Airlie wrote:
> 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:
On 4/25/23 21:29, Dave Airlie wrote:
> From: Dave Airlie
>
> This adds a tag that will go into the module info, only one firmware from
> the group given needs to be available for this driver to work. This allows
> dracut to avoid adding in firmware that aren't needed.
>
> This just brackets
Hi,
On 2023/6/8 15:39, Maxime Ripard wrote:
On Thu, Jun 08, 2023 at 01:18:38AM +0800, Sui Jingfeng wrote:
Hi,
On 2023/6/8 00:12, Paul Cercueil wrote:
Hi Sui,
Le mercredi 07 juin 2023 à 22:38 +0800, Sui Jingfeng a écrit :
Hi, welcome to discussion.
I have limited skills in manipulating
On 6/21/2023 8:55 PM, Andrew Lunn wrote:
Honestly I'm not sure though we need this complexity right now? I mean,
it'd be really easy to replace the calls in mac80211 with some other
more generalised calls in the future?
You need some really deep platform/hardware level knowledge and
Hi
On 2023/6/21 23:58, Lucas Stach wrote:
Am Mittwoch, dem 21.06.2023 um 23:30 +0800 schrieb Sui Jingfeng:
Hi,
On 2023/6/21 18:00, Lucas Stach wrote:
dma_sync_sgtable_for_cpu(dev->dev, etnaviv_obj->sgt,
etnaviv_op_to_dma_dir(op));
On Thu, Jun 22, 2023 at 09:27:14AM -0700, Alan Previn wrote:
> In the ABI header, GUC_CTB_MSG_MIN_LEN is '1' because
> GUC_CTB_HDR_LEN is 1. This aligns with H2G/G2H CTB specification
> where all command formats are defined in units of dwords so that '1'
> is a dword. Accordingly,
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
---
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?
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
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
Move helper function to get all the forcewakes required by the wa list
to the top, so it can be re-used by other functions.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 32 ++---
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git
Now that non-masked registers are already read before programming the
context reads, the additional read became redudant, so remove it.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git
Most of the context workarounds tweak masked registers, but not all. For
masked registers, when writing the value it's sufficient to just write
the wa->set_bits since that will take care of both the clr and set bits
as well as not overwriting other bits.
However there are some workarounds, the
On Fri, 02 Jun 2023 00:40:34 PDT (-0700), keith.z...@starfivetech.com wrote:
Hi,
This series is a DRM driver for StarFive SoC JH7110, which includes a
display controller driver for Verisilicon DC8200 and an HMDI driver.
We use GEM framework for buffer management and allocate memory by
using
On 6/22/23 17:15, Laurent Pinchart wrote:
Hi Geert,
Thank you for the patch.
On Thu, Jun 22, 2023 at 11:28:48AM +0200, Geert Uytterhoeven wrote:
When configurating a CHn Source Image Format Register (LDBBSIFR), one
should use the corresponding LDBBSIFR_RPKF_* definition for overlay
planes,
On 6/22/23 18:46, Gustavo A. R. Silva wrote:
Fix the following fallthrough warnings seen after building sh
architecture with sh7763rdp_defconfig configuration:
drivers/video/fbdev/sh7760fb.c: In function 'sh7760fb_get_color_info':
drivers/video/fbdev/sh7760fb.c:138:23: warning: this statement
Cybernet T10C cannot be dimmed without the backlight strobing. Create a
new quirk to lock the minimum brightness to the highest supported value.
This aligns the device with its behavior on Windows, which will not
lower the brightness below maximum.
Signed-off-by: Allen Ballway
---
V1 -> V2: Fix
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
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
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:
On 2023-06-22 05:56, Boris Brezillon wrote:
> On Wed, 21 Jun 2023 11:03:48 -0400
> Luben Tuikov wrote:
>
>> On 2023-06-21 10:53, Boris Brezillon wrote:
>>> On Wed, 21 Jun 2023 10:41:22 -0400
>>> Luben Tuikov wrote:
>>>
On 2023-06-21 10:18, Boris Brezillon wrote:
> Hello Luben,
On 6/22/23 16:48, Christian König wrote:
Am 22.06.23 um 16:08 schrieb Thomas Hellström:
On 6/22/23 15:55, Andi Shyti wrote:
Hi Thomas,
On Thu, Jun 22, 2023 at 12:14:11PM +0200, Thomas Hellström wrote:
On eviction errors other than -EMULTIHOP we were leaking a resource.
Fix.
Fixes:
Fix the following fallthrough warnings seen after building sh
architecture with sh7763rdp_defconfig configuration:
drivers/video/fbdev/sh7760fb.c: In function 'sh7760fb_get_color_info':
drivers/video/fbdev/sh7760fb.c:138:23: warning: this statement may fall through
[-Wimplicit-fallthrough=]
In the ABI header, GUC_CTB_MSG_MIN_LEN is '1' because
GUC_CTB_HDR_LEN is 1. This aligns with H2G/G2H CTB specification
where all command formats are defined in units of dwords so that '1'
is a dword. Accordingly, GUC_CTB_MSG_MAX_LEN is 256-1 (i.e. 255
dwords). However, h2g_write was incorrectly
On Wed, Jun 21, 2023 at 03:36:59PM +0200, Christian König wrote:
> This adds the infrastructure for an execution context for GEM buffers
> which is similar to the existing TTMs execbuf util and intended to replace
> it in the long term.
>
> The basic functionality is that we abstracts the
Hi,
I know something about this patch:
On 2023/6/21 20:53, Thomas Zimmermann wrote:
Access to I/O registers is required to detect and set up the
device. Enable the rsp PCI config bits before. While at it,
convert the magic number to macro constants.
Enabling the PCI config bits was done
Resend to restart the CI,
https://patchwork.freedesktop.org/series/119485/
Was stuck.
Regards,
Zhanjun
On 2023-06-22 11:26 a.m., Zhanjun Dong wrote:
The previouse i915_gem_object_create_internal already set it with proper
value before function return. This hard coded setting is incorrect
On 6/22/23 17:19, Boris Brezillon wrote:
Hi Danilo,
On Thu, 22 Jun 2023 15:58:23 +0200
Danilo Krummrich wrote:
Hi Boris,
On 6/22/23 15:01, Boris Brezillon wrote:
Hi Danilo,
On Tue, 20 Jun 2023 14:46:07 +0200
Danilo Krummrich wrote:
The only thing I'm worried about is the 'sync
The previouse i915_gem_object_create_internal already set it with proper
value before function return. This hard coded setting is incorrect for
platforms like MTL, thus need to be removed.
Signed-off-by: Zhanjun Dong
---
drivers/gpu/drm/i915/gt/intel_timeline.c | 2 --
1 file changed, 2
https://bugzilla.kernel.org/show_bug.cgi?id=217587
Bug ID: 217587
Summary: amdgpu kernel NULL pointer dereference, address:
0054
Product: Drivers
Version: 2.5
Hardware: AMD
OS: Linux
Hi,
On 2023/6/21 20:53, Thomas Zimmermann wrote:
Detection of the configuration mode and the chipset model are
linked to each other. One uses values from the other; namely the
PCI device revision and the SCU revision. Merge this code into
a single function.
Signed-off-by: Thomas Zimmermann
Hi Danilo,
On Thu, 22 Jun 2023 15:58:23 +0200
Danilo Krummrich wrote:
> Hi Boris,
>
> On 6/22/23 15:01, Boris Brezillon wrote:
> > Hi Danilo,
> >
> > On Tue, 20 Jun 2023 14:46:07 +0200
> > Danilo Krummrich wrote:
> >
> >>> The only thing I'm worried about is the 'sync mapping requests
Hi Geert,
Thank you for the patch.
On Thu, Jun 22, 2023 at 11:28:48AM +0200, Geert Uytterhoeven wrote:
> When configurating a CHn Source Image Format Register (LDBBSIFR), one
> should use the corresponding LDBBSIFR_RPKF_* definition for overlay
> planes, not the DDFR_PKF_* definition for the
On 6/22/23 10:53, Qi Zheng wrote:
> The shrinker_rwsem is a global read-write lock in
> shrinkers subsystem, which protects most operations
> such as slab shrink, registration and unregistration
> of shrinkers, etc. This can easily cause problems in
> the following cases.
>
> 1) When the memory
Hi,
On 2023/6/21 20:53, Thomas Zimmermann wrote:
ASpeed distinguishes among various generations of the AST graphics
chipset with various models. [1] The most-recent model AST 2600 is
of the 7th generation, the AST 2500 is of the 6th generation, and so
on.
The ast driver simply picks one of the
On 6/22/23 17:04, Danilo Krummrich wrote:
On 6/22/23 16:42, Christian König wrote:
Am 22.06.23 um 16:22 schrieb Danilo Krummrich:
On 6/22/23 15:54, Christian König wrote:
Am 20.06.23 um 14:23 schrieb Danilo Krummrich:
Hi Christian,
On 6/20/23 08:45, Christian König wrote:
Hi Danilo,
sorry
On 6/22/23 16:42, Christian König wrote:
Am 22.06.23 um 16:22 schrieb Danilo Krummrich:
On 6/22/23 15:54, Christian König wrote:
Am 20.06.23 um 14:23 schrieb Danilo Krummrich:
Hi Christian,
On 6/20/23 08:45, Christian König wrote:
Hi Danilo,
sorry for the delayed reply. I've trying to dig
+ Rasmus Villemoes
> > -#define __GENMASK(h, l) \
> > - (((~UL(0)) - (UL(1) << (l)) + 1) & \
> > -(~UL(0) >> (BITS_PER_LONG - 1 - (h
> > -#define GENMASK(h, l) \
> > - (GENMASK_INPUT_CHECK(h, l) + __GENMASK(h, l))
> > +#define __GENMASK(t, h, l) \
> > + (GENMASK_INPUT_CHECK(h, l) +
On 6/22/23 10:53, Qi Zheng wrote:
> The mm/vmscan.c file is too large, so separate the shrinker-related
> code from it into a separate file. No functional changes.
>
> Signed-off-by: Qi Zheng
Maybe do this move as patch 01 so the further changes are done in the new
file already?
On Thu, Jun 22, 2023 at 11:21:13AM +0200, Geert Uytterhoeven wrote:
> Add device tree bindings for the LCD Controller (LCDC) found in Renesas
> SuperH SH-Mobile and ARM SH/R-Mobile SOCs.
>
> Based on a plain text prototype by Laurent Pinchart.
>
> Signed-off-by: Geert Uytterhoeven
> Cc: Rob
Am 22.06.23 um 16:08 schrieb Thomas Hellström:
On 6/22/23 15:55, Andi Shyti wrote:
Hi Thomas,
On Thu, Jun 22, 2023 at 12:14:11PM +0200, Thomas Hellström wrote:
On eviction errors other than -EMULTIHOP we were leaking a resource.
Fix.
Fixes: 403797925768 ("drm/ttm: Fix multihop assert on
On 6/22/23 10:53, Qi Zheng wrote:
> 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
[Public]
Hmm, seems all the stack trace I get now are from amdgpu_gem_va_ioctl, so I
suppose the issue is only on that path now, the gang submit patch fixed it for
amdgpu_cs_ioctl.
Teddy
-Original Message-
From: Li, Yunxiang (Teddy)
Sent: Thursday, June 22, 2023 10:12
To: Koenig,
Alex, Luben or somebody else at least a bit familiar with that, can I
get a quick rb or acked-by?
This is an important bug fix for Android CTS.
Thanks,
Christian.
Am 21.06.23 um 09:32 schrieb Christian König:
Some Android CTS is testing for that.
Signed-off-by: Christian König
CC:
Am 22.06.23 um 16:22 schrieb Danilo Krummrich:
On 6/22/23 15:54, Christian König wrote:
Am 20.06.23 um 14:23 schrieb Danilo Krummrich:
Hi Christian,
On 6/20/23 08:45, Christian König wrote:
Hi Danilo,
sorry for the delayed reply. I've trying to dig myself out of a
hole at the moment.
No
On 6/22/23 15:55, Andi Shyti wrote:
Hi Thomas,
On Thu, Jun 22, 2023 at 12:14:11PM +0200, Thomas Hellström wrote:
On eviction errors other than -EMULTIHOP we were leaking a resource.
Fix.
Fixes: 403797925768 ("drm/ttm: Fix multihop assert on eviction.")
Cc: Andrey Grodzovsky
Cc: Christian
On Fri, Jun 09, 2023 at 05:56:34PM +0200, Miquel Raynal wrote:
> There is apparently no reasons to open-code of_device_uevent() besides:
> - The helper receives a struct device while we want to use the of_node
> member of the struct device *parent*.
> - of_device_uevent() could not be called by
When the resource is the first in the bulk_move range, adding it again
(thus moving it to the tail) will corrupt the list since the first
pointer is not moved. This eventually lead to null pointer deref in
ttm_lru_bulk_move_del()
Fixes: fee2ede15542 ("drm/ttm: rework bulk move handling v5")
On 6/22/23 15:54, Christian König wrote:
Am 20.06.23 um 14:23 schrieb Danilo Krummrich:
Hi Christian,
On 6/20/23 08:45, Christian König wrote:
Hi Danilo,
sorry for the delayed reply. I've trying to dig myself out of a hole
at the moment.
No worries, thank you for taking a look anyway!
[Public]
If I take out this reserve and the change that makes dma_resv_reserve_fences
nestable, I get a BUG in the add_fence, so we might be missing a reserve
somewhere else then.
Teddy
-Original Message-
From: Koenig, Christian
Sent: Thursday, June 22, 2023 3:39
To: Li, Yunxiang
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
Hi Boris,
On 6/22/23 15:01, Boris Brezillon wrote:
Hi Danilo,
On Tue, 20 Jun 2023 14:46:07 +0200
Danilo Krummrich wrote:
The only thing I'm worried about is the 'sync mapping requests have to
go through the async path and wait for all previous async requests to
be processed' problem I
Hi Thomas,
On Thu, Jun 22, 2023 at 12:14:12PM +0200, Thomas Hellström wrote:
> If moving the bo to system for swapout failed, we were leaking
> a resource. Fix.
>
> Fixes: bfa3357ef9ab ("drm/ttm: allocate resource object instead of embedding
> it v2")
> Cc: Christian König
> Cc: "Christian
Hi Thomas,
On Thu, Jun 22, 2023 at 12:14:11PM +0200, Thomas Hellström wrote:
> On eviction errors other than -EMULTIHOP we were leaking a resource.
> Fix.
>
> Fixes: 403797925768 ("drm/ttm: Fix multihop assert on eviction.")
> Cc: Andrey Grodzovsky
> Cc: Christian König
> Cc: Christian Koenig
Am 20.06.23 um 14:23 schrieb Danilo Krummrich:
Hi Christian,
On 6/20/23 08:45, Christian König wrote:
Hi Danilo,
sorry for the delayed reply. I've trying to dig myself out of a hole
at the moment.
No worries, thank you for taking a look anyway!
Am 20.06.23 um 02:42 schrieb Danilo
Hi Arnd,
On Thu, Jun 22, 2023 at 12:18:41PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The mchbar_addr variable is only used inside of an #ifdef:
>
> drivers/gpu/drm/i915/soc/intel_gmch.c:41:6: error: variable 'mchbar_addr' set
> but not used [-Werror,-Wunused-but-set-variable]
>
Hi,
Ah, I forgot to check that before send a patch, sorry for the noise :-)
On 2023/6/22 20:35, Jocelyn Falempe wrote:
This patch was already sent by Tom Rix last month:
https://patchwork.freedesktop.org/series/117881/
I can push it to drm-misc-next, if Thomas is ok.
That sounds fine.
On 6/21/23 15:41, Arthur Grillo wrote:
> Support a 1D gamma LUT with interpolation for each color channel on the
> VKMS driver. Add a check for the LUT length by creating
> vkms_atomic_check().
>
> Tested with:
> igt@kms_color@gamma
> igt@kms_color@legacy-gamma
>
1 - 100 of 204 matches
Mail list logo
