rivers/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 you have an
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
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
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
---
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
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, 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寫道：
>
> 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:
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
> 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
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
> 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
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
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
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
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
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.
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:
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
> > >
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 +--
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
---
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
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 +-
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
---
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,
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 ++--
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
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
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 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
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 ---
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
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
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 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
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
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
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 +++
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
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
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.
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
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'.
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
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 +
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
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
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
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,
>>
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
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
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:
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 &&
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
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,
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 +
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
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 ++--
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
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
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
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:
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
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
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 |
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
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);
+
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
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
So that we can start using drm_dbg_*() throughout the DRM DP helpers.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_dual_mode_helper.c | 8 +---
drivers/gpu/drm/i915/display/intel_lspcon.c | 12 +++-
include/drm/drm_dp_dual_mode_helper.h | 4 ++--
3 files changed,
Since we're about to be using drm_dbg_*() throughout the DP helpers, we'll
need to be able to access the DRM device in the dual mode DP helpers as
well. Note however that since drm_dp_dual_mode_detect() can be called with
DDC adapters that aren't part of a drm_dp_aux struct, we need to pass down
Another function that we'll need to pass a drm_device (and not drm_dp_aux)
down to so that we can move over to 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 | 3 +--
So that we can start using drm_dbg_*() for
drm_dp_link_train_channel_eq_delay() and
drm_dp_lttpr_link_train_channel_eq_delay().
Signed-off-by: Lyude Paul
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 2 +-
drivers/gpu/drm/drm_dp_helper.c
Since we're about to convert everything in drm_dp_helper.c over to using
drm_dbg_*(), let's also make our logging more consistent in drm_dp_helper.c
while we're at it to ensure that we always print the name of the AUX
channel in question.
Signed-off-by: Lyude Paul
---
So that we can start using drm_dbg_*() in
drm_dp_link_train_clock_recovery_delay().
Signed-off-by: Lyude Paul
Reviewed-by: Laurent Pinchart
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 2 +-
drivers/gpu/drm/drm_dp_helper.c | 3 ++-
This is something that we've wanted for a while now: the ability to
actually look up the respective drm_device for a given drm_dp_aux struct.
This will also allow us to transition over to using the drm_dbg_*() helpers
for debug message printing, as we'll finally have a drm_device to reference
for
The docs we had for drm_dp_aux_init() and drm_dp_aux_register() were mostly
correct, except for the fact that they made the assumption that all AUX
devices were grandchildren of their respective DRM devices. This is the
case for most normal GPUs, but is almost never the case with SoCs and
display
Just adds some missing calls to
drm_dp_aux_register()/drm_dp_aux_unregister() for when we attach/detach the
bridge.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git
Since AUX adapters on nouveau have their respective DRM connectors as
parents, we need to make sure that we register then after their connectors.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 25 -
1 file changed, 20 insertions(+), 5
Since it's been asked quite a few times on some of the various DP
related patch series I've submitted to use the new DRM printk helpers,
and it technically wasn't really trivial to do this before due to the
lack of a consistent way to find a drm_device for an AUX channel, this
patch series aims to
Applied. Thanks!
Alex
On Thu, Apr 8, 2021 at 9:01 PM wrote:
>
> From: Yingjie Wang
>
> In dm_dp_mst_detect(), We should check whether or not @connector
> has been unregistered from userspace. If the connector is unregistered,
> we should return disconnected status.
>
> Fixes: 4562236b3bc0
Noticed while fixing the regression I introduced in Tegra that Tegra seems
to actually never release the device or module references it's grabbing for
the DP AUX channel. So, let's fix that by dropping them when appropriate.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/tegra/sor.c | 19
This patch series fixes a regression that was introduced by one of the
changes I made to when Tegra registers its AUX adapters, along with
fixing some reference leaks that I found along the way.
!!!NOTE!!!
There's one thing I'm not entirely sure about, which is the
While we're taking a reference of the DDC adapter for a DP AUX channel in
tegra_sor_probe() because we're going to be using that adapter with the
SOR, now that we've moved where AUX registration happens the actual device
structure for the DDC adapter isn't initialized yet. Which means that we
On Fri, 2021-04-23 at 14:39 +0200, Thierry Reding wrote:
>
> I'm curious: how is a DP AUX adapter reference count going to solve the
> issue of potentially registering devices too early (i.e. before the DRM
> is registered)?
>
> Is it because registering too early could cause a reference count
>
Add the required changes to support 7nm pll/phy in CPHY mode.
This adds a "qcom,dsi-phy-cphy-mode" property for the PHY node to enable
the CPHY mode.
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/dsi/dsi.xml.h | 2 +
drivers/gpu/drm/msm/dsi/dsi_host.c| 34 -
Document qcom,dsi-phy-cphy-mode option, which can be used to control
whether DSI will operate in D-PHY (default) or C-PHY mode.
Signed-off-by: Jonathan Marek
---
Documentation/devicetree/bindings/display/msm/dsi.txt | 1 +
1 file changed, 1 insertion(+)
diff --git
Add the required changes to support 7nm pll/phy in CPHY mode.
This adds a "qcom,dsi-phy-cphy-mode" property for the PHY node to enable
the CPHY mode.
v2:
- rebased on DSI PHY reworks
- reworked getting cphy_mode in dsi_host.c
- documentation change in separate patch
Jonathan Marek (2):
The pull request you sent on Fri, 23 Apr 2021 13:52:29 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-04-23
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/5bfc75d92efd494db37f5c4c173d3639d4772966
Thank you!
--
Deet-doot-dot, I am a bot.
Dear all,
On a custom board I have a simple DPI panel. Panel's backlight is drive with an
I2C led driver (PCA9632). led-backlight driver is sued to manage this as a
backlight.
When using brightness-levels and default-brightness-level the backlight stay
turned-off even if manually trying to
As of commit 5186421cbfe2 ("drm: Introduce epoch counter to
drm_connector") the drm_get_edid() function calls
drm_connector_update_edid_property() for us. There's no reason for us
to call it again.
Signed-off-by: Douglas Anderson
Reviewed-by: Bjorn Andersson
---
As Laurent pointed out [1] this
The of_find_i2c_adapter_by_node() could end up failing to find an
adapter in certain conditions. Specifically it's possible that
of_dev_or_parent_node_match() could end up finding an I2C client in
the list and cause bus_find_device() to stop early even though an I2C
adapter was present later in
It doesn't make sense to go out to the bus and read the EDID over and
over again. Let's cache it and throw away the cache when we turn power
off from the panel. Autosuspend means that even if there are several
calls to read the EDID before we officially turn the power on then we
should get good
We'd like to be able to expose the DDC-over-AUX channel bus to our
panel. This gets into a chicken-and-egg problem because:
- The panel wants to get its DDC at probe time.
- The ti-sn65dsi86 MIPI-to-eDP bridge code, which provides the DDC
bus, wants to get the panel at probe time.
By using a
I don't believe that it ever makes sense to read the EDID when a panel
is not powered and the powering on of the panel is the job of
prepare(). Let's make sure that this happens before we try to read the
EDID. We use the pm_runtime functions directly rather than directly
calling the normal
Adding this link allows the panel code to do things like read the
EDID.
Signed-off-by: Douglas Anderson
Reviewed-by: Bjorn Andersson
---
(no changes since v1)
arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git
This is really just a revert of commit 58074b08c04a ("drm/bridge:
ti-sn65dsi86: Read EDID blob over DDC"), resolving conflicts.
The old code failed to read the EDID properly in a very important
case: before the bridge's pre_enable() was called. The way things need
to work:
1. Read the EDID.
2.
Let's make the bridge use autosuspend with a 500ms delay. This is in
preparation for promoting DP AUX transfers to their own sub-driver so
that we're not constantly powering up and down the device as we
transfer all the chunks.
Signed-off-by: Douglas Anderson
Reviewed-by: Bjorn Andersson
---
Let's reorganize how we init and turn on the reference clock in the
code to allow us to turn it on early (even before pre_enable()) so
that we can read the EDID early. This is handy for eDP because:
- We always assume that a panel is there.
- Once we report that a panel is there we get asked to
1 - 100 of 175 matches
Mail list logo
