We have now seen panel (XMG Core 15 e21 laptop) advertizing support
for Intel proprietary eDP backlight control via DPCD registers, but
actually working only with legacy pwm control.
This patch adds panel EDID check for possible HDR static metadata and
Intel proprietary eDP backlight control is used only if that exists.
Missing HDR static metadata is ignored if user specifically asks for
Intel proprietary eDP backlight control via enable_dpcd_backlight
parameter.
v2 :
- Ignore missing HDR static metadata if Intel proprietary eDP
backlight control is forced via i915.enable_dpcd_backlight
- Printout info message if panel is missing HDR static metadata and
support for Intel proprietary eDP backlight control is detected
Fixes: 4a8d79901d5b ("drm/i915/dp: Enable Intel's HDR backlight interface (only SDR for now)")
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5284
Cc: Lyude Paul <lyude(a)redhat.com>
Cc: Mika Kahola <mika.kahola(a)intel.com>
Cc: Jani Nikula <jani.nikula(a)intel.com>
Cc: Filippo Falezza <filippo.falezza(a)outlook.it>
Cc: stable(a)vger.kernel.org
Signed-off-by: Jouni Högander <jouni.hogander(a)intel.com>
---
.../drm/i915/display/intel_dp_aux_backlight.c | 34 ++++++++++++++-----
1 file changed, 26 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index 97cf3cac0105..fb6cf30ee628 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -97,6 +97,14 @@
#define INTEL_EDP_BRIGHTNESS_OPTIMIZATION_1 0x359
+enum intel_dp_aux_backlight_modparam {
+ INTEL_DP_AUX_BACKLIGHT_AUTO = -1,
+ INTEL_DP_AUX_BACKLIGHT_OFF = 0,
+ INTEL_DP_AUX_BACKLIGHT_ON = 1,
+ INTEL_DP_AUX_BACKLIGHT_FORCE_VESA = 2,
+ INTEL_DP_AUX_BACKLIGHT_FORCE_INTEL = 3,
+};
+
/* Intel EDP backlight callbacks */
static bool
intel_dp_aux_supports_hdr_backlight(struct intel_connector *connector)
@@ -126,6 +134,24 @@ intel_dp_aux_supports_hdr_backlight(struct intel_connector *connector)
return false;
}
+ /*
+ * If we don't have HDR static metadata there is no way to
+ * runtime detect used range for nits based control. For now
+ * do not use Intel proprietary eDP backlight control if we
+ * don't have this data in panel EDID. In case we find panel
+ * which supports only nits based control, but doesn't provide
+ * HDR static metadata we need to start maintaining table of
+ * ranges for such panels.
+ */
+ if (i915->params.enable_dpcd_backlight != INTEL_DP_AUX_BACKLIGHT_FORCE_INTEL &&
+ !(connector->base.hdr_sink_metadata.hdmi_type1.metadata_type &
+ BIT(HDMI_STATIC_METADATA_TYPE1))) {
+ drm_info(&i915->drm,
+ "Panel is missing HDR static metadata. Possible support for Intel HDR backlight interface is not used. If your backlight controls don't work try booting with i915.enable_dpcd_backlight=%d. needs this, please file a _new_ bug report on drm/i915, see " FDO_BUG_URL " for details.\n",
+ INTEL_DP_AUX_BACKLIGHT_FORCE_INTEL);
+ return false;
+ }
+
panel->backlight.edp.intel.sdr_uses_aux =
tcon_cap[2] & INTEL_EDP_SDR_TCON_BRIGHTNESS_AUX_CAP;
@@ -413,14 +439,6 @@ static const struct intel_panel_bl_funcs intel_dp_vesa_bl_funcs = {
.get = intel_dp_aux_vesa_get_backlight,
};
-enum intel_dp_aux_backlight_modparam {
- INTEL_DP_AUX_BACKLIGHT_AUTO = -1,
- INTEL_DP_AUX_BACKLIGHT_OFF = 0,
- INTEL_DP_AUX_BACKLIGHT_ON = 1,
- INTEL_DP_AUX_BACKLIGHT_FORCE_VESA = 2,
- INTEL_DP_AUX_BACKLIGHT_FORCE_INTEL = 3,
-};
-
int intel_dp_aux_init_backlight_funcs(struct intel_connector *connector)
{
struct drm_device *dev = connector->base.dev;
--
2.25.1
From: Joerg Roedel <jroedel(a)suse.de>
Allow a runtime opt-out of kexec support for architecture code in case
the kernel is running in an environment where kexec is not properly
supported yet.
This will be used on x86 when the kernel is running as an SEV-ES
guest. SEV-ES guests need special handling for kexec to hand over all
CPUs to the new kernel. This requires special hypervisor support and
handling code in the guest which is not yet implemented.
Cc: stable(a)vger.kernel.org # v5.10+
Signed-off-by: Joerg Roedel <jroedel(a)suse.de>
---
include/linux/kexec.h | 1 +
kernel/kexec.c | 14 ++++++++++++++
kernel/kexec_file.c | 9 +++++++++
3 files changed, 24 insertions(+)
diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index 0c994ae37729..85c30dcd0bdc 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -201,6 +201,7 @@ int arch_kexec_kernel_verify_sig(struct kimage *image, void *buf,
unsigned long buf_len);
#endif
int arch_kexec_locate_mem_hole(struct kexec_buf *kbuf);
+bool arch_kexec_supported(void);
extern int kexec_add_buffer(struct kexec_buf *kbuf);
int kexec_locate_mem_hole(struct kexec_buf *kbuf);
diff --git a/kernel/kexec.c b/kernel/kexec.c
index c82c6c06f051..d03134160458 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -195,11 +195,25 @@ static int do_kexec_load(unsigned long entry, unsigned long nr_segments,
* that to happen you need to do that yourself.
*/
+bool __weak arch_kexec_supported(void)
+{
+ return true;
+}
+
static inline int kexec_load_check(unsigned long nr_segments,
unsigned long flags)
{
int result;
+ /*
+ * The architecture may support kexec in general, but the kernel could
+ * run in an environment where it is not (yet) possible to execute a new
+ * kernel. Allow the architecture code to opt-out of kexec support when
+ * it is running in such an environment.
+ */
+ if (!arch_kexec_supported())
+ return -ENOSYS;
+
/* We only trust the superuser with rebooting the system. */
if (!capable(CAP_SYS_BOOT) || kexec_load_disabled)
return -EPERM;
diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index 33400ff051a8..96d08a512e9c 100644
--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -358,6 +358,15 @@ SYSCALL_DEFINE5(kexec_file_load, int, kernel_fd, int, initrd_fd,
int ret = 0, i;
struct kimage **dest_image, *image;
+ /*
+ * The architecture may support kexec in general, but the kernel could
+ * run in an environment where it is not (yet) possible to execute a new
+ * kernel. Allow the architecture code to opt-out of kexec support when
+ * it is running in such an environment.
+ */
+ if (!arch_kexec_supported())
+ return -ENOSYS;
+
/* We only trust the superuser with rebooting the system. */
if (!capable(CAP_SYS_BOOT) || kexec_load_disabled)
return -EPERM;
--
2.31.1
Reviewed-by: Vabhav Sharma <vabhav.sharma(a)nxp.com>
> -----Original Message-----
> From: Fabio Estevam <festevam(a)gmail.com>
> Sent: Wednesday, April 20, 2022 5:36 PM
> To: herbert(a)gondor.apana.org.au
> Cc: Horia Geanta <horia.geanta(a)nxp.com>; Gaurav Jain
> <gaurav.jain(a)nxp.com>; Varun Sethi <V.Sethi(a)nxp.com>; linux-
> crypto(a)vger.kernel.org; Fabio Estevam <festevam(a)denx.de>;
> stable(a)vger.kernel.org
> Subject: [PATCH v5] crypto: caam - fix i.MX6SX entropy delay value
>
> From: Fabio Estevam <festevam(a)denx.de>
>
> Since commit 358ba762d9f1 ("crypto: caam - enable prediction resistance in
> HRWNG") the following CAAM errors can be seen on i.MX6SX:
>
> caam_jr 2101000.jr: 20003c5b: CCB: desc idx 60: RNG: Hardware error
> hwrng: no data available
>
> This error is due to an incorrect entropy delay for i.MX6SX.
>
> Fix it by increasing the minimum entropy delay for i.MX6SX as done in U-Boot:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch
> work.ozlabs.org%2Fproject%2Fuboot%2Fpatch%2F20220415111049.2565744-
> 1-
> gaurav.jain%40nxp.com%2F&data=05%7C01%7Cmeenakshi.aggarwal%4
> 0nxp.com%7Caf57d0186dde479aa9cf08da22c687d0%7C686ea1d3bc2b4c6fa92
> cd99c5c301635%7C0%7C0%7C637860533324307730%7CUnknown%7CTWFpb
> GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI
> 6Mn0%3D%7C3000%7C%7C%7C&sdata=UhqjgESpgMhOhJS%2BT4ghI6y
> NIvyybOI8yEv5%2FjKNcDE%3D&reserved=0
>
> As explained in the U-Boot patch:
>
> "RNG self tests are run to determine the correct entropy delay.
> Such tests are executed with different voltages and temperatures to identify
> the worst case value for the entropy delay. For i.MX6SX, it was determined
> that after adding a margin value of 1000 the minimum entropy delay should
> be at least 12000."
>
> Cc: <stable(a)vger.kernel.org>
> Fixes: 358ba762d9f1 ("crypto: caam - enable prediction resistance in HRWNG")
> Signed-off-by: Fabio Estevam <festevam(a)denx.de>
> Reviewed-by: Horia Geantă <horia.geanta(a)nxp.com>
> ---
> Changes since v4:
> - Change the function name to needs_entropy_delay_adjustment() -
> Vabhav
> - Improve the commit log by adding the explanation from the U-Boot patch -
> Vabhav
>
> drivers/crypto/caam/ctrl.c | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff --git a/drivers/crypto/caam/ctrl.c b/drivers/crypto/caam/ctrl.c index
> ca0361b2dbb0..f87aa2169e5f 100644
> --- a/drivers/crypto/caam/ctrl.c
> +++ b/drivers/crypto/caam/ctrl.c
> @@ -609,6 +609,13 @@ static bool check_version(struct fsl_mc_version
> *mc_version, u32 major, } #endif
>
> +static bool needs_entropy_delay_adjustment(void)
> +{
> + if (of_machine_is_compatible("fsl,imx6sx"))
> + return true;
> + return false;
> +}
> +
> /* Probe routine for CAAM top (controller) level */ static int
> caam_probe(struct platform_device *pdev) { @@ -855,6 +862,8 @@ static
> int caam_probe(struct platform_device *pdev)
> * Also, if a handle was instantiated, do not change
> * the TRNG parameters.
> */
> + if (needs_entropy_delay_adjustment())
> + ent_delay = 12000;
> if (!(ctrlpriv->rng4_sh_init || inst_handles)) {
> dev_info(dev,
> "Entropy delay = %u\n",
> @@ -871,6 +880,15 @@ static int caam_probe(struct platform_device *pdev)
> */
> ret = instantiate_rng(dev, inst_handles,
> gen_sk);
> + /*
> + * Entropy delay is determined via TRNG
> characterization.
> + * TRNG characterization is run across different
> voltages
> + * and temperatures.
> + * If worst case value for ent_dly is identified,
> + * the loop can be skipped for that platform.
> + */
> + if (needs_entropy_delay_adjustment())
> + break;
> if (ret == -EAGAIN)
> /*
> * if here, the loop will rerun,
> --
> 2.25.1
[Public]
Hi,
Can you please bring
commit 1210b17dd4ece454d68a9283f391e3b036aeb010 ("drm/amd/display: Only set PSR version when valid")
to 5.17.y+
This fixes a hang in certain GPU firmware on select panels.
You can also add to the commit log:
Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1969407
Thanks,