Now that we removed dependence on the power well IDs to determine the
control register and request/status flag offsets the only purpose of
power well IDs is to look up power wells directly bypassing the power
domains framework. However this direct lookup isn't needed for most of
the exisiting power wells and hopefully won't be needed for any new
power wells in the future. To make maintenance of the power well ID enum
easier, don't require a unique ID for each power well, only if it's
necessary. Remove the IDs becoming redundant this way and assign to all
the corresponding power wells a new DISP_PW_ID_NONE ID.
After the previous two patches the IDs don't need to have a fixed value,
so remove the explicit initializers and adjust the enum's code comment
accordingly.
v2:
- Keep required ID assignments for HSW_DISP_PW_GLOBAL and ICL_DISP_PW_2.
(Paulo)
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180806095843.13294-8-imre.deak@intel.com
Similarly to the previous patch use a separate request/status HW flag
index defined right after the corresponding control registers instead of
depending for this on the power well IDs. Since the set of
control/status registers varies among the different power wells (on a
single platform), also add a new i915_power_well_registers struct that
we populate and assign to each DDI power well as needed.
Also clarify a bit the code comment describing the function and layout
of the control registers.
This also fixes a problem on ICL, where we incorrectly read the KVMR
control register in hsw_power_well_requesters() even for DDI and AUX
power wells.
v2:
- Clarify platform range tags in code comments. (Paulo)
- Fix line over 80 chars checkpatch warning.
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180806095843.13294-7-imre.deak@intel.com
Atm, we determine the control/status flag offsets within the PUNIT
control/status registers based on the power well's ID. Since the power
well ID enum is global across all platforms, the associated macros to
get the flag offsets involves some magic. This makes checking the
register/bit definitions against the specification more difficult than
necessary. Also the values in the power well ID enum must stay fixed,
making code maintenance of the enum cumbersome.
To solve the above define the control/status flag indices right after
the corresponding registers and use these to derive the control/status
flag values by storing the indices in the i915_power_well_desc struct.
Initializing anonymous union fields require the preceding field in the
struct to be explicitly initialized - even when using named
initializers - and the initialization to be done right before the union
initialization, hence the reordering of the .id fields.
v2:
- Clarify commit log message about anonymous union initializers. (Paulo)
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180806095843.13294-6-imre.deak@intel.com
It makes sense to keep unchanging data const. Extract such fields from
the i915_power_well struct into a new i915_power_well_desc struct that
we initialize during compile time. For the rest of the dynamic
fields allocate an array of i915_power_well objects in i915 dev_priv,
and link to each of these objects their corresponding
i915_power_well_desc object.
v2:
- Fix checkpatch warnings about missing param name in fn declaration and
lines over 80 chars. (Paulo)
- Move check for unique IDs to __set_power_wells().
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
[Fixed checkpatch warn in __set_power_wells()]
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180806095843.13294-5-imre.deak@intel.com
From: Russell King <rmk@armlinux.org.uk>
As per the patches posted, discussed and tested by Peter Rosin, this
converts TDA998x to a bridge driver, while still allowing Armada and
TI LCDC to continue using it as they always have done. It also gets
rid of the private .fill_modes function, and tweaks the TMDS divider
calculation to be more correct to the available information.
[airlied: fixed two conflicts]
Signed-off-by: Dave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180802093421.GA29670@rmk-PC.armlinux.org.uk
Removing the drm_bridge_remove call should avoid a NULL dereference
during list processing in drm_bridge_remove if the error path is ever
taken.
The more natural approach would perhaps be to add a drm_bridge_add,
but there are several other bridges that never call drm_bridge_add.
Just removing the drm_bridge_remove is the easier fix.
Fixes: 84601dbdea ("drm: sti: rework init sequence")
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20180806061910.29914-2-peda@axentia.se
The serializer PLL divider is a power-of-two divider, so our calculation
which assumes that it's a numerical divider is incorrect. Replace it
with one that results in a power-of-two divider value instead.
Tested with all supported modes with a Samsung S24C750.
Tested-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
We can achieve the same effect via the get_modes() method, rather than
wrapping the fill_modes helper.
Tested-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Move the mode_valid() implementation to the bridge instead of the
connector, as we're checking the bridge's capabilities.
Tested-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Register the bridge outside of the component helper as we have
drivers that wish to use the tda998x without its encoder.
Tested-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Cleanup the code a little from the effects of the previous changes:
- Move tda998x_destroy() to be above tda998x_create()
- Use 'dev' directly in tda998x_create() where appropriate.
Tested-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Move the tda998x_priv allocation inside tda998x_create() and simplify
the tda998x_create()'s arguments. Pass the same to tda998x_destroy().
Tested-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Convert tda998x to a bridge driver with built-in encoder support for
compatibility with existing component drivers.
Tested-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
The dma_mapping_error() returns true on error but we want to return
-ENOMEM here.
Fixes: 79e542f5af ("drm/i915/kvmgt: Support setting dma map for huge pages")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
To consolidate all gvt private MMIO definition in one place,
this moves some not yet used in i915 to reg.h.
Reviewed-by: Hang Yuan <hang.yuan@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
drm_sched_job_finish() is a work item scheduled for each finished job on
a unbound system workqueue. This means the workers can execute out of order
with regard to the real hardware job completions.
If this happens queueing a timeout worker for the first job on the ring
mirror list is wrong, as this may be a job which has already finished
executing. Fix this by reorganizing the code to always queue the worker
for the next job on the list, if this job hasn't finished yet. This is
robust against a potential reordering of the finish workers.
Also move out the timeout worker cancelling, so that we don't need to
take the job list lock twice. As a small optimization list_del is used
to remove the job from the ring mirror list, as there is no need to
reinit the list head in the job we are about to free.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[why]
When programming tonga's connector's backend we didn't take
in account that HDMI's colour depth might be more than 8bpc
therefore we need to add a switch statement that would adjust
the pixel clock accordingly.
[how]
Add a switch statement updating clock by its appropriate
coefficient.
Signed-off-by: Mikita Lipski <mikita.lipski@amd.com>
Reviewed-by: Charlene Liu <Charlene.Liu@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
[Why]
We seem to have an issue where high enough display clock
will not get set properly during S3 resume if we only
call vbios once
[How]
Expand condition of display clock programming to happen
even when cached display clock matches requested display
clock
Signed-off-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com>
Reviewed-by: Tony Cheng <Tony.Cheng@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
The pointer for integrated_info can be NULL which causes the system to
do a null pointer deference and hang on boot.
[How]
Add a check to ensure that integrated_info is not null before enabling
DP ss.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Sun peng Li <Sunpeng.Li@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[why]
Prevent clock source sharing between HDMI and DP connectors.
DP shouldn't be sharing its ref clock with phy clock,
which caused an issue of older ASICS booting up with multiple
diplays plugged in.
[how]
Add an extra check that would prevent HDMI and DP sharing clk.
Signed-off-by: Mikita Lipski <mikita.lipski@amd.com>
Reviewed-by: Hersen Wu <hersenxs.wu@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
[why] dp hbr2 eye diagram pattern for raven asic is not stabled.
workaround is to use tp4 pattern. But this should not be
applied to asic before raven.
[how] add new bool varilable in asic caps. for raven asic,
use the workaround. for carrizo, vega, do not use workaround.
Signed-off-by: Hersen Wu <hersenxs.wu@amd.com>
Reviewed-by: Harry Wentland <Harry.Wentland@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
The calculated values for actual disp_clk_khz were ignored when
notifying pplib of the new display requirements. In order to honor DFS
bypass clocks from the hardware, the calculated value should be used.
[How]
The return value for set_dispclk is now assigned back into new_clocks
and correctly carried through into dccg->clks.phyclk_khz. When notifying
pplib of new display requirements dccg->clks.phyclk_khz is used
instead of dce.dispclk_khz. The value of dce.dispclk_khz was never
explicitly set to anything before.
A 15% higher display clock value than calculated is no longer requested
for dce110 since it now makes use of the calculated value.
Since dce112 makes use of dce110's set_bandwidth but not its
update_clocks it needs to have the value correctly carried through.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Harry Wentland <Harry.Wentland@amd.com>
Reviewed-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
Custom degamma lut functions are a feature we would
like to support on compatible hardware
[How]
In atomic check, convert from array of drm_color_lut to
dc_transfer_func. On hardware commit, allow for possibility
of custom degamma. Both are based on the equivalent
regamma pipeline.
Signed-off-by: David Francis <David.Francis@amd.com>
Reviewed-by: Krunoslav Kovac <Krunoslav.Kovac@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
In the dce112 function to destroy the resource pool, engines
(the aux engines) is destroyed twice. This has no ill effects
but is a tad redundant.
[How]
Remove the redundant call
Signed-off-by: David Francis <David.Francis@amd.com>
Reviewed-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
If there is no program explicitly setting the backlight
brightness (for example, during a minimal install of linux), the
hardware defaults to maximum brightness but the backlight_device
defaults to 0 value. Thus, settings displays the wrong brightness
value.
[How]
When creating the backlight device, set brightness to max
Signed-off-by: David Francis <David.Francis@amd.com>
Reviewed-by: Harry Wentland <Harry.Wentland@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
This hook that is supposed to read the actual backlight value
is used in a few places throughout the kernel to setup or force
update on backlight
[How]
Create a dc function that calls the existing abm function, and
call that function from amdgpu
Signed-off-by: David Francis <David.Francis@amd.com>
Reviewed-by: Harry Wentland <Harry.Wentland@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
400.1.1 is failing because we are not performing link training when
we get an HPD pulse for the same display. This is breaking DP
compliance
[How]
Always perform link training after HPD pulse if the detection
reason is not DETECT_REASON_HPDRX.
Signed-off-by: abdoulaye berthe <abdoulaye.berthe@amd.com>
Reviewed-by: Wenjing Liu <Wenjing.Liu@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
