Re: [PATCH v3 1/3] drm/loongson: Add DRM Driver for Loongson 7A1000 bridge chip

2021-07-27 Thread Daniel Vetter
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

Re: [PATCH v3 1/3] drm/loongson: Add DRM Driver for Loongson 7A1000 bridge chip

2021-07-23 Thread Daniel Vetter
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

Re: [PATCH RFC PKS/PMEM 09/58] drivers/gpu: Utilize new kmap_thread()

2020-10-09 Thread Daniel Vetter
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 >

Re: [PATCH v7 2/2] drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP bridge driver

2020-04-30 Thread Daniel Vetter
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

Re: [PATCH v7 2/2] drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP bridge driver

2020-04-30 Thread Daniel Vetter
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

Re: [PATCH v7 2/2] drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP bridge driver

2020-04-28 Thread Daniel Vetter
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

Re: [PATCH] staging: android: ion: Skip sync if not mapped

2020-04-17 Thread Daniel Vetter
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

Re: [PATCH] staging: fbtft: Fix Kconfig indentation

2019-11-20 Thread Daniel Vetter
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

[PATCH 04/15] staging/android/ion: delete dma_buf->kmap/unmap implemenation

2019-11-18 Thread Daniel Vetter
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

Re: [PATCH 1/2] staging: android: ion: Remove file ion_carveout_heap.c

2019-07-03 Thread Daniel Vetter
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

Re: [Intel-gfx] [PATCH] dma-buf: add struct dma_buf_attach_info v2

2019-05-03 Thread Daniel Vetter
; > 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

Re: [PATCH] staging: xgifb: delete the driver

2019-04-26 Thread Daniel Vetter
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

Re: [PATCH resend 00/15] staging: vboxvideo: Convert to atomic modesetting API

2018-10-05 Thread Daniel Vetter
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 __

Re: [PATCH 11/15] staging: vboxvideo: Fix DPMS support after atomic conversion

2018-10-02 Thread Daniel Vetter
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: > >>

Re: [PATCH 11/15] staging: vboxvideo: Fix DPMS support after atomic conversion

2018-10-01 Thread Daniel Vetter
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: > >>>

Re: [PATCH 01/15] staging: vboxvideo: Convert to atomic modesetting API

2018-10-01 Thread Daniel Vetter
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

Re: [PATCH 11/15] staging: vboxvideo: Fix DPMS support after atomic conversion

2018-10-01 Thread Daniel Vetter
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 > >

Re: [PATCH 11/15] staging: vboxvideo: Fix DPMS support after atomic conversion

2018-10-01 Thread Daniel Vetter
-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, >

Re: [PATCH 01/15] staging: vboxvideo: Convert to atomic modesetting API

2018-10-01 Thread Daniel Vetter
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

Re: [PATCH v2 05/17] compat_ioctl: move more drivers to generic_compat_ioctl_ptrarg

2018-09-12 Thread Daniel Vetter
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

Re: [PATCH 0/2] staging: vboxvideo: Add page-flip support

2018-08-06 Thread Daniel Vetter
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

Re: [PATCH] staging: android: ion: fix ion_dma_buf_attach signatur

2018-06-21 Thread Daniel Vetter
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

Re: [PATCH] MAINTAINERS: add dri-devel for Android ION

2018-04-04 Thread Daniel Vetter
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

[PATCH] MAINTAINERS: add dri-devel for Android ION

2018-04-04 Thread Daniel Vetter
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

Re: [PATCH 2/2] selftests: ion: Add simple test with the vgem driver

2018-02-19 Thread Daniel Vetter
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

Re: [PATCH 2/2] selftests: ion: Add simple test with the vgem driver

2018-02-19 Thread Daniel Vetter
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

Re: [PATCH v6 2/2] staging: ion: create one device entry per heap

2017-11-27 Thread Daniel Vetter
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

Re: [PATCH v3 2/2] staging: ion: create one device entry per heap

2017-09-25 Thread Daniel Vetter
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

Re: [PATCH 02/15] drm: make device_type const

2017-08-25 Thread Daniel Vetter
_______ > 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

Re: [PATCH v3 28/28] drm: vboxvideo: switch to drm_*_get(), drm_*_put() helpers

2017-08-14 Thread Daniel Vetter
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

Re: [RESEND PATCH] staging: vboxvideo: remove dead gamma lut code

2017-08-09 Thread Daniel Vetter
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

Re: [RESEND PATCH] staging: vboxvideo: remove dead gamma lut code

2017-08-07 Thread Daniel Vetter
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

Re: [PATCH] staging: vboxvideo: use drm_gem_object_put instead of drm_gem_object_unreference

2017-08-02 Thread Daniel Vetter
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

Re: [PATCH] staging: vboxvideo: use drm_gem_object_put instead of drm_gem_object_unreference

2017-08-02 Thread Daniel Vetter
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

Re: [Intel-gfx] [PATCH 0/3] Kconfig dependencies: acpi-video, backlight and thermal

2017-07-26 Thread Daniel Vetter
; <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> &

Re: [PATCH v4] staging: vboxvideo: Add vboxvideo to drivers/staging

2017-06-28 Thread Daniel Vetter
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.

Re: [Intel-gfx] [PATCH v2] dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro

