Hi Rodrigo,
On 10/4/2023 4:37 PM, Rodrigo Vivi wrote:
On Wed, Oct 04, 2023 at 03:54:59PM +0200, Nirmoy Das wrote:
Hi Rodrigo,
On 10/4/2023 2:44 PM, Rodrigo Vivi wrote:
On Wed, Oct 04, 2023 at 02:04:07PM +0200, Nirmoy Das wrote:
Take the mcr lock only when driver needs to write into a mcr
On Wed, Oct 04, 2023 at 03:54:59PM +0200, Nirmoy Das wrote:
> Hi Rodrigo,
>
> On 10/4/2023 2:44 PM, Rodrigo Vivi wrote:
> > On Wed, Oct 04, 2023 at 02:04:07PM +0200, Nirmoy Das wrote:
> > > Take the mcr lock only when driver needs to write into a mcr based
> > > tlb based registers.
> > >
> > >
Hi Rodrigo,
On 10/4/2023 2:44 PM, Rodrigo Vivi wrote:
On Wed, Oct 04, 2023 at 02:04:07PM +0200, Nirmoy Das wrote:
Take the mcr lock only when driver needs to write into a mcr based
tlb based registers.
To prevent GT reset interference, employ gt->reset.mutex instead, since
On Wed, Oct 04, 2023 at 02:04:07PM +0200, Nirmoy Das wrote:
> Take the mcr lock only when driver needs to write into a mcr based
> tlb based registers.
>
> To prevent GT reset interference, employ gt->reset.mutex instead, since
> intel_gt_mcr_multicast_write relies on gt->uncore->lock not being
Take the mcr lock only when driver needs to write into a mcr based
tlb based registers.
To prevent GT reset interference, employ gt->reset.mutex instead, since
intel_gt_mcr_multicast_write relies on gt->uncore->lock not being held.
v2: remove unused var, flags.
Signed-off-by: Nirmoy Das
---