aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/drm_edid.c
AgeCommit message (Collapse)AuthorFilesLines
2018-02-21drm/edid: quirk Sony PlayStation VR headset as non-desktopPhilipp Zabel1-0/+3
This uses the EDID info from the Sony PlayStation VR headset, when connected directly, to mark it as non-desktop. Since the connection box (product id b403) defaults to HDMI pass-through to the TV, it is not marked as non-desktop. Signed-off-by: Philipp Zabel <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
2018-02-21drm/edid: quirk Windows Mixed Reality headsets as non-desktopPhilipp Zabel1-0/+10
This uses the EDID info from Lenovo Explorer (LEN-b800), Acer AH100 (ACR-7fce), and Samsung Odyssey (SEC-144a) to mark them as non-desktop. The other entries are for the HP Windows Mixed Reality Headset (HPN-3515), the Fujitsu Windows Mixed Reality headset (FUJ-1970), the Dell Visor (DEL-7fce), and the ASUS HC102 (AUS-c102). They are not tested with real hardware, but listed as HMD monitors alongside the tested headsets in the Microsoft HololensSensors driver package. Signed-off-by: Philipp Zabel <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
2018-02-21drm/edid: quirk Oculus Rift headsets as non-desktopPhilipp Zabel1-0/+5
This uses the EDID info from Oculus Rift DK1 (OVR-0001), DK2 (OVR-0003), and CV1 (OVR-0004) to mark them as non-desktop. Signed-off-by: Philipp Zabel <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
2018-02-19drm/edid: Add 6 bpc quirk for CPT panel in Asus UX303LAKai-Heng Feng1-0/+3
Similar to commit e10aec652f31 ("drm/edid: Add 6 bpc quirk for display AEO model 0."), the EDID reports "DFP 1.x compliant TMDS" but it support 6bpc instead of 8 bpc. Hence, use 6 bpc quirk for this panel. Fixes: 196f954e2509 ("drm/i915/dp: Revert "drm/i915/dp: fall back to 18 bpp when sink capability is unknown"") BugLink: https://bugs.launchpad.net/bugs/1749420 Signed-off-by: Kai-Heng Feng <[email protected]> Reviewed-by: Mario Kleiner <[email protected]> Cc: <[email protected]> # v4.8+ Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-02-19drm: NULL pointer dereference [null-pointer-deref] (CWE 476) problemJoe Moriarty1-0/+2
The Parfait (version 2.1.0) static code analysis tool found the following NULL pointer derefernce problem. - drivers/gpu/drm/drm_edid.c The call to drm_cvt_mode() in function drm_mode_std() for the HDTV hack resulted in the possibility of accessing a NULL pointer if drm_mode_std() returned NULL. A check for this added right after the call to drm_cvt_mode() in this particular area of code. Signed-off-by: Joe Moriarty <[email protected]> Reviewed-by: Steven Sistare <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-01-30drm/edid: use true and false for boolean valuesGustavo A. R. Silva1-2/+2
Assign true or false to boolean variables instead of an integer value. This issue was detected with the help of Coccinelle. Signed-off-by: Gustavo A. R. Silva <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20180130100528.GA7154@training
2017-12-15drm/edid: kerneldoc for is_hdmi2_sinkDaniel Vetter1-0/+5
Also some breadcrumbs for how exactly to find this. Probably should pass drm_connector * or at least drm_display_info * to that function instead. But drm_hdmi_avi_infoframe_quant_range probably also wants drm_connector_state (and the hdmi stuff moved into that), so this is a bit more work. v2: Fix typo (Alex). Cc: Ville Syrjälä <[email protected]> Fixes: 9271c0ca573e ("drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks") Acked-by: Alex Deucher <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-12-13drm: Update edid-derived drm_display_info fields at edid property set [v2]Keith Packard1-14/+38
There are a set of values in the drm_display_info structure for each connector which hold information derived from EDID. These are computed in drm_add_display_info. Before this patch, that was only called in drm_add_edid_modes. This meant that they were only set when EDID was present and never reset when EDID was not, as happened when the display was disconnected. One of these fields, non_desktop, is used from drm_mode_connector_update_edid_property, the function responsible for assigning the new edid value to the application-visible property. Various drivers call these two functions (drm_add_edid_modes and drm_mode_connector_update_edid_property) in different orders. This means that even when EDID is present, the drm_display_info fields may not have been computed at the time that drm_mode_connector_update_edid_property used the non_desktop value to set the non_desktop property. I've added a public function (drm_reset_display_info) that resets the drm_display_info field values to default values and then made the drm_add_display_info function public. These two functions are now called directly from drm_mode_connector_update_edid_property so that the drm_display_info fields are always computed from the current EDID information before being used in that function. This means that the drm_display_info values are often computed twice, once when the EDID property it set and a second time when EDID is used to compute modes for the device. The alternative would be to uniformly ensure that the values were computed once before being used, which would require that all drivers reliably invoke the two paths in the same order. The computation is inexpensive enough that it seems more maintainable in the long term to simply compute them in both paths. The API to drm_add_display_info has been changed so that it no longer takes the set of edid-based quirks as a parameter. Rather, it now computes those quirks itself and returns them for further use by drm_add_edid_modes. This patch also includes a number of 'const' additions caused by drm_mode_connector_update_edid_property taking a 'const struct edid *' parameter and wanting to pass that along to drm_add_display_info. v2: after review by Daniel Vetter <[email protected]> Removed EXPORT_SYMBOL_GPL for drm_reset_display_info and drm_add_display_info. Added FIXME in drm_mode_connector_update_edid_property about potentially merging that with drm_add_edid_modes to avoid the need for two driver calls. Signed-off-by: Keith Packard <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (danvet: cherry picked from commit 12a889bf4bca ("drm: rework delayed connector cleanup in connector_iter") from drm-misc-next since functional conflict with changes in -next and we need to make sure both have the right version and nothing gets lost.) Signed-off-by: Daniel Vetter <[email protected]>
2017-12-13drm: Update edid-derived drm_display_info fields at edid property set [v2]Keith Packard1-14/+39
There are a set of values in the drm_display_info structure for each connector which hold information derived from EDID. These are computed in drm_add_display_info. Before this patch, that was only called in drm_add_edid_modes. This meant that they were only set when EDID was present and never reset when EDID was not, as happened when the display was disconnected. One of these fields, non_desktop, is used from drm_mode_connector_update_edid_property, the function responsible for assigning the new edid value to the application-visible property. Various drivers call these two functions (drm_add_edid_modes and drm_mode_connector_update_edid_property) in different orders. This means that even when EDID is present, the drm_display_info fields may not have been computed at the time that drm_mode_connector_update_edid_property used the non_desktop value to set the non_desktop property. I've added a public function (drm_reset_display_info) that resets the drm_display_info field values to default values and then made the drm_add_display_info function public. These two functions are now called directly from drm_mode_connector_update_edid_property so that the drm_display_info fields are always computed from the current EDID information before being used in that function. This means that the drm_display_info values are often computed twice, once when the EDID property it set and a second time when EDID is used to compute modes for the device. The alternative would be to uniformly ensure that the values were computed once before being used, which would require that all drivers reliably invoke the two paths in the same order. The computation is inexpensive enough that it seems more maintainable in the long term to simply compute them in both paths. The API to drm_add_display_info has been changed so that it no longer takes the set of edid-based quirks as a parameter. Rather, it now computes those quirks itself and returns them for further use by drm_add_edid_modes. This patch also includes a number of 'const' additions caused by drm_mode_connector_update_edid_property taking a 'const struct edid *' parameter and wanting to pass that along to drm_add_display_info. v2: after review by Daniel Vetter <[email protected]> Removed EXPORT_SYMBOL_GPL for drm_reset_display_info and drm_add_display_info. Added FIXME in drm_mode_connector_update_edid_property about potentially merging that with drm_add_edid_modes to avoid the need for two driver calls. Signed-off-by: Keith Packard <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-12-04Merge tag 'drm-misc-next-2017-11-30' of ↵Dave Airlie1-34/+70
git://anongit.freedesktop.org/drm/drm-misc into drm-next Cross-subsystem Changes: - device tree doc for the Mitsubishi AA070MC01 and Tianma TM070RVHG71 panels (Lukasz Majewski) and for a 2nd endpoint on stm32 (Philippe Cornu) Core Changes: The most important changes are: - Add drm_driver .last_close and .output_poll_changed helpers to reduce fbdev emulation footprint in drivers (Noralf) - Fix plane clipping in core and for vmwgfx (Ville) Then we have a bunch of of improvement for print and debug such as the addition of a framebuffer debugfs file. ELD connector, HDMI and improvements. And a bunch of misc improvements, clean ups and style changes and doc updates [airlied: drop eld bits from amdgpu_dm] Driver Changes: - sii8620: filter unsupported modes and add DVI mode support (Maciej Purski) - rockchip: analogix_dp: Remove unnecessary init code (Jeffy Chen) - virtio, cirrus: add fb create_handle support to enable screenshots(Lepton Wu) - virtio: replace reference/unreference with get/put (Aastha Gupta) - vc4, gma500: Convert timers to use timer_setup() (Kees Cook) - vc4: Reject HDMI modes with too high of clocks (Eric) - vc4: Add support for more pixel formats (Dave Stevenson) - stm: dsi: Rename driver name to "stm32-display-dsi" (Philippe Cornu) - stm: ltdc: add a 2nd endpoint (Philippe Cornu) - via: use monotonic time for VIA_WAIT_IRQ (Arnd Bergmann) * tag 'drm-misc-next-2017-11-30' of git://anongit.freedesktop.org/drm/drm-misc: (96 commits) drm/bridge: tc358767: add copyright lines MAINTAINERS: change maintainer for Rockchip drm drivers drm/vblank: Fix vblank timestamp debugs drm/via: use monotonic time for VIA_WAIT_IRQ dma-buf: Fix ifnullfree.cocci warnings drm/printer: Add drm_vprintf() drm/edid: Allow HDMI infoframe without VIC or S3D video/hdmi: Allow "empty" HDMI infoframes dma-buf/fence: Fix lock inversion within dma-fence-array drm/sti: Handle return value of platform_get_irq_byname drm/vc4: Add support for NV21 and NV61. drm/vc4: Use .pixel_order instead of custom .flip_cbcr drm/vc4: Add support for DRM_FORMAT_RGB888 and DRM_FORMAT_BGR888 drm: Move drm_plane_helper_check_state() into drm_atomic_helper.c drm: Check crtc_state->enable rather than crtc->enabled in drm_plane_helper_check_state() drm/vmwgfx: Try to fix plane clipping drm/vmwgfx: Use drm_plane_helper_check_state() drm/vmwgfx: Remove bogus crtc coords vs fb size check gpu: gma500: remove unneeded DRIVER_LICENSE #define drm: don't link DP aux i2c adapter to the hardware device node ...
2017-11-24Merge tag 'drm-misc-fixes-2017-11-20' of ↵Dave Airlie1-2/+10
git://anongit.freedesktop.org/drm/drm-misc into drm-next 4.15 merge window fixes 1 * tag 'drm-misc-fixes-2017-11-20' of git://anongit.freedesktop.org/drm/drm-misc: drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks drm/vc4: Account for interrupts in flight
2017-11-23drm/edid: quirk HTC vive headset as non-desktop. [v2]Dave Airlie1-0/+3
This uses the EDID info from my HTC Vive to mark it as non-desktop. v2: Change description from non-standard to non-desktop Reviewed-by: Keith Packard <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
2017-11-23drm: add connector info/property for non-desktop displays [v2]Dave Airlie1-2/+6
This adds the infrastructure needed to quirk displays using edid and to mark them a non-desktop. A non-desktop display is one which shouldn't normally be included as a part of a desktop environment. This is meant to cover head mounted devices like HTC Vive. v2: Change description from non-standard to non-desktop, add docs Reviewed-by: Keith Packard <[email protected]> Signed-off-by: Dave Airlie <[email protected]> fixup docs
2017-11-22drm/edid: Allow HDMI infoframe without VIC or S3DVille Syrjälä1-6/+28
Appedix F of HDMI 2.0 says that some HDMI sink may fail to switch from 3D to 2D mode in a timely fashion if the source simply stops sending the HDMI infoframe. The suggested workaround is to keep sending the infoframe even when strictly not necessary (ie. no VIC and no S3D). HDMI 1.4 does allow for this behaviour, stating that sending the infoframe is optional in this case. The infoframe was first specified in HDMI 1.4, so in theory sinks predating that may not appreciate us sending an uknown infoframe their way. To avoid regressions let's try to determine if the sink supports the infoframe or not. Unfortunately there's no direct way to do that, so instead we'll just check if we managed to parse any HDMI 1.4 4k or stereo modes from the EDID, and if so we assume the sink will accept the infoframe. Also if the EDID contains the HDMI 2.0 HDMI Forum VSDB we can assume the sink is prepared to receive the infoframe. v2: Fix getting has_hdmi_infoframe from display_info Always fail constructing the infoframe if the display possibly can't handle it Cc: Shashank Sharma <[email protected]> Cc: Andrzej Hajda <[email protected]> Cc: Laurent Pinchart <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Shashank Sharma <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-11-15drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinksVille Syrjälä1-2/+10
Apparently some sinks look at the YQ bits even when receiving RGB, and they get somehow confused when they see a non-zero YQ value. So we can't just blindly follow CEA-861-F and set YQ to match the RGB range. Unfortunately there is no good way to tell whether the sink designer claims to have read CEA-861-F. The CEA extension block revision number has generally been stuck at 3 since forever, and even a very recently manufactured sink might be based on an old design so the manufacturing date doesn't seem like something we can use. In lieu of better information let's follow CEA-861-F only for HDMI 2.0 sinks, since HDMI 2.0 is based on CEA-861-F. For HDMI 1.x sinks we'll always set YQ=0. The alternative would of course be to always set YQ=0. And if we ever encounter a HDMI 2.0+ sink with this bug that's what we'll probably have to do. Cc: [email protected] Cc: Jani Nikula <[email protected]> Cc: Eric Anholt <[email protected]> Cc: Neil Kownacki <[email protected]> Reported-by: Neil Kownacki <[email protected]> Tested-by: Neil Kownacki <[email protected]> Fixes: fcc8a22cc905 ("drm/edid: Set YQ bits in the AVI infoframe according to CEA-861-F") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101639 Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Acked-by: Eric Anholt <[email protected]>
2017-11-07drm/edid: make drm_edid_to_eld() staticJani Nikula1-3/+2
This is no longer needed outside of drm_edid.c. Reviewed-by: Ville Syrjälä <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Acked-by: Thierry Reding <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/9c0be7b97d0144ed0419c87ac42b30f5835ca7e6.1509545641.git.jani.nikula@intel.com
2017-11-07drm/edid: build ELD in drm_add_edid_modes()Jani Nikula1-2/+6
Call drm_edid_to_eld() from drm_add_edid_modes() to fill in the ELD automatically. There's no harm in doing this for connectors that do not support audio. Reviewed-by: Ville Syrjälä <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Acked-by: Thierry Reding <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/551b2e1cf19be04c510e7865d7539cfc2f54ea89.1509545641.git.jani.nikula@intel.com
2017-11-07drm/edid: abstract connector ELD clearingJani Nikula1-8/+13
Preparation for future work. No functional changes. Reviewed-by: Ville Syrjälä <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Acked-by: Thierry Reding <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/95e83e7a62566b65a56c8cb5038ddf0c6b8e5e95.1509545641.git.jani.nikula@intel.com
2017-11-07drm/edid: set ELD connector type in drm_edid_to_eld()Jani Nikula1-2/+7
Since drm_edid_to_eld() knows the connector type, we can set the type in ELD while at it. Most connectors this gets called on are not DP encoders, and with the HDMI type being 0, this does not change behaviour for non-DP. For i915 having this in place earlier would have saved a considerable amount of debugging that lead to the fix 2d8f63297b9f ("drm/i915: always update ELD connector type after get modes"). I don't see other drivers, even the ones calling drm_edid_to_eld() on DP connectors, setting the connector type in ELD. Cc: Alex Deucher <[email protected]> Cc: Christian König <[email protected]> Cc: Archit Taneja <[email protected]> Cc: Andrzej Hajda <[email protected]> Cc: Russell King <[email protected]> Cc: CK Hu <[email protected]> Cc: Philipp Zabel <[email protected]> Cc: Ben Skeggs <[email protected]> Cc: Mark Yao <[email protected]> Cc: Benjamin Gaignard <[email protected]> Cc: Vincent Abriou <[email protected]> Cc: Thierry Reding <[email protected]> Cc: Eric Anholt <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Acked-by: Thierry Reding <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/d527b31619528c477c2c136f25cdf118bc0cfc1d.1509545641.git.jani.nikula@intel.com
2017-11-07drm/edid: use macros for ELD offsets and valuesJani Nikula1-13/+14
We have the macros, use them. No functional changes. Reviewed-by: Ville Syrjälä <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Acked-by: Thierry Reding <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/36f00f018280a04d2db806574d337f7512986c86.1509545641.git.jani.nikula@intel.com
2017-09-19drm: handle override and firmware EDID at drm_do_get_edid() levelJani Nikula1-0/+15
Handle debugfs override edid and firmware edid at the low level to transparently and completely replace the real edid. Previously, we practically only used the modes from the override EDID, and none of the other data, such as audio parameters. This change also prevents actual EDID reads when the EDID is to be overridden, but retains the DDC probe. This is useful if the reason for preferring override EDID are problems with reading the data, or corruption of the data. Move firmware EDID loading from helper to core, as the functionality moves to lower level as well. This will result in a change of module parameter from drm_kms_helper.edid_firmware to drm.edid_firmware, which arguably makes more sense anyway. Some future work remains related to override and firmware EDID validation. Like before, no validation is done for override EDID. The firmware EDID is validated separately in the loader. Some unification and deduplication would be in order, to validate all of them at the drm_do_get_edid() level, like "real" EDIDs. v2: move firmware loading to core v3: rebase, commit message refresh Cc: Abdiel Janulgue <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Ville Syrjälä <[email protected]> Tested-by: Abdiel Janulgue <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Acked-by: Dave Airlie <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/1e8a710bcac46e5136c1a7b430074893c81f364a.1505203831.git.jani.nikula@intel.com
2017-07-14drm/edid: parse ycbcr 420 deep color informationShashank Sharma1-0/+12
CEA-861-F spec adds ycbcr420 deep color support information in hf-vsdb block. This patch extends the existing hf-vsdb parsing function by adding parsing of ycbcr420 deep color support from the EDID and adding it into display information stored. V2: Rebase V3: Rebase V4: Moved definition of y420_dc_modes into this patch, where its used (Ville) V5: Optimize function, if(conditions) not reqd (Ville) V6: Rebase V7: Rebase Cc: Ville Syrjälä <[email protected]> Cc: Jose Abreu <[email protected]> Signed-off-by: Shashank Sharma <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] [vsyrjala: Fix sparse indentation warn] Signed-off-by: Ville Syrjälä <[email protected]>
2017-07-14drm/edid: parse YCBCR420 videomodes from EDIDShashank Sharma1-2/+150
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 <[email protected]> Cc: Jose Abreu <[email protected]> Cc: Emil Velikov <[email protected]> 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 <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] [vsyrjala: Fix checkpatch complaints and indentation] Signed-off-by: Ville Syrjälä <[email protected]>
2017-07-14drm/edid: cleanup patch for CEA extended-tag macroShashank Sharma1-3/+12
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 Cc: Ville Syrjala <[email protected]> Signed-off-by: Shashank Sharma <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Ville Syrjälä <[email protected]>
2017-07-14drm/edid: parse sink information before CEA blocksShashank Sharma1-2/+7
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 Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Shashank Sharma <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Ville Syrjälä <[email protected]>
2017-07-14drm/edid: complete CEA modedb(VIC 1-107)Shashank Sharma1-1/+225
CEA-861-F specs defines new video modes to be used with HDMI 2.0 EDIDs. The VIC range has been extended from 1-64 to 1-107. Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now to be able to parse new CEA modes using the existing methods, we have to complete the modedb (VIC=65 onwards). This patch adds: - Timings for existing CEA video modes (from VIC=65 till VIC=92) - Newly added 4k modes (from VIC=93 to VIC=107). The patch was originaly discussed and reviewed here: https://patchwork.freedesktop.org/patch/135810/ Cc: Ville Syrjala <[email protected]> Cc: Jose Abreu <[email protected]> Cc: Andrzej Hajda <[email protected]> Cc: Alex Deucher <[email protected]> Cc: Harry Wentland <[email protected]> V2: Rebase V3: Rebase V4: Added native bit handling as per CEA-861-F spec (Ville) V5: Fix timings for VIC 77:1920x1080 and 104:3840x2160p (Ville) Remove unnecessary paranthesis from function svd_to_vic (Ville) Added r-b (Neil) V6: Rebase V7: Fix indentation for modes from VIC 80 Reviewed-by: Jose Abreu <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Acked-by: Harry Wentland <[email protected]> Signed-off-by: Shashank Sharma <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] [vsyrjala: Fix up remaining formatting/indentation issues] Signed-off-by: Ville Syrjälä <[email protected]>
2017-07-14drm: handle HDMI 2.0 VICs in AVI info-framesShashank Sharma1-1/+25
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 <[email protected]> Cc: Jose Abreu <[email protected]> Cc: Andrzej Hajda <[email protected]> Cc: Alex Deucher <[email protected]> Cc: Daniel Vetter <[email protected]> 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 Reviewed-by: Andrzej Hajda <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Signed-off-by: Shashank Sharma <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Ville Syrjälä <[email protected]>
2017-05-02drm/edid: Add 10 bpc quirk for LGD 764 panel in HP zBook 17 G2Mario Kleiner1-0/+8
The builtin eDP panel in the HP zBook 17 G2 supports 10 bpc, as advertised by the Laptops product specs and verified via injecting a fixed edid + photometer measurements, but edid reports unknown depth, so drivers fall back to 6 bpc. Add a quirk to get the full 10 bpc. Cc: [email protected] Signed-off-by: Mario Kleiner <[email protected]> Acked-by: Harry Wentland <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-03-23BackMerge tag 'v4.11-rc3' into drm-nextDave Airlie1-0/+3
Linux 4.11-rc3 as requested by Daniel
2017-03-21drm/edid: detect SCDC support in HF-VSDBShashank Sharma1-1/+32
This patch does following: - Adds a new structure (drm_hdmi_info) in drm_display_info. This structure will be used to save and indicate if sink supports advanced HDMI 2.0 features - Adds another structure drm_scdc within drm_hdmi_info, to reflect scdc support and capabilities in connected HDMI 2.0 sink. - Checks the HF-VSDB block for presence of SCDC, and marks it in scdc structure - If SCDC is present, checks if sink is capable of generating SCDC read request, and marks it in scdc structure. V2: Addressed review comments Thierry: - Fix typos in commit message and make abbreviation consistent across the commit message. - Change structure object name from hdmi_info -> hdmi - Fix typos and abbreviations in description of structure drm_hdmi_info end the description with a full stop. - Create a structure drm_scdc, and keep all information related to SCDC register set (supported, read request supported) etc in it. Ville: - Change rr -> read_request - Call drm_detect_scrambling function drm_parse_hf_vsdb so that all of HF-VSDB parsing can be kept in same function, in incremental patches. V3: Rebase. V4: Rebase. V5: Rebase. V6: Addressed review comments from Ville - Add clock rate calculations for 1/10 and 1/40 ratios - Remove leftovers from old patchset V7: Added R-B from Jose. V8: Rebase. V9: Rebase. V10: Rebase. Signed-off-by: Shashank Sharma <[email protected]> Reviewed-by: Thierry Reding <[email protected]> Reviewed-by: Jose Abreu <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-03-21drm/edid: detect SCDC support in HF-VSDBShashank Sharma1-0/+14
This patch does following: - Adds a new structure (drm_hdmi_info) in drm_display_info. This structure will be used to save and indicate if sink supports advanced HDMI 2.0 features - Adds another structure drm_scdc within drm_hdmi_info, to reflect scdc support and capabilities in connected HDMI 2.0 sink. - Checks the HF-VSDB block for presence of SCDC, and marks it in scdc structure - If SCDC is present, checks if sink is capable of generating SCDC read request, and marks it in scdc structure. V2: Addressed review comments Thierry: - Fix typos in commit message and make abbreviation consistent across the commit message. - Change structure object name from hdmi_info -> hdmi - Fix typos and abbreviations in description of structure drm_hdmi_info end the description with a full stop. - Create a structure drm_scdc, and keep all information related to SCDC register set (supported, read request supported) etc in it. Ville: - Change rr -> read_request - Call drm_detect_scrambling function drm_parse_hf_vsdb so that all of HF-VSDB parsing can be kept in same function, in incremental patches. V3: Rebase. V4: Rebase. V5: Rebase. V6: Rebase. V7: Added R-B from Jose. V8: Rebase. V9: Rebase. V10: Rebase. Signed-off-by: Shashank Sharma <[email protected]> Reviewed-by: Thierry Reding <[email protected]> Reviewed-by: Jose Abreu <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-03-21drm/edid: check for HF-VSDB blockThierry Reding1-0/+15
This patch implements a small function that finds if a given CEA db is hdmi-forum vendor specific data block or not. V2: Rebase. V3: Added R-B from Jose. V4: Rebase V5: Rebase V6: Rebase V7: Rebase V8: Rebase V9: Rebase V10: Rebase Signed-off-by: Thierry Reding <[email protected]> Signed-off-by: Shashank Sharma <[email protected]> Reviewed-by: Jose Abreu <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-03-06drm/edid: Add EDID_QUIRK_FORCE_8BPC quirk for Rotel RSX-1058Tomeu Vizoso1-0/+3
Rotel RSX-1058 is a receiver with 4 HDMI inputs and a HDMI output, all 1.1. When a sink that supports deep color is connected to the output, the receiver will send EDIDs that advertise this capability, even if it isn't possible with HDMI versions earlier than 1.3. Currently the kernel is assuming that deep color is possible and the sink displays an error. This quirk will make sure that deep color isn't used with this particular receiver. Fixes: 7a0baa623446 ("Revert "drm/i915: Disable 12bpc hdmi for now"") Signed-off-by: Tomeu Vizoso <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Cc: [email protected] Cc: Matt Horan <[email protected]> Tested-by: Matt Horan <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99869 Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]>
2017-02-28gpu: drm: core: Convert printk(KERN_<LEVEL> to pr_<level>Joe Perches1-2/+2
Use a more common logging style. Miscellanea: o Coalesce formats and realign arguments Signed-off-by: Joe Perches <[email protected]> [danvet: Resolve minor conflict in drm_edid.c] Signed-off-by: Daniel Vetter <[email protected]>
2017-02-21drm/edid: respect connector force for drm_get_edid ddc probeJani Nikula1-1/+4
Skip DDC probe for forced connector status. Don't try to read the EDID if the connector is forced off. Skipping probe for forced on connectors will make more sense when drm_do_get_edid() will handle override and firmware EDIDs. Suggested-by: Ville Syrjälä <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-02-21drm: do not debug log about missing CEA extensions on NULL edidJani Nikula1-0/+3
Make the drm_edid_to_eld() function useful for resetting, not just setting, the ELD and HDMI VSDB data, without debug warnings about missing CEA extensions. Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-02-14drm: Reduce EDID warnings from DRM_ERROR to DRM_NOTEChris Wilson1-7/+8
The warnings from parsing the EDID are not driver errors, but the "normal but significant" conditions from the external device. As such, they do not need the ferocity of an *ERROR*, but can use the less harsh DRM_NOTE instead. Signed-off-by: Chris Wilson <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-02-08drm/edid: Don't print an error if the checksum of a CEA block is wrongTomeu Vizoso1-5/+8
It's common to share screens within CI labs, and it's also common for KVM switches to alter the contents of the CEA block but leave the checksum outdated. So in this case, print a debug message instead of an error. References: https://bugs.freedesktop.org/show_bug.cgi?id=98228 Cc: Chris Wilson <[email protected]> Cc: Tomi Sarvela <[email protected]> Cc: [email protected] Signed-off-by: Tomeu Vizoso <[email protected]> Tested-by: Jari Tahvanainen <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-02-01drm: Clean up the 1366x768 fixup codesTakashi Iwai1-3/+5
This is just a cleanup, no functional change. The fixup code for 1366x768 in drm_mode_create_from_cmdline_mode() is basically a copy of the existing code in drm_edid.c. Make the latter code public so that it can be called from the former function. Signed-off-by: Takashi Iwai <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Ville Syrjälä <[email protected]> [vsyrjala: include drm_crtc_internal.h to make sparse happy] Signed-off-by: Ville Syrjälä <[email protected]>
2017-01-26drm/edid: Set YQ bits in the AVI infoframe according to CEA-861-FVille Syrjälä1-0/+14
CEA-861-F tells us: "When transmitting any RGB colorimetry, the Source should set the YQ-field to match the RGB Quantization Range being transmitted (e.g., when Limited Range RGB, set YQ=0 or when Full Range RGB, set YQ=1) and the Sink shall ignore the YQ-field." So let's go ahead and do that. Perhaps there are sinks that don't ignore the YQ as they should for RGB? I wasn't able to find similar text in CEA-861-E, so it would seem to be a fairly "recent" addition. Signed-off-by: Ville Syrjälä <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]> Acked-by: Eric Anholt <[email protected]>
2017-01-26drm/edid: Set AVI infoframe Q even when QS=0Ville Syrjälä1-1/+7
HDMI 2.0 recommends that we set the Q bits in the AVI infoframe even when the sink does not support quantization range selection (QS=0). According to CEA-861 we can do that as long as the Q we send matches the default quantization range for the mode. Previously I think I had misread the spec as saying that you can't send a non-zero Q at all when QS=0. But that's not what the spec actually says. v2: Fix typo in commit message (Jani) Signed-off-by: Ville Syrjälä <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]> Acked-by: Eric Anholt <[email protected]>
2017-01-26drm/edid: Introduce drm_hdmi_avi_infoframe_quant_range()Ville Syrjälä1-0/+26
Pull the logic to populate the quantization range information in the AVI infoframe into a small helper. We'll be adding a bit more logic to it, and having it in a central place seems like a good idea since it's based on the CEA-861 spec. Signed-off-by: Ville Syrjälä <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]> Acked-by: Eric Anholt <[email protected]>
2017-01-26drm/edid: Introduce drm_default_rgb_quant_range()Ville Syrjälä1-0/+19
Make the code selecting the RGB quantization range a little less magicy by wrapping it up in a small helper. v2: s/adjusted_mode/mode in vc4 to make it actually compile v3: Add a comment proposed by Eric Signed-off-by: Ville Syrjälä <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]> Acked-by: Eric Anholt <[email protected]>
2017-01-02drm/edid: constify edid quirk listJani Nikula1-3/+3
No reason not to be const. Reviewed-by: Daniel Vetter <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2016-12-18drm: Don't include <drm/drm_encoder.h> in <drm/drm_crtc.h>Laurent Pinchart1-0/+1
<drm/drm_crtc.h> used to define most of the in-kernel KMS API. It has now been split into separate files for each object type, but still includes most other KMS headers to avoid breaking driver compilation. As a step towards fixing that problem, remove the inclusion of <drm/drm_encoder.h> from <drm/drm_crtc.h> and include it instead where appropriate. Also remove the forward declarations of the drm_encoder and drm_encoder_helper_funcs structures from <drm/drm_crtc.h> as they're not needed in the header. <drm/drm_encoder.h> now has to include <drm/drm_mode.h> and contain a forward declaration of struct drm_encoder in order to allow including it as the first header in a compilation unit. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Reviewed-by: Sinclair Yeh <[email protected]> # For vmwgfx Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Archit Taneja <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/1481709550-29226-2-git-send-email-laurent.pinchart+renesas@ideasonboard.com
2016-11-30Merge tag 'drm-misc-next-2016-11-29' of ↵Dave Airlie1-12/+54
git://anongit.freedesktop.org/git/drm-misc into drm-next Big thing is that drm-misc is now officially a group maintainer/committer model thing, with MAINTAINERS suitably updated. Otherwise just the usual pile of misc things all over, nothing that stands out this time around. * tag 'drm-misc-next-2016-11-29' of git://anongit.freedesktop.org/git/drm-misc: (33 commits) drm: Introduce drm_framebuffer_assign() drm/bridge: adv7511: Enable the audio data and clock pads on adv7533 drm/bridge: adv7511: Add Audio support drm/edid: Consider alternate cea timings to be the same VIC drm/atomic: Constify drm_atomic_crtc_needs_modeset() drm: bridge: dw-hdmi: add ASoC dependency drm: Fix shift operations for drm_fb_helper::drm_target_preferred() drm: Avoid NULL dereference for DRM_LEGACY debug message drm: Use u64_to_user_ptr() helper for blob ioctls drm: Fix conflicting macro parameter in drm_mm_for_each_node_in_range() drm: Fixup kernel doc for driver->gem_create_object drm/hisilicon/hibmc: mark PM functions __maybe_unused drm/hisilicon/hibmc: Checking for NULL instead of IS_ERR() drm: bridge: add DesignWare HDMI I2S audio support drm: Check against color expansion in drm_mm_reserve_node() drm: Define drm_mm_for_each_node_in_range() drm/doc: Fix links in drm_property.c MAINTAINERS: Add link to drm-misc documentation vgaarb: use valid dev pointer in vgaarb_info() drm/atomic: Unconfuse the old_state mess in commmit_tail ...
2016-11-28drm/edid: Consider alternate cea timings to be the same VICVille Syrjälä1-12/+54
CEA-861 specifies that the vertical front porch may vary by one or two lines for specific VICs. Up to now we've only considered a mode to match the VIC if it matched the shortest possible vertical front porch length (as that is the variant we store in cea_modes[]). Let's allow our VIC matching to work with the other timings variants as well so that that we'll send out the correct VIC if the variant actually used isn't the one with the shortest vertical front porch. Cc: Shashank Sharma <[email protected]> Cc: Andrzej Hajda <[email protected]> Cc: Adam Jackson <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Andrzej Hajda <[email protected]>
2016-11-17Merge remote-tracking branch 'airlied/drm-next' into drm-intel-next-queuedDaniel Vetter1-2/+2
Tvrtko needs commit b3c11ac267d461d3d597967164ff7278a919a39f Author: Eric Engestrom <[email protected]> Date: Sat Nov 12 01:12:56 2016 +0000 drm: move allocation out of drm_get_format_name() to be able to apply his patches without conflicts. Signed-off-by: Daniel Vetter <[email protected]>
2016-11-09drm/edid: Remove drm_select_eldMaarten Lankhorst1-26/+0
The only user was i915, which is now gone. Signed-off-by: Maarten Lankhorst <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Acked-by: Dave Airlie <[email protected]> #irc Cc: [email protected] Link: http://patchwork.freedesktop.org/patch/msgid/1478609742-13603-9-git-send-email-maarten.lankhorst@linux.intel.com
2016-11-08drm/edid: Add the missing "Hz" to VIC 58,59 commentVille Syrjälä1-2/+2
All the VICs apart from 58 and 59 have the word "Hz" included in the comment. Include it for 59 and 59 as well. Cc: Shashank Sharma <[email protected]> Cc: Andrzej Hajda <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Andrzej Hajda <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.