Some vop can't support 10bit mode, if connector needs 10bit output,
force to use 8bit rgb888 mode, because the hardware would do the
format convert.
Change-Id: I8cdfbab12dd0ad63d36f3c52a4c7786a2bdbe6a1
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
This adds support for Rockchip soc lvds found on rk3288
Change-Id: Iaab32c8c02fb17bf55db97a7952a346ce45c7d09
Signed-off-by: Mark Yao <yzq@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Fill atomic needed funcs with default atomic helper library.
Rockchip use dw_hdmi, and drm/rockchip will covert to atomic api,
we need dw_hdmi support atomic funcs.
Now another drm driver use dw_hdmi is imx, not yet atomic, so
check DRIVER_ATOMIC at runtime to spilt atomic and not atomic.
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
Change-Id: I519527efaf88b1e5c1b30db1fd23e59d45b88d50
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
(cherry pick from 2c5b2cccdb)
A single blank line is enough to separate Kconfig entries.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Change-Id: I325951cc36a4429a8313b61e3f3a44aa24e49958
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
(cherry pick from dae91e4d1c)
For consistency with other drivers, use dashes instead of underscores in
filenames.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Change-Id: Ie872685143935c365b40c3aaf2a104879478ea66
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
(cherry pick from 248a86fc30)
LSK 16.06 v4.4-android
* tag 'lsk-v4.4-16.06-android': (447 commits)
Linux 4.4.14
netfilter: x_tables: introduce and use xt_copy_counters_from_user
netfilter: x_tables: do compat validation via translate_table
netfilter: x_tables: xt_compat_match_from_user doesn't need a retval
netfilter: ip6_tables: simplify translate_compat_table args
netfilter: ip_tables: simplify translate_compat_table args
netfilter: arp_tables: simplify translate_compat_table args
netfilter: x_tables: don't reject valid target size on some architectures
netfilter: x_tables: validate all offsets and sizes in a rule
netfilter: x_tables: check for bogus target offset
netfilter: x_tables: check standard target size too
netfilter: x_tables: add compat version of xt_check_entry_offsets
netfilter: x_tables: assert minimum target size
netfilter: x_tables: kill check_entry helper
netfilter: x_tables: add and use xt_check_entry_offsets
netfilter: x_tables: validate targets of jumps
netfilter: x_tables: don't move to non-existent next rule
drm/core: Do not preserve framebuffer on rmfb, v4.
crypto: qat - fix adf_ctl_drv.c:undefined reference to adf_init_pf_wq
netfilter: x_tables: fix unconditional helper
...
Otherwise, clk_gpu won't be disabled actually in the runtime.
Change-Id: If1e32061cbffc1564a5cf95fbf01aa91c827550d
Signed-off-by: chenzhen <chenzhen@rock-chips.com>
Return -EINVAL would cause mipi dsi bad behavior, probe defer
to ensure mipi find the correct mode,
Change-Id: I0bb8e97dd6bd19f66052b4e985e95d8d82faf29b
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
HardWare limited, the bottom layer not support per-pixel alpha,
Change-Id: I174da1d3d3cfff8d0b6cd6dfab4873438895e56d
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
Hardware limited, we should keep all unused layer same
with the same zpos, otherwise, would get display abnormal.
Change-Id: I417a6a14731148a89f0372cc028e43a94b56e4d3
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
That is wrong use old crtc mode on atomic check.
Change-Id: Ie37bd842f8bafca04303d641269a84a6016457f4
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
All rockchip drm modules are module_init, so the probe sequence
is judged by compile sequence.
We want the rockchip drm core probe on the last one, so if components
call probe defer on bind, would use rockchip drm core to do probe defer.
Change-Id: Ibda12998545a93327bdf35bc1b8386034189ba6a
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
The AUO B101EW05 panel is a 10.1" 1280(RGB)x800 WXGA TFT-LCD panel,
connected using LVDS interfaces
Change-Id: Ic67fe5793a975b585cecfb8da02e81cd9fa6346f
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Chunghwa CLAA070WP03 is 7” color TFT-LCD module composed of LCD panel,
LVDS driver ICs, control circuit and backlight. This module supports
800x1280 mode.
Change-Id: I6a6339ad25664e2e47fc0e0de5c079db3494bd25
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
The LG LP079QX1-SP0V is an 7.9" QXGA TFT with LED Backlight unit and
32 pins eDP interface. This module supports 1536x2048 mode.
Change-Id: Ib42185ffce772160133a3edf3c3cf61bff4b85c5
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
(am from https://patchwork.kernel.org/patch/9201799/)
When the input color format is YUV, we need to do some external scale
for CBCR. Like,
* In YUV420 data format:
cbcr_xscale = dst_w / src_w * 2;
cbcr_yscale = dst_h / src_h * 2;
* In YUV422 data format:
cbcr_xscale = dst_w / src_w * 2;
cbcr_yscale = dst_h / src_h;
* In YUV444 data format
cbcr_xscale = dst_w / src_w;
cbcr_yscale = dst_h / src_h;
Change-Id: I73e0423d3662bd340b5d155996f13d31c22dcc29
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
(am from https://patchwork.kernel.org/patch/9157353/)
The WIN0 of RK3036 VOP could support YUV data format, but driver
forget to add the uv_vir register field for it.
Change-Id: Ie27216d0612d41fec02346ce65412207ed26d4a1
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
(am from https://patchwork.kernel.org/patch/9157349/)
This misc update would try to fix below comments from my eDP thread[0],
and lucky to say this version is stable, and i'm start to perpare the
pull request to David with this version. So i guess it's time to create
a misc FIXUP patch to address the comments.
[0]: https://patchwork.kernel.org/patch/9175613/
- Correct the misspell of "marcos" in commit message (Dominik, reviewed at Google Gerrit)
- Write a kerneldoc-style comment explaining the chips data fields (Tomasz, reviewed at Google Gerrit)
- Drop the '.lcdcsel_mask' number in chips data field (Tomasz, reviewed at Google Gerrit)
- Make this hack code more clear (Tomasz, reviewed at Google Gerrit)
reg = ~reg & REF_CLK_MASK; ---> reg ^= REF_CLK_MASK;
- Give the "rk3399-edp" a separate line for clarity in document (Tomasz, reviewed at Google Gerrit)
- Move 'output_type' setting before the return statement (Tomasz, reviewed at Google Gerrit)
- Avoid to change any internal driver state in .mode_valid interface. (Tomasz, reviewed at Google Gerrit)
- Hook the connector's color_formats in .get_modes directly. (Tomasz, reviewed at Google Gerrit)
Change-Id: Ic35f166ebac04e417ff3d135e7bf4573bbca2004
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
This patch adds a helper to parse the encoder endpoint connected to the
encoder's crtc and two helpers to return its id and port id.
This can be used to determine input mux setting from endpoint or port ids.
Change-Id: I48eb7c66edb951af40085e4e388afbd5d4b2c77b
Suggested-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
(cherry pick from commit 4cacf91fcb)
Power domain recommand order is that:
-> enable clock
-> pm_runtime_get_sync
-> pm_runtime_put
-> disable clock
Change-Id: Ia8d5c961afe8da6407a7cca1e48696a285460686
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
As gpu power on and off frequently, and the interval time is smaller
than the polling time of devfreq, add power-off-delay function to
ensure devfreq work fine.
Change-Id: Iba2405c9ead91a437233f1fedf2f3555703aa9e1
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
commit 310944d148 upstream.
The component master driver imx-drm-core matches component devices using
their of_node. Since commit 950b410dd1ab ("gpu: ipu-v3: Fix imx-ipuv3-crtc
module autoloading"), the imx-ipuv3-crtc dev->of_node is not set during
probing. Before that, of_node was set and caused an of: modalias to be
used instead of the platform: modalias, which broke module autoloading.
On the other hand, if dev->of_node is not set yet when the imx-ipuv3-crtc
probe function calls component_add, component matching in imx-drm-core
fails. While dev->of_node will be set once the next component tries to
bring up the component master, imx-drm-core component binding will never
succeed if one of the crtc devices is probed last.
Add of_node to the component platform data and match against the
pdata->of_node instead of dev->of_node in imx-drm-core to work around
this problem.
Fixes: 950b410dd1ab ("gpu: ipu-v3: Fix imx-ipuv3-crtc module autoloading")
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Tested-by: Fabio Estevam <fabio.estevam@nxp.com>
Tested-by: Lothar Waßmann <LW@KARO-electronics.de>
Tested-by: Heiko Schocher <hs@denx.de>
Tested-by: Chris Ruehl <chris.ruehl@gtsys.com.hk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Unfortunately since we don't have Dave's connector refcounting patch
here yet, it's very possible that drm_atomic_state_default_clear() could
get called by intel_display_resume() when
intel_dp_mst_destroy_connector() isn't completely finished destroying an
mst connector, but has already finished setting connector->funcs to
NULL. As such, we need to treat the connector like it's already been
destroyed and just skip it, otherwise we'll end up dereferencing a NULL
pointer.
This fix is only required for 4.6 and below. David Airlie's patchseries
for 4.7 to add connector reference counting provides a more proper fix
for this.
Changes since v1:
- Fix leftover whitespace
Upstream fix: 0552f7651b ("drm/i915/mst: use reference counted
connectors. (v3)")
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Lyude <cpaul@redhat.com>
commit 255f0e7c41 upstream.
During boot, MST hotplugs are generally expected (even if no physical
hotplugging occurs) and result in DRM's connector topology changing.
This means that using num_connector from the current mode configuration
can lead to the number of connectors changing under us. This can lead to
some nasty scenarios in fbcon:
- We allocate an array to the size of dev->mode_config.num_connectors.
- MST hotplug occurs, dev->mode_config.num_connectors gets incremented.
- We try to loop through each element in the array using the new value
of dev->mode_config.num_connectors, and end up going out of bounds
since dev->mode_config.num_connectors is now larger then the array we
allocated.
fb_helper->connector_count however, will always remain consistent while
we do a modeset in fb_helper.
Note: This is just polish for 4.7, Dave Airlie's drm_connector
refcounting fixed these bugs for real. But it's good enough duct-tape
for stable kernel backporting, since backporting the refcounting
changes is way too invasive.
Signed-off-by: Lyude <cpaul@redhat.com>
[danvet: Clarify why we need this. Also remove the now unused "dev"
local variable to appease gcc.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1463065021-18280-3-git-send-email-cpaul@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 14a3842a1d upstream.
During boot time, MST devices usually send a ton of hotplug events
irregardless of whether or not any physical hotplugs actually occurred.
Hotplugs mean connectors being created/destroyed, and the number of DRM
connectors changing under us. This isn't a problem if we use
fb_helper->connector_count since we only set it once in the code,
however if we use num_connector from struct drm_mode_config we risk it's
value changing under us. On top of that, there's even a chance that
dev->mode_config.num_connector != fb_helper->connector_count. If the
number of connectors happens to increase under us, we'll end up using
the wrong array size for memcpy and start writing beyond the actual
length of the array, occasionally resulting in kernel panics.
Note: This is just polish for 4.7, Dave Airlie's drm_connector
refcounting fixed these bugs for real. But it's good enough duct-tape
for stable kernel backporting, since backporting the refcounting
changes is way too invasive.
Signed-off-by: Lyude <cpaul@redhat.com>
[danvet: Clarify why we need this.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1463065021-18280-2-git-send-email-cpaul@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9d746ab681 upstream.
When porting the hdmi deep color detection code from
radeon-kms to amdgpu-kms apparently some kind of
copy and paste error happened, attaching an else
branch to the wrong if statement.
The result is that hdmi deep color mode is always
disabled, regardless of gpu and display capabilities and
user wishes, as the code mistakenly thinks that the display
doesn't provide the required max_tmds_clock limit and falls
back to 8 bpc.
This patch fixes deep color support, as tested on a
R9 380 Tonga Pro + suitable display, and should be
backported to all kernels with amdgpu-kms support.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7851496a32 upstream.
mode->hdisplay * (var->bits_per_pixel + 7) gets evaluated before
the division, potentially making the pitch larger than it should
be.
Since the original intention is to do a div-round-up, just use
the macro instead.
Signed-off-by: Sinclair Yeh <syeh@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e02e588431 upstream.
Instead of calling vmw_cmd_ok, call vmw_cmd_dx_cid_check to
validate the context id for query commands.
Signed-off-by: Charmaine Lee <charmainel@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7ccca1d5bf upstream.
Fix possible out of bounds read, by adding missing comma.
The code may read pass the end of the dsi_errors array
when the most significant bit (bit #31) in the intr_stat register
is set.
This bug has been detected using CppCheck (static analysis tool).
Signed-off-by: Itai Handler <itai_handler@hotmail.com>
Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Save output_type and output_mode into rockchip_crtc_state,
it's nice to make them into atomic.
Change-Id: I35b000a5dc599449dccf98c1fe58de24073b5246
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
Tested-by: John Keeping <john@metanate.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
(cherry picked from git.kernel.org next/linux-next.git master
commit 4e257d9eee)
We were accidentally returning PTR_ERR(NULL) which means success when we
wanted to return a negative error code.
Change-Id: Ia56827712eeaafef93ce433c0e05b95534784e30
Fixes: 412d4ae6b7 ('drm/rockchip: hdmi: add Innosilicon HDMI support')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Yakir Yang <ykk@rock-chips.com>
(cherry picked from git.kernel.org next/linux-next.git master
commit 2743becb33)
The Innosilicon HDMI is a low power HDMI 1.4 transmitter
IP, and it have been integrated on some rockchip CPUs
(like RK3036, RK312x).
Change-Id: If2c52391f3dc6ca6de4411496c137b5b2fd5cb92
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
(cherry picked from git.kernel.org next/linux-next.git master
commit 412d4ae6b7)
When CONFIG_NEED_SG_DMA_LENGTH is enabled,
sg_dma_len is defined as follow :
"#define sg_dma_len(sg) ((sg)->dma_length)"
But, dma_length is not used by the framework indeed.
Change-Id: I51d1adf9f2738b1036fdaf6172ae932c007fac76
Signed-off-by: chenzhen <chenzhen@rock-chips.com>
