Re: [Intel-gfx] [PATCH 1/2] eventfd: simplify eventfd_signal()

/* already in OOM ? */ > if (memcg->under_oom) > - eventfd_signal(eventfd, 1); > + eventfd_signal(eventfd); > spin_unlock(_oom_lock); > > return 0; > @@ -4791,7 +4791,7 @@ static void memcg_event_remove(struct work_struct *work) > event->unregister_event(memcg, event->eventfd); > > /* Notify userspace the event is going away. */ > - eventfd_signal(event->eventfd, 1); > + eventfd_signal(event->eventfd); > > eventfd_ctx_put(event->eventfd); > kfree(event); > diff --git a/mm/vmpressure.c b/mm/vmpressure.c > index b52644771cc4..ba4cdef37e42 100644 > --- a/mm/vmpressure.c > +++ b/mm/vmpressure.c > @@ -169,7 +169,7 @@ static bool vmpressure_event(struct vmpressure *vmpr, > continue; > if (level < ev->level) > continue; > - eventfd_signal(ev->efd, 1); > + eventfd_signal(ev->efd); > ret = true; > } > mutex_unlock(>events_lock); > diff --git a/samples/vfio-mdev/mtty.c b/samples/vfio-mdev/mtty.c > index a60801fb8660..5edcf8d738de 100644 > --- a/samples/vfio-mdev/mtty.c > +++ b/samples/vfio-mdev/mtty.c > @@ -1028,9 +1028,9 @@ static int mtty_trigger_interrupt(struct mdev_state > *mdev_state) > } > > if (mdev_state->irq_index == VFIO_PCI_MSI_IRQ_INDEX) > - ret = eventfd_signal(mdev_state->msi_evtfd, 1); > + ret = eventfd_signal(mdev_state->msi_evtfd); > else > - ret = eventfd_signal(mdev_state->intx_evtfd, 1); > + ret = eventfd_signal(mdev_state->intx_evtfd); > > #if defined(DEBUG_INTR) > pr_info("Intx triggered\n"); > diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c > index 89912a17f5d5..c0e230f4c3e9 100644 > --- a/virt/kvm/eventfd.c > +++ b/virt/kvm/eventfd.c > @@ -61,7 +61,7 @@ static void irqfd_resampler_notify(struct > kvm_kernel_irqfd_resampler *resampler) > > list_for_each_entry_srcu(irqfd, >list, resampler_link, > > srcu_read_lock_held(>kvm->irq_srcu)) > - eventfd_signal(irqfd->resamplefd, 1); > + eventfd_signal(irqfd->resamplefd); > } > > /* > @@ -786,7 +786,7 @@ ioeventfd_write(struct kvm_vcpu *vcpu, struct > kvm_io_device *this, gpa_t addr, > if (!ioeventfd_in_range(p, addr, len, val)) > return -EOPNOTSUPP; > > - eventfd_signal(p->eventfd, 1); > + eventfd_signal(p->eventfd); > return 0; > } > > > -- > 2.34.1 > For habanalabs (device.c): Reviewed-by: Oded Gabbay

Re: [Intel-gfx] [RFC PATCH 00/20] Initial Xe driver submission

On Fri, Feb 17, 2023 at 10:51 PM Daniel Vetter wrote: > > Hi all, > > [I thought I've sent this out earlier this week, but alas got stuck, kinda > bad timing now since I'm out next week but oh well] > > So xe is a quite substantial thing, and I think we need a clear plan how to > land > this or

Re: [Intel-gfx] [PATCH 0/1] drm: Add a gpu page-table walker

On Thu, Feb 23, 2023 at 8:50 PM Alex Deucher wrote: > > On Thu, Feb 23, 2023 at 10:03 AM Thomas Hellström > wrote: > > > > Hi, Daniel, > > > > On 2/16/23 21:18, Daniel Vetter wrote: > > > On Thu, Feb 16, 2023 at 05:27:28PM +0100, Thomas Hellström wrote: > > >> A slightly unusual cover letter for

Re: [Intel-gfx] linux-next: manual merge of the accel tree with the drm-misc tree

On Fri, Jan 20, 2023 at 2:32 AM Stephen Rothwell wrote: > > Hi all, > > Today's linux-next merge of the accel tree got conflicts in: > > drivers/Makefile > drivers/accel/Kconfig > drivers/accel/Makefile > > between commit: > > 35b137630f08 ("accel/ivpu: Introduce a new DRM driver for

Re: [Intel-gfx] [PATCH v5 1/3] drm: Use XArray instead of IDR for minors

On Mon, Nov 7, 2022 at 6:20 PM Matthew Wilcox wrote: > > On Sun, Nov 06, 2022 at 04:51:39PM +0200, Oded Gabbay wrote: > > I tried executing the following code in a dummy driver I wrote: > > You don't need to write a dummy driver; you can write test-cases > entirely in user

