27 Mar, 2019
1 commit
-
Change the 'bit_clk' and 'pix_clk' fields of struct sec_mipi_dsim
and the 'bit_clk' field of struct dsim_pll_pms from 'uint64_t' type
to 'uint32_t' type, since first, these two fields are in KHz unit,
and so 32 bit unsigned integer is enough to hold the data values,
and second, use 32 bit integer can simplify related clocks compute.Signed-off-by: Fancy Fang
(cherry picked from commit 3e62c748a531ca5eacbf6a616d3a979be5222b9c)
24 Mar, 2019
2 commits
-
Coverity reported potential arithmetic overflow of a 32-bit
multiply operation. Adding a cast to promote the mulitply opertion to use
64 bits.Signed-off-by: Oliver Brown
-
Coverity reported a potential divide by zero. Adding a check to prevent
a divide by zero.Signed-off-by: Oliver Brown
22 Mar, 2019
3 commits
-
Changing error message "Link rate is too high - forcing link to lower rate"
to a debug message "Lowering DP link rate from to ".Signed-off-by: Oliver Brown
-
Although the hardware spec doesn't mention the additional operation to
wait for FrameGen secondary syncup for non-PC cases(FrameGen non-sync mode)
when we enable a display, it turns out it helps avoid content stream(i.e.,
extdst0 or extdst1) shadow load done event missing issue when the first
page flip ocurrs after the display enablement. Black/blanked display
is observed when the issue happens, which means the video signal is likely
totally off. Adding this waiting operation also aligns to the cases
where PC is used.Signed-off-by: Liu Ying
(cherry picked from commit cfedc1269f35054c79d7fd2e2a914e97a4c1a47a) -
Another coming patch will wait for framegen secondary channel syncup
for non-sync mode cases. It appears that waiting for 50ms for video
modes like 1920x1080p@24 and 1920x1080p@30 is not enough. So, this
patch increases the timeout value to 100ms.Signed-off-by: Liu Ying
(cherry picked from commit 5357bce465db659d69a5026882a899f2077ee078)
15 Mar, 2019
3 commits
-
In order to prevent stall from happening during the system suspend operations,
the DPU KMS driver should use a freezable and unbound work queue for nonblock
commits to make sure all work items are drained in the freeze phase of the
suspend operations. So, let's hook up a commit function of our own onto
->atomic_commit to replace the original one drm_atomic_helper_commit() which
uses the system_unbound_wq(unfreezable). The new function is almost a copy
of drm_atomic_helper_commit() expect for the work queue replacement.Note that other drivers which use drm_atomic_helper_commit() may have
the same problem during system suspend. The right fix should be at the
DRM atomic core. However, being conservative for now, it is okay to fix the
issue for this driver only.Signed-off-by: Liu Ying
(cherry picked from commit a80ca5f87f047acea57ace9f9365794f99894285) -
In order to prevent stall from happening during the system suspend operations,
DPU KMS would use a freezable and unbound work queue for nonblock commits to
replace the original one in DRM atomic helper, that is, the unfreezable
system_unbound_wq. This patch introduces such a work queue and makes it ready
to be used by the DPU KMS driver.Signed-off-by: Liu Ying
(cherry picked from commit af5a701cf2c169fda987efa29ae882f032fdd084) -
DPU KMS would use a freezable and unbound work queue for nonblock commits
to prevent stall from happening during the system suspend operations in the
coming commits. In order to make sure DCSS KMS has the same nonblock commit
behaviour as before, the two drivers may have a work queue of their own
respectively. So, let's make the work queues be driver specific.Signed-off-by: Liu Ying
(cherry picked from commit 894623c295a647a36dd56b6a76b310970bd9a165)
14 Mar, 2019
2 commits
-
Change the log message to report "difference is" instead of "error is" to
avoid confusion. This message is just reports the actual pixel clock for
informational purposes. It is not an actual error.Signed-off-by: Oliver Brown
-
The resets need to be set in poweron to handle the warm reset case.
Signed-off-by: Oliver Brown
07 Mar, 2019
1 commit
-
Unstable/low quality input video signal is likely to cause the transmitter
to fail to wait for input video stable, and thus, no HDMI/DVI video output.
It turns out resetting LVDS part logics may help prevent the issue from
happening.Cc: Sandor Yu
Cc: Jason Liu
Signed-off-by: Liu Ying
(cherry picked from commit 5d09098ed14b1199fd1983be8824517c843d46b2)
05 Mar, 2019
7 commits
-
Change the default HDMI clocks to 800 MHz for DPLL, 200 MHz for
core, and 100MHz for bus.Signed-off-by: Oliver Brown
-
For QM and QXP, the PHY_REF clock was default ON on SCFW so it was not
handled by driver. Since now this clock is OFF in SCFW, it can be
correctly handled by kernel driver.
Now, the PHY_REF clock rate is set by the nwl-dsi bridge driver,
depending on the display mode used.
In this driver, the PIXEL and BYPASS clocks rates were set to the same
rate as the PHY_REF, but their rates need to be set to current display
mode clock.
Also, the order of the clocks matters, so make sure the BYPASS is
enabled before the PIXEL clock.Signed-off-by: Robert Chiras
Reviewed-by: Laurentiu Palcu -
DP driver will hang if driver initialized in un-linked status.
Add DP link status check to avoid system hang.Signed-off-by: Sandor Yu
(cherry picked from commit 3626e1b4fe9c042705e72de3ac40d7e31193370c) -
DPCD read function should return actual read size.
msg->size is the requested read size
so replaced it with read_resp.size.Signed-off-by: Sandor Yu
(cherry picked from commit 7ae79233dd2df543f92a30d5b466295666008408) -
AVI info frame will failed work when hdmi in 4kp30/24/25.
It is caused by the data is overwritten by hdmi vendor info frame.
Change the hdmi vendor info frame to different address.Signed-off-by: Sandor Yu
(cherry picked from commit 399072542cbdab2e1d758b34a152ba71be5b8d17) -
hdmi_vendor_info function only valid for HDMI1.4 4K video mode,
remove return value check.
Remove dumplicate hdmi_avi_info_set function call.Signed-off-by: Sandor Yu
(cherry picked from commit 3cc51bd99d5ab7514c36f217b54f91136aa30bef) -
Add max tmds clock check in deep color mode.
Make sure tmds clock is not excess hdmi sink capability.Signed-off-by: Sandor Yu
(cherry picked from commit 672768a727f35512919d6b9ccc124d26395c5a65)
21 Feb, 2019
2 commits
-
Need to check the content protection property first in
imx_hdp_imx_encoder_enable. The function may return if
drm_hdmi_infoframe_set_hdr_metadata returns an error. This was preventing
iMX8QM from enabling content protection.Signed-off-by: Oliver Brown
-
When do dpu blit and wait to finish, it will call usleep_range(10, 20)
to poll register state. Change to usleep_range(30, 50) to low down CPU loading.Change-Id: If84c436b31d228b8b7a2a41e89611d354270baba
Signed-off-by: Ivan.liu
19 Feb, 2019
1 commit
-
The following commit:
459a5fac54d - MLK-20263: drm/imx/dcss: fix channel-0 line shift
removed the 5 tap filter for vertical luma/chroma when YUV formats were
used.Problem is that when the 7 tap filter is used for vertical luma/chroma,
artifacts can be seen on screen when scaling.RGB can, however, function correctly with only 7 tap filter.
This patch partially reverts the above patch and also does some cosmetic
changes when calling the dcss_scaler_filter_design() using false/true
instead of 0/1 for use_5_taps argument.Signed-off-by: Laurentiu Palcu
12 Feb, 2019
18 commits
-
Adding support for HDCP 1.4 and 2.2 based upon upstream 4.19 kernel
use of "Content Protection" connector property.Signed-off-by: Oliver Brown
-
Added content_type property to drm_connector_state
in order to properly handle external HDMI TV content-type setting.v2:
* Moved helper function which attaches content type property
to the drm core, as was suggested.
Removed redundant connector state initialization.v3:
* Removed caps in drm_content_type_enum_list.
After some discussion it turned out that HDMI Spec 1.4
was wrongly assuming that IT Content(itc) bit doesn't affect
Content type states, however itc bit needs to be manupulated
as well. In order to not expose additional property for itc,
for sake of simplicity it was decided to bind those together
in same "content type" property.v4:
* Added it_content checking in intel_digital_connector_atomic_check.
Fixed documentation for new content type enum.v5:
* Moved patch revision's description to commit messages.v6:
* Minor naming fix for the content type enumeration string.v7:
* Fix parameter name for documentation and parameter alignment
in order not to get warning. Added Content Type description to
new HDMI connector properties section.v8:
* Thrown away unneeded numbers from HDMI content-type property
description. Switch to strings desription instead of plain
definitions.v9:
* Moved away hdmi specific content-type enum from
drm_connector_state. Content type property should probably not
be bound to any specific connector interface in
drm_connector_state.
Same probably should be done to hdmi_picture_aspect_ration enum
which is also contained in drm_connector_state. Added special
helper function to get derive hdmi specific relevant infoframe
fields.v10:
* Added usage description to HDMI properties kernel doc.v11:
* Created centralized function for filling HDMI AVI infoframe, based
on correspondent DRM property value.Acked-by: Hans Verkuil
Acked-by: Daniel Vetter
Signed-off-by: Stanislav Lisovskiy
Link: https://patchwork.freedesktop.org/patch/msgid/20180515135928.31092-2-stanislav.lisovskiy@intel.com
[vsyrjala: clean up checkpatch multiple blank lines warnings]
Signed-off-by: Ville Syrjälä -
This patch adds a new optional connector property to allow userspace to enable
protection over the content it is displaying. This will typically be implemented
by the driver using HDCP.The property is a tri-state with the following values:
- OFF: Self explanatory, no content protection
- DESIRED: Userspace requests that the driver enable protection
- ENABLED: Once the driver has authenticated the link, it sets this valueThe driver is responsible for downgrading ENABLED to DESIRED if the link becomes
unprotected. The driver should also maintain the desiredness of protection
across hotplug/dpms/suspend.If this looks familiar, I posted [1] this 3 years ago. We have been using this
in ChromeOS across exynos, mediatek, and rockchip over that time.Changes in v2:
- Pimp kerneldoc for content_protection_property (Daniel)
- Drop sysfs attribute
Changes in v3:
- None
Changes in v4:
- Changed kerneldoc to recommend userspace polling (Daniel)
- Changed kerneldoc to briefly describe how to attach the property (Daniel)
Changes in v5:
- checkpatch whitespace noise
- Change DRM_MODE_CONTENT_PROTECTION_OFF to DRM_MODE_CONTENT_PROTECTION_UNDESIRED
Changes in v6:
- NoneReviewed-by: Daniel Vetter
Signed-off-by: Sean Paul[1] https://lists.freedesktop.org/archives/dri-devel/2014-December/073336.html
Link: https://patchwork.freedesktop.org/patch/msgid/20180108195545.218615-4-seanpaul@chromium.org -
Implement the mode_valid in dcss-crtc to filter-out unsupported modes.
In dcss-crtc, just use the mode_valid and mode_fixup functions from
dcss-dtg.Signed-off-by: Robert Chiras
Reviewed-by: Laurentiu Palcu -
Implement mode_valid and mode_fixup functions for the dcss-crtc
driver so that DCSS can filter-out unsupported modes and save the
configuration for the supported ones.
Use mode_fixup to apply the saved configuration of a supported mode.
The mechanism to determine if a mode is supported or not is made in
dcss-dtg.Also, add 2 new clocks:
- pll: this is the video PLL that provides the pixel clock; it's rate
needs to be set such that the pixel clock can be achieved
- pll_src*: this is an oscillator that can be used as source clock for
the video pll; currently, there are possible maximum 3 pll sources,
defined as pll_src1, pll_src2 and pll_src3. The actual clocks that
can be used as pll source are: CLK_25M, CLK_27M and CLK_PHY_27MHZRemoved the pdiv_clk and pout_clk and replaced them with pix_clk,
since out of those two only one was used: pdiv_clk, representing the pixel
clock.In dcss-dtg, each mode is tested and if we can achieve it's pixel
clock we save this mode configuration into an internal list and apply this
configuration later on when mode_fixup is called.Signed-off-by: Robert Chiras
Reviewed-by: Laurentiu Palcu -
Implement mode_valid and check functions from
drm_simple_display_pipe_funcs such that we can filter-out modes that
cannot be driven by this controller.
Add 3 new clocks:
- video_pll: this is the PLL that provides the pixel clock; it's rate
needs to be set such that the pixel clock can be achieved
- osc_25: this is an oscillater that can be used as source clock for the
video_pll; default freq is 25MHz
- osc_27: same as above, but with freq of 27MHzDepending on the display mode used, the video_pll needs to have it's
clock source a 25MHz or 27MHz oscillator. Also, the video_pll rate needs
to be set to a rate that can be evenly divided to obtain the required
pixel clock. All these settings (clock source and video_pll rate) are
saved in mode_valid, then applied before mode needs to be set in the
check function.Signed-off-by: Robert Chiras
Reviewed-by: Laurentiu Palcu -
The PL111 needs to filter valid modes based on memory bandwidth.
I guess it is a pretty simple operation, so we can still claim
the DRM KMS helper pipeline is simple after adding this (optional)
vtable callback.Reviewed-by: Eric Anholt
Reviewed-by: Daniel Vetter
Signed-off-by: Linus Walleij
Link: https://patchwork.freedesktop.org/patch/msgid/20180220072859.3386-1-linus.walleij@linaro.org -
Some pixel clocks are not working with DSI. Until a better solution is
found, just filter-out the display modes by their clocks.Signed-off-by: Robert Chiras
Reviewed-by: Laurentiu Palcu -
Panels can request a higher clock than the one that can actually be
driven by the CRTC, in order to have more time for DSI commands.
If this is the case, make sure that the crtc_clock used is one that can
actually be driven for current chosen phy_ref rate.Signed-off-by: Robert Chiras
Reviewed-by: Laurentiu Palcu -
This patch removes the exported function nwl_dsi_get_bit_clock that was
used by nwl_dsi-imx driver in order to configure the phy driver speed
and move this configuration directly into the nwl-dsi driver.
This function is now used directly by nwl-dsi to verify which mode can or
cannot be supported by the DSI PHY.
Also, in nwl-dsi, add support for mode_valid and add each supported mode
into a list kept internally so that it can apply the needed
configuration (phyref rate, dsi lanes, bit-clock) later when the mode is
used.Signed-off-by: Robert Chiras
Reviewed-by: Laurentiu Palcu -
Remove the variables 'format', 'vc' and 'dsi_mode_flags' since we can
use the directly from the dsi_device object.
Also, fix the VACTIVE value (currently, -1 is subtracted from it but it
wasn't necessary).Signed-off-by: Robert Chiras
Reviewed-by: Laurentiu Palcu -
Move the imx_nwl_update_sync_polarity function content into
imx_nwl_dsi_mode_fixup function.Signed-off-by: Robert Chiras
Reviewed-by: Laurentiu Palcu -
According to the Analog Devices configuration script, there are some
steps that need to be made when configuring the ADV for a specific mode.
Some of those steps were missing from driver, so this patch takes care
of this.
Also, in mode_fixup, the driver is trying to reconfigure the DSI lanes
from 4 to 3, when pixel clock is lower than 80MHz, which is not
necessary. the lanes property represents the maximum available lanes on
that devices and should not differ from a mode to another.
The DSI host is the one who should predict how many lanes it could use
to drive a display mode, so remove this from ADV driver.Signed-off-by: Robert Chiras
Reviewed-by: Laurentiu Palcu -
To avoid potential missing braces when initializing tmp_m, this patch
caches h/vdisplay, h/vsync_start and h/vsync_end locally in function
tcon_cfg_videomode() instead of declaring and initializing the local
variable tmp_m.Code change only, no functional impact.
Reported-by: Anson Huang
Signed-off-by: Liu Ying -
Apparently, there are HDMI sinks out there that advertise Rec.2020
support in the Colorimetry Data Block but are not HDR capable devices.
In this case, there's no HDR Static metadata data block and EOTF is 0.This patch will allow setting up the DCSS output pipe non-linearity to
Rec.2020, irrespective of sink's supported EOTF in HDR static metadata.Signed-off-by: Laurentiu Palcu
-
Currently, the DSI controller is configured for AUTOINSERT_EOTP
depending on the CONTINUOUS or NON_CONTINUOUS clock mode, causing
problems to devices that actually need EOTP (End of Transmission
packet).
Fix this by taking into consideration the special flag created in
drm_mipi_dsi API.Signed-off-by: Robert Chiras
-
Add scdc tmds config function.
Enable HDMI2.0 when TMDS character rate > 340MHz.
Enable HDMI2.0 when LTE_340Mcsc_scramble bit set in EDID.This patch can fix 4Kp60 YUV420 failed to work in some TV.
That TV cann't support scramble mode
when TMDS character rate low than 340MHz.Signed-off-by: Sandor Yu
-
Reset struct drm_display_info when it is initialized.
Signed-off-by: Sandor Yu
