- 19 Jul, 2016 9 commits
-
-
John Keeping authored
Because we are using a custom crtc_state structure, we must override the reset helper to allocate the correct amount of memory. Cc: stable@vger.kernel.org Fixes: 4e257d9e ("drm/rockchip: get rid of rockchip_drm_crtc_mode_config") Signed-off-by:
John Keeping <john@metanate.com> Signed-off-by:
Mark Yao <mark.yao@rock-chips.com> Reviewed-by:
Sean Paul <seanpaul@chromium.org>
-
Markus Elfring authored
The drm_gem_object_unreference_unlocked() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by:
Markus Elfring <elfring@users.sourceforge.net>
-
Dan Carpenter authored
The priv->crtc_funcs[] array has ROCKCHIP_MAX_CRTC elements so > should be >= here. Fixes: 2048e328 ('drm: rockchip: Add basic drm driver') Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Sean Paul <seanpaul@chromium.org>
-
Mark Yao authored
Signed-off-by:
Mark Yao <mark.yao@rock-chips.com> Reported-by:
Tomasz Figa <tfiga@chromium.org>
-
Mark Yao authored
When the input color format is YUV, we need to do some external scale for CBCR. Like, * In YUV420 data format: cbcr_xscale = dst_w / src_w * 2; cbcr_yscale = dst_h / src_h * 2; * In YUV422 data format: cbcr_xscale = dst_w / src_w * 2; cbcr_yscale = dst_h / src_h; * In YUV444 data format cbcr_xscale = dst_w / src_w; cbcr_yscale = dst_h / src_h; Signed-off-by:
Yakir Yang <ykk@rock-chips.com>
-
Yakir Yang authored
The WIN0 of RK3036 VOP could support YUV data format, but driver forget to add the uv_vir register field for it. Signed-off-by:
Yakir Yang <ykk@rock-chips.com>
-
John Keeping authored
Combined with the previous commit, this fixes all of the sparse warnings in drm/rockchip. Signed-off-by:
John Keeping <john@metanate.com>
-
John Keeping authored
This fixes the following sparse warnings: drivers/gpu/drm/rockchip/rockchip_drm_fb.c:32:23: warning: symbol 'rockchip_fb_get_gem_obj' was not declared. Should it be static? drivers/gpu/drm/rockchip/rockchip_drm_fb.c:315:24: warning: symbol 'rockchip_drm_framebuffer_init' was not declared. Should it be static? drivers/gpu/drm/rockchip/rockchip_drm_fb.c:329:6: warning: symbol 'rockchip_drm_mode_config_init' was not declared. Should it be static? Signed-off-by:
John Keeping <john@metanate.com>
-
John Keeping authored
drm_encoder_slave is not used in this file. Signed-off-by:
John Keeping <john@metanate.com>
-
- 16 Jul, 2016 5 commits
-
-
https://github.com/anholt/linuxDave Airlie authored
This pull request brings in vc4 shader validation for branching, allowing GLSL shaders with non-unrolled loops. * tag 'drm-vc4-next-2016-07-15' of https://github.com/anholt/linux: drm/vc4: Fix a "the the" typo in a comment. drm/vc4: Fix definition of QPU_R_MS_REV_FLAGS drm/vc4: Add a getparam to signal support for branches. drm/vc4: Add support for branching in shader validation. drm/vc4: Add a bitmap of branch targets during shader validation. drm/vc4: Move validation's current/max ip into the validation struct. drm/vc4: Add a getparam ioctl for getting the V3D identity regs.
-
git://anongit.freedesktop.org/tegra/linuxDave Airlie authored
drm/panel: Changes for v4.8-rc1 This set of changes contains a few cleanups for existing panels as well as improved handling of certain backlights. In addition there's support for a few new simple panels. * tag 'drm/panel/for-4.8-rc1' of git://anongit.freedesktop.org/tegra/linux: drm/panel: simple: Add support for Starry KR122EA0SRA panel dt-bindings: Add Starry KR122EA0SRA panel binding dt-bindings: Add vendor prefix for Starry dt-bindings: display: Add Sharp LQ101K1LY04 panel binding drm/panel: simple: Add support for Sharp LQ101K1LY04 drm/panel: simple: Add support for LG LP079QX1-SP0V panel dt-bindings: Add support for LG LP079QX1-SP0V panel drm/panel: simple: Add support for Sharp LQ123P1JX31 panel dt-bindings: Add Sharp LQ123P1JX31 panel binding drm/panel: simple: Add support for Samsung LSN122DL01-C01 panel dt-bindings: Add Samsung LSN122DL01-C01 panel binding drm/panel: simple: Add support for LG LP097QX1-SPA1 panel dt-bindings: Add LG LP097QX1-SPA1 panel binding drm/panel: simple: Update backlight state property drm/panel: simple: Remove gratuitous blank line drm/panel: simple: Fix a couple of physical sizes
-
git://anongit.freedesktop.org/tegra/linuxDave Airlie authored
drm/tegra: Changes for v4.8-rc1 This set of changes contains a bunch of cleanups to the host1x driver as well as the addition of a pin controller for DPAUX, which is required by boards to configure the DPAUX pads in AUX mode (for DisplayPort) or I2C mode (for HDMI and DDC). Included is also a bit of rework of the SOR driver in preparation to add DisplayPort support as well as some refactoring and cleanup. Finally, all output drivers are converted to runtime PM, which greatly simplifies the handling of clocks and resets. * tag 'drm/tegra/for-4.8-rc1' of git://anongit.freedesktop.org/tegra/linux: (35 commits) drm/tegra: sor: Reject HDMI 2.0 modes drm/tegra: sor: Prepare for generic PM domain support drm/tegra: dsi: Prepare for generic PM domain support drm/tegra: sor: Make XBAR configurable per SoC drm/tegra: sor: Use sor1_src clock to set parent for HDMI dt-bindings: display: tegra: Add source clock for SOR drm/tegra: sor: Implement sor1_brick clock drm/tegra: sor: Implement runtime PM drm/tegra: hdmi: Implement runtime PM drm/tegra: dsi: Implement runtime PM drm/tegra: dc: Implement runtime PM drm/tegra: hdmi: Enable audio over HDMI drm/tegra: sor: Do not support deep color modes drm/tegra: sor: Extract tegra_sor_mode_set() drm/tegra: sor: Split out tegra_sor_apply_config() drm/tegra: sor: Rename tegra_sor_calc_config() drm/tegra: sor: Factor out tegra_sor_set_parent_clock() drm/tegra: dpaux: Add pinctrl support dt-bindings: Add bindings for Tegra DPAUX pinctrl driver drm/tegra: Prepare DPAUX for supporting generic PM domains ...
-
git://github.com/yakir-Yang/linuxDave Airlie authored
Please consider merging this tag, which contains the v4 misc fixes and add RK3399 eDP support patches[0] I sent on 2016-06-29, rebased onto v4.7-rc5. * 'upstream/analogix-dp-20160705' of git://github.com/yakir-Yang/linux: dt-bindings: analogix_dp: rockchip: correct the wrong compatible name drm/rockchip: analogix_dp: introduce the pclk for grf drm/bridge: analogix_dp: fix no drm hpd event when panel plug in drm/rockchip: analogix_dp: update the comments about why need to hardcode VOP output mode drm/rockchip: analogix_dp: correct the connector display color format and bpc drm/bridge: analogix_dp: passing the connector as an argument in .get_modes() drm/rockchip: analogix_dp: make panel detect to an optional action drm/rockchip: analogix_dp: add rk3399 eDP support drm/bridge: analogix_dp: some rockchip chips need to flip REF_CLK bit setting drm/bridge: analogix_dp: correct the register bit define error in ANALOGIX_DP_PLL_REG_1 drm/rockchip: analogix_dp: split the lcdc select setting into device data
-
git://git.pengutronix.de/git/pza/linuxDave Airlie authored
imx-drm updates - atomic mode setting conversion - replace DMFC FIFO allocation mechanism with a fixed allocation that is good enough for all cases - support for external bridges connected to parallel-display - improved error handling in imx-ldb, imx-tve, and parallel-display - some code cleanup in imx-tve * tag 'imx-drm-next-2016-07-14' of git://git.pengutronix.de/git/pza/linux: drm/imx: parallel-display: add bridge support drm/imx: parallel-display: check return code from of_get_drm_display_mode() gpu: ipu-v3: ipu-dc: don't bug out on invalid bus_format drm/imx: imx-tve: fix the error message drm/imx: imx-tve: remove unneeded 'or' operation drm/imx: imx-tve: check the value returned by regulator_set_voltage() drm/imx: imx-ldb: check return code on panel attach drm/imx: turn remaining container_of macros into inline functions drm/imx: store internal bus configuration in crtc state drm/imx: remove empty mode_set encoder callbacks drm/imx: atomic phase 3 step 3: Advertise DRIVER_ATOMIC drm/imx: atomic phase 3 step 2: Legacy callback fixups drm/bridge: dw-hdmi: Remove the legacy drm_connector_funcs structure drm/imx: atomic phase 3 step 1: Use atomic configuration drm/imx: Remove encoders' ->prepare callbacks drm/imx: atomic phase 2 step 2: Track plane_state->fb correctly in ->page_flip drm/imx: atomic phase 2 step 1: Wire up state ->reset, ->duplicate and ->destroy drm/imx: atomic phase 1: Use transitional atomic CRTC and plane helpers gpu: ipu-v3: ipu-dmfc: Use static DMFC FIFO allocation mechanism drm/imx: ipuv3 plane: Check different types of plane separately
-
- 15 Jul, 2016 9 commits
-
-
Eric Anholt authored
Signed-off-by:
Eric Anholt <eric@anholt.net>
-
Eric Anholt authored
We don't use it in shader validation currently, so it had no effect, but best to fix it anyway in case we do some day. Signed-off-by:
Eric Anholt <eric@anholt.net>
-
Eric Anholt authored
Userspace needs to know if it can create shaders that do branching. Otherwise, for backwards compatibility with old kernels it needs to lower if statements to conditional assignments. Signed-off-by:
Eric Anholt <eric@anholt.net>
-
Eric Anholt authored
We're already checking that branch instructions are between the start of the shader and the proper PROG_END sequence. The other thing we need to make branching safe is to verify that the shader doesn't read past the end of the uniforms stream. To do that, we require that at any basic block reading uniforms have the following instructions: load_imm temp, <next offset within uniform stream> add unif_addr, temp, unif The instructions are generated by userspace, and the kernel verifies that the load_imm is of the expected offset, and that the add adds it to a uniform. We track which uniform in the stream that is, and at draw call time fix up the uniform stream to have the address of the start of the shader's uniforms at that location. Signed-off-by:
Eric Anholt <eric@anholt.net>
-
Eric Anholt authored
This isn't used yet, it's just a first step toward loop validation. During the main parsing of instructions, we need to know when we hit a new basic block so that we can reset validated state. v2: Fix a stray semicolon after an if block. (caught by kbuild test). Signed-off-by:
Eric Anholt <eric@anholt.net>
-
Dave Airlie authored
Merge branch 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next This pull request adds to the rework patch series for IOMMU integration to support ARM64bit architecture with DMA-IOMMU glue code. With this patch series, Exynos DRM works well on Exynos5433 SoC with IOMMU enabled. * 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos: drm/exynos: iommu: add support for ARM64 specific code for IOMMU glue drm/exynos: iommu: move ARM specific code to exynos_drm_iommu.h drm/exynos: iommu: remove unused entries from exynos_drm_private strcuture drm/exynos: iommu: add a check if all sub-devices have iommu controller drm/exynos: iommu: move dma_params configuration code to separate functions
-
https://github.com/anholt/linuxDave Airlie authored
This pull request brings in new vc4 plane formats for Android, precise vblank timestamping, and a couple of small cleanups. * tag 'drm-vc4-next-2016-07-12' of https://github.com/anholt/linux: drm/vc4: remove redundant ret status check drm/vc4: Implement precise vblank timestamping. drm/vc4: Bind the HVS before we bind the individual CRTCs. gpu: drm: vc4_hdmi: add missing of_node_put after calling of_parse_phandle drm: vc4: enable XBGR8888 and ABGR8888 pixel formats drm/vc4: clean up error exit path on failed dpi_connector allocation
-
git://anongit.freedesktop.org/drm-intelDave Airlie authored
- select igt testing depencies for CONFIG_DRM_I915_DEBUG (Chris) - track outputs in crtc state and clean up all our ad-hoc connector/encoder walking in modest code (Ville) - demidlayer drm_device/drm_i915_private (Chris Wilson) - thundering herd fix from Chris Wilson, with lots of help from Tvrtko Ursulin - piles of assorted clean and fallout from the thundering herd fix - documentation and more tuning for waitboosting (Chris) - pooled EU support on bxt (Arun Siluvery) - bxt support is no longer considered prelimary! - ring/engine vfunc cleanup from Tvrtko - introduce intel_wait_for_register helper (Chris) - opregion updates (Jani Nukla) - tuning and fixes for wait_for macros (Tvrkto&Imre) - more kabylake pci ids (Rodrigo) - pps cleanup and fixes for bxt (Imre) - move sink crc support over to atomic state (Maarten) - fix up async fbdev init ordering (Chris) - fbc fixes from Paulo and Chris * tag 'drm-intel-next-2016-07-11' of git://anongit.freedesktop.org/drm-intel: (223 commits) drm/i915: Update DRIVER_DATE to 20160711 drm/i915: Select DRM_VGEM for igt drm/i915: Select X86_MSR for igt drm/i915: Fill unused GGTT with scratch pages for VT-d drm/i915: Introduce Kabypoint PCH for Kabylake H/DT. drm/i915:gen9: implement WaMediaPoolStateCmdInWABB drm/i915: Check for invalid cloning earlier during modeset drm/i915: Simplify hdmi_12bpc_possible() drm/i915: Kill has_dsi_encoder drm/i915: s/INTEL_OUTPUT_DISPLAYPORT/INTEL_OUTPUT_DP/ drm/i915: Replace some open coded intel_crtc_has_dp_encoder()s drm/i915: Kill has_dp_encoder from pipe_config drm/i915: Replace manual lvds and sdvo/hdmi counting with intel_crtc_has_type() drm/i915: Unify intel_pipe_has_type() and intel_pipe_will_have_type() drm/i915: Add output_types bitmask into the crtc state drm/i915: Remove encoder type checks from MST suspend/resume drm/i915: Don't mark eDP encoders as MST capable drm/i915: avoid wait_for_atomic() in non-atomic host2guc_action() drm/i915: Group the irq breadcrumb variables into the same cacheline drm/i915: Wake up the bottom-half if we steal their interrupt ...
-
git://anongit.freedesktop.org/drm-intelDave Airlie authored
I recovered dri-devel backlog from my vacation, more misc stuff: - of_put_node fixes from Peter Chen (not all yet) - more patches from Gustavo to use kms-native drm_crtc_vblank_* funcs - docs sphinxification from Lukas Wunner - bunch of fixes all over from Dan Carpenter - more follow up work from Chris register/unregister rework in various places - vgem dma-buf export (for writing testcases) - small things all over from tons of different people * tag 'topic/drm-misc-2016-07-14' of git://anongit.freedesktop.org/drm-intel: (52 commits) drm: Don't overwrite user ioctl arg unless requested dma-buf/sync_file: improve Kconfig description for Sync Files MAINTAINERS: add entry for the Sync File Framework drm: Resurrect atomic rmfb code drm/vgem: Use PAGE_KERNEL in place of x86-specific PAGE_KERNEL_IO qxl: silence uninitialized variable warning qxl: check for kmap failures vga_switcheroo: Sphinxify docs drm: Restore double clflush on the last partial cacheline gpu: drm: rockchip_drm_drv: add missing of_node_put after calling of_parse_phandle gpu: drm: sti_vtg: add missing of_node_put after calling of_parse_phandle gpu: drm: sti_hqvdp: add missing of_node_put after calling of_parse_phandle gpu: drm: sti_vdo: add missing of_node_put after calling of_parse_phandle gpu: drm: sti_compositor: add missing of_node_put after calling of_parse_phandle drm/tilcdc: use drm_crtc_handle_vblank() drm/rcar-du: use drm_crtc_handle_vblank() drm/nouveau: use drm_crtc_handle_vblank() drm/atmel: use drm_crtc_handle_vblank() drm/armada: use drm_crtc_handle_vblank() drm: make drm_vblank_count_and_time() static ...
-
- 14 Jul, 2016 17 commits
-
-
Eric Anholt authored
Reduces the argument count for some of the functions, and will be used more with the upcoming looping support. Signed-off-by:
Eric Anholt <eric@anholt.net>
-
Eric Anholt authored
As I extend the driver to support different V3D revisions, userspace needs to know what version it's targeting. This is most easily detected using the V3D identity registers. v2: Make sure V3D is runtime PM on when reading the registers. v3: Switch to a 64-bit param value (suggested by Rob Clark in review) Signed-off-by:
Eric Anholt <eric@anholt.net> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> (v2) Reviewed-by: Rob Clark <robdclark@gmail.com> (v3, over irc)
-
Thierry Reding authored
Enabling HDMI 2.0 modes requires extra programming and will not work with the current driver, so reject all those modes. Signed-off-by:
Thierry Reding <treding@nvidia.com>
-
Jon Hunter authored
The SOR driver for Tegra requires the SOR power partition to be enabled. Now that Tegra supports the generic PM domain framework we manage the SOR power partition via this framework. However, the sequence for gating/ungating the SOR power partition requires that the SOR reset is asserted/de-asserted at the time the SOR power partition is gated/ungated, respectively. Now that the reset control core assumes that resets are exclusive, the Tegra generic PM domain code and the SOR driver cannot request the same reset unless we mark the reset as shared. Sharing resets will not work in this case because we cannot guarantee that the reset will be asserted/de-asserted at the appropriate time. Therefore, given that the Tegra generic PM domain code will handle the resets, do not request the reset in the SOR driver if the SOR device has a PM domain associated. Signed-off-by:
Jon Hunter <jonathanh@nvidia.com> Signed-off-by:
Thierry Reding <treding@nvidia.com>
-
Jon Hunter authored
The DSI driver for Tegra requires the SOR power partition to be enabled. Now that Tegra supports the generic PM domain framework we manage the SOR power partition via this framework. However, the sequence for gating/ungating the SOR power partition requires that the DSI reset is asserted/de-asserted at the time the SOR power partition is gated/ungated, respectively. Now that the reset control core assumes that resets are exclusive, the Tegra generic PM domain code and the DSI driver cannot request the same reset unless we mark the reset as shared. Sharing resets will not work in this case because we cannot guarantee that the reset will be asserted/de-asserted at the appropriate time. Therefore, given that the Tegra generic PM domain code will handle the resets, do not request the reset in the DSI driver if the DSI device has a PM domain associated. Signed-off-by:
Jon Hunter <jonathanh@nvidia.com> Signed-off-by:
Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
Provide a per-SoC mapping of lanes which can be used to configure the XBAR. Signed-off-by:
Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
When running in HDMI mode, the sor1 IP block needs to use the sor1_src as parent clock, and in turn configure the sor1_src to use pll_d2_out0 as its parent. Signed-off-by:
Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
The SOR clock can have various sources, with the most commonly used being the sor_safe, pll_d2_out0, pll_dp and sor_brick clocks. These are configured using a three level mux, of which the first 2 levels can be treated as one. The direct parents of the SOR clock are the sor_safe, sor_brick and sor_src clocks, whereas the pll_d2_out0 and pll_dp clocks can be selected as parents of the sor_src clock via a second mux. Previous generations of Tegra have only supported eDP and LVDS with the SOR, where LVDS was never used on publicly available hardware. Clocking for this only ever required the first level mux (to select between sor_safe and sor_brick). Tegra210 has a new revision of the SOR that supports HDMI and hence needs to support the second level mux to allow selecting pll_d2_out0 as the SOR clock's parent. This second mux is knows as sor_src, and operating system software needs a reference to it in order to select the proper parent. Signed-off-by:
Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
sor1_brick is a clock that can be used as a source for the sor1 clock. The registers to control the clock output are part of the sor1 IP block and hence the sor driver is the best place to implement it. Signed-off-by:
Thierry Reding <treding@nvidia.com>
-
Philipp Zabel authored
Add support for bridge chips connected externally to the i.MX DISP0/DISP1 DPI interfaces. Signed-off-by:
Philipp Zabel <p.zabel@pengutronix.de>
-
Chris Wilson authored
Currently, we completely ignore the user when it comes to the in/out direction of the ioctl argument, as we simply cannot trust userspace. (For example, they might request a copy of the modified ioctl argument when the driver is not expecting such and so leak kernel stack.) However, blindly copying over the target address may also lead to a spurious EFAULT, and a failure after the ioctl was completed successfully. This is important in order to avoid an ABI break when extending an ioctl from IOR to IORW. Similar to how we only copy the intersection of the kernel arg size and the user arg size, we only want to copy back the kernel arg data iff both the kernel and userspace request the copy. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1468335590-21023-1-git-send-email-chris@chris-wilson.co.uk
-
git://github.com/skeggsb/linuxDave Airlie authored
Here's an initial drm-next pull for nouveau 4.8, highlights: - GK20A/GM20B volt and clock improvements. - Initial support for GP100/GP104 GPUs, GP104 will not yet support acceleration due to NVIDIA having not released firmware for them as of yet. * 'linux-4.8' of git://github.com/skeggsb/linux: (97 commits) drm/nouveau/bus: remove cpu_coherent flag drm/nouveau/ttm: remove special handling of coherent objects drm/nouveau: check for supported chipset before booting fbdev off the hw drm/nouveau/ce/gp104: initial support drm/nouveau/fifo/gp104: initial support drm/nouveau/disp/gp104: initial support drm/nouveau/dma/gp104: initial support drm/nouveau/ltc/gp104: initial support drm/nouveau/ibus/gp104: initial support drm/nouveau/i2c/gp104: initial support drm/nouveau/gpio/gp104: initial support drm/nouveau/fuse/gp104: initial support drm/nouveau/bus/gp104: initial support drm/nouveau/bar/gp104: initial support drm/nouveau/mmu/gp104: initial support drm/nouveau/fb/gp104: initial support drm/nouveau/imem/gp104: initial support drm/nouveau/devinit/gp104: initial support drm/nouveau/bios/gp104: initial support drm/nouveau/tmr/gp104: initial support ...
-
Alexandre Courbot authored
This flag's only remaining function is to ignore the uncached flag for BOs on coherent architectures. However the reason for allocating an object uncache on a non-coherent architecture (namely because the cost of doing explicit flushes/ invalidations is higher than the benefit of caching the data because accesses are few and far between) should also apply on architectures for which coherency is maintained implicitly. Thus allocate coherent objects as uncached on all architectures. Signed-off-by:
Alexandre Courbot <acourbot@nvidia.com> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Alexandre Courbot authored
TTM-allocated coherent objects were populated using the DMA API and accessed using the mapping it returned to workaround coherency issues. These issues seem to have been solved, thus remove this extra case to handle and use the regular kernel mapping functions. Signed-off-by:
Alexandre Courbot <acourbot@nvidia.com> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Cc: stable@vger.kernel.org
-
Ben Skeggs authored
Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-