On Fri, Jul 23, 2021 at 07:22:46PM +0200, Sam Ravnborg wrote:
> On Fri, Jul 23, 2021 at 10:57:56AM +0200, Daniel Vetter wrote:
> > On Fri, Jul 23, 2021 at 11:12:49AM +0800, lichenyang wrote:
> > > From: Chenyang Li
> > >
> > > This patch adds an initial
> + if (!lencoder)
> + return -ENOMEM;
> +
> + lencoder->lcrtc = ldev->mode_info[index].crtc;
> + lencoder->ldev = ldev;
> + encoder = &lencoder->base;
> + encoder->possible_crtcs = 1 << index;
> +
> + drm_encod
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
>
On Thu, Apr 30, 2020 at 03:37:31PM +0200, Daniel Vetter wrote:
> On Thu, Apr 30, 2020 at 11:36:14AM +0800, Xin Ji wrote:
> > On Tue, Apr 28, 2020 at 12:05:08PM +0200, Daniel Vetter wrote:
> > > On Fri, Apr 24, 2020 at 08:12:04PM +0800, Nicolas Boichat wrote:
> > > > O
On Thu, Apr 30, 2020 at 11:36:14AM +0800, Xin Ji wrote:
> On Tue, Apr 28, 2020 at 12:05:08PM +0200, Daniel Vetter wrote:
> > On Fri, Apr 24, 2020 at 08:12:04PM +0800, Nicolas Boichat wrote:
> > > On Fri, Apr 24, 2020 at 2:51 PM Xin Ji wrote:
> > > >
> > &g
> Right, understand your argument. I'm pondering if it's not just better
> to reject the mode rather than trying a timing that is definitely
> quite different from what the monitor was asking for. No super strong
> opinion, I'll let other people on the list weigh in.
Yeah
oid/ion/ion.c
> > > > +++ b/drivers/staging/android/ion/ion.c
> > >
> > > Now that we have the dma-buff stuff in the tree, do we even need the
> > > ion code in the kernel anymore? Can't we delete it now?
> > >
> >
> > I agree that we s
On Wed, Nov 20, 2019 at 09:39:11PM +0800, Krzysztof Kozlowski wrote:
> Adjust indentation from spaces to tab (+optional two spaces) as in
> coding style with command like:
> $ sed -e 's/^/\t/' -i */Kconfig
>
> Signed-off-by: Krzysztof Kozlowski
Acked-by:
There's no callers in-tree anymore.
For merging probably best to stuff this into drm-misc, since that's
where the dma-buf heaps will land too. And the resulting conflict
hopefully ensures that dma-buf heaps wont have a new ->kmap/unmap
implemenation.
Signed-off-by: Daniel Vett
#x27;m not following the details, and it seems a bit a
crawl, but there's definitely work going on ... Just probably not
in-place in staging I think.
-Daniel
>
> thanks,
>
> greg k-h
> _______
> dri-devel mailing list
> dri-de...
fault value.
>
> I'm actually perfectly fine going down any route, but this just seemed to me
> simplest and with the least risk of breaking anything. Opinions?
I think given all our discussions and plans the argument object makes tons
of sense. Much easier to document well than a l
On Fri, Apr 26, 2019 at 2:42 AM Aaro Koskinen wrote:
> On Fri, Jan 18, 2019 at 12:20:28PM +0100, Daniel Vetter wrote:
> > On Fri, Jan 18, 2019 at 11:08:28AM +0100, Greg Kroah-Hartman wrote:
> > > There has not been any real work done on cleaning this driver up and
> >
merged the
series to nuke the transitional helpers for good for 2.21/5.1. Worst case
we just need to pull this in as a topic branch, based on a sufficiently
old-enough kernel.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
O
n Tue, Oct 2, 2018 at 11:25 AM Hans de Goede wrote:
>
> Hi,
>
> On 02-10-18 00:01, Daniel Vetter wrote:
> > On Mon, Oct 1, 2018 at 11:14 PM Hans de Goede wrote:
> >>
> >> Hi,
> >>
> >> On 01-10-18 18:52, Daniel Vetter wrote:
> >>
On Mon, Oct 1, 2018 at 11:14 PM Hans de Goede wrote:
>
> Hi,
>
> On 01-10-18 18:52, Daniel Vetter wrote:
> > On Mon, Oct 01, 2018 at 11:37:29AM +0200, Hans de Goede wrote:
> >> Hi,
> >>
> >> On 01-10-18 09:53, Daniel Vetter wrote:
> >>>
On Mon, Oct 01, 2018 at 11:17:57AM +0200, Hans de Goede wrote:
> Hi,
>
> On 01-10-18 09:51, Daniel Vetter wrote:
> > On Wed, Sep 26, 2018 at 09:41:51PM +0200, Hans de Goede wrote:
> > > Hi All,
> > >
> > > This series converts the vboxvideo drive
On Mon, Oct 01, 2018 at 11:37:29AM +0200, Hans de Goede wrote:
> Hi,
>
> On 01-10-18 09:53, Daniel Vetter wrote:
> > On Wed, Sep 26, 2018 at 09:42:02PM +0200, Hans de Goede wrote:
> > > Atomic modesetting does not use the traditional dpms call backs, instead
> >
vbox_crtc_atomic_flush,
> @@ -861,7 +838,6 @@ static const struct drm_connector_helper_funcs
> vbox_connector_helper_funcs = {
> };
>
> static const struct drm_connector_funcs vbox_connector_funcs = {
> - .dpms = drm_helper_connector_dpms,
> .detect = vbo
ply with that (I can do it locally, but
that doesn't allow me to conveniently reply&comment).
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
devel mailing list
de...@linuxdriverproject.org
http:
ed all these drivers to ensure that all ioctl arguments
> are used as pointers or are ignored, but are not interpreted as integer
> values.
>
> Signed-off-by: Arnd Bergmann
Acked-by: Daniel Vetter
At least for the drm and dma-buf bits.
-Daniel
> ---
> drivers/android/bin
31 insertions(+), 3 deletions(-)
>
> --
> 2.7.4
>
> ___
> 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.ffwl
On Wed, Jun 20, 2018 at 08:52:19PM +0200, Christian König wrote:
> Fixup for "dma_buf: remove device parameter from attach callback v2".
>
> I missed this driver, sorry for the noise. Patch is not even compile
> tested.
>
> Signed-off-by: Christian König
Revie
On Wed, Apr 4, 2018 at 4:30 PM, Greg Kroah-Hartman
wrote:
> On Wed, Apr 04, 2018 at 07:17:39AM -0700, Laura Abbott wrote:
>> On 04/04/2018 03:30 AM, Daniel Vetter wrote:
>> > Most of the other cross-driver gfx infrastructure (dma_buf, dma_fence)
>> > also gets cross pos
ri-de...@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org (moderated for non-subscribers)
Cc: Greg Kroah-Hartman
Signed-off-by: Daniel Vetter
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 555db72d4eb7..d43cdfca3eb5 100644
--- a/MAINTAINERS
+++ b/MAINTA
On Mon, Feb 19, 2018 at 10:18:21AM -0800, Laura Abbott wrote:
> On 02/19/2018 07:31 AM, Daniel Vetter wrote:
> > On Thu, Feb 15, 2018 at 05:24:45PM -0800, Laura Abbott wrote:
> > > Ion is designed to be a framework used by other clients who perform
> > > operations on t
t)
> + printf("sync start failed %d\n", errno);
> +
> + memset(info.buffer, 0xff, 4096);
> +
> + sync.flags = DMA_BUF_SYNC_END | DMA_BUF_SYNC_RW;
> + ret = ioctl(info.buffd, DMA_BUF_IOCTL_SYNC, &sync);
> + if (ret)
> + prin
$ mdfrm -c ~/mail/todo/
> 1523 messages in /home/gregkh/mail/todo/
>
> Please give me a chance to catch up...
commit model ftw, we have 400+ patches for 4.16 already merged and tested
and all ready, right when -rc1 gets tagged. Makes the merge window the
most relaxed time o
o makes it a root-only interface.
Distros really hate that, because it makes unpriviledged X/wayland really
hard to pull of. Passing a device file otoh from logind to the compositor
is dead simple (and how X et al get at e.g. the drm/input devices
already).
Adding some links from devices to co
_________
> 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
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
go in through
drm-misc I think (I don't want to be at Greg's mercy for merging cleanups,
same way we don't wait for driver maintainers if they don't merge the
patch in a timely fashion).
I'd say if no one is actually working on vbox cleanup (i.e. porting to
atomic) we'll throw it out next cycle again.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
On Tue, Aug 08, 2017 at 01:54:52PM +0200, Peter Rosin wrote:
> On 2017-08-07 11:21, Daniel Vetter wrote:
> > On Fri, Aug 04, 2017 at 12:45:06PM +0200, Peter Rosin wrote:
> >> The redundant fb helpers .load_lut, .gamma_set and .gamma_get are
> >> no longer used. Remove
= vbox_crtc_disable,
> - .load_lut = vbox_crtc_load_lut,
> .prepare = vbox_crtc_prepare,
> .commit = vbox_crtc_commit,
> };
> --
> 2.11.0
>
> ___
> dri-devel mailing list
> dri-de...@lists.fr
On Wed, Aug 2, 2017 at 3:47 PM, Cihangir Akturk wrote:
> On Wed, Aug 02, 2017 at 02:38:50PM +0200, Daniel Vetter wrote:
>> On Wed, Aug 2, 2017 at 1:46 AM, Cihangir Akturk wrote:
>> > drm_gem_object_unreference is a compatibility alias for drm_gem_object_put
>> > so
boxvideo/vbox_main.c
> +++ b/drivers/staging/vboxvideo/vbox_main.c
> @@ -525,7 +525,7 @@ vbox_dumb_mmap_offset(struct drm_file *file,
> bo = gem_to_vbox_bo(obj);
> *offset = vbox_bo_mmap_offset(bo);
>
> - drm_gem_object_unreference(obj);
> + drm_gem_object
> Cc: "Rafael J. Wysocki"
> Cc: Len Brown
> Cc: Lucas Stach
> Cc: Russell King
> Cc: Christian Gmeiner
> Cc: David Airlie
> Cc: Patrik Jakobsson
> Cc: Daniel Vetter
> Cc: Jani Nikula
> Cc: Ben Skeggs
> Cc: Darren Hart
> Cc: Andy Shevchenko
> C
undefined!
>>>> ERROR: "unregister_framebuffer" [drivers/staging/vboxvideo/vboxvideo.ko]
>>>> undefined!
>
>
> Hmm, this is likely caused by building with a Kconfig with FBDEV disabled.
>
> The attached patch should fix this. I will send out a v5 wit
onflicts.)
>
> [1] https://www.spinics.net/lists/target-devel/msg15070.html
>
> Signed-off-by: Logan Gunthorpe
> Reviewed-by: Sinclair Yeh
Acked-by: Daniel Vetter
Probably simplest if we pull this in through the drm-misc tree for 4.12.
Can we have an ack for the v4l side
ltiple nodes (e.g. /dev/ion/heap0)
> + - Better test framework (integration with VGEM was suggested)
Found another one: Integrate the ion kernel-doc into
Documenation/gpu/ion.rst and link it up within Documenation/gpu/index.rst.
There's a lot of api and overview stuff already around, w
he dma-buf debugfs stuff (maybe with an allocator
callback to dump additional data) is the better option.
Acked-by: Daniel Vetter
> ---
> drivers/staging/android/ion/ion-ioctl.c | 53 +--
> drivers/staging/android/ion/ion.c | 701
> ++--
> drivers
ings up while everyone is busy converting things over anyway. As part
> of this, also remove the useless alignment field from the allocation
> structure.
>
> Signed-off-by: Laura Abbott
Reviewed-by: Daniel Vetter
> ---
> drivers/staging/android/ion/Makefile | 3 -
>
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
KERN_INFO "N_HDLC: line discipline unregistered\n";
> -static char hdlc_unregister_fail[] __exitdata =
> +static const char hdlc_unregister_fail[] __exitdata =
> KERN_ERR "N_HDLC: can't unregister line discipline (err = %d)\n";
>
> static void __exit n_h
On Sun, Mar 12, 2017 at 2:34 PM, Benjamin Gaignard
wrote:
> 2017-03-09 18:38 GMT+01:00 Laura Abbott :
>> On 03/09/2017 02:00 AM, Benjamin Gaignard wrote:
>>> 2017-03-06 17:04 GMT+01:00 Daniel Vetter :
>>>> On Mon, Mar 06, 2017 at 11:58:05AM +0100, Mark Brown wrote:
At least from the unix device memory allocator pov it's probably simpler
to encode stuff like this into the heap name, instead of having to pass
heap + list of additional properties/constraints.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
On Mon, Mar 06, 2017 at 11:58:05AM +0100, Mark Brown wrote:
> On Mon, Mar 06, 2017 at 11:40:41AM +0100, Daniel Vetter wrote:
>
> > No one gave a thing about android in upstream, so Greg KH just dumped it
> > all into staging/android/. We've discussed ION a bunch of times
On Mon, Mar 06, 2017 at 05:02:05PM +0200, Laurent Pinchart wrote:
> Hi Daniel,
>
> On Monday 06 Mar 2017 11:38:20 Daniel Vetter wrote:
> > On Fri, Mar 03, 2017 at 06:45:40PM +0200, Laurent Pinchart wrote:
> > > - I haven't seen any proposal how a heap-base
On Mon, Mar 06, 2017 at 03:43:53PM +0200, Laurent Pinchart wrote:
> Hi Daniel,
>
> On Monday 06 Mar 2017 11:32:04 Daniel Vetter wrote:
> > On Fri, Mar 03, 2017 at 10:50:20AM -0800, Laura Abbott wrote:
> > > On 03/03/2017 08:41 AM, Laurent Pinchart wrote:
> > >&
n here, can you
> > clarify?
>
> There must have been a reason why this code ended up in the staging
> tree, right? So my question is what those reasons were and how they were
> handled in order to move the code from the staging subtree.
No one gave a thing about android in upstream, so Greg KH just dumped it
all into staging/android/. We've discussed ION a bunch of times, recorded
anything we'd like to fix in staging/android/TODO, and Laura's patch
series here addresses a big chunk of that.
This is pretty much the same approach we (gpu folks) used to de-stage the
syncpt stuff.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
).
Again I think waiting for this to be fully implemented before we merge any
part is going to just kill any upstreaming efforts. ION in itself, without
the full buffer negotiation dance seems clearly useful (also for stuff
like SMA), and having it merged will help with moving the buffer
allocation
ctly sure why/how arm-soc
ecosystem ended up focused so much on dma_alloc_coherent.
I think separating allocation from dma mapping/coherency is perfectly
fine, and the way to go.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
On Fri, Mar 03, 2017 at 10:46:03AM -0800, Laura Abbott wrote:
> On 03/03/2017 08:39 AM, Laurent Pinchart wrote:
> > Hi Daniel,
> >
> > On Friday 03 Mar 2017 10:56:54 Daniel Vetter wrote:
> >> On Thu, Mar 02, 2017 at 01:44:38PM -0800, Laura Abbott wrote:
> &g
>
> Signed-off-by: Laura Abbott
It looks like with this we could remove a lot of the EXPORT_SYMBOL
statements from the ion code. Might be good to follow up with a patch to
clean those out.
Otherwise a patch that only removes code, what's not to love!
Reviewed-by: Daniel Vetter
&
return PTR_ERR(internal_dev);
> +
> + ion_add_system_heap();
> + ion_add_system_contig_heap();
> +
> + ion_add_cma_heaps();
> + return 0;
> +}
> +subsys_initcall(ion_enumerate);
If we'd split each heap into its own file I think we could just put
initcalls into each of them, avoiding the need for so much #ifdef all
over.
That should also help when we add more specific heaps like the SMA one.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
On Fri, Mar 03, 2017 at 11:04:33AM +0100, Daniel Vetter wrote:
> On Thu, Mar 02, 2017 at 01:44:32PM -0800, Laura Abbott wrote:
> > Hi,
> >
> > There's been some recent discussions[1] about Ion-like frameworks. There's
> > apparently interest in just keepin
A_HEAP
> struct ion_heap *ion_cma_heap_create(struct ion_platform_heap *data);
> void ion_cma_heap_destroy(struct ion_heap *heap);
> +#else
> +static inline struct ion_heap *ion_cma_heap_create(
> + struct ion_platform_heap *data)
> +{
> + return E
e 100644 drivers/staging/android/ion/ion_enumerate.c
> delete mode 100644 drivers/staging/android/ion/ion_of.c
> delete mode 100644 drivers/staging/android/ion/ion_of.h
> delete mode 100644 drivers/staging/android/ion/tegra/Makefile
> delete mode 100644 drivers/staging/android/ion/tegra/
an up the uapi headers we'll be mostly fine.
would allow us to remove compat_ion.c entirely.
- ION_IOC_IMPORT: With this ion is purely an allocator, so not sure we
still need to be able to import anything. All the cache flushing/mapping
is done through dma-buf ops/ioctls.
l fences. What it really tests is the fence
interface (which is public in the uapi headers and all that), but to be
able to do that we need some (hw-independent way) to expose fences, which
this provides.
Long term we might even do this as a proper interface (with some
restrictions to make it safe and
atches are at the bottom of my priority list, sorry.
fwiw on the patch series:
Reviewed-by: Daniel Vetter
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.
the internal interfaces
anyway, but let's get this started.
Had some real nitpicks on the docs patch, but that can also be merged
later on imo. Except for that patch, on the series:
Reviewed-by: Daniel Vetter
>
> Thanks,
>
> Gustavo
>
> ---
> Gustavo Padovan (1
caller pass the name and the out-fence and gets back the sync_file. That
> is
> +just the first step, next it needs to install an fd on sync_file->file. So it
> +gets an fd:
> +
> + fd = get_unused_fd_flags(O_CLOEXEC);
> +
> +and installs it on sync_file->file:
>
fences fds back in
> the drm_atomic_ioctl() as an out arg in the out_fences_ptr field.
>
> struct drm_out_fences {
> __u32 crtc_id;
> __u32 fd;
> };
>
> v2: Comment by Rob Clark:
> - Squash commit that adds DRM_MODE_ATOMIC_OUT_FENCE flag here.
>
changes needed to any driver besides supporting fences.
>
> fence_collection's fence doesn't belong to any timeline context, so
> fence_is_later() and fence_later() are not meant to be called with
> fence_collections fences.
>
> v2: Comments by Daniel Vetter:
> > drivers/dma-buf/fence.c | 2 +-
> > drivers/dma-buf/sync_file.c | 60 +
> > drivers/gpu/drm/Kconfig | 1 +
> > drivers/gpu/drm/drm_atomic.c | 196
> > +
On Thu, Apr 21, 2016 at 12:38:49PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> This function had copies in 3 different files. Unify them in kernel.h.
>
> Cc: Joe Perches
> Cc: Andrew Morton
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Rob Clar
On Mon, Mar 21, 2016 at 01:26:58PM +0100, David Herrmann wrote:
> Hi
>
> On Mon, Mar 21, 2016 at 8:51 AM, Daniel Vetter wrote:
> > Just a bit of wording polish plus mentioning that it can fail and must
> > be restarted.
> >
> > Requested by Sumit.
> >
&g
access, even when there are
>
> "Userspace cannot on coherent access"? Do you mean "cannot do"? Sorry, the
> meaning isn't clear to me.
"cannot rely on". I'll send out v2 asap (and let's hope the coffee
works this time around).
-Daniel
--
Just a bit of wording polish plus mentioning that it can fail and must
be restarted.
Requested by Sumit.
v2: Fix them typos (Hans).
Cc: Chris Wilson
Cc: Tiago Vignatti
Cc: Stéphane Marchesin
Cc: David Herrmann
Cc: Sumit Semwal
Cc: Daniel Vetter
CC: linux-me...@vger.kernel.org
Cc: dri-de
Just a bit of wording polish plus mentioning that it can fail and must
be restarted.
Requested by Sumit.
Cc: Chris Wilson
Cc: Tiago Vignatti
Cc: Stéphane Marchesin
Cc: David Herrmann
Cc: Sumit Semwal
Cc: Daniel Vetter
CC: linux-me...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc
ixes a coherency issue for i915.ko as well as reducing the
> uninterruptible hold upon its BKL, the struct_mutex.
>
> Fixes commit c11e391da2a8fe973c3c2398452000bed505851e
> Author: Daniel Vetter
> Date: Thu Feb 11 20:04:51 2016 -0200
>
> dma-buf: Add ioctls to allow
__user *p)
> u64 user_ptr_to_u64(void __user *p)
>
> Maybe there's something about 32 bit userspace on
> 64 OS that should be done too.
Tbh I really don't think we should add 32bit variants and encourage the
mispractice of having 32bit user ptrs in ioctl structs and stuff. Anyway,
just my bikeshed on top ;-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
e amounts of additional stuff.
Is that reasonable ok for you, or do you insist we do a fences2.h without
going through staging ? ;-)
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
ing like:
>
> num_fences = min(info.num_fences, sync->num_fences);
> struct sync_fence_info array[num_fences];
>
> info.num_fences = sync->num_fences;
> if (num_fences &&
> copy_to_user((void * __user)(unsigned long)info.sync_fence_in
this light cleanup would be nice.
Wrt keeping SYNC_WAIT: I think that's totally fine. Redundant since
polling is supported, but not really an issue imo either. If we're totally
lazy we could implement SYNC_WAIT internally using poll and shave off a
few lines of the implementation.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
_name()
> >> This is misleading. I think timeline_fence prefix would be more
> >> appropriate here.
> > Why? These fence_default_.. functions are fence_ops and not related to
> > fence_timeline in any way.
> Because they're using fence_parent, which should probabl
On Tue, Jan 19, 2016 at 06:10:40PM -0200, Gustavo Padovan wrote:
> 2016-01-19 Daniel Vetter :
> > - get_timeline_name and get_driver_name are imo too much indirection, just
> > add ->(drv_)name field to each of these.
>
> I don't think is a good idea to change that
On Tue, Jan 19, 2016 at 03:52:26PM -0200, Gustavo Padovan wrote:
> 2016-01-19 John Harrison :
>
> > On 19/01/2016 15:23, Gustavo Padovan wrote:
> > >Hi Daniel,
> > >
> > >2016-01-19 Daniel Vetter :
> > >
> > >>On Fri, Jan 15, 2016 at 1
dma-buf/sync.c
> create mode 100644 drivers/dma-buf/sync_debug.c
> delete mode 100644 drivers/staging/android/sw_sync.c
> delete mode 100644 drivers/staging/android/sync.c
> delete mode 100644 drivers/staging/android/sync.h
> delete mode 100644 dri
gt;
> Unfortunately this board does not run upsrteam just yet, but looking
> at the sync driver and fence code we are pretty much in sync with
> upstream.
Just to check: Is that with a proper hw driver, or using SW_SYNC? The
later will get removed in upstream since i
On Tue, Dec 15, 2015 at 11:08:01AM -0800, Dmitry Torokhov wrote:
> On Tue, Dec 15, 2015 at 11:00 AM, Gustavo Padovan wrote:
> > 2015-12-15 Daniel Vetter :
> >
> >> On Mon, Dec 14, 2015 at 05:29:55PM -0800, Dmitry Torokhov wrote:
> >> > Userspace can close t
_driver_name)(struct fence *fence);
> const char * (*get_timeline_name)(struct fence *fence);
> bool (*enable_signaling)(struct fence *fence);
> + void (*disable_signaling)(struct fence *fence);
> bool (*signaled)(struct fence *fence);
> signed long (*wait)(struct
e_valid’:
> > > drivers/staging/imx-drm/imx-tve.c:252:6: warning: unused variable ‘ret’
> > > [-Wunused-variable]
> >
> > It doesn't apply to my tree :(
>
> Yeah, commit f9b0e251dfbf 'drm: make mode_valid callback optional' is
> in the drm tree, s
would like to see patches 1-5 scheduled for the next merge window,
> with 6-8 for the following window - this gives us grace of one kernel
> cycle to ensure that any new component helper users are properly
> converted.
Afaict the actual patches haven't made it to dri-devel, only to
linux-a
t; + if (c->dev == dev && c->ops == ops) {
> + list_del(&c->node);
> + component = c;
> + break;
> + }
> +
> + if (component && component->master)
> + take_down_master(compon
84 matches
Mail list logo
