GEM_WARN_ON currently has dangerous semantics where it is completely
compiled out on !GEM_DEBUG builds. This can leave users who expect it to
be more like a WARN_ON, just without a warning in non-debug builds, in
complete ignorance.
Another gotcha with it is that it cannot be used as a statement. Which is
again different from a standard kernel WARN_ON.
This patch fixes both problems by making it behave as one would expect.
It can now be used both as an expression and as statement, and also the
condition evaluates properly in all builds - code under the conditional
will therefore not unexpectedly disappear.
To satisfy call sites which really want the code under the conditional to
completely disappear, we add GEM_DEBUG_WARN_ON and convert some of the
callers to it. This one can also be used as both expression and statement.
>From the above it follows GEM_DEBUG_WARN_ON should be used in situations
where we are certain the condition will be hit during development, but at
a place in code where error can be handled to the benefit of not crashing
the machine.
GEM_WARN_ON on the other hand should be used where condition may happen in
production and we just want to distinguish the level of debugging output
emitted between the production and debug build.
v2:
* Dropped BUG_ON hunk.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Tomasz Lis <tomasz.lis@intel.com>
Reviewed-by: Tomasz Lis <tomasz.lis@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181012063142.16080-1-tvrtko.ursulin@linux.intel.com
Unfortunately, it appears our fix in:
commit b5d29843d8 ("drm/atomic_helper: Allow DPMS On<->Off changes
for unregistered connectors")
Which attempted to work around the problems introduced by:
commit 4d80273976 ("drm/atomic_helper: Disallow new modesets on
unregistered connectors")
Is still not the right solution, as modesets can still be triggered
outside of drm_atomic_set_crtc_for_connector().
So in order to fix this, while still being careful that we don't break
modesets that a driver may perform before being registered with
userspace, we replace connector->registered with a tristate member,
connector->registration_state. This allows us to keep track of whether
or not a connector is still initializing and hasn't been exposed to
userspace, is currently registered and exposed to userspace, or has been
legitimately removed from the system after having once been present.
Using this info, we can prevent userspace from performing new modesets
on unregistered connectors while still allowing the driver to perform
modesets on unregistered connectors before the driver has finished being
registered.
Changes since v1:
- Fix WARN_ON() in drm_connector_cleanup() that CI caught with this
patchset in igt@drv_module_reload@basic-reload-inject and
igt@drv_module_reload@basic-reload by checking if the connector is
registered instead of unregistered, as calling drm_connector_cleanup()
on a connector that hasn't been registered with userspace yet should
stay valid.
- Remove unregistered_connector_check(), and just go back to what we
were doing before in commit 4d80273976 ("drm/atomic_helper: Disallow
new modesets on unregistered connectors") except replacing
READ_ONCE(connector->registered) with drm_connector_is_unregistered().
This gets rid of the behavior of allowing DPMS On<->Off, but that should
be fine as it's more consistent with the UAPI we had before - danvet
- s/drm_connector_unregistered/drm_connector_is_unregistered/ - danvet
- Update documentation, fix some typos.
Fixes: b5d29843d8 ("drm/atomic_helper: Allow DPMS On<->Off changes for unregistered connectors")
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: stable@vger.kernel.org
Cc: David Airlie <airlied@linux.ie>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20181016203946.9601-1-lyude@redhat.com
combo-phy register instances are at same offset from base for each
combo-phy port, i.e.
Port A base offset: 0x16200
Port B base offset: 0x6C000
All the other addresses for both ports can be derived by calculating
offset to these base addresses.
PORT_CL_DW_OFFSET 0x0
PORT_CL_DW<x> 0 + x * 4
PORT_COMP_OFFSET 0x100
PORT_COMP_DW<x> 0x100 + x * 4
PORT_PCS_AUX_OFFSET 0x300
PORT_PCS_GRP_OFFSET 0x600
PORT_PCS_LN<y>_OFFSET 0x800 + y * 0x100
PORT_TX_AUX_OFFSET 0x380
PORT_TX_GRP_OFFSET 0x680
PORT_TX_LN<y>_OFFSET 0x880 + y * 0x100
And inside each PORT_TX_[AUX|GRP|LN] we add `dw * 4`.
Based on original patch by Mahesh Kumar <mahesh1.kumar@intel.com>.
v2: make port, dw and ln arguments follow the order in
register's name
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181016023517.8576-1-lucas.demarchi@intel.com
has_drrs is a flag we can't read out. We set it when seamless DRRS is
enabled in pipe_config, so intel_dump_pipe_config() and
intel_pipe_config_compare() will continue to do the right thing when
has_drrs is set on the real state.
This removes one more dereference of crtc->config.
While at it, fixup the comment and also read out M2_N2 for CHV, since
we program it in the set_m_n function.
Changes since v1:
- Only read out M2/N2 on platforms that support DRRS.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181015094023.6211-1-maarten.lankhorst@linux.intel.com
LSPCON chips can generate YCBCR outputs, if asked nicely :).
In order to generate YCBCR 4:2:0 outputs, a source must:
- send YCBCR 4:4:4 signals to LSPCON
- program color space as 4:2:0 in AVI infoframes
Whereas for YCBCR 4:4:4 outputs, the source must:
- send YCBCR 4:4:4 signals to LSPCON
- program color space as 4:4:4 in AVI infoframes
So for both 4:2:0 as well as 4:4:4 outputs, we are driving the
pipe for YCBCR 4:4:4 output, but AVI infoframe's color space
information indicates LSPCON FW to start scaling down from YCBCR
4:4:4 and generate YCBCR 4:2:0 output. As the scaling is done by
LSPCON device, we need not to reserve a scaler for 4:2:0 outputs.
V2: rebase
V3: Addressed review comments from Ville
- add enum crtc_output_format instead of bool ycbcr420
- use crtc_output_format=4:4:4 for modeset of LSPCON 4:2:0 output
cases in this way we will have YCBCR 4:4:4 framework ready (except
the ABI part)
V4: Added r-b from Maarten (for v3)
Addressed review comments from Ville:
- Do not add a non-atomic state variable to determine lspcon output.
Instead add bool in CRTC state to indicate lspcon based scaling.
V5: Addressed review comments from Ville:
- Change the state bool name from external scaling to something more
relavent.
- Keep the info and adjusted_mode structures const.
- use crtc_state instead of pipe_config.
- Push all the config change into lspcon_ycbcr420_config function.
V6: Rebase, small changes to accommodate changes in patch 2.
V7: Fixed checkpatch warnings for alignment
V8: Rebase
PS: Ignored following warnings to match the current formatting:
drm/i915: Add YCBCR 4:2:0/4:4:4 support for LSPCON
-:53: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#53: FILE: drivers/gpu/drm/i915/i915_reg.h:8721:
+#define TRANS_MSA_SAMPLING_444 (2<<1)
^
-:54: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#54: FILE: drivers/gpu/drm/i915/i915_reg.h:8722:
+#define TRANS_MSA_CLRSP_YCBCR (2<<3)
V9: Rebase
V10: Rebase
V11: Rebase
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1539325394-20788-8-git-send-email-shashank.sharma@intel.com
In order to pass AVI infoframes to LSPCON devices, a source has to
write them in a vendor recommended method and location.
This patch series:
- adds generic LSPCON infoframe setup functions.
- registers these functions into existing AVI infoframe framework.
- triggers these functions from modeset sequence.
Next patches in the series will add vendor specific code.
V2: Added new parameter to align with new definition of
drm_hdmi_avi_infoframe_quant_range
V3: Added r-b from Maarten (for V2)
Added new parameter output_format in struct lspcon to accommodate
Ville's review comments on last patch of the series
V4: Addressed Ville's review comment
- Do not add output_format in LSPCON state, as its non-atomic. Add
this into CRTC state (added in a later patch).
V5: Rebase
V6: Rebase
V7: Rebase
V8: Rebase
V9: Rebase
V10: Rebase
V11: Accommodated rebasing changes in intel_git_port fptrs (set_infoframes and infoframe_enabled)
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Imre Deak <imre.deak@linux.intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1539325394-20788-5-git-send-email-shashank.sharma@intel.com
This patch adds support for YCBCR 4:4:4 CRTC output format.
To do this, this patch extends the existing YCBCR 4:2:0
framework by:
- Adding new parameter in for YCBCR 4:4:4 enum crtc_iutput_format.
- Adding case for YCBCR 4:4:4 in while setting AVI infoframes.
- Adding necessary checks in modeset sequence.
V3: Added this patch in the series
V4: Added r-b from Maarten (for v3)
Addressed review comment from Ville:
Do not use (config->output_format > CRTC_OUTPUT_RGB)
V5: Rebase
V6: Rebase and small change, to accommodate changes in patch 2
V7: Fixed checkpatch alignment warnings
V8: Rebase
V9: Rebase
V10: Rebase
V11: Addressed review comment from Ville
Missing output_format_str[INTEL_OUTPUT_FORMAT_YCBCR444]
Added Ville's R-B.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1539325394-20788-3-git-send-email-shashank.sharma@intel.com
Currently, we are using a bool in CRTC state (state->ycbcr420),
to indicate modeset, that the output format is YCBCR 4:2:0. Now in
order to support other YCBCR formats, we will need more such flags.
This patch adds a new enum parameter for YCBCR 4:2:0 outputs, in the
CRTC output formats and then plugs it during the modeset.
V3: Added this patch in the series, to address review comments from
second patchset.
V4: Added r-b from Maarten (on v3)
Addressed review comments from Ville:
- Change the enum name to intel_output_format.
- Start the enum value (INVALID) from 0 instaed of 1.
- Set the crtc's output_format to RGB in encoder's compute_config.
V5: Broke previous patch 1 into two parts,
- first patch to add CRTC output format in general
- second patch (this one) to add YCBCR 4:2:0 output
format specifically.
- Use ARRAY_SIZE(format_str) for output format validity check (Ville)
V6: Added a separate function to calculate crtc_state->output_format, and
calling it from various get_config function (Fix CI build warning)
V7: Fixed checkpatch warnings for alignment
V8: Rebase
V9: Rebase
V10: Rebase
V11: Addressed review comments from Ville:
- Change check for CRTC output format from > ARRAY_SIZE to >= ARRAY_SIZE.
- Check for values < INTEL_OUTPUT_FORMAT_RGB is unnecessary.
- No need to get CRTC YCBCR config, for pre-BDW functions.
Added Ville's r-b.
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1539325394-20788-2-git-send-email-shashank.sharma@intel.com
This patch adds an enum "intel_output_format" to represent
the output format of a particular CRTC. This enum will be
used to produce a RGB/YCBCR4:4:4/YCBCR4:2:0 output format
during the atomic modeset calculations.
V5:
- Created this separate patch to introduce and init output_format.
- Initialize parameters of output_format_str respectively (Jani N).
- Call it intel_output_format than crtc_output_format(Ville).
- Set output format in pipe_config for every encoder (Ville).
- Get rid of extra DRM_DEBUG_KMS during get_pipe_config (Ville)
V6: Rebase
V7: Fixed alignment warnings (checkpatch)
V8: Another check[atch warning for alignment
V9: Rebase
V10: Rebase on top of DSI restructure
V11: Addressed review comment from Ville
- Set CRTC format for pre-HSW get_pipe_config() function too.
Added Ville's R-B
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1539325394-20788-1-git-send-email-shashank.sharma@intel.com
Jani Nikula