- 11 Jan, 2016 29 commits
-
-
Ben Skeggs authored
From DCB 4.1 spec. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Differences from GM10x: - GM20x LTC count detection differs from GM10x - GM20x init doesn't require large page size setting Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
resman and nvgpu both do this, presumably for good reason. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
GM20x doesn't require the priv ring timeout bumps that GK/GM10x have. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Should be no functional change here. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Alexandre Courbot authored
Commit 69c49382 ("drm/nouveau/instmem/gk20a: use direct CPU access") tried to be smart while using the DMA-API by managing the CPU mappings of buffers allocated with the DMA-API by itself. In doing so, it relied on dma_to_phys() which is an architecture-private function not available everywhere. This broke the build on several architectures. Since there is no reliable and portable way to obtain the physical address of a DMA-API buffer, stop trying to be smart and just use the CPU mapping that the DMA-API can provide. This means that buffers will be CPU-mapped for all their life as opposed to when we need them, but anyway using the DMA-API here is a fallback for when no IOMMU is available so we should not expect optimal behavior. This makes the IOMMU and DMA-API implementations of instmem diverge enough that we should maybe put them into separate files... Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Alexandre Courbot authored
The LRU list used for recycling CPU mappings was handling concurrency very poorly. For instance, if an instobj was acquired twice before being released once, it would end up into the LRU list even though there is still a client accessing it. This patch fixes this by properly counting how many clients are currently using a given instobj. While at it, we also raise errors when inconsistencies are detected, and factorize some code. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Nicolas Chauvet authored
This patch is needed by initramfs tools to detect the required firmware files for the module. This patch tests for either TEGRA_124_SOC or TEGRA_132_SOC for the firmwares related to the Tegra K1 generation. v2: move the MODULE_FIRMWARE to the nvidia_platform.c file. This will avoid to test for NOUVEAU_PLATFORM_DRIVER Signed-off-by: Nicolas Chauvet <kwizart@gmail.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Vince Hsu authored
The offset should be 8 on Kepler and later. Signed-off-by: Vince Hsu <vinceh@nvidia.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Very rough, no idea how correct it is at this point, but it prevents getteximage-depth from piglit from hanging the GPU. v2: updated with NV_PCE_FE_LAUNCHERR_REPORT values provided by NVIDIA Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Similar in spirit to the gk104 fix with a similar title. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
The CPU-side tracking of engine runlists was not protected by a lock, leading to list corruption, eventually causing runlist_update() to overrun the GPU-side runlist, triggering an OOPS. Fixes some of the issues noticed during parallel piglit runs. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ilia Mirkin authored
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ilia Mirkin authored
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Alexandre Courbot authored
We want to unlock nv_devices_mutex in this error path as well. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ilia Mirkin authored
Some Fermi's apparently alow allow 297MHz clocks, so create a parameter which allows end-users to set it themselves until we have a reliable way to determine the board's maximum pixel clocks. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Hauke Mehrtens authored
Without this patch a pixel clock rate above 165 MHz on a TMDS link is assumed to be dual link. This is true for DVI, but not for HDMI. HDMI supports no dual link, but it supports pixel clock rates above 165 MHz. Only activate Dual Link mode when it is actually possible and requested. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> [imirkin: check for hdmi monitor for computing proto, use sor ctrl to enable extra config bit] Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
- 31 Dec, 2015 11 commits
-
-
Dave Airlie authored
Merge tag 'omapdrm-4.5-resolved' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux into drm-next omapdrm changes for v4.5 * enable DRIVER_ATOMIC * improved TILER performance * cleanups preparing for DMAbuf import * fbdev emulation is now optional * minor fixes * tag 'omapdrm-4.5-resolved' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux: drm/omap: remove obsolete manager assignment drm/omap: set DRIVER_ATOMIC for omapdrm drm/omap: remove unused plugin defines drm/omap: Use bitmaps for TILER placement drm: omapdrm: gem: Remove check for impossible condition drm: omapdrm: gem: Simplify error handling when creating GEM object drm: omapdrm: gem: Don't free mmap offset twice drm: omapdrm: gem: Fix GEM object destroy in error path drm: omapdrm: gem: Free the correct memory object drm: omapdrm: gem: Mask out private flags passed from userspace drm: omapdrm: gem: Move global usergart variable to omap_drm_private drm: omapdrm: gem: Group functions by purpose drm: omapdrm: gem: Remove forward declarations drm: omapdrm: gem: Remove unused function prototypes drm: omapdrm: Make fbdev emulation optional drm: omapdrm: Fix plane state free in plane reset handler drm: omapdrm: move omap_plane_reset() drm/omap: Use platform_register/unregister_drivers() drm: omapdrm: tiler: Remove unneded module alias for tiler
-
Tomi Valkeinen authored
omap_encoder_update() assigns an overlay manager to dssdev->src->manager. This assignment is not needed, as the connections in the display chain have already been made at connect step. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Tomi Valkeinen authored
omapdrm supports atomic modesetting, and it seems to work ok. So let's set the flag to enable the atomic modesetting API support. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
-
Tomi Valkeinen authored
Remove unused defines related to SGX plugin which are not used. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
-
Andy Gross authored
Modified Tiler placement to utilize bitmaps for bookkeeping and all placement algorithms. This resulted in a substantial savings in time for all Tiler reservation and free operations. Typical savings are in the range of 28% decrease in time taken with larger buffers showing a 80%+ decrease. Signed-off-by: Andy Gross <andy.gross@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Laurent Pinchart authored
The GEM object can't be tiled without a usergart as that condition is checked and considered as an error when creating the GEM object. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Laurent Pinchart authored
The goto error statement end up just returning NULL without performing any cleanup, replace it with a direct return. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Laurent Pinchart authored
The drm_gem_free_mmap_offset() call in omap_gem_free_object() is redundant as the same function is called from drm_gem_object_release(). Remove it. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Laurent Pinchart authored
Use the omap_gem_free_object() function to destroy the GEM object in the omap_gem_new_handle() error path instead of doing it manually (and incorrectly). Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Laurent Pinchart authored
The GEM object free handler frees memory allocated by the driver using the pointer to the drm_gem_object instead of the pointer to the omap_gem_object that embeds it. This doesn't cause any issue in practice as the drm_gem_object is the first field of omap_gem_object, but would cause memory corruption if the structure layout changes. Fix it. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Laurent Pinchart authored
The 8 high order bits of the buffer flags are reserved for internal use. Mask them out from the flags passed by userspace. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-