Another function to pass drm_device * down to so we can start using the
drm_dbg_*() in the DRM DP helpers.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_dual_mode_helper.c | 5 +++--
include/drm/drm_dp_dual_mode_helper.h | 2 +-
2 files changed, 4 insertions(+), 3 deletions(-)
diff -
Another function we need to pass drm_device down to in order to start using
drm_dbg_*().
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_dual_mode_helper.c | 3 ++-
drivers/gpu/drm/i915/display/intel_hdmi.c | 2 +-
include/drm/drm_dp_dual_mode_helper.h | 2 +-
3 files changed, 4 inserti
Next step in the conversion, move everything in drm_dp_dual_mode_helper.c
over to using drm_err() and drm_dbg_kms(). This was done using the
following cocci script:
@@
expression list expr;
@@
(
- DRM_DEBUG_KMS(expr);
+ drm_dbg_kms(dev, expr);
|
- DRM_ERROR(expr);
+ drm_err(dev,
Now that we've added a back-pointer to drm_device to drm_dp_aux, made
drm_dp_aux available to any functions in drm_dp_helper.c which need to
print to the kernel log, and ensured all of our logging uses a consistent
format, let's do the final step of the conversion and actually move
everything over
Since this is one of the few functions in drm_dp_mst_topology.c that
doesn't have any way of getting access to a drm_device, let's pass the
drm_dp_mst_topology_mgr down to this function so that it can use
drm_dbg_kms().
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_mst_topology.c |
While this shouldn't really be something that happens all that often, since
we're going to be using the drm_dbg_* log helpers in DRM helpers it's
technically possible that a driver could use an AUX adapter before it's
been associated with it's respective drm_device. While drivers should take
care t
And finally, convert all of the code in drm_dp_mst_topology.c over to using
drm_err() and drm_dbg*(). Note that this refactor would have been a lot
more complicated to have tried writing a coccinelle script for, so this
whole thing was done by hand.
v2:
* Fix line-wrapping in drm_dp_mst_atomic_che
On Wed, Apr 21, 2021 at 1:43 PM Kai-Heng Feng
wrote:
>
> When an amdgpu device fails to init, it makes another VGA device cause
> kernel splat:
> kernel: amdgpu :08:00.0: amdgpu: amdgpu_device_ip_init failed
> kernel: amdgpu :08:00.0: amdgpu: Fatal error during GPU init
> kernel: amdgpu: p
Increase the minor version to indicate that MSM_PARAM_SUSPENDS is supported.
Fixes: 3ab1c5cc3939 ("drm/msm: Add param for userspace to query suspend count")
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/msm_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers
No one knows what this is for anymore, so just remove it.
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/msm_gem.c | 15 +++
1 file changed, 3 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index b199942266a2..09abda4
Add support for MSM_BO_CACHED_COHERENT, a coherent version of MSM_BO_CACHED
which is implemented by setting the IOMMU_CACHE flag.
Jonathan Marek (5):
drm/msm: remove unnecessary mmap logic for cached BOs
drm/msm: replace MSM_BO_UNCACHED with MSM_BO_WC for internal objects
drm/msm: use the ri
msm_gem_get_vaddr() currently always maps as writecombine, so use the right
flag instead of relying on broken behavior (things don't actually work if
they are mapped as uncached).
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 4 ++--
drivers/gpu/drm/msm/adreno/a
Use the same logic as the userspace mapping.
This fixes msm_rd with cached BOs.
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/msm_gem.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
Add a new cache mode for creating coherent host-cached BOs.
Signed-off-by: Jonathan Marek
Reviewed-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 1 +
drivers/gpu/drm/msm/msm_drv.c | 3 ++-
drivers/gpu/drm/msm/msm_drv.h | 1 +
drivers/gpu/drm/msm/ms
There shouldn't be any reason to ever use uncached over writecombine,
so just use writecombine for MSM_BO_UNCACHED.
Note: userspace never used MSM_BO_UNCACHED anyway
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/msm_gem.c | 4 +---
include/uapi/drm/msm_drm.h| 2 +-
2 files changed,
On Wed, Apr 21, 2021 at 2:40 AM Stephen Rothwell wrote:
>
> Hi all,
>
> On Fri, 16 Apr 2021 12:40:44 +1000 Stephen Rothwell
> wrote:
> >
> > After merging the amdgpu tree, today's linux-next build (powerpc
> > ppc64_defconfig) produced this warning:
> >
> > drivers/pci/quirks.c: In function 'qui
Kernel test robot throws below warning ->
>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_debugfs.c:3015:53:
>> warning: address of 'aconnector->mst_port->mst_mgr' will always
>> evaluate to 'true' [-Wpointer-bool-conversion]
if (!(aconnector->port &&
&aconn
Some trivia, no comment on the real logic of the changes:
On Fri, Apr 23, 2021 at 2:43 PM Lyude Paul wrote:
>
> Since AUX adapters on nouveau have their respective DRM connectors as
> parents, we need to make sure that we register then after their connectors.
then -> them
>
> Signed-off-by: Lyu
On 4/23/21 8:11 AM, Pekka Paalanen wrote:
> On Thu, 22 Apr 2021 15:10:04 -0300
> Leandro Ribeiro wrote:
>
>> Add a small description and document struct fields of
>> drm_mode_get_plane.
>>
>> Signed-off-by: Leandro Ribeiro
>> ---
>> include/uapi/drm/drm_mode.h | 16
>> 1 fil
When DRM_RCAR_DU=y and DRM_RCAR_LVDS=m, there are several build errors
as reported by 'kernel test robot'. These can be corrected by changing
"imply" to "select".
In looking at this, the same problem (build errors) happens when
DRM_RCAR_DU=y and DRM_RCAR_CMM=m, so again change the "imply" to
"sele
Kernel test robot throws below warning ->
>> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c:125:5: warning:
>> no previous prototype for 'kgd_arcturus_hqd_sdma_load'
>> [-Wmissing-prototypes]
125 | int kgd_arcturus_hqd_sdma_load(struct kgd_dev *kgd, void
*mqd,
>> drivers/gpu/drm/amd/amd
Hi Randy,
Thank you for the patch.
On Fri, Apr 23, 2021 at 02:37:27PM -0700, Randy Dunlap wrote:
> When DRM_RCAR_DU=y and DRM_RCAR_LVDS=m, there are several build errors
> as reported by 'kernel test robot'. These can be corrected by changing
> "imply" to "select".
>
> In looking at this, the sa
The backlight level of an eDP panel can be controlled through the AUX
channel using DPCD registers of the panel.
The capability for the Source device to adjust backlight characteristics
within the panel, using the Sink device DPCD registers is indicated by
the TCON_BACKLIGHT_ADJUSTMENT_CAPABLE bit
Add backlight driver for the panels supporting backlight control
using DPCD registers on the DisplayPort aux channel.
Changes in v2:
- New (most of the code reused from drm_dp_aux_backlight.c of v1)
Signed-off-by: Rajeev Nandan
---
drivers/video/backlight/Kconfig| 7 +
drivers/vid
Add bindings for DisplayPort aux backlight driver.
Changes in v2:
- New
Signed-off-by: Rajeev Nandan
---
.../bindings/leds/backlight/dp-aux-backlight.yaml | 49 ++
1 file changed, 49 insertions(+)
create mode 100644
Documentation/devicetree/bindings/leds/backlight/dp-aux-
On 4/23/21 2:46 PM, Laurent Pinchart wrote:
Hi Randy,
Thank you for the patch.
On Fri, Apr 23, 2021 at 02:37:27PM -0700, Randy Dunlap wrote:
When DRM_RCAR_DU=y and DRM_RCAR_LVDS=m, there are several build errors
as reported by 'kernel test robot'. These can be corrected by changing
"imply" to
On 4/23/21 2:56 PM, Randy Dunlap wrote:
On 4/23/21 2:46 PM, Laurent Pinchart wrote:
Hi Randy,
Thank you for the patch.
On Fri, Apr 23, 2021 at 02:37:27PM -0700, Randy Dunlap wrote:
When DRM_RCAR_DU=y and DRM_RCAR_LVDS=m, there are several build errors
as reported by 'kernel test robot'. These
Hi Randy,
On Fri, Apr 23, 2021 at 03:02:27PM -0700, Randy Dunlap wrote:
> On 4/23/21 2:56 PM, Randy Dunlap wrote:
> > On 4/23/21 2:46 PM, Laurent Pinchart wrote:
> >> On Fri, Apr 23, 2021 at 02:37:27PM -0700, Randy Dunlap wrote:
> >>> When DRM_RCAR_DU=y and DRM_RCAR_LVDS=m, there are several build
This reverts commit 88be76cdafc7 ("drm/i915: Allow userspace to specify
ringsize on construction"). This API was originally added for OpenCL
but the compute-runtime PR has sat open for a year without action so we
can still pull it out if we want. I argue we should drop it for three
reasons:
1.
Overview:
-
This patch series attempts to clean up some of the IOCTL mess we've created
over the last few years. The most egregious bit being context mutability.
In summary, this series:
1. Drops two never-used context params: RINGSIZE and NO_ZEROMAP
2. Drops the entire CONTEXT_CLONE A
The idea behind this param is to support OpenCL drivers with relocations
because OpenCL reserves 0x0 for NULL and, if we placed memory there, it
would confuse CL kernels. It was originally sent out as part of a patch
series including libdrm [1] and Beignet [2] support. However, the
libdrm and Bei
Instead of handling it like a context param, unconditionally set it when
intel_contexts are created. This doesn't fix anything but does simplify
the code a bit.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 43 +++
.../gpu/drm/i915/gem/i915_ge
None of the callbacks we use with it return an error code anymore; they
all return 0 unconditionally.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 26 +++--
1 file changed, 8 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/
This API is entirely unnecessary and I'd love to get rid of it. If
userspace wants a single timeline across multiple contexts, they can
either use implicit synchronization or a syncobj, both of which existed
at the time this feature landed. The justification given at the time
was that it would he
This has never been used by any userspace except IGT and provides no
real functionality beyond parroting back parameters userspace passed in
as part of context creation or via setparam. If the context is in
legacy mode (where you use I915_EXEC_RENDER and friends), it returns
success with zero data
This API allows one context to grab bits out of another context upon
creation. It can be used as a short-cut for setparam(getparam()) for
things like I915_CONTEXT_PARAM_VM. However, it's never been used by any
real userspace. It's used by a few IGT tests and that's it. Since it
doesn't add any
This adds a bunch of complexity which the media driver has never
actually used. The media driver does technically bond a balanced engine
to another engine but the balanced engine only has one engine in the
sibling set. This doesn't actually result in a virtual engine.
Unless some userspace badly
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 42 +
1 file changed, 27 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 941fbf78267b4..e5efd22c89ba2 1
This was only ever used for bonded virtual engine execution. Since
that's no longer allowed, this is dead code.
Signed-off-by: Jason Ekstrand
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 3 +-
drivers/gpu/drm/i915/i915_request.c | 42 ---
drivers/gpu/drm/i915/i
There's no sense in allowing userspace to create more engines than it
can possibly access via execbuf.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_contex
As far as I can tell, the only real reason for this is to avoid taking a
reference to the i915_gem_context. The cost of those two atomics
probably pales in comparison to the cost of the ioctl itself so we're
really not buying ourselves anything here. We're about to make context
lookup a tiny bit
There's a big comment saying how useful it is but no one is using this
for anything.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 9 -
drivers/gpu/drm/i915/gt/intel_gtt.h | 10 --
drivers/gpu/drm/i915/selftests/mock_gtt.c | 1 -
3 fi
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 143 ++
.../gpu/drm/i915/gem/i915_gem_context_types.h | 21 +++
.../gpu/drm/i915/gem/selftests/mock_context.c | 16 +-
3 files changed, 150 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/
We're about to start doing lazy context creation which means contexts
get created in i915_gem_context_lookup and we may start having more
errors than -ENOENT.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c| 12 ++--
drivers/gpu/drm/i915/gem/i915_gem_exe
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 267 --
.../gpu/drm/i915/gem/i915_gem_context_types.h | 2 +-
.../drm/i915/gem/selftests/i915_gem_context.c | 119
.../drm/i915/selftests/i915_mock_selftests.h | 1 -
4 files changed, 1
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 301
1 file changed, 301 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 3238260cffa31..ef23ab4260c24 100644
--- a/drive
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 657 --
drivers/gpu/drm/i915/gem/i915_gem_context.h | 3 +
.../gpu/drm/i915/gem/i915_gem_context_types.h | 26 +
.../gpu/drm/i915/gem/selftests/mock_context.c | 5 +-
drivers/gpu/drm/i915/i915
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
index 76029d7143f6c..76dd
Now that we have the whole engine set and VM at context creation time,
we can just assign those fields instead of creating first and handling
the VM and engines later. This lets us avoid creating useless VMs and
engine sets and lets us git rid of the complex VM setting code.
Signed-off-by: Jason
Signed-off-by: Jason Ekstrand
---
.../drm/i915/gem/selftests/i915_gem_context.c | 4 ++--
.../gpu/drm/i915/gem/selftests/mock_context.c | 8 +++-
.../gpu/drm/i915/gem/selftests/mock_context.h | 4 +++-
drivers/gpu/drm/i915/gt/selftest_execlists.c | 20 +--
drivers/gpu/drm/
Hi Alex,
On Fri, 23 Apr 2021 16:36:50 -0400 Alex Deucher wrote:
>
> On Wed, Apr 21, 2021 at 2:40 AM Stephen Rothwell
> wrote:
> >
> > On Fri, 16 Apr 2021 12:40:44 +1000 Stephen Rothwell
> > wrote:
> > >
> > > After merging the amdgpu tree, today's linux-next build (powerpc
> > > ppc64_defco
Hi Dave, Daniel,
Fixes for 5.13.
The following changes since commit af8352f1ff54c4fecf84e36315fd1928809a580b:
Merge tag 'drm-msm-next-2021-04-11' of https://gitlab.freedesktop.org/drm/msm
into drm-next (2021-04-13 23:35:54 +0200)
are available in the Git repository at:
https://gitlab.free
Prologue
This is series #3 in part of a larger work that arose from the minor
remark that the mdev_parent_ops indirection shim is useless and
complicates things.
It applies on top of Alex's current tree and requires the prior two
series.
This series achieves the removal of vfio_mdev.c.
For some reason the vfio_mdev shim mdev_driver has its own module and
kconfig. As the next patch requires access to it from mdev.ko merge the
two modules together and remove VFIO_MDEV_DEVICE.
A later patch deletes this driver entirely.
This also fixes a misuse of kconfig in the samples which prev
The last useful member in this struct is the supported_type_groups, move
it to the mdev_driver and delete mdev_parent_ops.
Replace it with mdev_driver as an argument to mdev_register_device()
Signed-off-by: Jason Gunthorpe
---
.../driver-api/vfio-mediated-device.rst | 36 +++--
While there is a confusing mess of pointers and structs in this driver,
the struct kvmgt_vdev (which in turn is 1:1 with a struct intel_vgpu) is
what holds the vfio_device. Replace all the drvdata's and weird
derivations of vgpu and vdev with container_of() or vdev->vgpu.
Signed-off-by: Jason Gunt
Am 2021-04-23 um 5:39 p.m. schrieb Souptick Joarder:
> Kernel test robot throws below warning ->
>
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c:125:5: warning:
>>> no previous prototype for 'kgd_arcturus_hqd_sdma_load'
>>> [-Wmissing-prototypes]
> 125 | int kgd_arcturus_hqd_sdma_loa
Hi, Jitao:
Jitao Shi 於 2021年4月20日 週二 下午9:26寫道：
>
> Reset dsi HW to default when power on. Prevent the setting differet
> between bootloader and kernel.
>
> Signed-off-by: Jitao Shi
> ---
> drivers/gpu/drm/mediatek/mtk_dsi.c | 36 +-
> 1 file changed, 35 insertions(+)
> I would expect the driver to unregister the controller at the start of
> the remove function, suspend doesn't really make sense here
It's strange - But without spi_master_suspend i have randomly stucks when i
try unload this module - as was written before
i was test it (load/unload module in loo
On 4/23/21 4:02 PM, Jason Gunthorpe wrote:
> @@ -171,7 +171,7 @@ config SAMPLE_VFIO_MDEV_MDPY_FB
>
> config SAMPLE_VFIO_MDEV_MBOCHS
> tristate "Build VFIO mdpy example mediated device sample code --
> loadable modules only"
You can drop the ending of the prompt string.
> - depends o
> I would expect the driver to unregister the controller at the start of
> the remove function, suspend doesn't really make sense here
It's strange - But without spi_master_suspend i have randomly stucks
when i try unload this module - as was written before
i was test it (load/unload module in loo
When DRM_RCAR_DU=y and DRM_RCAR_LVDS=m, there are several build errors
as reported by 'kernel test robot'. These can be corrected by changing
source code occurrences of IS_ENABLED(...) to IS_REACHABLE(...).
In looking at this, the same problem (build errors) happens when
DRM_RCAR_DU=y and DRM_RCAR
Hi, Neil:
Neil Armstrong 於 2021年4月19日 週一 下午3:33寫道：
>
> Some SoCs like the MT8167 are not validated and supported for HDMI modes
> out of HDMI CEA modes, so add a configuration boolean to filter out
> non-CEA modes.
Reviewed-by: Chun-Kuang Hu
>
> Signed-off-by: Fabien Parent
> Signed-off-by: N
Hi, Neil:
Neil Armstrong 於 2021年4月19日 週一 下午3:33寫道：
>
> Some SoCs like the MT8167 have a hard limit on the maximal supported HDMI TMDS
> clock, so add a configuration value to filter out those modes.
Reviewed-by: Chun-Kuang Hu
>
> Signed-off-by: Fabien Parent
> Signed-off-by: Neil Armstrong
>
Hi, Neil:
Neil Armstrong 於 2021年4月19日 週一 下午3:33寫道：
>
> The MT8167 SoC have a hard limit on the maximal supported HDMI TMDS clock,
> and is not validated and supported for HDMI modes out of HDMI CEA modes,
> so add a configuration entry linked to the MT8167 compatible.
Reviewed-by: Chun-Kuang Hu
Hi Rajeev,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on lee-backlight/for-backlight-next]
[also build test ERROR on drm-intel/for-linux-next drm-tip/drm-tip
drm-exynos/exynos-drm-next tegra-drm/drm/tegra/for-next v5.12-rc8 next-20210423]
[cannot apply to drm/drm
mmu500 targets don't have a "cx_mem" region, set llc_mmio to NULL in that
case to avoid the IS_ERR() condition in a6xx_llc_activate().
Fixes: 3d247123b5a1 ("drm/msm/a6xx: Add support for using system cache on
MMU500 based targets")
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/adreno/a6
Hi Jason,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-tip/drm-tip drm-exynos/exynos-drm-next
next-20210423]
[cannot apply to tegra-drm/drm/tegra/for-next drm/drm-next v5.12-rc8]
[If your patch is applied to
Hi Jason,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-tip/drm-tip drm-exynos/exynos-drm-next
next-20210423]
[cannot apply to tegra-drm/drm/tegra/for-next drm/drm-next v5.12-rc8]
[If your patch is
today.
drivers/gpu/drm/rcar-du/Kconfig |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
--- linux-next-20210423.orig/drivers/gpu/drm/rcar-du/Kconfig
+++ linux-next-20210423/drivers/gpu/drm/rcar-du/Kconfig
@@ -14,10 +14,11 @@ config DRM_RCAR_DU
Choose this option if y
c: Icenowy Zheng
Cc: Vasily Khoruzhick
Cc: Torsten Duwe
Cc: Maxime Ripard
---
drivers/gpu/drm/bridge/analogix/Kconfig |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next-20210423.orig/drivers/gpu/drm/bridge/analogix/Kconfig
+++ linux-next-20210423/drivers/gpu/drm/bridge/anal
101 - 171 of 171 matches
Mail list logo
