To get input/output bus_format/enc_format dynamically, this patch
introduce following funstion in plat_data:
- get_input_bus_format
- get_output_bus_format
- get_enc_in_encoding
- get_enc_out_encoding
Change-Id: Ic703cba93fad8ceff773e1caca80759f95a9d547
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
This patch adds helper functions for YCBCR 420 handling.
These functions do:
- check if a given video mode is YCBCR 420 only mode.
- check if a given video mode is YCBCR 420 also mode.
V2: Added YCBCR functions as helpers in DRM layer, instead of
keeping it in I915 layer.
V3: Added handling for YCBCR-420 only modes too.
V4: EXPORT_SYMBOL(drm_find_hdmi_output_type)
V5: Addressed review comments from Danvet:
- %s/drm_find_hdmi_output_type/drm_display_info_hdmi_output_type
- %s/drm_can_support_ycbcr_output/drm_display_supports_ycbcr_output
- %s/drm_can_support_this_ycbcr_output/
drm_display_supports_this_ycbcr_output
- pass drm_display_info instead of drm_connector for consistency
- For drm_get_highest_quality_ycbcr_supported doc, move the variable
description above, and then the function description.
V6: Add only YCBCR420 helpers (Ville)
V7: Addressed review comments from Ville
- Remove cea_vic_valid() check.
- Fix indentation.
- Make input parameters to helpers, const.
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Jose Abreu <Jose.Abreu@synopsys.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1499960000-9232-9-git-send-email-shashank.sharma@intel.com
[vsyrjala: Fix sparse indentation warn]
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Change-Id: Ic2177fc9a7c9a3005fcdc88aa9183b429209d2e0
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
(cherry picked from commit 2570fe2586)
HDMI 2.0 spec adds support for YCBCR420 sub-sampled output.
CEA-861-F adds two new blocks in EDID's CEA extension blocks,
to provide information about sink's YCBCR420 output capabilities.
These blocks are:
- YCBCR420vdb(YCBCR 420 video data block):
This block contains VICs of video modes, which can be sopported only
in YCBCR420 output mode (Not in RGB/YCBCR444/422. Its like a normal
SVD block, valid for YCBCR420 modes only.
- YCBCR420cmdb(YCBCR 420 capability map data block):
This block gives information about video modes which can support
YCBCR420 output mode also (along with RGB,YCBCR444/422 etc) This
block contains a bitmap index of normal svd videomodes, which can
support YCBCR420 output too.
So if bit 0 from first vcb byte is set, first video mode in the svd
list can support YCBCR420 output too. Bit 1 means second video mode
from svd list can support YCBCR420 output too, and so on.
This patch adds two bitmaps in display's hdmi_info structure, one each
for VCB and VDB modes. If the source is HDMI 2.0 capable, this patch
adds:
- VDB modes (YCBCR 420 only modes) in connector's mode list, also makes
an entry in the vdb_bitmap per vic.
- VCB modes (YCBCR 420 also modes) only entry in the vcb_bitmap.
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Jose Abreu <joabreu@synopsys.com>
Cc: Emil Velikov <emil.l.velikov@gmail.com>
V2: Addressed
Review comments from Emil:
- Use 1ULL<<i instead of 1<<i to make sure the output is 64bit.
- Use the suggested method for updating dbmap.
- Add documentation for YCBCR420_vcb_map to fix kbuild warning.
Review comments from Ville:
- Do not expose the YCBCR420 flags in uabi layer, keep it internal.
- Save a map of YCBCR420 modes for future reference.
- Check db length before trying to parse extended tag.
- Add a warning if there are > 64 modes in capability map block.
- Use y420cmdb in function names and macros while dealing with vcb
to be aligned with spec.
- Move the display information parsing block ahead of mode parsing
blocks.
V3: Addressed design/review comments from Ville
- Do not add flags in video modes, else we have to expose them to user
- There should not be a UABI change, and kernel should detect the
choice of the output based on type of mode, and the bitmaps.
- Use standard bitops from kernel bitmap header, instead of calculating
bit positions manually.
V4: Addressed review comments from Ville:
- s/ycbcr_420_vdb/y420vdb
- s/ycbcr_420_vcb/y420cmdb
- Be less verbose on description of do_y420vdb_modes
- Move newmode variable in the loop scope.
- Use svd_to_vic() to get a VIC, instead of 0x7f
- Remove bitmap description for CMDB modes & VDB modes
- Dont add connector->ycbcr_420_allowed check for cmdb modes
- Remove 'len' variable, in is_y420cmdb function, which is used
only once
- Add length check in is_y420vdb function
- Remove unnecessary if (!db) check in function parse_y420cmdb_bitmap
- Do not add print about YCBCR 420 modes
- Fix indentation in few places
- Move ycbcr420_dc_modes in next patch, where its used
- Add a separate patch for movement of drm_add_display_info()
V5: Addressed review comments from Ville:
- Add the patch which cleans up the current EXTENDED_TAG usage
- Make y420_cmdb_map u64
- Do not block ycbcr420 modes while parsing the EDID, rather
add a separate helper function to prune ycbcr420-only modes from
connector's probed modes.
V6: Rebase
V7: Move this patch after the 420_only validation patch (Ville)
V8: Addressed review comments from Ville
- use cea_vic_valid check before adding cmdb/vdb modes
- add check for i < 64 while adding cmdb modes
- use 1ULL while checking bitmap
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1500028426-14883-1-git-send-email-shashank.sharma@intel.com
[vsyrjala: Fix checkpatch complaints and indentation]
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Change-Id: Id99fd280375445ff5ec93e19283fa7e3c2e715f7
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
(cherry picked from commit 832d4f2f41)
YCBCR420 modes are supported only on HDMI 2.0 capable sources.
This patch adds:
- A drm helper to validate YCBCR420-only mode on a particular
connector. This function will help pruning the YCBCR420-only
modes from the connector's modelist.
- A bool variable (ycbcr_420_allowed) in the drm connector structure.
While handling the EDID from HDMI 2.0 sinks, its important to know
if the source is capable of handling YCBCR420 output, so that no
YCBCR 420 modes will be listed for sources which can't handle it.
A driver should set this variable if it wants to see YCBCR420 modes
in the modedb.
V5: Introduced the patch in series.
V6: Squashed two patches (validate YCBCR420 and add YCBCR420
identifier)
V7: Addressed review comments from Vile:
- Move this patch before we add 420 modes from EDID.
- No need for drm_valid_cea_vic() check, function back to non-static.
- Update MODE_STATUS with NO_420 condition.
- Introduce y420_vdb_modes variable in this patch
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1499960000-9232-6-git-send-email-shashank.sharma@intel.com
[vsyrjala: Drop the now bogus EXPORT_SYMBOL(drm_valid_cea_vic)]
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Change-Id: Ia5ef115a54ee522d4c44544ee3abe4247a54f9c0
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
(cherry picked from commit d85231530b)
CEA-861-F introduces extended tag codes for EDID extension blocks,
which indicates the actual type of the data block. The code for
using exteded tag is 0x7, whereas in the existing code, the
corresponding macro is named as "VIDEO_CAPABILITY_BLOCK"
This patch renames the macro and usages from "VIDEO_CAPABILITY_BLOCK"
to "USE_EXTENDED_TAG"
V2: Add extended tag code check for video capabilitiy block (ville)
V3: Ville:
- Use suggested names for macros
- Check the block length first, before checking the extended tag
V4: Fix commit message (David)
V5: Introduced this patch into HDMI-YCBCR-output series
V6: Rebase
V7: Rebase
Change-Id: I7564a9fd9b5a44be0a10394b14ff3d21d9b1e0d5
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1499960000-9232-5-git-send-email-shashank.sharma@intel.com
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
(cherry picked from commit 87563fc030)
CEA-861-F adds ycbcr capability map block, for HDMI 2.0 sinks.
This block contains a map of indexes of CEA modes, which can
support YCBCR 420 output also. To avoid multiple parsing of same
CEA block, let's parse the sink information and get this map, before
parsing CEA modes.
This patch moves the call to drm_add_display_info function, before the
mode parsing block.
V4: Introduced new patch in the series
V5: Move this patch before 4:2:0 parsing patch (ville)
Added r-b from Ville
V6: Rebase
V7: Rebase
Change-Id: Icf1a68daa1d7b63ceb28fee152d8a605d613c13a
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1499960000-9232-4-git-send-email-shashank.sharma@intel.com
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
(cherry picked from commit 0f0f870830)
HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
For any other mode, the VIC filed in AVI infoframes should be 0.
HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
extended to (VIC 1-107).
This patch adds a bool input variable, which indicates if the connected
sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a
HDMI 2.0 VIC to a HDMI 1.4 sink.
This patch touches all drm drivers, who are callers of this function
drm_hdmi_avi_infoframe_from_display_mode but to make sure there is
no change in current behavior, is_hdmi2 is kept as false.
In case of I915 driver, this patch:
- checks if the connected display is HDMI 2.0.
- HDMI infoframes carry one of this two type of information:
- VIC for 4K modes for HDMI 1.4 sinks
- S3D information for S3D modes
As CEA-861-F has already defined VICs for 4K videomodes, this
patch doesn't allow sending HDMI infoframes for HDMI 2.0 sinks,
until the mode is 3D.
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Jose Abreu <jose.abreu@synopsys.com>
Cc: Andrzej Hajda <a.hajda@samsung.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
PS: This patch touches a few lines in few files, which were
already above 80 char, so checkpatch gives 80 char warning again.
- gpu/drm/omapdrm/omap_encoder.c
- gpu/drm/i915/intel_sdvo.c
V2: Rebase, Added r-b from Andrzej
V3: Addressed review comment from Ville:
- Do not send VICs in both AVI-IF and HDMI-IF
send only one of it.
V4: Rebase
V5: Added r-b from Neil.
Addressed review comments from Ville
- Do not block HDMI vendor IF, instead check for VIC while
handling AVI infoframes
V6: Rebase
V7: Rebase
Change-Id: I4a8e9ed2f292d3db6512e29e43661a21bb0b2a48
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1499960000-9232-2-git-send-email-shashank.sharma@intel.com
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
(cherry picked from commit 0c1f528cb1)
Under some circumstances the Frame Composer arithmetic unit can miss
an FC register write due to being busy processing the previous one.
The issue can be worked around by issuing a TMDS software reset and
then write one of the FC registers several times. After tested, the
number of iterations of RK3399/RK3328(v2.11a), RK3368(v2.01a),
RK3288(v2.00a) is one.
Change-Id: Iba209e25d56aff84a8cc90b4d8dcb87369c9ae52
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
When lcdc status changing and ddr frequency changing at the same time,
it may deadlock. Use list_for_each_entry to avoid this bug.
Change-Id: I461e705c19079ccb288e10bd4f616b0b4e5869b1
Signed-off-by: Tang Yun ping <typ@rock-chips.com>
When lcdc status changing and ddr frequency changing at the same time,
it may deadlock. Use list_for_each_entry to avoid this bug.
Change-Id: I8074dc60b71650ea1afc300282f90ae8ff1ae97b
Signed-off-by: Tang Yun ping <typ@rock-chips.com>
odd and even field interlace generating a frame image.
fix cif_isp10_img_src_v4l2_subdev_enum_strm_fmts defrect info get error.
fix cif_isp10_rk3399 cif_clk_pll info doesn't match with dts config.
Change-Id: I44159c0dd4e676334221b5d5682e29d3280aa9fd
Signed-off-by: zhoupeng <benjo.zhou@rock-chips.com>
If the regulator is shared between several devices then the lowest
request voltage that meets the system constraints will be used.
Change-Id: I68536a8e9cc5a78c21b55564a2ed540b9c184cb8
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
If there is only one opp whose frequency is equal to the initial value
in opp table list, the GPU voltage domain will keep the initial voltage,
it may be too large.
Change-Id: I3dd97fe252a15b789f218f44b8fbc7d4143f7085
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
update rtl8723bu wifi driver to version v4.4.2_18635.20161006_BTCOEX20151228-664a
Change-Id: I7053c211228a48fd45f9084da86d97a74e82ac79
Signed-off-by: Alex Zhao <zzc@rock-chips.com>
This adds support for the BOE Corporation MV238QUM-N20 23.8"
eDP(HBR2, 5.4Gbps) UHD TFT LCD panel, which can be supported
by the simple panel driver.
Change-Id: I5ec47bf4864899ab437a8aea4fa0d58d338b709a
Signed-off-by: Wyon Bi <bivvy.bi@rock-chips.com>
This adds support for the LG Corporation LM238WR2-SPA1 23.8"
eDP(HBR2, 5.4Gbps) UHD TFT LCD panel, which can be supported
by the simple panel driver.
Change-Id: I586684ba893be54fbf664a8fa4dad0fe5eb999a0
Signed-off-by: Wyon Bi <bivvy.bi@rock-chips.com>
In the case hcd autosuspend is enabled, the hcd will enter L2 state
if no device connected. But if the controller works in otg mode, the
gadget driver still works in L0 state if connected with host. This
may result in transfer fail when gadget enqueue new request but the
hcd driver has set the global state into L2. This patch prevent the
hcd enter L2 state if the controller work in device mode.
Change-Id: If31873bebf05c100cf74e49c7d2813160a808f1e
Signed-off-by: Meng Dongyang <daniel.meng@rock-chips.com>
Commit 4f519feed0 ("phy: rockchip-inno-usb2: delay suspending
phy if plug out device"), introduced the following issue:
BUG: sleeping function called from invalid context at kernel/workqueue.c:2717
in_atomic(): 1, irqs_disabled(): 128, pid: 4, name: kworker/0:0
INFO: lockdep is turned off.
irq event stamp: 19674
hardirqs last enabled at (19673): [<ffffff8008cd8818>] _raw_spin_unlock_irqrestore+0x40/0x70
hardirqs last disabled at (19674): [<ffffff8008cd8690>] _raw_spin_lock_irq+0x1c/0x60
softirqs last enabled at (19664): [<ffffff80088dd1c0>] dw_mci_request+0xe0/0xf0
softirqs last disabled at (19660): [<ffffff80088dd140>] dw_mci_request+0x60/0xf0
CPU: 0 PID: 4 Comm: kworker/0:0 Not tainted 4.4.83 #69
Hardware name: Rockchip RK3399 Evaluation Board v3 (Android) (DT)
Workqueue: fusb302_wq fusb302_work_func
Call trace:
[<ffffff8008089f78>] dump_backtrace+0x0/0x1cc
[<ffffff800808a158>] show_stack+0x14/0x1c
[<ffffff80083ca33c>] dump_stack+0xb8/0xf4
[<ffffff80080cec40>] ___might_sleep+0x1b8/0x1c8
[<ffffff80080cecc0>] __might_sleep+0x70/0x80
[<ffffff80080becbc>] flush_work+0x74/0x270
[<ffffff80080bf09c>] __cancel_work_timer+0x12c/0x1bc
[<ffffff80080bf154>] cancel_delayed_work_sync+0x10/0x18
[<ffffff80083f9de8>] rockchip_otg_event+0x18/0x3c
[<ffffff80080c6380>] notifier_call_chain+0x54/0x88
[<ffffff80080c63dc>] raw_notifier_call_chain+0x14/0x1c
[<ffffff80089a5354>] extcon_sync+0x74/0x1c4
[<ffffff80085ab980>] platform_fusb_notify+0x184/0x204
[<ffffff80085ac4ac>] set_state_unattached+0x5c/0x90
[<ffffff80085ac85c>] fusb302_work_func+0x288/0x1904
[<ffffff80080bdfa4>] process_one_work+0x354/0x6d0
[<ffffff80080bf4a4>] worker_thread+0x2f8/0x414
[<ffffff80080c4e58>] kthread+0xf0/0xf8
[<ffffff80080828d0>] ret_from_fork+0x10/0x40
Actually, we don't need to cancel the otg_sm_work in the
event EXTCON_USB_HOST notifier_call. So just remove the
cancel_delayed_work_sync() in the rockchip_otg_event().
With this patch, we may get USB BC1.2 detection error
if plug in USB peripheral/host cable alternately and
quickly. So we need to reinit chg_state and chg_type
if OTG host cable plug in.
Change-Id: I349d59de3188d39707c527acb858a7be20a999ac
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
RK3126-evb use andriod as system, so we put the common nodes for
andriod into rk312x-andriod.dtsi. This patch enable devices:
emmc/sdmmc/sdio/fiq-debugger/ramoops/cpufreq/ddrfreq.
Change-Id: I24993486711dd5b6050c03667545c9cb147e1b64
Signed-off-by: Liang Chen <cl@rock-chips.com>
This adds the necessary data for handling dfi on the rk3128.
Access the dfi via registers provided by GRF (general register
files) module.
Change-Id: Ife9e9987224088434e878102b7d1c3b132e761ad
Signed-off-by: Liang Chen <cl@rock-chips.com>
This adds the necessary data for handling efuse on the rk3128.
Change-Id: Ieda973675ff959b3157bb4afe6e1dcdfac65506c
Signed-off-by: Liang Chen <cl@rock-chips.com>
This adds the necessary data for handling dmcfreq on the rk3128.
Change-Id: I6aeae7103c1eaed0b4515d8d11863c4b190b6918
Signed-off-by: Liang Chen <cl@rock-chips.com>
rk3399 Type-C1 USB 2.0 PHY supports USB BC1.2. This patch
adds registers configuration for Type-C1 USB BC1.2.
With this patch, and set dr_mode of Type-C1 USB to "otg" or
"peripheral" in the DTS, then the Type-C1 USB can detect USB
battery charger.
Change-Id: I2f07ae675cc6066db46e428e6e27045b911a0773
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
After commit 23287661af ("ipv6: Inhibit IPv4-mapped src address on the wire.")
Android failed to pass DatagramSocketTest#test_getRemoteSocketAddress:
fail: java.net.ConnectException: Address family not supported by protocol
Android side has patch "Fix DatagramSocketTest#test_getRemoteSocketAddress".
Unfortunately, which may not merge to Android 7.1 branch, so we have to fixes
it on kernel side.
Change-Id: I7444c7636f02485abf6ddd4d7b9cad1f4e6d06e1
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
LSK 17.08 v4.4-android
* tag 'lsk-v4.4-17.08-android': (451 commits)
Linux 4.4.83
pinctrl: samsung: Remove bogus irq_[un]mask from resource management
pinctrl: sunxi: add a missing function of A10/A20 pinctrl driver
pnfs/blocklayout: require 64-bit sector_t
iio: adc: vf610_adc: Fix VALT selection value for REFSEL bits
usb:xhci:Add quirk for Certain failing HP keyboard on reset after resume
usb: quirks: Add no-lpm quirk for Moshi USB to Ethernet Adapter
usb: core: unlink urbs from the tail of the endpoint's urb_list
USB: Check for dropped connection before switching to full speed
uag: Add US_FL_IGNORE_RESIDUE for Initio Corporation INIC-3069
iio: light: tsl2563: use correct event code
iio: accel: bmc150: Always restore device to normal mode after suspend-resume
staging:iio:resolver:ad2s1210 fix negative IIO_ANGL_VEL read
USB: hcd: Mark secondary HCD as dead if the primary one died
usb: musb: fix tx fifo flush handling again
USB: serial: pl2303: add new ATEN device id
USB: serial: cp210x: add support for Qivicon USB ZigBee dongle
USB: serial: option: add D-Link DWM-222 device ID
nfs/flexfiles: fix leak of nfs4_ff_ds_version arrays
fuse: initialize the flock flag in fuse_file on allocation
...
If two vops are working, one of screens will flicker when change ddr
frequency.
Change-Id: I6e31ac1b7a2bfb0d57ec4507c2da1ee714e59c35
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
