gt; bpf-prog attached to a cgroup. More inline.
If you have some pointers on this, I'm happy to do some reading and
learning too.
> On Wed, Feb 3, 2021 at 6:09 AM Daniel Vetter wrote:
> >
> > On Mon, Feb 01, 2021 at 11:51:07AM -0500, Kenny Ho wrote:
> > > On Mon, Feb 1,
On Mon, Feb 01, 2021 at 11:51:07AM -0500, Kenny Ho wrote:
> [Resent in plain text.]
>
> On Mon, Feb 1, 2021 at 9:49 AM Daniel Vetter wrote:
> > - there's been a pile of cgroups proposal to manage gpus at the drm
> > subsystem level, some by Kenny, and frankly
ork:
- inspecting ioctl arguments that need copying outside of the
driver/subsystem doing that copying is fundamentally racy
- there's been a pile of cgroups proposal to manage gpus at the drm
subsystem level, some by Kenny, and frankly this at least looks a bit
like a quick hack to sidestep the consensus process for that.
So once we push this into drivers it's not going to be a bpf hook anymore
I think.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, Oct 27, 2020 at 01:17:23PM +0100, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> Use the helper that checks for overflows internally instead of manually
> calculating the size of the new array.
>
> Signed-off-by: Bartosz Golaszewski
Acked-by: Daniel Vette
On Fri, Oct 09, 2020 at 12:49:44PM -0700, ira.we...@intel.com wrote:
> From: Ira Weiny
>
> These kmap() calls in the gpu stack are localized to a single thread.
> To avoid the over head of global PKRS updates use the new kmap_thread()
> call.
>
> Cc: David Airlie
>
? And use cross-module notifiers/calls
> > > > ? I did that with amdkfd and amdgpu/radeon a couple of years back. It
> > > > worked (that's the best thing I can say about it).
> > >
> > > That's fine with me.
> > >
> > > > The main problem with this "virtual bus" thing is that I'm not
> > > > familiar with it at all and from my experience I imagine it would take
> > > > a considerable time and effort to upstream this infrastructure work.
> > >
> > > It shouldn't be taking that long, but for some unknown reason, the
> > > original author of that code is sitting on it and not resending it. Go
> > > poke them through internal Intel channels to find out what the problem
> > > is, as I have no clue why a 200-300 line bus module is taking so long to
> > > get "right" :(
> > >
> > > I'm _ALMOST_ at the point where I would just do that work myself, but
> > > due to my current status with Intel, I'll let them do it as I have
> > > enough other things on my plate...
> > >
> > > > This could delay the NIC code for a couple of years, which by then
> > > > this won't be relevant at all.
> > >
> > > Why wouldn't this code be relevant in a year? It's going to be 2+ years
> > > before any of this shows up in an "enterprise distro" based on their
> > > release cycles anyway :)
> > >
> > > thanks,
> > >
> > > greg k-h
> >
> > Hi Greg,
> > ok, I'll take a look. Do you happen to have the name of the patch-set /
> > author ?
>
> Here's at least one copy:
>
> https://lore.kernel.org/linux-rdma/20200520070227.3392100-2-jeffrey.t.kirs...@intel.com/
>
> there might have been a newer one, can't remember, sorry.
Maybe I'm missing something or maybe the in-tree code we have already
should be refactored to use more buses and drivers, but
drivers/base/component.c is made for this. We use this to glue all kinds
of things across all kinds of subsystems already.
Of course it really should be only used for one-off problems, as soon as
you have a standard interface/interaction there should be some kind of
standard lookup way to get at your thing (and the driver behind it), e.g.
in drivers/gpu we're now building up drm_bridge and trying to get away
from componenent.c for these things.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
__
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
rry the fixup
for a while longer locally.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
intel-wired-...@lists.osuosl.org
> > > > Cc: netdev@vger.kernel.org
> > > > Signed-off-by: Chris Wilson
> > > > [Jani: bikeshed repainted]
> > > > Signed-off-by: Jani Nikula
> > >
> > > Jeff, please make sure this gets submitted to me soon.
> >
> > Expect it later tonight, just finishing up testing.
>
> Tested-by: Aaron Brown
Hm, I seem to be blind, but I can't find it anywhere in -rc6. Does someone
have the sha1 from Linus' git for this patch?
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Wed, May 31, 2017 at 5:08 PM, David Miller wrote:
> From: Daniel Vetter
> Date: Wed, 31 May 2017 08:10:45 +0200
>
>> On Wed, May 31, 2017 at 7:54 AM, Daniel Vetter
>> wrote:
>>> On Wed, May 31, 2017 at 1:06 AM, Dave Airlie wrote:
>>>> On
On Wed, May 31, 2017 at 7:54 AM, Daniel Vetter wrote:
> On Wed, May 31, 2017 at 1:06 AM, Dave Airlie wrote:
>> On 31 May 2017 at 08:10, David Miller wrote:
>>> From: Daniel Vetter
>>> Date: Tue, 30 May 2017 22:15:42 +0200
>>>
>>>> If the e
On Thu, Apr 13, 2017 at 04:05:18PM -0600, Logan Gunthorpe wrote:
> This is a single straightforward conversion from kmap to sg_map.
>
> Signed-off-by: Logan Gunthorpe
Acked-by: Daniel Vetter
Probably makes sense to merge through some other tree, but please be aware
of the considera
t; linux/genwqe
> linux/genwqe/.install
> linux/genwqe/genwqe_card.h
> linux/genwqe/..install.cmd
> linux/seg6.h
> linux/cifs
> linux/cifs/.install
> linux/cifs/cifs_mount.h
> linux/cifs/..install.cmd
> linux/auto_dev-ioctl.h
>
> Thanks to Julien Floret for
On Wed, Apr 20, 2016 at 11:27:27PM +0200, Luis R. Rodriguez wrote:
> On Wed, Apr 20, 2016 at 01:17:30PM +0200, Daniel Vetter wrote:
> > On Wed, Apr 20, 2016 at 11:10:54AM +0200, Luis R. Rodriguez wrote:
> > > Reason I ask is since I noticed a while ago a lot of drivers
>
uot;kick out firmware fb driver" out of fbdev, since we'd need it
to have a simple drm driver for e.g. uefi.
But I definitely don't want a legacy horror show like fbdev to
automagically take care of device mappings for drivers.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
16 matches
Mail list logo
