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
it(ldev->dev, encoder, _encoder_funcs,
> + DRM_MODE_ENCODER_DAC, NULL);
Please use the drmm_encoder version here too.
> +
> + ldev->mode_info[index].encoder = lencoder;
> +
> + return 0;
> +}
> diff --git a/drivers/gpu/drm/loongson/loongson_plane.c
> b/drivers/gpu/drm/loongson/loongson_plane.c
> new file mode 100644
> index ..679d6981fece
> --- /dev/null
> +++ b/drivers/gpu/drm/loongson/loongson_plane.c
> @@ -0,0 +1,97 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +
> +#include "loongson_drv.h"
> +
> +static void loongson_plane_atomic_update(struct drm_plane *plane,
> + struct drm_atomic_state *state)
> +{
> + struct loongson_crtc *lcrtc;
> + struct loongson_device *ldev;
> + struct drm_plane_state *lstate = plane->state;
> + u32 gpu_addr = 0;
> + u32 fb_addr = 0;
> + u32 reg_val = 0;
> + u32 reg_offset;
> + u32 pitch;
> + u8 depth;
> + u32 x, y;
> +
> + if (!lstate->crtc || !lstate->fb)
> + return;
> +
> + pitch = lstate->fb->pitches[0];
> + lcrtc = to_loongson_crtc(lstate->crtc);
> + ldev = lcrtc->ldev;
> + reg_offset = lcrtc->reg_offset;
> + x = lstate->crtc->x;
> + y = lstate->crtc->y;
> + depth = lstate->fb->format->cpp[0] << 3;
> +
> + gpu_addr = loongson_gpu_offset(lstate, ldev);
> + reg_val = (pitch + 255) & ~255;
> + ls7a_mm_wreg(ldev, FB_STRI_REG + reg_offset, reg_val);
> +
> + switch (depth) {
> + case 12 ... 16:
> + fb_addr = gpu_addr + y * pitch + ALIGN(x, 64) * 2;
> + break;
> + case 24 ... 32:
> + default:
> + fb_addr = gpu_addr + y * pitch + ALIGN(x, 64) * 4;
> + break;
> + }
> +
> + ls7a_mm_wreg(ldev, FB_ADDR0_REG + reg_offset, fb_addr);
> + ls7a_mm_wreg(ldev, FB_ADDR1_REG + reg_offset, fb_addr);
> + reg_val = lcrtc->cfg_reg | CFG_ENABLE;
> + ls7a_mm_wreg(ldev, FB_CFG_REG + reg_offset, reg_val);
> +}
> +
> +static const uint32_t loongson_formats[] = {
> + DRM_FORMAT_RGB565,
> + DRM_FORMAT_RGB888,
> + DRM_FORMAT_XRGB,
> + DRM_FORMAT_ARGB,
> +};
> +
> +static const uint64_t loongson_format_modifiers[] = { DRM_FORMAT_MOD_LINEAR,
> + DRM_FORMAT_MOD_INVALID };
> +
> +static const struct drm_plane_funcs loongson_plane_funcs = {
> + .atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
> + .atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
> + .destroy = drm_plane_cleanup,
> + .disable_plane = drm_atomic_helper_disable_plane,
> + .reset = drm_atomic_helper_plane_reset,
> + .update_plane = drm_atomic_helper_update_plane,
> +};
> +
> +static const struct drm_plane_helper_funcs loongson_plane_helper_funcs = {
> + .prepare_fb = drm_gem_vram_plane_helper_prepare_fb,
> + .cleanup_fb = drm_gem_vram_plane_helper_cleanup_fb,
> + .atomic_update = loongson_plane_atomic_update,
> +};
> +
> +int loongson_plane_init(struct loongson_crtc *lcrtc)
> +{
> + struct loongson_device *ldev;
> + int crtc_id;
> + int ret;
> +
> + ldev = lcrtc->ldev;
> + crtc_id = lcrtc->crtc_id;
> +
> + ret = drm_universal_plane_init(ldev->dev, >plane, BIT(crtc_id),
> +_plane_funcs, loongson_formats,
> +ARRAY_SIZE(loongson_formats),
> +loongson_format_modifiers,
> +DRM_PLANE_TYPE_PRIMARY, NULL);
> + if (ret) {
> + DRM_ERROR("fail to init planed crtc %d\n", crtc_id);
> + return ret;
> + }
> +
> + drm_plane_helper_add(>plane, _plane_helper_funcs);
> +
> + return 0;
> +}
> --
> 2.32.0
>
--
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, 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
t;
> 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 mode_fixup is
gt; +++ 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 shouldn't be taking further (non-sec
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: Daniel Ve
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 Vetter
Cc: La
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...@lists.freedesk
;
> 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 long list of parameters.
M
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
&g
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 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
> >
-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 = vbox_connector_detect,
>
hat (I can do it locally, but
that doesn't allow me to conveniently reply).
Cheers, 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
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/binder.c
nsertions(+), 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.ffwll.ch
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
<gre...@linuxfoundation.org> 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_fen
g>
Cc: de...@driverdev.osuosl.org
Cc: dri-de...@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org (moderated for non-subscribers)
Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>
---
MAINTAINERS | 2 ++
1 file changed, 2 i
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
nc 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, );
> + if (ret)
> + printf("sync end failed %d\n", errn
o patch queue
> looks like this:
> $ 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
terface.
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 corresponding ion heaps som
_______
> 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
t work for drm. And yes this patch needs to 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 o
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
e_set_base = vbox_crtc_mode_set_base, */
> .disable = 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.freede
On Wed, Aug 2, 2017 at 3:47 PM, Cihangir Akturk <cakt...@gmail.com> 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 <cakt...@gmail.com> wrote:
>> > drm_gem_object_unreference is a compatibilit
rm_gem_object_unreference(obj);
> + drm_gem_object_put(obj);
> ret = 0;
>
> out_unlock:
> --
> 2.7.4
>
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
; <r...@rjwysocki.net>
> Cc: Len Brown <l...@kernel.org>
> Cc: Lucas Stach <l.st...@pengutronix.de>
> Cc: Russell King <linux+etna...@armlinux.org.uk>
> Cc: Christian Gmeiner <christian.gmei...@gmail.com>
> Cc: David Airlie <airl...@linux.ie>
&
vboxvideo/vboxvideo.ko]
>>>> 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.
>
> [1] https://www.spinics.net/lists/target-devel/msg15070.html
>
> Signed-off-by: Logan Gunthorpe <log...@deltatee.com>
> Reviewed-by: Sinclair Yeh <s...@vmware.com>
Acked-by: Daniel Vetter <daniel.vet...@ffwll.ch>
Probably simplest if we pull this in throu
> Please send patches to Greg Kroah-Hartman <g...@kroah.com> and Cc:
> Arve Hjønnevåg <a...@android.com> and Riley Andrews <riandr...@android.com>
> --
> 2.7.4
>
> ___
> Linaro-m
;
Yeah I think improving the dma-buf debugfs stuff (maybe with an allocator
callback to dump additional data) is the better option.
Acked-by: Daniel Vetter <daniel.vet...@ffwll.ch>
> ---
> drivers/staging/android/ion/ion-ioctl.c | 53 +--
> drivers/staging/android/ion/ion.c
ile 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 <labb...@redhat.com>
Reviewed-by: Daniel Vetter <daniel.vet...@ffwll.ch>
> ---
> driv
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 <log...@deltatee.com>
Acked-by: Daniel Vetter <daniel.vet...@ffwll.ch>
Probably makes sense to merge th
atic const char hdlc_unregister_ok[] __exitdata =
> 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
On Sun, Mar 12, 2017 at 2:34 PM, Benjamin Gaignard
<benjamin.gaign...@linaro.org> wrote:
> 2017-03-09 18:38 GMT+01:00 Laura Abbott <labb...@redhat.com>:
>> On 03/09/2017 02:00 AM, Benjamin Gaignard wrote:
>>> 2017-03-06 17:04 GMT+01:00 Daniel Vetter <dan...@ffw
x 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, rec
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:
> > >&
e 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
ly 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 dance forward.
-Daniel
--
Daniel Vetter
So
d 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:
>
> Signed-off-by: Laura Abbott <labb...@redhat.com>
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: D
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 keeping Ion sinc
NFIG_ION_CMA_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 ERR_PTR(-ENODE
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/tegra_ion.c
>
> --
> 2.7.4
>
> --
> To unsubscrib
bit abi and clean 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.
Wi
al 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 a
ile:
> +
> + fd_install(fd, sync_file->file);
> +
> +The sync_file fd now can be sent to userspace.
> +
> +If the creation process fail, or the sync_file needs to be released by any
> +other reason fput(sync_file->file) should be used.
With
M_MODE_ATOMIC_OUT_FENCE flag here.
>
> Comment by Daniel Vetter:
> - Add clean up code for out_fences
>
> Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.co.uk>
> ---
> drivers/gpu/drm/drm_atomic.c | 163
> +-
andard struct fence.
>
> That means that no 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: Comm
-buf/fence-collection.c| 159
> > drivers/dma-buf/fence.c | 2 +-
> > drivers/dma-buf/sync_file.c | 60 +
> > drivers/gpu/drm/Kconfig | 1 +
> > drivers/gpu/drm/drm_atomic.c
linux-foundation.org>
> Cc: David Airlie <airl...@linux.ie>
> Cc: Daniel Vetter <daniel.vet...@intel.com>
> Cc: Rob Clark <robdcl...@gmail.com>
> Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.co.uk>
Ack for i915 parts for merging through
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 <daniel.vet...@ffwll.ch> wrote:
> > Just a bit of wording polish plus mentioning that it can fail and must
> > be restarted.
> >
> > R
pace cannot on coherent 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
Cc: David Herrmann <dh.herrm...@gmail.com>
Cc: Sumit Semwal <sumit.sem...@linaro.org>
Cc: Daniel Vetter <daniel.vet...@intel.com>
CC: linux-me...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Cc: intel-...@lists.freedesktop.org
Cc: de...@driverde
@gmail.com>
Cc: Sumit Semwal <sumit.sem...@linaro.org>
Cc: Daniel Vetter <daniel.vet...@intel.com>
CC: linux-me...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Cc: intel-...@lists.freedesktop.org
Cc: de...@driverdev.osuosl.org
Signed-off-by: Da
s fixes 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 <daniel.vet...@ffwll.ch>
> Date: Thu Feb 11 20:04:51 2016 -0200
>
>
> u32 user_ptr_to_u32(void __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 ptr
or trees with massive 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 mai
es
> higher,
>
> kernel would do something 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.syn
otally 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
lt_timeline_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
On Tue, Jan 19, 2016 at 06:10:40PM -0200, Gustavo Padovan wrote:
> 2016-01-19 Daniel Vetter <dan...@ffwll.ch>:
> > - 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
On Tue, Jan 19, 2016 at 03:52:26PM -0200, Gustavo Padovan wrote:
> 2016-01-19 John Harrison <john.c.harri...@intel.com>:
>
> > On 19/01/2016 15:23, Gustavo Padovan wrote:
> > >Hi Daniel,
> > >
> > >2016-01-19 Daniel Vetter <dan...@ffwll.ch>:
&
On Tue, Dec 15, 2015 at 11:08:01AM -0800, Dmitry Torokhov wrote:
> On Tue, Dec 15, 2015 at 11:00 AM, Gustavo Padovan <gust...@padovan.org> wrote:
> > 2015-12-15 Daniel Vetter <dan...@ffwll.ch>:
> >
> >> On Mon, Dec 14, 2015 at 05:29:55PM -0800, Dmitry Torokh
reproduce it
> > on upstream kernel as well?
>
> 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
ver_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
]
It doesn't apply to my tree :(
Yeah, commit f9b0e251dfbf 'drm: make mode_valid callback optional' is
in the drm tree, so this patch needs to go to Dave Airlie (cc'd).
Though Daniel Vetter may want to send it on.
For Dave's benefit, here is the patch again:
I've pulled it into my drm-stuff
,
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-arm-kernel. Are they stuck somewhere?
-Daniel
--
Daniel Vetter
Software Engineer
,
+ int (*compare)(struct device *, void *), void *compare_data);
+
+#endif
--
1.7.4.4
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer
81 matches
Mail list logo
