- 03 Apr, 2023 8 commits
-
-
Imre Deak authored
Arrange the TC PHY HW state setup/query functions into platform specific and generic groups. This prepares for upcoming patches adding generic TC PHY handlers and platform specific hooks for these, replacing the corresponding if ladders. No functional changes. v2: Fix non kernel-doc multiline comments. (Jani) Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Mika Kahola <mika.kahola@intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230323142035.1432621-2-imre.deak@intel.com
-
Swati Sharma authored
DSC_Output_Format_Sink_Support entry is added to i915_dsc_fec_support_show to depict if sink supports DSC output formats (RGB/YCbCr420/YCbCr444). Also, new debugfs entry is created to enforce output format. This is required because of our driver policy. For ex. if a mode is supported in both RGB and YCbCr420 output formats by the sink, our policy is to try RGB first and fall back to YCbCr420, if mode cannot be shown using RGB. So, to test other output formats like YCbCr420 or YCbCr444, we need a debugfs entry (force_dsc_output_format) to force this output format. v2: -Func name changed to intel_output_format_name() (Jani N) -Return forced o/p format from intel_dp_output_format() (Jani N) v3: -output_format_str[] to remain static (Jani N) Signed-off-by:Swati Sharma <swati2.sharma@intel.com> Reviewed-by:
Uma Shankar <uma.shankar@intel.com> Signed-off-by:
-
Suraj Kandpal authored
Add function to check if slice design requirements are being met as defined in Bspec: 49259 in the section Slice Design Requirement --v7 -remove full bspec link [Jani] -rename intel_dsc_check_slice_design_req to intel_dsc_slice_dimensions_valid [Jani] --v8 -fix condition to check if slice width and height are of two -fix minimum pixel in slice condition --v10 -condition should be < rather then >= [Uma] Cc: Uma Shankar <uma.shankar@intel.com> Signed-off-by:
Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by:
-
Suraj Kandpal authored
Now that we have laid the groundwork for YUV420 Enablement we fill up native_420 field in vdsc_cfg and add appropriate checks wherever required. ---v2 -adding native_422 field as 0 [Vandita] -filling in second_line_bpg_offset, second_line_offset_adj and nsl_bpg_offset in vds_cfg when native_420 is true ---v3 -adding display version check to solve igt issue --v7 -remove is_pipe_dsc check as its always true for D14 [Jani] --v10 -keep sink capability check [Jani] -move from !(x == y || w == z) to x !=y && w != z [Jani] --v11 -avoid native_420 computation if not gen14 [Uma] --v12 -fix state mismatch issue of compressed_bpp Cc: Uma Shankar <uma.shankar@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
-
Suraj Kandpal authored
Implementation of VDSC for YCbCr420. Add QP tables for 8,10,12 BPC from rc_tables.h in intel_qp_tables.c (Derived from C-Model, which is given along with DSC1.2a Spec from Vesa) intel_lookup_range_min/max_qp functons need to take into account the output format. Based on that appropriate qp table need to be chosen. Other rc_parameters need to be set where currently values for 444 format is hardcoded in calculate_rc_parameters( ). vdsc_cfg struct needs to be filled with output format information, where these are hardcoded for 444 format. Bspec: 49259 Signed-off-by:
Vandita Kulkarni <Vandita.kulkarni@intel.com> Reviewed-by:
-
Suraj Kandpal authored
Adding new DSC register which are introducted MTL onwards Signed-off-by:
-
Ankit Nautiyal authored
Go with DSC only if the given output_format is supported. v2: Use drm helper to get DSC format support for sink. v3: remove drm_dp_dsc_compute_bpp. Cc: Uma Shankar <uma.shankar@intel.com> Signed-off-by:
Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by:
-
Ankit Nautiyal authored
Add helper to check if the DP sink supports DSC with the given o/p format. v2: Add documentation for the helper. (Uma Shankar) v3: /** instead of /* (Uma Shankar) Signed-off-by:
-
- 31 Mar, 2023 9 commits
-
-
Ville Syrjälä authored
Define CUR_CHICKEN so we don't have to remember the offset. Looks like it's getting introduced in mtl. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230329190445.13456-3-ville.syrjala@linux.intel.comReviewed-by:
-
Ville Syrjälä authored
Add tgl+ comments to the PLANE_CHICKEN registers which I apparently forgot to add when defining the registers. Signed-off-by:
-
Ville Syrjälä authored
Cursor is not a universal plane and thus doesn't have the PLANE_CHICKEN register. Skip it. Fixes: c5de2484 ("drm/i915/dpt: Add a modparam to disable DPT via the chicken bit") Signed-off-by:
-
Jouni Högander authored
Implement Display WA #1136 for Pre-ICL. Bspec: 21664 v2: Handle disable psr in pre/post plane hooks Signed-off-by:
Jouni Högander <jouni.hogander@intel.com> Reviewed-by:
-
Jouni Högander authored
Ensure vblank >= psr2 vblank where Psr2 vblank = PSR2_CTL Block Count Number maximum line count. Bspec: 71580, 49274 v2: Use calculated block count number maximum line count Signed-off-by:
-
Jouni Högander authored
Add helpers to make it more clear how PSR2_CTL[Block Count Number] is configured. Signed-off-by:
-
Jouni Högander authored
PSR WM optimization should be disabled based on any wm level being disabled. Also same WA should be applied for ICL as well. Bspec: 71580 v5: - Set in pre plane hook and clear in post plane hook v4: - Handle mode change in psr enable/disable - Handle wm_level_disable changes separately in pre plane hook v3: - Split patch v2: - set/clear chicken bit in post_plane_update - apply for ICL as well Signed-off-by:
-
Jouni Högander authored
Wa_16013835468 is a separate from Wa_14015648006 and needs to be applied for display version 12. Fix this by removing all the references to Wa_14015648006 and apply Wa_16013835468 according to Bspec. Also move workaround into separate function as a preparation for Wa_14015648006 implementation. Bspec: 55378 v3: - apply for display version 12 only v2: - keep applying the wa in intel_psr_enable_source Signed-off-by:
-
Jouni Högander authored
pre/post hooks are doing things differently. Unify them. Signed-off-by:
-
- 30 Mar, 2023 7 commits
-
-
Daniele Ceraolo Spurio authored
The PTEs expect the offset from the base of the fake LMEM region (i.e. the base of stolen) and not from the base of the DSM. Quoting the specs: "Driver will set the Device Memory bit = 1 in the PTE when pointing to a page in DSM and program the PTE with offset from LMEM_BAR. Device Memory Offset from LMEM_BAR is same as offset from BGSM." DSM starts 8MBs from BGSM, so we set dsm_base = 8MB. Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Aravind Iddamsetty <aravind.iddamsetty@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Nirmoy Das <nirmoy.das@intel.com> Cc: Fei Yang <fei.yang@intel.com> Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Reviewed-by:
Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by:
Nirmoy Das <nirmoy.das@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230328012430.2524330-1-daniele.ceraolospurio@intel.com
-
Jani Nikula authored
Clean up i915_reg.h by splitting out DSB regs to display/intel_dsb_regs.h. Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
-
Jani Nikula authored
Clean up i915_reg.h by splitting out FDI regs to display/intel_fdi_regs.h. Signed-off-by:
-
Jani Nikula authored
Clean up i915_reg.h by splitting out DP AUX regs to display/intel_dp_aux_regs.h. Signed-off-by:
-
Jani Nikula authored
Clean up i915_reg.h by splitting out TV regs to display/intel_tv_regs.h. Signed-off-by:
-
Jani Nikula authored
Clean up i915_reg.h by splitting out PPS regs to display/intel_pps_regs.h. Signed-off-by:
-
Ville Syrjälä authored
Only the PWM output mode of the utility pin is incompatible with DC6/LCPLL disable. Check for that specifically. References: https://gitlab.freedesktop.org/drm/intel/-/issues/6609Signed-off-by:
-
- 29 Mar, 2023 1 commit
-
-
Stanislav Lisovskiy authored
For obvious reasons, we use compressed bpp instead of pipe bpp for DSC DP SST case. Lets be consistent and use compressed bpp instead of pipe bpp, also in DP MST DSC case. Signed-off-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Reviewed-by:
Vinod Govindapillai <vinod.govindapillai@intel.com> Fixes: d51f25eb ("drm/i915: Add DSC support to MST path") Link: https://patchwork.freedesktop.org/patch/msgid/20230327064217.24033-1-stanislav.lisovskiy@intel.com
-
- 28 Mar, 2023 4 commits
-
-
Jani Nikula authored
Essentially this is a revert of commit d9d54a53 ("drm/i915: Put future HW and their uAPIs under STAGING & BROKEN"). We currently have no users for this config option. The last one was removed in commit 8c26491f ("drm/i915: Kill the fake lmem support"). Drop it altogether; it's easy enough to resurrect if need arises. Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230327105330.312131-2-jani.nikula@intel.com
-
Rodrigo Vivi authored
Catch up with 6.3-rc cycle... Signed-off-by: -
Ville Syrjälä authored
Similar to FBC let's expose an debugfs file to control IPS false color. Enabling this provides an immediate visual feedback on whether IPS is working or not. Signed-off-by:
-
Ville Syrjälä authored
IPS is a per-pipe feature, so let's move the debugfs stuff under the crtc directory, and only register it when IPS is actually available. Signed-off-by:
-
- 27 Mar, 2023 3 commits
-
-
Daniel Vetter authored
Merge tag 'drm-rcar-next-20230325' of git://git.kernel.org/pub/scm/linux/kernel/git/pinchartl/linux into drm-next Miscellaneous fixes and improvements for rcar-du Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> From: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230325204922.GD19335@pendragon.ideasonboard.com
-
Vinod Govindapillai authored
Wrong register address is used to read the SAG block time. Fix the register address according to the bspec. Bspec: 64608 Signed-off-by:
-
Vinod Govindapillai authored
Wrong offsets are calculated to read QGV point registers. Fix it to read from the correct registers. Bspec: 64602 Reviewed-by:
-
- 25 Mar, 2023 8 commits
-
-
Dan Carpenter authored
The drmm_encoder_alloc() function returns error pointers. It never returns NULL. Fix the check accordingly. Fixes: 7a1adbd2 ("drm: rcar-du: Use drmm_encoder_alloc() to manage encoder") Signed-off-by:
Dan Carpenter <error27@gmail.com> Reviewed-by:
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by:
-
Laurent Pinchart authored
The DORCR register controls the routing of clocks and data between DU channels within a group. For groups that contain a single channel, there's no routing option to control, and some fields of the register are then reserved. On Gen2 those reserved fields are documented as required to be set to 0, while on Gen3 and newer the PG1T, DK1S and PG1D reserved fields must be set to 1. The DU driver initializes the DORCR register in rcar_du_group_setup(), where it ignores the PG1T, DK1S and PG1D, and then configures those fields to the correct value in rcar_du_group_set_routing(). This hasn't been shown to cause any issue, but prevents certifying that the driver complies with the documentation in safety-critical use cases. As there is no reasonable change that the documentation will be updated to clarify that those reserved fields can be written to 0 temporarily before starting the hardware, make sure that the registers are always set to valid values. Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
-
Laurent Pinchart authored
The DORCR fields were documented in the R-Car H1 datasheet with 1-based named, and then got renamed to 0-based in Gen2. The 0-based names are used for Gen3 and Gen4, making H1 an outlier. Rename the field macros to make them 0-based, in order to increase readability of the code when comparing it with the documentation. Signed-off-by:
-
Laurent Pinchart authored
When the input to a DU channel comes from a VSP, the DU doesn't perform any blending operation. Select XRGB8888 instead of ARGB8888 to ensure that the corresponding registers don't get written with invalid values. Signed-off-by:
-
Laurent Pinchart authored
The ESCR and OTAR registers are not present in all DU channels on Gen3 SoCs. ESCR only exists in channels that can be routed to an LVDS or DPAD, and OTAR in channels that can be routed to a DPAD. Skip writing those registers for other channels. This replaces the DU gen check, as Gen4 doesn't have LVDS or DPAD outputs. Signed-off-by:
-
Laurent Pinchart authored
On R-Car D3 and E3, the LVDS encoder provides the dot (pixel) clock to the DU, regardless of whether the LVDS output is used or not. When using the DPAD (RGB) output, the DU driver thus enables and disables the LVDS PLL manually, while when using the LVDS output, it lets the LVDS bridge driver handle the PLL configuration internally as part of the atomic enable and disable operations. This causes an issue when using the LVDS output. As bridges are disabled before CRTCs, the current implementation violates the enable/disable sequences documented in the hardware datasheet, which requires the dot clock to be enabled before the CRTC is started and disabled after it gets stopped. Fix the problem by enabling/disabling the LVDS PLL manually from the DU regardless of which output is used, and skipping the PLL handling in the LVDS bridge atomic enable and disable operations. This is however not enough. Disabling the LVDS encoder while leaving the PLL on still results in a vertical blanking wait timeout when disabling the DU. Investigation showed that the culprit is the LVEN bit. For an unclear reason, clearing the bit when disabling the LVDS encoder blocks vertical blanking interrupts. We thus have to delay disabling the whole LVDS encoder, not just disabling the PLL, until the DU is disabled. We could split the LVDS disable sequence by clearing the LVRES bit in the LVDS bridge atomic disable handler, and delaying the rest of the operations, in order to disable the LVDS output at bridge atomic disable time, before stopping the CRTC. This would make the code more complex, without a clear benefit, so keep the implementation simple(r). Signed-off-by:
Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
-
Laurent Pinchart authored
To prepare for a rework of the LVDS disable code, which will need to be called from rcar_lvds_pclk_disable(), move the LVDS enable code, currently stored in the __rcar_lvds_atomic_enable() function, to a separate code section separate from bridge operations. It will be then extended with the LVDS disable code. As part of this rework the __rcar_lvds_atomic_enable() function is renamed to rcar_lvds_enable() to more clearly indicate its purpose. No functional change intended. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by:
-
Laurent Pinchart authored
When disabling the companion bridge in rcar_lvds_atomic_disable(), there's no need to go through the bridge's operations to call .atomic_disable(). Call rcar_lvds_atomic_disable() on the companion directly. Signed-off-by:
-
