- 02 Mar, 2018 14 commits
-
-
Ville Syrjälä authored
Bring us forward from the stone age and switch our default YCbCr->RGB conversion matrix to BT.709 from BT.601. I would expect most matrial to be BT.709 these days. Cc: Harry Wentland <harry.wentland@amd.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Daniel Stone <daniel@fooishbar.org> Cc: Russell King - ARM Linux <linux@armlinux.org.uk> Cc: Ilia Mirkin <imirkin@alum.mit.edu> Cc: Hans Verkuil <hverkuil@xs4all.nl> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Jyri Sarha <jsarha@ti.com> Acked-by:
Shashank Sharma <shashank.sharma@intel.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180214192327.3250-8-ville.syrjala@linux.intel.com
-
Ville Syrjälä authored
Add support for the COLOR_ENCODING plane property which selects the matrix coefficients used for the YCbCr->RGB conversion. Our hardware can generally handle BT.601 and BT.709. CHV pipe B sprites have a fully programmable matrix, so in theory we could handle anything, but it doesn't seem all that useful to expose anything beyond BT.601 and BT.709 at this time. GLK can supposedly do BT.2020, but let's leave enabling that for the future as well. v2: Rename bit defines to match the spec more closely (Shashank) Cc: Harry Wentland <harry.wentland@amd.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Daniel Stone <daniel@fooishbar.org> Cc: Russell King - ARM Linux <linux@armlinux.org.uk> Cc: Ilia Mirkin <imirkin@alum.mit.edu> Cc: Hans Verkuil <hverkuil@xs4all.nl> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Jyri Sarha <jsarha@ti.com> Reviewed-by:
-
Ville Syrjälä authored
On GLK the plane CSC controls moved into the COLOR_CTL register. Update the code to progam the YCbCr->RGB CSC mode correctly when faced with an YCbCr framebuffer. The spec is rather confusing as it calls the mode "YUV601 to RGB709". I'm going to assume that just means it's going to use the YCbCr->RGB matrix as specified in BT.601 and doesn't actually change the gamut. Cc: Harry Wentland <harry.wentland@amd.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Daniel Stone <daniel@fooishbar.org> Cc: Russell King - ARM Linux <linux@armlinux.org.uk> Cc: Ilia Mirkin <imirkin@alum.mit.edu> Cc: Hans Verkuil <hverkuil@xs4all.nl> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com>
-
Ville Syrjälä authored
Turns out the VLV/CHV fixed function sprite CSC expects full range data as input. We've been feeding it limited range data to it all along. To expand the data out to full range we'll use the color correction registers (brightness, contrast, and saturation). On CHV pipe B we were actually doing the right thing already because we progammed the custom CSC matrix to do expect limited range input. Now that well pre-expand the data out with the color correction unit, we need to change the CSC matrix to operate with full range input instead. This should make the sprite output of the other pipes match the sprite output of pipe B reasonably well. Looking at the resulting pipe CRCs, there can be a slight difference in the output, but as I don't know the formula used by the fixed function CSC of the other pipes, I don't think it's worth the effort to try to match the output exactly. It might not even be possible due to difference in internal precision etc. One slight caveat here is that the color correction registers are single bufferred, so we should really be updating them during vblank, but we still don't have a mechanism for that, so just toss in another FIXME. v2: Rebase v3: s/bri/brightness/ s/con/contrast/ (Shashank) v4: Clarify the constants and math (Shashank) Cc: Harry Wentland <harry.wentland@amd.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Daniel Stone <daniel@fooishbar.org> Cc: Russell King - ARM Linux <linux@armlinux.org.uk> Cc: Ilia Mirkin <imirkin@alum.mit.edu> Cc: Hans Verkuil <hverkuil@xs4all.nl> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Jyri Sarha <jsarha@ti.com> Cc: "Tang, Jun" <jun.tang@intel.com> Reported-by:
"Tang, Jun" <jun.tang@intel.com> Cc: stable@vger.kernel.org Fixes: 7f1f3851 ("drm/i915: sprite support for ValleyView v4") Reviewed-by:
-
Ville Syrjälä authored
Include color_enconding and color_range in the plane state dump. v2: Add kerneldoc (danvet) Cc: Harry Wentland <harry.wentland@amd.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Daniel Stone <daniel@fooishbar.org> Cc: Russell King - ARM Linux <linux@armlinux.org.uk> Cc: Ilia Mirkin <imirkin@alum.mit.edu> Cc: Hans Verkuil <hverkuil@xs4all.nl> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Jyri Sarha <jsarha@ti.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by:
Harry Wentland <harry.wentland@amd.com>
-
Jyri Sarha authored
Add a standard optional properties to support different non RGB color encodings in DRM planes. COLOR_ENCODING select the supported non RGB color encoding, for instance ITU-R BT.709 YCbCr. COLOR_RANGE selects the value ranges within the selected color encoding. The properties are stored to drm_plane object to allow different set of supported encoding for different planes on the device. v2: Add/fix kerneldocs, verify bitmasks (danvet) Cc: Harry Wentland <harry.wentland@amd.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Daniel Stone <daniel@fooishbar.org> Cc: Russell King - ARM Linux <linux@armlinux.org.uk> Cc: Ilia Mirkin <imirkin@alum.mit.edu> Cc: Hans Verkuil <hverkuil@xs4all.nl> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Reviewed-by:
Jyri Sarha <jsarha@ti.com> [vsyrjala v2: Add/fix kerneldocs, verify bitmasks] Signed-off-by:
-
Jernej Skrabec authored
64-bit ARM SoCs from Allwinner have DE2/TCON/HDMI periphery which is compatible to 32-bit SoCs, so allow building DRM driver for arm64 architecture. Signed-off-by:
Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by:
Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180301213442.16677-14-jernej.skrabec@siol.net
-
Jernej Skrabec authored
While A83T HDMI PHY seems to be just customized Synopsys HDMI PHY, H3 HDMI PHY is completely custom PHY. However, they still have many things in common like clock and reset setup, setting sync polarity and more. Add support for H3 HDMI PHY variant. While documentation exists for this PHY variant, it doesn't go in great details. Because of that, almost all settings are copied from BSP linux 4.4. Interestingly, those settings are slightly different to those found in a older BSP with Linux 3.4. For now, no user visible difference was found between them. Signed-off-by:
-
Jernej Skrabec authored
DW HDMI PHY macros are moved to header file and expanded with the registers present on newer SoCs like H3 and H5. Signed-off-by:
-
Jernej Skrabec authored
There are multiple variants of DW HDMI PHYs in Allwinner SoCs. While some things like clock and reset setup are the same, PHY configuration differs a lot. Split out code which is PHY specific to separate functions and create a structure which holds pointers to those functions. Signed-off-by:
-
Jernej Skrabec authored
Current polarity configuration code is cleary wrong since it compares same flag two times. However, even if flag name is fixed, it won't work well for resolutions which have one polarity positive and another negative. Fix that by properly set each bit according to each polarity. Since those two bits are not described in any documentation, relationships were obtained by experimentation. Fixes: b7c7436a ("drm/sun4i: Implement A83T HDMI driver") Signed-off-by:
-
Jernej Skrabec authored
This mixer supports 1 VI plane, 3 UI plane and HW scaling on all planes. Signed-off-by:
-
Jernej Skrabec authored
H3 display engine has two mixers which are connected to HDMI and TV output. Signed-off-by:
-
Jernej Skrabec authored
Add missing compatibles for H3 HDMI pipeline. These compatibles can also be used with H5 SoC. Signed-off-by:
-
- 01 Mar, 2018 6 commits
-
-
Jeffy Chen authored
In bind the psr handler gets registered first before the core analogix_dp_bind() gets called. So it should be the other way around in unbind, first unbind the analogix_dp and then unregister the psr. Signed-off-by:
Jeffy Chen <jeffy.chen@rock-chips.com> Signed-off-by:
Thierry Escande <thierry.escande@collabora.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/76025075.yWNtk1v57f@phil
-
Jeffy Chen authored
The rockchip_drm_psr_register() can fail, so add a sanity check for that. Signed-off-by:
-
Jeffy Chen authored
Since we are initing connector in the core driver and encoder in the plat driver, let's clean them up in the right places. Signed-off-by:
Andrzej Hajda <a.hajda@samsung.com> Signed-off-by:
-
Jeffy Chen authored
The driver that instantiates the bridge should own the drvdata, as all driver model callbacks (probe, remove, shutdown, PM ops, etc.) are also owned by its driver struct. Moreover, storing two different pointer types in driver data depending on driver initialization status is barely a good practice and in fact has led to many bugs in this driver. Let's clean up this mess and change Analogix entry points to simply accept some opaque struct pointer, adjusting their users at the same time to avoid breaking the compilation. Signed-off-by:
Tomasz Figa <tfiga@chromium.org> Signed-off-by:
Sean Paul <seanpaul@chromium.org> Acked-by:
Jingoo Han <jingoohan1@gmail.com> Acked-by:
Archit Taneja <architt@codeaurora.org> Signed-off-by:
-
Jeffy Chen authored
Currently we are calling scl_vop_cal_scale() to get vskiplines for yrgb and cbcr. So the cbcr's vskiplines might be an unexpected value if the second scl_vop_cal_scale() didn't update it. Init vskiplines in scl_vop_cal_scale() to avoid that. Signed-off-by:
-
Jeffy Chen authored
Since we are trying to access components' resources in the master's suspend/resume PM callbacks(e.g. panel), add device links to correct the suspend/resume and shutdown ordering. Signed-off-by:
Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by:
-
- 28 Feb, 2018 2 commits
-
-
Arnd Bergmann authored
Calling devm_of_find_backlight directly means we get a link failure without CONFIG_BACKLIGHT_CLASS_DEVICE: drivers/gpu/drm/tinydrm/mi0283qt.o: In function `mi0283qt_probe': mi0283qt.c:(.text+0x684): undefined reference to `devm_of_find_backlight' This adds an explicit Kconfig dependency for it. While I did not observe that failure for st7735r, I assume the same change is needed there for the same reason. Fixes: d1a2e700 ("drm/tinydrm: Replace tinydrm_of_find_backlight with of_find_backlight") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Ville Syrjälä authored
The documentation for the ctm matrix suggests a two's complement format, but at least the i915 implementation is using sign-magnitude instead. And looks like malidp is doing the same. Change the docs to match the current implementation, and change the type from __s64 to __u64 to drive the point home. Cc: dri-devel@lists.freedesktop.org Cc: Mihail Atanassov <mihail.atanassov@arm.com> Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Brian Starkey <brian.starkey@arm.com> Cc: Mali DP Maintainers <malidp@foss.arm.com> Cc: Johnson Lin <johnson.lin@intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by:
-
- 27 Feb, 2018 7 commits
-
-
Rodrigo Siqueira authored
This patch fixes the checkpatch.pl check: virtgpu_ioctl.c:535: CHECK: spaces preferred around that '|' (ctx:VxV) virtgpu_vq.c:277: CHECK: spaces preferred around that '+' (ctx:VxV) ... Signed-off-by:
Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Reviewed-by:
Gurchetan Singh <gurchetansingh@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/8402b55696b44483ba2e1f6aaeb53bf709ffbfe7.1519343668.git.rodrigosiqueiramelo@gmail.comSigned-off-by:
Gerd Hoffmann <kraxel@redhat.com>
-
Rodrigo Siqueira authored
This patch fixes the checkpatch.pl check: virtgpu_drv.c:116: CHECK: Please don't use multiple blank lines virtgpu_vq.c:599: CHECK: Please don't use multiple blank lines virtgpu_prime.c:42: CHECK: Please don't use multiple blank lines Signed-off-by:
-
Rodrigo Siqueira authored
This patch fixes the checkpatch.pl warning: drivers/gpu/drm/virtio/virtgpu_display.c:64: WARNING: Prefer 'unsigned int' to bare use of 'unsigned' ... Signed-off-by:
-
Rodrigo Siqueira authored
This patch fixes the checkpatch.pl warning: virtgpu_ttm.c:181: WARNING: void function return statements are not generally useful ... Signed-off-by:
-
Rodrigo Siqueira authored
This patch fixes the checkpatch.pl warning: virtgpu_ioctl.c:551: WARNING: Block comments use a trailing */ on a separate line ... Signed-off-by:
-
Rodrigo Siqueira authored
This patch fixes the checkpatch.pl warnings: virtgpu_drv.c:57: WARNING: Missing a blank line after declarations virtgpu_display.c:99: WARNING: Missing a blank line after declarations ... Signed-off-by:
-
Rodrigo Siqueira authored
This patch fixes the checkpatch.pl errors: drivers/gpu/drm/virtio/virtgpu_drv.h:371: ERROR: code indent should use tabs where possible ... Signed-off-by:
-
- 26 Feb, 2018 4 commits
-
-
Ville Syrjälä authored
sparse complains: drivers/gpu/drm/drm_panel_orientation_quirks.c:133:5: warning: symbol 'drm_get_panel_orientation_quirk' was not declared. Should it be static? Cc: Hans de Goede <hdegoede@redhat.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Hans de Goede <hdegoede@redhat.com>
-
Ville Syrjälä authored
The core now checks that the plane supports the fb's format+modifier combination, so we can drop the related checks from skl_check_ccs_aux_surface(). These checks were specific to SKL/KBL/BXT anyway. Cc: Ben Widawsky <ben@bwidawsk.net> Cc: Jason Ekstrand <jason@jlekstrand.net> Cc: Daniel Stone <daniels@collabora.com> Signed-off-by:
Mika Kahola <mika.kahola@intel.com>
-
Ville Syrjälä authored
Currently we only check that the plane supports the pixel format of the fb we're about to feed to it. Extend it to check also the modifier, and more specifically that the combination of the format and modifier is supported. Cc: dri-devel@lists.freedesktop.org Cc: Ben Widawsky <ben@bwidawsk.net> Cc: Jason Ekstrand <jason@jlekstrand.net> Cc: Daniel Stone <daniels@collabora.com> Signed-off-by:
-
Thierry Reding authored
DRM_DUMB_VGA_DAC is a user-visible symbol. Selecting it can cause unmet direct dependencies such as this (on i386, randconfig): warning: (DRM_PL111) selects DRM_DUMB_VGA_DAC which has unmet direct dependencies (HAS_IOMEM && DRM && DRM_BRIDGE && OF) This is because DRM_DUMB_VGA_DAC depends on OF while DRM_PL111 does not. It does indirectly depend on OF via the ARM and ARM64 dependencies, but since it can also be enabled under COMPILE_TEST, randconfig can find a case where DRM_PL111 is selected without pulling in OF and not meeting the dependency for DRM_DUMB_VGA_DAC. Since select is "heavy handed", DRM_DUMB_VGA_DAC is going to be enabled regardless of the above warning and causes the following build error: ../drivers/gpu/drm/bridge/dumb-vga-dac.c: In function 'dumb_vga_probe': ../drivers/gpu/drm/bridge/dumb-vga-dac.c:207:13: error: 'struct drm_bridge' has no member named 'of_node' vga->bridge.of_node = pdev->dev.of_node; See Documentation/kbuild/kconfig-language.txt, "reverse dependencies". Fixes: 49f81d80 ("drm/pl111: Support handling bridge timings") Reported-by:
Randy Dunlap <rdunlap@infradead.org> Reviewed-by:
Eric Anholt <eric@anholt.net> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Archit Taneja <architt@codeaurora.org> Cc: Eric Anholt <eric@anholt.net> Signed-off-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
Archit Taneja <archit@cradlewise.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180220102903.27787-1-thierry.reding@gmail.com
-
- 23 Feb, 2018 1 commit
-
-
Benjamin Gaignard authored
In all cases we have to check pitch and size calculations to speed up data transfer. Fixes: 21f815bf ("drm/stm: drv: Improve data transfers") Signed-off-by:
Benjamin Gaignard <benjamin.gaignard@linaro.org> Tested-by:
Philippe Cornu <philippe.cornu@st.com> Reviewed-by:
-
- 22 Feb, 2018 6 commits
-
-
Linus Walleij authored
These clocks are in kHz not in Hz, oops. Fix it so my new bandwidth calculations patch starts working with these panels. Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20180211103840.18764-1-linus.walleij@linaro.org
-
Oleksandr Andrushchenko authored
Do not use deprecated drm_driver.{enable|disable)_vblank callbacks, but use drm_simple_kms_helpe's pipe callbacks instead. Signed-off-by:Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Cc: Eric Anholt <eric@anholt.net> Reviewed-by:
-
Oleksandr Andrushchenko authored
Do not use deprecated drm_driver.{enable|disable)_vblank callbacks, but use drm_simple_kms_helpe's pipe callbacks instead. Signed-off-by: -
Oleksandr Andrushchenko authored
Do not use deprecated drm_driver.{enable|disable)_vblank callbacks, but use drm_simple_kms_helpe's pipe callbacks instead. Signed-off-by:Marek Vasut <marex@denx.de> Signed-off-by:
-
Oleksandr Andrushchenko authored
If simple_kms_helper based driver needs to work with vblanks, then it has to provide drm_driver.{enable|disable}_vblank callbacks, because drm_simple_kms_helper.drm_crtc_funcs does not provide any. At the same time drm_driver.{enable|disable}_vblank callbacks are marked as deprecated and shouldn't be used by new drivers. Fix this by extending drm_simple_kms_helper.drm_crtc_funcs to provide the missing callbacks. Signed-off-by: -
Arnd Bergmann authored
When comparing two variables with min()/max(), they should be the same type: drivers/gpu/drm/drm_memory.c: In function 'drm_get_max_iomem': include/linux/kernel.h:821:16: error: comparison of distinct pointer types lacks a cast [-Werror] (void) (&max1 == &max2); This makes the local variable in drm_get_max_iomem make the type from resource->end. Fixes: 82626363 ("drm: add func to get max iomem address v2") Signed-off-by:
-
