On 9/13/20 9:37 PM, Dmitry Osipenko wrote:
13.09.2020 12:51, Mikko Perttunen пишет:
...
All waits that are internal to a job should only wait for relative sync
point increments. >
In the grate-kernel every job uses unique-and-clean sync point (which is
also internal to the kernel driver) and a r
05.09.2020 13:34, Mikko Perttunen пишет:
> + } else {
> + struct host1x_job *failed_job = job;
> +
> + host1x_job_dump(dev, job);
> +
> + host1x_syncpt_set_locked(job->syncpt);
> + failed_job->cancelled = true;
> +
> + list_for_each_en
12.09.2020 16:31, Mikko Perttunen пишет:
...
>> I'm now taking a closer look at this patch and it raises some more
>> questions, like for example by looking at the "On job timeout, we stop
>> the channel, NOP all future jobs on the channel using the same syncpoint
>> ..." through the prism of grate
13.09.2020 12:51, Mikko Perttunen пишет:
...
>> All waits that are internal to a job should only wait for relative sync
>> point increments. >
>> In the grate-kernel every job uses unique-and-clean sync point (which is
>> also internal to the kernel driver) and a relative wait [1] is used for
>> th
12.09.2020 01:11, Mikko Perttunen пишет:
> On 9/11/20 7:40 PM, Dmitry Osipenko wrote:
>> 05.09.2020 13:34, Mikko Perttunen пишет:
>>> + } else {
>>> + struct host1x_job *failed_job = job;
>>> +
>>> + host1x_job_dump(dev, job);
>>> +
>>> + host1x_syncpt_set_locked(job->syncpt
On 9/13/20 12:51 AM, Dmitry Osipenko wrote:
12.09.2020 16:31, Mikko Perttunen пишет:
...
I'm now taking a closer look at this patch and it raises some more
questions, like for example by looking at the "On job timeout, we stop
the channel, NOP all future jobs on the channel using the same syncpo
On 9/12/20 3:53 PM, Dmitry Osipenko wrote:
12.09.2020 01:11, Mikko Perttunen пишет:
On 9/11/20 7:40 PM, Dmitry Osipenko wrote:
05.09.2020 13:34, Mikko Perttunen пишет:
+ } else {
+ struct host1x_job *failed_job = job;
+
+ host1x_job_dump(dev, job);
+
+ host1x_syncpt_set
On 9/11/20 7:40 PM, Dmitry Osipenko wrote:
05.09.2020 13:34, Mikko Perttunen пишет:
+ } else {
+ struct host1x_job *failed_job = job;
+
+ host1x_job_dump(dev, job);
+
+ host1x_syncpt_set_locked(job->syncpt);
+ failed_job->cancelled =
Add a new property for jobs to enable or disable recovery i.e.
CPU increments of syncpoints to max value on job timeout. This
allows for a more solid model for hanged jobs, where userspace
doesn't need to guess if a syncpoint increment happened because
the job completed, or because job timeout was