2017-04-20 Thread Daniel Vetter
> > [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

Re: [Linaro-mm-sig] [PATCHv4 12/12] staging/android: Update Ion TODO list

2017-04-19 Thread Daniel Vetter
> 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

Re: [Linaro-mm-sig] [PATCHv4 10/12] staging: android: ion: Remove ion_handle and ion_client

2017-04-19 Thread Daniel Vetter
; 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

Re: [Linaro-mm-sig] [PATCHv4 05/12] staging: android: ion: Break the ABI in the name of forward progress

2017-04-19 Thread Daniel Vetter
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

Re: [PATCH 05/22] drm/i915: Make use of the new sg_map helper function

2017-04-18 Thread Daniel Vetter
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

Re: [PATCH] format-security: move static strings to const

2017-04-06 Thread Daniel Vetter
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

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

2017-03-12 Thread Daniel Vetter
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

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

2017-03-10 Thread Daniel Vetter
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

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

2017-03-06 Thread Daniel Vetter
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

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

2017-03-06 Thread Daniel Vetter
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

Re: [RFC PATCH 10/12] staging: android: ion: Use CMA APIs directly

2017-03-06 Thread Daniel Vetter
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: > > >&

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

2017-03-06 Thread Daniel Vetter
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

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

2017-03-06 Thread Daniel Vetter
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

Re: [RFC PATCH 10/12] staging: android: ion: Use CMA APIs directly

2017-03-06 Thread Daniel Vetter
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

Re: [RFC PATCH 06/12] staging: android: ion: Remove crufty cache support

2017-03-06 Thread 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:

Re: [RFC PATCH 07/12] staging: android: ion: Remove old platform support

2017-03-03 Thread Daniel Vetter
> > 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

Re: [RFC PATCH 12/12] staging; android: ion: Enumerate all available heaps

2017-03-03 Thread 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

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

2017-03-03 Thread Daniel Vetter
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

Re: [RFC PATCH 11/12] staging: android: ion: Make Ion heaps selectable

2017-03-03 Thread Daniel Vetter
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

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

2017-03-03 Thread Daniel Vetter
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

Re: [RFC PATCH 06/12] staging: android: ion: Remove crufty cache support

2017-03-03 Thread Daniel Vetter
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

Re: [PATCH 0/7] de-stage SW_SYNC validation frawework

2016-08-09 Thread Daniel Vetter
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

Re: [PATCH 12/12] Documentation: add Sync File doc

2016-04-27 Thread Daniel Vetter
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

Re: [RFC v2 8/8] drm/fence: add out-fences support

2016-04-26 Thread Daniel Vetter
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 > +-

Re: [RFC v2 1/8] dma-buf/fence: add fence_collection fences

2016-04-26 Thread Daniel Vetter
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

Re: [RFC v2 0/8] drm: explicit fencing support

2016-04-26 Thread Daniel Vetter
-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

Re: [PATCH v12 1/2] kernel.h: add u64_to_user_ptr()

2016-04-22 Thread Daniel Vetter
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

Re: [PATCH] dma-buf: Update docs for SYNC ioctl

2016-03-21 Thread Daniel Vetter
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

Re: [PATCH] dma-buf: Update docs for SYNC ioctl

2016-03-21 Thread Daniel Vetter
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

[PATCH] dma-buf: Update docs for SYNC ioctl

2016-03-21 Thread Daniel Vetter
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

[PATCH] dma-buf: Update docs for SYNC ioctl

2016-03-21 Thread Daniel Vetter
@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

Re: [PATCH] dma-buf, drm, ion: Propagate error code from dma_buf_start_cpu_access()

2016-03-19 Thread Daniel Vetter
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 > >

Re: [PATCH v9 2/3] kernel.h: add to_user_ptr()

2016-03-19 Thread Daniel Vetter
> 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

Re: [PATCH] staging/android: add flags member to sync ioctl structs

2016-03-04 Thread Daniel Vetter
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

Re: [PATCH v3 06/11] staging/android: turn fence_info into a __u64 pointer

2016-02-08 Thread Daniel Vetter
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

Re: [PATCH v2 01/11] dma-buf/sync_file: de-stage sync_file

2016-01-28 Thread Daniel Vetter
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

Re: [RFC 00/29] De-stage android's sync framework

2016-01-20 Thread Daniel Vetter
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

Re: [RFC 00/29] De-stage android's sync framework

2016-01-19 Thread Daniel Vetter
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

Re: [RFC 00/29] De-stage android's sync framework

2016-01-19 Thread Daniel Vetter
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>: &

Re: [PATCH] android: fix warning when releasing active sync point

2015-12-16 Thread Daniel Vetter
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

Re: [PATCH] android: fix warning when releasing active sync point

2015-12-16 Thread Daniel Vetter
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

Re: [PATCH] android: fix warning when releasing active sync point

2015-12-15 Thread Daniel Vetter
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

Re: [PATCH linux-next] imx-drm: imx-tve: remove unused variable

2014-05-27 Thread Daniel Vetter
] 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

Re: [RFC PATCH 0/8] component helper improvements

2014-04-27 Thread Daniel Vetter
, 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

Re: [PATCH RFC 26/46] drivers/base: provide an infrastructure for componentised subsystems

2014-02-07 Thread Daniel Vetter
, + 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