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
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:
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
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
> >
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 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:
> >>>
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:
> >>
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
___
> + 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, 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
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
>
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
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
> >
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
#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...
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
$ 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
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
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.
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/
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
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
>
> 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
&
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
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
).
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
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
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:
> > >&
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 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
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 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:
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 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
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, 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:
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
> 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
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
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
t; + if (c->dev == dev && c->ops == ops) {
> + list_del(&c->node);
> + component = c;
> + break;
> + }
> +
> + if (component && component->master)
> + take_down_master(compon
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
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 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
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 -
>
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
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
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
_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
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
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
__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
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
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
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
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
--
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
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
> > 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
> > +
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:
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.
>
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:
>
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
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
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
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
_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
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
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
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
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.
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
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
> 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
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
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
= 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 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
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
_________
> 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
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
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
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
84 matches
Mail list logo
