don't forget to mention this change in the commit message of v2.
Already included in v2.
Thanks for your review Maíra.
Kind regards.
Chema Casanova
r (size_t i = 0; i < ARRAY_SIZE(v3d_axi_ids); i++) {
if (axi_id >= v3d_axi_ids[i].begin
&& axi_id < v3d_axi_ids[i].end) {
client = v3d_axi_ids[i].client;
break;
}
}
After checking with Maíra we agree that was simpler the original
approach, as we would need to include an extra of the number
of elements in the arrays as ARRAY_SIZE and the compiler would
need to thread the size of the arrays as dynamic.
Kind regards,
Chema Casanova
Reviewed-by: Jose Maria Casanova Crespo
El 23/1/25 a las 2:24, Maíra Canal escribió:
In commit e4b5ccd392b9 ("drm/v3d: Ensure job pointer is set to NULL
after job completion"), we introduced a change to assign the job pointer
to NULL after completing a job, indicating job completion.
However,
Reviewed-by: Jose Maria Casanova Crespo
El 13/1/25 a las 16:47, Maíra Canal escribió:
CPU jobs, like Clean Cache jobs, execute synchronously once the DRM
scheduler starts running them. Consequently, a global `v3d->cpu_job`
variable is unnecessary, as everything is managed within the
`v3d_cpu_jo
El 13/1/25 a las 16:47, Maíra Canal escribió:
After a job completes, the corresponding pointer in the device must
be set to NULL. Failing to do so triggers a warning when unloading
the driver, as it appears the job is still active. To prevent this,
assign the job pointer to NULL after completing
El 3/4/24 a las 22:24, Maíra Canal escribió:
This will make it easier to instantiate the GPU stats variables and it
will create a structure where we can store all the variables that refer
to GPU stats.
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/v3d/v3d_drv.c | 14 ++
driver
El 3/4/24 a las 22:24, Maíra Canal escribió:
Given a set of GPU stats, that is, a `struct v3d_stats` related to a
queue in a given context, create a function that can update all this set of
GPU stats.
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/v3d/v3d_sched.c | 20
1
El 3/4/24 a las 22:24, Maíra Canal escribió:
The commit 509433d8146c ("drm/v3d: Expose the total GPU usage stats on sysfs")
introduced the calculation of global GPU stats. For the regards, it used
the already existing infrastructure provided by commit 09a93cc4f7d1 ("drm/v3d:
Implement show_fdinfo
El 3/4/24 a las 22:24, Maíra Canal escribió:
Currently, we manually perform all operations to update the GPU stats
variables. Apart from the code repetition, this is very prone to errors,
as we can see on the previous commit.
Therefore, create two functions to manage updating all GPU stats
varia
* Document the expected behavior in case of a GPU reset (Melissa Wen)
* Add a brief description about the sysfs outputs (Melissa Wen)
* Instead of having multiple sysfs files, use only one sysfs file,
called gpu_stats, with all the information (Chema Casanova)
* Add the number of jobs submitted in
eone with more experience with the v3d driver (Emma,
Iago maybe?) I'll be definitely be ok merging that patch
I've checked this patch and I've been using these tracepoints.
They have been working properly.
Reviewed-by: Jose Maria Casanova Crespo
Regards,
Chema Casanova
On 5/2/21 13:28, Yukimasa Sugizaki wrote:
On 05/02/2021, Eric Anholt wrote:
On Thu, Feb 4, 2021 at 10:09 AM Chema Casanova
wrote:
On 3/9/20 18:48, Yukimasa Sugizaki wrote:
From: Yukimasa Sugizaki
The default timeout is 500 ms which is too short for some workloads
including Piglit
ed something such complex.
I think it would also make sense to increase our default value for the
compute jobs.
What do you think?
In any case I think that having this general scheduling timeout
parameter as other drivers do is a good idea.
Regards,
Chema Casanova
static struct
I've tested the patch and confirmed that applies correctly over drm-next.
I've also confirmed that the timeout happens with the described test
case by the developer.
https://github.com/raspberrypi/linux/pull/3816#issuecomment-682251862
Considering this is my first review of a patch in v3d ker
14 matches
Mail list logo
