15 Apr, 2019
1 commit
-
The 'reset' pin used by this panel driver is shared with the touchscreen
driver, which is causing issues during suspend/resume process. In order
to better handle this gpio pin, release its resource during suspend and
acquire it again in resume.Signed-off-by: Robert Chiras
10 Apr, 2019
1 commit
-
We should assign dedicated id for every tcon instance.
This makes us be able to figure out bewteen master and
slave tcon. Only side-by-side display mode is likely
impacted. Based on tests, no functional change is
observed before or after this patch is applied.Signed-off-by: Liu Ying
(cherry picked from commit e181d9e56b096bbdc919f65b223d1bde413df1bb)
29 Mar, 2019
1 commit
-
It is only used in this file, so staticize it.
Signed-off-by: Liu Ying
(cherry picked from commit e293f8671509ed54c83a51b40da53da3bdf216f5)
28 Mar, 2019
2 commits
-
It isn't used out side of the file for now.
Signed-off-by: Liu Ying
(cherry picked from commit 13a0d5c3b15e42834b872b0da904f874ff717500) -
Due to TKT320590, we are asked to turn TCON into operation mode later after
the first dumb frame is generated by DPU. This makes DPR/PRG be able to
evade the frame. However, it turns out we have to set the TCON into operation
mode first and then wait for Framegen frame counter moving, otherwise, the
display pipeline cannot be setup correctly sometimes(If pixel combiner is used,
one of the two display streams is likely broken). This is a mysterious issue.
So, we've already taken a workaround for the cases where pixel combiner is used.It appears that the similar issue is likely to happen for cases where pixel
combiner is unused. That is to say, if pixel combiner is unused and prefetch
engine is used, the first atomic flush after the enablement is likely to fail -
content shadow load irq doesn't come. The sequence which the patch takes is
the same to the one taken by the previous workaround. Based on tests, it is
valid for cases with or without pixel combiner.Signed-off-by: Liu Ying
(cherry picked from commit b6126aa9697c77896d2085997eec2a6995509f4b)
27 Mar, 2019
7 commits
-
Double check that the DTG IRQ STATUS register bit is set when handling
the vblank and CTXLD kick interrupts to make sure we avoid spurious
interrupts and kick the CTXLD in a bad moment.Signed-off-by: Laurentiu Palcu
Reviewed-by: Robert Chiras
(cherry picked from commit cc56e4e07f623d0b831e0f8347f2f3198697ee20) -
Using one completion variable is not feasible as we can hit corner cases like
enabling and then quickly disabling DCSS where we end up signaling that DTG was
correctly disabled when, in fact, a VBLANK interrupt was received.Signed-off-by: Laurentiu Palcu
Reviewed-by: Robert Chiras
(cherry picked from commit 8073e87dce34548bea758c34d3b3557819c75551) -
Currently, we set the colorimetry to BT.2020 even if the color-depth is
8 bit. This is not according to HDMI specification.This patch makes sure we follow the specs.
Signed-off-by: Laurentiu Palcu
CC: Sandor Yu
Reviewed-by: Sandor Yu
Reviewed-by: Robert Chiras
(cherry picked from commit cdacfaadd5dccfdca5dd68640d8f08506f6a9114) -
A fixed PLL PMS setting for attached panel is obviously not
enough for any other mipi panel which needs a different PLL
output clock frequency, and besides, for the CEA-861 standard
display modes, the 'pll_pms' table also can not cover all the
modes requirements. So a general way is created to solve this
problem which can provide an optimum solution to output a PLL
bit clock to match the request frequency in a maximum degree
and also satisfy the input clock and intermediate clocks limit
according to the PLL specification.Signed-off-by: Fancy Fang
(cherry picked from commit a73fdd5e48fe0df47685cfc197fe66edc1e28405) -
Add a new property 'pref-rate' support which can be used to
assign a different clock frequency for the DPHY PLL reference
clock in the dtb file. And if this property does not exist,
the default clock frequency for the reference clock will be
used. And according to the spec, the DPHY PLL reference clk
frequency should be in [6MHz, 300MHz] range.Signed-off-by: Fancy Fang
(cherry picked from commit a9fafe8108505f8a1580af898ff5fa9c26d03680) -
When there is no existing horizontal blanking word counts in
'dsim_hblank_par' tables, these data requires to be computed
according to the 'hfp', 'hbp' and 'hsa' timings which are in
pixel unit. So the pixel unit data requires to be converted
to word count unit data correctly to match the PLL output clk
frequency.Signed-off-by: Fancy Fang
(cherry picked from commit af9ab0d4362d9298978e2ac62033f65ea1cc09ed) -
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
7 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
