Referencing the 'struct etnaviv_gpu *' by every etnaviv GEM BO is weird.
Drop it and drop yet another unused data field, namely 'access'.
Memory footprint of etnaviv GEM BOs reduced.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/etnaviv/etnaviv_gem.h | 2 --
1 file changed, 2 deletions(-)
di
if CONFIG_DRM_USE_DYNAMIC_DEBUG is set,
'drm_dbg' function is replaced with '__dynamic_func_call_cls',
which is replaced with a do while statement.
so in the previous code, there are the following build errors.
include/linux/dynamic_debug.h:221:58: error: expected expression before ‘do’
221 | #d
The pull request you sent on Sat, 2 Nov 2024 05:04:48 +1000:
> https://gitlab.freedesktop.org/drm/kernel.git tags/drm-fixes-2024-11-02
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/269ce3bd62e8ad83dadc80a2f755a799697ca4a3
Thank you!
--
Deet-doot-dot, I am a bot.
ht
On Fri, 25 Oct 2024 03:20:07 +0300, Dmitry Baryshkov wrote:
> As promised in the basic wide planes support ([1]) here comes a series
> supporting 2*max_linewidth for all the planes.
>
> Note: Unlike v1 and v2 this series finally includes support for
> additional planes - having more planes than
On Sat, 21 Sep 2024 11:17:28 +0300, Dmitry Baryshkov wrote:
> Current way of programming of the UBWC-related registers has been
> inherited from vendor's drivers. The ubwc_static was supposed to contain
> raw data to be programmed to the hardware, but was later repurposed to
> define of the bits.
On Fri, Nov 01, 2024 at 05:40:46PM -0700, Abhinav Kumar wrote:
>
>
> On 11/1/2024 3:26 PM, Dmitry Baryshkov wrote:
> > On Fri, 1 Nov 2024 at 23:41, Abhinav Kumar
> > wrote:
> > >
> > >
> > >
> > > On 10/18/2024 2:10 PM, Dmitry Baryshkov wrote:
> > > > The MSM HDMI driver supports interlaced
Hi Rouven,
kernel test robot noticed the following build errors:
[auto build test ERROR on c2ee9f594da826bea183ed14f2cc029c719bf4da]
url:
https://github.com/intel-lab-lkp/linux/commits/Rouven-Czerwinski/dt-bindings-display-panel-add-YAML-schema-for-LXD-M9189A/20241025-221252
base: c2ee9f59
if CONFIG_DRM_USE_DYNAMIC_DEBUG is set,
'drm_dbg' function is replaced with '__dynamic_func_call_cls',
which is replaced with a do while statement.
so in the previous code, there are the following build errors.
include/linux/dynamic_debug.h:221:58: error: expected expression before ‘do’
221 | #d
On 11/1/2024 3:26 PM, Dmitry Baryshkov wrote:
On Fri, 1 Nov 2024 at 23:41, Abhinav Kumar wrote:
On 10/18/2024 2:10 PM, Dmitry Baryshkov wrote:
The MSM HDMI driver supports interlaced modes. Set the corresponding
flag to allow interlaced modes on the corresponding connectors.
Signed-off-
From: Alexei Starovoitov
Hi DRM folks,
we'd like to start using drm_mm in bpf arena.
The drm_mm logic fits particularly well to bpf use case.
See individual patches.
objdump -h lib/drm_mm.o
.text 12c7
So no vmlinux size concerns.
Alexei Starovoitov (2):
drm, bpf: Move drm_mm.c
> >--- a/drivers/gpu/drm/xe/xe_macros.h
> >+++ b/drivers/gpu/drm/xe/xe_macros.h
> >@@ -11,8 +11,12 @@
> > #define XE_WARN_ON WARN_ON
> >
> > #define XE_IOCTL_DBG(xe, cond) \
> >- ((cond) && (drm_dbg(&(xe)->drm, \
> >- "Ioctl argument check failed at %s:%d: %s", \
> >-
From: Alexei Starovoitov
bpf arena is moving towards non-sleepable allocations in tracing
context while maple_tree does kmalloc/kfree deep inside. Hence switch
bpf arena to drm_mm algorithm that works with externally provided
drm_mm_node-s. This patch kmalloc/kfree-s drm_mm_node-s, but the next
p
From: Alexei Starovoitov
Move drm_mm.c to lib. The next commit will use drm_mm to manage
memory regions in bpf arena. Move drm_mm_print to
drivers/gpu/drm/drm_print.c, since it's not a core functionality
of drm_mm and it depeneds on drm_printer while drm_mm is
generic and usuable as-is by other s
On 11/1/2024 2:27 PM, Abhinav Kumar wrote:
On 11/1/2024 1:53 PM, Dmitry Baryshkov wrote:
On Fri, Nov 01, 2024 at 01:37:03PM -0700, Abhinav Kumar wrote:
On 10/31/2024 2:03 PM, Dmitry Baryshkov wrote:
On Thu, Oct 31, 2024 at 01:06:34PM -0700, Abhinav Kumar wrote:
On 10/31/2024 8:11 AM,
On Fri, 1 Nov 2024 at 23:41, Abhinav Kumar wrote:
>
>
>
> On 10/18/2024 2:10 PM, Dmitry Baryshkov wrote:
> > The MSM HDMI driver supports interlaced modes. Set the corresponding
> > flag to allow interlaced modes on the corresponding connectors.
> >
> > Signed-off-by: Dmitry Baryshkov
> > ---
> >
On 10/18/2024 2:10 PM, Dmitry Baryshkov wrote:
The MSM HDMI driver supports interlaced modes. Set the corresponding
flag to allow interlaced modes on the corresponding connectors.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 1 +
1 file changed, 1 insertion
When /proc/pid/fdinfo was part of proc.5 man page the indentation made
sense. As a standalone man page the indentation doesn't need to be so
far over to the right. Remove the initial tagged pragraph, move the
"since Linux 2.6.22" to a new history subsection.
Suggested-by: G. Branden Robinson
Sign
On 11/1/2024 1:53 PM, Dmitry Baryshkov wrote:
On Fri, Nov 01, 2024 at 01:37:03PM -0700, Abhinav Kumar wrote:
On 10/31/2024 2:03 PM, Dmitry Baryshkov wrote:
On Thu, Oct 31, 2024 at 01:06:34PM -0700, Abhinav Kumar wrote:
On 10/31/2024 8:11 AM, Dmitry Baryshkov wrote:
Hi Abhinav,
On Wed,
[why]
Starting from dp2 where dsc passthrough is introduced, it is required to
identify
the dsc passthrough aux, apart from dsc decompression aux. Existing
drm_dp_mst_port function
that returns dsc_aux alone is not sufficient.
[how]
1. Interface change in drm_dp_mst_dsc_aux_for_port, and depende
The patch series is to refactor existing dsc determination policy for
dsc decompression and dsc passthrough given a mst output port.
Original routine was written based on different peer device types
which is not accurate and shows difficulty when expanding support of
products that do not fully com
[why]
How we determine the dsc_aux used for dsc decompression in
drm_dp_mst_dsc_aux_for_port() today has defects:
1. The method how we determine a connected peer device is virtual or not
in drm_dp_mst_is_virtual_dpcd() is not always correct. There are DP1.4
products
in the market which don'
Previously the pid was highlighted through being a tagged paragraph
but not mentioned in the description. Add italics to the path
emphasizing pid and then change the first sentence to include pid in
the definition.
Suggested-by: G. Branden Robinson
Signed-off-by: Ian Rogers
---
man/man5/proc_pi
Add description of DRM fdinfo information based on the Linux kernel's
`Documentation/gpu/drm-usage-stats.rst`:
https://docs.kernel.org/gpu/drm-usage-stats.html
Signed-off-by: Ian Rogers
---
man/man5/proc_pid_fdinfo.5 | 94 ++
1 file changed, 94 insertions(+)
Make the sections about eventfd, epoll, signalfd, inotify, fanotify,
timerfd better separated with a clearer subsection header.
Signed-off-by: Ian Rogers
---
man/man5/proc_pid_fdinfo.5 | 6 ++
1 file changed, 6 insertions(+)
diff --git a/man/man5/proc_pid_fdinfo.5 b/man/man5/proc_pid_fdinfo
On Fri, Nov 01, 2024 at 01:37:03PM -0700, Abhinav Kumar wrote:
>
>
> On 10/31/2024 2:03 PM, Dmitry Baryshkov wrote:
> > On Thu, Oct 31, 2024 at 01:06:34PM -0700, Abhinav Kumar wrote:
> > >
> > >
> > > On 10/31/2024 8:11 AM, Dmitry Baryshkov wrote:
> > > > Hi Abhinav,
> > > >
> > > > On Wed, 30
On 10/31/2024 2:03 PM, Dmitry Baryshkov wrote:
On Thu, Oct 31, 2024 at 01:06:34PM -0700, Abhinav Kumar wrote:
On 10/31/2024 8:11 AM, Dmitry Baryshkov wrote:
Hi Abhinav,
On Wed, 30 Oct 2024 at 21:26, Abhinav Kumar wrote:
On 10/30/2024 3:48 AM, Dmitry Baryshkov wrote:
On Tue, Oct 29,
On Fri, Nov 01, 2024 at 03:43:40PM +0200, Imre Deak wrote:
> On Fri, Nov 01, 2024 at 11:22:13AM +0200, Jani Nikula wrote:
> > On Thu, 31 Oct 2024, Imre Deak wrote:
> > > On Thu, Oct 31, 2024 at 05:12:45PM +0200, Abel Vesa wrote:
> > >> According to the DisplayPort standard, LTTPRs have two operati
Hi Ian,
On Fri, Nov 01, 2024 at 11:19:18AM -0700, Ian Rogers wrote:
> On Fri, Nov 1, 2024 at 6:24 AM Alejandro Colomar wrote:
> >
> > On Tue, Oct 15, 2024 at 02:17:17PM -0700, Ian Rogers wrote:
> > > When /proc/pid/fdinfo was part of proc.5 man page the indentation made
> > > sense. As a standalo
On Fri, Nov 01, 2024 at 12:19:03PM +0200, Dmitry Baryshkov wrote:
> The no_capture_mute flag might differ from platform to platform,
> especially in the case of the wrapping implementations, like the
> upcoming DRM HDMI Codec framework. Move the flag next to all other flags
> in struct hdmi_codec_p
When /proc/pid/fdinfo was part of proc.5 man page the indentation made
sense. As a standalone man page the indentation doesn't need to be so
far over to the right. Remove the initial tagged pragraph.
Suggested-by: G. Branden Robinson
Signed-off-by: Ian Rogers
---
man/man5/proc_pid_fdinfo.5 | 52
Make the sections about eventfd, epoll, signalfd, inotify, fanotify,
timerfd better separated with a clearer subsection header.
Signed-off-by: Ian Rogers
---
man/man5/proc_pid_fdinfo.5 | 6 ++
1 file changed, 6 insertions(+)
diff --git a/man/man5/proc_pid_fdinfo.5 b/man/man5/proc_pid_fdinfo
Add description of DRM fdinfo information based on the Linux kernel's
`Documentation/gpu/drm-usage-stats.rst`:
https://docs.kernel.org/gpu/drm-usage-stats.html
Signed-off-by: Ian Rogers
---
man/man5/proc_pid_fdinfo.5 | 94 ++
1 file changed, 94 insertions(+)
Previously the pid was highlighted through being a tagged paragraph
but not mentioned in the description. Add italics to the path
emphasizing pid and then change the first sentence to include pid in
the definition.
Suggested-by: G. Branden Robinson
Signed-off-by: Ian Rogers
---
man/man5/proc_pi
Hi Linus,
Regular fixes pull, nothing too out of the ordinary, the mediatek
fixes came in a batch that I might have preferred a bit earlier but
all seem fine, otherwise regular xe/amdgpu and a few misc ones.
Dave.
drm-fixes-2024-11-02:
drm fixes for 6.12-rc6
xe:
- Fix missing HPD interrupt enab
Add support for gamma LUT in VOP2 driver. The implementation was inspired
by one found in VOP1 driver. Blue and red channels in gamma LUT register
write were swapped with respect to how gamma LUT values are written in
VOP1. Gamma LUT port selection was added before the write of new gamma LUT
table.
On Fri, 1 Nov 2024 13:54:04 -0300 Maíra Canal wrote:
> This series introduces four patches related to the kernel parameters
> controlling mTHP and a fifth patch replacing `strcpy()` for `strscpy()`
> in the file `mm/huge_memory.c`.
Thanks. I extracted [1/1] from the series, as the first patch
Hi,
As per my previous patchsets, the goal of this work is to find a nice way to
allow amdgpu to perform async page flips in the overlay plane as well, not
only on the primary one. Currently, when using the atomic uAPI, this is the only
type of plane allowed to do async flips, and every driver acc
amdgpu can handle async flips on overlay planes, so allow it for atomic
async checks.
Signed-off-by: André Almeida
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pla
Currently, DRM atomic uAPI allows only primary planes to be flipped
asynchronously. However, each driver might be able to perform async
flips in other different plane types. To enable drivers to set their own
restrictions on which type of plane they can or cannot flip, use the
existing atomic_async
On Fri, Nov 1, 2024 at 6:24 AM Alejandro Colomar wrote:
>
> On Tue, Oct 15, 2024 at 02:17:17PM -0700, Ian Rogers wrote:
> > When /proc/pid/fdinfo was part of proc.5 man page the indentation made
> > sense. As a standalone man page the indentation doesn't need to be so
> > far over to the right. Re
On Mon, 28 Oct 2024 10:37:36 +0800, Liu Ying wrote:
> Document ITE IT6263 LVDS to HDMI converter.
>
> Product link:
> https://www.ite.com.tw/en/product/cate1/IT6263
>
> Signed-off-by: Liu Ying
> ---
> v4:
> * Require dual-lvds-odd-pixels or dual-lvds-even-pixels DT properties for
> port@1.
>
On Tue, Oct 29, 2024 at 05:37:45PM +1100, Alistair Popple wrote:
>
> Matthew Brost writes:
>
> > On Thu, Oct 17, 2024 at 12:51:08PM +1100, Alistair Popple wrote:
> >>
> >> Matthew Brost writes:
> >>
> >> > On Wed, Oct 16, 2024 at 03:00:08PM +1100, Alistair Popple wrote:
> >> >>
> >> >> Matth
On Tue, Oct 29, 2024 at 04:25:52PM +0800, Liu Ying wrote:
> On 10/29/2024, Biju Das wrote:
> >
> > Hi Liu Ying,
>
> Hi Biju,
>
> >
> >> -Original Message-
> >> From: dri-devel On Behalf Of Liu
> >> Ying
> >> Sent: 29 October 2024 07:35
> >> Subject: Re: [PATCH v4 08/13] dt-bindings: d
This series introduces four patches related to the kernel parameters
controlling mTHP and a fifth patch replacing `strcpy()` for `strscpy()`
in the file `mm/huge_memory.c`.
The first patch is a straightforward documentation update, correcting
the format of the kernel parameter ``thp_anon=``.
The
Replace strcpy() with strscpy() in mm/huge_memory.c
strcpy() has been deprecated because it is generally unsafe, so help to
eliminate it from the kernel source.
Link: https://github.com/KSPP/linux/issues/88
Signed-off-by: Maíra Canal
Reviewed-by: Lance Yang
---
mm/huge_memory.c | 4 ++--
1 fil
Add the ``thp_shmem=`` kernel command line to allow specifying the
default policy of each supported shmem hugepage size. The kernel parameter
accepts the following format:
thp_shmem=[KMG],[KMG]:;[KMG]-[KMG]:
For example,
thp_shmem=16K-64K:always;128K,512K:inherit;256K:advise;1M-2M:never;4M-8M:wi
In order to implement a kernel parameter similar to ``thp_anon=`` for
shmem, we'll need the function ``get_order_from_str()``.
Instead of duplicating the function, move the function to a shared
header, in which both mm/shmem.c and mm/huge_memory.c will be able to
use it.
Signed-off-by: Maíra Cana
Add a new kernel command line to control the hugepage allocation policy
for the internal shmem mount, ``transparent_hugepage_shmem``. The
parameter is similar to ``transparent_hugepage`` and has the following
format:
transparent_hugepage_shmem=
where is one of the seven valid policies availa
If we add ``thp_anon=32,64K:always`` to the kernel command line, we
will see the following error:
[0.00] huge_memory: thp_anon=32,64K:always: error parsing string,
ignoring setting
This happens because the correct format isn't
``thp_anon=,[KMG]:```,
as [KMG] must follow each number to e
From: Maíra Canal
In order to implement a kernel parameter similar to ``thp_anon=`` for
shmem, we'll need the function ``get_order_from_str()``.
Instead of duplicating the function, move the function to a shared
header, in which both mm/shmem.c and mm/huge_memory.c will be able to
use it.
Signe
Replace strcpy() with strscpy() in mm/huge_memory.c
strcpy() has been deprecated because it is generally unsafe, so help to
eliminate it from the kernel source.
Link: https://github.com/KSPP/linux/issues/88
Signed-off-by: Maíra Canal
Reviewed-by: Lance Yang
---
mm/huge_memory.c | 4 ++--
1 fil
Add the ``thp_shmem=`` kernel command line to allow specifying the
default policy of each supported shmem hugepage size. The kernel parameter
accepts the following format:
thp_shmem=[KMG],[KMG]:;[KMG]-[KMG]:
For example,
thp_shmem=16K-64K:always;128K,512K:inherit;256K:advise;1M-2M:never;4M-8M:wi
Add a new kernel command line to control the hugepage allocation policy
for the internal shmem mount, ``transparent_hugepage_shmem``. The
parameter is similar to ``transparent_hugepage`` and has the following
format:
transparent_hugepage_shmem=
where is one of the seven valid policies availa
This series introduces four patches related to the kernel parameters
controlling mTHP and a fifth patch replacing `strcpy()` for `strscpy()`
in the file `mm/huge_memory.c`.
The first patch is a straightforward documentation update, correcting
the format of the kernel parameter ``thp_anon=``.
The
If we add ``thp_anon=32,64K:always`` to the kernel command line, we
will see the following error:
[0.00] huge_memory: thp_anon=32,64K:always: error parsing string,
ignoring setting
This happens because the correct format isn't
``thp_anon=,[KMG]:```,
as [KMG] must follow each number to e
On 10/25/2024 11:58 AM, Dmitry Baryshkov wrote:
> On Thu, Oct 24, 2024 at 12:56:58AM +0530, Akhil P Oommen wrote:
>> On 10/22/2024 11:19 AM, Krzysztof Kozlowski wrote:
>>> On Mon, Oct 21, 2024 at 05:23:43PM +0530, Akhil P Oommen wrote:
Add a new schema which extends opp-v2 to support a new ven
On 10/31/2024 15:50, Antonio Quartulli wrote:
On 31/10/2024 20:37, Mario Limonciello wrote:
On 10/31/2024 10:28, Antonio Quartulli wrote:
acpi_evaluate_object() may return AE_NOT_FOUND (failure), which
would result in dereferencing buffer.pointer (obj) while being NULL.
Although this case may
On Fri 2024-10-25 11:46:16, Jocelyn Falempe wrote:
> On 25/10/2024 01:11, Jocelyn Falempe wrote:
> > On 24/10/2024 16:34, Petr Mladek wrote:
> > > On Wed 2024-10-23 14:00:13, Jocelyn Falempe wrote:
> > > > The console is already suspended in printk.c.
> > >
> > > Does this mean that drm_log_client
On Fri, Nov 01, 2024 at 11:58:29AM +, Will Deacon wrote:
> On Fri, Oct 18, 2024 at 02:19:26PM -0300, Jason Gunthorpe wrote:
> > Of the page table implementations (AMD v1/2, VT-D SS, ARM32, DART)
> > arm_lpae is unique in how it handles partial unmap of large IOPTEs.
> >
> > All other drivers w
On 11/1/2024 2:00 AM, Konrad Dybcio wrote:
> On 30.10.2024 8:02 AM, Akhil P Oommen wrote:
>> From: Puranam V G Tejaswi
>>
>> Add gpu and gmu nodes for sa8775p chipset. As of now all
>> SKUs have the same GPU fmax, so there is no requirement of
>> speed bin support.
>>
>> Signed-off-by: Puranam V G
From: Zichen Xie
Like commit b0b0d811eac6 ("drm/mediatek: Fix coverity issue with
unintentional integer overflow"), directly multiply args->pitch and
args->height may lead to integer overflow. Add a cast to avoid it.
Fixes: 3d7637423be8 ("drm/vc4: bo: Split out Dumb buffers fixup")
Signed-off-by
From: Jie Zhang
Add support for Adreno 612 GPU found in SM6150/QCS615 chipsets.
A612 falls under ADRENO_6XX_GEN1 family and is a cut down version
of A615 GPU.
A612 has a new IP called Reduced Graphics Management Unit or RGMU
which is a small state machine which helps to toggle GX GDSC
(connected
On Fri, Nov 01, 2024 at 12:27:15PM +0200, Dmitry Baryshkov wrote:
> On Fri, 1 Nov 2024 at 11:20, Laurent Pinchart wrote:
> > On Fri, Nov 01, 2024 at 11:49:07AM +0800, Sui Jingfeng wrote:
> > > On 2024/11/1 00:23, Johan Hovold wrote:
> > > > On Thu, Oct 31, 2024 at 11:06:38PM +0800, Sui Jingfeng wro
On Tue, Oct 29, 2024 at 05:48:58PM +0900, Gyeyoung Baek wrote:
if CONFIG_DRM_USE_DYNAMIC_DEBUG is set,
'drm_dbg' function is replaced with '__dynamic_func_call_cls',
which is replaced with a do while statement.
so in the previous code, there are the following build errors.
include/linux/dynamic_
We'd like to use the OVT modes for vmwgfx. Can you export the main OVT
function so it matches the CVT one? Something like this:
struct drm_display_mode *drm_ovt_mode(struct drm_device *dev, int rid,
int vrefresh);
On Mon, Sep 9, 2024 at 12:17 PM Hamza Mahfooz wrote:
>
> +
> +/* OVT Algorthim as
On Fri, Oct 18, 2024 at 02:19:26PM -0300, Jason Gunthorpe wrote:
> Of the page table implementations (AMD v1/2, VT-D SS, ARM32, DART)
> arm_lpae is unique in how it handles partial unmap of large IOPTEs.
>
> All other drivers will unmap the large IOPTE and return it's length. For
> example if a 2
The light_up_connector helper function in the HDMI infrastructure unit
tests uses drm_atomic_set_crtc_for_connector(), but fails when it
returns an error.
This function can return EDEADLK though if the sequence needs to be
restarted, and WW_MUTEX_SLOWPATH is meant to test that we handle it
properl
From: Fabio Estevam
imx6sx.dtsi has the following lcdif entries:
compatible = "fsl,imx6sx-lcdif", "fsl,imx28-lcdif";
This causes the following dt-schema warning:
['fsl,imx6sx-lcdif', 'fsl,imx28-lcdif'] is too long
To keep DT compatibility, document 'fsl,imx28-lcdif' as a possible
'fsl,imx6sx-
On Fri, Oct 18, 2024 at 02:19:26PM -0300, Jason Gunthorpe wrote:
> Of the page table implementations (AMD v1/2, VT-D SS, ARM32, DART)
> arm_lpae is unique in how it handles partial unmap of large IOPTEs.
>
> All other drivers will unmap the large IOPTE and return it's length. For
> example if a 2
From: Fabio Estevam
mx6sl.dtsi and imx6sll.dtsi have the following lcdif entries:
compatible = "fsl,imx6sl-lcdif", "fsl,imx28-lcdif";
This causes dt-schema warnings as the current binding only
allow 'fsl,imx6sx-lcdif' as fallback.
['fsl,imx6sl-lcdif', 'fsl,imx28-lcdif'] is too long
['fsl,imx6s
From: Fabio Estevam
The LCDIF IP on i.MX6SL and i.MX6SLL is compatible with i.MX6SX.
Provide a more specific "fsl,imx6sx-lcdif" compatible and still keep
"fsl,imx28-lcdif" for DT compatibility.
Signed-off-by: Fabio Estevam
---
Changes since v3:
- None.
arch/arm/boot/dts/nxp/imx/imx6sl.dtsi
Hi,
On Wed, Oct 30, 2024 at 05:03:50AM +1000, Dave Airlie wrote:
> Hi,
>
> I mentioned this internally, but wanted to get it on the list,
>
> I ran the hdmi kunit tests with LOCKDEP and WW_MUTEX_SLOWPATH enabled
> and hit some issues.
>
> With the slowpath we get the occasional EDEADLK to test
On Fri, Nov 01, 2024 at 11:22:13AM +0200, Jani Nikula wrote:
> On Thu, 31 Oct 2024, Imre Deak wrote:
> > On Thu, Oct 31, 2024 at 05:12:45PM +0200, Abel Vesa wrote:
> >> According to the DisplayPort standard, LTTPRs have two operating
> >> modes:
> >> - non-transparent - it replies to DPCD LTTPR f
On Tue, Oct 15, 2024 at 02:17:17PM -0700, Ian Rogers wrote:
> When /proc/pid/fdinfo was part of proc.5 man page the indentation made
> sense. As a standalone man page the indentation doesn't need to be so
> far over to the right. Remove the initial tagged pragraph and move the
> styling to the init
On Fri, Nov 01, 2024 at 12:59:38PM +0200, Jani Nikula wrote:
> On Fri, 01 Nov 2024, Dmitry Baryshkov wrote:
> > The HDMI Connectors need to perform a variety of tasks when the HDMI
> > connector state changes. Such tasks include setting or invalidating CEC
> > address, notifying HDMI codec driver,
Hi Jason,
On Thu, Oct 24, 2024 at 10:44:11AM -0300, Jason Gunthorpe wrote:
> On Thu, Oct 24, 2024 at 02:05:53PM +0100, Will Deacon wrote:
>
> > My recollection is hazy, but I seem to remember VFIO using the largest
> > page sizes in the IOMMU 'pgsize_bitmap' for map() requests but then
> > using
Rather than relying on the TTM watermark accounting add a shrinker
for xe_bos in TT or system memory.
Leverage the newly added TTM per-page shrinking and shmem backup
support.
Although xe doesn't fully support WONTNEED (purgeable) bos yet,
introduce and add shrinker support for purgeable ttm_tts.
The XE_PL_TT watermark was set to 50% of system memory.
The idea behind that was unclear since the net effect is that
TT memory will be evicted to TTM_PL_SYSTEM memory if that
watermark is exceeded, requiring PPGTT rebinds and dma
remapping. But there is no similar watermark for TTM_PL_1SYSTEM
memo
This series implements TTM shrinker / eviction helpers and an xe bo
shrinker. It builds on a previous series, *and obsoletes that one*.
https://lore.kernel.org/linux-mm/b7491378-defd-4f1c-31e2-29e4c77e2...@amd.com/T/
Where the comment about layering
https://lore.kernel.org/linux-mm/b7491378-defd-
Provide a helper to shrink ttm_tt page-vectors on a per-page
basis. A ttm_backup backend could then in theory get away with
allocating a single temporary page for each struct ttm_tt.
This is accomplished by splitting larger pages before trying to
back them up.
In the future we could allow ttm_bac
Following the design direction communicated here:
https://lore.kernel.org/linux-mm/b7491378-defd-4f1c-31e2-29e4c77e2...@amd.com/T/#ma918844aa8a6efe8768fdcda0c6590d5c93850c9
Export a LRU walker for driver shrinker use. The walker
initially supports only trylocking, since that's the
method used by
Add a number of helpers for shrinking that access core TTM and
core MM functionality in a way that make them unsuitable for
driver open-coding.
v11:
- New patch (split off from previous) and additional helpers.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Brost
---
drivers/gpu/drm/ttm/
Use fault-injection to test partial TTM swapout and interrupted swapin.
Return -EINTR for swapin to test the callers ability to handle and
restart the swapin, and on swapout perform a partial swapout to test that
the swapin and release_shrunken functionality.
v8:
- Use the core fault-injection sys
Make the interface more symmetric by providing and using a
ttm_resource_cursor_init().
v10:
- Fix a stray newline (Matthew Brost)
- Update kerneldoc (Matthew Brost)
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Brost
Reviewed-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c |
Initially intended for experimenting with different backup
solutions (shmem vs direct swap cache insertion), abstract
the backup destination using a virtual base class.
Also provide a sample implementation for shmem.
While when settling on a preferred backup solution, one could
perhaps skip the a
On Fri, 01 Nov 2024, Dmitry Baryshkov wrote:
> The HDMI Connectors need to perform a variety of tasks when the HDMI
> connector state changes. Such tasks include setting or invalidating CEC
> address, notifying HDMI codec driver, updating scrambler data, etc.
>
> Implementing such tasks in a drive
From: baihan li
Add dp aux read/write functions. They are basic functions
and will be used later.
Signed-off-by: baihan li
Signed-off-by: yongbang shi
---
ChangeLog:
v2 -> v3:
- put the macro definations in latter patch where they are actually used,
suggested by Dmitry Baryshkov.
- rename
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 the same
mother
From: baihan li
Add link training process functions in this moduel.
Signed-off-by: baihan li
Signed-off-by: yongbang shi
---
Changelog:
v2 -> v3:
- using switchcase in dp_link_reduce_lane, suggested by Dmitry Baryshkov.
- deleting dp_link_pattern2dpcd function and using macros directly, su
From: baihan li
Build a dp level that hibmc driver can enable dp by
calling their functions.
Signed-off-by: baihan li
Signed-off-by: yongbang shi
---
ChangeLog:
v2 -> v3:
- fix build errors reported by kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202410250931.udq9s66
From: baihan li
To support DP interface displaying in hibmc driver. Add
a encoder and connector for DP modual.
Signed-off-by: baihan li
Signed-off-by: yongbang shi
---
ChangeLog:
v2 -> v3:
- fix build errors reported by kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/20
Hi Dave and Simona,
drm-xe-fixes for 6.12-rc6. Two important fixes for LNL and one missing
hpd enabling. This last one brought in a refactor as dependency,
otherwise it would cause some headache with conflicts.
thanks
Lucas De Marchi
drm-xe-fixes-2024-10-31:
Driver Changes:
- Fix missing HPD in
On Fri, 1 Nov 2024 at 11:20, Laurent Pinchart
wrote:
>
> On Fri, Nov 01, 2024 at 11:49:07AM +0800, Sui Jingfeng wrote:
> >
> > On 2024/11/1 00:23, Johan Hovold wrote:
> > > On Thu, Oct 31, 2024 at 11:06:38PM +0800, Sui Jingfeng wrote:
> > >
> > >> But I think Johan do need more times to understand
Several DRM drivers implement HDMI codec support (despite its name it
applies to both HDMI and DisplayPort drivers). Implement generic
framework to be used by these drivers. This removes a requirement to
implement get_eld() callback and provides default implementation for
codec's plug handling.
Th
While porting lt9611 DSI-to-HDMI bridge driver to use HDMI Connector
framework, I stumbled upon an issue while handling the Audio InfoFrames.
The HDMI codec callbacks weren't receiving the drm_atomic_state, so
there was no simple way to get the drm_connector that stayed at the end
of the bridge cha
The HDMI Connectors need to perform a variety of tasks when the HDMI
connector state changes. Such tasks include setting or invalidating CEC
address, notifying HDMI codec driver, updating scrambler data, etc.
Implementing such tasks in a driver-specific callbacks is error prone.
Start implementing
Add necessary glue code to be able to use new HDMI codec framework from
the DRM bridge drivers. The drm_bridge implements a limited set of the
hdmi_codec_ops interface, with the functions accepting both
drm_connector and drm_bridge instead of just a generic void pointer.
This framework is integrat
Extend drm_bridge_connector code to read the EDID and use it to update
connector status if the bridge chain implements HDMI bridge. Performing
it from the generic location minimizes individual bridge's code and
enforces standard behaviour from all corresponding drivers.
Signed-off-by: Dmitry Barys
The no_capture_mute flag might differ from platform to platform,
especially in the case of the wrapping implementations, like the
upcoming DRM HDMI Codec framework. Move the flag next to all other flags
in struct hdmi_codec_pdata.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/bridge/ite-it
The upcoming DRM connector HDMI codec implementation is going to use
codec-specific data in the .get_dai_id to get drm_connector. Pass data
to the callback, as it is done with other hdmi_codec_ops callbacks.
Acked-by: Mark Brown
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/bridge/adv7511
1 - 100 of 112 matches
Mail list logo
