aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2016-07-14drm/tegra: sor: Use sor1_src clock to set parent for HDMIThierry Reding1-1/+16
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>
2016-07-14drm/tegra: sor: Implement sor1_brick clockThierry Reding1-0/+107
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>
2016-07-14drm/i915: Pull out some more common engine init codeTvrtko Ursulin4-29/+56
Created two common helpers for engine setup and engine init phases respectively to help with code sharing. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1468422221-12132-1-git-send-email-tvrtko.ursulin@linux.intel.com Reviewed-by: Chris Wilson <chris-wilson.co.uk>
2016-07-14drm/i915: Move common engine setup into intel_engine_cs.cTvrtko Ursulin5-140/+168
Common code deserves to be put in a separate file from legacy and execlists implementation for clarity and ease of maintenance. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris-wilson.co.uk>
2016-07-14drm/i915: Simplify intel_init_ring_buffer prototypeTvrtko Ursulin1-10/+8
Engine contains dev_priv so need to pass it in. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Chris Wilson <chris-wilson.co.uk>
2016-07-14drm/i915: Make more use of the shared engine irq setupTvrtko Ursulin1-15/+5
Use more of the shared engine setup data for legacy engine initialization. This time to simplify the irq initialization code. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris-wilson.co.uk>
2016-07-14drm/i915: Unify engine init loopTvrtko Ursulin6-105/+50
With the unified common engine setup done, and the execlist engine initialization loop clearly split into two phases, we can eliminate the separate legacy engine initialization code. v2: Fix cleanup path for legacy. v3: Rename constructors. (Chris Wilson) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Chris Wilson <chris-wilson.co.uk>
2016-07-14drm/i915: Prepare for engine init unificationTvrtko Ursulin1-49/+54
Move the execlist engine setup to vfuncs so that the engine init loop is clearly split into the mode agnostic and specific steps. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Chris Wilson <chris-wilson.co.uk>
2016-07-14drm/i915: unify first-stage engine struct setupDave Gordon3-44/+41
intel_lrc.c has a table of "logical rings" (meaning engines), while intel_ringbuffer.c has separately open-coded initialisation for each engine. We can deduplicate this somewhat by using the same first-stage engine-setup function for both modes. So here we expose the function that transfers information from the static table of (all) known engines to the dev_priv->engine array of engines available on this device (adjusting the names along the way) and then embed calls to it in both the LRC and the legacy-mode setup. Signed-off-by: Dave Gordon <david.s.gordon@intel.com> Reviewed-by: Chris Wilson <chris-wilson.co.uk> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
2016-07-14drm/imx: parallel-display: add bridge supportPhilipp Zabel1-9/+41
Add support for bridge chips connected externally to the i.MX DISP0/DISP1 DPI interfaces. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-07-14drm: Don't overwrite user ioctl arg unless requestedChris Wilson1-28/+22
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
2016-07-14Merge branch 'linux-4.8' of git://github.com/skeggsb/linux into drm-nextDave Airlie129-565/+3710
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 ...
2016-07-14drm/nouveau/bus: remove cpu_coherent flagAlexandre Courbot4-5/+1
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>
2016-07-14drm/nouveau/ttm: remove special handling of coherent objectsAlexandre Courbot1-56/+5
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>
2016-07-14drm/nouveau: check for supported chipset before booting fbdev off the hwBen Skeggs1-1/+10
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Cc: stable@vger.kernel.org
2016-07-14drm/nouveau/ce/gp104: initial supportBen Skeggs7-0/+54
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/fifo/gp104: initial supportBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/disp/gp104: initial supportBen Skeggs25-5/+394
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/dma/gp104: initial supportBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/ltc/gp104: initial supportBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/ibus/gp104: initial supportBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/i2c/gp104: initial supportBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/gpio/gp104: initial supportBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/fuse/gp104: initial supportBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/bus/gp104: initial supportBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/bar/gp104: initial supportBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/mmu/gp104: initial supportBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/fb/gp104: initial supportBen Skeggs6-1/+49
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/imem/gp104: initial supportBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/devinit/gp104: initial supportBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/bios/gp104: initial supportBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/tmr/gp104: initial supportBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/pci/gp104: initial supportBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/mc/gp104: initial supportBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/top/gp104: initial supportBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/core: recognise GP104 chipsetBen Skeggs1-0/+6
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/sw/gp100: initial supportBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/gr/gp100: initial supportBen Skeggs9-1/+362
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/ce/gp100: initial supportBen Skeggs6-0/+113
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/fifo/gp100: initial supportBen Skeggs9-1/+110
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/disp/gp100: initial supportBen Skeggs11-0/+162
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/dma/gp100: initial implementationBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/secboot/gm200: initial supportBen Skeggs2-0/+17
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/ltc/gp100: initial supportBen Skeggs6-1/+80
Due to the GPU preventing us from touching NV_PLTCG_LTCS_LTSS_CBC_BASE, we cannot provide CBC/ZBC support without signed PMU firmware to handle the task for us... Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/ibus/gp100: initial supportBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/i2c/gm204: initial supportBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/gpio/gp100: initial supportBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/fuse/gp100: initial supportBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/bus/gp100: initial supportBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/bar/gp100: initial supportBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.