On Fri, 1 Jul 2022 08:56:53 +0100
Tvrtko Ursulin wrote:
> On 30/06/2022 17:01, Mauro Carvalho Chehab wrote:
> > Em Thu, 30 Jun 2022 09:12:41 +0100
> > Tvrtko Ursulin escreveu:
> >
> >> On 30/06/2022 08:32, Mauro Carvalho Chehab wrote:
> >>> Em Wed, 29 Jun 2022 17:02:59 +0100
> >>> Tvrtko
On 30/06/2022 17:01, Mauro Carvalho Chehab wrote:
Em Thu, 30 Jun 2022 09:12:41 +0100
Tvrtko Ursulin escreveu:
On 30/06/2022 08:32, Mauro Carvalho Chehab wrote:
Em Wed, 29 Jun 2022 17:02:59 +0100
Tvrtko Ursulin escreveu:
On 29/06/2022 16:30, Mauro Carvalho Chehab wrote:
On Tue, 28
Em Thu, 30 Jun 2022 09:12:41 +0100
Tvrtko Ursulin escreveu:
> On 30/06/2022 08:32, Mauro Carvalho Chehab wrote:
> > Em Wed, 29 Jun 2022 17:02:59 +0100
> > Tvrtko Ursulin escreveu:
> >
> >> On 29/06/2022 16:30, Mauro Carvalho Chehab wrote:
> >>> On Tue, 28 Jun 2022 16:49:23 +0100
> >>>
On 30/06/2022 08:32, Mauro Carvalho Chehab wrote:
Em Wed, 29 Jun 2022 17:02:59 +0100
Tvrtko Ursulin escreveu:
On 29/06/2022 16:30, Mauro Carvalho Chehab wrote:
On Tue, 28 Jun 2022 16:49:23 +0100
Tvrtko Ursulin wrote:
.. which for me means a different patch 1, followed by patch 6
Em Wed, 29 Jun 2022 17:02:59 +0100
Tvrtko Ursulin escreveu:
> On 29/06/2022 16:30, Mauro Carvalho Chehab wrote:
> > On Tue, 28 Jun 2022 16:49:23 +0100
> > Tvrtko Ursulin wrote:
> >
> >> .. which for me means a different patch 1, followed by patch 6 (moved
> >> to be patch 2) would be ideal
On 29/06/2022 16:30, Mauro Carvalho Chehab wrote:
On Tue, 28 Jun 2022 16:49:23 +0100
Tvrtko Ursulin wrote:
.. which for me means a different patch 1, followed by patch 6 (moved
to be patch 2) would be ideal stable material.
Then we have the current patch 2 which is open/unknown (to me at
On Tue, 28 Jun 2022 16:49:23 +0100
Tvrtko Ursulin wrote:
>.. which for me means a different patch 1, followed by patch 6 (moved
> to be patch 2) would be ideal stable material.
>
> Then we have the current patch 2 which is open/unknown (to me at least).
>
> And the rest seem like
Hi,
On 27/06/2022 10:00, Mauro Carvalho Chehab (by way of Mauro Carvalho
Chehab ) wrote:
Hi Tvrtko,
On Fri, 24 Jun 2022 09:34:21 +0100
Tvrtko Ursulin wrote:
On 23/06/2022 12:17, Andi Shyti wrote:
Hi Mauro,
On Wed, Jun 15, 2022 at 04:27:39PM +0100, Mauro Carvalho Chehab wrote:
From:
Hi Tvrtko,
On Fri, 24 Jun 2022 09:34:21 +0100
Tvrtko Ursulin wrote:
> On 23/06/2022 12:17, Andi Shyti wrote:
> > Hi Mauro,
> >
> > On Wed, Jun 15, 2022 at 04:27:39PM +0100, Mauro Carvalho Chehab wrote:
> >> From: Chris Wilson
> >>
> >> Don't allow two engines to be reset in parallel, as
On 23/06/2022 12:17, Andi Shyti wrote:
Hi Mauro,
On Wed, Jun 15, 2022 at 04:27:39PM +0100, Mauro Carvalho Chehab wrote:
From: Chris Wilson
Don't allow two engines to be reset in parallel, as they would both
try to select a reset bit (and send requests to common registers)
and wait on that
Hi Mauro,
On Wed, Jun 15, 2022 at 04:27:39PM +0100, Mauro Carvalho Chehab wrote:
> From: Chris Wilson
>
> Don't allow two engines to be reset in parallel, as they would both
> try to select a reset bit (and send requests to common registers)
> and wait on that register, at the same time.
On 15/06/2022 16:27, Mauro Carvalho Chehab wrote:
From: Chris Wilson
Don't allow two engines to be reset in parallel, as they would both
try to select a reset bit (and send requests to common registers)
and wait on that register, at the same time. Serialize control of
the reset requests/acks
From: Chris Wilson
Don't allow two engines to be reset in parallel, as they would both
try to select a reset bit (and send requests to common registers)
and wait on that register, at the same time. Serialize control of
the reset requests/acks using the uncore->lock, which will also ensure
that
13 matches
Mail list logo
