- 10 Nov, 2023 9 commits
-
-
AngeloGioacchino Del Regno authored
In many cases, soft reset takes more than 1 microsecond, but definitely less than 10; moreover in the poweron flow, tilers, shaders and l2 will become ready (each) in less than 10 microseconds as well. Even in the cases (at least on my platforms, rarely) in which those take more than 10 microseconds, it's very unlikely to see both soft reset and poweron to take more than 70 microseconds. Shorten the polling delay to 10 microseconds to consistently reduce the runtime resume time of the GPU. As an indicative example, measurements taken on a MediaTek MT8195 SoC Average runtime resume time in nanoseconds before this commit: GDM, user selection up/down: 88435ns GDM, Text Entry (typing user/password): 91489ns GNOME Desktop, idling, GKRELLM running: 73200ns After this commit: GDM: user selection up/down: 26690ns GDM: Text Entry (typing user/password): 27917ns GNOME Desktop, idling, GKRELLM running: 25304ns Signed-off-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by:
Steven Price <steven.price@arm.com> Signed-off-by:
-
AngeloGioacchino Del Regno authored
Even though soft reset should ideally never fail, during development of some power management features I managed to get some bits wrong: this resulted in GPU soft reset failures, where the GPU was never able to recover, not even after suspend/resume cycles, meaning that the only way to get functionality back was to reboot the machine. Perform a hard reset after a soft reset failure to be able to recover the GPU during runtime (so, without any machine reboot). Signed-off-by:
-
AngeloGioacchino Del Regno authored
The layout of the registers {TILER,SHADER,L2}_PWROFF_LO, used to request powering off cores, is the same as the {TILER,SHADER,L2}_PWRON_LO ones: this means that in order to request poweroff of cores, we are supposed to write a bitmask of cores that should be powered off! This means that the panfrost_gpu_power_off() function has always been doing nothing. Fix powering off the GPU by writing a bitmask of the cores to poweroff to the relevant PWROFF_LO registers and then check that the transition (from ON to OFF) has finished by polling the relevant PWRTRANS_LO registers. While at it, in order to avoid code duplication, move the core mask logic from panfrost_gpu_power_on() to a new panfrost_get_core_mask() function, used in both poweron and poweroff. Fixes: f3ba9122 ("drm/panfrost: Add initial panfrost driver") Signed-off-by: -
Danilo Krummrich authored
Currently, job flow control is implemented simply by limiting the number of jobs in flight. Therefore, a scheduler is initialized with a credit limit that corresponds to the number of jobs which can be sent to the hardware. This implies that for each job, drivers need to account for the maximum job size possible in order to not overflow the ring buffer. However, there are drivers, such as Nouveau, where the job size has a rather large range. For such drivers it can easily happen that job submissions not even filling the ring by 1% can block subsequent submissions, which, in the worst case, can lead to the ring run dry. In order to overcome this issue, allow for tracking the actual job size instead of the number of jobs. Therefore, add a field to track a job's credit count, which represents the number of credits a job contributes to the scheduler's credit limit. Signed-off-by:
Danilo Krummrich <dakr@redhat.com> Reviewed-by:
Luben Tuikov <ltuikov89@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231110001638.71750-1-dakr@redhat.com
-
Luben Tuikov authored
Define pr_fmt() as "[drm] " for DRM code using pr_*() facilities, especially when no devices are available. This makes it easier to browse kernel logs. Signed-off-by:
-
Hsin-Yi Wang authored
Add a few generic edp panels used by mt8186 chromebooks. Signed-off-by:
Hsin-Yi Wang <hsinyi@chromium.org> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Acked-by:
Maxime Ripard <mripard@kernel.org> Signed-off-by:
-
Hsin-Yi Wang authored
Rename AUO 0x235c B116XTN02 to B116XTN02.3 according to decoding edid. Fixes: 3db24204 ("drm/panel-edp: Add AUO B116XTN02, BOE NT116WHM-N21,836X2, NV116WHM-N49 V8.0") Cc: stable@vger.kernel.org Signed-off-by:
-
Hsin-Yi Wang authored
Rename AUO 0x405c B116XAK01 to B116XAK01.0 and adjust the timing of auo_b116xak01: T3=200, T12=500, T7_max = 50 according to decoding edid and datasheet. Fixes: da458286 ("drm/panel: Add support for AUO B116XAK01 panel") Cc: stable@vger.kernel.org Signed-off-by:
-
Luben Tuikov authored
Don't "wake up" the GPU scheduler unless the entity is ready, as well as we can queue to the scheduler, i.e. there is no point in waking up the scheduler for the entity unless the entity is ready. Signed-off-by:
-
- 09 Nov, 2023 9 commits
-
-
Jani Nikula authored
Occasionally it's necessary for drivers to modify the SADs of an ELD, but it's not so cool to have drivers poke at the ELD buffer directly. Using the helpers to translate between 3-byte SAD and struct cea_sad, add ELD helpers to get/set the SADs from/to an ELD. v2: s/i/sad_index/ (Mitul) Cc: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/8e9a05f2b1e0dd184132d636e1e778e8917ec25d.1698747331.git.jani.nikula@intel.com
-
Jani Nikula authored
Add helpers to pack/unpack SADs. Both ways and non-static, as follow-up work needs them. v2: Add include to get the declarations Cc: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Reviewed-by:
-
Jani Nikula authored
Use a temporary variable struct cea_sad *, instead of using struct cea_sad ** directly with the double dereferences. It's arguably easier on the eyes, and drops a set of parenthesis too. Cc: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Reviewed-by:
-
Jani Nikula authored
Reduce the dependencies on drm_eld.h. Some files might be able to drop the dependency on drm_edid.h too with the direct inclusion of drm_eld.h. Cc: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Reviewed-by:
-
Jani Nikula authored
Unify on kernel types. Cc: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Reviewed-by:
Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by:
-
Jani Nikula authored
The drm_edid.[ch] files are starting to be a bit crowded, and with plans to add more ELD related functionality, it's perhaps cleanest to split the ELD code out to a header of its own. Include drm_eld.h from drm_edid.h for starters, and leave it to follow-up work to only include drm_eld.h where needed. Cc: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Reviewed-by:
-
Maíra Canal authored
I've been contributing to V3D with improvements, reviews, testing and debugging. Therefore, add myself as a co-maintainer of the V3D driver. Signed-off-by:
Maíra Canal <mcanal@igalia.com> Acked-by:
Melissa Wen <mwen@igalia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231106134201.725805-1-mcanal@igalia.com
-
Maxime Ripard authored
Most of those suites are undocumented and aren't really clear about what they are testing. Let's add a TODO entry as a future task to get started into KUnit and DRM. Acked-by:
Daniel Vetter <daniel@ffwll.ch> Link: https://lore.kernel.org/r/20231025132428.723672-2-mripard@kernel.orgSigned-off-by:
-
Maxime Ripard authored
Both the drm_buddy and drm_mm tests have been converted from selftest to kunit recently. However, a significant portion of them are trying to exert some part of their API over a huge number of iterations and with random variations of their parameters. They are thus more a way to discover new bugs than actual unit tests. This is fine in itself but leads to very slow runtime (up to 25s for some drm_test_mm_reserve and drm_test_mm_insert on a Ryzen 7950x while running the tests in qemu) which make them a poor fit for kunit. Let's remove those tests from the drm_mm and drm_buddy test suites for now, and if it's ever needed we can always create proper unit tests for them later on. This made the entire DRM tests execution time (as of v6.6-rc1) come from 65s to less than .5s on a Ryzen 7950x system when running under qemu, and from 9 minutes to about 4s on a RaspberryPi4. Acked-by:
-
- 08 Nov, 2023 6 commits
-
-
Jacek Lawrynowicz authored
Use struct drm_gem_shmem_object as a base for struct ivpu_bo. This cuts by 50% the buffer management code. Signed-off-by:
Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Reviewed-by:
Jeffrey Hugo <quic_jhugo@quicinc.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231031073156.1301669-5-stanislaw.gruszka@linux.intel.com
-
Jacek Lawrynowicz authored
Usages of DRM_IVPU_BO_UNCACHED should be replaced by DRM_IVPU_BO_WC. There is no functional benefit from DRM_IVPU_BO_UNCACHED if these buffers are never mapped to host VM. This allows to cut the buffer handling code in the kernel driver by half. Usage of DRM_IVPU_BO_UNCACHED buffers was removed from user-space driver and will not be part of first UMD release. Signed-off-by:
-
Jacek Lawrynowicz authored
ivpu_bo_remove_all_bos_from_context() could race with ivpu_bo_free() when prime buffer was closed after vpu device was closed. Move the bo_list from context to vdev and use a dedicated lock to sync it. This list is not modified when BO is added/removed from a context. Also rename ivpu_bo_free_vpu_addr() to ivpu_bo_unbind() because this function does more then just free vpu_addr. Signed-off-by:
-
Jacek Lawrynowicz authored
Use gem->open() callback to simplify the code and prepare for gem_shmem conversion. It is called during handle creation for a gem object, during prime import and in BO_CREATE ioctl. Hence can be used for vpu_addr allocation. On the way remove unused bo->user_ptr field. Signed-off-by:
-
Emma Anholt authored
I am not active in the Linux kernel and don't want to see patches. Signed-off-by:
Emma Anholt <emma@anholt.net> Acked-by:
-
Luben Tuikov authored
Don't call drm_sched_select_entity() in drm_sched_run_job_queue(). In fact, rename __drm_sched_run_job_queue() to just drm_sched_run_job_queue(), and let it do just that, schedule the work item for execution. The problem is that drm_sched_run_job_queue() calls drm_sched_select_entity() to determine if the scheduler has an entity ready in one of its run-queues, and in the case of the Round-Robin (RR) scheduling, the function drm_sched_rq_select_entity_rr() does just that, selects the _next_ entity which is ready, sets up the run-queue and completion and returns that entity. The FIFO scheduling algorithm is unaffected. Now, since drm_sched_run_job_work() also calls drm_sched_select_entity(), then in the case of RR scheduling, that would result in drm_sched_select_entity() having been called twice, which may result in skipping a ready entity if more than one entity is ready. This commit fixes this by eliminating the call to drm_sched_select_entity() from drm_sched_run_job_queue(), and leaves it only in drm_sched_run_job_work(). v2: Rebased on top of Tvrtko's renames series of patches. (Luben) Add fixes-tag. (Tvrtko) Signed-off-by:Matthew Brost <matthew.brost@intel.com> Reviewed-by:
-
- 07 Nov, 2023 1 commit
-
-
Jacek Lawrynowicz authored
Use pm_runtime_status_suspended() instead of dev->power.runtime_status field that is not available without PM. Signed-off-by:
-
- 06 Nov, 2023 4 commits
-
-
Dario Binacchi authored
Replace 'HFP' with 'HBP'. Fixes: 899f24ed ("drm/panel: Add driver for Novatek NT35510-based panels") Signed-off-by:
Dario Binacchi <dario.binacchi@amarulasolutions.com> Reviewed-by:
Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231023090613.1694133-1-dario.binacchi@amarulasolutions.com
-
Maíra Canal authored
The previous patch exposed the accumulated amount of active time per client for each V3D queue. But this doesn't provide a global notion of the GPU usage. Therefore, provide the accumulated amount of active time for each V3D queue (BIN, RENDER, CSD, TFU and CACHE_CLEAN), considering all the jobs submitted to the queue, independent of the client. This data is exposed through the sysfs interface, so that if the interface is queried at two different points of time the usage percentage of each of the queues can be calculated. Co-developed-by:
Jose Maria Casanova Crespo <jmcasanova@igalia.com> Signed-off-by:
-
Maíra Canal authored
This patch exposes the accumulated amount of active time per client through the fdinfo infrastructure. The amount of active time is exposed for each V3D queue: BIN, RENDER, CSD, TFU and CACHE_CLEAN. In order to calculate the amount of active time per client, a CPU clock is used through the function local_clock(). The point where the jobs has started is marked and is finally compared with the time that the job had finished. Moreover, the number of jobs submitted to each queue is also exposed on fdinfo through the identifier "v3d-jobs-<queue>". Co-developed-by:
-
Tvrtko Ursulin authored
It is better not to lose precision and not revert to 1 MiB size granularity for every size greater than 1 MiB. Sizes in KiB should not be so troublesome to read (and in fact machine parsing is I expect the norm here), they align with other api like /proc/meminfo, and they allow writing tests for the interface without having to embed drm.ko implementation knowledge into them. (Like knowing that minimum buffer size one can use for successful verification has to be 1MiB aligned, and on top account for any pre-existing memory utilisation outside of driver's control.) But probably even more importantly I think that it is just better to show the accurate sizes and not arbitrary lose precision for a little bit of a stretched use case of eyeballing fdinfo text directly. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Adrián Larumbe <adrian.larumbe@collabora.com> Cc: steven.price@arm.com Reviewed-by:
-
- 05 Nov, 2023 5 commits
-
-
Tvrtko Ursulin authored
Because a) helper is exported to other parts of the scheduler and b) there isn't a plain drm_sched_wakeup to begin with, I think we can drop the suffix and by doing so separate the intimiate knowledge between the scheduler components a bit better. Signed-off-by:
-
Tvrtko Ursulin authored
"If ready" is not immediately clear what it means - is the scheduler ready or something else? Drop the suffix, clarify kerneldoc, and employ the same naming scheme as in drm_sched_run_free_queue: - drm_sched_run_job_queue - enqueues if there is something to enqueue *and* scheduler is ready (can queue) - __drm_sched_run_job_queue - low-level helper to simply queue the job Signed-off-by: -
Tvrtko Ursulin authored
The current name makes it sound like helper will free a queue, while what it does is it enqueues the free job worker. Rename it to drm_sched_run_free_queue to align with existing drm_sched_run_job_queue. Despite that creating an illusion there are two queues, while in reality there is only one, at least it creates a consistent naming for the two enqueuing helpers. At the same time simplify the "if done" helper by dropping the suffix and adding a double underscore prefix to the one which just enqueues. Signed-off-by:
-
Tvrtko Ursulin authored
Whether or not there are more jobs to clean up does not depend on the existance of the current job, given both drm_sched_get_finished_job and drm_sched_free_job_queue_if_done take and drop the job list lock. Therefore it is confusing to make it read like there is a dependency. Signed-off-by:
-
Tvrtko Ursulin authored
"Get cleanup job" makes it sound like helper is returning a job which will execute some cleanup, or something, while the kerneldoc itself accurately says "fetch the next _finished_ job". So lets rename the helper to be self documenting. Signed-off-by:
-
- 03 Nov, 2023 2 commits
-
-
Pranjal Ramajor Asha Kanojiya authored
Add support to partially execute a slice which is resized to zero. Executing a zero size slice in a BO should mean that there is no DMA transfers involved but you should still configure doorbell and semaphores. For example consider a BO of size 18K and it is sliced into 3 6K slices and user calls partial execute ioctl with resize as 10K. slice 0 - size is 6k and offset is 0, so resize of 10K will not cut short this slice hence we send the entire slice for execution. slice 1 - size is 6k and offset is 6k, so resize of 10K will cut short this slice and only the first 4k should be DMA along with configuring doorbell and semaphores. slice 2 - size is 6k and offset is 12k, so resize of 10k will cut short this slice and no DMA transfer would be involved but we should would configure doorbell and semaphores. This change begs to change the behavior of 0 resize. Currently, 0 resize partial execute ioctl behaves exactly like execute ioctl i.e. no resize. After this patch all the slice in BO should behave exactly like slice 2 in above example. Refactor copy_partial_exec_reqs() to make it more readable and less complex. Signed-off-by:Pranjal Ramajor Asha Kanojiya <quic_pkanojiy@quicinc.com> Reviewed-by:
Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231027164330.11978-1-quic_jhugo@quicinc.com
-
Carl Vanderlip authored
Current wrapper is right-sized to the message being transferred; however, this is smaller than the structure defining message wrappers since the trailing element is a union of message/transfer headers of various sizes (8 and 32 bytes on 32-bit system where issue was reported). Using the smaller header with a small message (wire_trans_dma_xfer is 24 bytes including header) ends up being smaller than a wrapper with the larger header. There are no accesses outside of the defined size, however they are possible if the larger union member is referenced. Abort messages are outside of hot-path and changing the wrapper struct would require a larger rewrite, so having the memory allocated to the message be 8 bytes too big is acceptable. Reported-by:
kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202310182253.bcb9JcyJ-lkp@intel.com/Signed-off-by:
Carl Vanderlip <quic_carlv@quicinc.com> Reviewed-by:
-
- 02 Nov, 2023 4 commits
-
-
Iago Toral Quiroga authored
This is required to get the V3D module to load with Raspberry Pi 5. Signed-off-by:
Iago Toral Quiroga <itoral@igalia.com> Reviewed-by:
Stefan Wahren <wahrenst@gmx.net> Reviewed-by:
-
Iago Toral Quiroga authored
BCM2712, Raspberry Pi 5's SoC, contains a V3D core. So add its specific compatible to the bindings. Signed-off-by:
Conor Dooley <conor.dooley@microchip.com> Signed-off-by:
-
Iago Toral Quiroga authored
This patch updates a number of register addresses that have been changed in Raspberry Pi 5 (V3D 7.1) and updates the code to use the corresponding registers and addresses based on the actual V3D version. Signed-off-by:
-
Iago Toral Quiroga authored
V3D 7.x takes a new parameter to configure TFU jobs that needs to be provided by user space. Signed-off-by:
-
