The error handling is wrong and "ent" could be NULL we when dereference
it to get "ent->d_inode".
The thing is that normally debugfs_create_file() is not supposed to
require (or have) any error handling. That function does return error
pointers if debugfs is turned off but we know it's enable here. When
it's enabled, then it returns NULL on error.
So what I did was I stripped out all the error handling except around
the i_size_write(). I could have just used a NULL check instead of an
IS_ERR_OR_NULL() but I figured this was more clear because that way you
don't have to look at the surrounding code to see whether debugfs is
enabled or not.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
PPTABLE structure is stretched to add I2C controller
configuration. Hold on the PPTABLE_V20_SMU_VERSION bump
until the VBIOS is ready.
Signed-off-by: Evan Quan <evan.quan@amd.com>
Reviewed-by: Feifei Xu <Feifei.Xu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.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
[Why]
A loop inside of build_evenly_distributed_points function that traverse through
the array of points become an infinite loop when m_GammaUpdates does not
get assigned to any value.
[How]
In DMColor, clear m_gammaIsValid bit just before writting all Zeromem for
m_GammaUpdates, to prevent calling build_evenly_distributed_points
before m_GammaUpdates gets assigned to some value.
Signed-off-by: Su Sung Chung <Su.Chung@amd.com>
Reviewed-by: Aric Cyr <Aric.Cyr@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Commit b24413180f added
"SPDX-License-Identifier: GPL-2.0" to files which previously had no
license, change this to MIT for radeon matching the license text of the
other radeon files.
Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Commit b24413180f
'License cleanup: add SPDX GPL-2.0 license identifier to files with no license'
incorrectly added "SPDX-License-Identifier: GPL-2.0" to a file with MIT
license text. Change the SPDX identifier to match the license text.
Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Once we push the job, the scheduler could run it and free it. So, if
we want to reference their fences, we need to grab them before then.
I haven't seen this happen in many days of conformance test runtime,
but let's still close the race.
Signed-off-by: Eric Anholt <eric@anholt.net>
Fixes: 57692c94dc ("drm/v3d: Introduce a new DRM driver for Broadcom V3D V3.x+")
Link: https://patchwork.freedesktop.org/patch/254119/
Reviewed-by: Boris Brezillon <boris.brezillon@bootlin.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
