summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/drm_modes.c
AgeCommit message (Collapse)AuthorFilesLines
2019-08-09Merge tag 'drm-misc-next-2019-08-08' of ↵Dave Airlie1-6/+11
git://anongit.freedesktop.org/drm/drm-misc into drm-next drm-misc-next for 5.4: UAPI Changes: - HDCP: Add a Content protection type property Cross-subsystem Changes: Core Changes: - Continue to rework the include dependencies - fb: Remove the unused drm_gem_fbdev_fb_create function - drm-dp-helper: Make the link rate calculation more tolerant to non-explicitly defined, yet supported, rates - fb-helper: Map DRM client buffer only when required, and instanciate a shadow buffer when the device has a dirty function or says so - connector: Add a helper to link the DDC adapter used by that connector to the userspace - vblank: Switch from DRM_WAIT_ON to wait_event_interruptible_timeout - dma-buf: Fix a stack corruption - ttm: Embed a drm_gem_object struct to make ttm_buffer_object a superclass of GEM, and convert drivers to use it. - hdcp: Improvements to report the content protection type to the userspace Driver Changes: - Remove drm_gem_prime_import/export from being defined in the drivers - Drop DRM_AUTH usage from drivers - Continue to drop drmP.h - Convert drivers to the connector ddc helper - ingenic: Add support for more panel-related cases - komeda: Support for dual-link - lima: Reduce logging - mpag200: Fix the cursor support - panfrost: Export GPU features register to userspace through an ioctl - pl111: Remove the CLD pads wiring support from the DT - rockchip: Rework to use DRM PSR helpers, fix a bug in the VOP_WIN_GET macro - sun4i: Improve support for color encoding and range - tinydrm: Rework SPI support, improve MIPI-DBI support, move to drm/tiny - vkms: Rework of the CRC tracking - bridges: - sii902x: Add support for audio graph card - tc358767: Rework AUX data handling code - ti-sn65dsi86: Add Debugfs and proper DSI mode flags support - panels - Support for GiantPlus GPM940B0, Sharp LQ070Y3DG3B, Ortustech COM37H3M, Novatek NT39016, Sharp LS020B1DD01D, Raydium RM67191, Boe Himax8279d, Sharp LD-D5116Z01B - Conversion of the device tree bindings to the YAML description - jh057n00900: Rework the enable / disable path - fbdev: - ssd1307fb: Support more devices based on that controller Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190808121423.xzpedzkpyecvsiy4@flea
2019-07-22Merge branch 'pdf_fixes_v1' of https://git.linuxtv.org/mchehab/experimental ↵Jonathan Corbet1-1/+1
into mauro Bring in a set of post-thrashup fixes from Mauro.
2019-07-22Merge v5.3-rc1 into drm-misc-nextMaxime Ripard1-4/+10
Noralf needs some SPI patches in 5.3 to merge some work on tinydrm. Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
2019-07-17docs: fix broken doc references due to renamesMauro Carvalho Chehab1-1/+1
Some files got renamed but probably due to some merge conflicts, a few references still point to the old locations. Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2019-07-10drm/modes: Skip invalid cmdline modeDmitry Osipenko1-0/+6
The named mode could be invalid and then cmdline parser misses to validate mode's dimensions, happily adding 0x0 mode as a valid mode. One case where this happens is NVIDIA Tegra devices that are using downstream bootloader which adds "video=tegrafb" to the kernel's cmdline and thus upstream Tegra DRM driver fails to probe because of the invalid mode. Fixes: 3aeeb13d8996 ("drm/modes: Support modes names on the command line") Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190709145151.23086-1-digetx@gmail.com
2019-07-01drm/selftests: reduce stack usageArnd Bergmann1-4/+4
Putting a large drm_connector object on the stack can lead to warnings in some configuration, such as: drivers/gpu/drm/selftests/test-drm_cmdline_parser.c:18:12: error: stack frame size of 1040 bytes in function 'drm_cmdline_test_res' [-Werror,-Wframe-larger-than=] static int drm_cmdline_test_res(void *ignored) Since the object is never modified, just declare it as 'static const' and allow this to be passed down. Fixes: b7ced38916a9 ("drm/selftests: Add command line parser selftests") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190628121712.1928142-1-arnd@arndb.de
2019-06-24drm: WARN on illegal aspect ratio when converting a mode to umodeVille Syrjälä1-1/+4
WARN if the incoming drm_display_mode has an illegal aspect ratio when converting it to a user mode. This should never happen unless the driver made a mistake and put an invalid value into the aspect ratio. Cc: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190620142639.17518-4-ville.syrjala@linux.intel.com Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2019-06-24drm: Do not accept garbage mode aspect ratio flagsVille Syrjälä1-1/+3
Don't let userspace feed us any old garbage in the mode aspect ratio flags. Cc: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190620142639.17518-3-ville.syrjala@linux.intel.com Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2019-06-24drm: Do not use bitwise OR to set picure_aspect_ratioVille Syrjälä1-4/+4
enum hdmi_picture_aspect is not a bitmask, so don't use bitwise OR to populate it. Cc: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190620142639.17518-2-ville.syrjala@linux.intel.com Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2019-06-19drm/modes: Parse overscan propertiesMaxime Ripard1-0/+44
Properly configuring the overscan properties might be needed for the initial setup of the framebuffer for display that still have overscan. Let's allow for more properties on the kernel command line to setup each margin. Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/e481f1628e3768ca49226ec2115cfa4dfcbd5e4c.1560783090.git-series.maxime.ripard@bootlin.com
2019-06-19drm/modes: Allow to specify rotation and reflection on the commandlineMaxime Ripard1-20/+94
Rotations and reflections setup are needed in some scenarios to initialise properly the initial framebuffer. Some drivers already had a bunch of quirks to deal with this, such as either a private kernel command line parameter (omapdss) or on the device tree (various panels). In order to accomodate this, let's create a video mode parameter to deal with the rotation and reflexion. Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/777da16e42db757c1f5b414b5ca34507097fed5c.1560783090.git-series.maxime.ripard@bootlin.com
2019-06-19drm/modes: Support modes names on the command lineMaxime Ripard1-16/+46
The drm subsystem also uses the video= kernel parameter, and in the documentation refers to the fbdev documentation for that parameter. However, that documentation also says that instead of giving the mode using its resolution we can also give a name. However, DRM doesn't handle that case at the moment. Even though in most case it shouldn't make any difference, it might be useful for analog modes, where different standards might have the same resolution, but still have a few different parameters that are not encoded in the modes (NTSC vs NTSC-J vs PAL-M for example). Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/18443e0c3bdbbd16cea4ec63bc7f2079b820b43b.1560783090.git-series.maxime.ripard@bootlin.com
2019-06-19drm/modes: Rewrite the command line parserMaxime Ripard1-115/+210
Rewrite the command line parser in order to get away from the state machine parsing the video mode lines. Hopefully, this will allow to extend it more easily to support named modes and / or properties set directly on the command line. Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/e32cd4009153b184103554009135c7bf7c9975d7.1560783090.git-series.maxime.ripard@bootlin.com
2019-05-27drm: drop use of drmP.h in drm/*Sam Ravnborg1-2/+5
The use of the drmP.h header file is deprecated. Remove use from all files in drm/* so people do not look there and follow a bad example. Build tested allyesconfig,allmodconfig on x86, arm etc. Including alpha that is as always more challenging than the rest. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Daniel Vetter <daniel@ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Sean Paul <sean@poorly.run> Cc: David Airlie <airlied@linux.ie> Link: https://patchwork.freedesktop.org/patch/msgid/20190526173535.32701-8-sam@ravnborg.org
2019-03-18drm: Use new DRM_BUS_FLAG_*_(DRIVE|SAMPLE)_(POS|NEG)EDGE flagsLaurent Pinchart1-6/+6
The DRM_BUS_FLAG_PIXDATA_(POS|NEG)EDGE and DRM_BUS_FLAG_SYNC_(POS|NEG)EDGE flags are deprecated in favour of the new DRM_BUS_FLAG_PIXDATA_(DRIVE|SAMPLE)_(POS|NEG)EDGE and new DRM_BUS_FLAG_SYNC_(DRIVE|SAMPLE)_(POS|NEG)EDGE flags. Replace them through the code. This effectively changes the value of the .sampling_edge bridge timings field in the dumb-vga-dac driver. This is safe to do as no driver consumes these values yet. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Stefan Agner <stefan@agner.ch> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2019-02-18Merge v5.0-rc7 into drm-nextDave Airlie1-1/+1
Backmerging for nouveau and imx that needed some fixes for next pulls. Signed-off-by: Dave Airlie <airlied@redhat.com>
2019-02-04drm: Trivial comment grammar cleanupsMatt Roper1-1/+1
Most of these are just cases where code comments used contractions (it's, who's) where they actually mean to use a possessive pronoun (its, whose) or vice-versa. Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190202012326.20096-1-matthew.d.roper@intel.com
2019-01-24drm/modes: Prevent division by zero htotalTina Zhang1-1/+1
This patch prevents division by zero htotal. In a follow-up mail Tina writes: > > How did you manage to get here with htotal == 0? This needs backtraces (or if > > this is just about static checkers, a mention of that). > > -Daniel > > In GVT-g, we are trying to enable a virtual display w/o setting timings for a pipe > (a.k.a htotal=0), then we met the following kernel panic: > > [ 32.832048] divide error: 0000 [#1] SMP PTI > [ 32.833614] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.18.0-rc4-sriov+ #33 > [ 32.834438] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.10.1-0-g8891697-dirty-20180511_165818-tinazhang-linux-1 04/01/2014 > [ 32.835901] RIP: 0010:drm_mode_hsync+0x1e/0x40 > [ 32.836004] Code: 31 c0 c3 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 8b 87 d8 00 00 00 85 c0 75 22 8b 4f 68 85 c9 78 1b 69 47 58 e8 03 00 00 99 <f7> f9 b9 d3 4d 62 10 05 f4 01 00 00 f7 e1 89 d0 c1 e8 06 f3 c3 66 > [ 32.836004] RSP: 0000:ffffc900000ebb90 EFLAGS: 00010206 > [ 32.836004] RAX: 0000000000000000 RBX: ffff88001c67c8a0 RCX: 0000000000000000 > [ 32.836004] RDX: 0000000000000000 RSI: ffff88001c67c000 RDI: ffff88001c67c8a0 > [ 32.836004] RBP: ffff88001c7d03a0 R08: ffff88001c67c8a0 R09: ffff88001c7d0330 > [ 32.836004] R10: ffffffff822c3a98 R11: 0000000000000001 R12: ffff88001c67c000 > [ 32.836004] R13: ffff88001c7d0370 R14: ffffffff8207eb78 R15: ffff88001c67c800 > [ 32.836004] FS: 0000000000000000(0000) GS:ffff88001da00000(0000) knlGS:0000000000000000 > [ 32.836004] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 32.836004] CR2: 0000000000000000 CR3: 000000000220a000 CR4: 00000000000006f0 > [ 32.836004] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > [ 32.836004] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 > [ 32.836004] Call Trace: > [ 32.836004] intel_mode_from_pipe_config+0x72/0x90 > [ 32.836004] intel_modeset_setup_hw_state+0x569/0xf90 > [ 32.836004] intel_modeset_init+0x905/0x1db0 > [ 32.836004] i915_driver_load+0xb8c/0x1120 > [ 32.836004] i915_pci_probe+0x4d/0xb0 > [ 32.836004] local_pci_probe+0x44/0xa0 > [ 32.836004] ? pci_assign_irq+0x27/0x130 > [ 32.836004] pci_device_probe+0x102/0x1c0 > [ 32.836004] driver_probe_device+0x2b8/0x480 > [ 32.836004] __driver_attach+0x109/0x110 > [ 32.836004] ? driver_probe_device+0x480/0x480 > [ 32.836004] bus_for_each_dev+0x67/0xc0 > [ 32.836004] ? klist_add_tail+0x3b/0x70 > [ 32.836004] bus_add_driver+0x1e8/0x260 > [ 32.836004] driver_register+0x5b/0xe0 > [ 32.836004] ? mipi_dsi_bus_init+0x11/0x11 > [ 32.836004] do_one_initcall+0x4d/0x1eb > [ 32.836004] kernel_init_freeable+0x197/0x237 > [ 32.836004] ? rest_init+0xd0/0xd0 > [ 32.836004] kernel_init+0xa/0x110 > [ 32.836004] ret_from_fork+0x35/0x40 > [ 32.836004] Modules linked in: > [ 32.859183] ---[ end trace 525608b0ed0e8665 ]--- > [ 32.859722] RIP: 0010:drm_mode_hsync+0x1e/0x40 > [ 32.860287] Code: 31 c0 c3 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 8b 87 d8 00 00 00 85 c0 75 22 8b 4f 68 85 c9 78 1b 69 47 58 e8 03 00 00 99 <f7> f9 b9 d3 4d 62 10 05 f4 01 00 00 f7 e1 89 d0 c1 e8 06 f3 c3 66 > [ 32.862680] RSP: 0000:ffffc900000ebb90 EFLAGS: 00010206 > [ 32.863309] RAX: 0000000000000000 RBX: ffff88001c67c8a0 RCX: 0000000000000000 > [ 32.864182] RDX: 0000000000000000 RSI: ffff88001c67c000 RDI: ffff88001c67c8a0 > [ 32.865206] RBP: ffff88001c7d03a0 R08: ffff88001c67c8a0 R09: ffff88001c7d0330 > [ 32.866359] R10: ffffffff822c3a98 R11: 0000000000000001 R12: ffff88001c67c000 > [ 32.867213] R13: ffff88001c7d0370 R14: ffffffff8207eb78 R15: ffff88001c67c800 > [ 32.868075] FS: 0000000000000000(0000) GS:ffff88001da00000(0000) knlGS:0000000000000000 > [ 32.868983] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 32.869659] CR2: 0000000000000000 CR3: 000000000220a000 CR4: 00000000000006f0 > [ 32.870599] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > [ 32.871598] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 > [ 32.872549] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b > > Since drm_mode_hsync() has the logic to check mode->htotal, I just extend it to cover the case htotal==0. Signed-off-by: Tina Zhang <tina.zhang@intel.com> Cc: Adam Jackson <ajax@redhat.com> Cc: Dave Airlie <airlied@redhat.com> Cc: Daniel Vetter <daniel@ffwll.ch> [danvet: Add additional explanations + cc: stable.] Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1548228539-3061-1-git-send-email-tina.zhang@intel.com
2019-01-15drm: Remove use of drm_mode_objectShayenne Moura1-9/+0
This patch removes the drm_mode_object prints, evaluation and use from drm_display_mode objects used in drm files. It removes dependency from drm_mode_object. Signed-off-by: Shayenne Moura <shayenneluzmoura@gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/785896b0a551464d0b780a55411707300802d6b6.1547214023.git.shayenneluzmoura@gmail.com
2018-10-01drm: Convert to using %pOFn instead of device_node.nameRob Herring1-2/+2
In preparation to remove the node name pointer from struct device_node, convert printf users to use the %pOFn format specifier. For drm_modes.c, the full node path is already printed out, so printing just the node name a 2nd time is redundant and can be removed. Cc: Gustavo Padovan <gustavo@padovan.org> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Sean Paul <sean@poorly.run> Cc: David Airlie <airlied@linux.ie> Acked-by: Rob Clark <robdclark@gmail.com> Cc: dri-devel@lists.freedesktop.org Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20180928225044.20132-1-robh@kernel.org
2018-07-13drm: drop _mode_ from remaining connector functionsDaniel Vetter1-3/+3
Since there's very few callers of these I've decided to do them all in one patch. With this the unecessarily long drm_mode_connector_ prefix is gone from the codebase! The only exception being struct drm_mode_connector_set_property, which is part of the uapi so can't be renamed. Again done with sed+some manual fixups for indent issues. Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180709084016.23750-8-daniel.vetter@ffwll.ch
2018-07-10drm: Add support for extracting sync signal drive edge from videomodePeter Ujfalusi1-4/+11
The sync in some panels needs to be driven by different edge of the pixel clock compared to data. This is reflected by the DISPLAY_FLAGS_SYNC_(POS|NEG)EDGE in videmode flags. Add similar similar definitions for bus_flags and convert the sync drive edge via drm_bus_flags_from_videomode(). Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Jyri Sarha <jsarha@ti.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180618132242.8673-2-tomi.valkeinen@ti.com
2018-06-15drm: Print bad user modesVille Syrjälä1-1/+1
Print out the modeline when we reject a bad user mode. Avoids having to guess why it was rejected. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180611193403.16118-2-ville.syrjala@linux.intel.com Reviewed-by: Harry Wentland <harry.wentland@amd.com>
2018-05-11drm: Add and handle new aspect ratios in DRM layerShashank Sharma1-0/+12
HDMI 2.0/CEA-861-F introduces two new aspect ratios: - 64:27 - 256:135 This patch: - Adds new DRM flags for to represent these new aspect ratios. - Adds new cases to handle these aspect ratios while converting from user->kernel mode or vise versa. This patch was once reviewed and merged, and later reverted due to lack of DRM client protection, while adding aspect ratio bits in user modes. This is a re-spin of the series, with DRM client cap protection. The previous series can be found here: https://pw-emeril.freedesktop.org/series/10850/ Signed-off-by: Shashank Sharma <shashank.sharma@intel.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> (V2) Reviewed-by: Jose Abreu <Jose.Abreu@synopsys.com> (V2) Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: Jose Abreu <Jose.Abreu@synopsys.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> V3: rebase V4: rebase V5: corrected the macro name for an aspect ratio, in a switch case. V6: rebase V7: rebase V8: rebase V9: rebase V10: rebase V11: rebase V12: rebase V13: rebase V14: rebase Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1525777785-9740-11-git-send-email-ankit.k.nautiyal@intel.com
2018-05-11drm: Add aspect ratio parsing in DRM layerShashank Sharma1-1/+34
Current DRM layer functions don't parse aspect ratio information while converting a user mode->kernel mode or vice versa. This causes modeset to pick mode with wrong aspect ratio, eventually causing failures in HDMI compliance test cases, due to wrong VIC. This patch adds aspect ratio information in DRM's mode conversion and mode comparision functions, to make sure kernel picks mode with right aspect ratio (as per the VIC). Background: This patch was once reviewed and merged, and later reverted due to lack of DRM cap protection. This is a re-spin of this patch, this time with DRM cap protection, to avoid aspect ratio information, when the client doesn't request for it. Review link: https://pw-emeril.freedesktop.org/patch/104068/ Background discussion: https://patchwork.kernel.org/patch/9379057/ Signed-off-by: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Lin, Jia <lin.a.jia@intel.com> Signed-off-by: Akashdeep Sharma <akashdeep.sharma@intel.com> Reviewed-by: Jim Bride <jim.bride@linux.intel.com> (V2) Reviewed-by: Jose Abreu <Jose.Abreu@synopsys.com> (V4) Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Jim Bride <jim.bride@linux.intel.com> Cc: Jose Abreu <Jose.Abreu@synopsys.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> V3: modified the aspect-ratio check in drm_mode_equal as per new flags provided by Ville. https://patchwork.freedesktop.org/patch/188043/ V4: rebase V5: rebase V6: As recommended by Ville, avoided matching of aspect-ratio in drm_fb_helper, while trying to find a common mode among connectors for the target clone mode. V7: rebase V8: rebase V9: rebase V10: rebase V11: rebase V12: rebase V13: rebase V14: rebase Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1525777785-9740-10-git-send-email-ankit.k.nautiyal@intel.com
2018-05-11drm/modes: Introduce drm_mode_match()Ville Syrjälä1-31/+103
Make mode matching less confusing by allowing the caller to specify which parts of the modes should match via some flags. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1525777785-9740-2-git-send-email-ankit.k.nautiyal@intel.com
2018-03-23drm: Fix uabi regression by allowing garbage mode->type from userspaceVille Syrjälä1-1/+7
Apparently xf86-video-vmware leaves the mode->type uninitialized when feeding the mode to the kernel. Thus we have no choice but to accept the garbage in. We'll just ignore any of the bits we don't want. The mode type is just a hint anyway, and more useful for the kernel->userspace direction. Reported-by: Thomas Hellstrom <thomas@shipmail.org> CC: Thomas Hellstrom <thomas@shipmail.org> Cc: Adam Jackson <ajax@redhat.com> Cc: Alex Deucher <alexander.deucher@amd.com> Fixes: c6ed6dad5cfb ("drm/uapi: Validate the mode flags/type") References: https://lists.freedesktop.org/archives/dri-devel/2018-March/170213.html Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180321211246.10152-1-ville.syrjala@linux.intel.com Tested-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Daniel Stone <daniels@collabora.com>
2018-03-16drm: Make drm_mode_vrefresh() a bit more accurateVille Syrjälä1-10/+9
Do the refresh rate calculation with a single division. This gives us slightly more accurate results, especially for interlaced since we don't just double the final truncated result. We do lose one bit compared to the old way, so with an interlaced mode the new code can only handle ~2GHz instead of the ~4GHz the old code handeled. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180313150759.27620-2-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2018-03-16drm: Nuke the useless 'ret' variable from drm_mode_convert_umode()Ville Syrjälä1-11/+4
No need to store the return value in a variable since we don't have to do any unwinding. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180313150759.27620-1-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2018-02-20drm/doc: Polish for drm_mode_parse_command_line_for_connectorDaniel Vetter1-2/+2
Quoting the module option format looks soo much nicer, and avoids sphinx spewing errors about markup issues. v2: Fix typo in commit message (Thierry). Reviewed-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180219225356.24996-4-daniel.vetter@ffwll.ch
2018-01-29drm/modes: Provide global mode_valid hookVille Syrjälä1-14/+34
Allow drivers to provide a device wide .mode_valid() hook in addition to the already existing crtc/encoder/bridge/connector hooks. This can be used to validate device/driver wide constraings without having to add those to the other hooks. And since we call this hook also for user modes later on in the modeset we don't have to worry about anything the hook has already rejected. I also have some further ideas for this hook. Eg. we could replace the drm_mode_set_crtcinfo(HALVE_V) call in drm_mode_convert_umode()/etc. with a driver specific variant via this hook. At least on i915 we would like to pass CRTC_STEREO_DOUBLE to that function instead, and then we could safely use the crtc_ timings in all our .mode_valid() hooks, which would allow us to reuse those hooks for validating the adjusted_mode during a modeset. v2: Fix the language fails in the kernel docs (Daniel) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171114183258.16976-10-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2018-01-29drm/modes: Kill off the oddball DRM_MODE_TYPE_CRTC_C vs. ↵Ville Syrjälä1-1/+1
DRM_MODE_TYPE_BUILTIN handling For some reason drm_mode_set_crtcinfo() does nothing if the mode has the DRM_MODE_TYPE_BUILTIN flag set without the other bit from DRM_MODE_TYPE_CRTC_C also set. I have zero idea what that is supposed to achieve, but since we have no users for neither flag bit let's kill this nonsense off. v2: Fix typo in commit message Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171114183258.16976-7-ville.syrjala@linux.intel.com Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2018-01-29drm/uapi: Validate the mode flags/typeVille Syrjälä1-0/+6
Currently userspace is allowed to feed in any king of garbage in the high bits of the mode flags/type, as are drivers when probing modes. Reject any mode with bogus flags/type. Hopefully this won't break any current userspace... v2: Split the type and flags checks to separates ifs (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jose Abreu <Jose.Abreu@synopsys.com> Cc: Adam Jackson <ajax@redhat.com> Cc: Keith Packard <keithp@keithp.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171115154913.23827-1-ville.syrjala@linux.intel.com Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2018-01-29drm/modes: Move 3D stereo flag check into drm_mode_validate_basic()Ville Syrjälä1-3/+3
Currently we don't sanity check the 3D stereo flags for modes filled out by the kernel. Move the check from drm_mode_convert_umode() into drm_mode_validate_basic() so that we get the same check going both ways. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171114183258.16976-2-ville.syrjala@linux.intel.com Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2017-07-31drm/modes: Fix drm_mode_is_420_only() commentSean Paul1-1/+1
Fixes the following warnings when building docs: ../drivers/gpu/drm/drm_modes.c:1623: warning: No description found for parameter 'display' ../drivers/gpu/drm/drm_modes.c:1623: warning: Excess function parameter 'connector' description in 'drm_mode_is_420_only' Signed-off-by: Sean Paul <seanpaul@chromium.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170720174746.29100-2-seanpaul@chromium.org
2017-07-26drm: Convert to using %pOF instead of full_nameRob Herring1-2/+2
Now that we have a custom printf format specifier, convert users of full_name to use %pOF instead. This is preparation to remove storing of the full path string for each node. Signed-off-by: Rob Herring <robh@kernel.org> Cc: Russell King <linux@armlinux.org.uk> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: Inki Dae <inki.dae@samsung.com> Cc: Joonyoung Shim <jy0922.shim@samsung.com> Cc: Seung-Woo Kim <sw0312.kim@samsung.com> Cc: Kyungmin Park <kyungmin.park@samsung.com> Cc: Kukjin Kim <kgene@kernel.org> Cc: Krzysztof Kozlowski <krzk@kernel.org> Cc: Javier Martinez Canillas <javier@osg.samsung.com> Cc: Xinliang Liu <z.liuxinliang@hisilicon.com> Cc: Rongrong Zou <zourongrong@gmail.com> Cc: Xinwei Kong <kong.kongxinwei@hisilicon.com> Cc: Chen Feng <puck.chen@hisilicon.com> Cc: CK Hu <ck.hu@mediatek.com> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Carlo Caione <carlo@caione.org> Cc: Kevin Hilman <khilman@baylibre.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Mark Yao <mark.yao@rock-chips.com> Cc: Heiko Stuebner <heiko@sntech.de> Cc: Maxime Ripard <maxime.ripard@free-electrons.com> Cc: Chen-Yu Tsai <wens@csie.org> Cc: Jyri Sarha <jsarha@ti.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: dri-devel@lists.freedesktop.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-samsung-soc@vger.kernel.org Cc: linux-mediatek@lists.infradead.org Cc: linux-amlogic@lists.infradead.org Cc: linux-renesas-soc@vger.kernel.org Cc: linux-rockchip@lists.infradead.org Partially-Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com> [seanpaul changed subject prefix and fixed conflict in stm/ltdc.c] Signed-off-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-14drm: add helper functions for YCBCR420 handlingShashank Sharma1-0/+58
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>
2017-07-14drm: add helper to validate YCBCR420 modesShashank Sharma1-0/+29
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>
2017-02-28drm: Rename drm_mode_object_get()Thierry Reding1-1/+1
Subsequent patches will introduce reference counting APIs that are more consistent with similar APIs throughout the Linux kernel. These APIs use the _get() and _put() suffixes and will collide with this existing function. Rename the function to drm_mode_object_add() which is a slightly more accurate description of what it does. Also the kerneldoc for this function gives an indication that it's badly named because it doesn't actually acquire a reference to anything. Reviewed-by: Sean Paul <seanpaul@chromium.org> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170228144643.5668-2-thierry.reding@gmail.com
2017-02-01drm: Clean up the 1366x768 fixup codesTakashi Iwai1-6/+2
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 <tiwai@suse.de> Link: http://patchwork.freedesktop.org/patch/msgid/20170117164329.10551-1-tiwai@suse.de Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> [vsyrjala: include drm_crtc_internal.h to make sparse happy] Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2017-02-01Merge tag 'drm-misc-next-2017-01-30' of ↵Dave Airlie1-0/+20
git://anongit.freedesktop.org/git/drm-misc into drm-next Another round of -misc stuff: - Noralf debugfs cleanup cleanup (not yet everything, some more driver patches awaiting acks). - More doc work. - edid/infoframe fixes from Ville. - misc 1-patch fixes all over, as usual Noralf needs this for his tinydrm pull request. * tag 'drm-misc-next-2017-01-30' of git://anongit.freedesktop.org/git/drm-misc: (48 commits) drm/vc4: Remove vc4_debugfs_cleanup() dma/fence: Export enable-signaling tracepoint for emission by drivers drm/tilcdc: Remove tilcdc_debugfs_cleanup() drm/tegra: Remove tegra_debugfs_cleanup() drm/sti: Remove drm_debugfs_remove_files() calls drm/radeon: Remove drm_debugfs_remove_files() call drm/omap: Remove omap_debugfs_cleanup() drm/hdlcd: Remove hdlcd_debugfs_cleanup() drm/etnaviv: Remove etnaviv_debugfs_cleanup() drm/etnaviv: allow build with COMPILE_TEST drm/amd/amdgpu: Remove drm_debugfs_remove_files() call drm/prime: Clarify DMA-BUF/GEM Object lifetime drm/ttm: Make sure BOs being swapped out are cacheable drm/atomic: Remove drm_atomic_debugfs_cleanup() drm: drm_minor_register(): Clean up debugfs on failure drm: debugfs: Remove all files automatically on cleanup drm/fourcc: add vivante tiled layout format modifiers drm/edid: Set YQ bits in the AVI infoframe according to CEA-861-F drm/edid: Set AVI infoframe Q even when QS=0 drm/edid: Introduce drm_hdmi_avi_infoframe_quant_range() ...
2017-01-26drm: Silence the compiler for drm_mode_get_hv_timings()Chris Wilson1-2/+1
Since moving drm_crtc_get_hv_timings() into drm_modes.c, the compiler has been able to get smarter and spots that drm_mode_copy() is trying to preserve garbage from the stack. Fixes: 196cd5d3758c ("drm: s/drm_crtc_get_hv_timings/drm_mode_get_hv_timings/") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170126114409.9115-1-chris@chris-wilson.co.uk
2017-01-26drm: s/drm_crtc_get_hv_timings/drm_mode_get_hv_timings/Daniel Vetter1-0/+21
The function operates on modes, not CRTCs. Also move it into drm_modes.[hc]. Spotted while reviewing CRTC docs. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170125062657.19270-15-daniel.vetter@ffwll.ch
2017-01-11drm: Fix broken VT switch with video=1366x768 optionTakashi Iwai1-0/+7
I noticed that the VT switch doesn't work any longer with a Dell laptop with 1366x768 eDP when the machine is connected with a DP monitor. It behaves as if VT were switched, but the graphics remain frozen. Actually the keyboard works, so I could switch back to VT7 again. I tried to track down the problem, and encountered a long story until we reach to this error: - The machine is booted with video=1366x768 option (the distro installer seems to add it as default). - Recently, drm_helper_probe_single_connector_modes() deals with cmdline modes, and it tries to create a new mode when no matching mode is found. - The drm_mode_create_from_cmdline_mode() creates a mode based on either CVT of GFT according to the given cmdline mode; in our case, it's 1366x768. - Since both CVT and GFT can't express the width 1366 due to alignment, the resultant mode becomes 1368x768, slightly larger than the given size. - Later on, the atomic commit is performed, and in drm_atomic_check_only(), the size of each plane is checked. - The size check of 1366x768 fails due to the above, and eventually the whole VT switch fails. Back in the history, we've had a manual fix-up of 1368x768 in various places via c09dedb7a50e ("drm/edid: Add a workaround for 1366x768 HD panel"), but they have been all in drm_edid.c at probing the modes from EDID. For addressing the problem above, we need a similar hack to the mode newly created from cmdline, manually adjusting the width when the expected size is 1366 while we get 1368 instead. Fixes: eaf99c749d43 ("drm: Perform cmdline mode parsing during...") Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: http://patchwork.freedesktop.org/patch/msgid/20170109145614.29454-1-tiwai@suse.de Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2016-11-15Revert "drm: Add aspect ratio parsing in DRM layer"Ville Syrjälä1-31/+0
This reverts commit 6dffd431e2296cda08e7e4f0242e02df1d1698cd. Adding new mode flags willy nilly breaks existing userspace. We need to coordinate this better, potentially with a new client cap that only exposes the aspect ratio flags when userspace is prepared for them (similar to what we do with stereo 3D modes). This also broke things so that we would always send out VIC==0 in the AVI infoframe unless the user specified an aspect ratio via the mode flags. And the automagic RGB full vs. limited range handling was similartly broken as the user mode would never match any CEA mode. Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Lin, Jia <lin.a.jia@intel.com> Cc: Akashdeep Sharma <akashdeep.sharma@intel.com> Cc: Jim Bride <jim.bride@linux.intel.com> Cc: Jose Abreu <Jose.Abreu@synopsys.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Emil Velikov <emil.l.velikov@gmail.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1478176304-6743-2-git-send-email-ville.syrjala@linux.intel.com
2016-11-15Revert "drm: Add and handle new aspect ratios in DRM layer"Ville Syrjälä1-12/+0
This reverts commit a68362fe3e84fcbedd49939aa200519aa5410135. Adding new mode flags willy nilly breaks existing userspace. We need to coordinate this better, potentially with a new client cap that only exposes the aspect ratio flags when userspace is prepared for them (similar to what we do with stereo 3D modes). Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Lin, Jia <lin.a.jia@intel.com> Cc: Akashdeep Sharma <akashdeep.sharma@intel.com> Cc: Jim Bride <jim.bride@linux.intel.com> Cc: Jose Abreu <Jose.Abreu@synopsys.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Emil Velikov <emil.l.velikov@gmail.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1478176304-6743-1-git-send-email-ville.syrjala@linux.intel.com
2016-11-08drm: helper macros to print composite typesRob Clark1-7/+1
I'll want to print things in a similar way in a later patch. This will make it easier. Signed-off-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/1478358492-30738-2-git-send-email-robdclark@gmail.com
2016-10-21drm: Use u64 for intermediate dotclock calculationsChris Wilson1-2/+6
We have reached the era where monitor bandwidths now exceed 31bits in frequency calculations, though as we stored them in kHz units we are safe from overflow in the modelines for some time. [ 48.723720] UBSAN: Undefined behaviour in ../drivers/gpu/drm/drm_modes.c:325:49 [ 48.726943] signed integer overflow: [ 48.728503] 2240 * 1000000 cannot be represented in type 'int' Reported-by: Martin Liška <marxin.liska@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98372 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20161021141540.26837-1-chris@chris-wilson.co.uk
2016-10-17drm: Add and handle new aspect ratios in DRM layerShashank Sharma1-0/+12
HDMI 2.0/CEA-861-F introduces two new aspect ratios: - 64:27 - 256:135 This patch: - Adds new DRM flags for to represent these new aspect ratios. - Adds new cases to handle these aspect ratios while converting from user->kernel mode or vise versa. V2: Rebase V3: Align macro for DRM_MODE_PICTURE_ASPECT_256_135 (Jim Bride) V4: Added r-b from Jose. Signed-off-by: Shashank Sharma <shashank.sharma@intel.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Reviewed-by: Jose Abreu <Jose.Abreu@synopsys.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1476705880-15600-5-git-send-email-shashank.sharma@intel.com
2016-10-17drm: Add aspect ratio parsing in DRM layerShashank Sharma1-0/+31
Current DRM layer functions don't parse aspect ratio information while converting a user mode->kernel mode or vice versa. This causes modeset to pick mode with wrong aspect ratio, eventually causing failures in HDMI compliance test cases, due to wrong VIC. This patch adds aspect ratio information in DRM's mode conversion and mode comparision functions, to make sure kernel picks mode with right aspect ratio (as per the VIC). V2: Addressed review comments from Sean: - Fix spellings/typo - No need to handle aspect ratio none - Add a break, for default case too V3: Rebase V4: Added r-b from Jose Signed-off-by: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Lin, Jia <lin.a.jia@intel.com> Signed-off-by: Akashdeep Sharma <akashdeep.sharma@intel.com> Reviewed-by: Jim Bride <jim.bride@linux.intel.com> Reviewed-by: Jose Abreu <Jose.Abreu@synopsys.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1476705880-15600-3-git-send-email-shashank.sharma@intel.com
generated by cgit v1.2.3 (git 2.39.1) at 2025-03-31 23:05:30 +0000