Introduce struct drm_edid and start converting struct edid * to struct
drm_edid * in the EDID parsing. The rationale for drm_edid is explained
in depth in commit message for patch 3.
Initially, there's little functional benefit in the series, it's mostly
just prep work. It's also intended to be relatively straightforward to
review.
Later on, we'll add interfaces around drm_edid that let us utilize the
actual EDID buffer allocation size as metadata outside of the size
contained within the EDID …
[View More]blob. This is a requirement for safely
handling HF-EEODB without a huge flag day switch from struct edid
usage. See [1] for that work.
BR,
Jani.
[1] https://cgit.freedesktop.org/~jani/drm/log/?h=edid-hfeeodb-2022-05-06
Jani Nikula (25):
drm/edid: use else-if in CTA extension parsing
drm/edid: convert drm_for_each_detailed_block() to edid iter
drm/edid: add struct drm_edid container
drm/edid: start propagating drm_edid to lower levels
drm/edid: keep propagating drm_edid to display info
drm/edid: propagate drm_edid to drm_edid_to_eld()
drm/edid: convert drm_edid_connector_update() to drm_edid fully
drm/edid: convert struct detailed_mode_closure to drm_edid
drm/edid: convert drm_mode_detailed() to drm_edid
drm/edid: convert drm_dmt_modes_for_range() to drm_edid
drm/edid: convert drm_gtf_modes_for_range() to drm_edid
drm/edid: convert drm_cvt_modes_for_range() to drm_edid
drm/edid: convert drm_mode_std() and children to drm_edid
drm/edid: convert mode_in_range() and drm_monitor_supports_rb() to
drm_edid
drm/edid: convert get_monitor_name() to drm_edid
drm/edid: convert drm_for_each_detailed_block() to drm_edid
drm/edid: add drm_edid helper for drm_edid_to_sad()
drm/edid: add drm_edid helper for drm_edid_to_speaker_allocation()
drm/edid: add drm_edid helper for drm_detect_hdmi_monitor()
drm/edid: add drm_edid helper for drm_detect_monitor_audio()
drm/edid: convert cea_db_iter_edid_begin() to drm_edid
drm/edid: convert drm_edid_iter_begin() to drm_edid
drm/edid: add drm_edid helper for drm_update_tile_info()
drm/displayid: convert to drm_edid
drm/edid: convert version_greater() to drm_edid
drivers/gpu/drm/drm_displayid.c | 16 +-
drivers/gpu/drm/drm_edid.c | 542 +++++++++++++++++++-------------
include/drm/drm_displayid.h | 6 +-
include/drm/drm_edid.h | 6 +-
4 files changed, 337 insertions(+), 233 deletions(-)
--
2.30.2
[View Less]
dp_catalog_ctrl_reset() will software reset DP controller. But it will
not reset programmable registers to default value. DP driver still have
to clear mask bits to interrupt status registers to disable interrupts
after software reset of controller. This patch removes the enable flag
condition checking to always clear mask bits of interrupt status
registers to disable interrupts if enable flag is false.
This patch also will fix the potential problem happen at system suspend where
…
[View More]dp_ctrl_reset_irq_ctrl() was called to try to disable HPD related irqs but
the irq is still unmasked unexpectedly and can come in while system are
suspending. This leads to bus hangs if the irq is handled after we power down
the DP hardware because we run the irq handler and access a device register
assuming that no irq could ever come in if we powered down the device. We
don't know when the irq will be handled though, so it's possible the irq is
pending from before we disable the irq in the hardware.
Changes in v2:
-- add more details commit text
Fixes: ba0a422be723 ("drm/msm/dp: do not initialize phy until plugin interrupt received")
Signed-off-by: Kuogee Hsieh <quic_khsieh(a)quicinc.com>
---
drivers/gpu/drm/msm/dp/dp_ctrl.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index ebd38d7..09475a5 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -1391,8 +1391,13 @@ void dp_ctrl_reset_irq_ctrl(struct dp_ctrl *dp_ctrl, bool enable)
dp_catalog_ctrl_reset(ctrl->catalog);
- if (enable)
- dp_catalog_ctrl_enable_irq(ctrl->catalog, enable);
+ /*
+ * all dp controller programmable registers will not
+ * be reset to default value after DP_SW_RESET
+ * therefore interrupt mask bits have to be updated
+ * to enable/disable interrupts
+ */
+ dp_catalog_ctrl_enable_irq(ctrl->catalog, enable);
}
void dp_ctrl_phy_init(struct dp_ctrl *dp_ctrl)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[View Less]
dp_catalog_ctrl_reset() will software reset DP controller. But it will
not reset programmable registers to default value. DP driver still have
to clear mask bits to interrupt status registers to disable interrupts
after software reset of controller. This patch removes the enable flag
condition checking to always clear mask bits of interrupt status
registers to disable interrupts if enable flag is false.
Fixes: ba0a422be723 ("drm/msm/dp: do not initialize phy until plugin interrupt received")
…
[View More]Signed-off-by: Kuogee Hsieh <quic_khsieh(a)quicinc.com>
---
drivers/gpu/drm/msm/dp/dp_ctrl.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index 38026f2..cbf3399 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -1379,8 +1379,13 @@ void dp_ctrl_reset_irq_ctrl(struct dp_ctrl *dp_ctrl, bool enable)
dp_catalog_ctrl_reset(ctrl->catalog);
- if (enable)
- dp_catalog_ctrl_enable_irq(ctrl->catalog, enable);
+ /*
+ * all dp controller programmable registers will not
+ * be reset to default value after DP_SW_RESET
+ * therefore interrupt mask bits have to be updated
+ * to enable/disable interrupts
+ */
+ dp_catalog_ctrl_enable_irq(ctrl->catalog, enable);
}
void dp_ctrl_phy_init(struct dp_ctrl *dp_ctrl)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[View Less]
Add the new helpers drm_gem_fb_vmap() and drm_gem_fb_vunmap(), which
provide vmap/vunmap for all BOs of a framebuffer. Convert shadow-
plane helpers, gud and vkms.
Callers of GEM vmap and vunmap functions used to do the minimum work
or get some detail wrong. Therefore shadow-plane helpers were intro-
duced to implement the details for all callers. The vmapping code in
the shadow-plane helpers is also useful for gud and vkms. So it makes
sense to provide rsp helpers. Simply call drm_gem_fb_vmap(…
[View More]) to
retrieve mappings of all of a framebuffer's BOs.
Future work: besides the mapping's addresses, drm_gem_fb_vmap() should
also return the mappings with the framebuffer data offset added. These
are the addresses were the actual image data is located. A follow-up
set of patches will implement this feature.
v3:
* free instances of struct vkms_writeback_job on cleanup
or errors
v2:
* update commit message for first patch (Maxime)
* fix error handling after DRM_FORMAT_MAX_PLANES changes
(kernel test robot)
* fix includes (kernel test robot)
* use [static N] notations for array parameters
Thomas Zimmermann (5):
drm: Define DRM_FORMAT_MAX_PLANES
drm/gem: Provide drm_gem_fb_{vmap,vunmap}()
drm/gem: Clear mapping addresses for unused framebuffer planes
drm/gud: Map framebuffer BOs with drm_gem_fb_vmap()
drm/vkms: Map output framebuffer BOs with drm_gem_fb_vmap()
drivers/gpu/drm/drm_gem_atomic_helper.c | 37 +-------
drivers/gpu/drm/drm_gem_framebuffer_helper.c | 96 ++++++++++++++++++--
drivers/gpu/drm/gud/gud_pipe.c | 10 +-
drivers/gpu/drm/vkms/vkms_composer.c | 2 +-
drivers/gpu/drm/vkms/vkms_drv.h | 6 +-
drivers/gpu/drm/vkms/vkms_writeback.c | 28 +++---
include/drm/drm_fourcc.h | 13 ++-
include/drm/drm_framebuffer.h | 8 +-
include/drm/drm_gem_atomic_helper.h | 3 +-
include/drm/drm_gem_framebuffer_helper.h | 6 ++
10 files changed, 139 insertions(+), 70 deletions(-)
base-commit: 2bda1ca4d4acb4892556fec3a7ea1f02afcd40bb
prerequisite-patch-id: c2b2f08f0eccc9f5df0c0da49fa1d36267deb11d
prerequisite-patch-id: c67e5d886a47b7d0266d81100837557fda34cb24
--
2.32.0
[View Less]
See https://gitlab.freedesktop.org/drm/amd/-/issues/1447
This report was against DRM, but I'm mentioning it here because we've
been talking about some link speed init issues lately, and AFAICT the
gitlab reports don't show up anywhere in lore.
Robert Hancock reported:
> I'm using a RX 5500 XT card on an Asus PRIME H270-PRO motherboard,
> Intel i5-7500 CPU, with kernel 5.10.9 under Fedora 33. I noticed
> that in Linux, "lspci -vv" always showed the GPU PCIe link running
> at 2.5GT/…
[View More]s link speed and never seemed to change regardless of the
> application being run, while in Windows, GPU-Z shows the link
> running at the max supported 8GT/s speed when under graphical load.
>
> It seems like the driver thinks that 2.5GT/s is the max allowable
> speed, based on the pp_dpm_pcie file:
>
> > cd /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/0000:02:00.0/0000:03:00.0/
> > cat pp_dpm_pcie
> 0: 2.5GT/s, x8 81Mhz *
> 1: 2.5GT/s, x8 619Mhz *
>
> I'm assuming that something is going wrong with the PCIe link speed
> detection in the driver. Using the "amdgpu.pcie_gen_cap=0x70007"
> kernel command line option seems to result in the driver detecting
> the proper 8GT/s maximum speed.
>
> lspci -vv output from booting without overriding the speed is
> attached.
[View Less]
Currently, kernel/module annotates module dependencies when
request_symbol is used, but it doesn't cover more complex inter-driver
dependencies that are subsystem and/or driver-specific.
In the case of hdmi sound, depending on the CPU/GPU, sometimes the
snd_hda_driver can talk directly with the hardware, but sometimes, it
uses the i915 driver. When the snd_hda_driver uses i915, it should
first be unbind/rmmod, as otherwise trying to unbind/rmmod the i915
driver cause driver issues, as as …
[View More]reported by CI tools with different
GPU models:
https://intel-gfx-ci.01.org/tree/drm-tip/IGT_6415/fi-tgl-1115g4/igt@core_ho…https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11495/bat-adlm-1/igt@i915_m…
In the past, just a few CPUs were doing such bindings, but this issue now
applies to all "modern" Intel CPUs that have onboard graphics, as well as
to the newer discrete GPUs.
With the discrete GPU case, the HDA controller is physically separate and
requires i915 to power on the hardware for all hardware access. In this
case, the issue is hit basicly 100% of the time.
With on-board graphics, i915 driver is needed only when the display
codec is accessed. If i915 is unbind during runtime suspend, while
snd-hda-intel is still bound, nothing bad happens, but unbinding i915
on other situations may also cause issues.
So, add support at kernel/modules to allow snd-hda drivers to properly
annotate when a dependency on a DRM driver dependencies exists,
and add a call to such new function at the snd-hda driver when it
successfully binds into the DRM driver.
This would allow userspace tools to check and properly remove the
audio driver before trying to remove or unbind the GPU driver.
It should be noticed that this series conveys the hidden module
dependencies. Other changes are needed in order to allow
removing or unbinding the i915 driver while keeping the snd-hda-intel
driver loaded/bound. With that regards, there are some discussions on
how to improve this at alsa-devel a while back:
https://mailman.alsa-project.org/pipermail/alsa-devel/2021-September/190099…
So, future improvements on both in i915 and the audio drivers could be made.
E.g. with discrete GPUs, it's the only codec of the card, so it seems feasible
to detach the ALSA card if i915 is bound (using infra made for VGA
switcheroo), but, until these improvements are done and land in
upstream, audio drivers needs to be unbound if i915 driver goes unbind.
Yet, even if such fixes got merged, this series is still needed, as it makes
such dependencies more explicit and easier to debug.
PS.: This series was generated against next-20220428.
---
v5:
- while v4 works fine, it ends calling try_module_format() recursively, which
is not what it it was supposed to do. So, change the logic to avoid such
recursion, by adding a static __try_module_format() and renaming the
new version that takes two arguments as try_module_format_owner().
v4:
- fix a compilation warning reported by Intel's Kernel robot when
!CONFIG_MODULE_UNLOAD or !CONFIG_MODULE.
v3: minor fixes:
- fixed a checkpatch warning;
- use a single line for the new function prototype.
v2:
- the dependencies are now handled directly at try_module_get().
Mauro Carvalho Chehab (2):
module: update dependencies at try_module_get()
ALSA: hda - identify when audio is provided by a video driver
include/linux/module.h | 8 +++--
kernel/module/main.c | 65 ++++++++++++++++++++++++++++++--------
sound/hda/hdac_component.c | 2 +-
3 files changed, 57 insertions(+), 18 deletions(-)
--
2.35.1
[View Less]