PCI subsystem provides callbacks to inform the driver about a request to
do function level reset by user, initiated by writing to sysfs entry
/sys/bus/pci/devices/.../reset. This will allow the driver to handle FLR
without the need to do unbind and rebind as the driver needs to
reinitialize the dev
This would be used in other places outside of gt_reset path.
v2:
1. Add kernel doc for xe_gt_idle (Michal)
2. fix return as no actual error is reported by xe_uc_stop (Himal)
Cc: Lucas De Marchi
Cc: Michal Wajdeczko
Cc: Himal Prasad Ghimiray
Reviewed-by: Rodrigo Vivi
Signed-off-by: Aravind Id
Save and restore PCI states where ever needed.
Cc: Lucas De Marchi
Reviewed-by: Rodrigo Vivi
Signed-off-by: Aravind Iddamsetty
---
drivers/gpu/drm/xe/xe_device_types.h | 3 ++
drivers/gpu/drm/xe/xe_pci.c | 48 ++--
drivers/gpu/drm/xe/xe_pci.h | 4 ++
In scenarios where drm_dev_put is directly called by driver we want to
release devm_drm_dev_init_release action associated with struct
drm_device.
v2: Directly expose the original function, instead of introducing a
helper (Rodrigo)
v3: add kernel-doc (Maxime Ripard)
Cc: Maxime Ripard
Cc: Thomas
PCI subsystem provides callbacks to inform the driver about a request to
do function level reset by user, initiated by writing to sysfs entry
/sys/bus/pci/devices/.../reset. This will allow the driver to handle FLR
without the need to do unbind and rebind as the driver needs to
reinitialize the dev
On Sun, 21 Apr 2024 17:39:47 +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 object
Thanks Maíra, this patch is:
Reviewed-by: Iago Toral Quiroga
Iago
El dom, 21-04-2024 a las 18:44 -0300, Maíra Canal escribió:
> Currently, we are using an alignment of 128 kB to insert a node,
> which
> ends up wasting memory as we perform plenty of small BOs allocations
> (<= 4 kB). We require
Add support for the following panel:
CSOT MNB601LS1-1
Signed-off-by: Xuxin Xiong
---
drivers/gpu/drm/panel/panel-edp.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-edp.c
b/drivers/gpu/drm/panel/panel-edp.c
index d58f90bc48fb..5e0b1c94bc62 100644
--- a/driver
Some boards(like Oland PRO: 0x1002:0x6613) seem to have
garbage in the upper 16 bits of the vram size register,
kern log as follows:
[6.00] [drm] Detected VRAM RAM=2256537600M, BAR=256M
[6.007812] [drm] RAM width 64bits GDDR5
[6.031250] [drm] amdgpu: 2256537600M of VRAM memory read
On Wed, Apr 03, 2024 at 12:56:21PM +0200, Maxime Ripard wrote:
> Commit 4fc8cb47fcfd ("drm/display: Move HDMI helpers into display-helper
> module") turned the DRM_DW_HDMI dependency of DRM_IMX_HDMI into a
> depends on which ended up disabling the driver in the defconfig. Make
> sure it's still ena
On Wed, 2024-03-27 at 21:06 +, Benno Lossin wrote:
> On 22.03.24 23:03, Lyude Paul wrote:
> > diff --git a/drivers/gpu/drm/rvkms/connector.rs
> > b/drivers/gpu/drm/rvkms/connector.rs
> > new file mode 100644
> > index 0..40f84d38437ee
> > --- /dev/null
> > +++ b/drivers/gpu/drm/rvkm
On Wed, 2024-03-27 at 20:50 +, Benno Lossin wrote:
> Hi,
>
> I just took a quick look and commented on the things that stuck
> out to me. Some general things:
> - several `unsafe` blocks have missing SAFETY comments,
> - missing documentation and examples.
This is really early on - so I had w
Hi all,
On Tue, 30 Jan 2024 13:56:26 +1100 Stephen Rothwell
wrote:
>
> After merging the amdgpu tree, today's linux-next build (htmldocs)
> produced this warning:
>
> drivers/gpu/drm/amd/display/dc/link/hwss/link_hwss_dio.h:1: warning: no
> structured comments found
> drivers/gpu/drm/amd/disp
Hi all,
On Tue, 30 Jan 2024 13:54:21 +1100 Stephen Rothwell
wrote:
>
> Hi all,
>
> After merging the amdgpu tree, today's linux-next build (htmldocs)
> produced this warning:
>
> drivers/gpu/drm/amd/display/dc/inc/hw/opp.h:1: warning: no structured
> comments found
> drivers/gpu/drm/amd/displ
Hi all,
On Tue, 30 Jan 2024 13:49:54 +1100 Stephen Rothwell
wrote:
>
> After merging the amdgpu tree, today's linux-next build (htmldocs)
> produced these warnings:
>
> drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:132: warning: Incorrect use of
> kernel-doc format: * @@overlap_only: Wh
On Sat, Apr 20, 2024 at 04:02:00PM -0700, Abhinav Kumar wrote:
>
>
> On 4/19/2024 7:33 PM, Dmitry Baryshkov wrote:
> > MSM display drivers provide kms structure allocated during probe().
> > Don't clean up priv->kms field in case of an error. Otherwise probe
> > functions might fail after KMS pro
On Fri, 29 Mar 2024 08:45:53 +0100, Luca Weiss wrote:
> Add the required changes to support DisplayPort (normally(?) available
> via the USB-C connector) on the SM6350/SM7225 SoC.
>
> This has been tested on a Fairphone 4 smartphone with additional changes
> not included in this series (mostly j
Hi all,
Fetching the drm tree produced this warning:
Commit
326e30e4624c ("drm/i915: Drop dead code for pvc")
added this unexpected file:
drivers/gpu/drm/i915/gt/intel_workarounds.c.rej
--
Cheers,
Stephen Rothwell
pgpp13acamnrT.pgp
Description: OpenPGP digital signature
Add a modparam for turning off Big/Super Pages to make sure that if an
user doesn't want Big/Super Pages enabled, it can disabled it by setting
the modparam to false.
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/v3d/v3d_drv.c | 8
drivers/gpu/drm/v3d/v3d_gemfs.c | 5 +
2 files c
Although Big/Super Pages could appear naturally, it would be quite hard
to have 1MB or 64KB allocated contiguously naturally. Therefore, we can
force the creation of large pages allocated contiguously by using a
mountpoint with "huge=within_size" enabled.
As V3D has a mountpoint with "huge=within_
The V3D MMU also supports 64KB and 1MB pages, called big and super pages,
respectively. In order to set a 64KB page or 1MB page in the MMU, we need
to make sure that page table entries for all 4KB pages within a big/super
page must be correctly configured.
In order to create a big/super page, we n
Create a function `drm_gem_shmem_create_with_mnt()`, similar to
`drm_gem_shmem_create()`, that has a mountpoint as a argument. This
function will create a shmem GEM object in a given tmpfs mountpoint.
This function will be useful for drivers that have a special mountpoint
with flags enabled.
Sign
Currently, we are using an alignment of 128 kB to insert a node, which
ends up wasting memory as we perform plenty of small BOs allocations
(<= 4 kB). We require that allocations are aligned to 128Kb so for any
allocation smaller than that, we are wasting the difference.
This implies that we canno
This series introduces support for big and super pages in V3D. The V3D MMU has
support for 64KB and 1MB pages, called big pages and super pages, which are
currently not used. Therefore, this patchset has the intention to enable big and
super pages in V3D. The advantage of enabling big and super pag
For some applications, such as applications that uses huge pages, we might
want to have a different mountpoint, for which we pass mount flags that
better match our usecase.
Therefore, create a new function `drm_gem_object_init_with_mnt()` that
allow us to define the tmpfs mountpoint where the GEM
Create a separate "tmpfs" kernel mount for V3D. This will allow us to
move away from the shmemfs `shm_mnt` and gives the flexibility to do
things like set our own mount options. Here, the interest is to use
"huge=", which should allow us to enable the use of THP for our
shmem-backed objects.
Signe
If the scheduler initialization fails, GEM initialization must fail as
well. Therefore, if `v3d_sched_init()` fails, free the DMA memory
allocated and return the error value in `v3d_gem_init()`.
Signed-off-by: Maíra Canal
Reviewed-by: Iago Toral Quiroga
---
drivers/gpu/drm/v3d/v3d_gem.c | 3 ++-
Dne petek, 19. april 2024 ob 15:36:17 GMT +2 je Ondřej Jirman napisal(a):
> Hi,
>
> On Sat, Feb 24, 2024 at 04:05:57PM GMT, megi xff wrote:
> > From: Ondrej Jirman
> >
> > This series refactors blender setup from individual planes to a common
> > place where it can be performed at once and is ea
On Sun, Apr 21, 2024 at 06:40:48AM +0530, Dharma Balasubiramani wrote:
> Add a new LVDS controller driver for sam9x7 which does the following:
> - Prepares and enables the LVDS Peripheral clock
> - Defines its connector type as DRM_MODE_CONNECTOR_LVDS and adds itself
> to the global bridge list.
>
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 callback would eventually try taking
the lock on the same
On Sun, Apr 21, 2024 at 04:25:34PM GMT, Marek Vasut wrote:
> On 4/21/24 1:09 PM, Ondřej Jirman wrote:
> > Hi,
>
> Hi,
>
> > On Sun, Apr 21, 2024 at 02:22:35AM GMT, Marek Vasut wrote:
> > > Doing modeset in .atomic_pre_enable callback instead of dedicated
> > > .mode_set
> > > callback does not s
On 2/12/24 12:09 AM, Adam Ford wrote:
The P divider should be set based on the min and max values of
the fin pll which may vary between different platforms.
These ranges are defined per platform, but hard-coded values
were used instead which resulted in a smaller range available
on the i.MX8M[MNP
On 2/12/24 12:09 AM, Adam Ford wrote:
When using video sync pulses, the HFP, HBP, and HSA are divided between
the available lanes if there is more than one lane. For certain
timings and lane configurations, the HFP may not be evenly divisible.
If the HFP is rounded down, it ends up being too sma
On 4/21/24 1:09 PM, Ondřej Jirman wrote:
Hi,
Hi,
On Sun, Apr 21, 2024 at 02:22:35AM GMT, Marek Vasut wrote:
Doing modeset in .atomic_pre_enable callback instead of dedicated .mode_set
callback does not seem right. Undo this change, which was added as part of
Actually no. If anything, mode_
Hi Adam,
Thank you for the patch.
On Sat, Apr 20, 2024 at 06:28:31AM -0500, Adam Ford wrote:
> When enabling i.MX8MP DWC HDMI driver, it automatically selects
> PHY_FSL_SAMSUNG_HDMI_PHY, since it wont' work without the phy.
> This may cause some Kconfig warnings during various build tests.
> Fix
Hi,
On Sun, Apr 21, 2024 at 02:22:35AM GMT, Marek Vasut wrote:
> Doing modeset in .atomic_pre_enable callback instead of dedicated .mode_set
> callback does not seem right. Undo this change, which was added as part of
Actually no. If anything, mode_set callback should be dropped entirely:
See ht
`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.
Signed-off-by: Shresth Prasad
---
Changes in v2:
- Change commit header and body to better reflect changes
- Remove call to of_n
Agreed, thanks for doing this, Christian.
Reviewed-by: Tomeu Vizoso
Cheers,
Tomeu
On Sat, Apr 20, 2024 at 3:41 PM Christian Gmeiner
wrote:
>
> From: Christian Gmeiner
>
> This reverts commit 1dccdba084897443d116508a8ed71e0ac8a031a4.
>
> In userspace a different approach was choosen - hwdb. A
39 matches
Mail list logo
