- 02 8月, 2017 1 次提交
-
-
由 Archit Taneja 提交于
msm_gpu's get_timestamp() op (called by the MSM_GET_PARAM ioctl) can result in register accesses. We need our power domain and clocks to be active for that. Make sure they are enabled here. Signed-off-by: NArchit Taneja <architt@codeaurora.org> Signed-off-by: NRob Clark <robdclark@gmail.com>
-
- 17 6月, 2017 1 次提交
-
-
由 Sushmita Susheelendra 提交于
Buffer object specific resources like pages, domains, sg list need not be protected with struct_mutex. They can be protected with a buffer object level lock. This simplifies locking and makes it easier to avoid potential recursive locking scenarios for SVM involving mmap_sem and struct_mutex. This also removes unnecessary serialization when creating buffer objects, and also between buffer object creation and GPU command submission. Signed-off-by: NSushmita Susheelendra <ssusheel@codeaurora.org> [robclark: squash in handling new locking for shrinker] Signed-off-by: NRob Clark <robdclark@gmail.com>
-
- 16 6月, 2017 4 次提交
-
-
由 Rob Clark 提交于
No functional change, that will come later. But this will make it easier to deal with dynamically created address spaces (ie. per- process pagetables for gpu). Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Rob Clark 提交于
Most, but not all, paths where calling the with struct_mutex held. The fast-path in msm_gem_get_iova() (plus some sub-code-paths that only run the first time) was masking this issue. So lets just always hold struct_mutex for hw_init(). And sprinkle some WARN_ON()'s and might_lock() to avoid this sort of problem in the future. Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Jordan Crouse 提交于
memptrs->wptr seems to be unused. Remove it to avoid confusing the upcoming preemption code. Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org> Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Jordan Crouse 提交于
The amount of information that we need to pass into msm_gpu_init() is steadily increasing, so add a new struct to stabilize the function call and make it easier to add new configuration down the line. Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org> Signed-off-by: NRob Clark <robdclark@gmail.com>
-
- 08 4月, 2017 7 次提交
-
-
由 Jordan Crouse 提交于
Some A3XX and A4XX GPU targets required that the GPU clock be programmed to a non zero value when it was disabled so 27Mhz was chosen as the "invalid" frequency. Even though newer targets do not have the same clock restrictions we still write 27Mhz on clock disable and expect the clock subsystem to round down to zero. For unknown reasons even though the slow clock speed is always 27Mhz and it isn't actually a functional level the legacy device tree frequency tables always defined it and then did gymnastics to work around it. Instead of playing the same silly games just hard code the "slow" clock speed in the code as 27MHz and save ourselves a bit of infrastructure. Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org> Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Jordan Crouse 提交于
User space needs to know where the GMEM whole starts so that they can set up the addressing correctly. Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org> Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Jordan Crouse 提交于
There are reasons for a memory object to outlive the file descriptor that created it and so the address space that a buffer object is attached to must also outlive the file descriptor. Reference count the address space so that it can remain viable until all the objects have released their addresses. Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org> Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Jordan Crouse 提交于
We should be detaching the MMU before destroying the address space. To do this cleanly, the detach has to happen in adreno_gpu_cleanup() because it needs access to structs in adreno_gpu.c. Plus it is better symmetry to have the attach and detach at the same code level. Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org> Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Rob Clark 提交于
We need to do this also in resume path when we need to re-hw_init(). Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Rob Clark 提交于
We need to use pm-runtime properly when IOMMU is using device_link() to control it's own clocks. Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Rob Clark 提交于
Each of the per-generation callbacks was doing this. Lets just simplify and move it into toplevel show() fxn. Signed-off-by: NRob Clark <robdclark@gmail.com>
-
- 04 4月, 2017 1 次提交
-
-
由 Jordan Crouse 提交于
We should be detaching the MMU before destroying the address space. To do this cleanly, the detach has to happen in adreno_gpu_cleanup() because it needs access to structs in adreno_gpu.c. Plus it is better symmetry to have the attach and detach at the same code level. Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org> Signed-off-by: NRob Clark <robdclark@gmail.com>
-
- 07 2月, 2017 1 次提交
-
-
由 Rob Clark 提交于
This was never documented or used in upstream dtb. It is used by downstream bindings from android device kernels. But the quirks are a property of the gpu revision, and as such are redundant to be listed separately in dt. Instead, move the quirks to the device table. Signed-off-by: NRob Clark <robdclark@gmail.com> Reviewed-by: NEric Anholt <eric@anholt.net>
-
- 13 1月, 2017 1 次提交
-
-
由 Rob Clark 提交于
Fixes: 9cb07b099fb ("drm/msm: support multiple address spaces") Reported-by: NRiku Voipio <riku.voipio@linaro.org> Signed-off-by: NRob Clark <robdclark@gmail.com>
-
- 30 12月, 2016 1 次提交
-
-
由 Jordan Crouse 提交于
Currently the value written to CP_RB_WPTR is calculated on the fly as (rb->next - rb->start). But as the code is designed rb->next is wrapped before writing the commands so if a series of commands happened to fit perfectly in the ringbuffer, rb->next would end up being equal to rb->size / 4 and thus result in an out of bounds address to CP_RB_WPTR. The easiest way to fix this is to mask WPTR when writing it to the hardware; it makes the hardware happy and the rest of the ringbuffer math appears to work and there isn't any point in upsetting anything. Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org> [squash in is_power_of_2() check] Signed-off-by: NRob Clark <robdclark@gmail.com>
-
- 29 11月, 2016 5 次提交
-
-
由 Jordan Crouse 提交于
Add support for the A5XX family of Adreno GPUs. Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org> Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Jordan Crouse 提交于
Disable the interrupt during the init sequence to avoid having interrupts fired for errors and other things that we are not ready to handle while initializing. Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org> Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Jordan Crouse 提交于
Add a new generic function to write a "64" bit value. This isn't actually a 64 bit operation, it just writes the upper and lower 32 bit of a 64 bit value to a specified LO and HI register. If a particular target doesn't support one of the registers it can mark that register as SKIP and writes/reads from that register will be quietly dropped. This can be immediately put in place for the ringbuffer base and the RPTR address. Both writes are converted to use adreno_gpu_write64() with their respective high and low registers and the high register appropriately marked as SKIP for both 32 bit targets (a3xx and a4xx). When a5xx comes it will define valid target registers for the 'hi' option and everything else will just work. Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org> Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Jordan Crouse 提交于
When the GPU hardware init function fails (like say, ME_INIT timed out) return error instead of blindly continuing on. This gives us a small chance of saving the system before it goes boom. Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org> Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Rob Clark 提交于
Scratch registers move, annoyingly enough, in a5xx. Move to per-generation aNxx_recover() fxn. Signed-off-by: NRob Clark <robdclark@gmail.com>
-
- 28 11月, 2016 1 次提交
-
-
由 Rob Clark 提交于
We can have various combinations of 64b and 32b address space, ie. 64b CPU but 32b display and gpu, or 64b CPU and GPU but 32b display. So best to decouple the device iova's from mmap offset. Signed-off-by: NRob Clark <robdclark@gmail.com>
-
- 16 7月, 2016 2 次提交
-
-
由 Rob Clark 提交于
For some optimizations coming on the userspace side, splitting larger draw or gmem cmds into multiple cmdstream buffers, we need to support much more than the previous small/arbitrary limit. Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Rob Clark 提交于
Before we can add vmap shrinking, we really need to know which vmap'ings are currently being used. So switch to get/put interface. Stubbed put fxns for now. Signed-off-by: NRob Clark <robdclark@gmail.com>
-
- 05 6月, 2016 1 次提交
-
-
由 Rob Clark 提交于
Some, but not all, callers of obj->vmap() would check if return IS_ERR(). So let's actually return an error if vmap() fails. And fixup the call-sites that were not handling this properly. Signed-off-by: NRob Clark <robdclark@gmail.com>
-
- 08 5月, 2016 4 次提交
-
-
由 Rob Clark 提交于
At this point, there is nothing left to fail. And submit already has a fence assigned and is added to the submit_list. Any problems from here on out are asynchronous (ie. hangcheck/recovery). Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Rob Clark 提交于
It is no longer true that we discard all in-flight submits on recover (these days we only discard the first one that hung). After the first re-submitted batch completes it would overwrite the fence with a correct value, but there would be a window of time which showed all re-submitted batches as already complete. Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Rob Clark 提交于
Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Rob Clark 提交于
Better encapsulate the per-timeline stuff into fence-context. For now there is just a single fence-context, but eventually we'll also have one per-CRTC to enable fully explicit fencing. Signed-off-by: NRob Clark <robdclark@gmail.com>
-
- 04 3月, 2016 3 次提交
-
-
由 Rob Clark 提交于
We need this for GL_TIMESTAMP queries. Note: currently only supported on a4xx.. a3xx doesn't have this always-on counter. I think we could emulate it with the one CP counter that is available, but for now it is of limited usefulness on a3xx (since we can't seem to do time-elapsed queries in any sane way with the existing firmware on a3xx, and if you are trying to do profiling on a tiler you want time-elapsed). We can add that later if it becomes useful. Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Craig Stout 提交于
As described in the downstream/kgsl driver: Sometimes the RPTR shadow memory is unreliable causing timeouts in adreno_idle(). Read it directly from the register instead. Signed-off-by: NCraig Stout <cstout@chromium.org> Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Craig Stout 提交于
Signed-off-by: NCraig Stout <cstout@chromium.org> Signed-off-by: NRob Clark <robdclark@gmail.com>
-
- 11 2月, 2016 1 次提交
-
-
由 Rob Clark 提交于
We need this in userspace for interpreting some of the perf ctrs. Note possibly not quite sufficient if we had some frequency mgmt approach other than race-to-idle. Not really sure what the best thing to do if we did. Although displaying results as a percentage of max frequence seems sensible(ish) if we did. Signed-off-by: NRob Clark <robdclark@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 12 6月, 2015 3 次提交
-
-
由 Rob Clark 提交于
Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Rob Clark 提交于
A few spots in the driver have support for downstream android CONFIG_MSM_BUS_SCALING. This is mainly to simplify backporting the driver for various devices which do not have sufficient upstream kernel support. But the intentionally dead code seems to cause some confusion. Rename the #define to make this more clear. Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Rob Clark 提交于
Dump a bit more info when the GPU hangs, without having hang_debug enabled (which dumps a *lot* of registers). Also dump the scratch registers, as they are useful for determining where in the cmdstream the GPU hung (and they seem always safe to read when GPU has hung). Note that the freedreno gallium driver emits increasing counter values to SCRATCH6 (to identify tile #) and SCRATCH7 (to identify draw #), so these two in particular can be used to "triangulate" where in the cmdstream the GPU hung. Signed-off-by: NRob Clark <robdclark@gmail.com>
-
- 15 5月, 2015 1 次提交
-
-
由 Rob Clark 提交于
In error paths, this was being called without struct_mutex held. Leading to panics like: msm 1a00000.qcom,mdss_mdp: No memory protection without IOMMU Kernel panic - not syncing: BUG! CPU: 0 PID: 1409 Comm: cat Not tainted 4.0.0-dirty #4 Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT) Call trace: [<ffffffc000089c78>] dump_backtrace+0x0/0x118 [<ffffffc000089da0>] show_stack+0x10/0x20 [<ffffffc0006686d4>] dump_stack+0x84/0xc4 [<ffffffc0006678b4>] panic+0xd0/0x210 [<ffffffc0003e1ce4>] drm_gem_object_free+0x5c/0x60 [<ffffffc000402870>] adreno_gpu_cleanup+0x60/0x80 [<ffffffc0004035a0>] a3xx_destroy+0x20/0x70 [<ffffffc0004036f4>] a3xx_gpu_init+0x84/0x108 [<ffffffc0004018b8>] adreno_load_gpu+0x58/0x190 [<ffffffc000419dac>] msm_open+0x74/0x88 [<ffffffc0003e0a48>] drm_open+0x168/0x400 [<ffffffc0003e7210>] drm_stub_open+0xa8/0x118 [<ffffffc0001a0e84>] chrdev_open+0x94/0x198 [<ffffffc000199f88>] do_dentry_open+0x208/0x310 [<ffffffc00019a4c4>] vfs_open+0x44/0x50 [<ffffffc0001aa26c>] do_last.isra.14+0x2c4/0xc10 [<ffffffc0001aac38>] path_openat+0x80/0x5e8 [<ffffffc0001ac354>] do_filp_open+0x2c/0x98 [<ffffffc00019b60c>] do_sys_open+0x13c/0x228 [<ffffffc00019b72c>] SyS_openat+0xc/0x18 CPU1: stopping But there isn't any particularly good reason to hold struct_mutex for teardown, so just standardize on calling it without the mutex held and use the _unlocked() versions for GEM obj unref'ing Signed-off-by: NRob Clark <robdclark@gmail.com>
-
- 17 12月, 2014 1 次提交
-
-
由 Markus Elfring 提交于
The release_firmware() 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: NMarkus Elfring <elfring@users.sourceforge.net> Reviewed-by: NThierry Reding <treding@nvidia.com> Signed-off-by: NRob Clark <robdclark@gmail.com>
-
- 17 11月, 2014 1 次提交
-
-
由 Aravind Ganesan 提交于
Added a4xx GPU support. Signed-off-by: NAravind Ganesan <aravindg@codeaurora.org> Signed-off-by: NRob Clark <robdclark@gmail.com>
-