I'll remove the unnecessary braces and resend the patch.
Regards,
Shresth
On Wed, May 1, 2024 at 7:49 PM Julia Lawall wrote:
>
>
>
> On Wed, 1 May 2024, Daniel Thompson wrote:
>
> > On Wed, May 01, 2024 at 06:21:46PM +0530, R Sundar wrote:
> > > Use the new cleanup magic to replace
`dev->of_node` already has a reference to the device_node and calling
of_node_get on it is unnecessary. All conresponding calls to
of_node_put are also removed.
Reviewed-by: Daniel Thompson
Signed-off-by: Shresth Prasad
---
Changes in v3:
- Remove unnecessary braces
On Wed, 24 Apr 2024, Krzysztof Kozlowski wrote:
> Hi,
>
> Changes in v2:
> - Collect tags, including wrongly places Thomas' tag (which requires me
> to manually edit 15 other patches to drop it).
> - Combine here checkpatch patch:
>
On 30/04/2024 14:58, Daniel Vetter wrote:
On Fri, Apr 19, 2024 at 03:20:19PM +0200, Jocelyn Falempe wrote:
drm_panic has been introduced recently, and uses the same fonts as
FRAMEBUFFER_CONSOLE.
Signed-off-by: Jocelyn Falempe
Acked-by: Daniel Vetter
lib/fonts/ doesn't seem to have a
On 02/05/2024 09:22, Lee Jones wrote:
> On Wed, 24 Apr 2024, Krzysztof Kozlowski wrote:
>
>> Hi,
>>
>> Changes in v2:
>> - Collect tags, including wrongly places Thomas' tag (which requires me
>> to manually edit 15 other patches to drop it).
>> - Combine here checkpatch patch:
>>
On Thu, May 02, 2024 at 09:34:17AM +0200, Neil Armstrong wrote:
> On 30/04/2024 11:34, Maxime Ripard wrote:
...
> Anyway since the rant is finished I'll land the patches.
Thank you all for the review and discussion!
--
With Best Regards,
Andy Shevchenko
On Thu, May 02, 2024 at 09:43:42AM +0200, Neil Armstrong wrote:
> Hi,
>
> On Thu, 25 Apr 2024 17:26:16 +0300, Andy Shevchenko wrote:
> > A few obvious fixes to the driver.
> >
> > Andy Shevchenko (3):
> > drm/panel: ili9341: Correct use of device property APIs
> > drm/panel: ili9341: Respect
On Wed, May 01, 2024 at 12:27:14AM +0800, Sui Jingfeng wrote:
> On 2024/4/30 22:13, Andy Shevchenko wrote:
> > On Fri, Apr 26, 2024 at 05:13:43AM +0800, Sui Jingfeng wrote:
...
> > the former might be subdivided to "is it swnode backed or real fwnode one?"
> >
> Yeah,
> On non-DT cases, it can
On 30/04/2024 12:37, Boris Brezillon wrote:
> In the post_reset function, if the fast reset didn't succeed, we
> are not clearing the fast_reset flag, which prevents firmware
> sections from being reloaded. While at it, use panthor_fw_stop()
> instead of manually writing DISABLE to the MCU_CONTROL
On Thu, 02 May 2024, Shresth Prasad wrote:
> `dev->of_node` already has a reference to the device_node and calling
> of_node_get on it is unnecessary. All conresponding calls to
> of_node_put are also removed.
>
> Reviewed-by: Daniel Thompson
> Signed-off-by: Shresth Prasad
> ---
> Changes in
From: Hsiao Chien Sung
Add OVL compatible name for MT8195.
Without this commit, DRM won't work after modifying the device tree.
Reviewed-by: CK Hu
Reviewed-by: AngeloGioacchino Del Regno
Signed-off-by: Hsiao Chien Sung
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 ++
1 file changed, 2
From: Hsiao Chien Sung
We found that IGT (Intel GPU Tool) will try to commit layers with
zero width or height and lead to undefined behaviors in hardware.
Disable the layers in such a situation.
Fixes: 777b7bc86a0a ("UPSTREAM: drm/mediatek: Add ovl_adaptor support for
MT8195")
Fixes:
From: Hsiao Chien Sung
Support constant alpha blending in OVL.
Signed-off-by: Hsiao Chien Sung
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
From: Hsiao Chien Sung
Support RGBA and RGBX formats in OVL.
Signed-off-by: Hsiao Chien Sung
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index
Am 30.04.24 um 19:38 schrieb Easwar Hariharan:
I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
with more appropriate terms. Inspired by and following on to Wolfram's
series to fix drivers/i2c/[1], fix the terminology for users of
I2C_ALGOBIT bitbanging interface,
Am 30.04.24 um 19:38 schrieb Easwar Hariharan:
I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
with more appropriate terms. Inspired by and following on to Wolfram's
series to fix drivers/i2c/[1], fix the terminology for users of
I2C_ALGOBIT bitbanging interface,
Am 30.04.24 um 19:38 schrieb Easwar Hariharan:
I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
with more appropriate terms. Inspired by and following on to Wolfram's
series to fix drivers/i2c/[1], fix the terminology for users of
I2C_ALGOBIT bitbanging interface,
On 01/05/2024 17:41, Douglas Anderson wrote:
We really don't expect these errors to be printed over and over
again. When a driver hits the error it should bail out. Just use a
normal error print.
This gives a nice space savings for users of these functions:
$ scripts/bloat-o-meter \
On 01/05/2024 17:41, Douglas Anderson wrote:
The mipi_dsi_dcs_write_seq() macro makes a call to
mipi_dsi_dcs_write_buffer() which returns a type ssize_t. The macro
then stores it in an int and checks to see if it's negative. This
could theoretically be a problem if "ssize_t" is larger than
On 01/05/2024 17:41, Douglas Anderson wrote:
The mipi_dsi_generic_write_seq() macro makes a call to
mipi_dsi_generic_write() which returns a type ssize_t. The macro then
stores it in an int and checks to see if it's negative. This could
theoretically be a problem if "ssize_t" is larger than
On Tue, Apr 30, 2024 at 09:09:15PM -0300, Jason Gunthorpe wrote:
> On Tue, Apr 30, 2024 at 08:57:48PM +0200, Daniel Vetter wrote:
> > On Tue, Apr 30, 2024 at 02:30:02PM -0300, Jason Gunthorpe wrote:
> > > On Mon, Apr 29, 2024 at 10:25:48AM +0200, Thomas Hellström wrote:
> > >
> > > > > Yes there
On Thu, May 2, 2024 at 5:03 PM Hsin-Te Yuan wrote:
>
> The anx7625 supports two different TDM settings, which determine whether
> or not the first audio data bit should be shifted. This series adds the
> support for configuring TDM setting through a property in the device
> tree.
As mentioned
The display IPs in MediaTek SoCs support being interconnected with
different instances of DDP IPs (for example, merge0 or merge1) and/or
with different DDP IPs (for example, rdma can be connected with either
color, dpi, dsi, merge, etc), forming a full Display Data Path that
ends with an actual
Document OF graph on MMSYS/VDOSYS: this supports up to three DDP paths
per HW instance (so potentially up to six displays for multi-vdo SoCs).
The MMSYS or VDOSYS is always the first component in the DDP pipeline,
so it only supports an output port with multiple endpoints - where each
endpoint
It is impossible to add each and every possible DDP path combination
for each and every possible combination of SoC and board: right now,
this driver hardcodes configuration for 10 SoCs and this is going to
grow larger and larger, and with new hacks like the introduction of
mtk_drm_route which is
Changes in v3:
- Rebased on next-20240502 because of renames in mediatek-drm
Changes in v2:
- Fixed wrong `required` block indentation in commit [2/3]
The display IPs in MediaTek SoCs are *VERY* flexible and those support
being interconnected with different instances of DDP IPs (for example
On Wed, 24 Apr 2024, Krzysztof Kozlowski wrote:
> 'struct lcd_ops' is not modified by core code.
>
> Suggested-by: Thomas Weißschuh
> Signed-off-by: Krzysztof Kozlowski
>
> ---
>
> Patch making lcd_ops const in progress:
>
Hi,
On Thu, 25 Apr 2024 17:26:16 +0300, Andy Shevchenko wrote:
> A few obvious fixes to the driver.
>
> Andy Shevchenko (3):
> drm/panel: ili9341: Correct use of device property APIs
> drm/panel: ili9341: Respect deferred probe
> drm/panel: ili9341: Use predefined error codes
>
> [...]
Hi,
On 01/05/2024 17:41, Douglas Anderson wrote:
The consensus of many DRM folks is that we want to move away from DSI
drivers defining tables of init commands. Instead, we want to move to
init functions that can use common DRM functions. The issue thus far
has been that using the macros
Hi,
On Wed, 01 May 2024 13:24:02 +0800, Sui Jingfeng wrote:
> Because the else clause after the return clause is not useful, remove it
> to get a better look.
>
>
Thanks, Applied to https://gitlab.freedesktop.org/drm/misc/kernel.git
(drm-misc-next)
[1/1] drm/panel: ili9341: Remove a
Il 25/04/24 04:23, CK Hu (胡俊光) ha scritto:
Hi, Angelo:
On Tue, 2024-04-09 at 14:02 +0200, AngeloGioacchino Del Regno wrote:
Document OF graph on MMSYS/VDOSYS: this supports up to three DDP
paths
per HW instance (so potentially up to six displays for multi-vdo
SoCs).
The MMSYS or VDOSYS is
Hi
Am 01.05.24 um 08:55 schrieb Adrián Larumbe:
When Panfrost must pin an object that is being prepared a dma-buf
attachment for on behalf of another driver, the core drm gem object pinning
code already takes a lock on the object's dma reservation.
However, Panfrost GEM object's pinning
Hi,
Although I haven't had a chance yet to eye through the current code,
some comments along the way.
On Thu, 2024-05-02 at 10:04 +0200, Daniel Vetter wrote:
> On Tue, Apr 30, 2024 at 09:09:15PM -0300, Jason Gunthorpe wrote:
> > On Tue, Apr 30, 2024 at 08:57:48PM +0200, Daniel Vetter wrote:
> >
Hi,
ignoring my r-b on patch 1, I'd like to rethink the current patches in
general.
I think drm_gem_shmem_pin() should become the locked version of _pin(),
so that drm_gem_shmem_object_pin() can call it directly. The existing
_pin_unlocked() would not be needed any longer. Same for the
On Tue, Apr 30, 2024 at 01:37:27PM +0200, Boris Brezillon wrote:
> In the post_reset function, if the fast reset didn't succeed, we
> are not clearing the fast_reset flag, which prevents firmware
> sections from being reloaded. While at it, use panthor_fw_stop()
> instead of manually writing
On Thu, May 2, 2024 at 3:06 PM Lee Jones wrote:
>
> On Thu, 02 May 2024, Shresth Prasad wrote:
>
> > `dev->of_node` already has a reference to the device_node and calling
> > of_node_get on it is unnecessary. All conresponding calls to
> > of_node_put are also removed.
> >
> > Reviewed-by: Daniel
Hi, Matt, Christian,
On Wed, 2024-04-17 at 08:09 +0200, Christian König wrote:
> Am 17.04.24 um 03:15 schrieb Matthew Brost:
> > On Tue, Apr 16, 2024 at 12:07:22PM +0200, Thomas Hellström wrote:
> > > To be able to handle list unlocking while traversing the LRU
> > > list, we want the iterators
On Wed, May 1, 2024 at 5:43 PM Douglas Anderson wrote:
> The mipi_dsi_dcs_write_seq() macro makes a call to
> mipi_dsi_dcs_write_buffer() which returns a type ssize_t. The macro
> then stores it in an int and checks to see if it's negative. This
> could theoretically be a problem if "ssize_t" is
On Wed, May 1, 2024 at 5:43 PM Douglas Anderson wrote:
> The mipi_dsi_generic_write_seq() macro makes a call to
> mipi_dsi_generic_write() which returns a type ssize_t. The macro then
> stores it in an int and checks to see if it's negative. This could
> theoretically be a problem if "ssize_t"
On Wed, May 1, 2024 at 5:43 PM Douglas Anderson wrote:
> We really don't expect these errors to be printed over and over
> again. When a driver hits the error it should bail out. Just use a
> normal error print.
>
> This gives a nice space savings for users of these functions:
>
> $
The anx7625 supports two different TDM settings, which determine whether
or not the first audio data bit should be shifted. This series adds the
support for configuring TDM setting through a property in the device
tree.
Signed-off-by: Hsin-Te Yuan
---
Hsin-Te Yuan (2):
dt-bindings:
Add a perporty to indicate whether anx7625 should shift the first audio
data bit. The default TDM setting is to shift the first audio data bit.
Signed-off-by: Hsin-Te Yuan
---
.../devicetree/bindings/display/bridge/analogix,anx7625.yaml | 4
1 file changed, 4 insertions(+)
diff
For some SoCs, the TDM setting is not to shift the first audio data bit,
which is not the default setting of anx7625. In such cases, the TDM
setting should be changed according to the device tree property.
Signed-off-by: Hsin-Te Yuan
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 8
Hi
Am 02.05.24 um 14:00 schrieb Boris Brezillon:
On Thu, 2 May 2024 13:59:41 +0200
Boris Brezillon wrote:
Hi Thomas,
On Thu, 2 May 2024 13:51:16 +0200
Thomas Zimmermann wrote:
Hi,
ignoring my r-b on patch 1, I'd like to rethink the current patches in
general.
I think
On Wed, 1 May 2024 07:56:00 +0100
Adrián Larumbe wrote:
> Commit ec144244a43f ("drm/gem-shmem: Acquire reservation lock in GEM
> pin/unpin callbacks") moved locking DRM object's dma reservation to
> drm_gem_shmem_object_pin, and made drm_gem_shmem_pin_locked public, so we
> need to make sure
On 30/04/2024 11:34, Maxime Ripard wrote:
On Tue, Apr 30, 2024 at 12:54:39AM +0800, Sui Jingfeng wrote:
On 2024/4/29 19:55, Maxime Ripard wrote:
On Sat, Apr 27, 2024 at 01:57:46PM +0800, Sui Jingfeng wrote:
On 2024/4/26 14:23, Maxime Ripard wrote:
On Fri, Apr 26, 2024 at 04:43:18AM +0800,
Hi Jason,
>
> On Tue, Apr 30, 2024 at 04:24:50PM -0600, Alex Williamson wrote:
> > > +static vm_fault_t vfio_pci_dma_buf_fault(struct vm_fault *vmf)
> > > +{
> > > + struct vm_area_struct *vma = vmf->vma;
> > > + struct vfio_pci_dma_buf *priv = vma->vm_private_data;
> > > + pgoff_t pgoff =
On Wed, May 01, 2024 at 07:50:43PM +0100, Adrián Larumbe wrote:
> Up to this day, all fdinfo-based GPU profilers must traverse the entire
> /proc directory structure to find open DRM clients with fdinfo file
> descriptors. This is inefficient and time-consuming.
>
> This patch adds a new DRM
On Wed, May 1, 2024 at 5:43 PM Douglas Anderson wrote:
> Through a cooperative effort between Hsin-Yi Wang and Dmitry
> Baryshkov, we have realized the dev_err() in the
> mipi_dsi_*_write_seq() macros was causing quite a bit of bloat to the
> kernel. Let's hoist this call into drm_mipi_dsi.c by
On Thu, 02 May 2024, Shresth Prasad wrote:
> On Thu, May 2, 2024 at 3:06 PM Lee Jones wrote:
> >
> > On Thu, 02 May 2024, Shresth Prasad wrote:
> >
> > > `dev->of_node` already has a reference to the device_node and calling
> > > of_node_get on it is unnecessary. All conresponding calls to
> > >
From: Hsiao Chien Sung
Support more 10bit formats in OVL.
Signed-off-by: Hsiao Chien Sung
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 32 ++---
1 file changed, 29 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
From: Hsiao Chien Sung
Fix an issue that plane coordinate was not saved when
calling async update.
Fixes: 920fffcc8912 ("drm/mediatek: update cursors by using async atomic
update")
Reviewed-by: CK Hu
Reviewed-by: AngeloGioacchino Del Regno
Signed-off-by: Hsiao Chien Sung
---
From: Hsiao Chien Sung
Support "Pre-multiplied" and "None" blend mode on MediaTek's chips by
adding correct blend mode property when the planes init.
Before this patch, only the "Coverage" mode (default) is supported.
For more information, there are three pixel blend modes in DRM driver:
From: Hsiao Chien Sung
Support "Pre-multiplied" alpha blending mode on in OVL.
Before this patch, only the "coverage" mode is supported.
Signed-off-by: Hsiao Chien Sung
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 41 +
1 file changed, 35 insertions(+), 6 deletions(-)
From: Hsiao Chien Sung
Support constant blending in Mixer.
Signed-off-by: Hsiao Chien Sung
---
drivers/gpu/drm/mediatek/mtk_ethdr.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_ethdr.c
b/drivers/gpu/drm/mediatek/mtk_ethdr.c
From: Hsiao Chien Sung
ETHDR 9-bit alpha should be disabled by default,
otherwise alpha blending will not work.
Reviewed-by: AngeloGioacchino Del Regno
Signed-off-by: Hsiao Chien Sung
---
drivers/soc/mediatek/mtk-mmsys.c | 1 +
1 file changed, 1 insertion(+)
diff --git
From: Hsiao Chien Sung
Support "None" alpha blending mode on MediaTek's chips.
Signed-off-by: Hsiao Chien Sung
---
drivers/gpu/drm/mediatek/mtk_ethdr.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_ethdr.c
From: Hsiao Chien Sung
Register CRC related function pointers to support
CRC retrieval.
Signed-off-by: Hsiao Chien Sung
---
drivers/gpu/drm/mediatek/mtk_crtc.c | 260
drivers/gpu/drm/mediatek/mtk_crtc.h | 38
drivers/gpu/drm/mediatek/mtk_ddp_comp.h | 3
From: Hsiao Chien Sung
We choose OVL as the CRC generator from other hardware
components that are also capable of calculating CRCs,
since its frame done event triggers vblanks, it can be
used as a signal to know when is safe to retrieve CRC of
the frame.
Please note that position of the
From: Hsiao Chien Sung
Always add DRM_MODE_ROTATE_0 to rotation property to meet
IGT's (Intel GPU Tools) requirement.
Reviewed-by: CK Hu
Reviewed-by: AngeloGioacchino Del Regno
Signed-off-by: Hsiao Chien Sung
---
drivers/gpu/drm/mediatek/mtk_ddp_comp.h | 6 +-
From: Hsiao Chien Sung
Set DRM mode configs limitation according to the hardware capabilities
and pass the IGT checks as below:
- The test "graphics.IgtKms.kms_plane" requires a frame buffer with
width of 4512 pixels (> 4096).
- The test "graphics.IgtKms.kms_cursor_crc" checks if the cursor
From: Hsiao Chien Sung
Support "None" alpha blending mode on MediaTek's chips.
Signed-off-by: Hsiao Chien Sung
Reviewed-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
From: Hsiao Chien Sung
Support "Pre-multiplied" alpha blending mode in Mixer.
Before this patch, only the coverage mode is supported.
Signed-off-by: Hsiao Chien Sung
---
drivers/gpu/drm/mediatek/mtk_ethdr.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git
From: Hsiao Chien Sung
This series is based on 20240307013458.23550-1-jason-jh@mediatek.com
This series adds support for running IGT (Intel GPU Tool) tests
with MediaTek display driver. The following changes will be
applied:
1. Add a new API for creating GCE thread loop to retrieve CRCs
From: Hsiao Chien Sung
We choose Mixer as CRC generator in OVL adaptor since
its frame done event will trigger vblanks, we can know
when is safe to retrieve CRC of the frame.
In OVL adaptor, there's no image procession after Mixer,
unlike the OVL in VDOSYS0, Mixer's CRC will include all
the
On Wed, 1 May 2024 07:55:59 +0100
Adrián Larumbe wrote:
> When Panfrost must pin an object that is being prepared a dma-buf
> attachment for on behalf of another driver, the core drm gem object pinning
> code already takes a lock on the object's dma reservation.
>
> However, Panfrost GEM
On 01/05/2024 17:41, Douglas Anderson wrote:
The current mipi_dsi_*_write_seq() macros are non-intutitive because
they contain a hidden "return" statement that will return out of the
_caller_ of the macro. Let's mark them as deprecated and instead
introduce some new macros that are more
On 01/05/2024 17:41, Douglas Anderson wrote:
Through a cooperative effort between Hsin-Yi Wang and Dmitry
Baryshkov, we have realized the dev_err() in the
mipi_dsi_*_write_seq() macros was causing quite a bit of bloat to the
kernel. Let's hoist this call into drm_mipi_dsi.c by adding a "chatty"
Hello
which tree should this patch be collected from now that it has
been reviewed ?
On Mon, Feb 26, 2024 at 02:25:43PM GMT, Jacopo Mondi wrote:
> Add FourCC definitions for the 48-bit RGB/BGR formats to the
> DRM/KMS uapi.
>
> The format will be used by the Raspberry Pi PiSP Back End,
>
On Thu, 02 May 2024, Lee Jones wrote:
> On Thu, 02 May 2024, Shresth Prasad wrote:
>
> > On Thu, May 2, 2024 at 3:06 PM Lee Jones wrote:
> > >
> > > On Thu, 02 May 2024, Shresth Prasad wrote:
> > >
> > > > `dev->of_node` already has a reference to the device_node and calling
> > > > of_node_get
Fix compile errors of the form "FIELD_PREP: mask is not constant" caused
by signed integer constant overflow. Files affected:
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
Reproducible with gcc 7.5
See https://lore.kernel.org/r/ykwq6%2btih8gqp...@zn.tnic for the gory
details as to why it
On Thu, 2 May 2024 13:59:41 +0200
Boris Brezillon wrote:
> Hi Thomas,
>
> On Thu, 2 May 2024 13:51:16 +0200
> Thomas Zimmermann wrote:
>
> > Hi,
> >
> > ignoring my r-b on patch 1, I'd like to rethink the current patches in
> > general.
> >
> > I think drm_gem_shmem_pin() should become the
Hi Thomas,
On Thu, 2 May 2024 13:51:16 +0200
Thomas Zimmermann wrote:
> Hi,
>
> ignoring my r-b on patch 1, I'd like to rethink the current patches in
> general.
>
> I think drm_gem_shmem_pin() should become the locked version of _pin(),
> so that drm_gem_shmem_object_pin() can call it
On 30/04/2024 12:28, Boris Brezillon wrote:
> From: Antonino Maniscalco
>
> If the kernel couldn't allocate memory because we reached the maximum
> number of chunks but no render passes are in flight
> (panthor_heap_grow() returning -ENOMEM), we should defer the OOM
> handling to the FW by
On Thu, 2024-05-02 at 09:46 -0300, Jason Gunthorpe wrote:
> On Thu, May 02, 2024 at 11:11:04AM +0200, Thomas Hellström wrote:
>
> > It's true the cpu vma lookup is a remnant from amdkfd. The idea
> > here is
> > to replace that with fixed prefaulting ranges of tunable size. So
> > far,
> > as you
When we check for state values returned by the FW, we only cover part of
the 0:7 range. Make sure we catch FW inconsistencies by adding a default
to the switch statement, and flagging the group state as unknown in that
case.
When an unknown state is detected, we trigger a reset, and consider the
On 02/05/2024 16:40, Boris Brezillon wrote:
> Make sure the user is aware that drm_panthor_tiler_heap_destroy::handle
> must be a handle previously returned by
> DRM_IOCTL_PANTHOR_TILER_HEAP_CREATE.
>
> Signed-off-by: Boris Brezillon
Reviewed-by: Steven Price
> ---
>
On 02/05/2024 16:27, Doug Anderson wrote:
Hi,
On Thu, May 2, 2024 at 12:48 AM Neil Armstrong
wrote:
Hi,
On 01/05/2024 17:41, Douglas Anderson wrote:
The consensus of many DRM folks is that we want to move away from DSI
drivers defining tables of init commands. Instead, we want to move to
Hey,
Den 2024-04-24 kl. 18:56, skrev Friedrich Vock:
Hi everyone,
recently I've been looking into remedies for apps (in particular, newer
games) that experience significant performance loss when they start to
hit VRAM limits, especially on older or lower-end cards that struggle
to fit both
Hi,
On 2024/5/2 16:32, Andy Shevchenko wrote:
On Wed, May 01, 2024 at 12:27:14AM +0800, Sui Jingfeng wrote:
On 2024/4/30 22:13, Andy Shevchenko wrote:
On Fri, Apr 26, 2024 at 05:13:43AM +0800, Sui Jingfeng wrote:
...
the former might be subdivided to "is it swnode backed or real fwnode
Hi,
On Thu, May 2, 2024 at 12:48 AM Neil Armstrong
wrote:
>
> Hi,
>
> On 01/05/2024 17:41, Douglas Anderson wrote:
> > The consensus of many DRM folks is that we want to move away from DSI
> > drivers defining tables of init commands. Instead, we want to move to
> > init functions that can use
Hi all,
Continuing after the brief IRC discussion yesterday regarding work
queues being prone to deadlocks or not, I had a browse around the code
base and ended up a bit confused.
When drm_sched_init documents and allocates an *ordered* wq, if no
custom one was provided, could someone
On 02/05/2024 16:40, Boris Brezillon wrote:
> The field used to store the chunk size if 12 bits wide, and the encoding
> is chunk_size = chunk_header.chunk_size << 12, which gives us a
> theoretical [4k:8M] range. This range is further limited by
> implementation constraints, and all known
On 02/05/2024 16:40, Boris Brezillon wrote:
> The heap ID is used to index the heap context pool, and allocating
> in the [1:MAX_HEAPS_PER_POOL] leads to an off-by-one. This was
> originally to avoid returning a zero heap handle, but given the handle
> is formed with (vm_id << 16) | heap_id, with
On Wed, May 1, 2024 at 5:43 PM Douglas Anderson wrote:
> Consensus on the mailing lists is that panels shouldn't use a table of
> init commands but should instead use init functions. With the recently
> introduced mipi_dsi_dcs_write_seq_multi() this is not only clean/easy
> but also saves space.
On Wed, Apr 24, 2024 at 06:06:52PM +0530, Aravind Iddamsetty wrote:
>
> On 24/04/24 17:21, Maxime Ripard wrote:
> > On Mon, Apr 22, 2024 at 12:27:53PM +0530, Aravind Iddamsetty wrote:
> >> In scenarios where drm_dev_put is directly called by driver we want to
> >> release
It doesn't make sense to have a maximum number of chunks smaller than
the initial number of chunks attached to the context.
Fix the uAPI header to reflect the new constraint, and mention the
undocumented "initial_chunk_count > 0" constraint while at it.
v3:
- Add R-b
v2:
- Fix the check
Fixes:
The field used to store the chunk size if 12 bits wide, and the encoding
is chunk_size = chunk_header.chunk_size << 12, which gives us a
theoretical [4k:8M] range. This range is further limited by
implementation constraints, and all known implementations seem to
impose a [128k:8M] range, so do the
The heap ID is used to index the heap context pool, and allocating
in the [1:MAX_HEAPS_PER_POOL] leads to an off-by-one. This was
originally to avoid returning a zero heap handle, but given the handle
is formed with (vm_id << 16) | heap_id, with vm_id > 0, we already can't
end up with a valid heap
From: Antonino Maniscalco
If the kernel couldn't allocate memory because we reached the maximum
number of chunks but no render passes are in flight
(panthor_heap_grow() returning -ENOMEM), we should defer the OOM
handling to the FW by returning a NULL chunk. The FW will then call
the tiler OOM
This is a collection of tiler heap fixes for bugs/oddities found while
looking at incremental rendering.
Ideally, we want to land those before 6.10 is released, so we don't need
to increment the driver version to reflect the ABI changes.
Changelog detailed in each commit.
Regards,
Boris
Make sure the user is aware that drm_panthor_tiler_heap_destroy::handle
must be a handle previously returned by
DRM_IOCTL_PANTHOR_TILER_HEAP_CREATE.
Signed-off-by: Boris Brezillon
---
include/uapi/drm/panthor_drm.h | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git
On Fri, 26 Apr 2024 22:56:02 +0900, Masahiro Yamada wrote:
> When you create a submenu using the 'menu' syntax, there is no
> ambiguity about its end because the code between 'menu' and 'endmenu'
> becomes the submenu.
>
> In contrast, 'menuconfig' does not have the corresponding end marker.
>
Dave, Sima
This week's small set of fixes for drm-next.
drm-xe-next-fixes-2024-05-02:
Driver Changes:
- Fix for a backmerge going slightly wrong.
- An UAF fix
- Avoid a WA error on LNL.
Thanks,
Thomas
The following changes since commit 4a56c0ed5aa0bcbe1f5f7d755fb1fe1ebf48ae9c:
Merge tag
On 02/05/2024 15:15, Boris Brezillon wrote:
> On Thu, 2 May 2024 15:03:51 +0100
> Steven Price wrote:
>
>> On 30/04/2024 12:28, Boris Brezillon wrote:
>>> ID 0 is reserved to encode 'no-tiler-heap', the heap ID range is
>>> [1:MAX_HEAPS_PER_POOL], which we occasionally need to turn into an index
On Thu, 04 Apr 2024, Yoshinori Sato wrote:
> Various parameters of SM501 can be set using platform_data,
> so parameters cannot be passed in the DeviceTree target.
> Expands the parameters set in platform_data so that they can be
> specified using DeviceTree properties.
>
> Signed-off-by:
On Thu, May 02, 2024 at 11:11:04AM +0200, Thomas Hellström wrote:
> It's true the cpu vma lookup is a remnant from amdkfd. The idea here is
> to replace that with fixed prefaulting ranges of tunable size. So far,
> as you mention, the prefaulting range has been determined by the CPU
> vma size.
On Thu, May 02, 2024 at 07:50:36AM +, Kasireddy, Vivek wrote:
> Hi Jason,
<...>
> > I'd rather we stick with the original design. Leon is working on DMA
> > API changes that should address half the issue.
> Ok, I'll keep an eye out for Leon's work.
The code for v1 is here:
On 30/04/2024 12:28, Boris Brezillon wrote:
> It doesn't make sense to have a maximum number of chunks smaller than
> the initial number of chunks attached to the context.
>
> Fix the uAPI header to reflect the new constraint, and mention the
> undocumented "initial_chunk_count > 0" constraint
On 30/04/2024 14:08, Adrián Larumbe wrote:
> Hi Boris,
>
> On 30.04.2024 13:28, Boris Brezillon wrote:
>> The field used to store the chunk size if 12 bits wide, and the encoding
>> is chunk_size = chunk_header.chunk_size << 12, which gives us a
>> theoretical [4k:8M] range. This range is further
1 - 100 of 169 matches
Mail list logo