Re: [Intel-gfx] [PATCH v5 1/3] drm: Use XArray instead of IDR for minors

On Wed, Nov 2, 2022 at 4:23 PM Oded Gabbay wrote: > > On Mon, Sep 12, 2022 at 12:17 AM Michał Winiarski > wrote: > > > > IDR is deprecated, and since XArray manages its own state with internal > > locking, it simplifies the locking on DRM side. > > Additionall

Re: [Intel-gfx] [PATCH v5 1/3] drm: Use XArray instead of IDR for minors

On Mon, Sep 12, 2022 at 12:17 AM Michał Winiarski wrote: > > IDR is deprecated, and since XArray manages its own state with internal > locking, it simplifies the locking on DRM side. > Additionally, don't use the IRQ-safe variant, since operating on drm > minor is not done in IRQ context. > >

Re: [Intel-gfx] [PATCH 3/3] misc/habalabs: don't set default fence_ops->wait

On Wed, May 20, 2020 at 9:05 PM Daniel Vetter wrote: > > On Thu, May 14, 2020 at 02:38:38PM +0300, Oded Gabbay wrote: > > On Tue, May 12, 2020 at 9:12 AM Daniel Vetter > > wrote: > > > > > > On Tue, May 12, 2020 at 4:14 AM Dave Airlie wrote: > > >

Re: [Intel-gfx] [PATCH 3/3] misc/habalabs: don't set default fence_ops->wait

On Tue, May 12, 2020 at 9:12 AM Daniel Vetter wrote: > > On Tue, May 12, 2020 at 4:14 AM Dave Airlie wrote: > > > > On Mon, 11 May 2020 at 19:37, Oded Gabbay wrote: > > > > > > On Mon, May 11, 2020 at 12:11 PM Daniel Vetter > > > wrote: &

Re: [Intel-gfx] [PATCH 3/3] misc/habalabs: don't set default fence_ops->wait

On Mon, May 11, 2020 at 12:36 PM Oded Gabbay wrote: > > On Mon, May 11, 2020 at 12:11 PM Daniel Vetter wrote: > > > > It's the default. > Thanks for catching that. > > > > > Also so much for "we're not going to tell the graphics people how to > >

Re: [Intel-gfx] [PATCH 3/3] misc/habalabs: don't set default fence_ops->wait

Signed-off-by: Daniel Vetter > Cc: Greg Kroah-Hartman > Cc: Olof Johansson > Cc: Oded Gabbay > Cc: Sumit Semwal > Cc: linux-me...@vger.kernel.org > Cc: linaro-mm-...@lists.linaro.org > --- > drivers/misc/habanalabs/command_submission.c | 1 - > 1 file changed, 1 del

Re: [Intel-gfx] Possible use_mm() mis-uses

On Wed, Aug 22, 2018 at 10:58 PM Linus Torvalds wrote: > > On Wed, Aug 22, 2018 at 12:37 PM Oded Gabbay wrote: > > > > Having said that, I think we *are* protected by the mmu_notifier > > release because if the process suddenly dies, we will gracefully clean > > th

Re: [Intel-gfx] Possible use_mm() mis-uses

On Wed, Aug 22, 2018 at 7:44 PM Linus Torvalds wrote: > One of the complex ones is the amdgpu driver. It does a > "use_mm(mmptr)" deep deep in the guts of a macro that ends up being > used in fa few places, and it's very hard to tell if it's right. > > It looks almost certainly buggy (there is no

Re: [Intel-gfx] [drm-tip:drm-tip 15/1373] arch/frv/include/asm/pgalloc.h:48:2: error: implicit declaration of function 'pgtable_page_dtor'; did you mean 'pgdat_page_nr'?

Hi, There is a missing #include at amdgpu_amdkfd.h I'll send a patch to Dave to apply to his drm-next tree to fix this. Thanks for catching this, Oded On Thu, Mar 15, 2018 at 4:50 AM, kbuild test robot wrote: > tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip >

Re: [Intel-gfx] [PATCH 01/10] drm/amd-kfd: Clean up inline handling

On Tue, Jun 21, 2016 at 12:10 PM, Daniel Vetter <daniel.vet...@ffwll.ch> wrote: > - inline functions need to be static inline, otherwise gcc can opt to > not inline and the linker gets unhappy. > - no forward decls for inline functions, just include the right headers. >

Re: [Intel-gfx] [PATCH 0/7] Enable SVM for Intel VT-d

On Sat, Oct 10, 2015 at 4:17 PM, David Woodhouse wrote: > > On Fri, 2015-10-09 at 00:50 +0100, David Woodhouse wrote: > > This patch set enables PASID support for the Intel IOMMU, along with > > page request support. > > > > Like its AMD counterpart, it exposes an