My system threw out a bunch of stack traces while booting
v6.12-rc1 and hung.
First of these looks like this:
[ 33.639799] fbcon: mgag200drmfb (fb0) is primary device
[ 33.651573] ixgbe :03:00.0: Intel(R) 10 Gigabit Network Connection
[ 33.652092] ixgbe :03:00.1: enabling device (01
On Mon, Sep 30, 2024 at 04:38:54PM +0800, Macpaul Lin wrote:
> The MediaTek DPI module is typically associated with one of the
> following multimedia power domains:
> - POWER_DOMAIN_DISPLAY
> - POWER_DOMAIN_VDOSYS
> - POWER_DOMAIN_MM
> The specific power domain used varies depending on the SoC d
Hi all,
After merging the drm-misc tree, today's linux-next build (htmldocs)
produced this warning:
include/drm/drm_drv.h:372: warning: Incorrect use of kernel-doc format:
* @fbdev_probe
include/drm/drm_drv.h:435: warning: Function parameter or struct member
'fbdev_probe' not described
On 9/30/24 16:49, AngeloGioacchino Del Regno wrote:
Il 26/09/24 13:14, Macpaul Lin ha scritto:
The infra-iommu node in mt8195.dtsi was triggering a CHECK_DTBS error due
to an excessively long 'interrupts' property. The error message was:
[snip]
diff --git
a/Documentation/devicetree/bin
On 10/2/24 09:51, Rob Herring wrote:
External email : Please do not click links or open attachments until you
have verified the sender or the content.
On Mon, Sep 30, 2024 at 04:38:54PM +0800, Macpaul Lin wrote:
The MediaTek DPI module is typically associated with one of the
foll
On 9/30/24 8:31 AM, Louis Chauvet wrote:
> Re-introduce a line-by-line composition algorithm for each pixel format.
> This allows more performance by not requiring an indirection per pixel
> read. This patch is focused on readability of the code.
>
> Line-by-line composition was introduced by [
Hi all,
After merging the drm-misc tree, today's linux-next build (htmldocs)
produced this warning:
drivers/gpu/drm/drm_fbdev_dma.c:1: warning: no structured comments found
Introduced by commit
731fddf4302e ("drm/fbdev-dma: Remove obsolete setup function")
$ git grep -l -w drivers/gpu/drm/dr
Hi all,
After merging the drm-misc tree, today's linux-next build (htmldocs)
produced this warning:
drivers/gpu/drm/drm_fbdev_shmem.c:1: warning: no structured comments found
Introduced by commit
bf0978203a74 ("drm/fbdev-shmem: Remove obsolete setup function")
--
Cheers,
Stephen Rothwell
Hi all,
After merging the drm-misc tree, today's linux-next build (htmldocs)
produced this warning:
drivers/gpu/drm/drm_fbdev_ttm.c:1: warning: no structured comments found
Introduced by commit
1000634477d8 ("drm/fbdev-ttm: Remove obsolete setup function")
--
Cheers,
Stephen Rothwell
pgpi
The infra-iommu node in mt8195.dtsi was triggering a CHECK_DTBS error due
to an excessively long 'interrupts' property. The error message was:
infra-iommu@10315000: interrupts: [[0, 795, 4, 0], [0, 796, 4, 0],
[0, 797, 4, 0], [0, 798, 4, 0], [0, 799, 4, 0]]
The MediaTek DPI module is typically associated with one of the
following multimedia power domains:
- POWER_DOMAIN_DISPLAY
- POWER_DOMAIN_VDOSYS
- POWER_DOMAIN_MM
The specific power domain used varies depending on the SoC design.
These power domains are shared by multiple devices within the SoC
The infracfg_ao node in mt8195.dtsi was causing a dtbs_check error.
The error message was:
syscon@10001000: compatible: ['mediatek,mt8195-infracfg_ao', 'syscon',
'simple-mfd'] is too long
To resolve this, remove 'simple-mfd' from the 'compatible' property of the
infracfg_ao node.
The ethernet-phy node in mt8395-genio-1200-evk.dts was triggering a
dtbs_check error. The error message was:
eth-phy0@1: $nodename:0: 'eth-phy0@1' does not match
'^ethernet-phy(@[a-f0-9]+)?$'
Fix this issue by replacing 'eth-phy' node to generic 'ethernet-phy'.
Fixes: f2b543a191b6
The mutex node in mt8195.dtsi was triggering a dtbs_check error:
mutex@1c101000: 'clock-names', 'reg-names' do not match any of the
regexes: 'pinctrl-[0-9]+'
This seems no need by inspecting the DT schemas and other reference boards,
so drop 'clock-names' and 'reg-names' in mt8
Hi Jason-JH.Lin,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm/drm-next]
[also build test ERROR on linus/master v6.12-rc1 next-20241001]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use
Il 01/10/24 12:07, CK Hu (胡俊光) ha scritto:
Hi, Angelo:
On Tue, 2024-09-10 at 10:51 +, AngeloGioacchino Del Regno wrote:
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 configurati
Hi,
On 30/09/2024 21:19, Jessica Zhang wrote:
On 9/30/2024 7:17 AM, neil.armstr...@linaro.org wrote:
On 25/09/2024 00:59, Jessica Zhang wrote:
Cache the CWB block mask in the DPU virtual encoder and configure CWB
according to the CWB block mask within the writeback phys encoder
Signed-off-b
On Fri, 20 Sep 2024 11:28:02 +0100
Liviu Dudau wrote:
> Since 641bb4394f40 ("fs: move FMODE_UNSIGNED_OFFSET to fop_flags")
> the FMODE_UNSIGNED_OFFSET flag has been moved to fop_flags and renamed,
> but the patch failed to make the changes for the panthor driver.
> When user space opens the rende
On Tue, Oct 01, 2024 at 05:54:46PM +0300, Andy Shevchenko wrote:
> On Tue, Oct 01, 2024 at 05:18:33PM +0300, Raag Jadav wrote:
> > On Tue, Oct 01, 2024 at 03:07:59PM +0300, Andy Shevchenko wrote:
> > > On Tue, Oct 01, 2024 at 08:08:18AM +0300, Raag Jadav wrote:
> > > > On Mon, Sep 30, 2024 at 03:59
On Mon, 30 Sep 2024 18:37:42 +0200
Boris Brezillon wrote:
> The group variable can't be used to retrieve ptdev in our second loop,
> because it points to the previously iterated list_head, not a valid
> group. Get the ptdev object from the scheduler instead.
>
> Cc:
> Fixes: d72f049087d4 ("drm/
On Fri, 13 Sep 2024 13:27:22 +0200
Boris Brezillon wrote:
> drm_gpuvm_bo_obtain_prealloc() will call drm_gpuvm_bo_put() on our
> pre-allocated BO if the association exists. Given we
> only have one ref on preallocated_vm_bo, drm_gpuvm_bo_destroy() will
> be called immediately, and we have to hol
Am 01.10.24 um 15:41 schrieb Benjamin Tissoires:
On Oct 01 2024, Werner Sembach wrote:
(sorry resend because thunderbird made it a html mail)
Hi,
Am 30.09.24 um 19:06 schrieb Benjamin Tissoires:
On Sep 30 2024, Werner Sembach wrote:
[...]
Thinking about it, maybe it's not to bad that it onl
On Thu, 5 Sep 2024 09:19:14 +0200
Boris Brezillon wrote:
> If deferred operations are pending, we want to wait for those to
> land before declaring the queue blocked on a SYNC_WAIT. We need
> this to deal with the case where the sync object is signalled through
> a deferred SYNC_{ADD,SET} from t
On Thu, 5 Sep 2024 09:01:54 +0200
Boris Brezillon wrote:
> The only user (the mesa gallium driver) is already assuming explicit
> synchronization and doing the export/import dance on shared BOs. The
> only reason we were registering ourselves as writers on external BOs
> is because Xe, which was
The TUXEDO Sirius 16 Gen1 and TUXEDO Sirius 16 Gen2 devices have a per-key
controllable RGB keyboard backlight. The firmware API for it is implemented
via WMI.
To make the backlight userspace configurable this driver emulates a
LampArray HID device and translates the input from hidraw to the
corre
Just wanted to send my current state as previous version had a null pointer
dereference.
On this toppic, why does hdev have a hdev->driver_data and a
hdev->dev.driver_data which are not the same? I assume hdev->driver_data is for
the ll_driver and hdev->dev.driver_data for the driver?
On Tue, Oct 01, 2024 at 08:08:18AM +0300, Raag Jadav wrote:
> On Mon, Sep 30, 2024 at 03:59:59PM +0300, Andy Shevchenko wrote:
> > On Mon, Sep 30, 2024 at 01:08:41PM +0530, Raag Jadav wrote:
...
> > > +static const char *const drm_wedge_recovery_opts[] = {
> > > + [DRM_WEDGE_RECOVERY_REBIND] = "r
On 25/09/2024 10:33, Jocelyn Falempe wrote:
On 24/09/2024 16:02, Alex Deucher wrote:
On Fri, Sep 20, 2024 at 11:36 AM Jocelyn Falempe
wrote:
On 17/09/2024 15:21, Alex Deucher wrote:
On Mon, Aug 12, 2024 at 2:10 AM Lu Yao wrote:
Add support for the drm_panic module, which displays a pretty
Am Sonntag, dem 08.09.2024 um 17:43 +0800 schrieb Sui Jingfeng:
> Because this make the code more easier to understand, When GPU access the
> VRAM, it will allocate a new mapping to use if there don't have one.
>
> Signed-off-by: Sui Jingfeng
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gem.c | 40 ++
Am Freitag, 20. September 2024, 12:28:02 CEST schrieb Liviu Dudau:
> Since 641bb4394f40 ("fs: move FMODE_UNSIGNED_OFFSET to fop_flags")
> the FMODE_UNSIGNED_OFFSET flag has been moved to fop_flags and renamed,
> but the patch failed to make the changes for the panthor driver.
> When user space open
Hi amdgpu Maintainers,
On 30/09/24 15:22, Vignesh Raman wrote:
Update the documentation to specify linking to a relevant GitLab
issue or email report for each new flake entry. Added specific
GitLab issue urls for amdgpu, i915, msm and xe driver.
Acked-by: Maxime Ripard
Acked-by: Rodrigo Vivi
Am Sonntag, dem 08.09.2024 um 17:43 +0800 schrieb Sui Jingfeng:
> Which is corresonding to the etnaviv_gem_obj_add()
>
While symmetry is nice, it's still not really symmetric, as this
function isn't exported into the PRIME parts of the driver like
etnaviv_gem_obj_add(). Given that I don't really s
From: baihan li
Add link training process functions in this moduel.
Signed-off-by: baihan li
---
drivers/gpu/drm/hisilicon/hibmc/Makefile | 2 +-
drivers/gpu/drm/hisilicon/hibmc/dp/dp_kapi.c | 258
drivers/gpu/drm/hisilicon/hibmc/dp/dp_link.c | 390 +++
drive
On 6/19/24 11:38, Hsiao Chien Sung via B4 Relay wrote:
From: Hsiao Chien Sung
Set the plane alpha according to DRM plane property.
Reviewed-by: CK Hu
Reviewed-by: AngeloGioacchino Del Regno
Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.")
Signed-off-by: Hsiao Ch
Am Sonntag, dem 08.09.2024 um 17:43 +0800 schrieb Sui Jingfeng:
> Because there are a lot of data members in the struct etnaviv_drm_private,
> which are intended to be shared by all GPU cores. It can be lengthy and
> daunting on error handling, the 'gem_lock' of struct etnaviv_drm_private
> just be
amdgpu_irq_ad_id() may fail and the irq handlers will not be registered.
This patch adds error code check.
Found by Linux Verification Center (linuxtesting.org) with static
analysis tool SVACE.
Signed-off-by: Igor Artemiev
---
.../drm/amd/pm/powerplay/hwmgr/smu_helper.c | 19 -
On 01.10.2024 12:01, Dmitry Baryshkov wrote:
> On September 30, 2024 1:49:41 PM GMT+03:00, Heiner Kallweit
> wrote:
>> On 22.09.2024 16:55, Dmitry Baryshkov wrote:
>>> On Sun, Sep 08, 2024 at 02:08:58PM GMT, Heiner Kallweit wrote:
This undocumented attribute returns a version string which ha
Am Sonntag, dem 08.09.2024 um 17:43 +0800 schrieb Sui Jingfeng:
> In the etnaviv_gem_vmap_impl() function, the driver vmap whatever buffers
> with write combine(WC) page property. This is incorrect, as some platforms
> are cached coherent. Cached buffers should be mapped with cached page
> property
On Tue, Oct 01, 2024 at 03:07:59PM +0300, Andy Shevchenko wrote:
> On Tue, Oct 01, 2024 at 08:08:18AM +0300, Raag Jadav wrote:
> > On Mon, Sep 30, 2024 at 03:59:59PM +0300, Andy Shevchenko wrote:
> > > On Mon, Sep 30, 2024 at 01:08:41PM +0530, Raag Jadav wrote:
>
> ...
>
> > > > +static const cha
Hi Huacai,
在 2024-09-29 15:50，Huacai Chen 写道：
This reverts commit fd69ef05029f9beb7b031ef96e7a36970806a670.
The original patch causes NULL pointer references:
[ 21.620856] CPU 3 Unable to handle kernel paging request at virtual
address , era == 94bf61d8, ra ==
9
Am Sonntag, dem 08.09.2024 um 17:43 +0800 schrieb Sui Jingfeng:
> The etnaviv_gem_prime_vmap() function has no caller in the
> etnaviv_gem_prime.c file, move it into etnaviv_gem.c file.
> While at it, rename it as etnaviv_gem_object_vmap(), since
> it is a intermidiate layer function, it has no dir
This is a note to let you know that I've just added the patch titled
drm/vmwgfx: Prevent unmapping active read buffers
to the 6.1-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-v
Hi Sui,
Am Sonntag, dem 08.09.2024 um 17:43 +0800 schrieb Sui Jingfeng:
> It will be called by drm_gem_print_info() if implemented, and it can
> provide more information about the framebuffer objects.
Etnaviv GEM BOs are not framebuffer objects.
>
> Signed-off-by: Sui Jingfeng
> ---
> drivers
On Tue, Oct 1, 2024 at 11:26 AM Jani Nikula wrote:
>
> regenerated? Should there be more granularity?
Indeed, eventually this will need to be split, like we did for `helpers.c`.
Cheers,
Miguel
On 10/1/24 20:17, Lucas Stach wrote:
CAUTION: This email comes from a non Wind River email account!
Do not click links or open attachments unless you recognize the sender and know
the content is safe.
Hi Xiaolei,
Am Dienstag, dem 03.09.2024 um 10:08 +0800 schrieb Xiaolei Wang:
Remove __GFP_H
Am Sonntag, dem 08.09.2024 um 17:43 +0800 schrieb Sui Jingfeng:
> This will make the newly implemented etnaviv_gem_object_funcs::print_info
> get in use, which improves code sharing and simplifies debugfs. Achieve
> better humen readability for debug log.
>
> Use container_of_const() if 'struct et
The DPI_OE bit is removed from the latest RZ/G2UL and RZ/G2L hardware
manual. So, drop this macro.
Signed-off-by: Biju Das
---
drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
b
I will look into this and get back to you. Thank you.
On Tue, Oct 1, 2024 at 8:23 PM Christophe Leroy
wrote:
>
> Hi All,
>
> Le 01/10/2024 à 14:09, Hoi Pok Wu a écrit :
> > [Vous ne recevez pas souvent de courriers de wuhoi...@gmail.com. Découvrez
> > pourquoi ceci est important à https://aka.m
Hi,
Am 30.09.24 um 21:38 schrieb Zichen Xie:
Dear Linux Developers for DMA BUFFER SHARING FRAMEWORK,
We are curious about the function 'dma_resv_get_fences' here:
https://elixir.bootlin.com/linux/v6.11/source/drivers/dma-buf/dma-resv.c#L568,
and the logic below:
```
dma_resv_for_each_fence_unlo
Hi again,
Am 01.10.24 um 14:23 schrieb Werner Sembach:
(sorry resend because thunderbird made it a html mail)
Hi,
Am 30.09.24 um 19:06 schrieb Benjamin Tissoires:
On Sep 30 2024, Werner Sembach wrote:
[...]
Thinking about it, maybe it's not to bad that it only changes once udev is
ready, lik
Enjoy!
The following changes since commit 9852d85ec9d492ebef56dc5f229416c925758edc:
Linux 6.12-rc1 (2024-09-29 15:06:19 -0700)
are available in the Git repository at:
ssh://g...@gitolite.kernel.org/pub/scm/linux/kernel/git/lee/backlight.git
tags/ib-backlight-hid-fbdev-v6.13
for you to fet
Am 01.10.24 um 12:57 schrieb Igor Artemiev:
amdgpu_irq_ad_id() may fail and the irq handlers will not be registered.
This patch adds error code check.
Found by Linux Verification Center (linuxtesting.org) with static
analysis tool SVACE.
Signed-off-by: Igor Artemiev
---
.../drm/amd/pm/powerp
On Tue, Oct 01, 2024 at 05:18:33PM +0300, Raag Jadav wrote:
> On Tue, Oct 01, 2024 at 03:07:59PM +0300, Andy Shevchenko wrote:
> > On Tue, Oct 01, 2024 at 08:08:18AM +0300, Raag Jadav wrote:
> > > On Mon, Sep 30, 2024 at 03:59:59PM +0300, Andy Shevchenko wrote:
> > > > On Mon, Sep 30, 2024 at 01:08
On Oct 01 2024, Werner Sembach wrote:
> (sorry resend because thunderbird made it a html mail)
>
> Hi,
>
> Am 30.09.24 um 19:06 schrieb Benjamin Tissoires:
> > On Sep 30 2024, Werner Sembach wrote:
> > > [...]
> > > Thinking about it, maybe it's not to bad that it only changes once udev is
> > >
On 01/10/2024 08:41, Mahadevan via B4 Relay wrote:
> This series introduces support to enable the Mobile Display Subsystem (MDSS)
> and Display Processing Unit (DPU) for the Qualcomm SA8775P target. It
> includes the addition of the hardware catalog, compatible string,
> relevant device tree change
On October 1, 2024 1:16:31 PM GMT+03:00, Krzysztof Kozlowski
wrote:
>On 01/10/2024 08:41, Mahadevan via B4 Relay wrote:
>> This series introduces support to enable the Mobile Display Subsystem (MDSS)
>> and Display Processing Unit (DPU) for the Qualcomm SA8775P target. It
>> includes the addition
This is a note to let you know that I've just added the patch titled
drm/vmwgfx: Prevent unmapping active read buffers
to the 6.6-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-v
Hi,
On 2024/10/1 21:40, Lucas Stach wrote:
Am Sonntag, dem 08.09.2024 um 17:43 +0800 schrieb Sui Jingfeng:
The etnaviv_gem_prime_vmap() function has no caller in the
etnaviv_gem_prime.c file, move it into etnaviv_gem.c file.
While at it, rename it as etnaviv_gem_object_vmap(), since
it is a int
On October 1, 2024 2:07:28 PM GMT+03:00, Heiner Kallweit
wrote:
>On 01.10.2024 12:01, Dmitry Baryshkov wrote:
>> On September 30, 2024 1:49:41 PM GMT+03:00, Heiner Kallweit
>> wrote:
>>> On 22.09.2024 16:55, Dmitry Baryshkov wrote:
On Sun, Sep 08, 2024 at 02:08:58PM GMT, Heiner Kallweit wr
Dear Linux Developers for DMA BUFFER SHARING FRAMEWORK,
We are curious about the function 'dma_resv_get_fences' here:
https://elixir.bootlin.com/linux/v6.11/source/drivers/dma-buf/dma-resv.c#L568,
and the logic below:
```
dma_resv_for_each_fence_unlocked(&cursor, fence) {
if (dma_resv_iter_is_res
Hi Xiaolei,
Am Dienstag, dem 03.09.2024 um 10:08 +0800 schrieb Xiaolei Wang:
> Remove __GFP_HIGHMEM when requesting a page from DMA32 zone,
> and since all vivante GPUs in the system will share the same
> DMA constraints, move the check of whether to get a page from
> DMA32 to etnaviv_bind().
>
>
Hi,
Am 30.09.24 um 19:06 schrieb Benjamin Tissoires:
On Sep 30 2024, Werner Sembach wrote:
[...]
Thinking about it, maybe it's not to bad that it only changes once udev is
ready, like this udev could decide if leds should be used or if it should
directly be passed to OpenRGB for example, giving
Hi,
sorry for late comments,
On 30.09.2024 09:38, Raag Jadav wrote:
> Introduce device wedged event, which will notify userspace of wedged
> (hanged/unusable) state of the DRM device through a uevent. This is
> useful especially in cases where the device is no longer operating as
> expected even
On 30/09/2024 19:05, Hugo Villeneuve wrote:
From: Hugo Villeneuve
Now that the driver has been converted to use wrapped MIPI DCS functions,
the num_init_cmds structure member is no longer needed, so remove it.
Fixes: 35583e129995 ("drm/panel: panel-jadard-jd9365da-h3: use wrapped MIPI DCS
fun
(sorry resend because thunderbird made it a html mail)
Hi,
Am 30.09.24 um 19:06 schrieb Benjamin Tissoires:
On Sep 30 2024, Werner Sembach wrote:
[...]
Thinking about it, maybe it's not to bad that it only changes once udev is
ready, like this udev could decide if leds should be used or if it
On September 30, 2024 1:49:41 PM GMT+03:00, Heiner Kallweit
wrote:
>On 22.09.2024 16:55, Dmitry Baryshkov wrote:
>> On Sun, Sep 08, 2024 at 02:08:58PM GMT, Heiner Kallweit wrote:
>>> This undocumented attribute returns a version string which hasn't been
>>> changed for ages. libdrm doesn't use it
Am Sonntag, dem 08.09.2024 um 17:43 +0800 schrieb Sui Jingfeng:
> Otherwise we don't know where a etnaviv GEM buffer object should put when
> we create it at userspace.
>
> Signed-off-by: Sui Jingfeng
> ---
> drivers/gpu/drm/etnaviv/etnaviv_drv.c | 9 +
> include/uapi/drm/etnaviv_drm.h
Hi Thomas,
Could you help on this issue?
I do not have access to the hardware now.
Thank you.
Regards,
Wu Hoi Pok
On Tue, Oct 1, 2024 at 12:26 PM Christian Zigotzky
wrote:
>
> On 30 September 2024 3:27pm, Alex Deucher wrote:
>
> + Wu Hoi Pok
>
> This is likely related to the drm device rewor
Hi Sui,
Am Dienstag, dem 01.10.2024 um 06:17 +0800 schrieb Sui Jingfeng:
> Etnaviv assumes that GPU page size is 4KiB, yet on some systems, the CPU
> page size is 16 KiB. The size of etnaviv buffer objects will be aligned
> to CPU page size on kernel side, however, userspace still assumes the
> pa
Am Sonntag, dem 08.09.2024 um 17:43 +0800 schrieb Sui Jingfeng:
> The etnaviv_gem_obj_add() a common operation, the 'etnaviv_drm_private::
> gem_list' is being used to record(track) all of the etnaviv GEM buffer
> object created in this driver.
>
> Once a etnaviv GEM buffer object has been allocat
From: baihan li
Add dp aux read/write functions. They are basic functions
and will be used later.
Signed-off-by: baihan li
---
drivers/gpu/drm/hisilicon/hibmc/Makefile | 3 +-
drivers/gpu/drm/hisilicon/hibmc/dp/dp_aux.c | 227 +++
drivers/gpu/drm/hisilicon/hibmc/dp/dp_a
From: baihan li
To support DP interface displaying in hibmc driver. Add
a encoder and connector for DP modual.
Signed-off-by: baihan li
---
drivers/gpu/drm/hisilicon/hibmc/Makefile | 2 +-
.../gpu/drm/hisilicon/hibmc/hibmc_drm_dp.c| 195 ++
.../gpu/drm/hisilicon/hibm
From: baihan li
Realizing the basic display function of DP cable for DP connector
displaying. Add DP module in hibmc drm driver, which is for Hisilicon
Hibmc SoC which used for Out-of-band management. Blow is the general
hardware connection, both the Hibmc and the host CPU are on
Am Sonntag, dem 08.09.2024 um 17:43 +0800 schrieb Sui Jingfeng:
> The vunmap() can be used to release virtual mapping obtained by vmap(),
> While the vmap() is used to make a long duration mapping of multiple
> physical pages into a contiguous virtual space.
>
> Make the implementation-specific vu
On Mon, Sep 16, 2024 at 04:42:33PM -0400, Lyude Paul wrote:
> Sigh. Took me a minute but I think I know what happened - I meant to push the
> entire series to drm-misc-next and not drm-misc-fixes, but I must have misread
> or typo'd the branch name and pushed the second half of patches to drm-misc-
On 27/09/24 4:51 am, Dmitry Baryshkov wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> On Thu, Sep 26, 2024 at 03:58:11PM GMT, Maxime Ripard wrote:
>> On Thu, Sep 26, 2024 at 04:32:59PM GMT, Dmitry Baryshkov wrote:
>>> On Thu, Sep 26, 2024
From: baihan li
Build a kapi level that hibmc driver can enable dp by
calling these kapi functions.
Signed-off-by: baihan li
---
drivers/gpu/drm/hisilicon/hibmc/Makefile | 2 +-
.../gpu/drm/hisilicon/hibmc/dp/dp_config.h| 20
drivers/gpu/drm/hisilicon/hibmc/dp/dp_kapi.c | 1
On Mon, 30 Sep 2024, Lyude Paul wrote:
> diff --git a/rust/bindings/bindings_helper.h b/rust/bindings/bindings_helper.h
> index b2e05f8c2ee7d..04898f70ef1b8 100644
> --- a/rust/bindings/bindings_helper.h
> +++ b/rust/bindings/bindings_helper.h
> @@ -9,6 +9,7 @@
> #include
> #include
> #includ
The DPI_OE bit is removed from the latest RZ/G2UL and RZ/G2L hardware
manual. So, drop this macro.
Signed-off-by: Biju Das
---
drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
b
Le 30/09/2024 à 09:48, Jani Nikula a écrit :
On Sat, 28 Sep 2024, Christophe JAILLET wrote:
"name" is allocated and freed in intel_backlight_device_register().
The initial allocation just duplicates "intel_backlight".
Later, if a device with this name has already been registered, another
dynam
On 8/9/24 15:35, Sean Anderson wrote:
> This series cleans up the zyqnmp_dp IRQ and locking situation. Once
> that's done, it adds debugfs support. The intent is to enable compliance
> testing or to help debug signal-integrity issues.
>
> Previously, I discussed converting the HPD work(s) to a thr
Hi,
On 2024/10/1 22:39, Lucas Stach wrote:
Am Sonntag, dem 08.09.2024 um 17:43 +0800 schrieb Sui Jingfeng:
The etnaviv_gem_obj_add() a common operation, the 'etnaviv_drm_private::
gem_list' is being used to record(track) all of the etnaviv GEM buffer
object created in this driver.
Once a etnav
Hi All,
Le 01/10/2024 à 14:09, Hoi Pok Wu a écrit :
[Vous ne recevez pas souvent de courriers de wuhoi...@gmail.com. Découvrez
pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification ]
Hi Thomas,
Could you help on this issue?
I do not have access to the hardware now.
Thank
Hi,
On 2024/10/1 22:21, Lucas Stach wrote:
Am Sonntag, dem 08.09.2024 um 17:43 +0800 schrieb Sui Jingfeng:
Which is corresonding to the etnaviv_gem_obj_add()
While symmetry is nice,
Thanks a lot for understanding and review my patch.
it's still not really symmetric,
patch 0016 will tr
Hi Benjamin,
Am 01.10.24 um 15:41 schrieb Benjamin Tissoires:
On Oct 01 2024, Werner Sembach wrote:
(sorry resend because thunderbird made it a html mail)
Hi,
Am 30.09.24 um 19:06 schrieb Benjamin Tissoires:
On Sep 30 2024, Werner Sembach wrote:
[...]
Thinking about it, maybe it's not to ba
Hi,
On 2024/10/1 16:27, Lucas Stach wrote:
Hi Sui,
Am Dienstag, dem 01.10.2024 um 06:17 +0800 schrieb Sui Jingfeng:
Etnaviv assumes that GPU page size is 4KiB, yet on some systems, the CPU
page size is 16 KiB. The size of etnaviv buffer objects will be aligned
to CPU page size on kernel side,
Hi Armin,
Am 01.10.24 um 18:45 schrieb Armin Wolf:
Am 01.10.24 um 15:41 schrieb Benjamin Tissoires:
On Oct 01 2024, Werner Sembach wrote:
(sorry resend because thunderbird made it a html mail)
Hi,
Am 30.09.24 um 19:06 schrieb Benjamin Tissoires:
On Sep 30 2024, Werner Sembach wrote:
[...]
On 10/1/24 3:10 AM, Bagas Sanjaya wrote:
On Thu, Sep 26, 2024 at 11:16:53PM +0200, Antonino Maniscalco wrote:
+.. SPDX-License-Identifier: GPL-2.0
+
+:orphan:
Why don't this be added to toctree in Documentation/gpu/index.rst?
Yes so there is existing orphan documentation for msm so my intent
Hi!
> > > > LampArray HID device and translates the input from hidraw to the
> > > > corresponding WMI calls. This is a new approach as the leds
> > > > subsystem lacks
> > > > a suitable UAPI for per-key keyboard backlights, and like this
> > > > no new UAPI
> > > > needs to be established.
> > >
Hi!
> PPS: sorry for pushing that hard on HID-BPF, but I can see that it fits
> all of the requirements here:
> - need to be dynamic
> - still unsure of the userspace implementation, meaning that userspace
> might do something wrong, which might require kernel changes
> - possibility to extend l
On Mon, Sep 30, 2024 at 4:41 PM Maxime Ripard wrote:
>
> Following a recent discussion at last Plumbers, John Stultz, Sumit
> Sewal, TJ Mercier and I came to an agreement that we should document
> what the dma-buf heaps names are expected to be, and what the buffers
> attributes you'll get should
From: Jonas Ådahl
In order for compositors to utilize real time scheduling capabilities,
it must be ensured by the kernel that calling a drmModeAtomicCommit()
with DRM_MODE_ATOMIC_NONBLOCK does not block in a manner that makes the
realtime scheduler watchdog send a SIGKILL to the calling process.
This patch adds drm_panic support for meson-drm, has been tested on
A311D with both TTY and Wayland session.
It is an RFC since I am not sure whether AFBC enabled case is handled
properly and don't find a good test case. Thanks for your time and
advice.
Yao Zi (1):
drm/meson: Support drm_panic
Hi,
On Wed, Sep 25, 2024 at 1:00 AM Tejas Vipin wrote:
>
> Changes the elida-kd35t133 panel to use multi style functions for
> improved error handling.
>
> Reviewed-by: Jessica Zhang
> Reviewed-by: Dmitry Baryshkov
> Signed-off-by: Tejas Vipin
> ---
> Changes in v3:
> - Added back bytes t
On Tue, Oct 1, 2024 at 7:51 PM Pintu Kumar wrote:
>
> Use of kmap_atomic/kunmap_atomic is deprecated, use
> kmap_local_page/kunmap_local instead.
>
> This is reported by checkpatch.
> Also fix repeated word issue.
>
> WARNING: Deprecated use of 'kmap_atomic', prefer 'kmap_local_page' instead
> +
This patch implements drm_plane_helper_funcs.get_scanout_buffer for
primary plane, enabling meson-drm to work with drm_panic.
This implementation tries to use current framebuffer as scanout buffer.
In case of AFBC enabled, we disable the decoder path and adjust OSD1
parameters in get_scanout_buffe
1 - 100 of 109 matches
Mail list logo
