- 25 8月, 2015 23 次提交
-
-
由 Chunming Zhou 提交于
Signed-off-by: NChunming Zhou <david1.zhou@amd.com> Reviewed-by: NChristian K?nig <christian.koenig@amd.com>
-
由 Chunming Zhou 提交于
Signed-off-by: NChunming Zhou <david1.zhou@amd.com> Reviewed-by: NChristian K?nig <christian.koenig@amd.com>
-
由 Chunming Zhou 提交于
Signed-off-by: NChunming Zhou <david1.zhou@amd.com> Reviewed-by: NChristian K?nig <christian.koenig@amd.com>
-
由 Christian König 提交于
Entity don't live as long as scheduler fences. Signed-off-by: NChristian König <christian.koenig@amd.com> Reviewed-by: NChunming Zhou <david1.zhou@amd.com>
-
由 Christian König 提交于
Calling schedule() is probably the worse things we can do. Signed-off-by: NChristian König <christian.koenig@amd.com> Reviewed-by: NChunming Zhou <david1.zhou@amd.com>
-
由 Christian König 提交于
Not used any more. Signed-off-by: NChristian König <christian.koenig@amd.com> Reviewed-by: NChunming Zhou <david1.zhou@amd.com>
-
由 Christian König 提交于
Signed-off-by: NChristian König <christian.koenig@amd.com> Reviewed-by: NChunming Zhou <david1.zhou@amd.com>
-
由 Christian König 提交于
Signed-off-by: NChristian König <christian.koenig@amd.com> Reviewed-by: NChunming Zhou <david1.zhou@amd.com>
-
由 Christian König 提交于
It isn't protecting anything. Signed-off-by: NChristian König <christian.koenig@amd.com> Reviewed-by: NChunming Zhou <david1.zhou@amd.com>
-
由 Christian König 提交于
Not used any more. Signed-off-by: NChristian König <christian.koenig@amd.com> Reviewed-by: NChunming Zhou <david1.zhou@amd.com>
-
由 Christian König 提交于
Signed-off-by: NChristian König <christian.koenig@amd.com> Reviewed-by: NChunming Zhou <david1.zhou@amd.com>
-
由 Christian König 提交于
Keep run queue, entity and scheduler handling together. Signed-off-by: NChristian König <christian.koenig@amd.com> Reviewed-by: NChunming Zhou <david1.zhou@amd.com>
-
由 Christian König 提交于
Signed-off-by: NChristian König <christian.koenig@amd.com> Reviewed-by: NChunming Zhou <david1.zhou@amd.com>
-
由 Christian König 提交于
That actually didn't worked at all. Signed-off-by: NChristian König <christian.koenig@amd.com> Reviewed-by: NChunming Zhou <david1.zhou@amd.com>
-
由 Christian König 提交于
Cleanup function name, stop checking scheduler ready twice, but check if kernel thread should stop instead. Signed-off-by: NChristian König <christian.koenig@amd.com> Reviewed-by: NChunming Zhou <david1.zhou@amd.com>
-
由 Christian König 提交于
None of them are used any more. v2: fix type in error message Signed-off-by: NChristian König <christian.koenig@amd.com> Reviewed-by: NChunming Zhou <david1.zhou@amd.com>
-
由 Christian König 提交于
Signed-off-by: NChristian König <christian.koenig@amd.com> Reviewed-by: NChunming Zhou <david1.zhou@amd.com>
-
由 Christian König 提交于
Signed-off-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NChunming Zhou <david1.zhou@amd.com> Reviewed-by: NChristian K?nig <christian.koenig@amd.com>
-
由 Christian König 提交于
Remove active_hw_rq and it's protecting queue_lock, they are unused. User 32bit atomic for hw_rq_count, 64bits for counting to three is a bit overkill. Cleanup the function name and remove incorrect comments. Signed-off-by: NChristian König <christian.koenig@amd.com> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Reviewed-by: NJammy Zhou <Jammy.Zhou@amd.com>
-
由 Christian König 提交于
Simply not used any more. Only keep 32bit atomic for fence sequence numbering. v2: trivial rebase Signed-off-by: NChristian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> (v1) Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com> (v1) Reviewed-by: Chunming Zhou <david1.zhou@amd.com> (v1)
-
由 Chunming Zhou 提交于
Signed-off-by: NChunming Zhou <david1.zhou@amd.com> Reviewed-by: NChristian K?nig <christian.koenig@amd.com>
-
由 Junwei Zhang 提交于
Rename the function and update the related code with this modified function. Add the new parameter of bool wait_all. If wait_all is true, it will return when all fences are signaled or timeout. If wait_all is false, it will return when any fence is signaled or timeout. Signed-off-by: NJunwei Zhang <Jerry.Zhang@amd.com> Reviewed-by: NMonk Liu <monk.liu@amd.com> Reviewed-by: NJammy Zhou <Jammy.Zhou@amd.com> Reviewed-by: NChristian König <christian.koenig@amd.com>
-
由 Alex Deucher 提交于
Use pci_alloc_consistent rather than kzalloc since we need 256 byte aligned memory for the ring buffer. v2: fix copy paste typo in free function noticed by Jammy. bug: https://bugs.freedesktop.org/show_bug.cgi?id=91749Reviewed-by: NChristian König <christian.koenig@amd.com> Reviewed-by: NJammy Zhou <Jammy.Zhou@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
- 22 8月, 2015 2 次提交
-
-
由 Alex Deucher 提交于
This is a port of: DRM - radeon: Don't link train DisplayPort on HPD until we get the dpcd to amdgpu. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Stephen Chandler Paul 提交于
Most of the time this isn't an issue since hotplugging an adaptor will trigger a crtc mode change which in turn, causes the driver to probe every DisplayPort for a dpcd. However, in cases where hotplugging doesn't cause a mode change (specifically when one unplugs a monitor from a DisplayPort connector, then plugs that same monitor back in seconds later on the same port without any other monitors connected), we never probe for the dpcd before starting the initial link training. What happens from there looks like this: - GPU has only one monitor connected. It's connected via DisplayPort, and does not go through an adaptor of any sort. - User unplugs DisplayPort connector from GPU. - Change in HPD is detected by the driver, we probe every DisplayPort for a possible connection. - Probe the port the user originally had the monitor connected on for it's dpcd. This fails, and we clear the first (and only the first) byte of the dpcd to indicate we no longer have a dpcd for this port. - User plugs the previously disconnected monitor back into the same DisplayPort. - radeon_connector_hotplug() is called before everyone else, and tries to handle the link training. Since only the first byte of the dpcd is zeroed, the driver is able to complete link training but does so against the wrong dpcd, causing it to initialize the link with the wrong settings. - Display stays blank (usually), dpcd is probed after the initial link training, and the driver prints no obvious messages to the log. In theory, since only one byte of the dpcd is chopped off (specifically, the byte that contains the revision information for DisplayPort), it's not entirely impossible that this bug may not show on certain monitors. For instance, the only reason this bug was visible on my ASUS PB238 monitor was due to the fact that this monitor using the enhanced framing symbol sequence, the flag for which is ignored if the radeon driver thinks that the DisplayPort version is below 1.1. Signed-off-by: NStephen Chandler Paul <cpaul@redhat.com> Reviewed-by: NJerome Glisse <jglisse@redhat.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
- 21 8月, 2015 9 次提交
-
-
由 Christian König 提交于
Stop double freeing the the BO list by pulling the content of amdgpu_cs_parser_prepare_job() into the IOCTL function again. v2: better commit message Signed-off-by: NChristian König <christian.koenig@amd.com> Reviewed-by: Chunming Zhou <david1.zhou@amd.com> (v1) Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Christian König 提交于
The problem now is that we don't necessarily call amdgpu_ib_get() in some error paths and so work with uninitialized data. Better require that the memory is already zeroed. v2: better commit message Signed-off-by: NChristian König <christian.koenig@amd.com> Reviewed-by: Chunming Zhou <david1.zhou@amd.com> (v1) Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Christian König 提交于
Fixes a whole bunch of lockdep warnings. Signed-off-by: NChristian König <christian.koenig@amd.com> Reviewed-by: NChunming Zhou <david1.zhou@amd.com>
-
由 Christian König 提交于
More appropriate and fixes some nasty lockdep warnings. Signed-off-by: NChristian König <christian.koenig@amd.com> Reviewed-by: NChunming Zhou <david1.zhou@amd.com>
-
由 Chunming Zhou 提交于
Signed-off-by: NChunming Zhou <david1.zhou@amd.com> Reviewed-by: NChristian K?nig <christian.koenig@amd.com>
-
由 Chunming Zhou 提交于
Signed-off-by: NChunming Zhou <david1.zhou@amd.com> Reviewed-by: NChristian K?nig <christian.koenig@amd.com>
-
由 Chunming Zhou 提交于
Signed-off-by: NChunming Zhou <david1.zhou@amd.com> Reviewed-by: NChristian K?nig <christian.koenig@amd.com>
-
由 Chunming Zhou 提交于
Signed-off-by: NChunming Zhou <david1.zhou@amd.com> Reviewed-by: NChristian K?nig <christian.koenig@amd.com>
-
由 Marek Olšák 提交于
Used by mesa, etc. for profiling. Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com> Signed-off-by: NMarek Olšák <marek.olsak@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
- 20 8月, 2015 1 次提交
-
-
由 Jianwei Wang 提交于
This patch add support for Two Dimensional Animation and Compositing Engine (2D-ACE) on the Freescale SoCs. 2D-ACE is a Freescale display controller. 2D-ACE describes the functionality of the module extremely well its name is a value that cannot be used as a token in programming languages. Instead the valid token "DCU" is used to tag the register names and function names. The Display Controller Unit (DCU) module is a system master that fetches graphics stored in internal or external memory and displays them on a TFT LCD panel. A wide range of panel sizes is supported and the timing of the interface signals is highly configurable. Graphics are read directly from memory and then blended in real-time, which allows for dynamic content creation with minimal CPU intervention. The features: (1) Full RGB888 output to TFT LCD panel. (2) Blending of each pixel using up to 4 source layers dependent on size of panel. (3) Each graphic layer can be placed with one pixel resolution in either axis. (4) Each graphic layer support RGB565 and RGB888 direct colors without alpha channel and BGRA8888 BGRA4444 ARGB1555 direct colors with an alpha channel and YUV422 format. (5) Each graphic layer support alpha blending with 8-bit resolution. This is a simplified version, only one primary plane, one framebuffer, one crtc, one connector and one encoder for TFT LCD panel. Signed-off-by: NAlison Wang <b18965@freescale.com> Signed-off-by: NXiubo Li <lixiubo@cmss.chinamobile.com> Signed-off-by: NJianwei Wang <jianwei.wang.chn@gmail.com> Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 18 8月, 2015 5 次提交
-
-
由 Boris Brezillon 提交于
Describe capabilities of the HLCDC IP found on sama5d4 SoCs and add a new entry to the atmel_hlcdc_of_match table. Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
-
由 Boris Brezillon 提交于
Describe capabilities of the HLCDC IP found on at91sam9n12 SoC and add a new entry to the atmel_hlcdc_of_match table. Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
-
由 Boris Brezillon 提交于
Describe capabilities of the HLCDC IP found on at91sam9x5 SoCs and add a new entry to the atmel_hlcdc_of_match table. Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
-
由 Boris Brezillon 提交于
The HLCDC IP supports RGB565 and RGB444 output formats. Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
-
由 Boris Brezillon 提交于
The atmel-hlcdc driver already supports atomic operations, add the missing DRM_ATOMIC flag to expose the atomic features to userspace. Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
-